Zum Inhalt

Ressourcen

Admin → System → Ressourcen ist die eine Seite für alles, was die Instanz an Ressourcen verbraucht und wie sie dimensioniert ist. Drei Untertabs (eigene Tab-Leiste innerhalb der Seite, per ?sub= adressierbar):

  • Speicher — Disk-Verbrauch, Datenbank-Größe, Retention pro Datenklasse, Aufräumen
  • RAM — Arbeitsspeicher pro Dienst, Anteil am Server-RAM
  • Leistung — Pipeline-Ampel, verworfene Ergebnisse, Sizing-Profile (Worker/Postgres/Redis)

Frühere Alt-Links auf die separaten Seiten „Speicher" und „Leistung" leiten automatisch auf die passende Untertab-Ansicht dieser Seite um.

Speicher

Belegungs-Übersicht

Oben auf dem Tab:

  • Belegung — wie viel der Partition ist belegt, in GB und Prozent. Warnung ab 85 % belegt.
  • Datenbank gesamt — Gesamtgröße der Postgres-Datenbank.
  • Wachstum pro Tag — nach Kompression und roh (vor Kompression), damit du siehst, wie viel die TimescaleDB-Kompression tatsächlich bringt.
  • WAL — Größe des Write-Ahead-Logs.

Datenklassen-Tabelle

Jede Hypertable-Datenklasse einzeln, mit Größe, „Komprimiert N/M Abschnitte", Zeilenzahl und ältestem Datenpunkt. Eine Warnung erscheint, wenn Kompression konfiguriert ist, aber sichtbar nicht greift.

Zusätzlich eine Übersicht der Metrik-Aggregate (5-Minuten-, Stunden- und Tages-Werte) mit ihrer jeweiligen Vorhaltezeit — die feinste Auflösung (5 Minuten) wird nach zwei Wochen automatisch verdichtet, Stunden-Werte nach gut einem Jahr, Tages-Werte bleiben unbegrenzt.

„Wohin der Platz geht"

Ein Docker-Verbrauchs-Panel schlüsselt auf, was auf der Platte liegt: Images, gestoppte Container, Volumes, Build-Cache — inklusive dem Anteil, der sich sofort zurückgewinnen ließe.

„Größte Datenproduzenten"

Eine Liste, welche Checks in den letzten 24 Stunden am meisten in die Datenbank geschrieben haben. Hilfreich, um einen zu häufig laufenden oder zu geschwätzigen Check zu identifizieren, bevor er die Retention sprengt.

Wie lange Vesana Daten aufbewahrt

Vesana behandelt Daten nach dem Grundsatz: Ereignisse bleiben, Messreihen werden gröber, gelöscht wird nur Rohmaterial. Dafür gehört jede Datenart zu genau einer von drei Klassen.

Ereignisse — werden standardmäßig nie gelöscht

Etwas ist zu einem Zeitpunkt passiert und hat jemanden interessiert. Diese Einträge sind winzig und lassen sich nicht rekonstruieren.

Datenart Behalten (Standard)
Status-Wechsel eines Checks unbegrenzt (komprimiert gespeichert)
Audit-Log (wer hat was geändert) unbegrenzt
Versendete Benachrichtigungen unbegrenzt
Zustell-Journal unbegrenzt
Anomalie-Ereignisse unbegrenzt

Messreihen — werden verdichtet statt gelöscht

Ein fortlaufend gemessener Zahlwert. Die Rohdaten sind begrenzt, aber die verdichteten Stufen bleiben — ein Langzeit-Trend geht damit nie verloren.

Stufe Auflösung Behalten
Rohdaten (Check-Ergebnisse) je Messung 90 Tage (einstellbar)
Stündliche Werte 1 Stunde 395 Tage
Tageswerte 1 Tag unbegrenzt

Rohmaterial — darf ablaufen

Volltext und Rohsignale, die nur frisch nützlich sind.

Datenart Komprimieren nach (Standard) Behalten (Standard)
Logs überwachter Systeme 3 Tage 30 Tage
Diagnose-Ereignisse (System-Log) 7 Tage 90 Tage
Agent-Heartbeats 3 Tage 90 Tage
Collector-Heartbeats 3 Tage 90 Tage

Von den Logs bleibt die Tageszählung

Der Volltext läuft nach 30 Tagen ab, aber wie viele Einträge es je Tag, Gerät, Quelle und Stufe gab, hält Vesana unbegrenzt fest. Damit lässt sich „wann fing das an" auch nach Jahren beantworten, ohne die Logs selbst länger aufzubewahren.

Ausfälle bleiben trotzdem

Wann ein Agent oder Collector weg war, hält Vesana zusätzlich als Ereignis fest — unbegrenzt. Der Verfügbarkeits-Balken zeigt einen Ausfall deshalb auch dann noch, wenn die Heartbeats selbst längst abgelaufen sind. Zeiträume, über die es gar keine Quelle gibt (vor der Einführung dieser Aufzeichnung), erscheinen als „kein Urteil" — nicht als Ausfall.

