全链路服务节点的监控方法、装置和存储介质与流程

本公开总体涉及计算机技术领域，更具体地，涉及一种全链路服务节点的监控方法、装置和存储介质。

背景技术：

随着计算机和互联网技术的蓬勃发展，连带网路购物的盛行，也加速电子商务的崛起。电子商务的业务链路通常包括许多服务节点，且各个服务节点之间具有业务关联。因此，只要是其中一个服务节点发生状况连带也会影响到业务链路上的其他服务节点的运行。

由于服务节点的相关应用程序在运行时都会产生日志数据，也就是记录资讯系统产生的过程性事件记录数据。通过日志数据可以得知服务节点的相关应用程序运行状况。但是后台系统只会針对个别应用程序进行采集，导致无法对同一业务链路所运行的各个应用程序的日志数据进行分析，以至于无法预先得知其它服务节点的应用程序可能发生的问题。

技术实现要素：

为了至少解决在上述背景技术所描述的现有技术缺陷，本公开的技术方案在多个方面提供了一种全链路服务节点的监控方法、装置和存储介质。

根据本公开的第一方面，提供一种全链路服务节点的监控方法，其中所述全链路上有多个服务节点，每个服务节点对应多个监控指标信息，所述方法包括：接收所述多个监控指标信息；分析所述多个监控指标信息；当所述多个监控指标信息之一为异常状态时，获取所述监控指标信息所对应的关联节点，所述关联节点为所述多个服务节点至少其中之一；以及根据所述监控指标信息调整所述关联节点的系统状态。

根据本公开的一个实施例，所述监控指标信息包括当前系统的中央处理器状态信息、磁盘状态信息以及内存状态信息中的至少一种。

根据本公开的另一个实施例，所述分析所述多个监控数据信息的步骤，包括：判断所述各个监控数据信息是否大于或等于所对应的阈值；以及如是，发出警告信息。

根据本公开的又一个实施例，所述多个关联节点具有至少一相同的所述多个监控指标信息。

根据本公开的一个实施例，还包括：在第一时间点存储所述多个服务节点及其对应的所述多个监控指标信息为第一日志数据；在第二时间点存储所述多个服务节点及其对应的所述多个监控指标信息为第二日志数据；比较所述第一日志数据及所述第二日志数据，输出趋势监控数据；以及根据所述趋势监控数据调整有异常的所述监控指标信息所对应的系统状态。

根据本公开的另一个实施例，所述第一时间点及所述第二时间点是在不同时间区间的同一时间点，其中所述时间区间是日、月及年其中之一。

根据本公开的第二方面，提供一种全链路服务节点的监控装置，其中所述全链路上有多个服务节点，所述各个服务节点对应多个监控指标信息，所述系统包括：接收模块，用于接收所述各个服务节点对应的多个监控指标信息；分析模块，用于分析所述多个监控数据信息；获取模块，用于当所述服务节点的所述多个监控指标信息之一为异常状态时，获取所述监控指标信息所对应的多个关联节点，所述多个关联节点为所述多个服务节点其中之多个；以及调整模块，用于根据所述监控指标信息调整所对应的系统状态。

根据本公开的一个实施例，所述装置还包括：判断模块，用于判断所述各个监控数据信息是否大于所对应的阈值，如是，发出警告信息。

根据本公开的另一个实施例，所述装置还包括：存储模块，用于在第一时间点存储所述多个服务节点及其对应的所述多个监控数据信息为第一日志数据，以及在第二时间点存储所述多个服务节点及其对应的所述多个监控数据信息为第二日志数据；以及比较模块，用于比较所述第一日志数据及所述第二日志数据，输出趋势监控数据。

根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序指令，该指令被一个或者多个处理器执行实现本公开的第一方面中任意一项所述方法的操作。

通过上述对本公开的技术方案及其多个实施例的描述，本领域技术人员可以理解本公开的全链路服务节点的监控方法可以监测各个服务节点的运行状态，如某服务节点的监控指标出现波动，除了抽取该服务节点数据，并且还会调取链路上其他服务节点的日志数据以达到于故障排解或预判的目的。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，并且相同或对应的标号表示相同或对应的部分，其中：

