Описание основных демонов (процессов) Zenoss.

В продолжение предыдущих разговоров по установке и настройке Zenoss Core, дадим описание основных демонов. Правда в предыдущих статьях речь шла про версию 3.х, здесь речь будет идти про 4.х, как наиболее актуальной. Итак начнем.

Zenoss Core имеет множество демонов (процессов), которые могут быть использованы для различных целей. Хотя вы можете не использовать все из них, но  понимание и представление о них иметь надо. Это поможет в решении конкретных требования по мониторингу Вашей инфраструктуры

В Zenoss v 4.x все демоны взаимодествуют с MySQL и zenhub. По умолчанию все процессы Zenoss запущены в информационном режиме (Info mode).

1. zeneventserver

В Zenoss 3.х обработкой событий руководил демон zenhub, но это было узким местом, которое вызывало некоторые проблемы с производительностью, поэтому в версии 4 был введен новый демон zeneventserver

Демон zeneventserver написан на Java, взаимодействует с RabbitMQ, выцепляет события из очереди  (zenoss.queues.zep.zenevents) и добавляет их а базу zenoss_zep, где они в дальнейшем и хранятся.

Другой задачей этого демона является извлечение информации о событии, связанном с ресурсами, общей информацией, первой доступности (first seen), последней доступности (last seen) и тд. в формате Java Script Object Notation [JSON], которая впоследствии отображается в веб-интерфейсе zenoss и передается в очередь событий  zenoss.queues.zep.signal. Установка нового Zenpack также затрагивает этот демон, т.к. создается новый класс событий (Event Class) 

Основные настройки -

cat /opt/zenoss/etc/zeneventserver.conf 
zep.jdbc.dbname=zenoss_zep
zep.jdbc.hostname=localhost
zep.jdbc.port=13306
zep.jdbc.password=xxxxxxx
zep.jdbc.username=xxxxxxx

Если мы остановим демон zeneventserver и проверим очередь rabbitmq командой rabbitmqctl -p /zenoss list_queues, мы увидим рост очереди zenoss.queues.zep.zenevents

Zeneventserver останавливаем от имени пользователя zenoss

# zeneventserver stop 
# rabbitmqctl -p /zenoss list_queues
Listing queues ...
celery  0
zenoss.queues.zep.migrated.summary      0
zenoss.queues.zep.migrated.archive      0
zenoss.queues.zep.rawevents     0
zenoss.queues.zep.heartbeats    0
zenoss.queues.zep.zenevents     14
zenoss.queues.zep.modelchange   0
zenoss.queues.zep.signal        0
...done.

Как только мы стартуем zeneventserver, то мы увидим что значение очереди вернется к нулю.

2. zenhub

Демон zenhub написан на python. Обработка событий срабатывает, когда zenhub демон получает данные от других демонов. В платной версии Zenoss включил рабочий процесс недействительности для лучшей производительности. В большинстве случаев Zenoss архитектура разворачивается как Linux VM (собранный образ виртуальной машины с Zenoss), в котором по-умолчанию работает только демон zenhub, это основная причина не отображения данных в веб-интерфейсе.

3. zenping

Демон zenping производит обычный ping до интерфейса отслеживаемого хоста с периодом опроса в одну минуту. Если интерфейс недоступен, zenoss генерирует предупреждения о критических событиях. Если интерфейс поднимается, zenoss автоматически очищает события об ошибках. zenping также используется для мониторинга, данные от которого могут быть использованы в графиках о доступности контролируемого устройства.

Ниже представлен пример ручного использования демона zenping, такая ситуация может возникнут при необходимости отладки.

zenping –d x.x.x.x –v10

где x.x.x.x – ip-адрес или DNS-имя устройства

4. zeneventd

Демон zeneventd  один из основных и служит для трансформации полученной информации (написан на Python для манипуляции событиями). Демон получает входящие события из очереди zenoss.queues.zep.rawevents и добавляет необходимую информацию такую как Device group/Device State, а также дополнительную информацию по событию, такую как время (например первое появление first seen, последнее появление last seen). Если демон прекращает работу, то можно увидеть увеличение очереди rawevents . Для отладки преобразования мы можем поставить log.info(‘For Debug’)  внутри кода, который будет выводиться в ‘/opt/zenoss/log/zeneventd.log’

# zeneventd stop 

# rabbitmqctl -p /zenoss list_queues
Listing queues ...
celery  0
zenoss.queues.zep.migrated.summary      0
zenoss.queues.zep.migrated.archive      0
zenoss.queues.zep.rawevents     12
zenoss.queues.zep.heartbeats    0
zenoss.queues.zep.zenevents     0
zenoss.queues.zep.modelchange   0
zenoss.queues.zep.signal        0
...done.

Для отладки можно использовать - 

# zeneventd run –d x.x.x.x –v10

?5. zensyslog

Демон zensyslog процесс сбора системных сообщений (var/log/messages), который получает информацию с отслеживаемых устройств на порту 514 (UDP)  

6. zenprocess

Демон zenprocess - демон мониторинга процессов, использующий  HOST-RESOURCES MIB, которые загружаются при начальной установке.  Zenprocess использует таблицу snmp и получает информацию о процессе, например PID, путь к исходнику, который выполняется и количество запущенных экземпляров и т.д. Период опроса демона zenprocess составляет 3 минуты (180 секунд). Невозможно изменить интервал на уровне устройства.

Ниже представлен пример команды для отладки:

zenprocess run –d x.x.x.x –v10

7. zenstatus

Демон zenstatus отслеживает  TCP/UDP сервисы которые доступны на устройстве, например http, https, net-bios и т.д.

8. zentrap

Демон zentrap принимает SNMP трапы, которые отсылают отслеживаемые устройства по порту 162 UDP. Демон декодирует входящие трапы в формат понятный Zenoss  (Python dictionary format, то бишь сопоставляет OID с MIB именами) и передает их zeneventd для дальнейшей обработки и генерации событий.

9. zenactiond

Демон Zenactiond запускает фоновые задания, такие как уведомления по электронной почте, проверку состояния базы данных, запуск различных обработчиков.  Zenactiond  также может обнаружить проблемы с подключением к ZODB или с базой данных MySQL. Т.к. эти два компонента критичны для работы системы, и если например один из них недоступен, то zenaction отправит уведомление на почту или телефон.

Zenaction взаимодествует с очередью сигналов в Rabbitmq и инициирует оповещение (почта, телефон и т.д.).

10. zenperfsnmp

zenperfsnmp демон собирает через snmpwalk метрики производительности, такие как процессор, память, использование файловой системы и сохраняет информацию в RRD [Round Robin Database] файлах, по-умолчанию интервал сбора данных составляет 300 сек. Временной интервал опроса не настраивается на уровне устройств, если мы его изменим, это отразится на глобальных настройках zenoss.

В режиме отладки можно использовать команду – 

zenperfsnmp run –d x.x.x.x –v10 

11. zencommand

Демон zencommand создан для обработки пользовательских сценариев через SSH, сложность заключается в том, что имя пользователя и пароль для SSH, должны быть заданы для каждого контролируемого устройства, что очень неудобно при их большом количестве.  Так мониторинг производительности производится путем настройки net-snmp на клиентском устройстве. 

zencommand run –d x.x.x.x –v10

12. zenmodeler

Демон Zenmodeler получает первичную информацию об устройстве, такую как интерфейсы, файловая система, IP-сервисы. По умолчанию интервал опроса составляет 12 часов. В основном он определяет изменения в конфигурациях устройств, например добавление нового интерфейса, нового раздела на диске и т.д.

Для проверки можно использовать –

zenmodeller run –d x.x.x.x –v10

13. zenrrdcached

Демон zenrrdcached служит для улучшения производительность, помогает кешировать RRD метрики в памяти, которые используются для генерации графиков в zenoss. Если демон не в состоянии вытащить метрики из памяти, он будет получать их из RRD-файлов, которые хранятся на диске.

14. zopectl

Демон zopectl вызывает zopeclient, который используется при разработке zenpack. Для применения изменений в течение разработки zenpack этот демон необходимо перезапустить.

zopectl restart

15. zenjobs

Демон zenjobs выполняет фоновые задачи, такие как обнаружение устройств в сети или добавление конкретного устройства, эти задачи будут добавлены в очередь и zenjobs обработает их. Как только устройство успешно добавлено (Discovered), дальнейшее моделирование происходит с помощью демона zenmodeler, а нам возвращается идентификатор задания. Если мы хотим  добавлять несколько устройств, то мы используем командную утилиту zenbatchload.

16. zenrdis

Демон zenrdis служит для построения распределенной карты сети, используя данные из коллектора на основании опроса (Ping) устройств.

В Zenoss каждый демон имеет конфигурационный файл, который находится в /opt/zenoss/etc/. По умолчанию все демоны работают в информационном режиме (Info Mode). Есть два способа включения режима отладки для демонов.

1.      Редактирование конфигурационного файла демона  - LogSeverity 10

2.      Имя демона + debug. Пример  zeneventd debug (переключить демон между Info режимом и режимом отладки)

Просматривая очередь RabbitMQ можно легко определить работает Zenoss без проблем или нет. Если мы найдем в очереди некоторые события которые повреждены, то необходимо перезагрузить демон отвечающий за выборку данных событий.