比赛术语说明

平台与入口

CloudMonitor 2.0（CMS 2.0，云监控 2.0）

阿里云统一的观测与告警平台，覆盖 Metric / Trace / Log / Event / Entity 五大数据域；题目数据在此查询与回放（CMS产品官方文档，CMS Otel Demo介绍，CMS Demo）。

SLS（日志服务）

日志与 Trace 数据的查询与分析平台；支持 SPL 高阶函数（模式挖掘、异常检测等）。常用于对 Copilot 结论做交叉验证（SLS产品官方文档）。

Workspace（工作空间）

观测数据的租户边界（示例：tianchi-2025）,进入控制台后需先选择正确工作空间，在页面刷新后请确保自己在tianchi-2025。

Region（地域）

数据所在区域（示例：cn-qingdao）。输入时间窗与查询均以该区域数据为准。

APM / Trace Explorer（应用监控 / 调用链分析）

查看 Trace 列表与详情的入口；支持按错误/异常、时间窗筛选，配合拓扑快速定位最下游第一故障 span。

Service Map（服务拓扑）

服务依赖可视化；节点/调用边展示错误率与时延，支持双击下钻。用于识别“主犯服务 vs 受害上游”。

Entity Explorer（实体查询）

云监控 2.0 的实体（K8s）维度分析入口；可用 SPL 的 entity_set / entity-call 调取 Deployment/Pod/Node 指标。

Copilot（页面内智能助手）

用于自动生成排障线索/解释。最终结论需以 Trace/日志/SPL 交叉验证为准。

数据模型与关键字段

Trace（调用链）

一次分布式调用的全貌，由多个 Span 组成。字段：traceId、serviceName、spanName 等。

Span

调用链中的一个区段（服务/方法/外呼）；字段：

• spanId、parentSpanId（父子关系）
  
• statusCode（0/1 正常；2/3 错误/异常）
  
• statusMessage（错误文本或异常摘要）
  
• resources（JSON 扩展标签，见下）
  

resources（Trace/Span 扩展标签）

常用键：k8s.pod.ip、k8s.node.name、service.version。用于把异常定位到 Pod/Node/版本。

Log（日志）

与 Trace 通过 traceId/spanId 关联；正文看 statusMessage，事件标记常在 events 字段。

Metric（指标）

本赛题告警口径涉及：

• arms_app_requests_error_count_raw（报错数，30s 粒度）
  
• arms_app_requests_seconds_raw{service="frontend"}（RT，单位秒）
  

Event（事件）

K8s 维度的变化/异常（如 Pod 逐出、Node NotReady）。用于验证 nodeKiller、OOM/重启等系统征兆。

K8s 实体层级（与 serviceName 的关系）

Deployment / Pod / Container / Node

• Deployment：一组相同 Pod 的编排单位（本赛题中 serviceName ≈ Deployment 名）。
  
• Pod：最小可调度单元，承载容器。
  
• Node：K8s 节点（虚机/物理机）。
  在 Entity Explorer 中可按 Deployment 拉取 CPU/内存等指标并追溯至 Pod/Node。
  

告警与 PromQL 口径

overall_error_count（系统总错误数）

告警规则：30s 粒度总报错数 > 50。

PromQL：

(sum(arms_app_requests_error_count_raw) > bool 50)[2d:30s]

frontend_avg_rt（前端平均时延）

告警规则：frontend 服务 30s 平均 RT > 0.5s。

PromQL：

(avg(arms_app_requests_seconds_raw{service="frontend"}) > bool 0.5)[2d:30s]

术语：> bool 产生布尔序列；[2d:30s] 为区间向量（过去 2 天，按 30s 抽样）。

SPL（日志/实体查询）关键算子

以下介绍SPL关键算子，更多的SPL学习资料请见SPL教程手册

基础管道

project（列选择）、where、stats（聚合）、extend（新增列）、unnest（展开数组）。

远程函数开关

在 SLS 查询前置：

set session enable_remote_functions=true;
set session velox_support_row_constructor_enabled=true;

模式挖掘

• get_log_patterns(contents, separators, options)：从日志集合抽取高频模式与变量位。
  
• diff_patterns(table_row, cols, label_col, pos_label, neg_label)：对比异常/正常两类数据的差异模式。
  

序列异常分解

series_decompose_anomalies(series, options)：对时间序列做异常点检测，返回得分与类型。

实体指标调用

• entity_set with(domain, name, query=...)：选定实体集合（如 k8s.deployment）。
  
• entity-call get_metric(domain, metric_set, metric_name, range, step)：按实体批量取指标序列。
  示例（查看 recommendation 的 CPU 使用与阈值占比）：
  

.entity_set with(domain='k8s', name='k8s.deployment', query=`name='recommendation'`)
| entity-call get_metric('k8s','k8s.metric.high_level_metric_deployment','deployment_cpu_usage_total','range','1m')
.entity_set with(domain='k8s', name='k8s.deployment', query=`name='recommendation'`)
| entity-call get_metric('k8s','k8s.metric.high_level_metric_deployment','deployment_cpu_usage_vs_limits','range','1m')

