CN116048814A - 一种基于监控效用数据的应用资源规格自动优化方法 - Google Patents

Abstract

本发明公开了一种基于监控效用数据的应用资源规格自动优化方法，在应用资源部署以后，基于一段时间多维度的监控数据为应用资源设置合理的规格，保证应用稳定运行的同时，使单节点容纳更多的应用部署，降低应用的运行成本，提高计算资源的使用率。其技术方案为：第一步：从节点上采集应用节点的负载数据；第二步：将各节点接入外部的实时监控系统，通过实时监控系统获取业务监控指标；第三步：根据需求设置变更配置的参数；第四步：基于变更配置的参数计算推荐规格和偏移度，选择手动或者自动在业务低峰期分批将变更后的新配置进行生效。

Description

一种基于监控效用数据的应用资源规格自动优化方法

技术领域

本发明涉及资源优化技术，具体涉及一种基于监控效用数据的应用资源规格自动优化方法。

背景技术

主流技术下，应用资源规格通常是通过开发者的经验来寻找相对合理的规格，在有压测条件的情况下会通过压测报告来确定。应用开发在上生产之前，可以配合压测团队一起对应用进行压测。通过压测报告的性能数据以及资源使用情况，结合项目计划要承载的流量大小，来确定应用规格，后续仅当明显有应用资源不足导致的异常后会进行升配。

具体如图2所示，开发在应用上线之前，通过压测数据或者根据经验来确定一个较高的资源规格，上线以后通常只会在资源不足的情况下对资源规格进行升配。

传统主流方案下，开发在应用上线之前，会对应用的重要程度和资源消耗情况进行评估。如果重要程度不高的应用，会选择一种常见的低配置，如1C2G，2C4G等。而如果是重要的核心应用，在缺少压测资源的情况下，通常会由开发根据经验指定高配置来部署。在可以压测的情况下，则通过压测数据综合计划承载的流量大小来确定资源规格。应用上线以后通常只会在资源不足的情况下对资源规格进行升配，如果是K8S上部署的，则可以额外配置HPA(水平扩展)，在应用负载较高时进行节点扩容，增加副本数，以保障业务的稳定性。HPA总体来说更偏向于是一个运维的保障。

可见，在传统方案下，因为是开发基于人工经验填写，通常情况下上线会参考容器的历史利用率情况、应用压测数据来确定，再根据生产上的运行情况的调整。专家模式无法规模化运作，随着应用数的增多，很难再精细化去配置每个应用的节点规格，而且往往会为了保证应用服务的可靠性稳定性，为应用预留大量冗余资源成为生产上的常态。在调整配置的时候，如果缺乏数据依据，贸然调整得过低也会给系统留下隐患。

根据云厂商统计数据表明，目前数据中心资源利用率仅为10％左右，存在着巨大的优化空间。这么低的资源利用率意味着计算资源存在着大量的浪费。如果能够做到提升资源利用率，降本增效，就可以给企业节省大量的机器成本。企业的规模越大，提升资源利用率所带来的降费效果就越显著。

目前依托于容器技术的普及，应用节点的弹性和部署能力得到了很大的提升，应用可以随时随地的调整自身的副本数和CPU内存规格，但是随之而来的就是解决如何合理设置CPU内存规格的问题，如果无法合理的设置CPU规则和内存大小，总体的资源使用率依旧难以提升。

传统的资源规格确认方式有以下几个弊端：

(1)压测方式的沟通和技术成本高，并且需要有专业压测团队的支撑，且周期长，通常需要一周以上，随着应用数量增多，效率会愈发低下，难以规模化运作。

(2)为了保证业务的稳定性，评估出来的资源规格往往会比实际使用高出很多，造成生产环境的资源平均负载率很低。但是降低配置又存在着一定风险，维护人员缺乏动力去自发调整。

通常如图1所示，应用系统的延迟和应用资源的使用率成反比。业务系统对资源竞争导致的服务质量下降是难以容忍的。在降本增效越来越受到企业重视的今天，数据中心在整体上资源利用率水平低，运营成本居高不下，资源利用率的提升势在必行。而提升资源利用率、降低运营成本却可能影响到在线业务服务质量，带来潜在的风险。

理想情况下，我们能通过调整资源规格大小来平衡资源的使用率与应用系统的性能的关系，在将应用系统的平均延迟在合理区间的前提下，尽可能地提高资源使用率，也就是图1中所示的期望区间范围。

