Monitoring y Observability: ¿qué debería supervisar su sistema?
Una caída a las 3 de la madrugada que nadie detecta. Una degradación progresiva del rendimiento que solo reportan los clientes. O una explosión de costes en la nube que solo se ve en la siguiente factura. Un buen monitoring previene exactamente eso — pero solo si supervisa las cosas correctas.
Monitoring vs. Observability — la diferencia
El monitoring responde a la pregunta: "¿Funciona mi sistema?" Usted define umbrales — CPU por encima del 90 %, Response Time superior a 2 segundos, disco lleno — y recibe alertas cuando algo se cumple. El monitoring detecta problemas conocidos.
La Observability va un paso más allá y responde: "¿Por qué mi sistema se comporta así?" Se trata de obtener una imagen completa a partir de métricas, logs y traces — también para problemas que no ha definido previamente. La Observability ayuda con problemas desconocidos.
En la práctica necesita ambos: monitoring como sistema de alerta temprana, Observability como herramienta de diagnóstico. El monitoring le dice que el paciente tiene fiebre. La Observability le dice por qué.
Los tres pilares de la Observability
Metrics
Valores numéricos a lo largo del tiempo — el pulso de su sistema. Muestran tendencias y permiten el alerting.
- Uso de CPU y RAM
- Response Times y latencia
- Error Rates y códigos de estado HTTP
- Request Throughput
Logs
Registros textuales de eventos individuales — el diario de su sistema. Indispensable para el análisis de errores.
- Application Logs (errores, advertencias)
- Audit Logs (¿quién hizo qué y cuándo?)
- Access Logs (accesos y solicitudes)
- Infrastructure Logs (eventos del sistema)
Traces
La trayectoria de una solicitud a través de todos los servicios — el mapa de su sistema. Muestra dónde se producen los problemas.
- Distributed Tracing entre servicios
- Request Flow y dependencias
- Análisis de cuellos de botella y latencia
- Service-Dependency-Mapping
Lo mínimo que debería supervisar
No medir todo lo que es medible — sino aquello que le ayuda a detectar problemas antes de que sus clientes los perciban.
Infraestructura
- Uso de CPU — por encima del 80 % de forma sostenida indica cuellos de botella
- Uso de RAM — detectar Memory Leaks antes de que se produzcan OOM-Kills
- Uso de disco — los discos llenos son la causa de fallo evitable más frecuente
- Throughput de red y latencia entre servicios
Application Health
- Response Time — P50, P95 y P99, no solo el promedio
- Error Rate — proporción de respuestas 5xx sobre el tráfico total
- Throughput — requests por segundo, para detectar picos de carga
- Queue Depth — ¿se acumulan los jobs o se procesan a tiempo?
Business Metrics
- Conversion Rate — una caída repentina indica problemas técnicos
- Pedidos y transacciones — detectar anomalías de inmediato
- Monitorización de facturación — Revenue como indicador de salud definitivo
Seguridad y costes
- Failed Logins — detectar ataques de fuerza bruta a tiempo
- Anomalías de tráfico — patrones de acceso inusuales indican posibles ataques
- Cloud Spend — resumen diario de costes para evitar sorpresas en el presupuesto
- Uso de recursos — las instancias sobredimensionadas generan costes innecesarios
Comparativa de herramientas: ¿cuál se adapta a usted?
| Criterio | Grafana Stack | Datadog | AWS CloudWatch | ELK Stack |
|---|---|---|---|---|
| Tipo | Open Source, Self-Hosted | SaaS, All-in-One | Nativo de AWS, gestionado | Open Source, Self-Hosted |
| Costes | Bajo — solo costes de infraestructura | Alto — por host y funcionalidad, caro al escalar | Moderado — Pay-per-Use, los costes aumentan con el volumen de datos | Bajo a moderado — se necesita infraestructura para Elasticsearch |
| Esfuerzo de implementación | Medio — configurar Prometheus, Grafana y Loki individualmente | Bajo — instalar el agente y listo | Bajo — integrado nativamente en AWS | Alto — Cluster-Setup, tuning, gestión de índices |
| Escalabilidad | Buena — con Thanos/Mimir también para configuraciones grandes | Muy buena — SaaS escala automáticamente | Buena — dentro del ecosistema de AWS | Buena — pero requiere gestión de clústeres |
| Curva de aprendizaje | Medio — PromQL y los dashboards de Grafana requieren tiempo de adaptación | Bajo — interfaz intuitiva | Bajo — pero con funcionalidad limitada | Alto — las queries de Elasticsearch y Kibana son complejas |
| Punto fuerte | Flexibilidad y comunidad — adaptable a cualquier configuración | Todo en una sola plataforma — Metrics, Logs, Traces, APM | Integración fluida con AWS sin infraestructura adicional | Análisis de logs y búsqueda de texto completo — imbatible para grandes volúmenes de logs |
¿A partir de cuándo merece la pena un monitoring profesional?
El monitoring básico es suficiente cuando ...
Para configuraciones sencillas con pocos servicios, a menudo bastan Health-Checks básicos y Uptime Monitoring.
- Usted opera una única aplicación con pocos componentes
- Se pueden asumir tiempos de inactividad de algunas horas
- Sin requisitos regulatorios de disponibilidad
- Pocos usuarios y bajo tráfico
Una configuración profesional merece la pena cuando ...
En cuanto las caídas se vuelven críticas para el negocio o la arquitectura crece, necesita más que Uptime Checks.
- Varios servicios o microservicios se comunican entre sí
- Cada hora de inactividad supone una pérdida significativa de facturación
- Hay que cumplir SLAs frente a clientes o socios
- Los costes cloud se vuelven confusos y sospecha que hay potencial de optimización
Errores típicos de monitoring
Configurar el monitoring es el primer paso. Hacerlo correctamente, el más difícil. Estos errores los vemos con frecuencia.
- Alert Fatigue — demasiadas alertas que nadie toma en serio. Cada alerta debería incluir una instrucción de actuación clara.
- Cementerio de dashboards — decenas de dashboards que nunca se vuelven a mirar tras su creación. Menos es más.
- Sin runbooks — la alerta se dispara, pero nadie sabe qué hacer. Cada alerta necesita un procedimiento documentado.
- Solo infraestructura, sin métricas de negocio — los servidores funcionan, pero la conversión se ha desplomado. Sin Business Monitoring, lo detecta demasiado tarde.
- Monitoring sin contexto — una CPU al 95 % puede ser normal o un problema. Sin baseline ni contexto, las métricas carecen de valor.
- No monitorizar el propio monitoring — si Prometheus falla y nadie lo detecta, no tiene monitoring.
Nuestra conclusión honesta
El monitoring no es un proyecto con una fecha de finalización — es una práctica que crece con su sistema. Empiece a pequeña escala, con las métricas que realmente importan: ¿Es accesible la aplicación? ¿Cómo de rápido responde? ¿Se producen errores? ¿Cuadran las cifras de negocio?
El error más frecuente no es tener poco monitoring — sino demasiado del tipo equivocado. Cien dashboards que nadie mira son peores que cinco alertas bien configuradas con runbooks claros. Empiece por aquello que le permita dormir tranquilo.
En devRocks apostamos preferentemente por el Grafana Stack — no porque sea el más sencillo, sino porque ofrece la mayor flexibilidad y no conlleva riesgos de vendor lock-in. Para equipos que quieren empezar rápido, Datadog puede ser la opción más pragmática. Lo decisivo no es la herramienta — sino que empiece.
Seguir leyendo
Preguntas frecuentes
¿Cuál es la diferencia entre monitorización y observabilidad?
La monitorización le muestra QUE algo no funciona, mediante métricas y umbrales predefinidos. La observabilidad le muestra POR QUÉ algo no funciona, mediante la combinación de métricas, logs y trazas. La monitorización responde preguntas conocidas, la observabilidad ayuda con problemas desconocidos.
¿Qué herramientas son adecuadas para la observabilidad?
Las herramientas de código abierto más comunes incluyen Prometheus y Grafana para métricas, Loki o Elasticsearch para logs, y Jaeger o Tempo para trazas. Soluciones comerciales como Datadog, New Relic o Dynatrace ofrecen todo en uno. La elección depende del presupuesto, la competencia del equipo y la complejidad de la infraestructura.
¿Cuáles son los tres pilares de la observabilidad?
Los tres pilares son métricas (mediciones cuantitativas como uso de CPU o tiempos de respuesta), logs (registros textuales de eventos) y trazas (seguimiento de solicitudes individuales a través de múltiples servicios). Solo la combinación de los tres permite una verdadera observabilidad.
¿Cuándo es suficiente la monitorización simple?
Para aplicaciones monolíticas con pocos componentes, la monitorización clásica suele ser suficiente. En cuanto se operan microservicios, sistemas distribuidos o infraestructura en la nube, la observabilidad se vuelve necesaria, porque los errores surgen entre límites de servicios y no se pueden diagnosticar solo con monitorización.
¿Cuánto cuesta un stack de observabilidad?
Los stacks de código abierto (Prometheus, Grafana, Loki) son gratuitos en cuanto a licencias, pero requieren esfuerzo operativo y know-how. Las soluciones SaaS comerciales cuestan típicamente entre 500 y 5.000 €/mes según el volumen de datos y los hosts. El mayor factor de coste a menudo no es la herramienta, sino el tiempo de implementación y capacitación del equipo.
¿Busca una estrategia de monitoring?
Analizamos su configuración actual, identificamos puntos ciegos y le ayudamos a construir un monitoring que realmente funcione — sin caos de alertas ni cementerio de dashboards.
Solicitar asesoramiento gratuito