Назад | Перейти на главную страницу

Диагностика сбоев сервера… Доступны ли программы в стиле «рекордера черного ящика»?

Мой сервер redhat дает сбой примерно каждые три недели в 4:15 утра по воскресеньям. (ну, это было в воскресенье, последние два были утром в четверг, в 16:15). Глядя на журналы (mysql, httpd, messages), нет никаких подсказок, почему. Кажется, они просто останавливаются.

Я запустил небольшой скрипт, чтобы снимать показания памяти каждые 15 минут, и он тоже останавливается (с нормальными показаниями) в это время.

Сервер удален у поставщика, поэтому я могу получить к нему доступ только через Интернет. Я использую Plesk.

Похоже, проблема связана с установленным заданием или чем-то еще. Я ничего не вижу в crontab.

Итак, мой вопрос ... Был ли у кого-нибудь еще это и может ли он дать совет? В противном случае.

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

Спасибо

Вы можете включить дампы ядра, которые будут копировать системную память в файл при сбое сервера.

Следующая проблема заключается в том, что делать с файлом coredump ... Если у вас есть кто-то, кто знает все о GDB, он может что-то с этим поделать ... или вы можете использовать команду "strings", чтобы выгрузить все текста из файла coredump, и, возможно, вам удастся что-нибудь найти.

это время, когда запланированы задания cron.daily, поэтому я бы заглянул в /etc/cron.daily, еженедельно или ежемесячно в качестве первых подозреваемых

вы можете установить поверх, который будет записывать снимки процессов каждые 10 минут

в качестве альтернативы вы можете установить psacct и использовать accton и lastcomm, чтобы увидеть, что выполняется

включение аудита также возможно, см. auditd (8)

войдите в другой ящик, который хорошо подключен, запустите screen, ssh на сервер и закройте kern.log, daemon.log, syslog, сообщения в отдельных окнах экрана. (Ctrl-A, c для создания нового окна, Control-A, D для отсоединения, screen -r для возобновления)

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

Если вы подозреваете панику ядра или упс

kernel.panic = 5 kernel.panic_on_oops = 5

в вашем sysctl.conf или аналогичном файле будет ждать 5 секунд, возможно, позволяя дискам очиститься, а затем перезагрузится.