По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев.
Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе Linux для устранения таких сценариев.
Проверка времени перезагрузки
Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last
Проверка системных журналов
Кроме того, можно сопоставить время перезагрузки, которую требуется диагностировать, с системными сообщениями.
Для систем CentOS/RHEL журналы можно найти по адресу /var/log/messages, а для систем Ubuntu/Debian - по адресу /var/log/syslog. Для фильтрации или поиска конкретных данных можно использовать команду tail или любимый текстовый редактор.
Как видно из приведенных ниже журналов, такие записи предполагают завершение работы или перезагрузку, инициированную администратором или пользователем root. Эти сообщения могут варьироваться в зависимости от типа ОС и способа запуска перезагрузки или завершения работы, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя этого не всегда может быть достаточно, чтобы определить причину.
Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов:
sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel'
/var/log/messages /var/log/syslog /var/log/apcupsd*
| grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups'
Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы.
Проверка журнала auditd
Для систем, использующих auditd – это отличное место для проверки различных событий с помощью инструмента ausearch. Используйте приведенную ниже команду для проверки последних двух записей из журналов аудита.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Появится сообщение о двух последних остановках или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN, за которым следует SYSTEM_BOOT, все должно быть хорошо. Но, если он сообщает две строки SYSTEM_BOOT подряд или только одно сообщение SYSTEM_BOOT, то, скорее всего, система некорректно завершила работу. Вывод при нормальной работе должен быть примерно следующим:
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
В приведенных ниже выходных данных перечислены два последовательных сообщения SYSTEM_BOOT, которые могут указывать на аварийное завершение работы, хотя результаты нужно скорректировать с данными системного журнала.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
Анализ журнала systemd
Чтобы сохранить журнал системных логов на диске, необходимо иметь постоянный системный журнал, иначе логи будут очищаться при перезагрузке. Для этого можно либо внести изменения в /etc/systemd/journald.conf, либо создать каталог самостоятельно с помощью следующих команд:
$ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald
После этого можно дополнительно перезагрузить систему для ввода нескольких записей перезагрузки в журнал, хотя это и не требуется.
Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала:
$ journalctl --list-boots
Вот его выходные данные на моем сервере:
Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте:
$ journalctl -b {num} –n
Здесь {num} будет индексом, заданным в команде journalctl --list-boots в первом столбце.
В приведенных выше выходных данных можно просмотреть сообщения, зарегистрированные в журнале, и отследить аномалии, если таковые имеются.
Заключение
Не всегда можно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Поэтому всегда удобно знать команды и журналы, которые фиксируют события, связанные с системой, и могут сократить время, необходимое для поиска первопричины.
Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.
Мы продолжаем заниматься автоматизацией нашей ИТ – инфраструктуры и сегодня хотим рассказать о простом и надежном методе мониторинга IP – АТС Asterisk в типовой SOHO – сети с помощью маршрутизатора Mikrotik. С помощью сетевой утилиты Netwatch мы настроим почтовые уведомления в случае недоступности нашего Asterisk.
Что такое Netwatch?
В операционной системе Mikrotik Router OS «зашит» достаточно богатый функционал для маршрутизатора его ценовой категории. Одним из очень полезных элементов этого функционала является сетевая утилита Netwatch. Работает она достаточно просто – отправляя через указанный промежуток времени ICMP – запросы маршрутизатор отслеживает состояние хоста, который подлежит мониторингу. Другими словами, роутер отправляет «пинг» на хост через определенный интервал (по умолчанию 1 минута), и если в течении таймаута хост не отвечает, то он считается недоступным.
Внимательно отнеситесь к подбору значений interval и timeout, так потенциально, повышенное значение первого может создать излишнюю нагрузку на маршрутизатор, а второй параметр, при наличии большой задержки у вас на сети, может привести к некорректному определению недоступности хоста.
Настройка SMTP на Mikrotik
Чтобы сетевая утилита работала корректно, необходимо настроить учетную запись. Настройки произведем на примере SMTP от Yandex. Переходим во вкладку Tools -> Email
Server - укажите здесь почтовый сервер для исходящей почты smtp.yandex.ru
Port - указываем 465 порт для безопасного соединения по протокол SMTP
Start TLS - указываем tls only
From - адрес электронной почты, который будет в письмах в качестве адреса отправителя
User - логин на почтовом сервере Яндекса
Password - пароль от почты
Нажимаем Apply. Далее, проверим наши настройки. Нажмите на кнопку Send Email:
Address - в данном случае наш Микротик преобразовал доменное имя smtp.yandex.ru в IP – адрес.
Port - так же указываем 465
User - логин пользователя почтой
Password - пароль от почтового аккаунта
TLS - отметьте галочкой
To - адрес получателя письма
From - укажите адрес отправителя
Subject - тема письма
Body - сообщение
По окончанию нажимаем на кнопку Send Email. У нас появилось отправленное письмо:
Мониторинг Asterisk с помощью Netwatch
После того как мы проверили отправку почты, приступаем к настройке сетевого мониторинга. Переходим во вкладку Tools -> Netwatch:
Ранее, мы рассказывали как настроить мониторинг пиров и транков на IP – АТС Asterisk.
Host - в данном поле укажите IP – адрес вашего Asterisk
Interval - интервал, через который будут отправлять ICMP запросы (пинги) на IP – АТС Asterisk. По умолчанию интервал равен 00:01:00 (1 минута)
Timeout - таймаут, в течение которого, хост мониторинга должен ответить на запросы. Если это время будет превышено, то хост будет считаться недоступным. По умолчанию, 1000мс (1 секунда)
Далее нажимаем на вкладку Up, в которой необходимо настроить скрипт, который будет отработан при доступности Asterisk. Скопируйте скрипт ниже, предварительно указав в поле to вашу почту :
tool e-mail send to=info@merionet.ru subject="Asterisk доступен" body="Asterisk доступен по сети"
Далем тоже самое для вкладки Down, в которой будет выполняться скрипт по недоступности Asterisk. Не забудьте изменить почту:
tool e-mail send to=info@merionet.ru subject="Asterisk не доступен!" body="Сервер IP – АТС Asterisk не доступен по протоколу ICMP – необходимо проверить"
По окончанию настроек нажмите Apply и OK.
В продолжение нашей статьи про настройку Netflow на маршрутизаторах Mikrotik, сегодня мы расскажем про Ntopng — приложение, которое анализирует трафик в вашей сети. Устанавливать будем на CentOS 7.
Установка
Ntopng не доступен в дефолтных репозиториях CentOS 7, поэтому предварительно нам нужно будет выполнить определенные действия по их добавлению. Сперва, выполните команду по добавлению EPEL репозитория:
sudo yum install epel-release
Затем необходимо создать ntop репозиторий. Для этого нужно будет создать файл ntop.repo внутри директории /etc/yum.repos.d - для этого введите команду sudo nano /etc/yum.repos.d/ntop.repo.
В данный файл добавьте следующие строки:
[ntop]
name=ntop packages
baseurl=http://www.nmon.net/centos-stable/$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://www.nmon.net/centos-stable/RPM-GPG-KEY-deri
[ntop-noarch]
name=ntop packages
baseurl=http://www.nmon.net/centos-stable/$releasever/noarch/
enabled=1
gpgcheck=1
gpgkey=http://www.nmon.net/centos-stable/RPM-GPG-KEY-deri
Для создания файла, конечно же, можно использовать любой текстовый редактор — не только nano. Но если хотите дотошно следовать инструкции, то, вероятно, сначала текстовый редактор придется установить с помощью команды yum install nano -y. После добавления нужных строк в файл сохраните изменения с помощью сочетания клавиш CTRL+O, и выйдите из файла командой CTRL+X.
Теперь переходим к непосредственно установке — выполните команду
sudo yum --enablerepo=epel install redis ntopng -y
. После этого просто соглашайтесь со всеми пунктами, и, спустя минут 5, все должно быть установлено.
Запуск сервисов и настройка ntopng
После установки ntopng, необходимо установить hiredis-devel пакет и запустить redis сервер до старта ntopng:
sudo yum --enablerepo=epel install hiredis-devel
Затем запускаем redis сервис и разрешаем ему автозапуск — и тоже самое делаем с ntopng.
sudo systemctl start redis.service
sudo systemctl enable redis.service
sudo systemctl start ntopng.service
sudo systemctl enable ntopng.service
Далее, проверим, работает ли ntopng командой sudo systemctl status ntopng.
Затем, превратим наш ntopng в бесплатную версию — для этого нужно отредактировать конфиг командой sudo nano /etc/ntopng/ntopng.conf и изменить строку:
-G=/var/tmp/ntopng.pid
на строку:
-G=/var/tmp/ntopng.pid
--community
После чего, сохраним и выйдем из файла и перезапустим ntopng:
sudo systemctl restart ntopng
Последний шаг — настроим фаерволл и перезагрузим его. Настройка заключается в разрешении порта 3000.
sudo firewall-cmd --permanent --add-port=3000/tcp
sudo firewall-cmd --reload
Первый запуск ntopng
Теперь осталось перейти по следующему адресу: http://yourhostip:3000. Логин и пароль по умолчанию — admin. Сразу после этого вам предложат изменить пароль.
Далее, вы увидите дэшборд, с разнообразной информацией, примерно как на скриншоте ниже:
Для понимания возможностей данного приложения — попробуйте посмотреть хосты, сети и прочие — в общем, попробуйте освоиться с функционалом.
Заключение
Всем спасибо за внимание, многие крупные вендоры сейчас уделяют особое внимание протоколу Netflow и придумывают различные сценарии применения. Как это может быть полезно именно для вас, пара примеров: после недельного анализа вашей сети вы поймете, что она была недостаточно сегментирована, или увидите какие-то подозрительные потоки. Дайте нам знать, если вам интересна более подробная настройка ntopng и софта, подобного ему — обязательно напишем про это статью! :).