Meine Frau war schneller als mein Monitoring: Zabbix im Container überwacht jetzt das Heimnetz

Kurz gesagt: Vor gut zwei Wochen kam meine Frau nach Hause und hatte kein WLAN. Der Access-Point im Erdgeschoss antwortete nicht einmal mehr auf einen Ping, Strom aus, Strom an, seitdem läuft er wieder. Gemerkt hatte es außer ihr niemand, auch mein Monitoring nicht. Jetzt läuft auf meinem NAS-Server ein Zabbix 7.0 LTS in vier rootless Podman-Containern und schickt eine Mail, sobald eine Komponente im Heimnetz nicht mehr antwortet. Dieser Beitrag beschreibt den Aufbau, was ich zusätzlich konfigurieren musste, wo es hakte und wo man in der Oberfläche was findet.

📶 Wie alles anfing

Meine Frau kam heim, das Handy zeigte kein WLAN, und sie war – verständlicherweise – nicht begeistert. Ich konnte es sofort bestätigen: Der Access-Point im Erdgeschoss war nicht erreichbar, nicht über die Weboberfläche und nicht per Ping. Stecker ziehen, ein paar Sekunden warten, Stecker wieder rein. Seit ungefähr 14 Tagen läuft er wieder ohne Auffälligkeiten. Warum er ausgestiegen ist, weiß ich bis heute nicht. Es ist eines dieser Phänomene, die einmal auftreten und sich nicht wiederholen lassen.

Viel mehr beschäftigt hat mich etwas anderes: Warum habe ich das von meiner Frau erfahren und nicht von meinem Monitoring? Die Antwort ist einfach. Prometheus und Grafana überwachen meine Server, ein Uptime-Check prüft alle fünf Minuten von außen, ob Blog und Nextcloud erreichbar sind. Die kleinen Kästen im Heimnetz – Router, Repeater, Switch, Telefonbasis, Wechselrichter – hatte niemand im Blick. Sie haben keinen Agent, man kann nur fragen, ob sie antworten.

Was man mitnimmt: Monitoring deckt genau das ab, wofür man es gebaut hat. Die Lücken liegen oft bei den unscheinbaren Geräten, die einfach funktionieren – bis sie es nicht mehr tun.

🔭 Was ist Zabbix?

Zabbix ist eine Open-Source-Software für Monitoring, also für die laufende Überwachung von Servern, Netzwerkgeräten, Anwendungen und Diensten. Alexei Vladishev hat sie 2001 als internes Werkzeug begonnen, 2004 erschien Version 1.0. Heute entwickelt sie die Firma Zabbix SIA in Riga in Lettland. Die Software ist vollständig frei – es gibt keine kostenpflichtige „Enterprise-Edition“ mit zurückgehaltenen Funktionen; die Firma verdient an Support, Schulungen und Zertifizierungen. Bis Version 6.4 stand Zabbix unter der GPLv2, seit 7.0 unter der AGPLv3. Alle anderthalb Jahre erscheint eine LTS-Version mit fünf Jahren Pflege.

Wofür Zabbix bekannt ist:

• Alles in einem. Datensammlung, Speicherung, Alarmregeln, Benachrichtigung, Dashboards, Karten und Berichte stecken in einem Produkt mit einer Weboberfläche. Bei Prometheus und Grafana sind das mehrere Werkzeuge, die man zusammensetzt.
• Mit und ohne Agent. Der Zabbix-Agent (inzwischen meist Agent 2, in Go geschrieben und per Plugins erweiterbar) misst Betriebssysteme und Anwendungen von innen. Für Geräte, auf denen man nichts installieren kann, gibt es agentlose Prüfungen: Ping, TCP-Ports, HTTP, SNMP, IPMI, SSH und mehr.
• Netzwerk und SNMP. Zabbix ist besonders verbreitet, wenn es um Switches, Router, Firewalls, USVs und Drucker geht. Für unzählige Geräte gibt es fertige Vorlagen.
• Vorlagen und automatische Erkennung. Eine Vorlage bündelt Prüfungen, Alarme und Diagramme. Mit der Low-Level-Discovery findet Zabbix selbst, welche Dateisysteme, Netzwerkkarten oder Platten ein Gerät hat, und legt die passenden Prüfungen an.
• Große Umgebungen. Über Proxies lässt sich die Überwachung auf viele Standorte verteilen; Zabbix ist für Zehntausende Geräte ausgelegt.
• Eine vollständige API. Alles, was die Oberfläche kann, geht auch per JSON-RPC – ich habe den gesamten Aufbau für diesen Beitrag per Skript über die API angelegt.

