-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
[exporter/logging] Build exporter's logger from service's logger #5677
[exporter/logging] Build exporter's logger from service's logger #5677
Conversation
69c78c3
to
16b18ad
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Codecov Report
@@ Coverage Diff @@
## main #5677 +/- ##
==========================================
+ Coverage 91.44% 91.53% +0.09%
==========================================
Files 192 192
Lines 11416 11398 -18
==========================================
- Hits 10439 10433 -6
+ Misses 778 770 -8
+ Partials 199 195 -4
Continue to review full report at Codecov.
|
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.
Arguably, the current behavior (not this PR's behavior) is desirable. When I am troubleshooting I often add a logging
exporter and set it to debug
level. I don't also want to enable debug
level for everything else, it will be just too much noise in the logs.
If we feel there is inconsistency because logging
exporter's debug
level does not honour the main level setting, I suggest we do something else instead: the "loglevel" setting of the logging
exporter should control whether the detailed output is generated, however that detailed output should be generated using info
level, not debug
level. So, essentially "loglevel" setting will control the behavior of the logging
exporter, not the behavior of the logging
exporter's logger. All output from logging
exporter will happen at the info
level. Once that change is made you can then pass the service's logger to the logging
exporter to use.
@tigrannajaryan Right, this was the first alternative mentioned in #5677 (comment). It feels a bit weird to me, but I understand your point about wanting to filter the logs. PTAL at #5678 which implements the suggested change. I will update this PR once that one is merged, marking as draft until then |
91c1643
to
9f78d01
Compare
Rewritten to not have breaking changes; depends on #5678 |
9f78d01
to
066c567
Compare
@tigrannajaryan this is ready for another look, I updated the PR description; this no longer introduces any breaking changes |
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.
LGTM
Description:
Build the logger on the logging exporter's logger from the one on
TelemetrySettings
, so that the logger honors the configuration settings ontelemetry::logs
and the configuration options onCollectorSettings.LoggingOptions
.Depends on #5678
Link to tracking Issue: Fixes #5652
Documentation: Documented the feature gate.