Como você desenharia o monitoramento de uma aplicação do zero?

Question

Accepted Answer

Comece **de cima para baixo com o que os usuários sentem**, não de baixo para cima a partir da infraestrutura. A frota de hosts mais confiável é inútil se as solicitações estão falhando, então comece com **SLI**s **orientadas ao usuário — **latency**, **error rate**, **availability** — depois adicione os quatro sinais dourados, depois as métricas de infra por último.

## A disposição em camadas, de usuário para dentro

```text
1. USER-FACING SLIs   → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS     → latency, traffic, errors, saturation per service
3. INFRA METRICS      → CPU, memory, disk, network (causes, not symptoms)
```

Se você apenas observar CPU e disco (de baixo para cima), pode estar completamente verde enquanto usuários recebem 500s. Observar SLIs primeiro (de cima para baixo) significa que você alerta sobre **sintomas que os usuários realmente sentem**, depois investiga em profundidade sinais dourados e infra para encontrar a causa.

## Por que isso importa

```text
INSTRUMENT  app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
   ↓
COLLECT     a TSDB scrapes/ingests them (Prometheus, Datadog agent)
   ↓
DASHBOARD   visualize SLIs + golden signals (Grafana) for humans to read
   ↓
ALERT       fire on SLO violations / burn rate, routed to on-call
```

## Um ponto de partida concreto

```promql
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

Defina um **SLO** em cada SLI (por exemplo, disponibilidade de 99,9%, p99 < 300ms), crie um dashboard deles e alerte quando o SLO está em risco — não a cada oscilação.

## Por que isso importa

O monitoramento construído de baixo para cima diz que um disco está 80% cheio, mas não que os clientes não conseguem fazer checkout. Começar a partir de SLIs orientadas ao usuário vincula cada dashboard e alerta ao impacto real do usuário, mantém o ruído baixo e fornece um caminho claro de investigação (sintoma → sinal dourado → causa de infra) quando algo quebra.