一种基于云AC的关键业务模块监听方法及系统与流程

文档序号:12809241阅读:154来源:国知局
一种基于云AC的关键业务模块监听方法及系统与流程
本发明涉及通信
技术领域
,尤其涉及一种基于云ac的关键业务模块监听方法及系统。
背景技术
:现在,随着通信技术的发展,在云端部署ac(accesscontroller,接入控制器),简称云ac,是一种越来越普遍的通信方式,ap设备(accesspointer,接入节点)跨越internet与云ac相连,从而实现云ac对各ap设备的管理和控制。云ac在运行时,一些关键业务模块需要与多个外围接口进行信息交互,保证各ap设备的正常运行,因此,这些关键业务模块的执行结果又跟用户的使用体验直接相关,对这些关键业务模块的运行状态进行监控就显得非常的必要。在现有技术中,大量ap设备连接云ac的情况下,如果云ac对关键业务模块的所有具体执行细节进行细粒度日志监听,由于这些细粒度日志信息非常巨大且需要写到存储设备上,会对云ac的性能造成很大的压力,降低云ac的处理能力,在生产环境下无法对所有的关键业务模块进行细粒度日志监听,导致云ac的处理能力无法满足实际需求时,运营维护人员无法及时得到通知,不利于运营维护人员及时采取相应的措施排除问题。技术实现要素:本发明的目的是提供一种基于云ac的关键业务模块监听方法及系统,在不对云ac的性能造成很大压力的情况下,当云ac的处理能力出现问题时,可以及时通知运营维护人员采取相应的措施排除问题。本发明提供的技术方案如下:一种基于云ac的关键业务模块监听方法,包括:步骤s100实时监听并统计云ac中关键业务模块的业务执行时间;步骤s200根据统计的所述业务执行时间,判断所述关键业务模块是否发生异常;步骤s300当所述关键业务模块发生异常时,发送异常提示信息。在上述技术方案中,根据关键业务模块的业务执行时间,来判断关键业务模块是否发生异常,若发生异常,就立即发送异常提示信息给运营维护人员,以便他们及时采取相应的措施来排除问题,使云ac恢复正常的工作性能。这种监听方式并不会对云ac的性能造成很大的影响,提高了用户的使用体验。进一步,所述步骤s200包括:步骤s210判断所述业务执行时间是否出现异常;步骤s220当所述业务执行时间出现异常时,获取所述业务执行时间对应的所述关键业务模块的出错次数;步骤s230根据预设规则,将获取的出现异常的所述业务执行时间对应的所述关键业务模块的出错次数更新;步骤s240根据所述关键业务模块的所述出错次数,判断所述关键业务模块是否发生异常。在上述技术方案中,通过业务执行时间来更新出错次数,再根据出错次数来判断关键业务模块是否出现异常,判断的过程更直观、简便。进一步,所述步骤210具体包括:步骤211判断所述业务执行时间是否超过所述业务执行时间对应的关键业务模块的预设执行时间;所述步骤s220具体包括:步骤s221当所述业务执行时间超过所述业务执行时间对应的关键业务模块的预设执行时间时,判断所述关键业务模块是否在异常数据库中;步骤s222当所述关键业务模块在所述异常数据库时,获取所述业务执行时间对应的所述关键业务模块的出错次数;步骤s223当所述关键业务模块未在所述异常数据库时,将所述关键业务模块添加入所述异常数据库,将所述关键业务模块的出错次数设置为初始值,并获取所述出错次数。在上述技术方案中,专门开辟一个异常数据库,用来存储关键业务模块的出错次数,使监听的过程不会影响到云ac的正常运行,既保证了云ac的正常工作,又能对云ac的关键业务模块进行监听。进一步,所述步骤s240包括:步骤s241当所述出错次数不为初始值的持续时间达到预设时间时,判断在所述异常数据库中的所述关键业务模块的所述出错次数在所述预设时间内是否大于预设警戒值;步骤s242当所述出错次数在所述预设时间内大于所述预设警戒值时,则认为所述出错次数对应的所述关键业务模块发生异常,执行步骤s300。在上述技术方案中,当关键业务模块的业务执行时间出现少量次数的异常时,这种情况是可以忽略的,只有在预设时间内出错次数大于预设警戒值时,才认为其发生异常,需要发送异常提示信息,多种情况的考虑优化了云ac的监听过程,提高了其工作效率。进一步,所述步骤s240还包括:步骤s243当所述出错次数在所述预设时间内不大于所述预设警戒值时,则将所述出错次数更新为初始值;或,步骤s244当所述出错次数在所述预设时间内不大于所述预设警戒值时,则将所述出错次数和/或所述出错次数对应的关键业务模块从所述异常数据库中删除。在上述技术方案中,在预设时间内若出错次数没有达到预设警戒值,则会自动将其更新为初始值,为下次出现异常作准备。也可以将出错次数和/或关键业务模块删除,一来为异常数据库释放存储空间,二来也为下次出现异常作准备。进一步,所述步骤s200之后还包括:步骤s400当所述关键业务模块发生异常时,打开发生异常的所述关键业务模块的细粒度日志。在上述技术方案中,当关键业务模块发生异常时,可以将此发生异常的关键业务模块的细粒度日志打开,方便后续运营维护人员查看,及时了解采取哪种措施排除问题。本发明还提供一种基于云ac的关键业务模块监听系统,包括:关键业务模块;监听统计模块,与所述关键业务模块电连接,用于实时监听并统计云ac中所述关键业务模块的业务执行时间;异常判断模块,与所述监听统计模块电连接,所述异常判断模块根据所述监听统计模块统计的所述业务执行时间,判断所述关键业务模块是否发生异常;异常提示模块,与所述异常判断模块电连接,当所述异常判断模块判断所述关键业务模块发生异常时,所述异常提示模块发送异常提示信息。在上述技术方案中,本发明在不影响云ac整体性能的情况下,可以对云ac的关键业务模块进行监听,当出现异常时,及时通知运营维护人员,大大提高了用户的使用体验。进一步,所述异常判断模块包括:时间判断子模块,用于判断所述业务执行时间是否出现异常;次数判断子模块,当异常数据库将所述出错次数更新后,所述次数判断子模块根据所述关键业务模块的所述出错次数,判断所述关键业务模块是否发生异常;所述基于云ac的关键业务模块监听系统还包括:次数获取模块,与所述异常判断模块电连接,当所述异常判断模块判断所述业务执行时间出现异常时,所述次数获取模块获取所述业务执行时间对应的所述关键业务模块的出错次数;所述异常数据库,与所述次数获取模块、所述异常判断模块电连接,当所述次数获取模块获取了所述出错次数时,所述异常数据库根据预设规则,将获取的出现异常的所述业务执行时间对应的所述关键业务模块的出错次数更新。进一步,所述时间判断子模块,进一步用于判断所述业务执行时间是否超过所述业务执行时间对应的关键业务模块的预设执行时间;所述异常判断模块还包括:模块判断子模块,当所述时间判断子模块判断所述业务执行时间出现异常时,所述模块判断子模块判断所述关键业务模块是否在所述异常数据库中;所述异常数据库,当所述异常判断模块判断所述关键业务模块未在所述异常数据库时,所述异常数据库进一步用于将所述关键业务模块添加入所述异常数据库,将所述关键业务模块的出错次数设置为初始值;所述次数获取模块,进一步用于获取所述业务执行时间对应的所述关键业务模块的出错次数。进一步,还包括:日志管理模块,与所述异常判断模块电连接,当所述异常判断模块判断所述关键业务模块发生异常时,所述日志管理模块打开发生异常的所述关键业务模块的细粒度日志。与现有技术相比,本发明的基于云ac的关键业务模块监听方法及系统有益效果在于:本发明只需要通过监听其业务执行时间以及相应的出错次数,就可以达到监听关键业务模块是否出现异常的目的,不需要一直监听各关键业务模块的细粒度日志,大大降低了云ac的性能占用率,在保证云ac得到监听的情况下,大大改善了用户的使用体验。附图说明下面将以明确易懂的方式,结合附图说明优选实施方式,对一种基于云ac的关键业务模块监听方法及系统的上述特性、技术特征、优点及其实现方式予以进一步说明。图1是本发明基于云ac的关键业务模块监听方法一个实施例的流程图;图2是本发明基于云ac的关键业务模块监听方法另一个实施例的流程图;图3是本发明基于云ac的关键业务模块监听系统一个实施例的结构示意图;图4是本发明基于云ac的关键业务模块监听系统另一个实施例的结构示意图。附图标号说明:10.关键业务模块,20.监听统计模块,30.异常判断模块,31.时间判断子模块,32.次数判断子模块,33.模块判断子模块,40.异常提示模块,50.次数获取模块,60.异常数据库,70.日志管理模块。具体实施方式为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对照附图说明本发明的具体实施方式。显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图,并获得其他的实施方式。为使图面简洁,各图中只示意性地表示出了与本发明相关的部分,它们并不代表其作为产品的实际结构。另外,以使图面简洁便于理解,在有些图中具有相同结构或功能的部件,仅示意性地绘示了其中的一个,或仅标出了其中的一个。在本文中,“一个”不仅表示“仅此一个”,也可以表示“多于一个”的情形。在本发明的一个实施例中,如图1所示,一种基于云ac的关键业务模块监听方法,包括:步骤s100实时监听并统计云ac中关键业务模块的业务执行时间;步骤s200根据统计的所述业务执行时间,判断所述关键业务模块是否发生异常;步骤s300当所述关键业务模块发生异常时,发送异常提示信息。具体的,关键业务模块在云ac中起着极为重要的作用,是考量云ac的业务性能能不能满足使用性能指标的关键因素。关键业务模块主要有:认证模块,此模块需要与ap设备、第三方认证、云ac数据库进行数据交换与处理;报文处理模块,接收并处理云ac和ap设备之间交互的报文等;报警信息处理模块,用于处理各接口的报警信息;外部接口模块,用于让云ac和ap设备之间实现通讯等其它关键业务模块。通过监听并统计某些/个关键业务模块吞吐量(或报文处理等)的业务执行时间,来确认关键业务模块是否出现异常。报文处理模块对上报的报文进行处理后,把跟用户认证相关的报文信息发到认证模块,认证模块收到消息后开始处理用户认证。例如:假设关键业务模块为云ac数据库,使用云ac数据库认证,最消耗时间的功能是在云ac数据库中根据用户名和密码查找用户信息并进行判断,在正常情况下,在云ac数据库中查询一条用户记录并返回结果的时间不超过100ms(可以设置此100ms为云ac数据库的预设执行时间),如果实际的业务执行时间超过100ms,就可以认为云ac数据库处理性能有问题,需要进行处理。如果使用第三方认证,例如:微信认证,假设关键业务模块为微信接口模块,最消耗时间的功能是等候微信的认证返回信息,可以指定时间为50ms(即预设执行时间),如果超过这个时间微信接口没有返回结果,可以认为与微信的接口不稳定,即微信接口模块出现异常,需要进行处理(例如:发出异常提示信息等)。关键业务模块可以由运营维护人员自己进行设置,在云ac中通过aop(aspectorientedprogramming,面向切面编程)编程方式,记录(这些)关键业务功能的执行时间。aop可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术,它将日志记录,性能统计,安全控制,事务处理,异常处理等代码从业务逻辑代码中划分出来,通过对这些行为的分离,改变这些行为的时候不影响业务逻辑的代码。使用aop方式对关键业务模块进行性能的监听,与关键业务模块的实际处理代码相互隔离,不会影响云ac本身的正常运行。根据关键业务模块的业务执行时间,来判断关键业务模块是否发生异常,若发生异常,就立即发送异常提示信息给运营维护人员,以便他们及时采取相应的措施来排除问题,使云ac恢复正常的工作性能。云ac可以通过邮件通道将异常信息发送给运营维护人员,也可以以报警声音作为异常提示信息发出。在本发明的另一个实施例中,除与上述相同的之外,监听并统计云ac的关键业务模块的数量可以为多个,即监听并统计多个关键业务模块各自的业务执行时间,分别对各关键业务模块的业务执行时间进行判断,当有某一个或一些关键业务模块发生异常时,就发送异常提示信息。优选地,在发送异常提示信息时,把发生异常的关键业务模块的名称一起发送,便于让运营维护人员了解具体哪个或哪些关键业务模块出问题。在本发明的另一个实施例中,除与上述相同的之外,所述步骤s200包括:步骤s210判断所述业务执行时间是否出现异常;步骤s220当所述业务执行时间出现异常时,获取所述业务执行时间对应的所述关键业务模块的出错次数;步骤s230根据预设规则,将获取的出现异常的所述业务执行时间对应的所述关键业务模块的出错次数更新;步骤s240根据所述关键业务模块的所述出错次数,判断所述关键业务模块是否发生异常。具体的,判断统计的关键业务模块的业务执行时间是否出现异常具体包括:判断统计的业务执行时间是否在预设执行时间范围内,如果在的话,就说明业务执行时间未出现异常;如果不在的话,就说明业务执行时间出现异常。当然,判断业务执行时间出现异常的方式也可以为其他方式,并不局限于上述那一种。运营维护人员会根据大数据得出每个关键业务模块的标准执行时间,作为预设执行时间,将实时统计的当前业务执行时间和预设执行时间进行比较,若当前的业务执行时间超过了对应关键业务模块的预设执行时间,则需要获取并更新此关键业务模块的出错次数,以便后续记录下,为判断关键业务模块是否出现异常作为判断依据。需要注意的是,当关键业务模块的数量为多个时,每个关键业务模块的预设执行时间是不同的,因此,需要将每个关键业务模块当前的业务执行时间与其对应的预设执行时间进行判断,这样才能确认是否需要更新各关键业务模块的出错次数。之所以每个关键业务模块的预设执行时间不同,是因为,每个关键业务模块其处理的业务不同。因此,每个关键业务模块的业务执行时间都有各自的判断标准,例如:如表一,若统计得到报文处理模块的业务执行时间为0.9秒/条,将其与报文处理模块的预设执行时间1秒/条进行比较,认为报文处理模块没有出现异常,不需要更新它的出错次数;若统计得到报警信息处理模块的业务执行时间为11毫秒/条,将其与报警信息处理模块的预设执行时间10毫秒/条进行比较,认为报警信息处理模块出现异常,需要获取并更新报警信息处理模块的出错次数。表一关键业务模块预设执行时间业务执行时间报文处理模块1秒/条(报文)0.9秒/条报警信息处理模块10毫秒/条(报警信息)11毫秒/条当业务执行时间出现异常时,可以从数据库中获取出现异常的业务执行时间对应的关键业务模块的出错次数,从而按照预设规则进行更新。对出错次数进行更新的预设规则可以由运营维护人员根据实际情况进行设定,例如:每出一次错,就加一,初始值为零;或者,以二十六个字母为顺序进行更新,初始值为a,第一次出错,出错次数变为b,第二次出错,由b变为c;初始值为20,每出一次错,就减一,直到减到零,则认为关键业务模块发生异常。优选地,所述步骤210具体包括:步骤211判断所述业务执行时间是否超过所述业务执行时间对应的关键业务模块的预设执行时间;所述步骤s220具体包括:步骤s221当所述业务执行时间超过所述业务执行时间对应的关键业务模块的预设执行时间时,判断所述关键业务模块是否在异常数据库中;步骤s222当所述关键业务模块在所述异常数据库时,获取所述业务执行时间对应的所述关键业务模块的出错次数;步骤s223当所述关键业务模块未在所述异常数据库时,将所述关键业务模块添加入所述异常数据库,将所述关键业务模块的出错次数设置为初始值,并获取所述出错次数。具体的,专门开辟一个异常数据库,用来存储关键业务模块的出错次数,当出现异常的业务执行时间对应的关键业务模块已经在异常数据库时,直接获取所述关键业务模块当前的出错次数(这里可以理解为:这个关键业务模块已经出错过了,因此被添加进了异常数据库中;也可以理解为,在这个异常数据库中为每个关键业务模块开辟了空间存储其出错次数);当关键业务模块不在异常数据库时,将关键业务模块添加进异常数据库,并设置其出错次数为初始值,之后再以此初始值为基础进行更新。例如:当发现报文处理模块的业务执行时间出现异常时,先判断报文处理模块是否在异常数据库中,1)若有的话,则直接获取它的出错次数(假设为3);2)若没有的话,将报文处理模块添加进异常数据库,并设置其出错次数为初始值(例如:0)。然后根据预设规则,以获取的出错次数为基础,进行更新,假设预设规则为每次出错加一,对1)的出错次数更新为3+1=4,对2)的出错次数更新为0+1=1。可以通过redisincr命令来将业务执行时间出现异常的关键业务模块加入到redis(若此关键业务模块没有被加入到redis中的话,redis相当于异常数据库)中,并把关键业务模块的相应键(即,出错次数)值加一。redis是一个开源(bsd许可)、内存存储的数据结构服务器,redis是一个速度非常快的非关系数据库,它支持字符串、哈希表、列表、集合、有序集合,位图,hyperloglogs等数据类型,内置复制、lua脚本、lru收回、事务以及不同级别磁盘持久化功能。优选地,所述步骤s240包括:步骤s241当所述出错次数不为初始值的持续时间达到预设时间时,判断在所述异常数据库中的所述关键业务模块的所述出错次数在预设时间内是否大于预设警戒值;步骤s242当所述出错次数在所述预设时间内大于所述预设警戒值时,则认为所述出错次数对应的所述关键业务模块发生异常,执行步骤s300。步骤s241进一步包括:当所述出错次数不为初始值的持续时间未达到预设时间时,跳转至步骤s100。具体的,一般情况下,考虑到云ac性能或者外部接口的连接变化,一段时间内少量的性能下降情况(即,业务执行时间出现少量的异常情况)可以忽略不计,没有必要一出现问题就通知运营维护人员。如果云ac发生异常情况,比如数据库读写变慢,外部接口通讯时间变长,那么在这个时间段内,大部分的关键业务模块的业务执行时间都会超过预设执行时间,这时可以认为相应的关键业务模块已经发生了异常,这种判断方法在保证云ac正常运行的情况下,监听效率更高。如上所述,当关键业务模块的业务执行时间出现少量次数的异常时,这种情况是可以忽略的,只有在预设时间内出错次数大于预设警戒值时,才认为其发生异常,需要发送异常提示信息,多种情况的考虑优化了云ac的监听过程,提高了其工作效率。另外,在发送异常提示信息后,运营维护人员会在查看、解决问题后,将出错次数更新为初始值。或者,运营维护人员会在查看、解决问题后,将出错次数和/或出错次数对应的关键业务模块从异常数据库中删除。优选地,所述步骤s240还包括:步骤s243当所述出错次数在所述预设时间内不大于所述预设警戒值时,则将所述出错次数更新为初始值。具体的,例如:预设时间为1分钟,预设警戒值为20,当第一次发现关键业务模块的业务执行时间出现异常时,就将其出错次数从0更新为1,并开始统计此关键业务在1分钟内的出错次数是否大于20,如果在1分钟内其出错次数大于20,则认为此关键业务模块出现异常,需要发送异常提示信息。如果在1分钟内其出错次数没有大于20,则认为此关键业务模块未出现异常,将此出错次数更新为初始值,当下次发生异常时,再重新开始。在本发明的另一个实施例中,除与上述相同的之外,所述步骤s240还包括:步骤s244当所述出错次数在所述预设时间内不大于所述预设警戒值时,则将所述出错次数和/或所述出错次数对应的关键业务模块从所述异常数据库中删除。具体的,当所述出错次数在所述预设时间内不大于所述预设警戒值时,将所述出错次数对应的关键业务模块从异常数据库中删除,具体步骤可以参考如下:通过expire命令设定关键业务模块的键(出错次数)有效期,到期后键在异常数据库中自动删除。优选地,所述步骤s200之后还包括:步骤s400当所述关键业务模块发生异常时,打开发生异常的所述关键业务模块的细粒度日志。具体的,当关键业务模块发生异常时,可以将此发生异常的关键业务模块的细粒度日志打开,方便后续运营维护人员查看,及时了解采取哪种措施排除问题。需要注意的是,步骤s300和步骤s400的顺序并不限制,可以先运行步骤s400,再运行步骤s300;也可以先运行步骤s300,再运行步骤s400。在本发明的另一个实施例中,如图2所示,一种基于云ac的关键业务模块监听方法,包括:步骤s100实时监听并统计云ac中关键业务模块的业务执行时间;步骤s200根据统计的所述业务执行时间,判断所述关键业务模块是否发生异常;所述步骤s200包括:步骤s210判断所述业务执行时间是否出现异常;所述步骤210具体包括:步骤211判断所述业务执行时间是否超过所述业务执行时间对应的关键业务模块的预设执行时间;步骤s220当所述业务执行时间出现异常时,获取所述业务执行时间对应的所述关键业务模块的出错次数;所述步骤s220具体包括:步骤s221当所述业务执行时间超过所述业务执行时间对应的关键业务模块的预设执行时间时,判断所述关键业务模块是否在异常数据库中;步骤s222当所述关键业务模块在所述异常数据库时,获取所述业务执行时间对应的所述关键业务模块的出错次数;步骤s223当所述关键业务模块未在所述异常数据库时,将所述关键业务模块添加入所述异常数据库,将所述关键业务模块的出错次数设置为初始值,并获取所述出错次数;步骤s230根据预设规则,将获取的出现异常的所述业务执行时间对应的所述关键业务模块的出错次数更新;步骤s240根据所述关键业务模块的所述出错次数,判断所述关键业务模块是否发生异常;所述步骤s240包括:步骤s241当所述出错次数不为初始值的持续时间达到预设时间时,判断在所述异常数据库中的所述关键业务模块的所述出错次数在预设时间内是否大于预设警戒值;当所述出错次数不为初始值的持续时间未达到预设时间时,跳转至步骤s100;步骤s242当所述出错次数在所述预设时间内大于所述预设警戒值时,则认为所述出错次数对应的所述关键业务模块发生异常,执行步骤s300步骤s244当所述出错次数在所述预设时间内不大于所述预设警戒值时,则将所述出错次数和/或所述出错次数对应的关键业务模块从所述异常数据库中删除;(步骤s244可以由步骤s243代替,图中未示出;步骤s243当所述出错次数在所述预设时间内不大于所述预设警戒值时,则将所述出错次数更新为初始值);步骤s300当所述关键业务模块发生异常时,发送异常提示信息;步骤s400当所述关键业务模块发生异常时,打开发生异常的所述关键业务模块的细粒度日志。具体的,本发明的基于云ac的关键业务模块监听方法,只需要通过监听其业务执行时间以及相应的出错次数,就可以达到监听关键业务模块是否出现异常的目的,不需要一直监听各关键业务模块的细粒度日志,大大降低了云ac的性能占用率,在保证云ac得到监听的情况下,大大改善了用户的使用体验。在本发明的另一个实施例中,如图3所示,一种基于云ac的关键业务模块监听系统,包括:关键业务模块10;监听统计模块20,与所述关键业务模块电连接,用于实时监听并统计云ac中所述关键业务模块的业务执行时间;异常判断模块30,与所述监听统计模块电连接,所述异常判断模块根据所述监听统计模块统计的所述业务执行时间,判断所述关键业务模块是否发生异常;异常提示模块40,与所述异常判断模块电连接,当所述异常判断模块判断所述关键业务模块发生异常时,所述异常提示模块发送异常提示信息。具体的,此系统是基于云ac实现的,关键业务模块在云ac中起着极为重要的作用,是考量云ac的业务性能能不能满足使用性能指标的关键因素。根据关键业务模块的业务执行时间,来判断关键业务模块是否发生异常,若发生异常,就立即发送异常提示信息给运营维护人员,以便他们及时采取相应的措施来排除问题,使云ac恢复正常的工作性能。云ac可以通过邮件通道将异常信息发送给运营维护人员,也可以以报警声音作为异常提示信息发出。在本发明的另一个实施例中,除与上述相同的之外,监听并统计云ac的关键业务模块的数量可以为多个,即监听并统计多个关键业务模块各自的业务执行时间,分别对各关键业务模块的业务执行时间进行判断,当有某一个或一些关键业务模块发生异常时,就发送异常提示信息。优选地,在发送异常提示信息时,把发生异常的关键业务模块的名称一起发送,便于让运营维护人员了解具体哪个或哪些关键业务模块出问题。在本发明的另一个实施例中,除与上述相同的之外,所述异常判断模块30包括:时间判断子模块31,用于判断所述业务执行时间是否出现异常;次数判断子模块32,当异常数据库将所述出错次数更新后,所述次数判断子模块根据所述关键业务模块的所述出错次数,判断所述关键业务模块是否发生异常;所述基于云ac的关键业务模块监听系统还包括:次数获取模块50,与所述异常判断模块电连接,当所述异常判断模块判断所述业务执行时间出现异常时,所述次数获取模块获取所述业务执行时间对应的所述关键业务模块的出错次数;所述异常数据库60,与所述次数获取模块、所述异常判断模块电连接,当所述次数获取模块获取了所述出错次数时,所述异常数据库根据预设规则,将获取的出现异常的所述业务执行时间对应的所述关键业务模块的出错次数更新。具体的,判断统计的关键业务模块的业务执行时间是否出现异常具体包括:判断统计的业务执行时间是否在预设执行时间范围内,如果在的话,就说明业务执行时间未出现异常;如果不在的话,就说明业务执行时间出现异常。当然,判断业务执行时间出现异常的方式也可以为其他方式,并不局限于上述那一种。运营维护人员会根据大数据得出每个关键业务模块的标准执行时间,作为预设执行时间,将实时统计的当前业务执行时间和预设执行时间进行比较,若当前的业务执行时间超过了对应关键业务模块的预设执行时间,则需要获取并更新此关键业务模块的出错次数,以便后续记录下,为判断关键业务模块是否出现异常作为判断依据。需要注意的是,当关键业务模块的数量为多个时,每个关键业务模块的预设执行时间是不同的,因此,需要将每个关键业务模块当前的业务执行时间与其对应的预设执行时间进行判断,这样才能确认是否需要更新各关键业务模块的出错次数。之所以每个关键业务模块的预设执行时间不同,是因为,每个关键业务模块其处理的业务不同。具体的例子可以参见相应的方法实施例,在此不再详细描述。优选地,如图4所示,所述时间判断子模块31,进一步用于判断所述业务执行时间是否超过所述业务执行时间对应的关键业务模块的预设执行时间;所述异常判断模块还包括:模块判断子模块33,当所述时间判断子模块判断所述业务执行时间出现异常时,所述模块判断子模块判断所述关键业务模块是否在所述异常数据库中;所述异常数据库60,当所述异常判断模块判断所述关键业务模块未在所述异常数据库时,所述异常数据库进一步用于将所述关键业务模块添加入所述异常数据库,将所述关键业务模块的出错次数设置为初始值;所述次数获取模块50,进一步用于获取所述业务执行时间对应的所述关键业务模块的出错次数。具体的,专门开辟一个异常数据库,用来存储关键业务模块的出错次数,当出现异常的业务执行时间对应的关键业务模块已经在异常数据库时,直接获取所述关键业务模块当前的出错次数(这里可以理解为:这个关键业务模块已经出错过了,因此被添加进了异常数据库中;也可以理解为,在这个异常数据库中为每个关键业务模块开辟了空间存储其出错次数);当关键业务模块不在异常数据库时,将关键业务模块添加进异常数据库,并设置其出错次数为初始值,之后再以此初始值为基础进行更新。具体的例子可以参见相应的方法实施例,在此不再详细描述。优选地,所述次数判断子模块32,进一步用于当所述出错次数不为初始值的持续时间达到预设时间时,判断在所述异常数据库中的所述关键业务模块的所述出错次数在预设时间内是否大于预设警戒值;以及,当所述出错次数在所述预设时间内大于所述预设警戒值时,所述次数判断子模块认为所述出错次数对应的所述关键业务模块发生异常。具体的,一般情况下,考虑到云ac性能或者外部接口的连接变化,一段时间内少量的性能下降情况(即,业务执行时间出现少量的异常情况)可以忽略不计,没有必要一出现问题就通知运营维护人员。如果云ac发生异常情况,比如数据库读写变慢,外部接口通讯时间变长,那么在这个时间段内,大部分的关键业务模块的业务执行时间都会超过预设执行时间,这时可以认为相应的关键业务模块已经发生了异常,这种判断方法在保证云ac正常运行的情况下,监听效率更高。如上所述,当关键业务模块的业务执行时间出现少量次数的异常时,这种情况是可以忽略的,只有在预设时间内出错次数大于预设警戒值时,才认为其发生异常,需要发送异常提示信息,多种情况的考虑优化了云ac的监听过程,提高了其工作效率。在本发明的另一个实施例中,除与上述相同的之外,所述异常数据库,当所述出错次数在所述预设时间内不大于所述预设警戒值时,所述异常数据库60进一步用于将所述出错次数更新为初始值。具体的,例如:预设时间为1分钟,预设警戒值为20,当第一次发现关键业务模块的业务执行时间出现异常时,就将其出错次数从0更新为1,并开始统计此关键业务在1分钟内的出错次数是否大于20,如果在1分钟内其出错次数大于20,则认为此关键业务模块出现异常,需要发送异常提示信息。如果在1分钟内其出错次数没有大于20,则认为此关键业务模块未出现异常,将此出错次数更新为初始值,当下次发生异常时,再重新开始。通过统计预设时间内的出错次数确认云ac是否真的出现异常的方法,杜绝了云ac短暂性、偶然性出现问题的情况,降低了运营维护人员得到无价值的异常提示信息的机会。在本发明的另一个实施例中,除与上述相同的之外,所述异常数据库60,当所述出错次数在所述预设时间内不大于所述预设警戒值时,所述异常数据库进一步用于将所述出错次数和/或所述出错次数对应的关键业务模块从所述异常数据库中删除。具体的,当在预设时间内关键业务模块的出错次数不大于预设警戒值时,就将出错次数删除,为下次关键业务模块出错时重新统计作准备。或者,将出错次数和出错次数对应的关键业务模块一起从异常数据库中删除,一来释放异常数据库的存储空间,二来也为下次关键业务模块出错时重新统计作准备。在本发明的另一个实施例中,如图4所示,除与上述相同的之外,还包括:日志管理模块70,与所述异常判断模块电连接,当所述异常判断模块判断所述关键业务模块发生异常时,所述日志管理模块打开发生异常的所述关键业务模块的细粒度日志。具体的,当关键业务模块发生异常时,可以将此发生异常的关键业务模块的细粒度日志打开,方便后续运营维护人员查看,及时了解采取哪种措施排除问题。需要注意的是,打开细粒度日志和发送异常提示信息的顺序并不作限定。本发明在不影响云ac整体性能的情况下,可以对云ac的关键业务模块进行监听,当出现异常时,及时通知运营维护人员,大大提高了用户的使用体验。应当说明的是,上述实施例均可根据需要自由组合。以上所述仅是本发明的优选实施方式,应当指出,对于本
技术领域
的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1