Snowpark Container Services : services de surveillance¶

Utilisation de SYSTEM$GET_SERVICE_LOGS¶

Vous fournissez le nom du service, l’ID d’instance, le nom du conteneur et, éventuellement, le nombre de lignes de journal les plus récentes à récupérer. Si une seule instance de service est en cours d’exécution, l’ID d’instance de service est 0. Par exemple, la commande d’instruction suivante récupère les 10 dernières lignes du journal d’un conteneur nommé echo qui appartient à l’instance 0 d’un service nommé echo_service :

SELECT SYSTEM$GET_SERVICE_LOGS('echo_service', '0', 'echo', 10);

Exemple de sortie :

+--------------------------------------------------------------------------+
| SYSTEM$GET_SERVICE_LOGS                                                  |
|--------------------------------------------------------------------------|
| 10.16.6.163 - - [11/Apr/2023 21:44:03] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:08] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:13] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:18] "GET /healthcheck HTTP/1.1" 200 - |
+--------------------------------------------------------------------------+
1 Row(s) produced. Time Elapsed: 0.878s

Si vous ne disposez pas des informations sur le service dont vous avez besoin pour appeler la fonction (comme l’ID d’instance ou le nom du conteneur), vous pouvez d’abord exécuter la commande SHOW SERVICE CONTAINERS IN SERVICE pour obtenir des informations sur les instances de service et les conteneurs exécutés dans chaque instance.

La fonction SYSTEM$GET_SERVICE_LOGS présente les limitations suivantes :

• Elle fusionne les flux de sortie standard et d’erreur standard. La fonction ne fournit aucune indication sur le flux d’où provient la sortie.

• Elle rapporte les données capturées pour un conteneur spécifique dans une instance de service unique.

• Elle ne signale que les journaux d’un conteneur en cours d’exécution. La fonction ne peut pas récupérer les journaux d’un conteneur précédent qui a été redémarré ou d’un conteneur d’un service qui est arrêté ou supprimé.

• La fonction renvoie jusqu’à 100 KB de données.

Utilisation d’une table d’événements¶

Snowflake peut capturer les journaux envoyés depuis les conteneurs vers les flux de sortie standard et d’erreur standard dans la table d’événements configurée pour votre compte. Pour plus d’informations sur la configuration d’une table d’événements, voir Journalisation, traçage et métriques.

Vous contrôlez quels flux sont collectés (tous, erreurs uniquement ou aucun) que vous souhaitez conserver dans une table d’événements en utilisant le champ spec.logExporters dans le fichier de spécification du service.

Vous pouvez ensuite interroger la table des événements pour connaître les événements. Par exemple, l’instruction SELECT suivante récupère les événements de services et de tâches Snowflake enregistrés au cours de l’heure écoulée :

SELECT TIMESTAMP, RESOURCE_ATTRIBUTES, RECORD_ATTRIBUTES, VALUE
FROM <current-event-table-for-your-account>
WHERE timestamp > dateadd(hour, -1, current_timestamp())
AND RESOURCE_ATTRIBUTES:"snow.service.name" = <service-name>
AND RECORD_TYPE = 'LOG'
ORDER BY timestamp DESC
LIMIT 10;

Snowflake recommande d’inclure un horodatage dans la clause WHERE des requêtes de tables d’événements, comme le montre cet exemple. Ceci est particulièrement important en raison du volume potentiel de données générées par les différents composants de Snowflake. En appliquant des filtres, vous pouvez extraire un sous-ensemble de données plus restreint, ce qui améliore les performances de la requête.

La table d’événements comprend les colonnes suivantes, qui fournissent des informations utiles sur les journaux collectés par Snowflake depuis votre conteneur :

• TIMESTAMP : indique quand Snowflake a collecté le journal.

• RESOURCE_ATTRIBUTES : fournit un objet JSON qui identifie le service Snowflake et le conteneur dans le service qui a généré le message de journal. Par exemple, il fournit des détails tels que le nom du service, le nom du conteneur et le nom du pool de calcul qui ont été spécifiés lors de l’exécution du service.

  {
    "snow.account.name": "SPCSDOCS1",
    "snow.compute_pool.id": 20,
    "snow.compute_pool.name": "TUTORIAL_COMPUTE_POOL",
    "snow.compute_pool.node.id": "a17e8157",
    "snow.compute_pool.node.instance_family": "CPU_X64_XS",
    "snow.database.id": 26,
    "snow.database.name": "TUTORIAL_DB",
    "snow.schema.id": 212,
    "snow.schema.name": "DATA_SCHEMA",
    "snow.service.container.instance": "0",
    "snow.service.container.name": "echo",
    "snow.service.container.run.id": "b30566",
     "snow.service.id": 114,
    "snow.service.name": "ECHO_SERVICE2",
    "snow.service.type": "Service"
  }
  

  Copy

• RECORD_ATTRIBUTES : pour un service Snowflake, il identifie une source d’erreur (sortie standard ou erreur standard).

  { "log.iostream": "stdout" }
  

  Copy

• VALUE : la sortie standard et l’erreur standard sont divisées en lignes, et chaque ligne génère un enregistrement dans la table d’événements.

  "echo-service [2023-10-23 17:52:27,429] [DEBUG] Sending response: {'data': [[0, 'Joe said hello!']]}"
  

Accès aux métriques du service de table d’événements¶

Pour enregistrer les métriques d’un service dans la table d’événements configurée pour votre compte, incluez la section suivante dans votre spécification de service :

platformMonitor:
  metricConfig:
    groups:
    - <group 1>
    - <group 2>
    - ...

Où chaque group N fait référence à un groupe de métriques prédéfinies qui vous intéresse (par exemple, system, network, ou storage). Pour plus d’informations, consultez la section spec.platformMonitor field dans la documentation sur la spécification du service.

Pendant que le service est en cours d’exécution, Snowflake enregistre ces métriques dans la table des événements de votre compte. Vous pouvez interroger votre table d’événements pour lire les métriques. La requête suivante récupère les métriques de service qui ont été enregistrées au cours de la dernière heure pour le service my_service :

SELECT timestamp, value
  FROM my_event_table_db.my_event_table_schema.my_event_table
  WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP())
    AND RESOURCE_ATTRIBUTES:"snow.service.name" = 'MY_SERVICE'
    AND RECORD_TYPE = 'METRIC'
    ORDER BY timestamp DESC
    LIMIT 10;

Si vous ne connaissez pas le nom de la table d’événements active pour le compte, exécutez la commande SHOW PARAMETERS pour afficher la valeur du paramètre EVENT_TABLE au niveau du compte :

SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

Pour plus d’informations sur les tables d’événements, voir Utilisation d’une table d’événements.

Exemple

Suivez ces étapes pour créer un exemple de service qui enregistre les métriques dans la table d’événements configurée pour votre compte.

1. Suivez le Tutoriel 1 pour créer un service nommé echo_service, avec un changement. À l’étape 3, quand vous créez un service, utilisez la commande CREATE SERVICE suivante qui ajoute le champ platformMonitor dans la spécification de service modifiée.

   CREATE SERVICE echo_service
     IN COMPUTE POOL tutorial_compute_pool
     FROM SPECIFICATION $$
       spec:
         containers:
         - name: echo
           image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest
           env:
             SERVER_PORT: 8000
             CHARACTER_NAME: Bob
           readinessProbe:
             port: 8000
             path: /healthcheck
         endpoints:
         - name: echoendpoint
           port: 8000
           public: true
         platformMonitor:
           metricConfig:
             groups:
             - system
             - system_limits
         $$
       MIN_INSTANCES=1
       MAX_INSTANCES=1;
   

   Copy

2. Une fois le service exécuté, Snowflake commence à enregistrer les métriques des groupes de métriques spécifiés dans la table des événements, que vous pouvez ensuite interroger. La requête suivante récupère les métriques signalées au cours de la dernière heure par le service Echo.

   SELECT timestamp, value
     ROM my_events
     WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP())
       AND RESOURCE_ATTRIBUTES:"snow.service.name" = 'ECHO_SERVICE'
       AND RECORD_TYPE = 'METRIC'
       ORDER BY timestamp, group DESC
       LIMIT 10;
   

   Copy

Accès aux métriques du pool de calcul¶

Les métriques du pool de calcul offrent des informations sur les nœuds du pool de calcul et les services qui y sont exécutés. Chaque nœud signale des métriques spécifiques au nœud, telles que la quantité de mémoire disponible pour les conteneurs, ainsi que des métriques de service, telles que l’utilisation de la mémoire par des conteneurs individuels. Les métriques du pool de calcul fournissent des informations du point de vue d’un nœud.

Chaque nœud dispose d’un éditeur de métriques qui écoute le port TCP 9001. D’autres services peuvent faire une requête HTTP GET avec le chemin /metrics vers le port 9001 sur le nœud. Pour découvrir l’adresse IP du nœud, récupérez les enregistrements SRV (ou enregistrements A) des DNS pour le nom d’hôte discover.monitor.compute_pool_name.snowflakecomputing.internal. Ensuite, créez un autre service dans votre compte qui interroge activement chaque nœud pour récupérer les métriques.

Le corps de la réponse fournit les métriques en utilisant le format Prometheus comme le montre l’exemple de métriques suivant :

# HELP node_memory_capacity Defines SPCS compute pool resource capacity on the node
# TYPE node_memory_capacity gauge
node_memory_capacity{snow_compute_pool_name="MY_POOL",snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"} 1
node_cpu_capacity{snow_compute_pool_name="MY_POOL",snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"} 7.21397383168e+09

Remarques :

• Chaque métrique commence par # HELP et # TYPE, pour fournir une brève description et le type de la métrique. Dans cet exemple, la métrique node_memory_capacity est de type gauge.

• Elle est ensuite suivie du nom de la métrique, d’une liste de libellés décrivant une ressource spécifique (point de données) et de sa valeur. Dans cet exemple, la métrique (nommée node_memory_capacity) fournit des informations sur la mémoire, indiquant que le nœud dispose de 7,2 GB de mémoire disponible. La métrique comprend également des métadonnées sous forme d’étiquettes, comme indiqué :

  snow_compute_pool_name="MY_POOL",
  snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"
  

Vous pouvez traiter ces métriques comme vous le souhaitez ; par exemple, vous pouvez stocker les métriques dans une base de données et utiliser une UI (comme un tableau de bord Grafrana) pour afficher les informations.

Pour obtenir la liste des métriques de pool de calcul disponibles, consultez Métriques de plateforme disponibles.

Exemple

Pour un exemple de configuration de Prometheus pour interroger votre pool de calcul pour les métriques, consultez les tutoriels sur les métriques du pool de calcul.

Métriques de plateforme disponibles¶

Vous trouverez ci-dessous une liste des groupes de métriques de plateforme disponibles et des métriques au sein de chaque groupe. Notez que les métriques de stockage nne sont actuellement collectées qu’à partir de volumes de stockage en blocs.