asp.net-mvc - 我是否应该为每个系统应用程序或每个环境提供应用程序洞察资源？

Question

我的系统由 2 个 WebApi 应用程序和 1 个用作 STS 的 MVC/WebApi 应用程序组成>，并且主 MVC 站点仅加载 Angular。这些将托管在 azure 中。我是否应该为每个环境中的每个组件拥有 1 个 AppInsights 资源(4 个应用程序 * 3 env = 12 个 AppInsights 资源)，还是每个环境只拥有一个并共享在一个环境中跨所有不同的应用程序键入 key ，以便我的所有遥测最终都在一个“存储桶”中？

如果任何具有遥测/分析经验的人都可以提供一些意见，那将会有很大的帮助。

Answer 1

编辑:11/2021 鉴于我上次回答这个问题已经过去了大约 5 年，很多事情都发生了变化。现在很多事情都不同了。

2020/2021 年，我们开展了将 Log Analytics 和 Application Insights 结合起来的工作，因此现在您可以拥有 N 个应用程序见解资源，它们全部指向一个单个工作区。这使得跨许多资源的合并/查询变得更加简单，简化了许多其他事情，例如计费，因为您需要为一个工作区而不是 N 个应用程序见解资源付费，等等。Log Analytics 还有很多功能当您使用日志分析支持的设置时，它们将受到支持。请参阅https://learn.microsoft.com/en-us/azure/azure-monitor/app/convert-classic-resource

现在有一个 azure 文档页面讨论此主题: https://learn.microsoft.com/en-us/azure/azure-monitor/app/separate-resources(来自文档)

When to use a single Application Insights 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 Key Performance Indicators (KPIs) such as response durations, failure rates in dashboard 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 Azure role-based access control (Azure 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.

2016 年答案(带删除线):取决于你，而且相当主观。需要考虑的事项:

• 这实际上取决于您希望能够一起分析哪些数据。。如果您希望能够通过所有层跟踪相同的用户/请求，您可以为所有层使用一种资源，并通过所有请求/等传递诸如相关性 ID 之类的内容，以便能够看到一些链式 react 所有层。跨资源/资源之间进行分析很复杂，通常需要使用连续导出之类的工具以及门户之外的其他工具

• 但是，如果不同的团队拥有不同的层，他们可能希望以不同的方式进行遥测，因此他们可能每个人都想要自己的“应用程序”。

• 每个应用程序允许拥有的不同命名自定义属性和指标的数量有限制(目前每个应用程序有 200 个？)，因此如果您将它们全部混合在一起，您可以使用快速设置自定义属性。 (customDimensions 字段现在是 json，因此在 2021 年这实际上是不正确的)

• 每个应用程序都有限制，并且每个应用程序可以进行的网络测试数量也有限制。因此，如果您对所有环境/层仅使用一个应用程序，并且其中一个层变得疯狂，它可能会限制您的所有数据，并且您可能会丢失遥测数据，直到疯狂消失并解除对该组件的限制。

• 如果您的情况中的“环境”是开发/测试/登台/生产，您可能确实希望将它们分开，这样来自开发人员执行随机崩溃操作的数据就不会污染您的生产遥测。

• 如果环境确实是“实例”，那么您可能不需要为此使用单独的应用程序，但每个实例的遥测数据理想情况下应该能够识别自身，以便您可以过滤/分组看看某个特定实例是否正在做一些不寻常的事情