Die Übersetzung des Artikels wurde speziell für die Studierenden des Kurses erstellt. .
— Softwareentwickler, Go-Enthusiast und leidenschaftlicher Problemlöser. Er ist auch Maintainer von Prometheus und Mitbegründer von Kubernetes SIG Instrumentation. Zuvor war er Production Engineer bei SoundCloud und leitete die Monitoring-Gruppe bei CoreOS. Aktuell arbeitet er bei Google.
— Infrastruktur-Ingenieur bei Improbable. Begeistert sich für neue Technologien und Herausforderungen in verteilten Systemen. Er hat Erfahrung im Low-Level-Programmieren bei Intel, war Contributor bei Mesos und verfügt über globale SRE-Praxis bei Improbable. Er verbessert die Welt der Mikrodienste. Seine drei Leidenschaften: Golang, Open Source und Volleyball.
Wenn Sie unser Flaggschiff-Produkt SpatialOS betrachten, können Sie erraten, dass Improbable eine hochdynamische Cloud-Infrastruktur globaler Maßstäbe mit Dutzenden von Kubernetes-Clustern benötigt. Wir gehörten zu den ersten, die ein Überwachungssystem einführten . Prometheus kann Millionen von Metriken in Echtzeit überwachen und wird mit einer mächtigen Abfragesprache geliefert, mit der die benötigten Informationen abgerufen werden können.
Die Einfachheit und Zuverlässigkeit von Prometheus ist eines seiner Hauptmerkmale. Sobald jedoch eine bestimmte Skalierung erreicht ist, sind einige Nachteile aufgetreten. Um diese Probleme zu lösen, haben wir — ein Open-Source-Projekt von Improbable, das einen nahtlosen Übergang bestehender Prometheus-Cluster zu einem einheitlichen Monitoring-System mit unbegrenztem Speicher für historische Daten ermöglicht. Thanos ist auf Github verfügbar. .
Unsere Ziele mit Thanos
Bei einer bestimmten Skalierung treten Probleme auf, die über die Möglichkeiten von Vanilla-Prometheus hinausgehen. Wie kann man Petabytes historischer Daten zuverlässig und kosteneffektiv speichern? Ist das möglich, ohne die Antwortzeiten von Abfragen zu beeinträchtigen? Kann man auf alle Metriken, die sich auf verschiedenen Prometheus-Servern befinden, mit einer einzigen API-Anfrage zugreifen? Gibt es eine Möglichkeit, replizierte Daten, die mit Prometheus HA gesammelt wurden, zu konsolidieren?
Um diese Fragen zu beantworten, haben wir Thanos entwickelt. In den folgenden Abschnitten beschreiben wir, wie wir diese Herausforderungen angegangen sind und erläutern die Ziele, die wir verfolgt haben.
Datenanfrage von mehreren Prometheus-Instanzen (globale Abfrage)
Prometheus bietet einen funktionalen Ansatz zum Sharding. Selbst ein einzelner Prometheus-Server gewährleistet ausreichende Skalierbarkeit, um die Benutzer von den Komplikationen des horizontalen Shardings in nahezu allen Nutzungsszenarien zu befreien.
Obwohl dies ein hervorragendes Bereitstellungsmodell ist, wird oft der Zugang zu Daten auf verschiedenen Prometheus-Servern über eine einheitliche API oder UI benötigt – die globale Ansicht. Natürlich können mehrere Abfragen in einem Grafana-Panel angezeigt werden, jedoch kann jede Abfrage nur auf einem Prometheus-Server ausgeführt werden. Mit Thanos hingegen können Sie Daten von mehreren Prometheus-Servern abrufen und aggregieren, da alle über einen einzigen Endpunkt zugänglich sind.
Früher, um eine globale Ansicht in Improbable zu erhalten, organisierten wir unsere Prometheus-Instanzen in einer mehrstufigen . Dies bedeutete, einen Meta-Server von Prometheus zu erstellen, der einen Teil der Metriken von jedem "Blatt"-Server sammelt.
Dieser Ansatz hat sich als problematisch erwiesen. Er führte zu einer komplizierten Konfiguration, einer zusätzlichen potenziellen Fehlerquelle und zur Anwendung komplexer Regeln, um der federierten Endpunkt nur die benötigten Daten zur Verfügung zu stellen. Außerdem ermöglicht eine solche Federation keine echte globale Ansicht, da nicht alle Daten aus einer einzigen API-Anfrage verfügbar sind.
Dies steht in engem Zusammenhang mit der einheitlichen Darstellung von Daten, die auf hochverfügbaren (High-Availability, HA) Prometheus-Servern gesammelt werden. Das HA-Modell von Prometheus sammelt die Daten unabhängig zweimal, was so einfach ist, dass es nicht einfacher sein könnte. Es wäre jedoch viel praktischer, eine kombinierte und deduplizierte Darstellung beider Datenströme zu verwenden.
Ein hochverfügbares Server-Setup für Prometheus ist von entscheidender Bedeutung. Bei Improbable nehmen wir das dauerhafte Monitoring der Daten sehr ernst, jedoch stellt ein einzelner Prometheus-Instanz in einem Cluster einen Ausfallpunkt dar. Jeder Konfigurationsfehler oder Hardwareausfall kann potenziell zum Verlust wichtiger Daten führen. Selbst ein einfaches Deployment kann zu kleinen Unterbrechungen im Metriksammeln führen, da ein Neustart deutlich länger als der Scraping-Intervall dauern kann.
Zuverlässige Speicherung historischer Daten
Eine kostengünstige, schnelle und langfristige Speicherung von Metriken ist unser Traum (und der vieler Prometheus-Anwender). Bei Improbable waren wir gezwungen, den Metrikspeicherzeitraum auf neun Tage (für Prometheus 1.8) einzustellen. Dies setzt uns offensichtliche Grenzen, wie weit wir in die Vergangenheit blicken können.
Prometheus 2.0 ist in dieser Hinsicht besser geworden, da die Anzahl der Zeitserien nicht mehr die Gesamtleistung des Servers beeinträchtigt (siehe ). Dennoch speichert Prometheus Daten auf der lokalen Festplatte. Obwohl eine hochgradig effiziente Datenkompression die Nutzung des lokalen SSD erheblich reduzieren kann, gibt es letztendlich dennoch eine Begrenzung für die Menge der speicherbaren historischen Daten.
Darüber hinaus kümmern wir uns bei Improbable um Zuverlässigkeit, Einfachheit und Kosten. Große lokale Festplatten sind schwieriger zu handhaben und zu sichern. Sie sind teurer und erfordern mehr Werkzeuge für Backups, was zu übermäßiger Komplexität führt.
Downsampling
Sobald wir begannen, mit historischen Daten zu arbeiten, wurde uns bewusst, dass es grundlegende Herausforderungen im Zusammenhang mit O-Notation gibt, die Anfragen immer langsamer machen, wenn wir mit Daten über Wochen, Monate und Jahre arbeiten.
Eine Standardlösung für dieses Problem wäre (Downsampling) – die Reduktion der Abtastrate eines Signals. Durch die Absenkung der Abtastrate können wir den „Maßstab“ auf einen größeren Zeitbereich reduzieren und die Anzahl der Proben beibehalten, was die Reaktionsfähigkeit der Anfragen bewahrt.
Das Herunterrechnen alter Daten ist eine unvermeidliche Anforderung jeder langfristigen Speichlösung und geht über die Standardfunktionen von Prometheus hinaus.
Zusätzliche Ziele
Eines der ursprünglichen Ziele des Thanos-Projekts war die nahtlose Integration mit bestehenden Prometheus-Installationen. Ein weiteres Ziel war die erleichterte Nutzung mit minimalem Zugangshindernis. Alle Abhängigkeiten sollten sowohl für kleine als auch für große Benutzer leicht erfüllbar sein, was auch eine geringe Grundkosteneinbeziehung bedeutet.
Thanos-Architektur
Nachdem wir die Ziele im vorherigen Abschnitt aufgelistet haben, wollen wir uns diesen widmen und sehen, wie Thanos diese Herausforderungen bewältigt.
Globale Ansicht
Um eine globale Ansicht über bestehende Prometheus-Instanzen zu erhalten, müssen wir einen einheitlichen Einstiegspunkt für Anfragen mit allen Servern verknüpfen. Genau das übernimmt die Thanos-Komponente. . Es wird neben jedem Prometheus-Server bereitgestellt und fungiert als Proxy, der lokale Prometheus-Daten über die gRPC-Schnittstelle des Store API bereitstellt, wodurch das Abfragen von Zeitreihendaten nach Labels und Zeitbereichen ermöglicht wird.
Auf der anderen Seite steht die horizontal skalierbare Querier-Komponente ohne Zustandsspeicherung, die etwas mehr tut, als nur auf PromQL-Anfragen über die standardmäßige Prometheus HTTP API zu antworten. Die Komponenten Querier, Sidecar und andere Thanos interagieren über .
- Wenn der Querier eine Anfrage erhält, verbindet er sich mit dem entsprechenden Store API-Server, also unseren Sidecar-Komponenten, und erhält Zeitreihendaten von den entsprechenden Prometheus-Servern.
- Anschließend kombiniert er die Antworten und führt die PromQL-Anfrage aus. Der Querier kann sowohl nicht überlappende Daten als auch duplizierte Daten von HA-Prometheus-Servern zusammenführen.
Dadurch lösen wir den Hauptteil unseres Puzzles – das Zusammenführen von Daten von isolierten Prometheus-Servern in eine einheitliche Ansicht. Tatsächlich kann Thanos nur für diese Funktionalität verwendet werden. Es sind keine Änderungen an bestehenden Prometheus-Servern erforderlich!
Unbegrenzte Speicherfrist!
Früher oder später möchten wir jedoch Daten speichern, die über die übliche Aufbewahrungszeit von Prometheus hinausgehen. Für die Speicherung historischer Daten haben wir ein Objektspeicher gewählt. Dieser ist in jeder Cloud sowie in lokalen Rechenzentren weit verbreitet und sehr kostengünstig. Darüber hinaus ist praktisch jeder Objektspeicher über das bekannte S3-API zugänglich.
Prometheus schreibt Daten etwa alle zwei Stunden aus dem Arbeitsspeicher auf die Festplatte. Der Block gespeicherter Daten enthält alle Daten für einen festen Zeitraum und ist unveränderlich. Das ist sehr praktisch, da der Thanos Sidecar einfach das Prometheus-Datenverzeichnis überwachen und bei Erscheinen neuer Blöcke diese in die Objektspeicher-Buckets hochladen kann.
Die Speicherung im Objektspeicher sofort nach der Aufzeichnung auf die Festplatte ermöglicht auch eine Vereinfachung des Scrapers (Prometheus und Thanos Sidecar). Das erleichtert die Wartung, die Kosten und das Design des Systems.
Wie Sie sehen, ist die Datensicherung sehr einfach zu realisieren. Aber wie sieht es mit der Abfrage von Daten im Objektspeicher aus?
Die Thanos Store-Komponente fungiert als Proxy für den Zugriff auf Daten aus dem Objektspeicher. Ähnlich wie der Thanos Sidecar ist sie Teil des Gossip-Clusters und implementiert die Store API. So können bestehende Querier sie als Sidecar betrachten, als eine weitere Quelle für Zeitreihendaten – es sind keine speziellen Konfigurationen erforderlich.
Die Blöcke der Zeitreihendaten bestehen aus mehreren großen Dateien. Eine bedarfsorientierte Bereitstellung wäre ziemlich ineffizient, und lokale Caches würden enorme Mengen an Speicher und Festplattenspeicher erfordern.
Stattdessen weiß das Store Gateway, wie es mit dem Speicherformat von Prometheus umgeht. Dank eines intelligenten Anfrageplaners und der Caching-Mechanismen, die nur die benötigten Indexpunkte der Blöcke speichern, konnten komplexe Anfragen auf ein Minimum an HTTP-Anfragen an die Objektspeicherdateien reduziert werden. Dadurch lässt sich die Anzahl der Anfragen um vier bis sechs Größenordnungen verringern, und es wird eine Reaktionszeit erreicht, die insgesamt schwer von der Abfrage von Daten auf einem lokalen SSD zu unterscheiden ist.
Wie in der oben stehenden Grafik dargestellt, reduziert Thanos Querier die Kosten für eine Abfrage an Speicherdaten erheblich, indem es das Prometheus-Speicherformat verwendet und verwandte Daten nahe beieinander platziert. Durch diesen Ansatz können wir zahlreiche Einzelabfragen in eine minimalistische Anzahl von Bulk-Operationen bündeln.
Verdichtung und Downsampling
Sobald ein neuer Block von Zeitreihendaten erfolgreich in den Objektspeicher geladen wurde, betrachten 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 das volle Potenzial der Indizierung nicht mehr aus. Um dieses Problem zu lösen, haben wir eine weitere Komponente namens Compactor eingeführt. Diese wendet einfach den lokalen Verdichtungsmechanismus von Prometheus auf die historischen Daten im Objektspeicher an und kann als einfaches, periodisches Batch-Job ausgeführt werden.
Dank effizienter Kompression stellt eine langanhaltende Abfrage im Speicher hinsichtlich der Datengröße kein Problem dar. Allerdings wird die potenzielle Kosten für das Entpacken von Milliarden von Werten und das Durchlaufen dieser durch den Abfrage-Handler unweigerlich zu einem drastischen Anstieg der Ausführungszeit führen. Andererseits, da jedem Pixel auf dem Bildschirm Hunderte von Datenpunkten zugeordnet sind, wird es unmöglich, die Daten in voller Auflösung zu visualisieren. Daher ist das Downsampling nicht nur möglich, sondern führt auch nicht zu einem merklichen Verlust an Genauigkeit.
Für das Downsampling aggregiert Compactor kontinuierlich Daten mit einer Auflösung von fünf Minuten und einer Stunde. Für jedes unbearbeitete Fragment, das mit TSDB XOR-Kompression kodiert wurde, werden verschiedene Typen aggregierter Daten gespeichert, wie zum Beispiel min, max oder sum für einen Block. Dies ermöglicht es dem Querier, automatisch das Aggregat auszuwählen, das für die jeweilige PromQL-Abfrage geeignet ist.
Um Daten mit geringerer Genauigkeit zu verwenden, benötigt der Benutzer keine spezielle Konfiguration. Querier wechselt automatisch zwischen verschiedenen Auflösungen und unbearbeiteten Daten, während 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 die Originaldaten sowie Daten mit einer Auflösung von fünf Minuten und einer Stunde. Es ist nicht erforderlich, die Originaldaten zu löschen.
Recording-Regeln
Selbst mit Thanos sind Recording-Regeln ein wesentlicher Bestandteil des Monitoring-Stacks. Sie reduzieren die Komplexität, die Latenz und die Kosten von Abfragen. Zudem sind sie nützlich für Benutzer, um aggregierte Daten zu Metriken zu erhalten. Thanos basiert auf Vanilla-Instanzen von Prometheus, daher ist es durchaus zulässig, Recording- und Alerting-Regeln auf einem bestehenden Prometheus-Server zu speichern. In einigen Fällen kann dies jedoch unzureichend sein:
- Globale Alerts und Regeln (z. B. Benachrichtigung, wenn der Dienst auf mehr als zwei von drei Clustern nicht funktioniert).
- Regel für Daten außerhalb des lokalen Speichers.
- Das Bestreben, alle Regeln und Warnungen an einem Ort zu speichern.
Für all diese Fälle umfasst Thanos ein separates Modul namens Ruler, das Regeln und Warnungen über Thanos Queries berechnet. Durch die weit bekannte StoreAPI kann der Query-Knoten auf frisch berechnete Metriken zugreifen. Diese werden später auch im Objektspeicher gespeichert und sind über den Store Gateway verfügbar.
Die Leistung von Thanos
Thanos ist flexibel genug, um an Ihre Anforderungen angepasst zu werden. Dies ist besonders hilfreich bei der Migration von einem einfachen Prometheus. Lassen Sie uns an einem kleinen Beispiel schnell wiederholen, was wir über die Komponenten von Thanos gelernt haben. So übertragen Sie Ihr einfaches Prometheus in die Welt der „unbegrenzten Metrikspeicherung“:
- Fügen Sie Thanos Sidecar zu Ihren Prometheus-Servern hinzu – beispielsweise als benachbarten Container im Kubernetes-Pod.
- Setzen Sie mehrere Replicas von Thanos Querier ein, um Daten anzeigen zu können. In diesem Schritt ist es einfach, Gossip zwischen Scraper und Querier einzurichten. Zur Überprüfung der Interaktion der Komponenten verwenden Sie die Metrik ‚thanos_cluster_members‘.
Nur diese beiden Schritte sind erforderlich, um eine globale Sicht und nahtlose Daten-Reduzierung von potenziellen HA-Replikaten in Prometheus sicherzustellen! Verbinden Sie einfach Ihre Dashboards mit dem HTTP-Querier-Endpunkt oder verwenden Sie die Thanos UI direkt.
Wenn Sie jedoch eine Sicherung der Metriken und eine langfristige Speicherung benötigen, müssen Sie drei weitere Schritte ausführen:
- Erstellen Sie einen Bucket in AWS S3 oder GCS. Richten Sie den Sidecar ein, um Daten in diese Buckets zu kopieren. Damit können Sie die lokale Datenspeicherung minimieren.
- Implementieren Sie das Store Gateway und verbinden Sie es mit dem bestehenden Gossip-Cluster. Jetzt können Sie Anfragen an die Daten in den Backups senden!
- Setzen Sie den Compactor ein, um die Effizienz der Abfragen über längere Zeiträume hinweg durch Verdichtung und Downsampling zu steigern.
Wenn Sie mehr erfahren möchten, schauen Sie sich gerne unsere und !
In nur fünf Schritten haben wir Prometheus in ein zuverlässiges Überwachungssystem mit globaler Sicht, unbegrenzter Speicherdauer und potenzieller hoher Verfügbarkeit der Metriken verwandelt.
Pull-Request: Wir brauchen Sie!
Von Anfang an war es 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 skalierbare Systemüberwachung ohne unnötige Komplikationen.
Wir freuen uns immer über GitHub Pull Requests und Issues. Zögern Sie nicht, uns über GitHub Issues oder Slack zu kontaktieren, wenn Sie Fragen oder Feedback haben oder Ihre Erfahrungen teilen möchten., falls Sie Fragen oder Anregungen haben oder Ihre Erfahrungen mit uns teilen möchten! Wenn Ihnen gefällt, was wir bei Improbable tun, zögern Sie nicht, uns zu kontaktieren — !
Quelle: habr.com
