Monitoramento

Você não pode consertar o que não vê. Monitoramento é seus olhos e ouvidos no sistema.

Métricas

Uma métrica é um número que muda no tempo. Em backend, geralmente caem em três buckets (as famosas três pilares da observabilidade: metrics, logs, traces — vamos focar em metrics aqui).

Os "Quatro Sinais Dourados" (Google SRE)

A bíblia do monitoramento, e o suficiente pra começar:

1. Latency (Latência): tempo de resposta. Sempre meça separadamente o tempo de respostas com sucesso e com erro — uma falha rápida pode mascarar problemas.
2. Traffic (Tráfego): quantas requisições por segundo. Mede o "uso".
3. Errors (Erros): taxa de erros. Pode ser HTTP 5xx, exceções, falhas de validação.
4. Saturation (Saturação): quão "cheio" o sistema está. CPU em 95%, fila de jobs com 10k itens, conexões de banco esgotadas.

Outros frameworks populares: RED (Rate, Errors, Duration — pra serviços) e USE (Utilization, Saturation, Errors — pra recursos como CPU/disco/rede).

O stack típico

• Prometheus: coleta métricas via scraping. Padrão de mercado.
• Grafana: dashboards lindos em cima do Prometheus.
• OpenTelemetry: standard aberto pra emitir métricas, logs, traces.
• Datadog / New Relic / Honeycomb: alternativas SaaS pra quem não quer operar a infra.

Exemplo: expondo métricas em Go

import (
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)
 
var requestDuration = prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name:    "http_request_duration_seconds",
        Help:    "Duração das requisições HTTP em segundos",
        Buckets: prometheus.DefBuckets,
    },
    []string{"method", "endpoint", "status"},
)
 
func init() {
    prometheus.MustRegister(requestDuration)
}
 
func main() {
    http.Handle("/metrics", promhttp.Handler())
    http.ListenAndServe(":8080", nil)
}

Prometheus faz scraping em /metrics, e no Grafana você plota gráficos de p50/p95/p99 por endpoint.

Alertas

Métrica sem alerta é só decoração de dashboard. Alertas avisam quando algo está errado agora (idealmente, antes do cliente reclamar).

Boas práticas

1. Alerte em sintomas, não em causas. "Disco em 80%" pode ou não ser problema. "Taxa de erro do checkout > 5%" é sempre problema. Alerte no que afeta o usuário.
2. Cada alerta precisa ser acionável. Se chegou o alerta, alguém tem que fazer alguma coisa. Se não tem ação clara, é ruído.
3. Combata fadiga de alerta. Se um alerta dispara 50x por dia e ninguém olha, ele não existe. Pior: vai esconder o alerta importante quando vier.
4. Severidade importa. Use níveis (P1 acorda alguém de madrugada, P3 só vira ticket). Não trate todo alerta como crítico.
5. Tenha um runbook. Cada alerta crítico deve linkar pra documentação: "se esse alerta dispara, faça X, Y, Z".
6. Use SLOs (Service Level Objectives). Em vez de "p99 < 200ms", defina "99,9% das requisições em < 200ms num período de 30 dias". Aí você alerta com base no error budget — sobra de orçamento de erros. Mais preciso, menos paranóico.

Exemplo de regra Prometheus

groups:
- name: api-alerts
  rules:
  - alert: AltaTaxaDeErro5xx
    expr: |
      sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
      sum(rate(http_requests_total[5m]))
        > 0.05
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Taxa de 5xx acima de 5% nos últimos 5min"
      runbook: "https://wiki.empresa.com/runbooks/alta-taxa-erro"