| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révisionLes deux révisions suivantes |
| technique:adminsys:monitoring:alerting:vmalert [2021/09/01 16:09] – qduchemi | technique:adminsys:monitoring:alerting:vmalert [2021/11/22 23:12] – ↷ Liens modifiés en raison d'un déplacement. qduchemi |
|---|
| Pour résumer très rapidement ce qui est utile, Picasoft stocke des **métriques** (mesure de n'importe quoi dans l'infrastructure : nombre de requêtes, utilisation CPU...) dans une time series database (TSDB). Une TSDB est une base de données optimisée pour stocker des séries de données associées à un horodatage, nommées *timeseries*. Picasoft utilise [[technique:adminsys:monitoring:metrologie:victoriametrics|Victoria Metrics]]. | Pour résumer très rapidement ce qui est utile, Picasoft stocke des **métriques** (mesure de n'importe quoi dans l'infrastructure : nombre de requêtes, utilisation CPU...) dans une time series database (TSDB). Une TSDB est une base de données optimisée pour stocker des séries de données associées à un horodatage, nommées *timeseries*. Picasoft utilise [[technique:adminsys:monitoring:metrologie:victoriametrics|Victoria Metrics]]. |
| |
| Les métriques suivent des [conventions de nommages](https://prometheus.io/docs/practices/naming) permettant de deviner leur nature (*e.g* `node_memory_MemAvailable_bytes`, qui s'auto-décrit bien). | Les métriques suivent des [conventions de nommages](https://prometheus.io/docs/practices/naming) permettant de deviner leur nature (*e.g* `traefik_service_requests_total`, qui s'auto-décrit bien). |
| |
| Chaque métrique est associée à des **labels**, qui portent des métadonnées sur la mesure, par exemple pour préciser le service ou la machine concernée par la métrique. | Chaque métrique est associée à des **labels**, qui portent des métadonnées sur la mesure, par exemple pour préciser le service ou la machine concernée par la métrique. |
| |
| ``` | ``` |
| rate(traefik_service_requests_total{service_name~="team.picasoft.net"}[5m) | rate(traefik_service_requests_total{service_name~="team.picasoft.net"}[5m]) |
| ``` | ``` |
| |
| |
| <bootnote> | <bootnote> |
| Dans `vmalert`, une règle est une condition sur le résultat d'une requête [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/). L'outil a en effet été conçu pour être compatible avec les fichiers d'alertes utilisés dans le monde Prometheus. | Dans `vmalert`, une règle est une condition sur le résultat d'une requête [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/). PromQL est initialement développé pour faire des requêtes sur une TSDB Prometheus, mais nous utilisons Victoria Metrics, qui est compatible avec l'écosystème Prometheus. Le format de fichier d'alertes `vmalert` est compatible avec le format de fichier d'alertes utilisé dans l'écosystème Prometheus. |
| </bootnote> | </bootnote> |
| |
| ``` | ``` |
| |
| <bootnote>Remarquer l'utilisation de la fonction `printf` pour formater la valeur en enlevant les virgules, et de $value qui contient la valeur ayant fait évaluer la règle positivement.</bootnote> | <bootnote>Remarquer l'utilisation de la fonction `printf` pour formater la valeur en enlevant les virgules, et de `$value` qui contient la valeur ayant fait évaluer la règle positivement.</bootnote> |
| |
| Ne reste plus qu'à ajouter le lien du dashboard Grafana, où on ajoutera une variable à l'URL pour filtrer directement par la machine concernée : | Ne reste plus qu'à ajouter le lien du dashboard Grafana, où on ajoutera une variable à l'URL pour filtrer directement par la machine concernée : |
| |
| ``` | ```yaml |
| dashboard: https://grafana.picasoft.net/d/VIb73SGWa/server-overview?var-node={{ $labels.instance }} | dashboard: https://grafana.picasoft.net/d/VIb73SGWa/server-overview?var-node={{ $labels.instance }} |
| ``` | ``` |
| ``` | ``` |
| |
| Or, pour notre message d'alerte, on aimerait bien savoir à quel [[technique:infrastructure:hyperviseurs:install_proxmox#configuration_du_stockage_proxmox|stockage Proxmox]] celui-ci correspond. | Or, pour notre message d'alerte, on aimerait bien savoir à quel [[technique:infrastructure:install_proxmox#configuration_du_stockage_proxmox|stockage Proxmox]] celui-ci correspond. |
| |
| <bootnote learn> | <bootnote learn> |
| La façon idiomatique de stocker des métadonnées associées à une métrique dans lui ajouter trop de labels est de créer une [pseudo-métrique](https://prometheus.io/docs/practices/naming/), suffixée par `_info`, et valant 1. De la sorte, on peut combiner les labels de la métrique dont la valeur nous intéresse avec les labels de la pseudo-métrique via une multiplication, qui ne change rien au résultat, puisque la pseudo-métrique vaut 1. | La façon idiomatique de stocker des métadonnées associées à une métrique sans lui ajouter trop de labels est de créer une [pseudo-métrique](https://prometheus.io/docs/practices/naming/), suffixée par `_info`, et valant 1. De la sorte, on peut combiner les labels de la métrique dont la valeur nous intéresse avec les labels de la pseudo-métrique via une multiplication, qui ne change rien au résultat, puisque la pseudo-métrique vaut 1. |
| </bootnote> | </bootnote> |
| |