Selbst gehostete Alternativen zu PRTG und SolarWinds für das Monitoring von Windows-Netzwerken

PRTG rechnet pro Sensor ab, also pro überwachter Metrik auf einem Gerät, nicht pro Gerät. Paesslers eigene Stufen setzen das praktische Verhältnis auf etwa zehn zu eins: 500 Sensoren decken rund 50 Geräte ab, 10.000 rund 1.000. Kommt ein Switch-Stack hinzu und Sie beginnen, den Durchsatz pro Port zu beobachten, wächst der Zähler schneller als der Bestand. SolarWinds zählt anders und landet am selben Punkt.

Für ein Windows-lastiges Netzwerk würde ich zwei selbst gehostete Alternativen zu PRTG und SolarWinds in die engere Wahl nehmen: Zabbix, oder einen Prometheus-basierten Stack, falls Ihr Team bereits einen betreibt. Die Entscheidung hängt davon ab, was jede Lösung auf einem Windows-Host sehen kann und was sie dafür braucht.

Ein Vorbehalt vorweg. Wenn niemand im Team freie Stunden hat, bleiben PRTG und SolarWinds die richtige Antwort. Ihre Bedienbarkeit ist ein Produkt, das Sie bewusst kaufen, und sie ist ihr Geld wert. Der hier beschriebene Wechsel gibt Stunden statt Lizenzgebühren aus, und das ist ein Tausch, kein Upgrade.

Kurzfassung

• Der Standard ist Zabbix. Zabbix vereint SNMP-Abfragen, Windows-Agenten, Templates und Alarmierung in einer Monitoring-Plattform. Sie betreiben weiterhin Zabbix-Server, Datenbank und Web-Frontend, aber Sie setzen nicht erst separate Monitoring-Komponenten zusammen, um überhaupt loszulegen.
• Die Ausnahme ist ein Team, das bereits Grafana und Prometheus betreibt für Anwendungs- und Host-Metriken. Etwas zu erweitern, das Sie ohnehin pflegen, ist günstiger, als ein zweites Monitoring-System aufzubauen.
• Prometheus fragt Netzwerkgeräte nicht von sich aus ab. snmp_exporter schließt diese Lücke; die Standardkonfiguration deckt viele gängige Switches und Router ab, während herstellerspezifische Objekte oder angepasste Abfragen den Generator und zusätzliche MIB-Arbeit erfordern können.
• Agentenlose Erfassung sieht nur, was ein Host oder Gerät freiwillig veröffentlicht. In Zabbix sind Windows-Ereignisprotokolle, Dienststatus und detaillierte Leistungsindikatoren Item-Keys des Agenten.
• Dimensionieren Sie den Server nach Metriken, nicht nach Geräten. Zabbix zählt eine Metrik als ein Item plus einen Trigger plus einen Graphen und rechnet mit rund 1.000 Metriken auf 2 CPU-Kernen und 8 GiB Arbeitsspeicher, rund 10.000 auf 4 Kernen und 16 GiB.

Wofür PRTG und SolarWinds Geld verlangen

Paessler publishes its PRTG tiers publicly, priced by sensor count and billed annually, starting from a few hundred dollars a month as of September 2026. Check the current figures yourself before budgeting. There is no perpetual-licence option in the current lineup. The freeware edition stops at 100 sensors, which Paessler describes as roughly 10 devices.

SolarWinds zählt eine andere Einheit, und die Regel übersieht man leicht, bis das Verlängerungsangebot kommt. Das NPM-Lizenzmodell von SolarWinds legt fest, dass NPM „nach der größten Anzahl der folgenden Typen überwachter Netzwerkelemente lizenziert wird: Nodes, Interfaces, Volumes“. Nicht die Summe. Der größte der drei Werte. Ein Netzwerk mit 80 Nodes und 900 überwachten Switch-Ports wird auf die 900 lizenziert, nicht auf die 80, und die Stufen reichen von SL100 bis SLX. Eine einzelne Polling-Engine ist unabhängig von der Stufe bei 12.000 Elementen gedeckelt (die Summe aus Nodes, Interfaces und Volumes, nicht der größte Wert), danach kommt eine weitere lizenzierte Polling-Engine hinzu.

