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

24.02.19

Администрирование - Мониторинг

Снятие метрик из базы данных 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. Критика, пожелания, дополнения - горячо приветствуются!

UPD 24.02.19: Присоединяйтесь! Разработка обрела свой адрес

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

См. также

Мониторинг баз и серверов 1С

Журнал регистрации Мониторинг Платформа 1С v8.3 Платные (руб)

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

9000 руб.

28.08.2019    30954    14    21    

66

Конфигурация Session Monitor

Мониторинг Инструменты администратора БД Платформа 1С v8.3 Россия Платные (руб)

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

1500 руб.

01.12.2020    14225    32    0    

47

Yellow Watcher - Жёлтый наблюдатель за информационными базами

Мониторинг Платформа 1С v8.3 Абонемент ($m)

Программный комплекс мониторинга качества работы информационных баз. Статистика возникновения управляемых блокировок (тип, последняя строка контекста, контекст). Анализ длительных запросов по данным из технологического журнала. Анализ потребления ресурсов СУБД запросами и статистика ожиданий по данным из Query Store. Монитор информационной базы - получение плана запроса для сеанса 1С.

1 стартмани

12.02.2024    3039    23    sdf1979    11    

51

Проверка доступа к интернет на сервере 1С

Мониторинг Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 Абонемент ($m)

Инструмент для проверки интернет - соединения на сервере 1С

3 стартмани

23.11.2023    1818    5    1395969    4    

2

Магия преобразований Vector, часть 3: журнал регистрации + прямой экспорт ошибок в Sentry

Журнал регистрации Мониторинг Абонемент ($m)

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

1 стартмани

19.11.2023    665    2    AlexSTAL    0    

6

Магия преобразований Vector, часть 2: технологический журнал

Технологический журнал Мониторинг Абонемент ($m)

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

1 стартмани

15.11.2023    765    4    AlexSTAL    0    

8

Магия преобразований: ЖР, ТЖ, RAS/RAC, логи - универсальное решение Vector

Мониторинг Журнал регистрации Технологический журнал Абонемент ($m)

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

1 стартмани

13.11.2023    2967    4    AlexSTAL    0    

42

Чем Service Discovery поможет 1С-нику и его клиентам?

Тестирование QA Мониторинг Бесплатно (free)

Если развернуть слепок рабочей среды в окружении для тестирования, тесты могут начать взаимодействовать с рабочим окружением. Расскажем о том, как автоматически перенастраивать базы 1С под окружение разработки или тестирования с помощью концепции Service Discovery.

08.11.2023    2919    ktb    0    

18
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Synoecium 778 23.10.18 14:37 Сейчас в теме
2. pallid 270 23.10.18 14:53 Сейчас в теме
Спасибо за конфигурацию

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


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

В приложенном файле - настройка Прометея на 3 цели: сам себя - показатели статистики, PushGateway - для получения с него метрик из короткоживущих процессов (отправляемые в PushGateway методом PUSH) и база WMS, которая и является основным поставщиком данных.
Прикрепленные файлы:
6. freewms 147 23.10.18 16:16 Сейчас в теме
(4) https://prometheus.io/docs/prometheus/latest/getting_started/ тут описание в т.ч. первичная настройка целей и частоты их опроса.
7. pallid 270 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 147 23.10.18 17:29 Сейчас в теме
(7) У Вас публикация выполнена на той же системе где стоит Прометей?
И есть подозрение, что кириллицу в части учетки Прометей не воспримет - не проверял, не знаю.
9. pallid 270 23.10.18 17:40 Сейчас в теме
(8) Да, для теста там же

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


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


да, а то даже нет возможности поставить ее на поддержку, пришлось свою сборку делать конфигурации поставщика
32. freewms 147 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 147 24.10.18 23:02 Сейчас в теме
(25) Леш, у меня свой локальный Git, поскольку я несколько параноидален.
17. CheBurator 3119 24.10.18 02:33 Сейчас в теме
Управление многоэтажным складом посредством отчетов и полубумажной технологией делало несчастными администраторов.

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


Привет, а что не так с Заббиксом?
У меня с ним проблем не возникло, и Графана успешно начитывает данные с Забикса.
29. freewms 147 24.10.18 22:56 Сейчас в теме
(24) На пикчах видно, что наша Графана выводит данные с 3-х систем - двух Заббиксов и одного Прометея.
Решали не проблему связки Заббикс-Графана - там проблем нет за исключением Алертов, а проблему "Куда деть данные оперативного учета из 1С"
34. akimych 227 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 147 25.10.18 12:03 Сейчас в теме
(34)
Смотря что мы понимаем под оперативным учетом. Оперативный учет != отчеты о продажах за месяц. Оперативный учет на складе - это оценка изменения загруженности зон на горизонтах 30мин-1час, достаточности сотрудников по факту и распределение их по направлениям деятельности. И да, алерты по проблемным узлам тоже.
Это не аналитика. Это желание оперативно реагировать на возникающие проблемы по заранее выставленным контрольным точкам.
Bassgood; +1 Ответить
26. ixijixi 1775 24.10.18 16:52 Сейчас в теме
порадовало
РегистрСведений.ФИОФизическихЛиц.СоскобПоследних(ДатаСоскоба)
30. freewms 147 24.10.18 22:57 Сейчас в теме
(26) Интересный регистр. Не могли бы Вы пояснить назначение? Не могу понять потребность его скоблить.
27. metmetmet 81 24.10.18 19:26 Сейчас в теме
А стек ELK рассматривали? Если да, то чем не устроил?
31. freewms 147 24.10.18 22:59 Сейчас в теме
(27) Elastiksearch вижу скорее как хранилище текстовых логов, а не упорядоченных временных серий. Как раз сейчас думаем на счет слива ТЖ в него для анализа проблем.
36. metmetmet 81 28.10.18 18:37 Сейчас в теме
Рассматривали вариант, когда prometheus сервер находится вне локальной сети для получения метрик pull способом?
37. freewms 147 28.10.18 23:15 Сейчас в теме
(36) Нам не приходилось, но в целом не вижу сложности. Если сможете обеспечить REST - должно работать.
38. pallid 270 29.10.18 16:11 Сейчас в теме
если ресурс не умеет отвечать в формате prometheus тогда в тагретах пишет что
invalid is not a valid start token


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

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

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

Могли бы Вы написать подробнее - почему данный подход не получился. Это же "классический" подход по сбору метрик, и уже был описан на инфостарте.

И, хотелось бы больше слайдов и текста по проведения настроек связки продуктов друг с другом и самих метрик.
LastRoot; +1 Ответить
43. freewms 147 30.11.18 09:16 Сейчас в теме
(42) Обратите внимание, какие метрики передаются в Прометея. Там накапливаются не данные о состоянии оборудования. Содержимое Прометея - это условные деньги в кассе, задолженности контрагентов, остатки на складе. Т.е. непосредственно данные бизнеса. Т.е. условные отчеты из условного 1С.
44. Darklight 32 30.11.18 09:31 Сейчас в теме
(43)Я просто не понимаю разницы в хранении (или нюанса передачи на хранение) данных о количестве соединений с серверов, количестве замятий бумаги на принтере, длинне очереди диска, или количества товаров на складе, количества занятых рабочих на складе, длинне очереди текущих заказов на сборку.
45. freewms 147 30.11.18 09:37 Сейчас в теме
(44) Нюанс заключается исключительно в инструментарии, который для этого есть. Собственно, в Заббиксе достаточно достаточно сложный инструментарий, заточенный под сбор данных по железкам. С набором устоявшихся стандартных механизмов по отрасли.
Прометей позволяет сделать сильно проще использование системы со стороны наполнения ее данными. При этом, система прозрачна для программистов и позволяет организовать передачу данных привычным кодом на привычном языке.
Уточнюсь - обобрать данные в 1С запросом, затолкать в Заббикс, получить там несколько разрезов будет выглядить так:
- Содаем кучу хостов по ожидаемым разрезам запроса
- Формируем, скажем, JSON силами 1С
- Кладем его куда-нибудь
- Пишем скрипт парсинга полученного файла
- Наталкиваем в Заббикс
- Сталкиваемся с проблемой вывода, скажем, в таблицу в Графане

