Como funciona o monitoramento Prometheus

O Prometheus se consolidou como o padrão de facto para coleta de métricas em ambientes cloud-native. Com mais de 50 mil stars no GitHub e integração nativa com Kubernetes, ele é o núcleo da stack de monitoramento de times de SRE e DevOps ao redor do mundo. Em 2024, o projeto lançou o Prometheus 3.0, a primeira major release em anos, com melhorias significativas de performance, novo formato nativo e compatibilidade ampliada com OpenTelemetry.

Neste guia técnico atualizado para 2026, você vai entender como funciona o Prometheus, sua arquitetura, como escrever queries em PromQL, configurar alertas e integrá-lo ao Grafana.

O que é o Prometheus?

O Prometheus é um sistema open source de monitoramento e alerta, criado pela SoundCloud em 2012 e doado à CNCF (Cloud Native Computing Foundation) em 2016. Ele coleta métricas via pull (scrape), armazena em um banco de dados de séries temporais (TSDB) e disponibiliza uma linguagem de query chamada PromQL para análise e criação de alertas.

Diferente de ferramentas baseadas em push (como StatsD e InfluxDB com Telegraf), o Prometheus vai ativamente buscar as métricas nos endpoints expostos pelas aplicações e exporters. Isso simplifica a descoberta de serviços e centraliza o controle de coleta no servidor.

O Prometheus integra-se nativamente ao ecossistema observabilidade: métricas (Prometheus), logs (Loki) e traces (OpenTelemetry ou Jaeger) formam a tríade completa quando combinados com Grafana.

Arquitetura do Prometheus

A arquitetura do Prometheus é deliberadamente simples e composta por componentes modulares.

Prometheus Server

O núcleo do sistema. Responsável por fazer o scrape dos targets, armazenar as métricas no TSDB local e servir a API HTTP para queries PromQL. Em ambientes de alta disponibilidade, múltiplos servidores Prometheus rodam em paralelo com as mesmas configurações — sem replicação nativa, mas com Thanos ou Cortex como camada de long-term storage distribuído.

Exporters

Os exporters são agentes que expõem métricas de sistemas que não têm suporte nativo ao Prometheus. Os principais são o node_exporter (métricas de host: CPU, memória, disco), blackbox_exporter (probing HTTP/TCP/DNS), mysqld_exporter, postgres_exporter e nginx_vts_exporter. Para aplicações custom, as bibliotecas cliente estão disponíveis em Go, Java, Python e outras linguagens.

Pushgateway

Componente que permite que jobs batch ou de curta duração enviem métricas via push antes de terminar. O Pushgateway age como intermediário: os jobs enviam as métricas e o Prometheus faz scrape do Pushgateway normalmente.

Alertmanager

O Alertmanager recebe alertas disparados pelo Prometheus e gerencia roteamento, deduplicação, agrupamento e silenciamento. Ele envia notificações para Slack, PagerDuty, OpsGenie, e-mail e outros canais configuráveis. A separação entre geração de alertas (Prometheus) e gerenciamento de notificações (Alertmanager) é um dos pontos fortes da arquitetura — permite gerenciar fadiga de alertas de forma centralizada.

Prometheus 3.0: o que mudou em 2026

O Prometheus 3.0 trouxe mudanças relevantes para ambientes de produção.

O novo formato nativo de histograma (Native Histograms) substitui os histogramas clássicos baseados em buckets fixos por uma representação mais eficiente e precisa. Isso reduz o número de séries temporais geradas por histograma e melhora a acurácia dos percentis sem necessidade de definir buckets antecipadamente.

A compatibilidade com OpenTelemetry foi aprofundada: o Prometheus 3.x aceita métricas no formato OTLP via OTLP receiver, consolidando-se como backend de métricas para pipelines OpenTelemetry sem necessidade de conversão.

O novo motor de queries melhorou a performance em queries sobre grandes janelas de tempo, reduzindo consumo de CPU e memória em clusters com milhões de séries ativas.

PromQL: a linguagem de queries do Prometheus