Der praktische Effekt beider Modelle ist derselbe. Die Lizenzstufe entscheidet, was überwacht wird. Nicht das Netzwerk. Schnittstellen, die Sie gern beobachten würden, bleiben unbeobachtet, weil das eine Grenze überschreiten würde, und diese Kosten tauchen nie auf der Rechnung auf.

Die zwei selbst gehosteten Wege, die sich lohnen

Zabbix ist eine einzelne Monitoring-Plattform rund um einen zentralen Server, eine Datenbank und ein Web-Frontend. Der Server fragt SNMP-Geräte ab, empfängt Daten von Windows-Agenten und wendet Templates, Trigger und Alarmierung im selben Produkt an. Verglichen mit dem Zusammensetzen eines Prometheus-basierten Netzwerk-Monitoring-Stacks gibt es weniger separate Komponenten, die Sie selbst integrieren müssen. Sie installieren es, richten es auf Hosts und hängen Templates an, also wiederverwendbare Bündel aus Items, Triggern und Graphen für eine Geräteklasse.

Fangen Sie bei der Lizenz an. Die Lizenzseite von Zabbix besagt, dass jede Version ab 7.0 unter der GNU Affero General Public License Version 3 erscheint und alles bis 6.4 unter GPLv2 stand. Für die Software fallen in keiner Größenordnung Lizenzgebühren an. Zabbix verkauft technischen Support als separates optionales Abonnement und bittet kommerzielle Nutzer, eine Stufe davon zu kaufen, aber nichts im Produkt ist hinter diesem Kauf verschlossen.

Der zweite Weg ist Grafana, Prometheus und VictoriaMetrics. Er ist in genau einer Situation die richtige Wahl: Sie betreiben diesen Stack bereits für Anwendungs- und Host-Metriken, und jemand pflegt ihn bereits. Wenn das auf Sie zutrifft, ist der komplette Aufbau auf einem einzelnen VPS ein gelöstes Problem, und Sie erweitern etwas Vertrautes. Niemand muss ein neues Datenmodell lernen.

LESEN

Grafana + Prometheus Monitoring-Stack auf Ihrem VPS einrichten (Docker-Compose-Anleitung)

Die Lücke auf diesem Weg sind Netzwerkgeräte. Prometheus scrapt HTTP-Endpunkte; SNMP spricht es nicht direkt. Netzwerkhardware läuft normalerweise über snmp_exporter, der das Gerät abfragt und die Ergebnisse für Prometheus zum Scrapen bereitstellt. Seine Standardkonfiguration enthält Module wie if_mib, sodass das übliche Interface-Monitoring auf vielen Switches und Routern keine eigens generierte Konfiguration erfordert. Der Generator wird erst dann zur Zusatzarbeit, wenn Sie herstellerspezifische Objekte, angepasste Walks oder MIBs brauchen, die standardmäßig nicht enthalten sind. Der Prometheus-Weg hat also mehr Teile zu pflegen als Zabbix, aber der Generator ist nicht für jedes Gerät Pflicht.

LibreNMS ist der dritte Name in diesem Feld, aufgebaut um automatische Erkennung: Es durchläuft ein Netzwerk über SNMP, CDP, LLDP, OSPF, BGP und ARP, um herauszufinden, was vorhanden ist. Es ist eine vernünftige Option, wenn die Erkennung Priorität hat. An der Frage der Windows-Erfassung ändert es nichts, und genau dort fällt diese Entscheidung.

Wie jeder Weg einen Windows-Host sieht

Windows-Monitoring kann über SNMP, Remote-WMI oder einen installierten Agenten laufen. Welcher Weg gilt, hängt vom Monitoring-Produkt und der erfassten Metrik ab. Speziell in Zabbix laufen die eingebauten WMI-Checks über den Windows-Agenten.

SNMP

Eine SNMP-Abfrage fragt ein Gerät nach dem aktuellen Wert eines nummerierten Objekts, adressiert über eine OID, also eine Position in der MIB des Geräts. Zurück kommt, was das Gerät veröffentlicht, und sonst nichts. Bei einem verwalteten Switch, einer Firewall oder einer USV reicht das meist: Interface-Zähler, Portstatus, Fehlerraten, Temperatur, Gehäusezustand.

Unter Windows ist das Bild dünner. Microsofts Hinweis zur Abkündigung von SNMP und WMI SNMP Provider bestätigt, dass beide Funktionen veraltet sind, daher würde ich Windows-SNMP als Legacy-Kompatibilitätspfad behandeln und nicht als Standard für eine neue Installation. Zabbix liefert weiterhin ein Template Windows by SNMP, aber der native Agent gibt Ihnen deutlich mehr Einblick in das Betriebssystem.

WMI

WMI lässt sich aus der Ferne abfragen, ohne einen Monitoring-Agenten auf dem Ziel zu installieren, weshalb Produkte wie PRTG es als agentenlose Windows-Erfassungsmethode nutzen können. Zabbix arbeitet anders. Seine eingebauten WMI-Checks, wmi.get und wmi.getall, sind Item-Keys des Windows-Agenten, sodass der Zabbix-Agent oder Agent 2 diese Abfragen auf der überwachten Maschine ausführt.

Remote-WMI bringt zudem eigene Netzwerkanforderungen mit, wenn ein Monitoring-Produkt es direkt nutzt. Auf aktuellen Windows-Systemen startet RPC auf TCP-Port 135 und handelt Verbindungen normalerweise über den dynamischen hohen TCP-Portbereich aus, typischerweise 49152 bis 65535. Firewall und WMI-Berechtigungen auf dem Ziel müssen die Verbindung zulassen.

Für diesen Vergleich zählt die Unterscheidung mehr als das Protokoll selbst: PRTG kann Remote-WMI ohne installierten Monitoring-Agenten nutzen, während Zabbix seine Windows-spezifische WMI-Sicht über seinen Agenten bekommt.

Der native Agent

Der Agent ist der Ort, an dem die Windows-spezifische Tiefe steckt. Die Zabbix-Dokumentation listet die Windows-spezifischen Keys: eventlog für das Monitoring des Windows-Ereignisprotokolls, perf_counter für jeden beliebigen Windows-Leistungsindikator, service.discovery und service.info für den Dienststatus. Alle davon sind Item-Keys des Agenten.

Die Kosten liegen im Rollout. Ein Agent auf jedem Windows Server und jeder Workstation, die Ihnen wichtig ist, ist ein Paket zum Verteilen, eine Version, die aktuell zu halten ist, und eine Firewall-Regel, die gepflegt werden muss. Das ist eine dauerhafte betriebliche Verpflichtung, und sie ist das Gegengewicht zur Lizenzersparnis.

Agentenlose Erfassung ist auf das begrenzt, was Host oder Gerät freiwillig veröffentlichen, und in Zabbix liegen Ereignisprotokolle und detaillierte Leistungsindikatoren hinter Item-Keys des Agenten.

Im direkten Vergleich

Der Vergleich hängt an vier Dingen: ob das Tool Netzwerkgeräte überhaupt per SNMP abfragt, ob es einen Windows-Agenten hat, wie tief es in einen Windows-Host hineinsehen kann und wie viel Zusammenbau zwischen Ihnen und einem funktionierenden System liegt. Die Lizenz steht daneben, weil sie der Grund ist, warum die Bewertung überhaupt begann.

