用于容器云平台的运维处理方法、装置及处理器与流程

1.本技术涉及平台运维领域，具体涉及一种用于容器云平台的运维处理方法、装置、处理器、机器可读存储介质以及计算机程序产品。


背景技术：

2.由于一个完整的容器云平台运用广泛、复杂程度高，容器云平台出现故障会引发许多的系统和应用问题，很难准确判断故障问题的出处，也不能及时给出解决故障问题的方法。
3.在当前传统数据中心中，容器云平台主要采用的运维方法是：一线运维人员根据监控系统发出的告警提示或者由一线运维人员每日巡检对容器云平台发生的故障进行运维处理。但一线运维人员解决问题的能力有限，需要二线运维人员或者研发人员介入处理，执行效率低，不能及时解决问题。且由于人工参与故障分析，准确度较低，不够及时。在故障问题得到解决后不能形成智能化故障处理解决方案，后续出现相同的问题时还需重新分析并处理，时间成本较高。


技术实现要素：

4.本技术实施例的目的是提供一种用于容器云平台的运维处理方法、装置、处理器、机器可读存储介质以及计算机程序产品。
5.为了实现上述目的，本技术第一方面提供一种用于容器云平台的运维处理方法，包括：获取容器云平台的监控数据以及告警数据；将监控数据和告警数据传输至故障处理引擎；通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件；调用与规则插件对应的执行引擎，以通过执行引擎采用pipeline的方式对监控数据和告警数据对应的故障问题进行处理，其中，pipeline包括多个并行执行或串行执行的任务。
6.在本技术实施例中，获取容器云平台的监控数据以及告警数据包括：获取通过prometheus采集的监控数据；获取通过alertmanager定义的告警规则所采集到的告警数据。
7.在本技术实施例中，通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件包括：通过故障处理引擎对监控数据和告警数据进行分析，以确定监控数据和告警数据的故障问题所对应的事件特征；根据事件特征，以责任链的模式遍历全部的插件，以确定出处理故障问题的规则插件，其中，每个插件对应一个故障问题和对应的解决方案。
8.在本技术实施例中，运维处理方法还包括：获取pipeline的执行结果并保存，并记录针对故障问题的处理信息。
9.在本技术实施例中，每个任务包括多个执行步骤，执行步骤之间以串行的方式执行。
10.在本技术实施例中，运维处理方法还包括：在对故障问题进行处理的过程中，发送
本地命令至nodeagent，nodeagent包括node节点；通过node节点执行本地命令。
11.在本技术实施例中，运维处理方法还包括：在无法登录node节点或无权限调用node节点的情况下，调用代理接口以发送本地命令至nodeagent，以通过node节点执行本地命令。
12.在本技术实施例中，每个插件均有对应的容器镜像、脚本和配置文件。
13.本技术第二方面提供一种处理器，被配置成执行上述的用于容器云平台的运维处理方法。
14.本技术第三方面提供一种用于容器云平台的运维处理装置，包括上述的处理器。
15.本技术第四方面提供一种机器可读存储介质，该机器可读存储介质上存储有指令，该指令在被处理器执行时使得所述处理器被配置成执行上述的用于容器云平台的运维处理方法。
16.本技术第五方面提供一种计算机程序产品，包括计算机程序，该计算机程序在被处理器执行时实现上述的任一项的用于容器云平台的运维处理方法。
17.通过上述技术方案，能够及时有效地找出故障问题，能够针对性地对故障问题进行分析，实现故障问题的自动化处理，进一步提高处理故障问题的效率与准确性。同时，通过插件的方式扩展故障问题，确保后续出现相同故障问题时可以快速有效地解决。
18.本技术实施例的其它特征和优点将在随后的具体实施方式部分予以详细说明。
附图说明
19.附图是用来提供对本技术实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本技术实施例，但并不构成对本技术实施例的限制。在附图中：
20.图1示意性示出了根据本技术实施例的用于容器云平台的运维处理方法的流程示意图；
21.图2示意性示出了根据本技术实施例的用于容器云平台的运维处理方法的原理示意图；
22.图3示意性示出了根据本技术实施例的计算机设备的内部结构图。
具体实施方式
23.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，应当理解的是，此处所描述的具体实施方式仅用于说明和解释本技术实施例，并不用于限制本技术实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
24.图1示意性示出了根据本技术实施例的用于容器云平台的运维处理方法的流程示意图。如图1所示，在本技术一实施例中，提供了一种用于容器云平台的运维处理方法，包括以下步骤：
25.步骤101，获取容器云平台的监控数据以及告警数据。
26.步骤102，将监控数据和告警数据传输至故障处理引擎。
27.步骤103，通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件。
28.步骤104，调用与规则插件对应的执行引擎，以通过执行引擎采用pipeline的方式对监控数据和告警数据对应的故障问题进行处理，其中，pipeline包括多个并行执行或串行执行的任务。
29.容器云平台可以指的是通过kubernetes实现的容器集群管理平台，可以提供资源管理、集群调度。弹性伸缩、服务发现等容器管理功能。kubernetes可以指的是一个可移植的、可扩展的开源平台。在对容器云平台的运维故障进行处理时，处理器可以先获取容器云平台的监控数据以及告警数据。其中，监控数据可以包括有容器云平台的资源信息、系统信息以及服务信息等。告警数据可以包括有告警目标、内存利用率以及cpu利用率。告警目标可以是虚拟机和容器等。pipeline可以指的是故障处理流水线。其中，pipeline可以包括多个并行执行或串行执行的任务。
30.在一个实施例中，获取容器云平台的监控数据以及告警数据包括：获取通过prometheus采集的监控数据；获取通过alertmanager定义的告警规则所采集到的告警数据。
31.具体地，处理器可以获取通过prometheus采集的监控数据。prometheus可以指的是一种常用于容器云平台的开源监控系统，可以根据配置的任务周期性地获取监控目标上的监控指标数据。prometheus可以按照相同的时序，并以时间维度存储采集到的连续的监控数据。处理器可以获取通过alertmanager定义的告警规则所采集到的告警数据。其中，alertmanager可以是指告警时间通知系统，可以支持通过邮件和短信等多种通信方式进行报警提示。alertmanager可以将告警数据进行分组管理，以将不同类型的告警信息发送至不同的用户或者系统。alertmanager定义的告警规则可以根据实际需求进行自定义。例如，可以将alertmanager的告警规则可以是在告警数据中的内存利用率大于90％和/或cpu利用率大于90％的情况下进行报警提示。
32.在获取到容器云平台的监控数据以及告警数据后，处理器可以将监控数据和告警数据传输至故障处理引擎。进一步地，prometheus可以对外提供应用程序接口，处理器可以通过prometheus对外提供的应用程序接口将监控数据传输至故障处理引擎。alertmanager可以自定义通知接口，处理器可以通过alertmanager的自定义通知接口将告警数据传输至故障处理引擎。
33.在将监控数据和告警数据传输至故障处理引擎的情况下，处理器可以通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件。在一个实施例中，通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件包括：通过故障处理引擎对监控数据和告警数据进行分析，以确定监控数据和告警数据的故障问题所对应的事件特征；根据事件特征，以责任链的模式遍历全部的插件，以确定出处理故障问题的规则插件，其中，每个插件对应一个故障问题和对应的解决方案。
34.处理器可以通过故障处理引擎对监控数据和告警数据进行分析，以确定监控数据和告警数据的故障问题所对应的事件特征。事件特征可以指的是告警目标和触发告警的条件信息。告警目标可以是虚拟机和容器等。触发告警的条件信息可以指的是容器云平台的内存利用率大于90％和/或cpu利用率大于90％等。
35.故障处理引擎可以包含有多个可以处理故障问题的规则插件。在规则插件中可以定义故障问题以及解决故障需要执行的任务，即，每个插件是可以对应一个故障问题和对应的解决方案。在一个实施例中，每个插件均有对应的容器镜像、脚本和配置文件，用于定义与之对应的插件在执行任务的每个步骤所需要做的事情。由于每个插件定义的故障问题以及对应的解决方案不同，在确定故障问题对应的事件特征的情况下，处理器可以根据事件特征，以责任链的模式遍历全部的插件，以确定出处理故障问题的规则插件。以责任链的模式遍历全部插件，即可以按照预设顺序将当前故障问题对应的事件特征与每个插件定义的故障问题对应的事件特征进行比对。在当前插件能够解决故障问题，即确认当前插件满足处理要求的情况下，可以确定当前插件为处理故障问题的规则插件。
36.例如，若故障处理引擎中包含有插件a、b以及c。a插件定义的故障问题对应的事件特征为虚拟机的内存利用率为92％，cpu利用率为93％。b插件定义的故障问题对应的事件特征为虚拟机的内存利用率为92％，cpu利用率为95％。c插件定义的故障问题对应的事件特征为容器的内存利用率为92％，cpu利用率为93％。而当前故障问题对应的事件特征为虚拟机的内存利用率为92％，cpu利用率为93％。因此，在处理器根据事件特征以责任链的模式遍历插件a、b以及c的情况下，可以确定处理故障问题的规则插件为a。
37.在确定对应处理的规则插件的情况下，处理器可以根据调用与规则插件对应的执行引擎，以通过执行引擎采用pipeline的方式对监控数据和告警数据对应的故障问题进行处理。其中，执行引擎可以指的是argo。argo可以指的是基于kubernetes的云原生流水线开源项目，可以为kubernetes提供本地容器运行的工作流，并将工作流中的每个步骤作为容器实现。pipeline可以指的是故障处理流水线。其中，pipeline可以包括多个并行执行或串行执行的任务。例如，在对前置条件进行检查时，可以采用并行的方式执行任务，以提高检查效率。在一个实施例中，每个任务包括多个执行步骤，执行步骤之间以串行的方式执行。pipeline中每个任务可以由多个执行步骤组成。每个步骤之间可以以串行的方式执行，以保证同一执行单元内的顺序执行逻辑。采用pipeline组合任务以及执行步骤的方式对故障问题进行处理，能够方便任务以及执行步骤的扩展和功能复用，方便后续pipeline应用之前的任务或者执行步骤。
38.在一个实施例中，运维处理方法还包括：获取pipeline的执行结果并保存，并记录针对故障问题的处理信息。
39.在通过执行引擎采用pipeline的方式对监控数据和告警数据对应的故障问题进行处理后，处理器可以获取pipeline的执行结果并保存，并记录针对故障问题的处理信息，以便后续对故障处理的完善与改进。
40.在一个实施例中，运维处理方法还包括：在对故障问题进行处理的过程中，发送本地命令至nodeagent，nodeagent包括node节点；通过node节点执行本地命令。
41.在对故障问题进行处理的过程中需要执行本地命令，若此时可以登录nodeagent上的node节点或者可以调用nodeagent上的node节点，则处理器可以通过node节点执行本地命令。其中，本地命令可以指的ip命令、lvm命令、docer命令等。nodeagent可以指的是节点代理。nodeagent可以包括有node节点，可以通过kubernetes资源控制器运行所有node节点，可以采集node节点上的故障信息。nodeagent还可以接收接口任务的调度，可以实现node节点以组件的故障修复功能。
42.在一个实施例中，运维处理方法还包括：在无法登录node节点或无权限调用node节点的情况下，调用代理接口以发送本地命令至nodeagent，以通过node节点执行本地命令。
43.在对故障问题进行处理的过程中需要执行本地命令，但此时无法登录nodeagent上的node节点或者无权限调用node节点，则处理器可以先调用代理接口以发送本地命令至nodeagent。然后，nodeagent可以通过封装本地命令，并可以以调用代理接口的方式触发nodeagent的node节点，以通过node节点执行本地命令。其中，代理接口可以指的是nodeagent的应用程序接口。
44.在一个实施例中，如图2所示，提供了一种用于容器云平台的运维处理方法的原理图示意图。
45.prometheus可以按照相同的时序，并以时间维度存储采集到的连续的监控数据。alertmanager可以提供定义告警规则采集告警数据。prometheus和alertmanager可以将采集到监控数据和告警数据传输至ruleengine，即故障处理引擎。ruleengine可以包含有多个规则插件。即，如图2所示的ruleplugin1和ruleplugin n等。其中，pipeline job即为pipeline任务的执行过程。
46.ruleengine可以对监控数据和告警数据进行分析，以确定监控数据和告警数据的故障问题所对应的事件特征。在确定故障问题对应的事件特征的情况下，ruleengine可以根据事件特征，以责任链的模式遍历全部的插件，以确定出处理故障问题的规则插件。在确定规则插件后，规则插件以crd的方式发起故障处理流水线，即如图2所示的pipeline。pipeline可以包括多个并行执行或串行执行的task。每个task包括多个step，step之间可以以串行的方式执行。在发起pipeline的情况下，可以通过调用与规则插件对应的argo对故障问题进行处理。argo可以指的是执行引擎。
47.如图2所示的nodeagent可以包括有node节点。当调用argo对故障问题进行处理的过程中需要执行本地命令，但此时无法登录nodeagent上的node节点或者无权限调用node节点时，则argo可以先调用nodeagent的api以发送本地命令至nodeagent。然后，nodeagent可以通过封装本地命令，并可以触发nodeagent的node节点，以通过node节点执行本地命令。
48.通过上述技术方案，能够及时有效地找出故障问题，能够针对性地对故障问题进行分析，实现故障问题的自动化处理，进一步提高处理故障问题的效率与准确性。同时，通过插件的方式扩展故障问题，确保后续出现相同故障问题时可以快速有效地解决。
49.图1为一个实施例中用于容器云平台的运维处理方法的流程示意图。应该理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
50.本技术实施例提供了一种处理器，处理器用于运行程序，其中，程序运行时执行上述用于容器云平台的运维处理方法。
51.本技术实施例提供了一种用于容器云平台的运维处理装置，包括上述的处理器。处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来实现对用于容器云平台的运维处理方法。
52.本技术实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现上述用于容器云平台的运维处理方法。
53.在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图3所示。该计算机设备包括通过系统总线连接的处理器a01、网络接口a02、存储器(图中未示出)和数据库(图中未示出)。其中，该计算机设备的处理器a01用于提供计算和控制能力。该计算机设备的存储器包括内存储器a03和非易失性存储介质a04。该非易失性存储介质a04存储有操作系统b01、计算机程序b02和数据库(图中未示出)。该内存储器a03为非易失性存储介质a04中的操作系统b01和计算机程序b02的运行提供环境。该计算机设备的数据库用于存储监控和告警等数据。该计算机设备的网络接口a02用于与外部的终端通过网络连接通信。该计算机程序b02被处理器a01执行时以实现一种用于容器云平台的运维处理方法。
54.本领域技术人员可以理解，图3中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
55.本技术实施例提供了一种设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：获取容器云平台的监控数据以及告警数据；将监控数据和告警数据传输至故障处理引擎；通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件；调用与规则插件对应的执行引擎，以通过执行引擎采用pipeline的方式对监控数据和告警数据对应的故障问题进行处理，其中，pipeline包括多个并行执行或串行执行的任务。
56.在一个实施例中，获取容器云平台的监控数据以及告警数据包括：获取通过prometheus采集的监控数据；获取通过alertmanager定义的告警规则所采集到的告警数据。
57.在一个实施例中，通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件包括：通过故障处理引擎对监控数据和告警数据进行分析，以确定监控数据和告警数据的故障问题所对应的事件特征；根据事件特征，以责任链的模式遍历全部的插件，以确定出处理故障问题的规则插件，其中，每个插件对应一个故障问题和对应的解决方案。
58.在一个实施例中，运维处理方法还包括：获取pipeline的执行结果并保存，并记录针对故障问题的处理信息。
59.在一个实施例中，每个任务包括多个执行步骤，执行步骤之间以串行的方式执行。
60.在一个实施例中，运维处理方法还包括：在对故障问题进行处理的过程中，发送本地命令至nodeagent，nodeagent包括node节点；通过node节点执行本地命令。
61.在一个实施例中，运维处理方法还包括：在无法登录node节点或无权限调用node节点的情况下，调用代理接口以发送本地命令至nodeagent，以通过node节点执行本地命令。
62.在一个实施例中，每个插件均有对应的容器镜像、脚本和配置文件。
63.本技术还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：获取容器云平台的监控数据以及告警数据；将监控数据和告警数据传输至故障处理引擎；通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件；调用与规则插件对应的执行引擎，以通过执行引擎采用pipeline的方式对监控数据和告警数据对应的故障问题进行处理，其中，pipeline包括多个并行执行或串行执行的任务。
64.在一个实施例中，获取容器云平台的监控数据以及告警数据包括：获取通过prometheus采集的监控数据；获取通过alertmanager定义的告警规则所采集到的告警数据。
65.在一个实施例中，通过故障处理引擎对监控数据和告警数据进行分析，以确定对应处理的规则插件包括：通过故障处理引擎对监控数据和告警数据进行分析，以确定监控数据和告警数据的故障问题所对应的事件特征；根据事件特征，以责任链的模式遍历全部的插件，以确定出处理故障问题的规则插件，其中，每个插件对应一个故障问题和对应的解决方案。
66.在一个实施例中，运维处理方法还包括：获取pipeline的执行结果并保存，并记录针对故障问题的处理信息。
67.在一个实施例中，每个任务包括多个执行步骤，执行步骤之间以串行的方式执行。
68.在一个实施例中，运维处理方法还包括：在对故障问题进行处理的过程中，发送本地命令至nodeagent，nodeagent包括node节点；通过node节点执行本地命令。
69.在一个实施例中，运维处理方法还包括：在无法登录node节点或无权限调用node节点的情况下，调用代理接口以发送本地命令至nodeagent，以通过node节点执行本地命令。
70.在一个实施例中，每个插件均有对应的容器镜像、脚本和配置文件。
71.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
72.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
73.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
74.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
75.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
76.存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。存储器是计算机可读介质的示例。
77.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
78.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
79.以上仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。