Monitoramento de dados: quais verificações aplicar, onde colocar cada uma e como calibrar o limiar

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado dez/2019Atualizado ago/2026

Segunda-feira, 8h. O painel de vendas abre com o número de sexta. Ninguém foi avisado. O servidor está no ar, o job da madrugada terminou com status de sucesso e todos os alertas de infraestrutura seguem verdes.

O job realmente terminou bem. Ele apenas processou zero linha, porque a origem mudou o nome de uma coluna no fim de semana. Nada quebrou no sentido técnico. Só o dado ficou errado.

Esse tipo de falha não aparece em monitoração de servidor, de rede ou de banco. Ela exige uma camada própria de verificação, com perguntas próprias, limiares próprios e um dono próprio quando dispara.

O que é monitoramento de dados?

Monitoramento de dados é a vigilância contínua da saúde dos ativos de dados: frescor, volume, esquema, distribuição e unicidade das tabelas que alimentam decisão. Ele não olha o servidor. Ele pergunta se o dado chegou na hora, na quantidade esperada e no formato combinado.

A diferença para a monitoração tradicional está no objeto observado. A monitoração de infraestrutura vigia o processo que move o dado. Ela pergunta se o job rodou, se a CPU aguentou e se a conexão caiu. O monitoramento de dados vigia o resultado desse processo.

Um exemplo separa as duas de vez. O job que executa em 4 minutos em vez dos 40 habituais é um sucesso para a monitoração de infraestrutura. Para o monitoramento de dados, é um alarme: processar dez vezes mais rápido quase sempre significa processar dez vezes menos linhas.

A camada conceitual desse assunto, com os pilares, a arquitetura de referência e as categorias de ferramenta, está no guia de Data Observability. Este texto fica no nível de baixo: quais verificações escrever, onde colocá-las e com que limiar.

Por que o pipeline verde entrega número errado

A falha silenciosa acontece porque o pipeline valida a execução, não o conteúdo. Quatro modos de falha respondem pela maior parte das ocorrências. Nenhum deles derruba um serviço.

O primeiro é a origem que muda sem avisar. Um sistema transacional renomeia uma coluna, troca o formato de data ou passa a enviar o CPF com máscara. A carga continua rodando. O campo chega vazio ou o registro morre na transformação.

Vem depois a carga parcial. A janela de extração fecha antes de a origem terminar de gravar, então o lote traz metade do dia. O total do relatório cai sem que nenhuma exceção seja levantada.

Em terceiro lugar aparece a duplicidade por reprocessamento. Alguém roda de novo a carga que falhou no meio, sem chave de idempotência. O faturamento passa a ser contado duas vezes.

Fecha a lista a dependência que atrasa. A tabela final depende de outras seis. Uma delas não chegou, o modelo foi construído com o que estava disponível. O resultado é um número coerente consigo mesmo, porém errado.

Esse conjunto explica um dado do mercado. A dbt Labs publicou em 2025 um levantamento com 459 profissionais da área. Nele, a má qualidade dos dados foi o problema mais citado, por 56% dos entrevistados.

As seis verificações que pegam a maior parte das quebras

Cada modo de falha acima tem uma verificação correspondente. As seis abaixo cobrem o grosso das ocorrências em um ambiente típico. Nenhuma delas exige plataforma proprietária.

Os limiares da terceira coluna são pontos de partida, não verdades universais. Calibre cada um contra a linha de base da sua própria tabela, conforme a seção seguinte. Vale dizer que nenhuma delas depende de linguagem específica: todas são consultas sobre a própria tabela.

 
Documentar a qualidade do dado não é prática nova nem invenção de fornecedor. A recomendação do W3C sobre publicação de dados na web já trata disso em boas práticas próprias. Elas cobrem informar a qualidade, versionar o conjunto e descrever a estrutura.

Na implementação, a documentação de um framework aberto de validação mostra que as seis viram código declarativo, versionado junto do pipeline. Comprar plataforma antes de escrever a primeira verificação inverte a ordem.

Onde cada verificação entra no fluxo

Colocar todas as verificações no fim é o erro mais comum. Quando a validação roda só antes do consumo, o time descobre o problema tarde. Ele já pagou pelo processamento inteiro, sem saber em que etapa o dado torceu.

Na origem, logo após a ingestão

Aqui entram esquema e frescor. São as duas que apontam para fora da equipe: mudança de contrato e atraso de quem envia. Detectar cedo permite parar o pipeline antes de propagar o defeito.

Essa é também a única posição em que a verificação de esquema tem valor de prevenção. Depois da transformação, a coluna renomeada já virou campo nulo. A informação sobre a causa se perdeu no caminho.

Vale transformar essa verificação em acordo explícito com quem envia o dado. Um contrato simples resolve boa parte disso: lista de campos, tipos e prazo de entrega. Dessa forma, em vez de descobrir a mudança pelo relatório quebrado, a equipe cobra o aviso prévio combinado.

Depois da transformação

Aqui entram volume, unicidade e integridade referencial. São verificações sobre a lógica que o time controla, então uma falha aponta para dentro: regra de junção errada, reprocessamento sem idempotência, filtro mal ajustado.

O passo depende do desenho do fluxo. A arquitetura que decide onde essas etapas ficam, incluindo a escolha entre lote e streaming, está detalhada no material sobre pipeline de dados.

Antes do consumo

Aqui entra a verificação de sanidade de negócio, a única que não é genérica. Faturamento negativo, pedido sem cliente, soma das partes diferente do total consolidado. Uma regra por indicador crítico basta para começar.

O consumo é onde a quebra fica cara. Um número errado que chega ao painel executivo já produziu decisão antes de alguém notar. Por isso o retrabalho de confiança custa mais que o de processamento. Essa ponta está tratada no guia de business intelligence.

Como calibrar o limiar sem afogar o time em alerta

Uma verificação mal calibrada é pior que nenhuma. Ela ensina o time a ignorar o canal. A partir daí, o alerta verdadeiro passa despercebido junto com os falsos.

Três ajustes resolvem a maior parte do ruído. O primeiro é medir a linha de base antes de definir o número. Rode a verificação em modo silencioso por duas ou três semanas e registre a variação real da tabela.

Depois, separe por sazonalidade. Volume de segunda-feira não se compara com volume de domingo. Fechamento de mês distorce qualquer média simples, então compare cada dia com o mesmo dia das semanas anteriores.

O terceiro ajuste é a janela de sustentação. Uma tabela que atrasa três minutos e se recupera sozinha não precisa acordar ninguém. Exija que a condição persista por um intervalo antes de virar notificação.

Esse cuidado é o mesmo que a operação de infraestrutura já aprendeu a ter. Os mecanismos de supressão, correlação e agrupamento estão descritos no material sobre fadiga de alertas. Eles valem sem adaptação para a camada de dados.

Um detalhe de modelagem também reduz falso positivo. Tabelas com estrutura inconsistente geram variação artificial nas verificações de nulo e de unicidade. Antes de culpar o limiar, revise as decisões de normalização de dados.

O que não vale a pena monitorar

Cobrir tudo é a forma mais rápida de não cobrir nada. Uma verificação em cada coluna de cada tabela produz milhares de sinais. Ninguém consegue distinguir o relevante no meio disso.

Três cortes definem o escopo inicial. Tabela intermediária, usada apenas como passagem entre duas etapas, dispensa verificação própria: o defeito dela reaparece na tabela final, que já está vigiada.

Coluna que ninguém consome também fica de fora. Antes de escrever a regra, confirme se algum relatório, modelo ou API lê aquele campo. Campo morto gera alerta que não muda decisão nenhuma.

Fica de fora, ainda, a tabela sem dono. Ela não deve ganhar verificação antes de ganhar responsável, porque o alerta cairia onde ninguém tem obrigação de responder. Nesse caso o trabalho correto é atribuir o dono primeiro.

Além disso, cada verificação tem custo de execução. Uma consulta de unicidade sobre uma tabela de bilhões de linhas roda a cada carga e aparece na fatura do armazém no fim do mês. Por isso, tabela grande pede amostragem ou janela incremental, em vez de varredura completa.

Sobra um critério simples. Monitore a tabela pela consequência de ela estar errada, começando pelas que sustentam decisão de dinheiro ou obrigação legal.

Quem atende quando o dado quebra

Essa é a pergunta que quase nenhum material responde. Um alerta de dado sem dono declarado vira mensagem em canal coletivo. Mensagem em canal coletivo não tem prazo de atendimento nem responsável.

O caminho que funciona trata a quebra de dado como incidente, com severidade atribuída pelo uso do dado, não pelo tamanho da tabela. Em síntese, a severidade responde a uma pergunta só: quem decide errado se esse dado ficar parado por mais um dia?

 
Definir esse quadro exige saber quem responde por cada tabela, o que é trabalho de governança de dados. Sem dono declarado, a tabela de severidade fica bonita no papel e vazia na prática.

O mapa de dependências completa o desenho. Saber quais painéis bebem de uma tabela permite calcular o raio de impacto no momento do incidente. Sem isso, a equipe descobre o alcance da quebra pelo telefone, conforme as áreas ligam.

Falta ainda a ponte com a camada de baixo. Boa parte das quebras de frescor não nasce no pipeline. Ela nasce em atraso de replicação, disco cheio ou lock prolongado no banco de origem, território do monitoramento de banco de dados.

Nas Lojas Marisa, monitoramos as 433 lojas a partir do datacenter, com os bancos Oracle acompanhados por indicadores de performance, disponibilidade, armazenamento e replicação. Quando a replicação atrasa, o sintoma aparece primeiro como tabela desatualizada no relatório, não como servidor fora do ar.

Ter as duas camadas no mesmo painel permite responder em minutos se a causa está no dado ou na infraestrutura. Veja o projeto de monitoração das Lojas Marisa em detalhe.

O primeiro ciclo cabe em uma semana

Nada disso precisa de projeto anual. Escolha as três tabelas que sustentam os indicadores mais consultados da empresa e comece por elas.

No primeiro dia, ligue frescor e volume em modo silencioso. Ao longo da semana, registre a variação real e transforme a linha de base observada em limiar. Só então ative a notificação, já com a janela de sustentação definida.

Em seguida, acrescente esquema na ingestão dessas mesmas três tabelas e atribua um dono a cada uma. Com isso a operação sai do zero e passa a descobrir a quebra antes do usuário. Essa é a única métrica que importa nessa fase.

Em contrapartida, resista à tentação de ligar as seis verificações de uma vez. Duas bem calibradas geram mais confiança que seis mal ajustadas, sobretudo porque o time aprende a acreditar no canal desde o começo.

Depois disso, a expansão é repetição: mais tabelas, mesma receita. A estruturação do fluxo inteiro, da coleta à disponibilização, é o trabalho descrito no serviço de engenharia de dados e BI.

Quer montar esse primeiro ciclo com quem opera monitoração e dados no mesmo time? Fale com um especialista da OpServices e traga a lista das suas tabelas críticas.