[發明專利]一種全鏈路追蹤監控方法

在審

• 申請號: 201810803491.1
• 申請日: 2018-07-18
• 公開（公告）號: CN109104302A
• 公開（公告）日: 2018-12-28
• 發明（設計）人: 楊君;李恒;劉義雷;鄧道成
• 申請（專利權）人: 杭州鑫合匯互聯網金融服務有限公司
• 主分類號: H04L12/24
• 分類號: H04L12/24
• 代理公司: 暫無信息
• 代理人: 暫無信息

本發明公開了一種全鏈路追蹤監控方法，其特征在于，包括以下步驟，步驟S1：埋點和生成格式化日志；步驟S2：收集和存儲日志；步驟S3：關聯上下游信息，實時計算報警。本發明用于展示異常節點上下文調用關系，定位故障業務來源，實時報警，關聯異常堆棧日志，找到異常根源。

技術領域

本發明涉及日志異常監測技術領域，尤其涉及一種全鏈路追蹤監控方法。

背景技術

目前公司系統正往服務化方向發展，涉及到的業務子系統眾多，系統之間存在互相調用的情況。那么接口之間就存在著各種上下游調用關系，當某個節點拋出了一個異常，我們很難定位上下游的調用關系，較難排查異常是由哪個節點調用產生的。同時，各個接口的調用情況我們無法做一個直觀，全面的查看，對于各個服務接口的“健康度”較難做一個整體診斷。在此背景下我們希望能夠建立一套全面有效的鏈路監控系統，為系統服務化做基礎支撐。

發明內容

本發明的目的在于提供一種全鏈路追蹤監控方法，展示異常節點上下文調用關系，定位故障業務來源，實時報警，關聯異常堆棧日志，找到異常根源。

為實現上述目的，本發明提供如下技術方案：

一種全鏈路追蹤監控方法，其特征在于，包括以下步驟，

步驟S1：埋點和生成格式化日志；

步驟S2：收集和存儲日志；

步驟S3：關聯上下游信息，實時計算報警。

進一步的，所述步驟S1的具體內容如下：通過提供獨立組件的方式，與業務代碼進行分離，在系統底層進行記錄請求參數信息和請求結果數據，所述請求參數信息包括全局唯一跟蹤標識TraceID和鏈路層級標識SpanID，所述請求結果數據包括響應狀態、響應大小和響應時間，并將請求參數信息與請求結果數據通過json格式共同寫入到文本日志。

進一步的，所述請求參數信息中唯一跟蹤標識TraceID為日志的唯一標識，在應用請求入口生成，并跟隨下游請求附加到header中進行透傳；鏈路層級標識SpanID代為上下游關系的層級ID，表示日志對應的子系統在鏈路中所處的層級。

進一步的，所述請求結果數據中響應狀態為http狀態碼，響應大小為請求下級子系統返回的消息體的內存大小，響應時間為調用下級子系統所使用的時間。

進一步的，所述步驟S3的具體內容如下：對日志中的請求結果數據進行分析判斷是否異常，具體的，將響應狀態、響應大小和響應時間分別與預先設定的數值區間進行比較，若在對應數值區間內，則判斷為正常，否則判斷為異常；然后將存在任意異常的日志提取出來，發出報警，再根據請求參數信息關聯上下游，調用對應鏈路的所有日志，并將結果反饋給開發人員。

進一步的，所述步驟S2的具體內容如下：通過filebeat服務實時監聽日志并推送到Kafka消息系統中，然后使用Storm框架將請求數據結果保存到Elasticsearch索引和Mongodb數據庫中。

與現有技術相比，本發明的有益效果是：本發明展示異常節點上下文調用關系，定位故障業務來源并進行實時報警；本發明還了解每個請求內部的交互過程，分析內部瓶頸點，如統計響應時間、出錯率等；實時報警，關聯異常堆棧日志，找到異常根源。

附圖說明

圖1為本發明的總流程圖。

圖2為本發明的日志埋點工作流程圖。

具體實施方式

下面對本發明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發明一部分實施例，而不是全部的實施例。基于本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬于本發明保護的范圍。