Von PRTG zu Zabbix migrieren: Was du vorher wissen musst
Du hast dich entschieden: weg von PRTG, hin zu Zabbix. Die Lizenzkosten sind der Auslöser, die Community und Skalierbarkeit von Zabbix der Anreiz. Aber bevor du anfängst: ein paar Dinge, die in den meisten "PRTG vs. Zabbix"-Artikeln fehlen, weil sie erst in der Praxis sichtbar werden.
Die Konzept-Übersetzung: PRTG-Begriffe in Zabbix-Begriffe
PRTG und Zabbix verwenden unterschiedliche Begriffe für vergleichbare Konzepte. Das klingt trivial, sorgt aber in der Praxis für Verwirrung, weil die Begriffe nicht 1:1 deckungsgleich sind:
| PRTG-Konzept | Zabbix-Äquivalent | Migrierbarkeit |
|---|---|---|
| Sensor | Item (+ Trigger) | Teilweise |
| Device | Host | Direkt |
| Group | Host Group | Direkt |
| Probe / Remote Probe | Zabbix Proxy | Konzeptionell ähnlich |
| Channel (innerhalb eines Sensors) | Mehrere separate Items | Muss aufgeteilt werden |
| Notification Template | Action + Media Type | Komplett neu |
| Map | Map (anderes Konzept) | Komplett neu |
| Auto-Discovery | Network Discovery / LLD | Konzeptionell anders |
| Sensor Factory | Calculated Item | Manuell umsetzen |
| Dependency (Parent/Child) | Trigger Dependency | Manuell nachbauen |
| Custom EXE/Script Sensor | UserParameter / External Check | Neu implementieren |
| Tags | Tags | Direkt |
Faustregel: Alles, was in PRTG "Konfiguration" ist (Hosts, Groups, Tags), lässt sich relativ leicht migrieren. Alles, was "Logik" ist (Notifications, Dependencies, Custom Sensors, Maps), muss komplett neu gebaut werden.
Was sich einfach überträgt
Hosts und Gruppen
Die Geräte-Struktur (Devices mit IPs, Gruppen-Zuordnung) kannst du 1:1 mitnehmen. Zabbix hat eine Import-Funktion für Hosts per XML/JSON und du kannst dir per PRTG-API-Export eine Host-Liste generieren, die du mit einem Script in Zabbix-Format umwandelst. Das spart am meisten Zeit.
Standard-SNMP-Monitoring
Wenn du in PRTG Standard-SNMP-Sensoren für Switches und Router nutzt, findest du in Zabbix fertige Templates für praktisch jeden gängigen Hersteller (Cisco, HP/Aruba, Juniper, etc.). Oft sind die Zabbix-Templates sogar detaillierter als PRTGs Standard-Sensoren.
Ping und HTTP-Checks
Trivial. Zabbix hat Simple Checks für ICMP Ping und HTTP/HTTPS, die sofort funktionieren. Kein Konfigurationsaufwand.
Windows-Server via WMI/SNMP
PRTG nutzt für Windows-Server-Monitoring unter anderem WMI. Zabbix kann WMI ebenfalls per Zabbix Agent oder WMI-Items, aber der bevorzugte Weg ist der Zabbix Agent (klein, ressourcenschonend, muss auf dem Windows-Server installiert werden). Für die meisten Standard-Metriken (CPU, RAM, Disk, Services) gibt es fertige Templates. Die Migration erfordert allerdings Agent-Rollout auf allen Windows-Servern.
Was komplett neu gebaut werden muss
Custom EXE/Script Sensoren
In PRTG schreibst du ein Skript (PowerShell, Python, VBS), das einen Rückgabewert liefert und PRTG macht daraus einen Sensor. In Zabbix gibt es ein ähnliches Konzept (UserParameter), aber die Syntax und Rückgabe-Formate sind anders.
Konsequenz: Jedes Custom Script muss angepasst werden. Die Logik bleibt meist gleich, aber die Wrapper-Schicht (wie das Script aufgerufen wird und wie es antwortet) ändert sich. Bei 5 Custom Sensors ist das ein halber Tag Arbeit. Bei 30 können es 3-5 Tage werden.
Notification-System
In PRTG konfigurierst du Notifications relativ bequem: wer wird benachrichtigt, bei welchem Zustand, mit welcher Eskalation, zu welcher Uhrzeit. In Zabbix läuft das über 3 separate Konzepte:
- Trigger: definiert, wann ein Problem vorliegt (z.B. "CPU > 90% seit 5 Minuten")
- Action: definiert, was bei welchem Trigger-Severity passiert
- Media Type: definiert den Kanal (E-Mail, Slack, SMS, Webhook)
Funktionell ist Zabbix sogar mächtiger (Conditions, Recovery-Messages, Escalation Steps). Aber die Einrichtung ist aufwendiger. Plane für die Nachbildung deines Notification-Setups 1-2 volle Tage ein.
Maps und Dashboards
PRTGs Maps nutzen ein proprietäres Format (im Browser als HTML gerendert), Zabbix-Maps sind SVG-basiert. Es gibt keinen Import-Weg. Jede Map wird von Grund auf neu gebaut. Wenn du ehrlich bist: die meisten Maps in PRTG sind sowieso veraltet (siehe Altlasten-Artikel). Die Migration ist ein guter Anlass, nur die Maps nachzubauen, die tatsächlich genutzt werden.
Alternative: Statt Zabbix-native-Maps kannst du Grafana als Dashboard-Schicht verwenden. Grafana hat eine offizielle Zabbix-Datasource und bietet deutlich modernere Visualisierungen als beide nativen Map-Editoren.
Die 4 Stolpersteine, die fast jede Migration hat
1. Parallelbetrieb wird unterschätzt
Du wirst PRTG nicht an Tag 1 abschalten. Realistisch läuft ein Parallelbetrieb von 2-4 Wochen, in denen du jedes System in beiden Tools überwachst und vergleichst, ob Zabbix die gleichen Alarme wirft wie PRTG. In dieser Phase steigt der Admin-Aufwand auf das Doppelte. Das muss eingeplant werden.
2. SNMP-Fallen bei Switches
PRTG pollt SNMP mit eigenen OID-Sets und hat pro Hersteller eingebaute Logik. Zabbix nutzt Community-Templates, die teils andere OIDs verwenden. Ergebnis: gleicher Switch, andere Werte, andere Schwellwerte, andere Alarme. Du musst die Templates nach der Migration validieren, nicht nur aktivieren.
3. Agent-Rollout auf Windows
PRTG braucht keinen Agenten auf den Ziel-Servern (es nutzt WMI/SNMP von einem zentralen Punkt). Zabbix funktioniert zwar auch ohne Agent, liefert aber mit Agent deutlich bessere Daten. Das bedeutet: du musst den Zabbix Agent auf allen Windows- und Linux-Servern installieren. Bei 50 Servern ist das ein halber Tag mit GPO oder Ansible. Bei 500 Servern ist es ein eigenes Projekt.
4. Das Team muss umlernen
Dieser Punkt wird in technischen Artikeln fast nie erwähnt, ist aber in der Praxis der schmerzhafteste: Dein Admin-Team kennt PRTG seit Jahren. Die Oberfläche, die Shortcuts, die Klick-Wege. In Zabbix ist alles anders. Nicht schlechter, aber anders. Es dauert 2-4 Wochen, bis ein erfahrener PRTG-Admin in Zabbix mit der gleichen Geschwindigkeit arbeitet wie vorher.
Das muss beim Projektplan berücksichtigt werden: In der Übergangszeit sinkt die Reaktionsgeschwindigkeit auf Alarme, weil die Admins erstmal suchen, wo was ist. Mach die Umstellung nicht während einer kritischen Phase (Releases, Audit-Zeitraum, Hochlast-Zeiten).
Migrations-Checkliste
Wenn du dich für die Vollmigration entschieden hast, hier eine Checkliste für die Reihenfolge:
- Inventur der PRTG-Umgebung: Wie viele Hosts, Sensoren, Custom Scripts, Notification-Regeln, Maps? Was davon ist aktiv, was Ballast?
- Zabbix-Server aufsetzen (Debian/Ubuntu + PostgreSQL, offizielle Doku folgen)
- Standard-Templates laden: OS-Templates (Windows, Linux), Netzwerk-Templates (per Hersteller) aus dem Zabbix-Template-Katalog
- Hosts importieren: Export aus PRTG-API, Transformation, Import in Zabbix (oder manuell bei weniger als 30 Hosts)
- Agent-Rollout: Zabbix Agent auf allen Ziel-Servern installieren
- Custom Scripts migrieren: EXE/Script-Sensoren als UserParameter nachbauen
- Notification-System aufsetzen: Trigger Severities definieren, Actions konfigurieren, Media Types einrichten
- Dependencies nachbauen: Trigger Dependencies für korrekte Alarm-Kaskadierung
- Dashboards/Maps: Nur die nachbauen, die tatsächlich genutzt werden (via Grafana oder nativ)
- Parallelbetrieb starten: 2-4 Wochen beide Systeme laufen lassen, Alarme vergleichen
- Validierung: Stimmen die Schwellwerte? Kommen die gleichen Alarme? Fehlt etwas?
- PRTG abschalten: Erst wenn 2 Wochen keine Diskrepanzen aufgetreten sind
Bevor du loslegst: PRTG-Inventur als Audit
Schritt 1 der Checkliste ist der wichtigste. Ohne eine saubere Inventur deiner aktuellen Umgebung weißt du nicht, wie groß das Migrationsprojekt wirklich wird. Mein PRTG-Audit-Paket liefert dir diese Inventur als Festpreis-Service: du bekommst eine vollständige Bestandsaufnahme mit priorisiertem Maßnahmenkatalog. Daraus wird sofort klar, ob eine Migration sinnvoll ist und wie groß sie wird.
Für die Zielseite: Zabbix Experte für NRW, RLP und Rhein-Main — Einführung, Migration und Template-Hygiene.
Ehrliche Empfehlung
PRTG ist ein gutes Tool. Zabbix ist ein gutes Tool. Die Entscheidung zwischen beiden ist keine Glaubensfrage, sondern eine Kosten-Nutzen-Rechnung, die von deiner Umgebungsgröße, dem Know-how im Team und dem Budget abhängt.
Wenn du unter 1.000 Sensoren bist und dein Team PRTG kennt: bleib bei PRTG und optimiere die Kosten. Wenn du über 2.500 Sensoren bist und die Rechnung jedes Jahr wächst: eine Migration lohnt sich mittelfristig, aber plane sie als Projekt, nicht als Wochenend-Aktion.
Und falls du unsicher bist: fang mit einer ehrlichen Inventur an. Die Zahlen sagen dir mehr als jede Meinung.