Zum Inhalt

Ressourcen

Admin → Wartung → 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 — Sizing-Profile (Worker/Postgres/Redis), Pipeline-Ampel

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.

Retention konfigurieren

Pro Datenklasse einstellbar — Komprimieren nach (Tage) und Behalten (Tage, 0 = unbegrenzt):

Datenklasse Label Komprimieren nach (Default) Behalten (Default) Komprimierbar
Messwerte (Check-Ergebnisse, Detail) Messwerte 3 Tage 90 Tage ja
Logs überwachter Systeme Logs 3 Tage 30 Tage ja
Diagnose-Ereignisse (System-Log) Diagnose 7 Tage 90 Tage ja
Collector-Heartbeats Heartbeats — 30 Tage nein
Agent-Heartbeats Heartbeats — 30 Tage nein

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.

Was hinter den Kulissen passiert

Deine Eingabe ist der Wunsch; ein Hintergrund-Job vollzieht ihn alle 6 Stunden als echte TimescaleDB-Policy (Kompressions- und Retention-Policy). Setzt du „Behalten" auf 0, wird die Retention-Policy komplett entfernt — die Daten wachsen dann unbegrenzt, exakt wie eingestellt.

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.

Sizing-Profile

Vier statische Profile — keine automatische Empfehlung, du wählst bewusst:

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

„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