Salut tout le monde. Ci-dessous la transcription .
– un système de surveillance pour divers systèmes et services, à l'aide duquel les administrateurs système peuvent collecter des informations sur les paramètres actuels des systèmes et configurer des alertes pour recevoir des notifications sur les écarts dans le fonctionnement des systèmes.
Le rapport comprendra une comparaison и — des projets de stockage à long terme des métriques Prometheus.
Tout d’abord, je vais vous parler de Prométhée. Il s'agit d'un système de surveillance qui collecte des métriques à partir de cibles spécifiées et les enregistre sur le stockage local. Prometheus peut enregistrer des métriques sur un stockage distant et générer des alertes et des règles d'enregistrement.
Limites de Prométhée :
- Il n'a pas de vue de requête globale. C'est lorsque vous disposez de plusieurs instances indépendantes de prometheus. Ils collectent des métriques. Et vous souhaitez interroger toutes ces métriques collectées à partir de différentes instances de Prometheus. Prométhée ne le permet pas.
- Avec prometheus, les performances sont limitées à un seul serveur. Prometheus n'évolue pas automatiquement sur plusieurs serveurs. Vous ne pouvez diviser manuellement vos cibles qu’entre plusieurs Prometheus.
- La portée des métriques dans Prometheus est limitée à un seul serveur pour la même raison qu'elle ne peut pas évoluer automatiquement sur plusieurs serveurs.
- Il n’est pas si simple d’organiser la sécurité des données dans Prometheus.
Des solutions à ces problèmes/défis ?
Les solutions sont :
Toutes ces solutions sont destinées au stockage à distance des données collectées par Prometheus. Ils résolvent le problème du stockage distant évoqué dans la diapositive précédente de différentes manières. Dans cette présentation je ne parlerai que des deux premières solutions : и .
Pour la première fois des informations sur apparu par . L'architecture y est décrite et comment ça marche.
Thanos prend les données que Prometheus a enregistrées sur le disque local et les copie sur S3, vers ou vers un autre stockage d'objets.
Ainsi Thanos fournit une vue globale des requêtes. Vous pouvez interroger les données stockées dans le stockage d'objets à partir de plusieurs instances Prometheus.
Thanos prend en charge PromQL et .
Thanos utilise le code Prometheus pour stocker les données.
Thanos est développé par les mêmes développeurs que Prometheus.
Sur . Ici , où nous avons parlé pour la première fois .
VictoriaMetrics reçoit des données de plusieurs prometheus protocole pris en charge par Prometheus.
VictoriaMetrics fournit une vue globale des requêtes, puisque plusieurs instances Prometheus peuvent écrire des données sur un seul VictoriaMetrics. Ainsi, vous pouvez effectuer des requêtes sur toutes ces données.
VictoriaMetrics prend également en charge, comme Thanos, les API de requête PromQL et Prometheus.
Contrairement à Thanos, le code source de VictoriaMetrics est écrit à partir de zéro et optimisé pour la vitesse et la consommation de ressources.
VictoriaMetrics, contrairement à Thanos, évolue à la fois verticalement et horizontalement. Manger , qui évolue verticalement. Vous pouvez commencer avec un processeur et 1 Go de mémoire et passer progressivement à des centaines de processeurs et 1 To de mémoire. VictoriaMetrics peut utiliser toutes ces ressources. Ses performances augmenteront d'environ 100 fois par rapport à un système monocœur.
L’histoire de Thanos a commencé en novembre 2017, lorsque le premier engagement public est apparu. Avant cela, Thanos était développé en interne .
En juin 2019, une version historique 0.5.0 a été publiée, dans laquelle protocole. Il a été retiré de Thanos parce qu'il n'avait pas bien performé. Souvent, le cluster Thanos ne fonctionnait pas correctement, les nœuds n'y étaient pas connectés correctement en raison du protocole Gossip. Nous avons donc décidé de le retirer de là. Je pense que c'est la bonne décision.
Le même mois de juin 2019, ils ont envoyé le numéro de candidature в .
Et après quelques mois, Thanos fut accepté , qui comprend Prometheus, Kubernetes et d'autres projets populaires.
En janvier 2018, le développement de VictoriaMetrics a commencé.
En septembre 2018, j'ai mentionné publiquement VictoriaMetrics pour la première fois.
En décembre 2018, une version à nœud unique a été publiée.
En mai 2019 sources des versions à nœud unique et en cluster.
En juin 2019, tout comme Thanos, nous avons déposé un dossier de candidature auprès de la fondation CNCF sous le numéro . Nous avons postulé un jour avant que Thanos ne postule.
Mais malheureusement, nous n’y sommes toujours pas acceptés. Aide communautaire nécessaire.
Regardons les diapositives les plus importantes montrant l'architecture de Thanos et VictoriaMetrics.
Commençons par Thanos. Les composants jaunes sont des composants Prometheus. Tout le reste est constitué de composants Thanos. Commençons par le composant le plus important. Thanos Sidecar est un composant installé à côté de chaque Prometheus. Il charge les données Prometheus du stockage local dans S3 ou un autre Object Storage.
Il existe également un composant appelé Thanos Store Gateway, qui peut lire ces données à partir d'Object Storage lors des requêtes entrantes de Thanos Query. Thanos Query implémente les API PromQL et Prometheus. Autrement dit, de l'extérieur, cela ressemble à Prométhée. Reçoit les requêtes PromQL, les envoie à Thanos Store Gateway, Thanos Store Gateway récupère les données nécessaires depuis Object Storage, les renvoie.
Mais nous stockons les données dans Object Storage sans les deux dernières heures en raison d'une fonctionnalité de l'implémentation de Thanos Sidecar, qui ne peut pas télécharger les deux dernières heures vers Object Storage S3, car Prometheus n'a pas encore créé de fichiers pour ces deux heures dans le stockage local.
Comment avez-vous décidé de contourner ce problème ? Thanos Query, en plus des requêtes adressées au Thanos Store Gateway, envoie des requêtes parallèles à chaque Thanos Sidecar, situé à côté de Prometheus.
Et Thanos Sidecar, à son tour, transmet les requêtes ultérieures à Prometheus et récupère les données des deux dernières heures.
En plus de ces composants, il existe également un composant optionnel sans lequel Thanos ne fonctionnera pas bien. Il s'agit de Thanos Compact, qui est chargé de fusionner les petits fichiers sur Object Storage en fichiers plus volumineux téléchargés ici par Thanos Sidecars. Thanos Sidecar y télécharge des fichiers de données en deux heures. Ces fichiers, s'ils ne sont pas fusionnés en fichiers plus volumineux, alors leur nombre peut augmenter de manière très significative. Plus il y a de fichiers de ce type, plus Thanos Store Gateway a besoin de mémoire, plus il faut de ressources pour transférer des données sur le réseau et des métadonnées. Thanos Store Gateway devient inefficace. Par conséquent, il est nécessaire d'exécuter Thanos Compact, qui fusionne les petits fichiers en fichiers plus gros, afin de réduire le nombre de ces fichiers et de réduire la surcharge sur Thanos Store Gateway.
Il existe également un composant tel que Thanos Ruler. Il exécute les règles d'alerte Prometheus et peut évaluer les règles d'enregistrement Prometheus afin de réécrire les données dans Object Storage. Mais il n'est pas recommandé d'utiliser ce composant, car... Il .
C'est le schéma simple de Thanos.
Comparons-le maintenant avec le schéma VictoriaMetrics.
VictoriaMetrics a 2 versions : version à nœud unique et version cluster. Le nœud unique s’exécute sur un seul ordinateur. Le nœud unique n'a pas ces composants, juste un binaire. Ce binaire sur la diapositive ressemble à ce carré. Tout ce qui se trouve à l'intérieur du carré correspond au contenu du fichier binaire pour la version à nœud unique. Vous n'avez pas besoin de le savoir. Vous exécutez simplement le binaire et tout fonctionne pour nous.
La version cluster est plus compliquée. À l'intérieur, il y a trois composants différents : vmselect, vminsert et vmstorage. D’après leur nom, ce que fait chacun d’eux devrait être clair. Le composant Insert accepte des données dans différents formats : de l'API d'écriture à distance Prometheus, du protocole de ligne Influx, du protocole Graphite et du protocole OpenTSDB. Le composant Insert les accepte, les analyse et les distribue entre les composants de stockage existants, où les données sont déjà stockées. Le composant Select, à son tour, accepte les requêtes PromQL. Il met en œuvre , ainsi que l'API d'interrogation Prometheus, et il peut être utilisé en remplacement de Prometheus dans Grafana ou d'autres clients API Prometheus. Select accepte une requête promql, l'analyse, lit les données nécessaires à l'exécution de cette requête à partir des nœuds de stockage, traite ces données et renvoie une réponse.
Comparons la complexité de l'installation de Thanos et VictoriaMetrics.
Commençons par Thanos. Avant de commencer à travailler avec Thanos, vous devez créer un compartiment dans Object Storage, tel que S3 ou GCS, afin que Thanos Sidecar puisse y écrire des données.
Ensuite, pour chaque Prometheus, vous devez installer Thanos Sidecar. Avant cela, n'oubliez pas de désactiver le compactage des données dans Prometheus. Le compactage des données compresse périodiquement les données dans le stockage Prometheus local afin de réduire la consommation de ressources.
Lorsque vous installez Thanos Sidecar sur votre Prometheus, vous devez désactiver ce compactage des données, car Thanos Sidecar ne fonctionne pas correctement avec le compactage des données activé. Cela signifie que votre Prometheus commence à enregistrer les données par blocs de deux heures et arrête de fusionner ces blocs en blocs plus grands. Par conséquent, si vous effectuez des requêtes qui dépassent la durée des deux dernières heures, elles ne fonctionneront pas aussi efficacement qu'elles l'auraient fait si le compactage des données avait été activé.
Par conséquent, Thanos recommande de réduire le temps de conservation des données dans le stockage local à 6 à 8 heures afin de réduire la surcharge d'un grand nombre de petits blocs.
Une fois que vous avez installé Thanos Sidecar, vous devez installer deux composants pour chaque compartiment de stockage d'objets. Il s’agit de Thanos Compactor et Thanos Store Gateway.
Après cela, vous devez installer Thanos Query et le configurer pour qu'il puisse se connecter à toutes les passerelles Thanos Store dont vous disposez, ainsi qu'à tous les Thanos Sidecars.
Il peut y avoir un léger problème ici.
Vous devez configurer une connexion fiable et sécurisée de Thanos Query à ces composants. Et si votre Prometheus est situé dans différents centres de données ou dans différents VPC, les connexions vers ceux-ci depuis l'extérieur sont interdites. Mais pour que Thanos Query fonctionne, vous devez y configurer la connexion d'une manière ou d'une autre, et vous devez trouver un moyen.
Si vous disposez de nombreux centres de données de ce type, la fiabilité de l'ensemble du système diminue en conséquence. Puisque Thanos Query doit constamment maintenir des connexions à tous les Thanos Sidecars situés dans différents centres de données. Pour chaque demande entrante, il acheminera les demandes vers tous les Thanos Sidecars. Si la connexion est interrompue, soit vous recevrez un ensemble de données incomplet, soit vous recevrez une réponse « le cluster est en panne ».
Dans VictoriaMetrics, tout est un peu plus simple. Pour la version à nœud unique, il vous suffit d'exécuter un binaire et tout fonctionne.
Dans la version cluster, il suffit d'exécuter les trois types de composants ci-dessus dans la quantité dont vous avez besoin, ou d'utiliser pour automatiser le lancement de composants dans Kubernetes. Nous prévoyons également de créer un opérateur Kubernetes. Le tableau Helm ne couvre pas certains cas et vous permet de vous tirer une balle dans le pied. Par exemple, cela permet de réduire le nombre de nœuds de stockage, ce qui entraînera une perte de données.
Après avoir lancé une version binaire ou clusterisée, il vous suffit d'ajouter Prometheus à la configuration afin qu'il commence à écrire des données en parallèle sur le stockage local et le stockage distant. Comme vous pouvez le constater, cette configuration devrait fonctionner de manière beaucoup plus fiable que la configuration Thanos. Nous n'avons pas besoin de maintenir une connexion entre VictoriaMetrics et tous les Prometheus, car Prometheus lui-même se connecte à VictoriaMetrics et transmet des données.
Considérons le soutien de Thanos et VictoriaMetrics.
Thanos doit surveiller Sidecar pour s'assurer qu'il n'arrête pas de charger des données dans Object Storage. Ils peuvent arrêter ce téléchargement de données en raison d'erreurs de téléchargement, par exemple votre connexion réseau à Object Storage est temporairement interrompue ou Object Storage est temporairement indisponible. Thanos Sidecar le remarquera à ce moment-là, signalera une erreur, pourra planter puis cesser de fonctionner. Si vous ne le surveillez pas, vous arrêterez de transférer des données vers Object Storage. Si le temps de conservation est dépassé (6 à 8 heures recommandées), vous perdrez les données qui n'ont pas abouti dans Object Storage.
Les compacteurs Thanos peuvent cesser de fonctionner en raison de . Les compacteurs récupèrent les données d'Object Storage et les fusionnent en morceaux de données plus volumineux. Comme les compacteurs ne sont pas synchronisés avec les Sidecars, les événements suivants peuvent se produire : Sidecar n'a pas encore eu le temps de terminer le bloc, Compactor décide que ce bloc a été complètement écrit. Compactor commence à le lire. Il ne lit pas le bloc dans son intégralité et cesse de fonctionner. Voir les détails .
Store Gateway peut renvoyer des données incohérentes en raison de courses entre Compactor et Sidecars. La même chose se produit ici, car Store Gateway n’est en aucun cas synchronisé avec les compacteurs et les side-cars. Par conséquent, des conditions de concurrence peuvent survenir lorsque Store Gateway ne voit pas une partie des données ou voit des données inutiles.
Le composant Query de Thanos renvoie par défaut un résultat partiel si certains side-cars ou passerelles de magasin ne sont pas disponibles pour le moment. Vous recevrez une partie des données et vous ne saurez même pas que vous n'avez pas reçu toutes les données. C'est ainsi que cela fonctionne par défaut. Dans une situation similaire, VictoriaMetrics renvoie les données marquées comme partielles.
Contrairement à Thanos, VictoriaMetrics perd rarement des données. Même si la connexion de Prometheus à VictoriaMetrics est interrompue, ce n'est pas un problème, puisque Prometheus continue d'enregistrer les nouvelles données entrantes dans le journal d'écriture anticipée, dont la taille est de 2 heures. Si vous rétablissez votre connexion à VictoriaMetrics dans les deux heures, vos données ne seront pas perdues. Prométhée .
Contrairement à Thanos, qui écrit les données sur le stockage objet seulement après deux heures, Prometheus réplique automatiquement les données à l'aide du protocole d'écriture à distance vers un stockage distant, tel que VictoriaMetrics. Vous n'avez pas peur de perdre le stockage local dans Prometheus. S'il perd soudainement le stockage local, dans le pire des cas, vous perdrez les dernières secondes de données qui n'ont pas eu le temps d'être enregistrées dans le stockage distant.
Kubernetes gère automatiquement le cluster, contrairement à Thanos. Il est difficile de placer tous les composants Thanos dans un seul cluster Kubernetes, contrairement aux composants du cluster VictoriaMetrics.
VictoriaMetrics propose une mise à jour très simple vers la nouvelle version. Arrêtez simplement VictoriaMetrics, mettez à jour les binaires et lancez-le. Lorsqu'ils sont arrêtés via un signal SIGINT, tous les binaires VictoriaMetrics effectuent un arrêt progressif. Ils enregistrent correctement les données nécessaires, ferment correctement les connexions entrantes pour ne rien perdre. Vous ne perdrez donc rien lors de la mise à niveau.
VictoriaMetrics facilite grandement l'extension d'un cluster. Ajoutez simplement les composants nécessaires et continuez à travailler.
À propos des pièges de Thanos et VictoriaMetrics.
Thanos présente les pièges suivants. Prometheus doit stocker les données des deux dernières heures. S'ils sont perdus, vous les perdrez complètement car ils n'ont pas encore été écrits dans Object Storage comme S3.
Le composant Store Gateway et le composant Compactor peuvent nécessiter beaucoup de mémoire pour fonctionner avec un stockage d'objets volumineux si de nombreux petits fichiers y sont stockés. Plus le nombre et la taille des fichiers sont élevés, plus la RAM du Store Gateway et du compacteur est importante pour stocker les métainformations. Thanos a beaucoup de problèmes concernant le fait que .
Thanos est annoncé pour évoluer indéfiniment avec la quantité de Prometheus dont vous disposez. Ce n’est en fait pas vrai. Étant donné que toutes les requêtes passent par le composant Query, qui doit interroger simultanément tous les composants Store Gateway et tous les composants Sidecar, extraire les données de là, puis les prétraiter. Évidemment, la vitesse de requête est limitée par le lien faible le plus lent, le Store Gateway le plus lent ou le Sidecar le plus lent.
Ces composants peuvent être chargés de manière inégale. Par exemple, vous avez Prometheus, qui collecte des millions de métriques par seconde. Et il y a Prometheus, qui collecte des milliers de métriques par seconde. Prometheus, qui collecte des millions de métriques par seconde, impose une charge beaucoup plus élevée au serveur sur lequel il s'exécute. En conséquence, Sidecar y fonctionne plus lentement. Et en général, tout y fonctionne lentement. Et le composant Query en extraira les données très lentement. En conséquence, les performances de l’ensemble de votre cluster seront limitées par ce side-car lent.
Par défaut, Thanos fournit des données partielles si certains side-cars et Store Gateway ne sont pas disponibles. Par exemple, si vos side-cars sont dispersés dans le monde entier dans différents centres de données, la probabilité d'une panne de connexion et d'une indisponibilité des composants augmente considérablement. Par conséquent, dans la plupart des cas, vous recevrez des données partielles sans même le savoir.
VictoriaMetrics comporte également des pièges. Le premier écueil est l’option qui limite la quantité de RAM utilisée pour le cache VictoriaMetrics. Par défaut, il est égal à 60 % de la RAM de la machine sur laquelle VictoriaMetrics est exécuté ou à 60 % de la RAM du pod VictoriaMetrics dans Kubernetes.
Si vous modifiez cette valeur de manière incorrecte, vous pouvez ruiner les performances de VictoriaMetrics. Par exemple, si vous définissez une valeur trop faible, les données risquent de ne plus tenir dans le cache VictoriaMetrics. Pour cette raison, elle devra effectuer un travail supplémentaire et charger le processeur et le disque. Si vous rendez cette option trop grande, cela augmente, d'une part, la probabilité que VictoriaMetrics plante avec une erreur de mémoire insuffisante et, d'autre part, cela conduira au fait qu'il restera très peu de RAM dans la mémoire du système d'exploitation pour cache de fichiers. Et VictoriaMetrics s'appuie sur un cache de fichiers pour ses performances. Si cela ne suffit pas, la charge sur le disque peut augmenter considérablement. Conseil donc : ne modifiez le paramètre que si cela est absolument nécessaire.
Deuxième option. Il s'agit de retentionPeriod - une période définie par défaut sur 1 mois. Il s'agit de la durée pendant laquelle VictoriaMetrics stocke les données. Passé ce délai, VictoriaMetrics supprime les données.
De nombreuses personnes exécutent VictoriaMetrics sans ce paramètre et enregistrent des données pendant un mois. Et puis ils demandent : pourquoi les données du mois précédent ont-elles disparu ? Parce que la période de rétention par défaut est de 1 mois. Par conséquent, vous devez connaître et définir la période de rétention correcte.
Jetons un coup d'œil aux fonctionnalités uniques.
Thanos possède une fonctionnalité appelée sous-échantillonnage : des intervalles de 5 minutes et d'une heure, qui sont souvent . Si vous recherchez sur Google et examinez leur problème sur github, il y a de nombreux problèmes liés à ce sous-échantillonnage, qui ne fonctionnent parfois pas correctement ou ne fonctionnent pas comme les utilisateurs l'attendent.
Thanos dispose d'une déduplication de données pour les paires Prometheus HA. Lorsque deux Prometheus collectent les mêmes métriques à partir des mêmes cibles et que Thanos les stocke dans Object Storage. Thanos peut correctement dédupliquer ces données, contrairement à VictoriaMetrics.
Thanos a un composant d'alerte qui figurait dans le schéma de Thanos. Mais lui .
Thanos a l'avantage que Thanos et Prometheus partagent le même code. Thanos et Prometheus sont développés par les mêmes développeurs. Avec des améliorations apportées à Thanos ou Prométhée, l’autre camp gagne.
La fonctionnalité principale de VictoriaMetrics est MetricsQL. Ce sont des extensions VictoriaMetrics pour PromQL, dont j'ai parlé lors de la précédente grande réunion de surveillance.
VictoriaMetrics prend en charge le chargement de données à l'aide de nombreux protocoles différents. VictoriaMetrics peut non seulement accepter les données de Prometheus, mais également via les protocoles Influx, OpenTSDB et Graphite.
Les données VictoriaMetrics prennent beaucoup moins de place que celles de Thanos et Prometheus.
Si vous enregistrez des données réelles, les utilisateurs parlent d'une réduction de 2 à 5 fois de la taille des données sur le disque par rapport à Prometheus et Thanos.
Un autre avantage de VictoriaMetrics est qu'il est optimisé pour la vitesse.
Regardons le coût des infrastructures.
L’un des avantages de Thanos est qu’il stocke les données dans un stockage objet, ce qui est relativement bon marché.
Lorsque vous stockez des données dans un stockage objet, vous devez payer pour les opérations d'écriture et de lecture des données (10 $ par million d'opérations). Lorsque vous écrivez des données sur le stockage objet, vous payez vos frais d'hébergement pour le téléchargement des données sur Internet ; si votre cluster n'est pas dans AWS, il y est gratuit. Lorsque vous lisez des données, vous payez entre 10 $ et 230 $ par 1 To. Cela peut être important si vous interrogez fréquemment les données historiques du cluster Thanos.
Pour un cluster Thanos, vous devez payer pour des serveurs pour les composants Compact, Store Gateway, Query qui nécessitent beaucoup de mémoire et un processeur pour de grandes quantités de données.
VictoriaMetrics a les dépenses suivantes. Si vous stockez des données sur des disques durs GCE, cela revient à 40 $ pour 1 To. Pour VictoriaMetrics, les disques durs ordinaires suffisent ; aucun SSD, qui coûte cinq fois plus cher, n'est nécessaire. VictoriaMetrics est optimisé pour le disque dur.
VictoriaMetrics nécessite des serveurs pour les composants : soit des composants à nœud unique, soit des composants en cluster, qui, contrairement aux composants Thanos, nécessitent beaucoup moins de CPU et de RAM - et seront donc moins chers.
Exemples de mise en œuvre.
Thanos a un exemple d'implémentation dans Gitlab. Gitlab fonctionne entièrement sur Thanos. Mais tout ne se passe pas aussi bien là-bas. Si tu les regardes , alors vous pouvez voir qu'ils en ont constamment : Il n'y a pas assez de mémoire pour les composants Store Gateway ou Query. Ils doivent constamment augmenter la quantité de mémoire.
De ce fait, les coûts liés à la résolution de ces problèmes augmentent.
La deuxième implémentation, qui pourrait être plus réussie, est celle de la société Improbable, qui a commencé à développer Thanos. Ils ont publié le code source de Thanos. Improbable est une entreprise qui développe des moteurs de jeux.
VictoriaMetrics propose des exemples de mise en œuvre publique :
- Constructeur de site Web wix.com
- Adidas implémente VictoriaMetrics et a même fait une présentation lors de la dernière PromCon 2019
- TrafficStars - réseau publicitaire
- Seznam.cz est un moteur de recherche tchèque populaire.
Et puis il y avait des sociétés anonymes que je ne peux pas nommer aujourd’hui. Ils n'ont pas consenti.
- Un développeur de jeux majeur. Plus grand que je suis improbable.
- Développeur majeur de logiciels graphiques.
- Grande banque russe.
- Fabricant européen d'éoliennes qui a testé avec succès VictoriaMetrics. Ce fabricant met en œuvre VictoriaMetrics pour surveiller les données collectées par les éoliennes à raison de 50 échantillons par seconde et par capteur. Chaque éolienne possède plusieurs centaines de capteurs. Ils disposent de plusieurs centaines d'éoliennes.
- Les compagnies aériennes russes qui souhaitent mettre en œuvre VictoriaMetrics, mais n’y parviennent toujours pas. Nous sommes au stade du contrat avec eux.
Conclusions.
VictoriaMetrics et Thanos résolvent des problèmes similaires, mais de différentes manières :
- Vue de requête globale
- mise à l'échelle horizontale
- rétention arbitraire
Merci.
Nous vous attendons à notre .
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Qu'utilisez-vous comme stockage à long terme pour Prometheus ?
-
35,3%Thanos6
-
0,0%Cortex0
-
0,0%M3DB0
-
41,2%VictoriaMetrics7
-
23,5%autre4
17 utilisateurs ont voté. 16 utilisateurs se sont abstenus.
Source: habr.com