2022-04-08 20:39:14 +00:00
|
|
|
|
::::: {.exercice}
|
|
|
|
|
|
2022-10-18 04:14:44 +00:00
|
|
|
|
### Exercice (obligatoire pour les SRS -- optionnel pour les GISTRE) {-}
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
Poursuivons [notre script de monitoring](#script-monitoring) afin d'envoyer nos
|
2022-02-24 19:43:43 +00:00
|
|
|
|
résultats vers InfluxDB : nous l'appellerons `./telegraf.sh`.
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
2022-10-18 04:14:44 +00:00
|
|
|
|
### Rappel d'InfluxDB
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
Commençons par lancer le conteneur Docker d'InfluxDB (pour éviter de
|
2022-02-24 19:43:43 +00:00
|
|
|
|
l'installer sur notre machine) :
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```bash
|
|
|
|
|
docker container run --name mytsdb -d -p 8086:8086 influxdb:1.8
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
2022-10-18 04:14:44 +00:00
|
|
|
|
::::: {.warning}
|
|
|
|
|
|
|
|
|
|
Nous utilisons la version 1.8 d'influxDB qui est plus simple à administrer pour
|
|
|
|
|
faire des tests. Vous pouvez partir sur la version 2, une API compatible avec
|
|
|
|
|
la version 1 est disponible, elle est plus simple à utiliser à partir d'un
|
|
|
|
|
shell.
|
|
|
|
|
|
|
|
|
|
:::::
|
|
|
|
|
|
2021-10-05 15:23:09 +00:00
|
|
|
|
Il nous faut ensuite créer une base de données pour y stocker nos
|
|
|
|
|
métriques. Voici comment on s'était débrouillé précédemment pour interagir avec
|
2022-02-24 19:43:43 +00:00
|
|
|
|
InfluxDB :
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```bash
|
|
|
|
|
docker container exec -i mytsdb influx <<EOF
|
|
|
|
|
CREATE DATABASE metrics;
|
|
|
|
|
SHOW DATABASES;
|
|
|
|
|
EOF
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Vérifiez que la base de données `metrics` a bien été créée.
|
|
|
|
|
|
|
|
|
|
|
2022-10-18 04:14:44 +00:00
|
|
|
|
### Monitoring vers InfluxDB
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
Maintenant, envoyons nos données vers la base
|
2022-02-24 19:43:43 +00:00
|
|
|
|
<https://docs.influxdata.com/influxdb/v1.8/guides/write_data/> :
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```bash
|
|
|
|
|
curl -i -XPOST 'http://localhost:8086/write?db=metrics' --data-binary \
|
|
|
|
|
"$my_cgroup_name memory.usage_in_bytes=$(cat .../my_cgroup_name/memory.usage_in_bytes)"
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
Pour vérifier que les données ont bien été ajoutées, nous pouvons effectuer la
|
2022-02-24 19:43:43 +00:00
|
|
|
|
requête suivante dans notre client `influx` :
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```sql
|
|
|
|
|
SELECT * from "$my_cgroup_name";
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
2022-10-18 04:14:44 +00:00
|
|
|
|
### Monitorer davantage de données
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
Liste non exhaustive de données à monitorer :
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
2022-02-24 19:43:43 +00:00
|
|
|
|
* Nombre d'IOs effectué ;
|
2022-10-18 14:40:31 +00:00
|
|
|
|
* nombre d'octets lus/écrits sur les disques ;
|
2022-02-24 19:43:43 +00:00
|
|
|
|
* temps de calcul utilisé (`userspace`, `system`, tout confondu) ;
|
2021-10-05 15:23:09 +00:00
|
|
|
|
* ...
|
|
|
|
|
|
|
|
|
|
Tous les cgroups existants dans le dernier noyau publié ont leur documentation
|
2022-02-24 19:43:43 +00:00
|
|
|
|
accessible ici :
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
- v1 : <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/index.html>
|
|
|
|
|
- v2 : <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html>
|
|
|
|
|
|
|
|
|
|
|
2022-10-18 04:14:44 +00:00
|
|
|
|
### Permettre à l'utilisateur de monitorer des processus
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
Maintenant, séparons notre script en deux parties afin qu'un utilisateur normal
|
2022-10-26 14:57:27 +00:00
|
|
|
|
(non-root) puisse utiliser la partie monitoring de notre script. La procédure
|
|
|
|
|
sera différente suivant la version des *cgroup*s que vous utilisez.
|
|
|
|
|
|
|
|
|
|
#### *cgroup*s v1\
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
|
|
|
|
Un premier script doit s'occuper de créer le(s) *cgroup*s et lui attribuer les
|
2022-10-18 04:14:44 +00:00
|
|
|
|
bons droits (`chown $EUID`), tandis que le deuxième va effectuer le monitoring,
|
|
|
|
|
sans privilèges particuliers.
|
2021-10-05 15:23:09 +00:00
|
|
|
|
|
2022-10-26 14:57:27 +00:00
|
|
|
|
##### Exemple {-}
|
|
|
|
|
\
|
2021-10-05 15:23:09 +00:00
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```
|
|
|
|
|
42sh$ sudo ./telegraf_init.sh my_cgroup_name
|
|
|
|
|
42sh$ ./telegraf.sh my_cgroup_name memhog 500
|
|
|
|
|
```
|
|
|
|
|
</div>
|
2022-04-08 20:39:14 +00:00
|
|
|
|
|
2022-10-26 14:57:27 +00:00
|
|
|
|
|
|
|
|
|
#### *cgroup*s v2\
|
|
|
|
|
|
|
|
|
|
On part du principe que `systemd` est le système d'initialisation de votre
|
|
|
|
|
machine et qu'il gère lui-même l'arborescence.
|
|
|
|
|
|
|
|
|
|
Dans cette version des *cgroup*s, on peut toujours déléguer une partie de
|
|
|
|
|
l'arborescence à un utilisateur, au moyen d'un `chown`, cependant une
|
|
|
|
|
contrainte supplémentaire entre en jeu. Lorsque l'on veut déplacer un
|
|
|
|
|
processus, il faut avoir les droits d'écriture à la fois sur la destination,
|
|
|
|
|
mais également sur la source, et sur tous les nœuds de l'arborescence que l'on
|
|
|
|
|
peut croiser lors du parcourt de l'arbre.
|
|
|
|
|
|
|
|
|
|
Cela signifie, qu'après avoir `mkdir -p virli/child1 virli/child2 && chown -R
|
|
|
|
|
$EUID:$EUID virli`, il est possible de déplacer un processus de :
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
/virli/child1
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
vers
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
/virli/child2
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
car on dispose bien des droits d'écriture sur l'ancêtre commun le plus proche
|
|
|
|
|
(à savoir `/virli`).
|
|
|
|
|
|
|
|
|
|
Les problèmes surviennent lorsque l'on souhaite déplacer un processus que
|
|
|
|
|
`systemd` a placé dans :
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
/user.slice/user@$UID.service/app.slice/app-alacritty-0a1b2c3d4e5f6e7d9c
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Il ne sera alors pas possible de le déplacer vers `/virli/child1`, car
|
|
|
|
|
l'ancêtre commun le plus proche est la racine des *cgroup*s, sur laquelle
|
|
|
|
|
l'utilisateur n'a pas les droits d'écriture.\
|
|
|
|
|
|
|
|
|
|
Pour faire cet exercice, vous allez donc devoir rechercher l'ancêtre commun le
|
|
|
|
|
plus proche sur lequel votre utilisateur a les droits d'écritures.
|
|
|
|
|
|
|
|
|
|
En utilisant `systemd` :
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
42sh$ systemctl --user show | grep ControlGroup
|
|
|
|
|
ControlGroup=/user.slice/user-1234.slice/user@1234.service
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Ou bien en recherchant dans l'arborescence des *cgroup*s votre processus :
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
42sh$ find /sys/fs/cgroup/ -name cgroup.procs -exec grep -l $$ {} \;
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
... puis en remontant tant que l'on dispose des droits d'écritures.\
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Le script `telegraf_init.sh` devra retourner le chemin vers le dossier
|
|
|
|
|
(éventuellement) créé à partir du nom passé en paramètre, depuis la racine des
|
|
|
|
|
*cgroup*s.
|
|
|
|
|
|
|
|
|
|
Ce retour servira de premier argument au script `telegraf.sh`.
|
|
|
|
|
|
|
|
|
|
##### Exemple {-}
|
|
|
|
|
\
|
|
|
|
|
<div lang="en-US">
|
|
|
|
|
```
|
|
|
|
|
42sh$ ./telegraf_init.sh my_cgroup_name
|
|
|
|
|
/user.slice/user@1234.service/my_cgroup_name
|
|
|
|
|
42sh$ ./telegraf.sh "/user.slice/user@1234.service/my_cgroup_name" memhog 500
|
|
|
|
|
```
|
|
|
|
|
</div>
|
|
|
|
|
|
2022-04-08 20:39:14 +00:00
|
|
|
|
:::::
|