Довольно часто приходится разбираться с причинами падения linux серверов (здесь сразу оговоримся - речь идет о железных серверах). Обычно что дальше происходит? Запрашиваем remote IP-KVM, немного ждем, подключаемся и пытаемся в маленьком окне консоли разглядеть что же явилось причиной падения (особенно будет "удобно" когда эти логи будут затерты какими-то не существенными записями и что-то понять уже не получится). После перезагрузки можно конечно смотреть логи/дашборды и вполне может быть удастся понять причину падения или хотя бы примерное направление куда копать. Но бывает в логах в момент падения может быть нечто такое:
/var/log/syslog: @@@@@@@@@@@@@@@@@@@@@@@@@@@@.....@@@@@@@
Некий бинарный мусор, который абсолютно не проясняет причину.
Для решения получения логов перед падением сервера уже давно существует нужное средство - netconsole, топорный модуль ядра, который отправит во вне лог, даже если уже ничего не работает на сервере. Мы до некоторого времени обычно действовали так: сервер начал падать, в IP-KVM не удается найти причину, настраиваем руками netconsole на источнике логов, на каком-то произвольном сервере в tmux-е открываем порт и начинаем ловить сообщения. Но хостер оказался такой, что уровень железного брака довольно высок (догадайтесь с 1-го раза кто :) ), плюс довольно часто некие баги ядра и пришло понимание, что настройку netconsole обязательно нужно настраивать для всех серверов. У всех в инфраструктуре могут использоваться разные Iac, у нас это saltstack, поэтому мы это сделали как-то так (на приемнике не забудьте заранее настроить syslog-ng/other programm). Думаю и для ansible можно сделать нечто подобное. В общем посыл статьи такой - используйте netconsole для разбора причин падений linux сервера, заранее автоматизируйте активацию и настройку модуля на сервере, это значительно ускорит разбор полетов, не потребуется снова ждать когда сервер упадет.
Также может быть оказаться полезной статья https://access.redhat.com/articles/2642741 - с помощью указанных способов можно научиться заранее понимать - штатно или нет произошло выключение сервера. Да, можно мониторить аптайм сервера и если он будет сброшен, то будет алерт в системе мониторинга с письмом в почтовом ящике (как вариант). Но возможен вариант, что сервер был перезагружен штатно, но например в системе мониторинга забыли на время отключить алерты для данного хоста. В общем, это еще один дополнительный вариант мониторинга "правильности" последнего ребута/старта хоста, который вполне может пригодиться.