Zum Inhalt

Collector

Der Collector ist eine Linux-VM im Kundennetz, die Remote-Checks ausführt:

  • SNMP (v1/v2c/v3) — Switches, Router, Firewalls, UPS, Storage
  • Ping — Erreichbarkeit
  • SSH — ssh_command, ssh_cpu, ssh_mem, ssh_disk
  • HTTP / HTTPS — http, ssl_certificate
  • Discovery — nmap-Scans

Er ist push-basiert: holt seine Konfiguration vom Server (GET /api/v1/config/collector/<id>), führt die Checks aus, schickt Ergebnisse zurück (POST /receiver/check-result).

Voraussetzungen

Was Mindestens Empfohlen
OS Debian 12, Ubuntu 22.04, RHEL 9, AlmaLinux 9, SUSE 15, Arch Debian 13
Architektur amd64 amd64
RAM 1 GB 2 GB ab ~500 Hosts
Disk 5 GB 20 GB
Outbound 443 zum Vesana-Server –
Netzwerksicht zum überwachten Subnetz –

nmap wird vom Installer mit installiert.

Schritt 1 — Collector in Vesana anlegen

Admin → Collectors → Neu:

Feld Beispiel
Name acme-collector-01
Tenant Acme GmbH
Beschreibung Kunden-LAN, Standort HQ

Nach Speichern zeigt Vesana einmalig einen API-Key:

vesana_<custom-prefix>_<32-bytes>

Sofort kopieren — danach nur noch Hash sichtbar.

Schritt 2 — Collector installieren

One-Command-Installer auf der Linux-VM, als root:

wget -qO- https://deine-domain.tld/collector/install.sh | bash -s -- API_KEY https://deine-domain.tld

Was passiert:

  1. Distro-Detection (Debian / RHEL / AlmaLinux / SUSE / Arch)
  2. Pakete: nmap, snmp (Client), ca-certificates, curl
  3. Binary nach /usr/local/bin/vesana-collector
  4. Config-Datei: /etc/vesana/collector.env 
    VESANA_SERVER=https://deine-domain.tld
VESANA_API_KEY=vesana_xxxxx_yyyy...
VESANA_LOG_LEVEL=info
  5. systemd-Unit /etc/systemd/system/vesana-collector.service
  6. systemctl enable --now vesana-collector

Re-run-safe — überschreibt Binary + Config.

Schritt 3 — Verifizieren

In Vesana: Admin → Collectors → der Collector sollte innerhalb von 60 s einen Heartbeat schicken (Zeitstempel aktualisiert sich). „Online" heißt: zuletzt vor weniger als 3 Minuten gesehen — dasselbe Fenster gilt einheitlich für Dashboard-Kachel, Collector-Liste und Tenant-Statistik.

Auf der Collector-VM:

sudo systemctl status vesana-collector
sudo journalctl -u vesana-collector -f

Schritt 4 — Hosts dem Collector zuweisen

Beim Anlegen eines Hosts mit passive-Checks: Collector aus dem Dropdown wählen. Bestehende Hosts: Host-Detail → Collector zuweisen.

Der Collector pollt seine Config alle 60 s — neue Hosts/Services erscheinen also mit kurzem Delay. Schwellwert-Änderungen (Warn/Critical) sind davon ausgenommen und wirken sofort: der Server wendet sie serverseitig auf jedes eingehende Ergebnis an, unabhängig vom letzten Config-Poll.

Discovery vom Collector

Discovery-Scans werden ebenfalls über den Collector ausgeführt. Workflow: Hosts → Discovery.

Der Collector erkennt dabei automatisch, welche Subnetze er sehen kann (lokale Netzwerk-Interfaces, Routing-Tabelle und optional ein SNMP-Walk der Default-Gateway-Routen) und meldet das an den Server zurück — das erleichtert die Auswahl sinnvoller Scan-Bereiche, ohne dass du das Subnetz von Hand recherchieren musst.

Log-Ingestion über den Collector

Der Collector-API-Key eignet sich auch dafür, Logs für mehrere Hosts gleichzeitig einzuliefern (POST /api/v1/logs/ingest mit X-API-Key statt Agent-Token). Typischer Fall: ein zentraler Syslog-Empfänger auf der Collector-VM sammelt Pakete von Switches, Firewalls und NAS-Systemen; jeder Log-Eintrag trägt seine eigene host_id, damit die Zuordnung zum richtigen Host stimmt. Cross-Tenant-Zuordnungen werden serverseitig abgewiesen.

Logging-Level erhöhen

sudo sed -i 's|^VESANA_LOG_LEVEL=.*|VESANA_LOG_LEVEL=debug|' /etc/vesana/collector.env
sudo systemctl restart vesana-collector

debug ist gesprächig — produktiv auf info zurück.

Mehrere Collectors

Bei größeren Umgebungen oder mehreren Standorten kannst du beliebig viele Collectors einrichten. Pro Standort einen Collector ist üblich. Hosts werden pro Service einem Collector zugeordnet — du kannst auch verschiedene Services eines Hosts an verschiedene Collectors hängen.

Lastverteilung erfolgt nicht automatisch — wenn ein Collector überlastet ist, manuell Hosts auf andere verteilen.

Auto-Update

Collector aktualisiert sich automatisch beim nächsten Config-Refresh (60 s) wenn der Server eine neuere Version meldet. Details: Agent-Versionierung — der Mechanismus ist gleich.

Troubleshooting

Collector zeigt nicht „online"

  1. Outbound 443 zum Server offen?
  2. DNS auflösbar?
  3. API-Key korrekt?
  4. journalctl -u vesana-collector --since '5 minutes ago'

Häufige Fehler siehe Agent-Troubleshooting — die Mechanik ist identisch.

SNMP-Check schlägt fehl

# Auf der Collector-VM testen:
snmpwalk -v 2c -c <community> <ziel-ip> .1.3.6.1.2.1.1.1.0

Wenn das schon scheitert, ist es nicht der Collector, sondern Netzwerk / SNMP-Config / Community.

Discovery findet nichts

# nmap-Scan manuell:
sudo nmap -sn 192.168.1.0/24

-sn ist Ping-Scan (kein Port-Scan). Wenn auch das nichts findet, ist die Subnetz-Sichtbarkeit das Problem.

Deinstallation

sudo systemctl stop vesana-collector
sudo systemctl disable vesana-collector
sudo rm /etc/systemd/system/vesana-collector.service
sudo rm -rf /etc/vesana
sudo rm /usr/local/bin/vesana-collector
sudo systemctl daemon-reload

In Vesana: Admin → Collectors → Löschen. Hosts, die diesem Collector zugewiesen waren, müssen anderen Collectors zugewiesen werden, sonst werden ihre Services NO_DATA.

Anschluss