diff --git a/content/ja/ninja-workshops/16-obi-ebpf/1-workshop-overview/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/1-workshop-overview/_index.md index 3e7fef7dfe..2138ce494e 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/1-workshop-overview/_index.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/1-workshop-overview/_index.md @@ -1,29 +1,29 @@ --- -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) | インストール済み | @@ -31,48 +31,48 @@ description: OBI ワークショップの目標、前提条件、アーキテク | 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` を有効にするだけで完了 diff --git a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/1-install-and-run.md b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/1-install-and-run.md index ba71687c58..6155d3edc6 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/1-install-and-run.md +++ b/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="" ## アプリの実行 -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 %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md index fe770340ae..4beab2eb99 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md +++ b/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 ``` diff --git a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md index 1cfd3894ff..4ee7a0cf46 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md @@ -7,26 +7,26 @@ weight: 3 {{% notice title="演習" style="green" icon="running" %}} -1. Splunk Observability Cloudの **APM** に移動します。 +1. Splunk Observability Cloud で **APM** に移動します。 2. サービス名 `warmup-app` でフィルタリングします。 -3. `/hello` エンドポイントのトレースが表示されます。 +3. `/hello` エンドポイントのトレースが表示されるはずです。 **注意: 最初のトレースが取り込まれるまで数分かかる場合があります** {{% /notice %}} ## 何が起きたのか？ -1. Flaskアプリは「素の状態」です。オブザーバビリティのコードは一切含まれていません。helloを返すことと、ハートビートメトリクスを送信する機能しかありません。 -2. OBIはカーネルのネットワークスタックにeBPFプローブをアタッチし、アプリのプロセスを流れるHTTPトラフィックを監視しました。 -3. OBIはOpenTelemetry互換のトレーススパンを生成し、Splunkに直接送信しました。 +1. Flask アプリは「素のまま」で、オブザーバビリティのコードは一切含まれていません。hello を返すことと heartbeat メトリクスを送信することしかできません。 +2. OBI はカーネルのネットワークスタックに eBPF プローブをアタッチし、アプリのプロセスを流れる HTTP トラフィックを観測しました。 +3. OBI は OpenTelemetry 互換のトレーススパンを生成し、Splunk に直接送信しました。 -**カーネルから実行中のプロセスに分散トレーシングを追加しました。SDK も、コード変更も、再起動も不要です。** +**SDK なし、コード変更なし、再起動なしで、カーネルから実行中のプロセスに分散トレーシングを追加しました。** -これはPhase 1とPhase 2で使用するのと同じ技術ですが、ベアプロセスではなくDockerコンテナ内で動作します。 +これは Phase 1 と Phase 2 で使用するのと同じ技術ですが、ベアプロセスではなく Docker コンテナ内で使用します。 ## Phase 0 のクリーンアップ -次に進む前に、PythonアプリとOBIを停止します: +次に進む前に、Python アプリと OBI を停止します: ``` bash kill %1 2>/dev/null diff --git a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/_index.md index 10d024befe..31d36c6578 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/_index.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/_index.md @@ -1,16 +1,16 @@ --- -title: "フェーズ 0: Python ウォームアップ" -linkTitle: 2. Python ウォームアップ +title: "Phase 0: Python ウォームアップ" +linkTitle: 2. Python Warm-up weight: 2 archetype: chapter time: 15 minutes -description: ホスト上で素の Python アプリを実行し、カスタムメトリクスで Splunk への接続を確認してから、OBI バイナリを使用して APM トレースを追加します -- すべて Docker なしで行います。 +description: ホスト上で素の Python アプリを実行し、カスタムメトリクスを使用して Splunk への接続を確認した後、OBI バイナリを使用して APM トレースを追加します。すべて Docker なしで行います。 --- -このフェーズでは、OBIが生のLinuxプロセス上で**カーネルレベル**で動作することを示します。コンテナなし、サイドカーなし、SDKなし -- カーネルからアプリを監視するeBPFバイナリだけです。 +このフェーズでは、OBI が生の Linux プロセス上で**カーネルレベル**で動作することを示します。コンテナなし、サイドカーなし、SDK なし、ただ eBPF バイナリがカーネルからアプリを監視するだけです。 -このセクションを完了すると、以下のことが達成できます： +このセクションの終了時には、以下が完了します -1. オブザーバビリティコードがゼロのPython Flaskアプリが動作している状態 -2. Splunk組織がデータを受信していることの証明（カスタムメトリクス経由） -3. アプリの完全なAPMトレース -- コード変更ゼロでカーネルから追加 +1. オブザーバビリティコードがゼロの Python Flask アプリの実行 +2. Splunk 組織がデータを受信していることの確認（カスタムメトリクス経由） +3. コード変更なしでカーネルからアプリに追加された完全な APM トレース diff --git a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md index d4eeaf9066..e2f8b8ad3d 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md @@ -7,19 +7,20 @@ weight: 1 {{% notice title="演習" style="green" icon="running" %}} -Phase 1/2ディレクトリに移動し、エディタで `docker-compose.yaml` を開きます： +**注:** 環境で `env` コマンドを使用して `ACCESS_TOKEN`、`REALM`、`INSTANCE` を取得してください。これらを設定ファイルに貼り付ける必要があります。 + +Phase 1/2 ディレクトリに移動し、エディタで `docker-compose.yaml` を開きます: ``` bash cd ~/workshop/obi/02-obi-docker vim docker-compose.yaml #or editor of choice ``` -`splunk-otel-collector` サービスを見つけ、4つのプレースホルダー値を実際の認証情報に置き換えます： -**注意:** 必要に応じて、ターミナルで `env` を使用して `ACCESS_TOKEN`、`REALM`、`INSTANCE` を確認できます +`splunk-otel-collector` サービスを見つけ、4つのプレースホルダー値を実際の認証情報に置き換えます: ``` yaml environment: - SPLUNK_INGEST_TOKEN: "YOUR_TOKEN_HERE" # <-- Your Splunk ingest token + SPLUNK_INGEST_TOKEN: "YOUR_ACCESS_TOKEN_HERE" # <-- Your Splunk ingest token SPLUNK_REALM: "YOUR_REALM" # <-- Your realm (us0, us1, eu0, etc.) WORKSHOP_HOST_NAME: "" # <-- the value from INSTANCE when you use `env` on terminal WORKSHOP_ENVIRONMENT: "" # <-- The hostname value above suffixed with `-ebpf` @@ -30,7 +31,7 @@ vim docker-compose.yaml #or editor of choice {{% /notice %}} {{% notice title="ヒント" style="primary" icon="lightbulb" %}} -**なぜ `WORKSHOP_HOST_NAME` と `WORKSHOP_ENVIRONMENT` が必要なのでしょうか？** ワークショップの参加者全員が同じSplunk組織にテレメトリを送信します。これらの値はすべてのメトリクスとトレースの `host.name` と `deployment.environment` 属性になるため、Splunkで**自分の**データをフィルタリングできます。 +**なぜ `WORKSHOP_HOST_NAME` と `WORKSHOP_ENVIRONMENT` が必要なのか？** ワークショップの参加者全員が同じ Splunk 組織にテレメトリを送信します。これらの値はすべてのメトリクスとトレースの `host.name` および `deployment.environment` 属性になるため、Splunk で**自分の**データをフィルタリングできます。 {{% /notice %}} ## スタックの起動 @@ -58,10 +59,10 @@ docker-compose up --build -d {{% /tab %}} {{< /tabs >}} -これにより、ソースから3つのアプリケーションイメージがビルドされ、以下が起動します： +これにより、ソースから3つのアプリケーションイメージがビルドされ、以下が起動します: -- **frontend** - [http://localhost:3000](http://localhost:3000) で稼働 -- **order-processor** - ポート8080で稼働 -- **payment-service** - ポート8081で稼働 -- **splunk-otel-collector** - ポート4317/4318でテレメトリを受信 -- **load-generator** - 2秒ごとに `/create-order` を自動的に呼び出し +- **frontend**: [http://localhost:3000](http://localhost:3000) +- **order-processor**: ポート 8080 +- **payment-service**: ポート 8081 +- **splunk-otel-collector**: ポート 4317/4318 でテレメトリを受信 +- **load-generator**: 2秒ごとに `/create-order` に自動リクエスト diff --git a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md index 896240b70e..72556f117c 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md @@ -1,30 +1,30 @@ --- -title: 3. Check Splunk +title: 3. Splunk の確認 weight: 3 --- ## インフラストラクチャメトリクスの確認 -{{% notice title="Exercise" style="green" icon="running" %}} +{{% notice title="演習" style="green" icon="running" %}} -1. [Metric Finder](https://app.signalfx.com/#/metrics) を開き、`workshop_heartbeat` を検索します。 -2. `host.name` が `WORKSHOP_HOST_NAME` の値と一致するメトリクスが表示されるはずです。 -3. その `host.name` で検索して、Collectorが送信している他のメトリクス（CPU、メモリ、ディスクなど）を確認します。 +1. [Metric Finder](https://app.us1.signalfx.com/#/metrics) を開き（または[チャートを作成](https://app.us1.signalfx.com/#/chart/new?template=default&filters=sf_metric%3Aworkshop_heartbeat)して）、`workshop_heartbeat` を検索します +2. `host.name` が `WORKSHOP_HOST_NAME` の値と一致するメトリクスが表示されるはずです +3. その `host.name` で検索して、Collector が送信している他のメトリクス（CPU、メモリ、ディスクなど）を確認します {{% /notice %}} ## APM が空であることを確認 -{{% notice title="Exercise" style="green" icon="running" %}} +{{% notice title="演習" style="green" icon="running" %}} -1. Splunk Observability Cloudで **APM** に移動します。 -2. 定義した環境（`WORKSHOP_ENVIRONMENT`）でフィルタリングします。 -3. **空** であるはずです（または存在しない）。サービス、トレース、サービスマップはありません。 +1. Splunk Observability Cloud で **APM** に移動します +2. 定義した環境（`WORKSHOP_ENVIRONMENT`）でフィルタリングします +3. **空**であるはずです（または存在しないはずです）。サービス、トレース、サービスマップはありません {{% /notice %}} -Collectorはデフォルトでインフラストラクチャメトリクスを送信しますが、トレースを生成しているものがないため、エクスポートするトレースがありません。 +Collector はインフラストラクチャメトリクスを送信しています。これはデフォルトの動作ですが、何もトレースを生成していないため、エクスポートするトレースがありません。 -{{% notice title="Note" style="info" %}} -これは「導入前」の状態です。実際のリクエストを処理する3つのサービスが稼働していますが、Splunk APMはそれらのリクエストをまったく可視化できていません。次のセクションでは、**アプリケーションコードに一切触れることなく**、これを修正します。 +{{% notice title="注記" style="info" %}} +これが「導入前」の状態です。3つのサービスが実際のリクエストを処理していますが、Splunk APM からはそれらのリクエストがまったく見えていません。次のセクションでは、**アプリケーションコードに触れることなく**、これを解決します。 {{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/_index.md index 51517a3b27..caccfbd274 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/_index.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/_index.md @@ -1,13 +1,13 @@ --- -title: "フェーズ 1: Docker -- OBI 導入前" -linkTitle: 3. OBI 導入前の Docker +title: "フェーズ 1: Docker (OBI 適用前)" +linkTitle: 3. OBI 適用前の Docker weight: 3 archetype: chapter time: 15 minutes description: Docker Compose で 3 つのマイクロサービスをデプロイし、APM が空であることを確認します。計装がないため、トレースは存在しません。 --- -このフェーズでは、ポリグロットなマイクロサービススタックをデプロイし、「導入前」の状態を確認します。インフラストラクチャメトリクスはSplunkに送信されますが、アプリケーションには計装が一切されていないため、APMにはトレースがありません。 +このフェーズでは、ポリグロット（またこの言葉です！）マイクロサービススタックをデプロイし、「適用前」の状態を確認します。インフラストラクチャメトリクスは Splunk に送信されますが、アプリケーションには計装が一切ないため、APM にはトレースがまったくありません。 ```text Frontend (Node.js :3000) → Order-Processor (Go :8080) → Payment-Service (Go :8081) diff --git a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md index 8afc5ed1d6..f0218b0a93 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md @@ -7,7 +7,7 @@ weight: 1 {{% notice title="Exercise" style="green" icon="running" %}} -エディターで `docker-compose.yaml` を開きます： +エディターで `docker-compose.yaml` を開きます ``` bash cd ~/workshop/obi/02-obi-docker @@ -15,7 +15,7 @@ docker-compose down vim docker-compose.yaml #or editor of choice ``` -ファイルの一番下までスクロールすると、`PHASE 2` というコメントブロックがあります。以下のブロックを**そのコメントの直下に**貼り付け、**2スペースのインデント**を維持して、他のサービス（`frontend:`、`load-generator:` など）と同じレベルに揃えてください： +ファイルの一番下までスクロールすると、`PHASE 2` と書かれたコメントブロックがあります。以下のブロックを**そのコメントの直下に**貼り付けてください。**2スペースのインデント**を維持して、他のサービス（`frontend:`、`load-generator:` など）と揃うようにします ``` yaml obi: @@ -30,29 +30,31 @@ vim docker-compose.yaml #or editor of choice OTEL_EBPF_CONFIG_PATH: /config/obi-config.yaml ``` +**注意:** vim で貼り付ける場合は、貼り付け前に `:set paste` を使用するとフォーマットが維持されます + ファイルを保存します。 {{% /notice %}} {{% notice title="Tip" style="primary" icon="lightbulb" %}} -`obi:` が2スペースでインデントされていることを確認してください（`frontend:`、`load-generator:` などと同じレベル）。インデントなしで左端に配置すると、Docker Composeは `Additional property obi is not allowed` というエラーで拒否します。**`services:` ブロックの内側**に配置する必要があります。 +`obi:` が2スペースでインデントされていることを確認してください（`frontend:`、`load-generator:` などと同じレベル）。インデントなしで左端に配置すると、Docker Compose は `Additional property obi is not allowed` というエラーで拒否します。`services:` ブロックの**内部に**配置する必要があります。 {{% /notice %}} ### 各行の説明 | 行 | 機能 | 重要な理由 | |---|---|---| -| `image: otel/ebpf-instrument:main` | [OBI コンテナイメージ](https://hub.docker.com/r/otel/ebpf-instrument) | スタックに追加する唯一のものです | -| `pid: host` | ホストの PID 名前空間を共有します | OBI は**他の**コンテナで実行されているプロセスを参照する必要があります | +| `image: otel/ebpf-instrument:main` | [OBI コンテナイメージ](https://hub.docker.com/r/otel/ebpf-instrument) | スタックに追加するのはこれだけです | +| `pid: host` | ホストの PID 名前空間を共有します | OBI は**他の**コンテナで実行されているプロセスを確認する必要があります | | `privileged: true` | カーネルレベルのアクセスを許可します | eBPF プログラムはカーネル関数にプローブをアタッチする必要があります | | `network_mode: host` | ホストのネットワークスタックを共有します | コンテキスト伝播に必要です -- OBI はネットワークレベルでトレースコンテキストを注入します | -| `volumes: ./obi-config.yaml:...` | サービスディスカバリ設定をマウントします | OBI にどのプロセスを計装するか、それらの名前を指定します | +| `volumes: ./obi-config.yaml:...` | サービスディスカバリー設定をマウントします | どのプロセスを計装し、どのような名前を付けるかを OBI に伝えます | | `volumes: /sys/fs/cgroup:...` | cgroup ファイルシステムをマウントします | OBI はこれを使用してコンテナ内で実行されているプロセスを検出します | | `OTEL_EBPF_CONFIG_PATH` | コンテナ内の設定ファイルを指定します | 設定用の標準 OBI 環境変数です | ## OBI の起動 -Docker Composeは `obi` サービスのみが新しいことを検出し、それを起動します。既存のサービスは実行を継続します。 +Docker Compose は `obi` サービスのみが新規であることを検出し、それを起動します。既存のサービスは引き続き実行されます。 {{< tabs >}} {{% tab title="Script" %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md index 2d2c8ac934..23012aa5b3 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md @@ -5,7 +5,7 @@ weight: 2 ## OBI 設定ファイル -`obi-config.yaml`（リポジトリに含まれています）を開いて、OBIがどのようにサービスを検出し、計装するかを理解しましょう: +`obi-config.yaml`（リポジトリに既に含まれています）を開いて、OBI がサービスを検出し計装する方法を理解しましょう ``` bash cat ~/workshop/obi/02-obi-docker/obi-config.yaml @@ -30,14 +30,14 @@ otel_traces_export: ### 各セクションの動作 -**`discovery.instrument`** は、OBIにサービスの検出方法と名前の付け方を指示します。プロセスがリッスンしているポートでマッチングし、生成されるトレースの `service.name` 属性として `name` を割り当てます。これがない場合、OBIは実行ファイルのパスをサービス名として使用します（例: `/usr/local/bin/order-processor`）。 +**`discovery.instrument`** は、OBI にサービスの検出方法と名前の付け方を指示します。リッスンしているポートでプロセスをマッチングし、生成されたトレースの `service.name` 属性として `name` を割り当てます。この設定がない場合、OBI は実行ファイルのパス（例`/usr/local/bin/order-processor`）をサービス名として使用します。 -**`context_propagation: all`** は分散トレーシングの鍵です。OBIはカーネルレベルで送信HTTPリクエストに `Traceparent` ヘッダーを注入します。これにより、`frontend` で開始されたトレースが `order-processor` を経由して `payment-service` まで接続されます -- これらのサービスがトレーシングについて何も知らなくても。 +**`context_propagation: all`** は分散トレーシングの鍵となる設定です。OBI はカーネルレベルで送信 HTTP リクエストに `Traceparent` ヘッダーを注入します。これにより、`frontend` で開始されたトレースが `order-processor` を経由して `payment-service` まで接続されます。これらのサービスがトレーシングについて何も知らないにもかかわらず、です。 -**`otel_traces_export.endpoint`** は、OBIにトレースの送信先を指示します。OBIは `network_mode: host` を使用するため、`localhost:4318` はcomposeファイルでホストにマッピングされたCollectorのポートに到達します。 +**`otel_traces_export.endpoint`** は、OBI にトレースの送信先を指示します。OBI は `network_mode: host` を使用するため、`localhost:4318` は compose ファイルでホストにマッピングされたコレクターのポートに到達します。 {{% notice title="Tip" style="primary" icon="lightbulb" %}} -詳細な設定オプションについては、OBIドキュメントを参照してください: +より詳細な設定オプションについては、OBI のドキュメントを参照してください * [Service discovery](https://opentelemetry.io/docs/zero-code/obi/configure/service-discovery) * [Context propagation](https://opentelemetry.io/docs/zero-code/obi/configure/metrics-traces-attributes/#context-propagation) diff --git a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md index d8957c2d42..6418557449 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md @@ -5,7 +5,7 @@ weight: 2 ## ワークショップアプリケーションのデプロイ -アプリケーションは専用のnamespaceにデプロイされます: +アプリケーションは専用の namespace にデプロイされます: {{< tabs >}} {{% tab title="Script" %}} @@ -36,7 +36,7 @@ deployment.apps/load-generator created ## Splunk OTel Collector のインストール -[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart) は、Kubernetesにcollectorをデプロイする本番環境向けの方法です。collectorのデプロイ、サービス、および設定を自動的に処理します。 +[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart) は、Kubernetes に Collector をデプロイするための本番環境向けの方法です。Collector のデプロイ、サービス、および設定を自動的に処理します。 ### Helm リポジトリの追加 @@ -63,10 +63,10 @@ Update Complete. ⎈Happy Helming!⎈ ### Collector のインストール -これはOBI **なし**でSplunk OTel Collectorをインストールします。次のステップでOBIを有効にして、有効化前後の違いを確認します。 +これにより、OBI **なし**で Splunk OTel Collector がインストールされます。次のステップで OBI を有効にして、有効化前後の違いを確認します。 {{% notice title="Note" style="info" %}} -環境変数 `ACCESS_TOKEN`、`REALM`、および `INSTANCE` は、ワークショップインスタンスで事前に設定されています。`env` を実行して、これらが存在することを確認してください。 +環境変数 `ACCESS_TOKEN`、`REALM`、`INSTANCE` はワークショップインスタンスに事前設定されています。`env` を実行して存在を確認してください。 {{% /notice %}} {{< tabs >}} @@ -124,13 +124,13 @@ splunk-otel-collector-cluster-receiver-xyz34 1/1 Running 0 ## アプリケーションのテスト -NodePort経由でfrontendにアクセスします: +NodePort 経由でフロントエンドにアクセスします: ``` bash kubectl port-forward -n obi-workshop svc/frontend 30000:3000 &; sleep 5 ``` -ポートがフォワードされたら、curlでページにアクセスできます: +ポートフォワーディングが完了したら、curl でページにアクセスできます: ``` bash curl -s http://localhost:30000/create-order | python3 -m json.tool @@ -140,6 +140,6 @@ curl -s http://localhost:30000/create-order | python3 -m json.tool {{% notice title="Exercise" style="green" icon="running" %}} -Splunk APMを確認し、environment `-ebpf` でフィルタリングしてください。collectorからのインフラストラクチャメトリクスは表示されますが、**アプリケーショントレースはまだ表示されません**。サービスは実行中ですが、計装されていません。 +Splunk APM で環境 `-ebpf` でフィルタリングして確認してください。Collector からのインフラストラクチャメトリクスは表示されますが、**新しいアプリケーショントレースはまだ表示されません**。サービスは実行中ですが、まだ計装されていません。 {{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md index 77390c4c9c..8f46005d8f 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md @@ -1,9 +1,9 @@ --- -title: 3. Enable OBI via Helm +title: 3. Helm で OBI を有効化 weight: 3 --- -アプリケーションコードを一切変更せずに、クラスター全体にトレースを追加します。必要なのはHelmのアップグレード1回だけです。 +アプリケーションコードを一切変更せずに、Helm のアップグレード1回だけでクラスター全体にトレーシングを追加します。 ## OBI を有効にして Collector をアップグレード @@ -21,24 +21,24 @@ helm -n obi-workshop upgrade splunk-otel-collector \ {{% /notice %}} -`--set="obi.enabled=true"` の追加が唯一の変更点です。Helmチャートが他のすべてを処理します： +変更点は `--set="obi.enabled=true"` という1つのオプションだけです。Helm チャートが残りのすべてを処理します -- **OBI DaemonSet** をデプロイ（各ノードに1つのPod） -- RBACを設定（ServiceAccount、ClusterRole、ClusterRoleBinding） -- OBIを自動的にCollectorに接続 -- eBPFに必要なLinux権限を付与 +- **OBI DaemonSet** をデプロイ（ノードごとに1つの Pod） +- RBAC を設定（ServiceAccount、ClusterRole、ClusterRoleBinding） +- OBI を自動的に Collector に接続 +- eBPF に必要な Linux ケーパビリティを付与 ### OBI に必要なものは？ -OBI Podは昇格された権限で実行されます。これはeBPFがカーネルレベルで動作するためです： +OBI Pod は、eBPF がカーネルレベルで動作するため、昇格した権限で実行されます ``` yaml -hostPID: true # ノード上のすべてのプロセスを確認（他の Pod を含む） -hostNetwork: true # ネットワークトラフィックを監視し、トレースコンテキストを注入 -privileged: true # カーネルに eBPF プローブをアタッチ +hostPID: true # See all processes on the node, including other pods +hostNetwork: true # Observe and inject trace context into network traffic +privileged: true # Attach eBPF probes to the kernel ``` -クラスターポリシーで必要な場合、権限を削減する方法の詳細については [OBI Security Documentation](https://opentelemetry.io/docs/zero-code/obi/security/) を参照してください。 +クラスターポリシーで必要な場合に権限を削減する方法については、[OBI Security Documentation](https://opentelemetry.io/docs/zero-code/obi/security/) を参照してください。 ## OBI が実行されていることを確認 @@ -68,20 +68,20 @@ level=INFO msg="instrumenting process" service=frontend {{% /tab %}} {{< /tabs >}} -トラフィックを生成します： +トラフィックを生成します ``` bash curl -s http://localhost:30000/create-order | python3 -m json.tool ``` -## Splunk APM で確認 +## Splunk APM を確認 トレースが流れるまで30〜60秒待ちます。 {{% notice title="Exercise" style="green" icon="running" %}} -1. **Service Map**: 3つのサービスが表示されるはずです：`frontend` -> `order-processor` -> `payment-service` -2. **Traces**: 任意のトレースをクリックしてください。3つのサービスすべてにまたがる完全な分散トレースと、各ホップのタイミングが表示されます。 -3. **Phase 2 と同様**: コード変更ゼロ。1つのフラグを指定した `helm upgrade` のみ。 +1. **Service Map**: `frontend` -> `order-processor` -> `payment-service` の3つのサービスが表示されるはずです。 +2. **Traces**: 任意のトレースをクリックします。3つのサービスすべてにまたがる完全な分散トレースと、各ホップのタイミングが表示されます。 +3. **フェーズ2と同じストーリー**: コード変更ゼロ。1つのフラグを付けた `helm upgrade` 1回だけです。 {{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/4-how-this-scales.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/4-how-this-scales.md index 4814c383c8..5a18d9ac8c 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/4-how-this-scales.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/4-how-this-scales.md @@ -1,32 +1,32 @@ --- -title: 4. スケーリングの仕組み +title: 4. How This Scales weight: 4 --- -## 環境間で共通するパターン +## 環境全体を通じたパターン -フェーズ0ではバイナリを実行しました。フェーズ2（Docker）では1つのコンテナを追加しました。フェーズ3（K8s）では `helm upgrade` を1回実行しました。パターンは同じです： +Phase 0 ではバイナリを実行しました。Phase 2（Docker）ではコンテナを1つ追加しました。Phase 3（K8s）では `helm upgrade` を1回実行しました。パターンは同じです | 環境 | OBI のデプロイ方法 | 変更点 | |---|---|---| -| ベアホスト | `sudo` でバイナリを実行 | なし -- OBI はカーネルからプロセスを監視します | -| Docker Compose | 1 つのコンテナ | `docker-compose.yaml` にサービスを追加 | -| Kubernetes | Helm chart フラグ | `--set="obi.enabled=true"` を指定して `helm upgrade` | +| ベアホスト | `sudo` でバイナリを実行 | なし：OBI はカーネルからプロセスを監視 | +| Docker Compose | コンテナを1つ追加 | `docker-compose.yaml` にサービスを追加 | +| Kubernetes | Helm chart フラグ | `--set="obi.enabled=true"` で `helm upgrade` | -[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/zero-code-ebpf-instrumentation.md) は、コレクターとOBIの両方を本番環境にデプロイするための方法です。さらに自動化を進めるには、[OpenTelemetry Operator](https://opentelemetry.io/docs/kubernetes/operator/) を使用して、アノテーションによりOBIをサイドカーとして自動的に注入できます。 +[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/zero-code-ebpf-instrumentation.md) は、コレクターと OBI の両方をデプロイする本番環境向けの方法です。さらに自動化するには、[OpenTelemetry Operator](https://opentelemetry.io/docs/kubernetes/operator/) を使用してアノテーションで OBI をサイドカーとして自動的に注入できます。 ## 価値提案（まとめ） -多くの組織には、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 を介して既に実行中のプロセスにアタッチ +- **言語非依存**: HTTP または gRPC を使用する Go、Node.js、Python、Java、Rust、C++ など何でも動作 +- **コンテナ1つまたは Helm フラグ1つ**: compose に追加するか、Helm chart で `obi.enabled=true` を有効にするだけで完了 diff --git a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/_index.md index 8829cc56a0..5e54ed1fe2 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/_index.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/_index.md @@ -3,10 +3,10 @@ title: "Phase 3: Kubernetes" linkTitle: 5. Kubernetes weight: 5 archetype: chapter -time: 25分 -description: 同じ3つのサービスをKubernetesにデプロイし、OBI DaemonSetを追加して、完全な分散トレーシングを取得します -- コード変更不要のまま、エンタープライズグレードのオーケストレーションを実現します。 +time: 25 minutes +description: Deploy the same three services to Kubernetes, add the OBI DaemonSet, and get full distributed tracing same zero-code story, enterprise-grade orchestration. --- -このフェーズでは、Phase 2とまったく同じ「素の」アプリケーションコードを使用し、[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart)を使ってKubernetesにデプロイします。 +このフェーズでは、Phase 2 とまったく同じ「素の」アプリケーションコードを使用し、[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart) を使って Kubernetes にデプロイします。 -コレクターはHelmでデプロイされ、OBIは単一のフラグ `obi.enabled=true` で有効化されます。これにより、OBI DaemonSetがデプロイされ、すべてのノード上のすべてのPodが計装されます。 +Collector は Helm を通じてデプロイされ、OBI は `obi.enabled=true` という単一のフラグで有効化されます。これにより、すべてのノードのすべての Pod を計装する OBI DaemonSet がデプロイされます。 diff --git a/content/ja/ninja-workshops/16-obi-ebpf/6-wrap-up/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/6-wrap-up/_index.md index b6385f959c..c20fade2ce 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/6-wrap-up/_index.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/6-wrap-up/_index.md @@ -4,18 +4,18 @@ linkTitle: 6. まとめ weight: 6 archetype: chapter time: 5 minutes -description: 重要なポイント、クリーンアップ手順、およびワークショップを拡張するためのアイデアです。 +description: 主要なポイント、クリーンアップ手順、およびワークショップを拡張するためのアイデアについて説明します。 --- -## 重要なポイント +## 主要なポイント -1. **OBI はカーネルから計装します。** SDKも、コード変更も、再コンパイルも不要です。eBPFプローブはネットワークレベルでHTTP/gRPCトラフィックを監視します。 +1. **OBI はカーネルから計装を行います。** SDK も、コード変更も、再コンパイルも不要です。eBPF プローブはネットワークレベルで HTTP/gRPC トラフィックを監視します。 -2. **コンテキスト伝播はネットワークレベルで行われます。** OBIは送信HTTPリクエストに `Traceparent` ヘッダーを注入し、サービス間でトレースを連携させます。これはサービスがトレースについて何も知らなくても機能します。 +2. **コンテキストの伝播はネットワークレベルで行われます。** OBI は送信 HTTP リクエストに `Traceparent` ヘッダーを注入し、サービスがトレースについて何も知らなくても、サービス間でトレースをリンクします。 -3. **デプロイパターンは一貫しています。** ベアメタル、Docker、Kubernetesのいずれであっても、アプローチは同じです。アプリケーションと一緒にOBIを実行し、コレクターに向けるだけです。 +3. **デプロイパターンは一貫しています。** ベアメタル、Docker、Kubernetes のいずれであっても、アプローチは同じです。アプリと一緒に OBI を実行し、コレクターに向けるだけです。 -4. **これは実際の企業の問題を解決します。** レガシーアプリ、コンパイル済みバイナリ、規制上の制約、開発者の抵抗 -- OBIは誰にもコードを変更させることなくオブザーバビリティを提供します。 +4. **これは実際のエンタープライズの問題を解決します。** レガシーアプリ、コンパイル済みバイナリ、規制上の制約、開発者の抵抗 - OBI はコードを変更することなくオブザーバビリティを提供します。 ## クリーンアップ @@ -42,33 +42,33 @@ kill %1 2>/dev/null ## ワークショップの拡張 -すべてのフェーズを完了したら、LLM（Cursor、Copilot、ChatGPTなど）を使用してワークショップを拡張するためのアイデアをご紹介します。 +すべてのフェーズを完了したら、LLM（Cursor、Copilot、ChatGPT など）を使用してワークショップを拡張するアイデアをいくつか紹介します。 ### 新しいエンドポイントの追加 -LLMに `order-processor` へ `GET /order-status/:id` エンドポイントを追加するよう依頼します。OBIは自動的にトレースします -- 設定変更は不要です（すでにポート8080を監視しています）。 +LLM に `order-processor` に `GET /order-status/:id` エンドポイントを追加するよう依頼してください。OBI は自動的にトレースします。設定の変更は不要です（すでにポート 8080 を監視しています）。 ### 新しいサービスの追加 -LLMにPython（Flask）でポート8082上に `inventory-service` を作成するよう依頼します。以下が必要です： +LLM にポート 8082 で Python（Flask）の `inventory-service` を作成するよう依頼してください。以下を行う必要があります -- サービスコードとDockerfileの作成 -- `docker-compose.yaml` への追加 -- `obi-config.yaml` へのポート8082の追加 +- サービスコードと Dockerfile を作成する +- `docker-compose.yaml` に追加する +- `obi-config.yaml` にポート 8082 を追加する ### エラーシナリオの追加 -LLMに `payment-service` を20% の確率でランダムに500ステータスで失敗させるよう依頼します。次に `order-processor` にリトライロジックを追加します。Splunk APMでエラー率が表示されるのを確認します。 +LLM に `payment-service` が 20% の確率でランダムに 500 ステータスで失敗するようにしてもらいます。その後、`order-processor` にリトライロジックを追加します。Splunk APM でエラー率が表示されるのを確認してください。 ### レイテンシシミュレーションの追加 -LLMに `payment-service` にランダムな100-500msのレイテンシを追加するよう依頼します。Splunk APMのサービスビューでレイテンシ分布が表示されるのを確認します。 +LLM に `payment-service` にランダムな 100-500ms のレイテンシを追加するよう依頼してください。Splunk APM のサービスビューでレイテンシ分布が表示されるのを確認してください。 -{{% notice title="注意" style="info" %}} -拡張する際の注意点： +{{% notice title="Note" style="info" %}} +拡張する際の注意点 -- OpenTelemetry SDKを追加**しないでください** -- ゼロコード計装がポイントです -- サービスはDockerネットワーク上に維持してください。サービス間呼び出しに `localhost` を使用しないでください +- OpenTelemetry SDK を追加**しないでください**：ゼロコード計装がポイントです +- サービスは Docker ネットワーク上に維持してください。サービス間呼び出しに `localhost` を使用しないでください - 新しいポートを追加する場合は `obi-config.yaml` を更新してください -- コード変更後は再ビルドしてください: `docker-compose up --build -d` +- コード変更後は再ビルドしてください`docker-compose up --build -d` {{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/_index.md index ef197e12fc..4b9e6acff7 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/_index.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/_index.md @@ -1,22 +1,23 @@ --- -draft: true -title: Zero-Code APM with OBI and eBPF -linkTitle: Zero-Code APM with OBI +draft: false +hidden: true +title: OBI と eBPF によるゼロコード APM +linkTitle: OBI によるゼロコード APM weight: 16 archetype: chapter time: 90 minutes authors: ["Jeremy Hicks"] -description: OpenTelemetry eBPF Instrumentation (OBI) がコードを一行も変更せずにアプリケーションに完全な分散トレーシングを追加し、Splunk Observability Cloud にテレメトリを送信する方法を実演するハンズオンワークショップです。 +description: OpenTelemetry eBPF Instrumentation（OBI）が、コードを一行も変更することなくアプリケーションに完全な分散トレーシングを追加し、Splunk Observability Cloud にテレメトリーを送信する方法を実践的に学ぶワークショップです。 --- -このワークショップでは、**OpenTelemetry eBPF Instrumentation (OBI)** の威力を体験します。これは、Linuxカーネルから直接サービスを計装するゼロコードのアプリケーションパフォーマンス監視アプローチです。 +このワークショップでは、**OpenTelemetry eBPF Instrumentation（OBI）** のパワーを体験します。これは、Linux カーネルから直接サービスを計装するゼロコードのアプリケーションパフォーマンスモニタリング手法です。 -以下の3つのフェーズを順番に進めていきます。各フェーズは前のフェーズの上に構築されています： +3つのフェーズを順に進めていきます。各フェーズは前のフェーズの上に構築されます -- **Phase 0 -- Python Warm-up**: ホスト上でシンプルなPythonアプリを実行します。OBIバイナリを使用してカーネルからAPMトレーシングを追加します -- SDKもコード変更も不要です。 -- **Phase 1 -- Docker (Before OBI)**: Docker Composeで3つのポリグロットマイクロサービス (Node.js + Go + Go) をデプロイします。APMが空であることを確認します。 -- **Phase 2 -- Docker (The Magic)**: OBIコンテナを1つ追加します。3つのサービスすべてで完全な分散トレースがSplunk APMに表示されます。コード変更はゼロです。 -- **Phase 3 -- Kubernetes**: Splunk OTel Collector Helm chartを使用して同じサービスをK8sにデプロイします。1つのフラグでOBIを有効にします。同じゼロコードトレーシングを、エンタープライズグレードのオーケストレーションで実現します。 +- **Phase 0 -- Python ウォームアップ**: ホスト上でシンプルな Python アプリを実行します。OBI バイナリを使用してカーネルから APM トレーシングを追加します。SDK もコード変更も不要です。 +- **Phase 1 -- Docker（OBI 導入前）**: Docker Compose で3つのポリグロットマイクロサービス（Node.js + Go + Go）をデプロイします。APM が空であることを確認します。 +- **Phase 2 -- Docker（マジック）**: OBI コンテナを1つ追加します。3つのサービスすべてで完全な分散トレースが Splunk APM に表示されます。コード変更はゼロです。 +- **Phase 3 -- Kubernetes**: 同じサービスを Splunk OTel Collector Helm チャートとともに K8s にデプロイします。1つのフラグで OBI を有効にします。同じゼロコードトレーシングで、エンタープライズグレードのオーケストレーションが実現します。 ```text Phase 0: Python (:5150) ──── instrumented by OBI binary on host @@ -32,8 +33,8 @@ Phase 3: Same services on Kubernetes + Splunk OTel Collector Helm chart + obi.e ``` {{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップ内の移動には以下の方法が便利です： +このワークショップを進める最も簡単な方法は以下を使用することです -- このページの右上にある左右の矢印 (**<** | **>**) +- このページの右上にある左右の矢印（**<** | **>**） - キーボードの左右カーソルキー {{% /notice %}} diff --git a/content/ja/ninja-workshops/17-appd-ingest/1-overview/_index.md b/content/ja/ninja-workshops/17-appd-ingest/1-overview/_index.md index 99293864b7..c11ca9bfca 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/1-overview/_index.md +++ b/content/ja/ninja-workshops/17-appd-ingest/1-overview/_index.md @@ -4,38 +4,38 @@ linkTitle: 1. Overview weight: 1 archetype: chapter time: 5 minutes -description: ユースケース、アーキテクチャ、前提条件、およびハイブリッドモードとデュアルシグナルモードの違いについて説明します。 +description: ユースケース、アーキテクチャ、前提条件、および hybrid mode と dual signal mode の違いについて説明します。 --- ## ユースケース -あなたの組織では現在、APMとしてAppDynamicsを使用しています。データの可視性とガバナンスの取り組みの一環として、経営陣はアプリケーションパフォーマンスデータを **Splunk Observability Cloud** にも送信することを望んでいます。これにより、チームはすでにSplunkにあるインフラストラクチャメトリクス、ログ、その他のシグナルと合わせて統一されたビューを得ることができます。 +あなたの組織では現在、APM として AppDynamics を運用しています。データの可視化とガバナンスの取り組みの一環として、経営層はアプリケーションパフォーマンスデータを **Splunk Observability Cloud** にも送信し、すでに Splunk に取り込まれているインフラストラクチャメトリクス、ログ、その他のシグナルと統合されたビューをチームに提供したいと考えています。 -すべてのサービスを別のOpenTelemetry SDKで再計装する代わりに、AppDynamics Java Agentは **デュアルシグナルモード** をサポートしています。単一のエージェントがAppDynamics APMデータとOpenTelemetryトレースの両方を同時に生成します。これにより、OpenTelemetry Collectorを通じて同じテレメトリをSplunk Observability Cloudにストリーミングしながら、AppDynamicsの完全な機能を維持できます。 +すべてのサービスを個別の OpenTelemetry SDK で再計装するのではなく、AppDynamics Java Agent は **dual signal mode** をサポートしています。これにより、単一のエージェントが AppDynamics APM データと OpenTelemetry トレースの両方を同時に生成できます。これにより、AppDynamics の完全な機能を維持しながら、OpenTelemetry Collector を通じて同じテレメトリを Splunk Observability Cloud にストリーミングできます。 -これは、現在AppDynamicsを熟知し依存しているL1およびL2チームにとって特に有用です。デュアルインジェストは、担当するアプリケーションやサービスがクラウドのSaaSプラットフォームでホストされる新しいサービスとより密接に接続されるようになっても、コンテキストを維持するのに役立ちます。 +これは、現在 AppDynamics を熟知し依存している L1 および L2 チームにとって特に有用です。Dual ingest は、彼らが担当するアプリケーションやサービスがクラウドの SaaS プラットフォームでホストされる新しいサービスとより密接に接続されるようになっても、コンテキストを維持するのに役立ちます。 ## 学習内容 -このワークショップを完了すると、以下のことができるようになります： +このワークショップを完了すると、以下のことができるようになります -- AppDynamics Java Agentを使用してシンプルなJavaサービスをビルドおよび実行する -- **ハイブリッドモード** と **デュアルシグナルモード** の違いを理解する -- デュアルシグナルモードを有効にしてAPMデータをAppDynamicsとSplunk Observability Cloudの両方に送信する +- AppDynamics Java Agent を使用してシンプルな Java サービスをビルドして実行する +- **hybrid mode** と **dual signal mode** の違いを理解する +- dual signal mode を有効にして、APM データを AppDynamics と Splunk Observability Cloud の両方に送信する - 両方のプラットフォームでトレースとメトリクスを確認する -- Splunk Observability Cloudで **グローバルデータリンク** を作成し、ワンクリックでAppDynamicsに移動できるようにする +- Splunk Observability Cloud で AppDynamics へのワンクリックナビゲーションのための **global data link** を作成する ## アーキテクチャ -このワークショップでは、Spring Boot JavaアプリケーションをEC2インスタンス上で直接実行します。AppDynamics Java AgentはJVMプロセスにアタッチされます。 +このワークショップでは、Spring Boot Java アプリケーションを EC2 インスタンス上で直接実行します。AppDynamics Java Agent は JVM プロセスにアタッチされます。 -**フェーズ1 -- 通常のAppD計装：** +**Phase 1: 通常の AppD 計装:** ```text Java App + AppD Agent ──▶ AppD Controller ``` -**フェーズ2 -- デュアルシグナルモード有効化：** +**Phase 2: Dual signal mode 有効化:** ```text Java App + AppD Agent ──▶ AppD Controller (AppD protocol, unchanged) @@ -45,62 +45,61 @@ Java App + AppD Agent ──▶ AppD Controller (AppD protocol, unchang Splunk Observability Cloud ``` -OpenTelemetry Collectorは同じEC2インスタンス上で実行され、エージェントからOTLPを受信し、トレースとメトリクスをSplunk Observability Cloudにエクスポートします。 +OpenTelemetry Collector は同じ EC2 インスタンス上で実行され、エージェントから OTLP を受信し、トレースとメトリクスを Splunk Observability Cloud にエクスポートします。 -**注意：** コレクターなしでエージェントから直接[OTLPインジェストエンドポイント](https://dev.splunk.com/observability/docs/datamodel/ingest/#Send-data-points)にデータを送信することも可能ですが、OTel設定で設定した一部の属性や関連付けが失われる可能性があります。 +**注意:** Collector を使用せずにエージェントから直接 [OTLP ingest endpoint](https://dev.splunk.com/observability/docs/datamodel/ingest/#Send-data-points) にデータを送信することも可能ですが、OTel 設定で一部の属性や関連付けが失われる可能性があります。 -## ハイブリッドモード vs デュアルシグナルモード +## Hybrid Mode vs Dual Signal Mode -AppDynamics Java AgentはOpenTelemetryデータを出力するための2つのモードをサポートしています。 +AppDynamics Java Agent は、OpenTelemetry データを出力するための2つのモードをサポートしています。 この違いを理解することは重要です！ -### ハイブリッドモード（GA、Java Agent 22.3以降） +### Hybrid Mode - 旧式 (GA, Java Agent 22.3+) -- AppDynamicsの **独自の計装ルール** がOTel形式のスパンを生成します -- エージェントは既存の計装を再利用してOTelデータを生成します（古いセマンティックバージョン） -- **オーバーヘッドが低い**（CPUとメモリ） -- フレームワークのカバレッジはAppDynamicsが計装するものに限定されます +- AppDynamics の**独自の計装ルール**が OTel 形式のスパンを生成します +- エージェントは既存の計装を再利用して OTel データを生成します（古いセマンティックバージョン） +- フレームワークのカバレッジは AppDynamics が計装するものに限定されます - 有効化方法: `-Dagent.deployment.mode=hybrid` -### デュアルシグナルモード（ベータ、Java Agent 25.6以降） +### Dual Signal Mode - 最新式 (Beta, Java Agent 25.6+) -- 完全な[OpenTelemetry Java自動計装](https://github.com/open-telemetry/opentelemetry-java-instrumentation/)がAppDエージェントと **並行して** 実行されます +- 完全な [OpenTelemetry Java auto-instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/) が AppD agent と**並行して**実行されます - 2つの独立した計装エンジンが並列で動作します -- **フレームワークカバレッジが広い** -- OTel Javaエージェントがサポートするすべてのフレームワークに対応 -- CPUとメモリの消費量が高くなります +- **より広範なフレームワークカバレッジ** - OTel Java agent がサポートするすべてのものに対応 +- より高い CPU とメモリ消費 - 有効化方法: `-Dagent.deployment.mode=dual` または環境変数 `AGENT_DEPLOYMENT_MODE=dual` -### このワークショップでデュアルモードを使用する理由 +### このワークショップで Dual Mode を使用する理由 -デュアルシグナルモードは、ハイブリッドモードにはない **相関属性** をルートスパンに追加します： +Dual signal mode は、hybrid mode にはない**相関属性**をルートスパンに追加します | 属性 | 説明 | |---|---| -| `appd.app.name` | AppDynamicsアプリケーション名 | -| `appd.tier.name` | AppDynamicsティア名（ティアが変更されるとトレースの途中にも表示されます） | -| `appd.bt.name` | AppDynamicsビジネストランザクション名 | -| `appd.request.guid` | AppDynamicsリクエストGUID | +| `appd.app.name` | AppDynamics アプリケーション名 | +| `appd.tier.name` | AppDynamics tier 名（tier が変更されるとトレースの途中にも表示されます） | +| `appd.bt.name` | AppDynamics ビジネストランザクション名 | +| `appd.request.guid` | AppDynamics リクエスト GUID | -これらの属性により、**グローバルデータリンク**（Splunk Observability Cloudのトレース上のクリック可能なリンクで、対応するAppDynamicsビューに直接移動できます）が有効になります。さらに、デュアルモードでキャプチャされたAppDynamicsスナップショットには、Data CollectorsタブにOTelの `TraceId` が含まれるため、双方向のナビゲーションが可能になります。 +これらの属性により、**global data links** が有効になります。これは Splunk Observability Cloud のトレース上のクリック可能なリンクで、対応する AppDynamics ビューに直接ナビゲートできます。さらに、dual mode でキャプチャされた AppDynamics スナップショットには、Data Collectors タブに OTel `TraceId` が含まれ、双方向のナビゲーションが可能になります。 ## 前提条件 -ワークショップインスタンスには必要なツールが事前に設定されています： +ワークショップインスタンスには必要なツールが事前設定されています | 要件 | ワークショップインスタンスでの状態 | |---|---| -| Linuxホスト（Ubuntu） | 提供済み | +| Linux ホスト (Ubuntu) | 提供済み | | OpenJDK 17 | インストール済み | | Maven | インストール済み | -| ワークショップアセット | `~/workshop/appd/` に事前デプロイ済み | +| ワークショップアセット | `~/workshop/appd/` にデプロイ済み | -以下も必要です： +以下も必要です -| 要件 | 取得方法 | +| 要件 | 入手方法 | |---|---| | Splunk Observability Cloud アカウント | インストラクターから提供されます | -| **Splunk Access Token**（Ingest） | インスタンスで `echo $ACCESS_TOKEN` を実行 | -| **Splunk Realm**（例：`us0`、`us1`、`eu0`） | インスタンスで `echo $REALM` を実行 | -| **インスタンス名** | インスタンスで `echo $INSTANCE` を実行 | -| AppDynamics Controllerアクセス | [SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) -- Ciscoの認証情報でログイン | +| **Splunk Access Token** (Ingest) | インスタンスで `echo $ACCESS_TOKEN` を実行 | +| **Splunk Realm** (例: `us0`, `us1`, `eu0`) | インスタンスで `echo $REALM` を実行 | +| **Instance name** | インスタンスで `echo $INSTANCE` を実行 | +| AppDynamics Controller アクセス | [SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco 認証情報でログイン | diff --git a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/3-run-and-verify.md b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/3-run-and-verify.md index 3f866d49e3..1dd653d06f 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/3-run-and-verify.md +++ b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/3-run-and-verify.md @@ -1,16 +1,24 @@ --- -title: 3. AppD で実行して確認する +title: 3. AppD での実行と確認 weight: 3 --- -AppDynamicsエージェントをアタッチしてアプリケーションを実行します。これは「通常の」単一送信先へのインストルメンテーションです。 +AppDynamics エージェントをアタッチしてアプリケーションを実行します。これは「通常の」単一送信先へのインストルメンテーションです。 ## AppDynamics エージェントで実行する -前のステップで取得した値で `` と `` を置き換えてください： +`` と `<>` を前のステップで取得した値に置き換えてください {{< tabs >}} {{% tab title="Command" %}} +環境変数をエクスポートします + +```bash +export APPD_ACCESS_KEY= +export APPD_APP_NAME=Dual-Ingest- +``` + +次に、エージェントを指定して java を起動します ```bash cd ~/workshop/appd @@ -19,12 +27,12 @@ java -javaagent:agent/javaagent.jar \ -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com \ -Dappdynamics.controller.port=443 \ -Dappdynamics.controller.ssl.enabled=true \ - -Dappdynamics.agent.applicationName=Dual-Ingest- \ + -Dappdynamics.agent.applicationName=${APPD_APP_NAME} \ -Dappdynamics.agent.tierName=OrderService \ -Dappdynamics.agent.nodeName=OrderService-Node \ -Dappdynamics.agent.accountName=se-lab \ - -Dappdynamics.agent.accountAccessKey= \ - -jar app/target/ingest-workshop-1.0.0.jar & + -Dappdynamics.agent.accountAccessKey=${APPD_ACCESS_KEY} \ + -jar app/target/ingest-workshop-1.0.0.jar & ``` {{% /tab %}} @@ -46,11 +54,11 @@ java -javaagent:agent/javaagent.jar \ {{% /tab %}} {{< /tabs >}} -Spring Bootの起動バナーが表示されるまで待ちます（約10〜15秒）。 +Spring Boot の起動バナーが表示されるまで待ちます（約10〜15秒）。 ## 負荷を生成する -シンプルな負荷生成器をバックグラウンドで起動します： +シンプルな負荷生成ツールをバックグラウンドで起動します ```bash while true; do @@ -63,22 +71,22 @@ done & ## AppDynamics Controller で確認する 1. [AppDynamics Controller](https://se-lab.saas.appdynamics.com/controller/) を開きます -2. **Applications** に移動し、ご自身のアプリケーションを見つけます（例：`Dual-Ingest-YOURINITIALS`） +2. **Applications** に移動し、自分のアプリケーションを見つけます（例`Dual-Ingest-YOURINITIALS`） 3. アプリケーションをクリックして **Flow Map** を表示します {{% notice title="お待ちください" style="info" icon="info-circle" %}} アプリケーションが登録され、ビジネストランザクションがフローマップに表示されるまで2〜5分かかる場合があります。必要に応じてページを更新してください。 {{% /notice %}} -以下が表示されるはずです： +以下が表示されるはずです -- フローマップ内の **OrderService** ティア +- フローマップに **OrderService** ティアが表示される - `/order` と `/inventory` エンドポイントのビジネストランザクション -- コントローラーに流れるメトリクスデータ +- コントローラーに流入するメトリクスデータ -この時点では、データは **AppDynamics にのみ**送信されています。アプリケーションはSplunk Observability Cloudには接続されていません。次のフェーズでは、デュアルシグナルモードを有効にしてこれを変更します。 +この時点では、データは **AppDynamics にのみ** 送信されています。アプリケーションは Splunk Observability Cloud には接続されていません。次のフェーズでは、デュアルシグナルモードを有効にしてこれを変更します。 ![AppDynamics Application](../../_images/appd-service.png?width=30vw) {{% notice title="実行したままにしてください" style="warning" icon="exclamation-triangle" %}} -アプリケーションと負荷生成器は実行したままにしておいてください。次のセクションでデュアルモードフラグを追加するために停止します。 +アプリケーションと負荷生成ツールは実行したままにしてください。次のセクションでデュアルモードのフラグを追加するために停止します。 {{% /notice %}} diff --git a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md index aa7c5628b6..ac48b521de 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md +++ b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md @@ -1,13 +1,13 @@ --- -title: 2. デュアルモードの有効化 +title: 2. Dual Mode の有効化 weight: 2 --- -JVMコマンドラインにデュアルシグナルモードのフラグを追加して、アプリケーションを再起動します。 +JVM コマンドラインに dual signal mode フラグを追加してアプリケーションを再起動します。 ## 実行中のアプリケーションを停止する -Phase 1で起動したアプリケーションとロードジェネレーターを停止します： +Phase 1 のアプリケーションとロードジェネレーターを停止します: ```bash kill %2 2>/dev/null # stop load generator @@ -15,14 +15,14 @@ kill %1 2>/dev/null # stop the java app ``` {{% notice title="Tip" style="primary" icon="lightbulb" %}} -`kill %1` が動作しない場合は、`ps aux | grep ingest-workshop` でPIDを確認して直接killしてください。 +`kill %1` が動作しない場合は、`ps aux | grep ingest-workshop` で PID を確認し、直接 kill してください。 {{% /notice %}} -## デュアルモードで再起動する +## Dual Mode で再起動する -同じAppDフラグに加えて、デュアルモードとOTelエクスポーターのフラグを追加してアプリケーションを再度実行します。`` と `` はPhase 1で使用したものと同じ値に置き換えてください： +同じ AppD フラグに加えて、dual mode と OTel exporter フラグを付けてアプリケーションを再度実行します。Phase 1 で設定した `${APPD_ACCESS_KEY}` と `${APPD_APP_NAME}` の変数を同じ値で使用します: -アプリケーションを起動する `-jar app/target/ingest-workshop-1.0.0.jar &` の直前に4行追加します。 +アプリケーションを起動する `-jar app/target/ingest-workshop-1.0.0.jar &` の直前に4行追加します ```bash cd ~/workshop/appd @@ -31,11 +31,11 @@ java -javaagent:agent/javaagent.jar \ -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com \ -Dappdynamics.controller.port=443 \ -Dappdynamics.controller.ssl.enabled=true \ - -Dappdynamics.agent.applicationName=Dual-Ingest- \ + -Dappdynamics.agent.applicationName=${APPD_APP_NAME} \ -Dappdynamics.agent.tierName=OrderService \ -Dappdynamics.agent.nodeName=OrderService-Node \ -Dappdynamics.agent.accountName=se-lab \ - -Dappdynamics.agent.accountAccessKey= \ + -Dappdynamics.agent.accountAccessKey=${APPD_ACCESS_KEY} \ -Dagent.deployment.mode=dual \ -Dotel.traces.exporter=otlp \ -Dotel.exporter.otlp.endpoint=http://localhost:4318 \ @@ -43,16 +43,16 @@ java -javaagent:agent/javaagent.jar \ -jar app/target/ingest-workshop-1.0.0.jar & ``` -Spring Bootの起動バナーが表示されるまで待ちます。 +Spring Boot のスタートアップバナーが表示されるまで待ちます。 ### 新しいフラグの説明 | フラグ | 目的 | |---|---| -| `-Dagent.deployment.mode=dual` | デュアルシグナルモードを有効にします -- OTel Java 自動計装が AppD エージェントと並行して動作します | +| `-Dagent.deployment.mode=dual` | dual signal mode を有効にし、完全な OTel Java 自動計装が AppD エージェントと並行して実行されます | | `-Dotel.traces.exporter=otlp` | OTel 計装に OTLP 経由でスパンをエクスポートするよう指示します | -| `-Dotel.exporter.otlp.endpoint` | ポート 4318（HTTP/protobuf）のローカル OTel Collector を指定します | -| `-Dotel.resource.attributes` | OTel リソース属性を設定します：`service.name` は AppD の tier に、`service.namespace` は AppD の application に、`deployment.environment` はワークショップインスタンスのデータにタグ付けされます | +| `-Dotel.exporter.otlp.endpoint` | ポート 4318 (HTTP/protobuf) のローカル OTel Collector を指定します | +| `-Dotel.resource.attributes` | OTel リソース属性を設定します: `service.name` は AppD の tier に、`service.namespace` は AppD の application に、`deployment.environment` はワークショップインスタンスのデータにタグ付けされます | ## ロードジェネレーターを再起動する @@ -64,9 +64,9 @@ while true; do done & ``` -## デュアルモードが有効であることを確認する +## Dual Mode がアクティブであることを確認する -アプリケーションログを確認して、デュアルモードが開始されたことを確認します： +アプリケーションログで dual mode が開始されたことを確認します: {{< tabs >}} {{% tab title="Command" %}} @@ -86,10 +86,10 @@ splunk 181598 172 2.1 14402900 717736 pts/0 SNl 21:31 1:02 java -javaage {{% /tab %}} {{< /tabs >}} -`deployment.mode=dual` フラグが設定されたjavaプロセスが表示されるはずです。 +`deployment.mode=dual` フラグが付いた java プロセスが表示されるはずです。 -AppDynamicsエージェントは現在、以下のデータを送信しています： +AppDynamics エージェントは現在、以下を送信しています: -- **AppD APM データ** をAppDynamics Controllerへ（変更なし） -- **OTLP トレース** を `localhost:4318` のローカルOTel Collectorへ送信し、そこからSplunk Observability Cloudに転送されます +- **AppD APM データ** を AppDynamics Controller へ（変更なし） +- **OTLP トレース** を `localhost:4318` のローカル OTel Collector へ、そこから Splunk Observability Cloud に転送されます - インスタンスで `env` を使用して、環境 `deployment.environment=${INSTANCE}-appd-dual` に使用される `{INSTANCE}` の値を確認できます diff --git a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md index 634f4774c8..a5acad4347 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md +++ b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md @@ -1,29 +1,29 @@ --- -title: 3. 両方のプラットフォームで確認 +title: 3. 両方のプラットフォームで確認する weight: 3 --- -デュアルモードを有効にして負荷を流している状態で、数分以内にトレースがSplunk Observability Cloudに到着するはずです。両方の送信先を確認しましょう。 +デュアルモードが有効になり、負荷がかかっている状態では、数分以内に Splunk Observability Cloud にトレースが届くはずです。両方の送信先を確認しましょう。 ## AppDynamics の確認（変更なし） -[AppDynamics Controller](https://se-lab.saas.appdynamics.com/controller/) に戻り、アプリケーションを開いて以下を確認します： +[AppDynamics Controller](https://se-lab.saas.appdynamics.com/controller/) に戻り、アプリケーションを開いて以下を確認します -- **OrderService** ティアがフローマップに引き続き表示されている -- `/order` と `/inventory` のビジネストランザクションが引き続き記録されている -- デュアルモードの追加によるエラーやパフォーマンス低下がない +- **OrderService** ティアがフローマップに表示されていること +- `/order` と `/inventory` のビジネストランザクションが記録され続けていること +- デュアルモードを追加してもエラーや劣化がないこと -デュアルモードはAppDynamicsのデータ収集に影響を与えないはずです。両方のストリームは独立して動作します。 +デュアルモードは AppDynamics のデータ収集に影響を与えないはずです。両方のストリームは独立して動作します。 ## Splunk Observability Cloud の確認 -1. [Splunk Observability Cloud](https://app.signalfx.com) に移動し、インストラクターから提供された認証情報でログインします。 +1. [Splunk Observability Cloud](https://app.signalfx.com) にアクセスし、インストラクターから提供された認証情報でログインします。 2. 左側のナビゲーションパネルで **APM** をクリックします。 3. **Environment** ドロップダウンで `-appd-dual` を選択します（これはリソース属性で設定した `deployment.environment` の値と一致します）。 ![AppDynamics Application](../../_images/o11y-service.png?width=30vw) {{% notice title="数分お待ちください" style="info" icon="info-circle" %}} -デュアルモードを有効にしてからトレースが表示されるまで2〜5分かかることがあります。サービスがまだ表示されない場合は、少し待ってからページを更新してください。 +デュアルモードを有効にしてからトレースが表示されるまで 2〜5 分かかることがあります。サービスがまだ表示されない場合は、しばらく待ってからページを更新してください。 {{% /notice %}} 4. サービスリストに **OrderService** が表示されるはずです。 @@ -32,26 +32,26 @@ weight: 3 1. **OrderService** サービスをクリックします。 2. **Traces** をクリックして個々のトレースを表示します。 -3. `GET /order` のトレースを選択してトレース詳細のウォーターフォールを開きます。 +3. `GET /order` のトレースを選択して、トレース詳細のウォーターフォールを開きます。 -トレースウォーターフォールでは、OTel Java自動計装によって生成されたスパンが表示されます。これらはAppDynamicsも監視している同じリクエストです。 +トレースウォーターフォールには、OTel Java 自動計装によって生成されたスパンが表示されます。これらは AppDynamics も監視しているのと同じリクエストです。 ![APM waterall](../../_images/waterfall.png) -## AppDynamics 相関属性の確認 +## AppDynamics 相関属性を確認する -**ルートスパン**をクリックしてスパン属性を確認します。AppDynamicsの相関属性が表示されるはずです： +**ルートスパン** をクリックしてスパン属性を確認します。AppDynamics の相関属性が表示されるはずです -| Attribute | Example Value | +| 属性 | 値の例 | |---|---| | `appd.app.name` | `Dual-Ingest-YOURINITIALS` | | `appd.tier.name` | `OrderService` | -| `appd.bt.name` | `/order` or `/inventory` | -| `appd.request.guid` | *(the AppDynamics request GUID)* | +| `appd.bt.name` | `/order` または `/inventory` | +| `appd.request.guid` | *（AppDynamics リクエスト GUID）* | -これらの属性はデュアルモードのAppDynamicsエージェントによって自動的に追加されます。このOTelトレースとAppDynamics Controllerの対応するデータとの直接的なリンクを作成します。 +これらの属性は、デュアルモードの AppDynamics エージェントによって自動的に追加されます。この OTel トレースと AppDynamics Controller 内の対応するデータとの間に直接リンクを作成します。 {{% notice title="重要なポイント" style="primary" icon="lightbulb" %}} -`appd.tier.name` 属性は、ティアが変更されるたびにトレースの途中のスパンにも表示されます。マルチティアアプリケーションでは、各スパンが正しいAppDynamicsティアのIDを保持します。 +`appd.tier.name` 属性は、ティアが変わるたびにトレースの途中のスパンにも表示されます。マルチティアアプリケーションでは、各スパンが正しい AppDynamics ティアアイデンティティを持ちます。 {{% /notice %}} -これで、同じアプリケーションが単一のエージェントから **2 つのプラットフォームに同時に** APMデータを送信するようになりました。次のセクションでは、グローバルデータリンクを作成して2つを接続します。 +これで、同じアプリケーションが単一のエージェントから **2 つのプラットフォームに同時に** APM データを送信するようになりました。次のセクションでは、グローバルデータリンクを作成して両者を接続します。 diff --git a/content/ja/ninja-workshops/17-appd-ingest/4-global-data-links/_index.md b/content/ja/ninja-workshops/17-appd-ingest/4-global-data-links/_index.md index d41f4c52a8..eb15ea9cb2 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/4-global-data-links/_index.md +++ b/content/ja/ninja-workshops/17-appd-ingest/4-global-data-links/_index.md @@ -1,71 +1,71 @@ --- -title: "フェーズ 3: グローバルデータリンク" -linkTitle: 4. グローバルデータリンク +title: "フェーズ 3: Global Data Links" +linkTitle: 4. Global Data Links weight: 4 archetype: chapter time: 10 minutes -description: appd.* スパン属性を使用して、対応する AppDynamics ティアビューに直接ナビゲートするグローバルデータリンクを Splunk Observability Cloud で作成します。 +description: appd.* スパン属性を使用して、対応する AppDynamics ティアビューに直接移動する Global Data Link を Splunk Observability Cloud で作成します。 --- -トレースの `appd.*` 属性は単なるメタデータではありません。これらを使用して**グローバルデータリンク**を作成することで、Splunk Observability Cloudでトレースを表示しているユーザーが、ワンクリックで対応するAppDynamicsビューに直接ジャンプできるようになります。 +トレースの `appd.*` 属性は単なるメタデータではありません。**Global Data Links** を活用することで、Splunk Observability Cloud でトレースを閲覧している誰もが、ワンクリックで対応する AppDynamics ビューに直接ジャンプできるようになります。 -## グローバルデータリンクとは？ +## Global Data Links とは -グローバルデータリンクは、スパン属性、タグ値、またはメトリクスディメンションにクリック可能なリンクを作成するSplunk Observability Cloudの機能です。ユーザーがリンクされた値をクリックすると、定義した外部URLに移動します。その際、実際の属性値がURLテンプレートに代入されます。 +Global Data Links は、スパン属性、タグ値、またはメトリクスディメンションにクリック可能なリンクを作成する Splunk Observability Cloud の機能です。ユーザーがリンクされた値をクリックすると、実際の属性値が URL テンプレートに代入された、定義済みの外部 URL に移動します。 -### データリンクの前提条件 +### Data Link の前提条件 -AppDynamicsでアプリケーションのURLをコピーしてください。アプリケーションを識別するURLの重要な部分は、URLのクエリパラメータです（例：`&application=99999`）。 -アプリケーションクエリパラメータを含む完全なURLを使用して、グローバルデータリンクを構築します。 +AppDynamics のアプリケーションへの URL をコピーします。アプリケーションを識別する URL の重要な部分は、URL 上のクエリパラメータです（例`&application=99999`）。 +アプリケーションのクエリパラメータを含む完全な URL を使用して、Global Data Link を構築します。 ![AppD Application ID](../_images/app-url.png) -## グローバルデータリンクの作成 +## Global Data Link の作成 -1. Splunk Observability Cloudで、左側のナビゲーションパネルにある **Settings**（歯車アイコン）をクリックします。 +1. Splunk Observability Cloud で、左側のナビゲーションパネルの **Settings**（歯車アイコン）をクリックします。 2. **Global Data Links** をクリックします。 3. **New Link** をクリックします。 -4. リンクを設定します： +4. リンクを設定します | フィールド | 値 | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Link Label** | `Open in AppDynamics` | | **Link to** | `Custom URL` | -| **Show on** | `Property:Value pair` - `appd.app.name:` を選択（例：`appd.app.name:Dual-Ingest-JRH`） | +| **Show on** | `Property:Value pair` - `appd.app.name:` を選択（例`appd.app.name:Dual-Ingest-JRH`） | | **URL** | `https://se-lab.saas.appdynamics.com/controller/#/location=APP_DASHBOARD&timeRange=Custom_Time_Range.BETWEEN_TIMES.{{ end_time }}.{{ start_time }}.6&application=&dashboardMode=force` | | **Time format** | `Unix time: epoch milliseconds` | | **Minimum trigger** | `appd.tier.name` | -{{% notice title="URLテンプレート構文" style="primary" icon="lightbulb" %}} -二重波括弧 `{{ end_time }}` と `{{ start_time }}` はテンプレート変数です。Splunk Observability Cloudは、クリック時に実際の値に置換します。 +{{% notice title="URL テンプレート構文" style="primary" icon="lightbulb" %}} +二重中括弧 `{{ end_time }}` と `{{ start_time }}` はテンプレート変数です。Splunk Observability Cloud はクリック時に実際の値に置換します。 -`` は、特定のアプリケーションのクエリパラメータに含まれる番号です。 +`` は、特定のアプリケーションのクエリパラメータからの番号です。 {{% /notice %}} ![Global Datalink Config](../_images/global-datalink-config.png?width=50vw) 5. **Save** をクリックします。 -## グローバルデータリンクのテスト +## Global Data Link のテスト 1. **APM** に戻り、**OrderService** サービスのトレースを開きます。 -2. ルートスパンをクリックして、その属性を表示します。 -3. 属性リストで `appd.app.name` を見つけます。これは **Open in AppDynamics** というラベルのクリック可能なリンクになっているはずです。 -4. リンクをクリックします。新しいブラウザタブが開き、AppDynamics Controllerの **OrderService** アプリケーションビューに直接移動します。 +2. ルートスパンをクリックして属性を表示します。 +3. 属性リストで `appd.app.name` を見つけます。**Open in AppDynamics** というラベルのクリック可能なリンクになっているはずです。 +4. リンクをクリックします。新しいブラウザタブが開き、AppDynamics Controller の **OrderService** アプリケーションビューに直接移動します。 ![Global Datalink Config](../_images/datalink.png?width=20vw) {{% notice title="注意" style="info" icon="info-circle" %}} -リンクが機能するには、同じブラウザでAppDynamics Controllerにログインしている必要があります。ログインを求められた場合は、Ciscoの認証情報を使用してください。 +リンクが機能するには、同じブラウザで AppDynamics Controller にログインしている必要があります。ログインを求められた場合は、Cisco の認証情報を使用してください。 {{% /notice %}} ## 逆方向へのナビゲーション（AppD から Splunk へ） -逆方向へのナビゲーションも可能です。デュアルモードでキャプチャされたAppDynamicsスナップショットには、**Data Collectors** タブの下にOTelの `TraceId` が含まれています。 +逆方向へのナビゲーションも可能です。デュアルモードでキャプチャされた AppDynamics スナップショットには、**Data Collectors** タブの下に OTel `TraceId` が含まれています。 -Splunk Observability Cloudで対応するトレースを見つけるには： +Splunk Observability Cloud で対応するトレースを見つけるには -1. AppDynamics Controllerで、ビジネストランザクションの **Transaction Snapshot** を開きます。 +1. AppDynamics Controller で、ビジネストランザクションの **Transaction Snapshot** を開きます。 2. **Data Collectors** タブに移動します。 3. `TraceId` の値を見つけます。 -4. Splunk Observability Cloudで、**APM → Traces** に移動し、そのトレースIDを検索します。 +4. Splunk Observability Cloud で、**APM → Traces** に移動し、そのトレース ID を検索します。 -これにより、2つのプラットフォーム間で**双方向の関連付け**が可能になります。 +これにより、2 つのプラットフォーム間の**双方向の関連付け**が可能になります。 ![AppDynamics Trace ID](../_images/appd-traceid.png?width=30vw) diff --git a/content/ja/ninja-workshops/17-appd-ingest/5-wrap-up/_index.md b/content/ja/ninja-workshops/17-appd-ingest/5-wrap-up/_index.md index 141e2cc483..86a8775871 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/5-wrap-up/_index.md +++ b/content/ja/ninja-workshops/17-appd-ingest/5-wrap-up/_index.md @@ -4,31 +4,31 @@ linkTitle: 5. まとめ weight: 5 archetype: chapter time: 5 minutes -description: まとめ、クリーンアップ、次のステップ +description: まとめ、クリーンアップ、次のステップ。 --- ## 達成したこと -このワークショップでは、以下のことを行いました： +このワークショップでは、以下のことを行いました -1. **通常の AppDynamics 計装で Java サービスをビルドして実行しました**：APMデータをAppDynamics Controllerのみに送信する単一のエージェントを使用しました。 +1. **通常の AppDynamics 計装で Java サービスをビルドして実行しました**：単一のエージェントが APM データを AppDynamics Controller にのみ送信します。 -2. **ハイブリッドモードとデュアルシグナルモードの違いを学びました**：ハイブリッドモードはAppD独自の計装を再利用してOTelスパンを生成し（低オーバーヘッド、狭いカバレッジ）、デュアルモードはAppDと並行して完全なOTel Java自動計装を実行します（広いカバレッジ、相関属性を追加）。 +2. **ハイブリッドモードとデュアルシグナルモードの違いを学びました**：ハイブリッドは AppD 独自の計装を再利用して OTel スパンを生成します（オーバーヘッドが低く、カバレッジが狭い）。一方、デュアルは AppD と並行して完全な OTel Java 自動計装を実行します（カバレッジが広く、相関属性を追加）。 -3. **デュアルシグナルモードを有効にしました**：同じプロセスに4つのJVMフラグを追加することで有効にしました。コード変更なし、2つ目のエージェントなし、再コンパイルなし。同じAppDynamicsエージェントがAppDynamicsとSplunk Observability Cloudの両方に同時にデータを送信するようになりました。 +3. **デュアルシグナルモードを有効化しました**：同じプロセスに 4 つの JVM フラグを追加することで実現しました。コード変更なし、追加エージェントなし、再コンパイルなし。同じ AppDynamics エージェントが AppDynamics と Splunk Observability Cloud の両方に同時にデータを送信するようになりました。 -4. **グローバルデータリンクを作成しました**：Splunk Observability Cloudで `appd.*` スパン属性を使用して、対応するAppDynamicsティアビューに直接ナビゲートできるようにしました。 +4. **グローバルデータリンクを作成しました**：Splunk Observability Cloud で `appd.*` スパン属性を使用して、対応する AppDynamics tier ビューに直接ナビゲートします。 ## クリーンアップ -アプリケーションと負荷生成ツールを停止します： +アプリケーションとロードジェネレーターを停止します ```bash kill %2 2>/dev/null # load generator kill %1 2>/dev/null # java app ``` -オプションでCollectorを停止します： +オプションで Collector を停止します ```bash sudo systemctl stop splunk-otel-collector @@ -36,17 +36,17 @@ sudo systemctl stop splunk-otel-collector ## 重要なポイント -- **デュアルモードはコード変更ではなく、設定変更です。** すでに計装されているアプリケーションにJVMフラグを追加することで有効にしました。これにより、アプリケーションコードに触れることなく、組織全体に展開することが実用的になります。 +- **デュアルモードはコード変更ではなく、設定変更です。** すでに計装されたアプリケーションに JVM フラグを追加することで有効化しました。これにより、アプリケーションコードに触れることなく組織全体に展開することが現実的になります。 -- **`appd.*` 相関属性がこの統合を価値あるものにしています。** これらがない場合（ハイブリッドモード）、Splunk O11yでOTelトレースを取得できますが、特定のAppDynamicsビジネストランザクション、ティア、またはアプリケーションにリンクバックする方法がありません。デュアルモードはそのリンケージを提供します。 +- **`appd.*` 相関属性が統合を価値あるものにしています。** これらがなければ（ハイブリッドモード）、Splunk O11y で OTel トレースを取得できますが、特定の AppDynamics ビジネストランザクション、tier、またはアプリケーションにリンクする方法がありません。デュアルモードはそのリンケージを提供します。 -- **グローバルデータリンクは相関をワークフローに変えます。** 2つのツールを手動でクロスリファレンスする代わりに、エンジニアはSplunk O11yトレースからAppDynamicsビューに直接クリックで移動できます。 +- **グローバルデータリンクは相関をワークフローに変えます。** 2 つのツールを手動でクロスリファレンスする代わりに、エンジニアは Splunk O11y トレースから AppDynamics ビューに直接クリックできます。 -- **このパターンは段階的な移行をサポートします。** 組織はデュアルモードを一定期間実行して、Splunk Observability Cloudが同じシグナル品質をキャプチャすることを検証し、その後サービスごとにデュアルを継続するか、Splunkのみの計装に切り替えるか、AppDynamicsを維持するかを決定できます。 +- **このパターンは段階的な移行をサポートします。** 組織はデュアルモードを一定期間実行して、Splunk Observability Cloud が同じシグナル品質をキャプチャすることを検証できます。その後、サービスごとにデュアルを継続するか、Splunk のみの計装に切り替えるか、AppDynamics を維持するかを決定します。 ## 参考資料 -- [Enable Dual Signal Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-dual-signal-mode) -- AppDynamicsドキュメント -- [Enable Hybrid Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-hybrid-mode) -- AppDynamicsドキュメント -- [Java Agent Frameworks for OpenTelemetry](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/support-for-appdynamics-for-opentelemetry/java-agent-frameworks-for-opentelemetry) -- サポートされているフレームワーク一覧 -- [Global Data Links](https://docs.splunk.com/observability/en/data-visualization/navigate-with-data-links.html) -- Splunk Observabilityドキュメント +- [Enable Dual Signal Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-dual-signal-mode) (AppDynamics ドキュメント) +- [Enable Hybrid Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-hybrid-mode) (AppDynamics ドキュメント) +- [Java Agent Frameworks for OpenTelemetry](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/support-for-appdynamics-for-opentelemetry/java-agent-frameworks-for-opentelemetry) (サポートされるフレームワーク一覧) +- [Global Data Links](https://docs.splunk.com/observability/en/data-visualization/navigate-with-data-links.html) (Splunk Observability ドキュメント) diff --git a/content/ja/ninja-workshops/17-appd-ingest/_index.md b/content/ja/ninja-workshops/17-appd-ingest/_index.md index 8603ad8239..a80c1fdc8b 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/_index.md +++ b/content/ja/ninja-workshops/17-appd-ingest/_index.md @@ -1,5 +1,6 @@ --- -draft: true +draft: false +hidden: true title: AppDynamics Dual Ingest to Splunk Observability linkTitle: AppD Dual Ingest weight: 17 @@ -9,4 +10,4 @@ authors: ["Jeremy Hicks"] description: AppDynamics Java Agent のデュアルシグナルモードを使用して、APM データを AppDynamics と Splunk Observability Cloud の両方に同時に送信し、グローバルデータリンクで両者を接続する方法を実演するハンズオンワークショップです。 --- -AppDynamics Java Agentを使用したデュアルインジェストについて学び、AppDynamicsとSplunk Observability Cloudの両方にデータを送信する方法を学びます。 +AppDynamics Java Agent を使用した Dual Ingest について学び、AppDynamics と Splunk Observability Cloud の両方にデータを送信する方法を習得します。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md index 6d94165ea7..65004ef74d 100644 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md +++ b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md @@ -6,15 +6,15 @@ weight: 1 ## OTLP HTTP Exporter -HTTP 経由で Splunk Observability Cloud にメトリクスを送信するには、**otlphttp** exporter を設定する必要があります。 +HTTP 経由で Splunk Observability Cloud にメトリクスを送信するには、**otlphttp** エクスポーターを設定する必要があります。 -`/etc/otelcol-contrib/config.yaml` ファイルを編集して、**otlphttp** exporter を設定しましょう。以下の YAML を **exporters** セクションの下に挿入してください。インデントは2スペースで行ってください。 +`/etc/otelcol-contrib/config.yaml` ファイルを編集して、**otlphttp** エクスポーターを設定しましょう。以下の YAML を **exporters** セクションの下に挿入してください。インデントは2スペースで揃えます。 -また、ディスクがいっぱいにならないように、logging exporter の詳細度を変更します。デフォルトの `detailed` は非常に冗長です。 +また、ディスクがいっぱいになるのを防ぐために、ロギングエクスポーターの詳細度も変更します。デフォルトの `detailed` は非常に出力が多いです。 ```yaml {hl_lines="3-4"} exporters: - logging: + debug: verbosity: normal otlphttp/splunk: ``` @@ -22,7 +22,7 @@ exporters: 次に、`metrics_endpoint` を定義してターゲット URL を設定する必要があります。 {{% notice style="note" %}} -Splunk 主催のワークショップに参加されている場合、使用しているインスタンスにはすでに Realm 環境変数が設定されています。設定ファイルでその環境変数を参照します。それ以外の場合は、新しい環境変数を作成して Realm を設定する必要があります。例 +Splunk 主催のワークショップに参加している場合、使用しているインスタンスにはすでに Realm 環境変数が設定されています。設定ファイルでその環境変数を参照します。それ以外の場合は、新しい環境変数を作成して Realm を設定する必要があります。例 ``` bash export REALM="us1" @@ -30,24 +30,24 @@ export REALM="us1" {{% /notice %}} -使用する URL は `https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp` です。（Splunk は、データレジデンシーのために世界中の主要な地理的場所に Realm を持っています）。 +使用する URL は `https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp` です。（Splunk はデータレジデンシーのために、世界の主要な地理的ロケーションに Realm を設置しています）。 -**otlphttp** exporter は、`traces_endpoint` と `logs_endpoint` のターゲット URL を定義することで、トレースとログを送信するように設定することもできます。これらの設定は、このワークショップの範囲外です。 +**otlphttp** エクスポーターは、`traces_endpoint` と `logs_endpoint` にそれぞれターゲット URL を定義することで、トレースとログを送信するように設定することもできます。これらの設定はこのワークショップの範囲外です。 ```yaml {hl_lines="5"} exporters: - logging: + debug: verbosity: normal otlphttp/splunk: metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp ``` -デフォルトでは、すべてのエンドポイントで `gzip` 圧縮が有効になっています。これは、exporter 設定で `compression: none` を設定することで無効にできます。このワークショップでは、データを送信する最も効率的な方法であるため、圧縮を有効のままにしてデフォルトを使用します。 +デフォルトでは、すべてのエンドポイントで `gzip` 圧縮が有効になっています。これはエクスポーター設定で `compression: none` を設定することで無効にできます。このワークショップでは、データを送信する最も効率的な方法であるため、圧縮を有効のままにしてデフォルトを使用します。 -Splunk Observability Cloud にメトリクスを送信するには、アクセストークンを使用する必要があります。これは、Splunk Observability Cloud UI で新しいトークンを作成することで行えます。トークンの作成方法の詳細については、[Create a token](https://docs.splunk.com/Observability/admin/authentication-tokens/org-tokens.html) を参照してください。トークンは **INGEST** タイプである必要があります。 +Splunk Observability Cloud にメトリクスを送信するには、アクセストークンを使用する必要があります。これは Splunk Observability Cloud UI で新しいトークンを作成することで行えます。トークンの作成方法の詳細については、[Create a token](https://docs.splunk.com/Observability/admin/authentication-tokens/org-tokens.html) を参照してください。トークンのタイプは **INGEST** である必要があります。 {{% notice style="note" %}} -Splunk 主催のワークショップに参加されている場合、使用しているインスタンスにはすでにアクセストークンが設定されています（環境変数として設定されています）。設定ファイルでその環境変数を参照します。それ以外の場合は、新しいトークンを作成して環境変数として設定する必要があります。例 +Splunk 主催のワークショップに参加している場合、使用しているインスタンスにはすでにアクセストークンが設定されています（環境変数として設定済み）。設定ファイルでその環境変数を参照します。それ以外の場合は、新しいトークンを作成して環境変数として設定する必要があります。例 ``` bash export ACCESS_TOKEN= @@ -55,11 +55,11 @@ export ACCESS_TOKEN= {{% /notice %}} -トークンは、`headers:` セクションの下に `X-SF-TOKEN: ${env:ACCESS_TOKEN}` を挿入することで設定ファイルに定義されます +トークンは、`headers:` セクションの下に `X-SF-TOKEN: ${env:ACCESS_TOKEN}` を挿入することで設定ファイルに定義します ```yaml {hl_lines="6-8"} exporters: - logging: + debug: verbosity: normal otlphttp/splunk: metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp @@ -69,11 +69,11 @@ exporters: ## 設定の確認 -Exporter について説明したので、設定の変更を確認しましょう +エクスポーターについて説明したので、設定の変更を確認しましょう --- -{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}Review your configuration{{% /badge %}}" %}} +{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定を確認する{{% /badge %}}" %}} {{< tabs >}} {{% tab title="config.yaml" %}} @@ -194,6 +194,6 @@ service: --- -もちろん、**OTLP** プロトコルをサポートする他のソリューションを指すように `metrics_endpoint` を簡単に設定できます。 +もちろん、`metrics_endpoint` を **OTLP** プロトコルをサポートする他のソリューションに向けて設定することも簡単にできます。 -次に、`config.yaml` の service セクションで、設定した receivers、processors、exporters を有効にする必要があります。 +次に、`config.yaml` の service セクションで、設定したレシーバー、プロセッサー、エクスポーターを有効にする必要があります。