-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiline filter breaks pipeline #5864
Comments
Is the issue step4 and step5 since step3 doesn't rewrite a tag name ? @PettitWesley @edsiper |
Hi @nokute78, when you execute the sample config, you will see, that there is no infinite loop (at least in this case), but there is step4 being executed one time for each multiline from step3. Before v1.9.3 this was not the case, where the processing ended after step3. I am aware that we could add a workaround for issue into our config and I am not saying that this is a severe bug - but it is definitely an unexpected behaviour change (which potentially leads into infinite loops for existing pipelines), that either should be fixed or documented correctly. Your idea of adding an integrated rewrite tag option for the multiline filter sounds good to me. |
I think adding an option to rewrite the tag makes sense. |
I am also surprised by your use case @drbugfinder-work When I fixed the filter and made it work using rewrite tag, I assumed that everyone would and could put the multiline filter as the first filter, since my thinking was that multiline logs that are split into multiple events are created by a source/input and the first thing you always want to do is recombine them, and then afterwards do any more processing. There'd be many cases where processing them first would make it impossible to recombine the split records. |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the |
This issue was closed because it has been stalled for 5 days with no activity. |
Bug Report
Describe the bug
With the update from FluentBit 1.9.2 to >= 1.9.3, we have observed, that parts of our pipelines break.
We have identified that there is an issue with the multiline filter. Unfortunately the patch #5564 (v1.9.5) does not seem to help here like with #5524 (comment)
The observed behaviour is that already processed records are getting processed again from the beginning of the pipeline after they were merged together by the multiline filter. This leads to a totally different (and wrong) processing of records, as they are potentially getting modified twice, when they enter the pipeline as a multiline record once again.
I'm guessing this is related with various in_emitter changes (e.g.: #4325 (comment) cc @nokute78 )
To Reproduce
fluent-bit.conf:
dummy-deployment-123_abc_dummy-xyz.log:
parsers.conf:
unpack.lua:
Test it with fluentbit 1.9.2, 1.9.3 (and later versions), you will see that in >= 1.9.3 the multiline record will enter the unpack.lua a second time after it was combined in the multiline filter.
Expected behavior
v1.9.3 and above should behave like v1.9.2 and below (or at least add this behaviour change to the documentation).
The text was updated successfully, but these errors were encountered: