Sysmonitor — облегчённая система мониторинга сервера
Сегодня в нашей статье мы рассмотрим супер-облегчённую систему мониторинга, которая предназначена исключительно для локального использования. В ней нет привычного нам традиционного разделения на сервер мониторинга, который собирает метрики от агентов и складирует их в СУБД и собственно агентов мониторинга, разбросанных по серверам в сети. Данный проект демонстрирует минималистский подход, по сути сводя всю систему мониторинга к запущенному процессу sysmonitor и сообщениям в файле лога /var/log/sysmonitor.log. Никаких посылок сообщений на почту, telegram (или ещё массу всевозможных приёмников сообщений) тут нет. Только лог, ничего больше.
Особенности sysmonitor
Возможности sysmonitor перечислены на схеме (взята с сайта https://docs.openeuler.org/):
Из схемы мы видим, что возможности sysmonitor покрывают следующие виды мониторинга:
- ошибки при работе файловых систем;
- ключевых процессов (если потребуется, у sysmonitor есть возможность выполнить команды для восстановления процесса);
- слежения за важными файлами и фиксации в лог событий их удаления или изменения;
- использования разделов диска;
- статусов сетевых адаптеров;
- использования CPU (при этом можно следить за конкретным ядром);
- использования памяти;
- количества процессов/потоков;
- файловых дескрипторов;
- количества inode смонтированных файловых систем;
- задержки i/o дисковой подсистемы;
- количества зомби процессов;
- Также sysmonitor позволяет создавать собственные варианты мониторинга, по параметрам, которые выберет сам системный администратор.
Все основные настройки относящиеся к процессу sysmonitor можно увидеть в файле: /etc/sysconfig/sysmonitor. С подробностями параметров настройки можно ознакомится в документации.
Установка и настройка sysmonitor
Тестирование данной системы мониторинга мы будем проводить на недавно вышедшей версии OpenScaler 24.03 LTS (x86_64).
Для этого мы развёрнём виртуальную машину с данной ОС с следующими характеристиками:
- 4 CPU
- 4 Гб ОП
- основной диск (на который установлена ОС) — 32 Гб
- диск для проведения тестирования — 1 Гб
Сначала залогинимся в систему под пользователем root и выполним установку sysmonitor.
Для этого мы используем команду:
# dnf install sysmonitor-kmod
Активируем службу sysmonitor:
# systemctl enable --now sysmonitor
После запуска все сообщения (согласно настройкам по умолчанию пакета sysmonitor) об интересующих нас событиях в ОС будут записываться в файл /var/log/sysmonitor.log
Всё, на этом мы уже имеем (да, настроенный по умолчанию, но вполне работающий) мониторинг!
Практический пример использования sysmonitor
Настало время проверить sysmonitor на практике. Для этого давайте попробуем реализовать простенький мониторинг такого параметра, на который мы легко сможем повлиять. Речь идёт о количестве inode на смонтированной файловой системе.
Собственно, для этого мы и цепляли к нашей виртуальной машине ещё один диск размером в 1 Гб.
Итак, подключаемся к нашей виртуальной машине (к примеру по ssh) и настраиваем наш дополнительный диск для проведения тестирования. Для этого мы нарежем одну большую партицию на этом диске и создадим на ней файловую систему:
# parted /dev/sdb mklabel gpt
# parted -- /dev/sdb mkpart testdata ext4 1MiB -1
# mkfs.ext4 /dev/sdb1
# mkdir /test && mount /dev/sdb1 /test
Проверяем сколько у нас inode:
# df -i /test/
/dev/sdb1 65408 13 65395 1% /test
Отлично, мы видим, что наша испытуемая партиция практически пустая.
Теперь добавим слежение за /test в настройку sysmonitor, для этого редактируем файл /etc/sysmonitor/inode
И добавляем в него строчку:
DISK="/test" ALARM="80" RESUME="70"
Делаем reload службе sysmonitor, чтобы она перечитала конфигурационные файлы:
# systemctl reload sysmonitor
При проведении тестирования будет не лишним самим следить за количеством используемых inode на тестовом диске, для этого оставим в этом терминале следующую проверку:
# watch -n1 df -i /test/
Таким образом, мы будем каждую секунду иметь перед глазами актуальную информацию о количестве inode на /test.
Теперь давайте откроем дополнительно ещё два терминала на нашей виртуальной машине.
В одном из них мы запустим слежение за событиями в логе sysmonitor:
# tail -f /var/log/sysmonitor.log
А на последнем терминале мы будем запускать команды по заполнению файловой системы /test тестовыми данными с целью уменьшения количества свободных inode.
Итак, у нас всё готово для старта тестирования и на нашем последнем терминале мы запускаем:
# cd /test; for i in {1..80000}; do echo $i; touch file-$i; done
В самом первом терминале, где мы следим за количеством inode мы видим как постепенно уменьшается количество свободных inode:
/dev/sdb1 65408 4441 60967 7% /test
...
/dev/sdb1 65408 13517 51891 21% /test
...
/dev/sdb1 65408 31808 33600 49% /test
...
/dev/sdb1 65408 44550 20858 69% /test
...
/dev/sdb1 65408 52602 12806 81% /test
...
/dev/sdb1 65408 61183 4225 94% /test
...
Пока, наконец, количество свободных inode не подходит к 0:
/dev/sdb1 65408 65408 0 100% /test
В терминале, где мы следим за логом sysmonitor.log мы видим сообщение вида:
2024-07-29T11:55:50.771293+03:00|warning|sysmonitor[1027]: report disk inode alarm, /test used:100% alarm:80%
Теперь удалим наши тестовые файлы и освободим файловую систему /test (команду выполняем на нашем последнем терминале):
cd /test; rm -f file-*
В логе sysmonitor.log видим сообщение:
2024-07-29T11:56:50.775129+03:00|info|sysmonitor[1027]: report disk inode recovered, /test used:1% resume:70%
Собственно это всё. Что именно делать при появлении сообщения об обнаруженной проблеме в логе sysmonitor — решать уже администратору системы. Может быть написать скрипт для парсинга лога по ключевым словам и отправки сообщений в telegram, или просто вывода содержимого этого лога на большой экран оператора. Здесь уже открывается простор для творчества. Главное — система фиксирует события и пишет об этом в лог.
Подведение итогов
Подытожим. Сегодня мы рассмотрели очень простую в настройке и легковесную систему мониторинга ОС по множеству параметров, которая с лёгкостью найдёт своего потребителя, который (по тем или иным причинам) не будет заинтересован в установке выделенного сервера под классическую систему мониторинга.