Як дослідити несподіване закриття сервера Linux?

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

Я знаю, що я дивлюсь на / var / log, але не впевнений, які журнали слід досліджувати та що слід шукати. Тож оцініть свої підказки.

По-перше, я повинен запитати: "відключення"? Ви маєте на увазі, що машина перезавантажується чи вона насправді зупиняється? Якщо він зупиняється, він або неправильно налаштований (можливо, в BIOS), або щось активно вимикає машину (тобто init 0).

Якщо ні, то вашим основним кандидатом буде / var / log / syslog та /var/log/kern.log, оскільки ваша проблема звучить як паніка ядра або помилка апаратного забезпечення, що викликається програмним забезпеченням. Звичайно, якщо сервер запускає якусь послугу (наприклад, apache), це може дати вам і підказку.

Часто в таких ситуаціях генеруються записи журналу, але оскільки у машини виникають труднощі, він не зможе записати записи на диск. Якщо вікно є кольоровим, велика ймовірність, що він підключений до послідовної консолі партнером по колорі. Саме тут я б заглянув, якби не знайшов нічого підозрілого у вищезгаданих журналах.

Якщо машина не підключена до послідовної консолі і в журналі немає нічого, ви можете розглянути можливість надсилання syslog до іншого вікна через мережу. Можливо, мережевий інтерфейс зберігається трохи довше, і повідомлення журналу можна прочитати на сервері syslog. Погляньте на rsyslog або syslog-ng.

ОНОВЛЕННЯ:

Я згоден з @Johann нижче. Найімовірнішою причиною зупинки є сторожова температура температури процесора. Спробуйте перевірити / побудувати графік температури в коробці через lmsensors або smartctl (як правило, найпростіший). Я вважаю, що colled є безпрецедентним при відстеженні великої кількості змінних у часі. Він може робити як IPMI, так і lm-датчики та hddtemp. Також деякі зупинки температури журналу BIOS: es журналу.

По-перше, ви хочете перевірити /var/log/syslog. Якщо ви не впевнені , що шукати, ви можете почати шукати слова error, panicі warning.

grep -i error /var/log/syslog

Якщо у вас є системні графіки (наприклад, Мунін). Перевірте їх і шукайте ненормальні візерунки. Якщо у вас не встановлено 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

Почніть з вищезазначених файлів.

Є два способи перевірити, що викликало відключення, спочатку перевірте консоль Out-Of-Band Management для будь-якої проблеми в апаратному забезпеченні, я б запропонував налаштувати SNMP та отримувати електронні листи або додавати пастки в програмне забезпечення для моніторингу для будь-якого попередження.

Потім через Операційну систему ви можете перевірити /var/log/messages(дистрибутив, заснований на RedHat), або /var/log/syslog(дистрибутив на основі Debian).

Дискова підсистема є досить складною, щоб на неї впливати, коли виникає проблема, оскільки ви майже не знайдете нічого у своїх журнальних файлах.

Спробуйте увійти через послідовну консоль. Для цього потрібні певні кабелі та інша система, щоб забрати лінії, але у вас є більше шансів реально наздогнати проблему.

Звичайно, якщо ваш вузол має вбудовану систему управління, подібну до ALOM / ILOM Oracle, ви також можете перевірити можливі проблеми та файли журналів.

Ви можете дізнатися, чи система знає про те, що вона йшла вниз за допомогою наступних команд

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

Якщо немає інформації =>, це може бути втрата влади або щось інше зовнішнє

якщо у вас є інформація => шукайте в журналах приблизно час перезавантаження / відключення