O método RED: Uma nova estratégia para monitorar microsserviços

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado jul/2024Atualizado set/2026

Rate, errors e duration: as três métricas que dizem se um serviço está entregando bem para quem o chama.

O método RED reduz o monitoramento de um serviço a três perguntas. Ou seja, quantas requisições chegam por segundo (rate), que fatia delas falha (errors) e quanto tempo cada uma leva (duration). Tom Wilkie desenhou o conjunto em 2015 para responder a uma pergunta única: o serviço está entregando bem para quem depende dele?

A promessa é a padronização. Como todo serviço expõe as mesmas três métricas, um painel só serve para o serviço de pedidos e para o de pagamentos. Dessa forma, quem está de plantão consegue ler o gráfico de um serviço que nunca abriu.

Este artigo mostra as três consultas rodando contra um laboratório próprio, com Prometheus 3.13.2 e Grafana 12.1.1 em Docker. A medição é de 3 de setembro de 2026. Em seguida, o texto mostra onde o método não enxerga, também com número medido.

O que são rate, errors e duration

As três letras nomeiam três perguntas sobre o mesmo serviço. Rate mede o volume que chega, errors mede a fração que falha e duration mede quanto tempo o chamador espera. Nenhuma das três olha para dentro do processo. Ou seja, todas descrevem o que o cliente do serviço percebe.

• Rate (R): requisições por segundo que o serviço atende.
• Errors (E): a fatia dessas requisições que termina em falha.
• Duration (D): a distribuição do tempo de resposta, nunca a média sozinha.

No Prometheus, as três saem de duas métricas apenas. Um counter chamado http_requests_total, com o código de status em rótulo, entrega R e E. Já um histogram chamado http_request_duration_seconds entrega D. Portanto, instrumentar um serviço para RED significa declarar duas métricas, não três.

As três consultas em PromQL

O laboratório sobe dois serviços instrumentados, um gerador de carga, o Prometheus e o Grafana. Cada serviço erra de propósito em 0,4% das requisições. Além disso, cada um tem uma cauda lenta deliberada, para o histograma ter o que mostrar. As consultas abaixo rodaram contra ele.

# R -- taxa: requisicoes por segundo, somada por servico
sum by (service) (rate(http_requests_total[5m]))
#   pedidos 26,59 req/s   pagamentos 20,82 req/s

# E -- erros: a FATIA que falha, nunca a contagem
sum by (service) (rate(http_requests_total{status="5.."}[5m]))
  / sum by (service) (rate(http_requests_total[5m]))
#   pedidos 0,41%        pagamentos 0,37%

# D -- duracao: percentil sobre o histograma, com sum by (le)
histogram_quantile(0.99,
  sum by (service, le) (rate(http_request_duration_seconds_bucket[5m])))
#   pedidos 723 ms        pagamentos 999 ms

Note o sum by (service) no cálculo de erros. Sem ele, o casamento de vetores exige rótulos idênticos dos dois lados. O lado esquerdo carrega status="500", portanto a divisão vira 5xx dividido por 5xx. O resultado é 1, ou seja, 100% de erro com o serviço saudável.

O painel RED no Grafana

Os três painéis empilhados são o formato padrão do método: mesma janela de tempo, mesma escala, uma letra por linha. A imagem abaixo mostra o laboratório em regime estável, isto é, sem nenhum incidente em curso. Em cada painel, as duas séries identificam os dois serviços.

Ler os três juntos é o que dá sentido a cada um. Por exemplo, uma taxa de erro de 0,4% significa coisas diferentes a 3 requisições por segundo e a 47 por segundo. É por isso que E entra como proporção, não como contagem absoluta.

Por que a média engana e o p99 não

D é a letra que mais dá margem a erro, porque a média é o número mais fácil de calcular. Contudo, o mesmo histograma lido dos dois jeitos deu números que não se parecem no laboratório.

# O jeito facil: media aritmetica do mesmo histograma
sum(rate(http_request_duration_seconds_sum{service="pedidos"}[5m]))
  / sum(rate(http_request_duration_seconds_count{service="pedidos"}[5m]))
#   => 61,3 ms

# O jeito que enxerga a cauda: percentil 99 do MESMO dado
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket{service="pedidos"}[5m])))
#   => 723,5 ms   ou 11,8 vezes a media

# p50  47,4 ms  |  p95  97,5 ms  |  p99  723,5 ms

A diferença tem causa conhecida: a média divide a soma dos tempos pela contagem de requisições. Dessa forma, uma cauda de 3% se dilui em 97% de respostas rápidas. Um limiar de alerta na média em 200 milissegundos nunca dispara, embora 1% dos usuários espere mais de 700 milissegundos.

