Observabilidad y alertas que avisan de lo que importa
Enteraros de una caída antes que vuestros clientes, saber por qué ha pasado y dejar de recibir alertas que nadie lee.
Herramientas habituales
- ClickHouse
- Elasticsearch
- Grafana
- Prometheus
- Graylog
- Kafka
- Matomo
- RabbitMQ
En resumen
La observabilidad es la capacidad de saber qué está pasando dentro de vuestra plataforma a partir de sus métricas, sus logs y sus trazas. Montamos Prometheus para las métricas, Loki y Alloy para los logs, OpenTelemetry para las trazas y Grafana para los paneles, con alertas de umbrales pactados que avisan de lo que afecta al servicio y no de todo.
- Idiomas
- Español, catalán o inglés
- Respuesta
- El siguiente día hábil, en horario laboral
- Método
- En vuestra cuenta y vuestro repositorio, en código y documentado
Qué incluye
- Métricas de infraestructura y de aplicación con Prometheus.
- Logs centralizados con Loki y Grafana Alloy, con retención acordada.
- Trazas con OpenTelemetry en los servicios que más lo necesitan.
- Paneles en Grafana por servicio, con las señales clave arriba.
- Alertas con Alertmanager, umbrales pactados y un canal claro.
- Objetivos de disponibilidad (SLO) para los servicios críticos.
- Guía breve de qué hacer con cada alerta.
- Todo desplegado con código, en vuestro repositorio.
¿Cuándo hace falta revisar la observabilidad?
Casi siempre que alguien dice «tenemos monitorización» pero las caídas las sigue avisando un cliente. Las señales habituales:
- Las caídas se descubren por un correo de un cliente o por redes sociales.
- Hay un canal de alertas con cientos de mensajes que nadie lee.
- Para encontrar un error hay que entrar por SSH a cada servidor y buscar en los logs.
- Nadie sabe decir qué disponibilidad tuvo el servicio el mes pasado.
- Los paneles de Grafana existen, pero los hizo alguien que ya no está.
¿Qué señal sirve para qué?
Métricas, logs y trazas no son tres formas de ver lo mismo: cada una responde a una pregunta distinta. Así las repartimos:
| Señal | Pregunta que responde | Herramienta | Ejemplo |
|---|---|---|---|
| Métricas | ¿Está bien el servicio ahora y cómo evoluciona? | Prometheus | Latencia del percentil 95 o errores por minuto |
| Logs | ¿Qué ha pasado exactamente en este momento? | Loki con Alloy | El error y la petición que lo provocó |
| Trazas | ¿En qué parte de la cadena se pierde el tiempo? | OpenTelemetry | Una petición que tarda en la base de datos |
| Alertas | ¿Tiene que actuar alguien ya? | Alertmanager | Errores por encima del umbral durante 5 minutos |
| SLO | ¿Estamos cumpliendo lo prometido? | Prometheus y Grafana | 99,9 % de peticiones correctas en 30 días |
Lo mismo vale fuera de la web: en plataformas IoT, como ThingsBoard o una plataforma IoT con MQTT, vigilamos también la ingesta de datos, las colas de mensajes y los dispositivos conectados. Y si queréis medir las visitas de vuestra web sin ceder los datos a terceros, montamos Matomo en vuestro servidor.
¿Cómo diseñamos las alertas?
Una alerta que no lleva a una acción es ruido, y el ruido hace que se ignoren las importantes. Seguimos tres reglas:
- Por síntoma, no por causa: primero lo que nota el usuario (errores, latencia, caída), después las causas (CPU, disco) como avisos.
- Con umbral pactado: el umbral y la ventana se deciden con vosotros, según lo que vuestro servicio tolera.
- Con instrucciones: cada alerta enlaza a una guía de qué mirar y qué hacer.
El resultado se mide: menos alertas, más rápidas de atender y ninguna caída que descubra antes un cliente.
¿Cómo se implanta?
Revisión
Qué se vigila hoy, qué se pierde y qué alertas se ignoran.
Métricas y logs
Prometheus, Loki y Alloy desplegados con código, con retención y almacenamiento acordados.
Paneles y SLO
Un panel por servicio y objetivos de disponibilidad para los críticos.
Alertas
Umbrales pactados, canal de aviso y guía para cada una.
¿Qué experiencia tenemos?
La observabilidad ha sido parte de toda nuestra trayectoria. Como DevOps en un SaaS B2B hemos mejorado la observabilidad y la recuperación ante desastres de la plataforma; desde la dirección técnica, el 99,9 % de disponibilidad se sostenía con alertas que avisaban antes que los clientes. Trabajamos a diario con Prometheus, Grafana, Loki, Alloy y Alertmanager. Si queréis que alguien atienda esas alertas cada mes, encaja con el SRE como servicio.
Preguntas frecuentes
¿Por qué no usar un servicio comercial de monitorización?
Puede ser buena opción y os lo diremos si encaja. Prometheus, Loki y Grafana suelen compensar cuando el volumen de datos hace caro el servicio comercial o cuando los datos no pueden salir de vuestra infraestructura.
¿Cuántas alertas debería tener?
Pocas y accionables. Cada alerta que despierta a alguien debe tener una acción clara; el resto va a un panel o a un resumen diario. Empezamos por las que afectan a vuestros usuarios y añadimos a partir de ahí.
¿Quién atiende las alertas?
Vuestro equipo, con la guía que dejamos, o nosotros dentro del SRE como servicio. Las alertas saltan a cualquier hora; la respuesta es el siguiente día hábil, en horario laboral.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Revisado el