Surveillance et dépannage DCM Projects

Cette rubrique explique comment surveiller les déploiements DCM et dépanner les plans DCM qui échouent.

Dépanner un DCM project

Si vous n’êtes pas familier avec le DCM project, vous risquez de rencontrer des erreurs dues à des mauvaise configurations ou à d’autres pièges courants. Cette section décrit ces erreurs et explique comment les résoudre.

Causes courantes d’erreurs

Le tableau suivant énumère les causes courantes d’erreurs dans une exécution DCM project :

Catégorie d’erreur

Causes courantes

Rôles secondaires

  • Les utilisateurs rencontrent des comportements incohérents parce qu’ils exploitent sans le savoir les privilèges des rôles secondaires lors de l’exécution de commandes DCM.

Privilèges de rôle insuffisants

  • Privilèges de rôle insuffisants pour créer des types d’objets définis

  • Privilèges de rôle insuffisants pour modifier ou supprimer des objets existants qui appartiennent désormais à un autre rôle

  • Privilèges de rôle insuffisants pour utiliser des DMFs système

  • Privilèges de rôle insuffisants pour exécuter un entrepôt et actualiser une table dynamique lors de la création

Problèmes de rendu Jinja

  • Problèmes de rendu Jinja provenant d’une syntaxe Jinja incorrecte

  • Problèmes de rendu Jinja provenant de discordances de type valeur

Problèmes de projet

  • Chemin de manifeste incorrect

  • Dossiers de définition vides

  • Fichiers de définition obsolètes sur la mauvaise branche du référentiel

  • Objets déjà déployés par un autre DCM project

  • Références de projet et d’objet non concordantes

Observer et auditer les déploiements DCM project

Les DCM Projects sont conçus pour fournir une transparence totale et des chemins d’audit pour toutes les modifications apportées à votre infrastructure de compte. Cela vous oblige à suivre quelques bonnes pratiques de développement logiciel pour mettre en place les processus de déploiement d’infrastructure. Pour plus d’informations, voir Automatiser un déploiement DCM project.

Utilisez les sources suivantes pour examiner les déploiements précédents :

Artefacts de déploiement

Pour chaque déploiement exécuté, un instantané immuable des artefacts de déploiement stocké dans le DCM project, avec les informations suivantes :

  • Le fichier manifeste (manifest.yml)

  • Tous les fichiers de définition d’objets et macros (fichiers .sql) à l’intérieur du dossier sources

  • La sortie de l’opération PLAN (plan_result.json) et l’opération DEPLOY (deploy_result.json), dont :

    • Les variables de modèle utilisées pour ce déploiement

    • Métadonnées du déploiement, y compris l’horodatage, le nom de l’objet et l’ID de la requête

    • L’ensemble des modifications

Cet ensemble complet rend toutes les actions de déploiement reproductibles pour le débogage, l’audit ou le redéploiement de l’état défini.

Les commandes suivantes sont disponibles pour observer et auditer un DCM project :

  • Avec le privilège MONITOR, vous pouvez :

    • Lister tous les déploiements stockés dans l’DCM project.

    • Lister tous les fichiers à l’intérieur d’un déploiement spécifié.

    • Lire, copier ou télécharger des fichiers spécifiques à l’intérieur de ce déploiement.

  • Avec le privilège OWNERSHIP, vous pouvez supprimer manuellement un déploiement s’il contient des données sensibles.

  • Avec le privilège READ, vous pouvez exécuter la commande DESCRIBE pour afficher le nom de déploiement, l’alias et l’horodatage les plus récents pour un DCM project sélectionné.

Exemples de commandes :

DESCRIBE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV;

SHOW DEPLOYMENTS IN DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV;

LIST 'snow://project/DCM_DEMO.PROJECTS.DCM_PROJECT_DEV/deployments/DEPLOYMENT$1/';

ALTER DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV DROP DEPLOYMENT DEPLOYMENT$1;

Historique du déploiement

Les fonctions INFORMATION_SCHEMA fournissent un accès basé sur les rôles et des moyens à faible latence pour voir les déploiements réussis et échoués pour un DCM project sélectionné.

Les arguments project_name et result_limit sont facultatifs.

Exemples de commandes :

SELECT
  START_TIMESTAMP,
  END_TIMESTAMP,
  STATUS,
  DEPLOYMENT_NUMBER,
  DEPLOYMENT_ALIAS,
  CONFIGURATION_PROFILE,
  ERROR_MESSAGE,
  EXECUTOR_ROLE,
  STATS
FROM
  TABLE (DCM_DEMO.INFORMATION_SCHEMA.DCM_DEPLOYMENT_HISTORY(
    project_name => 'DCM_DEMO.PROJECTS.DCM_PROJECT_DEV',
    result_limit => 50
  ));

Journaux d’événements

Vous pouvez définir le LOG_LEVEL privilégié sur l’objet DCM project ou hériter du LOG_LEVEL défini pour le schéma, la base de données ou le compte parent(e).

Si le LOG_LEVEL pour le DCM project est défini, les exécutions PLAN et DEPLOY échouées sont enregistrées avec les messages d’erreur correspondants sous forme d’événement, et vous pouvez les voir en interrogeant le tableau des événements défini. Pour plus d’informations sur la configuration des tableaux des événements et des niveaux de journalisation, consultez Aperçu de la table d’événements.

Par exemple :

SELECT
  TIMESTAMP,
  RESOURCE_ATTRIBUTES:"snow.executable.name" ::STRING AS PROJECT_NAME,
  CASE
    WHEN RESOURCE_ATTRIBUTES:"snow.project.dcm.execution.command" ::STRING = 'plan' THEN 'PLAN'
    WHEN RESOURCE_ATTRIBUTES:"snow.project.dcm.execution.command" ::STRING = 'deploy' THEN 'DEPLOY'
    ELSE RESOURCE_ATTRIBUTES:"snow.project.dcm.execution.command" ::STRING
  END AS COMMAND,
  CASE
    WHEN VALUE:"state" ::STRING = 'SUCCEEDED' THEN 'SUCCEEDED'
    WHEN VALUE:"state" ::STRING = 'FAILED' THEN 'FAILED'
    ELSE VALUE:"state" ::STRING
  END AS STATUS,
  COALESCE(
    CONCAT('Error message: ',VALUE:"message"::STRING),
    VALUE:"operation"::STRING)
  AS OPERATIONS,
  RESOURCE_ATTRIBUTES:"snow.session.role.primary.name" ::STRING AS ROLE,
  RESOURCE_ATTRIBUTES:"db.user" ::STRING AS USER_NAME,
  RECORD:"severity_text" ::STRING AS SEVERITY
FROM
  SNOWFLAKE.TELEMETRY.EVENTS
WHERE
  RESOURCE_ATTRIBUTES:"snow.executable.type" ::STRING = 'DCM_PROJECT'
ORDER BY
  TIMESTAMP DESC
LIMIT
  250;