Plugin Monitoring (Jeedom)

:warning: IMPORTANT

S’il n’y a pas d’information sur la mise à jour, c’est que celle-ci concerne uniquement de la mise à jour de documentation, de traduction ou de texte.

Auteurs

Merci à Phifi qui à l’origine du plugin Monitoring, repris depuis le 13 novembre 2023 par TiTidom.

Présentation

Ce plugin permet de récupérer des données système de différents équipements (en local pour monitorer votre Jeedom ou à distance via SSH) et de les afficher sur le Dashboard de Jeedom.

v2.5 Monitoring - Debian 12

v3.0 Monitoring - Odroid C2

Initialement, ce plugin a été créé pour monitorer seulement les Jeedom Mini et Mini+. Mais pour répondre à une forte demande, il a été rendu compatible avec des Jeedom installés sur des VM (Machine Virtuelle), des Linux distants (Debian, Ubuntu, etc…) ou encore un NAS Synology.

Compatibilité

:warning: IMPORTANT

La version minimum du core de Jeedom requise pour le plugin (jusqu’à la version 2.5) est la version 4.2 (depuis le 13 décembre 2023)

La version minimum du core de Jeedom requise pour le plugin à partir de la version 3.0 est la version 4.4 avec un OS Debian 11 minimum.

Des retours des utilisateurs, voici une liste, non exhaustive, des systèmes (hardware / distribution) compatibles :

A venir dans une future version v3.x :

Données visibles sur le Dashboard

Monitoring - Debian 10 aarch64

Configuration

Dépendances

Jusqu’à la version 2.5 du plugin, (et depuis la version du 13 décembre 2023), il n’y a plus de dépendances à installer.

A partir de la version 3.0 du plugin, Monitoring fonctionne de concert avec le plugin SSH-Manager (qui est donc une dépendance du plugin). Le plugin SSH-Manager est installé automatiquement (s’il n’est pas déjà installé) lors de la mise à jour du plugin Monitoring vers la version 3.0.

Monitoring - Dépendances

Les logs d’installation des dépendances se trouvent dans le fichier Monitoring_update accessible à partir de la page de configuration du plugin, ou bien directement à partir du menu Analyse / Logs de Jeedom.

Migration de la version 2.5 vers 3.0

Le passage de la version 2.5 à la version 3.0 n’est pas neutre, dans la mesure où le plugin a été réécrit. Merci de bien lire tout ce chapitre avant de migrer vers la version 3.0.

:warning: IMPORTANT

Pensez à recréer l’équipement “local” (celui qui monitore votre Jeedom) “à la main” ! Les commandes ont beaucoup évolué dans cette version 3.0, il est donc important de bien recréer un équipement et non pas simplement de le modifier, car l’équipement local n’est pas pris en compte par le bouton “Migrer” et la procédure ci-dessous qui ne concerne que les équipements distants.

Dans le panneau de configuration du plugin, un bouton Migrer (v2.5 -> v3.0) a été ajouté spécifiquement pour passer les équipements distants de la version 2.5 à la version 3.0.

Monitoring - Migration

Mais ATTENTION : Il ne migre que les paramètres de connexion des équipements distants (Adresse IP, Port SSH, Timeout SSH, Identifiant, Mot de passe, Clé SSH, Passphrase). Il ne migre PAS les paramètres spécifiques (tels que les seuils par exemple de certaines commandes dans la colorisation), et après cette migration, il faudra quand même supprimer les équipements pour les recréer (mais ce sera facilité par la migration des paramètres de connexion, puisque les objets auront été créés dans le plugin SSH-Manager)

Il y a deux manières de migrer les équipements distants vers la version 3.0 :

Méthode 1 (Conseillée) (En utilisant le bouton Migrer) :

:information_source: ASTUCE

A l’étape 5, vous pouvez conserver les anciens équipements le temps de finaliser la migration, MAIS il ne faut absolument pas y toucher : Ni les renommer, ni aucune autre modification qui implique d’utiliser le bouton “Sauvegarder” de l’équipement en question, sinon vous aurez des erreurs affichées à l’écran de type “Duplicate entry” Si vous conservez les anciens équipements, cela vous permettra via les outils intégrés à Jeedom, par exemple de récupérer l’historique d’une commande ou de remplacer une commande dans un scénario.

Pensez bien (c’est important : Pour ne pas conserver de vieilles configurations dans la base de données Jeedom), après avoir finalisé votre migration, à supprimer ces anciens équipements, car tant qu’ils seront présents, cela amènera des erreurs dans les logs du plugin.

Une fois les nouveaux équipements recréés et paramétrés, la migration est terminée. Vous n’avez plus qu’à profiter des données du plugin Monitoring.

Méthode 2 (Sans utiliser le bouton Migrer, méthode manuelle) :

:information_source: ASTUCE

Cette méthode n’utilise pas le bouton Migrer, elle n’est conseillée (pour toute raison qui vous est propre) que si vous ne souhaitez pas utiliser le bouton “Migrer”, mais il faut alors se souvenir de l’ensemble des paramètres de connexion (ip, identifiant, mot de passe, clé ssh, etc…) de vos équipements Monitoring pour pouvoir les recréer.

Version du Plugin

A chaque version du plugin qui sort, un numéro est attribué sous la forme “version_majeure.version_mineure.version_patch” (par ex. : “2.2.0”). Vous pouvez retrouver cette information sur la page de configuration du plugin. Pour toute demande sur le Community, merci de préciser dans vos messages ce numéro de version du plugin.

Monitoring - Plugin Version

Configuration des Mises à jour Automatiques

A partir de la page du plugin, vous pouvez accéder à la Configuration du plugin qui se présente sous cette forme :

Monitoring - Configuration

Par défaut :

:warning: IMPORTANT

Sauf cas exceptionnel, vous n’avez aucune raison de désactiver les mises à jour automatiques faites toutes les 15 min !

Si vous souhaitez monitorer votre équipement Local (Votre Jeedom) plus régulièrement (Toutes les minutes), vous pouvez activer l’option “Equipement Local (1min)” et appuyer ensuite sur le bouton “Sauvegarder”.

Pensez dans ce cas à activer l’historique des commandes de cet équipement local et à changer le “Mode de lissage” de l’historique, car par défaut Jeedom lisse les valeurs à “5 minutes”, et vous perdriez le bénéfice de mettre à jours ces valeurs toutes les minutes !

A minima, je vous conseille (pour ces mises à jour toutes les minutes) d’activer l’historique sur la commande “Charge Système 1 min” et dans la configuration de cette commande, onglet “Configuration” de modifier les options d’historique comme ceci :

Monitoring - Historique

:information_source: ASTUCE

A partir de la version 2.5.5, vous avez également la possibilité de définir, pour chaque équipement, une fréquence personnalisée de mise à jour des informations (cron personnalisé)

Configuration d’un équipement

Monitoring - Page Plugin

Pour configurer un nouvel équipement :

Monitoring - Plugins

Monitoring - Ajouter

Monitoring - Par Défaut

Monitoring - Carte Réseau

Panneau de la v3.0 Monitoring - Local vs Distant

:warning: IMPORTANT

Pour des systèmes Linux monitorés à distance via SSH, vous devez choisir un compte (identifiant) avec des droits suffisants pour lancer les commandes (par ex. un utilisateur “sudo” ou bien à défaut le compte “root”).

Pour un NAS Synology, il faut utiliser un compte disposant des droits administrateurs.

Choix “Local”

Version 3.0

Une option est disponible lorsque vous choisissez ce mode :

Choix “Distant”

Version 3.0

Après avoir sélectionné ce mode, 1 champ s’affiche :

Monitoring - Hôte SSH

Le bouton + à droite de la liste, permet d’ajouter un hôte SSH sans avoir à se rendre dans le plugin SSH-Manager :

Monitoring - New SSH

Remplissez alors les différents champs :

Cliquer ensuite sur Sauvegarder Hôte SSH. L’équipement sera créé automatiquement, et disponible dans la liste Sélectionner un hôte.

Une fois l’hôte sélectionné, configurez les différentes options souhaitées (NAS, Linux, Auto-Actualisation, etc…) et Sauvegardez l’équipement.

Choix “Distant (Mot de passe)”

Version 2.5

Après avoir sélectionné ce mode, 4 champs supplémentaires s’affichent :

Monitoring - Distant (Password)

Choix “Distant (Clé SSH)”

Version 2.5

Après avoir sélectionné ce mode, 5 champs supplémentaires s’affichent :

Monitoring - Distant (Clé)

:warning: IMPORTANT

Le plugin ne gère pas la génération de la clé SSH, ni la recopie de la clé publique sur le système distant (nécessaire pour permettre la connexion à ce système via une clé SSH).

Pour plus d’informations sur la génération d’une clé SSH, rendez-vous dans la FAQ.

Configuration spécifique pour un NAS Synology

Avant toute chose, pour pouvoir monitorer un NAS Synology, il faut que le service SSH soit activé dessus. c’est via ce protocole SSH que le plugin communique avec votre baie Synology.

Pour vous en assurer, rendez-vous dans le panneau de configuration de votre baie Syno, dans la partie “Terminal & SNMP” et assurez-vous que la case “Activer le service SSH” est bien cochée.

Monitoring - NAS - SSH

Vous pouvez ensuite configurer votre équipement :

Pour monitorer un NAS Synology, il faut cocher la case “Activer” du bloc “NAS Synology” situé sur la droite de la page de configuration de l’équipement. Cela permet de détecter correctement les informations systèmes spécifiques à votre NAS, comme le numéro de version, les volumes disques, etc…

Après avoir cliqué sur le bouton “Activer”, plusieurs options sont disponibles :

Monitoring - NAS Synology

Configuration spécifique pour un Linux/Proxmox

Sur la page de configuration de votre équipement, vous avez un bloc spécifique (sur la droite) : “Linux/Proxmox” :

Si la température est mal détectée sur votre équipement, et que vous avez connaissance de la commande exacte qui permet de la récupérer, vous pouvez utiliser ce champ prévu à cet effet.

Monitoring - Proxmox

Configuration spécifique : Auto-Actualisation (Cron)

Optionnel

Pour chaque équipement, vous avez la possibilité de définir une fréquence personnalisée de mise à jour des infos systèmes de l’équipement, disponible sur la partie droite de la page de configuration de votre équipement, dans un bloc spécifique : “Auto-Actualisation (Cron)” :

Monitoring - Cron Perso

Après avoir cliqué sur le bouton “Activer”, le champ “Cron Personnalisé” est disponible. Utilisez alors le bouton ?, à droite du champ, pour afficher “l’assistant Cron”, qui vous permettra de définir la fréquence souhaitée (toutes les minutes, toutes les 5 minutes, toutes les heures, une fois par jour, etc…)

Monitoring - Cron Assistant

Cliquez ensuite sur le bouton Sauvegarder et votre cron personnalisé est défini.

:warning: IMPORTANT

Ce cron personnalisé et PRIORITAIRE sur le(s) cron(s) par défaut du plugin (1min et 15min). Dis autrement : Si vous définissez un cron personnalisé, le(s) cron(s) par défaut du plugin ne se déclencheront plus pour CET équipement (ils continueront de se déclencher pour les autres équipement du plugin).

Configuration spécifique : Statistiques (Tendance)

Cocher la case Tendance pour afficher sur le widget du dashboard les tendances (à la hausse, à la baisse, etc…) lorsque l’historisation de la commande est activée.

Commandes spécifiques : “Cron On” / “Cron Off” / “Statut Cron”

Ces 3 commandes sont disponibles à partir de la version 2.5.5.

Monitoring - Cron Commands

Ces commandes peuvent être utilisées dans un scénario, par exemple, pour mettre en pause (Cron Off) la récupération automatique des infos de l’équipement, si celui-ci est arrêté pendant une période (ex. : un NAS qui est éteint lorsque la personne est absente). Cela évite les erreurs de récupération d’infos pendant cette période. Lorsque l’utilisateur rallumera le NAS, le scénario pourra alors remettre en route le cron de l’équipement avec la commande Cron On.

Monitoring - Cron Scenario

Lorsque vous utilisez les commandes Cron On et Cron Off, un icône (play ou pause) est présent sur le widget du dashboard pour vous indiquer l’état du cron pour cet équipement.

Monitoring - Cron Play

Monitoring - Cron Pause

Configuration spécifique : Commandes ‘perso1’ et ‘perso2’

Pour chaque équipement, vous avez la possibilité de configurer 2 commandes personnalisées : “perso1” et “perso2”.

Monitoring - Proxmox

Saisissez toute commande Linux valide dans la zone prévue à cet effet, et indiquez si besoin l’unité. Vous pouvez également personnaliser le nom de la commande et l’icône à afficher sur le Dashboard.

Si la case “Afficher” est cochée pour les commandes “perso1” et/ou “perso2”, alors le résultat de ces commandes sera affiché sur le Dashboard.

Colorisation des valeurs

Pour permettre de les mettre en avant, il est possible de coloriser certaines valeurs (en vert, orange et rouge) suivant deux seuils définis. Les valeurs rentrées pour les différents seuils devront être dans la plage de celles que retourne la commande correspondante. Par exemple, si la commande retourne : 55°C ou 12%, il faudra alors saisir la valeur chiffrée (55, 12), sans le signe “%”, “°C”.

Monitoring - Commandes

Il est possible de choisir des seuils pour les commandes suivantes :

Informations sur les seuils de colorisation

Il existe deux types de colorisation : “Vert - Orange - Rouge” et “Rouge - Orange - Vert” suivant la donnée à représenter.

Ex. : Pour représenter un espace disque UTILISE, le modèle “Vert Orange Rouge” sera associé, alors que pour représenter une mémoire LIBRE on va utiliser le modèle inverse “Rouge Orange Vert”.

Monitoring - Colorisation VOR

Monitoring - Colorisation ROV

Valeurs par défaut pour les seuils de colorisation

Voici quelques valeurs qui pourront vous aider à calibrer les seuils de vos équipements (ils ne sont donnés qu’à titre d’exemple) :

Charge Système 1 min / 5 min / 15 min (Load Average) :

Cette valeur est un nombre décimal (1.17 par exemple), dont le minimum est 0.00 (système au repos)

Pour se donner une idée de la charge réelle du système en pourcentage (%) à partir du Load Average 1 min, on peut faire ce calcul : (valeur / nombre de coeurs) * 100

Espace Disque Utilisé (Pourcentage) :

Plus cette valeur est basse, mieux c’est ! L’unité est un pourcentage (%) compris entre 0% et 100%.

Mémoire Libre (Pourcentage) :

Plus cette valeur est haute, mieux c’est ! L’unité est un pourcentage (%) compris entre 100% et 0%.

Swap Libre (Pourcentage) :

Plus cette valeur est haute, mieux c’est ! L’unité est un pourcentage (%) compris entre 100% et 0%.

Température CPU :

Plus cette valeur est basse, mieux c’est ! L’unité est en degré (°C).

Historisation

Pour certaines valeurs, il est possible d’activer “Historiser” pour représenter, par une courbe, les variations de celles-ci.

Historiser est possible pour (commandes du widget) :

:information_source: ASTUCE

