您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

运行状况终结点监视模式

在应用程序中实施可让外部工具通过公开终结点定期访问的功能检查。 这有助于验证应用程序和服务的运行是否正常。

上下文和问题

一种良好的做法(通常也是一项业务要求)是监视 Web 应用程序和后端服务,以确保它们保持可用且正常运行。 但是,有时监视在云中运行的服务比监视本地服务更难。 例如,无法完全控制宿主环境,并且服务通常依赖于平台供应商和其他公司提供的其他服务。

有许多因素会影响云托管的应用程序,例如网络延迟、底层计算与存储系统的性能和可用性,以及这些系统之间的网络带宽。 由于其中的任何因素,服务可能发生整体性或局部性的故障。 因此,必须定期验证服务是否正确运行,确保提供所需级别的可用性,这可能是服务级别协议 (SLA) 所涵盖的要求。

解决方案

通过将请求发送到应用程序上的终结点来实施运行状况监视。 应用程序应执行必要的检查,并返回其状态指示。

运行状况监视检查通常结合了两个因素:

  • 应用程序或服务在响应针对运行状况验证终结点的请求时执行的检查(如果有)。
  • 通过执行运行状况验证检查的工具或框架分析结果。

响应代码指示应用程序的状态,并选择性地指示应用程序使用的任何组件或服务的状态。 延迟或响应时间检查由监视工具或框架执行。 下图提供了模式概览。

模式概览

应用程序中运行状况监视代码可能执行的其他检查包括:

  • 检查云存储或数据库的可用性和响应时间。
  • 检查位于应用程序中的或者位于其他位置、但由应用程序使用的其他资源或服务。

可以使用某些服务和工具,通过将请求提交到一组可配置的终结点,并根据一组可配置的规则评估结果,来监视 Web 应用程序。 创建一个只是在系统上执行某些功能测试的服务终结点相对较为容易。

监视工具可执行的典型检查包括:

  • 验证响应代码。 例如,HTTP 响应 200(正常)表示应用程序已做出响应且未出错。 监视系统可能还会检查其他响应代码以提供更全面的结果。
  • 即使返回了 200(正常)状态代码,也会检查响应内容以检测错误。 这可以检测仅影响所返回网页的某个部分或服务响应的错误。 例如,检查页面标题,或查找指示返回了正确页面的特定短语。
  • 测量响应时间,即网络延迟与应用程序执行请求所花费时间的合计。 如果值增大,则可能表示应用程序或网络正在出现问题。
  • 检查位于应用程序外部的资源或服务,例如应用程序用来分发全局缓存中的内容的内容分发网络。
  • 检查 SSL 证书过期时间。
  • 测量针对应用程序 URL 执行 DNS 查找所花费的响应时间,以测量 DNS 延迟和 DNS 故障。
  • 验证 DNS 查找返回的 URL 以确保条目正确。 这有助于避免恶意用户通过成功攻击 DNS 服务器进行请求重定向。

在可能的情况下,从不同的本地位置或托管位置运行这些检查来测量和比较响应时间也很有用。 理想情况下,应该从靠近客户的位置监视应用程序,以获取每个位置的准确性能视图。 除了提供更可靠的检查机制以外,结果可以帮助确定应用程序的部署位置,以及是否将其部署到多个数据中心。

此外,还应针对客户使用的所有服务实例运行测试,确保所有客户可正常运行应用程序。 例如,如果客户存储分散在多个存储帐户中,则监视过程应检查所有这些存储帐户。

问题和注意事项

在决定如何实现此模式时,请考虑以下几点:

如何验证响应。 例如,仅凭一个 200(正常)状态代码是否足以确认应用程序在正常运行? 尽管这是应用程序可用性的最基本测量方法,并且是此模式的最简单实现方式,但是,它在应用程序中的操作、趋势和可能即将出现的问题方面提供的信息极少。

要为应用程序公开的终结点数。 一种方法是将针对应用程序使用的核心服务至少公开一个终结点,并为低优先级服务公开另一个终结点,以便将不同级别的重要性分配给每项监视结果。 此外,请考虑公开更多的终结点,例如,为每个核心服务公开一个终结点,以获得更高的监视粒度。 例如,运行状况验证检查可能会检查应用程序使用的数据库、存储和外部地理编码服务,每个检查项需要不同级别的正常运行时间和响应时间。 如果地理编码服务或其他某个后台任务有几分钟不可用,应用程序可能仍处于正常状态。

是否使用用于常规访问 的同一终结点进行监视,但是否使用用于运行状况验证检查的特定路径,例如常规访问终结点上的 /health。 这样,监视工具便可运行应用程序中的某些功能测试,例如,添加新用户注册、登录和下达测试工单,同时还可验证常规访问终结点是否可用。

在服务中为响应 监视请求而收集的信息的类型,以及如何返回此信息。 大多数现有工具和框架仅查看终结点返回的 HTTP 状态代码。 若要返回并验证其他信息,可能需要创建自定义监视实用工具或服务。

要收集多少信息。 在检查期间执行过多的处理可能导致应用程序过载并影响其他用户。 所需的时间可能超过监视系统的超时时间,因此会将应用程序标记为不可用。 大多数应用程序包含错误处理程序和性能计数器等检测功能用于记录性能与详细错误信息,这些信息可能已足够,而无需通过运行状况验证检查返回更多信息。

