O monitoramento com Prometheus se tornou o padrão de fato para métricas em ambientes containerizados, mas isso não significa que seja a escolha certa para todo cenário. Neste review técnico, analiso a arquitetura, os pontos fortes, as limitações reais e os trade-offs que times de TI e donos de SaaS precisam considerar antes de colocá-lo em produção.
Como funciona o monitoramento com Prometheus na prática
O Prometheus adota um modelo pull: o servidor consulta periodicamente endpoints HTTP (geralmente /metrics) expostos pelas aplicações e exporters. Os dados são gravados em um banco de séries temporais (TSDB) local, indexado por nome da métrica e pares de labels. Essa decisão de design simplifica a detecção de alvos fora do ar, pois uma falha de scrape já é um sinal por si só (a métrica up).
Componentes principais
- Prometheus Server: faz o scrape, armazena as séries e avalia regras.
- Exporters: como
node_exporterpara hosts ekube-state-metricspara o estado de objetos do Kubernetes. - Alertmanager: agrupa, deduplica, silencia e roteia alertas para Slack, e-mail ou PagerDuty.
- Service discovery: integração nativa com Kubernetes, Consul, DNS e outros, evitando listas estáticas de alvos.
- PromQL: linguagem de consulta funcional para agregações, taxas e cálculo de percentis a partir de histogramas.
Um exemplo mínimo de configuração com descoberta de pods no Kubernetes:
global:
scrape_interval: 30s
evaluation_interval: 30s
scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: trueO bloco relabel_configs é onde muita gente tropeça. Ele define quais alvos entram e quais labels são preservadas, e é um dos principais controles de custo e de cardinalidade.
Pontos fortes do monitoramento com Prometheus
Em times que já operam Kubernetes, o ganho é imediato. A integração com service discovery reduz trabalho manual, e o ecossistema de exporters cobre bancos de dados, proxies, filas e hardware. A PromQL permite expressar SLIs diretamente na consulta, como a taxa de erros por serviço:
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))Outro ponto positivo é a operação simples de uma instância única: um binário, configuração declarativa em YAML e nenhuma dependência externa obrigatória. Isso combina bem com versionamento em Git e provisionamento automatizado. Se você já trata sua infraestrutura de forma declarativa, vale ler o review técnico do Terraform para times de TI e aplicar a mesma disciplina às regras e aos alvos de monitoramento.
As regras de alerta também seguem o modelo declarativo:
groups:
- name: api-alerts
rules:
- alert: AltaTaxaDeErros5xx
expr: |
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) > 0.05
for: 10m
labels:
severity: critical
annotations:
summary: Taxa de erros 5xx acima do limiteO parâmetro for evita alertas por picos transitórios, reduzindo ruído e fadiga de plantão.
Limitações e trade-offs que ninguém deveria ignorar
O monitoramento com Prometheus tem fronteiras claras, e conhecê-las evita retrabalho caro mais adiante.
- Escala horizontal: a instância padrão não é um banco distribuído. Para alta disponibilidade e retenção longa, é comum recorrer a
remote_writee soluções como Thanos, Mimir ou VictoriaMetrics, o que aumenta a complexidade operacional. - Cardinalidade: labels com valores ilimitados (ID de usuário, URL completa, ID de requisição) multiplicam séries e consomem memória rapidamente. É a causa mais comum de incidentes no próprio Prometheus.
- Escopo restrito a métricas: logs e traces exigem outras ferramentas, como Loki e Tempo ou OpenTelemetry. Observabilidade completa é uma stack, não um produto único.
- Jobs efêmeros: tarefas de curta duração podem terminar antes do scrape. O Pushgateway resolve alguns casos, mas deve ser usado com critério.
- Retenção local: o armazenamento em disco exige planejamento de volume, backup e política de retenção.
Na prática, a decisão não é "Prometheus ou nada", e sim até que ponto você consegue operá-lo sozinho antes de precisar de uma camada de longo prazo ou de um serviço gerenciado.
Quando adotar e como estruturar a implantação
O monitoramento com Prometheus faz mais sentido quando você tem workloads dinâmicos, múltiplos serviços e necessidade de alertas baseados em SLO. Em ambientes pequenos, com poucas VMs estáticas, uma solução gerenciada pode custar menos em horas de engenharia do que operar a stack inteira.
Algumas boas práticas para uma implantação saudável:
- Padronize nomes de métricas e labels desde o início, com convenções documentadas.
- Use histogramas para latência e evite calcular médias, que escondem a cauda da distribuição.
- Defina alertas por sintoma (erro e latência percebidos pelo usuário) e não apenas por causa (CPU alta).
- Monitore o próprio Prometheus: séries ativas, duração do scrape e uso de memória.
- Versione configuração e regras em Git, com revisão por pull request.
Também vale automatizar tarefas repetitivas ao redor da operação, como triagem de alertas e geração de relatórios. Escrevi sobre esse tipo de abordagem em como automatizar processos internos com IA sem depender de agência, e o raciocínio se aplica bem a rotinas de operação.
Conclusão
O Prometheus entrega muito valor quando usado dentro do seu escopo: métricas, alertas e integração nativa com Kubernetes. Os riscos aparecem em cardinalidade descontrolada e na tentativa de usá-lo como solução única de observabilidade. Para quem está construindo ou operando SaaS, o monitoramento com Prometheus é uma base sólida, desde que venha acompanhado de convenções claras, revisão de alertas e um plano realista de escala e retenção.
