Observabilidade SRE: o 80/20 que importa de verdade

A observabilidade SRE tem um padrão comum: times de engenharia adotam a ferramenta, instrumentam tudo, ficam sufocados de sinal e param de olhar pra qualquer coisa. A ferramenta fica abandonada enquanto postmortems continuam dependendo de caça aos logs.

Após ajudar ~80 times a migrarem para stacks instrumentadas, convergimos numa regra 80/20 que se confirma de forma consistente.

Os 20% de observabilidade SRE que sempre valem

Cinco categorias, em ordem de prioridade:

1. Taxa de request, taxa de erro, latência (métricas RED) em toda fronteira externa
2. Profundidade de fila em todo sistema assíncrono
3. Utilização do pool de conexões de banco
4. Memória e contadores de goroutines/threads em processos longos
5. Métricas de KPI de negócio com a mesma disciplina de SLO que as de infra

Acabou. Cinco categorias. A maioria dos times sub-instrumenta aqui enquanto super-instrumenta em outros lugares — e essa inversão é a causa raiz de quase toda dor de plantão que vemos no campo de engenharia.

Os 80% que você deveria deixar pra depois

A armadilha é instrumentar chamadas de função individuais “por garantia”. Não vai precisar, e o ruído afoga o sinal.

O padrão certo: lance sem esse nível de detalhe. Quando algo quebra e você está debugando sem a visibilidade que gostaria, instrumente aí. A dor te ensina o que valia a pena medir.

Uma coisa que ninguém te avisa

A biblioteca de instrumentação em si vira load-bearing. Já vimos múltiplas indisponibilidades causadas pelo caminho de emissão de métricas falhando sob carga. Trate sua biblioteca de observabilidade com o mesmo rigor do client de banco.

Boa observabilidade SRE é mais sobre o que você decide NÃO medir do que sobre o que decide medir. Times com 200 dashboards quase sempre olham apenas para 10. Comece pelos 10.