O PromQL (Prometheus Query Language) é a linguagem usada para consultar e agregar métricas coletadas. Ela opera sobre séries temporais e suporta funções matemáticas, agregações e seleções por labels.

Tipos de queries básicas

Instant vector: retorna o valor mais recente de uma métrica.
up — retorna 1 (target ativo) ou 0 (target inativo) para todos os targets monitorados.

Rate e irate: calcula a taxa de crescimento por segundo de um counter.
rate(http_requests_total[5m]) — taxa de requisições nos últimos 5 minutos.

Percentis com histograma:
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) — P99 de latência.

Agregações:
sum(rate(http_requests_total[5m])) by (service) — taxa total agrupada por serviço.

Labels e seletores

Labels são a dimensão mais poderosa do Prometheus. Cada métrica pode ter múltiplos labels (job, instance, environment, region) que permitem filtragem e agregação granular. Neste sentido, um bom esquema de labels é fundamental para escalar o uso do Prometheus sem explosão de cardinalidade.

Configuração e scrape

A configuração do Prometheus é feita via arquivo YAML (prometheus.yml). Um exemplo básico de scrape config:


scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['servidor-1:9100', 'servidor-2:9100']


Em ambientes Kubernetes, o Prometheus usa service discovery nativo para descobrir pods e serviços automaticamente via anotações. O kube-prometheus-stack (Helm chart mantido pela comunidade) é a forma recomendada de instalação em K8s — ele instala Prometheus, Alertmanager, Grafana e um conjunto de dashboards e alertas pré-configurados para Kubernetes.

Alertas no Prometheus

Alertas são definidos em arquivos de regras separados, carregados pelo servidor Prometheus. Um exemplo de alerta para instância fora do ar:


groups:
- name: availability
rules:
- alert: InstanceDown
expr: up == 0
for: 5m
labels:
severity: critical
annotations:
summary: "Instância {{ $labels.instance }} offline"


O parâmetro for: 5m define que o alerta só dispara se a condição persistir por 5 minutos — evitando falsos positivos em falhas transitórias. Alertas disparados são enviados ao Alertmanager, que decide roteamento e supressão conforme as regras configuradas. Essa estrutura é base para reduzir fadiga de alertas em operações de grande escala.

Prometheus e os 4 sinais de ouro do SRE

O Prometheus é a ferramenta de referência para implementar os 4 sinais de ouro do SRE (Latência, Tráfego, Erros e Saturação) em ambientes cloud-native. Cada sinal corresponde a um conjunto de métricas e queries PromQL que podem ser padronizados em dashboards Grafana e usados como base para definir SLOs e calcular error budgets.

Para equipes que adotam SRE, o Prometheus é o instrumento de medição que transforma SLOs em dados concretos e acionáveis.

Long-term storage: Thanos e Cortex

O Prometheus armazena dados localmente por padrão (15 dias por padrão, configurável). Para retenção longa e alta disponibilidade, os projetos mais adotados são o Thanos e o Cortex/Mimir.

O Thanos adiciona uma camada de armazenamento em object storage (S3, GCS, Azure Blob) sobre o Prometheus existente, com compactação e deduplicação. O Grafana Mimir (sucessor do Cortex) é uma solução totalmente escalável horizontalmente para ambientes que precisam de alta ingestão e multi-tenancy. Ambas as opções são recomendadas para ambientes de produção que precisam de histórico superior a 30 dias.

Conclusão

O Prometheus é o pilar central do monitoramento cloud-native em 2026. Sua arquitetura pull, o modelo de labels, o PromQL e a integração nativa com Kubernetes e OpenTelemetry fazem dele a escolha natural para times que adotam SRE, DevOps e observabilidade como práticas operacionais.

Com o Prometheus 3.0 consolidado, histogramas nativos e suporte a OTLP, o ecossistema está mais maduro do que nunca. Se você quer implementar uma estratégia de monitoramento baseada em Prometheus com Grafana, alertas inteligentes e long-term storage, fale com nossos especialistas.