Monitoramento de pipeline de dados: como parar de descobrir falhas pelo relatório desatualizado

Monitoramento de pipeline de dados: como parar de descobrir falhas pelo relatório desatualizado

Segunda-feira, cinco minutos antes da reunião de resultados. Alguém abre o dashboard de vendas e percebe que os números são de quinta-feira passada. Ninguém foi avisado. O job falhou em silêncio, o token da API expirou ou a máquina que rodava o script reiniciou, e o relatório continuou com cara de atualizado.

Esse cenário é muito comum em empresas que começaram a usar dados antes de ter uma área de dados formal. A ingestão nasce como um script de quem tinha um tempo livre, vira cinco scripts rodando em VMs e, quando alguém percebe, é infraestrutura crítica que ninguém monitora.

Pipeline quebrar é normal. APIs mudam, credenciais expiram, fontes ficam fora do ar. O problema é quando quem descobre primeiro é a diretoria, e não o time que cuida dos dados. Este guia mostra como montar um monitoramento de pipeline de dados que inverte essa ordem.

Por que pipelines de dados falham em silêncio

A maioria das falhas de ingestão não gera erro visível para quem consome o dado:

• Credencial ou token expirado: a chamada à API retorna 401, o script registra o erro num log que ninguém lê.
• Mudança de schema na origem: um campo é renomeado e a carga falha, ou pior, carrega com a coluna vazia.
• Rate limit: a API corta a extração no meio e o job termina "com sucesso" trazendo metade dos registros.
• Infraestrutura caseira: a VM reinicia, o cron não volta, e nada avisa que o agendamento parou.

Em todos esses casos, o dashboard continua carregando. Ele só mostra um dado velho.

Passo 1: faça o inventário de fontes e de quem depende delas

Antes de configurar qualquer alerta, liste todas as fontes de dados que alimentam o warehouse. Para cada uma, registre:

• Origem (ex: HubSpot, sistema financeiro, banco de produção)
• Destino (tabela ou dataset no warehouse)
• Frequência atual de atualização
• Quem é responsável pelo pipeline
• Quais relatórios e áreas consomem esse dado

Esse inventário revela o tamanho real do problema. É comum descobrir pipelines que ninguém lembra quem criou, ou fontes críticas para o financeiro rodando num script pessoal.

Passo 2: defina a frequência que cada dado realmente precisa

Nem todo dado precisa ser atualizado de hora em hora. O CRM que alimenta o time comercial pode precisar de atualização horária. Um sistema financeiro consultado no fechamento do mês pode rodar uma vez por dia. Fontes sem suporte a carga incremental (sem cursor por data de atualização) podem fazer mais sentido num refresh semanal.

Definir essa frequência esperada por fonte é o que transforma "o dado está atrasado?" numa pergunta com resposta objetiva. Sem esse acordo, não existe atraso, só achismo.

Passo 3: configure alertas de falha no canal onde o time já está

Alerta que depende de alguém abrir uma tela não é alerta. A falha precisa chegar onde o time já trabalha: Slack, e-mail, Discord ou a ferramenta de incidentes que vocês usam.

O alerta deve dizer, no mínimo, qual pipeline falhou, quando e qual foi o erro. Com isso, quem recebe consegue decidir em segundos se é algo transitório ou se precisa agir.

Se a ingestão roda numa ferramenta dedicada, isso costuma vir pronto. Na Erathos, por exemplo, qualquer job que falha dispara notificação por Slack, e-mail ou Discord, com o histórico de execuções de cada conector disponível para investigação. Para quem já tem uma stack de observabilidade, a API permite levar esses eventos para lá.

Passo 4: monitore o frescor do dado, não só o erro

Este é o passo que mais times esquecem. Um job pode terminar com status de sucesso e ainda assim trazer zero linhas, ou trazer dados de um período errado.

Para cobrir isso, monitore o frescor no próprio warehouse:

