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. Pour trouver la table des événements actifs pour le compte, utilisez la commande SHOW PARAMETERS pour vérifier la valeur du paramètre EVENT_TABLE :

SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

Ce paramètre indique la table d’événements active pour le compte.

Effectuez ensuite une requête dans la table des événements. 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
     FROM my_events
     WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP())
       AND RESOURCE_ATTRIBUTES:"snow.service.name" = 'ECHO_SERVICE'
       AND RECORD_TYPE = 'METRIC'
       AND RECORD:metric.name = 'container.cpu.usage'
       ORDER BY timestamp DESC
       LIMIT 100;
   

   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.cp.spcs.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.

Publication des métriques et des traçages de l’application OTLP¶

Snowflake exécute un collecteur OTel que votre conteneur de service peut utiliser pour publier des métriques et des traçages de l’application OTLP. En d’autres termes, un conteneur de service peut envoyer des métriques aux points de terminaison du collecteur OTel, que Snowflake écrit ensuite dans la table d’événements configurée pour votre compte Snowflake, avec les détails du service d’origine.

Il fonctionne de la manière suivante :

• Snowflake remplit automatiquement les variables d’environnement suivantes dans votre conteneur de service qui fournissent les points de terminaison du collecteur OTel où les conteneurs peuvent publier des métriques et des traçages de l’application :

  • OTEL_EXPORTER_OTLP_METRICS_ENDPOINT

  • OTEL_EXPORTER_OTLP_TRACES_ENDPOINT

• Le client OTLP standard recherche ces variables d’environnement pour découvrir automatiquement le collecteur OTel. Cela permet à votre conteneur de service de publier des métriques et des traçages à l’aide de ce client.

from opentelemetry.sdk.trace import TracerProvider
from snowflake.telemetry.trace import SnowflakeTraceIdGenerator


trace_id_generator = SnowflakeTraceIdGenerator()
tracer_provider = TracerProvider(
    resource=Resource.create({"service.name": SERVICE_NAME}),
    id_generator=trace_id_generator
)

import io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk;
import com.snowflake.telemetry.trace.SnowflakeTraceIdGenerator;

static OpenTelemetry initOpenTelemetry() {
  return AutoConfiguredOpenTelemetrySdk.builder()
      .addPropertiesSupplier(
          () ->
              Map.of(...config options...)
      .addTracerProviderCustomizer(
          (tracerProviderBuilder, configProperties) -> {
            tracerProviderBuilder.setIdGenerator(SnowflakeTraceIdGenerator.INSTANCE);
            return tracerProviderBuilder;
          })
      .build()
      .getOpenTelemetrySdk();

Publication des métriques de l’application Prometheus¶

Snowflake prend les métriques Prometheus où, au lieu de pousser les métriques OTLP, votre application peut exposer les métriques Prometheus pour être interrogée par un collecteur fourni par Snowflake. Pour que Snowflake collecte ces métriques d’application à partir de votre service et les publie dans la table des événements, procédez comme suit :

• Demandez à votre service d’écouter sur un port, qui expose vos métriques Prometheus.

• Incluez dans votre service un conteneur fourni par Snowflake (également appelé conteneur « sidecar »), avec la configuration nécessaire pour extraire les métriques de votre conteneur de service.

Le conteneur « sidecar » Prometheus extrait les métriques de l’application du conteneur à une fréquence planifiée, convertit le format Prometheus au format OTLP et envoie les métriques au collecteur OTel. Le collecteur OTel publie ensuite ces métriques dans la table d’événements configurée pour votre compte Snowflake.

Vous ajoutez le conteneur « sidecar » Prometheus à la spécification de service en tant qu’autre conteneur et vous incluez un argument pour spécifier le point de terminaison HTTP exposé par votre conteneur, en utilisant le format suivant :

localhost:{PORT}/{METRICS_PATH}, {SCRAPE_FREQUENCY}

Il spécifie un numéro de port, un chemin et la fréquence à laquelle le conteneur « sidecar » doit extraire les métriques.

Un exemple de fragment de spécification de service montre que le conteneur « sidecar » rejette, toutes les minutes, des métriques de votre conteneur de service à partir du port 8000 et extrait des métriques du chemin « /metrics » :

spec:
  containers:
  - name: <name>
    image: <image-name>
    .....
  - name: prometheus
    image: /snowflake/images/snowflake_images/monitoring-prometheus-sidecar:0.0.1
    args:
      - "-e"
      - "localhost:8000/metrics,1m"

Dans la spécification :

• image est l’image du conteneur « sidecar » fourni par Snowflake.

• args fournit la configuration nécessaire pour que le conteneur prometheus puisse récupérer les métriques :

  • À partir du port 8000 fourni par votre conteneur. Le port est exigé dans cette configuration de conteneur prometheus.

  • Utilisation du chemin « /metrics ». Facultatif. Si non spécifié, « /metrics » est le chemin par défaut.

  • Chaque minute. Facultatif. Si non spécifiée, la valeur par défaut est « 1m ».

  Si vous utilisez les valeurs par défaut, il s’agit de la configuration équivalente pour la récupération des métriques :

  spec:
      ...
      args:
        - "-e"
        - "localhost:8000"
  

  Copy

Accès aux métriques et aux traçages de l’application dans la table des événements¶

Vous pouvez demander à la table d’événements de récupérer les métriques de l’application. La requête suivante permet de récupérer les métriques de l’application collectées au cours de l’heure écoulée.

SELECT timestamp, record:metric.name, value
  FROM <current_event_table_for_your_account>
  WHERE timestamp > dateadd(hour, -1, CURRENT_TIMESTAMP())
    AND resource_attributes:"snow.service.name" = <service_name>
    AND scope:"name" != 'snow.spcs.platform'
    AND record_type = 'METRIC'
  ORDER BY timestamp DESC
  LIMIT 10;

Pour plus d’informations sur les tables d’événements, voir Aperçu de la table d’événements. Vous pouvez visualiser ces métriques dans les tableaux de bord Snowflake.

Vous pouvez également interroger votre table d’événements pour afficher les traçages de l’application. Par exemple, pour récupérer les traçages d’application de l’heure écoulée, dans la requête précédente, remplacez la condition record_type comme suit :

AND record_type = 'SPAN' OR record_type = 'SPAN_EVENT'

Les traçages peuvent être visualisés dans la visionneuse Snowflake Trail.

Les métriques et les traçages contiennent à la fois des attributs définis par l’utilisateur et des attributs définis par Snowflake en tant que ressources et attributs d’enregistrement. Notez que le préfixe snow. est réservé aux attributs générés par Snowflake. Snowflake ignore les attributs personnalisés qui utilisent ce préfixe. Pour consulter la liste des attributs définis par Snowflake, voir Métriques de plateforme disponibles.

L’exemple de code est fourni à la fois en Python et en Java pour illustrer l’instrumentation d’une application avec des métriques et des traçages personnalisés à l’aide du SDK OTLP. Les exemples montrent comment configurer la génération d’ID de traçage Snowflake pour qu’elle soit compatible avec la visionneuse de traçage Snowflake Trail.