[GELÖST] Icinga-Daten unter /var/spool/icinga2/ managen

[BrotherJ]

Hallo,

meine /var-Partition läuft infolge von Incinga unter " /var/spool/icinga2/" massiv voll:

Code: Alles auswählen

# du -ch --max-depth=1 --one-file-system /var/spool/icinga2
18G     /var/spool/icinga2/perfdata
8,0K    /var/spool/icinga2/tmp
18G     /var/spool/icinga2
18G     insgesamt

Wie ließe sich das managen, so dass regelmässig hier wieder Platz freigegeben wird?

Beste Grüße

Andreas

[JTH]

Ich habe vorweg keine Ahnung, was Icinga genau ist und macht. Aber dem Vernehmen nach soll /var/spool/icinga2/perfdata nicht volllaufen, wenn das Ganze richtig konfiguriert ist. Die Daten sollten weiterverarbeitet und dann gelöscht werden: /var/spool/icinga2/perfdata is keeping all perf data Wenn das nicht geschieht, die Daten nicht verwendet werden, solltest du die entsprechende Funktion vllt. abschalten?

Das war das vierte Ergebnis bei Google

[BrotherJ]

Ich habe vorweg keine Ahnung, was Icinga genau ist und macht.

Das ist die freie Version von Nagios, ein Fork davon. Und genauso wie Nagios ist ein Monitoringsystem. Aber Danke für den Link, ich hoffe er hilft weiter.

Beste Grüße

BrotherJ

[Meillo]

Halte uns bitte auf dem Laufenden, wie es sich weiterentwickelt. Ich interessiere mich fuer die Erklaerung und die Loesung des Problems.

[BrotherJ]

Halte uns bitte auf dem Laufenden, wie es sich weiterentwickelt. Ich interessiere mich fuer die Erklaerung und die Loesung des Problems.

Keine Sorge, wer meine Posts verfolgt, wird feststellen, dass wenn ich Fragen stelle, auch die Lösung dokumentiere. Das mache ich nicht nur, damit Andere davon profitieren, sondern auch zur eigenen Dokumentation.

Nun, perfdata kann man aktivieren oder auch nicht, wird aber wie in dem Blog erwähnt in den meisten Tutorials empfohlen zu aktivieren. Das ist es somit eben auch bei mir der Fall. Andere Seiten wie diese https://blog.veloc1ty.de/2016/07/04/ici ... 2perfdata/ empfehlen das Löschen der betreffenden Dateien. Mich wundert es vielmehr, dass Icinfǵa2 nicht selber ein Mechanismus zur Dateienbereinigung mitanbietet oder die Tutorials das nicht erwähnen. Denn diese Dateienflut und die damit verbundenen Konsequenzen ist doch bekannt.

Meine Recherche am System hatte jetzt ergeben, dass

Code: Alles auswählen

ll /var/spool/icinga2/perfdata | wc -l
2346119

mit über 2 Mio. Dateien der Bestand exorbitant hoch ist. Meine Lösung in Mangel eines automatischen Bereinigungsmechanismus bei Icinga2 ist das Löschen wie folgt und zukünftig als Cronjob:

Code: Alles auswählen

find /var/spool/icinga2/perfdata -type f -ctime +90 -exec rm {} \;

Da der Löschvorgang noch läuft kann ich erst nach dieser Antwort das Ergebnis berichten.

Mit besten Dank

BrotherJ

[BrotherJ]

Das Löschen dauert eine ganze Weile, lohnt sich aber. Ich würde sogar lediglich für 30 Tage die Dateien belassen und via Cronjob ältere Dateien wöchentlich aus dem Verzeichnis löschen.

--- Problem gelöst! ---

[MSfree]

Das Löschen dauert eine ganze Weile, lohnt sich aber. Ich würde sogar lediglich für 30 Tage die Dateien belassen und via Cronjob ältere Dateien wöchentlich aus dem Verzeichnis löschen.

Man könnte auch logrotate für den Zweck "mißbrauchen". Das kann dann auch alte Dateien komprimieren, bevor sie nach der Aufhebezeit ganz gelöscht werden. Logrotate wird von cron sowieso schon täglich ausgeführt und der Konfigurationsaufwand ist auf die Erstellung einer neuen Datei unter /etc/logrotate.d begrenzt.

[BrotherJ]

Man könnte auch logrotate für den Zweck "mißbrauchen". Das kann dann auch alte Dateien komprimieren, bevor sie nach der Aufhebezeit ganz gelöscht werden. Logrotate wird von cron sowieso schon täglich ausgeführt und der Konfigurationsaufwand ist auf die Erstellung einer neuen Datei unter /etc/logrotate.d begrenzt.

Stimmt, "man könnte". Das halte ich aber für wenig Zweckerfüllend. Der Eintrag in der crontab

Code: Alles auswählen

@weekly /usr/bin/find /var/spool/icinga2/perfdata -type f -ctime +30 -exec rm {} \;

ist kleiner als eine ganze Datei unter /etc/logrotate.d zu erstellen. Und betrachten wir das Ausgangsproblem einer vollgelaufenen var-Partition wegen eben diesem perfdata, dann macht das Befüllen mit komprimierten alten Dateien für mich keinen nachvollziehbaren Sinn.
Das waren jetzt innerhalb von 11 Monaten 2.346.119 Dateien, nicht sonderlich große Einzeldateien aber in der Summe doch 11 GB. Und ohnehin Icinga2 funktioniert weiter, selbst die Zeitleiste dort drin ist unberührt. Ergo waren diese 2 Mio. Dateien ohnehin bedenkenlos löschbar.

Ich würde lieber logrotate für das nutzen, wozu es geschaffen wurde: Rotierende Logfiles. Wenn ich diese perfdata-Dateien unbedingt aufheben wollte, geht auch ein klassisches Backup mit Komprimierung.

[JTH]

ist kleiner als eine ganze Datei unter /etc/logrotate.d zu erstellen.

Die Datei für logrotate wäre sogar 10 Buchstaben kürzer

Code: Alles auswählen

/var/spool/icinga2/perfdata/* {
	maxage 30
	missingok
	rotate 0
	weekly
}

[Meillo]

Ich würde lieber logrotate für das nutzen, wozu es geschaffen wurde: Rotierende Logfiles. Wenn ich diese perfdata-Dateien unbedingt aufheben wollte, geht auch ein klassisches Backup mit Komprimierung.

Ich finde, dass logrotate durchaus fuer solche Zwecke gemacht ist. Wahrscheinlich ist es auf Dauer auch uebersichtlicher, das per logrotate und nicht per Cronjob umzusetzen.

[BrotherJ]

Die Datei für logrotate wäre sogar 10 Buchstaben kürzer

Code: Alles auswählen

/var/spool/icinga2/perfdata/* {
	maxage 30
	missingok
	rotate 0
	weekly
}

Ok, stimmt mit dem Parameter "rotate 0" wäre es durchaus für den Einen oder den Anderen annehmbar.