Observabilidad: logs, métricas y trazas para entender un sistema por dentro
Durante años, vigilar un sistema consistía en mirar si el servidor seguía vivo, cuánta CPU consumía y si quedaba espacio en disco. Eso ya no basta. Una aplicación moderna puede estar repartida entre contenedores, APIs, colas, bases de datos, servicios cloud y proveedores externos. Cuando algo falla, la pregunta importante no es solo “¿está caído?”, sino “¿qué está pasando exactamente y dónde?”. Ahí entra la observabilidad: la capacidad de entender el comportamiento interno de un sistema a partir de las señales que emite: logs, métricas y trazas.
Monitorizar no es lo mismo que observar
La monitorización clásica responde bien a preguntas conocidas: si la CPU supera cierto umbral, si una web devuelve error 500, si una base de datos consume demasiada memoria o si un servidor deja de responder. Es útil, necesaria y sigue siendo la primera línea de defensa.
La observabilidad va un paso más allá. Sirve para investigar problemas que no estaban previstos de antemano. Por ejemplo: una petición tarda cinco segundos solo para determinados usuarios, un proceso funciona bien en desarrollo pero falla en producción, o una compra se queda bloqueada cuando intervienen tres servicios distintos.
En sistemas sencillos, bastaba con abrir un log y seguir la pista. En arquitecturas distribuidas, como las que explicamos al hablar de arquitectura web moderna o de Kubernetes, ya no hay una única máquina que mirar. Hay que reconstruir la historia completa.
Logs: el relato detallado de lo que ha ocurrido
Los logs son registros de eventos. Dicen que un usuario ha iniciado sesión, que una API ha recibido una petición, que una consulta SQL ha fallado o que un proceso ha terminado con error. Bien usados, son una fuente magnífica para entender el “por qué” de un incidente.
El problema es que muchos logs se escriben pensando solo en el desarrollador que depura en local. Mensajes como “error inesperado” o “falló la operación” sirven de poco cuando el sistema está en producción y hay presión real. Un buen log debería incluir contexto: identificador de petición, servicio afectado, código de error, latencia, versión desplegada y entorno.
También importa el formato. Los logs estructurados permiten buscar, filtrar y correlacionar eventos con mucha más precisión que una línea de texto libre. No se trata de registrar todo sin criterio. Registrar demasiado genera ruido, coste y riesgo de exponer datos sensibles. Registrar bien significa dejar migas suficientes para investigar sin convertir la plataforma en un vertedero de mensajes.
Métricas: la salud del sistema en números
Las métricas convierten el comportamiento del sistema en series temporales. Peticiones por segundo, porcentaje de errores, latencia media, percentil 95, uso de CPU, consumo de memoria, conexiones abiertas, tamaño de una cola o tiempo de respuesta de una base de datos. Son números, pero cuentan una historia.
Su gran ventaja es que permiten detectar tendencias y activar alertas. Si la latencia sube de forma sostenida, si el número de errores se dispara después de un despliegue o si una cola empieza a crecer sin vaciarse, algo está cambiando. Google, en su material de Site Reliability Engineering, insiste en que la monitorización debe aportar visibilidad operativa y ayudar a tomar decisiones, no solo llenar pantallas con gráficas.
La clave está en elegir métricas útiles. No todas valen lo mismo. En un servicio web suele interesar especialmente la tasa de errores, la latencia, el tráfico y la saturación. La observabilidad empieza cuando esas métricas se conectan con el impacto real en el usuario.
Trazas: seguir una petición de extremo a extremo
Las trazas distribuidas son la pieza que muchos descubren tarde. Permiten seguir el recorrido de una petición desde que entra en el sistema hasta que termina. En cada salto se genera un tramo: frontend, API, autenticación, servicio de pagos, base de datos, cola de mensajes o proveedor externo. Así se ve cuánto tarda cada parte y dónde aparece el cuello de botella.
Imaginemos una tienda online. El usuario pulsa “pagar” y la pantalla se queda cargando. Los servidores están activos, la CPU no parece disparada y los logs muestran mensajes dispersos. Con una traza se puede ver que la petición pasa bien por el carrito, tarda poco en validar el usuario, pero se queda dos segundos esperando la respuesta del proveedor de pagos. El problema deja de ser abstracto.
Según la documentación de OpenTelemetry, las trazas representan el camino de una petición, las métricas capturan mediciones en tiempo de ejecución y los logs registran eventos. Por separado ayudan. Juntas, cambian por completo la investigación de incidencias.
OpenTelemetry y el reto de no casarse con una herramienta
Durante años, cada fabricante ha intentado imponer su propia forma de recoger telemetría. Eso crea dependencia y hace más difícil mover cargas entre entornos. OpenTelemetry nació precisamente como un marco abierto y neutral para instrumentar, generar, recoger y exportar datos de observabilidad.
La idea es potente: instrumentas tus aplicaciones una vez y después puedes enviar esa información a distintas plataformas de análisis, ya sean comerciales, open source, on-premise o cloud. En entornos híbridos y multi-cloud, esa neutralidad evita que la observabilidad quede atrapada dentro de un único proveedor.
Pero conviene no confundir herramienta con estrategia. Instalar un agente, desplegar un collector o contratar una plataforma no arregla por sí solo un sistema opaco. Hay que definir qué servicios son críticos, qué señales importan, qué alertas tienen sentido, quién las atiende y cómo se documentan los incidentes. Esto conecta directamente con la gestión de servicios, los SLA y la gobernanza TIC, temas que ya tratamos en Tecnoic al hablar de ITIL, COBIT y SLA.
Conclusión
La observabilidad no consiste en acumular dashboards bonitos. Consiste en poder responder rápido, con datos, cuando un sistema se comporta de forma extraña. Los logs explican eventos, las métricas muestran tendencias y las trazas reconstruyen recorridos. La combinación permite pasar de la intuición a la investigación técnica.
En un mundo de APIs, contenedores, microservicios y cloud, observar bien ya no es un lujo de grandes tecnológicas. Es una condición básica para operar con seriedad. ¿Tu sistema se entiende cuando falla o solo parece funcionar cuando todo va bien? Te leo en comentarios.