Operações

Nível médio

Como recebo alertas antes de um problema de pipeline ficar caro?

Plataformas completas de observabilidade resolvem isso, mas é plataforma demais para uma pergunta que geralmente se resume a quatro ou cinco números indo na direção errada.

Ler em:
Execução 1 Execução 2 Execução 3 Execução 4 Execução 5 Execução 6
Uma tendência que vale a pena pegar cedo — sobe de forma constante, execução após execução, bem antes de virar um incidente.

A maioria dos incidentes de pipeline não começa como incidente — começa como uma tendência lenta que ninguém estava observando até cruzar algum limite e virar uma emergência. Você não precisa de uma plataforma completa de observabilidade para pegar a tendência cedo; precisa estar observando o punhado certo de sinais.

O punhado de métricas que realmente preveem problemas

  • Tempo de GC como % do tempo de task (Spark) — subindo de forma constante em execuções consecutivas prevê um OOM antes que aconteça, muitas vezes semanas antes da falha real.
  • Tendência de duração de checkpoint (Flink) — tempo de checkpoint crescendo prevê futuros timeouts de checkpoint e os reinícios de job que seguem, bem antes do primeiro timeout real acontecer.
  • Bytes de spill de shuffle (Spark) — uma alta lenta aqui significa que o dimensionamento das suas shuffle partitions não acompanhou o crescimento dos dados, bem antes de virar uma regressão de tempo de execução de várias horas.
  • Elapsed time vs. contagem de linhas, por modelo (dbt) — se essa razão piora execução após execução, um modelo está escalando pior que linearmente com o crescimento dos seus dados, e vai continuar piorando.

Tendência vale mais que limite fixo

Um limite de alerta fixo ("me avise se o tempo de execução passar de 30 minutos") só dispara depois que o problema já é real. Comparar cada execução contra uma linha de base móvel das execuções recentes pega a tendência enquanto ela ainda é pequena e barata de corrigir — a mesma métrica, usada proativamente em vez de reativamente, perguntando "isso está pior que as últimas N execuções" em vez de "isso cruzou uma linha arbitrária".

Você não precisa de todas as métricas — precisa do punhado certo, rastreado de forma consistente

A tentação em observabilidade é instrumentar tudo. A abordagem mais duradoura para um time pequeno: escolha o punhado de métricas acima específico para o seu tipo de pipeline, rastreie-as em cada execução (não só quando algo parece errado), e trate uma tendência ruim em qualquer uma delas como algo que vale a pena olhar — bem antes de valer a pena um chamado de emergência.

Como isso é hoje no opti-pipe: cada upload se soma ao histórico de métricas daquele pipeline, e as regras de memória/número de instâncias já são reavaliadas contra o histórico acumulado em vez de um único snapshot — então uma recomendação pode disparar novamente com uma sugestão ajustada conforme as tendências mudam, não só na primeira vez que um limite é cruzado. Uma funcionalidade dedicada de alertas proativos (avisar antes mesmo de você pensar em checar) está na lista, mas ainda não foi implementada — veja o artigo acima sobre a lacuna dev-vs-produção para outro caso na mesma categoria.

Veja como isso fica no seu próprio pipeline.

Envie um event log real do Spark, um run_results.json do dbt, ou uma exportação de métricas do Flink, e receba recomendações concretas para aprovar — não mais uma regra de bolso.