Percentiles de latencia: por qué no se deben promediar

Dos servidores muestran su p95 de latencia. Uno marca 100 milisegundos; el otro, 1.000. El dashboard calcula la media y presenta 550 milisegundos como p95 del servicio. La cifra tiene decimales, color y una línea de tendencia. Lo que le falta es representar el percentil que promete.

El error resulta tentador porque sumar resúmenes parece una forma razonable de resumir un sistema. Pero un percentil es una posición dentro de una distribución. Al conservar solo esa posición perdemos información necesaria para reconstruir la distribución conjunta.

Por qué la media de dos p95 no es el p95 global

Los percentiles de varios grupos no se pueden promediar para obtener el percentil del conjunto. Ni siquiera ponderarlos por el número de solicitudes resuelve el problema en general. Para calcular el percentil global necesitamos las observaciones originales o una representación combinable de su distribución, con la precisión y el alcance adecuados.

Veamos el caso del principio con todos los datos. Es un ejemplo sintético, construido para poder comprobar la cuenta. Durante una misma ventana, el servidor A atiende 990 solicitudes, todas en 100 milisegundos. El servidor B atiende diez solicitudes, todas en 1.000 milisegundos. Suponemos que cada solicitud pertenece a un solo servidor y se registra una sola vez.

El p95 de A es 100 milisegundos y el de B es 1.000. Su media simple da 550; su media ponderada por volumen da 109. Ninguna es el p95 global.

Al ordenar las 1.000 observaciones de menor a mayor, las primeras 990 valen 100 milisegundos. Para este cálculo usamos el criterio de rango más próximo por arriba: la posición del p95 es el techo de 0,95 multiplicado por 1.000, es decir, la observación 950. Por tanto, el p95 conjunto es 100 milisegundos. Otros métodos de interpolación habituales también caen aquí dentro del bloque de valores iguales, aunque pueden diferir con otros datos.

Los 109 milisegundos sí coinciden, en este ejemplo particular, con la latencia media global. Ocurre porque cada servidor tiene una latencia constante y su p95 coincide con su propia media. Esa coincidencia no convierte una media en un percentil ni hace válida la operación para otras distribuciones.

Un p95 correcto también puede ocultar a un grupo

El resultado global anterior es matemáticamente correcto y, aun así, puede ser insuficiente para decidir. Si las diez solicitudes lentas pertenecen al mismo cliente, ese cliente obtiene una experiencia mala en todas sus operaciones. Para el conjunto, representa solo un 1 % del tráfico.

Conviene mantener ambas observaciones. El percentil global describe las solicitudes agregadas. El desglose por cliente, región o tipo de operación puede revelar una concentración relevante del daño. Son preguntas diferentes, y ninguna obliga a sustituir la otra por un promedio de percentiles.

También cambia el significado si medimos intentos técnicos en lugar de operaciones del usuario. Un fallo con varios reintentos genera más observaciones que una operación que termina a la primera. La latencia de cada intento no representa necesariamente el tiempo total que esperó la persona. Es una distinción próxima a la que aparece al analizar timeouts, reintentos y efectos de una operación: la unidad técnica que podemos contar no siempre es la unidad que nos interesa evaluar.

La distribución se combina antes de extraer el percentil

La documentación de histogramas y resúmenes de Prometheus diferencia dos representaciones. Los resúmenes pueden exponer cuantiles ya calculados por cada instancia; esos cuantiles no permiten obtener por agregación el del servicio. Los histogramas conservan recuentos por intervalos, que sí permiten combinar distribuciones compatibles y estimar después el percentil.

En los histogramas clásicos, los límites de los intervalos deben ser compatibles para esa combinación. Además, estimar un percentil a partir de intervalos introduce una incertidumbre ligada a su resolución. Una cifra con muchos decimales no recupera la información que no se conservó.

Esto cambia una conversación habitual sobre almacenamiento de métricas. Si solo guardamos el p95 de cada minuto, no podemos obtener el p95 del día haciendo la media de esos valores. Podemos describir cómo variaron los p95 de los minutos, que es otro análisis. Para responder sobre todas las solicitudes del día necesitamos conservar información suficiente sobre sus distribuciones y volúmenes.

La misma cautela se aplica a la frontera de observación. El capítulo de objetivos de servicio del libro SRE de Google explica el valor de mirar distribuciones y de precisar ventanas, solicitudes incluidas y punto de medida. Un tiempo medido en el servidor y otro medido desde el cliente pueden ser correctos sin coincidir. Llamarlos simplemente «latencia» deja fuera la parte que permite interpretarlos.

El contrato de lectura de latencia

Para que una gráfica sobreviva a una conversación entre equipos, podemos acompañarla de un contrato de lectura de latencia. Este nombre identifica una propuesta propia de documentación, no un estándar estadístico ni una implementación de observabilidad.

Experiencia representada

Qué empieza y qué termina la medición: una solicitud, un intento o una operación completa del usuario. También dónde se toma el tiempo.

Población y ventana

Qué solicitudes entran, cuáles faltan y durante qué periodo. El volumen acompaña al percentil; errores y timeouts tienen un tratamiento explícito.

Forma de combinación

Qué datos permiten reunir instancias y periodos: observaciones o distribuciones compatibles. Si solo quedan percentiles, la limitación se declara.

Resolución y decisión

Cómo se estima el valor y para qué decisión sirve. Incluye los grupos cuyo comportamiento no debe quedar disuelto en el total.

En nuestro ejemplo, el contrato diría «1.000 solicitudes completadas durante la misma ventana, dos servidores, una observación por solicitud, tiempos exactos». También advertiría que no estamos midiendo errores ni abandonos porque el caso no los contiene. Llevarlo a un servicio real exige definir esos estados; excluir silenciosamente las peticiones que no terminaron puede mejorar la gráfica a costa de perder precisamente las peores experiencias.

Cuando el compromiso es un umbral, contemos su cumplimiento

A veces la pregunta del responsable es mucho más concreta: qué proporción de operaciones terminó dentro del tiempo aceptable. El SRE Workbook de Google desarrolla indicadores expresados como eventos buenos frente a eventos válidos. Ese enfoque permite discutir el compromiso con un denominador explícito.

Si en el ejemplo fijamos un límite ilustrativo de 300 milisegundos, cumplen 990 de las 1.000 solicitudes: un 99 %. No estamos recomendando ese umbral para ningún servicio. Solo mostrando que la proporción de cumplimiento responde directamente a esa pregunta, mientras el p95 ayuda a explorar otra parte de la distribución.

Ni la media ni el percentil son cifras sospechosas por naturaleza. El problema aparece al perder su significado entre la captura y el dashboard. Como ocurre con la definición de una métrica compartida, acordar qué representa el número evita discutir después sobre conclusiones incompatibles. Antes de ampliar capacidad porque el p95 empeoró, merece la pena comprobar que seguimos calculando el p95 de la experiencia que queríamos mejorar.