CN115865942A - 云平台资源监控方法、电子设备、计算机可读存储介质 - Google Patents

Abstract

本申请涉及云计算技术领域，尤其是涉及一种云平台资源监控方法、电子设备、计算机可读存储介质。本申请实施例的云平台资源监控方法，应用于云平台系统，需要先获取与云平台系统对应的云系统层级模型，云系统层级模型包括算力资源层、资源编排层以及应用资源层，进一步，对算力资源层进行算力指标检测，得到算力资源指标，对资源编排层进行编排指标检测，得到资源编排指标，对应用资源层进行应用指标检测，得到应用资源指标，再进一步，基于算力资源指标、资源编排指标与应用资源指标，生成资源监控信息，能够分别检测监控算力资源层、资源编排层以及应用资源层的资源动向，从而能够根据资源监控信息进一步监控应用程序在云平台的资源使用情况。

Description

云平台资源监控方法、电子设备、计算机可读存储介质

技术领域

本申请涉及云计算技术领域，尤其是涉及一种云平台资源监控方法、电子设备、计算机可读存储介质。

背景技术

Kubernetes(K8S)是为容器服务而生的一种可移植容器的编排管理技术。Kubernetes在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列功能。近来，越来越多的应用程序从主机平台移植到云平台，并通过云平台来实现资源抽象与资源管理，然而云平台架构区别于主机平台架构，主机平台架构主要是基于主机中的处理器利用本地资源来支持应用的运行，而云平台架构则是基于底层的分布式集群服务器来提供算力，进一步通过云操作系统，对应用程序所需的资源进行集群管理、调度优化等操作。需要明确，将应用程序移植到云平台之后，如何监控应用程序在云平台的资源使用情况，成为业内亟待解决的一个问题。

发明内容

本申请旨在至少解决现有技术中存在的技术问题之一。为此，本申请提出一种云平台资源监控方法、电子设备、计算机可读存储介质，能够监控应用程序在云平台的资源使用情况。

根据本申请的第一方面实施例的云平台资源监控方法，应用于云平台系统，所述方法包括：

获取与所述云平台系统对应的云系统层级模型，所述云系统层级模型包括算力资源层、资源编排层以及应用资源层，其中，所述算力资源层用于为所述云平台系统提供算力资源、所述资源编排层用于编排所述算力资源层提供的算力资源，所述应用资源层用于为所述云平台系统上的应用程序提供可调配资源；

对所述算力资源层进行算力指标检测，得到算力资源指标；

对所述资源编排层进行编排指标检测，得到资源编排指标；

对所述应用资源层进行应用指标检测，得到应用资源指标；

基于所述算力资源指标、所述资源编排指标与所述应用资源指标，生成资源监控信息。

根据本申请的一些实施例，所述算力资源层包括多个资源负载节点，所述算力资源指标包括算力限制指标，所述对所述算力资源层进行算力指标检测，得到算力资源指标，包括：

对多个所述资源负载节点进行集群划分处理，得到算力资源池；

基于所述算力资源池进行第一压力测试，得到所述算力限制指标。

根据本申请的一些实施例，所述基于所述算力资源池进行第一压力测试，得到所述算力限制指标，包括：

基于预设的异常模拟信息，从各个所述算力资源池的所述资源负载节点中确定正常模拟节点与异常模拟节点；

对各个所述算力资源池的所述异常模拟节点进行失效处理；

基于所述正常模拟节点以及失效处理后的所述异常模拟节点，进行第一压力测试，得到所述算力限制指标。

根据本申请的一些实施例，所述基于所述算力资源池进行第一压力测试，得到所述算力限制指标，包括：

获取与多个所述应用程序一一对应的应用标签信息，所述应用标签信息用于反映所述应用程序的资源消耗特征；

基于各个所述应用标签信息对所述算力资源池进行第一压力测试，得到所述算力限制指标。

根据本申请的一些实施例，所述基于各个所述应用标签信息对所述算力资源池进行第一压力测试，得到所述算力限制指标，包括：

基于各个所述应用标签信息，确定各个所述应用程序的消耗峰值时段；

基于所述消耗峰值时段处于同一预设区间内的各个所述应用程序，对所述算力资源池进行第一压力测试，得到所述算力限制指标。

根据本申请的一些实施例，所述资源编排层包括资源调配服务器，所述对所述资源编排层进行编排指标检测，得到资源编排指标，包括：

对所述资源调配服务器执行多次模拟请求操作，以获取与多次所述模拟请求操作一一对应的多个响应测试信息；

基于多个所述响应测试信息，确定所述资源调配服务器的响应上限信息；

基于所述响应上限信息，得到编排限制指标；

根据所述编排限制指标，得到资源编排指标。

根据本申请的一些实施例，所述资源编排层还包括数据存储单元，所述数据存储单元用于为所述资源调配服务器提供存储功能，所述根据所述编排限制指标，得到资源编排指标，包括：

对所述资源编排层的数据存储单元进行存储指标检测，得到编排实测指标；

基于预设的监控权重对所述编排限制指标与所述编排实测指标进行整合，得到所述资源编排指标，所述监控权重中所述编排实测指标的占比高于所述编排限制指标的占比。

根据本申请的一些实施例，对所述应用资源层进行应用指标检测，得到应用资源指标，包括：

获取与所述应用资源层对应的应用日志信息；

根据所述应用日志信息，得到资源告警信息与调度障碍信息；

根据所述资源告警信息与所述调度障碍信息，确定应用资源指标。

第二方面，本申请实施例提供了一种电子设备，包括：存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如本申请第一方面实施例中任意一项所述的云平台资源监控方法。

第三方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行实现如本申请第一方面实施例中任意一项所述的云平台资源监控方法。

根据本申请实施例的云平台资源监控方法、电子设备、计算机可读存储介质，至少具有如下有益效果：

本申请实施例的云平台资源监控方法，应用于云平台系统，需要先获取与云平台系统对应的云系统层级模型，而云系统层级模型包括算力资源层、资源编排层以及应用资源层，其中，算力资源层用于为云平台系统提供算力资源、资源编排层用于编排算力资源层提供的算力资源，应用资源层用于为云平台系统上的应用程序提供可调配资源，进一步，对算力资源层进行算力指标检测，得到算力资源指标，对资源编排层进行编排指标检测，得到资源编排指标，对应用资源层进行应用指标检测，得到应用资源指标，再进一步，基于算力资源指标、资源编排指标与应用资源指标，生成资源监控信息。基于算力资源指标、资源编排指标与应用资源指标，能够分别检测监控算力资源层、资源编排层以及应用资源层的资源动向，从而能够根据资源监控信息进一步监控应用程序在云平台的资源使用情况。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例提供的云平台资源监控方法流程示意图；

图2为本申请实施例图1中步骤S102的流程示意图；

图3为本申请实施例图2中步骤S202的流程示意图；

图4为本申请实施例图2中步骤S202的另一流程示意图；

图5为本申请实施例图4中步骤S402的流程示意图；

图6为本申请实施例图1中步骤S103的流程示意图；

图7为本申请实施例图6中步骤S604的流程示意图；

图8为本申请实施例图1中步骤S104的流程示意图；

图9是本申请实施例提供的电子设备的硬件结构示意图。

具体实施方式

下面详细描述本申请的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。

在本申请的描述中，若干的含义是一个或者多个，多个的含义是两个以上，大于、小于、超过等理解为不包括本数，以上、以下、以内等理解为包括本数。如果有描述到第一、第二只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示意性实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。本申请的描述中，需要说明的是，除非另有明确的限定，设置、安装、连接等词语应做广义理解，所属技术领域技术人员可以结合技术方案的具体内容合理确定上述词语在本申请中的具体含义。另外，下文中对于具体步骤的标识并不代表对于步骤顺序与执行逻辑的限定，各个步骤之间的执行顺序与执行逻辑应参照实施例所表述的内容进行理解与推定。

Kubernetes(K8S)是为容器服务而生的一种可移植容器的编排管理技术。Kubernetes在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列功能。近来，越来越多的应用程序从主机平台移植到Kubernetes平台，并通过Kubernetes平台来实现资源抽象与资源管理，然而Kubernetes平台架构区别于主机平台架构，主机平台架构主要是基于主机中的处理器利用本地资源来支持应用的运行，而Kubernetes平台架构则是基于底层的分布式集群服务器来提供算力，进一步通过Kubernetes操作系统，对应用程序所需的资源进行集群管理、调度优化等操作。需要明确，将应用程序移植到Kubernetes平台之后，如何监控应用程序在Kubernetes平台的资源使用情况，成为业内亟待解决的一个问题。

本申请旨在至少解决现有技术中存在的技术问题之一。为此，本申请提出一种云平台资源监控方法、电子设备、计算机可读存储介质，能够监控应用程序在云平台的资源使用情况。

根据本申请的第一方面实施例的云平台资源监控方法，应用于云平台系统，一些较为具体的实施例中，云平台资源监控方法主要应用于监控Kubernetes云平台系统的资源使用情况。

图1是本申请实施例提供的云平台资源监控方法的一个可选的流程图，图1中的方法可以包括但不限于包括步骤S101至步骤S105。

步骤S101，获取与云平台系统对应的云系统层级模型，云系统层级模型包括算力资源层、资源编排层以及应用资源层，其中，算力资源层用于为云平台系统提供算力资源、资源编排层用于编排算力资源层提供的算力资源，应用资源层用于为云平台系统上的应用程序提供可调配资源；

步骤S102，对算力资源层进行算力指标检测，得到算力资源指标；

步骤S103，对资源编排层进行编排指标检测，得到资源编排指标；

步骤S104，对应用资源层进行应用指标检测，得到应用资源指标；

步骤S105，基于算力资源指标、资源编排指标与应用资源指标，生成资源监控信息。

上述步骤S101至步骤S105示出的本申请实施例中，需要先获取与云平台系统对应的云系统层级模型，而云系统层级模型包括算力资源层、资源编排层以及应用资源层，其中，算力资源层用于为云平台系统提供算力资源、资源编排层用于编排算力资源层提供的算力资源，应用资源层用于为云平台系统上的应用程序提供可调配资源，进一步，对算力资源层进行算力指标检测，得到算力资源指标，对资源编排层进行编排指标检测，得到资源编排指标，对应用资源层进行应用指标检测，得到应用资源指标，再进一步，基于算力资源指标、资源编排指标与应用资源指标，生成资源监控信息。基于算力资源指标、资源编排指标与应用资源指标，能够分别检测监控算力资源层、资源编排层以及应用资源层的资源动向，从而能够根据资源监控信息进一步监控应用程序在云平台的资源使用情况。

本申请一些实施例的步骤S101中，需要先获取与云平台系统对应的云系统层级模型，云系统层级模型包括算力资源层、资源编排层以及应用资源层，其中，算力资源层用于为云平台系统提供算力资源、资源编排层用于编排算力资源层提供的算力资源，应用资源层用于为云平台系统上的应用程序提供可调配资源。需要说明的是，云平台系统(例如Kubernetes云平台系统)中的算力资源主要是由多个算力服务器(例如Kubernetes云平台系统中为Master节点与Node节点对应的服务器)提供，诸多计算节点所提供的算力资源被抽象出来进行汇总之后，进一步经由资源管理服务器(例如的Kubernetes云平台系统AP IServer)对各类资源对象的增添、删除、修改、查看以及调用各类资源接口，以实现将算力资源进行合理编排，再进一步分配至各个由云平台系统承载的应用程序，从而支持各类应用程序的运行。因此，为了对云平台系统中的算力资源使用情况进行监控，本申请一些示例性的实施例中依照云平台系统资源使用的架构特点，将云平台系统进行划分，从而获取到与云平台系统对应的云系统层级模型，云系统层级模型包括算力资源层、资源编排层以及应用资源层。其中，算力资源层包括多个算力服务器，用于为云平台系统提供算力资源；资源编排层包括资源管理服务器，用于编排算力资源层提供的算力资源；应用资源层可以包括资源控制器与资源调度器，用于为云平台系统上的应用程序提供可调配资源。需要明确，获取云系统层级模型的方式多种多样，可以是从数据库中调用获取云系统层级模型，也可以是直接针对云平台系统的架构特点进行划分而获取云系统层级模型，还可以是其他获取方式。应理解，在云系统层级模型的基础上，本申请实施例得以针对模型中各层级的特点来测定能够反映资源使用情况的各类指标，从而实现对云平台系统资源使用情况的监控。

