Supervision avec Zabbix

Un problème que personne ne voit ne sert à rien. Un problème que tout le monde reçoit à 3 h du matin pour un disque à 81 % est pire : au bout d'une semaine, plus personne ne lit les alertes. Ce chapitre configure l'envoi des alertes, puis montre comment éviter qu'elles deviennent du bruit.

Trois pièces : media type, média utilisateur, action

L'envoi d'une alerte passe par trois réglages à des endroits différents de l'interface. C'est déroutant au début.

Un oubli dans l'une des trois, et rien ne part. Le premier réflexe de débogage est Reports > Action log, qui liste chaque envoi tenté et son erreur.

Les media types

Zabbix 7.0 livre une quarantaine de media types prêts à l'emploi : e-mail, Slack, Microsoft Teams, Telegram, Discord, Mattermost, PagerDuty, Opsgenie, Jira, ServiceNow, et bien d'autres. Ils sont désactivés par défaut. On les active et on remplit leurs paramètres.

E-mail

Dans le media type Email, renseignez votre serveur SMTP, son port, la sécurité (STARTTLS sur le port 587 en général) et l'authentification. Le bouton Test envoie un message sans passer par une action : utilisez-le avant toute autre chose.

Telegram

Le media type Telegram demande un jeton de bot, obtenu auprès de @BotFather. Sur la fiche de l'utilisateur, le champ Send to reçoit l'identifiant de la conversation ou du groupe.

Un webhook maison : ntfy

Quand un canal n'existe pas, un media type de type Webhook l'ajoute en quelques lignes de JavaScript, exécutées par le serveur Zabbix. Exemple avec ntfy, le service de notifications push auto-hébergeable :

Paramètres du media type :

Script :

var params = JSON.parse(value);
var priorities = ['1', '2', '3', '3', '4', '5'];
 
var request = new HttpRequest();
request.addHeader('Title: ' + params.subject);
request.addHeader('Priority: ' + (priorities[parseInt(params.severity)] || '3'));
request.addHeader('Tags: warning');
 
var response = request.post(params.url, params.message);
 
if (request.getStatus() !== 200) {
    throw 'ntfy a répondu ' + request.getStatus() + ' : ' + response;
}
 
return 'OK';

{EVENT.NSEVERITY} vaut 0 pour « Not classified » et 5 pour « Disaster ». Le tableau priorities traduit la sévérité Zabbix en priorité ntfy : un « Disaster » réveille le téléphone, une « Information » reste silencieuse.

Les messages

Le contenu des alertes se règle dans l'onglet Message templates du media type, avec des macros :

Sujet : [{EVENT.SEVERITY}] {HOST.NAME} : {EVENT.NAME}
 
Problème démarré à {EVENT.TIME} le {EVENT.DATE}
Hôte : {HOST.NAME} ({HOST.IP})
Sévérité : {EVENT.SEVERITY}
Valeur : {ITEM.LASTVALUE1}
Tags : {EVENT.TAGS}
 
{TRIGGER.URL}

Le message de rétablissement utilise {EVENT.RECOVERY.TIME} et {EVENT.DURATION}. Un bon message permet de juger de la gravité sans ouvrir l'interface. Un lien vers une procédure, renseigné dans le champ URL du trigger et affiché par {TRIGGER.URL}, fait gagner de précieuses minutes en pleine nuit.

Les actions

Une action de trigger combine des conditions et des opérations. On en crée une par politique d'alerte, pas une par trigger.

Conditions

Les tags sont le meilleur outil de routage. Un tag équipe:base-de-données posé sur les templates PostgreSQL permet une action « équipe base de données » sans maintenir de liste d'hôtes.

Opérations et escalades

Une action envoie ses messages par étapes. Chaque étape a un délai, et les étapes suivantes ne s'exécutent que si le problème est toujours ouvert et non acquitté.

Cochez Pause operations for symptom problems et Pause operations for suppressed problems, et dans les opérations d'escalade, la condition Event is not acknowledged. Ainsi, dès que quelqu'un acquitte le problème, l'escalade s'arrête.

L'onglet Recovery operations envoie le message de rétablissement. L'onglet Update operations notifie quand quelqu'un acquitte, commente ou change la sévérité d'un problème : utile pour que toute l'équipe sache qu'un collègue s'en occupe.

Acquitter un problème

Dans Monitoring > Problems, un clic sur Update d'un problème permet de l'acquitter, d'ajouter un message, de changer sa sévérité, de le supprimer temporairement ou de le fermer manuellement si le trigger l'autorise.

Acquitter, c'est dire « je l'ai vu, je m'en occupe ». L'acquittement arrête les escalades et apparaît dans l'historique du problème. Prenez l'habitude d'y écrire une ligne sur ce que vous avez fait : c'est la mémoire de l'astreinte.

Les maintenances

Avant une mise à jour ou un redémarrage planifié, déclarez une maintenance dans Data collection > Maintenance : période, hôtes ou groupes, et éventuellement des tags pour ne couvrir que certains problèmes.

Le premier type est presque toujours le bon : on garde les graphiques de la maintenance, et si le problème persiste à la fin de la période, l'alerte part. Les maintenances se créent aussi par l'API, ce qu'on verra au chapitre 7 pour les intégrer à un déploiement automatisé.

Combattre la fatigue d'alerte

Une supervision qui crie tout le temps n'est plus écoutée. Quelques règles que j'applique systématiquement :

1. Chaque alerte doit appeler une action. Si la réponse à une alerte est « ah oui, c'est normal », le trigger est faux ou la sévérité trop haute.
2. Router par sévérité. Information et Warning vont dans un tableau de bord ou un canal de discussion lu en journée. Seuls High et Disaster réveillent quelqu'un.
3. Mesurer dans la durée. min(...,10m) plutôt que last() sur tout ce qui fluctue.
4. Déclarer les dépendances. Une panne réseau doit produire une alerte, pas cinquante.
5. Relire chaque mois. Reports > Top 100 triggers liste les triggers les plus bavards. Chacun d'eux est soit un vrai problème à corriger, soit un seuil à revoir.

Les alertes sont la partie visible de la supervision, celle sur laquelle l'équipe la juge. Elles méritent autant de soin que la collecte. Le chapitre suivant étend la supervision au-delà des serveurs Linux : équipements réseau en SNMP, sites web, bases de données, et sites distants via les proxies.