La teva monitorització no està trencada: està cridant

Hi ha una dada que es repeteix a tots els informes del sector i que gairebé ningú no llegeix del tot. Vectra AI xifra en 2.992 les alertes de seguretat que rep al dia una organització mitjana el 2026, i diu que el 63% no les atén ningú. El que crida l'atenció arriba després: aquest volum fa tres anys que cau (4.484 el 2023, 3.832 el 2025, sense dada pública del 2024) i el percentatge sense atendre continua on era. Filtrar més no ha arreglat res, perquè el problema mai no va ser quantes alertes entren.

Convé dir d'on surt aquesta xifra abans de fer-la servir: són alertes de seguretat, de centres d'operacions que vigilen amenaces. El nostre terreny és més ampli i més avorrit (el Zabbix que mira els nodes, la sonda que pregunta per la latència, la feina de còpia que ahir a la nit va trigar el doble), i allà no tenim cap estadística de sector per ensenyar. El que tenim són plataformes heretades. Quan ens fem càrrec d'una que feia anys que funcionava sola, el patró que solem trobar-nos és aquest: un munt de sensors, un munt de correus i una carpeta d'Outlook amb una regla que els envia directes a llegits.

La xifra que baixa i el problema que no

La sèrie és la part útil: 4.484 alertes diàries el 2023, 3.832 el 2025 i 2.992 el 2026. Un terç menys de soroll en tres anys. És exactament el que promet cada producte que es compra per «reduir el soroll», i ha funcionat. I tot i així, la majoria continua sense mirar-se. El mateix recompte cita l'informe State of the SOC 2026 de Microsoft i Omdia, amb dues xifres que apunten al mateix lloc: el 46% de les alertes resulten ser falsos positius i el 42% no arriba a investigar-se.

Un apunt honest: el 63% d'una font i el 42% de l'altra no quadren entre si, i no farem veure que sí. Mesuren coses diferents amb mostres diferents, i això ja diu alguna cosa sobre com de difícil és mesurar-ho. El que sí que sobreviu a la discrepància és l'ordre de magnitud: entre quatre i una mica més de sis de cada deu avisos acaben sense que ningú els toqui. Si a casa teva aquesta xifra fos del 10%, la conversa seria una altra. Poques vegades ho és.

Una alerta sense responsable és un log amb ínfules

La monitorització se sol dissenyar al revés. Es comença per «què puc mesurar», que avui és pràcticament tot, i s'acaba amb un plafó preciós que ningú no mira perquè sempre té alguna cosa en vermell. Nosaltres fem que cada alerta es guanyi el dret a existir, i per això demanem quatre respostes abans de crear-la:

La regla és dura a propòsit: si una condició no té les quatre respostes, no es crea l'alerta. Es queda com a mètrica, es pinta en un plafó i es revisa quan toca. No passa res per mesurar molt; el que fa mal és convertir cada mesura en una interrupció que algú haurà d'aprendre a ignorar.

«CPU al 90%» no és un problema, i aquest és el problema

El llindar fix és la fàbrica de soroll més gran que coneixem. Un node de virtualització amb la CPU al 90% durant la finestra de còpia nocturna està fent exactament allò per al qual es va comprar. Un disc al 85% tampoc no diu gaire; el que diu alguna cosa és a quina velocitat hi va arribar. I l'alerta salta igual, cada nit, fins que algú la silencia «un parell de dies».

L'alternativa no és esotèrica i fa anys que és a les eines que ja tens. Zabbix documenta dues funcions de predicció, timeleft() i forecast(): la primera calcula quant falta perquè una mètrica arribi a un llindar, la segona estima quin valor tindrà d'aquí a una estona, totes dues ajustant un model sobre l'històric. Amb això, l'alerta deixa de ser «el disc està al 85%» i passa a ser «a aquest ritme, aquest disc s'omple dijous». La primera t'interromp; la segona et dona tres dies per demanar pressupost. Mateixa mètrica, dos productes completament diferents.

L'altra peça que gairebé ningú no configura són les dependències entre disparadors. Quan cau un node, la caixa hauria d'enviar un correu dient que ha caigut el node, i no quaranta correus dels quaranta serveis que hi vivien a sobre. Es configura una vegada i separa una avaria d'una allau. En aquesta línia, la integració oficial de Zabbix a Proxmox ens va estalviar força artesania, però no estalvia criteri: la plantilla et dona les dades, les decisions continuen sent teves.

El que ens desperta de matinada (la llista és curta a propòsit)

Aquesta és la nostra llista, no cap veritat universal, i canvia segons el que el client s'hi jugui. Però el criteri es trasllada: desperta el que ja fa mal o el que farà mal abans que ningú arribi a l'oficina.

• Un servei caigut de cara a l'usuari, no un component caigut. La diferència importa: un node menys en un clúster amb marge no és cap urgència; l'aplicació que no respon sí.
• Pèrdua de la segona pota, no de la primera. Que caigui una font, un enllaç o una rèplica és el sistema funcionant com es va dissenyar. Que caigui la que quedava és una altra cosa, i gairebé ningú no té aquesta alerta muntada.
• Quòrum de clúster en risc. Aquí el marge entre «va bé» i «s'atura tot» es mesura en un node.
• Una còpia que no es pot restaurar, que no és el mateix que una feina de còpia fallida. Que la feina acabi en verd i la verificació digui una altra cosa és el pitjor dels silencis.
• Degradació de xarxa que l'usuari ja nota. No el ping, que gairebé sempre respon: la pèrdua de paquets i la latència sostinguda.
• Senyal de seguretat d'alta confiança de l'EDR/MDR: execució bloquejada, compte privilegiat nou, esborrat massiu. D'alta confiança, no «activitat sospitosa» genèrica.

Tota la resta (temperatures, pics, reinicis previstos, certificats a seixanta dies, actualitzacions pendents) va a l'informe del matí. És una decisió deliberada, i costa defensar-la en una reunió: cada cosa que puja a la llista de dalt treu atenció a les altres. Una guàrdia amb sis motius per sonar funciona. Amb seixanta, deixa de sonar del tot.

La fallada que no dispara cap llindar

Hi ha una trucada que es repeteix: «va lent». Tot està verd, el ping respon, la CPU tranquil·la, cap servei caigut. I l'usuari té raó. Gairebé sempre és un 2% de pèrdua de paquets amb jitter a l'enllaç, o una ruta que va canviar i ara fa la volta per un altre lloc: res que un llindar binari de «respon / no respon» no veurà mai. Per això mesurem la latència de manera contínua i la mirem com una sèrie, no com un sí o un no; per això mantenim la nostra pròpia imatge Docker de SmokePing. Com a operador amb xarxa pròpia, això ho veiem pels dos costats: el del client que truca i el del BGP i el NetFlow que diuen per on va el trànsit de debò.

Silenciar bé no és tapar-se els ulls

Hi ha una idea instal·lada, mig moral, que silenciar una alerta és fer trampa. Nosaltres ho tenim just per la contrària: silenciar és part del disseny. Finestres de manteniment declarades perquè un reinici previst no desperti ningú. Dependències perquè la causa parli i els símptomes callin. Agrupació perquè un incident sigui un avís i no dos-cents. Histèresi perquè una mètrica que balla al voltant del llindar no generi vint parelles de «problema» i «resolt» en una hora.

El que sí que és fer trampa és el silenci sense data. L'alerta que algú va apagar «fins dilluns» fa vuit mesos és el deute més perillós d'una plataforma, perquè des de fora s'assembla molt a la cobertura: el sensor hi és, el plafó diu verd i ningú no se n'assabentarà. Per això cada silenci porta caducitat i un motiu escrit. Quan caduca, o s'arregla la causa o es decideix, de manera conscient, que allò ja no es vigila. Totes dues són respostes legítimes. «Se me'n va anar del cap» no ho és.

