Whenever people ask me this question, I tend to struggle to give a short and concise answer.
Unfortunately this is one of these dreaded “it depends” situations, where it can be one or the other.
Where we need to start, is by defining what “the app” in question actually is.
Is it a web app resource in Azure? Is it a logical application? Is it a shared component used by many applications? Is it a product?
One scenario where the answer is fairly clear is when it comes to deployment environments. There are good reasons for keeping environments completely separate and the same should be true for application insights resources. Read More ->
There is also a scenario where consolidating more than one telemetry source into one AI resource makes sense. This works well in the case where we are dealing with a logical self contained application. (all telemetry sources are part of a known chain of actions or a set of known chains that all feed into the same app) Microsoft calls this the multi role scenario.
Finally, multiple instances of the same service should always use the same Application Insights resource and can use the cloudRole property to identify themselves as a particular instance.
If your app does not fall into one of those three boxes, then it gets a bit more complicated. There are benefits and drawbacks to both running one instance of app insights for every component of a service and for running just one instance for the whole service.
Here are a few things to think about:
Arguments for having a shared AI resource
- You can query across different services in AI Analytics
- A similar behaviour can be implemented with a custom correlation ID (if rolling up into OMS or another aggregator)
- If cloud_RoleName is used you see the different components in one application map
- The AI resource becomes the telemetry collector for a logical application
- If your services are used in the context of a particular application (and not shared across different functions) then the application map will be useful in debugging the app as a whole and visualising the components and dependencies through application map
Arguments for having one AI resource per service
- If you feed the telemetry for many services into one AppInsights resource you may start hitting throttling limits
- If you are going for a micro services approach, you may choose – from an architectural perspective – to keep all your services as self-contained as possible – including their telemetry
- From a deployment perspective, you may prefer to deploy all your services (including their app insights resources) independently
- This – however – means that you are going to need to consolidate telemetry in OMS or an equivalent product to query across services
- Form a billing perspective, you may want to have the ability to charge the cost of different services to different cost centres
- This is only possible if the components are separate