Graphite mit Icingadaten füttern

Seit Icinga 2 wird Graphite über ein eigenes Feature, also direkt, unterstützt. Muss man bei Icinga 1 noch den Umweg über zusätzliche Tools, wie z.B. Graphios gehen, fällt das nun weg. Standardmäßig erwartet Icinga 2 den Carbon Cache Daemon auf dem selben System (localhost) an Port 2003, also über das Plaintext Protokoll. Davon abweichende Einstellungen können in der Konfigurationsdatei „/etc/icinga2/features-available/graphite.conf“ vorgenommen werden.
Zunächst zieht der Carbon Cache Daemon die Datei „storage-schemas.conf“ zur Speicherung bzw. Aggregation der Metriken heran, die Icinga 2 Dokumentation gibt hier für den Graphite Carbon Cache Writer bereits ein allgemein gültiges Schema vor:

[icinga_internals]
pattern = ^icinga\..*\.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
retentions = 5m:7d
[icinga_default]
pattern = ^icinga\.
retentions = 1m:2d,5m:10d,30m:90d,360m:4y

Damit die Verdichtung der Daten korrekt funktioniert, ist es wichtig das die angegebenen Werte mit den wirklichen Host- bzw. Servicecheckintervallen (check_interval) überstimmen. In diesem Beispiel müsste also das Intervall für Host- und Servicechecks auf eine Minute gesetzt sein. Gibt es Abweichungen davon, müssen hier entsprechend Einträge hinzugefügt bzw. abgeändert werden.
Ob die Einstellungen passen, lässt sich nach den ersten Prüfungen mit den mitgelieferten Whisper Scripts anhand der abgelegten Metriken relativ leicht überprüfen. Zuerst kontrollieren wir mit whisper-info ob die angegeben Werte korrekt übernommen wurden:

# whisper-info rta.wsp
maxRetention: 126144000
xFilesFactor: 0.5
aggregationMethod: average
fileSize: 191104
Archive 0
retention: 172800
secondsPerPoint: 60
points: 2880
size: 34560
offset: 64
Archive 1
retention: 864000
secondsPerPoint: 300
points: 2880
size: 34560
offset: 34624
Archive 2
retention: 7776000
secondsPerPoint: 1800
points: 4320
size: 51840
offset: 69184
Archive 3
retention: 126144000
secondsPerPoint: 21600
points: 5840
size: 70080
offset: 121024

Die angegebene retention im Archive 0 von 172800 Sekunden stimmt mit dem angegebenen Speicherintervall überein (2*24*60*60 für 2 Tage) und auch die secondsPerPoint wurden mit 60 (also 1m) richtig übernommen. Eine stichpunktartige Kontrolle der retention von Archive 2 für 90 Tage (also 90*24*60*60) zeigt, das auch hier die Werte stimmen.
So weit gut so gut, allerdings sollte man um wirklich sicher zu gehen auch noch einen Blick auf die gespeicherten Datenpunkte werfen. Das geschieht mit whisper-fetch, der Parameter pretty zeigt dabei menschenlesbare Zeitstempel an:

# whisper-fetch --pretty rta.wsp
...
Tue Jul 21 09:05:00 2015	0.000083
Tue Jul 21 09:06:00 2015	0.000072
Tue Jul 21 09:07:00 2015	0.000137
Tue Jul 21 09:08:00 2015	0.000093
Tue Jul 21 09:09:00 2015	0.000102

Wenn die Einstellungen korrekt sind, sollten hier wie im gezeigten Beispiel nach Möglichkeit keine leeren Datenpunkte (Eintrag: None) vorkommen, andernfalls muss hier nochmal nachgefasst werden.

Markus Waldmüller

Head of Strategic Projects

---

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Lies mehr von Markus und triff unser Team