Clarification on guidance on exceptions using etw/eventsource to ApplicationInsights

[kstrauss]

Looking at issue #92 and the answer provided.

Option 1:

One is to use EventSource.Write method https://msdn.microsoft.com/en-us/library/system.diagnostics.tracing.eventsource.write(v=vs.110).aspx This should work well if you are using .NET Core, although I will be honest--I haven't tested it. Unfortunately with full framework there is a bug in the framework that prevents EventFlow from reading the event level correctly, so it is not a recommended way if you are using full (desktop) framework.

I already use eventsource.write with error level for those that have exceptions. I am not seeing these passed with with exception metadata with ApplicationInsights output. You are saying that this is a bug in .net ??

Option 3:

Yet another option is to use custom EventFlow input. That should be not nearly as troublesome as a custom output for AI. I think you could even integrate it with your EventSource e.g. by making the EventSource implement IObservable and using [NonEvent] methods to raise events that carry exception objects. This way you will have just one logging API, your EventSource, for the application to use.

So I would have to modify each eventsource to be something like:

public sealed class TestEventSource : EventSource, IObservable<EventData>
    {
        public static TestEventSource Log = new TestEventSource();
        /// <summary>
        /// Generic lets us write a debug message that is not associated with an
        /// event
        /// </summary>
        /// <param name="Message"></param>
        [Event(1, Keywords = Keywords.Debug)]
        public void DebugTrace(string Message)
        {
            WriteEvent(1, Message);
        }
        [NonEvent]
        public void SubscriptionToGESDropped(String serviceName, String gesInputStreamName, String dropReason, Exception exc = null)
        {
            SubscriptionToGESDropped(serviceName, gesInputStreamName, dropReason, FormatExceptionAsString(exc));
        }

       public IDisposable Subscribe(IObserver<EventData> observer)
        {
               //how should i retrofit things here, so I don't need to touch event method/event on 
        }
}

but my question would then center around, how would i retrofit eventsource, so i didn't have to go and touch each method without changing my baseclass and creating an overload for writeEvent? If I'm going to do that why wouldn't I rewrite Eventflow from the beginning or use say applicationInsights directly from the beginning? This doesn't save me really time from rewritting the logging in general.

Am I understanding the two options correctly?

[karolz-ms]

Hey Karl, sorry for late reply

To say more about feasibility of option 1, it would be really helpful if you could share a simple example/gist illustrating what you are trying to do and what you expect vs. what is actually happening.

Regarding option 3, you would do the following

1. Add a EventFlowSubject<EventData> subject member variable
2. In Subscribe() you would call this.subject.Subscribe(observer)
3. In SubscriptionToGETDropped() (and other methods that need to raise an event that should produce Application Insights exception information), you would create an EventFlow EventData object, add a property with a value set to the passed Exception instance, and call this.subject.OnNext(EventData).

Take a look at one of the inputs in EventFlow, e.g. Serilog input, in particular the Emit method and it should make things clearer.

Note that you would also need to ensure that your EventSource is added as an input to the EventSource pipeline. You could do this through configuration, registering your EventSource as a custom input, or just create the whole pipeline programmatically like the tests do.

Using Application Insights directly is yet another option, like you said, but that requires changing your logging API so it is not a very appealing perspective.

Hope this helps--let us know!

[karolz-ms]

Closing this issue for now, but please re-open as necessary