Alertas

Um alerta é um pedido de atenção de um humano, muitas vezes às 3 da manhã. Isso o torna o sinal mais caro do sistema: custa sono, foco e, com o tempo, confiança. Dois modos de falha matam o alerting. Alertas demais — "CPU acima de 80%" em cada pod, cada oscilação de cada dependência — e o engenheiro de on-call aprende a ignorar o pager; o incidente real se afoga no ruído. Alertas de menos, ou os errados — e a primeira pessoa a notar o checkout quebrado é um fã nas redes sociais. Esta página trata de alertas que disparam quando, e somente quando, os usuários estão sendo prejudicados o bastante para que alguém precise agir.

O que merece um page

Um bom page (o acionamento do on-call) é urgente, acionável e sobre um problema visível para o usuário¹. Se faltar qualquer um dos três, ele deveria ser outra coisa:

Sintomas, não causas

Alerte sobre sintomas — o que os usuários vivenciam: erros, latência, atualidade dos dados, corretude. Use causas — CPU, memória, um reinício de pod, uma fila cheia — para dashboards e diagnóstico, não para pages.

A exceção é um indicador antecedente que certamente vai virar sintoma e dá tempo para agir — um disco enchendo, um certificado expirando em 7 dias. Esses são tickets, não pages, a menos que o prazo seja de horas.

Do SLO ao alerta

O SLO já diz quanta falha é aceitável: com 99,9% dos checkouts com sucesso numa janela móvel de 28 dias (a janela usada em toda a aula de Confiabilidade), o error budget é 0,1% dos checkouts. A pergunta que um alerta precisa responder, portanto, não é "há erros?" — sempre há — mas "estamos gastando o budget rápido o bastante para ter problemas?".

A medida natural é o burn rate:

Um burn rate de 1 gasta exatamente o budget inteiro na janela inteira; um burn rate de 14,4 o gasta 14,4 vezes mais rápido. Se um burn rate \(b\) se mantém por um tempo \(t\), a fração do budget consumida é

Um burn rate de 1000× é uma indisponibilidade total (100% de erros contra um budget de 0,1%): o budget inteiro de 28 dias acaba em cerca de 40 minutos. É por isso que os alertas rápidos precisam disparar em minutos — e por isso que queimas lentas podem esperar o horário comercial.

Seis jeitos de escrever o alerta

O SRE Workbook² compara seis desenhos progressivamente melhores para um alerta de SLO. Sua qualidade é medida por quatro propriedades: precisão (fração dos alertas que eram problemas reais), recall (fração dos problemas reais que geraram alerta), tempo de detecção e tempo de reset (quanto tempo o alerta continua disparando depois que o problema acaba).

Multiwindow, multi-burn-rate

O desenho recomendado combina, para cada severidade, uma janela longa que prova que a queima é significativa e uma janela curta (1/12 da longa) que prova que ela ainda está acontecendo — assim o alerta para rápido quando o problema é corrigido:

O gráfico mostra o tempo de detecção para uma falha súbita com uma dada razão de erros, para as duas regras de page. Note o trade-off que ele codifica: quanto pior o incidente, mais rápido o alerta — e, para uma dada regra, o budget gasto no momento em que ela dispara é sempre o mesmo (2% e 5%).

Uma indisponibilidade total (100% de erros) dispara a regra rápida em menos de um minuto; um incidente que faz falhar 2% dos checkouts leva cerca de 43 minutos para disparar a regra rápida, e um que faz falhar 0,7% nunca a dispara, mas dispara a regra de 6 horas depois de cerca de 5 horas. Abaixo de 0,6% — um burn rate menor que 6× — só a regra de ticket o pega.

As regras em PromQL

Regras de gravação (recording rules) pré-calculam a razão de erros da jornada de checkout em cada janela; as regras de alerta as comparam com os limiares. (Ferramentas como Sloth, Pyrra ou a especificação OpenSLO geram essas regras a partir de uma definição curta de SLO, o que evita erros de copiar e colar.)

