Surveillance des tables d’événements et alertes pour les tables dynamiques¶
Ce sujet explique comment interroger une table d’événements qui fournit des informations sur votre statut d’actualisation et comment configurer des alertes sur les nouvelles données d’une table d’événements.
Interrogation d’une table d’événements pour surveiller les actualisations¶
Lorsqu’une table dynamique est rafraîchie, vous pouvez configurer Snowflake pour qu’il enregistre un événement qui fournit des informations sur le statut de l’opération d’actualisation. L’événement est enregistré dans la table d’événements actifs associée à la table dynamique.
Par exemple, supposons que vous ayez associé une table d’événements à une base de données. Lorsqu’une table dynamique de cette base de données est actualisée, Snowflake enregistre un événement dans cette table.
Vous pouvez effectuer une requête sur les événements connectés dans cette table d’événements active pour surveiller les actualisations de votre table dynamique.
Par exemple, pour obtenir l’horodatage, le nom de la table dynamique, l’ID de requête et le message d’erreur pour les erreurs avec les tables dynamiques dans la base de données my_db, procédez comme suit :
L’exemple suivant récupère toutes les colonnes pour les erreurs en amont avec les tables dynamiques dans le schéma my_schema :
Pour plus d’informations sur le rôle que vous devez utiliser pour interroger la table des événements et sur les conditions que vous pouvez utiliser pour filtrer les résultats, voir Paramétrer une alerte en cas de nouvelles données.
Définir des alertes sur les nouvelles données pour surveiller les mises à jour¶
Comme indiqué précédemment à l’adresse, lorsqu’une table dynamique est actualisée, un événement est connecté à la table des événements pour indiquer si l’actualisation a réussi ou échoué. Vous pouvez paramétrer une alerte sur les nouvelles données pour surveiller la table des événements. Vous pouvez configurer l’alerte de manière à ce que envoie une notification en cas d’échec de l’actualisation.
Les sections suivantes expliquent comment configurer la connexion des événements pour enregistrer les événements, comment configurer l’alerte et comment interpréter les événements enregistrés dans la table des événements :
Note
Connecter les événements pour les tables dynamiques engendre des coûts. Voir Coûts de la collecte de données de télémétrie.
Définition du niveau de gravité des événements sur capturer¶
Note
Si vous n’avez pas défini le niveau de gravité, aucun événement ne sera capturé.
Pour configurer l’enregistrement des événements de la table dynamique dans la table des événements, définissez le niveau de gravité des événements que vous souhaitez capturer dans la table des événements. Les événements sont saisis aux niveaux suivants :
ERROR: actualiser les événements d’échec.WARN: échecs d’actualisation des tables dynamiques en amont et événements d’échec d’actualisation.INFO: les événements d’actualisation réussis, les échecs d’actualisation des tables dynamiques en amont et les événements d’échec d’actualisation.
Pour définir le niveau, définissez le paramètre LOG_EVENT_LEVEL pour le compte ou l’objet. Vous pouvez définir le niveau pour :
Tous les objets du compte.
Tous les objets d’une base de données ou d’un schéma.
Une table dynamique spécifique.
Par exemple :
Pour capturer des événements de table dynamique de niveau ERROR pour tous les objets pris en charge dans le compte, exécutez ALTER ACCOUNT SET LOG_EVENT_LEVEL :
Définir
LOG_EVENT_LEVELau niveau du compte s’applique aux événements de journal (type d’enregistrementEVENT) pour les charges de travail prises en charge dans le compte, y compris les tables dynamiques. Il ne remplace pas LOG_LEVEL pour les messages de journalisation des APIs de journalisation. Pour plus d’informations, voir Paramètres.Pour capturer des événements de niveau INFO pour tous les objets pris en charge dans la base de données``my_db`` , exécutez ALTERDATABASE …SET LOG_EVENT_LEVEL :
Comme pour la définition du niveau sur le compte, la définition du niveau sur la base de données affecte les événements de journal pour les types d’objets pris en charge dans la base de données.
Pour capturer des événements de niveau WARN pour la table dynamique``my_dynamic_table``, exécutez ALTER DYNAMIC TABLE … SET LOG_EVENT_LEVEL :
Paramétrer une alerte en cas de nouvelles données¶
Après avoir défini le niveau de gravité des événements de journalisation, vous pouvez configurer une alerte sur les nouvelles données pour surveiller la table d’événements à la recherche de nouveaux événements indiquant une défaillance dans l’actualisation de la table dynamique. Une alerte sur les nouvelles données est déclenchée lorsque de nouvelles lignes sont insérées dans la table de l’événement et remplissent la condition spécifiée dans l’alerte.
Note
Pour créer l’alerte sur de nouvelles données, vous devez utiliser un rôle qui a reçu les privilèges nécessaires pour interroger la table des événements.
Si la condition d’alerte interroge la table d’événements par défaut (SNOWFLAKE.TELEMETRY.EVENTS) ou la vue prédéfinie (SNOWFLAKE.TELEMETRY.EVENTS_VIEW la vue), voir Rôles pour l’accès à la table d’événements par défaut et EVENTS_VIEW.
Pour gérer l’accès à la vue EVENTS_VIEW, voir Gérer l’accès à la vue EVENTS_VIEW.
Si la condition d’alerte interroge une table d’événements personnalisée, voir Privilèges de contrôle d’accès pour les tables d’événements.
Pour gérer l’accès à une table d’événements personnalisée, voir Gestion de l’accès aux données des tables d’événements.
Dans la condition d’alerte, pour effectuer une requête sur les événements de la table dynamique, sélectionnez les lignes où resource_attributes:"snow.executable.type" = 'DYNAMIC_TABLE'. Pour réduire la liste des événements, vous pouvez filtrer sur les colonnes suivantes :
Pour limiter les résultats aux tables dynamiques d’une base de données spécifique, utilisez
resource_attributes:"snow.database.name".Pour renvoyer les événements où l’actualisation a échoué en raison d’une erreur avec la table dynamique, utilisez
value:state = 'FAILED'.Pour renvoyer les événements dans lesquels l’actualisation a échoué en raison d’une erreur avec une table dynamique en amont, utilisez
value:state = 'UPSTREAM_FAILURE'.
Pour obtenir des informations sur les valeurs connectées pour un événement de table dynamique, voir Informations journalisées pour les événements de table dynamique.
Note
La colonne timestamp dans le tableau des événements stocke les valeurs en UTC. Si vous utilisez une alerte programmée avec un filtre d’horodatage (par exemple, timestamp > DATEADD('minute', -5, CURRENT_TIMESTAMP())), convertissez l’horodatage actuel en UTC afin de garantir des comparaisons précises :
Par exemple, l’instruction suivante crée une alerte sur les nouvelles données qui exécute une action lorsque les actualisations échouent pour les tables dynamiques dans la base de données my_db. L’exemple suppose que :
Votre table d’événements active est la table d’événements par défaut <label-logging_event_table_default> (SNOWFLAKE.TELEMETRY.EVENTS).
Vous avez mis en place une intégration de notification par webhook pour ce canal Slack.
Informations journalisées pour les événements de table dynamique¶
Lorsqu’une table dynamique est rafraîchie, un événement est connecté à la table des événements. Les sections suivantes décrivent la ligne de la table des événements qui représente l’événement :
Valeurs des colonnes de la table des événements¶
Lorsqu’une table dynamique est actualisée, une ligne contenant les valeurs suivantes est insérée dans la table des événements.
Note
Si une colonne n’est pas listée ci-dessous, la valeur de la colonne est NULL pour l’événement.
Colonne |
Type de données |
Description |
|---|---|---|
|
TIMESTAMP_NTZ |
L’horodatage UTC de la création d’un événement. |
|
TIMESTAMP_NTZ |
Un horaire UTC utilisé pour les journaux. Actuellement, il s’agit de la même valeur que celle qui figure dans la colonne |
|
OBJECT |
Attributs qui identifient la table dynamique qui a été rafraîchie. |
|
STRING |
Le type d’événement, qui est |
|
OBJECT |
Détails du statut d’actualisation de la table dynamique. |
|
VARIANT |
Le statut d’actualisation de la table dynamique et, si l’actualisation a échoué, le message d’erreur correspondant. |
Paires de valeurs clés dans la colonne resource_attributes ¶
La colonne resource_attributes contient une valeur OBJECT avec les paires clés-valeurs suivantes :
Nom d’attribut |
Type d’attribut |
Description |
Exemple |
|---|---|---|---|
|
INTEGER |
L’identificateur interne/généré par le système de la base de données contenant la table dynamique. |
|
|
VARCHAR |
Le nom de la base de données contenant la table dynamique. |
|
|
INTEGER |
L’identificateur interne/généré par le système de la table dynamique qui a été actualisée. |
|
|
VARCHAR |
Le nom de la table dynamique qui a été actualisée. |
|
|
VARCHAR |
Le type de l’objet. La valeur est |
|
|
INTEGER |
L’identificateur interne/généré par le système du rôle avec le privilège OWNERSHIP sur la table dynamique. |
|
|
VARCHAR |
Le nom du rôle ayant le privilège OWNERSHIP sur la table dynamique. |
|
|
VARCHAR |
Type de rôle qui possède l’objet, par exemple |
|
|
VARCHAR |
ID de la requête qui a actualisé la table dynamique. |
|
|
INTEGER |
L’identificateur interne/généré par le système du schéma contenant la table dynamique. |
|
|
VARCHAR |
Le nom du schéma contenant la table dynamique. |
|
|
INTEGER |
L’identificateur interne/généré par le système de l’entrepôt utilisé pour actualiser la table dynamique. |
|
|
VARCHAR |
Le nom de l’entrepôt utilisé pour actualiser la table dynamique. |
|
Paires de valeurs clés dans la colonne record¶
La colonne record contient une valeur OBJECT avec les paires clés-valeurs suivantes :
Clé |
Type |
Description |
Exemple |
|---|---|---|---|
|
VARCHAR |
Nom de l’événement. La valeur est``refresh.status`` pour l’actualisation des tables dynamiques. |
|
|
VARCHAR |
Le niveau de gravité de l’événement, qui correspond à l’une des valeurs suivantes :
|
|
Paires de valeurs clés dans la colonne value¶
La colonne value contient une valeur VARIANT avec les paires clés-valeurs suivantes :
Clé |
Type |
Description |
Exemple |
|---|---|---|---|
|
VARCHAR |
L’état de l’actualisation, qui peut prendre l’une des valeurs suivantes :
|
|
|
VARCHAR |
Si la valeur de |
|
Interroger les spans des pipelines pour tracer les actualisations¶
En plus des événements, Snowflake peut enregistrer des spans de pipeline pour les actualisations des tables dynamiques. Les événements et les spans sont deux mécanismes d’observabilité distincts :
Événements (contrôlés par LOG_LEVEL) fournissent des journaux par actualisation de table dynamique, indiquant si chaque actualisation a réussi ou échoué.
Plages (contrôlé par:ref:
TRACE_LEVEL<label-trace_level>) fournissent une observabilité plus riche au niveau du pipeline, y compris les IDs de traces corrélés sur un pipeline, les motifs d’actualisations omises et la topologie des dépendance.
Les spans capturent des états supplémentaires pour lesquels les événements ne sont pas émis, notamment les actualisations SKIPPED en raison d’omissions en amont ou de cycles d’actualisation où le planificateur a ignoré l’actualisation afin de minimiser la latence de la table dynamique et de ses consommateurs.
Note
L’enregistrement des spans pour les tables dynamiques entraîne des coûts. Voir Coûts de la collecte de données de télémétrie.
Activer les spans de pipeline¶
Pour activer les spans de pipeline pour les actualisations des tables dynamiques, définissez le paramètre TRACE_LEVEL sur ALWAYS au niveau de la base de données ou du schéma :
Vous pouvez également définir ce paramètre au niveau de la base de données pour capturer les spans de toutes les tables dynamiques de la base de données :
Interroger les données des spans¶
Pour interroger les spans de pipeline pour les actualisations des tables dynamiques, filtrez les lignes où record_type = 'SPAN' et record:"name" = 'table_refresh' :
Attributs de span (record_attributes )¶
Chaque ligne de span comprend les attributs suivants dans la colonne record_attributes, spécifique aux actualisations des tables dynamiques :
Nom d’attribut |
Type |
Description |
|---|---|---|
|
STRING |
L’état de l’actualisation : |
|
STRING |
Pourquoi la table dynamique a été ignorée ou pourquoi elle a échoué. NULL sur la réussite. Valeurs possibles :
|
|
STRING |
L’horodatage transactionnel au moment où l’actualisation a été évaluée. (Il se peut que cette date soit légèrement antérieure à l’heure réelle de l’actualisation.) Toutes les données, dans les objets de base, qui sont arrivées avant cet horodatage sont incluses dans la table dynamique. |
Note
Les spans couvrent les états SKIPPED (avec les motifs``UPSTREAM_SKIP`` et NOT_EFFECTIVE_TICK_TO_REFRESH) pour lesquels les événements ne sont pas émis. Si vous avez besoin de visibilité sur les actualisations ignorées, utilisez des spans à la place des événements.
Corrélation du pipeline avec les IDs de trace et les liens des spans¶
Une capacité unique de spans est la corrélation au niveau du pipeline. Lorsqu’un cycle d’actualisation comprend des opérations d’actualisation pour plusieurs tables dynamiques, tous les spans résultants partagent le même trace:"trace_id". Cela vous permet de reconstruire l’ensemble des opérations d’actualisation qui se sont produites dans un seul cycle d’actualisation.
Chaque span comprend également un tableau record:"links" qui répertorie l’span_id de chaque dépendance en amont. Par exemple, si DT_B dépend de DT_A, puis l’span_id de DT_A apparaît dans les record:"links" de DT_B.
Le champ record:"status":"code" est``STATUS_CODE_OK`` pour les réussites et les omissions, et``STATUS_CODE_ERROR`` pour les échecs.
Par exemple, pour corréler toutes les opérations d’actualisation de tables dynamiques dans un seul cycle d’actualisation, effectuez une requête pour les spans ayant le même trace_id :
Tracer une actualisation de pipeline¶
Cette section explique comment utiliser les spans de pipeline pour tracer un cycle d’actualisation de bout en bout : rechercher des spans appropriés, récupérer le pipeline complet et diagnostiquer des défaillances ou des omissions.
Exemple de scénario de pipeline¶
Considérons un pipeline linéaire de quatre tables dynamiques :
Dans cet exemple,``DT1`` et DT2 s’actualisent correctement, mais DT3 échoue en raison d’une erreur de requête. Étant donné que DT3 est un échec, DT4 est automatiquement ignoré avec le motif UPSTREAM_FAILURE.
Les étapes suivantes montrent comment récupérer et interpréter les spans de pipeline pour ce scénario.
Étape 1 : Rechercher le span d’une table dynamique¶
Pour étudier l’actualisation d’une table dynamique spécifique, interrogez la table des événements pour trouver son span le plus récent. Filtrez par nom de base de données, de schéma et de table dynamique pour vous assurer que vous faites correspondre l’objet correct :
La valeur trace_id identifie le cycle d’actualisation. Tous les spans de tables dynamiques dans une même actualisation de pipeline partagent le même trace_id. Utilisez cette valeur à l’étape suivante pour récupérer tous les spans du même cycle d’actualisation.
Étape 2 : Récupérer le pipeline complet¶
Interrogez tous les spans qui partagent le même trace_id pour voir chaque table dynamique dans le cycle d’actualisation. Incluez record:"links" pour capturer le graphique de dépendance et DATEDIFF pour calculer la durée de chaque opération d’actualisation :
À partir de ce résultat, vous pouvez voir une vue complète du cycle d’actualisation :
DT1etDT2ont réussi (30 et 29 secondes respectivement).DT3a échoué après 19 secondes en raison de l’échec d’une requête.DT4a été ignoré immédiatement (représenté par un span de durée zéro), parce que sa dépendance en amont a échoué.La colonne
UPSTREAM_LINKSmontre les dépendances directes de chaque table dynamique parspan_id.
Étape 3 : Identifier la cause profonde d’un échec ou d’une omission¶
Lorsqu’une table dynamique est ignorée ou échoue, vous pouvez tracer ses dépendances en amont par le biais des liens de span afin de trouver la cause principale. Cette requête résout les liens de span d’une table dynamique spécifique vers les autres spans du pipeline :
Dans cet exemple, DT4 a été ignoré, car sa dépendance en amont DT3 a échoué avec QUERY_FAILURE. Vous pouvez utiliser l’query_id pour examiner la requête qui a échoué (par exemple, en appelant GET_QUERY_OPERATOR_STATS ou en vérifiant l’historique des requêtes).
Pour les chaînes de dépendances plus longues, répétez le même schéma : remplacez le nom de la table dynamique cible pour aller plus en amont jusqu’à ce que vous atteigniez un span avec state = 'FAILED' et state_reason = 'QUERY_FAILURE', qui est la cause principale.
Déterminer l’impact en aval d’une défaillance¶
Pour savoir quelles tables dynamiques ont été affectées par une défaillance spécifique, inversez la recherche du lien de span. Cette requête recherche toutes les tables dynamiques dont les record:"links" référencent l’span_id de la table dynamique ayant échoué :
Cela renvoie les dépendances directes de la table dynamique ayant échoué. Pour trouver toutes les tables dynamiques affectées de façon transitoire, répétez la requête avec l’span_id de chaque dépendant pour aller plus en aval.
Utiliser des outils compatibles OpenTelemetry¶
Les spans de pipeline de table dynamique suivent le modèle de données OpenTelemetry standard. Parce que tous les spans d’un cycle d’actualisation partagent le même trace:"trace_id", vous pouvez les exporter depuis la table des événements vers les outils compatibles OpenTelemetry pour la visualisation.
Ces outils peuvent restituer le pipeline sous la forme d’une chronologie de trace, montrant la durée et le statut de l’opération d’actualisation de chaque table dynamique, ainsi que les relations de dépendance codées dans les liens de span.