Überwachen und Problembehandlung von DCM Projects¶

Unter diesem Thema wird beschrieben, wie Sie die DCM-Bereitstellungen überwachen und Probleme beim Fehlschlagen von DCM-Plänen beheben können.

Problembehandlung eines DCM project¶

Wenn Sie mit dem DCM project nicht vertraut sind, können Fehler aufgrund von Fehlkonfigurationen oder anderen häufigen Problemen auftreten. In diesem Abschnitt werden diese Fehler beschrieben und wie Sie sie beheben können.

Häufige Ursachen für Fehler¶

In der folgenden Tabelle sind die häufigsten Fehlerursachen bei einer DCM project-Ausführung aufgeführt:


Fehlerkategorie	Häufige Ursachen
Sekundärrollen	Benutzende stellen inkonsistentes Verhalten fest, da sie bei der Ausführung von DCM-Befehlen unwissentlich Berechtigungen von Sekundärrollen nutzen.
Unzureichende Rollenberechtigungen	Unzureichende Rollenberechtigungen, um definierte Objekttypen zu erstellen Unzureichende Rollenberechtigungen, um bestehende Objekte zu ändern oder zu löschen, die nun einer anderen Rolle gehören Unzureichende Rollenberechtigungen zur Verwendung von System-DMFs Unzureichende Rollenberechtigungen zum Ausführen eines Warehouses, um eine dynamische Tabelle beim Erstellen zu aktualisieren
Probleme beim Rendern von Jinja	Probleme beim Rendern von Jinja durch falsche Jinja-Syntax Probleme beim Rendern von Jinja durch Konflikte zwischen Werttypen
Projektprobleme	Falscher Manifestpfad Leere Definitionsordner Veraltete Definitionsdateien im falschen Repo-Zweig Objekte, die bereits von einem anderen DCM project bereitgestellt wurden Projekt- und Objektreferenzen stimmen nicht überein

Empfohlene Schritte zur Problembehandlung¶

Folgen Sie diesen Schritten zur Problembehandlung und dem Debuggen eines DCM project.


Schritt	Details
Sekundärrollen auf „Keine“ festlegen	Stellt sicher, dass die Primärrolle über alle für das DCM project erforderlichen Berechtigungen verfügt und sorgt für ein konsistentes Verhalten über Benutzende und Konten hinweg.
Fehlermeldungen von PLAN verwenden	Prüfen Sie, ob sich die Fehlermeldung auf eine bestimmte Datei- und Zeilennummer bezieht. Überprüfen Sie den Code in der angegebenen Zeile der Quelldatei. Öffnen Sie optional die entsprechende gerenderte Ausgabedatei aus dem Ordner `out/plan/sources/definitions`.
Einschränkungen	Führen Sie PLAN für das Projekt mit nur einer leeren SQL-Datei im Ordner mit den Definitionen aus, um zu bestätigen, dass die Projektberechtigungen und -einstellungen korrekt sind. Fügen Sie dem Projekt nach und nach die Definitionsdateien wieder hinzu.
Client ändern	Wenn der Workflow CI/CD fehlschlägt, versuchen Sie, dieselben CLI-Befehle lokal auszuführen. Wenn die lokalen CLI-Befehle fehlschlagen, versuchen Sie, sie in Workspaces auszuführen. Führen Sie `snow connection test` aus, um das Konto, die Rolle und den Benutzenden zu überprüfen.
Cortex Code für AI-unterstütztes Debugging verwenden	Starten Sie Cortex Code mit dem DCM-Skill, und beschreiben Sie den Fehler. Cortex Code kann die Ausgabe des Plans lesen, Probleme beim Rendern von Jinja diagnostizieren, Berechtigungslücken identifizieren und Korrekturen vorschlagen. Besonders nützlich ist dies für komplexe Jinja-Vorlagenfehler und für Probleme bei der Auflösung von Abhängigkeiten.

