Seite wählen

NETWAYS Blog

Herausforderungen beim Prometheus Scaling

Prometheus ist eine ausgezeichnete Monitoring-Lösung, wenn es um die Überwachung von Verfügbarkeit und Performance geht. Das initiale Deployment geht schnell und mit ein bisschen PromQL KnowHow hat man die Dashboards und Alarme schnell am Laufen. Schon steht die Prometheus Monitoring Lösung. Aber wie skaliert das Ganze?

In größeren oder wachsenden Umgebungen ergeben sich einige Herausforderungen, die es zu überwinden gilt. Im ersten Teil dieses Artikels sollen diese zunächst problematisiert werden. Der zweite Teil stellt dann im Prometheus Ökosystem etablierte Werkzeuge vor, die diese Herausforderungen lösen können.

 

Zentrale Oberfläche für mehrere Prometheus Instanzen

Eine häufige Anforderung ist, eine zentrale Anlaufstelle für mehrere Prometheus Instanzen abzubilden. Soll heißen, dass über die Zeit mehr und mehr Instanzen in Betrieb genommen werden und keine zentralen Abfragen möglich sind. Gründe dafür können sein, dass mehrere unabhängige Systeme jeweils eine oder mehrere Prometheus Instanzen bekommen (beispielsweise Kubernetes Cluster). Außerdem könnten verschiedene Teams oder Netzwerkzonen eigenständige Instanzen benötigen. Häufig zeigt sich: ein Prometheus kommt selten allein.

Fun Fact: der Plural von „Prometheus“ ist „Prometheis“. Im Deutschen wird aber auch gerne „die Prometheus“ als Plural genutzt. Vermutlich auch, weil der dentale Frikative „th“ des Englischen im Deutschen aber als Plosiv zur Geltung kommt und /pʁoˈmeːtaɪ̯s/ komisch klingt.

Auch wenn dank Federation und Remote Write verschiedene zentrale, dezentrale oder hochverfügbare Prometheus Architekturen möglich sind, haben diese oft hohen operativen Aufwand. In zentralen Architekturen könnten zudem einzelne Instanzen, die sich „danebenbenehmen“, das Gesamtkonstrukt stören. Damit sind beispielsweise Daten mit hoher Kardinalität gemeint, oder Instanzen, die hohe Last erzeugen. Es kann also durchaus sinnvoll sein, eigenständige Prometheus Instanzen zu betreiben.

Dadurch hat man aber nun keine zentrale API, um die Daten abzufragen. Heißt, eine Lösung, die eine globale Sicht auf mehrere Instanzen bereitstellt, muss her.

 

Prometheus Mandantenfähigkeit

Da sich, wie eben beschrieben, schnell mehrere Instanzen in der Infrastruktur tummeln, die an einer zentralen Stelle zusammenlaufen sollen, sollte diese Stelle idealerweise Mandantentrennung unterstützen. Heißt beispielsweise, Team A und B möchten sich beim Schreiben und Lesen von Daten nicht über die Füße laufen, aber dennoch die zentrale Infrastruktur nutzen. Daten sollen im besten Fall getrennt voneinander gespeichert werden und Abfragen isoliert voneinander sein.

Mandantenfähigkeit soll also dafür sorgen, dass wir zentrale Infrastruktur gemeinsam nutzen können. Wenn sich diese dann noch in bestehenden Authentifizierungslösung integrieren lässt, wäre das natürlich optimal.

 

Langzeitspeicherung von Daten

Die Anforderungen, für wie lange Metriken aufbewahrt werden müssen, unterscheiden sich je nach Anwendungsfall sehr stark. Dabei sind verschiedenste Faktoren ausschlaggebend.

Für produktive Systeme oder Testumgebungen möchte man vielleicht verschiedene Aufbewahrungsfristen. Daneben ist natürlich die Größe der jeweiligen Umgebung zu beachten, eine handvoll Nodes erzeugen wesentlich weniger Daten, als hunderte. Selbstverständlich spielen auch hier Netzwerkzonen oder Teams eine Rolle. Oder auch ganz einfach der Kostenfaktor, Speicher ist zwar günstig, aber nicht umsonst.

Man möchte also womöglich Daten von Prometheus Instanzen nur für 30 Tage lokal aufbewahren, um das tagtägliche Monitoring zu bewerkstelligen, aber gleichzeitig 6 oder 12 Monate historische Daten, um längerfristige oder wiederkehrende Trends zu erkennen.