Прометей + приложенная конфигурация - сводится к написанию запроса. Остальное происходит силами самого Прометея. При этом, со стороны Графаны поддерживаются запросы, которые позволят не определять заранее разрезы вывода.
46. tvm 30.11.18 10:18 Сейчас в теме
(44) имеется ввиду что периодически получаемые данные лучше где-то хранить и оттуда считывать Grafan-ой, нежели постоянно дергать 1С-ку и передавать в нее параметры, т.е. динамически получать
47. freewms 147 30.11.18 15:11 Сейчас в теме
(46) Очень точно сказано.
Дополню:Это позволяет при складском учете работать "на переднем крае" данных. Т.е. держать в кеше СУБД их и, практически, не обращаться к диску.
Строить запросы, тем более глубокие - тяжело с точки зрения нагрузки на СУБД.
48. sparhh 06.12.18 09:31 Сейчас в теме
(47) Можете еще раз пояснить - почему ZABBIX не может работать в таком же варианте?
Точно также запрашивать 1С через веб сервисы и сохранять у себя данные. Он ведь все это умеет, разве нет?
49. freewms 147 06.12.18 12:50 Сейчас в теме
(48) Пробуйте. Я не вижу в этом целесообразности потому что::
а) Сложности с механизмами подключения к 1С самого Заббикса.
б) Нагрузка на базу при вытаскивании данных периодами.
50. tvm 06.12.18 12:58 Сейчас в теме
(49)
насчет пункта а) не соглашусь.
насчет б) да, такое может быть
51. sparhh 06.12.18 13:39 Сейчас в теме
(49) Пожалуй еще раз перечитать надо.
В итоге все выглядит красиво, но по-моему для многих осталась нераскрытой тема почему не стал использоваться тот же ZABBIX.
52. freewms 147 06.12.18 21:57 Сейчас в теме
(51) Попробуйте получить Заббиксом из 1С данные, скажем, для построения графика динамики отгрузки клиентов с разбивкой по часам за сутки. Я правда не знаю как это сделать без насилия над собой и окружающими.
53. Steelvan 302 11.01.19 12:04 Сейчас в теме
(52) Собственно в том и вопрос.
Мы просим Вас описать трудности, которые возникнут, если использовать Zabbix, и которые будут отсутствовать, если использовать Прометея.
Спасибо.
54. freewms 147 11.01.19 22:54 Сейчас в теме
(53) Я не знаю типовых методов получения данных из 1С Заббиксом. В голове крутятся агенты Заббикса, дергающие скрипты, делающие выгрузки в текстовички из 1С но я это не прорабатывал, что бы выкладывать сюда. Отмел сразу на уровне идеи.
55. freewms 147 24.02.19 22:02 Сейчас в теме
Добавил ссылку на разработку. Разработка ведется в формате EDT. Присоединяйтесь!
56. narodukr 6 19.09.19 13:31 Сейчас в теме
Добрый день.
Спасибо за публикацию. Очень интересно.
Подскажите для тех кто живет еще в прошлом веке и не использует EDT,
где можно взять архив с примером данной разработки?
57. freewms 147 20.09.19 07:26 Сейчас в теме
58. ilijaz 23.09.19 10:15 Сейчас в теме
Насчет критики zabbix не согласен.
Да, он больше заточен под работу с сетевым и серверным оборудованием, что несет в себе лишний оверхед в настройках.
НО
Никто не запрещает вам сделать правило обнаружение и создать одну метрику по шаблону в куче необходимых разрезов.
Так же никто не запрещает публиковать JSON из тех же регистров мониторинга и забирать его zabbix web agentoм. Zabbix sender такой же пушер, для синхронной отправки событий. Важно не отвергать забикс, если есть некий централизованный мониторинг и хорошая служба эксплуатации, которая не забывает на алерты и действует по регламенту)

