BigData LogManager для 1С


#125

Это для актуальных версий платформы ) для тех, кто ещё не слез со старых, остаются боль, страдания и lgd.


#126

Дык всегда можно переключиться в старый формат. В чем проблема?


#127

Старый тупит, если б не тупил - данный топик не имел бы смысла


#128

В каком плане тупит? Старый вариант же как раз лучше работает по скорости записи.


#129

При чтении из него и поиске


#130

Новый тупит не меньше, при достаточном объеме.


#131

Вот поэтому и отрезаем выгруженные куски к чертям - они всё равно уже в ES.


#132

Добрый день!
Дошли руки до сбора логов, поставили graylog.
Решил сначала собрать записи ЖР из текстовых файлов через filebeat в graylog.
Пока смотрятся только файлы данных *.lgp с такими настройками в yml

 multiline.pattern: '^{\d{14}.+$'
 multiline.negate: true

События прилетают, но ни пользователя, ни метаданных, ни других полезных вещей не видно.

Как лучше сделать загрузку с определением значений массивов в 1Cv8.lgf? Pipeline видимо надо какой-то использовать, как его описать?
Может кто-нибудь поделиться наработками?
Спасибо


#133

#134

А там поддерживаются человекочитаемые имена метаданных и пользователи?


#135

Да, поддерживает вроде, вот его статья на ИС https://infostart.ru/public/182820/
Формат логов в старом формате описан, например, тут: https://infostart.ru/public/182061/
по сути эта его программа разбирает логи и кладет в mssql.
а мне хотелось бы реализовать разбор ми отправку на filebeat без дополнительных шлюзов.

мне очень понравилась идея “Старый журнал + filebeat -> es”


#136

Тут надо свой beat написать. Для разработки битов есть шаблон.
Я даже в какой-то момент начал эту задачу, но оно пока настолько концепт, что не публикую )


#137

Она не обязательно кладет в MSSQL, она умеет сразу в эластик отправлять


#138

Я не помню указывали или нет - пусть будет тут


#139

Только это ТЖ, но пусть будет тут


#140

У меня такая схема вышла: 1С ЖР => файлы, разбитые по дням => logstash => elasticsearch

Logstash’ем собираю ЖР из файлов с логами(lgp), фильтрую и загружаю в Elasticsearch, поиск и графики через Kibana. Из файла lgf составляю маппинг и отдаю его логсташу, чтобы была возможность видеть не только непонятные IDшники, но ещё и “human-readable” данные.
Сырых данных ЖР > 1ТБ. В эластике занимают места процентов на 20% меньше, благодаря сжатию.
Могу поделиться наработками, если кому интересно.


#141

Мне было бы очень интересно, особенно про маппинг


#142

А собственно файлы lgf каким образом парсятся?


#143

ktb
alex

Конфиги логстеша: https://github.com/ggerogery/logstash-1c-security-logs

А собственно файлы lgf каким образом парсятся?

“В лоб”, скриптом на баше, который в репе лежит - lgp-to-yml.sh. Он по крону парсит lgf в формат словарей для logstash’а(“KEY”: “VALUE”). Потом, главное, правильно расставить интервалы, чтобы за секунду до получения событий логстешем словари были обновлены. Рабочий конфиг логстеша - logstash/conf.d/raw_files_1.conf. Там есть фильтры translate:

translate {
field => “[UserId]”
destination => “[User]”
dictionary_path => “/etc/logstash/conf.d/custom_mapping_1C/DB_NAME_UserId.yml”
refresh_interval => 104
fallback => “Nothing to match!”
}

в этом примере он будет смотреть в поле UserId, увидит там, например, запись 1984, в словаре DB_NAME_UserId.yml посмотрит, что 1984 - это Петров_А_А, которого и поместит в User

raw_files_1.conf - там описан пайплайн, который смотрит в диру с сырыми логами конкретной БД 1С, каждое отдельное событие склеивает в одну строку(codec multiline) и прогоняет через все фильтры(mutate’ты -> grok -> translate), готовый результат складывает в эластик. Логи 1С неоднородные слишком, у меня вышло 6 разных GROK паттернов, которые покрывают все логи.


#144

Попробовал. Тестовая база разобралась хорошо, а рабочая нет. Все таки паттерны grok не подойдут под то что 1С сделала - у меня вылезло что в данных {P, {6 к примеру дополнительно 197 объектных полей. Предварительно получается неплохо, если я перед logstash файл прогоняю через рег-выражения, для приведения pattern.