запусти руками от УЗ logstash

просрался пользователь почему-то

уже починили

коллеги, хочу странного. можно ли притормозить в логстеше по условию одно сообщение, а не весь пайплайн? что то вроде 'отложить в кэш на N секунд'

добрый день всем
есть 2 хоста, с одинаковой версией логстеша, одинаковыми конфигами, одинаовыми по происхождению наборами jsom-файлов.
на первом jsom парсится нормально, на втором - провал.

как подебажить, чтобы поймать, где ломается?

хм... ошибка именно в парсинге?

или в прохождении пайплайна в целом?

Из идей в голову приходит только - перебросить это сообщение на другой пайп. То есть если выполнилось условие то сразу на аутпут посылать это сообщение (например по tcp или любой другой) и тут же его снова ловить логсташем и туда уже вкручивать sleep

не, проблема в том, что слипом тормозится весь воркер. т.е. при sleep => N, скорость прохождения сообщений через пайплайн будет worker_number/N...

не могу понять
т.к. пару перезапусков логстеша назад он втягивал все 140 тыщ записей, и больше не втягивает более свежие записи

и у всех втянутых тег _jsonparsefailure

так ты ж в пайп другой направишь, а основной пайп у тебя как молотил так и будет молотить

ну как. прилетает 10 записей в секунду... слип в секунду. последняя запись из пачки за первую секунду обработается через 10 секунд. и к этому моменту в очереди уже будут висеть следующие 90 сообщений. в результате - либо memory overhead, либо потери сообщений, как настроить...

ну, значит либо конфиги не одинаковые, либо софт-источник косячит с форматом

прилетело 10 сообщений на инпут1, дальше они пришли в фильтр1, 4 обработалось и ушли неа аутпут1, а пятое попало под условие и ты его без дальнейше обработки сразу кинул на аутпут2 (аутпут2 это не в эластик а в какой-нибудь tcp или вроде того) и оставшиеся 5 поступивших на аутпут1 прошли тоже как и первые 4 через фильтр1 и попали на аутпут1. а  вот то сообщение которое ты отправил на аутпут2, ты ловишь на инпут2, в фильтре2 ставишь слип, а затем атупутишь куда хочешь. Соответственно у тебя основной пайп не тормозиться, так как в нем нет слипа

основной - нет. тормозится добавочный. и там будут теряться сообщения, если будут прилетать чаще, чем 1 сообщение в слип-интервал.

дебажить с помощью stdout { codec => rubydebug } логстеш запущенный как сервис нельзя... арррр

да в принципе и не нужно. если у тебя не распарсился json, то он должен записаться одной строкой в поле message, можно скопировать для разбора оттуда

только тяни через json-вид в кибане, могут быть нечитаемые символы, в обысном просмотре обрезается

всем привет. Кто-нибудь пробовал передать через файлбит определенные лейблы  из докер-контейнера? В файле filebeat.yml уже есть несколько инпутов с типом container, указанием пути до файла логов этого контейнера и другими параметрами. Поначитался в доке, что лейблы как-то иначе подключаюся. Направьте на путь истинный.