我是否应该为每个系统应用程序或每个环境提供应用程序洞察资源?

IWr*_*pps 3 asp.net-mvc azure azure-application-insights

我有一个由 2 个应用程序组成的系统WebApi,其中 1MVCWebApi应用程序充当STS,主MVC站点仅加载angular。这些将在 中托管azure。我是否应该AppInsights为每个环境中的每个组件拥有 1 个资源(4 个应用程序 * 3 个环境 = 12 个 AppInsights 资源),或者我是否应该为每个环境只拥有一个资源,并在一个环境中的所有不同应用程序之间共享密钥环境,以便我的所有遥测最终都在一个“桶”中?

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

Joh*_*ner 5

编辑:2021 年 11 月,距离我上次回答这个问题已经过去了 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 (来自文档)

何时使用单个 Application Insights 资源

对于部署在一起的应用程序组件。通常由单个团队开发,由同一组 DevOps/ITOps 用户管理。

  • 默认情况下,是否可以在所有指标中聚合关键绩效指标 (KPI),例如响应持续时间、仪表板中的故障率等(您可以选择在 Metrics Explorer 体验中按角色名称进行细分)。
  • 如果不需要在应用程序组件之间以不同方式管理 Azure 基于角色的访问控制 (Azure RBAC)。
  • 如果您不需要组件之间不同的指标警报标准。
  • 如果您不需要以不同的方式管理组件之间的连续导出。
  • 如果您不需要在组件之间以不同方式管理计费/配额。
  • 如果可以让 API 密钥对所有组件的数据具有相同的访问权限。10 个 API 密钥足以满足所有这些需求。
  • 是否可以在所有角色中使用相同的智能检测和工作项集成设置。

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

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

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

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

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

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

  • 如果环境确实是“实例”,那么您可能不需要为此单独的应用程序,但理想情况下,每个实例的遥测应该识别自身,以便您可以过滤/分组以查看某个特定实例是否正在执行异常操作