ИТ-мониторинг ДОМ.РФ: от идеи к рабочему инструменту

Привет, Habr! Меня зовут Сергей, я инженер в ДОМ.РФ, и одна из моих задач — развитие ИТ-мониторинга. В этой статье я расскажу, как мы самостоятельно и с минимальными затратами пришли от идеи к рабочему инструменту, с помощью которого в одном месте в простой и понятной форме можно определить текущее здоровье наших систем.   

В идеале итоговый результат должен выглядеть как-то так:

При этом информация должна собираться из разных источников.  

Вводные: 

• единый интерфейс, отображающий все ИТ-системы в виде иконок со статусами, 

• визуально понятные статусы,  

• звуковое оповещение в случае изменения статуса работоспособности в разрезе каждой ИТ-системы, 

• возможность просмотра расширенной информации, а именно — причин, повлиявших на статус работоспособности.  

Чем подобный инструмент должен помочь: 

• уменьшить время реакции дежурной смены при массовых сбоях,  

• поможет коррелировать события между зависимыми ИТ-системами, 

• прозрачно укажет очаги возгорания в ИТ для людей как углубленных, так и не углубленных в ИТ.  

Звучит удобно? Удобно! 

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

А это минимум Zabbix, являющейся у нас основной системой мониторинга, в котором уже заведены все ИТ-системы. Он же занимается агрегацией событий из смежных систем мониторинга. Он же отвечает за визуализацию событий дежурной смене.  
Не забываем про существование Grafana, которая визуализирует дашборды команд. Тут появляется еще одно требование к инструменту: возможность добавлять к сущностям ИТ-сервисов линки на дашборды Grafana. 

К большим enterprise душа сразу не лежала, и вот почему: 

• муки выбора: быстро найти подходящий инструмент непросто, а это означает, что нас ждут длительные пилоты,

• закупки — пилот → бюрократия → промышленная эксплуатация, путь далеко не быстрый,

• доработки: в случае возникновения каких‑либо дополнительных потребностей мы зависимы от поставляемого продукта. Мало того, что надо договориться с вендором о возможности кастомизации, так еще и 90% вероятность, что это приведет к пункту закупок,

• интеграции — очень каверзный пункт. У нас есть два варианта развития событий: как правило, многие системы зонтичного мониторинга являются самостоятельным продуктом или агрегатором событий/данных из нижнеуровненвых систем мониторинга.

Это означает, что все уже имеющиеся сущности ИТ-сервисов из Zabbix придётся дублировать в новую систему. Одно дело — скопипастить названия, если предусмотрена тонкая интеграция, другое дело — выстроить зависимости (как событие из системы мониторинга «А» должно отобразиться в верхнеуровневой системе «Б»), перенести правила оповещений, корреляцию событий и взаимосвязи систем.  

Далее необходимо запустить процесс обработки событий. Из чего появляются требования к обработке событий. В привычном Zabbix есть возможности проставлении статусов обработки событий, временного подавления события и снижения критичности.  

Необходимо обучить персонал дежурной смены и администраторов/владельцев ИТ-систем пользоваться новым продуктом, в частности обработки событий и самостоятельной корректировки параметров мониторящихся ИТ-систем. 

Необходим продукт с тонкой интеграцией с Zabbix. Который будет только подхватывать активные события и визуализировать их, то есть вся логика останется на стороне Zabbix. 

Был один вариант (название умолчим), который мог собирать и обрабатывать события из Zabbix по API, но делал он это минут 15 на одну итерацию. Согласитесь, «такой себе» оперативный мониторинг. Вишенкой стало отсутствие возможности корреляции событий между смежными ИТ-системами.  

Подходим к разработке 

А раз уж это в любом случае в каком-то виде разработка, можно подумать и об обслуживании инструмента. Если это самостоятельное приложение, оно обязательно должно быть построено на HA-архитектуре, что несет за собой дополнительные трудозатраты на разработку + дальнейшее обслуживание.  

А если нет? У нас же есть Grafana! Grafana умеет в HA, легко обслуживается, она используется как основной инструмент визуализации метрик для команд. Используя именно её как инструмент отображения статусов ИТ-систем, мы избавляемся от лишних переходов между инструментами и лишнего балласта, который бы нам пришлось в последующем обслуживать. 

 
А может, получится обойтись малой кровью без разработки? 

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

• Grafana имеет интеграцию с Zabbix. — Хорошо 

