完整內容，請至幹話王 Grafana o11y-bench 深入剖析：讓 AI 真正面對 on-call 現場

LLM 到底能不能當 SRE？
不是問它「知不知道 PromQL 語法」，而是丟它進一個真實跑著的
Grafana + Prometheus + Loki + Tempo 環境，看它能不能找出根因。
這就是 Grafana Labs 開源的 o11y-bench 在做的事。
https://grafana.com/blog/o11y-bench-open-benchmark-for-observability-agents/

官方 leaderboard： https://o11ybench.ai/

我把它的任務設計、合成故障、雙層評分機制全部拆開來看了一遍，順便用 Gemini 3 Flash Preview 跑了一輪實測玩玩。

三個我覺得很值得學的設計：

1. 答案裡的 trace ID 必須真的出現在 Tempo 工具回傳裡（防幻覺）
2. Dashboard 題不靠 LLM 評分，直接打 Grafana API 驗 panel 狀態
3. Leaderboard 用 pass^k（每次都對）排序，不是 pass@k（最好情況）

o11y-bench 深入剖析：讓 AI 真正面對 on-call 現場

從任務設計、合成環境、Agent 架構、評分機制到報告輸出，逐一解析這個開放 benchmark 的每個組件——以及 Gemini 3 Flash Preview 的完整實測結果

先說清楚這在解決什麼問題

目前多數 LLM benchmark 測的是「知識」：模型知不知道 PromQL 的語法，知不知道什麼是 p99 latency。但 SRE 的工作從來不只是知識問題——真正的挑戰是：能不能在一個陌生的監控環境裡，自主操作工具，把分散在 metrics、logs、traces 三個訊號裡的線索拼起來，找到根因？

metrics 像體溫計（數字趨勢）、logs 像病歷（事件記錄）、traces 像 X ▎ 光（請求在系統內怎麼流動）。on-call 的難處是這三種資料分別存在三個系統裡，要自己拼起來。

Grafana Labs 的工程師 Yasir Ekinci 和 Jack Gordley 在 GrafanaCON 2026 發表 o11y-bench 時，特別強調了 observability 任務的本質差異：

"In observability, the dangerous mistakes are often the subtle ones."

一個查詢語法正確，但選了錯誤的 metric series；一個 dashboard 在 UI 上看起來正常，但 variable binding 沒有真正連上 panels——這類錯誤在一般的 benchmark 裡不會被抓到，但在真實 on-call 場景裡會導致錯誤判斷。這就是為什麼需要一個讓 agent 面對真實 stack、結果由程式直接驗證的 benchmark。

o11y-bench 嘗試回答這個問題。它是由 Grafana Labs 開發的開放 benchmark，基於 Harbor 框架運作，讓 LLM agent 在一個真實跑起來的 Grafana + Prometheus + Loki + Tempo stack 上解題，評分後對外公開 leaderboard。

• Harbor → benchmark 執行框架（負責起容器、跑 agent、收結果）

• Prometheus → 存 metrics、Loki → 存 logs、Tempo → 存 traces

整體架構鳥瞰

![](https://cdn.hashnode.com/uploads/covers/6420f5cbbdbe7d697133d12a/6c3b5c46-49a3-49c5-a14f-65445b52ddea.png align="center")

跑一次 benchmark 的流程大致如下：

tasks-spec/  →  (sync)  →  tasks/
                                ↓
                    Harbor 起一個 trial
                                ↓
              ┌─────────────────────────────┐
              │   docker/ sidecar 容器          │
              │   Prometheus + Loki + Tempo    │
              │   + Grafana + mcp-grafana      │
              └─────────────────────────────┘
                                ↓
              ┌─────────────────────────────┐
              │   agents/ agent 容器            │
              │   讀題目 → 呼叫 MCP 工具          │
              │   → 寫出 trajectory.json       │
              └─────────────────────────────┘
                                ↓
              ┌─────────────────────────────┐
              │   grading/ verifier            │
              │   deterministic checks         │
              │   + LLM rubric (Claude)        │
              └─────────────────────────────┘
                                ↓
              jobs/<job-name>/result.json
              jobs/<job-name>/run_report.html

以下逐一拆解每個組件。

組件一：tasks-spec/ — 題目的源頭

tasks-spec/
  prometheus_query/   (16 題)
  loki_query/         (10 題)
  tempo_query/        (13 題)
  grafana_api/        (6 題)
  dashboarding/       (7 題)
  investigation/      (11 題)

tasks-spec/ 是整個專案唯一需要手動維護的 task 資料，tasks/ 是從它生成的 output（不要直接編輯）。執行 mise run setup:sync 會把所有 YAML 轉換成 Harbor 能讀的任務格式。

YAML 格式設計

每個 task 的核心欄位：

id: promql-subquery-peak-error-rate
category: prometheus_query
statement: |
  六小時內，payment-service 的 error rate 峰值是多少？

checks:
  - name: Response cites a trace ID that appears in Tempo tool results
    weight: 70
    type: grounding
    params:
      mode: tool_trace_id

rubric:
  - criterion: The final response states the peak error rate accurately.
    weight: 65
    fact:
      kind: query
      backend: prometheus
      query: max_over_time(rate(http_requests_total{job="payment-service",status=~"5.."}[5m])[6h:1m])

有幾個刻意的設計決策值得注意：

• statement 用自然語言，不給語法提示：不寫「用 PromQL subquery」，只說「六小時內的峰值是多少」。這樣才是真正測 agent 能不能選對工具。

• 數字精確性用 fact：benchmark 自己跑那個 PromQL 拿到 ground truth，讓 judge 比對，而不是把答案寫死在 criterion 文字裡（否則改了資料就要改題目）。

• 具體實體用 grounding check：trace ID 不靠 LLM 判斷，程式直接比對。

grounding check：強制答案裡的具體值（trace ID、service 名）必須真的在工具回傳結果裡出現，防 LLM 編造

一道題包含三個東西：題目（statement）、程式驗的部分（checks）、LLM 評分的部分（rubric）。「rubric」是 LLM 評估常用語：一份評分準則清單。「LLM rubric」就是讓另一個 LLM（這裡是 Claude）當 judge，照清單逐條打勾 YES/NO。後面組件四會展開細節。

六個類別的能力層次

完整內容，請至幹話王 Grafana o11y-bench 深入剖析：讓 AI 真正面對 on-call 現場