Überwachung von Ereignistabellen und Warnmeldungen für dynamische Tabellen¶
Unter diesem Thema wird beschrieben, wie Sie eine Ereignistabelle abfragen, die Informationen über Ihren Aktualisierungsstatus liefert, und wie Sie Benachrichtigungen über neue Daten in einer Ereignistabelle einrichten.
Ereignistabelle zur Überwachung von Aktualisierungen abfragen¶
Wenn eine dynamische Tabelle aktualisiert wird, können Sie Snowflake so konfigurieren, dass ein Ereignis aufgezeichnet wird, das Informationen über den Status der Aktualisierungsoperation liefert. Das Ereignis wird in der aktiven Ereignistabelle aufgezeichnet, die mit der dynamischen Tabelle verbunden ist.
Nehmen Sie zum Beispiel an, dass Sie eine Ereignistabelle mit einer Datenbank verknüpft haben. Wenn eine dynamische Tabelle in dieser Datenbank aktualisiert wird, zeichnet Snowflake ein Ereignis in dieser Ereignistabelle auf.
Sie können die in dieser aktiven Ereignistabelle protokollierten Ereignisse abfragen, um die Aktualisierung Ihrer dynamischen Tabellen zu überwachen.
Um beispielsweise den Zeitstempel, den Namen der dynamischen Tabelle, die Abfrage-ID und die Fehlermeldung bei Fehlern mit dynamischen Tabellen in der Datenbank my_db zu erhalten, gehen Sie wie folgt vor:
Im folgenden Beispiel werden alle Spalten für Upstream-Fehler mit dynamischen Tabellen im Schema my_schema abgerufen:
Informationen über die Rolle, die Sie für die Abfrage der Ereignistabelle verwenden müssen, und die Bedingungen, die Sie zum Filtern der Ergebnisse verwenden können, finden Sie unter Benachrichtigung über neue Daten einrichten.
Benachrichtigungen für neue Daten einrichten, um Aktualisierungen zu überwachen¶
Wie bereits erwähnt, wird bei der Aktualisierung einer dynamischen Tabelle ein Ereignis in der Ereignistabelle protokolliert, um anzuzeigen, ob die Aktualisierung erfolgreich war oder nicht. Sie können eine Benachrichtigung über neue Daten einrichten, um die Ereignistabelle zu überwachen. Sie können die Benachrichtigung so konfigurieren, dass eine Benachrichtigung gesendet wird, wenn eine Aktualisierung fehlschlägt.
In den nächsten Abschnitten erfahren Sie, wie Sie die Ereignisprotokollierung einrichten, um die Ereignisse zu erfassen, wie Sie die Benachrichtigung einrichten und wie Sie die in der Ereignistabelle aufgezeichneten Ereignisse interpretieren:
Bemerkung
Die Protokollierung von Ereignissen für dynamische Tabellen ist mit Kosten verbunden. Siehe Kosten der Telemetriedatenerfassung.
Schweregrad der zu erfassenden Ereignisse festlegen¶
Bemerkung
Wenn Sie den Schweregrad nicht festlegen, werden keine Ereignisse erfasst.
Um Ereignisse für dynamische Tabellen einzurichten, die in der Ereignistabelle aufgezeichnet werden sollen, legen Sie den Schweregrad der Ereignisse fest, die in der Ereignistabelle erfasst werden sollen. Ereignisse werden auf den folgenden Ebenen erfasst:
ERROR: Ereignisse für Aktualisierungsfehler.WARN: Fehler bei der Aktualisierung von vorgelagerten dynamischen Tabellen und Ereignisse für Aktualisierungsfehler.INFO: Ereignisse für erfolgreiche Aktualisierung, Fehler bei der Aktualisierung von vorgelagerten dynamischen Tabellen und Ereignisse für Aktualisierungsfehler.
Um den Grad einzustellen,legen Sie den LOG_EVENT_LEVEL-Parameter für das Konto oder Objekt fest. Sie können den Grad für Folgendes festlegen:
Alle Objekte im Konto
Alle Objekte in einer Datenbank oder einem Schema
Eine bestimmte dynamische Tabelle
Beispiel:
Um dynamische Tabellenereignisse auf ERROR-Level für alle unterstützten Objekte im Konto zu erfassen, führen Sie ALTER ACCOUNT SET LOG_EVENT_LEVEL aus:
Das Festlegen von
LOG_EVENT_LEVELauf Account-Ebene gilt für Log-Ereignisse (Record-Typ EVENT) für unterstützte Workloads im Account, einschließlich dynamischer Tabellen. Es ersetzt nicht LOG_LEVEL für Logmeldungen beim Loggen von APIs. Weitere Informationen dazu finden Sie unter Parameter.Um INFO-Level-Ereignisse für alle unterstützten Objekte in der Datenbank
my_dbzu erfassen, führen Sie ALTER DATABASE … SET LOG_EVENT_LEVEL aus:Ähnlich wie beim Festlegen des Levels auf Account-Ebene wirkt sich das Festlegen des Levels auf Datenbankebene auf Log-Ereignisse für unterstützte Objekttypen in der Datenbank aus.
Um WARN-Level-Ereignisse für die dynamische Tabelle
my_dynamic_tablezu erfassen, führen Sie ALTER DYNAMIC … TABLE SET LOG_EVENT_LEVEL aus:
Benachrichtigung über neue Daten einrichten¶
Nachdem Sie den Schweregrad für Protokollierereignisse festgelegt haben, können Sie eine Benachrichtigung über neue Daten einrichten, um die Ereignistabelle auf neue Ereignisse zu überwachen, die auf einen Fehler bei einer dynamischen Tabellenaktualisierung hinweisen. Eine Benachrichtigung über neue Daten wird ausgelöst, wenn neue Zeilen in die Ereignistabelle eingefügt werden, die die in der Benachrichtigung angegebene Bedingung erfüllen.
Bemerkung
Um die Benachrichtigung über neue Daten zu erstellen, müssen Sie eine Rolle verwenden, die über die erforderlichen Berechtigungen zur Abfrage der Ereignistabelle verfügt.
Wenn die Bedingung für die Benachrichtigung die Standard-Ereignistabelle (SNOWFLAKE.TELEMETRY.EVENTS) oder die vordefinierte Ansicht (SNOWFLAKE.TELEMETRY.EVENTS_VIEW Ansicht) abfragt, siehe Rollen für den Zugriff auf die Standard-Ereignistabelle und EVENTS_VIEW.
Um den Zugriff auf die Ansicht EVENTS_VIEW zu verwalten, siehe Verwalten Sie den Zugriff auf die Ansicht EVENTS_VIEW.
Wenn die Bedingung für die Benachrichtigung eine benutzerdefinierte Ereignistabelle abfragt, siehe Zugriffssteuerungsrechte für Ereignistabelle.
Um den Zugriff auf eine benutzerdefinierte Ereignistabelle zu verwalten, siehe Verwalten des Zugriffs auf Ereignistabellendaten.
Um nach Ereignissen in dynamischen Tabellen abzufragen, wählen Sie in der Bedingung der Benachrichtigung Zeilen aus, in denen resource_attributes:"snow.executable.type" = 'DYNAMIC_TABLE' ist. Um die Liste der Ereignisse einzugrenzen, können Sie nach folgenden Spalten filtern:
Um die Ergebnisse auf dynamische Tabellen in einer bestimmten Datenbank zu beschränken, verwenden Sie
resource_attributes:"snow.database.name".Um Ereignisse zurückzugeben, bei denen die Aktualisierung aufgrund eines Fehlers in der dynamischen Tabelle fehlgeschlagen ist, verwenden Sie
value:state = 'FAILED'.Um Ereignisse zurückzugeben, bei denen die Aktualisierung aufgrund eines Fehlers mit einer vorgelagerten dynamischen Tabelle fehlgeschlagen ist, verwenden Sie
value:state = 'UPSTREAM_FAILURE'.
Informationen zu den Werten, die für ein Ereignis in einer dynamischen Tabelle protokolliert werden, finden Sie unter Für Ereignisse in dynamischen Tabellen protokollierte Informationen.
Bemerkung
Die Spalte timestamp in der Ereignistabelle speichert Werte in UTC. Wenn Sie einen geplanten Alert mit einem Zeitstempelfilter verwenden (z. B. timestamp > DATEADD('minute', -5, CURRENT_TIMESTAMP())), konvertieren Sie den aktuellen Zeitstempel in UTC, damit genaue Vergleiche möglich sind:
Die folgende Anweisung erstellt beispielsweise einen Alert für neue Daten, der eine Aktion ausführt, wenn Aktualisierungen von dynamischen Tabellen in der Datenbank my_db fehlschlagen. Das Beispiel nimmt Folgendes an:
Ihre aktive Ereignistabelle ist die Standard-Ereignistabelle (SNOWFLAKE.TELEMETRY.EVENTS).
Sie haben eine Webhook-Benachrichtigungsintegration für diesen Slack-Kanal eingerichtet.
Für Ereignisse in dynamischen Tabellen protokollierte Informationen¶
Wenn eine dynamische Tabelle aktualisiert wird, wird ein Ereignis in der Ereignistabelle protokolliert. Die folgenden Abschnitte beschreiben die Zeile der Ereignistabelle, die das Ereignis darstellt:
Spaltenwerte der Ereignistabelle¶
Wenn eine dynamische Tabelle aktualisiert wird, wird eine Zeile mit den folgenden Werten in die Ereignistabelle eingefügt.
Bemerkung
Wenn eine Spalte unten nicht aufgeführt ist, ist der Spaltenwert für das Ereignis NULL.
Spalte |
Datentyp |
Beschreibung |
|---|---|---|
|
TIMESTAMP_NTZ |
UTC-Zeitstempel für den Zeitpunkt, an dem das Ereignis erstellt wurde. |
|
TIMESTAMP_NTZ |
UTC-Zeit, die für Protokolle verwendet wird. Derzeit ist dies derselbe Wert, der in der Spalte |
|
OBJECT |
Attribute, die die aktualisierte dynamische Tabelle identifizieren. |
|
STRING |
Der Ereignistyp, der |
|
OBJECT |
Details über den Status der Aktualisierung der dynamischen Tabelle. |
|
VARIANT |
Der Status der Aktualisierung der dynamischen Tabelle und, falls die Aktualisierung fehlgeschlagen ist, die Fehlermeldung für den Fehler. |
Schlüssel-Wert-Paare in der Spalte resource_attributes ¶
Die Spalte resource_attributes enthält einen Wert OBJECT mit den folgenden Schlüssel-Wert-Paaren:
Attributname |
Attributtyp |
Beschreibung |
Beispiel |
|---|---|---|---|
|
INTEGER |
Der interne/systemgenerierte Bezeichner der Datenbank, die die dynamische Tabelle enthält. |
|
|
VARCHAR |
Der Name der Datenbank, die die dynamische Tabelle enthält. |
|
|
INTEGER |
Der interne/systemgenerierte Bezeichner der dynamischen Tabelle, die aktualisiert wurde. |
|
|
VARCHAR |
Der Name der dynamischen Tabelle, die aktualisiert wurde. |
|
|
VARCHAR |
Der Typ des Objekts. Der Wert ist |
|
|
INTEGER |
Der interne/systemgenerierte Bezeichner der Rolle mit der Berechtigung OWNERSHIP für die dynamische Tabelle. |
|
|
VARCHAR |
Der Name der Rolle mit der Berechtigung OWNERSHIP für die dynamische Tabelle. |
|
|
VARCHAR |
Der Typ der Rolle, die Eigentümer des Objekts ist, zum Beispiel |
|
|
VARCHAR |
ID der Abfrage, mit der die dynamische Tabelle aktualisiert wurde. |
|
|
INTEGER |
Der interne/systemgenerierte Bezeichner des Schemas, das die dynamische Tabelle enthält. |
|
|
VARCHAR |
Der Name des Schemas, das die dynamische Tabelle enthält. |
|
|
INTEGER |
Der interne/systemgenerierte Bezeichner des Warehouse, das zur Aktualisierung der dynamischen Tabelle verwendet wird. |
|
|
VARCHAR |
Der Name des Warehouse, das zur Aktualisierung der dynamischen Tabelle verwendet wird. |
|
Schlüssel-Wert-Paare in der Spalte record¶
Die Spalte record enthält einen Wert OBJECT mit den folgenden Schlüssel-Wert-Paaren:
Schlüssel |
Typ |
Beschreibung |
Beispiel |
|---|---|---|---|
|
VARCHAR |
Der Name des Ereignisses. Der Wert ist |
|
|
VARCHAR |
Der Schweregrad des Ereignisses, der einen der folgenden Werte annehmen kann:
|
|
Schlüssel-Wert-Paare in der Spalte value¶
Die Spalte value enthält einen Wert VARIANT mit den folgenden Schlüssel-Wert-Paaren:
Schlüssel |
Typ |
Beschreibung |
Beispiel |
|---|---|---|---|
|
VARCHAR |
Der Status der Aktualisierung, der die folgenden Werte annehmen kann:
|
|
|
VARCHAR |
Wenn der Wert für |
|
Abfragen von Pipeline-Bereichen (Spans), um Aktualisierungen zu verfolgen¶
Zusätzlich zu:ref:` Ereignissen<label-dynamic_tables_monitoring_sql_events>` kann Snowflake Pipeline-Bereiche (Spans) für Aktualisierungen dynamischer Tabellen aufzeichnen. Ereignisse und Bereiche (Spans) sind zwei separate Beobachtbarkeitsmechanismen:
Ereignisse (gesteuert durch LOG_LEVEL) liefern Protokolle pro Aktualisierung einer dynamischen Tabelle und geben an, ob jede Aktualisierung erfolgreich war oder fehlgeschlagen ist.
Bereiche (gesteuert durch:ref:
TRACE_LEVEL<label-trace_level>) bieten eine umfassendere Beobachtbarkeit auf Pipeline-Ebene, einschließlich korrelierter Ablaufverfolgungs-IDs über eine Pipeline, Gründe für Überspringen und Abhängigkeitstopologie.
Spans erfassen zusätzliche Zustände, für die keine Ereignisse ausgegeben werden, darunter SKIPPED-Aktualisierungen aufgrund von Überspringen in vorgelagerten Abhängigkeiten sowie Aktualisierungszyklen, bei denen der Scheduler eine Aktualisierung übersprungen hat, um die Verzögerung der dynamischen Tabelle und ihrer Konsumenten zu minimieren.
Bemerkung
Die Aufzeichnung von Bereichen (Spans) für dynamische Tabellen verursacht Kosten. Siehe Kosten der Telemetriedatenerfassung.
Aktivieren Sie Pipeline-Bereiche (Spans).¶
Um Pipeline-Bereiche (Spans) für Aktualisierungen dynamischer Tabellen zu aktivieren, stellen Sie den TRACE_LEVEL-Parameter auf Datenbank- oder Schemaebene auf ALWAYS:
Sie können dies auch auf Datenbankebene einstellen, um Bereiche (Spans) für alle dynamischen Tabellen in der Datenbank zu erfassen:
Abfragen von Bereichsdaten¶
Um Pipeline-Spans für Aktualisierungen dynamischer Tabellen abzufragen, filtern Sie nach Zeilen, mit record_type = 'SPAN' und record:"name" = 'table_refresh':
Bereichsattribute (record_attributes )¶
Jede Bereichszeile enthält in der record_attributes-Spalte die folgenden Attribute, die spezifisch für Aktualisierungen dynamischer Tabellen sind:
Attributname |
Typ |
Beschreibung |
|---|---|---|
|
STRING |
Status der Aktualisierung: |
|
STRING |
Warum die dynamische Tabelle übersprungen wurde oder fehlgeschlagen ist. NULL bei Erfolg. Mögliche Werte:
|
|
STRING |
Zeitstempel der Transaktion zum Zeitpunkt, als die Aktualisierung ausgewertet wurde. (Dies kann einen Moment vor dem tatsächlichen Zeitpunkt der Aktualisierung liegen.) Alle Daten in Basisobjekten, die vor diesem Zeitstempel eingegangen sind, sind in der dynamischen Tabelle enthalten. |
Bemerkung
Bereiche (Spans) decken SKIPPED-Status (mit Gründen UPSTREAM_SKIP und``NOT_EFFECTIVE_TICK_TO_REFRESH`` ) ab, für die Ereignisse nicht ausgegeben werden. Wenn Sie Einblick in übersprungene Aktualisierungen benötigen, verwenden Sie Bereiche (Spans) anstelle von Ereignissen.
Pipeline-Korrelation mit Trace-IDs und Bereichslinks¶
Eine einzigartige Fähigkeit von Bereichen (Spans) ist die Korrelation auf Pipeline-Ebene. Wenn ein Aktualisierungszyklus Aktualisierungsoperationen für mehrere dynamische Tabellen umfasst, haben alle resultierenden Bereiche (Spans) dieselbe``trace:“trace_id“``. So können Sie den vollständigen Satz von Aktualisierungsoperationen rekonstruieren, die in einer einzelnen Aktualisierungsoperation ausgeführt wurden.
Jeder Bereich (Span) enthält auch einen record:"links"-Array, der die span_id jeder Upstream-Abhängigkeit auflistet. Beispiel: Wenn DT_B von DT_A abhängt, erscheint die span_id von DT_A in record:"links" von DT_B.
Das record:"status":"code"-Feld ist STATUS_CODE_OK für Erfolge und Überspringen, und STATUS_CODE_ERROR für Fehler.
Um beispielsweise alle Aktualisierungsoperationen dynamischer Tabellen in einem einzigen Aktualisierungszyklus zu korrelieren, fragen Sie nach Bereichen mit derselben trace_id:
Tracking der Aktualisierung einer Pipeline¶
Dieser Abschnitt zeigt Schritt für Schritt, wie Sie Pipeline-Bereiche nutzen, um einen Aktualisierungszyklus von Anfang bis Ende nachzuvollziehen: vom Auffinden der relevanten Bereiche über das Abrufen der vollständigen Pipeline bis hin zur Diagnose von Fehlern oder übersprungenen Ausführungen.
Beispiel-Pipeline-Szenario¶
Betrachten Sie eine lineare Pipeline mit vier dynamischen Tabellen:
In diesem Beispiel werden DT1 und DT2 erfolgreich aktualisiert, während DT3 aufgrund eines Abfragefehlers fehlschlägt. Weil DT3 fehlschlägt, wird DT4 automatisch mit dem Grund UPSTREAM_FAILURE übersprungen.
Die folgenden Schritte zeigen, wie Sie die Pipeline-Bereiche (Spans) für dieses Szenario abrufen und interpretieren.
Schritt 1: Ermitteln des Bereichs für eine dynamische Tabelle¶
Um die Aktualisierung einer bestimmten dynamischen Tabelle zu untersuchen, fragen Sie die Ereignistabelle nach dem letzten Bereich (Span) ab. Filtern Sie nach Datenbank, Schema und Name der dynamischen Tabelle, um sicherzustellen, dass Sie das richtige Objekt finden:
Der trace_id-Wert kennzeichnet den Aktualisierungszyklus. Alle dynamischen Tabellenbereiche (Spans) innerhalb einer einzelnen Pipeline-Aktualisierung haben dieselbe``trace_id``. Verwenden Sie diesen Wert im nächsten Schritt, um alle Bereiche (Spans) aus demselben Aktualisierungszyklus abzurufen.
Schritt 2: Abrufen der vollständigen Pipeline¶
Alle Bereiche (Spans) abfragen, die dieselbe trace_id haben, um jede dynamische Tabelle im Aktualisierungszyklus anzuzeigen. Schließen Sie record:"links" ein, um das Abhängigkeitsdiagramm zu erfassen, und DATEDIFF, um die Dauer jeder Aktualisierungsoperation zu berechnen:
Aus diesem Ergebnis können Sie das vollständige Bild des Aktualisierungszyklus ableiten:
DT1undDT2erfolgreich (30 bzw. 29 Sekunden).DT3schlug nach 19 Sekunden aufgrund eines Abfragefehlers fehl.DT4wurde sofort übersprungen (dargestellt durch einen Null-Zeitbereich), da seine Upstream-Abhängigkeit fehlgeschlagen ist.Die
UPSTREAM_LINKS-Spalte zeigt die direkten Abhängigkeiten jeder dynamischen Tabelle nachspan_idab.
Schritt 3: Identifizieren der Ursache eines Fehlers oder Überspringens¶
Wenn eine dynamische Tabelle übersprungen wird oder fehlschlägt, können Sie deren Upstream-Abhängigkeiten über die Bereichslinks verfolgen, um die Ursache zu finden. Diese Abfrage löst die Bereichsverknüpfungen einer bestimmten dynamischen Tabelle wieder zu den anderen Bereichen (Spans) in der Pipeline auf:
In diesem Beispiel wurde DT4 übersprungen, da die vorgelagerte Abhängigkeit DT3 mit QUERY_FAILURE fehlgeschlagen ist. Sie können die query_id verwenden, um die fehlgeschlagene Abfrage weiter zu untersuchen (z. B. durch Aufrufen von GET_QUERY_OPERATOR_STATS oder Überprüfen des Abfrageverlaufs).
Für längere Abhängigkeitsketten wiederholen Sie dasselbe Vorgehen: Ersetzen Sie den Namen der Ziel-dynamischen Tabelle, um weiter stromaufwärts zu gehen, bis Sie einen Bereich mit state = 'FAILED' und state_reason = 'QUERY_FAILURE' erreichen – das ist die eigentliche Ursache.
Nachgelagerte Auswirkungen eines Fehlers ermitteln¶
Um herauszufinden, welche dynamischen Tabellen von einem bestimmten Fehler betroffen waren, führen Sie die Suche nach dem Bereichslink aus. Diese Abfrage findet alle dynamischen Tabellen, deren record:"links" auf die span_id der fehlgeschlagenen dynamischen Tabelle verweisen:
Gibt die direkten Abhängigen der fehlgeschlagenen dynamischen Tabelle zurück. Um alle transitiv betroffenen dynamischen Tabellen zu finden, wiederholen Sie die Abfrage mit jeder abhängigen``span_id``, um weiter stromabwärts zu gehen.
Verwenden Sie kompatible OpenTelemetry-Tools¶
Pipeline-Bereiche dynamischer Tabellen folgen dem OpenTelemetry-Standard-Datenmodell. Da alle Bereiche in einem Aktualisierungszyklus dieselbe trace:"trace_id" gemeinsam nutzen, können Sie diese aus der Ereignistabelle in OpenTelemetry-kompatible Tools zur Visualisierung exportieren.
Diese Tools können die Pipeline als Ablaufverfolgungszeitleiste darstellen und die Dauer und den Status der Aktualisierungsoperation jeder dynamischen Tabelle sowie die in den Bereichslinks kodierten Abhängigkeitsbeziehungen anzeigen.