Die Übersetzung des Artikels wurde speziell für die Studierenden des Kurses erstellt .
ist Softwareentwickler, Go-Fanatiker und Problemlöser. Er ist außerdem Prometheus-Maintainer und Mitbegründer der Kubernetes SIG-Instrumentierung. Zuvor war er Produktionsingenieur bei SoundCloud und leitete das Monitoring-Team bei CoreOS. Arbeitet derzeit bei Google.
- Infrastrukturingenieur bei Improbable. Er interessiert sich für neue Technologien und Probleme verteilter Systeme. Er verfügt über Erfahrung in der Low-Level-Programmierung bei Intel, Erfahrung als Mitwirkender bei Mesos und erstklassige SRE-Produktionserfahrung bei Improbable. Engagiert für die Verbesserung der Welt der Microservices. Seine drei Lieben: Golang, Open Source und Volleyball.
Wenn Sie sich unser Flaggschiffprodukt SpatialOS ansehen, können Sie davon ausgehen, dass Improbable eine hochdynamische, globale Cloud-Infrastruktur mit Dutzenden von Kubernetes-Clustern erfordert. Wir waren einer der Ersten, die ein Überwachungssystem eingesetzt haben . Prometheus ist in der Lage, Millionen von Metriken in Echtzeit zu verfolgen und verfügt über eine leistungsstarke Abfragesprache, mit der Sie die benötigten Informationen extrahieren können.
Die Einfachheit und Zuverlässigkeit von Prometheus ist einer seiner Hauptvorteile. Sobald wir jedoch ein bestimmtes Ausmaß erreichten, stießen wir auf mehrere Nachteile. Um diese Probleme zu lösen, haben wir entwickelt ist ein Open-Source-Projekt von Improbable, um bestehende Prometheus-Cluster nahtlos in ein einziges Überwachungssystem mit unbegrenzter Speicherung historischer Daten umzuwandeln. Thanos ist auf Github verfügbar .
Unsere Ziele mit Thanos
Ab einem bestimmten Ausmaß treten Probleme auf, die über die Möglichkeiten von Vanilla Prometheus hinausgehen. Wie können Petabytes an historischen Daten zuverlässig und wirtschaftlich gespeichert werden? Ist dies ohne Beeinträchtigung der Reaktionszeit möglich? Ist es möglich, mit einer einzigen API-Anfrage auf alle Metriken zuzugreifen, die sich auf verschiedenen Prometheus-Servern befinden? Gibt es eine Möglichkeit, mit Prometheus HA erfasste replizierte Daten zu kombinieren?
Um diese Probleme anzugehen, haben wir Thanos geschaffen. Die folgenden Abschnitte beschreiben, wie wir diese Probleme angegangen sind, und erläutern unsere Ziele.
Abfragen von Daten aus mehreren Prometheus-Instanzen (globale Abfrage)
Prometheus bietet einen funktionalen Ansatz für das Sharding. Selbst ein einzelner Prometheus-Server bietet genügend Skalierbarkeit, um Benutzer in fast allen Anwendungsfällen von der Komplexität des horizontalen Shardings zu befreien.
Obwohl dies ein großartiges Bereitstellungsmodell ist, ist es oft notwendig, über eine einzige API oder Benutzeroberfläche – eine globale Ansicht – auf Daten auf verschiedenen Prometheus-Servern zuzugreifen. Natürlich ist es möglich, mehrere Abfragen in einem Grafana-Panel anzuzeigen, aber jede Abfrage kann nur auf einem Prometheus-Server ausgeführt werden. Andererseits können Sie mit Thanos Daten von mehreren Prometheus-Servern abfragen und aggregieren, da sie alle von einem einzigen Endpunkt aus zugänglich sind.
Um einen globalen Überblick in Improbable zu erhalten, haben wir unsere Prometheus-Instanzen zuvor auf mehreren Ebenen organisiert . Dies bedeutete die Erstellung eines Prometheus-Metaservers, der einige der Metriken von jedem Blattserver sammelt.
Dieser Ansatz erwies sich als problematisch. Dies hat zu komplexeren Konfigurationen, der Hinzufügung eines zusätzlichen potenziellen Fehlerpunkts und der Anwendung komplexer Regeln geführt, um sicherzustellen, dass der föderierte Endpunkt nur die Daten erhält, die er benötigt. Darüber hinaus ermöglicht Ihnen diese Art der Föderation keine echte globale Ansicht, da nicht alle Daten über eine einzige API-Anfrage verfügbar sind.
Eng damit verbunden ist eine einheitliche Sicht auf die Daten, die auf Prometheus-Servern mit hoher Verfügbarkeit (HA) gesammelt werden. Das HA-Modell von Prometheus erfasst Daten unabhängig voneinander zweimal, was so einfach ist, dass es nicht einfacher sein könnte. Die Verwendung einer kombinierten und deduplizierten Ansicht beider Streams wäre jedoch wesentlich praktischer.
Natürlich besteht Bedarf an hochverfügbaren Prometheus-Servern. Bei Improbable nehmen wir die Datenüberwachung von Minute zu Minute sehr ernst, aber eine Prometheus-Instanz pro Cluster ist ein Single Point of Failure. Jeder Konfigurationsfehler oder Hardwarefehler kann möglicherweise zum Verlust wichtiger Daten führen. Selbst eine einfache Bereitstellung kann zu geringfügigen Unterbrechungen bei der Metrikerfassung führen, da Neustarts erheblich länger als das Scraping-Intervall dauern können.
Zuverlässige Speicherung historischer Daten
Eine kostengünstige, schnelle und langfristige Speicherung von Metriken ist unser Traum (der von den meisten Prometheus-Benutzern geteilt wird). In Improbable waren wir gezwungen, den Aufbewahrungszeitraum für Metriken auf neun Tage zu konfigurieren (für Prometheus 1.8). Dies führt zu offensichtlichen Grenzen dafür, wie weit wir zurückblicken können.
Prometheus 2.0 hat sich in dieser Hinsicht verbessert, da die Anzahl der Zeitreihen keinen Einfluss mehr auf die Gesamtleistung des Servers hat (siehe. ). Prometheus speichert Daten jedoch auf der lokalen Festplatte. Obwohl eine hocheffiziente Datenkomprimierung die lokale SSD-Nutzung erheblich reduzieren kann, gibt es letztendlich immer noch eine Grenze für die Menge der historischen Daten, die gespeichert werden können.
Darüber hinaus legen wir bei Improbable Wert auf Zuverlässigkeit, Einfachheit und Kosten. Große lokale Festplatten sind schwieriger zu bedienen und zu sichern. Sie kosten mehr und erfordern mehr Backup-Tools, was zu unnötiger Komplexität führt.
Downsampling
Als wir begannen, mit historischen Daten zu arbeiten, stellten wir fest, dass es bei Big-O grundlegende Schwierigkeiten gibt, die Abfragen immer langsamer machen, wenn wir mit Daten von Wochen, Monaten und Jahren arbeiten.
Die Standardlösung für dieses Problem wäre (Downsampling) – Reduzierung der Signalabtastfrequenz. Durch Downsampling können wir auf einen größeren Zeitbereich „herunterskalieren“ und die gleiche Anzahl an Stichproben beibehalten, sodass die Abfragen reaktionsfähig bleiben.
Das Downsampling alter Daten ist eine unvermeidliche Anforderung jeder Langzeitspeicherlösung und geht über den Rahmen von Vanilla Prometheus hinaus.
Zusätzliche Ziele
Eines der ursprünglichen Ziele des Thanos-Projekts war die nahtlose Integration in alle bestehenden Prometheus-Installationen. Das zweite Ziel war eine einfache Bedienung mit minimalen Eintrittsbarrieren. Etwaige Abhängigkeiten sollten sowohl für kleine als auch für große Benutzer problemlos erfüllt werden können, was auch niedrige Grundkosten bedeutet.
Thanos-Architektur
Nachdem wir unsere Ziele im vorherigen Abschnitt aufgeführt haben, wollen wir sie nun durchgehen und sehen, wie Thanos diese Probleme löst.
Globale Sicht
Um einen globalen Überblick über bestehende Prometheus-Instanzen zu erhalten, müssen wir einen einzelnen Anforderungseinstiegspunkt mit allen Servern verknüpfen. Genau das macht die Thanos-Komponente. . Es wird neben jedem Prometheus-Server bereitgestellt und fungiert als Proxy und stellt lokale Prometheus-Daten über die gRPC Store API bereit, sodass Zeitreihendaten nach Tag und Zeitbereich abgerufen werden können.
Auf der anderen Seite steht die skalierbare, zustandslose Querier-Komponente, die kaum mehr kann, als nur PromQL-Anfragen über die Standard-Prometheus-HTTP-API zu beantworten. Querier, Sidecar und andere Thanos-Komponenten kommunizieren über .
- Querier verbindet sich nach Erhalt einer Anfrage mit dem entsprechenden Store-API-Server, also mit unseren Sidecars, und empfängt Zeitreihendaten von den entsprechenden Prometheus-Servern.
- Anschließend werden die Antworten kombiniert und eine PromQL-Abfrage darauf ausgeführt. Querier kann sowohl disjunkte Daten als auch doppelte Daten von Prometheus HA-Servern zusammenführen.
Damit ist ein wichtiger Teil unseres Puzzles gelöst – die Kombination von Daten von isolierten Prometheus-Servern in einer einzigen Ansicht. Tatsächlich kann Thanos nur für diese Funktion verwendet werden. An bestehenden Prometheus-Servern müssen keine Änderungen vorgenommen werden!
Unbegrenzte Haltbarkeit!
Früher oder später werden wir jedoch Daten über die normale Prometheus-Aufbewahrungsdauer hinaus speichern wollen. Wir haben uns für Objektspeicher entschieden, um historische Daten zu speichern. Es ist in jeder Cloud sowie in lokalen Rechenzentren weit verbreitet und sehr kostengünstig. Darüber hinaus ist nahezu jeder Objektspeicher über die bekannte S3-API verfügbar.
Prometheus schreibt etwa alle zwei Stunden Daten vom RAM auf die Festplatte. Der gespeicherte Datenblock enthält alle Daten für einen festgelegten Zeitraum und ist unveränderlich. Dies ist sehr praktisch, da Thanos Sidecar einfach das Prometheus-Datenverzeichnis einsehen und diese in Objektspeicher-Buckets laden kann, sobald neue Blöcke verfügbar werden.
Durch das Laden in den Objektspeicher unmittelbar nach dem Schreiben auf die Festplatte können Sie auch die Einfachheit des Scrapers (Prometheus und Thanos Sidecar) beibehalten. Das vereinfacht Support, Kosten und Systemdesign.
Wie Sie sehen, ist die Datensicherung sehr einfach. Aber wie sieht es mit der Abfrage von Daten im Objektspeicher aus?
Die Thanos Store-Komponente fungiert als Proxy zum Abrufen von Daten aus dem Objektspeicher. Wie Thanos Sidecar nimmt es am Gossip-Cluster teil und implementiert die Store API. Auf diese Weise kann es vom vorhandenen Querier wie ein Sidecar als weitere Quelle für Zeitreihendaten behandelt werden – es ist keine spezielle Konfiguration erforderlich.
Zeitreihendatenblöcke bestehen aus mehreren großen Dateien. Sie bei Bedarf zu laden wäre ziemlich ineffizient und das lokale Zwischenspeichern würde eine große Menge an Arbeitsspeicher und Festplattenspeicher erfordern.
Stattdessen weiß Store Gateway, wie mit dem Prometheus-Speicherformat umzugehen ist. Dank eines intelligenten Abfrageplaners und der Zwischenspeicherung nur der notwendigen Indexteile von Blöcken ist es möglich, komplexe Abfragen auf eine minimale Anzahl von HTTP-Anfragen an Objektspeicherdateien zu reduzieren. Auf diese Weise können Sie die Anzahl der Anfragen um vier bis sechs Größenordnungen reduzieren und Antwortzeiten erreichen, die in der Regel nur schwer von Anfragen an Daten auf einer lokalen SSD zu unterscheiden sind.
Wie im Diagramm oben gezeigt, reduziert Thanos Querier die Kosten pro Abfrage von Objektspeicherdaten erheblich, indem es das Prometheus-Speicherformat nutzt und verwandte Daten nebeneinander platziert. Mit diesem Ansatz können wir viele einzelne Anfragen zu einer minimalen Anzahl von Massenvorgängen zusammenfassen.
Komprimierung und Downsampling
Sobald ein neuer Block von Zeitreihendaten erfolgreich in den Objektspeicher geladen wurde, behandeln wir ihn als „historische“ Daten, die sofort über das Store Gateway verfügbar sind.
Nach einiger Zeit sammeln sich jedoch Blöcke aus einer Quelle (Prometheus mit Sidecar) an und nutzen nicht mehr das volle Indizierungspotenzial. Um dieses Problem zu lösen, haben wir eine weitere Komponente namens Compactor eingeführt. Es wendet einfach die lokale Komprimierungs-Engine von Prometheus auf historische Daten im Objektspeicher an und kann als einfacher periodischer Batch-Job ausgeführt werden.
Dank effizienter Komprimierung stellt die Abfrage des Speichers über einen längeren Zeitraum kein Problem hinsichtlich der Datengröße dar. Allerdings führen die potenziellen Kosten für das Entpacken einer Milliarde Werte und deren Ausführung durch einen Abfrageprozessor unweigerlich zu einem dramatischen Anstieg der Abfrageausführungszeit. Da es andererseits Hunderte von Datenpunkten pro Pixel auf dem Bildschirm gibt, ist es unmöglich, die Daten überhaupt in voller Auflösung anzuzeigen. Somit ist ein Downsampling nicht nur möglich, sondern führt auch nicht zu einem spürbaren Genauigkeitsverlust.
Um Daten herunterzurechnen, aggregiert Compactor die Daten kontinuierlich mit einer Auflösung von fünf Minuten und einer Stunde. Für jeden mit TSDB-XOR-Komprimierung codierten Rohblock werden verschiedene Arten von Aggregatdaten gespeichert, z. B. Min., Max. oder Summe für einen Block. Dadurch kann Querier automatisch ein Aggregat auswählen, das für eine bestimmte PromQL-Abfrage geeignet ist.
Es ist keine spezielle Konfiguration erforderlich, damit der Benutzer Daten mit reduzierter Präzision verwenden kann. Querier wechselt automatisch zwischen verschiedenen Auflösungen und Rohdaten, wenn der Benutzer hinein- und herauszoomt. Auf Wunsch kann der Benutzer dies direkt über den Parameter „step“ in der Anfrage steuern.
Da die Kosten für die Speicherung von einem GB gering sind, speichert Thanos standardmäßig Rohdaten sowie Daten mit einer Auflösung von fünf Minuten und einer Stunde. Es besteht keine Notwendigkeit, die Originaldaten zu löschen.
Aufnahmeregeln
Auch bei Thanos sind Aufnahmeregeln ein wesentlicher Bestandteil des Überwachungsstapels. Sie reduzieren die Komplexität, Latenz und Kosten von Abfragen. Sie sind für Benutzer auch praktisch, um aggregierte Daten nach Metriken zu erhalten. Thanos basiert auf Vanilla-Prometheus-Instanzen, daher ist es durchaus akzeptabel, Aufzeichnungsregeln und Alarmierungsregeln auf einem vorhandenen Prometheus-Server zu speichern. In einigen Fällen reicht dies jedoch möglicherweise nicht aus:
- Globale Warnung und Regel (z. B. eine Warnung, wenn ein Dienst auf mehr als zwei von drei Clustern nicht funktioniert).
- Regel für Daten außerhalb des lokalen Speichers.
- Der Wunsch, alle Regeln und Warnungen an einem Ort zu speichern.
Für alle diese Fälle enthält Thanos eine separate Komponente namens Ruler, die Regeln und Warnungen über Thanos-Abfragen berechnet. Durch die Bereitstellung einer bekannten StoreAPI kann der Abfrageknoten auf frisch berechnete Metriken zugreifen. Später werden sie auch im Objektspeicher abgelegt und über das Store Gateway zur Verfügung gestellt.
Die Macht von Thanos
Thanos ist flexibel genug, um es an Ihre Bedürfnisse anzupassen. Dies ist besonders nützlich, wenn Sie vom einfachen Prometheus migrieren. Lassen Sie uns anhand eines kurzen Beispiels kurz zusammenfassen, was wir über Thanos-Komponenten gelernt haben. So entführen Sie Ihren Vanilla Prometheus in die Welt des „unbegrenzten Messwertspeichers“:
- Fügen Sie Thanos Sidecar zu Ihren Prometheus-Servern hinzu – zum Beispiel einen Sidecar-Container in einem Kubernetes-Pod.
- Stellen Sie mehrere Replikate von Thanos Querier bereit, um Daten anzeigen zu können. In dieser Phase kann es leicht zu Klatsch und Tratsch zwischen Scraper und Querier kommen. Um das Zusammenspiel von Komponenten zu überprüfen, verwenden Sie die Metrik „thanos_cluster_members“.
Allein diese beiden Schritte reichen aus, um eine globale Ansicht und eine nahtlose Datendeduplizierung von potenziellen Prometheus HA-Repliken zu ermöglichen! Verbinden Sie Ihre Dashboards einfach mit dem Querier-HTTP-Endpunkt oder verwenden Sie direkt die Thanos-Benutzeroberfläche.
Wenn Sie jedoch eine Datensicherung und Langzeitspeicherung benötigen, 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. Die lokale Datenspeicherung kann nun minimiert werden.
- Stellen Sie Store Gateway bereit und verbinden Sie es mit Ihrem bestehenden Gossip-Cluster. Jetzt können Sie die gesicherten Daten abfragen!
- Setzen Sie Compactor ein, um die Abfrageeffizienz über lange Zeiträume durch Komprimierung und Downsampling zu verbessern.
Wenn Sie mehr wissen möchten, werfen Sie einen Blick auf unsere и !
In nur fünf Schritten haben wir Prometheus in ein zuverlässiges Überwachungssystem mit globaler Sicht, unbegrenzter Speicherzeit und potenziell hoher Verfügbarkeit von Metriken verwandelt.
Pull-Request: Wir brauchen Dich!
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 mühelose Skalierung Ihres Überwachungssystems.
Wir freuen uns immer über GitHub-Pull-Anfragen und -Probleme. In der Zwischenzeit können Sie uns gerne über Github Issues oder Slack kontaktierenWenn Sie Fragen oder Feedback haben oder Ihre Erfahrungen damit teilen möchten! Wenn Ihnen gefällt, was wir bei Improbable tun, zögern Sie nicht, uns zu kontaktieren – !
Source: habr.com