Использование системы мониторинга Zabbix с 1С для мониторинга ключевых показателей бизнеса

Меня зовут Алексей Орловский, я руковожу ИТ-отделом компании, обслуживающей такие брэнды как СушиВок, ПиццаМафия и прочие фирмы в сфере HoReCa.

Мой доклад посвящен обзору нашей интеграции 1С и Zabbix для построения дашбордов и мониторинга ключевых показателей бизнеса.

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

Для примера, я каждый день слежу за ситуацией с коронавирусом в мире на сайте университета Джонса Хопкинса. Благодаря своевременно увиденному ухудшению ситуации в Италии, я успел отменить поездку с женой в марте в Рим.

Почему именно Zabbix? Если в поиске на HeadHunter ввести «Системный администратор Zabbix» мы увидим 928 резюме. Проверив таким же способом аналогичные системы мониторинга ИТ-инфраструктур, мы получим количество резюме в разы меньше.

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

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

Всем рекомендую изучать Zabbix по инструкции www.zabbix.com/documentation/4.0/ru/start. Все сказанное в этом докладе делалось на основании данной инструкции и на Zabbix версии 4.0.

Настройка Zabbix

Основная наша идея заключалась в том, чтобы сделать в 1С HTTP-сервис, через который Zabbix будет забирать информацию из базы данных и строить на ее основании метрики, триггеры и оповещения.

Для начала разберемся, что такое узлы сети.

В обычном понимании мониторинга Zabbix узлы сети – это элементы инфраструктуры (такие как сетевое оборудование, физические и виртуальные сервера, базы данных, источники бесперебойного питания и прочее), с которых Zabbix постоянно считывает информацию.

В нашем случае, узлы сети – это торговые точки, производства, города и даже базы 1С. Это то, по чему мы хотим получать информацию.

На слайде показан узел сети – торговая точка сети СушиВок Санкт-Петербурга:

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

• узел имеет IP адрес – это адрес базы, где находится данная торговая точка.

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

На примере, показанном на слайде, макросы узла сети – это:

• адрес URL базы, где находится торговая точка;

• GUID данной точки.

Таким образом узлы сети — это элементы бизнеса, которые необходимо мониторить.

Переходим к элементам данных.

По сути, элемент данных – это и есть метрика. Даже в инструкции на сайте Zabbix написано, что элемент данных – это метрика, поэтому прошу не путаться, если я буду называть оба варианта.

Итак, метрика – это конкретный фрагмент данных, получаемый от узла сети.

Мы подразделяем метрики на «родительские» и зависимые.

«Родительские» метрики с некоторой периодичностью отправляют в 1С JSON с нужными ключами метрик, а в ответ получают из 1С JSON с такой же структурой, но уже с полученными данными.

В примере мы отсылаем ключи метрик:

• MaxTimeKitchen – максимальное время отдачи кухни;

• CountOrdersInKitchen – количество заказов на кухне и т.д.

И вместе с каждым ключом метрик отправляем $STOREGUID – это тот самый пользовательский макрос из узла сети.

На следующем слайде представлен пример JSON-структуры, полученной из базы 1С. Здесь мы видим результаты запрошенных метрик – например, максимальное время отдачи кухни равно 9 минутам, а активных заказов сейчас 2.

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

В примере на слайде мы видим зависимую метрику «Совокупное время доставки», которая обновилась в 22:29 и получила информацию, что данный параметр равен 35 минутам.

Разбор JSON в Zabbix стал возможен с версии 4.0, которая вышла в 2018 году.

Сбор метрик на стороне 1С

Теперь обратимся к тому, что было сделано в 1С.

Мы добавили иерархический справочник «Метрики Zabbix», в котором у элемента есть ключ метрики, по которому 1С понимает, какую именно метрику в данный момент запрашивает Zabbix.

Для каждого элемента справочника «Метрики Zabbix» указывается текст запроса, который нужно выполнить, поэтому для добавления новых метрик не надо обновлять 1С. Это очень удобно.

Ну и какие запросы без параметров.

На слайде показан параметр Guid, значение которого мы передаем в JSON с помощью макроса узла сети. Значение этого параметра сразу же подхватывается в запрос и позволяет получить данные по нужной торговой точке.

Также параметры могут быть:

• ссылками на элементы базы данных;

• списком ссылок;

• и даже исполняемым кодом, как ТекущаяДата на представленном примере.

Следующим этапом мы добавили в справочник «Метрики Zabbix» постобработку – это было необходимо для формирования более сложных JSON-ов с несколькими полученными запросом результатами.

Результат в Zabbix – метрики и триггеры

В итоге мы получаем метрики в Zabbix.

На представленном графике показаны значения метрик по одной Киевской точке. Мы видим, какими в период с 19 до 20 часов были значения показателей:

• время кухни в инфо-табло – зеленая линия;

• количество заказов – красные точки;

• и максимальное время отдачи кухни – синяя линия.

На основании полученных метрик мы настроили триггеры.

Триггеры – это выражения, определяющие порог проблемы:

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

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

На примере показан триггер, открывающий проблему, когда время отдачи кухни будет на 5 минут больше, чем регламентное. Это мы можем увидеть в последнем неравенстве, где MaxTimeKitchen.last() > TimeOfKitchenInInfo.last() + 5. Все остальные неравенства всегда истинны и указаны здесь, потому что в Zabbix в оповещениях о проблеме нельзя использовать метрики, если они не присутствуют в выражении триггера.

Оповещения в Telegram

Соответственно из этих метрик мы сделали оповещения через Telegram – в СушиВок для оперативной информации используется именно Telegram, а не почта. Причем, в Zabbix оповещения для Telegram настраиваются «из коробки».

В оповещениях операционный отдел просил указывать всю информацию о точке – количество поваров, сумма чеков, количество чеков в комплектации и т.д., чтобы можно было полностью понимать, какая ситуация на точке была во время сбоя. Из-за этого в выражении триггера и нужны были эти лишние всегда истинные неравенства. Но при большом объёме срабатывающих триггеров из-за всей этой информации сообщения стали не читаемы – получалось полотно из слов.

Поэтому я воспользовался советом Родислава Гандапаса из книги «К выступлению готов», где он при подготовке к выступлениям на карточках рекомендует использовать пиктограммы, т.к. они быстрее читаются при беглом взгляде.

Так в наших оповещениях появились:

• ножи – это кухня;

• черепашки – это доставка;

• огоньки – если проблема не закрыта больше 10 мин.

Операционный отдел был очень доволен данными оповещениями.

Grafana

Но на этом мы не остановились и подключили к Zabbix-у дашборды на основе Grafana. Это кроссплатформенное программное обеспечение с открытым исходным кодом для аналитики и интерактивной визуализации отчетов. Благо эти проекты (Grafana и Zabbix) очень хорошо дружат и настраиваются из коробки.

И после этого мы стали для всех штамповать удобные дашборды, т.к. в графане это делается очень просто и получается красиво.

На слайде показан пример дашборда по сравнению производительности сотрудников 15 точек для территориального директора.

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

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

Обратите внимание, что на графиках в графане можно оставлять комментарии, чтобы позже не вспоминать, что случилось на точке, и почему у них были такие показатели.

Получив такие дашборды, операционный отдел уже хлопал стоя.

Действия в Zabbix

Но и на этом мы не остановились. И сделали в 1С сервис, который принимает запрос из Zabbix и исполняет код из справочника.

Давайте рассмотрим эту функциональность подробнее.

До этого в Zabbix при срабатывании триггера мы использовали только оповещения, но есть еще пользовательские скрипты. Для их использования мы поставили curl на сервере Zabbix, и с помощью команды из пользовательского скрипта стали отправлять в 1С JSON с ключами действий, которые необходимо выполнить при открытии либо при закрытии данной проблемы.

Обращаю внимание, что в команде мы опять же используем пользовательский макрос $STOREGUID для передачи значения GUID из узла сети.

В 1С же мы сделали еще один справочник – «Действия Zabbix», в котором имеется:

• ключ действия;

• исполняемый код;

• параметры, в которые аналогично параметрам из метрик может быть передан GUID из JSON, присылаемого Zabbix-ом, также параметры могут быть исполняемым кодом или списком элементов базы данных.

Таким образом мы сделали наш мониторинг про-активным.

Примеры использования данных возможностей в СушиВок:

• автоматическое поднятие времени отдачи на точке;

• постановка доставки на стоп;

• создание и закрытие записей о сбое в 1С и прочее.

Итоги интеграции

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

Оценим трудозатраты…

• Мы работаем по SCRUM’у, поэтому разработка интеграции у нас заняла четыре спринта – четыре недели (спринты у нас длятся одну неделю).

• Оповещения в Telegram и дашборды в Grafana заработали уже после двух первых спринтов.

• Работали над проектом два программиста 1С и затратили 16,5 ч/ч разработки.

С какими трудностями интеграции и настройки Zabbix мы столкнулись?

• Как я уже упоминал, в оповещениях можно использовать только метрики присутствующие в выражении триггера, из-за этого выражения превращаются в нечитаемую простыню неравенств.

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

• Третье – это назначение прав только группе пользователей на группу узлов, из-за этого человеку, который управляет одной точкой, нужно создавать отдельную группу узлов сети и отдельную группу пользователей.

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

Но все это было не критично, поэтому перейдем к подведению итогов интеграции.

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

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

Удобное устройство шаблонов в Zabbix и макросы позволили подключать новые города с 50 точками за 20 минут.