而采用何种手段，来动态地评估资源的使用情况并推荐规格，最终得到理想的规格来进行替换，是目前业界解决的课题。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种基于监控效用数据的应用资源规格自动优化方法，在应用资源部署以后，基于一段时间多维度的监控数据为应用资源设置合理的规格，保证应用稳定运行的同时，使单节点容纳更多的应用部署，降低应用的运行成本，提高计算资源的使用率。

本发明的技术方案为：本发明揭示了一种基于监控效用数据的应用资源规格自动优化方法，方法包括：

第一步：从节点上采集应用节点的负载数据；

第二步：将各节点接入外部的实时监控系统，通过实时监控系统获取业务监控指标；

第三步：根据需求设置变更配置的参数；

第四步：基于变更配置的参数计算推荐规格和偏移度，选择手动或者自动在业务低峰期分批将变更后的新配置进行生效。

根据本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例，负载数据包括节点/POD规格和性能效用指标，其中节点/POD规格包括节点数、CPU核数、内存规格，性能效用指标包括CPU使用量、CPU使用率、内存使用量、内存使用率。

根据本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例，在第一步中，在节点上安装采集组件进行采集，采集组件采集到的负载数据存储到Prometheus中，其中，采集组件包括node-exporter组件和cAdvisor组件，虚拟机的负载数据由node-exporter组件采集，docker容器的数据由Advisor组件采集，k8s的数据由node-exporter组件和cAdvisor组件采集。

根据本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例，第二步中的业务监控指标包括应用业务请求TPS和业务请求响应延迟的数据，实时监控系统包括美团的cat系统或者阿里的arms系统。

根据本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例，第三步中的变更配置的参数包括：安全冗余度、轮询周期、变更阈值、变更观察期，核心指标波动阈值。

根据本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例，第四步中的推荐规格和偏移度的具体处理进一步包括：

首先，通过秒级的监控数据周期性地计算各种效用基数，再基于计算出的效用基数计算出推荐规格和偏移度；

然后，在计算出上述的效用基数后再计算推荐规格；

之后，在推荐规格的基础上进行偏移值和偏移度的计算。

根据本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例，第四步中的变更后的新配置的生效处理进一步包括：

在每个轮询周期开始时，根据计算出的最新的偏移度和变更阈值进行判定，如果偏移度达到了变更阈值，则自动选择低峰期开始或者提醒管理员手动进行节点配置变更，配置变更按照计算出的最新的推荐规格进行分批变更。

根据本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例，分批变更采用以下方式：第一批先替换一个节点的配置，如果经过一半的观察期无异常，则第二批会继续替换剩余节点的配置。

根据本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例，第四步中的变更后的新配置的生效处理进一步包括：

判断业务监控指标在观察期内是否达到波动阈值，如果达到则自动或者提醒管理员进行配置回滚。

本发明对比现有技术有如下的有益效果：本发明的方案中，将压测的过程简化乃至略过，通过持续的各种维度的资源使用率数据结合权重以及业务核心指标的平均延迟和TPS波动情况，动态地评估资源的使用情况并推荐规格(如普通虚拟机的内存和CPU大小，K8S中POD的request和limit等)，最终得到理想的规格来进行替换。

详细而言，本发明包括以下创新之处：

1、结合应用的资源指标计算推荐配置，计算出来的配置更符合应用的实际需求，最大化利用机器的性能，极大的节省了机器费用。偏离度计算使得每次节省配置的效果得以量化，每次配置变更皆有依据，结果可追溯。

2、将规格变更与业务的核心指标关联起来，在配置变更的每一步始终关注核心指标的变化情况，适用范围广，同时适用于普通虚拟机、docker容器和k8s的配置优化。针对特定的应用可以配置各项参数来定制配置调整策略。配置好变更阈值和轮询周期，能让变更的频率控制在合理范围内。分批次变更保证了节点配置变更的平稳性，使得风险可以被及时发现，提高资源利用率的同时保证了业务的稳定性。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了传统技术中应用系统的平均延迟与应用资源的使用率的关系示意图。

图2示出了现有的应用资源的规格通过压测报告来确定的流程示意图。

图3示出了本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例的流程示意图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图3示出了本发明的基于监控效用数据的应用资源规格自动优化方法的一实施例的流程。首先概述一下方案的原理，在每个轮询周期开始时，资源优化管理系统里的资源效用模块通过采集到的CPU、内存等多维度的数据，配合权重和自定义规则计算推荐配置。变更管理模块根据选择在合适的时间分批调整配置，再在自定义的观察期内观测核心指标，如果核心指标无显著影响，则标识变更成功，反之则回滚并标记变更失败，对应的优化变更配置，比如调高安全冗余度等处理。

第一步：从节点上采集应用节点的负载数据，这些负载数据包括节点/POD规格和性能效用指标。节点/POD规格包括节点数、CPU核数、内存规格，性能效用指标包括CPU使用量、CPU使用率、内存使用量、内存使用率。

在本步骤中，需要在各类节点(包括虚拟机、docker容器、k8s集群节点等)上安装采集组件。

K8S即Kubernetes，是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。通过Kubernetes能够进行应用的自动化部署和扩缩容。在Kubernetes中，会将组成应用的容器组合成一个逻辑单元从而更易管理和发现。

对于节点/POD规格和性能效用指标在内的节点负载数据的采集，采集组件获取节点/POD规格和性能效用指标并进行存储到Prometheus中。

Prometheus是由SoundCloud开发的开源监控系统，由GO语言编写而成，采用Pull的方式来获取监控信息，并且提供了多维度的数据模型和灵活的查询接口。Prometheus既支持通过静态文件配置监控对象，还支持自动发现机制，能通过Kubernetes、Consul、DNS等多种方式动态获取监控对象。在数据采集方面，借助GO语言高并发的特性，一个Prometheus设备可以采集数百个节点的监控数据；在数据存储方面，单机Prometheus支持每秒10^6个指标采集，并且还支持大量存储场景下的远程存储。

其中，采集虚拟机的数据需要安装采集组件node-exporter，采集docker容器的数据需要安装采集组件cAdvisor，k8s同样可以借助这两个组件(node-exporter和cAdvisor)来采集数据。

这两个组件node-exporter和cAdvisor可以对节点机器以及机器上的资源和容器进行数据采集，包括CPU使用情况、内存使用情况、网络吞吐量及文件系统使用情况，采集的这些基础数据可以根据需要计算出应用节点的CPU、内存使用率的平均值、TP95等，进一步了解这些数据随着时间出现的波峰波谷、周期性等规律，为后续推荐配置计算提供数据支持。

第二步：将各节点接入外部的实时监控系统，比如美团的cat或者阿里的arms等，通过该实时监控系统获取应用业务请求TPS和业务请求响应延迟的数据。

在第二步中，实时监控应用业务的TPS和延迟变化。这些业务接口的数据的变化情况和第一步获取到的应用节点负载数据结合，就可以获取到平均延迟、TPS(一个表达系统处理能力的性能指标，每秒处理的事务数Transaction Per Second，是衡量系统处理能力的重要指标)和负载之间的关系，相当于将传统模式中的压测环节扩展到了生产环境中。这样无论后续代码怎样迭代，总能找到应用所需的合理的配置值。

第三步：根据需求设置变更配置的参数。

结合应用的特性和重要程度在资源优化管理系统中设置变更配置的参数，变更配置的参数包括：安全冗余度、轮询周期、变更阈值、变更观察期，核心指标波动阈值数据，这些参数用以确保配置迭代的过程中业务的稳定性。

这几个参数的含义如下。

安全冗余度：为预设的大于0的百分比，指的是为了保持应用稳定所预留的一部分资源，使资源使用率保持在合理的区间。通常应用重要性越高安全冗余度越大。特殊情况下可以适当调整安全冗余从而控制推荐规格大小。

轮询周期：即前后两次推荐配置检查之间的时间间隔。轮询周期不宜过短，通常两周或者一个月较合理。周期过短的话可能会影响采集数据的全面性，导致推荐配置不够准确。

变更阈值：为某一项资源的资源量或者百分比，比如针对内存，可以设置变更阈值为±500MiB，或者±30％，当检查到新的内存推荐配置与当前的内存配置的差值超出变更阈值的范围后，则会发起配置变更。

变更观察期：为配置变更后的观察等待期，默认为轮询周期的一半，结合核心指标波动阈值来持续跟踪新配置对应用造成的影响。

核心指标波动阈值：针对特定应用设置的波动告警阈值，是保障配置变更期间业务稳定性的重要指标，如果超过阈值则认为应用受到了影响。比如针对应用的某一个服务的延迟设置平均延迟增大20％和最大延迟500ms的波动阈值。

第四步：基于变更配置的参数计算出推荐规格和偏移度，选择手动或者自动在业务低峰期分批将变更后的新配置进行生效。

首先，通过秒级的监控数据周期性地计算各种效用基数，再基于计算出的效用基数计算出推荐规格和偏移度。

在此过程中，效用基数的计算如下：

