Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 6. Базовая настройка конфигурации Icinga с помощью Icinga Director

В этой части мы поговорим о теоретических аспектах управления конфигурацией Icinga и рассмотрим использование ранее развёрнутого модуля Icinga Director версии 1.2.0 для управления конфигурацией Icinga. Кроме того, на практических примерах будет рассмотрена базовая настройка таких объектов конфигурации Icinga Director, как Службы (Service), Шаблоны Хостов (Host Template) и Хосты (Host).

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

 

Об управлении конфигурацией клиентов Icinga

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

• Ручная настройка конфигурационных файлов методом самостоятельного их создания/удаления и их прямой правки. Этот способ является классическим вариантом управления конфигурацией и является самым трудоёмким, но в тоже время самым гибким. Упрощённый пример такой настройки мы рассмотрели в прошлой части.
• С помощью веб-инструмента Icinga Director. Этот способ выводит управление конфигурацией Icinga на новый уровень и позволяет сделать его более удобным, так как он реализует управление всеми конфигурационными файлами через веб-интерфейс Icinga Web 2. По сути это GUI реализация механизма Top Down, но с некоторыми методологическими изменениями и другими подходами к решению задач. Именно этот способ мы и будем рассматривать в рамках нашей серии заметок об Icinga.
• С помощью разных сторонних средств автоматизации, таких как Puppet и ему подобных.

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

При использовании Icinga Director желательно отказаться от прямого ручного создания и правки конфигурационных файлов Icinga, чтобы свести к минимуму возможные конфликты между ручной конфигурацией и конфигурацией, которую генерирует Director. Именно поэтому самым идеальным вариантом для работы с Icinga Director будет наличие свежей чистой инсталляции Icinga 2 с модулем Icinga Web 2. При этом у вас всегда остается сценарий миграции файлов конфигурации в Icinga Director, но данный способ мы оставим за пределами данной статьи. Также важно знать и то, что Icinga Director не вносит никаких правок в классические конфигурационные файлы Icinga расположенные в каталоге /etc/icinga2, а имеет свою независимую конфигурацию. Конфигурация хранится в созданной нами базе MySQL,и выгружается в текстовый вид для чтения серверной частью Icinga. Эти файлы вы можете посмотреть, как из Icinga Director, так и в файловой системе. В файловой системе текущую и последнюю конфигурации можно найти в каталоге /var/lib/icinga2/api/packages/director, а в веб-интерфейсе Icinga Director, если перейти в Overview/Config Deployment и нажать кнопку Render Config, вам для просмотра будут доступны выгруженные файлы конфигурации. Обратите внимание на то, что не стоит напрямую редактировать выгруженные файлы конфигурации в файловой системе, - для работы используйте только графический интерфейс или API.

Конфигурация Icinga Director спроектирована таким образом, что в случае, если работа с Icinga Director приводит нас к тупику и неработающей конфигурации, то мы всегда сможем попросту удалить этот модуль и вернуться на классическое управление конфигурацией без вреда основной базовой системе Icinga. Icinga Director хранит созданную в нём конфигурацию и все изменения с возможностью отката на предыдущие версии конфигураций. Такие временные слепки конфигурации, между которыми отслеживаются все изменения называются Stages, то есть на каждый момент времени, когда была изменена конфигурация и выполнен её успешный Deploy, имеется свой Stage, в котором хранятся все конфигурационные файлы.

      

Об объектах конфигурации Icinga Director

Внутри своей конфигурации Icinga Director, как и классическая Icinga, оперирует несколькими видами объектов. В рамках этой статьи мы рассмотрим некоторые их них.

Одним из основных принципов взаимосвязей объектов в Icinga является то, что сначала создаются шаблоны того-или иного вида объекта, а потом создаются сами объекты с привязкой к этим шаблонам. Шаблоны описывают одно или несколько схожих для некого множества объектов значений свойств. Для объекта может быть создано любое необходимое количество шаблонов. То есть основное назначение шаблона - это определить параметры, характерные для некоторого массива объектов (например для группы хостов), чтобы в дальнейшем можно было применить эти параметры к этому массиву объектов. Например, можно создать разные шаблоны для объектов типа Host с типовыми параметрами проверки внутри каждого шаблона: в одном шаблоне проверки запускаются чаще, в другом шаблоне реже, для третьего шаблона отключена отсылка уведомлений и т.п. Важно помнить, что при определении разных значений данных для одних и тех же параметров шаблонов, к объекту в конечном итоге будет применяется параметр из последнего по списку шаблона, либо параметр, переопределенный на уровне самого объекта.

В рамках данной статьи мы будем оперировать следующими понятиями и объектами: 

1) Команды (Command). Тут мы выделяем непосредственно команды (Command) и шаблоны команд (Command Templates). Команда - это предопределённое действие, которое выполняется на проверяемой системе или удаленно проверяет систему. Примером Команды может быть вызов утилиты с некоторыми параметрами или запуск какого-то скрипта.  Определение команды состоит из таких атрибутов, как:

• Описание базовых параметров и пути запуска скрипта или утилиты, выполняющих проверку (например скрипты удаленной и локальной проверки, monitoring plugins, которые мы устанавливали ранее);
• Аргументы команды, то есть сопоставление ключей запуска или с переменными среды Icinga, например, $address$ (адрес хоста, к которому применяется проверка), или с вычисляемыми значениями (Лямбда функции);
• Переменные команды, то есть определенные пользователем переменные, задающие значение переменных.

Команды можно разделить на такие основные типы, как:

• Check command – команды проверок;
• Notification command – команды отсылки уведомлений (e-mail, SMS, службы сообщений);
• Event command – команды действий по отношению к хосту или сервису (перезагрузка, запуск дополнительных утилит и т.д.)

Шаблоны команд используются в том случае, когда необходимо задать некие общие параметры проверок или переменные для группы команд. Необходимо учитывать то, что при первом старте Icinga Director смотрит описание команд сервера (кстати базовый набор команд в Icinga появляется после установки плагинов, о которых мы упоминали в самом начале) и добавленные пользователем команды (если такое делалось вручную) и импортирует их в качестве описательных ссылок. Изменить параметры команды в подобной ссылке нельзя, то есть для переопределения параметров, придется создавать собственную команду в Director-e.

 2) Службы (Service). Служба - это сущность описывающая проверку того или иного параметра системы указанной Командой (п.1) с некоторым набором параметров, определяющих среду вызова и исполнения этой Команды. В частности, в свойствах Службы задаётся то, где выполняется Команда – на стороне сервера или на стороне клиента Icinga. Также в свойствах службы может быть задано количество попыток выполнения Команды, интервалы между попытками и другие параметры. Здесь можно выделить такие сущности, как:

• Service Templates. Шаблон используется чтобы задать общие групповые характеристики. Это может быть частота проверок, общие переменные или назначение определенной функциональности (агент Icinga).
• Service Apply-Rules. Применение определенной Службы к Хосту или группе Хостов на основе набора признаков. Это могут быть, как свойства Хоста (имя, адрес, принадлежность к группе), так и набор пользовательских переменных.
• Service Groups. Может применяется для визуализации однотипных сервисов, определения прав пользователей Служб, или упрощения управления ими через API.
• Service Sets. Используется для назначения группы Команд к группе Хостов.

3) Хосты (Host). Хосты - это конечные компьютеры или сетевые устройства, однозначно идентифицируемые при помощи адреса, которые мы добавляем в систему мониторинга. Если говорить о Хостах, то здесь ещё можно выделить следующие вспомогательные сущности:

• Host Templates. Шаблоны Хостов представляют собой те или иные параметры настройки, которые могут быть применимы к одному или множеству Хостов, а также могут содержать в себе привязку Служб (п.2)
• Host Groups. Группы Хостов применяются для группировки Хостов, разграничению доступа или управлению через API.

Помимо вышеперечисленных объектов в конфигурации Icinga Director имеются и другие объекты, но их в рамках данной статьи мы рассматривать не будем.

 

Последовательность первичной настройки конфигурации Icinga Director

После активации модуля Icinga Director для начала работы с конфигурацией Icinga через веб-интерфейс нужно выполнить ряд действий, которые могут показаться новичку не совсем очевидными:

1. Создать запись о глобальной Зоне "director-global" (объект Zone в конфигурационном файле /etc/icinga2/zones.conf или напрямую в icinga2.conf). Эта Зона потребуется для хранения разных общих объектов конфигурации, таких, как Group (например для хранения групп хостов), TimePeriod, Templates и др.., которые Icinga Director будет распространять на клиентов.

2. Описать Службы (Services).

3. Создать разнообразные Шаблоны Хостов (Hosts > Templates), разделив их по логике разделения разных служб, за которыми нужно следить на хостах. При этом Шаблоны Хостов будем создавать руководствуясь принципом "от общего к частному", например так:

• Первым делом можно создать Шаблон, который будет применяться ко всем сущностям, которые доступны по сети (серверы Linux, серверы Windows, сетевые устройства типа коммутаторов, контроллеров управления и т.п.) с настройкой проверки доступности этой сущности в сети.
• Вторым можно создать Шаблон, который будет применяться, например, только к серверам Linux, с проверкой доступности службы SSH, занятого места на дисках, текущей нагрузки на систему, использования swap и т.п.
• Следующим можно создать ещё более узкоспециализированный Шаблон, например, для веб-серверов, который будет выполнять проверки доступности HTTP.

Таким образом Шаблонов Хостов можем создавать столько, сколько нам потребуется. И, как я уже сказал, внутри каждого Шаблона можно выполнять привязку к одной или нескольким Службам, доступность и работоспособность которых должна проверяться.

4. Создать записи о Хостах (Hosts). Для этого можно использовать как ручной режим (запись о каждом Хосте добавляется отдельно вручную, например указывается его IP адрес/FQDN-имя), так и автоматический - с помощью синхронизации из внешних источников (для этого в Icinga Director потребуется создать источник данных, а затем настроить синхронизацию с этим источником). При создании записи о хосте выполняется его привязка к одному или нескольким шаблонам, созданным в п.3.

Рассмотрим далее по порядку все эти действия.

 

Создание глобальной Зоны director-global, API user и Endpoint

Согласно документа IcingaWeb2 Module Director Getting Started, перед началом работы с Icinga Director, как минимум, нужно описать глобальную Зону с предопределённым именем "director-global". Эта глобальная зона используемая управляющим кодом Icinga Director, и должна быть создана на всех системах Icinga, управлять конфигурацией которых мы планируем с помощью Icinga Director. О том как настроить эту зону на клиентах Icinga, да и вообще о том, как настроить клиентов на управление с помощью Icinga Director, мы поговорим чуть дальше в этой заметке. Сейчас же мы настроим наш сервер на использование этой зоны.

В конфигурационном файле icinga2.conf, поставляемым в конфигурации Icinga по умолчанию, есть директива подключения отдельного файла, где описаны зоны - zones.conf:

# cat /etc/icinga2/icinga2.conf | grep zones

 * The zones.conf defines zones for a cluster setup.
include "zones.conf"

В этот файл мы должны добавить запись о глобальной зоне в следующем виде:

...
object Zone "director-global" { global = true }

После этого нужно перезапустить главную службу icinga2:

# systemctl restart icinga2.service

Управление всеми прочими зонами, в которых может возникнуть в дальнейшем необходимость, можно непосредственно через веб-интерфейс Icinga Director. Откроем главное меню управления Icinga Director http://{сервер}/icingaweb2/director. Здесь мы увидим, что в разделе Zones за исключением локальной зоны нашего сервера Icinga нет ни одной зоны.

На данном этапе нам пока достаточно этих настроек.

Следующим шагом, после создания глобальной зоны, документ Getting Started предлагает создание нового пользователя Icinga API с полным доступом к API.

Однако ранее в одной из предыдущих частей, в процессе активации Icinga API при подготовке к развёртыванию Icinga Director такой пользователь уже был сгенерирован (root) и поэтому создавать здесь снова какого-то ещё пользователя я не буду (создавать дополнительных пользователей имеет смысл в том случае, если в перспективе мы планируем делегирование прав доступа к API).

Здесь же обратим внимание на закладку Endpoints, где фигурируют конечные точки подключения к Icinga API. В нашем случае здесь уже присутствует запись о ранее активированной службе Icinga API на нашем сервере мониторинга:

И кстати здесь же мы видим привязку API-пользователя root. Именно эта точка Endpoint будет является для наших клиентов мониторинга, которых мы будем в дальнейшем подключать, источником получения конфигурации правил мониторинга Icinga в режиме Top Down.

 

Создание Шаблонов Служб (Service Templates)

Для примера создадим Шаблон Службы, который будет отвечать за мониторинг состояния службы ssh на Linux системах. Для этого перейдём в веб-интерфейсе Icinga Director в раздел Services и на вкладке Templates нажмём ссылку Add.

В открывшейся справа форме создания Шаблона Службы в нашем случае достаточно будет указать минимум опций, например:

• В поле Name вводим произвольное имя Службы;
• В поле Run on Agent выбираем из выпадающего списка Yes, что значит, что Команда проверки должна выполнятся на стороне клиента.
• В поле Check command выбираем из выпадающего списка поддерживаемых нашим сервером Icinga Команд  - Команду ssh

Чтобы сориентироваться в доступных нашему серверу мониторинга Командах, можно заглянуть в меню навигации на вкладку Commands и, используя поиск, найти ту или иную интересующую нас Команду. Например, давайте найдём используемую в нашем случае Команду ssh 

Найдя и выбрав команду, на закладке Preview мы сможем увидеть, что именно делает данная Команда.

Например, здесь мы видим, что выбранная Команда относится к типу Check command и выполняет вызов утилиты check_ssh из каталога с плагинами PluginDir (в нашем случае /usr/lib/nagios/plugins). При этом утилите передаётся предопределённый набор аргументов. Обратите внимание на описание, говорящее о том, что данная Команда является по сути внешним объектом, импортированным из Icinga 2, и не может напрямую подвергаться правке здесь (в интерфейсе Icinga Director), о чём мы уже упоминали ранее. Если на практике возникает необходимость правки используемых по умолчанию значений переменных, которые принимает утилита/скрипт той или иной Команды, то в Icinga Director существует механизм создания собственных Команд, вызов которых можно настраивать с помощью Полей Данных (Data Fields). Применение механизма Полей Данных мы коснёмся в дальнейшем в одном из практических примеров.

Вернёмся к Шаблонам Служб и по аналогии с описанным примером с ранее созданным Шаблоном, использующим Команду ssh, создадим ряд других Шаблонов Служб, которые нам могут пригодиться для мониторинга наших Linux-серверов. Приведу простейший набор таких Шаблонов:

 

Создание Шаблонов Хостов (Host Templates)

После того, как определены основные ориентиры относительно того, какие именно сервисы мы будем мониторить, нужно определиться с тем, к каким клиентам будут применяться эти сервисы. Для этого можно использовать разные методы. Самый простой способ - это создание Шаблонов Хостов с привязкой к ним одного или нескольких ранее созданных Шаблонов Служб с последующим назначением этих Шаблонов Хостов на конкретные записи Хостов, которые в свою очередь мы будем создавать на следующем этапе нашего описания. Однако, при создании Шаблонов Хостов не стоит мысленно зацикливаться именно на привязке к Службам, ибо как упоминалось ранее, Шаблоны Хостов в первую очередь предназначены для разделения всей общности Хостов по некоему признаку, имеющему схожее значение по тому или иному параметру. По большому счёту в этом и заключается прелесть механизма Шаблонов в Icinga, дающая администратору возможность увеличения вариативного ряда возможных конфигураций настройки.

Например, если подойти к вопросу мониторинга клиентов с точки зрения разделения правил настройки агентного и безагентного мониторинга, то первое что может прийти на ум, это создание отдельного Шаблона Хостов, который будет определять всех клиентов, на которых установлен агент Icinga.

Перейдём в раздел консоли Icinga Director > Hosts, переключимся на закладку Templates и нажмём ссылку Add. В открывшейся справа форме создания нового Шаблона Хоста среди всего множества опций обозначим только обязательные для заполнения и те, которые определяют суть нашего Шаблона, например:

• В поле Hostname введём понятное нам имя шаблона (пусть вас не смущает название поля, –предположительно это мелкая недоработка UI), например Icinga Agent;
• В поле Check command из выпадающего списка выберем Команду, которая, будет проверять доступность клиента на базовом уровне. Например, пусть это будет Команда hostalive4. Практика показывает, что если в Шаблоне Хостов не заполнено данное поле, то этот Шаблон не сможет примениться потом к рабочей конфигурации Icinga Director.
• Включим опцию Icinga2 Agent, после чего появятся ещё две обязательных опции - Establish connection и Accepts config, которые также включим. Этими опциями мы определяем то, что Хосты, к которым будет применён данный Шаблон Хостов имеют предустановленный агент Icinga и беспрекословно принимают от сервера рабочую конфигурацию мониторинга. То есть данные опции определяют режим работы клиента Icinga (Top Down), о котором мы говорили ранее). 

Созданный нами Шаблон Хостов, определяющий принадлежность к системам с клиентом Icinga разумно будет расширить одним из Шаблоном Служб, который мы создали ранее – icinga. То есть, раз уж этот Шаблон Хостов имеет непосредственное отношение к агентам Icinga, то к нему мы "подвесим" мониторинг работы системной службы клиентской части Icinga. Для этого в свойствах Шаблона Хостов (после его создания) переключимся на закладку Services и воспользуемся ссылкой Add service.

В появившейся справа закладке Add Service в поле Imports из выпадающего списка выберем ранее созданный нами Шаблон Службы на базе Команды icinga.

Будем считать, что первый Шаблон Хостов готов.

***

Следующим создадим ещё один Шаблон Хостов, который будет объединять некий набор Шаблонов Служб, свойственных для большинства наших Linux-серверов. Присвоим этому Шаблону имя, например, Linux Server - Base OS Services. В качестве Check command выберем Команду-"пустышку" dummy. Так как этот Шаблон будет определять принадлежность к Linux-системам, то дополнительно можем указать значение поля Icon image, введя в него имя файла иконки, например, tux.png, которая будет отображаться для Хостов, привязанных к этому Шаблону (файлы иконок расположены на сервере Icinga в каталоге /usr/share/icingaweb2/public/img/icons). Для сокращения размера скриншота уберу из него все незаполненные опции Шаблона и покажу только те, что заданы нами:

После создания Шаблона Хостов, выбрав его в списке Шаблонов и перейдя на закладку Services, по аналогии с предыдущим Шаблоном, выполним привязку созданных ранее Шаблонов Служб:

Второй Шаблон Хостов готов.

***

В качестве ещё одного примера, создадим третий Шаблон Хостов. Пусть это будет Шаблон описывающий принадлежность Хоста к множеству веб-серверов. Присвоим Шаблону имя, например, Linux Server - Web Services. В качестве Check command также выберем Команду-"пустышку" dummy, а на закладке Services выполним привязку к ранее созданному Шаблону Команд http.

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

 

Создание записей о Хостах и применение конфигурации

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

# icinga2 node list
# ( icinga2 node remove 'KOM-AD01-APP31.holding.com' ) && ( icinga2 node remove 'KOM-AD01-GW30.holding.com' ) && ( icinga2 node remove 'KOM-AD01-VM34.holding.com' ) 

# icinga2 node update-config
# systemctl reload icinga2

Первая команда выводит список всех подключенных Хостов, вторая удаляет несколько конкретных Хостов, подключённых ранее в режиме Bottom Up, а последующие две команды обновляют конфигурацию Icinga. После этого ранее подключенные вручную клиенты (Хосты) должны исчезнуть из веб-консоли Icinga. Если такое удаление не произвести, то в последующем, на этапе применения конфигурации Icinga Director к Хостам, мы получим сообщение о невозможности развёртывания конфигурации, то есть режим работы Top Down не сможет правильно работать.

***

Для создания записи о Хосте с помощью Icinga Director переходим в веб-консоли в раздел навигации Hosts и на одноимённой закладке нажимаем ссылку Add.

В открывшейся справа форме добавления Хоста заполняем интересующие нас поля:

• В поле Hostname вводим FQDN имя сервера, который мы хотим добавить в Icinga для мониторинга;
• В поле Imports добавляем те Шаблоны Хостов, которые имеют отношение к данному Хосту. В данном случае добавляются все три ранее сделанных Шаблона, так как на сервере установлен агент Icinga, ОС Linux и веб-сервер Apache. Отдельное внимание стоит обратить на порядок применения выбранных Шаблонов. Если в разных выбранных Шаблонах Хостов имеются одни и те же конфликтующие параметры, то к Хосту будет применён тот параметр, который находится в самом последнем в этом списке Шаблоне.;
• В поле Display Name вводим краткое имя Хоста, так как оно будет отображаться на веб-консоли;
• Host address – IPv4 адрес Хоста

Обратите внимание на то, что в отображаемом здесь поле Icon Image уже есть информация о том, что значение этого поля наследуется из назначенного Шаблона Linux Server –Base OS Services.

После создания новой записи о Хосте, как и после прочих операций по созданию и изменению объектов в Icinga Director, мы получим уведомление о том, что необходимо применить сделанные изменения в действующую конфигурацию Icinga, то есть выполнить развёртывание (Deploy) обновлённой конфигурации.

Выполнить применение обновлённой конфигурации в Icinga Director можно из разных мест:

• из формы элемента, который был создан/отредактирован, как, например, в нашем случае в форме редактирования Хоста доступна кнопка Deploy;
• из пункта навигации Activity log, где подсвечивается последнее количество ещё не применённых к рабочей конфигурации изменений в ссылке Deploy N pending changes. Здесь же можно просмотреть историю всех сделанных изменений до текущего момента

• из пункта навигации Deployments, где доступна история применяемых ранее конфигураций и есть ссылка визуализации конфигурации Render config, по нажатию которой, в открывающейся справа форме, будет выведена информация о текущей конфигурации со ссылкой на применение изменений.

Однако при первом же развёртывании конфигурации с добавленным Хостом мы можем получить ошибку, говорящую о конфликте конфигурации Icinga Director (Stage) c конфигурацией базовых настроек Icinga на сервере (/etc/icinga2/*).

Чтобы обойти эту проблему, пришлось на сервере Icinga закомментировать всё содержимое конфигурационного файла /etc/icinga2/conf.d/services.conf с последующим перезапуском службы icinga2 (# service icinga2 restart). В следствие такой редакции, все Службы, за которым ранее вёлся мониторинг на самом сервере Icinga, будут отключены, поэтому нам потребуется дополнительно решить и этот вопрос. Я решил этот вопрос следующим образом:

• На сервере Icinga закомментировал всё содержимое файла /etc/icinga2/conf.d/hosts.conf с последующим перезапуском службы icinga2 (# service icinga2 restart). После этого сервер Icinga совсем исчез из консоли Icinga Web.
• Вышеописанным методом через веб-интерфейс Icinga Director добавил сервер Icinga, как новый Хост, и применил изменения конфигурации.   

В конечном итоге через некоторое время в разделе веб-консоли Overview мы сможем наблюдать добавленные Хосты и состояние их Служб, в соответствии с ранее привязанными Шаблонами.

Вообще, как я понял, решение большинства конфликтных ситуаций между обновлённой конфигурацией Icinga Director (Stage) и локальной конфигурацией Icinga (/etc/icinga2/*) сводится к отключению мешающих Director-у параметров в локальной конфигурации. А чтобы полностью исключить возможность появления таких конфликтов, всех новых клиентов Icinga, подключаемых к Icinga Director лучше конфигурировать согласно рекомендаций на закладке Agent в свойствах Хостов, о чём и пойдёт речь далее. 

 

Подключение новых клиентов Icinga в конфигурации Icinga Director

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

Процедура установки клиента и плагинов мониторинга в данном случае выглядит аналогично ранее описанной.

На сервере с Debian 8.6 последовательность действий по установке клиента будет такой:

# wget -O - http://debmon.org/debmon/repo.key 2>/dev/null | apt-key add -
# echo 'deb http://debmon.org/debmon debmon-jessie main' > /etc/apt/sources.list.d/debmon.list
# echo 'deb http://httpredir.debian.org/debian jessie-backports main' >> /etc/apt/sources.list.d/debmon.list
# apt-get update
# apt-get install icinga2 -y
# apt-get install nagios-plugins -y
# echo include "/usr/share/nano/icinga2.nanorc" >> ~/.nanorc
# systemctl enable icinga2
# systemctl restart icinga2
# systemctl status icinga2

На сервере с CentOS 7.2 это будет выглядеть следующим образом:

# yum install epel-release
# yum install https://packages.icinga.org/epel/7/release/noarch/icinga-rpm-release-7-1.el7.centos.noarch.rpm
# yum install icinga2
# yum install nagios-plugins-all
# echo include "/usr/share/nano/icinga2.nanorc" >> ~/.nanorc
# systemctl enable icinga2
# systemctl restart icinga2
# systemctl status icinga2

Описание дальнейших действий по первичной настройке только что установленного клиента Icinga (в условиях управления конфигурацией этого клиента с помощью Icinga Director) можно будет найти в веб-консоли Icinga Web после добавления информации о новом Хосте в разделе настроек Icinga Director  > Hosts. Поэтому, по аналогии с выше описанным примером, добавим в Icinga Director новый Хост. После добавления новый Хост, как обычно, перейдёт сначала в состояние PENDING, а после проверки его сетевой доступности, в состояние UP. Службы же этого Хоста будут иметь статус UNKNOWN с сообщением об отсутствии настроенного соединения клиента с сервером. 

Выберем добавленный Хост и переключимся на закладку Agent. Здесь для Windows-клиентов будет доступен готовый PowerShell-скрипт, с помощью которого можно настроить клиента Icinga на платформе Windows. И здесь же для Linux-клиентов можно найти Bash-скрипт, с помощью которого можно выполнить настройку клиента Icinga в паре с готовым содержимым для клиентского конфигурационного файла /etc/icinga2/icinga2.conf.

В нашем конкретном примере интересен раздел информации Linux commandline, из которого мы скопируем содержимое скрипта…

…и создадим на клиентском Linux-сервере файл, например в каталоге пользователя, с этим содержимым, после чего выполним его с правами администратора:

# nano ~/icinga-client-configure.sh
# chmod +x ~/icinga-client-configure.sh
# ~/icinga-client-configure.sh

information/base: Writing private key to '/etc/icinga2/pki/KOM-AD01-APP30.holding.com.key'.
information/base: Writing X509 certificate to '/etc/icinga2/pki/KOM-AD01-APP30.holding.com.crt'.
information/pki: Writing certificate to file '/etc/icinga2/pki/trusted-master.crt'.
information/cli: Writing signed certificate to file '/etc/icinga2/pki/KOM-AD01-APP30.holding.com.crt'.
information/cli: Writing CA certificate to file '/etc/icinga2/pki/ca.crt'.

После того, как скрипт установит на клиентскую машину нужные сертификаты, выделим с веб-страницы и скопируем содержимое для файла /etc/icinga2/icinga2.conf в соответствующий файл на клиентской машине, полностью заменив его содержимое:

Отредактировав конфигурационный файл, произведём перезапуск службы icinga2 на клиентской машине:

# cp /etc/icinga2/icinga2.conf /etc/icinga2/icinga2.conf.back
# nano /etc/icinga2/icinga2.conf
# systemctl restart icinga2

Если на нашем клиентском Linux-сервере настроен брандмауэр, откроем в нём порт Icinga API, который сервер мониторинга использует для доставки централизованной конфигурации на клиентскую часть Icinga:

# iptables -A INPUT -i eth0 -p tcp -m tcp --dport 5665  -m comment --comment "Icinga API" -j ACCEPT

После этого снова проверим отображение статуса Служб на Хосте в веб-консоли Icinga. Через некоторое время все Службы должны перейти в активное состояние.

И вроде бы теперь всё хорошо и красиво, однако ситуация с одной из Служб (в нашем примере это http) сразу ставит перед нами новый вопрос – как можно изменить параметры мониторинга той или иной Службы для того или иного Хоста. Об этом мы поговорим в следующей части нашего цикла заметок об Icinga.

***

Благодарю Павла Валентиновича Козлова за всестороннюю помощь в написании теоретической части, редакционную поддержку и терпение по отношению к моим наивным вопросам :)