CN103118051B - 一种对信息发布过程进行监控的方法和设备 - Google Patents

Abstract

本申请公开了一种对信息发布过程进行监控的方法和设备，主要内容包括：监控设备在接收到信息创建触发消息时，确定待发布信息的标识以及确定待发布信息在发布过程中产生监控数据的后台服务器，在所述信息的发布过程中，监控设备利用所述信息标识，从确定的后台服务器中采集所述的监控数据，并利用预设异常判定条件与监控数据的属性信息的对应关系，对采集的监控数据进行判定，进而确定出信息发布过程中出现的异常情况，本申请实施例是监控设备根据实际需求主动采集监控数据并实时对采集的监控数据进行分析，避免了事后分析的滞后性，且监控设备利用异常判定条件实时对每条采集到的监控数据进行判定，可准确、及时地定位信息发布过程中的异常情况。

Description

一种对信息发布过程进行监控的方法和设备

技术领域

本申请涉及互联网信息处理技术领域，尤其涉及一种对信息发布过程进行监控的方法和设备。

背景技术

在目前的监控系统中，绝大部分监控系统是对监控对象所产生的监控数据进行采集与记录，如果需要对监控对象的运行状态进行评估，一般是在监控系统采集与记录监控数据后，由人工手动的方式对该监控数据进行分析、评估，具体地，可由人工手动的方式将监控数据以数据列表、图表和日志信息等离散型监控方式进行分析，通过多个数据列表、图表和日志信息的分析，来推导出所监控对象在运行过程中的实际状态。

由于信息发布是一种有生命周期特征(创建信息、信息发布、信息发布结束)且具有连续性、多变性和关联性的业务，因此，以信息发布过程的监控为例来反映现有的对监控对象的监控过程。

如图1所示，其为现有技术中对信息发布过程进行监控的方法流程图，具体包括以下步骤：

步骤101：信息发布服务器创建一待发布信息，并以网页的形式发布该信息。

在创建待发布信息时，信息发布服务器为该信息分配一个具有全局唯一性的标识。

步骤102：监控服务器在接收到人工手动方式输入的采集指令后，根据该采集指令中包含的所述分配的标识，采集发布信息过程中产生的包含该标识的监控数据。

步骤103：通过人工手动方式对采集到的监控数据进行分析。

例如：采集的监控数据可以是信息发布过程中产生的日志信息，通过对日志信息内容的分析，确定该信息在发布过程中某一时刻的发布状态，如：发布信息的页面的显示状态、一段时间内访问该页面的用户数量、发布该信息所产生的资源消耗、发布该信息所产生的费用等。

步骤104：通过人工手动方式对分析结果进行整理，生成信息发布过程最终的效果数据列表(例如：查看发布信息的页面和点击发布信息的页面的列表，资源消耗列表，以及费用详单等)反馈至查询数据平台，以供其他有需要的用户进行查询。

由此可见，现有的对信息发布过程的监控方法只能根据采集指令进行数据的采集，采用事后(如24小时以后)人工手动方式统计分析监控数据的方式进行监控，其监控效率低，且也降低了数据的真实可靠性；另外，若信息发布过程中出现异常情况，现有的监控方法只能通过技术人员根据采集到的监控数据利用专业知识进行分析时发现，或是在出现异常后由用户举报后发现，针对第一种发现异常的方案，有明显的滞后性，不能准确、及时地定位异常，针对第二种发现异常的方案，除了有滞后性外，还由于需要用户来发现异常并进行上报，将会导致用户体验下降，进而影响信息发布的效果。

以广告信息发布为例，在现有的监控过程中，从广告发布者创建广告信息到广告信息发布结束这一过程中，所产生的监控数据都是由广告发布技术人员对其进行分析、整理的，假设某一时刻浏览页面的用户点击发布的该广告信息页面时，出现页面跳转失败的异常，但相应的统计系统对本次点击操作进行了扣费，因此，采集的监控数据的内容可以反映出本次页面跳转失败的异常以及扣费异常，但是，由于广告信息发布过程产生的监控数据的数据量非常巨大，甚至到达数以百万计，通过事后(如24小时以后)的人工手动方式，是很难从海量的监控数据中查找出内容异常的监控数据，导致异常不能准确、及时地定位，为信息发布过程带来安全隐患。

发明内容

本申请的目的在于，提供了一种对信息发布过程进行监控的方法和设备，用以解决现有技术中监控系统不能准确、及时发现监控过程中出现的异常情形的问题。

一种对信息发布过程进行监控的方法，该方法包括：

在接收到信息创建触发消息时，确定待发布信息的标识，以及确定该待发布信息在发布过程中产生监控数据的至少一台后台服务器；

在所述信息的发布期结束前，利用所述信息的标识，从确定的后台服务器中采集该信息在发布过程中产生的监控数据；

利用预设的异常判定条件，对采集的监控数据进行监控，确定信息在发布过程出现的异常。

一种监控设备，该设备包括：

接收模块，用于接收信息创建触发消息；

确定模块，用于确定待发布信息的标识，以及确定该待发布信息在发布过程中产生监控数据的至少一台后台服务器；

采集模块，用于在所述信息的发布期结束前，利用所述信息的标识，从确定的后台服务器中采集该信息在发布过程中产生的监控数据；

监控模块，用于利用预设的异常判定条件，对采集的监控数据进行监控，确定信息在发布过程出现的异常。

本申请有益效果如下：

本申请实施例监控设备在接收到信息创建触发消息时，确定待发布信息的标识以及确定待发布信息在发布过程中产生监控数据的至少一台后台服务器，在所述信息的发布过程中，监控设备利用所述信息标识，从确定的后台服务器中采集所述的监控数据，并利用预设异常判定条件与监控数据的属性信息的对应关系，对采集的监控数据进行判定，进而确定出信息发布过程中出现的异常情况，使得信息发布过程中出现的异常情况能够准确、及时地定位。

附图说明

图1为现有技术中对信息发布过程进行监控的方法流程图；

图2为本申请实施例一中一种对信息发布的过程进行监控的方法流程图；

图3为所述广告信息在发布过程中，监控设备采集并存储产生的监控数据的示意图；

图4为针对图(3)监控设备对采集到的监控数据进行分析和整合后的结果展示图；

图5为所述广告信息在发布过程中出现异常，监控设备采集并存储产生的监控数据的示意图；

图6为针对图(5)监控设备对采集到的监控数据进行分析和整合后的结果展示图；

图7为本实施例三的一种监控设备的结构示意图。

具体实施方式

为了实现本申请目的，本申请实施例在接收到信息创建触发消息时，由监控设备确定待发布信息的标识以及确定待发布信息在发布过程中产生监控数据的至少一台后台服务器，在所述信息的发布过程中，监控设备利用所述信息标识，从确定的后台服务器中采集所述的监控数据，并利用预设异常判定条件与监控数据的属性信息的对应关系，对采集的监控数据进行判定，进而确定出信息发布过程中出现的异常情况，由于本申请实施例中是监控设备根据实际需求主动采集监控数据并实时对采集的监控数据进行分析，避免了事后分析的滞后性，且监控设备利用异常判定条件可实时对每条采集到的监控数据进行异常判定，可准确、及时地定位出信息发布过程中的异常情况。

下面结合说明书附图对本申请实施例的方案进行详细描述。

实施例一：

如图2所示，其为本申请实施例一中一种对信息发布的过程进行监控的方法流程图，该监控方法包括以下步骤：

步骤201：信息发布平台创建待发布信息。

本实施例中的信息发布平台可对外提供输入输出接口，在该信息发布平台上注册并登陆的信息发布者，可通过该输入输出接口向信息发布平台发起创建请求，在所述创建请求中可携带信息发布者的用户信息、发布开始时间、发布持续时间、发布内容(如文字信息、图片信息、音视频信息等)、发布名称等。

信息发布平台可对接收到的创建请求中发布内容的合法性进行认证，如利用黑名单中关键字的方式对发布内容的合法性进行认证。

在对发布内容的合法性认证通过后，信息发布平台为该信息发布者的本次发布过程分配一个全局唯一的标识。

信息发布平台可将该分配的标识通过输入输出接口向信息发布者输出，以便于信息发布者后续可利用该标识对该信息发布过程进行查询，也可将该标识与创建请求中的用户信息、发布名称之间建立对应关系，使得信息发布者后续可利用用户信息和发布名称对该信息发布过程进行查询。

信息发布平台根据所述创建请求中的发布内容、发布名称等创建待发布信息，并在创建待发布信息后，通过创建请求响应通知信息发布者。

步骤202：监控设备接收信息发布平台发送的创建触发消息，并确定待发布信息在发布过程中产生监控数据的至少一台后台服务器，所述创建触发消息中携带为所述待发布信息分配的标识。

由于信息发布平台可以同时响应多个信息发布者请求发布的信息，或同一信息发布者请求发布的多条信息，因此，信息发布平台可能在较短的时间内向监控设备发送多条创建触发消息，监控设备根据创建触发消息中携带的全局唯一标识来区分各条创建触发消息，且根据该全局唯一标识区分各信息发布事件。

由于信息在发布的过程中需要同时运行多台服务器，因此，在该信息的发布过程中，可能有多台后台服务器为该信息的发布过程产生监控数据。例如：一条广告信息的发布过程中，创建该广告信息需要运行信息发布平台、投放该广告信息的网站服务器以及对该广告发布过程进行计费的系统。在该广告信息创建过程以及信息发布者对已创建的广告信息进行更新时，信息发布平台将会为各操作产生相应的监控数据(如日志信息)；在该广告信息的投放过程中，网站服务器可产生该投放过程所占用的资源消耗、点击该广告信息的数量、广告信息在页面中的显示状态等与投放过程相关的监控数据；统计系统在该广告信息每次被点击时对指定账户进行扣费所产生的监控数据。

较优地，所述创建触发消息中还可以携带信息发布平台创建待发布信息的时间，以及待发布信息创建成功的标志。

为了使监控设备能够根据实际需求主动采集监控数据，因此，信息发布平台发送的创建触发消息还可以携带该待发布信息在发布过程中产生监控数据的至少一台后台服务器的标识；但本实施例的方案中并不限于将后台服务器的标识携带在创建触发消息中的情况，监控设备也可以通过其他方式与信息发布平台进行协商，确定待发布信息在发布过程中产生监控数据的至少一台后台服务器；或者，监控设备根据创建触发消息中携带的全局唯一标识确定相应的信息发布事件，进而确定该信息发布事件运行时产生监控数据的至少一台后台服务器。

在本步骤的方案中，信息发布平台可以在成功创建一个待发布信息后，就向监控设备发送创建触发消息，此时，该待发布信息可能已经发布，也可能由于还没有达到发布开始时间而未发布，这样做的目的是：由于创建待发布信息的时间和该信息的发布开始时间之间可能存在一定长度的时间段，在该时间段内，信息发布者可以对已创建的待发布信息进行更新，此时，信息发布平台将会为更新操作产生监控数据，监控设备就可以根据该监控数据对更新操作是否存在异常进行监控，可有效地避免在信息发布开始前出现异常而无法及时监控的问题。

步骤203：监控设备确定后台服务器所产生的监控数据的属性信息。

在本步骤中，在信息发布过程中产生监控数据的后台服务器可以是一台也可以是多台，针对任一后台服务器所产生的监控数据，其表示在信息发布过程中某一状态或某一操作过程，因此，可通过属性信息来区分各监控数据所表示的状态或操作。由于不同的后台服务器在信息发布过程中运行的业务不同，因此，各后台服务器可以产生与运行的业务相适应的属性信息的监控数据。例如：针对点击该广告信息的数量，网站服务器产生的监控数据的属性信息是页面浏览量(PageView，PV)；针对在该广告信息每次点击时对指定账户进行扣费，BOSS产生的监控数据的属性信息是计费。

监控设备在确定可产生监控数据的后台服务器后，可进一步确定各后台服务器所产生的监控数据的属性信息。

较优地，本步骤还可根据监控数据的属性信息，来进一步确定各监控数据的采集周期，这样做的目的是：不同属性信息的监控数据对时效性的要求不同，对于时效性要求高的监控数据，其采集周期需要设置为较短的时间，甚至于要求实时采集；对于时效性要求低的监控数据，其采集周期需要设置为较长的时间，以便于在满足各监控数据时效性、使采集的监控数据真实可靠且能够及时定位异常的情况下，还能够减少采集次数，降低采集过程所带来的资源占用量。

例如：点击广告信息的数量可以是24小时内不同访客浏览发布信息的累计数量，因此，产生相应监控数据的网站服务器可以每24小时产生一条针对点击广告信息的数量的监控数据，也就是说，属性信息为点击广告信息的数量的监控数据的采集周期为24小时；统计系统在每次点击广告信息后对指定账户进行扣费的操作是实时进行的，并在每次扣费后产生相应的监控数据，因此，数据信息为计费的监控数据的采集周期为实时采集。

步骤204：在信息的发布期结束前，监控设备利用发布信息的标识，从确定的后台服务器中采集该信息在发布过程中产生的监控数据。

本步骤中涉及的发布期可以根据步骤201中，信息发布者在请求创建待发布信息时，在创建请求中携带的发布开始时间和发布持续时间来确定。

本步骤的具体实现方式为：判断信息的发布期是否已结束，若已结束，则停止本实施例中的监控过程；若没有结束，则确定待采集的监控数据的属性信息，并进一步确定该待采集的监控数据的采集周期，并按照该采集周期从后台服务器中采集上一采集周期内产生的监控数据。

具体地，监控设备按照采集周期从后台服务器中采集监控数据的方式包括但不限于以下两种方式：

第一种采集方式：

监控设备在采集周期到达时，向后台服务器发送采集请求消息，所述采集请求消息中携带发布信息的全局唯一标识、该后台服务器所产生的监控数据的属性信息。由于监控数据的采集周期是与该监控数据的属性信息关联的，因此，在某一采集周期到达时，可从后台服务器中采集该采集周期对应属性信息的监控数据，因此，向后台服务器发送的采集请求消息中携带属性信息，可通知后台服务器需要向监控设备返回对应属性信息的上一采集周期内产生的监控数据。

例如：属性信息1和属性信息2所对应的采集周期为t，属性信息3所对应的采集周期为T，后台服务器1能够产生属性信息1、属性信息2和属性信息3的监控数据。

监控设备在采集周期t到达时(此时采集周期T未到达)，向后台服务器1发送的采集请求消息中携带发布信息的全局唯一标识、属性信息1、属性信息2；后台服务器1接收到该采集请求消息后，从本地查找出上一采集周期中产生的包含该全局唯一标识的监控数据，并从查找出的监控数据中进一步确定属性信息1和属性信息2的监控数据，为了使监控设备能够直接地识别各属性信息的监控数据，后台服务器1可按照属性信息属性信息1和属性信息2的监控数据进行划分，其中，划分在同一组内的监控数据具有相同的属性信息，并将划分后的监控数据通过采集请求响应发送给监控设备。

需要说明的是，所述上一采集周期中产生的包含该全局唯一标识的监控数据是指：从后台服务器1在本地查找监控数据开始，之前的采集周期t时长内所产生的所有监控数据。

第二种采集方式：

监控设备直接向后台服务器发送采集请求消息，所述采集请求消息中携带发布信息的全局唯一标识、该后台服务器所产生的监控数据的属性信息和该属性信息对应的采集周期，要求后台服务器根据该采集周期，周期性地将对应属性信息的监控数据返回给监控设备。具体的，后台服务器在采集周期到达时，将对应属性信息的上一采集周期内产生的监控数据返回给监控设备的方式与第一种采集方式相同，此处不再赘述。

需要说明的是，本步骤中的监控设备可同时从多台后台服务器中采集监控数据，且任一后台服务器可以同时向多台监控设备返回监控数据。

步骤205：监控设备利用预设的异常判定条件，对采集的监控数据进行监控，确定信息在发布过程出现的异常。

由于不同属性信息的监控数据所表示的信息发布状态或操作不同，因此，对于不同属性信息的监控数据所采用的异常判定条件也不同，较优地，可为各属性信息分别建立与异常判定条件的对应关系，针对任一属性信息的监控数据，可采用该属性信息对应的异常判定条件对监控数据是否出现异常进行判定。

异常判定条件与属性信息之间的对应关系可以有以下三种情况：

第一种情况：

异常判定条件与属性信息之间具有一一对应关系。例如：在属性信息是页面浏览量时，可为其建立一一对应的异常判定条件：单位时间内页面浏览量大于设定阈值，也就是说，若针对页面浏览量产生的监控数据的内容中，单位时间内浏览量的数值大于设定阈值时，可认为当前页面受到攻击，出现异常。

第二种情况：

异常判定条件与属性信息之间可以是一对多的关系，即多个属性信息对应一种异常判定条件的情况。

第三种情况：

异常判定条件与属性信息之间可以是多对一的关系，即一个属性信息对应多种异常判定条件的情况，只有该属性信息的监控数据同时满足对应的所有异常判定条件时，才确定该监控数据出现异常。

需要说明的是，由于信息发布过程是一个持续性的过程，在信息发布的不同阶段，属性信息对应的异常判定条件可能会发生变化，因此，本实施例的方案中也不限于根据需要实时更新异常判定条件的内容，以便于能够更加准确地定位出信息发布过程中的异常。

具体地，在本步骤中，监控设备利用异常判定条件，对采集的监控数据进行监控，确定信息在发布过程出现的异常的具体方法包括：

第一步：针对采集到的监控数据，确定该监控数据的属性信息所对应的异常判定条件。

第二步：将监控数据的内容与确定的异常判定条件进行比较，若比较结果为满足异常判定条件，则确认该监控数据为异常，进而确定信息在发布过程中出现了异常；否则，确认该监控数据为正常，跳转至步骤204。

例如：假设采集到两条监控数据，其属性信息分别是对指定账户扣费和页面浏览量，对属性信息为指定账户扣费时对应的异常判定条件为“ERROR”，属性信息为页面浏览量时对应的异常判定条件为“单位时间内页面浏览量大于1000”。若属性信息为指定账户扣费的监控数据的内容为“ERROR”，满足对应的异常判定条件，因此，确定属性信息为指定账户扣费的监控数据为异常；若属性信息为页面浏览量的监控数据的内容为“1000”，不满足对应的异常判定条件，因此，确定属性信息为页面浏览量的监控数据为正常。

当确定采集的监控数据出现异常，也就是说，确定信息发布过程出现异常时，可根据产生该监控数据的后台服务器以及该监控数据的属性信息，确定异常原因，并通过分析异常原因，判断满足异常判定条件的监控数据是否还满足预设的停止条件，若是，则确定所述信息的发布期结束，也就是说，即使此时步骤104中的发布期还没有结束，也强制结束信息发布过程；若不是，则跳转至步骤204。

假设停止条件为N个采集周期内，连续采集的N个监控数据都满足异常判定条件时，则认为出现了不可容忍的异常情况，需要强制结束信息发布过程。如：连续采集N条属性信息为指定账户扣费的监控数据的内容都为“ERROR”，则可认为计费过程出现了不可容忍的异常情况，强制结束信息发布过程。

在本实施例的方案中，监控设备可根据实际需要实时采集监控数据，并利用异常判定条件实时对每条采集到的监控数据进行异常判定，进而确定信息发布过程中出现异常的原因，这样可以实现对信息发布过程中出现的异常情况及时、准确的定位。

进一步地，监控设备向后台服务器发送采集请求消息时，所述采集请求消息中携带了全局唯一的标识和该后台服务器所产生的监控数据的属性信息，后台服务器在本地查找到包含全局唯一标识和所述属性信息的监控数据后，发送至监控设备，此时，监控设备采集到的监控数据中包含有属性信息，在通过数据列表或者图表等方式对采集的监控数据进行整合，使得整合后的监控数据不再是单一的数据信息，而是包含有属性信息的监控数据，并将整合后的监控数据在同一个页面上进行展示，这样不仅避免了通过多个页面之间进行相互跳转来查看这些监控数据的情形，而且使被查看的监控数据内容更具体和准确，更容易地根据得到的监控数据内容定位信息发布过程中的异常情况。

实施例二：

本实施例二通过具体的实例对本实施例一的方案进行详细说明。

假设，在网站的首页上发布广告信息，发布时间为2011年5月10日至2011年5月12日，信息发布平台对该广告信息创建一个待发布信息，并为本次发布广告信息的过程分配一个全局唯一标识(1)。

如图3所示，其为所述广告信息在发布过程中，监控设备采集并存储产生的监控数据的示意图。在信息发布平台创建待发布广告信息且向监控设备发送创建触发消息后，监控设备确定针对该广告信息发布过程的监控过程开始，从信息发布平台中采集一条监控数据：“1，测试计划，2011-5-10，true”，表示采集的监控数据是全局唯一标识为1的发布过程所产生的监控数据，信息发布名称为测试计划，于2011年5月10创建成功。

按照同样的方式，监控设备可以在信息发布结束前，不断地从包括信息发布平台的后台服务器中采集监控数据。例如：在某一时刻，监控设备采集的监控数据为：“1，测试计划，2011-5-11，pv，1000”，表示采集的监控数据是全局唯一标识为1的发布过程所产生的监控数据，信息发布名称为测试计划，属性信息为页面浏览量(PageView，PV)，对应的数据量为1000。

在广告信息发布结束的时候，监控设备采集的监控数据为：“1，测试计划，2011-5-12，true”，表示采集的监控数据是全局唯一标识为1的发布过程所产生的监控数据，信息发布名称为测试计划，于2011年5月12正常结束。

由于在信息发布创建时，确定了信息发布的起止时间，因此可以在信息发布结束时采集到监控数据的内容为“true”时，确定发布正常结束。

在待发布信息创建时，监控设备为了方便采集并存储全局唯一标识为1的信息发布过程中产生的监控数据，可采取嵌套的键值存储方式，这种存储方式在创建开始以后，将具有内在关系的监控数据进行存储，排除了不同信息发布过程之间的外在联系。

如图4所示，其为监控设备对采集到的监控数据进行分析和整合后的结果展示图。具体地，是将图3中采集并存储的监控数据分析整合后的结果展示图。

在信息发布的创建开始阶段，监控设备接收到“1，测试计划，2011-5-10，true”监控数据，则表示该待发布信息创建成功。

在信息发布的过程中，监控设备在不同的采集周期采集到如下三条监控数据：“1，测试计划，2011-5-10，pv，1000”、“1，测试计划，2011-5-11，pv，1000”和“1，测试计划，2011-5-12，pv，1000”。假设属性信息为pv时对应的异常判定条件为大于10000。上述三条监控数据的内容都不满足对应的异常判定条件，因此，可确定在采集上述三条监控数据的采集周期内，页面浏览量的状态正常，可在图4在展示结果图中展示状态是否正常的结果。

在信息发布结束时，监控设备采集到得监控数据为：“1，测试计划，2011-5-12，true”，则表示信息的发布过程正常结束。

以上为广告信息正常发布过程的情形，若广告信息在发布过程中出现了异常，则如图5所示，在信息发布过程中，监控设备采集到了如下一条监控数据“1，测试计划，2011-5-11，pv，20000”，表示：采集的监控数据是全局唯一标识为1的发布过程所产生的监控数据，信息发布名称为测试计划，属性信息为pv，对应的数据量为20000。

由于属性信息为pv时对应的异常判定条件为大于10000，因此，监控设备可确定采集的该监控数据出现异常，与图3的存储结构相比，将该出现异常的监控设备标记为ERROR。

假设在单位时间内采集到的属性信息为pv的监控数据的数量达到N条，则强制结束信息发布过程，采集到的监控数据为：“1，测试计划，2011-5-11，false”，表示采集的监控数据是全局唯一标识为1的发布过程所产生的监控数据，信息发布名称为测试计划，于2011年5月11异常结束。

由于图5采集并存储的监控数据出现异常，且最终强制结束信息发布过程，因此，图6所示的结果展示图中，展示各监控数据的状态以及最终异常结束的状态。

实施例三：

如图7所示，为本实施例三的一种监控设备的结构示意图。该监控设备包括接收模块31、确定模块32、采集模块33和监控模块34。其中：

接收模块31，用于接收信息创建触发消息。在信息创建时，监控设备的接收模块31通过监控设备的开始接口接收信息发布平台发送的创建触发消息。

确定模块32，用于确定待发布信息的标识，以及确定该待发布信息在发布过程中产生监控数据的至少一台后台服务器。

采集模块33，用于在所述信息的发布期结束前，利用所述信息的标识，从确定的后台服务器中采集该信息在发布过程中产生的监控数据。监控设备的采集模块33通过监控设备的采集接口从各后台服务器中采集信息发布过程中产生的监控数据。

监控模块34，用于利用预设的异常判定条件，对采集的监控数据进行监控，确定信息在发布过程出现的异常。

具体地，所述确定模块32，还用于确定各后台服务器所产生的监控数据的属性信息；所述采集模块33，具体用于向所述后台服务器发送采集请求消息，所述采集请求消息中携带所述信息的标识和该后台服务器所产生的监控数据的属性信息，指示后台服务器根据接收到的所述信息的标识，查找出包含该标识的监控数据，并按照接收到的属性信息，将查找出的监控数据进行划分，其中，划分在同一组内的监控数据具有相同的属性信息；所述接收模块31，还用于接收后台服务器按照属性信息划分后的监控数据。

所述确定模块32，还用于确定监控数据的属性信息所对应的采集周期。

所述采集模块33，还具体用于按照采集请求消息中携带的属性信息对应的采集周期从后台服务器中采集上一采集周期内产生的监控数据。

所述监控模块34，具体用于针对采集到的监控数据，利用该监控数据的属性信息所对应的异常判定条件，对该监控数据的内容进行判定，若该监控数据的内容满足该异常判定条件，则确定信息在发布过程出现异常；

所述确定模块32，还用于根据产生该监控数据的后台服务器以及该监控数据的属性信息，通过监控设备的错误输出接口确定监控数据出现的异常原因。

较优地，该监控设备设备还包括强制结束模块35。其中，

强制结束模块35，用于在满足异常判定条件的监控数据还满足预设的停止条件时，通过监控设备的结束接口确定所述信息的发布期结束。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种对信息发布过程进行监控的方法，其特征在于，该方法包括：

在接收到信息创建触发消息时，确定待发布信息的标识，以及确定该待发布信息在发布过程中产生监控数据的至少一台后台服务器；

在所述信息的发布期结束前，利用所述信息的标识，从确定的后台服务器中采集该信息在发布过程中产生的监控数据；

