Allow DiagnosticSourceTelemetryModule to take OnEventWrittenHandler like EventSourceTelemetryModule?

[rggammon]

EventSourceTelemetryModule constructor accepts a OnEventWrittenHandler parameter, defaulting to EventDataExtensions.Track (which calls CreateTraceTelementry & client.Track())

Would it make sense for DiagnosticSourceTelemetryModule to also provide a constructor that supported a caller-provided OnEventWrittenHandler? Eg, if I wanted to log events instead of traces. Or, #111 (which introduced this to EventSourceTelemetryModule), discussed needing this for handling nested EventData - similar reasoning could apply to DiagnosticSourceListenerSubscription.OnNext & event.Value

[SergeyKanzhelev]

DiagnosticSourceTelemetryModule is a special module. It uploads error logs from SDK for self-monitoring and troubleshooting. We have some dependencies on form of produced telemetry from it.

Why do you want to modify the format of error messages? What is your scenario?

[rggammon]

In my particular case, I am logging from an assembly that does not depend on asp.net core. My end goal is to 1) have a way to log custom events to AI and 2) not directly depend on TrackEvent, but log via one of the built-in .net diagnostics sources - EventSource / DiagnosticsSource / TraceSource

I can see how I can get there via EventSourceTelemetryModule + OnEventWrittenHandler (or write a custom telemetry module) - this is probably what I will do.

I was considering DiagnosticSourceTelemetryModule as well, for its ability to accept complex types (since they don't get serialized & sent cross-process), but this is not critical - eg: I'd prefer to use EventSourceTelemetryModule vs a fork of DiagnosticSourceTelemetryModule

I think of TraceSource as being optimized for unstructured logging, eg: having a trace listener call TrackEvent seems like the wrong path.

So, it seems like EventSourceTelemetryModule is my best choice here? Feel free to close, unless we see a path forward here with DiagnosticSourceTelemetryModule .

[SergeyKanzhelev]

Oh, I mistaken DiagnosticsSourceTelemetryModule with DiagnosticsTelemetryModule.

Yes, this callback will be useful.

[SergeyKanzhelev]

Do you want to send a PR to implement it?

[SergeyKanzhelev]

BTW, there is some work going on to do similar thing for dependency telemetry. In more centralized fashion. See this microsoft/ApplicationInsights-dotnet#788. Would similar approach be better for Logs?

CC: @lmolkova

[rggammon]

Looked at this & the related design discussion at microsoft/ApplicationInsights-dotnet-server#587 - in this case the idea is to translate events from the http diagnostics source into TrackDependency, attaching some extra headers of interest.

I don't think DiagnosticsSourceTelemetryModule is being used in this case? Eg: they would have written their own listener to translate http DepedencySource -> TrackDependency

I can see a few possible paths forward -

1. I can switch to EventSourceTelemetryModule which allows for plugging in custom OnEventWrittenHandler hander
2. PR where DiagnosticsSourceTelemetryModule gets a constructor with OnEventWrittenHandler, working the same way as EventSourceTelemetryModule - happy to contribute a PR for this, the work done on EventSourceTelemetryModule would serve as a good example.
3. Further generalize OnEventWrittenHandler so that it could be used in the scenario described in Support adding arbitrary HTTP response headers from dependencies ApplicationInsights-dotnet-server#587 - eg: if the event comes from http response diagnostics source, the customer-provided OnEventWrittenHandler handler could track the event in AI as dependency & attach specific headers as properties.

At first glance, 2 & 3 seem similar? eg: If OnEventWrittenHandler takes diagnostics source name, event name, payload, and ai telemetry client, the logic would special case the http response source & TrackDependency.

https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md

[SergeyKanzhelev]

I think option 2 is great for now. Let's see how generalization of dependency approach will play out before expanding it to logs.