PRTG mit Grafana: Dashboards für Geschäftsführer, nicht für Admins

Die PRTG-Weboberfläche ist gut darin, Admins zu zeigen, was gerade brennt. Sie ist schlecht darin, einer Geschäftsführerin zu zeigen, ob die IT diesen Monat ihren Job gemacht hat. Dafür brauchst du ein anderes Werkzeug oben drauf: Grafana. Hier der Praxis-Leitfaden, wie du PRTG-Daten nach Grafana bringst und welche 5 Dashboards in Mittelständlern wirklich angeschaut werden.

PRTG oder Grafana? Wann lohnt sich der Wechsel

„PRTG vs. Grafana" ist eine Frage, die im Mittelstand regelmäßig falsch gestellt wird. Die beiden Tools sind keine direkten Konkurrenten, sie lösen unterschiedliche Probleme. Wer das eine durch das andere ersetzt, verliert in beide Richtungen. Wer beide kombiniert, bekommt das Beste aus zwei Welten.

Wann ein echter Wechsel von PRTG zu Grafana sinnvoll wäre: Wenn die Datenerhebung schon woanders läuft (z.B. Prometheus, Telegraf, Zabbix als Sammler) und PRTG nur noch als Alarmierungs-Layer benutzt wird, ist die Frage berechtigt. In allen anderen Fällen ist die Antwort meistens: nicht ersetzen, sondern kombinieren. PRTG erfasst und alarmiert, Grafana visualisiert für die Empfänger, die mit der PRTG-GUI nichts anfangen können.

Wenn du PRTG sowieso nutzt und nur die Reporting-Sicht für die Geschäftsführung brauchst, ist die in diesem Artikel beschriebene InfluxDB-Bridge in 3 bis 5 Tagen umsetzbar. Wenn du noch gar nichts hast, ist die Frage „PRTG plus Grafana oder Open-Source-Stack" eine eigene Architekturentscheidung. Siehe dazu PRTG zu teuer? 3 Optionen mit Zabbix-Migration im Vergleich.

Warum die PRTG-GUI nicht für Entscheider gemacht ist

PRTG zeigt Sensorlisten, rote und grüne Punkte, Graphen pro Channel. Für einen Admin, der seinen Bestand kennt, ist das die richtige Sicht. Für einen Geschäftsführer ist es Lärm.

Beides ist legitim. Aber beides verlangt eine andere Visualisierung. Wer der Geschäftsführerin die PRTG-GUI zeigt, bekommt die Reaktion: "Ja, sieht beschäftigt aus." Wer ihr ein Grafana-Dashboard mit 3 Kennzahlen zeigt ("Verfügbarkeit Vertriebs-Systeme letzten Monat: 99,87 %", "Internetleitung Auslastung: bei aktuellem Trend Engpass in 14 Monaten", "Ungeplante Downtimes letzten Monat: 2, Auswirkung 41 Min"), bekommt Entscheidungen.

Wie kommen die Daten von PRTG nach Grafana?

Es gibt 3 gängige Architekturen. Welche du wählst, hängt vom Mengengerüst und davon ab, ob du Echtzeit oder historische Auswertungen brauchst.

Variante A: Grafana liest direkt die PRTG-API

Grafana bekommt einen JSON-Datasource (z.B. das Plugin "Infinity" oder "JSON API") und ruft Endpunkte wie /api/historicdata.json ab. Vorteil: keine Zwischendatenbank nötig. Nachteil: PRTG ist nicht für viele parallele Abfragen optimiert. Wenn 5 User gleichzeitig ein Dashboard mit 20 Panels öffnen, schlägt das auf den PRTG-Core zurück.

Geeignet für: kleine Installationen, wenige gleichzeitige Dashboard-User.

Variante B: PRTG schreibt nach InfluxDB, Grafana liest InfluxDB

Hier sitzt eine Zeitreihendatenbank zwischen PRTG und Grafana. PRTG hat eingebaute "Custom Sensor Push to InfluxDB"-Möglichkeiten oder man nutzt einen kleinen Python-Job, der zyklisch via API Daten zieht und in InfluxDB schreibt. Grafana liest dann nur noch aus InfluxDB: schnell, parallel-tauglich, ohne Last auf PRTG.

