Principais KPIs de Observabilidade: Exemplos e Guia Completo
Times de tecnologia investem alto em observabilidade, mas, na prática, muita gente olha para uma enxurrada de gráficos sem saber qual número importa. Sobram dashboards e faltam decisões. O problema raramente é a ferramenta. Em geral, falta uma lista clara de KPIs ancorados em frameworks consagrados e amarrados ao negócio.
Este guia consolida os principais KPIs de observabilidade que sustentam uma operação confiável em 2026. Você vai encontrar os 4 Golden Signals do Google SRE, os métodos RED e USE, além dos indicadores SLI e SLO com Error Budget. Também cobrimos os KPIs operacionais clássicos. Em seguida, mostramos como escolher e priorizar cada indicador no contexto da sua arquitetura.
A ideia é simples: sair do “olhar tudo” para o “medir o que decide”. Vamos do conceito à aplicação, sem inflar a teoria.
O que são KPIs de observabilidade?
KPIs de observabilidade são indicadores-chave de desempenho extraídos de métricas, logs e traces que descrevem como um sistema distribuído realmente se comporta em produção. Diferente das métricas brutas, um KPI carrega contexto: ele responde a uma pergunta de negócio ou de confiabilidade.
O monitoramento tradicional pergunta “o servidor está no ar?”. A observabilidade pergunta “por que o checkout demorou 4 segundos para o usuário no Rio Grande do Sul?”. Por isso, KPIs de observabilidade vão muito além de CPU e memória.
Vale destacar a relação com os três pilares da observabilidade. Métricas, logs e traces são as fontes de dados. Os KPIs são as decisões que extraímos dessas fontes. Sem KPIs definidos, a operação acumula telemetria mas continua reativa.
Os 4 Golden Signals: o ponto de partida
Os 4 Golden Signals foram codificados pelo time de SRE do Google. Eles continuam sendo o ponto de partida mais sólido para qualquer prática de observabilidade. Funcionam para serviços voltados ao usuário e ajudam a cobrir o essencial sem instrumentar tudo de uma vez.
São quatro: latência, tráfego, erros e saturação. Juntos, eles dão uma visão completa de saúde de serviço. Vale notar que cada um deve ser observado com percentis, não com médias. Uma latência média de 200 ms pode esconder uma cauda P99 de 4 segundos.
| Sinal | Como medir | Por que importa |
|---|---|---|
| Latência | Tempo de resposta por requisição em P50, P95 e P99 | Reflete a experiência percebida pelo usuário final |
| Tráfego | Requisições por segundo, transações por minuto, mensagens em fila | Mostra a demanda real do serviço e expõe picos sazonais |
| Erros | Taxa de respostas com falha (5xx, exceções, contratos quebrados) | Sinaliza degradação funcional antes do impacto no usuário |
| Saturação | Quão “cheio” o serviço está: CPU, memória, fila de threads, conexões | Antecipa colapso quando o sistema chega ao limite de capacidade |
A documentação oficial do livro de SRE do Google aprofunda cada sinal com exemplos. Em resumo, se você ainda não tem nada instrumentado, comece por aqui.
Método RED para serviços e USE para recursos
Os 4 Golden Signals cobrem bastante coisa, mas, dependendo do que você está observando, dois métodos complementares ajudam a refinar o foco. RED foi criado por Tom Wilkes para serviços voltados ao usuário. USE foi proposto por Brendan Gregg para recursos de infraestrutura.
RED significa Rate (taxa de requisições), Errors (taxa de erros) e Duration (duração). USE significa Utilization (utilização), Saturation (saturação) e Errors (erros). A escolha depende da camada: serviços usam RED; recursos usam USE.
| Dimensão | Método RED | Método USE |
|---|---|---|
| Foco | Serviços e APIs voltados ao usuário | Recursos físicos e lógicos da infraestrutura |
| Forte para | Microsserviços, APIs REST, gRPC | CPU, memória, disco, rede, filas |
| Limitação | Não enxerga gargalo de recurso direto | Não conta a história do usuário final |
| Métricas-chave | requests/s, error_rate, P99_latency | cpu_util, queue_depth, io_errors |
Na prática, RED e USE não competem. Eles atuam em camadas diferentes. Quem quer aprofundar, pode revisar nosso material sobre conceitos de RED e USE aplicados ao dia a dia operacional.
KPIs de confiabilidade: SLI, SLO e Error Budget
Os Golden Signals descrevem comportamento. SLIs e SLOs traduzem esse comportamento em compromisso de confiabilidade. Por isso, formam o coração de qualquer prática moderna de site reliability engineering. Sem eles, o time perde a capacidade de decidir quando vale arriscar uma feature nova.
SLI (Service Level Indicator) é a métrica observada. Por exemplo, a fração de requisições com latência abaixo de 300 ms. SLO (Service Level Objective) é o alvo dessa métrica. Por exemplo, 99,9% das requisições do checkout abaixo de 300 ms num período de 30 dias. Error Budget é o complemento desse alvo: 0,1% de orçamento de erro por mês.
Como aplicar isso? Para um e-commerce, três SLOs típicos cobrem o essencial:
Disponibilidade do checkout: 99,95% das requisições POST /checkout com resposta 2xx em janela de 30 dias.
Latência do login: 99% das requisições POST /login abaixo de 500 ms (P99) em janela de 7 dias.
Frescor de saldo: 99,9% das leituras de GET /saldo com dado mais novo que 60 segundos.
Quando o Error Budget está saudável, o time pode subir mudanças com mais agressividade. Quando esgota, prioriza confiabilidade. Esse mecanismo conecta a engenharia ao negócio sem fricção. Para mapear bem esses SLOs, vale conhecer o conceito de critical user journey, que ajuda a focar os indicadores no que realmente impacta a receita.
KPIs operacionais: MTTD, MTTR, MTBF e disponibilidade
Um conjunto de KPIs costuma ficar de fora do vocabulário SRE mas continua relevante para a operação: os indicadores de resposta a incidentes. Eles medem quão bem o time detecta, responde e aprende com falhas. Equipes maduras usam esses números como termômetro de processo.
MTTD (Mean Time To Detect) é o tempo médio entre a falha começar e o time tomar conhecimento. MTTR (Mean Time To Recover) é o tempo médio entre detecção e restauração do serviço. MTBF (Mean Time Between Failures) é o intervalo médio entre falhas consecutivas. Disponibilidade é o percentual de tempo em que o serviço esteve operacional dentro de uma janela.
A leitura conjunta importa mais que cada número isolado. MTTD alto sinaliza alertas mal calibrados ou falta de instrumentação. MTTR alto sugere runbooks fracos ou falta de automação. MTBF baixo aponta para problemas estruturais de arquitetura. Disponibilidade abaixo do contratado dispara cláusulas de SLA. Outro ponto: tratar esses KPIs sem segmentação por severidade distorce a percepção. Um P1 de 30 minutos pesa diferente de um P4 de 30 minutos.
KPIs por pilar: o que extrair de métricas, logs e traces
Cada pilar da observabilidade gera famílias de KPIs específicos. Combinar os três é o que diferencia uma operação madura de um monitoramento legacy disfarçado. A documentação da comunidade OpenTelemetry é uma boa referência para padronizar a coleta entre os três.
Métricas entregam contadores e séries temporais agregadas. Os KPIs típicos incluem requisições por segundo, taxa de erro, latência por percentil, profundidade de fila e taxa de saturação de recursos. Métricas são baratas de coletar e ideais para alertas em tempo real.
Logs entregam eventos discretos com contexto rico. Os KPIs típicos incluem volume de logs de erro por serviço, taxa de logs WARN por minuto e frequência de exceções não tratadas. Outro indicador-chave é a correlação de logs por trace ID. Logs respondem à pergunta “o que aconteceu exatamente?”.
Traces entregam o caminho de uma requisição entre serviços. Os KPIs típicos incluem duração total da trace, número de spans por requisição, percentual de spans com erro e gargalo dominante (qual span concentra mais tempo). Traces respondem a “onde o tempo foi gasto?”.
Como escolher e priorizar os KPIs no seu contexto
Listar dezenas de KPIs é fácil. Difícil é escolher os 8 a 12 que importam para a sua operação. A regra de ouro: comece pelo impacto no negócio e desça até a infraestrutura. Métricas de servidor sem amarração com receita são vaidade. Por outro lado, KPIs de negócio sem métricas técnicas que sustentem a investigação viram ruído.
Três anti-padrões merecem atenção. Vaidade: colecionar gráficos bonitos que ninguém olha. Excesso de alertas: alertar em tudo gera fadiga e o time aprende a ignorar. Sem contexto de negócio: indicadores técnicos sem ligação com receita ou experiência fazem o board questionar o investimento.
Use a hierarquia em três camadas. No topo ficam os KPIs de negócio (receita, conversão, NPS). No meio entram os SLOs por jornada crítica. Na base ficam os KPIs técnicos como Golden Signals, RED e USE. Conecte cada camada para que um alerta operacional chegue com contexto de impacto. Para aprofundar, vale revisar nossa visão de indicadores de performance em TI aplicados a clientes do mercado brasileiro.
Por fim, lembre-se de que KPI bom é KPI revisado. Calendarize uma revisão trimestral para aposentar indicadores que perderam relevância e adicionar os que a evolução do produto pediu.
Logs, métricas e traces unificados para diagnóstico em profundidade.
Instrumentamos aplicações corporativas com OpenTelemetry para correlacionar eventos e acelerar a análise de causa raiz em produção.
Conclusão
Os principais KPIs de observabilidade não são uma lista única que cabe em qualquer empresa. Eles combinam frameworks consolidados como Golden Signals, RED, USE, SLI/SLO e Error Budget. Cada conjunto precisa ser adaptado ao seu contexto, à sua arquitetura e ao seu apetite a risco. Em última análise, observabilidade boa é observabilidade que entrega decisão, não dashboard.
Comece pequeno, com os 4 Golden Signals nos serviços críticos. Em seguida, formalize SLIs e SLOs nas jornadas que mais impactam a receita. Depois, cubra os recursos de infraestrutura com USE e amarre tudo a um conjunto enxuto de KPIs operacionais (MTTD, MTTR, MTBF, disponibilidade). Cada camada nova precisa justificar o custo de coleta com decisões reais que ela permitiu.
Se a sua operação ainda não tem essa hierarquia, é hora de estruturar. A OpServices implementa projetos completos de observabilidade com instrumentação, dashboards e cultura de SRE para empresas brasileiras. Fale com um especialista e descubra como acelerar essa jornada na sua TI.
Perguntas Frequentes
O que são KPIs de observabilidade?
MTTD, MTTR e MTBF, sempre amarrados a uma decisão de negócio.Quais são os 4 Golden Signals do SRE?
P50, P95 e P99. Tráfego mede a demanda do serviço em requisições por segundo. Erros medem a taxa de respostas com falha (5xx, exceções, contratos quebrados). Saturação mede quão cheio o serviço está em CPU, memória, fila de threads ou conexões. Combinados, esses sinais cobrem o essencial sem sobrecarregar a instrumentação.Qual a diferença entre observabilidade e monitoramento?
O que é MTTR e MTBF na observabilidade?
MTTR avalia a maturidade de resposta a incidentes (runbooks, automação, comunicação), enquanto MTBF avalia a estabilidade estrutural do sistema (qualidade de código, arquitetura, capacity). MTTR alto sugere processos fracos. MTBF baixo aponta para problemas arquiteturais. Times maduros segmentam esses KPIs por severidade do incidente para evitar distorção na leitura.Como escolher os KPIs de observabilidade certos?
RED e USE para serviços e recursos. Evite três anti-padrões comuns: vaidade (gráficos bonitos que ninguém olha), excesso de alertas (gera fadiga e o time aprende a ignorar) e indicadores sem ligação com negócio. Mantenha entre 8 e 12 KPIs realmente usados e revise trimestralmente para aposentar os que perderam relevância.