利用预设的异常判定条件，对采集的监控数据进行监控，确定信息在发布过程出现的异常。

2.如权利要求1所述的方法，其特征在于，在确定产生监控数据的后台服务器之后，且从确定的后台服务器中采集所述监控数据之前，所述方法还包括：

确定各后台服务器所产生的监控数据的属性信息；

从确定的后台服务器中采集该信息在发布过程中产生的监控数据，具体包括：

向所述后台服务器发送采集请求消息，所述采集请求消息中携带所述信息的标识和该后台服务器所产生的监控数据的属性信息，指示后台服务器根据接收到的所述信息的标识，查找出包含该标识的监控数据，并按照接收到的属性信息，将查找出的监控数据进行划分，其中，划分在同一组内的监控数据具有相同的属性信息；

接收后台服务器按照属性信息划分后的监控数据。

3.如权利要求2所述的方法，其特征在于，从确定的后台服务器中采集所述监控数据之前，所述方法还包括：

确定监控数据的属性信息所对应的采集周期；

从确定的后台服务器中采集该信息在发布过程中产生的监控数据，具体包括：

按照采集请求消息中携带的属性信息对应的采集周期从后台服务器中采集上一采集周期内产生的监控数据。

4.如权利要求2所述的方法，其特征在于，所述异常判定条件与属性信息具有对应关系；

利用预设的异常判定条件，对采集的监控数据进行监控，确定信息在发布过程出现的异常，具体包括：

针对采集到的监控数据，利用该监控数据的属性信息所对应的异常判定条件，对该监控数据的内容进行判定，若该监控数据的内容满足该异常判定条件，则确定信息在发布过程出现异常。

5.如权利要求4所述的方法，其特征在于，在确定监控数据的内容满足该异常判定条件时，所述方法还包括：

根据产生该监控数据的后台服务器以及该监控数据的属性信息，确定异常原因。

6.如权利要求1～5任一所述的方法，其特征在于，确定信息在发布过程出现异常之后，所述方法还包括：

在满足异常判定条件的监控数据还满足预设的停止条件时，确定所述信息的发布期结束。

7.一种监控设备，其特征在于，该设备包括：

接收模块，用于接收信息创建触发消息；

确定模块，用于确定待发布信息的标识，以及确定该待发布信息在发布过程中产生监控数据的至少一台后台服务器；

采集模块，用于在所述信息的发布期结束前，利用所述信息的标识，从确定的后台服务器中采集该信息在发布过程中产生的监控数据；

监控模块，用于利用预设的异常判定条件，对采集的监控数据进行监控，确定信息在发布过程出现的异常。

8.如权利要求7所述的设备，其特征在于，

所述确定模块，还用于确定各后台服务器所产生的监控数据的属性信息；

所述采集模块，具体用于向所述后台服务器发送采集请求消息，所述采集请求消息中携带所述信息的标识和该后台服务器所产生的监控数据的属性信息，指示后台服务器根据接收到的所述信息的标识，查找出包含该标识的监控数据，并按照接收到的属性信息，将查找出的监控数据进行划分，其中，划分在同一组内的监控数据具有相同的属性信息；

所述接收模块，还用于接收后台服务器按照属性信息划分后的监控数据。

9.如权利要求8所述的设备，其特征在于，

所述确定模块，还用于确定监控数据的属性信息所对应的采集周期；

所述采集模块，还具体用于按照采集请求消息中携带的属性信息对应的采集周期从后台服务器中采集上一采集周期内产生的监控数据。

10.如权利要求8所述的设备，其特征在于，

所述监控模块，具体用于针对采集到的监控数据，利用该监控数据的属性信息所对应的异常判定条件，对该监控数据的内容进行判定，若该监控数据的内容满足该异常判定条件，则确定信息在发布过程出现异常；

所述确定模块，还用于根据产生该监控数据的后台服务器以及该监控数据的属性信息，确定异常原因。