Wcf DependencyTracking and regular Dependency Tracking TelemetryModule

[mlooise]

Hi,

I have question regarding the two dependency tracking modules that exist in both AI.WCF and regular Application Insight. First of all I am wondering whether the two modules are built to live together? I have read some comments that the two are not working together very well .(#72). It this still the situation as of now? It looks to be a very viable scenario that one would need both WCF and SQL depenedency tracking.

What I do see is that I get double dependencies tracked if I enable both. (WCF Channel Open, WCF Service Call, WCF Service). WCF Service is originating from the original AI dependency tracking and the others by AI.WCF.

I could ofcourse disable the default Dependency module but losing tracking of non-wcf dependencies (like SQL, REST). Is there any (future) way to have the best of both worlds (no double dependencies but still trace SQL and REST) ?

Regards,

Martin

[tomasr]

As you have noticed, yes, this duplication of requests is still an issue (actually, in some cases it can go beyond that, depending on what bindings you're using).

There's no way to solve this right now without some sort of common agreement and changes between the core SDK and the WCF SDK, and frankly I'm still trying to figure out what that could be.

@SergeyKanzhelev Is there anyone from the Dependency tracking team we could discuss this feature request with?

[SergeyKanzhelev]

@TomMilos is working on collecting dependencies for non-HTTP Azure storage API calls. I think the right way to do it will be to instrument Azure SDK itself. However once instrumented it may pose the same challenge of duplicating dependency calls collection. So I think this is a common problem needs solving.

I was thinking of marking the current thread as already tracking dependency. So enclosed dependency call will not be tracked. It may cause some problems in case we are missing the end of dependency call (like for System.Net http tracking via DiagnosticsSource in case of exception) or when dependency stopped on unrelated task by terminating the task or something of this nature.

CC: @AlexBulankou

[SergeyKanzhelev]

@mlooise - do you like how WCF depednencies being collected (apart from duplication)? I was thinking we need to move it to the main dependency tracking module so feedback is greatly appreciated before we'll start.

[mlooise]

@SergeyKanzhelev I am quite pleased with the WCF clientside-dependency tracking. For us it is far more usefull to see what specific operation is called on a .svc endpoint instead of just the 'POST'. For us a lot of operations are grouped into one WCF service so it is usefull to see which specific method is called and how long it took to complete. So for me a thumbsup on this implementation. I would be in favour of adding it to the 'main' dependency module as this would also solve the duplication issue.

@tomasr
I have for now solved the duplication in a different way by creating a custom filter. I have implemented the ITelemetryProcessor interface and I filter out the dependencies with type.name "WCF Service". The AI.WCF implementation uses different types like "WCF Service Call" and "WCF Channel Open", so these will not be filtered out. In this way I can still enable the normal dependency module to track SQL and http calls to REST services, but let WCF specific stuff be handled by AI.WCF. It seems a quick fix for us right now...

/// <summary>
    /// Custom TelemetryProcessor to exclude certain dependency types from sending to AI
    /// </summary>
    public class DependencyTelemetryFilter : ITelemetryProcessor
    {
        /// <summary>
        /// The next item in the chain
        /// </summary>
        private ITelemetryProcessor Next { get; set; }

        /// <summary>
        ///Comma seperated string of types to exclude
        /// </summary>
        public string TypeNames { get; set; } = "WCF Service";

        /// <summary>
        /// Link processors to each other in a chain.
        /// </summary>
        /// <param name="next"></param>
        public DependencyTelemetryFilter(ITelemetryProcessor next)
        {
            Next = next;
        }

        /// <summary>
        /// Process this item. Return if the type is contained in the list of filtered Typenames, otherwise process next.
        /// </summary>
        /// <param name="item">TelemetryItem to inspect</param>
        public void Process(ITelemetry item)
        {
            var dependency = item as DependencyTelemetry;
            if (!string.IsNullOrEmpty(dependency?.Type))
            {
                if (TypeNames.Split(',').ToList().Exists(t => dependency.Type.Equals(t)))
                    return;
            }
            Next.Process(item);
        }

Would this also be an option for now? Provide such a class in the AI.WCF package for people to use? It needs only one line of configuring:

<TelemetryProcessors>
  <Add Type="my.namespace.DependencyTelemetryFilter, my.namespace">
      <TypeNames>WCF Service,WCF Channel Open</TypeNames>
  </Add>
</TelemetryProcessors>