Как вы исследуете сбой системы, когда нет записей / журналов?

TL; DR

  1. Как на самом деле исследовать сбой системы, когда журналы ничего не показывают?
  2. Во-вторых, как мне подготовиться? для будущих сбоев? Можно ли вести более агрессивное / точное ведение журнала? В случае, если система паникует или зависает так, что даже не успела войти в систему.

Несколько недель назад я получил 3 VPS-машины (KVM) от провайдера, и 2 из них вышли из строя через неделю (в случайное / разное время). Все они имели 512 МБ оперативной памяти (с 512 МБ подкачки).

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

Никто из них не выполнял каких-либо задач, интенсивно использующих процессор / память. Один из них был просто сервером openvpn (с 2-3 пользователями), а другой - просто nginx + php, обслуживающий статический сайт. У них обоих всегда было около 200-300 доступной памяти, а загрузка процессора была ниже 10%.

У меня был установлен мониторинг Netdata. Так что у меня была история почти всего. Я посмотрел каждый график и график прямо перед сбоем. Не было резкого скачка или внезапного увеличения использования CPU / Memory / Disk / Network / Process / Firewall.

Я посмотрел каждый лог-файл в /var/logs/. Я читаю их построчно (до сбоя). Я также использовал journalctl. Не было ни ошибок, ни предупреждений, ни нехватки памяти, ни процесса уничтожения, а просто обычных событий.

Оба сервера, которые потерпели крах, имели syslog, который выглядел так:

enter image description here Как вы можете видеть, ufw просто блокирует случайных спамеров прямо перед сбой, а затем нет журнала. Кроме того, загрузка, которую вы видите в 20:41:02, является принудительной / принудительной перезагрузкой, которую мы сделали после сбоя, просто чтобы вернуть систему в рабочее состояние.

Когда я спросил поставщика, они сказали, что все выглядит хорошо на их стороне, и причина, по которой мои серверы рухнули, была в том, что 512 МБ ОЗУ было слишком мало, и мне пришлось обновить.

Кроме того, есть 2 вещи, которые я случайно прочитал в Интернете, и я подумал, что спрашиваю здесь, являются ли они реальной вещью.

  • «Пики Micro RAM, например, вращение таблиц оперативной памяти на диск и т. Д.»
  • параметр под названием journal_data_writeback, что если он включен, система может пропустить запись журналов на диск во время сбоя .
1
задан 12 September 2019 в 03:53

1 ответ

После говорящий guiverc в комментариях, я понял, что мне на самом деле нужно было назвать пакет linux-crashdump. Но потому что сервер был установлен с помощью минимального шаблона Ubuntu, Он не произвел файлов журнала во время катастрофического отказа. Вот почему я ничего не мог найти.

Для любого, кто исследует их причину катастрофического отказа и задается вопросом, почему нет никаких файлов журнала в /var/crash, удостоверьтесь, что Вы устанавливаете linux-crashdump так, надо надеяться, в следующий раз у Вас может быть что-то для взгляда на ;)

1
ответ дан 7 December 2019 в 14:58

Другие вопросы по тегам:

Похожие вопросы: