Alertes dans Snowsight¶
Vous pouvez configurer des alertes pour les fonctionnalités Snowflake dans Snowsight. Cette interface utilisateur simplifie la manière de surveiller votre compte Snowflake.
Plutôt que d’exécuter des instructions SQL pour créer et gérer les alertes, vous pouvez utiliser des assistants dans Snowsight pour créer, gérer et surveiller vos alertes.
La fonctionnalité de gestion des alertes dans Snowsight offre les avantages suivants :
Visibilité centralisée des alertes : dans le centre d’alertes Snowflake, vous pouvez voir toutes les alertes, l’historique de ces alertes et le statut d’exécution de ces alertes.
Modèles pour créer des alertes : vous pouvez rapidement créer des alertes pour les fonctionnalités suivantes en utilisant les modèles d’alerte fournis dans l’UI d’alertes Snowflake. Remarque : une fois qu’une alerte est générée à partir d’un modèle, elle est équivalente à toute autre alerte en ce qui concerne la gestion du cycle de vie, et ne contient pas de propriétés particulières
Surveillance proactive des fonctionnalités Snowflake : vous pouvez facilement configurer des notifications en cas de défaillances, de latence ou d’anomalies de données afin de garantir le bon fonctionnement de vos pipelines et de vos budgets.
Conditions préalables¶
Avant de pouvoir utiliser Snowsight pour créer, surveiller et gérer des alertes, vous devez remplir les conditions préalables suivantes :
Conditions préalables requises pour les alertes de tâches¶
Si vous prévoyez de créer, de gérer et de surveiller des alertes sur les tâches, vous devez procéder comme suit :
Définissez le niveau de gravité des messages enregistrés que vous souhaitez capturer pour les événements de tâche.
Les alertes des tâches surveillent les messages d’erreur qui sont connectés à la table des événements. Vous devez définir le paramètre LOG_LEVEL sur au moins
ERRORpour les tâches que vous souhaitez surveiller. Vous pouvez définir ce paramètre sur l’un des types d’objets suivants :Pour définir le niveau de gravité sur ERROR pour tous les objets du compte (y compris les tâches), exécutez ALTER ACCOUNT SET LOG_LEVEL :
Note
Ce paramètre concerne également les messages enregistrés par les UDFs, les procédures stockées et les tables dynamiques.
Pour définir le niveau de gravité sur ERROR pour tous les objets d’une base de données contenant les tâches, exécutez ALTER DATABASE … SET LOG_LEVEL :
Note
Ce paramètre concerne également les messages enregistrés par les UDFs, les procédures stockées et les tables dynamiques dans cette base de données.
Pour définir le niveau de gravité sur ERROR pour des tâches spécifiques, exécutez ALTER TASK … SET LOG_LEVEL :
Vérifiez les privilèges qui ont été accordés au rôle que vous prévoyez d’utiliser pour accéder à Snowsight.
Ce rôle doit se voir accorder les privilèges nécessaires pour interroger l’Vue TASK_HISTORY et l’Vue QUERY_HISTORY dans le schéma ACCOUNT_USAGE.
Pour plus d’informations, voir Permettre à d’autres rôles d’utiliser des schémas dans la base de données SNOWFLAKE.
Conditions préalables requises pour les alertes Openflow¶
Les alertes Openflow surveillent les événements enregistrés dans une table d’événements. Assurez-vous qu’Openflow est configuré pour enregistrer des événements. Pour plus d’informations, consultez les sections suivantes :
Configurer un tableau des événements pour enregistrer les événements Openflow (obligatoire) (si vous utilisez Openflow BYOC)
[Facultatif] Configurer un tableau des événements spécifique à Openflow (si vous utilisez Openflow Snowflake)
Conditions préalables requises pour les alertes sur la qualité des données¶
Assurez-vous que les fonctions de métrique des données (DMF) sont enregistrées et s’exécutent dans les tables et les vues que vous souhaitez surveiller.
Pour plus d’informations, voir Utiliser SQL pour configurer des fonctions de métrique des données.
Configuration des notifications pour les alertes¶
Lorsque vous créez une alerte dans Snowsight, vous pouvez configurer l’alerte pour envoyer une notification par e-mail ou par un webhook.
Pour envoyer des notifications, vous devez utiliser une intégration de notification. Vous pouvez utiliser une intégration de notification existante ou en créer une nouvelle :
Pour trouver les intégrations de notification existantes, exécutez SHOW NOTIFICATION INTEGRATIONS et utilisez un opérateur de canal pour filtrer les résultats :
Pour créer une nouvelle intégration de notifications par e-mail, voir Envoi de notifications par e-mail.
Pour créer une nouvelle intégration de notification webhook, voir CREATE NOTIFICATION INTEGRATION (webhooks).
Création d’un rôle pour l’accès aux alertes dans Snowsight¶
Pour permettre à des utilisateurs autres que l’administrateur du compte d’accéder aux alertes dans Snowsight, vous pouvez créer un rôle personnalisé auquel ont été accordés tous les privilèges nécessaires pour créer, gérer et surveiller des alertes. Vous pouvez attribuer ce rôle aux utilisateurs et à d’autres rôles qui doivent utiliser les alertes dans Snowsight.
Par exemple, supposons que vous souhaitiez créer un rôle nommé my_alert_center_role à cette fin. Pour créer ce rôle, procédez comme suit :
Basculer vers un rôle qui est autorisé à créer votre rôle personnalisé (par exemple, le rôle ACCOUNTADMIN) :
Créez votre rôle personnalisé :
Accordez le privilège USAGE sur un entrepôt que vous prévoyez d’utiliser pour accéder aux alertes dans Snowsight. Vous devez accorder ce privilège, car certaines des fonctionnalités nécessitent un entrepôt actif.
Accordez les privilèges d’exécution des alertes au rôle :
Si vous prévoyez de créer des alertes qui utilisent un entrepôt spécifique pour être exécutées, accordez les privilèges suivants à ce rôle :
Privilège EXECUTE ALERT sur le compte
Privilège USAGE sur l’entrepôt que vous souhaitez utiliser pour l’alerte
Par exemple :
Si vous prévoyez de créer une alerte sans serveur, accordez le privilège EXECUTE MANAGED ALERT sur le compte :
Accordez les privilèges requis pour créer des alertes dans une base de données et un schéma.
Par exemple, si vous prévoyez de créer les alertes dans une base de données nommée
my_alerts_databaseet dans un schéma nommémy_alert_schema, accordez le privilège USAGE sur cette base de données et ce schéma, et accordez le privilège CREATE ALERT sur le schéma :Accordez le privilège USAGE sur l’intégration de notifications par e-mail que vous avez configurée précédemment :
Accordez le rôle d’application qui autorise l’accès à la table d’événements par défaut :
Si vous prévoyez de configurer des alertes pour la surveillance de la qualité des données, accordez le rôle d’application et les privilèges nécessaires pour surveiller la qualité des données et exécuter des fonctions de métrique des données :
Accordez le rôle personnalisé à des utilisateurs ou à d’autres rôles :
Accès aux alertes dans Snowsight¶
Pour accéder aux alertes dans Snowsight :
Connectez-vous à Snowsight.
Dans le menu de navigation, sélectionnez Monitoring » Alerts.
Vous pouvez voir une liste des alertes existantes et filtrer les alertes par nom et par état. Vous pouvez également voir l’état des dernières exécutions d’alertes.
Création d’une nouvelle alerte¶
Vous pouvez créer une nouvelle alerte en utilisant l’un des modèles fournis. Pour créer une alerte, procédez comme suit :
Connectez-vous à Snowsight.
Dans le menu de navigation, sélectionnez Monitoring » Alerts, puis sélectionnez + Alert.
Dans le champ Name, saisissez un nom pour l’alerte.
Dans le champ Description, décrivez l’objectif de l’alerte.
Dans le menu Location, choisissez la base de données et le schéma dans lesquels vous souhaitez créer l’alerte.
Dans le menu Compute Type, choisissez l’une des options suivantes :
Pour créer une alerte sans serveur, choisissez Serverless.
Pour spécifier l’entrepôt que vous souhaitez utiliser pour l’alerte, choisissez Warehouse.
Si vous avez sélectionné cette option, choisissez l’entrepôt dans le menu Warehouse.
Si vous voulez activer l’alerte après sa création, sélectionnez Activate alert upon creation.
Si vous ne sélectionnez pas cette option, l’alerte nouvellement créée est suspendue. Vous devez réactiver l’alerte pour qu’elle soit opérationnelle.
Sélectionnez Next.
Dans le menu Select warehouse, choisissez l’entrepôt que vous souhaitez utiliser pour l’alerte.
Dans le menu Alert template, choisissez l’un des groupes de modèles pour les fonctionnalités Snowflake, puis choisissez le modèle que vous souhaitez utiliser pour créer l’alerte.
Le tableau suivant répertorie les groupes de modèles et les modèles que vous pouvez choisir.
Groupe de modèles
Modèle
Description
DATA_QUALITY
Anomaly detection alert
Surveille les anomalies détectées dans les métriques de qualité des données, et déclenche une alerte lorsque des tendances inhabituelles ou des valeurs aberrantes sont identifiées.
Expectation violations alert
Surveille les non-conformités aux critères de qualité des données, et déclenche une alerte lorsque les critères définis ne sont pas respectés.
OPENFLOW
High CPU alert
Surveille les pods d’exécution OpenFlow pour détecter une utilisation CPU élevée et prolongée (>90 %), ce qui peut indiquer une dégradation potentielle des performances.
Connector backpressure (object count)
Surveille le nombre d’éléments dans la file d’attente du connecteur afin de déterminer s’il dépasse le seuil de contre-pression, ce qui peut indiquer que le système en aval ne parvient pas à suivre le débit de données.
Connector backpressure (bytes)
Surveille le nombre d’octets en file d’attente du connecteur pour déterminer s’il dépasse le seuil de contre-pression, ce qui peut indiquer une pression sur la mémoire dans le pipeline de données.
High queued bytes alert
Surveille le nombre d’octets en file d’attente du connecteur pour déterminer s’il s’approche du seuil de contre-pression (> 80 %), ce qui peut fournir une alerte précoce avant que la contre-pression ne se produise.
High queued count alert
Surveille le nombre d’objets en file d’attente du connecteur afin de déterminer s’il s’approche du seuil de contre-pression (> 80 %), ce qui peut fournir une alerte précoce avant que la contre-pression ne se produise.
No data alert
Les moniteurs des connecteurs qui ont un temps de traitement actif, mais qui ne reçoivent ou n’envoient aucune donnée, ce qui peut indiquer d’éventuels problèmes de flux de données.
Runtime high error rate alert
Surveille les processeurs d’exécution Openflow pour détecter un volume élevé de journaux de niveau ERROR, ce qui peut indiquer des échecs de traitement.
Table replication failure alert
Surveille les transitions de réplication de table vers un état FAILED, ce qui peut indiquer des problèmes critiques de synchronisation des données.
TASKS
Error rate alert
Déclenche une alerte lorsque le taux d’erreur des tâches cumulé dépasse un seuil spécifié.
Remplissez les champs de configuration de l’alerte. Les champs dépendent du modèle que vous avez choisi.
Sélectionnez le champ d’application que vous souhaitez surveiller. Le champ d’application détermine les objets qui sont surveillés dans le cadre de l’alerte. Par exemple, pour surveiller tous les objets du compte, choisissez Account dans le menu Scope.
Dans le menu Schedule, choisissez le type de planification que vous souhaitez utiliser pour exécuter l’alerte :
Pour exécuter l’alerte uniquement lorsque de nouveaux objets sont ajoutés (par exemple, de nouvelles lignes insérées dans une table que vous surveillez), sélectionnez When new events are detected.
Pour exécuter l’alerte régulièrement et sélectionner la fréquence d’exécution de l’alerte (par exemple, toutes les 10 minutes), sélectionnez On a schedule.
Dans le menu Notification integration, choisissez l’intégration de notification créée précédemment. Vous pouvez utiliser une intégration d’e-mail ou une intégration de webhook.
Si vous avez sélectionné une intégration d’e-mail, dans le menu Email recipients, choisissez les adresses e-mail des personnes à notifier lorsque l’alerte est déclenchée.
Sélectionnez Create.
Note
L’assistant de modèles génère les instructions SQL pour la création de l’alerte. Si vous devez personnaliser davantage l’alerte, vous pouvez modifier directement ces instructions.
L’alerte n’est visible que si votre rôle actuel dispose du privilège MONITOR ou OWNERSHIP sur l’alerte.
Affichage des détails d’une alerte¶
Pour afficher les détails d’une alerte spécifique, sélectionnez la ligne de l’alerte dans la liste des alertes. Snowsight ouvre la page de détail de l’alerte, qui indique les informations suivantes :
Historique des exécutions récentes : Une table des exécutions récentes de l’alerte, comprenant le temps d’exécution, l’état (par exemple, Triggered ou Condition not met), la condition et l’action SQL exécutée, et les IDs de requêtes correspondantes. Vous pouvez filtrer par intervalle de temps et par état, et charger des exécutions supplémentaires.
Description : Le commentaire ou la description défini sur l’alerte.
Détails : Métadonnées sur l’alerte, comprenant le nom de l’alerte, son état (Démarrée ou Suspendue), le rôle de propriétaire, la base de données, le schéma, l’entrepôt et la planification.
Condition : L’instruction SQL qui représente la condition de l’alerte. Il s’agit du bloc
IF(EXISTS(...))de l’alerte.Action : L’instruction SQL que l’alerte exécute lorsque la condition est remplie. Il s’agit du bloc
THENde l’alerte.
Suivi des exécutions d’alertes¶
Dans le tableau de l’historique des exécutions récentes sur la page des détails de l’alerte, la colonne Status indique l’état de chaque exécution. Les états possibles sont les suivants :
Triggered : La condition a été évaluée comme TRUE et l’action a été exécutée.
Condition not met : La condition a été évaluée comme FALSE et aucune action n’a été exécutée.
Pour une liste complète des états possibles et de leur signification, voir la colonne STATE dans ALERT_HISTORY.
Pour enquêter sur un échec de l’exécution, vérifiez les colonnes Condition query ID et Action query ID. Vous pouvez utiliser ces IDs de requête pour rechercher les SQL_ERROR_CODE et SQL_ERROR_MESSAGE pour l’exécution dans ALERT_HISTORY, qui fournissent le code d’erreur spécifique et une description de ce qui s’est mal passé.
Modification d’une alerte¶
Pour modifier une alerte dans la page de détails de l’alerte, sélectionnez
dans le coin supérieur droit et choisissez Edit. Snowsight ouvre la boîte de dialogue d’édition avec deux onglets : General et Config.
Modification des propriétés générales des alertes¶
Dans l’onglet General, vous pouvez modifier les propriétés suivantes de l’alerte :
Nom : Le nom de l’alerte. Ce champ est en lecture seule pour les alertes existantes.
Commentaire : Une description de ce que l’alerte surveille. Correspond à la propriété COMMENT dans ALTER ALERT.
Type de calcul : Si l’alerte utilise un modèle de calcul sans serveur ou un entrepôt spécifié. Si vous choisissez Warehouse, sélectionnez l’entrepôt dans le menu Warehouse.
Planification : La fréquence d’exécution de l’alerte. Choisissez On a schedule et définissez la fréquence (par exemple, toutes les 30 minutes).
Sélectionnez Save pour appliquer les modifications.
Modifier la configuration d’une alerte¶
Dans l’onglet Config, vous pouvez modifier la configuration (CONFIG) de l’alerte. Lorsqu’une alerte est créée à partir d’un modèle, ce dernier définit une configuration qui contient les paramètres paramétrables de l’alerte (par exemple, les seuils, les destinataires des notifications et le périmètre de surveillance). La condition et l’action SQL de l’alerte lisent ces valeurs à l’environnement d’exécution via SYSTEM$GET_ALERT_CONFIG.
Modifier la configuration vous permet de modifier la logique métier de l’alerte sans modifier les instructions SQL sous-jacentes.
En fonction de la structure de la configuration, Snowsight affiche l’une des deux expériences d’édition.
Modification de la configuration d’un modèle¶
Si l’alerte a été créée à partir d’un modèle et que la configuration conserve la structure attendue par le modèle, Snowsight affiche un formulaire d’édition riche. Chaque champ de la configuration est affiché avec une étiquette lisible par l’utilisateur et une description des valeurs attendues. Les champs spécifiques dépendent du modèle, mais les exemples courants incluent :
Une valeur de seuil qui déclenche l’alerte (par exemple, un taux d’erreur compris entre 0,0 et 1,0).
Une méthode de notification telle que EMAIL ou WEBHOOK, avec des champs connexes pour l’intégration et les destinataires.
Un champ d’application qui contrôle les objets que l’alerte surveille (par exemple, ACCOUNT, DATABASE ou SCHEMA), avec des filtres facultatifs pour réduire encore le champ d’application.
Lorsque vous modifiez ces champs et que vous sélectionnez Save, Snowsight met à jour le CONFIG JSON sur l’alerte. La condition et l’action SQL de l’alerte utilisent alors les nouvelles valeurs la prochaine fois que l’alerte s’exécutera.
Modification d’une configuration clé-valeur plate¶
Si la configuration ne correspond pas à la structure attendue par le modèle (par exemple, si vous avez modifié le paramètre CONFIG via SQL et changé son schéma), Snowsight revient à un éditeur clé-valeur plat.
Dans cette vue, la configuration est affichée sous forme de liste de paires clé-valeur. Vous pouvez basculer entre deux modes :
Key-value : Modifier chaque paire clé-valeur individuellement.
JSON : Visualiser et modifier la configuration JSON brute directement.
Prudence
Les valeurs de configuration influencent les conditions et la logique d’action de l’alerte, mais il ne s’agit pas de paramètres gérés faisant l’objet d’un contrat détaillé avec Snowflake. CONFIG est une chaîne JSON que le code SQL de l’alerte lit lors de l’exécution, et c’est le code SQL du modèle qui se charge d’interpréter ces valeurs.
La modification des valeurs de configuration modifie le comportement d’exécution du code SQL de l’alerte. Des valeurs incorrectes (par exemple, une valeur non numérique pour un seuil ou une adresse e-mail non valide) peuvent entraîner un dysfonctionnement de l’alerte ou produire des résultats inattendus. Consulter la documentation du modèle ou le SQL de l’alerte avant de modifier les valeurs de configuration.
Pour plus d’informations sur la manière dont le paramètre CONFIG fonctionne au niveau de SQL, voir Transmission de la configuration à une alerte.