Cuatro métricas que cualquier app en producción debería vigilar a todas horas

En producción no existe el ?funciona en mi máquina?. Existe el ?funciona ahora, para usuarios reales, con tráfico real y con fallos reales?. Y cuando una aplicación ya está en la calle, hay una rutina que se repite en todos los equipos de ingeniería, SRE y operaciones: mirar siempre las mismas cuatro señales. No porque sean las únicas, sino porque son las que primero te dicen si el producto está vivo, si está sufriendo o si se está rompiendo.

Son métricas básicas, casi aburridas? hasta que un lunes por la mañana se convierten en la diferencia entre detectar un incidente a tiempo o enterarte por un tuit.

1) Uptime: lo mínimo indispensable, ?¿está arriba o está caído??

Uptime es la pregunta más simple y, por eso mismo, la más brutal: ¿la app responde o no responde? Da igual lo bonita que sea la arquitectura si el usuario abre la web y solo ve un error.

Lo habitual es medirlo con pings, health checks o endpoints de ?liveness/readiness? cada cierto tiempo. Un patrón típico: comprobar cada 30 s o 60 s si el servicio devuelve un 200 OK (o el estado esperado) y si lo hace en un tiempo razonable. Cuando esos checks fallan, hay un problema inmediato: caída completa, DNS roto, balanceador mal, un despliegue fallido o una dependencia crítica fuera de servicio.

Un detalle práctico: no es lo mismo un ?health check? superficial (?el proceso está vivo?) que uno útil (?la app está viva y puede hablar con lo mínimo: base de datos, cola, caché, etc.?). El primero evita falsos positivos, el segundo evita falsas sensaciones de seguridad.

Qué suele delatar el uptime

• Caídas totales (5xx generalizados o timeouts).

• Errores de red, rutas, certificados, DNS.

• Incidentes tras despliegues (rollback en caliente salva vidas).

2) Latencia: no importa el promedio, importan los casos malos

La latencia mide cuánto tarda una request en responder. En negocio se traduce de forma sencilla: lo rápido que ?se siente? tu producto. Y aquí está el error clásico: mirar solo el promedio.

El promedio es engañoso. Puedes tener 90 peticiones rápidas y 10 lentísimas, y el promedio te dirá que ?no está tan mal?. Pero esos 10 usuarios que esperan segundos ?o que abandonan? sí notan que está mal.

Por eso se miran percentiles:

• p95: el tiempo por debajo del cual cae el 95% de las requests.

• p99: lo mismo, pero con el 99%. Es decir, ?lo peor de lo peor?, donde suelen vivir los cuellos de botella.

Ejemplo típico:

• El promedio está en 120 ms

• El p95 está en 500 ms

• El p99 se dispara a 4 s

Eso indica colas, locks, GC, saturación de CPU, I/O lento, consultas que a veces se vuelven carísimas, o picos de tráfico que desbordan recursos.

Qué suele delatar la latencia

• Saturación (CPU, memoria, conexiones, hilos).

• Dependencias lentas (DB, APIs externas).

• ?Colas invisibles?: cuando se acumulan requests antes de ser atendidas.

3) Tasa de errores: aquí se ven los problemas que importan al producto

La tasa de errores es el termómetro de ?lo que realmente está fallando?: qué porcentaje de requests termina en error. Puede incluir:

• 4xx (errores de cliente, pero ojo: a veces reflejan un bug o un cambio de contrato).

• 5xx (fallo del servidor).

• timeouts (a efectos del usuario, también es fallo).

En esta métrica aparecen los problemas que el negocio nota: pagos que fallan, logins que no entran, datos que no se guardan, carritos que se vacían. Muchas incidencias no empiezan con una caída total: empiezan con un goteo de errores que sube lentamente mientras el sistema ?aguanta como puede?.

Además, conviene separar el error ?esperable? del error ?grave?. No es lo mismo un 404 legítimo que un 500 en checkout. En observabilidad de verdad, la tasa de errores se cruza con rutas críticas (pago, autenticación, búsqueda) y con impacto en usuarios.

Qué suele delatar la tasa de errores

• Bugs de despliegue, migraciones y cambios de esquema.

• Problemas de dependencias (DB, colas, terceros).

• Límite de recursos: cuando el sistema no puede y empieza a fallar.

4) Throughput: cuánta carga maneja el sistema y cuánto le falta para el límite

Throughput es cuántas requests procesa el sistema. Suele medirse en RPM (requests por minuto) o RPS (por segundo). Es la métrica que te dice si el tráfico está creciendo, si hubo un pico inesperado o si el sistema se está acercando a su techo.

Aquí hay una relación casi inevitable:

• Cuando el RPM se acerca a lo que el sistema puede manejar, lo primero que sube es la latencia.

• Si sigue creciendo, aparecen errores (timeouts, 5xx, rechazos).

El throughput es clave para interpretar el resto. Si sube la latencia pero el tráfico es estable, quizá hay regresión o dependencia lenta. Si sube la latencia justo cuando se dispara el RPM, probablemente es saturación. Y si el throughput cae mientras los usuarios se quejan, puede ser que el sistema esté rechazando solicitudes o que algo esté ?rompiéndose? y ya ni siquiera logra atender.

Qué suele delatar el throughput

• Picos de demanda (campañas, bots, cambios de SEO, integraciones).

• Ataques o abuso (scraping agresivo, DDoS a nivel aplicación).

• Necesidad de escalado, caché o colas para desacoplar carga.

Por qué estas cuatro métricas son la base de la observabilidad

Observabilidad no es ?tener dashboards bonitos?. Es poder responder rápido y con datos a preguntas incómodas:

• ¿La app está disponible?

• ¿Va lenta para alguien, o solo para algunos?

• ¿Qué está fallando exactamente y dónde?

• ¿El sistema está soportando la carga o está al borde?

Sin datos, se decide a ciegas. Con estas cuatro señales, al menos se sabe si hay humo? y en qué dirección mirar antes de que haya fuego.

Preguntas frecuentes

¿Qué diferencia hay entre ?monitorización? y ?observabilidad? en una app en producción?
La monitorización suele avisar de ?qué está mal? (alertas y métricas). La observabilidad permite entender ?por qué está mal?, correlacionando métricas, logs y trazas para diagnosticar la causa.

¿Por qué es más importante mirar p95/p99 que el promedio de latencia?
Porque el promedio oculta los casos lentos. Los percentiles muestran el rendimiento en el ?peor tramo? y revelan colas, saturación y dependencias problemáticas que afectan a usuarios reales.

¿Qué tasa de errores es ?aceptable? en producción?
Depende del servicio y de los SLO. Un 0,1% puede ser grave en pagos, pero tolerable en endpoints secundarios. Lo importante es medir por rutas críticas y por impacto en usuario.

¿Cómo se relacionan throughput, latencia y errores cuando el sistema se satura?
Normalmente primero sube la latencia, después aparecen timeouts y 5xx. Si la saturación empeora, el throughput puede incluso caer porque el sistema ya no logra procesar solicitudes.