[發明專利]日志數據傳輸方法、裝置和設備

有效

• 申請號: 201811609311.2
• 申請日: 2018-12-26
• 公開（公告）號: CN111371586B
• 公開（公告）日: 2023-01-10
• 發明（設計）人: 陳東沂;姚小龍;郭林東
• 申請（專利權）人: 順豐科技有限公司
• 主分類號: H04L41/069
• 分類號: H04L41/069;H04L43/08
• 代理公司: 北京志霖恒遠知識產權代理有限公司 11435
• 代理人: 郭棟梁

本申請公開了日志數據處理方法、裝置和設備。該方法包括：監聽應用程序產生的日志數據；實時地將日志數據發送至Kafka消息隊列的第一主題區域；在日志數據推送出現異常時，重試發送日志數據，如果重試成功，則停止發送日志數據至Kafka消息隊列；如果重試未成功，則進一步確定日志數據被發送的次數是否達到閾值；如果達到所述閾值，則將日志數據發送到第二主題區域；如果未達到閾值，則重試將日志數據發送到第一主題區域，并進行計數統計，以統計日志數據被發送的次數。本申請實施例，在應用程序的日志數據發送出現異常時，通過確定日志數據的重新發送的結果來避免日志數據的發送錯誤，有效地提高日志數據傳輸的準確性。

技術領域

本申請一般涉及數據處理技術領域，尤其涉及日志數據處理方法、裝置和設備。

背景技術

隨著電子商務技術的發展，網絡的后端服務器承載的壓力也越來越大，同時需要處理的“數據”也呈幾何級增長，實時準確的收集、傳輸、計算海量日志隨之成為電子商務中的迫切要求。

現有技術中采集日志的工具，例如Flume、Scribe、Chukwa、ELK等，遵循傳統的日志上報方式，即將日志數據先記錄到文件系統，在通過采集Agent將日志的變化上報，可能是增量或全量地采集日志數據發送到消息隊列。上述方式導致日志采集上報存在一定的延時，導致實時上報的效果不好。

同時，日志數據被采集上報給消息隊列后，僅依靠消息隊列自身的反饋機制，導致上報的日志數據存在錯誤性。

發明內容

鑒于現有技術中的上述缺陷或不足，期望提供一種日志數據傳輸方法、裝置和設備來提高日志傳輸的準確性。

第一方面，本申請實施例提供了一種日志數據傳輸方法，該方法包括：

監聽應用程序產生的日志數據；

實時地將日志數據發送至Kafka消息隊列的第一主題區域；

在日志數據推送出現異常時，重試發送日志數據，

如果重試成功，則停止發送日志數據至Kafka消息隊列；

如果重試未成功，則進一步確定日志數據被發送的次數是否達到閾值；

如果達到閾值，則將所述日志數據發送到第二主題區域；

如果未達到閾值，則重試將日志數據發送到第一主題區域，并進行計數統計，以統計日志數據被發送的次數。

第二方面，本申請實施例提供了一種日志數據傳輸裝置，該裝置包括：

監聽單元，用于監聽應用程序產生的日志數據；

消息發送單元，用于實時地將日志數據發送至Kafka消息隊列的第一主題區域；

異常處理單元，用于在日志數據發送出現異常時，重試發送日志數據，

如果重試成功，則停止發送日志數據至Kafka消息隊列；

如果重試未成功，則進一步確定日志數據被發送的次數是否達到閾值；

如果達到閾值，則將日志數據推送到第二主題區域；

如果未達到閾值，則重試將日志數據發送到第一主題區域，并觸發計數單元執行加1；

計數單元，用于統計日志數據被發送的次數。

本申請實施例提供的日志數據傳輸方法和裝置，其方法通過實時地監聽應用程序產生的日志數據，并將日志數據發送至Kafka消息隊列，當應用程序的日志數據的發送出現異常時，通過重試發送日志數據，然后確定重試結果是否成功，根據確定的結果對日志數據采取容錯處理，有效地避免日志數據的發送錯誤，提高了日志數據傳輸的準確性。