Monitorar e solucionar problemas do DCM Projects

Este tópico descreve como monitorar implantações do DCM e solucionar problemas de planos DCM com falha.

Solucionar problemas do DCM project

Se você não tiver familiaridade com o DCM project, poderá encontrar erros devido a configurações incorretas ou outras armadilhas comuns. Esta seção descreve esses erros e como resolvê-los.

Causas comuns de erros

A tabela a seguir lista as causas comuns de erros em uma execução do DCM project:

Categoria de erro

Causas comuns

Funções secundárias

  • Os usuários encontram comportamento inconsistente devido ao uso inadvertido de privilégios de função secundária ao executar comandos DCM.

Privilégios de função insuficientes

  • Privilégios de função insuficientes para criar tipos de objeto definidos

  • Privilégios de função insuficientes para alterar ou descartar objetos existentes que agora pertencem a outra função

  • Privilégios de função insuficientes para usar DMFs do sistema

  • Privilégios de função insuficientes para executar um warehouse para atualizar uma tabela dinâmica na criação

Problemas de renderização Jinja

  • Problemas de renderização Jinja devido à sintaxe Jinja incorreta

  • Problemas de renderização Jinja devido a incompatibilidades de tipo de valor

Problemas de projeto

  • Caminho do manifesto incorreto

  • Pastas de definição vazias

  • Arquivos de definição desatualizados na ramificação de repositório errado

  • Objetos que já foram implantados por outro DCM project

  • Referências de projeto e objeto incompatíveis

Observar e auditar as implantações de DCM project

Os DCM Projects são projetados para fornecer total transparência e trilhas de auditoria para todas as alterações na infraestrutura da sua conta. Isso exige que você siga algumas práticas recomendadas de desenvolvimento de software para configurar processos de implantação de infraestrutura. Para obter mais informações, consulte Automatizar uma implantação de DCM project.

Use as seguintes fontes para revisar implantações anteriores:

Artefatos de implantação

Para cada implantação executada, um instantâneo imutável dos artefatos de implantação é armazenado dentro do DCM project, com as seguintes informações:

  • O arquivo de manifesto (manifest.yml)

  • Todos os arquivos de definição de objeto e macro (arquivos .sql) dentro da pasta sources

  • A saída da operação PLAN (plan_result.json) e ​​da operação DEPLOY (deploy_result.json), incluindo:

    • As variáveis ​​de modelo utilizadas para esta implantação

    • Metadados de implantação, incluindo carimbo de data/hora, nome do objeto e ID de consulta

    • O conjunto de alterações

Este conjunto completo torna todas as ações de implantação reproduzíveis para depuração, auditoria ou reimplantação do estado definido.

Os seguintes comandos estão disponíveis para observar e auditar um DCM project:

  • Com o privilégio MONITOR, você pode:

    • Listar todas as implantações armazenadas dentro do DCM project.

    • Listar todos os arquivos dentro de uma implantação específica.

    • Ler, copiar ou baixar arquivos específicos dentro dessa implantação.

  • Com o privilégio OWNERSHIP, você poderá excluir manualmente uma implantação se ela contiver dados confidenciais.

  • Com o privilégio READ, você pode executar o comando DESCRIBE para ver o nome, o alias e o carimbo de data/hora da implantação mais recente para um DCM project selecionado.

Exemplos de comandos:

DESCRIBE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV;

SHOW DEPLOYMENTS IN DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV;

LIST 'snow://project/DCM_DEMO.PROJECTS.DCM_PROJECT_DEV/deployments/DEPLOYMENT$1/';

ALTER DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV DROP DEPLOYMENT DEPLOYMENT$1;

Histórico de implantação

As funções INFORMATION_SCHEMA fornecem acesso baseado em funções e maneiras de baixa latência para visualizar implantações bem-sucedidas e com falha para um DCM project selecionado.

Os argumentos project_name e result_limit são opcionais.

Exemplos de comandos:

SELECT
  START_TIMESTAMP,
  END_TIMESTAMP,
  STATUS,
  DEPLOYMENT_NUMBER,
  DEPLOYMENT_ALIAS,
  CONFIGURATION_PROFILE,
  ERROR_MESSAGE,
  EXECUTOR_ROLE,
  STATS
FROM
  TABLE (DCM_DEMO.INFORMATION_SCHEMA.DCM_DEPLOYMENT_HISTORY(
    project_name => 'DCM_DEMO.PROJECTS.DCM_PROJECT_DEV',
    result_limit => 50
  ));

Logs de eventos

Você pode definir o LOG_LEVEL preferencial no objeto de DCM project ou herdar o LOG_LEVEL definido do esquema, banco de dados ou conta pai.

Se o LOG_LEVEL para o DCM project estiver definido, as execuções com falha de PLAN e DEPLOY serão registradas com as mensagens de erro correspondentes como um evento, e você poderá visualizá-las consultando a tabela de eventos definida. Para obter mais informações sobre como configurar tabelas de eventos e níveis de log, consulte Visão geral da tabela de evento.

Por exemplo:

SELECT
  TIMESTAMP,
  RESOURCE_ATTRIBUTES:"snow.executable.name" ::STRING AS PROJECT_NAME,
  CASE
    WHEN RESOURCE_ATTRIBUTES:"snow.project.dcm.execution.command" ::STRING = 'plan' THEN 'PLAN'
    WHEN RESOURCE_ATTRIBUTES:"snow.project.dcm.execution.command" ::STRING = 'deploy' THEN 'DEPLOY'
    ELSE RESOURCE_ATTRIBUTES:"snow.project.dcm.execution.command" ::STRING
  END AS COMMAND,
  CASE
    WHEN VALUE:"state" ::STRING = 'SUCCEEDED' THEN 'SUCCEEDED'
    WHEN VALUE:"state" ::STRING = 'FAILED' THEN 'FAILED'
    ELSE VALUE:"state" ::STRING
  END AS STATUS,
  COALESCE(
    CONCAT('Error message: ',VALUE:"message"::STRING),
    VALUE:"operation"::STRING)
  AS OPERATIONS,
  RESOURCE_ATTRIBUTES:"snow.session.role.primary.name" ::STRING AS ROLE,
  RESOURCE_ATTRIBUTES:"db.user" ::STRING AS USER_NAME,
  RECORD:"severity_text" ::STRING AS SEVERITY
FROM
  SNOWFLAKE.TELEMETRY.EVENTS
WHERE
  RESOURCE_ATTRIBUTES:"snow.executable.type" ::STRING = 'DCM_PROJECT'
ORDER BY
  TIMESTAMP DESC
LIMIT
  250;