За счёт этого мониторинг уже работает более чем на 300 точках.

Получившийся инструмент полезен не только для операционного отдела, но и для других. Например:

• тех. поддержка использует для мониторинга времени обработки заказов с сайта;

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

Это позволило выявлять проблемы раньше, чем это заметят пользователи, увеличивая уровень предоставляемых сервисов.

За счет автоматизации контроля состояния точек, получилось сократить количество сотрудников, занимающихся этим до появления Zabbix.

Раньше они следили за временем отдачи на точках, временем доставки, открывали и закрывали сбои в 1С, повышали время и останавливали работу точек в экстренных ситуациях и т.д. Теперь все это делает Zabbix.

Что дальше

И в заключение, что мы ещё придумали сделать с Zabbix-ом?

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

Таким образом я задумал сделать для всех отделов – Снабжения, бухгалтерии, ИТ и прочих свои метрики и триггеры, на основании которых подписать с бизнесом SLA. Мне кажется, это будет самый честный и эффективный KPI, как для отделов, так и для бизнеса.

Вопросы

• В последней версии Zabbix они не обещают решить проблему «девяти метрик»?

• Когда я смотрел выступление разработчиков, которые рассказывали про возможности, которые они собираются включить в Zabbix версии 5.0, там ничего такого не было

• Если не секрет, расскажите какие-нибудь кейсы с использованием интересных метрик и реакцию на них?

• У нас, если при обмене данными накапливается большая очередь, и не отправляются данные больше 30 минут, всем программистам из Zabbix на почту рассылается сообщение, что очередь встала.

• Расскажите про структуру сети Zabbix, сколько у вас серверов, есть ли прокси?

• У нас используется один сервер Zabbix. На сервере 1С никакие вспомогательные прокси-серверы не разворачиваются – у нас центральный Zabbix сам запрашивает все данные, и этот обмен происходит с помощью веб-сервисов.

• Метрики считывает 1С регламентным заданием или Zabbix периодически JSON запрашивает?

• Когда вы настраиваете метрику в Zabbix, там очень гибко настраивается время опрашивания, вплоть до того, что ты можешь запрашивать эту метрику только по будням с 9 до 10, чтобы лишний раз не дергать 1С. И Zabbix каждый раз отправляет родительский JSON со списком метрик и GUID-ами узлов, которые хочет получить. И в ответ получает полный JSON с данными. А уже зависимые метрики разбирают этот JSON и получают из него элементы данных. Поэтому, отвечая на вопрос – никаких регламентных заданий. Это зло.

• По поводу множества запросов в разные 1С. Вы говорите, что они легко подключаются. Как реализовано внедрение вашей подсистемы в эти базы?

• Мы делали расширение 1С, чтобы можно было его подключать в несколько конфигураций.

• Будет ли выложена эта публикация?

• Собирались опубликовать. Выложу с инструкцией.

• При онлайн-мониторинге и большом количестве метрик есть ли деградация производительности 1С?

• Да, один раз было такое. Архитектурно немного некорректно сделано то, что в одной базе может быть 100 точек. И по сути, если метрика запрашивается каждую минуту, то каждую минуту запрашивается сто раз по количеству узлов. Но по-другому в той архитектуре, которую мы задумали, не сделать. Но даже при больших нагрузках все равно отрабатывало. Бывало, что, если метрика раз в минуту запрашивается, бывают пропуски, а потом все нормально идет подряд. Поэтому некритично. Когда мы все это архитектурно задумывали, мы сначала под этот проект хотели сделать отдельную базу SQL, но нам это не понадобилось

• А вы не думали про такую модель, как выгрузка этой информации из 1С? Это как раз к этим регламентных заданиям. Когда вы архитектурное решение проектировали, вы не думали о том, что пусть 1С куда-нибудь «плюет» в RabbitMQ или еще какую-нибудь очередь, а Zabbix уже из нее получает?

• По поводу RabbitMQ я пока не понял до конца всех плюсов – наверное, у нас нет таких объемов. Честно говоря, я против регламентов. У нас получилось очень гибко, и за счет этой гибкости очень легко настраиваются все эти метрики, триггеры без доработки конфигурации. Не хочется делать какие-то регламенты, потому что их потом придется дописывать дополнительно.

• В PRTG есть карты (maps) – это такое поле x на y в графическом виде, куда можно вытащить любые сенсоры. Очень удобно – все разноцветное. Есть ли такое в Zabbix?

• Это скорее вопрос к Grafana. В Zabbix есть графики, но они слишком упрощенные. Grafana в этом плане гораздо интереснее. Там есть различное представление отображаемой информации – не только графики. Там есть спидометры, индикаторы и т.д. Очень большое количество дашбордов, на любой вкус можно найти.

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Saint Petersburg.Online.