Monitorar a integridade e o desempenho do ambiente com as principais métricas

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Observação: esta página ainda não foi revisada para o Cloud Composer 3 e mostra conteúdo para o Cloud Composer 2.

Esta página descreve como monitorar a integridade e o desempenho gerais do ambiente do Cloud Composer com as principais métricas no painel de monitoramento.

Introdução

O foco deste tutorial são as principais métricas de monitoramento do Cloud Composer que podem fornecer uma boa visão geral da integridade e do desempenho no nível do ambiente.

O Cloud Composer oferece várias métricas que descrevem o estado atual do ambiente. As diretrizes de monitoramento neste tutorial são baseadas nas métricas expostas no painel de monitoramento do seu ambiente do Cloud Composer.

Neste tutorial, você vai aprender sobre as principais métricas que servem como indicadores principais de problemas com a performance e a integridade do seu ambiente, além das diretrizes para interpretar cada métrica em ações corretivas para manter o ambiente saudável. Você também vai configurar regras de alerta e executar o DAG de exemplo e usar essas métricas e alertas para otimizar o desempenho do seu ambiente.

Objetivos

Objetivo:

• Conheça as principais métricas de desempenho e integridade disponíveis no Monitoring mais avançado.
• Conheça os comparativos de mercado de cada métrica.
• Saiba como interpretar as métricas em ações corretivas.
• Criar alertas para cada uma das principais métricas.
• Execute um DAG de exemplo.
• Interpretar alertas e gráficos do Monitoring em ações corretivas.
• Otimize seu ambiente e avalie o desempenho dele.

Custos

Neste tutorial, usamos o seguinte componente faturável do Google Cloud:

• Cloud Composer (consulte os custos adicionais).
• Cloud Monitoring

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais detalhes, consulte Limpeza.

Antes de começar

Esta seção descreve as ações necessárias antes de iniciar o tutorial.

Criar e configurar um projeto

Para este tutorial, você precisa ter uma conta do Google Cloud projeto. Configure o projeto da seguinte maneira:

1. No console do Google Cloud, selecione ou crie um projeto:

   Acesse o seletor de projetos

2. Verifique se o faturamento foi ativado para o projeto. Saiba como verificar se o faturamento está ativado em um projeto.

3. Verifique se o usuário do projeto do Google Cloud tem os seguintes papéis para criar os recursos necessários:

   • Administrador de ambiente e de objetos do Storage (roles/composer.environmentAndStorageObjectAdmin)
   • Administrador do Compute (roles/compute.admin)
   • Editor do Monitoring (roles/monitoring.editor)

Ativar as APIs do projeto

Enable the Cloud Composer API.

Enable the API

criar o ambiente do Cloud Composer

Crie um ambiente do Cloud Composer 2.

Como parte desse procedimento, você concede a extensão do agente de serviço da API Cloud Composer v2 (roles/composer.ServiceAgentV2Ext) para o agente de serviço do Composer do Compute Engine. O Cloud Composer usa essa conta para realizar operações no projeto do Google Cloud.

Analisar as principais métricas de integridade e desempenho do ambiente

Este tutorial se concentra nas principais métricas que podem dar uma boa visão geral a integridade e o desempenho geral do ambiente.

O painel do Monitoring no O console do Google Cloud contém várias métricas e gráficos que permitem monitorar tendências no ambiente e identificar problemas com o Airflow componentes e recursos do Cloud Composer.

Cada ambiente do Cloud Composer tem seu próprio painel de monitoramento.

Conheça as métricas principais abaixo e localize cada uma delas no painel de monitoramento:

1. No console do Google Cloud, acesse a página Ambientes.

   Acessar "Ambientes"

2. Na lista de ambientes, clique no nome do ambiente. A página Detalhes do ambiente é aberta.

3. Acesse a guia Monitoramento.

