Fehler bei Graphite in der Historie

Icinga Web Modules
,
1

Hallo und guten Tag,

ich möchte gerne einmal mein Problem darstellen. Wir haben ein Problem mit dem darstellen der Graphen in der Vergangenheit. Bei Checks die alle 90 Sekunden prüfen, wird alles perfekt dargestellt. Leider laufen nicht alle checks alle 90 sekunden das es ja auch eine gewisse Last verursacht. Bei checks die default mäßig alle 5 Minuten laufen, kann ich mir die Graphen nur bis zu 2 Tage in der Vergangenheit anzeigen lassen.

Wir verwenden folgende Versionen.
Icinga Web 2 Version 2.8.2
graphite 1.1.0

Ich möchte mich gerne schon im Vorfelde für eure Hilfe bedanken.
Danke und Gruß
Enrico

2

[icinga_internals]
pattern = ^icinga2…*.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
retentions = 5m:7d

[icinga_default]
pattern = ^icinga2.
retentions = 1m:2d,5m:10d,30m:90d,360m:4y

[default_1min_for_1day]
pattern = .*
retentions = 60s:1d

[carbon]
pattern = ^carbon.

3

Das lässt sich anhand der Graphite-Konfiguration erklären.

Das Pattern ^icinga2. sorgt dafür, dass bei allen Checks die Regel unter [icinga_default] greift.
Diese Retention von 1m:2d,5m:10d,30m:90d,360m:4y bedeutet es wird mit einer Genaugigkeit von 1 Minute für die ersten 2 Tage, dann 5 Minuten für 10 Tage, 30 Minuten für 90 und 360 Minuten für 4 Jahre gearbeitet.

Wenn wir jetzt einen Check mit den standardmäßigen 90 Sekunden nehmen, werden sicher 3 Messwerte bei der 1 Minutengenauigkeit gespeichert. Auch das ist schon nicht ideal, aber es funktioniert noch, da in der Konfigurations für die Aggregation steht, dass beim Aggregieren auf die nächste Genaugkeit ein Durchschnitt gebildet werden soll wenn mindestens 50% ( xFilesFactor=0.5) der Werte vorhanden ist. Da 3 von 5 Werten einem Faktor von 0.6 entspricht funktioniert die Aggregation.

Sind aber weniger als 50% der Werte vorhanden, bei 5 Minuten Checkinterval wäre dies 1 Wert bei 5 Zeitslots, also 20% oder Faktor 0.2, findet keine Aggregierung statt und somit ist schon die 5 Minutengenauigkeit leer und es gibt nur Werte für maximal 2 Tage!

Also hier unbedingt dem Checkinterval entsprechende Werte für die erste Aggregationsstufe verwenden! Und danach müssen die Werte auch ein passendes Vielfaches sein. Das könnte also so aussehen, wobei für 5MINUTENCHECK ein passendes Pattern wie der Name oder das Checkcommand eingesetzt werden muss

...
[icinga_5m]
pattern = ^icinga2\..*\.5MINUTENCHECK
retentions = 5m:10d,30m:90d,360m:4y


[icinga_default]
pattern = ^icinga2\.
retentions = 90s:2d,6m:10d,30m:90d,360m:4y
...
1 Like
4

Hi.

@dgoetz This is probably one of the best explanations about the storage-schemas I have ever read. Thank you.

Additional note:
A change to the storage-schemas additionally requires an update of the whisper-files which already exist.
See also here

Would you two please translate this into english?

Greetings.

5

For sure I already thought about during writing.

So the problem of the original poster is that graphite is not showing data after two days for checks with a check interval of 5 minutes while it works fine with 90 seconds as interval.

Thankfully the problem is easily solved when you look at the posted configuration.

First we need to look which pattern is matching so which section is responsible, in this case ^icinga2. which results in section [icinga_default] and by this retention of 1m:2d,5m:10d,30m:90d,360m:4y. This means data will be stored with 1 minute accuracy for 2 days, then aggregated to 5 minutes for 10 days, 30 minutes for 90 days and 360 minutes for 4 years.

Now for the checks that work which are 90 seconds and will generate 3 metrics within 5 minutes. So while it works it is not ideal as we will only get 3 metrics instead of 5. This is 60% or a factor of 0.6. In the default aggregation configuration an aggregation by average is defined and with xFilesFactor=0.5 meaning a minimum of 50% of data is required for an aggregation to happen.

The not working ones are only filing one timeslot of 5 because they are checked every 5 minutes so it is only 20% or a factor of 0.2 which will result in no aggregation for the second interval and all later ones. And this results in having data only for the first 2 days!

What has to be changed is the configuration of the retention to match the check interval in Icinga! Furthermore to the first one matching the interval, further ones have to be a multiple of the first one.

So two changes for this specific case are needed. A new section for the 5 minute checks is created which requires a matching pattern like name of the service or check command instead of the placeholder 5MINUTECHECK. And the default section was adjusted.

...
[icinga_5m]
pattern = ^icinga2\..*\.5MINUTECHECK
retentions = 5m:10d,30m:90d,360m:4y


[icinga_default]
pattern = ^icinga2\.
retentions = 90s:2d,6m:10d,30m:90d,360m:4y
...

Furthermore you have to change the aggregation of the existing whisper files using whisper-resize / whisper-auto-resize or remove the files and let them be recreated for the change having an effect. (Thanks for pointing out @homerjay)

2 Likes
6

Danke für die schnellen Rückmeldungen.
Ich werde das asap umsetzen und testen.

Gruß
Enrico