Hybride Umgebungen sind in Mode, weil immer mehr Kunden die Flexibilität der Hyperscaler zwar schätzen, die Kontrolle über ihre unternehmenskritischen Daten aber letztlich nicht vollständig in die Hände des jeweiligen Anbieters legen wollen. Gerne kommen Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP) stattdessen als Puffer zum Einsatz, wenn zusätzliche Kapazität kurzfristig benötigt wird. Durchaus etabliert hat sich auch der Ansatz, bestimmte Aufgaben und Tasks in die Cloud zu verschieben, andere aber nicht. Verschiedene Faktoren spielen hier eine Rolle, etwa auch die potenziell anfallenden Kosten – und immer mehr Firmen sind längst dazu übergegangen, den für sich optimalen Mix aus finanziellem Aufwand, technischer Komplexität und tatsächlichem Nutzen zwischen den Welten zu suchen.

Das schafft im Alltag der Systembetreuung durchaus Probleme, die es vorher so nicht gab. Ein zentrales, wiederkehrendes Thema ist dabei das Monitoring hybrider Workloads. Es ist deutlich komplexer, eine Umgebung vollständig zu überwachen, wenn diese auf mehrere Standorte verteilt ist. Hier spielen plötzlich Begriffe wie "Ende-zu-Ende-Überwachung" eine Rolle, und längst übersteigen die Anforderungen an das Monitoring hybrider Umgebungen die Fähigkeiten der klassischen Monitoringsysteme erheblich. Wer etwa wissen möchte, wie viele Ressourcen in der Cloud gerade zu buchen sind, muss erstmal wissen, was im eigenen Setup los ist. Da hilft es nicht, wenn das eigene Monitoring lediglich feststellen kann, ob lokal ein Prozess noch läuft oder nicht. Stattdessen kommt das Trending ins Spiel, das auf Basis historischer und aktueller Nutzungsdaten errechnet, wann die Installation das nächste Mal in die Breite skaliert werden muss.

Und das Gespann aus Monitoring, Alerting und Trending (MAT) reicht trotzdem nicht aus: Verteilte Setups bedingen zentralisiertes Logging mitsamt einer zentralisierten Auswertung. Gerade in Clouds spielt zudem der Faktor Tracing eine Rolle, der sich im Kontext hybrider Umgebungen nochmals deutlich komplexer gestaltet als bei ausschließlich lokalen Umgebungen. Und schließlich gehen viele Systemverwalter heute so weit und betrachten auch Intrusion Detection sowie Endpoint Security als Faktoren, die beim Monitoring in der Cloud und mithin beim Überwachen hybrider Landschaften eine Rolle spielen sollten. Längst ist deshalb nicht mehr von Monitoring die Rede. Stattdessen geht es heute meist um Observability, einen viel breiter definierten Begriff.

Wie lässt sich Observability für hybride Umgebungen nun aber sinnvoll umsetzen? Eine Google-Suche etwa befördert die Hochglanzprospekte etlicher Hersteller zutage. Die allermeisten dieser Boxed-Produkte eint vor allem ein Preisschild, das sich gewaschen hat. Doch in diese Falle muss der Administrator gar nicht tappen. Hybride Setups lassen sich nämlich auch mit bekannten Bordmitteln der Open-Source-Welt durchaus sinnvoll überwachen. Wir führen anhand von Prometheus, Grafana, Loki und des Open-Telemetry-Networks exemplarisch anhand mehrerer Beispiele vor, wie Sie ein System zum Überwachen hybrider Workloads auch ohne teure Appliances sinnvoll ausgestalten. Dabei spielt vor allem das Thema Netzwerk eine bedeutende Rolle. Um ein einheitliches Monitoring zu ermöglichen, muss in jeder denkbaren Konstellation eine Netzwerkverbindung zwischen dem lokalen und dem entfernten System bestehen.

Zunächst ist es sinnvoll, den Begriff des "hybriden Monitorings" genauer zu betrachten. Zweifelsohne haben beispielsweise die Hyperscaler durchaus etliche Werkzeuge im Programm, um Workloads auf der eigenen Plattform effizient zu überwachen. Die sind aber eben auf die jeweilige Plattform beschränkt. Hinter den Kulissen greifen sie zum Teil verdeckt auf Datenquellen zu, die nur in der jeweiligen Umgebung, also Azure, AWS oder GCP, überhaupt zur Verfügung stehen. Für die Überwachung von Programmen im lokalen RZ eines Anbieters sind sie ungeeignet.

