Como resolver problemas de DAGs (fluxos de trabalho)

Nesta página, você encontra informações sobre a solução de problemas comuns do fluxo de trabalho e suas etapas.

Como resolver problemas do fluxo de trabalho

Para começar a solução de problemas, siga estes passos:

  1. Verifique os registros do Airflow.
  2. Revise o conjunto de operações do Google Cloud.
  3. No Console do Cloud, verifique se há erros nas páginas dos componentes do Google Cloud em execução no ambiente.
  4. Na interface da Web do Airflow, verifique na Visualização do gráfico (em inglês) do DAG se há instâncias de tarefa com falha.

    Dica: para navegar por um DAG grande para procurar instâncias de tarefa com falha, mude a orientação da visualização do gráfico (em inglês) de LR para RL substituindo a configuração dag_orientation padrão do servidor da Web.

Como depurar falhas do operador

Para depurar uma falha do operador, siga estes passos:

  1. Verifique se há erros específicos da tarefa.
  2. Verifique os registros do Airflow.
  3. Revise o conjunto de operações do Google Cloud.
  4. Verifique os registros específicos do operador.
  5. Corrija os erros.
  6. Faça upload do DAG na pasta dags/.
  7. Na interface da Web do Airflow, limpe os estados anteriores (em inglês) do DAG.
  8. Execute o DAG ou retome esse processo.

Problemas comuns

Nas seções a seguir, você encontra descrições dos sintomas e possíveis correções de alguns problemas comuns do fluxo de trabalho.

A tarefa falha sem emitir registros

Os registros são armazenados em buffer. Se um worker falhar antes da limpeza do buffer, os registros não serão emitidos. Quando uma tarefa falha sem emitir registros, isso indica que os workers do Airflow serão reiniciados devido à falta de memória (OOM, na sigla em inglês).

A execução do DAG é limitada pela RAM. Todas as tarefas são iniciadas com dois processos do Airflow: execução de tarefa e monitoramento. Atualmente, cada nó aceita até seis tarefas simultâneas, com aproximadamente 12 processos carregados com módulos do Airflow. É possível que mais memória seja consumida dependendo do tamanho do DAG.

Sintoma

  1. No Console do Cloud, acesse o painel de cargas de trabalho do GKE.
  2. Se houver pods de worker do Airflow que mostrem "Removido", clique em cada pod removido e procure a mensagem The node was low on resource: memory na parte superior da janela.

Correção

  1. Crie um novo ambiente do Cloud Composer com um tipo de máquina maior do que o atual.
  2. Garanta que as tarefas no DAG sejam idempotentes e que possam ser repetidas.
  3. Configure novas tentativas da tarefa.

A importação da carga do DAG atingiu o tempo limite

Sintoma

  • IU da Web do Airflow: na parte superior da página de lista de DAGs, uma caixa de alerta vermelha mostra Broken DAG: [/path/to/dagfile] Timeout.
  • Pacote de operações do Google Cloud: os registros airflow-scheduler contêm entradas semelhantes a:
    • "ERROR - Process timed out"
    • "ERROR - Failed to import: /path/to/dagfile"
    • "AirflowTaskTimeout: Timeout"

Correção

Modifique a configuração do Airflow para core-dagbag_import_timeout e conceda mais tempo para a análise do DAG.

O DAG falha no servidor da Web do Airflow ou faz com que ele retorne um erro 502 gateway timeout

As falhas no servidor da Web podem ocorrer por alguns motivos. Se você estiver executando composer-1.5.2 ou posterior, verifique os registros do servidor da Web do Airflow no Cloud Logging para depurar o erro 502 gateway timeout.

Computação pesada

Evite executar computação pesada durante a análise do DAG. Ao contrário dos nós de worker e de programador, que têm tipos de máquina que podem ser personalizados para garantir maior capacidade de CPU e de memória, o servidor da Web usa um tipo de máquina fixo. Isso poderá gerar falhas na análise do DAG se a computação executada durante esse processo for muito pesada.

O servidor da Web tem duas vCPUs e 2 GB de memória. O valor padrão para core-dagbag_import_timeout é de 30 segundos. Esse valor de tempo limite define o limite máximo de quanto tempo o Airflow gasta carregando um módulo do Python na pasta dags/.

Permissões incorretas

O servidor da Web não é executado na mesma conta de serviço que os workers e o programador. Assim, eles podem acessar recursos gerenciados pelo usuário a que o servidor não tem acesso.

Recomendamos que você evite acessar recursos que não sejam públicos durante a análise do DAG. Às vezes, isso é inevitável, e você precisará conceder permissões à conta de serviço do servidor da Web. O nome da conta de serviço é derivado do domínio do servidor da Web. Por exemplo, se o domínio for foo-tp.appspot.com, a conta de serviço será foo-tp@appspot.gserviceaccount.com.

Erros do DAG

O servidor da Web é executado no App Engine e fica separado do cluster do GKE do ambiente. O servidor da Web analisa os arquivos de definição do DAG, e um 502 gateway timeout pode ocorrer se houver erros no DAG. O Airflow funciona normalmente sem um servidor da Web ativo, contanto que o DAG problemático não interrompa nenhum processo executado no GKE. Nesse caso, é possível usar gcloud composer environments run para recuperar detalhes do ambiente e como uma solução alternativa se o servidor da Web ficar indisponível.

Em outros casos, é possível executar a análise do DAG no GKE, além de pesquisar os DAGs que causam exceções fatais do Python ou esse tempo limite (padrão de 30 segundos). Para resolver os problemas, conecte-se a um shell remoto em um contêiner de worker do Airflow e teste os erros de sintaxe. Para mais informações, consulte Como testar DAGs.