Nagios : Notification via Telegram
Prérequis
Avant de suivre le tutoriel
Dans cette version du tutoriel, je ne présente pas comment créer un bot Telegram. Je montre tout de même comment récupérer l’ID du groupe de chat. Pour suivre ce tutoriel, il vous faut donc :
- Un bot Telegram
- La clé de l’API
- Un groupe Telegram avec votre bot
Récupération de l’ID du groupe Telegram
La méthode la plus simple et d’aller sur l’interface web de Telegram. Cliquez ensuite sur votre groupe est copier le lien de votre navigateur.
Le mien est la forme :
L’ID de mon groupe est donc le : 123456789. Vous l’aurez compris, j’ai remplacé mon ID de groupe afin qu’il reste confidentiel.
Maintenant qu’on a toutes les informations nécessaires pour la configuration, on va d’abord valider à la main le système de notification avant de le passer en production.
Installation et tests
Script de notification
Pim van den Berg a écris un script en Python pour cela et l’a publié sur Github. C’est donc son script que nous allons utiliser.
On télécharge donc ce script et on le rend exécutable :
|
|
On test donc le lancement du script à la main de la manière suivante :
|
|
Remplacer donc la chaine 999999999:AAaaAaAaaaaAaaAAa-Z_9Tg7KO-92z14iOK
par votre clé d’API Telegram et 123456789
par votre ID de groupe (conservez bien le tiret avant l’identifiant).
Le premier lancement me une erreur comme quoi ne n’ai pas le module “twx.botapi” d’installé. On corrige donc cela par l’installation du module. Après plusieurs essaie, la seul commande qui me donne le moins d’erreur est la suivante :
|
|
J’ai tous de même les erreurs suivantes :
Building wheels for collected packages: twx.botapi
Running setup.py bdist_wheel for twx.botapi … error
[…]
error: [Errno 2] No such file or directory: ‘LICENSE.txt’Failed building wheel for twx.botapi
Running setup.py clean for twx.botapi
Failed to build twx.botapi
Installing collected packages: twx.botapi
Running setup.py install for twx.botapi … done
Je relance quand même le script et cela fonctionne !
Edit : La commande d’installation qui n’apporte pas d’erreur est sudo -H python -m pip install twx.botapi --no-cache-dir
. De cette manière, PIP utilise le “setup.py” en lieu et place du systeme de package wheel.
On tests donc les différents états Nagios :
|
|

Je vous conseille de tester cela avec l’utilisateur Nagios. Pour ma part, je n’ai pas eu de problème.
On va donc maintenant faire le nécessaire afin le passer en production.
Configuration
Enregistrement des secrets
On va d’abord enregistrer la clé d’API dans le fichiers de ressources (/usr/local/nagios/etc/resource.cfg
). J’y ajoute donc la ligne suivante :
|
|
J’utilise le “USER” 10 et car les précédant sont déjà utilisés dans ma configuration. Libre à vous de prendre un autre numéros.
Au début, j’avais aussi stocké l’identifiant du groupe, mais au final cela n’a pas fonctionné. Cela est surement dû au fait que cette macro est traduite en une autre macro ("$CONTACTPAGER$") dans le processus de notification. Les macros ne doivent fonctionner qu’en traduction directe.
Commandes
Au préalable, on copie le script et on rend notre utilisateur Nagios propriétaire du fichier :
|
|
On édite donc le fichier de commandes (/usr/local/nagios/etc/objects/commands.cfg
) pour lui ajouter les lignes suivantes :
|
|
N’oubliez pas de modifier le numéro de la macro “USER” si vous n’utilisez pas le même que moi.
Contact
On créer donc notre contact pour le groupe Telegram en éditant le fichier /usr/local/nagios/etc/objects/contacts.cfg
. On y ajoute les lignes suivantes :
|
|
N’oubliez pas de modifier la valeur de pager
par votre identifiant de groupe avec un tiret au début.
Les services notifie pas défaut le groupe de contact “admins”. J’ai donc ajouté “telegram_group” en tant que membre du groupe :
|
|
Si votre groupe “admin” doit contenir plusieurs membres, séparez les éléments pas des virgules.
Validation de la configuration
On valide donc notre configuration avant de relancer Nagios :
|
|
Résultats
Notre service de notification via Telegram est maintenant actif. Je vais maintenant attendre les problèmes ou les provoquer.
Création de fausses alertes
Pour tester simplement, on va utiliser le plugin check_dummy
. Comme son nom l’indique, ce check est stupide ! Si on lui envoie “0”, il répond “OK”. Voici quelques exemples :
Usage:
check_dummy[optional text]
|
|
Le problème d’implémenté simplement cela dans Nagios, c’est qu’à chaque fois qu’on veut changer de valeur de retour il faut modifier la configuration, le vérifier et relancer le service.
J’ai trouvé une astuce en envoyant en paramètre le contenu d’un fichier. Si j’écris “0” dans un fichier, le service passe en “OK”. Si je modifie le contenu du fichier par “1”, le service passe en “WARNING”.
J’ai donc créer le fichier dummy.txt avec le contenue “0” que j’ai mis avec les scripts (sa m’évite d’avoir à gérer les problèmes de droits).
|
|
On créer donc la commande ainsi que le service :
|
|
|
|
J’ai donc ajouté le service à mon serveur Nagios (“localhost”). Il est testé toutes les minutes et envoie immédiatement la notification. Une seule notification est envoyée par changement d’état.
Après avoir refait les étapes de changement de configuration et vu sur Nagios que mon service est bien “OK”, je teste les états avec les commandes suivantes :
|
|

Je n’ai pas testé les changements d’états des hôtes (la flemme…). Si vous voulez les tester il vous suffit d’appliquer le même principe pour un hôte en remplaçant votre “check-host-alive” par “my_check_dummy”.