Snowpark Container Services: Serviços de monitoramento¶

Como usar a função <service-name>!SPCS_GET_LOGS¶

a função de tabela <service_name>!SPCS_GET_LOGS retorna logs dos contêineres do trabalho especificado. Esses logs são coletados pelo Snowflake e são armazenados na tabela de eventos.

A lista a seguir explica as vantagens de usar esta função de tabela:

• Você pode recuperar os logs de um serviço específico.

• Você pode recuperar os logs dentro de um intervalo de tempo especificado.

• O chamador não precisa de acesso a toda a tabela de eventos, o que pode ser útil para clientes com requisitos rigorosos de segurança da informação. Se a sessão atual incluir a função de proprietário do serviço, ela terá acesso a esses logs.

Para service_name, você especifica o nome do serviço. A função retorna logs que o Snowflake coletou de contêineres desse serviço (consulte Acessar logs de contêiner).

Opcionalmente, você pode especificar um intervalo de datas. Por padrão, a função retorna logs de um dia. Por exemplo, a consulta recuperou os logs que o Snowflake coletou de contêineres do trabalho my_test_job no último dia, que é o padrão.

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

Copy

Exemplo de saída:

+-------------------------+-------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+
| 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" |
|                         |             |                |                                                                                                                                                                     | }                          |
+-------------------------+-------------+----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+

Para obter mais informações sobre como chamar este método, consulte <service_name>!SPCS_GET_LOGS.

Como usar tabela de evento¶

O Snowflake pode capturar logs enviados de contêineres para a saída padrão e fluxos de erro padrão na tabela de evento configurada para sua conta. Para obter mais informações sobre como configurar uma tabela de evento, consulte Registro, rastreamento e métricas.

Você controla quais fluxos são coletados (todos, somente erro padrão ou nenhum) para armazenar em uma tabela de evento, usando o campo spec.logExporters no arquivo de especificação de serviço.

É possível então consultar a tabela de evento para ver os eventos. Para localizar a tabela de eventos ativos da conta, use o comando SHOW PARAMETERS para verificar o valor do parâmetro EVENT_TABLE:

SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

O parâmetro especifica a tabela de eventos ativa para a conta.

Em seguida, consulte essa tabela de eventos. O seguinte comando SELECT recupera os eventos de serviço e trabalho do Snowflake registrados na última hora:

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 recomenda incluir um carimbo de data/hora na cláusula WHERE das consultas da tabela de eventos, conforme mostrado neste exemplo. Isso é especialmente importante devido ao volume potencial de dados gerados por vários componentes do Snowflake. Ao aplicar filtros, você pode recuperar um subconjunto menor de dados, o que melhora o desempenho da consulta.

A tabela de evento inclui as seguintes colunas, que fornecem informações úteis sobre os logs coletados pelo Snowflake de seu contêiner:

• TIMESTAMP: mostra quando o Snowflake coletou o log.

• RESOURCE_ATTRIBUTES: Fornece um objeto JSON que identifica o serviço Snowflake e o contêiner no serviço que gerou a mensagem de log. Por exemplo, ele fornece detalhes como o nome do serviço, o nome do contêiner e o nome do pool de computação que foram especificados quando o serviço foi executado.

  {
    "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: para um serviço Snowflake, ele identifica uma origem de erro (saída padrão ou erro padrão).

  { "log.iostream": "stdout" }
  

  Copy

• VALUE: a saída padrão e o erro padrão são divididos em linhas e cada linha gera um registro na tabela de eventos.

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

Como usar SYSTEM$GET_SERVICE_LOGS¶

A função SYSTEM$GET_SERVICE_LOGS retorna logs do contêiner de serviço atualmente em execução. Após a saída de um contêiner, você poderá continuar acessando os logs usando a função do sistema por um curto período. As funções do sistema são mais úteis durante o desenvolvimento e o teste, quando você está inicialmente criando um serviço ou um trabalho.

Forneça o nome do serviço, a ID da instância, o nome do contêiner e, opcionalmente, o número de linhas de log mais recentes a serem recuperadas. Se apenas uma instância de serviço estiver em execução, a ID da instância de serviço será 0. Por exemplo, o comando de instrução a seguir recupera as 10 linhas finais do log de um contêiner nomeado echo que pertence à instância 0 de um serviço chamado echo_service:

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

Exemplo de saída:

+--------------------------------------------------------------------------+
| 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

Se você não tiver as informações sobre o serviço necessárias para chamar a função (como o ID da instância ou nome do contêiner), é possível primeiro executar o comando SHOW SERVICE CONTAINERS IN SERVICE para obter informações sobre as instâncias do serviço e os contêineres em execução em cada instância.

A função SYSTEM$GET_SERVICE_LOGS tem as seguintes limitações:

• Ele realiza a fusão dos fluxos de saída padrão e de erro padrão. A função não indica de qual fluxo a saída veio.

• Ele relata os dados capturados para um contêiner específico em uma única instância de serviço.

• Ele relata apenas logs de um contêiner em execução. A função não pode buscar logs de um contêiner anterior que foi reiniciado ou de um contêiner de um serviço que foi interrompido ou excluído.

• A função retorna até 100 KB de dados.

Acesso a métricas de serviço de tabela de evento¶

Para registrar as métricas de um serviço na tabela de evento configurada para sua conta, inclua a seguinte seção na especificação do serviço:

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

Onde cada group N se refere a um grupo de métricas predefinido no qual você está interessado (por exemplo, system, network ou storage). Para obter mais informações, consulte a seção do campo spec.platformMonitor na documentação sobre a especificação do serviço.

Enquanto o serviço estiver em execução, o Snowflake registra essas métricas na tabela de evento de sua conta. Você pode ler essas métricas das seguintes maneiras:

• Usando o método auxiliar de serviço: a função de tabela <service_name>!SPCS_GET_METRICS retorna métricas coletadas pelo Snowflake para o serviço especificado. A lista a seguir explica as vantagens de usar esta função de tabela:

  • É possível recuperar métricas para um serviço específico.

  • Você pode recuperar métricas dentro de um intervalo de tempo especificado.

  • O autor da chamada não precisa de acesso a toda a tabela de eventos, o que pode ser útil para clientes com requisitos rigorosos de segurança da informação.

  A instrução SELECT a seguir usa a função de tabela para recuperar eventos de plataforma para o serviço especificado que foi registrado na última hora:

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

  Copy

• Consultar a tabela de eventos diretamente: é possível consultar a tabela de eventos para ler as métricas. A consulta a seguir recupera as métricas de serviço que foram registradas na última hora para o serviço 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

  Se você não souber o nome da tabela de eventos ativa para a conta, execute o comando SHOW PARAMETERS para exibir o valor do parâmetro EVENT_TABLE no nível da conta:

  SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;
  

  Copy

  Para obter mais informações sobre tabelas de evento, consulte Como usar tabela de evento.

Exemplo

Para criar um serviço de exemplo que registre métricas na tabela de eventos configurada para sua conta, conclua as etapas a seguir.

1. Criação de um serviço denominado echo_service seguindo os passos no Tutorial 1, com uma alteração. Na etapa 3, onde você cria um serviço, use o seguinte comando echo_service :doc:`, que adiciona o campo </developer-guide/snowpark-container-services/tutorials/tutorial-1> na especificação de serviço modificada:

   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

Após iniciar a execução do serviço, o Snowflake começa a registrar as métricas nos grupos de métricas especificados na tabela de eventos.

1. Acessar as métricas chamando a função <service_name>!SPCS_GET_METRICS ou consultando a tabela de eventos. Por exemplo, recuperar métricas relatadas na última hora pelo serviço echo_service:

   • Usar a função <service_name>!SPCS_GET_METRICS auxiliar:

     Copy

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

   • Consultar a tabela de eventos diretamente:

     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

Acessar métricas do pool de computação¶

As métricas do pool de computação oferecem insights sobre os nós no pool de computação e os serviços em execução neles. Cada nó relata métricas específicas do nó, como a quantidade de memória disponível para contêineres, bem como métricas de serviço, como o uso de memória por contêineres individuais. As métricas do pool de computação fornecem informações da perspectiva de um nó.

Cada nó tem um publicador de métricas que escuta na porta TCP 9001. Outros serviços podem fazer uma solicitação HTTP GET com o caminho /metrics para a porta 9001 no nó. Para descobrir o endereço IP do nó, recupere os registros SRV (ou registros A) do DNS para o nome de host discover.monitor.compute_pool_name.cp.spcs.internal. Em seguida, crie outro serviço na conta que pesquise ativamente cada nó para recuperar as métricas.

O corpo na resposta fornece as métricas usando o formato Prometheus conforme mostrado nas métricas de exemplo a seguir:

# 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

Observe o seguinte:

• O corpo da resposta começa com # HELP e # TYPE, que fornecem uma breve descrição e o tipo da métrica. Neste exemplo, a métrica node_memory_capacity é do tipo gauge.

• Em seguida, vem o nome da métrica, uma lista de rótulos que descrevem um recurso específico (ponto de dados) e seu valor. Neste exemplo, a métrica (nomeada node_memory_capacity) fornece informações de memória, indicando que o nó tem 7,2 GB de memória disponível. A métrica também inclui metadados na forma de rótulos, conforme mostrado:

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

É possível processar essas métricas da maneira que quiser; por exemplo, você pode armazenar métricas em um banco de dados e usar uma UI (como um painel do Grafana) para exibir as informações.

Para obter uma lista de métricas de pool de computação disponíveis, consulte Métricas de plataforma disponíveis.

Exemplo

Para ver um exemplo de configuração do Prometheus para consultar métricas do pool de computação, consulte os tutoriais de métricas do pool de computação.

Métricas de plataforma disponíveis¶

A seguir está uma lista de grupos de métricas de plataforma disponíveis e métricas dentro de cada grupo. Observe que atualmente as métricas de armazenamento são coletadas apenas de volumes de armazenamento em bloco.

Publicar métricas e rastreamentos de aplicativos do OTLP¶

O Snowflake executa um coletor OTel que o seu contêiner de serviço pode usar para publicar métricas e rastreamentos de aplicativos do OTLP. Ou seja, um contêiner de serviço pode enviar métricas para os pontos de extremidade do coletor OTel, que o Snowflake grava na tabela de eventos configurada para a sua conta Snowflake junto com os detalhes do serviço de origem.

Funciona da seguinte maneira:

• O Snowflake preenche automaticamente as seguintes variáveis de ambiente no seu contêiner de serviço que fornecem os pontos de extremidade do coletor OTel onde os contêineres podem publicar métricas e rastreamentos de aplicativos:

  • OTEL_EXPORTER_OTLP_METRICS_ENDPOINT

  • OTEL_EXPORTER_OTLP_TRACES_ENDPOINT

• O cliente padrão do OTLP procura essas variáveis de ambiente para descobrir automaticamente o coletor OTel. Isso permite que o seu contêiner de serviço publique métricas e rastreamentos usando esse cliente.

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();

Publicar métricas de aplicativos do Prometheus¶

O Snowflake oferece suporte a métricas do Prometheus em que, em vez de enviar métricas do OTLP, seu aplicativo pode expor métricas do Prometheus para serem pesquisadas por um coletor fornecido pelo Snowflake. Para que o Snowflake colete essas métricas de aplicativo do seu serviço e as publique na tabela de eventos, siga estas etapas:

• Faça com que seu serviço escute em uma porta que exponha suas métricas do Prometheus.

• Inclua no seu serviço um contêiner fornecido pelo Snowflake (também chamado de contêiner «sidecar»), com a configuração necessária para extrair as métricas do seu contêiner de serviço.

O sidecar do Prometheus extrai as métricas do aplicativo do contêiner em uma frequência programada, converte o formato do Prometheus no formato do OTLP e envia as métricas para o coletor OTel. Em seguida, o coletor OTel publica essas métricas na tabela de eventos configurada para sua conta Snowflake.

Você adiciona o contêiner sidecar do Prometheus à especificação do serviço como outro contêiner e inclui um argumento para especificar o ponto de extremidade HTTP exposto pelo seu contêiner, usando o seguinte formato:

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

Ele especifica o número da porta, o caminho e a frequência com que o sidecar deve extrair as métricas.

Um exemplo de fragmento de especificação de serviço mostra o contêiner sidecar coletando métricas a cada minuto do seu contêiner de serviço a partir da porta 8000 e extraindo métricas do caminho «/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"

Na especificação:

• image é a imagem do contêiner sidecar fornecido pelo Snowflake.

• args fornece a configuração necessária para que o contêiner do Prometheus extraia as métricas:

  • Da porta 8000 fornecida pelo seu contêiner. A porta é necessária nessa configuração do contêiner do Prometheus.

  • Usando o caminho «/metrics». É opcional. Se não for especificado, «/metrics» é o caminho padrão.

  • A cada minuto. É opcional. Se não for especificado, «1m» é o padrão.

  Se você usar os padrões, essa é a configuração equivalente para a extração de métricas:

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

  Copy

Acessar métricas e rastreamentos de aplicativos na tabela de eventos¶

Você pode consultar a tabela de eventos para obter métricas de aplicativos. A consulta a seguir recupera as métricas do aplicativo coletadas na última hora.

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;

Para obter mais informações sobre tabelas de evento, consulte Visão geral da tabela de evento. Você pode visualizar essas métricas nos painéis do Snowflake.

Você também pode consultar a tabela de eventos para visualizar os rastreamentos do aplicativo. Por exemplo, para recuperar rastreamentos de aplicativos da última hora, na consulta anterior, substitua a condição record_type da seguinte forma:

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

Os rastreamentos podem ser visualizados no visualizador do Snowflake trail

As métricas e os rastreamentos contêm atributos definidos pelo usuário e pelo Snowflake como atributos de recursos e registros. Observe que o prefixo snow. é reservado para atributos gerados pelo Snowflake; o Snowflake ignora os atributos personalizados que usam esse prefixo. Para ver uma lista de atributos definidos pelo Snowflake, consulte Métricas de plataforma disponíveis.

O código de exemplo é fornecido em Python e Java e demonstra a instrumentação de um aplicativo com métricas e rastreamentos personalizados usando o OTLP SDK. Os exemplos mostram como configurar a geração do Snowflake Trace ID para compatibilidade com o visualizador do Snowflake Trail para rastreamentos.

Eventos de plataforma de consulta¶

Depois de configurar o nível de log de seu recurso, o Snowflake registra os eventos da plataforma na tabela de eventos ativa de sua conta do Snowflake. É possível acessar esses eventos das seguintes maneiras:

• Usando o método auxiliar de serviço: a função de tabela <service_name>!SPCS_GET_EVENTS retorna eventos coletados pelo Snowflake dos contêineres do serviço especificado.

  A lista a seguir explica as vantagens de usar esta função de tabela:

  • Você pode recuperar eventos para um serviço específico.

  • É possível recuperar eventos dentro de um intervalo de tempo especificado.

  • O autor da chamada não precisa de acesso a toda a tabela de eventos, o que pode ser útil para clientes com requisitos rigorosos de segurança da informação.

  A seguinte instrução SELECT usa a função de tabela para recuperar eventos de plataforma para o serviço especificado registrado na última hora:

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

  Copy

• Usando a tabela de evento diretamente: você pode consultar a tabela de eventos diretamente. Para localizar a tabela de eventos ativos da conta, use o comando SHOW PARAMETERS para verificar o valor do parâmetro EVENT_TABLE:

  SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;
  

  Copy

  O parâmetro especifica a tabela de eventos ativa para a conta.

  Em seguida, consulte essa tabela de eventos. A seguinte instrução SELECT recupera eventos de plataforma para o serviço especificado que foi registrado na última hora:

  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

  Para obter mais informações sobre tabelas de evento, consulte Como usar tabela de evento.

  As seguintes colunas na tabela de eventos fornecem informações úteis sobre os eventos de plataforma:

  • TIMESTAMP: mostra quando o evento foi registrado.

  • RESOURCE_ATTRIBUTES: fornece um objeto JSON com metadados sobre a origem do evento, como um serviço, um contêiner ou um pool de computação. O exemplo a seguir de um valor na coluna resource_attribute identifica um serviço específico para o qual o evento é registrado

    {
      "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: indica a origem do evento. Para eventos de plataforma, o nome do escopo é snow.spcs.platform, conforme mostrado no exemplo a seguir:

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

    Copy

  • RECORD_TYPE: para eventos de plataforma, EVENT é o RECORD_TYPE.

  • RECORD: fornece metadados sobre o evento específico. Os metadados a seguir mostram o nome e o nível de gravidade do evento de plataforma:

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

    Copy

  • VALUE: fornece os detalhes do evento. O exemplo a seguir mostra o status e uma mensagem sobre o status do contêiner:

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

    Copy

Eventos com suporte¶

Atualmente, o Snowflake oferece suporte apenas aos eventos de alteração de status do contêiner.

A tabela a seguir lista os eventos de plataforma que o Snowflake registra. RECORD e VALUE nos nomes das colunas se referem às colunas na tabela de eventos (explicadas na seção anterior).