Der schwergewichtige Gegenentwurf zum schlanken Active-Probing: ein agent-basierter Server-Stack, der Infrastruktur-Metriken in Tiefe sammelt, sie über Jahre vorhält und in einer Visualisierungs-Plattform sichtbar macht, die längst zum De-facto-Standard geworden ist. Eine fundierte Anleitung mit Architektur, Kommunikation, schrittweiser Installation, Templates, Skalierung und Sicherheit — die geplante zweite Folge nach unserem Artikel zu Gatus.
Einordnung — der schwere Gegenpol
Im ersten Teil dieser Reihe haben wir Gatus als das Werkzeug eingeführt, das aus der Außensicht prüft, ob ein Endpoint antwortet, ein Zertifikat noch gültig ist und ein JSON-Body die richtigen Felder enthält. Ein einziges Go-Binary, eine YAML-Datei, in einer Stunde produktiv. Was Gatus bewusst nicht liefert — Host-Metriken, langfristige Time-Series, Korrelations-Dashboards, SNMP-Discovery — füllt die Kombination aus Zabbix und Grafana.
Zabbix beantwortet die Frage „Wie geht es meinen Servern, Netzwerken und Diensten von innen?" Es ist ein vollständiges Infrastructure-Monitoring-System mit eigener Datenbank, eigenem Frontend, eigener Trigger-Sprache, agent-basierter Datensammlung, SNMP-Unterstützung und Auto-Discovery für große Netze. Grafana ergänzt es um eine Visualisierungs-Ebene, die längst zum Standard geworden ist — heterogene Datenquellen in einem konsistenten Dashboard, mit Alerting, Annotations, Variablen und Drill-Downs.
Die beiden Werkzeuge sind nicht zwingend gekoppelt. Zabbix bringt ein eigenes Web-Frontend mit, in dem sich Probleme, Trigger und Hosts genauso anzeigen lassen wie Graphen über die Zeit. Wer nur Zabbix einsetzt, ist mit dem mitgelieferten Frontend gut bedient. Sobald aber Daten aus mehreren Quellen — Zabbix, Prometheus, PostgreSQL, ein eigenes Reporting-DWH — in einer gemeinsamen Sicht zusammenfließen sollen, ist Grafana der natürliche Sammelpunkt. Genau diese Kombination zeigt dieser Artikel.
Eine ehrliche Vorwarnung: der Stack ist mächtig, aber er ist auch aufwendig. Eine produktive Inbetriebnahme misst man in Tagen bis Wochen, nicht in Stunden. Das Templating-Konzept ist gewöhnungsbedürftig, die Trigger-Syntax hat ihre Eigenheiten, und ohne sauberes Sizing der Datenbank wächst die History-Tabelle innerhalb weniger Monate über jedes Vorstellungsvermögen hinaus. Wer das Werkzeug richtig einsetzt, bekommt dafür eine Telemetrie-Tiefe, die ein Endpoint-Checker prinzipbedingt nicht erreichen kann.
Komponenten und ihre Aufgaben
Bevor die Installation beschrieben wird, lohnt eine Übersicht der beteiligten Komponenten — was sie tun, was sie nicht tun, und welche Rolle sie im Gesamtbild spielen.
Zabbix Server
Der zentrale Prozess. Er empfängt Daten von Agenten und Proxies, wertet Trigger aus, schreibt Werte in die Datenbank, führt Aktionen (Eskalationen, Benachrichtigungen) aus und stellt eine JSON-RPC-API über das Frontend bereit. Ein einzelner Server-Prozess reicht für mehrere tausend überwachte Hosts; jenseits davon kommen Proxies oder ein HA-Setup ins Spiel (Abschnitt „Skalierung").
Datenbank
Zabbix verlangt zwingend eine relationale Datenbank — MySQL/MariaDB, PostgreSQL oder Oracle. PostgreSQL ist die Standardempfehlung in den meisten neuen Projekten, weil das Zabbix-Team mit der TimescaleDB-Extension eine partitionierte und stark komprimierte Variante anbietet, die für lange History-Zeiträume deutlich effizienter ist als eine klassische Tabelle. Die Datenbank speichert Konfiguration, History (Rohwerte) und Trends (aggregierte Stunden- und Tageswerte).
Zabbix Frontend
Ein PHP-Frontend, das in einem Nginx- oder Apache-Webserver läuft und gegen die Datenbank arbeitet. Es ist die klassische Bedienoberfläche: Host-Verwaltung, Trigger, Templates, Maps, Reports. Wer ausschließlich mit Grafana arbeitet, kann das Frontend nicht weglassen — es bleibt das Tool, mit dem die Monitoring-Konfiguration gepflegt wird.
Zabbix Agent
Auf jedem überwachten Host läuft ein kleiner Prozess (Zabbix Agent 2 in der aktuellen Generation, in Go geschrieben), der Metriken sammelt: CPU-Auslastung, Speicher, Disk-IO, Netzwerk-Counter, Dateisystem-Belegung, Prozess-Listen, Logdateien. Der Agent unterstützt zwei Modi: passiv (der Server pollt den Agenten alle paar Sekunden) und aktiv (der Agent schickt seine Werte selbständig zum Server, wenn er sie hat). Aktiv ist die Standardempfehlung — robust gegen Firewall-Topologien und entlastet den Server.
Zabbix Proxy
Optional, aber in größeren oder geografisch verteilten Setups fast immer dabei. Ein Proxy sammelt Daten von Agenten in einem Netzwerksegment und leitet sie gebündelt an den zentralen Server weiter. Drei typische Einsatzfelder: ein Standort mit eingeschränkter Bandbreite (Bündelung spart Traffic), eine DMZ ohne direkten Server-Zugriff (Proxy hat als einziger eine Server-Verbindung), oder eine Lastauslagerung (Proxy entlastet den Server bei der Polling-Frequenz).
Grafana
Eine eigenständige Anwendung, die als Datenquelle das Zabbix-Frontend (über dessen JSON-RPC-API) oder direkt die Zabbix-Datenbank anspricht. Sie zeichnet Dashboards, fügt Annotations hinzu, definiert Alert-Rules und schickt Benachrichtigungen über die gewohnten Channels (Slack, Teams, Email, PagerDuty). Grafana ist in Go und TypeScript geschrieben, läuft als einzelner Prozess, und ihre Installation ist deutlich schlanker als die des Zabbix-Servers.
Kommunikation und Ports
Der wichtigste Schritt vor jeder Installation ist das Verständnis, wer mit wem über welchen Port spricht. In Setups mit Firewalls, DMZs oder restriktiver Netzsegmentierung scheitert die Inbetriebnahme häufiger an einer fehlenden Freischaltung als an einem Konfigurationsfehler im Werkzeug selbst.
Abbildung 1 — Komponenten und Kommunikationspfade: Zabbix-Agenten melden ihre Werte über TCP 10050/10051 entweder direkt an den Server oder über einen Proxy. Der Server schreibt in PostgreSQL und stellt eine JSON-RPC-API bereit, die Frontend und Grafana nutzen. Browser-Zugriffe laufen über HTTPS.
Welche Ports tatsächlich gebraucht werden
TCP 10050 — Server/Proxy → Agent (passiver Modus). Der Server fragt aktiv den Agenten ab. Auf dem Host muss der Agent als TCP-Listener auf 10050 erreichbar sein.
TCP 10051 — Agent → Server/Proxy (aktiver Modus) und Proxy → Server. Der Agent baut die Verbindung von sich aus auf. Bessere Variante in restriktiven Netzen, weil der Agent „nach außen" verbindet und nicht „von außen erreichbar" sein muss.
TCP 5432 — Zabbix Server → PostgreSQL (Standardport für Postgres). Bei MySQL/MariaDB stattdessen TCP 3306.
TCP 443 — Browser → Frontend und Browser → Grafana, jeweils per HTTPS. Hinter einem Reverse-Proxy (Nginx, Traefik) mit TLS-Terminierung üblich.
TCP 443 — Grafana → Zabbix-Frontend (REST-API). Dieselbe HTTPS-Verbindung, mit der auch die Operatoren das Frontend ansprechen.
Aktiv vs. passiv — die wichtigste Designentscheidung
In neuen Setups arbeiten praktisch alle Agenten aktiv. Drei Gründe: (a) Die Firewall muss nur ausgehende Verbindungen zum Server zulassen, nicht eingehende auf jeden Host. (b) Der Server wird entlastet, weil er nicht selbst polled. (c) Active Items sammeln auch dann Werte ein, wenn der Server kurz nicht erreichbar war — der Agent puffert lokal und liefert nach. Passive Items haben ihren Platz, wenn ein konkreter Wert ad hoc abgefragt werden soll oder wenn die Server-Pull-Logik aus organisatorischen Gründen bevorzugt wird, aber als Default für 95 % der Hosts ist Aktiv die richtige Wahl.
Installation Schritt für Schritt
Die folgende Anleitung beschreibt eine produktionstaugliche Einzelserver-Installation auf Ubuntu 24.04 LTS mit Zabbix 7.x, PostgreSQL als Datenbank und Grafana 11.x als Visualisierungs-Plattform. Alle Befehle laufen als root bzw. mit sudo. Vor dem Start sollten Hostname, FQDN und Zeitsynchronisation (NTP) eingerichtet sein.
Datenbank und Zabbix Server
Schritt 1 — Repository einbinden und Pakete installieren. Zabbix pflegt eigene Paketquellen für jede unterstützte Distribution; auf der Projektseite gibt es einen Generator, der die richtigen Befehle für jede Version liefert. Für Ubuntu 24.04 mit Zabbix 7.0:
Schritt 3 — Initiales Schema einspielen. Das Zabbix-Paket bringt einen komprimierten SQL-Dump mit, der die Tabellenstruktur und die Standard-Templates enthält:
Schritt 4 — Optional, aber für mehr als ein paar Dutzend Hosts dringend empfohlen: TimescaleDB-Extension aktivieren und das History-Schema partitionieren. TimescaleDB ist eine Postgres-Erweiterung, die die History- und Trends-Tabellen in Hypertabellen umwandelt — mit automatischer Partitionierung nach Zeit und Kompression alter Werte. Bei großen Setups schrumpft der Datenbankplatz dadurch um den Faktor fünf bis zehn:
Schritt 5 — Zabbix-Server konfigurieren. Die Konfigurationsdatei liegt unter /etc/zabbix/zabbix_server.conf. Mindestens das Datenbank-Passwort eintragen:
Schritt 6 — Frontend konfigurieren. Das Nginx-Snippet unter /etc/zabbix/nginx.conf liefert eine vorbereitete Server-Block-Datei. Den Server-Namen und den Listen-Port anpassen, dann den Webserver starten:
Schritt 7 — Frontend im Browser öffnen und den Einrichtungs-Assistenten durchlaufen. Beim ersten Aufruf prüft Zabbix die PHP-Einstellungen, fragt die Datenbank-Verbindungsdaten ab und legt die Konfiguration unter /etc/zabbix/web/zabbix.conf.php ab. Der voreingestellte Operator-Benutzer ist Admin mit dem Passwort zabbix — direkt nach dem ersten Login ändern.
Praxis-Hinweis
Vor dem ersten produktiven Einsatz das Frontend hinter einen Reverse-Proxy mit TLS-Terminierung stellen (Nginx, Traefik, Caddy). Die mitgelieferte Konfiguration läuft per Default über HTTP — für interne Tests genug, aber niemals für eine Operator-Anmeldung mit Passwörtern aus einem Browser.
Zabbix Agent auf den überwachten Hosts
Auf jedem Host, der überwacht werden soll, läuft ein eigener Agent-Prozess. Auf einem Debian/Ubuntu-Host:
Server erlaubt eingehende Verbindungen vom genannten Host (passiver Modus). ServerActive ist die Gegenstelle für den aktiven Modus — der Agent verbindet sich ausgehend zu diesem Server. Hostname muss exakt mit dem im Frontend angelegten Hostnamen übereinstimmen (case-sensitive), sonst werden aktive Items nicht zugeordnet.
Der Host muss anschließend im Frontend manuell oder per Auto-Registration angelegt werden. Auto-Registration ist die elegantere Variante in größeren Setups: der Agent meldet sich beim Server, der ihn anhand eines Hostmetadata-Strings einer Hostgruppe und einem Template zuordnet. Das spart den Pflegeaufwand, sobald mehrere Dutzend Hosts ins Spiel kommen.
Grafana und Datenquelle
Grafana wird ebenfalls aus dem offiziellen Repository installiert:
Grafana läuft anschließend auf TCP 3000. Erstanmeldung mit admin / admin, Passwort sofort ändern. Anschließend das Zabbix-Plugin installieren — das offizielle Plugin alexanderzobnin-zabbix-app wird über das Grafana-CLI nachgezogen:
Plugin in der Grafana-UI aktivieren (Configuration → Plugins → Zabbix → Enable) und anschließend als Datenquelle einrichten: URL des Zabbix-Frontends inklusive /api_jsonrpc.php, Benutzername und Passwort eines Zabbix-Benutzers mit Lese-Rechten (am besten ein eigens für Grafana angelegter Service-Account, nicht der Admin). Eine Test-Verbindung zeigt sofort, ob die API erreichbar ist und die Authentifizierung funktioniert.
Hinter einem Reverse-Proxy sollte Grafana den eigenen URL-Präfix kennen, damit die internen Links korrekt sind. In /etc/grafana/grafana.ini:
Die eigentliche Monitoring-Konfiguration spielt sich in drei Konzepten ab, die in Zabbix sauber getrennt sind: Items beschreiben, was gemessen wird; Triggers beschreiben, wann das gemessene als Problem gilt; Templates bündeln beides zu wiederverwendbaren Paketen.
Items — die einzelnen Messwerte
Ein Item ist ein konkreter Messwert auf einem Host. Zabbix kennt fünfzehn Item-Typen — die wichtigsten in der Praxis sind Zabbix Agent, SNMP Agent, HTTP Agent (für REST-APIs), Database Monitor (direkter SQL-Query auf eine Datenbank) und Calculated (Ableitung aus anderen Items). Jedes Item hat einen Key — eine zabbix-eigene Notation, die Funktion und Parameter beschreibt:
system.cpu.util[,user] # CPU-Auslastung im User-Mode
vfs.fs.size[/,pused] # Belegung von / in Prozent
net.if.in[eth0] # eingehende Bytes auf eth0
proc.num[postgres] # Anzahl Postgres-Prozesse
log[/var/log/syslog,error,,,skip] # neue Logzeilen mit "error"
Die Sammelfrequenz ist pro Item einstellbar — typische Werte sind 30 Sekunden für CPU/RAM-Items und 5 Minuten für Disk-Belegung. Wer alle Items auf 10 Sekunden zieht, wird mit der Datenbankgröße in den ersten drei Monaten gestraft.
Triggers — die Problemerkennung
Ein Trigger ist ein boolescher Ausdruck über einem oder mehreren Items. Sobald der Ausdruck wahr wird, gilt der Host als „in Problem". Die Trigger-Syntax kennt Funktionen wie last(), avg(), min(), max(), change(), jeweils mit Zeitfenster. Zwei typische Beispiele:
last(/db-prod-01/vfs.fs.size[/,pused]) > 85
# / ist zu mehr als 85% belegt
avg(/db-prod-01/system.cpu.util[,user],5m) > 80
and avg(/db-prod-01/system.load[all,avg5],5m) > 4
# 5-Minuten-CPU-Durchschnitt über 80% UND Load-Average über 4
Trigger haben eine Schweregrad-Stufe (Information, Warning, Average, High, Disaster) und können Dependencies haben — ein „Host ist nicht erreichbar"-Trigger unterdrückt alle anderen Trigger desselben Hosts, damit eine ausgefallene Maschine nicht hundert Folge-Alarme erzeugt.
Templates — die Wiederverwendung
Ein Template ist eine Sammlung aus Items, Triggers, Graphen und Discovery-Regeln, die an mehrere Hosts angehängt werden kann. Zabbix bringt ab Werk ein paar hundert Templates mit — für Linux- und Windows-Hosts, für Datenbanken (Postgres, MySQL, Oracle, MSSQL), für Webserver (Nginx, Apache), für Container (Docker), für Netzwerk-Hardware (Cisco, Juniper, HP, MikroTik), und für viele Anwendungs-Stacks. Diese Templates sind als Startpunkt brauchbar, sollten aber in den meisten Setups in eigene Forks abgewandelt werden, weil die Default-Schwellwerte selten zur eigenen Betriebsrealität passen.
Low-Level Discovery
Eine der mächtigeren Funktionen: ein Item liefert eine Liste, und Zabbix legt automatisch für jedes Listenelement passende Items, Triggers und Graphen an. Klassisches Beispiel — Dateisystem-Discovery. Der Agent meldet alle gemounteten Dateisysteme, und Zabbix legt pro Dateisystem ein „Belegung in Prozent"-Item plus passenden Trigger an. Dasselbe Prinzip funktioniert für Netzwerk-Interfaces, SNMP-Tabellen (z. B. Switch-Ports), JMX-Beans, Datenbank-Tabellen oder eigene Skript-Outputs. Wer LLD versteht, schreibt deutlich weniger Konfigurations-Boilerplate.
Praxis-Hinweis
Templates und ihre Forks am besten als Code im Git-Repository versionieren. Zabbix kann Templates als YAML- oder XML-Dateien exportieren und importieren — damit lassen sich Änderungen reviewen, Test- und Produktionsstand synchron halten und Rollbacks sauber durchführen. Wer die Konfiguration ausschließlich über die UI pflegt, verliert diese Eigenschaft sofort.
Dashboards in Grafana
Mit dem Zabbix-Plugin und einer eingerichteten Datenquelle lassen sich Grafana-Dashboards direkt auf Zabbix-Items aufbauen. Drei Muster zeigen das Spektrum.
Das Host-Übersichts-Dashboard
Eine Reihe Panels mit den vier klassischen Metriken — CPU, RAM, Disk, Network — als Single-Stat oder Time-Series. Über eine Grafana-Variable $host wird der angezeigte Host gewählt; das Dropdown wird aus den Zabbix-Hostgruppen befüllt. Ein einziges Dashboard zeigt dann für jeden überwachten Server denselben Blickwinkel. Dieser Ansatz ist die natürliche Ablösung der „pro Server ein Graph"-Manie aus älteren Monitoring-Werkzeugen.
Das Service-Dashboard
Ein Dashboard pro fachlicher Anwendung — etwa „Bürgerportal" — das Items aus mehreren Hosts und Komponenten in einer Sicht zusammenfasst: Antwortzeit der API, Postgres-Verbindungszahl, Speicherbelegung des Frontends, Anzahl offener Zabbix-Probleme. Solche Dashboards sind oft das, was im Operations-Center auf einer Wand läuft. Sie sind nur dann sinnvoll, wenn die zugrundeliegenden Items konsistent benannt sind — die Disziplin beim Templating zahlt sich hier direkt aus.
Das SLO-Dashboard
Ein Dashboard, das eine SLO-Definition (Service Level Objective) sichtbar macht: Verfügbarkeit der letzten 30 Tage, Error-Budget-Verbrauch, prozentuale Latenz-Quantile. Solche Dashboards leben oft nicht mehr nur von Zabbix-Daten, sondern kombinieren mehrere Datenquellen — Zabbix für die Infrastruktur, Loki oder Elasticsearch für die Anwendungslogs, vielleicht Prometheus für Application-Metriken. Genau hier zeigt sich der Wert von Grafana als gemeinsamer Sammelpunkt.
Alerting: Zabbix oder Grafana?
Beide Werkzeuge können Alarme schicken. In der Praxis hat sich folgende Aufteilung bewährt: Zabbix alarmiert auf Infrastruktur-Events (Host down, Disk voll, Postgres-Verbindungen ausgeschöpft) — also dort, wo die Daten ursprünglich erhoben werden. Grafana alarmiert auf zusammengesetzte Bedingungen, die aus mehreren Datenquellen abgeleitet sind, sowie auf SLO-Verletzungen, die nicht in Zabbix-Items modelliert sind. Wer beides aktiviert ohne sauber abzugrenzen, bekommt Doppelalarmierungen und Pager-Müdigkeit.
Skalierung und Hochverfügbarkeit
Ein einzelner Zabbix-Server reicht in der Praxis für mehrere tausend Hosts, sofern die Datenbank ordentlich aufgestellt ist. Erst jenseits davon werden zusätzliche Maßnahmen nötig. Drei Hebel sind die relevanten.
Proxies in größeren oder verteilten Setups
Ein Zabbix Proxy ist ein eigener Prozess, der eine Teilmenge der Hosts überwacht und die gesammelten Daten gebündelt an den Server liefert. Drei typische Einsatzfelder:
Geografisch verteilte Standorte. Ein Außenstandort mit eingeschränkter Bandbreite bekommt einen eigenen Proxy. Der Proxy sammelt die Daten lokal und sendet sie komprimiert und gebündelt an die Zentrale — der Traffic schrumpft um den Faktor zehn gegenüber einzelnen Agent-Verbindungen.
DMZ-Setup. Die DMZ-Server dürfen nicht auf den internen Zabbix-Server zugreifen. Ein Proxy in der DMZ ist die einzige Komponente, die nach innen verbindet — die Agenten reden nur mit dem Proxy.
Lastauslagerung. Bei tausenden Items mit Sub-Sekunden-Frequenz wird der Server-Prozess selbst zum Engpass. Mehrere Proxies, die jeweils einen Teil der Hosts bedienen, entlasten den Server-Prozess auf die reine Trigger-Auswertung und die Datenbank-Schreibvorgänge.
Datenbank-Partitionierung mit TimescaleDB
Die History-Tabelle ist in jedem ernsthaften Zabbix-Setup die größte Tabelle, weil sie pro Item alle Rohwerte über den Retention-Zeitraum hält. Ohne Partitionierung wird sie schnell zur Bremse: jeder DELETE-Pass des Housekeeping-Tasks dauert dann Stunden. TimescaleDB löst das, indem es die Tabelle in Zeit-Chunks zerlegt — älter werdende Chunks werden komprimiert (Faktor zehn üblich), und nicht mehr benötigte Chunks können in Millisekunden gedroppt statt zeilenweise gelöscht werden.
HA-Mode des Zabbix-Servers
Seit Version 6 unterstützt Zabbix einen eigenen HA-Modus: mehrere Server-Instanzen lesen aus derselben Datenbank und einigen sich über einen Lock-Mechanismus, welcher gerade aktiv ist. Fällt der aktive Server aus, übernimmt eine Standby-Instanz innerhalb von Sekunden. Dieser HA-Modus ersetzt nicht die Datenbank-HA — Postgres muss separat über Replikation oder einen Cluster wie Patroni hochverfügbar gemacht werden. Aber er löst das Problem des ausgefallenen Server-Prozesses sauber, ohne dass eine externe Cluster-Software wie Pacemaker nötig ist.
Sicherheit, Retention und Betrieb
Die operative Stärke des Stacks zeigt sich darin, dass er sich über Jahre stabil betreiben lässt — vorausgesetzt, einige Eigenheiten werden beim Aufsetzen mitgedacht.
TLS zwischen Server, Proxy und Agent
Die Agent-Server-Kommunikation ist per Default unverschlüsselt. In abgeschotteten Netzwerken mag das tragbar sein, in jedem Setup, das auch nur teilweise über öffentliche oder geteilte Infrastruktur läuft, gehört TLS aktiviert. Zabbix unterstützt zwei Modi: PSK (Pre-Shared Key — symmetrisches Geheimnis pro Host oder pro Gruppe) und Zertifikate (asymmetrische Authentifizierung über X.509). PSK ist deutlich einfacher in der Pflege und für 90 % der Setups ausreichend.
# Auf dem Agent-Host:
openssl rand -hex 32 > /etc/zabbix/zabbix_agent2.psk
chmod 0600 /etc/zabbix/zabbix_agent2.psk
chown zabbix:zabbix /etc/zabbix/zabbix_agent2.psk
# In /etc/zabbix/zabbix_agent2.conf:
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=db-prod-01
TLSPSKFile=/etc/zabbix/zabbix_agent2.psk
Im Frontend wird der zugehörige PSK pro Host (oder pro Hostgruppe) hinterlegt. Verbindungen ohne korrekten PSK weist der Server ab.
Authentifizierung im Frontend
Das Zabbix-Frontend unterstützt LDAP- und SAML-Anbindung sowie HTTP-Auth. In Enterprise-Setups gehört einer dieser Mechanismen aktiviert, sodass Benutzer-Accounts nicht im Zabbix-eigenen Storage liegen, sondern aus dem zentralen Identity-Provider (Active Directory, Keycloak, Entra ID) kommen. Multi-Factor-Authentication unterstützt das Frontend ab Version 7.
Für die Grafana-Anmeldung gilt dasselbe: OAuth/OIDC einrichten, lokale Benutzer abschalten. Beide Plattformen sind Operator-Tools — die Anmelde-Disziplin muss dem Industrie-Standard entsprechen.
Retention und Housekeeping
Zwei Knöpfe regeln, wie lange Daten gespeichert werden: History (Rohwerte, üblicherweise 7–30 Tage) und Trends (aggregierte Stunden- und Tageswerte, üblicherweise 365 Tage bis 5 Jahre). Beide Werte werden pro Item eingestellt, lassen sich aber auf Template-Ebene zentral vergeben. Der Housekeeping-Task läuft im Server-Prozess und löscht abgelaufene Zeilen — mit TimescaleDB wird dieser Schritt zum simplen Chunk-Drop und kostet praktisch keine Laufzeit mehr.
Wer Compliance-Anforderungen an die Aufbewahrungsdauer hat — bei BAIT, KRITIS oder ISO 27001 typisch ein Jahr für Audit-relevante Events — sollte die History-Aufbewahrung für die betroffenen Items entsprechend setzen und das in einer eigenen Spalte der internen Service-Doku festhalten. Zabbix sagt nicht von sich aus, welche Items „wichtig" sind.
Backups
Das Wichtigste zuerst: die Datenbank. Ein pg_dump einer mittelgroßen Zabbix-Datenbank dauert je nach Größe Minuten bis Stunden. Für 24/7-Setups eher inkrementelle Postgres-Backups mit pgBackRest oder WAL-Archivierung. Die Konfiguration unter /etc/zabbix und die exportierten Templates aus dem Git-Repository sichern den Rest — der Server-Prozess selbst ist zustandslos.
Wann der Stack passt — und wann nicht
Zabbix und Grafana bilden einen mächtigen, etablierten Stack — aber sie sind nicht für jede Monitoring-Frage die richtige Antwort. Eine ehrliche Einordnung am Ende.
Passend, wenn …
tiefe Host- und Netzwerk-Telemetrie gebraucht wird — CPU, RAM, Disk, SNMP, Logfiles, Prozess-Listen — auf eigener Infrastruktur, agent-basiert;
eine große Anzahl Hosts oder eine verteilte Topologie mit DMZ-/Außenstandort-Setup zu überwachen ist und Proxies als natürliches Skalierungsmittel willkommen sind;
Templates und Auto-Discovery die Konfigurationsarbeit auf eine handhabbare Größenordnung schrumpfen lassen sollen;
eine Time-Series-History über Jahre aufbewahrt werden muss — für Capacity-Planning, Audits oder Compliance;
eine gemeinsame Visualisierung über Zabbix, Prometheus, Loki und Anwendungs-Datenbanken in einem Tool zusammenlaufen soll.
Weniger geeignet, wenn …
Sie schlicht wissen wollen, ob ein paar öffentliche APIs aus Anwendersicht erreichbar sind und eine Statusseite betreiben möchten — dort ist Gatus in einem Bruchteil der Zeit produktiv;
Sie ein vollständig SaaS-getriebenes Monitoring brauchen, ohne eigene Infrastruktur zu betreiben — dann sind Datadog, New Relic oder Dynatrace die naheliegende Antwort;
Sie ein cloud-natives Setup mit Container-Orchestrierung haben, in dem Prometheus mit dem dazugehörigen Ökosystem (Alertmanager, Thanos, Cortex) ohnehin schon Standard ist — Zabbix lässt sich integrieren, ist aber nicht der idiomatische Weg;
Sie die operative Disziplin für einen Server-Stack mit eigener Datenbank, eigenen Updates und eigenem Sizing nicht aufbringen können — das Werkzeug verzeiht Vernachlässigung schlechter als ein Single-Binary wie Gatus.
In den meisten regulierten Branchen, mit denen wir arbeiten, ist Zabbix nach wie vor das richtige Werkzeug für die Infrastruktur-Sicht — kombiniert mit Grafana für die Visualisierung und in der Regel ergänzt durch ein leichtgewichtiges Endpoint-Monitoring wie Gatus für die Außensicht und die öffentliche Statusseite. Die drei Werkzeuge sind komplementär, jedes beantwortet eine andere Frage. Wer alle drei beherrscht, hat den vollständigen Monitoring-Werkzeugkasten zur Hand — von „läuft die API?" über „verbrennt die Postgres ihre Verbindungen?" bis „wie hat sich die durchschnittliche CPU-Last über die letzten zwölf Monate entwickelt?"
Monitoring-Setup oder Stack-Konsolidierung?
Wir prüfen gemeinsam mit Ihrem Team Ihre Monitoring-Landschaft — Host-Coverage, Templates, Datenbank-Sizing, Alerting-Disziplin, Reverse-Proxy- und TLS-Konfiguration. Das Ergebnis: ein konkreter Maßnahmenplan, abgestimmt auf Größe und Reife Ihrer Plattform.
