Метрики, графики, статистика = Prometheus + Grafana

Программирование - Инструментарий

графики оперативный учет управление ресурсами складской учет анализ

76
Снятие метрик из базы данных 1С с хранением в Phrometheus и красивое оформление на основе Grafana. Или как мы создавали комфортные условия административному персоналу на отдельно взятом складе.

Часть первая, художественная.

Вступление

 

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

Для начала определимся с тем, что такое оперативный учет. Оперативный учет, проще говоря, это когда решения на основе предоставляемых системой данных принимаются здесь и сейчас. Где нет "пометить на удаление" и "отменить проведение". Где вся структура учета строится исключительно из потребностей бизнеса без учета ПБУ, НК и проч-проч-проч.

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

Самый простой пример оперативного учета - это складская деятельность при достаточно высоком уровне автоматизации склада. Высоким уровнем автоматизации давайте договоримся считать способность системы принимать решения и отдавать задачи исполнителям в режиме on-line. Подобный подход продемонстрирован компанией Axelot  в конфигурации 1С:WMS Логистика. Управление складом.

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

Стандартные отчеты плохо подходят наличием кнопки "Сформировать" и весьма скромными графическими возможностями.

Разнообразные варианты форм с автообновлением по обработчикам ожиданий весьма прилично нагружают систему при мало-мальски существенном объеме выводимой информации.

Хочется чего-то легкого, красивого и понятного...

 

Завязка

 

К предлагаемому варианту решения проблемы подтолкнула, как не странно, квалификация инженеров на проекте. В рамках крупного проекта ежедневно  приходится сталкиваться не только с проблемным поведением 1С, блокировками на СУБД, кривым кодом и нелепыми бизнес-процессами. Есть еще основа всего этого - локальная сеть с кучей оконечного оборудования. Начиная от свитчей и заканчивая терминалами сбора данных. А если копнуть еще глубже - то и у энергоснабжающих организаций бывают проблемы. И все это заканчивается банальным: "1С не работает".

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

 Лирическое отступление первое

 

После настройки системы мониторинга и выводом информации о жизненно важном аппаратном слое системы, жить на проекте стало несколько легче. Шишки перестали падать с такой частотой и с таких высот.

Однако решение проблем административного персонала было в зачаточном состоянии. Управление многоэтажным складом посредством отчетов и полубумажной технологией делало несчастными администраторов.

Попытки построения системы мониторинга процессов на внешних обработках делало несчастными разработчиков и сервер с СУБД.

А чувство прекрасного продолжало настойчиво требовать легкости и понятности.

 

Кульминация

 

По результатам созерцания аккуратных метрик в Grafana логично была предпринята попытка вытащить туда данные напрямую из 1С. Благо, есть плагин, позволяющий дергать данные непосредственно с помощью JSON.  При обновлении дашбордов с метриками раз в 10 секунд (ибо отказы железа по-прежнему хочется видеть оперативно), начала проседать база 1С. Попытки выливать данные в Zabbix и работать от него закончились порванным бубном и стесанной до кости сушеной заячьей лапкой.

Так не выходит

Начали подбирать варианты. Взгляд адепта красно-желтой литературы, отринув мысли о MSSQL и Postgree, начал обращаться в направлении сторонних продуктов. И после череды проб и ошибок остановился на проекте Prometheus. 

  Лирическое отступление второе

 

Prometheus - это, грубо говоря, TSDB (Time series database) - база данных формата NoSQL, организованная для хранения временных рядов, т.е. метрик. Плюс весьма неплохой ассортимент внешних плагинов для сбора данных. Плюс автоочистка истории. Плюс весьма скромные системные требования. Важное различие сборщиков метрик - это разделение на т.н. "pull" сборщиков - которые сами куда-то стучатся и требуют выдать им метрики и "push" сборщики, которые сидят и ждут, что к ним постучатся и принесут данные на блюдечке. Prometheus - pull сборщик, но при использовании плагина Pushgateway становится способен работать и в режиме push. В этом режиме отправка данных инициируется клиентом плагину, которого, в свою очередь, опрашивает Prometheus. И все это добро, как у нас принято, абсолютно free!

