CN109802842B - 应用拓扑的生成方法及相关设备 - Google Patents

Abstract

本申请提供了一种应用拓扑的生成方法及相关设备，其中，所述应用拓扑的生成方法，包括：应用探针判断被监控应用是否处于启动状态；若所述应用探针判断出所述被监控应用处于启动状态，则在***调用所述被监控应用的接口获取所述被监控应用被***调用时的调用参数；所述应用探针依据所述调用参数、所述被监控应用被***调用时时间戳、以及所述被监控应用的标识，生成调用日志。应用探针在***调用被监控应用的接口处获取被监控应用被***调用时的调用参数，无需用户在应用的源代码中引入应用探针，也就无需用户重新编译应用的源代码，拓宽了应用探针在应用拓扑构建方案中利用的范围，克服了应用探针利用的局限性的问题。

Description

应用拓扑的生成方法及相关设备

技术领域

本申请涉及IT技术领域，尤其涉及一种应用拓扑的生成方法及相关设备。

背景技术

应用在IT***各主机上的部署关系以及所部署的应用间的交互关系，构成了应用拓扑，其主要用于反映应用之间的通信调用关系。

而构建应用拓扑则需要非侵入式监听探针采集到的应用的***调用参数。目前，针对采用Go语言编译的应用，若需要构建应用拓扑，一般在应用的源代码中引入应用探针。该应用探针在启动后，则会在源代码里拦截、监听应用的***调用参数。

但是，在应用的源代码中引入应用探针，实质上是一种侵入式方法，破坏了应用探针的非侵入性。由于在构建应用间的拓扑关系之前，应用的源代码往往是已经编译完毕，要在源代码中引入应用探针则需要重新编译源代码，这样就导致了应用探针在应用拓扑构建方案中利用的局限性。

发明内容

本申请提供了一种应用拓扑的生成方法及相关设备，以克服应用探针在应用拓扑构建方案中利用的局限性的问题。

为了实现上述目的，现提出的方案如下：

本申请的第一方面提供了一种应用拓扑的生成方法，包括：应用探针判断被监控应用是否处于启动状态；若应用探针判断出被监控应用处于启动状态，则在***调用被监控应用的接口获取被监控应用被***调用时的调用参数；应用探针依据调用参数、被监控应用被***调用时时间戳、以及被监控应用的标识，生成调用日志。

从上述过程可以看出：应用探针在***调用被监控应用的接口处获取被监控应用被***调用时的调用参数，无需用户在应用的源代码中引入应用探针，也就无需用户重新编译应用的源代码，拓宽了应用探针在应用拓扑构建方案中利用的范围，克服了应用探针利用的局限性的问题。

在一个实现方式中，在***调用被监控应用的接口获取被监控应用被***调用时的调用参数，包括：应用探针采用***函数的绑定式进程跟踪机制追踪被监控应用，并判断被监控应用是否被***调用；若应用探针判断出被监控应用被***调用，则采用***函数的参数式进程跟踪机制获取所述调用参数。

在一个实现方式中，采用***函数的参数式进程跟踪机制获取所述调用参数之前，还包括：应用探针采用***函数的窥探式进程跟踪机制获取被监控应用的***调用号；应用探针判断***调用号是否属于套接字通信***的调用号；若应用探针判断出***调用号属于套接字通信***的调用号，则执行采用***函数的参数式进程跟踪机制获取调用参数。

在一个实现方式中，应用探针判断被监控应用是否处于启动状态，包括：应用探针在应用的进程号中，依据被监控应用的应用路径和应用名称查找被监控应用的进程号；若应用探针查找到被监控应用的进程号，则判断出被监控应用处于启动状态。

本申请的第二方面提供了一种应用探针，包括：判断单元，用于判断被监控应用是否处于启动状态；获取单元，用于若判断单元判断出被监控应用处于启动状态，则在***调用所被监控应用的接口获取被监控应用被***调用时的调用参数；生成单元，用于依据调用参数、被监控应用被***调用时时间戳、以及被监控应用的标识，生成调用日志。

在一个实现方式中，获取单元，包括：追踪单元，用于采用***函数的绑定式进程跟踪机制追踪被监控应用，并判断被监控应用是否被***调用；第一获取子单元，用于追踪单元判断出被监控应用被***调用，则采用***函数的参数式进程跟踪机制获取调用参数。

