L’observabilité dans les applications Snowflake¶

Types de données télémétriques¶

Pour que les données télémétriques que vous collectez soient largement utiles, la télémétrie Snowflake est conçue sur le cadre standard OpenTelemetry (parfois appelé OTel), un projet incubateur de la Cloud Native Compute Foundation. Grâce à ce cadre (et aux APIs et outils conçus pour lui), vous pouvez réutiliser les données collectées avec des outils autres que Snowflake. Grâce à OpenTelemetry, vous pouvez instrumenter le code de l’application pour ajouter de l’observabilité là où vous le souhaitez.

Les tables d’événements de Snowflake collectent les données de journal, de plage et de métrique dans le modèle de données OpenTelemetry. Les paragraphes suivants décrivent chaque type de données télémétriques collectées dans une table d’événements.

Journaux	Les journaux enregistrent les opérations individuelles effectuées par le code. Chaque message de journal est généré à un moment précis de l’exécution du code. Instrumenter le code Vous pouvez connecter votre code à l’aide de bibliothèques standard pour la langue que vous utilisez, comme listé dans Journalisation à partir du code du gestionnaire. Visualisation des données Vous pouvez visualiser les messages du journal à des fins d’analyse, soit en effectuant une requête dans la table des événements, soit en regardant les visualisations fournies dans Snowsight. L’image suivante, tirée de Snowsight, montre la liste des messages de journaux pour une période de deux heures dans une seule base de données.
Métriques	Les métriques sont des mesures calculées sur une période donnée. Ces valeurs comprennent les mesures de CPU et de mémoire. Instrumenter le code Snowflake émet des données de métriques automatiquement au fur et à mesure de l’exécution de votre code, vous n’avez donc pas besoin d’instrumenter votre code. Visualisation des données Vous pouvez visualiser les données des métriques pour les analyser, soit en effectuant une requête dans la table des événements, soit en regardant les visualisations fournies dans Snowsight. L’image suivante, tirée de Snowsight, montre les changements dans les données métriques collectées pour l’exécution d’une fonction définie par l’utilisateur.
Traces	Les traces montrent les événements distribués au fur et à mesure que les données circulent dans un système. Dans une trace, vous pouvez voir où le temps est passé lorsque le traitement passe d’un composant à l’autre. Vous pouvez émettre des événements de traçage - à l’intérieur de la plage par défaut créée par Snowflake ou à partir d’une plage personnalisée que vous créez - en utilisant les bibliothèques standard de la langue que vous utilisez, telles qu’elles sont répertoriées dans Journalisation à partir du code du gestionnaire. Instrumenter le code Vous pouvez émettre des événements de traçage de votre code à l’aide de bibliothèques standard pour la langue que vous utilisez, comme listé dans Traçage des événements à partir du code du gestionnaire. Visualisation des données Vous pouvez visualiser les événements de traçage à des fins d’analyse, soit en effectuant une requête dans la table des événements, soit en regardant les visualisations fournies dans Snowsight. L’image suivante, tirée de Snowsight, montre les plages résultant de l’exécution d’un UDF.

Configurer votre environnement pour capturer les données de télémétrie avant d’en avoir besoin¶

Vous ne pouvez pas analyser des données que vous n’avez pas collectées. Il est donc préférable de commencer à collecter des données de télémétrie afin de les avoir à portée de main lorsque vous en avez besoin. Au fur et à mesure que votre déploiement se développe, votre besoin de comprendre les performances de votre code s’accroît.

Utilisez les meilleures pratiques suivantes :

• Activez la collecte des données de télémétrie pour votre environnement Snowflake.

  Pour collecter les données dont vous aurez besoin, veillez à disposer d’une table d’événements active.

