O método RED para serviços orientados a requisições, com exemplars que ligam um bucket lento a um trace

Objetivo

Dar a todo serviço orientado a requisições os mesmos três sinais, para que dashboards, alertas e perguntas durante incidentes tenham o mesmo aspecto em toda a arquitetura: Rate (requisições por segundo), Errors (requisições que falham) e Duration (quanto tempo as requisições levam). Este é o método RED, que o post da Grafana citado atribui a Tom Wilkie como equivalente, voltado a microsserviços, do método USE, que se aplica a recursos de hardware.

Pré-requisitos

Uma biblioteca de métricas com contadores e histogramas, templates de rota de baixa cardinalidade e, opcionalmente, uma configuração de tracing cujos trace IDs possam ser anexados às observações das métricas.

Passos

1. Para cada serviço, exponha um contador <svc>_requests_total{route, method, code}, incrementado quando uma requisição termina, e um histograma <svc>_request_duration_seconds com os mesmos labels. Os erros são derivados de code (5xx, ou um label de falha específico do domínio), e não de um contador separado que pode divergir do total.
2. Monte uma linha de dashboard por serviço: taxa de requisições, proporção de erros (erros divididos pelo total na mesma janela) e percentis de duração calculados a partir do histograma. Ordene as linhas conforme o fluxo de dados, de modo que a linha de cima seja a chamadora da linha de baixo.
3. Crie alertas para a proporção de erros e para o objetivo de duração, não para a taxa; mudanças na taxa servem de contexto.
4. Anexe exemplars. O OpenMetrics define um exemplar como uma referência a dados fora do conjunto de métricas, na maioria das vezes um trace ID, formado por um conjunto de labels e um valor com timestamp opcional, com o comprimento combinado de nomes e valores dos labels limitado a 128 code points. A especificação do SDK de métricas do OpenTelemetry descreve um exemplar como uma medição registrada que expõe o valor, o momento da chamada, os atributos descartados pela agregação e, para instrumentos síncronos, o trace ID e o span ID do span ativo. O filtro de exemplars padrão desse SDK deve ser TraceBased, de modo que só medições feitas dentro de um span amostrado sejam elegíveis para virar exemplars. Outras bibliotecas cliente podem exigir que o trace ID seja passado junto com a observação; consulte a documentação da biblioteca.
5. Ative o armazenamento de exemplars no backend de métricas e configure os painéis de histograma do dashboard para exibir pontos de exemplar que abram o trace ao clicar.
6. Verifique a ligação: escolha um bucket lento no dashboard, abra o exemplar e confirme que o trace mostra a requisição que gerou a observação.

Resultado esperado

Qualquer pessoa de plantão consegue ler a saúde de qualquer serviço nos mesmos três painéis e ir de "o p99 subiu às 14:02" a um trace concreto de uma requisição lenta, sem precisar fazer buscas.

Limites e base de verificação

O RED cobre componentes orientados a requisições; filas e jobs em lote precisam de indicadores de atualidade (freshness) e de último sucesso, e a exaustão de recursos exige o USE. Os exemplars são tão bons quanto a amostragem de traces: uma requisição lenta não amostrada não deixa exemplar. Os limites dos buckets determinam quais percentis um histograma clássico consegue responder.