Snowpark Container Services : services de surveillance¶

Utilisation de la fonction <service-name>!SPCS_GET_LOGS¶

La fonction de table <service_name>!SPCS_GET_LOGS renvoie les journaux des conteneurs de la tâche spécifiée. Ces journaux sont collectés par Snowflake et sont stockés dans le tableau des événements.

La liste suivante explique les avantages de l’utilisation de cette fonction de table :

• Vous pouvez récupérer les journaux d’un service spécifique.

• Vous pouvez récupérer les journaux dans un intervalle de temps spécifié.

• L’appelant n’a pas besoin d’accéder à l’ensemble du tableau des événements, ce qui peut être bénéfique pour les clients ayant des exigences strictes en matière de sécurité de l’information. Si la session en cours inclut le rôle de propriétaire du service, ce dernier a accès à ces journaux.

Pour service_name, vous indiquez le nom du service. La fonction renvoie les journaux Snowflake collectés à partir des conteneurs de ce service (voir Accéder aux journaux des conteneurs).

Vous pouvez également spécifier une plage de dates. Par défaut, la fonction renvoie des journaux d’une journée. Par exemple, la requête récupérait les journaux que Snowflake collectait dans les conteneurs de la tâche``my_test_job`` au cours de la journée écoulée, qui est la valeur par défaut.

SELECT * FROM TABLE(my_test_job!SPCS_GET_LOGS());

Copy

Exemple de sortie :

+-------------------------+-------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+
| TIMESTAMP               | INSTANCE_ID | CONTAINER_NAME | LOG                                                                                                                                                                 | RECORD_ATTRIBUTES          |
|-------------------------+-------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------|
| 2025-06-26 00:23:40.281 |           0 | main           | job-tutorial - INFO - Job finished                                                                                                                                  | {                          |
|                         |             |                |                                                                                                                                                                     |   "log.iostream": "stdout" |
|                         |             |                |                                                                                                                                                                     | }                          |
| 2025-06-26 00:23:38.787 |           0 | main           | job-tutorial - INFO - Executing query [select current_time() as time,'hello'] and writing result to table [results]                                                 | {                          |
|                         |             |                |                                                                                                                                                                     |   "log.iostream": "stdout" |
|                         |             |                |                                                                                                                                                                     | }                          |
| 2025-06-26 00:23:38.787 |           0 | main           | job-tutorial - INFO - Connection succeeded. Current session context: database="TUTORIAL_DB", schema="DATA_SCHEMA", warehouse="TUTORIAL_WAREHOUSE", role="TEST_ROLE" | {                          |
|                         |             |                |                                                                                                                                                                     |   "log.iostream": "stdout" |
|                         |             |                |                                                                                                                                                                     | }                          |
| 2025-06-26 00:23:36.852 |           0 | main           | job-tutorial - INFO - Job started                                                                                                                                   | {                          |
|                         |             |                |                                                                                                                                                                     |   "log.iostream": "stdout" |
|                         |             |                |                                                                                                                                                                     | }                          |
+-------------------------+-------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+

Pour plus d’informations sur l’appel de cette méthode, voir <service_name>!SPCS_GET_LOGS.

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!']]}"
  

Utilisation de SYSTEM$GET_SERVICE_LOGS¶

La fonction SYSTEM$GET_SERVICE_LOGS renvoie les journaux du conteneur de service en cours d’exécution. Après la sortie d’un conteneur, vous pouvez continuer à accéder aux journaux à l’aide de la fonction système pendant une courte période. Les fonctions du système sont surtout utiles pendant le développement et les tests, lorsque vous créez un service ou une tâche.

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.

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 lire ces métriques de la manière suivante :

• Utilisation de la méthode d’aide du service : La fonction de table <service_name>!SPCS_GET_METRICS renvoie les métriques collectées par Snowflake pour le service spécifié. La liste suivante explique les avantages de l’utilisation de cette fonction de table :

  • Vous pouvez récupérer les métriques d’un service spécifique.

  • Vous pouvez récupérer des métriques dans un intervalle de temps spécifié.

  • L’appelant n’a pas besoin d’accéder à l’ensemble du tableau des événements, ce qui peut être bénéfique pour les clients ayant des exigences strictes en matière de sécurité de l’information.

  L’instruction suivante SELECT utilise la fonction de table pour récupérer les événements de la plateforme pour le service spécifié qui a été enregistré au cours de la dernière heure :

  SELECT *
    FROM TABLE(echo_service!SPCS_GET_METRICS(start_time => dateadd('hour', -1, current_timestamp())));
  

  Copy

• Interroger directement le tableau des événements : vous pouvez interroger votre tableau des é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;
  

  Copy

  Si vous ne connaissez pas le nom du tableau des événements actif 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;
  

  Copy

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

Exemple

Pour créer un exemple de service qui enregistre les métriques dans la tableau des événements configuré pour votre compte, procédez comme suit.

