¿Qué es la observabilidad?

¿Qué es la observabilidad?

La observabilidad (observability) es cuánto puedes entender de lo que ocurre dentro de un sistema a partir de los datos que emite. OpenTelemetry lo describe como entender un sistema desde fuera, sin conocer su funcionamiento interno, de modo que puedas hacer preguntas nuevas sobre un problema sin desplegar código nuevo. En la práctica, esos datos son logs, métricas y trazas, enlazados para que puedas pasar de uno a otro.

Las tres señales: logs, métricas y trazas

• Logs: mensajes con marca de tiempo que emiten los servicios y otros componentes. Solos suelen carecer de contexto, así que resultan más útiles con un ID de traza o de span.
• Métricas: agregaciones de datos numéricos durante un periodo, como la tasa de errores o el uso de CPU. Son baratas de almacenar y rápidas de graficar, pero ocultan las peticiones individuales.
• Trazas: el camino que sigue una sola petición por tus servicios. Una traza se compone de spans, y cada span es una unidad de trabajo con nombre, tiempos y metadatos.

Cómo funciona

Instrumentas tu código, normalmente con un SDK de OpenTelemetry, para que emita estas señales. La propagación de contexto lleva un ID de traza entre servicios: por defecto OpenTelemetry usa la cabecera traceparent de W3C Trace Context, y eso permite correlacionar señales de servicios distintos. Los datos van a un backend donde los consultas.

Guardar todas las trazas es caro, por eso se hace muestreo. En el muestreo al inicio (head sampling) la decisión se toma al comenzar la traza. En el muestreo al final (tail sampling) se espera a ver casi toda la traza, así que se pueden conservar las que tienen errores o latencia alta (muestreo en OpenTelemetry).

Observabilidad frente a monitorización

• La monitorización responde preguntas definidas de antemano: ¿está el endpoint disponible?, ¿la tasa de errores está bajo el umbral?, ¿el p95 cumple el presupuesto? Alimenta paneles y alertas para fallos que puedes predecir.
• La observabilidad permite hacer preguntas imprevistas a posteriori: ¿qué clientes vieron pagos lentos y qué llamada posterior los provocó?

La monitorización te dice que algo falla. La observabilidad te ayuda a averiguar por qué. Una producción sana necesita ambas.

Ejemplo

Un monitor de API avisa de que la latencia del checkout ha superado su umbral. Un gráfico de métricas muestra el p95 subiendo en /checkout desde el último despliegue. Abres una traza lenta y ves que un solo span, la llamada al proveedor de pagos, consume casi todo el tiempo. Los logs con ese mismo ID de traza muestran timeouts repetidos. Haces rollback y el incidente queda entendido en minutos, no en horas. La alerta vino de la monitorización y el diagnóstico, de la observabilidad.

Errores comunes

• Escribir logs sin ID de traza, de modo que una línea no se puede asociar a una petición.
• Poner valores ilimitados, como IDs de usuario o de petición, como etiquetas de métricas. Cada valor nuevo crea otra serie temporal y sube el coste. Esos valores van en trazas y logs.
• Montar paneles para todo y alertas para nada, o al revés.
• Guardar todo con el máximo detalle sin presupuesto ni política de muestreo.
• Añadir instrumentación solo después de un incidente.
• Tratar la observabilidad como una herramienta que se compra y no como el hábito de instrumentar y hacer preguntas.

Observabilidad, monitorización y pruebas de carga

LoadFocus no es una plataforma de observabilidad. Cubre la vista externa: la monitorización de APIs lanza comprobaciones contra tus endpoints desde varias regiones, valida código de estado, cuerpo, cabeceras y tiempo de respuesta, y avisa por canales como Slack, Microsoft Teams, PagerDuty y webhooks. Las comprobaciones gratuitas se ejecutan cada 5 minutos. Eso es monitorización sintética: dice que algo falla y dónde. Tus propias trazas y logs dicen por qué.

Ambas se ayudan también en las pruebas de carga. Ejecuta una prueba contra un entorno de staging instrumentado y tus paneles habituales mostrarán qué endpoint se ralentizó primero y qué consulta agotó el tiempo. Fíjate en los percentiles: consulta latencia. Las ejecuciones largas se tratan en nuestra guía de soak testing. Sobre herramientas y práctica, lee herramientas de monitorización del rendimiento de aplicaciones y buenas prácticas de monitorización. Si llega un incidente, consulta respuesta a incidentes.

Preguntas frecuentes

¿Cuáles son los tres pilares de la observabilidad?

Logs, métricas y trazas. Los logs registran eventos, las métricas agregan números en el tiempo y las trazas siguen una petición a través de varios servicios. OpenTelemetry los llama señales.

¿En qué se diferencian observabilidad y monitorización?

La monitorización comprueba condiciones definidas de antemano y avisa. La observabilidad ofrece datos suficientes para investigar problemas que nadie esperaba. Normalmente se necesitan las dos.

¿Necesito OpenTelemetry para tener observabilidad?

No, pero es una forma neutral respecto a proveedores de instrumentar el código y exportar logs, métricas y trazas al backend que elijas, y por eso muchos equipos empiezan por ahí.

¿Es LoadFocus una herramienta de observabilidad?

No. LoadFocus ofrece monitorización de APIs, pruebas de carga y monitorización de velocidad de página, que muestran cómo se comporta tu sistema desde fuera. No sustituye al tracing ni al análisis de logs dentro de tus servicios.

¿Por qué se muestrean las trazas?

Guardar todas las trazas cuesta mucho. OpenTelemetry describe el muestreo como una de las formas más eficaces de reducir el coste de la observabilidad sin perder visibilidad.