Как узнать причину сбоя Linux-сервера после перезагрузки

Вот сделка,

приходите на работу только для того, чтобы узнать, что один сервер вообще не отвечает, машина включена, но на экране ничего не отображается, не отвечает на ввод с клавиатуры (у меня не включены sys rq keys ).

Сервер должен быть запущен и работать как можно быстрее, поэтому я сделал полную перезагрузку сервера, и теперь все работает нормально.

Теперь мой босс хочет знать, что случилось и почему.

Итак, как мне начать отладку того, что пошло не так до перезагрузки? На какие журналы мне следует обратить особое внимание, и есть ли какие-нибудь изящные уловки, которые вы могли бы теперь использовать, чтобы отладить случайное зависание сервера (это случается не часто - я впервые вижу это)

Спасибо за любые полезные рекомендации и предложения.

Ps: Я запускаю ubuntu server 12.04.

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

Если у вас есть аппаратный RAID-контроллер, я бы узнал, можете ли вы прочитать его журнал (если 3Ware, используйте tw_cli). И независимо от того, есть ли у вас аппаратный или программный RAID, вы можете посмотреть параметры SMART дисков (если диски подключены к RAID-контроллеру, вам могут потребоваться специальные команды для доступа к ним. См. smartctl страница руководства).

Если вы это сделаете:

smartctl -a /dev/sdX

Я всегда в первую очередь смотрю на:

Количество перераспределенных секторов. Особенно плохо, когда со временем оно увеличивается. И я не полностью доверяю диску, на котором есть перераспределенные сектора.
Посмотрите журнал ошибок SMART. Поначалу это сложно читать, но главное - увидеть, есть ли события и в какое время (выраженное в возрасте диска в часах) они произошли. Вы можете увидеть текущий возраст диска как один из параметров SMART. Если это недавно, это может быть связано.

Кроме того, следите за dmesg и syslog, чтобы увидеть, будут ли со временем возникать ошибки. Например, ошибки диска часто обнаруживаются задолго до того, как станут фатальной проблемой, в виде исключений. У нас есть центральный сервер журналов (использующий rsyslog), который уведомляет меня об исключениях ata. Быстрый пример того, как это настроить:

/etc/rsyslog.d/60-smtp.conf:

$ModLoad ommail
$ActionMailSMTPServer localhost
$ActionMailFrom noreply@example.com

/etc/rsyslog.d/70-mail-ata-errors:

$ActionMailTo you@yexample.com
$template mailSubjectATA,"ATA error on %hostname%"
$template mailBodyATA,"You have ATA errors. Mostly it's the disk and you get these errors before a possible mdraid setup kicks the drive.\r\nBEWARE: ata1.00 is first ata, first disk. Ata1.01 is first ata, second disk. Use the ata-to-device-names.sh script to identify devices.\r\n msg='%msg%'"
$ActionMailSubject mailSubjectATA
$ActionExecOnlyOnceEveryInterval 3600
:msg, regex, "ata.*exception" :ommail:;mailBodyATA

Видеть здесь для имен ata-to-devicen сценарий.

Еще вы можете сделать мемтест. Установочные DVD / компакт-диски Ubuntu имеют их в меню загрузки, и я считаю, что любой сервер Ubuntu также имеет их в своем обычном меню загрузки. Пусть сделает хотя бы один проход, по возможности больше.

У вас есть ECC RAM BTW? ECC RAM важна для долгосрочной стабильности и целостности данных.

/var/log/syslog это хорошее место для начала. Найдите первые сообщения журнала после перезагрузки. Они что-то скажут о запуске системного журнала и о том, какую версию ядра вы используете.

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

Пройдите другие логины /var/log чтобы узнать, можете ли вы найти какие-либо строки с отметкой времени между последней строкой журнала до сбоя и первой строкой после.

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

В конфигурацию могут быть внесены изменения, которые помогут получить больше информации, если проблема повторится. Включение Sys Rq ключ - это один из вариантов. Также может быть целесообразно отключить гашение экрана (я предполагаю, что вы избегаете потери энергии, если не включаете монитор, когда вы его не используете). Более того, может помочь регистрация по сети на другом сервере, в частности, если основная причина связана с диском / файловой системой.

Часть меня хочет сказать, что Linux не должен просто разбейся... Современные операционные системы при нормальном использовании должны быть достаточно стабильными. Когда я начинаю замечать нестабильность сервера, это почти всегда связано с взаимодействием с оборудованием или драйверами. Я бы рекомендовал очень внимательно изучить сервер, его состояние и связанные с ним компоненты (RAM, хранилище и т. Д.).

Если вы используете оборудование, которое не дает или не может предоставить информацию о состоянии оборудования (например, компьютер настольного класса), мало шансов, что вы увидите что-либо, отраженное в журналах уровня Linux.