CN109739727B - 微服务架构中的服务监控方法及装置 - Google Patents
微服务架构中的服务监控方法及装置 Download PDFInfo
- Publication number
- CN109739727B CN109739727B CN201910005322.8A CN201910005322A CN109739727B CN 109739727 B CN109739727 B CN 109739727B CN 201910005322 A CN201910005322 A CN 201910005322A CN 109739727 B CN109739727 B CN 109739727B
- Authority
- CN
- China
- Prior art keywords
- service
- calling
- information
- message
- abnormal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 67
- 238000000034 method Methods 0.000 title claims abstract description 65
- 230000002159 abnormal effect Effects 0.000 claims abstract description 108
- 238000001514 detection method Methods 0.000 claims description 3
- 238000012806 monitoring device Methods 0.000 abstract description 61
- 238000010586 diagram Methods 0.000 description 6
- 238000011161 development Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 238000012800 visualization Methods 0.000 description 5
- 230000005856 abnormality Effects 0.000 description 3
- 241000283973 Oryctolagus cuniculus Species 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Landscapes
- Debugging And Monitoring (AREA)
- Alarm Systems (AREA)
Abstract
一种微服务架构中的服务监控方法及装置，所述方法包括：读取消息队列MQ中的调用消息，调用消息用于指示一个服务的一次调用，调用消息是在对应的服务被调用后由服务设备写入MQ；根据第一预设时长内读取的调用消息，生成待检测信息，待检测信息包括第一预设时长内各个服务的异常次数和超时次数；检测待检测信息是否满足预先设定的报警条件；若待检测信息满足报警条件，则向预先设定的用户终端发送报警信息。本申请中，通过MQ这一中间件，服务设备能够直接将调用消息传输给监控设备，使得监控设备能够实时地获取调用消息，并进行监控。因此，一旦服务出现异常等安全问题，监控设备能够及时发现并通知用户，提高了系统的安全性。
Description
技术领域
本申请涉及计算机技术领域，特别涉及一种微服务架构中的服务监控方法及装置。
背景技术
随着近年来互联网行业的快速发展，微服务架构的应用越来越广泛。微服务架构是拆分出多个可以独立开发，设计，运行和运维的服务，每个服务可以独立部署并且相互隔离，服务之间通过应用程序编程接口(Application Programming Interface，API)调用。依靠服务之间的调用，来服务用户，满足用户的需求。
微服务架构中的服务会被部署在不同的服务设备中，例如终端或服务器。一个服务设备可以部署一个服务，也可以部署多个服务。运行整个微服务架构的系统实际上运行各个服务设备。在运行过程中，为了系统的安全，由监控设备监控服务设备上各个服务被调用的详细信息，例如被调用的服务的名称、服务中具体被调用的方法或接口、被调用的次数、调用的耗时等等。
现有技术中，由于不同服务可能是基于不同开发语言开发的，服务设备无法将服务被调用的详细信息直接发送给监控设备。因此，服务设备生成日志文件，记录服务被调用的详细信息，等待监控设备来查看。监控设备周期性地查看各个服务设备上的日志文件，获取服务被调用的详细信息。因为各个服务被调用的详细信息是被动地等待监控设备来查看，所以上述监控设备获取的信息不是实时信息。一旦服务出现异常等安全问题，监控设备不能及时发现并通知用户，降低了系统的安全性。
发明内容
本申请提供了一种微服务架构中的服务监控方法及装置，可用于解决在现有技术中服务设备无法将服务被调用的详细信息直接发送给监控设备，导致一旦服务出现异常等安全问题，监控设备不能及时发现并通知用户，降低了系统的安全性的问题。
第一方面，本申请提供一种微服务架构中的服务监控方法，所述方法包括：
读取消息队列MQ中的调用消息，所述调用消息用于指示一个服务的一次调用，所述调用消息是在对应的服务被调用后由服务设备写入所述MQ；
根据第一预设时长内读取的调用消息，生成待检测信息，所述待检测信息包括所述第一预设时长内各个服务的异常次数和超时次数，所述异常次数是指一个服务出现异常的调用次数，所述超时次数是指调用一个服务超时的次数；
检测所述待检测信息是否满足预先设定的报警条件；
若所述待检测信息满足所述报警条件，则向预先设定的用户终端发送报警信息。
可选地，所述调用消息包括：调用时长和异常值，所述调用时长是指服务被调用的耗时，所述异常值为0或1；
所述根据第一预设时长内读取的调用消息，生成待检测信息，包括：
将所述第一预设时长内，对应于同一服务的调用消息发送至同一信道；
开启所述信道对应的协程；
通过所述协程在所述对应于同一服务的调用消息中，确定所述调用时长大于预设阈值的调用消息的数量为所述超时次数；
通过所述协程在所述对应于同一服务的调用消息中，确定所述异常值为1的调用消息的数量为所述异常次数；
根据所述各个服务的所述超时次数和所述异常次数，得到所述待检测信息。
可选地，所述方法还包括：
每隔预设时间间隔，根据所述预设时间间隔内读取的调用消息，更新日志文件，所述日志文件包括各个服务对应的记录信息，所述记录信息用于表示服务被调用的历史记录。
可选地，所述根据所述预设时间间隔内读取的调用消息，更新日志文件，包括：
确定待更新服务，所述待更新服务是指所述预设时间间隔内读取的调用消息对应的服务；
根据所述待更新服务对应的调用消息，更新所述待更新服务对应的记录信息。
可选地，所述报警条件包括：所述异常次数大于第一预设次数，和/或，所述超时次数大于第二预设次数。
第二方面，本申请提供一种微服务架构中的服务监控装置，所述装置包括：
消息读取模块，用于读取消息队列MQ中的调用消息，所述调用消息用于指示一个服务的一次调用，所述调用消息是在对应的服务被调用后由服务设备写入所述MQ；
信息生成模块，用于根据第一预设时长内读取的调用消息，生成待检测信息，所述待检测信息包括所述第一预设时长内各个服务的异常次数和超时次数，所述异常次数是指一个服务出现异常的调用次数，所述超时次数是指调用一个服务超时的次数；
报警检测模块，用于检测所述待检测信息是否满足预先设定的报警条件；
警报发送模块，用于当所述待检测信息满足所述报警条件时，向预先设定的用户终端发送报警信息。
可选地，所述调用消息包括：调用时长和异常值，所述调用时长是指服务被调用的耗时，所述异常值为0或1；
所述信息生成模块，具体用于：
将所述第一预设时长内，对应于同一服务的调用消息发送至同一信道；
开启所述信道对应的协程；
通过所述协程在所述对应于同一服务的调用消息中，确定所述调用时长大于预设阈值的调用消息的数量为所述超时次数；
通过所述协程在所述对应于同一服务的调用消息中，确定所述异常值为1的调用消息的数量为所述异常次数；
根据所述各个服务的所述超时次数和所述异常次数，得到所述待检测信息。
可选地，所述装置还包括：
日志更新模块，用于每隔预设时间间隔，根据所述预设时间间隔内读取的调用消息，更新日志文件，所述日志文件包括各个服务对应的记录信息，所述记录信息用于表示服务被调用的历史记录。
可选地，所述日志更新模块，具体用于：
确定待更新服务，所述待更新服务是指所述预设时间间隔内读取的调用消息对应的服务；
根据所述待更新服务对应的调用消息，更新所述待更新服务对应的记录信息。
可选地，所述报警条件包括：所述异常次数大于第一预设次数，和/或，所述超时次数大于第二预设次数。
在本申请中，服务设备在服务被调用后，利用MQ这一中间件，将调用消息传输给监控设备。监控设备根据从MQ中读取的调用消息，对服务设备上的服务进行监控，在满足报警条件时，向用户发送报警信息。通过MQ，服务设备能够直接将调用消息传输给监控设备，使得监控设备能够实时地获取调用消息，并进行监控。因此，一旦服务出现异常等安全问题，监控设备能够及时发现并通知用户，提高了系统的安全性。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是根据一示例性实施例示出的一种微服务架构中的服务监控方法的流程图；
图2是根据一示例性实施例示出的监控服务调用并生成日志文件的流程示意图。
图3是根据一示例性实施例示出的一种微服务架构中的服务监控装置的示意性框图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
本申请实施例提供的方法，各步骤的执行主体可以是部署有监控系统的监控设备。可选地，各步骤的执行主体可以是监控设备中运行的监控系统。该监控系统是指用于监控各个服务的调用情况的系统。上述监控设备可以是终端或服务器。
在本申请提供的实施例中，监控设备监控的服务部署在各自的服务设备中。该服务可以是微服务架构中的微服务，也可以是接入微服务架构的其它服务，例如具有开放API的服务。此外，调用服务实际上是通过访问服务的接口或方法实现的。
图1是根据一示例性实施例示出的一种微服务架构中的服务监控方法的流程图。该方法可以包括如下几个步骤：
步骤101，读取消息队列(Message，MQ)中的调用消息。
当服务设备上部署的服务调用完成后，服务设备生成一个指示本次调用的调用消息。由于调用消息需要准确地指示出一个服务的一次调用，因此调用消息包括一次调用的相关数据，例如被调用服务的服务名称，调用服务时访问的接口名称和服务设备的互联网协议(Internet Protocol，IP)地址等等。每生成一个调用消息，服务设备立即将新生成的调用消息写入MQ中。每当MQ中有调用消息写入，监控设备作为MQ消费者从消息队列中读取调用消息。
可选地，调用消息包括：服务标识，调用时长、异常值、接口地址、调用时间戳、IP地址和主键信息。服务标识用于唯一指示一个服务，例如服务名称。调用时长是指服务被调用的耗时，即一个服务从开始被调用到调用结束所耗费的时间。异常值用于指示调用是否发生异常。异常值为0或1。若调用没有发生异常，则服务设备将调用消息中的异常值置为0；若调用发生异常，则服务设备将调用消息中的异常值置为1。上述异常是指服务在运行过程中发生的导致程序异常的事件，例如由外部问题，如硬件错误和输入错误等，所导致的异常事件。接口地址是指服务被调用时被访问的接口的地址，例如action-service/heath。因为每个接口都有唯一的一个地址，所以接口地址可以唯一指示一个接口。调用时间戳用于指示服务被调用的时间，例如一个服务在2018年7月26日12时36分48秒被调用，则生成一个调用时间戳：201807261123648。主键信息用于唯一指示一个接口的一次访问，例如，主键信息可以是“接口地址+调用时间戳”的形式。IP地址是指部署有调用消息对应服务的服务设备的IP地址。
可选地，调用消息还包括：子方法配置项。在一个服务被调用时，该服务被访问的接口或方法中的子方法也可能被调用。服务设备生成子方法配置项，来记录子方法被调用的情况。其中，子方法配置项包括：子方法被调用的调用时长，子方法的异常值，子方法的方法标识、子方法的异常值以及子方法的主键信息。子方法被调用的调用时长是指子方法被调用的耗时。子方法的异常值用于指示子方法被调用时是否发生异常。子方法的方法标识用于唯一指示一个方法，例如子方法的方法名。子方法的主键信息用于唯一指示一个子方法的一次调用。
MQ是一种应用于分布式系统的中间件，而微服务架构正是分布式系统的一种应用方式。MQ连接的两端为写入消息的一端即MQ生产者和读取消息的一端即MQ消费者。只要按照双方预先规定的消息格式和通信机制，MQ消费者就可以读取MQ生产者写入的消息。MQ消费者不需要知道MQ生产者具体的信息，例如MQ生产者的开发语言。
在本申请实施例中，监控设备是上述MQ消费者，各个服务设备是上述MQ生产者。具有MQ这一中间件，监控设备能够实时地获取服务设备上传的调用消息。即使不同服务是基于不同开发语言开发的，例如Go语言(The Go Programming Language，GoLang)，Java和C++等等，由于调用消息是基于MQ传输的，服务设备也能够按照预先规定的消息格式和通信机制将调用消息发送给监控设备。具体地，服务设备可以将调用消息以Json格式发送。
可选地，MQ为基于高级消息队列协议(Advanced Message Queuing Protocol，AMQP)开发的Rabbit MQ。Rabbit MQ采用erlang语言编程开发，是一个开源的AMQP实现，支持多种开发语言的MQ生产者，例如Java，Python，超文本预处理器(HypertextPreprocessor，PHP)语言和C语言等等。
步骤102，根据第一预设时长内读取的调用消息，生成待检测信息。
监控设备能够实时获取服务设备的调用消息，但还需要根据调用消息对各个服务的调用情况进行检测，才能确定各个服务的调用是否存在安全问题。因此，监控设备根据第一预设时长内读取的调用消息，生成待检测信息。待检测信息包括第一预设时长内调用消息对应的各个服务被调用时的异常次数和超时次数。监控设备检测各个服务的调用是否存在安全问题实际是检测第一预设时长内的异常次数和超时次数。异常次数是指一个服务出现异常的调用次数。超时次数是指调用一个服务超时的次数。第一预设时长是根据实际经验预先设定的时长。例如，服务十分钟内的异常次数和超时次数能够反映该服务运行的安全性和稳定性。那么，将第一预设时长设置为十分钟。
在一种可能的实施方式中，监控设备在读取MQ中的一个调用消息后，获取前第一预设时长内读取的调用消息。监控设备根据调用消息中的服务标识确定各个调用消息对应的服务，再将对应于同一服务的调用消息发送至同一信道(Channle)。监控设备开启各个信道对应的协程，由各个协程根据信道中的调用消息生成待检测信息。协程与信道一一对应，而每个信道中是对应于同一服务的调用消息。因此，每一个服务的调用消息都由一个单独的协程进行处理。对于同一服务的调用消息，若一个调用消息中的调用时长大于预设阈值，则确定该调用消息所指示的调用为超时调用。因此，监控设备通过协程，确定调用时长大于预设阈值的调用消息，将这些调用消息的数量作为超时次数。监控设备通过协程，确定异常值为1的调用消息，将异常值为1的调用消息的数量作为异常次数。监控设备根据通过各个协程，确定的各个服务的超时次数和异常次数，最终得到待检测信息。
示例性地，监控设备在第一预设时长内读取了4个调用消息。4个调用消息分别对应于两个服务：服务A和服务B。服务A对应的两个调用消息中的调用时长均小于预设阈值，则服务A的超时次数为0。服务A对应的两个调用消息中的异常值均为1，则服务A的异常次数为2。服务B对应的两个调用消息中的调用时长均大于预设阈值，则服务B的超时次数为2。服务B对应的两个调用消息中的异常值均为0，则服务B的异常次数为0。
在另一种可能的实施方式中，监控设备检测的不是服务的超时次数和异常次数，而是服务中被访问的接口的超时次数和异常次数。因此，监控设备根据调用消息中的服务标识和接口地址确定各个调用消息对应的服务和接口，再将对应于同一服务、同一接口的调用消息发送至同一信道。监控设备开启各个信道对应的协程，由各个协程根据信道中的调用消息生成待检测信息。协程与信道一一对应，而每个信道中是对应于同一接口的调用消息。因此，每一个接口对应的调用消息都由一个单独的协程进行处理。此时，待检测信息是各个接口的待检测信息，其中包括了被访问的接口的超时次数和异常次数。
示例性地，监控设备在第一预设时长内读取了4个调用消息。4个调用消息分别对应于一个服务的两个接口：服务A的接口：A1和A2。A1对应的两个调用消息中的调用时长均小于预设阈值，则A1的超时次数为0。A1对应的两个调用消息中的异常值均为1，则A1的异常次数为2。A2对应的两个调用消息中的调用时长均大于预设阈值，则A2的超时次数为2。A2对应的两个调用消息中的异常值均为0，则A2的异常次数为0。那么，服务A的超时次数为2，异常次数也为2。但是，具体到接口时，A1的超时次数为0，异常次数为2；A2的超时次数为2，异常次数为0。
需要说明的是，上述两种方式生成的待检测信息只是划分的依据不同。一个是针对不同的服务进行分类，一个是针对不同的接口进行分类。若监控设备需要监控服务，则针对不同的服务进行分类。若监控设备需要监控接口，则针对不同的接口进行分类。
通过协程、信道和监控对象(服务或接口)的一一对应，监控设备在服务调用出现高并发的情况下，仍然能够有效地进行监控。由于监控设备并行地开启了不同的协程对不同信道中的调用消息进行处理，即使服务调用出现高并发，MQ中写入了大量服务的调用消息，监控设备也可以利用协程支持高并发处理的特点，及时地处理调用消息，进而进行监控。
可选地，监控设备可以确定一个服务累计的异常次数和超时次数。那么，监控设备每读取一个服务对应的调用消息时，都要更新该服务累计的异常次数和超时次数。但是，在更新过程中，监控设备可能读取到该服务对应的又一个调用消息。为了防止在高并发情况下更新出现数据不一致问题。监控设备需要在根据前一个调用消息更新异常次数和超时次数后，再根据后一个调用消息进行更新。因此，监控设备在更新异常次数和超时次数，开启数据锁，例如Mutex锁，锁定相关数据，使得监控设备每次只能够根据一个调用消息进行更新。从而，监控设备根据调用消息的顺序，更新累计的异常次数和超时次数，保证数据的准确性和安全性。
可选地，在生成待检测信息前，监控设备对读取的调用消息进行过滤，删除不需要监控的调用消息，例如静态页面的消息。
步骤103，检测待检测信息是否满足预先设定的报警条件。
监控设备检测各个服务的调用是否存在安全问题实际是检测第一预设时长内的异常次数和超时次数。因此，对于检测待检测信息所设定的报警条件，是针对异常次数和超时次数设定的条件。报警条件可以根据实际经验预先设定。若待检测信息满足报警条件，则执行步骤104；若待检测信息不满足报警条件，则监控设备不进行任何操作。
可选地，报警条件包括：异常次数大于第一预设次数，和/或，超时次数大于第二预设次数。当异常次数大于第一预设次数，和/或，超时次数大于第二预设次数时，监控设备确定系统存在安全问题，需要发出警报。其中，报警条件可以针对单个服务进行设置，也可以针对多个服务进行设置。
在一种可能的实施方式中，监控设备检测所有服务的异常次数的总和以及超时次数的总和。此时，上述报警条件是针对所有服务预先设置的。当所有服务总的异常次数大于第一预设次数，和/或，所有服务总的超时次数大于第二预设次数时，监控设备确定待检测信息满足报警条件。
示例性地，待检测信息包括的4个服务的异常次数和超时次数。4个服务的异常次数分别为：1，2，3，4。4个服务的超时次数分别为：0，1，0，2。第一预设次数为6次。第二预设次数为5次。4个服务的总异常次数为10次，大于第一预设次数。4个服务的总超时次数为3次，小于第二预设次数。监控设备确定待检测信息满足报警条件。
在另一种可能的实施方式中，监控设备分别检测待检测信息对应的各个服务的异常次数和超时次数。监控设备通过生成待检测信息时开启的协程，分别检测对应服务的异常次数和超时次数。上述报警条件是针对单个服务预先设置的。当任一服务的异常次数大于第一预设次数，和/或，超时次数大于第二预设次数时，监控设备确定待检测信息满足报警条件。
示例性地，待检测信息包括的2个服务的异常次数和超时次数。2个服务分别为：服务A和服务B。服务A和服务B的异常次数分别为：7和8。服务A和服务B的超时次数分别为：15，2。第一预设次数为10次。第二预设次数为12次。那么，监控设备确定服务A的超时次数大于第二预设次数，则确定待检测信息满足报警条件。
在又一种可能的实施方式中，监控设备分别检测待检测信息对应的各个接口的异常次数和超时次数。监控设备通过生成待检测信息时开启的协程，分别检测对应接口的异常次数和超时次数。当任一接口的异常次数大于第一预设次数，和/或，超时次数大于第二预设次数时，监控设备确定待检测信息满足报警条件。
需要说明的是，若分别检测待检测信息对应的各个服务或接口，可以对不同的服务或接口设置不同的报警条件。示例性地，待检测信息包括的2个服务的异常次数和超时次数。2个服务分别为：服务A和服务B。服务A和服务B的异常次数分别为：7和8。服务A和服务B的超时次数分别为：15，2。对于服务A设置的报警条件为：异常次数大于10，超时次数大于15。对于服务B设置的报警条件为：异常次数大于10，超时次数大于5。那么，监控设备确定服务A和服务B都不满足报警条件，无需发出警报。
步骤104，向预先设定的用户终端发送报警信息。
监控设备检测到待检测信息满足报警条件，则说明系统存在安全问题，需要通知用户。因此，监控设备向预先设定的用户终端发送报警信息，以通知用户。报警信息可以用于通知用户发生错误调用。该错误调用是指发生异常或调用超时的调用。因此报警信息包括：错误调用中的服务标识、接口地址、主键信息以及发送报警信息的时间。
可选地，当调用消息中包括子方法配置项时，监控设备可以对子方法的调用进行监控。当调用子方法的异常次数和超时次数满足预设条件时，监控终端向预先设定的用户终端发送报警信息。针对子方法发送的报警信息还包括上述子方法配置项。其中，预设条件可以与上述报警条件相同，也可以不同。
可选地，报警条件、预先设定的用户终端、上述预设阈值和预设条件是由技术人员或用户，预先写入监控设备的配置文件中的。因此，技术人员或用户可以通过对配置文件进行在线编辑来进行修改。相应地，监控设备会读取修改后的配置文件，确定修改后的报警条件、预先设定的用户终端，预设阈值和预设条件。
在本申请实施例提供的方法中，服务设备在服务被调用后，利用MQ这一中间件，将调用消息传输给监控设备。监控设备根据从MQ中读取的调用消息，对服务设备上的服务进行监控，在满足报警条件时，向用户发送报警信息。通过MQ，服务设备能够直接将调用消息传输给监控设备，使得监控设备能够实时地获取调用消息，并进行监控。因此，一旦服务出现异常等安全问题，监控设备能够及时发现并通知用户，提高了系统的安全性。
在本申请中，除了向用户发送报警信息，监控设备还会生日志文件。日志文件包括各个服务被调用的历史记录。用户或其它设备可以根据日志文件查看各个服务被调用的情况。
具体地，日志文件包括多条与各个服务对应的记录信息，每一条记录信息表示对应服务被调用的历史记录。记录信息包括服务名称，接口地址，最大耗时，平均耗时，调用次数，异常次数，报警次数，IP地址和日志更新时间等等。其中，最大耗时是指服务被调用时所耗费的最大时长。平均耗时是指服务每次被调用的平均时长。报警次数，是指该服务触发监控设备发送报警信息的次数。日志更新时间是指该记录信息最近一次被更新的时间。
由于MQ中不断地被服务设备写入新的调用消息，监控设备也会不断地读取调用消息。因此，监控设备需要对日志文件进行更新。每隔预设时间间隔，监控设备根据该预设时间间隔内读取的调用消息，更新日志文件。其中，预设时间间隔可以根据实际经验进行设定，例如5分钟。
可选地，监控设备确定待更新服务。待更新服务是指预设时间间隔内读取的调用消息对应的服务。在预设时间间隔内，只有被调用了的服务所对应的记录信息才需要更新，因此监控设备先确定待更新服务，再根据待更新服务对应的调用消息，更新各个记录信息。具体地，监控设备获取当前预设时间间隔内读取的调用消息。监控设备更新日志文件，实际是更新日志文件中的各个记录信息。对于一条记录信息，监控设备确定该记录信息对应的服务，检测获取的调用消息中是否包括该服务对应的调用消息。若不包括，则监控设备确定无需更新该记录信息。若包括，则监控设备确定需要更新该记录信息。
具体地，对于一条需要更新的记录信息，监控设备确定记录信息对应服务的调用消息的数量，将更新前的调用次数加上该数量，得到更新后的调用次数。对于一条需要更新的记录信息，监控设备根据更新前记录消息中的平均耗时和调用次数，确定更新前的总耗时。再将调用消息中的调用时长之和加上总耗时，得到更新后的总耗时。最后，将更新后的总耗时除以更新后的调用次数，得到更新后的平均耗时。对于一条需要更新的记录信息，监控设备确定调用消息中调用时长的最大值，若该最大值小于或等于更新前的最大耗时，则监控设备确定无需更新最大耗时；若该最大值大于更新前的最大耗时，则监控设备将该最大值作为更新后的最大耗时。对于一条需要更新的记录信息，监控设备将更新前的异常次数加上异常值为1的调用消息的数量，得到更新后的异常次数。
可选地，监控设备将日志文件导入可视化系统，生成可视化图表。例如，Kibana系统。该可视化化图表显示了上述记录信息的各项内容。例如，平均耗时图，异常次数图和超时次数图等等。
需要说明的是，根据用户的需求和实际的应用场景，在记录信息中，除了上述内容外，监控设备还可以记录超时次数、总耗时、更新频率、调用消息的主键信息和子方法信息等等其它与调用相关的信息。其中，更新频率是指监控设备对日志文件的更新频率。子方法信息是指用于表示子方法的调用情况的信息，包括子方法被调用的平均耗时，最大耗时，异常次数，超时次数和调用次数等等。
示例性地，请参考图2，其示出了监控设备监控服务调用并生成日志文件的流程示意图。服务设备201将调用消息写入Rabbit MQ 2021。监控设备202从Rabbit MQ 2021中读取调用消息。在读取后，监控设备202开启各个协程2022，生成待检测信息。监控设备202再检测待检测信息是否满足报警条件，若满足，则向用户终端203发送报警信息。同时，监控设备生成或更新日志文件，并将日志文件导入可视化系统204，得到可视化图表。
下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。
图3是根据一示例性实施例示出的一种微服务架构中的服务监控装置的示意性框图。该装置具有实现上述方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置可以包括：消息读取模块301，信息生成模块302，报警检测模块303和警报发送模块304。
消息读取模块301，用于读取消息队列MQ中的调用消息，所述调用消息用于指示一个服务的一次调用，所述调用消息是在对应的服务被调用后由服务设备写入所述MQ；
信息生成模块302，用于根据第一预设时长内读取的调用消息，生成待检测信息，所述待检测信息包括所述第一预设时长内各个服务的异常次数和超时次数，所述异常次数是指一个服务出现异常的调用次数，所述超时次数是指调用一个服务超时的次数；
报警检测模块303，用于检测所述待检测信息是否满足预先设定的报警条件；
警报发送模块304，用于当所述待检测信息满足所述报警条件时，向预先设定的用户终端发送报警信息。
在本申请实施例提供的装置中，服务设备在服务被调用后，利用MQ这一中间件，将调用消息传输给监控设备。监控设备根据从MQ中读取的调用消息，对服务设备上的服务进行监控，在满足报警条件时，向用户发送报警信息。通过MQ，服务设备能够直接将调用消息传输给监控设备，使得监控设备能够实时地获取调用消息，并进行监控。因此，一旦服务出现异常等安全问题，监控设备能够及时发现并通知用户，提高了系统的安全性。
可选地，所述调用消息包括：调用时长和异常值，所述调用时长是指服务被调用的耗时，所述异常值为0或1。所述信息生成模块302，具体用于：
将所述第一预设时长内，对应于同一服务的调用消息发送至同一信道；开启所述信道对应的协程；通过所述协程在所述对应于同一服务的调用消息中，确定所述调用时长大于预设阈值的调用消息的数量为所述超时次数；通过所述协程在所述对应于同一服务的调用消息中，确定所述异常值为1的调用消息的数量为所述异常次数；根据所述各个服务的所述超时次数和所述异常次数，得到所述待检测信息。
可选地，所述装置还包括：
日志更新模块，用于每隔预设时间间隔，根据所述预设时间间隔内读取的调用消息，更新日志文件，所述日志文件包括各个服务对应的记录信息，所述记录信息用于表示服务被调用的历史记录。
可选地，所述日志更新模块，具体用于：
确定待更新服务，所述待更新服务是指所述预设时间间隔内读取的调用消息对应的服务；
根据所述待更新服务对应的调用消息，更新所述待更新服务对应的记录信息。
可选地，所述报警条件包括：所述异常次数大于第一预设次数，和/或，所述超时次数大于第二预设次数。
在示例性实施例中，还提供了一种计算机可读存储介质，所述存储介质中存储有计算机程序或智能合约，所述计算机程序或智能合约被节点加载并执行以实现上述实施例提供的方法。可选地，上述计算机可读存储介质可以是只读存储记忆体(Read-OnlyMemory，ROM)、随机存储记忆体(Random Access Memory，RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
本领域的技术人员可以清楚地了解到本申请实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。
Claims (8)
1.一种微服务架构中的服务监控方法，其特征在于，所述方法包括：
读取消息队列MQ中的调用消息，所述调用消息用于指示一个服务的一次调用，所述调用消息是在对应的服务被调用后由服务设备写入所述MQ；所述调用消息包括：调用时长和异常值，所述调用时长是指服务被调用的耗时，所述异常值为0或1；若调用没有发生异常，则服务设备将所述调用消息中的异常值置为0；若调用发生异常，则服务设备将所述调用消息中的异常值置为1；
根据第一预设时长内读取的调用消息，生成待检测信息，所述待检测信息包括所述第一预设时长内各个服务以及接口的异常次数和超时次数，所述异常次数是指一个服务以及接口出现异常的调用次数，所述超时次数是指调用一个服务以及接口超时的次数；
检测所述待检测信息是否满足预先设定的报警条件；
若所述待检测信息满足所述报警条件，则向预先设定的用户终端发送报警信息；
其中，所述根据第一预设时长内读取的调用消息，生成待检测信息，包括：
将所述第一预设时长内，对应于同一服务的调用消息发送至同一信道；
开启所述信道对应的协程；
通过所述协程在所述对应于同一服务的调用消息中，确定所述调用时长大于预设阈值的调用消息的数量为所述超时次数；
通过所述协程在所述对应于同一服务的调用消息中，确定所述异常值为1的调用消息的数量为所述异常次数；
根据所述各个服务的所述超时次数和所述异常次数，得到所述待检测信息；
以及，根据调用消息中的服务标识和接口地址确定各个调用消息对应的服务和接口，再将对应于同一服务、同一接口的调用消息发送至同一信道；开启所述信道对应的协程，由所述协程根据信道中的调用消息生成各个接口的待检测信息，所述接口的待检测信息包括了被访问的接口的超时次数和异常次数。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
每隔预设时间间隔，根据所述预设时间间隔内读取的调用消息，更新日志文件，所述日志文件包括各个服务对应的记录信息，所述记录信息用于表示服务被调用的历史记录。
3.根据权利要求2所述的方法，其特征在于，所述根据所述预设时间间隔内读取的调用消息，更新日志文件，包括：
确定待更新服务，所述待更新服务是指所述预设时间间隔内读取的调用消息对应的服务；
根据所述待更新服务对应的调用消息，更新所述待更新服务对应的记录信息。
4.根据权利要求1至3任一项所述的方法，其特征在于，所述报警条件包括：所述异常次数大于第一预设次数，和/或，所述超时次数大于第二预设次数。
5.一种微服务架构中的服务监控装置，其特征在于，所述装置包括：
消息读取模块，用于读取消息队列MQ中的调用消息，所述调用消息用于指示一个服务的一次调用，所述调用消息是在对应的服务被调用后由服务设备写入所述MQ；所述调用消息包括：调用时长和异常值，所述调用时长是指服务被调用的耗时，所述异常值为0或1；若调用没有发生异常，则服务设备将所述调用消息中的异常值置为0；若调用发生异常，则服务设备将所述调用消息中的异常值置为1；
信息生成模块，用于根据第一预设时长内读取的调用消息，生成待检测信息，所述待检测信息包括所述第一预设时长内各个服务以及接口的异常次数和超时次数，所述异常次数是指一个服务以及接口出现异常的调用次数，所述超时次数是指调用一个服务以及接口超时的次数；
报警检测模块，用于检测所述待检测信息是否满足预先设定的报警条件；
警报发送模块，用于当所述待检测信息满足所述报警条件时，向预先设定的用户终端发送报警信息；
其中，所述信息生成模块，具体用于：
将所述第一预设时长内，对应于同一服务的调用消息发送至同一信道；
开启所述信道对应的协程；
通过所述协程在所述对应于同一服务的调用消息中，确定所述调用时长大于预设阈值的调用消息的数量为所述超时次数；
通过所述协程在所述对应于同一服务的调用消息中，确定所述异常值为1的调用消息的数量为所述异常次数；
根据所述各个服务的所述超时次数和所述异常次数，得到所述待检测信息；
以及，根据调用消息中的服务标识和接口地址确定各个调用消息对应的服务和接口，再将对应于同一服务、同一接口的调用消息发送至同一信道；开启所述信道对应的协程，由所述协程根据信道中的调用消息生成各个接口的待检测信息，所述接口的待检测信息包括了被访问的接口的超时次数和异常次数。
6.根据权利要求5所述的装置，其特征在于，所述装置还包括：
日志更新模块，用于每隔预设时间间隔，根据所述预设时间间隔内读取的调用消息，更新日志文件，所述日志文件包括各个服务对应的记录信息，所述记录信息用于表示服务被调用的历史记录。
7.根据权利要求6所述的装置，其特征在于，所述日志更新模块，具体用于：
确定待更新服务，所述待更新服务是指所述预设时间间隔内读取的调用消息对应的服务；
根据所述待更新服务对应的调用消息，更新所述待更新服务对应的记录信息。
8.根据权利要求5至7任一项所述的装置，其特征在于，所述报警条件包括：所述异常次数大于第一预设次数，和/或，所述超时次数大于第二预设次数。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910005322.8A CN109739727B (zh) | 2019-01-03 | 2019-01-03 | 微服务架构中的服务监控方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910005322.8A CN109739727B (zh) | 2019-01-03 | 2019-01-03 | 微服务架构中的服务监控方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109739727A CN109739727A (zh) | 2019-05-10 |
| CN109739727B true CN109739727B (zh) | 2022-07-01 |
Family
ID=66363272
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910005322.8A Active CN109739727B (zh) | 2019-01-03 | 2019-01-03 | 微服务架构中的服务监控方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109739727B (zh) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110297648A (zh) * | 2019-06-12 | 2019-10-01 | 阿里巴巴集团控股有限公司 | 应用自动降级和恢复方法和系统 |
| CN110445636B (zh) * | 2019-07-03 | 2022-03-18 | 平安科技（深圳）有限公司 | 基于管理平台的微服务预警方法、装置和计算机设备 |
| CN110532148B (zh) * | 2019-08-12 | 2022-12-23 | 北京金堤科技有限公司 | 微服务系统的监控方法及装置 |
| CN110727558A (zh) * | 2019-10-09 | 2020-01-24 | 北京字节跳动网络技术有限公司 | 信息提示方法、装置、存储介质及电子设备 |
| CN110990667B (zh) * | 2019-10-29 | 2023-06-23 | 内蒙古大学 | 一种基于协程技术的多端大学生电子档案管理系统 |
| CN112783677A (zh) * | 2019-11-04 | 2021-05-11 | 北京京东尚科信息技术有限公司 | 一种服务异常的监控方法和装置 |
| CN110825792B (zh) * | 2019-11-15 | 2024-06-07 | 珠海市新德汇信息技术有限公司 | 基于golang中间件协程模式下的高并发分布式数据检索方法 |
| CN110888780A (zh) * | 2019-11-19 | 2020-03-17 | 泰康保险集团股份有限公司 | 应用监控方法、装置、设备及存储介质 |
| CN112860504A (zh) * | 2019-11-26 | 2021-05-28 | 北京京东尚科信息技术有限公司 | 监控方法及装置、计算机存储介质、电子设备 |
| CN112039701B (zh) * | 2020-08-27 | 2023-08-15 | 中国平安财产保险股份有限公司 | 接口调用监控方法、装置、设备及存储介质 |
| CN112306989A (zh) * | 2020-10-26 | 2021-02-02 | 北京健康之家科技有限公司 | 数据库实例的处理方法及装置、存储介质、电子装置 |
| CN112559292B (zh) * | 2020-12-18 | 2024-06-21 | 北京北方华创微电子装备有限公司 | 设备应用监控方法、半导体工艺设备 |
| CN115190166A (zh) * | 2021-04-01 | 2022-10-14 | 山东华软金盾软件股份有限公司 | 一种微服务架构下消息传递的方法 |
| CN113238888A (zh) * | 2021-06-02 | 2021-08-10 | 浙江网商银行股份有限公司 | 数据处理方法、系统及装置 |
| CN114915543A (zh) * | 2022-05-07 | 2022-08-16 | 中国农业银行股份有限公司 | 一种消息队列的监控方法及装置 |
| CN115174502A (zh) * | 2022-06-30 | 2022-10-11 | 广东亿迅科技有限公司 | 一种api网关的流量控制方法、装置、设备及介质 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105740376A (zh) * | 2016-01-27 | 2016-07-06 | 北京铭万智达科技有限公司 | 一种微服务中api调用统计和监控的方法 |
| CN106776093A (zh) * | 2016-12-12 | 2017-05-31 | Tcl集团股份有限公司 | 一种应用程序异常日志处理方法及系统 |
| CN107766205A (zh) * | 2017-10-10 | 2018-03-06 | 武汉大学 | 一种面向微服务调用过程跟踪的监控系统及方法 |
| CN108845910A (zh) * | 2018-05-31 | 2018-11-20 | 康键信息技术（深圳）有限公司 | 大规模微服务系统的监控方法、装置及存储介质 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10484382B2 (en) * | 2016-08-31 | 2019-11-19 | Oracle International Corporation | Data management for a multi-tenant identity cloud service |
-
2019
- 2019-01-03 CN CN201910005322.8A patent/CN109739727B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105740376A (zh) * | 2016-01-27 | 2016-07-06 | 北京铭万智达科技有限公司 | 一种微服务中api调用统计和监控的方法 |
| CN106776093A (zh) * | 2016-12-12 | 2017-05-31 | Tcl集团股份有限公司 | 一种应用程序异常日志处理方法及系统 |
| CN107766205A (zh) * | 2017-10-10 | 2018-03-06 | 武汉大学 | 一种面向微服务调用过程跟踪的监控系统及方法 |
| CN108845910A (zh) * | 2018-05-31 | 2018-11-20 | 康键信息技术（深圳）有限公司 | 大规模微服务系统的监控方法、装置及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109739727A (zh) | 2019-05-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109739727B (zh) | 微服务架构中的服务监控方法及装置 | |
| US9645880B2 (en) | Supportability framework for mobile software applications | |
| CN109660426B (zh) | 监控方法及系统、计算机可读介质和电子设备 | |
| JP6160064B2 (ja) | 適用判定プログラム、障害検出装置および適用判定方法 | |
| CN110727560A (zh) | 云服务报警方法及装置 | |
| US11799748B2 (en) | Mitigating failure in request handling | |
| WO2019051948A1 (zh) | 监控数据的处理方法、设备、服务器及存储介质 | |
| CN112039701A (zh) | 接口调用监控方法、装置、设备及存储介质 | |
| WO2016178661A1 (en) | Determining idle testing periods | |
| CN113495820A (zh) | 异常信息收集、处理方法和装置以及异常监控系统 | |
| CN112860504A (zh) | 监控方法及装置、计算机存储介质、电子设备 | |
| CN110727563A (zh) | 预设客户的云服务报警方法及装置 | |
| US10432490B2 (en) | Monitoring single content page application transitions | |
| CN113342608A (zh) | 流式计算引擎任务的监控方法及装置 | |
| CN112306871A (zh) | 数据处理方法、装置、设备及存储介质 | |
| US20040015848A1 (en) | Method of detecting lost objects in a software system | |
| JP2006331026A (ja) | メッセージ分析システム及びメッセージ分析プログラム | |
| CN112783730B (zh) | 一种接口的监测方法、装置、介质及电子设备 | |
| CN112631808B (zh) | 数据同步方法、装置、电子设备和存储介质 | |
| US20100269052A1 (en) | Notifying of an unscheduled system interruption requiring manual intervention and adjusting interruption specifics reactive to user feedback | |
| CN112882892A (zh) | 数据处理方法和装置、电子设备及存储介质 | |
| CN112699015B (zh) | 日志输出方法、装置、服务器及计算机可读存储介质 | |
| CN112835780A (zh) | 一种业务检测方法及装置 | |
| CN113778800B (zh) | 一种报错信息处理方法、装置、系统、设备及存储介质 | |
| CN112671822B (zh) | 服务请求处理方法、装置、存储介质、服务器和系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20231128 Address after: 230012 In the factory building of Anhui Guogou Energy Co., Ltd., 100 meters east of the intersection of Guanjing Road and Luban Road in Xinzhan District, Hefei City, Anhui Province Patentee after: Hefei Youquan Information Technology Co.,Ltd. Address before: 100102 room 323701, building 5, yard 1, Futong East Street, Chaoyang District, Beijing Patentee before: YOUXINPAI (BEIJING) INFORMATION TECHNOLOGY Co.,Ltd. |
|
| TR01 | Transfer of patent right |