Os 4 sinais de ouro do SRE
Autor: Pedro Tebaldi PM do KeepGreen
Revisão técnica: Ednilson Correa SREMonitorar 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 capítulo de monitoramento do 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.
A tabela abaixo mostra como cada sinal se materializa em três tipos de serviço. O sinal é o mesmo; muda a métrica que o representa.
| Sinal | API HTTP síncrona | Fila ou stream | Banco de dados |
|---|---|---|---|
| Latência | P99 da requisição, com o alvo em milissegundos | Idade da mensagem mais antiga ainda na fila | P99 do tempo de consulta, separado por tipo de comando |
| Tráfego | Requisições por segundo | Mensagens consumidas por segundo | Transações e leituras por segundo |
| Erros | 5xx sobre o total, mais a resposta que estourou o alvo de latência | Mensagens que foram para a fila morta sobre o total | Conexões recusadas, deadlocks e consultas abortadas por tempo |
| Saturação | CPU acima de 80% ou memória acima de 90% | Fila que cresce por mais tempo que o intervalo de consumo | Conexões em uso sobre o máximo do pool, e espera por bloqueio |
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:
Rodamos as duas formas no dia 3 de setembro de 2026, em Prometheus 3.13.2, com dois serviços instrumentados. A primeira devolveu duas séries: 1,296 s e 0,785 s. A segunda devolveu 0,877 s, que é o P99 do conjunto.
Repare que 0,877 s não é a média das duas séries nem a maior delas. Percentil não soma: quem tira a média dos P99 de cada réplica publica um número que não existe. A documentação da função é explícita: o rótulo le precisa entrar na cláusula by.
No mesmo laboratório, a latência média ficou em 75 ms e o P99 em 877 ms. Assim, um SLO de 500 ms passaria folgado pela média e estouraria no P99, quase doze vezes maior. Por isso o percentil vem antes da média em qualquer painel de latência.
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:
No laboratório, a primeira forma devolveu quatro séries e nenhuma delas era o tráfego do serviço. A segunda devolveu 6,77 requisições por segundo, das quais 4,52 em pedidos e 2,25 em checkout. Em resumo, agregue antes de ler o número.
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:
Essa primeira forma parece certa e não é. O Prometheus só divide séries que tenham rótulos idênticos. O lado de cima carrega status="500", portanto apenas as séries de 5xx casam: a divisão vira 5xx sobre 5xx.
Na prática, a consulta devolve sempre 1, ou seja, 100% de erro. Com 0,32% de erro real, ela devolveu 1. Com o checkout em incidente a 8,32%, devolveu 1 de novo.
Veja abaixo as duas consultas no mesmo instante, com o serviço de checkout já degradado.
Corrigida, a consulta enxergou os dois estados: 0,61% em pedidos e 8,32% em checkout. Em contrapartida, um alerta preso à forma errada dispara no primeiro deploy e nunca mais cala. Essa é a receita da fadiga de alertas.
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: 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 e de memória:
Trocar a métrica de memória muda o veredito do alerta. No mesmo instante e na mesma máquina, o cálculo por MemFree apontou 99,3% de saturação; o cálculo por MemAvailable apontou 10,6%.
Essa diferença de quase 89 pontos percentuais é cache de página: 28,2 GB que o Linux devolve assim que a aplicação pedir. Com a regra dos 90%, o alerta por MemFree tocaria a noite inteira numa máquina com 10% de uso real. Ou seja, limiar de memória só é defensável junto com o nome da métrica.
O guia completo de SRE, em 35 páginas.
Escrito pelo time da OpServices: fundamentos da engenharia de confiabilidade, o que faz um SRE, as métricas que medem confiabilidade de verdade e a rotina de um time — do primeiro conceito ao plantão.
Só o e-mail. Sem spam, e seus dados protegidos pela LGPD.
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.
O orçamento de erro é aritmética, não opinião: ele é a fração do mês em que o serviço pode falhar sem quebrar a promessa. Cada nove a mais divide esse tempo por dez.
| SLO de disponibilidade | Orçamento em 30 dias | Equivalente por dia |
|---|---|---|
| 99% folgado | 7 h 12 min | 14 min 24 s |
| 99,5% | 3 h 36 min | 7 min 12 s |
| 99,9% comum | 43 min 12 s | 1 min 26 s |
| 99,95% | 21 min 36 s | 43 s |
| 99,99% caro | 4 min 19 s | 9 s |
Guarde a coluna da direita, porque é ela que o plantão sente. Com 99,99%, nove segundos de falha por dia já consomem o mês inteiro. Nenhum time chega lá sem automação de recuperação.
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, que é 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. Os três medem a mesma operação de ângulos diferentes. A escolha depende de onde o seu problema costuma nascer.
| Modelo | O que cobre | O que deixa de fora | Quando escolher |
|---|---|---|---|
| 4 sinais de ouro | Latência, tráfego, erros e saturação: a experiência do usuário mais o limite de capacidade | Não separa a saturação por recurso, então não diz qual peça encheu | Serviço voltado ao usuário, quando você só pode acompanhar quatro métricas |
| RED | Rate, Errors e Duration: tudo medido na borda da requisição |
Saturação. O painel fica verde até o recurso acabar de uma vez | Microsserviço sem estado, onde a capacidade é elástica e some do problema |
| USE | Utilization, Saturation e Errors recurso por recurso: CPU, disco, rede, memória |
Latência e demanda. Não enxerga o usuário esperando | Camada de infraestrutura, e como complemento do RED quando falta o porquê |
Repare que os três compartilham Erros. Em contrapartida, só os 4 sinais de ouro juntam a demanda e o limite de capacidade na mesma leitura. Esse par é o que antecipa o colapso antes de ele chegar ao usuário.
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.
Transformamos operações reativas em engenharia de confiabilidade (SRE).
Implementamos SLIs, SLOs e Error Budgets para reduzir o MTTR e eliminar a fadiga de alertas das suas equipes de operação.
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.
Perguntas Frequentes
O que são os 4 sinais de ouro do SRE?
Como monitorar latência com Prometheus?
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))) retorna o P99 do serviço. Sem o sum by (le), o Prometheus devolve um percentil por réplica em vez do número do serviço. Monitore P50, P95 e P99 em conjunto para detectar a cauda longa que a média esconde.Qual a diferença entre os 4 sinais de ouro e o método RED?
Como os 4 sinais de ouro se conectam a SLOs?