Dort stehen gleichzeitig andere Monitoringwerkzeuge zur Verfügung, zum Teil optimiert für bestimmte Programme, die wiederum zumindest ab Werk für die Überwachung von Workloads in öffentlichen Cloudinstallation eher ungeeignet sind. Ein valider Ansatz bestünde darin, die jeweiligen Werkzeuge der genutzten Umgebung einzusetzen, um eben dort jeweils das bestmögliche Monitoring zu implementieren. Dieser Ansatz hat allerdings zwei zentrale Nachteile.

Der erste besteht darin, dass kein "Single Point of Administration" vorhanden ist. Sämtliche Observability-Infrastruktur muss zweimal existieren, was auch Dienste wie das Alerting umfasst. Im Alltag hat das ganz praktische Effekte: Die Planung der Bereitschaft etwa muss an zwei unterschiedlichen Stellen gepflegt werden, die Technik für die Alarmierung von Bereitschaftlern muss zweimal unabhängig voneinander existieren und funktionieren.

Der fast noch gewichtigere, zweite Nachteil dieses Ansatzes ist aber, dass sich Ereignisse im öffentlichen oder im privaten Teil des Setups nicht sinnvoll korrelieren lassen, weil keine logische Verbindung zwischen den Monitoring-Systemen besteht. Implizit ist es ja auch unmöglich, solche Ereignisse sinnvoll zu erfassen, die den öffentlichen wie den privaten Teil der Landschaft umfassen. Der Knackpunkt beim Bau einer hybriden Observability besteht also darin, sämtliche Datenquellen abzuschöpfen, den gesamten Datensatz zu konsolidieren, daraus Trigger für verschiedene Ereignisse zu bauen und schließlich sämtliche Informationen unter einer einheitlichen Oberfläche verfügbar zu machen. Auf Monitoringdienste bei den Hyperscalern, die ohnehin existieren, darf ein Stack für hybride Observability dabei durchaus zugreifen, wenn es technisch sinnvoll ist. Die Kunst besteht im weiteren Verlauf darin, die passende Software zu finden und zu nutzen.

Damit am Ende nicht doch wieder teure Appliances her müssen, orientieren Sie sich im Idealfall an den Best Practices der Community. Dort stoßen Sie schnell auf alte Bekannte: Prometheus im Gespann mit Grafana hat sich in den vergangenen Jahren zu so etwas wie dem Industriestandard für den MAT-Teil des Observability-Komplexes entwickelt (Bild 1). Zur Erinnerung: Prometheus selbst ist eine Zeitreihendatenbank und mithin für skalierbare Setups in ebensolchen Umgebungen hervorragend geeignet.

Mittels eines Kniffs generiert der Alert Manager, eine Komponente aus dem Prometheus-Universum, aus den ursprünglichen Trendingdaten Alarme – indem er etwa den Metrikwert zur Anzahl laufender Prozesse eines bestimmten Dienstes als einzelnen Punkt eines sehr kurzen Zeitstrahls betrachtet und auf Basis des Ereignisses des Tests dann einen Alarm auslöst. Grafana schließlich kommt zum Einsatz, um die gesammelten Daten zu visualisieren und wird auch im Rahmen dieses Artikels noch eine bedeutende Rolle spielen.

Ein zentraler Aspekt beim Bau hybrider Observability-Konzepte ist die Frage, wo die für das Monitoring selbst benötigte Infrastruktur stehen sollte. Gerade wenn etwas schief läuft, muss diese ja funktionieren. Vielerorts hat sich deshalb der Ansatz etabliert, Monitoring für hybride Umgebungen in einer komplett autarken Zelle des eigenen Netzwerks zu betreiben. Diese sollte zusätzlich so redundant wie möglich angebunden sein, sodass der Ausfall einzelner Infrastrukturkomponenten nicht zum Ausfall der Überwachung führt. Obendrein sollte auch das Monitoringsystem selbst redundant arbeiten. Weil die meisten Komponenten wie Prometheus mittlerweile in Container-Form vorliegen, hat es sich vielerorts als beste Herangehensweise herausgestellt, eine kleine, autarke Plattform auf Kubernetes-Basis für das Monitoring bereitzustellen. Diese kann sich um Themen wie Redundanz eigenständig und automatisch kümmern.