通常时间越近的样本，越有参考价值。因此我们定义一个衰减因子n，n为小于1的小数，半衰期为一个波峰波谷周期，则权重系数w为：

w＝n^((样本距离当前时间间隔/半衰期长度)-1)

我们用对应时间段的样本数据(样本数据指的是资源的使用量数据，如前述的CPU使用量、内存使用量等)乘以权重系数w，这样每经过一个半衰期，样本数据的权重就相应下降。

假设每个半衰期的长度为1天，n为0.5，之前24小时的样本数据为a1,对应的权重系数w1为1,之前48小时到之前24小时的样本数据为a2，对应的权重系数w2为(1/2)^((48/24)-1)＝0.5,依次类推，最终得到当前轮询周期的效用基数E(a)为：

E(a)＝(a1*w1+a2*w2+…)/(w1+w2+…)。

然后，在计算出上述的效用基数后，再计算推荐规格如下：

推荐规格F(a)等于效用基数E(a)加上预设的安全冗余度r(r为大于0的百分比，非K8S默认30％，K8S request默认20％)：

F(a)＝E(a)*(1+r)。

推荐规格通常都是基于资源使用量的百分位计算，也就是TP90,TP95等，而不是资源使用量的平均值。TP90的含义是90％的数据都满足某一条件，在此处用来代表90％的时间负载都低于某个值。使用百分位计算消除了数据中异常值的大小影响，比如应用程序启动期间遇到的不频繁的CPU峰值。因为我们基于使用量的百分位数据计算得到效用基数，再加上一个安全冗余度r，即可得到最后的推荐规格。安全冗余度r的值可以根据应用的情况设置，通常有30％的冗余即可。由于内存为不可压缩资源，使用超过后会导致OOM(内存溢出，Out Of Memory)异常，影响服务可用性，因此OOM事件的发生也会被记录，并在周期内发生后将当前的内存规格同比放大，与推荐值做比较，取两者的较大值。

针对普通docker容器和虚拟机、针对k8s容器的推荐规格分别说明如下。

针对普通docker容器和虚拟机的推荐规格：

CPU：将样本数据a的值设置为指定单位半衰期内的CPU使用量的TP95，即E(cpu_tp95)；

内存：将样本数据a的值设置为指定单位半衰期内的内存使用量的峰值，即E(mem_max)，如果轮询周期内发生过OOM的话，则最终内存规格为当前内存规格*1.5和推荐规格的较大者。

针对K8S容器的推荐规格：

Request(资源请求量):参考普通docker容器的推荐规格计算方式，因为K8S更高的资源隔离性和可扩展性，根据应用的类型，可以适当将样本数据a的值设置为指定单位半衰期内的使用率的TP90或者平均值，或者降低安全冗余度，从而在单个宿主机上部署更多应用节点，进一步提高使用率。

Limit(资源限制量):CPU limit可以设置为request值*超配系数(2)，结果可以向上取整。同时不要占宿主机节点核数的过大比例，以达到性能和安全的平衡点，避免遇到CPU限流的问题。针对特殊情况可以调整超配系数。

内存limit则可以参考内存request的值，不建议超配过多，通常1.5即可。

之后，在推荐规格的基础上进行偏移值和偏移度的计算，计算规则如下：

偏移值:推荐规格–当前规格；

偏移度：(推荐规格–当前规格)/当前规格*100％。

利用偏移值可以直观地看到预计要调整的资源大小，偏移度则可以用来评估配置调整的必要性辅助决策。

一般认为，当-20％<偏移度<20％，则说明资源使用状况良好，超出这个范围就说明有必要进行配置调整。因此根据偏移度可以设置自动化变更条件来提高变更效率。

从上述处理可知，结合应用的资源指标计算推荐配置，计算出来的配置更符合应用的实际需求，最大化利用机器的性能，极大的节省了机器费用。偏离度计算使得每次节省配置的效果得以量化，每次配置变更皆有依据，结果可追溯。

变更配置的跟踪和生效的处理由变更管理模块来实现。

系统管理人员针对每一个应用配置轮询周期、变更观察期、指标波动阈值、变更阈值、冗余度等变更相关配置。变更管理模块综合机器监控数据和业务监控数据，轮询检查、发起、跟踪每次变更，观察期应小于轮询周期，默认为轮询周期的一半，从而保证每次自动或手动配置变更时，核心业务指标的稳定性。

在每个轮询周期开始的时候，变更管理模块获取资源效用模块计算的最新的推荐规格和偏移度，如果偏移度达到了变更阈值，则自动选择低峰期开始或者提醒管理员手动进行节点配置变更。