在一个实现方式中，获取单元还包括：第二获取子单元，用于采用***函数的窥探式进程跟踪机制获取被监控应用的***调用号；判断子单元，用于判断***调用号是否属于套接字通信***的调用号；其中，判断子单元判断出***调用号属于套接字通信***的调用号的情况下，第一获取子单元执行采用***函数的参数式进程跟踪机制获取调用参数操作。

在一个实现方式中，判断单元包括：查找单元，用于在应用的进程号中，依据被监控应用的应用路径和应用名称查找被监控应用的进程号；其中，若查找单元查找到被监控应用的进程号，则判断单元判断出被监控应用处于启动状态。

本申请的第三方面提供了一种终端，终端部署有至少一个应用以及对应每一个应用、且用于监控应用的应用探针；其中，应用探针监控应用时具体用于执行如上述任意一项所述的方法。

本申请的第四方面提供了一种应用拓扑的生成***，包括：应用探针、收集器、拓扑服务组件和对象管理服务组件；其中：应用探针用于执行如上述任意一项所述的方法；收集器用于收集应用探针生成的调用日志，并上报；拓扑服务组件用于接收收集器上报的调用日志，并依据调用日志和应用部署信息，生成应用拓扑；对象管理服务组件用于存储应用部署信息。

在一个实现方式中，应用探针采用分布式集群化部署，其中：拓扑服务组件接收收集器上报的调用日志时，具体用于：接收由消息中间件接收收集器上报、并转发的调用日志。

在一个实现方式中，拓扑服务组件依据调用日志和应用部署信息，生成应用拓扑，包括：筛选出调用日志中用于判断通信方向的***操作的调用日志，并依据筛选出的调用日志中的***操作，确定出应用间通信的方向；根据调用日志中的通信两端的IP地址和端口信息、以及应用部署信息，确定出调用日志所反映出的进行通信的两个应用的应用名称；筛选出调用日志中用于计算通信频率的调用日志，并依据筛选出的调用日志的数量，计算得到通信的频繁频率。

附图说明

图1为本申请实施例公开的应用拓扑的生成***的结构示意图；

图2为本申请实施例公开的应用拓扑的生成方法的时序图；

图3为本申请实施例公开的步骤S102的具体实施方式的流程图；

图4为本申请实施例公开的被监控应用被***调用时的调用数据的展示图；

图5为本申请实施例公开的应用探针的结构示意图；

图6为本申请实施例公开的终端的结构示意图。

具体实施方式

本申请实施例公开了一种应用拓扑的生成方法，应用于应用拓扑的生成***，参见图1，应用拓扑的生成***包括：应用探针101、收集器102、拓扑服务组件103、对象管理服务组件104。

其中，应用探针101用于监控被监控应用，在***调用被监控应用的接口处获取被监控应用的socket通信信息，并依据socket通信信息生成调用日志。根据被监控应用的编译语言，应用探针101设置为适应该语言的探针，例如：被监控应用由Go语言编译，应用探针101则为Go应用探针。应用探针101可以与被监控应用同步部署，还可以与用于监控被监控应用的uniagent同步部署。

收集器102部署于每一个网元节点。每一个网元节点可以包括多个终端，每一个终端均部署有多个应用。收集器102用于收集对应的网元节点中的应用部署的应用探针101生成的调用日志。

拓扑服务组件103接收由收集器102收集到的调用日志，并生成应用拓扑。

对象管理服务组件104存储有应用的应用部署信息，拓扑服务组件103可从对象管理服务组件104获取应用部署信息。

需要说明的是，应用拓扑的生成***中各个部件的具体执行过程，可参见下述实施例公开的应用拓扑的生成方法的内容。

本申请实施例公开的应用拓扑的生成方法，结合图1和图2，包括以下步骤：

S201、应用探针101判断被监控应用105是否处于启动状态。

其中，与被监控应用105同步部署、或者与被监控应用105的uniagent同步部署的应用探针101，实时或者有间隔的监测被监控应用105，判断该被监控应用105是否处于启动状态。若该被监控应用105处于启动状态，说明被监控应用105存在被***调用的可能。若该被监控应用105处于非启动状态，则继续监测其状态。

可选地，步骤S201的一种具体实施方式中，该步骤包括：

应用探针101在应用的进程号中，依据被监控应用105的应用路径和应用名称查找被监控应用105的进程号。

若应用探针101查找到被监控应用105的进程号，则判断出被监控应用105处于启动状态。

其中，应用被启动时，会产生应用的进程号(以下简称PID)。因此，通过查看应用的PID，即可确定被监控应用105是否被启动。具体的，输入ps命令，调取出***处于启动状态下的应用的PID，由于应用的PID会与应用的应用路径和应用名称相对应的，因此，依据被监控应用105的应用路径和应用名称，则可以查找调取出的应用的PID中是否包括被监控应用105的PID。

还需要说明的是，被监控应用105的应用路径和应用名称，可以是预先在应用探针101中设定，还可以是在执行步骤S101之前，由应用探针101去主动获取。

可选地，应用探针101去主动获取被监控应用105的应用路径和应用名称的方式，参见图1，具体在步骤S201之前，还包括：

S200、应用探针101从对象管理服务组件104读取被监控应用105的应用路径和应用名称。

对象管理服务组件104中保存的应用路径和应用名称可以由用户在配置脚本中输入，还可以是由Paas平台的应用管理中获取。并且，对象管理服务组件104中除了保存有应用的应用路径和应用名称以外，还保存有应用的应用标识、所属集群、执行通信时的IP地址和端口信息等其他应用部署信息，且均可以由Paas平台的应用管理中获取。

为了保证对象管理服务组件104有序性的存储应用部署信息，需要将每一个应用的应用名称、应用路径、应用标识、所属集群、执行通信时的IP地址和端口信息等应用部署信息按照列表式进行存储。

若应用探针101判断出被监控应用105处于启动状态，则执行S202、在***调用被监控应用105的接口处获取被监控应用105被***调用时的调用参数。

可选地，可以采用ptrace***在***调用被监控应用105的接口处监听、截取被监控应用105被***调用时的调用参数。其中，ptrace***函数由部署有被监控应用105和应用探针101的***自带的，提供了一个进程监视、控制另一个进程的执行机制，并且可以查询和修改被追踪进程的内存和寄存器。

其中，被监控应用105被***调用完成socket通信时，则利用ptrace***函数获取被监控应用105进行socket通信两端的IP地址和端口信息。其中，被监控应用105被***调用时的参数信息则包括socket通信两端的IP地址和端口信息。

应用探针101在***调用被监控应用的接口处获取被监控应用被***调用时的调用参数，无需用户在应用的源代码中引入应用探针，也就无需用户重新编译应用的源代码，拓宽了应用探针在应用拓扑构建方案中利用的范围，克服了应用探针利用的局限性的问题。

并且，应用探针101读取被监控应用105的应用路径和应用名称之后，即可利用被监控应用105的应用路径和应用名称，自动监测被监控应用的运行状态，判断被其是否处于启动状态，以执行获取被监控应用105被***调用时的参数信息的步骤，无需用户进行繁琐的配置过程，保证了较高的工作效率。

可选地，步骤S202的一种具体实施方式中，参见图3，该步骤包括：

S301、应用探针101采用ptrace***函数的绑定式进程跟踪机制追踪被监控应用105，并判断被监控应用105是否被***调用。

其中，应用探针101判断出被监控应用处于启动状态，应用探针101便通过ptrace***函数的绑定式进程跟踪机制(也称为PTRACE_ATTACH)来追踪被监控应用105，判断该被监控应用105是否被***调用。

PTRACE_ATTACH是ptrace***函数的一个参数，采用PTRACE_ATTACH这种机制来追踪被监控应用，可以使得应用探针进程能够与被监控应用的进程绑定，让被监控应用的进程每次进行***调用时都能被应用探针拦截、监控。

若应用探针101判断出被监控应用105被***调用，则执行步骤S302、应用探针101采用ptrace***函数的参数式进程跟踪机制获取***的调用参数。

其中，若应用探针101通过PTRACE_ATTACH判断出被监控应用105被***调用，则说明需要获取***的调用参数，则采用ptrace***函数的参数式进程跟踪机制(也称为PTRACE_GETREGS)获取***的调用参数。并且，PTRACE_GETREGS是ptrace***函数的另一个参数，其本身的功能就是获取***调用被监控应用时的调用参数。

应用探针101采用参数式进程跟踪机制提取出***每一次调用的调用数据，根据调用数据解析出***一次调用的调用参数，该***的调用参数一般包括：通信两端的IP地址和端口信息。

例如，参见图4，提取的***调用的调用数据包括：用框框出的connect操作的调用数据、getsockname操作的调用数据、getpeername操作的调用数据和write操作的调用数据。其中，read和write操作的调用数据没有包括通信两端的IP地址和端口信息，仅包括套接字。因此，若***调用为read操作或write操作，则需要利用套接字来间接获取通信两端的IP地址和端口信息。具体的，依据套接字筛选***的调用数据，查找与read操作或write操作的调用数据包括的套接字相同的getsockname操作和getpeername操作，获取getsockname操作和getpeername操作的调用数据中的通信两端的IP地址和端口信息。在图4中，框选的write操作的调用数据中，套接字为3。将套接字为3作为筛选凭据筛选***的每一项调用数据，筛选出用框框选出的getsockname操作和getpeername操作中，套接字均为3。因此，获取套接字均为3的getsockname操作和getpeername操作中的通信两端的IP地址和端口信息。

还需要说明的是，若被监控应用由Go语言编译，提取的***调用的调用数据一般包括：connect、write、read、getsockname和getpeername操作的相关数据，不用提取accept操作的数据，因为Go应用的accept***调用并不直观，而且仅借助connect便已经足够判断通信方向了。

为了尽量减少对被监控应用正常运行的时延影响，在判断出被监控应用被***调用之后，还需要过滤不必要的***调用拦截。因此，可选地，同样参见图3，步骤S301中，应用探针101判断出被监控应用105被***调用之后，执行S303。

S303、应用探针101采用ptrace***函数的窥探式进程跟踪机制获取被监控应用105的***调用号；

其中，ptrace***函数的窥探式进程跟踪机制(也称为PTRACE_PEEKUSER)，也是ptrace***函数的另一个参数，其功能之一就是获取***调用号。

S304、应用探针101判断获取得到的***调用号是否属于套接字通信***的调用号。

其中，***调用号与***函数名一一对应，判断***调用是否属于套接字(也称socket)通信***的调用号，就是指判断***调用号是否属于socket通信函数对应的调用号中的一个。

若应用探针101判断出***调用号属于套接字通信***的调用号，则执行步骤S302。若应用探针101判断出***调用号不属于套接字通信***的调用号，则跳过该***调用，不获取被监控应用105的调用参数，继续判断被监控应用105被***下一次调用时的***调用号。

其中，应用探针101判断出***调用号属于套接字通信***的调用号之后执行的步骤S302中，采用ptrace***函数的参数式进程跟踪机制获取的***的调用参数，包括被socket通信***调用的调用参数。

S203、应用探针101依据参数信息、被监控应用被***调用时的时间戳、以及被监控应用的应用标识，生成调用日志。

其中，调用日志包括：被监控应用105的应用标识、被监控应用105被***调用时的时间戳、被监控应用105被***调用时的参数信息。由于被监控应用105被***调用，一般用于执行socket通信，因此，该参数信息包括：socket通信的***操作，以及socket通信两端的IP地址和端口信息。

调用日志的格式可以为Timestamp|srcDN|localIP:port|remoteIP:port|method，示例如下：

2017-06-25 15:03:22|a21da5d153a4a9626425e|127.0.0.1:8887|127.0.0.3:5678|connect

2017-06-25 15:03:22|a21da5d153a4a9626425e|127.0.0.1:8887|127.0.0.3:5678|write

其中，Timestamp是被监控应用被***调用时的时间戳；srcDN是被监控应用的标识；

localIP:port是本地的IP地址和端口信息；remoteIP:port是对端的IP地址和端口信息；method是***操作，用以判断被监控应用在进行何种操作，比如：第一个示例中method为connect，则通过connect可以判断socket连接成功且该被监控应用为客户端。第二示例中method为write，通过write或read可以监控当前时刻是否有数据传输。

需要说明的是，被监控应用被***调用，执行通信的建立或者断开操作不会很频繁，但是在通信过程中的读写操作有可能频繁发生。因此，为了减少不必要的写日志操作，还需要进行调用日志去重、流控，也就是不对短时间内的读写操作重复记录。

具体的，可以通过对一个时间窗内的method进行过滤，若在该时间窗内的同一个被监控应用的同一个通信中已经记录过read或write，则后续不再进行读写操作的调用日志的记录，过了这个时间窗才能进行下一个读写操作的调用日志的记录。

还需要说明的是，应用探针101生成调用日志的被监控应用105的应用标识，也可以由应用探针101由对象管理服务组件104获取。

S204、收集器102收集应用探针101生成的调用日志。

其中，收集器102对应网元节点设置，且网元节点包括的每一个终端均可以包括由多种语言编译的应用。因此，收集器102收集得到的调用日志包括适应多种语言编译的应用探针生产的调用日志。为了方便管理，收集器102将收集到的应用日志统一规划格式，再进行封装。

S205、拓扑服务组件103接收由收集器102上报的调用日志。

可选地，若被应用探针监控的应用采用分布式集群化部署，由于应用探针与应用同步部署。因此，应用探针也属于分布式集群化部署。收集器102收集到应用探针101生成的调用日志并封装成日志后，发布到消息中间件kafka，由kafka转发到拓扑服务组件103。

S206、拓扑服务组件103依据调用日志和应用部署信息，生成应用拓扑。

其中，拓扑服务组件103生成的应用拓扑，就是指各个被监控应用间的实时通信拓扑关系。具体的，识别每一项调用日志的***操作，筛选出用于判断通信方向的调用日志，一般为connect操作或accetp操作的调用日志。依据筛选出的调用日志中的***操作，确定出socket通信的方向。根据调用日志中的通信两端的IP地址和端口信息，结合应用部署信息，确定出每一项调用日志所反映出的进行通信的两个应用名称。从调用日志中，依据***操作筛选出用于计算通信频率的调用日志，一般为read操作或write操作的调用日志。依据筛选出的调用日志的数量，计算得到通信的频繁频率。

拓扑服务组件103计算得到包括进行通信的应用的名称、通信的方向以及通信的频繁频率的应用拓扑后，将应用拓扑由拓扑服务组件103界面展示。如此，通过拓扑服务组件103界面展示，可以直观地将包括应用间的通信方向以及通信频繁程度的应用拓扑展示给用户，便于用户开展故障诊断、隔离以及根因分析操作。

可选地，本步骤中，拓扑服务组件103生成应用拓扑所需的应用部署信息，可以由对象管理服务组件104中获取。

本申请实施例还公开了一种应用探针，如图5所示，包括：

判断单元501，用于按照对应图2的实施例中步骤S201所公开的实施方式，判断被监控应用是否处于启动状态。

获取单元502，用于若判断单元501判断出被监控应用处于启动状态，则按照对应图2的实施例中步骤S202所公开的实施方式，在***调用被监控应用的接口处获取被监控应用被***调用时的调用参数。

生成单元503，用于按照对应图2的实施例中步骤S203所公开的实施方式，依据调用参数、被监控应用被***调用时时间戳、以及被监控应用的标识，生成调用日志。

可选地，在一种实施方式中，仍可参见图5，获取单元502，包括：

追踪单元5021，用于按照对应图3的实施例中步骤S301所公开的实施方式，采用ptrace***函数的绑定式进程跟踪机制追踪被监控应用，并判断被监控应用是否被***调用。

第一获取子单元5022，用于在追踪单元5021判断出被监控应用被***调用的情况下，按照对应图3的实施例中步骤S302所公开的实施方式，采用ptrace***函数的参数式进程跟踪机制获取所述调用参数。

可选地，在一种实施方式中，仍可参见图5，获取单元502还包括：

第二获取子单元5023，用于按照对应图3的实施例中步骤S303所公开的实施方式，采用ptrace***函数的窥探式进程跟踪机制获取被监控应用的***调用号。

判断子单元5024，用于按照对应图3的实施例中步骤S304所公开的实施方式，判断***调用号是否属于套接字通信***的调用号。

其中，判断子单元5024判断出***调用号属于套接字通信***的调用号的情况下，第一获取子单元5022执行采用ptrace***函数的参数式进程跟踪机制获取调用参数操作。

可选地，在一种实施方式中，仍可参见图5，判断单元501，包括：

查找单元5011，用于在应用的进程号中，依据被监控应用的应用路径和应用名称查找被监控应用的进程号；

其中，若查找单元5011查找到被监控应用的进程号，则判断单元501判断出被监控应用处于启动状态。

本申请实施例还公开了一种终端，参见图6，终端部署有至少一个应用601和以及对应每一个应用601、且用于监控应用601的应用探针602；其中，应用探针602监控应用601时具体按照对应图2的实施例公开的实施方式、对应图3的实施例工公开的实施方式执行应用拓扑的生成方法。

Claims (12)

1.一种应用拓扑的生成方法，其特征在于，包括：

应用探针判断被监控应用是否处于启动状态；

若所述应用探针判断出所述被监控应用处于启动状态，则在***调用所述被监控应用的接口处获取所述被监控应用被***调用时的调用参数，所述调用参数包括通信两端的IP地址和端口信息；

所述应用探针依据所述调用参数、所述被监控应用被***调用时的时间戳、以及所述被监控应用的标识，生成调用日志；所述调用日志用于生成应用拓扑。

