セルフサービスのオブザーバビリティ基盤をOpenTelemetryで作る / Building a Self-Service Observability Platform with OpenTelemetry

Platform Engineering Kaigi 2026の登壇資料です。
https://www.cnia.io/pek2026/sessions/eba4a57f-e4f0-4201-b731-0a37d6a53f7a/

詳細な内容はこちらのZennの書籍に書いてあります。
https://zenn.dev/ymotongpoo/books/observability-platform-with-otel

本セッションで紹介した構成のブループリントとしてこのプロジェクト公開しています
https://github.com/ymotongpoo/otel-platform-blueprint

Transcript

1. セルフサービスの オブザーバビリティ基盤を OpenTelemetryで作る システム全体で統一された計装を仕組みで解決 Platform Engineering Kaigi 2026 Room A 16:00-16:30 Yoshi Yamaguchi (@ymotongpoo)
2. 山口 能迪（やまぐちよしふみ） Staff Developer Advocate Grafana Labs 専門領域 オブザーバビリティ OpenTelemetry SRE @ymotongpoo
3. ある日の障害対応 例: 半年間誰も気づかない問題 どのチームも個々では正しく判断していた しかし、個別の判断が、横断検索とトレースを分断 同じ本番環境を指す名前 production prod prd トレースの断絶
4. 前提の共有 OpenTelemetryの最小構成 計装がテレメトリーを作る OTLP という標準の形式で送る Collector が受けて、加工して、送る 加工を担う部品がプロセッサー 送信元を表すリソース属性が付く 例: service.name=payment
5. どう防ぐか 中央レビューに集約すると 依頼が中央チームに集まると待ちが発生し、チームも消耗する
6. 今日の全体像 三本柱 1. 計装の配布: 何をどう送るかを配布物で決める 2. Collector層の管理: 転送経路の判断をアプリから引き剥がす 3. 規約のガバナンス: 柱1と柱2へ共通の語彙を供給する
7. セルフサービスの設計 誰が何を決めるか 決めさせないのではなく、決めなくていいようにする 柱 計装 プラットフォームが配る チームが決める 基盤が強制する ディストリビューションと 業務のスパンと リソース属性と文 デフォルト値 属性 脈の伝搬 許可された範囲 認証とPII削除、容 の追加 量制御 ドメイン属性の 名前空間、型、互 意味 換性 Collector バイナリとパイプライン 規約 レジストリ、生成物、検査
8. 柱1 計装を配る
9. 柱1: 最初の状態 各チームが書いていたもの exporter, err := otlptracegrpc.New(ctx, otlptracegrpc.WithEndpoint("collector.internal:4317"), otlptracegrpc.WithInsecure(), ) res, _ := resource.New(ctx, resource.WithAttributes(semconv.ServiceName("payment")), ) tp := sdktrace.NewTracerProvider( sdktrace.WithBatcher(exporter), sdktrace.WithResource(res), ) otel.SetTracerProvider(tp) otel.SetTextMapPropagator(propagation.TraceContext{}) 判断して書いていたもの 送信先 リソース属性 文脈の伝搬 サンプリング Propagatorの1行が抜けても動く
10. 柱1 計装の配布 配布するもの SDKディストリビューション 組織のデフォルト値入り SDK初期化の呼び出しと、失敗時の処理だけ。 コードに触れないサービスは、ゼロコード計装で最低限の 支援。 チームの自由 業務のスパンと属性 任意で記録するデータ 標準の環境変数による調整 自動検査: リソース属性の欠落と伝搬の設定漏れをCIで検出
11. 柱2 Collector層
12. 柱 2 : 構 成 パ タ ーン エージェントとゲートウェイの二段 エージェントはノードごと。ホストのメタデータを付け、全 ノードで同じ設定 ゲートウェイは組織単位。テイルサンプリング、PII削除、認 証を集約 テイルサンプリングが減らすのは保存量だけ。ゲートウェイ までの流量は減らない
13. 柱2 Collector層の管理 配布するもの 必要なコンポーネントだけを選んでビルドした社内 Collectorを配る。 設定は、チームに任意の内容を書かせず、許可した項目を指 定してもらう。テナントと環境ごとの振り分けもこの層で決 める。 台数が増えたらOpAMPで配布を自動化する（今日は触れませ ん） チームの自由 自チーム専用の追加パイプライン 送信先や追加属性のパラメータ 自動検査: 基盤が持つプロセッサーの設定と処理順が実効設定に 残り、接続先が許可リスト内であることを検査
14. 柱2: OTELCOL VALIDATEの注意点 設定を重ねると後勝ちになる # 基盤が配る base.yaml（抜粋） service: pipelines: traces: processors: [memory_limiter, transform/redact] # チームが重ねるファイル service: pipelines: traces: processors: [memory_limiter] $ otelcol validate --config base.yaml --config team.yaml $ echo $? 0 <-- エラーなし この例だとPII削除が消える リストごと置き換わり、実効設定から transform/redact が消える 検証は通る Collectorの設定としては妥当 validate はYAMLの正しさしか確認しない
15. 柱3 規約のガバナンス
16. 柱 3 : O P E N T E L E M E T R Y W E A V E R と レ ジ ス トリ Weaverでセマンティック規約を管理する 配布するもの OpenTelemetry Weaverは、レジストリのYAMLを検査 し、SDKの定数やCollectorの設定を生成するCLI # registry.yaml groups: - id: com.example.delivery type: attribute_group attributes: - id: com.example.delivery.id type: string 属性の名前と型と意味を、1か所に定義する そこからSDKの属性定数、Collectorの変換設定、ドキュメ ントを生成して配布 チームの自由 ドメイン固有の属性の意味 レジストリへのPRとして追加する 自動検査: 命名規則をポリシーで検査し、実データとの照合まで 自動化する
17. 柱3: 運用における循環 定義から、実データの検査まで レジストリのYAMLが唯一の定義 PRで check と diff 、マージ後に generate 実環境のテレメトリーを live-check で照合 検出したずれはレジストリの変更へ戻す
18. 生成AIと運用
19. 書く側 LLMも同じ基盤で扱う LLMを使うワークロードは、トークン使用量や会話の構造という新しいテレメトリーを出す OpenTelemetryには、これを扱うGenAI規約がある 三本柱がそのまま使える ただし GenAI 規約は Development 段階 リリースもタグも無いので、コミットで固定して差分を検知する
20. 読む側 サービス名の揺れでAIの検索範囲が欠ける service.name=payment で検索する 実際のエラーは payment-api で起きていた 結果は返るが、少ない 「影響は限定的」と報告される
21. 明日から 最初の一歩 同時に始める必要はないが、1つでも始めることが大事 柱1 柱2 ディストリビューションを作 Collector層を立てる る まずエージェントへ送信先を向け、 新規サービスから採用する。既存は 更新のタイミングで移す ゲートウェイを1台置く。PII削除と 認証はここに入れる。ここから始め るのが最も早い 柱3 レジストリを置く まず新しい属性の追加だけを通す。 生成とlive-checkは後から足せる
22. 人の判断から仕組みへ