Files
Enclume/docs/NOTIFICATIONS.md
hcornet 9debdcdf9c
build / Garde-fou (push) Successful in 10m45s
build / Images Harbor (catalog-sync, Dockerfile.catalog-sync) (push) Successful in 9m52s
build / Images Harbor (web, Dockerfile) (push) Successful in 10m0s
Chaque pack apporte son propre calendrier de notification
2026-09-12 11:02:02 +02:00

7.1 KiB

Notifications par périmètre

Un modèle de service sans notification ne sert à rien en production. Enclume génère donc aussi la chaîne de notification : le calendrier, la commande, les paramètres des contacts, et le script PHP qui met en forme le message.

Les packs livrent leur chaîne

Chaque pack du catalogue déclare son périmètre : le calendrier adapté à sa criticité, un groupe de contacts nommé CG-<Famille>-<Techno>, et l'impact métier d'une panne. Importer le pack LDAP crée donc le groupe CG-App-LDAP, rattache le modèle d'hôte et tous les modèles de service à un périmètre en 24x7, et remplit le message avec « Authentification et annuaire indisponibles ».

Il reste une chose à faire de votre côté : mettre des contacts dans le groupe. Enclume crée le groupe vide, faute de connaître vos utilisateurs.

Chaque pack apporte son calendrier

Un pack ne réutilise pas les calendriers du central : il crée le sien, TP-App-Apache-24x7, TP-HW-Printer-RFC3805-Heures-Ouvrees. Ajuster les plages d'une technologie ne touche alors qu'elle, et non tout ce qui pointait 24x7.

Le rythme copié à la création est 24x7 pour ce dont la panne réveille quelqu'un, Heures-Ouvrees sinon. Les plages restent modifiables ensuite, comme n'importe quel objet du projet.

Si vous préférez viser un calendrier existant sur votre central — 24x7, workhours — saisissez-le dans le périmètre : il apparaîtra dans le projet marqué « Centreon » et ne sera pas recréé, TP;ADD échouant sur un objet existant.

Le principe

Un périmètre regroupe ce qui différencie réellement un domaine d'un autre :

Élément Rôle
Calendrier quand la notification a le droit de partir (objet TP de Centreon)
Destinataires contacts existants et groupe à créer
États déclencheurs distincts pour l'hôte et le service
Contexte métier application, responsable, criticité, impact, procédure de reprise
Sujets pour l'hôte et pour le service, avec les macros de Centreon

Un incident sur la chaîne de facturation et un disque plein sur un serveur de rebond n'appellent ni le même destinataire, ni le même horaire, ni le même message. C'est exactement ce que le périmètre permet de séparer.

Ce qui est généré

Pour chaque périmètre :

  • deux commandes de type notif, <Périmètre>-Notify-Host et -Notify-Service ;
  • un script notifications/notif-<périmètre>.php, avec le shebang #!/usr/bin/php -c /etc/php.ini ;
  • les paramètres de notification de chaque contact : hostnotifperiod, svcnotifperiod, hostnotifopt, svcnotifopt, hostnotifcmd, svcnotifcmd ;
  • le groupe de contacts, s'il est demandé.

Et pour l'ensemble du projet, notifications/installer.sh, qui dépose les scripts sur le serveur.

Rattacher un modèle à un périmètre

C'est ce qui referme la boucle. Un modèle d'hôte ou de service porte un champ périmètre de notification ; renseigné, la génération ajoute au modèle :

HTPL;setparam;App-Facturation-custom;notifications_enabled;1
HTPL;setparam;App-Facturation-custom;notification_period;Heures-Ouvrees
HTPL;setparam;App-Facturation-custom;notification_options;d,u,r
HTPL;setparam;App-Facturation-custom;notification_interval;15
HTPL;setcontactgroup;App-Facturation-custom;CG-Facturation

Le modèle de service reçoit le même traitement, avec ses propres états déclencheurs — un service en alerte et un hôte indisponible ne se notifient pas selon les mêmes règles.

Conséquence pratique : un hôte qui hérite de App-Facturation-custom arrive dans Centreon avec sa chaîne de notification complète. Rien à reprendre à la main dans l'interface.

Installation

Les scripts ne s'installent pas tout seuls — comme le CLAPI, Enclume les écrit et vous les jouez, après relecture :

cd notifications
./installer.sh          # vérifie la syntaxe PHP, puis dépose dans le répertoire cible

Le script d'installation contrôle chaque fichier avec php -l avant de le copier, et l'installe en 0750 pour l'utilisateur du moteur de supervision.

Un agent de transport de courrier doit être en place sur la machine : le script utilise la fonction mail() de PHP, qui passe par sendmail. L'adresse d'expédition se règle par la variable d'environnement ENCLUME_EXPEDITEUR, à défaut centreon@<nom de la machine>.

Composer le corps du message

Le corps est une liste de blocs, dans l'ordre d'affichage. Quatre natures :

Bloc Ce qu'il affiche
Macro Centreon la valeur d'une macro, $NOTIFICATIONAUTHOR$, $SERVICEPERFDATA$, ou une macro personnalisée $_HOSTAPPLI$
Lien cliquable une macro contenant une URL, $SERVICENOTESURL$ par exemple, rendue en lien
Texte fixe une consigne qui ne dépend pas de l'événement, « Appeler le 3000 si non résolu en 30 minutes »
Sortie du contrôle la sortie du plugin, mise en avant en police fixe

Les blocs se définissent séparément pour l'hôte et pour le service. Tant qu'aucun n'est défini, les blocs par défaut s'appliquent — et le bouton « Composer à partir des blocs par défaut » les recopie pour servir de point de départ.

Une macro vide à l'exécution ne produit aucune ligne. Un message d'acquittement affichera donc l'auteur et son commentaire ; une notification de problème, où ces macros sont vides, n'affichera pas de lignes creuses.

Les macros personnalisées

C'est le vrai gain par rapport à un message figé. $_HOSTAPPLI$ ou $_HOSTRESPONSABLE$, définies comme macros sur l'hôte, produisent un message qui nomme l'application concernée et non celle du périmètre entier. L'éditeur propose une quarantaine de macros standard en suggestion, et accepte toute macro saisie à la main.

Voir le message avant de le déployer

Dans l'éditeur, un périmètre propose Aperçu du message, service et Aperçu du message, hôte. Le message s'affiche tel qu'il partira, avec un incident d'exemple : sujet, destinataire, mise en forme complète, plus la commande Centreon correspondante.

L'aperçu et le script PHP partagent le même gabarit HTML — celui-ci est écrit une seule fois et embarqué dans le script généré. Ce qui est montré est donc ce qui sera envoyé, et un test vérifie que les deux ne peuvent pas diverger.

Le message produit

Un message HTML avec un bandeau coloré selon l'état — vert rétabli, orange alerte, rouge critique —, un tableau des informations de l'événement, la sortie du plugin en police fixe, les champs métier du périmètre, et un lien vers la procédure de reprise quand elle est renseignée.

Toutes les valeurs passent par htmlspecialchars : la sortie d'un plugin peut contenir n'importe quoi, y compris des caractères qui casseraient la mise en page.

Ce qu'Enclume ne fait pas

Créer les contacts. Ils doivent exister sur le central, avec leur adresse de courriel. Enclume règle leurs paramètres de notification, il ne les invente pas.

Envoyer le message. Le site n'exécute rien, ici comme ailleurs.

Gérer les escalades. Elles ne sont pas exposées par CLAPI et restent à définir dans l'interface de Centreon.