Visão geral

Sábado, 9h59. Um show de estádio abre as vendas às 10h00 no BoxOffice: 2 milhões de fãs para 60 mil lugares. Às 10h04 o canal de suporte se enche de "o checkout fica girando para sempre". O time abre os dashboards: todos os pods estão verdes, a CPU está em 45%, a taxa de erros é de 0,3%, os health checks passam. E mesmo assim o fã mediano espera nove segundos para pagar. É o gateway? As reservas de assento no inventory? O provedor de pagamentos externo? O banco de dados? Quatro times entram numa call e cada um mostra um dashboard provando que o seu serviço está bem.

É para esse momento que a observabilidade existe. O sistema não está fora do ar — está lento de um jeito que ninguém previu, e a única saída é fazer perguntas novas ao sistema em execução e obter respostas em minutos, não em dias. Esta aula trata de projetar um sistema para que essas perguntas possam ser respondidas: quais sinais emitir, como carregar o contexto entre serviços, quando acordar um humano e como conduzir o incidente depois que alguém acordou.

Roteiro

1. Esta visão geral — monitoramento vs observabilidade, a paleta de observabilidade, o ciclo de investigação, health checks e quanto custa a telemetria.
2. Sinais — métricas, logs, traces e profiles; RED, USE e golden signals; cardinalidade; dashboards.
3. SLIs, SLOs e error budgets — a confiabilidade do ponto de vista do usuário: o que medir, que meta prometer e como gastar o orçamento.
4. OpenTelemetry — o padrão neutro de fornecedor: propagação de contexto, instrumentação, o Collector, amostragem e backends.
5. Alertas — alertas baseados em sintomas, burn rate do SLO, regras multiwindow, roteamento e runbooks.
6. Resposta a Incidentes — on-call, severidades, papéis no incidente, mitigar primeiro, postmortems.
7. Quiz — verifique seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Monitoramento vs observabilidade

As duas palavras costumam ser usadas como sinônimos, mas descrevem capacidades diferentes.

Monitoramento (monitoring) acompanha um conjunto de indicadores pré-definidos e avisa quando um deles cruza um limiar: "taxa de erros acima de 1%", "disco acima de 90%". Ele responde a perguntas que você sabia que deveria fazer quando montou o dashboard — os known unknowns.

Observabilidade é uma propriedade do sistema: o quão bem você consegue inferir seu estado interno a partir de suas saídas externas¹. O termo vem da teoria de controle (Kalman, 1960); em software, significa que, sem publicar código novo, você consegue fazer uma pergunta em que nunca tinha pensado — "por que só os checkouts com mais de quatro ingressos, pagos com uma bandeira de cartão, estão lentos desde 10h02?" — e respondê-la a partir da telemetria que o sistema já emite². Esses são os unknown unknowns, e sistemas distribuídos estão cheios deles.

O monitoramento não está obsoleto — ele é um subconjunto. Você ainda precisa de dashboards e alertas sobre sintomas conhecidos; a observabilidade é o que permite ir de "o alerta disparou" a "esta é a causa" quando a causa é nova.

A paleta de observabilidade

No System Design Playground, a categoria OBSERVABILITY tem cinco componentes. Cada um responde a uma pergunta diferente, e cada um é consumido por alguém diferente — um humano investigando, um humano sendo acordado, ou uma máquina tomando uma decisão de roteamento.

Todos descrevem os mesmos eventos de ângulos diferentes. Um único POST /checkout lento às 10h04 produz:

• uma amostra no histograma de latência do order (métrica) — barata, agregada, sem ideia de qual checkout;
• uma linha de log estruturada {"level":"WARN","msg":"payment call slow","trace_id":"4bf9…","duration_ms":8120} — precisa, cara em volume;
• um trace com spans para gateway → order → inventory → payment, com o span de pagamento levando 8,1 s — mostra onde;
• possivelmente uma amostra de profile mostrando threads paradas no cliente HTTP — mostra qual código;
• e, se checkouts suficientes ficarem lentos por tempo suficiente, um alerta que aciona o engenheiro de on-call.

A cola entre eles é o contexto: o mesmo trace_id na linha de log, no trace e anexado à amostra da métrica (um exemplar). Sem contexto compartilhado, você tem três ferramentas desconectadas; com ele, tem uma única investigação.

O ciclo de investigação

A observabilidade se paga como um ciclo repetível que vai de sinais baratos e agregados para sinais caros e detalhados — estreitando a busca a cada passo. Execute o diagrama:

flowchart LR
    A["Alerta<br/>SLO do checkout queimando 14×"] --> D["Dashboard RED<br/>qual serviço? qual rota?"]
    D --> E["Exemplar<br/>trace_id de uma requisição lenta"]
    E --> T["Trace<br/>qual span está lento?"]
    T --> L["Logs daquele span<br/>por quê? (erro, retry, timeout)"]
    L --> P["Profile<br/>qual caminho de código?"]
    P --> M["Mitigar<br/>rollback, breaker, failover"]
    M --> PM["Postmortem<br/>evitar a classe de falha"]

1. Detectar com um alerta baseado em SLO sobre um sintoma que os usuários sentem (Alertas).
2. Localizar com métricas: o dashboard RED mostra que o p99 do POST /checkout foi de 400 ms para 9 s; as outras rotas estão normais.
3. Escolher um exemplo: um painel de latência com exemplars liga uma amostra lenta ao seu trace_id.
4. Encontrar o salto: o waterfall do trace mostra 8 dos 9 segundos dentro do span payment, na chamada ao provedor externo.
5. Explicar: os logs daquele span mostram connection pool exhausted, waited 7.9 s — o provedor está lento, e o payment tem um pool de 20 conexões.
6. Mitigar primeiro, entender depois (Resposta a Incidentes): abrir o circuit breaker, colocar os checkouts numa fila ou trocar de provedor.
7. Aprender: o postmortem pergunta por que um provedor lento conseguiu fazer o checkout inteiro de refém — e adiciona um timeout, um bulkhead e um alerta sobre a latência do provedor.

Veja no simulador

Experimente. Em t = 50 s uma das três réplicas do catalog morre. Aperte Run sem mudar nada: todo serviço mostra a utilização como "?" (nada é medido), e por 30 s o balanceador continua mandando um terço das requisições para a réplica morta — cerca de 33% de erros de t = 51 s a 80 s, 93,8% de disponibilidade na execução. Adicione Metrics e conecte ao balanceador, à aplicação e ao banco: os números aparecem, mas os fãs veem exatamente os mesmos erros — medir não conserta nada sozinho. Depois adicione um Health Check conectado ao balanceador: a réplica morta sai da rotação em 3 s em vez de 30 s, e a disponibilidade sobe para 99,4%. O que o último componente, Alerting, muda está em Alertas.

O simulador completo está no System Design Playground.

Health checks

Um health check é o sinal mais simples e o único consumido por máquinas: um load balancer, um orquestrador ou um sistema de service discovery chama um endpoint e decide se uma instância deve receber tráfego ou ser reiniciada. Como as máquinas agem sobre ele automaticamente e em escala, um health check mal projetado é uma das causas clássicas de indisponibilidade total.

O Kubernetes distingue três probes³, e a distinção é o ponto principal:

stateDiagram-v2
    [*] --> Iniciando : container criado
    Iniciando --> Pronto : startup ok, readiness ok
    Iniciando --> Reiniciando : limite de startup excedido
    Pronto --> NaoPronto : readiness falha (sobrecarga, drenando)
    NaoPronto --> Pronto : readiness ok de novo
    Pronto --> Reiniciando : liveness falha (deadlock)
    NaoPronto --> Reiniciando : liveness falha
    Reiniciando --> Iniciando : novo container

Com o Spring Boot Actuator, as probes são grupos de health separados, expostos em /actuator/health/liveness e /actuator/health/readiness⁴:

# application.yaml (order service)
management:
  endpoint:
    health:
      probes:
        enabled: true
      group:
        readiness:
          include: readinessState
        liveness:
          include: livenessState

# Deployment (excerpt) — the order container
startupProbe:
  httpGet: { path: /actuator/health/liveness, port: 8080 }
  periodSeconds: 5
  failureThreshold: 24        # up to 2 minutes to start
