Warum Prometheus nicht ausreicht, um komplexe Umgebungen zu überwachen

Warum Prometheus nicht ausreicht, um komplexe Umgebungen zu überwachen

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. 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 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 /metrics. Um ein Target zu überwachen, wird Prometheus mit einem sogenannten Exporter konfiguriert. Ein Exporter ist ein Service, der Metriken vom Target abruft, sie korrekt formatiert und den /metrics-Endpoint bereitstellt, damit der Worker die Daten zur Speicherung in der Zeitreihendatenbank abholen kann. Für Jobs, die nicht gescraped werden können, bietet der Prometheus Pushgateway eine Möglichkeit, Zeitreihen von kurzlebigen Batch-Jobs zu pushen, die Prometheus dann abruft.

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

FAQs

Sind die Ergebnisse einer Ursachenanalyse immer genau?+

Nicht immer. Die Genauigkeit der Analyse richtet sich nach der Datenqualität, dem Fachwissen der für die Analyse zuständigen Personen und der Gründlichkeit des Untersuchungsprozesses. Protokolldaten befinden sich auf atomarer Ebene der Daten und sind daher bei der Ursachenanalyse am hilfreichsten und genauesten.

Wie unterscheidet sich Sumo Logic von anderen Kubernetes-Monitoring-Lösungen?+

Eine Kubernetes-Arbeitslast kann viele Probleme aufweisen, und moderne Application-Monitoring-Tools müssen herausfinden, welche Kombination aus Pod und Knoten Probleme hat. Prüfen Sie dann die zugehörigen Containerprotokolle, um die Ursache des Problems zu ermitteln. Idealerweise sollten Ausfälle der Kubernetes-Infrastruktur in einem Monitoring-Tool visualisiert werden, das Container-Metriken, Knoten-Metriken, Ressourcen-Metriken, Kubernetes-Cluster-Logs und Trace-Daten in Histogrammen und Diagrammen erfassen kann.

Herkömmliche Monitoring-Lösungen zwingen einem Microservices-Problem eine serverbasierte Lösung auf. Ihr Team verschwendet wertvolle Minuten damit, ernsthafte Kunden- und Sicherheitsprobleme mit Infrastrukturproblemen auf Pod-, Container- und Knotenebene zu korrelieren. Sumo Logic hat dieses Modell auf den Kopf gestellt.

Mit Sumo Logic können Sie Ihre Kubernetes-Umgebung in Form von Logs, Metriken und Ereignissen in verschiedenen Hierarchien betrachten, so dass Sie Ihren Cluster durch die Linse Ihrer Wahl sehen können. Wir können zum Beispiel native Kubernetes-Metadaten wie einen Namespace verwenden, um die Leistung aller mit einem Namespace verbundenen Pods zu visualisieren.

Gibt es besondere Herausforderungen oder Einschränkungen beim Monitoring eines Kubernetes-Einsatzes in einer Multi-Cloud-Umgebung+

Welche Kubernetes-Metriken sollte man messen?+

Es gibt viele wichtige Metriken für die Überwachung von Kubernetes-Clustern. Die Überwachung erfolgt auf zwei Ebenen: Cluster und Pod. Die Cluster-Überwachung überwacht den Zustand eines gesamten Kubernetes-Clusters, um zu überprüfen, ob die Knoten ordnungsgemäß und mit der richtigen Kapazität funktionieren, wie viele Anwendungen auf einem Knoten laufen und wie der Cluster die Ressourcen nutzt. Die Pod-Überwachung verfolgt Probleme, die sich auf einzelne Pod-Metriken auswirken, wie Ressourcenauslastung, Anwendungs- und Pod-Replikation oder Autoscaling-Metriken.

Auf Clusterebene müssen Sie messen, wie viele Knoten verfügbar und gesund sind, um die Cloud-Ressourcen zu bestimmen, die Sie für den Betrieb des Clusters benötigen. Sie müssen auch messen, welche Rechenressourcen Ihre Knoten nutzen – einschließlich Speicher, CPU, Bandbreite und Speicherauslastung –, um zu wissen, ob Sie die Größe oder Anzahl der Knoten in einem Cluster verringern oder erhöhen sollten.

Auf der Ebene des Pods gibt es drei wichtige Kennzahlen:

Container: Netzwerk-, CPU- und Speichernutzung

Anwendung: spezifisch für die Anwendung und bezogen auf ihre Geschäftslogik

Pod-Gesundheit und -Verfügbarkeit: wie der Orchestrator einen bestimmten Pod, Gesundheitsprüfungen, Netzwerkdaten und die fortschreitende Bereitstellung behandelt.