Wenn die Anforderung lautet „sag mir innerhalb einer Minute Bescheid, wenn ein Dienst nicht mehr antwortet“, ist ein Uptime-Monitor das Werkzeug in der richtigen Größe, und die beiden anderen sind dafür überdimensioniert. Was er nicht tut: einen Switch nach dem Interface-Durchsatz abfragen oder einen Windows-Leistungsindikator lesen. Er ersetzt also weder PRTG noch SolarWinds. Es ist eine andere Aufgabe, die manchmal für dieselbe gehalten wird.

LESEN

Uptime Kuma auf einem VPS einrichten

Welches Sie betreiben sollten

Betreiben Sie Zabbix. Für ein Windows-lastiges Netzwerk ohne bestehende Prometheus-Investition ist es mit großem Abstand der kürzere Weg. Sie haben weiterhin Server, Datenbank und Web-Frontend zu betreiben, aber Monitoring-Modell, Templates und Alarmierung leben in einem Produkt, statt aus mehreren Monitoring-Komponenten zusammengesetzt zu werden.

Für eine langlebige Monitoring-Installation nutzen Sie den aktuellen Zabbix-LTS-Zweig statt eines kurzlebigen Standard-Releases. Der LTS-Lebenszyklus von Zabbix gibt jedem Release drei Jahre vollen Support, gefolgt von zwei Jahren eingeschränktem Support, und das zählt hier mehr als die Jagd nach dem neuesten Feature-Release.

Die Ausnahme ist eng und konkret. Wenn Ihr Team Grafana und Prometheus bereits produktiv für Anwendungs- und Host-Metriken betreibt und jemand diesen Stack bereits verantwortet, dann ist snmp_exporter eine Ergänzung zu etwas Gepflegtem statt ein zweites System, das gepflegt werden muss. Diese Bedingung gilt nur gemeinsam: beide Hälften müssen zutreffen. Eine verwaiste Grafana-Instanz, die eine Person letztes Jahr aufgesetzt hat, zählt nicht.

Und wenn niemand die Stunden hat: verlängern. Das ist keine Ausflucht. Es ist eine andere Situation mit einer anderen richtigen Antwort. Der Wechsel macht aus einer Lizenzrechnung eine Betriebsrechnung: Agenten-Rollouts, Template-Arbeit, Upgrades und jemand, der das System gut genug versteht, um es um 2 Uhr nachts zu reparieren. Ein Team, das bereits am Limit ist, wird diese Arbeit schlecht oder gar nicht erledigen, und ungepflegtes Monitoring ist schlimmer als teures Monitoring, weil es leise ausfällt.

Den Hybrid gibt es wirklich: Behalten Sie das bestehende Produkt für einen schrumpfenden Kern kritischer Systeme, verschieben Sie alles andere nach Zabbix und lassen Sie die Lizenzstufe mit der Zeit sinken. Das funktioniert. Es bedeutet aber auch, zwei Monitoring-Systeme zu betreiben und ihre Alarme abzugleichen. Behandeln Sie es also als Übergangszustand mit Enddatum.

Was den Umzug nicht überlebt

Zabbix' eigener Migrationsleitfaden hat einen Abschnitt mit der Überschrift „Was NICHT migriert wird“, und die Liste ist länger, als das Wort „Migration“ vermuten lässt. Historische Daten und Sensorwerte kommen nicht mit. Eigene PRTG-Benachrichtigungen und Abhängigkeiten auch nicht. Karten und Dashboards auch nicht, weil die beiden Produkte sie so unterschiedlich modellieren, dass Neuaufbau besser ist als Übersetzen. Die Sensoren selbst ebenfalls nicht, da Zabbix mit einem völlig anderen Konzept arbeitet.

Gerätenamen, IP-Adressen und Interface-Typen lassen sich übernehmen. Selbst das läuft über eigene Export- und Import-Skripte gegen beide APIs. Der Leitfaden sagt unmissverständlich, dass es kein offizielles Werkzeug gibt, um direkt zwischen den beiden Plattformen zu migrieren.

