Seite wählen

NETWAYS Blog

Stresstest für InfluxDB

Nach einer frischen Installation von InfluxDB, egal ob auf einem dedizierten System oder nicht, frägt man sich vielleicht wie leistungsfähig das Graphing Setup nun wirklich ist oder wie viel es denn eigentlich verträgt?

Diese Fragen lassen sich mit influx-stress beantworten. Das in Golang geschriebene Helferchen ist über GitHub erhältlich und feuert beliebig viele einstellbare Metriken an InfluxDB. Dabei spielt es keine Rolle ob es lokal oder remote von einem anderen System aus aufgerufen wird.

Installation

Nachdem das Repository heruntergeladen wurde, wird das Ganze mit „go build“ kompiliert:

# git clone https://github.com/influxdata/influx-stress.git
# cd influx-stress/cmd/influx-stress/
# go build -o /usr/local/bin/influx-stress

Vorbereitungen

Das Tool unterstützt derzeit nur die Authentifizierung für v1, allerdings kann man auf diese bei Bedarf auch komplett verzichten. Mit InfluxDB OSS 2.x kann dafür die „InfluxDB 1.x compatibility API“ benutzt werden. Außerdem empfiehlt es sich für die Tests ein eigenes Bucket anzulegen um es später in einem Rutsch wieder zu löschen oder um gleich eine passende Retention Policy zu definieren.

# influx bucket create -n stress
# influx bucket list
# influx v1 auth create --username stress --password ****** --write-bucket f596604f968324ff
# influx v1 dbrp create --bucket-id f596604f968324ff --db stress --rp infinite

Let’s go!

Sind die Vorbereitungen gemacht, kann es losgehen. Mit „-f“ läuft die Abgabe der Metriken so schnell wie möglich (fast as possible). Ich würde empfehlen zumindest noch mit „-r“ (runtime) die Laufzeit einzuschränken, andernfalls würde es endlos laufen. Durch Eingabe von „–host“ definiert man den Remotehost (Standard: „http://localhost:8086“).

# /usr/local/bin/influx-stress insert -f -r 1m --user stress --passs ****** --db stress

Eine beispielhafte Serie (für Icinga) könnte so aussehen: (Standard: „ctr,some=tag n=0i“)

# /usr/local/bin/influx-stress insert -r 1m ping4,hostname=agent.example.com,service=ping4,metric=rta crit=0.200000,min=0,unit="seconds",value=0.200000,warn=0.100000 --user stress --passs ****** --db stress

Nach erfolgtem Lauf bekommt man sowohl den Durchsatz (Throughput) als auch die geschriebenen Punkte (Points Written) angezeigt. Außerdem werden die Standardeinstellungen für die nicht definierten Parameter ausgegeben, die sich natürlich aber auch noch abändern lassen.

Using batch size of 10000 line(s)
Spreading writes across 100000 series
Output is unthrottled
Using 20 concurrent writer(s)
Running until ~18446744073709551615 points sent or until ~1m0s has elapsed
Write Throughput: 212335
Points Written: 13100000

Wer mehr zum Thema InfluxDB erfahren möchte, dem kann ich neben unseren üblichen Dienstleistungen auch unser InfluxDB & Grafana Training wärmstens ans Herz legen.

Markus Waldmüller
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.

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
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

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
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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
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.