Aufbewahrung einstellen

Die Einstellungen sind nach den drei Klassen gruppiert — Ereignisse, Messreihen, Rohmaterial — mit je einem Satz, was die Klasse bedeutet.

Drei Vorschläge füllen die Felder mit einem Klick:

Vorschlag Ereignisse Messwerte roh Logs
Sparsam 2 Jahre 30 Tage 7 Tage
Standard unbegrenzt 90 Tage 30 Tage
Archiv unbegrenzt 365 Tage 90 Tage

Ein Vorschlag speichert nicht

Ein Klick auf ein Profil füllt nur die Eingabefelder. Gespeichert wird erst mit „Speichern & anwenden" — so siehst du vorher jede einzelne Zahl und jede Warnung. Das ist Absicht: ein Klick, der zehn Aufbewahrungen auf einmal verkürzt, wäre genau der Knopf, der den Datenverlust verursacht, den diese Funktion verhindern soll.

Pro Datenart einstellbar — Komprimieren nach (Tage) und Behalten (Tage, 0 = unbegrenzt).

Grenzen: Komprimieren zwischen 1 und 60 Tagen; Behalten zwischen 7 und 3650 Tagen, oder 0 für unbegrenzt. Die Aufbewahrungsfrist muss länger sein als die Kompressions-Frist. Speichern wirkt sofort und endgültig — es gibt keinen Rückgängig-Knopf, gelöschte Rohdaten sind weg.

Komprimieren lassen sich die Messreihen, das Rohmaterial und bei den Ereignissen die Status-Wechsel. Die übrigen Ereignisse liegen in gewöhnlichen Tabellen; für sie gibt es nur „Behalten".

Was hinter den Kulissen passiert

Deine Eingabe ist der Wunsch; ein Hintergrund-Job vollzieht ihn alle 6 Stunden. Bei komprimierbaren Datenarten als echte TimescaleDB-Policy, bei Ereignissen als zeitbasierte Löschung im täglichen Aufräum-Lauf. Setzt du „Behalten" auf 0, wird gar nichts mehr gelöscht — exakt wie eingestellt.

Ereignisse nur bewusst befristen

Bei Ereignissen ist der Standard „unbegrenzt", weil sie kaum Platz brauchen und nicht wiederherstellbar sind: alle Ereignis-Tabellen zusammen machen auf einer typischen Instanz weniger als ein Prozent der Datenbank aus. Wer hier eine Frist setzt, verliert den Verlauf endgültig — das Audit-Log ist dann z. B. für eine spätere Nachforschung nicht mehr vollständig.

Jetzt aufräumen

Ein Button „Jetzt aufräumen" erscheint, sobald ein sichtbarer Rückstand besteht (Kompression oder Retention hinkt hinterher). Das Ergebnis wird als Klartext gemeldet, z. B. „12 Abschnitt(e) komprimiert, 4 per Aufbewahrung entfernt".

Deadband & Heartbeat (Hintergrund-Mechanik)

Damit gleichbleibende Messwerte nicht bei jedem Poll eine neue Zeile erzeugen, schreibt der Worker nur bei: erstem Datenpunkt, Status-Wechsel, Wertänderung über einer kleinen Toleranzschwelle, oder wenn das Heartbeat-Intervall (Standard 10 Minuten) überschritten ist. Das reduziert den Speicherbedarf spürbar, ohne dass ein Trend verloren geht. Diese Feinsteuerung ist bewusst kein UI-Feld — sie ist eine interne Schutzmaßnahme, kein Retention-Hebel.

RAM