DCM project-Bereitstellungen beobachten und überwachen¶

DCM Projects sind so konzipiert, dass sie volle Transparenz und Prüfpfade für alle Änderungen an Ihrer Kontoinfrastruktur bieten. Dies setzt voraus, dass Sie einige Best Practices der Softwareentwicklung für das Einrichten von Bereitstellungsprozessen für Infrastrukturen befolgen. Weitere Informationen dazu finden Sie unter DCM project-Bereitstellung automatisieren.

Verwenden Sie die folgenden Quellen, um frühere Bereitstellungen zu überprüfen:

Bereitstellungsartefakte, die innerhalb des DCM project gespeichert sind
Bereitstellungsverlauf
Ereignisprotokolle von einem DCM project (abhängig von den Einstellungen des Protokolliergrads)

Bereitstellungsartefakte¶

Für jede ausgeführte Bereitstellung wird ein unveränderlicher Snapshot der Bereitstellungsartefakte im DCM project mit den folgenden Informationen gespeichert:

Die Manifest-Datei (manifest.yml)
Alle Objektdefinitions- und Makrodateien (.sql-Dateien) innerhalb des sources-Ordners
Die Ausgabe der PLAN-Operation (plan_result.json) und der DEPLOY-Operation (deploy_result.json), einschließlich:
- Die für diese Bereitstellung verwendeten Vorlagenvariablen
- Bereitstellungs-Metadaten, einschließlich Zeitstempel, Objektname und Abfrage-ID
- Der Änderungssatz

Dieser vollständige Satz macht alle Bereitstellungsaktionen zum Debuggen, Auditing oder zum erneuten Bereitstellen des definierten Status reproduzierbar.

Die folgenden Befehle sind für die Beobachtung und Prüfung eines DCM project verfügbar:

Mit der MONITOR-Berechtigung können Sie Folgendes tun:
- Auflisten aller im DCM project gespeicherten Bereitstellungen
- Auflisten aller Dateien innerhalb einer bestimmten Bereitstellung
- Lesen, Kopieren oder Herunterladen bestimmter Dateien innerhalb dieser Bereitstellung
Mit der OWNERSHIP-Berechtigung können Sie eine Bereitstellung manuell löschen, wenn sie sensible Daten enthält.
Mit der READ-Berechtigung können Sie den DESCRIBE-Befehl ausführen, um den neuesten Bereitstellungsnamen, den Alias und den Zeitstempel für ein ausgewähltes DCM project anzuzeigen.

Beispielbefehle:

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;

snow dcm describe

snow dcm describe --target STAGE

snow dcm list-deployments

snow dcm drop-deployment 'DEPLOYMENT$1'

Bereitstellungsverlauf¶

Die INFORMATION_SCHEMA-Funktionen bieten rollenbasierten Zugriff und Möglichkeiten mit niedriger Latenz, um erfolgreiche und fehlgeschlagene Bereitstellungen für ein ausgewähltes DCM project anzuzeigen.

Die Argumente project_name und result_limit sind optional.

Beispielbefehle:

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
  ));

Ereignisprotokolle¶

Sie können die bevorzugte LOG_LEVEL für das DCM project-Objekt einstellen oder die definierte LOG_LEVEL vom übergeordneten Schema, der übergeordneten Datenbank oder dem übergeordneten Konto erben.

Wenn die LOG_LEVEL für das DCM project festgelegt ist, werden fehlgeschlagene PLAN- und DEPLOY-Ausführungen mit den entsprechenden Fehlermeldungen als Ereignis protokolliert, und Sie können sie durch Abfragen der definierten Ereignistabelle einsehen. Weitere Informationen zum Einrichten von Ereignistabellen und Protokolliergraden finden Sie unter Überblick über die Ereignisse.

Beispiel:

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;

snow logs dcm_project DCM_DEMO.PROJECTS.DCM_PROJECT_DEV \
  --from SNOWFLAKE.TELEMETRY.EVENTS