Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:adminsys:monitoring:metrologie:victoriametrics [2020/11/16 00:23] – kyane
+++ technique:adminsys:monitoring:metrologie:victoriametrics [2022/05/24 21:06] (Version actuelle) – ppom
@@ Ligne 1: / Ligne 1: @@
-# Victoria Metrics
+{{indexmenu_n>10}}
+# Victoria Metrics pour stocker les métriques
 Picasoft s'appuie sur [[https://github.com/VictoriaMetrics/VictoriaMetrics|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 [[https://github.com/VictoriaMetrics/VictoriaMetrics#prominent-features|ces avantages]], VM propose une compatibilité avec la plupart des TSDB/protocoles de collecte de métriques existants, et surtout des [[https://valyala.medium.com/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae|performances bien plus importantes]].
@@ Ligne 13: / Ligne 15: @@
 L'outil proposé par Victoria Metrics pour l'ingestion de metrics est [[https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/app/vmagent/README.md|`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`.
+Dans le cas de Picasoft, on uniquement la méthode d'ingestion Prometheus avec `vmagent`.
 ===== Pull / Prometheus =====
-La première méthode est celle compatible avec Prometheus. `vmagent` prends en paramètre un [[https://prometheus.io/docs/prometheus/latest/configuration/configuration/|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 est celle compatible avec Prometheus. `vmagent` prends en paramètre un [[https://prometheus.io/docs/prometheus/latest/configuration/configuration/|fichier de configuration Prometheus]] dans lequel va se trouver [[https://gitlab.utc.fr/picasoft/projets/services/monitoring/-/blob/master/vmagent-prom.yml|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 (TODO lien wiki)
+  * les [[technique:adminsys:monitoring:collect:system_metrics|métriques systèmes]] des machines virtuelles
-  * les métriques de certains services (TODO lien wiki)
+  * les [[technique:adminsys:monitoring:collect:service_metrics|métriques internes des services]]
+  * les [[technique:adminsys:monitoring:collect:proxmox_metrics|métriques de Proxmox]]
+  * les [[technique:adminsys:monitoring:collect:blackbox|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 : [[https://github.com/VictoriaMetrics/vmctl|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 [[https://prometheus.io/docs/prometheus/latest/querying/basics/|PromQL]], le langage de requêtage de Prometheus.
+S'il est possible d'effectuer ces requêtes via [[technique:adminsys:monitoring:metrologie:grafana|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 :
+```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 GET
+- `jq` permet de formater le JSON de retour.
+<bootnote web>
+  * 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
+</bootnote>
+<bootnote learn>
+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
+  * ...
+</bootnote>
+Cas d'utilisation concret : une alerte (levée par [[technique:adminsys:monitoring:alerting:vmalert|vmalert]] et transmise sur Mattermost par [[technique:adminsys:monitoring:alerting:alertmanager|alertmanager]]) nous est envoyée tous les jours.
+{{:technique:adminsys:monitoring:metrologie:blackbox_alert.jpg|}}
+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 [[technique:adminsys:monitoring:collect:blackbox|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...
+<bootnote 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`.
+</bootnote>
+On peut alors faire :
+```bash
+$ curl localhost:8428/api/v1/query --data-urlencode 'query=probe_success{instance="blackbox.picasoft.net:443"}' | jq
+```
+On obtient :
-===== Push / Influx =====
+```json
+{
+  "status": "success",
+  "data": {
+    "resultType": "vector",
+    "result": [
+      {
+        "metric": {
+          "__name__": "probe_success",
+          "instance": "blackbox.picasoft.net:443",
+          "job": "blackbox-mail"
+        },
+        "value": [
+          1643891576,
+          "1"
+        ]
+      }
+    ]
+  }
+}
+```
-Le seconde méthode utilisée est la compatibilité de `vmagent` avec le [[https://docs.influxdata.com/influxdb/v2.0/reference/syntax/line-protocol/|InfluxDB Line Protocol]]
+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.