Gnocchi und Archiv Policies

Gnocchi ist eine time series database die aus dem OpenStack Projekt hervorgegangen ist. Da Gnocchi erst 2014 entstanden ist, wurde versucht die Schwächen vorhandener Lösungen zu umgehen. Im Vergleich fallen mir vor allem folgenden Features auf:

  • Mandantenfähigkeit
  • Skalierbarkeit
  • Hochverfügbarkeit
  • REST Interface (HTTP)
  • Unterstützung moderner Backends wie Ceph (librbd), Swift und S3
  • OpenSource

Ein weiters Feature ist die Unterstützung von archive policies. Diese legen fest wie lange und in welcher Granularität Metriken vorgehalten werden. Zusätzlich kann auch die Art der Aggregation definiert werden. Sendet man den unten stehenden json Text per HTTP an /v1/archive_policy wird z.B. eine Policy angelegt die Metriken mit einer Granularität von 5 Minuten für 62 Tage speichert und dafür 17856 Punkte benötigt (12 Metriken je Stunde * 24 Stunden * 62 Tage = 17856). Zusätzlich werden die Metriken in aggregierter From  für 365 und 3650 Tage gespeichert.
 

{
  "name": "router-metriken",
  "back_window" : 0,
  "definition" : [
    {
      "points" : 17856,
      "granularity" : "00:05:00",
      "timespan" : "62 days, 0:00:00"
    },
    {
      "points" : 8760,
      "granularity" : "1:00:00",
      "timespan" : "365 days, 0:00:00"
    },
    {
      "points" : 3650,
      "granularity" : "24:00:00",
      "timespan" : "3650 days, 0:00:00"
    }
  ],
  "aggregation_methods" : [
    "min",
    "max",
    "mean",
    "sum"
  ]
}

 
Welche archive policy für einzelne Metriken angewendet wird kann über rules bestimmt werden. Neue Metriken werden per Regex geprüft und ggf. einer Policy zugewiesen. Treffen mehrer Regeln greift der längste Regex. Mit der folgenden Regel werden alle Metriken die mit router beginnen zu der oben definierten Policy hinzugefügt.
 

{
  "archive_policy_name": "router-metriken",
  "metric_pattern": "router.*",
  "name": "router-metriken"
}

 
Mein erster Eindruck von Gnocchi ist durchaus positiv und mit den genannten Features kann sich die OpenStack Lösung von der Konkurrenz abheben. Aktuell ist Gnocchi wohl am besten für die Bedürfnisse von OpenStack ausgelegt. Es gibt aber auch Integrationen zu collectd, statsd, Icinga und Grafana.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Icinga Webinare im Dezember

NETWAYS Webinare Nachdem im Rahmen einer wieder einmal erfolgreichen OSMC sowohl eine neue Version von Icinga 2 als auch Icinga Web 2 veröffentlicht wurde, wollen wir natürlich die Gelegenheit nutzen, diese in unseren Webinaren vorzustellen.
Die Termine im Dezember stehen bereits fest und wir freuen uns wie immer auf eine rege Teilnahme zum Abschluss dieses erfolgreichen Jahres!

Titel Zeitraum Registrierung
Icinga 2 – Neues in 2.4 08. Dezember 2015 – 10:30 Uhr Anmelden
Icinga Web 2: Das neue Interface 09. Dezember 2015 – 10:30 Uhr Anmelden
Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Graphite mit Icingadaten füttern

Sgraphite_ping4-rtaeit 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
Markus Waldmüller
Lead Senior Consultant

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 Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.