O que um histograma de latência está tentando te dizer

A latência média é o número menos útil de um dashboard. Ela responde uma pergunta que ninguém faz: quanto cada request levaria se as lentas dividissem a dor com as rápidas. Ninguém vive a média. O usuário vive uma request de cada vez, e as lentas são as que ele lembra.

Um histograma responde uma pergunta melhor: como as requests estão distribuídas de verdade? Aprender a ler um é uma das habilidades de maior retorno em operação, e leva uma tarde.

Leia a forma antes dos números

Quando abro um histograma, ignoro a tabela de percentis por um momento e olho a forma. Um serviço saudável costuma mostrar uma corcova só, com uma cauda longa para a direita. Isso é normal: a maioria das requests é rápida, algumas são lentas por motivos chatos.

Duas corcovas significam dois caminhos de código. Quase sempre é cache hit contra cache miss: um grupo em 5 ms, outro em 80 ms. Às vezes é instância quente contra cold start numa plataforma serverless. Às vezes é uma query que usa índice para a maioria das entradas e faz sequential scan para algumas. Um histograma bimodal é um convite para dar nome aos dois caminhos e decidir se o lento é aceitável.

Uma corcova com um calombo pequeno bem à direita, num intervalo suspeitamente regular, costuma ser o garbage collector ou um job periódico segurando um lock. A forma diz onde olhar antes de você ter um único número.

O que p50, p95 e p99 contam, cada um

p50, a mediana, é a experiência típica. Se o p50 se move, seu caminho normal mudou: um deploy, um payload maior, uma dependência mais lenta para todo mundo.

p95 é a experiência dos seus usuários engajados. Quem faz vinte requests numa sessão vai cair numa request de p95 uma vez. Se o p95 dobra com o p50 parado, algo está errado para uma minoria: um shard, uma região, um cliente com conta grande.

p99 é onde as partes mais fracas do sistema aparecem: contenção de lock, retries, timeouts numa dependência, vizinho barulhento. É o número que quem está de plantão deveria acompanhar, porque os incidentes começam ali e descem.

A distância entre eles é um sinal por si só. p50 de 20 ms e p99 de 40 ms é um serviço apertado e previsível. p50 de 20 ms e p99 de 2 s é um serviço com um modo de falha escondido.

Amplificação de cauda: por que o p99 importa mais do que parece

Este é o número que muda como as pessoas projetam. Se uma página faz fan-out para 10 chamadas de backend em paralelo, e cada uma tem 1% de chance de cair no próprio p99, a chance de pelo menos uma ser lenta é 1 menos 0,99 elevado a dez, cerca de 10%. A latência da página é a da chamada mais lenta. Então uma página em dez sente um p99 de backend, mesmo com cada backend se comportando perfeitamente pelos próprios números.

Com 100 chamadas de fan-out, o que é normal num serviço de busca ou feed, isso vira 63%. A maioria das páginas pega um p99 em algum lugar. É por isso que sistemas grandes são obcecados por cauda: o p50 deles é feito do p99 de todo mundo. As correções são estruturais: hedged requests, timeouts mais curtos com fallback, menos chamadas por página e cache nas chamadas de pior cauda.

Como os buckets funcionam, e sobre o que alertar

Histogramas no estilo Prometheus não guardam cada observação. Guardam contagens em buckets cumulativos com limites fixos: le=0.005, le=0.01, le=0.025 e assim por diante. Os percentis são interpolados entre as bordas dos buckets. Isso tem duas consequências que vale conhecer.

Primeira: seu p99 só é tão preciso quanto os buckets perto dele. Se os limites pulam de 1 s para 2,5 s, todo p99 nessa faixa vai aparecer como um valor interpolado que pode não significar nada. Defina os limites em torno das latências que importam, principalmente perto do seu SLO. Segunda: percentis calculados de buckets podem ser agregados entre instâncias, diferente de percentis pré-calculados, que não podem ser tirados na média. É por isso que você quer histogramas, e não summaries, quando tem muitas réplicas.

Para alertas, evite alertar direto no p99; é ruidoso demais com pouco tráfego. Alerte na fração de requests mais lentas que o seu limiar numa janela, que é uma razão simples entre dois contadores de bucket, e na taxa de queima do error budget. Uma request lenta às 3 da manhã não é incidente. Cinco por cento das requests acima de 500 ms por dez minutos é.

O histograma sempre esteve tentando te dizer isso. A média só estava falando por cima.