Os 4 sinais de ouro do SRE

Monitorar tudo é monitorar nada. A proliferação de métricas em sistemas distribuídos criou um paradoxo: quanto mais dados, mais difícil identificar o que realmente importa quando algo falha. O Google resolveu esse problema com uma estrutura elegante e universalmente adotada.

Os 4 sinais de ouro do SRE — Latência, Tráfego, Erros e Saturação — são o conjunto mínimo de métricas que toda equipe de operações deve monitorar para medir a saúde real de um serviço. Criados e documentados pelo Google no livro Site Reliability Engineering, esses sinais formam a base de qualquer estratégia de observabilidade eficaz. Neste guia, você vai entender cada sinal, as queries PromQL para implementá-los e como conectá-los a SLOs e error budget.

Por que os 4 sinais de ouro?

Antes de detalhar cada sinal, é importante entender o raciocínio por trás da escolha. O Google identificou que, independentemente da tecnologia, linguagem ou arquitetura de um serviço, quatro dimensões de observabilidade capturam o essencial da experiência do usuário final.

Se a latência está alta, os usuários esperam. Se o tráfego cai abruptamente, algo impediu o acesso. Se os erros sobem, os usuários enfrentam falhas. Se a saturação está elevada, o colapso é iminente. Qualquer degradação de serviço se manifesta em pelo menos um desses quatro sinais antes de se tornar um incidente crítico.

Neste sentido, os 4 sinais de ouro não são apenas métricas de dashboard: são a base para definir SLOs (Service Level Objectives) e calcular o error budget que governa a velocidade de deploy de um time de SRE.

Sinal 1: Latência

Latência é o tempo que o sistema leva para responder a uma requisição. É talvez o sinal mais diretamente ligado à experiência do usuário: serviços lentos são percebidos como quebrados, mesmo que tecnicamente ainda funcionem.

A distinção crítica que o SRE do Google enfatiza é entre latência de requisições bem-sucedidas e latência de requisições com erro. Uma requisição que falha rapidamente tem latência baixa, mas não indica saúde — ela indica falha rápida. Por isso, monitorar apenas a latência média é insuficiente.

A melhor prática é monitorar percentis: P50 (mediana), P95 e P99. O P99 revela a experiência dos usuários mais lentos — que frequentemente são os mais impactados por problemas reais de capacidade ou dependências externas.

PromQL para latência P99 com Prometheus:

histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

No Grafana, configure um painel com os três percentis em um único gráfico para visualizar a distribuição de latência em tempo real e detectar anomalias de cauda longa.

Sinal 2: Tráfego

Tráfego é a medida de demanda no sistema: requisições por segundo (RPS), transações por minuto, eventos processados, conexões ativas. Ele é o contexto que dá significado a todos os outros sinais.

Erros de 1% com 10 RPS têm impacto negligenciável. Erros de 1% com 10.000 RPS significam 100 usuários afetados por segundo. Saturação que aparece com 500 RPS pode indicar um limite de capacidade crítico. Sem tráfego como denominador, os outros sinais perdem contexto.

O tráfego também é essencial para detectar anomalias de acesso: uma queda abrupta pode indicar um problema de DNS ou roteamento antes que qualquer outro sinal dispare. Um pico inesperado pode preceder saturação.

PromQL para taxa de requisições:

rate(http_requests_total[5m])

Para sistemas que processam eventos assíncronos (filas, streams), o tráfego é medido pelo throughput de eventos processados, não por requisições HTTP.

Sinal 3: Erros

Erros medem a taxa de requisições que falham — seja por erro explícito (HTTP 5xx), por erro implícito (HTTP 200 com corpo incorreto) ou por erro de política (respostas acima de 3 segundos que violam o SLO de latência).

A distinção entre erros explícitos e implícitos é frequentemente ignorada. Um serviço que retorna HTTP 200 mas com dados incorretos ou vazios está falhando do ponto de vista do usuário, mesmo que o infrastructure monitoring não o detecte como erro. Por isso, testes sintéticos e monitoramento de conteúdo de resposta são complementos necessários ao monitoramento de status codes.

PromQL para taxa de erros:

rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])

Esse indicador alimenta diretamente o cálculo do error budget: se o SLO é de 99,9% de disponibilidade, cada hora com taxa de erros acima de 0,1% consome budget que o time de desenvolvimento precisará negociar para continuar deployando.

Sinal 4: Saturação

Saturação mede o grau de ocupação dos recursos do sistema — CPU, memória, disco, conexões de banco de dados, threads disponíveis. É o sinal preditivo por excelência: indica quando o sistema está se aproximando de um limite antes que a degradação se manifeste em latência e erros.

A regra prática é: um sistema com CPU consistentemente acima de 80% ou memória acima de 90% está saturado mesmo que ainda esteja respondendo. A margem de segurança acabou, e qualquer pico de tráfego pode causar colapso.

Para sistemas distribuídos, a saturação precisa ser monitorada no nível de cada recurso crítico: não apenas CPU do host, mas também connection pool do banco de dados, capacidade de filas, inodes de filesystem e largura de banda de rede.

PromQL para saturação de CPU:

1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)

PromQL para saturação de memória:

1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)

Conectando os 4 sinais a SLOs e error budget

Os 4 sinais de ouro são mais que métricas operacionais: eles são a matéria-prima para definir SLIs (Service Level Indicators) e, a partir deles, os SLOs que governam o contrato de confiabilidade de um serviço.

Um SLO típico baseado nos 4 sinais poderia ser: “99,9% das requisições devem responder em menos de 500ms e com taxa de erros abaixo de 0,1% em uma janela de 30 dias”. Cada vez que esse objetivo é violado, o error budget é consumido. Quando o error budget acaba, o time precisa pausar novos deploys e focar em confiabilidade — esse é o mecanismo central de governança do SRE.

Ferramentas como Grafana, combinadas com Prometheus, permitem criar SLO dashboards que visualizam em tempo real o consumo do error budget e projetam o burn rate — a velocidade com que o budget está sendo consumido — identificando se o time está caminhando para esgotar o orçamento antes do fim do período.

4 sinais de ouro vs outros frameworks de observabilidade

Os 4 sinais de ouro do SRE são frequentemente comparados a outros modelos de observabilidade. O método RED (Rate, Errors, Duration) é praticamente idêntico mas omite Saturação, sendo adequado para serviços stateless. O método USE (Utilization, Saturation, Errors) foca em recursos de infraestrutura e complementa o RED para a camada de infraestrutura.

Para uma estratégia completa de observabilidade baseada nos três pilares — métricas, logs e traces — os 4 sinais de ouro são o ponto de partida para as métricas. Logs e traces fornecem o contexto necessário para diagnosticar por que um sinal está degradado.

Conclusão

Os 4 sinais de ouro do SRE — Latência, Tráfego, Erros e Saturação — são a estrutura mais eficiente para monitorar a saúde de qualquer serviço digital. Eles eliminam o ruído de centenas de métricas irrelevantes e focam o time nas dimensões que realmente refletem a experiência do usuário.

Implementar esses sinais com PromQL, visualizá-los no Grafana e conectá-los a SLOs e error budget é o caminho para uma operação de TI orientada a confiabilidade e dados. Se você quer implementar essa abordagem na sua infraestrutura, fale com nossos especialistas.