O monitoramento com Prometheus virou padrão de fato em ambientes containerizados, e não é por acaso: o projeto resolve bem um problema específico, que é coletar e consultar métricas numéricas de séries temporais com baixo atrito operacional. Neste review técnico, olho para a ferramenta como alguém que opera infraestrutura e SaaS: o que ela entrega, onde ela dói e quando vale a pena adotá-la.
Como o monitoramento com Prometheus funciona por dentro
A arquitetura central é simples. O servidor Prometheus faz scrape via HTTP em endpoints /metrics expostos pelas aplicações ou por exporters, e grava as amostras em um TSDB local, com armazenamento em disco otimizado para séries temporais. Esse modelo pull é a principal diferença em relação a soluções baseadas em push.
No monitoramento com Prometheus, cada série é identificada por um nome de métrica e um conjunto de labels. Isso dá poder de consulta, mas também define o principal risco operacional, que veremos adiante. Os tipos de métrica mais usados são:
- Counter: valor que só cresce (requisições, erros); você consulta com
rate(). - Gauge: valor que sobe e desce (memória, itens em fila).
- Histogram: distribuição em buckets, útil para latência e para calcular quantis com
histogram_quantile(). - Summary: quantis calculados no cliente, sem agregação confiável entre instâncias.
Os componentes ao redor completam o ecossistema: Alertmanager para roteamento, agrupamento e silenciamento de alertas; service discovery (Kubernetes, Consul, DNS, arquivos) para descobrir alvos dinamicamente; e o Grafana como camada de visualização, já que a UI nativa serve mais para depuração de queries.
Pontos fortes na prática
- PromQL expressivo: permite agregar por label, calcular taxas, razões de erro e comparar janelas de tempo em uma única linguagem.
- Service discovery nativo: em Kubernetes, pods e serviços entram e saem do scrape sem edição manual.
- Detecção de alvo fora do ar: a métrica sintética
upé gerada a cada scrape, o que dá um health check quase gratuito. - Ecossistema de exporters: node_exporter, blackbox_exporter e exporters de bancos de dados cobrem boa parte da infraestrutura comum.
- Operação simples: um binário, configuração em YAML e sem dependência de banco externo para começar.
Limites e trade-offs que ninguém deve ignorar
O monitoramento com Prometheus não é uma plataforma de observabilidade completa. Ele cobre métricas; logs e traces exigem outras peças, como Loki e Tempo ou alternativas equivalentes. Tratar o Prometheus como solução única é um erro comum.
Cardinalidade de labels
Cada combinação única de labels cria uma nova série. Colocar user_id, request_id ou URLs com parâmetros em labels pode explodir o consumo de memória e degradar o servidor. É o problema mais frequente em produção e se resolve com disciplina de instrumentação, não com mais hardware.
Retenção e escala
O TSDB local é pensado para armazenamento de curto e médio prazo; a retenção padrão é de 15 dias. Para retenção longa, alta disponibilidade e visão global entre clusters, você precisa de remote write e de uma camada adicional, como Thanos, Mimir ou VictoriaMetrics. Isso adiciona complexidade e custo operacional, e vale decidir esse desenho antes de o ambiente crescer.
Modelo pull e redes restritas
O pull exige que o servidor alcance os alvos. Em redes segmentadas, jobs efêmeros ou ambientes atrás de NAT, o Pushgateway ou um agente com remote write pode ser necessário, com ressalvas: o Pushgateway não deve virar proxy genérico de métricas.
Exemplo de configuração mínima
Um ponto de partida funcional, com scrape de uma API e uma regra de alerta para alvo indisponível:
global:
scrape_interval: 30s
evaluation_interval: 30s
rule_files:
- alerts.yml
scrape_configs:
- job_name: api
metrics_path: /metrics
static_configs:
- targets: ['api:8080']
# alerts.yml
groups:
- name: disponibilidade
rules:
- alert: AlvoIndisponivel
expr: up{job='api'} == 0
for: 2m
labels:
severity: critical
annotations:
summary: 'API sem resposta ao scrape'O campo for evita alertas por oscilações curtas, e as labels de severidade alimentam o roteamento no Alertmanager. Se você roda a stack com contêineres, vale conferir as práticas de healthcheck, volumes e rollback no nosso tutorial de Docker Compose em produção para times de TI.
Quando adotar e quando buscar alternativa
Adote monitoramento com Prometheus quando:
- você opera Kubernetes ou serviços containerizados com alvos dinâmicos;
- precisa de alertas baseados em taxa de erro, latência e saturação;
- tem time capaz de manter o servidor, as regras e a disciplina de labels.
Considere alternativas ou serviços gerenciados quando:
- o time é pequeno e não quer operar armazenamento e alta disponibilidade;
- a retenção longa e a consulta global entre ambientes são requisito central;
- o foco principal é APM, logs e traces integrados em uma única interface.
Há também o fator financeiro. Plataformas gerenciadas em dólar podem pesar no orçamento conforme o volume de séries cresce. Para quem quer rever esse eixo, o artigo Custo de Cloud Estrangeiro: o que eu mudaria hoje para cortar até 70% mostra como atacar visibilidade e custo juntos.
Boas práticas para um ambiente sustentável
- Defina um orçamento de cardinalidade e revise métricas com mais séries periodicamente.
- Baseie alertas em sintomas (erro e latência percebidos pelo usuário), não só em causas como CPU.
- Use recording rules para pré-calcular consultas pesadas usadas em dashboards.
- Versione configuração e regras em Git e valide com
promtoolno pipeline. - Planeje backup e retenção antes do primeiro incidente, não depois.
Conclusão
O monitoramento com Prometheus entrega excelente custo-benefício técnico para métricas, com PromQL poderoso e integração madura com Kubernetes. Em contrapartida, exige governança de labels, plano de retenção e complementos para logs e traces. Se o seu time aceita essa responsabilidade, é uma base sólida; se não, avalie uma camada gerenciada e compare o custo total antes de decidir.
