Shinken (программное обеспечение)

Архитектура Shinken направлена на упрощение балансировки нагрузки и обеспечение высокой доступности. Администратор управляет одной конфигурацией, которую система автоматически делит на части и распределяет между рабочими узлами. Название связано с этой особенностью: «Shinken» — это японский меч.

Shinken был написан Жаном Габесом в качестве концепта новой архитектуры Nagios. Считая новый вариант более быстрым и гибким по сравнению со старой реализацией на C, автор предложил сделать Shinken основной веткой разработки Nagios 4^[1]. Это предложение было отклонено авторами Nagios, и Shinken стал независимым программным обеспечением для мониторинга сетей, совместимым с Nagios^[2].

Shinken работает под управлением всех операционных систем, поддерживающих Python. Основная разработка ведётся под Linux, однако программа также хорошо функционирует на других Unix-системах и Windows. Процесс reactionner (отвечающий за отправку уведомлений) может быть запущен и под Android. Программа распространяется по лицензии GNU Affero General Public License и является свободным программным обеспечением.

• Архитектура
  • Мониторинговая система, написанная на Python
  • Распределённая архитектура с использованием Pyro (удалённые объекты)
• Активный и пассивный мониторинг
  • Мониторинг сетевых сервисов (SMTP, POP3, HTTP, NNTP, ICMP, SNMP, FTP, SSH)
  • Мониторинг ресурсов узлов (загрузка процессора, использование диска, системные журналы) на большинстве операционных систем для сети, включая Microsoft Windows
    • Использование агентов, таких как NSClient++, send_nsca, Check MK, Thrift TSCA
    • Использование агентов, позволяющих удалённо запускать скрипты через NRPE (встроенная реализация на Python входит в состав Shinken)
    • Агент-независимые методы: SNMP, WMI, сценарии SSH или HTTP(SSL)
    • Поддержка передачи результатов проверок напрямую через программы с использованием Apache Thrift (Java, Python, Ruby)
  • Мониторинг систем, отправляющих собранные данные по сети в специальные модули (например, VMWare ESX3/4/5, Collectd)
  • Поддержка удалённого мониторинга через SSH или SSL-туннели
  • Простой формат плагинов с возможностью создавать собственные проверки на любом языке (shell-скрипты, C++, Perl, Ruby, Python, PHP, C# и др.)
  • Расчёт KPI на основе статуса и производительных данных для формирования новых сервисов и метрик
• Внешние интерфейсы
  • Совместимость с Livestatus API для получения статуса, конфигурации и производительной информации
  • Экспорт данных в модули визуализации (PNP4Nagios, Graphite и др.)
  • Поддержка нативной системы сообщений Android
  • Экспорт событий в системы логирования через syslog и RabbitMQ
  • Модули могут быть подключены к любому процессу Shinken для расширения функциональности
• Производительность
  • Параллельное выполнение проверок сервисов и узлов
  • Возможность распределять процессы опроса по нескольким серверам
  • Поддержка резервирования и балансировки узлов мониторинга
  • Поддержка нескольких резервных внешних интерфейсов
  • Маршрутизация проверок на специальные процессы-опросчики
• Корреляция и бизнес-логика
  • Иерархия «родитель—потомок»
    • Определение иерархии узлов для различения между недоступными и неработающими узлами
    • 1:1, 1:N
  • Произвольные деревья зависимостей между сервисами и узлами
    • 1:1, 1:N
  • Интеграция бизнес-правил
    • Автоматизированные сервисы и узлы, отражающие состояние бизнес-процессов
    • Возможность присвоения бизнес-важности каждому сервису, узлу или процессу
  • Вывод только корневых проблем
  • Автоматическое присваивание статуса unknown потомкам при недоступности родителя
• Дополнительные возможности
  • Уведомления о проблемах и их решении (e-mail, пейджер, SMS, либо произвольные методы через плагины)
  • Определение обработчиков событий для автоматического реагирования
  • Переклассификация степеней оповещений на основе регулярных выражений
  • Поддержка имён объектов в UTF-8
  • Мониторинг нескольких клиентов с единой административной точкой
  • Рецидивная система простоев через параметр maintenance_period
  • Расширенная система шаблонов с наследованием и переопределением

Она состоит из нескольких процессов, каждый из которых оптимизирован под определённую задачу.

• Arbiter (арбитр)
  • Загружает конфигурационные файлы и распределяет объекты узлов и сервисов по планировщикам
  • Наблюдение за процессами и инициирование аварийного переключения при ошибках
  • Маршрутизация результатов проверок от Receiver к связанному Scheduler
  • Модули арбитра
    • Существуют различные модули для работы с конфигурацией
• Scheduler (планировщик)
  • Планирует выполнение проверок сервисов и узлов
  • Передаёт задания для опроса процессам Poller
  • Вычисляет статусы и зависимости
  • Применяет KPI-триггеры
  • Формирует уведомления и передаёт их процессу Reactionner
  • Обновляет файл или базу хранения состояний
  • Отправляет внутренние события (broks) брокерам
• Poller (опросчик)
  • Получает проверки от Scheduler, выполняет плагины или встроенные модули и отправляет результаты Scheduler
  • Модули Poller
    • NRPE — опрос данных через NRPE‑агенты
    • SNMP — активный опрос SNMP‑агентов (на основе PySNMP)
    • CommandPipe — получение пассивных данных от check_mk-скриптов, не обрабатывает команды
• Reactionner (реакционер)
  • Получает уведомления и обработчики событий, выполняет плагины/скрипты и возвращает результаты Scheduler
• Broker (брокер)
  • Содержит несколько модулей (обычно отдельные процессы)
  • Получает внутренние события (broks) от Scheduler и перенаправляет их в соответствующие модули
  • Модули определяют, обрабатывать ли событие по его типу (лог, статус, результаты проверок и т. д.)
  • Основные модули:
    • webui — обновляет внутренние объекты и предоставляет веб-сервер для нативного интерфейса Shinken
    • livestatus — обновляет внутренние объекты, доступные через API для Thruk или Check_MK Multisite
    • graphite — экспортирует данные в базу Graphite
    • ndodb — обновляет базу NDO (MySQL или Oracle)
    • simple_log — собирает логи процессов Shinken
    • status_dat — пишет статус в status.dat для классического CGI-интерфейса
• Receiver (опционально)
  • Принимает данные через локальные или удалённые протоколы
  • Буферизует пассивные данные перед передачей Scheduler (или Arbiter для глобальных команд)
  • Возможна организация кластера Receiver для обработки большого числа событий
  • Модули Receiver
    • NSCA — получение данных по протоколу NSCA
    • Collectd — получение данных производительности от collectd по сети
    • CommandPipe — прием команд, обновлений статуса и метрик
    • TSCA — интерфейс Apache Thrift для передачи результатов проверок с помощью буферизованного TCP-подключения от программ
    • Web Service — веб-сервис для приема результатов через HTTP POST (бета)

Для каждого типа процессов может существовать несколько экземпляров — на одном или на разных серверах, нагрузка между ними распределяется автоматически.

Shinken WebUI — встроенный веб-интерфейс для показа в реальном времени состояния, конфигурации, взаимодействия, дашборда для визуализации трендов из базы Graphite, а также отображения графов зависимостей.

Shinken skonfUI — независимый веб-фронтенд для управления автоматическим обнаружением и настройкой системы.

Сценарий командной строки shinken-admin — для управления процессами во время работы (изменение уровня логирования, диагностика и др.).

Сценарий install.sh — основной инструмент для установки, удаления и обновления Shinken и сопутствующих компонентов.

Shinken разрабатывается с открытым и тест-ориентированным подходом: участники проекта реализуют новые функции, рефакторинг, контроль качества и исправление ошибок^[3].

Исходный код размещается на GitHub^[4]. Также развёрнут интеграционный сервер, который выполняет автоматические тесты при каждом коммите и регулярные расширенные проверки.

Документация по Shinken размещена на wiki.