Glossar¶
A¶
Acknowledgement (ACK)¶
Operator-Bestätigung, dass ein Problem gesehen wurde. Unterdrückt weitere Notifications und blockiert die Promotion degraded → alerting, bis Recovery eintritt. → Acknowledgements
Active Check¶
Check mit check_mode = active — wird vom Aktiven Collector ausgeführt (oder, wenn dieser offline ist, vom Python-Hybrid-Fallback im Worker). Einer von drei gleichberechtigten Monitoring-Modi, kein Legacy-Pfad. → Architektur → Drei Monitoring-Modi
Aktiver Collector¶
Systemd-Service auf der Vesana-Maschine selbst (dasselbe Binary wie der Collector), führt check_mode='active'-Checks tenant-übergreifend aus. Maximal eine Instanz pro Vesana-Installation. → Architektur → Aktiver Collector
Akzeptierte Ausnahme¶
Sonderfall des Acknowledgements: Der Operator hat die Checkbox „ist ein Problem" abgewählt. Der Status bleibt sichtbar rot/wahr, zählt aber in keinem Problem-Rollup mehr. Bricht automatisch, wenn der Check schlimmer wird als beim Markieren. → Status-Modell → Acknowledged
Automatisches Setup¶
Reiter Discovery → „Automatisch einrichten": Vesana übernimmt entdeckte Geräte selbst (Gerätetyp bestimmen, gespeicherte Zugangsdaten probieren, Host anlegen, Profil-Checks aktivieren) und legt für alles andere Aufgaben an. → Automatisches Setup
Agent¶
Go-Single-Binary, das auf der überwachten Maschine läuft und Checks lokal ausführt. Push-basiert — meldet Ergebnisse via HTTPS POST an den Receiver. → Agents & Collectors → Agent
Agent-Gateway¶
Optionaler, separater Port nur für Maschinen-Endpunkte (Agent/Collector-Traffic), Default aus. Erlaubt es, den normalen UI-Port per Firewall zu schließen und trotzdem Agents aus fremden Netzen einliefern zu lassen (typisches MSP-Szenario). Der UI-Port bleibt weiterhin voll funktionsfähig — Bestandsagents brechen nie. → Installation → Distribution & Erreichbarkeit
Aggregat¶
Eigenständiges Objekt (kein normaler Check), das den Status einer Gruppe redundanter Mitglieder K-von-N auswertet: alle gesund → OK, mindestens K gesund → WARNING, weniger als K gesund → CRITICAL. Die WARNING-Stufe unterdrückt abhängige Dienste bewusst nicht. → Architektur → Aggregate (K-von-N)
Agent-Token¶
Token im Format vesana_agent_<32 url-safe chars>. 1:1 an einen Host gebunden. Vom Server SHA256-gehasht in agent_tokens.token_hash. Wird genau ein Mal beim Erzeugen angezeigt. → Sicherheit → Tokens
AI-Analyse¶
Service-spezifische Diagnose durch ein LLM mit Wiki-RAG, Web-Suche und State-Kontext. Eingebaut in Error-Overview und Host-Detail. → AI-Chat & Analyse
Alerting (State)¶
Phase im Three-Layer-State-Modell — Fehler dauerhaft, Push-Notification raus, Operator alarmiert. Spalte: current_status.alerting_state = 'alerting'. → State-Modell
Alert Rule¶
Regel, die definiert, wann eine Notification ausgelöst wird. Schwellwerte, Pattern, Eskalation, Gruppierung. → Alert Rules
API-Key¶
Token für Collectors. Format: Custom-Prefix + 32 Bytes. SHA256-Hash in api_keys.key_hash. → Sicherheit → Tokens
Auto-Discovery¶
Automatische Erkennung neuer Hosts via nmap-Scan und SNMP-sysOID-Match. Im Collector implementiert. → Hosts → Discovery
B¶
Baseline¶
28-Tage-Mittelwert + Standardabweichung pro Service, gespeichert pro 1-Stunde-Bucket (168 Buckets). Grundlage für Anomaly Detection. → Anomaly Detection
Builtin¶
Mit Vesana mitgelieferte Profile, Profile-Checks oder Wiki-Artikel. is_builtin = true. Werden bei Updates über Seed-Scripts upserted, modifizierte Builtins (is_modified = true) nicht überschrieben.
C¶
Check¶
Eine einzelne Messung — z. B. „CPU-Last" oder „Battery-Voltage". In Vesana realisiert als Profile-Check (Definition) und Host-Service (Instanz). → Profile & Checks
Check-Mode¶
active (Server prüft selbst), passive (Collector prüft remote), agent (Agent prüft lokal).
Check-Result¶
Eine eingegangene Messung mit Status, Wert, Message, Timestamp. Speicherung in check_results (TimescaleDB-Hypertable).
Collector¶
Linux-VM im Kundennetz, führt Remote-Checks aus (SNMP, Ping, SSH, HTTP). Push-basiert wie der Agent. → Agents & Collectors → Collector
Compose-Profile¶
Optionale Service-Gruppen in docker-compose.prod.yml — z. B. ai, backup. Aktiviert via --profile <name>.
Confirmation-Intervall¶
Im probing-State wartet der Worker confirmation_interval_seconds (Default 10 s) bevor er den Check erneut ausführt — nach confirmation_attempts (Default 1) bestätigten Fehlschlägen geht der UI-State auf degraded. → State-Modell
Custom Dashboard¶
Frei konfigurierbare Sicht aus Widgets. Variablen, Sharing, Public-Links. → Custom Dashboards
D¶
Deadband¶
Speicher-Optimierung: Ein Check-Ergebnis wird nur dann erneut in check_results gespeichert, wenn sich der Wert relativ ausreichend geändert hat oder ein Heartbeat-Intervall verstrichen ist. Reduziert die Zeitreihen-Größe bei stabilen Werten (z. B. CPU-Last, die sich kaum bewegt), ohne echte Änderungen zu verpassen.
Dead-Agent-Watcher / Dead-Collector-Watcher¶
Background-Job, der Hosts auf NO_DATA setzt, wenn Agent/Collector lange schweigt. Distributed Lock via Redis sorgt dafür, dass nur ein Replica läuft.
Degraded¶
Phase im Three-Layer-State-Modell — Fehler durch Confirmation bestätigt, noch keine Push-Notification. Promotion zu alerting läuft nach Sustained-Schwelle (60-120 s). Spalte: current_status.ui_state = 'degraded'. ACK in dieser Phase blockiert die Promotion. → State-Modell
Dependency¶
Eltern-Kind-Beziehung zwischen Hosts oder Services. Grundlage für Inhibition. → Dependencies & Inhibition
Discovery-Result¶
Ergebnis eines Network-Scans pro IP, mit sysOID, sysDescr, Service-Erkennung, vorgeschlagenem Profil.
Distributed Locking¶
Redis-basierter Lock mit 55 s Timeout, sodass Watcher in einem Multi-Replica-Setup nur einmal laufen.
Downtime¶
Geplantes oder ungeplantes Wartungsfenster, in dem Alerts unterdrückt werden. Einmalig oder per RRULE wiederkehrend. → Downtimes
E¶
Effective Config¶
Verschmelzung aus Profile-Check-Default und Host-Service-Override. Per COALESCE und JSONB-Merge im SQL berechnet. → Profile & Checks → Effective Config
Einstellbare Werte¶
Werte, die ein Monitoring-Script per Kopfzeile im Rumpf deklariert und die jeder Check einzeln ausfüllt (Umgebungsvariablen VESANA_*). → Einstellbare Werte an Scripts
Erwartungswerte¶
Benannte Soll-Werte an einem Profil-Check (pro Host überschreibbar), gegen die der Server das Check-Ergebnis vergleicht. Früher „Eigene Felder". → Erwartungswerte & Vergleich
Eskalation¶
Mehrstufige Alert-Strategie: erst Stufe 1 (z. B. E-Mail an Operator), nach 15 min ohne Ack Stufe 2 (Push an Manager), nach 30 min Stufe 3.
F¶
FCM (Firebase Cloud Messaging)¶
Google-Dienst für Push an Android-Geräte. Vesana nutzt ihn seit 08/2026 NICHT mehr — Push läuft über den Browser-Standard Web Push (VAPID), den jede Instanz ohne Anbieter-Konto selbst betreibt. → Vesana auf dem Smartphone
Field-Encryption¶
AES-256-GCM-Verschlüsselung sensibler Spalten (z. B. hosts.snmp_community). Schlüssel in FIELD_ENCRYPTION_KEY. → Sicherheit → Verschlüsselung
H¶
Heartbeat¶
Regelmäßige Lebenszeichen-Anfrage des Agents an den Server (POST /api/v1/agent/heartbeat). Default: alle 60 s. Setzt agent_tokens.last_seen_at.
Host¶
Konkrete überwachte Maschine oder Gerät. Hat genau ein Profil. → Hosts
Host-Service¶
Instanz eines Profile-Checks für einen konkreten Host. Mit optionalen Overrides. → Profile & Checks
Hypertable¶
TimescaleDB-Konstrukt für Zeitreihen-Tabellen mit automatischer Partitionierung. In Vesana: check_results, logs, agent_metrics.
I¶
Info-Modus¶
Dauerhafte Check-Konfiguration: reine Statistik, echter Status bleibt sichtbar, erreicht aber nie alerting_state='alerting' — keine Notifications, Eskalation oder Inhibition. Zählt als eigener Bucket statt als Problem, in der Fehlerübersicht standardmäßig ausgeblendet. Abgrenzung zur akzeptierten Ausnahme: dauerhaft konfiguriert statt zustandsgebunden. → Status-Modell → Info-Modus
Identitätsbestätigung (Step-Up)¶
Frischer Nachweis (Passkey, Authenticator-Code oder Passwort) der letzten 15 Minuten, den heikle Aktionen zusätzlich zur Berechtigung verlangen — gilt pro Sitzung. → Sitzungen
Inhibition¶
Unterdrückung von Alerts für abhängige Services, wenn der Eltern-Host im alerting-State ist (nicht schon bei degraded). → Dependencies & Inhibition
Instance-UUID¶
Eindeutige ID einer Vesana-Installation, in system_settings.instance_uuid. Wird beim ersten Phone-Home oder Feedback erzeugt, race-safe via INSERT ON CONFLICT.
Jump¶
Instanzweite Schnellsuche über Menüpunkte, Einstellungen, Geräte, Checks, Tenants, Ordner und mehr — Cmd/Strg+K oder der Knopf oben in der Seitenleiste. → Oberfläche & Navigation
Kategorien¶
Die Chip-Gruppe der Fehlerübersicht: Offen, ACK (marked as error), ACK (marked as no error), Downtime, Dependency down, Info — angewählt heißt „wird angezeigt". → Fehlerübersicht
L¶
Lizenz-Tier¶
Community, Professional, MSP — unterscheiden sich nur in Host-/Mandanten-Limits und Preis, nicht im Feature-Umfang. → Lizenz-Tiers
LLD (Low-Level Discovery)¶
Konzept aus Zabbix für dynamische Item-Generierung — z. B. „für jedes gefundene Filesystem einen Disk-Check anlegen". In Vesana aktuell nicht implementiert; Workaround: agent_services_auto-Check und SNMP-Picker.
M¶
MIB (Management Information Base)¶
SNMP-Datenbeschreibung. Vendor-spezifisch (z. B. Cisco-ENVMON-MIB, APC-PowerNet-MIB).
MIB-Snippet¶
YAML-Datei mit Vendor-MIB-Wissen — OIDs, Status-Mappings, Discovery-Hints. → MIB-Snippets
Mobile-Push¶
Push-Meldung an die installierte Vesana-Web-App (Android, iPhone, iPad) über Web Push. Der Kanal wählt nur die Benutzer (und optional Geräte); welche Statusse und ob die Entwarnung gehen, steht in der Alert-Regel. → Vesana auf dem Smartphone
MSP (Managed Service Provider)¶
IT-Dienstleister, der mehrere Kundenumgebungen monitort. Standardanwender für Multi-Tenant-Mode. Auch Name des höchsten Lizenz-Tiers (unbegrenzt Hosts/Mandanten). → Lizenz-Tiers
N¶
NO_DATA¶
Status-Wert: keine Daten innerhalb der Erwartungs-Frist empfangen. Orange im UI. → State-Modell
Notification Channel¶
Konfigurierter Output-Kanal für Alerts: E-Mail, Mobile-Push, Webhook, Slack, Teams. → Notification Channels
NSCA¶
Nagios Service Check Acceptor. Legacy-Protokoll auf Port 5667. Vesana kann als NSCA-Empfänger fungieren — Migrations-Pfad für Nagios-Bestände. → NSCA-Migration
O¶
OID (Object Identifier)¶
SNMP-Identifier, z. B. .1.3.6.1.2.1.1.5.0 für sysName.
Override¶
Host-spezifische Abweichung von einem Profile-Check-Default. → Effective Config
P¶
Passive Check¶
Check, der von einem Collector ausgeführt wird (check_mode = passive).
PENDING¶
Blaue Anzeige „Wartet auf Daten" — Read-Time-Sonderfall von NO_DATA für frisch angelegte oder reaktivierte Services, solange noch kein erstes Ergebnis da ist (kein Zeitfenster — endet nur durch Ergebnis oder Offline-Urteil). Kein eigener DB-Status. → Status-Modell → PENDING
Permission¶
Rechte-Bit. Beispiele: host.create, alert_rule.edit, ai.query. → Rollen & Permissions
Pipeline-Health¶
System-Endpoint /api/v1/admin/health/snapshot mit Stream-Backlog, Insert-Rate, DB+Disk-Free, Worker-Pool-Status. → System-Health
Policy¶
Deklarative Regel: Match-Bedingung (JsonLogic-Subset) + Action (Check anlegen, Tag setzen, Config patchen). Wendet sich automatisch auf alle passenden Hosts an — Bulk-Konfiguration ohne SSH. Dry-Run ist vor dem Speichern Pflicht, ein Circuit-Breaker stoppt ausufernde Syncs. → Architektur → Policies
Probing¶
Erste Phase im Three-Layer-State-Modell — Check hat einmal Fehler gemeldet, Confirmation-Retry läuft. Operator sieht eine grau-pulsierende Pille. Spalte: current_status.ui_state = 'probing'. Geht entweder nach Confirmation auf degraded, oder direkt zurück auf ok wenn der Retry-Versuch grün ist. → State-Modell
Profil¶
Geräte-Definition mit Capabilities und visuellem Layout-Typ. → Profile & Checks
Profile-Check¶
Check-Definition pro Profil. → Profile & Checks
R¶
RAG (Retrieval-Augmented Generation)¶
Technik, bei der ein LLM mit relevantem Kontext aus einer Datenbank gefüttert wird. Vesana nutzt pgvector + Wiki-Embeddings als RAG-Quelle. → AI-Features
Reachability-Hint¶
Ping-basierter Live-Hint, ob ein Host gerade erreichbar ist. Grundlage für die Host-Down-Inhibition (Eltern-Host wirklich „down", nicht nur irgendein Check alerting) und für die Suspension von Kind-Service-Fast-Polls, solange der Elternteil nicht erreichbar ist. → Alerting → Reachability-Hint
Receiver¶
Eingangs-Service, der Agent- und Collector-Pakete annimmt und in den Redis Stream schreibt. Schnellster Pfad — keine DB-Schreibzugriffe.
Recovery¶
Übergang aus alerting zurück zu ok. Optional eine eigene Notification.
Recovery-Poll-Intervall¶
Im degraded-State pollt der Worker-Scheduler den Active-Check enger (Default 15 s) für schnelleres Recovery-Detection. Feld: recovery_poll_interval_seconds. → State-Modell
S¶
Severity¶
Schweregrad-Reihenfolge: CRITICAL > WARNING > NO_DATA > UNKNOWN > OK.
Site / Standort¶
Geo-Wahrheit für physische Karten. Ein Host gehört zu genau einem Standort (Fallback: eigener Host-Ort, falls kein Standort gepflegt). Eine physische Karte hängt an genau einem Standort; Deko-Knoten auf physischen Karten lösen nie Abhängigkeiten aus.
Soft-Delete¶
Logisches Löschen via deleted_at-Spalte. Items landen im Papierkorb, werden nach 30 Tagen physisch gelöscht. → Soft-Delete & Papierkorb
Status-Page¶
Öffentlich erreichbare Seite mit ausgewählten Komponenten-Status. Branding pro Tenant. → Public Status Pages
Struktur-Spalte¶
Der Baum links auf der Hosts-Seite: Tenants als Abschnitte, darin eigene, verschachtelbare Ordner; Geräte per Ziehen oder Rechtsklick einsortieren. → Hosts-Seite & Struktur
Suppression¶
Ein Check zählt in keinem Problem-Rollup, wenn er unterdrückt ist: in Downtime ODER (akzeptiert UND nicht „ist ein Problem") ODER (Info-Modus UND Status ≠ OK). Die Fehlerübersicht zeigt trotzdem bewusst alles. → Status-Modell → Suppression-Regel
Sustained-Schwelle¶
Wie lange ein degraded ununterbrochen bestehen muss, bevor der Watcher zu alerting promoviert. Defaults: 60 s für CRITICAL, 120 s für WARNING (Settings default_alert_after_critical_seconds, default_alert_after_warning_seconds). → State-Modell
sysOID¶
SNMP-Object-ID, die ein Gerät identifiziert (.1.3.6.1.2.1.1.2.0). Grundlage für Profile-Auto-Match.
T¶
Tenant¶
Mandanten-Trennlinie. Jeder Host, jede Alert-Rule, jedes Dashboard hat eine tenant_id. → Architektur
Tester-Mode¶
Env-Bypass für Beta-Tester. Alle Features ohne Lizenzschlüssel. → Lizenz
Three-Layer-State-Modell¶
Aktuelles State-Modell seit v0.48 (Migration 147 hat das alte Soft/Hard-Modell entfernt). Trennt UI-State (probing/degraded/alerting/no_data/unknown/ok — was der Operator sieht) von Alerting-State (ok/alerting — was Notifications und SLA antreibt). → State-Modell
track_change¶
Audit-Helper, der old_values und new_values einer Update-Operation als JSONB im audit_log speichert. → Audit-Log
U¶
UI-State¶
Operator-sichtbarer Layer im Three-Layer-State-Modell. Werte: ok, probing, degraded, alerting, no_data, unknown. Treibt die Pille in der Fehlerübersicht. → State-Modell
UNKNOWN¶
Status-Wert: Check lief, aber Ergebnis nicht eindeutig. Grau im UI. → State-Modell
Updater-Sidecar¶
Container, der GUI-Updates ausführt: Pre-Update-Backup, Pull, Migrations, Restart, Auto-Rollback. → Updates
V¶
Variable (Dashboard)¶
Platzhalter wie $host, $tenant für dynamische Widget-Filterung. Multi-Select möglich. URL-persistiert. → Custom Dashboards
Visual-Type¶
Spezielle Hardware-Visualisierung pro Profil (switch_portmap, ups_panel, …).
W¶
Watchdog¶
Background-Job, der Status-Übergänge überwacht (Dead-Agent, Dead-Collector, Service-Overdue, Downtime-Expiry).
Wiki¶
Eingebaute Wissensbasis. Markdown, Kategorien, Tags, Service-Linking, pgvector-Embeddings. → Wiki
Worker¶
Konsumer-Service, der Redis-Stream-Messages verarbeitet, Status updated, Alerts auswertet. Mehrfach instanziierbar.
Z¶
Zone¶
Gruppe von Hosts auf der logischen Karte (früher „Blase"): Panel mit Status-Balken; Züge vom Zonenrand legen echte Abhängigkeiten über die Status-Hosts an, die Zone selbst alarmiert nie. → Logische Karte
Zugangsdaten-Set¶
Tenant-weit gespeicherte Geräte-Zugangsdaten (SNMP v2c/v3, SSH, API-Token), beim Anlegen und im Automatischen Setup per Auswahl nutzbar; Geheimnisse werden nie wieder angezeigt. → Zugangsdaten
Zstd¶
Kompressions-Algorithmus für Log-Pakete. Agent komprimiert Log-Einträge vor dem POST.