一种分布式业务的监控告警方法及装置与流程

本发明属于计算机技术领域，尤其涉及一种分布式业务的监控告警方法及装置。

背景技术：

随着大数据技术的发展，单一的计算能力已经无法满足日渐增加的数据需求，分布式计算能力显得尤为重要，如何保障分布式计算能力的正常、可靠运行，以及非正常运行后的告警恢复机制，是目前监控系统技术领域关注的重点。

现有的分布式业务的监控告警技术包括：(1)在每台业务终端机器部署监控脚本，仅对业务进程是否存活进行监控，当发现监控的业务进程没有存活，会向监控中心上报此次失败信息，监控中心接受到此消息后，会读取预定义的告警配置并发送告警。(2)在每台业务终端机器提供单独的监控接口，监控中心需单独编写代码来调用各个业务终端机所提供的监控接口，以检查业务的可用性，如果调用接口过程中发现返回预先定义的失败状态协议，则读取告警配置并发送告警。

上述方案的缺陷在于：(1)仅对业务进程进行存活监控，不能体现内部逻辑是否正常运行，不能达到完善的监控目的；而在各个机器部署监控脚本，可能会被中断，且部署耗时，不方便于集中调度管理。(2)对每台业务终端机器，开发人员都需要单独编写监控接口，增加了开发量；并且监控的完善性完全依赖于监控接口，不能体现实际业务是否运行正常，难以达到实际的监控目的。

技术实现要素：

本发明实施例的目的在于提供了一种分布式业务的监控告警方法及系统，能够深入到业务内部，完善监控业务运行情况，且不需要在每台业务终端机部署监控脚本，也不需要单独编写监控接口，减轻了部署成本和开发成本。

本发明公开了一种分布式业务的监控告警方法，包括以下步骤：

s01，在应用程序的预定义代码片段部署业务监控节点，以监控代码运行；

s02，当代码运行发生异常时捕获异常消息；

s03，根据捕获的异常消息产生相应告警。

进一步的，所述预定义代码片段包括：网络通信、数据库访问、第三方接口调用、文件读写、缓存服务访问、消息队列服务访问或各种服务中间件调用中的至少一种。

进一步的，所述代码运行发生异常为导致应用程序不能正常运行的状态，代码运行发生异常包括：网络请求断开、数据库不能访问、第三方接口调用超时、文件读写失败、连接缓存系统失败、消息队列或各种中间件服务通信失败。

进一步的，异常消息至少包括业务标识。

进一步的，捕获的异常消息以消息队列形式传递。

本发明还公开了一种分布式业务的监控告警装置，包括业务监控节点部署模块、异常消息捕获模块、告警模块，其中：

业务监控节点部署模块，用于在应用程序的预定义代码片段部署业务监控节点，以监控代码运行；

异常消息捕获模块，用于当代码运行发生异常时捕获异常消息；

告警模块，用于根据捕获的异常消息产生相应告警。

进一步的，所述预定义代码片段包括：网络通信、数据库访问、第三方接口调用、文件读写、缓存服务访问、消息队列服务访问或各种服务中间件调用中的至少一种。

进一步的，所述代码运行发生异常为导致应用程序不能正常运行的状态，代码运行发生异常包括：网络请求断开、数据库不能访问、第三方接口调用超时、文件读写失败、连接缓存系统失败、消息队列或各种中间件服务通信失败。

进一步的，异常消息至少包括业务标识。

进一步的，所述监控告警装置还包括消息队列模块，用于接收异常消息捕获模块捕获的异常消息，并将其发送给告警模块。

本发明相比于现有技术的有益效果在于，本发明在应用程序的预定义代码片段部署业务监控节点以监控代码运行，当代码运行发生异常时捕获异常消息，并产生告警。在实际业务代码段进行监控，不仅能了解业务进程的存活情况，也能体现内部逻辑的运行情况，能达到完善的监控目的。并且，开发人员可以根据预设规则合理的布置监控节点，提高了监控的准确性和灵活性。另外，本发明也不需要单独编写监控接口，大大降低了监控的部署及开发成本。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一示例性实施例示出的一种分布式业务的监控告警方法的流程图。

图2为本发明一示例性实施例示出的一种分布式业务的监控告警装置的结构示意图。

图3为本发明另一示例性实施例示出的一种分布式业务的监控告警装置的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优节点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，一种分布式业务的监控告警方法，包括以下步骤：

s101，在应用程序的预定义代码片段部署业务监控节点，以监控代码运行。

在应用程序中，主动的对可能发生异常且有监控意义的代码片段里代码片段部署业务监控节点，监控代码运行。如在网络通信、数据库访问、第三方接口调用、文件读写、缓存服务访问、消息队列服务访问、各种服务中间件调用等代码片段处部署业务监控节点。

比如在一个学生信息系统里，有一个业务是从数据库读取某个学生的用户信息，则在数据库访问这一代码片段进行监控。可以理解的，数据库访问这段代码片段用于操作数据库这种服务组件，而如果数据库不能正常服务或访问数据库时不能正常通信，必然会造成相应代码片段异常，导致业务进程奔溃，因此需要在此处部署监控节点。

又比如，对于一些需要获取授权用户信息的业务，如微博、微信等，是调用第三方接口通过网络来获取信息。而如果网络或第三方服务的不可用，必然会造成相应代码片段异常，导致业务进程奔溃，因此需要在此处部署监控节点。

s102，当代码运行发生异常时捕获异常消息。

代码运行发生异常主要指导致应用程序不能正常运行的状态。比如网络请求断开、数据库不能访问、第三方接口调用超时、文件读写失败、连接缓存系统失败、消息队列或各种中间件服务通信失败等等。

以学生信息系统为例说明，当发现数据库访问这一代码片段发生异常，即数据不能访问，则捕获异常消息。捕获的异常消息至少包括业务名称，当然，还可以包括异常时间、事件标识、异常堆栈等。业务名称，为具有一定意义的能够描述此业务场景的标识，用于标识被告警人；异常时间可以为当前系统时间；事件标识，可以为用于区分一个业务中的多个监控点的标识；堆栈信息可以为发生异常的堆栈上下文调用信息，用于排查异常原因。

基本的各种编程语言都有自己的捕获异常实现方式，比如在python语言中，捕获异常的方式为try，except；在php，java语言中捕获异常的方式为try，catch。为了方便对异常消息进行处理，优选将异常消息组成消息体，比如拼装成json消息体，形式如：

{“业务名称”:“读取学生信息”，“异常时间:“xxxx-xx-xxxx:xx:xx”，“事件标识”:“数据库读取”，”异常堆栈”:”xx“}

s103，根据捕获的异常消息产生相应告警。

比如对s102过来的消息体进行decode操作，然后根据业务名称和预定义在配置文件中的业务名称和告警人信息的对应关系来读取配置中的告警人信息，产生相应告警。比如业务名称：{被告警人名称，被告警人通知方式，告警人地址}，告警人名称为被告警人真实名称；被告警人通知方式可以为短信或邮件；被告警人地址可以为被告警人的邮件地址或电话号码。若捕获的异常消息的业务名称能匹配预定义配置文件的告警信息，则按配置被告警方式通知被告警人已产生告警。

另外，在步骤s102、s103之间可以利用消息队列来传递捕获的异常消息，相比传统的通过http来通信，减少了一些无用的头部信息，数据包比http更小，节省了传输带宽，并且可以灵活的部署多个监听消息队列模块来适应异常消息堆积的情况。

本实施例根据预设的规则为应用程序部署业务监控节点以监控代码运行，当代码运行发生异常时捕获异常消息，并产生告警。在实际业务代码段进行监控，不仅能了解业务进程的存活情况，也能体现内部逻辑的运行情况，能达到完善的监控目的。并且，开发人员可以根据预设规则合理的布置监控节点，提高了监控的准确性和灵活性。另外，本发明也不需要单独编写监控接口，大大降低了监控的部署及开发成本。

本发明还公开了一种分布式业务的监控告警装置，如图2所示，包括业务监控节点部署模块11、异常消息捕获模块12、告警模块13，其中：

业务监控节点部署模块11，用于在应用程序的预定义代码片段部署业务监控节点，以监控代码运行。

