CN111934793B - 一种互联网架构全链路监控方法及装置 - Google Patents

Abstract

本发明属于信息安全技术领域，本发明提供了一种互联网架构全链路监控方法及装置，互联网架构全链路监控方法包括：响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息；根据所述各个节点所需要的时间信息生成网络拓扑图；根据所述网络拓扑图监控互联网架构。本发明提供的互联网架构全链路监控方法及装置，通过结合全链路监控技术，有效解决了异构应用的高可用性检测的问题，并对应用透明，无需大量修改代码。

Description

一种互联网架构全链路监控方法及装置

技术领域

本发明涉及计算机技术领域，尤其是涉及计算机软件运维技术领域，具体涉及一种互联网架构全链路监控方法及装置。

背景技术

目前面对互联网应用的高并发量，高性能，高可用的急切需求，爆发式的客户量和业务的复杂性导致系统越来越复杂，如秒杀网购，纪念币预定等愈加常态化的海量的瞬间访问量等复杂场景，导致生产故障频频发生，运维人员疲于应急分析解决问题，运维压力与日俱增，给传统的运维方式带来了前所未有的冲击。而将生产隐患消灭于发生之前，“治未病”才是解决系统高可用性的关键。而如何快速准确识别系统的薄弱点正是解决该问题的关键点。

另外，现有技术中缺少将系统的生态情况实时和高可用监控相结合的系统。监控系统聚合分析和事中故障定位能力不足：当前的监控侧重单个调用链路的性能表现和事后分析和调优，缺少对链路数据的聚合分析，支持事中快速对故障进行定位。缺乏有效的可视化分析视图：互联网节点部署规模庞大，其间涉及众多各类监控专业系统，监控数据目前还比较分散，排查问题常常要涉及到多个系统，缺乏统一的可视化分析视图，并且问题定位手段单一。

发明内容

本发明属于信息安全技术领域，针对现有技术中的问题，本发明提供的互联网架构全链路监控方法及装置，通过结合全链路监控技术，有效解决了异构应用的高可用性检测的问题，并对应用透明，无需大量修改代码。

为解决上述技术问题，本发明提供以下技术方案：

第一方面，本发明提供一种互联网架构全链路监控方法，包括：

响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息；

根据所述各个节点所需要的时间信息生成网络拓扑图；

根据所述网络拓扑图监控互联网架构。

一实施例中，所述各个节点所需要的时间信息包括：客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

一实施例中，所述响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息信息，包括：

利用生产者消费者模式，基于所述数据请求以及kafka建立消息队列，所述消息队列格式为json；

根据所述消息队列确定跟踪节点ID、父节点ID以及子节点ID；

根据所述跟踪节点ID、所述父节点ID以及所述子节点ID描述所述客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

一实施例中，所述根据所述各个节点所需要的时间信息生成网络拓扑图包括：

利用聚合分析方法以及Neo4j图数据库，根据所述各个节点所需要的时间信息生成网络拓扑图。

第二方面，本发明提供一种互联网架构全链路监控装置，包括：

时间采集单元，用于响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息；

拓扑图生成单元，用于根据所述各个节点所需要的时间信息生成网络拓扑图；

监控单元，用于根据所述网络拓扑图监控互联网架构。

一实施例中，所述各个节点所需要的时间信息包括：客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

一实施例中，所述时间采集单元包括：

消息队列建立模块，用于利用生产者消费者模式，基于所述数据请求以及kafka建立消息队列，所述消息队列格式为json；

节点ID确定模块，用于根据所述消息队列确定跟踪节点ID、父节点ID以及子节点ID；

时间描述模块，用于根据所述跟踪节点ID、所述父节点ID以及所述子节点ID描述所述客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

一实施例中，所述拓扑图生成单元具体用于利用聚合分析方法以及Neo4j图数据库，根据所述各个节点所需要的时间信息生成网络拓扑图。

第三方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现互联网架构全链路监控方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现互联网架构全链路监控方法的步骤。

