Dans le guide précédent, vous avez configuré le système de sauvegarde propre à Proxmox entièrement depuis le panneau de configuration, à savoir une tâche planifiée, un chemin de restauration réel et une exécution authentique de « vzdump » enregistrée de bout en bout dans son propre journal des tâches. La surveillance manuelle de ce journal ne fonctionne que tant qu'une personne a les yeux rivés sur l'écran ; ce dernier guide vient donc boucler la boucle : il s'agit d'analyser les informations que Proxmox recueille déjà sur ses propres ressources et de transformer certains événements en notifications affichées à un endroit où un utilisateur peut réellement les voir.
Consulter les graphiques de ressources intégrés
La page « Résumé » propre à chaque nœud s'ouvre sur un ensemble de chiffres en temps réel avant même qu'un seul graphique ne se charge : utilisation du processeur, charge moyenne, utilisation de la mémoire vive, espace disque disponible, délai d'E/S, partage KSM et utilisation de l'espace d'échange, tous ces chiffres étant relevés directement sur l'hôte plutôt qu'estimés. Cette même page indique également clairement sur quel matériel et quels logiciels cette plateforme fonctionne réellement, ce qui mérite d’être consulté dès le premier chargement.
La section « État du référentiel » mérite d’être lue plutôt que d’être ignorée : ce nœud signale un référentiel non prêt pour la production, à savoir celui, gratuit et sans abonnement, sur lequel l’ensemble de ce laboratoire a fonctionné depuis le tout premier guide. Il s’agit d’un avertissement réel et correctement mis en évidence, et non d’une simple remarque superficielle. Les graphiques « Heure », « Jour », « Semaine », « Mois » et « Année » affichent chacun les mêmes courbes de CPU, de mémoire, de réseau et de disque ci-dessous, avec une résolution de plus en plus grossière à mesure que la période remonte dans le temps, ce qui suffit pour repérer une fuite de mémoire lente ou un disque qui se remplit discrètement, sans avoir à recourir à aucun outil extérieur au panneau lui-même.
L'historique de ce graphique est-il conservé après un redémarrage ?
Oui. Proxmox stocke ces données au format RRD sur le disque, c'est-à-dire le même format « round-robin » que Munin et Cacti utilisent depuis des années. Ainsi, un redémarrage n'entraîne aucune perte des données déjà enregistrées et le système reprend simplement l'écriture dans le même fichier.
Acheminer les événements réels vers une notification réelle
Un graphique n'est utile qu'à ceux qui le consultent réellement ; c'est pourquoi Proxmox propose un système de notifications totalement distinct : « Datacenter », « Notifications », répartis en deux listes qui fonctionnent de concert, plutôt qu'une longue page de paramètres.
Regardez ce qui est déjà câblé
Un nouveau nœud dispose déjà des deux moitiés configurées, en arrière-plan, avant même que quiconque n'accède à cette page : une cible et un comparateur, tous deux marqués comme « intégrés » plutôt que comme ayant été ajoutés par un utilisateur.
« mail-to-root », la cible, est une entrée sendmail pointant vers l'adresse vers laquelle « root@pam » est effectivement résolu. default-matcher, le module de correspondance, est délibérément non spécifique : il correspond à tout et achemine tout vers cette seule cible, ce qui explique précisément pourquoi l’exécution de vzdump décrite dans le guide précédent n’a jamais nécessité de configuration de notification pour disposer d’un emplacement où signaler un échec.
Ajouter une destination Webhook
L'e-mail fonctionne, mais c'est rarement là que l'opérateur surveille réellement ce à quoi il doit réagir en temps réel. L'option « Ajouter » de la barre d'outils « Cibles de notification » propose également Gotify, SMTP et Webhook, et c'est ce dernier qui permet d'atteindre n'importe quelle destination : toute URL acceptant une requête POST, avec un contrôle total sur les en-têtes, le corps du message et les secrets.
Aucun élément de ce formulaire ne présuppose l'existence d'un service spécifique à l'autre bout. La section « Headers » permet d'indiquer une clé API ou de redéfinir le type de contenu ; la section « Body » est un modèle libre permettant d'adapter le format JSON aux attentes du destinataire ; enfin, la section « Secrets » permet de conserver un jeton en dehors du champ « Body » lui-même, afin qu'il n'apparaisse jamais par inadvertance dans un journal des tâches ou une piste d'audit.
Acheminer les événements spécifiques à cet itinéraire vers celui-ci
Un « matcher » détermine quels événements parviennent effectivement à une cible donnée, en s'appuyant sur des règles qui s'apparentent à des filtres de recherche. Le champ « Field », au sein d'une règle, propose exactement cinq types d'événements réels, chacun étant lié à une partie spécifique de Proxmox plutôt qu'à un niveau de gravité fictif :
- vzdump : notifications de sauvegarde ; c'est précisément la catégorie à laquelle appartiendrait une tâche ayant échoué, comme celle décrite dans le guide précédent.
- réplication : notifications relatives aux tâches de réplication, qui s'appliquent dès qu'un deuxième nœud rejoint ce cluster.
- fencing : notifications relatives au fencing des nœuds, liées à la haute disponibilité (HA) et qu'il convient de rediriger vers un emplacement bien visible dès qu'une configuration de basculement réelle est en place.
- package-updates : une simple notification indiquant que des mises à jour sont disponibles, qui s'apparente davantage à un résumé qu'à un incident.
- system-mail : tout ce que le système enverrait autrement par e-mail à l'utilisateur local ; il s'agit d'un « fourre-tout » plutôt que d'un événement spécifique.
En nommant ce « matcher » « backup-alerts » et en cochant « ops-webhook » dans l’onglet « Notifier » de ses cibles, plutôt que de remplacer purement et simplement le « default-matcher », les deux règles fonctionnent désormais en parallèle : un événement « vzdump » est spécifiquement acheminé vers « ops-webhook », tandis que « default-matcher » continue de tout intercepter, y compris les notifications de sauvegarde, et continue d’envoyer des e-mails à « root@pam » comme auparavant. L’empilement de plusieurs matchers de cette manière est la pratique courante dès lors que le nombre d’alertes dépasse le cadre d’une seule règle fourre-tout.
Avant de mettre en production un nouveau module de correspondance, veillez à lui faire passer au préalable un véritable événement de test. La fonction « Tester », disponible dans la barre d'outils « Cibles de notification », déclenche immédiatement une véritable notification vers la cible sélectionnée. C'est le moyen le plus rapide de vérifier qu'un point de terminaison de webhook reçoit bien ce que cette boîte de dialogue promet, avant qu'une véritable panne de sauvegarde ne vienne mettre cela en évidence.
Indicateurs d'exportation pour des tableaux de bord concrets et des seuils d'alerte
Les graphiques intégrés répondent bien à la question « que s'est-il passé ? », du moins pour ceux qui pensent à les consulter. Ils ne permettent toutefois pas d'envoyer une alerte « dès que l'utilisation du processeur reste supérieure à 90 % pendant cinq minutes », car Proxmox ne dispose pas en soi de notion de seuil de métrique. C’est précisément cette lacune que Metric Server, situé plus haut dans le même menu « Datacenter », est censé combler : un flux en temps réel de toutes les métriques déjà collectées par ce panneau, transmis à un outil spécialement conçu pour cette tâche.
Graphite et InfluxDB sont les deux solutions bien établies, toutes deux associées depuis longtemps à Grafana pour ce type précis de tableau de bord ; OpenTelemetry est une solution plus récente et indépendante des éditeurs, qui repose sur le même protocole que celui adopté par un nombre croissant de piles d'observabilité, quelle que soit la base de données qui les sous-tend.
Une fois que les métriques sont enregistrées dans une base de données de séries chronologiques en temps réel, les alertes de seuil ne constituent plus du tout une limitation de Proxmox : les règles d’alerte propres à Grafana, ou tout autre outil capable d’interroger InfluxDB ou Graphite, prennent le relais à partir de là, en surveillant exactement les mêmes chiffres que ce guide a observés à l’œil nu sur la page « Résumé » tout au long de ce guide.
En résumé
- Les pages de synthèse des nœuds et des centres de données permettent de suivre l'historique de l'utilisation du processeur, de la mémoire, du réseau et des disques sur une période pouvant aller jusqu'à un an ; aucun outil supplémentaire n'est nécessaire pour obtenir un aperçu rapide.
- Le système de notification distingue les cibles, vers lesquelles une alerte est envoyée, des filtres, qui déterminent les événements à acheminer vers celles-ci, et ces deux éléments peuvent s'empiler.
- Une destination de webhook peut pointer vers n'importe quelle URL, qu'il s'agisse de Slack, Discord, PagerDuty ou d'un tableau de bord interne.
- C'est l'exportation des données de Metric Server vers Graphite, InfluxDB ou OpenTelemetry qui permet en réalité de mettre en place des alertes basées sur des seuils, au-delà de ce que Proxmox suit de manière native.
Le trafic transitant par le tunnel évoqué plus haut dans ce guide présente lui aussi un intérêt particulier, comme l'explique Taipan dans son propre référence en matière de mesure de la bande passante.