Como funciona o monitoramento Prometheus

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado mar/2023Atualizado ago/2026

O Prometheus coleta métricas de servidores, aplicações e containers por scrape. É o padrão de facto de monitoramento em ambientes cloud-native, com integração nativa ao Kubernetes. Esta página mostra quatro coisas testadas, não descritas: o arquivo de scrape, três consultas PromQL, uma regra de alerta e o critério de versão.

Cada bloco traz a saída real: tudo rodou em um laboratório com Prometheus 3.13.2, a linha LTS, em 28 de agosto de 2026. Nessa data o repositório do projeto reunia 65.867 stars. A major release 3 saiu em novembro de 2024 e a linha corrente já é a 3.14.

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. Não existe replicação nativa: quem cobre isso é o Thanos ou o 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. A escolha entre eles é de cobertura, não de preferência: cada um responde a uma pergunta diferente sobre o ambiente.

No laboratório desta página, o node_exporter sozinho publicou 776 séries de um único host. Em um parque de 100 servidores isso dá cerca de 77 mil séries só de infraestrutura, antes de qualquer métrica de aplicação. Por isso a conta de capacidade do TSDB começa pelo exporter de host, não pelo código instrumentado.

Para aplicações próprias, 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 gerar alerta (Prometheus) e notificar (Alertmanager) concentra num só lugar a decisão de quem é acordado. Dá para gerenciar fadiga de alertas sem tocar em nenhuma regra.

Prometheus 3: o que mudou e qual versão rodar em produção

A linha 3 do Prometheus trouxe mudanças relevantes para ambientes de produção. Duas delas costumam ser mal entendidas na hora de planejar a atualização.

Os histogramas nativos (Native Histograms) representam a distribuição sem buckets fixos. Isso reduz o número de séries por histograma e melhora a acurácia dos percentis. Eles não são automáticos, porém. A especificação oficial marca o recurso como estável só a partir da v3.8.0. Mesmo nela, a coleta segue desligada até que o scrape config traga scrape_native_histograms: true.

# A configuração efetiva do servidor, lida da API de status.
curl -s localhost:9090/api/v1/status/config \
  | grep -o 'scrape_native_histograms: [a-z]*' | uniq -c

      4 scrape_native_histograms: false
#     o default global e os três jobs, todos desligados

Subir para a linha 3 sem tocar nesse campo, portanto, não muda nada. O servidor continua guardando o histograma clássico, com os mesmos buckets e a mesma contagem de séries de antes.

A compatibilidade com OpenTelemetry foi aprofundada. O Prometheus 3.x aceita métricas no formato OTLP via OTLP receiver, o que o consolida como backend de métricas para pipelines OpenTelemetry.

Sobre qual versão rodar, vale ler a política de suporte do projeto. Uma minor release nova sai a cada seis semanas e deixa de receber correção quando a seguinte chega. Já as versões LTS recebem correção de bug e de segurança por um ano. A 3.5 encerrou o suporte em 31/07/2026 e a 3.13, publicada em 01/07/2026, é suportada até 31/07/2027. Quem hoje roda a 3.5 em produção está fora da janela de correção.

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.

As três perguntas que respondem primeiro

Três perguntas cobrem a maior parte do diagnóstico do dia a dia. O alvo está de pé? Quanto trabalho ele recebe? Como a latência se distribui? Abaixo estão as consultas que respondem a cada uma delas, executadas contra o laboratório, com a saída que o servidor devolveu.

# 1. Os alvos estão respondendo ao scrape?
up
#    -> 4 séries, todas em 1: prometheus (localhost:9090),
#       node (node-exporter:9100), aplicacao (app-pedidos:8000)
#       e aplicacao (app-checkout:8000)

# 2. Quantas requisições por segundo cada serviço atende?
sum by (service) (rate(http_requests_total[5m]))
#    -> {service="pedidos"}   4.7545527913
#    -> {service="checkout"}  2.3755136127

# 3. Qual a latência mediana e qual a de cauda?
histogram_quantile(0.50,
  sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))
#    -> {service="pedidos"}   0.0474571734     47 ms
#    -> {service="checkout"}  0.0704954954     70 ms

histogram_quantile(0.99,
  sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))
#    -> {service="pedidos"}   0.7177083333    718 ms
#    -> {service="checkout"}  0.8429166666    843 ms

A terceira pergunta é a que muda decisão. A mediana do serviço de pedidos ficou em 47 ms enquanto o p99 ficou em 718 ms, quinze vezes mais. Uma média de latência esconderia esse comportamento por completo. É por isso que limiar de alerta de latência se define sobre percentil, nunca sobre média.

Labels e seletores

Labels são a dimensão que dá granularidade ao modelo de dados. Cada métrica pode ter múltiplos labels (job, instance, environment, region) que permitem filtragem e agregação granular. O custo aparece na multiplicação: cada valor distinto de cada label cria uma série nova. Um label com ID de usuário ou com a URL completa da requisição leva a explosão de cardinalidade em poucas horas.

Configuração e scrape

A configuração do Prometheus é feita via arquivo YAML (prometheus.yml). O arquivo abaixo é o que roda no laboratório desta página. São três jobs, um para cada natureza de alvo, com o label service definido no scrape config.

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    ambiente: laboratorio

rule_files:
  - /etc/prometheus/regras-de-alerta.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: node
    static_configs:
      - targets: ["node-exporter:9100"]
        labels:
          ambiente: laboratorio

  - job_name: aplicacao
    metrics_path: /metrics
    static_configs:
      - targets: ["app-pedidos:8000"]
        labels:
          service: pedidos
      - targets: ["app-checkout:8000"]
        labels:
          service: checkout

Definir o label no static_configs tem uma razão prática. O mesmo binário sobe como pedidos ou como checkout sem recompilar nada. Quem decide o nome do serviço passa a ser quem opera a coleta, não quem escreve o código.

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 já configurados para Kubernetes.

Alertas no Prometheus

Alertas são definidos em arquivos de regras separados, carregados pelo servidor Prometheus. A regra abaixo é a que roda no laboratório. Ela compara a taxa de erro 5xx de cada serviço com um orçamento de erro de 1%.

groups:
  - name: nivel-de-servico
    rules:
      - alert: TaxaDeErroAcimaDoOrcamento
        expr: |
          sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))
            / sum by (service) (rate(http_requests_total[5m])) > 0.01
        for: 5m
        labels:
          severidade: alta
        annotations:
          summary: "Erro 5xx em {{ $labels.service }} acima de 1% há 5 minutos"

O parâmetro for: 5m é o que separa alerta de ruído. No teste de 28/08/2026 a condição passou a ser verdadeira às 05:11:53 UTC. O alerta só mudou para firing às 05:16:53, exatos cinco minutos depois. Nesse intervalo ele fica em pending: aparece no console, mas não notifica ninguém.

A tela abaixo mostra a regra já disparada, com a taxa medida no momento do disparo.

A curva que produziu esse disparo aparece no gráfico do próprio Prometheus. O serviço de checkout saiu de 0,4% e chegou a 12,5% de erro, enquanto o de pedidos seguiu abaixo de 0,5% durante todo o episódio.

Alertas disparados vão para o Alertmanager, que decide roteamento e supressão conforme as regras configuradas. Essa estrutura é a 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 a linha 3 consolidada, histogramas nativos estáveis desde a 3.8 e suporte a OTLP, o ecossistema chegou a um patamar que dispensa adaptação artesanal. Se você quer implementar uma estratégia de monitoramento baseada em Prometheus com Grafana, alertas calibrados e long-term storage, fale com nossos especialistas.