Aktiver Collector (Active-Checker)¶
Der Aktive Collector ist der dritte Monitoring-Modus: Statt einer Linux-VM im Kundennetz führt der Vesana-Server selbst die Checks aus. Technisch ist es dasselbe Collector-Binary wie beim regulären Collector — es läuft nur als eigener Dienst direkt auf der Vesana-Maschine. In der Oberfläche heißt er meist Active-Checker — als Admin-Reiter und als Prüfweg in Host- und Check-Dialogen; die Übersicht unter Agent Lock nennt ihn „Aktiver Collector (Vesana-Server)". Früher hieß er Check-Executor.
Eigenschaften¶
- Server-global, tenant-übergreifend: Ein Aktiver Collector bedient Checks über alle Tenants der Instanz. Er erscheint deshalb bei keinem Tenant als Collector und belegt kein Collector-Kontingent.
- Einer oder mehrere: Weitere Aktive Collectors — auf dieser oder einer anderen Maschine — teilen sich die Checks (siehe Mehrere Aktive Collectors).
- Nie als Collector eines Hosts wählbar. Ein Host ohne zugewiesenen Collector läuft automatisch über den Aktiven Collector; ein Collector, der entfernt oder gelöscht wird, gibt seine Hosts an ihn ab, und ihre Checks laufen weiter (ab v1.9.437 auch beim Löschen — vorher blieben sie auf No Data).
- Kurzer Poll-Zyklus (2 Sekunden für Sofort-Aufträge) — dieses Nachfragen zählt als Lebenszeichen, der Aktive Collector gilt also nicht schon nach zwei Minuten ohne Ergebnis als offline.
Wann sinnvoll¶
- Checks gegen Ziele, die der Server selbst erreicht (Webseiten, DNS, Zertifikate, Geräte im Netz des Servers).
- Schneller Start: Checks laufen ab dem ersten Tag, ohne dass erst ein Collector beim Kunden ausgerollt werden muss.
- Als Ergänzung, solange (noch) kein dedizierter Collector existiert — sobald einer da ist, ziehst du Hosts einzeln um.
Einrichtung¶
Admin → Agents & Collectors → Active-Checker zeigt den Status (Nicht installiert / Online / Installiert · Offline) und einen 7-Tage-Verfügbarkeitsbalken. Denselben Balken mit derselben Bewertung zeigen die Mandanten-Seite und das Host-Detail (ab v1.9.437) — Zeiträume ohne Urteil, etwa vor dem ersten Heartbeat eines frisch angelegten Collectors, bleiben dabei neutral grau statt fälschlich grün; ohne ein einziges Urteil steht „—".
Auf frisch aufgesetzten Instanzen richtet sich der Aktive Collector von selbst ein, sobald der Einrichtungs-Assistent abgeschlossen ist — „Vesana starten" wartet sogar, bis er läuft. Klappt das nicht, zeigt die Seite ein Banner mit dem Warte- oder Fehlerzustand und versucht es in regelmäßigen Abständen erneut. Manuell geht es jederzeit per Knopfdruck: Die Seite legt den Collector-Datensatz an, zeigt den API-Key einmalig im Klartext und liefert das Install-Snippet für die Vesana-Maschine.
Der Aktive Collector aktualisiert sich selbst — auch dann, wenn Vesana nicht auf Port 443 läuft (er nutzt die Adresse, unter der er den Server nachweislich erreicht).
Server-seitige Prüfung pro Tenant freigeben¶
Ab v1.9.437 entscheidet der Super-Admin pro Tenant, was über den Server laufen darf — zwei Schalter je Tenant unter Admin → Agents & Collectors → Active-Checker:
| Schalter | Wirkung |
|---|---|
| Netzwerk-Checks über den Server | Checks im Modus Active-Checker (Ping, HTTP, SNMP, SSH …) für Nutzer dieses Tenants |
| Eigene Plugins auf dem Server | Script-/Kommando-Checks, die eigenen Code auf der Vesana-Maschine ausführen |
- Instanzen mit einem Tenant sind automatisch freigegeben; Super-Admins sind nie eingeschränkt — die Freigabe gilt für alle anderen Nutzer des Tenants.
- Checks, die vor der Einführung dieser Regel bestanden, laufen unverändert weiter — sie gelten als vom Betreiber eingerichtet (ab v1.9.444; in v1.9.437–443 standen sie auf Instanzen mit mehreren Tenants nach dem Update auf Unknown).
- Ohne Freigabe lehnt Vesana das Anlegen oder Ändern solcher Checks sofort mit Klartext ab (Assistent, Editor, Sammel-Bearbeiten). Ein gesperrter Check läuft nicht und meldet den Grund als Unknown; im Check-Detail steht der Weg zur Freigabe.
- Vor dem Ausschalten nennt die Seite die Zahl der betroffenen Checks; jede Änderung landet im Audit-Log. Unter Standard für neue Tenants legst du fest, was neu angelegte Tenants von Anfang an dürfen.
- Server-interne Adressen (Loopback, Docker-Netze, eigene Interface-Adressen) sind für nicht-privilegierte Checks gesperrt — außer der Check wurde von einem Super-Admin gespeichert (das steht dann am Check). Ein eigener Collector im Kundennetz prüft sein Netz weiterhin uneingeschränkt.
Discovery-Einstellungen nur für Super-Admins¶
Der Aktive Collector gilt für die ganze Instanz. Seine Discovery-Einstellungen — DNS-Server, SNMP-Communities, Subnetz-Ausnahmen, manuelle Subnetze und Netz-Bezeichnungen — ändern deshalb nur Super-Admins; andere Konten erhalten beim Speichern eine Ablehnung (403), auch mit dem Recht, Collectors zu bearbeiten. Bei regulären Collectors bleibt es beim Recht des Tenants. Auf Instanzen mit einem Tenant, deren Admin Super-Admin ist, ändert sich nichts.
Auf Instanzen mit mehreren Tenants gilt außerdem: Netze, die der Aktive Collector selbst kennt (Schnittstellen, Routen, ARP, LLDP), sehen nur Konten mit Zugriff auf alle Tenants; alle anderen sehen nur Netze aus Scans ihres eigenen Tenants. Scans, Zeitplan und „Alles scannen" über den Aktiven Collector gehören dem Tenant des Nutzers und brauchen dessen Server-Freigabe (siehe oben). SNMP-Communities aus Scans lernt der Aktive Collector nur, wenn die Instanz genau einen Tenant hat.
Sofort-Checks¶
„Jetzt prüfen" funktioniert beim Aktiven Collector wie bei Agent und regulärem Collector: Der Auftrag kommt binnen Sekunden an, das Ergebnis erscheint direkt im Panel. Bei langen Messungen (z. B. dem Internetlinien-Speedtest) bleibt „läuft noch …" stehen, bis das Ergebnis da ist; währenddessen ist „Jetzt prüfen" gesperrt. Antwortet der Aktive Collector nicht, zeigt Vesana das als „nicht erreichbar" — unterscheidbar von einer laufenden Messung.
Mehrere Aktive Collectors¶
Ein Aktiver Collector nutzt alle Kerne seiner Maschine. Reicht das nicht — die Seite meldet dann „Kommt nicht hinterher" und die Instanz-Gesundheit nennt den Grund —, kommt ein weiterer dazu. Jeder aktive Check gehört dann genau einem Aktiven Collector; die Zuteilung erfolgt je Gerät, alle Checks eines Geräts laufen beim selben.
Hinzufügen: Admin → Agents & Collectors → Active-Checker → Aktiven Collector hinzufügen. Du wählst, wo er läuft:
- Andere Maschine — der übliche Weg. Der Befehl prüft das Zertifikat des Servers über einen Pin (auch bei selbstsigniertem Zertifikat) und wird auf der neuen Maschine als root ausgeführt. Die Maschine muss dieselben Ziele erreichen wie der Server — jeder Aktive Collector kann jeden aktiven Check bekommen.
- Dieser Server (weitere Instanz) — ein zweiter Dienst
(
vesana-active-collector-<name>) auf der Vesana-Maschine. Lohnt sich selten, weil ein Aktiver Collector bereits alle Kerne nutzt.
Ein neuer Aktiver Collector bekommt seinen Anteil, sobald er 5 Minuten ohne Unterbrechung läuft; bis dahin prüfen die anderen weiter. Einzige Ausnahme: Starten alle gemeinsam (Erstinstallation, Rückkehr nach einem längeren Ausfall des Servers), teilen sich die, die innerhalb einer Minute anlaufen, die Checks sofort. Die Liste zeigt je Aktivem Collector Zustand (online, läuft an, offline), wie viele Geräte und Checks er gerade prüft, ob er hinterherkommt, und die Maschine.
Der primäre (in der Liste markiert, normalerweise der auf der Vesana-Maschine) macht zusätzlich, was an den Server gebunden ist: Discovery-Scans, „Netze finden", die Internetlinie und lokale Plugins. Fällt er aus, laufen diese Checks im Server-Ersatzweg (siehe unten) — die übrigen übernehmen die anderen Aktiven Collectors. „Zum primären machen" verlegt die Rolle; der primäre selbst lässt sich nicht entfernen.
Ausfall und Rückkehr:
- Meldet sich ein Aktiver Collector 2 Minuten nicht, übernehmen die anderen
seine Checks. Nach 3 Minuten steht im Diagnose-Log
active_collector_offline(wer übernommen hat), und die Admin-Übersicht nennt den Grund. Checks mit sehr kurzem Intervall können in dieser Zeit kurz „No Data" zeigen — die Daten fehlten tatsächlich. - Kommt er zurück, bekommt er seinen Anteil erst nach 5 Minuten ohne Unterbrechung zurück; ein Aktiver Collector, der ständig weg und wieder da ist, verschiebt die Checks also nicht hin und her.
- Verliert ein Aktiver Collector die Verbindung zum Server, hört er auf zu prüfen: ein weiterer nach 90 Sekunden (bevor ein anderer übernimmt), der primäre nach 2½ Minuten (kurz nachdem ein anderer übernommen hat) — kein Gerät wird auf Dauer doppelt geprüft. Gibt es nur einen Aktiven Collector (oder ist die Verteilung ausgeschaltet), prüft er immer weiter.
„Jetzt prüfen" geht an den Aktiven Collector, dem der Check gehört.
Agent Lock gilt je Aktivem Collector: jede Maschine (und jede Instanz) hat ihre eigene Freigabe.
Entfernen: Seine Checks übernehmen sofort die anderen, sein Schlüssel gilt nicht mehr. Den Dienst entfernst du auf der Maschine selbst — der Installer nennt am Ende den vollständigen Befehl. Für die Standard-Instanz:
sudo systemctl disable --now vesana-active-collector-update.path vesana-active-collector
sudo rm -f /etc/systemd/system/vesana-active-collector.service \
/etc/systemd/system/vesana-active-collector-update.{path,service}
sudo systemctl daemon-reload
sudo rm -rf /var/lib/vesana-active-collector /etc/vesana-active-collector /opt/vesana-active-collector
Bei einer weiteren Instanz hängt an allen Namen -<name>.
Server-interne Adressen auf weiteren Aktiven Collectors: Ein weiterer Aktiver Collector sperrt für Checks ohne Super-Admin-Freigabe dieselben Ziele wie der Server — die Netze des Servers (die meldet ihm der primäre) und die Netze seiner eigenen Maschine (Loopback, eigene Adressen, lokale Subnetze). Geräte im lokalen Netz der zweiten Maschine prüft er also nur mit Checks, die ein Super-Admin gespeichert hat. Die Netze des Servers kennt er nur über den primären: Läuft der primäre nicht auf der Vesana-Maschine (zum Beispiel nach „Zum primären machen" für einen entfernten), meldet er die Netze SEINER Maschine — die des Vesana-Servers sind dann für die anderen nicht mehr gesperrt. Der primäre gehört deshalb auf die Vesana-Maschine.
Notschalter¶
Beide Schalter liegen in den Systemeinstellungen und wirken ohne Neustart nach wenigen Sekunden. Die Verteilung lässt sich auch in der Liste ausschalten.
| Schlüssel | Wert für „wie vorher" | Was es tut | Wann zurückschalten |
|---|---|---|---|
active_collector_sharing_enabled |
false |
Aus: nur der primäre prüft alle aktiven Checks, weitere Aktive Collectors bekommen keine. | Wenn Checks auf einer anderen Maschine nicht laufen (anderes Netz, fehlende Erreichbarkeit) oder im Diagnose-Log ac_result_not_responsible auftaucht. |
collector_native_ping_enabled |
false |
Ping-Checks laufen über einen ICMP-Socket des Collectors statt über das Programm ping — dasselbe Ergebnis, deutlich weniger Last. Aus: wieder über das Programm. Gilt für alle Collectors ab dieser Version. |
Wenn Ping-Werte nach dem Update anders aussehen als vorher. Darf das Betriebssystem den Socket nicht öffnen, nimmt der Collector von selbst das Programm und meldet collector_ping_fallback im Diagnose-Log. |
INSERT INTO system_settings (key, value) VALUES ('active_collector_sharing_enabled', 'false')
ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value;
Wenn der Aktive Collector offline ist (Server-Fallback)¶
Ist kein Aktiver Collector online (bei mehreren: keiner), übernimmt der Server selbst einen Teil der Checks:
- Ping, Port, HTTP und HTTP-JSON, einfache SNMP-Werte (
snmp,snmp_string,snmp_interface) sowie SSH-Checks (CPU, RAM, Disk, Kommando/Script, Prozess, Dienst) laufen über diesen Fallback weiter — reduziert, aber nicht ausgefallen. Auch hier gelten Server-Freigabe und die Sperre server-interner Adressen. - Check-Typen, die nur das Collector-Binary kann (z. B. SNMP-Walks und -Tabellen, SSL-Zertifikat, vSphere, Internetlinie, Plugins), gehen auf Unknown mit einer klaren Meldung, solange kein Aktiver Collector läuft.
Sobald er wieder online ist, übernimmt er die betroffenen Checks automatisch — keine doppelte Ausführung, keine manuelle Umschaltung.
Warnung: API-Key-Regenerierung trennt sofort¶
API-Key nie ohne unmittelbaren Plan regenerieren
Wird der API-Key des Aktiven Collectors neu generiert, wird der alte Key sofort deaktiviert — der laufende Dienst verliert augenblicklich die Verbindung, bis der neue Key auf der Maschine eingetragen und der Dienst neu gestartet wird. Regeneriere den Key nur, wenn du direkt danach Zugriff auf die Vesana-Maschine hast. Dasselbe gilt für API-Keys regulärer Collectors.
Grenzen¶
- Mehrere Aktive Collectors teilen sich die Checks nach Geräten, nicht nach Netzen: Jeder muss alle Ziele erreichen können. Für Netze, die nur von einer bestimmten Stelle aus erreichbar sind, ist ein regulärer Collector die richtige Wahl.
- Er sieht das Netzwerk aus Sicht des Servers, nicht aus Sicht des Kundennetzes. Für Checks, die eine Sicht aus dem Kundennetz brauchen, bleibt der reguläre Collector die richtige Wahl.