PRTG-Alternative gesucht? Zabbix, Checkmk, Nagios und Monitoring-Appliances im Vergleich

Warum sucht jemand eine Alternative zu einem Tool, das funktioniert?

Der Anlass ist selten ein Ausfall von PRTG selbst. In den Gesprächen mit Systemhäusern und Admins tauchen vier Auslöser immer wieder auf, und keiner davon ist ein Funktionsmangel.

Der erste ist das Lizenzmodell. PRTG wird nach Sensoren lizenziert, und ein Sensor ist nicht ein Gerät, sondern ein einzelner Messpunkt: eine CPU-Last, ein Switch-Port, ein Ping, ein Laufwerk. Ein Server mit Festplatten, RAID, Diensten und Netzwerkkarte belegt schnell 8-15 Sensoren. Wer wächst, rutscht in die nächste Lizenzstaffel, oft ohne dass sich an der Zahl der Geräte viel geändert hätte. Das ist kein Vorwurf an den Hersteller, das Modell ist transparent dokumentiert. Es passt nur nicht zu jeder Umgebung.

Der zweite Auslöser ist der Betriebsaufwand. Ein Monitoring-Server will selbst gepflegt werden: Updates, Datenbank, Sicherung, Zertifikate, und irgendwann die Frage, wer eigentlich den Server überwacht, der alle anderen überwacht. Klingt nach Kleinkram. Ist es über drei Jahre nicht.

Der dritte Auslöser betrifft vor allem Systemhäuser: viele kleine Kundenstandorte mit je fünf bis zehn Geräten. Eine zentrale Instanz braucht dann VPN oder Remote-Probes zu jedem Standort, und die Sensoren summieren sich über alle Kunden.

Der vierte ist der unscheinbarste: die Berichte. Ein Admin liest Dashboards. Ein Geschäftsführer oder eine Praxisinhaberin liest keinen Graphen mit 40 Kurven, sondern will einen Satz: Ist alles in Ordnung, und wenn nicht, was ist zu tun? Dazu gleich mehr.

Keiner der vier Anlässe ist mit einem Tool-Wechsel allein erledigt. Was Monitoring grundsätzlich leisten sollte, steht im Überblick zu IT-Monitoring für Unternehmen; hier geht es um die Entscheidung zwischen den Werkzeugen.

PRTG, Zabbix, Checkmk und Nagios: Wo liegen Stärken und Grenzen?

Die folgenden Kurzprofile beruhen auf öffentlichen Herstellerangaben, Stand September 2026, ohne Gewähr; alle genannten Marken gehören den jeweiligen Inhabern. Sie sollen einordnen, nicht bewerten: Jedes der vier Werkzeuge hat einen Einsatzbereich, in dem es die bessere Wahl ist.

PRTG Network Monitor von Paessler ist eine kommerzielle Monitoring-Software, die auf einem Windows-Server läuft und Geräte überwiegend agentenlos über SNMP, WMI, SSH und Flow-Protokolle abfragt. Stärken: kurze Einrichtungszeit, automatische Geräteerkennung, Karten und Berichte eingebaut, dazu eine gehostete Variante des Herstellers. Grenzen: Die Lizenzierung nach Sensoren wird bei wachsenden oder verteilten Umgebungen zum Planungsfaktor, und Standorte ohne eigenen Windows-Server brauchen Remote-Probes.

Zabbix ist eine Open-Source-Monitoring-Plattform ohne Lizenzkosten und ohne Sensor- oder Host-Limit (AGPL-Lizenz seit Version 7.0); der Hersteller verdient an Support und Schulungen. Sie arbeitet mit eigenem Agent, prüft aber auch agentenlos über SNMP, IPMI, JMX und HTTP. Stärken: skaliert bis in sehr große Umgebungen, keine Kostensprünge beim Wachstum. Grenzen: Der Betrieb verlangt einen Linux-Server samt Datenbank, die Einarbeitung in Templates, Trigger und Makros braucht Zeit, und Berichte für Nicht-Techniker sind nicht der Schwerpunkt.

Checkmk kommt aus München und existiert in einer kostenlosen Raw Edition (Open Source, mit Nagios-Kern) sowie in kommerziellen Editionen mit eigenem Kern, die nach Anzahl der überwachten Services lizenziert werden. Der eigene Agent liefert mit einem Aufruf sehr viele Messwerte, dazu kommen SNMP und eine große Bibliothek an Check-Plugins. Stärken: regelbasierte Konfiguration, die über hunderte Hosts sauber skaliert, Hersteller und Community im deutschsprachigen Raum. Grenzen: Die Raw Edition ist im Funktionsumfang enger als die bezahlten Editionen, und das Regelwerk will verstanden sein, bevor es entlastet.

