Prometheus não é observabilidade
É comum ouvir que uma empresa “tem observabilidade” porque instalou Prometheus e Grafana. As duas ferramentas são excelentes, mas essa conclusão mistura ferramenta com capacidade operacional.
Prometheus coleta métricas. Grafana ajuda a visualizar dados. Nenhum dos dois, sozinho, responde às perguntas que aparecem quando um serviço fica lento, quando uma fila começa a crescer ou quando um deploy piora uma taxa de erro. Para isso, é preciso decidir o que medir, relacionar sinais e, principalmente, saber qual ação tomar quando algo sai do esperado.
Observabilidade não é uma tela cheia de gráficos verdes. É a capacidade de investigar o estado interno de um sistema a partir dos sinais que ele emite.
O que o Prometheus faz muito bem
O Prometheus foi feito para coletar séries temporais de métricas, consultá-las com PromQL e avaliar regras de alerta. Para workloads modernos, especialmente em Kubernetes, ele resolve uma parte importante do problema: centraliza números que antes ficariam espalhados em endpoints, agentes e planilhas improvisadas.
Ele é particularmente útil para acompanhar:
- uso de CPU, memória, disco e rede;
- quantidade de requisições, latência e erros HTTP;
- tamanho de filas, conexões abertas e pools de banco;
- métricas de negócio, como pagamentos aprovados ou arquivos processados;
- disponibilidade de endpoints por meio de exporters, como o Blackbox Exporter.
Ter esses dados é melhor do que operar no escuro. Mas coletar tudo indiscriminadamente também não é observabilidade. É só uma forma cara de acumular números.
O que fica faltando
Imagine que a latência de uma API subiu de 200 ms para 3 s. Um painel do Grafana confirma o sintoma. Ótimo. Agora começam as perguntas que realmente importam:
- a lentidão está em todas as rotas ou em uma específica?
- o problema começou após um deploy ou após uma alteração no banco?
- qual dependência está consumindo o tempo da requisição?
- quais usuários ou fluxos foram afetados?
- existe correlação com saturação de CPU, erros de DNS, conexões esgotadas ou mensagens paradas na fila?
Métricas ajudam a estreitar o caminho, mas dificilmente respondem a tudo sozinhas. Logs estruturados mostram eventos e contexto. Traces distribuídos mostram o percurso de uma requisição entre serviços. Eventos de deploy, mudanças de configuração e incidentes ajudam a explicar o que mudou no ambiente. Sem esses elementos, o diagnóstico continua dependendo de adivinhação e memória de quem está de plantão.
O modelo mais conhecido fala nos três pilares: métricas, logs e traces. Ele é útil como lembrete, desde que não vire mais um checklist vazio. Uma operação madura também precisa de contexto de mudança, ownership claro e procedimentos que conectem o alerta a uma decisão.
Métricas que servem para decidir
O erro mais recorrente não é a falta de métricas. É medir coisas que não orientam nenhuma ação. CPU em 72% pode ser perfeitamente normal. CPU em 72% acompanhada por aumento de fila, latência e erros de timeout já conta outra história.
Eu prefiro começar pelas perguntas operacionais e só depois escolher as métricas. Por exemplo:
| Pergunta | Sinais úteis |
|---|---|
| O usuário está conseguindo usar o serviço? | taxa de sucesso, latência, erros por rota, disponibilidade externa |
| O serviço aguenta a carga atual? | saturação, filas, conexões, uso de recursos e tempo de resposta |
| Uma dependência está falhando? | erros por destino, duração de chamadas, retries e timeouts |
| O deploy piorou algo? | comparação antes/depois, versão em execução e eventos de rollout |
Esse ponto de partida evita dashboards que mostram a mesma métrica em seis formatos diferentes, mas não mostram o impacto para quem usa o sistema.
Alertas não são dashboards com sirene
Outro sinal de pouca maturidade é alertar tudo. Um alerta precisa indicar uma situação acionável. “CPU alta” pode ser útil como diagnóstico, mas raramente deveria acordar alguém de madrugada sem relação com impacto real.
Alertas melhores combinam duração, severidade e consequência. Uma taxa de erro acima do normal durante alguns minutos, em uma operação crítica, merece atenção. Um Pod reiniciado uma vez pode ser apenas ruído. A própria documentação do Prometheus recomenda alertas que apontem diretamente para uma condição que precisa de intervenção humana.
Cada alerta deveria responder, antes de ser criado:
- Qual falha ou impacto ele representa?
- Quem é responsável por agir?
- O que essa pessoa consegue fazer ao recebê-lo?
- Onde está o procedimento de diagnóstico ou mitigação?
Quando não há resposta para essas perguntas, o alerta provavelmente deveria ser uma métrica no dashboard, não uma página para o plantão.
Um caminho prático
Não é necessário montar uma plataforma enorme para começar bem. Uma evolução razoável pode ser:
- definir os serviços e jornadas que realmente importam;
- instrumentar métricas de requisições, erros, duração e saturação;
- adotar logs estruturados com identificadores de correlação;
- incluir tracing nos fluxos que atravessam mais de um serviço;
- registrar deploys e mudanças relevantes ao lado dos gráficos;
- criar poucos alertas, ligados a impacto e a um runbook;
- revisar os sinais depois de incidentes reais.
O último item faz diferença. Incidentes mostram quais dados faltaram, quais gráficos enganaram e quais alertas só produziram barulho. A observabilidade melhora quando é tratada como parte da operação, não como uma entrega encerrada depois da instalação de uma stack.
Pensamento final
Prometheus continua sendo uma peça importante nesse desenho. Só não deve carregar uma responsabilidade que é maior do que ele. Instalar uma ferramenta é relativamente simples. Construir a capacidade de entender um sistema sob pressão é o trabalho de verdade.