Введение

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

У инженеров эксплуатации для наблюдения есть следующие источники данных:

  • Журнал регистрации 1С (оф.описание) - встроенный механизм регистрации событий в базе 1С в нотации метаданных 1С (объектов и действий пользователей в том числе служебных). Реализован как отдельное хранилище, расположенное на сервере 1С в виде текстовых файлах с внутренним форматом или базой SQL Lite.

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

  • Windows утилита администрирования кластеров (оф.описание) - приложение 1С для просмотра текущего состава и настроек кластера 1С, Информационных баз, рабочих серверов, сеансов и соединений.

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

К сожалению, из коробки не один из перечисленных инструментов нельзя уложить в привычные системы наблюдения (zabbix, prometheus, clickhouse, ELK и другие).

А задача такая стоит, поэтому решаем ее :). Для начала посмотрим, что мешает в ее реализации (в скобках напишу, что удалось нивелировать):

Журнал регистрации 1С

Ограничения:

  • При большом объеме данных пользоваться штатным механизмом просмотра событий нереально, особенно, применяя отборы для поиска информации (решено);

  • Отсутствует возможность агрегации данных (решено);

  • Хранение во внутреннем формате, что дает определенные сложности в парсинге журнала для перекладки в другую систему (решено);

  • С выходом новых версий платформы 1С, формат и набор атрибутов может измениться (решено);

  • Нет автоматической ротации журнала (рано или поздно файлы забьют весь диск) (решено).

  • Невозможно обратиться к сущностям (журнал хранит только тип сущности и ее идентификатор) (решено)

Возможности:

  • Выгружать в таблицу или файл журнал событий порциями на встроенном языке 1С;

  • Сокращать журнал на встроенном языке.

Технологический журнал

Ограничения:

  • Много “шума” в событиях, сложно настроить конфигурационный файл, чтобы исключить совсем служебные несущественные записи от значимых (не решено);

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

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

  • События фиксируются после их окончания. Например, если блокировка началась в 10:00:00, а объект был заблокирован только через 15 секунд (ожидание блокировки), то событие будет датировано 10:00:15 с указанной продолжительностью в 15000 миллисекунд (не решено, но учтено). 

Возможности:

  • Отбор регистрируемых события с помощью конфигурационного файла;

  • Ротация журнала (настраивается пользователем в конфигурационном файле).

Windows утилита администрирования кластеров

Ограничения:

  • Только Windows (решено);

  • Нет хранения статистики. Отражается только текущее состояние (решено);

  • Нет возможности отбора и поиска (решено частично);

  • При наличии боле 300-500 сеансов начинает заметно подтормаживать при обновлении (решено);

  • Представление данных в байтах и секундах (решено).

Возможности:

  • Просмотр текущей ситуации.

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

Решение

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

Мы отказались от автоматического парсинга технологического журнала, оставив его на ручное включение и анализ файлов с помощью GREP, в случае падения производительности или непонятного поведения платформы 1С.

А вот с журналом регистрации и со сбором метрик с кластеров 1С решили построить следующую схему, взяв решение здесь:

где,

ClickHouse - хранит записи журнала регистрации.

Prometheus - хранит значения метрик, собранных с кластеров 1С. 

Grafana - визуализирует данные с Prometheus и ClickHouse.

Оркестратор 1С: 

  • Периодически опрашивает кластера 1С с помощью RAS и предоставляет данные Prometheus по его http запросу;

  • Получает журнал регистрации, выгруженный с каждой наблюдаемой базы 1С, парсит его и укладывает в ClickHouse;

  • Позволяет строить агрегированный отчет по данным журналов регистрации, сохраненным в ClickHouse;

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

В каждую наблюдаемую базу встраивается дополнительная конфигурация “Оснастка”, которая:

  • В фоновом режиме нативно выгружает порцию данных из журнала регистрации и передает их в оркестратор для дальнейшего помещения в ClickHouse;

  • Осуществляет ротацию записей журнала регистрации 1С.

В итоге

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

  1. Возможность быстрого поиска и анализа данных из журнала регистрации (это ж ClickHouse);

  2. Ротация записей журналов регистрации (нет риска, что диск забьется логами);

  3. Визуализация значений метрик систем 1С, с возможностью ретроспективного анализа (Grafana + Prometheus);

  4. Возможность построения отчета агрегированных данных журналов регистрации;

  5. Возможность просмотра текущих значений объектов кластера 1С в читаемом виде.

Комментарии (4)


  1. svk28
    02.10.2023 11:40

    Мы у себя реализовали автоматический парсер журналов в виде службы, которая обрабатывает данные и шлет в кластер elasticsearch (opensearch) или в csv (json) файлы. Есть фильтрация по событиям (какие события не слать). Отчеты уже из эластика через кибану или графану.


    1. dd_kruglov Автор
      02.10.2023 11:40

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

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


  1. Dr_Wut
    02.10.2023 11:40

    Скажите пожалуйста, а вы какие бизнес-задачи решаете этим инструментом?


    1. dd_kruglov Автор
      02.10.2023 11:40
      +1

      То что на поверхности:

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

      2. Выявление неоптимальных алгоритмов, выкаченных при обновлении, но не являющихся ошибкой (сказывается на общей производительности), например из реальных кейсов:

        • Подтормаживание одного из методов API из-за кратного увеличения количества транзакций-записи в регистр сведений, по факту просто постоянно перезаписывались одни и те же данные.

        • Значительный объема передачи данных между сервером 1С и СУБД, при этом объем данных переданных между клиентом и СУБД не увеличивался: причина - неоптимальные настройки одного из отчетов СКД.

      3. Выявление падений платформы (крах rphost) и сопоставление событий предшествующее этим падениям, повышение стабильности работы системы.

      4. Быстрый поиск событий в логах, например кто поменял тот или иной документ.

      5. Мониторинг ошибок, особенно в служебных сеансах (в фоновых заданиях и http-сервисах), с точки зрения бизнеса - раньше узнаем о проблемах, а не когда партнер скажет (если скажет), что функционал недоступен.

      6. Так же на основании агрегированных данных можно понимать объем бизнес-транзакций, например количество созданных заказов покупателей, как показатель активности интернет покупателей, не на этапе "положили в корзину", а на этапе, что весь бизнес-процесс отработал.

      Думаю, что список можно дополнять и дополнять :)