{"id":94153,"date":"2020-09-13T19:42:30","date_gmt":"2020-09-13T17:42:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev"},"modified":"2020-09-13T19:42:30","modified_gmt":"2020-09-13T17:42:30","slug":"victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics und die \u00dcberwachung privater Clouds. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics \u2013 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).<\/p>\n

<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ich hei\u00dfe Kolobaev Pavel. DevOps, SRE, LeroyMerlin, alles als Code \u2013 das bezieht sich auf uns: auf mich und auf andere Mitarbeiter von LeroyMerlin.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

https:\/\/bit.ly\/3jf1fIK<\/a><\/noindex><\/p>\n

<\/p>\n

Es gibt eine Cloud auf Basis von OpenStack. Dort ist ein kurzer Link zum Tech Radar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Es basiert auf Kubernetes-Hardware sowie auf allen zugeh\u00f6rigen Diensten zu OpenStack und Logging. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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\u00fc\u00dfe. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Alle Daten m\u00fcssen wir aus dem Kubernetes-Cluster exportieren, denn wenn etwas passiert, m\u00fcssen wir verstehen, was und wo ist. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Die erste L\u00f6sung \u2013 wir verwenden Federation, wenn wir einen externen Prometheus haben, wenn wir \u00fcber den Federation-Mechanismus auf das Kubernetes-Cluster zugreifen.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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\u00f6nnen. Wir haben die scrape_timeout auf 25 Sekunden verl\u00e4ngert.<\/p>\n

<\/p>\n

Warum mussten wir das tun? Prometheus beginnt, die Zeit des Timeouts ab dem Zeitpunkt zu z\u00e4hlen, an dem die Abfrage erfolgt. Und es spielt keine Rolle, dass die Daten weiterhin flie\u00dfen. Wenn in diesem angegebenen Zeitraum keine Daten \u00fcbertragen werden und die Sitzung nicht \u00fcber http geschlossen wird, gilt die Sitzung als fehlgeschlagen, und die Daten gelangen nicht in den Prometheus.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Jeder kennt die Grafiken, die wir erhalten, wenn Teile der Daten fehlen. Die Grafiken sind unregelm\u00e4\u00dfig, und das gef\u00e4llt uns nicht. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Die n\u00e4chste Option ist Sharding auf Basis von zwei verschiedenen Prometheus durch denselben Federation-Mechanismus.<\/p>\n

<\/p>\n

Wir k\u00f6nnten sie einfach nach Namen sharden. Das kann man auch verwenden, aber wir haben entschieden, weiterzugehen. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Wir m\u00fcssen nun diese Shards irgendwie verarbeiten. Man kann promxy verwenden, welches in den Shard-Bereich geht und die Daten vervielf\u00e4ltigt. Es arbeitet mit zwei Shards als mit einem einzigen Einstiegspunkt. Das kann man \u00fcber promxy umsetzen, ist aber momentan zu kompliziert. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Die erste Option \u2013 wir m\u00f6chten auf den Federation-Mechanismus verzichten, da er sehr langsam ist. <\/p>\n

<\/p>\n

Die Entwickler von Prometheus sagen eindeutig: \u201eJungs, verwendet andere TimescaleDB, denn wir werden die langfristige Speicherung von Metriken nicht unterst\u00fctzen\u201c. Das ist nicht ihre Aufgabe. \"VictoriaMetrics<\/p>\n

<\/p>\n

Wir notieren uns auf einem Zettel, dass wir tats\u00e4chlich einen Export nach au\u00dfen ben\u00f6tigen, um nicht alles an einem Ort zu speichern. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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. <\/p>\n

<\/p>\n

Aktuell haben wir eine Dev- und eine Prod-Umgebung. In Dev sind es etwa 9 Gigabyte bei 350.000 Metriken. In Prod sind es \u00fcber 14 Gigabyte bei 780.000 Metriken. Dabei liegt unsere Retention-Time nur bei 30 Minuten. Das ist schlecht. Und ich erkl\u00e4re jetzt, warum.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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\u00f6tigt. 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\u00fcr einen Server nur f\u00fcr Monitoring zu zahlen. <\/p>\n

<\/p>\n

Unsere Anzahl an Maschinen wird nicht nur steigen, wir \u00fcberwachen 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.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mit dem Speicherplatz ist die Situation hier nicht ganz so schlecht, aber wir m\u00f6chten 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\u00e4re immer besser. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Daher notieren wir einen weiteren Punkt \u2013 den hohen Ressourcenverbrauch, den wir gerne senken w\u00fcrden, da wir nicht m\u00f6chten, dass unser Monitoring-Cluster mehr Ressourcen frisst als unser Cluster, der f\u00fcr die Verwaltung von OpenStack zust\u00e4ndig ist.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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 \u00fcberhaupt keine solchen M\u00f6glichkeiten gibt. Eine Begrenzung in Docker zu verwenden, ist ebenfalls keine Option. Wenn Ihr RAF abst\u00fcrzt und dort 20-30 Gigabyte anfallen, wird es sehr lange dauern, bis es wieder hochf\u00e4hrt. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Das ist ein weiterer Grund, warum Prometheus f\u00fcr uns nicht geeignet ist, d. h. weil man den Speicherverbrauch nicht begrenzen kann. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Es k\u00f6nnte ein solches Schema entwickelt werden. Dieses Schema ben\u00f6tigen wir, um einen HA-Cluster zu organisieren. Wir m\u00f6chten, dass unsere Metriken immer und \u00fcberall verf\u00fcgbar sind, selbst bei Ausf\u00e4llen des Servers, der diese Metriken speichert. Daher m\u00fcssen wir ein solches Schema aufbauen. <\/p>\n

<\/p>\n

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. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Die Nachteile in der Reihenfolge, in der wir sie f\u00fcr uns aufgeschrieben haben:<\/p>\n

<\/p>\n