可視化全鏈路日誌追蹤

可觀測性作爲系統高可用的重要保障，已經成爲系統建設中不可或缺的一環。然而隨着業務邏輯的日益複雜，傳統的 ELK 方案在日誌蒐集、篩選和分析等方面愈加耗時耗力，而分佈式會話跟蹤方案雖然基於追蹤能力完善了日誌的串聯，但更聚焦於調用鏈路，也難以直接應用於高效的業務追蹤。

本文介紹了可視化全鏈路日誌追蹤的新方案，它以業務鏈路爲載體，通過有效組織業務每次執行的日誌，實現了執行現場的可視化還原，支持問題的高效定位。

1. 背景

1.1 業務系統日益複雜

隨着互聯網產品的快速發展，不斷變化的商業環境和用戶訴求帶來了紛繁複雜的業務需求。業務系統需要支撐的業務場景越來越廣、涵蓋的業務邏輯越來越多，系統的複雜度也跟着快速提升。與此同時，由於微服務架構的演進，業務邏輯的實現往往需要依賴多個服務間的共同協作。總而言之，業務系統的日益複雜已經成爲一種常態。

1.2 業務追蹤面臨挑戰

業務系統往往面臨着多樣的日常客訴和突發問題，“業務追蹤” 就成爲了關鍵的應對手段。業務追蹤可以看做一次業務執行的現場還原過程，通過執行中的各種記錄還原出原始現場，可用於業務邏輯執行情況的分析和問題的定位，是整個系統建設中重要的一環。

目前在分佈式場景下，業務追蹤的主流實現方式包括兩類，一類是基於日誌的 ELK 方案，一類是基於單次請求調用的會話跟蹤方案。然而隨着業務邏輯的日益複雜，上述方案越來越不適用於當下的業務系統。

1.2.1 傳統的 ELK 方案

日誌作爲業務系統的必備能力，職責就是記錄程序運行期間發生的離散事件，並且在事後階段用於程序的行爲分析，比如曾經調用過什麼方法、操作過哪些數據等等。在分佈式系統中，ELK 技術棧已經成爲日誌收集和分析的通用解決方案。如下圖 1 所示，伴隨着業務邏輯的執行，業務日誌會被打印，統一收集並存儲至 Elasticsearch（下稱 ES）[2]。

圖 1 業務系統 ELK 案例

傳統的 ELK 方案需要開發者在編寫代碼時儘可能全地打印日誌，再通過關鍵字段從 ES 中搜集篩選出與業務邏輯相關的日誌數據，進而拼湊出業務執行的現場信息。然而該方案存在如下的痛點：

• 日誌蒐集繁瑣：雖然 ES 提供了日誌檢索的能力，但是日誌數據往往是缺乏結構性的文本段，很難快速完整地蒐集到全部相關的日誌。

• 日誌篩選困難：不同業務場景、業務邏輯之間存在重疊，重疊邏輯打印的業務日誌可能相互干擾，難以從中篩選出正確的關聯日誌。

• 日誌分析耗時：蒐集到的日誌只是一條條離散的數據，只能閱讀代碼，再結合邏輯，由人工對日誌進行串聯分析，儘可能地還原出現場。

綜上所述，隨着業務邏輯和系統複雜度的攀升，傳統的 ELK 方案在日誌蒐集、日誌篩選和日誌分析方面愈加的耗時耗力，很難快速實現對業務的追蹤。

1.2.2 分佈式會話跟蹤方案

在分佈式系統，尤其是微服務系統中，業務場景的某次請求往往需要經過多個服務、多箇中間件、多臺機器的複雜鏈路處理才能完成。爲了解決複雜鏈路排查困難的問題，“分佈式會話跟蹤方案” 誕生。該方案的理論知識由 Google 在 2010 年《Dapper》論文 [3] 中發表，隨後 Twitter 開發出了一個開源版本 Zipkin[4]。

市面上的同類型框架幾乎都是以 Google Dapper 論文爲基礎進行實現，整體大同小異，都是通過一個分佈式全局唯一的 id（即 traceId），將分佈在各個服務節點上的同一次請求串聯起來，還原調用關係、追蹤系統問題、分析調用數據、統計系統指標。分佈式會話跟蹤，是一種會話級別的追蹤能力，如下圖 2 所示，單個分佈式請求被還原成一條調用鏈路，從客戶端發起請求抵達系統的邊界開始，記錄請求流經的每一個服務，直到向客戶端返回響應爲止。

圖 2 一次典型的請求全過程（摘自《Dapper》）

分佈式會話跟蹤的主要作用是分析分佈式系統的調用行爲，並不能很好地應用於業務邏輯的追蹤。下圖 3 是一個審覈業務場景的追蹤案例，業務系統對外提供審覈能力，待審對象的審覈需要經過 “初審” 和“複審”兩個環節（兩個環節關聯相同的 taskId），因此整個審覈環節的執行調用了兩次審覈接口。如圖左側所示，完整的審覈場景涉及衆多 “業務邏輯” 的執行，而分佈式會話跟蹤只是根據兩次 RPC 調用生成了右側的兩條調用鏈路，並沒有辦法準確地描述審覈場景業務邏輯的執行，問題主要體現在以下幾個方面：

圖 3 分佈式會話跟蹤案例

(1) 無法同時追蹤多條調用鏈路

分佈式會話跟蹤僅支持單個請求的調用追蹤，當業務場景包含了多個調用時，將生成多條調用鏈路；由於調用鏈路通過 traceId 串聯，不同鏈路之間相互獨立，因此給完整的業務追蹤增加了難度。例如當排查審覈場景的業務問題時，由於初審和複審是不同的 RPC 請求，所以無法直接同時獲取到 2 條調用鏈路，通常需要額外存儲 2 個 traceId 的映射關係。

(2) 無法準確描述業務邏輯的全景

分佈式會話跟蹤生成的調用鏈路，只包含單次請求的實際調用情況，部分未執行的調用以及本地邏輯無法體現在鏈路中，導致無法準確描述業務邏輯的全景。例如同樣是審覈接口，初審鏈路 1 包含了服務 b 的調用，而複審鏈路 2 卻並沒有包含，這是因爲審覈場景中存在 “判斷邏輯”，而該邏輯無法體現在調用鏈路中，還是需要人工結合代碼進行分析。

(3) 無法聚焦於當前業務系統的邏輯執行

分佈式會話跟蹤覆蓋了單個請求流經的所有服務、組件、機器等等，不僅包含當前業務系統，還涉及了衆多的下游服務，當接口內部邏輯複雜時，調用鏈路的深度和複雜度都會明顯增加，而業務追蹤其實僅需要聚焦於當前業務系統的邏輯執行情況。例如審覈場景生成的調用鏈路，就涉及了衆多下游服務的內部調用情況，反而給當前業務系統的問題排查增加了複雜度。

1.2.3 總結

傳統的 ELK 方案是一種滯後的業務追蹤，需要事後從大量離散的日誌中搜集和篩選出需要的日誌，並人工進行日誌的串聯分析，其過程必然耗時耗力。而分佈式會話跟蹤方案則是在調用執行的同時，實時地完成了鏈路的動態串聯，但由於是會話級別且僅關注於調用關係等問題，導致其無法很好地應用於業務追蹤。

因此，無論是傳統的 ELK 方案還是分佈式會話跟蹤方案，都難以滿足日益複雜的業務追蹤需求。本文希望能夠實現聚焦於業務邏輯追蹤的高效解決方案，將業務執行的日誌以業務鏈路爲載體進行高效組織和串聯，並支持業務執行現場的還原和可視化查看，從而提升定位問題的效率，即可視化全鏈路日誌追蹤。

下文將介紹可視化全鏈路日誌追蹤的設計思路和通用方案，同時介紹新方案在大衆點評內容平臺的落地情況，旨在幫助有類似需求的業務系統開發需求的同學提供一些思路。

2. 可視化全鏈路日誌追蹤

2.1 設計思路

可視化全鏈路日誌追蹤考慮在前置階段，即業務執行的同時實現業務日誌的高效組織和動態串聯，如下圖 4 所示，此時離散的日誌數據將會根據業務邏輯進行組織，繪製出執行現場，從而可以實現高效的業務追蹤。

圖 4 業務系統日誌追蹤案例

新方案需要回答兩個關鍵問題：如何高效組織業務日誌，以及如何動態串聯業務日誌。下文將逐一進行回答。

問題 1：如何高效組織業務日誌？

爲了實現高效的業務追蹤，首先需要準確完整地描述出業務邏輯，形成業務邏輯的全景圖，而業務追蹤其實就是通過執行時的日誌數據，在全景圖中還原出業務執行的現場。

新方案對業務邏輯進行了抽象，定義出業務邏輯鏈路，下面還是以 “審覈業務場景” 爲例，來說明業務邏輯鏈路的抽象過程：

• 邏輯節點：業務系統的衆多邏輯可以按照業務功能進行拆分，形成一個個相互獨立的業務邏輯單元，即邏輯節點，可以是本地方法（如下圖 5 的 “判斷邏輯” 節點）也可以是 RPC 等遠程調用方法（如下圖 5 的 “邏輯 A” 節點）。

• 邏輯鏈路：業務系統對外支撐着衆多的業務場景，每個業務場景對應一個完整的業務流程，可以抽象爲由邏輯節點組合而成的邏輯鏈路，如下圖 5 中的邏輯鏈路就準確完整地描述了 “審覈業務場景”。

一次業務追蹤就是邏輯鏈路的某一次執行情況的還原，邏輯鏈路完整準確地描述了業務邏輯全景，同時作爲載體可以實現業務日誌的高效組織。

圖 5 業務邏輯鏈路案例

問題 2：如何動態串聯業務日誌？

業務邏輯執行時的日誌數據原本是離散存儲的，而此時需要實現的是，隨着業務邏輯的執行動態串聯各個邏輯節點的日誌，進而還原出完整的業務邏輯執行現場。

由於邏輯節點之間、邏輯節點內部往往通過 MQ 或者 RPC 等進行交互，新方案可以採用分佈式會話跟蹤提供的分佈式參數透傳能力 [5] 實現業務日誌的動態串聯：

• 通過在執行線程和網絡通信中持續地透傳參數，實現在業務邏輯執行的同時，不中斷地傳遞鏈路和節點的標識，實現離散日誌的染色。

• 基於標識，染色的離散日誌會被動態串聯至正在執行的節點，逐漸匯聚出完整的邏輯鏈路，最終實現業務執行現場的高效組織和可視化展示。

與分佈式會話跟蹤方案不同的是，當同時串聯多次分佈式調用時，新方案需要結合業務邏輯選取一個公共 id 作爲標識，例如圖 5 的審覈場景涉及 2 次 RPC 調用，爲了保證 2 次執行被串聯至同一條邏輯鏈路，此時結合審覈業務場景，選擇初審和複審相同的 “任務 id” 作爲標識，完整地實現審覈場景的邏輯鏈路串聯和執行現場還原。

2.2 通用方案

明確日誌的高效組織和動態串聯這兩個基本問題後，本文選取圖 4 業務系統中的 “邏輯鏈路 1” 進行通用方案的詳細說明，方案可以拆解爲以下步驟：

圖 6 通用方案拆解

2.2.1 鏈路定義

“鏈路定義” 的含義爲：使用特定語言，靜態描述完整的邏輯鏈路，鏈路通常由多個邏輯節點，按照一定的業務規則組合而成，業務規則即各個邏輯節點之間存在的執行關係，包括串行、並行、條件分支。

DSL（Domain Specific Language）是爲了解決某一類任務而專門設計的計算機語言，可以通過 JSON 或 XML 定義出一系列節點（邏輯節點）的組合關係（業務規則）。因此，本方案選擇使用 DSL 描述邏輯鏈路，實現邏輯鏈路從抽象定義到具體實現。

圖 7 鏈路的抽象定義和具體實現

邏輯鏈路 1-DSL

  [
    {
      "nodeName": "A",
      "nodeType": "rpc"
    },
    {
      "nodeName": "Fork",
      "nodeType": "fork",
      "forkNodes": [
        [
          {
            "nodeName": "B",
            "nodeType": "rpc"
          }
        ],
        [
          {
            "nodeName": "C",
            "nodeType": "local"
          }
        ]
      ]
    },
    {
      "nodeName": "Join",
      "nodeType": "join",
      "joinOnList": [
        "B",
        "C"
      ]
    },
    {
      "nodeName": "D",
      "nodeType": "decision",
      "decisionCases": {
        "true": [
          {
            "nodeName": "E",
            "nodeType": "rpc"
          }
        ]
      },
      "defaultCase": [
        {
          "nodeName": "F",
          "nodeType": "rpc"
        }
      ]
    }
  ]

2.2.2 鏈路染色

“鏈路染色” 的含義爲：在鏈路執行過程中，通過透傳串聯標識，明確具體是哪條鏈路在執行，執行到了哪個節點。

鏈路染色包括兩個步驟：

步驟一：確定串聯標識，當邏輯鏈路開啓時，確定唯一標識，能夠明確後續待執行的鏈路和節點。

• 鏈路唯一標識  =  業務標識 + 場景標識 + 執行標識 （三個標識共同決定 “某個業務場景下的某次執行”）

• 業務標識：賦予鏈路業務含義，例如 “用戶 id”、“活動 id” 等等。

• 場景標識：賦予鏈路場景含義，例如當前場景是 “邏輯鏈路 1”。

• 執行標識：賦予鏈路執行含義，例如只涉及單次調用時，可以直接選擇 “traceId”；涉及多次調用時則，根據業務邏輯選取多次調用相同的 “公共 id”。

• 節點唯一標識  =  鏈路唯一標識 + 節點名稱 （兩個標識共同決定 “某個業務場景下的某次執行中的某個邏輯節點”）

• 節點名稱：DSL 中預設的節點唯一名稱，如 “A”。

步驟二：傳遞串聯標識，當邏輯鏈路執行時，在分佈式的完整鏈路中透傳串聯標識，動態串聯鏈路中已執行的節點，實現鏈路的染色。例如在 “邏輯鏈路 1” 中：

• 當 “A” 節點觸發執行，則開始在後續鏈路和節點中傳遞串聯標識，隨着業務流程的執行，逐步完成整個鏈路的染色。

• 當標識傳遞至 “E” 節點時，則表示 “D” 條件分支的判斷結果是 “true”，同時動態地將“E” 節點串聯至已執行的鏈路中。

2.2.3 鏈路上報

“鏈路上報” 的含義爲：在鏈路執行過程中，將日誌以鏈路的組織形式進行上報，實現業務現場的準確保存。

圖 8 鏈路上報圖示

如上圖 8 所示，上報的日誌數據包括：節點日誌和業務日誌。其中節點日誌的作用是繪製鏈路中的已執行節點，記錄了節點的開始、結束、輸入、輸出；業務日誌的作用是展示鏈路節點具體業務邏輯的執行情況，記錄了任何對業務邏輯起到解釋作用的數據，包括與上下游交互的入參出參、複雜邏輯的中間變量、邏輯執行拋出的異常。

2.2.4 鏈路存儲

“鏈路存儲” 的含義爲：將鏈路執行中上報的日誌落地存儲，並用於後續的 “現場還原”。上報日誌可以拆分爲鏈路日誌、節點日誌和業務日誌三類：

• 鏈路日誌：鏈路單次執行中，從開始節點和結束節點的日誌中提取的鏈路基本信息，包含鏈路類型、鏈路元信息、鏈路開始 / 結束時間等。

• 節點日誌：鏈路單次執行中，已執行節點的基本信息，包含節點名稱、節點狀態、節點開始 / 結束時間等。

• 業務日誌：鏈路單次執行中，已執行節點中的業務日誌信息，包含日誌級別、日誌時間、日誌數據等。

下圖就是鏈路存儲的存儲模型，包含了鏈路日誌，節點日誌，業務日誌、鏈路元數據（配置數據），並且是如下圖 9 所示的樹狀結構，其中業務標識作爲根節點，用於後續的鏈路查詢。

圖 9 鏈路的樹狀存儲結構

3. 大衆點評內容平臺實踐

3.1 業務特點與挑戰

互聯網時代，內容爲王。內容型平臺的核心打法就是搭建內容流水線，保障內容可持續、健康且有價值地流轉到內容消費者，並最終形成內容 “生產→治理→消費→生產” 的良性循環。

大衆點評和美團 App 擁有豐富多樣的內容，站內外業務方、合作方有着衆多的消費場景。對於內容流水線中的三方，分別有如下需求：

• 內容的生產方：希望生產的內容能在更多的渠道分發，收穫更多的流量，被消費者所喜愛。

• 內容的治理方：希望作爲 “防火牆” 過濾出合法合規的內容，同時整合機器和人工能力，豐富內容屬性。

• 內容的消費方：希望獲得滿足其個性化需求的內容，能夠吸引其種草，或輔助其做出消費決策。

生產方的內容模型各異、所需處理手段各不相同，消費方對於內容也有着個性化的要求。如果由各個生產方和消費方單獨對接，內容模型異構、處理流程和輸出門檻各異的問題將帶來對接的高成本和低效率。在此背景下，點評內容平臺應運而生，作爲內容流水線的 “治理方”，承上啓下實現了內容的統一接入、統一處理和統一輸出：

圖 10 點評內容平臺業務形態

• 統一接入：統一內容數據模型，對接不同的內容生產方，將異構的內容轉化爲內容平臺通用的數據模型。

• 統一處理：統一處理能力建設，積累並完善通用的機器處理和人工運營能力，保證內容合法合規，屬性豐富。

• 統一輸出：統一輸出門檻建設，對接不同的內容消費方，爲下游提供規範且滿足其個性化需求的內容數據。

如下圖 11 所示，是點評內容平臺的核心業務流程，每一條內容都會經過這個流程，最終決定在各個渠道下是否分發。

圖 11 點評內容平臺業務流程

內容是否及時、準確經過內容平臺的處理，是內容生產方和消費方的核心關注，也是日常值班的主要客訴類型。而內容平臺的業務追蹤建設，主要面臨以下的困難與複雜性：

• 業務場景多：業務流程涉及多個不同的業務場景，且邏輯各異，例如實時接入、人工運營、分發重算等圖中列出的部分場景。

• 邏輯節點多：業務場景涉及衆多的邏輯節點，且不同內容類型節點各異，例如同樣是實時接入場景，筆記內容和直播內容在執行的邏輯節點上存在較大差異。

• 觸發執行多：業務場景會被多次觸發執行，且由於來源不同，邏輯也會存在差異，例如筆記內容被作者編輯、被系統審覈等等後，都會觸發實時接入場景的重新執行。

點評內容平臺日均處理百萬條內容，涉及百萬次業務場景的執行、高達億級的邏輯節點的執行，而業務日誌分散在不同的應用中，並且不同內容，不同場景，不同節點以及多次執行的日誌混雜在一起，無論是日誌的蒐集還是現場的還原都相當繁瑣耗時，傳統的業務追蹤方案越來越不適用於內容平臺。

點評內容平臺亟需新的解決方案，實現高效的業務追蹤，因此我們進行了可視化全鏈路日誌追蹤的建設，下面本文將介紹一下相關的實踐和成果。

3.2 實踐與成果

3.2.1 實踐

點評內容平臺是一個複雜的業務系統，對外支撐着衆多的業務場景，通過對於業務場景的梳理和抽象，可以定義出實時接入、人工運營、任務導入、分發重算等多個業務邏輯鏈路。由於點評內容平臺涉及衆多的內部服務和下游依賴服務，每天支撐着大量的內容處理業務，伴隨着業務的執行將生成大量的日誌數據，與此同時鏈路上報還需要對衆多的服務進行改造。因此在通用的全鏈路日誌追蹤方案的基礎上，點評內容平臺進行了如下的具體實踐。

(1) 支持大數據量日誌的上報和存儲

點評內容平臺實現了圖 12 所示的日誌上報架構，支持衆多服務統一的日誌收集、處理和存儲，能夠很好地支撐大數據量下的日誌追蹤建設。

圖 12 點評內容平臺日誌上報架構

日誌收集：各應用服務通過機器上部署的 log_agent 收集異步上報的日誌數據，並統一傳輸至 Kafka 通道中，此外針對少量不支持 log_agent 的服務，搭建瞭如圖所示的中轉應用。

日誌解析：收集的日誌通過 Kafka 接入到 Flink 中，統一進行解析和處理，根據日誌類型對日誌進行分類和聚合，解析爲鏈路日誌、節點日誌和業務日誌。

日誌存儲：完成日誌解析後，日誌會按照樹狀的存儲模型進行落地存儲，結合存儲的需求分析以及各個存儲選項的特點，點評內容平臺最終選擇 HBase 作爲存儲選型。

整體而言，log_agent + Kafka + Flink + HBase 的日誌上報和存儲架構能夠很好地支持複雜的業務系統，天然支持分佈式場景下衆多應用的日誌上報，同時適用於高流量的數據寫入。

(2) 實現衆多後端服務的低成本改造

點評內容平臺實現了 “自定義日誌工具包”（即下圖 13 的 TraceLogger 工具包），屏蔽鏈路追蹤中的上報細節，實現衆多服務改造的成本最小化。TraceLogger 工具包的功能包括：

• 模仿 slf4j-api：工具包的實現在 slf4j 框架之上，並模仿 slf4j-api 對外提供相同的 API，因此使用方無學習成本。

• 屏蔽內部細節，內部封裝一系列的鏈路日誌上報邏輯，屏蔽染色等細節，降低使用方的開發成本。

• 上報判斷：

• 判斷鏈路標識：無標識時，進行兜底的日誌上報，防止日誌丟失。

• 判斷上報方式：有標識時，支持日誌和 RPC 中轉兩種上報方式。

• 日誌組裝：實現參數佔位、異常堆棧輸出等功能，並將相關數據組裝爲 Trace 對象，便於進行統一的收集和處理。

• 異常上報：通過 ErrorAPI 主動上報異常，兼容原日誌上報中 ErrorAppender。

• 日誌上報：適配 Log4j2 日誌框架實現最終的日誌上報。

圖 13 TraceLogger 日誌工具包

下面是 TraceLogger 工具包分別進行業務日誌和節點日誌上報的使用案例，整體的改造成本較低。

業務日誌上報：無學習成本，基本無改造成本。

案例：業務日誌上報

  // 替換前：原日誌上報
  LOGGER.error("update struct failed, param:{}", GsonUtils.toJson(structRequest), e);
  // 替換後：全鏈路日誌上報
  TraceLogger.error("update struct failed, param:{}", GsonUtils.toJson(structRequest), e);

節點日誌上報：支持 API、AOP 兩種上報方式，靈活且成本低。

案例：節點日誌上報

  public Response realTimeInputLink(long contentId) {
    // 鏈路開始：傳遞串聯標識（業務標識 + 場景標識 + 執行標識）
    TraceUtils.passLinkMark("contentId_type_uuid");
    // ...
    // 本地調用(API上報節點日誌)
    TraceUtils.reportNode("contentStore", contentId, StatusEnums.RUNNING)
    contentStore(contentId);
    TraceUtils.reportNode("contentStore", structResp, StatusEnums.COMPLETED)
    // ...
    // 遠程調用
    Response processResp = picProcess(contentId);
    // ...
  }
  // AOP上報節點日誌
  @TraceNode(node)
  public Response picProcess(long contentId) {
    // 圖片處理業務邏輯
    // 業務日誌數據上報
    TraceLogger.warn("picProcess failed, contentId:{}", contentId);
  }

3.2.2 成果

