Work on tuto 3

This commit is contained in:
nemunaire 2016-10-05 22:49:08 +02:00
commit b459443d9e
9 changed files with 322 additions and 653 deletions

View file

@ -14,11 +14,12 @@ de ressources ou altérer leurs priorités.
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
*cgroup*s 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, monter-le en suivant la
pas de dossier `freezer` ou si celui-ci est vide, montez-le en suivant la
procédure suivante :
```
@ -27,8 +28,9 @@ mount -t cgroup -o freezer none /sys/fs/cgroup/freezer/
```
Cette dernière commande monte le groupe de processus racine, pour le *cgroup*
freezer. Tous les dossiers contenu dans cette racine sont des sous-groupes de
cette dernière.
freezer. Tous les dossiers contenu dans cette racine sont donc des
sous-groupes.
### Création d'un nouveau groupe
@ -47,6 +49,7 @@ Vous avez 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.
@ -64,22 +67,24 @@ 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, vous avez déplacé le processus dans ce groupe, il
n'est alors plus dans aucun autre groupe (dans ce *cgroup*, il ne bouge pas
n'est alors plus dans aucun autre groupe (pour ce *cgroup*, il ne bouge pas
dans les autres *cgroup*s).
### Consultation de l'état
En affichant le contenu du dossier `virli`, nous avons pu 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 vous pouvez modifier.
En affichant le contenu du dossier `virli`, nous pouvons 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 vous pouvez 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*,
consulter la documentation, accessible ici :
<https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt>
consulter
[la documentation associée](https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt).
### Changement d'état
@ -105,11 +110,28 @@ echo THAWED > /sys/fs/cgroup/freezer/virli/freezer.state
```
## Script de monitoring
## Exercice : script de monitoring
À nous maintenant de concevoir un script qui va enregistrer vers une base de
données des statistiques issues des *cgroup*s.
### Rappel d'InfluxDB
Commençons par lancer le conteneur Docker d'InfluxDB (pour éviter de
l'installer sur notre machine) :
```shell
docker run -d -p 8086:8086 -p 8083:8083 influxdb
```
Il nous faut ensuite créer une base de données pour y stocker les métriques,
rendez-vous à <http://localhost:8083/> puis entrez la requête :
```sql
CREATE DATABASE metrics;
```
À nous maintenant de concevoir un script qui va enregistrer vers la base de
données créée (*metrics*) dans la partie précédente, des statistiques issues
des *cgroup*s.
### Monitoring instantané vers la console
@ -125,30 +147,29 @@ mémoire utilisée par le groupe monitoré.
Vous pouvez utiliser un programme comme `memhog` pour remplir rapidement votre
mémoire.
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
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.
```
cgroup_enable=memory
```
### Monitoring vers InfluxDB
Maintenant, envoyons nos données vers la base
<https://influxdb.com/docs/v0.9/guides/writing_data.html> :
<https://docs.influxdata.com/influxdb/v1.0/guides/writing_data/> :
```
curl -i -XPOST 'http://172.23.42.2:8086/write?db=metrics' --data-binary \
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 sont bien ajoutées, vous pouvez effectuez la
Pour vérifier que les données ont bien été ajoutées, vous pouvez effectuez la
requête suivante dans l'interface web d'InfluxDB :
```
SELECT * from "$my_cgroup_name";
```
### Monitorer davantage de données
Liste non exhaustive de données à monitorer :
@ -159,7 +180,8 @@ Liste non exhaustive de données à monitorer :
* trafic réseau généré ;
* ...
<https://www.kernel.org/doc/Documentation/cgroups/>
<https://www.kernel.org/doc/Documentation/cgroup-v1/>
### Permettre à l'utilisateur de monitorer des process
@ -172,7 +194,7 @@ bons droits, tandis que le deuxième va utiliser effectuer le monitoring, sans
#### Exemple
```
42sh# ./monitor_init my_cgroup_name
42sh$ sudo ./monitor_init my_cgroup_name
42sh$ ./monitor my_cgroup_name memhog 500
```
@ -181,8 +203,7 @@ bons droits, tandis que le deuxième va utiliser effectuer le monitoring, sans
### Script de monitoring
Rendez la révision la plus avancée de vos scripts de monitoring de process via
les *cgroup*s.
Rendez la révision la plus avancée de vos scripts de monitoring de processus.
### Questions
@ -194,3 +215,19 @@ les *cgroup*s.
1. Actuellement, comment peut-on limiter le nombre de processus lancés par un
utilisateur ou un groupe ?
## Pour aller plus loin
Depuis les noyaux 4.5, il est possible d'utiliser la nouvelle version du
pseudo système de fichiers des *CGroup*s. Le principal changement vient du
regroupement au sein d'une seule hiérarchie des différents *CGroup*s que l'on
avait dans la v1. Davantage d'informations sont disponibles :
* [https://lwn.net/Articles/679786/](Understanding the new control groups API)
;
* [https://www.kernel.org/doc/Documentation/cgroup-v2.txt](Kernel Document
about Control Group v2).
Pour tout connaître en détails, [la série d'articles de Neil Brown sur les
Control groups](https://lwn.net/Articles/604609/) est excellente !