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

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

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

背景和问题

它是非常好的做法，而且一般是一个业务需求。并监控web应用程序。和中间层和共享服务，以确保它们是可用的，并执行正确的。然而，它更难以监測在云中执行比它要监控本地服务的服务。

举例来说，你不必全然控制主机环境，而服务通常依赖于平台，供应商和其它公司提供其它服务。

也有一些影响云托管的应用，如网络延迟。性能和以下的计算和存储系统的可用性，以及它们之间的网络带宽的因素非常多。因为不论什么这些因素的服务可能全然或部分失败。

因此，您必须定期验证服务正在运行正确，以确保可用性，这可能是您的服务级别协议（SLA）的一部分所要求的水平。

解决方式

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

一种保健监測检查通常结合了两个因素：检查（假设有的话）的应用程序或服务响应于所述请求发送到健康验证端点运行。而且结果由工具或框架正在运行健康检查验证的分析。的响应代码表示的应用程序的状态和任选的不论什么组件或服务。它使用。的延迟或响应时间检查由监測工具或框架进行。

图1示出了该模式的运行的概述。

图1  - 模式概述


附加的检查。可能例如以下进行：在该应用程序的执行状况监视代码包含：
•检查云存储或可用性和响应时间的数据库。
•检查位于所述应用程序内。或位于其他地方，但应用程序使用的其他资源或服务。

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

这能够通过监控工具来运行典型的检查包含：
•验证的响应代码。比如，200的HTTP响应（OK）的指示应用程序作出反应而不会出现错误。该监控系统也可能会检查是否有其它响应代码。给出的结果更全面的指标。
•检查响应的内容。以检測错误，甚至当返回200（OK）的状态码。这能够检測到影响返回的网页或服务响应的仅有部分的错误。比如。检查一个页面的标题或寻找某个特定的词组，表示正确的页面被退回。
•測量响应时间，这表明网络延迟和应用程序把运行请求的时间相结合。

添加的值能够指示一个新兴的问题与该应用程序或网络。
•检查资源或位于该应用程序之外的服务。如由应用程序使用。以从全局快速缓存传递内容的内容分发网络。
•检查SSL证书过期。
•測量用于该应用程序的URL的DNS查询的响应时间，以便測量的DNS延迟和DNS故障。
•验证返回的DNS查询，以确保正确输入的URL。

这有助于通过在DNSserver上成功的攻击，以避免恶意请求的重定向。

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

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

问题和注意事项

在决定怎样实现这个模式时，请考虑下面几点：
•怎样验证响应。比如，不过一个200（OK）状态码足以验证应用程序是否工作正常？尽管这提供了应用程序的可用性的最基本的措施，并且是最小运行这个模式中，它提供了有关操作。趋势，并在应用中可能即将出现的问题的信息非常少。


Note：

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

•端点的数量。以暴露于一个应用程序。一种方法是将暴露的至少一个端点的应用程序所使用的核心服务。而还有一个用于辅助或低优先级的服务，使得不同级别的重要性将被分配给每一个监控结果。也能够考虑暴露多个端点。如为每一个核心服务，以提供额外的监控粒度。举例来说，一个健康的验证检查能够检查数据库，存储和应用程序使用外部地理编码服务;每一个都须要不同级别的正常执行时间和响应时间。应用程序可能仍然是健康的，假设地理编码服务，或其它一些后台任务。是几分钟不可用。
•是否使用同样的终点监測作为用于一般訪问。而是设计为健康验证检查一个特定的路径;比如。/健康检查/{GUID}/对一般接入端点。这同意应用程序内的某些功能測试由监測工具，比如加入新的用户注冊。登录。以及将一个測试的顺序被运行。同一时候也证实，一般接入终端是可用的。
•收集在服务响应于监控请求，以及怎样返回该信息的信息类型。大多数现有的工具和框架仅仅看该HTTP状态代码端点的回报。要恢复和验证其它信息，可能须要创建一个自己定义监控有用程序或服务。

•多少信息收集。在检查过程中进行过度处理能够重载应用和影响其它用户。而且所花费的时间可能超过监控系统的超时。使得它标志着该应用程序为不可用。

大多数的应用包含仪表。如错误处理程序，而且记录性能和具体的错误信息的性能计数器，这可能是足够的。而不是从一个健康验证检查返回的附加信息。
•怎样配置安全监控端点保护他们免受公众使用;这可能暴露该应用程序的恶意攻击。风险敏感信息的曝光。还是吸引拒绝服务（DoS）攻击。

典型地，这应该在应用程序的配置来完毕。以便它能够easy地更新。而无需又一次启动该应用程序。

能够考虑使用下面一种或多种技术：通过要求认证◦Secure端点。这能够通过使用在请求报头中的身份验证的安全密钥或通过传递凭证与请求来实现，条件是，监控服务或工具支持认证。
◦Use一个不起眼的或隐藏的端点。比如，暴露在端点上一个不同的IP地址，以所使用的默认的应用程序的URL。一个非标准的HTTPport上配置端点，和/或使用复杂的路径測试页。它通常能够指定在应用程序配置额外的端点地址和port，并为这些端点的DNSserver（假设须要），以避免直接指定IP地址加入条目。

◦Expose上接受一个參数的端点的方法，诸如键的值或操作模式的值。

依据不同的请求时收到的代码能够运行特定測试或一组測试。或者返回一个404这个參数提供的值（未找到）错误，假设不能被识别的參数值。所识别的參数值能够在该应用程序的配置进行设置。

 


Note：

DoS攻击是可能对一个单独的端点。它运行基本功能測试。而不会影响应用程序的动作的影响较小。理想情况下，应避免使用測试可能暴露敏感信息。

假设你必须返回，可能是对攻击者实用的信息。考虑怎样将保护端点免受未经授权的訪问数据。

在这样的情况下，只依靠默默无闻是不够的。还应该考虑使用HTTPS连接和加密的不论什么敏感数据，虽然这会添加server上的负载。


•怎样訪问正在使用认证固定的端点。

不是全部的工具和框架可被配置为包含与健康验证请求的凭证。比如。微软的Azure内置健康验证功能无法提供身份验证凭据。一些第三方的替代品，能够是Pingdom的。Panopta。NewRelic的。和Statuscake。
•怎样确保监控代理是否正确地履行。一种方法是。以暴露一个端点仅返回来自应用程序的配置或可被用来測试剂的随机值的值。

Note：

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

何时使用这个模式

这样的模式很适合于：
•监控站点和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系统中心操作管理器的框架等。

•创建一个自己定义的工具。或者在您自己的或托管的server上执行的服务。

注意：

虽然Azure提供一个合理的全面的监控选项，您能够决定使用额外的服务和工具，以提供额外的信息。


Azure管理服务提供了各地的警报规则建立了一个全面的内置监控机制。

管理服务网页中的Azure管理门户Alerts部分，能够配置高达每认购10警报规则为您服务。

这些规则指定一条件和用于服务诸如CPU负载的阈值，或每秒请求或错误的数量，而且该服务能够自己主动发送电子邮件通知给你在每一个规则定义的地址。

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

注意：

有关创建监视警报的具体信息，请參阅MSDN上的管理服务。


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

除了请求路由，流量管理坪的URL，port和相对你定期指定的路径来确定其规则中定义的应用程序的实例是活动的，并响应请求。

假设它检測到一个状态代码200（OK）它标志着应用程序可用。其它状态的代码会导致流量管理器来标记应用程序离线。

您能够查看流量管理器控制台的状态和配置规则来又一次路由请求被响应的应用程序的其它实例。

可是。请记住。流量管理器将仅仅等待10秒钟，以接收来自监控URL的响应。

因此，你应该确保你的健康验证码这个时间范围内运行，同意网络延迟从流量管理器往返于您的应用程序，然后再返回。

注意：

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

本文翻译自MSDN：http://msdn.microsoft.com/en-us/library/dn589789.aspx