Zum Inhalt

Speicher wächst

Die Datenbank oder die Festplatte des Servers füllt sich schneller, als erwartet. Fast immer liegt die Ursache in einer Kombination aus Aufbewahrungs-Einstellung, einem zu geschwätzigen Check oder aktivierter Log-Sammlung — selten in einem echten Leck.

1. Erst hinschauen, dann handeln

Admin → System → Ressourcen → Untertab „Speicher" ist die zentrale Stelle für alles rund um Disk- und DB-Verbrauch:

  • Belegung — wie viel der Partition ist belegt (Warnung ab 85 %), Datenbank gesamt, Wachstum pro Tag nach Kompression (und roh davor), Write-Ahead-Log, Backups
  • Datenklassen-Tabelle — je Datenklasse Größe, Kompressionsstand, Zeilenzahl, älteste Daten
  • „Wohin der Platz geht" — Docker-Aufschlüsselung (Images, Container, Volumes, Build-Cache) inklusive Backups und Kartenbildern
  • „Größte Datenproduzenten" — welche Checks in den letzten 24 Stunden am meisten geschrieben haben

Details: Ressourcen.

2. Größten Datenproduzenten identifizieren

Bevor du an der Aufbewahrung drehst, lohnt sich der Blick auf „Größte Datenproduzenten" — oft ist ein einzelner Check die Ursache: ein zu kurzes Intervall, ein Check, der viele Werte gleichzeitig schreibt (z. B. ein SNMP-Walk mit vielen Sensoren), oder ein dicker Messwert-Anhang. Fix meist einfacher als eine kürzere Aufbewahrung: Intervall des betroffenen Checks erhöhen.

3. Logs als häufiger Treiber

Log-Sammlung über den Agent (Dateien, journald, Windows-Eventlog) kann bei hoher Log-Rate spürbar zur Speichergröße beitragen — deutlich mehr als reine Metrik-Checks. Prüfe:

  • Läuft Log-Sammlung auf Hosts, bei denen das gar nicht nötig wäre?
  • Ist die Aufbewahrung für Logs (Standard: nach 3 Tagen komprimieren, 30 Tage behalten) passend für dein Volumen? Die Tageszählung je Gerät, Quelle und Stufe bleibt auch nach Ablauf des Volltexts unbegrenzt erhalten.
  • Sammelt eine Quelle unnötig geschwätzige Stufen mit? journald-Quellen haben eine Mindest-Stufe (neue Quellen starten mit Warnung).

Details: Logs.

4. Aufbewahrung prüfen und anpassen

Unter Admin → System → Ressourcen → Speicher ist die Aufbewahrung nach Datenart gruppiert:

Datenart Datenklassen Standard
Ereignisse — etwas ist zu einem Zeitpunkt passiert Status-Wechsel, Audit-Log, Versendete Benachrichtigungen, Zustell-Journal, Anomalie-Ereignisse unbegrenzt behalten (Status-Wechsel nach 7 Tagen komprimiert)
Messreihen — fortlaufend gemessene Zahlen Messwerte (Detail) nach 3 Tagen komprimieren, 90 Tage behalten
Rohmaterial — nur frisch nützlich Logs (überwachte Systeme) nach 3 Tagen komprimieren, 30 Tage behalten
Diagnose-Ereignisse nach 7 Tagen komprimieren, 90 Tage behalten
Agent- und Collector-Heartbeats nach 3 Tagen komprimieren, 90 Tage behalten

Grenzen: Komprimieren zwischen 1 und 60 Tagen, Behalten zwischen 7 und 3650 Tagen — oder 0 für unbegrenzt.

Drei Vorschläge füllen die Felder mit einem Klick — gespeichert wird erst mit „Speichern & anwenden", damit du jede Zahl vorher siehst:

Vorschlag Messwerte Logs Diagnose-Ereignisse, Heartbeats Ereignisse
Sparsam 30 Tage 7 Tage 30 Tage 730 Tage
Standard 90 Tage 30 Tage 90 Tage unbegrenzt
Archiv 365 Tage 90 Tage 365 Tage unbegrenzt

Speichern wirkt sofort und endgültig — bereits gelöschte Daten lassen sich nicht zurückholen. Trägst du für Ereignisse eine Frist ein, warnt die Seite an Ort und Stelle: Ereignisse lassen sich nicht wiederherstellen und machen nur einen kleinen Teil der Datenbank aus. Der größte Hebel sind fast immer Messwerte und Logs.

Langzeit-Verläufe bleiben trotzdem erhalten

Auch wenn die Detail-Messwerte nach der eingestellten Frist gelöscht werden, bleiben die daraus verdichteten Werte: 5-Minuten-Werte 14 Tage, Stunden-Werte 395 Tage, Tages-Werte unbegrenzt. Der Check-Verlauf schaltet für ältere Zeiträume automatisch auf diese Werte um, die Statusfarben kommen aus dem Status-Verlauf. Wann ein Agent oder Collector ausgefallen war, bleibt auch nach Ablauf der Heartbeats sichtbar.

Status-Verlauf auf großen Installationen

Der Status-Verlauf wird seit v1.900.0 komprimiert gespeichert. Die Umstellung läuft beim Start automatisch — auf sehr großen Installationen aber nicht, weil sie die Tabelle kurz sperrt. Dann meldet sich Vesana im Diagnose-Log mit dem Befehl für ein Wartungsfenster.

5. „Jetzt aufräumen"

Der Knopf „Jetzt aufräumen" wendet Aufbewahrung und Kompression sofort an, statt auf den nächsten planmäßigen Lauf (alle 6 Stunden) zu warten. Wartet ein Rückstau unkomprimierter Daten, nennt die Seite seine Größe. Das Ergebnis steht danach da, z. B. „Letzter Lauf: 12 Abschnitt(e) komprimiert, 4 per Aufbewahrung entfernt".

6. Kompression greift nicht sichtbar

Zeigt die Seite „Die Kompression greift nicht …", liegen ältere Daten unkomprimiert und brauchen ein Vielfaches an Platz. Oft ist nur der Wartungslauf noch nicht durchgelaufen (bis zu 6 Stunden Verzögerung), oder frisch geschriebene Abschnitte sind naturgemäß noch unkomprimiert (Kompression greift erst nach der eingestellten Frist, z. B. 3 Tage). „Jetzt aufräumen" starten; bleibt die Meldung danach stehen, hilft ein Support-Bundle. Fehler beim Nachkomprimieren stehen im Diagnose-Log (timescale_recompress_failed).

7. Disk-Platz durch Docker selbst

Nicht jedes Wachstum kommt aus der Datenbank — alte, ungenutzte Docker-Images und Build-Cache sammeln sich über die Zeit an. Der Updater räumt alte Vesana-Images bei jedem Update selbst ab. Das „Wohin der Platz geht"-Panel zeigt den Rest; ein docker image prune bzw. docker builder prune (manuell, außerhalb der GUI) räumt zusätzlich auf, sollte aber nicht während eines laufenden Updates passieren. Kein docker volume prune — die Volumes enthalten Datenbank und Backups.

Checkliste

  1. Ressourcen → Speicher öffnen, Belegung + Wachstum/Tag ansehen
  2. Größte Datenproduzenten prüfen — ein einzelner Check verantwortlich?
  3. Log-Sammlung sinnvoll begrenzt?
  4. Aufbewahrung je Datenart zum tatsächlichen Bedarf passend?
  5. „Jetzt aufräumen" nutzen statt auf den nächsten 6-Stunden-Lauf zu warten
  6. Docker-Altlasten (Images/Build-Cache) mit einbeziehen

Anschluss