CN110036600A - 网络健康数据汇聚服务 - Google Patents

Abstract

在网络健康管理器处检查与一个或多个数据源相对应的各自的网络度量集。基于所述网络度量集的分析，确定与一个或多个端点对类别相对应的网络健康状态。存储对特定端点对类别的所述网络健康状态的指示。

Description

网络健康数据汇聚服务

背景技术

许多公司和其它组织操作计算机网络，所述计算机网络互连多个计算系统以支持其操作，如其中所述计算系统被共同定位(例如，作为本地网络的一部分)或替代地定位在多个不同的地理位置中(例如，通过一个或多个专用或公共中间网络连接)。例如，容纳大量互连计算系统的数据中心已经变得司空见惯，如由单个组织和代表单个组织运营的专用数据中心，以及由作为企业的实体运营以向客户提供计算资源的公共数据中心。一些公共数据中心运营商为各种客户拥有的硬件提供网络接入、电力和安全安装设施，而其它公共数据中心运营商提供“全方位服务(full service)”设施，所述全方位服务设施还包含可供所述运营商的客户使用的硬件资源。

用于商品硬件的虚拟化技术的出现已经在管理具有不同需求的许多客户的大规模计算资源方面提供了益处，从而允许多个客户有效且安全地共享各种计算资源。例如，虚拟化技术可以通过向每个用户提供由单个虚拟化主机托管的一个或多个虚拟机来允许单个物理虚拟化主机在多个用户之间共享。每个这样的虚拟机可以表示充当不同逻辑计算系统的软件模拟，所述软件模拟向用户提供他们是给定硬件计算资源的唯一运营商的假象，同时还在各种虚拟机之间提供应用孤立和安全性。此外，一些虚拟化技术能够提供跨越两个或更多物理资源的虚拟资源，如具有跨越多个不同物理计算系统的多个虚拟处理器的单个虚拟机。

在许多情况下，虚拟化计算服务的客户可能无法控制为其虚拟机选择的特定虚拟化主机，或者可以用于其虚拟机的入站和出站业务量的网络路径。相反，客户可以依赖虚拟化计算服务的提供商来选择能够支持期望的性能水平、可用性等的虚拟化主机和网络路径。从客户的角度来看，为其使用而分配的各种类型的资源有时可能看起来像是“黑匣子(black box)”，几乎没有可用于详细故障排除或分析的工具。因此，当应用出现性能或功能问题时，客户可能无法直接快速确定问题是否是由客户直接控制之外的基础架构问题引起的，或问题是否由应用错误或客户生成的配置错误引起的。

附图说明

图1示出了根据至少一些实施例的实例系统环境，其中可以汇聚来自各种数据源的度量以经由编程接口向一个或多个提供商网络服务的客户提供网络健康状态信息。

图2示出了根据至少一些实施例的实例场景，其中由各种中介工具产生的输出可以用于生成网络健康状态信息。

图3示出了根据至少一些实施例的网络健康管理服务节点的实例部件。

图4示出了根据至少一些实施例的网络健康状态描述符的实例元素，所述网络健康状态描述符可以用于存储代表客户汇聚的信息。

图5示出了根据至少一些实施例的网络健康状态请求的实例元素，所述网络健康状态请求可以经由网络健康管理服务支持的编程接口传输。

图6示出了根据至少一些实施例的实例数据源，从所述实例数据源可以获得与虚拟化计算服务的客户机虚拟机有关的网络相关度量。

图7示出了根据至少一些实施例的虚拟化计算服务的资源的实例层级。

图8示出了根据至少一些实施例的可以代表虚拟化计算服务的客户建立的孤立虚拟网络的实例。

图9示出了根据至少一些实施例的端点对类别的实例，其中可以向网络健康管理服务的客户端提供各自的健康状态信息报告。

图10示出了根据至少一些实施例的实例基于web的接口，所述接口可以用于向虚拟化计算服务的客户端提供高级网络健康状态信息。

图11示出了根据至少一些实施例的实例基于web的接口，所述接口可以用于在各个虚拟机的级别向虚拟化计算服务的客户端提供网络健康状态信息。

图12示出了根据至少一些实施例的实例基于web的接口，所述接口可以用于指定关于分配给客户端的各种资源显示的健康相关度量。

图13示出了根据至少一些实施例的可以在网络健康管理服务处从其收集数据的工具的实例。

图14示出了根据至少一些实施例的客户机虚拟机的实例，所述客户虚拟机可以被建立为连接验证器工具的一部分，其连接验证器工具的输出由网络健康管理服务使用。

图15示出了根据至少一些实施例的连接验证器代理的实例，所述连接验证器代理可以安装在客户客户机虚拟机和客户驻地以供网络健康管理服务使用。

图16示出了根据至少一些实施例的到客户数据中心的网络路径的实例，关于哪些度量可以由网络健康管理服务获得。

图17示出了根据至少一些实施例的实例系统环境，其中通过网络健康监测服务可以利用从与封装协议相关联的网络数据包跟踪会话收集的数据。

图18提供了根据至少一些实施例的使用在不同虚拟主机处实例化的虚拟机之间的封装的网络数据包流的概述。

图19示出了根据至少一些实施例的可以关于网络数据包跟踪会话获得的实例度量。

图20示出了根据至少一些实施例的实例系统环境，其中在通过编程接口呈现之前，可以基于受损事件的预期客户影响来过滤网络健康状态信息。

图21是示出根据至少一些实施例的可以在网络健康管理服务处执行的操作的各方面的流程图。

图22是示出根据至少一些实施例的用于汇聚和验证网络健康信息的算法的各方面的流程图。

图23是示出根据至少一些实施例的可以在网络健康管理服务处执行的操作的各方面的流程图，所述网络健康管理服务使客户端能够经由编程接口请求网络健康状态信息。

图24是示出根据至少一些实施例的可以在网络健康管理服务处执行的操作的各方面的流程图，所述网络健康管理服务提供网络健康状态信息的可定制的图形表示。

图25是示出根据至少一些实施例的可以在网络健康管理服务处执行的操作的各方面的流程图，所述网络健康管理服务基于客户影响来过滤网络健康信息。

图26是示出可以在至少一些实施例中使用的实例计算装置的框图。

尽管本文通过实例的方式针对若干实施例和说明性附图描述了实施例，但是本领域技术人员将认识到，实施例不限于所描述的实施例或附图。应当理解，附图和对其的详细描述并非旨在将实施例限制于所公开的特定形式，而是相反，其意图是覆盖落入由所附权利要求限定的精神和范围内的所有修改、等同物和替代物。本文使用的标题仅用于组织目的，并不意指用于限制说明书或权利要求的范围。如在整个本申请中所使用的，词语“可以”以允许的意义使用(即，意指具有潜在的意义)，而不是强制意义(即，意指必须)。类似地，词语“包含(include)”、“包含(including)”和“包含(includes)”意指包含但不限于。当在权利要求中使用时，术语“或”用作包含性的而不是排他性的或。例如，短语“x、y或z中的至少一个”意指x、y和z中的任何一个，以及它们的任何组合。

具体实施方式

用于在提供商网络的网络健康管理服务处执行的操作的方法和设备的各个实施例，包含描述了用于汇聚从不同粒度的各种源收集的度量以产生与分配给客户的特定资源集相关的定制并且易于理解的网络健康状态信息的技术。本文可以使用术语“网络健康状态(network health state)”或“网络健康状态(network health status)”来指示关于各种类型资源之间的网络路径的性能和可用性的信息，如下文进一步详细描述的。可以在不同实施例中以各种细节水平，例如基于顾客偏好提供健康状态信息。在高级别，可以在各个实施例中提供关于某些资源集是否已经检测到网络受损或故障的指示，并且如果是，则可以提供受损可能影响任何给定客户或特定客户的程度。在更详细的级别，在一些实施例中，可以例如根据请求向客户提供关于数据包丢失率、等待时间(包含如各种数据包大小的平均等待时间或第90百分位等待时间的汇聚统计，和/或“抖动”或随时间的等待时间变化的度量)等的统计数据。

由如公司或公共部门组织的实体设置的网络，以提供可通过互联网和/或其它网络访问的一个或多个网络可访问服务(如各种类型的基于云的计算或存储服务)到分布式客户端集，所述网络在本文中可以称为提供商网络。提供商网络有时可称为“公共云”环境。在一些情况下，提供商网络的资源可以分布在跨多个数据中心，所述数据中心进而可以分布在多个地理区域中(例如，每个区域对应于一个或多个城市、州或国家)，并且可以被组织成可用性容器或可用区域以用于故障恢复目的，如下文进一步详细描述的。可以从提供商网络的资源分组层级的各个级别的数据源和/或中介工具收集用于网络健康状态确定的基础度量-例如，可以收集指示数据中心对之间、可用性容器对之间的连接性或网络性能的度量等。

在一些提供商网络中，可以支持多租户虚拟化计算服务，以及一个或多个多租户存储服务、数据库服务等。使用这样的服务，客户可以例如从虚拟计算服务获取一组虚拟机，在所选存储服务的存储装置上存储各种数据集，并且使用虚拟机来运行访问数据集的应用。多租户服务的给定资源(例如，存储装置或计算装置)可以至少原则上用于代表多个客户账户执行的操作。通常，在至少一些提供商网络中，客户可能无法访问关于基础设施实施方式细节的信息(例如，可以为给定客户端使用的各种主机或服务器的位置)；相反，客户可以依赖提供商网络运营商来提供适当的物理和/或虚拟资源集以满足客户需求。这样，提供商网络的底层基础设施部件中的至少一些，所述底层基础设施部件可能涉及在客户感兴趣的端点之间提供连接，可以被认为是“非公开的”，并且可能对客户不可见或不可访问。在各个实施例中，网络健康管理服务可以分析关于非公共资源或装置(例如，客户可能无法访问的路由器、物理网络链路、虚拟化管理软件等)以及来自客户可见数据源(如在分配给客户的虚拟机上运行的进程)的度量，以确定可能与给定客户相关的各种端点对类别的网络健康状态。

本文使用的术语“端点对”可以指示一对资源，在所述一对资源之间网络数据包可以代表一个或多个客户在一个或两个方向上流动。例如，一个端点对可以包含作为所述对的第一元素的代表在提供商网络的虚拟化主机处的特定客户建立的客户机虚拟机，并且作为第二元素，在位于客户数据中心的主机上运行的程序。代替(或除了)在各个资源级别提供网络健康状态信息，网络健康管理服务可以提供关于各种类别的端点对的概括信息，如下文进一步详细讨论的。因此，在上文的实例中，网络健康管理服务可以(至少最初)提供关于为客户建立的一组客户机虚拟机与位于客户数据中心的一组装置之间的网络路径状态的信息，而不是报告单个客户机虚拟机与单个客户数据中心装置之间的网络路径状态。端点对类别中表示的两个端点中的每一个因此可以表示各自的资源集(一个资源集包括上文实例中的虚拟机组，而另一个资源集包括位于客户数据中心的装置组)。端点对类别的端点之间的路径可以包括一个或多个物理网络链路和/或相关网络装置的虚拟表示，在各个实施例中，业务量在对应资源集之间流过所述网络装置。这样，代表客户使用的潜在复杂物理网络的众多装置和链路可以被虚拟化为一个或多个端点对类别，为此可以提供易于理解的健康状态信息。在一些实施例中，还可以提供关于特定端点或资源的详细网络健康状态信息。在一些实施例中，客户可能能够指定或选择期望网络健康状态信息的特定端点对类别，和/或期望网络健康状态信息的特定端点。

通常，网络健康管理服务可以被设计成有效地向各种提供商网络服务的客户提供相关并且可靠的健康状态信息。可能倾向于不必要地警告客户的网络受损的“假阳性”报告(即，不存在或可能存在但不影响向其提供问题报告的特定客户的问题的报告)在各个实施例中尽可能地避免。一般而言，假阳性报告可能有几个不同的根本原因，包含例如可能不可靠的度量或数据源，无法确定给定的网络故障是否实际上会影响给定的客户等；这些类型的原因中的每一个可以由网络健康管理服务解决，如下文进一步详细描述的。例如，在提供关于网络受损事件的潜在不准确报告之前，在一些实施例中可以获得来自多个独立源的事件的证据。通过提供及时和准确的网络健康状态信息，网络健康管理服务可以使客户更容易快速确定意外的应用行为是否更可能是由基础设施问题或应用本身的问题引起的，由此可能减少调试成本。实际上，所述服务可能消耗来自各种源的大量网络相关度量，并且将度量转换为健康状态信息，这对于客户而言可能比原始度量可能更有用。在各个实施例中，一些原始度量甚至可能对客户没有意义，因为它们可能是指客户不知道的内部资源和装置。在如下文所描述的不同实施例中可以支持用于以期望的粒度级别和期望的报告频率获得网络健康状态信息的多个易于使用的编程接口。在一些实施例中，网络健康管理服务(在本文也可以称为网络健康管理器)可以作为具有其自己的一组编程接口的独立服务来实施；在其它实施例中，网络健康管理服务可以包含在如虚拟化计算服务等提供商网络的其它服务之一内。网络健康管理服务通常可以包括或利用分布在提供商网络内的多个硬件和/或软件部件(并且在一些情况下，在提供商网络之外，如安装在客户数据中心的连接验证代理，其在下文描述)。

根据一个实施例，网络健康管理器可以被配置成识别与虚拟化计算服务的客户相关联的资源相对应的一个或多个端点对类别。例如，可以基于与可以维持资源分配清单的虚拟化计算服务的控制平面或管理部件的交互来识别端点对类别。根据个体客户的需要，可以为客户建立如下文所描述的一个或多个孤立虚拟网络，并且在一些实施例中，端点对类别可以包括孤立虚拟网络之一内的虚拟机。

可以在不同实施例中获得各种网络度量集，所述网络度量集可以提供对与客户相关的端点对类别的健康的洞察。例如，可以从连接验证器工具获得第一组网络度量，而可以从基础设施监测工具或服务获得第二组网络度量。连接验证器可以包括一组代理或节点，其被配置成在一些实施例中周期性地彼此通信和/或与提供商网络外部的端点通信，包含在虚拟化计算服务处建立的虚拟机处实例化的至少一个代理。在一些实施例中，代理可以作为用户模式或应用层过程运行，并且在其它实施例中作为内核模式过程(或用户模式和内核模式部件的某种组合)运行。基础设施监测工具可以从至少一些非公共资源或装置，如路由器、物理网络链路等收集度量，所述资源或装置是客户不能直接访问的。

在一些实施例中，可以将各自的权重分配给网络度量集(或者更广泛地，分配给获得度量集的工具)，指示关于网络受损的潜在识别的度量集的相对优先级或可信度的实例。例如，网络健康管理器可访问的知识库可以包含指示提供商网络的不同位置中的各种工具的可靠性的条目，使用来自各个工具或基础数据源的数据产生网络受损的假阳性报告的次数等。分配权重时考虑的因素可以包含，例如，在各个实施例中，收集度量的物理位置、收集度量的软件/硬件栈中的逻辑位置、收集度量的最近时间(其收集时间)等。

网络健康管理器可以利用度量集和其各自的权重来确定不同端点对类别的各自的网络健康状态，并且向与客户相关联的一个或多个目的地提供状态的指示。例如，在一个实施例中，可以经由如由网络健康管理服务公开的API(应用编程接口)的编程接口接收针对网络健康状态信息的请求，并且可以响应于API调用来提供所请求的信息。在另一个实施例中，可以将用于显示客户端使用的资源的图形表示或布局以及对应的网络健康状态信息的数据集传输到客户端装置以进行呈现。

在一个实施例中，由网络健康管理器收集的至少一个度量集可以指示可能的网络受损事件，如路由器、网关或物理网络链路的故障。为了减少这种受损的假阳性报告，网络健康管理器可以尝试使用从另一个源获得的不同度量集来验证受损是否实际发生。可依赖于如似乎确认受损的独立源的数量、指示受损的连续度量集的数量、分配给度量集或其源的相对权重等因素的验证算法可以是在向客户报告受损之前使用。在至少一个实施例中，例如在提供商网络的封装协议处理部件处获得的关于网络数据包流的精细粒度信息可以用于将网络受损报告仅过滤到那些应用预计会受到受损影响的客户，如下文进一步详细讨论的。在一个这种实施例中，可以例如基于对分配给客户的资源的网络配置和/或客户正在使用的特定服务的分析来分配网络受损事件对一个或多个给定客户的应用的影响的相应概率，并且如果冲击概率超过阈值，则可以向客户提供受损事件的报告。

实例系统环境

图1示出了根据至少一些实施例的实例系统环境，其中可以汇聚来自各种数据源的度量以经由编程接口向一个或多个提供商网络服务的客户提供网络健康状态信息。如图所示，系统100包括提供商网络102，在所述提供商网络处可以实施多个网络可访问服务，包含例如虚拟化计算服务(VCS)130、存储服务(SS)140和数据库服务(DS)150。VCS、SS和DS每个可以包括分配给服务客户端使用的各种资源，以及对服务是专用的并且客户端不可访问的内部资源。例如，VCS 130可以包括多个客户机虚拟机(GVM)132，如GVM 132A、132B或132C，其中每个客户机虚拟机可以代表VCS的给定客户进行实例化。类似地，存储服务140可以包括多个客户存储资产(CSA)142，如CSA 142A和142B，而数据库服务150可以包括多个客户数据库资产(CDA)152，如CDA 152A或152B。CSA 142可以包括，例如，可通过web服务接口访问的非结构化存储对象，可通过块装置级接口访问的存储卷等。CDA 152可以包括例如关系数据库或非关系数据库的实例等。在所描绘的实施例中，可以为提供商网络的给定客户分配多个服务的资源-例如，客户C1的资源集172可以包括如图所示的GVM 132B和132C，CSA142A和CDA 152A。在一些实施例中，提供商网络可以包含图1中未示出的其它服务，如机器学习服务、并行计算服务等，并且给定客户的资源集可以包含来自那些其它服务的资源。

每个服务可以包括图1中未示出的一组管理或控制平面部件，其可以维护指示向各个客户配发或分配特定资源的信息以及各种其它类型的元数据。在一些实施例中，可以由网络健康管理服务查询这种资源分配元数据，以确定要向特定客户提供网络健康状态信息的特定端点对类别，如下文进一步详细讨论的。另外，在每个服务中，可以使用各自的特定于服务的专用资源集来支持面向客户的功能，如专用VCS资源136、专用存储服务资源146和专用数据库服务资源156。一些资源158(例如，各种物理网络链路、提供商网络的内部路由器等)可以由若干不同服务共享，并且因此可以称为跨服务资源或多服务资源。

分配给给定客户的GVM可以用于在所描绘的实施例中运行客户选择的各种应用，并且这些应用可以与使用提供商网络102的其它服务实施的资源通信和/或利用所述资源，包含例如存储服务和数据库服务。带有双箭头的虚线指示可以代表服务客户使用的网络数据包路径。例如，网络数据包可以在GVM 132B与CDA 152A之间、GVM 132C与CSA 142A之间、以及GVM 132B与外部端点170之间流动(如公共互联网的装置和/或位于如办公室或客户管理的数据中心等客户驻地的装置)。GVM 132B和CDA 152A可以被认为是一个端点对，所述端点对的网络健康状态可以是客户C1感兴趣的，GVM 132C和CSA 142A可以被认为是另一个端点对，而GVM 132B和外部端点170可以被认为是第三端点对。更广泛地，感兴趣的端点对类别可以包含{VCS 130的GVM、SS 140的CSA}、{VCS 130的GVM、DS 150的CDA}和{VCS 130的GVM、外部端点170}。应注意的是，至少在VCS 130的GVM(如SS 140)使用的一个或多个其它服务允许来自公共互联网的访问的一些实施例中，可以在VCS内建立称为虚拟专用端点的特殊端点，以使服务请求能够从VCS流向其它服务(以及对要接收的服务请求的响应)，而无需使用公共IP地址或使用公共互联网链路。

在所描绘的实施例中，可以在提供商网络处建立包括多个节点的网络健康管理服务(NHMS)110，以经由各种编程接口119向如120A或120B等客户端提供关于各种端点对类别(和/或特定端点对)的网络健康状态信息。编程接口119可以包括，例如，用于发送健康状态请求和接收对应的响应(例如，请求/响应166)的一组API、一个或多个基于web的控制台、一个或多个命令行工具和/或不一定基于web的图形用户接口(GUI)。NHMS 110可以包含多个汇聚和分析节点(AAN)112，如AAN 112A和112B，其中的每一个可以使用所描绘的实施例中的一个或多个计算装置来实施。另外，用于汇聚和呈现健康状态信息的元数据113可以在NHMS 110处维护，如知识库条目，其可以用于将信任分数或权重分配给各种度量、客户端偏好等。

AAN 112可以被配置成例如通过查询与包含VCS 130、SS 140和/或DS 150的各种服务相关联的一个或多个控制平面元数据存储来识别与所描绘的实施例中的给定客户的资源集相对应的特定端点对类别。AAN 112可以从提供商网络102的各个部分收集各种网络度量集，以便向客户端120提供相关并且可靠的网络健康状态信息。可以使用多个度量收集器(MC)，如与VCS 130相关联的MC 134、与存储服务140相关联的MC 144、与数据库服务150相关联的MC 154，以及不特定地与提供商网络的任何特定服务相关联的一个或多个MC164。在不同的实施例中，一些MC可以包括已经收集各种类型的度量的预先存在的工具，而其它MC可以表示代表NHMS本身设置的代理(例如，执行的过程或线程或硬件装置)。一些MC可以从客户可见的实体收集网络度量，如请求/响应消息成功率，而其它MCS可以从如资源136、146、156或158的专用资源收集度量。通常，如图1中的非虚线箭头所指示，网络度量信息可以从提供商网络的基础资源流向MC，并且在所描绘的实施例中从MC流向AAN。在度量被传递到AAN之前，可以在至少一些实施例中在一个或多个MC处执行初步汇聚或概括级别。应注意的是，在至少一个实施例中，一些AAN可以直接从一个或多个源收集网络度量，例如，不利用中介MC。

在一些实施例中，可以对应于各种分层和/或基于位置的服务资源分组来设置各自的AAN 112和MC集。例如，如下文所讨论的，在一些实施例中，可以在提供商网络的每个数据中心的每个房间中设置各自的AAN和/或MC，在所述房间中用于给定服务的资源被定位。一般而言，NHMS 110可以被设计成能够通过组合从各种数据源获得的信息来检测各种粒度级别的网络问题或受损，从而可以快速地向客户端120提供适当的网络健康状态信息。

AAN可以在所描绘的实施例中将各自的权重或信任分数分配给各个MC和/或各个度量集，例如，基于各种因素，如网络受损的假阳性报告的历史、软件/硬件栈内的数据源的级别、数据源的位置等。使用权重和收集的度量，可以生成指示不同端点对类别的当前(和/或过去)网络健康状态的各自的描述符或记录。在一些实施例中，可以估计给定网络受损对给定客户的应用的影响的相应概率，并且如果概率超过阈值，则可以提供受损的指示。在各个实施例中，在向客户端120呈现问题的指示之前，可以从多个源获得指示潜在网络问题的证据的确认。可以经由适当的编程接口119的集向所描绘的实施例中的一个或多个目的地提供与给定客户有关的健康状态信息。在一些实施例中，至少一些网络健康状态信息可以至少临时地存储在存储库中，例如用于趋势分析。

中介工具

图2示出了根据至少一些实施例的实例场景，其中由各种中介工具产生的输出可以用于生成网络健康状态信息。在所描绘的场景中，可以利用在各种数据源210处生成的网络相关度量以及服务使用元数据270，以通过一个或多个NHMS节点230为客户端240产生规划后网络健康状态信息260。数据源可以包含例如一个或多个GVM(如在数据源210A的情况下)、一个或多个网络链路(如在数据源210E的情况下)等。对于一些数据源类别，提供商网络可以以工具的形式提供现有的度量收集器，所述工具还可以用于其它控制平面功能。在所描绘的实施例中，这些工具可以由NHMS用作中介220。例如，连接验证器工具220A可以在所描绘的实施例中从各种GVM获得请求/响应消息成功率度量，而基础设施监测工具220B可以检查跨所选网络链路的等待时间和数据包丢弃率。

在各个实施例中，还可以在NHMS处直接从至少一些基础数据源收集网络度量，如数据源210K的情况。应注意的是，从NHMS节点230的角度来看，中介工具220可以被认为是数据源，即使由中介工具提供的数据进而可以从其它资源获得。中介工具220可以各自提供不同格式的数据，并且NHMS节点可以负责解析所提供的各种数据记录、将它们归一化为标准格式、消除来自不同工具的度量所应用的资源之间的歧义、映射度量到不同的端点对类别等。服务使用元数据270可以指示在所描绘的实施例中由给定客户使用的特定提供商网络服务和特征，以及分配给客户的每个服务的特定资源。服务使用元数据270可以有助于识别应该向给定客户端240提供网络健康状态信息260的特定端点类别。网络健康状态信息260可以被描述为在所描绘的实施例中规划，例如，可以提供与各个客户端账户相关的相关信息的定制概要(而不是适用于整个服务或提供商网络的网络健康状态信息的通用表示)。在某些情况下，例如，即使两个客户具有位于特定数据中心的同一房间中的资源，也可以基于所使用的特定服务和/或资源的网络配置的差异向两个客户提供不同的健康状态信息。

网络健康管理服务节点部件

图3示出了根据至少一些实施例的网络健康管理服务节点的实例部件。如图所示，网络健康管理服务(NHMS)节点302(其可以与图1的汇聚和分析节点112相对应)可以包括例如客户端账户资源集检测器304、一个或多个度量记录解析器306、数据源消歧器308、权重分配器312、状态汇聚器/验证器314和/或呈现管理器316。在一些实施例中，图3中示出的个别部件可以作为单独的软件过程或执行的线程实施。在至少一个实施例中，一些部件可以以固件和/或硬件实施。

客户端账户资源集检测器304可以例如通过与提供商网络的一个或多个服务的各自的控制平面(即，管理)部件352的通信来确定与给定客户端账户相关联的客户正在使用的(或已经被分配给)提供商网络服务的集合，和/或正在使用的各种服务的特定资源。如上文所提及的，可以在NHMS节点302处从各种数据源收集与网络相关的度量。获得的度量记录可以由各种中介工具和/或数据源不同地格式化，并且一个或多个解析器306可以从度量记录中提取相关信息。在至少一些情况下，可以从多于一个数据源接收与相同底层网络流有关的度量。例如，各自的主机处的两个应用层过程可以提供关于主机之间的网络业务量的各自的数据包丢失率，而如路由器或交换机等中介网络装置还可以提供关于在主机之间传送的数据包的信息。数据源消歧器308可以负责使用各种基于相关的技术中的任何一种来识别在所描绘的实施例中一个或多个度量集对应的特定基础资源。在一些实施例中，各种工具或数据源可以表达不同单元中的相同基础现象的测量，并且这种测量可以例如通过消歧器308或解析器306归一化到公共单元。

可以将各自的权重或信任分数分配给在所描绘的实施例中提供度量集的度量集或数据源。权重分配器312可以考虑许多不同的因素。例如，知识库354可以包含指示关于网络受损的假阳性报告的历史的记录377以及其输出用于这种报告的数据源或工具。另外，在一些实施例中，知识库354可以包含指示软件/硬件/固件栈的特定层的数据源位置记录378，在各种数据源、各种数据源的物理或地理位置等处从中收集网络相关度量。在一些实施例中，权重分配器312还可以考虑定时和重复相关因素379-例如，如果从给定数据源或中介工具获得的三个连续度量集指示可能已经发生网络受损事件，则权重分配给所述数据源或工具可能高于最后获得的最后五个度量集中的两个指示网络受损的情况。最近收到的给定度量集也可能起作用-例如，如果一个度量集MS1的收集时间过去是十分钟，而不同度量集MS2的收集时间是所述部分中的一分钟，MS1可能具有比MS2更低的信任分数或分配的权重(其它因素相同)。在一个实施方式中，自收集度量集以来经过的时间可以用作用于分配权重或信任分数的函数中的衰减项(例如，线性或指数衰减)。

状态汇聚器和验证器314可以负责组合所收集的度量中含有的信息以及分配给度量的权重，以及生成各种端点对类别(和/或特定端点对)的网络健康状态概要和/或细节。在各个实施例中，汇聚信息可以以健康状态描述符的形式或下面在图4的上下文中描述的那种记录的形式存储。在一些实施例中，可以使用添加与给定端点对类别相对应的不同度量集的加权表示并且然后基于不同源的数量对总和进行归一化的公式来获得所述类别的网络健康状态概要。在至少一些实施例中，还可以将概率或置信水平分配给网络健康状态-例如，关于特定时间点的给定端点对类别，可以将90％概率分配给“无受损”状态，可以将9％的概率分配给“部分受损”状态，并且可以将1％的概率分配给“大范围受损”状态。在一个实施例中，汇聚器/验证器部件可以被配置成利用从独立源获得的多个度量集来验证某些类型的网络健康状态-例如，可以使用第二或第三工具或数据源来确认明显的网络受损事件。

呈现管理器318可以负责适当地格式化网络健康状态信息以便传输到各个目的地。例如，一组端点对的网络健康状态可以以人类可读的格式呈现给一组目的地(如感兴趣的各方的电子邮件地址)，并且以机器可读的格式用于另一组目的地(如警报生成器程序等)。在至少一个实施例中，可以由呈现管理器318产生可以用于生成客户资源的图形表示和对应健康状态信息的数据集，并且将其传输到一个或多个客户端显示装置。取决于客户指示的偏好和/或在NHMS处做出的概括决定，在一些实施例中，在给定时间或在给定消息/报告中，可以仅传输在节点302处汇聚的(并且在网络健康状态描述符中记录的)总网络健康信息的子集。应注意的是，在一些实施例中，图3中示出的一些部件可以不在一个或多个NHMS节点处实施。在一个实施例中，可以为各种功能指定各自的NHMS节点集-例如，一些节点可以负责度量集收集和解析、其它节点用于权重分配、其它用于汇聚/验证网络健康状态、以及其它节点用于格式化或呈现状态信息。

健康状态描述符元素

图4示出了根据至少一些实施例的网络健康状态描述符的实例元素，所述网络健康状态描述符可以用于存储代表客户汇聚的信息。这些描述符可以由NHMS节点准备和/或存储，并且描述符的内容的子集(或全部)可以用于向客户端目的地提供网络健康状态报告或结果。如图所示，给定健康状态描述符402除了其它元素之外还可以包含客户端标识符403、描述符所应用的端点对类别404、时间戳或时间段406、与受损相关的概要状态408、请求/响应成功统计410、等待时间统计412、数据包丢失率统计414、趋势信息416和/或用于描述符中含有的信息的特定数据源或工具的标识符418。

客户端标识符403可以指示例如提供商网络的客户端账户，代表其生成描述符402的其余部分中存储的网络状态信息。如前所提及的，在各个实施例中，可以在NHMS处确定关于为给定客户提供网络健康状态信息的端点对类别的集。下面在图9的上下文中进一步详细地讨论了若干端点对类别的实例。在所描绘的实施例中，可以针对各个端点对类别周期性地生成各自的描述符402。在其它实施例中，与多个端点对类别有关的网络健康状态信息可以存储在单个描述符内。

时间戳或时间段元素406可以指示在所描绘的实施例中收集用于生成健康状态信息的度量的时间(或时间段)。与受损相关的概要状态408可以经由类别404表示的端点对之间的网络路径提供数据包流条件的高级概述。可以从各个实施例中的(通常很小的)选项集中选择给定端点对类别的概要状态，例如，其中单独选项可以表示与端点对类别相关联的网络业务量的对应程度的受损。在一个实施例中，可以使用颜色编码方案(例如，在可以显示从描述符402导出的数据集的客户端侧显示装置处)以指示受损的严重性，其中颜色为绿色或者字为绿色指示连接未受损(数据包正在流动而没有明显的错误或延迟)，颜色或字为黄色指示连接部分受损(一些数据包可能在某些端点之间丢弃/延迟)，而颜色或字为红色指示连接严重受损(大多数数据包可能会被延迟或丢弃)。在其它实施例中可以使用高级别受损相关概要状态408的其它符号或编码。例如，在一些实施例中可以使用数字代码：例如，“0”表示无受损、“1”表示部分受损、“2”表示严重/大范围受损或者“百分比受损”方案可以使用，其中提供了由于受损而遇到问题的概率(例如，基于受故障事件影响的特定类型的资源的近似部分)。在各个实施例中，网络健康管理服务可以例如基于各自的度量范围来限定用于各种类型的端点和资源的默认的与受损相关的概要状态集。在至少一个实施例中，如下面在图5的上下文中所讨论的，客户可以指定他们自己的至少一些健康状态的定义，其可以覆盖默认定义。

可以使用多个较低级别的统计数据来导出不同实施例中的概要状态，并且在所描绘的实施例中，至少一些较低级别的统计数据可以存储在描述符402中。例如，可以通过连接验证器工具生成请求/响应成功率统计410，所述连接验证器工具使来自所选择的代理的请求消息被发送到所选择的端点并且跟踪在阈值间隔内接收到对请求消息的响应的数量。等待时间统计412可以记录消息从一个装置传输到另一个装置所花费的时间。在不同实施例中，可以收集和/或提供给网络健康管理服务的客户端的不同种类的等待时间统计412。例如，可以在一个实施方式中收集如不同数据包大小的平均等待时间等汇聚统计，而在另一个实施例中还可以或者代之以收集指示随时间的等待时间的变化的抖动统计。数据包丢失率统计414可以指示在两个端点之间的给定网络业务量时段期间丢失或丢弃的数据包的分数。可以使用在所描绘的实施例中从各种数据源收集的度量来计算或汇聚统计410、412和414中的个别统计。在一些实施例中，关于一些或所有其它统计中的最近趋势的信息416可以存储在描述符402中。在至少一个实施例中，从其输出中导出统计和/或概要的特定工具或数据源的指示还可以例如使用ID元素418存储在描述符402中。应注意的是，在各个实施例中，可以仅将描述符402中指示的信息的子集提供给网络健康管理服务的客户端-例如，在一个实施例中，至少在最初，可以仅通过编程接口向客户端提供概要信息。一些编程接口可以使客户端能够获得更多细节，如统计数据410、412或414，和/或趋势信息416。在至少一个实施例中，描述符402可以不必存储在永久存储器中。给定描述符402可以简单地表示在将从度量导出的健康状态信息报告给客户之前代表客户处理一组网络健康相关度量的中间结果。

健康状态请求元素

图5示出了根据至少一些实施例的网络健康状态请求的实例元素，所述网络健康状态请求可以经由网络健康管理服务支持的编程接口传输。如图所示，在所描绘的实施例中，请求502可以包含一个或多个客户端标识符504的指示、目标资源或服务列表506、一个或多个端点对类别508、时间段510、健康状态定义512、一个或多个报告阈值514、报告/通知机制516、报告格式518和保留设置520。

在一些实施例中，提供商网络的给定客户可以与若干客户端账户相关联-例如，可能已经为组织的不同部门或不同的协作商业实体设置了不同的账户。可以在客户端ID字段504中指示期望网络健康状态信息的客户端账户集。在一些实施例中，具有大量资源的客户可能仅希望看到与他们正在使用的资源和/或服务的子集有关的健康状态信息；可以在请求502的元素506中指示这些资源和/或服务。

在一个实施例中，代替或除了指示要为其提供网络健康状态信息的服务和/或资源之外，客户端可以指定一个或多个端点对类别508。在一些实施例中，健康状态信息可用的端点对类别的目录可以通过编程接口提供给客户，并且可以从这种目录中选择类别508。在一个实施例中，客户可以限定定制的端点对类别，例如，使用下面在图9的上下文中讨论的那种标签，并且在元素508中指示这种自定义类别。在一些实施例中，可以在请求502的元素510中指示待收集或检查度量的时间段。时间段可以以绝对或相对术语表达-例如，客户端请求可以指示逻辑等效物“使用与最近10分钟时段相对应的度量”，或“使用在2016年4月3日17:00:00GMT与17:20:00之间收集的度量”。在一些实施例中，时间段元素510可以用于获取过去的时间段的健康状态信息-例如，以帮助执行应用问题的事后分析。

