Azure设计模式之端点监控模式
端点监控模式
使用外部工具定期为应用程序做功能检查。可以帮助验证应用程序和服务是否正确运行。
问题背景
对web应用程序和后端服务进行监控是很好的做法,通常是业务上的需求,以保证它们的可用性并在正确地执行。然而,监控云服务比监视传统服务更困难。例如,没有完全可控的宿主环境,服务通常依赖于平台供应商或他人提供的服务。
影响云应用程序的因素很多,如网络延迟、底层计算和存储系统的性能和可用性,以及它们之间的网络带宽。这些因素可能会影响服务甚至导致失败。因此,必须定期验证服务是否正确的执行,以保证高可用性,这可能是服务级别协议(SLA)的一部分。
解决方案
通过向应用程序的终结点发送请求来监听服务运行状况。应用程序应执行必要的检查,并返回其状态信息。
运行状况监控通常包含两个因素:
应用程序或服务对健康验证请求检查的响应。
通过执行健康验证检查的工具或框架对结果进行分析。
响应代码指示应用程序的状态以及它所使用的任何组件或服务。
对延迟或响应时间的检查由监视工具或框架执行。下图提供了该模式的运行流程。
应用程序运行状况的监控可能执行的其他检查:
检查云存储或数据库的可用性和响应时间。
检查应用程序中的其他资源或服务,如位于其他位置。
通过向集群发送请求,根据一组可配置的规则评估结果,可以使用服务和工具来监视web应用程序。而创建单一端点相对容易,其唯一目的是在系统上执行某些功能的测试。
监视工具可以执行的典型检查包括:
验证服务的响应代码。例如,HTTP响应200(OK)表示应用程序响应时没有错误。监控系统还可以检查其他响应代码以提供更全面的结果验证。
对响应的内容进行检测看是否有错误,即使返回200(OK)状态代码。这可以检测返回的网页或服务中的部分错误。例如,检查页面的标题或查找页面中的特定词组。
测量响应时间,表示网络延迟和应用程序执行请求所用时间的总和。超出某数值表示应用程序或网络出现问题。检查位于应用程序之外的资源或服务, 如应用程序对全局缓存中的内容的读写和传递。检查SSL证书的过期时间。
测量dns查找应用程序URL的响应时间,以检测dns延迟和dns故障。
确保由DNS查找返回的URL正确。这样可以避免恶意攻击DNS的请求完成的重定向。在可能的情况下,在不同服务器或托管环境运行这些检查以测量和比较响应时间很有用。理想情况下,应该从靠近客户的位置监控应用程序,以便从每个位置获得准确的性能视图。除了提供更健壮的检测机制外,结果还可以帮助决定应用程序的部署位置,以及是否在多个数据中心部署。
还应对所有服务实例运行测试,以确保应用程序能正确地工作。例如,如果客户存储分布在多个存储帐户上,则监视过程应包含所有存储账户。
问题和注意事项
在决定如何实现此模式时,需要考虑以下几点:
如何验证响应。例如,仅仅一个200(OK)的状态码足以验证应用程序是否正常工作？虽然这提供了最基本的应用程序可用性度量, 并且是此模式的最化小实现,但它无法提供有关应用程序中的操作、趋势和所有可能的问题信息。
确保只有在找到并处理目标资源时,应用程序才会返回200(OK)。例如在某些情况下(例如,使用母版页来承载目标web页时),即使未找到目标页,服务器也会发送回200(OK)状态代码而不是404(未找到)代码。
要为应用程序公开的节点数。一种方法是为应用程序使用的核心服务至少公开一个节点,另一个是针对较低优先级服务,为每个监视结果分配不同级别的重要性。此外,还应考虑公开更多的端点(如每个核心服务一个),以完成额外的监控粒度。例如,运行状况的验证可能会检查应用程序所使用的数据库、存储和地理位置服务,其中每一个都包含了不同的正常运行时间和响应级别。如果地理位置服务(或其他一些后台任务)在几分钟内不可用,则应用程序仍然可以正常运行。
是否使用同一个节点进行监控用于常规访问,而是用于运行状况验证检查的特定路径,例如,/检查/{GUID}/是否在常规访问节点上。这使得应用程序中的某些功能测试可由监视工具完成,例如添加新用户注册、登录和放置测试顺序,同时还验证常规端点是否可用。
要在服务中收集的响应监视请求信息类型,以及如何返回这些信息。大多数工具和框架只查看端点返回的HTTP状态码。若要返回并验证其他信息,必须创建自定义监视工具或服务。
要收集多少信息。在检查过程中执行过多的处理会使应用程序超载并影响其他用户。所花费的时间可能使监控系统超时,因此从而将应用程序标记为了不可用。大多数应用程序都包括用于记录性能和详细错误信息的工具,如错误处理程序和性能计数器,可能已经是足够的,而不必从健康验证检查中返回其他更多信息。
缓存节点状态。太频繁运行健康检查可能会很昂贵。例如,如果健康状况来自控制面板,不希望每个请求都触发健康检查。而是定期检查系统运行状况并缓存它的状态值。公开一个节点用于返回缓存状态信息。
如何安全地对监视节点进行配置,以免被公共访问,因为这可能使应用程序暴露于恶意攻击、暴露敏感信息或被服务（DoS）攻击。通常,应该在应用程序配置中完成此操作,就能够在不需要重新启动应用程序的情况下可以方便地进行更新。考虑使用以下一种或多种方法:
使用身份验证来保护节点。如果监视服务或工具支持身份验证,则可使用请求标头中的身份验证安全密钥或通过请求传递凭据来执行身份验证。
使用模糊或隐藏的节点。例如,将不同IP地址上的终端作为应用程序URL所使用的默认端点,在非标准HTTP端口上配置端点,使用/或复杂路径来测试页面。可以在应用程序配置中指定其他端点地址和端口,并在需要时向DNS服务器添加这些端点，避免指定IP地址。
在端点暴露方法接受请求参数(如键值或操作码)。根据为参数提供的值,当收到请求时,代码可以执行特定的测试或测试集,如果参数值不被识别,则返回404(未找到)错误。可在应用程序配置中设置哪些参数值可识别。
DoS攻击可能会对基本功能测试的节点有较小影响,而不会影响应用程序的操作。理想情况下,避免使用可能暴露敏感信息的测试。如果必须返回可能对攻击者有用的信息,就要考虑如何保护节点和数据免受未经授权的访问。在这种情况下就应该考虑使用HTTPS连接并加密敏感数据,尽管这会增加服务器上的负载。
如何访问需要身份验证的端点。并非所有的工具和框架都可以配置为支持请求中包含身份验证凭据。例如,微软Azure内置的健康验证功能就无法提供身份验证凭据。一些可以支持的第三方产品是Pingdom、Panopta、NewRelic和Statuscake。
如何确保监控代理正在正确的运行。一种方法是暴露一个终端,该端点从应用程序配置中返回一个值,或一个可用于测试代理的随机值。
要确保监视系统对自身的检查,如自检和内置测试,以避免误报结果。
何时使用此模式
此模式适用于:
监控网站和web应用程序以确保可用性。
监控网站和web应用程序以检查操作是否正确。
监控中间层或共享服务,以检测并隔离可能中断其他应用程序的故障。
对应用程序中现有检测机制进行补充,如性能计数器和错误处理程序。运行状况验证检查不能代替应用程序中的日志与审计记录。检测可以为现有框架提供有价值的信息,为监视计数器和错误日志用于检测故障或其他问题。但是,如果应用程序不可用,则无法提供这些信息。
例子
下面的代码示例取自HealthCheckController类(host在(github)https://github.com/mspnp/cloud-design-patterns/tree/master/health-endpoint-monitoring),演示了如何暴露一系列运行状况检查的节点。
下面的CoreServices方法对应用程序中服务执行一系列检查。如果所有测试都没有错误地运行,该方法将返回一 200(OK)状态代码。如果任何测试引发异常,则该方法将返回一个500(内部错误)状态码。如果希望监视工具或框架能够使用,则该方法可以在发生错误时返回更多信息。
Azure环境的应用程序中的节点监控
在Azure应用程序中监视节点的选择有:
使用Azure的内置监视功能。
使用第三方服务或框架(如Microsoft系统中心操作管理器)。
创建自定义工具或部署自己的服务。
尽管Azure提供了一系列相对全面的监控选项,但仍可以使用其他服务和工具来提供额外的信息。Azure管理服务为预警规则提供了内置的监控机制。在Azure账户中"管理服务"页的"警报"部分，可以为服务配置多达10个警报规则。这些规则包括为服务(如CPU负载)或每秒的请求数或错误数指定一个阈值条件,服务可以自动向每个规则中定义的地址发送电子邮件进行通知。
取决于应用程序选择的宿主机制(如网站、云服务、虚拟机或移动服务),可监视的条件也会有所变化,但所有这些情况都是可配置的。此节点应提供及时的响应,以便警报系统能够检测到应用程序是否运行正常。
可阅读有关创建警报通知的详细信息。（https://azure.microsoft.com/documentation/articles/insights-receive-alert-notifications/）
如果将应用程序托管在azure云服务或web和worker角色或虚拟机中,则可使用azure中的"流量管理器"(Traffic Manager)的其中一个内置服务。流量管理器是一种路由和负载均衡服务,它可根据一系列规则和设置将请求分配给云服务托管应用的某个实例。
除了路由请求之外,流量管理器还会定期对指定的URL端口和相对路径进行ping操作,以确定其规则中定义的应用程序的哪些实例是活动的。如果检测到状态代码200(OK),则将该应用程序标记为可用。任何其他状态代码都会导致流量管理器将应用程序标记为脱机。可以在"流量管理器"的控制台中查看该状态值,也可将该规则配置为将请求重定向到应用程序的其他实例。
但是,流量管理器等待十秒才能从监控的URL拿到响应。因此,要确保监控验证码在这段时间内被执行,从而保证从流量管理器到应用程序有足够的时间通信。
可以在这里阅读有关使用流量管理器对应用程序监控的详细信息（https://docs.microsoft.com/en-us/azure/traffic-manager/）。在多个数据中心部署指南中也讨论到了流量管理器（https://msdn.microsoft.com/library/dn589779.aspx）。
相关阅读
在实现此模式时, 以下链接可能会有用:
仪器和遥测指南。检查服务和组件的运行状况通常是通过探测来完成的,在监控应用程序性能和检测运行时发生的事件时,返回有用的信息是有帮助的。这些数据可以被回传给监测工具,作为健康监测的补充信息。仪器和遥测指南信息会收集远程应用的诊断信息。
接收警报通知（https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/insights-alerts-portal）。
这里有一个可下载的示例应用程序（https://github.com/mspnp/cloud-design-patterns/tree/master/health-endpoint-monitoring）。
使用外部工具定期为应用程序做功能检查。可以帮助验证应用程序和服务是否正确运行。
问题背景
对web应用程序和后端服务进行监控是很好的做法,通常是业务上的需求,以保证它们的可用性并在正确地执行。然而,监控云服务比监视传统服务更困难。例如,没有完全可控的宿主环境,服务通常依赖于平台供应商或他人提供的服务。
影响云应用程序的因素很多,如网络延迟、底层计算和存储系统的性能和可用性,以及它们之间的网络带宽。这些因素可能会影响服务甚至导致失败。因此,必须定期验证服务是否正确的执行,以保证高可用性,这可能是服务级别协议(SLA)的一部分。
解决方案
通过向应用程序的终结点发送请求来监听服务运行状况。应用程序应执行必要的检查,并返回其状态信息。
运行状况监控通常包含两个因素:
应用程序或服务对健康验证请求检查的响应。
通过执行健康验证检查的工具或框架对结果进行分析。
响应代码指示应用程序的状态以及它所使用的任何组件或服务。
对延迟或响应时间的检查由监视工具或框架执行。下图提供了该模式的运行流程。
应用程序运行状况的监控可能执行的其他检查:
检查云存储或数据库的可用性和响应时间。
检查应用程序中的其他资源或服务,如位于其他位置。
通过向集群发送请求,根据一组可配置的规则评估结果,可以使用服务和工具来监视web应用程序。而创建单一端点相对容易,其唯一目的是在系统上执行某些功能的测试。
监视工具可以执行的典型检查包括:
验证服务的响应代码。例如,HTTP响应200(OK)表示应用程序响应时没有错误。监控系统还可以检查其他响应代码以提供更全面的结果验证。
对响应的内容进行检测看是否有错误,即使返回200(OK)状态代码。这可以检测返回的网页或服务中的部分错误。例如,检查页面的标题或查找页面中的特定词组。
测量响应时间,表示网络延迟和应用程序执行请求所用时间的总和。超出某数值表示应用程序或网络出现问题。检查位于应用程序之外的资源或服务, 如应用程序对全局缓存中的内容的读写和传递。检查SSL证书的过期时间。
测量dns查找应用程序URL的响应时间,以检测dns延迟和dns故障。
确保由DNS查找返回的URL正确。这样可以避免恶意攻击DNS的请求完成的重定向。在可能的情况下,在不同服务器或托管环境运行这些检查以测量和比较响应时间很有用。理想情况下,应该从靠近客户的位置监控应用程序,以便从每个位置获得准确的性能视图。除了提供更健壮的检测机制外,结果还可以帮助决定应用程序的部署位置,以及是否在多个数据中心部署。
还应对所有服务实例运行测试,以确保应用程序能正确地工作。例如,如果客户存储分布在多个存储帐户上,则监视过程应包含所有存储账户。
问题和注意事项
在决定如何实现此模式时,需要考虑以下几点:
如何验证响应。例如,仅仅一个200(OK)的状态码足以验证应用程序是否正常工作？虽然这提供了最基本的应用程序可用性度量, 并且是此模式的最化小实现,但它无法提供有关应用程序中的操作、趋势和所有可能的问题信息。
确保只有在找到并处理目标资源时,应用程序才会返回200(OK)。例如在某些情况下(例如,使用母版页来承载目标web页时),即使未找到目标页,服务器也会发送回200(OK)状态代码而不是404(未找到)代码。
要为应用程序公开的节点数。一种方法是为应用程序使用的核心服务至少公开一个节点,另一个是针对较低优先级服务,为每个监视结果分配不同级别的重要性。此外,还应考虑公开更多的端点(如每个核心服务一个),以完成额外的监控粒度。例如,运行状况的验证可能会检查应用程序所使用的数据库、存储和地理位置服务,其中每一个都包含了不同的正常运行时间和响应级别。如果地理位置服务(或其他一些后台任务)在几分钟内不可用,则应用程序仍然可以正常运行。
是否使用同一个节点进行监控用于常规访问,而是用于运行状况验证检查的特定路径,例如,/检查/{GUID}/是否在常规访问节点上。这使得应用程序中的某些功能测试可由监视工具完成,例如添加新用户注册、登录和放置测试顺序,同时还验证常规端点是否可用。
要在服务中收集的响应监视请求信息类型,以及如何返回这些信息。大多数工具和框架只查看端点返回的HTTP状态码。若要返回并验证其他信息,必须创建自定义监视工具或服务。
要收集多少信息。在检查过程中执行过多的处理会使应用程序超载并影响其他用户。所花费的时间可能使监控系统超时,因此从而将应用程序标记为了不可用。大多数应用程序都包括用于记录性能和详细错误信息的工具,如错误处理程序和性能计数器,可能已经是足够的,而不必从健康验证检查中返回其他更多信息。
缓存节点状态。太频繁运行健康检查可能会很昂贵。例如,如果健康状况来自控制面板,不希望每个请求都触发健康检查。而是定期检查系统运行状况并缓存它的状态值。公开一个节点用于返回缓存状态信息。
如何安全地对监视节点进行配置,以免被公共访问,因为这可能使应用程序暴露于恶意攻击、暴露敏感信息或被服务（DoS）攻击。通常,应该在应用程序配置中完成此操作,就能够在不需要重新启动应用程序的情况下可以方便地进行更新。考虑使用以下一种或多种方法:
使用身份验证来保护节点。如果监视服务或工具支持身份验证,则可使用请求标头中的身份验证安全密钥或通过请求传递凭据来执行身份验证。
使用模糊或隐藏的节点。例如,将不同IP地址上的终端作为应用程序URL所使用的默认端点,在非标准HTTP端口上配置端点,使用/或复杂路径来测试页面。可以在应用程序配置中指定其他端点地址和端口,并在需要时向DNS服务器添加这些端点，避免指定IP地址。
在端点暴露方法接受请求参数(如键值或操作码)。根据为参数提供的值,当收到请求时,代码可以执行特定的测试或测试集,如果参数值不被识别,则返回404(未找到)错误。可在应用程序配置中设置哪些参数值可识别。
DoS攻击可能会对基本功能测试的节点有较小影响,而不会影响应用程序的操作。理想情况下,避免使用可能暴露敏感信息的测试。如果必须返回可能对攻击者有用的信息,就要考虑如何保护节点和数据免受未经授权的访问。在这种情况下就应该考虑使用HTTPS连接并加密敏感数据,尽管这会增加服务器上的负载。
如何访问需要身份验证的端点。并非所有的工具和框架都可以配置为支持请求中包含身份验证凭据。例如,微软Azure内置的健康验证功能就无法提供身份验证凭据。一些可以支持的第三方产品是Pingdom、Panopta、NewRelic和Statuscake。
如何确保监控代理正在正确的运行。一种方法是暴露一个终端,该端点从应用程序配置中返回一个值,或一个可用于测试代理的随机值。
要确保监视系统对自身的检查,如自检和内置测试,以避免误报结果。
何时使用此模式
此模式适用于:
监控网站和web应用程序以确保可用性。
监控网站和web应用程序以检查操作是否正确。
监控中间层或共享服务,以检测并隔离可能中断其他应用程序的故障。
对应用程序中现有检测机制进行补充,如性能计数器和错误处理程序。运行状况验证检查不能代替应用程序中的日志与审计记录。检测可以为现有框架提供有价值的信息,为监视计数器和错误日志用于检测故障或其他问题。但是,如果应用程序不可用,则无法提供这些信息。
例子
下面的代码示例取自HealthCheckController类(host在(github)https://github.com/mspnp/cloud-design-patterns/tree/master/health-endpoint-monitoring),演示了如何暴露一系列运行状况检查的节点。
下面的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);
}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. If not matched it
// could return a 404 (Not Found) status.
// The obscure path can be set through configuration to hide the endpoint.
var hiddenPathKey = CloudConfigurationManager.GetSetting("Test.ObscurePath");
// If the value passed does not match that in configuration, return 404 (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账户中"管理服务"页的"警报"部分，可以为服务配置多达10个警报规则。这些规则包括为服务(如CPU负载)或每秒的请求数或错误数指定一个阈值条件,服务可以自动向每个规则中定义的地址发送电子邮件进行通知。
取决于应用程序选择的宿主机制(如网站、云服务、虚拟机或移动服务),可监视的条件也会有所变化,但所有这些情况都是可配置的。此节点应提供及时的响应,以便警报系统能够检测到应用程序是否运行正常。
可阅读有关创建警报通知的详细信息。（https://azure.microsoft.com/documentation/articles/insights-receive-alert-notifications/）
如果将应用程序托管在azure云服务或web和worker角色或虚拟机中,则可使用azure中的"流量管理器"(Traffic Manager)的其中一个内置服务。流量管理器是一种路由和负载均衡服务,它可根据一系列规则和设置将请求分配给云服务托管应用的某个实例。
除了路由请求之外,流量管理器还会定期对指定的URL端口和相对路径进行ping操作,以确定其规则中定义的应用程序的哪些实例是活动的。如果检测到状态代码200(OK),则将该应用程序标记为可用。任何其他状态代码都会导致流量管理器将应用程序标记为脱机。可以在"流量管理器"的控制台中查看该状态值,也可将该规则配置为将请求重定向到应用程序的其他实例。
但是,流量管理器等待十秒才能从监控的URL拿到响应。因此,要确保监控验证码在这段时间内被执行,从而保证从流量管理器到应用程序有足够的时间通信。
可以在这里阅读有关使用流量管理器对应用程序监控的详细信息（https://docs.microsoft.com/en-us/azure/traffic-manager/）。在多个数据中心部署指南中也讨论到了流量管理器（https://msdn.microsoft.com/library/dn589779.aspx）。
相关阅读
在实现此模式时, 以下链接可能会有用:
仪器和遥测指南。检查服务和组件的运行状况通常是通过探测来完成的,在监控应用程序性能和检测运行时发生的事件时,返回有用的信息是有帮助的。这些数据可以被回传给监测工具,作为健康监测的补充信息。仪器和遥测指南信息会收集远程应用的诊断信息。
接收警报通知（https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/insights-alerts-portal）。
这里有一个可下载的示例应用程序（https://github.com/mspnp/cloud-design-patterns/tree/master/health-endpoint-monitoring）。