“Está lento” não é diagnóstico. Sem observabilidade, todo incidente vira caça ao tesouro no escuro. Com Prometheus e Grafana, você troca achismo por dado — e MTTR alto por resposta rápida.

Este guia vai do básico (coletar métrica) ao que importa de verdade (definir SLO).

Os três pilares — comece pelas métricas

Observabilidade tem três frentes: métricas, logs e traces. Não tente tudo de uma vez. Métricas dão o maior retorno inicial: são baratas de coletar e respondem “está saudável?”.

Como o Prometheus funciona

Prometheus faz scrape: ele puxa as métricas dos seus serviços num endpoint /metrics, em intervalo fixo. Você não empurra dado pra ele.

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'minha-api'
    static_configs:
      - targets: ['api:8080']

Sua aplicação expõe /metrics (via client library) e o Prometheus coleta. Simples assim.

As 4 métricas que importam (Golden Signals)

Não meça tudo. Meça o que o Google SRE chama de Golden Signals:

1. Latência — quanto tempo a requisição leva.
2. Tráfego — quantas requisições por segundo.
3. Erros — taxa de falha.
4. Saturação — quão cheio está o recurso (CPU, memória, fila).

Exemplo de query PromQL pra taxa de erro:

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Isso te dá o percentual de erro nos últimos 5 minutos. Essa é a base do seu alerta e do seu SLO.

Grafana: o dashboard que alguém realmente olha

Prometheus guarda o dado; Grafana mostra. O erro comum é fazer dashboard com 50 painéis que ninguém entende. Faça um painel por Golden Signal e pare.

Conecte o Grafana ao Prometheus como data source e monte 4 painéis. Pronto — você já vê a saúde do sistema numa tela.

O salto de maturidade: SLO

Aqui a maioria para, e é onde está o valor real.

• SLI (indicator) — a métrica: “99,5% das requisições respondem em menos de 300ms”.
• SLO (objective) — a meta: “queremos manter isso em 30 dias”.
• Error budget — o quanto você pode falhar: 0,5% de margem.

Por que isso muda o jogo? Porque error budget vira decisão. Budget sobrando? Pode arriscar deploy novo. Budget estourado? Congela feature e foca em estabilidade. Acaba a briga “subjetiva” entre dev e ops — o número decide.

Alertas que não viram ruído

Alerta sobre causa, não sobre sintoma de cada CPU. Alerte quando o SLO estiver em risco:

# alert.rules.yml
groups:
  - name: slo
    rules:
      - alert: ErrorBudgetBurnRapido
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m])) > 0.01
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Taxa de erro acima de 1% por 5min"

Regra de ouro: se o alerta não exige ação humana, não é alerta — é log. Alerta demais = time ignora todos.

Erros comuns

• Coletar métrica e nunca olhar → dashboard morto.
• Alerta pra tudo → fadiga, ninguém responde.
• Pular SLO → você mede sem saber qual o alvo.

Próximo passo

Observabilidade fecha o ciclo DevOps: você entrega rápido e sabe que está saudável. Sem isso, velocidade vira risco.

Monto Prometheus + Grafana com você dentro de um projeto completo — Docker, Kubernetes, CI/CD e monitoramento — no DevOps na Prática. Quer discutir o cenário do seu sistema? Chama no WhatsApp.