Zabbix-Architektur: Server, Proxy und Agent richtig einplanen

Server und Datenbank bilden die zentrale Verarbeitung

Der Zabbix-Server verarbeitet Messwerte, bewertet Trigger und führt konfigurierte Aktionen aus. Die Datenbank hält Konfiguration und Monitoringdaten. Frontend, Server und Datenbank sind unterschiedliche Bestandteile mit eigenen Betriebsanforderungen. Wählen Sie die unterstützte Datenbank und deren Version anhand der eingesetzten Zabbix-Version.

Agenten sammeln Werte auf den Zielsystemen

Zabbix-Agenten erfassen lokale Informationen. Bei passiven Prüfungen fragt der Server oder Proxy den Agenten ab. Bei aktiven Prüfungen holt der Agent seine Prüfliste und sendet Ergebnisse an den vorgesehenen Server oder Proxy. Diese Unterscheidung beeinflusst Firewallregeln, Namensauflösung und die Fehlersuche.

Proxies übernehmen verteilte Datenerfassung

Ein Proxy kann Messwerte an einem Standort erfassen und abhängig von seiner Konfiguration zeitweise puffern. Die Auswertung von Triggern und die reguläre Alarmierung bleiben Aufgabe des Servers. Ein Proxy ist deshalb kein eigenständiges Alarmsystem für den Ausfall der Zentrale. Übertragungsstörungen und die Grenzen des Puffers müssen selbst überwacht werden.

Vom Item zur bearbeitbaren Meldung

Ein Item beschreibt einen erfassten Wert. Ein Trigger bewertet eine Bedingung. Aktionen und Benachrichtigungen legen fest, was bei passenden Ereignissen geschieht. Templates bündeln wiederverwendbare Definitionen. Prüfen Sie diese Kette vollständig: Ein sichtbarer Messwert beweist noch nicht, dass die richtige Person bei einem Fehler informiert wird.

Kapazität aus dem Messkonzept ableiten

Anzahl der Items, Prüfintervalle, Vorverarbeitung und Aufbewahrungszeiten beeinflussen die Last. Betrachten Sie Datenbank-I/O, Speicherbedarf und Wartungsaufgaben gemeinsam mit Rückstau und Auslastung der Zabbix-Prozesse. Ein zusätzlicher Proxy entlastet die Erfassung, beseitigt aber nicht automatisch Engpässe bei zentraler Verarbeitung und Speicherung.

Hochverfügbarkeit in allen Schichten betrachten

Die native Server-Hochverfügbarkeit arbeitet mit einem aktiven und weiteren wartenden Knoten, die dieselbe Datenbank verwenden. Sie ist keine parallele Verarbeitung aller Serverknoten. Für Datenbank, Frontend, Netzwerk und Stromversorgung braucht es zusätzliche Überlegungen. Prüfen Sie Failover und Wiederherstellung als vollständigen Ablauf.

Zugänge und Integrationen absichern

Richten Sie verschlüsselte Komponentenverbindungen ausdrücklich ein und begrenzen Sie Zugriffe. API-Zugänge benötigen passende Rechte und einen geregelten Lebenszyklus. Skripte und automatische Aktionen müssen überprüft werden. Monitoringdaten können sensible Informationen über Infrastruktur und Benutzeraktivitäten enthalten.

Auch das Monitoring muss überwacht werden

Prüfen Sie ausbleibende Daten, Fehler der Benachrichtigung, Warteschlangen und die Verfügbarkeit der Zentrale. Ein unabhängiger Erreichbarkeitscheck kann helfen, einen Ausfall zu bemerken, den die ausgefallene Plattform selbst nicht mehr melden kann. Dokumentieren Sie Betrieb, Updates, Sicherung und Wiederherstellung.