1. Créer un service nommé echo_service en suivant les étapes dans le Tutoriel 1, 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

Une fois le service exécuté, Snowflake commence à enregistrer les métriques des groupes de métriques spécifiés dans le tableau des événements, que vous pouvez ensuite interroger.

1. Accédez aux métriques en appelant la fonction <service_name>!SPCS_GET_METRICS ou en interrogeant le tableau des événements. Par exemple, récupérez les métriques signalées au cours de la dernière heure par le service echo_service :

   • Utiliser la fonction d’aide <service_name>!SPCS_GET_METRICS :

     Copy

     SELECT * FROM TABLE(echo_service!SPCS_GET_METRICS(START_TIME => DATEADD(“hour”, -1, CURRENT_TIMESTAMP())));

   • Interroger directement le tableau des événements :

     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éder 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.

Interroger les événements de plateforme¶

Après avoir configuré le niveau de journalisation de votre ressource, Snowflake enregistre les événements de plateforme dans le tableau des événements actif de votre compte Snowflake. Vous pouvez accéder à ces événements des manières suivantes :

• Utilisation de la méthode d’aide du service : La fonction de table <service_name>!SPCS_GET_EVENTS renvoie les événements collectés par Snowflake à partir des conteneurs du service spécifié.

  La liste suivante explique les avantages de l’utilisation de cette fonction de table :

  • Vous pouvez récupérer les événements d’un service spécifique.

  • Vous pouvez récupérer des événements dans un intervalle de temps spécifié.

  • L’appelant n’a pas besoin d’accéder à l’ensemble du tableau des événements, ce qui peut être bénéfique pour les clients ayant des exigences strictes en matière de sécurité de l’information.

  L’instruction suivante SELECT utilise la fonction de table pour récupérer les événements de la plateforme pour le service spécifié enregistré au cours de la dernière heure :

  SELECT *
  FROM TABLE(echo_service!SPCS_GET_EVENTS(START_TIME => DATEADD('hour', -1, CURRENT_TIMESTAMP())));
  

  Copy

• Utilisation directe du tableau des événements : vous pouvez interroger directement le tableau des é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;
  

  Copy

  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 extrait les événements de plateforme pour le service spécifié qui a été enregistré au cours de la dernière heure :

  SELECT TIMESTAMP, RESOURCE_ATTRIBUTES, RECORD, VALUE
    FROM <your_event_table>
    WHERE TIMESTAMP > DATEADD(hour, -1, CURRENT_TIMESTAMP())
      AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<your_service_name>'
      AND RECORD_TYPE = 'EVENT'
      AND SCOPE:"name" = 'snow.spcs.platform'
    ORDER BY TIMESTAMP DESC
    LIMIT 10;
  

  Copy

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

  Les colonnes suivantes du tableau des événements fournissent des informations utiles sur les événements de plateforme :

  • TIMESTAMP: indique quand l’événement a été enregistré.

  • RESOURCE_ATTRIBUTES: fournit un objet JSON contenant des métadonnées sur la source de l’événement, tel qu’un service, un conteneur ou un pool de calcul. L’exemple suivant d’une valeur dans la colonne resource_attribute identifie un service spécifique pour lequel l’événement est enregistré

    {
      "snow.compute_pool.name": "TUTORIAL_COMPUTE_POOL",
      "snow.compute_pool.id": 123,
      "snow.database.name": "TUTORIAL_DB",
      "snow.database.id": 456,
      "snow.schema.name": "DATA_SCHEMA",
      "snow.schema.id": 789,
      "snow.service.container.name": "echo",
      "snow.service.name": "ECHO_SERVICE2",
      "snow.service.id": 212,
      "snow.service.type": "Service"
    }
    

    Copy

  • SCOPE: indique l’origine de l’événement. Pour les événements de plateforme, le nom de la portée est snow.spcs.platform, comme le montre l’exemple suivant :

    { "name": "snow.spcs.platform" }
    

    Copy

  • RECORD_TYPE : pour les événements de plateforme, EVENT est le RECORD_TYPE.

  • RECORD : fournit des métadonnées sur l’événement spécifique. Les métadonnées suivantes indiquent le nom et le niveau de gravité de l’événement de plateforme :

    { "name": "CONTAINER.STATUS_CHANGE", "severity_text": "INFO" }
    

    Copy

  • VALUE : fournit les détails de l’événement. L’exemple suivant montre l’état et un message sur l’état du conteneur :

    { "message": "Running", "status": "READY" }
    

    Copy

Événements pris en charge¶

Actuellement, Snowflake ne prend en charge que les événements de changement d’état des conteneurs.

Le tableau suivant répertorie les événements de plateforme que Snowflake enregistre. RECORD et VALUE dans les noms des colonnes font référence aux colonnes du tableau des événements (expliqué dans la section précédente).