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 kommen verzögert an, manche bleiben aus.

Diese Seite beschreibt Symptome, wie man sie diagnostiziert und welche Maßnahmen in welcher Reihenfolge sinnvoll sind. Für den Aktiven Collector gilt dasselbe, zusätzlich meldet seine Admin-Seite „Kommt nicht hinterher" und es lassen sich weitere Aktive Collectors dazunehmen.

Wie viel parallel läuft¶

Der Collector führt seine Checks im Hintergrund aus; Config-Abruf, neu fällige Checks und Aufträge warten nicht auf den langsamsten Check. Die Zahl gleichzeitiger Checks richtet sich nach den Kernen der VM: bis 3 Kerne 16, darüber 16 je Kern, höchstens 256. Ein einzelnes Ziel bekommt nie mehr als 16 gleichzeitige Checks, Script- und Plugin-Checks (je ein eigener Prozess) laufen höchstens zu 16 gleichzeitig. Mehr Kerne helfen einem überlasteten Collector also direkt.

Jeder Check hat eine harte Frist (zweimal sein Intervall, mindestens 30 s, höchstens 90 s; Internetlinie 120 s). Läuft sie ab, meldet der Check UNKNOWN und der Collector arbeitet weiter.

Symptome¶

Symptom	Wahrscheinliche Ursache
Hinweis auf Verarbeitungs-Verzögerung (Pipeline) in der Oberfläche	Worker-Backlog am Server (siehe Skalierung) — selten der Collector
Viele Checks eines Collectors gleichzeitig auf „No Data"	Collector offline oder überlastet
„Zuletzt gesehen" des Collectors älter als ~1 Minute	Collector hat Verbindungsprobleme oder hängt (Herzschlag alle 30 s, offline ab 3 Minuten)
Discovery-Scans laufen lange	großes Subnetz oder langsame Ziele (Frist je Scan 15 Minuten)
Hohe CPU oder Speicher auf der Collector-VM	Zu viele gleichzeitige Walks/SSH-Sitzungen
Im Log häufig `check abandoned (deadline exceeded)`	Checks laufen in ihre Frist — Ziele langsam oder Collector ausgelastet

Schritt 1 — Diagnose auf der Collector-VM¶

# Dienst-Status
systemctl status vesana-collector

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

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

Aussagekräftige Log-Zeilen:

running checks hosts=… due=… und checks complete count=… — wie viele Checks pro Durchlauf fällig sind und fertig werden.
check abandoned (deadline exceeded) — ein Check hat seine Frist überschritten.
failed to send results / send attempt failed — Ergebnisse kommen nicht beim Server an (Netz, Zertifikat, Server-Last).
watchdog: no check progress for too long, exiting for restart — ein echter Hänger; systemd startet den Collector neu.

Auf dem Vesana-Server (psql):

-- Herzschlag-Abstand
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)¶

Bei nicht zeitkritischen Checks das Intervall verdoppeln:

Am Profil-Check das Intervall erhöhen (z. B. 60 s → 180 s) — gilt für alle Hosts mit dem Profil.
Für einen einzelnen Host: Check bearbeiten → Intervall.

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

B) Profil-Checks ausdünnen¶

Legt ein Profil 30 Checks pro Host an, multipliziert sich das: 100 Hosts mit diesem Profil sind 3 000 Checks.

Profile → Profil öffnen — prüfen, welche Checks wirklich gebraucht werden.
Selten benötigte Checks am Profil nicht mehr automatisch hinzufügen lassen; bestehende Checks einzelner Hosts in der Host-Detail-Ansicht deaktivieren.
Walk-Checks nur auf die gewünschten Tabellen/OIDs richten statt ganze Bäume abzufragen.

C) Discovery zähmen¶

Discovery-Scans belegen den Collector zeitweise stark.

Automatische Scans seltener planen oder nur bei Änderungen manuell scannen.
Subnetze, die nicht gescannt werden sollen, in der Discovery mit Subnet ausschließen dauerhaft fernhalten.
Mehrere Collectors: jeder scannt sein eigenes Netz statt alles.

D) Hosts auf zweiten Collector aufteilen¶

Bei sehr vielen Hosts pro Collector oder stark unterschiedlichem Check-Mix lohnt sich ein zweiter Collector.

Neuen Collector anlegen: Tenants → Tenant → Collectors → Neuer Collector.
Auf der gewünschten VM installieren (siehe Collector).
Hosts umziehen: Host-Detail → Host verwalten → Verbindung → Collector (passive Checks). Die Zuordnung gilt je Host.

Aufteilungs-Heuristiken:

Nach Tenant — jeder Kunde hat ohnehin eigene Collectors (ein Collector gehört zu genau einem Tenant).
Nach Subnetz — 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 Speichernutzung mehr Ressourcen geben. Ab 4 Kernen steigt die Parallelität automatisch mit (siehe oben).

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	lieber einen zweiten Collector anlegen

Diese Werte sind Richtwerte; der Check-Mix (viele SSH- und Walk-Checks) zählt mehr als die Host-Zahl.

F) Langsame Ziele¶

Die Zeitlimits der Checks sind fest eingebaut und nicht pro Check einstellbar: SNMP 5 s mit einer Wiederholung (Walks 8 s mit zwei Wiederholungen), SSH-Verbindungsaufbau 10 s. Ein HTTP-Check hat ein eigenes Feld timeout (Standard 10 s), ein Plugin-Check ebenfalls (Standard 30 s). Liegt ein Ziel ständig an der Grenze, ist meist das Gerät oder das Netz das Problem — Firmware aktualisieren oder weniger abfragen.

G) Notschalter am Server¶

Die Parallelität lässt sich für alle Collectors fest vorgeben (collector_check_concurrency in system_settings, 16 = Verhalten früherer Versionen). Normalerweise nicht nötig.

Wann ist es nicht der Collector?¶

Pipeline-Verzögerung, aber der Collector ist ruhig → Server-seitig: zu wenige Worker. Siehe Skalierung.
Einzelner Host hängt → das Ziel-Gerät antwortet langsam (oft der SNMP-Dienst). Firmware aktualisieren oder weniger OIDs abfragen.
Discovery-Scan läuft lange → bei großen Subnetzen (/16 = 65 536 Adressen) normal. Auf kleinere Subnetze einschränken.

Den Collector selbst überwachen¶

Einen Host für die Collector-VM anlegen (IP der VM, ein Linux-Profil).
Am einfachsten den Vesana-Agent auf der Collector-VM installieren — er liefert CPU, Speicher und Platte ohne weiteren Aufwand.
Ohne Agent: die VM über einen anderen Collector oder den Aktiven Collector prüfen — prüft sie sich selbst, merkt niemand, wenn sie weg ist.

Fällt ein Collector aus, meldet Vesana das ohnehin als „Collector offline" mit der Zahl der unbeobachteten Hosts und Checks.