Observability

こんにちは。ジェダイパンくず🍞 です。 以前の記事 自前開発した Prometheus Exporter で自宅ルータのメトリクス監視運用している話 や Prometheus Exporter 開発で Discord サーバ運営の健全化を図る では、Go で Prometheus Exporter を書いて Prometheus Server に scrape させていました。 最近は Grafana のエージェントとして Grafana Alloy を使う構成が増えています。Alloy は Prometheus の scrape や remote_write、OpenTelemetry、ログ収集などを 1 つのバイナリで扱えるテレメトリコレクタで、prometheus.exporter.* という形で多くの exporter を内蔵しています。そこで「自作 exporter を Alloy の世界に持ち込むにはどうするのか」「Alloy の component そのものを Go で書けるのか」を調べて、実際に手を動かしてみました。 コードは下記に置いてあります。 https://github.com/jedipunkz/alloy-playground 結論 自作のメトリクスを Alloy で扱う方法は大きく 2 つあります。 パターン 内容 A: 独立 exporter + prometheus.scrape 従来通り Go で exporter を書き、公式の Alloy から HTTP で scrape する B: Alloy を fork して component を追加 Alloy のソースツリーに internal/component/prometheus/exporter/<name> を足してビルドする Alloy の component は Go で書けます。ただし Alloy にはプラグイン機構が無く、exporter 系 component が使う API は internal/ 配下にあるため、パターン B は Alloy を fork してビルドするしかありません。自分のサービス向けの独自メトリクスであれば、運用コストの低いパターン A を選ぶのが良さそうだと感じました。 ...

こんにちは。ジェダイパンくず☁️ です。 以前 2026年6月現時点において SRE がどう AI に向き合っているか調べてみた や Google が提唱する AI in SRE とは何か で、AI SRE エージェントの動向や Google の評価フレームワークについて書きました。その後 ADK Go 2.0 のグラフワークフローを読んで SRE Agent への応用を考える で、実際にインシデントトリアージのワークフローも書いてみています。 ここまでやってみて、ずっと引っかかっていたのが「で、そのエージェントはどれくらい正しく原因を当てられるの？」という問いです。ベンダーの発表では「MTTR が何割短縮」といった数字がよく出てきますが、その多くは自社インフラ上での自己申告で、横並びで比較できるものではありません。 そこで 2026 年に出た AI SRE エージェント向けの評価ベンチマーク 4 本を読んでみました。 OpenRCA 2.0 ORCA-bench Cloud-OpsBench SREGym 読んでみると、4 本ともアプローチは違うのに、エージェントが間違えるパターンについてはほぼ同じことを言っていて面白かったです。本記事では、各ベンチマークの中身、各論文が挙げる課題と解決策、そして自分で SRE エージェントを作るときに持ち帰れることを整理します。 なお 4 本ともプレプリント (arXiv) で、数値は論文に書かれたものをそのまま引用しています。 4 本の全体像 4 本とも「LLM エージェントは障害の root cause を特定できるか」という同じ問いを扱っていますが、何をエージェントに渡して、何を採点するかが違います。 ベンチマーク エージェントに渡すもの 採点の重点 規模 OpenRCA 2.0 静的なテレメトリ (trace / metrics / log) 答えに加えて、原因から症状までの伝播経路 500 件 ORCA-bench 曖昧なユーザー報告 + Grafana 経由の 6 日分テレメトリ + ソースコード on-call に近い条件で当てられるか 1,079 タスク Cloud-OpsBench 障害時の Kubernetes 状態を固めた snapshot を、診断ツール経由で調査 答えに加えて、必要な証拠を集めたか 754 件 SREGym 動いている Kubernetes 環境 診断に加えて、修復まで完了できるか 90 問 ざっくり言うと、OpenRCA 2.0 と Cloud-OpsBench は「答えが合っていても根拠が伴っているか」を測る方向、ORCA-bench と SREGym は「現実の障害対応にどこまで近づけるか」を測る方向に振っています。 ...