本申请一些实施例的步骤S102中，对算力资源层进行算力指标检测，得到算力资源指标。需要强调的是，算力资源层包括多个算力服务器，用于为云平台系统提供算力资源。本申请一些实施例中，各个算力服务器基于其输入接口、输出接口、中央处理器以及内存容量来实现对云平台系统算力资源的供应。为了监控算力资源层的资源使用情况，需要对算力资源层进行算力指标检测，得到算力资源指标。需要明确的是，算力资源层中算力资源指标的类型多种多样，可以包括，但不限于：反映算力资源层算力供应能力的算力限制指标、反映算力资源层当前算力使用情况的算力实测指标。其中，算力限制指标可以通过在对云平台系统进行压力测试的过程中测定，而算力实测指标则可以通过对各个算力服务器的I/O接口数据传输速度、中央处理器使用率、内存容量大小以及数据吞吐量等各种各样的指标进行检测而获取。

在一些较为具体的实施例中，Kubernetes云平台系统中的算力服务器主要为Master节点与Node节点提供算力资源，其中Master节点指的是集群控制节点，每个Kubenetes集群里需要有一个Master节点来负责整个集群的管理和控制，基本上Kubenetes所有的控制命令都会发给Master节点，再进一步由Master节点来负责具体的执行过程，基于Master节点的重要性，Master节点通常会占据一个独立的X86服务器(或者一个虚拟机)。Master节点上运行的进程可以包括，但不限于：其一，Kubenetes API Server，用于提供HTTP Rest接口的关键服务进程，是Kubenetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程；其二，Kubenetes Contro l l er Manager,Kubenetes里所有资源对象的自动化控制中心；其三，Kubenetes Schedu l er，负责资源调度的进程。除了Master节点，Kubenetes集群中的其他算力服务器被称为Node节点，Node节点可以是一台物理主机，也可以是二台虚拟机。Node节点是Kubenetes集群中的工作负载节点，每个Node节点都会被Master节点分配一些工作负载(工作负载指的是容器,例如:Docker)，当某个Node节点宕机时，其上的工作负载会被Master节点自动转移到其他节点上去。Node节点上运行的进程可以包括，但不限于：Kube l et，负责Pod对应的容器的创建、启停等任务，同时与Master节点密切协作，实现集群管理的基本功能；Kube-proxy，实现Kubenetes通信与负载均衡机制的重要组件；Docker Engi ne(Docker引擎)，负责本机的容器创建和管理工作。

参照图2，根据本申请一些实施例的云平台资源监控方法，算力资源层包括多个资源负载节点，算力资源指标包括算力限制指标，对算力资源层进行算力指标检测，得到算力资源指标，步骤S102可以包括但不限于下述步骤S201至步骤S202。

步骤S201，对多个资源负载节点进行集群划分处理，得到算力资源池；

步骤S202，基于算力资源池进行第一压力测试，得到算力限制指标。

在一些实施例的步骤S201中，需要先对多个资源负载节点进行集群划分处理，得到算力资源池。本申请一些示例性的实施例中，算力资源层包括多个算力服务器，其中一些算力服务器作为资源控制节点，用于为资源编排层中编排资源的组件提供算力基础，而另一些算力服务器则作为资源负载节点主要承担应用程序所需要的工作负载。需要指出，反映算力资源层资源占用情况的算力资源指标可以包括算力实测指标与算力限制指标，其中，算力实测指标即为实际测得的算力指标，包括但不限于中央处理器利用率、内存容量、数据吞吐量、数据传输速率等指标的实测值；而算力限制指标值得是反映算力资源层负荷上限的指标，需要指出，通过对算力资源层进行第一压力测试，模拟出算力资源层的负荷边界情形，即可测定反映算力资源层负荷上限的算力限制指标。

应理解，算力资源池是一种集成算力资源的虚拟资源池，虚拟资源池作为实现融合基础设施结构的关键要素，是共享服务器、存储和网络的集合，能够根据应用程序的要求更快地进行重新配置，从而能够更容易、更快捷地支持业务需求的变化。在云计算环境下，资源不再是分散的硬件，而是将物理服务器经过整合之后，形成一个或多个逻辑上的虚拟资源池，共享包括计算、存储、网络资源。资源池可以委派对主机(或群集)资源的控制权，在使用资源池划分群集内的所有资源时，其优势非常明显。可以创建多个资源池作为主机或群集的直接子级，并对它们进行配置。然后可向其他个人或组织委派对资源池的控制权。需要明确，对多个资源负载节点进行集群划分处理，得到算力资源池，有以下优点：其一，根据需要添加、移除或重组资源池，或者更改资源分配，能够使得资源池之间相互隔离，资源池内部相互共享，得以形成灵活的层次结构组织，各个算力资源池形成了层次结构组织之后，某资源池内部的资源分配变化不会对其他不相关的资源池造成影响；其二，可以参照当前的份额、预留和限制设置等因素，向该资源池授予的资源范围内进行所有的虚拟机创建和管理操作，方便资源管理；其三，资源与硬件的分离，如果使用的是已启用动态资源调度(DRS，Dynamic Resource Schedu l)的群集，则所有主机的资源始终会分配给群集，这意味着系统能够实现独立于提供资源的实际主机来进行资源管理，举例而言，若将三台2GB主机替换为两台3GB主机，系统中无需对资源分配进行更改，资源与硬件的分离的特点可更多地聚合计算能力而无需关注各个主机的使用状况。基于上述三方面原因，在编排算力资源之前，往往需要先划分算力资源池再针对多个资源负载节点的算力资源进行抽象与汇总。因此，本申请一些实施例中为了更好地模拟上述情形，对算力资源层进行第一压力测试之前，需要预先对多个资源负载节点进行集群划分处理，得到算力资源池，然后再进一步基于算力资源池进行第一压力测试，从而模拟出算力资源层的负荷边界情形。

