Support multiple tenants in a single Application Insights instance

Posted on Posted in Azure

As Appli­ca­tion Insights con­tin­ues to evolve, the abil­i­ty to slice and dice your data also con­tin­ues to increase. With an eye toward microser­vices, Microsoft recent­ly made added sup­port for mul­ti-com­po­nent appli­ca­tions to Appli­ca­tion Insights that allow you to aggre­gate all of your com­po­nents' teleme­try, but still fil­ter by indi­vid­ual ser­vices via the cloud ser­vice role name. But what if we have mul­ti­ple ten­ants using our appli­ca­tion and have archi­tect­ed our appli­ca­tion so each ten­ant gets their own ded­i­cat­ed set of ser­vices? How can we track teleme­try for each of those clients indi­vid­u­al­ly if desired, but still be able to get an over­all view of appli­ca­tion health and min­i­mize administration?

There are sev­er­al options, each with their own pros and cons:

  • We could iso­late each ten­ant into their own Appli­ca­tion Insights resource and use OMS to get an aggre­gat­ed dash­board view of all our tenants
  • We could hijack the cloud ser­vice role name to indi­cate the ten­ant name using the lat­est Appli­ca­tion Insights changes men­tioned previously
  • We could fil­ter by request host names if they're deter­min­is­tic of the tenant

Instead, let's look at a sim­pler solu­tion that requires min­i­mal effort and has min­i­mal drawbacks.

Add Custom Properties to Telemetry

Beyond just log­ging cus­tom events and cus­tom met­rics, Appli­ca­tion Insights also offers the abil­i­ty to add cus­tom prop­er­ties to all out­bound teleme­try, even the default sys­tem-gen­er­at­ed teleme­try. Our goal is to add a Ten­ant prop­er­ty to all out­bound teleme­try that will allow us to fil­ter for and aggre­gate by indi­vid­ual ten­ants in Appli­ca­tion Insights . We'll start by cre­at­ing a cus­tom serv­er-side Teleme­try Proces­sor in our web application.

This proces­sor will read the Ten­ant­Name prop­er­ty from app set­tings and add it to all teleme­try as a cus­tom prop­er­ty named Ten­ant before mov­ing on to the next proces­sor in the chain. Next, we'll tell Appli­ca­tion Insights to start using our proces­sor by adding it to our ApplicationInsights.config file.

After we pub­lish our changes, all serv­er-side teleme­try from this appli­ca­tion will con­tain a Ten­ant prop­er­ty filled in with what­ev­er val­ue is in the config.

Seeing Tenant Data in Application Insights

Now that the data's stored, we will be able to fil­ter on Ten­ants as if they were any oth­er prop­er­ty on the telemetry.

We can also group by the Ten­ant in the Met­rics Explor­er to see our met­rics bro­ken out by each Tenant.

Note that there does seem to be a delay between the new cus­tom prop­er­ty appear­ing in your teleme­try and the new cus­tom prop­er­ty being avail­able as an option to group by or fil­ter on. If you don't see your cus­tom prop­er­ty avail­able in the drop-down lists, even after refresh­ing, come back a lit­tle bit lat­er and try again.

While we only added serv­er-side teleme­try pro­cess­ing in the exam­ple above, the the same basic con­cept also applies to client-side teleme­try. We can eas­i­ly cre­ate a new Teleme­try Ini­tial­iz­er in our Appli­ca­tion Insights JavaScript snip­pet. As long as the ten­ant data is pop­u­lat­ed on the same cus­tom prop­er­ty (Ten­ant­Name in this exam­ple), it will seam­less­ly inte­grate with our per-ten­ant serv­er-side telemetry.

Leave a Reply

Your email address will not be published. Required fields are marked *