从上述描述可知，本发明实施例提供的互联网架构全链路监控方法及装置，首先响应于客户的数据请求，接着，采集数据请求经历的各个节点所需要的时间；最后根据各个节点所需要的时间生成网络拓扑图；本发明在不侵入系统的基础上，有效解决了异构应用的高可用性检测的问题。

附图说明

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

图1为本发明的实施例中互联网架构全链路监控方法流程示意图；

图2为本发明的实施例中步骤100的流程示意图；

图3为本发明的实施例中步骤200的流程示意图；

图4为本发明的具体应用实例中互联网架构全链路监控系统的结构示意图；

图5为本发明的具体应用实例中互联网架构全链路监控系统的模块化示意图；

图6为本发明的具体应用实例中互联网架构全链路监控方法的流程示意图；

图7为本发明的实施例中互联网架构全链路监控装置的结构框图；

图8为本发明的实施例中时间采集单元的结构框图；

图9为本发明的实施例中的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本发明的实施例提供一种互联网架构全链路监控方法的具体实施方式，参见图1，该方法具体包括如下内容：

步骤100：响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息。

具体地，客户发起数据请求，服务器接收请求后，发起调用(如果该服务器下设子系统时，向子系统发起调用)，最后返回给客户，每次调用采集的信息都反馈给收集器，通过节点成对的计算，调用关系最终形成一棵调用树，在每次调用发送时，对调用耗时进行统计。可以理解的是，步骤100可以发现耗时多的节点，对于单独的节点或单点的路径，可提示监管人员其不符合高可用标准。

步骤200：根据所述各个节点所需要的时间信息生成网络拓扑图。

可以理解的是，步骤200中的网络拓扑图是指由网络节点设备和通信介质(含设备的通信耗时)构成的网络结构图。这里的节点可以是网络单元(网络单元是网络系统中的各种数据处理设备、数据通信控制设备和数据终端设备)。根据步骤200中所生成的网络拓扑图可以识别单节点，耗时长的路径和节点，吞吐量骤降等高可用问题，进而实现高可用架构检测和优化。

步骤300：根据所述网络拓扑图监控互联网架构。

通过预设的阈值与监控网络拓扑图中每个节点以及每个路径的耗时进行对比，当发现实际耗时不在预设的阈值范围内时，发出报警至运维人员，具体地，可以选择基准报警阀值，也可以自定义不同应用的报警阀值。根据系统特点设置灵活的阀值，如果请求返回时间超过阀值，就会报警。对系统单点预警，多链路超阀值报警，SQL语句处理慢报警，网络流量剧增等高可用报警进行多等级的高可用报警。同样地，报警按照紧急重要，紧急不重要，重要不紧急，不重要不紧急四个级别定义。可以手动调整升级或者降级。当然也可以通过颜色来区分预警级别。

从上述描述可知，本发明实施例提供的互联网架构全链路监控方法，首先响应于客户的数据请求，接着，采集数据请求经历的各个节点所需要的时间；最后根据各个节点所需要的时间生成网络拓扑图；本发明在不侵入系统的基础上，有效解决了异构应用的高可用性检测的问题。具体地，通过结合全链路监控，多级预警和智能优化，以及较高的可扩展性(架构高可用自动检测优化的基础是对系统的访问链路的清晰实时认识)。本系统底层基于全链路跟踪监控，自动绘制出网络拓扑图，一目了然发现耗时多的节点，标注为可疑节点，实时监控系统的各个节点性能，及时发现系统的性能瓶颈。横向上实现交易全链路跟踪，跨应用框架、跨多语言体系，纵向上实现常用组件的跟踪扩展。

一实施例中，所述各个节点所需要的时间信息包括：客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

一实施例中，参见图2，步骤100进一步包括：

步骤101：利用生产者消费者模式，基于所述数据请求以及kafka建立消息队列；

具体地，消息队列格式为json使用生产者消费者模式，基于数据请求以及kafka建立消息队列，通过继承基类RequestProducer可以产生不同的类型请求。另外，可以理解的是，Kafka是一个开源流处理平台，由Scala语言和Java语言编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。这种动作(网页浏览，搜索和其他客户的行动)是在网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。Kafka的作用是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

步骤102：根据所述消息队列确定跟踪节点ID、父节点ID以及子节点ID。

步骤103：根据所述跟踪节点ID、所述父节点ID以及所述子节点ID描述所述客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

在步骤102以及步骤103中，一份消息通过消息队列kafka的partition分区的特性根据request ID(trace ID)进行分类管理，request ID作为键值，根据放入高速缓存redis中，以提高计算能力，根据父节点parent ID来计算请求链路的关系，记录客户端发送消息时间戳，服务器端接收端时间戳，服务器端发送时间戳，客户端接收时间。

一实施例中，参见图3，步骤200进一步包括：

步骤201：利用聚合分析方法以及Neo4j图数据库，根据所述各个节点所需要的时间信息生成网络拓扑图。

可以理解的是，图数据库Neo4j有很容易表示连接的数据，检索、遍历、导航大量的连接数据非常容易和快速特点。因此将收集的数据，按照节点和关系(边)存入图数据库，无需转化就可以直接提取，快速成为网状拓扑结构。方便json格式的数据导出。节点：包含属性。(属性可以使用json的嵌套模型，关系(边)：包含开始节点、结束节点及属性。Neo4j的关系具有方向性。

另外，这里的聚合分析是数据库中重要的功能特性，是指完成对一个查询的数据集中数据的聚合计算，如：找出某字段(或计算表达式的结果)的最大值、最小值，计算和、平均值等。

本发明实施例所提供的互联网架构全链路监控方法，结合黑盒和标注两种方式收集请求信息，“一数两用”，一份数据快速构建单链路，一份数据通过聚合分析计算，分析关键路径，自动绘制出网络拓扑图，发现耗时多的节点，标注为可疑节点，对于单点的节点，提示不符合高可用标准。根据上述信息，分析得到具体交易性能基准指标，为实际性能测试和生产资源配置提供重要参考。

为进一步地说明本方案，本发明提供互联网架构全链路监控方法的具体应用实例，具体包括如下内容。

本具体应用实例中的全链路监控基本思路：客户发起请求，服务器A接收请求后，再向子系统发起调用，最后返回给客户，每次调用采集的信息都反馈给收集器，通过节点成对的计算，调用关系最终形成一棵调用树，在每次调用发送时，对调用耗时进行统计。

本具体应用实例中的全链路监控核心：跟踪id和父子id、植入点、定制化日志、采样率、跟踪信息的收集和查询。根据递归算法快速计算依赖关系dependence，根据不同的系统采用灵活的采样率。

参见图4，本具体应用实例还提供一种互联网架构全链路监控系统，包括数据采集层、数据处理层以及展示层，其中采集数据层负责请求追踪收集，数据处理层的作用是追踪信息加工以及全链路组合分析，展示层负责全链路自动绘制、多级别高可用报警以及高可用优化。

参见图5，从模块化的角度来说，互联网架构全链路监控系统又包括请求追踪收集模块、追踪信息加工模块、链路聚合分析模块、全链路自动绘制模块、多等级高可用报警模块以及高可用优化模块，其中：

请求追踪收集模块：使用生产者消费者模式，基于kafka建立消息队列，基类RequestProducer，通过继承该基类可以产生不同的类型请求，装饰器设计模式实现消息加工，对每一跳的结果进行描述，为架构生成信息。

追踪信息加工模块：请求信息完成收集标记后出队，然后被类RequestConsumer消费。追踪消息克隆一份，实现“一数两用”。由两套消息队列kafka处理，一份数据用来快速计算单个链路的路径消耗时间，简单的计算保证高效实时性。另一份数据结合配置管理系统cmdb，对日志的高级解析用于计算聚合路径，从集群、服务、应用层面识别系统高可用性。这份数据由链路聚合分析模块处理。

链路聚合分析模块：基于定制化日志解析、配置管理系统cmdb两者相结合，手动输入服务器信息补充的方式实现聚合分析链路。

全链路自动绘制模块：基于链路聚合分析模块对追踪信息的二次加工，结合配置管理系统cmdb，日志分析聚合分析链路的信息，通过自动绘制拓扑图从应用、集群、节点、服务等视角，整合指标、日志、链路等信息，逐层下钻，提供面向生产问题分析的可视化统一界面，一目了然的呈现，与其相关的系统可以迅速作出反应。

多等级高可用报警模块：首先该模块具有灵活的预警阀值功能：运维人员可以选择基准报警阀值，也可以自定义不同应用的报警阀值。根据系统特点设置灵活的阀值，如果请求返回时间超过阀值，就会报警。

其次，该模块还具有多等级的高可用报警功能：对系统单点预警，多链路超阀值报警，SQL语句处理慢，网络流量剧增等高可用报警进行多等级的高可用报警。报警按照紧急重要，紧急不重要，重要不紧急，不重要不紧急四个级别定义。可以手动调整升级或者降级。优选地，紧急重要采用红色预警表示，紧急不重要采用橙色，重要不紧急采用黄色，不重要不紧急采用蓝色。

高可用优化模块。该模块具有灵活便捷的诊断能力，具体地，建立在线实时诊断平台，提供的线程检测、jvm检测、方法和跟踪等联机分析能力，包装成Web功能集成值全息监控平台，提供给开发人员在线使用。

参见图6，本具体应用实例所提供的互联网架构全链路监控方法具体包括如下内容。

步骤S1：采集数据请求经历的各个节点所需要的时间。

具体地，在前台采集数据时，首先，在http请求前增加trace开始标记，在http请求实际时往header中添加header信息。请求回来后，增加trace结束标记，用意计算本次网络调用耗时。js中增加一个定时任务，定期将trace数据发往后台跟踪接口。采集的数据频率为每5分钟，如果延迟时间不到阀值的80％，不采集定制化的日志，减少数据传输量，减轻系统压力。网络设备可以自行通过协议采集访问链路信息，为拓扑结构的自动绘制提供数据。通过引入库调用框架拦截采集信息(通过trace id parent id客户端发送时间，服务器端接收时间，服务器端发送时间，客户端接收时间计算每一个节点耗时，通过聚合分析，简化计算，自动绘制网络拓扑图)。另外，可以理解的是，这种采集方式属于非侵入式采集方式，与应用部署到相同的网络区域即可，不受具体应用的限制，具有对应用透明的特性，对应用程序本身无需代码侵入修改。集成了系统，网络、应用的综合体，能够清晰明了，准确定位设备机房或者系统(物理和逻辑层面)单点，负载均衡情况，及薄弱环节。

参见表1，在后台收集数据时，针对CTP框架，首先在1、在event-modules.xml配置一个opStep监听处理链，然后继承AbstractOpStepListener抽象类，接着，在onBeforeExecuted()方法中添加trace start()，并启动跟踪，最后在onAfterExecuted()方法中添加trace finish()，结束跟踪。

表1

步骤S2：利用聚合分析方法以及Neo4j图数据库，根据各个节点所需要的时间生成网络拓扑图。

具体地，使用Neo4j图数据库，CQL语言对图数据库进行操作。图数据库Neo4j有很容易表示连接的数据，检索、遍历、导航大量的连接数据非常容易和快速特点。因此将收集的数据，按照节点和关系(边)存入图数据库，无需转化就可以直接提取，快速成为网状拓扑结构。方便json格式的数据导出。节点：包含属性。(属性可以使用json的嵌套模型，关系(边)：包含开始节点、结束节点及属性。Neo4j的关系具有方向性，在步骤S2中可以对日志进行定制化，具体地：

定制化的日志：标准化的日志和个性化的日志定制相结合。标准化的日志满足了最低要求的单条链路的访问绘制关系和访问延迟，实时显示系统的可用性和性能，鉴别问题节点。个性化定制日志内容，总体格式为json，key-value的键值对轻松定义格式，方便解析。例如：可以识别出具体的服务(不拘泥与单节点级别，基于集群级别，服务级别，应用级别的识别)，报错原因(网络流量剧增，数据库连接不上，数据库SQL语句处理缓慢、服务器吞吐量骤降等问题)。通过二次加工，为报警提供精准的一线原材料。定制日志由于内容比较多，所以日常采集频率低。定制化日志在下面三种情况下采集来减轻系统压力。

(1)延迟时间超过阀值的80％

(2)执行系统运行低峰期进行每日一次的定时任务。

(3)主动开启定制化日志收集开关，调用收集接口。

分析器Analyser负责分析主管基类，子类有单链路分析器LinkAnalyser、全链路分析器(EndtoEndAnalyser)，日志的分析器(LogAnalyser)继承基类，定制化日志分析器(VIPLogAnalyser)。

配置管理系统帮助器CMDBHelper提供配置管理系统采集信息，ManualHelper提供手动输入信息。报警管理员AlarmManager负责报警的判断和修改。判断为报警的送入展示层，不是的，通过修改器标记为无效报警。修改器Modifier负责对报警信息的修改，过期或无效的报警信息标注为INVALID。

这里的追踪消息的格式为json。一份消息通过消息队列kafka的partition分区的特性根据request id(trace id)进行分类管理，request id作为键值，根据放入高速缓存redis中，以提高计算能力，根据父节点parent id来计算请求链路的关系，记录客户端发送消息时间戳cs，服务器端接收端时间戳sr，服务器端发送时间戳ss，客户端接收时间cr，所以有：

客户端发送请求时间＝sr-cs

服务器端处理请求时间＝ss-sr

客户端接收请求时间＝cr-ss

系统延迟的原因一目了然。

另外，成对的(request id，parent id)通过队列的递归计算，以时间复杂度为O(N)的级别实现快速准确识别单链路的访问关系。

针对嵌套识别路径：

1、成对的调用和返回消息：(A＝>B，B＝>A)(B＝>D，D＝>B)(B＝>C，C＝>B)。

2、找到和评分嵌套关系：B＝>C嵌套在A＝>B中，B＝>D也嵌套在A＝>B中

3、选取最佳的家长parent。

4、重建调用路径：A＝>B＝>【C:D】，时间复杂度O(mp)，M＝number of message；P＝mean of per-node parallelism，最后通过时间戳识别因果路径(causal paths)。

当然也可以根据手动输入数据结合自动探测技术自动形成系统架构图，可以手动进行调整补充。

手动输入数据：服务器ip(web服务器，应用服务器，数据库服务器，缓存服务器等)，网络设备和负载均衡设备(F5，网关，交换机，路由器，CDN，防火墙网络区域划分，SLB等)，自动生成应用架构图。

步骤S3：根据网络拓扑图监控互联网架构。

具体地，可以选择基准报警阀值，也可以自定义不同应用的报警阀值。根据系统特点设置灵活的阀值，如果请求返回时间超过阀值，就会报警。

步骤S3可以实现自行探测，具体地，建立生产者消费者模型，建立模拟请求追踪链，形成闭环。模拟发送业务不同类型的访问请求形成应用的访问路线，根据全链路访问路线，自动绘制应用架构图。测试环境中可以写操作，生产环境仅限于读操作。对于单点的路径进行识别，网络区域隔离负载均衡等判断是否符合高可用性，是否有缓存及缓存可用性，不同颜色闪烁不同警告，智能提示优化方案。

本具体应用实例还提供一种高可用架构的例子，首先针对单节点包括以下步骤。

步骤一：单链路分析器LinkAnalyser根据信息收集模块获取到单链路信息。

单链路：

192.12.3.15->192.12.68.128->192.12.34.158->189.5.123.27

192.12.3.16->192.12.68.129->192.12.34.160->189.5.123.27

192.12.3.19->192.12.68.132->192.12.34.161->189.5.123.27

[key，value][service,A]

步骤二：全链路分析器(EndtoEndAnalyser)调用配置管理系统帮助器CMDBHelper和日志的分析器(LogAnalyser)，根据配置管理系统和日志可得到：

服务A：192.12.3.15，192.12.3.16，192.12.3.19

服务B：192.12.68.128，192.12.68.129，192.12.68.132

服务C：192.12.34.158，192.12.34.160，192.12.34.161

服务D：189.5.123.27

步骤三：报警管理员AlarmManager根据请求追踪信息，识别判断目前服务D为单节点访问，向多级别高可用模块提出单节点的预警。目前单节点的预警可能是假预警，由于访问量少，负载均衡策略问题导致的都在189.5.123.27访问。如果出现一条访问192.12.3.15->192.12.68.128->192.12.34.158->189.5.123.26->192.12.3.15，则服务D至少有两台服务器，解除单节点预警，但仍可能存在负载不均衡的问题，可以通过计算判断访问流量。如果不是则在展现层呈现单节点预警高级别的高可用架构问题。对于数据库的主备机有特殊的信息处理，排除其单节点预警。

针对多条单链路出现阈值预警：类似单节点处理过程，重点添加时间延迟的参数信息处理，定制化日志处理，增加了业务场景的判断。根据采集的定制日志，对数据进行二次加工处理，结合配置管理系统cmdb经过聚合分析识别服务应用层面的判断属于同一业务场景的，升级成为多链路超阀值高可用架构报警，帮助快速定位问题，通过业务场景的评估进行封锁交易等操作，解决系统高可用性。

针对SQL语句处理慢的问题：类似单节点处理过程，增加定制日志分析内容。可简单的通过定制日志即可获取到预警。

从上述描述可知，本发明实施例提供的互联网架构全链路监控方法，首先响应于客户的数据请求，接着，采集数据请求经历的各个节点所需要的时间；最后根据各个节点所需要的时间生成网络拓扑图；本发明通过结合全链路监控，有效解决了异构应用的高可用性检测的问题，实现了多级预警和智能优化，并具有较高的可扩展性。本发明具有以下有益效果：

(1)全链路监控和高可用架构检测优化相结合，实现端到端的交易分析能力。本系统对应用生态的实时情况监控，是通过底层基于全链路实时监控实现，及时准确全面的数据来源为聚合分析提供有力的支持。多链路报警侧重于业务场景识别。链路数据实时聚合功能，实现拓扑关系的构建和特征识别，并给予预警阀值结合链路特征精准报警，侧重于业务场景识别，可以帮助快速定位问题。

(2)非侵入性系统，对应用透明。无需大量修改代码，学习成本，减轻程序员的工作量。控制采集频率和采集内容，减少产生的系统压力。

(3)手动和自动获取服务器信息相结合。解决系统迭代快速上线，或者自动扩缩容等系统改变导致的架构改变，可以及时获取到系统架构的现状。

(4)可视化的多级报警和智能优化。分级别的报警可以使运维人员和开发人员工作轻重缓急的有序开展整改。架构的智能优化有效提高系统的高可用性。

基于同一发明构思，本申请实施例还提供了互联网架构全链路监控装置，可以用于实现上述实施例所描述的方法，如下面的实施例。由于互联网架构全链路监控装置解决问题的原理与互联网架构全链路监控方法相似，因此互联网架构全链路监控装置的实施可以参见互联网架构全链路监控方法实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本发明的实施例提供一种能够实现互联网架构全链路监控方法的互联网架构全链路监控装置的具体实施方式，参见图7，互联网架构全链路监控装置具体包括如下内容：

时间采集单元10，用于响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息；

拓扑图生成单元20，用于根据所述各个节点所需要的时间信息生成网络拓扑图；

监控单元30，用于根据所述网络拓扑图监控互联网架构。

一实施例中，所述各个节点所需要的时间信息包括：客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

一实施例中，参见图8，所述时间采集单元10包括：

消息队列建立模块101，用于利用生产者消费者模式，基于所述数据请求以及kafka建立消息队列，所述消息队列格式为json；

节点ID确定模块102，用于根据所述消息队列确定跟踪节点ID、父节点ID以及子节点ID；

时间描述模块103，用于根据所述跟踪节点ID、所述父节点ID以及所述子节点ID描述所述客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

一实施例中，所述拓扑图生成单元具体用于利用聚合分析方法以及Neo4j图数据库，根据所述各个节点所需要的时间信息生成网络拓扑图。

从上述描述可知，本发明实施例提供的互联网架构全链路监控装置，首先响应于客户的数据请求，接着，采集数据请求经历的各个节点所需要的时间；最后根据各个节点所需要的时间生成网络拓扑图；本发明在不侵入系统的基础上，有效解决了异构应用的高可用性检测的问题。

上述实施例阐明的装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为电子设备，具体的，电子设备例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

在一个典型的实例中电子设备具体包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，该处理器执行该程序时实现上述互联网架构全链路监控方法的步骤，该步骤包括：

步骤100：响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息；

步骤200：根据所述各个节点所需要的时间信息生成网络拓扑图；

步骤300：根据所述网络拓扑图监控互联网架构。

下面参考图9，其示出了适于用来实现本申请实施例的电子设备600的结构示意图。

如图9所示，电子设备600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分608加载到随机访问存储器(RAM))603中的程序而执行各种适当的工作和处理。在RAM603中，还存储有系统600操作所需的各种程序和数据。CPU601、ROM602、以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡，调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装如存储部分608。

特别地，根据本发明的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述互联网架构全链路监控方法的步骤，该步骤包括：

步骤100：响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息；

步骤200：根据所述各个节点所需要的时间信息生成网络拓扑图；

步骤300：根据所述网络拓扑图监控互联网架构。

在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上该仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (6)

1.一种互联网架构全链路监控方法，其特征在于，包括：

响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息；

根据所述各个节点所需要的时间信息生成网络拓扑图；

根据所述网络拓扑图监控互联网架构；

所述各个节点所需要的时间信息包括：客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间；

所述响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息，包括：

利用生产者消费者模式，基于所述数据请求以及kafka建立消息队列，所述消息队列格式为json；

根据所述消息队列确定跟踪节点ID、父节点ID以及子节点ID；

根据所述跟踪节点ID、所述父节点ID以及所述子节点ID描述所述客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

2.根据权利要求1所述的互联网架构全链路监控方法，其特征在于，所述根据所述各个节点所需要的时间信息生成网络拓扑图包括：

利用聚合分析方法以及Neo4j图数据库，根据所述各个节点所需要的时间信息生成网络拓扑图。

3.一种互联网架构全链路监控装置，其特征在于，包括：

时间采集单元，用于响应于客户的数据请求，采集所述数据请求所需遍历的各个节点所需要的时间信息；

拓扑图生成单元，用于根据所述各个节点所需要的时间信息生成网络拓扑图；

监控单元，用于根据所述网络拓扑图监控互联网架构；

所述各个节点所需要的时间信息包括：客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间；

所述时间采集单元包括：

消息队列建立模块，用于利用生产者消费者模式，基于所述数据请求以及kafka建立消息队列，所述消息队列格式为json；

节点ID确定模块，用于根据所述消息队列确定跟踪节点ID、父节点ID以及子节点ID；

时间描述模块，用于根据所述跟踪节点ID、所述父节点ID以及所述子节点ID描述所述客户端发送时间，服务器端接收时间，服务器端发送时间以及客户端接收时间。

4.根据权利要求3所述的互联网架构全链路监控装置，其特征在于，所述拓扑图生成单元具体用于利用聚合分析方法以及Neo4j图数据库，根据所述各个节点所需要的时间信息生成网络拓扑图。

5.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至2任一项所述互联网架构全链路监控方法的步骤。

6.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至2任一项所述互联网架构全链路监控方法的步骤。

Images