Show HN: AI SRE Arena、Kubernetes上のAI SREエージェントのためのオープンベンチマーク

Project Arenaは、ベンダーニュートラルなスターターキットで、使い捨て可能なKubernetesフィクスチャをデプロイし、障害を注入し、任意の製品からの調査記録を保存し、設定可能なジャッジで完了した調査をスコアリングします。Python 3.10+のみがPythonの依存関係です。Kubernetes操作にはkubectlも必要です。ローカルクラスターの作成にはDockerとkindが必要です。 クラスターにはローカルのkindまたはAWS EKSを選択し、次に21シナリオのフルスイートまたは6シナリオのスモークフィクスチャを選択します。クラスタータイプとシナリオスイートは別々の選択です。 仕組み フローチャート LR A[クラスターとアプリケーションのデプロイ] --> B[製品の接続] B --> C[障害の注入と検証] C --> D[製品に調査させる] D --> E[調査記録の保存] E --> F[選択したジャッジでスコアリング] F --> G[結果の比較] 実行 Project Arenaディレクトリからコマンドを実行します。 クラスターセットアップ、製品統合、シナリオ実行、スコアリングは別々のステップです。以下のセクションを順番に実行してください。 ベンチマーク結果 デプロイ方法 シナリオの実行方法 製品の接続方法 調査のスコアリング方法 結果の比較方法 クリーンアップ方法 高度な設定 ベンチマーク結果 21のKubernetesインシデントシナリオすべてで、Edge DeltaのネイティブAI調査、GrafanaのネイティブAI調査、およびClaudeを各プラットフォームのオブザーバビリティCLIを使用して比較しました。edxはEdge Deltaへのアクセスを提供し、gcxはGrafanaへのアクセスを提供します。すべての最終調査は、GPT-6-Astraを使用して同じインシデント事実とスコアリングルーブリックに対して評価されました。 検出と調査の結果 Edge Deltaは18シナリオを検出し調査しました。Grafanaは12シナリオを検出・調査しました。Claudeは各プラットフォームで全21シナリオに対して外部から起動されました。edxでは16アラートと5件の顧客レポート、gcxでは12アラートと9件の顧客レポートでした。検出はClaudeについては独立して測定されていないため、そのセルは「—」と表示されています。調査スコアは、その列の完了したすべての調査を使用します。実装準備性は、緩和策の提案がないケースを除外します。 メトリック Edge Deltaネイティブ Grafanaネイティブ Claude + edx Claude + gcx 検出 18/21 (85.7%) 12/21 (57.1%) — — 根本原因分析 15/18 (83.3%) 9/12 (75.0%) 18/21 (85.7%) 19/21 (90.5%) 影響範囲 12/18 (66.7%) 8/12 (66.7%) 18/21 (85.7%) 18/21 (85.7%) サポートされている最終緩和策 8/18 (44.4%) 5/12 (41.7%) 16/21 (76.2%) 15/21 (71.4%) 実装準備性 9/16 (56.2%) 5/12 (41.7%) 16/21 (76.2%) 15/21 (71.4%) 同じ12件のインシデントでの比較 この表は、両方のネイティブ製品が調査した12件のインシデントタイプと、それに対応するClaudeの調査結果を使用しています。これは、起動プロンプト、タイミング、または利用可能な証拠の違いではなく、含めるシナリオを制御します。 メトリック Edge Deltaネイティブ Grafanaネイティブ Claude + edx Claude + gcx 根本原因分析 11/12 (91.7%) 9/12 (75.0%) 10/12 (83.3%) 10/12 (83.3%) 影響範囲 9/12 (75.0%) 8/12 (66.7%) 10/12 (83.3%) 10/12 (83.3%) サポートされている最終緩和策 7/12 (58.3%) 5/12 (41.7%) 8/12 (66.7%) 8/12 (66.7%) 実装準備性 8/12 (66.7%) 5/12 (41.7%) 8/12 (66.7%) 8/12 (66.7%) すべてのシナリオの結果を表示 · CSVをダウンロード メトリックの意味 メトリック クレジットを獲得する条件 検出 製品がインシデントを検出し、観測ウィンドウ内に調査を開始したこと。 根本原因分析 最終レポートがインシデントの原因を正しく説明していること。 影響範囲 最終レポートが、サポートされていない障害を主張することなく、影響を受けたワークロードと下流への影響を正しく特定していること。 サポートされている最終緩和策 最終的な提案が、誤ったまたは安全でないアドバイスを残さずに、具体的でサポートされた修正または安全な封じ込めを提供していること。 実装準備性 提案が修正と必要な詳細を指定していること。通常のレビュー、実装、ロールアウトチェックは残る場合があります。 緩和策と準備性は、実行された修復や検証された回復ではなく、提案を測定します。グレーディングルールについてはスコアリングルーブリックを、判定の内訳と評価の詳細については結果と方法論全体を参照してください。 デプロイ方法 すべてのコマンドをProject Arenaディレクトリから実行します。 両方の環境は、クラスターとイメージのセットアップ後に同じベンチマークコマンドを使用します。 ランナーは提供されたコンテキストを使用します。ネットワークのインストールやレジストリへのアクセス設定を自動的に行いません。 ローカル kind AWS EKS クラスター作成 Dockerとkind Terraform (infra/cluster) 依存関係 kubectl AWS認証情報なし AWS認証情報あり フルスイートイメージ kindにビルドしてロード レジストリにビルドしてプッシュ ネットワーク NetworkPolicyは強制的なCNIを必要とします TerraformはVPC CNIポリシー強制を有効にします クリーンアップ kindクラスターを削除 ワークロードを削除してからTerraformリソースを破棄 デプロイパスの選択 クラスターセットアップとデプロイメント方法は別々の選択です。 パス 変更がKubernetesに到達する方法 セットアップ 直接ベンチ kubectlを使用してアプリケーションと障害のマニフェストを適用します GitOps (フルスイート) リポジトリに変更をコミットしてプッシュします。Argo CDが同期します。 Argo CDのセットアップと実行ガイドに従ってください。 GitOpsパスは、コンポーネントアプリケーション、flagd-values、およびbatch-activeを使用します。 アプリケーションと障害の設定は、別々のリポジトリまたは1つのリポジトリ内の別々のパスに配置できます。 独自のリポジトリを使用し、それらのURLを設定してください。 調査製品がアクセスできるリポジトリを記録してください。 デプロイ、障害、リセットコマンドは以下では直接パスを使用します。Argo管理アプリケーションの場合、Argoの自己修復との競合を避けるために、GitOpsガイドのコマンドを使用してください。直接の変更はブロックされます。 調査のインポート、スコアリング、レポート作成は、両方のパスで同じように機能します。 ローカル 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互換になるわけではありません。 フルスイートの場合、arena.jsonでレジストリを「fixture.local」とし、タグを「v1」のままにします。 リンクされたセットアップは、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 # 上記で表示されたワーカーに一致するプラットフォームを選択します。 export ARENA_PLATFORM=linux/amd64 # フルスイートの事前ビルド済みアプリケーションに必要です。 python3 -m bench.scenarios build-images --registry YOUR_REGISTRY/bench \ --tag YOUR_TAG --platform "$ARENA_PLATFORM" --push ビルドを実行するコンピューターに関係なく、ワーカーアーキテクチャを選択します。 Kubernetesワーカー ビルドプラットフォーム ARM64ワーカー スモークスイートはサポートされています。フルスイートはアプリケーションの再ビルドと検証が必要です。 Intel Macローカル kind または Intel/AMDワーカー（デフォルトのEKS m6i.xlargeを含む） linux/amd64 Apple Silicon Macは、linux/amd64を使用してIntel/AMD EKSワーカー用にビルドできます。Docker Desktopはエミュレーションを通じてクロスプラットフォームビルドをサポートします。 このコマンドは一度に1つのターゲットアーキテクチャをビルドします。 混合アーキテクチャクラスターでは、アプリケーションはAMD64ワーカーにスケジュールされます。 arena.jsonでレジストリとタグを同じ値に設定します。 ノードはレジストリへのプルアクセスが必要です。レジストリの権限またはKubernetesのプル認証情報を自分で設定してください。 AWSリソースは課金されます。Terraformは現在、1つのリージョン内の3つのアベイラビリティゾーンにサブネットを作成します。ゾーン数とワーカー数は別々の設定です。 どちらのセットアップの後でも、あなたのPRをインストールしてください