（十一）—— 健康端点监控模式

云计算设计模式（十一）——健康端点监控模式

实施外部工具可以定期通过暴露终端访问应用程序中的功能检查。这个模式可以帮助验证的应用和服务被正确执行。

背景和问题

它是很好的做法，并且通常是一个业务需求，并监控web应用程序，和中间层和共享服务，以确保它们是可用的，并执行正确的。然而，它更难以监测在云中运行比它要监控本地服务的服务。举例来说，你不必完全控制主机环境，而服务通常依赖于平台，供应商和其他公司提供其他服务。

也有一些影响云托管的应用，如网络延迟，性能和下面的计算和存储系统的可用性，以及它们之间的网络带宽的因素很多。由于任何这些因素的服务可能完全或部分失败。因此，您必须定期验证服务正在执行正确，以确保可用性，这可能是您的服务级别协议（SLA）的一部分所要求的水平。

解决方案

通过将请求发送到应用程序的端点实施健康监测。该应用程序应该执行必要的检查，并返回其状态的指示。

一种保健监测检查通常结合了两个因素：检查（如果有的话）的应用程序或服务响应于所述请求发送到健康验证端点执行，并且结果由工具或框架正在执行健康检查验证的分析。的响应代码表示的应用程序的状态和任选的任何组件或服务，它使用。的延迟或响应时间检查由监测工具或框架进行。图1示出了该模式的执行的概述。

图1 - 模式概述

附加的检查，可能如下进行：在该应用程序的运行状况监视代码包括：

• 检查云存储或可用性和响应时间的数据库。
• 检查位于所述应用程序内，或位于其它地方，但应用程序使用的其他资源或服务。

几个现有的服务和工具可用于监视 web 应用程序通过提交一个请求到一组可配置的端点，并评价针对一组可配置的规则的结果。它相对容易地创建一个服务端点，其唯一的目的是要在系统上执行一些功能测试。

这可以通过监控工具来执行典型的检查包括：

• 验证的响应代码。例如，200 的 HTTP 响应（OK）的指示应用程序作出反应而不会出现错误。该监控系统也可能会检查是否有其他响应代码，给出的结果更全面的指标。
• 检查响应的内容，以检测错误，甚至当返回 200（OK）的状态码。这可以检测到影响返回的网页或服务响应的仅有部分的错误。例如，检查一个页面的标题或寻找某个特定的词组，表示正确的页面被退回。
• 测量响应时间，这表明网络延迟和应用程序把执行请求的时间相结合。增加的值可以指示一个新兴的问题与该应用程序或网络。
• 检查资源或位于该应用程序之外的服务，如由应用程序使用，以从全局高速缓存传递内容的内容分发网络。
• 检查 SSL 证书过期。
• 测量用于该应用程序的 URL 的 DNS 查询的响应时间，以便测量的 DNS 延迟和 DNS 故障。
• 验证返回的 DNS 查询，以确保正确输入的URL。这有助于通过在 DNS 服务器上成功的攻击，以避免恶意请求的重定向。

它也是有用的，在可能情况下，以内部部署和托管的位置运行，从这些不同的检查，以测量和来自不同地方比较的响应时间。理想情况下，你应该监视那些贴近客户，以得到每个位置的性能进行精确的视图位置的应用程序。除了提供一个更为坚固的检查机制，其结果可能会影响部署位置的选择的应用程序，以及是否在一个以上的数据中心部署。

试验还应该对所有客户使用，以确保应用程序正常工作的所有顾客的服务实例运行。例如，如果客户的存储空间分布在多个存储账户，在监测过程中，必须检查所有的这些。

问题和注意事项

在决定如何实现这个模式时，请考虑以下几点：

• 如何验证响应。例如，仅仅是一个200（OK）状态码足以验证应用程序是否工作正常？虽然这提供了应用程序的可用性的最基本的措施，而且是最小执行这个模式中，它提供了有关操作，趋势，并在应用中可能即将出现的问题的信息很少。

Note

确保应用程序不会正确地当目标资源是发现和处理仅返回200状态码。在某些情况下，使用母版页来承载目标网页的时候，例如，服务器可能会返回一个 200 OK 状态码，而不是一个 404 未找到的代码，即使没有找到目标内容页面。

• 端点的数量，以暴露于一个应用程序。一种方法是将暴露的至少一个端点的应用程序所使用的核心服务，而另一个用于辅助或低优先级的服务，使得不同级别的重要性将被分配给每个监控结果。也可以考虑暴露多个端点，如为每个核心服务，以提供额外的监控粒度。举例来说，一个健康的验证检查可以检查数据库，存储和应用程序使用外部地理编码服务;每个都需要不同级别的正常运行时间和响应时间。应用程序可能仍然是健康的，如果地理编码服务，或其他一些后台任务，是几分钟不可用。
• 是否使用相同的终点监测作为用于一般访问，而是设计为健康验证检查一个特定的路径;例如，/健康检查/{GUID}/对一般接入端点。这允许应用程序内的某些功能测试由监测工具，例如添加新的用户注册，登录，以及将一个测试的顺序被执行，同时也证实，一般接入终端是可用的。
• 收集在服务响应于监控请求，以及如何返回该信息的信息类型。大多数现有的工具和框架只看该 HTTP 状态代码端点的回报。要恢复和验证其他信息，可能需要创建一个自定义监控实用程序或服务。
• 多少信息收集。在检查过程中进行过度处理可以重载应用和影响其他用户，并且所花费的时间可能超过监控系统的超时，使得它标志着该应用程序为不可用。大多数的应用包括仪表，如错误处理程序，并且记录性能和详细的错误信息的性能计数器，这可能是足够的，而不是从一个健康验证检查返回的附加信息。
• 如何配置安全监控端点保护他们免受公众使用;这可能暴露该应用程序的恶意攻击，风险敏感信息的曝光，还是吸引拒绝服务（DoS）攻击。典型地，这应该在应用程序的配置来完成，以便它可以容易地更新，而无需重新启动该应用程序。可以考虑使用以下一种或多种技术：通过要求认证◦Secure 端点。这可以通过使用在请求报头中的身份验证的安全密钥或通过传递凭证与请求来实现，条件是，监控服务或工具支持认证。
• Use 一个不起眼的或隐藏的端点。例如，暴露在端点上一个不同的 IP 地址，以所使用的默认的应用程序的 URL，一个非标准的 HTTP 端口上配置端点，和/或使用复杂的路径测试页。它通常可以指定在应用程序配置额外的端点地址和端口，并为这些端点的 DNS 服务器（如果需要），以避免直接指定 IP 地址添加条目。
• Expose 上接受一个参数的端点的方法，诸如键的值或操作模式的值。根据不同的请求时收到的代码可以执行特定测试或一组测试，或者返回一个 404 这个参数提供的值（未找到）错误，如果不能被识别的参数值。所识别的参数值可以在该应用程序的配置进行设置。

Note1

DoS 攻击是可能对一个单独的端点，它执行基本功能测试，而不会影响应用程序的动作的影响较小。理想情况下，应避免使用测试可能暴露敏感信息。如果你必须返回，可能是对攻击者有用的信息，考虑如何将保护端点免受未经授权的访问数据。在这种情况下，仅仅依靠默默无闻是不够的。还应该考虑使用 HTTPS 连接和加密的任何敏感数据，尽管这会增加服务器上的负载。

• 如何访问正在使用认证固定的端点。不是所有的工具和框架可被配置为包括与健康验证请求的凭证。例如，微软的 Azure 内置健康验证功能无法提供身份验证凭据。一些第三方的替代品，可以是 Pingdom 的，Panopta，NewRelic 的，和 Statuscake。
• 如何确保监控代理是否正确地履行。一种方法是，以暴露一个端点仅返回来自应用程序的配置或可被用来测试剂的随机值的值。

Note2

还要确保监控系统进行自身检查，如自检和内置的测试，以避免它在发出假阳性结果。

何时使用这个模式

这种模式非常适合于：

• 监控网站和 Web 应用程序，以验证可用性。
• 监控网站和 Web 应用程序，以检查其是否工作正常。
• 监控中间层或共享服务来检测和隔离故障，可能影响其他应用程序。
• 要在应用程序中补充现有的仪器，如性能计数器和错误处理程序。卫生检验检查并不能取代的日志和审计中的应用程序的需求。仪表能够提供有价值的信息为现有的框架，监视计数器和错误日志来检测故障或其他问题。然而，它不能提供的信息，如果该应用程序是不可用的。

例子

下面的代码示例，从 HealthCheckController 类的 HealthEndpointMonitoring.Web 项目采取包括可以下载本指南的样品，演示露出一个端点进行一系列健康检查。

该 CoreServices 方法，如下所示，执行在应用程序中使用的服务的一系列检查。如果所有的测试中没有错误执行，该方法返回一个 200（OK）状态码。如果有任何的测试引发了异常，该方法返回一个 500（内部错误）状态码。当发生错误时的方法，可任选地返回附加信息，如果该监控工具或框架能够利用它。

public ActionResult CoreServices()  
{  
  try  
  {  
    // Run a simple check to ensure the database is available.  
    DataStore.Instance.CoreHealthCheck();  
 
    // Run a simple check on our external service.  
    MyExternalService.Instance.CoreHealthCheck();  
  }  
  catch (Exception ex)  
  {  
    Trace.TraceError("Exception in basic health check: {0}", ex.Message);  
 
    // This can optionally return different status codes based on the exception.  
    // Optionally it could return more details about the exception.  
    // The additional information could be used by administrators who access the  
    // endpoint with a browser, or using a ping utility that can display the  
    // additional information.  
    return new HttpStatusCodeResult((int)HttpStatusCode.InternalServerError);  
  }  
  return new HttpStatusCodeResult((int)HttpStatusCode.OK);  
}

该 ObscurePath 方法显示了如何读取应用程序配置的路径，并用它作为测试端点。这个例子也说明了如何接受一个 ID 作为参数，并用它来检查有效的请求。

public ActionResult ObscurePath(string id)  
{  
  // The id could be used as a simple way to obscure or hide the endpoint.  
  // The id to match could be retrieved from configuration and, if matched,   
  // perform a specific set of tests and return the result. It not matched it  
  // could return a 404 Not Found status.  
 
  // The obscure path can be set through configuration in order to hide the endpoint.  
  var hiddenPathKey = CloudConfigurationManager.GetSetting("Test.ObscurePath");  
 
  // If the value passed does not match that in configuration, return 403 "Not Found".  
  if (!string.Equals(id, hiddenPathKey))  
  {  
    return new HttpStatusCodeResult((int)HttpStatusCode.NotFound);  
  }  
 
  // Else continue and run the tests...  
  // Return results from the core services test.  
  return this.CoreServices();  
}

该 TestResponseFromConfig 方法显示了如何可以公开执行一个指定的配置设定值检查的端点。

public ActionResult TestResponseFromConfig()  
{  
  // Health check that returns a response code set in configuration for testing.  
  var returnStatusCodeSetting = CloudConfigurationManager.GetSetting(  
                                                          "Test.ReturnStatusCode");  
 
  int returnStatusCode;  
 
  if (!int.TryParse(returnStatusCodeSetting, out returnStatusCode))  
  {  
    returnStatusCode = (int)HttpStatusCode.OK;  
  }  
 
  return new HttpStatusCodeResult(returnStatusCode);  
}

监控端点在 Azure 中托管的应用程序

在Azure应用程序监控终端的一些选项包括：

• 使用微软的Azure，的内置功能，如管理服务或流量管理器。
• 使用第三方服务或Microsoft系统中心操作管理器的框架等。
• 创建一个自定义的工具，或者在您自己的或托管的服务器上运行的服务。

注意： 尽管 Azure 提供一个合理的全面的监控选项，您可以决定使用额外的服务和工具，以提供额外的信息。

Azure 管理服务提供了各地的警报规则建立了一个全面的内置监控机制。管理服务网页中的 Azure 管理门户 Alerts 部分，可以配置高达每认购10警报规则为您服务。这些规则指定一条件和用于服务诸如 CPU 负载的阈值，或每秒请求或错误的数量，并且该服务可以自动发送电子邮件通知给你在每个规则定义的地址。

您可以监视具体费用取决于您选择适合您的应用程序的托管机制的条件下（如网站，云服务，虚拟机，或移动服务），但所有这些，包括创建使用网络端点警报规则的能力您在为您服务的设置指定。此端点应该及时地作出反应，以使警报系统可以检测到该应用程序是否正常运行。

注意： 有关创建监视警报的详细信息，请参阅 MSDN 上的管理服务。

如果你的主机在 Azure 云服务网络和工作角色或虚拟机应用程序时，您可以采取的内置服务在Azure中所谓的流量管理器中的一个优势。流量管理器是一个路由和负载平衡服务，可以将请求分发到您的云服务托管的应用程序基于一系列的规则和设置的具体实例。

除了请求路由，流量管理坪的 URL，端口和相对你定期指定的路径来确定其规则中定义的应用程序的实例是活动的，并响应请求。如果它检测到一个状态代码 200（OK）它标志着应用程序可用，其他状态的代码会导致流量管理器来标记应用程序离线。您可以查看流量管理器控制台的状态和配置规则来重新路由请求被响应的应用程序的其他实例。

但是，请记住，流量管理器将只等待10秒钟，以接收来自监控URL的响应。因此，你应该确保你的健康验证码这个时间范围内执行，允许网络延迟从流量管理器往返于您的应用程序，然后再返回。

注意： 有关使用 Windows 流量管理器来监视你的应用程序的更多信息，请参阅 MSDN 上微软 Azure Traffic Manager 的。流量管理器在多个数据中心部署指南进行了讨论。