时间与窗口

time_range（题目时间窗）

题目给定的唯一有效分析窗口。格式：

YYYY-MM-DD HH:mm:ss ~ YYYY-MM-DD HH:mm:ss（中间 空格 + ~ + 空格；左右边界包含）。

控制台按 北京时间（UTC+8） 解析；请原样粘贴题面时间。

execution_time_range（执行时间窗）

参赛者实际运行脚本/工具的起止时间（决赛必填，用于审计重放），格式与 time_range 一致。

根因命名与注入类型

语法

.

• component：小写+短横线（例 frontend-proxy、product-catalog）
  
• faultType：驼峰（camelCase）
  

故障类型

• failure：联通正常但返回业务错误（错误率↑）。
  
• unreachable：不可达/超时（长尾时延↑）。
  
• networkLatency：跨服务链路普慢（调用边拉长）。
  
• cpu：服务内部计算饱和（段内 RT 普涨）。
  
• memory：内存压力/OOM（重启/抖动）。
  
• largeGc：JVM 大 GC（短时尖峰暂停）。
  
• cacheFailure：缓存命中骤降、回源暴增。
  
• floodHomepage：入口洪峰流量（压测/攻击/误配）。
  
• nodeKiller：节点被杀/NotReady，多服务同抖。
  

提交与评测

candidate_root_causes（候选根因集合）

题目允许提交的根因列表（字符串数组）。答案必须从中选择。

root_causes（最终答案集合）

选手输出的根因集合（字符串数组），须满足最小充分性：

修复列表中所有注入点即可消警；去掉任一项则无法消警。

单注入题：仅该单点即答案。多注入题：提交去冗后的最小集合（建议 ≤ 5）。

executed_queries（执行过的查询/操作）

记录你实际执行过的查询（初赛可选、决赛必填）。元素格式：

{"dsl":"promql|spl|page","query":"查询串或页面路径"}

• dsl=page 可写：dashboard: AIOps/Service Map > Drilldown(frontend)
  
• 不得包含账号密钥等敏感信息
  

JSONL（答案文件格式）

UTF-8；一题一行；无注释/末尾逗号/空行。示例结构：

{"problem_id": "string","root_causes": ["<component>.<faultType>", "..."],"executed_queries": [ { "dsl": "promql|spl|page", "query": "string" } ]}

诊断方法论术语

独占耗时（Exclusive Time）

某 span 自身花费的时间（不含其子 span 的时间）。找“独占耗时长”的 span，可定位服务内部瓶颈（如 cpu/largeGc）。

最下游第一故障（First Error Downstream）

沿调用链向下游寻找首次出现 statusCode>1 且其子孙无更深层错误的 span，通常即根因点。

模式/差异分析（Patterns / Diff Patterns）

• Patterns：在错误样本中抽取共性模式（如同一服务/方法/版本）。
  
• Diff Patterns：比较“异常 vs 正常”两类数据，找显著差异特征（如异常仅出现在 serviceName=recommendation）。
  

FAQ

1. 账号、入口与区域

Q：控制台入口/工作空间是？

A：区域 cn-qingdao；工作空间一般为 tianchi-2025。进不去或搜不到，多半是权限/网络问题：清缓存、换网络、确认权限，再不行带截图到群里反馈。

Q：APM、SLS、实体查询分别在哪？

• Trace/拓扑：APM → 调用链分析（Trace Explorer）、拓扑视图。
  
• 日志（SPL）：SLS 日志查询。
  
• 实体（K8s 指标）：实体查询（Entity Explorer），可用 entity_set / entity-call 拉 Deployment/Pod 指标。
  

2. 入门与整体

Q：我该如何最快上手？

A：按“三步走”：

• 步1：告警入手定窗 + Trace/拓扑看“谁先错 / 谁拖慢”。
  
• 步2：Trace 锁根因 + 日志模式/事件做铁证。
  
• 步3：实体指标（或二次证据）交叉验证 → 输出最小充分集合并规范提交。
  

Q：A/B 榜区别？

A：A 榜题更友好，重在让你拿到分；B 榜更复杂/多注入，且数据集更换。评分以 B 榜为准。

Q：样例整体复现思路？

A：overall_error_count → Trace 错误瀑布 → 拓扑异常边落到 某个应用（如product-catalog） → SLS events/statusMessage 验证注入 → 提交 product-catalog.Failure。

A：frontend_avg_rt → Trace 看独占耗时长的 span 聚集在 某个应用（如recommendation） → 实体查询 CPU 急升且显著异常 → 提交 recommendation.cpu。

Q：服务依赖拓扑图会提供吗？

A：会在赛题说明中提供，也可参考CMS2.0的全链路拓扑。

Q：干扰项排除的思路是什么？

A：比赛环境中会有一些常态化的报错或者时延长期保持在比较高的水位，选手在页面或者通过脚本进行故障排查的时候需要识别在故障区间有【显著】变化的service/pod/node。

3. 时间与窗口

Q：题面 time_range 用什么时区？边界算不算？

A：以北京时间（UTC+8）。格式必须是

YYYY-MM-DD HH:mm:ss ~ YYYY-MM-DD HH:mm:ss（中间空格 + ~ + 空格），左右边界均包含。请把题面时间原样粘贴到控制台。

Q：粘贴时间后没数据？

A：常见原因：格式不对（少空格/少 ~）、区域或工作空间错、数据延迟、限流。先缩小时间窗、加 limit，再确认“错误/异常”筛选是否勾上。

4. 候选根因与命名

Q：答案必须跟候选集合一模一样吗？

A：必须。root_causes 必须是题目的 candidate_root_causes 子集，字符串逐字一致（包含大小写与连字符/驼峰风格）。题面若给了不同风格写法，以题面为准。

Q：根因命名的语法是什么？

A：通用规范为 .（component 小写+短横线，如 product-catalog；faultType 驼峰，如 networkLatency、cacheFailure 等）。再次强调：提交时请照抄题面候选项。

5. 页面操作要点

Q：Trace Explorer 里“错误/异常”对应什么？

A：对应 statusCode in (2,3)。列表点“详情”进入调用瀑布图，优先定位最下游第一故障（其子孙没有更深层错误的那个 span）。

Q：服务拓扑怎么看主因？

A：看异常节点/异常边（错误率升高/RT 拉长），从上游沿边下钻，找到下游首次报错的服务/方法，并回到 Trace 细看该服务的错误链路。

Q：Copilot 说的能直接信吗？

A：把 Copilot 当线索。最后结论务必用 Trace/日志/SPL 做可复现验证（如 events 或日志模式）。

6. 我需要哪些字段？

Q：Trace/日志要看哪些字段？

• Trace/Span：traceId、spanId、parentSpanId、serviceName、spanName、statusCode、statusMessage、resources(k8s.pod.ip / k8s.node.name / service.version)
  
• Log：对齐 traceId/spanId，重点看 statusMessage 与 events。
  
• Metric：arms_app_requests_error_count_raw（总错误数）、arms_app_requests_seconds_raw{service="frontend"}（RT）。
  

7. 典型故障怎么快速区分？

Q：failure / unreachable / networkLatency 怎么分？

• failure：能连上但返回错误 → 错误率升高。
  
• unreachable：连不上或超时 → 长尾时延明显、超时错误多。
  
• networkLatency：跨服务链路普遍变慢 → 多条调用边 RT 拉长。
  

Q：cpu / memory / largeGc 的直觉特征？

• cpu：服务内部段 RT 普涨，实体 CPU 使用显著升高。
  
• memory：抖动/重启（OOM），实体层能看到重启/内存接近限值。
  
• largeGc：短时尖峰暂停（JVM），错误集中于 Java 服务并快速恢复。
  

Q：cacheFailure / floodHomepage / nodeKiller 呢？

• cacheFailure：命中骤降、回源暴涨，下游承压。
  
• floodHomepage：入口流量洪峰，前端/网关先变慢/丢请求。
  
• nodeKiller：某节点 NotReady/被杀，多服务同时抖动并发生迁移。
  

8. 提交与审计

Q：答案文件的格式是什么？

A：JSONL（UTF-8），一题一行，结构如下（无注释/空行/末尾逗号）：

{"problem_id": "string","root_causes": ["<component>.<faultType>", "..."],"executed_queries": [{ "dsl": "promql|spl|page", "query": "string" }],"execution_time_range": "YYYY-MM-DD HH:mm:ss ~ YYYY-MM-DD HH:mm:ss"}

Q：executed_queries 和 execution_time_range 什么时候必填？

A：决赛必填。

• executed_queries：写你实际执行过的查询或页面路径（dsl=page 可写“Dashboard 名称 / 下钻路径 / 关键筛选”）。
  
• execution_time_range：你脚本/工具实际运行的起止时间，用于审计重放。
  

9. 常见格式错误与自检

Q：最常见扣分点？

• root_causes 不在候选集合或大小写/风格不一致；
  
• 时间窗格式不合规（缺空格或 ~）；
  
• 越窗取证（使用 time_range 外数据）；
  
• 多注入题未做去冗（非最小充分集）；
  
• JSONL 一行多对象/空行/注释。
  

Q：提交前自检清单

• JSONL 一题一行，无注释/空行/末尾逗号。
  
• 所有 root_causes 在候选集合内，字符串逐字一致。
  
• 多注入题做过“去一项测试”（最小充分）。（决赛）
  
• executed_queries 与 execution_time_range 已填写且可复现。
  

10. 限流与兜底

Q：查询超时/限流怎么办？

A：缩小 time_range、加 limit；先按服务聚合，再下钻；必要时拆分查询（分服务/分分钟段）。

Q：Copilot 不稳定时如何兜底？

A：直接使用上面的SPL 模板完成模式/差异/实体指标验证。