Damit das Konzept funktioniert, muss das Monitoringsystem aber freilich Netzwerkpfade zu allen Teilen der Umgebung besitzen, die es überwachen soll. Die Hyperscaler bieten hier verschiedene Möglichkeiten: Entsprechende Dienste lassen sich zum einen direkt in Richtung Internet exponieren, doch das ist vielerorts verständlicherweise unerwünscht. Stattdessen bieten die Hyperscaler wie auch die meisten privaten Cloudumgebungen Netzwerkfunktionen an, die es ermöglichen, externe Clients in die gegebenen Netze zu integrieren. Das stellen Sie sich am besten wie eine Art VPN vor, denn genau darum handelt es sich. Wer mittels dafür vorgesehener Funktion in AWS die Daten in AWS mit einem zweiten Setupteil verbindet, schafft im Grunde auch nichts anderes als eine VPN-Verbindung. Falls die genutzte Plattform im privaten Teil des Setups entsprechende Features gar nicht anbietet, kann alternativ eine "echte" VPN-Verbindung zum Einsatz kommen. Hier eignen sich etwa die Site-to-Site-Features von IPsec gut. Der Systemverwalter startet in solchen Umgebungen dann meist eine eigene virtuelle Instanz, die die VPN-Verbindung aufbaut und auf diese Weise den IP-Adressraum des einen Netzes für das andere Netz erreichbar macht. Hier ist schlimmstenfalls aber etwas Bastelei nötig, weil Sicherheitsfunktionen wie Security Groups entsprechend zu konfigurieren sind.

Wer keinen dritten Standort zur Verfügung hat, wirft aber nicht gleich die Flinte ins Korn. Der Umstand macht das Monitoringkonzept allerdings etwas komplexer. Denn dann ist es zunächst notwendig, die beiden Standorte – also die öffentliche Cloud und die private Umgebung – ebenfalls mit einer Quasi-VPN-Verbindung zu verbinden. Die Monitoringdienste laufen anschließend idealerweise an beiden Lokationen, aber aufeinander abgestimmt im Cluster-Modus. Prometheus etwa lässt sich problemlos zweimal ausrollen; beide Instanzen sollten im Anschluss aber so konfiguriert sein, dass sie sämtliche Monitoringziele an beiden Standorten abfragen. Komplementär lässt sich hier durch den Einsatz von Thanos [1] zudem erreichen, dass Grafana-Instanzen an beiden Orten über einen einzelnen Zugangspunkt an die Metrikdaten beider Prometheus-Instanzen herankommen. Das ist nötig, um beim Ausfall einer Seite eine verbleibende, funktionale Monitoringinstanz zu haben. Auch der Alert Manager von Prometheus beherrscht schließlich Deduplikation mittels eines Cluster-Modus. Bei regulärer Verfügbarkeit beider Sites empfangen Systemverwalter also nicht jede Nachricht über jedes Problem mehrmals.

Ist die eigentliche Infrastruktur für das Monitoring ausgerollt, steht die Frage im Raum, was genau zu überwachen ist. Klassische Strategien helfen hier weiter: Zunächst tut der Administrator gut daran, für seine Infrastrukturdienste ganz klassische Verfügbarkeits- und Funktions-checks zu installieren. Die Website "Awesome Prometheus Alerts" [2] leistet hier hilfreiche Vorarbeit. Im Netz finden sich zudem fertige Prometheus-Alarme für etliche Zusatzdienste. Zur Erinnerung: Prometheus folgt bei der Überwachung dem Pull-Prinzip.

Die laufenden Prometheus-Instanzen holen sich Metrikdaten also entweder von den Zielprogrammen direkt, falls diese über entsprechende Schnittstellen verfügen. Das wäre beispielsweise bei Ceph der Fall. Alternativ gibt es Werkzeuge, die Metrikdaten für einzelne Programme einsammeln und zum Abruf bereitstellen, die sogenannten "Exporter". Ab Werk bringt Prometheus den "Node Exporter" mit, der sich für die Überwachung grundlegender Vitalwerte jedes virtuellen Systems hervorragend eignet.

Für Azure, GCP sowie AWS finden sich zudem Exporter, die die APIs des jeweiligen Diensts abfragen und dort Metrikdaten einsammeln, um sie anschließend im Prometheus-Format zur Verfügung zu stellen. Hier kommt ein großer Stoß Performancedaten mit, wie sie in den jeweiligen nativen Monitoringwerkzeugen der Clouds enthalten sind. Mittels des CloudWatch-Exporters für AWS [3] lassen sich beispielsweise sämtliche Metrikdaten aus CloudWatch in Prometheus recyclen (Bild 2). Diese Daten sind auch deshalb so wertvoll, weil sie einen Blick hinter die Kulissen einzelner Teile der Hyperscaler-Umgebungen ermöglichen, also Daten bereitstellen, die Prometheus im entfernten Teil des Setups technisch gar nicht erheben kann. Es ist also empfehlenswert, die Monitoringdienste der Plattformen von Anfang an in das hybride Monitoring zu integrieren.

Besonders hervorgehoben seien schließlich außerdem die Exporter, die Metrikdaten überwachen, wie sie nur in hybriden Umgebungen üblicherweise anfallen. Die Quasi-VPN-Verbindungen zwischen den Standorten etwa sind selbst auch ein Monitoring-Target. Welcher Exporter zur Anwendung kommt, hängt dabei von der Art und Weise ab, wie die Verbindung implementiert ist. Zudem bietet es sich gerade in Setups mit komplexer Netzwerkstruktur an, das Netz auch besonders penibel zu überwachen. Mikroarchitekturanwendungen etwa setzen oft auf Mesh-Komponenten wie Istio (Bild 3), um die Kommunikation zwischen ihren einzelnen Diensten zu überwachen. Istio bietet selbst eine Prometheus-Schnittstelle an, die Sie unbedingt in Ihr Monitoring integrieren sollten. Die umfangreichen Netzwerkverbindungen solcher Anwendungen sind schließlich schon in rein lokalen Installationen eine Herausforderung in Sachen Monitoring. In verteilten Setups mit "Netzwerkbrücke" sind sie ein weiterer Faktor erhöhter Komplexität.

Wer ein hybrides Monitoringkonzept wie beschrieben plant, sollte unbedingt Gebrauch von den Vorzügen der Orchestrierung so wie der Automation machen. Wenn beide Seiten der Plattform beispielsweise eine Orchestrierung ermöglichen, ergibt es unbedingt Sinn, diese auch flächendeckend zu nutzen. Das Aufsetzen von Prometheus etwa geht leichter von der Hand, wenn links und rechts Kubernetes-Installationen vorhanden sind. Denn dann lässt sich derselbe Container mit passender Konfiguration lokal wie auch in der Cloud nutzen. Ähnliches gilt für die anderen beschriebenen Dienste. Positiv fällt nebenher noch an, dass Automation und Orchestrierung die Gefahr eventueller Fehlkonfigurationen und administrativer Fehler ganz erheblich reduzieren. Wie eingangs bereits erwähnt, geht es bei Observability aber eben nicht nur um Monitoring. Zumindest die Faktoren zentralisiertes Logging und Tracing sind ebenfalls relevant.

Die gute Nachricht ist: Wer für den Monitoringteil seiner Umgebung die notwendigen Tools und Verbindungen bereits geschaffen hat, kann diese für zentralisiertes Logging und auch für Tracing im Regelfall wiederverwenden. Auch hier stellt sich zunächst aber natürlich die Frage nach sinnvollen Werkzeugen.

In den Markt des zentralisierten Loggings ist dabei in den vergangenen Jahren Bewegung gekommen. Splunkt gilt bis heute als Platzhirsch, seine Einführung scheitert nach wie vor vielerorts aber an den horrenden Preisen, die das Unternehmen für seine Produkte – volumenbasiert – aufruft. Als valide Alternative galt Administratoren lange ELK, also das Gespann aus ElasticSearch, LogStash und Kibana. Mittlerweile steht ElasticSearch nicht mehr unter einer freien Lizenz. Die letzte freie Version der Software haben Entwickler vor Jahren jedoch als OpenSearch abgespalten und gepflegt, so dass sich zentralisiertes Logging heute auch durch diese Kombination erreichen lässt. Allerdings hat die Sache einen Haken: ElasticSearch und dadurch auch OpenSearch sind extrem komplexe Werkzeuge mit hohem Wartungs- und Betriebsaufwand.

Soll ein solches Gespann in Landschaften mit hybriden Komponenten zum Einsatz kommen, legt alleine dieser Umstand noch eine weitere Schippe in Sachen Komplexität drauf. Im Gegensatz zu Prometheus und Thanos mit Grafana gestaltet sich die Konfiguration eines – oder eigentlich eher zweier – OpenSearch-Cluster bereits als sehr komplex. Sollen die dann auch noch in sinnvoller Weise Daten austauschen, um standortübergreifende Redundanz zu ermöglichen, sieht der Admin sich flugs einem Mammutprojekt gegenüber.

Heimlich, still und leise hat sich deshalb in den vergangenen Jahren eine dritte Kombination aus Diensten am Markt etabliert und verbreitet: Loki und Promtail. Loki stammt von denselben Entwicklern, die auch für Grafana verantwortlich zeichnen. Es ist eine Art Prometheus für Logdateien. Anders als OpenSearch nimmt Loki keine umfassende Indizierung sämtlicher empfangenen Inhalte vor, sodass es aus deutlich weniger Diensten besteht und weniger eigene Datenhaltung betreibt. Promtail ist der Dienst, der von den Überwachungszielen die zu nutzenden Logging-Daten einsammelt. Der Vorteil: Loki folgt der Architektur von Prometheus in vielerlei Hinsicht. Das beschriebene Betriebskonzept für Prometheus lässt sich mit Abstrichen insofern auch auf Loki umsetzen. Lediglich ein Dienst wie Thanos, der über mehrere Prometheus-Instanzen eine logische Abfrageschicht legt, ist für Loki nicht verfügbar.

Schließlich darf das Thema Tracing nicht unter den Tisch fallen. Denn dieses spielt gerade in verteilten Setups mit Mikroarchitekturkomponenten eine Rolle. Und eben diese wiederum begegnen dem Systemverwalter in hybriden Setups bevorzugt, weil sie diese Art des Betriebs bestmöglich abbilden können. Worum geht es beim Tracing überhaupt? Ist eine Anwendung im Stile einer Mikroarchitektur-Anwendung verfasst, kommunizieren ihre vielen einzelnen Teile über festgelegte Schnittstellen wie gRPC.

Das erschwert das Debugging deutlich stärker als in monolithischen Anwendungen, denn der Admin kann nicht einfach beobachten, was innerhalb einer Anwendung geschieht. Stattdessen muss er den Weg aller Datenpakete von einem auslösenden Ereignis (etwa eine eingehende E-Mail) bis zum letzten Schritt des Verarbeitungsvorgangs nachvollziehen. Dabei wandern Daten zwischen den Teilen der Mikroarchitekturanwendung hin und her, verändern sich, lösen andere Ereignisse aus. Tracing hilft, eben diese Transformationen von Daten sichtbar zu machen. Als Königslösung in Sachen Tracing gilt aktuell Open Telemetry.

Anders als bei Monitoring, Alerting und Trending sowie der Log Aggregation fällt dem Admin beim Thema Tracing aber nicht die Verantwortung zu, spezifische Dienste anzubieten. Denn damit Tracing funktioniert, müssen die Entwickler einer App ihre App einerseits gegen die entsprechenden Bibliotheken verlinken, etwa gegen jene des Open-Telemetry-Projektes. Darüber hinaus benötigen sie im Anschluss Werkzeuge, die die Traces sichtbar machen und so zu analysieren erlauben. Hier sei der Administrator zumindest so freundlich und stelle auf Klick abrufbare Debugging-Umgebungen für Tracing zur Verfügung, beispielsweise mit vorinstallierter Software. Der zentrale Betrieb einer Jaeger-Instanz [4] (Bild 4) bietet sich hier besonders an. Der hybride Faktor spielt hier letztlich nur eine untergeordnete Rolle, denn die Traces nutzen die hybriden Netzwerkverbindungen ja "einfach so", falls diese vorhanden sind.

Standardkomponenten im Gespann mit etwas Netzwerktechnik ermöglichen den Betrieb einer Observability-Umgebung, die erprobt und extrem vielseitig zugleich ist. Auch hier bewährt sich Open-Source-Software als gute und günstige Alternative zu fertigen Produkten am Markt.