pixel
Seite wählen

NETWAYS Blog

So repliziert man Daten mit InfluxDB

Mit InfluxDB 2.0 hat influxdata einen großen Schritt gewagt und viele Neuerungen eingeführt. Hierzu gehören unter anderem die Integration von Webinterface und Task-Engine und DBMS, aber auch die neue Abfragesprache Flux. Ein paar Funktionen, die in es in InfluxDB 1.x gab, wurden zunächst jedoch noch nicht Umgesetzt. Hierzu gehörte bis jetzt das Thema Replikation.
Von Replikation spricht man, wenn Daten von einem Server automatisiert auf einen oder mehrere weitere Server kopiert werden um beispielsweise die Datensicherheit zu erhöhen oder den Zugriff zu beschleunigen.

Seit influxDB 2.2 ist Replikation als technical preview in der Open Source Version enthalten und kann schnell und einfach über das influx command line interface eingerichtet werden. Bei diesem Verfahren werden die Daten TLS gesichert an die API eines oder mehrerer InfluxDB Server gesendet. Wird die Verbindung zwischen Quell- und Zielserver unterbrochen, werden die Daten zu einem späteren Zeitpunkt übertragen.

Einrichtung

Vorab werden hierfür ein Quell-Bucket und ein Authentifizierungstoken auf Server1, und ein Ziel-Bucket plus Authentifizierungstoken auf Server2 benötigt. Bei der Gelegenheit sollte man sich auch schon einmal die Organisations-IDs und Bucket-IDs notieren

# Server 1
user@server1$ influx org ls
user@server1$ influx bucket create -n example-local-bucket
user@server1$ influx auth create ...
# Server 2
user@server2$ influx org ls
user@server2$ influx bucket create -n example-remote-bucket
user@server2$ influx auth create ...

Nach dieser Vorarbeit muss zunächst Remote-Verbindung zu Server 2 angeben werden. Diese wird dann mit im folgenden Schritt genutzt um die Replikation zu aktivieren. In einer nicht gesicherten Testumgebung können zudem die Schalter -allow-insecure-tls und –skip-verify hilfreich sein.

user@server1$ influx remote create \
--name myremote \
--org-id <org ID> \
--token <token> \
--remote-url <remote URL> \
--remote-api-token <remote token> \
--remote-org-id <remote org ID> \

user@server1$ influx replication create \
--name myreplication
--local-bucket example-local-bucket
--remote-bucket example-remote-bucket
--remote-id 0ooxX0xxXo0x

Das ganze ist auch noch weitergehend konfigurierbar, es kann z.B. die Länge des Replay-Logs oder das maximale Alter von zu replizierenden Daten geändert werden.

Weitergehende Informationen finden sich in der Influxdb-Doku:

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

InfluxDB Time Series Database

In diesem Beitrag geht es um Zeitreihen-Daten (time series data) und InfluxDB (time series databases).

 

Time Series Data

Was sind eigentlich die time series data? Es gibt Programme oder Tools, die eine große Menge an Rohdaten sammeln. Diese Daten haben ein wichtiges Merkmal: Wenn die Daten produziert werden, haben diese einen Zeitstempel. Jene Daten spiegeln die Veränderungen wider, die im Laufe der Zeit passiert ist. Daher können wir diese Werte als zeitabhängigen Vektor betrachten.

Die Daten haben manchmal die Eigenschaft der Kontinuität, beispielsweise können die Temperatur einer Umgebung oder die check-Ergebnisse von einem Überwachungssystem wie Icinga über die Zeit kontinuierlich gespeichert werden.

Diese Daten haben drei wichtige Merkmale:

  • Die Daten erreichen uns nahezu zeitgleich mit der Erfassung.
  • Die Daten kommen normalerweise geordnet bei uns an.
  • Die Registrierungszeit ist einer der wichtigsten Eigenschafen.

Mit anderen Worten: Die einzige Operation besteht darin, neue Daten zu den vorherigen Daten hinzuzufügen.

 

Time Series Database

Zeitreihendatenbanken (time series database) sind Datenbanken, die speziell zum Speichern und Untersuchen von Zeitreihendaten entwickelt wurden. Diese Daten werden im Allgemeinen in Wert-Zeit Paaren gespeichert. Zeitreihendatenbanken sind für die Arbeit mit Wert-Zeit Paaren optimiert – sie verwenden beispielsweise Komprimierungsalgorithmen, um Daten effizienter zu verwalten.

Einige dieser Datenbanken ermöglichen es auch, Änderungen in Daten zu prüfen und diese in Diagramme umzuwandeln. Zu den wichtigsten Zeitreihendatenbanken gehören:

  • Riak
  • kdb+
  • IMB Informix
  • InfluxDB
  • Prometheus
  • eXtremeDB
  • IBM Informix on Cloud
  • Azure Time Series Insights
  • TimescaleDB
  • Druid
  • OpenTSDB
  • Gtaphite

InfluxDB

InfluxDB ist eine Open Source Zeitreihendatenbank, die vom InfluxData-Team entwickelt wurde. InfluxDB wurde mit der Go-Sprache entwickelt und ist einfach zum Installieren und Bedienen. Die Menge der Daten, die man sammeln kann, ist unbegrenzt, und es spielt keine Rolle, wie oder in welchem ​​Format die Daten an InfluxDB übermittelt werden. Es gibt außerdem die Möglichkeit, anhand der Daten im InfluxDB-Webinterface Graphen darzustellen – diese können z.B. in Überwachungssystemen wie Icinga nützlich sein.
InfluxDB ist stärker gewachsen, als andere Zeitreihendatenbanken. Und dadurch, dass es ein Open Source Programm ist, ist der Quellcode einfach zu verwenden!

 

InfluxDB Funktionen

Es gibt einige Faktoren, die InfluxDB von anderen Datenbanken unterscheidet.
Gute Leistung ist eines der Hauptmerkmale von InfluxDB. Diese ermöglicht es, die Daten mit guter Geschwindigkeit und guter Qualität zu verwenden, selbst bei hoher Datenlast. Zu diesem Zweck verwendet InfluxDB Komprimierung zum Verwalten von Daten und kann 1 Million Daten pro Sekunde sammeln und verwalten.

Wenn Du mit der SQL-Syntax vertraut bist, wirst Du  auch mit der InfluxDB-Abfrage vertraut sein. InfluxDB verwendet eine eigene Syntax namens InfluxQL. Angenommen, Du sammelst Daten aus dem Speicher eines Computers, und möchtest diese Daten anzeigen. Dann musst Du nur eine SQL-Abfrage schreiben – diese nimmt die Daten der letzten 3 Monate und gruppiert sie in 10-Tage-Pakete.

Beim Umgang mit großen Datenmengen wird es schwierig sein, sie zu speichern und zu pflegen, und mit der Zeit werden diese Daten immer komplexer. InfluxDB kann diese Daten in kleineren Größen und genauer über lange Zeiträume speichern.
Mithilfe der Datenspeicherungsrichtlinien, auf die Du in InfluxDB Zugriff hast, kannst Du Deine Einstellungen so anpassen, dass Deine Daten bis zu 30 Tage lang genau verfügbar sind. Danach kannst Du sie bis zu 6 Monate oder länger speichern oder für immer aufbewahren. Mit dieser Funktion kannst Du Daten speichern und gleichzeitig Festplattenspeicher sparen.

Saeid Hassan-Abadi
Saeid Hassan-Abadi
Junior Consultant

Saeid hat im September 2019 seine Ausbildung zum Fachinformatiker im Bereich Systemintegration gestartet. Der gebürtige Perser hat in seinem Heimatland Iran Wirtschaftsindustrie-Ingenieurwesen studiert. Er arbeitet leidenschaftlich gerne am Computer und eignet sich gerne neues Wissen an. Seine Hobbys sind Musik hören, Sport treiben und mit seinen Freunden Zeit verbringen.

Grafana queries InfluxDB

Christoph hat euch ja bereits in einem früheren Blogpost vor ca. einem Jahr näher gebracht wie man Icinga 2 und InfluxDB 2 miteinander “zum Reden” bringt. Seit Icinga 2.13 steht nun auch der Influxdb2Writer zur Verfügung, welchen Afeef in seinem Blogpost benützt.

Ich möchte euch heute darauf basierend zeigen wie man nun das Setup erweitert und Grafana mit InfluxDB 2 konnektiert. Da InfluxDB 2 zum aktuellen Zeitpunkt sowohl die neue Flux Open Source Query Language (Flux) als auch noch die ältere Influx Query Language (InfluxQL) unterstützt, gibt es dafür grundsätzlich zwei verschiedene Möglichkeiten.

Zuerst stellen wir jedoch sicher das bereits ein Bucket für Icinga existiert und kopieren die ID für später:

$ influx bucket list
b860eefe6e38c504 icinga infinite 168h0m0s 6533ea60dddd2193 implicit

InfluxQL

Fangen wir mit der etwas aufwändigeren Methode an. Diese ist nötig wenn man InfluxDB 2 mittels InfluxQL abfragen möchte und geht nur auf CLI-Ebene. Dafür erstellen wir eine v1-Authentifizierung namens “grafana” mit lesendem Zugriff auf das Icinga-Bucket:

$ influx v1 auth create --username grafana --password ****** --read-bucket b860eefe6e38c504
$ influx v1 auth list

Genau dieser “username” und das zugehörige “password” wird dann bei Grafana in der jeweiligen Data Source mit der Query Language “InfluxQL” als “User” bzw. “Password” eingetragen. Zusätzlich geben wir bei “Database” den Namen des Buckets, in unserem Fall “icinga”, an.

Flux

Für Flux gestaltet sich das Ganze etwas einfacher, da hier die native Authentifizierung verwendet werden kann:

$ influx auth create --description grafana --read-bucket b860eefe6e38c504
$ influx auth list

Bei der Data Source mit der Query Language “Flux” ist dann in Grafana der soeben erstellte lange und kryptische “Token” einzutragen. Außerdem wird das Bucket, beispielhaft “icinga”, und die Organisation benötigt. Diese wird beim initialen Setup von InfluxDB generiert und lässt sich wie folgt herausfinden:

$ influx org list

Wem das jetzt etwas zu Trocken war, dem kann ich gerne unsere Schulung zum Thema InfluxDB & Grafana nahe legen. Dort wird das im Kontext nochmal anschaulicher erklärt und auch Rückfragen sind natürlich gestattet.

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.

It’s just an Influx Task – Scrapers

Ein Scraper in Influx ist eine einfache Möglichkeit Performancedaten von einer Prometheus Datenquelle abzurufen. Das Prometheus Datenformat besteht aus verschiedenen Typen von Metriken, die in Plain-Text über http von einem Agenten oder einer Software angeboten werden. Der Scraper ist ein Task, der regelmäßig ausgeführt wird, alle angebotenen Daten abruft und in einen InfluxDB bucket schreibt.

Influx UI

Scraper stehen ab InfluxDB 2.0 zur Verfügung und können einfach über die UI für eine beliebige URL aktiviert werden. Hierbei wird auch immer ein “Default” vorgeschlagen. Dieser zeigt auf die InfluxDB selber, da auch die InfluxDB ihre eigenen Performancedaten in diesem Format anbietet.

Influx CLI

Das Influx command-line interface bietet keine Option an, um einen Scraper zu aktivieren. Aber ein Scraper ist eigentlich auch nur ein Task.
Tasks werden in influxDB in der Sprache Flux geschrieben. Also kann man den Scraper auch einfach selber schreiben.

Hierzu brauchen wir 2 Funktionen:

  • prometheus.scrape
    • Mit prometheus.scrape werden die Daten von einer gegebenen URL abgerufen.
  • to
    • Mit der “to” Funktion werden Daten in einen Bucket geschrieben.

Zusammengefasst sieht das dann folgendermaßen aus:

import "experimental/prometheus"

prometheus.scrape(url: "https://prometheus.endpoint.example/metrics")
|> to(
org: "example-org",
bucket: "example-bucket"
)

 

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Icinga 2 mit InfluxDB 2

Die Überwachung von Infrastruktur und Software ist eine grundlegende Sache in der IT. Beim Monitoring spielt aber nicht nur der Status und die Benachrichtigung der zu überwachenden Objekte eine wesentliche Rolle, sondern auch die Aufbewahrung und die nachträgliche Betrachtung von Performancedaten. Diese lassen sich bei Icinga 2 anhand von Check Plugins ermitteln und mit unterschiedlichen Writern bzw. Features u.a. an InfluxDB weiterleiten.

Nach der Installation von Icinga 2 und influxDB 2 können wir einen Bucket erstellen in dem wir später die Icinga 2 Metriken aufbewahren können.

# influx bucket create -n icinga
ID                  Name      Retention   Shard group duration     Organization ID 
b07cac747d7d6dd7    icinga    infinite    168h0m0s                 74cacb1ac05bfe71

Icinga 2 benötigt einen Token um in diesen Bucket schreiben zu können. Den Token für die Schreibberechtigung können wir wie folgt generieren.

# influx auth create --write-bucket b07cac747d7d6dd7

Damit Icinga 2 mit dem Export der Metriken anfängt, muss das folgende Object konfiguriert werden.

# cat /etc/icinga2/features-available/influxdb2.conf
object Influxdb2Writer "influxdb2" {
  host = "127.0.0.1"
  port = 8086
  organization = "icinga"
  bucket = "icinga"
  auth_token = "TKfmBkRdJ2HfjcVk35nwr0eX0TiYCbEcBe8xDh-_dIafGFpGalTe5HlCAKt6ZlPlJsyw4uH8Mfk4Mt7uI-xqyQ=="
  flush_threshold = 1024
  flush_interval = 10s

Ab diesem Zeitpunkt können wir die Daten im InfluxDB UI auf https://x.x.x.x:8086 ansehen. Die dortigen Dashboards kann man z. B. durch Grafana oder InfluxDB zusammenstellen bzw. anzeigen lassen. Um mehr über InfluxDB 2 und Grafana zu erfahren, könnt Ihr die InfluxDB Schulung buchen & besuchen.

Afeef Ghannam
Afeef Ghannam
Systems Engineer

Afeef hat seine Ausbildung Als Fachinformatiker in Richtung Systemintegration im Juli 2020 bei NETWAYS absolviert, seitdem unterstützt er die Kolleg:innen im Operations Team der NETWAYS Professional Services bei der Betriebsunterstützung. Nach der Arbeit macht er gerne Sport, trifft Freunde oder mag es Filme zu schauen.