Edge Delta 开源 AI SRE Arena：面向 Kubernetes 上 AI SRE 智能体的开放基准

一个供应商中立的入门工具包，用于部署一次性 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 目录运行命令。集群设置、产品集成、场景执行和评分是相互独立的步骤；请按顺序遵循以下各节。

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

基准测试结果

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

检测与调查结果

Edge Delta 检测并调查了 18 个场景；Grafana 检测并调查了 12 个。Claude 在每个平台上针对全部 21 个场景从外部启动：使用 edx 时为 16 个告警和 5 个客户报告，使用 gcx 时为 12 个告警和 9 个客户报告。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 工作节点。Apple Silicon Mac 可以在原生 ARM64 kind 工作节点上运行冒烟套件，或操作 AMD64 EKS 集群。仅构建 ARM64 故障镜像并不能使整个应用兼容 ARM64。

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

AWS EKS

除 Python、kubectl 和 Docker 外，还需安装 Terraform 和 AWS CLI。配置你的 AWS 凭证，然后按照AWS 集群设置创建集群和 kubeconfig 上下文。向你的镜像仓库验证 Docker 身份，并为你的工作节点架构构建镜像：

export ARENA_CONTEXT=YOUR_CONTEXT
kubectl --context "$ARENA_CONTEXT" get nodes -L kubernetes.io/arch
# Choose the platform matching the workers shown above.
export ARENA_PLATFORM=linux/amd64  # Required by the full suite’s prebuilt application.
python3 -m bench.scenarios build-images --registry YOUR_REGISTRY/bench \
  --tag YOUR_TAG --platform "$ARENA_PLATFORM" --push

选择工作节点架构，与运行构建的计算机无关：

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

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

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

如何运行场景

配置一次运行

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
# In another terminal:
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 状态和应用行为提供故障信号；通过你选择的工具收集指标和追踪。

将 arena.json 中的 product 设置为你想在对比表中显示的名称。调查结束后，将这些文件保存到 <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  # Prepare the investigation, answer key and scoring rules
   python3 -m bench judge   # Send them to your chosen model

结果是案例目录中的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 许可证获得许可。捆绑的第三方代码保留其自己的许可证，包括Apache-2.0下的商店应用程序。