| Scroll Ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Concept
Les notifications sont toutes manières permettent d'informer les utilisateurs en dehors de l'interface de Shinken d'un changement de statut ou de contexte d'un hôte, check ou cluster.
- Pour un élément donné ( hôte, check, cluster ),
- une notification sera générée, suivant la configuration de l'élément ( notifie sur tous les statuts et contextes, seulement sur certains, ... )
- et l'envoyer à des utilisateurs en fonction du paramétrage de la ou les méthodes de notification qu'il utilise.
Les sous-.Ces pages vont expliquer :
la- La logique de notification
- , c.a.d le "quand, qui, comment
- " ( voir la page
- Logique de notification),
- Les types de notifications possibles :
- Soit utiliser/customiser les notifications par email fourni par défaut dans Shinken ( voir la page
- .
- Comment faire votre propre méthode de notification.
- Les escalades pour notifier d'autres utilisateurs si un élément est trop longtemps non OK par exemple ( voir la
Dans une deuxième temps, il sera peut-être nécessaire d'avoir recours à une utilisation plus spécifique, pour cela un certain nombre de pages expliqueront :
- Comment faire vos propres méthodes de notifications ( voir la page NEW_PAGE - 003.5.6 - SEF-11240 - Créer une méthode de notification spécifique - bonnes pratiques )
- Comment faire vos propres commandes de notifications ( voir la page NEW_PAGE - 003.5.6 - SEF-11240 - Créer des commandes de notification spécifique - bonnes pratiques )
- Comment faire vos propres modèles de mail ( voir la page NEW_PAGE - 003.5.6 - SEF-11240 - Créer votre propre modèle de mail de notification )
Reactionner et réaction
Lorsque des objets supervisés changent d'état, et qu'ils sont paramétrés pour réagir à ce changement, alors le démon Reactionner permet d’exécuter une réaction.
Une réaction est une commande qui est paramétrée dans Shinken.
La réaction peut être :
- Une commande de notification
- Une commande du Gestionnaire d'événements
Dans ces pages, nous allons nous intéresser aux commandes de notification, et comment les personnaliser.
| Info | ||
|---|---|---|
| ||
| Avant de commencer à lire cette page, il est important de comprendre que la commande de notification peut utiliser n'importe quels scripts placés sur votre Reactionner. Donc, potentiellement, la commande peut vous alerter de manière traditionnelle, en vous envoyant un email via une commande "mail", mais pourquoi pas en envoyant un message instantané via votre serveur Jabber, ou encore en faisant clignoter une LED branchée sur votre Raspberry! |
Problème
Tester votre commande
Si vous souhaitez envoyer une commande depuis votre Reactionner afin de vérifier le bon envoi de l'email, loguez-vous en shinken via :
| Code Block | ||||
|---|---|---|---|---|
| ||||
su - shinken
|
Puis envoyer votre commande, par exemple :
| Code Block | ||||
|---|---|---|---|---|
| ||||
/var/lib/shinken/libexec/notifications/notify_by_email.py --title-tpl /var/lib/shinken/libexec/notifications/service_alert_title_template.tpl
--content-tpl /var/lib/shinken/libexec/notifications/service_alert_content_template.tpl -F "ENVOYEUR@DOMAIN.COM" -r "RECEVEUR@DOMAIN.COM" -n
PROBLEM -H "mon-serveur" --address "172.16.0.10" --url http://172.16.0.10:7767 --huuid 7b0513f631a011e889e9080027da5b5c --check "Memory"
--state CRITICAL --last-state 0 --last-change 1525338011.76 --last-check "03-05-2018 11:00:56" --output
"Critical : memory consumption is too high 66%" --long-output "" --ack-author "" --ack-data "" |
Vous devriez alors recevoir :
| Code Block | ||||
|---|---|---|---|---|
| ||||
DATE,426:INFO: Mail sent successfully |
Et vous devriez recevoir l'email dans votre boite email.
Logs
Si vous avez des difficultés, veuillez vérifier les logs :
- Du Réactionner dans /var/log/shinken/
- De votre serveur mail linux (postfix/smtp) dans /var/log/maillog
Configuration avancée (relais SMTP)
- )
Mécanisme des notifications
Il est important de comprendre le mécanisme des notifications :
- C'est le Scheduler détermine si une notification doit avoir lieu, en créant des commandes de notification à exécuter
- mais c'est le Reactionner qui exécute les scripts de notification, en prenant en charge les commandes de notification à exécuter.
Plus précisément, suivant le changement d'état d'un élément ( constaté par le Poller ), et la configuration définie sur cet élément, le Scheduler prépare les commandes pour notifier les utilisateurs de leur méthode de notification.
- Si pour un même utilisateur, plusieurs méthodes de notification sont définies, une commande de notification pourra être créée ( mais pas systématiquement, car cela dépendra du paramétrage de la méthode de notification ).
- Ceci permet d'avoir par exemple :
- des doubles notifications,
- ou de n'avoir qu'une notification, mais de changer de média en fonction de l'heure.
Si votre serveur SMTP principal est un serveur connu et généralisé dans votre architecture, vous pouvez aussi modifier votre configuration afin de relayer n'importe quel email vers ce serveur :
- Editer le fichier /etc/postfix/main.cf
- Modifier la ligne avec l'IP de votre serveur SMTP (ici 192.168.1.240) : relayhost = 192.168.1.240
Redémarrer postfix
Code Block language text theme Emacs service postfix restart
Test d'envoi de mail :
| language | text |
|---|---|
| theme | Emacs |