Observabilidade com Prometheus é hoje um dos temas mais recorrentes entre times de TI que operam infraestrutura distribuída, containers e microsserviços. Depois de anos acompanhando implantações em ambientes de clientes da DevSkin e da Kubmix, este review reúne uma análise técnica honesta: como a ferramenta funciona por dentro, onde ela brilha e onde exige complementos para sustentar operações críticas.
Arquitetura da Observabilidade com Prometheus: Como Funciona a Coleta de Métricas
O Prometheus adota um modelo pull-based: em vez de aplicações empurrarem métricas para um coletor central, o próprio servidor Prometheus faz scrape periódico de endpoints HTTP expostos no formato texto (ou protobuf) padrão. Isso simplifica o troubleshooting, já que basta acessar o endpoint /metrics para inspecionar o que está sendo exposto.
A configuração básica de coleta é declarativa, geralmente em YAML:
scrape_configs:
- job_name: 'app-backend'
scrape_interval: 15s
static_configs:
- targets: ['backend-svc:8080']
Internamente, o Prometheus armazena séries temporais em um TSDB próprio, otimizado para escrita sequencial e compressão de blocos. Esse design traz ótima performance local, mas retenção longa (meses ou anos) em disco local não é o cenário ideal — por isso soluções como Thanos ou Cortex costumam ser adicionadas para remote_write, deduplicação e armazenamento de longo prazo em object storage.
Em ambientes Kubernetes, a observabilidade com Prometheus se apoia fortemente em service discovery: o servidor consulta a API do cluster para descobrir pods, services e endpoints automaticamente, eliminando a necessidade de manter listas estáticas de targets. Quem já avaliou kubernetes gerenciado vs serverless sabe que esse tipo de integração nativa pesa bastante na decisão de arquitetura.
PromQL, Alertmanager e Integração com Grafana na Prática
A linguagem de consulta PromQL é um dos pontos fortes da ferramenta. Ela permite operações como rate(), histogram_quantile() e agregações por label, essenciais para calcular latência p95/p99 ou taxa de erro por serviço. Um exemplo comum:
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
Esse tipo de query é a base de dashboards no Grafana, que consome o Prometheus como data source via HTTP API. A combinação Prometheus + Grafana virou padrão de mercado justamente porque separa responsabilidades: coleta e armazenamento de um lado, visualização e storytelling de dados do outro.
Para alertas, o Alertmanager recebe alertas disparados por regras PromQL configuradas no servidor, e cuida de deduplicação, agrupamento, silenciamento e roteamento para canais como Slack, e-mail ou PagerDuty. É aqui que muitas implementações de observabilidade com Prometheus falham na prática: regras mal calibradas geram fadiga de alertas, e times acabam ignorando notificações importantes. Definir SLOs claros antes de escrever regras de alerta é mais importante do que a ferramenta em si.
Alta disponibilidade e escala
Por padrão, o Prometheus roda em modo single-node, o que cria um ponto único de falha. Para alta disponibilidade, é comum rodar réplicas idênticas com os mesmos scrape_configs, ou adotar Thanos Sidecar/Query para federar múltiplas instâncias e oferecer uma view global. Esse trade-off entre simplicidade operacional e resiliência precisa ser avaliado conforme a criticidade do ambiente — não existe bala de prata.
Prós, Contras e Quando Escolher Observabilidade com Prometheus
Entre os pontos positivos, destacam-se:
- Modelo pull-based simplifica debugging e reduz acoplamento entre aplicação e sistema de monitoramento;
- PromQL é expressiva e permite análises complexas de séries temporais sem sair da própria ferramenta;
- Ecossistema maduro de exporters (node_exporter, kube-state-metrics, blackbox_exporter) cobre praticamente qualquer stack;
- Integração nativa com Kubernetes via service discovery reduz esforço de manutenção.
Já entre os contras reais:
- Armazenamento local não escala bem para retenção longa sem componentes adicionais (Thanos, Cortex, Mimir);
- Alta disponibilidade exige arquitetura extra, não vem out-of-the-box;
- PromQL tem curva de aprendizado real para queries mais avançadas de agregação e joins;
- Não é adequado para logs ou traces — é preciso combinar com Loki, Tempo ou Jaeger para observabilidade completa.
Na prática, a observabilidade com Prometheus faz mais sentido para times que já operam Kubernetes ou infraestrutura containerizada, precisam de métricas de séries temporais com granularidade fina e têm maturidade para operar o stack (ou usar uma versão gerenciada). Para startups em estágio inicial, uma alternativa gerenciada como Grafana Cloud ou Datadog pode reduzir a carga operacional inicial, migrando para self-hosted conforme o custo e a escala justificarem.
Vale lembrar que adotar observabilidade não é só uma decisão técnica: comunicar essa evolução de stack para o time e para stakeholders também importa, como discutimos em como comunicar evolução e construir autoridade.
Conclusão
A observabilidade com Prometheus continua sendo referência para métricas em ambientes cloud-native, especialmente por sua arquitetura pull-based, PromQL e integração nativa com Kubernetes. Os contras — retenção, alta disponibilidade e escopo limitado a métricas — são conhecidos e têm soluções maduras no ecossistema. A decisão certa depende do estágio de maturidade da equipe de TI e da criticidade do ambiente monitorado.
