Jein. Ich habe ein für diesen Zweck ausreichend gut funktionierendes Provisorium.
Diese Behauptung habe ich schon mal gelesen. Richtig ist, dass ich es (als Provisorium) installiert habe um mal einen Überblick über Latenz und Jitter im Netzwerk zu bekommen, als ich VoIP-Probleme hatte (dafür war es auch gut). Seitdem läuft es einfach im Hintergrund… Richtig ist auch, dass man sich über Veränderungen (inkl. Ausfall) benachrichtigen lassen kann.
Ich bewerbe oder empfehle Smokeping aber nicht als generisches Networkmonitoring-Tool.
IMHO: Ja
Nicht nur, aber auch weil es kein SNMP unterstützt: Keine Empfehlung, nur die Realität: Ich habe als Provisorium mal Uptime Kuma installiert. Einrichtung von Sensoren für Windows-Anhänger in klicki-bunti möglich. Ging alles sehr schnell. Bei mir ist die UI inzwischen sterbenslangsam (glaube <100 Sensoren), in einer neueren Version ist das angeblich ggf. besser, aber dafür müsste ich erst das OS updaten, was zum letzten Zeitpunkt wo ich es getestet habe an fehlenden deb-repository pgp Schlüsseln von turnkeylinux gescheitert ist.
Ich habe das Thema Netzwerkmonitoring vor einigen Jahren schon mal recherchiert, und es steht auch ganz oben auf meiner Agenda, gleich unter PBX Ersetzen, VPN migrieren, FW Filtering reaktivieren, VLAN-Umstrukturierung inkl. Einführung Directory-Server, SSO und Radius abschließen, und Serverautomatisierung einführen. Damals – zum Hype des Micro-Service-Pattern – hatte ich den Eindruck, dass der Stern von Icinga – Wikipedia, einem Fork von Nagios – Wikipedia, bereits am sinken war und the new hot shit Prometheus (Software) – Wikipedia (mit dem von @Lennart regelmäßig empfohlenen Grafana zur Visualisierung) ist. Leider ist mir damals was dazwischen gekommen, als dass ich es bisher noch nicht ausprobieren konnte. Daher möchte ich es vorsorglich ohne Prejudiz der Sach- und Rechtslage, sowie ohne Anerkennung einer Rechtspflicht, nicht empfehlen (gleichwohl erneut evaluieren sobald das Thema von ganz oben nach gaaanz oben in meiner Priorität gerutscht ist).
Ansonsten gehe ich davon aus, dass @felix.wolfsteller oder @holger noch eine Empfehlung haben könnten.
PS: Ich verstehe und teile deinen Frust über Smokeping.
PPS: Manche Menschen nutzen ja KI…:
Frage
Jemand hat in einem Forum folgenden Beitrag verfasst, welches Tool würdest du ihm empfehlen?
nutzt ihr Netzwerkmonitoring? Also um Alarme zu bekommen, wenn bestimmte Geräte oder ganze Netzsegmente offline gehen?
Wir machen das seit Jahren mit PRTG (unter Windows, kostenlos bis 100 Sensoren). Inzwischen zwei Instanzen, also 200 Sensoren, reicht auch nur noch knapp. Da ich ja grundsätzlich offen für Ent-Windowsifizierung bin und ein Großteil der Sensoren nur aus Pings besteht UND weil @sjjh nicht müde wird, Smokeping zu bewerben, habe ich das in den vergangenen Wochen getestet.
Ich bin leider wenig glücklich damit. Der Workflow bei Konfigurationsänderungen nervt. Man ändert eine Datei, startet anschließend den Dienst neu, und wenn man Pech hat, also meistens, schlägt das wegen eines Syntaxfehlers fehl. Ja, mit Hinweis, in welcher Datei, aber nicht in welcher Zeile. Also gewöhnt man sich an, nach jedem Komma zu speichern und neu zu laden, um Fehler schnell zu finden. Lästig.
Dann Alerting. Habe ich anhand verschiedener Beispiele eingerichtet und hatte am nächsten Morgen 1600 Mails im Postfach. Die Syntax à la „pattern = ==0%,==0%,==0%,==0%,>0%“ finde ich wenig intuitiv, um es mal sehr vornehm auszudrücken.
Time conditions scheint es gar nicht zu geben, ich habe aber diverse Geräte, die nur tagsüber erreichbar sind (manche PV-Wechselrichter nehmen ihre NIC offline, wenn keine Sonne scheint, andere Geräte sind nachts nicht erreichbar wegen WLAN-Nachtabschaltung).
Und ich vermisse ein Dashboard, auf dem alle aktuellen Alarme versammelt sind. Wenn ich aus dem Monitoring 50 Mails bekomme, lösche ich die meist komplett und schaue auf dem Dashboard, was davon tatsächlich noch aktuell ist. Smokeping weist mir zwar das Gerät mit der „Top Packet Loss“ aus, aber falls weitere offline sind, sehe ich das nicht. Meine Anforderung geht in Richtung ~200 überwachte Targets, da brauche ich eine gute Übersichtsseite.
Antwort mittels Claude Haiku 3.5
Basierend auf der detaillierten Beschreibung der Anforderungen würde ich Zabbix als optimale Lösung empfehlen. Hier sind die Gründe:
Vorteile von Zabbix
| Eigenschaft |
Beschreibung |
| Plattformunabhängigkeit |
Linux-basiert, läuft auf verschiedenen Betriebssystemen |
| Skalierbarkeit |
Geeignet für ~200 überwachte Targets |
| Alerting-Funktionen |
Flexible Benachrichtigungsregeln mit Zeitbedingungen |
| Dashboard |
Umfassende Übersichtsseiten mit aktuellen Alarmen |
| Konfiguration |
Web-Interface für einfache Änderungen |
Detaillierte Vorteile
- Löst die Probleme mit Smokeping:
- Intuitive Konfiguration über Weboberfläche
- Keine Neustart-Erfordernis bei Änderungen
- Präzise Fehlermeldungen
- Zeitbasierte Überwachungsregeln
- Zentrales Dashboard für Alarme
Zusätzliche Funktionen
- Unterstützt verschiedene Monitoring-Methoden (SNMP, ICMP, etc.)
- Open-Source mit Enterprise-Erweiterungen
- Kostenlose Community-Edition
- Mehrsprachige Unterstützung
Zabbix scheint perfekt zu passen, um die genannten Herausforderungen mit Smokeping zu adressieren und die Netzwerküberwachung zu vereinfachen.
Da die Anforderungen sehr spezifisch sind, würde ich noch zwei alternative Optionen vorschlagen:
- Nagios (ähnlich flexibel, aber komplexere Einrichtung)
- Icinga2 (Fork von Nagios mit moderner Architektur)
Möchten Sie, dass ich diese Optionen noch detaillierter erkläre?
Antwort mittels GPT-5 mini
Für die beschriebenen Anforderungen (ca. 200 Targets, einfache Ping-/ICMP-Checks, zuverlässiges Alerting mit Zeitbedingungen, gutes Dashboard, Konfigurationsworkflow ohne ständiges Neustarten, weniger Windows-Abhängigkeit) empfehle ich primär zwei Optionen — eine für einfache, robuste Überwachung; eine für umfassendere Features und Flexibilität.
Kurzempfehlungen
- Hauptempfehlung (einfach, skalierbar, gute Alerting/Time-based Regeln, moderne UI): Zabbix (aktuelle LTS).
- Alternative (Cloud-native, sehr flexibles Alerting & Routing, bestes Dashboarding zusammen mit Grafana): Prometheus + Alertmanager + Grafana (ggf. mit node_exporter / blackbox_exporter für Ping).
- Wenn du etwas mit minimalem Ops-Aufwand willst und kein On‑Prem-Management: ein gehosteter Monitoring-Service (z. B. UptimeRobot, StatusCake, Better Uptime) — weniger flexibel intern, aber sehr wartungsarm.
Warum Zabbix passt (stichpunkte)
- Unterstützt ICMP/agent/agentless Checks, vHosts, Netzsegmente; skaliert gut auf hunderte bis tausende Targets.
- Grafische, zentrale Web‑UI mit übersichtlichen Dashboards und Host-/Problem-Views (Übersichtsseite, die aktive Alarme zeigt).
- Mächtiges, aber gut strukturierbares Alerting mit Eskalationen, benutzer- und zeitbasierten Bedingungen (Timeperiods / Maintenance Windows).
- Templates und Massenkonfiguration (vorher konfigurieren, dann per Template auf viele Hosts anwenden) — kein ständiges Datei‑Edit + Dienst‑Restart nötig.
- Historie, Visualisierung, Trigger-Feinregelung (z. B. mehrere Paketrate/Packet-Loss-Degressionen).
- Läuft unter Linux; Agent optional — somit gute “Ent-Windowsifizierung”.
Warum Prometheus + Alertmanager + Grafana passt (stichpunkte)
- Prometheus sammelt Metriken (blackbox_exporter für Ping/HTTP), Grafana bietet sehr flexible Dashboards (Top N Packet Loss etc.).
- Alertmanager erlaubt komplexe Alert‑Routing, Stille/Zeitfenster (silences), deduplizierung, grouping — sehr mächtig.
- Konfigurationsbasierter Workflow (YAML), kann mit config-reload ohne Service-Stop arbeiten (Prometheus unterstützt SIGHUP/reload hooks / live reload).
- Eher Metrik‑orientiert: für reine Up/Down-Ping-Monitoring etwas mehr Setup (blackbox_exporter + proper scrape config), dafür hohe Flexibilität und Integrationen.
Praxistipp zur Mailflut / Time‑Windows / Dashboards
- Definiere Alerting-Rules so, dass Flut vermieden wird: Grupping (Alertmanager) / Problem-aggregation (Zabbix triggers), Suppression für wiederkehrende, kurzzeitige Zustände.
- Nutze Maintenance Windows oder Zeitprofile für Hosts, die tagsüber/nachts anders erreichbar sind.
- Richte ein zentralen „Active Problems“ Dashboard (in Zabbix: Problems view; in Grafana: Panel query auf Alerts/last_state) — das reduziert E‑Mail‑Scrolling.
Kurzentscheidungshilfe (wenn du mich entscheiden lässt)
- Willst du möglichst schnell von Windows weg, ein All‑in‑one mit geringerer Komplexität und guten Defaults? → Zabbix.
- Willst du maximale Flexibilität, moderne Metrikpipeline und beste Dashboards (bereit für spätere Erweiterung)? → Prometheus + Grafana + Alertmanager.
Wenn du willst, erstelle ich dir ein kurzes Migrations‑Setup: Zabbix‑Template für ~200 Pings (inkl. Timeperiods + Eskalation) oder Prometheus blackbox_scrape + Alertmanager rule examples + Grafana dashboard JSON. Welche Option bevorzugst du?
PPS: Bei Zabbix – Wikipedia hatte ich IIRC die Sorge, dass es zu Open Core verkommt und damit nicht mehr nutzbar ist – gut möglich, dass meine Sorge unbegründet ist.
