Разбор технологического журнала без боли и страданий

Критерии выбора

Когда я подошел к задаче разбора технологического журнала, я выделил для себя рад критериев:

• Масштабируемость
  Количество логов растет с ростом базы, а значит должен быть довольно гибкий механизм масштабирования разбора логов

• Отказоустойчивость

• Гибкость
  Хочется иметь возможность без боли и страданий добавлять или изменять текущие механизмы экспорта журнала.

• Скорость работы
  В ситуации, когда объем генерируемых логов в час со всеми ограничениями достигает десятков гигабайт - скорость обработки этих логов становится критичным фактором.

Проблемы существующих решений

Дак что же использовать для решения подобных проблем? На самом деле - решений на ИС масса. и Bash-скрипты, и экспортеры всех мастей на всех возможных языках, и тд и тп. Зачем нужен свой велосипед?

• Почти ни одно из этих решений не позволяло использовать в качестве хранилища разобранного Clickhouse
  Экономия места, а так же скорость его работы - делают его практически незаменимым в задаче хранения логов.
• Те же, что давали такую возможность не подходили для дальнейшего развития т.к. там использовался совсем "не мой" стек технологий.

Vector

В итоге в качестве экспортера был выбран Vector Это продукт с открытым исходным кодом и большим зоопарком возможностей для обработки логов. в чем плюсы этого решения:

• Скорость
  Написанный на Rust вектор перемалывает логи в невероятных объемах
• Стабильность.
• Гибкость настройки
  ТЖ - мягко скажем не самая удобная для разбора конструкция... Вектор позволяет аккуратно работать с ним фильтруя ложные срабатывания
• Масштабируемость
  При необходимости обработка ТЖ может вестись в несколько потоков
• Удобство настройки и использования
  Экспортер может легко работать как в Windows, так и в linux средах, а так же очень удобно и комфортно разворачивается в Docker-контейнере
• Количество вариантов хранилища для логов
  Вектор имеет уже описанные коннекторы с Clickhouse, Elasticserch, а так же еще с 3мя десятками популярных хранилищ.

Инструкция по установке

Проще всего использовать решение в Docker-контейнере

1. Скачиваем архив
2. Создаем таблицы в Clickhouse при помощи скриптов из папки sql-scripts
3. Переименовываем файлы Docker-compose.yaml.example и TechJournal.env.examle убирая ".example"
4. Заполняем настройки подключения к базе и фильтр событий в файле techJournal.env
   
5. В файле docker-compose указываете путь к папке с логами
6. и все. docker-compose up -d и вы собираете логи ТЖ в базу clickhouse

Инструкция для работы в windows

1. Установите Vector c официального сайта.
2. Скачиваем архив для Windows
3. Создаем таблицы в Clickhouse при помощи скриптов из папки sql-scripts
4. В файле executor.cmd задаем настройки сборщика
5. запускаем executor.cmd

Структура проекта

Все довольно просто:

•  Весь конфиг находится в папке ./config
• В папке transforms хранятся отдельные обработчики для каждого из событий, они так и называются
  
• Для того чтобы изменить процедуру анализа события, достаточно отредактировать файл с соответствующей трансформацией.
• Для того чтобы добавить событие к обработке необходимо изменить конфигурационный файл добавив туда область с обработкой конкретного события, а так же создать обработчик в папке transforms

Что работает из коробки

• Анализ исключительных ситуаций EXCP, QERR и EXCPCNTX
• Анализ ожиданий на управляемых блокировках
• Анализ событий SDBL и DBMSSQL

Что в планах на ближайшее будущее

• Уже сейчас тестируется разбор Call и Scall
• Далее в планах обработка событий реструктуризации базы данных(Restructuring, workflow, analysis)
• Далее Утечки памяти.
• Остальные события будут добавляться по требованию(потребности)
• Создание механизмов мониторинга и анализа ТЖ(дашборды, графики предсоставленные запросы)
• Реализация расширения для 1с, с традиционным анализом ТЖ, но с использованием в качестве источника данных clickhouse
• Проработка механизма устаревания данных в базе clickhouse

В заключении

Мне кажется, что это один из самых гибких и эффективных вариантов анализа ТЖ, которые есть в наличии.
Проект подходит для промышленного использования. У этого проекта полностью открытый исходный код, так что есть простор для кастомизации. 

Тестировалось на платформе 8.3.20.2180

Проект доступен на github
Буду рад помощи и указанию на неточности обработки

UPDATE 16.12

1. Добавилась обработка и сбор событий call и Scall, теперь можно вытаскивать самые долгие вызовы.
2. Исправление минорных дефектов