-
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
cloudwatch_logs: remove sequence tokens from API calls #7973
cloudwatch_logs: remove sequence tokens from API calls #7973
Conversation
src/aws/flb_aws_util.c
Outdated
/* error can not be parsed, print raw response */ | ||
flb_plg_error(ins, "Raw response: %s", response); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might not be the right way to think about things, but one interesting thought I just had- we already have folks complaining about the rates of hits for "error" from Fluent Bit: https://github.com/aws/aws-for-fluent-bit/blob/mainline/troubleshooting/debugging.md#rate-of-network-errors
So I wonder if this should be warn, because its printing a raw response which if its an error, will probably have error in it, so we don't need to further increase our error hits anymore...
🧐
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's reasonable.
src/aws/flb_aws_util.c
Outdated
@@ -596,6 +598,7 @@ void flb_aws_print_error(char *response, size_t response_len, | |||
} | |||
|
|||
flb_sds_destroy(error); | |||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why add empty return?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No reason I can recall. Can remove.
Minus one small comment, I think this is probably good to go. |
6c9656d
to
737cb82
Compare
/* error can not be parsed, print raw response to debug */ | ||
flb_plg_debug(ctx->ins, "Raw response: %s", c->resp.payload); | ||
/* error can not be parsed, print raw response */ | ||
flb_plg_error(ctx->ins, "Raw response: %s", c->resp.payload); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matthewfala for same reasoning as my earlier comment on error => warn for raw responses, let's also do warn here?
/* error can not be parsed, print raw response to debug */ | ||
flb_plg_debug(ctx->ins, "Raw response: %s", c->resp.payload); | ||
/* error can not be parsed, print raw response */ | ||
flb_plg_error(ctx->ins, "Raw response: %s", c->resp.payload); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comment here
737cb82
to
f6c1c45
Compare
f6c1c45
to
6c9656d
Compare
6c9656d
to
737cb82
Compare
737cb82
to
eeb3009
Compare
Signed-off-by: Matthew Fala <[email protected]>
eeb3009
to
e17679c
Compare
@@ -581,6 +581,8 @@ void flb_aws_print_error(char *response, size_t response_len, | |||
|
|||
error = flb_json_get_val(response, response_len, "__type"); | |||
if (!error) { | |||
/* error can not be parsed, print raw response */ | |||
flb_plg_warn(ins, "Raw response: %s", response); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This lacks full context that it could have: we can print the api
value in the raw response here, like: PutLogEvents: Raw Response:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess based on the response, the API should be obvious? Is this true? I think if this does really add context, it'd be nice to add.
We could also follow up with it later I suppose, as long we stage it now, so we don't forget it..
What are your thoughts on how important this context is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this is nice to have but not essential. I'll update this for master, and include it in aws-for-fluent-bit after release of 2.32.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool and thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to go minus one minor CX comment
thanks, merged. note: commits must be with proper plugin name e.g: |
Signed-off-by: Matthew Fala <[email protected]>
@edsiper @PettitWesley @matthewfala is it safe to say that with 2.2.0 release of fluent-bit workers are at least supported with cloudwatch_logs output? I don't see the documentation updated but just wanted to double check with you all. |
Allow multiple workers on
cloudwatch_logs
by removing sequence tokens 🎉🎉🎉This PR removes the sequence tokens from CloudWatch Log API requests entirely (as per the recent CWL API update).
Also removes error handling for
InvalidSequence
andDataAlreadyAccepted
exceptions which no longer occur.CWL API Docs:
https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html
Note: This is a cleaned up version of the following branch https://github.com/PettitWesley/fluent-bit.git 1_9-sequence-token
Enter
[N/A]
in the box, if an item is not applicable to your change.Testing
Before we can approve your change; please submit the following in a comment:
If this is a change to packaging of containers or native binaries then please confirm it works for all targets.
ok-package-test
label to test for all targets (requires maintainer to do).Documentation
Backporting
Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.