InfluxDB, Grafana et Glances, le monitoring qui brille

GNU/Linux Magazine n° 209 | novembre 2017 | Denis Gourmel
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
Dans l’article qui va suivre, je vais vous guider, si vous l’acceptez, dans la mise en place d’un système de monitoring peu conventionnel. En nous basant sur des programmes très spécifiques, mais complémentaires, nous allons créer un outil capable de surveiller vos serveurs tout en affichant vos données dans une interface digne du XXIème siècle.

Le monde du monitoring est sûrement plus stable que les services et produits qui sont eux-mêmes « monitorés ». C'est pourquoi j'ai eu envie de voir ce que l'on pouvait faire à ce niveau-là avec les technologies d'aujourd'hui… Force est de constater que je ne m'attendais pas à un tel résultat.

Allons-y, je vais vous conter mes péripéties.

1. Préparation des paquetages avant l'ascension

Plutôt que d'utiliser une solution de monitoring « tout-en-un », je préfère une fois de plus construire mon système grâce à différentes briques que je juge complémentaires. Ma distribution serveur du moment étant Ubuntu, cet article se base sur la dernière version « LTS » (soit Ubuntu 16.04). Cependant, vu que nous allons utiliser Docker, la distribution de l'OS n'aura au final que très peu d'importance.

1.1 Installation de Docker

J’espère que vous êtes bien harnachés, car c’est parti.

Nous allons installer Docker « Community Edition » avec la dernière méthode en date.

Tout d’abord les « prérequis » :

$ sudo apt-get install -y apt-transport-https software-properties-common  ca-certificates curl

Ajoutons ensuite le dépôt adéquat :

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

$ sudo add-apt-repository  "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

Il faut désormais mettre à jour la liste de nos dépôts afin de prendre en compte l’ajout :

$ sudo apt-get update

Et enfin, nous pouvons installer la dernière version de Docker ainsi que docker-compose que nous utiliserons pour gérer nos containers :

$ sudo apt-get -y install docker-ce docker-compose

L’étape suivante n’est pas obligatoire, mais j’aime bien configurer mes installations de Docker de la sorte. Il s’agit simplement d’ajouter son utilisateur au groupe docker afin de pouvoir lancer Docker sans passer « sudo » :

$ sudo usermod -aG docker MonUser

Note

Afin de prendre en compte les changements, vous devrez vous déconnecter / reconnecter.

1.2 Configuration du réseau Docker

Dans la partie qui va suivre, nous allons voir comment créer un réseau « dédié » à nos containers de monitoring. Pour une fois, nous allons pouvoir ajouter une couche de sécurité tout en ajoutant aussi une couche de praticité. Qui a dit qu’il fallait choisir entre sécurité et praticité ?

En effet, par défaut Docker crée ses containers avec des IP dynamiques et les changent à chaque redémarrage des containers.

Nous ajoutons donc le côté pratique d’avoir une IP fixe et un nom d’hôte pour chaque container tout en isolant les containers du réseau principal. Cette isolation va permettre à nos containers d’ouvrir des ports uniquement visibles par eux-mêmes et non pas par le reste du monde.

$ docker network create --driver bridge br0

Vérifions que notre nouveau réseau est disponible avec la commande suivante :

$ docker network ls

NETWORK ID          NAME                DRIVER              SCOPE

f5fa89b94de4        br0                 bridge              local

193d033921f1        bridge              bridge              local

49e3217679f9        host                host                local

d7e622968ebb        none                null                local

Et… voilà, c’est tout ! Docker est installé et fonctionnel, voilà le premier palier franchi.

2. Récupération et lancement des images

Attaquons-nous au palier suivant, mais n’ayez crainte, l’ascension n’en sera pas pour autant plus compliquée. En cas de chute, je suis là et je tiens la corde.

J’ai pour habitude de placer mes images Docker dans un répertoire dédié :

$ sudo mkdir -p /srv/data/apps/{glances,influxdb,grafana,nginx}

$ chown -R MonUser: /srv/data

2.1 InfluxDB

À partir du bon répertoire, construisons un fichier /srv/data/apps/influxdb/docker-compose.yml :

# docker-compose for influxDB

version: '2'

services:

  influxdb:

    image: influxdb

    container_name: influxdb

    ports:

#      - "8083:8083"

      - "8086:8086"

      - "2003:2003"

    volumes:

      - influxdb-storage:/var/lib/influxdb

    environment:

      - INFLUXDB_GRAPHITE_ENABLED=true

    restart: always

    networks:

      default:

        aliases:

          - influxdb

networks:

  default:

    external:

      name: br0

volumes:

  influxdb-storage:

Nous pouvons désormais lancer notre premier container. Vu qu’il s’agit du premier lancement, la dernière image en date d'InfluxDB sera aussi téléchargée :

$ docker-compose up -d

Afin de vérifier que tout est en ordre, nous pouvons exécuter la commande suivante :

$ docker ps

CONTAINER ID        IMAGE                         COMMAND                  CREATED             STATUS              PORTS                              NAMES

01c53fe77784        influxdb                      "/entrypoint.sh in..."   20 minutes ago      Up 20 minutes       0.0.0.0:2003->2003/tcp, 8086/tcp   influxdb

Vous constaterez que le statut du container nommé influxdb indique Up : cela veut dire que tout fonctionne.

Ensuite, nous devons créer une base de données au sein d’InfluxDB afin d’y stocker les statistiques venant de Glances. La première étape consiste à entrer dans le container d’InfluxDB :

$ docker exec -it influxdb bash

Une fois dans le container, connectons-nous à InfluxDB :

$ influx

La dernière étape consiste à créer la base, l’utilisateur, et lui donner les droits :

Connected to http://localhost:8086 version 1.2.2

InfluxDB shell version: 1.2.2

> create database glances

> create user "glances" with password 'MyPass'

> grant all on "glances" to "glances"

> exit

Note

Pour quitter le container et revenir à notre hôte, un simple <Ctrl> + <d> suffit.

Attaquons-nous désormais à la collecte des statistiques avec Glances [1].

2.2 Glances

Même procédure que précédemment ; nous nous plaçons dans le bon répertoire et créons notre fichier de configuration principal /srv/data/apps/glances/docker-compose.yml :

# docker-compose for Glances

version: '2'

services:

  glances:

    image: docker.io/nicolargo/glances

    container_name: glances

    volumes:

      - /var/run/docker.sock:/var/run/docker.sock:ro

      - ./conf/glances.conf:/glances/conf/glances.conf

      - ./scripts:/scripts

  #    - /home/MonUser/fake:/srv/fake

    environment:

      - GLANCES_OPT=-q --export-influxdb

    pid: "host"

    restart: always

    networks:

      default:

        aliases:

          - glances

networks:

  default:

    external:

      name: br0

Note

En fonction de votre partitionnement, il se peut que le container de Glances ne voit pas toutes vos partitions. Dans ce cas, je vous recommande de créer un dossier « bidon » sur les partitions en question et de le monter via le fichier docker-compose.yml (cf. le dossier /srv/fake dans ma config).

Ensuite, nous allons créer les dossiers, fichiers de configuration et points de montage nécessaires au lancement de Glances en nous basant sur le fichier que nous venons de créer :

$ mkdir {conf,scripts}

Pour ce qui est de la configuration de Glances, elle se trouve dans /srv/data/apps/glances/conf/glances.conf. Je vous présente uniquement les parties les plus « intéressantes », le reste étant les valeurs par défaut. De plus, vous trouverez tous mes fichiers de configuration sur mon GitHub [2].

[load]

careful=0.7

warning=1.0

critical=5.0

critical_action=sh /scripts/send_sms.sh "Load:: `uptime`"

[mem]

careful=50

warning=70

ceitical=90

critical_action=sh /scripts/send_sms.sh "Free mem: `free -m | grep Mem | awk '{print $4}'`"

[fs]

careful=50

warning=70

critical=90

critical_action=sh /scripts/send_sms.sh "Disk: `df -h | grep md | grep 9[0-9]`"

[influxdb]

host=influxdb

port=8086

user=glances

password=MyPass

db=glances

prefix=ubunmonit

[amp_nginx]

enable=true

regex=nginx

refresh=60

one_line=false

status_url=http://nginx/nginx_status

Comme nous pouvons le voir dans la config ci-dessus, j’utilise un script « maison » pour envoyer des alertes par SMS lorsqu’un seuil critique est atteint. Voici le script scripts/send_sms.sh en question :

#!/bin/bash

curl -k "https://smsapi.free-mobile.fr/sendmsg?user=MonUser&pass=MyPass&msg=Ubunmonit - $1"

N’oubliez pas de rendre votre script exécutable :

$ chmod +x scripts/send_sms.sh

Note

Ce script permet d’envoyer des SMS via l’API Free mobile [3]. Dans le cas où vous n’utiliseriez pas Free, il existe des méthodes similaires (ou basées sur l’envoi de mails) chez les autres opérateurs, voire chez des prestataires externes.

Construisons notre container :

$ docker-compose up -d

Encore une fois, nous pouvons vérifier que tout fonctionne avec docker ps. En cas d’erreur, pour « débugger » , nous pouvons utiliser la commande docker logs -f glances, ou encore docker exec -it glances bash (si le container est Up) pour aller « fouiller » dans le container.

Admettons que tout fonctionne, et allons voir dans notre base InfluxDB si nous avons récolté des données :

$ docker exec -it influxdb bash

root@01c53fe77784:/# influx

Connected to http://localhost:8086 version 1.2.2

InfluxDB shell version: 1.2.2

> show databases

name: databases

name

----

_internal

glances

> use glances

Using database glances

> show measurements

name: measurements

name

----

ubunmonit.cpu

ubunmonit.diskio

ubunmonit.docker

ubunmonit.fs

ubunmonit.ip

ubunmonit.load

ubunmonit.mem

ubunmonit.memswap

ubunmonit.network

ubunmonit.percpu

ubunmonit.processcount

ubunmonit.sensors

ubunmonit.uptime

Parfait ! Glances communique avec InfluxDB et la base commence à stocker nos différentes statistiques.

J’ai beau adorer mon terminal, quand il s’agit de statistiques je préfère quand même avoir des graphiques et une représentation plus « visuelle ». Ça tombe bien, c’est exactement le rôle de Grafana.

2.3 Grafana

Pour ne pas déroger à la règle,  nous allons créer le fichier suivant /srv/data/apps/grafana/docker-compose.yml :

# docker-compose for Grafana

version: '2'

services:

  grafana:

    image: grafana/grafana

    container_name: grafana

#    ports:

#      - "3000:3000"

    volumes:

      - grafana-storage:/var/lib/grafana

    environment:

      - GF_SECURITY_ADMIN_PASSWORD=An0th3rP4ss

    restart: always

    networks:

      default:

        aliases:

          - grafana

networks:

  default:

    external:

      name: br0

volumes:

  grafana-storage:

Et nous lançons le container :

$ docker-compose up -d

Comme vous pouvez le remarquer, j’ai décidé de ne pas « exposer » le port 3000. C’est-à-dire qu’à l’heure actuelle, notre interface graphique n’est pas visible depuis l’extérieur de notre serveur.

Vérifions :

$ netstat -tulpn

(Not all processes could be identified, non-owned process info

 will not be shown, you would have to be root to see it all.)

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -

tcp6       0      0 :::2003                 :::*                    LISTEN      -

tcp6       0      0 :::22                   :::*                    LISTEN      -

udp        0      0 0.0.0.0:68              0.0.0.0:*                           -

Effectivement, seuls SSH (22/tcp), DHCP (68/udp) et 2003/tcp sont visibles depuis l’extérieur. Pour ce qui est du port 2003/tcp, il provient du container InfluxDB et correspond à une base Graphite dans laquelle je stocke les informations provenant de mon NAS (nous verrons cela plus tard).

Un simple docker ps nous confirme tout de même que le port 3000 (par exemple) est utilisé :

$ docker ps

CONTAINER ID        IMAGE                         COMMAND                  CREATED             STATUS              PORTS                              NAMES

6a061326eb47        grafana/grafana               "/run.sh"                6 minutes ago       Up 6 minutes        3000/tcp                           grafana

01c53fe77784        influxdb                      "/entrypoint.sh in..."   32 minutes ago      Up 32 minutes       0.0.0.0:2003->2003/tcp, 8086/tcp   influxdb

93e983755929        docker.io/nicolargo/glances   "/bin/sh -c 'pytho..."   43 minutes ago      Up 21 minutes       61208-61209/tcp                    glances

Mais comment allons-nous y accéder ? La réponse à cette question après la pu… ou plutôt après un petit bonus : récupérer les stats de FreeNAS.

2.4 Bonus : FreeNAS

J’utilise un NAS « maison » basé sur FreeNAS. Ce dernier propose d’envoyer ses statistiques vers une « base de données » Graphite.

Côté FreeNAS 9.x, il faut aller dans System > Advanced, et renseigner l’adresse de votre serveur InfluxDB dans la partie Remote Graphite Server Hostname.

Côté InfluxDB, la configuration est faite via le fichier docker-compose.yml que nous avons utilisé. Voilà, c’est tout ! En admettant qu’il n’y ait pas de pare-feu entre votre NAS et le serveur qui fait tourner votre container InfluxDB, cela fonctionnera.

Il est grand temps d’afficher tout ce que nous sommes en train de collecter. Pour ce faire, nous allons utiliser un reverse proxy NGiNX avec des certificats « SSL » (notez les guillemets).

3. Consultation des stats via un reverse proxy

Troisième et avant-dernier palier. Le sommet est en vue, mais l’oxygène se raréfie. Essayons tout de même de rester concentrés.

3.1 Du httpS pour tous !

Tout d’abord, un grand merci à toute l’équipe de Let’s Encrypt [4]. Grâce à leur projet, nous pouvons désormais utiliser des certificats « SSL » facilement et gratuitement. Il n’y a donc aucune raison de s’en passer. Installons le paquetage certbot pour gérer nos certificats :

$ sudo add-apt-repository ppa:certbot/certbot

$ sudo apt-get update

$ sudo apt-get install -y letsencrypt

Ensuite, nous générons le certificat pour notre virtual host Grafana. J’utilise un sous-domaine du genre grafana.monserveur.com :

$ sudo letsencrypt certonly --standalone -d grafana.monserveur.com

Note

Afin que Let’s Encrypt puisse vous attribuer un certificat, il faut que votre sous-domaine soit valide. C’est-à-dire qu’un enregistrement DNS doit exister et pointer vers l’IP de votre serveur.

Répondez aux questions et voilà, si tout s’est passé comme prévu, vous trouverez vos certificats et clefs dans :

$ sudo ls -l /etc/letsencrypt/

total 24

drwx------  4 root root 4096 Oct 27 07:31 accounts

drwx------ 14 root root 4096 Nov 28 05:37 archive

drwxr-xr-x  2 root root 4096 Apr 22 02:50 csr

drwx------  2 root root 4096 Apr 22 02:50 keys

drwx------ 14 root root 4096 Nov 28 05:37 live

drwxr-xr-x  2 root root 4096 Apr 22 02:50 renewal

Le seul « inconvénient » avec Let’s Encrypt, c’est que les certificats ne sont valables que trois mois. Il est donc nécessaire de mettre en place un renouvellement automatique. C’est que nous allons faire avec systemd (oui, oui, l’horrible systemd).

Il faut tout d’abord créer un service /etc/systemd/system/renew-letsencrypt.service :

[Unit]

Description=Renew Let's Encrypt certificates

[Service]

Type=oneshot

# check for renewal, only start/stop nginx if certs need to be renewed

ExecStart=/usr/bin/letsencrypt renew --agree-tos --pre-hook "/usr/bin/docker stop nginx" --post-hook "/usr/bin/docker start nginx"

Ensuite un timer /etc/systemd/system/renew-letsencrypt.timer :

[Unit]

Description=Daily renewal of Let's Encrypt's certificates

[Timer]

# once a day, at 2AM

OnCalendar=*-*-* 02:00:00

# Be kind to the Let's Encrypt servers: add a random delay of 3600 seconds

RandomizedDelaySec=3600

Persistent=true

[Install]

WantedBy=timers.target

Indiquons à systemd que nous venons d’ajouter un service :

$ sudo systemctl daemon-reload

Ensuite, démarrons le service :

$ sudo systemctl start renew-letsencrypt.timer

Et si tout se passe bien, alors activons ce service pour qu’il se lance automatiquement à chaque démarrage du serveur :

$ sudo systemctl enable renew-letsencrypt.timer

Vous pouvez vérifier que votre timer a bien été pris en compte avec la commande suivante :

$ sudo systemctl list-timers

NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES

Thu 2017-04-27 07:49:57 PDT  1h 17min left Thu 2017-04-27 01:01:20 PDT  5h 30min ago apt-daily.timer              apt-daily.service

Thu 2017-04-27 12:06:28 PDT  5h 34min left Thu 2017-04-27 00:48:40 PDT  5h 43min ago certbot.timer certbot.service

Fri 2017-04-28 02:29:20 PDT  19h left      Thu 2017-04-27 02:29:20 PDT  4h 2min ago  systemd-tmpfiles-clean.timer systemd-tmpfiles-clean

3 timers listed.

3.2 Mise en place du reverse proxy

Encore une fois, et cette fois-ci, promis, c’est la dernière : nous allons créer un nouveau fichier docker-compose.ymldans /srv/data/apps/nginx qui ressemblera à cela :

# docker-compose for Nginx

version: '2'

services:

  nginx:

    image: nginx

    container_name: nginx

    ports:

      - "443:443"

      - "80:80"

    volumes:

      - ./conf.d:/etc/nginx/conf.d

      - /etc/letsencrypt:/etc/nginx/ssl

      - /srv/data/ssl/dhparam.pem:/etc/nginx/cert/dhparam.pem

    #environment:

    restart: always

    networks:

      default:

        aliases:

          - nginx

networks:

  default:

    external:

      name: br0

Les configurations de nos virtual hosts résident dans un dossier dédié :

$ mkdir -p /srv/data/apps/nginx/conf.d/vhost

Préparons la voie pour la config « SSL » :

$ mkdir /srv/data/ssl

$ cd /srv/data/ssl/ && openssl dhparam -out dhparam.pem 4096

Commençons par créer un vhost pour obtenir le statut de NGiNX lui-même afin que Glances puisse collecter des statistiques sur son usage (fichier /srv/data/apps/nginx/conf.d/vhost/status.conf) :

server {

    listen   80;

location /nginx_status {

        stub_status on;

        access_log   off;

        allow 172.0.0.0/8;

        deny all;

   }

}

Ensuite le vhost pour Grafana (fichier grafana.conf dans le même répertoire) :

server {

       listen         80;

       server_name    grafana.monserveur.com;

       return         301 https://$server_name$request_uri;

}

server {

    listen 443 ssl;

    ssl_certificate /etc/nginx/ssl/live/grafana.monserveur.com/fullchain.pem;

    ssl_certificate_key /etc/nginx/ssl/live/grafana.monserveur.com/privkey.pem;

    ssl_dhparam /etc/nginx/cert/dhparam.pem;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_prefer_server_ciphers on;

    ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    server_name  grafana.monserveur.com;

    access_log on;

    location / {

        proxy_pass      http://grafana:3000;

        proxy_set_header    Host            $host;

        proxy_set_header    X-Real-IP       $remote_addr;

        proxy_set_header    X-Forwarded-for $remote_addr;

        port_in_redirect off;

        proxy_connect_timeout 300;

    }

    error_page   500 502 503 504  /50x.html;

    location = /50x.html {

        root   /usr/local/nginx/html;

    }

}

Note

Notez bien les valeurs ssl_certificate et ssl_certificate_key qui pointent vers votre dossier Let’s Encrypt qui a été monté dans le container via le fichier docker-compose.yml.

N’oublions pas de créer des liens symboliques depuis le dossier conf.d vers le dossier contenant nos vhosts. De la sorte, il sera plus facile d’ajouter/supprimer des vhosts à notre serveur web :

$ cd /srv/data/apps/nginx/conf.d

$ ln -s vhost/status.conf status.conf

$ ln -s vhost/grafana.conf grafana.conf

Et on démarre notre container :

$ cd /srv/data/apps/nginx

$ docker-compose up -d

L’heure de vérité a sonné, essayons de nous connecter à Grafana !

4. Visualisation des stats dans Grafana

Ouvrez votre navigateur et rendez-vous sur : https://grafana.monserveur.com ! Le login par défaut est admin, et le mot de passe An0th3rP4ss (ou celui que vous avez entré dans le fichier docker-compose.yml correspondant à Grafana).

Cerise sur le gâteau, votre site passe parfaitement le test du certificat « SSL », et vous obtenez la meilleure note possible, A+ ! [5]

4.1 Ajout des sources

La toute première chose à faire  (sans parler de changer le mot de passe et/ou créer des utilisateurs) consiste à définir vos « Data sources ». Pour ce faire, il faut cliquer dans le coin supérieur gauche sur le logo > Data Sources > Add data source.

La première source que nous allons ajouter sera Glances. Nommez donc la source comme bon vous semble puis sélectionnez InfluxDB comme type. Pour l’URL, il s’agit de http://influxdb:8086, l’access sur proxy, et enfin les informations concernant la base, à savoir glances comme nom de base et d’utilisateur et le mot de passe défini dans la section influxdb.

