Profile & Checks¶

Das wichtigste Konzept in Vesana. Wenn du diese Seite verstanden hast, fügen sich Discovery, SNMP-Picker, Policies, 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 genau ein Profil	`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, vm_host, server_hardware)
Icon — aus Lucide

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. Beim Seed-Lauf werden modifizierte Builtins nicht überschrieben.

Reset: Profile-Karte → Reset setzt einen modifizierten Builtin auf den Original-Zustand zurück.

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)
`retry_interval_seconds`	Im Soft-State (Default 15 s)
`max_check_attempts`	Soft → Hard nach wievielen Fehlschlägen (Default 3)
`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?
`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
`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:

COALESCE(hs.interval_override, pc.interval_seconds)         AS interval_seconds
COALESCE(pc.check_config, '{}'::jsonb)
  || COALESCE(hs.config_overrides, '{}'::jsonb)             AS effective_config

Das Override-Prinzip ist additiv: 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

Lebenszyklus eines Profile-Checks¶

sequenceDiagram
    participant U as User
    participant API
    participant DB
    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->>API: POST /receiver mit Result
    API->>W: in 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 auf Host setzen → 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)	Alle Modifikationen verwerfen, Original aus Seed wiederherstellen
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
`vm_host`	VMware/KVM-Host mit VM-Liste + Cores
`server_hardware`	PSU/CPU/RAM-Layout

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