任务监控方法、装置、电子设备和存储介质与流程

1.本发明涉及任务监管技术领域，具体涉及一种kubernetes环境下的任务监控方法、装置、电子设备和存储介质。


背景技术：

2.随着云计算技术的不断成熟，容器技术逐步成为业界的发展热点，各主流云计算平台也无一例外地迅速提供了容器服务，kubernetes作为容器应用的管理中心，对集群内部所有容器的生命周期进行管理，结合自身的健康检查及错误恢复机制，实现了集群内部应用层的高可用性，容器集群提供强大便利的同时，如何有效地对集群内应用进行资源监控成为研究的重点。
3.目前，kubernetes作为云原生架构的核心基础设施，已经成为云原生应用的编排、调度、部署的标准。kubernetes可以承载无状态应用(deployment)、有状态应用(statefulset)、一次性任务(job)、周期性任务(cronjob)等各种类型的任务。
4.但是，在对任务的监控方面，传统的kubernetes社区提供了kube
‑
state
‑
metrics、prometheus等组件对kubernetes集群各种资源进行全面的监控。这对于有状态应用deployment和无状态应用statefulset，kube
‑
state
‑
metrics的监控指标比较完善；而对于job类型的任务，kube
‑
state
‑
metrics无法对其进行准且全面的监控。


技术实现要素：

