Tout d'abord, je dois demander: "arrêts"? Voulez-vous dire que la machine redémarre ou s'arrête-t-elle réellement? S'il s'arrête, il est soit mal configuré (peut-être dans le BIOS), soit quelque chose arrête activement la machine (par exemple, init 0).
Sinon, votre principal candidat serait / var / log / syslog et /var/log/kern.log car votre problème ressemble à une panique du noyau ou à une panne matérielle déclenchée par logiciel. Bien sûr, si le serveur exécute un service (par exemple, apache), cela peut aussi vous donner un indice.
Souvent, dans des situations comme celle-ci, des entrées de journal sont générées, mais comme la machine rencontre des difficultés, elle ne parvient pas à écrire les entrées sur le disque. Si le boîtier est colocalisé, il est probable qu'il soit connecté à une console série par le partenaire colo. C'est là que je chercherais si je ne trouvais rien de suspect dans les journaux ci-dessus.
Si la machine n'est pas connectée à une console série et qu'il n'y a rien dans le journal, vous pouvez envisager d'envoyer Syslog à une autre boîte via le réseau. L'interface réseau survit peut-être un peu plus longtemps et les messages de journal peuvent être lus sur le serveur syslog. Jetez un œil à rsyslog ou syslog-ng.
MISE À JOUR:
Je suis d'accord avec @Johann ci-dessous. La cause la plus probable de l'arrêt est le chien de garde de la température du processeur. Essayez de vérifier / tracer la température dans la boîte via lmsensors ou smartctl (généralement le plus simple). Je trouve que collectd est sans égal pour garder une trace d'un grand nombre de variables au fil du temps. Il peut faire à la fois des capteurs IPMI et lm et hddtemp. En outre, certains événements d'arrêt de température du journal du BIOS: es.