whisper-Daten aufräumen

Diesen Beitrag schrieb ich 6 Jahre und 6 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.

Geschätzte Lesezeit: 2 Minuten

Hosts kommen, Hosts gehen. Services werden eingerichtet, umbenannt, verworfen. Checks werden von by_ssh und nrpe auf den Icinga 2-Core umgestellt. Kurz: es gibt viele gute Gründe für veraltete Datenbestände in Sachen Graphite.

Störend finde ich diese Altlasten insofern, als dass sie

  • Ressourcen verbraten: und das nicht gerade zu knapp – wir sprechen hier durchaus von vielen Gigabyte auf schnellen (und somit teuren) Datenträgern
  • Verwirrung stiften: spätestens, wenn Kollegen Dashboards in Grafana erstellen wollen, sind sie verblüfft bezüglich der Auswahlmöglichkeiten, die sich ihnen bieten. Denn sind Daten vorhanden, werden sie als Option angeboten, auch wenn sie veraltet sind

Ich habe also zwei Möglichkeiten: entweder ich mumpfe die wsp-Files entsprechend um, merge, verschiebe, was auch immer nötig ist, um die Daten zu halten – das bietet sich an, wenn ein Service-Check lediglich umbenannt wird. Im Falle entsorgter Hosts will ich die Daten aber auf lange Sicht ganz verwerfen. Beides will ich mir nun endlich mal hier aufnotieren – ist nämlich ganz klassisch etwas, das ich jedes Mal aufs Neue nachschlagen muss… ;)

Löschen veralteter Daten

Welche Dateien wurden seit mindestens 180 Tagen nicht mehr beschrieben? Mit dem folgenden Aufruf liste ich mir diese auf – zusammen mit einer Hochrechnung, wieviel Speicherplatz freigeschaufelt würde, wenn ich den Kram sofort über die Wupper schicke. Meine whisper-Daten liegen in /var/lib/graphite/whisper/icinga2 – der Pfad kann in deinem Setup natürlich anders heißen.

$ find /var/lib/graphite/whisper/icinga2 \
-name "*wsp" \
-mtime +180 \
-exec echo -n -e {}"\0" \; \
| du -hc --files0-from=-
...
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/reachable.wsp
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/acknowledgement.wsp
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/max_check_attempts.wsp
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/state.wsp
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/downtime_depth.wsp
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/latency.wsp
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/current_attempt.wsp
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/execution_time.wsp
424K /var/lib/graphite/whisper/icinga2/oldhost/services/Cert/http/metadata/state_type.wsp
11G total

Jetzt wird es spannend: genau diese wsp-Files sollen gelöscht werden. Teste den Aufruf vorher und teste ihn nicht ohne Backup, ich übernehme keine Haftung dafür falls er auf deinem Systemen irgendwo Amok läuft! :)

$ find /var/lib/graphite/whisper/icinga2 \
-type f \
-mtime +180 \
-name "*wsp" \
-exec rm '{}' \;

Dieser Löschvorgang verläuft kommentarlos; wenn du anschließend den ersten Aufruf erneut ausführst wirst du feststellen, dass keine Daten mehr gelistet werden. Allerdings wurden lediglich die wsp-Daten gelöscht – was zurückbleibt sind Massen leerer Ordner. Wie viele das genau sind, kannst du dir mit folgendem Aufruf listen lassen – lässt du die Pipe an wc -l weg, erhältst du stattdessen die konkrete Liste der Ordner:

$ find /var/lib/graphite/whisper/icinga2 \
-type d \
-empty \
| wc -l
5896

Kein Mensch braucht Massen leerer Ordner – also werden nun auch die in die Tonne getreten.

$ find /var/lib/graphite/whisper/icinga2 \
-type d \
-empty \
-delete

Für Mutige, die ihren Skills hier voll und ganz vertrauen: lässt sich natürlich prima in Cron-Jobs verpacken.

#!/usr/bin/env bash
 
PROG=$( basename $0 )
WHISPER_DATA="/var/lib/graphite/whisper/icinga2"
DAYS="180"
 
logger "=> Starting $PROG"
 
SAVED_SPACE="$( find $WHISPER_DATA \
-name '*wsp' \
-mtime +$DAYS \
-exec echo -n -e {}'\0' \; \
| du -hc --files0-from=- \
| tail -n 1 \
| awk '{print $1}' )"
 
logger "$PROG about to delete $SAVED_SPACE..."
 
find $WHISPER_DATA \
-type f \
-mtime +$DAYS \
-name "*wsp" \
-exec rm '{}' \;
 
EMPTY_FOLDERS="$( find $WHISPER_DATA \
-type d \
-empty \
| wc -l )"
 
logger "$PROG about to delete $EMPTY_FOLDERS folders..."
 
find $WHISPER_DATA \
-type d \
-empty \
-delete
 
logger "$PROG ... done!"

Merge whisper files

Irgendwann kam ich mal auf die großartige Idee, Service-Checks umzubenennen. Da ich die bis dahin gesammelten Performance Daten nicht verlieren wollte, musste ich mit whisper-fill und whisper-resize die Säge auspacken und mir einen Workaround schnitzen. Beim Aufräumen fand ich das zugehörige Script, und auch wenn ich es gerade nicht mehr brauche (und es ein wenig rudimentär ist), ist es zum vollständigen Verwerfen doch zu schade.

#!/usr/bin/env bash
 
SERVICE_OLD="$1"
SERVICE_NEW="$2"
WHISPER="/var/lib/graphite/whisper/icinga2"
LOG="/tmp/Processed_Hosts"
 
if [ -e $LOG ] ; then
  touch $LOG
fi
 
echo d > $LOG
cd $WHISPER
 
## Jetzt finden wir alle, die diesen alten Service haben
for h in $(dirname `find * -type d -iname $SERVICE_OLD` | cut -d "/" -f1)
do
  SOURCE="$WHISPER/$h/services/$SERVICE_OLD"
  TARGET="$WHISPER/$h/services/$SERVICE_NEW"
 
  cd $SOURCE
  for f in $(find * -type f -iname "*.wsp")
    do
      if [ -a $f ] ; then
        whisper-fill $f $TARGET/$f
        whisper-resize --nobackup $TARGET/$f 1min:7d 3min:30d 30min:180d 6h:2y
        chown -R _graphite: $TARGET
        echo "Processed $(basename $f) for $h..." >> $LOG
      fi
    done
 
  echo "==> Now deleting $SOURCE..." >> $LOG
  echo "" >> $LOG
  rm -rf $SOURCE
done

Falls es dir irgendwie nützlich ist: have fun! 😎

Alle Bilder dieser Seite: © Marianne Spiller – Alle Rechte vorbehalten
Hintergrundbild: Laternenpflanze mit Schnee im eigenen Garten, 2017, 1500x 690px, Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten

Eure Gedanken zu „whisper-Daten aufräumen“

Ich freue mich über jeden Kommentar, es sei denn, er ist blöd. Deshalb behalte ich mir auch vor, die richtig blöden kurzerhand wieder zu löschen. Die Kommentarfunktion ist über GitHub realisiert, weshalb ihr euch zunächst dort einloggen und „utterances“ bestätigen müsst. Die Kommentare selbst werden im Issue-Tracker und mit dem Label „✨💬✨ comment“ erfasst – jeder Blogartikel ist ein eigenes Issue. Über GitHub könnt ihr eure Kommentare somit jederzeit bearbeiten oder löschen.