Seite wählen

NETWAYS Blog

Icinga Monitoring-Satelliten – wieso sie für dich sinnvoll sind

This entry is part 4 of 5 in the series Icinga. Einfach. Erklärt.

Eine zuverlässige und robuste IT-Infrastruktur, die den Anforderungen von Unternehmen gerecht wird, ist von entscheidender Bedeutung. Da Unternehmen wachsen und immer komplexer werden, wird es immer schwieriger, die IT-Infrastruktur effektiv zu überwachen und zu verwalten. An dieser Stelle kommen Monitoringlösungen wie Icinga ins Spiel.

Icinga ist eine Open-Source-Monitoringlösung, mit der man die Verfügbarkeit und Leistung der IT-Infrastruktur, einschließlich Servern, Anwendungen und Netzwerkgeräten überwachen kann. Mit Icinga kannst du deine Infrastruktur proaktiv überwachen und Probleme erkennen, bevor sie zu Problemen werden.

Obwohl Icinga ein leistungsstarkes Monitoringtool ist, ist die zu Grunde liegende Hardware nicht unfehlbar. Wenn es um eine große und komplexe Infrastruktur geht, kann sinnvoll sein, sich nicht auf einen einzigen Server zu verlassen. Hier kommt der Einsatz mehrerer Icinga-Satelliten ins Spiel. Diese können jeweils zu zweit in einer „Zone“ zusammengefasst werden, wobei beide Knoten die gleiche Rolle einnehmen und sich die zu erledigenden Aufgaben aufteilen.

Also, was sind die Vorteile, mehrere Icinga-Satelliten einzusetzen?

Hohe Verfügbarkeit der Monitoringumgebung

Einer der wichtigsten Vorteile für die Nutzung mehrerer Icinga-Satelliten ist die hohe Verfügbarkeit. Durch den Einsatz mehrerer Satelliten in verschiedenen Rechenzentren oder geografischen Standorten wird sichergestellt, dass die Monitoringinfrastruktur hochverfügbar ist. Wenn ein Satellit ausfällt, kann zunächst mal der zweite Knoten alle Aufgaben übernehmen.
Sollte die Verbindung zu einem Standort weg sein, werden lokale Messergebnisse zwischengespeichert. Sobald sie wieder da ist, werden sie wieder abgespielt. In der Zwischenzeit können die anderen Standorte ihre Infrastruktur weiter überwachen und bei Problemen Warnungen senden.

Diese hohe Verfügbarkeit trägt dazu bei, Ausfallzeiten zu minimieren und sicherzustellen, dass geschäftskritische Systeme verfügbar bleiben und wie vorgesehen funktionieren. Durch die Bereitstellung von Redundanz können mehrere Satelliten dazu beitragen, das Risiko eines einzelnen Ausfallpunkts zu verringern, was helfen kann, kostspielige Ausfallzeiten zu vermeiden.

Besseres Load-Balancing

Ein weiterer Vorteil des Einsatzes mehrerer Icinga-Satelliten ist Load-Balancing. Durch die Verteilung der Überwachungslast auf mehrere Satelliten kannst du sicherstellen, dass kein einzelner Monitoringknoten mit Monitoringaufgaben überlastet wird.
Durch den Lastausgleich kannst du deine Monitoringinfrastruktur auch für verschiedene Anwendungsfälle optimieren. So kannst du beispielsweise einen Satelliten für das Monitoring von Webservern und einen anderen für das Monitoring von Datenbankservern einsetzen.

Skalierbarkeit deiner Icinga-Umgebung

Wenn das Unternehmen wächst, wird die IT-Infrastruktur wahrscheinlich immer komplexer. Das Hinzufügen weiterer Server, Anwendungen und Netzwerkgeräte zur Infrastruktur kann einen einzelnen Überwachungsknoten schnell überfordern. Indem mehrere Icinga-Satelliten genutzt werden, kann die Monitoringinfrastruktur skalieren, um die erhöhte Last zu bewältigen.

Skalierbarkeit ist für Unternehmen, die schnell wachsen oder unvorhersehbare Arbeitslasten haben, von entscheidender Bedeutung. Die Möglichkeit, bei Bedarf weitere Satelliten hinzufügen zu können, stellt sicher, dass deine Monitoringinfrastruktur mit den Anforderungen des Business Schritt halten kann.

In einer finalen Ausbaustufe muss der zentrale Icinga-Knoten gar keine Monitoringaufgaben mehr übernehmen. Er kann dann konzentriert Performancedaten schreiben, die Datenbank befüllen, Config entgegennehmen und verarbeiten oder Benachrichtigungen verschicken.

Geografische Vielfalt

Durch die Platzierung von Icinga-Satelliten an verschiedenen geografischen Standorten kannst du die Verfügbarkeit und Leistung deiner IT-Infrastruktur aus verschiedenen Perspektiven überwachen. Auf diese Weise kannst du Probleme erkennen, die möglicherweise nur in bestimmten Regionen auftreten, z. B. Netzwerküberlastung oder Latenzprobleme.

Geografische Vielfalt kann auch für Unternehmen nützlich sein, die Kunden oder Betriebe in verschiedenen Teilen der Welt haben. Indem du die Infrastruktur von verschiedenen Standorten aus überwachst, kannst du sicherstellen, dass alle Dienste für Kunden unabhängig vom Standort verfügbar sind und gut funktionieren.

Hierarchie und Verschachtelung

Besonders bei großen Standorten und hoch-gesicherten Netzen bietet es sich an, Satelliten in verschiedenen Netz-Segmenten zu installieren. Beispielsweise im Produktionsnetz, im Management-Netz oder in einer DMZ.
Hierdurch lässt sich der Netzwerkverkehr zwischen den Netzwerkzonen verringern und die Firewallfreischaltungen auf das Nötigste reduzieren. Besonders praktisch ist es dabei, dass man sich aussuchen kann, ob der Satellit einen Listener-Port öffnet und auf Anfragen wartet oder sich aktiv zu seinem Upstream-Server verbindet.

Durch hierarchische Organisation der Satelliten lässt sich sicherstellen, welche Informationen wo verfügbar sind, jeder Satellit lässt sich hierbei mit einem eigenen Web-Interface und eigenen Benachrichtigungen ausstatten.
Dadurch kann jeder Standort auch im Fall eines totalen WAN-Ausfalls lokal seine Monitoring-Informationen sehen. Er sieht jedoch nicht die Informationen der anderen Standorte. An der obersten Icinga-Instanz im HQ sind alle Informationen verfügbar, da die Satelliten ihre Nachrichten hoch melden.

Mehr Infos und Hilfe

Wenn du Hilfe beim Aufbau einer komplexen Umgebung brauchst oder deinen externen Icinga-Satelliten bei NETWAYS in der Cloud betreiben möchtest, komm gerne auf uns zu und vereinbare ein Gespräch. Du kannst Icinga, egal ob als Master oder als Satellit, ganz unverbindlich einen Monat bei NETWAYS Web Services testen.

Falls Du stattdessen eine Review deiner bestehenden Icinga-Satelliten durchführen lassen willst oder bei der Einrichtung von Icinga-Satelliten Hilfe suchst, melde Dich gerne! Ich oder ein:e Kolleg:in führen gerne eine individuelle Betrachtung zu Deiner IT-Umgebung und ihren Anforderungen durch. Im Rahmen eines solchen Consultingtermins erstellen wir Dir zunächst ein Konzept und können gerne auch direkt mit der Umsetzung beginnen.

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.

Kickstart your Laptop with Linux

Alle paar Jahre bekomme ich einen neuen Laptop bei Netways. Vor zwei Wochen war es wieder so weit und somit eine gute Gelegenheit mal wieder die Betriebssystem-Frage zu stellen. Die alte Frage also: „Welches Linux ist das Beste?“. Also für mich ganz persönlich. Nicht für die weite Welt. Zur Auswahl stehen die rpm Fraktion wie centos, fedora oder rhel; debianoide wie ubuntu, mint, debian und arch Derivate wie Manjaro oder Endeavour.

Entscheidungsmatrix

  • Suse ist raus, fedora ist mir zu unstable, centos/rhel zu altbacken.
  • ubuntu ist mir zu kommerziell, debian zu rock-stable, mint vereinigt irgendwas dazwischen
  • Manjaro finde ich ganz gut, Endeavour ist ein reines Arch mit beigelegtem installer.

Ergebnis

Ich nehme nichts von alledem, sondern Arch-Linux ohne Verpackung, aus folgenden Gründen.

