Pierre-Olivier Mercier c4bb727cd4 2021 tuto

2021-09-11 14:41:48 +02:00

8.7 KiB

Raw Blame History

\newpage

Utiliser les cgroups

Les cgroups (pour Control Groups) permettent de collecter des statistiques sur des groupes de processus (appelés tâches) et de leur attribuer des propriétés. Par exemple, il est possible leur imposer des limites d'utilisation de ressources ou d'altérer leur comportement.

Premiers tests

Nous allons commencer par faire quelques tests avec le cgroup freezer, qui permet d'interrompre l'exécution d'un groupe de processus et de la reprendre.

Montage du cgroup

En fonction de la configuration de votre système, il est possible que les cgroups ne soient pas montés au démarrage dans /sys/fs/cgroup/. Si vous n'avez pas de dossier freezer ou si celui-ci est vide, montez-le en suivant la procédure suivante :

```bash mkdir /sys/fs/cgroup/freezer/ mount -t cgroup -o freezer none /sys/fs/cgroup/freezer/ ```

Cette dernière commande monte l'arborescence de groupes relative à ce cgroup freezer. Tous les dossiers contenus dans cette racine sont donc des sous-groupes.

Création d'un nouveau groupe

La première étape dans l'utilisation d'un cgroup est de créer un groupe.

Pour ce faire, il suffit de créer un nouveau dossier dans un groupe existant, par exemple la racine :

```bash mkdir /sys/fs/cgroup/freezer/virli/ ls /sys/fs/cgroup/freezer/virli/ ```

Nous avons maintenant un nouveau groupe de processus virli dans le cgroup Freezer. Comme il s'agit d'une hiérarchie, le groupe virli hérite des propriétés de son (ses) père(s).

Rattachement de processus

Pour le moment, ce nouveau groupe ne contient aucune tâche.

Ouvrons un nouveau terminal (c'est lui que l'on va geler), et récupérons son PID : echo $$.

La liste des processus rattachés à un cgroup se trouve dans le fichier task du groupe. Pour ajouter une tâche à ce groupe, cela se passe de cette manière :

```bash echo $PID > /sys/fs/cgroup/freezer/virli/tasks ```

Il faut ici remplacer $PID par le PID du shell que l'on a relevé juste avant.

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 cgroups).

Malgré l'utilisation de la redirection > (et non >>), il s'agit belle 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.

Consultation de l'état

En affichant le contenu du dossier virli, nous pouvions constater que celui-ci contenait déjà un certain nombre de fichiers. Certain d'entre-eux 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\newline /sys/fs/cgroup/freezer/virli/freezer.state.

Pour plus d'information sur les différents fichiers présents dans ce cgroup, consultez la documentation associée.

Changement d'état

Faisons exécuter à notre interpréteur une commande pour voir effectivement l'exécution s'arrêter. Si vous manquez d'inspiration, utilisez :

```bash for i in $(seq 9999); do echo -n $i; sleep .1; echo -n " - "; sleep .1; done ```

Maintenant, nous avons donné l'ordre au noyau de ne plus allouer de temps de calcul à notre shell et ses fils :

```bash echo FROZEN > /sys/fs/cgroup/freezer/virli/freezer.state ```

À cet instant, vous devriez voir votre compteur s'arrêter. Pour reprendre l'exécution :

```bash echo THAWED > /sys/fs/cgroup/freezer/virli/freezer.state ```

Exercice : script de monitoring

À nous maintenant de concevoir un script qui va enregistrer vers une base de données des statistiques issues des cgroups.

Rappel d'InfluxDB

Commençons par lancer le conteneur Docker d'InfluxDB (pour éviter de l'installer sur notre machine) :

```bash docker container run --name mytsdb -d -p 8086:8086 influxdb ```

Il nous faut ensuite créer une base de données pour y stocker nos métriques. Voici comment on s'était débrouillé dans un précédent TP pour interagir avec InfluxDB :

```bash docker container exec -i mytsdb influx <

Vérifiez que la base de données metrics a bien été créée.

Monitoring instantané vers la console

Dans un premier temps, commençons par afficher dans la console, la quantité de mémoire utilisée par le groupe monitoré.

Vous pouvez utiliser un programme comme memhog pour remplir rapidement votre mémoire.

``` 42sh# mkdir /sys/fs/cgroup... 42sh$ echo $$ | sudo tee /sys/fs/cgroup.../tasks 42sh# ./monitor group_name memhog 500 ~~~ 13595 ~~~ Current memory usage: 75194368/550502400 (13%) ~~~ 13595 ~~~ Current memory usage: 150290432/550502400 (27%) ~~~ 13595 ~~~ Current memory usage: 223690752/550502400 (40%) ~~~ 13595 ~~~ Current memory usage: 296828928/550502400 (53%) ~~~ 13595 ~~~ Current memory usage: 368001024/550502400 (66%) ~~~ 13595 ~~~ Current memory usage: 438517760/550502400 (79%) ~~~ 13595 ~~~ Current memory usage: 480329728/550502400 (87%) ~~~ 13595 ~~~ Current memory usage: 155648/550502400 (0%) ```

Si vous n'avez pas le cgroup memory, il est possible qu'il ne soit pas 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.

Monitoring vers InfluxDB

Maintenant, envoyons nos données vers la base https://docs.influxdata.com/influxdb/v1.6/guides/writing_data/ :

```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)" ```

Pour vérifier que les données ont bien été ajoutées, nous pouvons effectuer la requête suivante dans notre client influx :

```sql SELECT * from "$my_cgroup_name"; ```

Monitorer davantage de données

Liste non exhaustive de données à monitorer :

Nombre d'IOs effectué ;
nombre d'octets lu/écrit sur les disques ;
temps de calcul utilisé ;
trafic réseau généré ;
...

Tous les cgroups existants dans le dernier noyau publié ont leur documentation accessible ici : https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/index.html

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) cgroups et lui attribuer les bons droits, tandis que le deuxième va effectuer le monitoring, sans privilèges particuliers.

Exemple

``` 42sh$ sudo ./monitor_init my_cgroup_name 42sh$ ./monitor my_cgroup_name memhog 500 ```

Fixer des limites

Au delà de la simple consultation, les cgroups peuvent servir à limiter la quantité de ressources mise à 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, qui limite le nombre d'octets que notre groupe de processus va pouvoir allouer au maximum :

``` 42sh$ cat /sys/fs/cgroup/memory/virli/memory.max_usage_in_bytes 0 # 0 = Aucune limite 42sh$ echo 4M > /sys/fs/cgroup/memory/virli/memory.max_usage_in_bytes # Maintenant, la limite est à 4MB, vérifions... 42sh$ cat /sys/fs/cgroup/memory/virli/memory.max_usage_in_bytes 4194304 ```

Chaque cgroups défini de nombreux indicateurs et possède de nombreux limiteurs, n'hésitez pas à consulter la documentation associée à chaque cgroup.

Pour aller plus loin {-}

Pour tout connaître en détails, la série d'articles de Neil Brown sur les Control groups est excellente !

Depuis les noyaux 4.5, il est possible d'utiliser la nouvelle version du pseudo système de fichiers des CGroups. Le principal changement vient du regroupement au sein d'une seule hiérarchie des différents CGroups que l'on avait dans la v1. Davantage d'informations sont disponibles :

8.7 KiB Raw Blame History