Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 9. Настройка e-mail оповещений в Icinga Director 1.3

В этой части нашего цикла заметок об Icinga будет рассмотрен пример того, как настроить оповещения по электронной почте с помощью Icinga Director 1.3.0 и подключаемого плагина уведомлений (Notification Plugin).

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

  1. Создаём временные периоды (Timeperiod)
  2. Создаём получателя оповещений (Icinga User)
  3. Устанавливаем скрипт для отсылки оповещений
  4. Создаём Команды (Notification Plugin Command)
  5. Создаём группу Хостов
  6. Создаём Оповещения (Notification)
  7. Проверяем результат

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

 

Создаём временные периоды (Timeperiod)

Объекты типа Timeperiod будут использоваться для определения интервала времени, в течение которого будет работать отсылка оповещений. То есть объекты такого типа в дальнейшем будут привязываться к создаваемым объектам типа Оповещение (Notification) или Шаблон Оповещений.

В веб-консоли Icinga Web 2 в главном меню навигации выбираем корневую ссылку Icinga Director, после чего в открывшейся форме разделов настроек выбираем раздел настройки оповещений - Notifications

В разделе управления оповещениями выбираем пункт Timeperiods

Для того, чтобы создать новый объект Timeperiod, по общей логике Icinga Director, предварительно потребуется создать Шаблон соответствующего типа.  Выберем ссылку Add, чтобы создать новый Шаблон. В открывшейся справа форме из выпадающего списка выберем тип объекта Timeperiod template и укажем понятное нам имя Шаблона, например, Dummy-Timeperiod.

Затем создадим ещё один объект, на этот раз уже c типом Timeperiod object с произвольным именем, например Always, и привязкой к ранее созданному Шаблону (Dummy-Timeperiod).

После создания объекта Timeperiod, в его свойствах переключимся на закладку Ranges. Здесь мы можем настроить временные интервалы действия данного объекта. Например, можно создавать разные объекты Timeperiod, которые будут описывать только рабочие часы или дни недели, или наоборот нерабочее время. Это позволит в дальнейшем гибко настраивать время работы оповещений. В нашем примере настраивается Timeperiod постоянного действия, то есть 7 дней в неделю и 24 часа в сутки. Используя кнопку Add добавляем описание всех семи дней недели и время действия для каждого дня.

Дополнительную информацию о настройке Timeperiod и возможных форматах определения значений можно найти в документах 5.9. Time Periods и 3.4.7. Timeperiod Definition.

 

Создаём получателя оповещений (Icinga User)

Объекты типа User, создаваемые в интерфейсе Icinga Director будут хранить в себе информацию об адресе доставки оповещений, например, email-адрес для почтовых оповещений или номер телефона для отсылки SMS-уведомлений.

В разделе управления оповещениями (Icinga Director > Notifications) выбираем пункт Users / Contacts

Также, как и в случае с Timeperiod, перед тем как создать объект самого пользователя User, нам сначала нужно создать объект Шаблона соответствующего типа. Переключимся на закладку Templates и выберем ссылку Add. В открывшейся справа форме укажем удобное нам имя Шаблона, например dummy-user, и включим опцию Send notifications = Yes

После того, как Шаблон пользователя создан, перейдём на закладку Users и выберем ссылку Add. В открывшейся справа форме добавления пользователя Icinga User укажем имя пользователя, который будет получать оповещения. В поле Imports выберем созданный ранее Шаблон пользователя (dummy-user) и обязательно укажем действующий адрес электронной почты в поле Email

После того, как получатель оповещений создан, в Icinga Director нужно создать специальную Команду оповещения (Notification Plugin Command). Однако прежде, чем это сделать, нам потребуется перебраться в консоль сервера Icinga и добавить специальный скрипт, который будет выполнять формирование письма электронной почты в нужном нам формате с последующей отправкой.

 

Устанавливаем скрипт для отсылки оповещений

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

  • /etc/icinga2/scripts/mail-host-notification.sh
  • /etc/icinga2/scripts/mail-service-notification.sh

