🎨 Imagen generada con IA.
¿Alguna vez abriste todos los dashboards disponibles, viste todo en verde, y de todas formas
alguien te mandó un mensaje diciendo que la app no cargaba?
Eso no es una falla técnica rara. Es una señal de algo más profundo: estás
monitoreando, pero no observando.
Y la diferencia entre las dos cosas es más importante de lo que parece.
Aprendí a manejar en un vocho sin un solo sensor
Aprendí a manejar en el Volkswagen sedán 1991 de mi mamá. Sin sensores de reversa, sin cámara, sin aviso de punto ciego, sin asistencias de ningún tipo. Puro espejo, oído y estómago. Uno aprende a calcular el espacio por intuición, y cuando algo salía mal te enterabas por el golpe.
Manejar hoy es otra cosa. El coche te avisa que viene alguien por el carril de al lado, que estás demasiado cerca, que se te bajó la presión de una llanta. No es que ahora manejes mejor: es que dejaste de depender de adivinar.
Operar infraestructura sin observabilidad se siente exactamente como ese vocho. Avanzas por espejo y por fe, con la experiencia como único sensor. Funciona —yo lo hice durante años— pero funciona hasta que no, y te enteras por el golpe: un usuario que llama, un cliente molesto, un servicio caído desde hace cuarenta minutos.
De eso trata todo lo que sigue. No de comprar herramientas: de dejar de manejar a ciegas.
El monitoreo hace una pregunta. Solo una.
El monitoreo lleva décadas con nosotros por buenas razones. Configurar alertas cuando el CPU supera el 90%, cuando un servidor deja de responder, cuando la tasa de errores sube de golpe — eso funciona. Y funcionó bien por mucho tiempo.
La trampa es que el monitoreo solo responde una pregunta: ¿está pasando algo malo?
El problema con esa pregunta es que asume que ya sabes qué buscar. Que ya definiste de antemano qué condición importa. Que el fallo que te va a doler mañana ya se parece a alguno que viste antes.
El usuario lo siente antes que tú.
Mi primer “aha”: cuando vi los saltos de internet
Mi primer acercamiento real a esto fue hace años con ThousandEyes. Al principio hasta me supo a poco, porque no me daba toda la información que yo esperaba. Pero el día que pude ver los saltos BGP —el camino exacto que tomaban los datos por internet, salto a salto— me voló la cabeza. De repente ya no solo sabía que algo iba lento: sabía por dónde.
Después llegaron las pruebas HTTPS sintéticas, y me pareció genial poder comprobar, una y otra vez y desde fuera, si un servicio respondía como debía, tal como lo vería un usuario real.
Con el tiempo caí en cuenta de algo: otras herramientas, como los APM, hacían algo parecido pero desde otro ángulo. Y ahí empecé a conectar los puntos —redes, wireless, seguridad, aplicaciones—: cada una me contaba una parte. La observabilidad no fue una herramienta que compré; fue el momento en que todas esas piezas dejaron de ser islas y empezaron a contarme una sola historia del sistema.
Por eso, cuando alguien me pregunta qué es la observabilidad, no arranco por la definición. Arranco por ahí: es pasar de mirar señales sueltas a entender el todo.
Entonces, ¿qué es la observabilidad?
La observabilidad no es una herramienta. No es una plataforma más costosa ni un dashboard con más colores. Es una propiedad de los sistemas: la capacidad de entender su estado interno a partir de las señales que emiten hacia afuera.
Un sistema es observable cuando puedes hacerle cualquier pregunta sobre su comportamiento y tienes los datos para responderla. Incluso preguntas que nunca anticipaste necesitar hacer.
Eso último es lo importante.
El monitoreo te dice que el semáforo está en rojo. La observabilidad te dice qué ocurrió en cada cruce del camino que llevó ahí: quién venía, a qué velocidad, qué señal ignoró primero, y si ya había pasado antes.
No es solo más información. Es una relación diferente con el sistema.
Las tres señales (y por qué las tres importan)
Cuando alguien habla de observabilidad, inevitablemente aparecen tres conceptos. No son redundantes ni intercambiables. Son complementarios, y cada uno aporta algo que los otros no pueden.
Números a lo largo del tiempo. Latencia, errores, solicitudes por segundo. Son el termómetro del sistema: el primero en avisarte cuando algo cambia, aunque no siempre te digan por qué.
El registro escrito de los eventos. Qué pasó, cuándo, con qué parámetros. El diario de a bordo del sistema. Verbosos, detallados, e indispensables cuando necesitas saber exactamente qué ocurrió.
El camino completo que recorre una solicitud por todos los servicios. En sistemas distribuidos, eso puede ser veinte componentes. Las trazas muestran exactamente dónde se rompe la cadena.
Juntas, estas tres señales no solo te dicen que algo está mal. Te dicen dónde, por qué y desde cuándo. Eso convierte datos en comprensión.
Lo que esto tiene que ver con el negocio
Los equipos que solo monitorean reaccionan. Reciben alertas, investigan, descubren, corrigen. El ciclo puede durar horas. En un sistema de pagos, en una plataforma de salud, en cualquier servicio con usuarios reales, esas horas tienen un costo muy concreto.
Los equipos con observabilidad investigan antes de que la alerta llegue. Ven señales tempranas. Correlacionan datos de varias fuentes. Y cuando algo falla de todas formas, el tiempo para entender el problema colapsa de horas a minutos.
No es eficiencia técnica por el gusto de la eficiencia. Es confianza del cliente. Es continuidad del servicio. Es la diferencia entre un incidente que nadie notó y uno que se volvió noticia.
El tablero en verde y el teléfono sonando
Durante años operé la telefonía de una dependencia de gobierno con oficinas repartidas por todo el país. El tablero marcaba disponibilidad del noventa y tantos por ciento, en verde, todos los días. Y todos los días alguien llamaba para avisar que en su oficina no entraban las llamadas.
Las dos cosas eran ciertas al mismo tiempo. El número del tablero era un promedio de cientos de sitios, y la mayoría eran grandes. Cuando una oficina de doce personas se quedaba muda, el promedio se movía tan poco que ninguna alerta llegaba a dispararse. El servicio estaba caído para esas doce personas y perfectamente sano para la métrica.
Eso es un agregado escondiendo un incidente, y es de los problemas que más he visto en veinte años. Lo incómodo es que el monitoreo no estaba mal configurado: contestaba con exactitud la pregunta que le habíamos hecho. Le preguntamos ¿está arriba el servicio? y respondió que sí. Nunca le preguntamos ¿está arriba para todos?, porque esa pregunta no cabía en el tablero.
Nuestra solución de entonces fue rudimentaria y bastante honesta: cada mañana a las ocho yo marcaba a mano a una decena de conmutadores para comprobar que respondieran. Una persona haciendo synthetic monitoring con un teléfono. Funcionaba dentro de lo que cabe, y tenía dos defectos enormes: solo cubría los sitios que me daba tiempo de marcar, y solo encontraba la falla a las ocho de la mañana. Si algo se caía a las nueve, nos enterábamos igual que siempre: porque alguien llamaba.
Lo que faltaba no era otra herramienta ni otro tablero. Faltaba poder preguntarle al sistema algo que nadie había previsto: ¿qué sitios llevan más de una hora sin cursar una sola llamada? Esa pregunta no existía en ningún lado porque a nadie se le había ocurrido antes de necesitarla. Poder hacerla sin desplegar nada nuevo es, en una frase, la diferencia entre monitorear y observar.
Hay un detalle de esa historia que tardé en entender: el problema nunca fue la falta de datos. Cada conmutador registraba lo que hacía. Los datos existían, estaban ahí, y aun así no servían de nada, porque estaban aplastados dentro de un promedio y no se podían separar por sitio sin pedirle a alguien que fuera a buscarlos a mano. Tener los datos y poder interrogarlos son dos cosas distintas, y casi todo el valor está en la segunda.
Hay un ejercicio de cinco minutos para saber si tu monitoreo tiene este punto ciego: toma tu métrica principal de disponibilidad y pregunta cuántos usuarios, o cuántos sitios, tendrían que estar caídos para que ese número bajara un solo punto. Si la respuesta te incomoda, ya sabes la distancia exacta que hay entre tu tablero y la experiencia real de la gente que usa el sistema.
Si te reconoces en la escena —el tablero en verde y los usuarios molestos— no tienes un problema de herramientas. Tienes un problema de granularidad y de preguntas. Y las dos se resuelven con lo mismo: guardar suficiente contexto de cada evento para poder cortarlo después por donde haga falta, aunque hoy todavía no sepas por dónde va a ser.
Mi primer archivo de datos inútiles era de papel
Hice mi servicio social en una dependencia donde toda la documentación se llevaba a mano. La oficina de mi jefe estaba llena de carpetas: años y años de muestras tomadas con disciplina, ordenadas y archivadas.
Nadie volvía a abrirlas.
Me acordé de esas carpetas muchos años después, mirando un tablero en verde. Son el mismo problema con dos disfraces distintos: en el archivo los datos existían y nadie los consultaba; en el tablero existían y estaban aplastados dentro de un promedio. En los dos casos la información estaba ahí. En los dos casos no servía de nada.
Por eso desconfío del consejo de “recolecta más telemetría”. Casi nunca el problema fue la captura.
¿Entonces el monitoreo ya no sirve?
Sí sirve. Y mucho.
El monitoreo sigue siendo necesario para detectar anomalías rápido y disparar alertas en el momento correcto. La observabilidad no reemplaza eso. Lo amplía. Todo sistema observable incluye monitoreo. Pero no todo sistema monitoreado es observable.
La diferencia clave está en la dirección de las preguntas. El monitoreo responde las que ya sabías que ibas a hacer. La observabilidad te permite responder las que todavía no sabías que necesitabas hacer. Y en sistemas complejos, esas siempre son las más importantes.
Un dato que me parece fascinante
El término observabilidad no nació en Silicon Valley. Viene de la teoría de control, un campo de la ingeniería que estudia cómo los sistemas responden a su entorno. Rudolf Kalman lo formalizó en 1960: un sistema es observable si su estado interno puede determinarse a partir de sus salidas externas. Décadas después, la industria del software adoptó el concepto para describir algo que se estaba volviendo urgente. El salto no fue tecnológico. Fue conceptual.
¿Y cómo se construye todo esto?
Construir observabilidad no ocurre de un día para otro. Implica instrumentar los sistemas para que emitan las señales correctas, diseñar cómo esos datos fluyen y se almacenan, y elegir las herramientas que tienen sentido en cada contexto.
Un estándar que está cambiando mucho este panorama es OpenTelemetry, mantenido por la Cloud Native Computing Foundation. Permite instrumentar una vez y enviar datos a múltiples plataformas sin quedar atado a un proveedor específico. Para equipos que no quieren depender de un solo vendor, eso es enorme.
Los próximos artículos de esta serie van a entrar en cada uno de estos temas. Las tres señales en profundidad. OpenTelemetry explicado sin drama. Cómo todo esto conecta con las decisiones de producto.
Pero antes de todo eso, tenía que estar esto: la diferencia entre mirar un dashboard y entender un sistema.
El monitoreo detecta si algo está mal según condiciones predefinidas. La observabilidad permite investigar por qué está mal, incluso ante situaciones que nadie anticipó, usando métricas, logs y trazas distribuidas.
Porque en sistemas distribuidos, una sola acción del usuario puede involucrar decenas de servicios. Si uno falla, el monitoreo tradicional puede no encontrar la causa raíz. La observabilidad conecta las señales de todos los componentes para revelarla.
Métricas, logs y trazas. Las métricas miden el estado general en el tiempo, los logs registran eventos específicos con detalle, y las trazas siguen el recorrido completo de una solicitud a través de los servicios.
No. El monitoreo sigue siendo necesario. La observabilidad lo complementa añadiendo contexto, profundidad y capacidad de investigación, tanto cuando las alertas se disparan como antes de que lo hagan.
Las más comunes incluyen OpenTelemetry como estándar abierto de instrumentación, junto con plataformas como Datadog, Splunk, Grafana, Dynatrace y New Relic. La elección depende del stack, el equipo y el presupuesto.
No. Los principios aplican a cualquier sistema con usuarios reales. OpenTelemetry es gratuito y de código abierto, y muchas plataformas tienen niveles gratuitos para empezar sin inversión inicial.
Que puedes entender su estado interno a partir de las señales que emite: métricas, logs y trazas. Que puedes responder cualquier pregunta sobre su comportamiento, incluso preguntas que nunca habías anticipado necesitar hacer.
Que los sistemas estén con ustedes. ✦
Ethel Méndez
Senior Product Manager en observabilidad y redes B2B, con 20 años de campo, NOC y servicios administrados en LATAM. Escribo lo que aprendí operando sistemas de verdad, no en un curso.