В данной заключительной части нашего цикла заметок о развёртывании и базовой настройке Icinga будет рассмотрен пример того, как настроить SMS оповещения с помощью Icinga Director 1.3.1 и подключаемого плагина уведомлений (Notification Plugin).
Исходя из того условия, что в прошлый раз мы уже произвели некоторые настройки оповещений в Icinga Director, последовательность действий будет следующей:
- Подключаем к серверу GSM-модем
- Устанавливаем и настраиваем пакет smstools
- Устанавливаем скрипт для отсылки оповещений
- Создаём Команду типа Notification Plugin Command в Icinga Director
- Создаём Группу Служб (ServiceGroup) в Icinga Director
- Настраиваем периоды (Timeperiod) и получателей оповещений (User) в Icinga Director
- Создаём Оповещения (Notification) в Icinga Director
- Проверяем результат
Рассмотрим все этапы по порядку.
Подключаем к серверу GSM-модем
Перед установкой и настройкой пакета smstools к COM-порту нашего сервера нужно подключить GSM-модем с активной SIM-картой, который будет использоваться для отсылки SMS-сообщений. Для повышения надёжности системы оповещений можно подключить к нашему серверу несколько модемов, так как пакет smstools способен работать более чем с одним модемом, организуя из подключённых модемов пул с общей очередью обработки отправляемых SMS-сообщений.
В моём случае сервер Icinga запущен в виртуальной машине oVirt на базе Debian 8 (Jessie) Linux и аппаратный модем транслируется на сервер с помощью устройства Moxa Nport. Информацию о том, как настроить такую трансляцию можно найти в статье Вики: Трансляция COM-порта с устройства Moxa Nport 5610 в виртуальную машину с Linux Debian 8 (Jessie).
Устанавливаем и настраиваем пакет smstools
Установим пакет, который будет заниматься отсылкой SMS-сообщений на подключенный модем:
# apt-get install smstools -y
Настроим главный конфигурационный файл службы smstools /etc/smsd.conf. Файл содержит множество параметров. Приведу лишь те, которые необходимо изменить в данный момент в рамках нашей задачи:
devices = GSM1
...
[GSM1]
device = /dev/ttyr01
incoming = no
baudrate = 115200
Для вступления изменений в силу перезапустим службу:
# service smstools restart
Попробуем отправить тестовое SMS-сообщение командой типа:
# echo -e "To: +79128887766\n\nTest SMS!" > /var/spool/sms/outgoing/`date +%Y%m%d-%Hh-%Mm-%Ss-%Nns`
На указанный номер должно прийти SMS-сообщение.
В случае возникновения проблем с отсылкой тестового SMS-сообщения, отладка smstools заключается во включении высокого уровня логирования loglevel и отслеживанием событий, регистрируемых в логе, указанном в logfile конфигурационного файла /etc/smsd.conf
...
logfile = /var/log/smstools/smsd.log
...
loglevel = 7
...
Вполне вероятно, что возникнет потребность в том, чтобы оповещения приходили на языке, отличном от английского, например, на русском языке. В таком случае в начале текстового файла, формируемого для smsd под заголовком с номером телефона нужно добавить дополнительный заголовок вида…
Alphabet: UCS
…а содержимое самого SMS-сообщения потребуется сконвертировать в кодировку UCS-2. В каталоге /usr/share/doc/smstools/examples/scripts/ есть примеры скриптов, которые можно взять за основу для создания собственного скрипта конвертации. Я позаимствовал скрипт из заметки Организация SMS шлюза (smstools3), где рассматривается конвертация из формата UTF-8 в формат UCS-2 и немного подправил с учётом замечаний, обнаруженных в ветке обсуждения Mis-coding/Disorderly code (кстати, в конце этой ветки есть ещё один вариант готового скрипта конвертации).
Таким образом, в каталоге /usr/local/sbin/ создаём скрипт конвертации smsd-text-to-UCS.sh, на тот случай, если в smsd будет отправлено сообщение содержащее no-ACSII символы:
# touch /usr/local/sbin/smsd-text-to-UCS.sh
# chmod 755 /usr/local/sbin/smsd-text-to-UCS.sh
Наполним скрипт следующим содержимым:
#!/bin/sh
PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
if [ $# -lt 1 ]; then
echo "Give me a file!"
exit 10
fi
if [ ! -f "$1" ]; then
echo "$1: No such file or it's not a regular file!"
exit 20
fi
if ! which iconv > /dev/null 2>&1; then
echo "There is no iconv(1) here! Please, install it."
exit 40
fi
HEADER=`sed -e '/^$/ q' $1`
BODY=`sed -e '1,/^$/ d' $1`
ALPHABET=""
# Is body in english?
if ! echo -n "$BODY" | iconv -t ISO-8859-15 > /dev/null 2>&1; then
ALPHABET="Alphabet: UCS"
fi
FILE=`mktemp /tmp/smsd_XXXXXX`
echo "$HEADER" >> $FILE
# If body isn't in english tell it to smsd
[ -n "$ALPHABET" ] && echo "$ALPHABET" >> $FILE
echo "" >> $FILE
# Convert body if it's needed.
if [ -n "$ALPHABET" ]; then
echo -n "$BODY" | iconv -t UNICODEBIG >> $FILE
else
echo -n "$BODY" >> $FILE
fi
mv $FILE $1
Ссылку на этот скрипт укажем в параметре checkhandler конфигурационного файла smsd.conf. В таком случае все файлы, попадающие в каталог /var/spool/sms/outgoing/ перед непосредственной отправкой будут обрабатываться данным скриптом. В конечном итоге конфигурационный файл /etc/smsd.conf примет следующий вид (без учёта закомментированных параметров):
devices = GSM1
outgoing = /var/spool/sms/outgoing
checked = /var/spool/sms/checked
incoming = /var/spool/sms/incoming
logfile = /var/log/smstools/smsd.log
infofile = /var/run/smstools/smsd.working
pidfile = /var/run/smstools/smsd.pid
outgoing = /var/spool/sms/outgoing
checked = /var/spool/sms/checked
failed = /var/spool/sms/failed
incoming = /var/spool/sms/incoming
sent = /var/spool/sms/sent
stats = /var/log/smstools/smsd_stats
checkhandler = /usr/local/sbin/smsd-text-to-UCS.sh
receive_before_send = no
autosplit = 3
[GSM1]
device = /dev/ttyr01
smsc = 79037011111
incoming = no
baudrate = 115200
Обратите внимание на то, что в своей итоговой конфигурации, я добавил параметр smsc, который определяет номер SMS-центра Провайдера услуг связи. В моём случае используется Билайн, и до тех пор, пока я явно не указал номер SMS-центра (номер узнал в на сайте провайдера), с отсылкой SMS-сообщений были проблемы (в логе при этом регистрировалась ошибка: The modem answer was not OK: +CMS ERROR: 38 (Network out of order))
После внесения нужных изменений в smsd.conf перезапустим службу smstools:
# service smstools restart
Теперь пробуем отправить SMS-сообщение с русскими символами:
# echo -e "To: +79128887766\n\nПривет!" > /var/spool/sms/outgoing/`date +%Y%m%d-%Hh-%Mm-%Ss-%Nns`
После успешной отправки сообщения будут сохранены в каталоге /var/spool/sms/sent/. Так будет выглядеть сообщение отправленное с использованием только английских символов в сообщении:
# cat /var/spool/sms/sent/20170723-20h-42m-37s-503011100ns
To: +79128887766
Modem: GSM1
Sent: 17-07-23 20:42:48
IMSI: 210998230641574
Test SMS!
А так будет выглядеть сообщение отправленное с использованием кириллицы:
# cat /var/spool/sms/sent/20170723-20h-45m-29s-597768454ns
To: +79128887766
Alphabet: UCS
Modem: GSM1
Sent: 17-07-23 20:45:46
IMSI: 210998230641574
@825B!
На данном этапе подготовку службы smstools будем считать законченной и теперь на нашем сервере имеется полезный универсальный инструмент для отсылки SMS-сообщений из любых приложений и скриптов. Теперь можно переходить к настройке на стороне Icinga.
Устанавливаем скрипт для отсылки оповещений
Чтобы Icinga могла создавать в каталоге очереди smsd новые файлы добавим пользователя, от имени которого работает служба icinga2 в группу, имеющую доступ к каталогам службы smstools (smsd) в /var/spool/sms
# usermod -aG smsd nagios
# id nagios
uid=109(nagios) gid=114(nagios) groups=114(nagios),117(icingaweb2),122(smsd)
Создадим скрипт формата Icinga Notification Plugin, с помощью которого Icinga будет формировать и передавать оповещения в очередь службы smstools. Для этого переходим в каталог /etc/icinga2/scripts/, скачиваем готовый скрипт с GitHub и делаем его исполняемым:
# cd /etc/icinga2/scripts
# wget https://raw.githubusercontent.com/Aleksey-Maksimov/Icinga_notification-to-sms/master/notification-to-sms.sh
# chmod +x notification-to-sms.sh
Прежде, чем интегрировать скрипт в Icinga Director, желательно протестировать его работу из консоли, используя поддерживаемые скриптом аргументы. Получить полный список допустимых аргументов и их описание можно командой:
# /etc/icinga2/scripts/notification-to-sms.sh --help
Чтобы базово убедиться в том, что скрипт успешно сможет отправлять SMS-сообщения, можно запустить его с набором аргументов, имеющих некие вымышленные значения. Самое главное здесь правильно указать режим работы скрипта (--plugin-mode) и реальный номер мобильного телефона получателя (--sms-to). Скрипт имеет 2 основных режима работы – для отправки оповещений об изменении состояния Хостов Icinga (--plugin-mode 'host-mode') и для отправки оповещений об изменении состояния Служб Icinga (--plugin-mode 'service-mode').
Выполним проверочный вызов скрипта с набором аргументов, которые будут передаваться со стороны Icinga в случае с оповещением о недоступности какого-то Хоста Icinga:
# /etc/icinga2/scripts/notification-to-sms.sh --plugin-mode 'host-mode' --notification-type 'PROBLEM' --host-displayname 'KOM-AD01-UP006' --host-address '10.1.1.6' --host-output 'CRITICAL - Host Unreachable (1.1.1.6)' --sms-to '79128887766'
Проверим ещё один вызов, который будет использоваться со стороны Icinga в случае с оповещением о проблеме со Службой Icinga:
# /etc/icinga2/scripts/notification-to-sms.sh --plugin-mode 'service-mode' --notification-type 'PROBLEM' --host-displayname 'KOM-AD01-UP006' --host-address '1.1.1.6' --service-desc 'APC UPS Input Voltage' --service-output 'SNMP CRITICAL - upsAdvInputLineVoltage *205* VAC' --sms-to '79128887766'
Если при проверочных запусках скрипта мы получили соответствующие SMS-оповещения, можно переходить в веб-интерфейс Icinga Director и на базе скрипта создавать Команду Icinga.
Создаём Команду типа Notification Plugin Command в Icinga Director
На этом этапе нам нужно создать объект типа 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.
В конечном итоге мы будем иметь две Команды, каждая из которых имеет собственный набор аргументов:
Далее созданные Команды мы можем привязать к Шаблонам Оповещений, которые будут созданы в дальнейшем. Однако, прежде чем приступить к созданию Шаблонов Оповещений, нам нужно создать какую-то общность объектов мониторинга, например Группу Хостов или Группу Служб, на которую будут нацелены эти Шаблоны. На практике в качестве основного канала оповещений чаще всего используются оповещения по электронной почте, и в этом случае зачастую удобней использовать привязку Оповещений к Группам Хостов, как было описано ранее. Если же говорить об SMS-оповещениях, то они чаще всего используются на выборочной основе для каких-либо важных и критичных показателей работы ИТ-инфраструктуры, например при возникновении проблем с электропитанием или нарушением температурного режима в ЦОД. И в этом случае уже удобней будет использовать привязку Оповещений к Группам Служб Icinga. Рассмотрим пример, в котором создаётся Группа Служб с динамическим назначением членства всем Службам Icinga, связанным с показателем входного напряжения на источниках бесперебойного питания (ИБП).
Создаём Группу Служб в Icinga Director
Объекты Групп Служб (ServiceGroup) используются в Icinga Director для динамического объединения Служб в некоторые общности по совокупности одного или более условий, гибко комбинируемых друг с другом. В нашем простом примере будет создана Группы Служб "Critical-Services-with-SMS-Notifications", которая будет привязана ко всем Службам, имя которых подпадает по маску input voltage.
Перейдём в Icinga Director > Services и на закладке Groups нажмём ссылку добавления новой Группы - Add. Укажем понятное имя Группы и в блоке Assign where добавим условия, отталкиваясь от выбранной из списка переменной Service.name.
Далее настроим временные периоды и получателей оповещений.
Настраиваем периоды (Timeperiod) и получателей оповещений (User)
Предназначение и пример настройки объектов типа Timeperiod и User мы последовательно рассматривали в прошлой заметке. В рамках этой заметки мы будем использовать рассмотренный ранее период Timeperiod с именем Always, который определяет период времени 24х7:
Что же касается объектов типа User, то единственной отличительной особенностью, которой нужно уделить внимание в контексте данной заметки, является то, что в свойствах получателей оповещений (объекты типа User) должен быть указан номер мобильного телефона в поле Pager. Этот номер будет использоваться для отсылки SMS-сообщений.
Теперь можем перейти к созданию Оповещений.
Создаём Оповещения (Notification) в Icinga Director
Также, как и в случае с другими типами объектов в Icinga Director, перед тем как создать объект Оповещения (Notification), нам сначала нужно создать объект Шаблона соответствующего типа. В разделе управления оповещениями (Icinga Director > Notifications) выбираем пункт Notification templates
С помощью ссылки Add создадим пару Шаблонов Оповещений. Первый Шаблон будет предназначен для создания Оповещений об изменении статуса Хостов, второй – для создания Оповещений об изменении статуса Служб Icinga. Имена Шаблонов задаём такие, чтобы они отражали сущность хранящихся в Шаблоне настроек, например SMS-Notifications-for-Hosts-24x7 и SMS-Notifications-for-Services-24x7. Для каждого Шаблона указываем соответствующую Команду типа Notification Plugin Command, которую мы создали ранее (notification-to-sms-host-mode и notification-to-sms-service-mode соответственно). И здесь же, при желании, можем выполнить привязку к ранее созданному объекту типа Timeperiod (Always). Возможно дополнительно полезной будет установка свойства Notification interval равным 0, чтобы Icinga не пыталась посылать нам повторные оповещения.
Итоговая конфигурация Icinga для каждого созданного нами Шаблона Оповещений будет предельно проста, так как фактически является связующим звеном с другими объектами – Командой и Периодом:
После того, как создан хотя бы один Шаблон Оповещений, в навигации Icinga Director > Notifications появится возможность создавать сами Оповещения – Notifications
Новые Оповещения создаются также с помощью ссылки Add. В форме свойств создаваемого Оповещения укажем:
- Понятное нам наименование, например Critical-Icinga-Services-SMS-Notifications.
- В поле Imports выберем ранее созданный Шаблон Оповещений (SMS-Notifications-for-Services-24x7), из которого, кстати говоря, в нашем примере унаследуется настройка полей Notification interval и Time period.
- В поле Users выберем созданный ранее (один или более) объект типа Icinga User (напомню, что номер телефона, на который будут отсылаться оповещения будет браться именно из этого объекта из поля Pager).
- В поле Apply to выберем из выпадающего списка Services, так как данное Оповещение создаётся для объектов типа Icinga Service. При этом должна соблюдаться логическая связь между тем, что мы выберем в поле Imports и тем, что выберем в поле Apply to.
- В перечне условий применения Assign where нам нужно будет указать хотя бы одно условие, по которому будут отбираться объекты, на изменение состояния которых будет срабатывать данное Оповещение. Список возможных для отбора атрибутов большой, а условия можно комбинировать в между собой в логические связи AND/OR/NOT, что даёт нам широкие возможности для отбора. В моём примере выбран один из самых простых способов – единственное условие с нацеливанием на Группу Служб, в которую входят Службы с именами по маске *input voltage* (для этого мы ранее и создавали группу Critical-Services-with-SMS-notifications).
После того, как Оповещение с заданными параметрами создано, переключимся на закладку Preview и посмотрим то, в каком конечном виде Оповещение попадёт в рабочую конфигурацию Icinga:
На этом можем считать, что вся нужная в рассматриваемом примере цепочка действий для работы механизма SMS-оповещений построена. Теперь нужно применить новую конфигурацию Icinga, если это не делалось по ходу выполнения всех ранее описанный действий:
Конфигурация должна примениться без ошибок, после чего можно приступить к проверке конечного результата.
Проверяем результат
Процедуру отсылки оповещений можно инициировать разными способами. Согласно рассматриваемого нами примера и проведённым настройкам в Icinga Director, мы можем проверить отсылку Оповещений при изменении статуса Служб Icinga, отвечающих за мониторинг состояния входного напряжения на ИБП. Сделать это можно путём форсированной отсылки оповещения о текущем состоянии соответствующей Службы непосредственно из веб-интерфейса Icinga Web 2. Для этого в веб-консоли перейдём в раздел Overview > Services. Выберем в списке любую Службу, подпадающую под условия отбора ранее созданной нами Группы Служб Critical-Services-with-SMS-notifications и на основной закладке информации о Службе Service увидим:
- Все Группы Служб, к которым динамически привязана данная Служба
- Всех пользователей, которым будут доставляться оповещения об изменении статуса Службы
- Ссылку Send notification, с помощью которой всем соответствующим пользователям можно отправить оповещение с информацией о текущем статусе Службы
Перейдём по ссылке Send notification и введём произвольный комментарий. Включим признак Forced, чтобы отправить оповещение немедленно в независимости от настроек таймингов в Оповещениях. Нажмём кнопку Send custom notification чтобы инициировать отправку.
На номер мобильного телефона, указанный в свойствах получателя оповещений (в нашем случае Vasiliy Tyerkin), придёт SMS-сообщение, из которого мы получим информацию о текущем статусе Службы "APC UPS Input Voltage" для нашего ИБП. Здесь же мы увидим время получения статусного состояния и комментарий, который ранее указал администратор при отправке уведомления в поле Comment.
Если отправленное из веб-интерфейса Icinga Web 2 оповещение не пришло на телефон, то для отладки работы Icinga можно включить расширенное логирование, как было описано в конце прошлой заметки в разделе Решение проблем.
В случае штатного автоматического срабатывания механизма оповещений мы должны получать похожие SMS-сообщения, где в Info будет отображена информация о последнем изменении статуса объекта мониторинга, полученная из плагинов проверки Check Plugin. Для того чтобы проверить работу автоматической отсылки уведомлений в случае возникновения проблемы, попробуем сымитировать эту проблему. В нашем случае достаточно будет на несколько минут отключить питающий ввод на подопытном ИБП, дождаться SMS-сообщения о наличии проблемы. Затем включим питающий ввод обратно, после чего должно прийти второе SMS-сообщение, свидетельствующее о том, что проблема с входящим напряжением устранена.
Как видим, в рамках рассматриваемого примера с ИБП, желаемый результат достигнут. В дальнейшем, при возникновении необходимости включения SMS-оповещений для каких-то других Служб или Хостов Icinga требуется минимум действий в веб-интерфейсе Icinga Director.
На этом я хочу закончить свой цикл заметок о развёртывании и базовой настройке системы мониторинга Icinga 2 на базе сервера Debian Jessie. Однако, я надеюсь на то, что по мере возможности в нашем Блоге и в соответствующем разделе Вики в дальнейшем будут появляться новые материалы на эту интересную тему.
Дополнительные источники информации:
- Thomas Krenn Wiki - SMS Benachrichtigungen mit Icinga
- Markus Benning Blog - SMS notifications in icinga2 with sms77.de
- Claudio Kuenzler Blog - Icinga 2: Send SMS alerts only for CRITICAL status and its recoveries
- Linux Journal - Using an SMS Server to Provide a Robust Alerting Service for Nagios
- Grspavankumar Blog - Nagios + SMS notifications with Gammu and Siemens MC35i
- Unix Tips & Tricks Blog - Отправка уведомлений через sms в Nagios 3
- Олег Парамонов - Принимаем и отправляем СМС при помощи GSM-модема
- Станислав Герман-Евтушенко - Nagios + SMS используя мобильный телефон
- timp87 Blog - Организация SMS шлюза (smstools3)
RSS - Записи
Случайно удалил файл /etc/icinga2/conf.d/commands.conf
Подскажите, пожалуйста, его возможно восстановить?