Магия преобразований: ЖР, ТЖ, RAS/RAC, логи - универсальное решение Vector

13.11.23

База данных - Журнал регистрации

Как легко и быстро с помощью специализированных решений собирать, парсить и передавать логи и метрики.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование SM По подписке [?] Купить один файл
Пример глобального файла конфигурации
.yaml 1,23Kb
5
5
1 SM
Скачать Купить за 1 850 руб.
Пример файла конфигурации для RAC process list
.yaml 6,52Kb
4
4
1 SM
Скачать Купить за 1 850 руб.

Предисловие

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

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

Но лично я не сторонник хранения огромных массивов данных в 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.

мониторинг парсинг Vector

См. также

Архивирование (backup) Журнал регистрации Поиск данных Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал регистрации изменений документов в 1С для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма «История изменений». Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

21600 руб.

15.05.2017    43108    12    24    

40

Журнал регистрации Мониторинг Системный администратор Программист Бизнес-аналитик Руководитель проекта Платформа 1С v8.3 Платные (руб)

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

9000 руб.

28.08.2019    32265    18    21    

70

Журнал регистрации Системный администратор Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Конфигурация LogiCH эффективно решает проблему хранения и анализа записей журналов регистрации. Разработка использует столбцовую СУБД ClickHouse, одну из самых быстрых Big Data OLAP СУБД. Любой анализ журнала можно выполнить в одном отчете, в котором доступны все возможности СКД с учетом ограничений RLS. Количество подключаемых баз не ограничено и не влияет на скорость построения анализа.

5000 руб.

28.11.2018    20087    14    6    

37

Мониторинг Инструменты администратора БД Системный администратор Платформа 1С v8.3 Россия Платные (руб)

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

1500 руб.

01.12.2020    15151    38    0    

55

Мониторинг Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

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

1 стартмани

13.06.2024    4126    21    Garilia    3    

33

Мониторинг Системный администратор Бесплатно (free)

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

24.05.2024    3497    AdepTcs    2    

19
Оставьте свое сообщение