Auto MongoDB telemetry in Application Insights— Too verbose? — Quick Note

At Wescover we are using the App Insights Node.js library to track and report server side metrics. Being quite l̶a̶z̶y̶ efficient we mostly left the library to pursue its out-of-the box defaults.

Valuable Defaults

Among those defaults is the oh-so-useful MongoDB telemetry reporting. Basically, the library looks for the mongodb and mongodb-core packages and monkey patches them to capture calls.

The result is useful both on the “Application Map” view and being able to view the distribution of operations and their performances.

Pretty good for almost 0 effort.

Lately we started working against a MongoDB replica-set to improve overall availability. We soon noticed that a spike in dependency tracking with most of the tracked calls to the admin DB with an operation called ismaster.

The ismaster operation is part of the mongodb driver’s work at determining the status of the replica set and discovery of additional node. Important, but irrelevant to our application domain.

This was unacceptable, we considered to either fall out of the defaults and track the MongoDB calls with some custom code but eventually found a better solution.

Telemetry Processors To The Rescue

The AppInsights library exposes a useful hook point called a Telemetry Processor. In essence it’s a piece of custom handler code that gets to intercept, modify, or omit tracking calls produced by the library (automatically or manually).

The basic setup follows:

The processor is a function that accepts an envelope and context parameters, can modify them and returns true to report the event or false to drop it. In the example above we modify nothing, just dropping the requests we do not care about.

Another useful example of a processor which does modify the tracking payload is in the following code which shows how we inject a bot-type custom property to (automatically reported) web requests. We do not want to store the entire user-agent strings (and AppInsights by default do not store those anyway). We rather just want to know which of the requests originated from known bots and who are those bots.

Hope that helped!