应用程序见解实施 - 需要的建议 [英] Application Insights Implementation - Recommendations Needed
问题描述
有关围绕为一组应用程序实施Application Insights的最佳实践的一些问题：
1.如何配置Application Insights一个拥有大量应用程序的环境？应该是每个逻辑应用程序组都有一个App Insights实例，还是建议在应用程序
和Application Insights实例之间建立1：1映射。
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。就环境而言，我假设为每个环境（例如DEV，QA和PROD）提供一个App Insights实例是有意义的。这是推荐吗？
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在Azure门户中创建Application Insights实例时，下拉列表需要选择应用程序类型为.NET，Java。 Node.js或General。此选择对创建
的Application Insights实例有何影响？
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?
推荐答案
Vikram，
Vikram,
编辑： 根据承诺从PG中添加了其他信息。
Added additional information from PG as promised.
我应该使用单个还是多个Application Insights资源？
将Application Insights的一个实例用于应用程序组合（由业务系统分隔），并为开发，测试和发布以及独立应用程序使用1：1映射。
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.
https://docs.microsoft.com/en-us/azure/azure-monitor/app/troubleshoot-faq#应该使用 - 单一或多个应用程序洞察 - 资源
"在单个资源中使用单个资源用于所有组件或角色业务系统。为开发，测试和发布版本以及独立应用程序使用单独的资源。"
"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):
"我们建议为不同的环境使用不同的AI资源。通常，我们建议为每个可独立部署的应用程序组件使用不同的AI资源。您可以使用任一模型，单个或多个AI资源 -
它*不*影响应用程序地图或交易诊断体验。"
使用单个AI资源：
用于一起部署的应用程序组件。通常由一个团队开发，由同一组DevOps / ITOps用户管理。
• 如果默认情况下在所有这些方面聚合KPI（例如响应持续时间，失败率等）是有意义的（您可以选择按Metrics Explorer体验中的角色名称进行细分）。
• 如果不需要在应用程序组件之间以不同方式管理RBAC。
• 如果您不需要不同的指标警报标准组件之间。
• 如果您不需要管理组件之间的连续导出不同。
• 如果不这样做需要在组件之间以不同方式管理账单/配额。
• 如果可以让API密钥对所有组件的数据具有相同的访问权限。 10个API密钥足以满足所有这些需求。
• 如果可以在所有角色中使用相同的智能检测和工作项集成设置。
要保留的其他内容记住：
• 您可能需要添加自定义代码以确保有意义的值被设置到"Cloud_RoleName"属性中。如果没有为此属性设置有意义的值，则门户体验的* NONE *将起作用。
    o 对于Service Fabric应用程序和经典云服务，SDK会自动从Azure角色环境中读取并设置这些内容。对于所有其他类型的应用，您可能需要
才能明确设置。
• 实时指标体验不支持按角色名称进行拆分。
"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之前已回答过这个问题，他的回答也值得一试：
Dmitry has answered this question before, and his answer is worth checking out as well:
我们的跨应用程序体验，例如AppMap和End-End事务视图都是基于多个资源分开的数据构建的，但可以使用单个资源中的数据（例如，如果在该遥测中定义了云角色名称以支持单个资源中的
应用程序地图。
我们最初创建了失败/性能等应用内体验，以便在一个Application Insights资源中发挥最佳效果是按服务部署创建的（无论该部署中的实例数量是多少），但它希望将不同的
环境/组件分离到自己的资源中（因为如果所有数据都是如此，则视图变得混乱且难以调查性能在一个资源中。）
我应该为Dev，QA和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:
https://docs.microsoft.com/en-us/azure/ azure-monitor / app / separate-resources
"当您开发下一个版本的在Web应用程序中，您不希望混淆新版本和已发布版本的Application Insights遥测。为避免混淆，请从不同的开发
阶段发送遥测数据，以使用单独的检测键（ikeys）分离Application Insights资源。为了在版本从一个阶段移动到另一个阶段时更容易更改检测密钥，在代码中而不是在配置
文件中设置ikey非常有用"
选择应用类型会产生什么影响（.NET，Java，门户网站中的Node.js，General）
从历史上看，不同的应用类型会显示不同的标签。 例如，Java不支持Live Metrics，因此如果您选择Java，则不会显示Live Metrics选项卡。 但是，情况已经不再如此，无论您选择哪种应用类型，
应该具有相同的体验。 我们建议选择.NET以获得完整的体验，以保证安全（并且将来可能会删除此UI元素）。
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).
这篇关于应用程序见解实施 - 需要的建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
