Victoria Metrics pour stocker les métriques
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.
Stockage
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.
Ingestion
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 uniquement la méthode d’ingestion Prometheus avec vmagent
.
Pull / Prometheus
Cette 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. 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
- les métriques de santé des serveurs web/DNS
Administration
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.
Effectuer des requêtes via l'API (debug)
On peut faire des requêtes sur les données de Victoria Metrics à des fins de debug :
- Vérifier qu’une métrique est bien présente
- Obtenir les valeurs brutes d’une métrique
- Vérifier les valeurs d’une métrique pour un label particulier
- etc.
Le requêtage de Victoria Metrics s’effectue avec PromQL, le langage de requêtage de Prometheus.
S’il est possible d’effectuer ces requêtes via Grafana, le plus simple est parfois d’obtenir les valeurs brutes.
Pour ce faire, il suffit de se rendre dans le conteneur Victoria Metrics et d’installer curl
et jq
, puis d’effectuer des requêtes sur la base :
- snippet.bash
$ curl localhost:8428/api/v1/query --data-urlencode 'query=<PROM_QL_QUERY>' | jq
curl
permet de requêter l’API qui écoute sur le port 8428,- l’endpoint
/api/v1/query
permet d’effectuer une requête Prometheus classique et de récupérer la dernière valeur connue, --data-urlencode
permet de passer un paramètre GETjq
permet de formater le JSON de retour.
Lien:
- Le requêtage s’effectue comme expliqué ici : https://prometheus.io/docs/prometheus/latest/querying/basics/
- L’API a d’autres possibilités ; voir ici : https://prometheus.io/docs/prometheus/latest/querying/api
A Savoir:
D’autres endpoints existent en fonction des besoins :
- L’endpoint
/api/v1/query_range
permet de récupérer les valeurs sur une période de temps données : https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries - L’endpoint
/api/v1/admin/tsdb/delete_series
permet de supprimer des valeurs insérées par mégardes : https://prometheus.io/docs/prometheus/latest/querying/api/#delete-series - …
Cas d’utilisation concret : une alerte (levée par vmalert et transmise sur Mattermost par alertmanager) nous est envoyée tous les jours.
Cette alerte est levée quand la métrique probe_success
d’un service vaut 0, c’est-à-dire que le service ne répond pas. C’est Blackbox qui insère cette métrique. Or, Blackbox est configuré pour surveiller les sites web, le LDAP… mais pas lui-même ! Que veut dire ce blackbox.picasoft.net:443
? Il n’est pas dans la configuration…
Question:
On se demande donc : quelles sont les valeurs et autres métadonnées de la métrique probe_success
lorsque son label instance
vaut blackbox.picasoft.net:443
.
On peut alors faire :
- snippet.bash
$ curl localhost:8428/api/v1/query --data-urlencode 'query=probe_success{instance="blackbox.picasoft.net:443"}' | jq
On obtient :
- snippet.json
{ "status": "success", "data": { "resultType": "vector", "result": [ { "metric": { "__name__": "probe_success", "instance": "blackbox.picasoft.net:443", "job": "blackbox-mail" }, "value": [ 1643891576, "1" ] } ] } }
On comprend ici que c’est la partie de Blackbox qui surveille le serveur mail qui dysfonctionne (job blackbox-mail
), et on peut essayer de régler le problème.