全部產品
Search

搜尋本產品

    Application Real-Time Monitoring Service：業務鏈路最佳實務

    文件中心

    Application Real-Time Monitoring Service：業務鏈路最佳實務

    更新時間：Jan 21, 2026

    本文基於電商平台情境，從研發和營運角度介紹如何通過業務鏈路解決問題。

    樣本情境

    某電商平台全業務系統已全面接入ARMS實現全鏈路監控能力，支撐日常營運中的效能監控、故障定位及容量分析。在即將到來的珠寶品類大促活動期間，技術保證團隊召開專項會議部署保障方案時，發現現有監控體系存在以下關鍵問題：

    • 業務維度監控缺失

      研發團隊在查看下單介面監控詳情時發現，現有系統僅支援介面級指標彙總（如QPS、RT、錯誤率），無法按業務類目（如珠寶/服飾/3C等）進行流量分層分析。這導致：

      • 大促期間珠寶類目流量突增時，無法精準識別其對系統資源的真實消耗。

      • 異常警示配置無法針對珠寶類目交易鏈路進行獨立閾值設定。

      image.png

    • 容量評估能力不足

      營運團隊在分析服務拓撲架構時發現，現有依賴關係拓撲圖僅能展示服務間靜態調用關係，缺乏動態業務流量映射能力。具體表現為：

      • 無法量化珠寶類目業務流量在各微服務元件中的實際承載量。

      • 擴容決策缺乏資料支撐，無法科學評估訂單服務、庫存服務等核心模組的擴容比例。

      image.png

    業務鏈路分析實踐

    通過業務鏈路分析功能可有效解決上述問題。

    1. 業務入口標記：識別並標記承載珠寶類目交易的業務入口應用（如訂單服務入口網關）。

    2. 全自動鏈路追蹤：基於分布式鏈路追蹤技術，自動將業務流量沿著完整調用鏈路（從入口應用到支付、庫存等下遊服務）細化追蹤至介面級粒度，並進行業務染色標記。

      image

    3. 智能警示配置：支援基於業務維度獨立警示策略（如珠寶類目支付鏈路耗時超過閾值時觸發專項警示）。

    步驟一：提取業務參數

    通過配置業務參數擷取規則，系統可自動從請求參數中解析出業務維度標識。以珠寶類目下單介面為例，在入參裡擷取“類目”資訊，範例程式碼中下單類目資訊在CommonRequestBody對象裡。

    @RequestMapping(value = "/order", produces = "application/json", method = RequestMethod.POST)
    public CommonResult<?> order(@RequestBody CommonRequestBody requestBody) throws Exception {
        bizO11yHandleService.syncCall(requestBody);
        return CommonResult.succeeded(new CommonData("Cache",
                "{\"param1\":\"value1\",\"resultCode\":" + requestBody.getCode() + "}",
                "succeeded.", requestBody.getCode()));
    }

    在下單介面CommonRequestBody中，業務類目標識category儲存在請求體的嵌套對象extraInfo中：

    CommonRequestBody

    @Data
public class CommonRequestBody {

    private String requestId;

    private int code;

    private boolean needDetail;

    private Map<String, String> extraInfo;
}

    CommonRequestBody JSON請求體

    {
  "code": 200,
  "needDetail": true,
  "requestId": "req-32413",
  "extraInfo": {
    "orderNumber": "ord-xxxxx",
    "level": "vip",
    "arms": "good",
    "source": "app",
    "category": "jewelry"
  }
}

    找到類目資訊後，即可在入口應用的應用配置 > 業務參數擷取規則頁面以無代碼入侵的方式，提取類目下的category屬性。具體操作，請參見提取業務參數。

    image

    參數

    說明

    樣本值

    規則名稱

    自訂規則名稱。

    類目

    Attribute名稱

    規則提取出的值在Span中對應的Attribute名稱。

    category

    參數提取類型

    需要提取的參數類型。

    HTTP服務端請求

    參數規則配置

    • 生效介面（HTTP類型）：該條規則作用的HTTP介面範圍，探針僅對匹配成功的介面提取相應參數。

    • 文本編碼類別型：待提取參數文本的編碼類別型。

    • 參數擷取規則：

      • 參數來源：待提取參數所在的實際載體來源。

      • 參數處理步驟：流式的參數處理步驟，用於從參數載體中逐步解析出最終的參數值。

    • 生效介面：等於/api/v1/biz/order

    • 文本編碼類別型：UTF-8

    • 參數擷取規則：

      • 參數來源：Body

      • Ognl：extraInfo

      • JsonPath：category

    是否啟用

    該條規則是否啟用。

    開啟

    步驟二：配置業務鏈路

    基於已提取的category業務參數，在業務鏈路列表頁面配置針對該業務參數的調用鏈路。具體操作，請參見建立業務鏈路。

    image.png

    參數

    說明

    樣本值

    業務鏈路名稱

    自訂業務鏈路名稱。

    珠寶下單

    業務鏈路標識

    參數值會落到指標上用於標記對應業務鏈路，需要唯一。

    jewelry_order

    入口應用

    選擇業務的入口應用，入口應用的探針版本需為4.3.0或以上。

    biz-trace-demo

    入口介面

    選擇業務的入口介面，目前只支援HTTP的介面。

    /api/v1/biz/order

    特徵參數

    基於入口介面的出入參，做更精細的匹配非必填。

    -

    特徵鏈路配置

    • 同時滿足下述規則，規則的“且”邏輯，在多個規則參數配置的情況下，都滿足才會被認定為業務。

    • 滿足下述一條規則，規則的“或”邏輯，在多個規則參數配置的情況下，有一個匹配就會被認定為業務。

    同時滿足下述規則

    規則參數

    • 業務參數規則，可選內容為入口應用上配置的業務參數擷取規則。

    • 匹配規則，目前可選值“包含”。

    • 規則值，可以多選，未上報的值可以自訂輸入添加。

    名稱為類目的業務參數規則中值包含jewelry

    查看鏈路詳情

    業務鏈路建立完成後，ARMS探針將會自動識別對應鏈路。在業務鏈路列表頁面單擊珠寶下單，即可查看業務鏈路詳情，如圖所示珠寶類目下單鏈路將從原始全量下單鏈路中獨立出來，形成專用監控視圖。

    image.png

    通過業務鏈路分析功能，營運團隊可直接在ARMS拓撲圖中觀察珠寶類目下單鏈路的完整依賴關係，關鍵的應用和介面，入口流量到各個應用的請求。結合以上資料營運團隊即可針對性地給出本次活動的架構依賴以及擴容比例的依據。

    步驟三：配置警示

    將珠寶下單鏈路獨立出來後，就可以基於該鏈路單獨配置警示。

    業務鏈路監控資料來源預設整合至可觀測監控 Prometheus 版，對應的執行個體名稱為metricstore-apm-metrics-custom_<regionId>_default-cms-<userId>-<region>。通過編寫PromQL語句可以完成自訂警示配置。

    假設訂單請求數超過1就警示，對應的PromQL如下：

    sum(sum_over_time_lorc(arms_biz_app_requests_count_raw{_biz_code="jewelry_order",serverIp=~".*",callKind=~"http|rpc|custom_entry|server|consumer|schedule",pid="ckv8e2vzfj@f17de22dde9bd19",rpc=~"/api/v1/biz/order",source="apm",}[1m]))>1
    說明

    建立Prometheus警示規則的操作，請參見建立Prometheus警示規則。

    image.png

    如何編寫PromQL

    單擊監控詳情面板上的image表徵圖，可以查看對應面板的PromQL。具體操作，請參見查詢語句。

    image

    例如對於以下PromQL：

    sum(sum_over_time_lorc(arms_biz_app_requests_count_raw{_biz_code="jewelry_order",serverIp=~".*",callKind=~"http|rpc|custom_entry|server|consumer|schedule",pid="ckv8e2vzfj@f17de22dde9bd19",rpc=~"/api/v1/biz/order",source="apm",}[$__range])) or vector(0)

    去掉預留位置並加上警示的匹配條件（此處樣本佈建要求數大於1），修改後的PromQL如下：

    sum(sum_over_time_lorc(arms_biz_app_requests_count_raw{_biz_code="jewelry_order",serverIp=~".*",callKind=~"http|rpc|custom_entry|server|consumer|schedule",pid="ckv8e2vzfj@f17de22dde9bd19",rpc=~"/api/v1/biz/order",source="apm",}[1m]))>1

    查看警示通知

    警示配置完成後，當有符合的流量進來時就會觸發警示。除此之外，您還可以針對大促情境，定製基於錯誤率、耗時等指標的警示規則。

    您可以在業務鏈路分析的事件分析頁面，查看所有已產生的警示事件。

    步驟四：自訂查詢

    現在需要自訂做更進階的操作，比如針對“珠寶下單”中調用發送訊息的量做內部分析，通過調用介面來擷取對應的值。這裡支援通過從SLS的儲存裡調用介面擷取需要的值。

    儲存路徑：

    • SLS Project:proj-xtrace-<encode>-<region-id>。

    • SLS MetricStore:metricstore-apm-metrics-custom。

    這裡“珠寶下單”中調用發送訊息的量，可以從頁面上擷取對應的promql

    將對應的查詢語句，直接粘貼到對應sls 儲存裡可以直接查詢，這裡$__range是預留位置，在sls使用裡需要根據實際情況作替換，比如1m表示步長1分鐘。

    語句調試沒問題，就可以使用sls的getLogsV2介面進行調用查詢。

    查詢參數示意

    在控制台上可以直接使用promql查詢，這邊調用介面時，需要按照PromQL函數做下處理：

    sum(sum_over_time_lorc(arms_biz_app_requests_count_raw{_biz_code="jewelry_order",pid="ckv8e2vzfj@2be3e49d1d76cfd",serverIp=~".*",callKind=~"http|rpc|custom_entry|server",rpc=~"/api/send/msg",source="apm",}[1m]))
    * | select promql_query_range('sum(sum_over_time_lorc(arms_biz_app_requests_count_raw{_biz_code="jewelry_order",pid="ckv8e2vzfj@2be3e49d1d76cfd",serverIp=~".*",callKind=~"http|rpc|custom_entry|server",rpc=~"/api/send/msg",source="apm",}[1m]))') from metrics limit 10000