Moderne Systeme sehen ganz anders aus als noch vor Jahren. Im Großen und Ganzen haben sich Entwickler vom Aufbau klassischer Monolithen wegbewegt hin zur Entwicklung von containerisierten Anwendungen, die über eine hochgradig verteilte Infrastruktur laufen.
Auch wenn dieser Wandel die Systeme von Natur aus widerstandsfähiger gemacht hat, ist es durch die Zunahme der Gesamtkomplexität wichtiger geworden, Probleme effektiv zu identifizieren und an der Wurzel zu packen, wenn sie auftreten.
Ein Teil der Lösung für diese Herausforderung liegt in der Nutzung von Tools und Plattformen, die den Zustand von Diensten und Infrastruktur effektiv überwachen können. Zu diesem Zweck werden in diesem Beitrag Best Practices für die Prometheus-Überwachung von Diensten und Infrastrukturen erläutert. Darüber hinaus werden die Gründe dargelegt, warum Prometheus allein nicht ausreicht, um die komplexen, hochgradig verteilten Systemumgebungen zu überwachen, die heute im Einsatz sind.
Was ist Prometheus?
Prometheus ist ein Open-Source-Monitoring- und Alarmierungs-Toolkit, das erstmals 2012 von SoundCloud für die Überwachung von Cloud-nativen Metriken entwickelt wurde.
Im Bereich Monitoring und Observability haben wir drei primäre Datentypen: Logs, Metriken und Traces. Metriken dienen als Daten-Stoppuhr, die Ihnen hilft, Service Level Objectives (SLOs) und Service Level Indicators (SLIs) in einer Zeitreihe zu verfolgen.
Metriken mit hoher Kardinalität haben viele eindeutige Kombinationen von Bezeichnungen (z. B. user_id, region), was die Speicher- und Abfrageleistung von Prometheus belasten kann. Viele Kunden benötigen jedoch mehr von ihren Observability-Umgebungen, und heutzutage haben die meisten Leute OpenTelemetry, um Collectors zu vereinheitlichen und Daten aus allen drei Datenquellen zu sammeln.
Was kann mit Prometheus überwacht werden?
Unternehmen verwenden Prometheus Monitoring, um Metrikdaten zur Service- und Infrastrukturleistung zu sammeln. Je nach Anwendungsfall können die Prometheus-Metriken Leistungskennzahlen wie CPU-Auslastung, Speichernutzung, Gesamtzahl der Anfragen, Anfragen pro Sekunde, Anzahl der Anfragen, Anzahl der Ausnahmen und mehr enthalten. Wenn sie effektiv genutzt werden, können diese gesammelten Metrikdaten Unternehmen dabei helfen, Systemprobleme rechtzeitig zu erkennen.
Prometheus-Server-Architektur
Im Mittelpunkt der Prometheus-Architektur steht der Prometheus-Server, der die eigentlichen Überwachungsfunktionen ausführt. Der Prometheus-Server besteht aus drei Hauptkomponenten: einer Zeitreihen-Datenbank, einem Worker für den Datenabruf und einem HTTP-Server.
Zeitreihen-Datenbank
Diese Komponente ist für die Speicherung von Metrikdaten zuständig. Diese Daten werden als Zeitreihe gespeichert. Das bedeutet, dass die Daten in der Datenbank als eine Reihe von Datenpunkten mit Zeitstempeln dargestellt werden, die zur gleichen Metrik und zum gleichen Satz von gelabelten Dimensionen gehören.
Worker für Datenabruf
Diese Komponente tut genau das, was ihr Name andeutet: Sie zieht Metriken von „Zielen“ ab, bei denen es sich um Anwendungen, Dienste oder andere Komponenten der Systeminfrastruktur handeln kann. Anschließend werden diese gesammelten Metriken in die Zeitreihen-Datenbank übertragen. Der Datenabruf-Worker sammelt diese Metriken, indem er HTTP-Endpunkte, auch bekannt als Prometheus-Instanz, auf den Zielen abfragt.
Standardmäßig lautet der Endpunkt für Metriken < hostaddress >/metrics. Sie konfigurieren Prometheus mit einem Prometheus-Exporter zur Überwachung eines Ziels. Im Kern ist ein Exporter ein Dienst, der Metriken vom Ziel abruft, sie richtig formatiert und den Endpunkt /metrics zur Verfügung stellt, damit der Datenabrufer die Daten zur Speicherung in der Zeitreihendatenbank abrufen kann. Um Metriken von Jobs zu pushen, die nicht abgefragt werden können, können Sie mit dem Prometheus Pushgateway Zeitreihen von kurzlebigen Batch-Jobs auf Service-Ebene an einen zwischengeschalteten Job pushen, den Prometheus abfragen kann.
HTTP-Server
Dieser Server akzeptiert Abfragen in einer Prometheus-Abfragesprache (PromQL), um Daten aus der Zeitreihen-Datenbank zu ziehen. Der HTTP-Server kann von der Prometheus Graph UI oder anderen Datenvisualisierungstools wie Grafana genutzt werden, um Entwicklern und IT-Mitarbeitern eine Schnittstelle für die Abfrage und Visualisierung dieser Metriken in einem nützlichen, menschenfreundlichen Format zu bieten.
Verwaltung von Prometheus-Warnungen
Der Prometheus Alertmanager ist hier ebenfalls erwähnenswert. In der Prometheus-Konfiguration können Sie Regeln einrichten, um Grenzwerte zu definieren, bei deren Überschreitung ein Alarm ausgelöst wird. Wenn dies geschieht, sendet der Prometheus-Server Warnmeldungen an den Alertmanager. Von dort aus kümmert sich der Alertmanager um die Deduplizierung, Gruppierung und Weiterleitung dieser Alarme an die zuständigen Mitarbeiter per E-Mail oder eine andere Alarmierungsintegration.
Warum Prometheus allein nicht ausreicht
Wie wir wissen, sind moderne Entwicklungsarchitekturen sehr viel komplexer als die von vor mehr als einem Jahrzehnt. Heutige Systeme enthalten viele Server, auf denen containerisierte Anwendungen und Dienste laufen, wie ein Kubernetes-Cluster. Diese Dienste sind lose gekoppelt und rufen sich gegenseitig auf, um dem Endbenutzer Funktionen zur Verfügung zu stellen. Architektonisch können diese Dienste auch entkoppelt sein und in mehreren Cloud-Umgebungen laufen. Die Komplexität dieser Systeme kann dazu führen, dass die Ursachen von Fehlern nicht mehr erkannt werden.
Unternehmen benötigen einen detaillierten Einblick in das Systemverhalten, um diese Herausforderung zu meistern. Das Sammeln und Aggregieren von Log-Ereignisdaten ist für dieses Ziel entscheidend. Diese Protokolldaten können mit Leistungsmetriken korreliert werden, so dass Unternehmen die für eine effiziente Ursachenanalyse erforderlichen Einblicke und Zusammenhänge gewinnen können. Prometheus sammelt zwar Metriken, aber keine Protokolldaten. Daher bietet es nicht den Detailgrad, der für eine effektive Incident Response erforderlich ist.
Darüber hinaus steht Prometheus vor Herausforderungen, wenn es erheblich skaliert wird – eine Situation, die bei solchen hochgradig verteilten modernen Systemen oft unvermeidlich ist. Prometheus wurde ursprünglich nicht für die Abfrage und Aggregation von Metriken aus mehreren Instanzen entwickelt. Die entsprechende Konfiguration erfordert eine zusätzliche Komplexität der Prometheus-Bereitstellung in Ihrem Unternehmen. Dies erschwert die Erlangung eines ganzheitlichen Überblicks über das gesamte System, was ein entscheidender Aspekt für eine effiziente Incident Response auf Vorfälle ist.
Und schließlich wurde Prometheus nicht dafür entwickelt, Metrikdaten über längere Zeiträume zu speichern. Der Zugriff auf diese Art von historischen Daten kann für Unternehmen, die komplexe Umgebungen verwalten, von unschätzbarem Wert sein. Zum Beispiel können Unternehmen diese Metriken analysieren, um Muster zu erkennen, die über einige Monate oder sogar ein Jahr hinweg auftreten, um ein Verständnis für die Systemnutzung während eines bestimmten Zeitraums zu erhalten. Solche Insights können Skalierungsstrategien diktieren, wenn Systeme an ihre Grenzen stoßen können.
Einheitliche Erfassung für Kubernetes-Monitoring
Prometheus ist zwar ein großartiges Tool zum Sammeln von High-Level-Metriken für SLOs und SLIs, aber Site Reliability Engineers und Sicherheitsanalysten müssen die Protokolle genauer untersuchen, um herauszufinden, was genau schief gelaufen sein könnte. Deshalb ist eine einheitliche Telemetrieerfassung für alle Datentypen – Logs , Metriken und Traces – so wichtig. Wir müssen uns von veralteten Prozessen und Denkweisen trennen, um innovativ zu sein, und die neuesten Best Practices nutzen, um das bestmögliche digitale Kundenerlebnis zu gewährleisten.
All diese Herausforderungen lassen sich am besten durch die Nutzung eines einheitlichen Kubernetes-Monitorings mit OpenTelemetry Collector von Sumo Logic und die Einrichtung des neuesten Helm Chart bewältigen. Außerdem können Sie mit Otel Remote Management von Sumo Logic Zeit bei der Einrichtung und Verwaltung Ihrer Collectors sparen. Sie können Prometheus-Daten weiterhin neben diesem Collector aggregieren, aber es gibt keinen Grund, ihn als Middleware für Metriken zu verwenden, es sei denn, Ihre Infrastruktur erfordert spezielle esoterische Fähigkeiten. Zum Beispiel die Vertrautheit mit PromQL oder der Bedarf an spezifischen Histogrammen, die in der Sumo Logic Überwachungsumgebung nicht verfügbar sind.
Es ist hilfreich, OpenTelemetry als Standard zu verwenden, um einen geringeren Erfassungsaufwand zu erzielen und Zeit bei der Instrumentierung für effektive Sicherheits- und Überwachungsmethoden zu sparen.
Neugierig auf mehr? Informieren Sie sich über Best Practices für Kubernetes-Monitoring.