4. Selecione a seção Visão geral, localize o item Visão geral do ambiente no painel e observe a métrica Integridade do ambiente (DAG de monitoramento do Airflow).

   • Esta linha do tempo mostra a integridade do Cloud Composer de nuvem. A cor verde da barra de integridade do ambiente indica que o ambiente está em bom estado, enquanto o status de ambiente não saudável é indicado com a cor vermelha.

   • A cada poucos minutos, o Cloud Composer executa um DAG de atividade chamado airflow_monitoring. Se a execução do DAG de atividade for concluída com êxito, o o status de integridade é True. Se a execução do DAG de atividade falhar (por exemplo, devido à remoção de pods, encerramento de processos externos ou manutenção), o status de integridade é False.

5. Selecione a seção Banco de dados SQL e localize Integridade do banco de dados. no painel e observe a métrica Integridade do banco de dados.

   • Essa linha do tempo mostra o status da conexão com o instância do Cloud SQL do seu ambiente. A barra de integridade do banco de dados verde indica conectividade, enquanto as falhas de conexão são indicadas com a cor vermelha.

   • O pod de monitoramento do Airflow dá um ping no banco de dados periodicamente e emite relatórios status de integridade como True se uma conexão puder ser estabelecida ou Caso contrário, False.

6. No item Integridade do banco de dados, observe os Uso de CPU do banco de dados e Métricas de uso de memória do banco de dados.

   • O gráfico de uso da CPU do banco de dados indica o uso de núcleos da CPU pelo as instâncias de banco de dados do Cloud SQL do seu ambiente em comparação limite total de CPU disponível para o banco de dados.

   • O gráfico de uso de memória do banco de dados indica o uso de memória pelo as instâncias de banco de dados do Cloud SQL do seu ambiente em comparação o limite total de memória disponível do banco de dados.

7. Selecione a seção Programadores e localize o sinal de funcionamento do programador. no painel e observe a métrica Frequência de funcionamento do programador.

   • Essa linha do tempo mostra integridade do programador do Airflow. Verifique se há áreas vermelhas para identificar problemas do agendador do Airflow. Se as ambiente tiver mais de um agendador, então o status do sinal de funcionamento será desde que pelo menos um dos programadores esteja respondendo.

   • O programador será considerado não íntegro se o último sinal de funcionamento tiver sido recebido mais de 30 segundos (valor padrão) antes do horário atual.

8. Selecione a seção Estatísticas do DAG, localize o item Tarefas zumbi excluídas no painel e observe a métrica Tarefas zumbi excluídas.

   • Este gráfico indica o número de tarefas zumbi eliminadas em um pequeno janela de tempo. Tarefas zumbi geralmente são causadas pelo encerramento externo dos processos do Airflow (como quando um processo de tarefa é encerrado).

   • O programador do Airflow elimina tarefas zumbi periodicamente, o que é refletido neste gráfico.

9. Selecione a seção Workers e localize Reinicializações do contêiner do worker. item no painel e observe a métrica Reinicializações do contêiner do worker.

   • Um gráfico indica o número total de reinicializações para contêineres de workers individuais. Muitas reinicializações de contêiner podem afetar a disponibilidade seu serviço ou outros serviços downstream que o usam como dependência.

Observação :é possível analisar melhor cada métrica visualizá-los no Cloud Monitoring.

Conheça os comparativos de mercado e as possíveis ações corretivas para as principais métricas

Importante :as métricas da linha do tempo fornecem uma visão geral da integridade dos componentes individuais do ambiente; No entanto, as áreas vermelhas não indicam que um componente não está íntegro. Às vezes, pequenas áreas vermelhas na linha do tempo verde geral podem ser causadas por fatores externos, como operações de manutenção no cluster do ambiente. Use o modelo de monitoramento correspondente gráficos e registros para investigar possíveis motivos, analisar a correlação entre métricas diferentes e fazer correções com base na raiz identificada causas.

A lista a seguir descreve valores de referência que podem indicar problemas e fornece ações corretivas que você pode realizar para resolver esses problemas.

• Integridade do ambiente (DAG de monitoramento do Airflow)

  • Menos de 90% de taxa de sucesso em uma janela de 4 horas

  • As falhas podem resultar na remoção de pods ou no encerramento de workers porque quando o ambiente está sobrecarregado ou com defeito. Áreas vermelhas no meio ambiente a linha do tempo de saúde geralmente se correlaciona com áreas vermelhas nas outras barras de saúde dos componentes individuais do ambiente. Identifique a causa raiz analisar outras métricas no painel do Monitoring.

• Integridade do banco de dados

  • Menos de 95% de taxa de sucesso em uma janela de 4 horas

  • As falhas indicam que há problemas de conectividade com o banco de dados do Airflow, o que pode ser resultado de uma falha ou inatividade do banco de dados porque ele está sobrecarregado (por exemplo, devido ao uso intenso de CPU ou memória ou latência mais alta ao se conectar ao banco de dados). Estes sintomas são causados com mais frequência por DAGs abaixo do ideal, como quando eles usam diversas variáveis de ambiente ou Airflow definidas globalmente. Identifique a causa raiz analisando as métricas de uso de recursos do banco de dados SQL. Também é possível inspecionar os registros do programador em busca de erros relacionados à conectividade do banco de dados.

• Uso de CPU e memória do banco de dados

  • Mais de 80% do uso médio da CPU ou da memória em uma janela de 12 horas

  • O banco de dados pode estar sobrecarregado. Analise a correlação entre as execuções de DAG e os picos no uso de CPU ou memória do banco de dados.

    • É possível reduzir a carga do banco de dados DAGs mais eficientes com consultas e conexões otimizadas em execução ou pela distribuição carregar de maneira mais uniforme com o tempo.

    • Como alternativa, é possível alocar mais CPU ou memória para o banco de dados. Os recursos de banco de dados são controlados pela propriedade de tamanho do ambiente do seu ambiente, que precisa ser dimensionadas para um tamanho maior.

• Sinal de funcionamento do programador

  • Menos de 90% de taxa de sucesso em uma janela de 4 horas

  • Atribua mais recursos ao programador ou aumente o número de programadores de 1 para 2 (recomendado).

• Tarefas zumbi excluídas

  • Mais de uma tarefa zumbi a cada 24 horas

  • O motivo mais comum para tarefas zumbis é a falta de CPU ou memória no cluster do ambiente. Analise os gráficos de uso de recursos dos workers e atribua mais recursos a eles ou aumente o tempo limite das tarefas zumbis para que o agendador aguarde mais tempo antes de considerar uma tarefa como zumbi.

• Reinicializações do contêiner do worker

  • Mais de uma reinicialização a cada 24 horas

  • O motivo mais comum é a falta de memória ou armazenamento do worker. Analise o consumo de recursos do worker e aloque mais memória ou armazenamento aos workers. Se a falta de recursos não for o motivo, analise solução de problemas de incidentes de reinicialização do worker e usar Consultas do Logging para descobrir os motivos das reinicializações do worker.

Criar canais de notificação

Siga as instruções em Criar um canal de notificação para criar um canal de notificação por e-mail.

Observação: para fins de redundância, é recomendável criar vários tipos de canais de notificação. Por exemplo, é possível configurar um canal de notificação do Slack além do e-mail.

Para saber mais sobre canais de notificação, consulte Gerenciar canais de notificação.

Criar políticas de alerta

Crie políticas de alertas com base nos comparativos fornecidos nas seções anteriores deste tutorial para monitorar continuamente os valores das métricas e receber notificações quando elas violarem uma condição.

Console

É possível configurar alertas para cada métrica apresentada no painel do Monitoring clicando no ícone de sino no canto do item correspondente:

Figura 1. Criar um alerta para uma métrica exibida no painel de monitoramento (clique para ampliar)

1. Encontre cada métrica que você quer monitorar no painel do Monitoring painel de controle e clique no ícone de sino no canto do item de métrica. A página Criar política de alertas é aberta.

   Importante: nome da métrica, nome do ambiente e filtros de local estão aplicadas automaticamente. No entanto, as políticas de alertas de alguns métricas exigem mais filtros e nomes de métricas diferentes. Consulte os campos "Filtros" e "Nome da métrica" nas configurações de políticas de alerta para métricas individuais e verifique se os filtros corretos estão sendo aplicados.

2. Na seção Transformar dados:

   1. Configure a seção Within each time series conforme descrito na configuração das políticas de alerta para a métrica.

   2. Clique em Próxima e configure a seção Configurar gatilho de alerta. conforme descrito na configuração das políticas de alertas da métrica.

3. Clique em Próxima.

4. Configure as notificações. Expanda o menu Canais de notificação. e selecione os canais de notificação que você criou no etapa anterior.

5. Clique em OK.

6. Na seção Nomear a política de alertas, preencha o campo Nome da política de alertas. Use um nome descritivo para cada uma das métricas. Use a opção política de alertas" conforme descrito na configuração das políticas de alertas para a métrica.

7. Clique em Próxima.

8. Revise a política de alertas e clique em Criar política.

Métrica de integridade do ambiente (DAG de monitoramento do Airflow): configurações de política de alertas

• Nome da métrica: ambiente do Cloud Composer – íntegro
• API: composer.googleapis.com/environment/healthy

• Filtros:

  environment_name = [ENVIRONMENT_NAME]
  location = [CLUSTER_LOCATION]
  

• Transformar dados > Em cada série temporal:

  • Janela contínua: personalizada
  • Valor personalizado: 4
  • Unidades personalizadas: horas
  • Função de janela contínua: fração verdadeira

• Configure o gatilho de alertas:

  • Tipos de condição: limite
  • Acionador de alerta: Qualquer série temporal que viola
  • Posição do limite: abaixo do limite
  • Valor do limite: 90
  • Nome da condição: condição de integridade do ambiente

• Configure as notificações e finalize o alerta:

  • Nome da política de alertas: "Saúde do ambiente do Airflow"

Métrica de integridade do banco de dados: configurações da política de alertas

• Nome da métrica: Cloud Composer Environment - Database Healthy
• API: composer.googleapis.com/environment/database_health

• Filtros:

  environment_name = [ENVIRONMENT_NAME]
  location = [CLUSTER_LOCATION]
  

• Transformar dados > Em cada série temporal:

  • Janela contínua: personalizada
  • Valor personalizado: 4
  • Unidades personalizadas: horas
  • Função de janela contínua: fração verdadeira

• Configure o gatilho de alertas:

  • Tipos de condição: limite
  • Acionador de alerta: Qualquer série temporal que viola
  • Posição do limite: abaixo do limite
  • Valor do limite: 95
  • Nome da condição: condição de integridade do banco de dados

• Configure as notificações e finalize o alerta:

  • Nomeie a política de alertas: Integridade do banco de dados do Airflow

Métrica de uso da CPU do banco de dados: configurações da política de alertas

Observação: para simplificar, ao configurar alertas para o uso da memória do Database e Métricas de uso da CPU do banco de dados, use os nomes das métricas Uso da memória do banco de dados (composer.googleapis.com/environment/database/memory/utilization) e Uso de CPU do banco de dados (composer.googleapis.com/environment/database/cpu/utilization) em vez de nomes de métricas padrão que monitoram os bytes usados (composer.googleapis.com/environment/database/memory/bytes_used) e usados vez (composer.googleapis.com/environment/database/cpu/usage_time). O As métricas de utilização de CPU e memória do banco de dados monitoram a porcentagem de em comparação com a CPU e a memória disponíveis automaticamente, o que ajuda a evitar cálculos ao configurar o gatilho de condição.

• Nome da métrica: Ambiente do Cloud Composer - Uso de CPU do banco de dados
• API: composer.googleapis.com/environment/database/cpu/utilization

• Filtros:

  environment_name = [ENVIRONMENT_NAME]
  location = [CLUSTER_LOCATION]
  

• Transformar dados > Em cada série temporal:

  • Janela contínua: personalizada
  • Valor personalizado: 12
  • Unidades personalizadas: hora(s)
  • Função de janela contínua: média

• Configurar o gatilho de alerta:

  • Tipos de condição: limite
  • Acionador de alerta: qualquer série temporal viola
  • Posição do limite: acima do limite
  • Valor do limite: 80
  • Nome da condição: condição de uso da CPU do banco de dados

• Configure notificações e finalize o alerta:

  • Nomeie a política de alertas: "Uso de CPU do banco de dados do Airflow"

Métrica de uso da CPU do banco de dados: configurações da política de alertas

Observação: para simplificar, ao configurar alertas para o uso da memória do Database e Métricas de uso da CPU do banco de dados, use os nomes das métricas Uso da memória do banco de dados (composer.googleapis.com/environment/database/memory/utilization) e Uso de CPU do banco de dados (composer.googleapis.com/environment/database/cpu/utilization) em vez de nomes de métricas padrão que monitoram os bytes usados (composer.googleapis.com/environment/database/memory/bytes_used) e usados vez (composer.googleapis.com/environment/database/cpu/usage_time). O As métricas de utilização de CPU e memória do banco de dados monitoram a porcentagem de em comparação com a CPU e a memória disponíveis automaticamente, o que ajuda a evitar cálculos ao configurar o gatilho de condição.

• Nome da métrica: ambiente do Cloud Composer: utilização da memória do banco de dados
• API: composer.googleapis.com/environment/database/memory/utilization

• Filtros:

  environment_name = [ENVIRONMENT_NAME]
  location = [CLUSTER_LOCATION]
  

• Transformar dados > Em cada série temporal:

  • Janela contínua: personalizada
  • Valor personalizado: 12
  • Unidades personalizadas: hora(s)
  • Função de janela contínua: média

• Configurar o gatilho de alerta:

  • Tipos de condição: limite
  • Acionador de alerta: qualquer série temporal viola
  • Posição do limite: acima do limite
  • Valor do limite: 80
  • Nome da condição: condição de uso da memória do banco de dados

• Configure notificações e finalize o alerta:

  • Nome da política de alertas: Uso de memória do banco de dados do Airflow

Métrica de sinais de funcionamento do programador: configurações da política de alertas

• Nome da métrica: ambiente do Cloud Composer: batimentos do programador
• API: composer.googleapis.com/environment/scheduler_heartbeat_count

• Filtros:

  environment_name = [ENVIRONMENT_NAME]
  location = [CLUSTER_LOCATION]
  

• Transformar dados > Em cada série temporal:

  • Janela contínua: personalizada
  • Valor personalizado: 4
  • Unidades personalizadas: hora(s)
  • Função de janela contínua: contagem

• Configure o gatilho de alertas:

  • Tipos de condição: limite
  • Acionador de alerta: Qualquer série temporal que viola
  • Posição do limite: abaixo do limite

  • Valor do limite: 216

    Observação: a contagem de batimentos cardíacos média do programador em um ambiente inativo é 240. Portanto, uma taxa de sucesso de 90% em uma janela de 4 horas equivale a 240 * 0,9 =
    1. Você pode conseguir esse número executando uma consulta que agrega o valor _scheduler_heartbeat_count_mean no Editor de consultas do Metrics Explorer.

  • Nome da condição: condição de sinal de funcionamento do programador

• Configure notificações e finalize o alerta:

  • Nomeie a política de alertas: Sinal de funcionamento do programador do Airflow

Métrica "Tarefas zumbis eliminadas": configurações da política de alertas

• Nome da métrica: ambiente do Cloud Composer: tarefas zumbi excluídas
• API: composer.googleapis.com/environment/zombie_task_killed_count

• Filtros:

  environment_name = [ENVIRONMENT_NAME]
  location = [CLUSTER_LOCATION]
  

• Transformar dados > Em cada série temporal:

  • Janela contínua: 1 dia
  • Função de janela contínua: soma

• Configure o gatilho de alertas:

  • Tipos de condição: limite
  • Acionador de alerta: qualquer série temporal viola
  • Posição do limite: acima do limite
  • Valor do limite: 1
  • Nome da condição: condição das tarefas zumbi

• Configure as notificações e finalize o alerta:

  • Nomeie a política de alertas: "Tarefas zumbis do Airflow"

Métrica de reinicializações do contêiner do worker: configurações da política de alertas

