LINUX.ORG.RU
ФорумAdmin

Поиск логов за определенную дату

 ,


0

1

Привет, ЛОР!

Очень нужна твоя помощь неопытному сисадмину. В общем, стоит передо мной задача просмотреть логи за определенную дату и выяснить причину неисправности сервера за данный промежуток времени. Нагуглив в интернете, я узнал поподробнее про великолепный systemd, все было бы неплохо, если бы он был установлен на системе клиента под управлением centos. Так что, увы, не вариант. Единственное, что пока мне удалось выяснить, так это то что примерно в этот промежуток времени происходил ребут севера, и более ничего. Какие у меня есть варианты для поиска необходимой мне информации?

Всех заранее сердечно благодарю!

Покажи формат записи (пару строк из лога).

Deathstalker ★★★★★ ()

если в логи записываются месяц, день, время то можно сделать grep.
Пример с кроном

cat cron | grep "Jul 22 18:58" или  cat cron | grep "Jul 22 18:*"

gssomi ★★ ()

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

gregz ()
Ответ на: комментарий от gregz

Система крашится очень часто. Что посоветуете в первую очередь проверить\посмотреть, чтобы понять причину периодических падений сервера (я полагаю, клиенту не только причина падения интересна, но и возможность это избегать впоследствии)?

reboot   system boot  2.6.32-042stab11 Wed Jul 20 21:55 - 18:00 (1+20:05)
reboot   system boot  2.6.32-042stab11 Wed Jul 20 19:35 - 18:00 (1+22:24)
reboot   system boot  2.6.32-042stab11 Mon Jul 18 03:44 - 19:13 (2+15:29)
reboot   system boot  2.6.32-042stab11 Tue Jul 12 08:31 - 19:13 (8+10:41)
reboot   system boot  2.6.32-042stab11 Tue Apr 12 17:25 - 07:59 (90+14:34)
reboot   system boot  2.6.32-042stab11 Fri Mar 25 21:33 - 16:29 (17+18:56)
reboot   system boot  2.6.32-042stab11 Fri Mar 25 14:53 - 21:32  (06:38)
reboot   system boot  2.6.32-042stab11 Wed Feb 17 11:18 - 14:53 (37+03:34)
reboot   system boot  2.6.32-042stab11 Tue Jan 26 15:10 - 11:17 (21+20:06)
reboot   system boot  2.6.32-042stab11 Thu Dec 24 11:53 - 11:17 (54+23:24)
reboot   system boot  2.6.32-042stab11 Sat Dec  5 21:55 - 11:47 (18+13:51)
reboot   system boot  2.6.32-042stab11 Wed Oct 21 10:11 - 11:47 (64+01:35)
reboot   system boot  2.6.32-042stab09 Tue Feb 24 09:36 - 10:04 (239+00:27)
reboot   system boot  2.6.32-042stab09 Mon Feb 16 02:52 - 09:28 (8+06:36)
reboot   system boot  2.6.32-042stab09 Sun Feb 15 22:44 - 02:47  (04:03)
reboot   system boot  2.6.32-042stab09 Sun Feb 15 22:27 - 02:47  (04:20)
reboot   system boot  2.6.32-042stab09 Fri Feb 13 13:49 - 02:47 (2+12:58)
reboot   system boot  2.6.32-042stab09 Wed Nov 19 11:44 - 02:47 (88+15:03)
reboot   system boot  2.6.32-042stab09 Mon Nov 17 12:50 - 09:29 (1+20:38)
reboot   system boot  2.6.32-042stab08 Wed Aug 13 15:37 - 12:37 (95+20:59)

ivan_dav ()
Ответ на: комментарий от ivan_dav

Сервер реальный или виртуальный? В случае железки скорее всего бажное оборудование. Первым делом проверить диски/контроллеры. Прогнать fsck, посмотреть смарт-дату. Хотя обычно в таком случае в логи хоть что-то да записывается. Если виртуалка - есть шансы какого-нибудь протухшего openvz в виде хоста. Он любит гостей вешать и ронять.

gregz ()
Ответ на: комментарий от gregz

Если виртуалка - есть шансы какого-нибудь протухшего openvz в виде хоста. Он любит гостей вешать и ронять.

Виртуалка как раз. Я так понимаю с этим вопросом стоит долбить хостера? Или я могу самостоятельно что-то выяснить?

ivan_dav ()
Ответ на: комментарий от gregz

Прошу прощения под хостом вы имели в виду же hostname, конечно же? А то я вас несколько не понял.

ivan_dav ()
Ответ на: комментарий от ivan_dav

Самостоятельно ты можешь выяснить систему виртуализации (в гостях openvz наличиствует файлик /proc/user_beancounters), если уже ее не знаешь, еще раз внимательно посмотреть логи и прогнать диски тестами, чтобы было с чем к хостеру идти.

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

gregz ()
Ответ на: комментарий от ivan_dav

Под хостом я имел ввиду систему виртуализации, которая работает на хосте, на котором живет твоя виртуалка. Ну, знаешь, kvm/xen/lxc/openvz, вот это все. Опенвз из них самый проблемный и давно устаревший.

gregz ()
Ответ на: комментарий от gregz

Да, у меня openvz :( Обнаружил в /proc файлик, о котором вы говорили.

ivan_dav ()
Ответ на: комментарий от ivan_dav

Система крашится очень часто. Что посоветуете в первую очередь проверить\посмотреть, чтобы понять причину периодических падений сервера (я полагаю, клиенту не только причина падения интересна, но и возможность это избегать впоследствии)?

Поставить nmon на мониторинг в течении суток. После возникновения проблемы проанализировать лог.

dada ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.