VictoriaMetrics – eine schnelle und skalierbare Datenbank zur Speicherung und Verarbeitung von Daten in Form von Zeitreihen (ein Datensatz besteht aus Zeit und einer Menge entsprechender Werte, beispielsweise von periodischen Abfragen des Zustands von Sensoren oder der Sammlung von Metriken).
Ich heiße Kolobaev Pavel. DevOps, SRE, LeroyMerlin, alles als Code – das bezieht sich auf uns: auf mich und auf andere Mitarbeiter von LeroyMerlin.
Es gibt eine Cloud auf Basis von OpenStack. Dort ist ein kurzer Link zum Tech Radar.
Es basiert auf Kubernetes-Hardware sowie auf allen zugehörigen Diensten zu OpenStack und Logging.
So sah unser Schema in der Entwicklung aus. Als wir das alles entwickelten, hatten wir einen Prometheus-Operator, der die Daten im Inneren des K8s-Clusters speicherte. Er findet automatisch das, was er speichern muss, und legt es sich sozusagen unter die Füße.
Alle Daten müssen wir aus dem Kubernetes-Cluster exportieren, denn wenn etwas passiert, müssen wir verstehen, was und wo ist.
Die erste Lösung – wir verwenden Federation, wenn wir einen externen Prometheus haben, wenn wir über den Federation-Mechanismus auf das Kubernetes-Cluster zugreifen.
Aber hier gibt es kleine Probleme. In unserem Fall begannen die Probleme, als wir 250.000 Metriken hatten, und als es 400.000 Metriken wurden, stellten wir fest, dass wir so nicht arbeiten können. Wir haben die scrape_timeout auf 25 Sekunden verlängert.
Warum mussten wir das tun? Prometheus beginnt, die Zeit des Timeouts ab dem Zeitpunkt zu zählen, an dem die Abfrage erfolgt. Und es spielt keine Rolle, dass die Daten weiterhin fließen. Wenn in diesem angegebenen Zeitraum keine Daten übertragen werden und die Sitzung nicht über http geschlossen wird, gilt die Sitzung als fehlgeschlagen, und die Daten gelangen nicht in den Prometheus.
Jeder kennt die Grafiken, die wir erhalten, wenn Teile der Daten fehlen. Die Grafiken sind unregelmäßig, und das gefällt uns nicht.
Die nächste Option ist Sharding auf Basis von zwei verschiedenen Prometheus durch denselben Federation-Mechanismus.
Wir könnten sie einfach nach Namen sharden. Das kann man auch verwenden, aber wir haben entschieden, weiterzugehen.
Wir müssen nun diese Shards irgendwie verarbeiten. Man kann promxy verwenden, welches in den Shard-Bereich geht und die Daten vervielfältigt. Es arbeitet mit zwei Shards als mit einem einzigen Einstiegspunkt. Das kann man über promxy umsetzen, ist aber momentan zu kompliziert.
Die erste Option – wir möchten auf den Federation-Mechanismus verzichten, da er sehr langsam ist.
Die Entwickler von Prometheus sagen eindeutig: „Jungs, verwendet andere TimescaleDB, denn wir werden die langfristige Speicherung von Metriken nicht unterstützen“. Das ist nicht ihre Aufgabe. 
Wir notieren uns auf einem Zettel, dass wir tatsächlich einen Export nach außen benötigen, um nicht alles an einem Ort zu speichern.
Der zweite Nachteil ist der Speicherverbrauch. Ja, ich verstehe, dass viele sagen werden, dass ein paar Gigabyte RAM im Jahr 2020 ein Klacks sind, aber nichtsdestotrotz.
Aktuell haben wir eine Dev- und eine Prod-Umgebung. In Dev sind es etwa 9 Gigabyte bei 350.000 Metriken. In Prod sind es über 14 Gigabyte bei 780.000 Metriken. Dabei liegt unsere Retention-Time nur bei 30 Minuten. Das ist schlecht. Und ich erkläre jetzt, warum.
Wir machen eine Berechnung, d. h. bei eineinhalb Millionen Metriken, und wir sind diesen Zahlen bereits nahe, gelangen wir in der Planungsphase auf 35-37 Gigabyte RAM. Bei 4 Millionen Metriken werden bereits etwa 90 Gigabyte RAM benötigt. Das wurde mit der Formel berechnet, die die Entwickler von Prometheus bereitstellen. Wir haben die Korrelation betrachtet und festgestellt, dass wir nicht bereit sind, mehrere Millionen für einen Server nur für Monitoring zu zahlen.
Unsere Anzahl an Maschinen wird nicht nur steigen, wir überwachen auch die virtuellen Maschinen selbst. Deshalb gilt: Je mehr virtuelle Maschinen, desto mehr unterschiedliche Metriken etc. Unser Cluster wird in Bezug auf Metriken speziell wachsen.
Mit dem Speicherplatz ist die Situation hier nicht ganz so schlecht, aber wir möchten es verbessern. Wir haben in 15 Tagen insgesamt 120 Gigabyte erhalten, davon sind 100 Gigabyte komprimierte Daten und 20 Gigabyte unkomprimierte Daten, aber weniger wäre immer besser.
Daher notieren wir einen weiteren Punkt – den hohen Ressourcenverbrauch, den wir gerne senken würden, da wir nicht möchten, dass unser Monitoring-Cluster mehr Ressourcen frisst als unser Cluster, der für die Verwaltung von OpenStack zuständig ist.
Es gibt noch einen Nachteil von Prometheus, den wir festgestellt haben, und zwar eine Art Speicherbegrenzung. Bei Prometheus ist die Situation hier deutlich schlechter, da es überhaupt keine solchen Möglichkeiten gibt. Eine Begrenzung in Docker zu verwenden, ist ebenfalls keine Option. Wenn Ihr RAF abstürzt und dort 20-30 Gigabyte anfallen, wird es sehr lange dauern, bis es wieder hochfährt.
Das ist ein weiterer Grund, warum Prometheus für uns nicht geeignet ist, d. h. weil man den Speicherverbrauch nicht begrenzen kann.
Es könnte ein solches Schema entwickelt werden. Dieses Schema benötigen wir, um einen HA-Cluster zu organisieren. Wir möchten, dass unsere Metriken immer und überall verfügbar sind, selbst bei Ausfällen des Servers, der diese Metriken speichert. Daher müssen wir ein solches Schema aufbauen.
Dieses Schema besagt, dass wir eine Duplizierung von Shards haben werden, und damit auch eine Duplizierung der Ressourcenkosten. Es kann fast horizontal skaliert werden, aber dennoch wird der Ressourcenverbrauch enorm sein.
Die Nachteile in der Reihenfolge, in der wir sie für uns aufgeschrieben haben:
- Es ist erforderlich, Metriken nach außen zu exportieren.
- Hoher Ressourcenverbrauch.
- Es kann kein begrenzter Speicherverbrauch festgelegt werden.
- Komplexe und ressourcenintensive Umsetzung von HA.
Wir haben beschlossen, von Prometheus als Speicher abzusehen.
Wir haben noch zusätzliche Anforderungen definiert, die wir benötigen. Das sind:
- Die Unterstützung von promql, da bereits viel für Prometheus geschrieben wurde: Abfragen, Alarme.
- Und dann haben wir Grafana, die ebenfalls für Prometheus als Backend geschrieben wurde. Wir möchten die Dashboards nicht neu schreiben.
- Wir möchten eine ordentliche HA-Architektur aufbauen.
- Wir möchten den Verbrauch aller Ressourcen reduzieren.
- Es gibt noch einen kleinen Punkt. Wir können keine verschiedenen Arten von Cloud-Systemen zur Metrik-Sammlung verwenden. Wir wissen nicht, was in diese Metriken eingehen wird. Und da alles Mögliche dort gelangen kann, sind wir gezwungen, uns auf lokale Unterbringung zu beschränken.
Die Auswahl war gering. Wir haben alles gesammelt, wo wir Erfahrung haben. Wir haben die Seite von Prometheus im Bereich Integration angeschaut, viele Artikel gelesen, geschaut, was es überhaupt gibt. Und für uns haben wir VictoriaMetrics als Ersatz für Prometheus gewählt.
Warum? Weil:
- Es unterstützt promql.
- Es hat eine modulare Architektur.
- Es erfordert keine Änderungen in Grafana.
- Und das Wichtigste ist – möglicherweise werden wir die Metrikspeicherung innerhalb unserer Firma als Dienstleistung anbieten, daher schauen wir im Voraus in Richtung von Einschränkungen, damit die Benutzer alle Ressourcen des Clusters in einem bestimmten Umfang nutzen können, da die Möglichkeit besteht, dass es eine Multi-Tenant-Umgebung sein wird.
Wir machen die ersten Vergleiche. Wir nehmen das gleiche Prometheus innerhalb des Clusters, zu dem ein externes Prometheus zugreift. Wir fügen VictoriaMetrics über remoteWrite hinzu.
Ich möchte gleich klarstellen, dass wir hier eine kleine Erhöhung des CPU-Verbrauchs bei VictoriaMetrics festgestellt haben. Auf der VictoriaMetrics-Wiki steht, welche Parameter am besten geeignet sind. Wir haben diese überprüft. Sie haben den CPU-Verbrauch erheblich gesenkt.
In unserem Fall ist der Speicherverbrauch von Prometheus, der sich im Kubernetes-Cluster befindet, nicht signifikant gestiegen.
Wir vergleichen zwei Datenquellen mit denselben Daten. In Prometheus sehen wir all die fehlenden Daten. In VictoriaMetrics ist alles in Ordnung.
Testergebnisse zum Speicherplatz. In Prometheus haben wir insgesamt 120 Gigabyte erhalten. In VictoriaMetrics erhalten wir bereits 4 Gigabyte pro Tag. Dort gibt es einen etwas anderen Mechanismus als bei Prometheus. Das heißt, die Daten werden bereits sehr gut komprimiert, sowohl über einen Tag als auch über eine halbe Stunde. Sie sind bereits gut komprimiert, trotz der bevorstehenden Datenfusion. Letztendlich haben wir beim Speicherplatz gespart.
Wir sparen auch beim Ressourcenverbrauch des Speichers. Prometheus war zum Zeitpunkt der Tests auf einer virtuellen Maschine mit 8 Kernen und 24 Gigabyte ausgeführt. Prometheus beansprucht praktisch alles. Er wurde durch den OOM Killer beendet. Dabei hatte er nur 900.000 aktive Metriken. Das sind etwa 25.000-27.000 Metriken pro Sekunde.
VictoriaMetrics lief bei uns auf einer virtuellen Maschine mit zwei Kernen und 8 Gigabyte RAM. Es gelang uns, VictoriaMetrics gut zum Laufen zu bringen, indem wir einige Dinge auf der 8-Gigabyte-Maschine optimierten. Letztendlich blieben wir bei 7 Gigabyte. Dabei erhielten wir eine schnellere Ausgabe von Inhalten, also von Metriken, sogar über der von Prometheus.
Der CPU-Verbrauch ist im Vergleich zu Prometheus viel besser geworden. Hier verbraucht Prometheus 2,5 Kerne, während VictoriaMetrics nur 0,25 Kerne benötigt. Zu Beginn – 0,5 Kerne. Im Laufe der Datenfusion erreicht sie ein Kern, aber das ist äußerst selten.
In unserem Fall fiel die Wahl auf VictoriaMetrics aus offensichtlichen Gründen, wir wollten sparen, und das haben wir auch.
Wir streichen sofort zwei Punkte – das Auslesen der Metriken und den hohen Ressourcenverbrauch. Es bleiben uns zwei Punkte, die wir noch für uns klären müssen.
Hier möchte ich gleich klarstellen, dass wir VictoriaMetrics als Metrikspeicher betrachten. Da wir VictoriaMetrics wahrscheinlich als Speicher für das gesamte Leroy anbieten werden, müssen wir die Personen, die diesen Cluster nutzen, einschränken, damit sie uns nicht überlasten.
Es gibt einen hervorragenden Parameter, der es ermöglicht, zeitliche, volumetrische und zeitliche Ausführungsgrenzen festzulegen.
Außerdem gibt es eine ausgezeichnete Option, die den Speicherverbrauch einschränkt, sodass wir das Gleichgewicht finden können, das uns eine normale Arbeitsgeschwindigkeit und eine angemessene Ressourcennutzung ermöglicht.
Ein weiterer Nachteil, d. h. wir streichen den Punkt – man kann den Speicherverbrauch nicht beschränken.
In den ersten Iterationen haben wir VictoriaMetrics Single Node getestet. Danach wechseln wir zur VictoriaMetrics Cluster Version.
Hier haben wir die Freiheit, verschiedene Dienste in VictoriaMetrics je nach dem, worauf sie laufen und welche Ressourcen sie verbrauchen, zu verteilen. Das ist eine sehr flexible und bequeme Lösung. Wir haben sie selbst verwendet.
Die Hauptkomponenten der VictoriaMetrics Cluster Version sind vmstorage. Es können N Anzahl sein. In unserem Fall sind es bis jetzt 2.
Und es gibt vminsert. Dies ist ein Proxy-Server, der es uns ermöglicht: Sharding zwischen allen Storages zu arrangieren, die wir ihm mitgeteilt haben, und er ermöglicht auch Replikation, d. h. Sie haben sowohl Sharding als auch Replikation.
Vminsert unterstützt die Protokolle OpenTSDB, Graphite, InfluxDB und remoteWrite von Prometheus.
Es gibt auch vmselect. Seine Hauptaufgabe besteht darin, zu vmstorage zu gehen, Daten von ihnen abzurufen, diese Daten zu deduplizieren und sie dem Kunden zu übergeben.
Es gibt ein großartiges Tool namens vmagent. Es gefällt uns sehr. Es ermöglicht eine Konfiguration, die genau wie bei Prometheus ist, und funktioniert dabei genau wie Prometheus. D. h. es sammelt Metriken von verschiedenen Entitäten und Diensten und sendet sie an vminsert. Danach hängt alles von Ihnen ab.
Ein weiterer großartiger Dienst ist vmalert, der es ermöglicht, VictoriaMetrics als Backend zu verwenden, verarbeitet Daten von vminsert und sendet sie an vmselect. Es verarbeitet die Alarme sowie die Regeln. Bei Alarmen erhalten wir die Warnung über alertmanager.
Es gibt die Komponente wmauth. Diese könnte möglicherweise verwendet werden, oder auch nicht (wir haben uns noch nicht entschieden), als Authentifizierungssystem für die Multitenancy-Versionen der Cluster. Es unterstützt remoteWrite für Prometheus und kann anhand der URL autorisieren, genauer gesagt, ihres zweiten Teils, wohin Sie schreiben dürfen oder nicht.
Es gibt auch vmbackup, vmrestore. Dies ist im Wesentlichen die Wiederherstellung und Sicherung aller Daten. Es unterstützt S3, GCS, file.
Die erste Iteration unseres Clusters fand während der Quarantäne statt. Zu diesem Zeitpunkt gab es keine Replikation, daher stellte unsere Iteration zwei verschiedene und unabhängige Cluster dar, aus denen wir über remoteWrite Daten erhielten.
Hier möchte ich anmerken, dass wir beim Wechsel von VictoriaMetrics Single Node zur VictoriaMetrics Cluster Version in Bezug auf den Ressourcenverbrauch, d. h. hauptsächlich den Speicher, gleich geblieben sind. So haben sich unsere Daten verteilt, d. h. der Ressourcenverbrauch.
Hier wurde bereits eine Replikation hinzugefügt. Wir haben alles in einem relativ großen Cluster zusammengeführt. Unsere Daten werden sowohl shardiert als auch repliziert.
Der gesamte Cluster hat N Eingänge, d. h. Prometheus kann Daten über HAPROXY hinzufügen. Hier ist unser Einstiegspunkt. Und über diesen Eingangspunkt kann man mit Grafana zugreifen.
In unserem Fall ist HAPROXY der einzige Port, der Select, Insert und andere Dienste in dieses Cluster proxiert. Da es uns nicht möglich war, eine einzige Adresse zu erstellen, mussten wir mehrere Eingänge machen, da die virtuellen Maschinen, auf denen der VictoriaMetrics-Cluster läuft, in verschiedenen Zonen eines Cloud-Anbieters sind, d. h. außerhalb unserer Cloud.
Wir haben Alerting. Wir nutzen es. Wir verwenden den Alertmanager von Prometheus. Als Kanal für die Zustellung der Alarme nutzen wir Opsgenie und Telegram. In Telegram gibt es Benachrichtigungen von dev, vielleicht etwas von prod, aber eher etwas Statistisches, das für Ingenieure wichtig ist. Opsgenie ist kritisch. Das sind Anrufe, das Management von Vorfällen.
Die ewige Frage: „Wer überwacht die Überwachung?“ In unserem Fall überwacht die Überwachung sich selbst, da wir vmagent auf jeder Node verwenden. Da unsere Nodes über verschiedene Rechenzentren eines Anbieters verteilt sind, hat jedes Rechenzentrum seinen eigenen Kanal, der unabhängig ist, und selbst wenn ein Split-Brain auftritt, erhalten wir immer noch Alarme. Ja, es werden mehr sein, aber es ist besser, mehr Alarme zu erhalten als gar keine.
Wir beenden unsere Liste mit der Umsetzung von HA.
Und ich möchte die positive Erfahrung mit der VictoriaMetrics-Community hervorheben. Es war sehr positiv. Die Leute sind hilfsbereit. Sie versuchen, sich in jeden Fall einzuarbeiten, der vorgeschlagen wird.
Ich habe Issues auf GitHub erstellt. Sie wurden sehr schnell gelöst. Es gibt noch ein paar Issues, die nicht vollständig abgeschlossen sind, aber ich sehe bereits im Code, dass die Arbeit in diese Richtung läuft.
Der Hauptschmerz während der Iterationen für mich war, dass wenn ich einen Knoten abschalte, das vminsert in den ersten 30 Sekunden nicht verstehen konnte, dass der Backend nicht vorhanden ist. Das ist jetzt gelöst. Und in buchstäblich einer oder zwei Sekunden werden die Daten bereits von allen verbleibenden Knoten abgerufen, und die Anfrage hört auf, auf den fehlenden Knoten zu warten.
Wir wollten irgendwann, dass es einen VictoriaMetrics-Operator gibt. Darauf haben wir gewartet. Jetzt sind wir aktiv dabei, eine Wrapper-Umgebung für den VictoriaMetrics-Operator aufzubauen, um alle Vorberechnungsregeln usw. von Prometheus zu übernehmen, da wir die Regeln, die mit dem Prometheus-Operator geliefert werden, ziemlich aktiv nutzen.
Es gibt Vorschläge zur Verbesserung der Cluster-Implementierung. Ich habe sie oben aufgeführt.
Und ich hätte auch sehr gerne Downsampling. In unserem Fall wird Downsampling ausschließlich für die Anzeige von Trends benötigt. Grob gesagt, eine Metrik reicht mir tagsüber aus. Diese Trends sind für ein Jahr, drei Jahre, fünf Jahre, zehn Jahre notwendig. Und ein einziger Wert der Metrik reicht völlig aus.
- Wir haben wie einige unserer Kollegen die Schmerzpunkte beim Einsatz von Prometheus erkannt.
- Wir haben uns für VictoriaMetrics entschieden.
- Es skalierbar sowohl vertikal als auch horizontal sehr gut.
- Wir können verschiedene Komponenten auf verschiedene Knoten im Cluster verteilen, sie in Bezug auf den Speicher begrenzen, Speicher hinzufügen usw.
Wir werden VictoriaMetrics bei uns einsetzen, da es uns sehr gefallen hat. So war es vorher und so ist es jetzt.
Ein paar QR-Codes für den VictoriaMetrics-Chat, meine Kontakte, Tech-Radar von LeroyMerlin.
Quelle: habr.com
