Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 4. Инициализация Master-сервера и подключение Linux-клиентов Icinga (классический вариант)

В этой части мы немного поговорим о возможных вариантах мониторинга удалённых хостов в системе мониторинга Icinga 2 и рассмотрим процедуру подключения хостов на базе CentOS и Debian Linux к ранее развёрнутому серверу мониторинга c помощью установки агента Icinga.

О видах мониторинга Icinga

Сервер Icinga может выполнять как безагентный (agent less) мониторинг удалённых хостов, так и мониторинг хостов, на которые установлены разные виды агентов. В роли агентов может выступать как экземпляр Icinga, настроенный на удаленном сервере, так и дополнительное ПО, умеющее отправлять результат проверок на сервер мониторинга, но об этом чуть далее.

При безагентном мониторинге сервер Icinga может получать информацию об удалённом хосте как с помощью активных проверок (Active Check), запускаемых на самом сервере Icinga, так и с помощью пассивных проверок (Passive Check), инициируемых самим удалённым хостом с отправкой уведомлений на сервер Icinga.

Примерами безагентного активного мониторинга могут быть:

• периодический опрос сервером Icinga удалённого хоста на предмет доступности того или иного TCP-порта или ответа, получаемого от удалённого хоста при обращении на какой-либо порт (например разбор HTTP заголовков, получаемых в ответе от веб-сервера на удалённом хосте);
• опрос сервером Icinga состояния служб, работающих на удалённом хосте по протоколу SNMP (для Linux/Windows-систем, для сетевого оборудования) или таким протоколам, как WMI (для Windows-систем).
• получение информации сервером Icinga о состоянии аппаратной части оборудования через управляющие интерфейсы IPMI (HP iLO, IBM RSA, Dell DRAC и т.д.).

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

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

• возможность автоматизации управления конфигурацией хоста со стороны сервера;
• возможность исполнения проверок или команд на агенте по команде сервера, например, возможность использования обработчиков событий (Event handlers), с помощью которых можно автоматизировать восстановление работоспособности проблемного сервиса;
• шифрование канала передачи данных между сервером и агентом и т.д. при помощи SSL
  

Мониторинг Icinga с помощью агентов можно разделить на несколько разных реализаций:

• "родной" пакет Icinga2 в режиме клиента для Linux-систем
• NRPE Client - агент для Linux-систем (на стороне сервера требуется плагин check_nrpe) (например из пакета nagios-nrpe-server)
• NSClient++ - агент для Windows-систем, завернутый MSI-пакет (предпочтительней использовать check_nt или nscp_local, также может работать через плагин check_nrpe)
• NSCA-NG (но это уже устаревший вариант, хотя и активно применяемый в ряде конфигураций)
  

Есть мнение о том, что с точки зрения здравого смысла и вопросов безопасности,  лучше вообще отказаться от реализаций NRPE ниже 3 версии и NSCA.

В рамках цикла наших заметок об Icinga будут рассматриваться примеры использования как безагентного мониторинга сетевых устройств, так и мониторинга с использованием агента, в качестве которого будет выступать стандартный пакет Icinga2 в режиме клиента для Linux-систем.

Клиент-серверная архитектура

С точки зрения клиент-серверной архитектуры в Icinga 2 различается три основные сущности – Master, Satellite, Client.

• Master - это серверный экземпляр Icinga 2 на верхнем уровне иерархии. Master-узел в простых развёртываниях один, в высоко-доступных развёртываниях Master-узлов может быть несколько (кластер). 
• Satellite – вспомогательный узел, который способен выступать в качестве распространителя конфигурации Icinga для рядовых клиентов и позволяет рядовым клиентам не замечать недоступности основного Master-узла. Satellite-узлы могут быть полезны в больших развёртываниях, где требуется децентрализация основной конфигурации, например, когда требования к мониторингу одних и тех же служб различаются на разных площадках.
• Client – обычный клиентский узел, который получает конфигурацию мониторинга с родительского узла (Master или Satellite).

Приведу простую схему из документа, в котором описаны возможные архитектурные варианты Distributed Monitoring with Master, Satellites, and Clients:

Развёртывание любой из трёх перечисленных сущностей Icinga 2 сводится, как минимум, к установке пакета icinga2 и выполнению мастера конфигурирования узла с помощью команды: 

# icinga2 node wizard

В моём примере будет рассматриваться простая конфигурация с единственным Master-узлом и некоторым количеством клиентских узлов, то есть без участия Satellite-узлов. Таким образом, сначала мы рассмотрим конфигурирование Master-узла, а затем пример настройки пары клиентских Linux-систем.

 

Режимы работы клиента Icinga

Клиентская часть Icinga может работать в двух режимах: Top Down и Bottom Up.

В режиме Top Down сервер (Master) инициирует исполнение команд проверки на клиенте и/или может передавать конфигурацию клиенту. Как пример подобной конфигурации мы будем рассматривать развертывание хостов и сервисов в Icinga Director.

В режиме Bottom Up клиент самостоятельно (по собственному расписанию) выполняет проверки (рассылает уведомления) и отправляет результаты на Master-сервер. Этот вариант мы будем рассматривать далее в статье.

Обратите внимание на то, что режим Bottom Up на сегодня уже может считаться нерекомендуемым к использованию (Deprecated), так будет поддерживаться до конца следующего года, а начиная с версии Icinga 2.8 - 2.9 этот режим работы клиента работать перестанет. Подробнее об этом можно прочитать здесь: Feature #13255 - Deprecation of cluster/client mode "bottom up" w/ repository.d and node update-config

 

Инициализация Master-узла

На сервере, где мы ранее уже развернули Icinga 2 и Icinga Web 2, запускаем мастер конфигурирования узла:

# icinga2 node wizard

Последует ряд вопросов, на которые нам нужно будет ответить…

На первый вопрос мастера вводим n, чтобы перевести мастер конфигурирования в режим настройки Master-узла.

Затем нам будет предложено ввести имя Common Name (CN). Это имя будет использоваться для генерации SSL-сертификата, который будет использоваться для защиты соединений между сервером и его клиентами. По умолчанию в качестве CN предлагается FQDN-имя нашего сервера. Соглашаемся с этим именем, нажав Enter.

Так как в прошлой статье мы уже запускали процедуру активации Icinga API (выполняли команду  icinga2 api setup), то уже тогда на нашем сервере был создан локальный Центр сертификации (certificate authority) и сгенерирован этим ЦС SSL-сертификат (в каталоге /etc/icinga2/pki/) на имя нашего сервера. Поэтому в данном случае мастер конфигурирования узла обнаружит этот сертификат и подхватит его.

Также мастер обнаружит, что поддержка API в Icinga уже включена, а API user уже создан, и лишь предложит добавить информацию о Bind Host и Bind Port, где мы ничего не вводим, а просто нажимаем Enter для продолжения работы мастера.

В завершающей стадии мастер выполнит обновление некоторых конфигурационных файлов Icinga.

Здесь у нас появляются такие понятия, как "зона" (Zone) и "конечная точка" (Endpoint). Если упростить, то, "зона" является границей доверия и распространения конфигураций в "конечные точки", а "конечная точка" – это точка подключения клиентов к TCP-прослушивателю Icinga API (то есть конечная точка однозначно ассоциируется с каким-либо серверным узлом Icinga и характеризуется его FQDN именем). В одну зону может входить любое множество конечных точек.
Различается три основных типа зон: локальная, родительская, глобальная. С точки зрения исполнения команд, конечная точка способна принимать команды из своей локальной или родительской зоны. А с точки зрения приема конфигураций, конечная точка способна принимать конфигурации из родительской или глобальной зоны.
О дополнительных аспектах взаимодействия зон, понимания глобальной зоны и исполнения команд проверок мы поговорим в следующий статьях, посвящённых Icinga Director.

Вернёмся к нашему Master-узлу. В нашем случае и Zone и Endpoint будут иметь одно и тоже имя – FQDN-имя нашего сервера мониторинга.

Заглянем в файл /etc/icinga2/constants.conf и убедимся в наличии записи о зоне, относящейся к нашему, только что созданному, Master-серверу:

# cat /etc/icinga2/constants.conf | egrep -i "ZoneName|TicketSalt"

const ZoneName = "KOM-AD01-MON20.holding.com"
const TicketSalt = "cbb2630005eca9f240b39de83a9acd7ecd"

В файле /etc/icinga2/zones.conf впишем в качестве Zone и Endpoint - FQDN имя Master-сервера:

Для вступления изменений конфигурации в силу, перезапустим службу icinga2:

# systemctl restart icinga2

Таким нехитрым образом мы инициировали работу Master-сервера, теперь переходим к установке клиентов.

 

Установка Icinga на Client-узел

В качестве примера развёртывания Linux-клиента я буду использовать системы на базе Debian 8.6 и CentOS 7.2.

В то время, когда мастер конфигурирования узла Icinga будет запущен на клиентской Linux-системе, он отправит запрос на получение клиентского сертификата на Master-узел (а мы помним о том, что на нашем Master-узле работает Центр сертификации). И для того, чтобы Master-узел автоматически мог ответить такому клиенту на запрос, то есть сразу выдать сертификат, нам предварительно потребуется создать специальный "тикет" для этого клиента на Master-узле с помощью команды:

# icinga2 pki ticket --cn 'KOM-AD01-APP31.holding.com'

f5cf58ef82a5a99bc0a9f9b40fddab6d1da63641

Теперь переходим на клиентскую Linux-систему и выполняем установку пакетов icinga2 и nagios-plugins c последующей активацией службы icinga2.

На сервере с 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
# 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
# systemctl enable icinga2
# systemctl restart icinga2
# systemctl status icinga2

Дальнейшие действия будут одинаковы и как для Debian-клиентов, так и для CentOS-клиентов.

После установки пакетов запускаем мастер настройки узла Icinga:

# icinga2 node wizard

Обратите внимание на то, что запуск мастера настройки узла – это классический вариант подключения клиента Icinga к Master-серверу. При использовании модуля расширения Icinga Director у нас появляется ещё один вариант подключения клиента к серверу, о чём мы поговорим в дальнейшем при рассмотрении примеров использования Icinga Director.   

Также, как и при инициализации Master-сервера, здесь нам потребуется ответить на несколько вопросов, но вопросов будет уже больше:

• На первый вопрос введём Y, чтобы перевести мастер в режим настройки клиента.
• Затем нам будет предложено ввести имя Common Name (CN). Это имя будет использоваться для генерации SSL-сертификата клиента на стороне ЦС, который работает на Master-сервере. По умолчанию в качестве CN предлагается FQDN-имя нашего сервера. Соглашаемся с этим именем, нажав Enter.
• Следующим пунктом нам нужно ввести СN-имя конечной точки Endpoint на стороне Master-сервера. В нашем случае это FQDN-имя сервера мониторинга.
• На вопрос, хотим ли мы установить соединение с Master-узлом с этого клиента, отвечаем утвердительно – вводим Y
• Затем снова введём имя сервера Master endpoint host, а порт Master endpoint port оставим предложенный по умолчанию, так как именно этот (TCP 5665) порт у нас используется для Icinga API на стороне нашего Master-сервера.
• На вопрос, хотим ли мы настроить дополнительные подключения к другим Master-серверам (клиент Icinga может работать с несколькими серверами одновременно), ответим отрицательно, так как в нашем случае используется всего одни сервер – вводим N.
• Далее нас спросят о том, через какое Master-соединение можно отправить запрос на генерацию сертификата. По умолчанию здесь будут предложены уже введенные ранее данные об имени и порте Master-сервера, поэтому просто два раза нажмём Enter. 

C Master-узла будет запрошен сертификат сервера и показаны нам для проверки его данные, в частности отпечаток Fingerprint. Это не более, чем дополнительная проверка для повышения уровня безопасности процесса подключения клиента к серверу. Проверив информацию о сертификате, вводим согласие о том, что информация корректна -Y

После этого с сервера Icinga у нас будет запрошен "тикет", который мы сгенерировали ранее на Master-сервере для клиента с именем KOM-AD01-APP31.holding.com. Используя этот "тикет" мастер конфигурирования запросит у Центра сертификации Icinga на сервере мониторинга SSL-сертификат для клиента и, получив его от ЦС, сохранит в каталоге /etc/icinga2/pki/.

На вопросы о Bind Host и Bind Port просто жмём Enter.

Затем будет задан вопрос о принятии конфигурации и разрешении принятия команд с Master-сервера Accept config / commands from master. Отвечаем утвердительно - Y. После этот Icinga-клиент обновит локальную копию информации о зонах и настройках полученных с Master-сервера и завершит свою работу.

Теперь нам нужно обновить локальный файл зон Icinga, добавив туда информацию о клиенте:

# echo include "/usr/share/nano/icinga2.nanorc" >> ~/.nanorc
# nano /etc/icinga2/zones.conf

После работы мастера конфигурации узла Icinga в этом файле уже будет присутствовать информация о Master-узле и нам останется только заменить значения NodeName и ZoneName последних двух секций добавив туда FQDN-имя нашего клиента

После этого перезапустим на нашем клиенте службу icinga2:

# systemctl restart icinga2

 

Инициализация Client-узла на Master-узле

После настройки наш клиент Icinga 2 будет периодически отправлять на Master-сервер копию своей локальной конфигурации. Чтобы проверить то, что информация о конфигурации клиентских служб успешно передаётся на сервер, выполним на стороне сервера команду: 

# icinga2 node list

Эта команда выведет информацию о всех узлах, которые выполняют периодические подключения к серверу с отправкой на него своей конфигурации:

Чтобы обновить конфигурацию сервера, загрузив в него информацию о конфигурации подключающихся клиентов, выполним команды:

# icinga2 node update-config
# service icinga2 reload

Обратите внимание на то, что выполнять обновление конфигурации сервера с помощью команды  icinga2 node update-config  нужно только в том случае, если мы планируем вручную управлять конфигурационными файлами Icinga. Если же мы планируем использовать функционал Icinga Director для управления конфигурацией Icinga, то нам лучше воздержаться от выполнения этой команды. Хотя на самом деле нет ничего страшного, если мы на данном этапе выполним эту команду и обновим конфигурацию сервера, так как в следующей части, при рассмотрении процесса настройки Icinga Director я приведу пример того, как очистить конфигурацию сервера от записей об узлах, добавленных ранее в ручной конфигурации.

Итак, после обновления конфигурации сервера, перейдём в веб-консоль Icinga (Overview > Hosts) и сможем увидеть информацию о новом клиенте, который некоторое непродолжительно время будет находится в статусе PENDING…

А затем этот хост перейдёт в статус UP, после чего станет доступна информация о текущем состоянии его служб:

Как видим, в конфигурации по умолчанию некоторые из служб на нашем клиенте имеют критический статус. В следующей отдельной заметке мы попробуем разобраться с тем, как можно изменить эту ситуацию. А в этой части мы выполнили поставленную задачу – провели инициализацию Master-сервера и подключили к нему несколько Linux-клиентов в режиме Bottom Up.

PS: Хочу выразить отдельную благодарность за помощь в написании теоретической части и редакционную поддержку Павлу Козлову.

Дополнительные источники информации:

• Icinga Documentation - Distributed Monitoring with Master, Satellites, and Clients
• ITzGeek - How to Add Remote Linux Host into Icinga 2 Server
• LinOxide - How to Add Host and Manage Services in Icinga2