O prometheus grafana virou a combinação padrão de monitoramento em ambientes cloud native, e vale entender o que ela entrega de verdade antes de colocá-la em produção. Neste review técnico, analiso a arquitetura, os pontos fortes, as limitações e os cenários em que a stack faz sentido para donos de SaaS e times de infraestrutura, sem números de benchmark inventados.
Como o prometheus grafana funciona na arquitetura
O Prometheus é um banco de séries temporais com coleta no modelo pull: o servidor consulta periodicamente endpoints HTTP (normalmente /metrics) expostos pelas aplicações e exporters, em um formato de texto simples. O Grafana entra como camada de visualização, consultando o Prometheus como data source via PromQL. O alerta fica a cargo do Alertmanager, um componente separado que agrupa, deduplica e roteia notificações.
Esse desenho tem uma consequência prática: se o alvo não responde, a própria coleta falha e a métrica up vai a zero. Você ganha um sinal de disponibilidade quase de graça, algo que modelos push não entregam com a mesma simplicidade.
Componentes principais
- Prometheus server: faz scrape, armazena em TSDB local e avalia regras de gravação e alerta.
- Exporters: traduzem métricas de sistemas terceiros, como node_exporter para hosts e exporters de bancos de dados.
- Alertmanager: roteia alertas para e-mail, chat ou ferramentas de on-call.
- Grafana: dashboards, exploração de dados e alertas visuais.
- Service discovery: em Kubernetes, descobre pods e serviços via API, evitando listas estáticas de IPs.
Exemplo de configuração mínima
O trecho abaixo mostra um job de scrape estático e uma regra de alerta para indisponibilidade de alvo:
# prometheus.yml
global:
scrape_interval: 15s
scrape_configs:
- job_name: api
metrics_path: /metrics
static_configs:
- targets: ['api:8080']
# regras de alerta
groups:
- name: disponibilidade
rules:
- alert: AlvoIndisponivel
expr: up == 0
for: 2m
labels:
severity: critical
annotations:
summary: 'Alvo {{ $labels.instance }} fora do ar'Para latência, um padrão comum em PromQL é calcular percentis a partir de histogramas:
histogram_quantile(0.95,
sum by (le) (rate(http_request_duration_seconds_bucket[5m])))Prós e contras reais do prometheus grafana
Pontos fortes
- Modelo de dados dimensional: labels permitem fatiar métricas por serviço, rota, versão ou cliente com consultas expressivas.
- PromQL: linguagem poderosa para taxas, agregações e SLIs, embora exija curva de aprendizado.
- Ecossistema: há exporters e bibliotecas de instrumentação para a maioria das linguagens e componentes de infraestrutura.
- Integração com Kubernetes: service discovery nativo e operadores que padronizam a instalação.
- Código aberto e portável: reduz lock-in em relação a plataformas proprietárias de APM.
Limitações que você precisa planejar
- Cardinalidade: cada combinação única de labels cria uma série nova. Usar ID de usuário ou de requisição como label é o erro clássico que derruba memória e desempenho.
- Armazenamento local: o TSDB não é distribuído por padrão. Alta disponibilidade costuma significar duas réplicas independentes coletando os mesmos alvos.
- Retenção de longo prazo: exige remote write para soluções como Thanos, Mimir ou VictoriaMetrics, o que adiciona complexidade operacional.
- Escopo restrito: a stack cobre métricas. Logs e traces pedem ferramentas complementares, como Loki e Tempo, ou outros backends compatíveis com OpenTelemetry.
- Jobs de curta duração: tarefas efêmeras podem terminar antes do scrape e dependem do Pushgateway, que deve ser usado com cautela.
Na prática, o custo real de prometheus grafana raramente está na licença, que não existe, e sim em horas de engenharia para operar, versionar dashboards e manter a higiene das métricas.
Quando adotar e quando evitar
A stack prometheus grafana é uma ótima escolha quando você roda workloads em Kubernetes ou containers, precisa de SLOs baseados em métricas e tem ao menos uma pessoa capaz de cuidar da plataforma. Para um SaaS em crescimento, ela oferece visibilidade de latência, taxa de erro e saturação (os sinais dourados) sem depender de contratos de APM caros.
Evite adotá-la por impulso se o time é muito pequeno, se a infraestrutura é uma única VM com baixa complexidade ou se o principal problema é investigar erros pontuais, caso em que logs e tracing entregam mais valor. Nesses casos, um serviço gerenciado compatível com Prometheus pode reduzir o peso operacional mantendo o mesmo PromQL.
Boas práticas para começar
- Defina primeiro os SLIs (disponibilidade, latência, erros) e só depois monte dashboards.
- Padronize nomes de métricas e labels e revise a cardinalidade antes de cada release.
- Use regras de gravação para consultas pesadas que alimentam dashboards frequentes.
- Versione dashboards e regras de alerta como código, em Git, com revisão de pull request.
- Alerte sobre sintomas que afetam o usuário, não sobre cada métrica de CPU.
Há ainda um ganho de negócio pouco explorado: maturidade operacional vira conteúdo. Status pages, post-mortems e métricas de confiabilidade alimentam a comunicação com clientes, e isso se conecta ao que explico em calendário editorial para SaaS. Para amarrar essa narrativa ao posicionamento, vale ver também as dicas de marketing digital para donos de SaaS e empresas de TI.
Conclusão
O prometheus grafana não é uma solução completa de observabilidade, mas é uma base sólida, aberta e madura para métricas e alertas. Seu retorno aparece quando o time controla a cardinalidade, define SLOs claros e planeja retenção e alta disponibilidade desde o início. Se esse é o seu cenário, comece pequeno, instrumente os serviços críticos e evolua a stack conforme a operação exigir.