在至少一些实施例中，客户端可以任选地指示网络健康管理服务将关于客户端资源报告的多个健康状态的定义512。例如，如果一对端点之间的数据包丢弃概率为10％，则一些客户端可能会限定“严重受损”状态，而如果一对端点之间的消息的平均等待时间超过T毫秒，或者如果等待时间的抖动或方差超过阈值，则其它客户端可以限定“严重受损”状态。在一些情况下，可以使用多种类型的度量来限定健康状态。例如，给定状态可以被限定为等待时间条件Cond1和数据包丢弃率条件Cond2的布尔组合(Boolean combination)。在一个这种场景中，未受损的健康状态可以由布尔组合的逻辑等效物限定“P字节数据包的第90百分位等待时间小于T1毫秒”并且“最后M分钟中的数据包丢弃率不大于D％”。一个客户端限定的状态数量可能与另一个客户端限定的数量不同。在一些实施例中，可以针对相应类别的资源或端点指示不同的状态定义。此外，除了整体受损相关状态(例如，“未受损”、“严重受损”等)之外，在至少一个实施例中，客户端可能希望获得导致确定总体状态的基础度量。在一些实施例中，还可以在请求中指示要包含在对请求502的响应中的度量的种类(例如，作为状态定义元素的一部分或在单独的元素中)。一些客户端可以指示在图4的元素408的上下文中讨论的那种与受损相关的概要状态信息是足够的，而其它客户端可能希望获得关于请求/响应成功率、数据包丢弃、平均或百分位等待时间、等待时间变化(抖动)统计等的更详细的统计。

报告阈值514可以用于指示向客户端提供健康状态信息的条件。例如，除非可能会影响客户端的应用的网络受损事件的概率有10％，否则一些客户端可能不愿意提供健康状态信息。无论是否检测到受损事件，或者仅在给定资源或端点对的状态改变时，其它客户端可能希望接收健康状态信息。在各个实施例中，客户端可以在请求502中指示多个报告或通知机制516的任何组合。例如，一些客户端可以指示电子邮件地址、文本消息地址等，而其它客户端可能希望在仪表板或图形显示器上接收健康状态信息。在一些实施例中，提供商网络的通知服务可以是可选择的通知机制，或者客户端可以简单地希望通过应用编程接口提供信息。一些客户端可能希望使用“拉”模型来获得网络健康状态，其中信息仅在被请求时提供，而其它人可能更喜欢“推送”方法，其中网络健康管理服务定期或在特定条件下主动向一个或多个目的地发送健康状态信息。在至少一些实施例中可以支持订阅模型，其中响应于单个订阅请求，可以使用指定的通知机制将多个健康状态消息传输到一个或多个订户，每个消息指示在各自的时间间隔期间一个或多个端点对类别的健康状态。报告格式518可以指示用于在所描绘的实施例中报告健康状态的编码或数据结构-例如，是否要使用JSON(JavaScript对象表示法)、XML(扩展标记语言)或纯文本，或者是否将使用哈希映射或其它数据结构。在一些实施例中，保留偏好520可以指示网络健康状态数据将在网络健康管理服务处保留的时间段(例如，一周或一个月)，例如，以便可以支持关于过去健康状态的查询。在至少一些实施例中，还可以支持用于报告健康状态信息的时间序列格式。在这种实施例中，可以为端点对类别或特定资源提供一系列网络健康状态数据记录，其中每个记录与由客户端指示或由服务选择的时间间隔内的各自的时间点相对应(例如，可以为前十分钟的每分钟提供一条记录)。时间序列的每个网络健康状态数据记录可以表示对应时间点的概要健康状态，或者在对应时间点收集的特定度量。在一些实施例中，客户端可以请求提供关于一个或多个端点对类别的健康状态随时间的各种变化的信息。例如，代替提供与特定时间相对应的静态健康状态信息报告，或者其客户明确指定其记录内间隔的时间序列，NHMS可以在几秒或几分钟内提供端点对类别的受损程度变化的指示。例如，NHMS可能会报告端点对在T1时间受损70％，在执行修复时(T1+delta1)受损50％，在时间(T1+delta1+delta2)受损20％等。在一些实施例中，可以至少部分地基于期望的时间序列持续时间和/或要报告改变的健康状态信息的时间段来设置保留偏好520。

在一些实施例中，网络健康管理服务可以实施一个或多个API，以使健康状态请求能够被发送到网络健康管理服务并且接收对应的响应。例如，在一个实施例中可以使用如getHealthState(myAccountID、resourceDescriptor、serviceDescriptor、endpointPairDescriptor、timingPreferences、healthStateDefinitions、reportingThreshold、reportingMechanism、format、retentionPeriod)等API，其中参数分别表示图5中所示的请求502的各种元素。getHealthState的一些或所有参数在各种实施方式中可以是任选的-例如，可以从用于提交请求的消息的报头推断客户的账户标识符，如果未指定resourceDescriptor或serviceDescriptor参数，则网络健康管理服务可以确定所针对的资源/服务等。在至少一个实施例中，如果并且当客户端提交不具有参数的等效“getHealthState()”，则网络健康管理服务可以确定图2中所示的一些或所有元素的适当值，例如，使用一组默认参数确定算法和从各种服务获得的元数据，并且基于这些值向客户端提供有意义的健康状态信息。应注意的是，在一些实施例中，作为使用图形用户接口控件(如鼠标点击按钮或链路)的结果，可以生成类似于图5中所指示的请求。

数据源实例

图6示出了根据至少一些实施例的实例数据源，从所述实例数据源可以获得与虚拟化计算服务的客户机虚拟机有关的网络相关度量。如前所讨论的，虚拟化计算服务(VCS)可以包括多个虚拟化主机，在单个主机处可以实例化一个或多个客户机虚拟机(GVM)。在图6所描绘的实施例中，VCS的虚拟化主机602包括两个客户机虚拟机650A和650B、以及管理虚拟机655、管理程序620、以及包含CPU 605A和605B的多个硬件装置、主存储器608、虚拟化管理卸载卡610和网络接口卡(NIC)611。

管理虚拟机655，管理程序620和虚拟化管理卸载卡610可以统称为虚拟化管理部件(VMC)。VMC可以充当GVM 650与虚拟主机的(剩余)硬件部件之间的中介，实际上向每个GVM呈现硬件的抽象或虚拟化视图。如下文进一步详细讨论的，可以在VCS处实施封装协议，这使得GVM 650能够使用不与虚拟化主机处的NIC 611相关联的网络地址彼此(以及与其它端点)通信。

每个GVM 650(以及管理VM 655)可以包括一个或多个应用，如分别是GVM 650A和650B的客户应用654A和654B以及VM 655的管理应用657，其中至少一些可能与其它GVM、VCS主机、提供商网络的其它服务的端点或提供商网络外部的端点的应用进行通信。另外，每个虚拟机可以包括各自的操作系统652(如652A到652C)，并且可以存储各自的网络相关配置设置653(例如，653A到653C)。

虚拟化主机602的NIC 611可以经由物理链路661A连接到交换机628，所述交换机可以进而经由附加物理链路661B和661C连接到路由器/网关629和/或其它网络装置631。至少在原理上，由于图6中所示的硬件和软件部件的任何组合的潜在问题，可能发生连接中断、业务流减速、数据包丢弃和其它网络受损。此外，在一些情况下，网络受损可能由不适当的配置设置653导致。结果，为了获得分配给不同客户的GVM的网络健康状态的综合视图，在一些实施例中，可以设置各自的度量收集器634以从所示的不同种类的部件中的每一个捕获度量，并且将收集的度量传递到网络健康管理服务。一些度量收集器可以包含在虚拟化主机中(例如，作为守护进程或用户模式进程)，而其它度量收集器可以在虚拟化主机外部(例如，以数据包报头分析器、嗅探器、业务流分析器、轻敲工具等形式)。在一些实施例中，度量收集器中的一个或多个可以周期性地捕获各种配置设置653并且将它们提供给网络健康管理服务以进行分析。

资源分组层级

确定客户资源的网络健康状态的复杂性可能由于资源可能分布在广泛分布的位置的事实而进一步复杂化，可能使一些位置比其它位置更彻底地用于网络测量。图7示出了根据至少一些实施例的虚拟化计算服务的资源的实例层级。如图所示，VCS 702的资源可以分散在多个区域712中，如区域712A和712B。给定区域712可以包括一组数据中心716(例如，区域712A的数据中心716A、716B和716G，或区域712B的数据中心716C和716D)。构成给定区域的数据中心可以位于彼此附近，例如，在相同的大都市区域或州内，尽管VCS区域边界与地理/政治边界之间的对应关系在至少一些实施例中可能不精确。

在所描绘的实施例中，VCS资源还可以在可用性容器(AC)714之间逻辑地划分，如区域712A的AC 714A和714B，以及区域712B的AC 714C和714D。可用性容器在某些环境中也可称为可用区。给定可用性容器可以包括一个或多个不同位置或数据中心的部分或全部，所述位置或数据中心以这种方式工程化(例如，具有独立的基础设施部件，如与电力相关的设备、冷却设备或物理安全部件)，使得给定可用性容器中的资源与其它可用性容器中的故障孤立。在图7所示的实例中，AC 714A、714C和714D各自包括单个数据中心内的资源，而AC714B的资源跨越两个数据中心712B和712G。一个可用性容器中的故障可能不会导致任何其它可用性容器中的故障；因此，给定资源的可用性简档旨在独立于不同可用性容器中的资源的可用性简档。因此，通过在各自的可用性容器中启动多个应用实例，可以保护各种类型的服务和/或应用免于在单个位置处的故障。如下文进一步详细讨论的，可以代表一些VCS客户设置包括多个可用性容器中的GVM的孤立虚拟网络，以增强客户应用的故障恢复能力。从应用可用性的角度来看，关于可用性容器之间的网络路径状态的信息对于至少一些客户可能尤其重要。

每个数据中心712可以进而包括一个或多个房间，如数据中心712B的房间722A。给定房间可以进而包括多个机架，如机架724A，其中定位有多个虚拟主机(如机架724A的虚拟主机726A)，并且每个虚拟主机可以包括零个或多个GVM(如主机726A的GVM 728A)。网络故障或其它受损可能发生在图7所示的层级的任何不同级别。在一些实施例中，还可以分层地组织网络健康管理服务的节点。例如，可以在每个区域中建立一个或多个区域级NHMS节点720(例如，720A或720B)，可以在每个可用性容器中设置AC级NHMS节点740(例如，740A到740D)，数据中心级NHMS节点718(例如，718A、718B、718G、718C或718D)可以配置在每个数据中心中，依此类推。在层级的一些级别，可以在一个实施例中配置度量收集器和汇聚/分析节点，而在其它级别，可以仅设置度量收集器或仅设置汇聚/分析节点。在至少一些实施例中，NHMS节点的层级也可以扩展到其它级别-例如，每个机架可以具有其自己的一个或多个NHMS节点，或者数据中心内的每个房间可以具有其自己的一个或多个NHMS节点。在图7所描绘的实施例中，NHMS可以负责将在层级的各个级别获得的大量详细的点对点网络度量转换成可靠的汇聚网络健康状态信息，客户可以根据需要使用所述信息来诊断和解决复杂分布式应用的网络相关问题。

孤立虚拟网络

根据其应用和安全需求，虚拟化计算服务的客户可能需要不同级别的网络孤立。图8示出了根据至少一些实施例的可以代表虚拟化计算服务的客户建立的孤立虚拟网络的实例。VCS 802在所描绘的实施例中包括至少四个可用性容器(AC)814-AC 814A到814D。示出了孤立虚拟网络(IVN)804的四个实例-全部为一个客户C1建立的IVN 804A、804B和804C，以及为不同的客户C2建立的IVN 804B。IVN 804A包括GVM 816F、816J和816M，GVM中的每一个是各自的可用性容器814的一部分。IVN 804B在两个AC中的每一个中包括两个GVM-AC814B中的GVM 816D和816E，以及AC 814C中的GVM 816G和816H。IVN 804C包括GVM 816C和816T，两者均是AC 814A的一部分。IVN 804D包括AC 814A中的GVM 816A和816B，以及AC814D中的GVM 816K和816L。

一般而言，IVN 804可以包括一个或多个客户机虚拟机和/或其它装置(如由存储服务管理的存储装置，或如虚拟或物理网关等网络装置)和提供商网络的资源。为其建立IVN的客户可以为IVN授予大量的网络配置灵活性。例如，客户可以选择一系列专用IP地址，从中将特定地址分配给各个客户机虚拟机、设置子网、为传入和传出业务量建立安全规则、创建路由表条目等，其方式与在客户拥有的设施中选择网络配置设置的方式非常相似。在所述IVN之外可能无法访问(至少默认情况下)在给定IVN 804内分配的专用IP地址；结果，客户端可以为GVM选择任意IP地址，而不必担心复制已经在IVN外部分配的地址的可能性。通常，IVN功能可以使VCS客户端能够像使用客户端拥有的资源一样设置网络配置，同时受益于提供商网络可能实现的扩展、可用性和价格相关优势。在一些提供商网络环境中，IVN也可以称为“虚拟专用云”。

在一些实施例中，分配给客户的GVM中的每一个可以属于IVN；在其它实施例中，可以将至少一些未配置为IVN的一部分的GVM分配给客户。不同的IVN可以用于各自的相关应用组，并且在一些实施例中可以为每个IVN独立地配置安全设置。默认情况下，IVN之外的资源可能无法访问给定IVN中的至少一些资源(如GVM)。在一些实施例中，可以使用虚拟和/或物理网关来启用IVN的资源与IVN外部的资源之间的连接性。一些IVN可以被配置成实现IVN的GVM与提供商网络外部的网络，例如在客户拥有的数据中心处建立的客户网络之间的安全通信。在至少一些实施例中，IVN可以表示从客户角度来看的重要资源分组抽象。因此，在这种实施例中，至少一些客户可能希望在IVN级别处获得网络健康状态信息。

端点对类别

如前所提及的，在至少一些实施例中，可以关于多个端点对类别生成网络健康状态信息。图9示出了根据至少一些实施例的端点对类别的实例，其中可以向网络健康管理服务的客户端提供各自的健康状态信息报告。端点对类别的每个端点可以表示在各个实施例中具有一些共同特性的集的资源集-例如，给定资源集中的资源可以具有公共地理位置或网络配置设置，或者给定资源集中的资源可以用于实施特定服务。给定类别的端点之间的路径可以包括一个或多个物理网络链路的虚拟表示，并且可以至少部分地使用从用于与所述类别相关联的业务量的物理网络装置处获得的网络度量来导出所述类别的健康状态信息。

端点对类别920A与位于不同区域中的资源集相对应-例如，区域R1中的一个资源912A，以及区域R2中的另一个资源912B。类别920B包括位于不同可用性容器中的端点-例如，可用性容器AC1中的一个资源914A，以及不同可用性容器AC2中的第二资源914B。类别920C包括位于不同的孤立虚拟网络中的端点，如孤立虚拟网络IVN1中的客户机虚拟机GVM1，以及IVN2中的第二GVM、GVM2。

在类别920D中，端点之一是公共互联网资源918B(例如，公共互联网的网站)，而另一端点是VCS的IVN(IVN1)内的GVM(GVM1)。在类别920E中，端点930B中的一个与作为客户驻地网络的一部分的资源相对应，而第二端点是VCS的IVN(IVN1)内的资源(GVM1)。端点对类别920E表示跨服务网络业务量，例如，在一个提供商网络服务(如VCS)的资源932A与另一个提供商网络服务(如存储服务或数据库服务)的资源932B之间。如前所提及的，在一些实施例中，由VCS 130的GVM访问的一个或多个其它服务可以允许客户端从公共互联网提交请求。在一些这种实施例中，可以在VCS内建立特殊端点(称为虚拟专用端点)，其使得能够使用提供商网络资源使服务请求从VCS流向其它服务(以及对要接收的服务请求的响应)，而不需要表示请求/响应的数据包遍历公共互联网。在一些实施例中，用于跨服务业务量的端点对类别(类似于类别920E)可以包含用于其中一个服务的虚拟专用端点作为所述对的端点之一。

在至少一个实施例中，提供商网络的客户可以限定自定义端点对类别。例如，可以提供一组API或其它编程接口以允许客户用各自的标签标记所选择的资源集，并且然后限定端点对类别，所述端点对类别包括具有一个标签的一个资源以及具有不同标签的另一个资源。考虑一个实例场景，其中客户C1具有两个应用，App1(在第一VCS资源集上运行)和App2(在不同的一组VCS资源上运行)。使用由VCS或网络健康管理服务提供的编程接口，客户C1可以将用于App1的资源标记为“App1组(App1-group)”资源，并且将用于App2的资源标记为“App2组(App2-group)”资源。然后可以创建如920G等自定义端点对类别，与App1组与App2组的资源之间的网络通信相对应。其它自定义端点对类别可以表示组内业务量-例如，与其它App1组资源通信的App1组资源，或与App2组资源通信的App2组资源。自定义端点对类别的网络健康状态信息可以例如根据请求或者由网络健康管理服务默认提供给客户C1。一些客户可能希望获得与自定义端点和服务限定的端点的组合有关的网络健康状态信息。各种端点对类别的端点之间的路径922(例如，路径922A到922G)可以呈现各种硬件部件(例如，物理网络链路，如路由器等网络装置)的简明虚拟化视图以及用于与所述类别的端点相对应的资源之间的业务量的相关软件/固件。实际上，在各个实施例中，可以使用端点对类别来提供代表客户使用的网络部件集的虚拟化视图。在一些实施例中可以使用不同于(或除了)图9中所示的端点对类别之外的端点对类别。应注意的是，在各个实施例中，在某些情况下，向给定客户提供健康状态信息的资源可以映射到单个端点对类别；因此，可能无法为至少一些客户识别多个端点对类别。

在各个实施例中，网络健康管理服务可以负责(a)识别要向给定客户端或客户提供网络健康状态信息的端点对类别，以及(b)使用从各种数据源和/或中介工具获得的网络度量来生成所识别的端点对类别的网络健康状态信息。在一些实施例中，如前所提及的，提供商网络的各种服务的控制平面部件可能能够指示分配给给定客户的资源种类，从中可以导出可能对客户最有用的端点对类别。在至少一个实施例中，客户端可以指定期望健康状态信息的特定端点对类别，或者客户端可以创建类似于图9的类别920G的新端点对类别，所述类别可以被假设为应该为其提供健康状态信息的类别。鉴于在大型提供商网络环境中可收集的各种各样的数据源和度量，针对各个端点对类别可靠地确定健康状态的任务可以涉及使用各种算法来进行关联、消歧、验证和概括。例如，可以从如应用级或用户模式连接验证器、网络链路监测器、路由器、封装协议处理部件等各种源接收可能与端点对类别920B(具有各自的可用性容器中的端点)的健康状态相关的信息。可能必须解析和关联信息(就时间而言、就所涉及的资源的物理和网络位置而言等)。在一些情况下，所获得的信息的一部分可能与另一部分冲突，并且在可以生成端点对类别的健康状态的概括表示之前，可以使用验证协议(其可以涉及收集附加数据)来解决各个实施例中的这种冲突。

图形接口实例

在各个实施例中，各种编程接口可以用于以可定制的粒度提供网络健康状态信息，包含例如基于web的控制台、API、命令行工具和图形用户接口。图10示出了根据至少一些实施例的实例图形接口，所述接口可以用于向虚拟化计算服务的客户端提供高级网络健康状态信息。如图所示，接口可以包括基于web的健康控制台1002。控制台1002可以包含提供控制台内容的概述的消息区域1003，以及正在显示健康状态信息的网络部分的概括表示1010。可以使用各个图标以概要形式表示与不同端点对类别的端点相对应的多组资源，并且可以通过类别的端点之间的虚拟路径来表示多组资源之间的物理网络链路/装置。在至少一个实施例中，一旦网络健康管理服务检测到与客户端账户相关联的实体已经成功登录到与虚拟化计算服务(或提供商网络的一些其它服务)相关联的管理控制台，就可以显示类似于图10中所示的健康状态信息(并且随后可以定期刷新显示)。也就是说，登录管理控制台可以用作传输网络健康状态的图形显示的请求的等同物(以便可以不需要对健康状态信息的图形显示的显式请求)。在一个实施方式中，健康状态信息可以与管理控制台的若干标签的一个标签相关联-例如，一个标签可以提供计费信息、另一个可以提供账户简档信息、另一个可以用于请求资源分配、而另一个可以提供网络健康状态信息。

在所描绘的实例场景中，控制台示出若干端点对类别的健康状态信息，其中每对的至少一个端点是孤立虚拟网络IVN-K内的GVM。端点对类别在图10中标记为1051到1060。所示的每个端点对类别表示在一些路径集合上的网络业务流的类型，通过汇聚与各种数据源和位置相对应的度量，可以为其生成概要健康状态信息。IVN-K的GVM分布在两个可用性容器1011A和1011B中。图例1006中指示的三个符号之一(所述符号中的每一个指示网络业务量的相应程度的受损)被分配给每个端点对类别以概括网络健康状态：带有复选标记符号的圆圈指示未受损的状态，带有“X”的圆圈指示严重受损，而带有“？”的圆圈指示部分受损。在一些实施例中，可以使用颜色代码来指示网络健康问题或受损的严重性-例如，红色图标或红色文本可以用于指示极端或严重受损，黄色图标或文本可以用于指示中度或部分受损，以及绿色图标或文本可以用于指示未受损状态。在一些实施例中，可以使用其它编码方案来指示与不同网络健康状态相对应的网络业务量的受损程度。标记为“R-S”的按钮显示在健康状态符号附近，其指示受损(部分或严重受损)，并且可以用于获得关于受损的修复状态。在各个实施例中，网络健康管理服务可以选择健康状态(即，状态被认为是未受损、部分受损或严重受损的状况)中的每一个的定义。在至少一个实施例中，客户可以向网络健康管理服务提供他们自己的健康状态的定制定义，并且服务可以在报告客户资源的网络健康时使用这些定义。

端点对类别(EPC)1053的一个端点表示可用性容器1011A中的IVN-K的GVM，而另一个端点表示可用性容器1011B中的IVN-K的GVM。EPC 1051和1052表示可用性容器1011中的GVM与外部互联网之间的通信。EPC 1057表示可用性容器1011A内的IVN-K的GVM之间的网络业务量，而EPC 1158表示可用性容器1011B内的IVN-K的GVM之间的网络业务量。

在所描绘的实例中，EPC 1054表示AC 1001A中的GVM与客户拥有的数据中心DC1之间的业务量，而EPC 1055表示AC 1011B中的GVM与不同的客户拥有的数据中心DC2之间的业务量，EPC 1056表示IVN-K与另一个孤立虚拟网络IVN-L之间的业务量。EPC 1059表示AC1011A的GVM与存储服务SS1之间的业务量。EPC 1060表示AC 1011B的GVM与数据库服务DS1之间的业务量。

在图10中显示健康状态的各种端点对类别中，一个(EPC 1059)处于严重受损状态，一个(EPC 1052)处于部分受损状态，并且其余处于截止消息区域1003中指示的时间的未受损状态。缩放控件1004可以用于获得更详细的网络健康状态信息，如下面在图11的上下文中所讨论的。

图10中所示的图形显示的类型实际上提供了用于客户端的资源的“虚拟网络”表示，所述图形显示可以响应于客户端在各个实施例中提交的健康状态请求而生成。可以使用术语“虚拟网络”，因为关于实际用于客户端的网络业务量的至少一些物理装置和物理网络链路的信息可以以对应于端点对类别的图标和虚拟路径的形式被抽象。显示器的特定焦点(在所示实例中为IVN-K的GVM)可以在请求中指示，或者可以在各个实施例中由网络健康管理服务基于对请求者正在使用的资源的检查来选择。在至少一些实施例中，给定的客户端可能具有大量资源(例如，在众多区域与可用性容器之间分布的数十个IVN)，并且网络健康管理服务可能必须在给定有限量的显示空间的情况下确定如何最好地概括客户端网络的状态。用于显示客户网络健康信息的规模或粒度相关决策可以至少部分地基于显示器的特性-例如，网络健康管理服务也许有可能确定正在使用的显示装置的大小(以像素为单位)，并且可以相应地调整所显示的信息的粒度。在至少一些实施例中，可以例如可经由刷新控件1007以控制的速率自动刷新经由控制台1002显示的信息。请注意，由于新资源是代表客户分配的，或者一些资源已取消分配，后续刷新可能会导致显示不同端点对类别集的健康状态信息-即，端点对类别集、端点对成员之间的路径的状态或两者可以随时间改变。

在至少一些实施例中，客户可以提供关于经由控制台1002显示的网络健康状态信息的反馈(或者更一般地，通过任何支持的接口提供的健康状态信息)。这种反馈可以包含例如，指示客户正在经历与端点对类别或特定资源的指示的健康状态信息匹配的应用行为的确认，或者由网络健康管理服务提供的健康状态指示的矛盾。在图10中描绘的实施例中，可以使用控件1091来提供反馈(例如，其可以导致弹出文本形式或图形输入面板的显示)。在其它实施例中，至少一些健康状态图标可以具有嵌入式控件，所述嵌入式控件使得顾客能够通过点击或靠近图标本身来提供反馈-例如，通过点击与EPC 1059相关联的示出大范围受损的图标，客户可能能够确认受损状态(或者相反，指示从客户的角度来看，关于EPC1059的网络业务量没有受到受损)。在一些实施例中，也可以通过非图形接口提供这种反馈消息。例如，客户可以接收对类似于通过API提交的图5中所示的网络健康状态请求的响应，并且使用另一个API来提交指示响应中含有的网络健康状态信息的确认/矛盾的后续反馈。如命令行工具等其它接口还可以在各个实施例中用于反馈消息。

在网络健康管理服务的不同实施例中，可以以各种方式使用这种反馈消息的内容。例如，在一个实施例中，从客户获得的反馈可以被视为另一度量集，然后可以将其与来自其它源的度量一起汇聚以更新各种EPC或资源的网络健康状态信息。考虑一种场景，其中NHMS结束(并且向众多客户指示)特定可用性容器AC1与公共互联网之间的业务量以不受损的方式流动。如果来自使用AC1的大量客户的反馈与所述结论相矛盾，则汇聚的客户反馈可能被用于触发对AC1与互联网之间的业务流状态的更广泛的验证，和/或得出结论认为所述状态实际上可能部分或大范围受损。

在一个实施例中，NHMS可以使用反馈消息内容的另一种方式是在提供商网络的客户支持组织处触发各种类型的事件或操作。例如，考虑一种场景，其中在某个时间T1，NHMS得出结论受损事件已经发生，所述事件正在破坏端点集{E1}与{E2}之间的业务量。NHMS可以通知预期受到事件影响的客户，例如，使用类似于控制台1002、API等的接口。可以在提供商网络处启动调试和/或修复受损的操作。之后，在某个时间(T1+delta1)，根据各种度量和/或来自修复组织或实体的输入，NHMS可以得出结论认为受损已经确定，并且向各个客户指示维修及恢复未受损状态的完成情况。如果特定客户接收到特定EPC的健康状态应该未受损但仍继续遇到与所述EPC相关联的应用网络问题的指示，则可以向指示客户的应用继续受到负面影响的NHMS传输反馈消息。在这种场景下，NHMS可以使用矛盾的反馈消息的内容来例如打开或升级支持请求，或者使提供商网络的支持人员的成员联系接收反馈的客户。如果大量客户的应用遭受受损事件的负面影响，这种行动方案可能尤其适合，大多数客户报告他们不再遇到问题，但特定客户C1仍然继续遇到问题。在这种情况下，C1的资源或应用特有的东西可能会导致问题，并且因此可能会启动C1的支持操作。

如上文所提及的，在一些实施例中，刷新控件1007可以用于更新正在显示的信息。在其它实施例中，代替或除了提供健康状态信息的快照之外，所述健康状态信息的快照中的每一个分别指示给定时间点的网络健康，可以提供更多动态健康信息视图。在一个这种实施例中，网络健康信息的时间序列可以用图形表示，给定时间序列的个别网络健康状态记录表示在选定时间间隔内离散时间点的一个或多个资源的状态。在一些实施例中，可以在图形视图中表示对健康状态的改变(如果发生这种改变)。例如，在一种场景下，给定端点对类别的健康状态可以由视觉“未受损百分比”指示符表示。如果端点对类别由于某些故障而大范围未受损，则未受损的百分比值可能会降至零或一些小整数。在进行维修时，未受损的百分比值可能会上升，最终达到100％。在一些实施例中，可以使用图表示出受损程度的这种变化，其中X轴表示时间并且Y轴与“未受损百分比”度量相对应。具有这种动态并且自动更新的健康状态视图对于其应用受到故障影响的客户可能特别有价值。

在至少一个实施例中，可以提供关于图形视图中的健康状态信息的布局的提示。例如，可以获得关于特定端点与另一端点之间或者特定端点类别与另一端点类别之间的逻辑或物理关系的信息，其可以用于相对于彼此放置那些实体的图形表示(例如，来自如虚拟化计算服务的控制平面部件等源)。在一种场景下，可以向要显示健康状态信息的装置提供区域与可用性容器之间的包含关系，以及通常应该在可用性容器级别信息上方显示区域级别信息的指令。这种关系信息和伴随的指令可以导致网络健康状态信息的图形表示的一致的接口外观-例如，区域间信息可以一致地显示在区域内信息之上，而不管显示装置或者显示信息的特定客户。在一些实施例中，关系信息可以包含在由网络健康管理服务为图形显示器生成的数据集中，或者可以在其它实施例中单独获得。

在一些情况下，客户可能希望深入到比图10中所示的概括级别更精细的细节的粒度。图11示出了根据至少一些实施例的实例图形接口，其可用于在各个虚拟机的级别向虚拟化计算服务的客户端提供网络健康状态信息。从类似于图10的概括网络表示开始，并且使用缩放控件1104和/或图形控制台1102的其它接口元素，VCS的客户端能够在所描绘的实施例中查看各个资源之间的网络业务流状态。

在放大的网络图像1110中，焦点在于各个端点而不是端点对类别。示出了四个GVM：孤立虚拟网络IVN-K中的GVM 1110A、1110B和1110C，以及孤立虚拟网络IVN-L中的GVM1110D。在至少一些实施例中，在各个资源级别处的网络健康状态信息可以仅关于例如在选定的时间窗口内实际发生传输网络数据包的尝试的路径示出。因此，例如，在图11中描绘的场景中，虽然原则上可能是网络数据包可以在GVM 1110A与GVM 1110D之间传输的情况，但是未指示所述路径的健康状态，因为GVM 1110A和1110D可能未在相对于显示信息的时间的前T分钟内进行通信(或尝试通信)。

在所示的实例场景中，示出了GVM 1110A与五个其它端点之间的网络业务流的各自的状态：存储对象S01(其可以在提供商网络的存储服务处管理)、GVM 1110B、GVM 1110C和公共互联网端点“a.b.c.d”(例如表达为互联网协议版本4地址)和“e.f.g.h”。如由各个符号所指示(从图例1106中所示的符号集中选择)，与GVM 1110A相关联的大多数业务流的健康状态未受损。例外情况是S01与GVM 1110A之间的业务流，其显示为严重受损。

针对GVM 1110B示出了七个业务量端点：GVM 1110A、GVM 1110C、GVM 1110D、两个公共互联网端点，以及两个数据库实例DB1和DB2(例如，可以由提供商网络的数据库服务管理)。GVM 1110B与之通信的大多数端点的业务流状态显示为未受损，但互联网端点“e.f.g.h”除外，所述端点显示为部分受损。关于GVM 1110C和1110D，显示健康信息的所有业务流都未受损。

应注意的是，图11中所指示的细节水平可能对缩小某些类型的意外应用行为的根本原因非常有帮助。例如，考虑GVM 1110B与互联网端点“e.f.g.h”之间的网络路径的部分受损。由于GVM 1110A与“e.f.g.h”之间的业务量似乎未受损，这表明“e.f.g.h”本身是健康的，并且引起部分受损的潜在问题可能与GVM 1110B与“e.f.g.h”之间的路径部分相关，这与用于在GVM 1110A与“e.f.g.h”之间流动的数据包的路径不同。在各个实施例中，附加控件(如图10中所示的R-S或修复状态按钮，或图10中所示的刷新控件)也可以包含在如图11中所示的更精细的粒度显示中。在至少一个实施例中，网络健康管理服务可以在端点之间的相应方向上显示用于业务量的单独状态信息-例如，对于如数据包丢弃率的某些类型的度量，从端点E1流向端点E2的业务量的健康状态可以不同于从端点E2流向端点E1的业务量的健康状态。应注意的是，即使在图11中所示的细节级别处，也可以在至少一些情况下提供物理网络链路的虚拟表示-例如，GVM 1110A与1110B之间的路径实际上可以包含多个物理链路和/或多个物理网络装置，所有这些都使用单个箭头共同表示。

在一些实施例中，代替使用缩放控件，可以向客户端提供接口以命名他们希望查看健康状态信息的资源，以及要显示的特定健康度量集。图12示出了根据至少一些实施例的实例图形接口，其可以用于指定关于分配给客户端的各种资源显示的健康相关度量。如图所示，基于web的控制台1202可以包含消息区域1203，用于指示健康状态信息的请求参数的区域1204，以及可以示出对请求的响应的结果区域1224。

在所描绘的实施例中，客户端可以使用按钮1206来添加要为其显示网络健康状态信息的资源的名称。可以例如经由健康显示请求参数区域1204中的下拉菜单提供用于资源类型的多个选项。在各个实施例中，实例资源类型可以包含GVM、存储对象、数据库实例等。所选类型的资源的标识符可以由健康显示请求参数区域1204的“资源ID”列中的客户端提供。对应于给定的资源或资源类型，可以通过与所描绘的实施例中的“度量”列相关联的下拉菜单来提供可用健康度量的选项。在客户端已经指示要显示健康状态信息的特定资源和度量之后，“提交请求”按钮1208可以用于在所描绘的实施例中将请求传输到网络健康管理服务。在一些实施例中，所述请求可以被转换成一个或多个API调用，其中给定的API调用包含与图5中所示的元素类似的元素。

在健康显示结果区域1224中，可以针对请求中指示的资源中的每一个显示所请求的度量。例如，如图所示，对于具有标识符“GVM000223”的GVM，指示在最后10分钟内对公共互联网的请求/响应率为99.5％。对于请求所有可用度量的GVM0007713，可以显示对互联网的请求响应速率、IVN内消息等待时间和IVM间消息等待时间。对于具有标识符SO5245的存储对象，可以根据请求提供出站数据包丢弃率。应注意的是，在至少一个实施例中，客户端能够使用类似于图12中所示的接口来代替或者除了要为其提供健康状态信息的特定端点之外指定端点对类别。在各个实施例中，在图10、图11和图12的实例中以图形方式显示的信息种类还可以从网络健康管理服务以非图形或基于文本的格式获得。一般而言，可以从服务检索的信息的种类可以独立于在这种实施例中用于检索信息的接口-因此，可以使用任何支持的编程接口来检索任何允许的粒度和频率处的任何类型的网络健康相关信息。

用于获取网络度量的实例工具

如前所提及的，在一些实施例中，可以使用许多不同的中介工具来收集由网络健康管理服务进行分析和汇聚的度量。图13示出了根据至少一些实施例的可以在网络健康管理服务处从其收集数据的工具的实例。关于一些工具和相关数据源的附加细节在下文提供，例如，在图14到图19的上下文中。

网络健康管理服务1301可以使用例如所描绘实施例中的连接验证器工具1310，例如，基于与用户模式进程对和/或特权内核模式进程相关联的请求/响应成功率，获得高级连接信息。在至少一些实施例中，可以在提供商网络处或从提供商网络使用多个域名系统(DNS)服务器，例如，用于促进各种服务的控制平面部件之间以及客户应用之间的通信。一个或多个DNS监测器1330可以跟踪提供商网络的各个部分中的DNS业务量的状态-例如，测量响应DNS请求的等待时间、DNS请求的成功率等。DNS故障可能会对客户应用通信产生重大负面影响。这样，网络健康管理服务可能能够利用DNS监测器1330的输出来确定各种端点对类别的健康状态。如前所提及的，在一些实施例中，从VCS访问的一个或多个如存储服务等其它服务可以允许从公共互联网传输服务请求。在一些这种实施例中，可以在VCS内建立特殊端点(称为虚拟专用端点)，其使得能够使用提供商网络资源使服务请求从VCS流向其它服务(以及对要接收的服务请求的响应)，而不需要表示请求/响应的数据包遍历公共互联网。用于监测与这种虚拟专用端点的连接的工具1335和/或利用虚拟专用端点的业务流的性能还可以在所描绘的实施例中向NHMS提供度量。

