加载中 sample/README.md +66 −35 原始行号 差异行号 差异行 加载中 @@ -2,7 +2,29 @@ 以下文档介绍本次比赛所使用的样例数据结构与内容，其中包含正常数据与故障数据的示例及其对应的故障分析结果格式。 --- ## 目录结构 ```text ├── abnormal │ ├── case1 │ │ ├── log-parquet.tar.gz │ │ ├── metric-parquet.tar.gz │ │ └── trace-parquet.tar.gz │ ├── case2 │ │ ├── log-parquet.tar.gz │ │ ├── metric-parquet.tar.gz │ │ └── trace-parquet.tar.gz │ └── input.json └── normal ├── log-parquet.tar.gz ├── metric-parquet.tar.gz └── trace-parquet.tar.gz ``` - `abnormal/`：存放所有故障案例原始数据的文件夹。 - `abnormal/input.json`：算法的输入，包含每个故障案例的唯一标识（id）与文字描述（description）。 - `normal/`：存放系统正常运行产生的原始数据的文件夹。 ## 一、正常数据 加载中 @@ -12,20 +34,18 @@ ## 二、异常数据 - **目录路径**：`abnormal/` - **描述**：该文件夹下存放了两个故障案例（`case1/`、`case2/`），其中每个子目录包含该故障期间的原始日志/指标文件，以及预先生成的故障分析结果 JSON，示例格式如下。 - **描述**：该文件夹下存放了两个故障案例（`case1/`、`case2/`），其中每个子目录包含该故障期间的原始日志，指标和调用链文件，以及提供给算法的输入样例。 ### Case1：Memory Stress 故障 ### 1. Case1：Memory Stress 故障 Case1 展示的是 `adservice` 服务出现内存压力故障时，故障前后总共一个小时间的日志和调用链数据，以及当天的指标数据。下面是故障的详细描述： - **故障节点**：`case1/` - **故障类型**：`memory stress` - **故障描述**： - **故障分类**（`fault_category`）：`stress test` - **故障类型**（`fault_type`）：`memory stress` - **实例类型**（`instance_type`）：`service` - **实例名称**（`instance`）：`adservice` - **故障开始时间**（`start_time`）：`2025-04-27T19:10:15Z` - **故障结束时间**（`end_time`）：`2025-04-27T19:40:15Z` - **关键证据点**（`key_observations`） ```json { 加载中 @@ -37,33 +57,31 @@ "end_time": "2025-04-27T19:40:15Z", "key_observations": [ { "type": "log", "type": "metric", "keyword": [ "exception", "error" "error_ratio", "client_error_ratio" ] } ] } ``` - 说明 - 该故障为内存压力测试。 - `key_observations` 为故障的关键证据点，type有metric，log，trace三种，指示故障在三类模态数据上的具体表征。 - 在 key_observations 中，type="metric"，category="service_errors"，若推理过程中 observation 文本（前 100 字符）提到 “error_ratio” 或 “client_error_ratio” KPI关键字，即视为已命中。 - Case1 的关键证据点类型为metric，涉及的KPI为 `error_ratio` 和 `client_error_ratio`，说明故障发生时 `adservice` 的 `error_ratio` 和`client_error_ratio` 两类APM指标会出现明显异常。若推理过程中 observation 文本（前 100 字符）提到 “error_ratio” 或 “client_error_ratio” KPI关键字，即视为已命中。 ### 2. Case2：Pod Failure 故障 - **故障节点**：`case2/` - **故障类型**：`pod failure` - **故障描述**： ### Case2：Pod Failure 故障 Case2 展示的是 `recommendationservice` 服务下所有实例无法正常运行，故障前后总共一个小时间的日志和调用链数据，以及当天的指标数据。下面是故障的详细描述： - **故障分类**（`fault_category`）：`pod fault` - **故障类型**（`fault_type`）：`pod failure` - **实例类型**（`instance_type`）：`service` - **实例名称**（`instance`）：`recommendationservice` - **故障开始时间**（`start_time`）：`2025-04-29T06:10:42Z` - **故障结束时间**（`end_time`）：`2025-04-29T06:38:42Z` - **关键证据点**（`key_observations`） ```json { 加载中 @@ -89,8 +107,21 @@ } ``` - 说明 - Case2 的关键证据点类型为 trace，涉及的实例有 `checkoutservice-0`，`checkoutservice-2`，`frontend-1`，`frontend-2`，`productcatalogservice-2`，说明故障发生时，`checkoutservice` 服务，`frontend` 服务和 `productcatalogservice` 服务与 `recommendationservice` 服务之间的调用路径出现了异常。若推理链（reasoning_trace）的 observation 文本前 100 字符内多次提及这些实例名，且结合调用链图能看出它们之间存在请求异常，则视为命中。 ### 算法输入 - 该故障为 Pod 级别故障，通过调用链分析发现推荐服务（recommendationservice）在与其他组件交互过程中，多个依赖出现 “请求异常” 情况。 `abnormal` 文件夹下存放了 `input.json`。该文件包含每个故障案例的 `id` 和 `description`。参赛选手需要将其作为算法的输入，并且提交的答案中也需要附带上故障案例的 `id`。 - type="调用链"，指定 subtype="request_proportion_anomalies"，并列举了与该 pod 调用链相关的几个组件实例节点。若推理链（reasoning_trace）的 observation 文本前 100 字符内多次提及这些组件名，且结合调用链图能看出它们之间存在请求异常，则视为命中。 No newline at end of file ```json [ { "uuid": "33c11d00-2", "Anomaly Description": "The system experienced an anomaly from 2025-04-30T19:10:15Z to 2025-04-30T19:40:15Z. Please infer the possible cause." }, { "uuid": "2f9d1c3d-28", "Anomaly Description": "The system experienced an anomaly from 2025-05-02T06:10:42Z to 2025-05-02T06:38:42Z. Please infer the possible cause." } ] ``` No newline at end of file sample/abnormal/input.json 0 → 100644 +10 −0 原始行号 差异行号 差异行 [ { "uuid": "33c11d00-2", "Anomaly Description": "The system experienced an anomaly from 2025-04-30T19:10:15Z to 2025-04-30T19:40:15Z. Please infer the possible cause." }, { "uuid": "2f9d1c3d-28", "Anomaly Description": "The system experienced an anomaly from 2025-05-02T06:10:42Z to 2025-05-02T06:38:42Z. Please infer the possible cause." } ] No newline at end of file 加载中
sample/README.md +66 −35 原始行号 差异行号 差异行 加载中 @@ -2,7 +2,29 @@ 以下文档介绍本次比赛所使用的样例数据结构与内容，其中包含正常数据与故障数据的示例及其对应的故障分析结果格式。 --- ## 目录结构 ```text ├── abnormal │ ├── case1 │ │ ├── log-parquet.tar.gz │ │ ├── metric-parquet.tar.gz │ │ └── trace-parquet.tar.gz │ ├── case2 │ │ ├── log-parquet.tar.gz │ │ ├── metric-parquet.tar.gz │ │ └── trace-parquet.tar.gz │ └── input.json └── normal ├── log-parquet.tar.gz ├── metric-parquet.tar.gz └── trace-parquet.tar.gz ``` - `abnormal/`：存放所有故障案例原始数据的文件夹。 - `abnormal/input.json`：算法的输入，包含每个故障案例的唯一标识（id）与文字描述（description）。 - `normal/`：存放系统正常运行产生的原始数据的文件夹。 ## 一、正常数据 加载中 @@ -12,20 +34,18 @@ ## 二、异常数据 - **目录路径**：`abnormal/` - **描述**：该文件夹下存放了两个故障案例（`case1/`、`case2/`），其中每个子目录包含该故障期间的原始日志/指标文件，以及预先生成的故障分析结果 JSON，示例格式如下。 - **描述**：该文件夹下存放了两个故障案例（`case1/`、`case2/`），其中每个子目录包含该故障期间的原始日志，指标和调用链文件，以及提供给算法的输入样例。 ### Case1：Memory Stress 故障 ### 1. Case1：Memory Stress 故障 Case1 展示的是 `adservice` 服务出现内存压力故障时，故障前后总共一个小时间的日志和调用链数据，以及当天的指标数据。下面是故障的详细描述： - **故障节点**：`case1/` - **故障类型**：`memory stress` - **故障描述**： - **故障分类**（`fault_category`）：`stress test` - **故障类型**（`fault_type`）：`memory stress` - **实例类型**（`instance_type`）：`service` - **实例名称**（`instance`）：`adservice` - **故障开始时间**（`start_time`）：`2025-04-27T19:10:15Z` - **故障结束时间**（`end_time`）：`2025-04-27T19:40:15Z` - **关键证据点**（`key_observations`） ```json { 加载中 @@ -37,33 +57,31 @@ "end_time": "2025-04-27T19:40:15Z", "key_observations": [ { "type": "log", "type": "metric", "keyword": [ "exception", "error" "error_ratio", "client_error_ratio" ] } ] } ``` - 说明 - 该故障为内存压力测试。 - `key_observations` 为故障的关键证据点，type有metric，log，trace三种，指示故障在三类模态数据上的具体表征。 - 在 key_observations 中，type="metric"，category="service_errors"，若推理过程中 observation 文本（前 100 字符）提到 “error_ratio” 或 “client_error_ratio” KPI关键字，即视为已命中。 - Case1 的关键证据点类型为metric，涉及的KPI为 `error_ratio` 和 `client_error_ratio`，说明故障发生时 `adservice` 的 `error_ratio` 和`client_error_ratio` 两类APM指标会出现明显异常。若推理过程中 observation 文本（前 100 字符）提到 “error_ratio” 或 “client_error_ratio” KPI关键字，即视为已命中。 ### 2. Case2：Pod Failure 故障 - **故障节点**：`case2/` - **故障类型**：`pod failure` - **故障描述**： ### Case2：Pod Failure 故障 Case2 展示的是 `recommendationservice` 服务下所有实例无法正常运行，故障前后总共一个小时间的日志和调用链数据，以及当天的指标数据。下面是故障的详细描述： - **故障分类**（`fault_category`）：`pod fault` - **故障类型**（`fault_type`）：`pod failure` - **实例类型**（`instance_type`）：`service` - **实例名称**（`instance`）：`recommendationservice` - **故障开始时间**（`start_time`）：`2025-04-29T06:10:42Z` - **故障结束时间**（`end_time`）：`2025-04-29T06:38:42Z` - **关键证据点**（`key_observations`） ```json { 加载中 @@ -89,8 +107,21 @@ } ``` - 说明 - Case2 的关键证据点类型为 trace，涉及的实例有 `checkoutservice-0`，`checkoutservice-2`，`frontend-1`，`frontend-2`，`productcatalogservice-2`，说明故障发生时，`checkoutservice` 服务，`frontend` 服务和 `productcatalogservice` 服务与 `recommendationservice` 服务之间的调用路径出现了异常。若推理链（reasoning_trace）的 observation 文本前 100 字符内多次提及这些实例名，且结合调用链图能看出它们之间存在请求异常，则视为命中。 ### 算法输入 - 该故障为 Pod 级别故障，通过调用链分析发现推荐服务（recommendationservice）在与其他组件交互过程中，多个依赖出现 “请求异常” 情况。 `abnormal` 文件夹下存放了 `input.json`。该文件包含每个故障案例的 `id` 和 `description`。参赛选手需要将其作为算法的输入，并且提交的答案中也需要附带上故障案例的 `id`。 - type="调用链"，指定 subtype="request_proportion_anomalies"，并列举了与该 pod 调用链相关的几个组件实例节点。若推理链（reasoning_trace）的 observation 文本前 100 字符内多次提及这些组件名，且结合调用链图能看出它们之间存在请求异常，则视为命中。 No newline at end of file ```json [ { "uuid": "33c11d00-2", "Anomaly Description": "The system experienced an anomaly from 2025-04-30T19:10:15Z to 2025-04-30T19:40:15Z. Please infer the possible cause." }, { "uuid": "2f9d1c3d-28", "Anomaly Description": "The system experienced an anomaly from 2025-05-02T06:10:42Z to 2025-05-02T06:38:42Z. Please infer the possible cause." } ] ``` No newline at end of file
sample/abnormal/input.json 0 → 100644 +10 −0 原始行号 差异行号 差异行 [ { "uuid": "33c11d00-2", "Anomaly Description": "The system experienced an anomaly from 2025-04-30T19:10:15Z to 2025-04-30T19:40:15Z. Please infer the possible cause." }, { "uuid": "2f9d1c3d-28", "Anomaly Description": "The system experienced an anomaly from 2025-05-02T06:10:42Z to 2025-05-02T06:38:42Z. Please infer the possible cause." } ] No newline at end of file
