Esta página foi traduzida pela API Cloud Translation.
Switch to English

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 o dag_orientation do servidor da Web padrão. configuração:

    Seção Chave Valor
    webserver dag_orientation LR, TB, RL ou BT

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 sã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 e monitoramento. 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 da natureza do DAG.

Sintoma

  1. No Console do Cloud, acesse o painel Kubernetes Engine -> Cargas de trabalho.

    Abra o painel Cargas de trabalho

  2. Se houver pods airflow-worker que mostrem Evicted, clique em cada pod removido e procure a mensagem The node was low on resource: memory na parte superior da janela.

Corrigir

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"

Corrigir:

Modifique a opção de configuração dagbag_import_timeout do Airflow e conceda mais tempo para a análise do DAG:

Seção Chave Valor
core dagbag_import_timeout Novo valor de tempo limite

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 diversos motivos. Verifique os registros do airflow-webserver no Cloud Logging para determinar a causa do 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.