Вход на сайт
Яндекс.Метрика

Рейтинг@Mail.ru

Обобщенная система оповещения пробников Nagios в зависимости от приоритетности ответственных

Идея проекта заключается в оповещении ответственных в порядке их приоритетности по серверам.

Сервис должен собирать информацию о проблемных машинах, т.е. в случае падения нескольких сервисов или серверов втечение некоторого времени (назовем это время временем реакции на пробники, которое задается через веб интерфейсhttps://contacts.kds.corp.hostcomm.ru/cgi-bin/servers_new.pl (по умолчанию равно 100 секунд)), система должна распознать ответственного группы серверов и сформировать один вызов на мобильный телефон. Если абонент отвечает и нажимает цифру 1, тогда вызов считается принятым и ему приходит емейл со списком проблемных серверов. В случае неответа или отказа приниять вызов, система должна впоследствии пересобрать всю информацию о проблемах и вызвать следующего по списку ответственного и т.д. Совершая вызов необходимо сообщить абоненту краткую информацию о случившемся и дождаться реакции абонента.

Для решения такой задачи выбран подход с использованием внешней базы данных nagios_notify, в которой будет храниться информация по ответственным, информация о группах проектов, о всех серверах, о срабатывании пробников (т.е. алертов), о совершении вызовов.

Всё это добро работает на машине contacts.kds.corp.hostcomm.ru. Скрипты написаны на языке perl, веб интерфейсы на perl+javascript. Кого заинтересовало пишите в личку :)

1. Схема БД nagios_notify

 Схема базы данных для работы с Nagios

 1.1 Таблица servers

Таблицы servers, projects, members заполняются вызовом скрипта insert_bd.pl по расписанию.

Данные для таблицы servers берутся из парсинга json странички https://nagios.corp.ru/nagios/cgi-bin/status_new.cgi?style=hostdetail&jsonoutput

Где status_new.cgi - переписанный из исходников и скомпилированный в бинарник программа под нашу версию Icinga 1.9.3 бинарник. Он научен выводить дополнительное поле «notes» в веб интерфейс нагиоса из его файлов конфигурации, в котором будет имя проекта, к которому принадлежит сервер.

status_new.cgi отдает:

{ "cgi_json_version": "1.9.0",

 "icinga_status": {

 "status_data_age": 56,

"status_update_interval": 15,

"reading_status_data_ok": true,

"program_version": "1.9.3",

"icinga_pid": 48889,

 ...

 },

 "status": {

 "host_status": [

 { "host_name": "cf19.hc.ru", "host_display_name": ".sweb.ru", "status": "UP", "last_check": "25-09-2015 06:50:47", "duration": "4d 7h 58m 53s", "attempts": "1/3", "state_type": "HARD", "is_flapping": false, "in_scheduled_downtime": false, "active_checks_enabled": false, "passive_checks_enabled": true, "notifications_enabled": true, "has_been_acknowledged": false, "action_url": "https://grapher2.nagios.corp.hostcomm.ru/pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_' class='tips' rel='/grapher2/pnp4nagios/index.php/popup?host=$HOSTNAME$&srv=_HOST_", "notes_url": null, "notes": "devops_hc_cpanel", "status_information": "PING OK - Packet loss = 0%, RTA = 1.26 ms"},

 { "host_name": "cf9.hc.ru", "host_display_name": "77.222.32.1", "status": "UP", "last_check": "25-09-2015 06:50:36", "duration": "45d 4h 21m 38s", "attempts": "1/3", "state_type": "HARD", "is_flapping": false, "in_scheduled_downtime": false, "active_checks_enabled": false, "passive_checks_enabled": true, "notifications_enabled": true, "has_been_acknowledged": false, "action_url": null, "notes_url": null, "notes": "devops_hc_cpanel", "status_information": "PING OK - Packet loss = 0%, RTA = 2.62 ms"},

 

Тут забираем в БД значения полей "host_name" и "notes".

Поле servername таблицы servers уникально, что не дает вставить дубликаты. Изменения в списке, т.е. удаление хоста также реализовано (удаление всех хостов что не в списке).

Для управления временем реакции на пробники по оповещению ответственных есть поле time_konsolid, которые можно изменять через веб интерфейс https://contacts.kds.corp.hostcomm.ru/cgi-bin/servers_new.pl

 

1.2. Таблица projects

Проекты хранятся в базе LDAP по пути «ou=nagios_responsible,ou=groups,ou=corp,ou=sites,o=hc»

Поле project_name заполняется значением атрибута cn (в данном примере project_name = devops_hc_vps) и оно уникально.

Таблица projects синхронизируется с базой LDAP.

 

1.3. Таблица members

Таблица заполняется согласно полю uniqueMember проекта в «ou=nagios_responsible,ou=groups,ou=corp,ou=sites,o=hc». Поля email, sip заполняются из ветки LDAP «ou=users,o=hc» по фильтру uid.

Учитываются изменения в LDAP значений email, sip, принадлежность к группе.

Поля name и group_id вместе уникальны.

Присутствует поле weight, которое показывает приоритетность ответственного к проекту.

Поле weight заполняется вручную через веб-интерфейс https://contacts.kds.corp.hostcomm.ru/cgi-bin/weight.pl

 

1.4. Таблица nagios_ntf (таблица аларминга нагиоса)

Таблица заполняется вызовом скрипта nagios_ntf.pl по событию (т.е. когда срабатывает аларм) в системе nagios.

На вход программы передается тип пробника (т.е. сервис это или хост), статус сервиса/хоста, хостнейм, идентификатор события, название упавшего сервиса (если хост упал то поле пустое):

./nagios_ntf.pl "SERVICE" "PROBLEM" "std.node24.nagios.corp.hostcomm.ru" "APACHE"

Конфигурация Nagios в описании контактов должна иметь следующий вид:

Описание контактов:

define contact{

use contact-by-sip-perl #темплейт

contact_name nagios_notify_sip

}

 

define contact{ 

name contact-by-sip-perl ; The name of this contact template

service_notification_period 24x7 ; service notifications can be sent anytime 

host_notification_period 24x7 ; host notifications can be sent anytime 

service_notification_options c,r

host_notification_options d,r

service_notification_commands notify-service-by-sip-perl ; send service notifications via sip

host_notification_commands notify-host-by-sip-perl ; send host notifications via sip

register 0 ; ITS NOT A REAL CONTACT, JUST A TEMPLATE!

}

 

define host{

use hostcomm_graph-host-template

host_name nic.ru

contact_groups kds

contacts nagios_notify_sip

notes nagios_sys_infra

}

Передаваемые статусы :

c = notify on CRITICAL service states

r = notify on service recoveries (OK states)

d = notify on DOWN host states

r = notify on host recoveries (UP states)

Таблица заполняется статусами PROBLEM и RECOVERY только для тех хостов, которые входят в группу KDS, и для которых в конфигурации указано поле notes, равное имени проекта.

Пример заполненной таблицы:

id date_0 date_1 type status count contact_group_id
 444362  2015-10-29 10:45:41  2015-10-29 10:56:25  SERVICE  PROBLEM  2  2574
 444362  2015-10-29 10:46:27  NULL  SERVICE  RECOVERY  1  2574
 444364 2015-10-29 10:48:39 NULL   SERVICE  PROBLEM  1 2574 
 444364 2015-10-29 10:49:27 NULL  SERVICE   PROBLEM  1 2574 
description primary_key asterisk_state tel_number date_answer date_recovery que_mail
 APACHE  1262  1  81234567891  2015-10-29 10:50:45  NULL  2
 HTTP 1263   -1  81234567891  2015-10-29 10:50:45  2015-10-29 10:55:09  2
HTTP  1264   1  81234567891 2015-10-29 10:54:54   NULL  2
APACHE  1265   1  81234567891  2015-10-29 10:54:54 NULL   2

 

В веб-интерфейсе она выглядит так

servername date_0 date_1 date_recovery status description
fe104.hc.ru  2015-10-28 16:22:17    2015-10-28 16:24:15  RECOVERY  HTTP
std.node24.nagios.corp.hostcomm.ru  2015-10-28 14:25:22    2015-10-28 14:31:25  RECOVERY  PUPPET
kiae.node23.nagios.corp.hostcomm.ru  2015-10-28 14:25:34    2015-10-28 14:31:16  RECOVERY  PUPPET
cf24.hc.ru      2015-10-28 14:27:43 RECOVERY   HTTP
fe53.hc.ru  2015-10-28 15:29:27    2015-10-28 15:31:27  RECOVERY  HTTP
contact_group_id project_name count tel_number person date_answer
 2574  devops_hc_fe  1  81234567891   skuleshov  2015-10-28 16:24:44
4985   devops_infra_nagios  1  81234567891   skuleshov  2015-10-28 14:28:35
4985   devops_infra_nagios  1  81234567891   skuleshov  2015-10-28 14:28:35
2571   devops_hc_cpanel  0  81234567891   skuleshov  
2574   devops_hc_fe  1  81234567891   skuleshov  0000-00-00 00:00:00

 

Где servername – имя сервера; id – это id сервера;date_0 – время первого срабатывания пробника; date_1 – время последнего повторного срабатывания пробника; type – что поломалось: либо сервис либо хост; date_recovery – время, когда сервис/хост стал работоспособным; status – статус (Problem, Recovery); description – описание пробника, для хоста поле пустое; asterisk_state – статус астериска (имеет технологическое значение); contact_group_id – группа контактов проекта; project_name – имя проекта; count – количество срабатываний пробника (показывает сколько раз подряд прилетал статус PROBLEM не становясь ни разу RECOVERY); tel_number – телефонный номер ответственного, ответившенго на звонок подтверждением вызова (тот, кто нажал “1”); person – логин ответственного; date_answer – дата ответа ответственного на звонок; que_mail – значение: 0 – по умолчанию; 1 – звонок был совершен; 2 – по этому пробнику было отправлено письмо ответственному.

 

2. Совершение вызова ответственному.

Вызовы формирует скрипт alarm.pl, который запускается по крону каждые 2 минуты.

Формируется список контактных групп и список серверов из таблицы nagios_ntf по условию консолидации пробников ( из скрипта: UNIX_TIMESTAMP(date_0)+t_s.time_konsolid<$now_date ).

На основе этого списка для каждой группы совершается вызов ответственному согласно весовой конфигурации, заданной через веб интерфейс https://contacts.kds.corp.hostcomm.ru/cgi-bin/weight.pl

Веса могут иметь значения от 0 и выше. Начинается обзвон с низкого приоритета. Также может быть, что у нескольких ответственных будет один вес, в таком случае абонент выбирается рандомно.

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

Вызов совершается посредством отправки callback файла в систему Asterisk, в котором передается переменная group_id и номер абонента.

Примерный callback файл выглядит так:

# cat /tmp/nagios/2574.call
Channel: SIP/81234567891@reconn
CallerID: 4955555555
MaxRetries: 3
RetryTime: 10
WaitTime: 40
Context: nagios_auto
Extension: s
Priority: 1
Set: group_id=2574
Set: dst=81234567891
Set: src=37927
AlwaysDelete: Yes

Asterisk получив файл callback совершает вызов (dial) на номер абонента. Затем ждет, что наберет вызываемый абонент после ответа на звонок:

0 – "не могу" – ответственный не готов поработать;
1- "могу" – ответственный готов взяться за работу;
и если ничего не набрал или не дозвонились - "-1";

Данные о текущем состоянии вызова содержатся в перезаписываемой таблице dialer

id group_id file status count date_0 date_1 sip_number servers
16 4985   0 1 2015-10-28 14:28:01 2015-10-28 14:28:35 81234567891 kiae.node23.nagios.corp.hostcomm.ru,
std.node24.nagios.corp.hostcomm.ru
17 2574   -1 2 2015-10-29 11:12:02 2015-10-29 11:15:03 81234567891 fe105.hc.ru

Тому абоненту, который нажмет “1” придет e-mail уведомление со списком проблемных серверов.Где group_id – номер группы проекта; status – статус вызова(0,-1,1); date_0 – время совершения вызова; date_1 – время ответа; sip_number -номер абонента; servers – список серверов, по которым звонили(не используется это поле).

За это отвечает скрипт send_email.pl (вызывается по крону каждые 30сек): для каждой группы ответственных формируется список серверов, по которым надо звонить исходя из таблицы nagios_ntf полей que_mail=1 и status=PROBLEM. Если в это время все сервисы по которым звонили поднялись, то в сообщении так и будет указано, что всё ок.

Вот и всё, теперь у нас есть автоматическая звонилка по пробникам.

Если кого-то этот проект заинтересовал и хотелось бы поработать с ним, то прошу обращаться в личку, подумаем чем вам помочь :)

 

Обновлено 05.04.2016 15:21

unix-way