# prometheus-rules.yaml — checkout availability SLO: 99.9% over 28 days
groups:
  - name: slo-checkout-recordings
    rules:
      - record: slo:checkout_errors:ratio_rate5m
        expr: |
          sum(rate(http_server_request_duration_seconds_count{job="order", http_route="/checkout", http_response_status_code=~"5.."}[5m]))
          /
          sum(rate(http_server_request_duration_seconds_count{job="order", http_route="/checkout"}[5m]))
      - record: slo:checkout_errors:ratio_rate1h
        expr: |
          sum(rate(http_server_request_duration_seconds_count{job="order", http_route="/checkout", http_response_status_code=~"5.."}[1h]))
          /
          sum(rate(http_server_request_duration_seconds_count{job="order", http_route="/checkout"}[1h]))
      # ... the same expression for 30m, 6h and 3d

  - name: slo-checkout-alerts
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          slo:checkout_errors:ratio_rate1h > (14.4 * 0.001)
          and
          slo:checkout_errors:ratio_rate5m > (14.4 * 0.001)
        labels:
          severity: page
          team: checkout
        annotations:
          summary: "Checkout is burning its 28-day error budget at more than 14.4x"
          runbook_url: "runbooks/checkout-slo.md"
      - alert: CheckoutErrorBudgetSlowBurn
        expr: |
          slo:checkout_errors:ratio_rate6h > (6 * 0.001)
          and
          slo:checkout_errors:ratio_rate30m > (6 * 0.001)
        labels:
          severity: page
          team: checkout
      - alert: CheckoutErrorBudgetTicket
        expr: |
          slo:checkout_errors:ratio_rate3d > (1 * 0.001)
          and
          slo:checkout_errors:ratio_rate6h > (1 * 0.001)
        labels:
          severity: ticket
          team: checkout

Um SLO de latência funciona do mesmo jeito: os "eventos ruins" são as requisições mais lentas que o limiar, calculadas a partir do bucket do histograma que termina no limiar:

# fraction of checkouts slower than 2 s over 1 h (the "error ratio" of a latency SLO)
1 - (
  sum(rate(http_server_request_duration_seconds_bucket{job="order", http_route="/checkout", le="2"}[1h]))
  /
  sum(rate(http_server_request_duration_seconds_count{job="order", http_route="/checkout"}[1h]))
)

- uid: catalog-availability-fast-burn
  title: "catalog availability SLO: fast burn"
  condition: C
  data:
    - refId: A          # burn rate over the long window (1 h)
      relativeTimeRange: { from: 3600, to: 0 }
      datasourceUid: prometheus
      model:
        refId: A
        instant: true
        expr: |
          (
            sum(rate(http_server_request_duration_seconds_count{service_name="catalog", http_route!~"/actuator.*", http_response_status_code=~"5.."}[1h]))
            / sum(rate(http_server_request_duration_seconds_count{service_name="catalog", http_route!~"/actuator.*"}[1h]))
          ) / 0.005
    - refId: C
      datasourceUid: __expr__
      model:
        refId: C
        type: math
        expression: "$A > 14.4 && $B > 14.4"
  for: 1m
  noDataState: OK
  execErrState: Error
  labels:
    severity: page
    slo: catalog-availability

Roteamento: de uma regra disparada até uma pessoa

Uma regra de alerta só produz um alerta disparado. Algo precisa decidir quem fica sabendo, como e com que frequência. No ecossistema Prometheus, isso é o Alertmanager³ (o Grafana Alerting tem os mesmos conceitos): ele agrupa alertas relacionados numa só notificação, deduplica, aplica inibições e silêncios, e roteia pelos labels até os receivers.

flowchart LR
    R["Avaliação da regra<br/>Prometheus / ruler do Mimir"] --> F["Alerta disparado<br/>severity=page, team=checkout"]
    F --> G["Alertmanager<br/>agrupa · deduplica"]
    G --> S{"Silenciado ou<br/>inibido?"}
    S -->|sim| X["Descartado<br/>(ainda visível na UI)"]
    S -->|não| RT{"Roteia pelos labels"}
    RT -->|severity=page| PD["Pager<br/>celular do on-call"]
    RT -->|severity=page| SL["Slack #incidents"]
    RT -->|severity=ticket| TK["Fila de tickets"]
    PD --> ACK["On-call confirma<br/>ou escala após 5 min"]

# alertmanager.yaml (sketch)
route:
  receiver: slack-observability          # default for anything unmatched
  group_by: [alertname, team]
  group_wait: 30s                        # wait to batch related alerts into one notification
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: [severity="page"]
      receiver: pager-checkout
      continue: true                     # also evaluate the next route
    - matchers: [severity="page"]
      receiver: slack-incidents
    - matchers: [severity="ticket"]
      receiver: ticket-queue

inhibit_rules:
  - source_matchers: [alertname="RegionDown"]
    target_matchers: [severity=~"page|ticket"]
    equal: [region]                      # one page for the region, not fifty for its services