Ein sehr neuer Laptop hat manchmal aktuelle Chipsätze oder ähnliches, die einen aktuellen Kernel oder andere Tools erfordern. Bei Arch Linux bekommt man immer aktuelle Software und muss nicht auf einen neuen Major-Release der Distro warten, da es sich um einen Rolling-Release handelt.
Für die Installation des OS brauche Endeavour oder Manjaro mehr. Das reine Arch Linux bringt mittlerweile einen terminal basierten Installer mit. Bis vor ein paar Jahren musste man die im Arch-Wiki beschriebene Schritt für Schritt Installation durchführen. Jetzt hat sich das mit archinstall aber sehr vereinfacht. Hier hat man nach circa 5 Minuten ein lauffähiges System. In meinem Fall: Eine LUKS verschlüsselte Basis Partition, darauf ein Gnome mit Wayland. Eine Besonderheit ist mir dabei aufgefallen. Per Default wird nicht mehr grub sondern systemd-boot genutzt. Ein letzter Fallstrick: Man sollte bei „Netzwerk“ angeben, dass der NetworkManager die Verbindungen verwaltet, sonst hat man nach dem Neustart der Installation kein Netzwerk mehr. Damit dann nicht zu langweilig wird ist dann natürlich kein NetworkManager installiert und ohne Internet ist das auhch nicht möglich. Da ifconfig(depricated) auch nicht installiert ist landet man dann schnell an dem Punkt, wo man mit dem *ip* command weiterhelfen muss.
Generell ist das Arch-Wiki eine gute Anlaufstation für Hilfe. Obwohl Arch eine viel kleinere Nutzerbasis hat als Ubnutu oder fedora, ist das Wiki mittlerweile so ausführlich, dass ich darin auch Lösungen für Probleme finde die ich mit anderen Distros habe.
Updates: funktionieren einfach. Ich benutze seit circa sieben Jahren Arch Linux und konnte in der Zeit immer problemlos updaten. Ab und zu muss man mal den keyring aktualisieren wenn die Updates lange ignoriert wurden aber die Updates – an und für sich – funktionieren einfach.
Bei Ubuntu oder Fedora kann man das Glück haben das ein Softwarehersteller direkt Pakete baut und anbietet. Bei Arch nicht. Bei Arch gibt es allerdings das Arch User Repository (AUR). Hier werden an zentraler Stelle Pakete von einer großen Community gepflegt. Ein AUR Paket besteht dabei im Prinzip aus einem Pacman-Install-Skript(PKGBUILD), dass entweder vorkompilierte binaries von *irgendwo* laden oder auch mit Quelltext Binaries on-demand kompilieren kann. Allerdings muss man sich bewusst sein, dass die PKGBUILD zwar im AUR von der Community geprüft werden *können*, aber nicht in jedem Fall sicher sind. Ich finde aber das PKGBUILD-Format ist sehr einfach lesbar und man kann genau nachlesen was genau von wo heruntergeladen und wie installiert wird. Wenn man z.B. spotify aus dem AUR installiert kann man nachlesen, dass das debian Paket hierfür genutzt wird und von repository.spotify.com geladen wird. Außerdem kann man hier sehen, wie gpg genutzt wird um den Inhalt zu verifizieren.

[...]
source=('spotify.protocol'
'LICENSE'
"${pkgname}-${pkgver}-x86_64.deb::http://repository.spotify.com/pool/non-free/s/spotify-client/spotify-client_${pkgver}.${_commit}_amd64.deb"
[...]

Um mit AUR Paketen einfach installieren zu können favorisiere ich YAY, dass als pacman replacement fungiert. Eine Installation von eben genanntem Spotify würde man z.B. mit *yay spotify* anstoßen. Und bevor ich es vergesse: die schicken Icons aus dem Screenshot kommen aus dem buuf icon-set und können auch mit yay installiert werden.

To the moon

Für mich ist Arch aktuell das optimale Betriebssystem und wenn alle Anderen ihren Fehler endlich eingesehen haben könnte 2023 das Jahr des Linux-Desktops werden.

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.

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.

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.

Neues von den Influxdays EMEA 2021

Auf den influxdays kündigt Paul Dix, CTO von InfluxData, einen neuen Core names iOx für influxDB an. Dieser Schritt löst spontan Unsicherheit aus. Hier ein paar Fakten um die Gemüter zu beruhigen:

InfluxDB 2.x Open Source wird, so wie es jetzt existiert, parallel mit regelmäßigen Point-Releases weiterentwickelt.
InfluxDB IOx wird SQL, InfluxQL und Flux unterstützen.
InfluxDB IOx wird in einem zukünftigen Release ein optionales Speicher-Backend für InfluxDB werden.
Die Implementierung durch Rust und Apache Arrow soll eine höhere Sicherheit erreichen. Auf Grund verschiedener Optimierungen am Speicherverhalten soll die Datenmenge verringert und gleichzeitig die Abfragegeschwindigkeit erhöht werden.
InfluxDB Enterprise-Kunden werden in der zweiten Hälfte des Jahres 2021 über eine kommerziell unterstützte Version von InfluxDB IOx und InfluxDB Enterprise verfügen.

Das war nicht das einzige Thema auf der online abgehaltenen Konferenz.
In dem ausgewogenen Programm konnte man sich anschauen, wie man mittels Telegraf Daten in Richtung influxDB schreibt. In einem anderen Vortrag ging es um Dashboards, Alerts und Tasks.

Ein Highlight war für mich der Talk von Aengus Rooney, der zwar trotz des Titels „What’s New with Grafana and InfluxDB“ erstaunlich wenig Neuerungen gezeigt hat, jedoch mit einem längeren Hands-On die Möglichkeiten von Grafana anhand eines selbst erstellten Handels Terminals für Kraken/Bitcoin demonstriert hat.

Alle Aufzeichnungen der Konferenz werden ab 31. Mai veröffentlicht. Man findet sie, wie auch die Videos vergangener Konferenzen, auf den Seiten der influxdays und auf youtube.

Wer mehr über influx und die Möglichkeiten erfahren möchte kann sich auch bei NETWAYS im Rahmen eines zweitägigen Trainings informieren.

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.