El problema de la monitorización reactiva
La monitorización tradicional funciona con umbrales: CPU por encima del 90 %, disco por encima del 85 %, cola con más de 1.000 elementos. Esas alertas son útiles, pero se disparan cuando el daño ya se está produciendo. Cuando el dashboard se pone en rojo, las transacciones ya están dando timeout y el teléfono de soporte suena.
Peor aún, las herramientas genéricas solo cubren métricas genéricas. Ven que un proceso Java consume memoria, pero no ven que un trabajo batch concreto dentro de tu ERP está encolando cuatro veces más registros que en la misma franja horaria del martes anterior. En esa brecha de visibilidad es donde viven los incidentes de producción.
Qué significa realmente la monitorización proactiva
La monitorización proactiva cambia la pregunta de "¿esta métrica supera el límite?" a "¿este sistema se comporta como es habitual en él?". La plataforma que operamos para nuestros clientes de servicios gestionados se apoya en cuatro ideas:
Reconocimiento de patrones de comportamiento
Cada activo monitorizado tiene una línea base aprendida. Las alertas se disparan cuando el comportamiento se desvía del patrón, no cuando se supera un umbral arbitrario. Así se detectan fugas de memoria, discos lentos y planes de consulta que se degradan poco a poco antes de que alguien reciba una llamada.
5 años de histórico
Una retención a largo plazo permite comparar la carga de hoy con la misma semana del trimestre o del año anterior. La planificación de capacidad y la puntuación de anomalías dejan de ser una conjetura.
Cientos de plugins a medida
La monitorización estándar se queda en las métricas obvias. A lo largo de los años hemos construido cientos de plugins y conectores para bases de datos propietarias, middleware heredado, cabinas de almacenamiento poco comunes y procesos de negocio específicos de cada cliente.
Enrutamiento de alertas que respeta el contrato
Cada alerta está vinculada a una regla de notificación y a un modelo de contrato: la persona adecuada, el canal adecuado, la severidad adecuada, con supresión para ventanas de mantenimiento conocidas.
Qué monitorizamos
Los clientes suelen empezar con un par de activos obvios —una base de datos de producción, una API crítica— y van ampliando la cobertura desde ahí. Hoy la misma plataforma vigila desde el almacenamiento físico hasta los ERP en SaaS, con un modelo de alertas unificado.
| Capa | Qué cubrimos |
|---|---|
| Servidores y SO | Linux, Windows, AIX, Solaris — CPU, memoria, procesos, eventos del kernel |
| Bases de datos | Oracle, PostgreSQL, SQL Server, MySQL, MongoDB — sesiones, bloqueos, tablespaces, consultas lentas |
| Middleware | WebLogic, Tomcat, JBoss, IIS, Kafka, RabbitMQ — JVM, colas, hilos |
| Almacenamiento y backup | Cabinas SAN/NAS, estado de snapshots, cumplimiento de ventanas de backup, pruebas de restauración |
| Red | Firewalls, switches, balanceadores de carga, túneles VPN, latencia y pérdida de paquetes |
| Cloud y SaaS | AWS, Azure, OCI, Microsoft 365, NetSuite — cuotas, anomalías de facturación, disponibilidad de APIs |
| APIs de negocio | Endpoints REST/SOAP a medida, tiempo de respuesta, presupuestos de error, desviaciones de contrato |
| ERP y aplicaciones de negocio | NetSuite, Oracle Fusion, SAP — trabajos batch, integraciones, KPIs transaccionales |
La capa de plugins es la verdadera ventaja
La plataforma base es de nivel empresarial y está bien documentada. La razón por la que los clientes se quedan es la biblioteca de plugins y conectores que hemos construido encima: cientos de sondas para sistemas que ningún agente comercial soporta de fábrica.
- Bases de datos y middleware heredados — agentes para módulos antiguos de Oracle E-Business, pasarelas de mainframe y stacks Java a medida que aún sostienen el negocio.
- Monitores de procesos de negocio — comprobaciones sintéticas que simulan un recorrido real de usuario (login, hacer un pedido, contabilizar una factura) y alertan ante regresiones funcionales, no solo de infraestructura.
- Sondas de ERP y finanzas — vigilantes de saved searches de NetSuite, estado de integraciones de Oracle Fusion, comprobaciones de backlog de IDocs de SAP.
- Conectores específicos de sector — estado de switches de pago para clientes fintech, estado de bots RPA para centros de servicios compartidos, telemetría IoT para instalaciones.
De la alerta al resultado
La detección es solo la mitad del trabajo. Cada alerta entra en un flujo de respuesta definido:
- Evento enriquecido — las alertas llegan con el activo, el responsable, el último incidente similar y el runbook adjunto.
- Enrutamiento por contrato — cada cliente tiene rutas de escalado, turnos de guardia y definiciones de severidad distintas. La plataforma las respeta.
- Auto-remediación cuando es seguro — reiniciar un servicio bloqueado, liberar un tablespace, rotar un log, matar una sesión descontrolada — todo registrado, todo reversible.
- Evidencia de tendencia en cada ticket — cuando un ingeniero abre un incidente, recibe los últimos 12 meses de la misma métrica, no solo el pico.
Qué cambia para el negocio
- Caídas detectadas en estado previo al fallo, no en la autopsia posterior.
- Menos conversaciones de "¿por qué no lo vimos venir?" tras los incidentes.
- Decisiones de capacidad basadas en cinco años de comportamiento real, no en heurísticas del fabricante.
- Un único modelo de alertas para cloud, on-premise, SaaS y aplicaciones a medida.
- Evidencias listas para auditoría de ISO 27001 y controles de tipo SOC.
Cómo empezar
Normalmente ejecutamos una discovery de dos semanas: inventariamos el entorno, identificamos los diez principales modos de fallo que la herramienta actual no detecta y ponemos en marcha la monitorización para esos primero. Si un sistema no está cubierto por ningún plugin existente, construimos uno; así es como la biblioteca ha llegado a su tamaño actual.
Si estás cansado de enterarte de los incidentes por tus usuarios, esa es la conversación que hay que tener.