- 01Entender
- 02Priorizar
- 03Actuar
A maioria das equipas não tem um problema de falta de metrica. Tem um problema de seleção. Golden Signals, RED e USE São três quadros simples para observar serviços e recursos sem converter cada gráfico em alerta.
Os três métodos numa tabela
| Método | Sinais | Melhor uso |
|---|---|---|
| Golden Signals | Latência, tráfego, erros, saturação | Saúde dos serviços orientados para os utilizadores |
| RED | Rato, Erros, Duração | APIs, microserviços e transacções |
| USE | Utilização, Saturação, Erros | Infraestrutura e recursos limitados |
O RED pode descrever uma API e o USE explicar por que razão o recurso que a sustenta está saturado.
Golden Signals
Google SRE propõe quatro sinais fundamentais.
Latência
Tempo necessário para responder a um pedido. Você deve separar respostas bem sucedidas e fracassadas e analisar percentiles. Um erro pode responder rapidamente e melhorar falsamente a média.
Tráfico
Solicita que receba o sistema: pedidos por segundo, transações, sessões, mensagens ou consultas. Forneça contexto para interpretar os outros sinais.
Erros
Pedidos falhados de forma explícita, implícita ou por política. Um HTTP 200 com resultado incompleto pode também ser um erro de negócio.
Saturação
Quanto o seu limite está perto: colas, fios, ligações, CPU ou capacidade. A saturação anticipa a degradação antes do esgotamento total.
Método RED
RED simplifica a vista por serviço:
- Taxa: Quantas operações processa.
- Erros: Quantos falham.
- Duração: Quanto tempo demoram.
É ideal para mapas de microserviços porque permite comparar componentes com uma linguagem comum. Um dashboard RED por serviço deve incluir versão e ambiente para relacionar alterações.
USE método
USE aplica-se a cada recurso:
- Utilização: Percentagem de tempo ou capacidade utilizada.
- Saturação: trabalho em espera de que não possa ser imediatamente atendido.
- Erros: falhas do recurso.
Exemplos:
| Recurso | Utilização | Saturação | Erros |
|---|---|---|---|
| CPU | tempo ocupado | raiz da fila | erros de máquina |
| Disco | tempo activo | E/S da fila | operações falhadas |
| Pool DB | ligações usadas | pedidos à espera | timeouts |
| Fila | consumo/capacidade | profundidade ou idade | Mensagens Falhous |
Um CPU a 90 % não implica necessariamente um problema. Se não existir uma fila e o SLO estiver completo, pode representar um uso eficiente.
Do dashboard à alerta
Não todas as metricas merecem a paginação de uma pessoa, um alerta urgente deve cumprir três condições:
- Existem impactos ou riscos iminentes.
- Uma pessoa pode executar uma acção.
- A urgência justifica interrompê-la.
Os alertas baseados em sintomas — erros ou latência em relação a um SLO — são geralmente mais úteis do que os limiares isolados de recursos. USE fornece contexto para diagnosticar a causa.
SLO e burn taxa: adicionar urgência de negócios
Os sinais mostram comportamento; um SLO define quanto deterioramento tolera o serviço. erro de orçamento representa a margem permitida e o Burn rate Indica a velocidade de consumo.
Um alerta por burn rate evita dois extremos: paginar por uma desvio breve sem impacto ou esperar até que o objectivo mensal seja irrecuperável. As janelas rápidas detectam incidentes intensos; as janelas longas capturam degradações suportadas.
Para conceber:
- Definai o indicador a partir da experiência do usuário.
- Acorda o objectivo e a janela com o negócio.
- Calcula o consumo de orçamento, não apenas o valor instantâneo.
- Atribui gravidade de acordo com a velocidade e o tempo restante.
- Ligue cada nível com uma acção concreta.
Um SLO não deve tornar-se um número decorativo. Se não mudar as prioridades, desligue ou responda, ainda não funciona como ferramenta operacional.
Exemplo: checkout lento
- Golden Signals detecta aumento de latência e erros.
- O RED coloca a mudança no serviço de pagamentos.
- Uma amostra espera na base de dados.
- USE confirmação da saturação do pool de ligações.
- O desenvolvimento recente explica o novo padrão.
Nenhum quadro isolado conta toda a história. A correlação transforma sinais em uma explicação.
Percentiles em vez de média
A média mistura experiências. Se nove pedidos demoram 100 ms e uma tarde 5 segundos, a média não representa nenhum usuário.
Utilização p50 para comportamento típico e p95/p99 para cola de latência. Escolhi o percentil de acordo com volume e compromisso de serviço; um p99 sobre muito poucas amostras pode ser instável.
Erros Frequentes
- Aplicar o RED a um disco ou a uma transacção sem adaptação.
- Alerta por utilização sem observação da saturação.
- Misturar erros técnicos e de negócios.
- Usar a média para a latência.
- Criar o mesmo limiar para todos os serviços.
- Não segmentar por versão, região ou dependência.
- Medir sem um SLO que defina o que importa.
Modelo de serviço
Para cada serviço, deve documentar:
- Proprietário e crítica.
- SLO e janela de medição.
- Rato, erros e duração.
- Dependências principais.
- Recurso limitador e sinais USE
- Mudanças recentes.
- Ação e canal de cada alerta.
Esta ficha vale mais de 20 dashboards sem responsabilidade.
Teste de Qualidade
Tome um incidente recente e recolhe o tabuleiro sem usar conhecimento prévio. As Golden Sinals mostram o impacto? RED coloca o serviço? Você está confirmando ou descartando saturação? Se a resposta precisa abrir consultas improvisadas, documenta o dado faltante. Se uma métrica nunca participa de uma decisão, tire-a da vista principal. O teste deve ser repetido após alterações importantes porque um alerta útil hoje pode ficar obsoleto quando a arquitectura muda.
Próximo passo
CTL desenha tabuleiros, SLOs e alertas sobre Grafana, Prometheus e plataformas APM. Agenda um 'workshop' para converter as unidades métricas atuais em sinais operacionais.
Perguntas frequentes
O RED substitui as Golden Signals?
Não. RED cobre tráfego, erros e latência; a saturação é observada com Golden Signals ou USE. Podem combinar-se.
Quantas métricas precisam de um serviço?
Não existe um número fixo. Começa pelos sinais que representam experiência e capacidade de acção; adicione detalhe apenas quando ajudar a diagnosticar.
Que alerta deve ser configurado primeiro?
Um aviso sobre o incumprimento ou o consumo acelerado do SLO da experiência mais crítica, com um playbook e owner definidos.