Первый скрипт ориентирован на отправку оповещений в случае изменения состояния Хостов, а второй – в случае изменения состояния отдельно взятых Служб на Хостах. Однако нам данные скрипты не подойдут, так как они не рассчитаны на приём дополнительных настраиваемых внешних параметров, которые нам могут потребоваться в случае настройки оповещений в Icinga Director под свои "хотелки". Вместо этого можно воспользоваться одним из публично доступных решений. Например в статье Icinga 2 + Director + Notifications = <3 фрау Спиллер предлагает нам пару своих скриптов взамен выше-обозначенных. Её скрипты в симбиозе с Icinga Director умеют посылать письма в формате простого текста и, как я подозреваю (хотя сам не проверял), вполне пригодны для использования. Однако мне не очень понравилась идея разделения скриптов оповещений на два разных файла, использующих ряд одинаковых параметров. Поэтому я сделал свой вариант, объединяющий логику работы оповещений для Хостов и Служб в одном скрипте. Помимо этого вместо текстового формата формирования писем я использую HTML-формат, что позволяет улучшить визуальное восприятие этих писем, а излишняя информация об отсутствующих данных, например, при отсутствии комментария к оповещению, попросту не попадает в письмо.

Итак, в консоли сервера Icinga переходим в каталог /etc/icinga2/scripts/, скачиваем готовый скрипт с GitHub и делаем его исполняемым:

# cd /etc/icinga2/scripts
# wget https://raw.githubusercontent.com/Aleksey-Maksimov/Icinga2/master/scripts/notification-to-email.sh
# chmod +x notification-to-email.sh

Скрипт в своей работе для отправки почты использует стандартный инструмент mail, который, как я понимаю, в разных дистрибутивах Linux может ссылаться на разные исполняемые файлы. Поэтому прежде, чем прикручивать скрипт в Icinga Director, желательно протестировать его работу из консоли, используя поддерживаемые скриптом аргументы. Получить полный список допустимых аргументов и их описание можно командой:

# /etc/icinga2/scripts/notification-to-email.sh --help

Чтобы базово убедиться в том, что скрипт успешно сможет отправлять почту, можно запустить его с набором аргументов, имеющих некие вымышленные значения. Самое главное здесь правильно указать режим работы скрипта (--plugin-mode) и реальный адрес получателя (--mail-to):

# /etc/icinga2/scripts/notification-to-email.sh --plugin-mode 'host-mode' --notification-type 'TEST' --host-displayname 'MYHOST' --host-alias 'MYHOST.mycorp.com' --host-state 'VERYGOOD' --host-output 'I am fine'  --mail-to 'Vasiliy.Tyerkin@holding.com'

Скрипт имеет 2 основных режима работы – для отправки оповещений об изменении состояния Хостов (--plugin-mode 'host-mode') и для отправки оповещений об изменении состояния Служб (--plugin-mode 'service-mode')

В результате работы скрипта в почту должно прийти письмо примерно такого вида (ссылка внизу письма работать не будет, так как при вызове скрипта не задан соответствующий аргумент)

Если письмо не приходит, можно воспользоваться рекомендациями из раздела "Решение проблем" (см.далее).

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

 

Создаём Команды типа Notification Plugin Command

На этом этапе нам нужно создать объекты типа Icinga Command, которые будут отвечать за непосредственный вызов скрипта, который мы добавили на сервер Icinga ранее. Так как наш скрипт имеет два режима работы, нам нужно будет создать две Команды. Первую с набором аргументов, соответствующих Host-оповещениям, а вторую с набором аргументов, соответствующих Service-оповещениям.

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

В открывшейся справа форме добавления Icinga Command из выпадающего списка выберем тип Команды Notification Plugin Command, зададим уникальное имя Команды и укажем путь к исполняемому скрипту, который мы разместили на сервере Icinga ранее. В данном примере создаётся Команда для оповещений о состоянии изменения Хостов.  

После того, как объект Команды будет записан, в его свойствах появятся дополнительные закладки, среди которых нам нужно выбрать Arguments. Здесь мы зададим тот перечень аргументов, которые будут переданы скрипту Команды. При этом задавать нужно не все аргументы, которые способен принимать скрипт, а только те, что имеют отношение к либо к Host-оповещениям, либо к Service-оповещениям. В поле Argument name указываем названия аргументов, так как показано в примере, а в поле Value указываем одну из переменных, которыми оперирует Icinga (подразумевается что в этих переменных хранятся данные, которые автоматически заполняются модулем работы с оповещениями)

Напомню, что перечень аргументов скрипта можно получить, вызывав его в консоли с аргументом --help. Там же есть информация и об используемых в данном примере переменных Icinga. 

Ключевым аргументом здесь является --plugin-mode, который в данном примере принимает значение ориентированное на Host-оповещения – 'host-mode'

После того, как аргументы настроены, переключимся на закладку Preview и посмотрим то, в каком конечном виде Команда попадёт в рабочую конфигурацию Icinga: 

Аналогичным образом создаём вторую Команду, которая будет использоваться для оповещений об изменении статуса Служб.

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

В конечном итоге мы будем иметь две Команды, каждая из которых имеет собственный набор аргументов:

Далее созданные Команды мы можем привязать к Шаблонам Оповещений, которые будут созданы в дальнейшем, однако прежде чем приступить к созданию Шаблонов Оповещений создадим Группу Хостов, на которую будут нацелены эти Шаблоны.

 

Создаём группу Хостов

Объекты Групп Хостов (Hostgroup) используются в Icinga Director для динамического объединения Хостов в некоторые общности по совокупности одного или более условий, гибко комбинируемых друг с другом. Рассмотрим самый простой пример – создание Группы Хостов, которая будет привязана ко всем Хостам, имя которых подпадает по маску KOM-AD01-*.

Перейдём в Icinga Director > Hosts и на закладке Groups нажмём ссылку добавления новой Группы - Add. Укажем понятное имя Группы и в блоке Assign where добавим условия отталкиваясь от выбранной из списка переменной Host.name.

Теперь можно приступать к созданию объектов Оповещений.

 

Создаём Оповещения (Notification)

Также, как и в случае с другими типами объектов в Icinga Director, перед тем как создать объект Оповещения (Notification), нам сначала нужно создать объект Шаблона соответствующего типа. В разделе управления оповещениями (Icinga Director > Notifications) выбираем пункт Notification templates

С помощью ссылки Add создадим пару Шаблонов Оповещений. Первый Шаблон будет предназначен для создания Оповещений об изменении статуса Хостов, второй – для создания Оповещений об изменении статуса Служб Icinga. Имена Шаблонов задаём такие, чтобы они отражали сущность хранящихся в Шаблоне настроек, например Email-Notifications-for-Hosts-24x7 и Email-Notifications-for-Services-24x7. Для каждого Шаблона указываем соответствующую Команду типа Notification Plugin Command, которую мы создали ранее (notification-to-email-host-mode и notification-to-email-service-mode соответственно). И здесь же, при желании, можем выполнить привязку к ранее созданному объекту типа Timeperiod (Always).

Итоговая конфигурация Icinga для каждого созданного нами Шаблона Оповещений будет предельно проста, так как фактически является связующим звеном с другими объектами – Командой и Периодом:

После того, как создан хотя бы один Шаблон Оповещений, в навигации Icinga Director > Notifications появится возможность создавать сами Оповещения – Notifications

 

Новые Оповещения создаются также с помощью ссылки Add. В форме свойств создаваемого Оповещения укажем:

  • Понятное нам наименование, например, в представленном примере создаётся Оповещение об изменении состояния объектов типа Хост с именами KOM-AD01-* (условие из ранее созданной Группы Хостов) и поэтому логично присвоить Оповещению имя типа KOM-AD01-Icinga-Host-Notifications.
  • В поле Imports выберем ранее созданный Шаблон Оповещений (Email-Notifications-for-Hosts-24x7), из которого, кстати говоря, в нашем примере унаследуется настройка поля Time period.
  • В поле Users выберем созданный ранее (один или более) объект типа Icinga User (напомню, что адрес e-mail, на который будут отсылаться оповещения будет браться именно из этого объекта).
  • В поле Apply to выберем из выпадающего списка Hosts или Services в зависимости от того, какого рода Оповещение создаётся –для Хостов или Служб. Мы помним про то, что для этих типов объектов у нас используются разные Команды оповещений, которые в свою очередь привязаны к Шаблонам Оповещений. То есть, в данном примере, должна соблюдаться логическая связь между тем, что мы выберем в поле Imports и тем, что выберем в поле Apply to. И именно из-за того, что в данном конечном объекте Оповещения существует такое разграничение, мы изначально и создавали раздельные Команды для Хостов и Служб.
  • В перечне условий применения Assign where нам нужно будет указать хотя бы одно условие, по которому будут отбираться объекты, на изменение состояния которых будет срабатывать данное Оповещение. Список возможных для отбора атрибутов большой, а условия можно комбинировать в между собой в логические связи AND/OR/NOT, что даёт нам широкие возможности для отбора. В моём примере выбран один из самых простых способов – единственное условие с нацеливанием на Группу Хостов, в которую входят Хосты с именами KOM-AD01-* (для этого мы ранее и создавали группу KOM-AD01-Hosts).

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

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

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

 

Проверяем результат

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

Однако есть и менее изощрённый способ проверки – это форсированная отсылка оповещения о текущем состоянии Хоста непосредственно из веб-интерфейса Icinga Web 2. Для этого в веб-консоли перейдём в раздел Overview > Hosts. Выберем в списке Хостов любой хост, подпадающий под условия отбора ранее созданной нами Группы Хостов и на основной закладке информации о хосте Host увидим:

  • Все Группы Хостов, к которым динамически привязан данный Хост
  • Всех пользователей, которым будут доставляться оповещения об изменении статуса Хоста
  • Ссылку Send notification, с помощью которой всем соответствующим пользователям можно отправить оповещение с информацией о текущем статусе Хоста   

Перейдём по ссылке Send notification и введём произвольный комментарий. Включим признак Forced, чтобы отправить оповещение немедленно в независимости от настроек таймингов в Оповещениях. Нажмём кнопку Send custom notification чтобы инициировать отправку.

В почту должно прийти письмо, из которого мы получим информацию о Хосте и его текущем статусе. Здесь же мы увидим время получения статусного состояния, комментарий администратора и ссылку на объект Хоста в веб-консоли Icinga Web 2.

Аналогичным образом можно проверить отправку оповещений из веб-страницы обзора состояния любой Службы. В случае штатного срабатывания механизма оповещений мы должны получать похожие письма, где в Description будет отображена информация о последнем изменении статуса объекта мониторинга, полученная из плагинов проверки Check Plugin. При этом шапка вложенной таблицы будет менять подсветку в зависимости от состояния объекта, например Service State. Вот пример писем об изменении статуса службы на WARNING и CRITICAL:

При восстановлении работоспособности объекта мониторинга, согласно настроенной в нашем примере конфигурации, будет приходить соответствующее письмо 

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

 

Решение проблем

Если всё настроено, но письма до получателя не ходят, то разбор полётов следует начать с проверки - настроен ли вообще наш сервер Icinga на отправку почты. Примеры настройки отправки почты с сервера на корпоративный SmartHost я описывал ранее в Вики-статьях:

Там же можно найти и простейшие способы проверки отсылки почты с сервера.

***

Если почта отсылается с сервера исправно, но оповещения с Icinga не приходят, то можно воспользоваться режимом отладки Icinga и посмотреть, что у неё внутри происходит в момент попытки отправки оповещения. Для этого воспользуемся документом Icinga 2 Troubleshooting и включим режим расширенного логирования:

# icinga2 feature enable debuglog
# systemctl restart icinga2
# tail -f /var/log/icinga2/debug.log | grep "notice/Process"

Так как лог debug.log может заполняться очень интенсивно, сразу после проверочных отправок оповещений обязательно отключаем режим отладки с перезапуском службы:

# icinga2 feature disable debuglog
# systemctl restart icinga2

На этом пока всё. До новых встреч.

Добавить комментарий