VictoriaMetrics est un SGBD rapide et évolutif permettant de stocker et de traiter des données sous forme de série temporelle (un enregistrement forme une heure et un ensemble de valeurs correspondant à cette heure, par exemple, obtenues grâce à une interrogation périodique de l'état des capteurs ou la collecte de métriques).
Je m'appelle Pavel Kolobaev. DevOps, SRE, LeroyMerlin, tout est comme le code - tout tourne autour de nous : de moi et des autres collaborateurs de LeroyMerlin.
Il existe un cloud basé sur OpenStack. Il y a un petit lien vers le radar technique.
Il est construit sur la base du fer Kubernetes, ainsi que sur tous les services liés à OpenStack et à la journalisation.
C'est le schéma que nous avions en développement. Lorsque nous avons développé tout cela, nous avions l'opérateur Prometheus, qui stockait les données à l'intérieur même du cluster K8s. Il trouve automatiquement ce qui doit être frotté et le met sous ses pieds, grosso modo.
Nous devrons déplacer toutes les données en dehors du cluster Kubernetes, car si quelque chose se produit, nous devons comprendre quoi et où.
La première solution consiste à utiliser la fédération lorsque nous avons un Prometheus tiers lorsque nous accédons au cluster Kubernetes via le mécanisme de fédération.
Mais il y a quelques problèmes mineurs ici. Dans notre cas, les problèmes ont commencé quand on avait 250 000 métriques, et quand il y avait 400 000 métriques, on s'est rendu compte qu'on ne pouvait pas travailler comme ça. Nous avons augmenté scrape_timeout à 25 secondes.
Pourquoi avons-nous dû faire cela? Prometheus commence à compter le délai d'attente à partir du début du moment de ramassage. Peu importe que les données continuent d'affluer. Si, pendant cette période de temps spécifiée, les données n'ont pas fusionné et que la session n'est pas fermée via http, on considère que la session a échoué et que les données n'entrent pas dans Prometheus lui-même.
Tout le monde connaît les graphiques que nous obtenons lorsqu'une partie des données est manquante. Les graphismes sont déchirés et nous n'en sommes pas satisfaits.
L'option suivante est le partage basé sur deux Prometheus différents via le même mécanisme de fédération.
Par exemple, prenez-les simplement et partagez-les par leur nom. Cela peut également être utilisé, mais nous avons décidé de passer à autre chose.
Nous allons maintenant devoir traiter ces fragments d'une manière ou d'une autre. Vous pouvez prendre promxy, qui descend dans la zone de partition, multiplie les données. Il fonctionne avec deux fragments comme point d'entrée unique. Cela peut être implémenté via promxy, mais c'est trop compliqué pour l'instant.
La première option - nous voulons abandonner le mécanisme de fédération, car il est très lent.
Les développeurs de Prometheus disent explicitement : "Les gars, utilisez d'autres TimescaleDB, car nous ne prendrons pas en charge le stockage à long terme des métriques." Ce n'est pas leur tâche.
On note sur un bout de papier qu'il nous reste à décharger à l'extérieur, histoire de ne pas tout stocker au même endroit.
Le deuxième inconvénient est la consommation de mémoire. Oui, je comprends que beaucoup diront qu'en 2020, quelques gigaoctets de mémoire valent un sou, mais néanmoins.
Nous avons maintenant un environnement de développement et un environnement de production. En développement, cela représente environ 9 gigaoctets pour 350 000 métriques. En prod, c'est 14 gigaoctets avec un petit 780 000 métriques. En même temps, nous n'avons que 30 minutes de temps de rétention. C'est mauvais. Et maintenant je vais vous expliquer pourquoi.
Nous faisons le calcul, c'est-à-dire avec un million et demi de métriques, et nous en sommes déjà proches, au stade de la conception, nous obtenons 35 à 37 gigaoctets de mémoire. Mais déjà à 4 millions de métriques, environ 90 gigaoctets de mémoire sont déjà nécessaires. Autrement dit, il a été calculé selon la formule fournie par les développeurs de Prometheus. Nous avons examiné la corrélation et réalisé que nous ne voulions pas payer quelques millions pour un serveur uniquement pour la surveillance.
Nous n'augmenterons pas seulement le nombre de machines, nous surveillerons également les machines virtuelles elles-mêmes. Par conséquent, plus il y a de machines virtuelles, plus il y a de métriques de toutes sortes, etc. Nous aurons une croissance particulière de notre cluster en termes de métriques.
Avec l'espace disque, tout n'est pas si triste ici, mais j'aimerais l'améliorer. Nous avons reçu un total de 15 gigaoctets en 120 jours, dont 100 sont des données compressées, 20 sont des données non compressées, mais vous en voulez toujours moins.
En conséquence, nous notons un point de plus - il s'agit d'une grande consommation de ressources que nous voulons toujours économiser, car nous ne voulons pas que notre cluster de surveillance consomme plus de ressources que notre cluster qui gère OpenStack.
Il y a un autre inconvénient de Prometheus, que nous avons identifié par nous-mêmes, c'est au moins une sorte de limitation de la mémoire. Avec Prométhée, tout est bien pire ici, car il n'a pas du tout de tels rebondissements. L'utilisation de la limite de docker n'est pas non plus une option. Si soudainement votre RAF tombe et qu'il y a 20 à 30 gigaoctets, il faudra alors très longtemps pour augmenter.
C'est une autre raison pour laquelle Prometheus ne nous convient pas, c'est-à-dire que nous ne pouvons pas limiter la consommation de mémoire.
Il serait possible de proposer un tel schéma. Nous avons besoin de ce schéma pour organiser un cluster HA. Nous voulons que nos métriques soient disponibles à tout moment, n'importe où, même si le serveur qui stocke ces métriques tombe en panne. Et donc nous devons construire un tel schéma.
Ce schéma indique que nous aurons une duplication des fragments et, par conséquent, une duplication des coûts des ressources consommées. Il peut être mis à l'échelle presque horizontalement, mais néanmoins la consommation de ressources sera infernale.
Inconvénients dans l'ordre, sous la forme dans laquelle nous les avons écrits pour nous-mêmes :
- Nécessite de télécharger des métriques vers l'extérieur.
- Forte consommation de ressources.
- Vous ne pouvez pas limiter la consommation de mémoire.
- Mise en œuvre compliquée et gourmande en ressources de la haute disponibilité.
Pour nous-mêmes, nous avons décidé de nous éloigner de Prometheus en tant que référentiel.
Nous avons identifié des exigences supplémentaires pour nous-mêmes dont nous avons besoin. Ce:
- C'est le support promql, car beaucoup a déjà été écrit pour Prometheus : requêtes, alertes.
- Et puis nous avons Grafana, qui est déjà écrit de la même manière sous Prometheus en tant que backend. Je ne veux pas réécrire les tableaux de bord.
- Nous voulons construire une architecture HA normale.
- Nous voulons réduire la consommation de toutes les ressources.
- Il y a une autre petite nuance. Nous ne pouvons pas utiliser différents types de systèmes cloud pour collecter des métriques. Nous ne savons pas ce qui va entrer dans ces mesures pour le moment. Et puisque tout peut y voler, nous devons nous limiter au placement local.
Le choix était petit. Nous avons rassemblé tout ce sur quoi nous avions de l'expérience. Nous avons regardé la page Prometheus dans la section intégration, lu un tas d'articles, regardé ce qui est généralement disponible. Et pour nous, nous avons choisi VictoriaMetrics en remplacement de Prometheus.
Pourquoi? Parce que:
- Capable de promql.
- Il existe une architecture modulaire.
- Ne nécessite aucune modification de Grafana.
- Et surtout, nous fournirons probablement un stockage de métriques au sein de notre entreprise en tant que service, nous envisageons donc à l'avance divers types de restrictions afin que les utilisateurs puissent utiliser toutes les ressources du cluster de manière limitée, car il y a une chance qu'il sera multilocataire.
Nous faisons la première comparaison. Nous prenons le même Prometheus à l'intérieur du cluster, le Prometheus externe y va. Nous ajoutons via remoteWrite VictoriaMetrics.
Je vais faire une réservation tout de suite qu'ici, nous avons constaté une légère augmentation de la consommation de CPU de VictoriaMetrics. Le wiki VictoriaMetrics indique quels paramètres sont les mieux adaptés. Nous les avons vérifiés. Ils ont très bien réduit la consommation du CPU.
Dans notre cas, la consommation mémoire de Prometheus, qui est situé dans un cluster Kubernetes, n'a pas augmenté de manière significative.
Nous comparons deux sources de données des mêmes données. Dans Prometheus, nous voyons tous les mêmes données manquantes. Tout va bien chez VictoriaMetrics.
Résultats des tests avec espace disque. Chez Prometheus, nous avons obtenu 120 gigaoctets au total. Chez VictoriaMetrics, nous obtenons déjà 4 gigaoctets par jour. Il existe un mécanisme légèrement différent de celui que vous avez l'habitude de voir dans Prometheus. C'est-à-dire que les données sont déjà assez bien compressées pendant une journée, pendant une demi-heure. Ils sont déjà bien récoltés en une journée, en une demi-heure, malgré le fait que plus tard les données seront fusionnées. En conséquence, nous avons économisé sur l'espace disque.
Nous économisons également sur la consommation de ressources mémoire. Au moment des tests, nous avions Prometheus déployé sur une machine virtuelle - 8 cœurs, 24 gigaoctets. Prométhée mange presque tout. Il est tombé sur OOM Killer. Dans le même temps, seules 900 000 métriques actives y ont été versées. Cela représente environ 25 000 à 27 000 métriques par seconde.
VictoriaMetrics fonctionnait sur une machine virtuelle double cœur avec 8 gigaoctets de RAM. Nous avons réussi à faire fonctionner VictoriaMetrics en peaufinant certaines choses sur une machine de 8 Go. En conséquence, nous sommes restés dans les 7 gigaoctets. Dans le même temps, nous avons obtenu la vitesse de diffusion du contenu, c'est-à-dire des métriques, encore plus élevées que celles de Prometheus.
Le CPU est bien meilleur que Prometheus. Ici, Prometheus consomme 2,5 cœurs et VictoriaMetrics ne consomme que 0,25 cœurs. Au début - 0,5 cœurs. Au fur et à mesure qu'il fusionne, il atteint un noyau, mais c'est extrêmement, extrêmement rare.
Dans notre cas, le choix s'est porté sur VictoriaMetrics pour des raisons évidentes, nous voulions faire des économies et économisé.
Nous rayons d'emblée deux points - il s'agit du déchargement de métriques et d'une grande consommation de ressources. Et il nous reste à trancher deux points que nous nous sommes encore laissés.
Ici je vais faire une réservation tout de suite, nous considérons VictoriaMetrics comme un référentiel de métriques. Mais puisque nous fournirons très probablement VictoriaMetrics comme stockage pour tous les Leroy, nous devons limiter ceux qui utiliseront ce cluster afin qu'ils ne nous le mettent pas.
Il existe un merveilleux paramètre qui permet de limiter par le temps, par la quantité de données et par le temps d'exécution.
Et il existe également une excellente option qui vous permet de limiter la consommation de mémoire, ainsi nous pouvons trouver l'équilibre même qui nous permettra d'obtenir une vitesse normale et une consommation de ressources adéquate.
Moins un point de plus, c'est-à-dire que nous barrons le point - vous ne pouvez pas limiter la consommation de mémoire.
Dans les premières itérations, nous avons testé le nœud unique VictoriaMetrics. Ensuite, nous passons à la version du cluster VictoriaMetrics.
Ici, nous avons carte blanche sur le sujet de la séparation des différents services dans VictoriaMetrics, en fonction de ce sur quoi ils tourneront et des ressources qu'ils consommeront. C'est une solution très flexible et pratique. Nous l'avons utilisé nous-mêmes.
Les principaux composants de la version cluster de VictoriaMetrics sont vmstsorage. Il peut y avoir un nombre N. Dans notre cas, il y en a 2.
Et il y a vminsert. Il s'agit d'un serveur proxy qui nous permet : d'organiser le sharding entre tous les stockages dont nous lui avons parlé, et il autorise une autre réplique, c'est-à-dire que vous aurez à la fois le sharding et une réplique.
Vminsert prend en charge les protocoles OpenTSDB, Graphite, InfluxDB et remoteWrite de Prometheus.
Il y a aussi vmselect. Sa tâche principale est d'aller sur vmstorage, d'en obtenir des données, de dédupliquer ces données et de les donner au client.
Il y a une chose merveilleuse comme vmagent. Nous l'aimons vraiment. Il vous permet de configurer comme Prometheus et de tout faire comme Prometheus. Autrement dit, il collecte les métriques de différentes entités et services et les envoie à vminsert. Ensuite, tout dépend de vous.
Un autre excellent service est vmalert, qui vous permet d'utiliser VictoriaMetrics comme backend, de recevoir des données traitées de vminsert et d'envoyer des données traitées à vmselect. Il traite les alertes elles-mêmes, ainsi que les règles. Dans le cas des alertes, nous recevons une alerte via alertmanager.
Il y a un composant wmauth. Nous l'utiliserons probablement, et peut-être pas (nous n'avons pas encore décidé de cela) comme système d'autorisation pour les versions multi-locataires des clusters. Il prend en charge remoteWrite pour Prometheus et peut autoriser en fonction de l'URL, ou plutôt de la deuxième partie de celle-ci, où vous pouvez ou ne pouvez pas écrire.
Il y a aussi vmbackup, vmrestore. Il s'agit, en fait, de la restauration et de la sauvegarde de toutes les données. Capable de S3, GCS, fichier.
La première itération de notre cluster a été faite pendant la quarantaine. À cette époque, il n'y avait pas de réplica, donc notre itération consistait en deux clusters différents et indépendants, dans lesquels nous recevions des données via remoteWrite.
Ici, je ferai une réserve sur le fait que lorsque nous sommes passés de VictoriaMetrics Single Node à VictoriaMetrics Cluster Version, nous sommes toujours restés dans les mêmes ressources consommées, c'est-à-dire que la principale est la mémoire. Approximativement de cette manière, nos données ont été distribuées, c'est-à-dire la consommation de ressources.
Une réplique a déjà été ajoutée ici. Nous avons combiné tout cela en un cluster relativement grand. Toutes les données sont à la fois partitionnées et répliquées.
L'ensemble du cluster a N points d'entrée, c'est-à-dire que Prometheus peut ajouter des données via HAPROXY. Voici notre porte d'entrée. Et via ce point d'entrée, vous pouvez vous connecter avec Grafana.
Dans notre cas, HAPROXY est le seul port proxy qui sélectionne, insère et autres services dans ce cluster. Dans notre cas, il était impossible de faire une adresse, nous avons dû faire plusieurs points d'entrée, car les machines virtuelles elles-mêmes, sur lesquelles tourne le cluster VictoriaMetrics, sont situées dans différentes zones du même fournisseur de cloud, c'est-à-dire pas à l'intérieur de notre cloud , mais à l'extérieur.
Nous avons une alerte. Nous l'utilisons. Nous utilisons alertmanager de Prometheus. Nous utilisons Opsgenie et Telegram comme canal de diffusion des alertes. Dans Telegram, ils viennent du développement, peut-être de la production, mais plutôt de quelque chose de statistique dont les ingénieurs ont besoin. Et Opsgenie est critique. Ce sont les appels, la gestion des incidents.
La question séculaire : "Qui surveille la surveillance ?". Dans notre cas, la surveillance surveille la surveillance elle-même, car nous utilisons vmagent sur chaque nœud. Et puisque nos nœuds sont situés dans différents centres de données du même fournisseur, chaque centre de données a son propre canal, ils sont indépendants, et même si un cerveau partagé arrive, nous recevrons toujours des alertes. Oui, il y en aura plus, mais il vaut mieux recevoir plus d'alertes qu'aucune.
Nous terminons notre liste avec la mise en œuvre de HA.
Et en outre, je voudrais souligner l'expérience de communication avec la communauté VictoriaMetrics. Cela s'est avéré très positif. Les gars sont réactifs. Ils essaient de se plonger dans chaque cas qui est offert.
J'ai créé des problèmes sur GitHub. Ils ont été résolus très rapidement. Il y a quelques autres problèmes qui ne sont pas complètement clos, mais je peux déjà voir dans le code que des travaux sont en cours dans cette direction.
La principale douleur pendant les itérations pour moi était que si je réduisais le nœud, alors pendant les 30 premières secondes, vminsert ne pouvait pas comprendre qu'il n'y avait pas de backend. Maintenant, c'est déjà décidé. Et littéralement en une seconde ou deux, les données sont extraites de tous les nœuds restants et la requête cesse d'attendre ce nœud manquant.
Nous voulions à un moment donné que VictoriaMetrics soit l'opérateur de VictoriaMetrics. Nous l'avons attendu. Nous construisons maintenant activement une liaison sur l'opérateur VictoriaMetrics pour prendre toutes les règles de pré-calcul, etc. Prometheus, car nous utilisons assez activement les règles fournies avec l'opérateur Prometheus.
Il y a des suggestions pour améliorer la mise en œuvre du cluster. Je les ai décrites ci-dessus.
Et je veux aussi vraiment le sous-échantillonnage. Dans notre cas, le sous-échantillonnage est nécessaire exclusivement pour visualiser les tendances. En gros, une métrique me suffit pendant la journée. Ces tendances s'imposent depuis un an, trois, cinq, dix ans. Et une seule valeur métrique suffit.
- Nous avons connu la douleur, comme certains de nos collègues, en utilisant Prometheus.
- Nous avons choisi VictoriaMetrics pour nous-mêmes.
- Il s'adapte assez bien à la fois verticalement et horizontalement.
- Nous pouvons distribuer différents composants à un nombre différent de nœuds dans le cluster, les limiter en termes de mémoire, ajouter de la mémoire, etc.
Nous utiliserons VictoriaMetrics à la maison, car nous l'avons vraiment aimé. Voici ce qui s'est passé et ce qui s'est passé.
Quelques codes qr pour le chat VictoriaMetrics, mes contacts, le radar technique LeroyMerlin.
Source: habr.com