Select Page

NETWAYS Blog

Icinga for Windows Preview: Visualisiert eure Metriken!

Icinga hat in seinem Blogpost mitgeteilt, dass es mit Icinga for Windows v1.10.0 einige Änderungen an den Performance Metriken geben wird. Hier wollen wir einmal grob zusammenfassen, worum es geht und welche Auswirkungen diese Änderungen haben. Für alle Details ist der Original-Post aber sehr zu empfehlen!

Das Label-Problem

Ein grundlegendes Problem in aktuellen Icinga for Windows Versionen ist die Tatsache, dass die Labels für Performance Metriken zwar automatisch vom Icinga PowerShell Framework generiert werden, jedoch eine Filterung auf diese Werte innerhalb von Grafana nicht so einfach möglich ist. Nimmt man sich einmal das Partition-Space Plugin zur Hand, sehen die Metriken wie folgt aus:

‘free_space_partition_c’=10328260000B;;;0;491811100000

‘used_space_partition_c’=481483000000B;;;0;491811100000

Das Label ändert sich dabei, je nachdem ob das Plugin den Free- oder Used-Space der Partitionen überwacht. An sich wäre das nicht schlimm, da Grafana ja das Filtern über mehrere Metriken hinweg erlaubt. Jedoch ergeben sich Probleme bei komplexen Plugins oder wenn verschiedene Plugins eine ähnliche Struktur der Performance Metriken liefern – dann ist nicht mehr abzugrenzen, woher eine Metrik kommt.

Check_Multi Label

Um diesem Problem entgegenzuwirken, gibt es mit Icinga for Windows v1.10.0 im August einen Breaking Change: Alle Performance Metriken werden künftig im check_multi Format geschrieben. Dadurch ergeben sich eine Vielzahl von Vorteilen, da im Vorfeld schon während der Label Generierung ein Index, ein Template sowie ein Metrik Name definiert werden kann. Im Beispiel der oberen Performance Werte, sieht das Ergebnis dann wie folgt aus:

‘c::ifw_partitionspace::used’=480627800000B;;;0;491811100000

‘c::ifw_partitionspace::free’=11178000000B;;;0;491811100000

In diesem Beispiel wäre der Index unsere Partition c, das Template für die Visualisierung ifw_partitionspace und der Name der Metrik used oder free. Sowohl der Index als auch der Metrik Name müssen innerhalb der Plugins mittels der Funktion New-IcingaCheck gesetzt werden. Hierfür gibt es dann neue Argument, -MetricIndex und -MetricName. Das Template, in unserem Beispiel ifw_partitionspace, wird dabei automatisch je nach Name des Check-Plugins gesetzt.

Natürlich ergibt sich hierdurch ein kleiner Mehraufwand für Entwickler während des Bauens der Plugins, jedoch sind die Daten in der Regel sowieso vorhanden und werden in bisherige Labels eingearbeitet, weshalb dieser überschaubar ist.

Metriken Visualisieren

Da es sich hierbei um einen Breaking Change handelt und deshalb vorhandene Grafana Dashboards nicht mehr funktionieren, gibt es eine gute Nachricht: Icinga liefert ab Tag 1 der Icinga for Windows v1.10.0 für alle Plugins Grafana Dashboards aus!

Aufgrund technischer Gründe ist ein Parallelbetrieb von alten und neuen Performance Metriken nicht möglich, daher wurde dies zum Anlass genommen, standardisierte und von Icinga gepflegte Dashboards bereitzustellen. Hierfür wird lediglich InfluxDB 2 sowie Grafana benötigt. Wer bereits eigene Dashboards erstellt hat, kann sich die vorgefertigten Dashboards als Basis hernehmen und seine Ansichten anpassen, während neue User sich direkt aus dem Portfolio bedienen können.

Icinga Web 2 CPU Metriken

Icinga Web 2 Disk Metriken

Grafana Basis-Dashboard für Icinga for Windows

 

Wir freuen uns bereits sehr auf den Release von Icinga for Windows v1.10.0 im August und helfen gerne beim Update, der Implementierung oder Erweiterung. Hierzu könnt Ihr gerne mit uns Kontakt aufnehmen!

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".

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
Systems Engineer

Saeid hat im Juli 2022 seine Ausbildung als Fachinformatiker für Systemintegration bei uns abgeschloßen, und arbeitet nun in Operation-Team. 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
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.

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.