CN113961303A - 利用重排序考虑的管理消息负荷均衡的数据中心资源监测 - Google Patents

Abstract

描述了用于数据中心中的资源监测和管理消息重新排序的技术。在一个示例中，一种计算系统包括入口引擎，用于从数据中心中的网络设备接收消息，该数据中心包括多个网络设备和计算系统；以及响应于从数据中心中的网络设备接收到消息，将消息传送到与该消息的协议类型相对应的适当的收集器应用，该消息的协议类型符合对从一个或多个网络设备向计算系统传送的消息流中存储的数据的至少一项要求。

Description

利用重排序考虑的管理消息负荷均衡的数据中心资源监测

技术领域

本公开涉及监测和改进云数据中心和网络的性能。

背景技术

虚拟数据中心正在成为现代信息技术(IT)基础设施的内核基础。特别地，现代数据中心已经广泛利用了虚拟化环境，其中诸如虚拟机或容器的虚拟主机被部署在物理计算设备的基础计算平台上并在物理计算设备的基础计算平台上执行。

大规模数据中心的虚拟化可以提供若干优点。一个优点是虚拟化可以显著改进效率。随着基础物理计算设备(即服务器)变得越来越强大，随着每个物理CPU的具有大量核的多核微处理器架构的出现，虚拟化变得更加容易和高效。第二个优点是虚拟化可提供对基础设施的重要控制。随着诸如在基于云的计算环境中的物理计算资源成为可替代资源，计算基础设施的供应和管理变得更加容易。因此，除了虚拟化所提供的效率和增加的投资回报率(ROI)之外，企业IT员工还因为其管理上的优点而通常更喜欢数据中心中的虚拟化计算集群。

一些数据中心包括用于监测数据中心内的资源、收集包括测量数据中心性能的统计在内的各种数据、然后使用所收集的数据来支持虚拟化联网基础设施的管理的机制。随着网络上对象的数量及其生成的度量标准的增长，数据中心无法依靠传统的机制来监测数据中心资源，例如有关网络的健康状况和任意潜在风险。这些机制对网络元素的规模、可用性、效率施加了限制，并且通常需要进行其他处理，例如以周期性地对网络元素进行直接轮询。

发明内容

本公开描述了用于针对计算环境进行监测、调度和性能管理的技术，诸如部署在数据中心内的虚拟化基础设施。这些技术提供了对操作性能和基础设施资源的可视性。如本文所述，这些技术可以利用分布式架构中的分析来提供接近或看似近实时和历史监测、性能可见性和动态优化，以改进计算环境内的编排、安全性、计费和计划。所述技术可在例如混合、私有或公共企业云环境内提供优点。这些技术可适应各种虚拟化机制，诸如容器和虚拟机，以支持多租户、动态且不断发展的企业云。

本公开的各方面大体上描述了用于在监测任意示例数据中心中的网络基础设施元件和其他资源的同时维持捕获的各种数据的可行性的技术和系统。这些技术和系统依靠与捕获的数据的协议类型相对应的策略来确定如何管理(例如正确传送)传输捕获的数据的消息。根据一个示例策略，某些协议类型要求在目的地服务器上对消息进行适当的排序；与正确顺序的任意偏离都可能阻止消息的存储数据成为性能可见性和动态优化以改进计算环境中的编排、安全性、计费和计划的可行数据集合。与本公开不同的技术和系统不依赖于这样的策略，因此，在没有适当的收集器应用的情况下无序到达目的地服务器或到达目的地服务器的任意消息都可能使消息的存储数据不可用或无效，从而破坏了网络基础设施的管理。

通常，本文描述的策略实施是指满足根据消息的遥测协议类型使存储的消息数据(例如捕获的遥测数据)成为可行数据集合的一个或多个要求。策略实施的示例可以涉及以下各项的任意组合：修改捕获的遥测数据的结构或遥测数据本身，经由负荷均衡、高可用性和/或自动缩放来提供可伸缩性，标识与遥测协议相对应的适当收集器应用类型和/或类似物。

在示例计算系统中，示例入口引擎对传入消息执行策略实施，以确保存储的消息数据基于消息的协议类型来遵守每个相应的策略。一个示例策略为上述捕获的遥测数据规定了一个或多个要求，这样，如果满足每个要求，则可以从消息中提取捕获的遥测数据，将其组装成可行的数据集合，然后进行处理，以进行网络基础设施监测和管理流程。使这些消息满足其对应的策略要求，可使在目的地服务器上运行的一个或多个应用收集并成功分析捕获的遥测数据，以获得有关数据中心资源的有意义的信息(例如健康状况或风险评估)。(大多数情况下)完全消减或消除了消息混乱或丢失导致数据中心中断的情况。出于这个原因和这里描述的其他原因，本公开提供了计算机联网中的技术改进以及对解决不同计算机联网协议类型的消息的问题的技术解决方案的实际应用。

在一个示例中，一种方法包括：由在计算系统的处理电路上运行的入口引擎从数据中心中的网络设备接收消息，该数据中心包括多个网络设备和该计算系统；并且响应于从数据中心中的网络设备接收到消息，入口引擎将消息传递到与该消息协议类型相对应的适当的收集器应用，该消息协议类型符合对从多个网络设备传送到计算系统的消息中存储的数据的至少一项要求。

在另一个示例中，一种计算系统包括：存储器；以及与所述存储器通信的处理电路，所述处理电路被配置为执行包括入口引擎的逻辑，所述入口引擎被配置为：从包括多个网络设备和所述计算系统的数据中心中的网络设备接收消息；并响应于从数据中心中的网络设备接收到消息，将消息传递到与该消息的协议类型相对应的适当的收集器应用，该消息的协议类型符合从一个或多个网络设备传递到计算系统的消息流中存储的数据的至少一项要求。

在另一示例中，一种计算机可读介质，包括指令，该指令用于使得可编程处理器能够：通过在计算系统的处理电路上运行的入口引擎从数据中心中的网络设备接收消息，该数据中心包括多个网络设备和计算系统；并响应于从数据中心中的网络设备接收到消息，将消息传送到与该消息的协议类型相对应的适当的收集器应用，该消息的协议类型符合从一个或多个网络设备传递到计算系统的消息流中存储的数据的至少一项要求。

一个或多个示例的细节在附图和以下描述中阐述。根据说明书和附图以及根据权利要求书，其他特征、目的和优点将是显而易见的。

附图说明

图1是示出了根据本发明的一个或多个方面的示例网络的概念图，该示例网络包括示例数据中心，在该示例数据中心中，利用具有重新排序考虑的管理的消息负荷均衡来监测资源。

图2是更详细地示出了根据本公开的一个或多个方面的图1的示例数据中心的一部分的框图，并且其中资源由示例性服务器利用具有重新排序考虑的管理消息负荷均衡来监测。

图3是示出了根据本公开的一个或多个方面的图1的示例数据中心的示例分析集群的框图。

图4A是示出了根据本公开的一个或多个方面的图1的示例数据中心中的示例分析集群的示例配置的框图。图4B是示出了根据本公开的一个或多个方面的图4A的分析集群的示例路由实例的框图。图4C是示出了根据本公开的一个或多个方面的图4A的示例分析集群的示例故障转移的框图。图4D是示出了根据本公开的一个或多个方面的图4A的示例分析集群中的示例自动缩放操作的框图。

图5是示出了根据本公开的一个或多个方面的图4的示例分析集群中的计算系统的示例操作的流程图。

具体实施方式

如本文所述，数据中心可以部署各种网络基础设施资源监测/管理机制，其中一些机制与其他机制不同地操作。一些实现特定的协议类型，通过该协议类型可以在网络设备级别捕获各种数据，然后将其传送到专用计算系统集合(例如形成集群的服务器，其在本文中被称为分析集群)以进行处理。为了成功地分析来自网络设备的数据，数据中心可以建立针对计算系统具有不同要求的策略来遵循以便于确保成功分析任意协议类型的数据。数据可以作为消息传递，然后被提取以进行分析；但是，不遵守策略通常会导致分析失败。

失败的分析的示例原因包括丢失的或损坏的消息、消息乱序到达、消息具有不正确的元数据(例如在消息头中)、消息具有不正确格式的数据等。每种消息协议类型的数据模型都可能需要符合专用的要求集合。按照惯例，数据中心内的分析集群无法确保符合与相关消息数据的任意协议类型相对应的需求。

为了克服这些和其他限制，本公开描述了确保与任意给定消息协议类型的专用要求集合相符合的技术。基于UDP传输协议的协议类型(例如遥测协议)不采用序列号来维护消息流的顺序，这在处理乱序消息时可能会造成困难。用于某些协议类型的收集器应用不能使用乱序消息(例如由于同一消息流中的消息之间的依赖性)，因此要求属于同一消息流的至少某些消息按顺序或时间顺序到达。但是，这些收集器应用不能依赖任意已知的网络功能虚拟化基础设施(NFVi)机制进行重新排序。因为不存在重新排序机制，或者由于某些消息在多个节点之间被丢弃或拆分，所以根据一种或多种协议类型的收集器应用可能需要所有消息数据，因此，对应的策略可能会提出要求同一收集器应用接收消息流的每个消息。其他协议类型可以实现不受乱序消息影响的数据模型。在这种数据模型中，一条消息中存储的数据不依赖于另一条消息中存储的数据。其他协议类型的相应策略可能要求多个收集器应用处理不同的消息(例如并行)。因此，本文描述的任意策略中的一个要求是基于消息协议类型/数据模型对重新排序的容忍度，标识适当的应用以接收消息流的每个消息。

另一策略可能要求在消息头部中保留特定消息属性(例如源信息)(例如使消息元数据符合协议类型的数据模型)；否则，这些属性可能会被覆盖，从而导致分析失败。符合此要求使兼容的收集器应用可以正确提取消息元数据，然后正确分析消息有效负荷数据。纠正任意不符合的一种示例技术可以修改消息元数据和/或消息协议类型策略。一旦解决了不符合项，就可以将消息传送到适当的收集器应用。

本文描述的一些技术和系统使得能够经由遥测数据的验证实现策略实施，遥测数据以消息形式存储和传输。示例策略可以将对遥测数据的要求进行编码，以使其对于数据中心的分布式架构中的分析而言是可行的。由数据中心中的传感器、代理、设备和/或类似物生成的遥测数据可以以消息形式被传送到一个或多个专用目的地服务器。在这些服务器中，各种应用分析在每个消息中存储的遥测数据，并获得测量、统计数据或一些其他有意义的信息，以评估数据中心中资源的运行状态(例如健康/风险)。遥测数据的进一步分析可能会为与管理网络基础设施和数据中心内其他资源有关的其他任务产生有意义的信息。

对于操作作为用于从数据中心的网络设备传输遥测数据的消息的目的地服务器的计算系统集群，至少一个专用服务器(例如管理计算系统)可通信地耦合到该计算系统集群并且作为要监测的消息的中间目的地和访问点进行操作。该专用服务器可以包括软件定义网络(SDN)控制器，以为群集中的其他服务器执行服务，诸如操作数据中心中的策略控制器，在目的地服务器中配置入口引擎，以强制使对遥测数据的要求成为可行，操作负荷均衡机制以为传输遥测数据的消息的协议类型分发兼容的收集器应用，并根据此在目的地服务器之间分发消息。因为在将消息分发到目的地服务器时，负荷均衡机制没有考虑消息的协议类型，所以能够将消息传递到目的地服务器，而无需与符合遥测数据要求的消息协议类型相对应的适当收集器应用成为可行的。为了传送符合消息协议类型要求的消息，入口引擎会标识适当的收集器应用，以接收与消息协议类型相对应的消息。

数据中心中网络基础设施资源监测/管理的另一方面是性能管理，其包括负荷均衡。在典型的部署中，网络元素或设备将数据流传输到至少一个充当性能管理系统微服务提供者的目的地服务器。流传输的数据可以包括遥测数据，诸如物理接口统计、防火墙过滤器计数器统计、标签交换路径(LSP)统计。通过使用UDP的传感器从诸如线卡或网络处理单元(NPU)的源网络设备导出相关数据，相关数据作为消息经由至少一个目的地服务器上的数据端口到达。进而，在一个目的地服务器上运行的经过适当配置的入口引擎将执行策略实施，如本文所述。

图1是示出了根据本公开的一个或多个方面的示例网络105的概念图，该示例网络105包括示例数据中心110，在该示例数据中心110中，监测基于云的计算环境的基础设施元素的性能和使用度量，并且可选地包括与由多个处理共享的资源有关的内部处理器度量。图1示出了网络105和数据中心110的一种示例实现，该数据中心110托管一个或多个基于云的计算网络，计算域或项目，在本文中通常称为云计算集群。基于云的计算集群可以共置于共同的整体计算环境中，诸如单个数据中心，也可以分布在整个环境中，诸如分布在不同的数据中心中。基于云的计算集群可以例如是不同的云环境，诸如OpenStack云环境、Kubernetes云环境或其他计算集群、域、网络等的各种组合。在其他情况下，网络105和数据中心110的其他实现可能是合适的。这样的实现可以包括在图1的示例中包括的组件的子集和/或可以包括在图1中未示出的附加组件。

在图1的示例中，数据中心110为通过服务提供商网络106耦合到数据中心110的客户104提供了用于应用和服务的操作环境。尽管结合图1的网络105描述的功能和操作可以是在图1中被示为分布在多个设备中，但是在其他示例中，归因于图1中一个或多个设备的特征和技术可以由一个或多个这样的设备的本地组件在内部执行。类似地，一个或多个这样的设备可以包括某些组件并且执行可以在本文的描述中另外归因于一个或多个其他设备的各种技术。此外，某些操作、技术、特征和/或功能可以结合图1描述，或者以其他方式由特定组件，设备和/或模块执行。在其他示例中，这样的操作、技术、特征和/或功能可以由其他组件、设备或模块执行。因此，即使本文中没有以这种方式具体描述，归因于一个或多个组件、设备或模块的一些操作、技术、特征和/或功能也可以归因于其他组件、设备和/或模块。

数据中心110托管基础设施设备，诸如联网和存储系统、冗余电源和环境控制。服务提供商网络106可以耦合到由其他提供商管理的一个或多个网络，并且因此可以形成例如因特网的大规模公共网络基础设施的一部分。

在一些示例中，数据中心110可以代表许多地理分布的网络数据中心之一。如图1的示例所示，数据中心110是为客户104提供网络服务的设施。客户104可以是集体实体，诸如企业和政府或个人。例如网络数据中心可以为多个企业和最终用户托管Web服务。其他示例性服务可能包括数据存储、虚拟专用网络、业务工程、文件服务、数据挖掘、科学或超级计算等。在一些示例中，数据中心110是单独的网络服务器、网络对等方或其他。

在图1的示例中，数据中心110包括存储系统和应用服务器的集合，包括服务器126A至服务器126N(统称为“服务器126”)，这些服务器经由一个或多个层的物理网络交换机和路由器提供的高速交换结构121互连。服务器126用作数据中心的物理计算节点。例如每个服务器126可以提供用于执行一个或多个客户特定虚拟机148(图1中的“VM”)或诸如容器的其他虚拟化实例的操作环境。服务器126中的每一个可以可替代地称为主机计算设备，或更简单地称为主机。服务器126可以执行一个或多个虚拟实例，诸如虚拟机、容器或用于运行一个或多个服务的其他虚拟执行环境，诸如虚拟网络功能(VNF)。

尽管未示出，但是交换结构121可以包括耦合至机箱交换机的分布层的机架顶部(TOR)交换机，并且数据中心110可以包括一个或多个非边缘交换机、路由器、集线器、网关、诸如防火墙、入侵检测和/或入侵防御设备的安全设备、服务器、计算机终端、笔记本电脑、打印机、数据库、诸如蜂窝电话或个人数字助理的无线移动设备、无线接入点、网桥、电缆调制解调器、应用加速器或其他网络设备。交换结构121可以执行第3层路由，以通过服务提供商网络106在数据中心110和客户104之间路由网络业务。网关108用来在交换结构121和服务提供商网络106之间转发和接收分组。

根据本公开的一个或多个示例，软件定义联网(“SDN”)控制器132提供逻辑上且在某些情况下物理上集中的控制器，以促进数据中心110内一个或多个虚拟网络的操作。在整个本公开中，术语SDN控制器和虚拟网络控制器(“VNC”)可以互换使用。在一些示例中，SDN控制器132响应于经由北向API 131从编排引擎130接收到的配置输入而操作，其依次响应于配置输入而操作，配置输入从与用户界面设备129交互和/或操作用户界面设备129的管理员128接收。有关SDN控制器132与数据中心110的其他设备或其他软件定义的网络协同工作的附加信息可在2013年6月5日提交的标题为“PHYSICAL PATH DETERMINATION FORVIRTUAL NETWORK PACKET FLOWS”的国际申请号PCT/US 2013/044378中找到，其通过引用并入本文，如同本文完整阐述一样。

用户接口设备129可以被实现为用于交互呈现输出和/或接受用户输入的任意合适的设备。例如用户接口设备129可以包括显示器。用户接口设备129可以是计算系统，诸如由用户和/或管理员128操作的移动或非移动计算设备。用户接口设备129可以例如代表工作站、膝上型计算机或笔记本计算机、台式计算机、平板计算机或根据本公开的一个或多个方面的可由用户操作和/或呈现用户界面的任意其他计算设备。在一些示例中，用户接口设备129可以与策略控制器201在物理上分离和/或在不同的位置。在这样的示例中，用户接口设备129可以通过网络或其他通信方式与策略控制器201通信。在其他示例中，用户界面设备129可以是策略控制器201的本地外围设备，或者可以集成到策略控制器201中。

在一些示例中，编排引擎130管理数据中心110的功能，诸如计算、存储、联网和应用资源。例如编排(orchestration)引擎130可以为数据中心110内或跨数据中心的租户创建虚拟网络。编排引擎130可以将虚拟机(VM)附加到租户的虚拟网络。编排引擎130可以将租户的虚拟网络连接到外部网络，例如因特网或VPN。编排引擎130可以跨一组VM或到租户网络的边界实施安全策略。编排引擎130可以在租户的虚拟网络中部署网络服务(例如负荷均衡器)。

在某些示例中，SDN控制器132管理网络和联网服务，诸如负荷均衡、安全性，并经由南向API 133将来自服务器126的资源分配给各种应用。也就是说，南向API 133表示由SDN控制器132利用以使网络的实际状态等于编排引擎130所指定的期望状态的一组通信协议。例如SDN控制器132通过配置以下各项来实现来自编排引擎130的高级请求：物理交换机，例如TOR交换机、机箱交换机、和交换结构121；物理路由器；物理服务节点，诸如防火墙和负荷均衡器；以及虚拟服务，诸如VM中的虚拟防火墙等。SDN控制器132在状态数据库内维护路由、联网、和配置信息。

通常，任意两个网络设备之间的业务，诸如交换结构121中的网络设备(未显示)之间、或者服务器126与客户104之间、或者服务器126之间的业务，例如可以使用许多不同的路径遍历物理网络。例如两个网络设备之间可能存在多个成本相等的不同路径。在某些情况下，可以在每个网络交换节点处使用称为多路径路由的路由策略，将属于从一个网络设备到另一网络设备的网络业务的分组分发到各种可能的路径中。例如因特网工程任务组(IETF)RFC 2992，“Analysis of an Equal-Cost Multi-Path Algorithm”描述了一种路由技术，用于沿相等成本的多个路径路由分组。RFC 2992的技术分析了一种特定的多路径路由策略，该策略涉及通过对分组头部字段进行哈希处理来将流分配到bin，其通过一条确定性路径从特定网络流发送所有分组。

例如“流”可以由分组的头部或“五元组”的头部中使用的五个值定义，即用于通过物理网络路由分组的协议、源IP地址、目的地IP地址、源端口和目的地端口。例如协议指定通信协议，诸如TCP或UDP，并且“源端口”和“目的地端口”是指连接的源端口和目的地端口。与特定流条目匹配的一个或多个分组数据单元(PDU)集合代表流。可以使用PDU的任意参数来对流进行大致分类，诸如源和目的地数据链路(例如MAC)和网络(例如IP)地址、虚拟局域网(VLAN)标签、传输层信息、多协议标签交换(MPLS)或通用MPLS(GMPLS)标签、以及接收该流的网络设备的入口端口。例如流可以是在传输控制协议(TCP)连接中发送的所有PDU、由特定MAC地址或IP地址来源的所有PDU、具有相同VLAN标签的所有PDU、或在同一交换机端口处接收的所有PDU。

虚拟路由器142(虚拟路由器142A到虚拟路由器142N，图1中统称为“虚拟路由器142”)执行针对数据中心110中对应虚拟网络的多个路由实例，并将分组路由到由服务器126提供的操作环境中执行的适当虚拟机。每个服务器126可以包括虚拟路由器。例如由服务器126A的虚拟路由器142A从基础物理网络结构接收的分组可以包括外部头部，以允许物理网络结构将有效载荷或“内部分组”隧道传输到服务器126A的网络接口的物理网络地址。外部头部不仅可以包括服务器网络接口的物理网络地址，还可以包括虚拟网络标识符，诸如标识虚拟网络之一的VxLAN标签或多协议标签交换(MPLS)标签以及由虚拟路由器执行的对应的路由实例。内部分组包括内部头部，该内部头部具有符合由虚拟网络标识符标识的虚拟网络的虚拟网络寻址空间的目的网络地址。

在某些方面，虚拟路由器对从基础物理网络结构接收的多个隧道传输的分组进行缓冲并聚合，然后将其递送到用于分组的适当的路由实例。也就是说，在服务器126之一上执行的虚拟路由器可以从交换结构121中的一个或多个TOR交换机接收分组流的入站隧道分组，并在将隧道分组路由到本地执行的虚拟机之前，处理隧道分组以构建单个聚合隧道分组，以转发到虚拟机。也就是说，虚拟路由器可以缓冲多个入站隧道分组并构造单个隧道分组，其中多个隧道分组的有效负荷被组合为单个有效负荷，并且隧道分组上的外部/重叠头部被移除并被替换为单个头部虚拟网络标识符。这样，虚拟路由器可以将聚合隧道分组转发到虚拟机，就像从虚拟网络接收到单个入站隧道分组一样。此外，为了执行聚合操作，虚拟路由器可以利用基于内核的卸载引擎，该引擎无缝地并且自动地引导隧道分组的聚合。虚拟路由器将业务转发到在服务器126上执行的客户特定虚拟机的其他示例技术在标题为“PACKET SEGMENTATION OFFLOAD FOR VIRTUAL NETWORKS”的美国专利申请14/228,844中被描述，其通过引用并入本文。

在一些示例实现中，在服务器126上执行的虚拟路由器142在多个处理器核之间引导接收到的入站隧道分组，以在处理分组以路由到一个或多个虚拟和/或物理机器时促进核之间的分组处理负荷均衡。作为一个示例，服务器126A包括多个网络接口卡和多个处理器核，以执行虚拟路由器142A，并在多个处理器核之间引导接收到的分组，以促进内核之间的分组处理负荷均衡。例如服务器126A的特定网络接口卡可以与网络接口卡将所有接收到的分组定向到的指定处理器核相关联。根据应用于内部和外部分组头部中至少一个的哈希函数，各种处理器内核不是处理每个接收到的分组，而是将流卸载到一个或多个其他处理器核，以进行处理以利用其他处理器核的可用工作周期。

