Метрики, графики, статистика = Prometheus + Grafana
Администрирование - Мониторинг
Часть первая, художественная.
Вступление
История решения проблемы, с которой ежедневно сталкивается разработчик 1С при решении прикладных задач, связанных с оперативным учетом на предприятии.
Для начала определимся с тем, что такое оперативный учет. Оперативный учет, проще говоря, это когда решения на основе предоставляемых системой данных принимаются здесь и сейчас. Где нет "пометить на удаление" и "отменить проведение". Где вся структура учета строится исключительно из потребностей бизнеса без учета ПБУ, НК и проч-проч-проч.
Такие решения не очень популярны на сегодняшних день на платформе 1С, но тем не менее, потихоньку набирают обороты и, надеюсь, будут только шириться.
Самый простой пример оперативного учета - это складская деятельность при достаточно высоком уровне автоматизации склада. Высоким уровнем автоматизации давайте договоримся считать способность системы принимать решения и отдавать задачи исполнителям в режиме on-line. Подобный подход продемонстрирован компанией Axelot в конфигурации 1С:WMS Логистика. Управление складом.
В рамках разработки таких систем узким местом является сбор и наглядное представление данных для принятия управленческих решений и при контроле за исполнением задач в силу высокой динамики изменения входных данных.
Стандартные отчеты плохо подходят наличием кнопки "Сформировать" и весьма скромными графическими возможностями.
Разнообразные варианты форм с автообновлением по обработчикам ожиданий весьма прилично нагружают систему при мало-мальски существенном объеме выводимой информации.
Хочется чего-то легкого, красивого и понятного...
Завязка
К предлагаемому варианту решения проблемы подтолкнула, как не странно, квалификация инженеров на проекте. В рамках крупного проекта ежедневно приходится сталкиваться не только с проблемным поведением 1С, блокировками на СУБД, кривым кодом и нелепыми бизнес-процессами. Есть еще основа всего этого - локальная сеть с кучей оконечного оборудования. Начиная от свитчей и заканчивая терминалами сбора данных. А если копнуть еще глубже - то и у энергоснабжающих организаций бывают проблемы. И все это заканчивается банальным: "1С не работает".
В современных реалиях существует огромное множество систем мониторинга оборудования. Но у нас ее не было. И с нее пришлось начать. На первом этапе - завели Zabbix, начали собирать статистику со всего до чего смогли дотянуться. Потом потребовалось собирать данные с удаленных филиалов. И снова Zabbix, но расположенный на другом сервере и нам доступный только read-only. А потом возникло желание видеть данные единовременно с обоих серверов мониторинга. И тут на помощь пришла совершенно потрясающая платформа для мониторинга и аналитики - Grafana.
Лирическое отступление первое
Если вкатце - то Grafana это рендер всяческих метрик. А метрика это что? Это просто числовое значение чего-то с изменением во времени. Вот их-то, любимых, Grafana и выводит во всяких разных разрезах, формах и цветах. Платформа совершенно прекрасная, легко тюнингуемая, с кучей плагинов. За деталями отправлю на официальный сайт платформы. От себя отмечу, что на мой вкус - это одна из самых красивых и стильных систем графического представления информации. И, что примечательно, совершенно free!
После настройки системы мониторинга и выводом информации о жизненно важном аппаратном слое системы, жить на проекте стало несколько легче. Шишки перестали падать с такой частотой и с таких высот.
Однако решение проблем административного персонала было в зачаточном состоянии. Управление многоэтажным складом посредством отчетов и полубумажной технологией делало несчастными администраторов.
Попытки построения системы мониторинга процессов на внешних обработках делало несчастными разработчиков и сервер с СУБД.
А чувство прекрасного продолжало настойчиво требовать легкости и понятности.
Кульминация
По результатам созерцания аккуратных метрик в 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: Присоединяйтесь! Разработка обрела свой адрес
Infostart Dashboards — дашборды и метрики в 1С
Решение «Инфоборды» позволяет собрать все ключевые показатели и метрики прямо на главном экране 1С. Настраивайте панели с виджетами — выручка, долги, KPI, задачи, остатки и динамика продаж — всё в виде интерактивных дашбордов. Контролируйте эффективность компании в реальном времени без отчётов и сложных запросов.
Вступайте в нашу телеграмм-группу Инфостарт
графики оперативный учет управление ресурсами складской анализ
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Работа с интерфейсом Анализ учета Мониторинг 1С:Предприятие 8 1С 8.3 1C:Бухгалтерия 1С:Бухгалтерия 3.0 1С:ERP Управление предприятием 2 1С:Управление холдингом 1С:Зарплата и Управление Персоналом 3.x 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Управление торговлей 11 Платные (руб)
Создайте свой функциональный интерфейс в любой конфигурации 1С с помощью расширения Infostart Dashboard. Настраивайте панели виджетов с метриками, индикаторами и показателями на начальном экране. Узнайте возможность внедрения подсистемы у себя в конфигурации с помощью бесплатной обработки "Анализ внедрения подсистемы 1С Infostart Dashboard"!
31720 руб.
27.03.2025 92400 69 44
Журнал регистрации Мониторинг Системный администратор Разработчик 1С 8.3 Абонемент ($m)
Мониторинг журнала регистрации - расширение, которое визуализирует ошибки из журнала регистрации в разрезе приложений. Расширение позволит выявить всплеск ошибок, подсветит динамические обновления и покажет картину рабочего процесса.
1 стартмани
07.11.2026 479 3 mrcamomile 8
Мониторинг Сервера Системный администратор 1С 8.3 Бесплатно (free)
Шесть блоков технического отчёта по кластеру 1С: площадка, процессы, нагрузка, диск, копии, журналы за названный период — и открытые вопросы. Цифры из двух реальных прогонов на Windows Server 2019 (srvinfo 119 ГБ, 444 бэкапа и ни одного по нужной базе, висящий сеанс с лицензией). Что собирать, чего не делать, и где агент ошибся.
02.11.2026 365 netbka 1
Журнал регистрации Инструменты администратора БД Технологический журнал Мониторинг Системный администратор Разработчик 1С 8.3 1С 8.5 1С:Управление торговлей 11 Абонемент ($m)
Расширение для любой конфигурации на БСП: замеры, ошибки, задания, обмены, блокировки, диски, сеансы и техжурнал в одном окне, с уведомлениями в Telegram и на почту.
3 стартмани
19.10.2026 511 6 windsurf 0
Мониторинг Системный администратор Абонемент ($m)
Небольшая программа для рабочих мест и серверов: следит за выбранными службами Windows (сервер 1С, СУБД, УТМ, лицензии) и сама запускает их, если служба остановилась или зависла. Полная редакция вдобавок не даёт пользователям запускать программы не из списка разрешённых или из списка запрещённых.
1 стартмани
08.10.2026 458 4 IronCAT09 0
Мониторинг Обновление 1С Системный администратор Разработчик 1С 8.3 Бесплатно (free)
Отложенное обновление идёт третий день, штатная форма пишет "Выполнено: N из M", и непонятно, ждать или разбираться. Проверьте у себя: в БСП 3.1 почасовая история обработанных объектов, время завершения каждого обработчика, попытки и текст ошибки уже лежат в регистрах, не хватает только деления. Разобрал, где это хранится, как считать прогноз двумя скоростями (по объектам и по обработчикам) и как найти обработчик, который держит очередь, в том числе когда БСП записала ему "зацикливание", а держала его блокировка. Проверено на копии УТ 11.5 с 215 настоящими обработчиками типовой: очередь шла 4 часа, прогноз за 2 часа до конца ошибся на 5 минут. В конце обработка, которая отвечает одной строкой.
30.09.2026 900 nedomolkov.ivan 0
Мониторинг Обновление 1С Системный администратор Разработчик 1С 8.3 Абонемент ($m)
Внешняя обработка одной строкой говорит, идёт отложенное обновление или стоит, когда закончится и какой обработчик держит очередь. Скорость по почасовой истории БСП и по завершённым обработчикам, остаток по плану обмена обновления, виновник по регистру обработчиков и журналу регистрации. Выгрузка состояния в Markdown для нейросети. Только чтение. Нужен регистр "Обработчики обновления" из свежих версий БСП 3.1 (проверено на УТ 11.5.22).
10 стартмани
30.09.2026 555 0 nedomolkov.ivan 0
Мониторинг Системный администратор Разработчик 1С 8.3 Бесплатно (free)
Регламентное задание включено, расписание заполнено, ошибок в журнале регистрации нет, а данные не приходят. Проверьте у себя форму "Регламентные и фоновые операции": если в колонке результата пусто, это не значит, что всё хорошо, это значит, что задание не запускалось. Мы собрали стенд на копии рабочей УТ 11.5 и прошли все места, где задание застревает до своего кода: флаг блокировки на кластере, признак копии базы у БСП, пользователь в карточке задания, функциональная опция, расписание, которое не наступит. У каждого места код проверки. Самое неприятное подтвердилось на платформе 8.3.27: задание под пользователем, которого нет в базе, не оставляет в журнале регистрации ни одной строки. Плюс как по журналу отличить ручной запуск от запуска сервером и как увидеть задание, которое работает вхолостую.
30.09.2026 1071 nedomolkov.ivan 0
В дальнейшем предполагается обеспечить возможность считывания одной и той же метрики несколько раз до ее устаревания. Это необходимо, когда частота регламентного опроса Прометеем превышает частоту формирования "тяжелой" метрики.
У него есть понятие "Цель" - это те http-сервисы, которые он опрашивает с определенной периодичностью и забирает соскобы себе в базу.
В приложенном файле - настройка Прометея на 3 цели: сам себя - показатели статистики, PushGateway - для получения с него метрик из короткоживущих процессов (отправляемые в PushGateway методом PUSH) и база WMS, которая и является основным поставщиком данных.
в prometheus.yml добавить:
- job_name: 'test'
basic_auth:
username: 'Администратор'
password: ''
scrape_interval: 10s
metrics_path: '/test/hs/prometheus/polling'
static_configs:
- targets: ['localhost'] Показатьвроде разобрался
Пример из конфы в аттаче статьи:
код формирования статуса |
|---|
Функция PollingGet(Запрос)
UserAgent = Запрос.Заголовки.Получить("User-Agent");
Accept = Запрос.Заголовки.Получить("Accept");
Если UserAgent = Неопределено ИЛИ Accept = Неопределено Тогда
Возврат Новый HTTPСервисОтвет(400);
КонецЕсли;
Если (СтрНайти(Accept,"text/plain") = 0) Тогда
Возврат Новый HTTPСервисОтвет(405);
КонецЕсли;
УстановитьПривилегированныйРежим(Истина);
МетрикиСтрокой = prРасчетМетрикPrometheusСервер.ПолучитьМетрикиPULL();
УстановитьПривилегированныйРежим(Ложь);
Если НЕ ЗначениеЗаполнено(МетрикиСтрокой) Тогда
Возврат Новый HTTPСервисОтвет(418);
КонецЕсли;
Ответ = Новый HTTPСервисОтвет(200);
Ответ.УстановитьТелоИзСтроки(МетрикиСтрокой,КодировкаТекста.UTF8,ИспользованиеByteOrderMark.НеИспользовать);
Возврат Ответ;
КонецФункции
Показать |
- склад под управлением какой WMS?
Привет, а что не так с Заббиксом?
У меня с ним проблем не возникло, и Графана успешно начитывает данные с Забикса.
Решали не проблему связки Заббикс-Графана - там проблем нет за исключением Алертов, а проблему "Куда деть данные оперативного учета из 1С"
На мой взгляд Графана не совсем верное решение для таких целей, она для - цитата с офиц. сайта
В данном случае лучше подойдет PowerBI, который умеет не только представлять данные, но и крутить их в разные стороны.
Смотря что мы понимаем под оперативным учетом. Оперативный учет != отчеты о продажах за месяц. Оперативный учет на складе - это оценка изменения загруженности зон на горизонтах 30мин-1час, достаточности сотрудников по факту и распределение их по направлениям деятельности. И да, алерты по проблемным узлам тоже.
Это не аналитика. Это желание оперативно реагировать на возникающие проблемы по заранее выставленным контрольным точкам.
invalid is not a valid start tokenа по сути хочется только мониторить живучесть сервиса...
альтернатива писать прослойку - которая будет ретранслировать состояние сервиса? или есть еще варианты?
Попытки выливать данные в Zabbix и работать от него закончились порванным бубном и стесанной до кости сушеной заячьей лапкой.
Могли бы Вы написать подробнее - почему данный подход не получился. Это же "классический" подход по сбору метрик, и уже был описан на инфостарте.
И, хотелось бы больше слайдов и текста по проведения настроек связки продуктов друг с другом и самих метрик.
Прометей позволяет сделать сильно проще использование системы со стороны наполнения ее данными. При этом, система прозрачна для программистов и позволяет организовать передачу данных привычным кодом на привычном языке.
Уточнюсь - обобрать данные в 1С запросом, затолкать в Заббикс, получить там несколько разрезов будет выглядить так:
- Содаем кучу хостов по ожидаемым разрезам запроса
- Формируем, скажем, JSON силами 1С
- Кладем его куда-нибудь
- Пишем скрипт парсинга полученного файла
- Наталкиваем в Заббикс
- Сталкиваемся с проблемой вывода, скажем, в таблицу в Графане
Прометей + приложенная конфигурация - сводится к написанию запроса. Остальное происходит силами самого Прометея. При этом, со стороны Графаны поддерживаются запросы, которые позволят не определять заранее разрезы вывода.
Дополню:Это позволяет при складском учете работать "на переднем крае" данных. Т.е. держать в кеше СУБД их и, практически, не обращаться к диску.
Строить запросы, тем более глубокие - тяжело с точки зрения нагрузки на СУБД.
Да, он больше заточен под работу с сетевым и серверным оборудованием, что несет в себе лишний оверхед в настройках.
НО
Никто не запрещает вам сделать правило обнаружение и создать одну метрику по шаблону в куче необходимых разрезов.
Так же никто не запрещает публиковать JSON из тех же регистров мониторинга и забирать его zabbix web agentoм. Zabbix sender такой же пушер, для синхронной отправки событий. Важно не отвергать забикс, если есть некий централизованный мониторинг и хорошая служба эксплуатации, которая не забывает на алерты и действует по регламенту)
В целом конечно верное и правильное решение использование прометеуса вместо забикса для мониторинга сервера приложений. Респект.
Для этого есть, например:
Прометей предназначен для наблюдения за состоянием именно данных внутри базы данных. Т.е. за бизнес-процессами непосредственно.
1) В 1С - Создать регламент, который будет опрашивать данные и формировать JSON
2) В 1С - Куда-то положить сформированный JSON,
3) ЛИБО в 1С ЛИБО в Zabbix Agent настроить отправку. Не забыв о том, что 1С может несколько серверов приложений.
4) Самый ад: открыть Заббикс и настроить калькулируемые метрики (для каждого из разрезов аналитики), а так же при условвии, что новые данные (скажем, новый контрагент) заводятся в 1С, каждый раз при появлении нового элемента в разрезах аналитики - идти и донастраивать Заббикс.
Вот это вот всё и делает невозможным использования Заббикса для обработки данных. Слишком высокая трудоемкость обслуживания.
Нет, этого не нужно, если использовать правила обнаружения, по которым метрики создаются из шаблона с нужным ключом для разреза.
>И из практики: Вы каждого 1С-программиста сможете научить работать с Заббиксом? Оно Вам надо? А метрики в Прометея у нас кидает каждый программист )))))
Ни в коем случае ни говорю, что нужно использовать заббикс. Ваше решение и использование прометеоуса как инструмента верное и наиболее гибкое. Хочу лишь донести, что ваши мысли об ограничениях забикса не свосем корректны.
Насколько часто Вы планируете их запускать?
(62)
Судя по Вашему отзыву, я, к сожалению, не смог донести корректно свои мысли касательно Заббикса.
Это шикарная система, с богатейшим функционалом и потрясающими возможностями (За исключением танцев с бубном вокруг Housekeeper'а и усекновения базы при больших нагрузках).
Однако для частоменяющегося и заранее неопределенного набора аналитических разрезов она слабо подходит вследствие своей жесткой структуры.
P.S. Вы очень интересный собеседник, с удовольствием бы продолжил общение в личке.
А это зависит от необходимости и "тяжелости" процедуры (скрипта) обнаружения.
(63)
Да, часто мы хайлоад сами себе на ровном месте делаем собирая очень часто ненужны метрики.
(63)
Я только за. Мало людей, которые серьезно относятся к мониторингу.
1) опубликовать http- сервис из 1С
2) настроить его как цель в prometheus.yml
Главный нюанс с которым я столкнулся - это то, что отступы пробелами в prometheus.yml имеют значение.
По событию системы вызывается элемент справочника "Метрики" и выполняется его обработчик. По окончанию обработки метрики отправляются в Pushgateway.
ИЛИ
Подготовленная любым удобным способом таблица значений с данными передается входным параметром в экспортную процедуру, которая форматирует данные и отправляет их в Pushgateway.
Настройки конфигурации:
- Константа "URL Pushgateway": адрес сбора метрик службой Pushgateway
- Константа "Число повторных запросов метрики": количество раз, которое метрика будет отдана Prometheus при повторных обращениях. Каждое обновление метрики обнуляет счетчик. Используется для исключения провалов графиков в случае длительного формировании метрики и/или частого опроса Prometheus'ом"
1. Приветствую! Подскажи пожалуйста, Настройки конфигурации, где искать эти константы, где прописывать?
2. Правильно ли я настроил отправку по пушу (фото приклеплено)
Спасибо
Разделитель целой и дробной части - поставьте "точка" - так будет соответствовать стандарту JSON.
Уточнение - для использования PUSH должен быть поднят prometheus pushgateway. Он обычно на порту 9091 висит. Нет ли у вас в этом ошибки?
Покажите скрины со страниц:
З.Ы.
В целом - в следующей версии планируется исклбючение механизма PUSH. Сейчас над этим работаю.
Мы хотим использовать именно push , т.к у нас не установлен серверный модуль 1с, а установить его в данный момент проблематично, и наши сис админы на отрез отказываются.
Если в послейдующем релизе push запросов к прометею не будет, как тогда можно передавать метрики из 1с (каким еще альтернативным способом).
Спасибо!
Метрики с push на файловой базе будут отправляться только если запущен хотя бы один клиент. Расскажите, как вы планируете применять метод "по необходимости". Я не очень понимаю цели. Без этого трудно что-то советовать.
Спасибо!
В файловой базе регламенты выполняются при запущенном клиенте. Отправка методом PUSH - это регламентная операция.
(73)
Для этого есть отчеты. Мне кажется, Вы не совсем верно понимаете назначение метрик.
Я в статье писал об особенностях сбора метрик:
Это оперативно меняющиеся данные, снимаемые без погружения "в историю". Метрика штатно по регламенту отрабатывает раз в 10 секунд (насколько помню).
Насколько я Вас понял - вы хотите тягать метриками данные за значительные периоды (месяц). Вы получите итоговую величину за период (месяц), записанную в прометей на дату снятия метрики. Не могу понять как Вы хотите применить это в анализе.
Доброе утро! Напиши пожалуйста, тогда в каких случаях используют метрики из 1с в прометей, какие данные туда реально и актуально отдавать, если не данные за долгий период, как мы хотим. Мне нужно для руководителя проектов дать внятное объяснение, стоит ли двигатся в данном направлении или допиливать графический отчет из 1с.
[P.S]
Конфигурация написана, работает и создавалась явно для определенных задач, у меня получается сейчас нет понимания, что и в каких случаях мы можем передавать средствами 1с в Промитей.
Спасибо!
[P.S]
Конфигурация написана, работает и создавалась явно д
Давайте рассмотрим, например, анализ загруженности склада по зонам. Условно - есть 20-30 зон. Есть регистр, в котором можно снимать остатки по зонам.
Предложенный механизм и снимает остатки раз в 30 секунд текущий остаткок. Средствами графаны уже делается построение графиков за период, например.
Т.е. схема работы - мониторинг.
По поводу настроек, там все верно?
1) Grafana + simple json
2) Prometheus + Grafana
Вы пишите:
"При обновлении дашбордов с метриками раз в 10 секунд (ибо отказы железа по-прежнему хочется видеть оперативно), начала проседать база 1С."
Я верно понимаю что все упирается в то, что частота обновления панелей задается для всего дашборда, а не только метрик 1с?
Пробовали ли вы организовать похожий принцип работы: регистр с метриками и grafana берет из нее а не строит тяжёлые запросы?
Я просто не могу до конца понять необходимость Prometheus
Просто из того что я видел, суть одна, есть сервис который возвращает данные из 1с, и я не до конца понимаю, какая разница, кто берет, grafana или Prometheus.
Вариант PULL:
Регламентное задание конфигурации через равные промежутки времени запускает на выполнение все алгоритмы из справочника "Метрики" с типом pull не помеченные на удаление. Результат выполнения раскладывается в регистр сведений в текстовом формате, понятном Prometheus.
Вариант PULL:
Регламентное задание конфигурации через равные промежутки времени запускает на выполнение все алгоритмы из справочника "Метрики" с типом pull не помеченные на удаление. Результат выполнения раскладывается в регистр сведений в текстовом формате, понятном Prometheus.
От этого решения ушел еще в первых версиях. Сейчас расчет для метрик PULL происходит сразу по запросу Prometheus без промежуточного хранения. Извините за поздний ответ.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 811821
Создание 23.10.18 12:36
Обновление 24.02.19 21:59
Просмотры 57410
Загрузки 156
Рейтинг
161
Комментарии 84
Код открыт Да
Рубрики Мониторинг
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)