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

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

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

6 ответов

Во-первых, я должен спросить: "выключения"? Вы имеете в виду, что машина перезагружается или она действительно останавливается? Если он останавливается, он либо неправильно настроен (возможно, в 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) и остановила систему. Все эти проблемы были вызваны поломкой вентилятора процессора. После замены вентилятора все нормализовалось.

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

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

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

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

В каталоге /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, вы также можете проверить наличие возможных проблем и файлы журналов там.

Другие вопросы по тегам