缓存终结点状态。 过于频繁地执行运行状况检查可能会产生很高的系统开销。 例如,如果运行状况状态通过仪表板报告,则不希望对仪表板的每一个请求都触发运行状况检查。 应该定期检查系统运行状况并缓存状态。 公开返回缓存状态的终结点。

如何为监视终结点配置安全性,以保护它们免受公共访问,这可能会使应用程序遭受恶意攻击、面临敏感信息泄露的风险,或吸引拒绝服务 (DoS) 攻击。 通常应在应用程序配置中执行此操作,以便无需重启应用程序就能更新配置。 考虑使用以下一种或多种技术:

  • 要求身份验证,以保护终结点。 为此,可以在请求标头中使用身份验证安全密钥,或者连同请求一起传递凭据,前提是监视服务或工具支持身份验证。

    • 使用模糊化或隐藏的终结点。 例如,在不是由默认应用程序 URL 使用的 IP 地址上公开终结点,在非标准 HTTP 端口上配置终结点,和/或使用测试页的复杂路径。 通常可以在应用程序配置中指定其他终结点地址和端口,并可以根据需要将这些终结点的条目添加到 DNS 服务器,以免直接指定 IP 地址。

    • 在终结点上公开一个可接受键值或操作模式值等参数的方法。 根据为此参数提供的值,在收到到请求时,代码可以执行一个特定的测试或一组测试;如果参数值未被识别,则代码会返回 404(未找到)错误。 可以在应用程序配置中设置识别的参数值。

      DoS 攻击可能只对执行基本功能测试的独立终结点产生较小的影响,而不会影响应用程序的运行。 理想情况下,请避免使用可能透露敏感信息的测试。 如果必须返回可能对攻击者有用的信息,请考虑如何防范终结点和数据受到未经授权的访问。 在这种情况下,只是依靠模糊处理并不足够。 还应考虑使用 HTTPS 连接并加密所有敏感数据,尽管这会增大服务器的负载。

  • 如何访问使用身份验证保护的终结点是评估运行状况检查终结点和使用终结点时需考虑的一点。 例如, 应用服务的内置 运行状况检查与应用服务的身份验证和授权功能集成。

如何确保监视代理正常运行。 一种方法是公开一个只返回应用程序配置中的值,或者返回可用于测试代理的随机值的终结点。

另外,请确保监视系统对自身进行检查,例如自测试和内置测试,以免发出误报结果。

何时使用此模式

此模式适合用于:

  • 监视网站和 Web 应用程序,以验证可用性。
  • 监视网站和 Web 应用程序以检查是否正常运行。
  • 监视中间层或共享服务,以检测并隔离可能会中断其他应用程序的故障。
  • 补充应用程序中的现有检测,例如性能计数器和错误处理程序。 运行状况验证检查不能取代应用程序中的日志记录和审核要求。 检测可为现有框架提供有用的信息,使它们能够监视计数器和错误日志,以检测故障或其他问题。 但是,如果应用程序不可用,则它无法提供信息。

示例

运行状况检查 ASP.NET是中间件和一组库,用于报告应用基础结构组件的运行状况。 它提供了一个框架,用于以一致的方法报告运行状况检查,实现上面解决的许多做法。 这包括数据库连接等外部检查,以及运行情况探测和就绪情况探测等特定概念。

GitHub在 上找到许多使用 ASP.NET 运行状况检查的示例GitHub。

监视 Azure 托管应用程序中的终结点

用于监视 Azure 应用程序中的终结点的一些选项包括:

  • 使用 Azure 的内置监视功能。

  • 使用第三方服务或框架,例 Microsoft System Center Operations Manager。

  • 创建自定义实用工具,或者创建可在自己的服务器或托管服务器上运行的服务。

    尽管 Azure 提供了相当全面的监视选项,但你也可以使用其他服务和工具来提供附加的信息。 应用程序Insights是 Azure Monitor的一项功能,面向开发团队,可帮助你了解应用的表现以及应用的使用方式。 它监视请求速率、响应时间、失败率、依赖项速率和失败率,并帮助你了解外部服务是否拖慢了速度。

可监视的条件因为应用程序选择的托管机制而异,但所有这些条件都包括创建警报规则的能力,该规则使用你在服务的设置中指定的 Web 终结点。 该终结点应及时做出响应,使警报系统可以检测到应用程序在正常运行。

阅读有关创建警报通知的详细信息。

发生重大中断时,客户端流量应可路由到可在其他区域或区域之间保持可用的应用程序部署。 最终,应该使用跨界连接和全局负载均衡,具体取决于应用程序是面向内部还是面向外部。 服务(Azure Front Door、Azure 流量管理器 CDN)可以基于通过运行状况探测提供的应用程序运行状况跨区域路由流量。

Azure 流量管理器路由和负载均衡服务,该服务可以基于一系列规则和设置将请求分发到应用程序的特定实例。 除了路由请求以外,流量管理器会定期针对指定的 URL、端口和相对路径执行 ping,以确定应用程序规则中定义的哪些应用程序实例处于活动状态并在响应请求。 如果流量管理器检测到状态代码 200(正常),则会将应用程序标记为可用。 其他任何状态代码会导致流量管理器将应用程序标记为脱机。 可以在流量管理器控制台中查看状态,并配置规则用于将请求重新路由到正在做出响应的其他应用程序实例。

但是,流量管理员只会等待一段时间才能收到来自监视 URL 的响应。 因此,应确保运行状况验证代码在此时限内执行,并考虑到在流量管理器与应用程序之间往返所存在的网络延迟。

实施此模式时,可参考以下指南: