CN110531988A

CN110531988A - 应用程序的状态预测方法及相关装置

Info

Publication number: CN110531988A
Application number: CN201910722370.9A
Authority: CN
Inventors: 白晨
Original assignee: New H3C Big Data Technologies Co Ltd
Current assignee: New H3C Big Data Technologies Co Ltd
Priority date: 2019-08-06
Filing date: 2019-08-06
Publication date: 2019-12-03
Anticipated expiration: 2039-08-06
Also published as: CN110531988B

Abstract

本发明涉及大数据技术领域，涉及一种应用程序的状态预测方法及相关装置，所述方法包括：获取应用程序的每一服务分别对应的性能状态监控信息和服务状态监控信息；将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息；采用预先训练完成的状态预测模型对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果。本发明采用预先训练后的状态预测模型对应用程序的当前状态进行预测，以便及时发现应用程序的异常，防患于未然。

Description

应用程序的状态预测方法及相关装置

技术领域

本发明涉及大数据技术领域，具体而言，涉及一种应用程序的状态预测方法及相关装置。

背景技术

容器是一种轻量级、可移植、自包含的软件打包技术，使应用程序可以在几乎任何地方以相同的方式运行。容器运行在主操作系统的用户空间中，与操作系统的其他进程隔离，启动容器不需要启动整个操作系统，因此容器的部署和启动速度更快、开销更小，也更容易迁移。现有技术中，部署应用程序时，通常先将应用程序打包成容器，然后通过部署对应的容器实现应用程序的部署。

Kubernetes作为分布式容器部署平台，通常以集群的形式部署，集群由一组节点组成，这些节点可以是物理服务器或虚拟机。通过使用分布在Kubernetes集群内各节点上的容器来管理面向服务的应用程序，为应用程序的部署、更新、调度、服务发现、服务注册、负载均衡、分布式配置管理、运维、扩容等提供了统一的平台支撑，显著地简化了在容器和云上部署应用的复杂性。

如何提高Kubernetes集群中部署的应用程序运行的稳定性和可靠性是本领域技术人员亟待解决的问题。

发明内容

本发明实施例的目的在于提供一种应用程序的状态预测方法及相关装置，通过对Kubernetes集群中应用程序的状态可能出现的异常进行预测，从而及时发现状态异常的应用程序，提前采取措施，防患于未然，最终提高Kubernetes集群中部署的应用程序运行的稳定性和可靠性。

为了实现上述目的，本发明实施例采用的技术方案如下：

第一方面，本发明实施例提供了一种应用程序的状态预测方法，应用于服务器，服务器与Kubernetes集群通信，Kubernetes集群中的至少一个node节点运行有应用程序的至少一个服务，所述方法包括：获取应用程序的每一服务分别对应的性能状态监控信息和服务状态监控信息，其中，一个服务对应的性能状态监控信息为表征运行该服务的所述Kubernetes集群和/或运行该服务的node节点的硬件性能的信息，一个服务对应的服务状态监控信息为表征该服务的运行状态的信息；将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息；采用预先训练完成的状态预测模型对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果。

第二方面，本发明实施例还提供了一种应用程序的状态预测装置，应用于服务器，服务器与Kubernetes集群通信，Kubernetes集群中的至少一个node节点运行有应用程序的至少一个服务，所述装置包括获取模块、合并模块和预测模块。其中，获取模块用于获取应用程序的每一服务分别对应的性能状态监控信息和服务状态监控信息，其中，一个服务对应的性能状态监控信息为表征运行该服务的所述Kubernetes集群和/或运行该服务的node节点的硬件性能的信息，一个服务对应的服务状态监控信息为表征该服务的运行状态的信息；合并模块用于将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息；预测模块用于采用预先训练完成的状态预测模型对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果。

第三方面，本发明实施例还提供了一种服务器，所述服务器包括：一个或多个处理器；存储器，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现上述的应用程序的状态预测方法。

第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述应用程序的状态预测方法。

相对现有技术，本发明实施例提供的一种应用程序的状态预测方法及相关装置，在对应用程序的状态进行预测时，首先，获取表征运行该服务的所述Kubernetes集群和/或运行该服务的node节点的硬件性能的性能状态监控信息和表征该服务的运行状态的服务状态监控信息，然后，将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息；最后，采用预先训练完成的状态预测模型对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果。与现有技术相比，本发明实施例采用预先训练后的状态预测模型对应用程序的当前状态进行预测，以便及时发现应用程序的异常，防患于未然。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了Kubernetes集群的监控平台的架构示意图。

图2示出了本发明实施例提供的应用场景的方框示意图。

图3示出了本发明实施例提供的应用程序的状态预测方法的流程图。

图4示出了本发明实施例提供的状态预测模型的训练方法的流程图。

图5示出了本发明实施例提供的应用程序的状态预测装置的方框示意图。

图6示出了本发明实施例提供的服务器的方框示意图。

图标：10-master节点；20-node节点；30-服务器；31-存储器；32-通信接口；33-处理器；34-总线；200-应用程序的状态预测装置；201-获取模块；202-合并模块；203-预测模块；204-优化模块；205-训练模块。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本发明的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

Kubernetes集群由master节点和node节点组成，master节点是Kubernetes集群的控制中心，负责整个Kubernetes集群的管理和控制，node节点是负载节点，负责pod对应的容器的创建、启停等任务，同时与master节点密切协作，监控管理整个集群的状态，pod是一组容器的集合，也是Kubernetes集群调度的单位，同一个pod中的所有容器会被调度到Kubernetes集群中相同的node节点，不同pod可能被调度到Kubernetes集群中的任意node节点。

一个应用程序包含一个或多个服务，每个服务对应应用程序中相对独立的功能模块，由一个或多个pod提供，例如，web应用包含两个服务：前端页面和后台数据库，每个服务分别对应一个pod，每个pod负责实现对应服务的功能。

为了及时发现Kubernetes集群中出现异常的应用程序，通常由Kubernetes集群的性能监控平台监控运行应用程序的服务的Kubernetes集群和/或运行该服务的node节点的硬件性能的信息，例如，CPU的利用率、内存的使用率，文件系统和网络的统计信息等，并将这些监控信息以图表、曲线等直观的形式显示给运维人员，以便运维人员及时了解Kubernetes集群的运行状态、及时对发现的异常情况进行相应的处理。

图1示出了Kubernetes集群的监控平台的架构示意图，图1中，Kubernetes集群包括一个master节点10和多个node节点20，Kubernetes集群与一个独立的数据库InfluxDB通信，每个node节点20上运行监控模块cAdvisor，负责对本节点的硬件性能的信息进行实时监控和性能数据采集，例如，CPU使用情况、内存使用情况、网络吞吐量及文件系统使用情况等。监控信息汇总模块heapster可以运行在任意一个node节点20，heapster可以从master节点10处获取每个node节点20的地址信息，从每个node节点20获取其本地性能数据，再以服务为单位对所有node节点20上的性能数据进行汇总，得到每个服务对应的性能数据后存储在于InfluxDB数据库中，此处的数据库可以是InfluxDB，或者mySql等其他数据库，本发明对此不予限定，最后，采用专门的数据可视化工具将每个服务的性能数据进行可视化显示，数据可视化工具可以是Grafana，或者Kibana等其他实现数据可视化的工具，本发明对此不予限定。

上述方法虽然可以及时地将监控的性能数据展示给运维人员，以便运维人员及时了解Kubernetes集群的运行状态，在异常发生后，运维人员可以根据该运行状态及时制定异常解决方案，第一时间处理异常，将异常导致的损失降到最低，但是，在一些可靠性和实时性要求高的应用场景中，一旦异常导致部署的应用程序不可用造成业务中断，会造成严重后果。

为了防患于未然，本发明实施例提供了一种应用程序的状态预测方法及相关装置，在Kubernetes集群中的应用程序的状态出现异常前能及时给运维人员提供预测，以便运维人员根据预测结果做出相应的防御措施，避免异常的发生，下面将对此详细描述。

请参照图2，图2示出了本发明实施例提供的应用场景的方框示意图，图2是在图1的基础上改进而成，图2中，服务器30分别与master节点10、node节点20及数据库InfluxDB通信。

服务器30将第一监控策略下发至每个node节点20，每个node节点20上运行的cAdvisor模块根据第一监控策略对本地的硬件性能指标进行监控，一个服务对应的性能状态监控信息可以来自于Kubernetes集群的各node节点20的本地的硬件性能指标的监控数据，也可以来自于运行该服务的node节点20的本地的硬件性能指标的监控数据，同时，服务器30还将第二监控策略下发运行该服务的node节点20，运行该服务的node节点20上运行的cAdvisor模块根据第二监控策略对该服务的运行状态指标进行监控，并对服务状态监控信息进行采集。

需要说明的是，服务器30也可以对Kubernetes集群的各node节点20的本地的硬件性能指标的监控数据进行汇总，将汇总后的信息作为该服务的性能状态监控信息，还可以对Kubernetes集群的部分node节点20的本地的硬件性能指标的监控数据进行汇总，将汇总后的信息作为该服务的性能状态监控信息。

服务器30从master节点10获取应用程序对应的所有服务，从heapster模块获取其中每一服务的性能状态监控信息和服务状态监控信息，服务器30将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息，然后采用预先训练完成的状态预测模型对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果，而且，服务器30还会将当前运行状态信息存储至InfluxDB数据库。

服务器30对状态预测模型进行训练时，从master节点10获取应用程序对应的所有服务，从数据库InfluxDB中获取其中每一服务对应的当前运行状态信息，对当前运行状态进行进行标注处理，将该当前运行状态信息与其对应的标注信息作为一个训练数据，获取多个训练数据，利用多个训练数据，对状态预测模型进行训练，直至满足预设要求，得到训练完成状态预测模型。

当然，训练数据的获取方式也可以是：服务器30在获取到一个服务对应的性能状态监控信息和服务状态监控信息，并对该性能状态监控信息与该服务状态监控信息进行合并，得到该服务的当前运行状态信息时，对该当前运行状态信息进行标注处理，得到该服务对应的一个训练数据，并存储至数据库InfluxDB中。

请参照图3，图3示出了本发明实施例提供的应用程序的状态预测方法的流程图，该应用程序的状态预测方法包括以下步骤：

步骤S101，获取应用程序的每一服务分别对应的性能状态监控信息和服务状态监控信息。

在本实施例中，应用程序通常包括多个服务，每一服务的功能由一个或者多个pod提供，一个pod运行于一个node节点20，每个node节点20上运行的cAdvisor负责监控本节点的硬件性能的信息和运行的所有pod的服务状态监控信息。

在本实施例中，每一服务对应的性能状态监控信息可以是运行该服务的Kubernetes集群中各node节点20对本地的硬件性能指标进行监控得到的硬件性能的信息，也可以是运行该服务的node节点20对本地的硬件性能指标进行监控得到的硬件性能的信息，或者同时包括这两种硬件性能的信息。例如，运行服务a的Kubernetes集群共包括5个node节点20：1#节点～5#节点，其中，运行服务a的node节点20为：1#节点、3#节点和5#节点，硬件性能指标包括指标1、指标2和指标3，则服务a的性能状态监控信息包括：1#节点～5#节点的指标1对应的性能状态监控信息、1#节点～5#节点的指标2对应的性能状态监控信息汇总后的性能状态监控信息、1#节点的指标3对应的性能状态监控信息、3#节点的指标3对应的性能状态监控信息、5#节点的指标3对应的性能状态监控信息。性能状态监控信息包括、但不限于CPU使用率、内存使用率、每秒请求数、响应时间等。服务状态监控信息与之类似，区别在于监控策略不同，运行该服务的每个node节点20上的服务状态监控信息是依据第二监控策略对对应的服务的运行状态指标进行监控得到的。第二监控策略可以是用户依据具体的应用场景预先定义的，例如，10分钟内出现延迟超过1秒的次数等。

由于第二监控策略可以由用户根据需要进行自定义，使得服务状态监控信息获取方式更灵活，获取到的服务状态监控信息也更多样化，更符合实际场景的需要。

步骤S102，将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息。

在本实施例中，为了保证对每一服务的监控信息尽量考虑全面，使得预测的结果更准确，因此，将每一服务的性能状态监控信息与服务状态监控信息合并起来为该服务的当前运行状态信息，然后，对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果。合并的方式可以是，建立每一服务的性能状态监控信息与对应的服务状态监控信息之间的关联关系，针对每一服务，可以采用如下步骤：

首先，基于获取到的一个服务对应的性能状态监控信息携带的第一标识和服务状态监控信息携带的第二标识，建立该性能状态监控信息和服务状态监控信息之间的关联关系。

在本实施例中，可以根据第一标识，第二标识，一个服务的名称和获取该一个服务对应的性能状态监控信息和服务状态监控信息的时间点，建立该性能状态监控信息和服务状态监控信息之间的关联关系。其中，第一标识为表示该一个服务的性能状态监控信息的唯一标识，第二标识为表示该一个服务某个时间点的服务状态监控信息的唯一标识。

在本实施例中，作为一种具体实施方式，关联关系的建立过程可以是：将性能状态监控信息存入性能状态表，将服务状态监控信息存入服务状态表，使用一个状态总表将性能状态表和服务状态表进行合并，以建立性能状态监控信息和服务状态监控信息的关联关系。例如，表1为性能状态表，表2为服务状态表。

表1

表2

其中，表1中的MetricsID为服务名对应的服务在表1中的索引ID，即第一标识，表2中的StatusID为服务名对应的服务在表2中的索引ID，即第二标识。将表1和表2进行合并得到的表3。

表3

ID

服务名

命名空间

MetricsID

StatusID

根据表3，就可以找到表3中任意一个服务名对应的服务的性能状态监控信息和服务状态监控信息。例如，表3中的一条记录为：

ID	服务名	命名空间	MetricsID	StatusID
					1	A	A name space	10	5

需要服务A的状态监控信息时，首先在表3中找到服务A，然后根据MetricsID在表1中找到服务A的性能状态监控信息，根据StatusID在表2中找到服务A的服务状态监控信息，将服务A的性能状态监控信息和服务A的服务状态监控信息合并起来作为服务A的当前运行状态信息。

需要说明的是，只有同一个服务在同一个时间点获取的性能状态监控信息和服务状态监控信息才能进行合并。

其次，将已建立关联关系的该性能状态监控信息和服务状态监控信息作为该服务的当前运行状态信息。

步骤S103，采用预先训练完成的状态预测模型对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果。

在本实施例中，预先训练完成的状态预测模型是基于应用程序的所有服务的历史的运行状态监控信息，对预先建立的状态预测模型进行训练得到的。

需要说明的是，可以为一个应用程序构建一个状态预测模型，基于该应用程序的所有服务的历史的运行状态监控信息，对该模型进行训练，得到可以预测应用程序的运行状态的状态预测模型。也可以为一个应用程序中的每一服务构建一个状态预测模型，基于每一服务的历史的运行状态监控信息对该服务对应的状态预测模型进行训练，得到预测应用程序的每一服务的运行状态的状态预测模型，根据每一服务分别对应的运行状态预测结果，综合判断应用程序的运行状态预测结果。