Zeigt, wie viel Arbeitsspeicher Vesana insgesamt und pro Dienst verbraucht — die Werte kommen aus den Container-Statistiken, bereinigt um Linux-Page-Cache (der sich sonst fälschlich wie „belegtes" RAM liest).

  • Vesana gesamt (alle Dienste) — Summe über alle Container, plus „von X GB Server-RAM (Y %)"
  • Verteilung pro Dienst — als Balken je Dienst: Datenbank, API, Receiver, Worker, Worker-Scheduler, Redis, Webserver, Updater, Ollama (falls aktiv), Agent-Gateway (falls aktiv)

Die Ansicht aktualisiert sich automatisch alle 30 Sekunden. Ohne laufenden Updater-Container (z. B. bei einer komplett manuell verwalteten Installation) erscheint eine Warnung statt der Live-Zahlen — die Werte werden serverseitig über den Updater erhoben, nicht über die API selbst.

Nutze diese Ansicht, bevor du hochskalierst: Wenn ein einzelner Dienst (z. B. die Datenbank) den Löwenanteil belegt, sagt dir das mehr als die reine Server-Gesamtauslastung.

Leistung

Pipeline-Ampel

Oben auf dem Tab steht eine Ampel (grün/gelb/rot), die anzeigt, wie weit die Verarbeitung hinterherhinkt — abgeleitet aus dem Alter der ältesten noch unbearbeiteten Nachricht im Verarbeitungs-Stream. Sie ist die schnelle Antwort auf die Frage „muss ich gerade hochskalieren?": Grün heißt, die Pipeline verarbeitet in Echtzeit; gelb/rot heißt, Nachrichten stauen sich — ein Grund, ein größeres Sizing-Profil zu wählen oder die Ursache (DB-Engpass, zu wenige Worker) zu untersuchen.

Verworfene Ergebnisse

Konnte der Worker ein Ergebnis endgültig nicht speichern, landet es hier als verworfenes Ergebnis (Dead-Letter) — es ist verloren und wird nicht erneut versucht. Solange solche Einträge liegen, meldet die Admin-Übersicht „Aufmerksamkeit nötig" und nennt diesen Grund. Ist die Ursache behoben (meist steht sie im Diagnose-Log), räumst du sie mit Abräumen weg (nur Super-Admins); der Vorgang steht danach im Diagnose-Log.

Sizing-Profile

Vier statische Profile — keine automatische Empfehlung, du wählst bewusst (nur Super-Admins):

Profil Worker WORKER_CONCURRENCY Postgres shared_buffers effective_cache_size work_mem maintenance_work_mem max_connections DB-Pool Redis maxmemory
Klein 1 4 256 MB 512 MB 8 MB 128 MB 100 5 (+10 Overflow) 256 MB
Mittel 2 4 512 MB 1 GB 16 MB 256 MB 150 10 (+20 Overflow) 512 MB
Groß 3 8 1 GB 2 GB 32 MB 512 MB 200 15 (+30 Overflow) 1 GB
XL 5 8 2 GB 4 GB 64 MB 1 GB 300 20 (+40 Overflow) 2 GB

Bei einer Neuinstallation leitet der Installer die Postgres-Speicherwerte aus dem Arbeitsspeicher des Servers ab; der Einrichtungs-Assistent senkt sie nie. „Anwenden" auf dieser Seite setzt dagegen genau die Werte des gewählten Profils.

„Anwenden" schreibt die passenden Werte in die .env und führt einen Container-Neustart (docker compose up -d) aus — Postgres hat dabei eine kurze Downtime (Sekunden, nicht Minuten), die anderen Container werden ohne Datenverlust neu erstellt.

Sizing-Bestätigung mit echten Laufzeit-Zahlen

Nach „Anwenden" verlässt sich Vesana nicht auf die reine Erwartung, sondern fragt beim laufenden System nach: wie viele Worker-Container laufen tatsächlich, und hat Postgres shared_buffers wirklich übernommen (SHOW shared_buffers). Das Frontend pollt bis zu 120 Sekunden lang, bis Profil, Worker-Anzahl und shared_buffers zum gewählten Ziel passen, und meldet den Erfolg dann mit den echten gemessenen Zahlen — nicht nur „Einstellung gespeichert".

Das ist wichtig, weil ein reiner Einstellungs-Erfolg nichts darüber aussagt, ob der Container-Neustart auch angekommen ist. Schlägt die Bestätigung fehl (z. B. Postgres braucht länger als 120 s zum Neustart), prüfe die Container-Logs — die Einstellung selbst ist trotzdem gespeichert und wird beim nächsten manuellen Neustart wirksam.

Wann welches Profil?

Als grobe Orientierung — das tatsächlich richtige Profil hängt vom Check-Mix ab (viele SNMP-Walks brauchen mehr Worker, viele Agent-Checks brauchen mehr DB-Schreibrate):

  • Klein — Einzelner Standort, kleines Büro, wenige hundert Services
  • Mittel — Mehrere Standorte oder Mittelstand
  • Groß — Größerer IT-Dienstleister mit vielen Kunden
  • XL — Datacenter-/Enterprise-Maßstab (mehr als 32 GB RAM auf dem Server empfohlen)

Beobachte die Pipeline-Ampel und die RAM-Verteilung, bevor du hochskalierst — beide zusammen zeigen dir, ob der Engpass bei den Workern, bei Postgres oder beim Server-RAM insgesamt liegt.

Manuelles Tuning jenseits der Profile

Die vier Profile decken die meisten Fälle ab. Für Sonderfälle bleibt manuelles Tuning der .env-Variablen möglich (siehe Self-Hosting-Übersicht) — z. B. wenn du gezielt nur WORKER_REPLICAS erhöhen willst, ohne die Postgres-Werte anzufassen. Nach manueller Änderung: docker compose up -d, damit die neuen Werte greifen.

Anschluss