На новом сервере 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: es регистрируют события остановки температуры.
Сначала вы хотите проверить /var/log/syslog. Если вы не знаете, что искать, можете начать с поиска слов error, panic и warning.
grep -i error /var/log/syslog
Если у вас есть системные графики (например, Munin). Проверьте их и поищите аномальные узоры. Если у вас не установлен munin, возможно, стоит его установить (apt-get install munin munin-node)
Вам также следует проверить корневую почту на наличие интересных сообщений, которые могут быть связаны с сбоем вашей системы.
Другой файл журнала, который вы должны проверить, - это журналы ошибок приложения. Например /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
Если нет информации =>, это может быть потеря питания или что-то еще внешнее
если у вас есть информация => искать в журналах время перезагрузки / выключения