Il s'est passé quelque chose cette nuit : où se trouve vraiment la trace

Une alerte dit que quelque chose est arrivé. Un journal dit pourquoi. Le piège : la trace dont vous avez le plus besoin couvre la minute où la machine est morte, et sur une installation par défaut c'est justement celle qui a le plus de chances de manquer.

AtlasPVE ·

Cette fiche répond à

  • proxmox logs après crash
  • proxmox emplacement des fichiers journaux
  • proxmox journal des tâches emplacement
  • proxmox syslog emplacement
  • proxmox logs after crash

La machine a redémarré pendant la nuit et personne ne le lui a demandé. Tout fonctionne à nouveau, rien n'est visiblement cassé, et la seule phrase honnête possible est celle-ci : il s'est passé quelque chose.

La surveillance dispose de trois traces, et elles répondent à trois questions différentes. Une alerte dit que quelque chose est arrivé. Une métrique dit quelle forme cela avait. Un journal dit pourquoi. Ce texte parle du troisième, et de ce fait gênant : le journal qui couvre la minute intéressante est celui qui a le plus de chances d'avoir disparu.

La première question est plus petite qu'on ne croit

Avant toute théorie matérielle, posez la question la moins coûteuse : a-t-elle été arrêtée, ou est-elle morte ?

Une seule ligne y répond. Un arrêt propre laisse une signature à la fin du journal du démarrage précédent : le service de journalisation note qu'on lui a demandé de s'arrêter, puis note qu'il s'est arrêté. Une machine privée de courant ne laisse aucune fin. La trace s'interrompt simplement au milieu d'une activité ordinaire.

Cette seule distinction coupe l'enquête en deux. Une fin propre signifie que quelque chose a décidé de redémarrer, donc cherchez le demandeur : une mise à jour, un chien de garde, une tâche planifiée, une personne. Aucune fin signifie que la machine a été interrompue, donc regardez l'alimentation, la chaleur, la mémoire et le stockage en dessous.

Encore faut-il que le démarrage précédent existe encore

Voilà le piège. Le journal ne conserve l'historique de façon durable que si un répertoire précis existe sur le disque. S'il manque, le journal vit en mémoire, et chaque redémarrage efface exactement la preuve que vous venez chercher. Aucune erreur, aucun avertissement ; vous demandez le démarrage précédent et on vous répond qu'il n'y en a pas.

Cela se vérifie mieux un après-midi calme que le matin où l'on en a besoin. C'est un répertoire, et c'est lui qui fait la différence entre avoir une trace et croire qu'on en a une.

C'est aussi la même forme qu'un piège qui mérite d'être nommé deux fois : un enregistreur qui partage le sort de ce qu'il enregistre. La courbe que vous voulez le plus est celle qui a cessé d'être écrite au moment où c'est devenu intéressant ; et le journal que vous voulez le plus appartient au démarrage qui n'existe plus.

Le fichier que la moitié d'internet vous dit de lire n'est peut-être pas là

Mesuré sur une installation actuelle, Proxmox VE 9.2.6 sur Debian 13.6 : le démon de journalisation système classique n'est pas installé, et /var/log/syslog n'existe pas.

Cela pèse plus lourd qu'il n'y paraît. Une grande partie des conseils de dépannage écrits ces quinze dernières années commence par « regardez /var/log/syslog ». Sur une machine actuelle cette commande ne renvoie rien, et pour quelqu'un sous pression le résultat se lit comme *je n'ai pas de journaux* plutôt que *je regarde au mauvais endroit*. La trace système est aujourd'hui le journal, et il ne s'ouvre pas dans un éditeur, il s'interroge.

Proxmox tient une seconde trace, qui répond à une autre question

Distinct du journal système, Proxmox VE tient son propre journal des tâches. Toute opération lancée depuis l'interface web ou l'API devient une tâche avec un identifiant, une heure de début, une heure de fin et un statut final, et un fichier d'index accompagne les fichiers de tâches individuels. Sur un seul hôte de laboratoire, cet index contenait 283 lignes, avec environ 960 fichiers de tâches derrière.

Les deux traces excellent dans des domaines différents. Le journal est bon pour « que faisait le système ». Le journal des tâches est bon pour « qui a demandé quoi, et est-ce que ça s'est terminé ». Quand une machine virtuelle porte un instantané que personne ne se souvient d'avoir pris, ou qu'une modification apparaît sans auteur, le journal des tâches répond en général plus vite, car c'est une liste d'intentions et non un flux d'événements.

Fixez le plafond avant d'avoir besoin de l'historique

Par défaut, la limite du journal s'exprime en part du système de fichiers et non en durée. Sur l'hôte mesuré plus haut, aucune limite explicite n'était fixée et le journal avait atteint environ 276 Mo.

Deux nombres méritent d'être connus à l'avance : combien d'espace le journal peut occuper, et jusqu'où cela remonte réellement sur cette machine. L'ordre compte, et c'est le même que pour les métriques. Décidez jusqu'où vous devez voir en arrière, puis choisissez le réglage qui va jusque-là. Découvrir la réponse en plein incident, c'est découvrir que la réponse est « pas assez loin ».

Ce qu'Atlas fait, et ne fait pas

Atlas ne remplace pas le journal et n'essaie pas de lire vos traces à votre place. Il n'y a pas de recherche dans les journaux ici, et prétendre le contraire vous préparerait une mauvaise matinée.

Ce qu'Atlas porte, c'est la première moitié : le résumé quotidien signale un redémarrage non planifié comme un fait, avec la machine et l'heure, pour que la question soit au moins posée. La lecture reste la vôtre et la réponse habite toujours le journal.

C'est là tout l'enjeu. La pire version de cette nuit n'est pas le redémarrage que vous avez examiné avec le mauvais fichier ouvert. C'est le redémarrage que personne n'a remarqué, car une trace que personne n'ouvre jamais ne répond à rien.

Sources

La documentation officielle de Proxmox. En anglais, et c’est elle qui a le dernier mot sur ce sujet.

Fiches liées

À quoi cela ressemble dans Atlas ?

Aller à la page produit