Tu monitorización no está rota: está gritando

Hay un dato que se repite en todos los informes del sector y que casi nadie lee del todo. Vectra AI cifra en 2.992 las alertas de seguridad que recibe al día una organización media en 2026, y dice que el 63% no las atiende nadie. Lo llamativo llega después: ese volumen lleva tres años cayendo (4.484 en 2023, 3.832 en 2025, sin dato público de 2024) y el porcentaje sin atender sigue donde estaba. Filtrar más no ha arreglado nada, porque el problema nunca fue cuántas alertas entran.

Conviene decir de dónde sale ese número antes de usarlo: son alertas de seguridad, de centros de operaciones que vigilan amenazas. Nuestro terreno es más amplio y más aburrido (el Zabbix que mira los nodos, la sonda que pregunta por la latencia, el trabajo de copia que anoche tardó el doble), y ahí no tenemos una estadística de sector que enseñar. Lo que tenemos son plataformas heredadas. Cuando nos hacemos cargo de una que llevaba años funcionando sola, el patrón que solemos encontrarnos es este: un montón de sensores, un montón de correos y una carpeta de Outlook con una regla que los manda directos a leídos.

La cifra que baja y el problema que no

La serie es la parte útil: 4.484 alertas diarias en 2023, 3.832 en 2025 y 2.992 en 2026. Un tercio menos de ruido en tres años. Es exactamente lo que promete cada producto que se compra para «reducir el ruido», y ha funcionado. Y aun así, la mayoría sigue sin mirarse. El mismo recuento cita el informe State of the SOC 2026 de Microsoft y Omdia, con dos cifras que apuntan al mismo sitio: el 46% de las alertas resultan ser falsos positivos y el 42% no llega a investigarse.

Un apunte honesto: el 63% de una fuente y el 42% de la otra no cuadran entre sí, y no vamos a fingir que sí. Miden cosas distintas con muestras distintas, y eso ya dice algo sobre lo difícil que es medir esto. Lo que sí sobrevive a la discrepancia es el orden de magnitud: entre cuatro y algo más de seis de cada diez avisos acaban sin que nadie los toque. Si en tu casa esa cifra fuera del 10%, la conversación sería otra. Rara vez lo es.

Una alerta sin dueño es un log con ínfulas

La monitorización se suele diseñar al revés. Se empieza por «qué puedo medir», que hoy es prácticamente todo, y se acaba con un panel precioso que nadie mira porque siempre tiene algo en rojo. Nosotros hacemos que cada alerta se gane el derecho a existir, y para eso pedimos cuatro respuestas antes de crearla:

La regla es dura a propósito: si una condición no tiene las cuatro respuestas, no se crea la alerta. Se queda como métrica, se pinta en un panel y se revisa cuando toca. No pasa nada por medir mucho; lo que hace daño es convertir cada medición en una interrupción que alguien tendrá que aprender a ignorar.

«CPU al 90%» no es un problema, y ese es el problema

El umbral fijo es la mayor fábrica de ruido que conocemos. Un nodo de virtualización con la CPU al 90% durante la ventana de copia nocturna está haciendo exactamente aquello para lo que se compró. Un disco al 85% tampoco dice gran cosa; lo que dice algo es a qué velocidad llegó ahí. Y la alerta salta igual, todas las noches, hasta que alguien la silencia «un par de días».

La alternativa no es esotérica y lleva años en las herramientas que ya tienes. Zabbix documenta dos funciones de predicción, timeleft() y forecast(): la primera calcula cuánto falta para que una métrica alcance un umbral, la segunda estima qué valor tendrá dentro de un rato, ambas ajustando un modelo sobre el histórico. Con eso, la alerta deja de ser «el disco está al 85%» y pasa a ser «a este ritmo, este disco se llena el jueves». La primera te interrumpe; la segunda te da tres días para pedir presupuesto. Misma métrica, dos productos completamente distintos.

La otra pieza que casi nadie configura son las dependencias entre disparadores. Cuando cae un nodo, la caja debería mandar un correo diciendo que cayó el nodo, y no cuarenta correos de los cuarenta servicios que vivían encima. Se configura una vez y separa una avería de una avalancha. En esa línea, la integración oficial de Zabbix en Proxmox nos ahorró bastante artesanía, pero no ahorra criterio: la plantilla te da los datos, las decisiones siguen siendo tuyas.

Lo que nos despierta de madrugada (la lista es corta a propósito)

Esta es nuestra lista, no una verdad universal, y cambia según lo que el cliente se juegue. Pero el criterio se traslada: despierta lo que ya duele o lo que va a doler antes de que alguien llegue a la oficina.

• Un servicio caído de cara al usuario, no un componente caído. La diferencia importa: un nodo menos en un clúster con holgura no es una urgencia; la aplicación que no responde sí.
• Pérdida de la segunda pata, no de la primera. Que se caiga una fuente, un enlace o una réplica es el sistema funcionando como se diseñó. Que se caiga la que quedaba es otra cosa, y casi nadie tiene esa alerta montada.
• Quórum de clúster en riesgo. Aquí el margen entre «va bien» y «se para todo» se mide en un nodo.
• Una copia que no se puede restaurar, que no es lo mismo que un trabajo de copia fallido. Que el trabajo termine en verde y la verificación diga otra cosa es el peor de los silencios.
• Degradación de red que el usuario ya nota. No el ping, que casi siempre responde: la pérdida de paquetes y la latencia sostenida.
• Señal de seguridad de alta confianza del EDR/MDR: ejecución bloqueada, cuenta privilegiada nueva, borrado masivo. De alta confianza, no «actividad sospechosa» genérica.

Todo lo demás (temperaturas, picos, reinicios previstos, certificados a sesenta días, actualizaciones pendientes) va al informe de la mañana. Es una decisión deliberada, y cuesta defenderla en una reunión: cada cosa que sube a la lista de arriba le quita atención a las demás. Una guardia con seis motivos para sonar funciona. Con sesenta, deja de sonar del todo.

El fallo que no dispara ningún umbral

Hay una llamada que se repite: «va lento». Todo está verde, el ping responde, la CPU tranquila, ningún servicio caído. Y el usuario tiene razón. Casi siempre es un 2% de pérdida de paquetes con jitter en el enlace, o una ruta que cambió y ahora da la vuelta por otro sitio: nada que un umbral binario de «responde / no responde» vaya a ver jamás. Por eso medimos la latencia de forma continua y la miramos como una serie, no como un sí o un no; por eso mantenemos nuestra propia imagen Docker de SmokePing. Como operador con red propia, esto lo vemos por los dos lados: el del cliente que llama y el del BGP y el NetFlow que dicen por dónde va el tráfico de verdad.

Silenciar bien no es taparse los ojos

Hay una idea instalada, medio moral, de que silenciar una alerta es hacer trampa. Nosotros la tenemos por lo contrario: silenciar es parte del diseño. Ventanas de mantenimiento declaradas para que un reinicio previsto no despierte a nadie. Dependencias para que la causa hable y los síntomas se callen. Agrupación para que un incidente sea un aviso y no doscientos. Histéresis para que una métrica que baila alrededor del umbral no genere veinte parejas de «problema» y «resuelto» en una hora.

Lo que sí es hacer trampa es el silencio sin fecha. La alerta que alguien apagó «hasta el lunes» hace ocho meses es la deuda más peligrosa de una plataforma, porque desde fuera se parece mucho a la cobertura: el sensor está, el panel dice verde y nadie va a enterarse. Por eso cada silencio lleva caducidad y un motivo escrito. Cuando caduca, o se arregla la causa o se decide, de forma consciente, que eso ya no se vigila. Las dos son respuestas legítimas. «Se me olvidó» no lo es.

Cómo se poda esto un martes cualquiera

Cuando heredamos una plataforma que grita, no rediseñamos nada el primer día. Sacamos el histórico de los últimos treinta o noventa días, lo agrupamos por disparador y lo ordenamos por número de veces que saltó. La lista siempre tiene la misma forma: un puñado de disparadores concentra la mayor parte del volumen, y la cola larga apenas pesa. Ahí está la palanca.

Para cada uno de esos, una de cuatro decisiones y ninguna otra: arreglar la causa (el disco que se llena todas las semanas no necesita una alerta mejor, necesita una rotación de logs); cambiar la condición (duración mínima, histéresis, dependencia, predicción en vez de umbral); degradar a informe; o borrarla. Sí, borrarla. La monitorización acumula por defecto porque quitar da miedo, y ese miedo es exactamente lo que produce plataformas de cuatro mil alertas al día.

Y una métrica de éxito que no es la obvia. Perseguir «menos alertas» se consigue apagando cosas y no significa nada. Lo que miramos es el porcentaje de alertas que provocaron una acción. Si sube, la monitorización está mejorando aunque el número total se quede clavado. Aplicamos el mismo criterio hace un par de semanas para priorizar parches, cuando el Patch Tuesday de julio trajo 622 vulnerabilidades de golpe: ordenar la lista era todo el trabajo.

Y esto lo revisamos por trimestres, porque una monitorización sin poda vuelve a crecer sola: cada proyecto nuevo trae sus sensores, cada susto trae su alerta de recuerdo, y en un año estás otra vez donde empezaste.

El 24/7 que no es 24/7

Aquí llega la parte incómoda, y la decimos aunque sea nuestro propio negocio el que se pone en cuestión. Recibir una alerta a las tres de la mañana no es soporte 24/7. Es un correo a las tres de la mañana. El servicio empieza donde alguien la lee, decide y toca algo. Si la monitorización manda trescientos correos al día a una dirección genérica, lo que has montado es una carpeta.

Las cinco preguntas que le haríamos a cualquier contrato de guardia, incluido el nuestro: ¿la alerta llega a una persona concreta de turno o a un buzón compartido? ¿en cuánto tiempo se compromete alguien a responder, y está escrito? ¿qué puede tocar esa persona sin llamar a nadie —reiniciar un servicio, migrar una máquina, cortar un puerto— y qué no? ¿hay un procedimiento escrito por tipo de alerta o se improvisa? y la que más duele: ¿cuándo fue la última vez que alguien probó la cadena entera, de madrugada, con una alerta de mentira?

Un cierre sin moraleja. Coge las alertas de la semana pasada y cuenta cuántas hicieron que alguien tocara algo. Ese número (no el de sensores, ni el de paneles, ni el del logo del fabricante) es tu monitorización. El resto es decoración con notificaciones.

Fuentes (verificadas): media de 2.992 alertas de seguridad diarias en 2026, 63% sin atender, y la serie 4.484 (2023) y 3.832 (2025): Vectra AI, «Alert fatigue: causes, real cost, and how to fix it». Las cifras del 46% de falsos positivos y el 42% de alertas sin investigar se atribuyen al informe State of the SOC 2026 de Microsoft y Omdia y las tomamos de esa misma página de Vectra: no hemos verificado el informe original de primera mano y por eso las damos como cita de segunda mano. Las funciones de predicción timeleft() y forecast(), con sus modelos de ajuste sobre el histórico: documentación oficial de Zabbix, «Predictive trigger functions». Nuestro uso de Zabbix y SmokePing, la red propia con BGP y NetFlow y la filosofía de alertas que importan son de casa. El criterio de las cuatro preguntas, la lista de lo que despierta y las cinco preguntas del contrato de guardia son nuestros, no doctrina de nadie.