在本实施例中，由于状态监控信息是实时收集的，所以在对预先建立的状态预测模型进行训练完成后，还可以基于预设的优化规则，依据新产生的历史运行状态信息对训练完成后的状态预测模型进行优化，以提高预测的准确率，因此，本实施例还包括步骤S104。

步骤S104，基于预设的优化规则，依据新的历史运行状态信息对训练完成的状态预测模型进行优化。

在本实施例中，预设的优化规则，可以是新的历史运行状态信息达到预设数量，例如，预设数量为100条，即新的历史运行状态信息达到100条时，基于新的100条历史运行状态信息对训练完成的状态预测模型进行优化。预设的优化规则也可以是达到预设的优化周期，预设的优化周期可以是一周，或者是一个月，例如，基于最近一周的历史运行状态信息对训练完成的状态预测模型进行优化。

在得到状态预测结果后，为了更直观地展示状态预测结果，并且对可能导致的异常的原因给用户较为明确地指示，使用户在防患于未然时可以做到有的放矢，提高预防的效率和准确性，本实施例还可以进一步对运行状态预测结果进行处理，具体包括：

第一，根据应用程序的运行状态预测结果，判断应用程序的运行状态是否异常。

在本实施例中，状态预测模型可以采用SVM算法训练得到，SVM算法本身就是一个二类分类器，因此，利用状态预测模型对应用程序的运行状态进行预测后得到的状态预测结果中，包含了应用程序的运行状态是否异常的信息。

第二，当应用程序的运行状态为异常时，根据状态预测结果中每个监控项的特征权重的高低对多个监控项进行排序。

在本实施例中，当前运行状态信息包括多个监控项，例如，CPU的利用率是一个监控项，内存的利用率是另一个监控项，并且，每个监控项在应用程序的运行状态出现异常时占的特征权重也不一样，例如，CPU的利用率的特征权重大于内存的利用率，则可以认为，CPU的利用率对于应用程序的影响大于内存的利用率，因此，在应用程序的运行状态预测为异常时，用户需要首先关注CPU的利用率，其次再关注内存的利用率。

在本实施例中，除了可以根据运行状态预测结果判断出应用程序的状态是否异常，而且，在判断结果为异常时，还可以从运行状态预测结果中得到每个监控项的特征权重，根据特征权重的高低对监控项进行排序，以便用户可以快速了解对应用程序影响最大的监控项，从而针对性地采取相应的措施，避免应用程序发生状态异常。

与现有技术相比，本发明实施例具有以下有益效果：

首先，可以根据应用程序的当前运行状态信息进行实时预测，对于可能出现的运行状态异常进行提前维护，有效避免应用程序异常导致的业务中断。

其次，可以根据实际场景需要自定义监控策略，获取服务状态监控信息，使得监控策略更灵活，预测考虑的监控信息更全面，预测结果更准确。

第三，可以根据新产生的历史的状态监控信息对训练完成后的状态预测模型进行优化，进一步提高预测的准确率。

第四，对每个应用程序均建立并训练一个状态预测模型，使得状态预测模型更有针对性，也更准确。

最后，预测为异常时，可以针对监控项的特征权重的高低对监控项进行排序，以便于用户在采取措施时更有针对性，提高提前维护的效率。

在本实施例中，为了得到一个预先训练完成的状态预测模型，本实施例还包括步骤S201-S203。

请参照图4，图4示出了本发明实施例提供的状态预测模型的训练方法的流程图，该方法包括以下步骤：

步骤S201，基于获取到的每一服务对应的当前运行状态信息对该当前运行状态信息进行标注处理，将该当前运行状态信息与其对应的标注信息作为一个训练数据。

在本实施例中，每一服务对应的当前运行状态监控信息在获取后存储于与Kubernetes集群通信数据库中，数据库可以是如图2中的InfluxDB，也可以是mysql等其他数据库，本发明对此不予限定。

在本实施例中，对该当前运行状态信息进行标注处理是对当前运行状态信息增加一个标注信息，该标注信息用于表征对应服务的运行状态，运行状态包括两种：正常和异常，例如，可以用1表示异常，-1表示正常。一个训练数据为：同一个时间点采集的、经过关联后的性能状态监控信息、服务状态监控信息和对应的标注信息。

步骤S202，获取多个训练数据，并利用多个训练数据，对状态预测模型进行训练。

步骤S203，当状态预测模型满足预设要求时，确定得到训练完成的状态预测模型。

在本实施例中，对预先建立的状态预测模型进行训练的过程采用的算法可以是支持向量机SVM算法、也可以是决策树算法、K近邻算法等等，下面以SVM算法为例，对训练步骤进行详细说明：

第一步，将获取到的每一服务对应的当前运行状态信息转换为与SVM适配的数值型数据，并对训练数据打上分类标签。

在本实施例中，由于当前运行状态监控信息中可以包含非数据型数据，例如，服务是否重启过，其对应的取值有两个：“是”和“否”，或者是“TRUE”和“FALSE”，此时，就需要对该取值进行转换，比如说，用数值“1”表示“是”，用数值“0”表示“否”。

每条转换后的当前运行状态监控信息对应一个数据点向量，即一条训练数据，所有的转换后的当前运行状态监控信息构成训练数据集。

第二步，设定分割超平面为w^Tx+b，其中，x表示训练数据集中的数据点向量，w为超平面的法向量，b为超平面的偏差。

在本实施例中，该分割超平面即状态预测模型，对状态预测模型的训练过程即是确定w和b取值的过程，将确定的w和b的取值代入w^Tx+b，即可得到训练后的状态预测模型。

求解最佳分割超平面的过程，即确定较佳的w和b的取值的过程。为了求解最佳分割超平面，首先计算训练数据集中的数据点到分割超平面的距离，例如，数据点A到分割超平面的距离公式为：

为了确定w和b的取值，需要找到具有最小间隔的数据点，并对该间隔最大化，即为求解：其中，label即为状态异常的值。转换该求解公式，令所有支持向量(即训练数据集中的数据点)的label·(w^Tx+b)均为1，那么可以通过求||w||^-1的最大值来得到最终w的取值。通过引入拉格朗日乘子法，在约束条件label·(w^Tx+b)≥1.0下，优化后的目标函数为：其中<x⁽ⁱ⁾,x^(j)>表示x⁽ⁱ⁾和x^(j)两个向量的内积，目标函数的约束条件为C≥α≥0，常数C用于控制“最大化间隔”和“保证大部分数据点的函数间隔小于1.0”这两个目标的权重。

可以使用SMO算法求解α和b，其求解思路为：先固定α_i之外的所有参数，然后求α_i上的极值。由于存在约束若固定α_i之外的其他参数，则α_i可以有其他变量导出，于是，每次选择两个变量α_i和α_j，并固定其他参数，由此，在参数初始化后，SMO不断执行如下步骤直至收敛：

选取一对需要更新的α_i和α_j；

固定α_i和α_j以外的参数，求解目标函数获得更新后的α_i和α_j。

当达到收敛条件时，即可根据求解出的α的值，最终求解出w和b的值。

由于SVM算法和SMO算法均是较为成熟的算法，本发明不再对具体算法的详细过程进行赘述。

第三步，将第二步得到的w和b的值代入分割超平面中，得到训练后的状态预测模型。

请参照图5，图5示出了本发明实施例提供的应用程序的状态预测装置200的方框示意图。应用程序的状态预测装置200包括获取模块201、合并模块202、预测模块203、优化模块204及训练模块205。

获取模块201，用于获取应用程序的每一服务分别对应的性能状态监控信息和服务状态监控信息，其中，一个服务对应的性能状态监控信息为表征运行该服务的所述Kubernetes集群和/或运行该服务的node节点的硬件性能的信息，一个服务对应的服务状态监控信息为表征该服务的运行状态的信息。

在本实施例中，若一个服务对应的性能状态监控信息为表征运行该服务的Kubernetes集群的node节点的硬件性能的信息，则一个服务对应的性能状态监控信息为运行该服务的Kubernetes集群中各node节点分别依据服务器下发的第一监控策略对本地的硬件性能指标进行监控得到的；若一个服务对应的性能状态监控信息为表征运行该服务的node节点的硬件性能的信息，则一个服务对应的性能状态监控信息为运行该服务的node节点依据服务器下发的第一监控策略对本地的硬件性能指标进行监控得到的；一个服务对应的服务状态监控信息为运行该服务的node节点依据服务器下发的第二监控策略对该服务的运行状态指标进行监控得到的。

合并模块202，用于将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息。

在本实施例中，作为一种实施方式，合并模块202具体用于：针对每一服务分别执行以下操作：基于获取到的一个服务对应的性能状态监控信息携带的第一标识和服务状态监控信息携带的第二标识，建立该性能状态监控信息和服务状态监控信息之间的关联关系；将已建立关联关系的该性能状态监控信息和服务状态监控信息作为该服务的当前运行状态信息。

预测模块203，用于采用预先训练完成的状态预测模型对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果。

优化模块204，用于基于预设的优化规则，依据新的历史运行状态信息对训练完成的状态预测模型进行优化。

训练模块205，用于基于获取到的每一服务对应的当前运行状态信息对该当前运行状态信息进行标注处理，将该当前运行状态信息与其对应的标注信息作为一个训练数据；获取多个训练数据，并利用多个训练数据，对状态预测模型进行训练；当状态预测模型满足预设要求时，确定得到训练完成的状态预测模型。

请参照图6，图6示出了本发明实施例提供的服务器30的方框示意图。服务器30可以是，但不限于，虚拟机、实体服务器、实体服务器上的虚拟机等能提供与所述服务器或者虚拟机有相同功能的实体或者虚拟的服务端。服务器30的操作系统可以是，但不限于，Windows系统、Linux系统等。所述服务器30包括存储器31、通信接口32、处理器33和总线34，所述存储器31、通信接口32和处理器33通过总线34连接，处理器33用于执行存储器31中存储的可执行模块，例如计算机程序。

其中，存储器31可能包含高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口32(可以是有线或者无线)实现该服务器30与数据库或者Kubernetes集群中node节点和master节点之间的通信连接。

总线34可以是ISA总线、PCI总线或EISA总线等。图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器31用于存储程序，例如图5所示的应用程序的状态预测装置200。应用程序的状态预测装置200包括至少一个可以软件或固件(firmware)的形式存储于所述存储器31中或固化在所述服务器30的操作系统(operating system，OS)中的软件功能模块。所述处理器33在接收到执行指令后，执行所述程序以实现本发明上述实施例揭示的应用程序的状态预测方法。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述应用程序的状态预测方法。

综上所述，本发明实施例提供一种应用程序的状态预测方法及相关装置，应用程序的状态预测方法应用于服务器，服务器与Kubernetes集群通信，Kubernetes集群中的至少一个node节点运行有应用程序的至少一个服务，所述方法包括：获取应用程序的每一服务分别对应的性能状态监控信息和服务状态监控信息，其中，一个服务对应的性能状态监控信息为表征运行该服务的所述Kubernetes集群和/或运行该服务的node节点的硬件性能的信息，一个服务对应的服务状态监控信息为表征该服务的运行状态的信息；将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息；采用预先训练完成的状态预测模型对应用程序的所有服务的当前运行状态信息进行处理，得到应用程序的运行状态预测结果。本发明实施例采用预先训练后的状态预测模型对应用程序的当前状态进行预测，以便及时发现应用程序的异常，防患于未然。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

Claims

1.一种应用程序的状态预测方法，应用于服务器，所述服务器与Kubernetes集群通信，其特征在于，所述Kubernetes集群中的至少一个node节点运行有应用程序的至少一个服务，所述方法包括：

获取所述应用程序的每一服务分别对应的性能状态监控信息和服务状态监控信息，其中，一个服务对应的性能状态监控信息为表征运行该服务的所述Kubernetes集群和/或运行该服务的node节点的硬件性能的信息，所述一个服务对应的服务状态监控信息为表征该服务的运行状态的信息；

将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息；

采用预先训练完成的状态预测模型对所述应用程序的所有服务的当前运行状态信息进行处理，得到所述应用程序的运行状态预测结果。

2.如权利要求1所述的方法，其特征在于，

若一个服务对应的性能状态监控信息为表征运行该服务的所述Kubernetes集群的node节点的硬件性能的信息，则所述一个服务对应的性能状态监控信息为运行该服务的所述Kubernetes集群中各node节点分别依据所述服务器下发的第一监控策略对本地的硬件性能指标进行监控得到的；

若一个服务对应的性能状态监控信息为表征运行该服务的node节点的硬件性能的信息，则所述一个服务对应的性能状态监控信息为运行该服务的node节点依据所述服务器下发的第一监控策略对本地的硬件性能指标进行监控得到的；

所述一个服务对应的服务状态监控信息为运行该服务的node节点依据所述服务器下发的第二监控策略对该服务的运行状态指标进行监控得到的。

3.如权利要求1所述的方法，其特征在于，所述将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息的步骤，包括：

针对每一服务分别执行以下操作：

基于获取到的一个服务对应的性能状态监控信息携带的第一标识和服务状态监控信息携带的第二标识，建立该性能状态监控信息和服务状态监控信息之间的关联关系；

将已建立关联关系的该性能状态监控信息和服务状态监控信息作为该服务的当前运行状态信息。

4.如权利要求1-3任一项所述的方法，其特征在于，在得到所述预先训练完成的状态预测模型之前，所述方法还包括：

基于获取到的每一服务对应的当前运行状态信息对该当前运行状态信息进行标注处理，将该当前运行状态信息与其对应的标注信息作为一个训练数据；

得到所述预先训练完成的状态预测模型的步骤包括：

获取多个训练数据，并利用所述多个训练数据，对所述状态预测模型进行训练；

当所述状态预测模型满足预设要求时，确定得到训练完成的状态预测模型。

5.如权利要求1所述的方法，其特征在于，所述方法还包括：

基于预设的优化规则，依据新的历史运行状态信息对所述训练完成的状态预测模型进行优化。

6.一种应用程序的状态预测装置，应用于服务器，所述服务器与Kubernetes集群通信，其特征在于，所述Kubernetes集群中的至少一个node节点运行有应用程序的至少一个服务，所述装置包括：

获取模块，用于获取所述应用程序的每一服务分别对应的性能状态监控信息和服务状态监控信息，其中，一个服务对应的性能状态监控信息为表征运行该服务的所述Kubernetes集群和/或运行该服务的node节点的硬件性能的信息，所述一个服务对应的服务状态监控信息为表征该服务的运行状态的信息；

合并模块，用于将每一服务对应的性能状态监控信息分别与该服务对应的服务状态监控信息进行合并，得到该服务的当前运行状态信息；

预测模块，用于采用预先训练完成的状态预测模型对所述应用程序的所有服务的当前运行状态信息进行处理，得到所述应用程序的运行状态预测结果。

7.如权利要求6所述的装置，其特征在于，若一个服务对应的性能状态监控信息为表征运行该服务的所述Kubernetes集群的node节点的硬件性能的信息，则所述一个服务对应的性能状态监控信息为运行该服务的所述Kubernetes集群中各node节点分别依据所述服务器下发的第一监控策略对本地的硬件性能指标进行监控得到的；

8.如权利要求6所述的装置，其特征在于，所述合并模块具体用于：

针对每一服务分别执行以下操作：

9.一种服务器，其特征在于，所述服务器包括：

一个或多个处理器；

存储器，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-5中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1-5中任一项所述的方法。