• Compare o maior valor de updated_at (ou equivalente) de cada tabela com a frequência definida no passo 2.
• Se você usa dbt, configure source freshness com limites de warn_after e error_after por fonte.
• Acompanhe o volume de linhas carregadas por execução. Uma queda brusca costuma indicar problema na origem.

Job verde não significa dado fresco. Os dois sinais juntos é que dão confiança.

Passo 5: tire a ingestão do código caseiro

Scripts próprios podem até funcionar no começo, mas toda a camada de retry, paginação, controle incremental, tratamento de rate limit e alerta fica por conta de quem escreveu. E quem escreveu quase sempre está ocupado com outra prioridade.

Vale fazer a conta: quanto tempo o time gasta mantendo conectores e investigando falhas, em vez de modelar dados e trabalhar com as áreas de negócio? Construir um conector robusto do zero costuma levar semanas. Mantê-lo funcionando é um custo que nunca acaba.

A Erathos tem mais de 100 conectores prontos (CRMs, ERPs, mídia paga e bancos como PostgreSQL, MySQL e MongoDB), entregando em BigQuery, Databricks, Redshift e S3. Quando a fonte não está no catálogo, o time constrói junto, inclusive conexões com APIs internas. Dá para testar por 14 dias, sem cartão de crédito.

Passo 6: crie uma rotina de resposta

Alerta sem dono vira ruído. Defina:

1. Quem recebe: uma pessoa ou um canal com responsável claro.
2. Primeiro diagnóstico: a próxima execução rodou normalmente? Se sim, foi uma falha transitória.
3. Quando escalar: se a falha se repete, investigar a origem ou acionar o fornecedor da ferramenta.
4. Como comunicar: se um dado crítico vai ficar atrasado, avisar as áreas consumidoras antes da reunião, e não depois.

Documente esse fluxo. Ele é o que garante que o monitoramento continua funcionando quando a pessoa que montou tirar férias.

Na prática: como a Convenia saiu do "descobre pelo relatório"

A Convenia, plataforma de gestão de RH que atende mais de 3.000 empresas, não tinha uma área de dados formal. A demanda ficava com o time de RevOps, e os pipelines rodavam soltos em VMs, sem nenhuma visibilidade. Pelo menos uma vez por semana, alguém descobria que um dado estava quebrado quando precisava dele para uma reunião.

Quando Bernardo Cardozo chegou para estruturar a área de dados, a Erathos foi sua primeira contratação. Hoje a Convenia centraliza HubSpot, Conta Azul, Google Ads, Facebook Ads, MongoDB, Vindi e a API interna de contabilidade no BigQuery, com o HubSpot atualizando de hora em hora e alertas de falha no Slack.

"Hoje, qualquer coisa que dá errado, cai uma notificação no Slack para mim. Eu olho se o próximo job de execução rodou, e se não consigo entender por quê, falo direto com o time da Erathos."
Bernardo Cardozo, Coordenador de Dados na Convenia

Os resultados:

• Cerca de 15 minutos para colocar uma nova fonte do catálogo fluindo até o BigQuery, contra a estimativa de cerca de um mês para construir do zero.
• 3 pessoas cuidando de toda a ingestão, modelagem e analytics de uma empresa de 150 funcionários, com o tempo do time redirecionado de manutenção de pipeline para governança.
• Cerca de R$147 mil de economia líquida por ano, aproximadamente 6 vezes o valor investido na Erathos.

Estimativa considerando o custo de um engenheiro de dados dedicado à ingestão (salário médio de mercado mais encargos CLT) ao longo de 12 meses, comparado ao investimento anual na Erathos.

Leia o case completo da Convenia

Comece agora

Monitorar pipeline de dados começa por tirar a ingestão de onde ninguém vê.

• Crie sua conta gratuita e teste por 14 dias, sem cartão de crédito.
• Agende uma conversa com um especialista para entender como a Erathos encaixa no seu stack.