2.根据权利要求1所述的方法，其特征在于，所述在***调用所述被监控应用的接口处获取所述被监控应用被***调用时的调用参数，包括：

所述应用探针采用***函数的绑定式进程跟踪机制追踪所述被监控应用，并判断所述被监控应用是否被***调用；

若所述应用探针判断出所述被监控应用被***调用，则采用***函数的参数式进程跟踪机制获取所述调用参数。

3.根据权利要求2所述的方法，其特征在于，所述采用***函数的参数式进程跟踪机制获取所述调用参数之前，还包括：

所述应用探针采用***函数的窥探式进程跟踪机制获取所述被监控应用的***调用号；

所述应用探针判断所述***调用号是否属于套接字通信***的调用号；

若所述应用探针判断出所述***调用号属于所述套接字通信***的调用号，则执行采用***函数的参数式进程跟踪机制获取所述调用参数。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述应用探针判断被监控应用是否处于启动状态，包括：

所述应用探针在应用的进程号中，依据所述被监控应用的应用路径和应用名称查找所述被监控应用的进程号；

若所述应用探针查找到所述被监控应用的进程号，则判断出所述被监控应用处于启动状态。

5.一种应用探针，其特征在于，包括：

判断单元，用于判断被监控应用是否处于启动状态；

获取单元，用于若所述判断单元判断出所述被监控应用处于启动状态，则在***调用所述被监控应用的接口处获取所述被监控应用被***调用时的调用参数，所述调用参数包括通信两端的IP地址和端口信息；

生成单元，用于依据所述调用参数、所述被监控应用被***调用时时间戳、以及所述被监控应用的标识，生成调用日志；所述调用日志用于生成应用拓扑。

6.根据权利要求5所述的应用探针，其特征在于，所述获取单元，包括：

追踪单元，用于采用***函数的绑定式进程跟踪机制追踪所述被监控应用，并判断所述被监控应用是否被***调用；

第一获取子单元，用于所述追踪单元判断出所述被监控应用被***调用，则采用***函数的参数式进程跟踪机制获取所述调用参数。

7.根据权利要求6所述的应用探针，其特征在于，所述获取单元还包括：

第二获取子单元，用于采用***函数的窥探式进程跟踪机制获取所述被监控应用的***调用号；

判断子单元，用于判断所述***调用号是否属于套接字通信***的调用号；

其中，所述判断子单元判断出所述***调用号属于所述套接字通信***的调用号的情况下，所述第一获取子单元执行采用***函数的参数式进程跟踪机制获取调用参数操作。

8.根据权利要求5-7任一项所述的应用探针，其特征在于，所述判断单元，包括：

查找单元，用于在应用的进程号中，依据所述被监控应用的应用路径和应用名称查找所述被监控应用的进程号；

其中，若所述查找单元查找到所述被监控应用的进程号，则所述判断单元判断出所述被监控应用处于启动状态。

9.一种终端，其特征在于，所述终端部署有至少一个应用以及对应每一个应用、且用于监控所述应用的应用探针；其中，所述应用探针监控所述应用时具体用于执行如权利要求1-4中任意一项所述的方法。

10.一种应用拓扑的生成***，其特征在于，包括：应用探针、收集器、拓扑服务组件和对象管理服务组件；其中：

所述应用探针用于执行如权利要求1-4中任意一项所述的方法；

所述收集器用于收集所述应用探针生成的调用日志，并上报；

所述拓扑服务组件用于接收所述收集器上报的调用日志，并依据所述调用日志和应用部署信息，生成应用拓扑；

所述对象管理服务组件用于存储所述应用部署信息。

11.根据权利要求10所述的***，其特征在于，所述应用探针采用分布式集群化部署，其中：所述拓扑服务组件接收所述收集器上报的调用日志时，具体用于：

接收由消息中间件接收所述收集器上报、并转发的所述调用日志。

12.根据权利要求10或11所述的***，其特征在于，所述拓扑服务组件依据所述调用日志和应用部署信息，生成应用拓扑，包括：

筛选出所述调用日志中用于判断通信方向的***操作的调用日志，并依据筛选出的调用日志中的***操作，确定出应用间通信的方向；

根据所述调用日志中的通信两端的IP地址和端口信息、以及所述应用部署信息，确定出所述调用日志所反映出的进行通信的两个应用的应用名称；

筛选出所述调用日志中用于计算通信频率的调用日志，并依据筛选出的调用日志的数量，计算得到通信的频繁频率。

Images