Hallo zusammen. Nachfolgend finden Sie die Transkription .
– ein Monitoring-System für verschiedene Systeme und Dienste, mit dem Systemadministratoren Informationen über die aktuellen Parameter der Systeme sammeln und Alarme einrichten können, um Benachrichtigungen über Abweichungen im Betrieb der Systeme zu erhalten.
Der Vortrag wird einen Vergleich enthalten und – Projekte zur langfristigen Speicherung von Prometheus-Metriken.
Zuerst möchte ich über Prometheus sprechen. Dies ist ein Monitoring-System, das Metriken von bestimmten Zielsystemen sammelt und sie in einem lokalen Speicher speichert. Prometheus kann Metriken in einen entfernten Speicher aufzeichnen und generiert Alarme sowie Aufzeichnungsregeln.
Einschränkungen von Prometheus:
- Es gibt keine globale Abfrageansicht. Das ist der Fall, wenn Sie mehrere unabhängige Instanzen von Prometheus haben. Diese sammeln Metriken, und Sie möchten eine Abfrage über all diese Metriken hinweg durchführen, die von verschiedenen Instanzen von Prometheus gesammelt wurden. Prometheus erlaubt dies nicht.
- Die Leistung von Prometheus ist nur auf einen Server beschränkt. Prometheus kann sich nicht automatisch auf mehrere Server skalieren. Sie können lediglich manuell Ihre Zielsysteme zwischen mehreren Prometheus-Instanzen aufteilen.
- Das Volumen der Metriken in Prometheus ist nur durch einen einzigen Server begrenzt, aus dem Grund, dass es automatisch nicht auf mehrere Server skalierbar ist.
- Es ist nicht so einfach, die Speicherung von Daten in Prometheus zu organisieren.
Was sind die Lösungen für diese Probleme?
Die Lösungen sind folgende:
Alle diese Lösungen dienen zur externen Speicherung von Daten, die von Prometheus gesammelt wurden. Sie lösen das Problem des Remote-Speichers aus der vorherigen Folie auf unterschiedliche Weise. In dieser Präsentation werde ich nur über die ersten beiden Lösungen sprechen: und .
Erstmals wurde die Information über veröffentlicht am . Dort wird die Architektur beschrieben und wie sie funktioniert.
Thanos nimmt die Daten, die Prometheus auf der lokalen Festplatte gespeichert hat, und kopiert sie in S3, in oder in einen anderen Object Storage.
So sorgt Thanos für eine globale Abfrageansicht. Sie können Daten, die in Object Storage gespeichert sind, von mehreren Instanzen von Prometheus abfragen.
Thanos unterstützt PromQL und .
Thanos verwendet den Code von Prometheus zur Datenspeicherung.
Thanos wird von denselben Entwicklern entwickelt, die auch Prometheus entwickelt haben.
Über . Hier ist , wo wir erstmals über .
VictoriaMetrics Daten von mehreren Prometheus über protokoll, das von Prometheus unterstützt wird.
VictoriaMetrics bietet eine globale Abfragesicht, da mehrere Instanzen von Prometheus Daten in ein einziges VictoriaMetrics schreiben können. So können Sie Anfragen über all diese Daten stellen.
VictoriaMetrics unterstützt, wie auch Thanos, das PromQL und die Prometheus-Abfrage-API.
Im Gegensatz zu Thanos wurde der Quellcode von VictoriaMetrics von Grund auf neu geschrieben und ist auf Geschwindigkeit und Ressourcenverbrauch optimiert.
VictoriaMetrics skaliert, anders als Thanos, sowohl vertikal als auch horizontal. Es gibt , die vertikal skaliert. Sie können mit einem Prozessor und 1 GB RAM beginnen und schrittweise auf Hunderte von Prozessoren und 1 TB RAM wachsen. VictoriaMetrics kann all diese Ressourcen nutzen. Ihre Leistung wird sich im Vergleich zu einem einprozessorsystem etwa um das 100-Fache steigern.
Die Geschichte von Thanos begann im November 2017 mit dem ersten öffentlichen Commit. Zuvor wurde Thanos intern bei .
entwickelt. Im Juni 2019 gab es eine bedeutende Veröffentlichung 0.5.0, in der Protokoll. Es wurde aus Thanos entfernt, da es nicht die besten Ergebnisse gezeigt hat. Oft arbeitete der Thanos-Cluster nicht richtig, und Knoten konnten wegen des Gossip-Protokolls nicht korrekt verbunden werden. Daher wurde entschieden, es zu entfernen. Ich halte das für die richtige Entscheidung.
Im Juni 2019 schickten sie den Antrag mit der Nummer in .
Und nach ein paar Monaten wurde Thanos in , das Prometheus, Kubernetes und andere beliebte Projekte umfasst, aufgenommen.
Im Januar 2018 begann die Entwicklung von VictoriaMetrics.
Im September 2018 erwähnte ich VictoriaMetrics erstmals öffentlich.
Im Dezember 2018 veröffentlichten wir die Single-Node-Version.
Im Mai 2019 die Quellcodes sowohl der Single-Node- als auch der Cluster-Version.
Im Juni 2019, ebenso wie Thanos, haben wir einen Antrag bei der CNCF-Stiftung unter der Nummer gestellt. Wir haben unseren Antrag einen Tag früher eingereicht als Thanos.
Aber leider wurden wir dort bis jetzt noch nicht akzeptiert. Die Community braucht Unterstützung.
Lassen Sie uns die wichtigsten Folien betrachten, die die Architektur von Thanos und VictoriaMetrics zeigen.
Lassen Sie uns mit Thanos beginnen. Die gelben Komponenten sind die Komponenten von Prometheus. Alles andere sind Thanos-Komponenten. Beginnen wir mit der wichtigsten Komponente. Thanos Sidecar ist eine Komponente, die neben jedem Prometheus installiert wird. Sie kümmert sich darum, die Prometheus-Daten aus dem lokalen Speicher in S3 oder einen anderen Object Storage zu laden.
Es gibt noch eine weitere Komponente, das Thanos Store Gateway, das in der Lage ist, diese Daten aus dem Object Storage bei eingehenden Anfragen von Thanos Query zu lesen. Thanos Query implementiert PromQL und die Prometheus API. Von außen sieht es also wie Prometheus aus. Es akzeptiert PromQL-Anfragen, leitet sie an das Thanos Store Gateway weiter, das die benötigten Daten aus dem Object Storage abruft und sie zurücksendet.
Aber in unserem Object Storage werden die Daten der letzten zwei Stunden aufgrund der Besonderheiten der Implementierung von Thanos Sidecar nicht gespeichert, da für diese zwei Stunden Prometheus noch keine Dateien im lokalen Speicher erstellt hat.
Wie wurde dieses Problem umgangen? Thanos Query sendet neben den Anfragen an das Thanos Store Gateway parallel auch Anfragen an jedes Thanos Sidecar, das sich neben Prometheus befindet.
Das Thanos Sidecar leitet diese Anfragen dann weiter an Prometheus und ruft die Daten der letzten zwei Stunden ab.
Neben diesen Komponenten gibt es noch eine optionale Komponente, ohne die Thanos nicht richtig funktionieren kann. Das ist Thanos Compact, das sich um das Zusammenführen kleiner Dateien im Object Storage in größere Dateien kümmert, die von den Thanos Sidecars hochgeladen wurden. Thanos Sidecar lädt Dateien mit Daten über einen Zeitraum von zwei Stunden hoch. Wenn diese Dateien nicht in größere Dateien zusammengeführt werden, kann ihre Anzahl erheblich ansteigen. Je mehr solcher Dateien vorhanden sind, desto mehr Speicher benötigt die Thanos Store Gateway, und desto mehr Ressourcen werden für die Datenübertragung im Netzwerk, einschließlich Metadaten, benötigt. Die Effizienz der Thanos Store Gateway leidet darunter. Daher sollte unbedingt Thanos Compact aktiviert werden, das kleine Dateien in größere zusammenführt, um deren Anzahl zu reduzieren und den Overhead auf die Thanos Store Gateway zu minimieren.
Es gibt auch eine Komponente namens Thanos Ruler. Sie führt die Prometheus-Alerting-Regeln aus und kann Prometheus-Recording-Regeln berechnen, um Daten wieder im Object Storage zu speichern. Diese Komponente wird jedoch nicht empfohlen, da sie .
So sieht das einfache Schema von Thanos aus.
Jetzt vergleichen wir es mit dem Schema von VictoriaMetrics.
VictoriaMetrics bietet zwei Versionen an: eine Einzelknoten- und eine Cluster-Version. Die Einzelknoten-Version läuft auf einem einzigen Computer. In der Einzelknoten-Version sind diese Komponenten nicht vorhanden, nur eine einzige Binärdatei. Diese Binärdatei sieht auf der Folie wie dieses Quadrat aus. Alles, was sich im Inneren des Quadrats befindet, ist der Inhalt der Binärdatei für die Einzelknoten-Version. Es ist nicht notwendig, darüber Bescheid zu wissen. Sie starten einfach die Binärdatei – und schon funktioniert alles.
Die Cluster-Version ist komplexer. Sie enthält drei unterschiedliche Komponenten: vmselect, vminsert und vmstorage. Aus ihren Namen sollte ersichtlich sein, welche Funktion jede dieser Komponenten hat. Die Insert-Komponente nimmt Daten in verschiedenen Formaten entgegen: über die Prometheus Remote Write API, das Influx Line-Protokoll, das Graphite-Protokoll und das OpenTSDB-Protokoll. Die Insert-Komponente nimmt diese Daten entgegen, analysiert sie und verteilt sie zwischen den vorhandenen Storage-Komponenten, wo die Daten dann gespeichert werden. Die Select-Komponente hingegen verarbeitet PromQL-Abfragen. Sie implementiert , sowie die Abfrage-API von Prometheus und kann als zusätzliche Datenquelle zu Prometheus in Grafana oder anderen Prometheus-API-Clients verwendet werden. Die Select-Komponente nimmt eine PromQL-Abfrage entgegen, analysiert sie, liest die benötigten Daten zur Ausführung dieser Abfrage aus den Storage-Knoten, verarbeitet diese Daten und gibt die Antwort zurück.
Vergleichen wir die Installationskomplexität von Thanos und VictoriaMetrics.
Beginnen wir mit Thanos. Bevor Sie mit Thanos arbeiten können, müssen Sie einen Bucket im Object Storage, wie S3 oder GCS, erstellen, damit der Thanos Sidecar dort Daten ablegen kann.
Anschließend muss für jeden Prometheus der Thanos Sidecar installiert werden. Vergessen Sie dabei nicht, die Datenkompression in Prometheus zu deaktivieren. Die Datenkompression komprimiert periodisch die Daten im lokalen Speicher von Prometheus, um den Ressourcenverbrauch zu reduzieren.
Wenn Sie den Thanos Sidecar an Ihren Prometheus-Instanzen installieren, sollten Sie diese Datenkompression deaktivieren, da der Thanos Sidecar nicht korrekt arbeitet, wenn die Datenkompression aktiviert ist. Das bedeutet, dass Ihr Prometheus die Daten in Blöcken von zwei Stunden speichert und aufhört, diese Blöcke zu größeren Einheiten zusammenzuführen. Wenn Sie also Abfragen stellen, die die Dauer der letzten zwei Stunden überschreiten, werden sie nicht so effizient arbeiten, wie sie könnten, wenn die Datenkompression aktiviert wäre.
Deshalb empfiehlt Thanos, die Datenaufbewahrungszeit im lokalen Speicher auf 6-8 Stunden zu reduzieren, um diese Überlastung durch eine große Anzahl kleiner Blöcke zu verringern.
Nachdem Sie den Thanos Sidecar installiert haben, müssen Sie für jeden Object Storage Bucket zwei Komponenten einrichten: den Thanos Compactor und das Thanos Store Gateway.
Danach sollten Sie Thanos Query installieren und so konfigurieren, dass es sich mit allen Thanos Store Gateways verbindet, die Sie haben, sowie zu allen Thanos Sidecars.
Hier könnte es ein kleines Problem geben.
Sie müssen eine zuverlässige und sichere Verbindung von Thanos Query zu diesen Komponenten einrichten. Wenn Ihre Prometheus-Instanzen sich in verschiedenen Rechenzentren oder in unterschiedlichen VPCs befinden, sind externe Verbindungen nicht gestattet. Für das Funktionieren von Thanos Query müssen Sie jedoch einen Weg finden, um eine Verbindung herzustellen.
Wenn Sie viele solcher Rechenzentren haben, verringert sich die Zuverlässigkeit des gesamten Systems. Thanos Query muss ständig Verbindungen zu allen Thanos Sidecars aufrechterhalten, die in verschiedenen Rechenzentren lokalisiert sind. Bei jeder eingehenden Anfrage wird es Anfragen an alle Thanos Sidecars weiterleiten. Wenn die Verbindung unterbrochen wird, erhalten Sie entweder einen unvollständigen Datensatz oder die Antwort "Cluster nicht verfügbar".
Bei VictoriaMetrics ist alles etwas einfacher. Für die Single-Node-Version genügt es, ein einziges Binärprogramm zu starten, und schon funktioniert alles.
In der Cluster-Version müssen Sie alle oben genannten drei Arten von Komponenten in beliebiger Anzahl starten oder verwenden, um den Start der Komponenten in Kubernetes zu automatisieren. Wir planen auch, einen Kubernetes-Operator zu entwickeln. Das Helm-Chart deckt einige Anwendungsfälle nicht ab und kann dazu führen, dass Sie sich ins Knie schießen. Zum Beispiel erlaubt es, die Anzahl der Storage-Nodes zu reduzieren, was zum Verlust von Daten führen kann.
Sobald Sie ein Binärprogramm oder die Cluster-Version gestartet haben, müssen Sie nur noch die Konfiguration für Prometheus hinzufügen, , damit es beginnt, Daten gleichzeitig im lokalen Storage und im Remote Storage zu speichern. Wie Sie festgestellt haben, sollte eine solche Konfiguration wesentlich zuverlässiger funktionieren im Vergleich zur Thanos-Konfiguration. Wir müssen die Verbindung von VictoriaMetrics zu allen Prometheus-Instanzen nicht aufrechterhalten, da sich die Prometheus-Instanzen selbst mit VictoriaMetrics verbinden und Daten übermitteln.
Betrachten wir die Unterstützung von Thanos und VictoriaMetrics.
Thanos muss den Sidecar überwachen, um sicherzustellen, dass sie den Datenfluss in den Object Storage nicht unterbrechen. Sie könnten den Datenfluss aufgrund von Upload-Fehlern einstellen, beispielsweise wenn Ihre Netzwerkverbindung zum Object Storage vorübergehend unterbrochen wird oder wenn der Object Storage vorübergehend nicht verfügbar ist. In diesem Moment wird Thanos Sidecar dies bemerken, einen Fehler melden, möglicherweise abstürzen und danach nicht mehr funktionieren. Wenn Sie ihn nicht überwachen, werden die Daten nicht mehr an den Object Storage übermittelt. Wenn die Aufbewahrungszeit (6-8 Stunden empfohlen) abläuft, verlieren Sie die Daten, die nicht in den Object Storage gelangt sind.
Thanos Compactoren können aufgrund von . Die Compactoren nehmen Daten aus dem Object Storage und fassen sie zu größeren Dateneinheiten zusammen. Da die Compactoren nicht mit den Sidecars synchronisiert sind, kann Folgendes passieren: Der Sidecar hat den Block noch nicht vollständig geschrieben, der Compactor entscheidet, dass dieser Block vollständig aufgenommen wurde. Der Compactor beginnt, ihn zu lesen. Er liest den Block nicht vollständig und hört dann auf zu arbeiten. Siehe Details. .
Der Store Gateway kann inkonsistente Daten aufgrund von Race-Conditions zwischen dem Compactor und den Sidecars zurückgeben. Hier verhält es sich ähnlich, da der Store Gateway nicht mit den Compactoren und Sidecars synchronisiert ist. Dadurch können Race-Conditions auftreten, bei denen der Store Gateway Teile der Daten nicht sieht oder zusätzliche Daten anzeigt.
Die Query-Komponente in Thanos gibt standardmäßig ein Teilergebnis zurück, wenn einige Sidecars oder der Store Gateway derzeit nicht verfügbar sind. Sie erhalten einen Teil der Daten, ohne zu wissen, dass nicht alle Daten vorliegen. So funktioniert es standardmäßig. In einer ähnlichen Situation gibt VictoriaMetrics die markierten Daten als teilweis vorhanden zurück.
Im Gegensatz zu Thanos verliert VictoriaMetrics selten Daten. Selbst wenn die Verbindung von Prometheus zu VictoriaMetrics unterbrochen wird, ist das kein Problem, da Prometheus weiterhin die eingehenden neuen Daten im Write Ahead Log speichert, dessen Größe zwei Stunden beträgt. Wenn Sie innerhalb von zwei Stunden die Verbindung zu VictoriaMetrics wiederherstellen, gehen die Daten nicht verloren. Prometheus .
Im Gegensatz zu Thanos, der Daten nur nach zwei Stunden im Object Storage speichert, repliziert Prometheus Daten automatisch über das Remote Write-Protokoll in den Remote Storage, wie zum Beispiel VictoriaMetrics. Sie müssen sich keine Sorgen um den Verlust des Local Storage in Prometheus machen. Wenn dieser plötzlich verloren geht, verlieren Sie im schlimmsten Fall nur die letzten Sekunden an Daten, die nicht in den Remote Storage geschrieben wurden.
Kubernetes verwaltet den Cluster automatisch, im Gegensatz zu Thanos. Alle Komponenten von Thanos lassen sich nur schwer in einem einzigen Kubernetes-Cluster unterbringen, während die Cluster-Komponenten von VictoriaMetrics problemlos integriert werden können.
VictoriaMetrics ermöglicht ein sehr einfaches Upgrade auf eine neue Version. Sie stoppen einfach VictoriaMetrics, aktualisieren die Binärdateien und starten es neu. Beim Stoppen über das SIGINT-Signal führen alle Binärdateien von VictoriaMetrics einen sanften Shutdown durch. Sie speichern alle benötigten Daten korrekt und schließen eingehende Verbindungen ordnungsgemäß, um nichts zu verlieren. Daher verlieren Sie bei einem Upgrade keinerlei Daten.
Das Erweitern des Clusters bei VictoriaMetrics ist sehr einfach. Fügen Sie einfach die benötigten Komponenten hinzu und arbeiten Sie weiter.
Über die Stolpersteine bei Thanos und VictoriaMetrics.
Bei Thanos gibt es folgende Fallstricke. Prometheus muss die Daten der letzten zwei Stunden speichern. Wenn diese verloren gehen, gehen sie vollständig verloren, da sie noch nicht im Object Storage, wie S3, gespeichert wurden.
Der Store Gateway und der Compactor können viel Speicher benötigen, wenn sie mit großen Object Storages arbeiten, insbesondere wenn dort viele kleine Dateien gespeichert sind. Je mehr Dateien vorhanden sind und je größer ihr Volumen, desto mehr Arbeitsspeicher benötigen der Store Gateway und der Compactor, um Metainformationen zu speichern. Thanos hat viele Probleme damit, dass .
Thanos wirbt damit, dass es unbegrenzt skalierbar ist, was die Anzahl Ihrer Prometheus-Instanzen betrifft. In Wirklichkeit ist das nicht der Fall. Da alle Anfragen über die Query-Komponente laufen, die parallel alle Store Gateway-Komponenten und Sidecar-Komponenten abfragen muss, um Daten zu ziehen und sie dann vorzubereiten. Offensichtlich ist die Geschwindigkeit der Anfragen durch das schwächste Glied begrenzt, sei es der langsamste Store Gateway oder der langsamste Sidecar.
Diese Komponenten können ungleichmäßig ausgelastet sein. Zum Beispiel haben Sie einen Prometheus, der Millionen von Metriken pro Sekunde sammelt. Und es gibt einen Prometheus, der Tausende von Metriken pro Sekunde sammelt. Der Prometheus, der Millionen von Metriken pro Sekunde verarbeitet, belastet den Server, auf dem er läuft, deutlich stärker. Folglich arbeitet der Sidecar dort langsamer. Generell funktioniert alles dort langsamer. Der Query-Komponente wird es sehr schwer fallen, Daten von dort abzurufen. Dementsprechend wird die Leistung Ihres gesamten Clusters durch diesen langsamen Sidecar beeinträchtigt.
Standardmäßig gibt Thanos nur partielle Daten zurück, wenn einige Sidecar’s oder Store Gateway nicht verfügbar sind. Wenn Ihre Sidecar’s über die ganze Welt in verschiedenen Rechenzentren verteilt sind, erhöht sich die Wahrscheinlichkeit von Verbindungsabbrüchen und der Unzugänglichkeit der Komponenten erheblich. Folglich werden Sie in den meisten Fällen partielle Daten erhalten, ohne es zu wissen.
VictoriaMetrics hat ebenfalls seine Tücken. Der erste Stolperstein ist die Option, die den Speicherbedarf für den Cache von VictoriaMetrics begrenzt. Standardmäßig liegt dieser Wert bei 60 % des Arbeitsspeichers auf der Maschine, auf der VictoriaMetrics läuft, oder bei 60 % des RAM des VictoriaMetrics-Pods in Kubernetes.
Wenn dieser Wert falsch eingestellt wird, kann dies die Leistung von VictoriaMetrics erheblich beeinträchtigen. Beispielsweise kann das Festlegen eines zu niedrigen Wertes dazu führen, dass die Daten nicht mehr im VictoriaMetrics-Cache untergebracht werden können. Dadurch muss das System zusätzliche Arbeiten übernehmen und den Prozessor und die Festplatte stärker beanspruchen. Wenn Sie diesen Parameter zu hoch setzen, steigt erstens die Wahrscheinlichkeit, dass VictoriaMetrics mit einem 'Out of Memory'-Fehler abstürzt, und zweitens bleibt im Betriebssystem kaum noch Arbeitsspeicher für den Dateicache übrig. VictoriaMetrics ist auf den Dateicache für eine optimale Leistung angewiesen. Wenn dieser nicht ausreicht, erhöht sich die Belastung der Festplatte erheblich. Daher der Rat: Ändern Sie den Parameter nur bei absoluter Notwendigkeit.
Die zweite Option ist der retentionPeriod – der Zeitraum, der standardmäßig auf 1 Monat eingestellt ist. In diesem Zeitraum speichert VictoriaMetrics die Daten. Nach Ablauf dieser Frist löscht VictoriaMetrics die Daten.
Viele Nutzer starten VictoriaMetrics ohne diesen Parameter und speichern Daten für einen Monat. Später fragen sie: Warum sind die Daten vom vorherigen Monat verschwunden? Weil der retentionPeriod standardmäßig auf 1 Monat gesetzt ist. Daher ist es wichtig, den richtigen retentionPeriod zu kennen und einzustellen.
Lassen Sie uns die einzigartigen Funktionen durchgehen.
Thanos bietet eine Funktion namens Downsampling: 5-Minuten- und Stundenintervalle, die oft . Eine Google-Suche und ein Blick auf deren Issues auf GitHub zeigen viele Probleme im Zusammenhang mit diesem Downsampling, da es manchmal nicht richtig funktioniert oder nicht so, wie die Nutzer es erwarten.
Thanos verfügt über eine Daten-Deduplizierung für Prometheus HA-Paare. Wenn zwei Prometheus-Instanzen dieselben Metriken von denselben Zielen sammeln, kombiniert Thanos diese in einem Object Storage. Thanos kann diese Daten korrekt deduplizieren, im Gegensatz zu VictoriaMetrics.
Thanos hat eine Alert-Komponente, die in dem Thanos-Schema dargestellt ist. Es wird jedoch .
Ein Vorteil von Thanos ist, dass der Code von Thanos und Prometheus identisch ist. Beide wurden von demselben Entwicklerteam erstellt. Wenn Verbesserungen an Thanos oder Prometheus vorgenommen werden, profitieren beide Seiten davon.
Das Hauptmerkmal von VictoriaMetrics ist MetricsQL. Diese Erweiterung von VictoriaMetrics für PromQL habe ich bereits bei meinem letzten großen Monitoring-Meetup vorgestellt.
VictoriaMetrics unterstützt die Datenübertragung über eine Vielzahl unterschiedlicher Protokolle. Sie kann nicht nur Daten von Prometheus empfangen, sondern auch über Influx, OpenTSDB und Graphite.
Die gespeicherten Daten in VictoriaMetrics nehmen normalerweise deutlich weniger Platz ein als bei Thanos und Prometheus.
Bei der Speicherung echter Daten berichten Benutzer von einer Reduzierung der Datenmenge auf der Festplatte um das 2- bis 5-fache im Vergleich zu Prometheus und Thanos.
Ein weiteres Plus von VictoriaMetrics ist die Geschwindigkeit ihrer Optimierung.
Lassen Sie uns die Infrastrukturkosten durchgehen.
Ein Vorteil von Thanos ist, dass er Daten in einem Object Storage speichert, der vergleichsweise kostengünstig ist.
Bei der Speicherung von Daten im Object Storage müssen Sie die Lese- und Schreiboperationen bezahlen (10 $ pro Million Operationen). Wenn Sie Daten ins Object Storage schreiben, tragen Sie die Kosten für das Hochladen der Daten ins Internet, es sei denn, Ihr Cluster befindet sich in AWS—dort ist es kostenlos. Beim Lesen der Daten zahlen Sie zwischen 10 $ und 230 $ pro 1 TB. Das kann erheblich werden, wenn Sie häufig historische Daten aus dem Thanos-Cluster abrufen.
Für den Thanos-Cluster müssen Sie Server für die Komponenten Compact, Store Gateway und Query bezahlen, die viel Speicher und CPU für große Datenmengen benötigen.
Bei VictoriaMetrics sind die Kosten wie folgt. Wenn Sie Daten auf GCE HDD-Disketten speichern, belaufen sie sich auf 40 $ pro 1 TB. Für VictoriaMetrics sind normale HDD-Disketten ausreichend, es werden keine teuren SSDs benötigt, die fünfmal so teuer sind. VictoriaMetrics ist für HDDs optimiert.
Für VictoriaMetrics sind Server für die Komponenten erforderlich: entweder Einzelknoten oder für Clusterkomponenten, die im Gegensatz zu den Thanos-Komponenten viel weniger CPU und RAM benötigen—daher wird es günstiger sein.
Beispiele für Implementierungen.
Ein Beispiel für die Implementierung von Thanos ist Gitlab. Gitlab funktioniert vollständig mit Thanos. Aber es gibt nicht alles so reibungslos. Wenn man sich deren ... , dann zeigt sich, dass sie ständig mit irgendwelchen : es fehlt an Speicher für die Store Gateway oder Query-Komponenten. Sie müssen ständig den Speicherbedarf erhöhen.
Dadurch steigen die Kosten zur Lösung dieser Probleme.
Eine zweite Implementierung, die erfolgreicher sein könnte, ist das Unternehmen Improbable, das mit der Entwicklung von Thanos begonnen hat. Sie haben den Quellcode von Thanos veröffentlicht. Improbable ist ein Unternehmen, das sich mit der Entwicklung von Spiel-Engines beschäftigt.
Öffentliche Anwendungsbeispiele von VictoriaMetrics sind:
- wix.com Website-Builder
- Adidas implementiert VictoriaMetrics und hat sogar einen Vortrag auf der letzten PromCon 2019 gehalten.
- TrafficStars – Werbenetzwerk
- Seznam.cz – beliebte tschechische Suchmaschine.
Und dann gab es einige No-Name-Unternehmen, die ich jetzt nicht nennen kann. Sie haben keine Zustimmung gegeben.
- Ein großer Spieleentwickler. Größer als sie Improbable.
- Ein großer Entwickler von Grafiksoftware.
- Eine große russische Bank.
- Ein europäischer Hersteller von Windturbinen hat VictoriaMetrics erfolgreich getestet. Dieser Hersteller implementiert VictoriaMetrics zur Überwachung von Daten, die mit einer Rate von 50 Proben pro Sekunde von jedem Sensor der Windturbinen erfasst werden. In jeder Windturbine befinden sich mehrere Hundert Sensoren. Sie betreiben mehrere Hundert Windturbinen.
- Russische Fluggesellschaften, die VictoriaMetrics implementieren möchten, aber es bisher nicht geschafft haben. Wir stehen mit ihnen in Verhandlungen.
Fazit.
VictoriaMetrics und Thanos lösen ähnliche Aufgaben, jedoch auf unterschiedliche Weise:
- Globale Abfrageansicht
- Horizontale Skalierung
- Beliebige Retention
Danke.
Wir freuen uns auf Ihren Besuch in unserem .
Nur registrierte Benutzer können an der Umfrage teilnehmen. Sind Sie an Contour interessiert?
Was verwenden Sie als Langzeitspeicher für Prometheus?
35,3%Thanos6
0,0%Cortex0
0,0%M3DB0
41,2%VictoriaMetrics7
23,5%anderes4
17 Nutzer haben abgestimmt. 16 Nutzer haben sich enthalten.
Quelle: habr.com
