CN116126621A - 大数据集群的任务监控方法及相关设备 - Google Patents
大数据集群的任务监控方法及相关设备 Download PDFInfo
- Publication number
- CN116126621A CN116126621A CN202211039280.8A CN202211039280A CN116126621A CN 116126621 A CN116126621 A CN 116126621A CN 202211039280 A CN202211039280 A CN 202211039280A CN 116126621 A CN116126621 A CN 116126621A
- Authority
- CN
- China
- Prior art keywords
- task
- node
- working node
- log
- working
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 130
- 238000000034 method Methods 0.000 title claims abstract description 72
- 230000002159 abnormal effect Effects 0.000 claims abstract description 188
- 238000012423 maintenance Methods 0.000 claims abstract description 135
- 238000004458 analytical method Methods 0.000 claims abstract description 115
- 238000012545 processing Methods 0.000 claims description 21
- 238000012806 monitoring device Methods 0.000 claims description 17
- 238000012216 screening Methods 0.000 claims description 12
- 230000000007 visual effect Effects 0.000 claims description 8
- 238000007726 management method Methods 0.000 description 90
- 230000006870 function Effects 0.000 description 22
- 230000008569 process Effects 0.000 description 13
- 238000010586 diagram Methods 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 8
- 238000011160 research Methods 0.000 description 8
- 230000005856 abnormality Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 230000009286 beneficial effect Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 238000007405 data analysis Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 238000013500 data storage Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000013079 data visualisation Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012800 visualization Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000007619 statistical method Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请公开了一种大数据集群的任务监控方法及相关设备。方法应用于运行有任务监控系统的电子设备中,任务监控系统包括数据包捕获工具、运行监控工具以及运维子系统,大数据集群包括管理节点和工作节点,数据包捕获工具部署于管理节点,运行监控工具部署于工作节点中,方法包括:通过数据包捕获工具获取工作节点向管理节点发送的心跳数据包;若基于心跳数据包确定工作节点为异常工作节点,则通过运行监控工具获取工作节点的任务运行日志;通过运维子系统,基于预设任务分析策略和工作节点的任务运行日志,确定工作节点中的异常运行任务。
Description
技术领域
本申请涉及大数据技术领域,尤其涉及一种大数据集群的任务监控方法及相关设备。
背景技术
随着业务发展和时间推移,传统的关系型数据库在性能和容量方面难以支撑海量的数据存储及数据分析等需求,以分布式文件系统(Hadoop Distributed File System,HDFS)为代表的大数据集群应运而生。大数据集群通常包括管理节点和多个工作节点,每个工作节点在管理节点的控制下执行相应任务,以满足海量的数据存储及数据分析等需求。受到各种因素的影响,工作节点时长会出现异常,若大数据集群中的异常工作节点数量达到一定阈值,就会出现数据库丢失,导致大数据集群失去对外提供数据服务的能力。此时,就需要快速识别大数据集群中异常的工作节点及导致该工作节点异常的运行任务,以便及时恢复大数据集群的数据服务能力。
目前,传统的大数据集群监控方案是由人工采集各类相关数据再进行人工判研。但是,这种方案不仅费时费力、浪费运维人员成本,还受限于人为经验和熟练程度,无法保证采集数据的时效性、准确性和全面性,进而无法保证监控时效性和准确性。
发明内容
本申请实施例提供一种大数据集群的任务监控方法及相关设备,用于解决传统的异常分析方案存在的费时费力、浪费运维人员成本依据无法保证最终识别结果的准确性的问题。
为了实现上述目的,本申请实施例采用下述技术方案:
第一方面,本申请实施例提供一种大数据集群的任务监控方法,应用于运行有任务监控系统的电子设备中,所述任务监控系统包括数据包捕获工具、运行监控工具以及运维子系统,所述大数据集群包括管理节点和工作节点,所述数据包捕获工具部署于所述管理节点,所述运行监控工具部署于所述工作节点中;所述方法包括:
通过所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包;
若基于所述心跳数据包确定所述工作节点为异常工作节点,则通过所述运行监控工具获取所述工作节点的任务运行日志;
通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点的异常运行任务。
第二方面,本申请实施例提供一种大数据集群的任务监控装置,应用于运行有任务监控系统的电子设备中,所述任务监控系统包括数据包捕获工具、运行监控工具以及运维子系统,所述大数据集群包括管理节点和工作节点,所述数据包捕获工具部署于所述管理节点,所述运行监控工具部署于所述工作节点中;所述装置包括:
获取单元,用于所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包;
所述获取单元,还用于若基于所述心跳数据包确定所述工作节点为异常工作节点,则通过所述运行监控工具获取所述工作节点的任务运行日志;
确定单元,用于通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
第三方面,本申请实施例提供一种电子设备,包括:
处理器;
用于存储所述处理器可执行指令的存储器;
其中,所述处理器被配置为执行所述指令,以实现如第二方面所述的方法。
第四方面,本申请实施例提供一种计算机可读存储介质,当所述存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行如第一方面所述的方法。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
利用大数据集群中的工作节点与管理节点之间的心跳机制,通过在大数据集群中的管理节点部署数据包捕获工具,可以自动获取大数据集群中的工作节点向管理节点发送的心跳数据包,将获取的心跳数据包提供给运维子系统,使得运维子系统能够根据工作节点向管理节点发送的心跳数据包,准确识别工作节点是否异常;利用运行监控工具的日志采集及上报功能,在大数据集群的工作节点部署运行监控工具,可以自动获取大数据集群中的工作节点的任务运行日志,由于各个工作节点的任务运行日志记录了各种的运行任务的相关情况,通过将获取的任务运行日志提供给运维子系统,并预先在运维子系统中配置相应的任务分析策略,使得运维子系统基于异常工作节点的任务运行日志和预设任务分析策略,即可准确地确定异常工作节点的异常运行任务,实现对异常工作节点及其异常原因的自动化监控,整个过程无需人工参与数据采集及研判,不仅可以提高监控效率、节省运维人员成本,还可以极大程度的降低对人为经验和熟练程度的依赖,有利于提高监控和准确性。另外,通过数据包捕获工具可以保证获取的心跳数据包的时效性,通过运行监控工具可以保证获取的任务运行日志的时效性,进而有利于提高监控时效性,在工作节点有异常的苗头时提前介入采集相关信息和识别,从而可以大大提高大数据集群的稳定性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请的一个实施例提供的一种大数据集群的任务监控系统的结构示意图;
图2为本申请的另一个实施例提供的一种大数据集群的任务监控系统的结构示意图;
图3为本申请的又一个实施例提供的一种大数据集群的任务监控系统的结构示意图;
图4为本申请的一个实施例提供的一种大数据集群的任务监控方法的流程示意图;
图5为本申请的另一个实施例提供的一种大数据集群的任务监控方法的流程示意图;
图6为本申请的一个实施例提供的一种大数据集群的任务监控装置的结构示意图;
图7为本申请的一个实施例提供的一种电子设备的结构示意图。
附图标记说明:
11-数据包捕获工具、12-运行监控工具、13-运维子系统、14-存储平台、
131a-第一运维节点、131b-第二运维节点、132-日志采集节点、133-消息队列集群、134-日志分析节点、135-告警节点、
21-管理节点、22-工作节点。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象,而不用于描述特定的顺序或先后次序。应理解,这样使用的数据在适当情况下可以互换,以便本申请实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,本说明书和权利要求书中“和/或”表示所连接对象的至少其中之一,字符“/”一般表示前后关联对象是一种“或”的关系。
部分概念说明:
HDFS:Hadoop分布式文件系统,是指被设计成适合运行在通用硬件(CommodityHardware)上的分布式文件系统(Distributed File System)。
NameNode:HDFS大数据集群的管理节点,主要作用为HDFS大数据集群的元数据的管理。它维护着文件系统树及整棵树内所有的文件和目录,同时也记录着每个文件中各个块所在的数据节点信息。
DataNode:HDFS大数据集群的工作节点,负责实际的底层的文件的读写,如果客户端程序发起了读HDFS文件的命令,那么首先将这些文件分成数据块,然后管理节点将告知客户端这些数据块是存储在哪些DataNode上之后,客户端将直接和DataNode交互。
YARN:是一种大数据计算资源管理器,它是一个通用资源管理系统,可为上层应用提供统一的资源管理和调度,它的引入为HDFS大数据集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
Cloudera Manageer:集合了集群部署、集群监控、集群配置变更等功能的大数据集群管理工具。
IOTOP:一款Linux操作系统上用于查询当前磁盘IO使用情况的工具,能够查询出磁盘IO消耗的TOP进程。
IOSTAT:一款Linux操作系统上用于查询当前磁盘IO使用情况的工具,能够查询当前各磁盘IO使用率、读写速率、读写等待时长。
JSTACK:一款分析Java服务的实时线程运行情况的工具,能够查询到Java服务内部各线程的运行状态。
TOP:一款Linux操作系统上用于实时查询中央处理器(Central ProcessingUnit,CPU)、内存消耗情况的工具,可以查询出各服务的CPU、内存消耗排名及详细服务进程信息等。
ELK:是一套针对日志数据做解决方案的框架,分别代表了三款产品,即,E:ElasticSearch(ES),负责日志的存储和检索;L:Logstash,负责日志的收集、过滤和格式化;K:Kibana,负责日志的展示统计和数据可视化。
Filebeat:是一款轻量型日志采集工具,可以安装在各个节点上,根据配置读取对应位置的日志,并上报到相应的地方去。
运维节点:复杂的信息技术(Information Technology,IT)系统都是由成百上千台主机构成的集群,此时需要一台机器用于管理集群内所有节点,这台主机被称为运维节点。
Tcpdump:一款网络数据包捕获工具,可以实时捕获指定主机网卡、指定IP地址和端口号上进出的数据包,并将其存储成数据包文件。
Prometheus:是一套开源的监控、报警、时间序列数据库的组合。
Grafana:是一款开源数据可视化工具,可以做数据监控和数据统计,带有告警功能。
如前所述,传统的大数据集群监控方案是由人工采集各类相关数据再进行人工判研。但是,这种方案不仅费时费力、浪费运维人员成本,还受限于人为经验和熟练程度,无法保证采集数据的时效性、准确性和全面性,进而无法保证监控时效性和准确性。
考虑到大数据集群中的工作节点与管理节点之间维持有心跳机制,也即工作节点每间隔一定时长会向管理节点发送一个心跳数据包,当工作节点出现异常时,比如网络故障、硬件故障、系统资源异常等,就会造成工作节点丢失心跳,当丢失心跳超过一定时长后,就会造成工作节点与管理节点失联,基于此,本申请实施例旨在提出一种大数据集群的任务监控方法,利用大数据集群中的工作节点与管理节点之间的心跳机制,通过在大数据集群中的管理节点部署数据包捕获工具,可以自动获取大数据集群中的工作节点向管理节点发送的心跳数据包,且可以保证获取的心跳数据包的时效性,将获取的心跳数据包提供给运维子系统,使得运维子系统能够根据工作节点向管理节点发送的心跳数据包,及时、准确识别工作节点是否异常;利用运行监控工具的日志采集及上报功能,在大数据集群的工作节点部署运行监控工具,可以自动获取大数据集群中的工作节点的任务运行日志,且可以保证获取的任务运行日志的时效性,由于各个工作节点的任务运行日志记录了各种的运行任务的相关情况,通过将获取的任务运行日志提供给运维子系统,并预先在运维子系统中配置相应的任务分析策略,使得运维子系统基于异常工作节点的任务运行日志和预设任务分析策略,即可及时、准确地确定异常工作节点的异常运行任务,实现对异常工作节点及其异常原因的自动化监控,整个过程无需人工参与数据采集及研判,不仅可以提高监控效率、节省运维人员成本,还可以极大程度的降低对人为经验和熟练程度的依赖,有利于提高采集数据的时效性、准确性和全面性,从而有利于提高监控时效性和准确性。
以下结合附图,详细说明本申请各实施例提供的技术方案。
请参见图1,为本申请的一个实施例提供的一种大数据集群的任务监控系统的结构示意图,该任务监控系统包括:数据包捕获工具11、运行监控工具12和运维子系统13。
本申请实施例中,大数据集群通常包括管理节点21和多个工作节点22,每个工作节点22在管理节点21的控制下执行相应任务,以满足海量的数据存储及数据分析等需求。每个工作节点22与管理节点21之间均维持有心跳机制,也即每个工作节点22每间隔一定时长会向管理节点21发送一个心跳数据包。
数据包捕获工具11是指具有数据包捕获功能的工具。在工作节点22出现异常的情况下,比如网络故障、硬件故障、系统资源异常等,就会造成工作节点22丢失心跳,当丢失心跳超过一定时长后,就会造成工作节点22与管理节点21失联。基于此,数据包捕获工具11可部署于管理节点21,其可用于获取大数据集群中的工作节点22向管理节点21发送的心跳数据包,且获取的心跳数据包具有一定的时效性,将获取的心跳数据包提供给运维子系统13,有利于运维子系统13能够及时、准确识别工作节点22是否异常。
实际应用中,数据包捕获工具11可以包括任意具有数据包捕获功能的工具,具体可根据实际需要进行选择,本申请实施例对此不作限定。例如,数据包捕获工具11可以包括Tcpdump等。
另外,数据包捕获工具11可以通过任意适当的方式将来自工作节点22的心跳数据包提供给运维子系统13。可选地,数据包捕获工具11也可以间接将捕获的来自工作节点22的心跳数据包发送给运维子系统13。示例地,如图2和图3所示,大数据集群的任务监控系统还包括存储平台14,数据包捕获工具11将获取的来自工作节点22的心跳数据包存储至存储平台14,相应地,运维子系统13从存储平台获取工作节点向管理节点发送的心跳数据包。
其中,存储平台14可以具有任意适当的结构,本申请实施例对此不作限定。示例地,存储平台14可以为网络文件系统(Network File System,NFS),由此可以实现心跳数据包的远程存储和共享,减少对本地存储资源的消耗。
可以理解的是,通过在数据包捕获工具11与运维子系统13之间增设存储平台14,不仅可以缓解运维子系统13的处理压力,还可以降低数据包捕获工具11获取的心跳数据包丢失的风险,进而使得大数据集群在其自愈能力作用下很快便可恢复正常。具体地大数据集群的自愈能力为:大数据集群中的数据块为多副本机制,当数据块副本低于集群设置的副本数时,会触发大数据集群的块副本自动复制补齐机制,保证数据块在大部分时候都为大数据集群设置的数量;而失联工作节点上的数据块将成为冗余块,冗余块会被很快清理掉,清掉后客户端到失联工作节点请求量会大量下降,则失联工作节点的IO负载会大量下降,进而有利于失联工作节点的快速恢复。
可选地,数据包捕获工具11也可以直接将捕获的来自工作节点22的心跳数据包发送给运维子系统13,从而有利于提高来自工作节点22的心跳数据包的时效性。
运行监控工具12是指具有日志采集及上报功能的工具,其部署于工作节点22。具体而言,运行监控工具12的数量可以为多个,一个运行监控工具12对应部署于大数据集群中的一个工作节点22上,其可用于获取所在工作节点22的运行任务日志并提供给运维子系统13,且获取的运行任务日志具有一定的时效性。
实际应用中,运行监控工具可以包括任意具有日志采集及上报功能的工具,具体可根据实际需要进行选择,本申请实施例对此不作限定。例如,运行监控工具可以包括但不限于:IOTOP、IOSTAT、JSTACK、TOP等,在本申请实施例中,IOTOP可以获取所在工作节点22的磁盘IO消耗情况等运行状态数据,IOSTAT可以获取所在工作节点22的磁盘IO使用率、读写速率、读写等待时长等运行状态数据,JSTACK可以获取所在工作节点22的各线程的运行状态等运行状态数据,TOP可以获取所在工作节点22的各线程的CPU消耗情况、内存消耗情况等运行状态数据。当然,应理解,每个工作节点22上都可以部署上述全部运行监控工具,或者,不同工作节点22上部署不同的运行监控工具,或者,一部分工作节点22上部署上述全部运行监控工具,而另一部分工作节点22上部署上述部分运行监控工具,等等。
另外,运行监控工具12可以周期性地获取所在工作节点22的任务运行日志,并提供给运维子系统13;或者,运维子系统13也可以在识别出异常工作节点的情况下,控制部署于异常工作节点的运行监控工具12获取该异常工作节点的任务运行日志。
值得说明的是,由于运维子系统13对每个工作节点22的异常识别和异常任务分析的具体实现过程类似,下面仅以一个工作节点为例进行说明。
由于出现异常的工作节点通常丢失心跳,导致数据包捕获工具11无法获取到该工作节点发送给管理节点21的心跳数据包,运维子系统13可用于基于工作节点22向管理节点发送的心跳数据包,确定工作节点是否为异常工作节点。
可选地,考虑到网络延时等各种因素的影响,工作节点22在正常情况下发送给管理节点21的心跳数据包可能存在一定延时,但若工作节点22向管理节点21发送的心跳数据包存在较大延时,甚至管理节点21未接收到工作节点22发送的心跳数据包,则可以判定工作节点22出现异常,基于此,为了实现对工作节点22发送的心跳数据包的全面监控,以准确识别工作节点22是否为异常工作节点,部署于管理节点21的数据包捕获工具11可以按照预设间隔时长,周期性地获取工作节点22向管理节点21发送的心跳数据包。相应地,运维子系统可用于在数据包捕获工具11相邻两次获取到来自工作节点22的心跳数据包之间的间隔时长超过预设间隔时长的情况下,确定工作节点22为异常工作节点。
其中,预设间隔时长可以根据实际需要进行设置,本申请实施例对此不作限定。示例地,若工作节点22每隔3秒向管理节点21发送一个心跳数据包,那么,预设间隔时长可以设置为2分钟,由此,数据包捕获工具11每隔2分钟获取工作节点22向管理节点21发送的心跳数据包,若数据包捕获工具11当前获取心跳数据包相较于上一次获取心跳数据包的时间间隔超过2分钟,则可确定工作节点22为异常工作节点。
本申请实施例在此示出了运维子系统13基于数据包捕获工具11获取的心跳数据包识别异常工作节点的一种具体实现方式。当然,应理解,上述运维子系统13也可以通过其他实现方式,基于数据包捕获工具11获取的心跳数据包识别异常工作节点,比如若数据包捕获工具11在当前时刻之前的指定时间段内获取的来自工作节点22的心跳数据包数量小于预设数量阈值,则可以确定工作节点22为异常工作节点,等等。其中,预设数量阈值可以根据实际需要进行设置,本申请实施例对此不作限定。
由于工作节点的任务运行日志记录了各种的运行任务的相关情况,运维子系统13在识别出异常工作节点之后,还可基于异常工作节点的任务运行日志和预设任务分析策略,确定异常工作节点的异常运行任务,该异常运行任务即为导致工作节点异常的运行任务。
其中,预设任务分析策略是指预先设置的、用于异常任务分析的策略,具体内容可以根据实际需要进行选择,本申请实施例对此不作限定。
示例地,预设任务分析策略可根据运行监控工具12获取的运行任务日志进行设置。考虑到为实现对工作节点22的全面监控,工作节点22的任务运行日志通常包括工作节点22中多个运行任务的运行状态信息,该运行状态信息包括每个运行任务对应的多个运行状态数据,一个运行状态数据对应一个分析维度。例如,工作节点22中每个运行任务的多个运行状态数据可以包括但不限于工作节点22中每个运行任务的磁盘IO消耗情况、磁盘IO使用率、磁盘IO的读写速率、磁盘IO的读写等待时长、各线程的运行状态等。需要说明的是,工作节点22可运行有至少一个任务,也即工作节点22具有至少一个运行任务,每个运行任务均具有对应的多个运行状态数据。
在此情况下,可选地,异常任务分析策略可以包括每个分析维度对应的基准参考数据。相应地,运维子系统可针对异常工作节点22的每个运行任务,将该运行任务的每个运行状态数据与每个运维状态数据所对应维度的基准参考数据进行比对,得到每个运行状态的比对结果,进一步基于该运行任务的每个运行状态数据对应的比对结果,确定该运行任务是否为异常运行任务。示例地,若异常工作节点22的某个运行任务的多个运维状态数据中,有超过半数的运维状态数据超过对应维度的基准参考数据,则可确定该运行任务为异常工作节点22的异常运行任务。
可选地,为了提高异常运行任务的识别效率,预设任务分析策略可以包括目标筛选条件和目标分析维度,其中,目标筛选条件用于对异常工作节点的运行任务进行初筛,得到可能异常的运行任务;目标分析维度用于对筛选出的运行任务进行分析,确定异常工作节点的异常运行任务。具体而言,运维子系统13可基于异常工作节点中多个运行任务的运行状态信息,从异常工作节点的多个运行任务中满足目标筛选条件的运行任务,作为候选运行任务,以及基于候选运行任务的目标运行状态数据,确定候选运行任务是否为异常工作节点的异常运行任务,其中,目标运行状态数据与目标分析维度对应。
更为具体地,预设任务分析策略还包括目标排序条件。相应地,上述基于候选运行任务的目标运行状态数据,确定候选运行任务是否为工作节点的异常运行任务,具体包括:若候选运行任务对应的目标运行状态数据满足目标排序条件,则确定候选运行任务为工作节点中的异常运行任务。
其中,目标筛选条件可以包括目标分析维度对应的基准指标数据,目标分析维度可以为上述多个运行状态数据对应的维度中的部分或全部维度,具体可根据实际需要进行选择,本申请实施例对此不作限定。目标排序条件可以包括排序方式及基准排列位置。
示例地,目标筛选条件可以磁盘IO使用率>95%、运行任务的类型为来自资源管理器的调度任务,目标分析维度可以为磁盘IO使用率;目标排序条件可以为按照磁盘IO使用率从高到低的顺序排列的前N位(N为正整数)。进一步,可从异常工作节点的运行任务中选取磁盘IO使用率大于95%的运行任务,作为候选运行任务;若选取出的候选运行任务为一个,则可将该候选运行任务确定为异常运行任务;若选取出的候选运行任务为多个,则可对这些候选运行任务按照磁盘IO使用率高低进行排序,选取磁盘IO使用率最高的N个候选运行任务,确定为异常运行任务。
本申请实施例在此示出了运维子系统13确定异常工作节点的异常运行任务的一种具体实现方式。当然,应理解,上述运维子系统13也可以通过其他实现方式,确定异常工作节点的异常运行任务,本申请实施例对此不作限定。
本申请实施例中,运维子系统13可以具有任意适当的架构,具体可根据实际需要进行设置,本申请实施例对此不作限定。
可选地,如图2所示,运维子系统13包括第一运维节点131a、日志采集节点132、消息队列集群133和日志分析节点134。
其中,第一运维节点131a可用于基于工作节点22向管理节点21发送的心跳数据包,确定工作节点22是否为异常工作节点。实际应用中,第一运维节点131a可以用于管理大数据集群内所有节点的一台主机。
日志采集节点132可用于从运行监控工具12获取工作节点22的任务运行日志并发送给消息队列集群133。实际应用中,日志采集节点132中可以部署采用任意适当的、具有日志采集和转发功能的工具,示例地,日志采集节点132中可以部署Filebeat,其可以根据配置读取运行监控工具12获取的任务运行日志,并发送给消息队列集群133。
消息队列集群133用于接收日志采集节点132发送的工作节点22的任务运行日志,以及从工作节点22的任务运行日志中,获取日志分析节点134订阅的任务运行日志并发送给日志分析节点134。实际应用中,消息队列集群133可以采用任意适当的、具有消息订阅发布功能的集群,示例地,消息队列集群可以为Kafka集群,由于Kafka集群具有高吞吐量和强大的动作流数据处理能力,可以提高任务运行日志在日志采集节点132与日志分析节点134之间的流转速度,有利于提升工作节点22的任务运行日志的失效性。
日志分析节点134可向消息队列集群133订阅大数据集群中的异常工作节点的任务运行日志,以及基于预设任务分析策略和异常工作节点的任务运行日志,确定异常工作节点的异常运行任务。
实际应用中,日志分析节点134可以具有任意适当的结构,具体可根据实际需要进行设置,本申请实施例对此不作限定。示例地,为了提高日志分析节点134的性能,日志分析节点134中可部署有日志处理工具、存储单元和可视化分析工具。其中,日志处理工具用于向消息队列集群133订阅大数据集群中的异常工作节点的任务运行日志,并将异常工作节点的任务运行日志保存至存储单元中;可视化分析工具用于从存储单元获取异常工作节点的任务运行日志,以及基于预设任务分析策略和异常工作节点的任务运行日志,确定异常工作节点的异常运行任务。
示例地,日志分析节点134可以采用ELK架构,在该架构下,日志处理工具可以为Logstash,存储单元为ElasticSearch,可视化分析公开可以为Kibana。
可以理解的是,考虑到随着时间的推移,数据包捕获工具11获取的心跳数据包以及运行监控工具12获取的任务运行日志的数据量增大,通过采用包含第一运维节点、日志采集节点、消息队列集群和日志分析节点这类架构的运维子系统,由各个节点承担一部分工作,各个节点之间协同完成心跳数据包及任务运行日志的有序传输、异常工作节点的识别以及异常运行任务的识别,从而可以确保各项工作的有序性、条理性,提高运维子系统的稳定性和最终识别结果的可靠性。
可选地,如图3所示,运维子系统13可以包括第二运维节点131b。第二运维节点131b可用于基于所述工作节点向所述管理节点发送的心跳数据包,确定所述工作节点是否为异常工作节点,以及基于预设任务分析策略和所述异常工作节点的任务运行日志,确定所述异常工作节点的异常运行任务。
实际应用中,第二运维节点131b可以用于管理大数据集群内所有节点的一台主机,其中可以部署具有数据分析功能的工具,具体可根据实际需要进行选择,本申请实施例对此不作限定。示例地,考虑到心跳数据包和任务运行日志都是基于时间序列的数据,第二运维节点131b中可部署Prometheus,Prometheus作为一套开源的监控、报警、时间序列数据库的组合,有利于提高异常工作节点识别及异常运行任务识别的准确性。
进一步地,为了便于运维人员能够及时了解异常运行任务,以便及时采取相关措施保障大数据集群对外提供数据服务的能力,如图3所示,运维子系统还可以包括告警节点135。告警节点135用于在第二运维节点131b确定出异常工作节点的异常运行任务之后,基于异常工作节点的任务运行日志,确定异常运行任务的运行相关信息,以及基于异常运行任务的运行相关信息,输出告警信息。其中,异常运行任务的运行相关信息可以根据实际需要进行选择,异常运行任务的运行相关信息可以包括异常运行任务的多个运行状态数据以及存在异常的异常运行状态数据等。
实际应用中,告警节点135中可以部署可视化分析工具,比如Grafana,从而可实现对异常工作节点的任务运行日志的监控、运行相关信息的统计分析以及告警。
另外,告警节点135可以通过任意适当的方式输出告警信息,具体可以例如包括但不限于通过邮件及其他媒介等方式中的至少一种,向运维人员推送告警。
可以理解的是,采用包含第二运维节点及告警节点这一架构的运维子系统,可以大大缩减运维子系统中的数据链路,不仅有利于降低监控异常发生的概率,还有利于有降低数据的延迟可能性,监控实时性更高。
本申请实施例提供的大数据集群的任务监控系统,利用大数据集群中的工作节点与管理节点之间的心跳机制,通过在大数据集群中的管理节点部署数据包捕获工具,可以自动获取大数据集群中的工作节点向管理节点发送的心跳数据包,且可以保证获取的心跳数据包的时效性,将获取的心跳数据包提供给运维子系统,使得运维子系统能够根据工作节点向管理节点发送的心跳数据包,及时、准确识别工作节点是否异常;利用运行监控工具的日志采集及上报功能,在大数据集群的工作节点部署运行监控工具,可以自动获取大数据集群中的工作节点的任务运行日志,且可以保证获取的任务运行日志的时效性,由于各个工作节点的任务运行日志记录了各种的运行任务的相关情况,通过将获取的任务运行日志提供给运维子系统,并预先在运维子系统中配置相应的任务分析策略,使得运维子系统基于异常工作节点的任务运行日志和预设任务分析策略,即可及时、准确地确定异常工作节点的异常运行任务,实现对异常工作节点及其异常原因的自动化监控,整个过程无需人工参与数据采集及研判,不仅可以提高监控效率、节省运维人员成本,还可以极大程度的降低对人为经验和熟练程度的依赖,有利于提高采集数据的时效性、准确性和全面性,从而有利于提高监控时效性和准确性。
示例地,以运行任务A为例:该运行任务每批次需要处理100亿条以上的数据,该运行任务逻辑中存在大量冗余排序和分组操作,导致该任务运行的工作节点的磁盘IO同时被该运行任务消耗殆尽,导致大数据集群提供的数据服务发生异常,若采用人工采集和判研的传统手段,至少需要30~60分钟才能识别出该运行任务属于异常运行任务。但若通过本申请实施例提供的大数据集群的任务监控系统进行工作节点相关数据的自动采集、异常工作节点的自动识别以及异常工作节点中异常运行任务的自动识别,此时只需要1~5分钟便可识别出异常任务。
基于图1至图3所示实施例揭示的大数据集群的任务监控系统,本申请实施例还提供一种大数据集群的任务监控方法,该方法可应用于运行有任务监控系统的电子设备中,比如运行有图1至图3所示实施例揭示的任务监控系统的电子设备中。请参考图4,为本申请的一个实施例提供的一种大数据集群的任务监控方法的流程示意图,该方法可以包括如下步骤:
S402,通过数据包捕获工具获取工作节点向管理节点发送的心跳数据包。
可选地,如图5所示,上述S402具体可以包括:控制数据包捕获工具按照预设间隔时长,周期性地获取工作节点向管理节点发送的心跳数据包。
本申请实施例在此示出了上述S402的一种具体实现方式。当然,应理解,上述S402也可以采用其他的方式实现,本申请实施例对此不作限定。
S404,若基于心跳数据包确定工作节点为异常工作节点,则通过运行监控工具获取工作节点的任务运行日志。本申请实施例中,在上述S404之前,可通过运维子系统,基于工作节点向管理节点发送的心跳数据包确定工作节点是否为异常工作节点。可选地,如图5所示,基于工作节点向管理节点发送的心跳数据包,确定工作节点是否为异常工作节点,具体可以包括如下步骤:若数据包捕获工具相邻两次获取到来自工作节点的心跳数据包之间的间隔时长超过预设间隔时长,则确定工作节点为异常工作节点。
本申请实施例在此示出了上述确定工作节点是否为异常工作节点的一种具体实现方式。当然,应理解,上述确定工作节点是否为异常工作节点也可以采用其他的方式实现,本申请实施例对此不作限定。
具体实施时,可通过运维子系统获取工作节点向管理节点发送的心跳数据包,以及基于工作节点向管理节点发送的心跳数据包,确定工作节点是否为异常工作节点。
更为具体地,可通过第一运维节点或第二运维节点从数据包捕获工具获取工作节点向管理节点发送的心跳数据包。
示例地,在上述图2所示的运维子系统的架构下,可通过第一运维节点,直接从数据包捕获工具获取工作节点向管理节点发送的心跳数据包,以及基于工作节点向管理节点发送的心跳数据包,确定工作节点是否为异常工作节点。在上述图3所示的运维子系统的架构下,可通过第二运维节点,从数据包捕获工具获取工作节点向管理节点发送的心跳数据包,以及基于工作节点向管理节点发送的心跳数据包,确定工作节点是否为异常工作节点。
可选地,本申请实施例中的任务监控系统还包括存储平台,在上述S402之后,本申请实施例提供的大数据集群的任务监控方法还可以包括:将工作节点向管理节点发送的心跳数据包存储至存储平台。相应地,上述通过运维子系统,从数据包捕获工具获取工作节点向管理节点发送的心跳数据包,包括:通过所述运维子系统从存储平台获取工作节点向管理节点发送的心跳数据包。
示例地,在上述图2所示的运维子系统的架构下,可通过第一运维节点,从存储平台获取工作节点向管理节点发送的心跳数据包,以及基于工作节点向管理节点发送的心跳数据包,确定工作节点是否为异常工作节点。在上述图3所示的运维子系统的架构下,可通过第二运维节点,从存储平台获取工作节点向管理节点发送的心跳数据包,以及基于工作节点向管理节点发送的心跳数据包,确定工作节点是否为异常工作节点。其中,存储平台中的心跳数据包是由数据包捕获工具在捕获到工作节点向管理节点发送的心跳数据包之后存储至该存储平台中的。
在本申请的另一个实施例中,若基于工作节点向管理节点发送的心跳数据包确定工作节点不为异常工作节点,则可以不再执行上述S404和S406,由此可以在一定程度上减少获取及分析任务运行日志所占用的功耗开销;或者,也可以在确定工作节点为异常工作节点的情况下,执行上述S404并存储该工作节点的任务运行日志,以便用于后续的节点运行相关分析任务等。
S406,通过运维子系统,基于预设任务分析策略和工作节点的任务运行日志,确定工作节点的异常运行任务。
可选地,预设任务分析策略包括目标筛选条件和目标分析维度。工作节点的任务运行日志包括工作节点中多个运行任务的运行状态信息,其中,该运行状态信息包括每个运行任务对应的多个运行状态数据,一个运行状态数据对应一个分析维度。相应地,如图5所示,上述S406具体可以包括如下步骤:通过运维子系统,基于工作节点中多个运行任务的运行状态信息,将工作节点的多个运行任务中获取满足目标筛选条件的运行任务,作为候选运行任务;基于候选运行任务的目标运行状态数据,确定候选运行任务是否为工作节点的异常运行任务,其中,目标运行状态数据与目标分析维度对应。
更为具体地,预设任务分析策略还包括目标排序条件。相应地,上述基于候选运行任务的目标运行状态数据,确定候选运行任务是否为工作节点的异常运行任务,具体包括:若候选运行任务对应的目标运行状态数据满足目标排序条件,则确定候选运行任务为工作节点中的异常运行任务。
具体应用中,在上述图2所示的运维子系统的架构下,上述S406具体可实现为:通过日志采集节点从运行监控工具获取工作节点的任务运行日志并发送给消息队列集群;通过日志分析节点向消息队列集群订阅工作节点的任务运行日志;通过消息队列集群接收日志分析节点发送的任务运行日志,以及将日志分析节点订阅的任务运行日志发送给日志分析节点;通过日志分析节点,基于预设任务分析策略和异常工作节点的任务运行日志,确定工作节点中的异常运行任务。
更为具体地,日志分析节点中部署有日志处理工具、存储单元和可视化分析公开。相应地,所述通过所述日志分析节点,基于预设任务分析策略和所述异常工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:通过所述日志处理工具向所述消息队列集群订阅所述大数据集群中的工作节点的任务运行日志,并将所述工作节点的任务运行日志保存至所述存储单元中;
通过所述可视化分析工具从所述存储单元获取所述异常工作节点的任务运行日志,以及基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点的异常运行任务。
在上述图3所示的运维子系统的架构下,上述S406具体可实现为:通过第二运维节点从运行监控工具获取工作节点的任务运行日志,以及基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点的异常运行任务。
本申请实施例在此示出了上述S406的部分具体实现方式。当然,应理解,上述S406也可以采用其他的方式实现,本申请实施例对此不作限定。
在本申请的另一个实施例中,在上述S406之后,本申请实施例提供的大数据集群的任务监控方法还可以包括:基于工作节点的任务运行日志,确定异常运行任务的运行相关信息,以及基于运行相关信息,输出告警信息。
需要说明的是,本申请实施例提供的大数据集群的任务监控方法中各步骤的具体实现方式可参见上述大数据集群的任务监控系统中的运维子系统的相应功能的具体实现方式,由于原理相同,在此不再重复说明。
本申请实施例提供的大数据集群的任务监控方法,利用大数据集群中的工作节点与管理节点之间的心跳机制,通过在大数据集群中的管理节点部署数据包捕获工具,可以自动获取大数据集群中的工作节点向管理节点发送的心跳数据包,且可以保证获取的心跳数据包的时效性,进而根据工作节点向管理节点发送的心跳数据包,及时、准确识别工作节点是否异常;利用运行监控工具的日志采集及上报功能,在大数据集群的工作节点部署运行监控工具,可以自动获取大数据集群中的工作节点的任务运行日志,且可以保证获取的任务运行日志的时效性,由于各个工作节点的任务运行日志记录了各种的运行任务的相关情况,基于异常工作节点的任务运行日志和预设任务分析策略,即可及时、准确地确定异常工作节点的异常运行任务,实现对异常工作节点及其异常原因的自动化监控,整个过程无需人工参与数据采集及研判,不仅可以提高监控效率、节省运维人员成本,还可以极大程度的降低对人为经验和熟练程度的依赖,有利于提高采集数据的时效性、准确性和全面性,从而有利于提高监控时效性和准确性。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
此外,与上述图4所示的大数据集群的任务监控方法相对应地,本申请实施例还提供一种大数据集群的任务监控装置,该任务监控装置可应用于运行有任务监控系统的电子设备,比如运行有图1至图3所示实施例揭示的任务监控系统的电子设备。请参考图6,为本申请的一个实施例提供的一种大数据集群的任务监控装置的结构示意图,该任务监控装置600可以包括:
获取单元610,用于通过所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包;
所述获取单元610,还用于若基于所述心跳数据包确定所述工作节点为异常工作节点,则通过所述运行监控工具获取所述工作节点的任务运行日志;
确定单元620,用于通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
可选地,所述预设任务分析策略包括目标筛选条件、目标分析维度和目标排序条件,所述工作节点的任务运行日志包括所述工作节点中国多个运行任务的运行状态信息,所述运行状态信息包括每个运行任务对应的多个运行状态数据,一个所述运行状态数据对应一个分析维度;
所述确定单元,通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:
通过所述运维子系统,基于所述工作节点中多个运行任务的运行状态信息,将所述工作节点的运行任务中获取满足所述目标筛选条件的运行任务,作为候选运行任务;
若所述候选运行任务的目标运行状态数据满足所述目标排序条件,则确定所述候选运行任务为所述工作节点中的异常运行任务,其中,所述目标运行状态数据与所述目标分析维度对应。
可选地,所述运维子系统包括日志采集节点、消息队列集群和日志分析节点;
所述确定单元,通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:
通过所述日志采集节点从所述运行监控工具获取所述工作节点的任务运行日志并发送给所述消息队列集群;
通过所述日志分析节点向所述消息队列集群订阅所述工作节点的任务运行日志;
通过所述消息队列集群接收所述日志分析节点发送的任务运行日志,以及将所述日志分析节点订阅的任务运行日志发送给所述日志分析节点;
通过所述日志分析节点,基于预设任务分析策略和所述异常工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
可选地,所述日志分析节点中部署有日志处理工具、存储单元和可视化分析工具;
所述确定单元,通过所述日志分析节点,基于预设任务分析策略和所述异常工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:
通过所述日志处理工具向所述消息队列集群订阅所述大数据集群中的工作节点的任务运行日志,并将所述工作节点的任务运行日志保存至所述存储单元中;
通过所述可视化分析工具从所述存储单元获取所述异常工作节点的任务运行日志,以及基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点的异常运行任务。
可选地,所述确定单元还用于:通过所述运维子系统获取所述工作节点向所述管理节点发送的心跳数据包,以及基于所述工作节点向所述管理节点发送的心跳数据包,确定所述工作节点是否异常工作节点。
可选地,所述运维子系统包括第一运维节点或第二运维节点;
所述确定单元,通过所述运维子系统获取所述工作节点向所述管理节点发送的心跳数据包,包括:
通过所述第一运维节点或第二运维节点从所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包
可选地,若所述运维子系统包括第二运维节点;则所述确定单元,通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:
通过所述第二运维节点从所述运行监控工具获取所述工作节点的任务运行日志,以及基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
可选地,所述确定单元,还用于在基于预设任务分析策略和所述工作节点的任务运行日志确定所述工作节点中的异常运行任务之后,基于所述工作节点的任务运行日志,确定所述异常运行任务的运行相关信息;
所述任务监控装置还包括:
告警单元,用于基于所述运行相关信息,输出告警信息。
可选地,所述任务监控系统还包括存储平台;
所述获取单元,还用于在通过所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包之后,将所述工作节点向所述管理节点发送的心跳数据包存储至所述存储平台;
所述确定单元,通过所述运维子系统,从所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包,包括:
通过所述运维子系统从所述存储平台获取所述工作节点向所述管理节点发送的心跳数据包。
可选地,所述获取单元,通过所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包,包括:
控制所述数据包捕获工具按照预设间隔时长,周期性地获取所述工作节点向所述管理节点发送的心跳数据包;
所述确定单元,基于所述工作节点向所述管理节点发送的心跳数据包,确定所述工作节点是否为异常工作节点,包括:
若所述数据包捕获工具相邻两次获取到来自所述工作节点的心跳数据包之间的间隔时长超过所述预设间隔时长,则确定所述工作节点为异常工作节点。
显然,本申请实施例提供的大数据集群的任务监控装置能够作为图4所示的大数据集群的任务监控方法的执行主体,例如图4所示的大数据集群的任务监控方法中,步骤S402和步骤S404可由图6所示的任务监控装置600中的获取单元610执行,步骤S406可由图6所示的任务监控装置600中的确定单元620执行。
根据本申请的另一个实施例,图6所示的大数据集群的任务监控装置中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成,或者其中的某个(些)单元还可以再拆分为功能上更小的多个单元来构成,这可以实现同样的操作,而不影响本申请实施例的技术效果的实现。上述单元是基于逻辑功能划分的,在实际应用中,一个单元的功能也可以由多个单元来实现,或者多个单元的功能由一个单元实现。在本申请的其他实施例中,大数据集群的任务监控装置也可以包括其他单元,在实际应用中,这些功能也可以由其他单元协助实现,并且可以由多个单元协作实现。
根据本申请的另一个实施例,可以通过在包括中央处理单元(CentralProcessing Unit,CPU)、随机存取存储介质(Random Access Memory,RAM)、只读存储介质(Read-Only Memory,ROM)等处理元件和存储元件的例如计算机的通用计算设备上,运行能够执行如图4所示的相应方法所涉及的各步骤的计算机程序(包括程序代码),来构造如图6中所示的大数据集群的任务监控装置,以及来实现本申请实施例的大数据集群的任务监控方法。所述计算机程序可以记载于例如计算机可读存储介质上,并通过计算机可读存储介质转载于电子设备中,并在其中运行。
本申请实施例提供的大数据集群的任务监控装置,利用大数据集群中的工作节点与管理节点之间的心跳机制,通过在大数据集群中的管理节点部署数据包捕获工具,可以自动获取大数据集群中的工作节点向管理节点发送的心跳数据包,且可以保证获取的心跳数据包的时效性,进而根据工作节点向管理节点发送的心跳数据包,及时、准确识别工作节点是否异常;利用运行监控工具的日志采集及上报功能,在大数据集群的工作节点部署运行监控工具,可以自动获取大数据集群中的工作节点的任务运行日志,且可以保证获取的任务运行日志的时效性,由于各个工作节点的任务运行日志记录了各种的运行任务的相关情况,基于异常工作节点的任务运行日志和预设任务分析策略,即可及时、准确地确定异常工作节点的异常运行任务,实现对异常工作节点及其异常原因的自动化监控,整个过程无需人工参与数据采集及研判,不仅可以提高监控效率、节省运维人员成本,还可以极大程度的降低对人为经验和熟练程度的依赖,有利于提高采集数据的时效性、准确性和全面性,从而有利于提高监控时效性和准确性。
图7是本申请的一个实施例电子设备的结构示意图。请参考图7,在硬件层面,该电子设备包括处理器,可选地还包括内部总线、网络接口、存储器。其中,存储器可能包含内存,例如高速随机存取存储器(Random-Access Memory,RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少1个磁盘存储器等。当然,该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接,该内部总线可以是ISA(Industry Standard Architecture,工业标准体系结构)总线、PCI(PeripheralComponent Interconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示,图7中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
存储器,用于存放程序。具体地,程序可以包括程序代码,所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器,并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行,在逻辑层面上形成大数据集群的任务监控装置。处理器,执行存储器所存放的程序,并具体用于执行以下操作:
通过部署于所述大数据集群中的管理节点的数据包捕获工具,获取所述大数据集群中的工作节点向所述管理节点发送的心跳数据包;
若基于所述心跳数据包确定所述工作节点为异常工作节点,则通过部署于所述工作节点的运行监控工具,获取所述工作节点的任务运行日志;
基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
上述如本申请图4所示实施例揭示的大数据集群的任务监控装置执行的方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器,包括中央处理器(Central ProcessingUnit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(DigitalSignal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
该电子设备还可执行图4的方法,并实现大数据集群的任务监控装置在图4所示实施例的功能,本申请实施例在此不再赘述。
当然,除了软件实现方式之外,本申请的电子设备并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
本申请实施例还提出了一种计算机可读存储介质,该计算机可读存储介质存储一个或多个程序,该一个或多个程序包括指令,该指令当被包括多个应用程序的便携式电子设备执行时,能够使该便携式电子设备执行图1所示实施例的方法,并具体用于执行以下操作:
通过部署于所述大数据集群中的管理节点的数据包捕获工具,获取所述大数据集群中的工作节点向所述管理节点发送的心跳数据包;
若基于所述心跳数据包确定所述工作节点为异常工作节点,则通过部署于所述工作节点的运行监控工具,获取所述工作节点的任务运行日志;
基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
总之,以上所述仅为本申请的较佳实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
Claims (13)
1.一种大数据集群的任务监控方法,其特征在于,应用于运行有任务监控系统的电子设备中,所述任务监控系统包括数据包捕获工具、运行监控工具以及运维子系统,所述大数据集群包括管理节点和工作节点,所述数据包捕获工具部署于所述管理节点中,所述运行监控工具部署于所述工作节点中;所述方法包括:
通过所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包;
若基于所述心跳数据包确定所述工作节点为异常工作节点,则通过所述运行监控工具获取所述工作节点的任务运行日志;
通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
2.根据权利要求1所述的方法,其特征在于,所述预设任务分析策略包括目标筛选条件、目标分析维度和目标排序条件,所述工作节点的任务运行日志包括所述工作节点中多个运行任务的运行状态信息,所述运行状态信息包括每个运行任务对应的多个运行状态数据,一个运行状态数据对应一个分析维度;
所述通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:
通过所述运维子系统,基于所述工作节点中多个运行任务的运行状态信息,将所述工作节点的多个运行任务中满足所述目标筛选条件的运行任务作为候选运行任务;
若所述候选运行任务对应的目标运行状态数据满足所述目标排序条件,则确定所述候选运行任务为所述工作节点中的异常运行任务,其中,所述目标运行状态数据与所述目标分析维度对应。
3.根据权利要求1所述的方法,其特征在于,所述运维子系统包括日志采集节点、消息队列集群和日志分析节点;
所述通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:
通过所述日志采集节点从所述运行监控工具获取所述工作节点的任务运行日志并发送给所述消息队列集群;
通过所述日志分析节点向所述消息队列集群订阅所述工作节点的任务运行日志;
通过所述消息队列集群接收所述日志分析节点发送的任务运行日志,以及将所述日志分析节点订阅的任务运行日志发送给所述日志分析节点;
通过所述日志分析节点,基于预设任务分析策略和所述异常工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
4.根据权利要求3所述的方法,其特征在于,所述日志分析节点中部署有日志处理工具、存储单元和可视化分析工具;
所述通过所述日志分析节点,基于预设任务分析策略和所述异常工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:
通过所述日志处理工具向所述消息队列集群订阅所述大数据集群中的工作节点的任务运行日志,并将所述工作节点的任务运行日志保存至所述存储单元中;
通过所述可视化分析工具从所述存储单元获取所述异常工作节点的任务运行日志,以及基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点的异常运行任务。
5.根据权利要求1所述的方法,其特征在于,所述方法还包括:
通过所述运维子系统获取所述工作节点向所述管理节点发送的心跳数据包;
基于所述工作节点向所述管理节点发送的心跳数据包,确定所述工作节点是否异常工作节点。
6.根据权利要求5所述的方法,其特征在于,所述运维子系统包括第一运维节点或第二运维节点;所述通过所述运维子系统获取所述工作节点向所述管理节点发送的心跳数据包,包括:
通过所述第一运维节点或第二运维节点从所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包。
7.根据权利要求6所述的方法,其特征在于,若所述运维子系统包括第二运维节点;则所述通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务,包括:
通过所述第二运维节点从所述运行监控工具获取所述工作节点的任务运行日志,以及基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
8.根据权利要求1所述的方法,其特征在于,在基于预设任务分析策略和所述工作节点的任务运行日志确定所述工作节点中的异常运行任务之后,所述方法还包括:
通过所述运维子系统,基于所述工作节点的任务运行日志,确定所述异常运行任务的运行相关信息,以及基于所述运行相关信息,输出告警信息。
9.根据权利要求5所述的方法,其特征在于,所述任务监控系统还包括存储平台;
在通过所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包之后,所述方法还包括:
将所述工作节点向所述管理节点发送的心跳数据包存储至所述存储平台;
所述通过所述运维子系统,从所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包,包括:
通过所述运维子系统从所述存储平台获取所述工作节点向所述管理节点发送的心跳数据包。
10.根据权利要求9所述的方法,其特征在于,所述通过所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包,包括:
控制所述数据包捕获工具按照预设间隔时长,周期性地获取所述工作节点向所述管理节点发送的心跳数据包;
所述基于所述工作节点向所述管理节点发送的心跳数据包,确定所述工作节点是否为异常工作节点,包括:
若所述数据包捕获工具相邻两次获取到来自所述工作节点的心跳数据包之间的间隔时长超过所述预设间隔时长,则确定所述工作节点为异常工作节点。
11.一种大数据集群的任务监控装置,其特征在于,应用于运行有任务监控系统的电子设备中,所述任务监控系统包括数据包捕获工具、运行监控工具以及运维子系统,所述大数据集群包括管理节点和工作节点,所述数据包捕获工具部署于所述管理节点,所述运行监控工具部署于所述工作节点中;所述装置包括:
获取单元,用于通过所述数据包捕获工具获取所述工作节点向所述管理节点发送的心跳数据包;
所述获取单元,还用于若基于所述心跳数据包确定所述工作节点为异常工作节点,则通过所述运行监控工具获取所述工作节点的任务运行日志;
确定单元,用于通过所述运维子系统,基于预设任务分析策略和所述工作节点的任务运行日志,确定所述工作节点中的异常运行任务。
12.一种电子设备,其特征在于,包括:
处理器;
用于存储所述处理器可执行指令的存储器;
其中,所述处理器被配置为执行所述指令,以实现如权利要求1至10中任一项所述的方法。
13.一种计算机可读存储介质,其特征在于,当所述存储介质中的指令由电子设备的处理器执行时,使得电子设备能够执行如权利要求1至10中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211039280.8A CN116126621A (zh) | 2022-08-29 | 2022-08-29 | 大数据集群的任务监控方法及相关设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211039280.8A CN116126621A (zh) | 2022-08-29 | 2022-08-29 | 大数据集群的任务监控方法及相关设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116126621A true CN116126621A (zh) | 2023-05-16 |
Family
ID=86308628
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211039280.8A Pending CN116126621A (zh) | 2022-08-29 | 2022-08-29 | 大数据集群的任务监控方法及相关设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116126621A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116627771A (zh) * | 2023-07-18 | 2023-08-22 | 中移(苏州)软件技术有限公司 | 日志采集方法、装置、电子设备和可读存储介质 |
-
2022
- 2022-08-29 CN CN202211039280.8A patent/CN116126621A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116627771A (zh) * | 2023-07-18 | 2023-08-22 | 中移(苏州)软件技术有限公司 | 日志采集方法、装置、电子设备和可读存储介质 |
CN116627771B (zh) * | 2023-07-18 | 2023-10-13 | 中移(苏州)软件技术有限公司 | 日志采集方法、装置、电子设备和可读存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110502494B (zh) | 日志处理方法、装置、计算机设备及存储介质 | |
EP3425524A1 (en) | Cloud platform-based client application data calculation method and device | |
CN107832196B (zh) | 一种用于实时日志异常内容的监测装置及监测方法 | |
EP3432520B1 (en) | Efficient storage and querying of time series metrics | |
CN105488610A (zh) | 一种电力应用系统故障实时分析诊断系统及方法 | |
CN109885453B (zh) | 基于流数据处理的大数据平台监控系统 | |
CN109165138A (zh) | 一种监控设备故障的方法和装置 | |
CN110209518A (zh) | 一种多数据源日志数据集中收集存储方法及装置 | |
CN113656245B (zh) | 数据的巡检方法、装置、存储介质及处理器 | |
CN113485999A (zh) | 数据清理方法、装置和服务器 | |
CN106789158A (zh) | 一种云服务保险定损方法和系统 | |
CN116126621A (zh) | 大数据集群的任务监控方法及相关设备 | |
CN111314158A (zh) | 大数据平台监控方法、装置及设备、介质 | |
CN112579552A (zh) | 日志存储及调用方法、装置及系统 | |
CN117632897A (zh) | 动态扩缩容方法及装置 | |
CN116594840A (zh) | 基于elk的日志故障采集与分析方法、系统、设备及介质 | |
CN111339052A (zh) | 一种非结构化日志数据处理方法及装置 | |
CN107257289A (zh) | 一种风险分析设备、监控系统和监控方法 | |
CN112527887B (zh) | 一种应用于Gbase数据库的可视化运维方法及装置 | |
CN111324583B (zh) | 一种业务日志的分类方法及装置 | |
CN115686381A (zh) | 存储集群运行状态的预测方法及装置 | |
CN115525392A (zh) | 容器监控方法、装置、电子设备及存储介质 | |
CN113472881B (zh) | 在线终端设备的统计方法和装置 | |
CN115562933A (zh) | 作业监控数据的处理方法及装置、存储介质、电子设备 | |
CN113409876A (zh) | 一种故障硬盘的定位方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |