CN106034047B - 数据处理方法及装置 - Google Patents
数据处理方法及装置 Download PDFInfo
- Publication number
- CN106034047B CN106034047B CN201510180705.0A CN201510180705A CN106034047B CN 106034047 B CN106034047 B CN 106034047B CN 201510180705 A CN201510180705 A CN 201510180705A CN 106034047 B CN106034047 B CN 106034047B
- Authority
- CN
- China
- Prior art keywords
- dimension
- homophony
- business module
- business
- monitoring data
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明实施例公开了一种数据处理方法及装置；方法包括：获取服务节点之间进行访问的监控数据，所述监控数据从至少一个维度表征所述服务节点之间、以及所述服务节点的服务之间进行访问的特征信息；基于所述监控数据的上报时间将所述监控数据进行分片处理，得到分片监控数据，分片处理时所使用的时间片的大小基于监控的实时性要求确定；确定目标维度，所述目标维度包括所述维度至少之一；基于所述目标维度对所述分片监控数据进行归并处理，得到所述目标维度的分片监控数据的归并处理结果。采用本发明，能够对海量的监控数据进行高效归并处理，以便能够基于归并结果进行告警分析或确定网络故障。
Description
技术领域
本发明涉及大数据技术，尤其涉及一种数据处理方法及装置。
背景技术
基于互联网的社交网络日益壮大，社交应用如QQ、微信的用户群相当庞大，庞大的用户群使用社交应用对在后台支撑社交网络的服务器集群的稳定性和健壮性提出了更高的要求。
目前，社交应用的功能需要服务节点(可以由一个或多个服务器的网络资源、运算资源映射而成，每个服务节点支持运行一个或多个服务)交互实现，社交应用的功能越来越多、且用户的基数庞大，这就需要对海量的服务节点的监控数据进行分析，并且需要及时分析出故障所在；当基于监控数据进行分析时，由于监控数据的数据往往是海量，导致难以及时对监控数据进行告警分析处理或定位故障。
发明内容
本发明实施例提供一种数据处理方法及装置，能够对海量的监控数据进行高效归并处理，以便能够基于归并结果进行告警分析或确定网络故障。
本发明实施例的技术方案是这样实现的：
本发明实施例提供一种数据处理方法，所述方法包括：
获取服务节点之间进行访问的监控数据，所述监控数据从至少一个维度表征所述服务节点之间、以及所述服务节点的服务之间进行访问的特征信息；
基于所述监控数据的上报时间将所述监控数据进行分片处理，得到分片监控数据，分片处理时所使用的时间片的大小基于监控的实时性要求确定；
确定目标维度，所述目标维度包括所述维度至少之一；
基于所述目标维度对所述分片监控数据进行归并处理，得到所述目标维度的分片监控数据的归并处理结果。
本发明实施例还提供一种数据处理装置，所述装置包括：
接收单元，用于获取服务节点之间进行访问的监控数据，所述监控数据从至少一个维度表征所述服务节点之间、以及所述服务节点的服务之间进行访问的特征信息；
格式化单元，用于基于所述监控数据的上报时间将所述监控数据进行分片处理，得到分片监控数据，分片处理时所使用的时间片的大小基于监控的实时性要求确定；
归并单元，用于确定目标维度，所述目标维度包括所述维度至少之一；
所述归并单元，还用于基于所述目标维度对所述分片监控数据进行归并处理，得到所述目标维度的分片监控数据的归并处理结果。
本发明实施例中，采集承载社交应用的网络上报的监控数据包括服务节点维度(包括主调服务节点维度和被调服务节点维度)、服务维度(包括主调服务维度和被调服务维度)、被调服务接口维度；基于上述维度确定不同的目标维度，进而基于不同的目标维度对分片监控数据进行归并处理， 由于采用了基于时间片对监控处理进行分片处理后进行不同目标维度的归并处理， 实现了数据的实时处理，相较于相关技术提升了处理效率；并且，不同目标维度的归并处理结果能够从不同的角度表征网络在不同时间片的状态信息，从而便于基于不同目标维度的数据归并处理结果进行告警分析，进而实现故障的精确定位。
附图说明
图1是本发明实施例中部署Storm集群系统承载数据处理装置的示意图；
图2是本发明实施例中承载数据处理装置的Storm集群处理数据流的示意图；
图3发是本发明实施例中承载数据处理装置的Storm集群的计算拓扑的示意图；
图4是本发明实施例中承载社交应用的网络的拓扑示意图一；
图5是本发明实施例中承载社交应用的网络的拓扑示意图二；
图6是本发明实施例中承载社交应用的网络的拓扑示意图三；
图7是本发明实施例中承载社交应用的网络的拓扑示意图四；
图8是本发明实施例中承载社交应用的网络的拓扑示意图五；
图9是本发明实施例中承载社交应用的网络的拓扑示意图六；
图10是本发明实施例中数据处理装置的结构示意图；
图11是本发明实施例中Storm集群系统承载数据处理装置的拓扑示意图。
具体实施方式
以微信应用为例，为了能够对用户触发的功能及时响应，保证用户体验，往往需要部署的大量的服务节点实现微信应用中的不同功能(如查看朋友圈、添加好友等)，社交应用中的可以由至少一个业务模块不仅限于一个，业务模块为多个服务节点组成)与其他业务模块之间进行访问(也可以称为模块调用)实现，相应地产生海量针对服务节点的监控数据；发明人发现，由此导致的问题在于：
1)监控数据本身的信息量少，往往只涵盖对应主调服务节点(可以采用主调IP表示)、以及被调服务节点(采用被调服务IP标识)通过特定接口提供被调服务的特定接口(采用接口ID)两个维度对应的信息，例如成功次数、延时等；当微信的某一功能出现问题时，无法准确定位故障所在，如图1所示，基于上述的监控数据只能确定故障是位于哪个主调服务节点或被调服务节点的接口，而无法将故障定位到业务模块、主调服务节点、主调服务节点中的服务，或被调服务节点。
2)监控数据量大，导致难以及时分析，从而进行告警处理或定位故障
承载社交应用的服务节点产生的监控数据往往是海量，如果逐个分析监控数据，需要耗费相当的运算资源，并且难以保证后续告警处理或定位故障的实时性。
发明人在实施本发明的过程中发现，如果能够将服务节点的监控数据扩展到相较于现有技术更多的维度，也就是从多个维度采集对应服务节点的监控数据，并基于监控数据的上报时间对监控数据进行分片处理得到分片监控数据，对于分片监控数据进行目标维度的归并，得到目标维度的分片监控数据的归并处理结果，这种基于时间片(可以单个时间片或一段时间对应的时间片)对应分片监控数据进行归并的处理方式相较于能够明显提升监控数据的处理效率并且，监控数据是基于多个维度采集得到的，能够对服务节点的运行情况进行全面的描述，这就便于基于分片监控数据的归并结果进行告警分析或定位故障。
以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
实施例一
本实施例记载一种数据处理方法，可以由数据处理装置来实现，这里的数据处理装置在拓扑上可以采用Storm集群系统架构实现，数据处理装置对数据进行处理的不同功能单元或步骤可以映射到Storm集群系统中的工作节点中，由不同的工作节点完成数据处理；Storm系统的一个示意图如图1所示，Storm系统主要是由一个主节点(Master node)和工作节点(Worker node)组成，通过Zookeeper进行协调；其中，主节点运行一个后台程序Nimbus，用于在Storm系统中的资源分配和任务调度，并且监控系统状态；工作节点(主节点和多个工作节点由服务器的集群即Storm集群实现)运行一个后台程序Supervisor，用于接收分配的任务，根据需要管理(启动或关闭)Worker进程；Zookeeper，用于存放公有数据(如心跳信息、Storm系统的状态和配置信息)；Nimbus、Supervisor和Worker都把心跳信息保存在Zookeeper；以使Nimbus根据Zookeeper上的心跳信息和系统状态，进行资源分配和任务调度。
每个节点都是拓扑(Topology)中一个子集的实现，Topology为Storm系统中运行的一个实时应用程序，可以表征作为数据源的发射节点(Spout)和数据处理节点(Bolt)间的消息流(Stream，简称为流)的传递形成的逻辑上的一个拓扑结构，如图2所示，Storm系统中的数据以流的形式传递，流的基本单位为元组(Tuple)，Storm中的流可以视为由元组组成的有向无界(在时间上无界)的序列；
一个Topology的示意图如图3所示，Topology可以视为由Bolt和Spout组成的计算拓扑，Bolt和Spout通过Worker进程中的线程运行，线程也可以称为任务(Task)；Spout为Storm系统中流的源头，用于从外部数据源(如消息队列或数据库)获取流并发送至Storm；Bolt为Storm系统中的计算单元，它可以只传输流，也可以根据自身的消息处理逻辑处理来自上游(Bolt或Spout)的流，进行过滤，聚合，查询等操作，并根据处理逻辑向下游的Bolt发送处理后的流或将处理后得到的结果入库存储。
Topology中每一个计算组件(Spout和Bolt)都有一个并行执行度，在创建Topology时可以进行指定，Zookeeper会在集群内分配对应并行度个数的线程(也即Task)来同时运行组件；如图4所示，Topology中使用流(也即消息流)分组(Streaming Grouping)来指定组件之间的流的发送，即Bolt/上游Spout发送(也可以称为发射)流的目标下游Bolt、以及目标下游Blot中用于处理流的目标Task；在如图3的示出的流分组一个示意图中，Spout将流发送至下游的Bolt a和Bolt b中Task处理，Bolt b将处理后的结果发送至Bolt c中的Task。
如图4所示，本实施例记载的数据处理方法可以包括以下步骤：
步骤101，获取服务节点之间进行访问的监控数据。
发明人发现承载社交应用的网络拓扑具有金字塔式的结构特点，这样可以基于该结构特点将采集监控数据的维度与网络拓扑的结构对应起来，例如网络拓扑的每一次结构对应一个采集监控数据的维度；承载社交应用的网络拓扑自上而下的结构为：业务模块->服务节点(包括主调服务节点和被调服务节点)->服务(服务节点中运行的服务)->被调服务接口(被调服务响应主调服务的服务调用请求的接口)；
下面结合图5进行说明，在图5所示的社交应用的承载网络拓扑结构如图5所示，多个服务节点承载相同的一个业务而在拓扑上构成一个业务模块，在业务模块这一层拓扑中，社交应用中的功能(如图5所示的添加好友)是由业务模块之间的访问(具体通过调用实现)，具体为主调业务模块(可以采用主调模块ID标识)访问被调业务模块(可以采用被调业务模块ID标识)实现；业务模块是多个服务节点构成以支撑实现社交应用的一个功能，那么在服务节点这一层拓扑中，业务模块之间的访问是服务节点之间通过服务调用实现的，其中主动发起服务调用请求的服务节点称为主调服务节点(可以采用主调IP标识)，主调服务节点针对用户侧触发的社交应用的一个功能向被调服务节点发起调用请求，被调服务节点(可以采用被调IP标识)提供的被调服务(采用被调服务ID标识)通过被调服务的特定接口(采用接口ID)来响应主调服务的服务调用请求；服务节点(包括主调服务节点和被调服务节点)中运行有多个服务，那么在服务这一层拓扑结构中，业务模块之间的访问是通过服务之间的调用实现的，其中主调服务节点运行的发起调用请求的服务为主调服务(采用主调服务ID标识)。
结合上述分析，本实施例中基于以下维度来采集监控数据：服务节点(包括主调服务节点和被调服务节点)；服务(服务节点中运行的服务)；被调服务接口(被调服务响应主调服务的服务调用请求的接口)；这样，当社交应用的功能出现问题时，能够基于监控数据确定故障出现在网络的哪一层，例如是服务节点故障导致社交应用的功能出现问题，还是某一个被调服务的接口出现问题导致社交应用的功能不可用，从而能够及时排除故障；再例如可以基于不同维度(如业务模块维度、服务节点维度)采集监控数据，包括不同维度的调用成功次数、调用失败次数、调用延时信息。
步骤102，基于监控数据的上报时间将监控数据进行分片处理，得到分片监控数据。
分片处理时所使用的时间片的大小基于监控的实时性要求确定，由于监控数据的数量很大，可以采用1分钟为时间片长度，将一天采集(上报)的监控数据基于上报时间分为1440个分片监控数据；当然，这里的时间片长度仅为示例，时间片长度可以基于数据处理装置的运算能力和数据处理的实时性要求确定。
结合在步骤101中的分析，每个分片数据可以包括以下维度对应的调用成功次数、调用失败次数、调用延时：
服务节点维度，如图6所示，主调业务模块1调用被调业务模块3的处理在服务节点维度，是由主调服务节点1运行的主调服务1访问被调服务节点运行的被调服务1以及被调服务2实现的；
服务维度，如图6所示，主调业务模块1调用被调业务模块3的处理在服务节点维度，是由主调服务1被调服务1以及被调服务2实现的；
被调服务接口维度，如图7所示，主调业务模块1调用被调业务模块3的处理在被调服务接口维度，是由主调服务1调用被调服务1的接口1以及被调服务2的接口3实现的。
步骤103，确定目标维度。
目标维度可以为业务模块维度、服务节点维度、服务维度、被调服务接口维度)的任意组合，下面结合部分组合得到的目标维度举例说明：
第一目标维度：主调业务模块ID(对应主调业务模块维度)、被调业务模块ID(对应被调业务模块维度)；第一维度的调用成功次数，调用失败次数、调用延时等信息，表征主调业务模块和被调业务模块的访问是否正常；结合图8，当第一目标维度为主调业务模块1、被调业务模块2时，该第一目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调业务模块1、被调业务模块2之间的调用情况(如调用是否正常)。
第二目标维度：主调业务模块ID、被调业务模块ID、主调服务ID(对应主调服务维度)；第二维度的调用成功次数，调用失败次数、调用延时等信息，能反应出主调业务模块运行的主调服务调用被调业务模块(也即调用被调业务模块运行的服务)的情况；结合图7，当第二目标维度为主调业务模块1、被调业务模块2、主调服务1时，该第二目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调业务模块1运行的主调服务1调用被调业务模块2(也即调用被调业务模块2运行的被调服务1、以及被调服务2)的情况。
第三目标维度：主调服务ID、被调服务ID；第三维度的调用成功次数，调用失败次数、调用延时等信息，能反应出主调服务调用被调服务的情况；结合图7，当第三目标维度为主调服务1、被调服务1时，该第三目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调服务1调用被调服务1的情况，类似的，当第三目标维度为主调服务1、被调服务2时，该第三目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调服务1调用被调服务2的情况。
第四目标维度：主调服务ID、被调服务ID、被调服务接口ID(对应被调服务接口维度)；第四维度的调用成功次数，调用失败次数、调用延时等信息，能反应出主调服务通过被调服务的特定接口调用被调服务的情况；结合图7，当第四目标维度为主调服务1、被调服务1、接口1时，该第四目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调服务1通过接口1调用被调服务1的情况；当第四目标维度为主调服务1、被调服务1、接口2时，该第四目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调服务1通过接口2调用被调服务1的情况；当第四目标维度为主调服务1、被调服务2、接口3时，该第四目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调服务1通过接口3调用被调服务2的情况；当第四目标维度为主调服务1、被调服务2、接口4时，该第四目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调服务1通过接口4调用被调服务2的情况。
第五目标维度：主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID；第五维度的调用成功次数，调用失败次数、调用延时等信息，能反应出主调服务通过被调服务的特定接口调用被调服务的情况；结合图7，当第五目标维度为主调业务模块1、主调服务1、被调业务模块3、被调服务1、接口1时，该第五目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调业务模块1运行的主调服务1通过接口1调用被调业务模块3运行的被调服务1的情况；当第五目标维度为主调业务模块1、主调服务1、被调业务模块3、被调服务1、接口2时，该第五目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调业务模块1运行的主调服务1通过接口2调用被调业务模块3运行的被调服务1的情况；
当第五目标维度为主调业务模块1、主调服务1、被调业务模块3、被调服务2、接口3时，该第五目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调业务模块1运行的主调服务1通过接口3调用被调业务模块3运行的被调服务2的情况；
当第五目标维度为主调业务模块1、主调服务1、被调业务模块3、被调服务2、接口4时，该第四目标维度的调用成功次数，调用失败次数、调用延时等信息表征主调业务模块1运行的主调服务1通过接口4调用被调业务模块3运行的被调服务2的情况。
步骤104，基于目标维度对分片监控数据进行归并处理，得到目标维度的分片监控数据的归并处理结果。
步骤101获取服务节点之间进行访问的监控数据。从服务节点维度、服务维度、被调服务接口维度表征了调用成功次数、失败次数以及调用延时信息，相应地，在对监控数据分片得到的分片监控数据，也从模块维度、服务节点维度、服务维度、被调服务接口维度表征了调用成功次数、失败次数以及调用延时信息；在步骤104中进行归并处理的目标分片监控数据，可以为任意时间段上报的监控数据得到的分片监控数据(如一天、一周或一月上报的监控数据得到的分片监控数据)，从而得到不同时间段的归并处理结果；下面结合图9对得到不同目标维度的归并处理结果的实施过程进行说明。
图9示出承载社交应用的一个功能的拓扑结构图，该社交应用的功能可以社交应用(如微信、QQ)中的任意功能(如微信的朋友圈、QQ的好友空间)；在业务模块维度，该功能由主调业务模块1访问被调业务模块2实现；在服务节点维度，该功能由主调服务节点1调用被调服务节点3实现；在服务维度，该功能由主调服务1调用被调服务1、以及被调服务2实现，并由主调服务2调用被调服务1、以及被调服务2实现；在被调服务接口维度，该服务由主调服务1通过被调服务1的接口1、接口2调用被调服务2实现，并由主调服务1通过被调服务2的接口3、接口4调用被调服务2实现，该服务还由主调服务2通过被调服务1的接口1、接口2调用被调服务2实现，并由主调服务2通过被调服务2的接口3、接口4调用被调服务2实现。
如前所述，分片监控数据在业务模块维度、服务节点维度、服务维度、被调服务接口维度表征了调用成功次数、失败次数以及调用延时信息；结合图9，在主调服务节点1、主调服务1、被调服务节点3、被调服务1、接口1维度对应的分片监控数据的一个示例如表1所示(为表示方便，使用xxx代表具体数值，其中每个表项的xxx可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
| 主调服务节点1 | 被调服务节点3 | 主调服务1 | 被调服务1 | 接口1 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表1
结合图9，在主调服务节点1、主调服务1、被调服务节点3、被调服务1、接口2维度对应的分片监控数据的一个示例如下表2所示(为表示方便，使用xxx代表具体数值，其中每个表项的xxx可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
| 主调服务节点1 | 被调服务节点3 | 主调服务1 | 被调服务1 | 接口2 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表2
结合图9，在主调服务节点1、主调服务1、被调服务节点3、被调服务2、接口3维度对应的分片监控数据的一个示例如下表3所示(为表示方便，使用xxx代表具体数值，其中每个表项的xxx可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
| 主调服务节点1 | 被调服务节点3 | 主调服务1 | 被调服务2 | 接口3 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表3
结合图9，在主调服务节点1、主调服务1、被调服务节点3、被调服务2、接口4维度对应的分片监控数据的一个示例如下表4所示(为表示方便，使用xxx代表具体数值，其中每个表项的xxx可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
| 主调服务节点1 | 被调服务节点3 | 主调服务1 | 被调服务2 | 接口4 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表4
结合图9，在主调服务节点1、主调服务2、被调服务节点3、被调服务1、接口1维度对应的分片监控数据的一个示例如下表5所示(为表示方便，使用xxx代表具体数值，其中每个表项的xxx可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
| 主调服务节点1 | 被调服务节点3 | 主调服务2 | 被调服务2 | 接口1 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表5
结合图9，在主调服务节点1、主调服务2、被调服务节点3、被调服务1、接口2维度对应的分片监控数据的一个示例如下表6所示(为表示方便，使用xxx代表具体数值，其中每个表项的xxx可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
| 主调服务节点1 | 被调服务节点3 | 主调服务2 | 被调服务2 | 接口2 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表6
结合图9，在主调服务节点1、主调服务2、被调服务节点3、被调服务2、接口3维度对应的分片监控数据的一个示例如下表6所示(为表示方便，使用xxx代表具体数值，其中每个表项的xxx可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
| 主调服务节点1 | 被调服务节点3 | 主调服务2 | 被调服务2 | 接口3 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表7
结合图9，在主调服务节点1、主调服务2、被调服务节点3、被调服务2、接口4维度对应的分片监控数据的一个示例如下表8所示(为表示方便，使用xxx代表具体数值，其中每个表项的xxx可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
| 主调服务节点1 | 被调服务节点3 | 主调服务2 | 被调服务2 | 接口4 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表8
下面对利用上述的分片监控数据对获得不同维度的归并处理结果进行说明：
1)第一目标维度归并处理结果
第一目标维度包括主调业务模块ID和被调业务模块ID；
由于第一目标维度包括主调业务模块ID，且监控数据表征特征信息(包括调用成功次数、调用失败次数、调用延时)的维度至少包括主调服务节点ID，且如图9所示，主调业务模块包括至少一个主调服务节点，因此可以基于主调服务节点ID和主调业务模块ID的对应关系，将上述各表所示的分片监控数据中的主调服务节点维度转换为主调业务模块ID维度；
同时由于第一目标维度包括被调业务模块ID，分片监控数据表征特征信息(包括调用成功次数、调用失败次数、调用延时)的维度至少包括被调服务节点ID，且如图9所示，被调业务模块包括至少一个被调服务节点，基于被调服务节点ID和被调业务模块ID的对应关系，将所述分片监控数据中的被调服务节点维度转换为被调业务模块ID维度；
在图9中，由于主调服务节点1与主调业务模块1存在对应关系，被调服务节点3与被调业务模块2存在对应关系，对表1所示的分片监控数据进行维度转换后的处理结果如下表9所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务1 | 被调服务1 | 接口1 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表9
对表2所示的分片监控数据进行维度转换后的处理结果如下表10所示：
表10
对表3所示的分片监控数据进行维度转换后的处理结果如下表11所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务1 | 被调服务2 | 接口3 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表11
对表4所示的分片监控数据进行维度转换后的处理结果如下表12所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务1 | 被调服务2 | 接口4 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表12
对表5所示的分片监控数据进行维度转换后的处理结果如下表13所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务2 | 被调服务2 | 接口1 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表13
对表6所示的分片监控数据进行维度转换后的处理结果如下表14所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务2 | 被调服务2 | 接口2 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表14
对表7所示的分片监控数据进行维度转换后的处理结果如下表15所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务2 | 被调服务2 | 接口3 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表15
对表8所示的分片监控数据进行维度转换后的处理结果如下表16所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务2 | 被调服务2 | 接口4 | |
| 成功 | xxx | xxx | xxx | xxx | xxx |
| 失败 | xxx | xxx | xxx | xxx | xxx |
| 延时 | xxx | xxx | xxx | xxx | xxx |
表16
结合表9至表16所所示出的分片监控数据，将分片监控数据中对应特定主调业务模块ID和被调业务模块ID(以主调业务模块1和被调业务模块2为例)对应的特征信息(包括调用成功次数、调用失败次数、调用延时)进行收敛，直至收敛至主调业务模块ID维度和/或被调业务模块ID维度(以主调业务模块1和被调业务模块2为例时，第一目标维度对应收敛至主调业务模块1维度和被调业务模块2维度)；例如表9至表16示出的分片监控数据的调用成功次数、以及调用失败次数可以对应累加，而调用延时可以取累加值或平均值；得到表征主调业务模块1与被调业务模块2(对应第一目标维度)之间的特征信息的归并处理结果的一个示例如表17所示：
| 主调业务模块1 | 被调业务模块2 | |
| 成功率 | yyy | yyy |
| 延时 | yyy | yyy |
| 延时抖动 | yyy | yyy |
表17
为表示方便，使用yyy代表具体数值，其中每个表项的yyy可以代表不同的数值，成功表示调用成功次数，失败表示调用失败次数，延时表示调用延时)：
表17中的成功率为主调业务模块1调用被调业务模块2的成功率，延时可以为每次调用的平均延时(也可以采用延时的加和)；延时抖动表示每次调用延时相对平均调用延时的抖动。
2)第二目标维度归并处理结果
由于第二目标维度包括主调业务模块ID、被调业务模块ID、主调服务ID；与得到第一目标维度的归并处理结果类似，首先将表1至表8所示的分片监控数据转换至主调业务模块ID、被调业务模块ID维度，得到表9至表16所示的分片监控数据；
结合表9至表16所所示出的分片监控数据，将特定主调业务模块ID、被调业务模块ID、主调服务ID对应的特征信息(包括调用成功次数、调用失败次数、调用延时)进行收敛，直至收敛至主调业务模块ID维度、被调业务模块ID维度以及主调服务ID维度；例如表9至表16示出的分片监控数据的调用成功次数、以及调用失败次数可以对应累加，而调用延时可以取累加值或平均值；得到表征主调业务模块1、被调业务模块2、主调服务1(对应第二目标维度)之间的调用的特征信息的归并处理结果的一个示例如表18所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务1 | |
| 成功率 | yyy | yyy | yyy |
| 延时 | yyy | yyy | yyy |
| 延时抖动 | yyy | yyy | yyy |
表18
3)第三目标维度归并处理结果
第三目标维度包括主调服务ID、被调服务ID，可以直接将表1至表8所示的分片监控数据进行收敛，直至收敛至主调服务ID、被调服务ID维度；
结合表1至表8所所示出的分片监控数据，将相同的主调服务ID、被调服务ID(如主调服务1、被调服务2；或主调服务2、被调服务2)对应的特征信息(包括调用成功次数、调用失败次数、调用延时)进行收敛，直至收敛至主调服务ID维度以及被调服务ID维度；例如表1至表8示出的分片监控数据的调用成功次数、以及调用失败次数可以对应累加，而调用延时可以取累加值或平均值；得到表征主调服务1、被调服务1(对应第三目标维度)之间的调用的特征信息的归并处理结果的一个示例如表19所示：
| 主调服务1 | 被调服务2 | |
| 成功率 | yyy | yyy |
| 延时 | yyy | yyy |
| 延时抖动 | yyy | yyy |
表19
4)第四目标维度归并处理结果
由于第四目标维度包括主调服务ID、被调服务ID、被调服务接口ID；可以直接将表1至表8所示的分片监控数据进行收敛，直至收敛至主调服务ID、被调服务ID维度；
结合表1至表8所所示出的分片监控数据中具有相同的主调服务ID、被调服务ID、被调服务接口ID(如主调服务1、被调服务2、被调服务接口1)对应的特征信息(包括调用成功次数、调用失败次数、调用延时)进行收敛，直至收敛至主调服务ID维度、被调服务ID维度、被调服务接口ID维度；例如表1至表8示出的分片监控数据中主调服务1、被调服务1、被调服务接口1对应的特征信息如调用成功次数、以及调用失败次数可以对应累加，而调用延时可以取累加值或平均值；得到表征主调服务1通过被调服务接口1调用被调服务2(对应第四目标维度)之间的调用的特征信息的归并处理结果的一个示例如表20所示：
表20
5)第五目标维度归并处理结果
由于第五目标维度包括主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID；首先将表1至表8所示的分片监控数据转换至主调业务模块ID、被调业务模块ID维度，得到表9至表16所示的分片监控数据；基于表9至表16所示的分片监控数据基于相同的主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID进行收敛，直至收敛至主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID维度；
结合表9至表16所所示出的分片监控数据，将相同的主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID对应的特征信息(包括调用成功次数、调用失败次数、调用延时)进行收敛，直至收敛至主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID维度；例如基于相同的主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID将表9至表16示出的主调服务1以及被调服务1的分片监控数据的调用成功次数、以及调用失败次数可以对应累加，而调用延时可以取累加值或平均值；得到表征主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID(对应第五目标维度)之间的调用的特征信息的归并处理结果的一个示例如表21所示：
| 主调业务模块1 | 被调业务模块2 | 主调服务1 | 被调服务1 | 接口1 | |
| 成功 | yyy | yyy | yyy | yyy | yyy |
| 失败 | yyy | yyy | yyy | yyy | yyy |
| 延时 | yyy | yyy | yyy | yyy | yyy |
表21
本实施例中，采集承载社交应用的网络上报的监控数据包括服务节点维度(包括主调服务节点维度和被调服务节点维度)、服务维度(包括主调服务维度和被调服务维度)、被调服务接口维度；基于上述维度确定不同的目标维度，进而基于不同的目标维度对分片监控数据进行归并处理，由于采用了基于时间片对监控处理进行分片处理后进行不同目标维度的归并处理，实现了数据的实时处理，相较于相关技术提升了处理效率；并且，不同目标维度的归并处理结果能够从不同的角度表征网络在不同时间片的状态信息，从而便于基于不同目标维度的数据归并处理结果进行告警分析，进而实现故障的精确定位。
实施例二
本实施例基于实施例一，实际应用中，当得到分片监控数据的归并处理结果时，可以对基于不同目标维度(包括实施例一中所述的第一目标维度至第二目标维度)对应的告警策略对所得到的归并处理结果进行告警分析；
不同的目标维度对应有相应的告警策略，下面结合不同的目标维度进行说明：
1)第一目标维度
第一告警策略用于设定主调业务模块与被调业务模块的成功率(与成功次数、失败次数对应)、延时对应的阈值(最大值)、延时抖动；在实施例中，可以基于特定时间段(如一天、一周或一月)对应的监控数据进行分片得到分片数据，并基于分片监控数据进行归并处理得到第一目标维度的归并处理结果，包括主调业务模块调用被调业务模块的成功率、延时、延时抖动等信息，当归并处理结果满足第一告警策略时，表征监控数据满足告警策略，从而发出告警；
以图9为例，结合表17基于分片监控数据进行归并处理的归并处理结果也即主调业务模块1与被调业务模块2之间的特征信息的归并处理结果，包括主调业务模块1调用被调业务模块2的成功率、延时、延时抖动，当主调业务模块1调用被调业务模块2的成功率、延时、延时抖动超均出第一告警策略中约定的对应的阈值时，表明主调业务模块1与被调业务模块2之间的调用出现问题，可以发出告警。
2)第二目标维度
第二告警策略用于设定主调业务模块ID、被调业务模块ID、主调服务ID维度的成功率(与成功次数、失败次数对应)、延时对应的阈值(最大值)、延时抖动；在实施例中，可以基于特定时间段(如一天、一周或一月)对应的监控数据进行分片得到分片数据，并基于分片监控数据进行归并处理得到第二目标维度的归并处理结果，包括主调业务模块中的主调服务调用被调业务模块的成功率、延时、延时抖动等信息，当归并处理结果满足第二告警策略时，表征监控数据满足告警策略，从而发出告警；
以图9为例，结合表18基于分片监控数据进行归并处理的归并处理结果也即主调业务模块1中的主调服务1与被调业务模块2之间的特征信息的归并处理结果，包括主调业务模块1调用被调业务模块2的成功率、延时、延时抖动，当主调业务模块1中运行的主调服务1调用被调业务模块2的成功率、延时、延时抖动超均出第二告警策略中设定的对应的阈值时，表明主调业务模块1中的主调服务1与被调业务模块2之间的调用出现问题，可以发出告警。
3)第三目标维度
第三告警策略用于设定主调服务ID、被调服务ID维度的成功率(与成功次数、失败次数对应)、延时对应的阈值(最大值)、延时抖动；在实施例中，可以基于特定时间段(如一天、一周或一月)对应的监控数据进行分片得到分片数据，并基于分片监控数据进行归并处理得到第三目标维度的归并处理结果，包括主调服务调用被调服务的成功率、延时、延时抖动等信息，当归并处理结果满足第三告警策略时，表征监控数据满足告警策略，从而发出告警；
以图9为例，结合表19基于分片监控数据进行归并处理的归并处理结果也即主调服务1与被调服务2之间的特征信息的归并处理结果，包括主调服务1调用被调服务2的成功率、延时、延时抖动，当主调服务1调用被调服务2的成功率、延时、延时抖动超均出第三告警策略中设定的对应的阈值时，表明主调服务1与被调服务2之间的调用出现问题，可以发出告警。
4)第四目标维度
第四告警策略用于设定主调服务ID、被调服务ID、被调服务接口ID维度的成功率(与成功次数、失败次数对应)、延时对应的阈值(最大值)、延时抖动；在实施例中，可以基于特定时间段(如一天、一周或一月)对应的监控数据进行分片得到分片数据，并基于分片监控数据进行归并处理得到第四目标维度的归并处理结果，包括主调服务通过特定被调服务接口(以被调服务接口ID标识)调用被调服务的成功率、延时、延时抖动等信息，当归并处理结果满足第四告警策略时，表征监控数据满足告警策略，从而发出告警；
以图9为例，结合表20基于分片监控数据进行归并处理的归并处理结果也即主调业务模块1、被调业务模块2、被调服务接口1维度的分片监控数据的归并处理结果，包括主调服务1通过被调服务接口1调用被调服务2的成功率、延时、延时抖动，当主调服务1通过被调服务接口1调用被调服务2的成功率、延时、延时抖动超均出第四告警策略中设定的对应的阈值时，表明主调业务1通过被调服务接口1调用被调服务2出现问题，可以发出告警。
5)第五目标维度
第四告警策略用于设定主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID的成功率(与成功次数、失败次数对应)、延时对应的阈值(最大值)、延时抖动；在实施例中，可以基于特定时间段(如一天、一周或一月)对应的监控数据进行分片得到分片数据，并基于分片监控数据进行归并处理得到第五目标维度的归并处理结果，包括主调业务模块中的主调服务通过特定被调服务接口(以被调服务接口ID标识)调用特定被调业务模块中的特定被调服务的成功率、延时、延时抖动等信息，当归并处理结果满足第五告警策略时，表征监控数据满足告警策略，从而发出告警；
以图9为例，结合表21基于分片监控数据进行归并处理的归并处理结果也即主调业务模块1、主调服务1、被调业务模块2、被调服务1、被调服务接口1维度的分片监控数据的归并处理结果，包括主调业务模块1中的主调服务1通过被调服务接口1调用被调业务模块1中的被调服务1的成功率、延时、延时抖动，当主调业务模块1中的主调服务1通过被调服务接口1调用被调业务模块1中的被调服务1的成功率、延时、延时抖动超均出第五告警策略中设定的对应的阈值时，表明主调业务模块1中的主调服务1通过被调服务接口1调用被调业务模块1中的被调服务1出现问题，可以发出告警。
本实施例中基于不同目标维度的告警策略对分片监控数据的归并处理结果进行告警分析，能够使运维人员准确确定承载社交应用的网络中的哪一层拓扑结构发生问题，例如是业务模块拓扑层面发生问题，还是某一个服务的接口出现问题，便于及时排除故障，确保承载社交应用的网络的稳定性。
实施例三
本实施例基于实施例二，对承载社交应用的功能的网络中的故障定位进行说明。
以图9为例，在第二目标维度，当主调业务模块1中的主调服务1与被调业务模块2之间的特征信息的归并处理结果，包括主调业务模块1调用被调业务模块2的成功率、延时、延时抖动，均超出第二告警策略中设定的对应的阈值时，可能会导致在第一目标维度，主调业务模块1与被调业务模块2之间的特征信息的归并处理结果，包括主调业务模块1调用被调业务模块2的成功率、延时、延时抖动，当主调业务模块1调用被调业务模块2的成功率、延时、延时抖动超均出第一告警策略中约定的对应的阈值；也就是说，在实施例二中第一目标维度的告警具体是由第二目标维度的调用出现问题(故障)导致，因此，实际应用中可以只针对第二目标维度进行告警，以指示故障出现在第二目标维度。
例如，当基于第N目标维度确定特定时间(如一天、一周或一月)的对应的分片监控数据的归并处理结果超出第N目标维度对应的告警策略设定的告警阈值时，基于预设的目标维度的优先级排序，按照N+1、N+2···N+m维度的顺序开始定位故障所在的维度(也就是说，m依次从首项为1、公差为1的正整数等差序列中取值)，直至第N+m目标维度对应的分片监控数据的归并处理结果未超出所述第N+m目标维度对应的告警阈值，第N+m+1目标维度对应的分片监控数据的归并处理结果超出第N+m+1目标维度对应的告警阈值，那么N+m+1维度为发生故障的最底层维度；其中，N取值为正整数，m依次从首项为1、公差为1的正整数等差序列中取值。
目标维度的优先级排序采用前述的第一目标维度至第五目标维度的排序，发明人在实施本发明的过程中发现，采用下述的目标维度优先级排序可以快速定位故障：
第一目标维度：主调业务模块ID、被调业务模块ID；
第二目标维度：主调业务模块ID、被调业务模块ID、主调服务ID；
第三目标维度：主调服务ID、被调服务ID；
第四目标维度：主调服务ID、被调服务ID、被调服务接口ID；
第五目标维度：主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID。
结合图9，当利用第一告警策略分析第一目标维度的归并处理结果确定第一目标维度的归并处理结果满足告警条件(也即主调业务模块1和被调业务模块2之间的调用出现问题)时，继续利用第二目标告警策略分析第二目标维度的归并处理结果，以确定是主调服务节点中的哪个主调服务调用与被调业务模块之间的调用出现问题(图9中示出了主调业务模块1中的主调服务1和主调服务2调用被调业务模块2)；
这里，设基于第二目标维度的归并处理结果，确定主调服务节点1中的主调和被调服务节点3之间的调用告警条件(也即主调业务模块1中的主调服务1与被调业务模块2之间的特征信息的归并处理结果，包括主调业务模块1调用被调业务模块2的成功率、延时、延时抖动，均超出第二告警策略中设定的对应的阈值)；
那么，在第三目标维度，基于第三告警策略以及第三目标维度的归并处理结果(包括主调服务1与被调服务1、2的调用的特征信息的归并处理结果，以及主调服务2与被调服务1、2之间的特征信息归并处理结果)，分析主调服务节点1的哪个主调服务1和被调服务节点3的哪个被调服务之间的调用出现问题，例如当主调服务1与被调服务1、2之间的调用均出现问题(调用的特征信息的归并处理结果满足第三告警策略设定的告警条件)，则确定主调服务1自身出现问题；
如果主调服务1与被调服务1之间的调用未出现问题，而主调服务1与被调服务2之间的调用出现问题，则需要在第四目标维度利用主调服务1通过接口3、4调用被调服务2的特征信息的归并处理结果(也即第四目标维度的归并处理结果)，判断被调服务2的哪个接口出现问题；当主调服务1通过接口3调用被调服务2的特征信息的归并处理结果满足第四告警策略设定的告警条件时，表明被调服务2的接口3出现故障；
由于被调服务2可能运行于多个被调业务模块中，因此当被调服务2的接口3出现故障时，还可以基于第五目标维度的归并处理结果，判断仅仅是被调业务模块2的被调服务2的接口3出现故障，还是所有被调业务模块的被调服务2的接口3出现故障，从而实现故障准确定位。
实施例四
本实施例记载一种计算机可读介质，可以为ROM(例如，只读存储器、FLASH存储器、转移装置等)、磁存储介质(例如，磁带、磁盘驱动器等)、光学存储介质(例如，CD-ROM、DVD-ROM、纸卡、纸带等)以及其他熟知类型的程序存储器；所述计算机可读介质中存储有计算机可执行指令，当执行所述指令时，引起至少一个处理器执行包括以下的操作：
获取服务节点之间进行访问的监控数据，所述监控数据从至少一个维度表征所述服务节点之间、以及所述服务节点的服务之间进行访问的特征信息；
基于所述监控数据的上报时间将所述监控数据进行分片处理，得到分片监控数据，分片处理时所使用的时间片的大小基于监控的实时性要求确定；
确定目标维度，所述目标维度包括所述维度至少之一；
基于所述目标维度对所述分片监控数据进行归并处理，得到所述目标维度的分片监控数据的归并处理结果。
作为一个实施方式，当执行所述指令时，还引起至少一个处理器执行包括以下的操作：
所述目标维度包括主调业务模块ID，基于主调服务节点ID和主调业务模块ID的对应关系，将所述分片监控数据中的主调服务节点维度转换为主调业务模块ID维度，所述监控数据表征所述特征信息的维度至少包括主调服务节点ID，所述主调业务模块包括至少一个主调服务节点。
作为一个实施方式，当执行所述指令时，还引起至少一个处理器执行包括以下的操作：
所述目标维度包括被调业务模块ID，基于被调服务节点ID和被调业务模块ID的对应关系，将所述分片监控数据中的被调服务节点维度转换为被调业务模块ID维度，所述监控数据表征所述特征信息的维度至少包括被调服务节点ID，所述被调业务模块包括至少一个被调服务节点。
作为一个实施方式，当执行所述指令时，还引起至少一个处理器执行包括以下的操作：
基于目标维度对所述分片监控数据进行归并处理，得到所述目标维度的监控数据的归并处理结果，包括：
至少基于主调业务模块ID维度和/或被调业务模块ID维度，对特定时间对应的分片监控数据进行收敛，直至，
所述特定时间对应的分片监控数据收敛至主调业务模块ID维度和/或被调业务模块ID维度，对应得到主调业务模块ID维度和/或被调业务模块ID维度对应的归并处理结果，所述归并处理结果包括成功率、延时和延时抖动至少之一，所述特征信息包括成功次数、失败次数和延时至少之一。
作为一个实施方式，当执行所述指令时，还引起至少一个处理器执行包括以下的操作：
基于所述目标维度对应的告警策略对所得到的归并处理结果进行告警分析；
当分析结果表征归并处理结果超出对应的阈值时发出告警信息。
作为一个实施方式，当执行所述指令时，还引起至少一个处理器执行包括以下的操作：
当基于第N目标维度确定特定时间的对应的分片监控数据的归并处理结果超出所述第N目标维度对应的告警阈值时，基于预设的目标维度的优先级排序，确定第N+m目标维度；
其中，所述第N+m目标维度对应的分片监控数据的归并处理结果未超出所述第N+m目标维度对应的告警阈值，第N+m+1目标维度对应的分片监控数据的归并处理结果超出第N+m+1目标维度对应的告警阈值，N取值为正整数，m依次从首项为1、公差为1的正整数等差序列中取值。
作为一个实施方式，所述预设的目标维度的优先级排序为：
第一目标维度：主调业务模块ID、被调业务模块ID；
第二目标维度：主调业务模块ID、被调业务模块ID、主调服务ID；
第三目标维度：主调服务ID、被调服务ID；
第四目标维度：主调服务ID、被调服务ID、被调服务接口ID；
第五目标维度：主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID。
实施例五
本实施例记载一种数据处理装置，如图10所示，包括：
接收单元10，用于获取服务节点之间进行访问的监控数据，所述监控数据从至少一个维度表征所述服务节点之间、以及所述服务节点的服务之间进行访问的特征信息；
格式化单元20，用于基于所述监控数据的上报时间将所述监控数据进行分片处理，得到分片监控数据，分片处理时所使用的时间片的大小基于监控的实时性要求确定；
归并单元30，用于确定目标维度，所述目标维度包括所述维度至少之一；
归并单元30，还用于基于所述目标维度对所述分片监控数据进行归并处理，得到所述目标维度的分片监控数据的归并处理结果。
作为一个实施方式，所述装置还包括：
第一翻译单元40，用于基于主调服务节点ID和主调业务模块ID的对应关系将所述分片监控数据中的主调服务节点维度转换为主调业务模块ID维度，所述监控数据表征所述特征信息的维度至少包括主调服务节点ID，所述主调业务模块包括至少一个主调服务节点，所述目标维度包括主调业务模块ID，。
作为一个实施方式，所述装置还包括：
第二翻译单元50，用于基于被调服务节点ID和被调业务模块ID的对应关系，将所述分片监控数据中的被调服务节点维度转换为被调业务模块ID维度，所述监控数据表征所述特征信息的维度至少包括被调服务节点ID，所述被调业务模块包括至少一个被调服务节点，所述目标维度包括被调业务模块ID。
作为一个实施方式，所述归并单元30，用于至少基于主调业务模块ID维度和/或被调业务模块ID维度，对特定时间对应的分片监控数据进行收敛，直至，
所述特定时间对应的分片监控数据收敛至主调业务模块ID维度和/或被调业务模块ID维度，对应得到主调业务模块ID维度和/或被调业务模块ID维度对应的归并处理结果，所述归并处理结果包括成功率、延时和延时抖动至少之一，所述特征信息包括成功次数、失败次数和延时至少之一。
作为一个实施方式，所述装置还包括：
分析单元60，用于基于所述目标维度对应的告警策略对所得到的归并处理结果进行告警分析；
告警单元70，用于当所述分析单元得到的分析结果表征归并处理结果超出对应的阈值时发出告警信息。
作为一个实施方式，所述归并单元30，还用于当基于第N目标维度确定特定时间的对应的分片监控数据的归并处理结果超出所述第N目标维度对应的告警阈值时，基于预设的目标维度的优先级排序，确定第N+m目标维度；
其中，所述第N+m目标维度对应的分片监控数据的归并处理结果未超出所述第N+m目标维度对应的告警阈值，N取值为正整数，m依次从首项为1、公差为1的正整数等差序列中取值。
作为一个实施方式，所述预设的目标维度的优先级排序为：
第一目标维度：主调业务模块ID、被调业务模块ID；
第二目标维度：主调业务模块ID、被调业务模块ID、主调服务ID；
第三目标维度：主调服务ID、被调服务ID；
第四目标维度：主调服务ID、被调服务ID、被调服务接口ID；
第五目标维度：主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID。
实际应用中上述单元可以服务器集群的计算资源和网络资源实现，服务器集群可以使用Storm集群技术部署，一个示例如图11所示，接收单元10可以由Storm集群中的接收机实现，格式化单元20可由Storm集群中的发射节点(Spout)实现，翻译单元(包括第一翻译单元40和第二翻译单元50)可与Storm集群中的由Bolt实现的接入节点对应，归并单元30可与Storm集群中的由Bolt实现的翻译节点对应，分析单元60可与Storm集群中的由Bolt实现的统计节点对应，告警单元70可与Storm集群中的由Bolt实现的告警节点对应，图11中Storm每个节点的线程树仅为示例，实际应用中基于数据处理量确定。
本实施例中，采集承载社交应用的网络上报的监控数据包括服务节点维度(包括主调服务节点维度和被调服务节点维度)、服务维度(包括主调服务维度和被调服务维度)、被调服务接口维度；基于上述维度确定不同的目标维度，进而基于不同的目标维度对分片监控数据进行归并处理，由于采用了基于时间片对监控处理进行分片处理后进行不同目标维度的归并处理，实现了数据的实时处理，相较于相关技术提升了处理效率；并且，不同目标维度的归并处理结果能够从不同的角度表征网络在不同时间片的状态信息，从而便于基于不同目标维度的数据归并处理结果进行告警分析，进而实现故障的精确定位。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、随机存取存储器(RAM，Random Access Memory)、只读存储器(ROM，Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、RAM、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。
Claims (14)
1.一种数据处理方法，其特征在于，所述方法包括：
获取服务节点之间进行访问的监控数据，所述监控数据从至少一个维度表征所述服务节点之间、以及所述服务节点的服务之间进行访问的特征信息；
基于所述监控数据的上报时间将所述监控数据进行分片处理，得到分片监控数据，分片处理时所使用的时间片的大小基于监控的实时性要求确定；
确定目标维度，所述目标维度包括所述维度至少之一；
基于所述目标维度对所述分片监控数据进行归并处理，得到所述目标维度的分片监控数据的归并处理结果。
2.如权利要求1所述的方法，其特征在于，所述方法还包括：
所述目标维度包括主调业务模块ID，基于主调服务节点ID和主调业务模块ID的对应关系，将所述分片监控数据中的主调服务节点维度转换为主调业务模块ID维度，所述监控数据表征所述特征信息的维度至少包括主调服务节点ID，所述主调业务模块包括至少一个主调服务节点。
3.如权利要求1所述的方法，其特征在于，所述方法还包括：
所述目标维度包括被调业务模块ID，基于被调服务节点ID和被调业务模块ID的对应关系，将所述分片监控数据中的被调服务节点维度转换为被调业务模块ID维度，所述监控数据表征所述特征信息的维度至少包括被调服务节点ID，所述被调业务模块包括至少一个被调服务节点。
4.如权利要求2或3所述的方法，其特征在于，基于目标维度对所述分片监控数据进行归并处理，得到所述目标维度的监控数据的归并处理结果，包括：
至少基于主调业务模块ID维度和/或被调业务模块ID维度，对特定时间对应的分片监控数据进行收敛，直至，
所述特定时间对应的分片监控数据收敛至主调业务模块ID维度和/或被调业务模块ID维度，对应得到主调业务模块ID维度和/或被调业务模块ID维度对应的归并处理结果，所述归并处理结果包括成功率、延时和延时抖动至少之一，所述特征信息包括成功次数、失败次数和延时至少之一。
5.如权利要求1所述的方法，其特征在于，所述方法还包括：
基于所述目标维度对应的告警策略对所得到的归并处理结果进行告警分析；
当分析结果表征归并处理结果超出对应的阈值时发出告警信息。
6.如权利要求1所述的方法，其特征在于，所述方法还包括：
当基于第N目标维度确定特定时间的对应的分片监控数据的归并处理结果超出所述第N目标维度对应的告警阈值时，基于预设的目标维度的优先级排序，确定第N+m目标维度；
其中，所述第N+m目标维度对应的分片监控数据的归并处理结果未超出所述第N+m目标维度对应的告警阈值，第N+m+1目标维度对应的分片监控数据的归并处理结果超出第N+m+1目标维度对应的告警阈值，N取值为正整数，m依次从首项为1、公差为1的正整数等差序列中取值。
7.如权利要求6所述的方法，其特征在于，所述预设的目标维度的优先级排序为：
第一目标维度：主调业务模块ID、被调业务模块ID；
第二目标维度：主调业务模块ID、被调业务模块ID、主调服务ID；
第三目标维度：主调服务ID、被调服务ID；
第四目标维度：主调服务ID、被调服务ID、被调服务接口ID；
第五目标维度：主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID。
8.一种数据处理装置，其特征在于，所述装置包括：
接收单元，用于获取服务节点之间进行访问的监控数据，所述监控数据从至少一个维度表征所述服务节点之间、以及所述服务节点的服务之间进行访问的特征信息；
格式化单元，用于基于所述监控数据的上报时间将所述监控数据进行分片处理，得到分片监控数据，分片处理时所使用的时间片的大小基于监控的实时性要求确定；
归并单元，用于确定目标维度，所述目标维度包括所述维度至少之一；
所述归并单元，还用于基于所述目标维度对所述分片监控数据进行归并处理，得到所述目标维度的分片监控数据的归并处理结果。
9.如权利要求8所述的装置，其特征在于，所述装置还包括：
第一翻译单元，用于基于主调服务节点ID和主调业务模块ID的对应关系将所述分片监控数据中的主调服务节点维度转换为主调业务模块ID维度，所述监控数据表征所述特征信息的维度至少包括主调服务节点ID，所述主调业务模块包括至少一个主调服务节点，所述目标维度包括主调业务模块ID。
10.如权利要求8所述的装置，其特征在于，所述装置还包括：
第二翻译单元，用于基于被调服务节点ID和被调业务模块ID的对应关系，将所述分片监控数据中的被调服务节点维度转换为被调业务模块ID维度，所述监控数据表征所述特征信息的维度至少包括被调服务节点ID，所述被调业务模块包括至少一个被调服务节点，所述目标维度包括被调业务模块ID。
11.如权利要求9或10所述的装置，其特征在于，
所述归并单元，用于至少基于主调业务模块ID维度和/或被调业务模块ID维度，对特定时间对应的分片监控数据进行收敛，直至，
所述特定时间对应的分片监控数据收敛至主调业务模块ID维度和/或被调业务模块ID维度，对应得到主调业务模块ID维度和/或被调业务模块ID维度对应的归并处理结果，所述归并处理结果包括成功率、延时和延时抖动至少之一，所述特征信息包括成功次数、失败次数和延时至少之一。
12.如权利要求8所述的装置，其特征在于，所述装置还包括：
分析单元，用于基于所述目标维度对应的告警策略对所得到的归并处理结果进行告警分析；
告警单元，用于当所述分析单元得到的分析结果表征归并处理结果超出对应的阈值时发出告警信息。
13.如权利要求8所述的装置，其特征在于，
所述归并单元，还用于当基于第N目标维度确定特定时间的对应的分片监控数据的归并处理结果超出所述第N目标维度对应的告警阈值时，基于预设的目标维度的优先级排序，确定第N+m目标维度；
其中，所述第N+m目标维度对应的分片监控数据的归并处理结果未超出所述第N+m目标维度对应的告警阈值，第N+m+1目标维度对应的分片监控数据的归并处理结果超出第N+m+1目标维度对应的告警阈值，N取值为正整数，m依次从首项为1、公差为1的正整数等差序列中取值。
14.如权利要求13所述的装置，其特征在于，所述预设的目标维度的优先级排序为：
第一目标维度：主调业务模块ID、被调业务模块ID；
第二目标维度：主调业务模块ID、被调业务模块ID、主调服务ID；
第三目标维度：主调服务ID、被调服务ID；
第四目标维度：主调服务ID、被调服务ID、被调服务接口ID；
第五目标维度：主调业务模块ID、被调业务模块ID、主调服务ID、被调服务ID、被调服务接口ID。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510180705.0A CN106034047B (zh) | 2015-04-16 | 2015-04-16 | 数据处理方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510180705.0A CN106034047B (zh) | 2015-04-16 | 2015-04-16 | 数据处理方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106034047A CN106034047A (zh) | 2016-10-19 |
| CN106034047B true CN106034047B (zh) | 2019-07-16 |
Family
ID=57149069
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510180705.0A Active CN106034047B (zh) | 2015-04-16 | 2015-04-16 | 数据处理方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106034047B (zh) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106844042B (zh) * | 2016-12-29 | 2024-06-18 | 全球能源互联网研究院有限公司 | 电力ip多媒体子系统网络的数据处理方法以及处理装置 |
| CN107092649B (zh) * | 2017-03-13 | 2021-04-06 | 浙江工业大学 | 一种面向实时流计算的无感知拓扑替换方法 |
| CN108881415B (zh) * | 2018-05-31 | 2020-11-17 | 广州亿程交通信息集团有限公司 | 分布式实时大数据分析系统 |
| CN110971916B (zh) * | 2018-09-28 | 2022-02-08 | 武汉斗鱼网络科技有限公司 | 一种直播流畅度监控方法及系统 |
| CN114629768A (zh) * | 2022-02-17 | 2022-06-14 | 亚信科技（南京）有限公司 | 应用拓扑的处理方法、装置、电子设备、存储介质及产品 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102231673A (zh) * | 2011-05-31 | 2011-11-02 | 北京京东世纪贸易有限公司 | 用于监控业务服务器的系统和方法 |
| CN102307116A (zh) * | 2011-05-31 | 2012-01-04 | 北京京东世纪贸易有限公司 | 用于生成监控信息的系统和方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150085870A1 (en) * | 2013-09-25 | 2015-03-26 | Cisco Technology, Inc. | Co-operative load sharing and redundancy in distributed service chains in a network environment |
-
2015
- 2015-04-16 CN CN201510180705.0A patent/CN106034047B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102231673A (zh) * | 2011-05-31 | 2011-11-02 | 北京京东世纪贸易有限公司 | 用于监控业务服务器的系统和方法 |
| CN102307116A (zh) * | 2011-05-31 | 2012-01-04 | 北京京东世纪贸易有限公司 | 用于生成监控信息的系统和方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106034047A (zh) | 2016-10-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106034047B (zh) | 数据处理方法及装置 | |
| Coutinho et al. | Elasticity in cloud computing: a survey | |
| CN112162865B (zh) | 服务器的调度方法、装置和服务器 | |
| CN105376100B (zh) | 一种适用于云平台资源监控的分布式告警规则评估方法 | |
| CN110232010A (zh) | 一种告警方法、告警服务器及监控服务器 | |
| Picoreti et al. | Multilevel observability in cloud orchestration | |
| CN114500250B (zh) | 一种云模式下体系联动的综合运维系统及方法 | |
| CN103716173B (zh) | 一种存储监控系统及监控告警发布的方法 | |
| CN106533806B (zh) | 多租户SDN网络中基于应用感知提供跨层QoS的方法 | |
| US11190431B2 (en) | Prioritized client-server communications based on server health | |
| CN104468819A (zh) | 一种物联网消息推送系统及其方法 | |
| WO2017080161A1 (zh) | 云计算中报警信息的处理方法及装置 | |
| CN113259355B (zh) | 一种基于sdn的工业互联网标识切片管理系统 | |
| US9535749B2 (en) | Methods for managing work load bursts and devices thereof | |
| CN111124830B (zh) | 一种微服务的监控方法及装置 | |
| CN103236948A (zh) | 一种电信网告警方法及系统 | |
| CN102929773A (zh) | 信息采集方法和装置 | |
| CN107579858A (zh) | 云主机的告警方法及装置、通信系统 | |
| CN110740061A (zh) | 故障预警方法、装置及计算机存储介质 | |
| CN106789270A (zh) | 一种信息系统集中运维管理的实现方法及系统 | |
| CN108234189B (zh) | 一种告警数据处理方法和装置 | |
| Simoncelli et al. | Stream-monitoring with blockmon: convergence of network measurements and data analytics platforms | |
| CN104063560B (zh) | 基于云计算平台的调度系统及调度方法 | |
| CN111190875A (zh) | 基于容器平台的日志聚合方法及装置 | |
| Colombo et al. | Towards self-adaptive peer-to-peer monitoring for fog environments |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20190809 Address after: 518000 Nanshan District science and technology zone, Guangdong, Zhejiang Province, science and technology in the Tencent Building on the 1st floor of the 35 layer Co-patentee after: Tencent cloud computing (Beijing) limited liability company Patentee after: Tencent Technology (Shenzhen) Co., Ltd. Address before: Shenzhen Futian District City, Guangdong province 518000 Zhenxing Road, SEG Science Park 2 East Room 403 Patentee before: Tencent Technology (Shenzhen) Co., Ltd. |