Nagios ist der Klassiker: Nagios Core ist Open Source und seit über zwanzig Jahren im Einsatz, Nagios XI die kommerzielle Variante mit Web-Oberfläche und Lizenzierung nach überwachten Knoten. Die Plugin-Architektur ist so verbreitet, dass andere Werkzeuge (darunter Checkmk Raw und Icinga) sie übernommen haben. Stärken: extrem anpassbar, riesiger Fundus an Plugins, geringe Hardware-Anforderungen. Grenzen: Nagios Core wird über Textdateien konfiguriert, Auto-Discovery und Reporting sind ohne Zusatzwerkzeuge schmal, und die Oberfläche wirkt gegenüber jüngeren Produkten älter. Kein Fehler, aber ein Faktor bei der Übergabe an Kollegen.

Welche PRTG-Alternative passt zu welcher Umgebung?

Die Tabelle stellt die vier Werkzeuge einer fünften Option gegenüber, die in Vergleichen oft fehlt: einer Monitoring-Appliance mit festem Prüfumfang oder einem Managed-Angebot, bei dem der Betrieb komplett außer Haus liegt. Beide beantworten die Anlässe zwei bis vier aus dem ersten Abschnitt anders als ein reiner Software-Wechsel.

Lesen Sie die letzte Spalte zuerst. Die Frage ist nicht, welches Werkzeug am meisten kann, sondern welches zu der Person passt, die es in zwei Jahren noch bedient. Ein Systemhaus mit drei Technikern und 40 Kundenstandorten hat ein anderes Problem als ein Mittelständler mit einem Serverraum und einem Admin.

Wer die Software-Optionen tiefer vergleichen will, findet im Beitrag Monitoring-Tools im Vergleich die Detailkriterien; für die reine Netzwerkschicht mit Switches, Firewall und WLAN lohnt der Blick auf Netzwerk-Monitoring. Was eine Appliance mit festem Prüfumfang konkret abdeckt und wo sie gegenüber einer Vollsoftware bewusst weniger bietet, steht in der Gegenüberstellung von dwatcher mit klassischen Monitoring-Tools.

Wann ist ein Wechsel nicht sinnvoll?

Ein Wechsel ist nicht sinnvoll, wenn das eigentliche Problem nicht im Werkzeug liegt, sondern in seiner Pflege. Das ist häufiger, als Vergleichsartikel zugeben.

Erster Fall: zu viele Alarme. Wenn PRTG 300 Meldungen am Tag schickt und niemand mehr hinsieht, ist nicht PRTG das Problem, sondern es sind Schwellenwerte, die seit der Einrichtung niemand angefasst hat. Zabbix oder Checkmk mit denselben Schwellen produzieren dieselbe Flut. Ein Monitoring, dessen Alarme niemand liest, ist Dekoration, egal von welchem Hersteller.

Zweiter Fall: Das Sensor-Limit ist erreicht, aber ein Teil der Sensoren zeigt auf abgeschaltete Geräte, Testsysteme oder doppelte Prüfungen. In gewachsenen Installationen ist dieser Anteil erfahrungsgemäß erheblich. Aufräumen ist billiger als Migrieren.

Dritter Fall: Das Team kennt das Werkzeug. Wer mit PRTG seit fünf Jahren zurechtkommt und die Lizenz im Budget hat, tauscht mit einem Wechsel bekannte Grenzen gegen unbekannte. Wer wechselt, weil das neue Tool mehr kann, wechselt aus dem falschen Grund. Wechseln sollte, wer ein konkretes Problem benennen kann, das das aktuelle Werkzeug strukturell nicht löst: das Lizenzmodell bei 30 Standorten, der fehlende Klartext-Bericht für den Kunden, der Server, den niemand mehr pflegen will.

Vierter Fall, oft übersehen: Systemhäuser, die ohnehin ein RMM-Tool für Patches und Fernwartung betreiben, decken damit Clients und Windows-Server bereits ab. Ob ein zweites Werkzeug für Netzwerkgeräte und NAS nötig ist, zeigt erst das Inventar aus dem nächsten Abschnitt.

