O monitoramento com Prometheus se tornou padrão de fato para quem opera SaaS em containers e Kubernetes. Neste review técnico, olho a ferramenta como ela é em produção: como coleta dados, onde brilha, onde cobra um preço operacional e em quais cenários vale a pena adotá-la ou combiná-la com outras peças.
Como o Prometheus funciona de verdade
O Prometheus é um projeto da CNCF, com status graduated, que combina coletor, banco de séries temporais (TSDB) local, linguagem de consulta (PromQL) e motor de regras. A decisão de arquitetura mais importante é o modelo pull: o servidor faz scrape via HTTP em endpoints /metrics, em vez de esperar que a aplicação envie dados.
No monitoramento com Prometheus, cada alvo expõe métricas em formato de texto, e o servidor as armazena como séries identificadas por nome e labels. Isso traz benefícios concretos:
- Saúde do alvo gratuita: a métrica
upindica se o scrape funcionou, o que já funciona como health check. - Service discovery: integração nativa com Kubernetes, Consul, EC2 e arquivos, sem cadastro manual de hosts.
- Tipos de métrica claros: counter, gauge, histogram e summary, que moldam como você escreve as consultas.
Para o que não é possível raspar, como jobs batch de curta duração, existe o Pushgateway. Ele é útil, mas deve ser exceção, não regra.
Pontos fortes na prática
PromQL e consultas operacionais
A PromQL é o grande diferencial. Funções como rate(), increase() e histogram_quantile(), somadas a agregações por label, permitem calcular taxa de erro, latência por percentil e saturação diretamente no servidor. Para equipes que trabalham com SLOs, essa base é sólida.
Ecossistema de exporters
Há exporters maduros para quase tudo: node_exporter para hosts Linux, kube-state-metrics para o estado dos objetos Kubernetes, blackbox_exporter para sondas HTTP/TCP e exporters para bancos de dados. Se você está decidindo a camada de dados, vale ler o comparativo técnico entre PostgreSQL e MySQL, porque ambos têm exporters que ajudam a observar replicação, conexões e locks.
Alertas com Alertmanager
As regras de alerta são avaliadas no Prometheus, e o Alertmanager cuida de agrupamento, deduplicação, inibição, silenciamento e roteamento para Slack, e-mail ou PagerDuty. Separar avaliação de notificação evita tempestade de alertas e dá controle fino sobre quem acorda de madrugada.
Limitações e trade-offs que ninguém deve ignorar
Um erro comum no monitoramento com Prometheus é achar que ele resolve toda a observabilidade. Ele trata métricas. Logs e traces exigem outras ferramentas, como Loki, Tempo ou stacks equivalentes.
- Escala vertical por padrão: um servidor Prometheus não é um cluster. Alta disponibilidade costuma ser feita com duas réplicas idênticas fazendo scrape dos mesmos alvos.
- Retenção local limitada: o padrão é 15 dias (
--storage.tsdb.retention.time). Para histórico longo, o caminho é remote write para Thanos, Mimir, VictoriaMetrics ou serviço gerenciado. - Cardinalidade: labels com valores ilimitados, como ID de usuário, URL completa ou ID de requisição, multiplicam séries e consomem memória. É o principal motivo de instâncias que caem por falta de RAM.
- Dados não são perfeitos: o modelo de scrape amostra o estado em intervalos, então eventos mais curtos que o intervalo podem passar despercebidos.
Há também o custo indireto. Armazenamento de longo prazo, tráfego entre zonas e volumes de disco entram na conta de infraestrutura. Quem já se preocupa com isso encontra boas práticas no guia custo de cloud: como reduzir até 70% sem perder performance, que ajuda a pensar retenção e arquitetura com disciplina financeira.
Exemplo de configuração mínima
Um setup mínimo de monitoramento com Prometheus tem um prometheus.yml com intervalo de scrape, alvos e arquivo de regras:
global:\n scrape_interval: 30s\n evaluation_interval: 30s\n\nrule_files:\n - rules.yml\n\nscrape_configs:\n - job_name: node\n static_configs:\n - targets: ['10.0.0.10:9100']\n - job_name: api\n metrics_path: /metrics\n static_configs:\n - targets: ['api:8080']E uma regra de alerta simples para detectar alvo fora do ar:
groups:\n - name: basico\n rules:\n - alert: InstanciaIndisponivel\n expr: up == 0\n for: 3m\n labels:\n severity: critical\n annotations:\n summary: 'Alvo {{ $labels.instance }} fora do ar'O campo for é importante: ele evita alertas por falhas transitórias e reduz ruído. Em produção, o ideal é alertar por sintomas (erro e latência percebidos pelo usuário) e usar métricas de causa para diagnóstico.
Quando adotar e quando buscar alternativa
Adote o monitoramento com Prometheus se você roda Kubernetes ou containers, tem equipe técnica capaz de manter a stack e quer evitar lock-in de fornecedor. O formato de exposição é aberto, e o ecossistema com Grafana para dashboards é amplo e bem documentado.
Considere alternativas ou um serviço gerenciado quando a equipe é pequena demais para operar storage de longo prazo, quando a cardinalidade é naturalmente alta ou quando você precisa de métricas, logs e traces correlacionados em uma única interface sem montar a integração. Um bom caminho intermediário é manter o Prometheus como coletor e enviar dados por remote write para um backend escalável.
Algumas boas práticas valem para qualquer cenário:
- Defina convenções de nomes e labels antes de instrumentar.
- Use histogramas para latência, em vez de médias.
- Revise regularmente as séries de maior cardinalidade.
- Versione regras e dashboards como código, no mesmo pipeline da infraestrutura.
Conclusão
O monitoramento com Prometheus entrega um núcleo técnico excelente: modelo pull simples, PromQL expressiva e alertas bem desenhados. Em troca, exige atenção a cardinalidade, retenção e alta disponibilidade. Para donos de SaaS e times de TI com maturidade em containers, é uma base confiável. Basta tratá-lo como uma peça da observabilidade, não como a solução inteira.