В терминах платформы Prometheus, сбор данных называется "scrape" - "соскоб". Т.е. берется срез данных на момент времени, ему присваивается timestamp (время взятия соскоба) и данные убираются в собственное хранилище Prometheus. Одно из выгодных отличий Prometheus является необязательность присвоения timestamp'а при отправке пакета с данным. При отсутствии метки времени присвоение происходит автоматически при помещении данных в базу Prometheus.

Чувству прекрасного для экстаза не хватало только понятности.

 

Развязка

 

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

Альтернатива

Источником данных по-прежнему является 1С, однако хранение данных осуществляется в сторонней базе, а сбор данных происходит "соскобами", исключающими запросы с большой глубиной периода. "Соскобы" осуществляются двумя способами:

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

2) Для съема метрик по фактически занесенным данным в результате жизнедеятельности пользователей, используется pull метод, когда регламентным заданием снимается срез данных (условно - остатки, не обороты) и заботливо подготовленные метрики ожидают запроса от Prometheus.

Обоими способами снятые метрики отправляются на хранение в Prometheus, откуда их читает Grafana  с нужной периодичностью и с нужными временными границами.

А теперь - слайды:

Управление отгрузкой

Технадзор отгрузка

 

Часть вторая, техническая, теоретическая.

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

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

 

Основным элементом конфигурации является справочник "Метрики", в котором содержатся алгоритмы сбора метрик.

Процесс описания метрики  заключается в написании произвольного кода на языке 1С. Выполняется на сервере. Входные параметры отсутствуют.  

В результате выполнения алгоритма получения метрики, должна быть сформирована переменная с именем "ТаблицаЗначений" и одноименного типа. В таблице значений в обязательном порядке должна присутствовать колонка "ЗначениеМетрики", в которое записывается числовой показатель метрики. Дополнительные колонки таблицы значений расцениваются как ярлыки (в терминологии Phrometheus), где имя ярлыка = имя колонки, а значение = строковому значению в ячейке. Эти поля удобно использовать для фильтрации данных при выводе в Grafanа.

Вариант PULL:

Регламентное задание конфигурации через равные промежутки времени запускает на выполнение все алгоритмы из справочника "Метрики" с типом pull не помеченные на удаление. Результат выполнения раскладывается в регистр сведений в текстовом формате, понятном Prometheus. При обращении платформы Prometheus к HTTP-публикации базы 1С, происходит чтение данных из регистра, агрегация в единый пакет и выдача ответом на REST запрос.

Вариант PUSH:

По событию системы вызывается элемент справочника "Метрики" и выполняется его обработчик. По окончанию обработки метрики отправляются в Pushgateway.

ИЛИ

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

 

Настройки конфигурации:

- Константа "URL Pushgateway": адрес сбора метрик службой Pushgateway 

- Константа "Число повторных запросов метрики": количество раз, которое метрика будет отдана Prometheus при повторных обращениях. Каждое обновление метрики обнуляет счетчик. Используется для исключения провалов графиков в случае длительного формировании метрики и/или частого опроса Prometheus'ом.

 

P.S. Критика, пожелания, дополнения - горячо приветствуются!

76

Скачать файлы

Наименование Файл Версия Размер
Метрики, графики, статистика = Prometheus + Grafana:
.cf 36,24Kb
23.10.18
131
.cf 1.0.0.3 36,24Kb 131 Скачать бесплатно

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. Synoecium 401 23.10.18 14:37 Сейчас в теме
2. pallid 188 23.10.18 14:53 Сейчас в теме
Спасибо за конфигурацию

При обращении платформы Prometheus к HTTP-публикации базы 1С, происходит чтение данных из регистра


а каким образом происходит обращение? как это реализовывается в Prometheus?
3. freewms 76 23.10.18 15:32 Сейчас в теме
(2) Предполагается, что "тяжелые" запросы пишут в регистр по факту выполнения, а Prometheus, который опрашивает систему раз в -дцать секунд вместо выполнения "тяжелого" запроса считывает метрику из регистра, предварительно туда записанную.
В дальнейшем предполагается обеспечить возможность считывания одной и той же метрики несколько раз до ее устаревания. Это необходимо, когда частота регламентного опроса Прометеем превышает частоту формирования "тяжелой" метрики.
4. pallid 188 23.10.18 15:44 Сейчас в теме
(3) хотелось уточнить чем забирать данные из http-сервиса? как и чем это настраивается? это выполняет отдельное приложение?
5. freewms 76 23.10.18 15:54 Сейчас в теме
(4) Данные забирает непосредственно сам Прометей.
У него есть понятие "Цель" - это те http-сервисы, которые он опрашивает с определенной периодичностью и забирает соскобы себе в базу.

