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

Как отличить преднамеренную перезагрузку и сбой питания от журналов

Один из моих хостов centos недавно перезагрузился, к сожалению, мониторинг не был реализован.

Как узнать, что вызвало его перезагрузку. у меня есть только ssh доступ к нему.

Как определить, связана ли причина со следующим:

1.power failure.(Will there be any special non maskable interrupt logged some where)

2.Intentional hard reset.(will it be possible to differentiate between power failure n reset also what will be Signal to look for?).

3.manual reboot command(How to differentiate this from hard reset,will inode reveal anythng related to this like "**Cleaning Orphaned node**"  any special signals?)

4.Low disk space.(there is no message in /log/messages 30 minutes before restart,something stopped daemon from writing to log, disk space was ok ).  

5.Overloaded CPU (Not configured to run any cronjob for saving sar o/p,Currently load average is normal Will there be any special signal to look for when CPU is loaded.)

6.Low RAM(currently there is more than 24 GB free space

Мне интересно узнать разницу между преднамеренной (аппаратный сброс / команда) и перезагрузкой из-за сбоя питания.

Для большинства аппаратных сбоев вы можете посмотреть System Event Log записи, он может выявить такие вещи, как:

  1. Перегрев процессора
  2. Ошибки памяти ECC
  3. Сбои в питании
  4. IPMI перезагружается

и многое другое.

Вы можете получить доступ к SEL (если он доступен на вашем оборудовании) через ipmitool или ipmiutil команды, см .: ipmiutil sel - показать записи журнала системных событий прошивки

Для 3 вы увидите сообщения журнала о завершении работы процессов перед перезагрузкой. Вы не увидите тех, у кого есть 1 и 2. Кроме того, при некорректном завершении работы вы можете увидеть сообщения, связанные с проверкой файловой системы при загрузке. Однако имейте в виду, что их наличие не обязательно указывает на принудительное завершение работы, поскольку некоторые файловые системы запускают периодические проверки самих себя каждые N дней или каждые X подключений.

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

Чтобы расширить 6, при экстремальной нагрузке на оперативную память ядро ​​вызовет своего убийцу нехватки памяти, который убивает процессы, требующие большого количества памяти, для сохранения общей стабильности системы. Когда это произойдет, это будет зарегистрировано.