• Nome da métrica: ambiente do Cloud Composer - tarefas zumbis eliminadas
• API: composer.googleapis.com/environment/zombie_task_killed_count

• Filtros:

  environment_name = [ENVIRONMENT_NAME]
  location = [CLUSTER_LOCATION]
  

• Transformar dados > Em cada série temporal:

  • Janela contínua: 1 dia
  • Função de janela contínua: soma

• Configure o gatilho de alertas:

  • Tipos de condição: limite
  • Acionador de alerta: qualquer série temporal viola
  • Posição do limite: acima do limite
  • Valor do limite: 1
  • Nome da condição: condição das tarefas zumbi

• Configure as notificações e finalize o alerta:

  • Nomeie a política de alertas: "Tarefas zumbis do Airflow"

Terraform

Executar um script do Terraform que cria um canal de notificação por e-mail e faz uploads políticas de alertas para as principais métricas fornecidas neste tutorial com base nas seus respectivos comparativos de mercado:

1. Salve o arquivo de exemplo do Terraform no seu computador local.

2. Substitua:

   • PROJECT_ID: o ID do projeto. Por exemplo, example-project.
   • EMAIL_ADDRESS: o endereço de e-mail que deverá ser notificado caso um é acionado.
   • ENVIRONMENT_NAME: o nome do seu ambiente do Cloud Composer. Por exemplo, example-composer-environment.
   • CLUSTER_NAME: o nome do cluster do ambiente, que pode ser encontrado em Configuração do ambiente > Recursos > Cluster do GKE no console do Google Cloud.

resource "google_monitoring_notification_channel" "basic" {
  project      = "PROJECT_ID"
  display_name = "Test Notification Channel"
  type         = "email"
  labels = {
    email_address = "EMAIL_ADDRESS"
  }
  # force_delete = false
}

resource "google_monitoring_alert_policy" "environment_health_metric" {
  project      = "PROJECT_ID"
  display_name = "Airflow Environment Health"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Environment health condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/healthy\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_LT"
      threshold_value = 0.9
      aggregations {
        alignment_period   = "14400s"
        per_series_aligner = "ALIGN_FRACTION_TRUE"
      }
    }
  }

}

resource "google_monitoring_alert_policy" "database_health_metric" {
  project      = "PROJECT_ID"
  display_name = "Airflow Database Health"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Database health condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database_health\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_LT"
      threshold_value = 0.95
      aggregations {
        alignment_period   = "14400s"
        per_series_aligner = "ALIGN_FRACTION_TRUE"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_database_cpu_usage" {
  project      = "PROJECT_ID"
  display_name = "Airflow Database CPU Usage"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Database CPU usage condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database/cpu/utilization\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 80
      aggregations {
        alignment_period   = "43200s"
        per_series_aligner = "ALIGN_MEAN"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_database_memory_usage" {
  project      = "PROJECT_ID"
  display_name = "Airflow Database Memory Usage"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Database memory usage condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/database/memory/utilization\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 80
      aggregations {
        alignment_period   = "43200s"
        per_series_aligner = "ALIGN_MEAN"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_scheduler_heartbeat" {
  project      = "PROJECT_ID"
  display_name = "Airflow Scheduler Heartbeat"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Scheduler heartbeat condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/scheduler_heartbeat_count\" AND resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_LT"
      threshold_value = 216 // Threshold is 90% of the average for composer.googleapis.com/environment/scheduler_heartbeat_count metric in an idle environment
      aggregations {
        alignment_period   = "14400s"
        per_series_aligner = "ALIGN_COUNT"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_zombie_task" {
  project      = "PROJECT_ID"
  display_name = "Airflow Zombie Tasks"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Zombie tasks condition"
    condition_threshold {
      filter     = "resource.type = \"cloud_composer_environment\" AND metric.type=\"composer.googleapis.com/environment/zombie_task_killed_count\" AND  resource.label.environment_name=\"ENVIRONMENT_NAME\""
      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 1
      aggregations {
        alignment_period   = "86400s"
        per_series_aligner = "ALIGN_SUM"
      }
    }
  }
}

resource "google_monitoring_alert_policy" "alert_worker_restarts" {
  project      = "PROJECT_ID"
  display_name = "Airflow Worker Restarts"
  combiner     = "OR"
  notification_channels = [google_monitoring_notification_channel.basic.name] // To manually add a notification channel add it with the syntax "projects/[PROJECT_ID]/notificationChannels/[CHANNEL_ID]"
  conditions {
    display_name = "Worker container restarts condition"
    condition_threshold {
      filter     = "resource.type = \"k8s_container\" AND (resource.labels.cluster_name = \"CLUSTER_NAME\" AND resource.labels.container_name = monitoring.regex.full_match(\"airflow-worker|base\") AND resource.labels.pod_name = monitoring.regex.full_match(\"airflow-worker-.*|airflow-k8s-worker-.*\")) AND metric.type = \"kubernetes.io/container/restart_count\""

      duration   = "60s"
      comparison = "COMPARISON_GT"
      threshold_value = 1
      aggregations {
        alignment_period   = "86400s"
        per_series_aligner = "ALIGN_RATE"
      }
    }
  }
}

Testar as políticas de alertas

Nesta seção, descrevemos como testar as políticas de alertas criadas e interpretar resultados.

Fazer upload de um DAG de exemplo

O DAG de amostra memory_consumption_dag.py fornecido neste tutorial imita uso intensivo de memória do worker. O DAG contém quatro tarefas, cada uma delas grava dados em uma string de amostra, consumindo 380 MB de memória. A amostra O DAG está programado para ser executado a cada dois minutos e começa a ser executado automaticamente depois de fazer o upload no ambiente do Composer.

Aviso: exclua ou pause este DAG depois de concluir o tutorial. caso contrário, seu ambiente pode consumir uma quantidade significativa de recursos, pode resultar em custos adicionais.

Faça upload do DAG de amostra a seguir no ambiente que você criou nas etapas anteriores:

from datetime import datetime
import sys
import time

from airflow import DAG
from airflow.operators.python import PythonOperator


def ram_function():
    data = ""
    start = time.time()
    for i in range(38):
        data += "a" * 10 * 1000**2
        time.sleep(0.2)
        print(f"{i}, {round(time.time() - start, 4)}, {sys.getsizeof(data) / (1000 ** 3)}")
    print(f"Size={sys.getsizeof(data) / (1000 ** 3)}GB")
    time.sleep(30 - (time.time() - start))
    print(f"Complete in {round(time.time() - start, 2)} seconds!")


with DAG(
    dag_id="memory_consumption_dag",
    start_date=datetime(2023, 1, 1, 1, 1, 1),
    schedule="1/2 * * * *",
    catchup=False,
) as dag:
    for i in range(4):
        PythonOperator(
            task_id=f"task_{i+1}",
            python_callable=ram_function,
            retries=0,
            dag=dag,
        )

Interpretar alertas e métricas no Monitoring

Aguarde cerca de 10 minutos depois que o DAG de exemplo começar a ser executado e avalie os resultados do teste:

1. Verifique se você recebeu uma notificação do Google Cloud Alerting com o assunto que começa com [ALERT]. O conteúdo desta mensagem contém os detalhes do incidente da política de alertas.

2. Clique no botão Ver incidente na notificação por e-mail. Você será redirecionado para o Metrics Explorer. Analisar os detalhes do alerta incidente:

   

   Figura 2. Detalhes do incidente de alerta (clique para ampliar)

   O gráfico de métricas de incidentes indica que as métricas criadas excederam o limite de 1, o que significa que o Airflow detectou e eliminou mais de uma tarefa zumbificada.

3. No ambiente do Cloud Composer, acesse a guia Monitoring, abra a seção DAG statistics e encontre o gráfico Zombie tasks killed:

   

   Figura 3. Gráfico de tarefas zumbi (clique para ampliar)

   O gráfico indica que o Airflow eliminou cerca de 20 tarefas zumbi dentro de apenas nos primeiros 10 minutos da execução do DAG de amostra.

4. De acordo com os comparativos de mercado e as ações corretivas, o motivo mais comum para tarefas zumbi é a falta de memória ou CPU do worker. Identifique a causa raiz das tarefas zumbi analisando a utilização de recursos do worker.

   Abra a seção "Workers" no painel do Monitoring e revise as métricas de uso da CPU e da memória do worker:

   

   Figura 4.Métricas de uso de CPU e memória do worker (clique para ampliar)

   O gráfico de uso da CPU total dos workers indica que o uso da CPU do worker estava abaixo de 50% do limite total disponível o tempo todo. Portanto, a CPU disponível é suficiente. O gráfico de uso total da memória dos workers mostra que, ao executar o que o DAG de amostra atingiu o limite de memória alocável, que é igual quase 75% do limite de memória total mostrado no gráfico O GKE reserva 25% dos primeiros 4 GiB de memória e uma mais 100 MiB de memória em cada nó para lidar com a remoção de pods).

   É possível concluir que os workers não têm os recursos de memória necessários para executar o DAG de exemplo.

Otimizar seu ambiente e avaliar o desempenho dele

Com base na análise da utilização de recursos do worker, é necessário alocar mais memória para que todas as tarefas do DAG sejam concluídas.

Observação: a mudança de workers A CPU ou a memória reinicia os workers, o que pode afetar tarefas em execução. Recomendamos fazer isso quando nenhum DAG estiver em execução.

1. No ambiente do Composer, abra a guia DAGs e clique no nome do exemplo de DAG (memory_consumption_dag) e, em seguida, clique em Pausar DAG.

2. Aloque mais memória do worker:

   1. Na guia "Configuração do ambiente", encontre a configuração Recursos > Workloads e clique em Editar.

   2. No item Worker, aumente o limite de Memória. Neste tutorial, usam 3,25 GB.

   3. Salve as alterações e aguarde alguns minutos para que o worker seja reinicializado.

3. Abra a guia "DAGs", clique no nome do DAG de exemplo (memory_consumption_dag) e clique em Reativar DAG.

Acesse Monitoramento e verifique se nenhuma nova tarefa zumbi apareceu depois que você atualizou os limites de recursos do worker:

Figura 5. Gráfico de tarefas zumbis depois que o limite de memória é alterado (clique para ampliar)

Observação: é recomendável observar o desempenho do ambiente por períodos mais longos. Por exemplo, em um ambiente de produção em que você executa muitos DAGs, recomendamos verificar se não há novos alertas após 24 horas.

Resumo

Neste tutorial, você aprendeu sobre os principais fatores de integridade e métricas de desempenho, como configurar políticas de alertas para cada métrica e como para interpretar cada métrica em ações corretivas. Depois, você executou um DAG de amostra identificou a causa raiz dos problemas de saúde do ambiente com a ajuda de alertas e gráficos do Monitoring e otimizou seu ambiente com a alocação de mais memória aos workers. No entanto, é recomendado otimizar os DAGs reduzir o consumo de recursos dos workers, porque não é possível aumentar os recursos além de um certo limite.

Limpar

Para evitar cobranças dos recursos na sua conta do Google Cloud usados neste tutorial, exclua o projeto que contém os recursos ou manter o projeto e excluir os recursos individuais.

Exclua o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Excluir recursos individuais

Se você planeja ver vários tutoriais e guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

Console

1. Exclua o ambiente do Cloud Composer. Você também excluir o bucket do ambiente durante este procedimento.
2. Exclua cada uma das políticas de alertas que você criou no Cloud Monitoring.

Terraform

1. Confirme que o script do Terraform não contém entradas para recursos que ainda são exigidos pelo seu projeto. Por exemplo, manter algumas APIs ativadas e o IAM permissões ainda atribuídas (se você adicionou essas definições ao seu script do Terraform).
2. Execute terraform destroy.
3. Exclua manualmente o bucket do ambiente. Cloud Composer não o exclui automaticamente. Você pode fazer isso console ou Google Cloud CLI.

A seguir

• Otimizar ambientes
• Escalonar ambientes
• Gerenciar rótulos de ambiente e detalhar custos de ambiente