El 40 % del tráfico de la API era comprobaciones internas tras migrar a service mesh
Tras mover su API de cuentas a un service mesh, el equipo descubrió que cuatro de cada diez solicitudes eran health checks internos que inflaban sus métricas.
En mayo el equipo de backend trasladó la API de cuentas a un service mesh y, de la noche a la mañana, el recuento de peticiones cayó un 41 %. El disparador de alerta se activó a las 02:00 h, pero los usuarios no notaron nada. La causa era que el mesh había redirigido los health checks a un puerto que el middleware de métricas no observaba.
Para cuantificar el impacto, el autor contabilizó todas las comprobaciones que pasaban por el puerto principal: sondas de readiness y liveness de kubelet cada cinco segundos en 24 pods, verificaciones del balanceador de carga desde tres zonas cada diez segundos, un servicio de uptime desde seis ubicaciones y un verificador de dependencias que llamaba al endpoint de estado de cada servicio cada quince segundos. Todas esas peticiones recibían un 200 en unos dos milisegundos y se contabilizaban como tráfico normal.
En el pico diurno esos checks representaban alrededor del 15 % del total de peticiones; durante la noche, el 70 %. En un día completo, el 40 % del tráfico era sintético, sin posibilidad de error. Como resultado, los indicadores de error y latencia estaban diluidos: el denominador incluía máquinas que solo preguntaban si el servicio estaba vivo. Durante una interrupción parcial en marzo, los usuarios vieron un 7,8 % de errores, mientras el dashboard mostraba 4,6 % y permanecía bajo el umbral de 5 %.
La solución consistió en mover las sondas a un puerto administrativo no instrumentado y etiquetar cada petición con una clase de llamador (usuario, interno o sintético). Los objetivos ahora se calculan solo sobre tráfico de usuarios; los checks sintéticos siguen generando alertas como señal independiente. Además, se añadió un panel que muestra la proporción de tráfico no‑usuario por servicio, evitando futuras diluciones.
Al recomputar el último trimestre excluyendo los probes, descubrieron que habían consumido casi el doble del presupuesto de errores reportado y fallaron el objetivo en dos de tres meses. La lección es clara: decidir quién cuenta en el numerador y el denominador es crucial, porque cualquier entidad que pueda alcanzar el endpoint influye en los indicadores.
Esta revisión muestra la importancia de separar el tráfico de control del tráfico de producción en entornos con service mesh y de etiquetar correctamente las métricas para obtener una visión real de la disponibilidad del servicio.
