А что такое НЕ используя фоновые задания ?
BigData LogManager для 1С
Это когда я не в 1С программирую алгоритм накопления данных, которые хочу выкинуть в elastic, а потом запускаю несколько фоновых заданий, чтобы это выполнить. А сам elastic, получая на вход запросы, ставит их в очередь, если не справляется по-каким то причинам (диск медленный, например). Объясню задачу. У меня в 1С идет загрузка данных в 20 потоках, и синхронно отправлять на каждый загруженный документ лог в elastic становится затратно по времени, скорость импорта падает процентов на 7-10. Но что-то мне подсказывает, что я слишком многого хочу 
Для этой цели может подойти что-то типа Beats. или Fluetnd
А вы содержимое журнала регистрации отправляете в ES?
Спасибо, посмотрю. Журнал регистрации не отправляю. Лог идет не в ЖР, а в свой справочник логирования.
Коллеги немного поправили меня: я забыл про rabbit. Он как раз больше всего к указанной задаче подходит.
Был такой вебинар, версии 1.0 - к вебинару прилагались файлы. Так вот - Инфостарт их в какой-то момент потерял. Я в какой-то момент переехал с Windows на Linux и грохнул диск с данными находясь в полной уверенности что у меня все забэкапировано либо в GIT, либо в облачном хранилище.
И внезапно выяснилось что я эти файлы найти не могу - ни в одном из репозиториев. Вот такое вот фиаско.
Шли дни и мы тут решили (у нас лето наведение порядка) наконец-то приступить к разбору старого акаунта на bitbucket. Так как у нас давно все на GitHub и GitLab - то туда особо никто и не заглядывал.
И что бы вы думали…
@aborisov https://bitbucket.org/silverbulleters/elk-bundle/src
Вот они исходнички то - все таки я таки положил их в GIT. Косяк в том что я забыл что это был bitbucket
И все-таки я не понимаю, зачем для скобочного журнала 1С нужен logstash? 
Ну типа - препроцессор… Что обеспечить типизацию по полям а не класть сырые данные
@lustin ответил на вопрос, я дополню:
Того же самого можно достичь как минимум ещё 1 путём - задействовать ingest node в кластере ElasticSearch, определив pipeline для разбора записей. Тогда Logstash не нужен в этой цепочке.
А в чем преимущество перед прямой отправкой в REST Elastic?
Бо,elastic не успевает принимать события и может их потерять.
А это как? Вот я отправил пакет, дождался подтверждения и что, тоже может потерять?
Начинает долго отвечать, запись события до 1 секунді, а если переносить журнал регистрации, то там тех собітий дофига. По чистому rest у меня не получилось в боевой режим перевести, т.к. вігрузка не поспевала за переносом последовательности.
Это в bulk режиме такие проблемы? Или поштучно?
Это поштучно - события будут отправляться дольше, чем генерироваться. В bulk режиме можно нарваться на то, что пакет не проиндексировался из-за свой величины или из-за нагрузки на сервер эластика. Beats как раз решают эту проблему - они уже содержат всю необходимую обвязку для отправки пакетов такого размера, которым elastic не подавится и примет за вменяемое время.
А индексирование блокирует прием пакетов или вопрос только в том, когда данные станут доступны?
Не блокирует. Здесь проблема в доступных серверу elastic ресурсах - если их маловато, то он может начать давать отлупы пакетам. Плюс у меня в случае с REST бывало, что пакет индексировался частично - по разным причинам, в основном нехватка памяти в куче. Вместо своего велосипеда лучше пользоваться beats.
Ну тут вопрос в том, как натравить BEATS на скобкофайл 1С-ный, либо делать промежуточную хранилку, либо грузить напрямую.
Если травить на ТЖ, то самое простое - filebeat+ingest_node, как было выше в теме. Если нужен ЖР - здесь есть разные варианты, начиная от выгрузки в текстовые логи и кормление тому же filebeat, и заканчивая beat от серебрянопульцев, который тащит журнал прямо из sqlite.
В том-то и дело, что для ЖР вариантов не много.
Непонятно что имеется ввиду под “выгрузка в текстовые логи и кормление тому же filebeat”.
Предлагаете самостоятельно дублировать весь ЖР, выгружая его кодом?
и заканчивая beat от серебрянопульцев, который тащит журнал прямо из sqlite.
От sqlite уже сама 1С открестилась. Так что это тоже не вариант.