Тема, drop rule я итак легко могу сделать. Но это никак не решает задачу тротлинга, так как drop rule видит только текущее сообщение, и может дропать только по условию полей этого сообщения

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

Ох, в пайплайне добавь свою функцию, которая будет делать инкремент в кастомное статик поле которое можно добавить на инпуте и отправляй это в другой стрим. Там проверяй, если инкремент больше 10, дропай.

Фиксед?

Это есть в доках же

Да там только стринги и да надо ещё вычислять по таймстампу что инкремент ещё валидный. Но это все реализуемо

Я в Питер полетел, развлекайся)

pipeline отрабатывает после добавления static field в input. Они вообще не свзяаны.
static field ты просто можешь статично добавлять какое-то поле в input. Больше ничего

pipeline привзяывается к стриму. Ты можешь в нем поле с инкрементом добавлять - да. Но где ты будешь хранить счетчик и откуда ты возьмешь условие инкремента? У тебя pipeline видит текущий только лог, откуда ты возмешь счетчик для инкремента? И как ты напишешь условие, ты не можешь текущее сообщение сравнить с предыдущим например

Вот так выглдяит static field в input

Окей ты добавляешь через static field в input например поле INC=1
Что ты с этим будещь делать в pipeline? +1 Ну будут у тебя все логи с INC=2

нет, ты не можешь в pipeline это сделать. Так как pipeline кроме текущего лога ничего не знает, он не может знать, например что предыдущий лог был такой-же. И брать счетчик из лога который уже обработал, чтобы сделать текущему логу +1

А о чём сыр-бор то? Я смотрю со стороны, думаю, ну воткните перед ним какую-нибудь мидлварь, которая будет знать и уметь то, что нужно (и какие предыдущие сообщения были, и какая очредь накопилась...)

Вот теперь дальше подумай сам, как это реализовать. Цепляй туда пипелин, статик поле у тебя есть, пишешь функцию, по регекспу, допустим, еррор, делаешь инкремент. потом route_to_stream,  там другой пипелин и там чекаешь что ты заполнил.
Если инкремент больше десяти, начинаешь дропать.

ну понятно что можно свое решение написать. Речь о graylog. Я пытаюсь выяснить, как это делает @Sn00p, а он не хочет делиться pipeline'ом, или этого просто не делал

Разжевать до функции?)

Это платные услуги.

Ща он сто пудов спросит, как понять что сообщения одинаковые какой надо регексп написать) но и это реализуемо

Тем же механизмом

по какому регексу? Откуда возметься increment > 10?

Окей вот у тебя логи
1) "{message: test}"
2) "{message: test}"
3) "{message: test}"

Как ты сказал, мы добавили к ним через static field в input поле INC = 1. Получаем
1) "{message: test, INC: 1}"
2) "{message: test, INC: 1}"
3) "{message: test, INC: 1}"

Что мы должны сделать в pipeline чтобы получить:

1) "{message: test, INC: 1}"
2) "{message: test, INC: 2}"
3) "{message: test, INC: 3}"

Если мы напишем так

rule "incremtent"
when
    has_field("INC")
then
   set_field("INC", to_long($message.INC)+1);
end

То получим
1) "{message: test, INC: 2}"
2) "{message: test, INC: 2}"
3) "{message: test, INC: 2}"

Это первое

Второе, каким образом ты в pipeline вообще проверишь что у тебя текущее $message такое-же как предыдущее?
Если у тебя например на вход пришло

1) "{message: test1}"
2) "{message: test2}"
3) "{message: test3}"

То ты получишь теже самые

1) "{message: test1, INC:2}"
2) "{message: test2, INC:2}"
3) "{message: test2, INC:2}"

Ну вот подумай, ты же можешь там какие хочешь функции писать