ETW events for debugging
Before opening a feature request against this repo, consider whether the feature is generic enough for the SDK, or it should be a specific plugin/extension to the SDK.
Is your feature request related to a problem? #130
- The issue 130 was not reproducible on-demand.
- Once there is a very rare repro in a retail build on a customer's (Bing team) machine, the bug persisted in the existing running Edge process.
Describe the solution you'd like. Emitting ETW events of debug logs when there is a listener.
Describe alternatives you've considered. Enabling at run-time printing out of all levels of debug logs when there is a debugger attached.
Additional context. None.
We had that feature in v1.7-v1.8 legacy SDK, but unfortunately it was not implemented in v3.0 yet. There are several other practical reasons why we'd really like to do this ---- pretty much routing all debug logs to ETW provider instead of file on disk, so that we don't store the log in TEMP dir.
There's a related "Enhancement" described here, which was also suggesting not only routing debug logs, but "loopback events" to ETW - #7
Part of the implementation is in - copied from the legacy SDK. But not currently wired to the log macros: https://github.com/microsoft/cpp_client_telemetry/blob/master/lib/tracing/api/DebugLogger.hpp https://github.com/microsoft/cpp_client_telemetry/blob/master/lib/tracing/api/DebugProviders.hpp Ref. ETWStringStream implementation that allows to route events to ETW. I can take on the task to reroute all debug logs to ETW - to wire that code again.
So that you can attach the ETW listener, and/or use tools like Microsoft Message Analyzer to review the process debug logs in realtime.
@mkoscumb - basically Office would also benefit if we stop emitting logs on disk. But route to ETW and only if the ETW listener for that provider GUID is registered. That way we would no longer need to store logs in TEMP....
@HIROSN based on some discussion from the past couple community meetings, it should already be possible to change the logging level at runtime by updating the SDK's config. I think the main ask here is to support a logging mechanism that doesn't cost anything until it's enabled/used (like ETW)?
Logging to a file, with how it was setup in the SDK, incurred some cost on all clients, even when we didn't want logging -- so we disabled some of that code.
Reforecast to April.
Reforecast to June.
Reforecast to 2021. We can use OpenTelemetry C++ SDK ETW exporter for that. It adds about ~40KB. https://github.com/open-telemetry/opentelemetry-cpp/issues/326