Métricas e Monitoramento

Tipos de métricas, métodos RED e USE, Prometheus, Grafana e como medir o comportamento de sistemas distribuídos.

O que são métricas?

As métricas são valores numéricos que representam o estado ou o comportamento de um sistema em um determinado momento. Diferentemente dos logs (que capturam eventos individuais), as métricas capturam tendências e permitem responder perguntas como: “Quantas requests por segundo estamos processando?” ou “Qual é a latência do percentil 99?”

Tipos de métricas

Counters (contadores)

Um counter é um valor que só pode ser incrementado. Ele é reiniciado quando o serviço é reiniciado.

• Uso: Contar eventos acumulativos.
• Exemplos: Total de requests recebidas, total de erros, total de mensagens processadas.
• Ponto-chave: O que é útil não é o valor absoluto, mas a taxa de variação (requests/segundo).

Gauges (indicadores)

Um gauge é um valor que pode subir e descer. Representa o estado atual de algo.

• Uso: Medir valores instantâneos.
• Exemplos: Conexões ativas, uso de memória, tamanho de fila, temperatura da CPU.
• Ponto-chave: Útil para detectar saturação e tendências.

Histograms (histogramas)

Um histograma agrupa observações em buckets predefinidos e calcula distribuições.

• Uso: Medir distribuições de valores, especialmente latências.
• Exemplos: Latência de requests (p50, p95, p99), tamanho de payloads.
• Ponto-chave: Os percentis são mais úteis que as médias — uma média de 100ms pode esconder que 1% das requests leva 5 segundos.

Summaries (resumos)

Semelhante aos histogramas, mas calculam os percentis no cliente em vez de no servidor.

• Uso: Quando você precisa de percentis exatos sem configurar buckets.
• Trade-off: Não podem ser agregados entre instâncias, diferentemente dos histogramas.

Métodos para escolher métricas

Método RED (para serviços)

O método RED foca em métricas orientadas ao usuário para serviços request-driven:

O RED é ideal para microsserviços que atendem requests HTTP ou gRPC. Se essas três métricas estiverem bem, o serviço provavelmente está saudável.

Método USE (para recursos)

O método USE foca na infraestrutura e nos recursos do sistema:

O USE é ideal para diagnosticar problemas de infraestrutura: CPU, memória, disco, rede, conexões com o banco de dados.

Combinando RED e USE

Na prática, use ambos os métodos:

• RED para entender a experiência do usuário e a saúde dos serviços.
• USE para entender a saúde da infraestrutura subjacente.

Prometheus

O Prometheus é o padrão de fato para métricas em arquiteturas cloud-native.

Modelo pull

Diferentemente de outros sistemas que recebem métricas (push), o Prometheus as coleta ativamente (pull). Cada serviço expõe um endpoint /metrics que o Prometheus consulta periodicamente.

Formato de métricas

# HELP http_requests_total Total de requests HTTP recibidas
# TYPE http_requests_total counter
http_requests_total{method="GET",path="/api/orders",status="200"} 15234
http_requests_total{method="POST",path="/api/orders",status="201"} 3421
http_requests_total{method="POST",path="/api/orders",status="500"} 12

PromQL

O Prometheus inclui uma linguagem de consulta poderosa (PromQL) para analisar métricas:

# Tasa de requests por segundo en los últimos 5 minutos
rate(http_requests_total[5m])

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

# Latencia del percentil 99
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

Alertas com o Prometheus

O Prometheus se integra com o Alertmanager para definir regras de alerta baseadas em PromQL:

groups:
  - name: servicio-ordenes
    rules:
      - alert: AltaTasaDeErrores
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Alta tasa de errores en el servicio de órdenes"

Grafana

O Grafana é a ferramenta de visualização mais popular para métricas do Prometheus.

Dashboards eficazes

Um bom dashboard do Grafana para um microsserviço inclui:

1. Painel superior: Métricas RED (rate, errors, duration) como indicadores principais.
2. Painéis de latência: Histogramas com percentis p50, p95, p99.
3. Painéis de recursos: CPU, memória, conexões (métricas USE).
4. Painéis de dependências: Latência e erros em direção a serviços downstream.

Variáveis e templates

O Grafana permite criar dashboards dinâmicos com variáveis:

• Seletor de serviço para reutilizar o mesmo dashboard.
• Seletor de intervalo temporal.
• Filtros por instância, método HTTP ou endpoint.

Boas práticas

Nomenclatura consistente

Use convenções claras para nomear métricas:

• Prefixo com o nome do serviço: order_service_requests_total.
• Sufixo com a unidade: _seconds, _bytes, _total.
• Labels para dimensões: method, status, endpoint.

Cardinalidade sob controle

Cada combinação única de labels cria uma série temporal. Evite labels com alta cardinalidade (como user IDs ou request IDs) — eles podem fazer o armazenamento do Prometheus explodir.

Métricas de negócio

Não se limite a métricas técnicas. As métricas de negócio são igualmente valiosas:

• Pedidos criados por minuto.
• Pagamentos bem-sucedidos vs recusados.
• Tempo médio de checkout.

Golden signals

O Google define quatro “golden signals” que todo serviço deveria monitorar:

1. Latência: Tempo que leva para atender as requests.
2. Tráfego: Volume de requests.
3. Erros: Taxa de requests que falham.
4. Saturação: Quão “cheio” está o serviço.

Resumo

As métricas são o segundo pilar da observabilidade. Enquanto os logs dizem o que aconteceu, as métricas dizem como o sistema está agora e para onde ele está indo. Combinando os métodos RED e USE com ferramentas como Prometheus e Grafana, você pode construir um sistema de monitoramento que o alerte antes que os problemas afetem os usuários.