VictoriaMetrics ist ein schnelles und skalierbares DBMS zum Speichern und Verarbeiten von Daten in Form einer Zeitreihe (ein Datensatz bildet eine Zeit und einen dieser Zeit entsprechenden Satz von Werten, die beispielsweise durch eine periodische Abfrage des Status von Sensoren erhalten werden). oder das Sammeln von Metriken).
Mein Name ist Pavel Kolobaev. DevOps, SRE, LeroyMerlin, alles ist wie Code – es dreht sich alles um uns: um mich und um andere LeroyMerlin-Mitarbeiter.
Es gibt eine Cloud, die auf OpenStack basiert. Es gibt einen kleinen Link zum technischen Radar.
Es basiert auf Kubernetes-Eisen sowie allen damit verbundenen Diensten für OpenStack und Protokollierung.
Dies ist das Schema, das wir in der Entwicklung hatten. Als wir das alles entwickelten, hatten wir den Prometheus-Operator, der Daten im K8s-Cluster selbst speicherte. Er findet automatisch, was geschrubbt werden muss, und legt es, grob gesagt, unter seine Füße.
Wir müssen alle Daten außerhalb des Kubernetes-Clusters verschieben, denn wenn etwas passiert, müssen wir verstehen, was und wo.
Die erste Lösung besteht darin, dass wir die Föderation verwenden, wenn wir einen Prometheus eines Drittanbieters haben, wenn wir über den Föderationsmechanismus zum Kubernetes-Cluster wechseln.
Aber hier gibt es einige kleinere Probleme. In unserem Fall begannen die Probleme, als wir 250 Metriken hatten, und als es 000 waren, wurde uns klar, dass wir so nicht arbeiten konnten. Wir haben scrape_timeout auf 400 Sekunden erhöht.
Warum mussten wir das tun? Prometheus beginnt mit der Zählung des Timeouts ab Beginn des Abholzeitpunkts. Es spielt keine Rolle, dass die Daten immer noch einströmen. Wenn in diesem angegebenen Zeitraum die Daten nicht zusammengeführt wurden und die Sitzung nicht über http geschlossen wurde, gilt die Sitzung als fehlgeschlagen und die Daten gelangen nicht in Prometheus selbst.
Jeder kennt die Grafiken, die wir erhalten, wenn ein Teil der Daten fehlt. Die Grafiken sind zerrissen und wir sind damit nicht zufrieden.
Die nächste Option ist das Sharding basierend auf zwei verschiedenen Prometheus über denselben Föderationsmechanismus.
Nehmen Sie sie zum Beispiel einfach und teilen Sie sie mit Namen auf. Dies kann auch verwendet werden, aber wir haben uns entschieden, weiterzumachen.
Diese Scherben müssen wir nun irgendwie verarbeiten. Sie können Promxy verwenden, das in den Shard-Bereich absteigt und die Daten multipliziert. Es funktioniert mit zwei Shards als einem einzigen Einstiegspunkt. Dies kann über promxy implementiert werden, ist aber im Moment zu kompliziert.
Die erste Option besteht darin, den Föderationsmechanismus aufzugeben, da er sehr langsam ist.
Die Prometheus-Entwickler sagen ausdrücklich: „Leute, nutzt andere TimescaleDB, denn wir werden keine Langzeitspeicherung von Metriken unterstützen.“ Das ist nicht ihre Aufgabe.
Wir notieren auf einem Zettel, dass wir noch draußen abladen müssen, um nicht alles an einem Ort aufzubewahren.
Der zweite Nachteil ist der Speicherverbrauch. Ja, ich verstehe, dass viele sagen werden, dass im Jahr 2020 ein paar Gigabyte Speicher einen Cent wert sind, aber trotzdem.
Jetzt haben wir eine Entwicklungs- und eine Produktionsumgebung. In der Entwicklung sind das etwa 9 Gigabyte pro 350 Metriken. In Prod sind das 000 Gigabyte mit kleinen 14 Metriken. Gleichzeitig haben wir nur eine Retentionszeit von 780 Minuten. Das ist schlecht. Und jetzt werde ich erklären, warum.
Wir machen eine Berechnung, also mit eineinhalb Millionen Metriken, und wir sind schon nah dran, in der Entwurfsphase bekommen wir 35-37 Gigabyte Speicher. Aber bereits bei 4 Millionen Metriken werden etwa 90 Gigabyte Speicher benötigt. Das heißt, es wurde nach der von den Prometheus-Entwicklern bereitgestellten Formel berechnet. Wir haben uns den Zusammenhang angeschaut und festgestellt, dass wir nicht ein paar Millionen für einen Server nur für die Überwachung ausgeben wollen.
Wir werden nicht nur die Anzahl der Maschinen erhöhen, sondern auch die virtuellen Maschinen selbst überwachen. Daher gilt: Je mehr virtuelle Maschinen, desto mehr Metriken verschiedener Art usw. Wir werden ein besonderes Wachstum unseres Clusters in Bezug auf Metriken verzeichnen.
Mit dem Speicherplatz ist hier nicht alles so traurig, aber ich würde es gerne verbessern. Wir haben in 15 Tagen insgesamt 120 Gigabyte erhalten, davon 100 komprimierte Daten, 20 unkomprimierte Daten, aber weniger will man immer.
Dementsprechend schreiben wir noch einen Punkt auf: Dies ist ein großer Ressourcenverbrauch, den wir noch einsparen möchten, da wir nicht möchten, dass unser Überwachungscluster mehr Ressourcen verbraucht als unser Cluster, der OpenStack verwaltet.
Es gibt noch einen weiteren Nachteil von Prometheus, den wir selbst identifiziert haben, nämlich zumindest eine Art Speicherbeschränkung. Bei Prometheus ist hier alles viel schlimmer, weil er solche Wendungen überhaupt nicht hat. Die Verwendung des Docker-Limits ist ebenfalls keine Option. Wenn Ihr RAF plötzlich ausfällt und 20 bis 30 Gigabyte vorhanden sind, wird es sehr lange dauern, bis es wieder ansteigt.
Auch deshalb ist Prometheus für uns nicht geeignet, d. h. wir können den Speicherverbrauch nicht begrenzen.
Es wäre möglich, ein solches Schema zu entwickeln. Wir benötigen dieses Schema, um einen HA-Cluster zu organisieren. Wir möchten, dass unsere Metriken jederzeit und überall verfügbar sind, auch wenn der Server, der diese Metriken speichert, ausfällt. Und deshalb müssen wir ein solches System aufbauen.
Dieses Schema besagt, dass wir eine Verdoppelung der Shards und dementsprechend eine Verdoppelung der Kosten der verbrauchten Ressourcen haben werden. Es kann fast horizontal skaliert werden, aber der Ressourcenverbrauch wird trotzdem höllisch sein.
Nachteile in der Reihenfolge, in der wir sie für uns selbst aufgeschrieben haben:
- Erfordert das Hochladen von Metriken nach außen.
- Hoher Ressourcenverbrauch.
- Sie können den Speicherverbrauch nicht begrenzen.
- Komplizierte und ressourcenintensive Implementierung von HA.
Für uns selbst haben wir beschlossen, dass wir uns von Prometheus als Aufbewahrungsort verabschieden.
Wir haben zusätzliche Anforderungen an uns selbst identifiziert, die wir benötigen. Das:
- Dies ist Promql-Unterstützung, da bereits viel für Prometheus geschrieben wurde: Abfragen, Warnungen.
- Und dann haben wir noch Grafana, das bereits unter Prometheus als Backend auf die gleiche Weise geschrieben ist. Ich möchte keine Dashboards neu schreiben.
- Wir wollen eine normale HA-Architektur aufbauen.
- Wir wollen den Verbrauch jeglicher Ressourcen reduzieren.
- Es gibt noch eine weitere kleine Nuance. Wir können nicht verschiedene Arten von Cloud-Systemen zur Erfassung von Metriken verwenden. Wir wissen vorerst nicht, was in diese Kennzahlen einfließen wird. Und da dort alles fliegen kann, müssen wir uns auf die Platzierung vor Ort beschränken.
Die Auswahl war gering. Wir haben alles gesammelt, wozu wir Erfahrungen hatten. Wir haben uns die Prometheus-Seite im Integrationsbereich angesehen, eine Reihe von Artikeln gelesen und uns angesehen, was allgemein verfügbar ist. Und wir haben uns für VictoriaMetrics als Ersatz für Prometheus entschieden.
Warum? Weil:
- Kann Promql ausführen.
- Es gibt eine modulare Architektur.
- Erfordert keine Änderungen an Grafana.
- Und was am wichtigsten ist: Wir werden in unserem Unternehmen wahrscheinlich eine Speicherung von Metriken als Service bereitstellen, daher prüfen wir im Voraus verschiedene Arten von Einschränkungen, damit Benutzer alle Ressourcen des Clusters in begrenztem Umfang nutzen können, da dies möglich ist dass es mandantenfähig sein wird.
Wir machen den ersten Vergleich. Wir nehmen denselben Prometheus innerhalb des Clusters, externer Prometheus geht dorthin. Wir fügen über remoteWrite VictoriaMetrics hinzu.
Ich mache gleich einen Vorbehalt, dass wir hier einen leichten Anstieg des CPU-Verbrauchs von VictoriaMetrics feststellen konnten. Das VictoriaMetrics-Wiki sagt, welche Parameter am besten geeignet sind. Wir haben sie überprüft. Sie haben den CPU-Verbrauch sehr gut reduziert.
In unserem Fall ist der Speicherverbrauch von Prometheus, das sich in einem Kubernetes-Cluster befindet, nicht wesentlich gestiegen.
Wir vergleichen zwei Datenquellen derselben Daten. In Prometheus sehen wir dieselben fehlenden Daten. Bei VictoriaMetrics ist alles gut.
Ergebnisse von Tests mit Speicherplatz. Wir bei Prometheus haben insgesamt 120 Gigabyte. Bei VictoriaMetrics bekommen wir bereits 4 Gigabyte pro Tag. Es gibt einen etwas anderen Mechanismus als den, den Sie von Prometheus gewohnt sind. Das heißt, die Daten sind für einen Tag, für eine halbe Stunde schon recht gut komprimiert. Sie sind bereits an einem Tag, in einer halben Stunde gut geerntet, obwohl die Daten später zusammengeführt werden. Dadurch haben wir Speicherplatz gespart.
Wir sparen auch den Verbrauch von Speicherressourcen. Zum Zeitpunkt der Tests hatten wir Prometheus auf einer virtuellen Maschine bereitgestellt – 8 Kerne, 24 Gigabyte. Prometheus isst fast alles. Er fiel auf OOM Killer. Gleichzeitig wurden nur 900 aktive Metriken eingespeist. Das sind etwa 000–25 Messwerte pro Sekunde.
VictoriaMetrics lief auf einer virtuellen Dual-Core-Maschine mit 8 Gigabyte RAM. Wir haben es geschafft, dass VictoriaMetrics gut funktioniert, indem wir einige Dinge auf einem 8-GB-Rechner optimiert haben. Dadurch haben wir die Grenze von 7 Gigabyte eingehalten. Gleichzeitig ist die Geschwindigkeit der Inhaltsbereitstellung, also der Kennzahlen, sogar noch höher als bei Prometheus.
Die CPU ist viel besser als Prometheus. Hier verbraucht Prometheus 2,5 Kerne und VictoriaMetrics nur 0,25 Kerne. Zu Beginn - 0,5 Kerne. Beim Verschmelzen erreicht es einen Kern, aber das kommt äußerst, äußerst selten vor.
In unserem Fall fiel die Wahl aus offensichtlichen Gründen auf VictoriaMetrics, wir wollten Geld sparen und haben gespart.
Zwei Punkte streichen wir gleich vorweg – das ist die Entlastung von Metriken und ein hoher Ressourcenverbrauch. Und es bleibt uns überlassen, zwei Punkte zu entscheiden, die wir uns noch selbst überlassen haben.
Hier mache ich gleich eine Reservierung, wir betrachten VictoriaMetrics als eine Sammlung von Metriken. Da wir jedoch höchstwahrscheinlich VictoriaMetrics als Speicher für alle Leroy bereitstellen werden, müssen wir diejenigen einschränken, die diesen Cluster verwenden, damit sie ihn uns nicht zur Verfügung stellen.
Es gibt einen wunderbaren Parameter, mit dem Sie die Zeit, die Datenmenge und die Ausführungszeit begrenzen können.
Und es gibt auch eine hervorragende Option, mit der Sie den Speicherverbrauch begrenzen können, sodass wir genau das Gleichgewicht finden können, das uns eine normale Geschwindigkeit und einen angemessenen Ressourcenverbrauch ermöglicht.
Minus noch ein Punkt, das heißt, wir streichen den Punkt – Sie können den Speicherverbrauch nicht begrenzen.
In den ersten Iterationen haben wir den VictoriaMetrics Single Node getestet. Als nächstes gehen wir zur VictoriaMetrics Cluster-Version über.
Hier haben wir freie Hand bei der Trennung verschiedener Dienste in VictoriaMetrics, je nachdem, worauf sie sich konzentrieren und welche Ressourcen sie verbrauchen. Dies ist eine sehr flexible und bequeme Lösung. Wir haben es selbst genutzt.
Die Hauptkomponenten der VictoriaMetrics Cluster-Version sind vmstsorage. Es kann eine N-Nummer geben. In unserem Fall sind es 2 davon.
Und es gibt vminsert. Dabei handelt es sich um einen Proxy-Server, der es uns ermöglicht: Sharding zwischen allen Speichern, von denen wir ihm erzählt haben, zu arrangieren, und der ein weiteres Replikat ermöglicht, d. h. Sie haben sowohl Sharding als auch ein Replikat.
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 dort abzurufen, diese Daten zu deduplizieren und sie dem Client zu übergeben.
Es gibt eine wunderbare Sache wie vmagent. Wir mögen sie wirklich. Sie können damit genau wie Prometheus konfigurieren und trotzdem alles genau wie Prometheus erledigen. Das heißt, es sammelt Metriken von verschiedenen Entitäten und Diensten und sendet sie an vminsert. Dann hängt alles von dir ab.
Ein weiterer toller Dienst ist vmalert, der es Ihnen ermöglicht, VictoriaMetrics als Backend zu verwenden, verarbeitete Daten von vminsert zu empfangen und verarbeitete Daten an vmselect zu senden. Es verarbeitet die Warnungen selbst sowie die Regeln. Im Falle von Alarmen erhalten wir eine Benachrichtigung über den Alertmanager.
Es gibt eine wmauth-Komponente. Wir werden es wahrscheinlich und vielleicht auch nicht (wir haben uns noch nicht dazu entschieden) als Autorisierungssystem für Multitenancy-Versionen von Clustern verwenden. Es unterstützt remoteWrite für Prometheus und kann basierend auf der URL bzw. dem zweiten Teil davon autorisieren, wo Sie schreiben können oder nicht.
Es gibt auch vmbackup und vmrestore. Dabei handelt es sich tatsächlich um die Wiederherstellung und Sicherung aller Daten. Fähig zu S3, GCS, Datei.
Die erste Iteration unseres Clusters wurde während der Quarantäne durchgeführt. Zu diesem Zeitpunkt gab es kein Replikat, daher bestand unsere Iteration aus zwei verschiedenen und unabhängigen Clustern, in die wir Daten über remoteWrite erhielten.
Hier mache ich einen Vorbehalt, dass wir beim Wechsel von VictoriaMetrics Single Node zur VictoriaMetrics Cluster-Version immer noch die gleichen verbrauchten Ressourcen hatten, d. h. die wichtigste ist der Speicher. Ungefähr auf diese Weise wurden unsere Daten verteilt, d. H. Ressourcenverbrauch.
Eine Replik wurde hier bereits hinzugefügt. Das alles haben wir zu einem relativ großen Cluster zusammengefasst. Alle Daten werden sowohl fragmentiert als auch repliziert.
Der gesamte Cluster verfügt über N Einstiegspunkte, d. h. Prometheus kann über HAPROXY Daten hinzufügen. Hier ist unser Einstiegspunkt. Und über diesen Einstiegspunkt können Sie sich mit Grafana anmelden.
In unserem Fall ist HAPROXY der einzige Port, der ausgewählte, eingefügte und andere Dienste in diesem Cluster weiterleitet. In unserem Fall war es unmöglich, eine Adresse festzulegen, wir mussten mehrere Einstiegspunkte festlegen, da sich die virtuellen Maschinen selbst, auf denen der VictoriaMetrics-Cluster läuft, in verschiedenen Zonen desselben Cloud-Anbieters befinden, also nicht innerhalb unserer Cloud , aber draußen.
Wir haben eine Warnung. Wir nutzen es. Wir verwenden den Alertmanager von Prometheus. Wir nutzen Opsgenie und Telegram als Benachrichtigungskanal. In Telegram strömen sie von Entwicklern, vielleicht etwas von Produkt, aber eher etwas Statistisches, das Ingenieure brauchen. Und Opsgenie ist entscheidend. Das sind Anrufe, Incident Management.
Die uralte Frage: „Wer überwacht die Überwachung?“ In unserem Fall überwacht die Überwachung die Überwachung selbst, da wir auf jedem Knoten vmagent verwenden. Und da sich unsere Knoten in verschiedenen Rechenzentren desselben Anbieters befinden, verfügt jedes Rechenzentrum über einen eigenen Kanal, sie sind unabhängig und selbst wenn es zu einem Split Brain kommt, erhalten wir dennoch Benachrichtigungen. Ja, es wird mehr davon geben, aber es ist besser, mehr Benachrichtigungen zu erhalten als keine.
Wir beenden unsere Liste mit der Implementierung von HA.
Darüber hinaus möchte ich auf die Erfahrungen bei der Kommunikation mit der VictoriaMetrics-Community hinweisen. Es stellte sich als sehr positiv heraus. Jungs sind ansprechbar. Sie versuchen, sich mit jedem angebotenen Fall auseinanderzusetzen.
Ich habe Probleme auf GitHub gemacht. Sie wurden sehr schnell gelöst. Es gibt noch ein paar weitere Probleme, die noch nicht vollständig behoben sind, aber ich kann dem Code bereits entnehmen, dass in dieser Richtung gearbeitet wird.
Der Hauptschmerz während der Iterationen bestand für mich darin, dass vminsert in den ersten 30 Sekunden nicht verstehen konnte, dass es kein Backend gab, wenn ich den Knoten abschaltete. Nun ist es bereits entschieden. Und buchstäblich in ein oder zwei Sekunden werden die Daten von allen verbleibenden Knoten übernommen und die Anfrage hört auf, auf diesen fehlenden Knoten zu warten.
Wir wollten, dass VictoriaMetrics irgendwann der VictoriaMetrics-Betreiber wird. Wir haben auf ihn gewartet. Wir bauen jetzt aktiv eine Bindung über den VictoriaMetrics-Operator auf, um alle Vorberechnungsregeln usw. zu übernehmen. Prometheus, weil wir die Regeln, die mit dem Prometheus-Operator einhergehen, ziemlich aktiv nutzen.
Es gibt Vorschläge zur Verbesserung der Cluster-Implementierung. Ich habe sie oben skizziert.
Und ich möchte auch wirklich Downsampling. In unserem Fall wird das Downsampling ausschließlich zur Anzeige von Trends benötigt. Grob gesagt reicht mir tagsüber eine Metrik. Diese Trends werden für ein Jahr, drei, fünf, zehn Jahre benötigt. Und ein metrischer Wert reicht aus.
- Wir haben, wie auch einige unserer Kollegen, bei der Anwendung von Prometheus Schmerzen erlebt.
- Wir haben uns für VictoriaMetrics entschieden.
- Es lässt sich sowohl vertikal als auch horizontal recht gut skalieren.
- Wir können verschiedene Komponenten auf eine unterschiedliche Anzahl von Knoten im Cluster verteilen, sie hinsichtlich des Speichers begrenzen, Speicher hinzufügen usw.
Wir werden VictoriaMetrics zu Hause nutzen, weil es uns sehr gut gefallen hat. Hier ist, was passiert ist und was passiert ist.
Ein paar QR-Codes für den VictoriaMetrics-Chat, meine Kontakte, das technische Radar von LeroyMerlin.
Source: habr.com