ワークショップ概要

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 と従来のゼロコード計装の比較 #

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

1. 計装モデル #

2. 可視性のレベル #

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

4. 運用特性 #

5. Splunk ディストリビューション機能 #