Im Folgenden werden einige etablierte Lösungen für die eben beschriebenen Herausforderungen beim Prometheus Scaling beschreiben.

 

Thanos

Thanos (https://thanos.io/) besteht aus einer handvoll Komponenten, die zusätzlich zu Prometheus Instanzen laufen, um so ein skalierbares und hochverfügbares Gesamtkonstrukt zu bauen. Jede Komponente hat hier eine sehr spezifische Aufgabe und versucht diese so gut wie möglich zu lösen (KISS-Prinzip).

Anmerkung des Autors: auch wenn sich einzelne Komponenten eines Systems nach dem „Keep It Simple“ Prinzip ausrichten, heißt das nicht, dass das daraus resultierende Konstrukt nicht durchaus komplex sein kann.

Dieses modulare Design von Thanos hat einige Vorteile. Nicht alle Komponenten müssen zum Einsatz kommen, viele davon sind „stateless“ (speichern also keinen Zustand) und sie skalieren unabhängig voreinander.

Als ein Kernstück von Thanos könnte man das „Store Gateway“ sehen. Diese Komponente spricht mit einem Objektspeicher (beispielsweise S3), um historische Daten zu speichern und stellt eine gRPC API bereit, über welche die Daten angefragt werden können.

Bestehende Prometheus Instanzen können unverändert weiterlaufen und werden jeweils mit der Thanos Sidecar Komponente ausgestattet. Diese schiebt die Prometheus Zeitserienblöcke regelmäßig in den Objektspeicher. Gleichzeitig können mehrere Sidecars über die „Query Frontend“ Komponente gebündelt werden, damit wird eine zentrale API erzeugt, die alle Prometheus Instanzen so wie die historischen Daten abfragen kann.

Eine optionale Downsampling Komponente kann die historischen Daten im Objektspeicher in regelmäßigen Intervallen komprimieren. Außerdem kann eine „Receiver“ Komponente genutzt werden, um Metriken direkt aus Prometheus mittels Remote Write abzuliefern, so vermeidet man die Sidecar Komponente.

Mit Thanos lässt sich problemlos eine zentrale Oberfläche für mehrere Prometheus Instanzen erstellen und auch Langzeitspeicherung von Daten ist machbar. Die Mandantenfähigkeit ist jedoch (Stand August 2023) noch nicht ganz ausgereift. Zwar kennen einige Komponenten das Konzept von Mandanten, die Implementierung ist aber noch nicht sehr einheitlich (ist aber in Arbeit). Dazu muss man fairerweise auch sagen, dass Thanos eine Apache-2.0-lizenzierte freie Software ist, hinter der keine Firma steht, sondern die CNCF.

 

Cortex

Cortex (https://cortexmetrics.io/) basiert in Teilen auf Thanos/Prometheus Code und hat ähnliche Features wie Thanos. Ein wesentlicher Unterschied ist, dass Prometheus Instanzen die Daten immer mittels Remote Write selbst einliefern. Es gibt also keine Sidecar Komponente, aber die Prometheus Konfiguration muss angepasst werden. Diese Anpassung ist jedoch trivial.

Interessant am Cortex Design ist auch, dass es sich um eine einzelne Binärdatei handelt, die alle Komponenten beinhalten. Heißt, Cortex kann im einfachsten Fall als ein Prozess laufen. Ändern sich die Anforderungen, kann man entweder mehrere Instanzen starten, die auf den gleichen Objektspeicher zugreifen, oder einzelne Komponenten skalieren. Sind die Daten einmal im Objektspeicher ist die Architektur sehr ähnlich zu Thanos.

Es gibt aber auch entscheidende Unterschiede. Beispielsweise ist das Downsampling von historischen Daten noch auf der Roadmap (Stand August 2023). Ein vorteilhafter Unterschied ist aber, dass die Mandantenfähigkeit in allen Komponenten verfügbar ist.

Cortex unterstützt Mandantenfähigkeit mittels einem HTTP-Header (X-Scope-OrgID), welcher den jeweiligen Tenant beinhaltet. Jeder Tenant hat dann eine eigene Zeitseriendatenbank im Cortex Objektspeicher und auch jede Abfrage muss diesen HTTP-Header mit der Tenant-ID schicken. Cortex vertraut diesem HTTP-Header, heißt, externe Tools (beispielsweise ein Reverse Proxy) müssen für die Authentifizierung sorgen. HTTP Authentifizierung ist immerhin ein gut verstandenes Problem mit vielen Lösungen.

 

Grafana Mimir

Grafana Mimir (https://grafana.com/oss/mimir/) basiert auf dem Cortex Code. Grafana Labs – ein Haupt-Contributor bei Cortex – hat hier zusätzliche Features zum Produkt „Mimir“ entwickelt. Die Architektur ist großteils identisch und Mimir wurde bewusst in der Version 2.0 veröffentlicht, um den Fork und dessen Features zu differenzieren. Außerdem wurde, basierend auf der Grafana Mimir Code-Base, das Produkt „Grafana Enterprise Metrics (GEM)“ entwickelt, was nochmals weitere Features für den Enterprise-Bereich enthält.

In den Versionen nach dem Fork wurde der Fokus auf Performance-Optimierung und Mandantenfähigkeit gelegt. Erwähnenswert ist allerdings auch, dass Grafana Mimir unter der AGPL-3.0 Lizenz veröffentlicht wurde.

 

Fazit

Monitoring mit Prometheus bringt einige Herausforderungen mit sich. Nicht nur, dass man PromQL verstehen und schreiben lernen muss, bei wachsender Infrastruktur hat man operative Hürden zu bewältigen. Meine persönliche Empfehlung ist aktuell Cortex oder Mimir. Zum einen ist die elegante Deployment Option mit einer (Golang) Binärdatei ein Faktor, und zum anderen die durchgängige Mandantenfähigkeit mittels HTTP-Header. Trotzdem muss man auch sagen, dass die Authentifizierung mit HTTP eigene Herausforderungen mitbringt. Technologisch könnte man das Ganze als gelöstes Problem sehen, Authentifizierung/Autorisierung/Verschlüsselung mit HTTP sind gut verstandene Probleme. Aus einer organisatorischen Perspektive ist das Thema aber immer noch trickreich, da viele Komponenten integriert und betreut werden müssen.

Alles in allem ist Prometheus Monitoring ein spannender Bereich, in dem es noch viele spannende Probleme zu lösen gibt.

Markus Opolka
Markus Opolka
Senior Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

check_prometheus ist jetzt öffentlich verfügbar!

Monitoring ist komplex, das wissen wir hier bei NETWAYS leider zu gut. Deswegen laufen in der Infrastruktur auch mal gerne mehrere Tools für die Überwachung. Zwei gern gesehene Kandidaten sind dabei Icinga und Prometheus. Icinga und Prometheus erfüllen unterschiedliche Rollen im Monitoring, daher besteht oft Bedarf für eine Integration beider Tools. Genau dafür haben wir check_prometheus geschrieben, was wir nun der Öffentlichkeit zur Verfügung stellen.

https://github.com/NETWAYS/check_prometheus

Mit check_prometheus lassen sich der Status deiner Prometheus Server ermitteln, Alarme aus Prometheus auslesen und sogar PromQL aus Icinga auswerten. Das Check Plugin haben wir in Golang geschrieben, das heißt, es werden keine weiteren Abhängigkeiten auf der Icinga Instanz benötigt. Hier einige Beispiele für die Nutzung:

Wir können grundlegend zunächst mal prüfen, ob unser Prometheus Server erreichbar und operativ ist. Dafür nutzen wir den health Unterbefehl:

$ check_prometheus health

[OK] - Prometheus Server is Healthy. | statuscode=200

Natürlich können wir hier Adresse oder TLS Konfiguration als Parameter angeben.

Mit dem alert Unterbefehl, lässt sich außerdem der Status von in Prometheus definierten Alarmen überprüfen. Entweder eines oder mehrerer spezifischen Alarme:

$ check_prometheus alert --name "MyVeryImportantAlert"

[CRITICAL] - 1 Alerts: 1 Firing - 0 Pending - 0 Inactive
\_[CRITICAL] [MyVeryImportantAlert] - Job: [example] is firing - value: 1.00
| firing=1 pending=0 inactive=0

Oder auch einfach alle bereits in Prometheus definierten Alarme und deren Status:

$ check_prometheus alert

[CRITICAL] - 6 Alerts: 3 Firing - 0 Pending - 3 Inactive
\_[OK] [PrometheusTargetMissing] is inactive
\_[CRITICAL] [PrometheusAlertmanagerJobMissing] - Job: [alertmanager] is firing - value: 1.00
\_[OK] [HostOutOfMemory] - Job: [alertmanager]
\_[OK] [HostHighCpuLoad] - Job: [alertmanager]
\_[CRITICAL] [HighResultLatency] - Job: [prometheus] on Instance: [node01] is firing - value: 11.00
| total=6 firing=3 pending=0 inactive=3

Wenn wir keine Alarme in Prometheus definieren wollen, können wir mit dem query Unterbefehl auch direkt PromQL auswerten lassen und gegen Schwellwerte prüfen:

$ check_prometheus query -q my_very_important_metric{job="prometheus"}[10s]' -c5 -w 10

[WARNING] - 1 Metrics: 1 Critical - 0 Warning - 0 Ok
\_[WARNING] my_very_important_metric{instance="node01", job="prometheus"} - value: 15
| my_very_important_metric_node01_prometheus=15

Persönlich empfehle ich jedoch, Alarme in Prometheus zu definieren da wir hier weitere Möglichkeiten haben, den jeweiligen Alarm zu definieren (beispielsweise das for Schlagwort in der Alarm Definition).

Jetzt da wir unsere Prometheus Instanzen mit Icinga integriert haben, können wir uns ansehen, wie wir den Prometheus Alertmanager aus Icinga ansprechen können. Die Integration mit dem Prometheus Alertmanager ist glücklicherweise kein großes Problem. Durch die Prometheus Alertmanager HTTP API, können wir relativ leicht benutzerdefinierte Alarme mittels JSON erzeugen. Alles was wir brauchen ist ein Notification Plugin, das uns die Statusmeldung in Icinga nach JSON transformiert und diese an den Alertmanager schickt.

Da jede Benachrichtigungsstrategie anders aussieht, können wir hier keine universelle Lösung implementieren. Das heißt aber nicht, dass wir nicht Beispiele zur Verfügung stellen können. Im Repository findet ihr ein kleines Python Skript, dass sich ohne Abhängigkeiten auf jeder Icinga Instanz einsetzen lässt:

notify-alertmanager-example.py --hostname mynode01 --service ping --state 2

Hast du einen Bug gefunden, oder brauchst ein neues Feature? Melde dich einfach auf GitHub!

Markus Opolka
Markus Opolka
Senior Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.

Prometheus jetzt verfügbar

Vielleicht dürfte dem einen oder anderen regelmässigen Besucher schon aufgefallen sein,
dass Prometheus in unser Produktportfolio aufgenommen wurde. Als Ergänzung zu den anderen Monitoringanwendungen
(Icinga2, ElasticStack, Graylog) bietet es eine gute Ergänzung für bestimmte Anwendungsszenarien die sonst
noch nicht oder nicht ideal abgedeckt werden konnten.

Die Installation ist zwar bei Prometheus prinzipiell sehr einfach (das statisch gelinkte Binary an den richtigen Ort kopieren und ausführen), aber das ist typischerweise nicht die beliebteste Art und Weise Software zu installieren,
schliesslich müssen dann Updates immer wieder mit dem gleichen Prozedere ausgebracht werden. Das wäre ja an sich nicht weiter schwierig zu automatisieren, aber wofür das Rad neu erfinden, das ist schliesslich die Aufgabe eines Paketmanagers.

Aus diesem Grund sind jetzt in den Netways Repositories Pakete für RHEL- und Debianartige Linux-Distributionen verfügbar. Für Debian(artige) gibt es Prometheus zwar schon paketiert aus den offizielen Quellen, aber aus Gründen der Konsequenz haben wir diese in der gleichen Version wie die RHEL-Pakete nochmals gebaut.

Das Prometheus entspricht eins zu eins dem Build der von Prometheus auch auf Github verfügbar ist.

Wir wünschen fröhliche Installation und wer noch Bugs/Probleme find, darf sie beh möchte uns darauf aufmerksam machen 🙂

Lorenz Kästle
Lorenz Kästle
Systems Engineer

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Prometheus Webinare in 2023

Letzte Woche haben wir im Rahmen unserer Webinare auf YouTube einen groben Überblick über die Lösung Prometheus gegeben – das Video kann man sich hier ansehen, sofern man den Termin verpasst hat.

Um neben unserer Beratungsdienstleistung das Thema Prometheus weiter auszubauen, haben wir beschlossen Anfang 2023 eine Webinar-Reihe für die Lösung durchzuführen. Dasselbe haben wir bereits für Icinga und Elastic durchgeführt und für Graylog eingeplant. Ziel der Prometheus Webinar-Serie ist es, nicht nur den Aufbau selbst zu begleiten, sondern verschiedene Integrationen aufzuzeigen und die Möglichkeit, eigene Exporter zu bauen.

Webinar Themen

Zum jetzigen Stand haben wir uns folgende Themen überlegt:

  • Installation von Prometheus Komponenten mit NETWAYS Paketen
  • Anbindung externer Systeme mittels Exporter
  • Konfiguration von Alarmierungen
  • Schreiben eigener Prometheus Exporter
  • Integration von Prometheus und Icinga

Zeitplanung

Die Webinare werden im Laufe von Q1 und Q2 2023 stattfinden. Die genaue zeitliche Gestaltung wird in den nächsten Wochen erfolgen und direkt auf unserem YouTube-Kanal einsehbar sein. Am besten für eine schnelle Übersicht den Kanal abonnieren und sich bei neuen Videos und Ereignissen benachrichtigen lassen!

Sofern noch Themenwünsche offen sind oder wir generell etwas bei den Webinaren berücksichtigen sollen, am besten direkt Kontakt mit uns aufnehmen. Alternativ stehen wir natürlich beratend bei der Konzeptionierung, dem Aufbau und der Integration zur Seite und bieten eine Prometheus Schulung an – wir freuen uns über Anfragen!

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

Durchstarten mit Prometheus

Prometheus ist eine freie Monitoringsoftware, die komplett in Go geschrieben wurde. Prometheus zeichnet Metriken in einer Zeitreihendatenbank auf, die von Anwendungen per HTTP abgefragt werden, nutzt Grafana für die Visualisierung der Messwerte und ermöglicht Warnmeldungen in Echtzeit mit dem Alarmmanager.

Prometheus und Grafana gelten als de-facto Standard-Monitoringsystem für Kubernetes und eignen sich hervorragend zur Überwachung für alle Kubernetes On-Premise oder Cloud-Umgebungen, wie z.B. bei uns in den NETWAYS Web Services.

Aber natürlich kann Prometheus noch viel mehr und damit euch der Einstieg so einfach wie möglich fällt, haben wir passende Starterpakete im Angebot:

Prometheus Starterpaket Standard (2 Tage)

  • Installation von Prometheus
  • Installation verschiedener Exporter
  • Einführung in PromQL
  • Beispielhafte Überwachung von Linux Servern
  • Beispielhafte Überwachung von Windows Servern
  • Beispielhafte Überwachung einer Datenbank (MySQL, PostgreSQL)
  • Beispielhafte Überwachung einer Webseite
  • Beispielhafte Überwachung von Netzwerkkomponenten per SNMP
  • Installation des Alertmanagers
  • Einrichtung von E-Mail Benachrichtigungen

Prometheus Starterpaket Plus (4 Tage)

Alle Leistungen aus dem Starterpaket Standard plus:

  • Installation des Pushgateway
  • Konfiguration von Hochverfügbarkeit
  • Konfiguration von Remote Endpoints und Storage
  • Integration mit Grafana

Prometheus Erweiterungspakete

  • Konfiguration von sicherheitsrelevanten Themen
  • Entwicklung eines eigenen Exporters
  • Deep Dive in PromQL
  • Einblick in die Prometheus Best Practices

Alle Punkte und Themen können auch frei gewählt werden und wir erstellen gerne jederzeit ein individuelles Angebot. Meldet euch einfach bei uns!

Webinar: Wir stellen Prometheus vor

Und um es euch noch einfacher zu machen, stellen wir am 28.9.2022 um 10:30h Prometheus in einem Webinar vor. Meine Kollegen geben einen ersten Einblick in den Funktionsumfang von Prometheus und beantworten gerne eure Frage. Wir werden in den nächsten Monaten noch viel zu Prometheus zu erzählen haben, daher am besten gleich am unseren Youtube Channel abonnieren.

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.