图1是示出根据本公开实施例的系统框架；

图2(a)至(d)是示出根据本公开实施例的监控指标波形图；

图3是示出根据本公开实施例的全链路服务节点的监控方法流程图；

图4(a)及(b)是示出根据本公开实施例的同比趋势监控数据波形图；

图4(c)是示出根据本公开另一实施例的环比趋势监控数据柱状图；

图5是示出根据本公开另一实施例的全链路服务节点的监控方法流程图；

图6是示出根据本公开实施例的全链路服务节点的监控装置图；以及

图7是示出根据本公开的实施方式的一种程序产品。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

应当理解，本公开的权利要求、说明书及附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。本公开的说明书和权利要求书中使用的术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本公开说明书中所使用的术语仅仅是出于描述特定实施例的目的，而并不意在限定本公开。如在本公开说明书和权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。还应当进一步理解，在本公开说明书和权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

本公开针对现有技术只对单一服务节点所对应的应用程序作为错误侦测对象的不足，提供了一种全链路服务节点的监控方法，可以监测各个服务节点的运行状态，例如某服务节点的监控指标出现波动，除了抽取该服务节点数据，并且还会调取链路上其他服务节点的日志数据以达到整体故障排解或预判的目的。此外，根据波动区间变化，抽调不同历史时间的日志数据进行环比和同比，进行综合分析后，形成趋势监控数据，可进一步用于资源扩容或故障预判，有益于增加系统的稳定性。

下面结合附图来详细描述本公开的具体实施方式。

图1示出了根据本公开实施例的系统框架图。如图1所示，本实施例的系统架构100包括电子终端101，服务器102、网络103和入口端104。电子终端101可以为手机、平板电脑、电子阅读器等移动终端，但并不限于此，还可以是其他终端。用户可以使用电子终端101通过网络103与服务器104进行数据传输。电子终端101上可以安装各种应用程序，例如：网页浏览器、搜索引擎、商城、书城、即时通信等应用程序。

服务器102作为传递介质，可以通过网络103提供数据处理、存储、传输以及管理用户数据等等功能，例如：当用户通过电子终端101浏览的网站时，服务器102可以作为提供支持的后台管理服务器。该后台管理服务器可以对接收到的用户请求等数据进行汇整、分析等处理，并将处理结果(例如：根据用户请求获取或生成的网页、信息、或数据等)反馈给电子终端101。

网络103是作为电子终端101、服务器102和入口端104之间提供通信链接的传输通道。网络103可以包括有线网、光纤网或无线网等链接类型。

入口端104是对应电子终端101安装的多个应用程序的入口选项114、124……1n4(n＝正整数)，例如：搜索引擎入口、商城入口……等。

具体来说，本公开实施例所提供的全链路服务节点的监控方法一般可以由服务器102执行。在一个实施场景中，本公开实施例所提供的方法也可以通过能与电子终端101和/或服务器102通信的服务器或服务器集群执行。例如：用户浏览记录可以直接被存储在电子终端101之中，电子终端101再将用户浏览记录发送到服务器或者服务器集群中，并且由接收到该浏览记录的服务器或者服务器集群来执行本公开实施例所提供的全链路服务节点的监控方法。或者，用户浏览记录也可以存储在服务器或者服务器集群中，并且在该服务器或者服务器集群接收到错误信息后，根据存储的相应的用户浏览记录以执行本公开实施例所提供的全链路服务节点的监控方法。

应该理解的是图1中的电子终端、服务器、网络和入口的数目仅仅是示意性的。根据实际应用场景的需求，可以具有任意数目的电子终端、网络和服务器。

下面结合图1的系统架构，参考图3来描述根据本公开示例性实施方式的全链路服务节点的监控方法。需要注意的是，上述系统架构仅是为了便于理解本公开的实施方案的其中之一实施示例而非限制性的，相反地，本公开的实施方式可以应用于任何适用的系统架构。

全链路中的服务节点包括有：网络负载均衡服务器(serverloadbalancing，以下简称slb)，web服务节点如：nginx前端机、书架(bookshelf)、充值消费服务(consume)、注册服务(register)、站内信服务(message)、查询搜索的接口(business)、以及远程字典服务(remotedictionaryserver，以下简称redis)缓存数据库、mysql数据库等。其中redis缓存是一种结构化数据库，提供的是缓存服务，以降低mysql数据库的查询压力

不同性质的服务节点需要有不同的监控指标进行监测，例如：consume、register、message、business等这些都是提供web服务的服务节点，所以监控指标大致相同，包括有：中央处理器(以下简称cpu)使用率、磁盘使用率、内存使用率、系统负载、及端口的存活性等等。又比如redis这类缓存数据库，监控的指标则包括有：服务存活性、内存使用率、连接数、缓存命中率及每秒查询量(queriespersecond，以下简称qps)等等。qps是指一台服务器每秒能够查询的次数，是对一个特定的查询服务器在规定时间内所处理查询量多少的衡量标准，在互联网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

此外，如mysql这类提供数据存储、查询等功能的数据库管理系统，监控的指标包括有：服务存活性、cpu、内存使用率、连接数、qps、连接数及主从延迟等等。本公开实施例是利用mysql数据库来运行监控指标，其它可利用的还有如sqlserver、postgresql等关系型数据库。

根据上述可知，不同业务关系的服务节点多数对应不同的监控指标，进一步，针对各个监控指标的差异预先定义多个警示级别，并且针对不同监控指标还设置有对应警示级别的阈值。换句话说，如监测到监控指标一旦超过预设阈值时，即发布对应该阈值的警示级别的通知。

下表1以警告和严重2个警示级别作说明，“警告”级别可以由值班人员自行处理，便可以解除警示并恢复至正常运行状态。“严重”级别的警示造成的影响较大，需要通知到相关负责人。特别一提的是，相同的服务节点由于业务线不同，监控的阈值也会有所不同。表1的阈值仅提供参考，可以由本领域人员灵活设置，本公开对此不作限定。

如表1所示，本公开包括的监控指标有:cpu利用率、磁盘空间使用率、内存使用率、mysql_qps、iops(input/outputoperationspersecond)使用率及连接数使用率。同时参照图2(a)至(d)为监控指标的波形示意图。

表1监控指标定义表

首先，在此实施例中，监控指标的统计周期设定为每60秒监测一次，也可以设定1分钟、5分钟、或10分钟。

监控指标为cpu使用率时，当监测cpu使用率出现5次平均值大于或等于40％时，发出“警告”级别报警信息并通知值班人员处理。如图2(a)示出cpu使用率的监控波形示意图，横轴显示时间，纵轴显示的是cpu使用率。示例性的在21:30分时cpu使用率(cpuusage)为40.56％，且之后连续超过5次平均值大于40％(图2(a)中报警线位于40.00％)，属于“警告”级别报警信息，系统将通知到相关负责人。其中监测的平均值次数弹性地由本技术领域人员依实际需求做设置。

当监控指标为磁盘空间使用率时，如图2(b)示出磁盘空间使用率的监控波形示意图，横轴显示时间，纵轴显示的是磁盘空间使用率。示例性的在23:56分时磁盘空间使用率(diskusage)为60.15％，且之后连续5次平均值大于60％(图2(b)中报警线位于60.00％)，因此发出“警告”级别报警信息并通知值班人员处理。如再出现5次平均值大于80％时，则属于“严重”级别报警信息，将通知到相关负责人。

当监控指标为内存使用率时，如图2(c)示出内存使用率的监控波形示意图，横轴显示时间，纵轴显示的是内存使用率。示例性的在11:30分磁盘空间使用率(memory_usedutilization)为62.66％，且之后连续5次平均值大于60％(图2(c)中报警线位于60.00％)，故发出“警告”级别报警信息并通知值班人员处理。在另一种情境下，当连续出现5次平均值大于80％时，属于“严重”级别报警信息时，将通知到相关负责人。

