一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

一种限流阈值动态调整方法及装置与流程

2022-09-01 10:32:44 来源:中国专利 TAG:


1.本文涉及报警监控领域,尤其涉及一种限流阈值动态调整方法及装置。


背景技术:

2.随着互联网金融日益发展,各业务系统功能随之不断拓展,为快速、准确地确定异常原因,及时预防生产故障,运维与开发人员配置了多类型的海量监控指标,除常见的交易监控,网络监控,系统监控等,还有大量自定义的故障事件报警,导致监控越来越复杂,监控报警越来越多,发生生产故障时,往往会引发报警风暴现象。这种情况下,监控系统为保证报警时效性,往往会采用限流措施对超出处理能力的大量报警进行直接丢弃。
3.目前常见限流方法为漏桶算法、令牌桶算法、滑动窗口等,或按报警等级限流,按业务系统限流等。以上报警限流方法存在一个共同点,限流阈值固定不变,因此存在如下局限性:次要业务系统占用监控资源,使得重要业务系统报警被丢弃;监控资源空闲时,某些业务系统因报警达到阈值而被丢弃。


技术实现要素:

4.本文用于解决现有技术中限流阈值固定不变的方式对各业务系统的报警信息进行报警存在无法优先处理重要业务系统的报警信息以及报警资源分配不合理的问题。
5.为了解决上述技术问题,本文提供了一种限流阈值动态调整方法,所述方法包括:
6.根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值;
7.由业务系统的优先级、业务系统的各报警类型的报警涨幅值及业务系统中报警信息的报警等级组成业务系统的评价指标;
8.根据各业务系统的评价指标对各预设评判等级的隶属度,构建各业务系统的模糊评价矩阵,其中,所述预设评判等级用于反映各评价指标的重要程度;
9.根据各业务系统的模糊评价矩阵,计算得到各业务系统的报警放行指标值;
10.利用各业务系统的报警放行指标值分配监控系统性能空闲余量,以得到各业务系统的限流阈值;
11.利用各业务系统中各报警类型的权重分配各业务系统的限流阈值,以得到各业务系统中各报警类型的令牌桶阈值。
12.作为本文的进一步实施例中,根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值,包括:
13.按照业务系统及报警类型,对各业务系统最近n个统计周期内的报警信息进行划分,得到多个报警信息组;
14.对各报警信息组进行分析,预测得到各报警信息组的下一统计周期的预测报警量;
15.计算报警信息组的平均报警量;
16.根据各报警信息组的预测报警量和平均报警量,计算得到各报警信息组的报警涨幅值。
17.作为本文进一步实施例中,对各报警信息组进行分析,预测得到各报警信息组的下一统计周期的预测报警量,包括:
18.对每一报警信息组执行如下操作:
19.利用多种预测方法对该报警信息组进行分析,预测得到该报警信息组的下一统计周期的多个预测报警量;
20.从该报警信息组的下一统计周期的多个预测报警量中选择最大值作为该报警信息组的下一统计周期的最终报警量;
21.所述多种预测方法包括:线性回归法、二次指数平滑法、基于时间序列预测法中的至少两个。
22.作为本文进一步实施例中,根据各业务系统的模糊评价矩阵,计算得到各业务系统的报警放行指标值,包括:
23.根据各业务系统的模糊评价矩阵及各评价指标的权重,计算得到各业务系统在各预设评价等级下的综合评价值;
24.根据各业务系统在各预设评价等级下的综合评价值及各预设评判等级的预设值,计算得到各业务系统的报警放行指标值。
25.作为本文进一步实施例中,利用各业务系统的报警放行指标值分配监控系统性能空闲余量,以得到各业务系统的限流阈值包括:利用如下公式计算各业务系统的限流阈值:
[0026][0027]
其中,si为业务系统i的限流阈值,fi为业务系统i的报警放行指标值,n0为业务系统总量,eq为监控系统性能空闲余量,b
t
为基础阈值。
[0028]
作为本文进一步实施例中,利用各业务系统中各报警类型的权重分配各业务系统的限流阈值,以得到各业务系统中各报警类型的令牌桶阈值包括:利用如下公式计算各业务系统中各报警类型的令牌桶阈值:
[0029][0030]
其中,s
ij
为业务系统i报警类型j的令牌桶阈值,aw
ij
为业务系统i报警类型j的权重,m为报警类型总量,si为业务系统i的限流阈值。
[0031]
作为本文进一步实施例中,限流阈值动态调整方法还包括:
[0032]
计算各报警类型的令牌桶阈值总和;
[0033]
通过各报警类型的令牌桶阈值总和占监控系统性能容量比值,调整各报警类型处理作业数量。
[0034]
作为本文进一步实施例中,通过各报警类型的令牌桶阈值总和占监控系统性能容量比值,调整各报警类型处理作业数量包括:利用如下公式计算各报警类型处理作业数量:
[0035][0036]
其中,zj为报警类型j的处理作业数量,为各报警类型的令牌桶阈值总和,m为报警类型总量,s
ij
为业务系统i报警类型j的令牌桶阈值,pc为监控系统的性能容量,q为总作业数量。
[0037]
作为本文进一步实施例中,根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值之前还包括:
[0038]
统计最近一统计周期内各业务系统中各报警类型的报警量;
[0039]
比较各业务系统中各报警类型的报警量与相应的令牌桶阈值确定的报警通过量,若某一业务系统中某一报警类型的报警量小于相应的报警通过量,则执行根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值的步骤。
[0040]
本文的第二方面提供一种限流阈值动态调整装置,包括:
[0041]
报警涨幅计算单元,用于根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值;
[0042]
评价指标构建单元,用于由业务系统的优先级、业务系统的各报警类型的报警涨幅值及业务系统中报警信息的报警等级组成业务系统的评价指标;
[0043]
模糊评价单元,用于根据各业务系统的评价指标对预设评判等级的隶属度,构建各业务系统的模糊评价矩阵,其中,所述预设评判等级用于反映各评价指标的重要程度;
[0044]
报警放行指标计算单元,用于根据各业务系统的模糊评价矩阵值,计算得到各业务系统的报警放行指标值;
[0045]
第一阈值计算单元,用于根据各业务系统的报警放行指标值及监控系统性能空闲余量,计算得到各业务系统的限流阈值;
[0046]
第二阈值计算单元,用于根据各业务系统的限流阈值及各业务系统各报警类型权重,计算并更新各业务系统中各报警类型的令牌桶阈值。
[0047]
本文的第三方面提供一种计算机设备,包括存储器、处理器、以及存储在所述存储器上的计算机程序,所述计算机程序被所述处理器运行时,执行根据前述任一实施例所述方法的指令。
[0048]
本文的第四方面提供一种计算机存储介质,其上存储有计算机程序,所述计算机程序被计算机设备的处理器运行时,执行根据前述任一实施例所述方法的指令。
[0049]
本文提供的限流阈值动态调整方法及装置,通过根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值;计算各业务系统的评价指标(业务系统的优先级、各报警类型的报警涨幅值及业务系统中报警信息的报警等级)对各预设评判等级的隶属度,根据各业务系统的评价指标对各预设评判等级的隶属度构建各业务系统的模糊评价矩阵,进而根据业务系统的模糊评价矩阵计算各业务系统的报警放行指标值;根据各业务系统的报警放行指标值分配监控系统性能空闲余量,以得到各业务系统的限流阈值;根据各业务系统中各报警类型的权重分配各业务系统的限流阈值,以得到各业务系统中各报警类型的令牌桶阈值,能够融合考虑各业务系统报警类型涨幅、业务系统优先级、报警信息的报警等级、监控系统性能空闲余量,动态调整业务系统中各报警类
型的令牌桶阈值,在保证监控系统报警处理效率及整体报警时效性的同时,保障高增长、高优先级及高报警等级的重要报警在发生报警风暴时及时报出,方便后续做关联分析及根因定位。
[0050]
为让本文的上述和其他目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附图式,作详细说明如下。
附图说明
[0051]
为了更清楚地说明本文实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本文的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
[0052]
图1示出了本文实施例限流阈值动态调整方法的第一流程图;
[0053]
图2示出了本文实施例报警涨幅值计算过程的第一流程图;
[0054]
图3示出了本文实施例报警涨幅值计算过程的第二流程图;
[0055]
图4示出了本文实施例报警放行指标值计算过程的流程图;
[0056]
图5示出了本文实施例报警类型阈值韦恩图;
[0057]
图6示出了本文实施例限流阈值动态调整方法的第二流程图;
[0058]
图7示出了本文实施例限流阈值动态调整装置的结构图;
[0059]
图8示出了本文实施例报警信息处理过程的流程图;
[0060]
图9示出了本文实施例计算机设备的结构图。
[0061]
附图符号说明:
[0062]
700、报警涨幅计算单元;
[0063]
701、评价指标构建单元;
[0064]
702、模糊评价单元;
[0065]
703、报警放行指标计算单元;
[0066]
704、第一阈值计算单元;
[0067]
705、第二阈值计算单元;
[0068]
902、计算机设备;
[0069]
904、处理器;
[0070]
906、存储器;
[0071]
908、驱动机构;
[0072]
910、输入/输出模块;
[0073]
912、输入设备;
[0074]
914、输出设备;
[0075]
916、呈现设备;
[0076]
918、图形用户接口;
[0077]
920、网络接口;
[0078]
922、通信链路;
[0079]
924、通信总线。
具体实施方式
[0080]
下面将结合本文实施例中的附图,对本文实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本文一部分实施例,而不是全部的实施例。基于本文中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本文保护的范围。
[0081]
需要说明的是,本文的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
[0082]
本说明书提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的系统或装置产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行。
[0083]
需要说明的是,本文的限流阈值动态调整方法及装置可用于金融领域业务系统的监控系统,也可用于除金融领域之外的任意领域,本文的限流阈值动态调整方法及装置的应用领域不做限定。
[0084]
需要说明的是,本技术所涉及的数据(包括但不限于用于分析的报警信息、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的数据。
[0085]
本文一实施例中,提供一种限流阈值动态调整方法,用于解决现有技术中限流阈值固定不变的方式对各业务系统的报警信息进行报警存在无法优先处理重要业务系统的报警信息以及报警资源分配不合理的问题。具体的,如图1所示,限流阈值动态调整方法包括:
[0086]
步骤101,根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值。
[0087]
步骤102,由业务系统的优先级、业务系统的各报警类型的报警涨幅值及业务系统的报警等级组成业务系统的评价指标。
[0088]
步骤103,根据各业务系统的评价指标对各预设评判等级的隶属度,构建各业务系统的模糊评价矩阵,其中,所述预设评判等级用于反映各评价指标的重要程度。
[0089]
步骤104,根据各业务系统的模糊评价矩阵,计算得到各业务系统的报警放行指标值。
[0090]
步骤105,利用各业务系统的报警放行指标值分配监控系统性能空闲余量,以得到各业务系统的限流阈值。
[0091]
步骤106,利用各业务系统中各报警类型的权重分配各业务系统的限流阈值,以得到各业务系统中各报警类型的令牌桶阈值。
[0092]
步骤106得到各业务系统中各报警类型的令牌桶阈值之后,可利用令牌桶阈值设定令牌桶量,令牌桶阈值为最大报警通过量,每通过一个报警会占用一个令牌,且每隔固定
时间间隔(例如5秒或10秒补充一次)补充一次令牌,令牌补充之后,报警通过量=令牌桶当前余量 令牌补充量。
[0093]
具体的,以某一业务系统的某一报警类型的报警为例,当收到该业务系统的该报警类型的报警信息之后,判断报警量是否小于该业务系统的该报警类型对应的报警通过量,若否,则报警信息将被丢弃,若是,则允许通过报警信息。
[0094]
详细的说,步骤101中,n为正整数,可根据实际需求设定,本文对其具体取值不做限定。统计周期为报警信息的统计时间间隔,即每个统计周期统计一次报警信息,统计周期可根据实际需求进行设定,例如为5s、10s等,本文对统计周期具体取值不做限定。
[0095]
不同业务系统用于处理不同的业务,具体业务视应用场景而定。如表1所示,报警信息至少包括:报警等级、业务系统名称、时间戳、报警类型、报警详情、报警地点及报警量(即报警次数)。
[0096]
表1
[0097][0098]
每一业务系统的报警类型相同,如表2所示,报警类型包括:交易监控报警、批量作业报警、网络故障报警、系统故障报警、异常事件报警,每一报警类型可对应多种报警等级。
[0099]
表2
[0100][0101]
本文所述的报警涨幅值指的是下一统计周期相对于历史统计周期报警量的增幅。
[0102]
本文所述的业务系统的优先级可根据实际情况进行设定,本文对其不做具体限定。例如可根据业务系统的重要程度进行设定,涉及交易、资金等的业务系统相较于其它业务系统重要程度较高,对应的优先级也高。
[0103]
本文所述的预设评判等级可根据需求进行设定,一具体实施方式中,预设评判等级集合可表示为集v={v1,v2,v3,v4,v5},即不重要,次要,普通,优先,重要五个等级。当然,具体实施时,预设评判等级还可有其它划分方式,本文对此不作限定。
[0104]
以报警类型包括交易监控报警、批量作业报警、网络故障报警、系统故障报警、异常事件报警为例,对应的各业务系统的评价指标有7个,如表3所示,评价指标集合可记为u={u1,u2,...,u7}。
[0105]
表3
[0106]
评价指标标号评价指标评判标准u1业务系统优先级按重点、支撑、普通业务系统等定级u2交易报警增速根据该类型报警预测报警涨幅值进行定级u3批量报警增速根据该类型报警预测报警涨幅值进行定级u4网络报警增速根据该类型报警预测报警涨幅值进行定级u5系统报警增速根据该类型报警预测报警涨幅值进行定级u6事件报警增速根据该类型报警预测报警涨幅值进行定级u7报警等级按各等级报警数量直接定级
[0107]
本文所述的业务系统评价指标对各预设评判等级的隶属度即业务系统评价指标属于各预设评判等级的概率,概率评价标准如表3所示。例如u1由业务系统分级直接确定分数,业务系统a为重点业务系统,则业务系统a对预设评判等级集合v的隶属度为r1=[0,0,0,0,1]。u2-u6由预测的报警涨幅值直接确定,报警涨幅值与预设评判等级满足如下表4所示映射关系。
[0108]
表4
[0109][0110][0111]
由此可以确定出的r2-r6,假设为r2=[0,0,1,0,0],r3=[0,0,0,1,0],r4=[0,1,0,0,0],r5=[0,0,0,0,1],r6=[0,0,1,0,0]。u7由各等级报警占比直接确定,假设业务系统仅包含等级最高的两类报警,这两类报警占比为7:3,则可得r7,如r7=[0.7,0.3,0,0,0]。由此,以ri为第i行构成模糊评价矩阵:
[0112][0113]
评价标准中的定级标准反映指标与预设评判等级的对应关系,可根据实际需求进
行设定,本文对此不作限定。评价指标集合、预设评价等级集合及模糊评价矩阵构成了一个模糊综合评判模型,可记为(u,v,r)。
[0114]
本文所述的各业务系统的报警放行指标值能够反映各业务系统最多放行报警量。
[0115]
本文所述的监控系统即运行步骤101至步骤105方法指令的系统,其性能空闲余量指的是cup、内存等的空闲余量。
[0116]
本文所述的各业务系统的限流阈值即各业务系统最多放行报警量。
[0117]
本文所述的各业务系统中各报警类型的权重可通过分析各业务系统产生的各报警类型的分布情况确定,分布量越大,对应的权重越大。
[0118]
本实施例能够融合考虑各业务系统报警类型涨幅、业务系统优先级、报警信息的报警等级、监控系统性能空闲余量,动态调整业务系统中各报警类型的令牌桶阈值,在保证监控系统报警处理效率及整体报警时效性的同时,保障高增长、高优先级及高报警等级的重要报警在发生报警风暴时及时报出,方便后续做关联分析及根因定位。
[0119]
本文一实施例中,如图2所示,上述步骤101根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值,包括:
[0120]
步骤201,按照业务系统及报警类型,对各业务系统最近n个统计周期内的报警信息进行划分,得到多个报警信息组。
[0121]
本步骤实施时,根据报警信息中业务系统标识及报警类型对报警信息进行划分。
[0122]
步骤202,对各报警信息组进行分析,预测得到各报警信息组的下一统计周期的预测报警量。本步骤的具体实施过程参考后续实施例,此处不再详述。
[0123]
步骤203,计算报警信息组的平均报警量。
[0124]
本步骤实施时,先对每个报警信息组中各报警信息中的报警量进行加和处理,然后利用加和值除以报警信息组中报警信息个数,得到平均报警量。
[0125]
步骤204,根据各报警信息组的预测报警量和平均报警量,计算得到各报警信息组的报警涨幅值。
[0126]
具体实施时,每个报警信息组的报警涨幅值计算过程包括:先计算预测报警量与平均报警量之差;然后利用差值除以平均报警量得到报警涨幅值。
[0127]
本文一实施例中,如图3所示,上述步骤202实施过程包括:对每一个报警信息组可执行如下操作:
[0128]
步骤301,利用多种预测方法对该报警信息组进行分析,预测得到该报警信息组的下一统计周期的多个预测报警量;
[0129]
步骤302,从该报警信息组的下一统计周期的多个预测报警量中选择最大值作为该报警信息组的下一统计周期的最终报警量。
[0130]
所述多种预测方法包括:线性回归法、二次指数平滑法、基于时间序列预测法中的至少两个。
[0131]
下面对二次指数平滑法预测下一统计周期的预测报警量进行详细说明:
[0132]
(1)一次指数平滑公式为:
[0133]st 1
=ax
t
(1-a)s
t

[0134]
x
t
为时期t的报警量,可以以每5秒或每10秒为周期统计报警量。
[0135]st
为时期t的预测报警量,s
t 1
为时期t 1的预测报警量,s1可以用第1期的报警量或
最初几期的平均值来代替。
[0136]
a为平滑系数,取值范围0-1,为了反映报警量最新的变化,所以a取较大值,可以取0.9。
[0137]
将s
t
,s
t-1
,...,s2的表达式逐次代入s
t 1
中,得到如下表达式:
[0138]st 1
=ax
t
a(1-a)x
t-1
... a(1-a)
t-1
x1 (1-a)
t
s1;
[0139]
其中,x
t1
为时期t-1的报警量,x1为时期1的报警量。
[0140]
(2)二次指数平滑法公式为:
[0141][0142]st
为t期的一次指数平滑值即时期t的预测报警量,由一次指数平滑法公式计算得出:
[0143]
分别为t期和t

1期的二次指数平滑值;
[0144]
a为平滑系数,取值范围0-1,为了反映报警量最新的变化,所以a取较大值,可以取0.9。
[0145]
(3)二次指数平滑法的预测模型为:
[0146]yt t
=m
t
n
t
t;
[0147]
其中m
t
,n
t
代表参数,由下列公式求得:
[0148][0149]
t为预测超前期数,t取1时,y
t 1
即为下一期预测报警量。
[0150]
因各类型报警互相之间是有关联的,例如系统报警、网络报警的增长可能会引起事件报警、交易报警的增长。所以对各业务系统各类型报警量两两做相关性分析。取两种不同报警类型做因变量y和自变量x,两者之间建立一元线性回归方程,可由自变量x的下一期二次指数平滑法预测值来预测因变量y的下一期报警量,下面对线性回归法预测下一统计周期的预测报警量进行详细说明:
[0151]
(1)相关系数r计算公式,(用∑代替):
[0152][0153]
xi为i期某一类型报警量的值,如系统报警报警量;
[0154]
yi为i期另一类型报警量的值,如交易报警报警量;
[0155]
n为报警统计周期。
[0156]
0《|r|《1,则x与y存在一定的线性相关关系;|r|》0.7,为高度线性相关;0.3《|r|≤0.7,为中度线性相关;|r|≤0.3,为低度线性相关。
[0157]
各类型报警量两两做相关性分析,可得到各类型报警相关性最强的报警类型。
[0158]
(2)一元线性回归分析法预测模型为:
[0159]yt
=a bx
t

[0160]
x
t
为t期关联类型报警量的值;
[0161]yt
为t期被预测类型报警量的值;
[0162]
a,b代表一元线性回归方程的参数,由下列公式求得:
[0163]
将a、b代入一元线性回归方程,只要给定关联类型报警的下一期二次指数平滑法预测值,即可求出被预测类型报警的线性回归预测值。
[0164]
本文一实施例中,如图4所示,步骤104根据各业务系统的模糊评价矩阵,计算得到各业务系统的报警放行指标值,包括:
[0165]
步骤401,根据各业务系统的模糊评价矩阵及各评价指标的权重,计算得到各业务系统在各预设评价等级下的综合评价值。
[0166]
其中,以表3所示评价指标为例,则评价指标的权重集记为:a={a1,a2,...,a7},且满足其中,n1为评价指标总个数。
[0167]
通过对各评价指标的权重与各业务系统的模糊评价矩阵进行点乘处理,计算得到各业务系统在各预设评价等级下的综合评价值。
[0168]
假设某一业务系统的模糊评价矩阵为r,则该业务系统的综合评价值b=ar,b={b1,b2,...,b5}。
[0169]
步骤402,根据各业务系统在各预设评价等级下的综合评价值及各预设评判等级的预设值,利用如下公式计算得到各业务系统的报警放行指标值:
[0170]
f=bs;
[0171]
其中,f为报警放行指标值,b为综合评价值,s为预设评价等级的预设值(对应等级的级分),假设预设评判等级集合可表示为集v={v1,v2,v3,v4,v5},即不重要,次要,普通,优先,重要五个等级,则对应的s=(20,40,60,80,100)。具体实施时,可按预设评价等级的重要程度设定各评价等级的预设值,重要程度越高,对应的预设值也越高,本文对其具体值不做限定。
[0172]
本文一实施例中,步骤105利用各业务系统的报警放行指标值分配监控系统性能空闲余量(如图5所示),以得到各业务系统的限流阈值包括:将监控系统处理上限减去为各业务系统保留的基础阈值后的性能空闲余量,按各业务系统报警放行指标得分进行分配,具体的,利用如下公式计算各业务系统的限流阈值:
[0173][0174]
其中,si为业务系统i的限流阈值,fi为业务系统i的报警放行指标值,n0为业务系统总量,eq为监控系统性能空闲余量,b
t
为基础阈值。
[0175]
具体的,监控系统性能空闲余量可由监控系统所在部署平台提供的及分配的cpu、内存等资源决定,是一个确定值,具体数值及使用率可以由部署平台直接获取
[0176]
基础阈值能够为业务系统资源提供最低保障,假设监控系统允许的总量为n,业务系统共m个,各系统基础阈值=(n
×
5%)/m,即基础阈值为系统总量的5%平分到各个业务
系统的放行量。
[0177]
本文一实施例中,上述步骤106利用各业务系统中各报警类型的权重分配各业务系统的限流阈值,以得到各业务系统中各报警类型的令牌桶阈值包括:利用如下公式计算各业务系统中各报警类型的令牌桶阈值:
[0178][0179]
其中,s
ij
为业务系统i报警类型j的令牌桶阈值,aw
ij
为业务系统i报警类型j的权重,m为报警类型总量,si为业务系统i的限流阈值。
[0180]
具体实施时,各业务系统中报警类型的权重由运维人员根据报警类型报警量确定,本文对其取值不做具体限定。
[0181]
具体实施时,监控系统还可以定制权重,各报警类型报警通过量和各报警类型报警相关性进行实时显示。运维人员可以通过调整报警类型权重,改变各类型报警的通过比例。
[0182]
本文一实施例中,为了提升报警处理能力,为各系统及各报警类型的报警分配适合的处理资源,如图6所示,限流阈值动态调整方法除了包括上述步骤101至步骤105外,还包括利用各类型报警占监控系统性能容量比例,同步调整各类型报警处理作业比例,具体的,限流阈值动态调整方法还包括:
[0183]
步骤107,计算各报警类型的令牌桶阈值总和。
[0184]
步骤108,通过各报警类型的令牌桶阈值总和占监控系统性能容量比值,调整各报警类型处理作业数量。具体的,利用如下公式计算各报警类型处理作业数量:
[0185][0186]
其中,zj为报警类型j的处理作业数量,为各报警类型的令牌桶阈值总和,m为报警类型总量,s
ij
为业务系统i报警类型j的令牌桶阈值,pc为监控系统的性能容量,q为总作业数量,可直接查询得到。
[0187]
具体实施时,如果系统性能容量进行了扩容,性能空闲余量与可分配的报警处理作业数量同步提升。
[0188]
本文一实施例中,图1所示方法可每隔固定时间间隔执行一次,还可通过如下方式确定是否执行:统计最近一统计周期内各业务系统中各报警类型的报警量;
[0189]
比较各业务系统中各报警类型的报警量与相应的令牌桶阈值确定的报警通过量,若某一业务系统中某一报警类型的报警量小于相应的报警通过量,则说明报警量仍有余量,则执行图1所示重新确定各业务系统中各报警类型的根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统下各报警类型的报警信息的令牌桶阈值。
[0190]
本文通过对报警增长情况的实时预测,使高增长的应用占用更多资源,保障了报警的通过率,并且通过对各业务系统报警放行指标分数的计算,合理分配监控系统空闲资源,使高优先级应用的报警、重要报警类型的报警、高等级的报警能得到处理保障,能够达到很好的监控效果。
[0191]
基于同一发明构思,本文还提供一种限流阈值动态调整装置,如下面的实施例所述。由于限流阈值动态调整装置解决问题的原理与限流阈值动态调整方法相似,因此,限流阈值动态调整装置的实施可以参见限流阈值动态调整方法,重复之处不再赘述。
[0192]
具体的,如图7所示,限流阈值动态调整装置包括:
[0193]
报警涨幅计算单元700,用于根据各业务系统最近n个统计周期内的报警信息,预测得到各业务系统中各报警类型的报警涨幅值;
[0194]
评价指标构建单元701,用于由业务系统的优先级、业务系统的各报警类型的报警涨幅值及业务系统中报警信息的报警等级组成业务系统的评价指标;
[0195]
模糊评价单元702,用于根据各业务系统的评价指标对预设评判等级的隶属度,构建各业务系统的模糊评价矩阵,其中,所述预设评判等级用于反映各评价指标的重要程度;
[0196]
报警放行指标计算单元703,用于根据各业务系统的模糊评价矩阵值,计算得到各业务系统的报警放行指标值;
[0197]
第一阈值计算单元704,用于利用各业务系统的报警放行指标值分配监控系统性能空闲余量,以得到各业务系统的限流阈值;
[0198]
第二阈值计算单元705,用于利用各业务系统的限流阈值分配各业务系统各报警类型权重,以得到并更新各业务系统中各报警类型的令牌桶阈值。
[0199]
本实施例通过能够融合考虑各业务系统报警类型涨幅、业务系统优先级、报警信息的报警等级、监控系统性能空闲余量,动态调整业务系统中各报警类型的令牌桶阈值,在保证监控系统报警处理效率及整体报警时效性的同时,保障高增长、高优先级及高报警等级的重要报警在发生报警风暴时及时报出,方便后续做关联分析及根因定位。
[0200]
为了更清楚说明本文技术方案,下面以一具体实施例说明报警信息处理过程。具体的,如图8所示,报警信息处理过程包括:
[0201]
步骤801,接收各业务系统发送的待处理报警信息;
[0202]
步骤802,利用现有令牌桶策略限流,即判断各业务系统发送的各报警类型的报警量是否在报警通过量(令牌桶当前余量 令牌补充量)的范围内,若是,则执行步骤803,若否,则执行步骤804;
[0203]
步骤803,通过报警通过量内的报警报文,超过报警通过量的报警报文丢弃;
[0204]
步骤804,利用二次指数平滑法预测各业务系统中各报警类型的报警涨幅值,利用一元线性回归法预测各业务系统中各报警类型的报警涨幅值,选择各业务系统中各报警类型的两个报警涨幅值最大者作为最终确定的涨幅值,即预测报警量=max(二次指数平滑法预测值,线性回归预测值);
[0205]
步骤805,计算各业务系统的评价指标对各预设评判等级的隶属度,根据各业务系统的评价指标对各预设评判等级的隶属度构建各业务系统的模糊评价矩阵,根据各业务系统的模糊评价矩阵,计算得到各业务系统的报警放行指标值;
[0206]
步骤806,利用各业务系统的报警放行指标值分配监控系统性能空闲余量,以得到各业务系统的限流阈值;
[0207]
步骤807,利用各业务系统中各报警类型的权重分配各业务系统的限流阈值,以得到各业务系统中各报警类型的令牌桶阈值;
[0208]
步骤808,更新各业务系统中各报警类型的令牌桶阈值;
[0209]
步骤809,通过各报警类型的令牌桶阈值总和占监控系统性能容量比值,调整各报警类型处理作业数量。
[0210]
本文通过对报警增长情况的实时预测,使高增长的报警占用更多资源,保障了报警的通过率,并且通过对各业务系统报警放行指标值的计算,合理分配监控系统空闲资源,使高优先级应用的报警、重要报警类型的报警、高等级的报警能得到处理保障,能够达到很好的监控效果。
[0211]
本文一实施例中,还提供一种计算机设备,具体的,如图9所示,计算机设备902可以包括一个或多个处理器904,诸如一个或多个中央处理单元(cpu),每个处理单元可以实现一个或多个硬件线程。计算机设备902还可以包括任何存储器906,用于存储上述任一实施例所示方法指令的计算机程序,还用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的,比如,存储器906可以包括以下任一项或多种组合:任何类型的ram,任何类型的rom,闪存设备,硬盘,光盘等。更一般地,任何存储器都可以使用任何技术来存储信息。进一步地,任何存储器可以提供信息的易失性或非易失性保留。进一步地,任何存储器可以表示计算机设备902的固定或可移除部件。在一种情况下,当处理器904执行被存储在任何存储器或存储器的组合中的相关联的指令时,计算机设备902可以执行相关联指令的任一操作。计算机设备902还包括用于与任何存储器交互的一个或多个驱动机构908,诸如硬盘驱动机构、光盘驱动机构等。
[0212]
计算机设备902还可以包括输入/输出模块910(i/o),其用于接收各种输入(经由输入设备912)和用于提供各种输出(经由输出设备914))。一个具体输出机构可以包括呈现设备916和相关联的图形用户接口918(gui)。在其他实施例中,还可以不包括输入/输出模块910(i/o)、输入设备912以及输出设备914,仅作为网络中的一台计算机设备。计算机设备902还可以包括一个或多个网络接口920,其用于经由一个或多个通信链路922与其他设备交换数据。一个或多个通信总线924将上文所描述的部件耦合在一起。
[0213]
通信链路922可以以任何方式实现,例如,通过局域网、广域网(例如,因特网)、点对点连接等、或其任何组合。通信链路922可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。
[0214]
对应于图1-图4、图6中的方法,本文实施例还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法的步骤。
[0215]
本文实施例还提供一种计算机可读指令,其中当处理器执行所述指令时,其中的程序使得处理器执行如图1-图4、图6所示的方法。
[0216]
应理解,在本文的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本文实施例的实施过程构成任何限定。
[0217]
还应理解,在本文实施例中,术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系。例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
[0218]
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件
和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本文的范围。
[0219]
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
[0220]
在本文所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接,也可以是电的,机械的或其它的形式连接。
[0221]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。
[0222]
另外,在本文各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
[0223]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本文的技术方案本质上或者说对现有技术做出贡献的部分,或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-only memory)、随机存取存储器(ram,random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0224]
本文中应用了具体实施例对本文的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本文的方法及其核心思想;同时,对于本领域的一般技术人员,依据本文的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本文的限制。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献