• Pour vous assurer que vous recueillez les données de télémétrie que vous souhaitez, , définissez les niveaux de télémétrie sur des seuils utiles.

  Dans un premier temps, vous devrez définir ces paramètres afin de vous assurer que vous collectez bien des données. Par exemple, définissez un niveau de journalisation d’au moins WARN pour tout travail de production ou critique pour l’entreprise. Au fil du temps, vous pourrez ajuster ces niveaux en fonction de l’évolution de vos besoins.

  Organisez vos procédures stockées de production, les UDFs et d’autres objets sous une base de données ou un schéma afin de pouvoir simplement activer les journaux d’avertissement pour cette base de données ou ce schéma. Cela évite de devoir gérer des paramètres pour des objets distincts.

• Pour générer des données à des fins de dépannage, ajoutez les instructions de journalisation ou les événements de traçage à vos travaux de production.

  Lorsque vous utilisez les bibliothèques de journalisation standard telles que les bibliothèques de journalisation SLF4J de Java ou de Python, Snowflake route automatiquement les jounruax provenant de ces paquets vers votre table d’événements.

  Pour le traçage, vous pouvez utiliser les bibliothèques de télémétrie fournies avec Snowflake.

• Pour inclure dans les données de suivi des parties du traitement du gestionnaire que vous souhaitez mesurer, ajoutez custom spans au code du gestionnaire de votre procédure stockée.

  En plus des plages intégrées des objets Snowflake, Snowflake représente les plages personnalisées que vous créez dans le diagramme de traçage. Avec les plages personnalisées, vous pouvez capturer des données sur des parties arbitraires du traitement de votre code pour voir combien de temps ces parties prennent à s’exécuter. Vous pouvez également joindre des métadonnées arbitraires aux portées personnalisées afin d’ajouter des descriptions aux données à des fins de dépannage et d’optimisation.

Optimiser les procédures grâce à la télémétrie des requêtes¶

Dans le diagramme de traçage de la télémétrie des requêtes, vous trouverez des données sur toutes les plagess émises par une requête.

• L’axe horizontal indique la durée. Une plage qui apparaît plus longue horizontalement a pris plus de temps pour finir qu’une plage plus courte.

• L’axe vertical affiche la hiérarchie des appels. Dans cette hiérarchie, toute plage située directement sous une autre plage est un « enfant » de la plage « parent » située au-dessus.

Vous pouvez utiliser ce diagramme pour trouver des possibilités d’optimisation dans les procédures stockées. En utilisant ce que vous voyez dans le diagramme comme point de départ, vous pouvez prendre des mesures pour optimiser votre code.

Par exemple, vous pouvez organiser des opérations séquentielles pour qu’elles s’exécutent en parallèle à l’aide de bibliothèques telles que joblib. Joblib est un ensemble d’outils permettant d’ajouter des paramètres au code Python. Grâce à lui, vous pouvez plus facilement écrire du code parallèle.

Cache des opérations DataFrame redondantes¶

Lorsqu’une chaîne d’opérations DataFrame est utilisée plusieurs fois, elle apparaît dans le diagramme de traçage sous la forme d’une plage pour chaque action DataFrame. En fonction de la complexité de la requête, ce délai peut être assez long.

Par exemple, dans le code ci-dessous, la même chaîne DataFrame est appelée dans plusieurs contextes :

count = session.table(...).select().filter().join().count()

if count > 0:
  session.table(...).select().filter().join().write.save_as_table(...) # same query as the count, this will execute again
else:
  session.table(...).select().filter('other criteria').join() # nearly same query as the count

L’utilisation de la mise en cache améliore les performances en mettant en cache les DataFrame intermédiaires sous forme de table temporaire, ce qui réduit les requêtes redondantes :

cached_df = session.table(...).select().filter().join().cache_result()
count = df.count()

if count > 0:
  cached_df.write.save_as_table() # reuses the cached DF
else:
  cached_df

Gérer la quantité de données télémétriques reçues pour les UDFs¶

Lorsque vous ajoutez du code pour collecter des données de télémétrie avec des UDFs, n’oubliez pas que le modèle d’exécution UDF peut signifier beaucoup plus de lignes dans la table des événements que pour une procédure.

Lorsqu’une UDF est appelée sur chaque ligne d’entrée, le code de votre gestionnaire émet des instructions de connexion ou des événements de plage pour chaque ligne du jeu de données d’entrée. Par exemple, un jeu de données de 10 millions de lignes transmis à une UDF produirait 10 millions d’entrées de journal.