在一些实施例的步骤S202中，基于算力资源池进行第一压力测试，得到算力限制指标。需要明确，第一压力测试用于模拟算力资源层的负荷边界情形，在第一压力测试的过程中针对算力资源层的各项指标进行测定，即可得到算力限制指标。需要指出，第一压力测试可以通过压力测试工具或者利用预先编写好的程序、脚本等方式来实现，其中第一压力测试模拟的负荷边界情形可以包括，但不限于：若干资源负载节点发生异常、算力资源池处于极限负荷等特定的负荷情形，针对每一种负荷边界情形，可以测定由中央处理器利用率、内存容量、数据吞吐量、数据传输速率等指标所构成的指标数据组，从而将指标数据组确定为算力限制指标。应理解，基于算力资源池进行第一压力测试，得到算力限制指标的方式多种多样，可以包括，但不限于上述举出的具体实施例。

经由上述步骤S201至步骤S202，在对多个资源负载节点进行集群划分处理，得到算力资源池之后，再基于算力资源池进行第一压力测试，得到算力限制指标，能够模拟出实际使用场景下，算力资源层的负荷边界情形，从而得到更为贴合实际应用场景的算力限制指标。

参照图3，根据本申请一些实施例的云平台资源监控方法，步骤S202可以包括，但不限于下述步骤S301至步骤S303。

步骤S301，基于预设的异常模拟信息，从各个算力资源池的资源负载节点中确定正常模拟节点与异常模拟节点；

步骤S302，对各个算力资源池的异常模拟节点进行失效处理；

步骤S303，基于正常模拟节点以及失效处理后的异常模拟节点，进行第一压力测试，得到算力限制指标。

在一些实施例中的步骤S301至步骤S302中，先基于预设的异常模拟信息，从各个算力资源池的资源负载节点中确定正常模拟节点与异常模拟节点，再对各个算力资源池的异常模拟节点进行失效处理。需要说明的是，对各个算力资源池的异常模拟节点进行失效处理，用于模拟若干资源负载节点发生异常的负荷边界情形。应理解，每一算力资源池均包括多个资源负载节点，而同一算力资源池的所有资源负载节点中可能存在若干个负载资源节点出现异常而失效，此时整个资源池能够为云平台系统提供的算力资源随即受到影响。

在一些实施例中的步骤S303中，为了评估若干个负载资源节点出现异常而失效时，算力资源所受到的影响，本申请一些较为优选的实施例中基于预设的异常模拟信息从各个算力资源池的资源负载节点中确定正常模拟节点与异常模拟节点，再对各个算力资源池的异常模拟节点进行失效处理之后，进一步基于正常模拟节点以及失效处理后的异常模拟节点，进行第一压力测试，得到算力限制指标。需要明确，预设的异常模拟信息指的是预先设置的、用于模拟资源负载节点异常状况的参照信息。例如，基于预设的异常模拟信息，从每一算力资源池中随机选中一组资源负载节点进行失效处理，再基于正常模拟节点以及失效处理后的异常模拟节点进行第一压力测试，以模拟各个算力资源池可能会遭遇的故障情形。根据本申请一些较为具体的实施例，在上述第一压力测试的过程中，确定算力资源池所能够承载的故障负荷上限，再基于故障负荷上限确定资源池中所有资源负载节点正常时所对应的安全阈值并将其作为算力限制指标，即可实现为算力资源池可能出现的故障留有足够余量，避免安全隐患。

参照图4，根据本申请一些实施例的云平台资源监控方法，步骤S202还可以包括，但不限于下述步骤S401至步骤S402。

步骤S401，获取与多个应用程序一一对应的应用标签信息，应用标签信息用于反映应用程序的资源消耗特征；

步骤S402，基于各个应用标签信息对算力资源池进行第一压力测试，得到算力限制指标。

在一些实施例中的步骤S401至步骤S402中，先获取与多个应用程序一一对应的应用标签信息，应用标签信息用于反映应用程序的资源消耗特征，再基于各个应用标签信息对算力资源池进行第一压力测试，得到算力限制指标。需要强调，算力资源池是一种集成算力资源的虚拟资源池，虚拟资源池作为实现融合基础设施结构的关键要素，是共享服务器、存储和网络的集合，能够根据应用程序的要求更快地进行重新配置，从而能够更容易、更快捷地支持业务需求的变化。本申请一些实施例中，云平台系统的资源使用情况可能会符合某些特定的资源消耗特征，例如某几个应用程序资源消耗的高峰往往集中于同一时间段内、某几个体量中等的应用程序由于相互之间的联动关系而产生较大资源消耗等各种各样的资源消耗特征。而应用标签信息则用于反映应用程序的资源消耗特征，因此，基于各个应用标签信息对算力资源池进行第一压力测试，得到算力限制指标，即可针对具备各种资源消耗特征的云平台系统进行模拟，进一步营造出各个算力资源池可能会遭遇的负荷边界情形，从而更为准确的得到算力限制指标。

根据本申请一些较为具体的实施例，针对Kubernetes云平台系统的监控过程中，可以结合各个应用标签信息与污点机制对算力资源池进行第一压力测试。例如，某几个应用程序资源消耗的高峰往往集中于同一时间段内，则可以依照此规律判断：若这几个应用程序分别对应与不同的算力资源池，则相较而言节省资源算力，同理，若这几个应用程序对应相同的算力资源池，则相较而言较为耗费更多的资源算力；基于上述判断，可以利用污点机制，将上述几个应用程序分配到不同应用程序，测定算力消耗的最小值，再将上述几个应用程序分配到相同应用程序，测定算力消耗的最大值，如此一来便可依照算力消耗的最小值与最大值划定算力消耗的合理区间，当实测得到的算力消耗不在此合理区间内，这说明算力消耗出现异常。需要说明的是，Kubernetes云平台系统的污点(Tai nt)应用于Node节点上，表示该节点存在污点，其中不能忍受这个污点的Pod则无法被调度/运行到该节点上。而容忍度(To l erat ion)则应用于Pod上，容忍度允许资源调度器调度带有对应污点的Pod，或者允许这个Pod继续运行到这个节点上。可以明确，污点和容忍度之间相互配合，即可用来避免Pod被分配/运行到不合适的节点上，另外，每个节点上都可以应用一个或多个污点，每个Pod也是可以应用一个或多个容忍度。需要指出，基于各个应用标签信息对算力资源池进行第一压力测试，得到算力限制指标的方式多种多样，可以包括，但不限于上述举出的具体实施例。需要强调，基于各个应用标签信息对算力资源池进行第一压力测试，得到算力限制指标，即可针对具备各种资源消耗特征的云平台系统进行模拟，进一步营造出各个算力资源池可能会遭遇的负荷边界情形，从而更为准确的得到算力限制指标。

参照图5，根据本申请一些实施例的云平台资源监控方法，步骤S402可以包括，但不限于下述步骤S501至步骤S502。

步骤S501，基于各个应用标签信息，确定各个应用程序的消耗峰值时段；

步骤S502，基于消耗峰值时段处于同一预设区间内的各个应用程序，对算力资源池进行第一压力测试，得到算力限制指标。

在一些实施例中的步骤S501至步骤S502中，先基于各个应用标签信息，确定各个应用程序的消耗峰值时段，再基于消耗峰值时段处于同一预设区间内的各个应用程序，对算力资源池进行第一压力测试，得到算力限制指标。需要强调，应用标签信息用于反映应用程序的资源消耗特征，因此基于各个应用标签信息，即可确定各个应用程序的消耗峰值时段，其中消耗峰值时段值得的应用程序的算力消耗峰值所处的时段。若某几个应用程序资源消耗的高峰往往集中于同一时间段内，则基于消耗峰值时段处于同一预设区间内的各个应用程序，对算力资源池进行第一压力测试，得到算力限制指标。具体而言，若这几个应用程序分别对应与不同的算力资源池，则相较而言节省资源算力，同理，若这几个应用程序对应相同的算力资源池，则相较而言较为耗费更多的资源算力，因此，将消耗峰值时段处于同一预设区间内的各个应用程序均分配在不同算力资源池内进行第一压力测试，测得算力资源消耗的最小值，再消耗峰值时段处于同一预设区间内的各个应用程序分配在同一算力资源池内进行第一压力测试，测得算力资源消耗的最大值，随即以算力资源消耗的最小值与最大值，即可划定算力资源消耗的合理区间，将该合理区间确定为算力限制指标将其与算力实测指标进行比对，即可用于判断算力消耗是否出现异常。需要强调，基于各个应用标签信息对算力资源池进行第一压力测试，得到算力限制指标的方式多种多样，可以包括，但不限于上述举出的具体实施例。应理解，由于实际应用中，针对应用程序的算力资源池分配有多种多样的情况，故而基于消耗峰值时段处于同一预设区间内的各个应用程序，对算力资源池进行第一压力测试，能够更为合理地测定算力限制指标。

本申请一些实施例的步骤S103中，对资源编排层进行编排指标检测，得到资源编排指标。需要强调的是，资源编排层包括资源管理服务器，用于编排算力资源层提供的算力资源。需要指出，资源编排指标包括反映资源调度能力限制的编排限制指标、反映资源调度情况的编排实测指标。其中，编排限制指标能够通过对资源管理服务器进行压力测试而测定，而编排实测指标则可以通过资源管理服务器与各模块之间的信息交互而获取。

在一些较为具体的实施例中，Kubernetes云平台系统中的资源管理服务器指的是Kubernetes AP I Server，用于提供Kubernetes各类资源对象(如Pod、RC、Servi ce等)的增删改查及WATCH等HTTP Rest接口，是整个系统的数据总线和数据中心。Kubernetes AP IServer作为集群的核心，负责集群各功能模块之间的通信，集群内各个功能模块通过AP IServer将信息存入Etcd，当需要获取和操作这些数据时，通过AP I Server提供的REST接口(GET\L I ST\WATCH方法)来实现，从而实现各模块之间的信息交互。具体而言，AP IServer与各模块之间的交互包括以下几类：其一，Kube l et与AP I Server之间的交互，每个Node节点上的Kube l et定期就会调用API Server的REST接口报告自身状态，APIServer接收这些信息后，将节点状态信息更新到Etcd中。Kube l et也通过API Server的WATCH接口监听Pod信息，从而对Node节点上的POD进行管理；其二，Kube-contro l l er-manager与API Server之间的交互，Kube-contro l l er-manager中的Node Contro l ler模块通过API Server提供的WATCH接口，实时监控Node节点的信息，并做相应处理，通过API Server提供的接口可以实时监控整个集群里的每一个资源对象的当前状态，当发生各种故障导致系统状态发生变化，这些Node Contro l l er会尝试将系统从“现有状态”修正到“期望状态”；其三，Kube-Schedu l er与API Server之间的交互，Schedu l er通过APIServer的WATCH接口监听到新建Pod副本的信息后，它会检索所有符合该Pod要求的Node节点列表，开始执行Pod调度逻辑，调度成功后随即将Pod绑定到目标节点上。

参照图6，根据本申请的一些实施例，资源编排层包括资源调配服务器，步骤S103可以包括，但不限于下述步骤S601至步骤S604。

步骤S601，对资源调配服务器执行多次模拟请求操作，以获取与多次模拟请求操作一一对应的多个响应测试信息；

步骤S602，基于多个响应测试信息，确定资源调配服务器的响应上限信息；

步骤S603，基于响应上限信息，得到编排限制指标；

步骤S604，根据编排限制指标，得到资源编排指标。

在一些实施例中的步骤S601至步骤S604中，先对资源调配服务器执行多次模拟请求操作，以获取与多次模拟请求操作一一对应的多个响应测试信息，基于多个响应测试信息，确定资源调配服务器的响应上限信息，进一步，基于响应上限信息，得到编排限制指标，再进一步，基于响应上限信息，得到编排限制指标。需要强调，资源编排层用于编排算力资源层提供的算力资源，应理解，如若云平台系统的资源编排能力不足，即便算力资源层能够提供十分充足的资源，也难以顺利在云平台系统中实现合理调用资源，达到理想目的。因此，监控云平台系统的资源编排能力十分重要，故而本申请一些示例性的实施例中，对资源调配服务器执行多次模拟请求操作，以获取与多次模拟请求操作一一对应的多个响应测试信息，其原因在于，通过多次的模拟请求操作、与多次模拟请求操作一一对应的多个响应测试信息，能够基于多个响应测试信息，确定资源调配服务器的响应上限信息，其中响应上限信息则反映的是资源调配服务器的响应上限，以便于在后续步骤中基于响应上限信息得到反映云平台系统资源编排能力的编排限制指标。需要明确的是，对资源调配服务器执行多次模拟请求操作可以通过压力测试工具或者利用预先编写好的程序、脚本等方式来实现，而响应测试信息可以是与模拟请求操作对应的响应时间，也可以是单位时间内的有效响应次数，还可以是与模拟请求操作对应的其他响应参数。

根据本申请一些较为具体的实施例，在Kubernetes云平台系统中，可以通过压力测试工具或者预先编写的程序、脚本，对Kubernetes各类API资源(如Dep l oyment、Service等)多次实施增添、删除、修改、查看四类模拟请求操作，以获取与多次模拟请求操作一一对应的多个响应测试信息，从而基于多个响应测试信息，确定资源调配服务器的响应上限信息。以she l l脚本为例，使用Kubect l客户端的get、de l et l e、ed it等指令循环批量操作创建、删除、修改POD等各类资源模拟日常操作行为，核心是在高频模拟AP I操作的同时，利用监控工具找到资源调配服务器能够承载请求的响应上限信息，以便于进一步基于响应上限信息，得到编排限制指标。需要指出的是，资源调配服务器的编排限制指标可以包括，但不限于Api-server的响应时间、超时情况等。另外，本申请一些实施例中，也可以通过存储服务能力的压力测试工具，使用jmeter或者撰写脚本可以模拟对Etcd的高频读写，同时配合监控工具测定Etcd的读写耗时，磁盘IO指标等能够反馈服务能力的指标，并将其确定为编排限制指标的一部分。

经由上述步骤S601至步骤S604，先对资源调配服务器执行多次模拟请求操作，以获取与多次模拟请求操作一一对应的多个响应测试信息，再基于多个响应测试信息，确定资源调配服务器的响应上限信息，进一步，基于响应上限信息，得到编排限制指标，再进一步，根据编排限制指标，得到资源编排指标，能够基于资源调配服务器的响应上限信息来确定编排限制指标，从而更为合理地测定资源编排指标，以监控云平台系统的资源编排能力。

参照图7，根据本申请一些实施例的云平台资源监控方法，资源编排层还包括数据存储单元，数据存储单元为资源调配服务器提供存储功能，步骤S604可以包括但不限于下述步骤S701至步骤S702。

步骤S701，对资源编排层的数据存储单元进行存储指标检测，得到编排实测指标；

步骤S702，基于预设的监控权重对编排限制指标与编排实测指标进行整合，得到资源编排指标，监控权重中编排实测指标的占比高于编排限制指标的占比。

在一些实施例中的步骤S701至步骤S702中，需要先对资源编排层的数据存储单元进行存储指标检测，得到编排实测指标，再基于预设的监控权重对编排限制指标与编排实测指标进行整合，得到资源编排指标，监控权重中编排实测指标的占比高于编排限制指标的占比。需要强调的是，资源编排指标包括反映资源调度能力限制的编排限制指标、反映资源调度情况的编排实测指标。需要明确，资源编排层的数据存储单元存储有云平台系统中的控制数据、应用数据以及云平台系统的集群状态，以便云平台系统进行调用。由于资源编排层的数据存储单元存储有云平台系统中的控制数据、应用数据以及云平台系统的集群状态，并且数据存储单元为资源调配服务器提供存储功能，因此数据存储单元的存储服务能力对资源调配服务器的资源编排能力有着重要影响，一些实施例中，若资源调配服务器的资源编排能力受到限制，需要优先排查数据存储单元是否存在异常。故而，为了便于排查数据存储单元可能出现的故障，本申请一些较为优选的实施例中，需要针对资源编排层的数据存储单元进行存储指标检测，得到编排实测指标。

根据本申请一些较为具体的实施例，在Kubernetes云平台系统中，资源编排层的数据存储单元可以是Kubernetes云平台系统的核心组件Etcd。需要说明，Etcd是Kubernetes云平台系统中一个高可用的键值存储系统，主要用于Kubernetes集群的共享配置和服务发现，它通过Raft一致性算法处理日志复制以保证强一致性，可以视作一个高可用强一致性的服务发现存储仓库。具体而言，Etcd需要集中管理一些配置信息，应用程序在启动的时候主动从Etcd获取一次配置信息，同时，在Etcd节点上注册一个WATCHer并等待，以后每次配置有更新的时候，Etcd都会实时通知订阅者，以此达到获取最新配置信息的目的；而服务发现也是分布式系统中需要解决的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名称就可以查找和连接。Etcd主要解决的是分布式系统中数据一致性的问题，而分布式系统中的数据分为控制数据和应用数据，Etcd处理的数据类型为控制数据，对于很少量的应用数据也可以进行处理。需要说明的是，作为资源调配服务器的Api-server可以视作Etcd的前端,同时整个Kubernetes集群的状态又存储在Etcd中，因此Etcd的存储服务能力实际上对于Ap i-server的资源编排能力有着举足轻重的影响。故而本申请一些较为优选的实施例中，需要实时测定Etcd的IOPS、IO bits/S以及Rratf延迟等指标，并将其确定为编排实测指标，用于反映Etcd的存储服务能力。在得到作为编排实测指标的Etcd的IOPS、IO bits/S以及Rratf延迟等指标之后，随即进一步基于预设的监控权重对编排限制指标与编排实测指标进行整合，得到资源编排指标，监控权重中编排实测指标的占比高于编排限制指标的占比，其原因也是在于Etcd的存储服务能力实际上对于Api-server的资源编排能力有着举足轻重的影响，故而在Api-server资源编排能力受到限制的情况下，可以首先依照监控权重中编排实测指标来进行Etcd的异常排查。需要指出，监控权重可以在资源编排指标中加以体现，以便于维护工作的进行，例如，若资源编排指标需要体现在监控大盘上，则可以对编排实测指标配置较大的画面占比、对编排限制指标配置小于编排实测指标的画面占比，或者，若资源调配服务器出现异常，首先跳出展示编排实测指标的弹窗。需要明确，对于云平台资源的监控伴随着诸多指标的罗列，若不合理地依照各指标的重要程度进行排列，则监控的效率将会较为低下，故而，本申请一些优选地的实施例基于预设的监控权重对编排限制指标与编排实测指标进行整合，得到资源编排指标，能够依照监控权重将编排实测指标作为一个较为重要的指标反馈给运维部门，以提升监控效率，便于后续维护。

