| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
| technique:adminsys:monitoring:metrologie:system_metrics [2020/11/18 20:20] – kyane | technique:adminsys:monitoring:collect:system_metrics [2022/05/24 21:07] (Version actuelle) – ppom |
|---|
| {{indexmenu_n>20}} | {{indexmenu_n>20}} |
| |
| ====== Métriques système ====== | # Systèmes d'exploitation |
| |
| On veut collecter des métriques systèmes (CPU, RAM, disque, réseau, etc.) sur les différentes machines virtuelles. Pour cela on va utiliser le [[https://github.com/prometheus/node_exporter|Prometheus Node Exporter]], qui est un *exporter* officiellement maintenu par Prometheus et qui exporte une très grande quantité de métriques système. | On veut collecter des métriques systèmes (CPU, RAM, disque, réseau, etc.) sur les différentes machines virtuelles et physiques. Pour cela on va utiliser le [[https://github.com/prometheus/node_exporter|Prometheus Node Exporter]], qui est un *exporter* officiellement maintenu par Prometheus et qui exporte une très grande quantité de métriques système. |
| |
| ===== Installation ===== | ===== Installation ===== |
| |
| Le //node-exporter// va exposer des métriques sur le port 9100 de la machine. Ceci signifie que n'importe qui peut récupérer les métriques du serveur. Il est donc nécessaire de configurer du filtrage pour n'autoriser que l'IP de notre serveur de monitoring. | Le //node-exporter// va exposer des métriques sur le port 9100 de la machine. Ceci signifie que n'importe qui peut récupérer les métriques du serveur. Il est donc nécessaire de configurer du filtrage pour n'autoriser que l'IP de notre serveur de monitoring. |
| Si UFW a bien été configuré [[https://wiki.picasoft.net/doku.php?id=technique:infrastructure:machines_virtuelles:reseau_ssh#firewall|à l'installation du serveur]] c'est chose faites. Sinon il faut ajouter la règle suivante : | |
| | Vérifier qu'UFW a [[technique:adminsys:secu:firewall|bien été configuré]]. |
| | |
| | <bootnote critical> |
| | Rajouter une règle sur un UFW non configuré bloquera entièrement l'accès au serveur ! Si la commande `ufw status` (en `root`) ne renvoie rien, alors UFW n'est pas configuré, il faut absolument le faire avant. |
| | </bootnote> |
| | |
| | Ajouter la règle suivante : |
| ```bash | ```bash |
| ufw allow proto tcp from 91.224.148.61 to any port 9100 | ufw allow proto tcp from <IPv4 monitoring> to any port 9100 |
| ufw allow proto tcp from 2a03:7220:8080:3d00::1 to any port 9100 | ufw allow proto tcp from <IPv6 monitoring> to any port 9100 |
| ``` | ``` |
| |
| ===== Configuration serveur ===== | ===== Configuration serveur ===== |
| |
| Du côté de `vmagent`, il faut ajouter une entrée dans le [[https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/blob/master/pica-metrologie/vmagent-prom.yml|fichier de configuration Prometheus]]. Pour cela on va ajouter une entrée dans la section ''scrape_config'' du fichier : | Du côté de `vmagent`, il faut ajouter une entrée dans le [[https://gitlab.utc.fr/picasoft/projets/services/monitoring/-/blob/master/vmagent-prom.yml|fichier de configuration Prometheus]]. Pour cela on va ajouter une entrée dans la section ''scrape_config'' du fichier : |
| |
| ```yaml | ```yaml |
| replacement: 'pica01' | replacement: 'pica01' |
| ``` | ``` |
| | |
| | <bootnote> |
| | Le *relabeling* permet simplement d'éviter que le nom de domaine et que l'hôte se retrouvent dans le label `instance` : on ne garde que `pica01`. |
| | </bootnote> |
| | |
| | Il suffit enfin de redémarrer `vmagent` sur la machine qui le fait tourner pour prendre en compte la nouvelle configuration. |
| | Le dashboard Grafana s'adapte automatiquement en proposant les machines ajoutées dans la configuration. |