本發(fā)明涉及數(shù)據(jù)采集技術領域，具體涉及一種數(shù)據(jù)采集監(jiān)控方法及裝置。

背景技術：

隨著互聯(lián)網(wǎng)的發(fā)展，業(yè)務量急劇增長，提供服務的服務器集群規(guī)模越來越龐大，提供的服務類型也越來越復雜。這種大數(shù)據(jù)背景下的業(yè)務日志數(shù)據(jù)采集的可靠性顯得越來越重要。

目前主流的業(yè)務日志數(shù)據(jù)采集系統(tǒng)是Cloudera提供的一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)腇lume系統(tǒng)。目前，基于Flume系統(tǒng)的業(yè)務日志數(shù)據(jù)采集流程具體如下：首先，采用Flume系統(tǒng)對業(yè)務日志數(shù)據(jù)進行分布式采集，然后，將采集的業(yè)務日志數(shù)據(jù)匯聚到Kafka中，最后，將采集的業(yè)務日志數(shù)據(jù)持久化存儲到HDFS(Hadoop Distributed File System，Hadoop分布式文件系統(tǒng))中。

但是，在大數(shù)據(jù)背景下，需要采集的業(yè)務日志數(shù)據(jù)分布于眾多服務器上，單臺服務器又有多種業(yè)務日志數(shù)據(jù)需要分別采集，導致采集任務數(shù)量多。而采用Flume系統(tǒng)對業(yè)務日志數(shù)據(jù)進行分布式采集過程中，由于Flume系統(tǒng)缺乏可靠的數(shù)據(jù)采集監(jiān)控技術，導致對業(yè)務日志數(shù)據(jù)進行分布式采集過程中發(fā)生的故障無法快速發(fā)現(xiàn)并準確定位。

技術實現(xiàn)要素：

有鑒于此，本發(fā)明實施例提供一種數(shù)據(jù)采集監(jiān)控方法及裝置，能夠?qū)I(yè)務日志數(shù)據(jù)進行分布式采集過程中發(fā)生的故障快速發(fā)現(xiàn)并準確定位。

為實現(xiàn)上述目的，本發(fā)明實施例提供如下技術方案：

一種數(shù)據(jù)采集監(jiān)控方法，包括：

獲取第一類型的從屬服務器上報的心跳數(shù)據(jù)，所述心跳數(shù)據(jù)包括所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息；

根據(jù)所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息判斷所述第一類型的從屬服務器對于所述文件的采集過程是否發(fā)生故障，得到第一判斷結果；

當所述第一判斷結果表示所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障時，定位所述故障在所述文件中的位置為所述文件已采集完成的最后一個數(shù)據(jù)之后的數(shù)據(jù)。

優(yōu)選的，所述根據(jù)所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息判斷所述第一類型的從屬服務器對于所述文件的采集過程是否發(fā)生故障，包括：

當達到預設采集時間閾值時，所述文件已采集完成的數(shù)據(jù)量信息小于所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息，則判斷所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障。

優(yōu)選的，所述方法還包括：

獲取所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間；

判斷在所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，是否接收到所述第一類型的從屬服務器上報的注銷請求或所述第一類型的從屬服務器上報的心跳數(shù)據(jù)；

當在所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，未接收到所述第一類型的從屬服務器上報的注銷請求且未接收到所述第一類型的從屬服務器上報的心跳數(shù)據(jù)，則確定所述第一類型的從屬服務器處于異常狀態(tài)。

優(yōu)選的，所述方法還包括：

獲取所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間；

判斷在所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，是否接收到所述第二類型的從屬服務器上報的注銷請求或所述第二類型的從屬服務器上報的心跳數(shù)據(jù)；

當在所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，未接收到所述第一類型的從屬服務器上報的注銷請求且未接收到所述第二類型的從屬服務器上報的心跳數(shù)據(jù)，則確定所述第二類型的從屬服務器處于異常狀態(tài)。

優(yōu)選的，所述方法還包括：

獲取所述第一類型的從屬服務器上報的第一采集數(shù)據(jù)條數(shù)；

獲取所述第二類型的從屬服務器上報的第二采集數(shù)據(jù)條數(shù)；

根據(jù)所述第一采集數(shù)據(jù)條數(shù)以及所述第二采集數(shù)據(jù)條數(shù)判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作是否發(fā)生故障，得到第二判斷結果；

當所述第二判斷結果表示所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作發(fā)生故障時，進行報警。

優(yōu)選的，所述根據(jù)所述第一采集數(shù)據(jù)條數(shù)以及所述第二采集數(shù)據(jù)條數(shù)判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作是否發(fā)生故障，包括：

當所述第一采集數(shù)據(jù)條數(shù)與所述第二采集數(shù)據(jù)條數(shù)不相等時，則判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作發(fā)生故障。

一種數(shù)據(jù)采集監(jiān)控裝置，包括：

第一獲取模塊，用于獲取第一類型的從屬服務器上報的心跳數(shù)據(jù)，所述心跳數(shù)據(jù)包括所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息；

第一判斷模塊，用于根據(jù)所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息判斷所述第一類型的從屬服務器對于所述文件的采集過程是否發(fā)生故障，得到第一判斷結果；

故障定位模塊，用于當所述第一判斷結果表示所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障時，定位所述故障在所述文件中的位置為所述文件已采集完成的最后一個數(shù)據(jù)之后的數(shù)據(jù)。

優(yōu)選的，所述第一判斷模塊具體用于：

當達到預設采集時間閾值時，所述文件已采集完成的數(shù)據(jù)量信息小于所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息，則判斷所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障。

優(yōu)選的，所述裝置還包括：

第二獲取模塊，用于獲取所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間；

第二判斷模塊，用于判斷在所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，是否接收到所述第一類型的從屬服務器上報的注銷請求或所述第一類型的從屬服務器上報的心跳數(shù)據(jù)；

第一狀態(tài)確定模塊，用于當在所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，未接收到所述第一類型的從屬服務器上報的注銷請求且未接收到所述第一類型的從屬服務器上報的心跳數(shù)據(jù)，則確定所述第一類型的從屬服務器處于異常狀態(tài)。

優(yōu)選的，所述裝置還包括：

第三獲取模塊，用于獲取所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間；

第三判斷模塊，用于判斷在所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，是否接收到所述第二類型的從屬服務器上報的注銷請求或所述第二類型的從屬服務器上報的心跳數(shù)據(jù)；

第二狀態(tài)確定模塊，用于當在所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，未接收到所述第一類型的從屬服務器上報的注銷請求且未接收到所述第二類型的從屬服務器上報的心跳數(shù)據(jù)，則確定所述第二類型的從屬服務器處于異常狀態(tài)。

優(yōu)選的，所述裝置還包括：

第四獲取模塊，用于獲取所述第一類型的從屬服務器上報的第一采集數(shù)據(jù)條數(shù)，以及，獲取所述第二類型的從屬服務器上報的第二采集數(shù)據(jù)條數(shù)；

第四判斷模塊，用于根據(jù)所述第一采集數(shù)據(jù)條數(shù)以及所述第二采集數(shù)據(jù)條數(shù)判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作是否發(fā)生故障，得到第二判斷結果；

報警模塊，用于當所述第二判斷結果表示所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作發(fā)生故障時，進行報警。

優(yōu)選的，所述第四判斷模塊具體用于：

當所述第一采集數(shù)據(jù)條數(shù)與所述第二采集數(shù)據(jù)條數(shù)不相等時，則判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作發(fā)生故障。

基于上述技術方案，本發(fā)明實施例中公開了一種數(shù)據(jù)采集監(jiān)控方法及裝置，獲取第一類型的從屬服務器上報的心跳數(shù)據(jù)，所述心跳數(shù)據(jù)包括所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息；根據(jù)所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息判斷所述第一類型的從屬服務器對于所述文件的采集過程是否發(fā)生故障，當所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障時，定位所述故障在所述文件中的位置為所述文件已采集完成的最后一個數(shù)據(jù)之后的數(shù)據(jù)?；谛奶鴶?shù)據(jù)，能夠?qū)I(yè)務日志數(shù)據(jù)進行分布式采集過程中發(fā)生的故障快速發(fā)現(xiàn)并準確定位。

