Monitoramento baseado em métricas ou em checagens: como decidir a arquitetura de coleta
Autor: Pedro Tebaldi PM do KeepGreen
Revisão técnica: Ednilson Correa SREO painel do plantão está verde. Mesmo assim o telefone toca: o ERP leva quatro minutos para gravar um pedido. A checagem de disponibilidade respondeu OK nas últimas mil execuções, porque ela pergunta se a porta responde. Ela nunca perguntou quanto tempo a resposta levou.
Esse é o ponto em que a arquitetura de coleta deixa de ser detalhe de implantação. As duas famílias resolvem problemas diferentes, cobram preços diferentes e falham de maneiras diferentes.
Este guia trata da escolha entre elas, não da definição de cada uma. Portanto, o que vem a seguir é critério. Onde cada arquitetura calcula o veredito, o que a checagem não responde, quando a migração compensa e qual conta chega depois.
Qual é a diferença entre monitoramento baseado em métricas e baseado em checagens?
O monitoramento baseado em métricas separa a coleta do julgamento: o agente entrega o número bruto, a plataforma decide o estado na hora da consulta. Já o monitoramento baseado em checagens junta as duas coisas dentro do plug-in, que interpreta o retorno e devolve o veredito pronto.
Na prática, o plug-in acessa o alvo, lê o valor e classifica sozinho o resultado como OK, WARNING ou CRITICAL. Quem decide a saúde do serviço é o script, não a plataforma.
A consequência dessa separação aparece no dia em que alguém pede para mudar um limiar. Na arquitetura de checagem, o limiar mora dentro do plug-in ou no argumento da definição do serviço. Mudar exige tocar na coleta, versionar o script e redistribuir para os coletores.
Na arquitetura de métricas, o limiar mora na consulta. O dado já está armazenado como série temporal, então a regra de alerta é reescrita sem encostar em quem coleta. Esse detalhe operacional explica boa parte da diferença de velocidade entre as duas equipes.
Outro ponto separa as duas na origem. O sistema de checagem nasceu para gerenciar alarme e notificação; guardar número é efeito colateral. O sistema de métricas nasceu para armazenar e consultar séries. Nele o alarme é um caso de uso, ao lado de tendência, capacidade e análise de incidente.
| Dimensão | Baseado em checagens | Baseado em métricas |
|---|---|---|
| Onde o estado é decidido | No plug-in, durante a coleta | Na consulta, sobre a série já armazenada |
| Histórico do dado bruto | Descartado ou reduzido a gráfico | Série completa dentro da retenção |
| Correlação entre sinais | Cada checagem enxerga só a si mesma | A consulta combina séries de origens distintas |
| Custo de mudar um limiar | Versão nova do plug-in nos coletores | Edição da consulta, sem tocar na coleta |
| Esforço de instrumentação | Plug-in pronto resolve o alvo comum | Exige exporter ou aplicação instrumentada |
| A conta que cresce | nº de checagens |
cardinalidade × retenção |
O modelo de dados da coluna da direita está na documentação oficial do projeto Prometheus. Ele é simples: nome da série mais um conjunto de rótulos. Cada combinação distinta forma uma série própria, detalhe que reaparece na conta de cardinalidade.
O que uma checagem não consegue responder
A limitação da checagem não está na qualidade do plug-in. Está no escopo do que ele enxerga: um alvo, um instante, nenhum vizinho. Quatro perguntas caem fora desse escopo. São justamente as que aparecem durante um incidente.
| Pergunta | Por que a checagem não responde | O que muda com série temporal |
|---|---|---|
| Isto é normal para uma terça-feira? | O plug-in é sem estado: compara com o limiar, nunca com o próprio passado | Linha de base por dia da semana e por faixa de horário |
| Quando isso estoura? | Só existe estado atual; não há inclinação para projetar | Projeção de esgotamento antes do limiar ser rompido |
| Isso tem relação com aquilo? | Cada plug-in roda isolado, sem acesso ao resultado dos outros | Consulta que cruza latência, fila de banco e descarte de pacotes |
| Quantos usuários sentiram? | O veredito é binário por alvo, sem noção de distribuição | Percentil p95 e p99 sobre a mesma população |
A terceira linha explica a maior parte da fadiga que um NOC acumula. Quando um roteador cai, a checagem dispara o alarme dele e mais os alarmes de tudo o que estava atrás. O operador recebe quarenta notificações de um único evento, sem hierarquia entre elas.
Com séries armazenadas, a regra consegue exigir a coincidência de dois sinais antes de acordar alguém. Esse é o mecanismo por trás da redução da fadiga de alertas em operações 24×7: menos notificação por evento, não notificação mais bonita.
A segunda linha resolve outro problema conhecido. Alertar quando o disco chega a 90% avisa tarde, na madrugada, fora da janela de manutenção. Alertar quando a inclinação da série projeta saturação em sete dias devolve o incidente ao horário comercial.
Push ou pull: como o número chega até o coletor
Dentro do modelo de métricas ainda existe uma escolha de transporte. No pull, o servidor busca o dado em intervalos definidos, varrendo endpoints que ele conhece de antemão. No push, o alvo envia a medição para um receptor, no ritmo dele.
A diferença prática é de governança. O pull dá ao servidor a lista fechada de quem ele coleta. Isso torna previsível o dimensionamento do coletor e simples a detecção de alvo mudo. Um alvo que parou de responder vira sinal explícito, sem depender de ninguém avisar.
O push cobre o que o pull não alcança. Entram aí job efêmero que termina antes da varredura, função serverless, dispositivo atrás de NAT e borda sem rota de entrada. Em compensação, o receptor precisa aguentar o pico de quem envia tudo ao mesmo tempo.
Na prática as duas convivem. Uma implantação de coleta por varredura com Prometheus dentro do datacenter costuma andar junto de um caminho de push para a borda. Escolher um lado por doutrina custa caro; escolher por natureza do alvo, não.
Quando a migração para métricas paga o próprio custo
Trocar de arquitetura tem preço: instrumentação, armazenamento, curva de aprendizado da linguagem de consulta e revisão de todas as regras de alerta. Antes de assinar essa conta, vale medir se o ambiente já está pedindo a troca.
Sinais de que a checagem chegou ao limite
Três sintomas aparecem juntos com frequência. Primeiro, a equipe abre o gráfico e não consegue responder se o número de agora é alto, porque não há histórico comparável na mesma granularidade.
Depois, o pós-mortem trava na frase “não dá para saber o que acontecia às 3h12”, já que o dado daquele instante nunca foi guardado. Por fim, cada pedido de limiar novo vira uma pequena entrega de software, com fila e janela.
Some a isso um quarto sinal, mais silencioso. O planejamento de capacidade dos recursos de TI vive em planilha, alimentada à mão. A ferramenta de monitoração não devolve série longa o suficiente para projetar crescimento.
Sinais de que trocar agora seria desperdício
Nem todo ambiente ganha com a mudança. Um parque de alvos padronizados, com plug-ins prontos e alertas estáveis, entrega disponibilidade sem instrumentação nova. Trocar essa base por métricas resolve um problema que ninguém tem.
Do mesmo modo, migrar antes de definir o que se pretende medir costuma produzir um repositório caro de séries que ninguém consulta. A ordem correta inverte isso: primeiro o conjunto de sinais que sustenta a decisão, depois a plataforma que os guarda.
Nesse ponto o guia de monitoramento de TI ajuda a fechar a lista de sinais por camada antes de qualquer decisão de ferramenta. Nossa equipe também tratou do assunto em vídeo, sobre como separar a métrica que sustenta decisão da que só enche painel.
O peso relativo dos sinais no mercado ajuda a calibrar a expectativa. A edição 2025 da pesquisa anual de observabilidade da Grafana Labs ouviu 1.255 profissionais. Nos resultados divulgados pelo publicador, métricas aparecem em 95% das operações, contra 87% de logs e 57% de traces.
As duas contas que chegam depois da migração
Quem migra descobre que o custo não está na licença. Ele está em duas grandezas que a arquitetura de checagem simplesmente não tinha.
Cardinalidade: a multiplicação silenciosa
Cada combinação distinta de rótulos cria uma série própria. Uma métrica de latência com 200 hosts, 20 endpoints e 5 códigos de status gera 20 mil séries. Acrescente um rótulo com o identificador da sessão do usuário e o número vira ilimitado.
Esse é o erro que parece certo no momento em que alguém o comete. Adicionar rótulo é barato na hora de instrumentar e caro na hora de armazenar. O detalhamento da conta, com as estratégias de corte, está no material sobre explosão de cardinalidade de métricas.
Regra prática de projeto: rótulo é para dimensão de baixa variação, como ambiente, região, serviço ou código de status. Identificador único de requisição, de usuário ou de sessão pertence ao trace ou ao log, jamais ao rótulo da métrica.
Retenção: quanto tempo guardar e por quê
A retenção não deveria ser um número escolhido por conforto. Ela decorre de dois compromissos concretos. O primeiro é a janela de apuração do SLA que a TI assinou. O segundo é o horizonte que o capacity planning precisa projetar.
Se o contrato apura disponibilidade por mês fechado, a série precisa sobreviver ao fechamento mais a auditoria. Se a projeção de crescimento olha um ano, alguma resolução tem que atravessar o ano inteiro. Duas faixas resolvem: alta resolução na janela curta de investigação, resolução reduzida na janela longa de tendência.
Ignorar esse desenho é o caminho mais comum para a conta de ingestão crescer sem que ninguém consiga apontar o responsável. O tema tem material próprio sobre controle de custos de observabilidade, incluindo o corte por valor de uso.
O mercado sente a mesma pressão. Na pesquisa citada acima, complexidade e custo aparecem como os dois maiores obstáculos de observabilidade, à frente de qualquer limitação técnica de ferramenta.
Como as duas arquiteturas convivem
A pergunta “os sistemas baseados em checagens ainda servem?” tem resposta curta: servem, principalmente como fonte de métrica. Um exporter lê o resultado das checagens existentes e o publica no formato de exposição que a plataforma de séries consome. O investimento em plug-in continua rendendo.
Esse arranjo tem uma vantagem que costuma decidir a discussão interna. A migração deixa de ser um evento de virada e passa a ser incremental. A camada de métricas sobe ao lado da que já existe, sem apagão de visibilidade nem congelamento do backlog.
A divisão de trabalho que funciona é simples. A checagem continua respondendo “está no ar?”, com plug-in pronto para o alvo comum. A métrica responde “está bom?”, “está piorando?” e “por quê?”. Uma delas guarda o portão; a outra explica o que aconteceu depois que ele foi cruzado.
Na operação do Instituto Butantan, o SESuite travava com lentidão de três a cinco minutos por operação. A resposta padrão era reiniciar o serviço ou aumentar hardware, porque a checagem insistia que o servidor estava no ar.
Instrumentamos consumo por processo, captura da query no SQL Server e traces de requisição, o que apontou a causa real em vez do sintoma. Veja o projeto de observabilidade no Instituto Butantan em detalhe.
O critério de alerta, aliás, não muda com a arquitetura. O capítulo sobre sistemas distribuídos do livro de SRE do Google insiste em um ponto. Alerte pelo sintoma que o usuário sente, não pela causa técnica que você suspeita.
A série temporal apenas torna esse conselho executável. O aprofundamento no dado em si fica em outro texto. O material sobre métricas na observabilidade cobre tipos de métrica, séries temporais e instrumentação via OpenTelemetry.
Logs, métricas e traces unificados para diagnóstico em profundidade.
Instrumentamos aplicações corporativas com OpenTelemetry para correlacionar eventos e acelerar a análise de causa raiz em produção.
Por onde começar na segunda-feira
A decisão entre as duas arquiteturas não se resolve escolhendo um vencedor. Ela se resolve sabendo qual pergunta a operação precisa responder e quanto custa manter a resposta disponível.
Comece pelo inventário do que hoje fica sem resposta durante um incidente. Se a lista contiver histórico, tendência ou correlação, a camada de métricas já tem justificativa. Em seguida, escolha um serviço crítico como piloto e defina os sinais antes da ferramenta. Trate cardinalidade e retenção como decisão de projeto, não como configuração padrão.
Mantenha a checagem no lugar dela durante a transição. Ela responde à pergunta binária com custo baixo. O exporter transforma esse investimento em insumo da nova camada em vez de sucata.
Quer acelerar essa transição com quem já fez isso em ambiente crítico? Fale com um especialista da OpServices e traga o seu inventário de sinais.
Perguntas Frequentes
Preciso trocar de ferramenta para adotar monitoramento baseado em métricas?
Push ou pull: qual modelo de coleta escolher?
Por quanto tempo guardar as métricas coletadas?
SLA acordado, somada ao prazo de auditoria do fechamento. O segundo é o horizonte que o capacity planning precisa projetar. O desenho usual separa duas faixas: alta resolução para investigação de incidente e resolução reduzida para tendência de longo prazo.O que é cardinalidade e por que ela encarece a operação?
O monitoramento baseado em checagens ficou obsoleto?