当监控指标为mysql_qps时，如图2(d)示出mysql_qps的监控波形示意图，横轴显示时间，纵轴显示的是mysql_qps每秒钟的查询量。示例性的在11:08分mysql_qps为2620秒/次，且之后连续5次平均值大于1600(图2(d)中报警线位于1.60k)，故发出“警告”级别报警信息并通知值班人员处理。在另一种情境下，当出现5次平均值大于2800时，属于“严重”级别报警信息，将通知到相关负责人。

iops是一个用于计算机存储设备(如硬盘(hdd)、固态硬盘(ssd)或存储区域网络(san))性能测试的量测方式，简言之，可以视为是每秒的读写次数。当监控指标为iops使用率时，如果监测iops使用率出现5次平均值大于或等于70％的，则发出“警告”级别报警信息并通知值班人员处理。或是连续超过5次平均值大于或等于80％时，属于“严重”级别报警信息时，将通知到相关负责人。

连接数是指与服务器建立的tcp连接数，换句话说，指的是客户端向服务器发起请求，并建立了tcp(transmissioncontrolprotocol传输控制协议)连接。也是每秒钟服务器链接的总tcp数量，tcp连接数量越大，尝试成功可能性越大。当监控指标为连接数使用率时，如果监测连接数使用率出现5次平均值大于或等于50％的，会发出“警告”级别报警信息并通知值班人员处理。或是连续超过5次平均值大于或等于60％时，属于“严重”级别报警信息时，将通知到相关负责人。

图3示出全链路服务节点的监控方法，其中所述全链路上有多个服务节点，每个服务节点对应多个监控指标信息。具体来说，全链路中的服务节点包括有：网络负载均衡服务器(serverloadbalancing，slb)、web服务节点如：nginx前端机、书架(bookshelf)，充值消费服务(consume)、注册服务(register)、站内信服务(message)、查询搜索的接口(business)、以及redis(remotedictionaryserver)缓存数据库、mysql数据库等。

该方法300包括多个下列步骤。

在步骤301中，接收多个监控指标信息，其中监控指标信息包括当前系统的cpu状态信息、磁盘状态信息以及内存状态信息中的至少一种。可选地，前述状态信息可以是指使用率，例如cpu使用率、磁盘使用率、内存使用率。

在步骤302中，分析多个监控指标信息，分析步骤包括：判断所述各个监控数据信息是否大于或等于所对应的阈值；如是，发出警告信息。

具体地，针对各个监控指标的差异预先定义多个警示级别，并且针对不同监控指标都设置有对应警示级别的阈值，特别一提的是，相同的服务节点由于业务线不同，监控的阈值也会有所不同。进一步来说，如监测到监控指标一旦超过预设阈值时，即发布对应该阈值的警示级别的通知。有关各个监控指标的阈值设置及对应的警示级别已在上表1及图2(a)至(d)中作说明，在此不再赘述。

在步骤303中，当多个监控指标信息之一为异常状态时，获取监控指标信息所对应的关联节点，关联节点为多个服务节点至少其中之一。举例来说，不同性质的服务节点需要有不同的监控指标进行监测，例如：consume、register、message、business等这些都是提供web服务的服务节点，所以监控指标大致相同，包括有：cpu使用率、磁盘使用率、内存使用率、系统负载、及端口的存活性等等。上述具有同样监控指标的服务节点都在同一业务链路上，并且具有相同的监控指标，consume、register、message、business属于关联节点。当这些关联节点中有任一发生异常状态就会影响到同一业务链路上的其它关联节点，其中异常状态是指监控指标大于或等于预先设置的阈值时，方法300会立即查看其它具有与发生异常状态相同的监控指标的关联节点。