基於上述實踐，點評內容平臺實現了可視化全鏈路日誌追蹤，能夠一鍵追蹤任意一條內容所有業務場景的執行，並通過可視化的鏈路進行執行現場的還原，追蹤效果如下圖所示：

【鏈路查詢功能】：根據內容 id 實時查詢該內容所有的邏輯鏈路執行，覆蓋所有的業務場景。

圖 14 鏈路查詢

【鏈路展示功能】：通過鏈路圖可視化展示業務邏輯的全景，同時展示各個節點的執行情況。

圖 15 鏈路展示

【節點詳情查詢功能】：支持展示任意已執行節點的詳情，包括節點輸入、輸出，以及節點執行過程中的關鍵業務日誌。

圖 16 節點詳情

目前，可視化全鏈路日誌追蹤系統已經成爲點評內容平臺的 “問題排查工具”，我們可以將問題排查耗時從小時級降低到 5 分鐘內；同時也是 “測試輔助工具”，利用可視化的日誌串聯和展示，明顯提升了 RD 自測、QA 測試的效率。最後總結一下可視化全鏈路日誌追蹤的優點：

• 接入成本低：DSL 配置配合簡單的日誌上報改造，即可快速接入。

• 追蹤範圍廣：任意一條內容的所有邏輯鏈路，均可被追蹤。

• 使用效率高：管理後臺支持鏈路和日誌的可視化查詢展示，簡單快捷。

4. 總結與展望

隨着分佈式業務系統的日益複雜，可觀測性對於業務系統的穩定運行也愈發重要 [6]。作爲大衆點評內容流水線中的複雜業務系統，爲了保障內容流轉的穩定可靠，點評內容平臺落地了全鏈路的可觀測建設，在日誌（Logging）、指標（Metrics）和追蹤（Tracing）的三個具體方向上都進行了一定的探索和建設。

其中之一就是本文的 “可視化全鏈路日誌追蹤”，結合日誌（Logging）與追蹤（Tracing），我們提出了一套新的業務追蹤通用方案，通過在業務執行階段，結合完整的業務邏輯動態完成日誌的組織串聯，替代了傳統方案低效且滯後的人工日誌串聯，最終可以實現業務全流程的高效追蹤以及業務問題的高效定位。此外，在指標（Metrics）方向上，點評內容平臺實踐落地了 “可視化全鏈路指標監控”，支持實時、多維度地展示業務系統的關鍵業務和技術指標，同時支持相應的告警和異常歸因能力，實現了對業務系統整體運行狀況的有效把控。

未來，點評內容平臺會持續深耕，實現覆蓋告警、概況、排錯和剖析等功能的可觀測體系 [7]，持續沉澱和輸出相關的通用方案，希望可以爲業務系統（特別是複雜的業務系統），提供一些可觀測性建設的借鑑和啓發。

5. 參考文獻

• [1] Metrics, tracing, and logging

• [2] ELK Stack: Elasticsearch, Logstash, Kibana | Elastic

• [3] Dapper, a Large-Scale Distributed Systems Tracing Infrastructure

• [4] OpenZipkin · A distributed tracing system

• [5] 分佈式會話跟蹤系統架構設計與實踐

• [6] 鳳凰架構 - 可觀測性

• [7] 萬字破解雲原生可觀測性

6. 作者及團隊簡介

海友、懷宇、亞平、立森等，均來自點評事業部 / 內容平臺技術團隊，負責點評內容平臺的建設工作。

點評內容平臺技術團隊，支持點評內容生態的建設，致力於打造支持億級內容的高吞吐、低延時、高可用、靈活可擴展的內容流式處理系統，爲點評信息流和搜索等核心內容分發場景提供豐富且優質的內容供給，更好地滿足用戶內容消費訴求。

美團技術團隊 10000 + 工程師，如何支撐中國領先的生活服務電子商務平臺？數億消費者、數百萬商戶、2000 多個行業、幾千億交易額背後是哪些技術在支撐？這裏是美團、大衆點評、美團外賣、美團配送、美團優選等技術團隊的對外窗口。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Er4-X8q5MKZZUgAUHyeLwA