En el complejo mundo de las arquitecturas de microservicios y cloud native, simplemente saber si un servicio está «vivo» ya no es suficiente. Necesitamos la capacidad de entender el estado interno de nuestros sistemas sin tener que adivinar los posibles fallos.
En este artículo, exploraremos a fondo la Observabilidad, la piedra angular de la gestión de sistemas distribuidos hoy en día. Descubriremos cómo esta práctica va mucho más allá de la monitorización tradicional , permitiéndonos responder al crucial ¿Por qué está pasando? para dominar los temidos problemas desconocidos o «unknown unknowns». Además, veremos cómo OpenTelemetry ha llegado para estandarizar y facilitar todo este proceso.
1. ¿Qué es la Observabilidad?
La Observabilidad es la capacidad de comprender el estado interno de un sistema a partir de los datos que produce, conocidos como telemetría. Va mucho más allá de la monitorización tradicional.
Mientras que la monitorización responde al ¿Qué está pasando? (por ejemplo, «La CPU está al 90%»), la Observabilidad nos permite responder al crucial ¿Por qué está pasando? Nos ayuda a manejar los temidos «unknown unknowns» (problemas desconocidos).
Las claves de la observabilidad son la alta cardinalidad (granularidad), alta dimensionalidad (muchos atributos de contexto) y la capacidad exploratoria de los datos.
2. La base de la Observabilidad: Las tres señales
Para lograr esta comprensión profunda del estado interno de un sistema, la Observabilidad no se basa en un único tipo de dato, sino en una colección orquestada de telemetría. Solo la combinación y correcta correlación de estas fuentes de información nos proporciona el poder de diagnóstico necesario para navegar por sistemas distribuidos complejos.
Para lograr esta visión completa, la observabilidad se fundamenta en tres tipos de datos de telemetría, que deben estar correlacionados entre sí.
- Métricas (Metrics): Responden a ¿QUÉ está pasando? Son datos numéricos agregados que indican que «Algo está pasando». Ejemplos incluyen el uso de CPU o el número de peticiones por segundo.
- Trazas (Traces) y Distributed Tracing: Responden a ¿DÓNDE está pasando? Muestran el recorrido completo de una solicitud a través de un sistema distribuido. Nos permiten aislar el componente o servicio específico que está causando el cuello de botella o error.
- Logs: Responden a ¿POR QUÉ está ocurriendo? Proporcionan el detalle específico del problema: mensajes de error, valores de variables y el contexto exacto del fallo. Un log correlacionado puede indicar, por ejemplo, un «Error: Timeout en DB».
Juntas resuelven el misterio: Las métricas detectan QUÉ está pasando, las traces muestran DÓNDE está sucediendo el problema, y los logs explican QUÉ EXACTAMENTE está ocurriendo.
Esto reduce drásticamente el MTTK (Mean Time to Know), permitiendo que una sola persona diagnostique incidentes complejos sin tener conocimiento previo del sistema.
Además, las señales OTEL permiten relacionar los servicios entre sí gracias a las trazas que indican “el viaje” que hace la petición de un usuario por los diferentes servicios. Por ejemplo, la visualización de dichas señales desde kibana haciendo uso de señales OTEL almacenadas en ElasticSearch:
3. ¿Por qué la Observabilidad es crucial hoy?
La necesidad de observabilidad está impulsada por la complejidad de las arquitecturas modernas:
- Arquitecturas Distribuidas: Los sistemas modernos (microservicios, serverless, multi-cloud) han incrementado exponencialmente la complejidad, creando múltiples puntos de fallo.
- Fallos en Cascada: Es esencial reducir el MTTR (Tiempo de Recuperación) y MTTD (Tiempo de Detección) para entender y controlar arquitecturas con muchos componentes.
- Escalabilidad de Equipos: Permite que cualquiera pueda investigar problemas sin depender de un experto o un equipo específico con conocimiento del sistema.
Impacto en el negocio
Las organizaciones con buenas prácticas de observabilidad logran hasta un 90% de reducción en tiempo de resolución (MTTR) y pueden prevenir hasta un 60% de los incidentes antes de que afecten a los usuarios.
4. Observabilidad vs. Monitorización tradicional
No son excluyentes, sino complementarias. La monitorización proporciona información, y la observabilidad ofrece el contexto profundo para la investigación.
| Monitorización Tradicional | Observabilidad Moderna |
| Enfoque: Recopila datos sobre la salud del sistema con umbrales predefinidos. | Enfoque: Analiza estados internos del sistema a partir de sus salidas para entender el comportamiento. |
| Responde: ¿Está roto? ¿Supera el umbral? | Responde: ¿Por qué está roto? ¿Cómo afecta a los usuarios? |
| Datos: Métricas predefinidas, baja cardinalidad, datos agregados. | Datos: Exploración arbitraria, alta cardinalidad, datos sin procesar y correlacionados. |
| Enfoque Temporal: Reactivo (responde a problemas conocidos). | Enfoque Temporal: Proactivo (permite diagnosticar unknown unknowns y problemas no previstos). |
5. OpenTelemetry: El proyecto estándar
La complejidad de instrumentar cada microservicio en diferentes lenguajes y para distintos backends ha sido resuelta por OpenTelemetry (Otel).
- Estándar Abierto: Es un proyecto de la CNCF (Cloud Native Computing Foundation) con nivel de incubación. Nació de la fusión de OpenCensus (Google) y OpenTracing (CNCF) en 2019. Es el segundo proyecto más activo de la CNCF después de Kubernetes.
- Instrumentar una sola vez: Proporciona un framework unificado y vendor-agnostic (independiente del proveedor) para instrumentación. Permite instrumentar tus aplicaciones una única vez y enviar los datos a cualquier backend de observabilidad, eliminando la dependencia de un proveedor.
- Componentes Clave: Define API, SDK, y el Protocolo OTLP (OpenTelemetry Protocol), que es el formato estándar para transmitir datos de telemetría, compatible con múltiples backends.
6. Componentes de OpenTelemetry
- Specification: Define requisitos multiplataforma para API (tipos de datos y operaciones), SDK (implementación) y Datos (protocolo OTLP y convenciones semánticas).
- Collector: Proxy agnóstico de proveedor que recibe, procesa y exporta telemetría en múltiples formatos (OTLP, Jaeger,Prometheus y herramientas comerciales).
- APIs/SDKs específicos por lenguaje: Implementaciones que permiten instrumentar código, integrar con frameworks populares y exportar datos a backends.
- Zero-code instrumentation: Agentes que instrumentan aplicaciones sin modificar código fuente (como el Java Agent).
7.- Implementando la Observabilidad: Formas de instrumentación
La instrumentación es el proceso de añadir código o configuraciones a tu aplicación para que ésta emita las señales de observabilidad (traces, metrics, logs). Es la forma en que tu aplicación ‘habla’ y comunica su comportamiento.
La mejor práctica combina la instrumentación automática para obtener visibilidad rápida de la infraestructura, y la manual para capturar los datos de negocio más críticos.
1. Automática (Zero-Code Instrumentation)
Este es el método más rápido y no requiere modificar el código fuente de tu aplicación.
- Mecanismo: Utiliza Agentes (como el Java Agent de OpenTelemetry) o starters de frameworks (como el de Spring Boot). Estos interceptan llamadas a librerías comunes (HTTP, bases de datos, mensajería).
- Ejemplo de Implementación (Java Agent):
java -javaagent:opentelemetry-javaagent.jar -jar jar - Descripción: Ejecuta la aplicación Java cargando el agente de instrumentación antes de iniciar el código de la aplicación, generando telemetría de operaciones comunes.
- Instrumentación Zero-Code en Kubernetes con el Operador de OpenTelemetry:
- Para entornos Kubernetes, el OpenTelemetry Operator puede inyectar automáticamente los agentes de instrumentación (initContainer) en tus Pods.
- Simplemente marcas los namespaces o Pods deseados con una anotación o etiqueta, y el Operador se encarga de modificar automáticamente la configuración de despliegue para que las aplicaciones comiencen a emitir telemetría OpenTelemetry.
- Ventaja clave en Kubernetes: Gestión centralizada y escalable de la instrumentación para cientos de microservicios sin tocar sus deployment files ni el código de la aplicación.
- Ventajas/Funcionalidad:
- Rápido: Ideal para un inicio rápido o aplicaciones legacy y obtener telemetría de infraestructura.
| Característica | Agente (Java Agent) | Operador (Kubernetes) |
| Ambiente Típico | Máquina Virtual o Contenedor Individual | Entornos Cloud Native (Kubernetes) |
| Mecanismo | Argumento de línea de comandos (-javaagent) | Inyección del aganete usando initContiner automática (Zero-Code) |
| Ventaja | Simple y universal para ese lenguaje | Centralizado, escalable y automatizado para toda la orquestación |
2. Manual con SDK (código modificado)
Este enfoque te da control total para capturar la lógica de negocio específica de tu dominio, escribiendo el código usando la API de OpenTelemetry.
- Mecanismo: El desarrollador inserta llamadas al SDK para crear spans y agregar métricas en puntos clave de la lógica de negocio.
- Ejemplo de Implementación (Java Tracing):
Span span = tracer.spanBuilder("processPayment").startSpan();
try {
// tu lógica de negocio
} finally {
span.end();
}
- Descripción: Crea un nuevo span llamado processPayment que se añade a la traza actual, midiendo la duración exacta de esa operación de negocio.
- Ventajas/Funcionalidad:
- Control Total: Captura lógica de negocio específica de tu dominio.
- Personalización: Ideal para métricas custom y trazas específicas
En resumen, la observabilidad moderna ha transformado la forma en que gestionamos arquitecturas complejas, permitiéndonos evolucionar de una monitorización tradicional puramente reactiva a una postura proactiva que nos ayuda a entender realmente el «por qué» de los problemas.
Al combinar y correlacionar las tres señales clave —métricas, trazas y logs— obtenemos el poder de detectar rápidamente las anomalías, localizar con precisión el componente afectado y conocer el detalle exacto del fallo sin tener que adivinar.
En este ecosistema, OpenTelemetry se ha consolidado como la herramienta definitiva, ofreciendo un estándar abierto e independiente que nos permite instrumentar nuestras aplicaciones una única vez. Ya sea optando por una instrumentación automática para obtener resultados rápidos sin tocar el código, o mediante una instrumentación manual para capturar la lógica de negocio más crítica, adoptar estas prácticas marca un antes y un después.
Al final, todo esto se traduce en un impacto directo y medible para el negocio: equipos más ágiles, una reducción drástica del tiempo de resolución (MTTR) y la prevención de incidentes antes de que lleguen a impactar a los usuarios.
¿Y tú, en qué punto te encuentras en tu viaje hacia la observabilidad?
Nos encantaría conocer tu experiencia de primera mano.
Déjanos un comentario más abajo contándonos: ¿qué herramientas de telemetría o monitorización estás usando actualmente en tus proyectos? ¿Cuál ha sido el mayor dolor de cabeza o «unknown unknown» al que te has enfrentado intentando rastrear un fallo en producción?
Álvaro Olmedo-Rodríguez. Ingeniero de Sistemas. Datadope
