Ma femme a été plus rapide que ma supervision : Zabbix en conteneurs surveille désormais mon réseau domestique

En bref : il y a un peu plus de deux semaines, ma femme est rentrée à la maison et n’avait pas de Wi-Fi. Le point d’accès du rez-de-chaussée ne répondait même plus au ping. Débrancher, rebrancher, et tout fonctionne depuis. Personne d’autre ne l’avait remarqué, pas même ma supervision. Désormais, un Zabbix 7.0 LTS tourne dans quatre conteneurs Podman rootless sur mon serveur NAS et m’envoie un mail dès qu’un composant du réseau domestique ne répond plus. Cet article décrit le montage, ce que j’ai dû configurer en plus, là où ça a coincé et où trouver quoi dans l’interface web.

📶 Comment tout a commencé

Ma femme est rentrée, son téléphone n’affichait aucun Wi-Fi, et elle n’était – on la comprend – pas ravie. J’ai pu le confirmer tout de suite : le point d’accès du rez-de-chaussée était injoignable, ni par son interface web, ni par ping. Débrancher, attendre quelques secondes, rebrancher. Depuis environ 14 jours, il tourne sans le moindre souci. Pourquoi il a décroché, je ne le sais toujours pas. C’est un de ces phénomènes qui arrivent une fois et refusent de se reproduire.

Ce qui m’a bien plus occupé, c’est autre chose : pourquoi l’ai-je appris par ma femme et pas par ma supervision ? La réponse est simple. Prometheus et Grafana surveillent mes serveurs, et un contrôle de disponibilité vérifie toutes les cinq minutes depuis l’extérieur que le blog et Nextcloud répondent. Personne ne regardait les petits boîtiers du réseau domestique – routeur, répéteurs, switch, base téléphonique, onduleur photovoltaïque. Ils n’ont pas d’agent ; on peut seulement leur demander s’ils répondent.

À retenir : une supervision couvre exactement ce pour quoi on l’a construite. Les trous se trouvent souvent du côté des appareils discrets qui fonctionnent, tout simplement – jusqu’au jour où ils ne fonctionnent plus.

🔭 Qu’est-ce que Zabbix ?

Zabbix est un logiciel de supervision open source : il surveille en continu serveurs, équipements réseau, applications et services. Alexei Vladishev l’a commencé en 2001 comme outil interne, la version 1.0 est sortie en 2004. Aujourd’hui, il est développé par la société Zabbix SIA à Riga, en Lettonie. Le logiciel est entièrement libre – il n’existe pas d’« édition entreprise » payante qui retiendrait des fonctions ; l’entreprise vit du support, des formations et des certifications. Jusqu’à la version 6.4, Zabbix était sous GPLv2, depuis la 7.0 sous AGPLv3. Une version LTS paraît tous les dix-huit mois et est maintenue cinq ans.

Ce qui fait la réputation de Zabbix :

• Tout-en-un. Collecte, stockage, règles d’alerte, notifications, tableaux de bord, cartes et rapports se trouvent dans un seul produit avec une seule interface web. Avec Prometheus et Grafana, ce sont plusieurs outils qu’on assemble soi-même.
• Avec ou sans agent. L’agent Zabbix (aujourd’hui surtout l’Agent 2, écrit en Go et extensible par plugins) mesure systèmes et applications de l’intérieur. Pour les appareils sur lesquels on ne peut rien installer, il existe des contrôles sans agent : ping, ports TCP, HTTP, SNMP, IPMI, SSH et d’autres.
• Réseau et SNMP. Zabbix est particulièrement répandu dès qu’il s’agit de switchs, routeurs, pare-feu, onduleurs et imprimantes. Il existe des modèles prêts à l’emploi pour d’innombrables appareils.
• Modèles et découverte automatique. Un modèle regroupe contrôles, alertes et graphiques. Grâce à la découverte bas niveau (low-level discovery), Zabbix trouve lui-même quels systèmes de fichiers, cartes réseau ou disques possède un appareil et crée les contrôles correspondants.
• Grands environnements. Des proxys répartissent la supervision sur de nombreux sites ; Zabbix est conçu pour des dizaines de milliers d’appareils.
• Une API complète. Tout ce que fait l’interface passe aussi par JSON-RPC – j’ai créé toute la configuration de cet article par script via l’API.