Nous n’évoquons ici que les commandes qui sont affichées via le Widget (template) sur le Dashboard, beaucoup d’autres commandes (presque toutes) sont historisables dans les équipements Monitoring, en cochant la case Historiser

Monitoring - Historisation

A partir du moment où une commande est historisée, vous avez aussi la possibilité d’afficher un “graphique de fond de tuile” sur le dashboard (desktop ou mobile). Pour configurer cette option, rendez-vous dans la configuration de votre équipement, et cliquez sur le bouton “Configuration Avancée”, en haut à droite de la page.

Monitoring - Config GraphInfo

Sur le dashboard, le graphique s’affichera alors en fond sur votre équipement :

Monitoring - GraphInfo

Personnalisation des commandes et affichage sur le Dashboard

Template de Widget

Par défaut, chaque équipement Monitoring utilise le widget intégré au plugin (template) pour son affichage sur le Dashboard.

Lorsque vous utilisez ce template :

Dans cette configuration, le plugin ne prend pas en compte le bouton “Afficher” de toutes les commandes, mais seulement de celles utilisées dans le widget :

Widget personnalisé

Vous avez également la possibilité de ne pas utiliser le widget intégré au plugin et d’organiser alors l’ensemble des commandes comme vous le souhaitez.

Pour cela :

Monitoring - Config Avancée

Monitoring - Template de Widget

Une fois le template de widget désactivé, vous pouvez afficher toutes les commandes de manière “standard” sur le Dashboard, et personnaliser chaque commande (icône, affichage ou non, ordre des commandes, stats, etc…).

:warning: IMPORTANT

Si vous n’utilisez pas le widget intégré au plugin, la colorisation des valeurs des commandes ne sera pas disponible à l’affichage.

Actions “redémarrage” et “extinction” d’un équipement

Mode Local

Il faut s’assurer que le compte avec lequel Jeedom travaille a bien le droit de lancer les commandes “reboot” et “poweroff” (c’est le cas dans les versions récentes de Jeedom).

Mode Distant

Il faut s’assurer, lors de la configuration de l’équipement, de choisir un compte (Identifiant) SSH qui a suffisamment de droits sur le système distant pour lancer les deux commandes reboot et poweroff (pour Linux) ou shutdown pour une baie Synology, sans avoir à taper un mot de passe de confirmation.

Pour s’assurer que le compte utilisé aura bien le droit de rebooter ou d’arrêter l’équipement :

:warning: IMPORTANT

Avant de rentrer la commande ci-dessous, remplacez MonUser (à deux endroits : Au début de la ligne de commande, mais aussi à la fin) par le nom d’utilisateur avec lequel vous vous connectez.

Lorsque vous aurez rentré cette commande, le système vous demandera votre mot de passe (celui du compte avec lequel vous êtes connectés) pour confirmer l’action.

Commande pour un équipement Linux :

echo 'MonUser ALL= NOPASSWD: /usr/sbin/reboot, /usr/sbin/poweroff' | sudo tee /etc/sudoers.d/MonUser

Commande Pour un équipement Synology :

echo 'MonUser ALL= NOPASSWD: /sbin/shutdown' | sudo tee /etc/sudoers.d/MonUser

:warning: IMPORTANT

Cette commande est nécessaire, y compris sur une baie Synology, même si vous utilisez un compte qui est déjà “admin”, car sans la commande ci-dessus, ce compte n’a pas le droit de redémarrer ou d’arrêter cette baie Syno à distance.

FAQ

Quelle est la fréquence de rafraîchissement des informations ?

Quelle est la signification de Charge système 1min/5min/15min ?

Quelle est la différence entre la mémoire “Libre” et “Disponible” ?

Linux est plus compliqué qu’il n’y parait quand il s’agit de la gestion de la mémoire, et :

Voici le pourquoi du comment :

Pourquoi, pour les HDD, “total” n’est pas la somme de “free” + “used” ?

