Alert intelligenti per Java: come filtrare i false positive in WildFly con metriche JMX e machine learning

Alert intelligenti per Java: come filtrare i false positive in WildFly con metriche JMX e machine learning

Introduzione

Le applicazioni Java in esecuzione su WildFly generano un gran numero di metriche di runtime. Quando queste metriche sono collegate a un sistema di alert tradizionale, è comune incorrere in false positive: notifiche che non corrispondono a un reale degrado di servizio. Questo fenomeno, noto come alert fatigue, aumenta il MTTR (Mean Time to Recovery) e riduce l’efficacia dei team SRE. In questo articolo mostriamo come combinare le metriche JMX con algoritmi di machine learning per creare alert intelligenti, riducendo il rumore e migliorando i KPI di osservabilità.

1. Comprendere le metriche JMX di WildFly

1.1 Le metriche chiave da monitorare

WildFly espone una vasta gamma di MBean tramite JMX. Tra le più rilevanti per il rilevamento di anomalie troviamo:

  • ThreadPoolRuntime: numero di thread attivi, in attesa e completati.
  • JVMRuntime: utilizzo della memoria heap, GC pause e tempo di vita della JVM.
  • DatasourceRuntime: connessioni attive, pool size e tempi di attesa.

Queste metriche consentono di costruire un profilo di baseline di comportamento normale dell’applicazione.

1.2 Raccolta e normalizzazione dei dati

Per un'analisi efficace, i dati JMX devono essere:

  1. Campionati a intervalli regolari (es. ogni 30 secondi).
  2. Normalizzati (z‑score) per rendere confrontabili metriche con scale diverse.
  3. Aggregati su finestre temporali (media, max, min) per ridurre il rumore di breve durata.

Che cosa è una baseline JMX? Una baseline è il valore medio (con deviazione standard) di una metrica calcolato su un periodo di stabilità operativa, utilizzato come riferimento per individuare deviazioni significative.

2. Introduzione al machine learning per il filtraggio degli alert

2.1 Perché il ML è utile

Gli algoritmi di unsupervised learning (es. Isolation Forest, One‑Class SVM) sono particolarmente adatti a rilevare anomalie in flussi di dati continui senza richiedere etichette preliminari. Questi modelli apprendono la distribuzione normale delle metriche JMX e segnalano valori che si discostano significativamente.

2.2 Pipeline di addestramento

  1. Raccolta dati storici (30‑60 giorni) da ambienti di produzione stabili.
  2. Pre‑processing: rimozione di outlier evidenti, imputazione di valori mancanti.
  3. Addestramento del modello di isolamento.
  4. Validazione con set di dati contenenti incidenti noti per verificare il tasso di falsi positivi.

2.3 Integrazione con il sistema di alert

Una volta addestrato, il modello può essere esposto come micro‑servizio REST. WildFly invia le metriche normalizzate a questo endpoint; il servizio restituisce un punteggio di anomalia. Un threshold configurabile determina se generare un alert.

3. KPI da monitorare per valutare l’efficacia degli alert intelligenti

3.1 Metriche operative

  • False Positive Rate (FPR): percentuale di alert non correlati a incidenti reali.
  • Alert Volume Reduction: differenza percentuale tra il numero di alert prima e dopo l’applicazione del modello ML.
  • MTTR: tempo medio di risoluzione degli incidenti, ideale se diminuisce dopo l’implementazione.

3.2 Dashboard consigliata

Utilizzando Lescopr, è possibile creare una dashboard con i seguenti widget:

  1. Trend FPR (line chart) – mostra l’andamento settimanale.
  2. Alert Breakdown (pie) – distingue tra alert “reali” e “filtrati”.
  3. SLA Compliance (gauge) – verifica che gli SLA rimangano entro i limiti.

4. Implementazione pratica passo‑passo

4.1 Configurare JMX in WildFly

# Abilita l'esposizione JMX
/bin/jboss-cli.sh --connect <<EOF
/subsystem=jmx:add
/subsystem=jmx:write-attribute(name=expose-resolved-model,value=true)
/stop
EOF

4.2 Inviare le metriche a Lescopr

MBeanServer server = ManagementFactory.getPlatformMBeanServer();
ObjectName name = new ObjectName("java.lang:type=Memory");
Long heapUsed = (Long) server.getAttribute(name, "HeapMemoryUsage.used");
// Invio a Lescopr via HTTP POST
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://api.lescopr.io/metrics"))
    .header("Content-Type", "application/json")
    .POST(HttpRequest.BodyPublishers.ofString("{\"metric\":\"heap_used\",\"value\":" + heapUsed + "}"))
    .build();
client.sendAsync(request, BodyHandlers.ofString());

4.3 Addestrare il modello ML con Lescopr AI

  1. Accedi alla console Lescopr → AI Models.
  2. Crea un nuovo modello Isolation Forest.
  3. Carica il dataset JMX esportato.
  4. Definisci il threshold di anomalia (es. 0.85).
  5. Salva e attiva il modello.

4.4 Configurare la regola di alert

Nel pannello Alert Rules di Lescopr:

  • Source: endpoint REST del modello ML.
  • Condition: anomaly_score > 0.85.
  • Action: invia notifica a Slack e crea ticket in Jira.

5. Best practice per mantenere bassi i falsi positivi

  • Ritoccare il threshold ogni trimestre in base ai nuovi pattern di traffico.
  • Rifare l’addestramento con dati recenti (30‑45 giorni) per catturare cambiamenti di versione.
  • Correlare con log: un alert è più affidabile se accompagnato da un pattern di log specifico (es. ERROR su org.jboss.as).

Conclusione

Filtrare i false positive in WildFly mediante metriche JMX e machine learning consente di ridurre l’alert fatigue, migliorare i KPI di osservabilità e accorpare il MTTR. L’approccio descritto combina la solidità delle metriche native di WildFly con la potenza predittiva dell’AI, offrendo un percorso chiaro per team SRE e sviluppatori Java.

Per approfondire, la documentazione di Lescopr descrive la configurazione passo dopo passo.