Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:adminsys:monitoring:alerting:vmalert [2021/09/01 16:10] qduchemitechnique:adminsys:monitoring:alerting:vmalert [2022/05/24 20:54] (Version actuelle) ppom
Ligne 11: Ligne 11:
 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.
Ligne 20: Ligne 20:
  
 ``` ```
-rate(traefik_service_requests_total{service_name~="team.picasoft.net"}[5m)+rate(traefik_service_requests_total{service_name~="team.picasoft.net"}[5m])
 ``` ```
  
Ligne 34: Ligne 34:
  
 <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>
  
-`vmalert` est exécuté depuis l'image Docker officielle et la configuration s'effectue avec les arguments de la ligne de commande (voir [Docker Compose](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-metrologie/docker-compose.yml)) et via un fichier de règles.+`vmalert` est exécuté depuis l'image Docker officielle et la configuration s'effectue avec les arguments de la ligne de commande (voir [Docker Compose](https://gitlab.utc.fr/picasoft/projets/services/monitoring/-/blob/master/docker-compose.yml)) et via un fichier de règles.
  
 <bootnote web> <bootnote web>
-Le but de cette documentation n'est pas d'être exhaustif mais de donner une intuition. Voir la [documentation de vmalert](https://docs.victoriametrics.com/vmalert.html) pour un tour d'horizon de toutes les options. Le fichier de règles utilisé en production se trouve [ici](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-metrologie/vmalert-rules.yml).+Le but de cette documentation n'est pas d'être exhaustif mais de donner une intuition. Voir la [documentation de vmalert](https://docs.victoriametrics.com/vmalert.html) pour un tour d'horizon de toutes les options. Le fichier de règles utilisé en production se trouve [ici](https://gitlab.utc.fr/picasoft/projets/services/monitoring/-/blob/master/vmalert-rules.yml).
 </bootnote> </bootnote>
  
Ligne 55: Ligne 55:
 ### Exemple de règle ### Exemple de règle
  
-Prenons un cas simple. Pour chaque service, [[technique:adminsys:monitoring:metrologie:collect:blackbox|Blackbox exporter]] expose une métrique nommée `probe_success`, qui correspond à l'état de santé du service et vaut `0` s'il est *down* et `1` s'il est *up*.+Prenons un cas simple. Pour chaque service, [[technique:adminsys:monitoring:collect:blackbox|Blackbox exporter]] expose une métrique nommée `probe_success`, qui correspond à l'état de santé du service et vaut `0` s'il est *down* et `1` s'il est *up*.
  
 L'alerte correspondante sera : L'alerte correspondante sera :
Ligne 95: Ligne 95:
 </bootnote> </bootnote>
  
-Tout ce qui concerne les disques, la mémoire, le CPU... est collecté grâce à [[technique:adminsys:monitoring:metrologie:collect:system_metrics|node_exporter]], et associé à [ce dashboard Grafana](https://grafana.picasoft.net/d/VIb73SGWa/server-overview). On trouve le graphe associé aux disques, et on clique sur `Edit`.+Tout ce qui concerne les disques, la mémoire, le CPU... est collecté grâce à [[technique:adminsys:monitoring:collect:system_metrics|node_exporter]], et associé à [ce dashboard Grafana](https://grafana.picasoft.net/d/VIb73SGWa/server-overview). On trouve le graphe associé aux disques, et on clique sur `Edit`.
  
 {{ :technique:adminsys:monitoring:alerting:disk_usage_grafana.png |}} {{ :technique:adminsys:monitoring:alerting:disk_usage_grafana.png |}}
Ligne 189: Ligne 189:
 C'est un cas très spécifique mais qui peut rendre perplexe. Parfois, certaines métriques ne portent pas toutes les métadonnées qui les concernent, pour plusieurs [bonnes raisons](https://www.robustperception.io/target-labels-are-for-life-not-just-for-christmas) : notamment, ne pas dupliquer des informations sur les disques dans toutes les métriques concernant les disques. C'est un cas très spécifique mais qui peut rendre perplexe. Parfois, certaines métriques ne portent pas toutes les métadonnées qui les concernent, pour plusieurs [bonnes raisons](https://www.robustperception.io/target-labels-are-for-life-not-just-for-christmas) : notamment, ne pas dupliquer des informations sur les disques dans toutes les métriques concernant les disques.
  
-Par exemple, la métrique `pve_disk_usage_bytes`, de [[technique:adminsys:monitoring:metrologie:collect:proxmox_metrics|l'exporter Proxmox]], ne contient que quelques labels, par exemple :+Par exemple, la métrique `pve_disk_usage_bytes`, de [[technique:adminsys:monitoring:collect:proxmox_metrics|l'exporter Proxmox]], ne contient que quelques labels, par exemple :
  
 ```json ```json
Ligne 200: Ligne 200:
 ``` ```
  
-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>
  
  • technique/adminsys/monitoring/alerting/vmalert.1630505419.txt.gz
  • de qduchemi