В приложенном файле - настройка Прометея на 3 цели: сам себя - показатели статистики, PushGateway - для получения с него метрик из короткоживущих процессов (отправляемые в PushGateway методом PUSH) и база WMS, которая и является основным поставщиком данных.
Прикрепленные файлы:
6. freewms 76 23.10.18 16:16 Сейчас в теме
(4) https://prometheus.io/docs/prometheus/latest/getting_started/ тут описание в т.ч. первичная настройка целей и частоты их опроса.
7. pallid 188 23.10.18 17:19 Сейчас в теме
(6)

в prometheus.yml добавить:

  - job_name: 'test'

    basic_auth:
      username: 'Администратор'
      password: ''
      
    scrape_interval: 10s 
    metrics_path: '/test/hs/prometheus/polling' 

    static_configs:
    - targets: ['localhost']
Показать


вроде разобрался
8. freewms 76 23.10.18 17:29 Сейчас в теме
(7) У Вас публикация выполнена на той же системе где стоит Прометей?
И есть подозрение, что кириллицу в части учетки Прометей не воспримет - не проверял, не знаю.
9. pallid 188 23.10.18 17:40 Сейчас в теме
(8) Да, для теста там же

Нормально воспринимает
10. freewms 76 23.10.18 17:42 Сейчас в теме
11. pallid 188 23.10.18 17:52 Сейчас в теме
Какой у вас рецепт для отображения http status code? поделитесь если есть
12. freewms 76 23.10.18 18:31 Сейчас в теме
(11) Посмотрите код http метода get. Там есть формирование кода ответа.
13. freewms 76 23.10.18 18:34 Сейчас в теме
(11) Дополню - часть кодов дает сам web-сервер, часть - 1С. Например, если публикация не сделана на web-сервере, получите 404 средствами web-сервера. А вот если публикация есть, но rest не соответствует шаблону - получите status-код силами 1С.
14. pallid 188 23.10.18 22:10 Сейчас в теме
А вот если публикация есть, но rest не соответствует шаблону - получите status-код силами 1С


То что нужно, а то хотелось уже писать шаблон для ответа
15. freewms 76 23.10.18 22:17 Сейчас в теме
(14) Под "силами 1С" подразумевал описанную программистом реакцию системы на http-запрос.
Пример из конфы в аттаче статьи:
код формирования статуса
16. freewms 76 23.10.18 23:48 Сейчас в теме
Если сообществу интересно - на следующей неделе смогу опубликовать доступ к треккеру по ошибкам и фичам подсистемы. Можно попробовать совместную разработку, еcли есть желающие. EDT, Git и вся фигня.
eeeio; Labotamy; vanoono; pallid; shalimski; +5 Ответить
20. pallid 188 24.10.18 08:41 Сейчас в теме
(16)
Можно попробовать совместную разработку, еcли есть желающие. EDT, Git и вся фигня


да, а то даже нет возможности поставить ее на поддержку, пришлось свою сборку делать конфигурации поставщика
32. freewms 76 24.10.18 23:00 Сейчас в теме
(20) (22)
Договорились! Отпишусь в теме.
22. vanoono 24.10.18 10:20 Сейчас в теме
(16)
Git


Да, думаю идея отличная, думаю найдется куча людей которые внесут свой вклад в разработку. Особенно с учётом,
как у нас принято, абсолютно free!
25. Labotamy 24.10.18 14:30 Сейчас в теме
(16)Выливай на гитхуб уже =)
vanoono; acanta; +2 Ответить
33. freewms 76 24.10.18 23:02 Сейчас в теме
(25) Леш, у меня свой локальный Git, поскольку я несколько параноидален.
17. CheBurator 3566 24.10.18 02:33 Сейчас в теме
Управление многоэтажным складом посредством отчетов и полубумажной технологией делало несчастными администраторов.

- склад под управлением какой WMS?
21. freewms 76 24.10.18 08:52 Сейчас в теме
(17) Есть самописки, есть Axelot
18. CheBurator 3566 24.10.18 02:41 Сейчас в теме
19. shalimski 5 24.10.18 03:12 Сейчас в теме
Рассматривали ли вы в качестве TSDB InfluxDB?
28. freewms 76 24.10.18 22:55 Сейчас в теме
(19) Простота интеграции Прометея сыграла свою злую роль.
23. vanoono 24.10.18 10:28 Сейчас в теме
В идеале сделать готовую сборку, в виде Docker контейнера , с Prometeus, Grafana, сервером 1С и тестовыми данными, чтобы так - Docker RUN и экстаз..
24. akimych 169 24.10.18 13:13 Сейчас в теме
Попытки выливать данные в Zabbix и работать от него закончились порванным бубном и стесанной до кости сушеной заячьей лапкой.


Привет, а что не так с Заббиксом?
У меня с ним проблем не возникло, и Графана успешно начитывает данные с Забикса.
29. freewms 76 24.10.18 22:56 Сейчас в теме
(24) На пикчах видно, что наша Графана выводит данные с 3-х систем - двух Заббиксов и одного Прометея.
Решали не проблему связки Заббикс-Графана - там проблем нет за исключением Алертов, а проблему "Куда деть данные оперативного учета из 1С"
34. akimych 169 25.10.18 10:11 Сейчас в теме
(29) Данные оперативного учета я так понимаю нужны для
для принятия управленческих решений
.

На мой взгляд Графана не совсем верное решение для таких целей, она для - цитата с офиц. сайта
Grafana allows you to query, visualize, alert on and understand your metrics no matter where they are stored
, т.е. это все-таки тул для системного мониторинга.

В данном случае лучше подойдет PowerBI, который умеет не только представлять данные, но и крутить их в разные стороны.
35. freewms 76 25.10.18 12:03 Сейчас в теме
(34)
Смотря что мы понимаем под оперативным учетом. Оперативный учет != отчеты о продажах за месяц. Оперативный учет на складе - это оценка изменения загруженности зон на горизонтах 30мин-1час, достаточности сотрудников по факту и распределение их по направлениям деятельности. И да, алерты по проблемным узлам тоже.
Это не аналитика. Это желание оперативно реагировать на возникающие проблемы по заранее выставленным контрольным точкам.
26. the1 321 24.10.18 16:52 Сейчас в теме
порадовало
РегистрСведений.ФИОФизическихЛиц.СоскобПоследних(ДатаСоскоба)
30. freewms 76 24.10.18 22:57 Сейчас в теме
(26) Интересный регистр. Не могли бы Вы пояснить назначение? Не могу понять потребность его скоблить.
27. metmetmet 59 24.10.18 19:26 Сейчас в теме
А стек ELK рассматривали? Если да, то чем не устроил?
31. freewms 76 24.10.18 22:59 Сейчас в теме
(27) Elastiksearch вижу скорее как хранилище текстовых логов, а не упорядоченных временных серий. Как раз сейчас думаем на счет слива ТЖ в него для анализа проблем.
36. metmetmet 59 28.10.18 18:37 Сейчас в теме
Рассматривали вариант, когда prometheus сервер находится вне локальной сети для получения метрик pull способом?
37. freewms 76 28.10.18 23:15 Сейчас в теме
(36) Нам не приходилось, но в целом не вижу сложности. Если сможете обеспечить REST - должно работать.
38. pallid 188 29.10.18 16:11 Сейчас в теме
если ресурс не умеет отвечать в формате prometheus тогда в тагретах пишет что
invalid is not a valid start token


а по сути хочется только мониторить живучесть сервиса...

альтернатива писать прослойку - которая будет ретранслировать состояние сервиса? или есть еще варианты?
39. freewms 76 30.10.18 18:04 Сейчас в теме
(38) Живучесть сервиса - Zabbix
40. pallid 188 30.10.18 23:20 Сейчас в теме
41. metmetmet 59 13.11.18 20:31 Сейчас в теме
(38) Есть вот такое расширение blackbox_exporter.
Вот здесь список официальных и неофициальных расширений (exporters) список.
Оставьте свое сообщение