Entendendo os conceitos de RED e USE

No mundo da Engenharia de Confiabilidade do Site (SRE) e da administração de sistemas, a quantidade de dados disponíveis pode ser esmagadora. Com a explosão de microsserviços e a complexidade da nuvem, um engenheiro pode facilmente se afogar em milhares de métricas sem saber exatamente para onde olhar quando um incidente ocorre.

É comum encontrar dashboards coloridos e complexos que, na hora da crise, não respondem à pergunta fundamental: “O problema está na infraestrutura ou na aplicação?”. Para resolver essa “paralisia por análise”, a comunidade técnica consolidou dois frameworks mentais essenciais para estruturar a observabilidade: os Conceitos de RED e USE.

Neste artigo técnico, vamos dissecar essas duas metodologias, entender suas origens, aplicações práticas e como elas devem coexistir em uma estratégia robusta de observabilidade.

O Dilema das Métricas: Por que precisamos de Frameworks?

Antes de entrar nas siglas, precisamos entender o problema. Antigamente, monitorávamos “se o servidor estava ligado”. Hoje, monitoramos latência de cauda (P99), consumo de threads, IOPS de disco e throughput de rede distribuída.

Sem uma metodologia, as equipes de operações tendem a coletar tudo e alertar sobre tudo. Isso gera “Fadiga de Alerta”. O Método USE e o Método RED funcionam como filtros cognitivos. Eles dizem ao engenheiro quais sinais são vitais (Sinais Dourados) e quais são apenas ruído.

Eles dividem o mundo em duas perspectivas claras:

• USE: Foca na saúde do recurso (Interno/Infraestrutura).
• RED: Foca na saúde da requisição (Externo/Serviço).

O Método USE: Utilization, Saturation, Errors

Criado por Brendan Gregg, uma autoridade mundial em performance de sistemas, o Método USE é orientado a recursos. Ele é ideal para diagnosticar problemas de infraestrutura física ou virtual (CPUs, Memória, Discos, Barramentos).

A premissa é: “Para cada recurso do sistema, verifique a Utilização, a Saturação e os Erros”.

Vamos detalhar cada pilar:

1. Utilization (Utilização)

Representa a porcentagem de tempo que o recurso esteve ocupado processando trabalho.
Por exemplo, uma CPU a 90% de utilização significa que, em 90% do tempo amostrado, ela estava executando instruções. É importante notar que alta utilização não significa necessariamente um problema, mas indica que o recurso está sendo bem aproveitado. O problema surge quando a utilização impede novos trabalhos de serem processados.

2. Saturation (Saturação)

Aqui reside o verdadeiro gargalo. A saturação é a medida do trabalho que foi enfileirado porque o recurso não pôde processá-lo imediatamente.
Se a Utilização é 100% e a Saturação é alta (fila grande), a performance degrada drasticamente. Em discos, isso é visto na fila de I/O. Em memória, pode ser visto através de swapping ou page faults excessivos. A saturação é o indicador principal de que você precisa escalar sua infraestrutura (Scale-up ou Scale-out).

3. Errors (Erros)

Contagem de eventos de erro do dispositivo. Erros de hardware (como bad blocks em disco ou erros de paridade em memória) ou erros de software (drops de pacotes na interface de rede por falta de buffer).
Diferente da utilização e saturação, a tolerância para erros em infraestrutura geralmente é zero.

Para aprofundar-se na teoria original, a documentação de Brendan Gregg sobre o USE Method é a leitura obrigatória.

O Método RED: Rate, Errors, Duration

Enquanto o USE olha para o servidor, o Método RED, popularizado por Tom Wilkie (hoje na Grafana Labs), olha para o serviço. Ele é uma simplificação dos “Google Golden Signals” e é perfeitamente adaptado para arquiteturas de microsserviços e APIs.

O foco aqui não é se a CPU está quente, mas se o usuário (ou o serviço chamador) está feliz.

Os três pilares do RED são:

1. Rate (Taxa)

