{"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\/fr\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics et la surveillance des clouds priv\u00e9s. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics \u2014 une base de donn\u00e9es rapide et \u00e9volutive pour le stockage et le traitement des donn\u00e9es sous forme de s\u00e9ries temporelles (un enregistrement forme le temps et un ensemble de valeurs correspondantes \u00e0 ce temps, par exemple, obtenues via un sondage p\u00e9riodique de l'\u00e9tat des capteurs ou la collecte de m\u00e9triques).<\/p>\n

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

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

\"VictoriaMetrics<\/p>\n

<\/p>\n

Je m'appelle Pavel Kolobaev. DevOps, SRE, LeroyMerlin, tout comme le code \u2013 c'est tout nous : moi et les autres employ\u00e9s de LeroyMerlin.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

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

<\/p>\n

Il existe un nuage bas\u00e9 sur OpenStack. Voici un petit lien vers le radar technique. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Il est construit sur du mat\u00e9riel Kubernetes, ainsi que sur tous les services associ\u00e9s \u00e0 OpenStack et \u00e0 la journalisation. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Voici comment nous avons organis\u00e9 le d\u00e9veloppement. Lorsque nous avons tout d\u00e9velopp\u00e9, nous avions un op\u00e9rateur Prometheus qui stockait les donn\u00e9es \u00e0 l'int\u00e9rieur du cluster K8s. Il trouve automatiquement ce qu'il faut scraper et le place sous ses pieds, pour dire les choses simplement. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Nous devons d\u00e9placer toutes les donn\u00e9es en dehors du cluster Kubernetes, car si quelque chose se produit, nous devons comprendre o\u00f9 et quoi. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La premi\u00e8re solution consiste \u00e0 utiliser la f\u00e9d\u00e9ration, lorsque nous avons un Prometheus externe, lorsque nous acc\u00e9dons au cluster Kubernetes via le m\u00e9canisme de f\u00e9d\u00e9ration.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mais ici, cela pose quelques probl\u00e8mes. Dans notre cas, les probl\u00e8mes ont commenc\u00e9 lorsque nous avions 250 000 m\u00e9triques, et lorsque nous sommes pass\u00e9s \u00e0 400 000 m\u00e9triques, nous avons r\u00e9alis\u00e9 que nous ne pouvions pas travailler de cette mani\u00e8re. Nous avons augment\u00e9 le scrape_timeout \u00e0 25 secondes.<\/p>\n

<\/p>\n

Pourquoi avons-nous d\u00fb faire cela ? Prometheus commence \u00e0 compter le temps d'attente \u00e0 partir du moment o\u00f9 il commence \u00e0 collecter. Et peu importe que les donn\u00e9es soient encore en cours d'envoi. Si, pendant cette p\u00e9riode sp\u00e9cifi\u00e9e, les donn\u00e9es ne sont pas envoy\u00e9es et que la session n'est pas ferm\u00e9e par http, il est consid\u00e9r\u00e9 que la session a \u00e9chou\u00e9 et que les donn\u00e9es ne sont pas envoy\u00e9es dans Prometheus lui-m\u00eame.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Tout le monde conna\u00eet les graphiques que nous obtenons lorsque certaines donn\u00e9es sont manquantes. Les graphiques sont fragment\u00e9s et cela ne nous convient pas. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La prochaine option est le partitionnement bas\u00e9 sur deux Prometheus diff\u00e9rents via le m\u00eame m\u00e9canisme de f\u00e9d\u00e9ration.<\/p>\n

<\/p>\n

Par exemple, simplement les partitionner par nom. Cela peut \u00e9galement \u00eatre utilis\u00e9, mais nous avons d\u00e9cid\u00e9 d'aller plus loin. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Nous allons maintenant devoir traiter ces shards d'une mani\u00e8re ou d'une autre. On peut utiliser promxy, qui va dans la zone du shard, multiplie les donn\u00e9es. Il fonctionne avec deux shards comme un point d'entr\u00e9e unique. Cela peut \u00eatre r\u00e9alis\u00e9 via promxy, mais c'est encore trop complexe. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La premi\u00e8re option \u2013 nous voulons renoncer au m\u00e9canisme de f\u00e9d\u00e9ration, car il est tr\u00e8s lent. <\/p>\n

<\/p>\n

Les d\u00e9veloppeurs de Prometheus disent clairement : \u00ab Les gars, utilisez d'autres TimescaleDB, car nous ne supporterons pas un stockage \u00e0 long terme des m\u00e9triques \u00bb. Ce n'est pas leur r\u00f4le. \"VictoriaMetrics<\/p>\n

<\/p>\n

Nous notons sur un papier qu'il nous faut effectivement une exportation vers l'ext\u00e9rieur, afin de ne pas tout stocker au m\u00eame endroit. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Le deuxi\u00e8me inconv\u00e9nient est la consommation de m\u00e9moire. Oui, je comprends que beaucoup diront qu'en 2020, quelques gigaoctets de m\u00e9moire ne co\u00fbtent pas cher, mais n\u00e9anmoins. <\/p>\n

<\/p>\n

Actuellement, nous avons un environnement dev et prod. En dev, cela repr\u00e9sente environ 9 gigaoctets pour 350 000 m\u00e9triques. En prod, c'est juste un peu plus de 14 gigaoctets pour 780 000 m\u00e9triques. De plus, notre temps de r\u00e9tention est de seulement 30 minutes. C'est probl\u00e9matique. Et je vais expliquer pourquoi.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Nous faisons le calcul, c'est-\u00e0-dire qu'avec un million et demi de m\u00e9triques, et nous y sommes presque, au stade de la conception, nous pr\u00e9voyons 35 \u00e0 37 gigaoctets de m\u00e9moire. Mais d\u00e9j\u00e0 pour 4 millions de m\u00e9triques, il faut environ 90 gigaoctets de m\u00e9moire. Cela a \u00e9t\u00e9 calcul\u00e9 selon la formule fournie par les d\u00e9veloppeurs de Prometheus. Nous avons observ\u00e9 la corr\u00e9lation et compris que nous ne voulons pas payer quelques millions pour un serveur juste pour la surveillance. <\/p>\n

<\/p>\n

Nous n'allons pas seulement augmenter le nombre de machines, nous surveillons aussi les machines virtuelles elles-m\u00eames. Donc, plus il y a de machines virtuelles, plus il y aura de m\u00e9triques de diff\u00e9rents types, etc. Nous pr\u00e9voyons une croissance sp\u00e9ciale de notre cluster en termes de m\u00e9triques.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ce n'est pas si grave en ce qui concerne l'espace disque, mais nous aimerions l'am\u00e9liorer. Nous avons obtenu en 15 jours un total de 120 gigaoctets, dont 100 sont des donn\u00e9es compress\u00e9es, 20 des donn\u00e9es non compress\u00e9es, mais nous souhaiterions toujours moins. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Par cons\u00e9quent, nous notons un autre point : c'est une grande consommation de ressources que nous aimerions \u00e9conomiser, car nous ne voulons pas que notre cluster de surveillance consomme plus de ressources que notre cluster qui g\u00e8re OpenStack.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Il y a un autre inconv\u00e9nient de Prometheus que nous avons identifi\u00e9, c'est au moins une certaine limitation de la m\u00e9moire. Avec Prometheus, c'est bien pire, car il n'a pas du tout ce type de r\u00e9glages. Utiliser des limites de m\u00e9moire dans Docker n\u2019est \u00e9galement pas une option. Si votre RAF tombe et qu'il y a 20-30 gigaoctets, la remont\u00e9e prendra beaucoup de temps. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

C'est une autre raison pour laquelle Prometheus ne nous convient pas, c'est-\u00e0-dire qu'il n'est pas possible de limiter la consommation de m\u00e9moire. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Nous pourrions adopter un tel sch\u00e9ma. Ce sch\u00e9ma est n\u00e9cessaire pour organiser un cluster HA. Nous voulons que nos m\u00e9triques soient toujours et partout accessibles, m\u00eame en cas de panne du serveur qui les stocke. Ainsi, nous devrons construire un tel sch\u00e9ma. <\/p>\n

<\/p>\n

Ce sch\u00e9ma indique que nous aurons une duplication des shards, et par cons\u00e9quent, une duplication des ressources consomm\u00e9es. Il peut presque \u00eatre mis \u00e0 l'\u00e9chelle horizontalement, mais n\u00e9anmoins, la consommation des ressources sera \u00e9norme. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Les inconv\u00e9nients, par ordre, tels que nous les avons \u00e9crits pour nous :<\/p>\n

<\/p>\n