Мониторинг и логирование 1С систем

Введение

Практически в каждой организации присутствуют информационные системы, реализованные на платформе 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 миллисекунд (не решено, но учтено решено). 

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

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

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

Особенности, которые надо учитывать при разборе:

1. Некторые имена атрибутов, содержат в имени ":", например: t:clientID, t:applicationName;

2. Есть вероятность повторения имен атрибутов в одном событии, пример "processName";

3. Значения атрибутов могут быть как без кавычек, так в одинарных кавычках, так и в двойных.

4. При наличии символа кавычек эквивалентному тому, что в начале и конце значения, они будут экранированы такими же символами, а именно:

   ..., Locks='InfoRg171.DIMS Exclusive Fld172="63837423165527" Fld173="020B6D891A8F1D292DB50579B8A4DDA8"',...

   или

   ..., Locks="InfoRg171.DIMS Exclusive Fld172='63837423165527' Fld173='020B6D891A8F1D292DB50579B8A4DDA8'",...

   или

   ..., Locks="InfoRg171.DIMS Exclusive Fld172="""63837423165527""" Fld173='020B6D891A8F1D292DB50579B8A4DDA8'",...

   или

   ..., Locks='InfoRg171.DIMS Exclusive Fld172="63837423165527" Fld173='''020B6D891A8F1D292DB50579B8A4DDA8'''',...

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

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

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

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

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

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

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

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

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

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

Решение

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

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

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