业务链路最佳实践_应用实时监控服务(ARMS)-阿里云帮助中心

本文基于电商平台场景，从研发和运维角度介绍如何通过业务链路解决问题。

示例场景

某电商平台全业务系统已全面接入ARMS实现全链路监控能力，支撑日常运营中的性能监控、故障定位及容量分析。在即将到来的珠宝品类大促活动期间，技术保障团队召开专项会议部署保障方案时，发现现有监控体系存在以下关键问题：

业务维度监控缺失
研发团队在查看下单接口监控详情时发现，现有系统仅支持接口级指标聚合（如QPS、RT、错误率），无法按业务类目（如珠宝/服饰/3C等）进行流量分层分析。这导致：
- 大促期间珠宝类目流量突增时，无法精准识别其对系统资源的真实消耗。
- 异常告警配置无法针对珠宝类目交易链路进行独立阈值设定。
容量评估能力不足
运维团队在分析服务拓扑架构时发现，现有依赖关系拓扑图仅能展示服务间静态调用关系，缺乏动态业务流量映射能力。具体表现为：
- 无法量化珠宝类目业务流量在各微服务组件中的实际承载量。
- 扩容决策缺乏数据支撑，无法科学评估订单服务、库存服务等核心模块的扩容比例。

业务链路分析实践

通过业务链路分析功能可有效解决上述问题。

业务入口标记：识别并标记承载珠宝类目交易的业务入口应用（如订单服务入口网关）。
全自动链路追踪：基于分布式链路追踪技术，自动将业务流量沿着完整调用链路（从入口应用到支付、库存等下游服务）细化追踪至接口级粒度，并进行业务染色标记。
智能告警配置：支持基于业务维度的独立告警策略（如珠宝类目支付链路耗时超过阈值时触发专项告警）。

步骤一：提取业务参数

通过配置业务参数提取规则，系统可自动从请求参数中解析出业务维度标识。以珠宝类目下单接口为例，在入参里获取“类目”信息，示例代码中下单类目信息在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属性。具体操作，请参见提取业务参数。

参数	说明	示例值
规则名称	自定义规则名称。	类目
Attribute名称	规则提取出的值在Span中对应的Attribute名称。	category
参数提取类型	需要提取的参数类型。	HTTP服务端请求
参数规则配置	生效接口（HTTP类型）：该条规则作用的HTTP接口范围，探针仅对匹配成功的接口提取相应参数。文本编码类型：待提取参数文本的编码类型。参数提取规则：参数来源：待提取参数所在的实际载体来源。参数处理步骤：流式的参数处理步骤，用于从参数载体中逐步解析出最终的参数值。	生效接口：等于/api/v1/biz/order 文本编码类型：UTF-8 参数提取规则：参数来源：Body Ognl：extraInfo JsonPath：category
是否启用	该条规则是否启用。	开启

步骤二：配置业务链路

基于已提取的category业务参数，在业务链路列表页面配置针对该业务参数的调用链路。具体操作，请参见新建业务链路。

参数	说明	示例值
业务链路名称	自定义业务链路名称。	珠宝下单
业务链路标识	参数值会落到指标上用于标记对应业务链路，需要唯一。	jewelry_order
入口应用	选择业务的入口应用，入口应用的探针版本需为4.3.0或以上。	biz-trace-demo
入口接口	选择业务的入口接口，目前只支持HTTP的接口。	/api/v1/biz/order
特征参数	基于入口接口的出入参，做更精细的匹配非必填。	-
特征链路配置	同时满足下述规则，规则的“且”逻辑，在多个规则参数配置的情况下，都满足才会被认定为业务。满足下述一条规则，规则的“或”逻辑，在多个规则参数配置的情况下，有一个匹配就会被认定为业务。	同时满足下述规则
规则参数	业务参数规则，可选内容为入口应用上配置的业务参数提取规则。匹配规则，目前可选值“包含”。规则值，可以多选，未上报的值可以自定义输入添加。	名称为类目的业务参数规则中值包含jewelry

查看链路详情

业务链路创建完成后，ARMS探针将会自动识别对应链路。在业务链路列表页面单击珠宝下单，即可查看业务链路详情，如图所示珠宝类目下单链路将从原始全量下单链路中独立出来，形成专用监控视图。

通过业务链路分析功能，运维团队可直接在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告警规则。

如何编写PromQL

单击监控详情面板上的图标，可以查看对应面板的PromQL。具体操作，请参见查询语句。

例如对于以下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

查看告警通知

告警配置完成后，当有符合的流量进来时就会触发告警。除此之外，您还可以针对大促场景，定制基于错误率、耗时等指标的告警规则。

您可以在业务链路分析的事件分析页面，查看所有已产生的告警事件。