Wie läuft ein Wechsel vom Monitoring-Tool ab?

Ein Tool-Wechsel im Monitoring ist ein Projekt von einigen Wochen, nicht ein Wochenende, denn das Wissen steckt nicht in der Software, sondern in den Schwellenwerten und Alarmwegen, die sich über Jahre eingeschliffen haben. Der folgende Ablauf passt für Umgebungen von etwa 5 bis 200 Geräten; in größeren Installationen kommen Phasen je Standort hinzu.

1. Sensor- und Check-Inventar erstellen: Alle aktiven Sensoren oder Checks exportieren, nach Gerät und Prüfart gruppieren und markieren, welche in den letzten 12 Monaten mindestens einen Alarm ausgelöst haben. Was nie ausgelöst hat und niemand vermisst, wird nicht migriert.
2. Anforderungsliste schreiben: Pro Prüfart festhalten, was das neue Werkzeug leisten muss (SNMP-Version, Agent ja oder nein, Alarm per E-Mail oder Ticket, Bericht für wen), und daraus 5-10 Ausschlusskriterien ableiten, an denen ein Kandidat scheitern darf.
3. Zielsystem im Parallelbetrieb aufsetzen: Das neue Werkzeug neben dem alten installieren oder die Appliance anschließen, zunächst mit 10-20 Prozent der Geräte, darunter die kritischsten. Das alte System bleibt in dieser Phase alleiniger Alarmgeber.
4. Alarmregeln übertragen und schärfen: Schwellenwerte, Eskalationsketten und Wartungsfenster aus dem Inventar übernehmen und dabei jede Regel einmal hinterfragen. Alarme des neuen Systems gehen zunächst an ein separates Postfach, nicht an den Bereitschaftsdienst.
5. Vergleichsphase auswerten: 4-8 Wochen lang beide Systeme laufen lassen und wöchentlich abgleichen, welche Störungen nur eines der beiden gemeldet hat. Abweichungen sind fast immer fehlende Checks oder falsche Schwellen, selten Software-Fehler.
6. Altes System abschalten: Erst wenn zwei Wochen ohne unerklärte Abweichung vergangen sind, die Alarmierung auf das neue System umlegen, historische Daten exportieren oder als Archiv sichern, die Lizenz kündigen und den alten Server aus der Überwachung nehmen.

Was kostet ein Wechsel wirklich: Sensoren, Arbeitszeit oder Pauschale?

Die Kosten eines Monitorings bestehen aus drei Posten, die je nach Modell unterschiedlich groß ausfallen: Lizenz, Arbeitszeit für Betrieb und Pflege, und im Störungsfall die Zeit bis zur Erkennung. Vergleichbar sind nur alle drei zusammen, auf drei Jahre gerechnet.

Bei PRTG ist die Lizenz die sichtbare Größe. Sie richtet sich nach der Sensorstaffel, die Sie tatsächlich brauchen, und wird nach Herstellerangaben als Abonnement abgerechnet. Arbeitszeit kommt für den Windows-Server, Updates und die Pflege der Sensoren hinzu.

Bei Zabbix, Checkmk Raw und Nagios Core entfällt die Lizenz, dafür wandert der Aufwand komplett in Arbeitszeit: Einrichtung, Templates, Datenbankpflege, Updates, und die Einarbeitung, die niemand in die Rechnung schreibt. Ein Open-Source-Monitoring ist so günstig wie die Stunden, die jemand dafür übrig hat. Für ein Systemhaus mit Linux-Kompetenz kann das die günstigere Rechnung sein; für ein Unternehmen ohne IT-Abteilung ist es oft die teuerste, weil jede dieser Stunden extern eingekauft wird.

Bei einer Appliance oder einem Managed Monitoring ist die Größe eine Pauschale je Standort oder Box, in der Betrieb, Updates und Berichte enthalten sind. Der Preis ist planbar, der Prüfumfang dafür fest. Wer Spezialchecks für Branchensoftware braucht, kommt damit allein nicht aus.

Pauschal lässt sich das nicht sagen; was gilt, zeigt erst die Bestandsaufnahme mit dem Sensor-Inventar aus Schritt 1. Ein Angebot ohne dieses Inventar ist eine Schätzung.

Wenn Sie klären möchten, welches Modell zu Ihrer Umgebung oder zu Ihren Kundenstandorten passt, können Sie ein unverbindliches Erstgespräch mit Datadiorama vereinbaren.