Pensez à utiliser les modèles suivants lorsque vous ajoutez des journaux et des événements de plage aux UDFs :

• Dans un premier temps, utilisez les niveaux de journalisation conçus pour réduire le nombre d’enregistrements.

  Utilisez les instructions de niveau de journalisation DEBUG- ou INFO et définissez le niveau de journalisation sur WARN en production. Si un problème est détecté, vous pouvez réduire le niveau de journalisation sur DEBUG ou INFO pour la durée de la session de débogage.

• Utilisez des blocs try/catch pour isoler le code à partir duquel vous souhaitez émettre des données de journalisation.

  L’utilisation de try/catch peut s’avérer utile pour détecter toute entrée UDF inattendue, la consigner en tant que journal de niveau WARN à des fins de sensibilisation, et renvoyer une valeur par défaut.

• Utilisez des instructions conditionnelles pour ne connecter que les scénarios qui vous intéressent.

  Avec des instructions if/else ou d’autres contraintes, vous pouvez contrôler le volume de la sortie de la journalisation.

Optimiser les fonctions définies par l’utilisateur grâce à la télémétrie des requêtes¶

Lorsqu’une UDF est appelée, Snowflake l’exécute en parallèle en créant une instance du code du gestionnaire pour chaque ligne d’entrée. Chacune de ces instances est représentée par sa propre plage dans un diagramme de traçage.

Vous pouvez utiliser ces intervalles pour dépanner les requêtes lentes et trouver des possibilités d’améliorer les performances. Par exemple, vous pouvez rencontrer des scénarios tels que le suivant :

• Une ou plusieurs instances de votre code UDF peuvent recevoir une ligne contenant des données nettement plus volumineuses ou différentes du reste de vos données. Dans ce cas, l’instance peut prendre beaucoup plus de temps pour se terminer, et sa durée est donc beaucoup plus longue.

• En fonction de la partition des entrées de votre requête et des clauses précédentes, une minorité d’instances peut recevoir une quantité importante de données en entrée.

L’image suivante montre une plage pour chaque ligne transmise à une UDF, où la durée plus longue d’une plage suggère que la ligne pourrait contenir des données plus importantes que les autres.

Meilleures pratiques en matière d’alertes et de notifications¶

Utilisez les pratiques suivantes pour améliorer l’observabilité en affinant et en augmentant la quantité d’informations que vous recevez du système.

• Évitez de dupliquer l’évaluation des événements.

  Vous pouvez éviter de dupliquer l’évaluation des événements en tenant compte du temps de latence entre la planification de l’alerte et son exécution. Pour ce faire, spécifiez les horodatages d’alerte en utilisant SCHEDULED_TIME et LAST_SUCCESSFUL_SCHEDULED_TIME au lieu de CURRENT_TIMESTAMP.

  Pour plus d’informations, voir Spécification des horodatages basés sur les planifications d’alerte.

• Enrichissez une action d’alerte ou une notification avec des résultats de la requête.

  Vous pouvez vérifier les résultats de l’instruction SQL spécifiée par une condition d’alerte. Pour obtenir les résultats de la requête, procédez comme suit :

  1. Récupérez l’ID de la requête pour l’instruction SQL de la condition d’alerte en appelant GET_CONDITION_QUERY_UUID.

  2. Transmettez l’ID de la requête à RESULT_SCAN pour obtenir les résultats de la requête.

• Enregistrez un résultat ou prenez une action automatisée en plus de l’envoi d’une notification.

  Vous pouvez spécifier qu’une action d’alerte exécute une tâche ou connecte une nouvelle ligne à une table chaque fois qu’une condition d’alerte est remplie. Par exemple, vous pouvez procéder ainsi si vous voulez entreprendre une action dans Snowflake chaque fois que la condition d’alerte est remplie.

  Si vous avez l’intention d’effectuer une action complexe après qu’une condition est remplie, assurez-vous que votre entrepôt a une taille appropriée.