Picasoft s’appuie sur Victoria Metrics (ou “VM”) pour sa stack de métrologie. C’est un projet de TSDB qui est assez jeune (fin 2018) qui est rapidement devenu très prometteur. Parmi ces avantages, VM propose une compatibilité avec la plupart des TSDB/protocoles de collecte de métriques existants, et surtout des performances bien plus importantes.
De plus le projet supporte les requêtes via le langage MetricsQL qui est une implémentation améliorée de PromQL (de Prometheus): on peut donc faire des requêtes en base de manière 100% compatible avec Prometheus. Ceci permet aussi d’utiliser Alertmanager ou vmalert pour déclencher des alertes sur les métriques.

Un point négatif à noter est la faible documentation du projet, cependant l’essentiel (et surtout ce qui est nécessaire pour Picasoft) est correctement couvert.

Victoria Metrics stocke les données directement sur disque. Une durée de rétention est configurable (1 mois par défaut) et s’applique à l’ensemble de l’instance : il n’est pas possible de la modifier pour une ou des métriques ne particulier. À Picasoft nous avons pour le moment fait le choix de garder indéfiniment les métriques, en particulier car celles associées à nos services (comme la quantité de comptes créés) sont importantes pour l’historique de l’association. Pour ce faire nous avons configuré la rétention, avec l’option -retentionPeriod, à 1200 mois, soit 100 ans.

L’outil proposé par Victoria Metrics pour l’ingestion de metrics est `vmagent`. C’est un petit composant qui se dépose à côté de Victoria Metrics et qui lui permet de collecter des métriques de manière compatible avec de nombreux protocoles. Il se charge donc de la collecte de métriques, qu’il écrit directement dans la base Victoria Metrics. En cas d’indisponibilité de la TSDB, il stocke dans un buffer sur disque les métriques collectées.
Dans le cas de Picasoft, on utilisé 2 méthodes d’ingestion différentes avec vmagent.

La première méthode est celle compatible avec Prometheus. vmagent prends en paramètre un fichier de configuration Prometheus dans lequel va se trouver la configuration des exporters à collecter (TODO lien exemple Gitlab). vmagent propose ainsi une compatibilité complète (en tout cas sur les fonctionnalités utilisées par Picasoft) avec Prometheus.

Cette méthode d’ingestion est à privilégier pour toute nouvelle collecte de métrique : elle est légère, simple à mettre en place, et plutôt sécurisante pour l’infrastructure (modèle pull plutôt que push). Elle nécessite quelques lignes de configuration côté serveur, et un simple mécanisme de sécurité côté exporter pour que seul le serveur monitoring puisse accéder à celui-ci. Cette méthode est utilisée pour collecter les métriques suivantes :

• les métriques systèmes des machines virtuelles (TODO lien wiki)
• les métriques de certains services (TODO lien wiki)

Le seconde méthode utilisée est la compatibilité de vmagent avec le InfluxDB Line Protocol, qui est le protocole utilisé pour écrire dans une TSDB InfluxDB (modèle push). Cette méthode est utilisée pour certains services qui ne propose pas d’exporter Prometheus nativement. Pour cela on utilise le metrics-bot de Picasoft (TODO lien wiki). Cette méthode n’est pas à privilégier lorsque l’on peut utiliser la première.

À coter que vmagent ne propose pas nativement de l’authentification InfluxDB (il faut pour cela utiliser `vmauth`), Picasoft n’expose donc pas directement le port permettant d’envoyer des métriques avec ce protocole. Tout passe par le pica-metrics-bot, qui est sur un réseau Docker partagé avec vmagent.

Victoria Metrics ne nécessite pas particulièrement de maintenance, hormis des mises à jour. On note cependant l’existence d’un outil pour certaines opérations, comme par exemple la migration depuis une ancienne TSDB : `vmctl`.