{"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 das Monitoring privater Clouds. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics \u2014 eine schnelle und skalierbare Datenbank zur Speicherung und Verarbeitung von Zeitreihendaten (eine Aufzeichnung besteht aus Zeitstempeln und einem Satz zugeh\u00f6riger Werte, wie beispielsweise den regelm\u00e4\u00dfig abgefragten Status von Sensoren oder gesammelten Metriken).<\/p>\n

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

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

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mein Name ist Kolobaev Pavel. DevOps, SRE, LeroyMerlin, alles als Code \u2013 das beschreibt uns: mich und die anderen 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 gibt es einen kleinen Link zum Tech-Radar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Sie basiert auf Kubernetes-Hardware sowie auf allen unterst\u00fctzenden Diensten f\u00fcr OpenStack und Logging. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Unser Entwicklungsansatz sah folgenderma\u00dfen aus. W\u00e4hrend der Entwicklung hatten wir einen Prometheus-Operator, der die Daten innerhalb des K8s-Clusters speicherte. Er findet automatisch, was zu scrapen ist und legt es sich quasi vor die F\u00fc\u00dfe. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Alle Daten m\u00fcssen wir aus dem Kubernetes-Cluster herausziehen, 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 und durch das Federation-Mechanismus auf das Kubernetes-Cluster zugreifen.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Hier gibt es jedoch ein paar Probleme. In unserem Fall traten die Probleme auf, als wir 250.000 Metriken hatten, und als es 400.000 wurden, merkten wir, dass wir so nicht weiterarbeiten konnten. Wir haben den scrape_timeout auf 25 Sekunden erh\u00f6ht.<\/p>\n

<\/p>\n

Warum mussten wir das tun? Prometheus beginnt die Zeit f\u00fcr das Timeout ab dem Zeitpunkt der Abholung zu z\u00e4hlen. Es spielt keine Rolle, dass die Daten weiterhin flie\u00dfen. Wenn in diesem angegebenen Zeitraum keine Daten \u00fcbertragen wurden und die Sitzung nicht \u00fcber HTTP geschlossen wird, gilt die Sitzung als gescheitert und die Daten gelangen nicht in Prometheus.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Allen sind die Grafiken vertraut, 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 M\u00f6glichkeit ist das Sharding basierend auf zwei verschiedenen Prometheus-Instanzen \u00fcber dasselbe Federation-Mechanismus.<\/p>\n

<\/p>\n

Zum Beispiel einfach nach Namen shardieren. Das kann man auch verwenden, aber wir haben uns entschieden, weiterzugehen. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Wir m\u00fcssen diese Shards nun irgendwie verarbeiten. Man kann promxy verwenden, das in den Shard-Bereich geht und die Daten multipliziert. Es arbeitet mit zwei Shards als einem einzigen Einstiegspunkt. So etwas kann \u00fcber promxy realisiert werden, ist aber momentan zu kompliziert. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Die erste Option besteht darin, auf den Federation-Mechanismus zu verzichten, da er sehr langsam ist. <\/p>\n

<\/p>\n

Die Entwickler von Prometheus sagen eindeutig: \u201eLeute, 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 Papier, dass wir dennoch einen Export nach au\u00dfen ben\u00f6tigen, um nicht alles an einem Ort zu speichern. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ein weiterer Nachteil ist der Speicherverbrauch. Ja, ich verstehe, dass viele sagen werden, dass ein paar Gigabyte RAM im Jahr 2020 g\u00fcnstig sind, dennoch ist es ein Faktor. <\/p>\n

<\/p>\n

Aktuell haben wir eine Entwicklungs- und eine Produktionsumgebung. In der Entwicklungsumgebung sind es etwa 9 Gigabyte f\u00fcr 350.000 Metriken. In der Produktionsumgebung sind es etwas \u00fcber 14 Gigabyte f\u00fcr 780.000 Metriken. Dabei betr\u00e4gt die Retentionszeit nur 30 Minuten. Das ist unzureichend. Ich werde erkl\u00e4ren, warum.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Wir analysieren, das hei\u00dft, bei anderthalb Millionen Metriken \u2013 wir sind bereits nahe daran \u2013 erhalten wir bereits in der Planungsphase 35-37 Gigabyte RAM. Bei 4 Millionen Metriken ben\u00f6tigen wir dann bereits etwa 90 Gigabyte RAM. Dies wurde nach der Formel berechnet, die die Entwickler von Prometheus zur Verf\u00fcgung stellen. Wir haben die Korrelation untersucht und sind zu dem Schluss gekommen, dass wir nicht bereit sind, ein paar Millionen nur f\u00fcr einen \u00dcberwachungsserver zu zahlen. <\/p>\n

<\/p>\n

Wir erhalten nicht nur eine gr\u00f6\u00dfere Anzahl an Maschinen, sondern \u00fcberwachen auch die virtuellen Maschinen selbst. Je mehr virtuelle Maschinen wir haben, desto mehr verschiedene Metriken ergeben sich. Unser Cluster wird speziell in Bezug auf diese Metriken wachsen.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mit dem Speicherplatz sieht es hier nicht so d\u00fcster aus, aber es gibt noch Verbesserungsbedarf. In den letzten 15 Tagen haben wir insgesamt 120 Gigabyte erhalten, davon 100 Gigabyte komprimierte Daten und 20 Gigabyte unkomprimierte Daten. Wir h\u00e4tten gerne weniger. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Daher f\u00fcgen wir einen weiteren Punkt hinzu: der hohe Ressourcenverbrauch, den wir reduzieren m\u00f6chten. Wir wollen nicht, dass unser \u00dcberwachungs-Cluster mehr Ressourcen ben\u00f6tigt als der Cluster, der f\u00fcr die Verwaltung von OpenStack zust\u00e4ndig ist.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ein weiterer Nachteil von Prometheus, den wir festgestellt haben, ist, dass es eine Art Speicherkontingent gibt. Damit sieht es bei Prometheus deutlich schlechter aus, da es kein solches Management gibt. Eine Begrenzung im Docker ist ebenfalls keine L\u00f6sung. Wenn beispielsweise Ihr RAF ausf\u00e4llt und 20-30 Gigabyte erreicht, wird es sehr lange dauern, bis es wieder hochkommt. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Wir k\u00f6nnen ein solches Schema in Betracht ziehen. Dieses Schema ist notwendig, um ein HA-Cluster zu organisieren. Wir m\u00f6chten, dass unsere Metriken jederzeit und \u00fcberall verf\u00fcgbar sind, selbst wenn der Server, der diese Metriken speichert, ausf\u00e4llt. Daher m\u00fcssen wir ein solches Schema erstellen. <\/p>\n

<\/p>\n

Dieses Schema besagt, dass wir eine Duplizierung der Shards haben werden, und somit auch eine Verdopplung der Ressourcen, die ben\u00f6tigt werden. Es kann fast horizontal skaliert werden, aber trotzdem wird der Ressourcenverbrauch enorm sein. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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

<\/p>\n