-
Notifications
You must be signed in to change notification settings - Fork 22
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] provide options to retag, send to label, and/or add keys for individual message failures #36
Comments
Oh, this plugin is based on fluent-plugin-elasticsearch. In more detail, please refer to this section: https://github.com/fluent/fluent-plugin-opensearch#retry_tag |
I will have to get to some more testing (unfortunately tied up through next week), but I believe the retry_tag and retry label approaches address issues when flushing, failing, retrying a chunk - correct? I do not believe they handle 'Records that have “hard” errors (schema violations, corrupted data, etc.) that cannot be retried will be sent to the @error handler. ' |
my attempts at testing with retry_tag or using retry label logic, when the OpenSearch cluster is not available have have been unsuccessful. I additionally tried copy with store ignore_if_prev_success have also been unsuccessful. I get a message "ignore copy because prev_success", with no copy the next destination. Has the retry_tag, retry label, and/or copy with store ignore_if_prev_success been recently tested? |
More details in relation to my above comment... With each of the following tests, I tested with this curl command...
First test - baseline with working opensearch cluster....
Results - messages made it to opensearch clusters Second test - change to an alternate port in the config to force connection failures
Result: could not connect, could not flush buffer, ultimately dropped the messages
Third test - trying with label RETRY
EXPECTED: could not connect, could not flush buffer, would send message to the RETRY label and print to stdout (DID NOT HAPPEN)
Fourth test - removing label RETRY, trying retry_tag retry_opensearch (match statement in both STANDARD and ROOT labels)
Result: could not connect, could not flush buffer, ultimately dropped the messages
Fifth test - removing retry_tag retry_opensearch logic, trying copy with store ignore_if_prev_success
Result: could not connect, could not flush buffer, ultimately dropped the messages
|
After really digging in, I understand that the retry and relabel of more or less what I was asking for in the first place - in that it should be used for individual messages failing during bulk inserts. Reading through the code, I see 409's are dropped, 400's are strictly sent to ERROR, and the remainder of code evaluate through some conditionals, then is either sent to ERROR, marked UnrecoverableError, or added to the retry_stream. The retry_stream is where it looks like the retry_tag gets used. With all of this in mind.... (and admittedly not having a good test of retry_tag and/or retry label yet) I was again hoping to ask about adding keys describing why the message failed in the first place and optionally taking messages that would otherwise be sent to ERROR and allow them to retry. I am hoping this pseudocode... might give a better Idea of what I am looking for.
|
(check apply)
Is your feature request related to a problem? Please describe.
We have message which reach the @error label without a clear understanding of why they are there.
Currently, the plugin will send messages to @error for errors like mapper_parsing_exception, etc..
The ERROR label, though, can receive messages from other plugins and/or various forms of failures
It would be beneficial to have these options for individual message failures:
Describe alternatives you've considered
N/A - there appear to be no available options when a message is errored
Additional context
N/A
The text was updated successfully, but these errors were encountered: