率这篇文章

应用程序洞察是用于应用程序级检测的Azure Monitor的组件。它从应用程序基础设施(如Web服务器)收集遥测数据,应用服务,Azure功能应用,以及应用程序代码。在这篇文章中,我们将讨论如何通过几个关键的方式实现应用程序洞察力的自动化:首先,通过在ARM模板中设置应用程序洞察实例;第二个,通过自动化脚本(包括Azure函数)将其连接到各种类型的Azure应用程序组件,应用服务,和API管理;第三,通过配置其智能检测功能,以可配置的方式发出自动警报。由于这是本系列文章中第一次部署插装代码,我们还将讨论一种可用于管理不同类型和级别的监控部署到不同环境中的方法。

这篇文章是一系列文章的一部分:

  • 第1部分通过描述我们应该为系统安装仪器的原因来介绍该系列,概述了Azure提供的一些主要工具,比如Azure Monitor,并讨论了为什么我们应该为我们的仪器和监控组件采用“基础设施作为代码”的心态。

  • 第2部分(本帖)描述Azure应用程序洞察力,包括主动检测和警报功能。它还概述了一种基于我们在不同环境中可能具有的需求部署仪表组件的模式,从短暂的开发和测试环境到生产环境。

  • 第3部分讨论如何发布自定义指标,通过应用程序洞察和Azure Monitor。自定义度量让我们可以丰富对我们的检测组件可用的数据。

  • 第4部分覆盖警报和度量警报的基础知识。Azure Monitor强大的警报系统是一个大主题,在这一部分,我们将讨论它是如何工作的,以及如何获取内置和自定义度量的警报。

  • 第5部分(即将推出)封面日志警报和资源健康警报,Azure Monitor提供的另外两种主要警报类型。日志警报让我们对进入应用程序洞察日志和日志分析工作区的信息发出警报,而当Azure本身出现可能导致停机或性能下降的问题时,资源健康状况会提醒我们。

  • 第6部分(即将)描述仪表盘。Azure门户有一个很棒的仪表板用户界面,我们的仪器数据可以作为图表提供。仪表盘也可以实现自动化,我将展示一些我在做这件事时学到的技巧。

  • 第7部分(即将推出)封面可用性测试,这使我们能够主动监视Web应用程序的潜在中断。我们将讨论部署和自动化单步(ping)和多步可用性测试。

  • 第8部分(即将)描述自动定标。虽然这并不完全是仪器本身,自动标度是建立在许多用于驱动警报和仪表板的相同数据之上的,自动缩放规则也可以自动化。

  • 最后,第9部分(即将推出)封面导出数据其他系统。可以自动导出Azure监视器度量和日志数据,与应用程序洞察数据一样,导出规则可以从自动化脚本中导出和使用。

设置应用程序洞察力

使用Azure门户或Visual Studio处理各种类型的资源时,应用程序洞察通常会自动部署。这在我们探索服务或测试东西时很有用,但到了构建生产级应用程序的时候,最好对每个组件的部署方式都有一些控制。可以使用ARM模板部署应用程序洞察力,这就是我们在这篇文章中要做的。

应用程序洞察是从ARM模板创建的简单资源。可以使用小ARM模板创建具有核心功能的实例:

关于此模板,需要注意以下几点:

  • 应用程序洞察仅在Azure区域的子集中可用。这意味着您可能需要将其部署到应用程序基础结构所在区域以外的其他区域。上面的模板包含一个参数来显式指定这个参数。
  • 您的Application Insights实例的名称不必是全局唯一的。与应用服务和Cosmos数据库账户等资源不同,应用程序Insights实例没有附加DNS名称,因此,如果多个实例位于不同的资源组中,则可以在多个实例中使用相同的名称。
  • 应用程序洞察力不是免费的。如果你有很多数据要摄入,你可能要付出巨大的代价。您可以使用配额如果你担心这件事的话。
  • 还有更多的选项,我们在这里不讨论。此文档页提供了进一步的详细信息。

部署应用程序洞察实例之后,它有一个仪表键它可用于将数据从应用程序发送到正确的Application Insights实例。可以通过门户和编程方式访问Instrumentation密钥,包括在ARM模板中。我们将在发布遥测时使用它。

发布遥测

有许多方法可以将遥测技术发布到应用程序洞察中。虽然我不会一一介绍,我将简要介绍一些将数据从应用程序获取到应用程序洞察力的最常见方法,以及如何使每一项自动化。

Azure函数

Azure函数内置了与应用程序洞察的集成。如果您通过门户创建一个Azure函数应用程序,它会询问您是否要设置此集成。当然,因为我们使用的是自动化脚本,我们必须自己做一点工作。神奇在于应用程序设置,应用灯光仪表键,我们可以连接到任何功能应用程序。这是一个ARM模板,它部署了一个Azure函数应用程序(以及相关的应用程序服务计划和存储帐户)。应用程序洞察实例,以及连接这两者的配置:

应用程序服务

如果我们使用asp.net将Web应用部署到应用服务中,我们可以直接使用ASP.NET集成。事实上,这适用于许多不同的托管环境,将在下一节中进行描述。

如果你有一个不使用ASP.NET的应用服务,不过,您仍然可以通过使用应用服务扩展。扩展通过在Web服务器中安装一些额外的逻辑来增强应用程序服务的内置行为。应用程序洞察力有一个这样的扩展,我们可以使用ARM模板配置它:

如你所见,类似于Azure函数示例,这个应用灯光仪表键此处用于将应用程序服务与Application Insights实例链接。

一句警告——我发现在第一次部署模板时,站点扩展ARM资源的部署并不总是正确的。如果第一次部署时出现错误,再试一次,看看问题是否消失了。我试过了,但从未完全理解为什么会发生这种情况或如何阻止它。

ASP.NET应用程序

如果有一个ASP.NET应用程序在应用程序服务或其他地方运行,您可以在项目中安装Nuget包,以收集应用程序细节遥测。此过程记录在这里。如果你这样做,您不需要安装上一节中的App Services扩展。确保在配置设置和然后从应用程序代码将其传递给应用程序洞察力

API管理

如果您有一个Azure API管理实例,您可能知道,这也可以将遥测技术发布到应用程序洞察中。这允许通过请求处理管道全程监控请求。说到自动化,Azure API管理对ARM模板有很好的支持,它的Application Insights集成也不例外。

在高层次上,我们需要做两件事:首先,我们创建了一个记录器资源建立与应用洞察的API管理范围的联系;其次,我们创建了一个诊断的资源指示我们的API向我们配置的Application Insights实例发送遥测。我们可以创建一个诊断的特定API或覆盖所有API的资源。

这个诊断的资源包括采样率,这是应将其遥测发送到Application Insights的请求的百分比。这个功能有很多细节需要注意,例如,性能影响以及抽样可以减少影响的方式。我们不会在这里讨论的,但是我鼓励您阅读Microsoft文档中的更多详细信息。使用此功能之前。

下面是一个示例ARM模板,它部署了一个API管理实例,应用程序洞察实例,以及将遥测从每个请求发送到应用程序洞察的配置:

智能检测

Application Insights提供了一个名为智能检测。Application Insights会在您的遥测数据进入时进行监视,如果发现不寻常的变化,它可以发送警报通知您。例如,它可以检测以下类型的问题:

  • 应用程序突然返回比以前发送的5xx(错误)类状态响应的速率更高。
  • 应用程序与数据库通信所需的时间大大超过了以前的平均值。

当然,这项功能并非万无一失——例如,以我的经验,它不会检测到随着时间推移错误率的缓慢变化,而这种变化可能仍然表明存在问题。尽管如此,这是一个非常有用的功能,可以提供给我们,它帮助我在很多场合识别问题。

默认情况下启用智能检测。除非您另有配置,智能检测警报将发送给Application Insights实例所在的Azure订阅的所有所有者。在许多情况下,这是不可取的:当您的Azure订阅包含许多不同的应用程序时,每个都有不同的所有者;或者当操作或开发团队没有被授予订阅所有者角色时(因为它们不应该是!);或者,当订阅由中央订阅管理团队管理时,该团队可能无法处理从所有应用程序收到的警报。我们可以配置每个智能检测警报使用主动检测配置ARM资源类型