配置变更按照推荐规格进行分批变更，默认分两个批次进行：第一批先替换一个节点的配置。如果经过一半的观察期无异常，第二批会继续替换剩余节点的配置。变更计划也可以根据情况进行自定义。

整个变更观察期间，变更管理模块会持续关注业务监控指标和各类机器告警，并进行多维度的比较：同比、环比以及已变更和未变更机器间的横向对比。如果出现异常情况：例如监控指标延迟的平均值/TP99的增长超过了定义的波动阈值(业务能容忍的阈值)，则自动或者提醒管理员进行配置回滚。随后标记本次变更失败，提醒管理员优化变更相关配置并结束流程。如果超过观察期，未发生上述风险事件，则标记本次变更成功并结束。

从上述处理可知，将规格变更与业务的核心指标关联起来，在配置变更的每一步始终关注核心指标的变化情况。适用范围广，同时适用于普通虚拟机，docker容器和k8s的配置优化。针对特定的应用可以配置各项参数来定制配置调整策略。配置好变更阈值和轮询周期，能让变更的频率控制在合理范围内。分批次变更保证了节点配置变更的平稳性，使得风险可以被及时发现，提高资源利用率的同时保证了业务的稳定性。

第四步中改变了传统的机器告警再被动调整配置的方式，在每个轮询周期内主动地去变更应用规格，将应用节点的负载和性能保持在均衡范围内。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (9)

1.一种基于监控效用数据的应用资源规格自动优化方法，其特征在于，方法包括：

第一步：从节点上采集应用节点的负载数据；

第二步：将各节点接入外部的实时监控系统，通过实时监控系统获取业务监控指标；

第三步：根据需求设置变更配置的参数；

第四步：基于变更配置的参数计算推荐规格和偏移度，选择手动或者自动在业务低峰期分批将变更后的新配置进行生效。

2.根据权利要求1所述的基于监控效用数据的应用资源规格自动优化方法，其特征在于，负载数据包括节点/POD规格和性能效用指标，其中节点/POD规格包括节点数、CPU核数、内存规格，性能效用指标包括CPU使用量、CPU使用率、内存使用量、内存使用率。

3.根据权利要求2所述的基于监控效用数据的应用资源规格自动优化方法，其特征在于，在第一步中，在节点上安装采集组件进行采集，采集组件采集到的负载数据存储到Prometheus中，其中，采集组件包括node-exporter组件和cAdvisor组件，虚拟机的负载数据由node-exporter组件采集，docker容器的数据由Advisor组件采集，k8s的数据由node-exporter组件和cAdvisor组件采集。

4.根据权利要求1所述的基于监控效用数据的应用资源规格自动优化方法，其特征在于，第二步中的业务监控指标包括应用业务请求TPS和业务请求响应延迟的数据，实时监控系统包括美团的cat系统或者阿里的arms系统。

5.根据权利要求1所述的基于监控效用数据的应用资源规格自动优化方法，其特征在于，第三步中的变更配置的参数包括：安全冗余度、轮询周期、变更阈值、变更观察期，核心指标波动阈值。

6.根据权利要求1所述的基于监控效用数据的应用资源规格自动优化方法，其特征在于，第四步中的推荐规格和偏移度的具体处理进一步包括：

首先，通过秒级的监控数据周期性地计算各种效用基数，再基于计算出的效用基数计算出推荐规格和偏移度；

然后，在计算出上述的效用基数后再计算推荐规格；

之后，在推荐规格的基础上进行偏移值和偏移度的计算。

7.根据权利要求1所述的基于监控效用数据的应用资源规格自动优化方法，其特征在于，第四步中的变更后的新配置的生效处理进一步包括：

在每个轮询周期开始时，根据计算出的最新的偏移度和变更阈值进行判定，如果偏移度达到了变更阈值，则自动选择低峰期开始或者提醒管理员手动进行节点配置变更，配置变更按照计算出的最新的推荐规格进行分批变更。

8.根据权利要求7所述的基于监控效用数据的应用资源规格自动优化方法，其特征在于，分批变更采用以下方式：第一批先替换一个节点的配置，如果经过一半的观察期无异常，则第二批会继续替换剩余节点的配置。

9.根据权利要求1所述的基于监控效用数据的应用资源规格自动优化方法，其特征在于，第四步中的变更后的新配置的生效处理进一步包括：

判断业务监控指标在观察期内是否达到波动阈值，如果达到则自动或者提醒管理员进行配置回滚。

Images