Si vous utilisez FreeNAS, répétez la même opération avec les informations adéquates.

4.2 Aperçu des possibilités

Il serait trop long d’expliquer Grafana en détail, je vais donc simplement donner un aperçu du fonctionnement ainsi que de ses possibilités.

Tout d’abord, Grafana fonctionne par dashboard (tableau de bord dans notre langue). J’utilise par exemple un tableau de bord par périphérique. Pour illustrer cet article, nous aurions donc un tableau de bord pour notre serveur surveillé via Glances et un second pour notre NAS.

Au sein de chaque tableau de bord, vous allez pouvoir ajouter le suivi de différentes statistiques. Admettons que vous vouliez voir l’usage de la mémoire au fil du temps, alors vous allez probablement utiliser un graphe. Par contre, si vous voulez obtenir le nombre de processus à un instant t, alors vous préfèrerez probablement avoir une simple valeur en évidence sur votre tableau de bord. Ces différents éléments sont appelés des panels (panneaux en français, même si cela ne sonne pas très bien). Il existe tout un tas de panneaux, comme des tableaux, des listes, des cartes du monde, des camemberts, etc.

Ces panneaux ainsi que les tableaux de bord peuvent être téléchargés via le site officiel et sont produits par la « communauté ».

4.3 Gestion des dashboards

Venons-en donc aux fameux tableaux de bord. Il s’agit d’un ensemble de panneaux qui forment un tout plus ou moins cohérent.

Pour vous donner un exemple, le tableau de bord correspondant à mon serveur me donne :

- des graphes d’utilisation CPU/mémoire/disque/ressources par containers ;

- un instantané du nombre de processus/espace disque, etc.

Ces tableaux de bord peuvent être facilement importés/exportés sous forme de fichier .json.

Note

Vous remarquez que la « data source » est souvent indiquée directement dans le fichier .json, ainsi que le nom des interfaces réseaux par exemple. Pensez donc à modifier ce fichier avant de l’importer afin de ne pas avoir à le faire graphiquement (ce qui sera plus contraignant).

Conclusion

Félicitations, nous voici arrivés au sommet, et en un seul morceau !

Durant notre ascension, nous avons vu comment tirer profit de technologies assez diverses et récentes pour construire un système de monitoring sur mesure. Je ne prétends pas que ce système est parfait, ni même viable en production. Je l’utilise uniquement sur un serveur personnel et j’ai mis en place cette solution dans le but de me familiariser avec ces technologies. Ayant trouvé l’expérience intéressante, j’ai décidé de la partager avec vous.

Les possibilités sont nombreuses. Il est par exemple possible de surveiller des appareils envoyant des données via SNMP (comme pfSense par exemple, ou des APs Cisco).

Malheureusement, mettre au point un tel système prend un temps certain. On ne parle clairement pas d’une solution « clef en main » comme du Zabbix. C’est de la « bidouille », mais c’est aussi pour cela qu’on aime le faire, n’est-ce pas ?

Pour aller encore plus haut...

Comme je le disais précédemment, ce système est très modulaire et les possibilités sont nombreuses, tout comme les améliorations. Vous avez peut-être retenu que nous avions utilisé un léger « hack » avec des points de montage bidons dans le container de Glances pour afficher les partitions manquantes. Il reste cependant un problème avec Glances dans un container, c’est qu’il ne voit pas l’interface réseau physique de notre serveur ! Impossible donc de surveiller en l’état cette interface.

De plus, aucun de nos containers n'est capable (tels qu’ils sont configurés) d’envoyer des e-mails, cela peut poser problème pour envoyer un message de création de compte et/ou oubli de mot de passe depuis Grafana par exemple…

Comme souvent dans ce domaine, le travail n’est jamais fini… et  il y aura encore de la place pour améliorer et optimiser au fur et à mesure des installations et/ou des nouveaux outils disponibles.

Références

[1] Site officiel de Glances par nicolargo : https://nicolargo.github.io/glances/

[2] Les différents fichiers de configuration sur GitHub : https://github.com/Nesousx/glaraflux

[3] Fonctionnement de l’API SMS Free : http://www.universfreebox.com/article/26337/Nouveau-Free-Mobile-lance-un-systeme-de-notification-SMS-pour-vos-appareils-connectes

[4] Let’s Encrypt - le httpS pour tous : https://letsencrypt.org/

[5] Testez votre certificat « SSL » :  https://www.ssllabs.com/ssltest/