在图1的示例中，数据中心110进一步包括策略控制器201，该策略控制器201为数据中心110提供监测、调度和性能管理。策略控制器201与部署在各个物理服务器216中的至少一些物理服务器中的监测代理205交互，以监测物理计算节点以及在该物理主机上执行的诸如VM 148的任何虚拟化主机的资源使用。以这种方式，监测代理205提供分布式机制，用于收集各种各样的使用度量以及用于由策略控制器201安装的策略的本地实施。在示例实现中，监测代理205在数据中心110的基础设施的最低级别“计算节点”上运行，这些节点提供计算资源来执行应用工作负荷。计算节点可以例如是服务器126的裸金属主机、虚拟机148、容器等。

策略控制器201从监测代理205获取使用度量，并构建仪表板203(例如用户界面集合)以提供对数据中心110的操作性能和基础设施资源的可见性。策略控制器201可以例如将仪表板203传送到UI设备129，以显示给管理员128。此外，策略控制器201可以对所收集的度量应用分析和机器学习，以提供接近或看似接近的实时和历史监测、性能可见性和动态优化，以改进数据中心110中的编排、安全性、计费和计划。

如图1的示例所示，策略控制器201可以将规则库定义并维护为策略集合202。策略控制器201可以基于策略集合202来管理对服务器126中的每一个的控制。可以响应于管理员128的输入或响应于策略控制器201执行的操作来创建或导出策略202。策略控制器201可以例如观察一段时间内数据中心110的操作并应用机器学习技术来生成一个或多个策略202。策略控制器201可以在进行有关数据中心110的进一步观察时周期性地、偶尔地或连续地完善策略202。

策略控制器201(例如策略控制器201内的分析引擎)可以确定如何在一个或多个服务器126上部署、实现和/或触发策略。例如策略控制器201可以被配置为推送一个一个或多个策略202到在服务器126上执行的一个或多个策略代理205。策略控制器201可以从一个或多个策略代理205接收有关内部处理器度量的信息，并确定针对一个或多个度量的规则条件是否被满足。策略控制器201可以分析从策略代理205接收的内部处理器度量，并且基于该分析，指示或使一个或多个策略代理205执行一个或多个动作以修改与策略代理相关联的服务器的操作。

在一些示例中，策略控制器201可以被配置为确定和/或标识在每个服务器126上执行的虚拟机、容器、服务和/或应用形式的元素。如本文所使用的，资源通常称为虚拟化基础设施的可消耗组件，即该基础设施使用的组件，例如CPU、存储器、磁盘、磁盘I/O、网络I/O、虚拟CPU和Contrail vRouters。资源可以具有一个或多个特征，每个特征与由策略代理205(和/或策略控制器201)分析并可选地报告的度量相关联。下面参照图2描述资源的示例原始度量的列表。

通常，基础设施元素，本文也称为元素，是基础设施的组件，其包括或消耗可消耗资源以便于进行操作。示例元素包括主机、物理或虚拟网络设备、实例(例如虚拟机、容器或其他虚拟操作环境实例)、集合、项目和服务。在某些情况下，元素可能是另一元素的资源。虚拟网络设备可以包括例如虚拟路由器和交换机、vRouters、vSwitch、开放式虚拟交换机和虚拟隧道转发器(VTF)。度量是用于针对元素所消耗的资源的特性来测量资源的量的值。

策略控制器201还可以分析从策略代理205接收的内部处理器度量，并基于每个虚拟机使用服务器126的共享资源的程度对一个或多个虚拟机148进行分类(例如分类可能是CPU绑定、高速缓存绑定、存储器绑定)。策略控制器201可以与编排引擎130交互以使编排引擎130基于在服务器126上执行的虚拟机148的分类来调整服务器126上的一个或多个虚拟机148的部署。

策略控制器201可以进一步被配置为向与用户接口设备129相关联的客户端接口报告关于是否满足规则的条件的信息。替代地，或另外地，策略控制器201可以被进一步配置为向一个或多个策略代理205和/或编排引擎130报告关于是否满足规则条件的信息。

策略控制器201可以被实现为任意合适的计算设备或实现在任意合适的计算设备之内，或者在多个计算设备之间实现。策略控制器201或策略控制器201的组件可以被实现为计算设备的一个或多个模块。在一些示例中，策略控制器201可以包括在数据中心110内包括的一类计算节点(例如“基础设施节点”)上执行的多个模块。这样的节点可以是OpenStack基础设施服务节点或Kubernetes主节点，和/或可以实现为虚拟机。在一些示例中，策略控制器201可以具有到数据中心110内的一些或所有其他计算节点的网络连接，并且还可以具有到管理数据中心110的其他基础设施服务的网络连接。

一个或多个策略202可以包括使一个或多个策略代理205监测与服务器126相关联的一个或多个度量的指令。一个或多个策略202可以包括使一个或多个策略代理205分析与服务器126相关联的一个或多个度量以确定是否满足规则的条件的指令。一个或多个策略202可以替代地或另外地包括使策略代理205向策略控制器201报告一个或多个度量的指令，包括那些度量是否满足与一个或多个策略202相关联的规则的条件。所报告的信息可以包括由一个或多个策略202指定或要求的原始数据、概要数据和采样数据。

在一些示例中，仪表板203可以被认为是用户接口集合的集合，该用户接口呈现关于度量、警报、通知、报告以及关于数据中心110的其他信息的信息。仪表板203可以包括由用户接口设备129呈现的一个或多个用户接口。仪表板203可以主要由策略控制器201或由在策略控制器201上执行的仪表板模块创建、更新和/或维护。在一些示例中，仪表板203可以主要由在策略控制器201上执行的仪表板模块创建、更新和/或维护。仪表板203和相关联的仪表板模块可以通过在存储器中实例化的软件对象共同实现，软件对象具有相关联数据和/或可执行软件指令，该相关联数据和/或可执行软件指令提供用于在显示器上绘制的输出数据。在整个说明书中，可以参考执行一个或多个功能的仪表板203，并且在这种情况下，仪表板203既指仪表板模块又指仪表板用户接口和相关数据的集合。

用户界面设备129可以检测与来自仪表板203的用户界面的交互作为用户输入(例如来自管理员128)。策略控制器可以响应于用户与仪表板203的交互而导致对数据中心110或在数据中心110的一个或多个虚拟机148上执行的项目的方面进行配置，其与网络资源、数据传递限制或成本、存储限制或成本、和/或会计报告有关。

仪表板203可以包括图形视图，该图形视图通过使用直方图的实例来提供资源利用的快速、可视概览。这样的直方图的bin可以代表使用诸如CPU利用率的给定百分比的资源的实例数。通过使用直方图呈现数据，仪表板203以允许管理员128如果在用户界面设备129处呈现了仪表板203的情况下以快速标识指示不足供应或过度供应的实例的模式的方式呈现信息。在一些示例中，仪表板203可以突出显示特定项目或主机上的实例的资源利用率，或者所有主机或项目上的总资源利用率，以便管理员128可以在整个基础设施的上下文中理解资源利用率。

仪表板203可以包括与使用计算、网络和/或存储资源的成本以及项目所产生的成本有关的信息。仪表板203还可呈现关于一个或多个虚拟机148或数据中心110内的其他资源的健康和风险的信息。在一些示例中，“健康”可对应于反映一个或多个虚拟机148的当前状态的指示符。例如表现出健康问题的示例虚拟机可能当前正在用户指定的性能策略之外运行。“风险”可以对应于反映一个或多个虚拟机148的预测的未来状态的指示符，使得表现出风险问题的示例虚拟机在将来可能不健康。可基于监测的度量和/或与那些度量对应的警报来确定健康和风险指示符。例如如果策略代理205未从主机接收心跳，则策略代理205可将该主机及其所有实例表征为不健康。策略控制器201可以更新仪表板203以反映相关主机的健康，并且可以指示不健康状态的原因是一个或多个“丢失的心跳”。

一个或多个策略代理205可以在一个或多个服务器126上执行以监测与服务器126和/或在服务器126上执行的虚拟机148相关联的一些或全部性能度量。策略代理205可以分析所监测的信息和/或度量，并生成与服务器126和/或在这样的服务器126上执行的一个或多个虚拟机148的操作状态相关的操作信息和/或情报。策略代理205可以与在一个或多个服务器126上操作的内核进行交互，以确定、提取或接收与在服务器126处执行与由一个或多个进程和/或虚拟机148对共享资源的使用相关联的内部处理器度量。策略代理205可以在每个服务器126本地执行监测和分析。在一些示例中，策略代理205可以以接近和/或看似实时的方式执行监测和/或分析。

在图1的示例中，并且根据本公开的一个或多个方面，策略代理205可以监测服务器126。例如服务器126A的策略代理205A可以与服务器126A的组件、模块或其他元素和/或在服务器126上执行的一个或多个虚拟机148交互。作为这种交互的结果，策略代理205A可以收集关于与服务器126和/或虚拟机148相关联的一个或多个度量的信息。这种度量可以是原始度量，可以直接基于或直接从服务器126、虚拟机148和/或数据中心110的其他组件读取；这样的度量可以替代地或另外地是SNMP度量和/或基于遥测的度量。在一些示例中，这样的度量中的一个或多个可以是计算的度量，其包括从原始度量导出的那些度量。在一些示例中，度量可以对应于与特定资源有关的总容量的百分比，诸如CPU利用率或CPU消耗或3级高速缓存使用率的百分比。但是，度量可以对应于其他类型的度量，诸如一个或多个虚拟机148正在读取和写入存储器的频率。

策略代理205可以在每个服务器126处本地执行网络基础设施资源监测和分析。在一些示例中，策略代理205累积由各种设备/应用(例如，传感器、探测器等)捕获的相关数据(例如，遥测数据)，根据消息协议类型将所捕获的相关数据打包到数据模型中，并在消息流中传送所打包的相关数据。如本文所述，一些协议类型定义了两个或更多个相邻消息的组件之间的数据模型中的依赖性，并且它们的对应策略或多个策略要求将整个消息流被流传输到同一收集器应用进行处理(例如按顺序次序)。其他协议类型可以在两个或更多相邻消息的组件之间定义零(或琐碎的数量)依赖性，以使相应的策略可能需要多个收集器应用在分布式架构中运行，以并行处理消息流中的至少一个子序列消息。

策略代理205可以将消息流中的消息发送到管理计算系统，该管理计算系统充当这些消息以及传送给示例数据中心110内的分析集群的任意其他消息的中介。在一些示例中，分析集群可以与图1所示的群集基本相似地操作，其中分析群集内的每个计算系统基本上类似于图1的服务器126进行操作。分析群集所接收的消息传输与监测网络基础设施元素相关的相关数据。根据相关数据，分析集群中运行的收集器应用可以推断出有意义的见解。响应于从示例数据中心110的一个或多个网络设备接收到这样的消息，管理计算系统可以运行负荷均衡服务以选择分析集群的计算系统作为接收消息的目的地服务器，然后将该消息传送到所选择的计算系统。运行在分析集群外部的负荷均衡服务通常在标识计算系统以接收消息时不考虑任意消息的协议类型。

根据本文描述的策略实施技术，在分析集群的一个或多个或每个计算系统中运行的入口引擎可以接收消息，并且通过考虑消息的协议类型，可以确保消息数据是由适当的收集器应用处理。入口引擎可以将与消息协议类型相对应的每个策略要求应用于消息流中的每个消息，直到消息满足每个要求为止。当给定消息的数据符合协议类型的数据模型并且可用于处理时，可能发生满足该策略。

在一个示例中，入口引擎基于消息的协议类型/数据模型来访问各种数据(例如配置数据)以标识用于接收消息的适当的收集器应用。适当的收集器应用可能与邮件的协议类型/数据模型兼容，并被分配给消息流。符合相应策略要求的入口引擎可以将消息传送到与消息的协议类型相对应的适当的收集器应用。这可能还涉及例如通过修改消息元数据或消息有效载荷数据将消息转换为兼容消息。在一个示例中，入口引擎将源信息插入消息头中，以确保适当的收集器应用可以处理消息数据。

除了标识适当的收集器应用并传送消息之外，入口引擎还可被配置为经由负荷均衡、高可用性和自动缩放来提供一个或多个收集器应用的可扩展性。在一个示例中，入口引擎可以通过将相同消息流中的消息传送到收集器应用，来响应在适当的收集器应用处或收集器应用的计算系统中的故障，收集器应用在与收集器应用的计算系统相同的分析集群的故障转移节点中运行。收集器应用对应于消息的协议类型，并且是适当的收集器应用的副本。在另一示例中，计算系统的入口引擎创建适当的收集器应用的一个或多个新实例，以用于接收协议类型的消息数据(例如遥测数据)。入口引擎可以将相同消息流的消息传送给在相同计算系统上运行的新实例，或者将消息传递给在分析集群的不同计算系统上运行的新实例。在又一个示例中，如果入口引擎检测到适当的收集器应用正在处理的过量负荷，则入口引擎可以创建新实例来处理该过量负荷，只要它符合对应的策略。

图2是根据本公开的一个或多个方面更详细地示出了图1的示例数据中心110的一部分的框图，并且其中监测与由在示例服务器126上执行的多个进程共享的资源有关的内部处理器度量。图2中所示的是用户接口设备129(由管理员128操作)、策略控制器201和服务器126。

策略控制器201可以代表执行根据本公开的一个或多个方面的操作的工具、系统、设备和模块的集合。策略控制器201可执行云服务优化服务，其可包括用于软件定义的基础设施的高级监测、调度和性能管理，其中容器和虚拟机(VM)的生命周期可以比传统开发环境中的生命周期短得多。策略控制器201可以在分布式架构(例如数据中心110)中利用大数据分析和机器学习。策略控制器201可以提供接近或看似接近实时和历史监测、性能可见性和动态优化。可以以与结合图1提供的策略控制器201的描述一致的方式来实现图2的策略控制器201。策略控制器201可以执行仪表板模块233，其创建、维护和/或更新仪表板203。仪表板203可以包括用户接口，该用户接口可以包括分层网络或虚拟化基础设施热图。可以向此类用户接口内的基础设施元素呈现颜色或范围指示符，该颜色或范围指示符标识值范围，可以将与每个基础设施元素相关联的一个或多个利用率度量分类到该值范围。

在图2中，如图1所示，策略控制器201包括策略202和仪表板模块233。策略202和仪表板203也可以与结合在图1中提供的策略202和仪表板203的描述一致的方式实现。在图2中，主要通过在控制器201上执行的仪表板模块233来创建、更新和/或维护仪表板203。在一些示例中，如图2所示，策略202可以被实现为数据存储。在这样的示例中，策略202可以表示用于存储策略202和/或与策略202有关的信息的任意合适的数据结构或存储介质。策略202可以主要由策略控制引擎211维护，并且在一些示例中，策略202可以通过NoSQL数据库实现。

在图2的示例中、图2的策略控制器201还包括策略控制引擎211、适配器207、消息总线215、报告和通知212、分析引擎214、使用度量数据存储216和数据管理器218。

根据本公开的一个或多个方面，策略控制引擎211可以被配置为控制策略控制器201的一个或多个组件之间的交互。例如策略控制引擎211可以管理策略202和控制适配器207。策略控制引擎211还可以使分析引擎214基于来自使用度量数据存储216的数据来生成报告和通知212，并可以传递一个或多个报告和通知212到用户接口设备129和/或数据中心110的其他系统或组件。

在一个示例中，策略控制引擎211调用一个或多个适配器207以发现特定于平台的资源并与特定平台的资源和/或其他云计算平台进行交互。例如一个或多个适配器207可以包括OpenStack适配器，OpenStack适配器被配置为与服务器126上运行的OpenStack云操作系统通信。一个或多个适配器207可以包括Kubernetes适配器，Kubernetes适配器被配置为与服务器126上的Kubernetes平台通信。适配器207可能还包括Amazon Web Services适配器、Microsoft Azure适配器和/或Google Compute Engine适配器。这样的适配器可以使策略控制器201能够学习和映射服务器126所利用的基础设施。策略控制器201可以同时使用多个适配器207。

可以在指定的时间段内生成一个或多个报告，报告由不同的范围组织：项目、主机或部门。在某些示例中，此类报告可以显示项目中或主机上调度的每个实例的资源利用率。仪表板203可以包括以图形或表格格式呈现报告的信息。仪表板203可以进一步使报告数据能够被下载为HTML格式的报告、原始逗号分隔值(CSV)文件或JSON格式的数据以供进一步分析。

数据管理器218和消息总线215提供用于与服务器126中部署的策略代理205进行通信的消息传送机制。数据管理器218可以例如发布消息以配置和编程策略代理205，并且可以管理度量和从策略代理205接收的其他数据，并在使用度量数据存储216中存储这种数据中的一些或全部。数据管理器218可以通过消息总线215与策略引擎211通信。策略引擎211可以通过与数据管理器218进行交互来订阅信息(例如，通过发布/订阅消息传递模式的度量信息)。在某些情况下，策略引擎211通过将标识符传递给数据管理器218和/或在调用数据管理器218公开的API时订阅信息。作为响应，数据管理器218可以将数据放置在消息总线215上，以供数据管理器218和/或其他组件使用。策略引擎211可以通过与数据管理器218交互(例如传递标识符和/或进行API取消订阅调用)来取消订阅通过消息总线215从数据管理器接收数据。

数据管理器218可例如从一个或多个策略代理205接收原始度量。数据管理器218可替代地或另外地接收由策略代理205对原始度量执行的分析的结果。数据管理器218可以替代地或另外地接收与一个或多个输入/输出设备248的使用模式有关的信息，该信息可以用于对一个或多个输入/输出设备248进行分类。数据管理器218可以存储一些或全部使用度量数据存储216中的此类信息。

在图2的示例中，服务器126代表为诸如VM 148的虚拟主机提供执行环境的物理计算节点。也就是说，服务器126包括基础物理计算硬件244、该基础物理计算硬件244包括一个或多个物理微处理器240、存储器249、诸如DRAM、电源241、一个或多个输入/输出设备248和一个或多个存储设备250。如图2所示，物理计算硬件244为管理程序210提供了执行环境，其是软件和/或固件层，该软件和/或固件层提供轻量级内核209，并操作以为虚拟机148、容器和/或其他类型的虚拟主机提供虚拟化的操作环境。服务器126可以代表图1所示的服务器126之一(例如服务器126A至服务器126N)。

在所示的示例中，处理器240是具有用于执行指令的一个或多个内部处理器核243、一个或多个内部高速缓存或高速缓存设备245、存储器控制器246和输入/输出控制器247的集成电路。尽管图2的服务器126的示例仅示出了一个处理器240，在其他示例中，服务器126可以包括多个处理器240，每个处理器可以包括多个处理器核。

服务器126的设备、模块、存储区域或其他组件中的一个或多个可以互连以能够实现组件间通信(物理地、通信地和/或可操作地)。例如核243可以经由存储器控制器246从存储器249读取数据或向存储器249写入数据，存储器控制器246向存储器总线242提供共享接口。输入/输出控制器247可以通过输入/输出总线251与一个或多个输入/输出设备248和/或一个或多个存储设备250通信。在某些示例中，可以通过通信通道提供此类连接的某些方面，这些通信通道包括系统总线、网络连接、进程间通信数据结构或用于传送数据或控制信号的任意其他方法。

在处理器240内，每个处理器内核243A-243N(统称为“处理器内核243”)提供独立的执行单元，以执行符合处理器核的指令集架构的指令。服务器126可以包括任意数量的物理处理器和任意数量的内部处理器核243。通常，每个处理器核243使用单个IC(即，芯片多处理器)组合为多核处理器(或“多核”处理器)。

在某些情况下，可以在一个或多个处理器核243(即，共享存储器)之间共享用于计算机可读存储介质的物理地址空间。例如处理器核243可以经由存储器总线242连接到一个或多个DRAM封装、模块和/或芯片(也未示出)，其呈现处理器核243可访问的物理地址空间。尽管此物理地址空间可以为存储器249的任何部分中的处理器核243提供最低的存储器访问时间，但处理器内核243可以直接访问存储器249的其余部分中的至少一些。

存储器控制器246可以包括用于使处理器核243能够通过存储器总线242与存储器249通信的硬件和/或固件。在所示的示例中，存储器控制器246是集成存储器控制器，并且可以在处理器240上物理地实现(例如，作为硬件)。然而，在其他示例中，存储器控制器246可以单独地或以不同的方式实现，并且可以不集成到处理器240中。

输入/输出控制器247可以包括用于使处理器核243能够与连接到输入/输出总线251的一个或多个组件通信和/或交互的硬件、软件和/或固件。在所示的示例中，输入/输出控制器247是集成的输入/输出控制器，并且可以在处理器240上物理地实现(例如作为硬件)。然而，在其他示例中，存储器控制器246也可以单独地和/或以不同的方式来实现，并且可能不被集成到处理器240中。

高速缓存245表示处理器240内部的在处理器核243之间共享的存储器资源。在一些示例中，高速缓存245可以包括1级、2级或3级高速缓存或其组合，并且可以提供处理器核243可访问的任意存储介质的最低延迟存储器访问。但是，在本文所述的大多数示例中，高速缓存245表示3级高速缓存，与1级高速缓存和/或2级高速缓存不同，通常在现代多核处理器芯片中的多个处理器核之间共享。然而，根据本公开的一个或多个方面，在一些示例中，本文描述的技术中的至少一些可以应用于其他共享资源，包括除三级高速缓存之外的其他共享存储器空间。

电源241向服务器126的一个或多个组件提供功率。电源241通常从数据中心，建筑物或其他位置的主要交流(AC)电源接收功率。电源241可以在数据中心110内的许多服务器126和/或其他网络设备或基础设施系统之间共享。电源241可以具有智能电源管理或消耗能力，并且这样的特征可以由服务器126的一个或多个模块和/或由一个或多个处理器核243控制、访问或调节，以智能地消耗、分配、供应或以其他方式管理功率。

一个或多个存储设备250可以代表计算机可读存储介质，其包括以任意方法或技术实现的用于存储诸如处理器可读指令、数据结构，程序模块或其他数据的信息的易失性和/或非易失性、可移除和/或不可移除介质。计算机可读存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、EEPROM、闪存、CD-ROM、数字多功能光盘(DVD)或其他光学存储、磁带、磁带盒、磁盘存储或其他磁存储设备、或可用于存储所需信息并可由处理器核243访问的任意其他介质。

一个或多个输入/输出设备248可以代表服务器126的任意输入或输出设备。在这样的示例中，输入/输出设备248可以从能够检测来自人或机器的输入的任意类型的设备生成、接收和/或处理输入。例如一个或多个输入/输出设备248可以生成、接收和/或处理以物理、音频、图像和/或视觉输入(例如键盘、麦克风、照相机)形式的输入。一个或多个输入/输出设备248可以通过能够产生输出的任意类型的设备来生成、呈现和/或处理输出。例如一个或多个输入/输出设备248可以生成、呈现和/或处理以触觉、音频、视觉和/或视频输出(例如触觉响应、声音、闪光、和/或或图片)的形式的输出。一些设备可以充当输入设备，一些设备可以充当输出设备，而某些设备可以充当输入和输出设备。

存储器249包括一个或多个计算机可读存储介质，其可以包括随机存取存储器(RAM)，诸如各种形式的动态RAM(DRAM)，例如DDR2/DDR3 SDRAM或静态RAM(SRAM)、闪存或任意其他形式的固定或可移除存储介质，其可用于以指令或数据结构的形式携带或存储所需的程序代码和程序数据，并且可由计算机访问。存储器249提供由可寻址存储器位置组成的物理地址空间。在一些示例中，存储器249可以向处理器核243呈现非统一的存储器访问(NUMA)架构。也就是说，处理器核243对构成存储器249的各种存储介质可能没有相等的存储器访问时间。处理器核243可以是在某些实例中被配置为使用存储器249的为内核提供较低存储器延迟的部分以减少整体存储器延迟。

