NETWAYS Blog

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

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.

Read more from Markus and meet the Team