Zum Inhalt

Vesana-Bibliothek

Die Vesana-Bibliothek ist der Katalog der Geräteprofile, die Vesana veröffentlicht — fertige Definitionen für SNMP-/SSH-/Agent-Checks je Gerätetyp, gegen echte Geräte verifiziert. Profile in der Bibliothek kommen nur von Vesana; Instanzen laden keine Profile oder MIBs hoch und teilen nichts.

Fragen, Wünsche und Rückmeldungen zu Profilen laufen über das öffentliche GitHub-Repository vesana-org/community. community.vesana.org hat keine Website und keine Anmeldung mehr.

Wie der Zugriff funktioniert

Deine Vesana-Instanz muss nicht selbst öffentlich erreichbar sein. Alle Anfragen an die Bibliothek laufen server-zu-server über deinen eigenen Backend-Prozess; das Frontend spricht nur deine eigene API an. Ist die Bibliothek nicht erreichbar, läuft die restliche Instanz unbeeinträchtigt weiter (siehe Ohne Internet).

Nur signierte Profile

Jede Profilversion in der Bibliothek ist von Vesana signiert. Die Instanz prüft die Signatur gegen eingebaute Schlüssel und installiert nur signierte Versionen. Eine unsignierte oder veränderte Version wird nicht installiert, es wird nichts geschrieben.

Profile-Seite: Installiert und Verfügbar

Profile hat zwei Reiter:

  • Installiert — nur die Profile, die auf dieser Instanz vorhanden sind.
  • Verfügbar — Profile der Bibliothek, die noch nicht installiert sind. Jedes Profil hat eine Vorschau mit seinen Checks und den Knopf Installieren.

Im Host-Assistenten und in den Check-Auswahlen gibt es eine Liste: installierte Profile und Profile der Bibliothek zusammen, eigene Profile mit der Kennzeichnung Eigenes. Wählst du ein Profil der Bibliothek, das noch nicht installiert ist, wird es dabei automatisch installiert.

Installieren

Beim Installieren kommen referenzierte Monitoring-Scripts mit, ohne eigene Zustimmungsabfrage. Danach liegt das Profil lokal in deiner Instanz. Nutzen die Checks MIBs, holt die Installation sie aus der MIB-Bibliothek mit; eine selbst hochgeladene Fassung derselben MIB bleibt immer stehen. Ist die MIB-Bibliothek dabei nicht erreichbar, läuft die Installation ohne die MIBs weiter und sagt das.

Erkennungsregeln (sysObjectID-/sysDescr-Muster für die automatische Profil-Zuordnung) kommen mit dem Profil mit.

Ein installiertes Profil merkt sich seine Herkunft (Profil und Version in der Bibliothek), damit Vesana erkennt, ob eine neuere Version vorliegt.

Updates

Vesana entwickelt die Profile weiter — neue Checks, korrigierte OIDs, bessere Schwellwerte, verbesserte Scripts und Erkennungsregeln.

Automatisch: Installierte Bibliotheksprofile, die lokal nicht verändert wurden, aktualisiert Vesana stündlich im Hintergrund. Neue Checks kommen dabei auch an die Hosts, die das Profil nutzen. Jedes automatische Update steht im Diagnose-Log. Abschalten lässt sich das unter Admin → Updates mit dem Schalter „Profile automatisch aktualisieren" (nur Super-Admin, Vorgabe: an), siehe Updates.

Lokal geänderte Profile werden nie still überschrieben. Sie zeigen „Update verfügbar"; ein Super-Admin übernimmt das Update über den Vergleichsdialog. Ein Update von Hand übernehmen darf nur ein Super-Admin — das gilt auch, wenn das automatische Update abgeschaltet ist.

Der Vergleichsdialog an Aktualisieren ist zweistufig:

  1. Vorschau zeigt, welche Checks neu sind, welche bestehenden die neue Version verändert (Feld für Feld; Passwörter, Communities und private Schlüssel nur maskiert) und welche entfallen. Umbenannte Checks erkennt Vesana und benennt sie in place um — der Verlauf bleibt, es entstehen keine doppelten Check-Generationen.
  2. Übernehmen mit expliziter Auswahl:
    • Neue Checks kommen ins Profil. Bestehende Checks entfernt das Update nicht von selbst.
    • Verbundene Hosts ebenfalls mit den neuen Checks versorgen — vorausgewählt: Hosts, die das Profil nutzen, bekommen die neuen Checks angehängt. Das läuft im Hintergrund: die Antwort kommt sofort, am Profil steht „Wird auf Hosts angewendet: 120 von 500", danach das Ergebnis. Ein Neustart der Instanz mittendrin bricht das nicht ab — der Lauf wird fortgesetzt und legt nur an, was noch fehlt. Lässt er sich nicht fortsetzen (Profil gelöscht, Konto nicht mehr aktiv), steht der Grund am Profil und im Diagnose-Log. Pro Profil läuft höchstens ein Lauf; ein weiteres Update davor wird abgewiesen. Optionale Checks des Profils werden dabei nicht angehängt; das Ergebnis nennt sie, ebenso Checks, die an einem Gerät nicht angelegt werden konnten (Ausführungsmodus dort nicht möglich).
    • Verbesserte bestehende Checks — auf neuen Stand heben? — je Check eine Auswahl, alle geänderten sind vorausgewählt. Ein ausgewählter Check übernimmt Beschreibung, Config, Intervall, Schwellwerte, Modus und Info-Modus aus der neuen Version. Abwählen lässt den Check unverändert. Eigene Anpassungen pro Host (Overrides) bleiben in jedem Fall erhalten.
    • Typ-Konflikte (gleicher Name, anderer Check-Typ) lassen sich je Check auf den neuen Typ umstellen (Verlauf bleibt), und nicht mehr enthaltene Alt-Checks lassen sich in den Papierkorb legen. Ohne diese Auswahl bleiben solche Checks unverändert.

Scripts kommen mit. Ein Update bringt verbesserte Script-Inhalte mit, sofern das Script lokal unverändert ist. Selbst angepasste Scripts werden nie überschrieben. Verbesserte Erkennungsregeln kommen ebenfalls mit; selbst gepflegte Regeln bleiben unangetastet. MIBs, die das Profil neu braucht, kommen wie beim Installieren mit.

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.

Keine Installation und kein Update überschreibt etwas Eigenes: keine Host-Overrides, keine selbst angepassten Scripts, keine selbst gepflegten Erkennungsregeln, keine selbst hochgeladenen MIBs.

Wann eine neue Version ankommt

Eine neue Profilversion erreicht zuerst Instanzen mit Tester-Lizenz, alle anderen Instanzen etwa zwei Tage später.

Nach Ende des Update-Zeitraums der Lizenz werden keine Profil-Updates mehr übernommen, weder automatisch noch von Hand. Installieren bleibt möglich.

Ohne Internet

Jedes Vesana-Image enthält einen Stand der Bibliothek. Ist die Bibliothek nicht erreichbar, zeigt der Reiter Verfügbar diesen Stand („Offline — Bibliothek vom "), und Installieren funktioniert daraus — mit derselben Signaturprüfung. Updates brauchen die Online-Bibliothek.

Aktiv/Passiv-Varianten

Profile der Bibliothek 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 Datei

Eigene Profile bleiben auf deiner Instanz. Zwischen zwei Instanzen tauschst du sie als JSON-Bundle aus (Export über das Symbol Als Datei exportieren an der Profil-Zeile, Import über Import oben auf der Profil-Seite; auch ZIP-Dateien mit mehreren Bundles) 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. Ein Export enthält nur Scripts, die der Exportierende auch sehen darf; der Rest wird als ausgelassen gezählt. Für alle außer Super-Admins lässt der Export außerdem SNMP-Communities, Passwörter, private Schlüssel und als Passwort deklarierte Script-Werte weg. Erkennungsregeln aus einer importierten Datei übernimmt nur ein Super-Admin.

Bringt eine Bundle-Datei Script-Code oder eigene Kommandos mit, bestätigt der Importierende vorher seine Identität (Passkey, Code oder Passwort) — das gilt für jedes Konto.

Vesana fragt beim Datei-Import, ob die Scripts mitkommen sollen. Wählst du „Ohne Scripts", 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