Введение
Около года назад мы пришли к выводу, что работа с журналом регистрации в текущем виде, как это предлагает 1С, особенно для наших HighLoad систем, невозможен. Логи за день только по одной ИС занимали около 300 Гб, это делало нереальным поиск истории действий пользователей. Такие действия – мука для администраторов. Они делали отбор, ждали несколько часов, понимали, что отбор был неверен и повторяли действие.
После этого мы реализовали выгрузку журнала регистрации в ClickHouse с помощью Vector, это позволило хранить довольно большую глубину данных, так как ClickHouse неплохо сжимает данные (данные в ClickHouse занимают в 8 раз меньше места чем в обычных файлах лога) и вторым преимуществом стало то, что отбор данных стал происходить существенно быстрее. Для примера, отбор по LIKE по нескольким миллиардам строк происходил за 30 сек. Еще одним неочевидным плюсом стала возможность просматривать логи разных ИС в одном месте – это может быть полезно для распределенных ИС. Наконец, мы получили хорошую аналитику по числу ошибок, интенсивности транзакций и контекст фоновых заданий.
Событие
Начиная с 25-й версии платформы 1С у утилиты автономного сервера ibcmd появилась возможность работы с журналом регистрации, а именно команда экспорта журнала в форматы xml и json.
Предусмотрен режим ожидания новых событий журнала регистрации – в этом режиме новые события будут дописываться в файл или консоль в реальном времени. Ссылка на заметки из зазеркалья.
Исходя из этого события мы решили сравнить, что лучше - используемое нами решение Vector или же утилита ibcmd.
Возможности ibcmd eventlog
Если вызвать справку по новому режиму работы утилиты ibcmd, мы получим следующее:
Исходя из данной справки мы имеем следующие возможности:
- Выгрузка данных в 2 форматах xml и json
- Поддержка выгрузки без учета корневых элементов json и xml – json line и xml line
- Выгрузка данных за необходимый период
- Отслеживание новых записей в ЖР
- Выгрузка данных в файл
Звучит неплохо, но, как всегда, дьявол кроется в деталях.
Возможности Vector
Vector – это высокопроизводительная платформа для управления потоками данных, разработанная компанией Timber. Она ориентирована на сбор, обработку и отправку логов, метрик и других потоков данных. Vector обеспечивает быструю, надежную и гибкую маршрутизацию данных для аналитики, мониторинга и обработки событий.
Vector помогает разработчикам и администраторам инфраструктуры централизованно собирать и обрабатывать данные, улучшая производительность и масштабируемость. Давайте рассмотрим основные функции и возможности этого инструмента.
В плане задач в рамках теста Vector (прочитать файл лога, разобрать и записать в json) позволяет:
- Отслеживать изменения файлов и мониторинг их добавления по маске
- Обработка нескольких каталогов для отслеживания изменений файлов
- Запоминает последние обработанные строки или файлы
- Настраиваемый алгоритм разбора файлов логов
- Настраиваемые схемы ротации выходного файла
- 10 форматов выходных файлов в т.ч. csv и protobuf
- Сжатие выходного файла
- Настраиваемые фильтры\условия по разобранным данным перед записью в целевой файл.
Функции вне зачета:
- Сбор данных (Sources):
- Vector поддерживает широкий спектр источников для сбора данных, включая файлы syslog, journald, Docker, Kubernetes, HTTP, Apache Kafka и многие другие;
- Можно интегрировать собственные источники данных, поддерживаются настраиваемые плагины для разнообразных протоколов и источников.
- Преобразование данных (Transforms):
- Приложение поддерживает трансформации для структурирования, нормализации и фильтрации данных на лету. Это позволяет изменять формат данных до их передачи в конечные точки (sinks);
- Vector позволяет удалять ненужные поля, а также применять фильтрацию по условиям и преобразовывать данные с помощью скриптов на языке Remap (Vector Remap Language, VRL);
- Возможность агрегации и агрегирование данных для их последующей отправки в определенное место.
- Отправка данных (Sinks):
- Vector поддерживает отправку данных в большое количество систем и сервисов, включая ElasticSearch, Amazon S3, Apache Kafka, Prometheus, ClickHouse, Splunk, Datadog, InfluxDB, AWS CloudWatch и другие;
- Можно настраивать несколько целевых точек отправки, делая Vector частью сложных ETL процессов.
- Высокая производительность:
- Vector разработан на Rust, что обеспечивает высокую производительность и надежность работы;
- Он способен обрабатывать миллионы событий в секунду с минимальными задержками, что делает его подходящим для высоконагруженных систем.
- Надежность и отказоустойчивость:
- Встроенные механизмы обеспечения целостности данных, такие как сохранение сообщений в случае сбоев сети, встроенное квотирование и регулирование нагрузки;
- Vector использует подход "отправить или потерпеть неудачу" (at-most-once или at-least-once), что гарантирует либо доставку данных, либо их полное восстановление.
- Конфигурируемость и управление конфигурацией:
- Vector имеет простой и понятный конфигурационный файл на языке TOML, который позволяет настроить все источники, трансформации и точки отправки;
- Также поддерживается динамическое обновление конфигурации и горячее применение изменений.
- Поддержка микросервисов и контейнеров:
- Vector легко интегрируется с Docker, Kubernetes и другими контейнерными системами, что делает его гибким для использования в микросервисной архитектуре;
- Поддерживает автоматическое определение служб и контейнеров, таких как Kubernetes Pods, что упрощает настройку потоков данных в динамических средах.
- Низкие требования к ресурсам:
- Vector разработан так, чтобы минимизировать потребление CPU и памяти, обеспечивая высокую пропускную способность при небольшом потреблении ресурсов;
- Подходит для использования на маломощных серверах и в облачных средах.
- Поддержка облачных решений:
- Vector может легко интегрироваться с сервисами AWS, GCP, Azure, и поддерживает множество функций, оптимизированных для облачных инфраструктур;
- Есть возможности для безопасной передачи данных, включая шифрование и интеграцию с системами управления доступом.
- Наблюдаемость и мониторинг:
- Vector генерирует собственные метрики, которые могут быть отправлены в мониторинговые системы (например, Prometheus), чтобы отслеживать его состояние и производительность;
- Vector имеет встроенную систему логирования и предоставления статистики о передаче и трансформации данных, что упрощает отладку и управление.
Тестирование выгрузки в json
Настройки тестирования
Для тестирования был взят лог одной из ИС за час размером 600 Мб.
Были выполнены следующие команды для трансформации лога с помощью ibcmd:
"C:\Program Files\1cv8\8.3.25.1072\bin\ibcmd.exe" eventlog export -f json --skip-root -o H:\tstExportJurnal1C\ibcmd\export.json H:\tstExportJurnal1C\base
Для Vector был сформирован следующий конфиг:
|
vector.yaml
|
Файл настройки трансформации transform.vrl
|
transform.vrl
|
Результат ibcmd
Утилита автономного сервера справилась с задачей разбора за 6 минут, при этом создав нагрузку в 10% CPU и 64 Мб RAM.
Стоит отметить, что утилита от 1С не просто распарсила файл лога lgp, а прочитала словарь из файла lgf и заменила все идентификаторы на читаемые представления и идентификаторы. Это конечно хорошо, но как побочный эффект мы получили дублирование данных в получившемся json-файле. Размер файла составил 4,01 ГБ
Пример файла:
|
export.json
|
Результат Vector
Vector справился с задачей разбора файла за 3 минуты, но использовал аж 42% CPU и 130 Мб RAM.
За счет того, что не пришлось идти в словарь lgf за представлениями идентификаторов, ibcmd дала фору Vector, но выходной json-файл получился меньше по весу – 1,88 Гб
|
export.json
|
Итоги тестирования
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Исходя из результатов тестирования можно сделать вывод, что утилита ibcmd более эффективно использует вычислительные ресурсы при преобразовании файла лога ЖР в json (при этом файл json максимально полный).
Итоги сравнения функционала
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
По функционалу Vector на голову выше ibcmd, но это не удивительно, так как у инструментов разные назначения.
Выводы
Чтобы сделать выводы, нужно определить, для какой цели вы хотите трансформировать логи журнала регистрации 1С в json.
В первую очередь это нужно для того, чтобы эти данные проанализировать, и тут будет два пути: если логов мало, то это можно сделать в самой 1С без каких либо трансформаций в json. Если же логов много, то логично это сделать в какой-то спец.системе. Это может быть ClickHouse, OpenSearch, Loki и т.п., и в таком случае полученные данные нужно будет еще чем-то отправить. Обычно для таких задачи используют FileBeat или Vector, и тут встает вопрос, а зачем тогда в этой цепочке ibcmd?
Как итог можно сказать, что функционал записи логов 1С в стандартных форматах логирования точно нужен, но реализация в отдельной утилите вызывает только вопросы.
Очень ждем настройку в базе 1С, которая позволяет выбирать формат, в котором 1С будет писать логи журнала регистрации.
