Observabilidade no Airflow: SLAs, retries, alertas e backfills (guia prático)

Um DAG “rodar” não significa que ele é confiável. Em produção, o que importa é previsibilidade: rodar no horário certo, com duração estável, falhar do jeito esperado quando precisa falhar e permitir recuperação segura quando algo dá errado.

Observabilidade é exatamente isso: sair do “deu erro” e chegar no “o que aconteceu, por que aconteceu e o que fazer agora”. A diferença entre observabilidade e monitoramento é bem explicada pela IBM em Qual a diferença entre observabilidade e monitoramento? e o recorte para dados (pipelines analíticos) aparece em O que é observabilidade de dados?.

Neste guia, você vai implementar observabilidade prática no Airflow para fluxos analíticos:

  • SLAs por task e por DAG
  • políticas de retries e backoff exponencial
  • alertas (e-mail e webhook) com roteamento por ownership
  • uso saudável de sensors
  • backfills seguros com idempotência e particionamento
  • pronto-socorro para zombies, stuck tasks e “fila travada”

1) O que observar no Airflow (o mínimo que resolve 80% dos incidentes)

Para pipelines analíticos, quatro sinais resolvem a maior parte do caos:

  1. Pontualidade: rodou quando devia?
  2. Duração: ficou muito mais lenta que o normal?
  3. Falhas: aumentou a taxa de erro ou ficou intermitente?
  4. Dados: entregou o que prometeu (volume, partição, consistência)?

A visão de “observabilidade como telemetria” (métricas, logs e rastreio) também é detalhada em O que é observabilidade?. E para um panorama mais amplo (padrões e serviços), você pode usar a documentação oficial do Google Cloud em Observabilidade e monitorização no Google Cloud.

2) SLAs no Airflow: como definir sem gerar ruído

SLA é compromisso de tempo. Ele não é timeout. Timeout interrompe. SLA avisa que passou do esperado.

Boas práticas que funcionam em produção:

  • Defina SLA apenas para tasks que impactam consumo downstream (dashboards, produto, relatórios).
  • Comece por SLA por task, não pelo DAG inteiro.
  • Baseie o tempo em histórico real (p95), não em “achismo”.
  • SLA sem roteamento vira spam. SLA com dono e ação vira confiabilidade.

Dica importante: se você opera Airflow gerenciado, a base de “pontualidade e execução” já aparece no troubleshooting e no monitoramento do serviço. No Cloud Composer, por exemplo, você tem guias oficiais para entender atrasos e agendamento em Como solucionar problemas do programador do Airflow (Composer).

3) Retries e backoff exponencial: robustez sem mascarar bug

Retries servem para falhas transitórias (rede, rate limit, instabilidade externa). Eles não devem esconder bug determinístico (schema mudou, coluna sumiu, regra errada).

Padrão saudável:

  • Poucos retries para tarefas determinísticas.
  • Mais retries para dependências instáveis, com backoff exponencial.
  • Limite superior (cap) para não estourar janela operacional.
  • Diferencie “falha transitória” de “falha de dados”.

Se você usa Cloud Composer, a própria documentação oficial conecta retries e backfill no contexto operacional em Recuperação, preenchimento e novas tentativas (Composer).

4) Alertas: e-mail e webhook com ownership (sem tempestade de notificações)

Alerta bom tem:

  • destino certo (time dono)
  • contexto mínimo (DAG, task, execução, erro, link para log)
  • severidade (informativo, ação, incidente)
  • ação recomendada (o que fazer em 2 minutos)

Padrão recomendado:

  • Falha de task: alerta para owner do DAG.
  • SLA estourado: alerta para owner e consumidor downstream (se impacta).
  • Falha repetida: abre incidente ou manda para canal de plantão.
  • Recuperado: manda “voltou ao normal” para reduzir ansiedade e ruído.

Em serviços gerenciados, existe documentação útil de “troubleshooting” que ajuda a decidir quando alertar por capacidade, fila e concorrência. No Google Cloud Composer, por exemplo, problemas de tasks enfileiradas e capacidade são detalhados em Troubleshooting Airflow scheduler issues (Composer).

5) Sensors: como esperar sem travar workers

Sensor é necessário quando você depende de algo externo (arquivo chegou, partição apareceu, API liberou). O erro clássico é usar o sensor como “sleep disfarçado”, prendendo slot e derrubando throughput.

Regras simples:

  • Tenha timeout e intervalo coerentes.
  • Evite sensores longos ocupando workers quando seu ambiente é limitado.
  • Prefira particionamento e independência: “se não tem partição, não processa”, ao invés de “espera até ter”.

6) Backfills com segurança: idempotência + particionamento

Backfill é inevitável. O que separa backfill seguro de desastre é:

Idempotência

Rodar de novo não pode duplicar nem corromper. Para isso, sua saída precisa ter uma estratégia clara:

  • sobrescrita por partição (data)
  • upsert por chave natural
  • staging e promoção (escreve em área temporária e publica depois)
Particionamento

Evite “reprocessar tudo”. Participe por data e reprocesse apenas o intervalo necessário.

Se você opera Airflow na AWS, a documentação oficial do MWAA tem pontos importantes sobre limitações e troubleshooting do backfill no ambiente gerenciado. Use como referência operacional:

7) Padrão de pastas, naming e ownership (o que mais reduz incidentes)

Um padrão simples já melhora a observabilidade, mesmo antes de qualquer ferramenta extra.

Sugestão de estrutura:

  • dags/ apenas DAGs
  • tasks/ operadores e componentes reutilizáveis
  • configs/ variáveis por ambiente
  • docs/ runbooks e checklists por pipeline
  • tests/ validações simples e contratos

Naming que ajuda operação:

  • DAG: domínio + pipeline + frequência (ex.: finance, mart_receita, daily)
  • Tasks: verbos claros (extract, load, build, dq_checks)
  • Tags: domínio, camada (raw/staging/mart), criticidade

Ownership que funciona:

  • owner real (time ou pessoa), não “data”
  • canal de alerta definido por owner
  • runbook linkado na descrição do DAG

8) Pronto-socorro: zombies, stuck tasks e “fila travada”

Sinais comuns:

  • task em running por muito tempo sem log novo
  • tasks queued que não começam
  • scheduler “vivo” mas sem throughput
  • fila crescendo e nada consumindo

Checklist de resposta rápida:

  1. Verifique capacidade (workers, concurrency, pools).
  2. Veja se o scheduler está agendando e se há slots livres.
  3. Se for dependência externa, aplique timeout e backoff.
  4. Evite “clear all” no impulso. Limpe o mínimo necessário.
  5. Registre o incidente e crie runbook para o padrão repetitivo.

Para ambientes gerenciados, use guias oficiais de troubleshooting como referência de diagnóstico. No Composer: Troubleshooting scheduler issues. No MWAA: Troubleshooting.

Conexão com a Tekne: do primeiro DAG à confiabilidade de produção

Se você já viu o conteúdo “Airflow para iniciantes: seu primeiro DAG em 45 minutos”, este é o passo seguinte: confiabilidade, alertas, backfills seguros e operação previsível. Isso se conecta diretamente ao Bootcamp de Data Analytics & BI da Tekne no módulo de orquestração e pipelines analíticos: Bootcamp Data Analytics & BI (Tekne).

Pesquisar

Posts Recentes

Categorias