附圖說明

為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)提供的附圖獲得其他的附圖。

圖1為本發(fā)明實施例提供的一種數(shù)據(jù)采集監(jiān)控方法的流程示意圖；

圖2為本發(fā)明實施例提供的一種Master監(jiān)控Source的狀態(tài)的方法的流程示意圖；

圖3為本發(fā)明實施例提供的一種Master監(jiān)控Sink的狀態(tài)的方法的流程示意圖；

圖4為本發(fā)明實施例提供的一種判斷Sink持久化存儲操作是否發(fā)生故障的方法的流程示意圖；

圖5為本發(fā)明實施例提供的一種數(shù)據(jù)采集監(jiān)控裝置的結構框圖。

具體實施方式

下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

本發(fā)明實施例中的數(shù)據(jù)采集監(jiān)控方法應用于基于Kafka的可監(jiān)控的分布式數(shù)據(jù)采集系統(tǒng)，該系統(tǒng)采用Master/Slave(主服務器/從屬服務器)結構，使用Kafka作為數(shù)據(jù)匯聚的中間節(jié)點，最終采用HDFS或其他可靠媒介對數(shù)據(jù)進行持久化存儲。該系統(tǒng)中，Slave執(zhí)行實際的采集任務，Slave按照采集功能的不同分為兩種類型，其中，Source(第一類型的從屬服務器)負責從各數(shù)據(jù)源服務器采集數(shù)據(jù)傳輸至Kafka；Sink(第二類型的從屬服務器)負責從Kafka消費采集的數(shù)據(jù)匯聚后進行持久化存儲。Master負責維護Slave的部署情況、監(jiān)控Slave的采集任務執(zhí)行情況等。

Slave啟動時，需要先向Master注冊自己被分配的任務的信息，注冊需要上報的信息包括Slave所在的服務器IP，Slave的類型(Source/Sink)，Slave的唯一ID，Slave執(zhí)行的采集任務列表等。如果Slave支持動態(tài)配置采集任務，那么當所執(zhí)行的采集任務發(fā)生變更的時候需要重新進行注冊。相應的，Slave正常關閉時，需要向Master進行注銷。注銷需要上報Slave所在的服務器IP，Slave的唯一ID。

Slave向Master注冊成功后，執(zhí)行實際的采集任務。其中，Source按照任務的配置信息，將采集的數(shù)據(jù)匯聚到Kafka的指定Topic。Sink按照任務的配置信息，將Kafka的指定Topic的數(shù)據(jù)存儲至可靠的存儲介質(zhì)(如，HDFS)中。

具體的，Source在采集數(shù)據(jù)時，需要對數(shù)據(jù)按時間分段(比如，以小時為單位對數(shù)據(jù)進行分段)，并將數(shù)據(jù)所在的時間分段信息寫入Kafka消息的Key中，將采集的數(shù)據(jù)實體寫入Kafka消息的Value中。其中，Source對數(shù)據(jù)按時間分段的方法如下：如果文件名中有時間戳，可以以文件名為依據(jù)；如果文件名沒有時間戳，可以以文件創(chuàng)建時間為依據(jù)；如果采集的是數(shù)據(jù)流，可以以接收到數(shù)據(jù)的時間為依據(jù)。Sink消費Kafka中的數(shù)據(jù)時，需要根據(jù)Kafka消息的Key中的時間分段信息，以小時為單位對數(shù)據(jù)進行處理，比如，每個小時建立獨立的文件夾，并根據(jù)Kafka消息的Key中的時間分段信息，將屬于不同時間段的數(shù)據(jù)寫入到不同的文件夾中。

另外由于所采集的數(shù)據(jù)以原始格式存儲于Kafka的Value之中，因此其他處理系統(tǒng)可以無需做任何改動，透明的消費Kafka中的數(shù)據(jù)。