Com es poda això un dimarts qualsevol

Quan heretem una plataforma que crida, no redissenyem res el primer dia. Traiem l'històric dels últims trenta o noranta dies, l'agrupem per disparador i l'ordenem per nombre de vegades que va saltar. La llista sempre té la mateixa forma: un grapat de disparadors concentra la major part del volum, i la cua llarga gairebé no pesa. Aquí és on hi ha la palanca.

Per a cadascun d'aquests, una de quatre decisions i cap altra: arreglar la causa (el disc que s'omple cada setmana no necessita una alerta millor, necessita una rotació de logs); canviar la condició (durada mínima, histèresi, dependència, predicció en comptes de llindar); degradar a informe; o esborrar-la. Sí, esborrar-la. La monitorització acumula per defecte perquè treure fa por, i aquesta por és exactament el que produeix plataformes de quatre mil alertes al dia.

I una mètrica d'èxit que no és l'òbvia. Perseguir «menys alertes» s'aconsegueix apagant coses i no vol dir res. El que mirem és el percentatge d'alertes que van provocar una acció. Si puja, la monitorització està millorant encara que la xifra total no es mogui. Vam aplicar el mateix criteri fa un parell de setmanes per prioritzar pedaços, quan el Patch Tuesday de juliol va portar 622 vulnerabilitats de cop: ordenar la llista era tota la feina.

I això ho revisem per trimestres, perquè una monitorització sense poda torna a créixer sola: cada projecte nou porta els seus sensors, cada ensurt porta la seva alerta de record, i en un any ets un altre cop on vas començar.

El 24/7 que no és 24/7

Aquí arriba la part incòmoda, i la diem encara que sigui el nostre propi negoci el que es posa en qüestió. Rebre una alerta a les tres de la matinada no és suport 24/7. És un correu a les tres de la matinada. El servei comença on algú la llegeix, decideix i toca alguna cosa. Si la monitorització envia tres-cents correus al dia a una adreça genèrica, el que has muntat és una carpeta.

Les cinc preguntes que faríem a qualsevol contracte de guàrdia, inclòs el nostre: l'alerta arriba a una persona concreta de torn o a una bústia compartida? en quant temps es compromet algú a respondre, i està escrit? què pot tocar aquesta persona sense trucar a ningú —reiniciar un servei, migrar una màquina, tallar un port— i què no? hi ha un procediment escrit per tipus d'alerta o s'improvisa? i la que més fa mal: quan va ser l'últim cop que algú va provar la cadena sencera, de matinada, amb una alerta de mentida?

Un tancament sense moralina. Agafa les alertes de la setmana passada i compta quantes van fer que algú toqués alguna cosa. Aquesta xifra (no la de sensors, ni la de plafons, ni la del logotip del fabricant) és la teva monitorització. La resta és decoració amb notificacions.

Fonts (verificades): mitjana de 2.992 alertes de seguretat diàries el 2026, 63% sense atendre, i la sèrie 4.484 (2023) i 3.832 (2025): Vectra AI, «Alert fatigue: causes, real cost, and how to fix it». Les xifres del 46% de falsos positius i el 42% d'alertes sense investigar s'atribueixen a l'informe State of the SOC 2026 de Microsoft i Omdia i les prenem d'aquesta mateixa pàgina de Vectra: no hem verificat l'informe original de primera mà i per això les donem com a cita de segona mà. Les funcions de predicció timeleft() i forecast(), amb els seus models d'ajust sobre l'històric: documentació oficial de Zabbix, «Predictive trigger functions». El nostre ús de Zabbix i SmokePing, la xarxa pròpia amb BGP i NetFlow i la filosofia d'alertes que importen són de casa. El criteri de les quatre preguntes, la llista del que desperta i les cinc preguntes del contracte de guàrdia són nostres, no doctrina de ningú.