内核209可以是在内核空间中执行的操作系统内核，并且可以包括例如Linux，Berkeley Software Distribution(BSD)或另一个Unix变体内核、或Windows服务器操作系统内核，其可从微软公司获得。通常，处理器核243、存储设备(例如高速缓存245、存储器249和/或存储设备250)、并且内核209可以存储指令和/或数据，并且可以提供用于执行服务器126的这样的指令和/或模块的操作环境。这些模块可以实现为软件，但是在一些示例中可以包括硬件、固件和软件的任意组合。处理器内核243、服务器126内的存储设备(例如高速缓存245、存储器249和/或存储设备250)和内核209的组合可以取回、存储和/或执行一个或多个应用、模块或软件的指令和/或数据。处理器核243和/或这样的存储设备还可以可操作地耦合到一个或多个其他软件和/或硬件组件，包括但不限于服务器126的一个或多个组件和/或连接到服务器126的一个或多个设备或系统。

管理程序210是在硬件平台244上执行以创建并运行一个或多个虚拟机148的操作系统级组件。在图2的示例中，管理程序210可以集成内核209的功能(例如“第1类管理程序”)。在其他示例中，管理程序210可以在内核209上执行(例如“类型2管理程序”)。在某些情况下，管理程序210可以称为虚拟机管理器(VMM)。管理程序的示例包括Linux内核的基于内核的虚拟机(KVM)、可从VMware获得的Xen、ESXi、可从Microsoft获得的Windows Hyper-V以及其他开源和专有管理程序。

在图2的示例中，服务器126包括虚拟路由器142，该虚拟路由器142在管理程序210中执行，并且可以按照与结合图1所提供的描述一致的方式进行操作。在图2的示例中，虚拟路由器142可以管理一个或多个虚拟网络，每个虚拟网络可以提供网络环境以在由管理程序210提供的虚拟化平台之上执行虚拟机148。每个虚拟机148可以与虚拟网络之一相关联。

策略代理205可以作为管理程序210的一部分执行，或者可以在内核空间内或作为内核209的一部分执行。策略代理205可以监测与服务器126相关联的一些或全部性能度量。根据本文所述的技术，在服务器126的其他度量中，策略代理205被配置为监测度量，度量与由在服务器126的多核处理器240内的处理器核243上执行的每个进程151在处理器240内部共享的资源的使用有关或描述由在服务器126的多核处理器240内的处理器内核243上执行的每个进程151在处理器240内部共享的资源的使用。在一些示例中，这样的内部处理器度量与高速缓存245(例如L3高速缓存)的使用或存储器总线242上的带宽的使用有关。策略代理205也可能能够诸如通过与进程标识符(PID)或内核209维护的其他信息的关联，生成和维持映射，映射将进程151的处理器度量关联到一个或多个虚拟机148。在其他示例中，策略代理205可能能够协助策略控制器201生成和维护这样的映射。策略代理205可在策略控制器201的指导下，响应于针对物理处理器240内部共享的资源获得的使用度量和/或进一步基于处理器240外部资源的其他使用度量，在服务器126处实施一个或多个策略202。

在图2的示例中，虚拟路由器代理136被包括在服务器126中。参考图1，虚拟路由器代理136可以被包括在每个服务器126中(尽管未在图1中示出)。在图2的示例中，虚拟路由器代理136与SDN控制器132通信，并响应于此，指示虚拟路由器142以控制虚拟网络的覆盖并协调服务器126内的数据分组的路由。通常，虚拟路由器代理136与SDN控制器132通信，SDN控制器132生成命令以控制通过数据中心110的分组路由。虚拟路由器代理136可以在用户空间中执行，并充当虚拟机148和SDN控制器132之间的控制平面消息的代理。例如，虚拟机148A可以请求经由虚拟路由器代理136使用其虚拟地址发送消息，而虚拟路由器代理136A可以依次发送该消息并请求针对虚拟机148A的虚拟地址接收对该消息的响应，该虚拟机发出第一条消息。在一些情况下，虚拟机148A可以调用由虚拟路由器代理136的应用编程接口呈现的进程或功能调用，并且虚拟路由器代理136也处理消息的封装，包括寻址。

在一些示例实现中，服务器126可以包括直接与编排引擎130通信的编排代理(图2中未示出)。例如响应于来自编排引擎130的指令，编排代理传送在相应服务器126中的每一个上执行的特定虚拟机148的属性，并且可以创建或终止单独的虚拟机。

虚拟机148A、虚拟机148B到虚拟机148N(统称为“虚拟机148”)可以表示虚拟机148的示例实例。服务器126可以将由存储器249提供的和/或由存储设备250提供的虚拟和/或物理地址空间划分为用于运行用户进程的用户空间。服务器126还可以将由存储器249和/或存储设备250提供的虚拟和/或物理地址空间划分成内核空间，该内核空间受到保护并且用户进程可能无法访问。

通常，每个虚拟机148可以是任意类型的软件应用，并且每个虚拟机可以被分配一个虚拟地址以供在对应的虚拟网络内使用，其中每个虚拟网络可以是由虚拟路由器142提供的不同虚拟子网。每个虚拟机148可以被分配其自己的虚拟三层(L3)IP地址，例如用于发送和接收通信，但不知道虚拟机在其上执行的物理服务器的IP地址。以此方式，“虚拟地址”是用于应用的地址，该地址不同于用于底层物理计算机系统的逻辑地址，例如图1的示例中的服务器126A。

每个虚拟机148可以代表租户虚拟机，该租户虚拟机运行诸如Web服务器，数据库服务器，企业应用的客户应用，或托管用于创建服务链的虚拟化服务。在某些情况下，服务器126(参见图1)或另一个计算设备中的任意一个或多个直接托管客户应用，即不作为虚拟机。本文所引用的虚拟机(例如虚拟机148)、服务器126或托管客户应用的单独的计算设备可以可替代地称为“主机”。此外，尽管根据虚拟机或虚拟主机描述了本公开的一个或多个方面，但是本文中针对这种虚拟机或虚拟主机描述的根据本公开的一个或多个方面的技术也可以适用于容器、应用、进程或在服务器126上执行的其他执行单元(虚拟或非虚拟)。

进程151A、进程151B到进程151N(统称为“进程151”)可以分别在一个或多个虚拟机148中执行。例如一个或多个进程151A可以对应于虚拟机148A，或者可以对应于虚拟机148A内执行的应用或应用的线程。类似地，不同的进程集合151B可以对应于虚拟机148B，或者对应于在虚拟机148B内执行的应用或应用的线程。在一些示例中，每个进程151可以是由与虚拟机148之一相关联的应用控制和/或创建的执行单元或其他执行单元的线程。每个进程151可以与进程标识符相关联，该进程标识符在报告诸如由策略代理205收集的内部处理器度量的一个或多个度量时由处理器核243用于标识每个进程151。

在操作中，服务器126的管理程序210可以创建共享服务器126资源的多个进程。例如管理程序210可以(例如在编排引擎130的指导下)在服务器126上实例化或启动一个或多个虚拟机148。每个虚拟机148可以执行一个或多个进程151，并且这些软件进程中的每个可以在服务器126的硬件处理器240中的一个或多个处理器核243上执行。例如虚拟机148A可以执行进程151A，虚拟机148B可以执行进程151B，并且虚拟机148N可以执行进程151N。在图2的示例中，进程151A、进程151B和进程151N(统称为“进程151”)都在同一物理主机(例如服务器126)上执行，并且可以在服务器126上执行时共享某些资源。例如，在处理器核243上执行的进程可以共享存储器总线242、存储器249、输入/输出设备248、存储设备250、高速缓存245、存储器控制器246、输入/输出控制器247和/或其他资源。

内核209(或实现内核209的管理程序210)可以调度要在处理器核243上执行的进程。例如内核209可以调度属于一个或多个虚拟机148的进程151，以在处理器内核243上执行。一个或多个进程151可以在一个或多个处理器核243上执行，并且内核209可以周期性地抢占一个或多个进程151以调度另一个进程151。因此，内核209可以周期性地执行上下文切换以开始或恢复进程151中的不同一个进程的执行。内核209可以维护队列，其用于标识要调度以执行的下一个进程，而内核209可以将先前的进程放回队列中以供以后执行。在一些示例中，内核209可以基于轮询或其他方式调度进程。当队列中的下一个进程开始执行时，该下一个进程可以访问由先前的进程使用的共享资源，包括例如高速缓存245、存储器总线242和/或存储器249。

图3是示出根据本公开的一个或多个方面的示例分析集群300的框图，例如图1的数据中心110。

在图3的示例中，多个网络设备302A-N(以下称为“网络设备302”)经由网络304相互连接。服务器306是专用服务器，通常用作网络设备302与分析集群300之间的中间设备，使得任何通信(例如，消息)首先由服务器306的组件生成的接口来处理。由一个或多个网络设备302发起的消息流可以定向到该接口，进而，服务器306根据一个或多个性能管理服务来分配每个消息流。

在服务器306中，负荷均衡器310指软件程序集合，当它们在各种硬件(例如处理电路)上执行时，运行一个或多个性能管理服务。负荷均衡器310可以协调各种硬件/软件组件以能够实现分析集群300中的网络第2层负荷均衡(例如第2层性能管理微服务)；作为一个示例，负荷均衡器310和操作该接口的软件层可以被配置为根据一种或多种策略来分配消息流。负荷均衡器310可以维护路由数据，以基于该消息流的协议类型来标识服务器308中的哪一个接收给定消息流中的消息。

分析集群300的多个计算系统可以运行各种应用以支持网络基础设施资源的监测和管理。本公开将这些计算系统称为多个服务器308A-C(以下称为“服务器308”)，其中每个服务器308可以是图1的服务器126的示例实施例。经由服务器306作为入口点，网络设备302可以提供相关的数据以用于资源监测和网络基础设施管理。在服务器308上运行的各种应用例如通过应用规则并生成包含对示例数据中心的见解的信息来消耗相关数据。这些见解提供了有意义的信息，以改进网络基础设施资源监测和网络管理。例如应用可以使用相关数据来评估资源的健康状况或风险，并确定资源的健康状况是好还是坏，还是处于风险中或低风险中。将相关数据流传输到分析集群300使网络管理员能够测量链路和节点利用率的趋势，并实时对诸如网络拥塞的问题进行故障排除。流传输的相关数据可以包括遥测数据诸如物理接口统计、防火墙过滤器计数器统计、标签交换路径(LSP)统计。

虽然本文描述的上述计算系统和其他计算系统可操作用于执行示例数据中心的资源监测和网络基础设施管理，但是本公开适用于必须遵循策略以确定如何管理传入消息以确保适当的收集器应用接收和处理消息的存储数据的任何计算系统。即使可以根据任意结构来格式化本公开中涉及的消息，但是消息组件通常也可以根据联网协议来格式化；例如一些根据遥测协议的消息存储遥测数据，以便与运行在服务器308中的目的地服务器中的收集器应用进行通信。

在每个服务器308中，多个收集器应用处理并存储相关数据以用于后续处理。每个收集器应用可以被配置为根据本文描述的协议类型接收消息，其中每个示例消息可以以特定消息格式布置。每个兼容的收集器应用都可操作用于将消息数据转换为可行的数据集合，以用于网络基础设施资源的监测和管理。每个兼容的收集器应用可以布置数据以符合与协议类型(例如遥测协议类型)兼容的一个或多个数据模型。例如基于负荷均衡器310，服务器308A可以被配置有兼容的收集器应用，以根据SNMP、Junos遥测接口(JTI)和SYSLOG协议类型接收相关数据。对于每个协议，服务器308A可以运行单个兼容收集器应用或多个兼容收集器应用。服务器308A可以运行更精细的收集器应用；例如服务器308A可以运行一个或多个收集器应用，这些一个或多个收集器应用被配置为收集协议类型的特定版本的数据，诸如SNMP版本2和版本3的单独收集器应用。

