-
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
Feature Request: Change multiline behavior to support cri-o type logs #1316
Comments
Hi, we also need a solution for partial logs cri-o (containerd). For example it would be great if this solution #852 could be extended. |
Definitely, we will work in a solution... ...but let's be honest, how is possible that another tooling is still adding more complexity when generating multiline logs ? |
any updates? |
The following is a minimal version of the idea from #852 implemented as a Lua filter. Untested, may be buggy. local reassemble_state = {}
function reassemble_cri_logs(tag, timestamp, record)
-- IMPORTANT: reassemble_key must be unique for each parser stream
-- otherwise entries from different sources will get mixed up.
-- Either make sure that your parser tags satisfy this or construct
-- reassemble_key some other way
local reassemble_key = tag
-- if partial line, accumulate
if record.logtag == 'P' then
reassemble_state[reassemble_key] = reassemble_state[reassemble_key] or "" .. record.message
return -1, 0, 0
end
-- otherwise it's a full line, concatenate with accumulated partial lines if any
record.message = reassemble_state[reassemble_key] or "" .. record.message
reassemble_state[reassemble_key] = nil
return 1, timestamp, record
end |
We are looking for a solution to handle cri-o multiline logs as well. Is there any way to do this now or is it still a missing feature? |
@strantalis You can write logs from application(s) WITHOUT newlines - replacing '\n' for another symbol - collect logs with fluentbit, send messages to ES, and replace "another symbol" back to '\n' in elastic pipeline... Sounds like a crutch, but it's working - we use this solution for handling multiline java stacktraces - see more |
The Lua filter I described in #1316 (comment) is another approach. Been using something very similar in production for the past few months, works great. |
For some reasons on my side it works only with braces around local reassemble_state = {}
function reassemble_cri_logs(tag, timestamp, record)
-- IMPORTANT: reassemble_key must be unique for each parser stream
-- otherwise entries from different sources will get mixed up.
-- Either make sure that your parser tags satisfy this or construct
-- reassemble_key some other way
local reassemble_key = tag
-- if partial line, accumulate
if record.logtag == 'P' then
reassemble_state[reassemble_key] = (reassemble_state[reassemble_key] or "") .. record.message
return -1, 0, 0
end
-- otherwise it's a full line, concatenate with accumulated partial lines if any
record.message = (reassemble_state[reassemble_key] or "") .. record.message
reassemble_state[reassemble_key] = nil
return 1, timestamp, record
end``` |
am I understanding this right? For the time being, simply using the cri parser when using cri-o/containerd is the correct parser, but it doesn't handle is multiline format well which requires further processing or this lua workaround. Please let me know if Im misunderstanding. |
Yes, the CRI parser will split every log line from CRI-O / containerd into |
Correct for now, note: we are working on generic multi-line support. Targeted for 1.7.X release, and after the first release |
Ok thank you I will be keeping an eye on this issue then |
in addition to the lua script being added, does /var/lib/docker/containers also need to be changed? also if anyone is using the helm chart for the lua script does anyone have an example of just the lua section, are you just putting that block "as is" into the curly brackets? |
We have also come across this issue where we have json log messages being put to stdout. Podman option for logging is journald which has its own mutiline max message size issues or k8sfile logging which is CRI-O as far as i can tell. CRI-O splits the json logging over 4 or 5 lines, it would be nice for fluentd and fluent bit to re-assemable these before being posted to elasticsearch. |
Actually now I'm wondering what fluentbit was doing with /var/lib/docker/containers, was it using it for metadata? with kubernetes tail is referening /var/log/containers/ after changing the parser to be cri, |
is this what's causing it?
im wondering if we can set this to -1 for now and it wont split any more? may as well suggest it just in case. |
This is a setting only in containerd, right? It doesnt exist in CRI-O at least. |
[editing response: max container log size is "under" key pair streaming section, but its not indented to be in that section, very confusing and strange]
I actually tried max_container_log_line_size = -1 to see if it would help, and not sure if anyone else wants to try it and collaborate findings but I no longer see logtag P, every logtag is now F. I did a filter in kibana and the only logtag showing up is F, I get 0 results for P. I hope its safe to assume I'm not getting separated logs with this. so perhaps for the containerd folks, this is a less intrusive alternative to the custom lua script? @timricese and yes, I can only confirm that I found that setting in containerd, thats what I'm using. |
Is there any news? Lua script is not worked for me.
|
I think it would be good to support cri-o type logs. We are running into this issue in our kubernetes cluster. |
FYI: new & native multiline support (with docker and cri modes) is coming shortly :) |
|
~2 weeks max |
#3444 was merged but doesn't appear to be released or documented yet. Is that also coming soon? |
Does release 1.7.5 contain the feature? There is nothing about multiline in RN( |
Those commits aren't in that tag, so I think not. |
I tried to look into the code, built the image v1.8 and havn't undestood how to set subj ( |
Hi guys, any updates on it? |
Considering that the feature resides on then branch "https://github.com/fluent/fluent-bit/tree/multiline-1.8" my guess is, that it will be available with release version 1.8.X |
I don't know why, but in our cluster, many lines are tagged with
|
@kien-truong we've seen this happen with some log types, for example Go raw stack traces where the Go runtime writes out each line in a separate |
@kien-truong you can use your own record start marker to collect multiline record + lua script to remove cri "prefix":
parsers
cleanup.lua
|
Is there documentation on MULTILINE_PARSER somewhere? The new |
(now we ship a built-in "cri" multiline parser) Multiline UpdateAs part of Fluent Bit v1.8, we have released a new Multiline core functionality. This new big feature allows you to configure new For now, you can take at the following documentation resources:
Documentation pages now point to complete config examples that are available on our repository. Thanks everyone for supporting this! |
@edsiper could you take a look at fluent/helm-charts#137 to add v1.8 support to the Helm chart? I'm happy to change the kubelet defaults and wait for the v1.8.2 image if that works better. |
@edsiper Was wondering about
|
@Quarky9 I think you might want to wait for the v1.8.2 release later today as that's the version mentioned in the announcement. |
FYI, although this issue is closed, it only appears to be partially solved by the current multiline parser capability -- specifically, although the built-in CRI parser can correctly parse CRI multiline logs, any custom multiline parser that you create will not be able to correctly parse CRI multiline logs. So, if you cannot use the built-in parser for whatever reason, you will not be able to create your own custom parser to use instead. In other words, as of now, any custom multiline parser that you create seems to suffer from the same regex limitations described in the very first post above:
For more details, see #4033. |
Problem
It appears as if fluentbit currently does not support cri-o type of multiline logs. This is due to the way the multiline code works.
Given a log format of type
A
which indicates a normal log line, and a log format of typeB
which indicates a continuation log line, the current multiline behavior is to only supportABBB
type multiline logs, but it doesn't supportBBBA
type multiline logs (to see what I mean, check out example 1 and 2 below).Cri-o has two logtags,
P
indicating a partial log line (one that will be continued by another partial log line, or by a 'full log line'), andF
indicating a full log line. AP
tagged log will be followed by a terminalF
tagged log to close out the multiline log. For example, cri-o logs look like:Which should become
foo bar baz bot
when combined as a multiline log. Current behavior is such that ifParser_Firstline
is set to match(?<date>[^ ]+) (?<stream>[^ ]+) P (?<log>.*)
, then instead of a single log offoo bar baz bot
current behavior would be to get three logs,foo
,bar
andbaz bot
.Possible Solution
Instead of a
Parser_Firstline
andParser_N
, can we have aParser_Multiline_Start
,Parser_Multiline_Continue
andParser_Multiline_End
?Example 1
Given the following logs in a file
/some/file
which can be captured with the current multiline behavior:given the following parsers:
Could be configured as:
Example 2
Given the following crio logs in a file
/some/file
which can not be captured with current multiline behavior:given the following parsers:
Could be configured as:
I believe the logic to use these parameters,
Parser_Multiline_Start
,Parser_Multiline_Continue
, andParser_Multiline_End
should be fairly straightforward. Would this be something that would be acceptable if it appeared in a PR?Best
The text was updated successfully, but these errors were encountered: