Zum Inhalt

Collector überlastet — was tun

Ein Collector ist eine kleine Linux-VM, die SNMP/SSH/Ping/HTTP-Checks parallel ausführt. Bei zu vielen Hosts, zu kurzen Intervallen oder unglücklichem Check-Mix kommt er nicht mehr hinterher: Check-Ergebnisse trudeln verzögert ein, manche bleiben aus, in der Sidebar leuchtet die Pipeline-LED orange.

Diese Seite beschreibt Symptome, wie man sie diagnostiziert und welche Maßnahmen in welcher Reihenfolge sinnvoll sind.

Symptome

Symptom Wahrscheinliche Ursache
Pipeline-LED dauerhaft orange/rot Worker-Backlog wegen Collector-Stau (siehe Skalierung) — oder der Collector selbst
Viele Checks gleichzeitig NO_DATA für 1–2 Minuten Collector ist überlastet oder kurz down
last_seen_at des Collectors hängt > 60s Heartbeat-Stau (Collector beschäftigt)
Discovery-Scans bleiben minutenlang running Discovery konkurriert mit Production-Checks
Hohe CPU oder Memory auf der Collector-VM Zu viele parallele Walks/SSH-Sessions
Check-Latenzen (Diff zwischen scheduled_at und received_at) > 30s Queue staut sich

Schritt 1 — Diagnose auf der Collector-VM

Per SSH zur Collector-VM:

# Service-Status
systemctl status vesana-collector

# Live-Logs
journalctl -u vesana-collector -f

# CPU/Memory
top -p $(pgrep -d',' vesana-collector)

# Wie viele Goroutines? (zeigt, wie viele parallele Checks laufen)
journalctl -u vesana-collector --since "10 min ago" | grep -c "starting check"

Im Log sehr aussagekräftig:

  • [scheduler] queue depth: N — wenn N dauerhaft > 50, Queue staut sich.
  • [snmp] timeout / [ssh] dial timeout — viele Timeouts deuten auf Netz-Engpass ODER zu kurzes Timeout für die Last.
  • [discovery] scan duration: X min — Discovery hängt im Forward.

Auf dem Vesana-Server:

# Collector-Heartbeat-Lag
SELECT id, name, last_seen_at, NOW() - last_seen_at AS lag
  FROM collectors WHERE deleted_at IS NULL ORDER BY lag DESC;

# Wie viele Hosts hängen an welchem Collector
SELECT c.name, COUNT(h.id) AS hosts
  FROM collectors c LEFT JOIN hosts h ON h.collector_id = c.id AND h.deleted_at IS NULL
  WHERE c.deleted_at IS NULL GROUP BY c.id, c.name ORDER BY hosts DESC;

Schritt 2 — Maßnahmen, von einfach nach komplex

A) Check-Intervalle erhöhen (sofortige Entlastung)

Die schnellste Atmungspause: bei nicht-zeitkritischen Checks das Intervall verdoppeln.

  • Profile-Check editieren → interval_seconds höher setzen (z.B. 60s → 180s).
  • Per Host-Override: Host-Detail → Check anklicken → „Intervall überschreiben".

Faustregel: SNMP-Walks alle 5 min reichen für die meisten Switches. Disk-Auslastung alle 2 min ist genug. Ping alle 60s — kürzer macht selten Sinn.

B) Profile-Checks ausdünnen

Wenn ein Profile 30 Checks pro Host auto-addet, multipliziert sich das. Bei 100 Hosts mit dem Profile sind das 3 000 Checks.

  • Profiles → Profil aufklappen — schaue welche Checks wirklich gebraucht werden.
  • Selten benötigte Checks: auto_add abdrehen. Bestehende Host-Services dazu kannst du in der Host-verwalten-Sicht einzeln deaktivieren.
  • Snippets/Vorlagen mit vielen OID-Walks: nur die wirklich gewünschten OIDs aktivieren statt komplette MIB-Trees zu walken.

C) Discovery zähmen

Discovery-Scans (Active-Scan / Pingsweep) belegen den Collector temporär stark.

  • Nicht regelmäßig laufen lassen — manueller Scan bei Änderungen reicht.
  • Discovery-Settings: aktive Subnet-Probe-Intervall erhöhen, oder einzelne Subnetze ausschließen (Discovery → Einstellungen → Subnet-Excludes).
  • Mehrere Collectors: jeden Collector mit eigener Discovery-Reichweite (jeder sein eigenes Subnetz statt überall scannen).

D) Hosts auf zweiten Collector aufteilen

Bei > 200 aktiven Hosts pro Collector oder bei stark unterschiedlichem Check-Mix lohnt sich ein zweiter Collector.

  1. Neuen Collector in Admin → Collectors anlegen.
  2. Auf der gewünschten VM installieren (siehe Collector).
  3. Hosts umziehen: Host-Detail → Host verwalten → Allgemein → Collector ändern. Oder Bulk in der Hosts-Übersicht.

Aufteilungs-Heuristiken:

  • Nach Tenant — sauberste Trennung, jeder Kunde hat eigenen Collector.
  • Nach Subnet — Collector A für 10.10.0.0/16, Collector B für 10.20.0.0/16.
  • Nach Check-Mix — ein Collector für SNMP-lastige Switches, einer für Server (Ping/SSH/HTTP).

E) Collector-VM aufwerten

Bei dauerhaft hoher CPU- oder Memory-Nutzung mehr Ressourcen geben.

Hosts pro Collector Empfohlene VM
< 50 1 vCPU, 1 GB RAM
50–200 2 vCPU, 2 GB RAM
200–500 4 vCPU, 4 GB RAM
> 500 besser zweiten Collector anlegen statt VM weiter aufzublasen

Über 500 Hosts pro Collector wirkt mehr CPU/RAM nur noch begrenzt — die Latenz-Schwelle ist dann meist im Netz oder bei Ziel-Geräten, nicht im Collector selbst.

F) Timeouts justieren

Wenn viele Walks/Pings in Timeouts laufen, hilft erhöhen — aber Vorsicht: längere Timeouts blockieren den Worker-Slot länger.

  • SNMP-Timeout pro Profile-Check unter check_config: timeout_seconds (Default 5s). Bei langsamen Geräten 10s.
  • SSH-Timeout: timeout_seconds (Default 10s). Bei alten Routern manchmal 20s nötig.
  • Ping-Timeout: in der Regel nicht zu erhöhen — wenn Ping > 2s braucht ist das Netz das Problem.

G) Logs forwarden statt pullen

Falls Logs vom Collector eingesammelt werden (Tail von Remote-Files via SSH): das ist teuer. Stattdessen besser einen Agent auf der Quelle laufen lassen — der pushed Logs aktiv, der Collector ist frei für andere Checks.

Wann ist es nicht der Collector?

Manchmal sieht es nach Collector-Last aus, ist aber etwas anderes:

  • Pipeline-LED orange aber Collector ist idle → Server-seitig: zu wenige Worker-Replicas. Siehe Skalierung.
  • Einzelner Host hängt → das Ziel-Gerät hat einen Bug (oft SNMPd) — der Collector wartet auf Antwort. Aktualisiere die Firmware oder reduziere die OIDs für dieses Gerät.
  • Discovery-Scan minutenlang running → bei /16-Subnetzen normal (1 Mio IPs zu scannen). Auf kleinere Subnetze einschränken.

Monitoring des Collectors selbst

Der Collector kann sich selbst überwachen lassen:

  1. Einen Host anlegen, der die Collector-VM ist (IP der VM, Profile generic_linux_server).
  2. Den Collector-Host an einen anderen Collector hängen (oder per Agent monitoren) — sonst überwacht er sich selbst und merkt nichts wenn er weg ist.
  3. CPU/Memory/Disk-Checks aktivieren — frühzeitige Warnung bevor er ganz steht.

Für agent-managed: einfach den Agent auf der Collector-VM installieren, der bringt Telemetrie ohne zusätzlichen Aufwand.

Verwandte Themen