对于给定的协议类型，本公开描述了要求集合，利用该要求集合，存储在消息或消息序列中的相关数据是符合的。如本文所述，诸如路由器、交换机等的不同网络设备提供用于收集相关数据(例如性能遥测数据)的不同机制(例如“遥测协议”)。为了说明，SNMP、gRPC、JTI和SYSLOG是用于导出性能遥测数据的不同遥测协议的示例。另外，每个遥测协议可以具有一个或多个唯一要求，例如用于控制分析集群的一个或多个计算系统处的(遥测)数据处理负荷的一个或多个要求。示例要求可以包括：将消息负荷维持在阈值(即最大值)处或以下；调整完整遥测数据集合的大小和/或速率(例如，周期性或突发)，以其将遥测数据传送到分析集群的一个或多个计算系统和/或由分析集群的一个或多个计算系统进行处理；调节消息的大小(例如消息有效负荷的大小)等。还有许多其他要求可能会影响分析集群的负荷均衡微服务。另一个要求可能表明，当消息被传递到收集器应用时，协议对消息排序/重新排序或丢包敏感。在云规模的环境中，这些要求使得在满足每个遥测协议要求的同时，跨多个收集器应用对高带宽遥测数据进行负荷均衡具有挑战性。本公开介绍了用于使用基于UDP的遥测协议(例如SNMP、JTI和SYSLOG)来收集遥测数据以便在满足不同遥测协议的专用要求的同时进行进一步的处理和分析的技术。

这种性能遥测数据的示例可以由数据中心110中的传感器、代理、设备等生成，然后以消息形式传达给服务器306。在服务器308中，各种应用分析存储在每个消息中的遥测数据并获得统计或一些其他有意义的信息。数据中心110中的一些网络基础设施元件(例如路由器)可以被配置为将消息形式的遥测数据传送到一个或多个目的地服务器。

Junos遥测接口(JTI)传感器可以在网络设备302N的转发组件(例如分组转发引擎)处生成遥测数据(例如链路状态路径(LSP)业务数据、逻辑和物理接口业务数据)并传送探测通过网络设备302N的数据平面。除了将网络设备302N的路由引擎连接到服务器306之外，数据端口还可以连接到服务器306或在服务器308之一上运行的适当的收集器应用。其他网络设备302可以使用服务器306到达适当的收集器应用。

本文所述的针对消息管理(例如分发)的技术不仅实施任意策略，而且确保将适当的要求集合应用于传入消息。一个示例要求集合确保传入消息的数据符合消息协议类型描述的数据模型。以这种方式，尽管具有不同的要求，但是可以通过或多或少地同时操作的不同协议类型(例如包括不同版本)来实现示例数据中心中的高效资源监测和网络基础设施管理。

图4A是示出根据本公开的一个或多个方面的图1的示例数据中心110中的示例分析集群的示例配置的框图。

类似于图3的分析集群300，分析集群400提供微服务以支持网络资源监测和网络管理，例如图1的数据中心110。在示例数据中心110中，多个网络设备402A-N(以下称为“网络设备402”)经由网络404相互连接。网络404通常代表各种网络基础设施元素和物理载体介质，以促进示例数据中心中的通信。至少一个网络设备，网络设备402N，经由服务器406被通信地耦合至分析集群400，该分析集群由多个计算系统形成，各种应用在其上支持网络资源监测和网络管理。本公开将这些计算系统称为服务器406为其提供负荷均衡服务的多个服务器408A-C(以下称为“服务器408”)中的目的地服务器。类似于服务器306，服务器406用作入口点，网络设备402可以通过入口点来提供消息，该消息传送用于资源监测和网络基础设施管理的相关数据。在服务器408上运行的许多应用例如通过应用规则并生成包含对示例数据中心110的见解的信息来消耗相关数据。

每个服务器408包括入口引擎410A-C的对应入口引擎(以下称为“入口引擎410”)和配置数据412A-C中的对应一个。在服务器408上运行的多个收集器应用414A-C(以下称为“收集器应用414”)例如通过应用规则并生成包含对示例数据中心110的见解的信息来消耗相关数据。每个入口引擎410通常都引用执行元件，执行元件包括各种计算硬件和/或软件，在某些情况下，这些计算硬件和/或软件执行在对应配置数据412中存储的示例配置。

用于任意给定的入口引擎410的示例性配置数据412使入口引擎410能够将特定协议类型的消息传送到与该特定协议类型相对应的一个或多个适当的收集器应用，该特定协议类型符合此类消息中存储的数据的一项或多项要求。对于根据特定协议类型的消息数据，对该数据的生存能力的示例要求可能包括会话亲缘关系、用于修改消息数据的代理、可扩展性等。鉴于这些示例要求，针对特定协议的示例设置可以为每个消息序列(例如流)标识适当的收集器应用、推入消息头部的属性、分析群集400中的故障转移节点以实现高可用性、用于负荷均衡和自动缩放的阈值等。示例性配置数据412可以进一步包括要在每个入口引擎的对应服务器中运行的每个协议类型的收集器应用的数量的初始或默认设置。示例性配置数据412可以例如基于数据的协议类型来标识哪个收集器应用414要处理由网络设备提供的数据。

作为示例来说明，在服务器408A中，配置数据412A鉴于策略416中的对应要求集合，存储了该服务器408A的配置设置。通常，这些设置使入口引擎410A能够例如通过以下各项来正确管理传入消息：维护传入消息的顺序、提供可扩展性(即负荷均衡、自动缩放和高可用性)、以及在将消息发送到一个或多个适当的收集器应用时添加/维护源地址信息414。配置数据412A中的一些示例设置使入口引擎410A能够识别服务器408A中的哪个收集器应用414适合于接收根据特定协议类型的消息。其他设置指示对特定消息属性的更改，例如以便维护消息序列的正确顺序。如本文所述，通过以正确的顺序具有多个消息，支持网络资源监测和网络管理的收集器应用414和其他应用能够组装在这些消息中传输的相关数据的完整数据集合。

如本文所述，策略416包括用于每种协议类型或消息类型的策略信息，并且该策略信息可用于向服务器408提供用于入口引擎410的配置数据412。关于服务器408A，配置数据412A可以根据SNMP来标识用于消息的收集器应用414A，根据JTI来标识用于消息的收集器应用414B，以及根据SYSLOG来标识用于消息的收集器应用414C。应该注意的是，配置数据412A可以指定另外的收集器应用414，其包括用于SNMP、SYSLOG和JTI消息的附加的收集器以及用于其他协议类型的一个或多个收集器。

服务器406将负荷均衡器418作为包括各种硬件和/或软件的执行元件来运行。在一个示例中，负荷均衡器418执行多种机制以创建然后用学习到的路由更新路由数据420，以将消息定向到服务器408中它们的目的地服务器。负荷均衡器418可以在路由数据420中存储由服务器408优化性能的路由。路由数据420可以指示服务器408中的哪一个将接收消息的特定序列(例如流)，诸如由相同网络设备生成或与相同源网络地址相关联的消息；这些指示并不代表对相关数据的要求，如果遵循这些要求，则可以防止此类数据变得无用。相反，每个入口引擎410被配置为基于消息协议类型对相关消息数据强制执行这些要求。

为了说明，鉴于路由数据420，服务器406可以将消息流的消息传送到特定服务器408，并且对应的入口引擎410可以进而按照协议类型的要求，将这些消息传送到与该消息的协议类型相对应的适当的收集器应用。适当的收集器应用可以代表用于处理相同消息流的其他消息的相同收集器应用，该收集器应用可能正在或可能不在特定服务器408上运行。因此，即使兼容的收集器应用正在特定服务器408中运行，对应的入口引擎410可以将消息传送给不同服务器408中的适当收集器应用。

图4B是示出了根据本公开的一个或多个方面的图4A的分析集群400中的示例路由实例的框图。当入口引擎410执行对应的配置数据412时，示例路由实例从将消息传递到适当的收集器应用414时遍历的路径得出。因此，每个示例路由实例指的是形成路径的节点集合，该路径向服务器408中的一个或多个目的地服务器传递属于特定消息协议类型的每个消息。

在图4B中用实线示出，第一路由实例表示根据第一协议类型布置的消息的路径。根据第一协议类型存储对消息数据的一个或多个需求的策略416可以包括指示对重排序的高容忍度的属性。此属性可能需要多个收集器应用来处理消息数据，而不是单个专用收集器应用。由于具有高容忍度属性，不需要多个收集器应用来维护消息顺序(例如通过协调消息处理)，并且这可以自由地以任意顺序处理消息，而不会导致相关数据无用。

因此，当一系列携带相关遥测数据的消息到达服务器406时，这些消息被传送到服务器408A，其中入口引擎410A标识多个收集器应用414A以接收/消耗相关数据(例如以任意顺序)。消息可以分布在收集器应用414A的多个实例中，其中每个实例接收相关数据的不同部分以进行处理(例如以并行、顺序或任意顺序)。入口引擎410A对消息的一个示例分发可以是将n个消息的子序列中的每个第i个消息传递给在服务器408中运行的第i个收集器应用414A。在图4A中，入口引擎410将每三个消息子序列中的第一、第二和第三消息传送到服务器408A、408B和408C中的相应收集器应用414A。在其他示例中，每个消息的副本都在多个实例中被分发，这样，即使一个副本丢失或某些分组被丢弃，收集器应用414A仍能够消耗相关数据并提取有意义的信息以支持网络资源监测和管理。

服务器408中运行的任意收集器应用414都有可能失败，需要将消息(故障转移)迁移到不同的收集器应用414和/或不同的服务器408。为了促进分析集群400中的高可用性，入口引擎410A可以在同一服务器408A或不同服务器408B或408C(即故障转移节点)中创建收集器应用414A(即故障转移收集器应用414A)的新实例。响应于服务器408A处的故障，服务器406将消息传送至服务器408B或408C，其中对应的入口引擎410B或410C进一步将消息传送至故障转移收集器应用414A。响应于在服务器408A处运行的收集器应用414A的故障，入口引擎410A可以将该消息传送至故障转移收集器应用414A并恢复消息处理。因此，通过运行同一收集器应用的另一台服务器可以实现高可用性，因此，如果第一台服务器发生故障，则消息业务可以故障转移到运行相同类型的收集器应用的另一台服务器。

维护故障转移节点和应用提供了许多益处。作为示例，在故障的情况下，兼容的收集器应用的至少一个实例在分析集群400中的另一台服务器408上运行。另一个益处是，如果消息丢失或消息数据损坏，则消息处理将很少或不中断。因此，故障不会中断分析集群400。根据第一协议类型布置的消息在传输期间可能无序到达、损坏、丢失和/或完全丢弃，并且在大多数示例中，服务器408的入口引擎即使从不完整的数据集合中，也应该能够获取有意义的信息。

第二路由实例(在图4B中用虚线示出)是从对根据第二协议类型布置的消息的策略416的实施而产生的。第二种协议类型的消息由同一个收集器应用按顺序处理。根据针对第二协议类型的策略416，必须遵循一个或多个要求，因为这些消息对于重新排序具有较低的容忍度，否则将无法获得或学习有意义的信息。一个示例要求可能是只有一个收集器应用才能按消息顺序处理消息。第二协议类型可以符合UDP传输协议，该协议不使用序列号来维护消息顺序。第二协议类型的示例包括其中会话无穷大是必需的基于UDP的遥测协议(例如JTI)。入口引擎410被配置为将这些消息引导到收集器应用414B的特定实例，诸如在服务器408A上运行的一个实例。因为分析服务器400专用于收集器应用414B的特定实例来处理第二协议类型的给定流(例如相同的源地址等)中的消息。如果除入口引擎410A以外的任意入口引擎接收到此消息，则该入口引擎(例如入口引擎410B或410C)会立即将该消息重定向到适当的收集器应用，如图4B所示。

