Splunk Observability StudioでGoアプリケーションを効率よく計装する

ISUCON は、お題となる Web サービスを、決められたルールの中で限界まで高速化するチューニングコンテストです。

遅いアプリケーションを前にしたとき、ソースコードから分かることには限りがあります。同じクエリーを繰り返し発行している箇所は、読めば見つかります。しかし、その箇所が実行時間の何割を占めるかは、コードのどこにも書かれていません。割合が分からないまま直すと、速くならない場所に時間を使ってしまいます。

この制約は、コーディングエージェントに改善を任せる場合も変わりません。エージェントもソースコードを読んでいるので、人と同じ見落とし方をします。テレメトリーを渡せるかどうかで、エージェントが出す改善案の順番が変わります。ISUCON の文脈でも、業務のアプリケーションでも、計装は改善作業の前提になります。

本記事では、ISUCON14 の Go 参考実装に計装を追加するにあたり、どのようにAIに任せ、人間はどう決めるかを中心に書いていきます。手順については公式ドキュメントなどをAIに参照させれば人間よりもうまく働いてくれる時代ですので、詳細なものは省いていきます。コードはフォークで公開しています。

本記事で扱う範囲

本記事で扱う範囲は次のとおりです。

• 対象：計装ライブラリや手動計装を使ってサーバースパン、DB スパン、ログの相関、アプリケーション独自のメトリクスを計装していく
• 対象外：計装のオーバーヘッドの測定、コンパイル時計装（otelc）、eBPF による計装

計装のオーバーヘッドは本記事では測っていません。別の記事で扱います。

Go の計装ライブラリでどこまで入るか

Java、Python、Node.js では、起動時にエージェントをアタッチすれば、コードを変えずに計装が入ります。Go は単一の静的バイナリーにコンパイルされるため、アタッチする先がありません。

Go で選べるのは 3 つです。使っているライブラリに対応する計装ライブラリを組み込む方法、ビルド時にコードを注入するコンパイル時計装（otelc、2026 年 7 月に v1）、そして eBPF による計装です。本記事ではもっともシンプルな計装ライブラリを試してみます。

計装ライブラリには、2 つの制約があります。ひとつは、対応する計装ライブラリが存在しないことがある点です。もうひとつは、存在してもそのままでは情報が足りない点です。

その結果、どのライブラリ計装を使って、どこを手動計装で補うかを決める作業が残ります。判断の数は、HTTP ルーター、データベースドライバー、外部 API のクライアント、ログ出力といった、計装の対象になる境界の数だけあります。業務上の指標を独自メトリクスとして足すかどうかも、さらに判断が必要です。

そのあたりの判断の支援をしてくれるのが、先日発表されたSplunk Observability Studioです。

Splunk Observability Studio とは

Splunk Observability Studio（以下 obstudio）は、計装の作業を手元で進めるためのツールです。ローカルで動き、ブラウザーの画面とコーディングエージェントのスキルの両方から使います。

計装に関わるスキルは 3 つあります。

obstudio は OTLP の受け口（gRPC ポート 4317/HTTP ポート 4318）を持ち、届いたトレース、メトリック、ログをその場で確認できます。Splunk Observability Cloud への転送や、アラート条件やダッシュボードの発行も、別のスキルから実行できます。

主な用途は、開発中の確認用です。保持できるのはスパンが 10,000 件まで、メトリックのデータポイントは直近 7 秒ほどで、それを超えると古いものから消えます。ベンチマーク実行時のテレメトリー推移全体を確認したい場合は、Splunk Observability Cloud にテレメトリーを送信して確認・分析します。

$otel-audit スキルで計装を評価する

$otel-audit スキルは、ソースコードを読んでルートとデータベースアクセスを数え、足りない計装を指摘として並べます。

Audit Score は 15% でした。レポートの要約は「18 routes · 0 span entries · 0 metric entries · 2 log integrations」です。ウェブアプリケーションのルートは 18 本あるのに、スパンもメトリックも 1 つもありません。

このスコアを100%にすればいいというわけではありません。たとえば、Logs は「present（存在する）」と表示されていますが、実体は標準出力への出力だけで、OTLP の設定はなく、トレースIDの出力もありません。スコアは達成度として見るよりも、出発点との差を見ていくときの参考として使うのがおすすめです。

また、$otel-audit スキルが読んでいるのはあくまでもソースコードであり、実行環境のパフォーマンスを反映したスコアではありません。ソースコード上ではN+1問題があるようにみえたとしても、データの特性上 1+1 程度のクエリー数にしかならないかもしれません。しかし、最低限の計装を始めなければ、実行環境のパフォーマンスの様子を知ることは不可能です。まずはソースコードから必要そうな計装をして観測可能な状況を作り、次に、パフォーマンス改善をしていきましょう。