Wo man Zabbix trifft: bei Internetprovidern und Telekommunikationsfirmen, in Rechenzentren, bei Banken, Behörden und Hochschulen, in vielen mittelständischen IT-Abteilungen – überall dort, wo eine gemischte Landschaft aus Servern, Netzwerktechnik und Spezialgeräten an einer Stelle überwacht werden soll.

Die Kehrseite: Zabbix ist mächtig, und das sieht man der Oberfläche an. Die Konfiguration liegt in der Datenbank statt in Textdateien, was „Konfiguration als Code“ schwerer macht als bei Prometheus. Und die Begriffe – Host, Item, Trigger, Template, Action – muss man einmal verinnerlichen, bevor alles einen Sinn ergibt.

Übrigens: Die Karte auf dem Dashboard zeigte nach der Installation zuerst Riga – dort sitzt Zabbix.

Was man mitnimmt: Zabbix ist das Schweizer Taschenmesser unter den Monitoring-Werkzeugen. Gerade bei vielen unterschiedlichen Geräten ohne eigenen Agent spielt es seine Stärken aus.

🎯 Das Ziel und warum Zabbix

Die Anforderung war bewusst klein: Eine Mail, wenn eine interne Komponente nicht mehr antwortet. Für Geräte ohne Agent heißt das: Ping, wo das Gerät auf Ping antwortet, und ein TCP-Verbindungstest auf einen Port wie 80 oder 443, wo es eine Weboberfläche hat.

Dazu kam ein zweiter Wunsch: Ich will auch merken, wenn das Internet selbst weg ist – und dann eine Mail „Internet nicht erreichbar“ bekommen statt fünf einzelner Alarme für jeden externen Server.

Das könnte ich auch mit einem kleinen Skript lösen. Ich habe mich trotzdem für Zabbix entschieden, aus zwei Gründen. Erstens bringt Zabbix genau diese agentlosen Prüfungen von Haus aus mit, dazu Verlauf, Diagramme, Abhängigkeiten zwischen Alarmen und Mailversand. Zweitens möchte ich aus beruflichem Interesse mehr praktische Erfahrung mit Zabbix sammeln – selbst aufbauen, selbst konfigurieren, selbst auf die Nase fallen, statt nur darüber zu lesen. Das Heimnetz ist dafür ein ideales Übungsfeld: echt genug, dass es Sinn ergibt, und klein genug, dass ein Fehler nicht wehtut.

Als Version habe ich Zabbix 7.0 LTS (7.0.32) gewählt. Version 8.0.0 war gerade erschienen, aber eine Punkt-Null-Version muss ich nicht als Erster ausprobieren, wenn ich gleichzeitig das Werkzeug lerne.

Was man mitnimmt: Für den Einstieg in ein neues Werkzeug lohnt sich ein echtes, kleines Problem mehr als eine Demo. Und eine LTS-Version nimmt eine Unbekannte aus der Gleichung.

🧱 Der Aufbau: vier Container, kein root

Zabbix läuft auf HP3, meinem NAS-Server mit Debian und ZFS, der ohnehin rund um die Uhr läuft und genug Reserven hat (4 Kerne, 32 GB RAM, davon war mehr als ein Drittel frei). Der Aufbau besteht aus vier Containern:

Die wichtigsten Entscheidungen dahinter:

• Podman rootless statt Docker als root. Alles läuft unter meinem normalen Benutzer. Ein Fehler in einem Container landet damit nicht als root auf dem NAS.
• Quadlet statt Compose. Jeder Container ist eine kleine .container-Datei unter ~/.config/containers/systemd/. Podman macht daraus normale systemd-Dienste – mit Abhängigkeiten, Neustart bei Absturz und Start beim Booten. Damit Benutzerdienste auch ohne Anmeldung starten, braucht es einmal loginctl enable-linger.
• Host-Netz statt NAT. Mit Network=host gehen Ping und TCP-Tests direkt ins Heimnetz, ohne Umweg über die Netzwerk-Übersetzung von Podman. PostgreSQL lauscht dafür ausdrücklich nur auf 127.0.0.1.
• Feste Grenzen für Speicher und CPU, damit Zabbix dem NAS-Betrieb nie in die Quere kommt. Tatsächlich brauchen alle vier Container zusammen gerade einmal rund 180 MB.
• Passwörter nicht in Dateien. Das Datenbank-Passwort liegt als Podman-Secret vor und wird den Containern als Datei übergeben, das Admin-Passwort der Oberfläche habe ich sofort nach dem Start über die API geändert.

So sieht die Datei für den Server aus:

[Unit]
Description=Zabbix server
Requires=zabbix-db.service
After=zabbix-db.service

[Container]
ContainerName=zabbix-server
Image=docker.io/zabbix/zabbix-server-pgsql:alpine-7.0.32
Network=host
Environment=DB_SERVER_HOST=127.0.0.1 POSTGRES_USER=zabbix POSTGRES_DB=zabbix
Environment=POSTGRES_PASSWORD_FILE=/run/secrets/zabbix-db-pw
Secret=zabbix-db-pw
AddCapability=NET_RAW
PodmanArgs=--memory=768m --cpus=1

[Service]
Restart=always

[Install]
WantedBy=default.target

Was man mitnimmt: Quadlet macht aus Containern ganz gewöhnliche systemd-Dienste. Man braucht keinen eigenen Container-Orchestrator, und systemctl --user status zeigt alles an einer Stelle.

💾 Wohin mit der Datenbank?

Eine naheliegende Frage war, ob die Datenbank auf die System-SSD gehört oder in den ZFS-Pool, der eigentlich für die Dateifreigaben da ist. Ich habe mich für den Pool entschieden. In HP3 stecken ausschließlich SSDs, auch die drei Platten im RAIDZ1-Verbund – Geschwindigkeit ist also kein Argument gegen den Pool. Dafür übersteht die Datenbank dort den Ausfall einer Platte, ZFS erkennt beschädigte Blöcke über Prüfsummen, und das Verzeichnis liegt in meinem Home-Dataset, das der Backup-PC ohnehin nachts sichert. Die System-SSD hat zwar über 400 GB frei, ist aber eine einzelne Platte und nicht im Backup.

Die Datenmengen sind überschaubar: Nach dem ersten Tag ist die Datenbank keine 100 MB groß. Ein eigenes ZFS-Dataset mit einer für PostgreSQL passenden Blockgröße wäre sauberer, braucht aber root – für diese Größenordnung lohnt es sich nicht.

Was man mitnimmt: Der schnellste Datenträger ist nicht automatisch der richtige. Für eine Datenbank zählen Redundanz und Backup mehr als die letzten Prozent Leistung.

📡 Was überwacht wird

Das Heimnetz ist in Zabbix in zwei Host-Gruppen aufgeteilt: LAN für die Geräte im Haus und Extern für meine Server im Rechenzentrum.

Im LAN prüft Zabbix jede Minute:

• Ping für Router, die drei WLAN-Repeater, Switch, Telefonbasis, Lüftungsanlage, PV-Wechselrichter und zwei Smart-Plugs. Dafür gibt es die fertige Vorlage ICMP Ping. Sie meldet ein Gerät als nicht erreichbar, wenn drei Pings in Folge ausbleiben – also nach etwa drei Minuten. Ein einzelner verlorener Ping löst keinen Alarm aus.
• TCP-Port zusätzlich dort, wo eine Weboberfläche läuft: 443 bei Router und Switch, 80 bei Lüftung und Wechselrichter. Der Schlüssel dafür ist net.tcp.service[tcp,<ip>,<port>], der Alarm feuert ebenfalls erst nach drei Fehlversuchen.
• Nur TCP 443 bei den drei Server-Fernwartungskarten (BMC). Sie hängen im selben Netz, aber was zählt, ist ob ihre Oberfläche antwortet.

Ein Detail, das ich ohne Zabbix nicht gehabt hätte: Der Port-Alarm hängt vom Ping-Alarm ab. Fällt ein Gerät komplett aus, kommt eine Mail („nicht per Ping erreichbar“) und nicht zwei. Nur wenn das Gerät auf Ping antwortet, die Weboberfläche aber nicht, meldet sich der Port-Alarm.

