Latência, Tráfego, Erros, Saturação

Quatro Números Cobrem a Maior Parte das Operações

Do livro Google SRE. Quatro sinais que você mede em cada camada de serviço. Se você instrumentar bem esses quatro, você detecta a maioria dos problemas de produção antes que os usuários o façam.

Latência: quanto tempo uma requisição leva? Relate distribuições, não apenas médias. A p99 (latência do 99º percentil) é mais importante que a média, pois a latência de cauda é o que os usuários percebem como 'lento'. Um serviço com média de 50 ms e p99 de 5.000 ms tem um problema real que a maioria dos usuários nunca percebe, mas os 1% mais afetados percebem absolutamente.

Tráfego: quantas requisições por segundo? Total de requisições, por endpoint, por código de status, por região. Linha de base conhecida; alerte sobre anomalias (queda súbita = problema de entrada; pico súbito = aumento de demanda ou ataque).

Erros: taxa de requisições falhas. Distinga 4xx (erros de cliente, não são sua culpa) de 5xx (erros de servidor, são sua culpa). Rastreie a taxa de erro como uma porcentagem do tráfego, não como contagens absolutas, para que os alertas funcionem em diferentes níveis de carga.

Saturação: o quanto o sistema está cheio? Utilização de CPU, memória, profundidade da pool de conexões, comprimento da fila. O indicador precursor. A saturação aumenta antes que a latência ou os erros se deteriorem. Um tier em 90% de saturação está a um minuto ruim de distância do colapso da fila.

Em um Tier de Proxy Especificamente

Cada sinal se destaca na camada de borda:

- Latência no proxy: duração do handshake TLS, tempo de conexão upstream, total de requisição-resposta. Medidos separadamente porque estão em partes diferentes do caminho.

- Tráfego no proxy: total de requisições/segundo, distribuição por backend (um backend quente sinaliza viés do balanceador de carga), detalhamento por código de status.

- Erros no proxy: 4xx de clientes (seus usuários acessando endpoints inválidos), 5xx de backends (seus serviços falhando), erros internos do proxy (502 = backend inacessível, 504 = timeout do backend).

- Saturação no proxy: contagem de sessões TLS, profundidade da pool de conexões upstream, CPU no próprio proxy (a terminação TLS é intensiva em CPU).

Dica de ouro: um aumento súbito em 502s com baixa latência do backend significa que o backend está encerrando a conexão antes de responder (reset de conexão, crash, OOM). Um aumento em 504s significa que o backend está lento, mas ainda respondendo. Leia o código de erro; ele indica onde a falha está ocorrendo.

Leia os Sinais

Seu dashboard mostra o seguinte nos últimos 10 minutos:

- Tráfego: praticamente estável em 800 req/s (sem pico)

- Latência: p50 estável em 40ms, p99 subiu de 200ms para 2.500ms em 5 minutos e continua subindo

- Erros: taxa de 4xx estável em 0,3% (ruído de fundo normal); taxa de 5xx subiu de 0,1% para 1,2% (principalmente 504 Gateway Timeout)

- Saturação: CPU do backend subiu de 45% para 78% nos mesmos 5 minutos; CPU do proxy estável em 30%

Quando Escalar, Quando Drenar, Quando Acionar Alertas

Decisões de Capacidade Necessitam de Gatilhos

Observar métricas é fácil. Saber quando agir sobre elas é a disciplina.

Escale quando: a saturação cruzar um limite sustentado (por exemplo, CPU do backend >70% por 5 minutos), ou a profundidade da fila crescer além de uma meta, ou a latência p99 exceder o SLO. O gatilho deve disparar antes que as coisas quebrem, não no momento da quebra.

Drene uma réplica quando: ela estiver consistentemente lenta / com erros enquanto as pares estão saudáveis (uma réplica operando em alta temperatura muitas vezes é um problema de nível de host, não de aplicação), ou ao implantar uma nova versão, ou ao retirar uma réplica de forma graciosa.

Acione um humano quando: um SLO estiver sendo consumido mais rápido do que o orçamento de erros pode sustentar, ou um gatilho de saturação disparar sem que o auto-escalonamento o absorva, ou um padrão de cascata aparecer (taxa de erro + taxa de repetição ambas em alta).

Não acione quando: um único minuto ruim se resolver sozinho, ou trabalhos em lote de fundo causem flutuações periódicas esperadas, ou ruído cruze o limite (o limite está errado, não o sistema).

SLOs e Consumo do Orçamento de Erros

Um SLO (objetivo de nível de serviço) define o desempenho aceitável: 'taxa de sucesso >= 99,9% em uma janela de 28 dias'. O complemento (0,1%) é o orçamento de erros.

Taxa de consumo (burn rate): a velocidade com que você está consumindo o orçamento de erros. Se você consumir 10% do orçamento em 1 hora, a taxa é 240x mais rápida do que o sustentável (1 hora é 1/672 de uma janela de 28 dias; consumir 10% nessa janela = 10% × 672 = 6720% projetado para a janela completa, quando apenas 100% é permitido).

Alertas de taxa de consumo em múltiplas janelas: acionar alertas quando ambas as janelas (5 minutos a uma taxa de 14,4x & 1 hora a uma taxa de 6x) consumirem o orçamento mais rápido do que o sustentável. Detecta tanto falhas rápidas quanto degradações lentas.

Por que isso importa para a capacidade: um serviço operando com um SLO de 99,9% com uma folga de 1% pode absorver pequenas instabilidades. Um serviço em 99,93% (apenas atingindo o SLO) está a um dia ruim de violar o objetivo. As decisões de capacidade devem visar uma margem confortável de SLO, não o mínimo que o atinge.

Uma Decisão de Capacidade Sob Observação

Seu serviço tem um SLO de 99,9% de solicitações bem-sucedidas em 28 dias. Estado atual do monitoramento na última hora:

- Taxa de sucesso: 99,5% (sustentada por 30 minutos)

- CPU do backend: média de 82% em toda a frota (meta: 70%)

- Latência p99: 800 ms (meta do SLO: <500 ms)

- Tráfego: 1.400 req/s, subindo a partir da linha de base de 1.000 req/s (40% acima do normal; tendência ainda em alta)

- Autoescalabilidade: configurada para adicionar réplicas quando o CPU > 80% sustentado por 5 min; atualmente em meio a uma escalação que adicionará 3 réplicas em ~90 segundos

Desenhe um Plano de Observabilidade para Lançamento

Síntese

Agora você pode projetar um /health que detecta falhas reais, um /version que permite verificar implantações, painéis dos quatro sinais de ouro em uma camada de proxy e gatilhos de capacidade vinculados à taxa de consumo de SLO.

Aplique os quatro.

Seu time está lançando o search.example.com (o serviço de busca da lição sobre modos de falha). O time deseja disponibilizar observabilidade que detecte problemas antes dos usuários, com uma matriz clara de decisão de acionamento ou não. SLO: 99,9% de solicitações bem-sucedidas, latência p99 < 300 ms, em uma janela de 28 dias.

Encerrando o Curso

Encerrando o Curso

Você concluiu todas as cinco lições:

- Proxies & Origins: a forma da camada de borda que quase todo serviço web público utiliza

- Escala Horizontal Stateless: por que uma camada sem estado se multiplica de forma barata e como dimensioná-la

- Separação de Ingresso e Egresso: por que uma caixa se torna duas e o modo de falha que a força

- Modos de Falha e Raio de Ação: SPOFs, cascatas, pós-mortems, itens de ação sem culpa

- Observabilidade e Capacidade (esta): o que medir para que os problemas apareçam antes dos usuários

O fio condutor: um sistema distribuído em escala web não é mágica. É um pequeno conjunto de padrões (proxy reverso, réplicas sem estado, separação de ingresso/egresso, bulkheads e circuit breakers, quatro sinais dourados) composto de forma cuidadosa. Uma vez que você reconhece os padrões, vê-os em toda arquitetura de produção.

Aulas complementares: cinco aulas de geometria-* reconfiguram o mesmo material como teoria dos grafos e geometria. Elas funcionam bem em qualquer ordem.

Muito bem.