ワークショップの概要

OBI ワークショップの目標、前提条件、およびアーキテクチャ。

学習内容 #

このワークショップを終了すると、以下のことができるようになります

• eBPF が Linux カーネルレベルでゼロコード計装をどのように実現するかを理解する
• ベアホスト上で OBI バイナリを使用して実行中のアプリケーションを計装する
• Docker Compose でポリグロット（複数言語）マイクロサービススタックをデプロイし、1つのコンテナで分散トレーシングを追加する
• Splunk OTel Collector Helm chart を使用して同じスタックを Kubernetes にデプロイし、1つのフラグで OBI を有効にする
• Splunk APM で分散トレース、サービスマップ、リクエストフローを確認する

前提条件 #

ワークショップインスタンスには必要なものがすべて事前設定されています

以下も必要です

アーキテクチャ #

このワークショップでは、リクエストチェーンを形成する3つのシンプルなマイクロサービスを使用します

Frontend (Node.js :3000)  →  Order-Processor (Go :8080)  →  Payment-Service (Go :8081)

これらのサービスにはオブザーバビリティコードが一切ありません — OpenTelemetry SDK なし、トレーシングヘッダーなし、いかなる種類の計装もありません。OBI は eBPF プローブを使用してカーネルからこれらを計装し、OpenTelemetry 互換のトレースを生成し、Splunk OTel Collector に送信します。Splunk OTel Collector はそれを Splunk Observability Cloud に転送します。

OBI とは？ #

OBI (OpenTelemetry eBPF Instrumentation) は、Linux カーネルの eBPF プローブを使用してアプリケーションを流れる HTTP/gRPC トラフィックを観測するスタンドアロンエージェントです。カーネルからプロセスにアタッチします — SDK 不要、コード変更不要、再コンパイル不要です。リクエストを検知し、OpenTelemetry 互換のトレーススパンを生成し、コレクターに送信します。

これは SDK で計装できない、またはしない組織にとって有用です

• ソースアクセスのないレガシーシステム
• 再コンパイルが選択肢にないコンパイル言語
• 開発者の抵抗（「計装を追加する時間がない」）
• コード変更があるたびに完全な監査サイクルが必要な規制上の制約

価値提案 #

多くの組織には、OpenTelemetry SDK で計装できない、またはしないアプリケーションがあります

• レガシーシステム: COBOL から Java への移行、10年以上前の .NET Framework アプリ、ソースアクセスのないベンダー提供バイナリ
• コンパイル言語: Go、Rust、C++ サービスで再コンパイルが選択肢にない、またはチームが離れてしまった場合
• 開発者の抵抗: 「時間がない」「スプリントに入っていない」「動いているコードは変えない」
• 規制上の制約: コード変更があると完全な監査/認証サイクルが発生する

OBI はコード変更なしで完全な分散トレーシングを提供します

• SDK 統合ゼロ: インポート不要、依存関係不要、コンパイル時の変更不要
• アプリケーション再起動ゼロ: OBI は eBPF 経由で実行中のプロセスにアタッチします
• 言語非依存: Go、Node.js、Python、Java、Rust、C++ など、HTTP または gRPC を使用するあらゆるものに対応
• 1つのコンテナまたは1つの Helm フラグ: compose に追加するか、Helm chart で obi.enabled=true を有効にするだけで完了です

OBI vs 従来のゼロコード計装 #

OBI と既存の従来の言語固有ゼロコード計装（Java、JS、.NET、Python、Go、PHP）は、オブザーバビリティ戦略において補完的な役割を果たします。違いを理解することで、各アプローチをいつ使用するかを判断できます。

1. 計装モデル #

2. 可視性のレベル #

3. カバレッジと互換性 #

4. 運用特性 #

5. Splunk Distro の機能 #