Monitoreo y observabilidad: APM, mejores prácticas de registro y alertas

Las empresas con prácticas de observabilidad maduras resuelven incidentes un 69 % más rápido según el informe Estado de observabilidad de Splunk. El monitoreo le indica que algo no funciona. La observabilidad te dice por qué está roto y dónde buscar. La diferencia entre combatir cada problema de producción durante horas y resolverlos en minutos se reduce a qué tan bien instrumenta sus sistemas, estructura sus registros y diseña sus alertas.

Conclusiones clave

• Los tres pilares de la observabilidad (métricas, registros y seguimientos) responden a diferentes preguntas y trabajan juntos para proporcionar una comprensión completa del sistema.
• Alerta sobre los síntomas (impacto de cara al usuario), no sobre las causas (métricas internas), para reducir la fatiga de las alertas y detectar nuevos modos de falla.
• El registro JSON estructurado con ID de correlación permite buscar entre servicios y reconstruir flujos de solicitudes
• Los SLO (objetivos de nivel de servicio) transforman el monitoreo de "hay algo roto" a "cumplimos con nuestros compromisos con los usuarios"

---

Los tres pilares de la observabilidad

La observabilidad se basa en tres tipos de datos complementarios. Cada pilar responde diferentes preguntas sobre el comportamiento de su sistema.

Métricas

Las métricas son medidas numéricas recopiladas a intervalos regulares. Responden preguntas de "qué está pasando": ¿Cuántas solicitudes por segundo? ¿Cuál es el tiempo promedio de respuesta? ¿Cuánta memoria hay en uso?

Características:

• Agregado y compacto: millones de eventos comprimidos en contadores de series temporales
• Barato de almacenar: datos de tamaño fijo independientemente del volumen de tráfico
• Ideal para paneles y alertas.
• Contexto limitado: sabes que el tiempo de respuesta aumentó, pero no sabes qué solicitudes específicas son lentas.

Tipos de métricas clave:

• Contador: valor que aumenta monótonamente (solicitudes totales, errores totales)
• Gauge: valor que sube y baja (uso actual de CPU, conexiones activas)
• Histograma: distribución de valores (percentiles de tiempo de respuesta, tamaños de carga útil)
• Resumen: percentiles precalculados en el lado del cliente

Registros

Los registros son registros de texto con marca de tiempo de eventos discretos. Responden preguntas de "qué pasó": ¿Qué mensaje de error vio el usuario? ¿Qué parámetros se pasaron a la función fallida? ¿Cuál era el estado del sistema cuando ocurrió el problema?

Características:

• Contexto rico: detalles arbitrarios sobre eventos individuales
• Caro a escala: los sistemas de alto tráfico generan gigabytes de registros por hora
• Posibilidad de búsqueda: encuentre eventos específicos con búsqueda de texto completo
• Requiere estructura: las líneas de registro no estructuradas son difíciles de analizar y correlacionar

Rastros

Los seguimientos siguen una única solicitud en múltiples servicios. Responden a las preguntas de "¿dónde se gasta el tiempo?": ¿Qué llamada de servicio es lenta? ¿Dónde diverge la ruta de la solicitud? ¿Qué consulta de base de datos es el cuello de botella?

Características:

• Mostrar causalidad: relaciones padre-hijo entre operaciones.
• Revelar el comportamiento del sistema distribuido: latencia a través de los límites del servicio.
• Se requiere muestreo a escala: rastrear cada solicitud es costoso
• Esencial para microservicios: sin rastros, la depuración de flujos de servicios múltiples es una conjetura

---

Ecosistema de herramientas de observabilidad

Elegir una pila

Para la mayoría de las empresas en crecimiento, recomendamos comenzar con:

1. Sentry para seguimiento de errores: detecta excepciones con seguimientos completos de la pila, mapas de origen y seguimiento de versiones.
2. Prometheus + Grafana para métricas: código abierto, ecosistema de integración extenso y probado en batalla
3. Registro estructurado en un servicio administrado: Datadog Logs, AWS CloudWatch o Grafana Loki, según su proveedor de nube.
4. OpenTelemetry para instrumentación: estándar neutral del proveedor que funciona con cualquier backend

Para los equipos que desean un único proveedor, Datadog ofrece la mejor experiencia todo en uno, pero a un costo significativo a escala. La pila de código abierto de Grafana (Prometheus, Loki, Tempo) proporciona capacidades equivalentes con un menor costo de licencia pero una mayor carga operativa.

