BigData LogManager для 1С

Предположим у вас большие “Журналы регистрации” :wink:

Можно воспользоваться платной обработкой

А можно поступить по взрослому.

Начнем с начала - то есть с конца

у нас есть в 1С внешний источник данных
у Microsoft есть Хитрый ODBC драйвер

select count(distinct LogTimeStamp) from OneSAuditLog;

Здесь определенным образом возникает вопрос "Откуда берется табличка OneSAuditLog"
А вот тут начинается интересное

Для начала нам понадобится Hadoop

cd ~
wget http://mirror.metrocast.net/apache/hadoop/core/hadoop-2.2.0/hadoop-2.2.0.tar.gz
tar -zxvf ./hadoop-2.2.0.tar.gz
mv ~/hadoop-2.2.0 ~/hadoop

Затем HiVE

cd ~
wget http://apache.osuosl.org/hive/hive-0.12.0/hive-0.12.0-bin.tar.gz
tar -zxvf hive-0.12.0-bin.tar.gz
mv ~/hive-0.12.0-bin ~/hive

После этого еще веселей - плагин между HiVE(Hadoop) и ElasticsSearch

ADD JAR /home/lustin/hive/aux_lib/elasticsearch-hadoop-1.3.0.M1-yarn.jar;



CREATE EXTERNAL TABLE OneSAuditLog(
    title LogTimeStamp,
    redirect_page string )
STORED BY 'org.elasticsearch.hadoop.hive.ESStorageHandler'
TBLPROPERTIES('es.resource' = 'OneSAuditLog_river/page/_search?q=*',
              'es.host' = 'localhost',
              'es.port' = '9200');

И если теперь разобраться что такое “Речки” будет совсем хорошо :wink:
остается только обеспечить “речку” для наших журналов регистрации…

Но это сложно, а пока можно обойтись и простейшим
Тогда Вам дорогие друзья остается только написать скрипт который:

  1. будет разбирать и передавать текстовые журналы регистрации в index ElasticSearch
  2. с форматом SQLite вообще все проще Любая база может стать источником индекса
1 Симпатия

Как то тяжело hive ставить, не проще ли logstash + elasticsearch поставить? Маленькая работа напильника в виде своего плагина и

и получаем

3 Симпатий

Интересно и похоже действительно проще. Но насколько я почитал, внешним источником elastic search подключить не выйдет. Плюшки внешнего источника мне лично видятся как возможность сделать контекстную команду в базе 1с с переходом к истории объекта или сервисная конфигурация, в которой собран весь мониторинг и логи.

output может бьіть и в hadoop

Да - единственный способ подключить Elastic и базу журнала регистрации в качестве внешнего источника: это Hive. Тогда возможно сделать на 1С сервисную базу НЕ сохраняя в ней сами журналы.

Плюс в Production мы запускали rsync для журналов регистрации перегружая их с сервера 1С на сервера ElasticSearch.

Но то что сделал @pumbaE - это вообще круто: это получается почти RealTime мониторинг журналов регистрации.

Правильно ли я понимаю: имеется в виду замена речки + elasticsearch на logstash + плагин? А какова схема работы плагина? Триггер на таблице журнала или служба + пулинг?

1 Симпатия

logstash - переодический pull (раз в 5 сек), получает данные, сохраняет последний номер считаной строки журнала и потом select where id >n, преобразовывает согласно правилам и отправляет в elasticsearch, так же может дополнительно отправлять в hadoop.

kibana - это web морда для elasticsearch, временной лаг все равно есть, пока индекс построиться.

Так - специально для @JohnyDeath как обещал:

Итак начнем с проблемы:

  1. 1С база в production генерирует большой журнал регистрации - в тестовом формате, и в формате sqlite базы в новых версиях
  2. наличие большого количества таких журналов, приводит к двум проблемам и одной потенциональной *опе в перспективе:
    а. читать и просматривать такие журналы долго, даже с помощью внешних обработок
    б. для увеличения производительности 1С эксперты закончившие курсы делают следующее: периодически очищают старые файлы журналов регистрации, сокращают период с одного дня по умолчанию, до одного часа для каждого файла журнала, в production системах регистрируют только ошибки, отключая информацию и предупреждения. Кто поумней - еще журналы регистрации кладет на отдельный быстрый раздел, отличный от системного.

Из всего перечисленного правильными являются только 2 вещи - быстрый раздел и снижение периода записи Журнала до одного часа. Остальное НЕ верно и ведет к проблемам.

Правильным считается хранить журналы (логи) и относится к ним как к данным никогда их не удаляя. Правильным считается, что на основе журналов можно строить онлайн мониторинг и что самое крутое: прогнозные и аналитические модели.

