Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
technique:adminsys:monitoring:metrologie:victoriametrics [2021/02/14 16:20] – kyane | technique:adminsys:monitoring:metrologie:victoriametrics [2022/05/24 21:06] (Version actuelle) – ppom |
---|
===== Pull / Prometheus ===== | ===== Pull / 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/dockerfiles/-/blob/master/pica-metrologie/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 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 : | 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 [[technique:adminsys:monitoring:metrologie:system_metrics|métriques systèmes]] des machines virtuelles | * les [[technique:adminsys:monitoring:collect:system_metrics|métriques systèmes]] des machines virtuelles |
* les [[technique:adminsys:monitoring:metrologie:service_metrics|métriques des services]] | * 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 ====== | ====== 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`]]. | 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 : |
| |
| ```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. |