Geeignet für: Standard-Architektur ab 500 Sensoren oder wenn mehrere Personen Dashboards nutzen.

Variante C: PRTG-Stream-Sensor in InfluxDB

Paessler hat seit Version 23.x einen offiziellen "Stream Sensor", der Werte direkt nach InfluxDB pushen kann. Konfiguration in der Sensor-GUI, kein eigener Job nötig. Funktioniert gut, ist aber pro Stream-Sensor lizenziert.

Geeignet für: dedizierte Streams für besonders wichtige Kennzahlen, ergänzend zu Variante B.

Setup-Skizze: Variante B in 4 Schritten

Die in der Praxis am häufigsten gewählte Architektur. Hier die Kurzfassung. Eine ausführliche Schritt-für-Schritt-Anleitung sprengt den Rahmen, aber das Grundgerüst sieht so aus:

1. InfluxDB aufsetzen

InfluxDB 2.x als Docker-Container oder LXC. Bucket anlegen (prtg_history), API-Token generieren. RAM-Bedarf bei 1.000 Sensoren und 30 Tagen Aufbewahrung: ca. 2 GB.

2. Python-Job, der alle 5 Minuten Daten zieht

Schema: PRTG-API per /api/table.json?content=sensors&columns=objid,sensor,lastvalue,status abfragen, Werte parsen, in InfluxDB schreiben. Tags: device, group, sensor_type. Felder: value, status. Der Job läuft als Cronjob oder systemd-Timer.

import requests, time
from influxdb_client import InfluxDBClient, Point

# PRTG abfragen
r = requests.get(PRTG_URL + "/api/table.json",
    params={"content":"sensors", "columns":"objid,sensor,lastvalue_,status",
            "username":USER, "passhash":HASH})

# Nach Influx schreiben
with InfluxDBClient(url=INFLUX_URL, token=TOKEN, org=ORG) as cli:
    write = cli.write_api()
    for s in r.json()["sensors"]:
        p = (Point("prtg")
             .tag("sensor_id", str(s["objid"]))
             .tag("sensor_name", s["sensor"])
             .field("value", float(s["lastvalue_raw"] or 0))
             .field("status", s["status"]))
        write.write(bucket="prtg_history", record=p)

Den Vollausbau dieses Patterns inkl. Fehlerbehandlung, Re-Auth und Rate-Limiting habe ich in PRTG-API: Sanierung per Python automatisieren dokumentiert.

3. Grafana mit InfluxDB-Datasource verbinden

In Grafana: "Data sources > Add data source > InfluxDB", URL und Token eintragen. Anschließend Test-Query in Grafana Explore: from(bucket:"prtg_history") |> range(start: -1h). Wenn Daten kommen, ist die Pipe komplett.

4. Erstes Dashboard bauen

Empfehlung: nicht versuchen, die PRTG-GUI nachzubauen. Stattdessen auf 3–5 Kennzahlen pro Dashboard fokussieren, jeweils mit Vergleichswert (Vormonat, Vorjahr) und Trendpfeil.

5 Dashboards, die in Mittelständlern wirklich angeschaut werden

Dashboard 1: Geschäftsführer-Cockpit (1 Seite, 5 Zahlen)

• Verfügbarkeit kritischer Systeme letzten Monat (in %)
• Anzahl ungeplanter Downtimes letzten Monat
• Gesamtdauer ungeplanter Downtimes (in Min)
• Trend Internet-Bandbreite (Auslastung Peak vs. Vormonat)
• Aktive kritische Alarme jetzt

Update-Intervall: 5 Minuten reicht völlig. Die GF schaut das einmal pro Woche an, vielleicht zweimal.

Dashboard 2: IT-Leiter-Übersicht

Hier kommen mehr Details rein: SLA-Erreichung pro Standort, Top-10-Devices nach Downtime, Trend bei kritischen Sensoren, Lizenz-Auslastung (aktuelle Sensoranzahl vs. Lizenzlimit). Update-Intervall: 1 Minute. Wird meist als Wandschirm in der IT-Abteilung genutzt.

Dashboard 3: Standort-Vergleich (Multi-Site-Mittelstand)

Eine Reihe pro Standort, Spalten: Internet-Verfügbarkeit, Server-Verfügbarkeit, kritische Alarme jetzt. Sortierung nach "schlechtester Standort oben". Sehr nützlich für Multi-Site-Unternehmen, weil sofort sichtbar wird, wer Aufmerksamkeit braucht.

Dashboard 4: Kapazitäts-Trends (für Budget-Gespräche)

Disk-Auslastung pro Server über 12 Monate, Bandbreiten-Auslastung pro Standort über 12 Monate, RAM-Trend bei kritischen Servern. Mit linearer Regression eingezeichnet, sodass sichtbar wird, wann das Limit erreicht wird. Genau das Dashboard, das man im Budgetgespräch zeigt, wenn man einen neuen Server begründen will.

Dashboard 5: Audit-Ansicht (für externe Prüfer)

Listenform: alle SLA-relevanten Sensoren, ihre Verfügbarkeit über die letzten 12 Monate als Heatmap. Read-only-Link, der an Wirtschaftsprüfer oder Auditoren rausgegeben werden kann. Wer ISO 27001 oder Branchenstandards erfüllen muss, hat damit das Verfügbarkeitsnachweis-Thema in 30 Minuten erledigt.

Was du beim Bau der Dashboards beachten solltest

Nicht jeder PRTG-Wert braucht ein Panel

Der häufigste Fehler: man baut das Grafana-Dashboard so, wie die PRTG-GUI aussieht: jeder Sensor wird zum Panel. Das wiederholt nur das Problem. Stattdessen: vor dem Bau einen Workshop mit dem Adressaten machen ("Welche 3 Fragen willst du dir mit dem Dashboard beantworten können?") und nur die dafür nötigen Werte aufnehmen.

Vergleichswerte sind Pflicht

Eine Zahl ohne Vergleich ist Lärm. Statt "12 Alarme letzten Monat" lieber "12 Alarme letzten Monat (Vormonat: 17, Vorjahr: 9)". Das macht den Unterschied zwischen "interessanter Zahl" und "Entscheidungsgrundlage".

Weniger ist mehr

Maximal 5 Panels pro Geschäftsführer-Dashboard, maximal 12 pro IT-Leiter-Dashboard. Wer 30 Panels auf eine Seite quetscht, hat schon verloren. Das menschliche Auge kann nicht mehr als ~7 Datenpunkte gleichzeitig verarbeiten.

Mobiltauglich denken

Dashboards werden oft auf dem Handy aufgerufen, wenn die GF aus dem Meeting kommt. Grafana hat eine Mobile-View, die aber nur funktioniert, wenn die Panels nicht zu komplex sind. Für die Mobile-Ansicht reicht oft eine reduzierte Variante mit den 3 wichtigsten Zahlen.

Ein Dashboard, das die Geschäftsführerin nicht öffnet, ist ein Backend-Tool mit hübscher Oberfläche.

Wann lohnt sich der Aufwand?

PRTG mit Grafana ist kein Aufwand für jede Installation. Eine grobe Daumenregel:

• Bis 200 Sensoren, eine IT-Person, kein externes Reporting: PRTG-GUI reicht.
• 200–1.000 Sensoren, IT-Team, regelmäßiges Reporting an die Geschäftsführung: Grafana lohnt sich.
• Über 1.000 Sensoren, Multi-Site, Compliance-Anforderungen: Grafana ist Pflicht. Die PRTG-GUI skaliert nicht.

Setup-Aufwand für eine saubere Variante-B-Architektur mit den ersten 2 Dashboards: 3 bis 5 Personentage. Dauerhafter Wartungsaufwand: etwa 2 Stunden pro Monat (Updates, neue Panels, Datenaufbewahrung).

Zusammenfassung

PRTG ist ein gutes Werkzeug für die Erkennung. Grafana ist das richtige Werkzeug für die Kommunikation. Wer beides kombiniert, gibt jedem Empfänger die Sicht, die er braucht: Admins die GUI für die operative Arbeit, Entscheider Grafana-Dashboards mit Kennzahlen, die zu Entscheidungen führen. Die Architektur (InfluxDB als Zeitreihen-Speicher dazwischen) ist erprobt und in einem Mittelständler in 3 bis 5 Tagen umsetzbar.