...oder auch: Die Magie von "date".
Wer mit einem Bash-Script einen Checkpunkt für ein Monitoring-System wie z.B. Check_MK schreibt, der kennt wahrscheinlich das Problem:
Manchmal übertreibt ein Monitoring-System und ruft seinen Check von Remote so oft auf, dass die Ressourcen des zu überwachenden Clients schlichtweg zu ausgelastet sind.
Das Monitoring hilft also nicht mehr, sondern bringt den zu überwachenden Client zu Fall.
Man kann jedoch die Ausgaben eines Scriptes sehr einfach (selbst) Cachen und sollte das auch selbst übernehmen, denn die Caching-Mechanismen solcher Monitoring-Systeme sind auch gern mal etwas unberechenbar...
Wer z.B. wie gewohnt und brav nach Dokumentation in Check_MK mehrzeilige Ausgaben in /usr/lib/check_mk_agent/local/${CACHE_ZEITINDEX}/mein_check.bash hinterlegt, der wird feststellen, dass diese nicht (mehr) funktionieren: Das Ergebnis wird einfach verschluckt und nicht angezeigt.
Mehrzeilige Ausgaben funktionieren anscheinend also nur noch in /usr/lib/check_mk_agent/local/ , wo jedoch dann kein Caching stattfindet und man den Client ggf. überlastet.
Ein Teufelskreis. :-) Was nun tun?
Ein kleines "if" mit "date" und die Ausgabe mit "tee" bringt hier einen Ausweg.
Hands on...!
# Konfigurieren von einem Cache
f_cachefile="/tmp/MeinCheck.cache"
cachetimeout="6 Hours"
umask 177
if [ -f "${f_cachefile}" ]; then
if [ $( date "+%s" ) -lt $( date -d "$( date -Rr "${f_cachefile}" ) + ${cachetimeout}" "+%s" ) ]; then
cat "${f_cachefile}"
exit 127
else
rm -f "${f_cachefile}"
fi
fi
# Hier passiert ein Test.
if [ "1" == "2" ]; then
echo "2 MeinCheck:1 - CRIT: Das Ergebnis war nicht abzusehen." | tee -a "${f_cachefile}"
else
echo "0 MeinCheck:1 - OK: Das Ergebnis war zu erwarten." | tee -a "${f_cachefile}"
fi
# Hier passiert der zweite Test.
if [ "$( date "+%u" )" == "1" ]; then
echo "1 MeinCheck:2 - WARN: Montage sind schrecklich." | tee -a "${f_cachefile}"
else
echo "0 MeinCheck:2 - OK: Alles okay." | tee -a "${f_cachefile}"
fi
Keine Kommentare:
Kommentar veröffentlichen