Configurer des alertes et des notifications sur un superviseur

1. Introduction à la supervision et aux alertes

1.1 Qu'est-ce que la supervision ?

La supervision (ou monitoring) consiste à surveiller en temps réel l'état de santé et les performances d'un parc informatique (serveurs, services, équipements réseau, applications, etc.). L'objectif est de détecter rapidement toute anomalie ou dégradation de service avant qu'elle ne devienne critique pour l'entreprise.

1.2 Rôle des alertes et notifications

Les alertes sont des signaux émis par l'outil de supervision lorsque certains indicateurs (metrics) dépassent un seuil prédéfini. Les notifications informent ensuite les équipes concernées via différents canaux (e-mail, SMS, webhook, intégration ITSM, etc.), afin qu'elles puissent réagir rapidement.

Ces alertes et notifications reposent sur la configuration de seuils et sur une logique de déclenchement (trigger) adaptée au contexte technique et métier.

2. Paramétrage des seuils et déclenchement des alertes

2.1 Les seuils de supervision (WARNING, CRITICAL, etc.)

Dans la plupart des outils de supervision (Nagios, Centreon, Zabbix, Icinga, etc.), on retrouve souvent les mêmes conventions de seuils :

• OK : le service ou la métrique surveillée est dans un état normal.
• WARNING : la métrique a dépassé un seuil d'avertissement (avertit qu'un problème potentiel apparaît).
• CRITICAL : la métrique a dépassé un seuil critique (le service est fortement dégradé ou totalement indisponible).
• UNKNOWN ou UNREACHABLE : l'outil ne parvient pas à déterminer l'état exact (problème de communication ou métrique non disponible).

Exemple : seuils de supervision CPU

• OK : moins de 70 % d'utilisation CPU
• WARNING : entre 70 % et 85 % d'utilisation CPU
• CRITICAL : plus de 85 % d'utilisation CPU

Cela permet de détecter en amont une surcharge éventuelle (en WARNING) avant qu'elle ne devienne critique (CRITICAL).

2.2 Comment définir les bons seuils ?

La configuration des seuils doit être adaptée à l'environnement et aux exigences de l'entreprise. Pour les définir :

• Identifier les métriques pertinentes : CPU, RAM, Espace disque, disponibilité d'un service, temps de réponse, etc.
• Connaître le comportement normal : par exemple, certains serveurs peuvent monter régulièrement à 80 % de CPU sans impact négatif. Il est essentiel de connaître les pics habituels.
• Définir des valeurs de WARNING et de CRITICAL cohérentes :
  • Le seuil WARNING doit être atteint avant que l'état réel de CRITICAL ne s'installe, pour donner le temps de réagir.
  • Le seuil CRITICAL doit traduire un état d'urgence qui nécessite une intervention immédiate.
• Ajuster régulièrement les seuils : avec l'évolution de l'infrastructure et des applications, il peut être nécessaire de recalibrer les valeurs définies.

2.3 Déclenchement (trigger) d'une alerte

Une alerte est déclenchée lorsque la valeur mesurée dépasse (ou repasse en-dessous, selon la logique) l'un des seuils configurés.

• Exemple Nagios/Centreon : on définit dans un fichier de configuration (ou via l'interface dans Centreon) les warnings et criticals sous forme d'intervalle ou de limite (ex. -w 70 -c 85 pour un plugin qui mesure la CPU).
• Exemple Zabbix : on définit des Triggers basés sur des expressions logiques (ex. {Template OS Linux:system.cpu.util[].last()}>85 pour un CRITICAL).

Dans chaque cas, si la métrique se situe dans la plage WARNING ou CRITICAL, le logiciel change l'état du service et génère l'alerte correspondante.

Durée et hystérésis

Certains outils permettent de configurer un hystérésis ou une durée minimum avant de changer d'état. Cela évite les alertes intempestives en cas de fluctuations très ponctuelles. Par exemple, ne générer une alerte CRITICAL que si la métrique reste au-dessus de 85 % pendant plus de 5 minutes.

3. Mécanismes de notification

Une fois l'état d'un service détecté comme étant en WARNING ou CRITICAL, l'outil doit notifier les personnes ou systèmes appropriés. Plusieurs canaux de notification sont généralement disponibles.

3.1 Notification par e-mail

C'est la méthode la plus courante. Les avantages :

• Facilité de mise en place (les outils de supervision disposent généralement d'options SMTP intégrées).
• Possibilité d'envoyer des détails (logs, graphiques, contexte) dans le corps du message.

Configuration de base :

• Définir un serveur SMTP et les informations d'authentification (si besoin).
• Associer aux services supervisés un ou plusieurs contacts (adresses e-mail).
• Choisir le niveau d'alerte pour lequel l'envoi d'un e-mail est déclenché (WARNING, CRITICAL, etc.).

3.2 Notification par SMS

Les SMS sont utiles pour alerter en cas de criticité élevée ou en dehors des heures de bureau, lorsque l'email pourrait être manqué.

Méthodes courantes :

• Passerelle GSM : un modem GSM connecté au serveur de supervision (à l'aide d'outils comme gammu ou smstools).
• Gateway SMS en ligne : envoi via l'API d'un fournisseur de SMS (OVH, Twilio, etc.).

Dans l'outil de supervision, on configure le script ou l'API pour émettre un SMS lorsque la condition CRITICAL (ou WARNING) est atteinte.

3.3 Webhooks et intégrations avancées

Les webhooks sont des appels HTTP envoyés à un endpoint externe lorsqu'un événement se produit. Ils permettent d'intégrer la supervision avec :

• Des outils de ChatOps (ex. Slack, Microsoft Teams, Mattermost).
• Des systèmes de notification centralisés (ex. PagerDuty, Opsgenie).
• Des outils de dashboards ou d'automatisation (ex. StackStorm, Ansible Tower).

La configuration d'un webhook consiste généralement à spécifier :

• L'URL à appeler.
• Les paramètres à transmettre dans la requête (type d'événement, niveau d'alerte, nom de l'hôte/service, etc.).
• Le type de requête (POST, GET, etc.).

3.4 Intégration avec des outils de ticketing

Beaucoup d'entreprises utilisent un outil de ticketing (ex. GLPI, ServiceNow, Jira Service Management, OTRS, etc.). L'idée est de créer automatiquement un ticket dans l'outil lorsqu'une alerte survient.

Méthodes courantes :

• Plugin / Connecteur natif : certains outils de supervision disposent de connecteurs prêts à l'emploi pour ServiceNow, Jira, etc.
• Webhook ou API : le système de monitoring envoie une requête à l'API de l'outil de ticketing pour créer/mettre à jour un ticket.
• E-mail to ticket : l'outil de ticketing peut transformer automatiquement un e-mail reçu en ticket.

Lorsqu'une alerte CRITICAL est détectée, on peut ainsi générer un ticket avec un résumé du problème et un lien vers la plateforme de supervision pour diagnostiquer plus en détail.

4. Bonnes pratiques pour la configuration des alertes et notifications

• Limiter le bruit : Éviter de trop générer d'alertes non critiques. Sinon, l'équipe risque de les ignorer ou de se noyer dans le flux.
• Définir clairement les responsabilités : Quel groupe reçoit les alertes ? Qui est d'astreinte ? Quelles sont les procédures d'escalade ?
• Escalade et priorisation : Mettre en place différents niveaux d'alerte (support N1, N2, N3) ou des plages horaires.
• Regrouper les alertes répétitives : Certains outils (Zabbix, Centreon) permettent de corréler les événements pour éviter d'envoyer trop d'e-mails ou SMS.
• Ajuster régulièrement les seuils : Les seuils définis un jour peuvent ne plus être pertinents quelques mois plus tard avec l'évolution de la charge ou de l'infrastructure.
• Prévoir des tests : Tester périodiquement les scénarios d'alerte (simulation d'un disque plein, arrêt d'un service, etc.) pour valider que les notifications arrivent bien.

5. Comparatif rapide sur la configuration dans Nagios, Centreon et Zabbix

5.1 Nagios

• Configuration via des fichiers texte (fichiers .cfg) : définition des services, contacts, commandes, hostgroups, etc.
• Les seuils sont souvent passés en paramètre aux plugins Nagios, par exemple :

define service {
use generic-service
host_name MonServeur
service_description Check CPU
check_command check_nrpe!check_cpu!70!85
...
}

• Ici, 70 correspond au WARNING et 85 au CRITICAL.
• Les notifications (emails, SMS) sont définies dans la section contacts et contactgroups.

5.2 Centreon

• Interface Web qui facilite la gestion et la configuration, s'appuie sur Nagios en backend (historiquement, Centreon Engine est un fork de Nagios).
• Modèles de services (templates) où l'on spécifie les seuils en paramètres.
• Notifications configurées dans la partie Configuration > Notification, où l'on assigne les contacts et définit les canaux (mail, SMS, etc.).
• Possibilité d'intégrer des modules additionnels et de configurer des escalades.

5.3 Zabbix

• Interface Web centrale et base de données pour stocker les données et la configuration.
• Utilisation d'items (métriques) et de triggers (conditions) :
  {NomHôte:system.cpu.util[].last()} > 85
• Notifications (Actions) : on définit des actions qui se déclenchent lorsqu'un trigger passe en état PROBLEM. L'action peut envoyer un e-mail, un SMS ou appeler un webhook.
• Gestion d'escalade native (règles d'envoi de notification différents selon l'ancienneté ou la criticité).

6. Conclusion

La configuration des alertes et notifications est un élément crucial pour garantir une supervision efficace. Les seuils (WARNING, CRITICAL, etc.) doivent être soigneusement calibrés pour refléter la réalité de l'environnement surveillé. Les notifications doivent être adaptées aux besoins de l'organisation : un simple e-mail pour un WARNING peut suffire, tandis qu'un CRITICAL en pleine nuit peut nécessiter un SMS ou la création immédiate d'un ticket.

Points clés à retenir :

• Définir des métriques et des seuils réalistes.
• Choisir des canaux de notification appropriés et éviter le bruit (trop d'alertes non pertinentes).
• Mettre en place des processus d'escalade clairs pour s'assurer que les problèmes sont traités rapidement.
• Tester régulièrement la configuration des alertes pour éviter les mauvaises surprises.