配置数据412B可以提供标识符、存储器地址或另一条信息，该信息描述了如何针对第二协议类型访问在服务器408A上运行的收集器应用414B的特定实例。由于配置数据412B，服务器408B的入口引擎410B可以被充分编程以具有指令以根据第二协议类型来适当地重定向消息。例如入口引擎410B可以将被确定为根据第二协议类型布置的任意消息重定向到服务器408A。图4B使用虚线示出了这种重定向。虽然在服务器408B中，收集器应用414B的另一个实例可能正在运行(如图4B所示)，但是策略416仍可以标识服务器408A和/或在服务器408A中运行的兼容收集器应用414B，以从服务器406接收消息。

入口引擎410通常应用传入消息的相应策略来确定哪个或哪些收集器应用是适当的。如果本地适当的收集器应用不可用，则入口引擎410确定哪些服务器408运行适当的收集器应用。另外，对应的策略可以指定一个或多个可扩展性要求。例如如果根据第二协议类型的消息流的一部分被传送给在服务器408A中运行的收集器应用414B，则第二协议类型的策略可能要求收集器应用414B的同一实例接收相同的消息流的一个或多个后续消息。一旦在服务器408A处组装了消息的有序集合，则在某些时候，可以从在消息的有序集合中存储的数据中收集足够数量的相关数据。如果该数量超过阈值，则可以创建收集器应用414B的新实例以处理这种溢出。在服务器408A中的收集器应用414B发生故障的情况下，入口引擎410A将消息处理迁移到收集器应用414B的故障转移实例。在迁移之前，入口引擎410A可以在服务器408A或另一个服务器408中创建收集器应用414B的故障转移实例。如果由于某种原因从排序集中丢失了一条消息，则无法从消息中存储的数据中提取信息。

负荷均衡器418可以被配置为通过将相同消息流的消息传送到其中适当的收集器应用的实例正在运行的同一服务器408来维持会话亲和力。负荷均衡器418将相同服务器408与消息流之间的映射存储在路由数据420中，以供服务器406遵循。即使适当的收集器应用已迁移(例如由于故障)到另一个服务器408，负荷均衡器418仍可以继续将相同流的消息发送到同一服务器408。这可能发生在将收集器应用414B迁移到服务器408B之后且当负荷均衡器418为根据第二协议类型布置的相同消息流选择相同的目的地服务器(例如服务器408B)时。为了防止消息丢失，服务器408B的对应入口引擎410B可以将消息重定向到服务器408A中的收集器应用414B。

在图4B中用虚线表示了第三路由实例，其中虚线表示根据第三协议类型的消息的路径。对于该路由实例，策略416可以在每个入口引擎处建立代理以将元数据插入每个消息中。作为对这些消息中任意相关数据的要求，策略416规定了一个或多个收集器应用414C，但保留了多少个收集器应用414C打开供入口引擎410C选择以进行消息处理。一个示例策略416要求可以将收集器应用414C标识为适当的收集器，但是同时，向入口引擎410C授予用于选择或创建副本收集器应用414C以处理消息的权限。入口引擎410C可以在服务器408中运行的收集器应用414C的实例之间分发这些消息(例如以有序的顺序)，包括408C中的实例和408C中的另一实例。

作为替代，入口引擎410C可以将消息分发到在服务器408C中运行的收集器应用414C的多个副本。即使图4B将服务器408C示为具有收集器应用414C的一个副本，服务器408C的其他示例可能具有多个副本，并且其他服务器408可能具有其他副本。任意数量的收集器应用414C都可以处理这些消息中的相关数据；通过在彼此之间重新分发这些消息，可以组装和处理这些消息中相关数据的完整数据集合。

图4C是示出了根据本公开的一个或多个方面的图4A的分析集群400中的示例故障转移的框图。一般而言，示例故障转移是指一种状态(例如操作状态)，在该状态中，分析集群400识别出不起作用的目的地服务器，利用一个或多个其他目的地服务器上的资源来处理最初以不起作用的目的地服务器为目的地的消息。

如图4C所示，服务器408A发生计算故障，结果变得无法运行；因此，如果将消息传送到该服务器408A，则该消息将不会到达并且可能完全丢失。负荷均衡器418被配置为通过将这些消息重定向到服务器408中的另一个目的地服务器来确保分析群集400具有高可用性，从而确保为相关数据处理了这些消息。为了替换先前在服务器408A中运行的收集器应用，入口引擎410B和410C可以实例化这些应用的初始副本(如果尚未运行)或在其他服务器408中实例化这些应用的其他副本。例如第一协议类型(例如SYSLOG协议类型)的消息可以从服务器408A重定向到服务器408B和408C，每个服务器已经安装并运行收集器应用414A的副本。

根据第二协议类型(例如诸如JTI的遥测协议)的消息可以在故障后被重定向，但是这样做可能会冒着破坏遥测数据分析并丢失一些对网络基础设施监测和管理的见解的风险。用于第二协议类型的策略416要求按顺序处理这些消息，或者至少不能提取某些相关遥测数据以获取操作统计和其他有意义的信息。因此，当故障使服务器408A中断时，服务器408B可以作为故障转移节点运行，并且收集器应用414B的新实例(例如副本/一个副本)可以接收这些消息并继续遥测数据分析。但是，在某些情况下，遥测数据分析可能会中断，因为该消息的协议类型要求收集器应用414B的同一实例接收该消息。对于某些第二协议类型(例如JTI)，收集器应用414B的新实例可以期望在故障转移期间出现最小的消息丢失，直到达到稳定状态。可能存在其他情况，即当前在服务器408B上运行的收集器应用414B的新实例无法响应服务器408A上的故障转移而处理传入消息。

应当注意，本公开不排除为第二协议类型的消息提供高可用性。在一些示例中，即使第二协议类型要求顺序消息处理，收集器应用414B也可以从服务器408A迁移到服务器408B。即使策略416指示需要维护消息的有序序列，但入口引擎410B实例化服务器408B中的收集器应用414B的第二个副本以处理这些消息。尽管在图4C中未示出，但是可以在服务器408B中实例化收集器应用414B的多个副本(例如副本)。即使收集器应用414B的第一副本已在服务器408B中运行，也可能发生这种情况。在一个示例中，收集器应用414B的第一副本不具有任意先前传送的消息，并且至少由于这个原因，不能用于传入消息。以这种方式，收集器应用414B的第一副本不会负担过多的处理任务，并且该第一副本的消息的数据收集不会中断。另一方面，如果策略416要求消息按顺序到达以便在同一收集器应用414B处进行处理，则可以在重置或重新启动消息序列之后为此目的指定收集器应用414B的第二个副本。某些协议类型可以满足此要求，同时允许例如在故障转移期间新实例承担责任。

图4D是示出了根据本公开的一个或多个方面的图4A的分析集群400中的示例自动缩放操作的框图。

在某些示例中，策略416指示服务器408中的任意入口引擎410如何或何时执行负荷均衡。对于SYSLOG协议类型的消息，入口引擎410可以在服务器408中运行的SYSLOG兼容收集器应用的所有副本之间负荷均衡这些消息。对于SNMP TRAP(例如版本2或3)协议类型的消息，入口引擎410可以在SNMP TRAP兼容收集器应用的所有副本之间负荷均衡这些消息。对于SNMP TRAP版本2的消息，入口引擎410可以保留源IP地址，否则可以由入口引擎410覆盖源IP地址，以实现跨副本的可扩展性。具有SNMP代理的入口引擎410可以摄取源IP地址以保留该源信息，直到副本接收到UDP消息为止。对于JTI消息，负荷均衡器418和入口引擎410都不提供可扩展性，因为JTI的策略416提出了一个要求：即将来自同一源IP地址的所有符合JTI的传入消息被路由到适当收集器应用的同一副本。为了维持对JTI消息的会话亲和性，入口引擎410被排除将这些消息路由到其他副本，即使该副本也是同一收集器应用的兼容实例。

例如将存储遥测数据的SYSLOG消息传送到至少服务器408A，以由收集器应用414A进行处理。响应于接收到该SYSLOG消息，服务器408A的入口引擎410A可以创建收集器应用414A(例如副本收集器应用414A')的新实例，以用于接收在SYSLOG协议类型的消息中存储的遥测数据。除了将消息传送到收集器应用414A的先前实例之外或代替将消息传送到收集器应用414A的先前实例，入口引擎410A可以将消息传送到新实例副本414'，和/或将消息传送到在不同的计算系统上运行的收集器应用414A的新实例。

在一些示例中，响应于确定一个或多个服务器408处的过载，相应的入口引擎410可以分析网络业务，并基于该分析来标识一个或多个新的收集器应用以进行实例化。对应的入口引擎410可以确定正在使用哪些协议类型来格式化网络业务中的大多数消息，并且然后实例化适当的收集器应用的副本以处理这些消息。如果分析集群400大部分接收到JTI消息，则对应的入口引擎410在多个目的地服务器408中创建适当的收集器应用414B的多个新实例。在其他示例中，策略416指示何时相应的入口引擎410在多个目的地服务器408之间执行负荷均衡。

图5是示出了根据本公开的一个或多个方面的图4A-4D的示例分析集群中的计算系统的示例操作的流程图。下面在图4B的服务器406的上下文中描述图5，该服务器本身是图1的服务器126的示例，并且是可以在图4A-D的分析集群400中部署的计算系统。在其他示例中，图5中描述的操作可以由一个或多个其他组件、模块、系统或设备执行。此外，在其他示例中，结合图5描述的操作可以被合并、以不同的顺序执行或被省略。

在图5的示例中，并且根据本公开的一个或多个方面，服务器406的处理电路访问策略信息(例如策略416)并基于策略信息来配置在分析集群400的服务器408中运行的每个入口引擎410(500)。基于用于分析集群400的策略信息，收集器应用被分布在分析集群400的服务器408之间，并被配置为从示例数据中心110的网络设备接收消息，然后处理在这些消息中存储的数据。从网络设备传送来的消息到达服务器406，服务器可以或可以不将这些消息路由到运行兼容收集器应用的适当目的地服务器，以处理存储在这些消息中的数据。策略信息包括对于在消息中存储的数据被视为有效和/或足够用于分析目的的一个或多个要求。

如本文所述的任意示例策略中的策略信息通常包括对在与特定联网协议类型相对应的消息中存储的数据的一个或多个要求。策略信息中的一个示例要求基于用于存储的消息数据的协议类型来确定一个或多个服务器408以根据该协议类型来接收消息。证明符合每个要求可确保存储的消息数据是用于网络资源监测和管理的可行数据集合。一些要求确保符合消息的特定网络协议类型，该消息可以是基于UDP的遥测协议的类型(例如JTI、SYSLOG、SNMP TRAP版本2和3等)，或另一类别的联网协议的类型。特定的网络协议可以属于协议的分组，诸如包括没有重新排序机制的任意协议类型的组。因为消息可以对应于多个的网络协议类型，所以一些示例策略为不同的联网协议定义了两个或更多个要求集合，诸如确保符合遥测协议的要求集合和确保符合传输协议的第二要求集合。作为另一个示例，基于协议类型，策略信息标识在发生迁移事件(如故障转移或负荷均衡)的情况下，哪个收集器应用适合于接收某些消息。协议类型还可以建立自动缩放阈值，用于确定何时创建适当的收集器应用的新实例或销毁旧实例。

如本文所述，分析集群400可以提供例如数据中心110的微服务，并且一些微服务涉及实现示例策略以指导消息的重新排序以用于网络资源监测和网络管理。策略控制器201可以定义一个或多个策略，例如数据中心110，其包括上述关于消息重新排序的策略。例如用户接口设备129可以检测输入，并且将输入的指示输出到策略控制器201。策略控制器201的策略控制引擎211可以确定输入对应于足以定义一个或多个策略的信息。策略控制引擎211可以定义一个或多个策略并将一个或多个策略存储在策略数据存储202中。策略控制器201可以将一个或多个策略部署到在一个或多个服务器126上执行的一个或多个策略代理205。在一个示例中，策略控制器201将一个或多个示例策略部署给在服务器126(例如服务器406)上执行的策略代理205。

如本文所述的服务器406可以接收消息，并且基于消息的头部和(可能)其他属性，确定与该消息的流相对应的目的地服务器。服务器406的处理电路基于路由数据420将服务器408之一标识为目的地服务器，然后将该消息传送至所标识的目的地服务器408。依次，在所标识的目的地服务器408的处理电路上运行的对应的入口引擎410。接收消息并确定协议类型(502)。

被标识的目的地服务器408的对应的入口引擎410标识用于处理消息的一个或多个适当的收集器应用(504)。所标识的目的地服务器408可以基于用于协议类型的策略信息来标识应用。如果策略信息需要相同的收集器应用来接收消息的有序集合，则所标识的目的地服务器408的对应入口引擎410可以将消息传递给在所标识的目的地服务器408或不同的第二目的地服务器408上运行的收集器应用(的一个实例)。

如果策略信息指示对重排序的高容忍度并且不要求消息到达同一收集器应用，则服务器406的处理电路可以负荷均衡相同协议类型并且来自跨服务器408中运行的多个收集器应用的相同流(即，具有相同的源地址)的消息。

作为选择，服务器408的入口引擎410可以修改消息数据(506)。这样的修改可能符合或可能不符合协议类型的策略信息。SNMP TRAP版本2，示例协议类型，可以接受分组的重新排序，但是，每个分组中的源IP地址(例如分组头)都需要被保留，否则可能被入口引擎410覆盖。当入口引擎410接收SNMP TRAP版本2的打包数据，以保留源IP地址，入口引擎410将该地址插入每个分组(例如UDP分组)中，并将那些分组传送到适当的收集器应用。

服务器408的入口引擎410将消息传送到一个或多个适当的收集器应用(508)。与邮件的协议类型相对应的每个适当的收集器应用都至少符合策略信息的一项要求。如本文所述，响应于从数据中心110中的网络设备接收到消息，入口引擎410可以确定该消息是否符合在消息中存储的数据的至少一项要求。如果策略信息指示对消息的协议类型的重新排序具有较高的容忍度，则入口引擎410将消息传递到多个适当的收集器应用中的特定一个。根据策略信息，入口引擎410在多个适当的收集器应用之间分发消息，使得每个应用处理同一消息流的不同消息。在一些示例中，入口引擎410将消息传送到与相同协议类型和消息流的其他消息相同的收集器应用的相同实例。

对于本文所述的进程、装置和其他示例或说明，包括在任意流程图或流程图中，本文所述的任意技术中包括的某些操作、动作、步骤或事件可以以不同的顺序执行、可以完全被添加、合并或省去(例如并非所有描述的行为或事件对于实施该技术都是必需的)。此外，在某些示例中，可以例如通过多线程处理、中断处理或多个处理器同时而不是顺序地执行操作、动作、步骤或事件。即使未明确标识为自动执行，其他某些操作、动作、步骤或事件也可以自动执行。此外，描述为自动执行的某些操作、动作、步骤或事件可以备选地不自动执行，而是在一些示例中，可以响应于输入或另一事件而执行这样的操作、动作、步骤或事件。

在一个或多个示例中，可以以硬件、软件、固件或其任意组合来实现所描述的功能。如果以软件实现，则功能可以作为一个或多个指令或代码存储在计算机可读介质上和/或通过计算机可读介质传输、并由基于硬件的处理单元执行。计算机可读介质可以包括与诸如数据存储介质的有形介质相对应的计算机可读存储介质，或者包括有助于将计算机程序从一个地方转移到另一地方(例如根据通信协议)的任意介质的通信介质。以这种方式，计算机可读介质可以对应于(1)非暂时性的有形计算机可读存储介质，或者(2)诸如信号或载波的通信介质。数据存储介质可以是可由一台或多台计算机或一个或多个处理器访问以检索指令、代码和/或数据结构以实现本公开中描述的技术的任意可用介质。计算机程序产品可以包括计算机可读介质。

作为示例而非限制，这样的计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁性存储设备、闪存或任意其他可以用于以指令或数据结构形式存储所需程序代码并且可以由计算机访问的其他介质。而且，任意连接都适当地称为计算机可读介质。例如如果使用同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或诸如红外、无线电和微波的无线技术从网站、服务器或其他远程源发送指令，则介质的定义包括同轴电缆、光纤电缆、双绞线、DSL或诸如红外、无线电和微波的无线技术。但是，应该理解，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其他瞬态介质，而是针对非瞬态的有形存储介质。所使用的磁盘和光盘包括光盘(CD)、激光光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光光盘，其中磁盘通常以磁性方式复制数据，而光盘则通过激光光学方式复制数据。上述的组合也应包括在计算机可读介质的范围内。

指令可以由一个或多个处理器执行，诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)或其他等效的集成或分立逻辑电路。因此，本文所使用的术语“处理器”或“处理电路”可以分别指任意前述结构或适合于实现所描述的技术的任意其他结构。另外，在一些示例中，可以在专用硬件和/或软件模块内提供所描述的功能。同样，该技术可以在一个或多个电路或逻辑元件中完全实现。

本公开的技术可以在多种设备或装置中实现，包括无线手机、移动或非移动计算设备、可穿戴或不可穿戴计算设备、集成电路(IC)或IC集合(例如芯片组)。在本公开中描述各种组件、模块或单元以强调被配置为执行所公开技术的设备的功能方面，但不一定需要由不同硬件单元来实现。而是，如上所述，各种单元可以组合在硬件单元中，或者由互操作的硬件单元的集合提供，包括与合适的软件和/或固件结合的如上所述的一个或多个处理器。

Claims (20)

1.一种方法，包括：

由在计算系统的处理电路上运行的入口引擎从数据中心中的网络设备接收消息，所述数据中心包括多个网络设备和所述计算系统；以及

响应于从所述数据中心的网络设备接收到消息，由所述入口引擎向与所述消息的协议类型相对应的适当的收集器应用传送所述消息，所述消息的协议类型符合针对在从所述多个网络设备向所述计算系统所传送的消息中存储的数据的至少一项要求。

2.根据权利要求1所述的方法，其中由所述计算系统的所述入口引擎传送所述消息还包括：基于所述至少一项要求，由所述入口引擎向第二计算系统中运行的收集器应用传送所述消息。

3.根据权利要求1所述的方法，其中由所述计算系统的所述入口引擎传送所述消息还包括：向所述计算系统中运行的、与具有相同协议类型的其他消息相同的收集器应用传送所述消息。

4.根据权利要求1所述的方法，其中由所述计算系统的所述入口引擎传送所述消息的步骤还包括：向第二计算系统中运行的、与具有相同协议类型的其他消息相同的收集器应用传送所述消息。

5.根据权利要求1所述的方法，其中由所述入口引擎传送所述消息还包括：由所述入口引擎向在分析集群的多个计算系统中运行的多个收集器应用分发消息序列，所述多个收集器应用与所述消息的协议类型兼容。

6.根据权利要求1所述的方法，其中由所述入口引擎传送所述消息还包括：由所述入口引擎向在与所述计算系统相同的集群的故障转移节点中运行的收集器应用传送所述消息，其中所述收集器应用与所述消息的协议类型相对应，并且是所述适当的收集器应用的副本。

7.根据权利要求1所述的方法，其中由所述计算系统的所述入口引擎传送所述消息的步骤还包括：标识收集器应用，以根据所述消息的遥测协议类型来处理存储的数据，所述存储的数据由所述网络设备提供。

8.根据权利要求1至7中的任一项所述的方法，还包括：

由所述入口引擎创建所述适当的收集器应用的新实例，以用于接收在所述协议类型的消息中存储的遥测数据；以及

以下至少一项：由所述计算系统的所述入口引擎向在所述计算系统上运行的所述新实例传送所述消息，或者由所述计算系统的所述入口引擎向在不同的计算系统上运行的所述新实例传送所述消息。

9.根据权利要求1至7中的任一项所述的方法，其中由所述计算系统的所述入口引擎传送所述消息还包括：由可通信地耦合至所述计算系统的服务器的负荷均衡器，向在第二计算系统上运行的第二入口引擎传送所述消息，其中所述第二入口引擎将所述消息重定向到在所述计算系统中运行的所述入口引擎。

10.根据权利要求1-7中的任一项所述的方法，其中由所述计算系统的所述入口引擎传送所述消息还包括：在向所述适当的收集器应用传送所述消息之前，修改消息头部。

11.根据权利要求1至7中的任一项所述的方法，其中由所述入口引擎传送所述消息还包括基于如何基于所述至少一项要求来管理所述消息的确定，由所述入口引擎向与所述消息的协议类型相对应的所述适当的收集器应用传送所述消息。

12.根据权利要求1至7中的任一项所述的方法，还包括：由被通信地耦合到所述计算系统的服务器的处理电路，基于针对所述协议类型的策略来生成配置数据，其中所述策略指示针对在所述消息中存储的遥测数据的可行数据集合的所述至少一项要求，其中所述配置数据标识一个或多个适当的收集器应用以用于接收所述消息。

13.根据权利要求1-7中的任一项所述的方法，其中由所述入口引擎传送所述消息还包括：由所述入口引擎通过访问配置数据来确定所述消息是否符合针对在所述消息中存储的数据的所述至少一项要求，所述配置数据包括在所述计算系统中运行的用于所述入口引擎的收集器应用的数量，以及针对在从一个或多个网络设备向所述计算系统传送的消息中存储的数据的所述至少一项要求，其中所述至少一项要求标识对应于所述消息的所述协议类型的所述适当的收集器应用。

14.一种计算系统，包括：

存储器；以及

与所述存储器通信的处理电路，所述处理电路被配置为执行包括入口引擎的逻辑，所述入口引擎被配置为：

从数据中心中的网络设备接收消息，所述数据中心包括多个网络设备和所述计算系统；以及

响应于从所述数据中心中的网络设备接收到所述消息，向与所述消息的协议类型相对应的适当的收集器应用传送所述消息，所述消息的协议类型符合针对在从一个或多个网络设备向所述计算系统传送的消息流中存储的数据的至少一项要求。

15.根据权利要求14所述的计算系统，其中所述入口引擎向与所述消息的协议类型相对应的多个收集器应用分发所述消息流的消息，所述多个收集器应用在集群中的多个计算系统中运行。

16.根据权利要求14所述的计算系统，其中所述入口引擎使用所述配置数据以基于所述消息的协议类型来标识所述适当的收集器应用的实例，所述实例在所述计算系统或不同的计算系统中的至少一个中运行。

17.根据权利要求14-16中的任一项所述的计算系统，其中响应于故障，所述入口引擎将所述消息重定向到在被通信地耦合到所述计算系统的故障转移节点中运行的第二适当的收集器应用。

18.根据权利要求14-16中的任一项所述的计算系统，其中所述入口引擎将所述消息修改为符合所述一项或多项要求。

19.根据权利要求14-16中的任一项所述的计算系统，其中所述计算系统作为用于相同集群中的至少一个第二计算系统的故障转移节点来操作，其中被通信地耦合到所述计算系统的服务器或在第二计算系统中运行的第二入口引擎中的至少一个响应于在所述适当的收集器应用处的故障来向所述计算系统传送所述消息。

20.一种计算机可读存储介质，被编码有用于使一个或多个可编程处理器执行根据权利要求1-13中的任一项所述的方法的指令。

Images