发明内容
本申请的实施例提供一种告警判定方法、装置及告警系统,可以提升告警判定的效率。
为了达到上述目的,本申请的实施例提供以下技术方案:
第一方面,本申请的实施例提供一种告警判定的方法,该方法应用于告警系统,告警系统包括服务器、被监控节点和至少两个计算节点,每个计算节点存储有预设类型告警规则,该方法包括:对于告警系统中的任意一个计算节点,计算节点根据存储的预设类型告警规则获取与预设类型告警规则对应的监控数据,计算节点根据预设类型告警规则对监控数据进行告警判定。
与现有技术中,服务器通常获取监控数据,再遍历各个告警规则进行告警判定,导致告警判定的效率较低相比,本申请提供的告警判定方法中,每个计算节点无需存储所有告警规则,而是仅存储预设类型告警规则,例如:所有类型的告警规则中的某一类型或某些类型的告警规则。之后计算节点根据其存储的预设类型告警规则,仅获取与该预设类型告警规则对应的监控数据,并根据预设类型告警规则以及监控数据进行告警判定。由于每个计算节点仅存储有部分告警规则以及与该告警规则对应的监控数据。也就意味着,计算节点处理的告警规则和监控数据的数量有所减少,所以能够缩短计算节点告警判定的时间,从而提升告警判定的效率。
在一种可能的设计中,告警规则包括:时间窗口为0的告警规则、短时间窗口告警规则和长时间窗口告警规则;其中,长时间窗口告警规则的时间窗口长度大于或等于预设窗口长度,短时间窗口告警规则的时间窗口长度小于预设窗口长度。
在一种可能的设计中,计算节点根据存储的预设类型告警规则获取与预设类型告警规则对应的监控数据具体可以实现为:若预设类型告警规则为时间窗口为0的告警规则,则计算节点获取实时监控数据;或者,若预设类型告警规则为短时间窗口告警规则,则计算节点获取短时间窗口对应的时间段内的监控数据;或者,若预设类型告警规则为长时间窗口告警规则,则计算节点获取长时间窗口对应的时间段内的监控数据。可见,根据预存储的告警规则的类型,每个计算节点仅获取与预存储的告警规则对应的监控数据,能够减少计算节点处理数据的数量,提升告警判定的效率。
在一种可能的设计中,预设类型告警规则包括至少一个子表达式,每个子表达式对应一个监控指标;监控数据包括监控指标。相应的,在计算节点根据存储的预设类型告警规则获取与预设类型告警规则对应的监控数据之后,还可以执行如下操作:计算节点按照监控指标和被监控节点标识对监控数据进行划分,得到至少一个第一监控数据组;其中,每个第一监控数据组的监控数据中包括的监控指标相同且对应的被监控节点标识相同。该实现方式中,将具有相同监控指标且被监控节点标识相同的监控数据划分为一组之后,加强了相关监控数据之间的联系,便于后续计算节点按照监控指标的不同分组情况,分别确定各个监控指标的值。
在一种可能的实现方式中,计算节点根据预设类型告警规则对监控数据进行告警判定具体可以实现为:计算节点确定监控数据中各个监控指标的值,根据各个监控指标的值,分别确定各个监控指标对应的子表达式的值,再根据各个监控指标对应的子表达式的值确定预设类型告警规则的值;若确定预设类型告警规则的值为预设值,则计算节点进行告警。
示例性的,所述预设类型告警规则的值可以为0或1,当根据该实现方式计算得到预设类型告警规则的值为1时,则进行告警,当计算得到预设类型告警规则的值为0时,则不执行告警的动作。
在一种可能的设计中,在计算节点确定监控数据中各个监控指标的值之后,还可以执行如下操作:计算节点按照获取监控数据的时间和告警规则标识对监控数据进行划分,得到至少一个第二监控数据组;第二监控数据组的监控数据对应的获取时间相同且告警规则标识相同。
在一种可能的设计中,计算节点从服务器获取预设类型告警规则。
第二方面,本申请实施例提供一种告警判定的方法,该方法应用于告警系统,告警系统包括服务器、被监控节点和至少两个计算节点,每个计算节点存储有预设类型告警规则;该方法包括:服务器接收用户输入的告警规则配置指令,其中,告警规则配置指令用于配置告警规则;服务器对配置的告警规则进行分类,以使得计算节点按照告警规则的类型分别获取预设类型告警规则。
与现有技术中,服务器通常获取监控数据,再遍历各个告警规则进行告警判定,导致告警判定的效率较低相比,本申请提供的告警判定方法中,每个计算节点无需存储所有告警规则,而是仅存储预设类型告警规则,例如:所有类型的告警规则中的某一类型或某些类型的告警规则。之后计算节点根据其存储的预设类型告警规则,仅获取与该预设类型告警规则对应的监控数据,并根据预设类型告警规则以及监控数据进行告警判定。由于每个计算节点仅存储有部分告警规则以及与该告警规则对应的监控数据。也就意味着,计算节点处理的告警规则和监控数据的数量有所减少,所以能够缩短计算节点告警判定的时间,从而提升告警判定的效率。
在一种可能的设计中,告警规则的类型包括时间窗口为0的告警规则、短时间窗口告警规则和长时间窗口告警规则;其中,长时间窗口告警规则的时间窗口长度大于或等于预设窗口长度,短时间窗口告警规则的时间窗口长度小于预设窗口长度。
在一种可能的设计中,服务器通过告警规则中子函数的类型和告警规则中的窗口函数来判断告警规则的类型。其中,通过该判断告警规则类型的方法,服务器对告警规则进行分类,从而计算节点可按照告警规则的类别获取预设类型告警规则。例如:服务器将分类后的告警规则下发给Hadoop分布式文件系统(Hadoop Distributed File System,HDFS)集群,再由HDFS集群将不同类型的告警规则下发给计算节点,从而,每个计算节点仅仅处理其对应的预设类型告警规则,并仅仅获取与该预设类型告警规则对应的监控数据,减少了计算节点处理数据的数据量,使得告警判定的效率有所提升。
第三方面,提供一种告警判定装置,该装置应用于告警系统,所述告警系统包括服务器、被监控节点和至少两个计算节点,每个计算节点存储有预设类型告警规则,所述装置作为计算节点包括:通信单元,用于根据存储的预设类型告警规则获取与所述预设类型告警规则对应的监控数据,所述计算节点为所述告警系统中的任意一个计算节点;处理单元,用于根据所述预设类型告警规则对所述监控数据进行告警判定。
在一种可能的设计中,所述告警规则包括:时间窗口为0的告警规则、短时间窗口告警规则和长时间窗口告警规则;其中,长时间窗口告警规则的时间窗口长度大于或等于预设窗口长度,短时间窗口告警规则的时间窗口长度小于预设窗口长度。
在一种可能的设计中,通信单元,还用于若所述预设类型告警规则为时间窗口为0的告警规则,则获取实时监控数据;或者,若所述预设类型告警规则为短时间窗口告警规则,则所述获取所述短时间窗口对应的时间段内的监控数据;或者,若所述预设类型告警规则为长时间窗口告警规则,则获取所述长时间窗口对应的时间段内的监控数据。
在一种可能的设计中,所述预设类型告警规则包括至少一个子表达式,每个子表达式对应一个监控指标;所述监控数据包括监控指标;所述处理单元,用于按照监控指标和被监控节点标识对所述监控数据进行划分,得到至少一个第一监控数据组;其中,每个第一监控数据组的监控数据中包括的监控指标相同且对应的被监控节点标识相同。
在一种可能的设计中,所述处理单元,还用于确定所述监控数据中各个监控指标的值;根据各个监控指标的值,分别确定各个监控指标对应的子表达式的值;根据各个监控指标对应的子表达式的值确定所述预设类型告警规则的值;若确定所述预设类型告警规则的值为预设值,则进行告警。
在一种可能的设计中,所述处理单元,还用于按照获取所述监控数据的时间和告警规则标识对所述监控数据进行划分,得到至少一个第二监控数据组;所述第二监控数据组的监控数据对应的获取时间相同且告警规则标识相同。
在一种可能的设计中,所述通信单元,还用于从所述服务器获取所述预设类型告警规则。
第四方面,提供一种告警判定装置,应用于告警系统,所述告警系统包括服务器、被监控节点和至少两个计算节点;所述装置作为服务器包括:通信单元,用于接收用户输入的告警规则配置指令,所述告警规则配置指令用于配置告警规则;处理单元,用于对配置的告警规则进行分类,以使得计算节点按照告警规则的类型分别获取预设类型告警规则。
在一种可能的设计中,所述告警规则的类型包括时间窗口为0的告警规则、短时间窗口告警规则和长时间窗口告警规则;其中,长时间窗口告警规则的时间窗口长度大于或等于预设窗口长度,短时间窗口告警规则的时间窗口长度小于预设窗口长度。
第五方面,提供一种计算节点,该计算节点包括:处理器、通信接口和存储器;其中,存储器用于存储计算机执行指令,当计算节点运行时,处理器执行存储器存储的计算机执行指令,以使计算节点执行如第一方面及其任一种可能的实现方式所述的告警判定方法。
第六方面,提供一种服务器,该服务器包括:处理器、通信接口和存储器;其中,存储器用于存储计算机执行指令,当服务器运行时,处理器执行存储器存储的计算机执行指令,以使服务器执行如第二方面及其任一种可能的实现方式所述的告警判定方法。
第七方面,提供一种计算机可读存储介质,计算机可读存储介质中存储有指令,当指令在计算节点上运行时,使得计算节点执行如第一方面及其任一种可能的实现方式所述的告警判定方法。
第八方面,提供一种计算机可读存储介质,计算机可读存储介质中存储有指令,当指令在服务器上运行时,使得服务器执行如第二方面及其任一种可能的实现方式所述的告警判定方法。
第九方面,提供一种包含指令的计算机程序产品,当其在计算节点上运行时,使得计算节点执行如第一方面及其任一种可能的实现方式所述的告警判定方法。
第十方面,提供一种包含指令的计算机程序产品,当其在服务器上运行时,使得服务器执行如第二方面及其任一种可能的实现方式所述的告警判定方法。
上述第三方面至第十方面的有益效果可参照相应的第一方面及第二方面,此处不再赘述。
具体实施方式
下面结合附图对本申请实施例提供的告警判定方法、装置及告警系统进行详细地描述。
本文中术语“和/或”,仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。
本申请的说明书以及附图中的术语“第一”和“第二”等是用于区别不同的对象,或者用于区别对同一对象的不同处理,而不是用于描述对象的特定顺序。
此外,本申请的描述中所提到的术语“包括”和“具有”以及它们的任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括其他没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
需要说明的是,本申请实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
随着通信业务的迅速发展,在局域网或数据中心网络等组网环境中,运行的网络设备日益增多,网络设备提供的业务越来越丰富,进而网络设备需消耗较多的资源,这会导致网络设备的性能不稳定。为了保证网络设备的性能平稳,需对网络设备的性能指标进行监控并根据监控结果实时调整。基于此,目前存在一种告警系统,在被监控的网络设备上安装有代理软件,代理软件收集被监控网络设备的各项指标数据,并将指标数据上报给服务端,服务端存储各个指标数据,然后,服务端通过遍历各条告警规则,从存储的指标数据中查询符合各个告警规则的指标数据。但是,服务端需遍历数量较多的告警规则,耗费较长的时间,不能够将故障事件及时通知给用户,降低故障维护的及时性。
为了解决上述问题,本申请实施例提供一种告警判定的方法、装置及告警系统。其中,本申请实施例提供的告警判定方法、装置及告警系统,可以应用于局域网、数据中心和跨地市等组网环境中。其中,局域网可以为企业用局域网,也可以是部署在网吧、候车厅等区域内的公用局域网。
如图1所示,告警系统10包括:服务器11、HDFS集群12、第一计算节点13、第二计算节点14、第三计算节点15、kafka集群16和多个被监控节点17。
其中,服务器11用于接收用户的告警规则配置指令,并根据告警规则配置指令解析该指令对应的告警规则,并对告警规则进行分类,进而可由计算节点获取相应类型的告警规则。该服务器11可以是物理设备,也可以是基于虚拟化技术实现的虚拟服务器。图1中仅示出了物理形式的服务器。
HDFS集群12用于存储服务器下发的告警规则,该集群包括至少一个用于管理文件的分布式物理设备和/或分布式虚拟机。图1仅示出了物理形式的HDFS集群。
kafka集群16用于收集被监控节点17的监控数据,其中kafka集群中,收集监控数据的功能可以实现为运行在物理设备中的软件,图1示出了kafka集群中的物理设备;被监控节点为待收集监控指标的节点,其可以为软件、虚拟机,也可以为物理机。
被监控节点17包括提供上网业务的业务设备、用于存储文件的存储设备等,示例性的,被监控节点17可以为软件、虚拟机,也可以为物理设备。
计算节点用于从HDFS集群中获取告警规则,并根据告警规则从kafka集群中获取告警规则对应的监控数据,然后根据告警规则对获取的监控数据进行告警判定。其中,计算节点可以实现为运行在物理设备中的软件,图1中示出了计算节点所在的物理设备。
其中,第一计算节点13存储有瞬时规则,用于根据瞬时规则进行告警判定。第二计算节点14存储有窗口规则,用于根据窗口规则进行告警判定。第三计算节点15存储有缓存规则,用于根据缓存规则进行告警判定。由于瞬时规则主要用于对实时数据进行告警判定,为了实现该功能,上述第一计算节点基于流处理技术框架,其中,流处理技术可以为Storm、Spark等技术。由于在流处理技术中,将大量的流式数据分解为多个短小的批处理数据,再对各个短小的批处理数据进行分批处理,从而能够保证监控数据的实时处理,以使得在每个周期中支持百万级监控数据的告警判定。
需要说明的是,本申请实施例中,瞬时规则又可称为时间窗口为0的告警规则,窗口规则又可称为短时间窗口告警规则,缓存规则又可称为长时间窗口告警规则,对这三种告警规则的详细说明请参见后文。
需要说明的是,图1以设置三个计算节点为例进行说明,可以理解的是,告警系统中还可以设置三个以上的计算节点。例如,设置四个计算节点,其中,计算节点1和计算节点2存储瞬时规则,计算节点3存储有窗口规则,计算节点4存储有缓存规则。还可以仅设置两个计算节点,例如,设置计算节点5和计算节点6,其中计算节点5存储有瞬时规则和窗口规则,计算节点6存储有缓存规则。具体设置计算节点的数量可以根据实际场景确定,本申请实施例不对此进行限制。
图2为本申请实施例提供的一种网络设备的组成示意图,该网络设备可以为如图1所示计算节点或服务器等。如图2所示,网络设备可以包括至少一个处理器21、通信接口22、存储器23和总线24。
下面结合图2对网络设备的各个构成部件进行具体的介绍:
处理器21是网络设备的控制中心,可以是一个处理器,也可以是多个处理元件的统称。在具体的实现中,作为一种实施例,处理器21可以包括一个或多个中央处理单元(Central Processing Unit,CPU),例如图2中所示的CPU0和CPU1。处理器21也可以是专用集成电路(Application Specific Integrated Circuit,ASIC),或者是被配置成实施本申请实施例的一个或多个集成电路,例如:一个或多个数字信号处理器(Digital SignalProcessor,DSP),或,一个或者多个现场可编程门阵列(Field Programmable Gate Array,FPGA)组成的集成电路集合。
其中,以处理器21是一个或多个CPU为例,处理器21可以通过运行或执行存储在网络设备中的存储器23内的软件程序,以及调用存储在存储器23内的数据,执行网络设备的各种功能。
在具体实现中,作为一种实施例,网络设备可以包括多个处理器,例如图2中所示的2个处理器21。这些处理器中的每一个可以是一个单核处理器(single-CPU),也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
在本申请实施例中,当网络设备为计算节点时,处理器21主要用于获取预设类型告警规则,并根据预设类型告警规则获取预设类型告警规则对应的监控数据,从而根据预设类型告警规则对监控数据进行告警。当网络设备为服务器时,处理器21主要用于对告警规则进行分类,并将不同类型的告警规则下发给不同的计算节点。例如:处理器21直接将不同类型的告警规则下发至相应的计算节点。又如:处理器21将分类后的告警规则下发给HDFS集群,然后由HDFS集群将告警规则下发给相应的计算节点,或者由计算节点从HDFS集群中获取相应类型的告警规则,使得每个节点仅仅获取预设类型的告警规则,并仅仅处理和预设类型告警规则对应的监控数据,减少计算节点的数据处理量,提升计算节点的计算效率,进而提升告警判定的效率。
存储器23可以是只读存储器(Read-Only Memory,ROM)或可存储静态信息和指令的其他类型的静态存储设备,随机存取存储器(Random Access Memory,RAM)或者可存储信息和指令的其他类型的动态存储设备,也可以是电可擦可编程只读存储器(ElectricallyErasable Programmable Read-Only Memory,EEPROM)、只读光盘(Compact Disc Read-Only Memory,CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器23可以是独立存在,通过总线24与处理器21相连接。存储器23也可以和处理器21集成在一起。
其中,存储器23可以包括程序存储区,用于存储执行本申请方案的程序指令,并由处理器21来控制执行。此外,存储器23还可以包括数据存储区,用于缓存网络设备的相关数据,以及执行本申请实施例提供的告警判定方法过程中产生的中间数据。
通信接口22,用于与其他设备或通信网络通信,如以太网,无线接入网(RadioAccess Network,RAN),无线局域网(Wireless Local Area Networks,WLAN)等。通信接口22可以包括接收单元实现接收功能,以及发送单元实现发送功能。在本申请实施例中通信接口主要用于收发告警规则和/或监控数据等。
总线24,可以是工业标准体系结构(Industry Standard Architecture,ISA)总线、外部设备互连(Peripheral Component Interconnect,PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture,EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,图2中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
图2中示出的设备结构并不构成对网络设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
本申请实施例提供一种告警判定的方法,可应用于图1所示的系统架构以及图2所示的网络设备。在介绍本申请实施例提供的方法前,先对本申请实施例中的术语进行介绍:
本申请实施例中,时间窗口指的是流处理技术中的时间窗口。流处理技术可以为Storm、Spark等技术。在流处理技术中,时间窗口操作指的是在一段时间内,获取该段时间内的数据,并对时间段内的数据进行预设操作。时间窗口长度为时间段长度,若时间窗口长度为0,则获取当前一个时刻的数据(即获取当前的实时数据),若时间窗口长度为N分钟,则获取N分钟内的数据。例如,如图3示出了本申请实施例中的时间窗口。假定有时刻1至时刻8,如图3中,时间窗口1的时间窗口长度为2,相应地,时间窗口1的窗口操作为获取2个时刻的数据,即获取时刻1和时刻2的数据;时间窗口2的时间窗口长度为3,相应地,时间窗口2的窗口操作为获取3个时刻的数据,即获取时刻4、时刻5和时刻6的数据;时间窗口3的时间窗口长度为0,相应地,时间窗口3的窗口操作为获取当前时刻的数据(即获取当前的实时数据),即获取时刻8的数据。
告警规则,具体可以为指示监控指标的规则。例如,告警规则可以为指示监控节点1的CPU使用率这一监控指标,并规定CPU使用率大于阈值时进行告警的规则。可以理解的是,在告警规则的指示下,可以获取相应的监控数据,并判断监控数据中的监控指标值是否达到告警规则中指示的阈值。例如,若告警规则为指示监控节点1的CPU使用率,并在CPU使用率大于80%时进行告警,则计算节点在配置有该告警规则之后,在告警规则的指示下,可以监测节点1的CPU使用率,若节点1的CPU使用率达到80%,则计算节点进行告警,以提示用户节点1的CPU使用率过高,使得用户根据告警提示及时对节点1进行维护。
告警规则为用户根据历史统计数据设定,例如,历史统计数据显示,当CPU使用率大于80%时,网络设备的运行性能显著下降,则可以设置告警规则,告警规则用于监控网络设备的CPU使用率。计算节点利用告警规则进行告警判定之前,需要先获取告警规则。参见图4,计算节点获取预设类型告警规则的过程包括:
S401、服务器接收用户输入的告警规则配置指令生成告警规则,告警规则配置指令用于配置告警规则。
其中,S401可由服务器通过输入设备(如触控屏、鼠标结合显示屏等,图2中未示出)接收用户输入的告警规则配置指令并由处理器生成相应的告警规则。
可选的,用户通过服务器的用户界面(User Interface,UI)输入告警规则配置指令。示例性地,用户通过输入告警规则配置指令来配置如下格式的告警规则。
其中,item_key为待监控的监控指标,此处监控指标为system.cpu.load,即系统CPU负载;item_value为待监控的监控指标的数值,即系统CPU负载的具体数值;last为求监控指标最新值的子函数,item_value.last为求系统CPU负载的最新值;alarm_instance_id为告警规则标识;"Processor load is too high"为告警通知的内容,即当监控指标的值达到阈值时,显示告警通知“处理器负载过高”;agentSN为被监控节点的名称ba109c36。
上述告警规则表示:需监控名称为ba109c36的节点的CPU负载的最新值,当其数值大于5时,触发告警,并给出告警提示“处理器负载过高”,以提示用户对处理器负载过高的情况做出维护或者调整。
用户可以通过在服务器的UI中点击配置告警规则的按钮(button)来输入告警规则配置指令,也可以通过命令行等方式输入告警规则配置指令,用户还可以通过其他方式输入告警规则配置指令,具体实施方式可根据实际应用场景确定,本申请实施例对此不限制。
S402、服务器对配置的告警规则进行分类。
其中,S402可由图2所示服务器中的处理器21执行。
可选的,告警规则包括时间窗口为0的告警规则、短时间窗口告警规则和长时间窗口告警规则,长时间窗口告警规则的时间窗口长度大于或等于预设窗口长度,短时间窗口告警规则的时间窗口长度小于预设窗口长度。
上述所指时间窗口为0的告警规则,可以为需实时、瞬时计算的告警规则,所以,时间窗口为0的告警规则又可称为瞬时规则。示例性地,若告警规则1为“监控节点1的CPU使用率的最新值,当CPU使用率的最新值大于80%时,进行告警”,在告警规则1中,需监控CPU使用率的最新值,即需监控CPU使用率的当前时刻的值(即CPU使用率的实时数值),所以,告警规则1是时间窗口为0的告警规则(瞬时规则)。假定当前时刻为图3所示的时刻8,则在告警规则1的指示下,如图1中的第一计算节点可以通过时间窗口3对应的窗口操作获取时刻8的CPU使用率的瞬时值,并根据告警规则1对获取的瞬时值进行告警判定。
假定预设窗口长度为10分钟,短时间窗口告警规则(又称窗口规则)为时间窗口长度小于10分钟的告警规则,其中,短时间窗口告警规则对应的时间窗口长度较短,其又可称为窗口规则。长时间窗口告警规则为时间窗口长度大于或等于10分钟的告警规则。其中,长时间窗口告警规则对应的时间窗口长度较大,相应地,需要获取的监控数据量较多,可以采用外挂缓存技术存储对应的监控数据,所以,长时间窗口告警规则又可称为缓存规则。假定告警规则为“检测节点1在5分钟内的平均流量”,该告警规则需检测节点1在某一时间段内的监控数据,且检测的时间段为5分钟内,5分钟小于预设窗口长度(10分钟),所以,该告警规则为短时间窗口告警规则(窗口规则)。同理,当检测的时间段大于或等于10分钟,告警规则相应的为长时间窗口告警规则(缓存规则)。
可选地,服务器可以通过告警规则中子函数的类型和告警规则中是否存在窗口函数来判断告警规则的类型。
例如,.last为求最新值的子函数,若告警规则中存在.last,则告警规则是时间窗口为0的告警规则。窗口函数WindowSize为表征时间窗口长度的子函数,若告警规则中存在该子函数,则告警规则为短时间窗口告警规则或者长时间窗口告警规则。具体属于哪种告警规则,需结合窗口函数的具体参数,例如,"WindowSize":600,即时间窗口长度为600秒,由于600秒等于预设窗口长度(10分钟),所以,该告警规则为长时间窗口告警规则。
S403、计算节点从服务器获取预设类型告警规则。
具体地,计算节点获取预设类型告警规则可以实现为:
S403a、服务器向HDFS集群发送分类后的告警规则。
其中,S403a可由图2所述服务器中的通信接口22执行。
可选地,在服务器接收到用户输入的更新的告警规则配置指令之后,将更新的告警规则发送给HDFS集群。其中,服务器可以先将更新的告警规则存储至数据库中,然后,将更新的告警规则发送给HDFS集群,以使得HDFS集群同步该更新的告警规则。
作为另一种可能的实施方式,由HDFS向服务器发起告警规则请求。具体地,可以在HDFS集群中设置定时器,并为定时器设置定时时长,当达到定时时长,定时器触发HDFS集群检测上述数据库,若数据库中存在更新的告警规则,则HDFS集群获取更新的告警规则。示例性地,定时时长设置为10秒,HDFS集群每隔10秒执行一次检测数据库中是否存在更新的告警规则的操作。具体定时时长可根据实际实施场景确定,本申请实施例不对此进行限制。
可选地,HDFS集群获取更新的告警规则之后,按照告警规则的类型存储告警规则。具体地,HDFS集群将时间窗口为0的告警规则存储至第一存储空间,且存储的文件名称可以为alarmRule_0;短时间窗口告警规则存储至第二存储空间,且存储的文件名称可以为alarmRule_time_short;将长时间窗口告警规则存储至第三存储空间,且存储的文件名称可以为alarmRule_time_long。
S403b、计算节点从HDFS集群中获取预设类型告警规则。
其中,S403b可由图2所述计算节点中的通信接口22执行。
在一种可能的实现方式中,计算节点中存储有预设类型告警规则的存储地址,并根据存储的预设类型告警规则的存储地址,从HDFS集群中获取预设类型告警规则。假定时间窗口为0的告警规则存储在HDFS集群中的第一存储空间中,该第一存储空间对应第一存储地址;短时间窗口告警规则存储在HDFS集群中的第二存储空间中,该第二存储空间对应第二存储地址;长时间窗口告警规则存储在HDFS集群中的第三存储空间中,该第三存储空间对应第三存储地址。示例地,第一计算节点中存储有第一存储地址,从而第一计算节点可以从HDFS集群的第一存储空间中读取更新的瞬时规则。同样地,第二计算节点中存储有第二存储地址,并从第二存储空间中读取更新的窗口规则,第三计算节点中存储有第三存储地址,并从第三存储空间中读取更新的缓存规则。其中,计算节点从HDFS集群中获取告警规则的具体方式可以为:计算节点中设置有定时器,并为定时器设置定时时长,当达到定时时长,定时器触发计算节点,使得计算节点检查HDFS集群中的告警规则,若HDFS集群中存在更新的告警规则,则计算节点从HDFS集群中获取该更新的告警规则。示例性地,定时时长设置为10秒,计算节点每隔10秒执行一次检测HDFS集群中是否存在更新的告警规则的操作。具体定时时长可根据实际实施场景确定,本申请实施例不对此进行限制。
上述以计算节点存储一种预设类型告警规则为例对计算节点获取预设类型告警规则的方式进行说明,除此之外,在本申请实施例中,计算节点中还可以分别存储多个告警规则对应的存储地址。例如,计算节点1中分别存储有瞬时规则和窗口规则对应的存储地址。
在另一种可能的实现方式中,计算节点获取HDFS集群中的告警规则可以实现为:HDFS集群在获取到服务器或者数据库中的更新的告警规则之后,通过HDFS集群与计算节点之间的告警规则同步接口,向计算节点发送更新的告警规则。
需要说明的是,除了上述先由HDFS集群从服务器中获取分类后的告警规则,再由计算节点从HDFS集群中获取预设类型告警规则的方式外,计算节点还可以直接从服务器获取预设类型告警规则。
可选地,若服务器中存在更新的告警规则,则服务器按照该更新的告警规则的类型,将该更新的告警规则下发给对应的计算节点。例如,用户通过服务器UI输入告警规则配置指令为服务器配置更新的告警规则,该告警规则为瞬时规则,则服务器将瞬时规则下发给对应的计算节点,即下发给第一计算节点。
在另一种可能的实现方式中,计算节点直接从服务器中获取预设类型告警规则还可以实现为:可以在计算节点中设置定时器,并为定时器设置定时时长,当达到定时时长,定时器触发计算节点检测上述服务器中的告警规则,若服务器中存在更新的告警规则,并且更新的告警规则为该计算节点对应的预设类型告警规则,则计算节点获取更新的告警规则。示例性地,定时时长设置为10秒,计算节点每隔10秒执行一次检测服务器中是否存在更新的告警规则的操作。具体定时时长可根据实际实施场景确定,本申请实施例不对此进行限制。
可以理解的是,经S401至S403,计算节点中存储有相应的预设类型告警规则。具体地,第一计算节点中存储有瞬时规则,第二计算节点中存储有窗口规则,第三计算节点中存储有缓存规则。
可以理解的是,当计算节点中存储有相应的预设类型告警规则之后,计算节点可以根据预设类型告警规则进行告警判定。相应地,在本申请实施例的另一种实现方式中,对计算节点进行告警判定的具体流程进行说明,如图5所示,该方法包括:
S501、计算节点根据存储的预设类型告警规则获取与预设类型告警规则对应的监控数据,计算节点为告警系统中的任意一个计算节点。
其中,S501可由图2所述计算节点中的通信接口22执行。
具体地,计算节点根据预设类型告警规则从Kafka中获取与预设类型告警规则对应的监控数据。若预设类型告警规则为时间窗口为0的告警规则(瞬时规则),即计算节点为第一计算节点,则由于告警规则指示需监控节点的当前时刻的预设监控指标,例如,需监控当前时刻的CPU负载值,该计算节点根据告警规则获取实时的监控数据。若预设类型告警规则为短时间窗口告警规则(窗口规则),则计算节点获取短时间窗口对应的时间段内的监控数据,并存储短时间窗口对应的时间段内的监控数据。若预设类型告警规则为长时间窗口告警规则,则获取长时间窗口对应的时间段内的监控数据,并将长时间窗口对应的时间段内的监控数据存储至远程数据服务(Remote Dictionary Server,Redis)数据库中。
其中,对于短时间窗口告警规则,由于时间窗口短,需要获取的监控数据量较小,所以,可以将获取的监控数据存入内存,加快监控数据的处理速度;对于长时间窗口告警规则,由于时间窗口较长,需要获取大量的监控数据,所以采用缓存技术将监控数据存入外挂的Redis数据库中,以提升大数据量场景中监控数据的处理速度。
以短时间窗口计算节点,即第二计算节点获取监控数据为例来说明本步骤(即S501),在经过S401至S403之后,第二计算节点存储有预设类型告警规则,即短时间窗口告警规则,该预设类型告警规则为“监控节点1在5分钟内的平均流量,若流量大于50KB,进行告警”,则第二计算节点根据该预设类型告警规则收集节点1的监控数据。
S502、计算节点根据预设类型告警规则对监控数据进行告警判定。
具体地,S502可以实现为:
S502a、计算节点确定监控数据中各个监控指标的值。
其中,S502a可由图2所述计算节点中的处理器21执行。
其中,监控数据中包含至少一个监控指标。监控指标可以为被监控节点的性能指标,例如,监控指标可以为被监控节点的CPU负载的最新值、CPU使用率的最新值、在预设时间段内CPU负载的均值、在预设时间段内CPU使用率的均值等。
通常,不同类型告警规则对应的监控数据中监控指标有所不同。例如,瞬时规则为“监控节点1的CPU使用率的最新值,当CPU使用率的最新值大于80%时,进行告警”,则根据该瞬时规则,需获取被监控节点的监控指标,其中,监控指标为CPU使用率的最新值。窗口规则为“监控节点1在5分钟内CPU使用率的均值,当CPU使用率的均值大于80%时,进行告警”,则根据该窗口规则,需获取被监控节点的监控指标,其中,监控指标为:在5分钟内CPU使用率的均值。缓存规则为“监控节点1在1小时内CPU使用率的均值,当CPU使用率的均值大于80%时,进行告警”,则根据该缓存规则,需获取被监控节点的监控指标,其中,监控指标为:在1小时内CPU使用率的均值。
假定获取的监控数据为
首先,为了统一监控数据的格式,需对所获取的监控数据进行预处理,假定预处理后的监控数据如下:
其中,预处理监控数据,从而统一监控数据格式的方式可参考现有技术,本申请实施例不再对此进行赘述。
之后,计算节点按照监控指标和被监控节点标识对监控数据进行划分,得到至少一个第一监控数据组,其中,每个第一监控数据组的监控数据中包括的监控指标相同且对应的被监控节点标识相同。结合上述举例,上述获取的两条监控数据可以被表示为如下形式:
如上述监控数据,第一条监控数据item_data1包含的监控指标为system.cpu.load(即CPU负载),item_data1的被监控节点标识为f49aaa48,第二条监控数据item_data2的监控指标为system.cpu.usage(即CPU使用率),item_data2的被监控节点标识也为f49aaa48。由于item_data1和item_data2的监控指标不同,在本申请实施例中,将item_data1和item_data2划分到不同的第一监控数据组中。可选地,分组后,item_data1和item_data2的数据格式如下:
(system.cpu.load@f49aaa48,item_data1)
(system.cpu.usage@f49aaa48,item_data2)
可见,分组之后,第一监控数据组1中包含一个监控数据,即item_data1,第一监控数据组2中包含一个监控数据,即item_data2。可以理解的是,在将上述监控数据进行分组划分之后,具有相同监控指标的数据可以划分到同一组中,加紧了数据之间的联系。
作为另一种可能的实现方式,还可以按照service字段对监控数据进行分组,其中,service字段表征的节点范围为一个集群中全部节点,从而,将一个集群中各个节点的监控数据进行关联,以实现跨主机间的告警判定。
在将监控数据进行上述的分组操作之后,需确定各个第一监控数据组中每个监控数据对应的预设指标的值。结合上述举例,第一监控数据组1包含监控数据item_data1,第一监控数据组2中包含监控数据item_data2,则需确定item_data1中监控指标system.cpu.load的值(即系统CPU负载的值),以及item_data2中system.cpu.usage的值(即系统CPU使用率的值)。具体地,计算节点读取item_data1中监控指标system.cpu.load对应的item_value为16.0,即第一条监控数据item_data1中的预设监控指标的值为16.0,item_data2中监控指标system.cpu.usage对应的item_value为10.0,即第二条监控数据item_data2中的监控指标的值为10.0。
S502b、计算节点根据各个监控指标的值,分别确定各个监控指标对应的子表达式的值。
其中,S502b可由图2所述计算节点中的处理器21执行。
告警规则包括数个子表达式,每一子表达式对应一个监控指标,监控数据包括监控指标。
例如,告警规则如下:
"expression":"{item_key=system.cpu.load:item_value.last}>10&&{item_key=system.cpu.usage:item_value.last}<20"
该告警规则的含义为:当系统CPU负载的最新值大于10,且系统CPU使用率的最新值小于20,进行告警。
则上述告警规则可分解为如下三个部分:
(1)function001={item_key=system.cpu.load:item_value.last}
(2)function002={item_key=system.cpu.usage:item_value.last}
(3)expression=function001>10&&function002<20
令子表达式1为function001>10,子表达式1与CPU负载的最新值有关,即子表达式1对应的监控指标为CPU负载的最新值。子表达式2为function002<20,子表达式2与CPU使用率的最新值有关,即子表达式2对应的监控指标为CPU使用率的最新值。
上述S502a中已经确定出监控数据item_data1中的监控指标system.cpu.load的最新值(即系统CPU负载的最新值)为16.0,以下说明根据监控指标的值确定其对应的子表达式值的方法。
具体地,将监控指标的值(16.0)代入子表达式1(即function001>10,其中,function001={item_key=system.cpu.load:item_value.last}),由于16.0>10,所以子表达式1的值为1(即子表达式1为真),同理,item_data2中的监控指标system.cpu.usage的值为10.0,10.0<20,则子表达式2的值也为1(即子表达式2也为真)。
可选地,在确定监控数据中各个监控指标值之后,还可以执行以下步骤:
计算节点按照获取监控数据的时间和告警规则标识对监控数据进行划分,得到至少一个第二监控数据组;第二监控数据组的监控数据对应的获取时间相同且告警规则标识相同。
即对item_data1和item_data2:
其中,"timestamp"为获取监控数据时对应的时间戳,"alarm_instance_id"为告警规则标识。
由上述item_data1和item_data2的监控数据,item_data1的时间戳(1501758175000)与item_data2的时间戳相同,且item_data1的告警规则标识(466)与item_data2的告警规则标识相同,则可将item_data1和item_data2划分到同一个第二监控数据组中,分组格式如下:
(466@1501758175000,[{"alarm_instance_id":"466","functionid":function001,"value":"16","raw_data":item_data1,"timestamp":1501758175000,"agentSN":"f49aaa48"},{"alarm_instance_id":"466","functionid":function002,"value":"10","raw_data":item_data2,"timestamp":1501758175000,"agentSN":"f49aaa48"}])
S502c、计算节点根据各个监控指标对应的子表达式的值确定预设类型告警规则的值。
其中,S502c可由图2所述计算节点中的处理器21执行。
结合上述举例,expression=function001>10&&function002<20,
子表达式1为function001>10、子表达式2为function002<20,由于子表达式1的值为1,子表达式2的值也为1,子表达式1与子表达式2的逻辑与操作得到的结果仍然为1,即告警规则的值为1。
S502d、若确定预设类型告警规则的值为预设值,则计算节点进行告警。
其中,S502d可由图2所述计算节点中的处理器21执行。
本申请实施例中,预设值通常为1,表征逻辑真。
预设类型告警规则的值可以为0(表征逻辑假)或1(表征逻辑真),通常,当预设类型告警规则的值为1(即逻辑真)时,则进行告警,当计算得到预设类型告警规则的值为0(即逻辑假)时,则不执行告警的动作。结合上述S502d的举例,在确定子表达式:function001>10的值时,由于被监控节点的监控指标值(即CPU负载的最新值)16.0>10,说明当前的CPU负载已经大于10,则进行告警。
与现有技术中,告警系统通常先存储监控数据,再遍历各个告警规则,导致告警判定的效率较低相比,本申请提供的告警判定方法,每个计算节点对应一种类型的告警规则,计算节点根据其对应的告警规则,获取告警规则对应的监控数据,并根据告警规则对监控数据进行告警判定。由于计算节点仅仅获取与其对应的告警规则,相应的,仅仅获取告警规则对应的监控数据。也就意味着,计算节点处理的告警规则和监控数据的数量有所减少,所以能够缩短计算节点告警判定的时间,从而提升告警判定的效率。
本申请实施例可以根据上述方法示例对上述网络设备(网络设备可以为上述计算节点或服务器)进行功能模块或者功能单元的划分,例如,可以对应各个功能划分各个功能模块或者功能单元,也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块或者功能单元的形式实现。其中,本申请实施例中对模块或者单元的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
图6示出了上述实施例中所涉及的告警判定装置的一种可能的结构示意图。如图6所示,该装置作为计算节点60包括:存储单元601、处理单元602和通信单元603。
其中,存储单元601,用于存储预设类型告警规则以及相关指令。处理单元602,用于对计算节点60的动作进行控制管理。例如,处理单元602用于支持计算节点60执行图5中的S501至S502,和/或用于本文所描述的技术方案的其它步骤。通信单元603,用于支持计算节点60与告警系统中的其他设备通信。例如,支持计算节点60执行图4中S403b。
需要说明的是,当图2为计算节点的结构示意图时,所述存储单元601可以实现为图2中的计算节点的存储器。处理单元602可以实现为图2中计算节点的处理器,通信单元603可以实现为图2中计算节点的通信接口。
如图7,本申请实施例还提供一种告警判定装置,该装置作为服务器70包括:存储单元701、处理单元702和通信单元703。
其中,存储单元701,用于存储告警规则以及相关指令。处理单元702,用于对服务器70的动作进行控制管理。例如,处理单元702用于支持服务器70执行图5中的S401、S402和S403a,和/或用于本文所描述的技术方案的其它步骤。通信单元703,用于支持服务器70与告警系统中的其他设备通信。例如,支持服务器70执行图4中S403a。
需要说明的是,当图2为服务器的结构示意图时,所述存储单元701可以实现为图2中的服务器的存储器。处理单元702可以实现为图2中服务器的处理器,通信单元703可以实现为图2中服务器的通信接口。
其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到图6、图7所示装置中对应功能模块的功能描述,在此不再赘述。
本申请实施例还提供一种计算机可读存储介质,计算机可读存储介质中存储有指令,当计算节点执行该指令时,该计算节点执行上述方法实施例所示的方法流程中计算节点执行的各个步骤。
本申请实施例还提供一种计算机可读存储介质,计算机可读存储介质中存储有指令,当服务器执行该指令时,该服务器执行上述方法实施例所示的方法流程中服务器执行的各个步骤。
其中,计算机可读存储介质,例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(Random Access Memory,RAM)、只读存储器(Read-Only Memory,ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory,EPROM)、寄存器、硬盘、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory,CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合、或者本领域熟知的任何其它形式的计算机可读存储介质。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于特定用途集成电路(Application Specific Integrated Circuit,ASIC)中。在本申请实施例中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。