Ein Team hat dokumentiert, was das in der Praxis kostet: rund 500 VMs und physische Server, etwa sieben Jahre auf PRTG, von Grund auf neu aufgebaut über sechs Monate Projektzeit mit niedriger Priorität. Aus ihren 2.500 PRTG-Sensoren wurden 43.000 Zabbix-Items, was anschaulich zeigt, wie unterschiedlich die beiden Systeme zählen.

„Fangen Sie bei null an. Es gibt keine Option ‚Knopf drücken und migrieren‘ von PRTG nach Zabbix, und selbst wenn es sie gäbe, ist so ein Vorhaben eine gute Gelegenheit, frühere Designfehler nicht zu wiederholen.“

Der Migrationsbericht von Digital Dilemma

Das ist die Erfahrung einer Organisation, kein Maßstab. Ein kleinerer Bestand wird diese Zahlen nicht erreichen. Was sich übertragen lässt, ist die Planungsannahme: Kalkulieren Sie Zeit für den Neuaufbau ein, nicht für eine Migration.

Ordnen Sie den Neuaufbau nach dem, worauf Sie nicht verzichten können. Geht es Ihnen um die Kontinuität der Alarmierung, bauen Sie zuerst die Benachrichtigungsregeln neu und lassen Sie die Dashboards hinterherhinken. Geht es um Berichtshistorie, exportieren Sie, was Sie brauchen, bevor die alte Lizenz ausläuft. Sie kommt nicht mit.

Den Server dimensionieren

Zabbix' Hardware-Anforderungen setzen eine kleine Installation mit etwa 1.000 überwachten Metriken auf 2 CPU-Kerne und 8 GiB Arbeitsspeicher an und eine mittlere Installation mit etwa 10.000 Metriken auf 4 Kerne und 16 GiB. Das sind die Zahlen, gegen die Sie beschaffen sollten.

Die Einheit ist die Stelle, an der die Dimensionierung schiefgeht. Zabbix definiert eine überwachte Metrik als ein Item plus einen Trigger plus einen Graphen. Eine Metrik ist kein Gerät und kein Host. Ein einzelner Windows Server steuert so viele Metriken bei, wie Sie Items konfigurieren: CPU, Arbeitsspeicher, jedes Dateisystem, jeder Dienst, jeder Indikator, den Sie abtasten. Die Geräteanzahl ist ein schlechter Anhaltspunkt für die Maschine, die Sie brauchen. Ein Bestand, der klein klingt, kann im mittleren Bereich landen, ohne dass jemand etwas Ungewöhnliches tut.

Zwei Dinge treiben die Zahl schneller nach oben als die Host-Anzahl. Erstens die Abfragefrequenz: Ein halbiertes Aktualisierungsintervall verdoppelt die Schreibrate für jedes Item in diesem Intervall. Zweitens die Aufbewahrung der Historie, denn die Datenbank wächst mit der Dauer, für die Sie Rohwerte behalten. Die Geräteanzahl zählt vor allem über die Zahl der überwachten Items, die jedes Gerät beisteuert.

Wenn Ihr Bestand nahe am Beispiel mit 1.000 Metriken bleibt, mit gewöhnlichen Aktualisierungsintervallen und moderater Aufbewahrung, ist der kleine Bereich ein vernünftiger Ausgangspunkt. Wenn Sie Leistungsindikatoren alle dreißig Sekunden abtasten und ein Jahr Rohhistorie behalten, dann nicht. Zabbix sagt ausdrücklich, dass die veröffentlichten Zahlen „Beispiele für Größe und Hardwarekonfiguration zum Einstieg“ sind, und empfiehlt Benchmarks in einer Staging-Umgebung, bevor Sie sich auf Produktionshardware festlegen. Das ist der Vorbehalt des Herstellers selbst. Nehmen Sie ihn wörtlich.

Zabbix unterstützt seine Server-Komponente nur unter Linux und UNIX; unter Windows wird nur der Agent unterstützt.