在步骤304中，根据监控指标信息调整关联节点的系统状态。具体地，通过监测监控指标信息除了可以针对已发生异常的服务节点进行维修，例如增加硬体设备以减轻系统负担，再者还可以对同一业务链路上的其它关联节点进行预防式维护，以避免有异常状况发生。

在一个实施场景中，本公开还可以根据波动区间变化，抽调不同历史时间的资源数据进行环比和同比，经过综合分析后，形成趋势监控数据，用于资源扩容或故障预判。具体来说，同比是指历史同期数据进行比较，例如今天的8点和昨天的8点的变化比；环比则表示连续2个统计周期(例如连续两个小时，每一个小时为一个周期)内的量的变化比。示例性列举同比增长率及环比增长率的公式如下。

同比增长率＝(本期数-同期数)/同期数×100％

环比增长率＝(本期数-上期数)/上期数×100％

增长率反映本期比上期增长了多少，一般是指报告期水平与前一时期水平之比，表示特定时期的发展速度。

图4(a)(b)示出本公开实施例的同比趋势监控数据波形图。图4(a)示出连续两天在11点至12点之间的mysql_qps波形图，横轴显示时间，纵轴显示的是mysql_qps每秒钟的查询量。由图中可见，mysql.dps(date1)和mysql.dps(date2)的两组曲线在波动区间变化极为相近且多数趋近重叠。举例来说，在时间11:24时进行监测，测出的mysql.dps(date1)是708.9，mysql.dps(date2)是677.4，同比增长率＝(708.9-677.4)/677.4×100％＝4.6％，同比增长率极低，表示在这两天内并无明显变化。

图4(b)示出连续两周的同一日在0点至24点之间的通过微信支付成功数量的波形图，横轴显示时间，纵轴显示的是“通过微信支付成功数量”(以下简称“数量”)。举例来说，如监控日设定为连续两周中的星期一时，第一周的星期一设定为day1，第二周的星期一设定为day2....，在另一个实时场景中，监测时间不限定是连续两周的星期一，可依当前状况进行调整。

由图中可见，day2的曲线随着day1的曲线有稳定成长的趋势，具体来说，当监测时间在2：00的day1数量是700，day2数量是800，同比增长率为(800-700)/700×100％＝14.3％；又比如监测时间在10：00的day1数量是700，day2数量是850，同比增长率为(850-700)/700×100％＝21.4％，比较时间在2:00与10：00时的day1和day2的同比增长率差距不大。但时间在20:00时的day1数量是900，day2数量是1250，同比增长率为(1250-900)/900×100％＝38.9％，相比之下，显示“通过微信支付成功数量”在day2相较于day1的同比增长率有明显的增加，特别是在时间20:00的时段时增加较多。推测在时间20:00时的cpu使用率或磁盘使用率将仍会持续提高，因此可以预先进行相关设备的扩充，特别是在20:00的时段要密切追踪是否有持续快速地增加。

图4(c)示出本公开另一实施例的环比趋势监控数据柱状图。图4(c)示出在0点至24点之间的通过微信支付成功数量的柱状图，横轴显示时间，纵轴显示的是“通过微信支付成功数量”(以下简称“数量”)。

由图中可见，以每两个小时为一个周期，连续监控两个周期，当监测周期在2：00至4:00时间区间(以下简称“周期1”)的数量是800，在4：00至6:00时间区间(以下简称“周期2”)的数量是600，环比增长率为(600-800)/800×100％＝-25％，显示周期1至周期2为负成长；又比如监测时间在16：00至18:00时间区间(以下简称“周期3”)的数量是1100，在18：00至20:00时间区间(以下简称“周期4”)的数量是1300，环比增长率为(1300-1100)/1100×100％＝18.2％，显示为显示周期3至周期4为正成长。当以两周期为一组，进一步比较两组周期1和2以及周期3和4，通过监测cpu使用率或磁盘使用率是降低或者持续提高，可以预先进行相关设备的减少或扩充。

在另一个实施场景中，本公开又提供另一全链路服务节点的监控方法500，如图5所示，该方法500包括下列步骤。

