Wenn eine Ticketregel in GLPI nicht tut, was sie soll, kostet die Diagnose die Administratoren der Umgebung meist Stunden. Das Modul Rule Inspector von NexTool kehrt diese Arbeit um: Statt die Regeln im Regelmanager einzeln zu öffnen, zeigt es direkt im Ticket, welche Ticketregeln ausgewertet wurden, welche einen Match hatten und warum.
Die Ausgangslage
Die Geschäftsregeln für Tickets gehören zu den mächtigsten Funktionen von GLPI: Sie weisen Techniker zu, legen Kategorie und SLA fest, lösen Benachrichtigungen aus und schließen sogar Tickets. Doch wenn etwas nicht funktioniert – ein Ticket, welches ohne Techniker ankam, eine Kategorie, die nicht angewendet wurde, eine SLA, die nie gegriffen hat –, ist die Diagnose Handarbeit. Der Administrator öffnet den Regelmanager, liest Kriterium für Kriterium, prüft die Ausführungsreihenfolge und versucht im Kopf zu rekonstruieren, was in dem Moment geschah, als dieses Ticket einging. In Umgebungen mit Dutzenden oder Hunderten von Regeln, die über Jahre des Betriebs gewachsen sind, wird daraus eine Schatzsuche.
Erschwerend kommt hinzu, dass die Regel, die „nicht gegriffen hat“, fast immer teilweise gegriffen hat. Sie hatte einen Match, unterlag aber einer anderen mit niedrigerem Rang, bei der die Aktion „Verarbeitung weiterer Regeln stoppen“ aktiviert war – und ab diesem Punkt läuft keine nachfolgende Regel mehr. Ohne ein Werkzeug, welches die Auswertung im Kontext des Tickets zeigt, bleibt dieses Detail unbemerkt.
Wie Rule Inspector funktioniert
Nach Installation und Aktivierung des Moduls gibt es in jedem Ticket einen Reiter Rules Inspector. Von dort aus haben Sie:
- Regeln abfragen – ein Klick wertet alle aktiven Ticketregeln in der Einheit des Tickets aus und zeigt, welche angewendet wurden, welche einen Match hatten, aber nicht ausgeführt wurden, und welche an den Kriterien gescheitert sind, mit Details zu jedem ausgewerteten Kriterium.
- Speicherung pro Ticket – Ergebnisse werden im Ticket gespeichert. Beim erneuten Öffnen wird der Button zu „Abfrage wiederholen“ und signalisiert, dass bereits eine frühere Auswertung zum Vergleich vorliegt.
- Test per ID – auf der eigenständigen Seite des Moduls können Sie im Reiter Test eine beliebige Ticketnummer eingeben und sehen, welche Regeln für sie zutreffen, ohne dieses Ticket öffnen zu müssen.
- Nach Einheit gefilterter Verlauf – der Reiter Verlauf listet die 100 jüngsten Auswertungen auf, beschränkt auf die Einheiten, die der Benutzer sehen darf. Es gibt keinen Datenabfluss zwischen Einheiten.
- CSV-Export – Ergebnisse lassen sich als CSV exportieren, mit Regel, ID, Rang, Match-Modus, Status, Score und der Anzahl wahrer, falscher und nicht unterstützter Kriterien sowie den Details jedes Kriteriums (
criteria | condition | value) und der Aktionen – bereit für Audit und Bericht.
Die Abfrage wertet bis zu 1000 aktive Regeln auf einmal aus, sortiert nach Rang; im Reiter des Tickets weist ein Hinweis darauf hin, wenn diese Grenze erreicht ist – relevant in Umgebungen, die im Laufe der Zeit viele Regeln angesammelt haben.
Was GLPI im Hintergrund speichert
Um zu verstehen, warum die manuelle Diagnose so mühsam ist, lohnt sich ein Blick darauf, wie die Regeln in der Datenbank liegen. Die folgende Abfrage listet die aktiven Ticketregeln nach Rang mit ihren Kriterien auf. Führen Sie sie auf einem Lese-Replikat oder in einem Zeitfenster mit geringer Last aus:
-- Regras de ticket ativas, por ranking, com seus criterios.
-- criteria e condition sao codigos numericos, nao texto legivel.
SELECT r.ranking,
r.name AS regra,
rc.criteria AS criterio_cod,
rc.condition AS condicao_cod,
rc.pattern AS valor
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;Schon dieses Ergebnis erklärt den Schmerz: criteria verweist auf ein internes Feld der Regel, und condition ist ein Code (zum Beispiel „ist gleich“, „ist nicht gleich“, „regulärer Ausdruck“). Dies mit bloßem Auge zu lesen erfordert, Tabelle für Tabelle zu dekodieren und zusätzlich mit der Rangfolge abzugleichen. Rule Inspector liefert dieselbe Information bereits dekodiert und – noch wichtiger – gegen ein reales Ticket ausgewertet.
Manuelle Diagnose vs. Rule Inspector
| Kriterium | Manuelle Diagnose in GLPI | Rule Inspector |
|---|---|---|
| Wo Sie untersuchen | Regelmanager, Regel für Regel, oder direkt per SQL | Reiter Rules Inspector direkt im Ticket |
| Kontext | Sie simulieren die Werte des Tickets im Kopf | Auswertung gegen ein reales, auf dem Bildschirm geöffnetes Ticket |
| Lesen der Kriterien | Numerische Codes, die dekodiert werden müssen | Lesbares Format criteria | condition | value |
| Match vs. Ausführung | Schwer voneinander zu unterscheiden | Trennt angewendete, Match ohne Ausführung und gescheiterte Regeln |
| Reihenfolge / Rang | Im Kopf rekonstruieren | Nach Rang ausgewertet, mit Hinweis auf die Grenze |
| Audit | Manueller Export, Fall für Fall | CSV-Export und nach Einheit gefilterter Verlauf |
So aktivieren Sie es
- Installieren Sie das Plugin NexTool in Ihrem GLPI.
- Öffnen Sie Einstellungen > NexTool > Module.
- Aktivieren Sie das Modul Rule Inspector.
- Synchronisieren Sie die Berechtigungen über das Dashboard von NexTool, damit die richtigen Profile den Reiter Rules Inspector im Ticket sehen.
Für wen es geeignet ist – und wann nicht
Rule Inspector richtet sich an alle, die Ticketregeln konfigurieren und betreuen: Administratoren, die eine neue Regel validieren, Qualitätsanalysten, die automatische Zuweisungen prüfen, Service-Desk-Verantwortliche, die untersuchen, warum bestimmte Tickets keine Kategorie oder SLA erhalten, und Teams, die gerade ein Versions-Upgrade hinter sich haben und bestätigen müssen, dass ihre Regeln weiterhin gelten.
Es ist nicht das richtige Werkzeug, wenn Ihre Umgebung keine Ticketregeln verwendet oder wenn die Frage einen anderen Regeltyp von GLPI betrifft – Wörterbücher für Dropdowns, Regeln für den Import von Assets, Rechtezuweisung per LDAP. Dieses Modul konzentriert sich auf alles, was läuft, wenn ein Ticket entsteht oder sich ändert.
Was wir im Betrieb gelernt haben
Im Betrieb von Umgebungen mit vielen Regeln ist ein Ticket, welches „nicht zugewiesen wurde“, fast nie ein Fehler von GLPI: Es liegt an der Rangfolge. Wir haben schon Dutzende Tickets geöffnet, bei denen die richtige Regel absolut korrekt war, aber eine vorherige Regel – niedrigerer Rang, also zuerst ausgewertet – die Aktion zum Stoppen der Verarbeitung hatte und die Kette abschnitt, bevor sie an der Reihe war. Ohne die Auswertung im Kontext des Tickets zu sehen, schwört der Kunde, die Regel sei „verschwunden“, obwohl sie in Wirklichkeit nie die Chance hatte zu laufen. Das zweite wiederkehrende Muster ist die Einheit: Jemand legt die Regel in der untergeordneten Einheit an und glaubt, sie gelte für alle, aber ein Ticket ging über eine andere Einheit ein, und die Regel lag schlicht nicht im Geltungsbereich. Rule Inspector verkürzt diese Diagnose von Stunden auf Sekunden, weil es für genau dieses Ticket zeigt, was einen Match hatte und was blockiert wurde – auch wenn der Schuldige eine „Stopp“-Regel drei Positionen weiter oben ist.
Kompatibilität
- GLPI: 10.x und 11.x
- Plan: FREE
- Plugin: NexTool 6.9.1+
Rule Inspector ist Teil von NexTool, einem modularen Plugin für GLPI. Entdecken Sie die weiteren Module oder sprechen Sie mit unserem Team über eine Demo.
Geprüft vom Team von NexTool Solutions.
