tuto3: Fix and complete cgroup part
This commit is contained in:
parent
7fcb8d0a8e
commit
412d69a649
|
|
@ -1,11 +1,11 @@
|
|||
::::: {.exercice}
|
||||
|
||||
### Exercice (obligatoire pour les SRS -- optionnel pour les GISTRE)
|
||||
### Exercice (obligatoire pour les SRS -- optionnel pour les GISTRE) {-}
|
||||
|
||||
Poursuivons [notre script de monitoring](#script-monitoring) afin d'envoyer nos
|
||||
résultats vers InfluxDB : nous l'appellerons `./telegraf.sh`.
|
||||
|
||||
#### Rappel d'InfluxDB
|
||||
### Rappel d'InfluxDB
|
||||
|
||||
Commençons par lancer le conteneur Docker d'InfluxDB (pour éviter de
|
||||
l'installer sur notre machine) :
|
||||
|
|
@ -16,6 +16,15 @@ docker container run --name mytsdb -d -p 8086:8086 influxdb:1.8
|
|||
```
|
||||
</div>
|
||||
|
||||
::::: {.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.
|
||||
|
||||
:::::
|
||||
|
||||
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
|
||||
InfluxDB :
|
||||
|
|
@ -32,7 +41,7 @@ EOF
|
|||
Vérifiez que la base de données `metrics` a bien été créée.
|
||||
|
||||
|
||||
#### Monitoring vers InfluxDB
|
||||
### Monitoring vers InfluxDB
|
||||
|
||||
Maintenant, envoyons nos données vers la base
|
||||
<https://docs.influxdata.com/influxdb/v1.8/guides/write_data/> :
|
||||
|
|
@ -54,7 +63,7 @@ SELECT * from "$my_cgroup_name";
|
|||
</div>
|
||||
|
||||
|
||||
#### Monitorer davantage de données
|
||||
### Monitorer davantage de données
|
||||
|
||||
Liste non exhaustive de données à monitorer :
|
||||
|
||||
|
|
@ -70,16 +79,16 @@ accessible ici :
|
|||
- v2 : <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html>
|
||||
|
||||
|
||||
#### Permettre à l'utilisateur de monitorer des processus
|
||||
### Permettre à l'utilisateur de monitorer des processus
|
||||
|
||||
Maintenant, séparons notre script en deux parties afin qu'un utilisateur normal
|
||||
(non-root) puisse utiliser la partie monitoring de notre script.
|
||||
|
||||
Un premier script doit s'occuper de créer le(s) *cgroup*s et lui attribuer les
|
||||
bons droits, tandis que le deuxième va effectuer le monitoring, sans privilèges
|
||||
particuliers.
|
||||
bons droits (`chown $EUID`), tandis que le deuxième va effectuer le monitoring,
|
||||
sans privilèges particuliers.
|
||||
|
||||
##### Exemple {-}
|
||||
#### Exemple {-}
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
|
|||
|
|
@ -175,16 +175,29 @@ echo $PID > /sys/fs/cgroup/{,freezer/}virli/cgroup.procs
|
|||
|
||||
Il faut ici remplacer `$PID` par le PID du shell que l'on a relevé juste avant.
|
||||
|
||||
::::: {.question}
|
||||
|
||||
#### Ne devrait-on pas utiliser `>>` pour ajouter le processus au fichier ? {-}
|
||||
|
||||
Malgré l'utilisation de la redirection `>` (et non `>>`), il s'agit bel et bien
|
||||
d'un ajout au fichier et non d'un écrasement. Il faut garder en tête que le
|
||||
système de fichier est entièrement simulé et que certains comportements sont
|
||||
adaptés.
|
||||
|
||||
:::::
|
||||
|
||||
En validant cette commande, nous avons déplacé le processus dans ce groupe, il
|
||||
n'est alors plus dans aucun autre groupe (pour ce *cgroup*, il ne bouge pas
|
||||
dans les autres *cgroup*s).
|
||||
dans les autres *cgroup*s de la v1).
|
||||
|
||||
::::: {.question}
|
||||
|
||||
Malgré l'utilisation de la redirection `>` (et non `>>`), il s'agit bel et
|
||||
bien d'un ajout au fichier et non d'un écrasement. Il faut garder en tête que
|
||||
le système de fichier est entièrement simulé et que certains comportements sont
|
||||
adaptés.
|
||||
#### Où sont placés les nouveaux processus ? {-}
|
||||
|
||||
Les nouveaux processus héritent des groupes de leur père.
|
||||
|
||||
Si vous lancez un `top` dans votre nouveau terminal, son PID sera présent dans
|
||||
le fichier `cgroup.procs`.
|
||||
|
||||
:::::
|
||||
|
||||
|
|
@ -197,12 +210,19 @@ sont en lecture seule et permettent de lire des statistiques instantanées sur
|
|||
le groupe ; tandis que d'autres sont des propriétés que nous pouvons modifier.
|
||||
|
||||
Nous pouvons consulter l'état de gel du groupe en affichant le contenu du
|
||||
fichier\
|
||||
`/sys/fs/cgroup/freezer/virli/freezer.state` ou `/sys/fs/cgroup/virli/cgroup.freeze`.
|
||||
fichier :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ cat /sys/fs/cgroup/freezer/virli/freezer.state # v1
|
||||
42sh$ cat /sys/fs/cgroup/virli/cgroup.freeze # v2
|
||||
```
|
||||
</div>
|
||||
|
||||
Pour plus d'informations sur les différents fichiers présents dans ce *cgroup*,
|
||||
consultez
|
||||
[la documentation associée](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/freezer-subsystem.html).
|
||||
[la documentation associée](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/freezer-subsystem.html) :\
|
||||
<https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/freezer-subsystem.html>
|
||||
|
||||
|
||||
### Changement d'état
|
||||
|
|
@ -216,7 +236,7 @@ for i in $(seq 9999); do echo -n $i; sleep .1; echo -n " - "; sleep .1; done
|
|||
```
|
||||
</div>
|
||||
|
||||
Maintenant, nous avons donné l'ordre au noyau de ne plus allouer de temps de
|
||||
Maintenant, nous alloner donné l'ordre au noyau de ne plus allouer de temps de
|
||||
calcul à notre shell et ses fils :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -241,8 +261,8 @@ echo 0 > /sys/fs/cgroup/virli/cgroup.freeze # v2
|
|||
|
||||
### Script de monitoring {- #script-monitoring}
|
||||
|
||||
À nous maintenant de concevoir un script qui va enregistrer vers une base de
|
||||
données des statistiques issues des *cgroup*s, tel `telegraf`.
|
||||
À nous maintenant de concevoir un script de collecte de statistiques issues des
|
||||
*cgroup*s, similaire à `telegraf`.
|
||||
|
||||
Dans un premier temps, commençons par afficher dans la console, la quantité de
|
||||
mémoire utilisée par le groupe monitoré.
|
||||
|
|
@ -297,6 +317,9 @@ activé par défaut par votre système. Si vous êtes dans ce cas, essayez
|
|||
d'ajouter `cgroup_enable=memory` à la ligne de commande de votre noyau.
|
||||
:::::
|
||||
|
||||
Gardez ce script dans un coin, nous allons le compléter dans les sections
|
||||
suivantes.
|
||||
|
||||
:::::
|
||||
|
||||
### Fixer des limites {#Fixer-des-limites}
|
||||
|
|
@ -306,8 +329,8 @@ quantité de ressources mises à disposition à un groupe de processus.
|
|||
|
||||
Pour définir une limite, nous allons écrire la valeur dans le fichier
|
||||
correspondant à une valeur limite, comme par exemple
|
||||
`memory.max_usage_in_bytes`/`memory.max`, qui limite le nombre d'octets que
|
||||
notre groupe de processus va pouvoir allouer au maximum :
|
||||
`memory.max_usage_in_bytes` (v1) ou `memory.max` (v2), qui limite le nombre
|
||||
d'octets que notre groupe de processus va pouvoir allouer au maximum :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -339,6 +362,8 @@ Chaque *cgroup*s définit de nombreux indicateurs et possède de nombreux
|
|||
limiteurs, n'hésitez pas à consulter la documentation associée à chaque
|
||||
*cgroup*.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Mettez à jour votre script de monitoring pour prendre en compte les
|
||||
limites que vous avez définies :
|
||||
|
||||
|
|
@ -358,6 +383,8 @@ limites que vous avez définies :
|
|||
```
|
||||
</div>
|
||||
|
||||
:::::
|
||||
|
||||
|
||||
### Pour aller plus loin {-}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue