使用SPL和链路追踪诊断因CPU异常导致的高延迟-开发者社区-阿里云

使用SPL进行诊断前请阅读下面的数据获取文档，确保拥有数据访问权限。

2025 AI 原生编程挑战赛数据获取文档

本指南介绍如何诊断系统高延迟问题的根因，通过分析分布式链路追踪数据和资源指标来定位性能瓶颈。

适用范围：本分析方法专门针对CPU资源异常导致的延迟问题。

对于其他类型的性能问题（如内存不足、网络延迟等），需要使用相应的专门分析方法。

本文提到的相关代码保存在下面的链接中，选手可以通过教程运行notebook中的STS_Root_Cause_Analysis_Latency.ipynb实现根因诊断。

https://github.com/alibabacloud-observability/tianchi-2025

1. 准备开发环境

1.1 安装基础环境

# 安装Python虚拟环境
python3 -m venv venv
source venv/bin/activate
# 安装依赖项
pip install -r requirements.txt

1.2 配置访问凭证

设置环境变量：

export ALIBABA_CLOUD_ACCESS_KEY_ID="你的AccessKey ID"
export ALIBABA_CLOUD_ACCESS_KEY_SECRET="你的AccessKey Secret"

2025.09.22之前上传个人账号的选手，获取的STS角色名为tianchi-user-a。需要设置变量：

export ALIBABA_CLOUD_ROLE_ARN="acs:ram::1672753017899339:role/tianchi-user-a"

2025.09.22到2025.10.09期间，参加比赛并上传个人账号的选手，获取的STS角色名为tianchi-2025-role-1。需要设置变量：

export ALIBABA_CLOUD_ROLE_ARN="acs:ram::1672753017899339:role/tianchi-2025-role-1"

2025.10.10到2025.11.09期间，参加比赛并上传个人账号的选手，获取的STS角色名为tianchi-2025-role-2。需要设置变量：

export ALIBABA_CLOUD_ROLE_ARN="acs:ram::1672753017899339:role/tianchi-2025-role-2"

从2025.11.10开始，参加比赛并上传个人账号的选手，获取的STS角色名为tianchi-2025-role-3。需要设置变量：

export ALIBABA_CLOUD_ROLE_ARN="acs:ram::1672753017899339:role/tianchi-2025-role-3"

1.3 启动分析环境

cd notebook
jupyter notebook STS_Root_Cause_Analysis_Latency.ipynb

2. 分析流程详解

2.1 环境配置和导入

目标: 初始化分析环境，加载必要的Python模块

操作步骤:

执行第一个代码段，检查所有依赖项是否正确导入
如看到✅ All available imports loaded successfully则环境配置成功
如有警告，请按提示安装缺失依赖

输出示例:

✅ FindRootCauseSpansRT imported successfully
✅ TestCMSQuery imported successfully
✅ Constants imported successfully
✅ All available imports loaded successfully
💡 If you see warnings above, please run: pip install -r requirements.txt

2.2 参数配置

目标: 设置分析时间范围和SLS访问参数

配置示例:

# SLS 配置
PROJECT_NAME = "proj-xtrace-a46b97cfdc1332238f714864c014a1b-cn-qingdao"
LOGSTORE_NAME = "logstore-tracing"
REGION = "cn-qingdao"
# 分析时间区间
ANOMALY_START_TIME = "2025-08-28 20:00:20"
ANOMALY_END_TIME = "2025-08-28 20:05:20"
NORMAL_START_TIME = "2025-08-27 20:00:20"
NORMAL_END_TIME = "2025-08-27 20:05:20"
# 分析参数
DURATION_THRESHOLD = 2000000000  # 2000ms（以纳秒为单位）
LIMIT_NUM = 1000  # 分析的 trace 数量
# CMS 指标配置
CMS_WORKSPACE = "quanxi-tianchi-test"
CMS_ENDPOINT = 'metrics.cn-qingdao.aliyuncs.com'

输出示例：

📊 Analysis Configuration:
  SLS Project: proj-xtrace-a46b97cfdc1332238f714864c014a1b-cn-qingdao
  Logstore: logstore-tracing
  Anomaly Period: 2025-08-28 20:00:20 to 2025-08-28 20:05:20
  Normal Period: 2025-08-27 20:00:20 to 2025-08-27 20:05:20
  Duration Threshold: 2.0s
  CMS Workspace: quanxi-tianchi-test

关键参数说明:

ANOMALY_START_TIME、ANOMALY_END_TIME: 异常时间段，故障发生时间（5分钟）
NORMAL_START_TIME、NORMAL_END_TIME: 正常时间段，前一天同时刻作为基线（5分钟）
DURATION_THRESHOLD: 持续时间阈值，2秒以纳秒表示
LIMIT_NUM: 分析数量限制，限制查询1000条trace避免超时

2.3 查找高独占时间的调用段

目标: 识别在异常时段消耗大量独占时间的调用段

操作步骤:

执行2.1 环境配置和导入的代码，初始化分析器
执行独占时间分析方法
查看找到的高独占时间调用段数量和示例spanID

输出示例:

🔍 Step 1: Finding high exclusive time spans...
============================================================
获取独占时间数据...
正常时间段查询到的独占时间日志条数: 3000
开始计算正常时间段的平均独占时间...
收集到 16382 个span的独占时间信息
查询到的日志条数: 2000
🔧 处理模式: 处理每个trace中的所有span
总共找到 9308 个有效的span独占时间数据
成功映射 7426 个span的serviceName和spanName
方案1覆盖率: 79.78% (7426/9308)
✅ 选择方案1：直接使用span_list中的serviceName和spanName（推荐）
🚀 [方案1] 使用span_list中的serviceName和spanName进行调整...
🚀 [方案1] 无需额外查询，直接处理 9308 个span
开始本地计算调整后的独占时间...
完成 9308 个span的时间调整计算
📊 结果:
  共找到 3244 个贡献了独占时间前95%的span
🔍 示例span IDs:
  1. a60372370298137a
  2. 54ba7fd7b19710b8
  3. 316778ebde33de90
  4. e4f52bfdb3a16926
  5. 745f145460b09a98
  ... and 3239 more spans

结果解读:

正常时段查询了3000条记录作为基线
收集16382个span的独占时间信息进行计算
最终找到3244个高独占时间调用段用于后续分析

2.4 模式差异分析 (diff_patterns)

目标: 使用diff_patterns算子发现异常调用段的特征模式

操作步骤:

系统自动生成包含高独占时间spanID的查询条件
执行diff_patterns查询，分析模式差异
解析查询结果，提取serviceName和spanName模式

输出示例:

🔍 Step 2: Pattern analysis with diff_patterns...
============================================================
📋 已生成用于模式分析的 diff_patterns 查询语句
🚀 正在使用SLS客户端执行 diff_patterns 查询...
✅ 模式分析完成：共返回 1 条结果记录
📊 模式分析结果:
  结果 1: {'ret': '[["\\"spanName\\"=\'grpc.oteldemo.CartService/GetCart\'","\\"spanName\\"=\'router flagservice egress\'","\\"serviceName\\"=\'cart\' AND \\"spanName\\"=\'POST /oteldemo.CartService/GetCart\'","\\"serviceName\\"=\'cart\' AND \\"spanName\\"=\'POST\'"],[706,471,466,244],[3456,1690,3239,2202],[0.353,0.2355,0.233,0.122],[0.11432351968243466,0.05590473040026464,0.10714521998015217,0.0728415481309957],[0.23867648031756534,0.17959526959973536,0.12585478001984785,0.04915845186900429],[1.0,1.0,1.0,1.0],[0.0,0.0,0.0,0.0],null]'}
  🔍 Analyzing pattern result: {'ret': '[["\\"spanName\\"=\'grpc.oteldemo.CartService/GetCart\'","\\"spanName\\"=\'router flagservice egress\'","\\"serviceName\\"=\'cart\' AND \\"spanName\\"=\'POST /oteldemo.CartService/GetCart\'","\\"serviceName\\"=\'cart\' AND \\"spanName\\"=\'POST\'"],[706,471,466,244],[3456,1690,3239,2202],[0.353,0.2355,0.233,0.122],[0.11432351968243466,0.05590473040026464,0.10714521998015217,0.0728415481309957],[0.23867648031756534,0.17959526959973536,0.12585478001984785,0.04915845186900429],[1.0,1.0,1.0,1.0],[0.0,0.0,0.0,0.0],null]'}
    📊 Extracted patterns: ['"spanName"=\'grpc.oteldemo.CartService/GetCart\'', '"spanName"=\'router flagservice egress\'', '"serviceName"=\'cart\' AND "spanName"=\'POST /oteldemo.CartService/GetCart\'', '"serviceName"=\'cart\' AND "spanName"=\'POST\'']
    📊 Pattern counts: [706, 471, 466, 244]
    ℹ️ Found spanName pattern: 'grpc.oteldemo.CartService/GetCart' (count: 706)
    ℹ️ Found spanName pattern: 'router flagservice egress' (count: 471)
    ✅ Found serviceName pattern: 'cart' (count: 466)
    ✅ Found serviceName pattern: 'cart' (count: 244)
🎯 识别出的service模式:
  - cart: 710 次模式匹配
💡 在模式中出现最多的serviceName: cart

结果解读:

spanName模式: grpc.oteldemo.CartService/GetCart 在异常span中出现706次，router flagservice egress出现471次
服务模式: cart 服务的相关模式共出现710次
目标确定: 系统自动设置TARGET_SERVICE = "cart"用于后续CPU分析

2.5 CPU指标分析

目标: 分析识别出的目标服务的CPU使用情况

分析维度:

CPU使用率vs限制 (deployment_cpu_usage_vs_limits) - 查看CPU使用率是否接近限制
CPU绝对使用量 (deployment_cpu_usage_total) - 查看CPU使用量的绝对变化

Kubernetes概念映射:

serviceName (链路追踪) ↔ deployment name (Kubernetes)
deployment → pod → container 的层级关系
CPU指标在deployment级别聚合

操作步骤:

系统根据模式分析结果自动确定TARGET_SERVICE
执行CPU使用率查询，获取时序数据
对比异常时段和正常时段的CPU使用情况
执行内存使用率查询作为对比验证

2.6 异常检测 (series_decompose_anomalies)

目标: 使用机器学习算法自动检测CPU指标异常

操作步骤:

对目标服务执行CPU异常检测查询
统计异常点数量和类型
根据异常点数量判断是否存在显著异常

2.7 根因分析总结

目标: 综合所有证据，得出最终的根因判断

证据权重评估:

span证据: 是否找到高独占时间的span
模式证据: 是否成功识别目标服务
指标证据: 是否获取到CPU/内存数据
异常证据: 是否检测到显著异常（≥3个异常点）

置信度评级:

高置信度: span证据 + 模式证据 + 指标证据 + 异常证据 (≥3异常点)
中置信度: span证据 + 模式证据 + 指标证据，但异常证据不足
低置信度: 证据不足或无法确定目标服务

根因候选格式: {service}.cpu (如: recommendation.cpu, cart.cpu)

输出示例:

🎯 最终答复：cart.cpu
📈 置信度：高
🔍 证据：TRUE
📝 支持证据：
   - 发现 3244 个高独占时间span
   - 模式分析表明涉及服务 cart
   - 自动异常检测确认了CPU使用异常
   - 检测到 210 个异常点（已达≥3阈值）

2.8 附加分析

目标: 分析其他服务的异常情况，排除其他可能的根因

分析范围: frontend、cart、checkout、payment、shipping、currency、ad、recommendation等常见服务

操作逻辑:

对每个服务执行CPU和内存异常检测
统计各服务的异常点数量
识别是否有其他服务也出现异常

结果用途:

验证主要根因的唯一性
发现可能的次要影响服务
了解系统健康状况

3. 可能出现报错的情况

如果在运行代码时报错如下：

大概率是系统的后台没有及时获取到选手的账号ID，这时候可以去比赛界面的【数据获取】入口再次上传您的账号ID，就能让系统立即发现您的账号，并授权。

4. 代码中的默认参数介绍

代码中涉及到的参数介绍：

PROJECT_NAME：日志服务项目名称，默认为proj-xtrace-a46b97cfdc1332238f714864c014a1b-cn-qingdao
LOGSTORE_NAME：日志库名称，默认为logstore-tracing
REGION：地域，默认为cn-qingdao
CMS_WORKSPACE：云监控工作区间，这是您进行宏观监控和发现异常的主要入口。默认为quanxi-tianchi-test
CMS_ENDPOINT：云监控API接入地址，这是云监控服务的API终端地址，所有通过程序（如SDK、命令行工具）对云监控指标数据的请求，都需要发送到这个地址。默认为metrics.cn-qingdao.aliyuncs.com

使用SPL快速诊断问题根因 -- 延迟分析指南

使用SPL进行诊断前请阅读下面的数据获取文档，确保拥有数据访问权限。

1. 准备开发环境

1.1 安装基础环境

1.2 配置访问凭证

2. 分析流程详解

2.1 环境配置和导入

2.2 参数配置

2.3 查找高独占时间的调用段

2.4 模式差异分析 (diff_patterns)

2.5 CPU指标分析

2.6 异常检测 (series_decompose_anomalies)

2.7 根因分析总结

2.8 附加分析

3. 可能出现报错的情况

4. 代码中的默认参数介绍

参考文档

热门文章

最新文章

相关电子书

探索云世界

热门

云计算

大数据

云原生

人工智能

数据库

开发与运维

活动广场

任务中心

训练营

直播

乘风者计划

下载

镜像站

技术资料

使用SPL快速诊断问题根因 -- 延迟分析指南

使用SPL进行诊断前请阅读下面的数据获取文档，确保拥有数据访问权限。

1. 准备开发环境

1.1 安装基础环境

1.2 配置访问凭证

2. 分析流程详解

2.1 环境配置和导入

2.2 参数配置

2.3 查找高独占时间的调用段

2.4 模式差异分析 (diff_patterns)

2.5 CPU指标分析

2.6 异常检测 (series_decompose_anomalies)

2.7 根因分析总结

2.8 附加分析

3. 可能出现报错的情况

4. 代码中的默认参数介绍

参考文档

热门文章

最新文章

相关电子书