El problema de las 3 AM
Todo ingeniero que ha operado sistemas en producción conoce la sensación. Tu teléfono vibra a las 3 AM. Se dispara una alerta. Abres tu laptop, con los ojos entrecerrados, y te encuentras con un dashboard lleno de indicadores rojos. Algo está mal. Pero, ¿qué?
Este es el momento que separa los sistemas con buena observabilidad de los que no la tienen. En un escenario, pasas los siguientes 90 minutos revisando logs, adivinando causas e intentando correlacionar eventos entre múltiples sistemas. En el otro, miras tu dashboard, ves exactamente qué componente está fallando, profundizas en las trazas relevantes e identificas la causa raíz en minutos.
Después de años operando sistemas enterprise en banca, middleware y plataformas distribuidas, hemos desarrollado opiniones firmes sobre qué funciona realmente en observabilidad de producción. La mayoría de lo que la industria enseña es correcto en teoría pero incompleto en la práctica.
Los tres pilares y la realidad de un solo pilar
Todos hablan de los tres pilares de la observabilidad: logs, métricas y trazas. Lo que hemos observado es que la mayoría de los equipos solo hacen bien uno de ellos — generalmente logging — y tratan los otros dos como un detalle menor.
Logs son lo predeterminado. Toda aplicación produce logs. El problema es que la mayoría de los logs son flujos de texto no estructurado que son prácticamente inútiles a las 3 AM. Volveremos a esto.
Métricas son mediciones numéricas a lo largo del tiempo. Uso de CPU, latencia de requests, tasas de error, profundidad de colas. Las métricas te dicen qué está pasando a nivel alto. Son el sistema de alerta temprana que te dice que algo está mal antes de que los usuarios lo noten.
Trazas siguen un request individual a través de todos los servicios que toca. En sistemas distribuidos, una traza es la única forma de entender el viaje completo de un request desde su entrada hasta la respuesta. Sin trazas, depurar sistemas distribuidos es adivinanza.
La razón por la que la mayoría de equipos solo hacen bien el logging es que requiere casi ninguna inversión inicial. Llamas una función de log y el texto aparece en algún lado. Las métricas requieren instrumentación — tienes que decidir qué medir, cómo agregarlo y dónde visualizarlo. Las trazas requieren propagación — necesitas correlation IDs fluyendo a través de cada servicio, cada cola, cada llamada a base de datos.
Nuestra recomendación: invierte en los tres desde el día uno. El costo de agregar observabilidad después del hecho — cuando los sistemas ya están en producción y los incidentes ya están ocurriendo — es un orden de magnitud mayor que construirla desde el inicio.
Logging estructurado que realmente ayuda
El cambio de mayor impacto que puedes hacer en tu logging es pasar de texto no estructurado a datos estructurados. En lugar de loguear "Usuario 12345 falló al procesar pago de $100.00 - timeout", loguea un evento estructurado con campos: user_id, action, amount, error_type, duration_ms, service_name, trace_id.
Por qué esto importa a las 3 AM:
Con logs no estructurados, encontrar todos los pagos fallidos en la última hora requiere regex. Encontrar todos los fallos de un usuario específico requiere un regex diferente. Correlacionar fallos con un servicio downstream específico requiere otro más. Cuando estás cansado y el sistema está caído, no quieres estar escribiendo regex.
Con logs estructurados, estas son consultas simples. Muéstrame todos los eventos donde action=payment AND error_type=timeout AND timestamp > hace 1 hora. Agrupa por service_name. Muéstrame la distribución de duration_ms.
Los campos que incluimos en cada evento de log:
timestamp (ISO 8601), service_name, trace_id, span_id, level (info/warn/error), action (qué se intentaba hacer), outcome (éxito/fallo), duration_ms (cuánto tardó), y cualquier campo específico del dominio relevante para la acción.
El trace_id es crítico. Conecta tus eventos de log con tus trazas distribuidas. Cuando ves un error en los logs, puedes inmediatamente traer la traza completa y ver cada servicio que ese request tocó.
Fatiga de alertas y cómo solucionarla
La fatiga de alertas es el problema operacional número uno que vemos en entornos enterprise. Los equipos configuran alertas, establecen umbrales para cada métrica que se les ocurre, y luego quedan enterrados en notificaciones. Después de una semana de falsas alarmas, el ingeniero de guardia empieza a ignorar alertas. Entonces ocurre un incidente real y nadie se da cuenta hasta que un usuario lo reporta.
La causa raíz de la fatiga de alertas es alertar por síntomas en vez de por impacto.
Un pico de CPU al 80% es un síntoma. Un aumento en la tasa de error de 0.1% a 2% es un síntoma. Estos pueden o no indicar un problema real. Lo que importa es: ¿están los usuarios afectados?
Reestructuramos las alertas en tres niveles:
Nivel 1: Impacto en usuarios. Tasas de error, percentiles de latencia (p95, p99) y disponibilidad. Estas se disparan al ingeniero de guardia inmediatamente. Si estas están alertando, los usuarios están teniendo una mala experiencia ahora mismo.
Nivel 2: Salud del sistema. Utilización de recursos, profundidad de colas, saturación de pools de conexiones. Estas son advertencias. Indican que un problema puede desarrollarse si no se atiende. Van a un canal de Slack, no al pager.
Nivel 3: Anomalías. Desviaciones de patrones normales que pueden ser interesantes pero no son inmediatamente accionables. Estas alimentan un dashboard de revisión diaria.
La perspectiva clave: cada alerta de Nivel 1 debe tener un runbook. Cuando la alerta se dispara, el ingeniero de guardia debe saber exactamente qué verificar primero, cuáles son las causas probables y cuáles son los pasos de remediación. Si no puedes escribir un runbook para una alerta, la alerta no es lo suficientemente específica para ser útil.
Dashboards que importan
Hemos visto organizaciones con cientos de dashboards donde nadie mira ninguno. El problema no es la herramienta — es que la mayoría de dashboards se construyen para verse impresionantes en lugar de para responder preguntas.
Los tres dashboards que todo sistema necesita:
Dashboard 1: El dashboard de negocio. Responde "¿el sistema funciona desde la perspectiva del usuario?" Métricas clave: volumen de requests, tasa de error, latencia p50/p95/p99, usuarios activos y KPIs específicos del negocio (transacciones procesadas, pagos completados, mensajes entregados). Este es el dashboard que miras primero durante un incidente.
Dashboard 2: El dashboard de salud de servicios. Un panel por servicio mostrando: tasa de requests, tasa de error, latencia, utilización de recursos. Responde "¿cuál servicio es el problema?" Cuando el Dashboard 1 muestra que algo está mal, el Dashboard 2 te dice dónde.
Dashboard 3: El dashboard de dependencias. Muestra la salud de dependencias externas: bases de datos, colas de mensajes, APIs de terceros, servicios downstream. Responde "¿el problema está en nuestro código o en algo de lo que dependemos?"
Los mejores dashboards son los que responden una pregunta en menos de 5 segundos. Si tienes que pensar qué te está mostrando un panel, el dashboard necesita trabajo.
Construir la cultura operacional
La observabilidad no es solo herramientas. Es una cultura. Las herramientas son inútiles si el equipo no las usa, no las mantiene y no las mejora basándose en incidentes reales.
Las revisiones post-incidente son el motor de mejora de la observabilidad. Después de cada incidente significativo, hacemos tres preguntas sobre observabilidad: ¿Cómo detectamos el problema? ¿Qué información teníamos durante la investigación? ¿Qué información nos faltaba?
Cada pieza faltante se convierte en un action item. Si no pudimos identificar el componente fallando rápidamente, agregamos una métrica o mejoramos un dashboard. Si no pudimos trazar un request a través del sistema, agregamos instrumentación de trazas. Si la alerta se disparó demasiado tarde, ajustamos el umbral o agregamos un indicador adelantado.
Con el tiempo, esto crea un ciclo de retroalimentación donde cada incidente hace al sistema más observable. El objetivo no es prevenir todos los incidentes — eso es imposible. El objetivo es detectarlos rápido, diagnosticarlos rápido y resolverlos rápido.
Después de implementar este enfoque en múltiples sistemas enterprise, el patrón es consistente. El tiempo medio de detección baja de horas a minutos. El tiempo medio de resolución baja de horas a decenas de minutos. Y los ingenieros de guardia realmente confían en las alertas — porque cada alerta significa algo real.
La observabilidad no es un proyecto con fecha de finalización. Es una práctica que mejora continuamente. Los sistemas que operamos hoy son órdenes de magnitud más observables que hace dos años, y en dos años serán mejores aún. Ese es el punto.