在步骤501中，在第一时间点存储所述多个服务节点及其对应的所述多个监控指标信息为第一日志数据。示例性地，第一时间点是指特定时间，可以是指特定小时或某一天，第一日志数据是纪录服务节点产生的任何事件，监控指标信息包括但不限为cpu使用率、磁盘使用率及内存使用率等，可以由本领域技术人员灵活设置，本公开对此不作限定。

在步骤502中，在第二时间点存储所述多个服务节点及其对应的多个监控指标信息为第二日志数据。示例性地，第二时间点是指特定时间，可以是指特定小时或某一天，其中第一时间点及所述第二时间点是在不同时间区间的同一时间点，其中所述时间区间是日、月及年其中之一。第二日志数据是纪录服务节点产生的任何事件，因此存储的多个监控指标信息不限为cpu使用率、磁盘使用率及内存使用率等，可以由本领域技术人员灵活设置，本公开对此不作限定。

在步骤503中，比较第一日志数据及第二日志数据，输出趋势监控数据。具体地，通过将第一日志数据及第二日志数据中的任一监控指标信息进行比较可以产生对应的趋势监控数据，图4(a)及(b)的同比趋势监控数据波形图分别显示的是其中之一组监控指标信息的比较，在此不作赘述。

在步骤504中，根据趋势监控数据调整有异常的所述监控指标信息所对应的系统状态。调整方式如图4(a)及(b)中进行说明，在此不作赘述。

本公开在又一个场景中还提供一种全链路服务节点的监控装置，其中所述全链路上有多个服务节点，各个服务节点对应多个监控指标信息，如图6所示，该监控装置包括：接收模块601、分析模块602、获取模块603、调整模块604、判断模块605。其中接收模块601接收各个服务节点对应的多个监控指标信息，其中监控指标信息包括当前系统的cpu状态信息、磁盘状态信息以及内存状态信息中的至少一种。可选地，前述状态信息可以是指使用率，例如cpu使用率、磁盘使用率、内存使用率。通过分析模块602分析多个监控数据信息，当所述服务节点的所述多个监控指标信息之一为异常状态时，由该获取模块603获取所述监控指标信息所对应的多个关联节点，其中多个关联节点为所述多个服务节点其中之多个。调整模块604将根据监控指标信息调整所对应的系统状态，通过监测监控指标信息除了可以针对已发生异常的服务节点进行维修，例如增加硬体设备以减轻系统负担，再者还可以对同一业务链路上的其它关联节点进行预防式维护。

进一步，该监控装置还包括判断模块605、存储模块606及比较模块607。判断模块605判断各个监控数据信息是否大于所对应的阈值，如是，发出警告信息。存储模块606在第一时间点存储所述多个服务节点及其对应的所述多个监控数据信息为第一日志数据，以及在第二时间点存储所述多个服务节点及其对应的所述多个监控数据信息为第二日志数据，通过比较模块607比较第一日志数据及第二日志数据，以输出趋势监控数据如图4(a)及(b)所示的同比趋势监控数据波形图。

在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序代码在被处理器执行时，所述程序代码用于使所述处理器执行上面描述的方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。

如图7所示，示出了根据本公开的实施方式的一种程序产品3，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者可以连接到外部计算设备(例如利用互联网服务提供商来通过互联网连接)。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

应该注意的是，上述实施例对本公开进行说明而不是对本公开进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。

本公开基于前述实施例可以解决现有技术只对单一服务节点所对应的应用程序作为错误侦测对象的不足，提供了一种全链路服务节点的监控方法可以监测各个服务节点的运行状态，如某服务节点的监控指标出现波动，除了抽取该服务节点数据，并且还会调取链路上其他服务节点的日志数据以达到于故障排解或预判的目的。此外，根据波动区间变化，抽调不同历史时间的日志数据进行环比和同比，进行综合分析后，形成趋势监控数据，可进一步用于资源扩容或故障预判，有益于增加系统的稳定性。