-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Metricbeat] Add reporting interface with error #10727
Conversation
db23d86
to
1d03797
Compare
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 like this a lot! I was just wondering about this last night so I am very happy to see it.
I'm still in favor of logging errors at the |
Maybe adding a log level as input parameter so we can set to |
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.
Nice idea!
For the logging level, have a look at my longer comment here: #10727 (comment) I think error logging should be focused on the production and not the setup / testing use case. |
bf89bbd
to
c6d1ada
Compare
c6d1ada
to
9c09c1c
Compare
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'd try to avoid adding a new fetcher interface, but as we can still reuse ReporterV2
and it is so easy to implement from the ReportingMetricSetV2
one I am not going to complain 🙂
1b91a13
to
cd2bf04
Compare
a86ffb4
to
681f41a
Compare
…ogs errors (#11763) Refactors code in the `kibana` Metricbeat module to use the new `Fetch` interface introduced in #10727. Note that x-pack code paths in this module were not refactored to use the new interface as we don't want errors from those code paths to be reported into `metricbeat-*` indices, only logged to Metricbeat logs. Related: #11767.
In Metricbeat modules we often see the pattern that before fetching the actual data, some processing is done and checks for errors happen. If an error happened, we have 3 lines of code:
By introducing the reporter interface with support for return an error I would like to eliminate the overhead and allow to directly return and error which is then reported and also logged.
So far we logged the error on the Error level. I'm now wondering if we should log these errors actually on the Info level as it's normally not a misbehaving of the Beat but the service does not respond as expected. So for the operator of the Beat normally no actions are needed.
As an example metricset I took php_fpm.process.