Im vorletzten Teil unseres großen InGraph Reiseführers geht es nicht direkt um das Graphing an sich, sondern um das Monitoring Plugin check_ingraph, das InGraph mitliefert.
Viele Probleme sind zum Glück schnell erklärt, aber leider auch genauso schnell verursacht: Switch kaputt, Festplatte tot, Zahlendreher beim ‚kill‘.
Gelegentlich gibt es aber Situationen, die nicht einfach ad-hoc erscheinen, sich für das Adlerauge eines Sysadmins jedoch am Graphen erkennen lassen. Wenn normale, zeitlich begrenzte Lastanstiege im Lauf der Zeit immer stärker ausschlagen, kann man das im Wochenverlauf des Graphen erkennen – noch bevor es kritisch wird.
Aber: Schön und gut wenn man solche Probleme an den Werten des Graphen erkennt – nur wer vergleicht schon jeden Tag die aktuelle Last mit der Last von letzter Woche (vor allem wenn die Maschinen keine Probleme bereiten) ?
Ich weiß wer: check_ingraph!
Der kleine Streber ist simpel, aber effizient: Das Plugin vergleicht bestimme Werte (hier z.B. die Serverlast) aus einem Interval mit den Werten eines Intervals aus der Vergangenheit und geht auf Warning/Critical wenn sich zu starke Abweichungen zwischen den Intervallen ergeben. Man kann so z.B. überprüfen, ob die Lastwerte der letzten 2 Stunden sich stark von den Lastwerten der letzten zwei Stunden vor einer Woche unterscheiden. Im Falle des Falles kann das Plugin dann präventiv darauf hinweisen, dass die Last im Vergleich ungewöhnlich hoch ist (selbst wenn Sie noch nicht im kritischen Rahmen für das System ist).
In der unteren Grafik ist ein check_ingraph Check grafisch dargestellt, der prüft ob die Werte der letzten Woche sich stark von denen dieser Woche unterscheiden:
Der Aufruf ist dabei wie folgt:
check_ingraph -H http1 -S "Current Load" -P load1 -F average -f -360 -g -192 -s -192 -t 0 -w 10 -c 20
Und, damit ich nicht einfach die tolle Dokumentation kopiere, etwas genauer:
- -H http1 -S „Current Load“ : -H ist der Parameter für den Host, -S für den Service. Hier überprüfen wir also den Current Load check vom Host ‚http1‘
- -P load1 : Perfdaten können ja beliebig viele Parameter enthalten, hier entscheiden wir uns für die Werte, die als load1 bezeichnet sind
- -F average: Gibt an, dass der Durchschnitt der Intervalle verglichen wird. Hier kann man auch ‚trend‘ für Trendwerte, ’stddev‘ für die Standardabweichung oder ‚hw‘ für Holt-Winters Forecasting verwenden
- -f -360: Das erste Interval beginnt vor 15 Tagen (= -1 (da in der Vergangenheit) * 15 * 24 (Stunden))
- -g -192: Das erste Interval endet vor 8 Tagen
- -s 192: Das zweite Interval beginnt vor 8 Tagen
- -t 0 : Das zweite Interval endet genau jetzt
- -w 10: Bei 10% Abweichung wird ein warning zurückgegeben
- -c 20: Bei 20% Abweichung wird ein critical zurückgegeben
Das sind zugleich auch die wichtigsten Parameter für die meisten Checks.
Zwar ist das Plugin recht einfach zu bedienen, die Effizienz hängt jedoch stark vom individuellen Anwendungsfall ab. Hier ein paar Fragen, die man sich beim Konfigurieren gerne stellen kann:
- Ist meine Intervallgröße passend gewählt? Zu große Intervalle neigen dazu Abweichungen zu verschlucken, zu kleine Intervalle geben kleinen Abweichungen zu viel Gewicht.
- Ergeben meine Intervalle Sinn? Wenn ein Datenbankserver nur unter der Woche belastet wird ergibt ein Vergleich zum Vortag keinen Sinn, da Samstage und Montage immer Alarm schlagen werden.
- Ergibt Forecasting einen Sinn? Wenn ja – ergibt es einen Sinn bei meinem Intervall?
Check_ingraph bietet damit eine sinnvolle Ergänzung zum visuellen Monitoring mit Graphen. Der ein oder andere schleichende Ausfall lässt sich beim richtigen Einsatz des Plugin früh erkennen und der Admin schläft damit mal wieder etwas ruhiger.
Also runterladen und ausprobieren!
0 Kommentare