Modèles, macros et découverte

01La règle d'or : ne pas modifier

Zabbix fournit plusieurs centaines de modèles maintenus par l'éditeur. Les modifier en place est tentant, et c'est la principale cause de plateformes figées : à la prochaine version, la mise à jour du modèle écrase les modifications, ou, plus souvent, personne n'ose plus le mettre à jour. Trois façons d'adapter sans toucher :

Nous organisons les modèles en trois couches : les officiels, jamais modifiés, importés depuis la version correspondante ; les modèles de politique, qui ne contiennent que des macros et lient les officiels (« Linux production », « Linux recette ») ; et les modèles métier, propres à un client ou une application.

02Macros et contextes

Les modèles officiels exposent leurs seuils sous forme de macros. Une macro définie sur l'hôte l'emporte sur celle du modèle, qui l'emporte sur la macro globale. Les macros à contexte vont plus loin : une même macro peut prendre une valeur différente selon le système de fichiers, l'interface ou le service découvert.

# seuil par defaut du modele officiel : 90 % critique
{$VFS.FS.PUSED.MAX.CRIT} = 90

# le volume de sauvegarde est fait pour etre plein
{$VFS.FS.PUSED.MAX.CRIT:"/srv/sauvegardes"} = 98

# exclure du declenchement tous les montages sous /mnt/iso
{$VFS.FS.PUSED.MAX.CRIT:regex:"^/mnt/iso"} = 101

03La découverte bas niveau

La découverte bas niveau crée automatiquement des éléments, des déclencheurs et des graphiques pour chaque disque, interface, base ou service trouvé sur l'hôte. Trois réglages font la différence entre une découverte utile et une découverte qui inonde :

• Les filtres, alimentés par des macros comme {$NET.IF.IFNAME.NOT_MATCHES}, pour écarter interfaces virtuelles et montages techniques avant qu'ils ne deviennent des éléments.
• Les surcharges, qui modifient le comportement d'un élément découvert selon son nom : désactiver un déclencheur pour les disques de sauvegarde, changer la gravité pour les interfaces de cœur de réseau.
• La gestion des ressources perdues : désactiver d'abord, après quelques heures, puis supprimer après quelques jours. Une interface qui disparaît une nuit pour maintenance ne doit pas emporter son historique.

04Superviser Proxmox VE

Le modèle officiel Proxmox VE by HTTP interroge l'API du cluster. Il découvre les noeuds, les machines virtuelles, les conteneurs et les stockages, sans aucun agent dans les invités. Il suffit d'un jeton d'API en lecture seule.

pveum user add zabbix@pve --comment "supervision Zabbix, lecture seule"
pveum acl modify / --users zabbix@pve --roles PVEAuditor
pveum user token add zabbix@pve supervision --privsep 0

Ce modèle voit le cluster tel que Proxmox le décrit : état des invités, consommation, occupation des stockages. Il ne voit pas l'intérieur des noeuds. Liez donc en plus le modèle Linux par agent actif à chaque noeud, pour les disques physiques, ZFS, la mémoire réelle et les services. Les deux se complètent sans doublon gênant.

05Superviser Ceph

Le modèle Ceph by Zabbix agent 2 s'appuie sur le greffon Ceph de l'agent 2. Ce greffon a longtemps interrogé le module RESTful du gestionnaire Ceph, et c'est précisément ce qui change : Ceph a déprécié ce module, connu pour ses fuites mémoire, puis l'a retiré avec la version 20, Tentacle. Avec Zabbix 8.0, le greffon devient un paquet séparé qui sait aussi parler à Ceph directement, par sa bibliothèque native.

apt install zabbix-agent2-plugin-ceph

# le mode natif lit la configuration et un trousseau Ceph locaux :
# reglez le mode et le compte dans la configuration du greffon,
# en suivant sa notice, puis redemarrez l'agent
systemctl restart zabbix-agent2

Un seul noeud suffit pour la vue d'ensemble du cluster Ceph : liez le modèle à l'hôte qui porte l'agent configuré, pas à chaque noeud, sous peine de recevoir chaque alerte autant de fois qu'il y a de noeuds. Pour la même raison, une dépendance vers l'hôte « cluster » Proxmox évite les doublons quand tout le cluster souffre.

06Les étiquettes, colonne vertébrale

Les groupes d'hôtes servent aux droits. Les étiquettes servent à tout le reste : filtrer les problèmes, router les alertes, construire les tableaux de bord, corréler les événements. Un schéma d'étiquettes décidé tôt et appliqué partout vaut plus que n'importe quel réglage fin.

Les étiquettes posées sur un modèle se propagent aux éléments et aux déclencheurs ; celles posées sur l'hôte s'ajoutent. L'autoregistration du chapitre 02 peut poser client et env dès la création de l'hôte.

07Éléments personnalisés

Quand aucun modèle ne couvre un besoin, un paramètre utilisateur de l'agent exécute une commande et en remonte le résultat. Restez simple : une commande rapide, une seule valeur, un nom de clé explicite.

# age en secondes du dernier fichier de sauvegarde
UserParameter=metier.sauvegarde.age,echo $(( $(date +%s) - $(stat -c %Y "$(ls -1t /srv/sauvegardes/*.tar.zst | head -1)") ))

# nombre de messages en file d'attente Postfix
UserParameter=metier.postfix.file,postqueue -j | wc -l