-
Notifications
You must be signed in to change notification settings - Fork 134
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
S3 output key formatting inconsistent rendering of $TAG[n]
#376
Comments
@ssplatt Do you mean the issue is random? May I know the frequency? |
I mean that over the last month since we upgraded to 2.25.1, some logs have made it through to the correct location ($TAG[2] parsed correctly), some have gone to fulltag[2], some have gone to $TAG[3], and some have gone to $TAG[1]. No other change has happened in the month. The output tag from our app is the same. On some days, all 4 appear. On same days, only one of those permutations shows up. It seems random because I cannot find a pattern to it other than an upgrade to 2.25.1. |
I have several thousand examples of this. I can try to get counts of all the different permutations but it might be more difficult for some. For example, the case where $TAG[2] actually parsed as $TAG[3] and ~100 different subdirectories were created. |
I can confirm it's happening to me too. In my case it happens when I use more than one OUTPUT, it seems that the plugin gets lost and mixes the tags. |
I have 6 or 8 using similar patterns. And like I said it worked fine until upgrading to 2.25.1. |
Thanks for all the report. We will try to reproduce the issue and get back. In the meanwhile, it would be much appreciated if anyone can test our latest version (2.26.0) to see the problem also happens. Thanks |
I can share more details in an AWS support case if that'd be helpful |
This issue does appear to continue in 2.26.0 |
to add more general detail, we are splitting logs into a bucket for use with Athena and a "raw log" bucket for backup in case we decide to repartition or need to re-ingest, or whatever. In one instance we are also forwarding all logs to our "legacy" fluentd cluster to make sure we have a backup in case the "new" Firelens Fluent Bit path doesn't work. The tag takes the form of So it seems that $TAG sometimes doesn't parse at all and other times the actual tag components get nudged to have a different index. |
@PettitWesley any update on this? We're using the output to seed an Athena database so the broken object path is hurting our partitioning. |
@ssplatt i am oncall this week and will take a look for this issue.
I will have an update by end of tomorrow based on my findings. |
@ssplatt I tried to reproduce it in my local but didn't make it.
I have ran fluent bit for 1.5 hour without any inconsistent rendering of $TAG[n] appearing at my side. |
According to one of the other comments, it only appears when there is more than one output in the same configuration using the tag sub indexes as a part of the key format. Can you add another S3 output (or 2 or 3) to your test setup? |
I'm hitting the same error, and it's happening when I configure multiple OUTPUTS. Here's a sample:
|
I see. I'll try multiple output today. Thanks for clarification |
here's a few examples from my configuration, highlighting that I have numerous outputs and many different sub-indexes used in different outputs.
|
Cool, I can reproduce it in my local now with below configuration,
The log path appears like below which doesn't right.
will take some debug and see what i can find. I don't have a ETA for now but will keep posted there if i find anything. |
@ssplatt @DrewZhang13 I am now working on repro and investigation for this bug. Do you folks see lots of these warnings when it fails, because I do:
|
I'll double check tomorrow but I do not believe I've seen logs like that |
1 similar comment
I'll double check tomorrow but I do not believe I've seen logs like that |
I also think there must be a way to repro this with a single output... all of the code is entirely thread safe and has no context outside of a single call... |
Oooooo I think I might have figured out what it is... the https://man7.org/linux/man-pages/man3/strtok.3.html I remember skimming that man page when we built that feature and thinking that this function was way too magical sounding. This is one of those times when we must remember that all AWS integrations with Fluent Bit were led/reviewed/written by an engineer who was not a real C programmer before he started Fluent Bit and previously had mostly just written really simple single-threaded Golang tools (me). |
The fix can be used via this image:
|
@PettitWesley |
@kyos3 Thanks! |
https://github.com/aws/aws-for-fluent-bit/releases/tag/v2.28.0 , the change in the release |
Bug Report
Describe the bug
S3 output has a key_format property which allows for using $TAG, or $TAG[n], (along with tag_delimiters) to create a path for objects based on tag properties. Sometimes using
$TAG[n]
in the path works fine, other times you get$TAG[n-1]
and still other times you getfull.tag.output.without.parsing[n]
rendered.To Reproduce
my.awesome.experimental.tag
.
/$TAG[2]/some_value=$TAG[3]/year=%Y/month=%m/day=%d/%H%M%S-$UUID.gz
tag[2]
astag[3]
and sometimes it doesn't parse the tag at all so the path results in/my.awesome.experimental.tag[3]/
all without changing the fluent-bit version, the app version, the tags, or anything else.Expected behavior
given
my.awesome.experimental.tag
,$TAG[2]
should always parse toexperimental
and the s3 key path would then always render as/experimental/some_value=tag/
Your Environment
aws-for-fluent-bit 2.25.1, fluentbit 1.9.3, Fargate and Firelens.
duplicate of fluent/fluent-bit#5662 since we're using aws-for-fluent-bit, wanted to raise awareness here as well.
The text was updated successfully, but these errors were encountered: