Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:monitoring:checkmk:check_mk [2020/02/14 15:13] – modification externe 127.0.0.1
+++ technique:monitoring:checkmk:check_mk [2020/09/04 15:10] (Version actuelle) – supprimée qduchemi
@@ Ligne 1: / Ligne 1: @@
-====== 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.
-===== Pourquoi Check_MK ? ======
-==== Qu'est ce que le monitoring et pour quel besoin ? ====
-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**.
-==== Les avantages d'une telle solution ====
-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.
-===== Déploiement du serveur =====
-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.
-==== Création/Mise à jour de l'image Check_MK ====
-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 [[https://gitlab.utc.fr/picasoft/dockerfiles|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 :
-<code>
-# 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
-</code>
-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.
-==== Mise en place avec docker-compose ====
-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/ // :
-<code>
-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
-</code>
-__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 :
-<code>
-$ docker-compose up -d checkmk
-</code>
-==== Accès à l'interface WEB ====
-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//.
-=== Ajout de la configuration personnalisée ===
-Une configuration personnalisée peut-être placée dans le fichier // /DATA/docker/checkmk/monitoring/etc/checkmk/main.mk // :
-<code>
-# 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
-</code>
-==== Ajout/Création des clés SSH ====
-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 id_monitoring (clé privée) et id_monitoring.pub (clé publique).
-Il faut tout d'abord accéder à l'instance docker hébergeant Check_MK :
-<code>
-# 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
-</code>
-<code>
-# 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 .
-</code>
-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é [[https://fr.wikipedia.org/wiki/EdDSA|edDSA]] et non [[https://fr.wikipedia.org/wiki/Chiffrement_RSA|RSA]], ce qui n'a que peu d'importance.
-==== Configuration de l'accès via ssh aux agents ====
-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 [[https://monitoring.picasoft.net|l'interface Web]] et suivre le chemin suivant :
-{{monitoring:wato_menu.png}}
-{{monitoring:datasource.png}}
-{{monitoring:individual_program.png}}
-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 :
-<code>
-ssh -i ~/.ssh/id_monitoring -T -oStrictHostKeyChecking=no root@$HOSTADDRESS$
-</code>
-{{monitoring:rule_ssh.png}}
-===== Déploiement d'un agent =====
-==== Introduction ====
-Un agent Check_MK 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 Check_MK puisse les traiter.
-**Exemple** : Début des informations renvoyées par l'agent (commande **check_mk_agent**)
-<code>
-$ 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
-...
-</code>
-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 //check_mk_agent// permettant de récupérer les informations. Nous verrons par la suite comment faire en sorte que la commande //check_mk_agent// soit lancée automatiquement lors de la connexion ssh.
-==== Installation de l'agent ====
-Dans le cas ou l'installation se fait depuis une distribution Debian, un paquet deb est disponible à l'adresse:
-<code>
-http://<adresse du moniteur>/<nom du site>/check_mk/agents/check-mk-agent_<version de check_mk>_all.deb
-</code>
-Dans mon cas, le site s'apelle pica_mon 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-agent_1.4.0p19-1_all.deb
-</code>
-L'agent est normalement installé et la commande check_mk_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 :
-<code>
-  --user=<nom d'utilisateur>
-  --password=<mot de passe>
-</code>
-==== Configuration SSH  ====
-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).
-=== Affichage de la clé ===
-Il faut, dans notre cas se connecter sur la machine ou est installé le serveur Check_MK, c'est à dire sur la VM de monitoring et effectuer les commandes suivantes :
-<code>
-$ cat /DATA/docker/checkmk/monitoring/id_monitoring
-</code>
-OU
-<code>
-$ cd /DATA/docker
-$ docker-compose exec checkmk /bin/bash
-$ omd su <nom du site>
-cat <chemin de la clé>.pub
-</code>
-Dans mon cas, cela donne :
-<code>
-OMD[monitoring]:~$ cat ~/.ssh/id_monitoring.pub
-ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM43I5Cn8hW4Wx+QFU/6eI3iWvzo8BU81e8cOjRTIt/K monitoring@monitoring.picasoft.net
-</code>
-=== Ajout de la clé dans le fichiers des clés autorisées ===
-Sur le système où est installé l'agent, il faut ajouter dans le fichier //~/.ssh/authorized_keys// la ligne suivante :
-<code>
-# Communication vers l'agent check_mk
-command="/usr/bin/check_mk_agent" <clé publique>
-</code>
-Ce qui donne dans mon cas :
-<code>
-# Communication vers l'agent check_mk
-command="/usr/bin/check_mk_agent" 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 Check_mk ====
-Aller sur [[https://monitoring.picasoft.net/monitoring/omd/|l'interface]], s'authentifier, puis le menu à gauche nommé "WATO Configuration", cliquer sur "Hosts":
-{{monitoring:wato_host.png}}
-Enfin, en haut de l'interface cliquer sur "New Host".
-{{monitoring:new_host.png}}
-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 Check_MK de Picasoft effectue le monitoring des hyperviseurs (Alice et Bob), ainsi que des VMs :
-{{monitoring:network-14-01-18.png}}
-===== 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