• Grafana из системы Zabbix может визуализировать метрики, количество проблем по какой-либо хост группе, статус «Услуга». — Вроде хорошо, но нет. Все это не подходит. Сущности «Услуга» — это заготовка от Zabbix для визуализаций зонтичного типа, здесь боль в том, что услуги заполняются вручную. Вручную, Карл! Не наш путь. Остальное совсем мимо. 

• У Grafana есть различные плагины для визуализаций, наиболее подходящая из коробки это «Stat». — Вроде хорошо, но нет. «Stat» — отображает красивую панельку, можно убрать тайтл, отображать имена значений, а не само значение, но нет визуального и звукового оповещения + не вставить два значения в одну плашку. Не подходит. 

Значит, от разработки не уйти 

Ок. Настало время структурировать требования, дополнить их, и собрать в единое ТЗ. Которое вкратце выглядит так: 

• единый дашборд отображающий все ИТ-системы в виде плашек, 

• возможность перемещения, изменения размеров плашек для визуального обозначения значимости ИТ-системы, 

• визуальное отображение статусов работоспособности в разрезе каждой ИТ-системы /плашки в виде цветового индикатора, 

• визуальное (blink — мигать) и звуковое оповещение в случае изменения статуса работоспособности в разрезе каждой ИТ-системы/плашки, 

• возможность добавления своих ссылок/линков к сущностям ИТ-системы /плашки, 

• отображать статусы работоспособности ИТ-систем, основываясь на событиях в системе Zabbix, 

• оперативно отображать изменения статусов с задержкой не более 1 минуты от времени возникновения событий, 

• при отображении статусов учитывать обработку событий в системе Zabbix (периоды технического обслуживания, подавление событий, снижение уровней критичности, а так же статус обработки), 

• отображение на сущностях ИТ-системы /плашки количества не обработанных событий если таковые имеются, 

• второй уровень дашборда , возможностью просмотра расширенной информации (текущий статус, события, повлиявшие на статус работоспособности ИТ-системы /плашки, список текущих активных проблем, отображение сущностей мониторинга, входящих в ИТ-систему в виде плашек с отображением статусов работоспособности сущности). 

Рассмотрим техническую составляющую 

Определимся, каким образом будем получать из Zabbix статусы ИТ-систем и количество необработанных событий.  

Какие есть варианты: 

• собирать статусы активных событий из Zabbix по API, структурировать и агрегировать их, далее перекладывать их в какую-то систему хранения, из которой Grafana будет брать статусы, 

• собирать лог событий, складывать в Elastic, структурировать и агрегировать их, далее перекладывать их в какую-то систему хранения, из которой Grafana будет брать статусы, 

• собирать лог событий, складывать в Elastic, собирать статус Grafana из Elastic,  

• направлять события в виде оповещения стандартными средствами Zabbix в обработчик, которым складывать в какую-то систему хранения, из которой Grafana будет брать статусы.  

Минусы везде схожи. А именно: возможна длительная обработка событий, дополнительное ПО — инструмент нуждающийся в периодическом обслуживании.  

В итоге мы решили брать статусы событий напрямую из БД Zabbix, структурировать и агрегировать их на уровне SELECT.  

Минусы данного подхода: дополнительная нагрузка на БД. Но нагрузка незначительная + она все равно была при использовании любого другого метода, меньше, но была бы.  

Для визуализации в Grafana нужен новый плагин, который будет учитывать все требования, описанные выше. Какие есть варианты: 

• писать плагин с нуля. — Боль, подрядчиков нанимать не хочется из соображений описанных про enterprise, у своих разработчиков и без нас дедлайны горят. 

• поискать исходники плагина «Stat» или любого другого подходящего по смыслу стороннего плагина и дописать необходимый функционал. — и такой плагин есть! Status Panel, нам подходит. 

Status Panel — плагин, способный отображать визуально статус какой-либо сущности, основываясь на нескольких показателях сущности + отображать эти показатели на этой же плашке (в отличие от того же коробочного «Stat»). А самое главное — у него открытый исходный код!  

Фактически мы получаем весь нужный функционал, а недостающий можем дописать. Да, есть минусы — в отсутствии поддержки (автор его забросил два года назад) и количестве поддерживаемых источников данных.  

Приступаем к применению напильника 

Далее мы разберем, как прорабатывался верхнеуровневый дашборд с отображением статусов работоспособности ИТ-систем. Второй слой с расширенной информацией рассматривать не будем. Так как в Zabbix уровней severity шесть, а в Status Panel из коробки всего два, оперировать будем матчингом Zabbix High →  Status Panel Warning, Zabbix Disaster → Status Panel Critical. Для нас достаточно отображения последних двух уровней severity из Zabbix. В случае необходимости добавить в Status Panel дополнительные severity можно путем правки statis_ctrl.js — то есть добавить в код недостающие severity по аналогии с уже имеющимися.  

Начнем с запросов. Сейчас стоит задача собрать по одной ИТ-системе статус и количество необработанных событий. Для выборки данных по ИТ-системе можно отталкиваться от хост-групп или тегов, тут кому как удобнее. Мы пошли по пути тегов, так как теги можно раскидать где угодно, тем самым покрыть зависимости систем от друг друга. Для начала отобразим в стандартном плагине Stat, дабы убедиться, что все работает: 

Пример одного из запросов:

SELECT CASE   WHEN (COALESCE(max(severity), '-1') = 4) THEN 'High'   WHEN (COALESCE(max(severity), '-1') = 5) THEN 'Disaster'   END as "Severity" FROM (   SELECT DISTINCT e.severity, e.acknowledged, e.name, t.triggerid   from triggers t   LEFT JOIN functions f ON ( f.triggerid = t.triggerid )   LEFT JOIN items i ON ( i.itemid = f.itemid )   LEFT JOIN events e ON ( e.objectid = t.triggerid )   LEFT JOIN problem_tag pt ON ( pt.eventid = e.eventid )   LEFT JOIN problem p ON ( p.eventid = e.eventid )   LEFT JOIN hosts ON ( i.hostid = hosts.hostid )   left join trigger_depends td on t.triggerid = td.triggerid_down   where pt.tag='IT-SYSTEM' AND pt.value='SYSTEM-NAME'    AND i.status =0 AND t.status =0 AND hosts.status =0 AND (e.object-0)=0    AND e.severity > 3 AND p.r_eventid IS NULL AND hosts.maintenance_status = 0    AND e.eventid NOT IN (select eventid from event_suppress where userid IS not NULL)    ) AS row

Далее плагин. Для начала запустим AS IS с одним запросом выборки статусов. Заранее известно, что запрос должен вернуть High. Указываем матчинг с нашей метрикой Severity, текстовые трешхолды. Но трешхолд не работает, хотя плашка должна была изменить цвет и показать, по какому параметру засветилась. 

Почему ничего не изменилось? Есть такой пункт Use ‘Disable’ color if no data, который в явном виде дал понять, что скрипт данных не видит. В принципе, ожидаемо, в доке есть упоминание: 

Currently the plugin was tested with influxDB and Graphite. Support for other data sources could be added by demand 

Благо это js, а значит путем просмотра кода и DevTools браузера сможем разобраться, что к чему. Основной код плагина находиться в файле statis_ctrl.js, за рендер отвечает функция onRender(), т.к. у нас нет данных по мнению этой функции, посмотрим, какие данные в неё приходят. За передачу данных рендеру отвечает функция onDataReceived(), которая уже берет данные из запроса, консолидирует данные в seriesHandler и возвращает обратно на рендер. 

onDataRecevied() 

key: "onDataReceived",   value: function onDataReceived(dataList) {   this.series = dataList.map(StatusPluginCtrl.seriesHandler.bind(this));   this.render();   seriesHandler    key: "seriesHandler",   value: function seriesHandler(seriesData) {   var series = new TimeSeries({   datapoints: seriesData.datapoints,   alias: seriesData.target   });   series.flotpairs = series.getFlotPairs("connected");   return series; 

Как видно из кода, от Grafana ожидаются данные target и datapoints. Посмотрим, что мы получаем фактически. Для этого выведем в лог данные из переменной dataList (console.log(dataList);): 

Как видим, при запросе к БД вида table мы не получаем данные в необходимом для нас виде. Два варианта, либо написать обработчик, либо переделать запрос возвращающий TimeSeries. Изначально мы пошли по неправильному пути и написали обработчик.  

onDataRecevied() 

key: "onDataReceived",   value: function onDataReceived(dataList) {   try {   this.series = dataList.map(StatusPluginCtrl.seriesHandler.bind(this));           this.render();   } catch (e) {   var newserie2 = new Array;   for (var j = 0; j < dataList.length; j++) {       for (var i = 0; i < dataList[j].rows.length; i++) {       var newserie = {                       "alias": `${dataList[j].columns[i]['text']}`,                       "target": `${dataList[j].columns[i]['text']}`,                   "datapoints": [[dataList[j].rows[i][0],0],[dataList[j].rows[i][0],1]]       };           newserie2[j] = newserie;           }       }       this.series = newserie2.map(StatusPluginCtrl.seriesHandler.bind(this));       this.render(); 

Да, работает, но есть вариант проще: добавляем в запрос выборку time, чтобы Grafana возвращала TimeSeries.  

Пример одного из запросов:

…………. 

END as «Severity», extract(epoch from now()) as time FROM ( 

…………. 

И о, чудо! Можно приступать к остальным пунктам тз. 

Начнем с отображения данных. Из коробки доступны варианты: выводить метрику по достижению какого-либо трешхолда либо выводить только текст/значение метрики, не отталкиваясь на трешхолды. Нам не подходит. Надо сделать/дописать две вариации вывода: 

• не отображать метрику совсем, при этом использовать трешхолд (используем для Severity, в случае изменения статуса работоспособности ИТ-системы у нас должен поменяться цвет, зачем нам еще текстом это выводить, тем самым занимая место?) 

Поступим немного по-варварски: в файле module.html, есть блоки, отвечающие за выводы метрик, наподобие: 

module.html  

<div ng-style="ctrl.panel.colorMode === 'Metric' && {'color':ctrl.panel.colors.crit}"    ng-class="{'boldAlertMetric': ctrl.panel.fontFormat === 'Bold', 'italicAlertMetric': ctrl.panel.fontFormat === 'Italic'}"    ng-repeat="crit in ctrl.crit">   <a ng-show="crit.url" ng-href="{{ crit.url | interpolateTemplateVars:this }}" target="_blank" style="color:inherit">{{ crit.alias }}</a>   <span ng-hide="crit.url">{{ crit.alias }}</span>   <span ng-show="crit.isDisplayValue"> - {{ crit.display_value | numberOrTextWithRegex : crit.valueDisplayRegex }}</span>   </div> 

Упростим его до: 

module.html  

<div ng-style="ctrl.panel.colorMode === 'Metric' && {'color':ctrl.panel.colors.crit}"    ng-class="{'boldAlertMetric': ctrl.panel.fontFormat === 'Bold', 'italicAlertMetric': ctrl.panel.fontFormat === 'Italic'}"    ng-repeat="crit in ctrl.crit">   <span ng-show="crit.isDisplayValue">{{ crit.alias }} - {{ crit.display_value | numberOrTextWithRegex : crit.valueDisplayRegex }}</span>   </div> 

Тем самым мы убрали привязку к выбору меню Display Alias и оставили только Display Value, зависящую от переменной isDisplayValue. Соглашусь, не самый хороший ход — вырезать часть имеющегося функционала из коробки, но под наши нужды сойдет.   

Отображать метрику только в случае прохождения порога, но не учитывать в состоянии самой плашки (используем для Not acknowledged — отображения не обработанных событий). 

Добавим свой Hendler Type. Так как нам необходимо отображать метрику только в случае превышения трешхолда, и у нас он будет неизменный, то зададим его в явном виде в коде и назовем Hendler Type, соответственно, ‘More Zero’.  

statis_ctrl.js  

-----   < _this.valueHandlers = ['Number Threshold', 'String Threshold', 'Date Threshold', 'Disable Criteria', 'Text Only'];   --   > _this.valueHandlers = ['Number Threshold', 'String Threshold', 'Date Threshold', 'Disable Criteria', 'Text Only', 'More Zero'];   -----   <} else if (target.valueHandler == "Text Only") {   <_this5.handleTextOnly(s, target);   --   >} else if (target.valueHandler == "Text Only") {   >_this5.handleTextOnly(s, target);   >} else if (target.valueHandler == "More Zero") {   >_this5.handleMoreZero(s, target);    -----   < }, {   <key: "updatePanelState",    --   >}, {   >key: "handleMoreZero",   >value: function handleMoreZero(series, target) {   >if (series.displayType == "Annotation") {   >this.annotation.push(series);   >} else {   >if (series.display_value == 0 ) {   >delete series.isDisplayValue;   >}   >this.display.push(series);   >}   >}   >}, {   >key: "updatePanelState",   -----

Уже неплохо, осталось добавить визуальное и звуковое оповещение. Для визуального оповещения воспользуемся эффектом анимации, применяемым к плашке. В данном случае нам необходимо учесть, что анимация должна появляться, когда изменяется статус и пропадать если статус сохраняется. Отталкиваться будем от обновления данных на странице. Так как встраивать все это дело будем в js, нужно как-то между собой различать плашки.   

CSS по линку выше добавляем к нашим CSS плагина (сразу не много поправим, чтобы эффект не вызывал эпилепсию): 

/css/status_panel.css    .blink {    animation-name: blinker;    animation-iteration-count: infinite;    animation-timing-function: cubic-bezier(1.0,2.0,0,1.0);    animation-duration: 1s;    animation-play-state: running;    -webkit-animation-name: blinker;    -webkit-animation-iteration-count: infinite;    -webkit-animation-play-state: running;    -webkit-animation-timing-function: cubic-bezier(1.0,2.0,0,1.0);    -webkit-animation-duration: 1s;  }    @keyframes blinker {    from { opacity: 1.0; }    50% { opacity: 0.5; }    to { opacity: 1.0; }  }    @-webkit-keyframes blinker {    from { opacity: 1.0; }    50% { opacity: 0.5; }    to { opacity: 1.0; }  } 

Далее строим логику в js, чтобы эффекты применялись когда нужно. Для начала объявим переменную массив для хранения статусов, где-нибудь в начале кода:  

statis_ctrl.js 

-----      <}();   <panelDefaults = {   --   >}();   >var GlobalpanelState = [];   >panelDefaults = {   ----- 

Ну и сама логика, за обновление статусов отвечает функция updatePanelState(), до и после описывать не будем, конечный результат выглядит вот так: 

updatePanelState()

key: "updatePanelState",   value: function updatePanelState() {   this.$panelContainer.removeClass('blink');   if (this.duplicates) {   this.panelState = 'error-state';   } else if (this.disabled.length > 0) {   this.panelState = 'disabled-state';   } else if (this.crit.length > 0) {   this.panelState = 'error-state';   } else if (this.warn.length > 0) {   this.panelState = 'warn-state';   } else if ((this.series == undefined || this.series.length == 0) && this.panel.isGrayOnNoData) {   this.panelState = 'no-data-state';   } else {   this.panelState = 'ok-state';   }   if ((GlobalpanelState[this.panel.id] != 'notplaycrit') & this.panelState === 'error-state') {   const music = new Audio('https://zabbix/audio/alarm_disaster.mp3').play();   if (typeof GlobalpanelState[this.panel.id] != "undefined") {   this.$panelContainer.addClass('blink');   }   GlobalpanelState[this.panel.id] = 'notplaycrit';   } else if ((GlobalpanelState[this.panel.id] != 'notplayok') & this.panelState === 'ok-state') {   const music = new Audio('https://zabbix/audio/alarm_ok.mp3').play();   if (typeof GlobalpanelState[this.panel.id] != "undefined") {   this.$panelContainer.addClass('blink');   }   GlobalpanelState[this.panel.id] = 'notplayok';   } else if ((GlobalpanelState[this.panel.id] != 'notplayhigh') & this.panelState === 'warn-state') {   const music = new Audio('https://zabbix/audio/alarm_high.mp3').play();   if (typeof GlobalpanelState[this.panel.id] != "undefined") {   this.$panelContainer.addClass('blink');   }   GlobalpanelState[this.panel.id] = 'notplayhigh';   }   } 

Некоторые особенности: 

В процессе добавления функционала все правки плагина были сделаны “на живую”, непосредственно в коде самого установленного плагина. С восьмой версии Grafana появилась проверка валидации плагина. В случае, если в коде какого-либо плагина были какие-то изменения, Grafana не подхватит его при последующей перезагрузке. Чтобы этого не произошло, плагин надо пересобрать и переподписать.  Сходу пересобрать не получилось, но переподписать то, что получилось, нам это не мешает. Для этого регистрируемся на сайте Grafana, получаем API-key роли PluginPublisher. Задаем переменную окружения GRAFANA_API_KEY. Устанавливаем nodejs с npx. Устанавливаем @grafana/toolkit. Качаем исходники плагина, заменяем файлы в директории dict нашими. И запускаем из корня исходников приватное подписывание плагина: «npx @grafana/toolkit plugin:sign —rootUrls http://ваш_url_grafana/».  

После чего будет получен заветный файл MANIFEST.txt, который поможет нам пройти валидацию, для этого не обходимо в директории плагина заменить файл на полученный. 

 Планы на будущее: 

• переписать плагин полностью под актуальный фреймворк использующейся в Grafana, 

• пересобрать и переподписать плагин уровнем community, а не private, 

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

• поглотить наработки по плагину «Status By Group Panel».