本申请一些实施例的步骤S104中，对应用资源层进行应用指标检测，得到应用资源指标。需要强调的是，应用资源层可以包括资源控制器与资源调度器，用于为云平台系统上的应用程序提供可调配资源。需要指出，应用资源指标包括反映资源告警信息的资源告警指标、反映调度障碍信息的调度障碍指标。其中，资源告警指标与调度障碍指标均可以从云平台系统的应用日志信息中获取。

根据本申请一些较为具体的实施例，Kubernetes云平台系统的应用资源层可以包括资源控制器Kube Contro l l er与资源调度器Kube Schedu l er，其中资源控制器KubeContro l l er的作用包括：确保预期的Pod的副本数量、确保所有的Node节点运行同一个Pod、规划一次性任务和定时任务、无状态应用部署、有状态应用部署，而资源调度器KubeSchedu l er用于根据预设算法选择Node节点进行应用部署。需要指出，Dep l oyment控制器是Kubernetes云平台系统中一类具体的资源控制器，由于Dep l oyment控制器不直接管理pod，而是通过管理rep l icaset来间接管理pod，即：dep l oyment管理rep l icaset，rep l icaset管理pod，因此Dep l oyment控制器比rep l icaset的功能更强大，故而一些较为优选的实施例中，选用Dep l oyment控制器作为资源控制器，用以指示Kubernetes云平台系统创建和更新应用程序的实例，利用Master节点将应用程序实例调度到节点中的具体的节点上，创建应用程序实例后，Dep l oyment控制器会持续监控这些实例，若运行应用程序实例的Node节点关机或被删除，则Dep l oyment控制器将在集群中资源最优的另一个Node节点上重新创建一个新的实例，进而提供一种自我修复机制来预防故障或维护问题。

参照图8，根据本申请一些实施例的云平台资源监控方法，步骤S104可以包括但不限于下述步骤S801至步骤S803。

步骤S801，获取与应用资源层对应的应用日志信息；

步骤S802，根据应用日志信息，得到资源告警信息与调度障碍信息；

步骤S803，根据资源告警信息与调度障碍信息，确定应用资源指标。

在一些实施例中的步骤S801至步骤S803中，针对应用资源层的应用指标检测，需要先获取与应用资源层对应的应用日志信息，再根据应用日志信息，得到资源告警信息与调度障碍信息，进而根据资源告警信息与调度障碍信息，确定应用资源指标。需要说明的是，针对每一应用程序，应用程序所见的资源池并非是整个被抽象的集群资源，实际上是多个已经被划分好的资源小池，故而应用资源指标则难以从资源池进行测定。由于云平台系统的应用日志信息中往往包括反映应用资源状况的字段，因此本申请一些实施例中，可以根据应用日志信息，得到资源告警信息与调度障碍信息，再进一步根据资源告警信息与调度障碍信息，确定应用资源指标。其中资源告警信息指的是资源负载节点异常时对应得到的日志信息，例如资源负载节点能够提供的算力资源不足，而调度障碍信息指的是资源编排过程异常时对应得到的日志信息，例如节点停滞时间过长。

根据本申请一些较为具体的实施例，Kubernetes云平台系统的应用日志信息中包括evi cted关键字(POD_EVI CTED)以及pend i ng关键字(POD_PEND I NG)，应理解，ev ict i on即驱赶的意思，而evi cted关键字则表示资源负载节点已被驱赶。当资源负载节点出现异常时，Kubernetes通过相应的驱赶机制剔除该节点上的Pod，多见于资源不足时导致的驱赶。而pend i ng为待定的意思，当Pod一直处于Pend i ng状态时，说明该Pod还未被调度到某个节点上，需查看Pod分析问题原因，Pod一直处于Pend i ng状态的原因可以包括，但不限于：节点资源不足、不满足nodeSe l ector与aff i n ity、Node存在Pod没有容忍的污点、低版本kube-Schedu l er的bug、kube-Schedu l er未正常运行、驱逐后其他可用节点与当前节点的有状态应用不在相同可用区等。因此，遍历Kubernetes云平台系统的应用日志信息，将evi cted关键字作为资源告警信息，将pend i ng关键字作为调度障碍信息，即可进一步根据资源告警信息与调度障碍信息，确定应用资源指标。

经由上述步骤S801至步骤S803示出的实施例，通过资源告警信息与调度障碍信息所得到的应用资源指标，能够更为清楚、明晰地反映资源分配情况，因此通过监控应用资源指标即可发现云平台系统的应用资源层是否出现异常。

本申请一些实施例的步骤S105中，基于算力资源指标、资源编排指标与应用资源指标，生成资源监控信息。需要说明的是，由于算力资源层用于为云平台系统提供算力资源，因此对算力资源层进行算力指标检测，即可得到反映算力资源层资源占用情况的算力资源指标；由于资源编排层用于编排算力资源层提供的算力资源，因此对资源编排层进行编排指标检测，即可得到反映资源编排情况的资源编排指标；由于应用资源层用于为云平台系统上的应用程序提供可调配资源，因此对应用资源层进行应用指标检测，即可得到反映资源分配情况的应用资源指标。故而，基于算力资源指标、资源编排指标与应用资源指标，即可生成用于反映云平台系统资源使用情况的资源监控信息。