Où l’on croise Zabbix : chez les fournisseurs d’accès et les opérateurs télécoms, dans les centres de données, les banques, les administrations et les universités, dans beaucoup de services informatiques de PME – partout où un paysage hétérogène de serveurs, d’équipements réseau et d’appareils spécialisés doit être surveillé depuis un seul endroit.

Le revers : Zabbix est puissant, et son interface le montre. La configuration vit dans la base de données plutôt que dans des fichiers texte, ce qui rend la « configuration en tant que code » plus difficile qu’avec Prometheus. Et le vocabulaire – host, item, trigger, template, action – doit être assimilé une fois avant que tout prenne sens.

Au passage : juste après l’installation, la carte du tableau de bord montrait Riga – c’est là que se trouve Zabbix.

À retenir : Zabbix est le couteau suisse des outils de supervision. Il montre toute sa force avec beaucoup d’appareils différents qui n’ont pas d’agent propre.

🎯 L’objectif et pourquoi Zabbix

L’exigence était volontairement modeste : un mail quand un composant interne ne répond plus. Pour des appareils sans agent, cela veut dire un ping là où l’appareil répond au ping, et un test de connexion TCP sur un port comme 80 ou 443 là où il possède une interface web.

S’y est ajouté un second souhait : je veux aussi savoir quand Internet lui-même est coupé – et recevoir alors un seul mail « Internet injoignable » plutôt que cinq alertes séparées, une par serveur externe.

Un petit script pourrait faire l’affaire. J’ai quand même choisi Zabbix, pour deux raisons. D’abord, Zabbix fournit exactement ces contrôles sans agent, avec historique, graphiques, dépendances entre alertes et envoi de mails. Ensuite, par intérêt professionnel, je veux acquérir davantage d’expérience pratique avec Zabbix – le monter moi-même, le configurer moi-même, me tromper moi-même, au lieu de seulement lire à son sujet. Le réseau domestique est un terrain d’entraînement idéal : assez réel pour avoir du sens, assez petit pour qu’une erreur ne fasse pas mal.

J’ai choisi Zabbix 7.0 LTS (7.0.32). La version 8.0.0 venait de sortir, mais je n’ai pas besoin d’essuyer les plâtres d’une version point zéro pendant que j’apprends l’outil.

À retenir : pour découvrir un nouvel outil, un vrai petit problème vaut mieux qu’une démo. Et une version LTS retire une inconnue de l’équation.

🧱 Le montage : quatre conteneurs, pas de root

Zabbix tourne sur HP3, mon serveur NAS sous Debian avec ZFS. Il fonctionne de toute façon jour et nuit et dispose de bonnes réserves (4 cœurs, 32 Go de RAM, dont plus d’un tiers libre). Le montage se compose de quatre conteneurs :

Les décisions importantes derrière ce choix :

• Podman rootless plutôt que Docker en root. Tout tourne sous mon utilisateur normal ; une erreur dans un conteneur n’atterrit pas en root sur le NAS.
• Quadlet plutôt que Compose. Chaque conteneur est un petit fichier .container dans ~/.config/containers/systemd/. Podman en fait des services systemd ordinaires – avec dépendances, redémarrage en cas de plantage et démarrage au boot. Pour que des services utilisateur démarrent sans connexion, il faut une fois loginctl enable-linger.
• Réseau de l’hôte plutôt que NAT. Avec Network=host, pings et tests TCP vont directement dans le réseau domestique, sans la traduction d’adresses de Podman. PostgreSQL n’écoute en revanche explicitement que sur 127.0.0.1.
• Limites fixes de mémoire et de CPU, pour que Zabbix ne gêne jamais le NAS. En pratique, les quatre conteneurs ensemble utilisent environ 180 Mo.
• Pas de mots de passe dans des fichiers. Le mot de passe de la base est un secret Podman transmis aux conteneurs sous forme de fichier, et j’ai changé le mot de passe admin de l’interface via l’API juste après le premier démarrage.

Voici le fichier du serveur :

[Unit]
Description=Zabbix server
Requires=zabbix-db.service
After=zabbix-db.service

[Container]
ContainerName=zabbix-server
Image=docker.io/zabbix/zabbix-server-pgsql:alpine-7.0.32
Network=host
Environment=DB_SERVER_HOST=127.0.0.1 POSTGRES_USER=zabbix POSTGRES_DB=zabbix
Environment=POSTGRES_PASSWORD_FILE=/run/secrets/zabbix-db-pw
Secret=zabbix-db-pw
AddCapability=NET_RAW
PodmanArgs=--memory=768m --cpus=1

[Service]
Restart=always

[Install]
WantedBy=default.target

À retenir : Quadlet transforme des conteneurs en services systemd tout à fait ordinaires. Pas besoin d’orchestrateur, et systemctl --user status montre tout au même endroit.

💾 Où mettre la base de données ?

Une question évidente : la base va-t-elle sur le SSD système ou dans le pool ZFS, qui sert normalement aux partages de fichiers ? J’ai choisi le pool. HP3 ne contient que des SSD, y compris les trois disques du RAIDZ1 – la vitesse n’est donc pas un argument contre le pool. En échange, la base y survit à la perte d’un disque, ZFS détecte les blocs endommagés grâce aux sommes de contrôle, et le répertoire se trouve dans mon dataset personnel, que le PC de sauvegarde copie de toute façon la nuit. Le SSD système a plus de 400 Go libres, mais c’est un disque unique et il n’est pas sauvegardé.

Les volumes restent modestes : après le premier jour, la base fait moins de 100 Mo. Un dataset ZFS dédié avec une taille de bloc adaptée à PostgreSQL serait plus propre, mais il faut root – inutile à cette échelle.

À retenir : le disque le plus rapide n’est pas forcément le bon. Pour une base de données, redondance et sauvegarde comptent plus que les derniers pourcents de performance.

📡 Ce qui est surveillé

Dans Zabbix, le réseau est réparti en deux groupes d’hôtes : LAN pour les appareils de la maison et Extern pour mes serveurs au centre de données.

Dans le LAN, Zabbix vérifie chaque minute :

• Le ping pour le routeur, les trois répéteurs Wi-Fi, le switch, la base téléphonique, la VMC, l’onduleur photovoltaïque et deux prises connectées. Zabbix fournit pour cela le modèle ICMP Ping. Il signale un appareil comme injoignable quand trois pings de suite restent sans réponse – donc au bout d’environ trois minutes. Un ping perdu isolé ne déclenche pas d’alerte.
• Un port TCP en plus, là où tourne une interface web : 443 pour le routeur et le switch, 80 pour la VMC et l’onduleur. La clé est net.tcp.service[tcp,<ip>,<port>], et cette alerte aussi ne se déclenche qu’après trois échecs.
• Uniquement TCP 443 pour les trois contrôleurs de gestion à distance des serveurs (BMC). Ils sont dans le même réseau, mais ce qui compte, c’est que leur interface réponde.

Un détail que je n’aurais pas eu sans Zabbix : l’alerte de port dépend de l’alerte de ping. Si un appareil tombe complètement, je reçois un mail (« injoignable par ping ICMP ») et pas deux. L’alerte de port ne se manifeste que si l’appareil répond au ping mais pas son interface web.

HP3 lui-même est mesuré par l’Agent 2 : CPU, RAM, charge, swap, processus, chaque carte réseau, les datasets ZFS et les entrées-sorties des quatre SSD. Le modèle Linux by Zabbix agent couvre tout cela, et Zabbix crée les graphiques tout seul.

Les serveurs externes – le blog et deux instances Nextcloud – sont vérifiés par des scénarios web : une requête toutes les deux minutes, avec HTTP 200 et un contenu précis attendus. Pour le blog, c’est la fin de la page d’accueil ; pour Nextcloud, status.php doit contenir "maintenance":false ; pour Collabora, la découverte WOPI doit répondre. En plus, l’agent lit les certificats TLS toutes les six heures et prévient 14 jours avant leur expiration.

Internet lui-même est vérifié par un hôte dédié nommé « Internet » : chaque minute, il envoie un ping à deux serveurs DNS publics indépendants (1.1.1.1 et 9.9.9.9) et appelle https://www.google.com/generate_204, une adresse prévue exactement pour ce genre de test de connectivité, qui ne renvoie que « 204 No Content ». L’alerte « Internet injoignable » ne se déclenche que si les deux serveurs restent muets trois fois de suite – une panne chez un seul fournisseur n’est pas une coupure d’Internet. Les alertes des serveurs externes en dépendent : si Internet est coupé, un seul mail arrive.

Je ne vérifie volontairement pas SSH ni les ports ouverts de ces serveurs. Une simple connexion au port 22 sans authentification finit dans le journal de sshd, et fail2ban peut en faire un bannissement de ma propre IP domestique. Un test rapide de plusieurs ports déclencherait le blocage anti-scan du pare-feu. Une requête HTTPS toutes les deux minutes, en revanche, est un visiteur tout à fait normal.

À retenir : de bonnes alertes sont économes. Trois échecs au lieu d’un et des dépendances entre alertes garantissent qu’un mail veut vraiment dire quelque chose.

🐛 Les pièges

Pas de montage sans surprises. Celles-ci ont été instructives :

1. Le ping ne marchait pas du tout au début. Chaque contrôle se terminait par sh: /usr/sbin/fping: Operation not permitted. Dans l’image du serveur, fping porte la capacité de fichier cap_net_raw=ep. Si cette capacité manque dans le conteneur, le noyau refuse déjà de lancer le programme – pas seulement le ping. La solution tenait en une ligne : AddCapability=NET_RAW dans le fichier Quadlet du serveur.
2. Un point d’exclamation dans le nom d’hôte. Zabbix refuse « FRITZ!Box » comme nom d’hôte. Le nom technique n’autorise que lettres, chiffres, espaces, points, tirets bas et tirets. C’est pourquoi Zabbix distingue le nom technique du visible name – c’est le second qui s’affiche partout.
3. Une IP « libre » ne l’était pas. Pour le test de mail, je voulais simuler une panne et j’ai fait pointer un appareil de test vers une adresse qui n’avait pas répondu lors de mon scan. Zabbix a alors signalé 66 % de perte de paquets – il y avait bien quelque chose, qui répondait juste de manière aléatoire. Pour les tests, j’utilise depuis une adresse de la plage de documentation (192.0.2.1, RFC 5737), qui ne répond jamais.
4. Un Zabbix fraîchement installé n’envoie aucun mail. L’action qui signale les problèmes aux administrateurs est désactivée d’usine, et l’utilisateur admin n’a pas d’adresse mail. Sans ces deux étapes, tout est vert et pourtant aucune alerte n’arrive jamais.
5. L’agent en conteneur ne voit pas automatiquement l’hôte. CPU, RAM, réseau et statistiques disque viennent de toute façon du noyau de l’hôte. Pour les systèmes de fichiers, j’ai monté la racine de l’hôte en lecture seule sous /hostfs et n’ai autorisé, via une macro, que les vrais systèmes de fichiers ; sinon les montages overlay internes de Podman apparaissent. L’agent n’a trouvé les disques qu’une fois les fichiers de périphérique /dev/sda à /dev/sdd visibles dans le conteneur – il ne lit pourtant que /proc/diskstats.
6. Fuseau horaire et format de l’heure. L’interface était en UTC et affichait « 03:26 PM ». Sous Administration → General → GUI, j’ai réglé Europe/Berlin et le format 24 heures.

À retenir : aucune des erreurs ne venait de Zabbix lui-même. Elles se trouvaient aux jointures : conteneur et noyau, données de test et réalité, valeurs par défaut et attentes.

✉️ Le test : une panne mise en scène

Une configuration mail n’est prouvée qu’une fois qu’un mail arrive. Zabbix utilise le même compte SMTP que HP3 utilise déjà pour ses mails d’état (port 587, STARTTLS). Pour le test, j’ai fait pointer un appareil vers l’adresse de documentation et j’ai attendu :

• Au bout d’environ trois minutes est arrivé le mail « Problem: ICMP Ping: Unavailable by ICMP ping ».
• Après avoir remis l’adresse sur un vrai appareil, « Resolved in 1m 0s » a suivi.

J’ai ensuite supprimé l’appareil de test. Pour les captures d’écran de cet article, j’ai remis la panne en scène une fois, notifications coupées – c’est pourquoi le point d’accès en panne s’appelle « WLAN-AP EG » (rez-de-chaussée) sur les images.

À retenir : une alerte jamais testée n’est qu’une hypothèse. Une panne provoquée exprès coûte cinq minutes et prouve toute la chaîne, du ping jusqu’à la boîte mail.

🧭 Visite de l’interface

Zabbix paraît écrasant au début : la navigation compte une bonne douzaine d’entrées principales avec de nombreuses sous-pages. Pour le quotidien d’un réseau domestique, on n’a pourtant besoin que de quelques endroits. Ce tableau est ma trousse de premiers secours – en dessous, chaque entrée explique ce qu’on y trouve.

Dashboards → Global view : la vue d’ensemble

La page d’accueil montre la disponibilité de tous les hôtes, les problèmes par sévérité, les problèmes en cours et une carte. La tuile « Host availability » déroute au début : les appareils sans agent y apparaissent en gris comme « Unknown ». Ce n’est pas une erreur – ils n’ont tout simplement pas d’agent ; leur état se trouve dans les contrôles de ping et de port. La carte (Geomap) place les appareils à l’endroit indiqué dans leur inventaire ; j’y ai mis la commune plutôt qu’une adresse exacte.

Monitoring → Problems : ce qui est en panne maintenant

C’est la page la plus importante. Chaque problème ouvert y figure avec son début, sa durée et sa sévérité. Avec Update, on peut acquitter un problème (« je m’en occupe ») et laisser un commentaire. Le filtre History montre aussi les problèmes résolus – pratique pour retrouver plus tard quand le point d’accès a disparu pour la dernière fois.

Monitoring → Hosts et Latest data : l’état de chaque appareil

Monitoring → Hosts (image plus haut, dans « Ce qui est surveillé ») liste chaque appareil avec des liens vers ses dernières valeurs, problèmes, graphiques et scénarios web. Latest data montre les valeurs brutes : le dernier ping est-il revenu, combien de temps a-t-il pris, un port était-il ouvert. Chaque valeur mène à un graphique.

Monitoring → Hosts → Web : les serveurs externes

Zabbix 7.0 n’a plus d’entrée de menu dédiée : dans Monitoring → Hosts, on clique sur le lien Web à côté d’un appareil. On y trouve les scénarios web pour le blog, Nextcloud et Collabora, avec l’heure et le résultat du dernier passage. Un clic sur le nom montre l’évolution du temps de réponse et de la vitesse de téléchargement. Si un scénario échoue, on voit quelle étape a échoué et avec quelle erreur.

Data collection → Hosts : ajouter un nouvel appareil

Les nouveaux appareils s’ajoutent sous Data collection → Hosts → Create host. Pour un appareil qui n’a besoin que d’un contrôle de ping, cinq champs suffisent :

1. Host name – le nom technique, caractères simples uniquement.
2. Visible name – le nom affiché partout.
3. Templates – choisir ICMP Ping.
4. Host groups – par exemple LAN.
5. Interfaces – une interface avec l’adresse IP de l’appareil. Le type n’a pas d’importance pour le ping ; Zabbix prend l’adresse dans l’interface.

Enregistrer, c’est tout – les premières valeurs arrivent dans la minute. Pour contrôler aussi un port, on ajoute sous Items de l’hôte un élément de type Simple check avec la clé net.tcp.service[tcp,,443], et sous Triggers une alerte comme max(/<host>/net.tcp.service[tcp,,443],#3)=0.

Juste à côté se trouve Data collection → Maintenance. On y saisit les périodes où des appareils sont éteints exprès – par exemple un PC de sauvegarde qui ne tourne que de temps en temps. Aucun mail n’est envoyé pendant ces périodes.

Alerts → Media types et Actions : pour que les mails arrivent

Deux endroits décident si un mail part ou non :

• Alerts → Media types → Email : serveur SMTP, port, chiffrement, expéditeur et identifiants. Le lien Test envoie un mail de test depuis cette page.
• Alerts → Actions → Trigger actions : l’action existante Report problems to Zabbix administrators doit être sur Enabled. Elle définit qui est prévenu d’un problème et de son retour à la normale.

Reste le destinataire : saisir sa propre adresse sous Users → Users → Admin → Media.

HP3 lui-même : des graphiques comme dans Grafana

Pour HP3, Zabbix a construit les graphiques tout seul à partir du modèle Linux : CPU, mémoire, charge, réseau par carte, occupation de chaque dataset ZFS et entrées-sorties disque. On les trouve sous Monitoring → Hosts → Graphs ou sur le tableau de bord d’hôte que Zabbix crée automatiquement.

À retenir : de toutes les entrées de menu, on en utilise quatre au quotidien : Problems, Hosts, Latest data et Create host. Le reste est de la configuration qu’on fait une fois.

🔄 La suite

Certains contrôles existent maintenant en double : mon ancien contrôle de disponibilité continue de vérifier le blog et Nextcloud, et Zabbix le fait aussi. C’est voulu. Les deux tournent en parallèle quelques semaines, puis je déciderai si Zabbix remplace l’ancien contrôle. Zabbix a pour lui l’historique et les temps de réponse, l’ancien contrôle d’être minuscule et de ne presque jamais pouvoir mal tourner.

Il m’importait tout autant que tout puisse être retiré. Comme tout tourne en rootless sous mon utilisateur, le démontage consiste à arrêter quatre services, supprimer quatre fichiers et un répertoire. J’ai noté ces étapes dès la mise en place.

Jusqu’ici, Zabbix ne demande à la plupart des appareils qu’une chose : « Tu es toujours là ? » Dans le prochain article, il doit regarder à l’intérieur :

• La FRITZ!Box et les répéteurs via TR-064. Ils ne parlent pas SNMP, mais cette interface fournit l’état de la ligne internet, le débit de synchronisation et le nombre de clients WLAN. C’est le vrai gain : un point d’accès peut répondre au ping et ne plus émettre de WLAN. « Plus un seul client depuis trois heures », voilà l’alerte qui aide vraiment.
• Le switch via SNMP. Avec la MIB standard (IF-MIB), Zabbix voit l’état, les erreurs et le trafic de chaque port et signale quand un port tombe.
• Le matériel des serveurs via iLO. Pour les ventilateurs, températures, alimentations et disques, Zabbix fournit un modèle prêt à l’emploi qui interroge Redfish (HTTP).
• Le photovoltaïque. L’onduleur Fronius a sa propre interface JSON, la Solar API. Zabbix peut l’interroger sans logiciel supplémentaire et en tirer des graphiques de production.
• Moins de mails lors d’une panne. Si le switch tombe aujourd’hui, chaque appareil derrière lui envoie son propre mail. Avec des dépendances entre les alertes, Zabbix sait que tout dépend du switch et ne signale que lui.
• Un deuxième canal d’alerte, par exemple une notification push sur le téléphone (ntfy), au cas où la voie du mail elle-même tombe en panne. S’y ajoutent une conservation plus courte des mesures et une sauvegarde nocturne de la base.

Et pour être honnête, j’espère que le premier vrai mail de Zabbix se fera attendre longtemps.

À retenir : faire tourner un nouvel outil à côté de l’ancien coûte peu et montre s’il est meilleur au quotidien. Noter tout de suite comment le retirer enlève le risque de l’essai.

🎯 Les leçons

1. Une supervision ne voit que ce pour quoi on l’a construite. Les trous silencieux, ce sont les appareils sans agent.
2. Une alerte n’est prouvée qu’une fois qu’une panne provoquée exprès arrive dans la boîte mail – retour à la normale compris.
3. Vérifier les valeurs par défaut : Zabbix n’a d’usine aucune action mail active, et le fuseau horaire est UTC.
4. Avec les conteneurs, les problèmes se situent souvent à la frontière avec le noyau : capacités, fichiers de périphérique, montages.
5. Pour les tests, utiliser des adresses dont on est sûr qu’elles n’appartiennent à personne – « n’a pas répondu au scan » ne veut pas dire « libre ».

🔧 Complément : moins d’écritures pour les SSD

Après la publication, une question est venue : les petites écritures permanentes abîment-elles le RAIDZ composé de SSD ? J’ai donc mesuré ce que la base écrit réellement : environ 750 transactions par minute, dont un peu plus de 110 imposaient une écriture immédiate sur disque via fsync – presque deux par seconde. Chaque fsync empêche ZFS de regrouper les écritures en RAM pour les écrire par lots, et dans un RAIDZ chaque petit bloc atterrit sur les disques avec sa parité.

Au regard de la durée de vie des SSD, c’est sans danger : environ 200 à 300 Mo par jour sont négligeables pour des disques prévus pour quelque 1 300 To d’écritures chacun. Comme le serveur est branché sur un onduleur, j’ai tout de même configuré PostgreSQL pour regrouper les écritures – quatre options dans le fichier Quadlet de la base :

Le résultat, par minute et à charge comparable :

Le prix : si le courant tombe malgré l’onduleur, les mesures des dernières secondes peuvent manquer. La base reste cohérente – avec synchronous_commit=off, PostgreSQL ne perd que les transactions les plus récentes, il n’en abîme jamais de plus anciennes. Pour des données de supervision, c’est un bon compromis.

À retenir : mesurer d’abord, optimiser ensuite. Le premier réglage seul n’a presque rien changé ; seule la mesure a montré que le processus d’arrière-plan continuait d’écrire chaque petite modification séparément, au rythme de 200 ms.

Les captures d’écran sont anonymisées : noms d’appareils, adresses IP, domaines et adresses mail ont été remplacés par des valeurs neutres avant la capture, et la panne est mise en scène.