Slave在執(zhí)行實際的采集任務的過程中，還需要維護采集任務的執(zhí)行情況，并作為心跳數(shù)據(jù)定期上報到Kafka的特定Topic中，等待Master拉取消費。Master通過消費Kafka中的Slave上報的心跳數(shù)據(jù)，即可監(jiān)控Slave的采集任務執(zhí)行情況。

圖1為本發(fā)明實施例提供的一種數(shù)據(jù)采集監(jiān)控方法的流程示意圖，該方法由Master執(zhí)行，具體的，該方法包括如下步驟：

步驟S10、獲取第一類型的從屬服務器上報的心跳數(shù)據(jù)，所述心跳數(shù)據(jù)包括所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息。

需要說明的是，第一類型的從屬服務器在上報心跳數(shù)據(jù)之前，已經(jīng)向Master成功注冊，文件可以為業(yè)務日志，數(shù)據(jù)量信息可以為字節(jié)數(shù)和數(shù)據(jù)條目數(shù)。

步驟S20、根據(jù)所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息判斷所述第一類型的從屬服務器對于所述文件的采集過程是否發(fā)生故障，得到第一判斷結果。

其中，當達到預設采集時間閾值時，所述文件已采集完成的數(shù)據(jù)量信息小于所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息，則判斷所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障。當所述文件已采集完成的數(shù)據(jù)量信息與所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息相同時，則判斷所述第一類型的從屬服務器對于所述文件的采集過程未發(fā)生故障。

步驟S30、當所述第一判斷結果表示所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障時，定位所述故障在所述文件中的位置為所述文件已采集完成的最后一個數(shù)據(jù)之后的數(shù)據(jù)。

具體來講，假設所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息為100字節(jié)，當達到預設采集時間閾值時，所述文件已采集完成的數(shù)據(jù)量信息為50字節(jié)，則可判定所述第一判斷結果表示所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障，且故障位置為所述文件的第51字節(jié)。

本發(fā)明實施例中公開的一種數(shù)據(jù)采集監(jiān)控方法，獲取第一類型的從屬服務器上報的心跳數(shù)據(jù)，所述心跳數(shù)據(jù)包括所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息；根據(jù)所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息判斷所述第一類型的從屬服務器對于所述文件的采集過程是否發(fā)生故障，當所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障時，定位所述故障在所述文件中的位置為所述文件已采集完成的最后一個數(shù)據(jù)之后的數(shù)據(jù)。基于心跳數(shù)據(jù)，能夠?qū)I(yè)務日志數(shù)據(jù)進行分布式采集過程中發(fā)生的故障快速發(fā)現(xiàn)并準確定位。

進一步的，Master還可監(jiān)控Slave的狀態(tài)是否異常。具體的，圖2示出了一種Master監(jiān)控Source的狀態(tài)的方法的流程示意圖，該方法具體包括如下步驟：

步驟S100、獲取所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間。

需要說明的是，本發(fā)明實施例中的所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間可以包含在所述第一類型的從屬服務器上報的心跳數(shù)據(jù)中，Master在獲取心跳數(shù)據(jù)之后，即可獲知所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間。

步驟S110、判斷在所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，是否接收到所述第一類型的從屬服務器上報的注銷請求或所述第一類型的從屬服務器上報的心跳數(shù)據(jù)。

步驟S120、當在所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，未接收到所述第一類型的從屬服務器上報的注銷請求且未接收到所述第一類型的從屬服務器上報的心跳數(shù)據(jù)，則確定所述第一類型的從屬服務器處于異常狀態(tài)。

圖3示出了一種Master監(jiān)控Sink的狀態(tài)的方法的流程示意圖，該方法具體包括如下步驟：

步驟S200、獲取所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間。

需要說明的是，第二類型的從屬服務器在上報心跳數(shù)據(jù)之前，已經(jīng)向Master成功注冊。

步驟S210、判斷在所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，是否接收到所述第二類型的從屬服務器上報的注銷請求或所述第二類型的從屬服務器上報的心跳數(shù)據(jù)。