图9示出了本申请实施例提供的电子设备900。电子设备900包括：处理器901、存储器902及存储在存储器902上并可在处理器901上运行的计算机程序，计算机程序运行时用于执行上述的云平台资源监控方法。

处理器901和存储器902可以通过总线或者其他方式连接。

存储器902作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序，如本申请实施例描述的云平台资源监控方法。处理器901通过运行存储在存储器902中的非暂态软件程序以及指令，从而实现上述的云平台资源监控方法。

存储器902可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序。存储数据区可存储执行上述的云平台资源监控方法。此外，存储器902可以包括高速随机存取存储器902，还可以包括非暂态存储器902，例如至少一个储存设备存储器件、闪存器件或其他非暂态固态存储器件。在一些实施方式中，存储器902可选包括相对于处理器901远程设置的存储器902，这些远程存储器902可以通过网络连接至该电子设备900。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

实现上述的云平台资源监控方法所需的非暂态软件程序以及指令存储在存储器902中，当被一个或者多个处理器901执行时，执行上述的云平台资源监控方法，例如，执行图1中的方法步骤S101至步骤S105、图2中的方法步骤S201至步骤S202、图3中的方法步骤S301至步骤S303、图4中的方法步骤S401至步骤S402、图5中的方法步骤S501至步骤S502、图6中的方法步骤S601至步骤S604、图7中的方法步骤S701至步骤S702、图8中的方法步骤S801至步骤S803。

本申请实施例还提供了计算机可读存储介质，存储有计算机可执行指令，计算机可执行指令用于执行上述的云平台资源监控方法。

在一实施例中，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个控制处理器执行，例如，执行图1中的方法步骤S101至步骤S105、图2中的方法步骤S201至步骤S202、图3中的方法步骤S301至步骤S303、图4中的方法步骤S401至步骤S402、图5中的方法步骤S501至步骤S502、图6中的方法步骤S601至步骤S604、图7中的方法步骤S701至步骤S702、图8中的方法步骤S801至步骤S803。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、储存设备存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包括计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。还应了解，本申请实施例提供的各种实施方式可以任意进行组合，以实现不同的技术效果。以上是对本申请的较佳实施进行了具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请精神的共享条件下还可作出种种等同的变形或替换，这些等同的变形或替换均包括在本申请权利要求所限定的范围内。

Claims (10)

1.一种云平台资源监控方法，其特征在于，应用于云平台系统，所述方法包括：

获取与所述云平台系统对应的云系统层级模型，所述云系统层级模型包括算力资源层、资源编排层以及应用资源层，其中，所述算力资源层用于为所述云平台系统提供算力资源、所述资源编排层用于编排所述算力资源层提供的算力资源，所述应用资源层用于为所述云平台系统上的应用程序提供可调配资源；

对所述算力资源层进行算力指标检测，得到算力资源指标；

对所述资源编排层进行编排指标检测，得到资源编排指标；

对所述应用资源层进行应用指标检测，得到应用资源指标；

基于所述算力资源指标、所述资源编排指标与所述应用资源指标，生成资源监控信息。

2.根据权利要求1所述的方法，其特征在于，所述算力资源层包括多个资源负载节点，所述算力资源指标包括算力限制指标，所述对所述算力资源层进行算力指标检测，得到算力资源指标，包括：

对多个所述资源负载节点进行集群划分处理，得到算力资源池；

基于所述算力资源池进行第一压力测试，得到所述算力限制指标。

3.根据权利要求2所述的方法，其特征在于，所述基于所述算力资源池进行第一压力测试，得到所述算力限制指标，包括：

基于预设的异常模拟信息，从各个所述算力资源池的所述资源负载节点中确定正常模拟节点与异常模拟节点；

对各个所述算力资源池的所述异常模拟节点进行失效处理；

基于所述正常模拟节点以及失效处理后的所述异常模拟节点，进行第一压力测试，得到所述算力限制指标。

4.根据权利要求2所述的方法，其特征在于，所述基于所述算力资源池进行第一压力测试，得到所述算力限制指标，包括：

获取与多个所述应用程序一一对应的应用标签信息，所述应用标签信息用于反映所述应用程序的资源消耗特征；

基于各个所述应用标签信息对所述算力资源池进行第一压力测试，得到所述算力限制指标。

5.根据权利要求4所述的方法，其特征在于，所述基于各个所述应用标签信息对所述算力资源池进行第一压力测试，得到所述算力限制指标，包括：

基于各个所述应用标签信息，确定各个所述应用程序的消耗峰值时段；

基于所述消耗峰值时段处于同一预设区间内的各个所述应用程序，对所述算力资源池进行第一压力测试，得到所述算力限制指标。

6.根据权利要求1所述的方法，其特征在于，所述资源编排层包括资源调配服务器，所述对所述资源编排层进行编排指标检测，得到资源编排指标，包括：

对所述资源调配服务器执行多次模拟请求操作，以获取与多次所述模拟请求操作一一对应的多个响应测试信息；

基于多个所述响应测试信息，确定所述资源调配服务器的响应上限信息；

基于所述响应上限信息，得到编排限制指标；

根据所述编排限制指标，得到资源编排指标。

7.根据权利要求6所述的方法，其特征在于，所述资源编排层还包括数据存储单元，所述数据存储单元用于为所述资源调配服务器提供存储功能，所述根据所述编排限制指标，得到资源编排指标，包括：

对所述资源编排层的数据存储单元进行存储指标检测，得到编排实测指标；

基于预设的监控权重对所述编排限制指标与所述编排实测指标进行整合，得到所述资源编排指标，所述监控权重中所述编排实测指标的占比高于所述编排限制指标的占比。

8.根据权利要求1所述的方法，其特征在于，对所述应用资源层进行应用指标检测，得到应用资源指标，包括：

获取与所述应用资源层对应的应用日志信息；

根据所述应用日志信息，得到资源告警信息与调度障碍信息；

根据所述资源告警信息与所述调度障碍信息，确定应用资源指标。

9.一种电子设备，其特征在于，包括：存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至8中任意一项所述的云平台资源监控方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行实现如权利要求1至8中任意一项所述的云平台资源监控方法。

Images