receivers:
  - name: pager-checkout
    pagerduty_configs:
      - routing_key_file: /etc/alertmanager/secrets/pager-checkout
  - name: slack-incidents
    slack_configs:
      - api_url_file: /etc/alertmanager/secrets/slack-incidents
        channel: "#incidents"
  - name: slack-observability
    slack_configs:
      - api_url_file: /etc/alertmanager/secrets/slack-observability
        channel: "#observability"
  - name: ticket-queue
    webhook_configs:
      - url: http://ticket-bridge:8080/alerts

Quem vigia o vigia?

Se o Prometheus ou o Alertmanager cair, nada alerta — e o silêncio se parece exatamente com saúde. Duas proteções padrão:

• Um dead man's switch: uma regra que sempre dispara (expr: vector(1), muitas vezes chamada Watchdog), enviada a um serviço externo que aciona o page se o sinal de vida parar de chegar.
• Alertas de ausência de dados: absent(up{job="order"}) ou absent_over_time(...) disparam quando uma métrica some — um exporter caído, uma métrica renomeada, um job que deixou de ser coletado.

Para jornadas com pouco tráfego à noite, uma razão sobre zero requisições é indefinida; probes sintéticas (um check do k6 ou do Blackbox Exporter que compra um ingresso de teste num evento falso a cada minuto) mantêm o SLI significativo a qualquer hora.

Runbooks

Todo page precisa apontar para um runbook: um documento curto que diz a um engenheiro cansado o que o alerta significa e o que tentar primeiro. Runbooks reduzem o MTTR porque os primeiros 10 minutos deixam de ser improviso.

# CheckoutErrorBudgetFastBurn

**Meaning**: checkout is failing at more than 14.4x the rate the 99.9% SLO allows;
at this pace the 28-day budget is gone in about 2 days.

**Impact**: fans cannot buy tickets. During an on-sale, declare an incident immediately (SEV1).

**First checks (5 minutes)**
1. Checkout dashboard: which status codes? which route? since when? any deploy or flag change?
2. Payment provider panel: latency and error ratio of the provider call.
3. Open an exemplar trace of a failed checkout: which span fails or waits?

**Mitigations**
- Recent deploy → roll back (`argocd app rollback order`).
- Provider slow or failing → switch to the secondary provider (flag `payment.provider=secondary`).
- Database saturated → enable the waiting room (flag `waiting-room.enabled=true`).

**Escalate to**: payments team (secondary on-call), then the incident commander rotation.

Máquinas detectam, pessoas reparam

Um alerta não tira uma réplica quebrada do balanceador: um health check faz isso em segundos, e não acorda ninguém. O page é para o que uma máquina não consegue fazer sozinha — restaurar o que foi perdido antes que a próxima falha encontre o BoxOffice com menos redundância do que foi projetado para ter. É por isso que o runbook acima reduz o MTTR, e por isso que uma réplica que reinicia e se recupera sozinha não vale um page.

Experimente. No observability-stack, uma das três réplicas do catalog morre em t = 50 s e fica morta por 80 s. Adicione Metrics (conectado ao balanceador, à aplicação e ao banco) e um Health Check conectado ao balanceador, e rode: os erros duram 3 s, e a disponibilidade é de 99,4%. Agora adicione Alerting conectado ao Metrics e rode de novo.

Trade-offs

Como se conecta

flowchart LR
    SLO["SLO 99.9% over 28 days<br/>→ SLIs, SLOs e error budgets"] --> BUD["error budget 0.1%"]
    SLI["SLI from metrics<br/>(RED, histograms)"] --> BR["burn rate =<br/>error ratio ÷ budget"]
    BUD --> BR
    BR --> MW["multiwindow rules:<br/>14.4× and 6× page, 1× ticket"]
    MW --> AM["Alertmanager: group,<br/>inhibit, silence, route"]
    AM --> PAGE["page + runbook"]
    AM --> TK["ticket"]
    PAGE --> IR["Incident Response"]
    DMS["dead man's switch,<br/>absent(), synthetic probes"] --> AM
    MW -.-> ONS["on-sale SLO,<br/>short windows"]

Componentes da paleta: alerting · metrics (o SLI e as recording rules) · payment (o provedor lento que queima o budget da abertura de vendas) · kafka (um disco de broker enchendo: ticket, não page). Cenários: observability-stack, flash-sale (uma abertura de vendas de 30 minutos precisa do próprio SLO). Continua em: SLIs, SLOs e error budgets (SLI, SLO, política de error budget), Resposta a Incidentes, Cloud-native — entrega (rollbacks citados no runbook), Hands-on 8 — SLO e alerta de burn rate.

Pontos-chave