O número de requisições que o serviço está recebendo por segundo.
Monitorar a taxa é crucial para entender a demanda. Um aumento repentino na taxa (spike) pode explicar por que a latência subiu ou por que o servidor travou (cenário de DDoS ou viralização). Uma queda abrupta na taxa pode indicar problemas de conectividade upstream.

2. Errors (Erros)

O número de requisições que falharam.
No contexto HTTP, estamos falando explicitamente de códigos 5xx (erros de servidor). Códigos 4xx (erros de cliente) também são importantes, mas geralmente indicam problema na chamada, não na saúde do serviço em si. A métrica de erros deve ser absoluta e também relativa (percentual de falha sobre a taxa total).

3. Duration (Duração)

O tempo que as requisições levam para serem processadas (Latência).
Aqui, médias são perigosas. Dizer que a “média é 200ms” esconde o fato de que 10% dos usuários estão esperando 5 segundos. Por isso, no Método RED, a Duração deve ser sempre visualizada em percentis (P50, P90, P99). Isso garante que você esteja monitorando a experiência da maioria e também dos casos extremos.

Para saber mais sobre a aplicação em microsserviços, recomendamos a leitura sobre os princípios de monitoramento em tempo real focados em APM.

Cruzando os Dados: A Estratégia Combinada

O erro mais comum é escolher apenas um. Uma estratégia de observabilidade madura utiliza ambos os conceitos de RED e USE de forma complementar.

Imagine um cenário de incidente:
1. O Alerta RED dispara: O dashboard de serviços mostra que a Duração (Duration) da API de Checkout subiu para 3 segundos e a taxa de Erros aumentou.
2. A Investigação começa: Sabemos que o cliente está sofrendo. Mas por quê? O código mudou? O tráfego aumentou?
3. Consulta ao USE: O engenheiro desce para o nível de infraestrutura (via telemetria detalhada) e aplica o método USE nos nós do cluster de banco de dados.
4. A Causa Raiz: Ele descobre que a Saturação de disco está altíssima, causada por um backup agendado rodando no horário errado, competindo por I/O.

Sem o RED, você não saberia que o usuário estava sendo impactado (talvez a fila de disco fosse invisível para um monitoramento básico). Sem o USE, você veria a lentidão, mas não saberia que a causa era o disco, podendo culpar erroneamente a aplicação.

Essa correlação é a essência do trabalho de um SRE.

Ferramentas e Implementação

Implementar os conceitos de RED e USE exige ferramentas que suportem coleta de métricas em séries temporais.

Para o RED, ferramentas de APM (Application Performance Monitoring) e Service Mesh (como Istio ou Linkerd) já entregam essas métricas quase que nativamente. O Prometheus é o padrão da indústria para coletar essas métricas de microsserviços.

Para o USE, agentes de infraestrutura (como Node Exporter) são necessários para extrair dados do Kernel do Linux ou do Hypervisor.

Um desafio comum é a visualização. Dashboards devem ser organizados hierarquicamente:

1. Nível 1 (Negócio): Taxa de sucesso de transações.
2. Nível 2 (Serviço – RED): Latência, Throughput e Erros por endpoint.
3. Nível 3 (Infra – USE): CPU, Memória, Rede e Disco por nó/pod.

Conclusão

Adotar os Conceitos de RED e USE não é apenas sobre configurar ferramentas; é sobre criar uma linguagem comum entre desenvolvedores e operações. Quando todos entendem o que é saturação e o que é latência de cauda (P99), a resolução de incidentes torna-se científica e menos baseada em “achismos”.

Enquanto o Método RED nos diz “O que” o usuário está sentindo, o Método USE nos ajuda a explicar o “Porquê” do ponto de vista físico. Juntos, eles formam a base de qualquer sistema resiliente.

Caso tenha interesse em conhecer mais sobre nossos modelos comerciais para este tipo de serviço e como implementar observabilidade avançada na sua empresa, fale com nossos especialistas.