El servidor de producción lleva dos horas respondiendo lento. El equipo lo sabe porque empezaron a llegar quejas de clientes. La monitorización registra que la CPU está al 95%, pero no explica por qué. Alguien pasa dos horas revisando logs manualmente hasta encontrar que una consulta a la base de datos empezó a tardar diez veces más desde las 14:32, justo después de un despliegue.
Eso es lo que ocurre cuando tiene monitorización pero no observabilidad. Y es mucho más común de lo que parece en empresas medianas con infraestructura propia o en la nube.
La diferencia que importa
Monitorización
Le dice qué está pasando: métricas de uso de CPU, memoria, disco, disponibilidad de servicios. Le alerta cuando un valor supera un umbral predefinido. Responde a preguntas conocidas: ¿está el servidor caído? ¿Queda espacio en disco?
Observabilidad
Le permite entender por qué está pasando: correlaciona métricas, logs y trazas para responder preguntas que no anticipó. Cuando algo falla de una manera nueva, la observabilidad es lo que permite diagnosticarlo sin adivinar.
Una analogía útil: la monitorización es el panel de instrumentos del coche que le muestra la temperatura del motor y le avisa si supera los 90°. La observabilidad es el sistema de diagnóstico del taller que, cuando la temperatura sube, puede decirle exactamente qué sensor está fallando, desde cuándo y qué condiciones lo provocaron.
Resumen práctico: la monitorización detecta que algo va mal. La observabilidad le permite entender qué, por qué y desde cuándo, sin necesidad de intervención manual para correlacionar información.
Los tres pilares de la observabilidad
Métricas
Valores numéricos a lo largo del tiempo: CPU, memoria, latencia, tasa de errores, peticiones por segundo. Son la base de la monitorización clásica.
Logs
Registros de eventos con marca de tiempo. Cada acción del sistema, cada error, cada petición queda registrada. Son el historial forense de lo que ocurrió.
Trazas
Seguimiento de una petición a lo largo de todos los sistemas que atraviesa. Permiten ver dónde se introduce latencia en flujos distribuidos o con múltiples servicios.
La clave no está en tener cada pilar por separado, sino en poder correlacionarlos: cuando llega una alerta de latencia alta, poder ir directamente del gráfico de métricas a los logs del momento exacto, y de ahí a la traza de la petición que falló. Sin esa correlación, el diagnóstico es siempre manual y lento.
¿Por qué esto es relevante para una PYME?
La observabilidad suele asociarse con grandes empresas con decenas de microservicios y equipos de SRE dedicados. Pero hay escenarios muy comunes en PYMEs donde la falta de visibilidad tiene un coste real:
La tasa de conversión cae un 30% durante el fin de semana. Sin observabilidad, nadie lo detecta hasta el lunes. Con logs y métricas correlacionadas, una alerta habría avisado en minutos de que el tiempo de carga del checkout había aumentado por encima del umbral de abandono.
Un proceso de sincronización entre el ERP y el almacén empieza a fallar silenciosamente. Los pedidos parecen procesarse pero el stock no se actualiza. Sin logs centralizados, el problema se detecta días después cuando el almacén envía un pedido ya agotado.
Un disco está llenándose de logs de error a un ritmo inusual. Sin monitorización de espacio en disco con alertas tempranas, el servidor cae cuando el disco llega al 100%. Con monitorización básica más análisis de logs, la alerta se habría disparado días antes.
El stack open-source: Grafana + Prometheus + Loki
La buena noticia es que no hace falta pagar por herramientas enterprise para tener un sistema de observabilidad serio. La combinación de Grafana, Prometheus y Loki es el stack open-source de referencia, usado tanto por startups como por equipos de infraestructura de grandes empresas.
Sistema de recogida y almacenamiento de métricas. Se conecta a sus servidores, contenedores, bases de datos y aplicaciones a través de exporters (pequeños agentes) y almacena las métricas en una base de datos de series temporales. Tiene su propio lenguaje de consulta (PromQL) que permite crear alertas muy precisas basadas en combinaciones de métricas.
- Exporters disponibles para nginx, PostgreSQL, MySQL, Redis, Node.js, Docker y decenas más
- Alertmanager para enrutar alertas a email, Slack, PagerDuty o cualquier webhook
- Ideal para métricas de infraestructura y aplicaciones
Sistema de agregación de logs diseñado por Grafana Labs. A diferencia de soluciones como Elasticsearch, Loki no indexa el contenido completo de los logs sino solo sus etiquetas (metadatos), lo que lo hace mucho más económico en recursos. Los logs se almacenan comprimidos y se consultan con LogQL, un lenguaje similar a PromQL.
- Integración nativa con Grafana: puede correlacionar logs con métricas en el mismo panel
- Promtail como agente de recogida de logs desde archivos o contenedores
- Consume mucho menos recursos que un stack ELK (Elasticsearch + Logstash + Kibana)
La capa de visualización que une todo. Permite crear dashboards con métricas de Prometheus y logs de Loki en la misma pantalla. Cuando una alerta de Prometheus se dispara, puede hacer clic directamente sobre el punto del gráfico y saltar a los logs de Loki de ese momento exacto. Es esa correlación la que convierte la monitorización en observabilidad real.
- Más de 80 fuentes de datos compatibles (AWS CloudWatch, MySQL, InfluxDB…)
- Sistema de alertas propio con canales de notificación configurables
- Dashboards de comunidad listos para usar para los stacks más comunes
Alertas inteligentes: la diferencia entre ruido y señal
Una de las trampas más comunes al implementar monitorización es configurar demasiadas alertas con umbrales fijos. El resultado es un equipo que recibe decenas de notificaciones al día, aprende a ignorarlas y un día se pierde la alerta importante entre el ruido.
Las alertas útiles tienen tres características:
Alertan sobre síntomas, no sobre causas
Una alerta que dice "CPU al 80%" no siempre requiere acción: depende del contexto. Una alerta que dice "el tiempo de respuesta de la API supera 2 segundos durante más de 5 minutos" es accionable porque indica impacto real en el usuario.
Tienen contexto suficiente para actuar
Una buena alerta incluye no solo el valor que la disparó sino también el enlace al dashboard relevante, los logs del periodo y una descripción del impacto esperado. Si quien recibe la alerta tiene que investigar por su cuenta qué significa, la alerta no está bien diseñada.
Usan umbrales dinámicos donde tiene sentido
Prometheus permite crear alertas basadas en tendencias o desviaciones respecto a la media histórica, no solo en valores absolutos. Una carga de CPU del 70% puede ser normal en horas pico y anómala a las 3 de la mañana. Las alertas que distinguen ese contexto generan muchos menos falsos positivos.
Regla práctica: si una alerta se dispara más de dos veces por semana sin requerir acción, hay que ajustarla o eliminarla. Las alertas que se ignoran son peores que no tener alertas.
Por dónde empezar: una hoja de ruta realista
- Monitorización básica de infraestructura
Empiece por lo más crítico: disponibilidad de servicios, uso de disco, CPU y memoria en sus servidores principales. Un Prometheus con Node Exporter y un dashboard de Grafana básico ya le da visibilidad sobre los fallos más comunes. Coste: tiempo de configuración (medio día) y los recursos del servidor donde lo despliegue.
- Centralización de logs con Loki
Añada Loki y Promtail para recoger los logs de sus aplicaciones y servicios en un único lugar. El primer beneficio inmediato es dejar de tener que conectarse a cada servidor por SSH para revisar logs cuando algo falla.
- Correlación en Grafana
Configure los data sources de Prometheus y Loki en Grafana y active la correlación entre ellos. A partir de aquí, cuando una métrica se dispara, puede ir directamente a los logs del momento exacto sin cambiar de herramienta.
- Alertas accionables
Defina no más de cinco o seis alertas iniciales sobre los síntomas más críticos para su negocio: tiempo de respuesta de la aplicación principal, errores HTTP 5xx, espacio en disco por debajo del 20%, servicios caídos. Configure las notificaciones a un canal de Slack o email del equipo responsable.
- Itere y amplíe
Una vez estabilizado el stack básico, amplíe la instrumentación a sus aplicaciones, añada métricas de negocio (pedidos por hora, usuarios activos) y refine las alertas basándose en los incidentes reales que vayan ocurriendo.
¿Necesita un equipo técnico para mantener esto?
El stack Grafana + Prometheus + Loki requiere configuración inicial y mantenimiento periódico, pero no necesita un equipo dedicado. Una vez instalado y estabilizado, el trabajo habitual es añadir nuevas métricas cuando cambia la infraestructura y ajustar alertas cuando aparecen falsos positivos. Para una PYME con infraestructura estable, eso supone pocas horas al mes.
Grafana Labs ofrece también una versión cloud gestionada de todo el stack (Grafana Cloud) con un tier gratuito generoso que puede ser suficiente para infraestructuras pequeñas, eliminando la necesidad de gestionar el propio servidor de observabilidad.
En EstructuraBit desplegamos y configuramos stacks de observabilidad adaptados a la infraestructura de cada empresa: desde un servidor único hasta entornos multi-cloud. Si quiere visibilidad real sobre lo que ocurre en sus sistemas, escríbanos.
Volver al blog