Filtrare errori non critici per ridurre rumore

Il problema più frequente di chi attiva un monitoring WordPress: troppi eventi, troppi alert, alert fatigue. In questa guida ti mostriamo come filtrare il rumore con WP Error Monitor per concentrarti sugli errori che contano davvero.

Identificare il rumore

Tipici falsi positivi: deprecation warning di PHP 8.x (es. function deprecated), notice di plugin che non sanitizzano (Undefined index), warning di file not found su asset opzionali, errori temporanei rete (cURL timeout occasionali). Sono spesso ricorrenti e non azionabili nel breve termine. Mantenerli a video confonde l’operatore.

Tipi di filtro in WP Error Monitor

1) Per severità: suppress E_NOTICE e E_DEPRECATED in produzione (WPEM_CAPTURE_LEVEL); 2) Per pattern messaggio: WPEM_IGNORE_PATTERNS array di regex (es. 'Undefined index: gtm'); 3) Per file: WPEM_IGNORE_FILES (whitelist plugin known-bad); 4) Per URL: WPEM_IGNORE_REQUEST_URI (es. /wp-cron.php in cui notice sono inevitabili); 5) Per IP: WPEM_IGNORE_IPS (es. monitoring uptime con paths inesistenti).

Quarantena: meglio di ignorare

Invece di ignorare del tutto, usa la modalità 'quarantinè: gli eventi vengono raccolti ma non triggerano alert, e finiscono in una vista separata del CRM. Così' se un'errore quarantened diventa critico (volume aumenta 10x) ricevi comunque notifica.

Alert fatigue: i numeri

Studi industria mostrano che dopo 50+ alert/giorno il team ignora il 70% delle notifiche. La soglia psicologica è 10-20 alert/giorno: oltre, si entra in fatigue. Calcola: numero alert ricevuti dal team in 7gg / 7. Se sopra 20, sei in fatigue. Strategie: 1) prioritize aggressivo (P1/P2 separati), 2) auto-resolve dopo X tempo, 3) digest mode (1 email/15min con riassunto), 4) rotation turni, 5) escalation policy.

Machine learning per anomaly detection

WP Error Monitor offre modulo ML opzionale che impara il baseline normale di errori per sito (volume, pattern, ore tipiche). Alert solo su anomalie significative (es. 5x rispetto a baseline). Riduce alert del 60-80% mantenendo coverage. Setup: WPEM_ML_BASELINE=true per 30gg di learning, poi switch a WPEM_ML_ANOMALY=true per alert basati su deviation.

Pattern aggregation per insight

Invece di guardare singoli eventi, aggrega per pattern: stesso messaggio + file = un pattern. WP Error Monitor mostra 'Top patterns' con count, first seen, last seen, trend (in aumento o calo). Così' 100 occorrenze dello stesso errore appaiono come 1 pattern con count=100, non 100 noise. Action chiare: pattern con count alto = priorità fix, pattern con count crescente = regression, pattern nuovo = bug appena introdotto. La vista pattern è default in 'Eventi' tab e si svolge il dettaglio per drill-down sulle singole occorrenze quando serve.

Auto-resolve per pattern transient

Alcuni errori sono transient: cURL timeout su API esterna lenta, lock DB occasionale, race condition rara. Non vale la pena alertare per ognuno. Configura auto-resolve: pattern che non si presenta per N giorni viene automaticamente marked 'resolved’ senza intervento manuale. Default N=7 giorni. Se torna, ri-apre automaticamente come 'regression'. Così' la dashboard mostra solo problemi attivi, non vecchi dimenticati. Setup: pannello 'Auto-resolve rules', definisci N giorni per ogni severità (es. NOTICE=3gg, WARNING=7gg, ERROR=14gg, CRITICAL=mai).

KPI di success per alert tuning

Misura il success del tuo alert tuning con KPI oggettivi: 1) alert ricevuti/giorno (target <20), 2) percentuale alert true positive (target >80%), 3) tempo medio di acknowledgement (target <15min per CRITICAL, <2h per altri), 4) percentuale alert su cui viene fatto fix (target >50% - se molto basso, troppi falsi positivi), 5) survey team feeling (alert fatigue stress level, target basso). Misura mensilmente, tuna threshold/filtri di conseguenza. WP Error Monitor offre dashboard 'Alert Health' con queste metriche pre-calcolate.

Periodic alert review

Schedula review mensile dei filtri alert: pattern oggi rumorosi potrebbero diventare critici domani con cambio versione PHP/WP. Revisione collaborativa tra team aiuta a identificare consensus sui pattern azionabili vs rumore vero, prevenendo derive personali nei filtri.

Procedura passo-passo

1. Apri WP Error Monitor e vai alla vista 'Eventi top'.
2. Identifica le 10 categorie di evento più numerose.
3. Per ognuna decidi: critico (fix), azionabile (ticket), rumore (filtra).
4. Aggiungi pattern a WPEM_IGNORE_PATTERNS in wp-config.php.
5. Per filtri lato server, usa l’interfaccia 'Filtri globali' del CRM.
6. Per warning ricorrenti di plugin noti, segnala bug all’autore.
7. Riesamina settimanalmente il top eventi e regola i filtri.
8. Attiva quarantine per pattern dubbi prima di ignorare definitivamente.
9. Misura alert/giorno team negli ultimi 30gg.
10. Se sopra 20, attiva modulo ML anomaly detection.

Errori comuni e come risolverli

• Filtro troppo aggressivo nasconde bug reali: Usa quarantine e revisione settimanale invece di ignore assoluto.
• WPEM_IGNORE_PATTERNS non funziona: Sintassi regex sbagliata: testa con preg_match prima.
• Volume cresce nonostante filtri: Filtri lato agent NON lato CRM: verifica dove è configurato.
• ML segnala anomalie false: Periodo learning troppo breve: estendi a 60-90gg.
• Pattern stagionali ignorati: ML model semplice: usa Prophet per stagionalità settimanale/mensile.

Domande frequenti

D: Posso filtrare anche per user agent?
R: Sì, WPEM_IGNORE_UA per escludere bot/scanner.

D: Quarantine occupa storage?
R: Sì, con TTL ridotto (default 7gg vs 90gg eventi normali).

D: Filtri condivisi tra siti?
R: Sì, i filtri globali del CRM sono cross-site.

D: ML modulo richiede risorse extra?
R: Marginalmente: usa scikit-learn lato CRM, no impatto siti.

D: Posso ricevere alert solo per nuovi pattern?
R: Sì, WPEM_ALERT_ON_NEW_ONLY=true.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.