Avez-vous besoin d'une pile de métriques, ou la vue intégrée répond-elle déjà à votre question ?

Il y a dans presque tout homelab une étape où quelqu'un installe une pile de métriques, construit de beaux tableaux de bord, puis cesse de les ouvrir. On lit généralement cela comme un manque de discipline. C'est plus souvent un décalage : la pile répondait à une question que personne ne posait.

Alertes et métriques ressemblent au même sujet et n'en sont pas un. Les alertes répondent à est-ce cassé maintenant. Les métriques répondent à que se passait-il alors. Ce dont vous avez besoin dépend entièrement des questions que vous posez réellement.

La question qui tranche

Pas « dois-je surveiller mon serveur », car oui. Demandez plutôt : jusqu'où en arrière la réponse doit-elle remonter ?

« Est-ce cassé en ce moment ? » La vue intégrée y répond. Charge actuelle, mémoire, occupation disque, quels invités tournent. Ajouter une pile de métriques pour cette question ajoute un service et ne répond à rien de neuf.

« Était-ce lent mardi dernier vers trois heures du matin ? » Là il vous faut de l'historique, et rien d'intégré ne le conserve à cette résolution aussi longtemps. C'est la raison honnête de faire tourner une pile de métriques, et elle est bonne.

« Vais-je manquer de disque avant le printemps ? » Il vous faut une courbe de tendance, c'est-à-dire de l'historique avec de l'arithmétique dessus. Raison réelle également.

« Laquelle de ces deux modifications a accéléré les choses ? » Il vous faut l'avant et l'après dans la même image. Raison réelle.

Si aucune de vos vraies questions ne remonte au-delà d'hier, une pile de métriques est un loisir plutôt qu'un outil. C'est très bien, et il vaut la peine de savoir lequel des deux vous construisez.

Ce que cela coûte, honnêtement

Un service de plus à maintenir en vie. Une pile de métriques à l'arrêt depuis trois semaines est pire que rien, car vous croyez avoir de l'historique et vous n'en avez pas.

Elle tourne généralement sur ce qu'elle observe. Voilà le piège qui mérite d'être nommé : quand l'hôte passe une mauvaise nuit, l'enregistrement de cette nuit meurt avec lui. Le graphique que vous voulez le plus est justement celui qui a cessé d'être écrit au moment où c'est devenu intéressant.

Le stockage grossit en silence. Des métriques fines venant d'une poignée d'invités s'accumulent plus vite qu'on ne croit, et cette croissance est invisible jusqu'à ce qu'un disque se remplisse.

Les tableaux de bord se périment. Un panneau construit pour un problème de l'an dernier occupe de l'écran longtemps après que ce problème a été résolu.

Les deux habitudes qui rendent cela rentable

Mettez l'enregistreur ailleurs que sur l'enregistré. Même une petite machine ailleurs, même bon marché. Si c'est impossible, sachez au moins que votre historique partage le sort de l'hôte, et traitez les graphiques comme un confort plutôt que comme une preuve.

Décidez la rétention avant la résolution. On choisit d'abord un intervalle d'échantillonnage et on découvre le coût de stockage ensuite. Le bon ordre est l'inverse : décidez jusqu'où vous devez remonter, puis choisissez la résolution qui tient dans l'espace que vous acceptez d'y consacrer. Trente secondes pendant une semaine sont souvent moins utiles que cinq minutes pendant un an.

Ce que Proxmox fournit déjà

Plus qu'on ne le suppose. Il y a des graphiques intégrés par nœud et par invité couvrant processeur, mémoire, réseau et disque sur plusieurs plages de temps, sans rien installer. Pour un hôte unique avec quelques invités, cela couvre l'essentiel des questions « était-ce chargé hier ».

Il existe aussi une manière documentée d'envoyer les métriques vers une base de séries temporelles externe, et c'est le chemin pris en charge quand vous décidez qu'il vous en faut une. Cela compte : le choix n'est pas « bricoler quelque chose », c'est un passage de relais pris en charge.

Ce que cet article n'est pas

Pas un argument contre Grafana. C'est réellement excellent, et pour plusieurs hôtes ou des questions de capacité à long horizon, il n'y a pas de substitut.

Pas l'affirmation que les tableaux de bord sont inutiles. Un tableau que vous ouvrez chaque semaine vaut dix que vous avez construits et oubliés.

Ce que fait Atlas, et ce qu'il ne fait pas

Atlas n'est pas une pile de métriques et n'essaie pas de l'être. Il n'a pas de base de séries temporelles, il ne garde pas des mois d'historique fin, et si votre question est « à quoi ressemblait le réseau mardi dernier à 03:14 », Atlas est le mauvais outil et Grafana le bon.

Ce à quoi Atlas répond, c'est l'autre question : y a-t-il ici quelque chose qui a besoin de moi aujourd'hui. Le résumé quotidien porte les redémarrages non planifiés, un noyau installé mais non démarré, l'âge de la sauvegarde la plus récente, la pression disque et mémoire, et les invités critiques arrêtés. Ce sont des réponses par oui ou non sur le présent, pas des tendances sur le passé.

Le seul endroit où les deux se recoupent est la capacité, et là Atlas reste volontairement superficiel : il signale la pression actuelle plutôt que de projeter une courbe. S'il vous faut la courbe, c'est une pile de métriques, et la recommandation honnête est d'en faire tourner une.

La raison de dire tout cela franchement est la même que celle de tout le reste de ce wiki. On croit plus facilement un outil sur ce qu'il fait quand il dit ce qu'il ne fait pas.