Japanese Translation: v6.45

content/ja/ninja-workshops/16-obi-ebpf/1-workshop-overview/_index.md

@@ -1,78 +1,78 @@
 ---
-title: ワークショップの概要
-linkTitle: 1. ワークショップの概要
+title: ワークショップ概要
+linkTitle: 1. ワークショップ概要
 weight: 1
 archetype: chapter
 time: 5 minutes
-description: OBI ワークショップの目標、前提条件、アーキテクチャ。
+description: OBI ワークショップの目標、前提条件、およびアーキテクチャ。
 ---
 
 ## 学習内容
 
-このワークショップを終えると、以下のことができるようになります:
+このワークショップを終了すると、以下のことができるようになります
 
-- eBPFがLinuxカーネルレベルでゼロコード計装をどのように実現するかを理解する
-- ベアホスト上でOBIバイナリを使用して実行中のアプリケーションを計装する
-- Docker Composeでポリグロットマイクロサービススタックをデプロイし、1つのコンテナで分散トレーシングを追加する
-- Splunk OTel Collector Helm chartを使用して同じスタックをKubernetesにデプロイし、1つのフラグでOBIを有効にする
-- Splunk APMで分散トレース、サービスマップ、リクエストフローを確認する
+- eBPF が Linux カーネルレベルでゼロコード計装を可能にする仕組みを理解する
+- ベアホスト上で OBI バイナリを使用して実行中のアプリケーションを計装する
+- Docker Compose でポリグロット（複数言語）マイクロサービススタックをデプロイし、1つのコンテナで分散トレーシングを追加する
+- Splunk OTel Collector Helm chart を使用して同じスタックを Kubernetes にデプロイし、1つのフラグで OBI を有効にする
+- Splunk APM で分散トレース、サービスマップ、リクエストフローを表示する
 
 ## 前提条件
 
-ワークショップインスタンスには必要なものがすべて事前設定されています:
+ワークショップインスタンスには必要なものがすべて事前設定されています
 
 | 要件 | ワークショップインスタンスでの状態 |
 |---|---|
-| Linux ホスト | 提供済み (Ubuntu) |
+| Linux ホスト | 提供済み（Ubuntu） |
 | Python 3.9+ | インストール済み |
 | Docker & Docker Compose | インストール済み |
 | K3s (Kubernetes) | インストール済み |
 | kubectl | インストール済み |
 | Helm 3 | インストール済み |
 | ワークショップアセット | `~/workshop/obi/` にデプロイ済み |
 
-以下も必要です:
+以下も必要です
 
 | 要件 | 取得方法 |
 |---|---|
 | Splunk Observability Cloud アカウント | インストラクターから提供されます |
-| **Splunk Access Token** (Ingest) | インスタンスで `env` と入力し、`ACCESS_TOKEN` を探してください |
-| **Splunk Realm** (例: `us0`, `us1`, `eu0`) | インスタンスで `env` と入力し、`REALM` を探してください |
-| **ユニークな名前** (例: `shw-2c74`) | `env` で `INSTANCE` を探してください。`host.name` として使用されます |
+| **Splunk Access Token**（Ingest） | インスタンスで `env` と入力し、`ACCESS_TOKEN` を探してください |
+| **Splunk Realm**（例`us0`、`us1`、`eu0`） | インスタンスで `env` と入力し、`REALM` を探してください |
+| **ユニークな名前**（例`shw-2c74`） | `env` で `INSTANCE` を探してください。`host.name` として使用されます |
 
 ## アーキテクチャ
 
-このワークショップでは、リクエストチェーンを形成する3つのシンプルなマイクロサービスを使用します:
+このワークショップでは、リクエストチェーンを形成する3つのシンプルなマイクロサービスを使用します
 
 ```text
 Frontend (Node.js :3000)  →  Order-Processor (Go :8080)  →  Payment-Service (Go :8081)
 ```
 
-これらのサービスには**オブザーバビリティコードが一切ありません** -- OpenTelemetry SDKも、トレーシングヘッダーも、いかなる種類の計装もありません。OBIはeBPFプローブを使用してカーネルからこれらを計装し、OpenTelemetry互換のトレースを生成し、Splunk OTel Collectorに送信します。CollectorはそれをSplunk Observability Cloudに転送します。
+これらのサービスには**オブザーバビリティコードがまったくありません** - OpenTelemetry SDK なし、トレーシングヘッダーなし、いかなる種類の計装もありません。OBI は eBPF プローブを使用してカーネルからこれらを計装し、OpenTelemetry 互換のトレースを生成して Splunk OTel Collector に送信し、そこから Splunk Observability Cloud に転送されます。
 
-## OBI とは?
+## OBI とは？
 
-[OBI (OpenTelemetry eBPF Instrumentation)](https://opentelemetry.io/docs/zero-code/obi/) は、LinuxカーネルのeBPFプローブを使用してアプリケーションを流れるHTTP/gRPCトラフィックを観測するスタンドアロンエージェントです。**カーネルから**プロセスにアタッチします -- SDKも、コード変更も、再コンパイルも不要です。リクエストを検知し、OpenTelemetry互換のトレーススパンを生成し、Collectorに送信します。
+[OBI (OpenTelemetry eBPF Instrumentation)](https://opentelemetry.io/docs/zero-code/obi/) は、Linux カーネルの eBPF プローブを使用してアプリケーションを流れる HTTP/gRPC トラフィックを監視するスタンドアロンエージェントです。**カーネルから**プロセスにアタッチします - SDK なし、コード変更なし、再コンパイルなし。リクエストを監視し、OpenTelemetry 互換のトレーススパンを生成して、コレクターに送信します。
 
-これはSDKでの計装が**できない**、または**しない**組織にとって価値があります:
+これは、SDK で計装**できない**または計装**したくない**組織にとって価値があります
 
 - ソースアクセスのないレガシーシステム
-- 再コンパイルがオプションにないコンパイル言語
+- 再コンパイルができないコンパイル言語
 - 開発者の抵抗（「計装を追加する時間がない」）
 - コード変更がフル監査サイクルをトリガーする規制上の制約
 
 ## 価値提案
 
-多くの組織には、OpenTelemetry SDKでの計装が**できない**、または**しない**アプリケーションがあります:
+多くの組織には、OpenTelemetry SDK で計装**できない**または計装**したくない**アプリケーションがあります
 
-- **レガシーシステム**: COBOLからJavaへの移行、10年前の .NET Frameworkアプリ、ソースアクセスのないベンダー提供バイナリ
-- **コンパイル言語**: 再コンパイルがオプションにない、またはチームが離れてしまったGo、Rust、C++ サービス
-- **開発者の抵抗**:「時間がない」、「スプリントに含まれていない」、「動作しているコードは変更しない」
-- **規制上の制約**: コード変更がフル監査/認証サイクルをトリガーする
+- **レガシーシステム**：COBOL から Java への移行、10年以上前の .NET Framework アプリ、ソースアクセスのないベンダー提供バイナリ
+- **コンパイル言語**：再コンパイルができない、またはチームが離れてしまった Go、Rust、C++ サービス
+- **開発者の抵抗**：「時間がない」、「スプリントに入っていない」、「動いているコードは変更しない」
+- **規制上の制約**：コード変更がフル監査/認証サイクルをトリガーする
 
-OBIは**コード変更なしで完全な分散トレーシング**を提供します:
+OBI は**コード変更なしで完全な分散トレーシング**を提供します
 
-- **SDK 統合ゼロ** -- インポートなし、依存関係なし、コンパイル時の変更なし
-- **アプリケーション再起動ゼロ** -- OBIはeBPF経由で既に実行中のプロセスにアタッチします
-- **言語非依存** -- Go、Node.js、Python、Java、Rust、C++ -- HTTPまたはgRPCを話すものなら何でも動作します
-- **1つのコンテナまたは1つの Helm フラグ** -- composeに追加するか、Helm chartで `obi.enabled=true` を有効にするだけで完了です
+- **SDK 統合ゼロ**：インポートなし、依存関係なし、コンパイル時の変更なし
+- **アプリケーション再起動ゼロ**：OBI は eBPF 経由で既に実行中のプロセスにアタッチします
+- **言語に依存しない**：Go、Node.js、Python、Java、Rust、C++、または HTTP や gRPC を使用するあらゆるものに対応
+- **1つのコンテナまたは1つの Helm フラグ**：compose に追加するか、Helm chart で `obi.enabled=true` を有効にするだけで完了

content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/1-install-and-run.md

@@ -5,7 +5,7 @@ weight: 1
 
 ## Python 環境のセットアップ
 
-Phase 0ディレクトリに移動し、仮想環境を作成します:
+Phase 0 ディレクトリに移動し、仮想環境を作成します
 
 {{< tabs >}}
 {{% tab title="Script" %}}
@@ -31,10 +31,10 @@ Successfully installed flask-3.x.x ...
 
 ## Splunk 認証情報の設定
 
-認証情報を環境変数としてエクスポートします。各プレースホルダーを実際の値に置き換えてください:
+認証情報を環境変数としてエクスポートします。各プレースホルダーを実際の値に置き換えてください
 
 {{% notice title="Exercise" style="green" icon="running" %}}
-`env` と入力したときに、環境に `ACCESS_TOKEN`、`REALM`、`INSTANCE` の値が設定されている必要があります。
+`env` と入力すると、環境には `ACCESS_TOKEN`、`REALM`、`INSTANCE` の値が設定されているはずです
 
 **存在しない場合は、以下のようにエクスポートしてください**
 
@@ -48,26 +48,26 @@ export INSTANCE="<YOUR_IDENTIFIER>"
 
 ## アプリの実行
 
-Flaskアプリをバックグラウンドで起動します:
+Flask アプリをバックグラウンドで起動します
 
 ``` bash
 python3 app.py &
 ```
 
-起動時に、アプリは単一の `app.heartbeat` メトリクスをSplunk Ingest APIに直接送信します。以下のように表示されるはずです:
+起動時に、アプリは単一の `app.heartbeat` メトリクスを直接 Splunk Ingest API に送信します。以下のように表示されるはずです
 
 ``` text
 Heartbeat sent to Splunk (200)
  * Running on http://0.0.0.0:5150
 ```
 
-エンドポイントにアクセスして、動作を確認します:
+エンドポイントにアクセスして、動作していることを確認します
 
 ``` bash
 curl http://localhost:5150/hello
 ```
 
-以下のようなレスポンスが返されるはずです:
+以下のレスポンスが返ってくるはずです
 
 ``` json
 {
@@ -78,11 +78,11 @@ curl http://localhost:5150/hello
 
 ## Splunk での確認
 
-1. [Metric Finder](https://app.signalfx.com/#/metrics) を開き、`app.heartbeat` を検索します
-2. 設定した値と一致する `host.name` を持つメトリクスが表示されるはずです。
+1. [Splunk Observability Cloud UI](http://app.us1.signalfx.com) を開き（URL はワークショップの場所によって異なります）、Metric Finder で `app.heartbeat` を検索します（または[チャートを作成](https://app.us1.signalfx.com/#/chart/new?template=default&filters=sf_metric%3Aapp.heartbeat)します）
+2. 設定した値と一致する `host.name` 属性を持つメトリクスが表示されるはずです。
 
 ![app.heartbeat](./images/heartbeat.png)
 
 {{% notice title="Note" style="info" %}}
-この時点で、アプリが動作しており、Splunkがデータを受信できることが確認できました。しかし、**トレースはゼロ**です。APMは空の状態です。アプリには計装コードが一切含まれていません。
+この時点で、アプリが動作しており、Splunk がデータを受信できることが確認できました。しかし、**トレースはゼロ**で APM は空です。アプリにはインストルメンテーションコードがまったくありません。
 {{% /notice %}}

content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md

@@ -1,18 +1,18 @@
 ---
-title: 2. OBI による計装
+title: 2. OBI によるインストルメンテーション
 weight: 2
 ---
 
-実行中のアプリにAPMトレースを追加します。**コードを一行も変更する必要はありません**。
+次に、**コードを一行も変更せずに**、実行中のアプリに APM トレーシングを追加します。
 
 ## OBI バイナリの抽出
 
-OBIにはまだスタンドアロンのダウンロードがないため、Dockerイメージからバイナリを抽出します：
+OBI にはまだスタンドアロンのダウンロードがないため、Docker イメージからバイナリを抽出します
 
 {{< tabs >}}
-{{% tab title="スクリプト" %}}
+{{% tab title="Script" %}}
 
-``` bash
+```bash
 IMAGE=otel/ebpf-instrument:main
 sudo docker pull $IMAGE
 ID=$(sudo docker create $IMAGE)
@@ -22,9 +22,9 @@ ls -la ./obi
 ```
 
 {{% /tab %}}
-{{% tab title="出力例" %}}
+{{% tab title="Example Output" %}}
 
-``` text
+```text
 main: Pulling from otel/ebpf-instrument
 0f5fbf7fdc05: Pull complete
 c9d0c8eb6b20: Pull complete
@@ -44,14 +44,14 @@ baa799720f42deaeeeb7690a39b91a5ae16f71ec33833d8a963808f14109ea0f
 
 ## OBI の実行
 
-{{% notice title="演習" style="green" icon="running" %}}
+{{% notice title="Exercise" style="green" icon="running" %}}
 
-**別のターミナル**で、`sudo` を使用してOBIを実行します。3つのプレースホルダーを前のステップで取得したrealm、token、hostnameに置き換えてください：
+**別のターミナル**で、`sudo` を使用して OBI を実行します。3つのプレースホルダーを前のステップで確認した realm、token、hostname に置き換えてください（完了まで1〜2分かかる場合があります）
 
 {{< tabs >}}
-{{% tab title="スクリプト" %}}
+{{% tab title="Script" %}}
 
-``` bash
+```bash
 cd ~/workshop/obi/01-obi-python
 
 sudo env \
@@ -65,10 +65,10 @@ sudo env \
 ```
 
 {{% /tab %}}
-{{% tab title="出力で確認する内容" %}}
+{{% tab title="Look for this in your Output" %}}
 トラフィックを生成し、以下の出力を確認してください
 
-``` text
+```text
 ...
 time=2026-02-27T19:29:56.296Z level=INFO msg="instrumenting process" component=discover.traceAttacher cmd=/usr/bin/python3.10 pid=245031 ino=7094 type=python service=warmup-app logenricher=false
 ...
@@ -80,25 +80,25 @@ time=2026-02-27T19:29:58.278Z level=INFO msg="Launching p.Tracer" component=gene
 
 {{% /notice %}}
 
-### これらの変数の役割
+### これらの変数は何をするのか？
 
 | 変数 | 目的 |
 |---|---|
 | `sudo` | eBPF プローブには root/カーネルアクセスが必要です |
-| `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` | Splunk の OTLP トレース取り込み用の完全な URL です。シグナル別の環境変数はこの URL に正確に送信します。ベースの `OTEL_EXPORTER_OTLP_ENDPOINT` は `/v1/traces` を追加しますが、これは Splunk のパスと一致しません |
+| `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` | Splunk の OTLP トレースインジェスト用の完全な URL です。シグナルごとの環境変数はこの URL に正確に送信します。ベースの `OTEL_EXPORTER_OTLP_ENDPOINT` は `/v1/traces` を追加しますが、これは Splunk のパスと一致しません |
 | `OTEL_EXPORTER_OTLP_HEADERS` | Splunk 用の認証ヘッダーです |
 | `OTEL_SERVICE_NAME` | Splunk APM に表示されるサービス名です |
-| `OTEL_RESOURCE_ATTRIBUTES` | すべてのトレースに `deployment.environment` と `host.name` を設定し、データをフィルタリングできるようにします |
-| `OTEL_EBPF_OPEN_PORT` | OBI にポート 5150 でリッスンしているプロセスを計装するよう指示します |
+| `OTEL_RESOURCE_ATTRIBUTES` | すべてのトレースに `deployment.environment` と `host.name` を設定し、自分のデータをフィルタリングできるようにします |
+| `OTEL_EBPF_OPEN_PORT` | ポート 5150 でリッスンしているプロセスをインストルメントするよう OBI に指示します |
 
-{{% notice title="注意" style="info" %}}
-OBIのログで `failed to upload metrics: 404 Not Found` のような警告が表示されることがあります。これは想定内の動作です。Splunkの直接取り込みには標準的なOTLPメトリクスエンドポイントがありません。トレースは正しくエクスポートされます。フェーズ2では、コレクターがトレースとメトリクスの両方を適切に処理します。
+{{% notice title="Note" style="info" %}}
+OBI のログに `failed to upload metrics: 404 Not Found` のような警告が表示される場合があります。これは想定内の動作です。Splunk のダイレクトインジェストには標準の OTLP メトリクスエンドポイントがありません。トレースは正常にエクスポートされます。フェーズ 2 では、コレクターがトレースとメトリクスの両方を適切に処理します。
 {{% /notice %}}
 
 ## トラフィックの生成
 
-最初のターミナルに戻り、いくつかのリクエストを生成します：
+最初のターミナルに戻り、いくつかのリクエストを生成します
 
-``` bash
+```bash
 for i in $(seq 1 20); do curl -s http://localhost:5150/hello; sleep 1; done
 ```