步驟S220、當在所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，未接收到所述第一類型的從屬服務器上報的注銷請求且未接收到所述第二類型的從屬服務器上報的心跳數(shù)據(jù)，則確定所述第二類型的從屬服務器處于異常狀態(tài)。

進一步的，Master通過比對Source以及Sink上報的采集數(shù)據(jù)條數(shù)，判斷由Source匯聚到Kafka的數(shù)據(jù)，是否正常被Sink完成了持久化存儲操作，精度可以達到每條數(shù)據(jù)。

具體的，圖4示出了一種判斷Sink持久化存儲操作是否發(fā)生故障的方法的流程示意圖，該方法包括如下步驟：

步驟S300、獲取所述第一類型的從屬服務器上報的第一采集數(shù)據(jù)條數(shù)。

步驟S310、獲取所述第二類型的從屬服務器上報的第二采集數(shù)據(jù)條數(shù)。

步驟S320、根據(jù)所述第一采集數(shù)據(jù)條數(shù)以及所述第二采集數(shù)據(jù)條數(shù)判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作是否發(fā)生故障，得到第二判斷結果。

其中，當所述第一采集數(shù)據(jù)條數(shù)與所述第二采集數(shù)據(jù)條數(shù)不相等時，則判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作發(fā)生故障。

步驟S330、當所述第二判斷結果表示所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作發(fā)生故障時，進行報警。

其中，可以通過郵件、短信或其他任何用戶定義的形式進行報警。

本發(fā)明實施例提供的數(shù)據(jù)采集監(jiān)控方法，可以支持不同技術的采集終端，維護各終端的部署情況以及任務配置情況，大幅提高對采集流程是否出現(xiàn)問題的判斷的準確性，并且可以快速定位問題發(fā)生所在的具體位置，采集的數(shù)據(jù)流和心跳數(shù)據(jù)同時依賴于Kafka，以此來準確判斷采集終端是否存活，避免因為采集終端在可以正常連接Kafka，但其他某些鏈路異常導致的存活狀態(tài)誤判，而且，對日志格式、采集終端所用技術等無要求。

下面對本發(fā)明實施例提供的數(shù)據(jù)采集監(jiān)控裝置進行介紹，下文描述的數(shù)據(jù)采集監(jiān)控裝置可與上文數(shù)據(jù)采集監(jiān)控方法相互對應參照。

圖5為本發(fā)明實施例提供的數(shù)據(jù)采集監(jiān)控裝置的結構框圖，該數(shù)據(jù)采集監(jiān)控裝置具體可以為Master，參照圖5，該數(shù)據(jù)采集監(jiān)控裝置可以包括：

第一獲取模塊100，用于獲取第一類型的從屬服務器上報的心跳數(shù)據(jù)，所述心跳數(shù)據(jù)包括所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息；

第一判斷模塊110，用于根據(jù)所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息判斷所述第一類型的從屬服務器對于所述文件的采集過程是否發(fā)生故障，得到第一判斷結果；

其中，所述第一判斷模塊具體用于：當達到預設采集時間閾值時，所述文件已采集完成的數(shù)據(jù)量信息小于所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息，則判斷所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障。

故障定位模塊120，用于當所述第一判斷結果表示所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障時，定位所述故障在所述文件中的位置為所述文件已采集完成的最后一個數(shù)據(jù)之后的數(shù)據(jù)。

優(yōu)選的，所述裝置還包括：

第二獲取模塊，用于獲取所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間；

第二判斷模塊，用于判斷在所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，是否接收到所述第一類型的從屬服務器上報的注銷請求或所述第一類型的從屬服務器上報的心跳數(shù)據(jù)；

第一狀態(tài)確定模塊，用于當在所述第一類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，未接收到所述第一類型的從屬服務器上報的注銷請求且未接收到所述第一類型的從屬服務器上報的心跳數(shù)據(jù)，則確定所述第一類型的從屬服務器處于異常狀態(tài)。

優(yōu)選的，所述裝置還包括：

第三獲取模塊，用于獲取所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間；

第三判斷模塊，用于判斷在所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，是否接收到所述第二類型的從屬服務器上報的注銷請求或所述第二類型的從屬服務器上報的心跳數(shù)據(jù)；

第二狀態(tài)確定模塊，用于當在所述第二類型的從屬服務器最后一次上報心跳數(shù)據(jù)的時間開始的預設時間閾值內(nèi)，未接收到所述第一類型的從屬服務器上報的注銷請求且未接收到所述第二類型的從屬服務器上報的心跳數(shù)據(jù)，則確定所述第二類型的從屬服務器處于異常狀態(tài)。

優(yōu)選的，所述裝置還包括：

第四獲取模塊，用于獲取所述第一類型的從屬服務器上報的第一采集數(shù)據(jù)條數(shù)，以及，獲取所述第二類型的從屬服務器上報的第二采集數(shù)據(jù)條數(shù)；

第四判斷模塊，用于根據(jù)所述第一采集數(shù)據(jù)條數(shù)以及所述第二采集數(shù)據(jù)條數(shù)判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作是否發(fā)生故障，得到第二判斷結果；

報警模塊，用于當所述第二判斷結果表示所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作發(fā)生故障時，進行報警。

優(yōu)選的，所述第四判斷模塊具體用于：

當所述第一采集數(shù)據(jù)條數(shù)與所述第二采集數(shù)據(jù)條數(shù)不相等時，則判斷所述第二類型的從屬服務器的數(shù)據(jù)持久化存儲操作發(fā)生故障。

綜上所述：

本發(fā)明實施例中公開了一種數(shù)據(jù)采集監(jiān)控方法及裝置，獲取第一類型的從屬服務器上報的心跳數(shù)據(jù)，所述心跳數(shù)據(jù)包括所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息；根據(jù)所述第一類型的從屬服務器應當采集的文件的數(shù)據(jù)量信息以及所述文件已采集完成的數(shù)據(jù)量信息判斷所述第一類型的從屬服務器對于所述文件的采集過程是否發(fā)生故障，當所述第一類型的從屬服務器對于所述文件的采集過程發(fā)生故障時，定位所述故障在所述文件中的位置為所述文件已采集完成的最后一個數(shù)據(jù)之后的數(shù)據(jù)?；谛奶鴶?shù)據(jù)，能夠?qū)I(yè)務日志數(shù)據(jù)進行分布式采集過程中發(fā)生的故障快速發(fā)現(xiàn)并準確定位。

本說明書中各個實施例采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似部分互相參見即可。對于實施例公開的裝置而言，由于其與實施例公開的方法相對應，所以描述的比較簡單，相關之處參見方法部分說明即可。

專業(yè)人員還可以進一步意識到，結合本文中所公開的實施例描述的各示例的單元及算法步驟，能夠以電子硬件、計算機軟件或者二者的結合來實現(xiàn)，為了清楚地說明硬件和軟件的可互換性，在上述說明中已經(jīng)按照功能一般性地描述了各示例的組成及步驟。這些功能究竟以硬件還是軟件方式來執(zhí)行，取決于技術方案的特定應用和設計約束條件。專業(yè)技術人員可以對每個特定的應用來使用不同方法來實現(xiàn)所描述的功能，但是這種實現(xiàn)不應認為超出本發(fā)明的范圍。

結合本文中所公開的實施例描述的方法或算法的步驟可以直接用硬件、處理器執(zhí)行的軟件模塊，或者二者的結合來實施。軟件模塊可以置于隨機存儲器(RAM)、內(nèi)存、只讀存儲器(ROM)、電可編程ROM、電可擦除可編程ROM、寄存器、硬盤、可移動磁盤、CD-ROM、或技術領域內(nèi)所公知的任意其它形式的存儲介質(zhì)中。

對所公開的實施例的上述說明，使本領域?qū)I(yè)技術人員能夠?qū)崿F(xiàn)或使用本發(fā)明。對這些實施例的多種修改對本領域的專業(yè)技術人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本發(fā)明的精神或范圍的情況下，在其它實施例中實現(xiàn)。因此，本發(fā)明將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。