HP3 selbst misst der Agent 2: CPU, RAM, Last, Swap, Prozesse, alle Netzwerkkarten, die ZFS-Datasets und die Ein- und Ausgabe der vier SSDs. Dafür reicht die Vorlage Linux by Zabbix agent, und Zabbix legt die Diagramme selbst an.

Die externen Server – Blog und zwei Nextcloud-Instanzen – prüft Zabbix über Web-Szenarien: alle zwei Minuten ein Abruf, erwartet wird HTTP 200 und ein bestimmter Inhalt. Beim Blog ist das das Ende der Startseite, bei Nextcloud muss status.php "maintenance":false enthalten, bei Collabora muss die WOPI-Discovery antworten. Zusätzlich liest der Agent alle sechs Stunden die TLS-Zertifikate aus und warnt 14 Tage vor Ablauf.

Das Internet selbst prüft ein eigener Host „Internet“: Er pingt jede Minute zwei unabhängige öffentliche DNS-Server an (1.1.1.1 und 9.9.9.9) und ruft https://www.google.com/generate_204 ab, eine Adresse, die genau für solche Erreichbarkeitstests gedacht ist und nur „204 No Content“ zurückgibt. Der Alarm „Internet nicht erreichbar“ feuert erst, wenn beide Server dreimal in Folge schweigen – eine Störung bei einem einzelnen Anbieter ist noch kein Internetausfall. Die Alarme der externen Server hängen von diesem Alarm ab: Ist das Internet weg, kommt genau eine Mail.

Bewusst nicht geprüft werden SSH oder offene Ports auf diesen Servern. Ein bloßer Verbindungsaufbau zu Port 22 ohne Anmeldung landet im Log von sshd, und fail2ban kann daraus eine Sperre meiner eigenen Heim-IP machen. Ein schneller Test mehrerer Ports würde die Portscan-Sperre der Firewall auslösen. Eine HTTPS-Anfrage alle zwei Minuten ist dagegen ganz normaler Besuch.

Was man mitnimmt: Gute Alarme sind sparsam. Drei Fehlversuche statt einem und Abhängigkeiten zwischen Alarmen sorgen dafür, dass eine Mail etwas bedeutet.

🐛 Die Stolpersteine

Kein Aufbau ohne Überraschungen. Diese hier waren lehrreich:

1. Ping ging zuerst gar nicht. Jede Ping-Prüfung endete mit sh: /usr/sbin/fping: Operation not permitted. Im Server-Image hat fping die Datei-Capability cap_net_raw=ep. Fehlt diese Capability im Container, verweigert der Kernel schon den Start des Programms – nicht erst den Ping. Die Lösung war eine Zeile: AddCapability=NET_RAW in der Quadlet-Datei des Servers.
2. Ausrufezeichen im Hostnamen. „FRITZ!Box“ als Hostname lehnt Zabbix ab. Der technische Name erlaubt nur Buchstaben, Ziffern, Leerzeichen, Punkt, Unterstrich und Bindestrich. Zabbix trennt deshalb zwischen technischem Namen und Visible name – angezeigt wird der zweite.
3. Eine „freie“ IP war nicht frei. Für den Mailtest wollte ich einen Ausfall simulieren und habe ein Testgerät auf eine Adresse gesetzt, die beim Ping-Scan nicht geantwortet hatte. Zabbix meldete daraufhin 66 % Paketverlust – an der Adresse hing doch etwas, nur antwortete es unzuverlässig. Für Tests nehme ich seitdem eine Adresse aus dem Dokumentationsbereich (192.0.2.1, RFC 5737), die garantiert nie antwortet.
4. Eine frische Zabbix-Installation verschickt keine Mails. Die Aktion, die Probleme an die Administratoren meldet, ist ab Werk deaktiviert, und der Admin-Benutzer hat keine Mailadresse. Ohne diese beiden Schritte sieht alles grün aus und trotzdem kommt nie ein Alarm an.
5. Der Agent im Container sieht nicht automatisch den Host. CPU, RAM, Netz und Platten-Statistik kommen ohnehin vom Kernel des Hosts. Für die Dateisysteme habe ich das Host-Dateisystem schreibgeschützt unter /hostfs eingehängt und per Makro nur die echten Dateisysteme zugelassen, sonst tauchen die internen Overlay-Mounts von Podman auf. Die Platten fand der Agent erst, als die Gerätedateien /dev/sda bis /dev/sdd im Container sichtbar waren – gelesen wird trotzdem nur /proc/diskstats.
6. Zeitzone und Uhrzeitformat. Die Oberfläche stand auf UTC und zeigte „03:26 PM“. Unter Administration → General → GUI habe ich Europe/Berlin und das 24-Stunden-Format eingestellt.

