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, der vom Vesana-Server selbst ausgeführt wird (z. B. ping, http von der API-Maschine aus). Veraltet für die meisten Anwendungsfälle — Collector ist die bevorzugte Variante.

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-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¶

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

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-Service für Push-Notifications an Android-Geräte. Vesana kann Shared-FCM (Standard) oder eigenes Firebase-Projekt nutzen. → Mobile App → Push-Notifications

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¶

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.

L¶

Lizenz-Tier¶

Community, Pro, Enterprise. → Lizenz-Tiers

Log-Alert-Regel¶

Pattern-Matching auf Log-Einträge mit Threshold, Absence- oder Any-Match-Auslöser. → Logs

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-Notification an die Android-App via FCM. Severity-Filter, User-Targeting, Recovery-Toggle pro Channel. → Mobile App

MSP (Managed Service Provider)¶

IT-Dienstleister, der mehrere Kundenumgebungen monitort. Standardanwender für Multi-Tenant-Mode.

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).

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

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

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.

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

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¶

Zstd¶

Kompressions-Algorithmus für Log-Pakete. Agent komprimiert Log-Einträge vor dem POST.