Предисловие

На написании данной статьи и более глубокого погружения в материал меня сподвигла моя текущая профессиональная деятельность и несколько статей, связанных с парсингом:

• Разбор технологического журнала без боли и страданий
• Выгрузка журнала регистрации 1С в ClickHouse с помощью Vector
• Инструменты экспорта журнала регистрации 1С в ClickHouse/ElasticSearch

В данной статье я детально рассмотрю пример реализации мониторинга производительности кластера 1С (своё видение разбора технологического журнала и журнала регистрации опубликую отдельными статьями, подписывайтесь, если понравится) и сделаю акцент на деталях работы конкретного решения.
По мониторингу производительности кластера есть несколько статей:

• Мониторим производительность с помощью 1С RAS
• Мониторим доступную производительность рабочих процессов в реальном времени
• Мониторинг доступной производительности рабочих процессов кластера 1С:8.3

Но лично я не сторонник хранения огромных массивов данных в 1С (так например реализовано в 1С:ЦКК).

Выбор инструмента

Инструментов для сбора, парсинга и доставки логов много, к примеру – Logstash, Filebeat, Fluentd, Fluent-bit, Vector и т.д. По совокупности факторов лично я отдал предпочтение Vector. Он написан на Rust, чрезвычайно быстрый, лёгкий к изучению и применению. Для погружения в выбор решения и детали работы можно посмотреть видео «Logstash или Vector // Курс "Observability: мониторинг, логирование, трейсинг"», так же там в 1:28:19 есть сравнение производительности разных популярных решений.

Архитектура (идеология) Vector поддерживает работу одновременно с двумя моделями данных – журналы и метрики (с возможностью конвертации из одной в другую). Модель конвейера Vector основана на компонентах ориентированных ациклических графов, содержащих независимые подграфы. События должны двигаться в одном направлении, от источников к приемникам, и не могут создавать циклы. Каждый компонент может создавать ноль или более событий.

Всего три вида компонентов – Sources, Transforms и Sinks (на момент написания статьи была заявлена поддержка 40 видов источников, 13 видов трансформации и 52 вида вывода). Наглядная инфографика с сайта продукта:

Для особо сложных случаев в блоке трансформации есть тип «Lua», который позволяет писать процедуры и функции на одноимённом языке программирования.

Vector представляет из себя одиночный бинарный файл, не требующий установки (поддерживаются все современные ОС). Для *nix систем только одна зависимость libc. Поддерживается работа в качестве службы в Windows или демона в Linux.

Возможны разные сценарии использования – распределённое, централизованное, на основе потока, но лучше это изучить непосредственно на оригинальном сайте, документация и описание там отличные (особое внимание советую уделить тонкостям – высокой доступности, буферам, «обратному давлению», работе с «секретами» и т.д.).

Конвейер Vector определяется с помощью файла (или файлов) конфигурации в одном из форматов YAML, TOML или JSON. В своей работе я остановился на YAML. Основные параметры работы задаются или в командной строке, или с помощью переменных среды (можно динамически изменять в процессе работы). Vector поддерживает изменение конвейера (горячую перезагрузку для применения любых изменений конфигурации) в режиме реального времени без перезапуска процесса. Так же есть поддержка API, который позволяет в режиме реального времени наблюдать за работающим экземпляром Vector и управлять им.

Практическая часть

Рассмотрим «магию преобразований» на примере результатов вывода списка процессов утилитой администрирования платформы 1С:Предприятие RAC:

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

@Echo off
chcp 65001 > nul
set hr=%time:~0,2%
if "%hr:~0,1%" equ " " set hr=0%hr:~1,1%
set datetime=%date:~-4,4%%date:~-7,2%%date:~-10,2%_%hr%%time:~3,2%%time:~6,2%
"D:\vector\RAC\rac.exe" process list --cluster=192a69a6-dfe5-4b73-9b35-0ebb971d2c04 --cluster-user=[user] --cluster-pwd=[123] >> D:\vector\RAC\process_list\process_list_192a69a6-dfe5-4b73-9b35-0ebb971d2c04_%datetime%.txt

Примечание: D:\vector\RAC\rac.exe это ссылка, к примеру, на C:\Program Files\1cv8\8.3.23.1912\bin\rac.exe (что бы при обновлении платформы достаточно было изменить только ссылку, а не изменять код скрипта; ещё можно было реализовать это на переменных среды).
Хотя Vector сам умеет вызывать exec и забирать данные со стандартного потока вывода, но я посчитал эту архитектуру более безопасной и надёжной в использовании - запуск скрипта по расписанию легко реализуется в любой ОС с помощью штатного планировщика заданий.

Для себя я принял общую концепцию конфигурирования – основной файл (описывает все глобальны параметры и функции – каталог с данными для работы самого Vector, параметры API, внутренние логи и метрики, «секреты» и т.д.) и каталог с отдельными файлами под каждую задачу (RAC, журналы регистрации 1С, технологические журналы 1С, журналы работы транспорта RabbitMQ, журналы работы web-серверов и т.д.). Пример строки параметров запуска Vector:

vector.exe --log-format json --config D:\vector\RAC\global.yaml --config-yaml D:\vector\RAC\yaml\*

Рассмотрим по этапам сам процесс конвейера.

Первым этапом всегда идёт блок с видом Sources. Для нашего примера его тип – File. На данном этапе получается следующая внутренняя картина (отладочный вывод в формате JSON; правая часть строк message обрезана на скриншотах, она содержит многострочную строку до разделителя пустой строки):

Далее пойдут блоки с видом Transforms.

Добавим нужные нам поля маркировки с помощью типа преобразования Remap (при необходимости; может потребоваться, когда у нас несколько Sources, а модель преобразовании данных одна). В примере это добавленное поле «_timezone»:

Далее, с помощью следующего блока с аналогичным типом Remap, с помощью простого регулярного выражения разложим Message на части и удалим лишнее:

Вот так мы за два простых действия получили конечный результат преобразования, который с помощью следующего блока вида Sinks можно сразу отправить в точку хранения и анализа данных, к примеру, в ElasticSearch, ClickHouse, Socket или через http-сервис в 1С (выбор огромен).

Ну а если есть необходимость сразу отправлять в централизованную систему мониторинга, без посредников, к примеру, Prometheus? Да легко! Добавим ещё один блок Transforms с типом Log_to_metric (для примера я взял только 2 параметра – available_perfomance и memory_size, ключевое уникальное поле – process):

Превосходно! А если усложнить задачу, и в Prometheus отправлять только агрегированные данные по кластеру, без разреза по Process? Тогда, наверное, нужно на первом этапе рассматривать весь файл как одну строку лога. Но, а если нам нужно это делать в одной итерации, чтобы отправлять в разные получатели данных? Немного подумав, можно нестандартным подходом реализовать и это. Сделаем второе ответвление (отдельными блоками Transforms) с типами Log_to_metric и Aggregate:

Выполнить каких-либо преобразования с форматом данных Метрика нет возможности, поэтому сконвертируем данные метрик обратно в модель данных Журналы с помощью Metric_to_log и вычислим сумму (или среднее) по агрегированным значениям (с помощью отдельного блока Remap):

И заключительным блоком будет обратное преобразование (чисто техническое) из модели данных Журналы в модель данных Метрики:

Заключительный этап – отправка данных получателю. Блок с видом Sinks и для нашего примера с типом Prometheus_remote_write. Проверяем:

Бонус

Внимательные читатели, возможно, заметили имя «TestCluster1541» на скриншотах? Но откуда оно взялось? В первом блоке «маркировки» (где добавляли часовой пояс) мы не маркировали таким образом события. Ответ простой – Vector поддерживает «таблицы обогащения», при чём они индексируются и не оказывают какого-либо существенного влияния на производительность:

К статье прикладываю примеры (шаблоны) – основной конфигурационный файл и файл для process list.