指摘を選んで実装する

今回 $otel-audit スキルが指摘したのは 11 件でした。それぞれに「計装すると何が見えるようになるか」が解説されています。

たとえば OTEL-002 は「HTTP リクエストにルート名付きのサーバースパンがない」という指摘で、計装すると GET /api/app/nearby-chairs のようなスパン名でルート単位の遅延とエラー率が見えるようになる、と書かれています。OTEL-003 は「リクエストの中で DB クエリーが見えない」で、同じクエリーの繰り返しが一目で分かるようになる、と続きます。指摘間の依存も示されています。OTEL-002 と OTEL-003 は、どちらも OTEL-001 の SDK 設定が前提であるはずです。

単に「スパンを追加する」ではなく「ルート単位の遅延が見えるようになる」と書かれていれば、いま必要かどうかを決められます。

選んだ指摘は、画面下部でコマンドになります。$otel-instrument --ids OTEL-001,OTEL-002,... の形で、対象のディレクトリーとともに生成されます。これをコーディングエージェントに渡すと、実装が始まります。選ぶのは人、書くのは機械、という分担です。

今回は 11 件すべてを選び、2 回に分けて実装しました。結果、Audit Score は 15% から 80% に上がり、指摘は 3 件に減りました。要約は「18 routes · 52 span entries · 22 metric entries」です。

AI では決められないこと

多くの場面で AI エージェントは妥当な判断と実装をします。しかし、すべてのことに対して妥当な判断ができるとは限りません。

まず、Goのフレームワークchiには、OpenTelemetry公式の計装はありません。コミュニティーの riandyrn/otelchi はありますが、これを使うべきかどうかは判断が分かれるところでした。今回はこのフレームワーク計装を使わず、標準の otelhttp でハンドラーをラップする選択をしています。依存を増やさずに済みますが、コードの変更箇所が多く、計装を外す場面で仕事が増えるかもしれません。

さらに、RDB リクエストのスパンがエラーで埋まりました。ベンチマーク 1 回で 541 件中 496 件です。

これはアプリケーションの障害ではありません。go-sql-driver が返す driver.ErrSkip が記録されたものです。これは「プリペアードステートメントに切り替える」という合図であり、エラーではありませんが、otelsql はエラーとして扱っています。これを抑制する必要がありました。

ほかにもいくつか、$otel-instrument スキルだけでは完結しないケースがあります。ISUCON の場面では計装の仕上がりはその後の試行錯誤回数に直結するため、追加のチェックをしたり、初期のプロンプトやスキルを見直したりする必要はあるかもしれません。やはり、事前のリハーサルはおすすめします。

まとめ

Splunk Observability Studio は、どんな計装が足りないかを洗い出し、選んだ計装を実装します。今回は 18 本のルートに対して、52 のスパンと 22 のメトリックを実装できました。指摘に「計装すると何が見えるか」が書かれているため、入れるかどうかの判断も速くなります。

AI が判断に迷う場面では、人間が手伝う必要があります（開発を「支援」してるのはエージェントなのか人間なのか、もうわからなくなってきてますね！）。対応する計装ライブラリがない箇所をどう埋めるか、ライブラリの既定が生む見かけの異常をどう抑えるかまで、今回は触れました。

仕事はまだ残っています。計装が意図どおりに終わったか、出力されたテレメトリーが実際に役に立つものかまでは、まだ詳しくは見ていません。トレースが出力されたとしても、それがパフォーマンス改善の参考になるかは、もう少し深く分析する必要はあります。

とはいえ、初期の計装が入ったことで、何がどう動いているのかの概要はつかめるようになります。どんなパスが叩かれているのか、スループットはどうか、レイテンシーやエラーはあるか、どんな DB をどう使っているのかなどなど。次の記事では、どこへ時間が使われていたかを分析し、実際にパフォーマンスを改善していきます。

次のステップ

• Splunk Observability Cloud Free Edition は、15 ホストまでクレジットカードなしで登録できます。機能とユーザー数の制限はありません。
• 計装の差分は GitHubリポジトリ で、実装の詳細は otelhttp とXSAM/otelsql のドキュメントで確認できます。
• ウェビナー「計装して、測って、外す。ISUCONの過去問で学ぶOpenTelemetryの実践」 では、本記事の内容をライブで実演します。2026 年 10 月 22 日（木）12:00 から 12:50 です。