[BUG] Unable to Prevent Dependency Logging

[jdurr1]

SDK Version: 3.3.4

Problem: We have this application insights version installed on 5+ SPFx React web parts on SharePoint and each of them are logging millions of rows to the dependencies table in Application Insights in Azure costing us thousands of dollars a month to support. We primarily use App Insights in these apps to track custom events only and would prefer to isolate auto-collection to a separate application separate from these (or not auto-collect at all). What would be the best configuration to accomplish this for these apps?

This was not an issue in previous versions of the SDK but now we need a configuration ASAP to filter/prevent these logs from occurring or we will have to cease custom event/click tracking all together. We also attempted previous versions of the SDK with no luck in preventing dependencies from logging.

Below is a code sample of configurations I have tried so far attempting to primarily prevent dependency tracking as that is the most costly logging occurring.

// Intialize Application Insights
let appInsights = new ApplicationInsights({
  config: {
    instrumentationKey: AppSettings.appInsightsConnectionString,
    disableFetchTracking: true,
    disableAjaxTracking: true,
    disableXhr: true
  }
});

// Telemetry initializer to filter out dependencies and page views  
const telemetryInitializer = (envelope: ITelemetryItem) => {  
  const baseType = envelope.baseType;  
    
  // Check the telemetry item type  
  if (baseType === 'RemoteDependencyData') {  
    return false; // Return false to exclude this item  
  }  
  
  return true; // Return true to allow the item through  
};  
// Add the telemetry initializer  
appInsights.addTelemetryInitializer(telemetryInitializer);
appInsights.loadAppInsights();

I've also attempted a dependency listener and initializer that return false to prevent these logs from occurring with no luck shown below:

// add dependency initializer to prevent dependencies from being sent to app insights
appInsights.addDependencyInitializer(() => {return false;});
appInsights.addDependencyListener(() => {return false;});

[MSNev]

These are all valid ways to stop the dependency requests from getting reported where

• The configuration items stop the code from "hooking" the fetch and XMLHttpRequest so they are the uber ways to stop it
• The Dependency Listeners provide a finer grain level (just for dependency requests) so you can choose which ones you want to report
• And finally, EVERYTHING goes through the telemetry initializer and returning false will drop the event on the floor.

As none of these are working (which are all in different locations), it seems to me that the code you have above initializing the SDK is actually not the code that is sending the dependency requests. ie. There is another SDK instance which doesn't have any of these options getting initialized.

Which would also mean that without the above "options" (to disable the requests) you would actually be getting multiple dependency events getting reported (as each SDK instance will be hooking the fetch and XMLHttpRequest and running it onw hooks).

How to diagnose / find the SDK instance.

I wish I could say just go here, but its never that simple. I generally start by using the F12 Network tab looking for the call to the track endpoint and then

• Follow the code link in the "initiator" column back to the code that "sent" the request, but this is not always useful as you can "create" and initialize multiple instances of the SDK from the same code and this will all point back to the same instance
• If not the above, then I will check the ourbound JSON for the sdk version to make sure it's the version I expect (as you can also have multiple versions of the SDK getting loaded (from the CDN) and the old v2.x will actually overwrite each other (we change the default approach for v3 so the first v3 version loaded is never replaced by another v3 version (but v2 (or v1) will still overwrite it)
• If still nothing, then it's "Debugging" (breakpoint) time, where using the "initiator" links obtained from the networking tab about, trace this back to the processTelemetry function of the Sender (the code that "batches" all of the events and drop a breakpoint there. Once you run the code and this shows a "Dependency" event (assuming you still have the above "disabling") you should then be able to go down the stack trace and find where the initialize function got called from (which would be from a call to loadAppInsights (most likely) but this could be getting initialized from the SDK loader or the code called when loaded from the CDN or from you code above (although I don't believe that would be the case based on the config you have).

And all this would just be it identify "where".

If we "assume" that its a "global" (loaded from the CDN) instance, then depending on the version getting loaded you would just reference the global appInsights instance (window.appInsights) and "add" a telemetryInitializer (should be available in for a v2 instance), or if it's v2.8.4 or later you could add a dependency listener. And if it's a v3.x we added full dynamic configuration support so you can actually "change" the disableXXXX configurations "after" initialization (except instead of using the "initialization" root option you will have to reference the runtime extension config (appInsights.config.extensionConfig.AjaxDependencyPlugin.disableXXXX -- we populate and make all the internal "default" values since v3.x onto this "shared" config object now, so if you inspect it you will be able to "see" the current configuration, this is also one way to "check" that you config used during initialization (calling the loadAppInsights) was applied).

[jdurr1]

@MSNev thanks so much for the great explanation on how the system works with multiple initiations of App Insights on a web page. This was very insightful and did lead me to discover that we had around 6 initializations with 3 of the 6 not having the additional configuration settings and dependencies filtering. After all applications were updated to the correct settings, we no longer see dependencies being logged and have significantly reduced our cost on App Insights.

Also the note about looking for the "track" event in the Network tab is was very helpful in tracking the dependencies logging events live in the browser.

We're back in a affordable/working state but are a bit perturbed why this logging was turned on by default. Are there some notes from the change or version that resulted in this auto-logging we could look into? We had to take on a lot of cost while figuring out this issue and want to make sure something like this doesn't happen again. Thank you again for the help

[MSNev]

Glad to hear that this was helpful.

In term so of "why" the dependency tracking is enabled by default, this has been the case for a very long time (well before I joined the team -- so years and I believe was also enabled in v1 (it got deprecated around the time I joined the team which was around v2.2.0 from memory -- so long ago now).

The reason this is on by default is so that for users enabling Application Insights integration its a simple matter of having the SDK loaded.

[github-actions[bot]]

This Issue will be closed in 30 days. Please remove the "Stale" label or comment to avoid closure with no action.