{"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 \u2013 skalierbares 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-Fan und Liebhaber komplexer Aufgaben. Er ist auch Maintainer von Prometheus und Mitbegr\u00fcnder der Kubernetes SIG Instrumentation. Zuvor war er Production Engineer bei SoundCloud und leitete das Monitoring-Team bei CoreOS. Derzeit arbeitet er bei Google.<\/p>\n

Bartek Plotka<\/a><\/noindex> \u2014 Infrastruktur-Ingenieur bei Improbable. Er interessiert sich f\u00fcr neue Technologien und Probleme verteilter Systeme. Er hat Erfahrung in der Low-Level-Programmierung bei Intel, war Contributor bei Mesos und hat globale SRE-Produktions-Erfahrung bei Improbable. Er arbeitet daran, die Welt der Mikrodienste zu verbessern. Seine drei Leidenschaften: Golang, Open Source und Volleyball.<\/i><\/p>\n

Wenn Sie sich unser Flaggschiff-Produkt SpatialOS ansehen, k\u00f6nnen Sie erraten, dass Improbable eine hochdynamische Cloud-Infrastruktur globalen Ma\u00dfstabs mit Dutzenden von Kubernetes-Clustern ben\u00f6tigt. Wir geh\u00f6rten zu den Ersten, die ein Monitoring-System einsetzten Prometheus<\/a><\/noindex>. Prometheus kann Millionen von Metriken in Echtzeit \u00fcberwachen und wird mit einer leistungsstarken Abfragesprache geliefert, die es erm\u00f6glicht, notwendige Informationen abzurufen.<\/p>\n

Die Einfachheit und Zuverl\u00e4ssigkeit von Prometheus ist eines seiner Hauptvorteile. Doch bei einer bestimmten Skalierung sind wir auf einige Nachteile gesto\u00dfen. Um diese Probleme zu l\u00f6sen, haben wir Thanos<\/a><\/noindex> \u2014 ein Open-Source-Projekt, das von Improbable erstellt wurde, um bestehende Prometheus-Cluster nahtlos in ein einheitliches \u00dcberwachungssystem mit unbegrenzter historischer Datenspeicherung zu transformieren. Thanos ist auf Github verf\u00fcgbar. hier<\/a><\/noindex>.<\/a><\/noindex><\/p>\n

Bleiben Sie auf dem Laufenden \u00fcber die neuesten Nachrichten von Improbable.<\/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 speichert man Petabytes historischer Daten zuverl\u00e4ssig und kosteng\u00fcnstig? Ist dies m\u00f6glich, ohne die Antwortzeiten zu beeintr\u00e4chtigen? Kann man auf alle Metriken, die auf verschiedenen Prometheus-Servern liegen, mit einer einzigen API-Anfrage zugreifen? Ist es m\u00f6glich, replizierte Daten, die mit Prometheus HA gesammelt wurden, irgendwie zu kombinieren?<\/p>\n

Um diese Fragen zu beantworten, haben wir Thanos entwickelt. In den folgenden Abschnitten wird beschrieben, wie wir an die L\u00f6sung dieser Fragen herangegangen sind, und die Ziele erkl\u00e4rt, die wir verfolgt haben.<\/p>\n

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

\nPrometheus bietet einen funktionalen Ansatz f\u00fcr das Sharding an. Selbst ein einzelner Prometheus-Server gew\u00e4hrleistet eine ausreichende Skalierbarkeit, um die Nutzer von den Komplikationen des horizontalen Shardings in nahezu allen Anwendungsf\u00e4llen zu befreien.<\/p>\n

Obwohl dies ein hervorragendes Bereitstellungsmodell ist, wird h\u00e4ufig der Zugriff auf Daten von verschiedenen Prometheus-Servern \u00fcber eine einheitliche API oder UI \u2013 global view \u2013 ben\u00f6tigt. Nat\u00fcrlich ist es m\u00f6glich, mehrere Abfragen in einem Grafana-Dashboard anzuzeigen, aber jede Abfrage kann nur auf einen Prometheus-Server ausgef\u00fchrt werden. Andererseits k\u00f6nnen Sie mit Thanos Daten von mehreren Prometheus-Servern abfragen und aggregieren, da sie alle \u00fcber einen einzigen Endpunkt zug\u00e4nglich sind.<\/p>\n

Fr\u00fcher haben wir zur Erzielung einer globalen Ansicht bei Improbable unsere Prometheus-Instanzen in eine mehrstufige Hierarchische F\u00f6deration<\/a><\/noindex>Das bedeutete die Erstellung eines Meta-Servers f\u00fcr Prometheus, der einen Teil der Metriken von jedem \"Blatt\"-Server sammelt.<\/p>\n

\"Thanos
\n
\nDieser Ansatz erwies sich als problematisch. Er f\u00fchrte zu einer komplizierten Konfiguration, zu einer zus\u00e4tzlichen potenziellen Fehlerquelle und zur Anwendung komplexer Regeln, um der f\u00f6derierten Endstelle nur die ben\u00f6tigten Daten bereitzustellen. Dar\u00fcber hinaus erm\u00f6glicht diese Art der F\u00f6deration keine echte globale Ansicht, da nicht alle Daten \u00fcber eine einzige API-Anfrage abgerufen werden k\u00f6nnen.<\/p>\n

Hierzu geh\u00f6rt auch die einheitliche Darstellung von Daten, die auf hochverf\u00fcgbaren (high-availability, HA) Prometheus-Servern gesammelt werden. Das HA-Modell von Prometheus sammelt 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 Ansicht beider Datenstr\u00f6me zu verwenden.<\/p>\n

Nat\u00fcrlich gibt es in hochverf\u00fcgbaren Prometheus-Servern einen Bedarf. Bei Improbable nehmen wir die Daten\u00fcberwachung im Minutentakt sehr ernst, aber das Vorhandensein einer einzigen Prometheus-Instanz pro Cluster stellt einen einzelnen Fehlerpunkt dar. Jede Konfigurationsfehler oder jedes Hardwareversagen k\u00f6nnte potenziell zum Verlust wichtiger Daten f\u00fchren. Selbst eine einfache Bereitstellung kann zu geringf\u00fcgigen Ausf\u00e4llen beim Metrik-Sammeln f\u00fchren, da ein Neustart deutlich l\u00e4nger als das 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 (den die meisten Benutzer von Prometheus teilen). Bei Improbable waren wir gezwungen, die Speicherdauer der Metriken auf neun Tage (f\u00fcr Prometheus 1.8) einzustellen. Das bringt offensichtliche Einschr\u00e4nkungen mit sich, wie weit wir in der Vergangenheit schauen k\u00f6nnen.<\/p>\n

Prometheus 2.0 ist in dieser Hinsicht besser geworden, da die Anzahl der Zeitreihen die Gesamtleistung des Servers nicht mehr beeinflusst (siehe KubeCon-Keynote \u00fcber Prometheus 2<\/a><\/noindex>). Dennoch speichert Prometheus Daten auf der lokalen Festplatte. Obwohl eine hochgradig effiziente Datenkompression den Einsatz von lokalem SSD-Speicher erheblich reduzieren kann, gibt es letztendlich trotzdem eine Grenze f\u00fcr die Menge der gespeicherten historischen Daten.<\/p>\n

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

Herunterstufen<\/h4>\n

\nSobald wir begannen, mit historischen Daten zu arbeiten, erkannten wir, dass es grundlegende Herausforderungen mit der O-Notation gibt, die Abfragen immer langsamer macht, wenn wir mit Daten \u00fcber Wochen, Monate und Jahre arbeiten.<\/p>\n

Eine standardm\u00e4\u00dfige L\u00f6sung f\u00fcr dieses Problem w\u00e4re Herunterstufen<\/a><\/noindex> (Downsampling) \u2014 die Reduzierung der Abtastrate eines Signals. Durch die Verringerung der Abtastrate k\u00f6nnen wir \"skalieren\", um einen gr\u00f6\u00dferen Zeitraum abzudecken und die gleiche Anzahl von Abtastungen beizubehalten, was die Reaktionsf\u00e4higkeit der Abfragen verbessert.<\/p>\n

Das Herunterstufen alter Daten ist eine unerl\u00e4ssliche Anforderung jeder L\u00f6sung f\u00fcr die langfristige Speicherung und geht \u00fcber das herk\u00f6mmliche 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. Das zweite Ziel war die einfache Bedienung mit einer minimalen Einstiegsh\u00fcrde. Alle Abh\u00e4ngigkeiten sollten sowohl f\u00fcr kleine als auch gro\u00dfe Nutzer leicht erf\u00fcllbar sein, was auch eine geringe Grundgeb\u00fchr impliziert.<\/p>\n

Architektur von Thanos<\/h2>\n

\nNachdem wir in dem vorherigen Abschnitt unsere Ziele aufgelistet haben, lassen Sie uns daran arbeiten und sehen, wie Thanos diese Herausforderungen angeht.<\/p>\n

Globale Ansicht<\/h4>\n

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

Auf der anderen Seite befindet sich die horizontal skalierbare, zustandslose Komponente Querier, 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. Der Querier verbindet sich bei Erhalt einer Anfrage mit dem entsprechenden Server des Store API, also mit unseren Sidecars, und erh\u00e4lt die 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-Servern von Prometheus zusammenf\u00fchren.<\/li>\n<\/ol>\n

    \nDas l\u00f6st den gr\u00f6\u00dften Teil unseres R\u00e4tsels \u2014 die Zusammenf\u00fchrung von Daten von isolierten Prometheus-Servern in eine einheitliche Ansicht. Tats\u00e4chlich kann Thanos nur f\u00fcr diese Funktionalit\u00e4t genutzt werden. Es sind keine \u00c4nderungen an den bestehenden Prometheus-Servern erforderlich!<\/p>\n

    Unbegrenzte Speicherfrist!<\/h4>\n

    \nAllerdings werden wir fr\u00fcher oder sp\u00e4ter die Daten speichern wollen, die \u00fcber die \u00fcbliche Speicherfrist von Prometheus hinausgehen. F\u00fcr die Speicherung von historischen Daten haben wir ein Objektspeicher gew\u00e4hlt. Dieser ist in jeder Cloud sowie in lokalen Rechenzentren weit verbreitet und \u00e4u\u00dferst kosteng\u00fcnstig. Zudem ist praktisch jeder Objektspeicher \u00fcber die gut bekannte S3 API zug\u00e4nglich.<\/p>\n

    Prometheus schreibt Daten aus dem Arbeitsspeicher ungef\u00e4hr alle zwei Stunden auf die Festplatte. Ein Block der gespeicherten Daten enth\u00e4lt alle Daten f\u00fcr einen festen Zeitraum und ist unver\u00e4nderlich. Das ist sehr praktisch, da Thanos Sidecar einfach das Verzeichnis der Prometheus-Daten durchsuchen kann und, w\u00e4hrend neue Bl\u00f6cke erscheinen, diese in die Buckets des Objektspeichers l\u00e4dt.<\/p>\n

    \"Thanos
    \n
    \nDas Laden in den Objektspeicher direkt nach dem Schreiben auf die Festplatte erm\u00f6glicht es auch, die Einfachheit des \u201eScrapers\u201c (Prometheus und Thanos Sidecar) zu bewahren. Dies vereinfacht die Wartung, die Kosten und das Design des Systems.<\/p>\n

    Wie Sie sehen, erfolgt die Datensicherung sehr einfach. Aber wie sieht es mit dem Abruf von Daten aus dem Objektspeicher aus?<\/p>\n

    Die Thanos Store-Komponente fungiert als Proxy zum Abrufen von Daten aus dem Objektspeicher. Wie Thanos Sidecar ist sie Teil eines 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. Das Herunterladen auf Anfrage w\u00e4re ziemlich ineffizient, und die lokale Zwischenspeicherung w\u00fcrde enorme Speicher- und Festplattenspeicher erfordern.<\/p>\n

    Stattdessen wei\u00df das Store Gateway, wie man mit dem Speicherformat von Prometheus umgeht. Dank eines intelligenten Abfrageplaners und der Zwischenspeicherung nur der ben\u00f6tigten Indexteile der Bl\u00f6cke ist es m\u00f6glich, komplexe Abfragen auf ein Minimum an HTTP-Anfragen an die Dateien des Objektspeichers zu reduzieren. Damit k\u00f6nnen die Anfragen um vier bis sechs Gr\u00f6\u00dfenordnungen reduziert und eine Antwortzeit erreicht werden, die insgesamt schwer von der Abfrage von Daten auf einem lokalen SSD zu unterscheiden ist.<\/p>\n

    \"Thanos
    \n
    \nWie in der obigen Grafik gezeigt, senkt Thanos Querier die Kosten f\u00fcr eine einzelne Anfrage an Daten im Objektspeicher erheblich, indem es das Speicherformat von Prometheus verwendet und verwandte Daten nahe beieinander anordnet. Mit diesem Ansatz k\u00f6nnen wir viele einzelne Anfragen in eine minimale Anzahl von Bulk-Operationen zusammenfassen.<\/p>\n

    Kompaktierung und Heruntersampling<\/h4>\n

    \nNachdem ein neuer Block von Zeitreihendaten erfolgreich in den Objektspeicher geladen wurde, betrachten wir ihn als \u201ehistorische\u201c 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 nicht mehr das volle Potenzial der Indizierung. Um dieses Problem zu l\u00f6sen, haben wir eine weitere Komponente namens Compactor eingef\u00fchrt. Diese wendet einfach den lokalen Kompaktierungsmechanismus von Prometheus auf die historischen Daten im Objektspeicher an und kann als einfaches, regelm\u00e4\u00dfiges Batch-Job ausgef\u00fchrt werden.<\/p>\n

    \"Thanos
    \n
    \nDank einer effektiven Komprimierung stellt eine Abfrage an das Repository \u00fcber einen l\u00e4ngeren Zeitraum kein Problem in Bezug auf die Datengr\u00f6\u00dfe dar. Allerdings wird die potenzielle Kosten f\u00fcr das Entpacken von einer Milliarde Werten und deren Verarbeitung durch den Query-Handler unweigerlich zu einer signifikanten Erh\u00f6hung der Ausf\u00fchrungszeit der Abfrage f\u00fchren. Auf der anderen Seite, da auf jeden Bildschirmpixel Hunderte von Datenpunkten entfallen, wird es unm\u00f6glich, die Daten in voller Aufl\u00f6sung zu visualisieren. Daher ist Downsamping nicht nur m\u00f6glich, sondern f\u00fchrt auch nicht zu einem sp\u00fcrbaren Verlust an Genauigkeit. <\/p>\n

    \"Thanos
    \n
    \nF\u00fcr das Downsamping von Daten aggregiert der Compactor kontinuierlich Daten mit einer Aufl\u00f6sung von f\u00fcnf Minuten und einer Stunde. F\u00fcr jedes unverarbeitete Fragment, das mit der TSDB-XOR-Komprimierung codiert wurde, werden verschiedene Arten von aggregierten Daten gespeichert, wie z.B. 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 reduzierter Genauigkeit zu verwenden, ben\u00f6tigt der Benutzer keine spezielle Konfiguration. Der Querier wechselt automatisch zwischen verschiedenen Aufl\u00f6sungen und unverarbeiteten Daten, wenn der Benutzer herein- oder herauszoomt. Wenn gew\u00fcnscht, kann der Benutzer dies direkt \u00fcber den Parameter \"step\" in der Abfrage steuern. <\/p>\n

    Da die Speicherkosten f\u00fcr ein GB gering sind, speichert Thanos standardm\u00e4\u00dfig die Rohdaten, die Daten mit einer Aufl\u00f6sung von f\u00fcnf Minuten und einer Stunde. Es besteht keine Notwendigkeit, die Rohdaten 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. Au\u00dferdem sind sie f\u00fcr Benutzer n\u00fctzlich, um aggregierte Daten zu Metriken zu erhalten. Thanos basiert auf einem Vanilla-Prometheus-Setup, daher ist es durchaus zul\u00e4ssig, Recording-Regeln und Alerting-Regeln auf einem bestehenden Prometheus-Server zu speichern. In einigen F\u00e4llen k\u00f6nnte dies jedoch unzureichend sein:<\/p>\n