Observabilidade em aplicativos Snowflake¶

Tipos de dados de telemetria¶

Para garantir que os dados de telemetria que você coleta sejam amplamente úteis, a telemetria do Snowflake foi desenvolvida com base na estrutura padrão OpenTelemetry (às vezes chamada de OTel), um projeto de incubação da Cloud Native Compute Foundation. Por meio desse framework (e de APIs e ferramentas projetadas para ela), você pode reutilizar os dados coletados com ferramentas além do Snowflake. Por meio do OpenTelemetry, é possível instrumentar o código do aplicativo para adicionar observabilidade onde você desejar.

As tabelas de eventos do Snowflake coletam dados de registro, abrangência e métricas no modelo de dados OpenTelemetry. A seguir, a descrição de cada tipo de dados de telemetria coletados em uma tabela de eventos.

Logs	Os logs registram operações individuais realizadas por código. Cada mensagem de log é gerada em um ponto discreto durante a execução do código. Instrumentação do código Você pode registrar a partir do seu código usando bibliotecas padrão para a linguagem que está usando, conforme listado em Registro a partir do código do manipulador. Visualização de dados Você pode visualizar as mensagens de log para análise, consultando a tabela de eventos ou observando as exibições fornecidas em Snowsight. A seguinte imagem do Snowsight mostra uma lista de mensagens de log coletadas em um período de duas horas em um único banco de dados.
Métricas	As métricas são medidas calculadas em um período de tempo. Esses valores incluem medições de CPU e de memória. Instrumentação de código O Snowflake emite dados de métricas automaticamente à medida que o código é executado, portanto, você não precisa instrumentar o código. Visualização de dados Você pode visualizar os dados de métricas para análise, consultando a tabela de eventos ou observando as visualizações fornecidas em Snowsight. A seguinte imagem do Snowsight mostra as alterações nos dados de métricas coletados para a execução de uma função definida pelo usuário.
Rastreamentos	Os rastreamentos mostram eventos distribuídos à medida que os dados fluem por um sistema. Em um rastreamento, você pode ver onde o tempo é gasto à medida que o processamento flui de um componente para outro. Você pode emitir eventos de rastreamento - tanto dentro do intervalo padrão criado pelo Snowflake quanto a partir de um intervalo personalizado criado por você - usando bibliotecas padrão para a linguagem que estiver usando, conforme listado em Registro a partir do código do manipulador. Instrumentação do código Você pode emitir eventos de rastreamento a partir do seu código usando bibliotecas padrão para a linguagem que está usando, conforme listado em Rastreamento de eventos a partir do código do manipulador. Visualização de dados Você pode visualizar os eventos de rastreamento para análise, consultando a tabela de eventos ou observando as exibições fornecidas em Snowsight. A imagem a seguir de Snowsight mostra os spans resultantes da execução da UDF.

Configure seu ambiente para capturar dados de telemetria antes que você precise deles¶

Não é possível analisar dados que não foram coletados, portanto, é melhor começar a coletar dados de telemetria para que você os tenha quando precisar. À medida que sua implementação cresce, aumenta a necessidade de entender o desempenho do seu código.

Use as práticas recomendadas a seguir:

• Habilite a coleta de dados de telemetria para seu ambiente Snowflake.

  Para coletar os dados de que você precisa, certifique-se de ter uma tabela de eventos ativa.

• Para garantir que você esteja coletando os dados de telemetria desejados, defina os níveis de telemetria para limiares úteis.

  A princípio, você deve definir esses níveis para garantir que está coletando dados. Por exemplo, defina os níveis de registro de log como, no mínimo, WARN para qualquer trabalho de produção ou crítico para os negócios. Com o tempo, você pode ajustar esses níveis para atender às necessidades em constante mudança.

  Organize seus procedimentos armazenados de produção, UDFs e outros objetos em um banco de dados ou esquema para que você possa simplesmente ativar os logs de aviso para esse banco de dados ou esquema. Isso evita o trabalho de gerenciar configurações para objetos separados.

• Para gerar dados para solução de problemas, adicione instruções de log ou eventos de rastreamento aos seus trabalhos de produção.

  Quando você usa bibliotecas de registro em log padrão como a SLF4J do Java ou as bibliotecas de registro em log do Python, o Snowflake encaminha automaticamente os logs desses pacotes para a tabela de eventos.

  Para rastreamento, você pode usar as bibliotecas de telemetria incluídas no Snowflake.

• Para incluir nos dados de rastreamento partes do processamento do manipulador que você deseja medir, adicione spans personalizados ao código do manipulador do procedimento armazenado.

  Juntamente com os intervalos integrados dos objetos do Snowflake, o Snowflake representa os spans personalizados que você cria no diagrama de rastreamento. Com os spans personalizados, você pode capturar dados sobre partes arbitrárias do processamento do seu código para ver quanto tempo essas partes levam para serem executadas. Você também pode anexar metadados arbitrários a períodos personalizados para adicionar descrições aos dados para solução de problemas e otimização.

Otimização de procedimentos com telemetria de consulta¶

No diagrama de rastreamento Telemetria de consulta, você encontrará dados sobre todos os spans emitidos por uma consulta.

• O eixo horizontal exibe a duração. Um span que parece mais longo horizontalmente levou mais tempo para ser concluído do que um span mais curto.

• O eixo vertical exibe a hierarquia de chamadas. Nessa hierarquia, qualquer span que esteja diretamente abaixo de outro intervalo é um «filho» do span «pai» acima dele.

Você pode usar esse diagrama para encontrar oportunidades de otimização em procedimentos armazenados. Usando o que vê no diagrama como ponto de partida, você pode tomar medidas para otimizar seu código.

Por exemplo, você pode organizar operações sequenciais para que sejam executadas em paralelo usando bibliotecas como a joblib. Joblib é um conjunto de ferramentas para adicionar pipelining ao código Python. Com ele, você pode escrever código paralelo com mais facilidade.

Operações de DataFrame de cache redundante¶

Quando você tem uma cadeia de operações do DataFrame que é usada várias vezes, ele as verá no diagrama de rastreamento como um span para cada ação do DataFrame. Dependendo da complexidade da consulta, esse span pode ser bastante longo.

Por exemplo, no código abaixo, a mesma cadeia do DataFrame é chamada em vários contextos:

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

O uso do cache melhora o desempenho ao armazenar em cache o DataFrame intermediário como uma tabela temporária, reduzindo as consultas redundantes:

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

Gerenciamento da quantidade de dados de telemetria recebidos para UDFs¶

Ao adicionar código para coletar dados de telemetria com UDFs, lembre-se de que o modelo de execução da UDF pode significar muito mais linhas na tabela de eventos do que para um procedimento.

Quando uma UDF é chamada em cada linha de entrada, o código do manipulador emite instruções de registro em log ou eventos de span para cada linha do conjunto de dados de entrada. Por exemplo, um conjunto de dados de 10 milhões de linhas passado para uma UDF emitiria 10 milhões de entradas de log.

Considere o uso dos seguintes padrões ao adicionar logs e eventos de span a UDFs:

• Inicialmente, use os níveis de registro em log projetados para reduzir o número de entradas registradas.

  Use as instruções de registro em log de nível DEBUG ou INFO e defina o nível de registro em log como WARN na produção. Se for encontrado um problema, você pode reduzir o nível de registro em log para DEBUG ou INFO durante a sessão de depuração.

• Use blocos try/catch para isolar o código a partir do qual você deseja emitir dados de registro em log.

  O uso do try/catch pode ser útil para capturar qualquer entrada da UDF inesperada, registrá-la como um registro de nível WARN para conscientização e retornar um valor padrão.

• Use instruções de condição para registrar apenas os cenários que são significativos para você.

  Com instruções if/else ou outras restrições, você pode controlar o volume da saída de registro.

Otimização das funções definidas pelo usuário com telemetria de consulta¶

Quando uma UDF é chamada, o Snowflake a executa em paralelo, criando uma instância do código do manipulador para cada linha de entrada. Você verá cada uma dessas instâncias representadas como seu próprio span em um diagrama de rastreamento.

Você pode usar esses spans para solucionar problemas de consultas lentas e encontrar oportunidades de melhorar o desempenho. Por exemplo, você pode ver cenários como o seguinte:

• Uma ou mais instâncias do seu código da UDF podem receber uma linha com dados significativamente maiores ou diferentes do restante dos dados. Quando isso acontece, essa instância pode levar muito mais tempo para ser concluída e, portanto, sua duração é muito maior.

• Dependendo do particionamento de entrada da sua consulta e das cláusulas anteriores, uma minoria das instâncias pode receber uma quantidade enorme de dados de entrada.

A imagem a seguir mostra um intervalo para cada linha passada para uma UDF, em que a duração mais longa de um span sugere que a linha pode ter dados maiores do que as outras.

Práticas recomendadas de alertas e notificações¶

Use as práticas a seguir para melhorar a observabilidade, refinando e aumentando a quantidade de informações que você recebe do sistema.

• Evite duplicar a avaliação do evento.

  Você pode evitar a duplicação de avaliações em eventos, levando em conta a latência entre a programação e a execução do alerta. Para fazer isso, especifique os carimbos de data/hora do alerta usando SCHEDULED_TIME e LAST_SUCCESSFUL_SCHEDULED_TIME em vez de CURRENT_TIMESTAMP.

  Para obter mais informações, consulte Especificação de carimbos de data/hora com base nos cronogramas de alerta.

• Enriqueça uma ação de alerta ou notificação com resultados de consulta.

  Você pode verificar os resultados da declaração de SQL especificada por uma condição de alerta. Para obter os resultados de consulta, faça o seguinte:

  1. Recupere o ID de consulta para a instrução SQL da condição de alerta, chamando GET_CONDITION_QUERY_UUID.

  2. Passe o ID de consulta para RESULT_SCAN para obter os resultados de consulta.

• Registre um resultado em log ou execute uma ação automatizada, além de enviar uma notificação.

  Você pode especificar que uma ação de alerta execute uma tarefa ou registre em log uma nova linha em uma tabela sempre que uma condição de alerta for atendida. Por exemplo, você pode fazer isso se tomar uma ação no Snowflake sempre que a condição de alerta for atendida.

  Se você pretende executar uma ação complexa depois que uma condição for atendida, certifique-se de que seu warehouse tenha o tamanho adequado.