Logs¶
Vesana kann Logs sammeln und durchsuchen — Datei-Tailing, journald, Windows-Event-Log. Auf Server-Seite landen sie in TimescaleDB-Hypertables, im Frontend in der LogsPage.
Architektur¶
flowchart LR
F[Datei-Logs] --> AT[Agent: file-tailing]
J[journald] --> AT
W[Windows Event Log] --> AT
AT --> Q[Disk-Queue (Backpressure)]
Q --> ZSTD[zstd-Kompression]
ZSTD -->|HTTPS POST| R[Receiver /logs/ingest]
R --> DB[(logs Hypertable)]
DB --> S[Search / FTS]
DB --> SSE[Live-Tail SSE]
Voraussetzungen¶
- Agent installiert (Logs werden ausschließlich vom Agent gesammelt — kein Collector-Pfad)
- Mindestens eine Log-Source pro Host konfiguriert
Log-Source anlegen¶
Host-Detail → Logs → Source hinzufügen:
| Feld | Beispiel |
|---|---|
| Name | nginx-access |
| Typ | file / journald / eventlog |
| Path / Unit / Channel | /var/log/nginx/access.log / nginx.service / Application |
| Severity-Filter | info und höher |
| Tags | optional, kommagetrennt |
Der Agent bekommt die neue Source beim nächsten Config-Refresh und beginnt zu tailen.
File-Tailing¶
type: file
path: /var/log/nginx/access.log
encoding: utf-8
parse:
format: regex
pattern: '^(?P<ip>\S+) - - \[(?P<ts>[^\]]+)\] "(?P<method>\S+) (?P<url>\S+).*" (?P<status>\d+)'
Glob-Patterns sind erlaubt: /var/log/myapp/*.log. Rotierte Files werden automatisch erkannt (inode-based).
journald¶
Windows Event Log¶
type: eventlog
channel: Application
sources:
- "VesanaAgent"
- "Windows Update"
levels:
- error
- warning
Suche¶
/logs ist die Such-UI. Filter:
- Volltext-Suche (deutscher FTS-Index, Fallback ILIKE für partielle Matches)
- Host
- Source
- Severity
- Zeitraum (relativ
last 1h/last 24hoder absolut)
Treffer-Liste mit klappbaren Einträgen (zeigt das ganze Log-Event mit Metadaten).
Live-Tail¶
Filter setzen → Live-Tail starten:
Server-Sent-Events (SSE) streamen neue Einträge in die UI. Auto-Scroll, Pause-Knopf, max. 1 000 sichtbare Einträge (älter wird verworfen).
Hinter den Kulissen: GET /api/v1/logs/stream?host=...&severity=error mit Content-Type: text/event-stream.
Log-Alert-Regeln¶
Patterns, die automatische Alerts triggern. Drei Modi:
Any-Match¶
Sobald ein Log-Eintrag matcht, wird ein Alert ausgelöst.
Sinnvoll für „taucht das Wort panic irgendwo auf?".
Threshold¶
Mehr als N Matches pro Zeitfenster.
Sinnvoll für Brute-Force-Patterns.
Implementierung: Redis-Sorted-Set, das die letzten N Matches mit Timestamps hält.
Absence¶
Kein Match innerhalb des Fensters → Alert.
Sinnvoll für „Backup-Cron sollte täglich genau einmal ein OK loggen".
Implementierung: Redis-TTL-Key, der bei jedem Match neu gesetzt wird. Wenn der Key abläuft, ohne dass er erneuert wurde → Alert.
Komprimierung¶
Der Agent komprimiert Log-Pakete vor dem POST mit zstd (Level 3). Typisch 8–12× kleiner als unkomprimiert. Empfänger dekomprimiert in /api/v1/logs/ingest und schreibt Bulk-Insert in die Hypertable.
Retention¶
| Tabelle | Default | Konfigurierbar in |
|---|---|---|
logs |
30 Tage | Admin → Einstellungen → Retention |
TimescaleDB-Compression läuft auf älteren Chunks — die rohen Events bleiben durchsuchbar, aber Disk-effizient (Faktor ~6).
Disk-Queue (Backpressure)¶
Der Agent puffert Log-Events lokal in einer Disk-Queue (Default 50 MB), bevor er sie an den Server schickt. Wenn der Server temporär nicht erreichbar ist:
- Agent puffert weiter
- Bei Erreichen des Limits werden die ältesten Events verworfen (Logs sind nicht so wertvoll, dass der Agent stehen bleiben sollte)
- Sobald der Server zurück ist, wird die Queue leergeschickt
Disk-Queue-Pfad: /var/lib/vesana-agent/queue/ (Linux) oder C:\ProgramData\Vesana\Agent\queue\.
Wann reicht es nicht¶
- Sehr hohe Volumina (> 10 000 events/s pro Host) — eigene Lösung wie Loki/Grafana parallel laufen lassen, nur Wichtiges in Vesana
- Strukturierte Telemetrie (OpenTelemetry-Logs) — gibt es noch nicht in Vesana; Workaround: in journald loggen, Pattern parsen
- Compliance-Speicher (revisionssicher) — Vesana ist kein WORM-Storage, dafür separate Lösung
Anschluss¶
- Alert Rules — Notifications für Log-Alert-Treffer
- Notification Channels — wohin der Alert geht