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 Retention-Einstellung, einem zu geschwätzigen Check oder aktivierter Log-Sammlung — selten in einem echten Leck.

1. Erst hinschauen, dann handeln

Admin → Wartung → 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 %)
  • Wachstum pro Tag — nach Kompression und roh; ein großer Unterschied zwischen beiden zeigt, dass Kompression zwar greift, aber die Rohdaten-Rate selbst hoch ist
  • Datenklassen-Tabelle — pro Hypertable Größe, Kompressionsstand, Zeilenzahl, ältester Datenpunkt
  • „Wohin der Platz geht" — Docker-Aufschlüsselung (Images, Container, Volumes, Build-Cache) inklusive sofort reklamierbarem Anteil
  • „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 Retention 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 neu angelegter Check ohne sinnvolles Intervall. Fix meist einfacher als Retention-Änderung: Intervall des betroffenen Checks erhöhen.

3. Logs als häufiger Treiber

Log-Sammlung (agent_script/File-Tailing/journald/Windows Event Log über den Agent) 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 Retention für Logs (Default: 3 Tage komprimieren, 30 Tage behalten) sinnvoll für dein Volumen, oder zu großzügig?
  • Filtert die Log-Source unnötig geschwätzige Quellen mit (z. B. Debug-Level-Logs, die niemand auswertet)?

Details: Logs.

4. Retention prüfen und anpassen

Pro Datenklasse einstellbar unter Admin → Wartung → Ressourcen → Speicher:

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

Grenzen: Komprimieren zwischen 1 und 60 Tagen, Behalten zwischen 7 und 3650 Tagen — oder 0 für unbegrenzt. Wichtig: Speichern wirkt sofort und endgültig, es gibt keinen Rückgängig-Knopf für bereits gelöschte Rohdaten.

Verlaufsdaten bleiben trotzdem erhalten

Auch wenn die Detail-Messwerte (check_results) nach der eingestellten Frist gelöscht werden, bleiben die daraus abgeleiteten 5-Minuten-, Stunden- und Tages-Aggregate für ihre jeweils eigene, viel längere Vorhaltezeit erhalten (Tages-Werte unbegrenzt). Langzeit-Trends im Verlauf gehen also nicht mit der Rohdaten-Retention verloren.

5. „Jetzt aufräumen"

Erscheint auf der Speicher-Seite ein sichtbarer Rückstand (Kompression oder Retention hinkt hinterher), zeigt sich ein Button „Jetzt aufräumen". Er stößt den Wartungslauf sofort an, statt auf den nächsten planmäßigen Lauf (alle 6 Stunden) zu warten, und meldet das Ergebnis im Klartext, z. B. „12 Abschnitt(e) komprimiert, 4 per Aufbewahrung entfernt".

6. Kompression greift nicht sichtbar

Zeigt die Datenklassen-Tabelle eine Warnung „Kompression greift nicht", obwohl Kompression konfiguriert ist — meist ein Zeichen, dass der Wartungslauf noch nicht durchgelaufen ist (bis zu 6 Stunden Verzögerung) oder dass frisch geschriebene Chunks naturgemäß noch unkomprimiert sind (Kompression greift erst nach der konfigurierten Frist, z. B. 3 Tage). Kein Grund zur Sorge, solange sich der Wert über mehrere Stunden hinweg bewegt.

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, besonders nach mehreren Updates. Das „Wohin der Platz geht"-Panel zeigt den reklamierbaren Anteil direkt an; ein docker system prune (manuell, außerhalb der GUI) räumt das zusätzlich auf, sollte aber außerhalb eines laufenden Updates passieren.

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. Retention pro Datenklasse 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