Metriken sind keine Geräte, und der Multiplikator zwischen beiden bestimmt die Größe der Maschine.

Wo der Monitoring-Server stehen sollte

Wenn das Monitoring einen standortweiten Ausfall überstehen soll, halten Sie den zentralen Zabbix-Server außerhalb der Fehlerdomäne des Standorts. Fällt der Uplink des Standorts aus, kann das überwachte Netzwerk offline gehen, ohne den Monitoring-Server mitzureißen.

Für ein privates Netzwerk kann ein Zabbix-Proxy innerhalb des Standorts sitzen und von den umliegenden Systemen erfassen. Der Proxy kann SNMP- und Agenten-Checks lokal abwickeln, die gesammelten Daten an den zentralen Server zurücksenden und Monitoring-Daten zwischenspeichern, solange die Verbindung zwischen beiden fehlt. So kann der zentrale Server außerhalb des Standorts bleiben, ohne dass jeder private Switch, jede Firewall und jeder Windows-Host direkt aus dem Internet erreichbar sein muss.

Ein VPS ist ein praktischer Ort für diesen zentralen Server. Cloudzy bietet Zabbix-Server als Ein-Klick-Bereitstellung auf Ubuntu Server 24.04 LTS an, falls Sie die Erstinstallation überspringen und direkt mit der Konfiguration von Hosts und Templates beginnen wollen.

Häufig gestellte Fragen

Ist Zabbix wirklich kostenlos?

Ja. Zabbix erscheint ab Version 7.0 unter der GNU Affero General Public License Version 3, und für die Software fällt keine Lizenzgebühr an, egal wie viele Geräte oder Metriken Sie überwachen. Zabbix verkauft technischen Support als separates optionales Abonnement, aber keine Funktion des Produkts ist dahinter verschlossen. Die Kosten für den Betrieb von Zabbix sind der Server, auf dem es läuft, und die Stunden, die Sie in den Betrieb stecken.

Muss ich auf jedem Windows Server einen Agenten installieren?

Nicht auf jeder Windows-Maschine, aber wenn Sie die native Windows-Monitoring-Tiefe von Zabbix wollen, planen Sie den Agenten auf den Servern ein, die Ihnen am wichtigsten sind. SNMP kann grobe agentenlose Daten liefern, allerdings hat Microsoft die Windows-SNMP-Funktion abgekündigt. Die eingebauten WMI-Checks von Zabbix laufen ebenfalls über seinen Windows-Agenten, WMI ist in Zabbix also kein direkter agentenloser Erfassungspfad. Nutzen Sie den Agenten für Ereignisprotokolle, Diensterkennung, WMI-Abfragen und detaillierte Leistungsindikatoren; agentenloses SNMP behalten Sie vor allem für Netzwerkhardware und Windows-Altfälle.

Kann ich den Monitoring-Server unter Windows betreiben?

Mit Zabbix nicht. Zabbix' Anforderungsdokumentation führt die Server-Komponente als nur unter Linux und anderen UNIX-Plattformen unterstützt und stellt fest, dass „UNIX das einzige Betriebssystem ist, das die nötige Leistung, Fehlertoleranz und Belastbarkeit dauerhaft liefern kann“. Die Windows-Unterstützung umfasst den Zabbix-Agenten und Agent 2, also das, was Sie auf den überwachten Maschinen installieren. Der Monitoring-Server sitzt auf einem Linux-Host; der Windows-Bestand ist das, was er beobachtet.

Kann Prometheus SNMP-Monitoring?

Nicht von sich aus. Prometheus scrapt HTTP-Endpunkte und nutzt snmp_exporter , um von SNMP-Geräten zu erfassen. Die Standardkonfiguration deckt viele gängige Switches und Router ab, während herstellerspezifische Objekte oder angepasste Abfragen zusätzliche MIB-Konfiguration und den Generator erfordern können.