Profile & Checks¶

Das wichtigste Konzept in Vesana. Wenn du diese Seite verstanden hast, fügen sich Discovery, SNMP-Picker, Effective-Config und Visuals automatisch zusammen.

Die zwei Stufen¶

flowchart LR
    subgraph "Profil — Was ist dieses Gerät?"
        P[Profil 'APC Smart-UPS']
        PC1[Profile-Check 'Battery Voltage']
        PC2[Profile-Check 'Output Load']
        PC3[Profile-Check 'Temperature 1']
        P --- PC1
        P --- PC2
        P --- PC3
    end

    subgraph "Hosts — Konkrete Geräte"
        H1[Host 'ups-server-room']
        H2[Host 'ups-rack42']
    end

    subgraph "host_services — Was wird tatsächlich überwacht?"
        S1[Service 'Battery Voltage']
        S2[Service 'Output Load']
        S3[Service 'Battery Voltage']
        S4[Service 'Output Load']
    end

    P --> H1
    P --> H2
    PC1 --> S1
    PC2 --> S2
    PC1 --> S3
    PC2 --> S4

Schicht	Was beschreibt sie	Tabelle
Profil	Gerätetyp + Capabilities + visueller Layout-Typ	`profiles`
Profile-Check	Eine Check-Definition pro Profil — Typ, Config, Schwellwerte	`profile_checks`
Host	Konkretes überwachtes Gerät, hat ein primäres Profil und optional weitere	`hosts`
Host-Service	Instanz eines Profile-Checks für einen Host, optional mit Overrides	`host_services`

Profil — was ist dieses Gerät¶

Ein Profil enthält:

Name + Beschreibung
Kategorie (server, network_device, ups, storage, vmhost, …)
Vendor (cisco, hpe, apc, …)
Capabilities:
- agent_capable — kann ein Agent installiert werden?
- snmp_enabled — wird SNMP unterstützt?
- ip_required — braucht das Profil eine IP?
- os_family — windows / linux / generic
sysOID-/sysDescr-Patterns — für Auto-Matching bei Discovery
Visual-Type (switch_portmap, ups_panel, nas_diskbay, firewall_panel)
Icon — aus der Icon-Bibliothek (Configuration → Icons)

Builtin vs. Custom¶

Profile sind entweder Builtin (mitgeliefert, is_builtin=true) oder Custom (selbst angelegt). Builtins können editiert werden — dann wird is_modified=true.

Reset gibt es je Check, nicht für das ganze Profil: Ein bearbeiteter Builtin-Check lässt sich auf seine Standardwerte zurücksetzen (nur Super-Admins), auf Wunsch samt den Overrides an allen Hosts. Hat ein Check keine mitgelieferten Standardwerte, lehnt Vesana den Reset ab, statt Erfolg zu melden.

Vesana-Bibliothek — der Verteilweg für Profile¶

Geräteprofile kommen aus der Vesana-Bibliothek — dem Katalog der Profile, die Vesana veröffentlicht und signiert. Eine neue Installation bringt keinen lokalen Profil-Katalog mit; die Erkennung bei der Discovery nutzt die Erkennungsregeln aus der Bibliothek. Neue Geräteprofile oder verbesserte Abdeckung müssen so nicht auf ein Vesana-Release warten.

Installieren legt ein Profil an; die MIBs, die seine Checks benutzen, kommen mit. Installiert werden nur von Vesana signierte Versionen.
Lokal unveränderte Profile aktualisiert Vesana stündlich automatisch. Hat die Bibliothek für ein lokal geändertes Profil eine neuere Version, steht daran „Update verfügbar"; ein Super-Admin übernimmt es über den Vergleichsdialog. Passwörter und Communities stehen in der Vorschau nur maskiert.

Profile-Check — was wird überwacht¶

Pro Profil gibt es N Profile-Checks. Jeder Profile-Check hat:

Feld	Bedeutung
`name`	Anzeigename, z. B. „Battery Voltage"
`check_type`	`ping`, `http`, `snmp`, `agent_cpu`, `agent_disk`, `snmp_string`, `snmp_table`, …
`check_config`	JSONB mit typ-spezifischen Optionen (OID, Path, Pattern …)
`interval_seconds`	Wie oft (Default 60 s)
`confirmation_interval_seconds`	Abstand zwischen Confirmation-Retries im `probing`-State (Default 10 s); wirkt nur, wenn der Server den Check selbst ausführt, nicht bei Agent/Collector
`confirmation_attempts`	Bestätigte Fehlschläge bis `probing → degraded` (Default 1)
`threshold_warn`	Warn-Schwelle
`threshold_crit`	Krit-Schwelle
`check_mode`	`active` / `passive` / `agent`
`value_type`	`gauge`, `counter`, `status`, `info`, `duration`
`script_id`	optional: Verweis auf einen Monitoring-Script
`auto_add`	wird der Check beim Profil-Apply automatisch erzeugt?
`sort_order`	Reihenfolge in der Check-Tabelle; am Profil per Ziehen einstellbar und Vorgabe für jedes Gerät mit diesem Profil, bis dort jemand selbst umsortiert
`chart_style`	Darstellung im Verlauf: `auto` (Vorgabe), `curve`, `band`, `both`; NULL = nicht gesetzt (= `auto`)
`is_modified`	wurde ein Builtin editiert?

Auto-Add¶

auto_add = true: beim Apply-Profile auf einen Host wird der Check automatisch erzeugt. auto_add = false: der Check ist im Profil definiert, aber nur als Option — Operator kann ihn explizit aktivieren.

Sinnvoll für Checks, die nicht auf jedem Modell vorhanden sind (z. B. Lüfter-Sensoren, die nur in fanless Switches fehlen).

Host-Service — Instanz mit Overrides¶

Wenn ein Profil auf einen Host angewendet wird, entstehen pro Profile-Check (mit auto_add=true) die host_services. Pro Service kannst du überschreiben, was im Profile-Check als Default steht:

Feld	Bedeutung
`display_name`	Anzeigename, kann pro Host abweichen
`profile_check_id`	FK auf den Profile-Check
`interval_override`	NULL = nimm den Profile-Check-Wert; gesetzt = nimm den Override
`chart_style_override`	NULL = nimm den Wert des Profile-Checks; sonst `auto`, `curve` (Kurve), `band` (Statusband) oder `both` (Kurve mit Band darunter) — wie der Verlauf des Checks gezeichnet wird
`config_overrides`	JSONB-Patch über `check_config`
`threshold_warn_override`	gleiche Logik
`threshold_crit_override`	gleiche Logik

Effective Config¶

Worker und Frontend rechnen für jeden Service die Effective Config aus — die Verschmelzung aus Profil-Default und Host-Override: Override-Felder ersetzen, alle anderen Felder bleiben aus dem Profile-Check.

flowchart LR
    PC[Profile-Check<br/>interval=60<br/>warn=80<br/>crit=95<br/>config={path:'/'}]
    HS[Host-Service<br/>interval_override=NULL<br/>warn_override=70<br/>config_overrides={path:'/var'}]
    EFF[Effective<br/>interval=60<br/>warn=70<br/>crit=95<br/>config={path:'/var'}]
    PC --> EFF
    HS --> EFF

Geerbt ist nicht überschrieben. Beim Speichern eines Host-Checks bleibt nur das als Override stehen, was sich vom Profilwert unterscheidet — ein Feld, dessen Wert dem Profil gleicht, ist kein Override. Deshalb zeigt der Host-Editor bei Schwellwerten „leer = geerbt" mit dem Profilwert als Platzhalter, und ein Profil-Update erreicht den Host weiterhin. (Früher fror jedes Speichern alle geerbten Werte als Host-Werte ein; Bestandsdaten wurden beim Update entpinnt.) Dasselbe gilt für die einstellbaren Werte eines Scripts.

Lebenszyklus eines Profile-Checks¶

sequenceDiagram
    participant U as User
    participant API
    participant DB
    participant R as Receiver
    participant W as Worker
    participant A as Agent/Collector

    U->>API: Profil 'APC Smart-UPS' apply auf Host 'ups-rack42'
    API->>DB: INSERT host_services (für jeden auto_add Check)
    A->>API: GET /agent/config oder /collector/config
    API->>DB: SELECT host_services + COALESCE(profile_checks)
    API-->>A: Effective Configs liefern
    A->>A: Check ausführen
    A->>R: Ergebnis senden
    R->>W: über den Redis Stream
    W->>DB: schreibt check_results, current_status
    W->>DB: Alert-Auswertung wenn Schwelle überschritten

Capabilities filtern Check-Typen¶

Im Frontend (Add-Service-Modal) und im Backend (POST /host-services/) werden Check-Typen kontextabhängig gefiltert:

Agent-Checks (agent_*) → nur Hosts mit profile.agent_capable = true und agent_managed = true
SNMP-Checks → nur Hosts mit profile.snmp_enabled = true
Netzwerk-Checks (ping, port, snmp, ssh_) → nur Hosts mit ip_address gesetzt
Profile-Checks werden zusätzlich OS-aware gefiltert: Linux-Hosts sehen keine Windows-spezifischen Checks und umgekehrt

So unterscheidet ein Operator zwischen „nicht möglich" und „nicht erlaubt" sofort.

Profile-Operationen¶

Operation	Was passiert
Apply	Profil einem Host zusätzlich zuordnen (ersetzt kein vorhandenes Profil) → host_services für `auto_add` Profile-Checks erzeugen
Clone	Profil + alle Profile-Checks duplizieren (Auto-Rename mit Suffix)
Export	JSON-Bundle `{schema_version, profile, checks}` herunterladen
Import	JSON-Bundle (oder ZIP) hochladen, ein kaputtes Bundle kippt nicht den Rest
Reset (Builtin-Check)	Einen bearbeiteten Builtin-Check auf seine Standardwerte zurücksetzen, optional samt Host-Overrides
Usage	wie viele Hosts/Services nutzen das Profil?

Details zur UI: Hosts & Geräte → Profile bearbeiten.

Visual Types¶

Profile mit visual_type aktivieren spezielle Hardware-Visualisierungen auf der Host-Detail-Seite:

Visual-Type	Wofür
`switch_portmap`	Port-Layout Switches mit Up/Down/Speed pro Port
`ups_panel`	UPS-Status-Panel mit Battery / Load / Temperature
`nas_diskbay`	Disk-Bay-Layout für NAS
`firewall_panel`	Firewall mit VPN-Tunnel + Throughput

Mehr Hintergrund: Hosts → Discovery & SNMP-Sensor-Picker.

Anschluss¶

Hosts → Profile bearbeiten — die UI-Seite
Status- und State-Modell — was passiert mit den Resultaten
Glossar — wenn ein Begriff fremd klingt