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 begegnet er dir unter zwei Namen: der Admin-Reiter heißt Active-Checker, in Host-Dialogen steht „Aktiver Collector (Server prüft selbst)". 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.
- Maximal einer pro Instanz.
- 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 / 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, Automatisches Setup). 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.
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.
Wenn der Aktive Collector offline ist (Server-Fallback)¶
Ist kein Aktiver Collector online, übernimmt der Server selbst einen Teil der Checks:
- Ping, HTTP, SNMP-Standardwerte sowie SSH-Script-, Prozess- und Dienst-Checks laufen über diesen Fallback weiter — reduziert, aber nicht ausgefallen.
- Check-Typen, die nur das Collector-Binary kann (z. B. spezielle SNMP-Walks, Internetlinie), 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¶
- Nur ein Aktiver Collector pro Instanz — kein Cluster.
- 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.