3 min de lectura
Lo esencial en resumen
- La observabilidad va más allá del monitorizado: no solo detectar problemas conocidos, sino comprender los desconocidos.
- Los tres tipos de señales —métricas, registros (logs) y trazas— forman conjuntamente la tríada de la observabilidad.
- OpenTelemetry es el estándar neutral frente a fabricantes para la recopilación de datos de telemetría.
- El seguimiento distribuido (Distributed Tracing) visualiza las rutas de las peticiones a través de microservicios.
- Los costes de las plataformas de observabilidad pueden alcanzar entre el 5 % y el 15 % de los costes de infraestructura en la nube.
El monitorizado responde a la pregunta: ¿Funciona mi sistema? La observabilidad responde a la pregunta: ¿Por qué no funciona? En sistemas en la nube distribuidos con cientos de microservicios, el monitorizado clásico ya no es suficiente. La observabilidad —la combinación de métricas, registros y trazas— hace que los sistemas complejos sean depurables.
Del monitorizado a la observabilidad
El monitorizado clásico comprueba estados conocidos: uso de CPU, consumo de memoria, códigos de estado HTTP. Los paneles muestran verde o rojo. Esto funciona para aplicaciones monolíticas con modos de fallo predecibles.
En arquitecturas de microservicios, este enfoque falla: una llamada API lenta puede deberse a un servicio sobrecargado situado a tres saltos de distancia. Los paneles de CPU muestran verde en todos los servicios —el problema está en la interacción. La observabilidad permite formular al sistema preguntas arbitrarias sin haberlas definido previamente.
La tríada de la observabilidad: métricas, registros, trazas
Las métricas son series temporales numéricas: tasa de peticiones, latencia (p50, p95, p99), tasa de errores, profundidad de cola. Prometheus se ha consolidado como estándar de facto, complementado por Grafana para la visualización. Las métricas responden a: ¿Qué está ocurriendo ahora?
Los registros (logs) son entradas de texto con contexto: mensajes de error, registros de auditoría, información de depuración. El registro estructurado (JSON en lugar de texto libre) hace que los logs sean analizables por máquina. ELK Stack (Elasticsearch, Logstash, Kibana), Loki y Datadog Logs son plataformas habituales. Los registros responden a: ¿Qué ha ocurrido?
Las trazas siguen una petición a través de todos los servicios implicados. Cada salto se documenta como un tramo (span), con información de tiempo, nombre del servicio y metadatos. Jaeger, Zipkin y Datadog APM visualizan las cascadas de trazas. Las trazas responden a: ¿Dónde está el problema?
OpenTelemetry: el estándar universal
Antes de que existiera OpenTelemetry, cada herramienta de observabilidad suponía una dependencia de un proveedor específico: agente de Datadog, agente de New Relic, OneAgent de Dynatrace —todos con instrumentación propietaria. Cambiar de proveedor requería volver a instrumentar todo el código.
OpenTelemetry (OTel) resuelve este problema como estándar independiente de proveedores. La aplicación se instrumenta una vez con los SDK de OTel y puede enviar datos de telemetría a cualquier backend compatible —Grafana Cloud, Datadog, Honeycomb, Jaeger—. El recolector (collector) de OTel recibe, procesa y exporta los datos con flexibilidad.
OTel es un proyecto de la CNCF con el respaldo de todos los grandes proveedores de observabilidad. La recomendación es clara: toda nueva instrumentación debe hacerse siempre con OpenTelemetry, nunca con agentes propietarios.
Mantener los costes bajo control
Los costes de la observabilidad pueden dispararse. Facturas de Datadog de más de 50.000 euros al mes no son infrecuentes en empresas de tamaño medio. Los factores principales: cada entrada de log, cada métrica y cada traza conlleva costes de ingesta y almacenamiento.
Estrategias para optimizar costes: Muestreo (Sampling) – no rastrear cada petición, sino hacerlo de forma inteligente (el muestreo basado en cola, Tail-Based Sampling, rastrea solo las peticiones inusuales). Gestión del nivel de logs – logs de depuración solo en desarrollo, nivel informativo en producción. Políticas de retención – mover los logs y trazas a almacenamiento frío o eliminarlos tras 30 días.
Las soluciones basadas en código abierto (Prometheus + Grafana + Loki + Tempo) eliminan los costes de licencia, pero requieren más esfuerzo operativo. El equilibrio: SaaS (más caro, menos trabajo) frente a autohospedaje (más económico, más carga operativa).
Alertas: lo correcto en el momento adecuado
Demasiadas alertas son peores que ninguna: la fatiga por alertas hace que se pasen por alto las alertas críticas. La mejor práctica consiste en basar las alertas en los SLO (objetivos de nivel de servicio), no en métricas individuales.
En lugar de generar una alerta cuando «la CPU > 80%» (algo a menudo inofensivo), se define: «el 99 % de las peticiones deben responderse en menos de 200 ms». Cuando se agota el presupuesto de errores, el sistema emite una alerta, independientemente de si la causa es la CPU, la memoria o un servicio externo. Herramientas como Sloth y Pyrra automatizan el alertado basado en SLO utilizando Prometheus.
Preguntas frecuentes
¿Cuánto cuesta una plataforma de observabilidad?
Las soluciones SaaS (Datadog, New Relic, Dynatrace) suelen costar entre el 5 % y el 15 % de los costes de infraestructura en la nube. Con un gasto mensual en cloud de 100.000 €, esto supondría entre 5.000 y 15.000 € al mes. Las soluciones basadas en código abierto (Prometheus + Grafana + Loki) eliminan los costes de licencia, pero requieren entre 0,5 y 1 FTE para su operación.
¿Está OpenTelemetry listo para producción?
Sí. Las trazas y métricas son estables (GA) desde 2023. Los logs alcanzaron el estado GA en 2024. Todos los principales proveedores de observabilidad apoyan OTel. La recomendación: iniciar siempre nuevos proyectos con OTel. Migrar la instrumentación existente de forma progresiva.
¿Cuánto se debería rastrear?
No todo. El muestreo basado en cola (Tail-Based Sampling) rastrea solo las peticiones inusuales: alta latencia, errores, caminos poco frecuentes. Esto reduce el volumen de datos en un 90-99 % con una pérdida mínima de información. El muestreo basado en cabecera (por ejemplo, el 10 % de todas las peticiones) es más sencillo, pero menos inteligente.
¿Cuál es la mejor plataforma de observabilidad?
Depende del contexto. Datadog ofrece la mejor experiencia todo en uno, pero es caro. Grafana Cloud es más económico y compatible con código abierto. Honeycomb es ideal para la exploración basada en consultas. Para equipos pequeños: la capa gratuita de Grafana Cloud o una solución autohospedada con Prometheus + Grafana.
¿Se necesita observabilidad para monolitos?
Sí, aunque es menos urgente que en microservicios. Para monolitos, a menudo bastan métricas y logs. Las trazas cobran relevancia cuando el monolito invoca servicios externos (base de datos, APIs, colas de mensajes). Empezar con Prometheus + Grafana es una opción razonable para cualquier pila tecnológica.
Fuente de la imagen principal: Pexels / AS Photography
Sugerencias de lectura de la redacción
- Lenovo ThinkCentre M75q Tiny Gen 5: PC mini empresarial con AMD PRO y 5 vatios en reposo para entornos Edge y kioscos
- La IA sin servidor está sobrevalorada: esto es lo que realmente importa
- QNAP TS-464: NAS de 4 bahías con Docker, HDMI y ranura PCIe: lo que Synology no ofrece en esta categoría
Más del network de medios MBF
SecurityToday | MyBusinessFuture | Digital Chiefs
