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. Analise o Stackdriver.
  3. No Console do GCP, verifique se há erros nas páginas dos elementos do GCP que executam o 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 procurar instâncias de tarefa com falha em um DAG grande, altere a orientação da visualização do gráfico (em inglês) de LR para RL. Basta substituir a configuração padrão dag_orientation 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. Analise o Stackdriver.
  4. Verifique os registros específicos do operador.
  5. Corrija os erros.
  6. Faça upload do DAG para a 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 GCP, acesse o painel de cargas de trabalho do GKE.
  2. Se houver pods "airflow-worker" que exibam "Removido", clique em cada um deles e veja se há 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 da lista de DAGs, uma caixa de alerta vermelho mostra Broken DAG: [/path/to/dagfile] Timeout.
  • Stackdriver: 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 em core-dagbag_import_timeout e execute a análise do DAG por mais tempo.

O DAG trava o servidor da Web do Airflow ou faz ele retornar um erro 502 gateway timeout

As falhas no servidor da Web podem ocorrer por alguns motivos. Se você executa o composer-1.5.2 ou superior, verifique os registros "airflow-webserver" no Stackdriver 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 de core-dagbag_import_timeout é 30 segundos. Esse valor define o limite máximo do tempo gasto pelo Airflow 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 analisa os arquivos de definição do DAG, e a falha 502 gateway timeout poderá ocorrer se houver erros no DAG. O Airflow funcionará normalmente sem um servidor da Web em operação se o DAG que causa o problema não estiver interrompendo processos em execução no GKE. Nesse caso, use gcloud composer environments run para recuperar detalhes sobre o ambiente. Essa é 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.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…