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

一种变更监控方法、系统及装置与流程

2022-08-17 11:08:31 来源:中国专利 TAG:


1.本技术涉及计算机处理技术领域,尤其涉及一种变更监控方法、系统及装置。


背景技术:

2.在现网中,为了确保变更系统的变更质量,用户可以使用一个或多个监控系统来进行监控。然而,面向用户的变更系统与监控系统两者之间相互隔离,需要用户在变更系统上操作后,再于监控系统中进行删除或添加监控指标,导致对用户临时增加巨大的工作量,观察期人工观察也需要大量的人力成本;而且由于人工临时添加监控指标,可能存在由于添加监控指标不完整,导致监控场景有所缺失。另外,监控系统日常只对系统级指标进行监控,监控粒度较大,变更引发的问题可能不会在系统级监控体现出来,导致告警存在漏告以及误告的问题;而且当系统级指标出现异常时,运维人员已在变更系统对整个任务处理流完成变更操作,对异常定位的过程不仅将花费很长时间,也由于监控粒度较大,监控系统并未记录任务处理流中一些细节信息,导致问题定位困难。


技术实现要素:

3.本技术提供一种变更监控方法、系统及装置,能够避免运维人员在变更系统操作后再在监控系统进行操作,减少运维人员工作量,通过降低监控粒度,减少异常定位所花费的时间,提升问题定位效率。
4.一方面,本技术提供了一种变更监控方法,所述方法包括:
5.第一系统在对变更任务流中当前变更对象的变更操作执行成功后,向告警中间件发送变更成功消息,所述变更成功消息携带所述当前变更对象的变更对象标识;
6.所述告警中间件将携带有所述变更对象标识的添加监控请求发送至第二系统;
7.所述第二系统基于所述添加监控请求,添加对所述当前变更对象的监控;
8.若所述第二系统监测到针对所述当前变更对象的告警信息,则向所述告警中间件发布所述告警信息;
9.所述告警中间件在确定所述告警信息满足预设收敛条件时,获取所述告警信息对应的告警方式,并在判定所述告警方式表征停止变更时,向所述第一系统发送停止变更指令;
10.所述第一系统基于所述停止变更指令,停止执行所述变更任务流中未变更对象的变更操作。
11.另一方面提供了一种变更监控方法,所述方法包括:
12.接收来自第一系统的变更成功消息,所述变更成功消息指示所述第一系统对变更任务流中的当前变更对象的变更操作执行成功,所述变更成功消息携带所述当前变更对象的变更对象标识;
13.将携带有所述变更对象标识的添加监控请求发送至第二系统,以使所述第二系统添加对所述当前变更对象的监控;
14.接收来自所述第二系统针对所述当前变更对象的告警信息,确定所述告警信息是否满足预设收敛条件;
15.在所述告警消息满足所述预设收敛条件时,获取所述告警信息对应的告警方式;
16.若所述告警方式指示停止变更,则向所述第一系统发送停止变更指令,以使所述第一系统停止执行所述变更任务流中未变更对象的变更操作。
17.另一方面提供了一种变更监控系统,所述系统包括第一系统、告警中间件和第二系统;
18.所述第一系统用于在对变更任务流中当前变更对象的变更操作执行成功后,向所述告警中间件发送变更成功消息,所述变更成功消息携带所述当前变更对象的变更对象标识;
19.所述告警中间件用于将携带有所述变更对象标识的添加监控请求发送至所述第二系统;
20.所述第二系统用于基于所述添加监控请求,添加对所述当前变更对象的监控;
21.所述第二系统还用于在监测到针对所述当前变更对象的告警信息时,向所述告警中间件发布所述告警信息;
22.所述告警中间件还用于在确定所述告警信息满足预设收敛条件时,获取所述告警信息对应的告警方式,并在判定所述告警方式表征停止变更时,向所述第一系统发送停止变更指令;
23.所述第一系统还用于基于所述停止变更指令,停止执行所述变更任务流中未变更对象的变更操作。
24.另一方面提供了一种变更监控装置,所述装置包括:
25.第一消息接收模块,用于接收来自第一系统的变更成功消息,所述变更成功消息指示所述第一系统对变更任务流中的当前变更对象的变更操作执行成功,所述变更成功消息携带所述当前变更对象的变更对象标识;
26.添加监控请求模块,用于将携带有所述变更对象标识的添加监控请求发送至第二系统,以使所述第二系统添加对所述当前变更对象的监控;
27.告警消息接收模块,用于接收来自所述第二系统针对所述当前变更对象的告警信息,确定所述告警信息是否满足预设收敛条件;
28.告警消息处理模块,用于在所述告警消息满足所述预设收敛条件时,获取所述告警信息对应的告警方式;
29.第一消息发送模块,用于在所述告警方式指示停止变更的情况下,向所述第一系统发送停止变更指令,以使所述第一系统停止执行所述变更任务流中未变更对象的变更操作。
30.本技术通过第一系统对变更对象进行变更操作后,由告警中间件自动向第二系统添加针对变更对象的监控请求,而不需要用户手动添加监控指标,减少用户的工作量的同时,可以避免由于额外添加监控指标所导致的覆盖场景不全的问题;而且将系统级监控粒度细化到对象级监控粒度,可以更精细化的对变更后的质量进行监控;在出现告警时,可以通过告警中间件做智能分析,在出现需要停止变更的告警信息时,可以通知第一系统立即停止变更任务流中未变更对象的变更操作,从而使告警问题定位更加收敛,减少异常定位
所花费的时间,提升问题定位效率和运营效率。
附图说明
31.为了更清楚地说明本技术实施例或现有技术中的技术方案和优点,下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本技术的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它附图。
32.图1是本技术实施例提供的一种变更监控系统的示意图。
33.图2是本技术实施例提供的一种变更监控方法的流程示意图。
34.图3是本技术实施例提供的添加监控策略的一个界面示例图。
35.图4是本技术实施例提供的另一种变更监控方法的流程示意图。
36.图5是本技术实施例提供的另一种变更监控方法的流程示意图。
37.图6是本技术实施例提供的变更计划配置的界面示意图。
38.图7是本技术实施例提供的另一种变更监控方法的流程示意图。
39.图8是本技术实施例提供的另一种变更监控方法的流程示意图。
40.图9是本技术实施例提供的建立第一处理任务的流程示意图。
41.图10是本技术实施例提供的监控组划分的一个示例图。
42.图11是本技术实施例提供的告警中间件的架构示意图。
43.图12是本技术实施例提供的另一种变更监控方法的流程示意图。
44.图13是本技术实施例提供的另一种变更监控方法的流程示意图。
45.图14是本技术实施例提供的一种变更监控装置的结构示意图。
46.图15是本技术实施例提供的一种用于实现本技术实施例所提供的方法的设备的硬件结构示意图。
具体实施方式
47.云技术(cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术。
48.云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用,将来每个物品都有可能存在自己的识别标志,都需要传输到后台系统进行逻辑处理,不同程度级别的数据将会分开处理,各类行业数据皆需要强大的系统后盾支撑,只能通过云计算来实现。
49.本技术实施例提供的技术方案涉及云技术的云应用领域中的云安全(cloud security)。云安全是指基于云计算商业模式应用的安全软件、硬件、用户、机构、安全云平台的总称。云安全融合了并行处理、网格计算、未知病毒行为判断等新兴技术和概念,通过网状的大量客户端对网络中软件行为的异常监测,获取互联网中木马、恶意程序的最新信息,并发送到服务端进行自动分析和处理,再把病毒和木马的解决方案分发到每一个客户端。
50.现网中,面向用户的变更系统与监控系统两者之间相互隔离,需要用户在变更系统上操作后,再于监控系统中进行删除或添加监控指标,导致对用户临时增加巨大的工作量,观察期人工观察也需要大量的人力成本;而且由于人工临时添加监控指标,可能存在由于添加监控指标不完整,导致监控场景有所缺失。另外,监控系统日常只对系统级指标进行监控,监控粒度较大,变更引发的问题可能不会在系统级监控体现出来,导致告警存在漏告以及误告的问题;而且当系统级指标出现异常时,运维人员已在变更系统对整个任务处理流完成变更操作,对异常定位的过程不仅将花费很长时间,也由于监控粒度较大,监控系统并未记录任务处理流中一些细节信息,导致问题定位困难。
51.鉴于此,本技术实施例提供了一种变更监控方法,该方法通过监控系统为变更系统的变更提供云安全服务。通过提供的云安全服务,运维人员不需要在变更系统操作后再在监控系统进行额外操作,减少运维人员工作量,通过降低监控粒度,减少异常定位所花费的时间,提升问题定位效率。
52.为使本技术的目的、技术方案和优点更加清楚,下面将结合附图对本技术作进一步地详细描述。显然,所描述的实施例仅仅是本技术的一部分实施例,而不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本技术保护的范围。
53.需要说明的是,本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
54.请参阅图1,其示出了本技术实施例提供的一种变更监控系统的示意图,如图1所示,该系统可以包括第一系统10、告警中间件20、以及一个或多个(途中采用30a、30b,
……
,30n来示出)第二系统30。
55.第一系统10是指现网进行变更的系统,可以根据第一系统10实现对各个变更对象的变更;第二系统30是指现网进行指标数据上报和监控告警的系统,可以根据第二系统30实现对各个变更对象的变更质量的监控。用户在第一系统10对各个变更对象进行变更操作后,通过告警中间件20自动向第二系统30发送添加告警请求,以使第二系统30监控变更对象的变更质量,为变更对象提供云安全服务。其中,第一系统10、告警中间件20和第二系统30均可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。
56.具体的,第一系统10用于在对变更任务流中当前变更对象的变更操作执行成功后,向告警中间件20发送变更成功消息,变更成功消息携带当前变更对象的变更对象标识;告警中间件20用于将携带有变更对象标识的添加监控请求发送至第二系统30;第二系统30用于基于添加监控请求,添加对当前变更对象的监控;第二系统30还用于在监测到针对当前变更对象的告警信息时,向告警中间件发布告警信息;告警中间件20还用于在确定告警信息满足预设收敛条件时,获取告警信息对应的告警方式,并在判定告警方式表征停止变
更时,向第一系统10发送停止变更指令;第一系统10还用于基于停止变更指令,停止执行变更任务流中未变更对象的变更操作。
57.第二系统30在添加对当前变更对象的监控时,会将添加结果反馈至告警中间件20,由告警中间件20基于反馈结果进行相应的处理。具体的,第二系统30还用于在成功添加对当前变更对象的监控时,向告警中间件20发送添加成功消息;告警中间件20接收到添加成功消息后,获取当前变更对象的实际监控时长,并在实际监控时长达到当前变更对象的预设监控时长后,向第二系统30发送删除监控请求;第二系统30基于删除监控请求,删除对当前变更对象的监控。
58.下面结合图1所示的系统,对本技术的一种变更监控方法进行进一步介绍。图2是本技术实施例提供的一种变更监控方法的流程示意图,本说明书提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的系统或服务器产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示,该方法可以包括:
59.s201,第一系统在对变更任务流中当前变更对象的变更操作执行成功后,向告警中间件发送变更成功消息。
60.本技术实施例中,变更操作可以是版本变更、配置变更或者扩容等操作,这些变更操作的实施对象即为变更对象。第一系统在执行对各个变更对象的变更操作时,为了能够在变更过程出现异常时及时停止变更操作,可以采用灰度部署的方式,也即将各个变更对象分批次进行变更,然后由所有批次的变更构成一个变更任务流。例如总共有1000个需要变更的变更对象,若分成10批,那么可由这10批构成一个变更任务流,每一批次变更可以看成是变更任务流中的一次任务,每次任务可以变更一个或多个变更对象。
61.为了避免系统级监控的监控粒度大所带来的问题定位难等系列问题,第一系统采用对象级的监控粒度,也即第一系统在对每个变更对象的变更操作执行成功后,均会向告警中间件发送变更成功消息,从而可以使第二系统对每个变更对象进行监控。其中,变更成功消息携带当前变更对象的变更对象标识,变更对象标识用于对变更对象进行唯一性识别。例如在变更对象标识是设备时,变更对象标识可以是设备ip。
62.s203,告警中间件将携带有变更对象标识的添加监控请求发送至第二系统。
63.告警中间件接收到变更成功消息后,获取变更成功消息中的变更对象标识,然后将该变更对象标识封装在添加监控请求中,并将该添加监控请求发送至第二系统。
64.s205,第二系统基于添加监控请求,添加对当前变更对象的监控。
65.第二系统中存储有每个变更对象的监控策略,监控策略是用户在进行变更操作前预先进行配置的,监控策略中包括一个或多个监控项,每个监控项包括一个或多个监控指标。第二系统接收到添加监控请求后,可以获取与添加监控请求中的变更对象标识匹配的监控策略,根据该监控策略添加对当前变更对象的监控。
66.如图3所示,其为添加监控策略的一个界面示例图。用户可以在第二系统对应的客户端,或者在告警中间件对应的客户端中,用户可以在该界面中添加业务指标,选择红线规则和指标模板,然后向第二系统或告警中间件发送监控配置请求。第二系统或告警中间件
接收到监控配置请求后,基于监控配置请求中所添加的业务指标、红线规则以及指标模板为每个变更对象生成监控策略,并建立变更对象与监控策略之间的映射关系;第二系统获取到添加监控请求后,获取与当前变更对象对应的监控策略,基于该策略添加对当前变更对象的监控。
67.s207,若第二系统监测到针对当前变更对象的告警信息,则向告警中间件发布告警信息。
68.由于第二系统与第一系统相互隔离,当第二系统监测到针对当前变更对象的告警信息时,直接向告警中间件发布告警信息,由告警中间件对告警信息做策略收敛处理,以确定是否停止对变更任务流中剩余任务中的未变更对象的变更操作。
69.s209,告警中间件在确定告警信息满足预设收敛条件时,获取告警信息对应的告警方式,并在判定告警方式表征停止变更时,向第一系统发送停止变更指令。
70.告警中间件中存储有每个变更对象在产生告警后的处理策略,例如每个监控项对应的告警方式和告警收敛条件等等。告警收敛条件用于判断告警信息是否有效,一些变更对象产生的告警并不对变更系统的变更质量产生影响,甚至可以忽略,通过告警收敛条件可以避免误报。
71.告警中间件所提供的告警方式可以包括停止变更以及通知用户,停止变更和通知用户可以同时存在,也即可以在停止变更的同时通知用户。其中,通知用户的方式可以是电话、微信、短信以及邮件等等,本技术对此不做具体限定。
72.告警信息中包括一个或多个监控项所产生的告警内容,每个监控项都有对应的告警收敛条件。告警中间件在接收到告警信息后,可以判断每个监控项所产生的告警内容是否均满足其对应的告警收敛条件;如果均满足,则可判定告警信息满足预设收敛条件。
73.告警中间件在获取告警信息对应的告警方式时,可以基于告警信息中每个监控项对应的告警方式进行确定,只要有一个监控项对应的告警方式表征停止变更,则整个告警信息对应的告警方式为停止变更。在确定告警信息对应的告警方式表征停止变更时,向第一系统发送停止变更指令。
74.s211,第一系统基于停止变更指令,停止执行变更任务流中未变更对象的变更操作。
75.通过第一系统对变更对象进行变更操作后,由告警中间件自动向第二系统添加针对变更对象的监控请求,而不需要用户手动添加监控指标,减少用户的工作量的同时,可以避免由于临时添加监控指标所导致的覆盖场景不全的问题;而且将系统级监控粒度细化到对象级监控粒度,可以更精细化的对变更后的质量进行监控;在出现告警时,可以通过告警中间件做智能分析,当出现需要停止变更的告警信息时,可以通知第一系统立即停止变更任务流中未变更对象的变更操作,从而使告警问题定位更加收敛,减少异常定位所花费的时间,提升问题定位效率和运营效率。
76.在实际应用中,第二系统在执行步骤s205添加对当前变更对象的监控时,可能包含添加成功和添加失败两种情况,但无论是添加成功还是添加失败,均会异步返回响应信息给告警中间件,以使告警中间建可以基于响应信息做进一步操作。而且对于一个变更对象的变更质量的监控,在观察期之后变更质量趋于稳定。为了节省系统资源,在观察期后,第二系统可以不需要再继续对变更对象进行监控。
77.鉴于此,在一个可能的实施方式中,如图4所示,在步骤s205实施之后,该方法还可以包括:
78.s2061,第二系统若成功添加对当前变更对象的监控,则向告警中间件发送添加成功消息。
79.其中,添加成功消息中携带变更对象标识。
80.s2062,告警中间件接收到添加成功消息后,记录当前变更对象的实际监控时长,并在实际监控时长到达当前变更对象的预设监控时长后,向第二系统发送删除监控指令。
81.告警中间件中存储有每个变更对象的预设监控时长,预设监控时长是在对监控策略进行配置时用户所设置的,预设监控时长用于指示当前变更对象的监控生命周期也即观察期,告警中间件可以通过添加成功消息中的变更对象标识获取当前变更对象的预设监控时长。告警中间件在接收到添加成功消息后,开始记录实际监控时长,并在实际监控时长达到预设监控时长后,向第二系统发送删除监控请求,以使第二系统删除对当前变更对象的监控。
82.s2063,第二系统基于删除监控请求,删除对当前变更对象的监控。
83.通过在变更对象的预设监控时长达到后及时删除对变更对象的监控,可以避免第二系统长期对变更对象的监控所造成的资源占有问题,因为在预设监控时长后,变更对象各种监控指标趋于正常,且种资源占有在很大程度上是存在资源浪费的现象。
84.第二系统在对每个变更对象的监控过程中,可能产生多条告警信息,在每次产生告警后,均通过告警中间件接收并处理,为了使用户第一时间掌握变更情况,可以由告警中间件对告警信息进行处理后通知给用户。
85.在一个可能的实施方式中,如图5所示,步骤s207在具体实施之后,该方法还可以包括:
86.s208,告警中间件在确定告警信息满足预设收敛条件后,对告警信息进行处理,并将处理后的告警信息发送至用户。
87.对告警信息处理可以是确定该告警信息是否已被通报过、是否已有相似的告警信息存在、或者是否与其他告警信息属于同一类型等等。通过对来自相同变更对象的不同告警信息,或者来自不同变更对象的相同或相似告警信息,进行处理后再通知给用户,能够降低告警误报的概率,以及便于用户对产生告警信息的问题进行定位。
88.在实际应用中,用户通常会间隔一段时间才会通过第一系统进行变更操作,例如版本升级通常是一个月或者几个月,扩容操作甚至可能几年,因而第一系统与告警中间件之间不需要建立长连接,而是在需要进行变更时,才建立连接,然后再完成对监控任务流各个变更对象的监控后,删除此连接,从而可以保障资源的有效利用。
89.因而在一个可能的实施方式中,在步骤s201具体实施之前,该方法还可以包括:告警中间件在接收到开启通信建立请求后,建立与第一系统之间的通信连接;相应的,在步骤s2062实施之后,该方法还可以包括:告警中间件检测变更任务流中是否还有未删除监控,若否,则注销与所述第一系统之间的通信连接。其中,开启通信建立请求携带有变更任务流标识以及该变更任务流标识中各个变更对象的变更对象标识,变更任务流标识指示属于哪一次变更流水线,告警中间件在对变更对象进行状态管理等操作时,可以根据变更任务流标识确定变更对象属于哪个监控组。
90.如图6所示,其为变更计划配置的界面示意图,该界面可运行于第二系统中的客户端中。用户可以选择变更类型和是否开启质量红线业务,若开启质量红线业务,则向告警中间件发送开启通信建立请求。可以理解的,如果用户在进行变更操作前并没有开启告警中间件,在每个变更对象的变更操作执行成功后,告警中间件将接收不到或者将不对变更成功消息进行处理。
91.通过在进行变更操作时在建立告警中间件与第一系统之间的通信连接,可以降低长连接所引起的不必要资源消耗。
92.本技术实施例还提供了一种变更监控方法,该方法可应用于上述系统和方法实施例所述的告警中间件。如图7所示,该方法可以包括:
93.s701,接收来自第一系统的变更成功消息,变更成功消息指示第一系统对变更任务流中的当前变更对象的变更操作执行成功,变更成功消息携带当前变更对象的变更对象标识。
94.变更对象标识用于对变更对象进行唯一性识别,例如在变更对象是模块时,变更对象标识可以是模块名称;在变更对象标识是设备时,变更对象标识可以是设备ip。
95.s703,将携带有变更对象标识的添加监控请求发送至第二系统,以使第二系统添加对当前变更对象的监控。
96.告警中间件负责对所有向第二系统发送的请求以及所有来自第二系统的响应信息进行处理,然后将处理结果通知给第一系统或用户。为了更便于对请求和响应信息进行处理,在一个可能的实施方式,如图8所示,步骤s703在具体实施之前,该方法还可以包括:
97.s702,根据变更对象标识,建立针对当前变更对象的处理任务。
98.相应的,步骤s703可以包括:
99.s7031,基于当前变更对象的处理任务,将携带有变更对象标识的添加监控请求发送至第二系统,以使第二系统添加对当前变更对象的监控。
100.具体的,如图9所示,步骤s702可以包括:
101.s7021,根据变更对象标识,获取与当前变更对象关联的监控组,得到目标监控组。
102.告警中间件在步骤s7021之前可以先根据变更对象之间的关联性对变更对象进行分组,将具有关联性的多个变更对象划分为同一个监控组。通过监控组的划分,可以为属于同一个监控组的各个变更对象的告警信息进行统一分析处理。在实际应用中,可以基于业务信息判断变更对象之间是否具有关联性,例如设备1和设备2都是属于同一个局域网,那么可以认为设备1和设备2之间具有关联性;又比如,模块1和模块2都属于同一个业务逻辑,则可以认为模块1和模块2之间具有关联性。可以理解的,对于关联性的确定还可以有其他实施方式,本技术对此不做具体限定。
103.s7023,若目标监控组不存在,则创建新监控组,将新监控组确定为目标监控组。
104.在创建新监控组时,告警中间件可以先根据变更对象标识获取监控处理器(hunter),然后创建监控组(watchdog),并建立监控组与监控处理器之间的长连接。其中,监控处理器用于对事件(event)进行处理,例如告警信息,一个监控处理器可以与多个监控处理器保持长连接,通常与一个监控处理器建立长连接的监控处理器的个数可以根据具体业务场景进行设置,在此不做具体限定。
105.s7025,在目标监控组中创建针对当前变更对象的第一处理任务,以通过第一处理
任务对所述当前变更对象进行状态管理。
106.每个监控组中可以包括多个第一处理任务(contex),第一处理任务与变更对象一一对应,也即第一处理任务对应一个监控。状态管理是指管理监控运行过程中的状态,例如刷新监控时长、删除监控等等。如图10所示,其为监控组划分的一个示例图。在图10中,watchdog可以管辖一组context,绑定一个hunter,属于同一个watchdog的各个context均将事件通过相同通道chan发送至hunter进行处理,一个变更也即一个变更任务流可以看成是一个监控处理组(huntergroup)。在目标监控组中创建第一处理任务也即在wachdog中创建一个与当前变更对象对应的context。
107.通过监控组的划分,告警中间件可以很快速的实现多业务或多系统的接入,从而使告警中间件具有更强的可扩展性。
108.为了对使得告警中间件的访问和回调更高效,在一个可能的实施方式中,步骤s702在具体实施时还可以包括:根据变更对象标识,在请求中心注册针对当前变更对象的第二处理任务,以及在回调中心注册针对当前变更对象的第三处理任务,第二处理任务用于对向第二系统发送的预设请求进行管理,第三处理任务用于对来自第二系统的预设消息进行管理。
109.预设请求至少可以包括添加监控请求、删除监控请求以及查询请求等等,请求中心是告警中间件向第二系统发送请求的处理中心,请求中心将对按照各个请求的请求类型进行管理,请求类型包括添加、删除、查询等等。请求中心将每种请求类型建立请求缓存,请求缓存与请求类型相对应,可以包括添加缓存、删除缓存以及查询缓存等等。在请求中心注册第二处理任务后,可以通过第二处理任务将当前变更对象的请求添加至请求中心内相应的请求缓存中。
110.预设消息至少可以包括添加成功消息、添加失败消息以及告警信息,回调中心是所有从第二系统接收来的消息的处理中心,回调中心按照消息类型进行回调管理建立回调接口,回调接口与请求缓存相对应,可以包括添加成功接口、添加失败接口以及告警接口。在回调中心注册第三处理任务后,可以通过第三处理任务将当前变更对象的消息类型,添加至回调中心内相应的回调接口。
111.在注册完成后,请求中心中将记录当前变更对象的所有操作,对于一个变更任务流,在现网中可能涉及成千上万的变更对象(比如设备升级),若每个变更对象在变更成功后均要向第二系统发送添加监控请求,在短时间内可能存在频繁请求的问题,为防止第二系统出现请求崩溃等异常现象,告警中间件通过请求中心完成请求批量收敛处理,实现请求合并的功能。
112.相应的,在一个可能的实施方式中,步骤s7031在具体实施时可以包括:
113.(1)根据当前变更对象的第二处理任务向请求中心的添加缓存中添加当前变更对象的待添加监控请求;
114.(2)对请求中心的添加缓存中的所有待添加监控请求进行收敛处理,得到目标添加监控请求;其中,目标添加监控请求携带一个或多个变更对象标识以及回调中心的回调接口;
115.(3)将目标添加监控请求发送至第二系统,以使第二系统添加对目标添加监控请求中每个变更对象标识对应变更对象的监控,以及使第二系统在监测到与各个变更对象标
识有关的告警信息时,向该回调接口发送所述告警信息。
116.每个请求缓存定义各自的请求和回调接口,属于同一个请求缓存中的请求将使用相同的回调接口进行告警信息的接收。第二系统在监测到变更对象的告警信息时,可以向变更对象标识对应的回调接口发送该告警信息。告警中间件可以采用轮询的方式对添加缓存中所有待添加监控请求进行收敛处理,然后将处理后的目标添加监控请求发送至第二系统。
117.收敛处理可以是将添加缓存中的所有待添加监控请求进行合并,得到目标添加监控请求,第二系统在接收到目标添加监控请求后,可以根据该目标添加监控请求中每个变更对象对应的变更对象标识,为每个变更对象添加监控。
118.如图11所示,其为告警中间件的架构示意图。在图11中,请求中心中包括各个请求类型对应的请求缓存,例如添加(add)类型的请求,会缓存在添加缓存(addcache)中,删除(delete)类型的请求,会缓存在删除缓存(deletecache)中。每个缓存在回调中心中有各自的回调接口,每个监控对象在回调中心注册第三处理任务是,会相应在回调中心中绑定自己的回调接口。
119.通常变更对象数量是非常巨大的,通过请求缓存机制,可以对第二系统添加监控做相应的收敛工作,既可以适配保证第二系统和第一系统的步调一致,也可以节省访问接入的资源;而且通过接口抽象,保证了告警中间件对第一系统和第二系统的弱相关,更便于扩展。另一方面,通过与第二系统之间的使用回调接口交互告警信息,对第二系统而言,告警中间件就是告警信息的接收人,而不是直接将告警信息发送给用户。
120.s705,接收来自第二系统针对当前变更对象的告警信息,确定告警信息是否满足预设收敛条件。
121.确定告警信息是否满足预设收敛条件的具体实施方式可参见上述步骤s209,在此不再重复赘述。
122.s707,在告警消息满足预设收敛条件时,获取告警信息对应的告警方式。
123.参见步骤s709所述,告警中间件所提供的告警方式可以包括停止变更以及通知用户,停止变更和通知用户可以同时存在,也即可以在停止变更的同时通知用户。其中,通知用户的方式可以是电话、微信、短信以及邮件等等,本技术对此不做具体限定。
124.s709,若告警方式指示停止变更,则向第一系统发送停止变更指令,以使第一系统停止执行所述变更任务流中未变更对象的变更操作。
125.对变更对象的变更质量的监控,在观察期之后变更质量趋于稳定,为了节省系统资源,在观察期后第二系统可以不需要再继续对变更对象进行监控。
126.鉴于此,在一个可能的实施方式中,如图12所示,在步骤s703实施之后,该方法还可以包括:
127.s7041,接收来自第二系统的添加成功消息,获取添加成功消息中的变更对象标识,添加成功消息用于指示第二系统成功添加对当前变更对象的监控。
128.s7043,根据变更对象标识,记录当前变更对象的实际监控时长。
129.s7045,在实际监控时长达到当前变更对象的预设监控时长后,向第二系统发送删除监控请求,以使第二系统删除对当前变更对象的监控。
130.如果第二系统中已删除了对当前变更对象的监控,而告警中间件中还保存有针对
当前变更对象的处理任务,那么这些处理任务也将失去存在的意义。因而,步骤s7045中的在实际监控时长达到预设监控时长后,还可以根据变更对象标识,删除针对当前变更对象的处理任务,以及删除当前变更对象的监控组,也即将与当前变更对象对应的context从watchdog中删除。
131.而如果第二系统未能成功添加针对当前变更对象的监控,告警中间件可以进行多次尝试发送添加监控请求,在尝试次数达到预设值时,也需要将这些处理任务进行删除。因而,在一个可能的实施方式中,如图13所示,在步骤s703实施之后,该方法还可以包括:
132.s7047,接收来自第二系统的添加失败消息,获取添加失败消息中的变更对象标识,添加失败消息用于指示第二系统对当前变更对象的监控添加失败;
133.s7049,获取变更对象标识对应的失败添加次数;
134.s70411,若失败添加次数未达到添加次数阈值,则重新向第二系统发送添加监控请求;
135.s70413,若失败添加次数达到添加次数阈值,则删除针对当前变更对象的处理任务。
136.本技术实施例中,告警中间件启动重试机制对添加监控失败的变更对象,再次发送添加监控请求,添加次数阈值可以根据实际需要进行设定。例如可以将添加次数阈值设置为5,在5次尝试仍然添加失败,则将当前变更对象的处理任务删除,视为监控失败。
137.在实际应用中,一般用户会间隔一段时间才会通过第一系统进行变更操作,例如版本升级通常是一个月或者几个月,扩容操作甚至可能几年,因而第一系统与告警中间件之间不需要建立长连接,在需要进行变更时,才建立连接,然后再完成对监控任务流各个变更对象的监控后,注销此连接。
138.因而在一个可能的实施方式中,在步骤s701具体实施之前,该方法还可以包括:接收开启通信建立请求,建立与第一系统之间的通信连接。
139.其中,开启通信建立请求携带变更任务流标识以及该变更任务流标识中各个变更对象的变更对象标识,变更任务流标识用于对变更任务流进行标识。告警中间件可以将一个变更任务流作为一个监控处理组(huntergroup),一个huntergroup可以用变更任务流标识进行唯一性识别。
140.相应的,在实际监控时长达到当前变更对象的预设监控时长后,该方法还可以包括:检测变更任务流中是否还有未删除监控,若否,则注销与所述第一系统之间的通信连接。
141.具体的,可以获取与变更任务流标识对应的监控处理组,然后判断该监控处理组下是否存在监控组,若不存在,则可判定变更任务流中没有未删除监控。
142.由上述实施例提供的技术方案可见,本技术实施例通过第二系统对变更对象进行变更操作后,由告警中间件自动向第一系统添加针对变更对象的监控请求,而不需要用户手动添加监控指标,减少用户的工作量的同时,可以避免由于额外添加监控指标所导致的覆盖场景不全的问题;而且将系统级监控粒度细化到对象级监控粒度,可以更精细化的对变更后的质量进行监控;在出现告警时,可以通过告警中间件做智能分析,在出现需要停止变更的告警信息时,可以通知第一系统立即停止变更任务流中未变更对象的变更操作,从而使告警问题定位更加收敛,减少异常定位所花费的时间,提升问题定位效率和运营效率。
143.基于与上述执行主体为告警中间件的方法实施例相同地发明构思,本发明实施例还提供了一种变更监控装置,参照图14中所示,该装置1400可以包括:
144.第一消息接收模块1410,用于接收来自第一系统的变更成功消息,变更成功消息指示第一系统对变更任务流中的当前变更对象的变更操作执行成功,变更成功消息携带当前变更对象的变更对象标识;
145.添加监控请求模块1420,用于将携带有变更对象标识的添加监控请求发送至第二系统,以使第二系统添加对当前变更对象的监控;
146.告警消息接收模块1430,用于接收来自第二系统针对当前变更对象的告警信息,确定告警信息是否满足预设收敛条件;
147.告警消息处理模块1440,用于在告警消息满足预设收敛条件时,获取告警信息对应的告警方式;
148.第一消息发送模块1450,用于在告警方式指示停止变更的情况下,向第一系统发送停止变更指令,以使第一系统停止执行变更任务流中未变更对象的变更操作。
149.在一个可能的实施方式中,该装置1400还可以包括:
150.对象创建模块,用于根据变更对象标识,建立针对当前变更对象的处理任务。
151.相应的,添加监控请求模块1420可以包括:
152.请求处理单元,用于基于当前变更对象的处理任务,将携带有变更对象标识的添加监控请求发送至第二系统,以使第二系统添加对当前变更对象的监控。
153.在一个可能的实施方式中,对象创建模块可以包括:
154.监控组获取单元,用于根据变更对象标识,获取与当前变更对象关联的监控组,得到目标监控组;
155.监控组创建单元,用于在目标监控组不存在的情况下创建新监控组,将新监控组确定为目标监控组;
156.第一对象创建单元,用于在目标监控组中创建针对当前变更对象的第一处理任务,以通过第一处理任务对当前变更对象进行状态管理。
157.在一个可能的实施方式中,对象创建模块还可以包括:
158.第二对象创建单元,用于根据变更对象标识,在请求中心注册针对当前变更对象的第二处理任务,以及在回调中心注册针对当前变更对象的第三处理任务,第二处理任务用于对向第二系统发送的预设请求进行管理,所述第三处理任务用于对来自第二系统的预设消息进行管理。
159.相应的,请求处理单元可以包括:
160.请求添加单元,用于根据当前变更对象的第二处理任务向请求中心的添加缓存中添加当前变更对象的待添加监控请求;
161.收敛处理单元,用于对请求中心的添加缓存中的所有待添加监控请求进行收敛处理,得到目标添加监控请求,目标添加监控请求携带一个或多个变更对象标识以及回调中心的回调接口;
162.请求发送单元,用于将目标添加监控请求发送至第二系统,以使第二系统添加对目标添加监控请求中每个变更对象标识对应变更对象的监控,以及使第二系统在监测到与各个变更对象标识有关的告警信息时,向回调接口发送告警信息。
163.在一个可能的实施方式中,该装置1400还可以包括:
164.第二消息接收模块,用于接收来自第二系统的添加成功消息,获取添加成功消息中的变更对象标识,添加成功消息用于指示第二系统成功添加对当前变更对象的监控;
165.监控时长获取模块,用于根据变更对象标识,记录当前变更对象的实际监控时长;
166.第二消息发送模块,用于在实际监控时长达到当前变更对象的预设监控时长后,向第二系统发送删除监控请求,以使第二系统删除对当前变更对象的监控。
167.在一个可能的实施方式中,该装置1400还可以包括:
168.通信建立模块,用于接收开启通信建立请求,建立与第一系统之间的通信连接。
169.通信注销模块,用于检测变更任务流中是否还有未删除监控,若否,则注销与第一系统之间的通信连接。
170.在一个可能的实施方式中,该装置1400还可以包括:
171.第三消息接收模块,用于接收来自第二系统的添加失败消息,获取添加失败消息中的变更对象标识,添加失败消息用于指示第二系统对当前变更对象的监控添加失败;
172.失败次数获取模块,用于获取变更对象标识对应的失败添加次数;
173.重试模块,用于在失败添加次数未达到添加次数阈值的情况下,则重新向第二系统发送添加监控请求;
174.删除任务模块,用于在失败添加次数达到添加次数阈值的情况下,删除针对当前变更对象的处理任务。
175.需要说明的是,上述实施例提供的装置,在实现其功能时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的装置与方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
176.本技术实施例还提供了一种电子设备,所述设备包括处理器和存储器,所述存储器中存储有至少一条指令或至少一段程序,所述至少一条指令或至少一段程序由所述处理器加载并执行上述方法实施例提供的变更监控方法。
177.进一步地,图15示出了一种用于实现本技术实施例所提供的方法的设备的硬件结构示意图,所述设备可以参与构成或包含本技术实施例所提供的装置或系统。如图15所示,设备15可以包括一个或多个(图中采用1502a、1502b,
……
,1502n来示出)处理器1502(处理器1502可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器1504、以及用于通信功能的传输装置1506。除此以外,还可以包括:显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解,图15所示的结构仅为示意,其并不对上述电子装置的结构造成限定。例如,设备15还可包括比图15中所示更多或者更少的组件,或者具有与图15所示不同的配置。
178.应当注意到的是上述一个或多个处理器1502和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外,数据处理电路可为单个独立的处理模块,或全部或部分的结合到设备15(或移动设备)中的其他元件中的任意一个内。如本技术实施例中所涉及到的,该数据
处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
179.存储器1504可用于存储应用软件的软件程序以及模块,如本技术实施例中所述的方法对应的程序指令/数据存储装置,处理器1502通过运行存储在存储器1504内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的一种变更监控方法。存储器1504可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器1504可进一步包括相对于处理器1502远程设置的存储器,这些远程存储器可以通过网络连接至设备15。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
180.传输装置1506用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备15的通信供应商提供的无线网络。在一个实例中,传输装置1506包括一个网络适配器(networkinterfacecontroller,nic),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输装置1506可以为射频(radiofrequency,rf)模块,其用于通过无线方式与互联网进行通讯。
181.显示器可以例如触摸屏式的液晶显示器(lcd),该液晶显示器可使得用户能够与设备15(或移动设备)的用户界面进行交互。
182.本技术实施例还提供了一种计算机存储介质,该计算机存储介质中存储有至少一条指令或至少一段程序,该至少一条指令或至少一段程序由处理器加载并执行以实现上述方法实施例提供的变更监控方法。
183.可选地,在本实施例中,上述计算机存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地,在本实施例中,上述存储介质可以包括但不限于:u盘、只读存储器(rom,read-only memory)、随机存取存储器(ram,random access memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
184.本技术实施例还提供了一种计算机程序产品或计算机程序,该计算机程序产品或计算机程序包括计算机指令,该计算机指令存储在计算机存储介质中。电子设备的处理器从计算机存储介质读取该计算机指令,处理器执行该计算机指令,使得该电子设备执行上述的方法实施例提供的变更监控方法。
185.需要说明的是:上述本技术实施例先后顺序仅仅为了描述,不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
186.本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置和电子设备实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
187.上述说明已经充分揭露了本技术的具体实施方式。需要指出的是,熟悉该领域的技术人员对本技术的具体实施方式所做的任何改动均不脱离本技术的权利要求书的范围。相应地,本技术的权利要求的范围也并不仅仅局限于前述具体实施方式。
再多了解一些

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

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

相关文献