Application Insights Implementation - Recommendations Needed RRS feed

  • Question

  • Some questions related to best practices around implementing Application Insights for a set of applications: 

    1. How does one provision the Application Insights in an environment with a large portfolio of applications? Should there be one instance of App Insights for every logical group of applications or is it recommended to have a 1:1 mapping between an application and Application Insights instance.

    2. In terms of the environments, I am assuming it makes sense to have one instance of App Insights for each environment such as DEV, QA and PROD. Is this is the recommendation? 

    3 While creating an instance of Application Insights in the Azure Portal, the drop down requires the selection of the type of application as .NET, Java. Node.js or General. What is the impact of this selection on the instance of Application Insights that is created? 

    Tuesday, April 2, 2019 10:33 AM

All replies

  • Vikram,


    Edit:  Added additional information from PG as promised.


    Should I use single or multiple Application Insights resources?

    Use one instance of Application Insights for a portfolio of applications (separated by business systems), and 1:1 mapping for development, test, and release, as well as for independent applications.


    "Use a single resource for all the components or roles in a single business system. Use separate resources for development, test, and release versions, and for independent applications."


    Additionally, the product group had this to say (and will be updating the FAQ above shortly):


    "We recommend using different AI resources for different environments. In general, we recommend a different AI resource for every independently deployable application component. You can use either model however, single or multiple AI resources – it does *NOT* affect Application Map or the Transaction Diagnostics experiences."

    Use single AI resource:
    For application components that are deployed together. Usually developed by a single team, managed by the same set of DevOps/ITOps users.
    If it makes sense to aggregate KPIs such as response durations, failure rates etc., across all of them by default (you can choose to segment by role name in the Metrics Explorer experience).
    If there is no need to manage RBAC differently between the application components.
    If you don’t need metrics alert criteria that are different between the components.
    If you do not need to manage continuous exports differently between the components.
    If you do not need to manage billing/quotas differently between the components.
    If it is okay to have an API key have the same access to data from all components. And 10 API keys are sufficient for the needs across all of them.
    If it is okay to have the same smart detection and work item integration settings across all roles.

    Other things to keep in mind:
    You may need to add custom code to ensure that meaningful values are set into the “Cloud_RoleName” attribute. Without meaningful values set for this attribute, *NONE* of the portal experiences will work.
          o For Service Fabric applications and classic cloud services, the SDK automatically reads from the Azure Role Environment and sets these. For all other types of apps, you will likely need to set this explicitly.
    Live Metrics experience does not support splitting by role name.


    Dmitry has answered this question before, and his answer is worth checking out as well:


    Our cross-app experiences such as AppMap and End-End transaction view are built with the data split across multiple resources in mind but will work with data in a single resource (for instance, if cloud role name is defined in that telemetry to support App Map in single resource).

    Our in-app experiences such as Failures/Performance were initially created to work best if one Application Insights resource was created per service deployment (regardless of the number of instances in that deployment), but it expects that different environments/components are separated into their own resources (because the view becomes cluttered and cumbersome to investigate performance if all data is in one resource).


    Should I use separate resources for Dev, QA, and Prod?

    We answered this in the previous question (use separate resources for development, test, and release), but we have documentation that will guide you through this process:


    "When you are developing the next version of a web application, you don't want to mix up the Application Insights telemetry from the new version and the already released version. To avoid confusion, send the telemetry from different development stages to separate Application Insights resources, with separate instrumentation keys (ikeys). To make it easier to change the instrumentation key as a version moves from one stage to another, it can be useful to set the ikey in code instead of in the configuration file"



    What is the impact of selecting the type of application (.NET, Java, Node.js, General) in the portal?

    Historically, different app types would have had different tabs that were displayed.  As an example, Java didn't support Live Metrics so the Live Metrics tab wouldn't be shown if you selected Java.  This is no longer the case, however, and you should have the same experience regardless of which app type you choose.  We recommend choosing .NET for the full experience just to be on the safe side (and there is a possibility that this UI element will be removed in the future).

    Wednesday, April 3, 2019 8:10 PM