В целом конечно верное и правильное решение использование прометеуса вместо забикса для мониторинга сервера приложений. Респект.
59. freewms 147 23.09.19 10:51 Сейчас в теме
(58) Я уже писал выше и повторюсь - этот механизм не для наблюдения за сервером приложений 1С. За сервером наблюдает Zabbix, как и за остальным железом в сети, поскольку это проще.
Для этого есть, например: https://github.com/freewms/zabbix-1c-service-template


Прометей предназначен для наблюдения за состоянием именно данных внутри базы данных. Т.е. за бизнес-процессами непосредственно.
60. freewms 147 23.09.19 13:31 Сейчас в теме
(58) В продолжении - сделать в 1С JSON никто не мешает, но давайте представим, что нам нужно что бы собрать данные для отображения, скажем, статистики заказов к отгрузку:
1) В 1С - Создать регламент, который будет опрашивать данные и формировать JSON
2) В 1С - Куда-то положить сформированный JSON,
3) ЛИБО в 1С ЛИБО в Zabbix Agent настроить отправку. Не забыв о том, что 1С может несколько серверов приложений.
4) Самый ад: открыть Заббикс и настроить калькулируемые метрики (для каждого из разрезов аналитики), а так же при условвии, что новые данные (скажем, новый контрагент) заводятся в 1С, каждый раз при появлении нового элемента в разрезах аналитики - идти и донастраивать Заббикс.

Вот это вот всё и делает невозможным использования Заббикса для обработки данных. Слишком высокая трудоемкость обслуживания.
61. freewms 147 23.09.19 13:32 Сейчас в теме
(58) И из практики: Вы каждого 1С-программиста сможете научить работать с Заббиксом? Оно Вам надо? А метрики в Прометея у нас кидает каждый программист )))))
62. ilijaz 23.09.19 15:10 Сейчас в теме
>идти и донастраивать Заббикс.
Нет, этого не нужно, если использовать правила обнаружения, по которым метрики создаются из шаблона с нужным ключом для разреза.

>И из практики: Вы каждого 1С-программиста сможете научить работать с Заббиксом? Оно Вам надо? А метрики в Прометея у нас кидает каждый программист )))))
Ни в коем случае ни говорю, что нужно использовать заббикс. Ваше решение и использование прометеоуса как инструмента верное и наиболее гибкое. Хочу лишь донести, что ваши мысли об ограничениях забикса не свосем корректны.
63. freewms 147 23.09.19 21:21 Сейчас в теме
(62)
Нет, этого не нужно, если использовать правила обнаружения, по которым метрики создаются из шаблона с нужным ключом для разреза.

Насколько часто Вы планируете их запускать?


(62)
Хочу лишь донести, что ваши мысли об ограничениях забикса не свосем корректны.


Судя по Вашему отзыву, я, к сожалению, не смог донести корректно свои мысли касательно Заббикса.
Это шикарная система, с богатейшим функционалом и потрясающими возможностями (За исключением танцев с бубном вокруг Housekeeper'а и усекновения базы при больших нагрузках).

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


P.S. Вы очень интересный собеседник, с удовольствием бы продолжил общение в личке.
64. ilijaz 26.09.19 22:40 Сейчас в теме
(63)
Насколько часто Вы планируете их запускать?


А это зависит от необходимости и "тяжелости" процедуры (скрипта) обнаружения.


(63)
усекновения базы при больших нагрузках).


Да, часто мы хайлоад сами себе на ровном месте делаем собирая очень часто ненужны метрики.


(63)
Вы очень интересный собеседник, с удовольствием бы продолжил общение в личке.


Я только за. Мало людей, которые серьезно относятся к мониторингу.
65. user1057086 07.11.19 14:38 Сейчас в теме
Спасибо большое за конфигурацию! вопрос вот в чем! Есть мануал по настройке связей, путей и т.д. между 1с и Prometeuse. Спасибо!
66. freewms 147 07.11.19 18:16 Сейчас в теме
Пишите в личку - решим. Мануал how to не делал. Вкратце:
1) опубликовать http- сервис из 1С
2) настроить его как цель в prometheus.yml

Главный нюанс с которым я столкнулся - это то, что отступы пробелами в prometheus.yml имеют значение.
67. user1057086 23.12.19 17:43 Сейчас в теме
(66)"Вариант PUSH:

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

ИЛИ

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



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

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

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

1. Приветствую! Подскажи пожалуйста, Настройки конфигурации, где искать эти константы, где прописывать?

2. Правильно ли я настроил отправку по пушу (фото приклеплено)

Спасибо
Прикрепленные файлы:
69. freewms 147 24.12.19 12:47 Сейчас в теме
(67)
Разделитель целой и дробной части - поставьте "точка" - так будет соответствовать стандарту JSON.

Уточнение - для использования PUSH должен быть поднят prometheus pushgateway. Он обычно на порту 9091 висит. Нет ли у вас в этом ошибки?
Покажите скрины со страниц:
http://192.168.0.61:9091
http://192.168.0.61:9090/targets

З.Ы.
В целом - в следующей версии планируется исклбючение механизма PUSH. Сейчас над этим работаю.
70. user1057086 24.12.19 16:51 Сейчас в теме
(69) Push поднят, в место 9091 стоит 9100, http://192.168.0.51:9100/metrics , http://192.168.0.51:9090/targets, http://192.168.0.51:9090/config
Мы хотим использовать именно push , т.к у нас не установлен серверный модуль 1с, а установить его в данный момент проблематично, и наши сис админы на отрез отказываются.
Если в послейдующем релизе push запросов к прометею не будет, как тогда можно передавать метрики из 1с (каким еще альтернативным способом).
Спасибо!
Прикрепленные файлы:
71. пользователь 24.12.19 17:48
Сообщение было скрыто модератором.
...
72. freewms 147 25.12.19 10:06 Сейчас в теме
(71)
Метрики с push на файловой базе будут отправляться только если запущен хотя бы один клиент. Расскажите, как вы планируете применять метод "по необходимости". Я не очень понимаю цели. Без этого трудно что-то советовать.
73. user1057086 25.12.19 11:31 Сейчас в теме
(72)Добрый день, Что значит "запущен один клиент", по поводу использовать "по необходимости" я не верно выразился, у нас задача в следующем, наши менеджеры хотят проводить аналитику продаж и т.д., нужно чтобы из 1с подавались данные о продажах за месяц, например, запрос написать не проблема, вычленить от туда две метрики как я понимаю (документ реализации, и дата), потом это нужно отправить в промитей, и соответственно подхватить метрики Графаной. В целом моя задача и она же проблема, передать в прометей метрики из 1с. Код как я понял 100% рабочий, значит проблема в настройках, а как правильно настроить связь я не пойму. и еще один нюанс, у нас установлена БП2.0, а код написан для управляемых форм, я в ручную перенес код из вашей конфигурации в нашу, вроде учел все связи и настройки , это может быть причиной , что данные не отдаются в прометей.
Спасибо!
74. freewms 147 25.12.19 17:11 Сейчас в теме
(73)
Добрый день, Что значит "запущен один клиент"

В файловой базе регламенты выполняются при запущенном клиенте. Отправка методом PUSH - это регламентная операция.

