You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at open-telemetry/opentelemetry-specification#3740 (comment), I noticed that the "console" loggers are using java.util.logging, which I suspect could get fed back into the logs "console" exporter if someone is using a jul bridge back into their logging framework and using our logging framework appenders.
I think #5918 could be used to address this (currently suppression is only checked for spans, so we would need to add a suppression check for logging instrumentation also).
The text was updated successfully, but these errors were encountered:
Although we have a special case for the stdout / console exporter for the log signal, which we call SystemOutLogRecordExporter. In this, we explicitly log to system out instead of using a logging framework. This avoids infinite loops of the form: LogAppender -> Log SDK -> LogExporter -> Logger -> LogAppender -> etc
Looking at open-telemetry/opentelemetry-specification#3740 (comment), I noticed that the "console" loggers are using java.util.logging, which I suspect could get fed back into the logs "console" exporter if someone is using a jul bridge back into their logging framework and using our logging framework appenders.
I think #5918 could be used to address this (currently suppression is only checked for spans, so we would need to add a suppression check for logging instrumentation also).
The text was updated successfully, but these errors were encountered: