NexTool Solutions

GLPI speichert die gesamte Historie des Service Desk, doch die nativen Berichte enden genau dort, wo die Leitung anfängt, nach dem "Warum" zu fragen. Metabase und Grafana lesen dieselbe MariaDB-Datenbank von GLPI und machen aus dieser Historie Dashboards - nur lösen sie unterschiedliche Probleme, und eine falsche Wahl kostet Nacharbeit.

Was sich ändert, wenn Sie ein BI an GLPI anbinden

Bevor wir beide Tools vergleichen, muss klar sein: Die GLPI-Datenbank wurde nicht für BI entworfen. Drei Details bestimmen den Großteil der Arbeit an jedem Dashboard, ob in Metabase oder in Grafana:

• Status, Priorität und Dringlichkeit sind Zahlen, kein Text. In glpi_tickets reicht die Spalte status von 1 (Neu) bis 6 (Geschlossen). Kein Tool weiß dies von selbst - übersetzen Sie die Codes nicht, sieht die Leitung "Status 2" im Diagramm.
• Nichts wird wirklich gelöscht. GLPI nutzt logisches Löschen: is_deleted = 1 markiert einen Datensatz als "im Papierkorb". Wer den Filter is_deleted = 0 vergisst, bläht alle Zählungen auf.
• Es ist mandantenfähig. Die Spalte entities_id trennt die Daten nach Kunde oder Bereich. Ein Dashboard, welches der Kunde sehen soll, muss den richtigen Teilbaum der Einheiten filtern - und dies gibt es in reinem SQL nicht umsonst.

Hinzu kommt ein vierter, rein operativer Punkt: Das BI direkt auf die Produktionsdatenbank zu richten, während der Geschäftszeiten, mit Abfragen, die glpi_tickets komplett zusammen mit glpi_logs durchsuchen, ist der schnellste Weg, GLPI selbst auszubremsen. Darauf kommen wir weiter unten zurück.

Direkter Vergleich

So verbinden Sie, ohne GLPI lahmzulegen

Unabhängig vom Tool ist die Verbindung dieselbe: ein Datenbankbenutzer nur mit Leserechten, idealerweise auf ein Replikat oder eine nachts wiederhergestellte Kopie gerichtet, niemals auf den Produktions-Master mit Schreibrechten.

-- Usuario so-leitura para o BI (rode no MariaDB/MySQL do GLPI).
-- Aponte, de preferencia, para uma replica ou copia restaurada,
-- nunca para o master de producao com permissao de escrita.
CREATE USER 'bi_ro'@'10.0.0.%' IDENTIFIED BY '${SENHA_FORTE}';
GRANT SELECT ON glpi.* TO 'bi_ro'@'10.0.0.%';
FLUSH PRIVILEGES;

Steht der Zugang, ist eine Abfrage, welche die Statuscodes übersetzt, als erstes Artefakt die Lösung für die "rohen Zahlen". Sie gilt für beide: In Metabase wird sie zu einer "SQL-Frage", in Grafana zu einem Tabellen- oder Balken-Panel.

-- Chamados abertos por status, com os codigos traduzidos.
-- No GLPI, glpi_tickets.status vai de 1 a 6.
SELECT
  CASE status
    WHEN 1 THEN 'Novo'
    WHEN 2 THEN 'Em atendimento (atribuido)'
    WHEN 3 THEN 'Em atendimento (planejado)'
    WHEN 4 THEN 'Pendente'
    WHEN 5 THEN 'Solucionado'
    WHEN 6 THEN 'Fechado'
  END AS situacao,
  COUNT(*) AS total
FROM glpi_tickets
WHERE is_deleted = 0          -- ignora a lixeira (exclusao logica)
  AND status IN (1, 2, 3, 4)  -- so os que ainda estao abertos
GROUP BY status
ORDER BY status;

In Metabase gibt es eine Abkürzung: Statt des CASE lassen sich die Werte der Spalte direkt in den Feldeinstellungen abbilden (1 auf "Neu", 2 auf "In Bearbeitung" und so weiter), und die Bezeichnung erscheint automatisch in jedem Diagramm. Ein Produktivitätsgewinn, den Grafana nicht bietet - dort ist CASE Pflicht.

Grafana: Dashboard as Code

Der Vorteil von Grafana für alle, die viele Umgebungen betreiben, zeigt sich nicht auf dem Bildschirm, sondern auf der Festplatte: Datenquelle und Dashboards sind versionierbare Dateien. Wir provisionieren dasselbe Dashboard bei mehreren Kunden aus einer YAML- und einer JSON-Datei in Git, ohne irgendetwas anzuklicken.

# /etc/grafana/provisioning/datasources/glpi.yaml
# Fonte de dados versionavel: o mesmo arquivo provisiona N ambientes.
apiVersion: 1
datasources:
  - name: GLPI-MariaDB
    type: mysql
    access: proxy
    url: mariadb.interno:3306
    database: glpi
    user: bi_ro
    jsonData:
      maxOpenConns: 5             # limite as conexoes: nao sufoque o GLPI
      timezone: America/Sao_Paulo
    secureJsonData:
      password: ${GLPI_BI_PASSWORD}

Der andere Unterschied ist die Zeit. Grafana versteht Zeitreihen nativ: Mit den Makros $__timeFilter und $__timeGroup steuern die Zeitraumauswahl und der Auto-Refresh oben im Bildschirm die Abfrage, und eine Template-Variable wird zu einem dynamischen Filter nach Einheit.

-- Painel de serie temporal: as macros ligam o seletor de periodo do topo.
SELECT
  $__timeGroup(date, '1d') AS time,    -- agrupa por dia
  COUNT(*)                 AS abertos
FROM glpi_tickets
WHERE is_deleted = 0
  AND entities_id IN (${entidade})      -- variavel de template (filtro por cliente)
  AND $__timeFilter(date)               -- respeita o intervalo escolhido na tela
GROUP BY 1
ORDER BY 1;

-- Consulta que alimenta a variavel de template "entidade":
SELECT name AS __text, id AS __value
FROM glpi_entities
ORDER BY completename;

Der Trade-off, der sich im Betrieb zeigt

Im Betrieb von GLPI-Landschaften für Kunden ist die Entscheidung selten technisch - es geht darum, wer auf ein Dashboard schaut. Der häufigste Fehler, den wir korrigieren, ist immer derselbe: Jemand wählt Grafana, weil es "mächtiger ist", baut ein tadelloses operatives Dashboard, und drei Monate später verlangt der Direktor einen monatlichen Bericht über Tickets nach Kategorie mit Export für den Kunden. In Grafana ist dies mühsam: Es wurde für Live-Metriken gebaut, nicht dafür, dass die Leitung navigiert und Tabellen exportiert. Dann kommt Metabase dazu, und die Umgebung hat zwei BIs zu pflegen.

Ein Detail, welches erst im Betrieb auffällt, ist die Trennung nach Kunden. In einer Beratung, die mehrere Kunden im selben GLPI (oder in getrennten GLPIs) betreut, müssen Sie sicherstellen, dass ein Dashboard von Kunde A niemals ein Ticket von Kunde B zeigt. In Metabase ist echtes Row-Level Security - Sandboxing pro Benutzer - eine kostenpflichtige Funktion; in der kostenlosen Version bleibt nur, pro Kunde eine Frage mit fester entities_id im WHERE anzulegen, was den Wartungsaufwand vervielfacht. In Grafana lösen wir es mit einer an die Einheiten gebundenen Template-Variable, aber die Kontrolle, wer was sieht, bleibt in Ihrer Hand. Es gibt keine kostenlose Abkürzung für Mandantenisolation - wir entscheiden von Fall zu Fall, und im Zweifel trennen wir nach Instanz, nicht nach Abfrage.

Empfehlung je Szenario

Wählen Sie Metabase, wenn die Zielgruppe Leitung, Kunde oder Analysten ohne SQL-Kenntnisse sind. Die Lernkurve ist flach, Berichte sind navigierbar und exportierbar, und die visuelle Abbildung der Status löst die "rohen Zahlen", ohne CASE zu schreiben. Es ist ein ideales Werkzeug, um Daten des Service Desk zu Menschen zu bringen, die kein Terminal öffnen.

Wählen Sie Grafana, wenn ein Dashboard operativ und live sein soll - Warteschlange je Gruppe, gefährdete SLAs, Tickets pro Stunde - für Technikteam oder NOC. Time Picker, Auto-Refresh, Mehrkanal-Alarme und Provisioning as Code sind echte Vorteile, die Metabase nicht gut abdeckt.

Nutzen Sie beide, wenn dasselbe GLPI unterschiedliche Zielgruppen bedient: Grafana an der Wand des Betriebs, Metabase in der Hand von Leitung und Kunde. Dies ist üblich und funktioniert, aber nehmen Sie die Kosten für zwei BIs bewusst in Kauf - wählen Sie diesen Weg nicht "zur Sicherheit".

Kosten und Aufwand

Die Lizenz ist nicht die Achse der Entscheidung: Beide haben eine kostenlose Open-Source-Version, die für GLPI-Dashboards ausreicht, und kostenpflichtige Pläne (Metabase Pro/Enterprise, Grafana Enterprise) kommen nur bei Skalierungs- oder Governance-Szenarien ins Spiel. Die echten Kosten liegen in der Modellierung. Schwierig ist nicht die Installation - sondern die Kenntnis des GLPI-Schemas: Status und Prioritäten abbilden, an is_deleted denken, den Einheitenbaum auflösen und die Produktion nicht belasten. Als ehrliche Spanne: Eine Handvoll operativer Dashboards in Grafana steht an einem Nachmittag; ein Satz gut modellierter Managementberichte in Metabase, mit Filtern nach Kunde und übersetzten Status, braucht meist zwei bis vier Arbeitstage, bis er verlässlich ist. Welche Kennzahlen in welches Dashboard gehören, zeigt unser Leitfaden zu KPIs für den Service Desk in GLPI.

Bei NexTool implementieren wir Metabase und Grafana auf dem GLPI von Kunden an beiden Fronten - Managementbericht und operatives Dashboard - immer mit Nur-Lese-Benutzer und ohne die Produktion lahmzulegen. Wenn Sie die richtigen Dashboards für die richtige Zielgruppe wollen, ohne Geisel eines unpassenden BI zu werden, entwirft unsere Beratung diese Kennzahlenebene von Anfang bis Ende.

Geprüft vom Team der NexTool Solutions.