El sistema funciona. Hasta el momento en que deja de hacerlo
Imagina una tienda en línea en la que los clientes pueden navegar por los productos, añadirlos al carrito y pasar al pago. El servidor responde, la página se abre y las métricas básicas de la infraestructura no indican ningún problema grave. A primera vista, todo funciona correctamente.
Mientras tanto, algunos clientes no pueden completar su pedido. Para unos, el pago tarda varios segundos; para otros, aparece un error. El equipo técnico recibe reportes, pero aún no sabe si la causa es la pasarela de pago, la base de datos, la última actualización de la aplicación o quizá un problema de comunicación entre servicios.
Esta es una situación en la que el monitoreo tradicional puede resultar insuficiente. Puede indicar que aumentó el número de errores o que se alargó el tiempo de respuesta, pero no siempre aporta la información necesaria para encontrar rápidamente la causa.
Precisamente esa laguna la cubre la observability, es decir, la observabilidad del sistema. Su objetivo no es solo constatar que la aplicación funciona de forma incorrecta. Se trata de poder analizar su comportamiento, reconstruir la secuencia de eventos y encontrar el origen del problema, incluso cuando antes no se había previsto un escenario concreto de falla.
Monitoreo y observability: objetivos similares, posibilidades distintas
El monitoreo y la observability están estrechamente relacionados, pero no significan lo mismo.
El monitoreo consiste en recopilar y analizar sistemáticamente datos sobre el estado de la aplicación y de la infraestructura. Permite seguir parámetros definidos, detectar desviaciones respecto a las normas establecidas y activar alertas cuando se produce una situación que requiere reacción.
Preguntas de ejemplo a las que responde el monitoreo:
- ¿El servidor está disponible?
- ¿Cuál es el tiempo medio de respuesta de la API?
- ¿El número de errores HTTP 500 supera el umbral establecido?
- ¿Cuál es el uso de memoria y procesador?
- ¿La cola de tareas crece más rápido de lo que el sistema puede procesarla?
La observability va más allá. Permite analizar datos procedentes de distintas partes del sistema y combinarlos en un contexto que ayuda a entender por qué se produjo un comportamiento determinado.
Puede resumirse en tres preguntas:
- Monitoreo: ¿Hay algo mal?
- Diagnóstico: ¿Dónde apareció el problema?
- Observability: ¿Qué ocurrió, por qué y cuál fue el impacto en el funcionamiento del sistema?
La observabilidad no sustituye al monitoreo. Es un enfoque que utiliza el monitoreo y datos telemétricos debidamente preparados para permitir un análisis más profundo del comportamiento de la aplicación. OpenTelemetry describe la observability como la capacidad de hacer preguntas al sistema sobre su comportamiento basándose en señales como logs, métricas y trazas distribuidas. <Cite ref="turn154932search0"/>
Tres pilares de la observability: logs, métricas y tracing
La base de la observabilidad son tres tipos de datos telemétricos: logs, metrics y traces. Cada uno muestra un aspecto distinto del funcionamiento de la aplicación. Solo su correlación ofrece una visión más amplia de la situación.
1. Logs: ¿qué ocurrió en la aplicación?
Los logs son registros estructurados de eventos generados por la aplicación, el sistema operativo, los servidores, las bases de datos y otros elementos de la infraestructura.
Pueden registrar, por ejemplo:
- el inicio y el fin de un proceso,
- el intento de inicio de sesión de un usuario,
- el envío de una solicitud a una API externa,
- un error de validación de datos,
- una transacción fallida,
- una excepción generada por la aplicación,
- el cambio de estado de un pedido.
Un log puede incluir una marca de tiempo, el nivel de importancia, el nombre del servicio, el mensaje, el identificador de la solicitud y atributos adicionales que describen el evento.
Conviene distinguir entre logs de texto y logs estructurados. Un registro de texto puede verse así:Error al procesar el pedido
Ese mensaje informa de que ha surgido un problema, pero dice poco sobre su contexto. En cambio, un log estructurado puede contener campos separados, como el identificador del pedido, el nombre de la operación, el código de error, el tiempo de ejecución y el identificador de la traza. Gracias a ello, los datos se pueden filtrar, agrupar y analizar automáticamente.
Buena práctica: los logs deben diseñarse pensando en el análisis posterior, y no solo en guardar mensajes. Conviene usar una nomenclatura coherente, niveles de importancia e identificadores de correlación que permitan vincular eventos procedentes de distintos componentes.
Al mismo tiempo, el registro debe hacerse con criterio. Guardar cada operación en toda su extensión puede generar enormes cantidades de datos, aumentar los costos de almacenamiento y dificultar la búsqueda de información relevante. Igualmente importante, los logs no deben revelar contraseñas, tokens de acceso, datos de tarjetas de pago ni otra información confidencial. Es necesario aplicar enmascaramiento, control de acceso, periodos de retención adecuados y normas de tratamiento seguro de los datos.
2. Métricas: ¿cómo se comporta el sistema con el tiempo?
Las métricas son datos numéricos agregados que describen el estado, el rendimiento y el comportamiento del sistema en un periodo determinado.
Entre las métricas de ejemplo se incluyen:
- el número de solicitudes atendidas por segundo,
- el porcentaje de solicitudes finalizadas con error,
- el tiempo de respuesta de la API,
- el uso de CPU y memoria,
- el número de sesiones activas,
- la longitud de la cola de tareas,
- el número de transacciones completadas,
- el tiempo de espera para conectar con la base de datos.
Su mayor ventaja es la posibilidad de observar tendencias. Un error puntual puede ser un incidente, pero un tiempo de respuesta que aumenta gradualmente, un número creciente de transacciones fallidas o una cola de tareas cada vez mayor pueden indicar un problema en desarrollo.
En la práctica, las métricas ayudan a responder no solo a la pregunta de si la aplicación funciona, sino también a si su rendimiento responde a las expectativas de los usuarios y a los requisitos del negocio.
Especialmente útiles son los percentiles del tiempo de respuesta, por ejemplo p95 y p99. La media puede ocultar una situación en la que la mayoría de los usuarios recibe respuesta rápidamente, pero una pequeña parte experimenta retrasos muy grandes. Los percentiles muestran cuánto tardan en atenderse las solicitudes más lentas y ayudan a detectar problemas que no se ven en los valores medios.
Buena práctica: elige métricas que tengan relevancia para el usuario y para el proceso de negocio. La simple información sobre la carga de la CPU no dirá si el cliente puede realizar un pedido. Por eso conviene monitorizar también indicadores relacionados con las funciones clave, como la tasa de éxito de los pagos, el tiempo de procesamiento del pedido o la disponibilidad de las operaciones más importantes.
3. Tracing: ¿por dónde pasó la solicitud?
El tracing, y en particular el distributed tracing, es decir, el seguimiento distribuido, permite rastrear el recorrido de una sola solicitud a través de distintos componentes del sistema.
En una aplicación moderna, una acción del usuario puede incluir varias etapas. Hacer clic en el botón «Realizar pedido» puede desencadenar una solicitud en el navegador, que llega a la API, luego al servicio de pedidos, a la base de datos, al sistema de inventario y a un proveedor externo de pagos.
Si el proceso se retrasa, la información sobre el tiempo de respuesta de toda la API por sí sola puede no ser suficiente. El tracing permite descomponer ese tiempo en operaciones individuales y ver qué etapa es responsable del retraso.
El elemento básico de un trace es un span, es decir, el registro de una sola operación. Un span puede contener la hora de inicio y fin, el nombre de la operación, el estado y metadatos. Los spans relacionados forman un trace que muestra el recorrido de toda la solicitud.
Por ejemplo:
- La API recibe la solicitud y la pasa más adelante.
- El servicio de pedidos verifica los datos.
- La base de datos guarda el pedido.
- El servicio de inventario comprueba la disponibilidad del producto.
- La pasarela de pago externa procesa la transacción.
- La aplicación devuelve el resultado al usuario.
Si todo el proceso dura 8 segundos, el tracing puede mostrar que 6,5 segundos los ocupó la respuesta de la pasarela de pago externa, mientras que las demás operaciones se desarrollaron correctamente. Entonces, el equipo obtiene un punto concreto para seguir analizando, en lugar de empezar la diagnosis a partir de componentes aleatorios.
El tracing es especialmente útil en arquitecturas de microservicios, sistemas distribuidos, aplicaciones basadas en colas y soluciones que integran muchos servicios externos. <Cite ref="turn154932search0"/>
Alertas: la información debe llegar a la persona adecuada
Los datos de telemetría solo son útiles cuando permiten actuar sobre ellos. Por eso, una parte importante de la observabilidad es el sistema de alertas.
Una alerta es una notificación sobre un evento o estado que requiere atención. Puede activarse al superar un umbral de una métrica, al detectar un patrón concreto de errores o al constatar que una función clave de la aplicación no funciona como se esperaba.
Sin embargo, no todo aumento de carga debería generar una alarma. Si el sistema atiende con regularidad mucho tráfico en horas punta, notificar cada incremento del número de solicitudes provocará ruido informativo. Demasiadas alertas hacen que se ignoren y, como consecuencia, se pase por alto un incidente realmente importante.
Por tanto, conviene determinar:
- qué eventos requieren una reacción inmediata,
- qué problemas pueden analizarse en un modo de trabajo estándar,
- quién es responsable de cada tipo de alerta,
- qué información debe incluir la notificación,
- qué acciones deben tomarse después de recibirla.
Un buen punto de partida es definir las alertas en función del impacto sobre el usuario y los objetivos de fiabilidad, y no solo según parámetros de infraestructura. Por ejemplo, una alerta por el aumento de la tasa de pagos fallidos puede tener más importancia de negocio que un pico breve en el uso de CPU.
Una alerta debe llevar a la acción. Si no se sabe quién debe gestionarla ni qué hay que hacer, no es más que otro mensaje en el sistema.
Ejemplo práctico: ¿cómo ayuda la observabilidad a encontrar la causa de una incidencia?
Supongamos que los usuarios de una aplicación B2B informan de que la generación de informes tarda mucho más de lo habitual. El monitoreo detecta un aumento del tiempo de respuesta y activa una alerta.
El equipo comienza el análisis:
- Las métricas indican que el problema afecta sobre todo a los informes que abarcan grandes rangos de datos. El resto de las funciones funciona con normalidad.
- El tracing muestra que el mayor retraso aparece durante la ejecución de la consulta a la base de datos.
- Los logs contienen detalles de la consulta, sus parámetros operativos e información sobre errores, sin revelar datos sensibles.
- La correlación de datos permite vincular un trace concreto con las entradas correspondientes en los logs y los cambios visibles en los gráficos de métricas.
- El análisis del cambio indica que el problema apareció después de desplegar la nueva versión del informe, que empezó a ejecutar una consulta costosa.
Gracias a ello, el equipo no tiene que revisar a ciegas toda la infraestructura. Puede concentrarse en una operación concreta, comparar el comportamiento antes y después del despliegue y, a continuación, optimizar la consulta o revertir el cambio.
La observabilidad no elimina las incidencias ni garantiza que se encuentre automáticamente cada causa. Sin embargo, permite acotar el ámbito de búsqueda, reducir el tiempo de diagnóstico y basar las decisiones en datos en lugar de suposiciones.
Correlación de datos: el mayor valor aparece cuando todo se combina
Los logs, las métricas y el tracing son útiles por separado, pero su verdadero valor aparece cuando pueden relacionarse entre sí.
Imaginemos que un dashboard muestra un aumento repentino del tiempo de respuesta. La métrica indica cuándo y en qué escala apareció el problema. El trace muestra qué operaciones componían la solicitud lenta. Los logs permiten comprobar qué eventos ocurrieron en una etapa concreta.
Para que esto sea posible, el sistema debe transmitir de forma coherente el contexto de la solicitud entre los servicios. Los identificadores de trace y span pueden usarse para vincular entradas de logs con traces. También conviene mantener información coherente sobre el nombre del servicio, el entorno, la versión de la aplicación y otros atributos que describan el origen de los datos.
Sin correlación, el equipo puede tener acceso a muchos dashboards, archivos y herramientas, pero seguir perdiendo tiempo al determinar manualmente qué eventos están relacionados. OpenTelemetry señala la correlación de logs, traces y contexto de recursos como un elemento importante para construir una telemetría útil. <Cite ref="turn154932search1"/>
OpenTelemetry: un estándar común para los datos de telemetría
Implementar observabilidad no tiene por qué significar depender de un único proveedor de herramientas. Una de las soluciones que favorecen la interoperabilidad es OpenTelemetry (OTel), un conjunto abierto de estándares, API, bibliotecas y herramientas para instrumentar, generar, recopilar y exportar datos de telemetría.
OpenTelemetry permite que la aplicación emita métricas, logs y traces con un modelo coherente. Después, los datos pueden enviarse al backend de observabilidad elegido, que se encarga de almacenarlos, buscarlos, visualizarlos y analizarlos.
Un elemento importante del ecosistema es OpenTelemetry Collector. Puede recibir datos de distintas fuentes, procesarlos, enriquecerlos con contexto adicional y exportarlos a los sistemas configurados. Gracias a ello, la aplicación no tiene que estar vinculada directamente con cada herramienta utilizada para el análisis.
Este enfoque es especialmente útil cuando la empresa utiliza muchas tecnologías, desarrolla la arquitectura del sistema o quiere conservar la posibilidad de cambiar de proveedor de herramientas. Sin embargo, el estándar por sí solo no garantiza una observabilidad completa. Siguen siendo necesarias una instrumentación adecuada, una estrategia bien pensada de recopilación de datos, dashboards apropiados, alertas y procedimientos de respuesta. <Cite ref="turn154932search3"/>
¿Cuándo conviene implementar observabilidad?
La observabilidad puede ser útil tanto en grandes sistemas distribuidos como en aplicaciones más pequeñas, en las que una caída o un fallo difícil de detectar tenga consecuencias de negocio importantes.
Conviene especialmente considerar este enfoque cuando:
- la aplicación consta de muchos servicios o integraciones,
- los problemas aparecen de forma irregular y son difíciles de reproducir,
- los usuarios informan de errores que no se ven en las pruebas estándar,
- el tiempo de diagnóstico de incidentes es demasiado largo,
- las sucesivas implementaciones provocan efectos difíciles de prever,
- la empresa está desarrollando el sistema y necesita datos para planificar el rendimiento,
- la aplicación gestiona procesos clave de ventas, operativos o financieros,
- el equipo necesita comprender mejor el impacto de los servicios externos en el funcionamiento de toda la solución.
Sin embargo, eso no significa que cada sitio web necesite un entorno de telemetría avanzado. En un servicio pequeño y sencillo, pueden bastar los registros básicos, la supervisión de disponibilidad y unas pocas métricas clave. El alcance de la solución debe corresponder a la complejidad de la aplicación, la escala del tráfico, los requisitos de fiabilidad y el coste de las posibles interrupciones.
¿Cuándo puede la observability ser un exceso de forma sobre contenido?
Implementar herramientas avanzadas sin un objetivo claramente definido puede generar más costes que beneficios.
Entre los errores más comunes se encuentran:
- Recopilar todo sin un plan. El exceso de datos aumenta los costes y dificulta la búsqueda de información relevante para el diagnóstico.
- No tener preguntas a las que el sistema deba responder. Los paneles pueden verse espectaculares, pero no ayudar a resolver problemas reales.
- Alertar por cada desviación. Un número excesivo de notificaciones provoca fatiga de alertas y aumenta el riesgo de pasar por alto un incidente.
- No asignar responsabilidad de respuesta. Incluso un problema bien detectado puede prolongarse mucho si nadie sabe quién debe ocuparse de él.
- No proteger los datos. La telemetría puede contener información sensible, identificadores de usuarios o datos operativos que requieren acceso restringido y una retención adecuada.
- Ignorar el coste de la instrumentación. Recopilar trazas y registros detallados a gran escala puede afectar al rendimiento de la aplicación y generar costes significativos de almacenamiento y procesamiento.
- Tratar la herramienta como una solución lista para usar. Instalar la plataforma por sí solo no garantiza una instrumentación correcta ni un proceso de diagnóstico eficiente.
Observability requiere, por tanto, no solo tecnología, sino también decisiones organizativas: qué datos son necesarios, quién los analiza, cómo responde el equipo y de qué manera las conclusiones de los incidentes se traducen en cambios en el sistema.
¿Cómo planificar la implementación de observability?
Lo más seguro es desarrollar la observabilidad por etapas, empezando por los procesos y funciones cuyo fallo tenga el mayor impacto en los usuarios y en la empresa.
1. Define los procesos de negocio clave
Identifica las operaciones más importantes, como el inicio de sesión, la realización de pedidos, los pagos, la generación de documentos o la sincronización de datos. Estas deben ser el punto de partida para determinar qué significa que la aplicación funcione correctamente.
2. Establece indicadores de fiabilidad
Elige métricas que reflejen la experiencia del usuario, por ejemplo la disponibilidad de funciones clave, el tiempo de respuesta o el porcentaje de operaciones completadas con éxito. Para los servicios importantes se puede definir un SLI (Service Level Indicator), es decir, un indicador de nivel de servicio, y un SLO (Service Level Objective), es decir, un objetivo relativo a ese indicador.
3. Cuida los registros estructurados
Unifica el formato de los registros, los niveles de importancia y los atributos básicos. Asegúrate de incluir identificadores de correlación y una política de eliminación o enmascaramiento de datos confidenciales. Los registros deben ser legibles para el equipo y procesables por las herramientas.
4. Añade tracing en las rutas críticas
Empieza por los procesos que abarcan varios servicios, bases de datos o integraciones externas. Sigue el recorrido de la solicitud por el sistema y cuida la propagación del contexto entre componentes.
5. Construye paneles en torno a preguntas concretas
En lugar de crear un único panel enorme, prepara vistas que respondan a las necesidades de distintos roles. El equipo técnico puede necesitar información sobre errores y retrasos, mientras que el propietario del producto puede necesitar datos sobre la eficacia de los procesos clave y el impacto de las interrupciones en los usuarios.
6. Diseña alertas y procedimientos de respuesta
Establece umbrales, prioridades, responsables e instrucciones de actuación. La alerta debe incluir contexto que ayude a iniciar rápidamente el diagnóstico, y no solo informar de que se ha superado un valor.
7. Prueba la observabilidad
Comprueba si el equipo es capaz de encontrar la causa de un error de ejemplo a partir de los datos disponibles. Se pueden realizar pruebas controladas de fallos en un entorno de pruebas o ejercicios de respuesta a incidentes. También conviene verificar si las alertas se activan cuando deben.
8. Desarrolla la solución a partir de los incidentes
Después de cada problema importante, conviene revisar qué información estaba disponible, qué faltaba y cómo se puede mejorar la instrumentación, las alertas o los procedimientos. Observability no es un proyecto de una sola vez, sino un proceso de mejora del conocimiento sobre el funcionamiento del sistema.
Costes y seguridad: dos aspectos que no se pueden pasar por alto
Los datos de telemetría tienen un precio. Los costes pueden derivarse de la instrumentación, la transferencia, la indexación, el almacenamiento, la retención y el análisis de datos. En sistemas con mucho tráfico, puede resultar especialmente costoso recopilar todas las trazas o registros muy detallados.
Por eso merece la pena aplicar una retención adaptada a las necesidades, filtrado de datos, muestreo de trazas (sampling) y distintos niveles de detalle según el entorno. Por ejemplo, un sistema en producción puede recopilar datos completos para errores y ciertas operaciones críticas, y muestrear parte de las solicitudes correctas para limitar el volumen.
Igualmente importante es la protección de los datos. Los registros y las trazas pueden contener sin querer datos personales, identificadores de sesión, fragmentos de consultas o información sobre la estructura de la infraestructura. Es necesario limitar el acceso a la telemetría, eliminar datos innecesarios, enmascarar la información confidencial y controlar los periodos de conservación. También conviene tratar los sistemas de observability como parte del entorno de producción, que a su vez requiere medidas de seguridad, copias de seguridad y control de permisos.
Observability como herramienta de gestión, no solo de diagnóstico
Aunque la observabilidad suele asociarse al trabajo de desarrolladores, DevOps y administradores, su valor va más allá del ámbito de TI.
Los datos sobre el tiempo de respuesta, los errores, la disponibilidad y la eficacia de los procesos pueden ayudar a la empresa a entender qué elementos tecnológicos apoyan la actividad y cuáles la limitan. Permiten identificar problemas recurrentes, evaluar el impacto de los cambios y planificar el desarrollo basándose en el comportamiento real del sistema.
Si, por ejemplo, el sistema de pedidos se ralentiza con regularidad en determinadas horas, los datos de telemetría pueden ayudar a determinar si hace falta optimizar consultas, cambiar la forma de procesar tareas o ampliar la infraestructura. En lugar de invertir en recursos adicionales basándose en la intuición, la empresa puede primero identificar el verdadero cuello de botella.
Observability también apoya el análisis de los efectos de las implementaciones. Comparar métricas, trazas y logs antes y después del cambio permite detectar regresiones más rápido y evaluar si la actualización produjo el efecto esperado.
Sin embargo, no debe equipararse la observabilidad con la toma automática de decisiones. Los datos muestran el comportamiento del sistema, pero su interpretación requiere conocer la arquitectura, los procesos de negocio y el contexto del incidente concreto.
Glosario de términos
- Observability (observabilidad) - capacidad de comprender el comportamiento interno de un sistema a partir de los datos que emite.
- Monitoring - seguimiento continuo de parámetros seleccionados y detección de estados específicos que requieren atención.
- Telemetry (telemetría) - datos recopilados y transmitidos desde la aplicación y la infraestructura con el fin de analizar su funcionamiento.
- Logs (logs) - registros de eventos que ocurren en la aplicación o en la infraestructura.
- Metrics (métricas) - mediciones numéricas del estado, rendimiento o comportamiento del sistema a lo largo del tiempo.
- Tracing - seguimiento del recorrido de las operaciones a través de los componentes de la aplicación.
- Distributed tracing - seguimiento de una sola solicitud en un sistema compuesto por muchos servicios o procesos.
- Span - registro de una operación individual que forma parte de una traza.
- Trace - conjunto de spans relacionados que muestran el recorrido de una operación.
- Alert - notificación sobre un estado o evento detectado que requiere reacción.
- SLI - indicador que mide un aspecto concreto del funcionamiento de un servicio.
- SLO - objetivo definido para un indicador de fiabilidad seleccionado.
- Sampling - técnica para limitar la cantidad de datos telemétricos recopilados mediante la selección de una parte representativa de los eventos.
- OpenTelemetry - conjunto abierto de estándares y herramientas que apoyan la instrumentación y exportación de datos telemétricos.
Resumen
La falla de una aplicación no siempre empieza con un servidor no disponible o un mensaje de error. A veces el sistema funciona formalmente, pero una función clave se vuelve demasiado lenta, parte de las transacciones no se completa con éxito o la integración falla solo en determinadas condiciones.
Monitoring ayuda a detectar irregularidades. Observability permite comprender qué condujo a su aparición y cuál fue su impacto en el funcionamiento de la aplicación. Los logs, las métricas, el tracing y unas alertas bien diseñadas forman juntos la base para un diagnóstico más ágil, un desarrollo consciente y la reducción del riesgo operativo.
No se trata de recopilar la mayor cantidad posible de datos ni de crear los dashboards más complejos. Se trata de que, cuando surja un problema, no preguntarse solo: „¿Está funcionando el sistema?”, sino poder determinar: „¿Qué ocurrió exactamente en el sistema, por qué y qué deberíamos hacer a continuación?”
Una aplicación madura no es solo la que funciona. Es también aquella cuyo comportamiento se puede comprender, diagnosticar y mejorar.
