Zum Inhalt

Community Hub

Der Community Hub (community.vesana.org) ist der zentrale Verteilungsweg für Geräteprofile — fertige Definitionen für SNMP-/SSH-/Agent-Checks je Gerätetyp, kuratiert und gegen echte Geräte verifiziert. Statt jedes Profil selbst zu bauen, durchsuchst du den Hub und importierst, was zu deiner Umgebung passt.

Wie der Zugriff funktioniert

Deine Vesana-Instanz muss nicht selbst öffentlich erreichbar sein — alle Hub-Anfragen laufen server-zu-server über deinen eigenen Backend-Prozess. Das Frontend spricht ausschließlich deine eigene API an, die wiederum den Hub kontaktiert. Ist der Hub gerade nicht erreichbar, zeigt die Oberfläche das sauber an (kein Absturz, nur „Community nicht erreichbar") — die restliche Instanz läuft unbeeinträchtigt weiter.

Profile durchsuchen

/profiles → Community durchsuchen:

  • Volltextsuche + Filter nach Kategorie/Vendor
  • Jedes Ergebnis zeigt, ob es kompatibel mit deiner Vesana-Version ist und ob es bereits importiert ist
  • Detail-Ansicht zeigt alle Profile-Checks vor dem Import

Importieren

Beim Import fragt Vesana, ob referenzierte Monitoring-Scripts mitkommen sollen (siehe unten „Scripts wandern mit"). Danach liegt das Profil lokal in deiner Instanz — änderbar wie jedes selbst angelegte Profil, unabhängig vom Hub.

Ein importiertes Profil merkt sich seine Herkunft (Quell-ID + Versionsstand im Hub), damit Vesana später erkennt, ob eine neuere Version verfügbar ist.

Updates: Vorschau, dann Übernehmen

Der Hub entwickelt Profile weiter — neue Checks, korrigierte OIDs, bessere Schwellwerte, verbesserte Scripts und Erkennungsregeln. Für jedes importierte Profil prüft Vesana, ob der Hub eine neuere Version hat (/profiles → Community-Updates); ein Knopf aktualisiert alle Community-Profile auf einmal.

Ein Update wird nie stillschweigend übernommen. Der Ablauf ist zweistufig:

  1. Vorschau zeigt einen Diff: welche Checks sind neu, welche bestehenden hat die neue Version verändert (Feld für Feld), welche entfallen. Umbenannte Checks erkennt Vesana und benennt sie in place um — der Verlauf bleibt, es entstehen keine doppelten Check-Generationen. Typ-Konflikte (gleicher Name, anderer Check-Typ) werden ausgewiesen und lassen sich per Klick heilen; nicht mehr enthaltene Alt-Checks wandern optional in den Papierkorb.
  2. Übernehmen mit expliziter Auswahl:
    • Neue Checks ins Profil aufnehmen — Standard.
    • Verbundene Geräte mitaktualisieren — vorausgewählt: Hosts, die das Profil bereits nutzen, bekommen die neuen Checks angehängt. Ohne das landet die Verbesserung nur im Profil, und die Geräte bleiben auf dem alten Stand. Das Ergebnis nennt auch die Checks, die an einem Gerät nicht angelegt werden konnten (etwa weil der Ausführungsmodus dort nicht möglich ist).
    • Optional + einzeln wählbar: bestehende, gleichnamige Checks auf den Hub-Stand heben (Config, Intervall, Schwellwerte). Standardmäßig aus — deine lokalen Anpassungen an einem Check bleiben unangetastet, bis du ihn explizit zum Refresh auswählst.

Scripts kommen mit. Ein Profil-Update bringt verbesserte Script-Inhalte mit, sofern das Script lokal unverändert ist. Selbst angepasste Scripts bleiben stehen und werden im Ergebnis getrennt ausgewiesen („lokal behalten"). Verbesserte Erkennungsregeln holt „Aktualisieren" ebenfalls nach; selbst angepasste Regeln bleiben unangetastet.

Geerbte Werte bleiben geerbt. Ein Host-Check hält nur fest, was du an ihm wirklich geändert hast — alles andere folgt dem Profil und damit jedem Update. Die sechs Telemetrie-Checks im Hintergrund (System-Übersicht, Netzwerk, Sicherheit, Inventar, Lebenszyklus, Hardware) tauchen in keinem Bundle und keinem Update-Dialog auf.

Der Import überschreibt nie ungefragt eigene Anpassungen. Du entscheidest pro Check, ob der Hub-Stand deine lokale Version ersetzen soll.

Aktiv/Passiv-Varianten

Profile aus dem Hub können Checks in mehreren Modi enthalten — passiv (über den Collector), aktiv (über den Aktiven Collector) oder Agent, je nachdem, was für den Check-Typ sinnvoll ist. Beim Anwenden eines Profils auf einen Host zählt der tatsächliche Modus des Hosts: Agent-Checks werden nur auf Agent-verwalteten Hosts angelegt, passive/aktive SNMP- und Netzwerk-Checks brauchen einen zugeordneten Collector bzw. laufen über den Aktiven Collector. Nicht passende Checks werden nie still übersprungen, sondern in der Antwort als skipped_checks gemeldet.

Profil-Export/-Import als Bundle

Unabhängig vom Hub kannst du Profile auch direkt zwischen zwei Instanzen austauschen — als JSON-Bundle (Download über /profiles → Export) oder per API (GET /profiles/{id}/export, POST /profiles/import).

Referenzierte Monitoring-Scripts wandern mit. Ein Profil, dessen Checks auf ein eigenes SSH-/Agent-Script verweisen, funktioniert nach dem Import auf einer anderen Instanz nur, wenn das Script dort auch existiert — sonst zeigt die Check-Config ins Leere und der Check läuft still nie (kein Ergebnis, kein Fehler). Deshalb trägt das Bundle referenzierte Scripts als eigenes Feld mit; sie werden beim Import als globale, wiederverwendbare Scripts angelegt (idempotent — ein zweiter Import derselben Scripts legt sie nicht doppelt an).

Globale Scripts anzulegen ist Super-Admin-Sache (sie werden an alle Mandanten ausgeliefert). Importiert ein Mandanten-Admin eine Bundle-Datei, kommt das Profil trotzdem an; die mitgelieferten Scripts werden übersprungen und gezählt, die betroffenen Checks bleiben ohne Script. Der reguläre Weg über den Hub — Import und „Profil aktualisieren" — ist davon nicht betroffen: dort holt der Server das Bundle selbst vom konfigurierten Hub, und Script-Verbesserungen erreichen weiterhin jede Instanz. Ein Export enthält nur Scripts, die der Exportierende auch sehen darf; der Rest wird als ausgelassen gezählt.

Vesana fragt beim Import explizit, ob die Scripts mitkommen sollen — falls du „Ohne Scripts" wählst, weist ein Hinweis darauf hin, dass Script-abhängige Checks danach ohne Ergebnis bleiben, bis du die Scripts manuell nachlegst.

Details zur Profil-Oberfläche selbst (Klonen, Threshold-Edit, Reset für Builtins): Profile bearbeiten.

Anschluss