OpenTracing——設計分散式追蹤系統的有效方法

當開始設計分散式跟蹤系統時，第一步先把跨RPC/IPC之間的 span 串聯起來，這樣整條 trace 才能通。你可以從使用支援 OpenTracing 標準的服務框架開始 (如：gRPC)。

專注高價值區域

從 RPC 層和你的 web 框架開始構建並走通整條 trace 鏈路。下一步，再從沒有被 RPC 和 WEB 服務框架覆蓋到的其他關鍵節點上，比如：redis、mysql、訊息中介軟體等資料儲存耗時的操作上進行節點監控。為高價值的事務建立一條關鍵鏈路的追蹤軌跡。注意：是關鍵路徑，一條鏈路過多的span節點，會對業務效能造成的不良影響

先走再跑，逐步提高

設計分散式跟蹤系統，最大的價值在於為關鍵事務生產端到端的追蹤。視覺化展示所有 sample 到的追蹤列表，並對 error 或者 timeout 等 trace 列表進行分析，並找到相應 trace span 執行單元的業務耗時，並進行業務優化。並對業務開發人員進行業務優化關鍵點有一定的指導意義，並根據豐富的資料包表統計，對同一類 trace 問題多，流量大的業務關鍵路徑進行優化或者重新設計。

同時 trace 關鍵路徑上的所有 span 節點，也可以根據 dashboard UI 分析資料統計的情況，進行細粒度的追蹤或者粗粒度的追蹤。

監控框架

總體來說，整合 OpenTracing，你需要做兩件事情：

服務端框架修改需求：

1. 過濾器、攔截器、中介軟體或者其他處理輸入請求的元件；
2. span 的儲存，存差異 request context 或者 request 到 span 的對映表；
3. 通過某種方式對 tracer 進行配置

客戶端框架修改需求：

1. 過濾器、攔截器、中介軟體或者其他處理對外呼叫的請求元件；
2. 通過某種方式對 tracer 進行配置

Operation Name

當業務方沒有指定 Operation Name 時，預設的 Operation Name 示例：

1. request handler 的方法名
2. web 請求路徑
3. RPC 服務名 + 方法名

注意：
    如果是RESTful風格，url上不要帶值, 例如：
    /v1/products/:product_id/code/:code 

    request url：
    /v1/products/123/code/YN_001

    則操作名預設最好為前者，
    product_id: 123, code: YN_001 附帶在span tag上。

確定需要追蹤的請求

有些使用者希望追蹤所有的請求，同時，有些使用者只需要追蹤特定的請求。所以分散式跟蹤系統的設計，應該允許使用者去設定是否需要追蹤，以滿足這兩種場景。兩種方法：

1. 使用程式的註解，提供@trace標註，被標註的方法會被追蹤。
2. 提供一種配置，允許使用者去設定他們是否使用標準，所有的請求是不是應該被追蹤。

當然，第一種方式是最友好方便的。GO 語言標註實現可以參考 Beego web 框架

追蹤請求的屬性

使用者可能需要追蹤關於請求的一些資訊，而不希望直接去操作 span 或者為 span 設定 tag。為使用者提供一種方式設定需要追蹤的請求屬性，並自動追蹤這些屬性值，是十分有幫助的。Functional options for friendly APIs 。

// SpanDecorator binds a function that decorate gRPC Spans.
func SpanDecorator(decorator SpanDecoratorFunc) Option{
    return func(o *options) {
        o.decorator = decorator
    }
}

另一種方式，是設定TRACED_REQUEST_ATTRIBUTES, 允許使用者傳遞一個列表（例如：URL, MOTHOD, HEADERS）, 然後你會在追蹤過濾器中，包含這些屬性中：

for attr in setting. TRACED_REQUEST_ATTRIBUTES:
    if hasattr(request, attr):
        payload = str(getattr(request, attr))
        span.set_tag(attr, payload)