5.为了解决现有技术中存在的上述问题，本技术实施方式提供了一种kubernetes环境下的任务监控方法、装置、电子设备和存储介质，可以实现对job类型的任务的全面监控。
6.第一方面，本技术的实施方式提供了一种kubernetes环境下的任务监控方法，包括：
7.通过第一组件获取n个组件发出的n个运行状态信息，其中，n个组件为在kubernetes环境下参与任务的生命周期的各个组件，n个运行状态信息用于标识n个运行状态信息对应的任务在生命周期中各个节点的运行状态，且n个组件与n个运行状态信息一一对应，n为大于或等于1的整数；
8.根据n个运行状态信息对n个运行状态信息对应的任务的运行状态进行监控。
9.在本技术的实施方式中，第一组件为kubernetes环境下的logstash组件；
10.因此，通过第一组件获取n个组件发出的n个运行状态信息，包括：
11.调用logstash组件通过消息队列获取n个组件发出的n个运行状态信息。
12.在本技术的实施方式中，在通过第一组件获取n个组件发出的n个运行状态信息之后，监控方法还包括：
13.通过第一组件将n个运行状态信息发送至数据库进行存储；
14.其中，数据库为clickhouse。
15.在本技术的实施方式中，根据n个运行状态信息确定n个运行状态信息对应的任务
的运行状态，包括：
16.通过grafana对n个运行状态信息进行展示，从而实现对n个运行状态信息对应的任务的监控。
17.第二方面，本技术的实施方式提供了一种kubernetes环境下的任务监控装置，包括：
18.获取模块，用于通过第一组件获取n个组件发出的n个运行状态信息，其中，n个组件为在kubernetes环境下参与任务的生命周期的各个组件，n个运行状态信息用于标识n个运行状态信息对应的任务在生命周期中各个节点的运行状态，且n个组件与n个运行状态信息一一对应，n为大于或等于1的整数；
19.监控模块，用于根据n个运行状态信息对n个运行状态信息对应的任务的运行状态进行监控。
20.在本技术的实施方式中，第一组件为kubernetes环境下的logstash组件；
21.因此，在通过第一组件获取n个组件发出的n个运行状态信息方面，获取模块，具体用于：
22.调用logstash组件通过消息队列获取n个组件发出的n个运行状态信息。
23.在本技术的实施方式中，监控装置还包括：
24.存储模块，用于在通过第一组件获取n个组件发出的n个运行状态信息之后，通过第一组件将n个运行状态信息发送至数据库进行存储；
25.其中，数据库为clickhouse。
26.在本技术的实施方式中，在根据n个运行状态信息确定n个运行状态信息对应的任务的运行状态方面，监控模块，具体用于：
27.通过grafana对n个运行状态信息进行展示，从而实现对n个运行状态信息对应的任务的监控。
28.第三方面，本技术实施方式提供一种电子设备，包括：处理器，处理器与存储器相连，存储器用于存储计算机程序，处理器用于执行存储器中存储的计算机程序，以使得电子设备执行如第一方面的方法。
29.第四方面，本技术实施方式提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序使得计算机执行如第一方面的方法。
30.第五方面，本技术实施方式提供一种计算机程序产品，计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，计算机可操作来使计算机执行如第一方面的方法。
31.实施本技术实施方式，具有如下有益效果：
32.可以看出，在本技术实施方式中，通过获取参与job类型的任务的生命周期中的各个节点的相关组件生成的运行状信息，对该任务的运行状态进行监控。相对于传统的kube
‑
state
‑
metrics、prometheus等组件，可以更加全面且精确的监控job类型任务的运行状态，从而在出现异常时，及时的进行异常分析、定位及处理。
附图说明
33.为了更清楚地说明本技术实施方式中的技术方案，下面将对实施方式描述中所需
要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
34.图1为本技术实施方式提供的一种kubernetes环境下的任务监控方法的流程示意图；
35.图2为本技术实施方式提供的一种在job类型的任务的等待中、运行中、执行完成时的监控的示意图；
36.图3为本技术实施方式提供的一种在job类型的任务由于内存溢出、超时退出、返回码错误等各类异常的监控告警的示意图；
37.图4为本技术实施方式提供的一种对历史的明细job任务进行分析查询的示意图；
38.图5为本技术实施方式提供的一种对任务的排队时长、实际执行时长进行监控的示意图
39.图6为本技术实施方式提供的一种对任务的内存进行监控和统计分析的示意图；
40.图7为本技术实施方式提供的一种kubernetes环境下的任务监控装置的功能模块组成框图；
41.图8为本技术实施方式提供的一种电子设备的结构示意图。
具体实施方式
42.下面将结合本技术实施方式中的附图，对本技术实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本技术一部分实施方式，而不是全部的实施方式。基于本技术中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本技术保护的范围。
43.本技术的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
44.在本文中提及“实施方式”意味着，结合实施方式描述的特定特征、结果或特性可以包含在本技术的至少一个实施方式中。在说明书中的各个位置出现该短语并不一定均是指相同的实施方式，也不是与其它实施方式互斥的独立的或备选的实施方式。本领域技术人员显式地和隐式地理解的是，本文所描述的实施方式可以与其它实施方式相结合。
45.目前，对于kubernetes环境，由于kubernetes本身的功能缺失，kube
‑
state
‑
metrics组件无法区分job类型的任务的pending、running等状态。在传统的监控中，无论job类型的任务处于何种状态，kubernetes均认为该job类型的任务处于running状态，即使该job类型的任务处于pending还未成功的状态。
46.同时，针对运行有大规模的job类型的任务的场景(例如在ai审图项目，每天的job类型的任务的数量高达数十万)，kubernetes的元数据存储etcd无法满足此类场景的压力，所以job类型的任务在运行完成之后的5min之内会加入清理机制，避免对etcd的压力。这导致kube
‑
state
‑
metrics组件对于job类型的任务complete的任务统计也是无效的。此外，由
于无法区分job类型的任务的实际运行状态，kube
‑
state
‑
metrics组件对于由内存溢出、超时导致失败的任务，也无法进行监控并报告。
47.基于此，本技术提出了一种在kubernetes环境下对于job类型的任务的监控方法，可以实现对job类型的任务全面且精准的监控，具体如下：
48.参阅图1，图1为本技术实施方式提供的一种kubernetes环境下的任务监控方法的流程示意图。该kubernetes环境下的任务监控方法包括以下步骤：
49.101：通过第一组件获取n个组件发出的n个运行状态信息。
50.在本实施方式中，n个组件为在kubernetes环境下参与任务的生命周期的各个组件。示例性的，n个组件可以包括：jobmanager组件、jobwoker组件、job容器和jobmonitor组件等。n个运行状态信息用于标识n个运行状态信息对应的任务在生命周期中各个节点的运行状态，且n个组件与n个运行状态信息一一对应，n为大于或等于1的整数。
51.示例性的，第一组件可以为kubernetes环境下的logstash组件，由logstash组件通过消息队列获取n个组件发出的n个运行状态信息。
52.以下，将以某个job类型的任务的整个生命周期为例，对步骤101的详细实现进行说明。
53.首先，由客户端将任务提交至kubernetes环境下的jobmanager组件，jobmanager组件收到任务之后，将任务信息发送到rabbitmq任务队列。同时，jobmanager组件生成任务queueing(排队中)的运行状态信息，并发送至到消息队列。
54.jobwoker组件持续对rabbitmq任务队列进行监听，当发现rabbitmq任务队列中收到任务信息后，jobwoker组件根据该任务信息创建新的job，并调用kubernetes接口，提交创建的新job。同时，jobwoker组件生成任务创建中的运行状态信息，并发送至到消息队列。
55.job容器等待kubernetes调度、启动、并开始执行创建的job任务，在job任务开始执行时，job容器生成任务running(运行中)的运行状态信息，并发送到消息队列；在job任务运行完成时，job容器生成任务success(运行成功)的运行状态信息，并发送到消息队列。
56.jobmonitor组件在job任务运行中时对job任务进行实时监控，在job任务由于超时、oom溢出等原因运行失败时，生成任务failed(失败)的运行状态信息，并发送到消息队列。
57.最后，由logstash组件实时收集消息队列中的运行状态信息。
58.在可选的实施方式中，jobmonitor组件使用开源kubernetes客户端组件进行开发，由此，可以保证任务即使因oom内存溢出、超时退出等错误，jobmonitor组件也能够产生相应的运行状态信息。
59.此外，在job任务在运行中，需要产生运行状态信息、内存占用信息，在本实施方式中，提供了一种实现产生运行状态信息、内存占用信息的关键逻辑，具体如下：
[0060][0061][0062]
在可选的实施方式中，运行状态信息可以是event事件，由此，job任务的生命周期中，提交排队、任务执行、任务完成、内存占用、执行时长等各个时期的数据均以event事件的形式实时输出到消息队列，使涉及job生命周期的任何事件都可以被捕捉到，实现了对job任务的全面监管。
[0063]
102：根据n个运行状态信息对n个运行状态信息对应的任务的运行状态进行监控。
[0064]
在本实施方式中，在步骤102之前，还可以通过第一组件将n个运行状态信息发送至数据库进行存储。由此，可以通过诸如grafana的可视化工具，对n个运行状态信息进行展示，从而实现对n个运行状态信息对应的任务的监控。
[0065]
示例性的，沿用上述job任务的示例，在logstash组件实时收集消息队列中的运行状态信息之后，logstash组件可以将收集到的运行状态信息发送到clickhouse中存储。
[0066]
具体而言，logstash组件可以监听rabbitmq数据源并将数据实时etl抽取到clickhouse(以http形式输出到clickhouse)，在本实施方式中，提供了一种实现上述抽取的关键逻辑，具体如下：
[0067][0068]
在本实施方式中，将运行状态数据存储至clickhouse后，可以通过在grafana中配置clickhouse数据源、各类监控仪表盘、各类告警仪表盘，从而将clickhouse中的各类运行状态信息根据其来源选取不同的监控仪表盘或告警仪表盘进行展示。
[0069]
在本实施方式中，各类仪表盘需要编写相应的查询sql完成，示例性的，查询最终
排队中的任务情况的查询sql关键逻辑如下：
[0070][0071]
由此，本技术提供的kubernetes环境下的任务监控方法支持在job类型的任务的等待中、运行中、执行完成时的监控，如图2所示；同时，也支持在job类型的任务由于内存溢出、超时退出、返回码错误等各类异常的监控告警，如图3所示。
[0072]
同时，由于所有任务的运行状态信息均存储在clickhouse中，本技术提供的kubernetes环境下的任务监控方法支持对历史的明细job任务进行分析查询，如图4所示，图4示出了一种查询过去24h内的所有异常任务的示意图。同样的，本技术提供的kubernetes环境下的任务监控方法还支持对任务的排队时长、实际执行时长进行监控，如图5所示；以及支持对任务的内存进行监控和统计分析，如图6所示。
[0073]
此外，在可选的实施方式中，clickhouse的数据存储空间如果受限，可以针对数据表数据设置ttl(即过期自动清理)，从而定期清理一些较长时间的运行状态信息，由此，可以保证大数据组件基本处于免运维状态。
[0074]
可以看出，在本技术实施方式中，通过获取参与job类型的任务的生命周期中的各个节点的相关组件生成的运行状信息，对该任务的运行状态进行监控。相对于传统的kube
‑
state
‑
metrics、prometheus等组件，可以更加全面且精确的监控job类型任务的运行状态，从而在出现异常时，及时的进行异常分析、定位及处理。同时，通过参与job类型的任务的生命周期中的各个节点的相关组件，将job类型的任务各个节点的运行状态信息发送至消息队列，再由logstash组件从消息队列进行拉取，实现了对大规模的job类型的任务执行场景下的实时监控告警。此外，本技术所提供的kubernetes环境下的任务监控方法，逻辑简单、易于实现，可以节省大量的资源成本。
[0075]
在可选的实施方式中，运维状态信息可以包括对应任务的任务标识、对应时期的
时期标识和时间戳。基于此，步骤102还可以通过以下方式实现：
[0076]
首先，在任务被提交至jobmanager组件后，系统可以根据该任务的信息，预先预测该任务会经过的节点，从而预测该任务对应的运行状态信息的数量。
[0077]
然后，对接收到的运行状态信息，按照其自身携带的任务标识进行分类。在检测到某个任务的任务结束状态信息后，判定接收到的该任务的运行状态信息的数量与预测的数量是否一致。若一致，则可以不用对该任务的运行状态信息进行分析，直接判定任务运行正常。若不一致，则对接收到的运行状态信息进行分析，确定是否出现异常情况。
[0078]
由此，可以实现对任务的快速分析，提高了kubernetes环境下对job类型的任务的监控效率。
[0079]
此外，在分析过程中，可以通过时间戳判定任务在运行过程中是否出现异常。示例性的，在预测接受到的任务会经过的节点时，还可以对其在每个节点的运行时间进行预测。由此，根据每个运行状态信息的时间戳，可以得到该任务在每个节点所运用的时间。结合事先预测的时间可以对出现异常的节点进行快速定位。
[0080]
具体而言，假定客户端提交了任务a，在接收到任务a后，根据任务a的任务信息对其经过的节点及每个节点所需的运行时间进行预测，得到：(节点1，2s)、(节点2，4s)、(节点3，10s)和(节点4，3s)共4对节点
‑
时间信息。在任务结束后，确认收到的运行状态信息为(接收，2021.02.21
‑
10:20:00)、(创建，2021.02.21
‑
10:20:02)、(开始运行，2021.02.21
‑
10:20:06)和(任务结束，2021.02.21
‑
10:20:36)。由此，可以看出该任务在节点3时的实际运行时间为30s，远大于预测的10s，因此，可以初步判定在该环节中，可能存在相关异常，优先对该环节的任务状态信息进行分析。
[0081]
参阅图7，图7为本技术实施方式提供的一种kubernetes环境下的任务监控装置的功能模块组成框图。如图7所示，该kubernetes环境下的任务监控装置700包括：
[0082]
获取模块701，用于通过第一组件获取n个组件发出的n个运行状态信息，其中，n个组件为在kubernetes环境下参与任务的生命周期的各个组件，n个运行状态信息用于标识n个运行状态信息对应的任务在生命周期中各个节点的运行状态，且n个组件与n个运行状态信息一一对应，n为大于或等于1的整数；
[0083]
监控模块702，用于根据n个运行状态信息对n个运行状态信息对应的任务的运行状态进行监控。
[0084]
在本发明的实施方式中，第一组件为kubernetes环境下的logstash组件；
[0085]
因此，在通过第一组件获取n个组件发出的n个运行状态信息方面，获取模块701，具体用于：
[0086]
调用logstash组件通过消息队列获取n个组件发出的n个运行状态信息。
[0087]
在本发明的实施方式中，监控装置还包括：
[0088]
存储模块703，用于在通过第一组件获取n个组件发出的n个运行状态信息之后，通过第一组件将n个运行状态信息发送至数据库进行存储；
[0089]
其中，数据库可以为clickhouse。
[0090]
在本发明的实施方式中，在根据n个运行状态信息确定n个运行状态信息对应的任务的运行状态方面，监控模块702，具体用于：
[0091]
通过grafana对n个运行状态信息进行展示，从而实现对n个运行状态信息对应的
任务的监控。
[0092]
参阅图8，图8为本技术实施方式提供的一种电子设备的结构示意图。如图8所示，电子设备800包括收发器801、处理器802和存储器803。它们之间通过总线804连接。存储器803用于存储计算机程序和数据，并可以将存储器803存储的数据传输给处理器802。
[0093]
处理器802用于读取存储器803中的计算机程序执行以下操作：
[0094]
通过第一组件获取n个组件发出的n个运行状态信息，其中，n个组件为在kubernetes环境下参与任务的生命周期的各个组件，n个运行状态信息用于标识n个运行状态信息对应的任务在生命周期中各个节点的运行状态，且n个组件与n个运行状态信息一一对应，n为大于或等于1的整数；
[0095]
根据n个运行状态信息对n个运行状态信息对应的任务的运行状态进行监控。
[0096]
在本发明的实施方式中，第一组件为kubernetes环境下的logstash组件；
[0097]
因此，在通过第一组件获取n个组件发出的n个运行状态信息方面，处理器802，具体用于执行以下操作：
[0098]
调用logstash组件通过消息队列获取n个组件发出的n个运行状态信息。
[0099]
在本发明的实施方式中，在通过第一组件获取n个组件发出的n个运行状态信息之后，监控方法还包括：
[0100]
通过第一组件将n个运行状态信息发送至数据库进行存储；
[0101]
其中，数据库可以为clickhouse。
[0102]
在本发明的实施方式中，在根据n个运行状态信息确定n个运行状态信息对应的任务的运行状态方面，处理器802，具体用于执行以下操作：
[0103]
通过grafana对n个运行状态信息进行展示，从而实现对n个运行状态信息对应的任务的监控。
[0104]
应理解，本技术中kubernetes环境下的任务监控装置可以包括智能手机(如android手机、ios手机、windows phone手机等)、平板电脑、掌上电脑、笔记本电脑、移动互联网设备mid(mobile internet devices，简称：mid)或穿戴式设备等。上述kubernetes环境下的任务监控装置仅是举例，而非穷举，包含但不限于上述kubernetes环境下的任务监控装置。在实际应用中，上述kubernetes环境下的任务监控装置还可以包括：智能车载终端、计算机设备等等。
[0105]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件结合硬件平台的方式来实现。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施方式或者实施方式的某些部分所述的方法。
[0106]
因此，本技术实施方式还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行以实现如上述方法实施方式中记载的任何一种kubernetes环境下的任务监控方法的部分或全部步骤。例如，所述存储介质可以包括硬盘、软盘、光盘、磁带、磁盘、优盘、闪存等。
[0107]
本技术实施方式还提供一种计算机程序产品，所述计算机程序产品包括存储了计
算机程序的非瞬时性计算机可读存储介质，所述计算机程序可操作来使计算机执行如上述方法实施方式中记载的任何一种kubernetes环境下的任务监控方法的部分或全部步骤。
[0108]
需要说明的是，对于前述的各方法实施方式，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施方式均属于可选实施方式，所涉及的动作和模块并不一定是本技术所必须的。
[0109]
在上述实施方式中，对各个实施方式的描述都各有侧重，某个实施方式中没有详述的部分，可以参见其他实施方式的相关描述。
[0110]
在本技术所提供的几个实施方式中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。
[0111]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。
[0112]
另外，在本技术各个实施方式中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件程序模块的形式实现。
[0113]
所述集成的单元如果以软件程序模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本技术各个实施方式所述方法的全部或部分步骤。而前述的存储器包括：u盘、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
[0114]
本领域普通技术人员可以理解上述实施方式的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器(英文：read
‑
only memory，简称：rom)、随机存取器(英文：random access memory，简称：ram)、磁盘或光盘等。
[0115]
以上对本技术实施方式进行了详细介绍，本文中应用了具体个例对本技术的原理及实施方式进行了阐述，以上实施方式的说明只是用于帮助理解本技术的方法及其核心思想；同时，对于本领域的一般技术人员，依据本技术的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本技术的限制。