{"id":81888,"date":"2020-05-17T13:42:23","date_gmt":"2020-05-17T11:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus"},"modified":"2020-05-17T13:42:23","modified_gmt":"2020-05-17T11:42:23","slug":"thanos-masshtabiruemyj-prometheus","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/thanos-masshtabiruemyj-prometheus","title":{"rendered":"Thanos \u2014 skalierbarer Prometheus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die \u00dcbersetzung des Artikels wurde speziell f\u00fcr die Studierenden des Kurses erstellt. \u201eDevOps-Praktiken und Werkzeuge\u201c<\/a><\/noindex>.<\/i><\/b><\/p>\n

\nFabian Reinartz<\/a><\/noindex> \u2014 Softwareentwickler, Go-Enthusiast und leidenschaftlicher Probleml\u00f6ser. Er ist auch Maintainer von Prometheus und Mitbegr\u00fcnder von Kubernetes SIG Instrumentation. Zuvor war er Production Engineer bei SoundCloud und leitete die Monitoring-Gruppe bei CoreOS. Aktuell arbeitet er bei Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 Infrastruktur-Ingenieur bei Improbable. Begeistert sich f\u00fcr neue Technologien und Herausforderungen in verteilten Systemen. Er hat Erfahrung im Low-Level-Programmieren bei Intel, war Contributor bei Mesos und verf\u00fcgt \u00fcber globale SRE-Praxis bei Improbable. Er verbessert die Welt der Mikrodienste. Seine drei Leidenschaften: Golang, Open Source und Volleyball.<\/i><\/p>\n

Wenn Sie unser Flaggschiff-Produkt SpatialOS betrachten, k\u00f6nnen Sie erraten, dass Improbable eine hochdynamische Cloud-Infrastruktur globaler Ma\u00dfst\u00e4be mit Dutzenden von Kubernetes-Clustern ben\u00f6tigt. Wir geh\u00f6rten zu den ersten, die ein \u00dcberwachungssystem einf\u00fchrten Prometheus<\/a><\/noindex>. Prometheus kann Millionen von Metriken in Echtzeit \u00fcberwachen und wird mit einer m\u00e4chtigen Abfragesprache geliefert, mit der die ben\u00f6tigten Informationen abgerufen werden k\u00f6nnen.<\/p>\n

Die Einfachheit und Zuverl\u00e4ssigkeit von Prometheus ist eines seiner Hauptmerkmale. Sobald jedoch eine bestimmte Skalierung erreicht ist, sind einige Nachteile aufgetreten. Um diese Probleme zu l\u00f6sen, haben wir Thanos<\/a><\/noindex> \u2014 ein Open-Source-Projekt von Improbable, das einen nahtlosen \u00dcbergang bestehender Prometheus-Cluster zu einem einheitlichen Monitoring-System mit unbegrenztem Speicher f\u00fcr historische Daten erm\u00f6glicht. Thanos ist auf Github verf\u00fcgbar. hier<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Bleiben Sie \u00fcber die neuesten Nachrichten von Improbable informiert.<\/a><\/noindex><\/p>\n

Unsere Ziele mit Thanos<\/h2>\n

\nBei einer bestimmten Skalierung treten Probleme auf, die \u00fcber die M\u00f6glichkeiten von Vanilla-Prometheus hinausgehen. Wie kann man Petabytes historischer Daten zuverl\u00e4ssig und kosteneffektiv speichern? Ist das m\u00f6glich, ohne die Antwortzeiten von Abfragen zu beeintr\u00e4chtigen? Kann man auf alle Metriken, die sich auf verschiedenen Prometheus-Servern befinden, mit einer einzigen API-Anfrage zugreifen? Gibt es eine M\u00f6glichkeit, replizierte Daten, die mit Prometheus HA gesammelt wurden, zu konsolidieren?<\/p>\n

Um diese Fragen zu beantworten, haben wir Thanos entwickelt. In den folgenden Abschnitten beschreiben wir, wie wir diese Herausforderungen angegangen sind und erl\u00e4utern die Ziele, die wir verfolgt haben.<\/p>\n

Datenanfrage von mehreren Prometheus-Instanzen (globale Abfrage)<\/h4>\n

\nPrometheus bietet einen funktionalen Ansatz zum Sharding. Selbst ein einzelner Prometheus-Server gew\u00e4hrleistet ausreichende Skalierbarkeit, um die Benutzer von den Komplikationen des horizontalen Shardings in nahezu allen Nutzungsszenarien zu befreien.<\/p>\n

Obwohl dies ein hervorragendes Bereitstellungsmodell ist, wird oft der Zugang zu Daten auf verschiedenen Prometheus-Servern \u00fcber eine einheitliche API oder UI ben\u00f6tigt \u2013 die globale Ansicht. Nat\u00fcrlich k\u00f6nnen mehrere Abfragen in einem Grafana-Panel angezeigt werden, jedoch kann jede Abfrage nur auf einem Prometheus-Server ausgef\u00fchrt werden. Mit Thanos hingegen k\u00f6nnen Sie Daten von mehreren Prometheus-Servern abrufen und aggregieren, da alle \u00fcber einen einzigen Endpunkt zug\u00e4nglich sind.<\/p>\n

Fr\u00fcher, um eine globale Ansicht in Improbable zu erhalten, organisierten wir unsere Prometheus-Instanzen in einer mehrstufigen Hierarchischen F\u00f6deration<\/a><\/noindex>. Dies bedeutete die Erstellung eines Meta-Servers f\u00fcr Prometheus, der eine Reihe von Metriken von jedem \u201eLeaf\u201c-Server sammelt.<\/p>\n

\"Thanos
\n
\nDieser Ansatz hat sich als problematisch erwiesen. Er f\u00fchrte zu einer komplizierten Konfiguration, einer zus\u00e4tzlichen potenziellen Fehlerquelle und zur Anwendung komplexer Regeln, um der federierten Endpunkt nur die ben\u00f6tigten Daten zur Verf\u00fcgung zu stellen. Au\u00dferdem erm\u00f6glicht eine solche Federation keine echte globale Ansicht, da nicht alle Daten aus einer einzigen API-Anfrage verf\u00fcgbar sind.<\/p>\n

Dies steht in engem Zusammenhang mit der einheitlichen Darstellung von Daten, die auf hochverf\u00fcgbaren (High-Availability, HA) Prometheus-Servern gesammelt werden. Das HA-Modell von Prometheus sammelt die Daten unabh\u00e4ngig zweimal, was so einfach ist, dass es nicht einfacher sein k\u00f6nnte. Es w\u00e4re jedoch viel praktischer, eine kombinierte und deduplizierte Darstellung beider Datenstr\u00f6me zu verwenden.<\/p>\n

Ein hochverf\u00fcgbares Server-Setup f\u00fcr 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\u00fchren. Selbst ein einfaches Deployment kann zu kleinen Unterbrechungen im Metriksammeln f\u00fchren, da ein Neustart deutlich l\u00e4nger als der Scraping-Intervall dauern kann.<\/p>\n

Zuverl\u00e4ssige Speicherung historischer Daten<\/h4>\n

\nEine kosteng\u00fcnstige, 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\u00fcr Prometheus 1.8) einzustellen. Dies setzt uns offensichtliche Grenzen, wie weit wir in die Vergangenheit blicken k\u00f6nnen.<\/p>\n

Prometheus 2.0 ist in dieser Hinsicht besser geworden, da die Anzahl der Zeitserien nicht mehr die Gesamtleistung des Servers beeintr\u00e4chtigt (siehe die KubeCon-Hauptrede \u00fcber Prometheus 2)<\/a><\/noindex>). 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\u00fcr die Menge der speicherbaren historischen Daten.<\/p>\n

Dar\u00fcber hinaus k\u00fcmmern wir uns bei Improbable um Zuverl\u00e4ssigkeit, Einfachheit und Kosten. Gro\u00dfe lokale Festplatten sind schwieriger zu handhaben und zu sichern. Sie sind teurer und erfordern mehr Werkzeuge f\u00fcr Backups, was zu \u00fcberm\u00e4\u00dfiger Komplexit\u00e4t f\u00fchrt.<\/p>\n

Downsampling<\/h4>\n

\nSobald 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 \u00fcber Wochen, Monate und Jahre arbeiten.<\/p>\n

Eine Standardl\u00f6sung f\u00fcr dieses Problem w\u00e4re Downsampling<\/a><\/noindex> (Downsampling) \u2013 die Reduktion der Abtastrate eines Signals. Durch die Absenkung der Abtastrate k\u00f6nnen wir den \u201eMa\u00dfstab\u201c auf einen gr\u00f6\u00dferen Zeitbereich reduzieren und die Anzahl der Proben beibehalten, was die Reaktionsf\u00e4higkeit der Anfragen bewahrt.<\/p>\n

Das Herunterrechnen alter Daten ist eine unvermeidliche Anforderung jeder langfristigen Speichl\u00f6sung und geht \u00fcber die Standardfunktionen von Prometheus hinaus.<\/p>\n

Zus\u00e4tzliche Ziele<\/h4>\n

\nEines der urspr\u00fcnglichen Ziele des Thanos-Projekts war die nahtlose Integration mit bestehenden Prometheus-Installationen. Ein weiteres Ziel war die erleichterte Nutzung mit minimalem Zugangshindernis. Alle Abh\u00e4ngigkeiten sollten sowohl f\u00fcr kleine als auch f\u00fcr gro\u00dfe Benutzer leicht erf\u00fcllbar sein, was auch eine geringe Grundkosteneinbeziehung bedeutet.<\/p>\n

Thanos-Architektur<\/h2>\n

\nNachdem wir die Ziele im vorherigen Abschnitt aufgelistet haben, wollen wir uns diesen widmen und sehen, wie Thanos diese Herausforderungen bew\u00e4ltigt.<\/p>\n

Globale Ansicht<\/h4>\n

\nUm eine globale Ansicht \u00fcber bestehende Prometheus-Instanzen zu erhalten, m\u00fcssen wir einen einheitlichen Einstiegspunkt f\u00fcr Anfragen mit allen Servern verkn\u00fcpfen. Genau das \u00fcbernimmt die Thanos-Komponente. Sidecar<\/a><\/noindex>. Es wird neben jedem Prometheus-Server bereitgestellt und fungiert als Proxy, der lokale Prometheus-Daten \u00fcber die gRPC-Schnittstelle des Store API bereitstellt, wodurch das Abfragen von Zeitreihendaten nach Labels und Zeitbereichen erm\u00f6glicht wird.<\/p>\n

Auf der anderen Seite steht die horizontal skalierbare Querier-Komponente ohne Zustandsspeicherung, die etwas mehr tut, als nur auf PromQL-Anfragen \u00fcber die standardm\u00e4\u00dfige Prometheus HTTP API zu antworten. Die Komponenten Querier, Sidecar und andere Thanos interagieren \u00fcber das Gossip-Protokoll.<\/a><\/noindex>.<\/p>\n

\"Thanos
\n<\/p>\n

    \n
  1. Wenn der Querier eine Anfrage erh\u00e4lt, verbindet er sich mit dem entsprechenden Store API-Server, also unseren Sidecar-Komponenten, und erh\u00e4lt Zeitreihendaten von den entsprechenden Prometheus-Servern.<\/li>\n
  2. Anschlie\u00dfend kombiniert er die Antworten und f\u00fchrt die PromQL-Anfrage aus. Der Querier kann sowohl nicht \u00fcberlappende Daten als auch duplizierte Daten von HA-Prometheus-Servern zusammenf\u00fchren.<\/li>\n<\/ol>\n

    \nDadurch l\u00f6sen wir den Hauptteil unseres Puzzles \u2013 das Zusammenf\u00fchren von Daten von isolierten Prometheus-Servern in eine einheitliche Ansicht. Tats\u00e4chlich kann Thanos nur f\u00fcr diese Funktionalit\u00e4t verwendet werden. Es sind keine \u00c4nderungen an bestehenden Prometheus-Servern erforderlich!<\/p>\n

    Unbegrenzte Speicherfrist!<\/h4>\n

    \nFr\u00fcher oder sp\u00e4ter m\u00f6chten wir jedoch Daten speichern, die \u00fcber die \u00fcbliche Aufbewahrungszeit von Prometheus hinausgehen. F\u00fcr die Speicherung historischer Daten haben wir ein Objektspeicher gew\u00e4hlt. Dieser ist in jeder Cloud sowie in lokalen Rechenzentren weit verbreitet und sehr kosteng\u00fcnstig. Dar\u00fcber hinaus ist praktisch jeder Objektspeicher \u00fcber das bekannte S3-API zug\u00e4nglich.<\/p>\n

    Prometheus schreibt Daten etwa alle zwei Stunden aus dem Arbeitsspeicher auf die Festplatte. Der Block gespeicherter Daten enth\u00e4lt alle Daten f\u00fcr einen festen Zeitraum und ist unver\u00e4nderlich. Das ist sehr praktisch, da der Thanos Sidecar einfach das Prometheus-Datenverzeichnis \u00fcberwachen und bei Erscheinen neuer Bl\u00f6cke diese in die Objektspeicher-Buckets hochladen kann.<\/p>\n

    \"Thanos
    \n
    \nDie Speicherung im Objektspeicher sofort nach der Aufzeichnung auf die Festplatte erm\u00f6glicht auch eine Vereinfachung des Scrapers (Prometheus und Thanos Sidecar). Das erleichtert die Wartung, die Kosten und das Design des Systems.<\/p>\n

    Wie Sie sehen, ist die Datensicherung sehr einfach zu realisieren. Aber wie sieht es mit der Abfrage von Daten im Objektspeicher aus?<\/p>\n

    Die Thanos Store-Komponente fungiert als Proxy f\u00fcr den Zugriff auf Daten aus dem Objektspeicher. \u00c4hnlich wie der Thanos Sidecar ist sie Teil des Gossip-Clusters und implementiert die Store API. So k\u00f6nnen bestehende Querier sie als Sidecar betrachten, als eine weitere Quelle f\u00fcr Zeitreihendaten \u2013 es sind keine speziellen Konfigurationen erforderlich.<\/p>\n

    \"Thanos
    \n
    \nDie Bl\u00f6cke der Zeitreihendaten bestehen aus mehreren gro\u00dfen Dateien. Eine bedarfsorientierte Bereitstellung w\u00e4re ziemlich ineffizient, und lokale Caches w\u00fcrden enorme Mengen an Speicher und Festplattenspeicher erfordern.<\/p>\n

    Stattdessen wei\u00df das Store Gateway, wie es mit dem Speicherformat von Prometheus umgeht. Dank eines intelligenten Anfrageplaners und der Caching-Mechanismen, die nur die ben\u00f6tigten Indexpunkte der Bl\u00f6cke speichern, konnten komplexe Anfragen auf ein Minimum an HTTP-Anfragen an die Objektspeicherdateien reduziert werden. Dadurch l\u00e4sst sich die Anzahl der Anfragen um vier bis sechs Gr\u00f6\u00dfenordnungen verringern, und es wird eine Reaktionszeit erreicht, die insgesamt schwer von der Abfrage von Daten auf einem lokalen SSD zu unterscheiden ist.<\/p>\n

    \"Thanos
    \n
    \nWie in der oben stehenden Grafik dargestellt, reduziert Thanos Querier die Kosten f\u00fcr eine Abfrage an Speicherdaten erheblich, indem es das Prometheus-Speicherformat verwendet und verwandte Daten nahe beieinander platziert. Durch diesen Ansatz k\u00f6nnen wir zahlreiche Einzelabfragen in eine minimalistische Anzahl von Bulk-Operationen b\u00fcndeln.<\/p>\n

    Verdichtung und Downsampling<\/h4>\n

    \nSobald ein neuer Block von Zeitreihendaten erfolgreich in den Objektspeicher geladen wurde, betrachten wir ihn als \"historische\" Daten, die sofort \u00fcber das Store Gateway verf\u00fcgbar sind.<\/p>\n

    Nach einiger Zeit sammeln sich jedoch Bl\u00f6cke aus einer Quelle (Prometheus mit Sidecar) an und nutzen das volle Potenzial der Indizierung nicht mehr aus. Um dieses Problem zu l\u00f6sen, haben wir eine weitere Komponente namens Compactor eingef\u00fchrt. Diese wendet einfach den lokalen Verdichtungsmechanismus von Prometheus auf die historischen Daten im Objektspeicher an und kann als einfaches, periodisches Batch-Job ausgef\u00fchrt werden.<\/p>\n

    \"Thanos
    \n
    \nDank effizienter Kompression stellt eine langanhaltende Abfrage im Speicher hinsichtlich der Datengr\u00f6\u00dfe kein Problem dar. Allerdings wird die potenzielle Kosten f\u00fcr das Entpacken von Milliarden von Werten und das Durchlaufen dieser durch den Abfrage-Handler unweigerlich zu einem drastischen Anstieg der Ausf\u00fchrungszeit f\u00fchren. Andererseits, da jedem Pixel auf dem Bildschirm Hunderte von Datenpunkten zugeordnet sind, wird es unm\u00f6glich, die Daten in voller Aufl\u00f6sung zu visualisieren. Daher ist das Downsampling nicht nur m\u00f6glich, sondern f\u00fchrt auch nicht zu einem merklichen Verlust an Genauigkeit. <\/p>\n

    \"Thanos
    \n
    \nF\u00fcr das Downsampling aggregiert Compactor kontinuierlich Daten mit einer Aufl\u00f6sung von f\u00fcnf Minuten und einer Stunde. F\u00fcr jedes unbearbeitete Fragment, das mit TSDB XOR-Kompression kodiert wurde, werden verschiedene Typen aggregierter Daten gespeichert, wie zum Beispiel min, max oder sum f\u00fcr einen Block. Dies erm\u00f6glicht es dem Querier, automatisch das Aggregat auszuw\u00e4hlen, das f\u00fcr die jeweilige PromQL-Abfrage geeignet ist. <\/p>\n

    Um Daten mit geringerer Genauigkeit zu verwenden, ben\u00f6tigt der Benutzer keine spezielle Konfiguration. Querier wechselt automatisch zwischen verschiedenen Aufl\u00f6sungen und unbearbeiteten Daten, w\u00e4hrend der Benutzer hinein- und herauszoomt. Auf Wunsch kann der Benutzer dies direkt \u00fcber den Parameter \u201estep\u201c in der Anfrage steuern. <\/p>\n

    Da die Kosten f\u00fcr die Speicherung von einem GB gering sind, speichert Thanos standardm\u00e4\u00dfig die Originaldaten sowie Daten mit einer Aufl\u00f6sung von f\u00fcnf Minuten und einer Stunde. Es ist nicht erforderlich, die Originaldaten zu l\u00f6schen.<\/p>\n

    Recording-Regeln<\/h2>\n

    \nSelbst mit Thanos sind Recording-Regeln ein wesentlicher Bestandteil des Monitoring-Stacks. Sie reduzieren die Komplexit\u00e4t, die Latenz und die Kosten von Abfragen. Zudem sind sie n\u00fctzlich f\u00fcr Benutzer, um aggregierte Daten zu Metriken zu erhalten. Thanos basiert auf Vanilla-Instanzen von Prometheus, daher ist es durchaus zul\u00e4ssig, Recording- und Alerting-Regeln auf einem bestehenden Prometheus-Server zu speichern. In einigen F\u00e4llen kann dies jedoch unzureichend sein:<\/p>\n