Durante años, la monitorización clásica fue suficiente.
Servidores más o menos fijos, aplicaciones monolíticas, cambios controlados, poco cloud.
Un agente, cuatro métricas, unos cuantos umbrales, traps SNMP… y a correr.
El problema es que la infraestructura ha cambiado, pero muchas prácticas no.
Hoy hablamos de cloud híbrido, contenedores, microservicios, APIs por todas partes y dependencias externas que no controlamos.
Y aun así, en demasiados sitios seguimos monitorizando “como siempre”: CPU, memoria, filesystem y procesos.
Este artículo no va de vender ninguna herramienta.
Va de poner orden en todo este lío de palabras: Monitoring, Observability, APM, AIOps, SRE…
Y de hacerlo con una idea en la cabeza: reducir trabajo repetitivo (TOIL) y ganar fiabilidad real.
1. Monitoring vs Observability: no son lo mismo
Empezamos por la base.
Monitoring es lo que llevamos haciendo toda la vida:
métricas técnicas, umbrales, alertas cuando algo se pasa de rango.
Es útil, necesario y seguirá existiendo.
Pero responde a una pregunta muy concreta:
“¿Está roto?”
Observability va un paso (o dos) más allá.
No se limita a decirte “está roto”: te ayuda a entender por qué.
Combina:
- Métricas
- Logs
- Trazas
- APM
- Contexto (topología, dependencias, cambios…)
- Experiencia de usuario
La pregunta que responde es distinta:
“¿Por qué está roto y qué parte del sistema está implicada?”
2. APM y Synthetics: mirar dentro vs mirar desde fuera
Otra confusión muy habitual: “Como tengo synthetics, ya no necesito APM”, o al revés.
APM (Application Performance Monitoring) es mirar la aplicación desde dentro:
- Transacciones reales
- Tiempos de respuesta
- Errores
- Llamadas a BBDD, colas, APIs…
- Mapa de servicios y dependencias
Synthetics es justo lo contrario: mirar desde fuera, simulando un usuario.
- Comprobar si la web responde
- Lanzar un login cada X minutos
- Simular una compra
- Medir desde distintas regiones
Uno responde a:
“¿Qué le está pasando a mi aplicación por dentro?”
El otro responde a:
“¿Puede entrar un usuario ahora mismo?”
3. AIOps: la capa de inteligencia (cuando hay buenos datos)
Aquí las etiquetas marketing han hecho mucho daño.
AIOps no es un producto mágico que lo arregla todo.
Es una capa que intenta poner orden en todo el ruido:
- Correlacionar eventos
- Detectar anomalías
- Reducir alertas duplicadas
- Predecir saturaciones
- Priorizar lo relevante
La idea es buena, pero tiene un detalle clave:
si por debajo solo hay métricas pobres y sin contexto… la inteligencia no puede hacer milagros.
4. SRE: fiabilidad, SLOs y TOIL
Aquí entramos en el terreno de las personas y los equipos.
SRE (Site Reliability Engineering) no es “el admin moderno” ni “el que sabe Kubernetes”.
Es una disciplina que une:
- SLIs (qué medimos)
- SLOs (qué nivel de servicio queremos)
- Automatización
- Observabilidad
- Postmortems
- Reducción de TOIL
Muy rápido:
- SLI → indicador (“disponibilidad real medida”, “p95 de latencia”).
- SLO → objetivo (“99.9% de disponibilidad mensual”, “p95 por debajo de 300 ms”).
Con estos dos conceptos claros se pueden tomar decisiones.
TOIL: el enemigo silencioso
Este término viene del libro de Google SRE, y da mucho juego porque pone nombre a algo que llevamos sufriendo años.
TOIL es:
- Trabajo manual
- Repetitivo
- Reactivo
- Que no escala
- Y que no aporta valor a largo plazo
Ejemplos que tú y yo hemos visto mil veces:
- Altas y bajas de agentes a mano
- Ajustar umbrales uno a uno en distintas consolas
- Revisar la misma alerta ruidosa cada día
- Scripts que solo entienden dos personas
- Integraciones “temporales” que se quedan para siempre
- Cambios de configuración repetitivos que podrían automatizarse
Si un equipo dedica la mayor parte de su tiempo a esto, no está haciendo ingeniería, está apagando fuegos.
Google recomienda que un equipo SRE no dedique más del 50% del tiempo a TOIL.
En muchos sitios estamos en el 80–90%.
5. Dos ejemplos de Frankenstein que he visto (y que quizá te suenen)
Para que no se quede en teoría, dos escenarios muy reales:
Caso 1: cuatro herramientas y ninguna visión clara
Departamentos con:
- Nagios (o similar) para la parte básica de sistemas
- Una herramienta específica de bases de datos
- Dynatrace (u otro APM) para las aplicaciones
- Alguna capa de Elastic/Search para logs
En papel suena potente.
En la práctica, si no se diseña bien:
- Cada herramienta alerta por su lado
- Nadie ve el cuadro completo
- Se duplican esfuerzos
- Se incrementa el TOIL: más consolas, más reglas, más ruido
Caso 2: el Frankenstein de scripts, synthetics y monitorización básica
Otro patrón muy común:
- Monitorización clásica para CPU/memoria
- Unos synthetics para comprobar cuatro URLs
- Unos cuantos scripts caseros que lanzan checks y mandan mails
- Alguna integración que envía eventos, pero sin logs ni trazas ni APM de verdad
Resultado:
Se mantiene el monstruo a base de parches.
No hay SLIs claros, no hay SLOs bien definidos y el equipo vive en modo reactivo.
6. Hacia dónde tiene sentido ir
No hace falta tirar todo lo que hay.
Pero sí hace falta tener un plan.
Ideas clave:
- Mantener la monitorización clásica donde tiene sentido, pero asumir que ya no es suficiente.
- Impulsar APM y trazas: sin eso, no hay observabilidad moderna.
- Usar synthetics como un canario, no como única medida.
- Empezar a definir SLIs y SLOs reales, aunque sea en pocas aplicaciones críticas.
- Atacar el TOIL de frente: listar tareas repetitivas y empezar a automatizar lo más doloroso.
- Formar o crear un rol SRE, aunque sea de forma progresiva.
Al final se trata de pasar de:
“Tenemos muchas alertas”
a:
“Sabemos qué importa, por qué falla y cómo evitar que vuelva a pasar”.
Y ahí es donde monitoring, observability, APM, AIOps y SRE empiezan a encajar de verdad.
**Puedes ver vídeo con el contenido de este artículo resumido en Youtube
