Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Debuggen bei hohem Speicherverbrauch

Jede Zeitreihe in Prometheus wird eindeutig durch ihren Metriknamen und optionale Schlüssel-Wert-Paare, die Labels genannt werden, identifiziert.

Die Labels ermöglichen das Filtern und Aggregieren der Zeitreihendaten, multiplizieren jedoch auch die Menge an Daten, die Prometheus sammelt.

Jede Zeitreihe hat eine definierte Menge an Labels, und Prometheus generiert eine neue Zeitreihe für alle einzigartigen Kombinationen von Labels. Wenn eine Metrik zwei angehängte Labels hat, werden zwei Zeitreihen für diese Metrik generiert. Das Ändern eines beliebigen Labelwerts, einschließlich des Hinzufügens oder Entfernens eines Labels, erstellt eine neue Zeitreihe.

Prometheus ist optimiert, um Daten zu speichern, die indexbasiert auf Serien sind. Es ist für eine relativ konstante Anzahl von Zeitreihen und eine relativ große Anzahl von Proben ausgelegt, die im Laufe der Zeit von den Exportern gesammelt werden müssen.

Umgekehrt ist Prometheus nicht optimiert, um eine schnell wechselnde Anzahl von Zeitreihen zu berücksichtigen. Aus diesem Grund können große Speicherverbrauchsspitzen auftreten, wenn das Monitoring auf Clustern installiert ist, auf denen viele Ressourcen erstellt und zerstört werden, insbesondere auf Multi-Tenant-Clustern.

Reduzierung von Speicherverbrauchsspitzen

Um den Speicherverbrauch zu reduzieren, kann Prometheus so konfiguriert werden, dass weniger Zeitreihen gespeichert werden, indem weniger Metriken abgerufen oder weniger Labels an die Zeitreihen angehängt werden. Um zu sehen, welche Zeitreihen den meisten Speicher verbrauchen, können Sie die TSDB (Zeitreihendatenbank)-Statusseite in der Prometheus-Benutzeroberfläche überprüfen.

Verteilte Prometheus-Lösungen wie Thanos und Cortex verwenden eine alternative Architektur, bei der mehrere kleine Prometheus-Instanzen bereitgestellt werden. Im Fall von Thanos werden die Metriken aus jedem Prometheus in die gemeinsame Thanos-Implementierung aggregiert, und diese Metriken werden dann in einem persistenten Speicher, wie S3, exportiert. Diese robustere Architektur vermeidet es, eine einzelne Prometheus-Instanz mit zu vielen Zeitreihen zu belasten, während sie gleichzeitig die Möglichkeit bewahrt, Metriken auf globaler Ebene abzufragen.