Как расследовать неожиданное отключение сервера Linux?

На новом сервере Xeon 55XX с 4xSSD на рейде 10 с Debian 6 я испытал 2 случайных отключения в течение двух недель после сборки сервера. Просмотр журналов пропускной способности перед выключением не показывает ничего необычного. Нагрузка на сервер, как правило, очень низкая (около 1), и она расположена далеко друг от друга. Кажется, что при отключении сервера не происходит перебоев в подаче электроэнергии.

Я знаю, что смотрю на / var / log, но не уверен, какие журналы мне следует исследовать и что искать. Так что цените ваши намеки.

Во-первых, я должен спросить: «выключения»? Вы имеете в виду, что машина перезагружается или она действительно останавливается? Если он останавливается, он либо неправильно настроен (возможно, в BIOS), либо что-то активно выключает машину (т.е. init 0).

Если нет, вашим основным кандидатом будут / var / log / syslog и /var/log/kern.log, поскольку ваша проблема звучит как паника ядра или аппаратная ошибка, вызванная программным обеспечением. Конечно, если на сервере запущен какой-то сервис (например, apache), это тоже может дать вам подсказку.

Часто в подобных ситуациях генерируются записи в журнале, но из-за проблем с машиной ей не удастся записать записи на диск. Если коробка расположена в одном месте, есть вероятность, что она подключена к последовательной консоли партнером Colo. Вот куда я бы заглянул, если бы не нашел ничего подозрительного в журналах выше.

Если аппарат не подключен к последовательной консоли, и в журнале ничего нет, вы можете рассмотреть возможность отправки системного журнала в другой ящик по сети. Возможно, сетевой интерфейс выживает немного дольше, и сообщения журнала могут быть прочитаны на сервере системного журнала. Посмотрите на rsyslog или syslog-ng.

ОБНОВИТЬ:

Я согласен с @Johann ниже. Наиболее вероятная причина остановки - сторожевой таймер температуры процессора. Попробуйте проверить / отобразить температуру в коробке через lmsensors или smartctl (как правило, самый простой). Я считаю, что collectd не имеет аналогов в отслеживании большого количества переменных во времени. Это могут делать как IPMI, так и lm-сенсоры и hddtemp. Также некоторые BIOS: регистрируют события остановки температуры.

Во-первых, вы хотите проверить /var/log/syslog. Если вы не уверены , что искать, вы можете начать искать слова error, panicи warning.

grep -i error /var/log/syslog

Если у вас есть системные графики (например, Munin). Проверьте их и поищите ненормальные паттерны. Если у вас не установлен munin, возможно, стоит установить его ( apt-get install munin munin-node)

Вы также должны проверить root-mail на наличие интересных сообщений, которые могут быть связаны с крахом вашей системы.

Другие файлы журналов, которые вы должны проверить, это журналы ошибок приложения. Например, /var/log/apache2/error.logили похоже. Они могут содержать информацию, ведущую вас к проблеме.

По моему опыту, «неожиданная остановка» почти всегда вызвана перегревом. Проверьте ваши температуры и скорости вращения вентиляторов с помощью lm_sensors и убедитесь, что они хороши.

Недавно у нас была такая же картина: сервер остановился примерно через час после того, как служба поддержки запустила его вручную. По истечении этого часа температура процессора достигла установленного порога в BIOS (iirc 60 или 70 ° C) и остановила систему. Все эти проблемы были вызваны поломкой вентилятора процессора. После замены вентилятора все нормализовалось.

В каталоге / var / log (и его подкаталогах) есть несколько файлов журналов, включая

/var/log/boot

и

/var/log/boot.log

Начните с файлов выше.

Есть 2 способа проверить, что вызвало завершение работы: сначала проверьте консоль Out-Of-Band Management на наличие проблем с оборудованием, я бы предложил настроить SNMP и получать электронные письма или добавлять ловушки в программное обеспечение для мониторинга для любых предупреждений.

Затем через операционную систему вы можете проверить /var/log/messages(дистрибутивы на основе RedHat) или /var/log/syslog(дистрибутивы на основе Debian).

Дисковая подсистема достаточно сложна, чтобы на нее можно было воздействовать при возникновении проблемы, потому что вы вряд ли получите что-либо в своих лог-файлах.

Попробуйте войти через последовательную консоль. Для этого требуются некоторые кабели и другая система, чтобы уловить линии, но у вас больше шансов на самом деле решить проблему.

Конечно, если ваш узел имеет встроенную систему управления, аналогичную Oracle ALOM / ILOM, вы также можете проверить наличие возможных проблем и файлы журналов там.

Вы можете узнать, знает ли система о том, что она отключалась, с помощью следующих команд.

sudo last -1x reboot
sudo last -1x shutdown

Если нет информации =>, то это может быть потеря власти или что-то еще внешнее

если у вас есть информация => поиск в журналах во время перезагрузки / выключения