livenessProbe:
  httpGet: { path: /actuator/health/liveness, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3         # 30 s of failures before a restart
readinessProbe:
  httpGet: { path: /actuator/health/readiness, port: 8080 }
  periodSeconds: 5
  failureThreshold: 2

Checks rasos vs profundos

Um check raso (shallow) responde "meu processo está vivo?". Um check profundo (deep) também chama as dependências — o banco de dados, o Redis, o provedor de pagamentos. Checks profundos parecem mais honestos, e essa é justamente a armadilha.

Os load balancers na borda usam a mesma ideia (veja Balanceamento de carga): removem um backend após N checks com falha e o recolocam após M sucessos — a histerese evita oscilação.

Quanto custa a telemetria

Observabilidade não é de graça e, numa entrevista — ou na fatura da nuvem —, você precisa raciocinar sobre seu volume como sobre qualquer outra carga de trabalho. Uma estimativa de guardanapo para o BoxOffice num dia normal, com premissas ilustrativas:

Com 100% de amostragem de traces, são mais de 5 TB de traces por mês — antes de a venda relâmpago multiplicar o tráfego por 50. Daí as três alavancas de custo que você verá nesta aula:

• Amostrar traces (guardar os interessantes — erros e requisições lentas — e uma pequena parte do resto), veja OpenTelemetry.
• Cardinalidade limitada nas métricas (nada de IDs de usuário em labels), veja Sinais.
• Níveis, amostragem e camadas de retenção para logs (DEBUG desligado em produção, 7–30 dias em armazenamento quente, depois object storage barato).

O mapa de conceitos da observabilidade

Os cinco componentes de observabilidade descrevem as mesmas requisições por ângulos diferentes, e o contexto compartilhado (exemplars, trace_id) os transforma numa única investigação. O mapa liga cada componente da paleta (verde) aos conceitos de que ele depende (azul) e às aulas que os continuam:

flowchart LR
    svc["app · worker<br/>(BoxOffice services)"]:::comp --> metrics["metrics"]:::comp
    svc --> tracing["tracing"]:::comp
    svc --> logs["logs"]:::comp
    metrics -->|"exemplar"| tracing
    tracing -->|"trace_id"| logs
    metrics --> alerting["alerting"]:::comp
    hc["healthcheck"]:::comp -->|"probes"| svc
    metrics -.- c1["RED, USE, golden signals,<br/>histograms, cardinality"]:::tech
    logs -.- c2["structured logs,<br/>levels, redaction"]:::tech
    tracing -.- c3["traceparent, Collector,<br/>tail sampling"]:::tech
    alerting -.- c4["SLO burn rate, multiwindow,<br/>routing, runbooks"]:::tech
    hc -.- c5["liveness, readiness, startup,<br/>shallow vs deep"]:::tech
    c4 --> c6["incident roles, mitigate first,<br/>postmortems"]:::tech
    c4 -.- d1["SLI, SLO, error budget<br/>(class 9)"]
    c5 -.- d2["Kubernetes probes, LB checks<br/>(classes 4 and 11)"]
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

Relacionados

• Hands-on 8 — Observabilidade: auto-instrumentação com OpenTelemetry e grafana/otel-lgtm no BoxOffice; dashboard RED, traces e um alerta de burn rate.
• Hands-on 9 — Resiliência e caos e Hands-on 10 — Kubernetes: probes, falhas com Toxiproxy, e como observá-las na telemetria.
• Confiabilidade e SLOs: SLIs, SLOs e error budgets — o que os alertas desta aula fazem cumprir.
• Engenharia de desempenho: testes de carga só são úteis se você conseguir ver por que o sistema entorta.
• Exercício: relatório de teste de carga e o game day do projeto.
• Estudo de caso: Ticketing (venda relâmpago do BoxOffice).

Pontos-chave

O que quebra em seguida

O BoxOffice agora se enxerga: um SLO com alerta de burn rate, um dashboard RED e um trace por pedido, da borda ao e-mail passando pelo Kafka — no lab 8, parar o banco aciona alguém em cerca de cinco a sete minutos (cerca de 440 s numa execução de teste). Enxergar não é sobreviver. Às 10h02 o provedor de pagamentos responde em 4 s em vez de 200 ms: o dashboard mostra o p95 do order subindo, o trace põe o tempo na chamada de pagamento, o alerta dispara — e o checkout morre mesmo assim, porque toda thread do order está esperando o provedor e não sobra nenhuma nem para as requisições que nunca o tocam. A observabilidade encurta o tempo para entender uma falha; impedir que uma dependência lenta derrube tudo — timeouts, circuit breakers, bulkheads e experimentos de caos que os comprovem — é a aula 10 — Confiabilidade.