-
Notifications
You must be signed in to change notification settings - Fork 765
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
Add AddOpenTelemetrySelfDiagnosticsLogging to OpenTelemetry.Extensions.Hosting #1867
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1867 +/- ##
==========================================
- Coverage 83.75% 83.61% -0.15%
==========================================
Files 251 255 +4
Lines 8864 9038 +174
==========================================
+ Hits 7424 7557 +133
- Misses 1440 1481 +41
|
src/OpenTelemetry.Extensions.Hosting/Implementation/SelfDiagnosticsEventLogForwarder.cs
Outdated
Show resolved
Hide resolved
Funny I did the same thing. Here's mine: https://github.com/Macross-Software/core/tree/develop/ClassLibraries/Macross.OpenTelemetry.Extensions |
Nice! I think it's really important to be able to easily enable these to go to the normal logging system and see why something isn't working or even just how it's working. |
src/OpenTelemetry.Extensions.Hosting/Implementation/EventSourceEventFormatting.cs
Outdated
Show resolved
Hide resolved
src/OpenTelemetry.Extensions.Hosting/Implementation/SelfDiagnosticsEventLogForwarder.cs
Outdated
Show resolved
Hide resolved
/// SelfDiagnosticsEventListener class enables the events from OpenTelemetry event sources | ||
/// and write the events to an ILoggerFactory. | ||
/// </summary> | ||
internal class SelfDiagnosticsEventLogForwarder : EventListener |
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.
Is this intended for local debugging only, or for production use?
I'll be a bit concerned if it is for production:
- The pattern matching "OpenTelemetry-*" and putting things in the
loggers
dictionary could be an attack surface, causing unbounded memory usage. - If folks consumes the logs in OpenTelemetry processor/exporters, it might dead loop (e.g. self-diagnostics go to logs, logs go to processor, processor triggered self-diagnostics).
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 would think it would just be for troubleshooting setups. Don't really think you'd ever want to have it on in production. Maybe briefly to figure out a telementry issue.
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.
#1258 has captured some of the requirements for a production-ready self-diagnostics solution.
If this feature is intended for non-production troubleshooting, is there a way we can clearly indicate that so people won't misuse it (e.g. a separate package, similar like the ConsoleExporter)? (e.g. in C++ folks normally do debug/release bits, doesn't seem to be a common practice in C# although technically it is supported)
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 mean, it's just listening to the event sources and writing to the logging system. Both of those things happen in production. I guess you might leave it on with a high minimum level like you do normal logging. So you can see errors and such.
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.
Also, @reyang we wouldn't need any of this if the whole project would just make use of MS.Ext.Logging like I was trying to argue for in that issue. That hasn't happened and the system currently uses event sources. So this is just forwarding those events to the standard logging system that every modern .NET app uses.
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.
My biggest concern here is that we could easily end up with dead loop.
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.
@cijothomas that would require moving away from event sources being the primary thing that OTel is writing to internally.
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.
If a user has enabled OpenTelemetryLoggerProvider (eg: https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/docs/logs/getting-started/Program.cs#L33), then this would be a never-ending-loop.
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.
@ejsmith Could you check this please?
(Sorry I haven't yet reviewed the recent change, but this part was an open issue even before, and not sure if this was addressed).
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.
@cijothomas I just tool a look at this and the Examples.AspNetCore
project already uses the OTel logging provider and it works fine. It does not result in a never-ending-loop.
src/OpenTelemetry.Extensions.Hosting/Implementation/SelfDiagnosticsLoggingHostedService.cs
Outdated
Show resolved
Hide resolved
0888d47
to
5089419
Compare
Changed to draft to wait for #1889 |
9841577
to
df3f1e2
Compare
@CodeBlanch @reyang @xiang17 This is up to date with main now and I think it's ready to be considered for merging. It needs to live in it's own hosted service or it won't be able to log startup issues. |
634c911
to
701d8f4
Compare
src/OpenTelemetry.Extensions.Hosting/Implementation/EventSourceEventFormatting.cs
Outdated
Show resolved
Hide resolved
src/OpenTelemetry.Extensions.Hosting/Implementation/EventSourceEventFormatting.cs
Outdated
Show resolved
Hide resolved
src/OpenTelemetry.Extensions.Hosting/Implementation/EventSourceEventFormatting.cs
Outdated
Show resolved
Hide resolved
@CodeBlanch @cijothomas @reyang I added tests and I think I've addressed all the feedback. Can you please take a look at this and let me know what needs to be done in order to get this merged? |
test/OpenTelemetry.Extensions.Hosting.Tests/OpenTelemetry.Extensions.Hosting.Tests.csproj
Show resolved
Hide resolved
// The sole purpose of this HostedService is to | ||
// start forwarding the self-diagnostics events | ||
// to the logger factory | ||
this.forwarder = new SelfDiagnosticsEventLogForwarder(System.Diagnostics.Tracing.EventLevel.LogAlways, this.serviceProvider.GetService<ILoggerFactory>()); |
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.
LogAlways
here means all the logs are going to collected by the forwarder.... Won't it mean checks like this (https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry/Internal/OpenTelemetrySdkEventSource.cs#L95), would always be true and causes perf issues?
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.
The messages get filtered out in the logger and can be controlled by logging configuration. The same logging system used in all of .NET Core production apps. I could make this a parameter going into the addselfdiagnostics method, but that would mean you would need to manually set that value and changing it in your logging configuration might not have any affect.
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.
The specification calls out having a dedicated option for controlling log level, so I think being able to adjust that independently of an application's logging level makes sense. https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#general-sdk-configuration
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.
Even if the ILogger logs are configured for ,say, only Error level, the current code subscribes to all level EventsSource logs (and drop the ones below Error.). This'd affect perf.
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.
@cijothomas I just pushed changes that set the EventLevels based on the logging configuration. It will also update them if the logging configuration changes at run time.
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.
Thanks. Will re-review this part.
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.
While this is trying to solve a reasonable ask (forward logs to Asp.Net Core's Ilogger mechanism), there are open questions unresolved, hence requesting-changes until we resolve them.
To me this isn't a reasonable ask. It's mandatory and what I would expect. It is currently very hard to figure out what is going on when I've misconfigured something and my APM data is just disappearing and not making it to the destination. Also, when I'm first starting out it's very valuable to see how things work. |
In production if I have the log level set to error then I can see when bad things are happening inside of Otel instead of them just being eaten and I never know about them. |
src/OpenTelemetry.Extensions.Hosting/Implementation/SelfDiagnosticsLoggingHostedService.cs
Outdated
Show resolved
Hide resolved
src/OpenTelemetry.Extensions.Hosting/OpenTelemetryServicesExtensions.cs
Outdated
Show resolved
Hide resolved
e379e0d
to
196f63c
Compare
25d8638
to
30b4390
Compare
@cijothomas @CodeBlanch can I please get an update on the status of this PR? |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Sigh. |
This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
It's currently hard to see what is going on with the OpenTelemetry system when you are trying to troubleshoot issues. OpenTelemetry has a self diagnostics feature, but it writes the events to a log file. This PR makes it easy to output the self diagnostics events to the .NET logging system instead and be able to easily see what is going on right in your applications logs.