🌍 🌵 📣 Thanos - Skalierbarer Prometheus 🚶🏽 🧜🏼 🚘

Die Übersetzung des Artikels wurde speziell für Studenten des Kurses "DevOps Practices and Tools" erstellt .

(Fabian Reinartz) — , Go . Prometheus Kubernetes SIG instrumentation. production- SoundCloud CoreOS. Google.

(Bartek Plotka) — Improbable. . Intel, Mesos production- SRE Improbable. . : Golang, open source .

Wenn Sie sich unser Flaggschiff-Produkt SpatialOS ansehen, können Sie davon ausgehen, dass Improbable eine hochdynamische globale Cloud-Infrastruktur mit Dutzenden von Kubernetes-Clustern benötigt. Wir waren einer der ersten, die das Prometheus- Überwachungssystem verwendeten . Prometheus kann Millionen von Metriken in Echtzeit verfolgen und verfügt über eine leistungsstarke Abfragesprache, um die erforderlichen Informationen abzurufen.

Einfachheit und Zuverlässigkeit Prometheus ist einer seiner Hauptvorteile. Nachdem wir jedoch eine bestimmte Skala überschritten hatten, stießen wir auf mehrere Nachteile. Um diese Probleme zu lösen, haben wir Thanos entwickelt- Ein Open-Source-Projekt von Improbable, mit dem vorhandene Prometheus-Cluster nahtlos in ein einziges Überwachungssystem mit einem unbegrenzten Repository historischer Daten umgewandelt werden können. Thanos ist hier auf Github erhältlich .

Bleiben Sie mit den neuesten Nachrichten von Improbable auf dem Laufenden.

Unsere Ziele mit Thanos

Ab einem bestimmten Ausmaß treten Probleme auf, die über die Fähigkeiten des Vanille-Prometheus hinausgehen. Wie können Petabytes historischer Daten zuverlässig und wirtschaftlich gespeichert werden? Kann dies unbeschadet der Antwortzeit auf die Anfrage erfolgen? Ist es möglich, mit einer einzigen API-Anfrage auf alle Metriken zuzugreifen, die sich auf verschiedenen Prometheus-Servern befinden? Ist es möglich, die mit Prometheus HA gesammelten replizierten Daten irgendwie zu kombinieren?

Um diese Probleme zu beheben, haben wir Thanos erstellt. In den folgenden Abschnitten wird beschrieben, wie wir diese Probleme angegangen sind, und die von uns verfolgten Ziele erläutert.

Abfragen von Daten aus mehreren Prometheus-Instanzen (globale Abfrage)

Prometheus bietet einen funktionalen Ansatz für das Splittern. Selbst ein Prometheus-Server bietet eine ausreichende Skalierbarkeit, um Benutzer in fast allen Anwendungsfällen von den Schwierigkeiten des horizontalen Shardings zu befreien.

Obwohl dies ein hervorragendes Bereitstellungsmodell ist, ist es häufig erforderlich, über eine einzige API- oder UI-globale Ansicht auf Daten auf verschiedenen Prometheus-Servern zuzugreifen. Natürlich ist es möglich, mehrere Anforderungen in einem Grafana-Bedienfeld anzuzeigen, aber jede Anforderung kann nur auf einem Prometheus-Server ausgeführt werden. Andererseits können Sie mit Thanos Daten von mehreren Prometheus-Servern abfragen und aggregieren, da alle von einem Endpunkt aus zugänglich sind.

Zuvor hatten wir unsere Prometheus-Instanzen auf mehreren Ebenen organisiert, um einen globalen Überblick über Improbable zu erhaltenHierarchische Föderation . Dies bedeutete, einen Prometheus-Metaserver zu erstellen, der einen Teil der Metriken von jedem Blattserver sammelt. Dies

erwies sich als problematisch, komplizierte die Konfiguration, fügte einen zusätzlichen potenziellen Fehlerpunkt hinzu und wandte komplexe Regeln an, um dem Verbundendpunkt genau die richtigen Daten bereitzustellen. Darüber hinaus können Sie mit einem solchen Verbund keine echte globale Ansicht erhalten, da nicht alle Daten über eine API-Anforderung zugänglich sind.

Eng damit verbunden ist die einmalige Darstellung der auf den Prometheus-Hochverfügbarkeitsservern (HA) gesammelten Daten. Das Prometheus HA-Modell sammelt unabhängig voneinander zweimal Daten, was so einfach ist, dass es nicht einfacher sein könnte. Die Verwendung einer kombinierten und deduplizierten Darstellung beider Threads wäre jedoch viel praktischer.

Natürlich werden hochverfügbare Prometheus-Server benötigt. Bei Improbable nehmen wir es wirklich ernst, Daten jede Minute zu überwachen, aber eine Instanz von Prometheus pro Cluster zu haben, ist eine einzige Fehlerquelle. Jeder Konfigurationsfehler oder Hardwarefehler kann möglicherweise zum Verlust wichtiger Daten führen. Selbst einfache Bereitstellungen können zu geringfügigen Störungen bei der Erfassung von Metriken führen, da der Neustart erheblich länger als das Scraping-Intervall sein kann.

Zuverlässige Speicherung historischer Daten

Günstige, schnelle und langfristige Speicherung von Metriken ist unser Traum (von den meisten Prometheus-Benutzern geteilt). In Improbable mussten wir die Speicherdauer für die Metriken auf neun Tage festlegen (für Prometheus 1.8). Dies fügt offensichtliche Einschränkungen hinzu, wie weit wir zurückblicken können.

Prometheus 2.0 ist in dieser Hinsicht besser, da die Anzahl der Zeitreihen die Gesamtserverleistung nicht mehr beeinflusst (siehe KubeCon-Keynote zu Prometheus 2 ). Prometheus speichert jedoch Daten auf einem lokalen Laufwerk. Obwohl eine hocheffiziente Datenkomprimierung die Verwendung lokaler SSDs erheblich reduzieren kann, ist die Menge der gespeicherten Verlaufsdaten letztendlich immer noch begrenzt.

Bei Improbable legen wir auch Wert auf Zuverlässigkeit, Einfachheit und Kosten. Große lokale Laufwerke sind schwieriger zu bedienen und zu sichern. Sie sind teurer und erfordern mehr Backup-Tools, was zu unnötiger Komplexität führt.

Downsampling

Als wir anfingen, mit historischen Daten zu arbeiten, stellten wir fest, dass es bei O-big grundlegende Schwierigkeiten gibt, die Abfragen immer langsamer machen, wenn wir über Wochen, Monate und Jahre mit Daten arbeiten.

Eine Standardlösung für dieses Problem ist das Downsampling - das Downsampling des Signals. Durch Downsampling können wir auf einen größeren Zeitbereich „verkleinern“ und die gleiche Anzahl von Samples beibehalten, wodurch wir die Reaktionsfähigkeit von Anforderungen beibehalten können.

Das Downsampling alter Daten ist eine unvermeidliche Voraussetzung für eine Langzeitspeicherlösung und geht über Vanilla Prometheus hinaus.

Zusätzliche Ziele

Eines der ersten Ziele des Thanos-Projekts war die nahtlose Integration in vorhandene Prometheus-Installationen. Das zweite Ziel war eine einfache Bedienung mit einer minimalen Eintrittsbarriere. Abhängigkeiten sollten sowohl für kleine als auch für große Benutzer leicht zu erfüllen sein, was auch niedrige Grundkosten impliziert.

Thanos Architektur

Nachdem unsere Ziele im vorherigen Abschnitt aufgeführt wurden, arbeiten wir daran und sehen, wie Thanos diese Probleme löst.

Globale Sicht

Um eine globale Übersicht über vorhandene Instanzen von Prometheus zu erhalten, müssen wir allen Servern einen einzelnen Anforderungseinstiegspunkt zuordnen. Genau das leistet die Thanos Sidecar- Komponente . Es wird neben jedem Prometheus-Server bereitgestellt und fungiert als Proxy, der lokale Prometheus-Daten über die gRPC-Schnittstelle des Stores bereitstellt und es Ihnen ermöglicht, Zeitreihendaten nach Bezeichnung und Zeitbereich auszuwählen.

Auf der anderen Seite gibt es eine zustandslose, horizontal skalierbare Querier-Komponente, die etwas mehr kann als nur auf PromQL-Anfragen über die Standard-Prometheus-HTTP-API zu antworten. Komponenten Querier, Sidecar und andere Thanos kommunizieren über das Klatschprotokoll .

Der Abfrager stellt nach Erhalt der Anforderung eine Verbindung zum entsprechenden Store-API-Server, dh zu unserem Sidecar, her und empfängt Zeitreihendaten von den entsprechenden Prometheus-Servern.
Danach werden die Antworten kombiniert und eine PromQL-Abfrage durchgeführt. Querier kann sowohl disjunkte Daten als auch doppelte Daten von Prometheus HA-Servern kombinieren.

Dies löst den Großteil unseres Rätsels - die Kombination von Daten von isolierten Prometheus-Servern in einer einzigen Ansicht. Tatsächlich kann Thanos nur für diese Gelegenheit verwendet werden. Bestehende Prometheus-Server müssen keine Änderungen vornehmen!

Unbegrenzte Haltbarkeit!

Früher oder später möchten wir jedoch Daten speichern, die über die normale Speicherzeit von Prometheus hinausgehen. Um historische Daten zu speichern, haben wir die Objektspeicherung ausgewählt. Es ist in jeder Cloud sowie in lokalen Rechenzentren weit verbreitet und sehr wirtschaftlich. Darüber hinaus kann über die bekannte S3-API auf nahezu jeden Objektspeicher zugegriffen werden.

Prometheus schreibt ungefähr alle zwei Stunden Daten aus dem RAM auf die Festplatte. Der Block gespeicherter Daten enthält alle Daten für einen festgelegten Zeitraum und ist unveränderlich. Dies ist sehr praktisch, da Thanos Sidecar einfach den Prometheus-Datenkatalog einsehen und diese, sobald neue Blöcke angezeigt werden, in die Objektspeicher-Buckets laden kann.

Durch das Herunterladen in den Objektspeicher unmittelbar nach dem Schreiben auf eine Festplatte können Sie auch die Einfachheit eines „Scraper“ (Prometheus und Thanos Sidecar) beibehalten. Dies vereinfacht den Support, die Kosten und das Systemdesign.

Wie Sie sehen, ist das Sichern von Daten sehr einfach. Aber was ist mit der Abfrage von Daten im Objektspeicher?

Die Thanos Store-Komponente fungiert als Proxy zum Abrufen von Daten aus dem Objektspeicher. Wie Thanos Sidecar nimmt es am Klatschcluster teil und implementiert die Store-API. Daher kann der vorhandene Querier es als Sidecar als weitere Quelle für Zeitreihendaten betrachten - es ist keine spezielle Konfiguration erforderlich.

Zeitreihendatenblöcke bestehen aus mehreren großen Dateien. Das Herunterladen bei Bedarf wäre ziemlich ineffizient, und das lokale Caching erforderte großen Speicher und Speicherplatz.

Stattdessen weiß Store Gateway, wie mit dem Prometheus-Speicherformat umgegangen wird. Dank des cleveren Abfrageplaners und des Zwischenspeicherns nur der erforderlichen Indexteile der Blöcke konnten komplexe Abfragen auf die minimale Anzahl von HTTP-Anforderungen an Objektspeicherdateien reduziert werden. Somit ist es möglich, die Anzahl von Anforderungen um vier bis sechs Größenordnungen zu reduzieren und Antwortzeiten zu erzielen, die im Allgemeinen schwer von Datenanforderungen auf einer lokalen SSD zu unterscheiden sind.

Wie im obigen Diagramm gezeigt, reduziert Thanos Querier die Kosten einer einzelnen Datenanforderung im Objektspeicher erheblich, indem das Prometheus-Speicherformat verwendet und zugehörige Daten nebeneinander platziert werden. Mit diesem Ansatz können wir viele einzelne Abfragen zu einer minimalen Anzahl von Massenoperationen kombinieren.

Verdichtung und Downsampling

Nachdem der neue Zeitreihendatenblock erfolgreich in den Objektspeicher geladen wurde, betrachten wir ihn als "historische" Daten, die sofort über das Store Gateway verfügbar werden.

Nach einer Weile sammeln sich jedoch Blöcke aus einer Quelle (Prometheus mit Beiwagen) an und nutzen nicht mehr das volle Indexierungspotential. Um dieses Problem zu lösen, haben wir eine weitere Komponente namens Compactor eingeführt. Es wendet einfach den lokalen Prometheus-Komprimierungsmechanismus auf historische Daten im Objektspeicher an und kann als einfacher periodischer Stapeljob ausgeführt werden.

Dank der effizienten Komprimierung verursacht eine Abfrage im Repository über einen längeren Zeitraum keine Probleme hinsichtlich der Datengröße. Die potenziellen Kosten für das Entpacken und Durchlaufen einer Milliarde Werte durch einen Abfrageprozessor führen jedoch zwangsläufig zu einer starken Verlängerung der Ausführungszeit für Abfragen. Andererseits gibt es, da es Hunderte von Datenpunkten pro Pixel des Bildschirms gibt, unmöglich, die Daten in voller Auflösung zu visualisieren. Downsampling ist also nicht nur möglich, sondern führt auch nicht zu einem spürbaren Genauigkeitsverlust.

Für das Downsampling von Daten aggregiert Compactor kontinuierlich Daten mit einer Auflösung von fünf Minuten und einer Stunde. Für jedes Rohfragment, das mit TSDB XOR-Komprimierung codiert wurde, werden verschiedene Arten von aggregierten Daten gespeichert, z. B. min, max oder sum für einen Block. Dadurch kann Querier automatisch das Aggregat auswählen, das für diese PromQL-Abfrage geeignet ist.

Um Daten mit reduzierter Genauigkeit zu verwenden, benötigt der Benutzer keine spezielle Konfiguration. Der Querier wechselt automatisch zwischen verschiedenen Auflösungen und Rohdaten, wenn der Benutzer ein- und auszoomt. Falls gewünscht, kann der Benutzer dies direkt über den Parameter "step" in der Anforderung steuern.

Da die Kosten für die Speicherung von einem GB gering sind, speichert Thanos standardmäßig die Originaldaten, Daten mit einer Auflösung von fünf Minuten und einer Stunde. Die Originaldaten müssen nicht gelöscht werden.

Aufnahmeregeln

Auch mit Thanos sind Aufzeichnungsregeln ein wesentlicher Bestandteil des Überwachungsstapels. Sie reduzieren die Komplexität, Latenz und Kosten von Anfragen. Sie sind auch praktisch für Benutzer, um aggregierte Metrikdaten zu erhalten. Thanos basiert auf Vanille-Instanzen von Prometheus, daher ist es durchaus akzeptabel, Aufzeichnungsregeln und Warnregeln auf einem vorhandenen Prometheus-Server zu speichern. In einigen Fällen reicht dies jedoch möglicherweise nicht aus:

Globale Warnungen und Regeln (z. B. Warnungen, wenn ein Dienst auf mehr als zwei der drei Cluster ausfällt).
Regel für Daten außerhalb des lokalen Speichers.
Der Wunsch, alle Regeln und Wachsamkeit an einem Ort zu halten.

In all diesen Fällen enthält Thanos eine separate Komponente namens Ruler, die Regeln und Warnungen über Thanos-Abfragen berechnet. Durch die Bereitstellung der bekannten StoreAPI kann der Abfrageknoten auf frisch berechnete Metriken zugreifen. Später werden sie auch im Objektspeicher gespeichert und über das Store Gateway verfügbar gemacht.

Die Kraft von Thanos

Thanos ist flexibel genug, um an Ihre Anforderungen angepasst zu werden. Dies ist besonders nützlich, wenn Sie von einem einfachen Prometheus migrieren. Lassen Sie uns einen kurzen Blick darauf werfen, was wir über die Komponenten von Thanos gelernt haben. So übertragen Sie Ihren Vanille-Prometheus in die Welt des „unbegrenzten Metrikspeichers“:

Fügen Sie Thanos Sidecar zu Ihren Prometheus-Servern hinzu - zum Beispiel den angrenzenden Container im Kubernetes-Pod.
Erweitern Sie mehrere Thanos Querier-Replikate, um Daten anzuzeigen. An diesem Punkt ist es einfach, Klatsch und Tratsch zwischen Scraper und Querier einzurichten. Verwenden Sie die Metrik 'thanos_cluster_members', um Komponenteninteraktionen zu testen.

Nur diese beiden Schritte reichen aus, um eine globale Ansicht und eine nahtlose Datendeduplizierung von potenziellen Prometheus HA-Replikaten bereitzustellen! Verbinden Sie einfach Ihre Dashboards mit dem Querier-HTTP-Endpunkt oder verwenden Sie die Thanos-Benutzeroberfläche direkt.

Wenn Sie jedoch Metriken und Langzeitspeicher sichern müssen, müssen Sie drei weitere Schritte ausführen:

Erstellen Sie einen AWS S3- oder GCS-Bucket. Konfigurieren Sie Sidecar so, dass Daten in diese Buckets kopiert werden. Jetzt können Sie die lokale Datenspeicherung minimieren.
Erweitern Sie das Store Gateway und verbinden Sie es mit einem vorhandenen Klatschcluster. Jetzt können Sie Datenanfragen in Backups senden!
Stellen Sie Compactor bereit, um die Abfrageleistung über lange Zeiträume mithilfe von Komprimierung und Downsampling zu verbessern.

Wenn Sie mehr wissen wollen, können Sie bei uns sehen Beispiele für die manifest Kubernetes und Sie beginnen !

In nur fünf Schritten haben wir Prometheus zu einem zuverlässigen Überwachungssystem mit globaler Sicht, unbegrenzter Speicherzeit und potenziell hoher Verfügbarkeit von Metriken gemacht.

Pull Anfrage: Wir brauchen dich!

Thanos war von Anfang an ein Open Source Projekt. Die nahtlose Integration mit Prometheus und die Möglichkeit, nur einen Teil von Thanos zu verwenden, machen es zu einer hervorragenden Wahl für die Skalierung eines Überwachungssystems ohne zusätzlichen Aufwand.

Wir freuen uns immer über GitHub Pull Request und Issues. Zögern Sie nicht, uns über Github Issues oder Slack Improbable-eng #thanos zu kontaktieren, wenn Sie Fragen oder Feedback haben oder Ihre Erfahrungen teilen möchten! Wenn Ihnen unsere Arbeit bei Improbable gefällt, können Sie sich gerne an uns wenden - wir haben immer freie Stellen !

Erfahren Sie mehr über den Kurs.

Thanos - Skalierbarer Prometheus