ZabFox

Dokumentation

Alles zum Installieren, Konfigurieren und Nutzen der ZabFox-Module.

Getting Started

Installiere und aktiviere das Network-Topology-Modul in deiner Zabbix-7.0-LTS- oder 7.4-Umgebung. Kein zusätzlicher Server — alles läuft im Frontend.

bash · modul installieren
# In den Modules-Ordner der Zabbix-UI
cd /usr/share/zabbix/ui/modules

# Release entpacken (Verzeichnisname ist Pflicht)
sudo unzip ~/Downloads/network_topology.zip
sudo chown -R root:root network_topology

# PHP-FPM neu laden
sudo systemctl reload php8.3-fpm

In vier Schritten startklar

01EntpackenAls network_topology.
02Verzeichnis scannenAdministration → Modules.
03AktivierenModul aktivieren.
04LoslegenMonitoring → Topology.

Update von einer 5.x-Version? Modul-Dateien ersetzen und php-fpm neu laden — ein Scan directory ist nicht nötig, es kam keine neue Action dazu.

Dashboard-Widgets · optional

Fünf Widgets bringen die Daten des Moduls direkt aufs Dashboard: Topologie-Graph, Health-Score pro Hostgruppe, KPI-Donut, Item-Pivot und eine Hostliste im Nagios-Stil. Alle fünf nutzen dieselbe Datenquelle wie das Hauptmodul — kein zweiter Dienst, keine zusätzliche Konfiguration.

Zabbix-Dashboard mit allen fünf Widgets: Topologie-Graph, KPI-Donut, Health-Score, Item- und Host-Tabelle
Alle fünf Widgets auf einem Zabbix-Dashboard — Topologie-Graph, KPI-Donut, Health-Score sowie Item- und Host-Tabelle (Demo-Daten).
Voraussetzungen: Zabbix 7.0 LTS oder 7.4. Und ein installiertes, aktiviertes Hauptmodul: Die Widgets holen sich von dort ihre Daten und die Graph-Bibliothek (Cytoscape.js) und funktionieren deshalb nicht eigenständig. Reihenfolge: erst Hauptmodul, dann Widgets.

Die fünf Widget-ZIPs liegen als Release-Assets auf GitHub — in den Modules-Ordner entpacken:

widget-installation
# In den Modules-Ordner der Zabbix-UI
cd /usr/share/zabbix/ui/modules

# Jedes Widget in einen EIGENEN Ordner (-d) — die ZIPs haben keinen Oberordner
sudo unzip network_topology_widget.zip -d network_topology_widget
sudo unzip network_topology_health_widget.zip -d network_topology_health_widget
sudo unzip network_topology_table_widget.zip -d network_topology_table_widget
sudo unzip network_topology_kpi_widget.zip -d network_topology_kpi_widget
sudo unzip network_topology_items_widget.zip -d network_topology_items_widget
sudo chown -R root:root network_topology_*

# php-fpm neu laden (Dienstname je nach Distro/PHP-Version)
sudo systemctl reload php8.3-fpm

Danach Administration → General → Modules → Scan directory und die fünf Module auf Enabled setzen. Sie erscheinen dann im Dashboard-Editor unter „Add widget".

FAQ

Braucht das Modul einen zusätzlichen Server?

Nein. Network Topology läuft komplett im Zabbix-Frontend als PHP-Modul — kein Extra-Dienst, kein separater Server.

Welche Zabbix-Version wird unterstützt?

Das Hauptmodul und die fünf Dashboard-Widgets laufen auf Zabbix 7.0 LTS und 7.4. Ältere Versionen werden nicht offiziell unterstützt. Zabbix 8 ist in Vorbereitung — auf dem 8.0 Release Candidate läuft das Modul bereits, und das Dunkeltheme passt sich dem neuen Dark-Blue an.

Ist ZabFox kostenlos und Open Source?

Ja. Das Network-Topology-Modul steht unter AGPL-3.0 und ist frei nutzbar.

Wie installiere ich das Modul?

Release nach ui/modules/ entpacken (Ordner network_topology), php-fpm neu laden und in Administration → Modules aktivieren — rund zwei Minuten.

Welche Ansichten gibt es?

Vier Haupt-Ansichten: Technical (Force-Graph), Management (Wallboard), Table (Hostliste/Pivot) und Geo (Leaflet-Karte) — dazu Analyse-Tabs wie Health, Stats, Dependencies, LLDP-Q, Compliance und Diag. Alles aus denselben Daten.

Was ist in der aktuellen Version neu?

Seit 5.5 ist das große Thema der MAC-/IP-/IPv6-Finder: MAC, IP oder IPv6 eingeben → Zugangs-Switch und Port, API-only aus FDB/ARP/ND und proxy-tauglich. Dazu passt sich das Dunkeltheme adaptiv an Zabbix an — inklusive dem Dark-Blue von Zabbix 8 (auf 8.0rc1 verifiziert). Davor machte v5.5.0 die volle Karte rund dreimal schneller (1000 Hosts von 4681 auf 1581 ms) plus NetBox-Kabelexport, v5.5.1 brachte Endgeräte-Blasen je Switch und Traffic/Laufzeit je Kabel, und eine Review-Welle härtete CPU-Quelle, History-Slider, Datenschutz und Datenqualität. Seit v5.0.0 heißt das Modul einheitlich network_topology.

Was passiert mit Geräten, die keine Topologie melden — unmanaged Switches, Firewalls ohne LLDP?

Das kommt auf das Gerät an, und es gibt zwei unterschiedliche Fälle.

Ein unmanaged Switch ist meist unsichtbar. Er spricht kein LLDP, reicht die Frames aber durch, weil er sie nicht verarbeitet. Die gemanagten Geräte links und rechts sehen dadurch sich gegenseitig und erscheinen auf der Karte direkt verbunden. Topologisch ist das falsch — praktisch stimmt die Aussage „diese beiden hängen zusammen" aber trotzdem.

Eine Firewall ohne LLDP ist der unangenehmere Fall. Sie wird von Zabbix überwacht, erscheint also als Knoten — aber ohne Kanten. Sie liegt als Insel auf der Karte, obwohl der halbe Verkehr durch sie läuft.

So füllst du die Lücken:

  1. Host-Tag nt:parent=<hostname> — der empfohlene Weg. Setz am Host ein Tag mit dem Namen des Geräts, an dem er hängt, z. B. nt:parent = fw-core. Das ist ein normales Zabbix-Host-Tag, liegt also serverseitig und ist für alle Benutzer sichtbar. Gedacht für Träger-Beziehungen (VM→Hypervisor, Container→Node), funktioniert aber genauso für „dieser Host hängt hinter dieser Firewall". Die Ausfallsimulation behandelt es als harte Abhängigkeit: Fällt der Parent aus, fällt der Child — unabhängig vom Netzpfad.
  2. Manuelle Links direkt in der Karte zeichnen (Star-Modus). Schnell für die eigene Sicht. Einschränkung: Sie liegen im localStorage des Browsers, sind also pro Benutzer und Gerät — dein Kollege sieht sie nicht. Zum Dokumentieren einer gemeinsamen Topologie ist das Tag das richtige Werkzeug.
  3. Ghost-Knoten decken den umgekehrten Fall ab: Meldet ein Nachbar ein Gerät, das in Zabbix gar nicht überwacht wird, erscheint es als gestrichelter Platzhalter. So wird die Lücke sichtbar, statt zu verschwinden.

Wichtig für die Ausfallsimulation: Sie kennt nur die Kanten, die sie bekommen hat. Ein Gerät, das nicht im Graphen steht, kann nicht als Ausfallpunkt simuliert werden — und eine handgezeichnete Kante, die nicht der Realität entspricht, macht die Simulation zuverlässig falsch. Für die Pfade, auf die es wirklich ankommt, lohnt sich ein Gegencheck: Sind die Kanten gemessen oder angenommen?