Por isso o alerta de duration se escreve sobre percentil. O percentil, por sua vez, precisa de sum by (le) para somar os buckets antes do cálculo. Some primeiro, calcule o percentil depois: percentil não é média e não se soma.

De onde veio o método RED

Tom Wilkie criou o método em 2015, quando trabalhava na Weaveworks, depois que um funcionário novo perguntou qual era sua filosofia de monitoramento. A motivação foi prática: o método USE, de Brendan Gregg, descreve máquina, disco e rede, mas não descrevia serviço.

O parentesco com os quatro sinais de ouro do Google é direto. Os sinais de ouro são latência, tráfego, erros e saturação. Assim, o RED fica com os três primeiros e deixa a saturação de fora. Wilkie descreve os dois como complementares em sua explicação sobre como instrumentar serviços. Isto é: um cuida da felicidade do usuário, o outro da felicidade da máquina.

Essa divisão explica os benefícios que o método entrega. As três métricas são as mesmas em todo serviço, portanto o time treina uma leitura só. Além disso, padronizar as métricas padroniza os painéis, os alertas e a automação em cima deles.

O que o RED não enxerga

A saturação que ficou de fora tem preço. Para medir esse preço, o teste manteve a configuração dos serviços intacta. Em seguida, só aumentou a concorrência do gerador de carga, de 6 para 24 conexões simultâneas.

# Unica mudanca: a concorrencia do gerador de carga, de 6 para 24.
# TAXA_ERRO e LATENCIA_BASE dos servicos ficaram intactas.
docker compose -f docker-compose.yml -f carga-alta.yml up -d carga

#                     saudavel     carga alta    variacao
#   R (dois servicos)  47,4 req/s   219,1 req/s   4,6x
#   E                   0,41%         0,38%       nenhuma
#   D p50              47,4 ms       76,1 ms      1,6x
#   D p95              97,5 ms      229,9 ms      2,4x
#   D p99             723,5 ms      755,4 ms      +4%
#   pool ocupado       1 de 8        8 de 8       cheio

Repare no que cada letra fez. R subiu 4,6 vezes, o que era esperado. Nenhuma requisição passou a falhar, portanto E ficou onde estava. No entanto, o p99, que é onde quase todo alerta de latência se apoia, subiu apenas 4%.

Ao mesmo tempo, o pool de conexões dos dois serviços saiu de 1 slot ocupado para os 8. Ele ficou cravado ali pelos quatro minutos seguintes. O serviço estava sem folga para absorver mais nada. Contudo, nenhum dos três painéis disse isso.

Ainda assim, um número da família reagiu: o p95 foi de 98 para 230 milissegundos. Ele não aparece no painel, que mostra o p99. E o p99 mal se mexeu por um motivo específico. A cauda lenta que o laboratório injeta de propósito é maior que a espera na fila, portanto ela continua mandando no percentil.

Em suma, o RED mostrou o tráfego subir, embora não tenha mostrado o serviço chegar ao limite. Nada nos três painéis diz quanto faltava para o serviço estourar. Responder isso exige uma métrica de saturação que o método deliberadamente não pede.

Há um segundo limite, dessa vez de escopo. RED descreve serviço que responde a requisição, portanto processamento em lote e fluxo contínuo ficam mal descritos por ele. Nesses casos, tamanho de fila e atraso de processamento dizem mais que taxa e duração.

Nenhum desses limites é novidade para quem escreve sobre o método. Tim Yocum, da InfluxData, registra a mesma ressalva em seu artigo na InfoWorld. A recomendação é combinar RED com USE, nunca escolher entre os dois.

Por onde começar

Comece pelo serviço que mais aparece nos incidentes, com as duas métricas do laboratório. São elas: um contador de requisições com status em rótulo e um histograma de duração. Assim, as três consultas deste artigo funcionam sem instrumentação extra.

Depois, escreva o alerta de duration sobre percentil, nunca sobre média. O de errors sai sobre proporção, nunca sobre contagem. Em seguida, use as três consultas para montar dashboards no Grafana uma vez só e reaproveite o painel em todos os serviços. É justamente isso que o método existe para permitir.

Por fim, trate a saturação em separado. O RED avisa que o usuário está esperando, embora não diga quanto falta para o serviço cair. Essa segunda pergunta o monitoramento com Prometheus responde com métricas de recurso ao lado das de serviço.

Em resumo, se a sua operação precisa dessa leitura montada e sustentada em produção, fale com um especialista da OpServices.