在应用程序中，主动的对可能发生异常且有监控意义的代码片段里代码片段部署业务监控节点，监控代码运行。如在网络通信、数据库访问、第三方接口调用、文件读写、缓存服务访问、消息队列服务访问、各种服务中间件调用等代码片段处部署业务监控节点。

比如在一个学生信息系统里，有一个业务是从数据库读取某个学生的用户信息，则在数据库访问这一代码片段进行监控。可以理解的，数据库访问这段代码片段用于操作数据库这种服务组件，而如果数据库不能正常服务或访问数据库时不能正常通信，必然会造成相应代码片段异常，导致业务进程奔溃，因此需要在此处部署监控节点。

又比如，对于一些需要获取授权用户信息的业务，如微博、微信等，是调用第三方接口通过网络来获取信息。而如果网络或第三方服务的不可用，必然会造成相应代码片段异常，导致业务进程奔溃，因此需要在此处部署监控节点。

异常消息捕获模块12，用于当代码运行发生异常时捕获异常消息。

代码运行发生异常主要指导致应用程序不能正常运行的状态。比如网络请求断开、数据库不能访问、第三方接口调用超时、文件读写失败、连接缓存系统失败、消息队列或各种中间件服务通信失败等等。

以学生信息系统为例说明，当发现数据库访问这一代码片段发生异常，即数据不能访问，则捕获异常消息。捕获的异常消息至少包括业务名称，当然，还可以包括异常时间、事件标识、异常堆栈等。业务名称，为具有一定意义的能够描述此业务场景的标识，用于标识被告警人；异常时间可以为当前系统时间；事件标识，可以为用于区分一个业务中的多个监控点的标识；堆栈信息可以为发生异常的堆栈上下文调用信息，用于排查异常原因。

基本的各种编程语言都有自己的捕获异常实现方式，比如在python语言中，捕获异常的方式为try，except；在php，java语言中捕获异常的方式为try，catch。为了方便对异常消息进行处理，优选将异常消息组成消息体，比如拼装成json消息体，形式如：

{“业务名称”:“读取学生信息”，“异常时间:“xxxx-xx-xxxx:xx:xx”，“事件标识”:“数据库读取”，”异常堆栈”:”xx“}

告警模块13，用于根据捕获的异常消息产生相应告警。

比如对异常消息捕获模块12发送过来的消息体进行decode操作，然后根据业务名称和预定义在配置文件中的业务名称和告警人信息的对应关系来读取配置中的告警人信息，产生相应告警。比如业务名称：{被告警人名称，被告警人通知方式，告警人地址}，告警人名称为被告警人真实名称；被告警人通知方式可以为短信或邮件；被告警人地址可以为被告警人的邮件地址或电话号码。若捕获的异常消息的业务名称能匹配预定义配置文件的告警信息，则按配置被告警方式通知被告警人已产生告警。

另外，监控告警装置还包括消息队列模块14，用于接收异常消息捕获模块12捕获的异常消息，并将其发送给告警模块13。相比传统的通过http来通信，减少了一些无用的头部信息，数据包比http更小，节省了传输带宽，并且可以灵活的部署多个监听消息队列模块来适应异常消息堆积的情况。

在具体产品中，如图3所示，业务监控节点部署模块11、异常消息捕获模块12可以部署于业务终端机器，即业务代码片段所在的机器，实际场景中可能有多台。告警模块13及消息队列模块14可部署于监控终端机器。

本实施例根据预设的规则为应用程序部署业务监控节点以监控代码运行，当代码运行发生异常时捕获异常消息，并产生告警。在实际业务代码段进行监控，不仅能了解业务进程的存活情况，也能体现内部逻辑的运行情况，能达到完善的监控目的。并且，开发人员可以根据预设规则合理的布置监控节点，提高了监控的准确性和灵活性。另外，本发明也不需要单独编写监控接口，大大降低了监控的部署及开发成本。

本领域普通技术人员可以理解为上述实施例所包括的各个模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能模块的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

本领域普通技术人员还可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以在存储于一计算机可读取存储介质中，所述的存储介质，包括rom/ram、磁盘、光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。