Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 5. Отключение неиспользуемых служб клиента Icinga (классический вариант)

Как понятно из предыдущей заметки, в используемой у нас конфигурации по умолчанию (с учётом ранее установленных плагинов) как сам сервер Icinga, так и подключенные к нему клиенты имеют 12 наблюдаемых служб (Services в терминологии Icinga, не путать с системными службами Linux). При этом, на представленной в нашем примере клиентской Linux-системе с именем KOM-AD01-APP31 (Linux-сервер на базе Debian 8.6) 3 службы имеют статус CRITICAL.

В данном случае состояние службы "apt" объяснимо, так как на клиентской системе в менеджере пакетов APT есть 17 неустановленных критических обновлений. А вот службы "http" и "ping6" попросту в системе не настроены или не используются.

Отключить отслеживание за состоянием служб, не требующих мониторинга, можно разными способами - как на стороне сервера, так и на стороне клиента.

Отключение службы на стороне сервера Icinga

На стороне сервера можно удалить или переименовать конфигурационный файл отвечающий за запуск мониторинга соответствующей службы из каталога /etc/icinga2/repository.d/hosts/{FQDN имя клиента}/, который наполняется в процессе выполнения команды icinga2 node update-config :

# cd /etc/icinga2/repository.d/hosts/KOM-AD01-APP31.holding.com/
# mv ping6.conf ping6.conf.disabled
# mv http.conf http.conf.disabled
# service icinga2 reload

Либо можно воспользоваться следующей последовательностью команд (более корректный метод):

# icinga2 repository service list 
# icinga2 repository service remove name=http host_name=KOM-AD01-APP31.holding.com
# icinga2 repository service remove name=ping6 host_name=KOM-AD01-APP31.holding.com
# icinga2 repository commit
# service icinga2 reload

Здесь первой командой мы получим полный список служб со всех клиентских хостов Icinga, который в данный момент есть в текущей конфигурации сервера, второй и третьей командой удалим из текущей конфигурации записи о службах конкретного клиента и последними двумя командами применим изменения.

Сразу после этого картина о состоянии хоста на веб-консоли Icinga изменится и ненужные службы исчезнут:

Однако при следующей же попытке выполнения команды обновления конфигурации Master-сервера (icinga2 node update-config) всё снова вернётся в исходное состояние, так как в конфигурации клиента отключенные службы остались без изменений и он по прежнему присылает на сервер информацию о своей старой конфигурации (смотри вывод команды icinga2 node list).

При этом ранее удалённые/переименованные нами конфигурационные файлы http.conf и ping6.conf будут восстановлены в каталоге /etc/icinga2/repository.d/hosts/{FQDN имя клиента}/.

Поэтому выполнять отключение ненужной службы мониторинга всё же лучше на стороне клиента.

Отключение службы на стороне клиента Icinga

Перейдём на клиентский компьютер и изменим конфигурационный файл services.conf:

# nano /etc/icinga2/conf.d/services.conf

Достаточно просто закомментировать соответствующие службы по аналогии с тем, как написаны комментарии в конфигурационном файле:

После этого проверим конфигурацию и перезапустим службу icinga2 на клиентской системе:

# /etc/init.d/icinga2 checkconfig

[ ok ] checking Icinga2 configuration.

# service icinga2 restart

Вернёмся на сервер Icinga и запросим информацию о службах, которые предоставляют клиенты:

Как видим, из списка служб исчезли закомментированные нами ранее на клиенте службы. Теперь, после того, как мы обновим конфигурацию сервера…

# icinga2 node update-config
# service icinga2 reload

… всё окончательно встанет на свои места и ненужные нам службы окончательно будут отключены в конфигурации на стороне сервера:

Ну и соответственно, если возникнет необходимость снова включить мониторинг отключенных служб, то мы поступим обратным образом, то есть уберём комментарии служб на клиентской системе в файле /etc/icinga2/conf.d/services.conf и затем выполним обновление конфигурации клиента и сервера.

Обратите внимание на то, что наш клиент был подключен к Master-серверу в режиме Bottom Up, о о котором мы упоминали в прошлый раз. Полагаю, здесь будет уместно остановится на кратком описании достоинств и недостатков данного режима работы.

К достоинствам можно отнести, такие особенности как:

• Индивидуальный список проверок на каждом клиенте;
• Индивидуальный список дополнительных объектов на клиенте (группы, уведомления, фронт энды и т.д.)
• Простота и гибкость конфигурации (установка клиента, настройка режима Satellite, настройка отправки результатов поверок Master-серверу)

Недостатки, как это не парадоксально, вытекают из вышеперечисленных достоинств. А именно:

• Вам необходимо отдельно конфигурировать каждого клиента
• Настроенные дополнительные объекты клиента не синхронизируются на Master-сервер, только результаты проверок. Например, вы настроили проверку дисков и добавили мнемоническое описание, на фронт-энде клиента оно будет видно, а на Master-сервере - нет.

Если для решения вопроса индивидуальных конфигурационных файлов необходимо использовать ПО контроля и распространения конфигурации (Puppy, Chief, Ansible, SCCM и т.п.), то вопрос синхронизации индивидуальных объектов уже не решается простыми методами (частично возможно дублирование конфигурации, но для очень ограниченного числа объектов).

Несмотря на описанные недостатки, режим Bottom Up может успешно применяться для создания независимых удаленных конфигураций с минимальным контролем. Однако постепенно желательно всё же перестраиваться на использование режима Top Down. Примером реализации подобного режима является Icinga Director, который мы уже установили ранее и будем рассматривать в следующей части.