Zum Inhalt

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.