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
  • Port — TCP-Erreichbarkeit
  • SSH — ssh_command, ssh_cpu, ssh_mem, ssh_disk, ssh_process, ssh_service
  • HTTP / HTTPS — http, http_json, ssl_certificate
  • vSphere/ESXi, Internetlinie, API-Scripts und Plugins
  • Discovery — Netzwerk-Scans mit eigenem Scanner (ARP, ICMP, TCP, Dienst-Erkennung)

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/api/v1/results). Er läuft nicht als root, sondern unter dem eigenen Systemkonto vesana-collector.

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 –

Für die Discovery ist kein Zusatzpaket nötig — der Scanner ist Teil des Collectors.

Schritt 1 — Collector in Vesana anlegen

Collectors gehören zu einem Tenant und werden dort angelegt: Tenants → Tenant aufklappen → Abschnitt Collectors → Neuer Collector. Einziges Feld ist der Name (z. B. acme-collector-01); Collector erstellen legt ihn an.

Danach zeigt Vesana einmalig den API-Key (vesana_…) zusammen mit dem fertigen Installationsbefehl. Sofort kopieren — gespeichert wird nur ein Hash. Später erzeugt Installer → Key erneuern am Collector einen neuen Key (der alte gilt dann sofort nicht mehr).

Schritt 2 — Collector installieren

Den Befehl aus dem Dialog kopieren und auf der Linux-VM als root ausführen. Der Dialog hat drei Reiter: Online (1-Liner), Online (interaktiv) (fragt Server-URL und Key ab, nichts landet in der Shell-History) und Offline-Bundle (Archiv mit Binary und Installer für VMs ohne Internet). Optionen darüber:

  • Server-URL (von der Kunden-VM erreichbar) — die Adresse, die der Collector in seine Konfiguration schreibt.
  • Server hat ein selbst-signiertes Zertifikat (TLS-Prüfung überspringen) — nur für Server ohne Zertifikats-Pin. Ist am Server ein Zertifikat gepinnt (Agent-Gateway hinter eigenem Proxy), trägt der Befehl den Pin selbst mit (VESANA_CERT_PIN=… VESANA_CERT_SPKI_PIN=…) und lädt per curl --pinnedpubkey — dann wird curl auf der VM gebraucht.
  • Diesen Server vor Vesana schützen (Agent Lock) — setzt VESANA_LOCK=1, siehe Agent Lock.

Grundform ohne Optionen:

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

Was passiert:

  1. Optionale Pakete: Nagios-/Monitoring-Plugins über den vorhandenen Paketmanager (apt, dnf/yum, zypper, pacman). Schlägt das fehl, gibt es eine Warnung, die Installation läuft weiter.
  2. Collector-ID über den API-Key auflösen, Binary laden und prüfen (Linux-Programm, Probelauf). Ein laufender Collector wird erst danach gestoppt.
  3. Systemkonto vesana-collector anlegen; Zustand unter /var/lib/vesana-collector.
  4. Programmdatei root-eigen nach /opt/vesana-collector/vesana-collector — der Dienst und von ihm ausgeführte Scripts können sie nicht ersetzen. Eine alte Kopie unter /usr/local/bin wird entfernt.
  5. Config-Datei /etc/vesana/collector.env (Rechte 600, gehört dem Dienstkonto): 
    VESANA_API_URL=https://deine-domain.tld
VESANA_RECEIVER_URL=https://deine-domain.tld/receiver
VESANA_API_KEY=vesana_…
VESANA_COLLECTOR_ID=<uuid>
    Dazu je nach Option VESANA_SERVER_CERT_SHA256 (Zertifikats-Pin) oder VESANA_INSECURE_SKIP_VERIFY=true.
  6. systemd-Dienst vesana-collector (eigenes Konto, schreibgeschütztes System, nur die Netz-Berechtigungen für Ping und Discovery) plus zwei Helfer: vesana-collector-update.path (spielt signierte Updates als root ein) und vesana-collector-uninstall.path (Selbst-Deinstallation auf Anweisung aus Vesana).
  7. Dienst aktivieren und starten.

Re-run-safe — ein erneuter Lauf aktualisiert Binary und Config.

Schritt 3 — Verifizieren

In Vesana: Tenants → Tenant öffnen → 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

Auf welcher Maschine läuft der Collector?

Unter jedem Collector steht „Läuft auf:". Der Collector meldet bei jedem Lebenszeichen seinen Rechnernamen und die Adressen seiner Netzwerkkarten.

  • Ist die Maschine in Vesana als Host angelegt — mit derselben IP oder demselben Rechnernamen, im selben Tenant —, steht dort ein Link auf diesen Host.
  • Sonst stehen Rechnername und IP-Adressen dort.
  • Passen mehrere Hosts gleich gut, gibt es keinen Link; der Hinweis beim Darüberfahren sagt das.
  • Ältere Collector-Versionen melden den Rechner noch nicht — bis zu ihrem Update steht dort die Adresse, von der ihre Anfragen ankommen. Hinter einer Firewall mit NAT ist das die Adresse der Firewall, nicht der VM.

Gesucht wird bewusst nur im Tenant des Collectors: Kundennetze überschneiden sich, eine gleiche IP bei einem anderen Kunden ist ein anderes Gerät. Der Aktive Collector gehört keinem Tenant und wird in allen Tenants gesucht, die du sehen darfst.

Schritt 4 — Hosts dem Collector zuweisen

Ein Host hat genau einen Collector (oder keinen — dann laufen seine Netzwerk-Checks über den Aktiven Collector). Beim Anlegen eines Hosts oder beim Hinzufügen von Checks wählst du als Prüfweg „Collector" und den Collector des Tenants. Bestehende Hosts: Host-Detail → Host verwalten → Verbindung → Collector (passive Checks).

Checks, die der Geräte-Scan anlegt, laufen auf Hosts mit Collector ebenfalls über diesen Collector.

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.

Collector-VM härten

Läuft auf der VM nur der Collector, lässt sie sich deutlich enger einstellen als ein gewöhnlicher Server. Ein Script übernimmt das — es zeigt jeden Schritt vorher und lässt sich mit einem Befehl zurücknehmen: Collector-VM härten.

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 /receiver/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.

Log

Der Collector schreibt ins Journal (journalctl -u vesana-collector), Stufe Info; eine einstellbare Log-Stufe gibt es nicht. Mit LOG_FORMAT=json in /etc/vesana/collector.env und einem Neustart kommt das Log als JSON (ein erneuter Installer-Lauf schreibt die Datei neu, dann die Zeile wieder ergänzen).

Mehrere Collectors

Bei größeren Umgebungen oder mehreren Standorten kannst du beliebig viele Collectors einrichten. Pro Standort einen Collector ist üblich. Die Zuordnung gilt je Host — alle Collector-Checks eines Hosts laufen über denselben Collector.

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.

Die Collector-Datei liegt root-eigen unter /opt/vesana-collector/ — der Dienst selbst darf sie nicht ersetzen, auch kein Script, das er ausführt. Er lädt und prüft das Update (Signatur, Version) und legt es nur bereit; der systemd-Helfer vesana-collector-update.path setzt es als root ein, prüft die Signatur dabei erneut und startet den Dienst neu. Eine abgelehnte oder nicht eingespielte Datei ersetzt nichts: der Collector bleibt auf seiner Version, schreibt den Grund ins Log (journalctl -u vesana-collector, bzw. journalctl -u vesana-collector-update) und versucht es für dieselbe Version erst nach einer Stunde wieder. Installationen aus älteren Versionen stellt ein erneuter Lauf des Installers um.

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: Paket snmp bzw. net-snmp-utils):
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.

SSH-Check: „SSH-Schlüssel hat sich geändert"

Beim ersten Kontakt merkt sich Vesana den SSH-Host-Key des Geräts (Fingerabdruck, je Host bzw. je abweichendem Ziel und Port). Jede weitere Verbindung prüft dagegen. Bietet das Gerät einen anderen Schlüssel an, meldet der Check CRITICAL (SSH_HOST_KEY_MISMATCH) und meldet sich nicht an.

In der Check-Ansicht steht dann „SSH-Schlüssel hat sich geändert" mit dem bisherigen und dem jetzt angebotenen Fingerabdruck. Neuen Schlüssel übernehmen pinnt genau den angezeigten Fingerabdruck (braucht das Recht, den Host zu bearbeiten, und eine frische Identitätsbestätigung). Nur übernehmen, wenn das Gerät neu aufgesetzt wurde — sonst könnte jemand die Verbindung abfangen.

Discovery findet nichts

# Ein bekanntes Gerät aus dem Zielnetz anpingen:
ping -c 3 192.168.1.10

Antwortet auch das nicht, ist die Subnetz-Sichtbarkeit das Problem. Weitere Schritte: Discovery findet nichts.

Deinstallation

Am einfachsten aus Vesana: Tenants → Tenant → Collectors → Collector löschen und bei „Was passiert mit dem Collector auf seiner VM?" Deinstallieren wählen. Beim nächsten Kontakt entfernt sich der Collector vollständig (Dienst, Programm, Konfiguration, Dienst-Benutzer). Mit Installiert lassen ruht er nur; Details: Deaktivieren, Löschen, Wiederherstellen. Ist Agent Lock aktiv, deinstalliert er sich nicht selbst.

Von Hand auf der VM:

sudo systemctl disable --now vesana-collector vesana-collector-update.path vesana-collector-uninstall.path
sudo rm -f /etc/systemd/system/vesana-collector.service \
  /etc/systemd/system/vesana-collector-update.{path,service} \
  /etc/systemd/system/vesana-collector-uninstall.{path,service} \
  /usr/local/sbin/vesana-collector-uninstall
sudo rm -rf /opt/vesana-collector /var/lib/vesana-collector /etc/vesana /etc/vesana-lock/collector
sudo userdel vesana-collector
sudo systemctl daemon-reload

/var/lib/vesana-active-collector nur entfernen, wenn auf der Maschine kein Aktiver Collector läuft (Custom-Plugins teilen sich das Verzeichnis).

Beim Löschen in Vesana werden die Hosts des Collectors gelöst: Ihre Collector-Checks laufen ab sofort über den Aktiven Collector weiter. Ein Wiederherstellen des Collectors aus dem Papierkorb bringt diese Zuordnung nicht zurück — die Hosts dann wieder von Hand zuweisen.

Anschluss