Durante décadas, saber si tu infraestructura funcionaba era relativamente sencillo: instalabas un agente, definías umbrales de CPU, memoria y disco, y esperabas a que saltara una alerta. Eso es monitorización, y sigue siendo imprescindible. Pero cuando una aplicación deja de ser un único proceso en un único servidor y se convierte en decenas de microservicios repartidos por un clúster de Kubernetes, esas alertas empiezan a decir "algo va mal" sin decir "dónde ni por qué".
Ahí es donde entra la observabilidad. No es un sinónimo de moda para monitorización, ni una herramienta nueva que sustituya a la anterior: es su evolución natural. La monitorización te dice que el sistema está roto; la observabilidad te da los datos para entender por qué lo está, incluso ante fallos que nunca anticipaste. Este artículo parte de donde termina la monitorización 24/7 clásica y explica sus tres pilares, cómo se correlacionan y cuándo merece la pena dar el salto.
De la Monitorización a la Observabilidad
La diferencia esencial se resume en una sola distinción: known-unknowns frente a unknown-unknowns. La monitorización se construye alrededor de fallos que ya conoces y anticipas: sabes que el disco se puede llenar, que la CPU se puede saturar o que un servicio puede dejar de responder, así que defines métricas y alertas para esos casos concretos. Es un enfoque de dashboards de estado que responde muy bien a la pregunta "¿está roto?".
El problema aparece con los fallos que no anticipaste. En un sistema distribuido, una latencia elevada en el checkout puede deberse a un servicio de terceros lento, a un pool de conexiones agotado tres saltos más abajo, a un reintento en cascada o a un nodo concreto del clúster con el disco degradado. Ninguna alerta predefinida cubre esa combinación exacta, porque nunca la habías visto. La observabilidad responde a "¿por qué está roto?": en lugar de comprobar hipótesis fijas, te permite formular preguntas nuevas sobre el comportamiento del sistema a partir de los datos que ya emite.
Dicho de otro modo, la monitorización es un conjunto finito de preguntas con respuesta predefinida; la observabilidad es la capacidad de hacer preguntas que no habías previsto sin tener que desplegar código nuevo. Y esa capacidad se construye sobre tres tipos de datos de telemetría que se complementan entre sí.
Los Tres Pilares: Métricas, Logs y Trazas
La observabilidad se apoya en tres señales, cada una con sus fortalezas y su coste. No compiten: se usan juntas. Entender qué responde cada una es la clave para diseñar una estrategia que no se vuelva ni ciega ni ruinosamente cara.
1. Métricas. Son valores numéricos agregados a lo largo del tiempo: peticiones por segundo, latencia p99, uso de memoria, tasa de errores. Al ser series temporales, son baratas de almacenar y consultar, agregables y perfectas para alertar y para dashboards de tendencia. Su límite es que carecen de contexto individual: te dicen que la tasa de error subió al 5%, pero no qué peticiones concretas fallaron ni por qué. La herramienta de referencia es Prometheus, con Grafana como capa de visualización.
2. Logs. Son eventos discretos con contexto: cada línea registra qué ocurrió, cuándo y con qué detalle (mensaje de error, ID de usuario, stack trace). Son insustituibles para el diagnóstico fino, pero caros de almacenar y de indexar a escala: un sistema con mucho tráfico genera terabytes de logs al día. Las plataformas típicas son Loki (más económico, indexa solo etiquetas) y el stack ELK / Elasticsearch (indexación completa, más potente en búsqueda pero más costoso).
3. Trazas distribuidas. Son el pilar que la monitorización clásica no tiene. Una traza reconstruye el viaje completo de una petición a medida que atraviesa todos los microservicios que la atienden. Cada tramo del recorrido es un span, con su duración y sus metadatos, y el conjunto se enlaza mediante un identificador común. Así puedes ver, para una petición lenta concreta, en qué servicio se fue el tiempo: si el 90% de la latencia estuvo en una consulta a base de datos o en una llamada a un servicio externo. Las herramientas de referencia son Jaeger y Grafana Tempo.
| Criterio | Métricas | Logs | Trazas |
|---|---|---|---|
| ¿Qué responde? | ¿Qué está pasando y cuánto? | ¿Qué ocurrió exactamente? | ¿Dónde se fue el tiempo? |
| Tipo de dato | Serie temporal agregada | Evento discreto con contexto | Recorrido de petición (spans) |
| Coste de almacenamiento | Bajo | Alto | Medio (con sampling) |
| Riesgo de cardinalidad | Alto | Medio | Bajo |
| Mejor para | Alertar y tendencias | Diagnóstico fino | Latencia en sistemas distribuidos |
| Herramienta típica | Prometheus | Loki / ELK | Jaeger / Tempo |
Correlación: del Síntoma a la Causa Raíz
El valor de la observabilidad no está en cada pilar por separado, sino en poder saltar de uno a otro sin fricción. Un pilar aislado es una isla; los tres correlacionados forman un mapa. El flujo de investigación ideal ante un incidente sigue casi siempre el mismo camino:
- arrow_right Empiezas por la métrica: una alerta indica que la latencia p99 del servicio de pagos se ha disparado. Sabes qué pasa y cuánto, pero no por qué.
- arrow_right Saltas a la traza: filtras las peticiones lentas del periodo afectado y examinas sus spans. Descubres que casi todo el tiempo se pierde en una llamada a un servicio de inventario.
- arrow_right Aterrizas en el log: desde ese span concreto abres los logs correlacionados de ese servicio en ese instante y encuentras la causa exacta: timeouts contra la base de datos por un pool de conexiones agotado.
Ese recorrido —de la métrica a la traza y de la traza al log— es lo que reduce el MTTR (tiempo medio de resolución) de horas a minutos. Para que funcione, las tres señales deben compartir contexto: los mismos identificadores de traza y las mismas etiquetas de servicio propagados a lo largo de todo el sistema. Y aquí es donde entra el estándar que lo hace posible.
OpenTelemetry: Instrumentación Unificada y sin Lock-in
Históricamente, cada proveedor de observabilidad tenía su propio agente y su propio SDK. Instrumentar tu código para uno significaba quedar atado a él: cambiar de herramienta implicaba reinstrumentar toda la aplicación. OpenTelemetry (OTel) resuelve exactamente eso: es un estándar abierto y neutral respecto al proveedor para generar métricas, logs y trazas.
La idea es sencilla y potente: instrumentas una sola vez con las librerías de OTel, y decides después a qué backend envías los datos. Puedes mandar tus métricas a Prometheus, tus trazas a Tempo y tus logs a Loki; o migrar mañana a una plataforma comercial sin tocar el código de tu aplicación. El OpenTelemetry Collector actúa como pieza central que recibe, procesa y reexporta la telemetría hacia uno o varios destinos.
Para una empresa, esto es sobre todo una decisión estratégica: evitar el vendor lock-in. La telemetría es un activo que no debería depender del proveedor de turno. Adoptar OTel como capa de instrumentación te da libertad para elegir —y cambiar— de backend según el coste, las prestaciones o las necesidades del proyecto, sin rehacer el trabajo de instrumentación.
Cardinalidad, Coste y Retención por Capas
La observabilidad tiene un enemigo silencioso que puede disparar la factura: la cardinalidad. Se refiere al número de combinaciones únicas de etiquetas que genera una métrica. Añadir una etiqueta con pocos valores (por ejemplo, el método HTTP) es inofensivo. Añadir una etiqueta de alta cardinalidad —ID de usuario, ID de sesión, URL completa con parámetros— multiplica el número de series temporales por millones y puede tumbar un Prometheus o hacer inviable el coste de almacenamiento.
Regla práctica sobre etiquetas:
Los datos de alta cardinalidad (ID de usuario, petición o sesión) van en logs y trazas, no en etiquetas de métricas. Las métricas deben etiquetarse solo con dimensiones de baja cardinalidad (servicio, endpoint, código de estado). Confundir esto es la causa número uno de facturas de observabilidad descontroladas.
Con las trazas, el control de coste se llama sampling (muestreo). Almacenar el 100% de las trazas de un sistema de alto tráfico es caro e innecesario: basta con quedarse con una fracción representativa, o mejor aún, con un tail sampling que conserve siempre las trazas de peticiones lentas o con errores y descarte la mayoría de las que fueron rápidas y correctas. Así retienes lo que importa para diagnosticar sin pagar por el ruido.
Por último, la retención por capas equilibra utilidad y presupuesto: mantén los datos recientes en almacenamiento rápido y detallado (días o semanas), degrada progresivamente a resoluciones agregadas para el medio plazo y archiva en almacenamiento barato tipo objeto para el largo plazo. No todos los datos de telemetría merecen el mismo coste ni la misma velocidad de acceso.
SLI, SLO y Error Budgets: el Marco de Fiabilidad
La observabilidad no es un fin en sí misma: existe para sostener objetivos de fiabilidad medibles. El marco que popularizó la práctica de SRE se apoya en tres conceptos encadenados. Un SLI (Service Level Indicator) es una métrica concreta de la experiencia del usuario: por ejemplo, el porcentaje de peticiones servidas correctamente por debajo de 300 ms. Un SLO (Service Level Objective) es el objetivo que te fijas sobre ese indicador: por ejemplo, cumplirlo el 99,9% del tiempo.
La consecuencia directa del SLO es el error budget (presupuesto de error): si tu objetivo es el 99,9%, tienes un 0,1% de fallo "permitido" en el periodo. Ese presupuesto es una herramienta de decisión: mientras te quede margen, puedes desplegar y experimentar; si lo agotas, congelas cambios y priorizas estabilidad. Este marco convierte la fiabilidad en algo negociable y cuantificable, en lugar de una aspiración vaga al "100% siempre". Para entender cómo se traduce esto en un compromiso contractual, revisa nuestro artículo sobre el SLA del 99,99% explicado y cuánto downtime representa realmente cada nivel de disponibilidad.
¿Cuándo Basta con Monitorizar y Cuándo Necesitas Observabilidad?
Adoptar observabilidad completa cuesta esfuerzo y dinero, así que la pregunta importante no es "¿la quiero?" sino "¿la necesito?". La respuesta depende de la arquitectura del sistema, no del tamaño de la empresa.
Basta con monitorización simple cuando tienes un monolito o unos pocos servidores con responsabilidades claras. Si una petición se atiende dentro de un único proceso, cuando algo va mal el espacio de búsqueda es pequeño: los logs de esa aplicación y las métricas del sistema suelen bastar. Añadir trazas distribuidas y toda la maquinaria de OTel sería sobreingeniería.
Necesitas observabilidad cuando el sistema es distribuido: microservicios, Kubernetes, colas de mensajes, múltiples bases de datos y llamadas entre servicios. En ese escenario, una sola petición puede tocar diez componentes distintos, y localizar dónde falla algo sin trazas es como buscar a oscuras. Cuantos más saltos de red haya entre el usuario y la respuesta, más justificada está la inversión.
- check_circle Señal de que necesitas observabilidad: dedicas más tiempo a localizar en qué servicio ocurre un problema que a arreglarlo.
- check_circle Otra señal: los incidentes reproducen combinaciones de fallos que nadie había previsto y las alertas existentes no los explican.
- check_circle Enfoque recomendado: empieza por una base sólida de monitorización y métricas, y añade trazas y correlación conforme la complejidad distribuida lo justifique.
EasyDataHost: Monitorización Gestionada como Base
La observabilidad se construye sobre unos cimientos sólidos, y esos cimientos son una monitorización bien hecha. En EasyDataHost ofrecemos monitorización gestionada (Monitoring as a Service) como capa base sobre la que tu equipo puede desarrollar una estrategia de observabilidad completa:
- arrow_right Recogida y retención de métricas de infraestructura (Prometheus y compatibles) con dashboards, umbrales y alertas gestionadas por nuestro equipo.
- arrow_right Agregación y retención de logs con la política por capas adecuada a tu volumen, evitando sorpresas de coste a escala.
- arrow_right Infraestructura preparada para OpenTelemetry, de modo que puedas instrumentar tus aplicaciones sin atarte a un proveedor concreto.
- arrow_right Integración con nuestros servicios gestionados, con soporte 24/7 y respuesta ante incidentes desde datacenter propio en España.
Nuestra infraestructura opera con certificación ISO 27001 y conformidad ENS. Si quieres pasar de "solo monitorizar" a entender de verdad por qué se comporta como se comporta tu plataforma, habla con nuestro equipo para diseñar la estrategia adecuada a tu arquitectura.
Preguntas Frecuentes
¿Cuál es la diferencia entre monitorización y observabilidad?
La monitorización responde a "¿está roto?" mediante métricas y alertas definidas de antemano sobre problemas que ya anticipas (known-unknowns). La observabilidad permite responder "¿por qué está roto?" correlacionando métricas, logs y trazas para investigar fallos que nunca predijiste (unknown-unknowns), algo imprescindible en sistemas distribuidos y microservicios.
¿Necesito observabilidad si tengo un monolito y pocos servidores?
No necesariamente. Para un monolito con pocos servidores, la monitorización clásica con métricas de sistema y alertas suele ser suficiente para operar con fiabilidad. La observabilidad aporta valor real cuando una petición atraviesa muchos servicios independientes: microservicios, Kubernetes y arquitecturas distribuidas donde localizar dónde falla algo no es evidente.
¿Qué es OpenTelemetry y por qué importa?
Es el estándar abierto y neutral de instrumentación para métricas, logs y trazas. Instrumentas tu aplicación una sola vez y puedes enviar los datos a cualquier backend (Prometheus, Jaeger, Tempo, Loki u otros), lo que evita el vendor lock-in y unifica la telemetría bajo un mismo formato.
Conclusión
La observabilidad no reemplaza a la monitorización: la extiende. Pasar de "¿está roto?" a "¿por qué está roto?" es lo que diferencia operar un sistema simple de operar uno distribuido con confianza:
- arrow_right La monitorización cubre los fallos que anticipas (known-unknowns); la observabilidad te permite investigar los que no anticipaste (unknown-unknowns).
- arrow_right Sus tres pilares se complementan: métricas para alertar y ver tendencias, logs para el detalle, y trazas para saber dónde se va el tiempo en un sistema distribuido.
- arrow_right La correlación entre los tres (métrica → traza → log) y OpenTelemetry como capa de instrumentación neutral son lo que convierten datos sueltos en respuestas.
- arrow_right Controla la cardinalidad y el coste, apóyate en SLI/SLO/error budgets y adopta observabilidad cuando tu arquitectura distribuida realmente lo justifique, no antes.