Moderne Systeme unterscheiden sich grundlegend von denen früherer Jahre. Die meisten Unternehmen haben sich von traditionellen Monolithen verabschiedet und containerisierte Anwendungen eingeführt, die auf hochverteilten Infrastrukturen laufen.
Diese Entwicklung erhöht die Resilienz, bringt jedoch ein höheres Maß an Komplexität mit sich, was die Identifikation und Behebung von Problemen erschwert.
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. Außerdem werden die Gründe dargelegt, warum Prometheus allein nicht ausreicht, um die komplexen, stark verteilten Systemumgebungen zu überwachen, die heute im Einsatz sind.
Was ist Prometheus?
Prometheus ist ein Open-Source-Monitoring- und Alerting-Toolkit, das 2012 von SoundCloud für das Monitoring Cloud-nativer Metriken entwickelt wurde.
Im Bereich Monitoring und Observability gibt es drei zentrale Datentypen: Logs, Metriken und Traces. Metriken dienen als zeitbasierte Messwerte, die Ihnen helfen, Service Level Objectives (SLOs) und Service Level Indicators (SLIs) in Form von Zeitreihen 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 Unternehmen OpenTelemetry übernommen, um Collectors zu vereinheitlichen und Daten aus allen drei Datenquellen zu sammeln.
Was kann mit Prometheus überwacht werden?
Unternehmen nutzen Prometheus, um Metrikdaten zur Performance von Services und Infrastruktur zu sammeln. Je nach Anwendungsfall können dies Indikatoren wie CPU-Auslastung, Speicherauslastung, Gesamtanzahl der Requests, Requests pro Sekunde, Request-Zähler, Exception-Zähler und mehr sein. Wenn diese Metriken korrekt genutzt werden, unterstützen sie Unternehmen dabei, Systemprobleme zeitnah zu identifizieren.
Prometheus-Server-Architektur
Im Mittelpunkt der Prometheus-Architektur steht der Prometheus-Server, der die eigentlichen Überwachungsfunktionen durchführt. Der Prometheus-Server besteht aus drei Hauptkomponenten: einer Zeitreihen-Datenbank, einem Worker für den Datenabruf und einem HTTP-Server.
Zeitreihendatenbank
Diese Komponente ist für die Speicherung der Metriken verantwortlich. Diese Metriken werden als Zeitreihe abgelegt, was bedeutet, dass die Daten als eine Reihe von zeitgestempelten Datenpunkten in der Datenbank gespeichert werden, die derselben Metrik und denselben Label-Dimensionen zugeordnet sind.
Worker für Datenabruf
Diese Komponente tut genau das, was ihr Name andeutet: ruft Metriken von sogenannten “Targets” ab, wie etwa Anwendungen, Services oder Infrastrukturkomponenten. Diese Metriken werden dann in die Zeitreihendatenbank übertragen. Die Datenerfassung erfolgt durch das Abrufen von HTTP-Endpunkten, auch als Prometheus-Instanzen bekannt, auf den entsprechenden Targets.
Der Standard-Endpoint für Metriken lautet
HTTP-Server
Der HTTP-Server akzeptiert Abfragen in der Prometheus Query Language (PromQL), um Daten aus der Zeitreihendatenbank abzurufen. Der HTTP-Server kann sowohl durch die Prometheus-UI als auch durch andere Visualisierungstools wie Grafana verwendet werden, um Entwicklern und IT-Personal eine benutzerfreundliche Schnittstelle zum Abfragen und Visualisieren dieser Metriken bereitzustellen.
Verwaltung von Prometheus-Alerts
Auch der Prometheus Alertmanager ist hier erwähnenswert. In der Prometheus-Konfiguration können Regeln definiert werden, die Grenzwerte festlegen, bei deren Überschreitung ein Alarm ausgelöst wird. Wenn diese Grenze überschritten wird, sendet der Prometheus-Server den Alarm an den Alertmanager. Der Alertmanager übernimmt dann die Aufgaben der Deduplizierung, Gruppierung und Weiterleitung dieser Alarme an die zuständigen Personen per E-Mail oder über andere Integrationen.
Warum Prometheus allein nicht ausreicht
Wie wir wissen, haben moderne Entwicklungsarchitekturen ein viel höheres Maß an Komplexität als noch vor über einem Jahrzehnt. Heutige Systeme bestehen aus vielen Servern, die containerisierte Anwendungen und Services betreiben, wie z. B. in einem Kubernetes-Cluster. Diese Services sind lose gekoppelt und rufen sich gegenseitig auf, um Funktionalitäten für den Endnutzer bereitzustellen. Architektonisch können diese Services auch entkoppelt sein und in mehreren Cloud-Umgebungen laufen. Die komplexe Struktur dieser Systeme kann dazu führen, dass die Ursachen von Ausfällen schwer zu identifizieren sind.
Um diese Herausforderung zu bewältigen, benötigen Unternehmen einen detaillierten Einblick in das Systemverhalten. Die Sammlung und Aggregation von Logdaten ist dabei von entscheidender Bedeutung. Diese Logdaten können mit Leistungsmetriken korreliert werden, so dass Unternehmen die für eine effiziente Ursachenanalyse erforderlichen Einblicke und Zusammenhänge gewinnen. Prometheus sammelt zwar Metriken, aber keine Logdaten. Daher bietet es nicht den Detailgrad, der für eine effektive Incident Response erforderlich ist.
Darüber hinaus steht Prometheus vor Herausforderungen, wenn es stark 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. Eine 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 Reaktion auf Vorfälle ist.
Und schließlich wurde Prometheus nicht entwickelt, um Metrikdaten über lange Zeiträume aufzubewahren. Der Zugriff auf diese Art von historischen Daten kann für Unternehmen, die komplexe Umgebungen verwalten, von unschätzbarem Wert sein. Zum einen 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 Erkenntnisse können Skalierungsstrategien vorgeben, wenn die Systeme an ihre Grenzen stoßen.
Einheitliche Erfassung für Kubernetes-Monitoring
Prometheus ist zwar ein hervorragendes Tool für die Erfassung von Metriken auf hoher Ebene für SLOs und SLIs, aber Site Reliability Engineers und Sicherheitsanalysten müssen die Logs 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 veraltete Prozesse und Denkweisen hinter uns lassen, um innovativ zu sein und die neuesten Best Practices zu nutzen, um das bestmögliche digitale Kundenerlebnis zu gewährleisten.
All diese Herausforderungen lassen sich am besten durch die Nutzung einer einheitlichen Kubernetes-Überwachung mit OpenTelemetry Collector von Sumo Logic und die Einrichtung des neuesten Helm Chart bewältigen. Zusätzlich können Sie mit Otel Remote Management von Sumo Logic Zeit bei der Einrichtung und Verwaltung Ihrer Collectors Zeit sparen. Sie können Prometheus-Daten immer noch neben diesem Collector aggregieren, aber es gibt keinen Grund, ihn als Middleware für Metriken zu verwenden, es sei denn, Ihre Infrastruktur erfordert spezifische Fachkenntnisse. Ein Beispiel dafür wäre die Vertrautheit mit PromQL oder das Erfordernis bestimmter Histogramme, die im Sumo Logic-Monitoring-Umfeld nicht verfügbar sind.
Es ist sinnvoll, OpenTelemetry als Standard zu nutzen, um eine kleinere Erfassungsfläche zu erreichen und die Zeit für die Instrumentierung im Rahmen der besten Sicherheits- und Monitoringpraktiken zu minimieren.
Neugierig auf mehr? Schauen Sie sich die Best Practices für Kubernetes-Monitoring an.
