-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Error event logs should include plugin id #4567
Comments
@DavidKnacker is the id missing even for logs generated by input plugin? |
@Athishpranav2003 I haven't checked it for error logs thrown by an input plugin yet. |
Ideally yes but since it's not behaving in that way I was checking what's the difference in underlying code Just ping me later with the case of input plugin |
👍 |
another scope of Idea: track plugin which emit error event in router side, then emit more user friendly error message. |
Thanks for your report. This fluentd/lib/fluent/root_agent.rb Lines 344 to 354 in e763c07
Although this is the current specification, it looks like not so good. |
It would be better to include the id of the plugin that emits the error event. It may be easy to manually include the id of fluentd/lib/fluent/plugin/filter_parser.rb Lines 101 to 103 in e763c07
However, it is not so good because every plugin that emits error events needs to consider this issue. As @kenhys says in #4567 (comment), it would be great if we could create a common mechanism for this.
|
@daipom so basically we need to avoid change in function signature but capture the caller plugin id? |
Yes. |
Why don't we use log.error method to generate the error log than emitting it as event(It's indirect but works the same way right)? |
@Athishpranav2003 to come back to your question, I do see the @id field for logs generated by the input plugin. |
@daipom what about this? |
Are there any updates on this? |
Sorry for my late response.
Filter plugin should use On the other hand, the events from Fluentd logger mean logs of Fluentd, not collected data by input plugins. Using both would be a possible solution. |
It would be helpful if we could know what plugin emitted the error event. fluent#4567 We need to care about the compatibility. This signature change would not break compatibility. However, I'm concerned that `caller_plugin_id` has a race condition, although I don't confirm it. It looks to me that the id can be another plugin-id running concurrently... It is not the issue with this fix, it is the issue of the existing implementation. Signed-off-by: Daijiro Fukuda <fukuda@clear-code.com>
I made a PR for this issue. However, I'm concerned about some race conditions of the related existing logic... |
I cannot say anything about potential race conditions, but I just tested the PR in my cluster and it seems to exactly achieve what I hoped for. |
@DavidKnacker Thanks! I will check the race condition! |
Describe the bug
The @id plugin parameter is used to give each plugin its unique id. This id should be included in logs generated by said plugin.
This seems to work inconsistent between different plugin types.
I tested the json filter plugin (for which the id is not shown) and the loki output plugin (which shows it)
working example:
results in logs:
Both contain the "id_too_long_message" id of the plugin the error occured in.
But for the filter plugin:
The error:
does not contain the id "id_not_json" of the filter plugin that caused the error.
To Reproduce
The config:
results in:
Expected behavior
The @id fiel, if set, shows up in logs prodcued by the plugin. In this example I would expect:
Your Environment
Your Configuration
The text was updated successfully, but these errors were encountered: