Check_MK - Solution de monitoring

Durant la TX n°5681, une solution de monitoring de l’infrastructure de Picasoft (Serveurs physiques et VMs) a été mise en place. La solution choisie pour répondre à ce besoin est CheckMK, qui sera présentée par la suite. Mais avant tout, cette page est dédiée à comprendre plus précisément ce que signifie le terme “monitoring”, à quoi sert-il et pourquoi cette solution plutôt qu’une autre.

Le monitoring, ou supervision est un terme englobant qui réponds à plusieurs objectifs :

• La récupération de métriques : un service central est chargé de la collecte de métriques auprès des différents hôtes. Une métrique représentant une donnée caractéristique de son système, comme par exemple, la charge CPU, la quantité de RAM. Celle-ci est généralement numérique, mais peut aussi prendre la forme d’un booléen , ou d’une chaîne de caractère ayant un sens plus large.
• Le stockage de métriques : les données sont stockées de manière à pouvoir être exploitables, notamment d’un point de vue temporel.
• La visualisation de métriques : l’exploitation des données, notamment sous la forme de graphe, permettent d’anticiper l’état du système (ex: une augmentation constante de la RAM ou de l’espace disque occupé), ou comprendre l’exploitation qui est faite (ex: une forte consommation de la bande passante à des heures précises) le tout dans l’objectif de pouvoir améliorer ou corriger le système.
• La gestion des alertes : La mise en place de valeurs seuils sur les métriques permet de définir des alertes au responsable technique, le tout sans que celui-ci ait besoin de les consulter régulièrement.
  

Le monitoring réponds donc à des besoins de maintenance d’un système d’information. En l’occurrence, il a été souhaité dans le cadre de la TX de superviser l’état des machines et VMs, il s’agit donc de supervision système. Cependant, il faut garder à l’esprit que cette pratique s’effectue aussi sur des équipements réseaux (routeurs, switchs,…), on parle alors de supervision réseau.

De nombreuses solutions de monitoring existent, dont beaucoup sont libres. La démarche de recherche d’une solution dans le cadre de la TX ne s’est pas basé sur une approche comparative, car très coûteuse en temps. Le problème a été pris dans l’autre sens : il s’agissait, parmi les solutions les plus connues, d’en choisir une répondant à nos besoins. Parmi ces solutions, plusieurs ont été retenues :

• Nagios est un “core”, c’est à dire qu’il ne possède pas à la base d’interface graphique. Il existe néanmoins de nombreux front-ends, dont des clients lourds et des interfaces Web. De plus, Nagios dispose d’une grande communauté de développeurs, et de nombreux plugins existent. Cependant sa mise en place est relative complexe.
• Zabbix est une solution de monitoring complète, donc plus rapide à mettre en place que Nagios. Elle dispose d’une interface web (qui ne s’avère pas vraiment intuitive) et se base sur le principe de template définissant les services à monitorer pour chaque type d’hôte (serveurs, équipements réseaux,…). Des agents doivent être installés sur les équipement afin de récupérer les données, malheureusement ceux-ci envoient constamment des données au serveur, ce qui s’avère consommateur en ressource. Autres points négatifs à prendre en compte, le paramètrage (qui est stocké en base de donnée) se fait principalement via une interface web et non via des fichiers de configuration; les métriques sont stockés en base de donnée MySQL ce qui induit des problèmes de performance à terme. D’autre part, il s’agit encore d’une solution jeune, donc moins robuste et exempte de bugs que Nagios, et dont la communauté s’amenuise.
• Check_MK est une solution en plein essor (la popularité est grandissante, et la solution connaît un succès certain), basé sur le core Nagios. Elle a les avantages de disposer d’une interface relativement intuitive (bien que très complête), d’avoir des agents passifs (ils sont appelés par le serveur) réduisant la consommation de ressource et de bande passante, et utilise de nombreux plugins Nagios éprouvés. De plus le stockage de métriques est basé sur RRD (Round Robin Database) tool, utilisant un buffer circulaire pour limiter la quantité de données. Enfin l’installation se limite à un seul paquet, fournissant ainsi une solution très rapide à déployer.

Le déploiement de Check_MK est simple et se découpe en deux parties :

• D’une part, il s’agit de mettre en place le serveur de monitoring. Il s’occupe :
  • d’aggréger les données
  • de mettre en place une interface Web permettant :
    • le paramétrage des services à monitorer sur chaque système
    • la visualisation des métriques sous forme de valeurs (en quasi-temps réel) et de graphes
    • la mise en place de systèmes d’alerte
    • la configurations de nombreuses autres options et fonctionnalités.
• D’autre part, il faut installer les agents sur chaque machine. Ceux-ci seront appelées par le serveur de monitoring, dans notre cas via une connexion SSH qui exécute automatiquement l’agent.

Une image Docker de Check_MK a été réalisée par Kyâne afin de s’intégrer facilement dans l’architecture de Picasoft. Celle-ci est disponible sur le Gitlab de Picasoft.

Pour construire l’image, il faut donc cloner ce repository, se rendre dans le dossier contenant le Dockerfile de l’image Check_MK et effectuer les commandes suivantes :

# Construction de l'image (le numéro de version est par exemple 1.4.0p19)
$ docker build -t registry.picasoft.net:5000/checkmk:<numéro de version>
$ docker tag registry.picasoft.net:5000/checkmk:<numéro de version> registry.picasoft.net:5000/checkmk:latest

# On envoie l'image sur le registry
$ docker push registry.picasoft.net:5000/checkmk:<numéro de version>
$ docker push registry.picasoft.net:5000/checkmk:latest

NB: Dans le cas ou l’on souhaite mettre à jour Check_MK, il faut ,avant de construire l’image, modifier le numéro de version dans le fichier Dockerfile correspondant.

L’image Docker a été déployée sur la VM de monitoring. Pour faire de même, il faut intégrer la configuration suivante docker-compose.yml, situé dans le dossier /DATA/docker/ :

checkmk:
  image: registry.picasoft.net:5000/checkmk:<version>
  container_name: checkmk
  volumes:
    - /DATA/docker/checkmk:/omd/sites
  environment:
    - SITE_NAME=monitoring
    - ADMIN_MAIL=contact@picasoft.net
    - ADMIN_PASSWORD=mypassword
  labels:
    - "traefik.frontend.rule=Host:checkmk.picasoft.net"
    - "traefik.port=5000"
    - "traefik.enable=true"
  restart: always

NB: Ne pas oublier de créer le dossier /DATA/docker/checkmk , si cela n’est pas déjà fait.

NB 2: Cette configuration est susceptible de changer ! Pour s’assurer d’une version à jour, il est conseillé de consulter le fichier README de l’image.

Il est ensuite possible de démarrer l’image via la commande :

$ docker-compose up -d checkmk

L’interface de Check_MK est normalement accessible à l’adresse <url>/<nom du site>/omd/, ce donne dans le cas de l’infrastructure de Picasoft https://checkmk.picasoft.net/monitoring/omd/ . Le login est cmkadmin, et le mot de passe est celui qui a été défini dans le fichier docker-compose.yml.

Une configuration personnalisée peut-être placée dans le fichier /DATA/docker/checkmk/monitoring/etc/checkmk/main.mk :

# 3 attempts before triggering issue for some services
extra_service_conf["max_check_attempts"] = [
  ( "3", ALL_HOSTS, "Check_MK" ),
  ( "3", ALL_HOSTS, "Check_MK_Discovery" ),
  ( "3", ALL_HOSTS, "PING" ),
]

# Ignore Docker interfaces and filesystems
ignored_services += [
  ( ALL_HOSTS, ["Interface veth", "Interface br", "Interface tap", "Filesystem /var/lib/docker/aufs", "Filesystem /var/lib/docker/overlay2"] ) 
]

# Change interfaces services name
if_inventory_uses_description = True

La communication entre les agents et le serveur de monitoring doit impérativement se faire en SSH, afin de chiffrer le transport des métriques. Pour cela, il faut avoir établi un jeu de clé privé/public, les manipulations suivantes sont donc à faire sur la VM de monitoring, uniquement dans le cas ou la paire de clés n’a pas encore été générée. Normalement, celle-ci l’a déjà été et les clés sont accessibles dans le dossier /DATA/docker/checkmk/monitoring/.ssh sous le nom de idmonitoring (clé privée) et idmonitoring.pub (clé publique).

Il faut tout d’abord accéder à l’instance docker hébergeant Check_MK :

# Accédons au dossier contenant le docker-compose.yml, afin de pouvoir utiliser la commande docker-compose
$ cd /DATA/docker/
# Lancons un shell bash dans le container nommé checkmk
$ docker-compose exec checkmk /bin/bash

# Pour se connecter en tant que l'utilisateur du site monitoring
$ omd su monitoring
# Créer la clé de chiffrement
$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/omd/sites/monitoring/.ssh/id_ed25519): <chemin de la clé privée> 
Enter passphrase (empty for no passphrase): # LAISSER VIDE !
Enter same passphrase again: # IDEM VIDE
Your identification has been saved in <chemin de la clé privée> .
Your public key has been saved <chemin de la clé privée>.pub .

Vous disposez normalement d’une paire de clés, celle sans extension .pub étant privée

Nb: Il n’est pas obligatoire de mettre le paramètre -t ed25519, car celui-ci précise seulement le fait que nous voulions générer une clé edDSA et non RSA, ce qui n’a que peu d’importance.

Il faut maintenant paramétrer Check_MK de manière à lui dire de se connecter aux agents via SSH en utilisant la clé privée créée pour l’occasion.

Pour cela, il faut se rendre sur l'interface Web et suivre le chemin suivant :

Enfin, il suffit de créer une règle en cliquant sur “create rule in folder”, puis de rajouter la commande suivante comme sur l’image ci dessous :

ssh -i ~/.ssh/id_monitoring -T -oStrictHostKeyChecking=no root@$HOSTADDRESS$

Un agent CheckMK est un script, qui lorsqu’il est exécuté sur une machine, va envoyer sous format textuel un ensemble de métriques formatées de manière à ce que le serveur CheckMK puisse les traiter.

Exemple : Début des informations renvoyées par l’agent (commande checkmkagent)

$ check_mk_agent 
<<<check_mk>>>
Version: 1.4.0p19
AgentOS: linux
Hostname: pica01-test
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
<<<df>>>
udev                              devtmpfs     4077996       0   4077996       0% /dev
tmpfs                             tmpfs         817932   84184    733748      11% /run
/dev/mapper/pica01--test--vg-root ext4         9480420 2245772   6730024      26% /
tmpfs                             tmpfs        4089660       0   4089660       0% /dev/shm
tmpfs                             tmpfs           5120       0      5120       0% /run/lock
...

Afin de sécuriser le transport des informations entre le serveur de monitoring et chaque agent, le serveur effectue une connexion ssh à chaque machine, et exécute la commande checkmkagent permettant de récupérer les informations. Nous verrons par la suite comment faire en sorte que la commande checkmkagent soit lancée automatiquement lors de la connexion ssh.

Dans le cas ou l’installation se fait depuis une distribution Debian, un paquet deb est disponible à l’adresse:

http://<adresse du moniteur>/<nom du site>/check_mk/agents/check-mk-agent_<version de check_mk>_all.deb

Dans mon cas, le site s’apelle picamon et la version actuelle est 1.4.0p19-1 : <code> $ wget https://monitoring.picasoft.net/monitoring/check_mk/agents/check-mk-agent_1.4.0p19-1_all.deb $ dpkg -i check-mk-agent1.4.0p19-1all.deb </code> L’agent est normalement installé et la commande checkmk_agent doit être disponible.

NB : Si une authentification est nécessaire pour télécharger l’agent, il est possible d’ajouter les paramètres suivants à la commande wget :

  --user=<nom d'utilisateur>
  --password=<mot de passe>

Nous allons autoriser le serveur de monitoring à se connecter à cet hôte, en ajoutant la clé publique du serveur (générée précédemment).

Il faut, dans notre cas se connecter sur la machine ou est installé le serveur CheckMK, c’est à dire sur la VM de monitoring et effectuer les commandes suivantes : <code> $ cat /DATA/docker/checkmk/monitoring/idmonitoring </code> OU

$ cd /DATA/docker
$ docker-compose exec checkmk /bin/bash
$ omd su <nom du site> 
cat <chemin de la clé>.pub

Dans mon cas, cela donne :

OMD[monitoring]:~$ cat ~/.ssh/id_monitoring.pub 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM43I5Cn8hW4Wx+QFU/6eI3iWvzo8BU81e8cOjRTIt/K monitoring@monitoring.picasoft.net

Sur le système où est installé l’agent, il faut ajouter dans le fichier ~/.ssh/authorizedkeys la ligne suivante : <code> # Communication vers l’agent checkmk command=“/usr/bin/checkmkagent” <clé publique> </code> Ce qui donne dans mon cas : <code> # Communication vers l’agent checkmk command=“/usr/bin/checkmkagent” ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM43I5Cn8hW4Wx+QFU/6eI3iWvzo8BU81e8cOjRTIt/K monitoring@monitoring.picasoft.net </code> Nb: Le commentaire est là pour indiquer au responsable technique à quoi correspond la clé, afin qu’elle ne soit pas enlevée. ==== Ajouter un hôte disposant de l’agent dans l’interface WEB de Checkmk ==== Aller sur l'interface, s’authentifier, puis le menu à gauche nommé “WATO Configuration”, cliquer sur “Hosts”: Enfin, en haut de l’interface cliquer sur “New Host”. Entrer le nom d’hôte de la machine dans le champs “Hostname” (il doit être résolvable depuis la VM de monitoring), puis cliquer sur “Save and go to settings”. Enfin, choisir les services à monitorer : * Le champ Undecided services contient les services non filtrés par le fichier main.mk. En cliquant sur “monitor”, on choisit de monitorer tout ces services. * Le champ Disabled services contient tout les services filtrés par le fichier main.mk. ===== L’infrastructure actuelle ===== Actuellement, le serveur CheckMK de Picasoft effectue le monitoring des hyperviseurs (Alice et Bob), ainsi que des VMs : ===== Sources ===== Qu’est ce que le monitoring et pour quel besoin https://www.ekino.com/panorama-solutions-monitoring/ Les avantages d’une telle solution http://blog.unicsolution.com/2013/11/best-monitoring-solution-omd-nagios.html https://wiki.monitoring-fr.org/nagios/addons/check_mk/start http://igm.univ-mlv.fr/~dr/XPOSE2010/supervision/architecture.html https://dumas.ccsd.cnrs.fr/dumas-01305578/document