以下是ARM模板示例,显示如何将智能检测警报重定向到您指定的电子邮件地址:

在开发环境中,您可能根本不想启用这些警报。开发环境可以偶尔使用,它的错误率比正常情况下要高得多,因此,应用程序洞察力用来主动监控问题的信号并没有那么有用。我发现最好自己配置智能检测,这样我就可以在不同的环境中打开或关闭它,对于那些确实需要它的环境,我将覆盖警报配置,将其发送到我自己的警报电子邮件地址,而不是发送给订阅所有者。这要求我们为不同的环境提供不同的仪器配置。

仪器环境

在大多数实际应用中,我们最终将应用程序部署到至少三个环境中:开发环境,软件开发人员在积极处理某个特性或变更时使用的;非生产环境,测试人员使用的,质量保证工程师,产品经理,以及其他需要在应用程序生效前访问其副本的人;和生产环境,由客户使用,可由中央运营团队监控。在这些类别中,也可以有多个实际环境–例如,对于不同类型的测试,可以有不同的非生产环境(例如,功能测试,安全测试,以及性能测试)。其中一些可能是长期的,而另一些则是短期的。

这些不同的环境中的每一个都对仪器有不同的需求:

  • 生产环境通常需要最高级别的警报和监控,因为问题可能会影响我们客户的体验。我们通常会为生产系统设置许多警报和仪表板。但我们也可能不想从生产系统中收集大量的遥测数据,尤其是这样做可能会对应用程序的性能造成负面影响。
  • 非生产环境可能需要某种程度的警觉,但是,与生产环境相比,某些类型的警报可能没有意义。例如,与生产系统相比,我们可以在较低层次的基础设施上运行非生产系统,因此,基于应用程序响应时间的警报可能需要不同的阈值来解释预期性能的降低。但与非生产环境相比,我们可能认为收集大量的遥测数据很重要,以防我们的测试人员发现任何问题,我们需要交互式地诊断它们,因此,我们可以允许比在生产环境中更高级别的遥测采样。
  • 开发环境可能只需要最少的仪器。通常在开发环境中,我将部署所有我将为非生产环境部署的遥测采集,但请关闭所有警报和仪表板。如果出现任何问题,不管怎样,我将自己交互地使用遥测技术。

当然,你的具体需求可能不同,但总的来说,我认为最好将我们的工具划分为不同类型的环境。例如,以下是我通常如何跨环境部署Application Insights组件:

仪表类型 发展 非生产 生产
应用程序洞察力智能检测 下车 在,向开发人员发送警报 在,向生产监控组发送警报
Application Insights Azure功能集成
应用程序洞察应用程序服务集成
应用程序洞察力API管理集成 在,100%取样 在,100%取样 在,30%取样

一旦我们确定了这些基本规则,然后我们可以实现它们。对于ARM模板,我倾向于使用ARM模板参数来处理这个问题。在本系列文章中,我们将看到如何使用参数来实现条件逻辑的示例。我还将提供此表的版本以及我对您可能考虑为每个环境部署的组件的建议。

通过ARM模板配置智能检测

现在我们已经基本了解了如何在每个环境中配置插装,我们可以重新考虑如何配置应用程序洞察。通常,我建议为系统将部署到的每个环境部署一个应用程序细节实例。如果我们用系统的所有组件构建一个复杂的ARM模板,我们可以在其中嵌入处理不同环境所需的条件逻辑。

这是一个大型ARM模板,其中包含我们在本文中创建的所有内容,具有三种环境类型模式:

总结

应用程序洞察是监视应用程序组件的非常有用的工具。它从一系列不同的来源收集遥测数据,这一切都可以自动化。它可以自动分析我们的一些数据,并具有智能检测功能,这也是我们可以通过自动化脚本配置的。此外,我们也可以自己将数据发布到其中。事实上,在本系列的下一篇文章中,我们将讨论如何将自定义度量发布到应用程序洞察中。

类别:
应用程序开发和集成Azure基础设施Azure平台
标签:

留下答复