Введение
Практически в каждой организации присутствуют информационные системы, реализованные на платформе 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С.
В итоге
С помощью использования такой схемы мы решили следующие задачи:
Возможность быстрого поиска и анализа данных из журнала регистрации (это ж ClickHouse);
Ротация записей журналов регистрации (нет риска, что диск забьется логами);
Визуализация значений метрик систем 1С, с возможностью ретроспективного анализа (Grafana + Prometheus);
Возможность построения отчета агрегированных данных журналов регистрации;
Возможность просмотра текущих значений объектов кластера 1С в читаемом виде.
