Edge Delta 开源 AI SRE 基准测试 Arena

一个供应商中立的启动工具包，用于部署一次性 Kubernetes 测试环境、注入故障、从任意产品保存调查记录，并用可配置的评判器对已完成的调查打分。Python 3.10+ 是唯一的 Python 依赖。Kubernetes 操作还需要kubectl；本地集群创建需要 Docker 和kind。

为你的集群选择本地 kind 或 AWS EKS，然后选择 21 场景完整套件或六场景冒烟测试环境。集群类型和场景套件是相互独立的选择。

工作原理

flowchart LR
    A[Deploy cluster and application] --> B[Connect your product]
    B --> C[Inject and verify a fault]
    C --> D[Let your product investigate]
    D --> E[Save investigation records]
    E --> F[Score with your chosen judge]
    F --> G[Compare results]

从 Project Arena 目录运行命令。集群搭建、产品集成、场景执行和评分是相互独立的步骤；请按顺序遵循以下各节。

• 基准测试结果
• 如何部署
• 如何运行场景
• 如何接入你的产品
• 如何对调查评分
• 如何比较结果
• 如何清理
• 高级配置

基准测试结果

我们比较了Edge Delta 的原生 AI 调查、Grafana 的原生 AI 调查，以及使用各平台可观测性 CLI 的 Claude，覆盖 21 个 Kubernetes 事故场景。edx提供对 Edge Delta 的访问；gcx提供对 Grafana 的访问。所有最终调查均使用 GPT-6-Astra 针对相同的事故事实和评分标准进行评估。

检测与调查结果

Edge Delta 检测并调查了 18 个场景；Grafana 检测并调查了 12 个。Claude 在每个平台上针对全部 21 个场景均从外部启动：16 个告警和 5 个客户报告使用 edx，以及12 个告警和 9 个客户报告使用 gcx。Claude 的检测未被独立测量，因此这些单元格显示为—。

调查评分使用该列中所有已完成的调查。实施就绪度排除没有缓解提案的案例。

在相同的 12 个事故上的比较

本表使用两个原生产品都调查过的 12 种事件类型，并对应 Claude 的调查结果。它控制的是纳入哪些场景，而不是启动提示词、时机或可用证据的差异。

查看每个场景的结果·下载 CSV

指标含义

缓解措施和就绪度衡量的是方案，而非已执行的修复或已验证的恢复。

参见评分标准了解评分规则，参见完整结果与方法论了解判定明细和评估细节。

如何部署

在 Project Arena 目录下运行所有命令。两个环境在完成集群和镜像设置后使用相同的基准测试命令。运行器使用你提供的上下文；它不会自动安装网络组件或配置镜像仓库访问权限。

选择部署路径

集群设置和部署方式是彼此独立的选择：

GitOps 路径使用组件 Application，flagd-values、以及batch-active。应用和故障配置可以放在单独的仓库中，也可以放在同一个仓库的不同路径中。使用你自己的仓库并配置它们的 URL。记录调查产品可以访问哪些仓库。

下面的部署、故障和重置命令使用直接方式。对于由 Argo 管理的应用，请使用 GitOps 指南中的命令；直接变更会被阻止，以避免与 Argo 的自愈机制冲突。调查导入、评分和报告在两种方式下工作方式相同。

本地 kind

安装 Python 3.10+、kubectl、Docker、kind 和 Helm。按照kind 设置创建带有 Cilium 的集群并加载完整套件镜像。然后选择其上下文：

export ARENA_CONTEXT=kind-incident-bench

完整套件使用预构建的应用镜像，适用于Linux AMD64并且需要 AMD64 worker。Apple Silicon Mac 可以在原生 ARM64 kind worker 上运行冒烟套件，或者操作 AMD64 EKS 集群。仅构建 ARM64 故障镜像并不能让完整应用兼容 ARM64。

对于完整套件，保持registry: "fixture.local"和tag: "v1"在arena.json。链接的设置会为以下项启用 NetworkPolicy 强制执行netpol-isolation。仅对于冒烟套件，python3 -m bench cluster create就足够了；冒烟套件使用固定的公共镜像，不需要完整套件镜像构建。

AWS EKS

除了 Python、kubectl 和 Docker 之外，还要安装 Terraform 和 AWS CLI。配置你的 AWS 凭证，然后按照AWS 集群设置创建集群和 kubeconfig 上下文。让 Docker 向你的镜像仓库进行身份验证，并为你的 worker 架构构建镜像：

export ARENA_CONTEXT=YOUR_CONTEXT
kubectl --context "$ARENA_CONTEXT" get nodes -L kubernetes.io/arch
#选择与上面显示的 worker 匹配的平台。
export ARENA_PLATFORM=linux/amd64  #完整套件的预构建应用所需。
python3 -m bench.scenarios build-images --registry YOUR_REGISTRY/bench \
  --tag YOUR_TAG --platform "$ARENA_PLATFORM" --push

选择worker 架构，无论由哪台计算机运行构建：

Apple Silicon Mac 可以使用以下方式为 Intel/AMD EKS 工作节点构建linux/amd64；Docker Desktop 通过模拟支持跨平台构建。此命令一次构建一个目标架构。在混合架构集群上，应用会被调度到 AMD64 工作节点上。

设置registry和tag在arena.json为相同的值。节点必须对镜像仓库有拉取权限；请自行配置仓库权限或 Kubernetes 拉取凭据。AWS 资源会产生费用。Terraform 目前会在一个区域内的三个可用区中创建子网；可用区数量和工作节点数量是独立的设置。

完成任一设置后，按照你产品的说明安装其采集器和告警配置。然后继续下面的运行配置。

如何运行场景

配置一次运行

python3 -m bench init

编辑生成的arena.json：

默认的full套件目前包含 21 个场景。较小的smoke套件包含六个场景，并使用公共 Python 镜像，因此不需要构建故障镜像。它们使用不同的应用；部署前请先选择一个套件。参见场景表了解要求和差异。

python3 -m bench catalog
python3 -m bench deploy

注入故障之前，请完成产品设置并确认产品能接收到健康应用的遥测数据。

注入并观察

对于全套件：

python3 -m bench fault
python3 -m bench verify
python3 -m bench evidence

fault应用清单；verify检查是否观察到预期的故障。仅成功应用并不能构成有效的测试。在重置故障之前，让产品完成调查。

对于smoke，使用fault和evidence，然后自行检查 Pod 状态、事件和服务可用性；自动化verify目前仅支持full。健康的冒烟应用在端口 8080 上提供 HTTP 服务：

kubectl --context "$ARENA_CONTEXT" -n incident-bench port-forward service/api 8080:8080
#在另一个终端中：
curl http://localhost:8080/health

若要再次尝试，请先重置，并用以下命令选择一个全新的用例目录--case，放在命令之前：

python3 -m bench --case oom-attempt2 fault
python3 -m bench --case oom-attempt2 verify
python3 -m bench --case oom-attempt2 evidence

使用同一个--case用于后续的导入和评分命令。它选择的是产物目录，而不是不同的场景。更改scenario在运行文件中，当测试另一个故障时。

如何连接你的产品

安装你的产品的采集器，并按照其自身的说明配置告警。Project Arena 不会安装供应商的智能体、登录产品，也不会自动配置告警。Kubernetes 日志、事件、Pod 状态和应用行为提供故障信号；通过你选择的工具收集指标和追踪。

设置product在arena.json为你希望在对比表中显示的名称。调查结束后，将这些文件保存到<output_dir>/<scenario>/（或你选择的案例目录）下：

使用以下命令导入它们：

python3 -m bench archive

该命令会自动使用这些文件名。缺少最终输入是错误；缺少中间/操作证据则保持缺失。明确记录检测结果，使用--detection detected或--detection not_detected在有观察窗口和证据支持时；默认是not_measured。

支持手动导出。对于基于 API 的集成，提供一个使用调查记录格式的导出器。托管产品连接器不随附。未检测到的案例仍然可以有一条记录，其最终答案为空；它不能被表示为已完成的调查。

如何对调查进行评分

评判者是一个 AI 模型，它将已完成的调查与场景的答案键以及评分标准进行比较。答案键已包含在内。

1. 在arena.json中，选择评判者提供商和模型。例如，编辑现有的judge部分：

   "judge": {
     "provider": "openai",
     "model": "YOUR_MODEL"
   }

2. 在你的 shell 中提供该提供商的 API 密钥（OPENAI_API_KEY用于此示例）。将密钥远离arena.json。其他提供商和本地模型也受支持。

3. 导入调查后，运行：

   python3 -m bench packet  #准备调查、答案键和评分规则
   python3 -m bench judge   #将它们发送给你选择的模型

结果是judgment.json在案例目录中：分数、解释和支持性引文。对你比较的每个产品使用相同的评判者模型和设置。API 调用可能会产生费用。

你可以对同一份已保存的调查再次评分，而无需重新运行事件。参见重新评分和已保存结果了解详情。

如何比较结果

python3 -m bench report --summary > summary.csv
python3 -m bench report --details > details.csv

摘要将指标放在行中，产品放在列中。每个单元格显示成功/适用（百分比）。仅为示例值，并非基准测试结果：

实际报告包含每个评分维度。明细表列出每个场景的判定结果以及是否计入分母。未检测到的案例计入检测率；不适用的案例从相关评分分母中排除。证据不足的案例在适用的已评分案例中仍保留在分母内。缺失的测量和未评分的调查在明细中仍然可见。短横线表示没有适用的已评分案例。

产品名称来自调查记录，通过内容哈希与判定结果匹配。记录和判定结果在配置的运行目录中发现。也包括未检测到案例的记录。比较产品时使用匹配的场景队列、评分标准和评判设置；参见报告选项和计数规则以合并运行并解读每个指标。

如何清理

场景之间重置

对于 GitOps，请遵循Git 重置和同步工作流以便仓库和集群返回到相同的基线。

对于使用直接部署的完整套件：

python3 -m bench reset --confirm-disposable

这会清除注入的资源，恢复三个场景标志，并且仅清除该故障的持久影响。健康的服务、应用数据、凭证和集群保持原样；重置会在下一次故障前验证基线。对于smoke，使用python3 -m bench reset；它会恢复应用但保留存储故障的 PVC。

移除本地 kind 集群

python3 -m bench cluster delete --confirm-delete

移除 AWS 资源

移除应用资源以及任何已配置的卷或负载均衡器，然后遵循AWS 拆除说明。重置故障不会停止 AWS 计费。可选的 Terraform 状态存储会单独持久保留。

高级配置

• 在命令前使用--run path/to/run.json以选择另一个配置。显式标志会覆盖已保存的设置。
• 配置的文件路径相对于运行文件。显式 CLI 路径和评判可执行文件参数相对于当前工作目录。
• 使用packet --rubric path/to/rubric.md用于自定义评分标准。在对比的产品之间保持相同的评分标准和评判设置。
• 产品导出器与评判格式描述自定义集成和证据要求。
• 场景实现指南涵盖清单、镜像构建、验证和重置行为。

运行离线测试：

python3 -m unittest discover -s tests -v

许可证

Project Arena 依据MIT 许可证授权。捆绑的第三方代码保留其自身许可证，包括位于以下许可下的 shop 应用Apache-2.0。