技术领域：
：本公开涉及监视和改进云数据中心和网络的性能。
背景技术：
：：虚拟化数据中心正在成为现代信息技术(IT)基础设施的核心基础。具体地，现代数据中心已广泛利用虚拟化环境，在其中诸如虚拟机或容器的虚拟主机在物理计算设备的底层计算平台上被部署和执行。具有大规模数据中心的虚拟化可提供几个优点。一个优点是虚拟化可以显著提高效率。由于随着每个物理CPU具有大量内核的多核微处理器架构的出现，底层物理计算设备(即服务器)变得越来越强大，虚拟化变得更容易和更高效。第二个优点是虚拟化可以对基础设施提供重要控制。随着物理计算资源诸如在基于云的计算环境中成为可替代资源，计算基础设施的供应和管理变得更加容易。因此，除了虚拟化提供的效率和增加的投资回报率(ROI)之外，企业IT工作人员通常更喜欢数据中心中的虚拟化计算集群用于它们的管理优点。技术实现要素：本公开描述了用于诸如在数据中心内部署的虚拟化基础设施的计算环境的监视、调度和性能管理的技术。这些技术提供操作性能和基础设施资源的可视性。如本文所述，这些技术可以利用分布式架构中的分析来提供实时和历史监视、性能可视性和动态优化，以改进计算环境内的组织、安全性、计费和计划。这些技术可以在例如混合、私人或公共企业云环境内提供优点。这些技术兼容诸如容器和虚拟机的各种虚拟化机制，以支持多租户、动态和持续演进的企业云。本公开的方面涉及监视作为基础设施的更高级别组件的多个不同元件之间共享的可消耗资源的性能和使用，所述资源被分别使用与组相关联的一个或多个规则集合来至少部分地针对作为一个或多个元件组的成员的这些元件来评估。例如，用户可以为元件配置规则集合，并进一步将元件配置为一个或多个元件组的成员，每个组具有对应的规则集合。策略控制器可以向在计算设备(例如服务器或网络设备)上执行的策略代理分发该元件的简档，其是该元件和该元件是其成员的每个组的规则集合的集合。策略代理可以基于多个规则集合以及由策略代理接收的度量来评估简档，该度量指示资源以及至少在一些情况下也是组的成员的一个或多个其他元件的性能。在某些情况下，策略代理可以将度量报告给更高级别的策略控制器，以使策略控制器能够使用分布在多个计算设备之间的资源的度量来评估简档。在评估元件的简档时，策略代理可以向策略控制器报告简档状态和/或诸如通过行为来限制简档应用于的元件所消耗的资源的使用来采取改善动作。在其他示例中，策略控制器可以监督响应于来自策略控制器的指示来可动作以限制共享资源的使用的多个服务器。此外，在一些示例中，关于一个或多个元件如何使用共享资源的信息可以被分析。基于这些信息，元件可以基于共享资源使用特征而被分类。这些分类可用于更高效地跨多个物理服务器设备分配元件。这些技术可以提供一个或多个优点。例如，这些技术可以允许用户为不同类型的元件组配置不同的规则集合，其中多个组与元件成员资格重叠，并且每个组具有对应的规则集合。这种灵活的组成员资格和规则集合配置可以允许用户通过配置另一组中的元件或组的成员资格而不必手动配置元件或组的整体简档，用简档来表达要应用于元件或组的警报的组合。此外，这些技术可以通过使用作为组成员的新元件集合来评估组简档来动态地考虑组成员资格中的改变，而不必重新配置组简档。在一个示例中，一种方法包括由策略控制器获得虚拟化基础设施的元件的第一简档，第一简档包括具有一个或多个警报的第一规则集合；由所述策略控制器获得用于包括所述元件的一个或多个元件的组的第二简档，所述第二简档包括具有一个或多个警报的第二规则集合；所述策略控制器至少基于作为所述组的成员的元件来修改所述第一简档以生成包括所述第一规则集合和所述第二规则集合的修改的第一简档；以及由策略控制器向计算设备输出修改的第一简档。在一个示例中，计算系统包括策略控制器，该策略控制器被配置为：获得虚拟化基础设施的元件的第一简档，第一简档包括具有一个或多个警报的第一规则集合；获得包括所述元件的一个或多个元件的组的第二简档，所述第二简档包括具有一个或多个警报的第二规则集合；至少基于作为该组的成员的元件来修改第一简档以生成包括第一规则集合和第二规则集合的经修改的第一简档；并向计算设备输出修改的第一简档。所述计算系统还包括所述计算设备，所述计算设备包括处理电路和存储指令的至少一个存储设备，所述指令在被执行时将所述处理电路配置为：响应于确定一个或多个使用度量触发第二规则集合的所述一个或多个警报中的至少一个，确定经修改的第一简档是活动的；并输出修改的第一简档是活动的指示。在一个示例中，一种包括指令的计算机可读存储介质，所述指令在被执行时配置计算系统的一个或多个处理器以：获得虚拟化基础设施的元件的第一简档，所述第一简档包括具有一个或多个警报的第一规则集合；获得包括所述元件的一个或多个元件的组的第二简档，所述第二简档包括具有一个或多个警报的第二规则集合；至少基于作为组的成员的元件来修改第一简档，以生成包括第一规则集合和第二规则集合的经修改的第一简档；并向计算设备输出经修改的第一简档。在另一示例中，一种计算系统包括多个基于云的计算集群，基于云的计算集群中的每一个包括：一个或多个计算节点；一个或多个策略代理，被配置为在计算节点上执行以监视与计算节点的资源有关的性能和使用度量；以及策略控制器，被配置为将策略部署到策略代理并从策略代理接收性能和使用度量。多集群面板软件系统被配置为从多个基于云的计算集群的控制器中的每一个接收数据。策略控制器中的每一个被配置为通过针对计算集群的基础设施元件的一个或多个规则集合的应用来评估相应计算集群的性能和使用度量。策略控制器中的每一个基于对集群的性能和使用度量的评估来向多集群面板软件系统输出指示基础设施元件的当前健康状况的数据。多集群面板软件系统数据输出呈现针对基于云计算集群中的每一个的当前健康状况的单个用户界面屏幕。在另一示例中，一种方法包括在多个不同的基于云的计算集群的计算节点上执行策略代理，以监视与计算集群中的每一个内的计算节点的资源相关的性能和使用度量。该方法还包括用计算集群中的每一个的相应策略控制器接收来自相应计算集群的计算节点上执行的策略代理的性能和使用度量，并且用策略控制器中的每一个来通过针对相应计算集群的基础设施元件的一个或多个规则集合的应用来评估相应计算集群的性能和使用度量。该方法进一步包括从策略控制器中的每一个向多集群面板软件系统输出数据，其中该数据指示集群的基础设施元件的当前健康状况并且是基于对性能以及使用度量的评估的；并且用多集群面板软件系统输出针对基于云的计算集群中的每一个的当前健康状况，并且用于作为单个用户界面屏幕显示。在附图和下面的描述中阐述了本公开的一个或多个示例的细节。本公开的其他特征、目的和优点将从说明书和附图以及权利要求中显而易见。附图说明图1是图示了根据本公开的一个或多个方面的包括其中与由多个处理共享的资源有关的内部处理器度量被监视的示例数据中心的示例性网络的概念图。图2是图示了根据本公开的一个或多个方面的进一步详细说明的图1的示例数据中心的一部分的框图，并且在示例数据中心中与由在示例服务器上执行的多个进程共享的资源有关的内部处理器度量被监视。图3A和图3B是图示了根据本公开的一个或多个方面的由示例用户界面设备呈现的示例用户界面的概念图。图4是图示了根据本公开的一个或多个方面的由示例服务器执行的操作的流程图。图5A-5B是图示了根据本公开的技术的用于多种类型的组的多个元件和组简档的示例简档层级的框图。图6是图示了根据本公开的技术的用于多种类型的组的多个元件和组简档的示例简档层级的框图。图7A-7B描绘了根据本公开的技术的用于由用户界面设备显示的示例用户界面输出。图8是图示了根据本公开的技术的计算系统的示例操作模式的流程图。图9A是其中单个集群控制器管理服务器或计算节点并通过面板提供可视化的示例网络的框图。图9B是其中多集群面板为管理相应计算集群的多个策略控制器提供可视化的示例网络的框图。图10图示了根据本公开的一个或多个方面的用于多集群面板的、计算设备上呈现的示例用户界面。图11图示了根据本公开的一个或多个方面的由计算设备输出的用于多集群面板的示例用户界面。图12图示了由多集群面板输出的、用于接收和处理来自管理员的输入以将集群配置为在多集群面板上显示的示例用户界面。图13图示了由多集群面板软件系统响应于图12所示的示例配置而呈现的示例用户界面。图14是由多集群面板软件系统输出的用于通知管理员其正在将视图从多集群视图切换到单个集群的示例用户界面。图15图示了当在单个集群视图中操作时由多集群面板软件系统输出的示例用户界面。图16是图示了本文描述的多集群面板软件系统的一个示例操作的流程图。在整个附图和正文中，类似的附图标记指代类似的元件。具体实施方式图1是图示了根据本公开的一个或多个方面的包括示例数据中心110的示例网络105的概念图，其中基于云的计算环境的基础设施元件的性能和使用度量被监视，并且可选地包括与由多个处理共享的资源有关的内部处理器度量。图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包括一组存储系统和应用服务器，包括经由由一层或多层物理网络交换机和路由器提供的高速交换结构121互连的服务器126A到服务器126N(统称为“服务器126”)。服务器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响应于经由北向API131从编配引擎130接收的配置输入进行操作，该北向API131进而又响应于从操作用户界面设备129的管理员128接收到的配置输入来进行操作。关于SDN控制器132结合数据中心110的其他设备或其他软件定义的网络操作的附加信息可以在2013年6月5日提交的名称为PHYSICALPATHDETERMINATIONFORVIRTUALNETWORKPACKETFLOWS的国际申请号PCT/US2013/044378中找到，其通过引用如同完全阐述一样并入本文。用户界面设备129可以被实现为任意合适的计算系统，诸如由用户和/或由管理员128操作的移动或非移动计算设备。用户界面设备129可以例如表示工作站、膝上型计算机或笔记本计算机、台式计算机、平板计算机或可以由用户操作的和/或根据本公开的一个或多个方面呈现用户界面的任意其他计算设备。在一些示例中，编配引擎(orchestrationengine)130管理数据中心110的功能，诸如计算、存储、网络和应用资源。例如，编配引擎130可以为数据中心110内或跨数据中心之间的租户创建虚拟网络。编配引擎130可以将虚拟机(VM)附接到租户的虚拟网络。编配引擎130可以将租户的虚拟网络连接到外部网络，例如因特网或VPN。编配引擎130可以跨一组VM或向租户网络的边界实施安全策略。编配引擎130可以在租户的虚拟网络中部署网络服务(例如负载均衡器)。在一些示例中，SDN控制器132管理网络和联网服务，诸如负载均衡、安全性，并且经由南向API133将资源从服务器126分配给各种应用。也就是说，南向API133表示SDN控制器132利用的用于使网络的实际状态等于如由编配引擎130指定的期望状态的通信协议集合。例如，SDN控制器132通过配置物理交换机，例如TOR交换机、机架交换机和交换结构121；物理路由器；物理服务节点，诸如防火墙和负载均衡器；以及诸如VM中的虚拟防火墙的虚拟服务来实现来自编配引擎130的高级别请求。SDN控制器132维护状态数据库内的路由、联网和配置信息。通常，任意两个网络设备之间(例如诸如交换机结构121内的网络设备(未图示)之间或服务器126与客户104之间或服务器126之间)的业务可以使用许多不同的路径穿越物理网络。例如，两个网络设备之间可以存在几个不同的等价路径。在某些情况下，属于从一个网络设备到另一网络设备的网络业务的分组可以被分布在使用在每个网络交换节点处称为多路径路由的路由策略的各种可能的路径中。例如，因特网工程任务组(IETF)RFC2992“等开销多路径算法的分析”描述了用于沿着等开销路径的多条路径来路由分组的路由技术。RFC2992的技术分析了一种特定的多路径路由策略，该特定的多路径路由策略涉及通过散列分组头部字段将流指派到箱，其通过单个确定性路径发送来自特定网络流的所有分组。例如，“流”可以通过分组的头部中使用的五个值(或“五元组”，即协议、源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交换机接收分组流的入站隧道分组，并且在将隧道分组路由到本地执行的虚拟机之前，处理隧道分组以构建用于转发到虚拟机的单个聚合隧道分组。也就是说，虚拟路由器可以缓冲多个入站隧道分组并且构建单个隧道分组，其中多个隧道分组的有效载荷被组合成单个有效载荷，并且隧道分组上的外部/覆盖头部被移除并且被替换为单个头部虚拟网络标识符。通过这种方式，聚合隧道分组可以由虚拟路由器转发到虚拟机，就好像单个入站隧道数据分组从虚拟网络被接收一样。此外，为了执行聚合操作，虚拟路由器可以利用基于内核的卸载引擎，其无缝且自动地引导隧道分组的聚合。标题为“PACKETSEGMENTATIONOFFLOADFORVIRTUALNETWORKS”的美国专利申请14/228,844中描述了另一示例技术，虚拟路由器通过该示例技术向在服务器126上执行的客户特定虚拟机转发业务，该美国专利申请通过引用并于本文。在一些示例实现中，在服务器126上执行的虚拟路由器142导向在多个处理器核之间接收的入站隧道分组，以在处理分组以用于路由到一个或多个虚拟和/或物理机器时促进核之间的分组处理负载均衡。作为一个示例，服务器126A包括多个网络接口卡和用于执行虚拟路由器142A的多个处理器核，并且在多个处理器核之间导向接收到的分组以促进核之间的分组处理负载均衡。例如，服务器126A的特定网络接口卡可以与指定处理器核相关联，网络接口卡将所有接收到的分组引导到该指定处理器核。各种处理器核不是处理每个接收的分组，而是根据被应用于内部分组头部和外部分组头部中的至少一个的散列函数，将流卸载到一个或多个其他处理器核，用于处理以利用其他处理器核的可用工作周期。在图1的示例中，数据中心110还包括策略控制器201，策略控制器201为数据中心110提供监视、调度和性能管理。策略控制器201与监视代理205交互，监视代理205被部署在至少一些相应的物理服务器216中，用于监视物理计算节点以及在物理主机上执行的诸如VM148的任意虚拟化主机的资源使用。以这种方式，监视代理205提供用于收集各种各样的使用度量以及用于由策略控制器201所安装的策略的本地实施的分布式机制。在示例实现中，监视代理205运行在数据中心110的基础设施的最低级别的“计算节点”上，其提供计算资源以执行应用有效载荷。计算节点可以例如是服务器126、虚拟机148、容器等的裸机主机。策略控制器201从监视代理205获得使用度量并构建面板203(例如，用户界面集合)以提供对数据中心110的操作性能和基础设施资源的可视性。策略控制器201可以例如将面板203传送给UI设备129以向管理员128显示。另外，策略控制器201可以将分析和机器学习应用于所收集的度量以提供实时和历史监视、性能可视性和动态优化以改进数据中心110内的组织、安全性、计费和规划。如图1的示例中所示，策略控制器201可以将规则库定义和维护为策略集合202。策略控制器201可以基于策略控制器201的策略集合202来管理服务器126中的每一个的控制。策略202可以响应于管理员128的输入或响应于策略控制器201执行的操作来被创建或导出。策略控制器201可以例如观察数据中心110随时间的操作并应用机器学习技术来生成一个或更多策略202。随着关于数据中心110的进一步观察被进行，策略控制器201可以周期性地、偶尔地或持续地改进策略202。策略控制器201(例如策略控制器201内的分析引擎)可以确定策略在服务器126中的一个或多个处如何被部署、实施和/或触发。例如，策略控制器201可以被配置为向在服务器126上执行的策略代理205中的一个或多个推送一个或多个策略202。策略控制器201可从策略代理205的一个或多个接收关于内部处理器度量的信息，并确定一个或多个度量的规则的条件是否被满足。策略控制器201可以分析从策略代理205接收的内部处理器度量，并且基于该分析，指示或促使一个或多个策略代理205执行一个或多个动作以修改与策略代理相关联的服务器的操作。在一些示例中，策略控制器201可以被配置为确定和/或标识以在每个服务器126上执行的虚拟机、容器、服务和/或应用的形式的元件。如本文所使用的资源通常是指虚拟化基础设施的可消耗组件，即由诸如CPU、存储器、磁盘、磁盘I/O、网络I/O、虚拟CPU和Contrailvrouter的基础设施使用的组件。资源可以具有一个或多个特征，每个特征与由策略代理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呈现的一个或多个用户界面。用户界面设备129可以检测与面板203的交互作为用户输入(例如，来自管理员128)。面板203可以响应于用户输入来使得对数据中心110的各个方面或在数据中心110的一个或多个虚拟机148上执行的、与网络资源、数据传输限制或开销、存储限制或开销、和/或会计报告有关的项目进行配置。面板203可以包括图形视图，其通过使用直方图的实例提供资源利用的快速、可视概览。这样的直方图的箱可以表示使用给定百分比的资源(例如CPU利用率)的实例的数目。通过使用直方图呈现数据，面板203以允许管理员128(如果面板203在用户界面设备129处呈现)以快速标识指示欠供应或过供应的实例的模式的方式呈现信息。在一些示例中，面板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的其他组件直接读取。在其他示例中，一个或多个这样的度量可以是计算度量，其包括从原始度量导出的那些度量。在一些示例中，度量可以对应于与特定资源有关的总容量的百分比，诸如CPU利用率或CPU消耗或者3级高速缓存使用的百分比。然而，度量可以对应于其他类型的测量，诸如一个或多个虚拟机148如何频繁地正在读取和写入存储器。策略控制器201可以配置策略代理205以监视触发警报的条件。例如，策略控制器201可以检测策略控制器201确定对应于用户输入的、来自用户界面设备129的输入。策略控制器201还可以确定用户输入对应于足以配置用户指定警报的信息，该信息基于针对一个或多个度量的值。策略控制器201可以处理输入并且生成实现警报设置的一个或多个策略202。在一些示例中，这样的策略202可以被配置为使得当策略代理205在服务器126处收集的一个或多个度量的值超过特定阈值时警报被触发。策略控制器201可以将关于所生成的策略202的信息传送给在服务器126上执行的一个或多个策略代理205。策略代理205可以针对警报所基于的条件来监视服务器126，如从策略控制器201接收的策略202所指定的。例如，策略代理205A可以监视服务器126A处的一个或多个度量。这些度量可涉及服务器126A、在服务器126A上执行的所有虚拟机148、和/或虚拟机148的特定实例。策略代理205A可基于监视的度量确定一个或多个值超过由从策略控制器201接收的一个或多个策略202设置的阈值。例如，策略代理205A可以确定CPU使用是否超过由策略设置的阈值(例如，服务器126A的CPU使用>50％)。在其他示例中，策略代理205A可以评估一个或多个度量是小于阈值(例如，如果服务器126A可用磁盘空间<20％，则发出警报)，还是等于阈值(例如，如果虚拟机148的实例数等于20，则发出警报)。如果策略代理205A确定受监视的度量触发阈值，则策略代理205A可以发出警报条件并将关于该警报的信息传送给策略控制器201。策略控制器201和/或策略代理205A可以例如通过生成通知来对警报起作用。策略控制器201可以更新面板203以包括通知。策略控制器201可以使更新的面板203在用户界面设备129处被呈现，从而通知管理员128警报状况。在一些示例中，策略控制器201可以生成策略并且建立警报条件而无需用户输入。例如，策略控制器201可以将分析和机器学习应用到由策略代理205收集的度量。策略控制器201可以分析由策略代理205在各个时间段收集的度量。策略控制器201可以基于这种分析来确定足以为一个或多个度量配置警报的信息。策略控制器201可以处理该信息并且生成实施警报设置的一个或多个策略202。策略控制器201可以将关于该策略的信息传送给在服务器126上执行的一个或多个策略代理205。此后，每个策略代理205可以监视条件并响应于根据无需用户输入生成的对应策略202来触发警报的条件。根据本文描述的技术，策略控制器201生成数据中心110的元件的简档213。简档与元件或元件组相关联，并且是警报的集合，其要针对警报的对应度量被评估以确定相关联的元件或元件组是“活动”还是“非活动”。例如，策略控制器201响应于经由UI设备126接收到的输入，可以为相应主机、实例(例如，VM148)、网络设备、其群组及其资源(例如，CPU、存储器、磁盘、网络接口等)生成简档213。此外，用户或管理员将数据中心110的元件配置为一个或多个元件组的成员，使得元件和组具有“成员的”关系。作为示例，OpenStack主机(例如，服务器126中的任一个)可以是一个或多个“主机聚合体”的成员，该主机聚合体每个是一个或多个主机的组。Kubernetes容器可以是(1)豆荚(“pod”)、(2)复制控制器、(3)命名空间和(4)若干不同服务的成员。虚拟机148A可以被配置为一个或多个“实例聚合体”的成员，实例聚合体每个是一个或多个实例的组。网络设备可以被配置为一个或多个“网络设备聚合体”的成员，该网络设备聚合体每个是一个或多个网络设备的组。在以上每个示例中，用户或代理可以为每个元件和元件组定义简档213。通常，并且如本文结合图2进一步描述的，这些技术利用某些内部处理器度量，该某些内部处理度量与在物理处理器的内部共享的资源有关，诸如与由执行处理器内的一个或多个核的软件共享的处理器的内部高速缓存、或由物理处理器内的核所消耗的存储器总线带宽有关的度量。与物理微处理器内共享的资源有关的这种度量可以提供关于在每个服务器126上执行的虚拟机148(或虚拟机148内的进程)如何竞争或以其他方式使用处理器内部的共享资源的见解。这些信息可用于查明瓶颈、资源竞争的实例、以及从诸如CPU利用率或CPU负载度量的其他度量中可能无法显而易见的性能问题。在一些示例中，一个或多个虚拟机148在给定服务器上操作和/或使用这种共享资源(诸如共享高速缓存或存储器总线)的方式可能不利地影响在该相同服务器上的其他虚拟机148的操作。然而，例如，通过仅监视CPU使用，可能难以标识哪个特定虚拟机正在引起其他虚拟机148的性能问题。然而，通过监视每个服务器126的处理器内部的资源的度量，可以能够不仅标识哪个虚拟机可能正在导致给定处理器上的其他虚拟机148的性能问题，而且还可以采取步骤来改进执行一个或多个服务器126的处理器的所有虚拟机148的策略控制。如果适当的策略控制跨数据中心110被应用，可以能够改进聚合体中的数据中心110的操作、效率和一致性能，并且更有效地遵守服务级别协议和性能保证。通过监视内部处理器度量以将服务器的处理器内共享的资源标识为由包括在处理器内部的硬件核上执行的软件进程的元件所消耗，数据中心110的策略控制器201可以标识以可能不利地影响在该服务器上执行的其他虚拟机148、容器和/或进程的性能的方式消耗共享资源的虚拟机148、容器和/或进程。通过标识可能不利地影响其他进程的操作的进程，数据中心110的策略控制器201可以采取步骤以解决这些进程如何操作或使用共享资源，并且因此改进在任意给定服务器上执行的虚拟机、容器、和/或进程的聚合性能，和/或共同改进所有服务器126的操作。因此，作为标识进程不利地影响其他进程的操作并且采取适当的响应动作的结果，虚拟机148可以更高效地在服务器126上执行计算操作，并且更高效地使用服务器126的共享资源。通过更高效地执行计算操作并且更高效地使用服务器126的共享资源，数据中心110可以更快速且更少延迟地执行计算任务。因此，本公开的各方面可以改进服务器126和数据中心110的功能，因为标识和寻址不利地影响其他虚拟机148的任意虚拟机148的操作产生可以具有使得服务器126和数据中心110能够更快速地且更少延迟地执行计算任务的效果。此外，可以触发警报的度量或条件的评估可以在每个服务器126处(例如由策略代理205)被本地地实现。通过在本地执行这种评估，可以以更高的频率访问与评估相关的情能度量，这可以允许或以其他方式促进更快地执行评估。在本地实施评估可以在一些情况下避免向另一计算设备(例如，策略控制器201)发送指示与评估相关联的性能度量的信息以用于分析。因此，与这些信息的传输有关的延迟可以完全被缓解或避免，这可以在评估中包括的性能度量的数目增加的场景中导致显著的性能改进。在另一示例中，与在操作条件评估期间获得的原始数据相反，当指示或以其它方式表示警报和/或事件发生的信息将被发送时，从计算设备发送的信息量可以被显著地减少。在又一示例中，给合与延迟减轻有关的效率增益，生成警报所花费的时间可以减少。图1中图示的和/或在本公开其他地方图示或描述的各种组件、功能单元和/或模块(例如，用户界面设备129、编配引擎130、SDN控制器132和策略控制器201、策略代理205)可以执行使用驻留在一个或多个计算设备中和/或在一个或多个计算设备处执行的软件、硬件、固件或者硬件、软件和固件的混合来描述的操作。例如，计算设备可以用多个处理器或多个设备来执行这些模块中的一个或多个。计算设备可以执行这样的模块中的一个或多个，作为在底层硬件上执行的虚拟机。这样的模块中的一个或多个可以作为操作系统或计算平台的一个或多个服务来执行。这样的模块中的一个或多个可以作为计算平台的应用层处的一个或多个可执行程序来执行。在其他示例中，由模块提供的功能可以由专用硬件设备来实现。虽然某些模块、数据存储库、组件、程序、可执行文件、数据项、功能单元和/或在一个或多个存储设备内包括的其他项目可以被分开图示，但是这样的项目中的一个或多个可以被组合并且作为单个模块、组件、程序、可执行文件、数据项或功能单元操作。例如，一个或多个模块或数据存储库可以被组合或部分组合，使得它们作为单个模块操作或提供功能。此外，一个或多个模块可以彼此结合地操作，使得例如一个模块充当另一模块的服务或扩展。此外，每个模块、数据存储库、组件、程序、可执行文件、数据项、功能单元或在存储设备内图示的其它项可以包括多个组件、子组件、模块、子模块、数据存储和/或其他未图示的组件或模块或数据存储库。此外，每个模块、数据存储库、组件、程序、可执行文件、数据项、功能单元或存储设备内图示的其他项目可以以各种方式来实现。例如，每个模块、数据存储库、组件、程序、可执行文件、数据项、功能单元或在存储设备内图示的其他项目可以被实现为在计算设备上执行的操作系统的一部分。在简档213中包括的警报，在被触发或“活动”时，确定简档213是否活动。另外，对于元件是其成员的元件组的警报还可以确定元件的简档213是否是活动的。因为元件可以是至少相对于元件重叠的多个组的成员，所以生成并且在一些情况下向配置代理205分发简档213的策略控制器201可以允许数据中心110的虚拟化基础设施的用户和管理员通过配置另一组中的元件或组的成员资格，而不必手动配置元件或组的整体简档213，用简档213表达应用于元件或组的警报组合。此外，技术可通过使用作为组成员的新元件集合来评估组的简档213来动态地考虑组成员资格中的改变，而不必重新配置组的简档213。策略控制器201可以将简档213分发给在计算设备(例如，服务器126或数据中心110的网络设备)上执行的策略代理205。策略代理205基于包括在其中的一个或多个警报并基于由策略代理205接收的指示该元件的性能的度量来评估接收到的简档213中的每一个，并且至少在该元件是组的成员的一些情况下，一个或多个其他元件也是该组的成员。策略控制器201的其他示例技术在标题为“MICRO-LEVELMONITORING,VISIBILITYANDCONTROLOFSHAREDRESOURCESINTERNALTOAPROCESSOROFAHOSTMACHINEFORAVIRTUALENVIRONMENT”的美国专利申请15/797,098中描述，其通过引用并入本文。图2是根据本公开的一个或多个方面进一步详细说明了的图1的示例数据中心110的一部分的框图，并且其中与由示例服务器126上执行的多个进程共享的资源有关的内部处理器度量被监视。图2中图示了用户界面设备129(由管理员128操作)、策略控制器201和服务器126。策略控制器201可以表示执行根据本公开的一个或多个方面的操作的工具、系统、设备和模块的集合。策略控制器201可以执行云服务优化服务，其可以包括软件定义基础设施的高级监视、调度和性能管理，其中容器和虚拟机(VM)可以具有比传统开发环境中的寿命周期短得多的寿命周期。策略控制器201可以利用分布式架构(例如，数据中心110)中的大数据分析和机器学习。策略控制器201可以提供接近实时和历史的监视、性能可视性和动态优化。图2的策略控制器201可以以与结合图1提供的策略控制器201的描述一致的方式来实现。在图2中，策略控制器201包括策略202和面板203，如图1所示。策略202和面板203也可以以与结合图1提供的策略202和面板203的描述一致的方式来实现。在一些示例中，如图2所示，策略202可以被实现为数据存储库。在这样的示例中，策略202可以表示用于存储策略202和/或与策略202有关的信息的任意合适的数据结构或存储介质。策略202可以主要由策略控制引擎211维护，并且策略202可以在一些示例中通过NoSQL数据库实现。在该示例中，图2的策略控制器201还包括策略控制引擎211、适配器207、报告和通知212、分析引擎214、使用度量数据存储库216和数据管理器218。根据本公开的一个或多个方面，策略控制引擎211可以被配置为控制策略控制器201的一个或多个组件之间的交互。例如，策略控制引擎211可以创建和/或更新面板203、管理策略202和控制适配器207。策略控制引擎211还可以使分析引擎214基于来自使用度量数据存储库216的数据来生成报告和通知212并且可以将一个或多个报告和通知212传递给用户界面设备129和/或数据中心110的其他系统或组件。在一个示例中，策略控制引擎211调用一个或多个适配器207来发现平台特定的资源并且与平台特定的资源和/或其他云计算平台交互。例如，一个或多个适配器207可以包括OpenStack适配器，OpenStack适配器被配置为与在服务器126上操作的OpenStack云操作系统进行通信。一个或多个适配器207可以包括Kubernetes适配器，Kubernetes适配器被配置为与服务器126上的Kubernetes平台进行通信。适配器207可能还包括AmazonWeb服务适配器、MicrosoftAzure适配器和/或GoogleComputeEngine适配器。这样的适配器可以使得策略控制器201能够学习和映射由服务器126所利用的基础设施。策略控制器201可以同时使用多个适配器207。报告和通知212可以经由策略控制器201的一个或多个组件来被创建、维护和/或更新。在一些示例中，报告和通知212可以包括在面板203内呈现的信息，并且可以包括说明基础设施资源随着时间的推移如何被实例消耗的信息。如下面进一步描述的，通知可以基于警报，并且通知可以通过面板203或通过其他手段来呈现。一个或多个报告可能针对指定的时间段被生成，由以下不同的范围组织：项目、主机或部门。在一些示例中，这样的报告可以显示项目中或在主机上调度的每个实例的资源利用率。面板203可以包括以图形或表格形式两者呈现报告的信息。面板203还可以使报告数据能够作为HTML格式的报告、原始逗号分隔值(CSV)文件、或JSON格式的数据被下载用于进一步分析。报告和通知212可以包括各种报告，包括项目报告、主机报告和/或部门报告，其中的每一个都可以被包括在面板203内。可以为单个项目或所有项目生成项目报告(只要管理员128被授权访问项目或所有项目)。项目报告可以显示资源分配、实际使用和计费。资源分配可以包括诸如vCPU、浮动IP地址和存储卷的资源的静态分配。实际资源使用可以针对项目中的每个实例并且作为项目中所有实例的使用的聚合总和在面板203内显示。资源使用可以显示由实例消耗的实际物理资源，诸如CPU使用百分比、存储器使用百分比、网络I/O和磁盘I/O。可以针对项目中的每个实例显示为资源使用计费的开销。此外，可以针对项目作为整体显示风格类型和资源类型(计算、网络、存储)的开销明细。作为一个示例，策略控制引擎211可以引导分析引擎214为诸如云计算环境的主机聚合体中的所有主机或主机集合生成主机报告。在一些示例中，只有具有管理员角色的用户可以生成主机报告。主机报告可以显示主机的聚合资源使用，以及由主机上调度的每个实例的资源使用的明细。主机报告还可以显示为主机上每个实例计费的开销以及总开销和每种风格类型的总开销。这提供了主机生成的收入的指示。作为另一示例，部门报告显示了向部门计费的总开销。在一些示例中，管理员128可以在多个部门之间划分项目开销，并且项目可以托管由多个部门使用的应用和服务。在这样的示例中，每个部门可能全部或部分负责与一个或多个项目相关的开销。面板203可以通过在面板203中呈现的部门报告来提供用于在多个部门之间划分项目开销的支持。在一些示例中，策略控制器201可以配置警报，并且可以在一个或多个服务器126和/或在一个或多个服务器126上执行的一个或多个虚拟机148(或容器)满足条件时生成警报通知。策略代理205可以监视服务器126和虚拟机148处的度量，并且分析对应于应用于那些服务器126和/或虚拟机148和/或在每个这种服务器126和/或服务器126上运行的实例的警报的条件的度量的原始数据。在一些示例中，警报可应用于标识要监视条件的元件的类型的指定“范围”。例如，此元件可以是“主机”、“实例”或“服务”。警报可能应用于这种元件中的一个或多个。例如，警报可以应用于数据中心110内的所有主机或指定主机聚合体内的所有主机(即，服务器126或虚拟机148的集群，管理程序主机组或池)。策略代理205可以连续收集主机(例如服务器126的特定VM148)及其实例的度量的测量。对于特定警报，策略代理205可以根据用户指定的函数(平均值、标准差、最小值、最大值、总和)来对样本进行聚合，并且针对每个用户指定的间隔产生单个测量。策略代理205可以将每个相同和/或测量与阈值进行比较。在一些示例中，由警报或包括警报条件的策略评估的阈值可以是静态阈值或动态阈值。对于静态阈值，策略代理205可以将度量或对应于度量的原始数据与固定值进行比较。例如，策略代理205可以使用用户指定的比较函数将度量与固定值进行比较(高于、低于、等于)。对于动态阈值，策略代理205可以将度量或对应于度量的原始数据与资源集合的历史趋势值或历史基线进行比较。例如，策略代理205可以将度量或其他测量与由策略代理205随时间学习的值进行比较。在一些示例实现中，策略控制器201被配置为应用动态阈值，其基于历史趋势来使能资源消耗中的异常值检测。例如，资源消耗可能在一天中的不同的小时和一周中的几天显著地改变。这可能使得很难为度量设置静态阈值。例如，针对周一上午10点到下午12点之间，70％的CPU使用可能被认为是正常的，但针对周六晚上9点到10点之间，相同数量的CPU使用可以被认为是异常高的。利用动态阈值，策略代理205可以学习跨警报应用范围内的所有资源的度量中的趋势。例如，如果警报被配置用于主机聚合，则策略代理205可以从针对该聚合中的主机收集的度量值中学习基线。类似地，对于具有针对项目配置的动态阈值的警报，策略代理205可以从针对该项目中的实例收集的度量值中学习基线。然后，当测量偏离针对特定时间段内学习的基线值时，策略代理205可以生成警报。具有动态阈值的警报可以通过度量、在其上建立基线的时间段、以及灵敏度来配置。策略代理205可以将灵敏度设置应用于偏离基线的测量，并且可以被配置为“高”、“中”或“低”灵敏度。配置有“高”灵敏度的警报可导致策略代理205向策略控制器201报告与配置有“低”灵敏度的警报相比与基线值的较小的偏离。在一些示例实现中，警报可以由其模式来表征，诸如“警报模式”或“事件模式”。当警报被配置为警报时，策略代理205可以在每当警报的状态改变时向策略控制器201发送通知或以其他方式通知策略控制器201和/或数据中心110的其他组件。在一些示例中，这种警报最初可以处于“学习”状态，直到策略代理205已经收集足够的数据来评估警报的状况。当警报的条件满足时，警报可以是“活动的”，当条件不满足时，警报可以是“不活动的”。当警报被配置为事件时，策略代理205针对其中警报的条件被满足的每个时间间隔，可以向策略控制器201发送通知或以其他方式通知策略控制器201(和/或数据中心110的其他组件)。例如，考虑60秒间隔内平均CPU使用超过90％的警报。如果警报模式是“警报”，则当警报在时间T1变为“活动”时，策略代理205可以向策略控制器201发送通知。当CPU在时间T5下降到90％以下时，策略代理205可以发送警报“不活动”的通知。如果相同的警报被配置在“事件”模式中，则策略代理205可以针对五个间隔中的其中CPU负载超过90％的每一个向策略控制器201发送通知。在一些示例中，每个警报可以被包括在由策略控制器201维护的策略202内并且应用于数据中心110内的特定资源。警报可以响应于来自用户的输入或者响应于其他设置来应用于特定范围：“主机”、“实例”和“服务”。此外，对于特定范围类型，警报可以应用于该范围类型资源的子集。例如，当警报的范围被配置为“主机”时，警报可以应用于所有主机或属于指定主机聚合的主机。当警报的范围配置为“实例”时，警报可以配置用于并应用于一个或多个特定项目。策略控制器201可以自动地配置与范围匹配的任意新资源的警报。例如，策略控制器201可以响应于用户输入来针对(例如，由一个或多个虚拟机148执行的)给定项目配置具有“实例”范围的警报。此后，当一个或多个服务器126在该项目中创建实例时，策略控制器201可以为新实例配置警报。因此，在一些示例中，针对警报的基本配置设置可以包括标识警报的名称、范围(警报应用的资源的类型：“主机”或“实例”)、聚合体(警报应用的资源集合)、模式(“警报”或“事件”)、度量(例如，将由策略代理205监视的度量)、聚合函数(例如，策略代理205在每个测量间隔期间可以如何组合样本-示例包括平均值、最大值、最小值、总和和标准偏离函数)、比较函数(例如，如何将测量值与阈值进行比较，诸如测量值是高于、低于还是等于阈值)、阈值(将度量测量与其进行比较的值)、单位类型(由度量类型确定)、和间隔(以秒或其他单位时间的测量间隔的持续时间)。警报可以定义应用于被监视的元件集合(例如项目中的虚拟机)的策略。当针对给定元件的警报条件被观察到时，通知被生成。用户可以配置警报以将通知发布给外部HTTP端点。对于每个通知，策略控制器201和/或策略代理205可以将JSON有效载荷发布给端点。有效载荷的模式可以由以下表示，其中“字符串”和0是用于分别指示值的类型、字符串和数字的通用占位符：在一些示例中，“说明”对象描述针对其该通知被生成的警报配置。在一些示例中，“状态”对象描述用于该特定通知的时间事件信息，诸如当条件被观察到的时间以及条件被观察到的元件。上面表示的模式对于每个字段可以具有以下值：严重性：“严重”、“错误”、“警告”、“信息”、“无”度量类型：请参阅度量。模式：“警报”、“事件”模块：生成警报的分析模块。“警报”、“健康/风险”、“服务警报”之一。状态：警报的状态。对于“警告”模式警报，有效值为“有效”、“无效”、“学习”。对于“事件”模式警报，状态总是“被触发”。阈值：阈值单位对应于度量类型。元件类型：实体的类型。“实例”、“主机”、“服务”之一。元件标识：实体的UUID。元件细节：关于实体的补充细节。此对象的内容取决于元件类型。对于“主机”或“服务”，该对象为空。对于“实例”，该对象将包含主机标识和项目标识。分析引擎214可以对在使用度量数据存储库216存储的数据执行分析、机器学习和其他功能或与使用度量数据存储216存储的数据有关的其他功能。分析引擎214可以进一步基于这样的信息生成报告、通知和警报。例如，分析引擎214可以分析在使用度量数据存储库216中存储的信息并且基于关于内部处理器度量的信息来标识以可能不利地影响在服务器126上执行其他虚拟机148的操作的方式进行操作的一个或多个虚拟机148。分析引擎214可以响应于标识以可能不利地影响其他虚拟机148的操作的方式操作的一个或多个虚拟机148，生成一个或多个报告和通知212。分析引擎214可以备选地或者另外地发出警报和/或引起或指令策略代理205采取动作来解决所标识的虚拟机148的操作。分析引擎214还可以分析一个或多个虚拟机148的度量，并基于该分析来在虚拟机148中的每一个倾向于消耗的共享资源方面来表征一个或多个虚拟机148。例如，分析引擎214可以将一个或多个虚拟机148表征为CPU限定、存储器限定、或高速缓存限定。使用度量数据存储库216可以表示用于存储与由策略代理205收集的度量有关的信息的任意合适的数据结构或存储介质。例如，使用度量数据存储库216可以使用NoSQL数据库来实现。在使用度量数据存储库216中存储的信息可以是可搜索的和/或被分类，使得分析引擎214、数据管理器218或策略控制器201的另一组件或模块可以提供来自使用度量数据存储库216的输入请求信息，并响应于输入，接收在使用度量数据存储库216存储的信息。使用度量数据存储216库可主要由数据管理器218维护。在一些示例中，“度量”是基础设施中的资源的测量值。策略代理205可以收集和计算由主机和实例利用的资源的度量。度量可以基于度量类型来被组织成层级类别。一些度量是总容量的百分比。在这种情况下，度量的类别确定了通过其计算百分比的总容量。例如，host.cpu.usage指示相对于主机上可用的总CPU消耗的CPU百分比。相反，instance.cpu.usage是相对于可用于实例的总CPU消耗的CPU的百分比。作为一个示例，考虑一个使用具有20个核的主机上的一个核的50％的实例。该实例的host.cpu.usage将为2.5％。如果实例已分配2个内核，则其instance.cpu.usage将为25％。警报可以被配置用于任意度量。许多度量也可以以例如基于图的形式显示在面板203内的用户界面中。当警报触发度量时，警报可以在事件的时间处被绘制在图上。通过这种方式，可能不会直接作为图绘制的度量可能与其他度量在时间上可视地相关。在以下示例中，主机可以使用一个或多个资源，例如CPU(“cpu”)和网络(“network”)，每个资源具有一个或多个相关联的度量，例如存储器带宽(“mem_bw”)和使用(“usage”)。类似地，实例可以使用各自具有一个或多个相关联的度量(例如，存储器带宽(“mem_bw”)和使用(“usage”))的一个或多个资源，例如虚拟CPU(“cpu”)和网络(“network”)。实例本身可能是主机或实例聚合体的资源，主机本身可能是主机聚合体的资源，等等。在一些示例中，可用于主机的原始度量可以包括：host.cpu.io_wait,host.cpu.ipc,host.cpu.l3_cache.miss,host.cpu.l3_cache.usage,host.cpu.mem_bw.local,host.cpu.mem_bw.remote**,host.cpu.mem_bw.total**,host.cpu.usage,host.disk.io.read,host.disk.io.write,host.disk.response_time,host.disk.read_response_time,host.disk.write_response_time,host.disk.smart.hdd.command_timeout,host.disk.smart.hdd.current_pending_sector_count,host.disk.smart.hdd.offline_uncorrectable,host.disk.smart.hdd.reallocated_sector_count,host.disk.smart.hdd.reported_uncorrectable_errors,host.disk.smart.ssd.available_reserved_space,host.disk.smart.ssd.media_wearout_indicator,host.disk.smart.ssd.reallocated_sector_count,host.disk.smart.ssd.wear_leveling_count,host.disk.usage.bytes,host.disk.usage.percent,host.memory.usage,host.memory.swap.usage,host.memory.dirty.rate,host.memory.page_fault.rate,host.memory.page_in_out.rate,host.network.egress.bit_rate,host.network.egress.drops,host.network.egress.errors,host.network.egress.packet_rate,host.network.ingress.bit_rate,host.network.ingress.drops,host.network.ingress.errors,host.network.ingress.packet_rate,host.network.ipv4Tables.rule_count,host.network.ipv6Tables.rule_count,openstack.host.disk_allocated,openstack.host.memory_allocated,和openstack.host.vcpus_allocated。在一些示例中，可用于主机的计算度量包括：host.cpu.normalized_load_1M,host.cpu.normalized_load_5M,host.cpu.normalized_load_15M,host.cpu.temperature,host.disk.smart.predict_failure,和host.heartbeat。例如，host.cpu.normalized_load是标准化的负载值，其可以被计算为运行和准备运行的线程的数目与CPU核的数目的比。这度量族可以指示CPU的需求水平。如果该值超过1，则比存在的用于执行该执行的CPU核多的线程准备运行。标准化负荷可以被提供为1分钟、5分钟和15分钟的间隔上的平均。度量host.cpu.temperature是可以从处理器和机架中的多个温度传感器导出的CPU温度值。这个温度提供了物理主机内部以摄氏度为单位的温度的一般指示符。度量host.disk.smart.predict_failure是一个或多个策略代理205可以使用由盘硬件提供的多个S.M.A.R.T计数器来计算的值。当其根据S.M.A.R.T.计数器的组合确定磁盘可能故障时，策略代理205可以将predict_failure设置为真(值＝1)。针对此度量触发的警报可以包含元数据中的磁盘标识符。度量host.heartbeat是可以指示策略代理205是否在主机上起作用的值。策略控制器201可以通过向策略代理205中的每一个发出状态请求来周期性地检查每个主机的状态。host.heartbeat度量对于每个成功的响应而递增。警报可以被配置为检测给定时间间隔内未命中的心跳。在一些示例中，以下原始度量可用于实例：instance.cpu.usage,instance.cpu.ipc,instance.cpu.l3_cache.miss,instance.cpu.l3_cache.usage,instance.cpu.mem_bw.local,instance.cpu.mem_bw.remote,instance.cpu.mem_bw.total,instance.disk.io.read,instance.disk.io.write,instance.disk.usage,instance.disk.usage.gb,instance.memory.usage,instance.network.egress.bit_rate,instance.network.egress.drops,instance.network.egress.errors,instance.network.egress.packet_rate,instance.network.egress.total_bytes,instance.network.egress.total_packets,instance.network.ingress.bit_rate,instance.network.ingress.drops,instance.network.ingress.errors,instance.network.ingress.packet_rate,andinstance.network.ingress.total_bytes,andinstance.network.ingress.total_packets。在一些示例中，以下计算的度量可用于实例：instance.heartbeat。在一些示例中，以下原始度量可用于虚拟路由器142：host.contrail.vrouter.aged_flows,host.contrail.vrouter.total_flows,host.contrail.vrouter.exception_packets,host.contrail.vrouter.drop_stats_flow_queue_limit_exceeded,host.contrail.vrouter.drop_stats_flow_table_full,host.contrail.vrouter.drop_stats_vlan_fwd_enq,host.contrail.vrouter.drop_stats_vlan_fwd_tx,host.contrail.vrouter.flow_export_drops,host.contrail.vrouter.flow_export_sampling_drops,host.contrail.vrouter.flow_rate_active_flows,host.contrail.vrouter.flow_rate_added_flows,andhost.contrail.vrouter.flow_rate_deleted_flows。在一些示例中，以下原始度量可用于在面板203内包括的OpenStackProjectChartView：openstack.project.active_instances,openstack.project.vcpus_allocated,openstack.project.volume_storage_allocated,openstack.project.memory_allocated,openstack.project.floating_ip_count,openstack.project.security_group_count,和openstack.project.volume_count。在一些示例中，以下原始度量可用于面板203内包括的KubernetesPodChartView中：pod.memory_allocated，pod.vcpus_allocated。数据管理器218提供用于与部署在服务器126中的策略代理205进行通信的消息传送机制。数据管理器218可以例如向配置和编程的策略代理发布消息，并且可以管理从策略代理205接收的度量和其他数据，并将这些数据中的一些或全部存储在使用度量数据存储库216内。数据管理器218可以例如从一个或多个策略代理205接收原始度量。数据管理器218可以备选地或附加地接收由策略代理205对原始度量执行的分析的结果。可选地或附加地，数据管理器218可以接收与可以用于对一个或多个输入/输出设备248进行分类的一个或多个输入/输出设备248的使用的模式有关的信息。数据管理器218可以将这样的信息中的一些或全部存储在使用度量数据存储库216内。在图2的示例中，服务器126表示为诸如VM148的虚拟主机提供执行环境的物理计算节点。也就是说，服务器126包括底层物理计算硬件244，底层物理计算硬件244包括一个或多个物理微处理器240、诸如DRAM的存储器249、电源241、一个或多个输入/输出设备248、以及一个或多个存储设备250。如图2所示，物理计算硬件244为管理程序210提供执行环境，其是提供轻量级内核209并且操作来为虚拟机148、容器和/或其他类型的虚拟主机提供虚拟化的操作环境的软件和/或固件层。服务器126可以表示图1中所图示的服务器126(例如，服务器126A至服务器126N)中的一个在所示的示例中，处理器240是具有用于执行指令的一个或多个内部处理器核243、一个或多个内部高速缓存或高速缓存设备245、存储器控制器246以及输入/输出控制器247的集成电路。虽然在图2的示例中，服务器126被图示仅具有一个处理器240，在其他示例中，服务器126可以包括多个处理器240，多个处理器240中的每一个可以包括多个处理器核。服务器126的设备、模块、存储区域或其他组件中的一个或多个可以互连以能够实现组件间通信(物理地、通信地和/或操作地)。例如，核243可以经由存储器控制器246向存储器249写入数据或从存储器249读取数据，存储器控制器246向存储器总线242提供共享接口。输入/输出控制器247可以通过输入/输出总线251与一个或多个输入/输出设备248和/或一个或多个存储设备250通信。在一些示例中，这种连接性的某些方面可以通过通信信道来提供，通信信道包括系统总线、网络连接、进程间通信数据结构、或者用于传送数据或控制信号的任意其他方法。在处理器240内，处理器核243A-243N(统称为“处理器核243”)中的每一个提供独立的执行单元以执行符合处理器核的指令集合架构的指令。服务器126可以包括任意数目的物理处理器和任意数目的内部处理器核243。通常，处理器核243中的每一个被组合为使用单个IC(即，芯片多处理器)的多核处理器(或“多个核”处理器)。在一些实例中，用于计算机可读存储介质的物理地址空间可以在一个或多个处理器核243(即，共享存储器)之间被共享。例如，处理器核243可以经由存储器总线242连接到呈现由处理器核243可访问的物理地址空间的一个或多个DRAM封装、模块和/或芯片(也未图示)。尽管该物理地址空间可以提供处理器核243对存储器249的部分中的任一个的最低存储器访问时间，存储器249的剩余部分中的至少一些可以直接被处理器核243访问。存储器控制器246可以包括用于使得处理器核243能够通过存储器总线242与存储器249通信的硬件和/或固件。在所示的示例中，存储器控制器246是集成存储器控制器，并且可以物理地实现(例如，作为硬件)在处理器240上。然而，在其他示例中，存储器控制器246可以分离地或以不同的方式实现，并且可以不被集成到处理器240中。输入/输出控制器247可以包括用于使处理器核243能够与连接到输入/输出总线251的一个或多个组件通信和/或交互的硬件、软件和/或固件。在所示的示例中，输入/输出控制器247是集成的输入/输出控制器，并且可以在处理器240上物理地实现(例如，作为硬件)。然而，在其他示例中，存储器控制器246也可以分离地和/或以不同的方式实现，并可以不被集成到处理器240中。高速缓存245表示在处理器核243之间共享的处理器240内部的存储器资源。在一些示例中，高速缓存245可以包括一级、二级或三级高速缓存或其组合，并且可以提供由处理器核243可访问的存储介质中的任一个的最低延迟存储器访问。然而，在本文描述的大多数示例中，高速缓存245表示三级高速缓存，与一级高速缓存和/或二级高速缓存不同，其通常在现代多核处理器芯片中的多个处理器核之间被共享。然而，根据本公开的一个或多个方面，在一些示例中，本文中所描述的技术中的至少一些可应用于其他共享资源，包括除三级高速缓存之外的其他共享存储器空间。电源241向服务器126的一个或多个组件提供功率。电源241通常从数据中心、建筑物或其他位置处的主要交流电(AC)电源接收功率。电源241可以在多个服务器126和/或数据中心110内的其他网络设备或基础设施系统之间共享。电源241可以具有智能电源管理或消耗能力，并且这些特征可以由服务器126的一个或多个模块和/或由一个或多个处理器核243控制、访问或调整，以智能地消耗、分配、供应或以其他方式管理功率。一个或多个存储设备250可表示计算机可读存储介质，其包括以用于诸如处理器可读指令、数据结构、程序模块或其他数据的信息的存储的任意方法或技术实现的易失性和/或非易失性、可移除和/或不可移除介质。计算机可读存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、EEPROM、闪存、CD-ROM、数字多功能光盘(DVD)或其他光存储、盒式磁带、磁带、磁盘存储器或其他磁存储设备、或可用于存储期望信息并且可由处理器核243访问的任意其他介质。一个或多个输入/输出设备248可以表示服务器126的任意输入或输出设备。在这样的示例中，输入/输出设备248可以生成、接收和/或处理来自能够检测来自人或机器的输入的任意类型的设备的输入。例如，一个或多个输入/输出设备248可以以物理、音频、图像和/或视觉输入(例如，键盘、麦克风、摄像机)的形式生成、接收和/或处理输入。一个或多个输入/输出设备248可以通过能够产生输出的任意类型的设备来生成、呈现和/或处理输出。例如，一个或多个输入/输出设备248可以以触觉、音频、视觉和/或视频输出(例如，触觉响应、声音、闪光灯和/或图像)的形式生成、呈现和/或处理输出。一些设备可以用作为输入设备，一些设备可以用作为输出设备，并且一些设备可以用作为输入设备和输出设备两者。存储器249包括一个或多个计算机可读存储介质，其可以包括诸如各种形式的动态RAM(DRAM)(例如DDR2/DDR3SDRAM)或静态RAM(SRAM)的随机存取存储器(RAM)、闪存或任意其他形式的固定或可移除存储介质，其可以用于以指令或数据结构的形式携带或存储期望的程序代码和程序数据并且可以由计算机访问。存储器249提供包含可寻址存储器位置的物理地址空间。存储器249在一些示例中可以向处理器核243呈现非统一存储器访问(NUMA)架构。也就是说，处理器核243可能不具有对构成存储器249的各种存储介质相等的存储器访问时间。处理器核243可以是在一些情况下被配置为使用为核提供较低存储器延迟的存储器249的部分以减少总体存储器延迟。内核209可以是在内核空间中执行的操作系统内核，并且可以包括例如Linux、BerkeleySoftwareDistribution(BSD)或另一Unix变体内核或从Microsoft公司可获得的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)、Xen、可从VMware获得的ESXi、可从Microsoft获得的WindowsHyper-V、以及其他开源和专有管理程序。在该特定示例中，服务器126包括在管理程序210内执行的虚拟路由器142，并且可以以与结合图1提供的描述一致的方式操作。在图2的示例中，虚拟路由器142可以管理一个或多个虚拟网络，每一个虚拟网络可以为由管理程序210提供的虚拟化平台的顶部上的虚拟机148提供用于执行的网络环境。虚拟机148中的每一个可以与虚拟网络中的一个相关联。策略代理205可以作为管理程序210的一部分执行，或者可以在内核空间内执行或者作为内核209的一部分执行。策略代理205可以监视与服务器126相关联的性能度量的一些或全部。根据本文描述的技术，除了服务器126的其他度量之外，策略代理205被配置为监视与处理器240内部的、由在服务器126的多核处理器240内的处理器核243上执行的进程151中的每一个来共享的资源的使用有关的使用的度量或者描述处理器240内部的、由在服务器126的多核处理器240内的处理器核243上执行的进程151中的每一个来共享的资源的。在一些示例中，这样的内部处理器度量涉及高速缓存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中的每一个可以与进程标识符相关联，该进程标识符由处理器核243使用以在报告一个或多个度量(诸如由策略代理205收集的内部处理器度量)时标识进程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。如本文所描述的虚拟机148中的每一个内的进程151使用在给定物理处理器240内部共享的资源的方式通常难以检测和管理，并且因此可能导致类似地在相同物理处理器内执行的虚拟机148中的不同一个内的进程151的性能问题。例如，在处理器核243A上执行的第一进程(例如，虚拟机148A内的进程151A之一)可以执行存储器操作，该存储器操作导致来自存储器249的数据被加载到高速缓存器245中。内核209可以在该数据被加载到高速缓存245中之后，执行上下文切换，使得第二进程(例如，进程151B之一)开始在处理器核243A(或处理器核243中的另一个)上执行。该第二进程(虚拟机148B内的进程151B之一)可以执行也导致数据被加载到共享高速缓存245中的存储器访问操作。如果第二进程执行占用或消耗大量高速缓存空间的操作，则由第一进程在高速缓存中存储的数据可以被重写。在由第一进程在高速缓存中存储的数据被第二进程重写之后，内核209可以最终执行上下文切换以恢复第一进程(即，来自进程151A)的执行。该第一进程可以尝试访问将以其他方式从高速缓存245可以快速可用的相同数据，但是由于作为第二进程(即，来自进程151B)执行的操作的结果，该数据从高速缓存245中被清除，所以第一进程会将经历页面错误和/或高速缓存未命中。处理器240然后将从存储器249重新取回数据，但是访问来自存储器249的数据很可能比访问来自高速缓存245的数据慢得多。因此，作为由第二进程执行的与高速缓存相关的操作的结果，第一进程的执行可能被不利地影响。换言之，即使当虚拟机的给定软件应用被分配了存储器249的其他足够共享和处理器240和/或其中的处理器核243的CPU时间，由另一软件应用的处理器240内部的高速缓存245的利用(并且因此通常不可见)可以导致这两个应用的差的和不可预测的性能。这样，本文描述了通过其使策略代理被配置为询问处理器240以获得资源(诸如高速缓存245)的度量的技术，该资源在处理器内部被共享并且因此否则在处理器外部不是可见的。此外，该技术利用策略控制器201提供的性能监视和策略实施机制内的内部处理器度量，从而提供对计算环境的改进的细粒度控制。作为另一示例，虚拟机148中的一个内的一个或多个进程151使用处理器240内部的其他共享资源的方式也可能导致其他进程的性能问题。例如，在处理器核243上执行的第一进程(例如，虚拟机148A内的进程151A之一)可以周期性地从存储器249读取和向存储器249写入。也在处理器核243上执行的第二进程(例如，虚拟机148B内的进程151B之一)也可以从存储器249读取和向存储器249写入。这样，第一进程和第二进程各自消耗处理器240内部的存储器总线242可用的带宽的一部分。然而，第二进程可以是高度存储器密集型进程，其执行涉及存储器总线242的许多操作。通过执行涉及存储器总线242的许多操作，第二进程可消耗存储器总线242的很多带宽，使得第一进程从存储器249读取和向存储器249写入的能力可能受到不利影响。因此，作为涉及共享存储器总线242的第二进程的操作的结果，第二进程的执行可能受到不利影响。在刚描述的示例中，进程可以在不同的虚拟机中或在相同的虚拟机上执行。在任意情况下，状况出现，其中不管被设计用于分配存储器249和处理器240和/或核243的公平数量的利用的策略如何，由处理器240内部的软件进程共享的利用资源可能以某种方式影响虚拟机148A的性能，以及相应地由虚拟机148A消耗的计算资源可能以某种方式影响虚拟机148B的性能。在这个意义上，虚拟机148A和虚拟机148B必须在相同服务器126上共存，因此必须在可能被认为是相同的“邻居”的地方共存。此外，在虚拟机148中的一个消耗大量的共享资源的情况下，特别是在消耗影响其他虚拟机148的情况下，资源消耗进程可能被认为是破坏邻居，并因此被标记为“嘈杂的”邻居。当针对在服务器126上执行的虚拟机148之一性能问题出现时，这些问题可能是服务器126上的嘈杂邻居(例如，资源密集型不同虚拟机)的结果。然而，诸如与处理器核243相关联的CPU利用率或CPU负载的一些典型或常见使用和/或性能度量可能不能精确定位或以其他方式标识哪个虚拟机可能被牵连为噪声邻居。换句话说，在虚拟机148中的一个正在消耗处理器240内部共享的资源并且在影响其他虚拟机148的方式中的情况下，该消耗可能不反映在诸如CPU利用率或CPU负载的度量中。相应地，可能需要其他资源度量以便标识和作用于可能以正在或将要影响其他虚拟机148、容器和/或进程151的性能的方式消耗共享资源的任意虚拟机148、容器和/或进程151。在图2的示例中，并且根据本公开的一个或多个方面，策略代理205监视服务器126的操作以标识以可能影响其他虚拟机148的操作的方式使用服务器126的处理器240内部的共享资源的虚拟机148。例如，策略代理205可以监视内部处理器度量，内部处理器度量关于或描述由服务器126内的处理器核243上执行的每个进程151对高速缓存245的使用。策略代理205可以备选地或附加地监视内部处理器度量，内部处理器度量关于或描述由服务器126内的处理器核243上执行的每个进程151对存储器总线242的存储器带宽的消耗。策略代理205可备选地或附加地监视内部处理器度量，内部处理器度量关于或描述由服务器126内的处理器核243上执行的每个进程151对其他共享资源的使用和/或消耗。为了访问和监视内部处理器度量，策略代理205可以通过由内核209的API揭示的专用硬件接口254来询问处理器240。例如，策略代理205可以访问或操纵处理器核243的一个或多个硬件寄存器以编程处理器240的监视电路(“MONCIRC”)252，用于内部监视共享资源并经由接口来报告那些资源的使用度量。策略代理205可以通过调用内核、操作系统和/或管理程序调用来访问和操纵处理器240的硬件接口。例如，处理器240的硬件接口可以是经由内核209映射的存储器，使得用于监视处理器的内部资源的处理器240的可编程寄存器可以由针对特定存储器地址的存储器访问指令来读取和写入。响应于策略代理205的这种指示，处理器240内部的监视电路252可以监视处理器核243的执行，并且向策略代理205传送关于每个进程151的内部处理器度量的信息或以其他方式使关于每个进程151的内部处理器度量的信息可用于策略代理205。策略代理205可以维护将处理器度量与在虚拟机148内执行的每个进程151相关联的映射。例如，策略代理205可以询问内核209以标识与在虚拟机148上执行的每个软件进程相关联的进程标识符。策略代理205可以使用与虚拟机148相关联的每个进程151的进程标识符来将针对每个进程151由处理器核243报告的处理器度量与虚拟机148之一相关联。策略代理205可以使用该信息来从与处理151中的每一个相关联的处理器度量中推断与虚拟机148中的每一个相关联的处理器度量。策略代理205可以使用与虚拟机148中的每一个相关联的推断的处理器度量来标识虚拟机148中的每一个如何使用服务器126的共享资源。策略代理205可以评估内部处理器度量并确定一个或多个虚拟机148是否以可能不利地影响其他虚拟机148的操作的方式使用共享资源。策略代理205可以响应于标识以可能不利地影响其他虚拟机148的操作的方式来正在使用共享资源的一个或多个虚拟机148而引发警报。例如，策略代理205可以分析虚拟机148B或在虚拟机148B内执行的一个或多个进程151B的内部处理器度量。策略代理205可以将一个或多个度量与警报阈值进行比较。警报阈值可以基于策略代理205从策略控制器201接收的、或由策略控制器201(或者来自策略控制器201的一个或多个组件)以其他方式表达的一个或多个策略202。策略代理205可以评估多个区间的内部处理器度量，并且根据一个或多个策略202评估处理器度量的统计(例如，平均、最大、标准差)。在一些示例中，策略代理205可以评估针对虚拟机148B在一段时间(例如，五分钟)内和/或在多个间隔上的内部处理器度量来确定用于虚拟机148B的内部处理器度量的代表性集合。策略代理205可以过滤出所收集的内部处理器度量中的不表示虚拟机148B的正常操作和/或不可能影响与服务器126内的虚拟机148B相邻的虚拟机148的操作的收集的内部处理器度量中的任意偏差。策略代理205可以基于这样的评估来确定虚拟机148B的内部处理器度量超过在一个或多个策略202中表达的警报阈值，或者与虚拟机148B相关联的内部处理器度量否则触发警报。策略代理205可以响应于警报，采取一个或多个动作来防止对其他虚拟机148的性能的有害影响。例如，警报或警报所基于的度量可以指示虚拟机器148B可能以可能影响一个或多个其他虚拟机148的性能的方式使用高速缓存245。策略代理205可以以下各项来对这种警报起作用：通过限制虚拟机148B对高速缓存245的使用，通过划分高速缓存245使得虚拟机148中的每一个仅具有对高速缓存245的一部分的访问，通过向虚拟机148B分配较小部分，通过将重叠或隔离的高速缓存行指派给一个或多个虚拟机148或进程151，或通过以其他方式限制在虚拟机148B内执行的虚拟机148B对高速缓存245的使用。在另一示例中，警报或者警报所基于的度量可以指示虚拟机148B可能正在消耗存储器带宽到了使得它正在影响试图使用存储器带宽的其他虚拟机148的性能的程度。通过限制虚拟机148B对存储器带宽的使用，策略代理205可以对这样的警报起作用。在一些示例中，策略代理205可以通过限制对在特定虚拟机内执行的一个或多个进程使用的共享资源的使用来限制一个或多个虚拟机对共享资源的使用。例如，警报或者警报所基于的度量可以指示虚拟机148B内的特定的被标识的进程正在以以下方式使用共享资源：该方式不仅可以影响一个或多个其他虚拟机148的性能而且还影响在相同虚拟机148B内执行的一个或多个其他进程151的性能。策略代理205可以通过限制由虚拟机148B内的所标识的进程对一个或多个共享资源的使用来对这样的警报起作用。策略代理205可以将限制仅应用于虚拟机148B内的所标识的进程，而不应用于虚拟机148B内的所有进程。在一些示例中，虚拟机148B本身可以实例化虚拟机148B内的一个或多个虚拟机。如果这个“第二级”虚拟机本身变成“嘈杂”，则策略代理205可以将限制仅应用于虚拟机148内的嘈杂虚拟机，并且避免限制虚拟机148B内的其他进程，其中这样的限制可能不被保证或不是必要的。在一些示例中，备选地或另外地，策略代理205可以向策略控制器201报告关于内部处理器度量的信息。例如，策略代理205可以从处理器核243收集处理器度量。策略代理205可以标识与所收集的处理器度量中的一些或全部相关联的虚拟机148。策略代理205可以向数据管理器218传送关于所收集的处理器度量的信息。数据管理器218可以将所接收的信息的一些或全部存储在使用度量数据存储库216中。策略控制器201可以对从策略代理205接收的关于内部处理器度量的信息起作用。例如，分析引擎214可以分析存储在使用度量数据存储库216中的信息，并且基于关于内部处理器度量的信息来标识以可能不利地影响在服务器126上执行的其他虚拟机148的操作的方式进行操作的一个或多个虚拟机148。分析引擎214可以响应于标识一个或多个虚拟机148来生成一个或多个报告和通知212。分析引擎214可以备选地或另外地引起或指示策略代理205采取行动以解决所标识的虚拟机148的操作。在一些示例中，备选地或另外地，策略代理205可以向策略控制器201报告从处理器核243的内部处理器度量导出的信息。换句话说，不是简单地向策略控制器201报告内部处理器度量，策略代理205可以对所收集的度量执行一些分析，并且将这种分析的结果报告给策略控制器201。例如，策略代理205可以收集处理器度量并且标识以可能不利影响在服务器126上执行的其他虚拟机148的操作的方式进行操作的一个或多个虚拟机148。策略代理205可以向数据管理器218传送关于其分析结果的信息，其可以标识一个或多个虚拟机148和/或可能涉及的共享资源。分析引擎214可以响应于这样的信息来指示策略代理205采取动作来解决所标识的虚拟机148的操作。因此，包括来自处理器核243的内部处理器度量的各种度量的处理和/或分析，可以由策略代理205，由策略控制器201(例如分析引擎214)，由策略代理205和策略控制器201的组合，或者由服务器126的另一模块或组件来执行。在一些示例中，策略代理205和/或策略控制器201可以使用在一些至强处理器中可用的英特尔的资源目录技术(RDT)来监视与处理器核243相关联的内部处理器度量，作为处理器240的监视电路252的一个示例。英特尔的RDT能够实现资源监视和控制特征，其被设计用于改进对共享平台资源如何被使用的可见性并对共享平台资源如何被使用进行控制。例如，通过使用监视电路252的RDT的高速缓存监视技术(CMT)，策略代理205可以确定正在服务器126上执行的个体线程的最终级高速缓存利用率。策略代理205和/或策略控制器201可以使用该信息来导出一个或多个虚拟机148(或进程151)对高速缓存245的使用。在另一示例中，策略代理205可以使用监视电路252的RDT的存储器带宽监视(MBM)来标识针对服务器126上的虚拟机148内执行的个体线程的本地存储器带宽使用。在RDT中，MBM是CMT的扩展，其提供针对其远程和本地存储器带宽使用监视每个线程。在另一示例中，策略代理205可以使用监视电路252的RDT的高速缓存分配技术(CAT)来优先化不同的虚拟机148或在服务器126上执行的进程。管理程序210、策略控制器201和/或策略代理205可以使用CAT来将高速缓存245划分给在服务器126上执行的不同虚拟机148。在另一示例中，策略代理205还可以使用RDT的代码和数据优先化(CDP)来将代码和数据段分配到高速缓存245中。为了访问通过RDT可用的信息，策略代理205可以访问由内核209揭示的CPU标识符信息和监视电路252的信息，以验证处理器核243是否实现了RDT能力中的一些或全部。策略代理205可以与英特尔处理器和在英特尔处理器上运行的内核进行交互。例如，如果处理器核243实现RDT或类似技术，则策略代理205可以通过调用适当的内核API或函数调用来配置模型特定寄存器(MSR)并对与和处理器核243相关联的期望的内部处理器度量相对应的特定项目标识符进行编程。作为响应，处理器核243可以周期性地发布所请求的内部处理器度量，或将所请求的内部处理器度量写入到指定的MSR。之后，策略代理205可以通过从指定的MSR读取来收集内部处理器度量。在一些示例中，例如当管理程序210实现Linux内核或者被实现在Linux内核之上时，Linux内核存储器映射内部处理器度量，并且控制策略代理205或其他进程如何从指定的MSR读取和写入。策略代理205可以调用适当的Linux调用以引导处理器核243监视特定的度量，并且策略代理205可以读取适当的MSR以便提取期望的内部处理器度量。策略控制器201可以建立一个或多个策略202，该一个或多个策略202指示当编配引擎130引导管理程序210加速、实例化或以其他方式启动新的虚拟机时，管理程序210将指定新虚拟机可以如何使用一个或多个共享资源。例如，策略控制器201的策略控制引擎211可以建立一个或多个策略202，该一个或多个策略202指示新的虚拟机148被给予高速缓存245的相等份额。或者高优先级虚拟机148、容器或进程151被给予更大的份额。策略控制引擎211可以使策略控制器201将一个或多个策略202传送给编配引擎130(或管理程序210)，使得当编制引擎130引导管理程序210创建新的虚拟机时，新的虚拟机器被创建具有高速缓存245的相等份额。在另一示例中，策略控制器201可以建立一个或多个策略202，该一个或多个策略202指示新虚拟机148被给予高速缓存245的特定百分比份额。在这样的示例中，策略控制引擎211可以使策略控制器201将一个或多个对应的策略202传送给编配引擎130和/或管理程序210，使得当编配引擎内核130引导管理程序210创建新的虚拟机时，新的虚拟机被创建具有高速缓存245的特定百分比份额。编配引擎130可以通过使用RDT的CAT功能或由其他处理器可用的类似功能来划分高速缓存245来实现这样的策略。在这样的示例中，策略代理205和/或策略控制器201仍可以通过进一步限制高速缓存245或其他共享资源的使用来响应警报，和/或生成一个或多个报告和通知212。REST接口可以是用于动态更新与虚拟机148和/或进程151相关联的高速缓存245的分配。例如：curl-i\-H'Content-Type:application/json'\-XPUT\-d'{"InstanceCacheAllocationPercentage":5}'\http://<host-ip-address>:7000/appformix/v1.0/instance_definition/<instance-id>在上面的示例中，可以为instance_definition设置的参数包括InstanceCacheAllocationMB、InstanceCacheAllocationPercentage和InstanceCacheAllocationEqualShare。策略控制器201和/或策略代理205可将隔离的高速缓存行提供给虚拟机148、虚拟机148的实例或应用。备选地或另外地，策略控制器201和/或策略代理205可以基于实例的优先级、实例的分类或基于应用有效载荷来分配高速缓存245的共享部分。在一些示例中，高速缓存可以逐CPU插槽地(例如，逐处理器240地)被分配。策略代理205可以基于使用、该进程集合的当前调度模式、以及该实例、虚拟机或应用的CPU核固定属性来执行分配。策略代理205和/或策略控制器201可以基于每个虚拟机消耗共享资源的方式来对一个或多个虚拟机148进行分类。例如，策略代理205可监视度量，包括一段时间内虚拟机148中的每一个的内部处理器度量。策略代理205可以针对虚拟机148中的每一个确定高速缓存245的使用模式、存储器带宽使用、每秒退出的指令、以及与虚拟机148中的每一个的操作相关联的其他度量。策略代理205可以将关于使用模式的信息传送给策略控制器201的数据管理器218。数据管理器218可将该信息存储在使用度量数据存储库216中。策略控制器201的分析引擎214可例如通过跨监视度量中的每一个执行线性回归，来分析虚拟机148中的每一个的度量。分析引擎214可以基于该分析在虚拟机148中的每一个倾向于消耗的共享资源方面表征虚拟机148中的一个或多个。例如，分析引擎214可以将一个或多个虚拟机148表征为CPU绑定、存储器绑定或高速缓存绑定。策略控制器201可以建立一个或多个策略202以限制在服务器126上具有相同或类似分类的虚拟机148的数目。例如，策略控制器201的策略控制引擎211可以建立一个或多个策略202，该一个或多个策略202就基于上面描述的虚拟机148的分类。这样的策略202可以被设计为避免具有过多的以相似的方式消耗服务器126的共享资源的虚拟机148。在一个示例中，策略控制引擎211和/或分析引擎214可以确定如果给定数目的虚拟机148可以被表征为CPU绑定，并且编配引擎130(或管理程序210)试图实例化或启动新的CPU绑定虚拟机，则一个或多个策略202可确保新虚拟机在服务器126上未被实例化或启动，而是在数据中心110内的不同物理主机上被实例化或启动。具体而言，在这样的示例中，策略控制引擎211可以建立一个或多个策略202，该一个或多个策略202将CPU绑定的虚拟机148的数目限制为与处理器核243相关联的核的数目。如果处理器核243存在16个核，则策略控制引擎211可以建立一个或多个策略202，该一个或多个策略202指示不超过16个CPU绑定虚拟机148应当在服务器126上执行。在不同的示例中，如果给定数目的虚拟机148可以被表征为高速缓存绑定，并且编配引擎130寻求实例化或启动新的高速缓存绑定的虚拟机，则一个或多个策略202可确保新的虚拟机在服务器126上未被实例化或启动，而是在数据中心110内的不同物理主机上被实例化或启动。策略控制器201可以使编配引擎130基于虚拟机148的分类来选择或调整在其上一个或多个虚拟机148正执行的物理主机。例如，参照图1和图2，策略控制器201的策略控制引擎211可以确定50个CPU绑定的虚拟机148并且没有存储器绑定的虚拟机148在服务器126A上正在执行。策略控制引擎211可以进一步确定没有CPU绑定的虚拟机148和40个存储器绑定的虚拟机148正在服务器126B上执行。如果在服务器126A上执行的50个CPU绑定的虚拟机148中的一些代之以在服务器126B上执行，并且在服务器126B上执行的40个存储器绑定的虚拟机148中的一些代之以在服务器126A上执行，则策略控制引擎211可以确定服务器126A和服务器126B各自可以更好地执行。因此，策略控制引擎211可以使策略控制器201与编配引擎130进行通信，指示编配引擎130重新分配一个或多个虚拟机148。例如，策略控制器201可以指令编配引擎130将在服务器126A上执行的虚拟机148中的一些移动到服务器126B，并且将在服务器126B上执行的虚拟机148中的一些移动到服务器126A。作为以这种方式跨服务器126地分配虚拟机148的结果，数据中心110可以展现出改进的性能。策略控制器201还可以建立策略以使用存储器带宽度量(例如，RDT的MBM度量)来改进NUMA局部性。在这样的示例中，如果远程存储器带宽大于本地存储器带宽，则策略代理205可以从处理器核243收集与未优化的NUMA相关的度量。策略代理205可以使用这些度量针对NUMA局部性重新打算或重新实现一个或多个虚拟机148。访问远程存储器的延迟可能远高于针对本地存储器的延迟。例如，分析引擎214通过使用例如静态或动态阈值、即时或历史使用数据的任意前述技术，将警报阈值与对应资源的使用度量216进行比较来评估在简档213中的每一个中包括的警报。基于藉由与元件的直接关联或与元件的间接关联来评估元件的简档213内的多个警报，因为元件由策略控制引擎211配置为与包括一个或多个警报的简档相关联的组的成员，分析引擎214将简档设置为活动或不活动，并且可以执行任意前述的改善、报告和/或通知操作中的任一个。在一些示例中，分析引擎214可以在策略代理205之间分发简档213以在服务器126上以分布式、本地的方式评估警报和简档213。图3A和图3B是图示了根据本公开的一个或多个方面的由示例用户界面设备呈现的示例用户界面的概念图。图3A中图示的用户界面301A和图3B中图示的用户界面301B可以各自对应于由用户界面设备129呈现的用户界面，并且可以是与结合图1和图2描述的面板203相对应或包括在结合图1和图2描述的面板203中的示例用户界面。虽然图3A和图3B中图示的用户界面被显示为图形用户界面，但是其他类型的界面也可以由用户界面设备129呈现，包括基于文本的用户界面、控制台或基于命令的用户界面、语音提示用户界面或任意其他适当的用户界面。用户界面301A和/或用户界面301B的一个或多个方面可以在图1和图2的数据中心110的上下文中被描述。参照图2、图3A和图3B，并且根据本公开的一个或多个方面，用户界面设备129可呈现用户界面301A和用户界面301B。例如，用户界面设备129可以检测其确定的对应于请求用户的的输入，以呈现与图2的服务器126相关联的度量。用户界面设备129可以向策略控制器201输出输入的指示。策略控制器201的策略控制引擎211可以检测输入并且确定该输入对应于对关于与服务器126相关联的度量的信息的请求。策略控制引擎211可以响应于该输入来生成面板203，该面板203可以包括在用户界面301A和用户界面301B底层的信息。策略控制引擎211可以使策略控制器201向用户界面设备129发送信息。用户界面设备129可以接收该信息，并且确定该信息包括足以生成用户界面的信息。用户界面设备129可以响应于从策略控制器201接收的信息，创建用户界面301A并以图3A所图示的方式在与用户界面设备129相关联的显示器上呈现用户界面。类似地，用户界面设备129也可以响应于从策略控制器201接收的信息来创建用户界面301B并以图3B所图示的方式在与用户界面设备129相关联的显示器处将其呈现。在图3A的示例中，用户界面301A包括CPU使用度量图310、CPU负载度量图320、磁盘使用度量图330和存储器使用度量图340。图3A中的每个图可以表示随着时间(沿着x轴)的度量值，该度量值与在服务器126上执行的多个虚拟机148相关联，并且如由图2的策略控制器201和/或策略代理205检测或确定。具体地，在图3A中，与虚拟机148A相关联的度量被显示为CPU使用312A、CPU负载322A、磁盘使用332A和存储器使用342A。另外，图3A中的虚拟机148B的度量包括CPU使用312B和存储器使用342B。在图3B的示例中，用户界面301B包括高速缓存使用图350、高速缓存未命中频率图360、本地存储器带宽图370和远程存储器带宽图380。再次，图3B中的每个图可以表示时间序列度量值，其与在服务器126上执行的多个虚拟机148相关联，并且由图2的策略控制器201和/或策略代理205检测或确定。在图3B中，与虚拟机相关联的度量包括高速缓存使用352B和高速缓存未命中频率362B。图3A中所示的信息启示虚拟机148A在大约10:35开始经历了CPU使用(参见CPU使用度量图310上的CPU使用312A)和CPU负载(参见CPU负载度量图320上的CPU负载322A)的显著增加。此外，虚拟机148A几乎同时经历了存储器使用的显著增加(参见存储器使用度量图340上的存储器使用342A)。根据图3A的用户界面301A中呈现的图，虚拟机148A的性能度量中的那些改变的原因可能不明显。特别地，请注意，图3A中的虚拟机148B的度量(例如，CPU使用312B)在10:35之后保持相对恒定，并且没有启示虚拟机148B以降低虚拟机148A的性能的方式操作。图3B的用户界面301B呈现从内部处理器度量导出的信息和图。与图3A不同，图3B提供了可能有助于标识哪个虚拟机148正在影响虚拟机148A的性能的信息。例如，虽然虚拟机148B在10:35之后具有相对恒定的20％CPU利用率(如图3A中的CPU使用312B所图示)，但是从图3B中的高速缓存使用图350(具体地，高速缓存使用352B)显而易见的是，虚拟机机器148B在大约10:35将其高速缓存使用增加到大约40MB。此外，虚拟机148B在10:35开始生成大量的高速缓存未命中(参见高速缓存未命中频率图360的高速缓存未命中频率362B)。基于该信息，策略代理205、策略控制器201和/或管理员操作用户界面设备129可以确定虚拟机148A的性能度量中的改变的原因是虚拟机148B，其可能以影响虚拟机148A的性能的方式正在使用高速缓存245。因此，并且如图3A和图3B所图示的，通过监视内部处理器度量以标识处理器内的虚拟机148B消耗的共享资源，可以标识正在以可能不利地影响竞争处理器内的那些相同资源的其他虚拟机的性能的方式消耗服务器126的处理器内的共享资源的一个或多个虚拟机。在不监视这种内部处理器度量的情况下，调试或以其他方式标识虚拟机148的性能度量中的改变的原因可能是困难的或不可能的。图4是图示根据本公开的一个或多个方面的由示例服务器执行的操作的流程图。图4在图2的服务器126的上下文内被描述。在其他示例中，图4中描述的操作可以由一个或多个其他组件、模块、系统或设备执行。此外，在其他示例中，结合图4描述的操作可以被合并、以不同的顺序被执行或省略。在图4的示例中，并且根据本公开的一个或多个方面，策略控制器201可以定义一个或多个策略(401)。例如，用户界面设备129可以检测输入，并且向策略控制器201输出输入的指示。策略控制器201的策略控制引擎211可以确定输入对应于足以定义一个或多个策略的信息。策略控制引擎211可以定义一个或多个策略并将一个或多个策略存储在策略数据存储库202。策略控制器201可以将一个或多个策略部署到在一个或多个服务器126上执行的一个或多个策略代理205(402)。例如，策略控制引擎211可以使得策略控制器201的数据管理器218向策略代理205输出信息。策略代理205可以从策略控制器201接收信息，并且确定该信息对应于将要在策略代理205处将被部署的一个或多个策略(403)。策略代理205可以配置处理器240以监视内部处理器度量(404)。例如，策略代理205可以与监视电路252交互和/或配置监视电路252以使能对处理器度量的监视。在一些示例中，策略代理可以配置监视电路252以根据资源目录技术来收集度量。处理器240可以响应于策略代理205的交互和/或配置，监视与服务器126的处理器240内共享的资源有关的内部处理器度量(405)。处理器240可以使这样的度量可用于其他设备或过程，诸如策略代理205(406)。在一些示例中，处理器240通过在存储器的指定区域或处理器240的寄存器内公布这样的度量来使得这些度量可用。策略代理205可以从处理器240读取内部处理器度量(407)。例如，策略代理205可以从寄存器(例如，模型特定寄存器)读取以访问关于与处理器240相关的内部处理器度量的信息。策略代理205可以分析度量并且根据适当的策略对服务器126进行操作(408)。例如，策略代理205可以基于内部处理器度量来确定部署在服务器126上的一个或多个虚拟机正在以可能不利地影响在服务器126上执行的其他虚拟机148的性能的方式使用在处理器240内部共享的高速缓存。在一些示例中，策略代理205可以确定部署在服务器126上的一个或多个虚拟机以可能不利地影响其他虚拟机148的性能的方式使用存储器带宽。策略代理205可以响应于这种确定来指令处理器240诸如通过将高速缓存的较小部分分配给该虚拟机来限制违规的(offending)虚拟机对共享高速缓存的使用。处理器240可以接收这样的指令并且根据从策略代理205接收的指令来限制违规的虚拟机对共享高速缓存的使用(409)。在一些示例中，策略代理205可以向策略控制器201报告信息(410)。例如，策略代理205可以向策略控制器201的数据管理器218报告内部处理器度量。备选地或另外地，策略代理205可以基于内部处理器度量来向数据管理器218报告由策略代理205执行的分析结果。响应于接收到由策略代理205报告的信息，策略控制器201可以生成一个或多个报告和/或通知(411)。例如，策略控制器201的分析引擎214可以生成一个或多个报告并且使得用户界面设备129将这样的报告呈现为用户界面。备选地或另外地，分析引擎214可以生成一个或多个警报，该一个或多个警报可以被包括在或被报告在由策略控制器201经由用户界面设备129呈现的面板203中。图5A-5B是图示了根据本公开的技术的用于多个元件的示例性简档层级和多种类型的组的组简档的的框图。元件500A-500J(“元件500”)消耗警报数据的来源的资源。示例元件可能包括主机、网络设备、实例和服务。元件500中的每一个与由用户或管理员为该元件配置的元件简档相关联。所图示的示例描绘了元件500A的元件简档550A。元件简档550可以表示任意简档213的示例实例，并且是监视警报的集合，该监视警报被评估以确定对应元件500的性能是否满足为警报定义的准则。类型-1组510A-510L(“类型-1组510”)各自是关联一个或多个元件500的数据结构。类型-2组520A-520L(“类型-2组520”)各自是关联一个或多个元件500的数据结构。单个元件500可以是一个或多个类型-1组510和一个或多个类型-2组520的成员。类型1和类型2表示不同类型的组，元素可能是不同类型的组的成员。组的类型可以包括聚合体(例如主机聚合体、实例聚合体、网络设备聚合体、网络设备接口聚合体)、虚拟网络、虚拟化网络功能(VNF)或VNF的集合、网络服务链。其他类型的组可能包括OpenStack或被指派了实例集合的其他项目、KubernetesPod、Kubernetes名称空间、Kubernetes复制控制器和Kubernetes服务。其他类型的组可以包括由OpenStack实例执行的一组一个或多个服务，这些服务包括例如RabbitMq、MySQL、Nova和Neutron服务。类型1和类型2可以是任意不同的，从上述示例中选择的组合，或者本文没有具体提到的其他示例。OpenStack样式系统项目的示例可以包括：1.特定的应用示例数据库项目，被指派了10个虚拟机的，其中一些用户可以访问该项目。虚拟机中的八个可以具有一个功能，例如，维护数据库项目的数据读取/写入，并且虚拟机中的两个可以具有另一功能，例如元数据或备份相关任务。2.VNF池，用于提供诸如虚拟防火墙服务的虚拟化网络服务。3.应用的组合，例如数据库可以被指派10个虚拟机，MessageBus可以被指派由团队拥有的10个虚拟机。4.实例用例的混合模型，其中单个虚拟机可以被不同的应用使用，诸如具有运行的数据库和MessageBus应用两者的十个虚拟机的并置层。不同的实体可以配置不同的类型1组510和类型2组520。例如，数据中心110管理员可以配置类型1组510并且用户可以配置类型2组520。一个或多个类型1组510可以具有对应的类型1组简档560。类型1组简档560A是类型1组510A的简档。一个或多个类型2组520可以具有对应的类型2组简档570。类型2组简档570A是类型2组520A的简档。为了清楚起见，仅图示了一个类型1组简档560和一个类型2组570。每个简档550、560、570是被评估以确定对应元件或组是否满足由警报监视的资源度量的用户定义准则的警报的集合。简档的警报可以被组织成称为规则集合的组。简档可能有一个或多个规则集合。规则集合包含一个或多个警报集合以及为警报相应指派的权重。该规则集合还包含一个阈值。为了确定简档的规则集合是否是活动的，策略控制器201或策略代理205计算规则集合中的所有活动警报的加权和。如果加权总和大于或等于阈值，则规则集合是活动的。如果简档的组成规则集合中的任一个是活动的，则简档被视为是活动的。图5A描绘了其中策略控制器201评估简档的示例，而图5B描绘了一个或多个策略代理205评估简档的示例。在一些情况下，策略控制器201和策略代理205两者均可以评估简档是简档层级的不同级别。在一些示例中，简档是具有范围、类型、唯一简档标识符和或更多规则集合的数据结构(例如包、集合或表)。简档的示例方案如下：简档:范围:<字符串>类型:<字符串>唯一标识:<uuid>规则集合:<规则集合对象列表>范围在上面被定义并且表示简档应用的元件或组的类型，例如主机、主机聚合体或实例。类型表示简档的目的，例如用于定义和监视对应元件或组的健康。唯一标识是查找和区分简档的唯一标识符。规则集合和规则集合对象列表，如下所述。如上所述，规则集合包含一个或多个警报集合以及为警报相应指派的权重。该规则集合还包含阈值。规则集合对象的示例方案如下：规则集合:规则列表<警报的列表>权重列表:<权重的列表>阈值:<0和1之间的值>规则集合标识符:<uuid>规则列表是规则集合的警报列表。权重列表是以1：1关系对应于警报列表相对应的权重列表。阈值是用于确定规则集合是否是活动的阈值，在该示例中，该阈值在0和1之间(包含端点)，但在其他示例中可以是任意值。规则集合标识符是查找和区分规则集合的唯一标识符。策略控制器201或策略代理205可以通过确定规则集合规则列表中的每个警报是否活动来评估规则集合。如果警报是活动的，则将其对应的权重添加到规则列表中活动警报权重的总和中。换句话说，加权总和是规则列表中与活动警报相对应的所有权重的总和。如果加权总和大于或等于阈值，则规则集合是活动的。如果简档的规则集合中的任一个是活动的，则简档是活动的。例如，规则集合R1可以被定义为：规则集合R1:规则列表:[A1,A2,A3,A4]权重列表:[0.1,0.3,0.4,0.2]阈值:0.3规则集合对象标识符:主机1规则列表包括4个警报--A1，A2，A3和A4，每个在元件'主机1'上定义，如规则集合对象标识符所示。每个警报均被指派有权重列表中定义的权重。规则集合具有阈值0.3。情况1：在时间t1，警报A1和A3在元件'主机1'上是活动的。为了确定规则集合R1是否是活动的，策略控制器201或策略代理205确定：R1_score＝sum(A1的权重,A3的权重)＝sum(0.1,0.4)＝0.5R1_active＝(R1_score>＝阈值)＝(0.5>＝0.3)＝真因此，规则集合R1在时间t1被认为是活动的。包含规则集合R1的所有简档在时间t1也被认为是活动的。情况2：在时间t2，警报A4是元件'主机1'上唯一活动的警报。为了确定规则集合R1是否是活动的，策略控制器201或策略代理205确定：R1_score＝sum(A4的权重)＝0.2R1_active＝(R1_score>＝阈值)＝(0.2>＝0.3)＝假因此，规则集合R1在时间t2被认为是不活动的。取决于简档的其他规则集合的状态，包含规则集合R1的所有简档可能在时间t2是活动的，也可能是不活动的。在典型的云环境中，元件与一个或多个元件组(备选地被称为“父”元件)具有“成员”关系。例如，OpenStack主机可以是若干主机聚合体的成员。Kubernetes容器可以是豆荚、复制控制器、命名空间和若干不同服务的成员。作为多个组的成员的元件具有简档，该简档是在其中其是成员的所有组的简档的组合，该策略控制器201使用规则集合来实现该简档。响应于用户将元件配置为组的新成员，策略控制器201修改该元件的简档以添加在组的简档中包括的所有规则集合。添加的规则集合中的RulesetId字段包含该组的唯一标识符，并保持元件简档中不同规则集合之间的区别。因此，响应于用户将元件配置为不再是组的成员，策略控制器201能够从元件的简档中标识组的规则集合并移除所标识的规则集合。在所图示的示例中，例如，元件500A可以表示具有包括规则集合552A的元件简档550A的虚拟机“V1”：简档V1:范围:实例类型:健康对象标识符:V1规则集合:用户可以使用户设备UI设备129向策略控制器201输出配置数据，以将虚拟机V1作为成员添加到项目“P1”和聚合体“A1”。项目P1可以是类型1组，并且类型1组510A可以表示项目P1。聚合体A1可以是类型2组，并且类型2组520A可以表示聚合体A1。作为类型1组510A的项目P1具有以下类型1组简档560A，包括规则集合562A：简档P1:范围:项目类型:健康对象标识符:P1规则集合:作为类型2组520A的聚合体A1具有以下类型2组简档570A，包括规则集合572A：简档A1:范围:聚合体类型:健康对象标识符:A1规则集合:策略控制器201响应于元件500A被添加为类型1组510A和类型2组520A两者的成员，来将元件简档550A修改为附加地包括分别来自简档560A和570A的规则集合562A和572A。相应地，修改的简档550A为：简档V1:范围:实例类型:健康对象标识符:V1规则集合:策略控制器201可以将简档550A分发给策略代理205。策略控制器201或策略代理205评估规则集合552A、562A和572A的警报，并且如果规则集合552A、562A和572A中的任一个是活动的，则确定简档550A是活动的。另外，策略控制器201或策略代理205评估类型1组简档560A和类型2组简档570A的规则集合的警报以确定简档560A、570A是否也是活动的。例如，如果规则集合562A是活动的，则简档550A和560A两者均是活动的。更具体地说，如果规则集合562A的警报PA1和PA2是活动的，则类型1组简档560A以及元件500A的简档550A是活动的。类型2组简档570A至少由于规则集合562A而不是活动的，因为规则集合562A不被包括在类型2组简档570A中。添加到元件简档中的规则集合562A、572A可以包括要被应用于由元件消耗的一个或多个资源的使用度量的警报。例如，规则集合562A可以包括具有基于针对实例的cpu.usage和memory.usage的条件的警报。为评估作为虚拟机的实例的元件500A的规则集合562A时，策略控制器201或策略代理205基于由元素500A表示的虚拟机的cpu.usage和memory.usage来评估警报。这应用于作为类型1组简档560A的成员的所有元件。策略控制器201可以使用对应元件或组的使用度量来评估规则集合552A、562A、572A的警报。例如，元件500A的警报可以被配置用于基于使用度量530的评估，类型1组510A的警报可以被配置用于基于使用度量532的评估，并且类型2组520A的警报可以被配置用于基于使用度量534的评估。使用度量532可以包括由作为类型1组510A的成员的元件所消耗的资源的度量，并且度量534可以包括由作为类型2群组520A的成员的元件所消耗的资源的度量。在某些情况下，组可能只有单个元件500。用户随后可以使用户设备UI设备129向策略控制器201输出配置数据，以将作为元件500A的虚拟机V1从作为类型2组520A的聚合体A1移除。响应于从类型2组520A中移除元件500A，策略控制器201修改元件简档550A以移除类型2组520A的类型2组简档570A的规则集合572A。修改的元件简档550A是：Profile_V1:范围:实例类型:健康对象标识符:V1规则集合:策略控制器201将简档状态指示540输出到UI设备129，其可以将简档状态指示540显示给用户。策略控制器201可以使用协议通过网络输出简档状态指示540。简档状态指示可以指示活动规则集合以及导致简档变为活动的一个或多个活动警报。如上所述，度量收集的来源以及规则集合的任意给定规则的来源和警报可以是分布式的，并且可以不影响对规则集合的状态的评估。度量的阈值和值可以基于静态或动态学习的全局阈值而被警报。因此，用户可以被提供有用于表达可组成针对元件或组的简档的有用的分解规则的各种组合的灵活性。例如，由实例聚合体或项目组成的VNF池可以基于分离的元件来设置规则，以影响其服务级别。例如，策略控制器201可以接收简档已被激活的通知，并部署新的实例并将该简档应用于新的实例。因此，由于为警报提供了附加资源的附加元件，简档变为停用。针对实例聚集体的简档可以指定如果实例聚集体中的指定百分比的实例不健康，则必须基于上下文状态转换来采取动作。通过在简档结构的叶子处提供转换信息的规则集合顶部开发定制服务，可以对假警报或相关性进行调整。例如，用户可以基于简档的第一规则集合来确定简档正在激活。然而，这第一规则集合可能与性能之间的关联性很差。因此，只有在因为简档的第二规则集合是活动的导致简档状态指示指示简档是活动的时，才可以设置以简档是活动的为条件的策略来采取动作用户可以将策略代理205的插件定义为为支持VNF池的主机服务提供定制度量；其中实例被物理地运行的主机可以提供关于VNF池的状态和功能的附加信息。因此，定制服务可以基于来自规则集合的用于定制聚合体的上下文警报来执行细粒度的动作，以便全局动作可以被应用。图6是图示根据本公开的技术的用于多个元件和多种类型的组的组简档的示例简档层级的框图。元件600具有元件简档660，元件简档660包括规则集合652。元件600是类型-1组610A的成员，类型-1组610A具有包括规则集合662A的类型1组简档660A。类型1组610A是类型N组610N的成员，类型N组610N具有包括662N的类型N组简档660N。尽管仅图示了两个级别的组层级，但示例层级可以包括附加级别。由于类型1组610A直接或通过作为类型N组610N的成员的另一组中的成员资格过渡地来是类型N组610N的成员，策略控制器201修改类型1组简档660A以包括规则集合662N。因为元件600是类型1组610A的成员，所以策略控制器201修改元件简档660以包括类型1组简档660A的规则集合，其包括规则集合662A和662N。元件简档660因此包括规则集合652、662A和662N。在一些情况下，策略控制器201可以修改“中间”简档以包括来自更高级别组的规则集合。在所示示例中，在这种情况下，策略控制器201修改类型1组简档660A以包括规则集合662N和来自用于更高级别组的简档的任意其他中间规则集合。策略控制器201或策略代理205基于在规则集合652、662A和662N中包括的警报来评估简档660是否活动。例如，基于元件600或作为类型-1组610A和类型-N组610N的成员的任意其他元件的使用度量，规则集合中的任一个可以被确定为活动的。策略控制器201可以提供应用编程接口(API)，设备可以通过该API访问简档以创建、读取、更新或删除简档。例如，API可以是在指定的URI处可访问的HTTP端点，例如，用户可以以JSON或XML对象的形式向其POST、GET、PATCH或DELETEHTTP有效载荷。作为一个示例，用户可以在本地创建元件简档660并将该简档存储到设备，然后将创建的元件简档660POST到由策略控制器201服务的HTTP端点以远程创建元件简档660。以下命令执行这些操作以创建具有多个规则集合的元件简档660并将元件简档存储到策略控制器201：$curl-XPOST-H"X-Auth-Token:<token>"-H"Content-type:application/json"-d@create_profile.jsonhttp://localhost:9000/appformix/v1.0/analytics_profile以下命令执行操作以获得具有来自不同父亲的多个规则集合的现有简档：$curl-XGET-H"X-Auth-Token:<token>"http://localhost:9000/appformix/v1.0/analytics_profile/d0149212-1bae-11e7-86b4-0242ac120006一般而言，简档的API能够一次接受简档定义。然而，当用户修改其他组中对应元件或组的成员资格时，策略控制器201动态修改该简档。例如，用户可以删除2个实例并向聚合体或项目添加4个新实例。聚合体或项目的简档(更具体而言，规则集合)将被应用于4个新实例的简档并被评估。在评估用于简档的规则集合和规则列表之前，度量生成的来源、警报条件标识、以及用于动态学习基线的能力被照顾。这可以提供优于使用中央数据存储库来集中聚合度量和处理策略和成员资格的其他系统的优点，其可能需要分配大量资源以得到所需信号，该所需信号是生成使用本文描述的监测警报和简档技术提供的健康和风险所需的相同服务级别信号所需的。图7A是根据本公开中描述的技术由用户界面设备输出的、用于接收和显示简档的示例用户界面。用户界面设备129可以向显示装置输出用于向用户显示的用户界面700。本示例中的用户界面700显示具有项目类型的组的简档。用户界面元件702、704和706分别指示该简档用于监视项目的健康、具有项目级别范围、并且被命名为“管理”。所显示的简档具有在用户界面700的相应用户界面区域中指示的两个规则集合710和712。规则集合710具有两个规则710A-710B，各自规则具有对应的权重708。规则集合710具有由用户界面元件711指示的阈值。规则集合712具有一个规则712A，规则712A具有对应的权重708。规则集合712具有由用户界面元件713指示的阈值。用户界面设备129的用户与用户界面700交互以修改简档以添加、移除或修改简档的规则集合。图7B是根据本公开的技术的用户界面设备输出的用于显示简档状态指示的示例用户界面。用户界面设备129可以向显示设备输出用于向用户显示的用户界面800。用户界面800显示两个实例818A-818B的使用度量。用户界面元件820A-1-820A-6显示实例818A的使用度量，而用户界面元件820B-1-820B-6显示实例818B的使用度量。用户界面800指示项目“ADMIN”的总体健康以及项目成员实例818A-818B的健康。实例818可以被认为是元件并且由用户添加到项目的组中。该项目具有包括规则集合的相关联的简档，该规则集合具有针对资源度量cpu.usage、memory.usage、network.ingress.bit_rate、disk.io.read_bw和disk.io.write_bw中的每一个的警报。因为实例818是项目的成员，所以针对实例818A-818B的相应简档“Test1”和“Test2”各自均包括项目的规则集合，并经由用户界面元件820显示度量，至少在某些情况下实时地。另外，用户界面800显示简档是活动还是不活动的指示。在本示例中，“Test1”的健康简档和风险简档被指示为活动。“Test2”的健康简档被指示为活动，“Test2”的风险简档被指示为不活动。用户元件816显示项目的存在的(“全部”)、是活动的(“坏”)、处于风险(“风险”)以及是不活动的(“良好”)成员(在本文中为实例)的数目。这里，两个实例818均是活动的，因此存在2个“坏”或不健康的实例。图8是图示了根据本公开的技术的计算系统的示例操作模式的流程图。策略控制器201从用户界面设备129接收或以其他方式获得简档数据，简档数据定义虚拟化基础设施的元件的第一简档(850)。第一简档包括具有一个或多个警报的规则集合。策略控制器201还从用户界面设备129接收或以其他方式获得简档数据，简档数据定义针对元件组的第二简档(854)。响应于从用户界面设备129接收到配置数据，将该元件配置为组的成员(854)，策略控制器201修改第一简档以包括来自第二简档的规则集合，并且由此生成修改的第一简档(856)。策略控制器201将修改的第一简档部署到服务器126的策略代理205，服务器126将修改的第一简档(856)应用于与元件所消耗的资源相关联的使用度量(858)。策略控制器201随后从用户界面设备129接收移除作为该组的成员的元件的配置数据(860)。来自第二简档的规则集合包括简档213的规则集合中的唯一标识符。唯一标识符被包括在步骤856中被添加到第一简档的规则集合中。使用来自第二简档的规则集合中的唯一标识符并且响应于移除作为组成员的元件的该配置数据，策略控制器201标识修改的第一简档中的规则集合并移除规则集合以恢复到第一简档(862)。策略控制器201将修改的第一简档部署到服务器126的策略代理205，其将第一简档应用于与由元件消耗的资源相关联的使用度量(864)。图9A是示例网络900A的框图，其中单个集群控制器201管理服务器或计算节点126并通过面板203为集群902提供可视化。在图9A所图示的示例中，控制器201被显示为集群902的一部分。然而，在其他示例中，控制器201不是集群902的一部分，并且在这样的示例中，“集群902”是指节点而不是控制器。图9A的集群902可以表示基于云的计算网络和/或计算域或项目或其他类型的计算集群。在图9A的集群902表示云环境的情况下，这样的云环境可以是OpenStack云环境或Kubernetes云环境。集群902可以跨多个环境(例如不同的数据中心)分布。控制器201可以以结合图1和/或图2描述和图示的方式操作。例如，在一些示例中，控制器201可以与部署在一个或多个服务器126(即，主机或计算节点126)内的监视代理(图9A中未图示)交互，该监视代理用于监视在一个或多个计算节点126上实现的服务器或物理计算节点以及诸如VM或容器的任意虚拟化主机或实例的资源使用。如本文所描述，在集群902内的监视代理可以在消息总线215上诸如以利用度量的形式发布关于这种资源使用的信息。监视代理提供分布式机制以收集各种各样的使用度量以及由控制器201安装的策略的本地实施。面板203可以以结合图1、图2和/或图3描述和图示的方式来实现。如结合图1所描述的，面板203可以主要由控制器201或由在策略控制器201上执行的面板模块来被创建、更新和/或维护。如图9A所图示的，控制器201可以生成面板203，面板203可以表示用户界面的集合(例如，包括用户界面910)，其提供关于与基础设施元件相关联的拓扑、结构、层级、利用和/或度量的信息。在图9A的示例中，用户界面910中的基础设施元件表示913对应于网络900A内的基础设施元件(例如，主机、实例、项目、虚拟或物理网络设备)，并且可以布置在用户界面910内以图示网络拓扑、层级、父/子关系或其他关系或配置。另外，基础设施元件表示913中的一个或多个可以包括提供关于利用、度量、健康、条件和/或与网络900A的基础设施有关的其他状态信息的指示符(例如，颜色或其他视觉指示符)，其通过用户界面910内的基础设施元件表示913来表示。例如，在一些示例中，红色的指示符可以表示高利用率，绿色的指示符可以表示低利用率，并且不落入两者类别的指示符可以以另一种方式或以不同的颜色(例如，黄色、橙色或无颜色)来表示。在一些示例中，控制器201响应于来自用户的输入(例如，与用户界面910内的度量选择用户界面组件911的交互)，可以生成或更新面板203内的用户界面，使得基础设施元件被健康、风险、聚合、项目、网络(虚拟或物理)、类型和/或其他方式过滤。在这样的示例中，过滤器可以使得一些基础设施元件隐藏在面板203或面板203的用户界面内，同时呈现面板203内的其他基础设施元件。可以使用函数范例来应用过滤器。例如，每个过滤器可以对应于函数，使得对于给定的“x”个资源集合、元件或其他要过滤的项目以及过滤器函数“f”和“g”，过滤器的应用可以计算f(g(x))。在过滤器遵循函数范例的情况下，以不同顺序应用过滤器(例如，g(f(x)))将具有相同的结果。在一些示例中，过滤器函数中的某些或全部是纯的，以便没有函数的上下文之外的状态信息被改变。每当过滤器值(或其他用户界面组件911)被改变时，控制器201可以将适当的过滤器应用于资源哈希表中的所有资源，然后将资源阵列重新指派给结果阵列。当与用户界面组件911的交互被检测时，当一个或多个基础设施元件表示913被选择或改变时，当度量数据由控制器201接收到时和/或在其他情况下，过滤器可以被应用和/或重新应用。在一些示例中，来自监视代理的数据可以使用基于推送的模型在消息总线215上接近和/或看起来接近实时地传送到控制器201。控制器201可以在维护面板203中订阅消息总线215上可用信息的子集；并且监视代理或从监视代理收集度量的分离的模块可以推送仅指定在最后时间间隔中发生的改变的变化量(“delta”)(差异)。例如，变化量可以指定网络900A和/或集群902的配置状态的净改变，诸如给定元件的计数的增加或减少，例如主机数目的增加或减少。作为另一示例，变化量可以指定对操作状态的改变，诸如用于从一个状态转换到另一状态的集群的基础设施元件的数目，诸如从健康状况转换为风险状态或从风险状态转换为健康状况的数目。这可以减少或最小化维护面板203所需的开销，并且允许面板随着网络的大小增加而伸缩。图9B是示例网络900B的框图，其中多集群面板系统901通过面板903为管理相应基于云的网络计算集群902A至集群902N(“集群902”)的控制器201A至控制器201N(“控制器201”)提供可视化。集群902可以是分离的基于云的计算网络、计算域或项目，并且可以共同位于共同的总体计算环境中或位于不同的环境中，诸如不同的数据中心。集群902例如可以是不同的云环境，诸如OpenStack云环境、Kubernetes云环境或其他计算集群、域、网络等的各种组合。例如，策略控制器201中的每一个可以根据本文描述的示例策略控制器(诸如图1和图2的策略控制器201)来操作。例如，策略控制器201中的每一个可以是监视系统的分离软件安装的组件(诸如图2所示的示例性系统)，并且控制器201中的每一个可以是本文描述的任意策略控制器的分离实例，以便为相应集群902提供监视、调度和性能管理。控制器201中的每一个与部署在相应集群902的物理服务器中的至少一些服务器和/或其他设备内的监视代理集合(图9B中未图示)进行交互，用于监视物理计算节点以及在物理主机上实现的任意虚拟化主机或实例(例如VM或容器)的资源使用。如本文所描述的计算集群902中的每一个内的监视代理提供分布式机制，用于收集各种各样的使用度量以及用于由集群902中的每一个的相应控制器201安装的策略的本地实施。在图9B的示例中，控制器201A和控制器201C是具有用于相应集群的多个冗余控制器的高可用性(HA)控制器。控制器201B和控制器201N是单个控制器。如下面进一步描述的，多集群面板系统901可以生成、创建和/或配置面板903以提供被称为“单个玻璃板”的统一视图，其中单个用户界面屏幕呈现度量、警报、通知、报告以及与多个集群902的基础设施元件的健康有关的其他信息的接近和/或看起来接近实时的可视表示。面板903可以以类似于本文所述的其他面板(诸如面板203)的方式操作或实现，并且因此面板903可以表示呈现关于网络900B和/或一个或多个集群902的信息的用户界面的集合。面板903可以与面板203的不同之处在于面板903可以被设计或配置用于多集群部署。面板903可以包括由用户界面设备(图9B中未图示)呈现的一个或多个用户界面。如图9B所示，多集群面板系统901是软件组件或软件组件集合，其诸如通过消息总线与部署在集群902内的控制器201中的每一个进行通信，所述消息总线在一个示例中是网络套接字消息基础设施与本文所示的其他面板一样，面板903可以包括图形视图，其使用各种图、小部件、直方图或其他U/I对象来提供由实例对资源利用的快速、可视化概览。在一个示例中，多集群面板系统901被配置为与指定的主控制器关联并且跨所有底层集群902来执行监视和警报。在这样的示例中，面板系统901可以作为一个或多个控制器201上的模块(例如，类似于仪表板模块233)来操作或执行。此外，控制器201中的任一个可以是例如由管理员指定的主集群，并且控制器中的任一个可以用作用于向面板903输出度量信息用于显示的成员集群，从而潜在地使多集群面板系统901变得不必要。备选地，多集群面板系统901不需要与特定的主集群相关联，并且可以是实例化的软件组件或组件集合，并且在独立于针对被监视的基于云的计算集群(例如，云域)集合的任意特定控制器安装的处理空间内执行。在一些多集群示例中，每个其他成员集群902配置有消息传送基础设施信息，使得控制器中的每一个可以将性能和度量使用数据直接推送到计算设备或管理面板903的模块，其进而绘制用于呈现信息的用户界面。作为一个示例，作为指定主控制器的控制器201A实例化管理多集群面板903的模块，并使用来自主控制器的配置信息来打开到成员集群集群902B到集群902N中每一个的websocket句柄，从而形成用于将性能和使用数据从控制器中的每一个传送到管理多集群面板903的模块的消息总线。在一个示例中，多集群面板903(即其中的用户界面)在单个玻璃板中显示所有成员集群的信息，包括每个相应集群的总体性能、健康和状态信息。在示例实现中，在该单个可视化中针对集群中的每一个显示资源(例如，主机、项目、实例)的健康、风险和计数。这样，在第一眼，用户可以查看和确定所有集群902的状态，并且针对更详细的信息可以确定集群中的哪一个更深入地进入其当前的健康和风险评估。需要关注的任意集群(例如具有不健康或处于风险中的资源的那些集群)都可以过滤到视图顶部。在一个示例性实现中，所有数据可以使用基于推送的模型接近和/或看起来接近实时地从控制器201被提供给多集群面板系统901。多集群面板系统901加入用于集群902中的每一个的相应的消息总线215A至消息总线215N(“消息总线215”)，并且集群902的控制器201中的每一个可以推送仅指定已在最后时间间隔中发生的改变的变化量(差异)。例如，变化量可以指定配置状态的净改变，诸如给定元件的计数中的增加或减少，例如主机数目的增加或减少。作为另一示例，变化量可以指定对操作状态的改变，诸如用于从一个状态转换到另一状态的集群的基础设施元件的数目，诸如从健康状况转换到风险状态或从风险状态转换到健康状况的数目。这可以减少或最小化面板系统901上的开销和/或用于维持面板903所需的开销，从而使面板能够随着集群数目的增加而伸缩。例如，假设集群C1具有N个资源，其中在时间间隔t1，k个处于健康状况并且m个处于不健康状况。在时间间隔t2，集群C1可以处于不同的状态，例如N'个资源，k'个是健康的并且m'个是不健康的。在该示例中，面板903将仅接收差异传送，差异传送指示N'-N资源被添加或删除，k-k'良好，并且m-m'不健康。这样，需要通过消息总线传送到多集群面板903的数据量可以显著减少，因为类似的信息不会在每个时间间隔中重复。由于这种多集群视图中的资源数目可能非常巨大，因此此方案可以提供显著的性能益处。在一个示例性实现中，多集群面板系统901和面板903上的数据使用负担通过以下被附加地减少或最小化：配置多集群面板系统901和/或面板903，来维护和输出仅用于显示每个受监视元件组中的总共元件的整数计数，连同针对具有差健康的元件组和处于危险中的元件的指示符(例如，颜色或图形控件)。如此，数据对象，多集群面板不需要消耗存储器和计算资源，导致针对多集群面板系统901和面板903的减少的时间和资源消耗。尽管消息总线215在图9B中的集群902中的每一个外部图示，但是在其他示例中，消息总线215中的每一个可以在控制器201内部实现(例如，如图9A所示)。在这样的示例中，多集群面板系统901可以诸如通过适当的API被提供对消息总线215中的每一个的访问。图10图示了根据本公开的一个或多个方面的用于多集群面板系统901的在计算设备上呈现的示例用户界面1020。通常，用户界面1020可基于由多集群面板系统901提供的输出而被绘制在用户界面设备上。面板1004可查看被视为在具有关联数据和/或可执行软件指令的存储器中实例化的软件对象，其提供输出数据用于在显示器上绘制。虽然用户界面1020被显示为图形用户界面，但是其他类型的界面可以由用户界面设备呈现，包括基于文本的用户界面、控制台或基于命令的用户界面、语音提示用户界面、或任意其他适当的界面用户界面。在图10所示的示例中，并且根据本公开的一个或多个方面，用户界面1020包括主显示区域1021，其包括四个图形集群区域1022A-1022D，其中的每一个对应于不同的计算集群1008。如图所示，用户界面的每个集群区域1022显示多个图形块，块1024中的每一个呈现对应的计算集群1008被监视的每个元件组内的元件的数目的计数。在该示例中，多集群面板系统901与不同OpenStack安装的多个集群相关联，并且用户界面120的每个集群区域1022包括八个图形图块，其显示用于集群的用户指定的OpenStack元件的计数。在此OpenStack示例中，受监视的OpenStack元件包括用于OpenStack云中的身份管理的Keystone服务，用于网络管理的Neutron服务，用于虚拟机管理的Nova服务，用于对应计算集群的警报、聚合体、主机、项目和实例。对于每个定义的元件组，对应的图形图块列出了在该颜色内被监视的该类型的元件的数目的整数计数。诸如块的颜色(例如绿色或红色)的指示符提供关于为元件组定义的对应SLA是否正在被满足的指示。在此示例中，鉴于收集的性能数据，基于它们的SLA要求，在集群1022B内表示的四种类型的OpenSource元件是健康的，而五种类型的OpenSource元件(警报、聚合体、主机、项目和接口)被观察并报告为不健康。在一个示例中，用户界面1020包括允许用户在多个不同模式和对应用户界面之间进行选择的边栏1023。在该示例中，边栏1023示出了用户已经选择“集群”模式1025，导致多集群面板系统901在显示区域1021上绘制多集群视图。图11图示了根据本公开的一个或多个方面的由用于多集群面板系统901的计算设备输出的示例用户界面1030。在图11所示的示例中，用户界面1030有两个四个图形集群区域1032A-1032B，其中每个图形集群区域对应于不同的计算集群1008。在该示例中，针对两个不同Kubernetes云安装，集群中的每一个对应于监视、策略分发和本文描述的控制框架的不同安装。这样，多集群面板系统901的示例用户界面1030图示了由相应控制器针对集群监视的Kubernetes元件类型集合。图12图示了由多集群面板系统901输出的示例用户界面1040，用于接收和处理来自管理员的输入，以将集群配置为在多集群面板上显示。将集群添加到主集群可以通过调整多集群面板上的设置来完成。在一个示例中，管理员与用户界面1040交互以提供用于控制器1006(图9)的控制器主机IP和端口以及用户名和密码或管理员的其他安全凭证被添加到面板。在图12的示例中，管理员已经配置了多集群面板以包括两个成员集群1042A和1042B。在这个示例中，集群1042A被命名为“ace99”并且与控制器“ace99”相关联，并且集群1042B被命名为“minig”并且与位于具有网络地址10.87.28.202的主机的控制器相关联。如图13所示，一旦通过设置页面添加了集群1006，多集群面板系统901处理该输入以构建并输出针对所添加集群的对应图形集群区域1052。图13图示了响应于图12中所示的示例配置，由多集群面板系统901呈现的示例用户界面1042。在一个示例实现中，多集群面板系统901使得用户能够容易地从多集群视图导航到任意个体集群而无需附加的登录认证。此外，用户可以进一步钻入单个集群内正被监视的元件，以对集群内定义的任意元件(实例对象)(诸如被监视的特定元件)的度量、警报和报告进行可视化，从而查看实时制图和针对该实例的数据。对于任意元件，用户能够查看资源利用率、度量、健康状况、SLA简档等。类似地，用户可以移回面板层级并深入到不同集群的元件利用，其中多集群视图为不同的云安装提供顶级可视化。这可以有利地提供无缝的用户体验，因为用户可以在不同的集群之间切换，而不需要必须刷新或再次登录。例如，基于由多集群面板系统901呈现的用户界面104，管理员可以确定集群(“minig”)中的一个具有处于风险或否则处于差健康的一些资源。这样，管理员可以例如通过点击图形集群区域1052A来提供输入以选择“minig”集群以有效地向下钻入minig集群。作为响应，如图14所示，多集群面板系统901更新用户界面以通知管理员其正在将视图从多集群视图切换到期望的集群(在该示例中的“minig”集群)。此时，多集群面板系统901在单个集群视图中操作并且基于目标集群内的策略控制器所监视的元件来更新其数据。换句话说，多集群面板系统901的内部数据结构被创建并且利用相应策略控制器针对目标集群维护的全部资源计数和SLA信息来刷新，并且新的用户界面被绘制并输出用于向用户显示。这些改变可以实时显示，而无需由用户的任意手动刷新或认证。此时，多集群面板系统901在单个集群视图中操作，并且被配置为开始收听新集群的消息总线，使得新的性能数据可以被接收并反映在面板中。图15图示了当在单个集群视图中操作时由多集群面板系统901生成并输出的示例用户界面1060。如图15所示，多集群面板系统901已从多集群视图切换到针对面板的单个面板视图1053，其中显示区域1021呈现单个期望集群的基础设施的整个使用度量、监视和性能数据。这允许管理员可以容易地查看并标识哪些特定元件针对该集群被影响。此外，如果管理员希望钻取(切换)回到集群视图，管理员可以选择边栏中的集群菜单项以返回到多集群视图。以这种方式，在这个特定示例中，多集群面板系统901使得用户能够容易地从多集群视图导航到任意个体集群并返回到多集群视图，而不需要为每个集群提供附加的登录认证，即使集群可能是不同的域或云环境。如上所述，用户可以用他或她的针对主集群的凭证来登录主集群面板，其由主控集群的控制器认证。当配置多集群面板以添加附加的成员集群时，已向主集群进行认证的用户的凭证将提供给正在添加的集群的认证组件，该集群生成并返回具有期满日期的集群特定安全令牌。主集群控制器构建可由集群ID索引的散列映射来存储安全令牌，用于在穿越面板时用户的后续无缝认证。例如，在如上面的示例中所讨论的，在用户正在查看多集群面板并且想钻入个体集群中的事件中，多集群视图面板系统901利用所选(目标)集群ID经由API来调用安全导向器软件组件(“cluster_token”)。此安全主导软件组件作为安全代理的形式运行，以从哈希表访问存储的凭证和所选集群的配置，以取回安全令牌，然后使用安全令牌查询控制器用于要被查看的集群，以从期望集群加载数据。通过这种方式，集群中的每一个的安全主导和后端认证软件组件都可以在用户遍历多个集群并在多集群视图和单个集群视图之间切换视图时处理集群认证，在单个集群视图中任意成员集群的详细性能和监视数据可以被检查。这可以有利地提供无缝的用户体验，因为用户可以在不需要刷新或再次登录的情况下在不同的个体集群和多集群视图之间切换。作为示例，假设多个集群C1、C2、C3已经被添加到多集群面板并且分别配置有用户名u1、u2、u3和密码p1、p2、p3。设C1为主集群。通常，管理员将登录到主集群中，使得面板1004将具有针对集群C1的经认证的安全令牌T1。通常，安全目录软件组件(cluster_tokenAPI)被配置为接受目标集群的令牌T1和clusterID作为输入，并用指定集群的安全令牌进行响应。例如，让针对C2和C3的令牌为通过安全主导API获取的T2、T3。然后，这些令牌用于获取集群中的每一个的更多详细信息。在一个示例中，面板1004通过在面板的处理空间内实例化的软件对象来表示每个集群，并且每个集群对象被clusterId键查找(访问)，clusterId可以是整数、指针、索引等。在这个示例中，每个集群对象包含面板1004已经接收到以显示在视图上的全部必要的数据。标识针对集群被监视的子资源的信息可以存储在由面板1004为集群创建的父对象内的相应数据结构中。在一个示例中，集群的所有个体安全令牌(T1-T3)与过期时间戳一起存储在哈希表中。主令牌T1也可以临时高速缓存在用户的浏览器本地存储装置上。当集群被选择时，多集群面板系统901可执行以下：1.确定选定的集群是否是当前集群。如果是，什么都不要做。否则，前进到步骤2。2.如果安全令牌已经存在于令牌哈希表中并且安全令牌未过期，则多集群面板系统901使用该令牌来请求、接收和更新具有该集群资源的面板。否则，前进到步骤3。3.如果安全令牌不存在，则多集群面板系统901使用主令牌进行API调用以提供必要的凭证以从所选集群接收安全令牌。这个新令牌将被添加到由多集群面板系统901维护的令牌哈希表中。如果对于所选集群存在任意先前令牌，则该令牌将被覆盖。然后程序再次执行第2步。图16是图示了本文描述的多集群面板的示例操作的流程图。如所描述的，策略代理(例如，策略代理205)被部署用于在多个不同的基于云的计算集群内的计算节点上执行，其中策略代理中的每一个监视与计算集群(例如，不同的云域或环境)中的每一个内的计算节点的资源相关的性能和使用度量(1200)。与相应计算集群一起操作的多个策略控制器(例如，策略控制器201)中的每一个从在相应计算集群的计算节点上执行的策略代理接收集群内虚拟化基础设施的性能和使用度量(1210)。作为响应，策略控制器中的每一个通过针对相应计算集群的基础设施元件的一个或多个规则集合(例如，策略202)的应用来评估相应计算集群的性能和使用度量(1220)，并将数据输出到多集群面板(例如，面板1004)，其中该数据指示该基础设施元件的当前健康状况并且是基于该集群的性能和使用度量的评估(1230)。多集群面板构造并输出例如供UI设备129显示的用户界面屏幕，其为基于云的计算集群中的每一个提供当前健康状况，从而提供不同的基于云的计算集群的统一视图，即使多个策略控制器可以用于不同的云域/环境(1240)。另外，多集群面板可以基于推送到多集群面板的数据来应用规则集合和触发服务，所述数据指示每个集群内的资源的健康和状态信息，从而通过多个不同的基于云的安装容易地提供自动策略控制(1250)。本文描述的技术可以提供附加的优点。例如，组织的定制服务可以在多集群环境中的主集群控制器上被定义和实现，以便利用和应用经由消息总线从多个集群接收到的分布式通知中的多集群规则。例如，定制服务可以通过规则定义和触发，以基于由一个或多个个体集群检测到并报告的SLA违规来自动地将虚拟机从一个云安装移动到另一云安装。此外，服务可由规则集合来触发，规则集合由主控制器应用于推送到多集群面板的变化量数据，其指示每个集群内的资源的健康和状态信息。此外，被触发的服务可以利用主令牌和令牌的认证哈希表来无缝地执行服务，而无需在受影响的集群中的每一个处要求重新认证。作为本文描述的技术的潜在优点的另一示例，管理员可以利用多集群面板系统901和主集群控制器来容易地配置费率计费返还服务并配置该服务以基于推送通知和多集群面板接收的关于跨多个云安装的使用度量的变化量来将特定的计费返还费计划应用于客户。作为本文描述的技术的潜在优点的另一示例，管理员可以利用多集群面板系统901并且配置主控制器以基于推送通知和由集群面板接收到的关于跨多个云安装的使用度量的变化量来进行动态容量规划和推荐。对于包括在任意流程图表或流程图中的本文中所描述的进程、装置和其他示例或图示，本文所描述的任意技术中包括的某些操作、动作、步骤或事件可以以不同的顺序执行，可以被添加、合并或完全忽略(例如，并非所有描述的动作或事件对于技术的实践都是必需的)。此外，在某些示例中，操作、动作、步骤或事件可以例如通过多线程处理、中断处理或多个处理器同时地而不是顺序地执行。进一步的某些操作动作、步骤或事件可以自动执行，即使没有明确标识为自动地执行。另外，被描述为自动地执行的某些操作、动作、步骤或事件可以备选地不被自动地执行，而是在某些示例中，这样的操作、动作、步骤或事件可以响应于输入或另一事件而被执行。在一个或多个示例中，所描述的功能可以以硬件、软件、固件或其任意组合来实现。如果以软件实现，则功能可以作为一个或多个指令或代码存储在计算机可读介质上和/或通过计算机可读介质进行发送并且由基于硬件的处理单元执行。计算机可读介质可包括：对应于诸如数据存储介质的有形介质的计算机可读存储介质、或包含促进将计算机程序从一处传送到另一处(例如，依照通信协议)的任意介质的通信介质。以此方式，计算机可读介质可对应于(1)非暂时性的有形计算机可读存储介质或(2)诸如信号或载波的通信介质。数据存储介质可以是可由一个或多个计算机或一个或多个处理器访问以取回用于实现本公开中描述的技术的指令、代码和/或数据结构的任意可用介质。计算机程序产品可以包括计算机可读介质。作为示例而非限制，这样的计算机可读存储介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储器、磁盘存储器或其它磁存储设备、闪存或可用于以指令或数据结构的形式存储期望的程序代码并可由计算机访问的任意其他介质。此外，任意连接都被适当地称为计算机可读介质。例如，如果指令使用同轴电缆、光纤电缆、双绞线、数字用户线路(DSL)或诸如红外线、无线电和微波的无线技术从网站、服务器或其他远程源发送，则同轴电缆、光纤电缆、双绞线、DSL或诸如红外、无线电和微波的无线技术都包括在介质的定义中。然而，应当理解的是，计算机可读存储介质和数据存储介质不包括连接、载波、信号或其它瞬态介质，而是代之以针对非瞬态有形存储介质。如使用的磁盘和光盘包括光盘(CD)、激光光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光光盘，其中磁盘通常以磁性方式再现数据，而光盘通过激光以光学方式再现数据。上述的组合也应当包括在计算机可读介质的范围内。指令可以由诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程逻辑阵列(FPGA)或其他等同的集成或离散逻辑电路的一个或多个处理器执行。因此，本文使用的术语“处理器”或“处理电路”可以各自指代任意前述结构或适于所描述的技术的实现的任意其他结构。另外，在一些示例中，所描述的功能可以在专用硬件和/或软件模块内提供。此外，这些技术可以完全在一个或多个电路或逻辑元件中实现。本公开的技术可以在各种各样的设备或装置中实现，包括无线手机、移动或非移动计算设备、可穿戴或不可穿戴计算设备、集成电路(IC)或IC(例如芯片组)集合。在本公开中描述了各种组件、模块或单元以强调被配置为执行所公开的技术的设备的功能方面，但是不一定需要通过不同的硬件单元来实现。相反，如上所述，各种单元可以组合在硬件单元中或者通过包括如上所述的一个或多个处理器的互操作硬件单元的集合结合合适的软件和/或固件来提供。当前第1页1 2 3 当前第1页1 2 3