Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
technique:monitoring:checkmk:check_mk [2020/02/06 16:28] – ↷ Page déplacée de monitoring:checkmk:check_mk à technique:monitoring:checkmk:check_mk qduchemi | 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' | ||
- | 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 " | ||
- | ===== 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, | ||
- | * La **visualisation** de métriques : l' | ||
- | * 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' | ||
- | |||
- | ==== 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, | ||
- | Parmi ces solutions, plusieurs ont été retenues : | ||
- | * **Nagios** est un " | ||
- | * **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' | ||
- | * **Check_MK** est une solution en plein essor (la popularité est grandissante, | ||
- | |||
- | ===== 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' | ||
- | * d' | ||
- | * 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' | ||
- | * la configurations de nombreuses autres options et fonctionnalités. | ||
- | * D' | ||
- | |||
- | ==== Création/ | ||
- | Une image Docker de Check_MK a été réalisée par Kyâne afin de s' | ||
- | |||
- | Pour construire l' | ||
- | < | ||
- | # Construction de l' | ||
- | $ docker build -t registry.picasoft.net: | ||
- | $ docker tag registry.picasoft.net: | ||
- | |||
- | # On envoie l' | ||
- | $ docker push registry.picasoft.net: | ||
- | $ docker push registry.picasoft.net: | ||
- | </ | ||
- | NB: Dans le cas ou l'on souhaite **mettre à jour Check_MK**, il faut ,avant de construire l' | ||
- | |||
- | ==== Mise en place avec docker-compose ==== | ||
- | L' | ||
- | Pour faire de même, il faut intégrer la configuration suivante // | ||
- | < | ||
- | checkmk: | ||
- | image: registry.picasoft.net: | ||
- | container_name: | ||
- | volumes: | ||
- | - / | ||
- | environment: | ||
- | - SITE_NAME=monitoring | ||
- | - ADMIN_MAIL=contact@picasoft.net | ||
- | - ADMIN_PASSWORD=mypassword | ||
- | labels: | ||
- | - " | ||
- | - " | ||
- | - " | ||
- | restart: always | ||
- | </ | ||
- | __NB:__ Ne pas oublier de créer le dossier // / | ||
- | |||
- | __NB 2:__ Cette configuration est susceptible de changer ! Pour s' | ||
- | |||
- | Il est ensuite possible de démarrer l' | ||
- | < | ||
- | $ docker-compose up -d checkmk | ||
- | </ | ||
- | |||
- | ==== Accès à l' | ||
- | |||
- | L' | ||
- | Le login est cmkadmin, et le mot de passe est celui qui a été défini dans le fichier // | ||
- | |||
- | === Ajout de la configuration personnalisée === | ||
- | Une configuration personnalisée peut-être placée dans le fichier // / | ||
- | < | ||
- | # 3 attempts before triggering issue for some services | ||
- | extra_service_conf[" | ||
- | ( " | ||
- | ( " | ||
- | ( " | ||
- | ] | ||
- | |||
- | # Ignore Docker interfaces and filesystems | ||
- | ignored_services += [ | ||
- | ( ALL_HOSTS, [" | ||
- | ] | ||
- | |||
- | # Change interfaces services name | ||
- | if_inventory_uses_description = True | ||
- | </ | ||
- | |||
- | ==== Ajout/ | ||
- | 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é/ | ||
- | |||
- | Il faut tout d' | ||
- | < | ||
- | # Accédons au dossier contenant le docker-compose.yml, | ||
- | $ cd / | ||
- | # Lancons un shell bash dans le container nommé checkmk | ||
- | $ docker-compose exec checkmk /bin/bash | ||
- | </ | ||
- | |||
- | < | ||
- | # Pour se connecter en tant que l' | ||
- | $ omd su monitoring | ||
- | # Créer la clé de chiffrement | ||
- | $ ssh-keygen -t ed25519 | ||
- | Generating public/ | ||
- | Enter file in which to save the key (/ | ||
- | Enter passphrase (empty for no passphrase): | ||
- | 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> | ||
- | </ | ||
- | 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:// | ||
- | |||
- | |||
- | ==== Configuration de l' | ||
- | 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' | ||
- | |||
- | Pour cela, il faut se rendre sur [[https:// | ||
- | |||
- | {{monitoring: | ||
- | |||
- | {{monitoring: | ||
- | |||
- | {{monitoring: | ||
- | |||
- | Enfin, il suffit de créer une règle en cliquant sur " | ||
- | < | ||
- | ssh -i ~/ | ||
- | </ | ||
- | {{monitoring: | ||
- | |||
- | |||
- | ===== Déploiement d'un agent ===== | ||
- | |||
- | ==== Introduction ==== | ||
- | Un agent Check_MK est un script, qui lorsqu' | ||
- | |||
- | **Exemple** : Début des informations renvoyées par l' | ||
- | < | ||
- | $ check_mk_agent | ||
- | <<< | ||
- | Version: 1.4.0p19 | ||
- | AgentOS: linux | ||
- | Hostname: pica01-test | ||
- | AgentDirectory: | ||
- | DataDirectory: | ||
- | SpoolDirectory: | ||
- | PluginsDirectory: | ||
- | LocalDirectory: | ||
- | <<< | ||
- | udev devtmpfs | ||
- | tmpfs | ||
- | / | ||
- | tmpfs | ||
- | tmpfs | ||
- | ... | ||
- | </ | ||
- | 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 // | ||
- | |||
- | ==== Installation de l' | ||
- | Dans le cas ou l' | ||
- | < | ||
- | http://< | ||
- | </ | ||
- | Dans mon cas, le site s' | ||
- | < | ||
- | $ wget https:// | ||
- | $ dpkg -i check-mk-agent_1.4.0p19-1_all.deb | ||
- | </ | ||
- | L' | ||
- | |||
- | |||
- | NB : Si une authentification est nécessaire pour télécharger l' | ||
- | < | ||
- | --user=< | ||
- | --password=< | ||
- | </ | ||
- | ==== 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 : | ||
- | < | ||
- | $ cat / | ||
- | </ | ||
- | OU | ||
- | < | ||
- | $ cd / | ||
- | $ docker-compose exec checkmk /bin/bash | ||
- | $ omd su <nom du site> | ||
- | cat <chemin de la clé> | ||
- | </ | ||
- | |||
- | Dans mon cas, cela donne : | ||
- | < | ||
- | OMD[monitoring]: | ||
- | ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM43I5Cn8hW4Wx+QFU/ | ||
- | </ | ||
- | |||
- | === Ajout de la clé dans le fichiers des clés autorisées === | ||
- | Sur le système où est installé l' | ||
- | < | ||
- | # Communication vers l' | ||
- | command="/ | ||
- | </ | ||
- | Ce qui donne dans mon cas : | ||
- | < | ||
- | # Communication vers l' | ||
- | command="/ | ||
- | </ | ||
- | Nb: Le commentaire est là pour indiquer au responsable technique à quoi correspond la clé, afin qu' | ||
- | |||
- | ==== Ajouter un hôte disposant de l' | ||
- | Aller sur [[https:// | ||
- | {{monitoring: | ||
- | |||
- | Enfin, en haut de l' | ||
- | {{monitoring: | ||
- | |||
- | Entrer le nom d' | ||
- | |||
- | Enfin, choisir les services à monitorer : | ||
- | * Le champ **Undecided services** contient les services non filtrés par le fichier main.mk. En cliquant sur " | ||
- | * Le champ **Disabled services** contient tout les services filtrés par le fichier main.mk. | ||
- | |||
- | ===== L' | ||
- | |||
- | Actuellement, | ||
- | {{monitoring: | ||
- | |||
- | |||
- | ===== Sources ===== | ||
- | **Qu' | ||
- | |||
- | https:// | ||
- | |||
- | **Les avantages d'une telle solution** | ||
- | |||
- | http:// | ||
- | |||
- | https:// | ||
- | |||
- | http:// | ||
- | |||
- | https:// | ||