teach/virli
1
0
Fork 0
Code Issues Pull Requests Releases Activity
6665cfbace
virli/tutorial/3/cgroups-influx.md

2.6 KiB
Raw Blame History

::::: {.exercice}

Exercice (obligatoire pour les SRS -- optionnel pour les GISTRE) {-}

Poursuivons notre script de monitoring afin d'envoyer nos résultats vers InfluxDB : nous l'appellerons ./telegraf.sh.

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:1.8 ```

::::: {.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 :

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

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

Monitoring vers InfluxDB

Maintenant, envoyons nos données vers la base https://docs.influxdata.com/influxdb/v1.8/guides/write_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é ;
  • nobre d'octets lus/écrits sur les disques ;
  • temps de calcul utilisé (userspace, system, tout confondu) ;
  • ...

Tous les cgroups existants dans le dernier noyau publié ont leur documentation accessible ici :

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 (chown $EUID), tandis que le deuxième va effectuer le monitoring, sans privilèges particuliers.

Exemple {-}

``` 42sh$ sudo ./telegraf_init.sh my_cgroup_name 42sh$ ./telegraf.sh my_cgroup_name memhog 500 ```

:::::