NexTool Solutions

Grafana liefert nur dann einen Mehrwert, wenn die Dashboards die Fragen derer beantworten, die den Betrieb verantworten, und derer, die entscheiden. Im GLPI- und Infrastruktur-Support, den wir für B2B-Kunden leisten, ist es die Visualisierungsebene, die wir neben dem Service Desk platzieren: Es liest SLA- und Ticket-Kennzahlen direkt aus der GLPI-Datenbank, verknüpft sie mit Verfügbarkeitsreihen aus Zabbix oder Prometheus und stellt alles auf einem Bildschirm dar, den NOC und Führungsebene interpretieren können, ohne Tabellen zu exportieren.

Wie wir Grafana neben GLPI positionieren

Unsere Architektur ist bewusst schlank: ein Grafana-Container auf demselben Host, auf dem GLPI bereits läuft, hinter demselben Reverse Proxy mit TLS, der drei unterschiedliche Datenquellen nutzt. Die erste ist die MariaDB/MySQL von GLPI selbst, mit einem Nur-Lese-Benutzer, für Service-Desk-Kennzahlen (offene Tickets, überschrittene SLAs, durchschnittliche Bearbeitungszeit). Die zweite ist Zabbix oder Prometheus, für Verfügbarkeit und Kapazität der Infrastruktur. Die dritte sind – sofern der Kunde ein NexTool-Plugin einsetzt – die Synchronisierungs- und Integrationskennzahlen, die dieses Ökosystem bereitstellt.

Der typische Fehler bei Teams, die so etwas allein aufbauen: Grafana mit dem Administrator-Benutzer von GLPI zu verbinden. Wir tun dies nie. Ein Dashboard muss nur lesen, und eine kompromittierte Datenquelle darf nicht zum Schreibzugang auf die Produktionsdatenbank werden. Wir legen einen dedizierten Benutzer mit SELECT, beschränkt auf die relevanten Tabellen, an, und Grafana erhält nie mehr Berechtigungen, als es zum Zeichnen eines Diagramms braucht.

Artefakt: Read-only-Benutzer und Datenquelle

Dieses Paar richten wir bei jeder Einführung ein. Zuerst den Lesebenutzer in der GLPI-Datenbank, mit minimalen Rechten:

-- read-only user for Grafana to read GLPI
CREATE USER 'grafana_ro'@'%' IDENTIFIED BY '${STRONG_PASSWORD}';
GRANT SELECT ON glpi.glpi_tickets           TO 'grafana_ro'@'%';
GRANT SELECT ON glpi.glpi_slas              TO 'grafana_ro'@'%';
GRANT SELECT ON glpi.glpi_tickets_users     TO 'grafana_ro'@'%';
GRANT SELECT ON glpi.glpi_itilcategories    TO 'grafana_ro'@'%';
FLUSH PRIVILEGES;
-- no GRANT ALL: the panel only draws, it never writes

Und die Bereitstellung der Datenquelle per Datei, damit ein Dashboard versioniert mit dem Container startet und nicht von manuellen Klicks in der Oberfläche abhängt:

# /etc/grafana/provisioning/datasources/glpi.yaml
apiVersion: 1
datasources:
  - name: GLPI (read-only)
    type: mysql
    access: proxy
    url: glpidb:3306
    database: glpi
    user: grafana_ro
    secureJsonData:
      password: ${STRONG_PASSWORD}   # injected via environment variable
    jsonData:
      maxOpenConns: 5                # does not choke the production database
      timeInterval: "1m"

Echte Abfrage: überschrittene SLAs nach Kategorie

Ein Management-Dashboard, welches wir immer liefern, zeigt Tickets mit abgelaufenem Lösungs-SLA, gruppiert nach Kategorie. Diese Ansicht öffnet die Führungsebene am Montag. Die Abfrage läuft direkt auf GLPI und hält sich an ein Zeitreihenformat, wie es Grafana erwartet:

SELECT
  c.completename                             AS category,
  COUNT(*)                                   AS breached_tickets
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.status NOT IN (5, 6)                 -- excludes solved and closed
  AND t.time_to_resolve IS NOT NULL
  AND t.time_to_resolve < NOW()             -- resolution deadline already passed
  AND t.is_deleted = 0
GROUP BY c.completename
ORDER BY breached_tickets DESC;

Ein Detail, welches nur kennt, wer GLPI betreibt: Die Status 5 und 6 bedeuten im Standardschema gelöst und geschlossen, und is_deleted = 0 ist Pflicht, weil GLPI logisch löscht – wer diese Spalte ignoriert, bläht die Zahl mit Tickets auf, die bereits im Papierkorb liegen. Im Support haben wir schon erlebt, dass ein Dashboard eines Drittanbieters doppelt so viele SLA-Überschreitungen meldete, nur weil is_deleted vergessen wurde. Genau solche Fehler untergraben das Vertrauen des Managements in ein ganzes Dashboard.

Dashboard pro Zielgruppe: was wir trennen

Wir mischen NOC und Geschäftsleitung nicht auf einem Bildschirm. Der Betrieb braucht Granularität, um sofort zu handeln; das Management braucht Trends, um zu entscheiden. Diese Trennung haben wir standardisiert:

Alarme: wo auslösen, ohne zu doppeln

Unsere Regel ist einfach und verhindert das schlimmste Observability-Problem: ein Ereignis, welches über zwei Wege alarmiert. Verfügbarkeit und Kapazität der Infrastruktur alarmieren an der Quelle (Zabbix oder Prometheus), die bereits Historie und Kontext des Hosts hat. Grafana alarmiert nur bei Geschäftskennzahlen, die erst durch die Verknüpfung der Quellen entstehen – etwa wenn ein SLA eines bestimmten Vertrags kurz vor der Überschreitung steht. Jedes Dashboard, welches wir liefern, enthält in der Beschreibung die Definition der Kennzahl und die erwartete Aktion bei Abweichungen. Ein Dashboard ohne diese Dokumentation wird zur Dekoration, und Dekoration schaut sich niemand an.

Ein weiterer Support-Punkt: Wir begrenzen maxOpenConns in der Datenquelle, weil ein Management-Dashboard mit aggressivem Refresh und mehreren schweren Abfragen zu viele Verbindungen öffnen und mit dem produktiven GLPI konkurrieren kann. Wir haben schon langsame Tickets behoben, die ein Team GLPI zuschrieb, deren Ursache aber ein falsch konfiguriertes Grafana war, welches den Verbindungspool der Datenbank leersaugte.

Setzt ein Kunde ein NexTool-Plugin ein, zeigen wir im selben Dashboard zusätzlich die Synchronisierungskennzahlen der Module – Integrationsstatus, Webhook-Warteschlangen und Zustand der Jobs –, sodass Service-Desk-Betrieb und Zustand des Ökosystems in einer Ansicht liegen, ohne Werkzeugwechsel.

Wenn Ihr GLPI-Betrieb noch darauf angewiesen ist, Tabellen zu exportieren, um den SLA-Stand zu kennen, führt NexTool diese Observability-Ebene neben Ihrem Service Desk ein und betreut sie, mit Dashboards, die bereits in GLPI und Infrastruktur integriert sind. Sprechen Sie mit uns über GLPI-Support mit integrierter Observability.

Geprüft vom Team von NexTool Solutions.