Monitoring Stack für Netzwerk, Hypervisor und Firewall

1. Was ein guter Monitoring-Stack leisten muss

Monitoring ist nicht das Sammeln möglichst vieler Metriken, sondern das schnelle Erkennen relevanter Abweichungen. Ein guter Stack beantwortet drei Fragen zuverlässig:

  • Lebt der Dienst? Erreichbarkeit und Grundfunktion.
  • Wird er knapp? CPU, RAM, Storage, Sessions, Fehlerzähler.
  • Warum ist es gerade schlecht? Korrelation aus Last, Fehlern und Änderungen.

Für Netzwerk, Hypervisor und Firewall bedeutet das: weniger dekorative Charts, mehr aussagekräftige Betriebsobjekte. Ein Link Down, ein voller ZFS-Pool oder ein ausgelasteter Stateful-Firewall-Table müssen auf einen Blick sichtbar sein.

2. Sinnvolle Bausteine im Self-Hosted-Umfeld

Im Homelab und in kleinen produktiven Umgebungen hat sich ein einfacher Metrik-Stack bewährt:

  • Prometheus: sammelt Zeitreihen per Pull.
  • Grafana: visualisiert Dashboards und Explore-Abfragen.
  • Alertmanager: bündelt und versendet Alarme.
  • Blackbox Exporter: prüft HTTP, ICMP, TCP und DNS von außen.
  • Node Exporter: Basis-Metriken für Linux-Hosts.

Für Logs gehört oft zusätzlich Loki, Graylog oder ELK dazu, das ist aber ein eigenes Thema. Der Kern dieses Artikels ist Metrik-Monitoring. Gerade für den Einstieg sollte der Stack bewusst klein bleiben.

3. Datenquellen für Netzwerk, Hypervisor und Firewall

3.1 Netzwerk

  • Interface-Status, Error Counter, Temperatur, CPU, Memory.
  • SNMP für klassische Switche und Router.
  • Optional Streaming Telemetry bei moderneren Plattformen.

3.2 Hypervisor

  • Host-Ressourcen: CPU-Steal, RAM, I/O-Wartezeit, Filesystem-Auslastung.
  • VM- und Container-Metriken: Laufstatus, Ballooning, Replikation, Backup-Fenster.
  • Storage-Signale: ZFS-Pool-Status, Ceph-Health, PBS-Jobs.

3.3 Firewall

  • Gateway-Latenz, Paketverlust, States, Session-Tabellen, VPN-Status.
  • CPU und RAM der Appliance.
  • WAN- und VPN-Durchsatz sowie Fehler bei DNS, DHCP oder IDS/IPS.

Gute Dashboards orientieren sich an diesen Betriebsobjekten. Ein "alles auf einer Seite"-Dashboard mit hundert Panels wirkt beeindruckend, hilft im Störungsfall aber selten.

4. Prometheus und Exporter praktisch aufsetzen

Für Linux-Server und VMs ist der Einstieg mit Node Exporter trivial. Für Netzwerkgeräte kommt häufig der snmp_exporter dazu, und für Firewalls entweder ein nativer Exporter oder ebenfalls SNMP. 

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets:
          - 192.168.10.11:9100
          - 192.168.10.12:9100

  - job_name: "blackbox-http"
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://grafana.example.internal
          - https://git.example.internal
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 192.168.10.30:9115

Für Proxmox, Ceph oder OPNsense gibt es community-getriebene Exporter. Gerade dort sollte man Metriken selektiv übernehmen und nicht blind alles aktivieren. Wenige belastbare Signale sind besser als unklare Massenmetriken ohne Besitzer.

5. Dashboards, Alerts und Eskalation

Dashboards sollten nach Verantwortungsbereichen strukturiert sein:

  • Perimeter: WAN, VPN, Firewall-States, DNS-Reachability.
  • Compute: Hypervisor, CPU, RAM, Storage, Cluster-Health.
  • Netz: Uplinks, Portfehler, Interface-Sättigung, Latenz.
  • Dienste: HTTP, DNS, Git, Monitoring selbst.

Alerts müssen Symptome priorisieren, nicht bloß Rohwerte. Beispiele:

  • Gateway-Paketverlust über 10 Prozent für mehr als 2 Minuten.
  • ZFS- oder Ceph-Health ungleich OK.
  • Blackbox-Probe für Reverse Proxy oder DNS schlägt mehrfach fehl.
  • Filesystem auf Hypervisor über 85 Prozent und weiter steigend.
groups:
  - name: infrastructure
    rules:
      - alert: HostFilesystemLow
        expr: node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} /
              node_filesystem_size_bytes{fstype!~"tmpfs|overlay"} < 0.15
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Wenig freier Speicher auf {{ $labels.instance }}"

Gute Alerts enthalten immer den nächsten sinnvollen Prüfpunkt, etwa Runbook-Link, Hostname oder betroffene Mountpoints. Sonst landet man trotz Alert wieder bei manueller Suche.

6. Betrieb, Retention und typische Fehler

Auch der Monitoring-Stack selbst ist Infrastruktur und braucht Pflege. Wichtige Punkte:

  • Retention: für kleine Umgebungen oft 15 bis 30 Tage lokal, Langzeitdaten optional extern.
  • Label-Hygiene: keine unnötig hochkardinalen Labels wie dynamische IDs oder Request-UUIDs.
  • Meta-Monitoring: Prometheus, Grafana und Alertmanager selbst überwachen.
  • Dashboards versionieren: JSON oder Provisioning-Dateien in Git.

Typische Anti-Patterns:

  • zu viele Alarme ohne klaren Owner,
  • Alerts direkt auf "kritisch", obwohl nur Trendbeobachtung nötig wäre,
  • Panels ohne Schwellenwerte oder Kontext,
  • Monitoring nur aus dem internen Netz, aber nicht aus Sicht eines Clients.

7. Troubleshooting

Wenn Metriken fehlen oder Alerts unplausibel wirken, sollte man in dieser Reihenfolge prüfen:

  1. Ist das Target überhaupt erreichbar?
  2. Antwortet der Exporter auf seinem Port?
  3. Hat sich ein Label oder Job-Name geändert?
  4. Ist die Query korrekt oder summiert sie Äpfel mit Birnen?
  5. Ist der Fehler im Zielsystem oder im Monitoring selbst?
curl http://192.168.10.11:9100/metrics
curl "http://192.168.10.20:9116/snmp?target=192.168.10.2&module=if_mib"
up{job="node"}
probe_success
prometheus_target_interval_length_seconds

Besonders nützlich ist die Targets-Ansicht von Prometheus. Dort sieht man sehr schnell, ob ein Problem auf DNS, TLS, Auth, Netzwerk oder Exporter-Konfiguration zurückgeht.

8. Zusammenfassung

Ein guter Monitoring-Stack ist klein, verständlich und eng am Betrieb orientiert. Prometheus, Grafana, Alertmanager und ein paar gezielte Exporter reichen für viele Homelabs und kleinere Infrastrukturen völlig aus.

Entscheidend ist nicht die Menge der Metriken, sondern die Qualität der Fragen, die man damit beantworten kann. Wenn Ausfall, Engpass und Ursache schnell sichtbar werden, erfüllt der Stack seinen Zweck.