Wir haben zunehmend mit wachsendem Speicherplatz unserer 1.6p11 Instanz zu kämpfen und nun stellt sich mir die Frage ob und wie genau das “logrotate” funktioniert. Der Speicher wächst linear an und bezüglich der historischen Daten finde ich teils wiedersprüchliche Informationen in der Dokumentation bzw. bin nicht sicher welche Module nun bei uns zum tragen kommen. Vielleicht kann mir hier jemand die Gedanken ordnen?
Was wächst?
/omd/sites//var/nagios/archive (~100G) wächst am stärksten
/omd/sites//var/pnp4nagios (~36G) weniger relevant
In der Doku bin ich über Messwerte in Checkmk schnell und einfach auswerten gestolpert. Hier geht es scheinbar ausschließlich um die Graphen und damit um “rrdcached”. Auch wenn ich die hier genannte WATO-Rule “Configuration of RRD databases of services” nicht finden kann, so bringt mir dies bei 300MB keine Kopfschmerzen.
Unter “Global configuration settings for Check_MK” finde ich bei uns noch den Punkt “AUTOMATIC DISK SPACE CLEANUP” der files älter als 365 Tage löschen sollte. Mir ist nicht ganz klar welche Daten hier genau gemeint sind.
Schlussendlich bin ich in den cronjobs noch auf /omd/sites/hdc/etc/cron.d/cmk_cleanup_piggyback gestoßen.
Nun meine Fragen: Welches Mechanismus ist für was zuständig und habe ich hier noch etwas übersehen?
Ich suche die Möglichkeit historische Daten nach X Tagen zu löschen. Welchen Mechanismus suche ich?
Die mit Abstand meisten Daten dürften sich in /omd/sites//var/nagios/archive ansammeln. Kann ich hier durch einen nicht-checkMK Mechanismus selbst Bereinigungen durchführen und was wäre davon betroffen?
Historische Events also alles was der Core so aufgezeichnet hat über die Zeit. Pro Tag existiert eine Datei mit dem Datum im Namen. Wenn man will kann man alles löschen was zum Beispiel 2020 und älter ist.
Hier würde ich aber auch ansetzen da 100GB in diesem Verzeichnis darauf hindeuten, dass am System es grundlegende Probleme gibt.
Bei nur 36GB Graphendaten ist das System noch nicht so riesig da sollten keine 100GB Core Log existieren.
Dein verlinkter Artikel aus dem Handbuch bezieht sich nicht auf den rrdcache Ordner sondern auf den pnp4nagios Ordner.
Hier kann man recht einfach aufräumen - alle Files welche innerhalb der letzten x Tage nicht angefasst wurden kann man entfernen. Ich selbst hab hier meist so Werte von 90 Tagen genommen. Achtung dieses Verfahrungen nur in der RAW Edition so anwenden und auch nur im Verzeichnis ~/var/pnp4nagios/perfdata. Bei der Verwendung der Enterprise muss anders vorgegangen werden da hier nicht alle Daten regelmäßig “angefasst” werden.
Danke für die rasche Antwort. Das es im nagios/archive Ordner Files pro Tag gibt kann ich bestätigen. Die haben alle eine Size von ca. 4.4 bis 9MB wobei an manchen Tagen ausreisser mit 28MB auch dabei sind. Außerdem habe ich Dateien mit zufälligen Zeichenketten beginnend immer mit “sed”. zB “sedauhriu”
Wenn hier offensichtlich schon etwas “falsch” ist, gibt es einen Tipp in welche Richtung ich weiter suchen soll?
Es gibt im Grunde nur ein Problem mit dem System: Wenn ich availability-abfragen mache, dann kann es bis zu 10min dauern, bis die Web-GUI wieder erreichbar ist. Ich vermute, weil eben so viele Files durchsucht werden müssen (diese reichen bis 2016 zurück). Tortzdem finde ich das Verhalten komisch, zumal es CPU-seitig zu keinem Bottleneck kommt und das System auch auf SSD liegt.
Ich glaube ich würde als nächstes einmal alte Logs ausmiste versuchen.
Filenamen die mit “sed” anfangen? klingt als hätte da mal jemand mit GNUs “sed” cli tool aufräumen wollen und evtl. n paar copy/paste Fehler gemacht.
Bist du der einzige Admin des Checkmk Hosts oder könnte da jemand anders dran gewesen sein?
Wie Andreas schon geschrieben hat: wenn dich die ältere Historie nicht interessiert, kannst du alle älter als ein bestimmtes Datum einfach löschen - da ist sonst nix weiter zu beachten. Ggfs. können die sed files ja auch raus. Wenn diese halbwegs aktuell sind, würde ich mal nach Cronjobs suchen die “sed” erwähnen, vielleicht läuft da ja auch irgendn script das Unsinn macht. Von Checkmk kommt sowas zumindest nicht.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
klingt als hätte da mal jemand mit GNUs “sed” cli tool aufräumen wollen und evtl. n paar copy/paste Fehler gemacht.