关于虚拟化计算服务与客户驻地网络(提供商网络外部的网络，例如，在办公室位置或由客户拥有/管理的数据中心)之间的安全网络路径，可以使客户端可以使用许多机制。在各个实施例中，这种机制可以包含例如专用的直接面向客户的物理链路和/或虚拟专用网络(VPN)；关于这些替代方案的更多细节在下面的图16的上下文中提供。可以为这些连接机制中的每一个建立各自的监测器1350和1340，并且在至少一些实施例中由网络健康管理服务1301使用它们。

在至少一个实施例中，用于提供商网络的各种内部物理链路的多个监测器1320可以被配置成向网络健康管理服务1301提供度量。例如，作为提供商网络的基础设施维护功能的一部分，可以高优先级监测连接数据中心内的房间或连接数据中心对的硬件链路。在一些实施例中，如下面进一步详细讨论的，封装协议可以用于管理客户虚拟机的网络业务量，并且与封装协议相关联的监测工具1315可以被配置成向网络健康管理服务提供输入。在至少一些实施例中，图13中所示的各种监测器和工具中的每一个可以在其目标资源或协议上运行各自的测试集，例如，在由工具选择的相应间隔处，并且以各自的不同的格式生成度量。网络健康管理服务1301可以负责收集和关联独立生成的度量、解决任何模糊或冲突、将度量映射到与不同客户相关的端点对类别，以及提供易于理解的与个人客户相关的定制健康状态信息。在至少一个实施例中，类似于图13中所示的工具可以作为网络健康管理服务本身的子部件实施-例如，使用请求/响应测试的连接验证可以由网络健康管理服务的代理执行。

连接验证器工具实施方式

在各个实施例中，可以使用多种方法来实施与提供商网络的一个或多个服务相关联的连接验证器工具。图14示出了根据至少一些实施例的客户机虚拟机的实例，所述客户虚拟机可以被建立为连接验证器工具的一部分，其连接验证器工具的输出由网络健康管理服务使用。如图所示，虚拟化计算服务1410的可用性容器1414A到1414D可以各自包括许多客户客户机虚拟机(GVM)1420(即，用于运行客户应用的GVM)。例如，区域1412A的可用性容器1414A可以包括客户GVM 1420A和1420B，区域1412A的可用性容器1414B可以包括客户GVM1420D和1420E，区域1412B的可用性容器1414C可以包括客户GVM 1420G和1420H，并且区域1412B的可用性容器1414D可以包括客户GVM 1420J和1420K。

除了客户GVM之外，可以在每个可用性容器1414中建立一个或多个连接验证器GVM1425，如可用性容器1414A中的连接验证器GVM 1425A、可用性容器1414B中的1425B、可用性容器1414C中的1425C和可用性容器1414D中的1425D。与可主要用于运行客户应用的客户GVM 1420相反，连接验证器GVM中的每一个可以主要负责运行连接性测试，包括向指定端点集发送消息(以及从指定端点集接收响应)。例如，可以在所描绘的实施例中向每个连接验证GVM 1425提供对等连接验证GVM和/或一个或多个外部端点1470的网络地址的列表，并指示(a)应将请求消息发送到各种地址的各自的速率以及(b)消息的属性(例如，消息大小、网络协议、请求内容、可接受的响应内容等)。例如，根据所接收的地址和指令，每个连接验证器GVM可以每分钟向100个目的地中的每一个发送各自的200字节的有效载荷请求消息，并且跟踪所接收的响应的数量、请求/响应往返的等待时间等。类似地，当从另一个GVM接收到连接请求消息时，可以通过连接验证器GVM将对应的响应传输给请求者。在用于请求/响应通信的不同实施例中可以使用各种协议中的任何协议，如HTTP(超文本传输协议)、ICMP(互联网控制消息协议)等的变体。

在所描绘的实施例中，请求/响应成功率(例如，在指定间隔内接收到对应结果的请求的分数)和/或其它度量可以由每个连接验证器GVM 1425提供给其区域1412中的连接性报告器1430(如区域1412A中的连接性报告器1430A和区域1412B中的连接性报告器1430B)。连接验证器GVM之间的网络业务量特性(数据包丢失率、等待时间等)可以被认为是客户GVM针对类似目的地将观察到的网络业务量特性的合理近似。在所描绘的实施例中，连接验证器工具可以包括报告器1430和特殊GVM 1414。如NHMS节点1431A和1431B等网络健康管理服务(NHMS)节点1431可以从报告器1430收集连接性度量，并且至少部分地基于所描绘的实施例中的连接性度量来生成网络健康状态信息。

在至少一个实施例中，用于连接验证的可安装代理模块可以由连接验证器工具和/或网络健康管理服务提供。图15示出了根据至少一些实施例的连接验证器代理的实例，所述连接验证器代理可以安装在客户客户机虚拟机和客户驻地以供网络健康管理服务使用。在所描绘的实施例中，上文所讨论的类型的请求/响应消息测试不仅可以由连接验证器GVM 1525(例如，1525A到1525D)执行，而且可以由连接验证器(CV)代理模块或过程1527(例如，代理1527A、1527B和1527C)执行。可以在虚拟化计算服务内的客户GVM(如客户GVM1520A处的CV代理1527A，客户GVM 1520G处的CV代理1527B)处安装或激活一些CV代理，而可以在客户驻地主机1575处激活其它CV代理(如代理1527C)。

在各个实施例中，连接验证器代理可以是可配置的-例如，客户端可以决定应该由每个代理运行的测试的各种属性，应该从代理提供结果的方式(例如，如1530A或1530B等连接性报告器，或如1531A或1531B等直接连接到NHMS节点)。一些客户端可能希望在其资源的选定重要子集上安装CV代理，其中获取特定和详细的网络健康状态信息被视为高优先级；其它客户可以在其所有资源上安装CV代理。在至少一个实施例中，从CV代理接收的输入可以用于检测和/或诊断网络健康管理服务在客户驻地处的网络问题。如图所示，CV代理1527C可以向连接性报告器1530B提供度量，其可以由NHMS节点1531B分析以确定其中配置主机1575的客户端网络的状态。注意，尽管在图14和图15中示出了连接验证数据的区域级汇聚，但是在不同实施例中，可以在资源层级的各个级别收集来自连接验证器GVM和/或代理的输入。在一些实施例中，可以利用CV代理，但是可以不必实例化专用连接验证器GVM；相反，CV代理可以作为客户GVM上的各自的进程或线程启动。图14和图15中所示的连接验证器GVM、可安装代理和连接性报告器在此可以统称为连接验证器工具的节点。如前所提及的，在一些实施例中，连接验证器工具可以作为网络健康管理服务的一部分实施。

保护到客户驻地的网络路径

图16示出了根据至少一些实施例的到客户数据中心的网络路径的实例，关于哪些度量可以由网络健康管理服务获得。如图所示，提供商网络1602可以包括代表特定客户C1建立的孤立虚拟网络(IVN)1605。C1还可以在提供商网络外的多个数据中心处具有计算装置，如数据中心1640A处的装置1645A和所描绘实施例中的数据中心1640B处的装置1645B。在所描绘的实施例中，可以使用虚拟专用网络(VPN)和/或专用的直接面向客户的物理链路来建立GVM1624(代表提供商网络中的客户C1设置)与外部装置1645之间的安全网络连接。

可以在客户路由器1660与路由器共址设施1630或转接中心处的提供商网络路由器1662之间的客户C1的请求处建立直接物理链路1654。在一些环境中，这种专用物理链路可以称为“直接连接”链路，并且可以提供不必由其它客户共享的带宽。在一个实施例中，例如，客户可以选择在外部数据中心与提供商网络之间配置10Gbps(千兆位/秒)专用的直接面向客户的链路或1Gbps专用的直接面向客户的链路。在各个实施例中，各种协议中的任何协议可以用于流经直接面向客户的链路的业务量-例如，在图16中描绘的场景中，可以建立通用路由封装(GRE)协议隧道1652。

对于一些客户应用，可能不需要与直接面向客户的链路相关联的专用带宽，并且可以在客户网关与提供商网络网关1610之间建立如隧道1656等VPN隧道。在不同实施例中可以将各种不同的协议用于VPN隧道，如SSL/TLS(安全套接字层/传输层安全性)、DTLS(数据报传输层安全性)、IKE(互联网密钥交换)和IPSec(互联网协议安全性)的组合等。提供商网络网关1610可以使用不同实施例中的各种方法来实施-例如，使用在GVM上运行的协议处理引擎的集合、使用定制硬件装置等。

在所描绘的实施例中，与直接面向客户的链路的健康相关的度量可以由监测器1622A和1622B收集并且传递到如节点1631A等网络健康监测服务节点，用于与从其它源获得的度量进行分析和汇聚。监测器1622A和/或1622B可以例如在直接面向客户的链路1654上运行各种测试。类似地，可以通过运行利用隧道1656的不同测试集来由VPN监测器1624获得与提供商网络和数据中心1640B之间的虚拟专用网络连接有关的度量，并且可以传递VPN度量以用于分析和汇聚到NHMS节点1631B。在一些实施例中，NHMS节点可以包括用于解析和解释与用于客户网络与提供商网络之间的连接性的各种协议相对应的度量的逻辑，如GRE、IKE、TLS/SSL、IPSec等。应注意的是，提供商网络的一些客户可能不利用直接面向客户的链路或VPN，并且NHMS的部分责任可能包含确定VPN相关或直接与客户链路相关的网络状态信息是否与给定客户相关。应注意的是，术语“客户数据中心”可以与本文中的术语“客户拥有的数据中心”或“客户管理的数据中心”同义地使用，并且可以指至少部分由提供商网络运营商以外的实体管理、拥有或运行的前提。类似地，术语“客户装置”可以用于指代客户拥有的或客户管理的装置(如路由器1660)。

封装协议层的数据包跟踪

图17示出了根据至少一些实施例的实例系统环境，其中通过网络健康监测服务可以利用从与封装协议相关联的网络数据包跟踪会话收集的数据。在所描绘的系统中，包含虚拟计算服务(VCS)1742、存储服务1752和数据库服务1762的许多服务在提供商网络1702处实施。如前所讨论的，VCS的至少一些资源(如虚拟化主机(VH)1730A、1730B和1730C)可以分布在一个或多个孤立虚拟网络(IVN)中，如在VCS客户端的请求下建立的IVN 1725A和1725B。

在图17所示的实施例中，IVN 1725A包括多个虚拟化主机1730，包含VH 1730A和VH1730B，而IVN 1725B包括VH 1730C。每个VH 1730可以包含各自的虚拟化管理部件(VMC)1715，如VMC 1715A、1715B和1715C。如前所讨论的，VMC可以包括例如管理程序和/或在管理域中运行的操作系统的实例(有时称为“dom-0”)。在一些实施例中，如网络处理外围设备卡1733等可以执行虚拟化管理功能的子集的一个或多个硬件卡也可以被认为是VMC。在所描绘的实施例中，每个VH 1730可以用于在给定时间点实例化零个或多个GVM 1712。例如，VH1730A显示有三个GVM 1712A、1712B和1712C；VH 1730B具有1712K和1712L的GVM，而GVM1712Q在VH 1730C处实例化。除了虚拟化主机1730之外，VCS 1742还可以含有各种其它部件，包含所描述的实施例中的网络健康管理服务1758的边缘路由器1728和节点1726(例如，1726A和1726B)。应注意的是，在一些实施例中，可以在VCS 1742外部设置至少一些NHMS节点1726。

为了促进在不同虚拟化主机1730(以及GVM 1712与VCS 1742外部的实体之间，如服务1751或1752的各种网络端点，以及提供商网络1702外部的端点)处实例化的GVM 1712之间的业务量，可以在VCS 1742的各种装置处实施封装协议。负责实施封装协议的软件和/或硬件部件，标记为封装协议处理部件(EPPC)1717，被示出并入VMC 1715(包含在网络处理外围装置1733内)，以及系统100中的边缘路由器128内。例如，VH 1730A的VMC 1715A包含EPPC 1717A，VMC 1715B包含EPPC 1717B，网络处理外围装置1733包含EPPC 1717C，以及边缘路由器1728包含EPPC 1717K。在一些实施例中，如VH 1730C的虚拟化主机可以配备有网络处理外围装置1733，使得例如可以从虚拟主机的主CPU或核心卸载与实施一个或多个网络协议(如封装协议本身和/或底层传输控制协议(TCP)、用户数据报协议(UDP)或Internet协议(IP))相关联的一些计算工作负载。在一些实施例中，网络处理外围装置可以经由外围部件互连快速(PCI-Express)总线或另一类似总线附接。在一个实施例中，定制或增强型网络接口卡可以用作某些虚拟化主机的网络处理外围装置。在其中在一个或多个虚拟化主机处使用网络处理外围装置的实施例中，可以将构成主机的VMC的管理程序和/或管理域操作系统的一些与网络相关的职责委托或卸载到外围装置，并且因此，主机的CPU/核心的更多处理能力可以用于客户机虚拟机。

根据封装协议，在特定虚拟化主机(例如，VH 1730A)的特定GVM(例如，GVM 1712C)处执行并且指向不同虚拟化主机(例如，VH 1730B)处的不同GVM(例如，GVM 1712L)处的应用进程的应用进程中生成的消息可以包含在源GVM 1712C的网络软件栈处的出站基线数据包OBP1中。标记为1766B的虚线箭头表示在图17所示的示例场景中，在GVM 1712C与GVM1712L之间传输客户数据(即，在应用级别生成的消息)。术语“基线”在本文中用于指代由各种GVM的网络软件栈生成或由其接收的数据包，与由EPPC1717生成的通常较大的“封装”数据包相反。(在某些情况下，当然，消息可能足够大以需要多个基线数据包，在这种情况下，多个基线数据包中的每一个都可以被类似地封装。)假设基于IP的网络协议用于GVM到GVM通信，则出站基线数据包OBP1可以指示分配给GVM 1712C的IP地址GVMAddr1作为源IP地址，以及分配给GVM 1712L的IP地址GVMAddr2作为目的地地址。在各个实施例中，分配给GVM(或更具体地，与GVM相关联的虚拟网络接口)的IP地址通常可以与分配给所述GVM运行的虚拟化主机的IP地址不同。例如，VH 1730A可以具有分配给其的地址VHAddr1，并且VH 1730B可以具有分配给其的地址VHAddr2。为了正确地路由GVM到GVM数据包，可以使用指示GVM与虚拟化主机之间的关系的网络映射，以及为IVN 1725设置的路由表例如可以用作封装协议的一部分。

在VH 1730A的GVM 1712C处创建出站基线数据包OBP1的实例中，VH 1730A的虚拟化管理部件VMC 1715A可以拦截OBP1，并且EPPC 1717A可以准备各自的出站封装数据包OEP1。例如，OEP1可以包含由封装协议限定的一个或多个报头，并且OEP1的主体可以包含OBP1。在至少一些实施例中，OEP1可以指示主机地址VHAddr1作为源地址，并且VHAddr2(或者在朝向VH2的路由上的一些中介地址)作为目的地地址。可以使用VH 1730A的物理网络接口卡(NIC)在其朝向VH 1730B的路径上传输OEP1。当OEP1达到VH 1730B时，VMC 1715B的EPPC 1717B可以检查其内容，并且可以将包含在OEP1中的基线数据包提供给GVM 1712L。类似的封装技术可以用于关于给定GVM 1712的入站数据包(例如，在GVM 1712L处生成的基线数据包可以合并在由VMC 1715B的EPPC 1717B生成的封装数据包内，在VMC 1715A的EPPC1717A处接收和验证、提取和传递到GVM 1712C)。

在图17中描绘的场景中，客户数据业务量(例如，包含在GVM 1712处生成的基线数据包或者指向GVM 1712的封装数据包)经由边缘路由器1728在GVM 1712C与1712L、GVM1712K与1712Q以及GVM 1712B与服务存储服务1751之间流动，分别如箭头1766B、1766C和1766A所指示。通常，客户业务量可以在任何两个GVM之间流动，或者在任何给定GVM与VCS1742外部的装置之间流动。与至少一些这种通信端点对相对应，可以在所涉及的EPPC之间建立各自的数据包跟踪会话1767。例如，已经在VH 1730A的EPPC 1717A与边缘路由器1728的EPPC 1717K之间建立了数据包跟踪会话1767A，并且已经在VH 1730B的EPPC 1717B与VH1730C的EPPC 1717C之间建立了数据包跟踪会话1767B。可以在参与会话的EPPC对中的EPPC中的一个的请求下建立每个会话1767。请求会话的EPPC可以被称为会话的“发射器”或“TX”EPPC，而接受会话建立请求的EPPC可以被称为会话的“接收器”或“RX”EPPC。

可以使用多个标准中的任何一个来确定给定EPPC是否以及何时应该尝试建立(作为TX EPPC)数据包跟踪会话，以及应当选择作为会话的潜在RX EPPC的特定对等EPPC。例如，在一些实施例中，每个EPPC可以具有固定大小的跟踪资源池(例如，存储器单元)，使得必须为任何给定会话保留池的所选资源子集。EPPC可以尝试建立新的数据包跟踪会话，例如，如果最近由于另一个数据包跟踪会话的终止而释放了池的跟踪资源，或者基于如在NHMS处接收网络健康状态请求等其它标准。还可以基于若干标准的任何组合来选择承担RXEPPC角色的对等EPPC：如在TX EPPC与建议的RX EPPC之间每分钟或每秒传输至少一些封装数据包的时间间隔的长度；已经在两个EPPC之间传输的封装数据包的数量；在特定时间间隔期间在两个EPPC之间传输的字节数；或者自两个EPPC之间的先前会话结束以来经过的时间间隔的长度。并非所有通信EPPC对都可以具有在给定时间点建立的对应跟踪会话；例如，没有示出对应于客户数据路径1766B的EPPC对(EPPC 1717A和1717B)的会话。取决于正在VCS的虚拟化主机上运行的应用的通信需求，以及对EPPC上可用的跟踪资源的限制，有时可能会出现这样的情况：在给定时间点，可以仅为VCS的通信EPPC对的一小部分设置数据包跟踪会话。例如，给定的EPPC可以将封装数据包传输到数百个目的地，但是可以限制为一次参与八个或十六个跟踪会话。

会话发起或TX EPPC可以使用一个或多个封装报头或编码比特序列将封装数据包传输到所提出的RX EPPC，作为所描绘的实施例中的握手过程的一部分，以请求RX EPPC参与会话。在建立会话之后，TX EPPC可以将一些或所有封装数据包(其含有嵌入的基线数据包)标记为要跟踪的数据包。可以维持关于RX EPPC和/或TX EPPC处的跟踪数据包的许多度量，如发送的数据包总数、发送的数据总量、接收的丢弃或损坏的数据包数量、接收到的无序数据包数、与数据包相对于其它路由使用的特定路由相关联的等待时间等。周期性地或响应于触发条件，会话1767的TX EPPC可以请求到目前为止在RX EPPC处收集的度量被传输回TX EPPC。在所描绘的实施例中，TX EPPC可以将从RX EPPC获得的网络度量发送到NHMS1758的一个或多个节点1726。网络健康更新消息的调度可以基于不同实施例中的各种参数：例如，可以从RX EPPC接收的每组度量发送一个更新消息，或者可以基于从RX EPPC获得的度量的初步分析来发送或更新消息，或者可以响应于来自NHMS 1758的请求来发送更新消息。如前所讨论的，可以在NHMS 1758处分析由给定EPPC 1717发送的更新消息的内容，以生成各种端点对类别(或针对特定端点对)的网络健康状态信息。

在各个实施例中，在EPPC之间交换的用于设置、终止或改变网络数据包跟踪会话的参数和/或用于报告所收集的度量的一些或所有消息本身可以包含在封装协议报头中。在一些实施例中，用于这种管理操作的封装数据包可能不一定含有由GVMS 1712生成或为所述GVMS生成的基线数据包。因此，一些会话管理消息可以搭载到也承载客户数据(基线数据包)的封装数据包上，而其它会话管理消息可能不含基线数据包。被跟踪的数据包(如被破坏的数据包计数或丢弃的数据包计数等度量被收集的数据包)通常可以包含含有客户数据的基线数据包。在各个实施例中，还可以使用根据封装协议格式化的数据包来实施EPPC与NHMS之间的至少一些通信。通过跟踪用于客户数据的封装数据包，如果使用心跳消息或ping的健康监测代理是网络健康信息的唯一来源，则可以获得比VCS的客户端应用所体验的性能更具代表性的度量。

图18提供了根据至少一些实施例的使用在不同虚拟主机处实例化的虚拟机之间的封装的网络数据包流的概述。示出了虚拟计算服务(VCS)的两个虚拟化主机VH 1830A和VH 1830B。在所描绘的实例中，两个VH 1830可以用于相同的孤立虚拟网络(IVN)的GVM，但是即使两个VH用于不同的IVN，或者如果根本不使用IVN，也可以使用类似的数据包流路径。每个虚拟化主机可以包括一个或多个客户机虚拟机，如VH 1830A处的GVM 1812A和1812B，以及VH 1830B处的GVM 1812K和1812L。在所描绘的实施例中，可以为每个GVM 1812分配至少一个专用IP地址(如分别用于GVM 1812A、1812B、1812K和1812L的PA-A、PA-B、PA-K或PA-L)，例如，来自客户先前建立的子网的地址范围，代表其建立含有GVM的IVN。例如，如果为IVN指定了IP地址范围(以无类别域间路由或CIDR格式表达)10.0.0.0/16，并且在子网10.0.1.0/24中设置了GVM 1812A和1812B，则GVM 1812A和1812B可以分别在10.0.1.0到10.0.1.255范围内分配不同的地址。在所描绘的实施例中，地址可以被指定为“专用”，因为它们(至少在默认情况下)不是在IVN外部通告。注意，至少在一些实施例中，专用IP地址(本文档中使用的术语)可能不一定符合有关专用网络地址分配的部分或全部IETF(互联网工程任务组)标准，如RFC(评论请求)1918(对于IP版本4)或RFC 4193(对于IP版本6)。

每个GVM 1812可以包括所描绘的实施例中的一个或多个应用进程1811，如应用1811A、1811B、1811K或1811L。如1811A等给定应用可以生成要发送到如1811L等其它应用的消息。这种应用消息可以合并在由应用运行的GVM处的操作系统的网络软件栈准备的一个或多个基线网络数据包(如数据包1844A，在应用1811A的情况下)。例如，基线数据包可以将发送GVM的专用地址(例如，PA-A)指示为源IP地址，并且将预期接收方GVM的专用地址(例如，PA-L)指示为目的地IP地址。基线数据包可以由GVM的网络软件栈的低级部件经由与GVM相关联的虚拟网络接口来传输。充当GVM与硬件部件1825A之间的中介的GVM运行的虚拟化主机处的VMC 1815(例如，VMC 1815A，其可以包括管理程序和/或管理域操作系统)，可以拦截这种基线数据包1844A。VMC 1815A的EPPC 1829A可以在封装数据包1845A内包含基线数据包的内容。如前所讨论的，可以在VCS中采用封装协议，因为GVM的地址可能必须被映射到虚拟主机的地址，在虚拟主机的地址处实例化GVM以沿着到达其目的地所需的路由传输数据包。例如，VH 1830A拥有具有主机IP地址HA-A的网络接口卡，并且VH 1830B拥有具有主机IP地址HA-B的网络接口卡，而在主机1830处建立的各自的GVM具有不同于客户选择的范围的IP地址。VMC 1815A可以使用IVN的路由表、网络映射和/或其它VCS网络配置元数据(其可以包括网关和其它装置的标识符/地址等)来确定应该通过其发送封装数据包1845A的路由。封装数据包1845A可以指示VH 1830A的主机IP地址HA-A作为源，并且目标VH 1830B的主机IP地址HA-B作为目的地(尽管在某些情况下，封装数据包中指示的目的地地址可以是分配给中介装置的地址，在所述中介装置上VH 1830B的地址可以是可用的)。封装数据包1845A可以沿着适当的路线向VH 230B传输，例如，可以包含各种中介装置1885的路由，如路由器、隧道装置等。

最终可以在虚拟化主机1830B的网络接口卡(硬件部件1825B之一)处接收封装数据包1845A。封装数据包1845A可以由VMC 1815B的EPPC 1829B处理。EPPC 1829B可以解包封装数据包1845A的内容。从封装数据包1845A提取的原始基线数据包1844A可以被传递到目的地应用1811L在其运行的GVM 1812L。在应用1811L处生成并且旨在用于应用1811A的数据包可以遵循用于基线数据包1844A的反向路径。例如，具有源IP地址PA-L和目的地IP地址PA-A的基线数据包1844B(在GVM 1812L处生成)可以被EPPC 1829B拦截和封装，并且可以使用中介装置1885准备和传输对应的封装数据包1845B。其中HA-B作为其源地址并且HA-A(或中介装置地址)作为其目的地地址的封装数据包1845B最终可以达到VH 1830A。在VH 1830A处，VMC 1815A的EPPC 1829A可以从封装数据包1845B提取基线数据包1844B并且将其传送到GVM 1812A。EPPC 1829可以设置许多不同的封装协议头值或比特序列，用于建立数据包跟踪会话、在会话期间跟踪数据包、从RX EPPC获得会话的TX EPPC以用于会话等。如前所提及的，在一些实施例中，在图18的上下文中讨论的EPPC功能的至少一部分可以在虚拟化主机的外围网络处理装置处实施或执行，例如，而不是在管理程序或管理域操作系统内实施。

图19示出了根据至少一些实施例的可以关于网络数据包跟踪会话获得的实例度量。会话的TX EPPC 1902可以传输跟踪同步请求消息1922，其包含会话ID 1934(指示正在请求在RX EPPC处收集的度量的会话)，以及用于将跟踪同步请求与它们各自的响应进行匹配的同步标识符1932。可以在数据包跟踪会话期间一次或多次发送这种跟踪同步请求消息。TX EPPC可以基于不同实施例中的各种标准来确定何时发送跟踪同步消息1922-例如，以如每T秒一次等固定时间间隔，在自从发送先前的跟踪同步消息以来已经将特定数量的数据包或字节数发送到RX EPPC之后，响应于从网络健康管理服务接收的报告跟踪结果的请求等。

响应于接收到跟踪同步请求消息1922，RX EPPC 1912可以首先验证消息中的会话ID 1934对应于RX EPPC已经收集度量的会话。如果会话ID与跟踪的会话不匹配，则可以将跟踪错误消息发送到TX EPPC。如果会话ID被验证，则RX EPPC可以准备跟踪同步结果消息1976并且在所描绘的实施例中将其传输到TX EPPC 1902。结果消息1976可以包含所描述的实施例中的同步标识符1932(与请求消息1922的同步标识符相对应)和会话级网络度量1965。在一些实施例中，UDP(用户数据报协议)可以用于在VH之间传输数据包，并且可以针对不同的UDP源端口(以及TX EPPC与RX EPPC之间的对应可替代路径)收集各自的度量集。在这种实施例中，在会话期间使用的每个不同UDP源端口具有一个阵列元素的度量集阵列可以包含在结果消息1976中。在不同实施例中，可以针对每个端口(和/或作为整体的会话)收集多种不同类型的网络度量的任何组合。例如，给定端口1951A的每端口度量1967A可以包含接收的数据包总数1952A、接收到的1954A的ECN(显式拥塞通知)的数量、接收到的无序数据包的数量1956A、接收到的损坏数据包的数量1958A、以及如使用所述端口传输封装数据包所记录的最新等待时间等一个或多个等待时间措施。在一些实施例中，可以通过RXEPPC如下获得数据包传输等待时间的估计：当接收到散列改变通知消息时，指示由TX EPPC发送的下一个封装数据包将使用不同的端口(并且因此使用不同的路径)，RX EPPC可以启动定时器。当接收到下一个封装数据包时，可以停止定时器，并且可以将定时器指示的经过时间视为新路径的等待时间的度量(例如，假设TX EPPC在发送散列改变通知消息之后立即发送封装数据包)。

在一些实施例中，跟踪同步结果消息中还可以包含附加度量，如在RX EPPC处可用的一个或多个路由跟踪，其识别用于RX EPPC与TX EPPC之间的可替代路径的中介路由器和链路。在一些实施例中，图19中所示的一些网络度量可能不被收集或提供给TX EPPC。在没有收集每端口度量的实施例中，可以将整个会话的单个度量集合提供给TX EPPC而不是每个端口包含一个条目的阵列。在至少一些实施例中，可以从基线数据包中提取源GVM和目标GVM的标识符或专用IP地址，并且可以将这种标识符包含在收集的度量中，以便可以在每GVM级别上，而不是在EPPC级别或除了EPPC级别之外执行分析。图19中所示类型的详细度量可以使得能够在网络健康管理服务处生成精细粒度健康状态信息。在一些实施例中，这种信息可用于过滤网络健康受损的报告，如下文进一步详细讨论的。应注意的是，在一些实施例中可以使用在封装协议层测量网络性能和健康状态的不同方法-例如，EPPC对可以周期性地向彼此发送不含客户数据的消息。

基于客户影响过滤网络健康信息

图20示出了根据至少一些实施例的实例系统环境，其中在通过编程接口呈现之前，可以基于受损事件的预期客户影响来过滤网络健康状态信息。在系统2000中，虚拟化计算服务2010的资源可以分布在若干可用性容器中，包含可用性容器2014A。可用性容器2014A的数据中心2016A包括代表众多客户使用的资源，包含客户C1、C2和C3。不同客户使用的各自的资源集可以至少部分地彼此重叠。例如，如图所示，资源集2075A(由客户C1使用)、2075B(由客户C2使用)和2075C(由客户C3使用)的交叉点是非空的。资源2075可以包含，例如，客户端的虚拟机被实例化的虚拟化主机、网络链路、如路由器、网关等装置等。某些资源(如网络链路和特定于网络的装置)可能是非公开的-也就是说，至少在默认情况下，客户可能无法直接访问某些资源的信息。

尽管使用了前面讨论过的各种工具和数据源，但是大型提供商网络中的资源之间的不同资源和网络路径的数量有时可能太大而不能允许持续捕获和维护所有可能的端点的健康状态信息。例如，VCS 2010(和/或提供商网络的其它网络可访问服务)可以包括数十万个主机，其中的个别主机可以用于实例化数十个客户机虚拟机，并且可以建立大量的网络装置以支持GVM之间以及GVM与其它服务的资源之间的通信。因此，在至少一些场景中，网络健康管理服务(NHMS)可用的度量可能并不总是足够完整，无法立即确定给定的网络健康受损事件(如特定路由器或交换机的硬件或软件故障)是否会影响代表给定客户运行的应用。

在所描绘的实施例中，NHMS节点2020可以使用从如连接验证器、DNS监测器、VPN监测器等各种数据源和工具收集的一些度量来检测网络健康受损事件2050的发生。图20中示出的示例网络健康受损事件2050可以是本地化的，其意义在于其仅影响数据中心2016A的资源的子集，因此仅影响可用性容器2014A的资源的子集。然而，即使应用利用数据中心2016A的资源，确定任何特定应用是否将受到事件2050的影响可能不是简单的事情。根据至少一个实施例，NHMS可以基于多个因素来估计或计算关于事件2050是否将影响应用的概率。例如，使用如在图17到图19的上下文中讨论的封装协议处理部件(EPPC)之间的数据包跟踪会话收集的封装协议层度量2022，指示各种客户正在使用的特定服务和特征的元数据2024，和/或资源网络配置和位置元数据2026可以用于确定所描绘的实施例中的应用影响的概率。网络配置设置信息可以例如指示IP地址、子网、孤立虚拟网络标识符等，其进而可以映射到数据中心内的物理位置。封装协议层信息可以提供与驻留在特定虚拟化主机处的虚拟机的数据包丢失、等待时间等有关的度量，并且因此可以用于识别其应用在虚拟化主机上运行的特定客户。服务使用信息可以更容易地确定给定的受损事件是否会影响客户-例如，如果受损事件是用于VCS与存储服务SS1之间的业务量的路由器的故障，并且客户C1没有使用SS1，则可以估计影响C1的故障的概率是低的。

取决于估计的影响概率，可以在呈现给客户之前过滤关于受损事件2050的信息。例如，过滤算法2030可以确定事件2050将影响客户C1的概率低于阈值，并且NHMS节点2020因此可以将状态消息2014A传输到C1，指示与C1相关的一个或多个端点对类别未受损(如符号2060A所指示)。类似地，如果客户C2的应用受影响的概率是事件2050低于阈值，则可以向C2提供指示C2的端点对类别未受损的状态信息2014B。相反，在所描绘的场景中，可以估计对C3的应用的负面影响的概率高于阈值。因此，状态信息2014C可以指示与C3相关的一个或多个端点对类别的受损状态(如符号2061所指示)。在所描绘的实施例中，除了状态信息本身之外，还可以向客户C3提供受损事件的通知2017。在一些实施例中，还可以提供客户C3可以用来请求与受损事件相对应的修复状态的接口(例如，类似于图10中所示的R-S按钮)。

在一些实施例中，可以提供受损事件的通知作为网络健康状态的一部分，甚至提供给可能不受事件影响的那些客户-例如，可以通知客户C1事件2050已经发生，但是C1的应用保持不受影响。例如，这种通知可能有助于减少客户对受损事件的不确定性。例如，如果客户C1了解(例如，来自社交媒体或其它来源)在提供商网络上发生了故障事件，但不确定所述事件是否影响C1的应用，则确认C1的应用未受影响的消息可能会有所帮助。在各个实施例中，可以响应于健康状态请求或查询来提供状态信息2014。在一些实施例中，即使没有接收到特定健康状态请求，也可以将健康状态信息2014推送到客户装置。在至少一些实施例中，可以提供客户的联网资源的图形表示，以及各种端点对类别和/或各个端点对的健康状态。在不同的实施例中，可以采用在图1到图19的上下文中描述的技术和算法中的一个或多个的组合来促进图20中所示的信息过滤的类型。例如，NHMS可以在向客户提供事件的指示之前使用多个独立数据源来验证受损事件2050已经发生。在确定与给定端点对类别相对应的健康状态之前，可能必须解析和关联从各种数据源获得的信息等。

网络健康状态确定和报告的方法

图21是示出根据至少一些实施例的可以在网络健康管理服务处执行的操作的各方面的流程图。如元素2101所示，可以识别从中收集网络度量以导出与提供商网络的各种客户或客户端有关的网络健康状态信息的数据源集。在一些情况下，可以使用中介工具来获得度量，而在其它情况下，可以直接从如用户模式应用、操作系统、虚拟化管理部件等基础数据源获得度量。在不同的实施例中可以采用各种各样的中介工具，包含例如具有执行请求/响应测试的一组节点的连接验证器工具，或者可以访问与客户不可见或不可访问的非公共资源有关的度量的各种基础设施监测器。例如，基础设施监测器可以执行测试，所述测试监测提供商网络的各个部分之间的所选硬件链路、涉及DNS查询的测试、VPN业务流、跨上述类型的专用直接面向客户的物理链路的业务量等。在一些实施例中，可以在封装协议层建立数据包跟踪会话以获得与流入/流出客户客户机虚拟机的数据包相关联的度量，并且可以在网络健康管理服务处检查使用这些会话获得的度量。

可以获得来自提供商网络的服务的控制平面元数据，以确定网络健康状态信息可能与各种客户相关的特定端点对类别(元素2104)。例如，在一个实施例中，可以确定特定客户的账户标识符，并且可以从虚拟化计算服务控制平面部件获得为账户标识符建立的孤立虚拟网络(IVN)集。可以例如基于跨越IVN边界的业务流的记录或者来自服务订阅或计费元数据来确定客户从每个IVN使用的其它服务的列表。一些客户可能拥有数千个个别客户机虚拟机并且使用大量不同的服务，因此在各个端点级别提供健康状态可能不切实际或不实用。基于对元数据和/或业务流信息的检查，可以导出易于理解和/或可视化的端点对类别集，使得可以概括地向各自的客户提供网络健康信息。考虑这样的场景，其中虚拟化计算服务的控制平面部件指示特定客户C1分别在两个IVN(IVN1和IVN2)中的每一个中具有100和150个客户机虚拟机，并且每个IVN中的一半GVM是可用性容器AC1的一部分，而另一半则位于不同的可用性容器AC2中。此外，控制平面部件还提供元数据，所述元数据指示已经为每个IVN、IVN1和IVN2设置了访问公共互联网的网关。给定此信息，NHMS可能能够导出一小组端点对类别(例如，与四个{IVN，AC}组合中的每一个中的一个端点和代表公共互联网的一个端点等的组合相对应)，其可用于向C1提供易于理解的概要网络健康状态信息。在至少一些实施例中，除了逻辑包含信息(如客户的哪些GVM属于哪个IVN)之外，从服务控制平面部件收集的元数据可以包含关于分配给客户或由客户使用的资源的物理位置信息。物理位置信息在将基础设施监测器报告的度量与客户的端点对类别匹配时可能特别有用。在各个实施例中，端点对类别可以用于生成用于客户的网络资源的虚拟视图。例如，类别的端点之间的路径可以包括一个或多个物理网络链路和/或装置的虚拟表示。

可以例如周期性地从网络健康管理服务处的数据源和/或中介工具收集各自的网络相关度量集(元素2107)。在至少一些实施例中，与不同数据源相对应的度量集可以不同地格式化和/或可以以不同的速率收集。度量集还可以指在一些情况下使用不同名称或不同单元的相同基础实体，这可能需要网络健康管理服务的消歧和/或归一化。

在至少一些实施例中，可以将各自的权重或信任分数分配给不同的度量集或工具(元素2110)。可以基于不同实施例中的各种因素来分配权重，包含例如度量集或工具对应的资源的物理位置、度量集或工具对应的网络栈的层、或度量的收集时间。在一个实施例中，网络健康管理服务可访问的知识库条目可以指示给定工具在提供关于网络故障或其它受损的信息方面的可靠性，因为所述工具经常导致呈现网络受损事件的假阳性报告等。在这种实施例中，可以使用这些知识库条目的内容(其可以随着更多证据随时间变得可用而更新)来分配权重。

使用分配给收集的度量的权重，可以关于与给定客户相关的端点对类别确定网络健康状态(元素2113)。在一个实施例中，例如，可以识别与端点对类别的每个端点相对应的资源之间的网络路径，并且可以提取和分析特定地与物理和/或逻辑装置以及形成那些路径的链路相对应的度量的子集，以确定所述端点对类别的网络健康状态。由于可以从大量源和工具以高容量收集度量，因此在这种实施例中可以采用各种技术来实现大型动态数据集的有效索引和查询(例如，使用存储器内数据模型或非关系数据模型)。在一些实施方式中，可以以促进有效消除不相关度量的方式来组织和存储所收集的度量。例如，可以在一个实施方式中通过服务对度量进行分区或索引，以便如果客户的服务使用元数据指示客户未使用服务S-k，则可以快速地将与S-k有关的所有度量指定为与所述客户的端点对类别的健康状态无关。在一些实施例中，可以针对每个端点对类别以与受损相关的概要形式表达状态-例如，给定端点对类别的网络健康可被视为“未受损”、“部分受损”或“大范围受损”。代替这些特定的状态概要，在一些实施例中可以使用用于表达指示各自的受损程度的概括健康状态的其它替代方案。从加权网络度量确定概括状态可以涉及在一些实施例中使用一个或多个基于规则的算法。在一些实施例中可以采用如“如果(来自工具T1的度量集MS1指示具有概率p1>PA和p1<PB的端点对类别EPC1的受损)以及(来自工具T2的度量集MS2指示具有概率p2>PC和p2<PD的端点对类别EPC1的受损)，则EPC1的概要状态部分受损”的逻辑等效物等规则。在一个实施方式中，机器学习算法(例如，回归算法)可以用于确定各种端点对类别的概要健康状态。机器学习算法的使用可以具有以下益处：随着越来越多的证据指示在网络健康管理服务处得出的结论的准确性，可以增强所使用的一个或多个模型，从而提高准确性。在所描绘的实施例中，关于与给定客户相关联的各种端点对类别的健康状态的信息可以被传输到一个或多个目的地(例如，到客户端程序或控制台)(元素2116)。在至少一个实施例中，代替或除了将信息传输到一个或多个目的地之外，健康状态信息可以存储在持久性存储库中，例如，用于以后的分析。

图22是示出根据至少一些实施例的用于汇聚和验证网络健康信息的算法的各方面的流程图。如元素2201中所示，可以从所描绘的实施例中的各种度量收集器{MC1、MC2、MC3、……}获得各自的度量集{MS1、MS2、MS3、……}。在一些实施方式中，一些或所有度量集可以包括时间序列，其中以所选时间间隔收集或报告新度量。度量集可以在不同实施例中以不同格式或符号提供-例如，给定度量收集器可以使用任何纯文本格式，JSON、XML和/或二进制编码，如BSON(二进制JSON)等。此外，即使两个工具或度量收集器使用相同的格式(如XML)，所使用的基础数据模型(如文档类型定义或DTD)可能因工具而异。因此，网络健康管理服务可以解析从不同源接收的度量集并且将它们转换为标准或归一化格式(元素2204)。

在至少一个实施例中，度量可以被分组为时间桶(元素2207)，例如，因为从不同的收集器接收它们的速率可以变化。例如，连接验证器工具可以每分钟提供一次报告，而硬件链路的基础设施监测器可以每五秒报告一次度量，并且网络健康监测服务可能必须将每个度量集分配给选定的间隔(例如，两分钟的间隔)。不同的度量集可以使用其各自的命名方案来引用相同的基础实体或量，并且网络健康管理服务可能必须关联来自不同源的度量(元素2210)，例如，使用将一个工具使用的名称映射到另一个工具使用的名称的字典或数据库。例如，一个工具可以通过IP地址“a.b.c.d”来指代给定的虚拟化主机，而另一个工具可以通过应用标签(如“WebServer1”)或位置指示符(例如，“H04.Rk003.Ro007.DS1”指示数据中心DS1的房间7中的机架3中的第四主机)来指代虚拟化主机，并且涉及这些名称中的任何特定一个的度量可以与涉及其它名称的度量相关联。在一些实施例中，给定度量集所应用的特定资源或实体可能不一定是立即明显的-例如，可能是给定主机具有两个具有各自的IP地址“a.b.c.d”和“a.b.c.m”的NIC的情况，并且可以分别报告这两个地址的网络业务量统计。在这种场景下，网络健康管理服务可能必须检查配置数据库以消除数据的歧义-即，确定两个度量集指的是同一主机。

如前所提及的，可以例如基于客户使用的服务集，分配给客户的资源集等来确定要向客户提供健康状态信息的端点对类别集。在一些实施例中，可以从用于与类别相关联的业务量的物理网络装置收集与给定端点对类别有关的至少一些度量。可以针对给定端点对类别确定具有相关置信水平的初步健康状态，例如，使用分配给各自的度量收集器的权重和如上文所描述的报告的度量(元素2213)。例如，如果存在来自四个不同度量收集器的四个度量集，所有这些度量集似乎指示影响端点对类别的网络故障，则可以将高置信水平(例如，90％)分配给所述类别的“基本上受损”的健康状态。相反，如果四个度量收集者中的一个指示受损，一个指示没有受损，并且其余两个没有提供关于受损的任何明确结论，则可以将较低置信水平(例如，20％)分配给所述类别的“基本上受损”的健康状态，并且可以将中等置信水平(例如，40％)分配给“部分受损”和“未受损”状态。

如果与一个健康状态相关联的置信水平超过阈值(其中阈值本身可以是随时间调整或调节的参数)，如在与元素2216相对应的操作中检测到的，则当前分析迭代的端点对类别的健康状态可以被认为是可报告的(元素2228)。然而，如果没有健康状态具有超过阈值的置信水平(也在对应于元素2216的操作中确定)，则网络健康管理服务可以确定是否有额外的确认性度量来源可用于正在考虑的端点对类别。如果一个或多个这种源(其可以例如包括其输入未包含在健康状态的初步确定中的附加度量收集器)可用(如在元素2219中检测到的)，则可以从附加源获得新度量(元素2222)。基于对新度量的分析以及先前检查的度量，可以重新计算或调节端点对类别的健康状态和/或置信水平。可以再次检查置信水平以确定它是否高于阈值，并且可以迭代与元素2216、2219和2222相对应的操作，直到获得超过阈值的置信水平，或者耗尽所有附加信息源。如果数据源耗尽并且仍未达到阈值置信水平，则在所描绘的实施例中可以将端点对类别指定为不清楚或无法报告的(元素2225)。

如果仍有待分析的更多端点对类别(如在元素2231中检测到的)，则可以针对下一个端点对类别执行与元素2213到2225相对应的操作。可报告的健康状态信息可以被传输到与顾客相关联的一个或多个目的地(元素2234)。在一些实施例中，关于是否要提供关于不确定健康状态的指示(例如，如果未达到置信水平阈值)的决定可以至少部分地基于客户端指定的偏好-例如，客户端可以通过编程接口指示是否仅提供高置信水平结果或者还提供不确定的结果。

图23是示出根据至少一些实施例的可以在网络健康管理服务处执行的操作的各方面的流程图，所述网络健康管理服务使客户端能够经由编程接口请求网络健康状态信息。如元素2301所示，可以确定已经通过编程接口接收了关于客户端账户的网络健康状态信息的请求。可以在不同实施例中使用各种类型的编程接口，包含例如API、基于web的控制台、命令行工具或图形用户接口。在一些实施例中，所述请求可以包含与图5的健康状态请求502的各自的元素相对应的一个或多个参数，如客户端账户的标识符、目标资源或服务、感兴趣的端点对类别等。在至少一个实施例中，包括在请求中的过滤参数可以指示不是为与客户端账户相关联的所有端点对类别提供健康状态信息，而是响应应该提供子集的健康状态信息，或者应该仅提供汇聚度量的一些子集。在一个实施例中，健康状态信息请求可以包含一个或多个健康状态的各自的定制定义-例如，客户端可以指示用于将端点对类别指定为处于部分受损状态或大范围受损状态的规则。在各个实施例中，健康状态请求的至少一些参数可以是任选的，使得服务不要求所有客户端提供图5中指示的所有元素。在一些实施例中，所述请求可以指示客户端希望订阅关于健康状态的更新-例如，周期性地或基于对一个或多个目的地的阈值事件的检测来提供各自的健康状态消息。

如果在请求中没有明确指示客户端账户，则可以例如基于与使用编程接口相关联的授权相关会话信息或报头来识别账户(元素2304)。如果未在请求中明确指示，例如通过与一个或多个如虚拟化计算服务等其它网络可访问服务的控制平面部件通信，则可以确定要响应于请求而提供健康状态信息的端点对类别集(元素2307)。如上文所提及的，在各个实施例中，类别的端点之间的路径可以包括一个或多个物理网络链路的虚拟表示。

与识别的端点对类别中的每一个相对应，可以从所描绘的实施例中的各种数据源(其在某些情况下可以包含用于与类别相关联的业务量的一个或多个物理网络装置)和/或中介工具获得各自的网络度量集(元素2310)。基础数据源可以对应于硬件/软件栈的各种级别，如图6中所示的实体种类，并且可以在类似于图7中所示的资源层级的各个级别收集对应的度量。在各个实施例中，可以将各自的权重或信任分数分配给如上文所讨论的度量集和/或中介工具。

如前所讨论的(例如，在图22的上下文中)可以关联和汇聚从各种源和工具获得的度量，以生成端点对类别的各自的健康状态描述符(元素2313)。在至少一些实施例中，健康状态描述符可以含有与受损相关的概要状态信息，以及支持关于各种较低级别度量的汇聚统计，如平均数据包丢弃率、等待时间的平均值和百分位数、请求/响应成功率等。在一些实施例中，给定健康状态描述符可以包括与图4中所示的元素类似的元素。基于所生成的描述符的内容和/或健康状态请求中指示的过滤参数或标准，可以生成响应(元素2316)并且经由编程接口将响应传输到一个或多个目的地(元素2319)。在一些实施例中，在接收到对特定健康状态请求的响应时，客户端可以提交关于附加信息或证据的后续请求。在一个这种实施例中，健康状态描述符可以含有比第一响应中提供的信息更多的信息；例如，关于个体度量的统计信息或关于包含在描述符中的数据源/工具的信息可能不在第一响应中提供，但是可以用于后续请求。

图24是示出根据至少一些实施例的可以在网络健康管理服务处执行的操作的各方面的流程图，所述网络健康管理服务提供网络健康状态信息的可定制的图形表示。如元素2401所示，可以确定要准备与客户端账户相关联的资源的网络健康状态信息的图形表示。在一些情况下，所述确定可以响应于显式请求(例如，经由API或经由由提供网络的网络可访问服务实施的基于web的管理控制台接收)。在其它情况下，如果并且当与客户端账户相关联的实体或用户成功登录到由提供商网络的服务实施的管理控制台时，成功登录可以触发确定待提供图形表示。可以例如基于从客户端接收的网络报头或其它元数据来确定客户端侧显示装置的一个或多个特性或约束(例如像素的大小)(元素2404)。

可以识别与客户端账户相关联的资源集以及对应的端点对类别(元素2407)，例如，使用从先前讨论的一个或多个服务的控制平面部件获得的信息。如上文所提及的，在各个实施例中，类别的端点之间的路径可以包括一个或多个物理网络链路的虚拟表示。可以获得与上文所讨论类型的各种数据源(其可以在至少一些情况下包含用于与端点对类别相关联的业务量的物理网络装置)相对应的各自的网络度量组/集(元素2410)，包含至少一些与非公共资源相关的度量。

可以使用与先前描述的方法类似的方法来解析和关联度量，以获得与客户端账户相关的各种端点对类别的各自的健康状态描述符(元素2413)。至少部分地基于健康状态信息可用的显示特性和/或端点对类别的数量，可以确定概括级别的网络健康信息(元素2416)。例如，如果不同端点对类别的数量使得分别显示所有类别的度量可能使显示混乱，则可以组合与若干不同端点对类别或资源相对应的度量以产生用于显示的概括信息。在一个实施例中，例如，与公共互联网与代表客户配置的若干不同的孤立虚拟网络之间的业务流有关的度量可以被汇聚到单个“IVN到互联网”概要度量。这种概括/组合可能需要用于组合健康状态信息的规则-例如，如果N个IVN中的任何一个具有相对于公共互联网的严重受损的网络健康状态，则概括的信息还可以指示在一个实施方式中的严重受损，即使(N-1)的IVN不受受损影响。

可以生成可用于显示与客户端账户相关联的资源的图形表示的数据集，以及为各种相关端点对类别确定的网络健康状态(元素2419)。然后可以将数据集传输到提供显示的一个或多个客户端侧装置(元素2422)。任选地，客户端可以指示显示器的刷新速率，在这种情况下，可以以对应于刷新速率的间隔传输基于接收到的度量的更新数据集。

图25是示出根据至少一些实施例的可以在网络健康管理服务处执行的操作的各方面的流程图，所述网络健康管理服务基于客户影响来过滤网络健康信息。如元素2501中所示，可以例如使用从各种工具和/或数据源收集的网络度量来检测与提供商网络的一个或多个资源相关联的网络健康受损事件。在一些实施例中可以使用与在图13到图19的上下文中讨论的工具类似的工具，并且可以从类似于图7中所示的资源层级的各个级别的图6中所示的数据源获得原始度量。健康受损事件可以例如对应于提供商网络的一个或多个装置处的软件或硬件故障，如虚拟化主机、物理网络链路、路由器、网关、交换机等。

网络健康管理服务可以分析受损事件对各种客户的应用的影响(元素2504)。例如，可以检查客户正在使用的提供商网络服务的列表，可以将与受损/故障装置或模块有关的位置信息与客户端资源的位置信息相关联，可以在虚拟化计算服务的封装协议处理层处从数据包跟踪会话捕获的度量或者可以分析其它服务等。在至少一些实施例中，可以比较与受损资源和/或客户资源有关的网络配置设置的各方面-例如，与给定虚拟机、主机或网络装置相关联的子网信息可以使NHMS能够确定给定客户是否会受到故障的影响。在一个实施例中，提供商网络的库存管理系统可以含有用于各种资源的位置信息(例如，在机架级、房间级、数据中心级、可用性容器级或区域级)，并且可以确定用于给定客户的应用的主机与一个或多个受损装置的接近度，以估计受损对应用的负面影响的概率。

对于客户C1，代表其资源被分配在发生受损事件的可用性容器AC1的特定数据中心DC1内，网络健康管理服务可以确定对C1的应用的负面影响的概率低于阈值(元素2513)。结果，网络健康管理服务可以使健康状态消息M1被传输到与C1相关联的目的地(例如，可以示出客户端资源的图形表示的客户端装置)。M1可以指示与C1相关的一个或多个端点对类别(或者分配给C1的特定资源)的状态未受损(元素2522)。实际上，尽管在C1被分配了一些资源的数据中心中发生了受损事件，但是可以过滤提供给C1的网络健康状态信息以避免C1的应用受到影响的指示。

相反，网络健康管理服务可以确定对也可能正在使用DC1和AC1的资源的客户C2的应用的负面影响的概率超过阈值(元素2517)。结果，可以将不同的健康状态消息M2传输到附属于C2的目的地，指示已经发生受损事件和/或指示与C2相关的一个或多个端点对类别处于受损状态(元素2526)。也可以为许多其它客户准备类似的客户特定健康状态消息；客户C1和C2的讨论并不旨在指示网络健康状态信息的过滤仅限于任何特定数量的客户。在一些实施例中，用于决定是否要向给定客户报告受损事件的阈值概率可以是可定制的-例如，客户可以通过网络健康管理服务的编程接口指示偏好，以了解应该通知他们关于故障/受损的条件。在至少一个实施例中，即使网络健康管理服务确定客户的应用可能不受影响，也可以向客户提供受损事件发生的指示。例如，可以这样做以肯定地通知或向客户保证，虽然已经识别(并且正在解决/修复)故障，但是客户自己的应用不会受到影响。

应注意的是，在各个实施例中，除了图21到图25的流程图中所示的操作之外的至少一些操作可以用于实施上文所描述的网络健康管理技术。所示的一些操作可能在一些实施例中不实施，或者可以以不同的顺序实施，或者并行实施而不是顺序实施。

用例

上文所描述的用于在提供商网络处实施的服务的客户端以各种粒度级别提供可定制和验证的网络健康状态信息的技术在许多场景中可能是有用的。对于许多客户而言，提供商网络服务(例如虚拟化计算服务或存储服务)的资源可能看起来等同于黑匣子，在用于实施服务的装置中提供有限的可见性。当在提供商网络资源上运行的客户应用出现行为异常或性能不佳时，尤其是在网络业务量方面，客户可能不会直截了当地确定明显的问题是否是真正的问题，并且如果这是一个真正的问题，那么根本原因在于应用层还是在提供商网络的基础设施中。因此，如果问题是由基础设施级的受损引起的，则从多个独立工具收集度量并且汇聚度量以通过易于使用的接口提供客户特定的健康状态信息的技术可以减少客户在应用级调试中浪费的工作量。此外，通过确保使用多个源验证网络受损报告，并且根据对提供报告的特定客户的应用的预期或实际影响过滤网络受损报告，可以减少关于不会影响客户的故障的错误警报。

可以根据以下条款描述本公开的实施例：

1.一种系统，包括：

与提供商网络的虚拟化计算服务相关联的网络健康管理器的一个或多个计算装置；

其中所述一个或多个计算装置被配置成：

识别与和所述虚拟化计算服务的客户相关联的资源相对应的一个或多个端点对类别，其中所述一个或多个端点对类别中的端点对类别的端点之间的路径包括一个或多个物理网络链路的虚拟表示，并且其中所述一个或多个端点对类别中的特定端点对类别包括孤立虚拟网络内的端点；

从一个或多个来源获得各自的网络度量集；

至少部分地基于所述各自的网络度量集，确定与所述一个或多个端点对类别相对应的各自的网络健康状态，其中所述各自的网络度量集中的特定网络度量集是从用于与对应端点对类别相关联的网络业务的物理装置获得的；以及

至少将与所述特定端点对类别相对应的所述网络健康状态的指示传输到所选目的地。

2.根据条款1所述的系统，其中所述一个或多个计算装置被配置成：

响应于至少部分地基于来自所述一个或多个来源中的第一来源的特定网络度量集而检测到关于所述特定端点对类别的网络健康受损，

在传输对所述特定端点对类别的受损网络健康状态的指示之前，验证不同网络度量集确认所述网络健康受损。

3.根据条款1所述的系统，其中与所述特定端点对类别相对应的所述网络健康状态的指示指示所述特定端点对类别的网络业务的受损程度。

4.根据条款1所述的系统，其中所述多个网络度量集中的特定网络度量集包含以下中的一个或多个：(a)请求-响应成功率，(b)消息等待时间，(c)数据包丢失率，或(d)指示消息等待时间随着时间推移的变化的度量。

5.根据条款1所述的系统，其中所述一个或多个计算装置被配置成：

将各自的权重分配给所述各自的网络度量集中的个别网络度量集，其中分配给所述网络度量的特定集的特定权重至少部分地基于以下中的一个或多个：(a)所述特定集对应的资源的物理位置，(b)所述特定集对应的网络栈的层，或(c)所述特定集中的至少一个度量的收集时间；以及

利用所述各自的权重中的至少一个权重来确定与所述特定端点对类别相对应的所述网络健康状态。

6.根据条款1所述的系统，其中所述一个或多个来源包括(a)连接验证器和(b)基础设施监测器，其中所述连接验证器包括在所述虚拟化计算服务的特定虚拟机处实例化的节点，并且其中所述基础设施监测器配置成从所述提供商网络的专用网络装置收集特定网络度量集中的特定网络度量。

7.一种方法，包括：

由一个或多个计算装置执行：

获得与一个或多个数据源相对应的各自的网络度量集；

至少部分地基于所述各自的网络度量集，确定与一个或多个端点对类别相对应的各自的网络健康状态；以及

存储对与所述一个或多个端点对类别中的特定端点对类别相对应的至少所述网络健康状态的指示。

8.根据条款7所述的方法，进一步包括由所述一个或多个计算装置执行：

将各自的权重分配给多个网络度量集中的个别网络度量集；

其中所述确定所述各自的网络健康状态包括利用所述各自的权重。

9.根据条款8所述的方法，其中分配给所述多个网络度量集中的特定集的特定权重至少部分地基于以下中的一个或多个：(a)所述特定集对应的资源的物理位置，(b)所述特定集对应的网络栈的层，或(c)所述特定集中的至少一个度量的收集时间。

10.根据条款7所述的方法，其中所述各自的网络度量集包括指示第一资源和第二资源之间的连接性的第一网络度量集，其中所述第一资源包括第一虚拟机，并且其中所述第二资源包括第二虚拟机。

11.根据条款10所述的方法，其中所述第一虚拟机被配置在代表特定客户端建立的第一孤立虚拟网络内。

12.根据条款7所述的方法，其中所述特定端点对类别与提供商网络的特定客户端账户相关联，所述方法进一步包括由所述一个或多个计算装置执行：

识别代表所述特定客户端账户利用的一个或多个网络可访问服务；

确定所述各自的网络度量集中的特定网络度量集与用于与所述一个或多个网络可访问服务中的特定服务相关联的网络业务的物理装置有关；以及

利用所述特定网络度量集来确定所述特定端点对类别的所述健康状态。

13.根据条款7所述的方法，其中所述各自的网络度量集包括指示通过公共互联网可访问的端点和另一端点之间的连接性的第一网络度量集。

14.根据条款7所述的方法，其中所述各自的网络度量集包括指示提供商网络的第一网络可访问服务的第一资源和所述提供商网络的第二网络可访问服务的第二资源之间的连接性的第一网络度量集。

15.根据条款7所述的方法，其中获得所述各自的网络度量集中的特定网络度量集包括利用以下中的一个或多个：(a)被配置成发出域名服务(DNS)查询的工具，(b)被配置成运行虚拟专用网络(VPN)测试的工具，或(c)被配置成运行测试的工具，所述测试利用在所述提供商网络和客户网络装置之间建立的专用物理链路。

16.根据条款7所述的方法，其中所述特定端点对类别包括以下之一：(a)虚拟化计算服务的一个可用性容器内的第一端点和所述虚拟化计算服务的不同可用性容器内的第二端点，(b)一个地理区域内的第一端点和不同地理区域内的第二端点，(c)虚拟化计算服务内的第一端点和客户数据中心处的第二端点，(d)虚拟化计算服务内的第一端点和公共互联网内的第二端点，(e)虚拟化计算服务内的第一端点和不同的网络可访问服务内的第二端点，或(f)第一孤立虚拟网络内的第一端点和所述第一孤立虚拟网络外的第二端点。

17.一种非暂时性计算机可访问存储媒体，其存储程序指令，所述程序指令当在一个或多个处理器执行时：

检查与一个或多个数据源相对应的各自的网络度量集；

至少部分地基于所述第一网络度量集和第二网络度量集的所述检查，确定与一个或多个端点对类别相对应的各自的网络健康状态；以及

存储对与所述一个或多个端点对类别中的特定端点对类别相对应的至少所述网络健康状态的指示。

18.根据条款17所述的非暂时性计算机可访问存储媒体，其中所述各自的网络度量集中的特定网络度量集包括从非公共网络装置获得的度量，其中所述非公共网络装置包括以下中的一个或多个：(a)路由器，(b)网关，(c)交换机，(d)网络接口卡(NIC)，(e)将所述提供商网络的一部分连接到外部网络的物理链路，或(f)封装协议处理部件。

19.根据条款17所述的非暂时性计算机可访问存储媒体，其中所述指令当在所述一个或多个处理器上执行时：

分析与虚拟化计算服务的特定客户有关的资源分配元数据以识别所述一个或多个端点对类别，其中所述资源分配元数据指示代表所述特定客户建立的至少一个孤立虚拟网络。

20.根据条款17所述的非暂时性计算机可访问存储媒体，其中为了确定所述各自的网络健康状态，所述指令当在所述一个或多个处理器上执行时：

利用分配给多个网络度量集中的个别网络度量集的各自的权重。

21.根据条款20所述的非暂时性计算机可访问存储媒体，其中分配给所述多个网络度量集中的特定集的特定权重至少部分地基于以下中的一个或多个：(a)所述特定集对应的资源的物理位置，(b)所述特定集对应的网络栈的层，或(c)所述特定集中的至少一个度量的收集时间。

说明性计算机系统

在至少一些实施例中，实施本文所描述的一种或多种技术的一部分或全部的服务器，包含实施网络健康管理服务的各种部件的技术、网络健康管理服务使用的工具和度量收集器、网络健康状态管理中涉及的提供商网络的其它资源等可以包含通用计算机系统，所述通用计算机系统包含或被配置成访问一个或多个计算机可访问媒体。图26示出了这种通用计算装置9000。在所示实施例中，计算装置9000包含经由输入/输出(I/O)接口9030耦合到系统存储器9020(其可以包括非易失性和易失性存储器模块)的一个或多个处理器9010。计算装置9000进一步包含耦合到I/O接口9030的网络接口9040。

在各个实施例中，计算装置9000可以是包含一个处理器9010的单处理器系统，或者包含若干处理器9010(例如，两个、四个、八个或另一个合适数量)的多处理器系统。处理器9010可以是能够执行指令的任何合适的处理器。例如，在各个实施例中，处理器9010可以是实施各种指令集架构(ISA)中的任何一种的通用或嵌入式处理器，如x86、PowerPC、SPARC或MIPS ISA、或任何其它合适的ISA。在多处理器系统中，处理器9010中的每一个可以共同但不是必须地实施相同的ISA。在一些实施方式中，可以使用图形处理单元(GPU)来代替常规的处理器或作为常规处理器的补充。

系统存储器9020可以被配置成存储可由一个或多个处理器9010访问的指令和数据。在至少一些实施例中，系统存储器9020可以包括易失性和非易失性部分；在其它实施例中，可以仅使用易失性存储器。在各个实施例中，系统存储器9020的易失性部分可以使用任何合适的存储器技术来实施，如静态随机存取存储器(SRAM)、同步动态RAM或任何其它类型的存储器。对于系统存储器的非易失性部分(例如，其可以包括一个或多个NVDIMM)，在一些实施例中，可以使用基于闪存的存储器装置，包含NAND闪存装置。在至少一些实施例中，系统存储器的非易失性部分可以包含电源，如超级电容器或其它电力存储装置(例如，电池)。在各个实施例中，基于忆阻器的电阻随机存取存储器(ReRAM)、三维NAND技术、铁电RAM、磁阻RAM(MRAM)或任何各种类型的相变存储器(PCM)可以至少用于系统存储器的非易失性部分。在所示实施例中，实施如上述那些方法、技术和数据等一个或多个所期望功能的程序指令和数据被示为存储在系统存储器9020中作为代码9025和数据9026。

在一个实施例中，I/O接口9030可以被配置成协调处理器9010、系统存储器9020与装置中的任何外围装置之间的I/O业务量，包含网络接口9040或如各种类型的持久和/或易失性存储装置的其它外围接口。在一些实施例中，I/O接口9030可以执行任何必要的协议、定时或其它数据变换，以将来自一个部件(例如，系统存储器9020)的数据信号转换成适合于由另一个部件(例如，处理器9010)使用的格式。在一些实施例中，I/O接口9030可以包含对通过各种类型的外围总线连接的装置的支持，例如，如外围部件互连(PCI)总线标准或通用串行总线(USB)标准的变体。在一些实施例中，I/O接口9030的功能可以分成两个或更多个单独的部件，例如，如北桥和南桥。而且，在一些实施例中，I/O接口9030的一些或全部功能，如到系统存储器9020的接口可以直接并入到处理器9010中。

网络接口9040可以被配置成允许数据在计算装置9000和附接到网络或网络9050的其它装置9060之间交换，例如，如图1到图25所示的其它计算机系统或装置。在各个实施例中，网络接口9040可以支持经由任何合适的有线或无线通用数据网络的通信，例如，如以太网网络的类型。另外，网络接口9040可以支持经由如模拟语音网络或数字光纤通信网络等电信/电话网络，经由如光纤通道SAN的存储区域网络或经由任何其它合适类型的网络和/或协议的通信。

在一些实施例中，系统存储器9020可以是计算机可访问媒体的一个实施例，所述计算机可访问媒体被配置成存储如上文针对图1到图25所描述的程序指令和数据，用于实施对应方法和设备的实施例。然而，在其它实施例中，可以在不同类型的计算机可访问媒体上接收、发送或存储程序指令和/或数据。一般而言，计算机可访问媒体可以包含非暂时性存储媒体或如磁性或光学媒体等存储媒体，例如经由I/O接口9030耦合到计算装置9000的磁盘或DVD/CD。非暂时性计算机可访问存储媒体还可以包含任何易失性或非易失性媒体，如RAM(例如SDRAM、DDR SDRAM、RDRAM、SRAM等)、ROM等，其可以包含在计算装置9000的一些实施例中作为系统存储器9020或另一种类型的存储器。进一步地，计算机可访问媒体可以包含传输媒体或如电信号、电磁信号或数字信号等信号，经由如网络和/或无线链路等通信媒体传送，如可以经由网络接口9040实施。如图26中所示的多个计算装置的部分或全部可以用于在各个实施例中实施所描述的功能；例如，在各种不同装置和服务器上运行的软件部件可以协作以提供功能。在一些实施例中，除了使用通用计算机系统实施之外或代替使用通用计算机系统实施，可以使用存储装置、网络装置或专用计算机系统来实施所描述的功能的部分。本文所使用的术语“计算装置”是指至少所有这些类型的装置，并且不限于这些类型的装置。

结论

各个实施例可以进一步包含在计算机可访问媒体上接收、发送或存储根据前述描述实施的指令和/或数据。一般而言，计算机可访问媒体可以包含如磁性或光学媒体等存储媒体(storage media)或存储媒体(memory media)，例如磁盘或DVD/CD-ROM、易失性或非易失性媒体，如RAM(例如SDRAM、DDR、RDRAM、SRAM等)、ROM等，以及通过如网络和/或无线链路等通信媒体传送的传输媒体或如电信号、电磁信号或数字信号的信号。

如附图中所示和本文描述的各种方法代表方法的示例性实施例。所述方法可以用软件、硬件或其组合来实施。可以改变方法的顺序，并且可以添加、重新排序、组合、省略、修改等各种元素。

可以进行各种修改和改变，这对于受益于本公开的本领域技术人员来说是显而易见的。旨在包含所有这些修改和变化，并且因此，以上描述被认为是说明性的而不是限制性的。

Claims (15)

1.一种方法，包括：

由一个或多个计算装置执行：

获得与一个或多个数据源相对应的各自的网络度量集；

至少部分地基于所述各自的网络度量集，确定与一个或多个端点对类别相对应的各自的网络健康状态；以及

存储对与所述一个或多个端点对类别中的特定端点对类别相对应的至少所述网络健康状态的指示。

2.根据权利要求1所述的方法，进一步包括由所述一个或多个计算装置执行：

将各自的权重分配给多个网络度量集中的个别网络度量集；

其中所述确定各自的网络健康状态包括利用所述各自的权重。

3.根据权利要求2所述的方法，其中分配给所述多个网络度量集中的特定集的特定权重至少部分地基于以下中的一个或多个：(a)所述特定集对应的资源的物理位置，(b)所述特定集对应的网络栈的层，或(c)所述特定集中的至少一个度量的收集时间。

4.根据权利要求1所述的方法，其中所述各自的网络度量集包括指示第一资源和第二资源之间的连接性的第一网络度量集，其中所述第一资源包括第一虚拟机，并且其中所述第二资源包括第二虚拟机。

5.根据权利要求4所述的方法，其中所述第一虚拟机被配置在代表特定客户端建立的第一孤立虚拟网络内。

6.根据权利要求1所述的方法，其中所述特定端点对类别与提供商网络的特定客户端账户相关联，所述方法进一步包括由所述一个或多个计算装置执行：

识别代表所述特定客户端账户利用的一个或多个网络可访问服务；

确定所述各自的网络度量集中的特定网络度量集与用于与所述一个或多个网络可访问服务中的特定服务相关联的网络业务的物理装置有关；以及

利用所述特定网络度量集来确定所述特定端点对类别的所述健康状态。

7.根据权利要求1所述的方法，其中所述各自的网络度量集包括指示通过公共互联网可访问的端点和另一端点之间的连接性的第一网络度量集。

8.根据权利要求1所述的方法，其中所述各自的网络度量集包括指示提供商网络的第一网络可访问服务的第一资源和所述提供商网络的第二网络可访问服务的第二资源之间的连接性的第一网络度量集。

9.根据权利要求1所述的方法，其中获得所述各自的网络度量集中的特定网络度量集包括利用以下中的一个或多个：(a)被配置成发出域名服务(DNS)查询的工具，(b)被配置成运行虚拟专用网络(VPN)测试的工具，或(c)被配置成运行测试的工具，所述测试利用在所述提供商网络和客户网络装置之间建立的专用物理链路。

10.根据权利要求1所述的方法，其中所述特定端点对类别包括以下之一：(a)虚拟化计算服务的一个可用性容器内的第一端点和所述虚拟化计算服务的不同可用性容器内的第二端点，(b)一个地理区域内的第一端点和不同地理区域内的第二端点，(c)虚拟化计算服务内的第一端点和客户数据中心处的第二端点，(d)虚拟化计算服务内的第一端点和公共互联网内的第二端点，(e)虚拟化计算服务内的第一端点和不同的网络可访问服务内的第二端点，或(f)第一孤立虚拟网络内的第一端点和所述第一孤立虚拟网络外的第二端点。

11.一种包含耦接到存储器的处理器的系统，所述存储器包含程序指令，所述程序指令当在一个或多个处理器上执行时：

检查与一个或多个数据源相对应的各自的网络度量集；

至少部分地基于第一网络度量集和第二网络度量集的检查，确定与一个或多个端点对类别相对应的各自的网络健康状态；以及

存储对与所述一个或多个端点对类别中的特定端点对类别相对应的至少所述网络健康状态的指示。

12.根据权利要求11所述的系统，其中所述各自的网络度量集中的特定网络度量集包括从非公共网络装置获得的度量，其中所述非公共网络装置包括以下中的一个或多个：(a)路由器，(b)网关，(c)交换机，(d)网络接口卡(NIC)，(e)将所述提供商网络的一部分连接到外部网络的物理链路，或(f)封装协议处理部件。

13.根据权利要求11所述的系统，其中所述指令当在所述一个或多个处理器上执行时：

分析与虚拟化计算服务的特定客户有关的资源分配元数据以识别所述一个或多个端点对类别，其中所述资源分配元数据指示代表所述特定客户建立的至少一个孤立虚拟网络。

14.根据权利要求11所述的系统，其中为了确定所述各自的网络健康状态，所述指令当在所述一个或多个处理器上执行时：

利用分配给多个网络度量集中的个别网络度量集的各自的权重。

15.根据权利要求14所述的系统，其中分配给所述多个网络度量集中的特定集的特定权重至少部分地基于以下中的一个或多个：(a)所述特定集对应的资源的物理位置，(b)所述特定集对应的网络栈的层，或(c)所述特定集中的至少一个度量的收集时间。