(73)
нужно чтобы из 1с подавались данные о продажах за месяц,

Для этого есть отчеты. Мне кажется, Вы не совсем верно понимаете назначение метрик.
Я в статье писал об особенностях сбора метрик:
Узким местом является сбор и наглядное представление данных для принятия управленческих решений и при контроле за исполнением задач в силу высокой динамики изменения входных данных.

Это оперативно меняющиеся данные, снимаемые без погружения "в историю". Метрика штатно по регламенту отрабатывает раз в 10 секунд (насколько помню).

Насколько я Вас понял - вы хотите тягать метриками данные за значительные периоды (месяц). Вы получите итоговую величину за период (месяц), записанную в прометей на дату снятия метрики. Не могу понять как Вы хотите применить это в анализе.
75. user1057086 26.12.19 09:54 Сейчас в теме
(74)
Это оперативно меняющиеся данные, снимаемые без погружения "в историю". Метрика штатно по регламенту отрабатывает раз в 10 секунд (насколько помню).

Доброе утро! Напиши пожалуйста, тогда в каких случаях используют метрики из 1с в прометей, какие данные туда реально и актуально отдавать, если не данные за долгий период, как мы хотим. Мне нужно для руководителя проектов дать внятное объяснение, стоит ли двигатся в данном направлении или допиливать графический отчет из 1с.
[P.S]
Конфигурация написана, работает и создавалась явно для определенных задач, у меня получается сейчас нет понимания, что и в каких случаях мы можем передавать средствами 1с в Промитей.

Спасибо!
76. freewms 147 26.12.19 10:33 Сейчас в теме
(75)
тро! Напиши пожалуйста, тогда в каких случаях используют метрики из 1с в прометей, какие данные туда реально и актуально отдавать, если не данные за долгий период, как мы хотим. Мне нужно для руководителя проектов дать внятное объяснение, стоит ли двигатся в данном направлении или допиливать графический отчет из 1с.
[P.S]
Конфигурация написана, работает и создавалась явно д


Давайте рассмотрим, например, анализ загруженности склада по зонам. Условно - есть 20-30 зон. Есть регистр, в котором можно снимать остатки по зонам.
Предложенный механизм и снимает остатки раз в 30 секунд текущий остаткок. Средствами графаны уже делается построение графиков за период, например.
Т.е. схема работы - мониторинг.
77. user1057086 26.12.19 17:26 Сейчас в теме
(76) Добрый вечер! Я так понимаю метрики берутся из справочника, или же необходимо регистр создавать, и как тогда подавать данные метрик.
По поводу настроек, там все верно?
Прикрепленные файлы:
68. пользователь 24.12.19 12:44
Сообщение было скрыто модератором.
...
78. untru 13 25.12.22 11:42 Сейчас в теме
Добрый день, сейчас хочу реализовать dashboard и не очень понимаю такой момент. У меня сейчас есть два варианта:
1) Grafana + simple json
2) Prometheus + Grafana
Вы пишите:
"При обновлении дашбордов с метриками раз в 10 секунд (ибо отказы железа по-прежнему хочется видеть оперативно), начала проседать база 1С."
Я верно понимаю что все упирается в то, что частота обновления панелей задается для всего дашборда, а не только метрик 1с?
Пробовали ли вы организовать похожий принцип работы: регистр с метриками и grafana берет из нее а не строит тяжёлые запросы?
Я просто не могу до конца понять необходимость Prometheus
Просто из того что я видел, суть одна, есть сервис который возвращает данные из 1с, и я не до конца понимаю, какая разница, кто берет, grafana или Prometheus.
79. untru 13 26.12.22 08:54 Сейчас в теме
Чуть меняю свой вопрос, у вас на графике например есть количество операций за последний час, я вот не очень понимаю какую цифру мы должны в прометей отдавать, дельту между запросами в те же 30 секунд? Или час это как бы лейбл метрики?
Оставьте свое сообщение