Отсюда и возникает текущее решение:

  1. на production серверах 1С журналы регистрации НЕ хранятся (хранится только текущий за последний час), остальное с помощью агента или консольной утилиты переносится на файловой хранилище (особые ортодоксы кладут такие файлики прямо на Hadoop, для маленьких команд работает несколько другой подход.

rsync d:\srvinfo**.lgr -e ssh pd-logs.example.lan:~/var/log//
del /y d:\srvinfo**.lgr
то есть просто тупо кладем файлики на хранилище. RSync для любителей PowerShell может быть заменен на PS командлет.

таким образом ты имеешь ВСЕ журналы регистрации, со ВСЕХ серверов 1С на хранилище.

  1. дальше на серваке разворачиваешь 3 продукта (крайне желательно контейнерами) но можно и через далее - далее - далее Logstash + Kibana + ElasticSearch.

весь вопрос зачем ?

  1. центральное хранилище журналов регистрации, с быстрым поиском
  2. хранение ВСЕХ событий журнала регистрации
  3. централизованное оповещение об ошибках журнала регистрации - чтобы не подключать БСП (будь она не ладна).
  4. красивые и модные панели. :wink:
  5. PROFFIT
4 Симпатий

Спасибо за развернутый ответ.
Теперь захотелось и у себя развернуть и посмотреть на всю эту красоту.

маленькое замечание - мы с @pumbaE когда рассказывали про DevOps на связанном тренинге, делали хитрый вброс о том, что и технологический журнал то же данные, и их тоже можно хранить и анализировать, но… пока никто, кроме одной НЕ названной команды этого не пробовал.

немного вклинюсь в разговор.
с учетом подключения технологического журнала в течении какого времени это возможно запустить (делая в первый раз) и получить хранилище с данными скажем по 8 системам?
Понимаю что оценка будет экспертной, коэффициент отклонения накину.

3-5 дней. Если не играть в политику и не “метать” бисер перед техническими “свяньями”.

Машинка может быть простая под столом - например i7 и тарабайтника будет достаточно. Бэкапы потом настроить - дело дня.

Хоть и прошло много времени, но про тему я не забыл.
В рамках изучения docker запустил связку logstash+es+kibana.
Пока научил проглатывать обычный текстовый лог 7ки.
Многое еще не понятно как в docker, так и в связке, но мне определенно эти штуки нравятся, буду наращивать использование.
lustin, pumbaE спасибо за ликбез по этой теме

1 Симпатия

Я лично добил адаптер для Logstash + 1C (журналы регистрации и технический журнал).

Теперь большой вопрос - как это перевести в Production’ready концепцт

А так не за что.

1 Симпатия

Под адаптером имеется в виду плагин на ruby? За основу брался этот: https://github.com/logstash-plugins/logstash-input-sqlite ?

А в чем загвоздка? Стабильность? Сложное развертывание?

Немного переписал плагин sqlite для logstash и он начал передавать данные в ES, но только если в этих данных нет даты.
В запросе к sqlite преобразую дату из integer datetime((EventLog.[date] - 62135596800 * 10000) / 10000 - 3600, ‘unixepoch’, ‘localtime’) и это отрабатывает нормально.
Дальше logstash пытается переварить эту дату и вываливается с ошибкой:
“reason”=>“failed to parse [date]”, “caused_by”=>{“type”=>“number_format_exception”, “reason”=>"For input string: "2015-06-26 07:08:55"
Попробовал перевести дату в строку в запросе: strftime(date,‘now’) но так же получил ошибку.
Попробовал сделать фильтр в logstash: filter {
date { match => [“date”, “YYYY-MM-dd HH:mm:ss”] }
} ошибка все равно остается.
Алексей, Евгений, как вы обходили эту ошибку? Может есть какая то возможность передать дату числом и собрать уже на уровне logstash\es?
Еще интересно, какую колонку использовали в качестве нумератора, который используется для сохранения последнего загруженного номера строки? Если не секрет конечно.
Видится возможность использовать rowID, но непонятно как тут быть, если обрезать журнал.
Сам пока использую поле date.

Победил. logstash прекрасно переваривает дату в unix формате. Была еще проблема с хранением since table в базе журнала 1с, но вместо такого подхода я использовал отдельную бд sqlite.
Пока топорно, но все взлетело.

Блин - видимо придется публиковать наш плагин для logstash для коллективной разработки. Чтобы тебе было легче кодировать.

Только у меня к тебе одна просьба - я тебе выдам доступ к исходникам плагина, но он не для распространения в публичной сфере. Потому что его нужно вначале отладить на наших внутренних проекта.

Было бы действительно легче, возможно смогу внести свой вклад в этот плагин. У меня сейчас работает для цб, но с проблемами. По плану отладить и попробовать свести журналы всех 9 узлов риб в ES. Так что в отладке точно смогу помочь.

InfluxDB + Grafana никто не пробовали использовать? У нас просто исторически железячные метрики в нём, задумываюсь 1С-овские логи тоже туда отправить.