---

Mejores prácticas de registro estructurado

Las líneas de registro no estructuradas como Error processing order 12345 for user [email protected] son legibles por humanos pero hostiles a las máquinas. Los registros JSON estructurados permiten buscar, filtrar, agregar y alertar sobre campos específicos.

Estructura de registro

Cada entrada del registro debe incluir:

ID de correlación

Un ID de correlación es un identificador único generado al inicio de cada solicitud y pasado a cada llamada de servicio posterior, consulta de base de datos y trabajo en segundo plano. Al investigar un problema, la búsqueda por ID de correlación muestra cada entrada de registro relacionada con esa solicitud específica en todos los servicios.

Implementación: Genere un UUID en la puerta de enlace API o el equilibrador de carga, páselo en el encabezado X-Request-ID e inclúyalo en cada entrada del registro. En NestJS, utilice un middleware que extraiga o genere el ID de correlación y lo almacene en el contexto de almacenamiento local asíncrono.

Niveles de registro

Utilice niveles de registro de forma coherente:

• DEBUG: información de diagnóstico detallada, deshabilitada en producción a menos que se realice una depuración activa
• INFO -- eventos comerciales importantes (pedido realizado, usuario registrado, pago procesado)
• ADVERTENCIA: situaciones inesperadas que el sistema manejó pero que deben investigarse (reintento exitoso, error de caché, llamada API obsoleta)
• ERROR: fallas que afectaron la experiencia del usuario (solicitud fallida, pago rechazado, servicio externo no disponible)
• FATAL: la aplicación no puede continuar (base de datos inalcanzable, falta la configuración requerida)

Retención de registros y gestión de costos

Los registros son los datos de observabilidad más caros de almacenar. Implementar retención por niveles:

• Almacenamiento activo (30 días): búsqueda de texto completo, consultas rápidas, alto costo
• Almacenamiento en caliente (90 días): comprimido, consultas más lentas, costo moderado
• Almacenamiento en frío (más de 1 año): archivado, consulta bajo demanda, bajo costo
• Registros de depuración: no los almacene en producción a menos que se solucionen problemas activamente

---

Diseño de alerta

Las malas alertas crean fatiga en las alertas: los equipos dejan de responder a las alertas porque la mayoría son falsos positivos o ruido de baja prioridad. Una buena alerta pone de manifiesto problemas genuinos que requieren intervención humana.

Alerta sobre síntomas, no causas

Alerta basada en síntomas (buena): "La tasa de error en /api/orders superó el 1 % durante 5 minutos": esto indica directamente el impacto en el usuario, independientemente de la causa subyacente.

Alerta basada en causa (incorrecta): "La CPU de la base de datos excedió el 90%": esto puede afectar o no a los usuarios. La base de datos podría manejar bien el 95% de la CPU, o podría estar al 50% de la CPU pero completamente bloqueada.

Las métricas basadas en causas pertenecen a los paneles de investigación, no a las reglas de alerta.

Niveles de gravedad de las alertas

Reducción del ruido de alerta

1. Alertas relacionadas con el grupo: si la base de datos deja de funcionar, recibirá una alerta de "base de datos no disponible", no 50 alertas de cada servicio que depende de ella.
2. Requiere infracción sostenida: "CPU por encima del 90 % durante 5 minutos", no "CPU por encima del 90 % durante 1 segundo" para evitar picos transitorios
3. Resolución automática: las alertas deberían borrarse automáticamente cuando se resuelva la condición.
4. Revisión de alertas semanales: revise todas las alertas que se activaron, identifique y corrija o silencie aquellas que no requirieron acción humana.
5. Ciclo de retroalimentación de guardia: después de cada rotación de guardia, el ingeniero documenta qué alertas fueron procesables y cuáles necesitan ajuste.

---

SLO: objetivos de nivel de servicio

Los SLO transforman el monitoreo de reactivo ("algo se rompió, arréglalo") a proactivo ("estamos consumiendo nuestro presupuesto de errores, investiguemos antes de que los usuarios se den cuenta").

Definición de SLO

Un SLO define la confiabilidad objetivo de un servicio. Consta de:

• SLI (indicador de nivel de servicio): la métrica que se está midiendo (tasa de éxito de la solicitud, percentil de latencia)
• Objetivo: el umbral que define el rendimiento aceptable (tasa de éxito del 99,9 %, P95 por debajo de 200 ms)
• Ventana: el período de tiempo durante el cual se evalúa el objetivo (30 días consecutivos)

Ejemplos de SLO para una plataforma de comercio electrónico

Error en presupuestos

El presupuesto de error es el inverso de su objetivo de SLO. Un SLO del 99,9 % permite errores del 0,1 %: aproximadamente 43 minutos de tiempo de inactividad por mes. Cuando se agota el presupuesto de errores, el equipo cambia el enfoque de las funciones al trabajo de confiabilidad.

Los presupuestos de errores proporcionan un lenguaje compartido entre los equipos de ingeniería y de producto. En lugar de debatir si un servicio es "suficientemente confiable", ambos equipos pueden ver exactamente cuánto error queda y tomar decisiones basadas en datos sobre el envío de nuevas funciones versus la inversión en estabilidad.

---

Preguntas frecuentes

¿Cuánto cuesta la observabilidad a escala?

Los costos de observabilidad oscilan entre $10 y $50 por host por mes para pilas de código abierto (Prometheus, Grafana, Loki) y $30-100+ por host para soluciones comerciales (Datadog, New Relic). El mayor factor de costo es el volumen de registros: optimice tomando muestras de los registros de depuración, comprimiendo los registros almacenados y estableciendo períodos de retención adecuados. Para la mayoría de las empresas con menos de 50 servidores, el coste es de entre 500 y 2000 dólares al mes.

¿Debo utilizar OpenTelemetry o agentes específicos del proveedor?

Utilice OpenTelemetry. Es el estándar de la industria para instrumentación, respaldado por todos los principales proveedores de observabilidad y evita la dependencia de proveedores. Puede cambiar de backend (de Datadog a Grafana, por ejemplo) sin volver a instrumentar su código. Los agentes de proveedores específicos a veces ofrecen una integración más profunda, pero el compromiso de portabilidad no vale la pena.

¿Cómo configuro el monitoreo para una aplicación NestJS?

En NestJS, utilice interceptores para cronometrar las solicitudes, filtros de excepciones para el seguimiento de errores y middleware para la propagación de ID de correlación. Integre Sentry con @sentry/nestjs para seguimiento de errores. Exporte métricas de Prometheus con la biblioteca prom-client expuesta en un punto final /metrics. Utilice el registro estructurado con nestjs-pino o winston configurado para salida JSON.

¿Cuál es la diferencia entre monitoreo y observabilidad?

La supervisión le avisa cuando algo predefinido sale mal (CPU alta, tasa de errores elevada, disco lleno). La observabilidad le permite plantear nuevas preguntas sobre el comportamiento del sistema sin implementar nueva instrumentación. Un sistema es observable cuando se puede comprender su estado interno a partir de sus resultados externos (métricas, registros, seguimientos). En la práctica, un buen seguimiento es un subconjunto de la observabilidad.

¿Cómo convenzo a mi equipo de invertir en observabilidad?

Realice un seguimiento del tiempo medio de resolución (MTTR) para incidentes de producción antes y después de las mejoras de observabilidad. Los equipos con buena observabilidad suelen reducir el MTTR entre un 60 y un 70 %. Multiplique el tiempo ahorrado por el costo de ingeniería para mostrar el retorno de la inversión. Realice también un seguimiento del número de incidentes detectados mediante la supervisión frente a los informes de los usuarios: la detección proactiva genera confianza en el cliente.

---

¿Qué sigue?

Comience con el seguimiento de errores (Sentry) si no tiene nada: proporciona el valor más inmediato al detectar y alertar sobre errores de producción. A continuación, agregue registros estructurados con ID de correlación. Luego implemente la recopilación de métricas con los paneles de Prometheus y Grafana. Finalmente, agregue seguimiento distribuido cuando tenga múltiples servicios.

Para conocer el contexto completo de ingeniería de rendimiento, consulte nuestra guía fundamental sobre ampliar su plataforma empresarial. Para optimizar la infraestructura que supervisa su monitoreo, lea nuestra guía de escalamiento de infraestructura.

ECOSIRE implementa pilas de observabilidad para plataformas comerciales que se ejecutan en Odoo ERP y arquitecturas personalizadas. Comuníquese con nuestro equipo de DevOps para obtener una evaluación de monitoreo y observabilidad.

---

Publicado por ECOSIRE: ayuda a las empresas a escalar con soluciones impulsadas por IA en Odoo ERP, Shopify eCommerce y OpenClaw AI.