Concernant la gestion du disque sous Linux, il y a une particularité à connaître pour pouvoir répondre à la question en titre :

C’est pour cette raison que j’ai décidé de mettre à disposition toutes les valeurs (que ce soit concernant la mémoire ou les disques) : libre, disponible, utilisé, total, etc… pour que l’utilisateur, en fonction des situations et de ce qu’il souhaite vérifier sur son équipement, ait le choix.

Pourquoi l’addition des % “free” et “used” ne donne pas 100% ?

Les pourcentages “free” et “used” ne font pas 100% quand on les additionne, pour les infos concernant notamment les disques et la mémoire. Est-ce normal ? En un sens : oui ! (Et c’est voulu).

Cela découle entre autres des explications ci-dessus sur la mémoire et sur les disques. Les pourcentages (libre, disponible, utilisé, etc…) ont été calculés à partir des formules extraites et exactes de Linux (en prenant donc en compte par exemple les réservations faites par le système, la prise en compte des caches et des buffers, etc…), et c’est pour cette raison que leur “simple” somme ne fait pas 100%, et que vous devez les utiliser séparément et surtout en fonction de ce que vous recherchez comme information. (Mais il serait trop long d’en faire l’explication complète ici, il y a des sites entiers qui s’y consacrent sur internet)

Est-il possible de monitorer un “VMware ESXi” ?

Pendant la mise à jour du plugin, j’obtiens une erreur dans les logs

cat: /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/temp1_input: No such file or directory

J’obtiens des erreurs dans les logs “cron_execution”

Comme par ex. (récupération de la température CPU) : cat: /sys/devices/virtual/thermal/thermal_zone0/temp: Aucun fichier ou dossier de ce type

Je n’arrive pas à récupérer certaines infos de Synology

Message d’erreur : “Could not chdir to home directory /var/services/homes”

Monitoring - FAQ Synology

Dans la configuration du NAS Synology, il faut se rendre dans le “Panneau de configuration”, puis “Utilisateurs et groupes”, onglet “Avancé”, et tout en bas du panneau dans la partie “Accueil utilisateur” :

Monitoring - FAQ Syno Accueil

Comment générer une “clé SSH” permettant de se connecter à un équipement distant ?

Il existe beaucoup de tutoriels sur internet expliquant comment générer ces clés, nous ne verrons ici que quelques principes :

FreeBSD : impossible de récupérer les informations des commandes

Sur FreeBSD (notamment sur la version tournant sur Raspberry Pi3B+), le shell par défaut utilisé pour les users “freebsd” et “root” n’est pas compatible avec les commandes lancées par le plugin pour récupérer les informations (disque, ram, etc…).

Dans les logs du plugin, lorsque cela ne fonctionne pas, vous allez récupérer une ligne (en niveau debug de logs) de ce type :

[2024-11-03 23:14:04] DEBUG : [NomEquipement - Mon][SSH-EXEC] ARMv Result :: Ambiguous output redirect.

Pour permettre la récupération des commandes, il faut changer le shell du compte utilisé par le plugin. Par défaut, il s’agit du compte freebsd.

Pour changer le shell, il faut passer en utilisateur root et lancer une commande. Voici la marche à suivre :

Après avoir effectué ces quelques manipulations, vous serez à même de récupérer les commandes de votre équipement FreeBSD.

Captures d’écrans

Quelques captures de systèmes monitorés via le plugin :

Debian 10_x86 (VM) : Monitoring - Debian 10

Debian 10_aarch64 (Odroid C2) : Monitoring - Debian 10 aarch64

Debian 11 (VM) : Monitoring - Debian 11

Debian 12 (VM) : Monitoring - Debian 12

NAS Synology : Monitoring - Syno

Changelog

Voir le fichier dédié (version stable) : Changelog (Stable)

Voir le fichier dédié (version beta) : Changelog (Beta)

Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site web. Si vous continuez à utiliser ce site, nous supposerons que vous en êtes satisfait.