Презентация_Миронов

1.

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ФГБОУ ВО
«БРЯНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»
ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Кафедра «Информатика и программное обеспечение»
Дипломная работа
Развертывание системы мониторинга сервисов
с механизмом автоматического восстановления
их работоспособности
Руководитель:
к.т.н., доц. Израилев В.Я.
Студент:
гр. О-22-МОА-тп-Б Миронов М.Д.
БРЯНСК 2026

2.

Актуальность темы
Ручной контроль Linux-сервисов не всегда обеспечивает быструю реакцию, поэтому актуальна
система, которая автоматически проверяет сервисы, фиксирует инциденты и выполняет ограниченное
восстановление с повторной проверкой результата.
Проблема: ручной контроль не всегда
обеспечивает быструю реакцию на отказ сервиса
Остановка сервиса делает веб-интерфейс
недоступным
Важно хранить историю проверок и
инцидентов
Восстановление должно быть ограниченным
и проверяемым
Система должна показывать состояние
сервера и сервисов
Панель мониторинга с состоянием сервисов
02

3.

Цель и задачи работы
Цель: разработка системы мониторинга Linux-сервисов с механизмом автоматического восстановления.
Задачи:
1) Проанализировать предметную область и аналоги
2) Спроектировать архитектуру и структуру базы данных
3) Реализовать HTTP-, TCP- и systemd-проверки
4) Реализовать журналы, инциденты, политики L1-L3 и восстановление сервисов
5) Провести тестирование системы
Объект: процесс мониторинга состояния Linux-сервисов и
восстановления их работоспособности
Предмет: методы проверки состояния, регистрации
инцидентов и автоматического восстановления служб
03

4.

Сравнение аналогов
Критерий
Zabbix
Kubernetes
Systemd
Система проекта
Назначение
Мониторинг
инфраструктуры
Управление
контейнерными
приложениями
Управление Linuxслужбами
Мониторинг и
восстановление Linuxсервисов
Объекты контроля
Серверы, сети, приложения
Контейнеры, pod, узлы
кластера
Локальные systemd-службы
HTTP-, TCP- и systemdсервисы
Наблюдение и журналы
Веб-интерфейс, история
событий
События кластера и логи
контейнеров
Командная строка и
journalctl
Веб-интерфейс, журналы
проверок, инцидентов и
восстановлений
Восстановление
Через действия, скрипты и
команды
Self-healing контейнеров
Restart / systemctl restart
Политики L1–L3,
ограничение попыток и
повторная проверка
Соответствие задаче
Мощный, но избыточный
Требует контейнеров и
кластера
Полезен как механизм, но
недостаточен как система
мониторинга
Соответствует теме и
реализованной среде
04

5.

Функциональная модель
05

6.

Исследовательская часть
Цель исследования: сравнить подходы к автоматическому восстановлению серверных служб и выбрать
рациональный вариант для Linux-сервисов.
Подход
Сильная сторона
Ограничение
Выбран комбинированный подход
Простой restart
Быстрый и простой
Не подтверждает результат
systemd
Встроен в Linux
Нет полной логики
инцидентов
Повторная
проверка
Подтверждает доступность
сервиса
Требует дополнительной
логики
Ограничение
попыток
Защищает от бесконечного
цикла restart
Нужны политики и счётчики
Комбинированный
подход
Инцидент + восстановление
+ повторная проверка +
эскалация
Сложнее в реализации
• HTTP-, TCP- и systemd-проверки
состояния
• регистрация инцидента при сбое
• проверка политики реакции L1–L3
• ограниченный restart nginx через
systemd
• повторная проверка результата
• фиксация действия в журнале
восстановления
06

7.

Архитектура системы
Основные компоненты системы мониторинга Linux-сервисов
07

8.

Проектная диаграмма
08

9.

Себестоимость проекта
Плановая себестоимость разработки системы мониторинга
Linux-сервисов составила примерно:
1 600 000 руб.
44%
Основная зарплата
Элемент
Доля
Основная зарплата
44,47%
Прочие расходы
23,08%
Отчисления
15,34%
Аренда
6,68%
Доп. зарплата
6,67%
Амортизация
2,81%
ПО и материалы
0,96%
Доп. зарплата
7%
Отчисления
Аренда
Амортизация
ПО
Материалы
15%
Прочие расходы
23%
3%
7%
0% 1%
10

10.

Выводы и дальнейшее развитие
11
Вывод:
• Проведён анализ предметной области и аналогов мониторинга
• Исследованы подходы к автоматическому восстановлению Linux-сервисов
• Спроектирована архитектура веб-приложения на Flask и SQLite
• Реализованы HTTP-, TCP- и systemd-проверки, журналы и инциденты
• Реализовано восстановление сервисов с политиками L1-L3
Дальнейшее развитие:
Уведомления администратора по email или месседжерам
Расширение списка сервисов для восстановления
Добавление новых типов проверок
Роли пользователей и отчёты по инцидентам
Перенос системы на отдельный сервер

11.

СПАСИБО ЗА ВНИМАНИЕ!