Was man mitnimmt: Die Fehler lagen nie bei Zabbix selbst, sondern an den Übergängen: Container und Kernel, Testdaten und Wirklichkeit, Standardwerte und Erwartung.

✉️ Der Test: ein nachgestellter Ausfall

Eine Mail-Konfiguration ist erst bewiesen, wenn eine Mail ankommt. Zabbix nutzt dafür dasselbe SMTP-Konto, über das HP3 schon heute seine Statusmails verschickt (Port 587, STARTTLS). Für den Test habe ich ein Gerät auf die Dokumentationsadresse gesetzt und gewartet:

• Nach rund drei Minuten kam die Mail „Problem: ICMP Ping: Unavailable by ICMP ping“.
• Nachdem ich die Adresse wieder auf ein echtes Gerät gestellt hatte, kam „Resolved in 1m 0s“ hinterher.

Das Testgerät habe ich danach gelöscht. Für die Screenshots in diesem Beitrag habe ich den Ausfall noch einmal nachgestellt, mit abgeschalteter Benachrichtigung – deshalb heißt der ausgefallene Access-Point in den Bildern „WLAN-AP EG“.

Was man mitnimmt: Ein Alarm, der nie getestet wurde, ist eine Annahme. Ein absichtlich herbeigeführter Ausfall kostet fünf Minuten und beweist die ganze Kette vom Ping bis zum Postfach.

🧭 Rundgang durch die Oberfläche

Zabbix wirkt am Anfang erschlagend: Die Navigation hat ein gutes Dutzend Hauptpunkte mit vielen Unterseiten. Für den Alltag im Heimnetz braucht man aber nur wenige Stellen. Diese Tabelle ist meine Erste Hilfe – darunter steht zu jedem Punkt, was man dort sieht.

Dashboards → Global view: der Überblick

Die Startseite zeigt die Verfügbarkeit aller Hosts, die Probleme nach Schweregrad, die aktuellen Probleme und eine Karte. Die Kachel „Host availability“ ist anfangs verwirrend: Geräte ohne Agent erscheinen dort grau als „Unknown“. Das ist kein Fehler – sie haben schlicht keinen Agent, ihr Zustand steht in den Ping- und Port-Prüfungen. Die Karte (Geomap) zeigt die Geräte an dem Ort, der in ihrer Inventarisierung steht; ich habe dafür den Ort eingetragen statt einer genauen Adresse.

Monitoring → Problems: was gerade kaputt ist

Das ist die wichtigste Seite. Hier steht jedes offene Problem mit Beginn, Dauer und Schweregrad. Über Update kann man ein Problem bestätigen („ich kümmere mich“) und einen Kommentar hinterlassen. Mit dem Filter History sieht man auch erledigte Probleme – praktisch, um später nachzuvollziehen, wann der Access-Point zuletzt weg war.

Monitoring → Hosts und Latest data: der Zustand jedes Geräts

Monitoring → Hosts (Bild oben im Abschnitt „Was überwacht wird“) listet jedes Gerät mit Links zu seinen letzten Werten, Problemen, Diagrammen und Web-Szenarien. Latest data zeigt die nackten Messwerte: ob der letzte Ping ankam, wie lange er brauchte, ob ein Port offen war. Jeder Wert hat einen Link zum Diagramm.

Monitoring → Hosts → Web: die externen Server

Einen eigenen Menüpunkt dafür hat Zabbix 7.0 nicht: Man klickt in Monitoring → Hosts beim Gerät auf den Link Web. Dort stehen die Web-Szenarien für Blog, Nextcloud und Collabora mit Zeitpunkt und Ergebnis des letzten Laufs. Ein Klick auf den Namen zeigt Antwortzeit und Downloadgeschwindigkeit im Verlauf. Schlägt ein Szenario fehl, steht dort, welcher Schritt mit welchem Fehler scheiterte.

Data collection → Hosts: ein neues Gerät aufnehmen

Neue Geräte kommen unter Data collection → Hosts → Create host dazu. Für ein Gerät, das nur per Ping überwacht werden soll, reichen fünf Felder:

1. Host name – technischer Name, nur einfache Zeichen.
2. Visible name – der Name, der überall angezeigt wird.
3. Templates – ICMP Ping auswählen.
4. Host groups – zum Beispiel LAN.
5. Interfaces – eine Schnittstelle mit der IP-Adresse des Geräts. Der Typ ist für Ping egal; Zabbix nimmt die Adresse aus der Schnittstelle.

Speichern, fertig – nach spätestens einer Minute kommen die ersten Werte. Soll zusätzlich ein Port geprüft werden, legt man unter Items des Hosts eine Prüfung vom Typ Simple check mit dem Schlüssel net.tcp.service[tcp,,443] an und unter Triggers einen Alarm wie max(/<host>/net.tcp.service[tcp,,443],#3)=0.

Gleich daneben liegt Data collection → Maintenance. Dort trägt man Zeiten ein, in denen Geräte absichtlich aus sind – zum Beispiel einen Backup-PC, der nur gelegentlich läuft. Dann gibt es in dieser Zeit keine Mails.

Alerts → Media types und Actions: damit Mails ankommen

Zwei Stellen entscheiden, ob überhaupt eine Mail verschickt wird:

• Alerts → Media types → Email: SMTP-Server, Port, Verschlüsselung, Absender und Zugangsdaten. Über den Knopf Test kann man von hier aus eine Testmail schicken.
• Alerts → Actions → Trigger actions: Die vorhandene Aktion Report problems to Zabbix administrators muss auf Enabled stehen. Sie legt fest, wer bei einem Problem und bei der Entwarnung benachrichtigt wird.

Dazu kommt der Empfänger: unter Users → Users → Admin → Media die eigene Mailadresse eintragen.

HP3 selbst: Diagramme wie in Grafana

Für HP3 hat Zabbix aus der Linux-Vorlage selbst Diagramme gebaut: CPU, Speicher, Last, Netzwerk je Karte, Belegung jedes ZFS-Datasets und Platten-IO. Man findet sie unter Monitoring → Hosts → Graphs oder auf dem automatisch angelegten Host-Dashboard.

Was man mitnimmt: Von den vielen Menüpunkten braucht man im Alltag vier: Problems, Hosts, Latest data und Create host. Der Rest ist Konfiguration, die man einmal macht.

🔄 Wie es weitergeht

Ein Teil der Prüfungen ist jetzt doppelt vorhanden: Mein bisheriger Uptime-Check prüft Blog und Nextcloud weiterhin, Zabbix tut es zusätzlich. Das ist bewusst so. Beide laufen ein paar Wochen parallel, dann entscheide ich, ob Zabbix den Uptime-Check ersetzt. Zabbix hat den Vorteil von Verlauf und Antwortzeiten, der Uptime-Check den Vorteil, dass er winzig ist und kaum etwas schiefgehen kann.

Ebenso wichtig war mir, dass sich alles wieder entfernen lässt. Weil alles rootless unter meinem Benutzer läuft, besteht der Rückbau aus vier Dienste stoppen, vier Dateien löschen und einem Verzeichnis. Diese Schritte habe ich gleich beim Aufbau aufgeschrieben.

Bisher fragt Zabbix bei den meisten Geräten nur: „Bist du noch da?“ Im nächsten Post soll es in die Geräte hineinschauen:

• FRITZ!Box und Repeater über TR-064. SNMP können sie nicht, aber über diese Schnittstelle liefern sie den Status der Internetleitung, die Synchronisationsrate und die Zahl der WLAN-Clients. Das ist der eigentliche Gewinn: Ein Access-Point kann auf Ping antworten und trotzdem kein WLAN mehr senden. „Seit drei Stunden kein einziger Client“ ist der Alarm, der dann wirklich hilft.
• Der Switch über SNMP. Mit der Standard-MIB (IF-MIB) sieht Zabbix Status, Fehler und Datenverkehr jedes Ports und meldet, wenn ein Port ausfällt.
• Die Server-Hardware über iLO. Für Lüfter, Temperaturen, Netzteile und Platten bringt Zabbix eine fertige Vorlage mit, die per Redfish (HTTP) abfragt.
• Die Photovoltaik. Der Fronius-Wechselrichter hat eine eigene JSON-Schnittstelle, die Solar API. Zabbix kann sie ohne Zusatzsoftware abfragen und daraus Diagramme zum Ertrag bauen.
• Weniger Mails bei einem Ausfall. Fällt der Switch aus, kommt heute für jedes Gerät dahinter eine eigene Mail. Mit Abhängigkeiten zwischen den Alarmen weiß Zabbix, dass alles am Switch hängt, und meldet nur ihn.
• Ein zweiter Meldeweg wie eine Push-Nachricht aufs Handy (ntfy), falls der Mailweg selbst hakt. Dazu kürzere Aufbewahrung der Messwerte und eine nächtliche Sicherung der Datenbank.

Und ehrlich gesagt hoffe ich, dass die erste echte Mail von Zabbix noch lange auf sich warten lässt.

Was man mitnimmt: Ein neues Werkzeug neben dem alten laufen zu lassen, kostet wenig und zeigt, ob es im Alltag besser ist. Den Rückbau gleich mit aufzuschreiben, nimmt dem Ausprobieren das Risiko.

🎯 Die Lehren

1. Monitoring sieht nur, wofür man es gebaut hat. Die stillen Lücken liegen bei den Geräten ohne Agent.
2. Ein Alarm ist erst bewiesen, wenn ein absichtlich herbeigeführter Ausfall im Postfach ankommt – inklusive Entwarnung.
3. Standardwerte prüfen: Bei Zabbix ist ab Werk keine Mail-Aktion aktiv, die Zeitzone ist UTC.
4. Bei Containern liegen die Fehler oft an der Grenze zum Kernel: Capabilities, Gerätedateien, Mounts.
5. Für Tests Adressen nehmen, die garantiert niemandem gehören – „hat beim Scan nicht geantwortet“ heißt nicht „ist frei“.

🔧 Nachtrag: weniger Schreiblast für die SSDs

Nach der Veröffentlichung kam die Frage, ob ständige kleine Schreibvorgänge dem RAIDZ aus SSDs schaden. Also habe ich gemessen, was die Datenbank tatsächlich schreibt: rund 750 Transaktionen pro Minute, gut 110 davon erzwangen per fsync ein sofortiges Schreiben auf die Platte – knapp zwei pro Sekunde. Jedes fsync hindert ZFS daran, Schreibvorgänge im RAM zu sammeln und gebündelt zu schreiben, und im RAIDZ landet jeder kleine Block samt Parität auf den Platten.

Gemessen an der Lebensdauer der SSDs ist das harmlos: grob 200 bis 300 MB am Tag sind bei einer Auslegung auf rund 1.300 TB Schreibvolumen pro Platte vernachlässigbar. Weil der Server an einer USV hängt, habe ich PostgreSQL trotzdem auf Sammeln umgestellt – vier Optionen in der Quadlet-Datei der Datenbank:

Das Ergebnis, jeweils pro Minute bei vergleichbarer Last:

Der Preis: Fällt der Strom trotz USV aus, können die Messwerte der letzten Sekunden fehlen. Die Datenbank bleibt dabei konsistent – PostgreSQL verliert mit synchronous_commit=off nur die jüngsten Transaktionen, es zerstört keine älteren. Für Monitoring-Daten ist das ein guter Tausch.

Was man mitnimmt: Erst messen, dann optimieren. Die erste Einstellung allein brachte fast nichts; erst die Messung zeigte, dass der Hintergrundprozess im 200-ms-Takt weiter jede Kleinigkeit einzeln schrieb.

Die Screenshots sind anonymisiert: Gerätenamen, IP-Adressen, Domains und Mailadressen wurden vor der Aufnahme durch neutrale Platzhalter ersetzt, der Ausfall ist nachgestellt.