Diagnosticare quali regole sono state applicate a un ticket GLPI con Rule Inspector

Smetti di fare debug delle regole di ticket GLPI aprendole una a una. Il modulo Rule Inspector di NexTool mostra, dentro il ticket stesso, quali regole sono state applicate, quali hanno fatto match senza eseguire e quali hanno fallito - con SQL di riferimento, confronto con il metodo manuale ed esportazione CSV per l'audit.

Quando una regola di ticket in GLPI non fa quello che dovrebbe, la diagnosi consuma spesso ore di chi amministra l'ambiente. Il modulo Rule Inspector di NexTool ribalta questo lavoro: invece di aprire le regole una a una nel gestore, mostra, dentro il ticket stesso, quali regole di ticket sono state valutate, quali hanno fatto match e perché.

Il problema

Le regole di business dei ticket sono tra le funzioni più potenti di GLPI: assegnano tecnici, definiscono categoria e SLA, scatenano notifiche e persino chiudono i ticket. Ma quando qualcosa non funziona - un ticket arrivato senza tecnico, una categoria non applicata, uno SLA che non ha mai attecchito - la diagnosi si fa a mano. L'amministratore apre il gestore delle regole, legge criterio per criterio, verifica l'ordine di esecuzione e prova a ricostruire a memoria cosa è successo nell'istante in cui quel ticket è entrato. In ambienti con decine o centinaia di regole ereditate da anni di operatività, questo diventa una caccia al tesoro.

L'aggravante è che la regola che "non si è applicata" quasi sempre si è applicata parzialmente. Ha fatto match, ma ha perso contro un'altra di ranking inferiore che aveva attiva l'azione "Ferma l'elaborazione delle regole" - e da lì nessuna regola successiva viene eseguita. Senza uno strumento che mostri la valutazione nel contesto del ticket, quel dettaglio passa inosservato.

Come funziona Rule Inspector

Dopo aver installato e attivato il modulo, una scheda Rules compare su ogni ticket. Da lì hai:

  • Valuta regole - un clic valuta tutte le regole di ticket attive nell'entità del ticket e mostra quali sono state applicate, quali hanno fatto match senza eseguire e quali hanno fallito i criteri, con il dettaglio di ogni criterio valutato.
  • Persistenza per ticket - il risultato resta salvato sul ticket. Alla riapertura, il pulsante diventa "Ripeti valutazione", segnalando che esiste già una valutazione precedente da confrontare.
  • Test per ID - nella pagina autonoma del modulo, la scheda Test permette di indicare qualsiasi numero di ticket e vedere quali regole sono vere per esso, senza aprire il ticket.
  • Storico filtrato per entità - la scheda Storico elenca tutte le valutazioni, ristrette alle entità che l'utente può vedere. Nessuna fuga di dati tra entità.
  • Esportazione CSV - lo storico esce in CSV con una colonna di criteri nel formato criteria | condition | value, pronta per audit e report.

La valutazione elabora fino a 1000 regole per volta, ordinate per ranking, con un indicatore visivo quando quel limite viene raggiunto - rilevante negli ambienti che hanno accumulato regole nel tempo.

Cosa conserva GLPI sotto

Per capire perché la diagnosi manuale è penosa, conviene guardare come le regole stanno nel database. La query sotto elenca le regole di ticket attive, per ranking, con i loro criteri. Eseguila su una replica di lettura o in una finestra di basso utilizzo:

-- Regole di ticket attive, per ranking, con i loro criteri.
-- criteria e condition sono codici numerici, non testo leggibile.
SELECT r.ranking,
       r.name              AS regola,
       rc.criteria         AS criterio_cod,
       rc.condition        AS condizione_cod,
       rc.pattern          AS valore
FROM glpi_rules r
JOIN glpi_rulecriterias rc ON rc.rules_id = r.id
WHERE r.sub_type = 'RuleTicket'
  AND r.is_active = 1
ORDER BY r.ranking, rc.id;

Il risultato spiega già il dolore: criteria punta a un campo interno della regola e condition è un codice (per esempio, "è uguale a", "non è uguale a", "espressione regolare"). Leggerlo a occhio nudo richiede di decodificare tabella per tabella e incrociare con l'ordine di ranking. Rule Inspector consegna questa stessa informazione già decodificata e, soprattutto, valutata contro un ticket reale.

Diagnosi manuale vs Rule Inspector

CriterioDiagnosi manuale in GLPIRule Inspector
Dove indaghiGestore delle regole, una a una, o SQL direttoScheda Rules dentro il ticket stesso
ContestoSimuli a mente i valori del ticketValuta contro il ticket reale, aperto a schermo
Lettura dei criteriCodici numerici da decodificareFormato leggibile criteria | condition | value
Match vs esecuzioneDifficile distinguere l'una dall'altraSepara applicate, match senza esecuzione e fallite
Ordine / rankingRicostruire a memoriaValutate per ranking, con il limite segnalato
AuditEsportazione manuale, caso per casoEsportazione CSV e storico filtrato per entità

Come attivarlo

  1. Installa il plugin NexTool sul tuo GLPI.
  2. Vai in Configurazione > NexTool > Moduli.
  3. Attiva il modulo Rule Inspector.
  4. Sincronizza i permessi dal pannello NexTool affinché i profili giusti inizino a vedere la scheda Rules sul ticket.

Per chi è - e quando non usarlo

Rule Inspector è per chi configura e mantiene le regole di ticket: amministratori che validano una regola nuova, analisti di qualità che auditano le assegnazioni automatiche, responsabili di service desk che indagano perché certi ticket non ricevono categoria o SLA, e team appena migrati di versione che devono confermare che le regole valgono ancora.

Non è lo strumento giusto se il tuo ambiente non usa regole di ticket, o se il dubbio riguarda un altro tipo di regola GLPI - dizionari di menu a tendina, regole di importazione asset, assegnazione di diritti via LDAP. Il modulo si concentra su ciò che viene eseguito quando un ticket nasce o cambia.

Cosa abbiamo imparato mantenendolo

Nella manutenzione di ambienti con molte regole, il ticket che "non è stato assegnato" non è quasi mai un bug di GLPI: è ordine di ranking. Abbiamo aperto decine di ticket in cui la regola corretta era perfettamente giusta, ma una regola precedente - ranking inferiore, quindi valutata prima - aveva l'azione di ferma-elaborazione e tagliava la coda prima di arrivarci. Senza vedere la valutazione nel contesto del ticket, il cliente giura che la regola "è sparita", quando in realtà non ha mai avuto la possibilità di eseguire. Il secondo schema ricorrente è l'entità: qualcuno crea la regola sull'entità figlia pensando che valga per tutte, ma il ticket è entrato da un'altra entità e la regola semplicemente non era nell'ambito. Rule Inspector accorcia quella diagnosi da ore a secondi perché mostra, per quel ticket specifico, cosa ha fatto match e cosa è stato bloccato - anche quando il colpevole è una regola di "ferma" tre posizioni più in alto.

Compatibilità

  • GLPI: 10.x e 11.x
  • Piano: FREE
  • Plugin: NexTool 3.x+

Rule Inspector fa parte di NexTool, plugin modulare per GLPI. Scopri gli altri moduli o parla con il team per una dimostrazione.


Questo contenuto è stato prodotto con l'aiuto dell'intelligenza artificiale e revisionato dal team di Nextool Solutions.

Domande Frequenti

Il modulo Rule Inspector di NexTool valuta le regole di ticket attive nell'entità del ticket e mostra, dentro il ticket stesso, quali sono state applicate, quali hanno fatto match senza eseguire e quali hanno fallito i criteri, con il dettaglio di ogni criterio.

Nella maggior parte dei casi la regola ha fatto match, ma una regola di ranking inferiore valutata prima aveva l'azione di ferma-elaborazione e ha tagliato la coda. Un'altra causa comune è l'ambito di entità. Rule Inspector mostra esattamente cosa è stato bloccato per quel ticket.

Sì. La scheda Test accetta qualsiasi ID di ticket e mostra quali regole sono vere per esso, e lo Storico esporta in CSV con i criteri nel formato criteria | condition | value, filtrato per le entità che l'utente può vedere.

Sì. Rule Inspector è un modulo FREE di NexTool, compatibile con GLPI 10.x e 11.x, e richiede il plugin NexTool 3.x o superiore.

Hai bisogno di aiuto?