From 6c9ed2bf42a3aae4a77b4edb4453c81f7cbb4183 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Mon, 11 May 2026 01:10:52 +0000 Subject: [PATCH] Add Japanese translations for v6.63 Automatically translated using Claude Code with AWS Bedrock. - Translated files: 44 - Failed files: 0 Generated by GitHub Actions --- .../2-python-warmup/1-install-and-run.md | 24 +- .../2-python-warmup/2-instrument-with-obi.md | 24 +- .../1-configure-and-start.md | 32 +- .../3-docker-before-obi/2-generate-traffic.md | 20 +- .../4-docker-obi-magic/3-verify-traces.md | 26 +- .../5-kubernetes/2-deploy-baseline.md | 16 +- .../5-kubernetes/3-add-obi-daemonset.md | 34 +- .../16-obi-ebpf/6-wrap-up/_index.md | 39 +-- .../2-run-with-appd/1-build-the-app.md | 16 +- .../2-run-with-appd/2-download-appd-agent.md | 21 +- .../2-run-with-appd/3-run-and-verify.md | 41 +-- .../1-install-otel-collector.md | 46 +-- .../3-enable-dual-mode/2-enable-dual-mode.md | 41 +-- .../18-agentic-ai/1-connect-to-instance.md | 58 +++- .../10-add-ai-defense-instrumentation.md | 90 ++--- .../18-agentic-ai/11-detect-security-risks.md | 47 ++- .../12-explore-other-ai-frameworks.md | 70 ++-- .../2-review-azure-ai-metrics.md | 28 +- .../18-agentic-ai/3-deploy-collector.md | 24 +- .../4-review-agentic-ai-app/_index.md | 38 ++- .../18-agentic-ai/5-deploy-the-app.md | 74 +++-- .../18-agentic-ai/6-instrument-the-app.md | 59 ++-- .../7-review-agent-trace-data.md | 35 +- .../18-agentic-ai/8-add-tool-calls.md | 97 +++--- .../18-agentic-ai/9-detect-quality-issue.md | 58 ++-- .../1-getting-started/_index.md | 84 +++++ ...-cisco-enterprise-networks-content-pack.md | 94 ++++++ .../2-itsi-service-kpi-import-and-setup.md | 117 +++++++ .../3-itsi-validate-configuration.md | 55 ++++ .../_index.md | 50 +++ ...up-cisco-catalyst-inbound-notifications.md | 142 ++++++++ .../_index.md | 28 ++ .../1-solarwinds-content-pack.md | 145 ++++++++ .../_index.md | 26 ++ .../1-itsi-create-custom-neap.md | 127 +++++++ .../2-itsi-service-kpi-review.md | 77 +++++ .../5-create-custom-neap/_index.md | 31 ++ .../6-scenario-review/_index.md | 137 ++++++++ .../network-event-intelligence/_index.md | 50 +++ .../4-distributed-tracing/_index.md | 310 ++++++++++++------ .../4-kubernetes-testing/_index.md | 280 ++++++++++++---- .../thousandeyes-integration/_index.md | 39 +-- .../2-online-boutique/_index.md | 48 +++ content/ja/workshop-setup/5-presenter-mode.md | 64 ++++ 44 files changed, 2324 insertions(+), 638 deletions(-) create mode 100644 content/ja/scenarios/network-event-intelligence/1-getting-started/_index.md create mode 100644 content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/1-cisco-enterprise-networks-content-pack.md create mode 100644 content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/2-itsi-service-kpi-import-and-setup.md create mode 100644 content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/3-itsi-validate-configuration.md create mode 100644 content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/_index.md create mode 100644 content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/1-setup-cisco-catalyst-inbound-notifications.md create mode 100644 content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/_index.md create mode 100644 content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/1-solarwinds-content-pack.md create mode 100644 content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/_index.md create mode 100644 content/ja/scenarios/network-event-intelligence/5-create-custom-neap/1-itsi-create-custom-neap.md create mode 100644 content/ja/scenarios/network-event-intelligence/5-create-custom-neap/2-itsi-service-kpi-review.md create mode 100644 content/ja/scenarios/network-event-intelligence/5-create-custom-neap/_index.md create mode 100644 content/ja/scenarios/network-event-intelligence/6-scenario-review/_index.md create mode 100644 content/ja/scenarios/network-event-intelligence/_index.md create mode 100644 content/ja/splunk4rookies/observability-cloud-short/2-online-boutique/_index.md create mode 100644 content/ja/workshop-setup/5-presenter-mode.md 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 6155d3edc6..eef9a1b8ba 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,12 +31,12 @@ Successfully installed flask-3.x.x ... ## Splunk 認証情報の設定 -認証情報を環境変数としてエクスポートします。各プレースホルダーを実際の値に置き換えてください +認証情報を環境変数としてエクスポートします。各プレースホルダーを実際の値に置き換えてください: {{% notice title="Exercise" style="green" icon="running" %}} -`env` と入力すると、環境には `ACCESS_TOKEN`、`REALM`、`INSTANCE` の値が設定されているはずです +`env` と入力したときに、`ACCESS_TOKEN`、`REALM`、`INSTANCE` の値が環境に設定されている必要があります。 -**存在しない場合は、以下のようにエクスポートしてください** +**値が存在しない場合は、以下のようにエクスポートしてください** ``` bash export ACCESS_TOKEN="" @@ -48,28 +48,30 @@ 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 ``` -エンドポイントにアクセスして、動作していることを確認します +まず Enter キーを押してプロンプトに戻ります。 +次にエンドポイントにアクセスして、動作を確認します: ``` bash -curl http://localhost:5150/hello +curl -s http://localhost:5150/hello | jq ``` -以下のレスポンスが返ってくるはずです +以下のレスポンスが返されるはずです: ``` json +127.0.0.1 - - [04/May/2026 13:10:16] "GET /hello HTTP/1.1" 200 - { "host": "", "message": "Hello from the OBI Workshop warm-up!" @@ -78,11 +80,11 @@ curl http://localhost:5150/hello ## Splunk での確認 -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)します） +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 5639b75e9b..b52850baed 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,5 +1,5 @@ --- -title: 2. OBI でインストルメントする +title: 2. OBI による計装 weight: 2 --- @@ -7,13 +7,13 @@ weight: 2 ## OBI のダウンロード -[GitHub リリースページ](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases)からビルド済みの OBI バイナリをダウンロードします。 +[GitHub リリースページ](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases)からビルド済みの OBI バイナリをダウンロードします {{< tabs >}} {{% tab title="Script" %}} ```bash -VERSION=0.6.0 +VERSION=0.8.0 ARCH=amd64 wget "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/download/v$VERSION/obi-v$VERSION-linux-$ARCH.tar.gz" wget "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/download/v$VERSION/SHA256SUMS" @@ -37,7 +37,7 @@ obi-v0.6.0-linux-amd64.tar.gz: OK {{% notice title="Exercise" style="green" icon="running" %}} -**別のターミナル**で、`sudo` を使って OBI を実行します。3つのプレースホルダーを前のステップで確認した realm、token、hostname に置き換えてください（完了まで1〜2分かかる場合があります）。 +**別のターミナル**で、`sudo` を使って OBI を実行します。3つのプレースホルダーを前のステップで取得した realm、token、hostname に置き換えてください（完了までに1〜2分かかる場合があります） {{< tabs >}} {{% tab title="Script" %}} @@ -71,27 +71,27 @@ 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 のパスとは一致しません | +| `sudo` | eBPF プローブにはroot/カーネルアクセスが必要です | +| `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` | ポート 5150 でリッスンしているプロセスをインストルメントするよう OBI に指示します | +| `OTEL_RESOURCE_ATTRIBUTES` | すべてのトレースに `deployment.environment` と `host.name` を設定し、自分のデータをフィルタリングできるようにします | +| `OTEL_EBPF_OPEN_PORT` | ポート 5150 でリッスンしているプロセスを計装するよう OBI に指示します | {{% notice title="Note" style="info" %}} -OBI のログに `failed to upload metrics: 404 Not Found` のような警告が表示される場合があります。これは想定どおりです。Splunk の直接取り込みには標準的な OTLP メトリクスエンドポイントがありません。トレースは正常にエクスポートされます。Phase 2 では、Collector がトレースとメトリクスの両方を適切に処理します。 +OBI のログに `failed to upload metrics: 404 Not Found` のような警告が表示される場合があります。これは想定どおりの動作です。Splunk のダイレクトインジェストには標準的な OTLP メトリクスエンドポイントがありません。トレースは正常にエクスポートされます。フェーズ2では、コレクターがトレースとメトリクスの両方を適切に処理します。 {{% /notice %}} ## トラフィックの生成 -最初のターミナルに戻り、いくつかのリクエストを生成します。 +最初のターミナルに戻り、いくつかのリクエストを生成します ```bash for i in $(seq 1 20); do curl -s "http://localhost:5150/hello"; sleep 1; done ``` -***注意:*** 404 エラーが発生した場合は、curl している URL の末尾に `\` が付加されていないか確認してください。一部のターミナルでは `;` がエスケープされ、無効な URL になることがあります +***NOTE:*** 404 エラーが発生した場合は、curl で指定している URL の末尾に `\` が付加されていないか確認してください。一部のターミナルでは `;` がエスケープされ、無効な URL になることがあります 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 e2f8b8ad3d..89e41d2f2a 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 @@ -5,18 +5,22 @@ weight: 1 ## Splunk 認証情報の追加 -{{% notice title="演習" style="green" icon="running" %}} +{{% notice title="Exercise" style="green" icon="running" %}} -**注:** 環境で `env` コマンドを使用して `ACCESS_TOKEN`、`REALM`、`INSTANCE` を取得してください。これらを設定ファイルに貼り付ける必要があります。 +**注意:** 環境内の `ACCESS_TOKEN`、`REALM`、`INSTANCE` を確認してください。これらの値を設定ファイルに貼り付ける必要があります。 -Phase 1/2 ディレクトリに移動し、エディタで `docker-compose.yaml` を開きます: +``` bash +echo $ACCESS_TOKEN; echo $REALM; echo $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つのプレースホルダー値を実際の認証情報に置き換えます: +`splunk-otel-collector` サービスを見つけ、4つのプレースホルダー値を実際の認証情報に置き換えます ``` yaml environment: @@ -30,21 +34,21 @@ 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 で**自分の**データをフィルタリングできます。 +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +**なぜ `WORKSHOP_HOST_NAME` と `WORKSHOP_ENVIRONMENT` が必要なのですか？** ワークショップの参加者全員が同じ Splunk 組織にテレメトリを送信します。これらの値はすべてのメトリクスとトレースの `host.name` および `deployment.environment` 属性になるため、Splunk で**自分の**データをフィルタリングできます。 {{% /notice %}} ## スタックの起動 {{< tabs >}} -{{% tab title="スクリプト" %}} +{{% tab title="Script" %}} ``` bash docker-compose up --build -d ``` {{% /tab %}} -{{% tab title="出力例" %}} +{{% tab title="Example Output" %}} ``` text [+] Building 12.3s (24/24) FINISHED @@ -59,10 +63,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/2-generate-traffic.md b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md index 689ab87a5f..d4cc88e6e9 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md @@ -3,19 +3,19 @@ title: 2. トラフィックの生成 weight: 2 --- -## フロントエンドへのアクセス +## フロントエンドにアクセスする -{{% notice title="演習" style="green" icon="running" %}} +{{% notice title="Exercise" style="green" icon="running" %}} -curlを使用してトラフィックを生成します: +curl を使用してトラフィックを生成します: ``` bash -curl -s http://localhost:3000/create-order | python3 -m json.tool +curl -s http://localhost:3000/create-order | jq ``` {{% /notice %}} -以下のようなJSONレスポンスが表示されます: +次のような JSON レスポンスが表示されるはずです: ``` json { @@ -28,13 +28,13 @@ curl -s http://localhost:3000/create-order | python3 -m json.tool } ``` -リクエストは3つのサービスすべてを通過しました。しかし、現時点では誰も監視していません。 +リクエストは3つのサービスすべてを通過しました。しかし現時点では、誰も監視していません。 -## コードの確認 +## コードを確認する -ソースコードを確認し、計装がまったく行われていないことを確認してください: +ソースコードを確認して、計装がまったく存在しないことを確認しましょう: -{{% notice title="演習" style="green" icon="running" %}} +{{% notice title="Exercise" style="green" icon="running" %}} ``` bash grep -r "opentelemetry\|otel\|tracing\|instrument" ~/workshop/obi/02-obi-docker/frontend/ @@ -44,4 +44,4 @@ grep -r "opentelemetry\|otel\|tracing\|instrument" ~/workshop/obi/02-obi-docker/ {{% /notice %}} -3つのコマンドはすべて何も返しません。アプリケーションコードには**トレースヘッダー、SDK、計装が一切ありません**。 +3つのコマンドはすべて何も返しません。アプリケーションコードのどこにも **トレーシングヘッダー、SDK、計装は一切ありません**。 diff --git a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md index 080a9938a0..315680010c 100644 --- a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md +++ b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md @@ -5,14 +5,14 @@ weight: 3 ## クイック検証 -まず、すべてが正常に動作していることを確認します： +まず、すべてが正常に動作していることを確認します: {{< tabs >}} {{% tab title="Script" %}} ``` bash docker-compose ps -curl -s localhost:3000/create-order | python3 -m json.tool +curl -s localhost:3000/create-order | jq docker-compose logs obi | head -30 ``` @@ -28,7 +28,7 @@ docker-compose logs obi | head -30 {{% /tab %}} {{< /tabs >}} -OBIのログで、次のような行を探してください： +OBI のログで、以下のような行を探してください: ``` text level=INFO msg="instrumenting process" cmd=/usr/local/bin/payment-service service=payment-service @@ -36,33 +36,33 @@ level=INFO msg="instrumenting process" cmd=/usr/local/bin/order-processor servic level=INFO msg="instrumenting process" cmd=node service=frontend ``` -## Splunk APM を確認する +## Splunk APM の確認 -トレースが流れるまで30〜60秒待ってから、Splunk APMを確認します。 +トレースが流れるまで 30〜60 秒待ってから、Splunk APM を確認します。 {{% notice title="Exercise" style="green" icon="running" %}} -1. **Service Map**: APMに移動し、ご自身の環境でフィルタリングします。3つのサービスが表示されるはずです: `frontend` -> `order-processor` -> `payment-service`。 -2. **Traces**: 任意のトレースをクリックします。3つのサービスすべてにまたがる完全な分散トレースと、各ホップのタイミングが表示されます。 -3. **フェーズ 1 との比較**: 数分前は完全に空だったAPMダッシュボードに、完全なサービストポロジーが表示されるようになりました。 +1. **Service Map**: APM に移動し、ご自身の環境でフィルタリングします。`frontend` -> `order-processor` -> `payment-service` の3つのサービスが表示されるはずです。 +2. **Traces**: 任意のトレースをクリックします。3つのサービスすべてにまたがる分散トレースが、各ホップのタイミングとともに表示されます。 +3. **Phase 1 との比較**: 数分前には完全に空だった APM ダッシュボードに、完全なサービストポロジーが表示されるようになりました。 {{% /notice %}} -**compose ファイルにコンテナを 1 つ追加しただけです。アプリケーションコードは 1 行も変更していません。これで完全な分散トレーシングが実現しました。** +**compose ファイルにコンテナを1つ追加しただけです。アプリケーションコードの変更はゼロ行です。これで完全な分散トレーシングが実現しました。** -## 解答 +## 解答例 -途中で詰まった場合は、すべての変更が適用された最終的な `docker-compose.yaml` を以下で確認できます： +途中で行き詰まった場合、すべての変更が適用された最終版の `docker-compose.yaml` は以下で確認できます: ``` bash cat ~/workshop/obi/02-obi-docker/docker-compose.final.yaml ``` -ご自身の `docker-compose.yaml` と比較して、違いを確認してください。 +ご自身の `docker-compose.yaml` と比較して、差分を確認してください。 ## Docker のクリーンアップ -Kubernetesフェーズに進む前に、Dockerスタックを停止します： +Kubernetes フェーズに進む前に、Docker スタックを停止します: ``` bash docker-compose down 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 6418557449..5652c59bfa 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,22 +124,22 @@ splunk-otel-collector-cluster-receiver-xyz34 1/1 Running 0 ## アプリケーションのテスト -NodePort 経由でフロントエンドにアクセスします: +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 +curl -s http://localhost:30000/create-order | jq ``` ## APM が空であることを確認 {{% notice title="Exercise" style="green" icon="running" %}} -Splunk APM で環境 `-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 8f46005d8f..3d941b4ed3 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,11 +1,11 @@ --- -title: 3. Helm で OBI を有効化 +title: 3. Helm で OBI を有効化する weight: 3 --- -アプリケーションコードを一切変更せずに、Helm のアップグレード1回だけでクラスター全体にトレーシングを追加します。 +アプリケーションコードを一切変更せずに、Helm のアップグレード1つでクラスター全体にトレーシングを追加します。 -## OBI を有効にして Collector をアップグレード +## OBI を有効にして Collector をアップグレードする {{% notice title="Exercise" style="green" icon="running" %}} @@ -21,16 +21,16 @@ helm -n obi-workshop upgrade splunk-otel-collector \ {{% /notice %}} -変更点は `--set="obi.enabled=true"` という1つのオプションだけです。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 # See all processes on the node, including other pods @@ -38,9 +38,9 @@ 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 が実行されていることを確認 +## OBI の動作を確認する {{< tabs >}} {{% tab title="Script" %}} @@ -51,7 +51,7 @@ kubectl logs -n obi-workshop -l app.kubernetes.io/name=obi --tail=20 ``` {{% /tab %}} -{{% tab title="Example Output to look for" %}} +{{% tab title="確認すべき出力例" %}} ``` text NAME READY STATUS RESTARTS AGE @@ -71,17 +71,17 @@ level=INFO msg="instrumenting process" service=frontend トラフィックを生成します ``` bash -curl -s http://localhost:30000/create-order | python3 -m json.tool +curl -s http://localhost:30000/create-order | jq ``` -## Splunk APM を確認 +## Splunk APM を確認する -トレースが流れるまで30〜60秒待ちます。 +トレースが流れるまで30〜60秒お待ちください。 {{% notice title="Exercise" style="green" icon="running" %}} 1. **Service Map**: `frontend` -> `order-processor` -> `payment-service` の3つのサービスが表示されるはずです。 -2. **Traces**: 任意のトレースをクリックします。3つのサービスすべてにまたがる完全な分散トレースと、各ホップのタイミングが表示されます。 -3. **フェーズ2と同じストーリー**: コード変更ゼロ。1つのフラグを付けた `helm upgrade` 1回だけです。 +2. **Traces**: 任意のトレースをクリックしてください。3つのサービスすべてにまたがる分散トレースが、各ホップのタイミングとともに表示されます。 +3. **フェーズ 2 と同じストーリー**: コード変更はゼロです。1つのフラグを指定した `helm upgrade` 1回だけです。 {{% /notice %}} 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 c20fade2ce..a5381ac4cd 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,25 +4,26 @@ 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 は誰にもコードの変更を求めることなくオブザーバビリティを提供します。 ## クリーンアップ ### Kubernetes ``` bash -helm uninstall splunk-otel-collector +kill %1 2>/dev/null; # kill port forward +helm -n obi-workshop uninstall splunk-otel-collector kubectl delete namespace obi-workshop ``` @@ -42,33 +43,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 にポート 8082 で Python（Flask）の `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="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/17-appd-ingest/2-run-with-appd/1-build-the-app.md b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/1-build-the-app.md index ac8db700ab..e1561b4b81 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/1-build-the-app.md +++ b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/1-build-the-app.md @@ -3,11 +3,11 @@ title: 1. アプリのビルド weight: 1 --- -このワークショップには、いくつかのRESTエンドポイントを持つシンプルなSpring Bootアプリケーションが含まれています。ビルドしましょう。 +このワークショップには、いくつかの REST エンドポイントを持つシンプルな Spring Boot アプリケーションが含まれています。それをビルドしましょう。 ## Java と Maven の確認 -インスタンスにはOpenJDK 17とMavenがプリインストールされています。確認してください： +インスタンスには OpenJDK 17 と Maven がプリインストールされています。以下のコマンドで確認します: {{< tabs >}} {{% tab title="Command" %}} @@ -29,7 +29,7 @@ Apache Maven 3.x.x ... ## アプリケーションのビルド -ワークショップのアプリディレクトリに移動し、fat JARをビルドします： +ワークショップのアプリディレクトリに移動し、fat JAR をビルドします: {{< tabs >}} {{% tab title="Command" %}} @@ -50,18 +50,18 @@ mvn package -DskipTests {{< /tabs >}} {{% notice title="初回ビルド" style="info" icon="info-circle" %}} -最初の `mvn package` はSpring Bootの依存関係をダウンロードします。30〜60秒かかります。2回目以降のビルドはずっと速くなります。 +初回の `mvn package` では Spring Boot の依存関係をダウンロードします。これには 30〜60 秒かかります。2 回目以降のビルドはより高速です。 {{% /notice %}} ## アプリケーションのテスト（AppD なし） -アプリを短時間実行して、起動を確認します： +アプリが起動することを確認するため、一時的に実行します: ```bash java -jar target/ingest-workshop-1.0.0.jar & ``` -数秒待ってからテストします： +数秒待ってから Enter キーを押してプロンプトに戻り、テストを実行します: {{< tabs >}} {{% tab title="Command" %}} @@ -82,10 +82,10 @@ curl -s localhost:8080/health | jq . {{% /tab %}} {{< /tabs >}} -次に進む前にアプリを停止します： +次に進む前にアプリを停止します: ```bash kill %1 ``` -アプリケーションは正常に動作しています。次に、AppDynamics Java Agentをダウンロードして、このプロセスにアタッチします。 +アプリケーションは正常に動作しています。次のステップでは、AppDynamics Java Agent をダウンロードして、このプロセスにアタッチします。 diff --git a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md index b8b55cf122..76e2ca8440 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md +++ b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md @@ -1,13 +1,13 @@ --- -title: 2. AppD エージェントのダウンロード +title: 2. AppD Agent のダウンロード weight: 2 --- -デュアルシグナルモードを使用するには、AppDynamics Java Agent（バージョン 25.6.0 以上）が必要です。インスタンスにエージェントを追加します。 +デュアルシグナルモードを使用するには、AppDynamics Java Agent（バージョン 25.6.0 以上）が必要です。インスタンスに追加します。 -## エージェントの展開 +## Agent の解凍 -インスタンスに SSH 接続し、ダウンロードスクリプトを実行すると、作成済みの `agent` ディレクトリにエージェントが展開されます。 +インスタンスに SSH 接続し、ダウンロードスクリプトを実行すると、作成済みの `agent` ディレクトリに Agent が展開されます ```bash cd ~/workshop/appd @@ -16,16 +16,17 @@ chmod +x ./download-appd-agent.sh ./download-appd-agent.sh ``` -これで `~/workshop/appd/agent/javaagent.jar` にエージェントの JAR ファイルが配置されているはずです。 +これで `~/workshop/appd/agent/javaagent.jar` に Agent の JAR ファイルが配置されているはずです。 ## Account Access Key の確認 -アプリケーションを実行する際に [**Account Access Key**](https://se-lab.saas.appdynamics.com/controller/#/licensing/license-management-account?timeRange=last_15_minutes.BEFORE_NOW.-1.-1.15) が必要になります。AppDynamics Controller で確認できます。 +アプリケーションを実行する際に [**Account Access Key**](https://se-lab.saas.appdynamics.com/controller/#/licensing/license-management-account?timeRange=last_15_minutes.BEFORE_NOW.-1.-1.15) が必要になります。AppDynamics Controller で確認できます -1. **Settings**（歯車アイコン）→ **License** に移動します -2. 左側のサイドバーで **Account** をクリックします -2. **Account** の下にある **Name**（`se-lab`）と **Access Key** をメモします +1. 画面右上の自分の名前をクリックします +2. **Admin** → **License** に移動します +3. 左サイドバーの **Account** をクリックします +4. **Account** の下にある **Name**（`se-lab`）と **Access Key** を控えます {{% notice title="手元に控えておきましょう" style="primary" icon="lightbulb" %}} -次のステップで Account Name と Access Key を JVM プロパティとして使用します。これらはエージェントをコントローラーに認証するために必要です。 +次のステップで Account Name と Access Key を JVM プロパティとして使用します。これらは Agent を Controller に認証するために必要です。 {{% /notice %}} 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 95bd6c33d6..bf5cc608cc 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,24 +1,24 @@ --- -title: 3. AppD で実行と確認 +title: 3. AppD での実行と確認 weight: 3 --- -ここで、AppDynamics エージェントをアタッチした状態でアプリケーションを実行します。これは「通常の」単一送信先のインストルメンテーションです。 +AppDynamics エージェントをアタッチしてアプリケーションを実行します。これは「通常の」単一送信先へのインストルメンテーションです。 -## AppDynamics エージェントを使った実行 +## AppDynamics エージェントで実行する -`` を、前のステップで取得した AppDynamics トークンに置き換えます。 +`` を前のステップで取得した AppDynamics トークンに置き換えてください: {{< tabs >}} -{{% tab title="コマンド" %}} -環境変数をエクスポートします。 +{{% tab title="Command" %}} +環境変数をエクスポートします ```bash export APPD_ACCESS_KEY= export APPD_APP_NAME=Dual-Ingest-${INSTANCE} ``` -その後、エージェント付きで Java を起動できます。 +次に、エージェント付きで Java を起動します: ```bash cd ~/workshop/appd @@ -32,11 +32,11 @@ java -javaagent:agent/javaagent.jar \ -Dappdynamics.agent.nodeName=OrderService-Node \ -Dappdynamics.agent.accountName=se-lab \ -Dappdynamics.agent.accountAccessKey=${APPD_ACCESS_KEY} \ - -jar app/target/ingest-workshop-1.0.0.jar & + -jar app/target/ingest-workshop-1.0.0.jar & ``` {{% /tab %}} -{{% tab title="例" %}} +{{% tab title="Example" %}} ```text java -javaagent:agent/javaagent.jar \ @@ -54,11 +54,12 @@ java -javaagent:agent/javaagent.jar \ {{% /tab %}} {{< /tabs >}} -Spring Boot の起動バナーが表示されるまで待ちます（10〜15秒程度）。 +Spring Boot の起動バナーが表示されるまで待ちます（約10〜15秒）。 +Enter キーを押してプロンプトに戻ります。 ## 負荷を生成する -バックグラウンドでシンプルなロードジェネレーターを開始します。 +バックグラウンドでシンプルな負荷生成ツールを起動します: ```bash while true; do @@ -71,22 +72,22 @@ done & ## AppDynamics Controller で確認する 1. [AppDynamics Controller](https://se-lab.saas.appdynamics.com/controller/) を開きます -2. **Applications** に移動し、自分のアプリケーション（例: `Dual-Ingest-`）を見つけます +2. **Applications** に移動し、お使いのアプリケーションを見つけます（例: `Dual-Ingest-`） 3. アプリケーションをクリックして **Flow Map** を表示します -{{% notice title="少しお待ちください" style="info" icon="info-circle" %}} -アプリケーションが登録され、ビジネストランザクションが flow map に表示されるまで、2〜5分かかる場合があります。必要に応じてページを更新してください。 +{{% notice title="お待ちください" style="info" icon="info-circle" %}} +アプリケーションが登録され、ビジネストランザクションがフローマップに表示されるまで2〜5分かかる場合があります。必要に応じてページを更新してください。 {{% /notice %}} -次の内容が表示されるはずです。 +以下が表示されるはずです: -- flow map に表示される **OrderService** tier +- フローマップ内の **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 title="実行を継続してください" style="warning" icon="exclamation-triangle" %}} +アプリケーションと負荷生成ツールは実行したままにしてください。次のセクションでデュアルモードフラグを追加するために停止します。 {{% /notice %}} diff --git a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md index 31c100baaf..2a211ebc08 100644 --- a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md +++ b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md @@ -3,7 +3,7 @@ title: 1. OTel Collector のインストール weight: 1 --- -デュアルモードの AppDynamics エージェントは OTLP 経由で OpenTelemetry データを送信します。そのデータを受信して Splunk Observability Cloud に転送するために、同じホスト上に Collector が必要です。 +デュアルモードの AppDynamics エージェントは、OTLP 経由で OpenTelemetry データを送信します。そのデータを受信して Splunk Observability Cloud に転送するために、同じホスト上にコレクターが必要です。 ## 環境変数の確認 @@ -15,11 +15,11 @@ echo "ACCESS_TOKEN=$ACCESS_TOKEN" echo "INSTANCE=$INSTANCE" ``` -3つすべてに値が設定されている必要があります。空のものがある場合は、インストラクターに確認してください。 +3つすべてに値が設定されている必要があります。いずれかが空の場合は、インストラクターに確認してください。 ## Splunk OpenTelemetry Collector のインストール -Splunk OTel Collector のインストールスクリプトを実行します。これにより、Collector が `systemd` サービスとしてインストールされます +Splunk OTel Collector のインストールスクリプトを実行します。これにより、コレクターが `systemd` サービスとしてインストールされます {{< tabs >}} {{% tab title="Command" %}} @@ -39,9 +39,9 @@ Splunk OpenTelemetry Collector has been successfully installed. {{% /tab %}} {{< /tabs >}} -## ワークショップ用 Collector 設定の適用 +## ワークショップ用コレクター設定の適用 -デフォルトの Collector 設定は汎用的なものです。これを、AppDynamics エージェントから OTLP を受信し Splunk Observability Cloud にエクスポートするワークショップ専用の設定に置き換えます。まず、追加する内容を確認しましょう +デフォルトのコレクター設定は汎用的なものです。これを、AppDynamics エージェントからの OTLP を受信して Splunk Observability Cloud にエクスポートするワークショップ固有の設定に置き換えます。まず、追加する内容を確認しましょう ```bash vim ~/workshop/appd/collector-config.yaml @@ -95,26 +95,26 @@ vim ~/workshop/appd/collector-config.yaml {{% /tab %}} {{% /tabs %}} -これらのプロセッサーは、`host.name` と `deployment.enviroment`/`deployment.environment.name`（推奨）属性の変数を正しく参照するようにします。 +これらのプロセッサーは、`host.name` と `deployment.enviroment`/`deployment.environment.name`（推奨）属性に対して変数を正しく参照するようにします。 -`transform/drop_dims_high_cardinality` プロセッサーは [OpenTelemetry Transformation Language (OTTL)](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/LANGUAGE.md) を使用して、34を超える属性を持つメトリクスをチェックします（メトリクスに付与される実際の値もポイントとしてカウントされます）。 +`transform/drop_dims_high_cardinality` プロセッサーは、[OpenTelemetry Transformation Language (OTTL)](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/LANGUAGE.md) を使用して、メトリクスの属性が34を超えていないかチェックします（メトリクスに付加される実際の値もポイントとしてカウントされます）。 -- **重要: 現在、属性が多すぎる（36を超える）メトリクスはバックエンドでドロップされます。** AppDynamics テレメトリでは追加の属性により、この問題が発生する可能性があります。 +- **重要: 現在、バックエンドでは属性が多すぎるメトリクス（>36）はドロップされます。** これは、AppDynamics テレメトリーの追加属性により発生する可能性があります。 -`transform` 設定では、メトリクスの属性の合計が34を超えているかどうかを確認し、超えている場合は価値が低い可能性のある属性を段階的に削除します。 -最後に、空きスペースを確認した後 `cardinality.trimmed` ディメンションを追加し、属性が削除されたメトリクスを簡単に識別できるようにします。 +`transform` の設定では、メトリクスの結合属性数が34を超えているかどうかをチェックし、超えている場合は重要度の低い属性を段階的に削除します。 +最後に、空きスペースを確認した上で `cardinality.trimmed` ディメンションを追加し、属性が削除されたメトリクスを簡単に識別できるようにします。 -これらの各プロセッサーは、設定内のメトリクス用 `pipeline:` の末尾に含まれています。 +これらのプロセッサーはそれぞれ、設定内のメトリクス用 `pipeline:` の末尾に含まれています。 -次に、カスタム設定を `agent_config.yaml` に上書きコピーします +次に、そのカスタム設定を `agent_config.yaml` にコピーします ```bash sudo cp ~/workshop/appd/collector-config.yaml /etc/otel/collector/agent_config.yaml ``` -## Collector 環境変数の設定 +## コレクターの環境変数の設定 -Collector サービスは設定ファイルから環境変数を読み取ります。Splunk OTel Collector バイナリには `SPLUNK_REALM` と `SPLUNK_ACCESS_TOKEN`（`SPLUNK_` プレフィックス付き）が必要です。インスタンスには `REALM` と `ACCESS_TOKEN` があるため、それらをマッピングします +コレクターサービスは設定ファイルから環境変数を読み取ります。Splunk OTel Collector バイナリは `SPLUNK_REALM` と `SPLUNK_ACCESS_TOKEN`（`SPLUNK_` プレフィックス付き）を必要とします。インスタンスには `REALM` と `ACCESS_TOKEN` があるため、それらをマッピングします ```bash sudo bash -c "cat > /etc/otel/collector/splunk-otel-collector.conf << EOF @@ -132,9 +132,9 @@ SPLUNK_COLLECTD_DIR=/usr/lib/splunk-otel-collector/agent-bundle/run/collectd EOF" ``` -## Collector の再起動 +## コレクターの再起動 -新しい設定を反映するために再起動します +新しい設定を適用するために再起動します {{< tabs >}} {{% tab title="Command" %}} @@ -146,7 +146,7 @@ sudo systemctl restart splunk-otel-collector {{% /tab %}} {{< /tabs >}} -## Collector の動作確認 +## コレクターの動作確認 {{< tabs >}} {{% tab title="Command" %}} @@ -173,18 +173,22 @@ sudo systemctl status splunk-otel-collector --no-pager {{% tab title="Command" %}} ```bash -curl -s http://localhost:13133/ +curl -s http://localhost:13133/ | jq ``` {{% /tab %}} {{% tab title="Example Output" %}} ```text -splunk@ip-172-31-77-108 ~/workshop/appd $ curl -s http://localhost:13133/ -{"status":"Server available","upSince":"2026-03-09T21:25:53.277371609Z","uptime":"22.684480311s"}% +splunk@ip-172-31-47-33 ~/workshop/appd $ curl -s http://localhost:13133/ | jq +{ + "status": "Server available", + "upSince": "2026-05-04T16:02:29.509202038Z", + "uptime": "30.174963775s" +} ``` {{% /tab %}} {{< /tabs >}} -Collector はポート **4317**（gRPC）と **4318**（HTTP）で OTLP をリッスンしています。 +コレクターは現在、ポート **4317**（gRPC）と **4318**（HTTP）で OTLP をリッスンしています。 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 dd8f2b1368..f2fd60e9b2 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,28 +1,28 @@ --- -title: 2. Dual Mode の有効化 +title: 2. デュアルモードの有効化 weight: 2 --- -JVM コマンドラインに Dual Signal Mode フラグを追加して、アプリケーションを再起動します。 +JVM コマンドラインにデュアルシグナルモードのフラグを追加して、アプリケーションを再起動します。 -## 実行中のアプリケーションの停止 +## 実行中のアプリケーションを停止する -Phase 1 のアプリとロードジェネレーターを停止します。 +フェーズ 1 で起動したアプリケーションとロードジェネレーターを停止します: ```bash kill %2 2>/dev/null # stop load generator kill %1 2>/dev/null # stop the java app ``` -{{% notice title="Tip" style="primary" icon="lightbulb" %}} +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} `kill %1` が動作しない場合は、`ps aux | grep ingest-workshop` で PID を確認し、直接 kill してください。 {{% /notice %}} -## Dual Mode での再起動 +## デュアルモードで再起動する -同じ AppD フラグに加えて、Dual Mode と OTel エクスポーターのフラグを追加してアプリを再度実行します。Phase 1 で設定した `${APPD_ACCESS_KEY}` と `${APPD_APP_NAME}` の変数を同じ値で使用します。 +同じ AppD フラグに加えて、デュアルモードと OTel エクスポーターのフラグを追加してアプリケーションを再度実行します。フェーズ 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 @@ -44,17 +44,18 @@ java -javaagent:agent/javaagent.jar \ ``` Spring Boot の起動バナーが表示されるまで待ちます。 +Enter キーを押してプロンプトに戻ります。 ### 新しいフラグの説明 | フラグ | 目的 | |---|---| -| `-Dagent.deployment.mode=dual` | Dual Signal Mode を有効にします。完全な OTel Java 自動インストルメンテーションが AppD エージェントと並行して動作します | -| `-Dotel.traces.exporter=otlp` | OTel インストルメンテーションに OTLP 経由でスパンをエクスポートするよう指示します | -| `-Dotel.exporter.otlp.endpoint` | ローカルの OTel Collector のポート 4318（HTTP/protobuf）を指定します | -| `-Dotel.resource.attributes` | OTel リソース属性を設定します。`service.name` は AppD ティアに、`service.namespace` は AppD アプリケーションに、`deployment.environment` はワークショップインスタンスのデータにタグ付けされます | +| `-Dagent.deployment.mode=dual` | デュアルシグナルモードを有効にします。完全な 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 ティアに、`service.namespace` は AppD アプリケーションに、`deployment.environment` はワークショップインスタンスのデータにタグ付けされます | -## ロードジェネレーターの再起動 +## ロードジェネレーターを再起動する ```bash while true; do @@ -64,19 +65,19 @@ while true; do done & ``` -## Dual Mode が有効であることの確認 +## デュアルモードが有効であることを確認する -アプリケーションログで Dual Mode が開始されたことを確認します。 +アプリケーションログでデュアルモードが開始されたことを確認します: {{< tabs >}} -{{% tab title="Command" %}} +{{% tab title="コマンド" %}} ```bash ps aux | grep "deployment.mode=dual" | grep -v grep ``` {{% /tab %}} -{{% tab title="Example Output" %}} +{{% tab title="出力例" %}} ```text splunk@ip-172-31-77-108 ~/workshop/appd $ ps aux | grep "deployment.mode=dual" | grep -v grep @@ -88,8 +89,8 @@ splunk 181598 172 2.1 14402900 717736 pts/0 SNl 21:31 1:02 java -javaage `deployment.mode=dual` フラグが付いた Java プロセスが表示されるはずです。 -AppDynamics エージェントは以下のデータを送信しています。 +AppDynamics エージェントは以下のデータを送信しています: -- **AppD APM データ** を AppDynamics Controller に送信（変更なし） -- **OTLP トレース** をローカルの OTel Collector（`localhost:4318`）に送信し、Splunk Observability Cloud に転送します +- **AppD APM データ** を AppDynamics Controller へ（変更なし） +- **OTLP トレース** をローカルの OTel Collector (`localhost:4318`) へ。そこから Splunk Observability Cloud に転送されます - インスタンスで `env` を実行すると、環境 `deployment.environment=${INSTANCE}-appd-dual` に使用される `{INSTANCE}` の値を確認できます diff --git a/content/ja/ninja-workshops/18-agentic-ai/1-connect-to-instance.md b/content/ja/ninja-workshops/18-agentic-ai/1-connect-to-instance.md index 60be78b1d0..203fcf3bd5 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/1-connect-to-instance.md +++ b/content/ja/ninja-workshops/18-agentic-ai/1-connect-to-instance.md @@ -5,25 +5,67 @@ weight: 1 time: 5 minutes --- -## EC2 インスタンスへの接続 +## EC2 インスタンスに接続する -各参加者用に AWS/EC2 に Ubuntu Linux インスタンスを用意しています。 +各参加者用に AWS/EC2 上に Ubuntu Linux インスタンスを用意しています: -インストラクターから提供された IP アドレスとパスワードを使用して、以下のいずれかの方法で EC2 インスタンスに接続してください +* お住まいのリージョンのリンクをクリックして **Splunk Show** イベントにアクセスします +* 右上の **Enroll** をクリックします +* ページ下部付近で EC2 インスタンスの詳細を確認します + +以下のような接続情報が表示されます: + +![Connection Information](../images/ConnectionInformation.png) + +**Connection Information** に記載されている IP アドレス（**SSH Command** の一部）と **SSH Password** を使用して、以下のいずれかの方法で EC2 インスタンスに接続します: * Mac OS / Linux * ssh splunk@IP address * Windows 10+ - * OpenSSH クライアントを使用してください -* 以前のバージョンの Windows - * Putty を使用してください + * OpenSSH クライアントを使用します +* それ以前のバージョンの Windows + * Putty を使用します + +{{% notice title="VPN 接続" style="green" icon="running" %}} + +オフィスから作業していて接続に問題がある場合は、まず企業 VPN に接続してみてください。 + +{{% /notice %}} ## インスタンス名の取得 -ssh で EC2 インスタンスにログインしたら、以下のコマンドを使用してインスタンス名を取得してください +SSH で EC2 インスタンスにログインしたら、以下のコマンドでインスタンス名を取得します: ```bash echo $INSTANCE ``` -このインスタンス名はあなた固有のものであり、ワークショップの後半で Splunk Observability Cloud でデータを検索する際に使用するため、メモしておいてください。 +この名前をメモしておいてください。インスタンス名はあなた固有のもので、ワークショップの後半で Splunk Observability Cloud 上のデータを検索する際に使用します。 + +## Visual Studio Code の接続（オプション） + +このワークショップでは複数のファイルを編集します。ワークショップの手順には `vi` エディタを使用するためのヒントが含まれており、参加者は `nano` エディタも使用できます。 + +本格的な IDE を使用したい場合は、ノート PC 上の Visual Studio Code から EC2 インスタンス上のリモートファイルを編集できます。 + +手順の概要は以下のとおりです: + +1. [このリンク](https://code.visualstudio.com/download)から VS Code をダウンロードしてインストールします。 +2. VS Code で **Settings** に移動し、**Extensions** を開きます。 +3. **Remote – SSH extension**（Microsoft 製）を検索してインストールします。 + +![Install Remote SSH Extension](../images/InstallRemoteSSH.png) + +4. F1 キー（Windows では Ctrl+Shift+P / Mac OS では Cmd+Shift+P）を押します。 +5. **Remote-SSH: Connect to Host** を実行します。 +6. Splunk Show から SSH コマンドをコピーします: `ssh -p 2222 splunk@EC2_PUBLIC_IP` +7. プロンプトが表示されたら、デフォルトの SSH 設定ファイルを選択します。 +8. 再度 F1 キー（Windows では Ctrl+Shift+P / Mac OS では Cmd+Shift+P）を押します。 +9. **Remote-SSH: Connect to Host** を実行します。 +10. 先ほど追加したホストを選択します。VS Code が新しいウィンドウを開き、接続を開始します。 +11. VS Code の上部に **SSH password** の入力を求めるプロンプトが表示されます。Splunk Show からパスワードをコピーして入力します。 +12. **Open Folder** をクリックし、フォルダ名として `/home/splunk` を入力します: + +![Open Remote Folder](../images/OpenRemoteFolder.png) + +これで VS Code を使用してリモートでファイルを編集できます！ diff --git a/content/ja/ninja-workshops/18-agentic-ai/10-add-ai-defense-instrumentation.md b/content/ja/ninja-workshops/18-agentic-ai/10-add-ai-defense-instrumentation.md index ad4492ed07..929364df6c 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/10-add-ai-defense-instrumentation.md +++ b/content/ja/ninja-workshops/18-agentic-ai/10-add-ai-defense-instrumentation.md @@ -1,55 +1,65 @@ --- -title: AI Defense 計装の追加 -linkTitle: 10. AI Defense 計装の追加 +title: AI Defense インストルメンテーションの追加 +linkTitle: 10. AI Defense インストルメンテーションの追加 weight: 10 time: 15 minutes --- -> 注意: このセクションでは複数のファイルを変更する必要があります。 -> 変更箇所がわからない場合やアプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-ai-defense` フォルダにある -> モデルソリューションを参照してください。 +> 注: このワークショップのセクションでは、複数のファイルを変更する必要があります。 +> どこを変更すればよいかわからない場合や、アプリケーションが +> 動作しなくなった場合は、このセクションの期待される解答である +> `~/workshop/agentic-ai/app-with-ai-defense` フォルダーを参照してください。 Splunk Observability Cloud は [Cisco AI Defense](https://www.cisco.com/site/us/en/products/security/ai-defense/index.html) -と統合し、AI エージェントの実行時に検出された[セキュリティおよびプライバシーリスク](https://securitydocs.cisco.com/docs/ai-def/user/105473.dita)の統合ビューを提供します。これにより、パフォーマンスとリスクを一か所で監視できます。 +と統合し、AI エージェントのランタイムで検出された[セキュリティおよびプライバシーリスク](https://securitydocs.cisco.com/docs/ai-def/user/105473.dita)の統合ビューを提供します。これにより、パフォーマンスとリスクを一箇所で監視できます。 -これは **Splunk AI Security Monitoring** と呼ばれ、以下のことが可能になります: +これは **Splunk AI Security Monitoring** と呼ばれ、以下のことに役立ちます: -* プロンプトインジェクションや PII 漏洩など、検出またはブロックされたセキュリティおよびプライバシーリスクに関与するエージェント、インタラクション、サービスを特定する -* リスクの傾向をレイテンシー、エラー、その他のパフォーマンスメトリクスとともに経時的に追跡する -* トレースコンテキストでリスクのあるインタラクションを、特定のプロンプトとレスポンスのレベルまで調査する +* プロンプトインジェクションや PII 漏洩など、検出またはブロックされたセキュリティおよびプライバシーリスクに関連するエージェント、インタラクション、サービスを特定する +* リスクの傾向をレイテンシー、エラー、その他のパフォーマンスメトリクスとともに時系列で追跡する +* トレースコンテキスト内でリスクのあるインタラクションを、特定のプロンプトやレスポンスまで掘り下げて調査する -このセクションでは、Agentic AI アプリケーションに AI Defense インテグレーションを追加し、Splunk Observability Cloud で得られたデータを確認します。 +このセクションでは、Agentic AI アプリケーションに AI Defense インテグレーションを追加し、 +Splunk Observability Cloud で得られたデータを確認します。 ## 仕組み -Splunk AI Security Monitoring は、Python ベースの AI エージェントのセキュリティおよびプライバシーリスクのトレーシングを自動化する計装ライブラリ +Splunk AI Security Monitoring は、Python ベースの AI エージェント向けに +セキュリティおよびプライバシーリスクのトレーシングを自動化するインストルメンテーションライブラリ [opentelemetry-instrumentation-aidefense](https://github.com/signalfx/splunk-otel-python-contrib/tree/main/instrumentation-genai/opentelemetry-instrumentation-aidefense) -を提供しています。このライブラリは、AI エージェントが LLM（OpenAI など）やオーケストレーションフレームワーク（LangChain など）に対して行う呼び出しにセキュリティテレメトリーをキャプチャして付与し、すべてのプロンプトとレスポンスがセキュリティガードレールに対して監査され、統合された OpenTelemetry トレース内に記録されるようにします。これは、LLM またはワークフロースパンに `gen_ai.security.event_id attribute` を追加することで実現されます。 +を提供します。 +このライブラリは、AI エージェントが LLM（OpenAI など）やオーケストレーションフレームワーク +（LangChain など）に対して行う呼び出しに対してセキュリティテレメトリをキャプチャし付与することで、 +すべてのプロンプトとレスポンスがセキュリティガードレールに対して監査され、 +統合された OpenTelemetry トレース内に記録されるようにします。これは LLM またはワークフローの span に +`gen_ai.security.event_id attribute` を追加することで実現されます。 -## SDK モードと Gateway モード +## SDK モード vs. Gateway モード `opentelemetry-instrumentation-aidefense` ライブラリは、SDK モードまたは Gateway モードのいずれかで動作できます: -* SDK モードでは、開発者が `inspect_prompt()` を使用して明示的なセキュリティチェックを追加します。このオプションは、セキュリティチェックの実装方法と問題への対処方法を完全に制御したい開発者に最適です。 -* Gateway モードでは、LLM 呼び出しが Cisco AI Defense Gateway を経由してプロキシされるため、アプリケーションコードの変更は不要です。このモードは、OpenAI、Anthropic などの一般的な商用 LLM でサポートされています。 +* SDK モードでは、開発者が `inspect_prompt()` を使用して明示的なセキュリティチェックを追加します。このオプションは、セキュリティチェックの実装方法や問題への対処方法を完全に制御したい開発者に最適です。 +* Gateway モードでは、LLM 呼び出しが Cisco AI Defense Gateway を経由してプロキシされるため、アプリケーションのコード変更は不要です。このモードは、OpenAI、Anthropic など、一般的な商用 LLM でサポートされています。 -このワークショップでは、Azure OpenAI を使用した Gateway モードを利用します。 +このワークショップでは、Azure OpenAI で Gateway モードを使用します。 ## Cisco AI Defense インテグレーションのセットアップ -最初のステップは、[Cisco AI Defense とのインテグレーションのセットアップ](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-security-monitoring/set-up-an-integration-with-cisco-ai-defense)です。 +最初のステップは、[Cisco AI Defense とのインテグレーションをセットアップ](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-security-monitoring/set-up-an-integration-with-cisco-ai-defense)することです。 -**Data Management -> Deployed integrations** に移動し、`AI Defense` を検索すると、このインテグレーションが既に設定されていることが確認できます: +**Data Management -> Deployed integrations** に移動し `AI Defense` を検索すると、 +このインテグレーションがすでに設定されていることがわかります: -> 注意: このインテグレーションを表示するには、`aiDefenseIntegration` フィーチャーフラグが有効になっている必要があります +> 注: このインテグレーションを表示するには、`aiDefenseIntegration` フィーチャーフラグが有効になっている必要があります ![AI Defense Config](../images/AIDefenseConfig.png) -## 計装パッケージの追加 +## インストルメンテーションパッケージの追加 -次に、いくつかの計装パッケージをインストールする必要があります。`~/workshop/agentic-ai/base-app/requirements.txt` を開いて編集し、以下のパッケージを追加します: +次に、いくつかのインストルメンテーションパッケージをインストールする必要があります。 +`~/workshop/agentic-ai/base-app/requirements.txt` を開いて編集し、 +以下のパッケージを追加します: ```` # AI Defense instrumentation (Gateway Mode support in v0.2.0+) @@ -60,7 +70,7 @@ cisco-aidefense-sdk>=2.0.0 httpx>=0.24.0 ```` -> ヒント: 以下のコマンドを実行して、変更内容をモデルソリューションと比較できます: +> ヒント: 以下のコマンドを実行して、変更内容を期待される解答と比較してください: > > `diff ~/workshop/agentic-ai/base-app/requirements.txt ~/workshop/agentic-ai/app-with-ai-defense/requirements.txt` @@ -74,19 +84,24 @@ docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-ai docker push localhost:9999/agentic-ai-app:app-with-ai-defense ``` -### AI Defense Gateway 用の Secret の作成 +> ヒント: イメージのビルドに時間がかかりすぎる場合は、ビルド済みの +> イメージの使用を検討してください。その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルの +> イメージ名を `localhost:9999/agentic-ai-app:app-with-ai-defense` の代わりに +> `ghcr.io/splunk/agentic-ai-app:app-with-ai-defense` に変更してください。 -AI Defense Gateway の URL を保存するための Secret を作成します: +### AI Defense Gateway のシークレットの作成 -> 注意: Secret の作成時に使用する実際の AI Defense URL はワークショップの講師から提供されます +ワークショップインストラクターから提供されたドキュメントには、AI Defense Gateway の URL を +保存するシークレットを作成するための `kubectl create secret` コマンドが記載されています。 -```bash -kubectl create secret generic ai-defense-secret -n travel-agent --from-literal=ai-defense-gateway-url='https://us.gateway.aidefense.security.cisco.com/{tenant}/connections/{conn}' -``` +ドキュメントからこの `kubectl create secret` コマンドをコピーして、 +SSH ターミナルで実行してください。 ### Kubernetes マニフェストの更新 -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集し、`AZURE_OPENAI_ENDPOINT` 環境変数の定義を以下のように置き換えます。これにより、Azure OpenAI 宛てのリクエストが代わりに AI Defense Gateway を経由して送信されるようになります: +`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集し、 +`AZURE_OPENAI_ENDPOINT` 環境変数の定義を以下のように置き換えます。 +これにより、Azure OpenAI 宛てのリクエストが代わりに AI Defense Gateway を経由して送信されるようになります: ```yaml - name: AZURE_OPENAI_ENDPOINT @@ -96,13 +111,13 @@ kubectl create secret generic ai-defense-secret -n travel-agent --from-literal=a key: ai-defense-gateway-url ``` -同じファイルで、計装を含むイメージを使用するようにイメージを更新します: +同じファイルで、インストルメンテーション付きのイメージを使用するようにイメージを更新します: ```yaml image: localhost:9999/agentic-ai-app:app-with-ai-defense ``` -> ヒント: 以下のコマンドを実行して、変更内容をモデルソリューションと比較できます: +> ヒント: 以下のコマンドを実行して、変更内容を期待される解答と比較してください: > > `diff ~/workshop/agentic-ai/base-app/k8s.yaml ~/workshop/agentic-ai/app-with-ai-defense/k8s.yaml` @@ -116,17 +131,17 @@ kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml ### Kubernetes でのアプリケーションのテスト -新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します: +新しいアプリケーション Pod が正常に起動し、古い Pod が存在しないことを確認します: {{< tabs >}} -{{% tab title="Script" %}} +{{% tab title="スクリプト" %}} ``` bash kubectl get pods -n travel-agent ``` {{% /tab %}} -{{% tab title="Example Output" %}} +{{% tab title="出力例" %}} ```` NAME READY STATUS RESTARTS AGE @@ -149,4 +164,5 @@ curl http://travel-planner.localhost/travel/plan \ }' ``` -現時点では、アプリケーションが引き続き動作していることを確認してください。次のセクションでは、セキュリティリスクを追加し、それがどのように検出されるかを確認します。 +ここでは、アプリケーションがまだ動作していることを確認するだけで構いません。次のセクションでは、 +セキュリティリスクを追加し、それがどのように検出されるかを確認します。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/11-detect-security-risks.md b/content/ja/ninja-workshops/18-agentic-ai/11-detect-security-risks.md index 8f1dd035f2..8931f7a989 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/11-detect-security-risks.md +++ b/content/ja/ninja-workshops/18-agentic-ai/11-detect-security-risks.md @@ -1,14 +1,14 @@ --- title: セキュリティリスクの検出 -linkTitle: 11. セキュリティリスクの検出 +linkTitle: 11. Detect Security Risks weight: 11 time: 15 minutes --- -> 注意: このセクションでは複数のファイルを変更する必要があります。 -> 変更箇所がわからない場合やアプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-security-risk` フォルダにある -> モデルソリューションを参照してください。 +> 注意: このワークショップのセクションでは、複数のファイルを変更する必要があります。 +> どこを変更すべきか分からない場合や、アプリケーションが正常に +> 動作しなくなった場合は、`~/workshop/agentic-ai/app-with-security-risk` フォルダにある +> このセクションの模範解答を参照してください。 前のセクションでは、アプリケーションエージェントの1つの出力に品質問題を注入するラッパーを追加しました。 @@ -20,9 +20,11 @@ time: 15 minutes Activity Specialist エージェントがこのラッパーを使用して LLM の出力を変更するように修正しましょう。 -`~/workshop/agentic-ai/base-app/main.py` ファイルを開いて編集します。 +`~/workshop/agentic-ai/base-app/main.py` ファイルを編集用に開きます。 -`activity_specialist_node` 関数の定義を以下のバージョンに置き換えます。これは、LLM がレスポンスの一部としてユーザーのクレジットカード番号を含めるシナリオを効果的にシミュレートしており、明らかなセキュリティリスクおよび PCI 違反です。 +`activity_specialist_node` 関数の定義を以下のバージョンに置き換えます。 +これは、LLM がレスポンスの一部としてユーザーのクレジットカード番号を +含めてしまうシナリオを効果的にシミュレートするもので、明らかなセキュリティリスクおよび PCI 違反です。 > ヒント: `vi` エディタで大量の行を一括削除するには、`Shift` + `v` を押して `Visual > Line` モードにし、下矢印キーで削除したい行をすべて選択してから、`d` @@ -76,7 +78,7 @@ def activity_specialist_node( return state ``` -> ヒント: 以下のコマンドを実行して、変更内容をモデルソリューションと比較できます: +> ヒント: 以下のコマンドを実行して、変更内容を模範解答と比較できます: > > `diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-security-risk/main.py` @@ -90,9 +92,15 @@ docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-se docker push localhost:9999/agentic-ai-app:app-with-security-risk ``` +> ヒント: イメージのビルドに時間がかかりすぎる場合は、ビルド済みの +> イメージの使用を検討してください。その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルの +> イメージ名を `localhost:9999/agentic-ai-app:app-with-security-risk` の代わりに +> `ghcr.io/splunk/agentic-ai-app:app-with-security-risk` に更新してください。 + ### Kubernetes マニフェストの更新 -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集し、セキュリティリスクを含むイメージを使用するようにイメージを更新します: +`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを編集用に開き、 +セキュリティリスクを含むイメージを使用するようにイメージを更新します: ```yaml image: localhost:9999/agentic-ai-app:app-with-security-risk @@ -108,7 +116,7 @@ kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml ### Kubernetes でのアプリケーションのテスト -新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します: +新しいアプリケーション Pod が正常に起動し、古い Pod が存在しないことを確認します: {{< tabs >}} {{% tab title="Script" %}} @@ -143,21 +151,25 @@ curl http://travel-planner.localhost/travel/plan \ ## Cisco AI Defense でのイベントの確認 -AI Defense アプリケーションに直接ログインすると、リクエストに対してイベントが記録されており、AI Defense がプロンプトに含まれていたクレジットカード番号を自動的にリダクトしたことが確認できます: +ワークショップの参加者は AI Defense アプリケーションに直接ログインすることはできません。 +しかし、AI Defense ダッシュボードを表示できた場合、このリクエストに対してイベントが +記録されており、プロンプトに含まれるクレジットカード番号が自動的にマスクされていることが確認できます。 ![AI Defense Events](../images/AIDefenseEvents.png) -AI Defense ではポリシーを設定して、特定の種類のセキュリティ問題を監視するかブロックするかを指定できます。今回のケースでは、PCI 関連の問題を監視のみに設定しています。 +AI Defense ではポリシーを設定して、特定の種類のセキュリティ問題を監視するかブロックするかを指定できます。今回のケースでは、PCI 関連の問題を監視のみする設定にしています。 ## Splunk Observability Cloud でのデータの確認 -Splunk Observability Cloud に戻り、トレースがどのように表示されるか確認しましょう。 +Splunk Observability Cloud に戻って、トレースがどのように表示されるか確認しましょう。 -`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認します（例: `agentic-ai-$INSTANCE`）。ページにセキュリティリスクが表示されるようになっていることがわかります。 +`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認してください +（例: `agentic-ai-$INSTANCE`）。ページにセキュリティリスクが表示されるようになったことが分かります。 ![Agents with Security Risks](../images/AgentsWithSecurityRisks.png) -> `AI overview` ページや `plan_synthesizer` エージェントの `AI agent` ページにもセキュリティリスクが表示されます。 +> `AI overview` ページや、`plan_synthesizer` エージェントの `AI agent` ページでも +> セキュリティリスクが表示されるはずです。 `APM -> AI trace data` に移動し、最新のトレースを読み込みます。 @@ -165,11 +177,12 @@ Splunk Observability Cloud に戻り、トレースがどのように表示さ ![Agent Flow With Security Risk](../images/AgentFlowWithSecurityRisk.png) -`activity_specialist` エージェントの `invoke_agent` スパンを見ると、LLM がレスポンス内で顧客のクレジットカード番号を平文で開示したため、PCI セキュリティリスクが検出されブロックされたことがわかります: +`activity_specialist` エージェントの `invoke_agent` スパンを見ると、LLM がレスポンスで +顧客のクレジットカード番号を平文で開示したため、PCI セキュリティリスクが検出されブロックされたことが分かります: ![Trace With Security Risk](../images/TraceWithSecurityRisk.png) -セキュリティリスクをクリックすると、追加の詳細情報と、Cisco AI Defense でイベントを表示するためのリンクが表示されます: +セキュリティリスクをクリックすると、追加の詳細情報と Cisco AI Defense でイベントを表示するためのリンクが表示されます: ![Security Risk Details](../images/SecurityRiskDetails.png) diff --git a/content/ja/ninja-workshops/18-agentic-ai/12-explore-other-ai-frameworks.md b/content/ja/ninja-workshops/18-agentic-ai/12-explore-other-ai-frameworks.md index 5e7cbaf6e2..66ad58a1a2 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/12-explore-other-ai-frameworks.md +++ b/content/ja/ninja-workshops/18-agentic-ai/12-explore-other-ai-frameworks.md @@ -1,15 +1,15 @@ --- -title: その他のエージェント AI フレームワークの探索 -linkTitle: 12. その他のエージェント AI フレームワークの探索 +title: 他のエージェント AI フレームワークの探索 +linkTitle: 12. 他のエージェント AI フレームワークの探索 weight: 12 time: 15 minutes --- -このワークショップの前のセクションでは、**LangChain** と **LangGraph** を使用して構築されたエージェント AI アプリケーションを OpenTelemetry で計装することに焦点を当てました。 +このワークショップの前のセクションでは、OpenTelemetry を使用して **LangChain** と **LangGraph** で構築されたエージェント AI アプリケーションの計装に焦点を当てました。 -このセクションでは、範囲を広げて**その他の一般的なエージェント AI フレームワーク**を取り上げ、利用可能な計装アプローチの概要を説明します。 +このセクションでは、範囲を広げて **他の主要なエージェント AI フレームワーク** を取り上げ、利用可能な計装アプローチを概説します。 -大まかに言うと、エージェント AI アプリケーションを OpenTelemetry で計装するには**2つの主要なオプション**があります。最適なアプローチは、使用するフレームワークとアプリケーションに既存の計装が含まれているかどうかによって異なります。 +大まかに言うと、OpenTelemetry でエージェント AI アプリケーションを計装するには **2つの主要なオプション** があります。最適なアプローチは、使用するフレームワークとアプリケーションに既存の計装があるかどうかによって異なります。 ## 適切な計装アプローチの選択 @@ -25,11 +25,11 @@ Splunk は、以下を含む広く使用されているエージェント AI フ #### このオプションを使用する場合 -以下の場合にこのアプローチを選択します: +次の場合にこのアプローチを選択してください: * アプリケーションが上記のフレームワークのいずれかを使用している場合。 -* 最小限の設定で Splunk Observability Cloud 向けに最適化された **OpenTelemetry 計装**が必要な場合。 -* **ゼロコード**の計装体験を希望する場合。 +* 最小限の設定で Splunk Observability Cloud に最適化された **OpenTelemetry 計装** が必要な場合。 +* **ゼロコード** の計装エクスペリエンスを希望する場合。 #### 仕組み @@ -39,17 +39,17 @@ Splunk は、以下を含む広く使用されているエージェント AI フ * 追加の Splunk OpenTelemetry パッケージのインストール * 以下のようなオプション機能を有効にするための特定の環境変数の設定: - * LLM のプロンプトと補完のキャプチャ + * LLM プロンプトと補完のキャプチャ * LLM レスポンスのセマンティック品質の評価 * Cisco AI Defense との統合 -**注**: これは、ワークショップの前半で LangChain と LangGraph に使用したアプローチと同じであり、オプションのプロンプトおよび補完キャプチャも含まれています。 +**注意**: これは、ワークショップの前半で LangChain と LangGraph に使用したアプローチと同じです（オプションのプロンプトと補完のキャプチャを含む）。 ### オプション 2: サードパーティ計装ライブラリ -フレームワークが Splunk OpenTelemetry 計装で**直接サポートされていない**場合は、より広範なフレームワークカバレッジを提供するサードパーティライブラリを使用できます。 +フレームワークが Splunk OpenTelemetry 計装で **直接サポートされていない** 場合は、より広いフレームワークカバレッジを提供するサードパーティライブラリを使用できます。 -一般的に使用されるサードパーティ計装ライブラリには以下があります: +よく使用されるサードパーティ計装ライブラリには以下があります: * [LangSmith](https://docs.langchain.com/langsmith/observability): * [OpenLIT](https://docs.openlit.io/latest/sdk/overview) @@ -57,38 +57,38 @@ Splunk は、以下を含む広く使用されているエージェント AI フ #### このオプションを使用する場合 -このアプローチは以下の場合に適しています: +このアプローチは次の場合に適しています: * アプリケーションがオプション 1 に記載されていないエージェント AI フレームワークを使用している場合 -* アプリケーションがサードパーティ計装ライブラリで**すでに計装されている**場合 +* アプリケーションがサードパーティ計装ライブラリで **既に計装されている** 場合 * 既存のコードの再計装を避けたい場合 #### 仕組み サードパーティライブラリは通常、独自のフォーマットまたは以前の OpenTelemetry スキーマでテレメトリを出力します。このデータを Splunk Observability Cloud と統合するには: -1. 出力されたテレメトリを最新の OpenTelemetry セマンティック規約に変換する**変換レイヤー**を有効にします。 +1. 出力されたテレメトリを最新の OpenTelemetry セマンティック規約に変換する **変換レイヤー** を有効にします。 2. OpenTelemetry Collector を以下のように設定します: * 変換されたデータを受信する * Splunk Observability Cloud にエクスポートする -手順の詳細については、以下を参照してください: +詳細な手順については、以下を参照してください: [Translate and collect data from AI applications instrumented with third-party libraries](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-monitoring/set-up-ai-agent-monitoring/translate-data-from-third-party-instrumentation-libraries) ### まとめ | シナリオ | 推奨オプション | |--------------------------------------|-----------------------------------------| -| サポートされているフレームワーク、最小限のセットアップ | Splunk OpenTelemetry 計装 | -| サポートされていないフレームワーク | サードパーティ計装ライブラリ | +| サポート対象フレームワーク、最小限のセットアップ | Splunk OpenTelemetry 計装 | +| サポート対象外のフレームワーク | サードパーティ計装ライブラリ | | 既存のサードパーティ計装 | サードパーティ + OpenTelemetry 変換 | ## CrewAI の例 -CrewAI を使用した例を見ていきましょう。ワークショップで使用してきた旅行プランナーアプリケーションは、CrewAI を使用して書き直されています。ソースコードは `~/workshop/agentic-ai/crewai` フォルダにあります。 +CrewAI を使用した例を見ていきましょう。ワークショップで使用してきたトラベルプランナーアプリケーションは、CrewAI を使って書き直されています。ソースコードは `~/workshop/agentic-ai/crewai` フォルダにあります。 -CrewAI は宣言的なアプローチを使用してエージェントとタスクを定義することに注意してください。例えば、`~/workshop/agentic-ai/crewai/config/agents.yaml` ファイルでは、以下のようなエージェントが定義されています: +CrewAI は宣言的なアプローチでエージェントとタスクを定義することに注意してください。例えば、`~/workshop/agentic-ai/crewai/config/agents.yaml` ファイルでは、以下のようなエージェントが定義されています: ```yaml coordinator: @@ -125,7 +125,7 @@ coordinate_trip: agent: coordinator ``` -CrewAI アプリケーションを計装するために、以下のパッケージが `requirements.txt` ファイルに追加されていることに注目してください: +CrewAI アプリケーションを計装するために、`requirements.txt` ファイルに以下のパッケージが追加されていることに注目してください: ```` splunk-opentelemetry==2.8.0 @@ -136,9 +136,9 @@ splunk-otel-util-genai==0.1.9 opentelemetry-instrumentation-flask==0.59b0 ```` -### CrewAI の例をデプロイする +### CrewAI の例のデプロイ -まず、新しい Docker イメージをビルドして CrewAI の例をデプロイしましょう: +まず新しい Docker イメージをビルドして、CrewAI の例をデプロイしましょう: ``` bash cd ~/workshop/agentic-ai/crewai @@ -146,6 +146,8 @@ docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:crewai . docker push localhost:9999/agentic-ai-app:crewai ``` +> ヒント: イメージのビルドに時間がかかりすぎる場合は、ビルド済みのイメージの使用を検討してください。その場合は、`~/workshop/agentic-ai/crewai/k8s.yaml` ファイルのイメージ名を `localhost:9999/agentic-ai-app:crewai` の代わりに `ghcr.io/splunk/agentic-ai-app:crewai` に更新してください。 + このバージョンのアプリケーションには別の環境名を使用しましょう: ```bash @@ -154,15 +156,15 @@ kubectl create configmap instance-config-crewai \ -n travel-agent ``` -次に、以下のようにマニフェストファイルを使用して CrewAI アプリケーションをデプロイします: +次に、マニフェストファイルを使用して CrewAI アプリケーションをデプロイします: ``` bash kubectl apply -f ~/workshop/agentic-ai/crewai/k8s.yaml ``` -### Kubernetes でアプリケーションをテストする +### Kubernetes でのアプリケーションのテスト -新しいアプリケーション Pod が正常に起動し、古い Pod が存在しないことを確認します: +新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します: {{< tabs >}} {{% tab title="Script" %}} @@ -195,11 +197,11 @@ curl http://travel-planner.localhost/travel/plan \ }' ``` -### Splunk Observability Cloud でデータを表示する +### Splunk Observability Cloud でのデータ表示 -Splunk Observability Cloud に戻り、CrewAI アプリケーションのトレースを表示しましょう。 +Splunk Observability Cloud に戻り、CrewAI アプリケーションのトレースを確認しましょう。 -`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認してください（例: `agentic-ai-crewai-$INSTANCE`）。エージェント名が若干異なることに気づくでしょう: +`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認してください（例: `agentic-ai-crewai-$INSTANCE`）。エージェント名が若干異なっていることに気づくでしょう: ![CrewAI Agents](../images/CrewAiAgents.png) @@ -209,15 +211,15 @@ Splunk Observability Cloud に戻り、CrewAI アプリケーションのトレ ![CrewAI Trace Details](../images/CrewAiTraceDetails.png) -CrewAI のトレースと LangChain/LangGraph のトレースで異なる点に気づきましたか？ +CrewAI のトレースと LangChain/LangGraph のトレースで何か違いに気づきましたか？
- ここをクリックして回答を表示 + クリックして回答を確認 いくつかの違いがあります: -* エージェント名が異なります（`Hotel Booking Specialist` と `hotel_specialist`） -* CrewAI バージョンでは coordinator と plan synthesizer エージェントが表示されません -* `crewai` 推定サービスのスパンには、ウォーターフォールビューの一部としてエージェントの指示が含まれています +* エージェント名が異なります（`Hotel Booking Specialist` vs. `hotel_specialist`） +* CrewAI バージョンでは coordinator と plan synthesizer エージェントがリストに表示されません +* `crewai` 推論サービスのスパンには、ウォーターフォールビューの一部としてエージェントの指示が含まれています
diff --git a/content/ja/ninja-workshops/18-agentic-ai/2-review-azure-ai-metrics.md b/content/ja/ninja-workshops/18-agentic-ai/2-review-azure-ai-metrics.md index 0dadec4c86..202e848987 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/2-review-azure-ai-metrics.md +++ b/content/ja/ninja-workshops/18-agentic-ai/2-review-azure-ai-metrics.md @@ -7,11 +7,11 @@ time: 10 minutes このワークショップでは、Azure で動作する OpenAI モデルを使用します。 -Azure OpenAI アプリケーションから Splunk Observability Cloud にメトリクスを送信するように設定することで、Azure OpenAI アプリケーションのパフォーマンスを監視できます。 +Azure OpenAI アプリケーションから Splunk Observability Cloud にメトリクスを送信するよう設定することで、Azure OpenAI アプリケーションのパフォーマンスを監視できます。 -[ドキュメント](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-infrastructure-monitoring/set-up-data-integrations/cloud-services/azure-openai)に記載されている手順に従って、ワークショップ用の Splunk Observability Cloud インスタンスと Azure アカウントの統合は既に完了しています。 +ワークショップ用の Splunk Observability Cloud インスタンスには、[ドキュメント](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-infrastructure-monitoring/set-up-data-integrations/cloud-services/azure-openai)に記載されている手順に従って、Azure アカウントとの統合が既に設定されています。 -Azure OpenAI メトリクスが含まれるようにするため、`Cognitive Services` からメトリクスを取得するように接続を設定しました +Azure OpenAI メトリクスが含まれるようにするため、`Cognitive Services` からメトリクスを取得するよう接続が設定されています ![Azure connection](../images/AzureConnection.png) @@ -29,32 +29,34 @@ Azure OpenAI では、以下のメトリクスが取得されます **Metrics** -> **Metric finder** に移動し、`ProcessedPromptTokens` メトリクスを検索して **View in chart** をクリックします -> 注: [このリンク](https://app.us1.signalfx.com/#/chart/v2/new?template=default&filters=sf_metric:ProcessedPromptTokens)を使用して **Metric finder** でこのメトリクスを表示することもできます。 +> 注意[このリンク](https://app.us1.signalfx.com/#/chart/v2/new?template=default&filters=sf_metric:ProcessedPromptTokens)を使用して **Metric finder** でこのメトリクスを表示することもできます。 ![Processed Prompt Tokens Metric](../images/ProcessedPromptTokensMetric.png) -## Azure OpenAI ナビゲーター +## Azure OpenAI Navigator -Splunk Observability Cloud は、OpenTelemetry の生成 AI クライアントおよびモデルサーバーのメトリクスを収集し、Azure で動作する Open AI 大規模言語モデル（LLM）サービスのトークン使用量を追跡します。 +Splunk Observability Cloud は、OpenTelemetry の生成 AI クライアントおよびモデルサーバーメトリクスを収集し、Azure で動作する OpenAI 大規模言語モデル（LLM）サービスのトークン使用状況を追跡します。 -これらのメトリクスは Azure OpenAI ナビゲーターを使用して確認できます。**Infrastructure** -> **Overview** -> **AI Frameworks** に移動し、**Azure OpenAI** をクリックします +これらのメトリクスは Azure OpenAI Navigator を使用して表示できます。**Infrastructure** -> **Overview** -> **AI Frameworks** に移動し、**Azure OpenAI** をクリックします。 + +**Table** タブが選択されていることを確認し、テーブル内の `gpt-4.1-mini` モデルをクリックします。以下のようなナビゲーターが表示されます ![Azure OpenAI Navigator](../images/AzureOpenAINavigator.png) -## Azure OpenAI ダッシュボード +## Azure OpenAI Dashboard -Splunk Observability Cloud は、Azure OpenAI 用の組み込みダッシュボードを提供しており、以下の項目を即座に可視化できます +Splunk Observability Cloud は、Azure OpenAI 用の組み込みダッシュボードを提供しており、以下の項目をすぐに可視化できます * アクティブな Azure OpenAI モデル * トークン使用量 * 呼び出しレイテンシー -* モデル別の呼び出し数 +* モデル別の呼び出し回数 * 最初のバイトまでの時間 -* 合計レスポンス時間 +* 合計応答時間 * モデルの可用性 * リクエストあたりのトークン数 -* モデルごとの処理済みトークン数 -* モデルごとの生成済みトークン数 +* モデル別の処理済みトークン数 +* モデル別の生成済みトークン数 **Dashboards** に移動し、**Azure OpenAI** を検索してダッシュボードを表示します diff --git a/content/ja/ninja-workshops/18-agentic-ai/3-deploy-collector.md b/content/ja/ninja-workshops/18-agentic-ai/3-deploy-collector.md index 38618d119b..839d23b30a 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/3-deploy-collector.md +++ b/content/ja/ninja-workshops/18-agentic-ai/3-deploy-collector.md @@ -5,7 +5,7 @@ weight: 3 time: 10 minutes --- -このワークショップでは、Kubernetes 上で動作する Agentic AI アプリケーションからメトリクス、トレース、ログをキャプチャするために OpenTelemetry を使用します。このセクションでは、Helm を使用して Kubernetes クラスターに OpenTelemetry Collector をインストールします。これにより、環境からメトリクス、トレース、ログをキャプチャし、Splunk に送信できるようになります。 +このワークショップでは、Kubernetes 上で動作する Agentic AI アプリケーションからメトリクス、トレース、ログをキャプチャするために OpenTelemetry を使用します。このセクションでは、Helm を使用して Kubernetes クラスターに OpenTelemetry Collector をインストールします。これにより、環境からメトリクス、トレース、ログをキャプチャし、Splunk に送信します。 ## Helm を使用して Collector をインストールする @@ -15,16 +15,16 @@ time: 10 minutes helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart ``` -次に、リポジトリが最新であることを確認します: +リポジトリが最新であることを確認します: ``` bash helm repo update ``` -Helm チャートのデプロイメントを設定するために、`/home/splunk` ディレクトリに `values.yaml` という名前の新しいファイルを作成します: +Helm チャートのデプロイを設定するために、`/home/splunk` ディレクトリに `values.yaml` という名前の新しいファイルを作成します: ``` bash -# swith to the /home/splunk dir +# switch to the /home/splunk dir cd /home/splunk # create a values.yaml file in vi vi values.yaml @@ -32,7 +32,7 @@ vi values.yaml 次に、以下の内容を貼り付けます: -> 貼り付ける前に `:set paste` と入力してください。これにより、`vi` が貼り付けたコードを自動インデントするのを防ぐことができます。 +> 貼り付ける前に `:set paste` と入力して、`vi` が貼り付けたコードを自動インデントしないようにしてください。 ``` yaml agent: @@ -42,11 +42,11 @@ agent: send_otlp_histograms: true ``` -> vi で変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力してから `enter/return` キーを押します。 +> vi で変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力してから `enter/return` キーを押してください。 -このカスタム設定により、エクスポーターが受信したヒストグラムメトリクスは、SignalFx 形式に変換されることなく OTLP 形式で Splunk Observability バックエンドに送信されます。この設定は、`gen_ai.evaluation.score` などの AI Agent Monitoring で使用されるヒストグラムメトリクスが期待通りに処理されるようにするために重要です。 +このカスタム設定により、エクスポーターが受信したヒストグラムメトリクスは、SignalFx 形式に変換されずに OTLP 形式で Splunk Observability バックエンドに送信されます。この設定は、`gen_ai.evaluation.score` などの AI Agent Monitoring で使用されるヒストグラムメトリクスが期待どおりに処理されるために重要です。 -次のコマンドを使用して Collector をインストールできます: +次のコマンドを使用して Collector をインストールします: {{< tabs >}} {{% tab title="Script" %}} @@ -83,7 +83,7 @@ Splunk OpenTelemetry Collector is installed and configured to send data to Splun ## Collector が動作していることを確認する -次のコマンドで Collector が動作しているかどうかを確認できます: +次のコマンドで Collector が動作しているか確認できます: {{< tabs >}} {{% tab title="Script" %}} @@ -110,11 +110,11 @@ splunk-otel-collector-k8s-cluster-receiver-dbf64995b-xgm9b 1/1 Running 0 ### 新しい Kubernetes エクスペリエンスを使用する場合 -O11y Cloud で新しい Kubernetes エクスペリエンスを使用するように設定されている場合は、このセクションの手順に従ってください。そうでない場合は、代わりに **従来の Kubernetes エクスペリエンスを使用する場合** のセクションを参照してください。 +O11y Cloud で新しい Kubernetes エクスペリエンスを使用するように設定されている場合は、このセクションの手順に従ってください。それ以外の場合は、**従来の Kubernetes エクスペリエンスを使用する場合** のセクションを参照してください。 Splunk Observability Cloud で、**Infrastructure** -> **Kubernetes overview** に移動し、クラスター名（`-cluster`）を追加します: -> ヒント: インスタンス名を忘れた場合は、`echo $INSTANCE` コマンドを使用してください +> ヒント: インスタンス名を忘れた場合は `echo $INSTANCE` コマンドを使用してください ![Kubernetes overview filter](../images/k8sOverviewFilter.png) @@ -126,6 +126,6 @@ Splunk Observability Cloud で、**Infrastructure** -> **Kubernetes overview** Splunk Observability Cloud で、**Infrastructure** -> **Kubernetes** -> **Kubernetes Clusters** に移動し、クラスター名（`-cluster`）を検索します: -> ヒント: インスタンス名を忘れた場合は、`echo $INSTANCE` コマンドを使用してください +> ヒント: インスタンス名を忘れた場合は `echo $INSTANCE` コマンドを使用してください ![Kubernetes cluster](../images/k8scluster.png) diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/_index.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/_index.md index 72a090a893..8577b7ffca 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/_index.md +++ b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/_index.md @@ -8,18 +8,42 @@ time: 15 minutes ## アプリケーション概要 このワークショップでは、旅行予約のための **Agentic AI** アプリケーションを使用します。 -**OpenTelemetry** でアプリケーションを計装する前に、アプリケーションの仕組みを理解しておくと役立ちます。 +このセクションでは、アプリケーションアーキテクチャを確認し、使用されている +主要な **LangChain** と **LangGraph** の概念について説明します。 + +{{% notice title="LangChain vs. LangGraph" style="green" icon="running" %}} + +**LangChain** は、プロンプト、ツール、モデル統合など、大規模言語モデルを扱うための +基本的なビルディングブロックを提供します。**LangGraph** は、これらの概念を基盤として、 +コンポーネント間の複雑でステートフルなワークフローをオーケストレーションします。 +簡単に言えば、**LangChain** は LLM を活用したステップが何をするかを定義し、 +**LangGraph** はそれらのステップがエージェントアプリケーション内でどのように +連携するかを制御します。 + +{{% /notice %}} + +このワークショップの主な目的は **OpenTelemetry** でアプリケーションを計装することですが、 +アプリケーションの構造を基本的に理解しておくことで、オブザーバビリティの作業が +より明確になります。エージェント、ツール、ワークフローがどのように構築されているかを確認することで、 +トレースとシステム分析を開始した際にテレメトリが何を表しているかを理解しやすくなります。 + +アーキテクチャの説明に沿って実装を確認したい場合は、 +EC2 インスタンス上の以下のパスでアプリケーションのソースコードを確認できます: + +`~/workshop/agentic-ai/base-app/main.py` ![Application Architecture](../images/travel-planner-app-architecture.jpg) -このアプリケーションは **Flask API** であり、旅行プランニングのリクエストを受け付け、複数の LangChain ベースの LLM ノードで構成された **LangGraph** ワークフローを通じて処理します。各ノードは特定の役割を果たし、共有ステートを更新して、次のステップに引き渡します。 +このアプリケーションは **Flask API** であり、旅行プランニングのリクエストを受け付け、 +複数の LangChain ベースの LLM ノードで構成された **LangGraph** ワークフローを通じて +処理します。各ノードは特定の役割を果たし、共有ステートを更新して、次のステップに引き継ぎます。 -ワークショップのこのパートでは、以下の内容を確認します: +このパートでは、以下の内容を確認します: -* リクエストライフサイクル +* リクエストのライフサイクル * 共有ステートモデル * LangGraph ノードの仕組み -* コードで使用されている LangChain の抽象化 -* 後の工程でオブザーバビリティが重要になる箇所 +* コード内で使用されている LangChain の抽象化 +* 後でオブザーバビリティが重要になるポイント -アプリケーションのアーキテクチャと実装の詳細については、各サブセクションに進んでください。 +サブセクションに移動して、アプリケーションアーキテクチャと実装の詳細をご確認ください。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/5-deploy-the-app.md b/content/ja/ninja-workshops/18-agentic-ai/5-deploy-the-app.md index ef92a1f246..782f37953e 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/5-deploy-the-app.md +++ b/content/ja/ninja-workshops/18-agentic-ai/5-deploy-the-app.md @@ -11,16 +11,16 @@ time: 15 minutes ### 環境変数の設定 -コマンドターミナルで、以下の環境変数を設定します。これらはアプリケーションが Azure でホストされている OpenAI モデルに接続するために使用されます: +ワークショップのインストラクターから提供されたドキュメントには、以下の環境変数を設定するための `export` コマンドが記載されています: -> 注: `AZURE_OPENAI_ENDPOINT` と `AZURE_OPENAI_API_KEY` の値はワークショップの講師から提供されます。 +* `AZURE_OPENAI_DEPLOYMENT_NAME` +* `AZURE_OPENAI_API_VERSION` +* `AZURE_OPENAI_ENDPOINT` +* `AZURE_OPENAI_API_KEY` -``` bash -export AZURE_OPENAI_DEPLOYMENT_NAME=gpt-4.1-mini -export AZURE_OPENAI_API_VERSION=2024-12-01-preview -export AZURE_OPENAI_ENDPOINT=your_azure_openai_endpoint -export AZURE_OPENAI_API_KEY=your_azure_openai_api_key -``` +これらの環境変数は、Azure でホストされている OpenAI モデルへの接続方法をアプリケーションに伝えます。 + +ドキュメントからこれらの `export` コマンドをコピーして、SSH ターミナルに貼り付けて実行してください。 ### 仮想環境の作成 @@ -43,7 +43,7 @@ python3 main.py ### アプリケーションのテスト -EC2 インスタンスに接続した2つ目のターミナルセッションを開き、以下のコマンドを実行してアプリケーションをテストします。提案された旅行プランが JSON 形式で返されます: +EC2 インスタンスに接続された2つ目のターミナルセッションを開き、以下のコマンドを実行してアプリケーションをテストします。提案された旅行プランが JSON 形式で返されるはずです: {{< tabs >}} {{% tab title="Script" %}} @@ -63,53 +63,63 @@ curl http://localhost:8080/travel/plan \ {{% tab title="Example Output" %}} ```json -{"activities_summary":"Sure! Here are signature activities for a week in Tokyo:\n\n1. Day 1: Explore Asakusa and Senso-ji Temple, then stroll Nakamise Shopping Street.\n2. Day 2: Visit Tsukiji Outer Market for fresh sushi breakfast, then tour Ginza for upscale shopping.\n3. Day 3: Spend the day in Shibuya\u2014cross the famous scramble, visit Hachiko statue, and shop in trendy boutiques.\n4. Day 4: Explore Harajuku\u2019s Takeshita Street and Meiji Shrine, followed by Omotesando\u2019s stylish cafes.\n5. Day 5: Discover Akihabara\u2019s electronics and anime culture, with a visit to a themed caf\u00e9.\n6. Day 6: Take a day trip to Odaiba for teamLab Borderless digital art museum and waterfront views.\n7. Day 7: Relax in Ueno Park, visit museums, and shop at Ameya-Yokocho market.\n\nWould you like hotel or dining recommendations as well?","agent_steps":[{"agent":"coordinator","status":"completed"},{"agent":"flight_specialist","status":"completed"},{"agent":"hotel_specialist","status":"completed"} +{"activities_summary":"Sure! Here are signature activities for a week in Tokyo:\n\n1. Day 1: Explore Asakusa and Senso-ji Temple, then stroll Nakamise Shopping Street.\n2. Day 2: Visit Tsukiji Outer Market for fresh sushi breakfast, then tour Ginza for upscale shopping.\n3. Day 3: Spend the day in Shibuya—cross the famous scramble, visit Hachiko statue, and shop in trendy boutiques.\n4. Day 4: Explore Harajuku’s Takeshita Street and Meiji Shrine, followed by Omotesando’s stylish cafes.\n5. Day 5: Discover Akihabara’s electronics and anime culture, with a visit to a themed café.\n6. Day 6: Take a day trip to Odaiba for teamLab Borderless digital art museum and waterfront views.\n7. Day 7: Relax in Ueno Park, visit museums, and shop at Ameya-Yokocho market.\n\nWould you like hotel or dining recommendations as well?","agent_steps":[{"agent":"coordinator","status":"completed"},{"agent":"flight_specialist","status":"completed"},{"agent":"hotel_specialist","status":"completed"} ``` {{% /tab %}} {{< /tabs >}} -## Agentic AI アプリケーションのデプロイ (Kubernetes) - -アプリケーションが正常に動作することを確認できたので、Kubernetes にデプロイしましょう。 +### アプリケーションの停止 -### Dockerfile の作成 +アプリケーションが正常に動作していることを確認したら、最初のターミナルに戻ってアプリケーションを停止してください。 -ビルド済みの Dockerfile が `~/workshop/agentic-ai/base-app/Dockerfile` にあります。`requirements.txt` ファイルのすべてのパッケージが Docker イメージのビルド時にインストールされることが確認できます: - -```` -RUN pip install --no-cache-dir -r requirements.txt -```` - -コンテナは以下のコマンドで起動されます: +## Agentic AI アプリケーションのデプロイ (Kubernetes) -```` -CMD ["python", "main.py"] -```` +アプリケーションが正常に動作することを確認できたので、Kubernetes にデプロイしましょう。 ### Docker イメージのビルド +このセクションでは、`~/workshop/agentic-ai/base-app/Dockerfile` にある Dockerfile を使用して、アプリケーションの Docker イメージをビルドします。以下のコマンドを実行してイメージをビルドしてください: + ``` bash cd ~/workshop/agentic-ai/base-app docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:base-app . docker push localhost:9999/agentic-ai-app:base-app ``` -### Azure 認証情報を含む Secret の作成 +> ヒント: イメージのビルドに時間がかかりすぎる場合は、ビルド済みのイメージを使用することを検討してください。その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイル内のイメージ名を `localhost:9999/agentic-ai-app:base-app` から `ghcr.io/splunk/agentic-ai-app:base-app` に変更してください。 + +### アプリケーション用 Namespace の作成 -Kubernetes の Secret を使用して Azure OpenAI のエンドポイントとキーを保存します: +アプリケーションをホストするための新しい Namespace を作成しましょう: ``` bash kubectl create ns travel-agent +``` -kubectl create secret generic azure-openai-api -n travel-agent --from-literal=azure-openai-api-endpoint=$AZURE_OPENAI_ENDPOINT --from-literal=azure-openai-api-key=$AZURE_OPENAI_API_KEY +### Azure 資格情報を含む Secret の作成 + +Kubernetes Secret を使用して、Azure OpenAI のエンドポイントとキーを保存します: + +> 注意: このコマンドは、先ほど `AZURE_OPENAI_ENDPOINT` と `AZURE_OPENAI_API_KEY` の環境変数を設定したターミナルで実行してください。 + +``` bash +{ [ -z "$AZURE_OPENAI_ENDPOINT" ] || \ + [ -z "$AZURE_OPENAI_API_KEY" ]; } && \ + echo "Error: Missing variables" || \ + kubectl create secret generic azure-openai-api \ + -n travel-agent \ + --from-literal=azure-openai-api-endpoint=$AZURE_OPENAI_ENDPOINT \ + --from-literal=azure-openai-api-key=$AZURE_OPENAI_API_KEY ``` +> 補足: Missing variables というエラーが表示された場合は、インストラクターから提供されたドキュメントの `export` コマンドを使用して、環境変数を再度設定する必要があります。 + ### Kubernetes マニフェストファイルを使用したアプリケーションのデプロイ -ビルド済みの Kubernetes マニフェストが `~/workshop/agentic-ai/base-app/k8s.yaml` にあります。 +ビルド済みの Kubernetes マニフェストは、`~/workshop/agentic-ai/base-app/k8s.yaml` というファイルにあります。 -以下のようにマニフェストファイルを使用してアプリケーションをデプロイします: +以下のようにマニフェストファイルを使用してアプリケーションをデプロイできます: ``` bash kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml @@ -117,7 +127,7 @@ kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml ### アプリケーションの実行確認 -以下のコマンドを使用して、アプリケーション Pod のステータスが `Running` であることを確認します: +以下のコマンドを使用して、アプリケーションの Pod のステータスが `Running` であることを確認してください: {{< tabs >}} {{% tab title="Script" %}} @@ -159,7 +169,7 @@ curl http://travel-planner.localhost/travel/plan \ {{% tab title="Example Output" %}} ```json -{"activities_summary":"Sure! Here are signature activities for a week in Tokyo:\n\n1. Day 1: Explore Asakusa and Senso-ji Temple, then stroll Nakamise Shopping Street.\n2. Day 2: Visit Tsukiji Outer Market for fresh sushi breakfast, then tour Ginza for upscale shopping.\n3. Day 3: Spend the day in Shibuya\u2014cross the famous scramble, visit Hachiko statue, and shop in trendy boutiques.\n4. Day 4: Explore Harajuku\u2019s Takeshita Street and Meiji Shrine, followed by Omotesando\u2019s stylish cafes.\n5. Day 5: Discover Akihabara\u2019s electronics and anime culture, with a visit to a themed caf\u00e9.\n6. Day 6: Take a day trip to Odaiba for teamLab Borderless digital art museum and waterfront views.\n7. Day 7: Relax in Ueno Park, visit museums, and shop at Ameya-Yokocho market.\n\nWould you like hotel or dining recommendations as well?","agent_steps":[{"agent":"coordinator","status":"completed"},{"agent":"flight_specialist","status":"completed"},{"agent":"hotel_specialist","status":"completed"} +{"activities_summary":"Sure! Here are signature activities for a week in Tokyo:\n\n1. Day 1: Explore Asakusa and Senso-ji Temple, then stroll Nakamise Shopping Street.\n2. Day 2: Visit Tsukiji Outer Market for fresh sushi breakfast, then tour Ginza for upscale shopping.\n3. Day 3: Spend the day in Shibuya—cross the famous scramble, visit Hachiko statue, and shop in trendy boutiques.\n4. Day 4: Explore Harajuku’s Takeshita Street and Meiji Shrine, followed by Omotesando’s stylish cafes.\n5. Day 5: Discover Akihabara’s electronics and anime culture, with a visit to a themed café.\n6. Day 6: Take a day trip to Odaiba for teamLab Borderless digital art museum and waterfront views.\n7. Day 7: Relax in Ueno Park, visit museums, and shop at Ameya-Yokocho market.\n\nWould you like hotel or dining recommendations as well?","agent_steps":[{"agent":"coordinator","status":"completed"},{"agent":"flight_specialist","status":"completed"},{"agent":"hotel_specialist","status":"completed"} ``` {{% /tab %}} @@ -167,7 +177,7 @@ curl http://travel-planner.localhost/travel/plan \ ## トラブルシューティング -トラブルシューティングが必要な場合は、以下のコマンドを使用してアプリケーションのログを確認します: +トラブルシューティングが必要な場合は、以下のコマンドを使用してアプリケーションのログを確認してください: ```bash kubectl logs -l app=travel-planner-langchain -n travel-agent -f diff --git a/content/ja/ninja-workshops/18-agentic-ai/6-instrument-the-app.md b/content/ja/ninja-workshops/18-agentic-ai/6-instrument-the-app.md index 55246f4eb3..b1c79ab241 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/6-instrument-the-app.md +++ b/content/ja/ninja-workshops/18-agentic-ai/6-instrument-the-app.md @@ -5,17 +5,16 @@ weight: 6 time: 15 minutes --- -> 注意: このセクションでは複数のファイルを変更する必要があります。 -> 変更箇所がわからない場合やアプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-instrumentation` フォルダにある -> モデルソリューションを参照してください。 +> 注意: このワークショップのセクションでは、複数のファイルを変更する必要があります。 +> どこを変更すればよいかわからない場合や、アプリケーションが動作しなくなった場合は、 +> `~/workshop/agentic-ai/app-with-instrumentation` フォルダにあるこのセクションの期待される解答を参照してください。 Agentic AI アプリケーションを OpenTelemetry で計装し、Kubernetes にデプロイするには、いくつかの手順が必要です: 1. `requirements.txt` ファイルに計装パッケージを追加する 2. `opentelemetry-instrument` を使用してアプリケーションを起動するように Dockerfile を更新する 3. 計装パッケージを含む新しい Docker イメージをビルドする -4. 環境変数を含むように Kubernetes マニフェストを更新する +4. 環境変数を使用して Kubernetes マニフェストを更新する 5. Kubernetes マニフェストをデプロイする ## 計装パッケージの追加 @@ -32,26 +31,26 @@ opentelemetry-instrumentation-flask==0.59b0 各パッケージの説明は以下のとおりです: -* `splunk-opentelemetry`: Splunk Distribution of OpenTelemetry Python です。Python アプリケーションを計装し、分散トレースをキャプチャして Splunk APM にレポートします。 -* `splunk-otel-instrumentation-langchain`: LangChain の LLM/チャットワークフロー向けの OpenTelemetry 計装を提供するパッケージです。 -* `splunk-otel-genai-emitters-splunk`: Splunk Platform でのストレージとフィルタリングを最適化するために、Evaluation Results ログの Splunk スキーマ用エミッターを提供するパッケージです。 +* `splunk-opentelemetry`: Splunk ディストリビューションの OpenTelemetry Python です。Python アプリケーションを計装し、分散トレースをキャプチャして Splunk APM に送信します。 +* `splunk-otel-instrumentation-langchain`: LangChain の LLM/チャットワークフローに対する OpenTelemetry 計装を提供するパッケージです。 +* `splunk-otel-genai-emitters-splunk`: Splunk Platform でのストレージとフィルタリングを最適化するために、Splunk スキーマの Evaluation Results ログ用エミッターを提供するパッケージです。 * `splunk-otel-util-genai`: OpenTelemetry セマンティック規約を使用した生成 AI ワークロードの計装を容易にする API とデータ型を提供するユーティリティ関数を含むパッケージです。 * `opentelemetry-instrumentation-flask`: OpenTelemetry WSGI ミドルウェアを基盤として、Flask アプリケーションの Web リクエストを追跡するライブラリです。 -> ヒント: 以下のコマンドを実行して、変更内容をモデルソリューションと比較できます: +> ヒント: 以下のコマンドを実行して、変更内容を期待される解答と比較できます: > > `diff ~/workshop/agentic-ai/base-app/requirements.txt ~/workshop/agentic-ai/app-with-instrumentation/requirements.txt` ## Dockerfile の更新 -次に、OpenTelemetry 計装を有効にする必要があります。これは、`opentelemetry-instrument` を使用してアプリケーションが起動されるように Dockerfile を更新することで行います。`~/workshop/agentic-ai/base-app/Dockerfile` ファイルを開いて編集し、最後の行を以下のように更新します: +次に、OpenTelemetry 計装を有効にする必要があります。これは、`opentelemetry-instrument` でアプリケーションが起動されるように Dockerfile を更新することで行います。`~/workshop/agentic-ai/base-app/Dockerfile` ファイルを開いて編集し、最後の行を以下のように更新します: ```dockerfile # Run the server with instrumentation CMD ["opentelemetry-instrument", "python", "main.py"] ``` -> ヒント: 以下のコマンドを実行して、変更内容をモデルソリューションと比較できます: +> ヒント: 以下のコマンドを実行して、変更内容を期待される解答と比較できます: > > `diff ~/workshop/agentic-ai/base-app/Dockerfile ~/workshop/agentic-ai/app-with-instrumentation/Dockerfile` @@ -65,13 +64,17 @@ docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-in docker push localhost:9999/agentic-ai-app:app-with-instrumentation ``` +> ヒント: イメージのビルドに時間がかかりすぎる場合は、ビルド済みのイメージを使用することを検討してください。 +> その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルのイメージ名を +> `localhost:9999/agentic-ai-app:app-with-instrumentation` の代わりに `ghcr.io/splunk/agentic-ai-app:app-with-instrumentation` に更新してください。 + ### ConfigMap の定義 -アプリケーションを Kubernetes にデプロイする際、テレメトリー（メトリクス、トレース、ログ）を明確でユニークな環境識別子とともに Splunk Observability Cloud に送信したいと考えます。これにより、異なるデプロイメント間でのフィルタリング、比較、トラブルシューティングが容易になります。 +アプリケーションを Kubernetes にデプロイする際、テレメトリ(メトリクス、トレース、ログ)を明確でユニークな環境識別子とともに Splunk Observability Cloud に送信したいと考えます。これにより、異なるデプロイメント間でデータのフィルタリング、比較、トラブルシューティングが容易になります。 これを実現するために、`deployment.environment` という名前の OpenTelemetry リソース属性を設定します。値をハードコーディングする代わりに、EC2 インスタンスに既に存在する `INSTANCE` 環境変数から値を導出します。これにより、各デプロイメントに正しい環境名が自動的にタグ付けされます。 -この設定は Kubernetes ConfigMap に保存し、後でアプリケーション Pod に環境変数として注入できるようにします。 +この設定を Kubernetes の ConfigMap に保存し、後でアプリケーション Pod に環境変数として注入できるようにします。 以下のコマンドで ConfigMap を作成します: @@ -81,27 +84,27 @@ kubectl create configmap instance-config \ -n travel-agent ``` -このコマンドが行うこと: +このコマンドの動作内容: * OpenTelemetry が期待する `OTEL_RESOURCE_ATTRIBUTES` 環境変数を定義します。 * `$INSTANCE` の値に応じて、`deployment.environment` を `agentic-ai-shw-1c43` のような値に設定します。 -* `travel-agent` namespace に ConfigMap を作成します。 +* `travel-agent` 名前空間に ConfigMap を作成します。 次のステップで Kubernetes デプロイメントを設定する際に、この ConfigMap を参照します。 ### Kubernetes マニフェストの更新 -OpenTelemetry 計装、特に AI Agent Monitoring には、計装データの収集、処理、エクスポートの方法を定義する多数の環境変数の設定が必要です。 +OpenTelemetry の計装、特に AI Agent Monitoring では、計装データの収集、処理、エクスポート方法を定義するために多数の環境変数を設定する必要があります。 -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集します。計装を含むイメージを使用するように**イメージタグ**を更新します: +`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集します。計装を含むイメージを使用するように **image タグ** を更新します: ```yaml image: localhost:9999/agentic-ai-app:app-with-instrumentation ``` -同じファイルで、`Begin: Add Environment Variables` と `End: Add Environment Variables` のコメントの間に以下の**環境変数**を追加します: +同じファイルで、`Begin: Add Environment Variables` と `End: Add Environment Variables` のコメントの間に、以下の**環境変数**を追加します: -> ヒント: 貼り付ける前に `:set paste` と入力すると、`vi` がコードを自動インデントするのを防げます。 +> ヒント: 貼り付ける前に `:set paste` と入力して、`vi` が貼り付けたコードを自動インデントしないようにしてください。 ```yaml # Begin: Add Environment Variables @@ -137,31 +140,31 @@ OpenTelemetry 計装、特に AI Agent Monitoring には、計装データの収 # End: Add Environment Variables ``` -> 注意: スクロールしないとテキストの一部が表示されない場合があります。 +> 注意: スクロールしないと一部のテキストが表示されない場合があります。 > 右上の `Copy text to clipboard` ボタンを使用して、すべてのテキストをコピーしてください。 -> 注意: YAML ではインデントが重要です。新しい環境変数が既存の環境変数と揃っていることを確認してください。 +> 注意: yaml ではインデントが重要です。新しい環境変数が既存の環境変数と揃っていることを確認してください。 -以下の環境変数は Agentic AI モニタリングに固有のもので、説明は以下のとおりです: +以下の環境変数は Agentic AI モニタリングに固有のもので、それぞれの説明は以下のとおりです: -* `OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE`: OTLP メトリクスエクスポーターが、出力するメトリクスについて累積合計、デルタ、またはメモリ効率の良いテンポラリティのどれをレポートするかを決定します。Agentic AI モニタリングでは `DELTA` に設定することが推奨されます。 +* `OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE`: OTLP メトリクスエクスポーターが、出力されるメトリクスに対して累積合計、デルタ、またはメモリ効率の良いテンポラリティのいずれでレポートするかを決定します。Agentic AI モニタリングでは `DELTA` に設定することが推奨されます。 * `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT`: Agentic AI アプリケーションからのメッセージキャプチャを有効/無効にするために使用します。このワークショップでは `true` に設定しています。 -* `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE`: メッセージのキャプチャ方法を定義します。このワークショップでは `SPAN` に設定しており、span イベントストアを使用してメッセージがキャプチャされるようにしています。 -* `OTEL_INSTRUMENTATION_GENAI_EMITTERS`: このワークショップでは `span_metric,splunk` に設定しており、span とメトリクスの両方のデータ、および Splunk 固有の機能がキャプチャされるようにしています。 +* `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE`: メッセージのキャプチャ方法を定義します。このワークショップでは `SPAN` に設定しており、スパンイベントストアを使用してメッセージがキャプチャされます。 +* `OTEL_INSTRUMENTATION_GENAI_EMITTERS`: このワークショップでは `span_metric,splunk` に設定しており、スパンとメトリクスの両方のデータ、および Splunk 固有の機能がキャプチャされます。 -> ヒント: 以下のコマンドを実行して、変更内容をモデルソリューションと比較できます: +> ヒント: 以下のコマンドを実行して、変更内容を期待される解答と比較できます: > > `diff ~/workshop/agentic-ai/base-app/k8s.yaml ~/workshop/agentic-ai/app-with-instrumentation/k8s.yaml` ### 更新されたアプリケーションのデプロイ -以下のようにマニフェストファイルを使用して、更新されたアプリケーションをデプロイできます: +マニフェストファイルを使用して、更新されたアプリケーションを以下のようにデプロイできます: ``` bash kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml ``` -### Kubernetes でのアプリケーションのテスト +### Kubernetes でのアプリケーションテスト 新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します: diff --git a/content/ja/ninja-workshops/18-agentic-ai/7-review-agent-trace-data.md b/content/ja/ninja-workshops/18-agentic-ai/7-review-agent-trace-data.md index 55b6ec89ae..43b3612c55 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/7-review-agent-trace-data.md +++ b/content/ja/ninja-workshops/18-agentic-ai/7-review-agent-trace-data.md @@ -7,48 +7,55 @@ time: 10 minutes ## LLM プロバイダー設定の確認 -Splunk Observability Cloud には、Large Language Model (LLM) を接続するためのインテグレーションが含まれています。Splunk はこの接続を使用して、アプリケーションが生成した LLM レスポンスの**セマンティック品質**を評価します。 +Splunk Observability Cloud には、Large Language Model（LLM）を接続するためのインテグレーションが含まれています。Splunk はこの接続を使用して、アプリケーションが生成した LLM レスポンスの**セマンティック品質**を評価します。 -このインテグレーションは、ワークショップの組織ですでに設定済みです。 +このインテグレーションは、ワークショップの組織で既に設定済みです。 -設定を確認するには、**Data Management → Deployed Integrations** に移動し、**LLM Providers** を検索して選択します。以下のプロバイダーが表示されるはずです +設定を確認するには、**Data Management → Deployed Integrations** に移動し、**Categories** フィルターを `LLMs` に設定します。 + +**LLM Providers** を検索して選択します。以下のプロバイダーが表示されるはずです ![LLM Providers](../images/LLMProviders.png) -`Azure OpenAI O11y Specialists` プロバイダーをクリックして詳細を表示します +`Azure OpenAI O11y Specialists` プロバイダーをクリックして詳細を確認します ![LLM Provider Details](../images/LLMProviderDetails.png) この組織では、サンプリングレートが **20%** に設定されています。これは、平均してアプリケーションが生成した **LLM レスポンスの 20%** に対して Splunk がセマンティック品質を評価することを意味します。 -**1分あたり50件の評価というレート制限**も設定されています。サンプリングレートとレート制限はどちらも、お客様のニーズに応じて調整できます。サンプリングレートを高くすると、より多くの評価データが得られますが、トークン使用量と関連コストも増加します。 +**1分あたり50件の評価というレートリミット**も設定されています。サンプリングレートとレートリミットはどちらも、お客様のニーズに応じて調整できます。サンプリングレートを高くすると、より多くの評価データが得られますが、トークンの使用量と関連コストも増加します。 ## AI Agent Monitoring 設定の確認 -Splunk Observability Cloud には、AI Agent Monitoring に関連する詳細の保存に使用するデータソースを設定するページも含まれています。選択肢は以下の通りです +Splunk Observability Cloud には、AI Agent Monitoring に関連する詳細情報の保存に使用するデータソースを設定できるページも含まれています。選択肢は以下のとおりです * Data source – Splunk Observability Cloud * Data source – Splunk logs -これらの設定は **Settings -> AI Agent Monitoring** に移動すると確認できます +これらの設定は、**Settings -> AI Agent Monitoring** に移動して確認できます ![AI Agent Monitoring Configuration](../images/AIAgentMonitoringConfiguration.png) -Splunk は、AI Agent Monitoring 関連の詳細の保存に Splunk Observability Cloud を使用することを推奨しています。このワークショップではこの設定を使用しています。 +Splunk は、AI Agent Monitoring 関連の詳細情報の保存には Splunk Observability Cloud の使用を推奨しています。このワークショップでもこの設定を使用しています。 ## AI Monitoring 権限の確認 -LLM の会話データは機密性が高い可能性があるため、この情報にアクセスして表示できるユーザーを制御するための `ai_monitoring` という新しいロールが Splunk Observability Cloud に追加されています +LLM の会話データには機密情報が含まれる可能性があるため、この情報にアクセスして閲覧できるユーザーを制御する `ai_monitoring` という新しいロールが Splunk Observability Cloud に追加されました ![AI Monitoring Role](../images/AIMonitoringRole.png) -## Splunk Observability Cloud でのトレースデータの表示 +## Splunk Observability Cloud でトレースデータを表示する + +Splunk Observability Cloud で `APM` に移動し、`Service Map` を選択します。 +ご自身の環境名が選択されていることを確認してください（例`agentic-ai-$INSTANCE`）。 + +> ヒント：インスタンス名を忘れた場合は `echo $INSTANCE` コマンドを使用してください -Splunk Observability Cloud で `APM` に移動し、`Service Map` を選択します。環境名が選択されていることを確認します（例: `agentic-ai-$INSTANCE`）。以下のようなサービスマップが表示されるはずです +以下のようなサービスマップが表示されるはずです ![Service Map](../images/ServiceMap.png) -右側のメニューで `Traces` をクリックします。次に、実行時間が長いトレースの1つを選択します。以下の例のように表示されるはずです +右側のメニューで `Traces` をクリックします。次に、実行時間の長いトレースを1つ選択します。以下の例のように表示されるはずです ![Trace](../images/Trace.png) @@ -58,8 +65,8 @@ Splunk Observability Cloud で `APM` に移動し、`Service Map` を選択し ![Trace Details](../images/TraceDetails.png) -次に、`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認します（例: `agentic-ai-$INSTANCE`）。ページが空であることに気付くでしょう。 +次に、`APM` に移動して `AI agents` を選択します。ご自身の環境名が選択されていることを確認してください（例`agentic-ai-$INSTANCE`）。ページが空であることに気づくでしょう！ ![Agents](../images/Agents.png) -これらのインストルメンテーションの問題は、次のセクションで対処します。 +これらの計装の問題については、次のセクションで対処します。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/8-add-tool-calls.md b/content/ja/ninja-workshops/18-agentic-ai/8-add-tool-calls.md index f478c121c9..0b7bdf5afc 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/8-add-tool-calls.md +++ b/content/ja/ninja-workshops/18-agentic-ai/8-add-tool-calls.md @@ -1,38 +1,38 @@ --- -title: Tool Calls の追加 -linkTitle: 8. Tool Calls の追加 +title: Tool Call の追加 +linkTitle: 8. Tool Call の追加 weight: 8 time: 15 minutes --- -> 注意: このセクションでは複数のファイルを変更する必要があります。 -> 変更箇所がわからない場合やアプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-agents-and-tools` フォルダにある -> モデルソリューションを参照してください。 +> 注意：このワークショップセクションでは、複数のファイルを変更する必要があります。 +> どこを変更すればよいかわからない場合や、アプリケーションが動作しなくなった場合は、 +> `~/workshop/agentic-ai/app-with-agents-and-tools` フォルダにあるこのセクションの +> 模範解答を参照してください。 -前のセクションでは、エージェントが新しい **Agents** ページや、トレース上部の **Agent flow** に表示されていないことがわかりました。 +前のセクションでは、エージェントが新しい **Agents** ページやトレース上部の **Agent flow** に表示されていないことを確認しました。 その理由は、現在のアプリケーションがエージェントを使用しておらず、LLM を直接呼び出しているためです。 -言い換えると、現在のアプリケーションは台本のある演劇のようなものです。すべてのセリフとアクションがコードに書かれています。LLM を呼び出す際には、特定のセリフを読み上げるよう依頼しているだけです。LLM が自ら判断を行っていないため、Observability for AI の計装はこれを自律的なエージェントとして認識しません。 +言い換えると、現在のアプリはスクリプト化された演劇のようなものです。すべてのセリフとアクションがコードに記述されています。LLM を呼び出す際は、特定のセリフを読むよう依頼しているだけです。LLM が自ら選択を行っていないため、Observability for AI の計装はこれを自律的なエージェントとして認識しません。 -次のセクションでは、LLM に**ツール**とそれらを使用する権限を与えます。エージェントモデルに移行することで、LLM は **Tool Calls** を生成するようになります。OpenTelemetry の計装がこれらのインタラクションをキャプチャし、LLM の思考プロセスとツールの使用状況を確認できるようになります。また、各エージェントが Splunk Observability Cloud に表示されるようになります。 +次のセクションでは、LLM に**ツール**とそれらの使い方を決定する権限を与えます。エージェントモデルに移行することで、LLM は **Tool Call** を生成するようになります。OpenTelemetry の計装がこれらのインタラクションをキャプチャし、LLM の思考プロセスとツールの使用状況を確認できるようになります。また、各エージェントが Splunk Observability Cloud に表示されるようになります。 ## 直接呼び出しとエージェントトレースの比較 -これらの変更を行う前に、LLM を直接呼び出した場合とエージェント経由で呼び出した場合で、トレースがどのようにキャプチャされるかを詳しく見てみましょう。 +これらの変更を行う前に、LLM を直接呼び出した場合とエージェント経由で呼び出した場合のトレースのキャプチャ方法について詳しく見ていきましょう。 -**直接呼び出しのトレース:** +**直接呼び出しのトレース** -`llm.invoke()` を呼び出すと、計装は標準的な "Chat" または "Completion" のスパンを認識します。プロンプトとレスポンスが記録されます。エージェントフレームワークによって管理される "ループ" や "ツール呼び出し" のロジックがないため、Splunk Observability Cloud はスパンを "Agent" として分類するために必要なメタデータを認識できません。 +`llm.invoke()` を呼び出すと、計装は標準的な「Chat」または「Completion」スパンを検出します。プロンプトとレスポンスが記録されます。エージェントフレームワークが管理する「ループ」や「ツール呼び出し」のロジックがないため、Splunk Observability Cloud はスパンを「Agent」として分類するために必要なメタデータを検出できません。 -**エージェントトレース:** +**エージェントトレース** -エージェント（例: `create_react_agent`）を使用すると、フレームワークは実行を特定の "Agent" および "Tool" スパンでラップします。これらのスパンには、OpenTelemetry に「これは単なるチャットではなく、特定のツールを使用した推論ループです」と伝えるメタデータが含まれています。これにより、Agents ページとトレースビジュアライゼーションの Agent Flow ダイアグラムにデータが表示されます。 +エージェント（例`create_react_agent`）を使用すると、フレームワークは実行を特定の「Agent」および「Tool」スパンでラップします。これらのスパンには、OpenTelemetry に「これは単なるチャットではなく、特定のツールを持つ推論ループです」と伝えるメタデータが含まれています。これにより、Agents ページとトレースビジュアライゼーションの Agent Flow ダイアグラムにデータが表示されます。 ## バックアップの作成 -Python コードを変更する前に、以下のコマンドで `main.py` ファイルのバックアップを作成します: +Python コードを変更する前に、以下のコマンドを使用して `main.py` ファイルのバックアップを作成します ```bash cp ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/base-app/main.py.bak @@ -40,9 +40,9 @@ cp ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/base-app/main.py ## Import 文の追加 -`~/workshop/agentic-ai/base-app/main.py` ファイルを開いて編集します。 +`~/workshop/agentic-ai/base-app/main.py` ファイルを編集用に開きます。 -`Begin: Add Import Statements` と `End: Add Import Statements` の間に以下の import 文を追加します: +`Begin: Add Import Statements` と `End: Add Import Statements` の間に、以下の import 文を追加します ```python # Begin: Add Import Statements @@ -57,7 +57,7 @@ from langchain.agents import ( ## ツールの追加 -同じ `main.py` ファイルで、`Begin: Tool Definitions` と `End: Tool Definitions` の間にツール定義を追加します: +同じ `main.py` ファイルで、`Begin: Tool Definitions` と `End: Tool Definitions` の間にツール定義を追加します ```python # Begin: Tool Definitions @@ -104,7 +104,7 @@ def mock_search_activities(destination: str) -> str: ## AI Agent Monitoring 用のアプリケーション設定 -現在、アプリケーションは以下のように LLM を作成して呼び出しています: +現在、アプリケーションは以下のように LLM を作成して呼び出しています ```python def flight_specialist_node(state: PlannerState) -> PlannerState: @@ -116,36 +116,36 @@ def flight_specialist_node(state: PlannerState) -> PlannerState: ... ``` -AI Agent Monitoring のためには、エージェント名を含むメタデータ付きのエージェントを作成し、LLM ではなくエージェントを呼び出す必要があります。 +AI Agent Monitoring では、エージェント名を含むメタデータ付きのエージェントを作成し、LLM ではなくエージェントを呼び出す必要があります。 {{% notice title="LangChain Agents" style="green" icon="running" %}} -次のステップでは、アプリケーションに**エージェント**を追加します。LangChain におけるエージェントとは具体的に何でしょうか？ +次のステップでは、アプリケーションに**エージェント**を追加します。しかし、LangChain におけるエージェントとは正確には何でしょうか？ -[LangChain のドキュメント](https://docs.langchain.com/oss/python/langchain/agents)によると: +[LangChain のドキュメント](https://docs.langchain.com/oss/python/langchain/agents)によると -「エージェントは、言語モデルとツールを組み合わせて、タスクについて推論し、使用するツールを決定し、反復的にソリューションに向かって作業するシステムを作成します。」 +「Agents は言語モデルとツールを組み合わせて、タスクについて推論し、使用するツールを決定し、反復的に解決策に向かって作業するシステムを作成します。」 -実際には、これはモデルがテキスト生成だけに限定されないことを意味します。代わりに、タスクを完了するために利用可能な**ツール**（API、データベース、コード実行など）のセットから選択できます。 +実際には、モデルはテキスト生成だけに限定されなくなることを意味します。代わりに、タスクを完了するために利用可能な**ツール**のセット（API、データベース、コード実行など）から選択できるようになります。 -このスタイルのエージェントは、一般的に **LangChain ReAct agent** と呼ばれます。 +このスタイルのエージェントは、**LangChain ReAct agent** と呼ばれることが多いです。 -ReAct は **Reasoning + Acting**（推論 + 行動）の略です。エージェントは以下のループで動作します: +ReAct は **Reasoning + Acting** の略です。エージェントは以下のループで動作します * タスクについて簡潔に推論する * 関連するツールを選択して呼び出す * 結果を観察する -* その新しい情報を使って次のステップを決定する +* 新しい情報を使用して次のステップを決定する -エージェントが最終回答を生成するのに十分な情報を収集するまで、このプロセスが繰り返されます。 +このプロセスは、エージェントが最終的な回答を生成するのに十分な情報を収集するまで繰り返されます。 {{% /notice %}} -`coordinator_node`、`flight_specialist_node`、`hotel_specialist_node`、`activity_specialist_node`、`plan_synthesizer_node` 関数の定義を以下のコードに置き換えます: +`coordinator_node`、`flight_specialist_node`、`hotel_specialist_node`、`activity_specialist_node`、`plan_synthesizer_node` 関数の定義を以下に置き換えます -> ヒント: `vi` エディタで大量の行を一括削除するには、`Shift` + `v` を押して `Visual -> Line` モードにし、下矢印キーで削除したい行をすべて選択してから、`d` -> を押して選択した行を削除します。 +> ヒント`vi` エディタで大量の行を一括削除するには、`Shift` + `v` を押して `Visual +> Line` モードに入り、下矢印キーで削除したい行をすべて選択してから、`d` を押して +> 選択した行を削除します。 ```python def coordinator_node( @@ -357,13 +357,13 @@ def plan_synthesizer_node(state: PlannerState) -> PlannerState: フライト、ホテル、アクティビティのスペシャリストエージェントを作成する際にツールを渡していることに注目してください。エージェントが呼び出されると、LLM はリクエストを処理するためにツールを呼び出すべきかどうかを判断します。 -> ヒント: 以下のコマンドを実行して、変更内容をモデルソリューションと比較できます: +> ヒント：以下のコマンドを実行して、変更内容を模範解答と比較できます > > `diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-agents-and-tools/main.py` ## 更新された Docker イメージのビルド -新しいタグで更新された Docker イメージをビルドします: +新しいタグで更新された Docker イメージをビルドします ``` bash cd ~/workshop/agentic-ai/base-app @@ -371,9 +371,14 @@ docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-ag docker push localhost:9999/agentic-ai-app:app-with-agents-and-tools ``` +> ヒント：イメージのビルドに時間がかかりすぎる場合は、ビルド済みのイメージの使用を検討してください。 +> その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルのイメージ名を +> `localhost:9999/agentic-ai-app:app-with-agents-and-tools` の代わりに +> `ghcr.io/splunk/agentic-ai-app:app-with-agents-and-tools` に更新してください。 + ### Kubernetes マニフェストの更新 -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集し、エージェントとツールを含むイメージを使用するようにイメージを更新します: +`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを編集用に開き、エージェントとツールを含むイメージを使用するようにイメージを更新します ```yaml image: localhost:9999/agentic-ai-app:app-with-agents-and-tools @@ -381,15 +386,15 @@ docker push localhost:9999/agentic-ai-app:app-with-agents-and-tools ### 更新されたアプリケーションのデプロイ -以下のようにマニフェストファイルを使用して、更新されたアプリケーションをデプロイできます: +以下のようにマニフェストファイルを使用して、更新されたアプリケーションをデプロイできます ``` bash kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml ``` -### Kubernetes でのアプリケーションのテスト +### Kubernetes でのアプリケーションテスト -新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します: +新しいアプリケーション Pod が正常に起動し、古い Pod が存在しないことを確認します {{< tabs >}} {{% tab title="Script" %}} @@ -409,7 +414,7 @@ travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s {{% /tab %}} {{< /tabs >}} -次に、以下のコマンドを実行してアプリケーションをテストします: +次に、以下のコマンドを実行してアプリケーションをテストします ``` bash curl http://travel-planner.localhost/travel/plan \ @@ -422,23 +427,25 @@ curl http://travel-planner.localhost/travel/plan \ }' ``` -## Splunk Observability Cloud でのデータ確認 +## Splunk Observability Cloud でデータを表示する Splunk Observability Cloud に戻って、トレースがどのように表示されるか確認しましょう。 -`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認してください（例: `agentic-ai-$INSTANCE`）。ページにデータが表示されるようになりました！ +`APM` に移動し、`AI agents` を選択します。ご自身の環境名が選択されていることを確認してください（例`agentic-ai-$INSTANCE`）。ページにデータが表示されるようになりました！ ![Agents](../images/Agents-v2.png) -`APM -> AI trace data` に移動します。これは AI 関連のコンテンツを含むトレースを検索できる新しいページです: +`APM -> AI trace data` に移動します。これは AI 関連のコンテンツを含むトレースを検索できる新しいページです ![Agents](../images/AI-trace-data.png) -環境名が選択されていることを確認してください（例: `agentic-ai-$INSTANCE`）。 -新しいトレースの1つを選択します。Agent flow にすべてのエージェントが表示されるようになりました！ +ご自身の環境名が選択されていることを確認してください（例`agentic-ai-$INSTANCE`）。 +新しいトレースを1つ選択します。Agent flow にすべてのエージェントが表示されるようになりました！ ![Trace](../images/Trace-v2.png) -Tool calls も確認できます: +Tool Call も確認できます + +> 注意：Tool Call の詳細を確認するには、画面右側の `AI details` から `Span details` に切り替えてください。 ![Trace](../images/TraceWithToolCalls.png) diff --git a/content/ja/ninja-workshops/18-agentic-ai/9-detect-quality-issue.md b/content/ja/ninja-workshops/18-agentic-ai/9-detect-quality-issue.md index 9c9714ce7a..600fb600db 100644 --- a/content/ja/ninja-workshops/18-agentic-ai/9-detect-quality-issue.md +++ b/content/ja/ninja-workshops/18-agentic-ai/9-detect-quality-issue.md @@ -6,11 +6,11 @@ time: 15 minutes --- > 注意: このセクションでは複数のファイルを変更する必要があります。 -> 変更箇所がわからない場合やアプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-quality-issue` フォルダにある -> モデルソリューションを参照してください。 +> どこを変更すればよいかわからない場合や、アプリケーションが +> 動作しなくなった場合は、このセクションのモデルソリューションを参照してください。 +> モデルソリューションは `~/workshop/agentic-ai/app-with-quality-issue` フォルダにあります。 -前のセクションでは、アプリケーションを OpenTelemetry で計装し、 +前のセクションでは、アプリケーションに OpenTelemetry を組み込み、 エージェントの応答のセマンティック品質を評価するように設定しました。 このセクションでは、アプリケーションにいくつかの品質問題を追加し、 @@ -18,23 +18,30 @@ Splunk Observability Cloud がそのような問題をどのように検出で ## Poisoned Chat Wrapper について -このセクションでは、既存の `ChatModel` をラップして出力をインターセプトし「汚染」する `PoisonedChatWrapper` というカスタムクラスを使用します。このアプローチを採用したのは、OpenTelemetry 計装でキャプチャされる前に出力をインターセプトできるようにするためです。 +このセクションでは、既存の `ChatModel` をラップして出力をインターセプトし「汚染」する +`PoisonedChatWrapper` というカスタムクラスを使用します。このアプローチを採用したのは、 +OpenTelemetry インストルメンテーションでキャプチャされる前に出力をインターセプトできるようにするためです。 -この仕組みに興味がある場合は、`poison_chat_wrapper.py` ファイルを確認してください。 +この仕組みについて詳しく知りたい場合は、`poison_chat_wrapper.py` ファイルを確認してください。 ## Hotel Specialist の出力を汚染する -次に、hotel specialist エージェントがこのラッパーを使用して LLM の出力を変更するように修正します。まず、`~/workshop/agentic-ai/base-app/main.py` ファイルを編集し、`Begin: Add Import Statements` と `End: Add Import Statements` の間に以下の import 文を追加します: +次に、hotel specialist エージェントがこのラッパーを使用して LLM の出力を変更するように修正します。 +まず、`~/workshop/agentic-ai/base-app/main.py` ファイルを変更して、 +`Begin: Add Import Statements` と `End: Add Import Statements` の間に +以下のインポート文を追加します: ```python from poison_chat_wrapper import PoisonedChatWrapper ``` -次に、`hotel_specialist_node` 関数の定義を以下に置き換えます: +> 注意: この新しいインポート文は、以前に追加した他のインポート文に加えて追加するものです。 + +次に、`hotel_specialist_node` 関数の定義を以下の内容に置き換えます: > ヒント: `vi` エディタで大量の行を一括削除するには、`Shift` + `v` を押して `Visual -> Line` モードに入り、下矢印キーで削除したい行をすべて選択してから、`d` -> を押して選択した行を削除します。 +> Line` モードにし、下矢印キーで削除したい行をすべて選択してから、`d` を押して +> 選択した行を削除します。 ```python def hotel_specialist_node( @@ -93,7 +100,7 @@ def hotel_specialist_node( ## 更新された Docker イメージのビルド -新しいタグで更新された Docker イメージをビルドします: +新しいタグを付けて更新された Docker イメージをビルドします: ``` bash cd ~/workshop/agentic-ai/base-app @@ -101,9 +108,15 @@ docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-qu docker push localhost:9999/agentic-ai-app:app-with-quality-issue ``` +> ヒント: イメージのビルドに時間がかかりすぎる場合は、ビルド済みの +> イメージの使用を検討してください。その場合は、 +> `~/workshop/agentic-ai/base-app/k8s.yaml` ファイルのイメージ名を +> `localhost:9999/agentic-ai-app:app-with-quality-issue` から `ghcr.io/splunk/agentic-ai-app:app-with-quality-issue` に更新してください。 + ### Kubernetes マニフェストの更新 -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集し、品質問題を含むイメージを使用するようにイメージを更新します: +`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを編集用に開き、 +品質問題のあるイメージを使用するようにイメージを更新します: ```yaml image: localhost:9999/agentic-ai-app:app-with-quality-issue @@ -117,19 +130,19 @@ docker push localhost:9999/agentic-ai-app:app-with-quality-issue kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml ``` -### Kubernetes でのアプリケーションのテスト +### Kubernetes でのアプリケーションテスト -新しいアプリケーション Pod が正常に起動し、古い Pod が存在しないことを確認します: +新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します: {{< tabs >}} -{{% tab title="Script" %}} +{{% tab title="スクリプト" %}} ``` bash kubectl get pods -n travel-agent ``` {{% /tab %}} -{{% tab title="Example Output" %}} +{{% tab title="出力例" %}} ```` NAME READY STATUS RESTARTS AGE @@ -154,10 +167,15 @@ curl http://travel-planner.localhost/travel/plan \ ## Splunk Observability Cloud でデータを確認する -Splunk Observability Cloud に戻り、トレースがどのように表示されるかを確認しましょう。 +Splunk Observability Cloud に戻り、トレースがどのように表示されるか確認しましょう。 -`hotel_specialist` エージェントの `invoke_agent` スパンを見ると、エージェントがホテルを推薦した後に `pretty terrible` と呼んでいることから、いくつかの品質問題があることがわかります: +`hotel_specialist` エージェントの `invoke_agent` スパンを見ると、 +エージェントにいくつかの品質問題があることがわかります。ホテルを推薦した後に +`pretty terrible` と呼んでいます: -![Trace With Quality Issue](../images/TraceWithQualityIssue.png) +![品質問題のあるトレース](../images/TraceWithQualityIssue.png) -> 注意: すべてのエージェント呼び出しが評価されるわけではありません。ワークショップの組織では 20% の確率でのみ評価するように設定されています。これは組織レベルで設定可能です。`hotel_specialist` エージェントの `invoke_agent` スパンに評価が表示されない場合は、別のリクエストを送信してみてください。 +> 注意: すべてのエージェント呼び出しが評価されるわけではありません。ワークショップ組織では +> 20% の確率でのみ評価するように設定されています。これは組織レベルで設定可能です。 +> `hotel_specialist` エージェントの `invoke_agent` スパンに評価が表示されない場合は、 +> もう一度リクエストを送信してみてください。 diff --git a/content/ja/scenarios/network-event-intelligence/1-getting-started/_index.md b/content/ja/scenarios/network-event-intelligence/1-getting-started/_index.md new file mode 100644 index 0000000000..10f1c7295d --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/1-getting-started/_index.md @@ -0,0 +1,84 @@ +--- +title: はじめに +linkTitle: 1. はじめに +weight: 1 +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+ +## ワークショップへのアクセス + +このワークショップの前に、ワークショップインスタンスへのアクセス情報が提供されているはずです。このワークショップでは、Splunk Enterprise と IT Service Intelligence が含まれる事前構成済みの環境を使用します。インスタンスへのリンクと認証情報は、Splunk Show のインスタンス詳細で確認できます。 + +このワークショップを完了するために必要なすべてのデータは `netops` インデックスで利用できます。このインデックスには、**Catalyst Center**、**Merkai**、および **Solarwinds** からのアラートのデータが含まれています。 + +自動化された障害シナリオが30分サイクルで実行されます。Catalyst Center のサイトは15分間正常に動作し、その後15分間パフォーマンスが低下します。環境が異常な状態の間、**Catalyst Center** と **Solarwinds** から Issue とアラートが生成されます。 + +このワークショップの大部分は IT Service Intelligence で完了します。特に記載がない限り、ナビゲーション手順はそこから開始します。 + +
+{{% notice style="primary" title="ワークショップインスタンスへのアクセス" %}} +
+ +**1.** Splunk Show のワークショップ詳細に記載されている URL と認証情報を使用して、Splunk インスタンスにログインします。 + +**2.** **Apps -> IT Service Intelligence** に移動します。 + +ITSI を初めて開くときは、Getting Started モーダルを閉じる必要がある場合があります（もちろん、重要な情報をすべて読んだ後に）。 +
+ +![ITSI Getting Started Modal](../images/getting-strarted-modal.png?width=30vw) +{{% / notice %}} +
+ +## データの取り込み + +このワークショップでは一貫したシナリオを提供するために datagen を使用していますが、実際の環境では、このワークショップで扱うユースケースを実装するために以下の Splunk App とアドオンが必要です。 + +### 1. [Cisco Catalyst Add-on for Splunk](https://splunkbase.splunk.com/app/7538) + +_Cisco Catalyst Add-on for Splunk は、さまざまな Cisco 製品（Cisco Identity Services Engine、Cisco SD-WAN、Cisco Catalyst Center、Cisco Cyber Vision）のデータを収集します。このアドオンは、これらのソースからのデータを解析し、Splunk インデックスに格納します。_ + +### 2. [Splunk App for Content Packs](https://splunkbase.splunk.com/app/5391) + +_Splunk App for Content Packs には、IT Service Intelligence (ITSI) 環境の迅速なセットアップに役立つパッケージ済みコンテンツが含まれています。このパッケージ済みコンテンツは、KPI Base searches、ITSI Glass Tables、テンプレート、その他のオブジェクトで構成されています。_ + +{{% notice style="info" %}} +このワークショップでは、**Content Pack for Cisco Enterprise Networks** を使用します。これにより、**Cisco Catalyst Add-on for Splunk** が提供するトポロジー情報を使用して、サービスを自動的にインポートできます。 +{{% / notice %}} + +### 3. [SolarWinds Add-on for Splunk](https://splunkbase.splunk.com/app/3584)（オプション） + +_SolarWinds Add-on for Splunk は、SolarWinds のアラートと SolarWinds の資産インベントリ（ネットワークデバイスとそのさまざまな属性）を収集します。このアドオンには、任意の SolarWinds クエリをスケジュールし、対応する出力を Splunk にインデックス化できる汎用入力も含まれています。 +その後、データを直接分析したり、Splunk プラットフォーム内の他のアプリケーションパフォーマンス関連データと相関させるためのコンテキストデータフィードとして使用したりできます。_ + +{{% notice style="info" %}} +このアドオンは、このワークショップで扱うユースケースではオプションです。SolarWinds のアラートは Splunk HTTP Event Collector に直接送信されるため、アドオンは必要ありません。実際のシナリオでは、アドオンは資産インベントリ情報を使用して追加のコンテキストとデータエンリッチメントを提供できます。 +{{% / notice %}} + +## その他の App/アドオン + +### 1. [Cisco Meraki Add-on for Splunk](https://splunkbase.splunk.com/app/5580) + +_Splunk Add-on for Cisco Meraki は、Meraki 組織全体にわたる包括的なネットワーク可観測性とセキュリティ監視を提供します。このアドオンは、Cisco Meraki REST API と Webhook を通じて豊富なデータを収集し、ネットワークパフォーマンス、セキュリティ、デバイスの正常性に関するインサイトを提供します。データの探索やカスタムダッシュボードの作成に役立つサンプルビジュアライゼーションも提供されています。_ + +{{% notice style="info" %}} +このワークショップでは Cisco Meraki は扱いませんが、`netops` インデックスには **Cisco Meraki Add-on for Splunk** を使用して収集される Cisco Meraki データが含まれています。 +{{% / notice %}} + +### 2. [Cisco Enterprise Networking for Splunk Platform](https://splunkbase.splunk.com/app/7539) + +_Cisco Enterprise Networking for Splunk Platform は、さまざまな Cisco 製品（Cisco Identity Services Engine、Cisco SD-WAN、Cisco Catalyst Center、Cisco Cyber Vision、Cisco Meraki、Cisco ThousandEyes）のダッシュボードにビジュアライゼーションを提供します。_ +この App は以下によって収集されたデータを使用します + +* _Cisco Catalyst Add-on for Splunk_ +* _Cisco Catalyst Enhanced Netflow Add-on for Splunk_ +* _Cisco Meraki Add-on for Splunk_ +* _Cisco ThousandEyes App for Splunk_ + +![Cisco Enterprise Networking App](../images/cisco-ent-network-overview.png?width=30vw) + +
+ diff --git a/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/1-cisco-enterprise-networks-content-pack.md b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/1-cisco-enterprise-networks-content-pack.md new file mode 100644 index 0000000000..629332d1eb --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/1-cisco-enterprise-networks-content-pack.md @@ -0,0 +1,94 @@ +--- +title: Cisco Enterprise Networks Content Pack のインストール +linkTitle: 2.1 Cisco Enterprise Networks Content Pack のインストール +weight: 1 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+
+このセクションでは、Cisco ネットワークインフラストラクチャ向けの事前構築済みサービス、KPI、およびデータ統合を提供する Cisco Enterprise Networks Content Pack をインストールします。 +
+ +{{% notice title="演習: Cisco Enterprise Networks Content Pack のインストール" style="primary" icon="running" %}} +**1.** ITSI で **Configuration -> Data Integrations** に移動します + +**2.** Data Integrations の下にあるタブから **Content Library** を選択します + +
+{{% notice style="Info" %}} +
+ここでは、Splunk App for Content Packs で利用可能なすべてのすぐに使える統合を確認できます +
+ +![Data Integrations](../../images/content-library.png?width=40vw) +{{% / notice %}} +
+ +**3.** **Content Pack for Cisco Enterprise Networks** を選択し、**Proceed** をクリックします + +
+{{% notice style="Info" %}} +
+このページでは、Content Pack で利用可能な内容の概要を確認できます +
+ +![Content Pack for Cisco Enterprise Networks](../../images/content-pack-overview.png?width=40vw) +{{% / notice %}} +
+ +**5.** **Add all 14 objects** が有効になっていることを確認します + +**6.** **Import As Enabled** トグルを有効にします + +**重要: Add a prefix to your new objects セクションにプレフィックスを入力しないでください** + +**7.** **Install Selected** をクリックします + +
+{{% notice style="Info" %}} +
+**Install Selected** をクリックする前に、Add all 14 objects と Import As Enabled の両方がオンになっていることを確認してください +
+ +![Install Selected](../../images/install-selected.png?width=40vw) +{{% / notice %}} +
+ +**8.** **Install** をクリックします。 + +
+{{% notice style="Info" %}} +
+本番環境では、大きな変更を行う前にバックアップを取ることがベストプラクティスです +
+ +![Install](../../images/install-confirm.png?width=40vw) +{{% / notice %}} +
+ +**9.** インストールが完了したことを確認します。 + +
+{{% notice style="Info" %}} +
+サマリーにすべてのオブジェクトが正常にインストールされたことが表示されます +
+ +![Installation Complete](../../images/installation-complete.png?width=40vw) +{{% / notice %}} +
+ +{{% notice style="Primary" title="お疲れ様でした!" %}} +
+Cisco Enterprise Networks Content Pack のインストールが完了しました！ + +次のセクションでは、Content Pack を使用して Catalyst Center Sites を ITSI のサービスとして自動的にインポートする方法を確認します。 + +**Configure Services** をクリックして、ワークショップの次のセクションに進んでください。 +
+{{% / notice %}} + +{{% / notice %}} +
diff --git a/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/2-itsi-service-kpi-import-and-setup.md b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/2-itsi-service-kpi-import-and-setup.md new file mode 100644 index 0000000000..757d7300a1 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/2-itsi-service-kpi-import-and-setup.md @@ -0,0 +1,117 @@ +--- +title: ITSI サービスと KPI の検証 +linkTitle: 2.2 ITSI サービスと KPI の検証 +weight: 2 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+
+ITSI 4.21 では、手動のインポートプロセスがガイド付きワークフローと事前構築済みのデータ統合に置き換えられました。コンテンツパックには、Meraki と Catalyst Center のサービス階層を自動的に検出して構築するサービスインポートモジュールが含まれています。 +
+ +{{% notice title="演習: サービスのインポートとアラートの設定" style="primary" icon="running" %}} + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +Catalyst Center の Import Services ページに戻るには、**Configuration** > **Data Integrations** > **Content Library** > **Cisco Enterprise Networks** に移動します。 +{{% / notice %}} + +**1.** **Service Import Modules** の下で、**Cisco Catalyst Center** を選択します。 + +
+{{% notice style="Info" %}} +
+自動サービス階層インポートは、Catalyst Center と Meraki の両方でサポートされています +
+ +![Service Import Modules](../../images/service-import-modules.png?width=40vw) +{{% / notice %}} +
+ +**2.** Catalyst Center ホストと利用可能なすべてのサービスを選択します。**Next** をクリックします。 + +
+{{% notice style="Info" %}} +
+Catalyst Center ホストと利用可能なすべてのサイトを選択して、ITSI サービスとしてインポートします +
+ +![Select Services](../../images/select-services.png?width=40vw) +{{% / notice %}} +
+ +**3.** **Default Service Sandbox** を選択します。**Next** をクリックします。 + +
+{{% notice style="Info" %}} +
+サービスは、本番環境の ITSI に公開される前にレビュー用のサンドボックスにインポートされます +
+ +![Default Service Sandbox](../../images/default-service-sandbox.png?width=40vw) +{{% / notice %}} +
+ +**4.** インポートされるサービスを確認します。**Import** をクリックします。 + +
+{{% notice style="Info" %}} +
+Import をクリックする前に、作成される Catalyst Center サイトサービスの完全なリストを確認します +
+ +![Review Services](../../images/review-services.png?width=40vw) +{{% / notice %}} +
+ +**5.** Service Sandbox を確認します。**Publish** をクリックします。事前チェックが完了したら、**Next** をクリックします。 + +
+{{% notice style="Info" %}} +
+サンドボックスでサービス階層を確認し、公開して ITSI でサービスを有効にします +
+ +![Service Sandbox](../../images/service-sandbox-publish.png?width=40vw) +{{% / notice %}} +
+ +**6.** **Configuration** > **Service Monitoring** > **Service and KPI Management** に移動します。 + +**7.** **Select All** チェックボックスを使用して、すべてのサービスを選択します。 + +**8.** すべてのサービスを選択した状態で、**Bulk Action** > **Enable** をクリックします。 + +
+{{% notice style="Info" %}} +
+Service and KPI Management ページから Bulk Action を使用して、インポートされたすべてのサービスを一度に有効にします +
+ +![Service and KPI Management](../../images/service-kpi-management.png?width=40vw) +{{% / notice %}} +
+ +**9.** **Enable** をクリックします。数分後に KPI が表示されます。 + +
+{{% notice style="Info" %}} +
+有効化アクションを確認します。KPI は数分以内に計算を開始します +
+ +![Enable KPIs](../../images/enable-kpis.png?width=40vw) +{{% / notice %}} +
+ +{{% notice style="Primary" title="お疲れ様でした！" %}} +
+CSV やルックアップの作成、SPL の記述、サービス依存関係の手動設定を行うことなく、すべての Catalyst Center サービスをインポートできました。とても便利ですね。 + +次のセクションに進んで、設定が正しく動作していることを検証しましょう。 +
+{{% / notice %}} + +{{% /notice %}} +
diff --git a/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/3-itsi-validate-configuration.md b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/3-itsi-validate-configuration.md new file mode 100644 index 0000000000..29f0b48025 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/3-itsi-validate-configuration.md @@ -0,0 +1,55 @@ +--- +title: 設定の検証 +linkTitle: 2.3 設定の検証 +weight: 3 +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+
+インポートしたサービスと KPI が正しく計算されていること、および Catalyst Center からのアラートパイプラインがアクティブであることを確認してから、次に進みます。 +
+ +{{% notice title="演習: 設定の検証" style="primary" icon="running" %}} + +**1.** **Service Analyzer** > **Default Service Analyzer** に移動します。 + +インポートしたサービスと、Catalyst Center Site Service Template に含まれる KPI が表示されるはずです。 + +サービスと KPI のヘルスステータスが表示されるまで数分かかる場合があります。 + +
+{{% notice style="Info" %}} +
+Service Analyzer には、インポートした Catalyst Center サイトサービスとその現在のヘルスステータスが表示されます +
+ +![ITSI Service Analyzer](../../images/service-analyzer.png?width=40vw) +{{% / notice %}} +
+ +**2.** **Tree** をクリックして **Service Tree** ビューに切り替えます + +**3.** サービスツリー内の Store サービスのいずれかをクリックして、Catalyst Center Site に関連付けられた KPI を表示します + +
+{{% notice style="Info" %}} +
+サービスをクリックすると、個々の KPI とネットワークレイヤーごとの現在のヘルススコアが表示されます +
+ +![Service KPIs](../../images/service-kpis.png?width=40vw) +{{% / notice %}} +
+ +{{% notice style="Primary" title="おめでとうございます！" %}} +
+Catalyst Center サービスが ITSI で稼働しています！ + +次のセクションでは、**Inbound Notification Service** を設定します。これにより、ネットワークパフォーマンスの低下を示す Catalyst Center Issue が発生した際に、ITSI でノータブルイベントが自動的に作成されるようになります。 +
+{{% / notice %}} + +{{% / notice %}} +
diff --git a/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/_index.md b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/_index.md new file mode 100644 index 0000000000..1d819f567c --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/2-import-catalyst-center-services-in-itsi/_index.md @@ -0,0 +1,50 @@ +--- +title: Catalyst Center サービスを ITSI にインポートする +linkTitle: 2. Catalyst Center サービスを ITSI にインポートする +weight: 2 +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- +
+ +## デバイスヘルスからロケーションベースのネットワーク可視化へ + +従来のネットワーク監視ツールは、個々のデバイスについてレポートします（ルーターが稼働しているか停止しているか、スイッチに到達可能かどうかなど）。このレベルの可視性では、*何が*障害を起こしたかはわかりますが、*どこで影響が発生しているか*や*ビジネスにとってどの程度深刻か*はわかりません。ブランチオフィスのディストリビューションスイッチがパフォーマンス低下し始めた場合、運用チームがサイト全体に影響が及んでいることを把握するために、複数のツールのアラートを手動で関連付ける必要があってはなりません。 + +このセクションでは、そのギャップに対処します。**Content Pack for Cisco Enterprise Networks** を使用して Cisco Catalyst Center のトポロジーデータを ITSI にインポートすることで、デバイスのヘルスをサイトレベルに集約する**ロケーション対応のサービスモデル**を作成します。50個の個別のデバイスアラートを監視する代わりに、サイトごとに1つのサービスヘルススコアが表示されるため、チームは「*現在どのサイトで問題が発生しているか？*」という質問に即座に回答を得ることができます。 + +## Content Pack が重要な理由 + +**Content Pack for Cisco Enterprise Networks**（**Splunk App for Content Packs** を通じて利用可能）が、ここでの重要なイネーブラーです。サービスや KPI を一から手動で構築する代わりに、このコンテンツパックは **Cisco Catalyst Add-on for Splunk** によって既に収集されているトポロジーデータを使用して、Catalyst Center のサイトを ITSI サービスとして自動的に検出・インポートします。各サイトがサービスとなり、各サービスにはそのサイト内のすべてのネットワークレイヤーのヘルスを反映する事前構築済みの KPI セットが付与されます。 + +インポートワークフローは、Cisco Catalyst Center のサイト階層を読み取り、サイトごとに1つの ITSI サービスを作成します。その後、ITSI がエンティティディスカバリーサーチを実行し、適切なデバイス（エンティティ）を各サービスに自動的に関連付けます。手動でのマッピングは不要です！ + +![Import Catalyst Center Services](../images/review-services.png?width=40vw) + +## Catalyst Center Site サービステンプレート + +この統合の中核となるのが、**Catalyst Center Site** サービステンプレートです。サービスがインポートされると、このテンプレートが各サイトに適用され、そのロケーションにおけるネットワークスタックの各レイヤーを追跡する6つのすぐに使える KPI が提供されます + +
+ +| KPI | 測定対象 | +|---|---| +| **Access Layer** | Access Layer デバイスの平均 HealthScore | +| **Access Points** | Access Point デバイスの平均 HealthScore | +| **Core Layer** | Core Layer デバイスの平均 HealthScore | +| **Distribution Layer** | Distribution Layer デバイスの平均 HealthScore | +| **Router Health** | ルーターの平均 HealthScore | +| **Wireless Controller Health** | Wireless Controller の平均 HealthScore | + +
+ +これらの KPI は、Cisco Catalyst Center HealthScore から直接取得されます。HealthScore は、Catalyst Center がオンボーディング、接続性、無線周波数のヘルスに基づいて各デバイスに割り当てる1〜10のスコアです。これらのスコアをネットワークレイヤーごとに平均化することで、ITSI はサイト全体のヘルスを低下させている*スタックの正確な部分*を特定できます。その結果、「Site X のパフォーマンスが低下している」から「Site X の Access Layer が問題である」への特定が数秒で行えるようになります。 + +## このセクションで行うこと + +このセクションを完了すると、以下が達成されます + +- **Content Pack for Cisco Enterprise Networks** をインストールし、Catalyst Center のサイトを ITSI サービスとしてインポート +- Catalyst Center Site の KPI が実際のネットワークヘルスデータで正しく値が入力されていることを検証 + +
diff --git a/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/1-setup-cisco-catalyst-inbound-notifications.md b/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/1-setup-cisco-catalyst-inbound-notifications.md new file mode 100644 index 0000000000..5ee869f99b --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/1-setup-cisco-catalyst-inbound-notifications.md @@ -0,0 +1,142 @@ +--- +title: Cisco Catalyst インバウンド通知の設定 +linkTitle: 3.1 Cisco Catalyst インバウンド通知の設定 +weight: 1 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+
+ITSI 4.21 には、Cisco Meraki および Catalyst Center アラート用のネイティブデータ統合が含まれています。推奨される方法は、アラートを正規化するために必要な設定があらかじめ構成されたデフォルト接続を有効化することです。デフォルト構成は、お客様の特定のユースケースに合わせてカスタマイズできます。 + +このセクションでは、ロケーション間でイベントを相関できるようにアラートをカスタマイズし、サービスの正常性が正常に戻ったときにエピソードが自動的に解決されるようにステータスマッピングを更新します。 +
+ +{{% notice title="演習: アラート統合の構成" style="primary" icon="running" %}} + +**1.** ITSI で、**Configuration** > **Data Integrations** に移動します。 + +**2.** **Integrations library** の **Alerts** セクションで、**Cisco Catalyst Center** を選択します。 + +
+{{% notice style="Info" %}} +
+Data Integrations ライブラリの Alerts セクションには、Catalyst Center と Meraki 用の事前構築済み接続が含まれています +
+ +![Data Integrations](../../images/data-integrations-alerts.png?width=40vw) +{{% / notice %}} +
+ +**3.** **+ Add Connection** をクリックします。 + +
+{{% notice style="Info" %}} +
+カスタム接続を追加すると、サーチ、フィールドマッピング、スロットリング動作をデフォルトとは独立して制御できます +
+ +![Add Connection](../../images/add-connection.png?width=40vw) +{{% / notice %}} +
+ +**4.** 名前に `Catalyst Center Alerts` と入力します。以下のサーチを使用します: + +```splunk +index=netops sourcetype="cisco:dnac:issue" +| eval itsi_site = case( isnotnull(SiteNameHierarchy) AND SiteNameHierarchy!="", mvindex(split(SiteNameHierarchy, "/"), 3), isnotnull(DeviceName) AND DeviceName!="", "Store-" . mvindex(split(DeviceName, "-"), 0) ) +``` + +**5.** **Validate** をクリックします + +**6.** **Lookback period** を **5 minutes** に設定します + +
+{{% notice style="Info" %}} +
+バリデーションにより、サーチがイベントを返し、フィールドマッピングが正しいことを保存前に確認できます +
+ +![Validate Connection](../../images/validate-connection.png?width=40vw) +{{% / notice %}} +
+ +**7.** **Source** を **Mapping rule** に更新し、タイプとして **Coalesce** を使用します + +**8.** 最初のフィールドとして `DeviceName` を、2番目のフィールドとして `SiteName` を選択します + +**9.** **else use the default value** フィールドに `IssueSpecificEntityValue` と入力します + +
+{{% notice style="Info" %}} +
+Source フィールドは、ITSI エピソード内でアラートの発生元を識別するために使用されます +
+ +![Update Source](../../images/cat-center-notification-config-1.png?width=40vw) +{{% / notice %}} +
+ +**10.** **Severity ID** マッピングを **Mapping rule** に更新し、タイプとして **Value case mapping** を使用します + +**11.** `IssueStatus` の **is equal to (not case sensitive)** を `resolved` に設定し、**then use** を `Normal` にします + +**12.** if 文の残りの部分に以下の値をマッピングします: + +`vendor_severity` の **is equal to (not case sensitive)** を `P1` に設定し、**then use** を `Critical` にします + +`vendor_severity` の **is equal to (not case sensitive)** を `P2` に設定し、**then use** を `High` にします + +`vendor_severity` の **is equal to (not case sensitive)** を `P3` に設定し、**then use** を `Medium` にします + +`vendor_severity` の **is equal to (not case sensitive)** を `P4` に設定し、**then use** を `Low` にします + +最後に、**else use this default value** を `Info` に設定します + +
+{{% notice style="Info" %}} +
+Catalyst Center の重大度の値を ITSI の重大度スケールにマッピングして、エピソードに正しい優先度が表示されるようにします +
+ +![Severity ID Mapping](../../images/severity-mapping.png?width=40vw) +{{% / notice %}} +
+ +**13.** **subcomponent** を `itsi_site` に更新します + +**14.** * **Run every** を **1 minute** に変更します + +**15.** **Service Association** セクションに `NY HQ`、`Store-SJC10`、および `Store-SJC12` を追加します + +**16.** **Entity Lookup Field** に `SiteNameHierarchy` を使用します + +**17.** **Enable throttling** トグルをオンにします + +**18.** **Suppress period** を **5 minutes** ごとに設定します + +**19.** 右上の **Preview Results** をクリックします（**注:** プレビューで結果が表示されない場合があります。イベントは **Create a custom NEAP** セクションで確認します） + +**20.** **Save and Activate** をクリックします + +
+{{% notice style="Info" %}} +
+subcomponent フィールドは、各アラートを ITSI 内の対応する Catalyst Center サイトサービスにリンクするものです +
+ +![Subcomponent Configuration](../../images/subcomponent-config.png?width=40vw) +{{% / notice %}} +
+ +{{% notice style="Primary" title="お疲れ様でした！" %}} +
+Catalyst Center アラートが、サイトサービスにリンクされた正規化済みの注目すべきイベントとして ITSI に取り込まれるようになりました。 + +次のセクションでは、ITSI が両方のベンダーからのイベントを相関できるように、2番目のアラートソースとして SolarWinds を追加します。 +
+{{% / notice %}} + +{{% /notice %}} +
diff --git a/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/_index.md b/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/_index.md new file mode 100644 index 0000000000..9dba3ed5c7 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/3-configure-catalyst-center-notifications/_index.md @@ -0,0 +1,28 @@ +--- +title: Catalyst Center 通知の設定 +linkTitle: 3. Catalyst Center 通知の設定 +weight: 3 +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+ +## Catalyst Center アラートを ITSI に取り込む + +Catalyst Center のサービスと KPI が ITSI で稼働している状態で、次のステップはインバウンド通知を設定し、Catalyst Center が生成した Issue とイベントを ITSI のエピソードに直接取り込むことです。これにより、ロケーションベースのモニタリングをアクショナブルにするフィードバックループが構築されます。サイトの KPI ヘルススコアが低下すると、Catalyst Center が Issue を発生させ、その Issue が影響を受けたサイトサービスに紐づくノータブルイベントとして ITSI に表示されます。 + +**Cisco Catalyst Add-on for Splunk** がデータの取り込みを処理しますが、アラートの正規化には ITSI 内でインバウンド通知接続を設定する必要があります。Content Pack for Cisco Enterprise Networks には、Catalyst Center 用の事前構築済みアラートデータ統合テンプレートが含まれており、関連フィールドが自動的にマッピングされるため、セットアップは簡単です。 + +**注意:** このセクションでは、ITSI で Catalyst Center インバウンド通知接続のカスタムバージョンを設定し、Catalyst Center からの Issue が Episode Review ページに正規化されたノータブルイベントとして表示されるようにします。 + +![Catalyst Center Notification Configuration](../images/cat-center-notification-config-1.png?width=60vw) + +## このセクションで行うこと + +このセクションを完了すると、以下が達成されます: + +- ITSI で **Cisco Catalyst Center** アラート用のカスタムインバウンド通知接続を設定 +- イベントを正しいサイトサービスに関連付けるために必要なアラートフィールドをマッピング + +
diff --git a/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/1-solarwinds-content-pack.md b/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/1-solarwinds-content-pack.md new file mode 100644 index 0000000000..469683eede --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/1-solarwinds-content-pack.md @@ -0,0 +1,145 @@ +--- +title: Solarwinds Content Pack のインストール +linkTitle: 4.1 Solarwinds Content Pack のインストール +weight: 1 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+
+このセクションでは、SolarWinds Content Pack をインストールおよび設定し、SolarWinds アラートを ITSI に取り込みます。これにより、クロスベンダー相関に必要な2ソースのアラートパイプラインが完成します。 +
+ +{{% notice title="演習: Solarwinds Content Pack のインストール" style="primary" icon="running" %}} + +**1.** ITSI で、**Configuration** > **Data Integrations** に移動します。 + +**2.** **Integrations library** の **Alerts** セクションで、**Solarwinds** を選択します。 + +
+{{% notice style="Info" %}} +
+SolarWinds Content Pack には、ITSI 用の構築済みフィールドマッピングとアラートテンプレートが含まれています +
+ +![Content Pack for Solarwinds](../../images/solarwinds-content-pack.png?width=40vw) +{{% / notice %}} +
+ +**3.** 接続タイトルに `Solarwinds Alerts` と入力します。 + +**4.** 検索に以下の SPL を使用します: + +```text +index=netops sourcetype="solarwinds:alert:hec" +``` + +**5.** **Validate** をクリックします。 + +**6.** **Lookback period** を **5 minutes** に設定します。 + +
+{{% notice style="Info" %}} +
+バリデーションにより、接続を保存する前に検索が SolarWinds イベントを返していることを確認できます +
+ +![Validate Connection](../../images/solarwinds-validate.png?width=40vw) +{{% / notice %}} +
+ +**7.** **Signature** を `title` に設定します。 + +
+{{% notice style="Info" %}} +
+Signature フィールドは各アラートタイプを一意に識別し、ITSI 内での重複排除に使用されます +
+ +![Signature](../../images/solarwinds-signature.png?width=40vw) +{{% / notice %}} +
+ +**8.** **Severity ID** のマッピングを、タイプとして **Value case mapping** を使用する **Mapping rule** に更新します + +**9.** `severity_id` **is equal to (not case sensitive)** を `1` に、**then use** を `Normal` に設定します + +**10.** 残りの if 文に以下の値をマッピングします: + +`severity_id` **is equal to (not case sensitive)** を `2` に、**then use** を `Low` に設定 + +`severity_id` **is equal to (not case sensitive)** を `3` に、**then use** を `Medium` に設定 + +`severity_id` **is equal to (not case sensitive)** を `4` に、**then use** を `High` に設定 + +`severity_id` **is equal to (not case sensitive)** を `5` に、**then use** を `Critical` に設定 + +最後に、**else use this default value** を `Info` に設定します + +
+{{% notice style="Info" %}} +
+SolarWinds の重大度の値を ITSI の重大度スケールにマッピングし、エピソードに正しい優先度が表示されるようにします +
+ +![Severity ID Mapping](../../images/solarwinds-severity.png?width=40vw) +{{% / notice %}} +
+ +**11.** **subcomponent** を `vendor_region` に更新します。 + +
+{{% notice style="Info" %}} +
+subcomponent フィールドは各 SolarWinds アラートを対応するサイトにリンクし、クロスベンダー相関を可能にします +
+ +![Subcomponent](../../images/solarwinds-subcomponent.png?width=40vw) +{{% / notice %}} +
+ +**12.** **additional fields** を展開し、**description** を `signature` に設定します。 + +
+{{% notice style="Info" %}} +
+追加フィールドは、ITSI でエピソードを確認する際に表示される追加のコンテキストを提供します +
+ +![Additional Fields](../../images/solarwinds-additional-fields.png?width=40vw) +{{% / notice %}} +
+ +**13.** Schedule を **Run Every Minute** に設定します。 + +**14.** **Service Association** セクションに `NY HQ`、`Store-SJC10`、`Store-SJC12` を追加します + +**15.** **Enable throttling** トグルをオンにします + +**16.** **Suppress period** を **5 minutes** ごとに設定します + +**17.** 右上の **Preview Results** をクリックします（**注:** プレビューで結果が表示されない場合があります。イベントは **Create a custom NEAP** セクションで確認します） + +**18.** **Save and Activate** をクリックします + +
+{{% notice style="Info" %}} +
+保存前に Preview Results で変換されたフィールドを確認し、マッピングが正しいことを確認します +
+ +![Save and Activate](../../images/solarwinds-save-activate.png?width=40vw) +{{% / notice %}} +
+ +{{% notice style="Primary" title="お疲れ様でした！" %}} +
+SolarWinds アラートが Catalyst Center イベントとともに ITSI に取り込まれるようになりました。両方のソースが正規化され、相関の準備が整いました。 + +次のセクションでは、両方のベンダーからのアラートをサイトごとに1つのエピソードにグループ化するカスタム NEAP を作成します。 +
+{{% / notice %}} + +{{% /notice %}} +
diff --git a/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/_index.md b/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/_index.md new file mode 100644 index 0000000000..ff5a4d87ca --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/4-configure-solarwinds-notifications/_index.md @@ -0,0 +1,26 @@ +--- +title: SolarWinds 通知の設定 +linkTitle: 4. SolarWinds 通知の設定 +weight: 4 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+ +## 2つ目のアラートソースの追加 + +このワークショップの主要な目標は、クロスベンダーのアラート相関を実演することです。Cisco Catalyst Center は Cisco インフラストラクチャをカバーしますが、多くのエンタープライズネットワークでは、Cisco 以外のデバイス、WAN リンク、およびより広範なネットワークヘルスメトリクスを監視するために、SolarWinds のようなサードパーティ監視ツールにも依存しています。両方のソースが同じサイトまたは同じ時間帯についてアラートを発生させた場合、ITSI はそれぞれに個別のノイズを生成するのではなく、単一のエピソードにグループ化できるべきです。 + +**SolarWinds Add-on for Splunk** は詳細なアセットコンテキストを提供できますが、このユースケースでは SolarWinds アラートは Splunk HTTP Event Collector に直接配信されます。Content Pack for Cisco Enterprise Networks には、これらのアラートを正規化して Catalyst Center アラートと同じ方法で ITSI に認識させるための事前構築済みの統合テンプレートが含まれています。 + +このセクションでは、SolarWinds Content Pack をインストールし、インバウンド通知接続を設定します。これにより、次のセクションで NEAP が相関させる2ソースアラートパイプラインが完成します。 + +## このセクションで行うこと + +このセクションを完了すると、以下が達成されます: + +- **SolarWinds Content Pack** のインストールとインバウンド通知接続の設定 +- SolarWinds アラートが正規化されたノータブルイベントとして ITSI に流入していることの確認 + +
diff --git a/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/1-itsi-create-custom-neap.md b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/1-itsi-create-custom-neap.md new file mode 100644 index 0000000000..5e4d0d6c1d --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/1-itsi-create-custom-neap.md @@ -0,0 +1,127 @@ +--- +title: ITSI カスタム NEAP の作成 +linkTitle: 5.1 ITSI カスタム NEAP の作成 +weight: 1 +time: 10 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+
+前のステップで Catalyst Center と Solarwinds のインバウンド通知ルールを設定したため、まもなくこれらのソースに対してエピソードが生成されるはずです。ITSI がデフォルトの集約ポリシーを適用していることに気づくかもしれません。デフォルトポリシーはアラートをソース別にグループ化することで、迅速な集約値を提供します。しかし、このデータセットではエピソードをロケーション別にグループ化したいと考えています。これにより、Catalyst Center と SolarWinds のアラート間の相関が可能になります。これは ITSI イベント管理の差別化機能です。 +
+ +{{% notice title="演習: カスタム NEAP の作成" style="primary" icon="running" %}} + +**1.** **Alerts and Episodes** に移動します。最近作成されたエピソードを確認します。アラートのグループ化に **Default Aggregation Policy** が使用されていることに注目してください。この環境のブレークシナリオは30分サイクル（15分間正常、15分間異常）で動作するため、エピソードが表示されるまで最大15分かかる場合があります。 + +
+{{% notice style="Info" %}} +
+Alerts and Episodes ビューには、現在のすべてのNotableイベントと、それらがグループ化されたエピソードが表示されます +
+ +![Alerts and Episodes](../../images/alerts-and-episodes.png?width=40vw) +{{% / notice %}} +
+ +**2.** **Configuration** > **Event Management** > **Notable Event Aggregation Policies** に移動します。 + +**3.** 右上の **Create Notable Event Aggregation Policy** をクリックします。 + +
+{{% notice style="Info" %}} +
+ITSI にはいくつかの組み込みポリシーが含まれています。ここでは、複数のベンダーからのネットワークサイトアラートをグループ化するための新しいポリシーを作成します +
+ +![Create NEAP](../../images/create-neap.png?width=40vw) +{{% / notice %}} +
+ +**4.** **Filtering Criteria and Instructions** で `orig_sourcetype` matches `cisco:dnac:issue` を追加します。 + +**5.** **Add Rule (OR)** をクリックし、`orig_sourcetype` matches `solarwinds:alert:hec` を入力します。 + +**6.** **Group alerts episodes based on...** で `host` を `subcomponent` に置き換えます。 + +**7.** デフォルトの **Break Episode** スタンザを **If the flow of events into the episode is paused for** に置き換え、**600 seconds** を使用します。 + +{{% notice style="info" %}} +ブレーク条件が満たされると、現在のエピソードにはイベントを追加できなくなり、次のNotableイベントから新しいエピソードが開始されます。例: 次のイベントが発生した場合にエピソードをブレーク: message matches **status** `Normal`。このルールは、正常なNotableイベントを受信すると（問題が解決されたことを示す）、エピソードをブレークします。 +{{% /notice %}} + +
+{{% notice style="Info" %}} +
+フィルタリング条件は、このポリシーが適用されるアラートソースを定義し、グループ化フィールドはエピソードの形成方法を決定します +
+ +![Filtering Criteria](../../images/filtering-criteria.png?width=40vw) +{{% / notice %}} +
+ +{{% notice style="info" %}} +IT Service Intelligence（ITSI）の Event iQ は、機械学習アルゴリズムを使用してフィールド値を比較し、Notableイベントをエピソードに相関させます。イベントを相関させるための手動属性を定義する代わりに、グループ化ポリシーで使用する正しい属性を自動的に識別できます。ITSI にアラートをオンボードした後、アラートをフィルタリングする条件を設定し、Event iQ を使用して履歴イベントデータの分析に基づくイベント相関ポリシーを作成できます。 + +ワークフローで Event iQ を使用すると、自動化されたアラート監視の迅速なセットアップ、アラートノイズの削減、イベントアクションの実行が可能になります。さらに、アルゴリズムは環境のアラートニーズに合わせて継続的にチューニングできます。 +{{% /notice %}} + +**8.** **Episode Information** を展開します。 + +* **Episode Title** を **Static Value** に設定し、`Network Issue Impacting: %subcomponent%` と入力します +* **Episode Severity** を **Same as the highest Severity** に設定します +* 右上の **Next** をクリックします + +
+{{% notice style="Info" %}} +
+エピソードタイトルで %subcomponent% を使用すると、このポリシーで作成されるすべてのエピソードに影響を受けるサイト名が自動的に入力されます +
+ +![Episode Information](../../images/episode-information.png?width=40vw) +{{% / notice %}} +
+ +**9.** **Action Rules** を設定します。 + +{{% notice style="info" %}} +集約ポリシー内にアクションルールを設定して、エピソードのアクティベーション条件が満たされたときに自動アクションを実行します。アクションルールはオプションであり、集約ポリシーごとに複数定義できます。 +{{% /notice %}} + +* ルールを追加: If **all event severities are** でドロップダウンから **Normal** を選択し、**60 seconds** を入力します +* Then **Change severity to** でドロップダウンから **Normal** を選択し、**Change status to** > **Resolved** を選択します +* **Next** をクリックします + +
+{{% notice style="Info" %}} +
+アクションルールにより、すべての関連アラートが正常に戻ったときにエピソードが自動的に解決され、手動トリアージが削減されます +
+ +![Action Rules](../../images/action-rules.png?width=40vw) +{{% / notice %}} +
+ +**10.** **Policy Title** に `Network Events by Location` と入力します。Status の **Enabled** をクリックします。**Next** をクリックします。 + +
+{{% notice style="Info" %}} +
+ポリシーをすぐに有効にして、保存後すぐに受信アラートのグループ化を開始するようにします +
+ +![Policy Title](../../images/policy-title.png?width=40vw) +{{% / notice %}} +
+ +{{% notice style="Primary" title="お疲れ様でした！" %}} +
+カスタム NEAP がアクティブになりました。同じサイトを共有する Catalyst Center と SolarWinds のアラートは、影響を受けるロケーション名がタイトルに付いた単一のエピソードにグループ化されます。 + +次のセクションに進んで、エンドツーエンドの設定全体を検証しましょう。 +
+{{% / notice %}} + +{{% /notice %}} +
diff --git a/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/2-itsi-service-kpi-review.md b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/2-itsi-service-kpi-review.md new file mode 100644 index 0000000000..ee64f34cda --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/2-itsi-service-kpi-review.md @@ -0,0 +1,77 @@ +--- +title: ITSI Service and KPI Review +linkTitle: 5.2 ITSI Service and KPI Review +weight: 2 +time: 5 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+
+このセクションでは、前のステップで構成したコンテンツパックとアラート統合によって作成されたサービスとエピソードを確認し、エンドツーエンドのパイプライン全体が正しく動作していることを確認します。 +
+ +{{% notice title="演習: サービスとエピソードの確認" style="primary" icon="running" %}} + +{{% notice style="info" %}} +IT Service Intelligence (ITSI) の Service Insights は、組織内のビジネスサービスおよび技術サービスのマッピングと監視を表します。ITSI において、サービスとは、組織に特定のサービスを提供するように構成された、相互接続されたアプリケーションとホストの集合です。ITSI Service Insights は、デバイスとアプリケーション間の接続に基づいてサービスの依存関係をマッピングするのに役立ち、問題のあるオブジェクトがサービス運用の残りの部分に与える影響を即座に確認できます。 +{{% /notice %}} + +**1.** **ITSI Service Analyzer** > **Default Service Analyzer** に移動します。インポートしたサービスが表示されるはずです + +**2.** Analyzer の名前を `Network Health by Location` に編集します + +
+{{% notice style="Info" %}} +
+Tree ビューでは、各 Catalyst Center サイトとその基盤となる KPI の正常性を含む、完全なサービス階層が表示されます +
+ +![Service Analyzer Tree View](../../images/service-analyzer.png?width=40vw) +{{% / notice %}} +
+ +**3.** 右側の **Tree** をクリックします + +**4.** **Filter Services** に **United States** を追加します + +**5.** 時間枠を **Last 1 hour** に、**Auto Refresh** を **1 minute** に設定します + +
+{{% notice style="Info" %}} +
+United States でフィルタリングし Auto Refresh を設定すると、すべてのロケーションにわたるサイトの正常性をライブビューで確認できます +
+ +![Episode Review](../../images/service-kpis.png?width=40vw) +{{% / notice %}} +
+ +**6.** **Save** をクリックします。ビューは下の画像と同じになるはずです + +**7.** **Alerts and Episodes** をクリックします + +**8.** 最近作成されたエピソードを選択します + +**9.** **Episode details** で、使用された **Aggregation Policy** が前のステップで作成した NEAP であることを確認します + +
+{{% notice style="Info" %}} +
+カスタム NEAP によって作成されたエピソードは、Catalyst Center と SolarWinds のアラートをサイト名のエピソードとしてグループ化します +
+ +![Alerts and Episodes](../../images/episode-review.png?width=40vw) +{{% / notice %}} +
+ +{{% notice style="Primary" title="お疲れ様でした!" %}} +
+パイプライン全体が確認されました。サービスとその依存関係が構成され、KPI が計算されており、カスタム NEAP がクロスベンダーのアラートをサイトごとにグループ化しています。 + +次のセクションに進んで、このシナリオを確認しましょう。 +
+{{% / notice %}} + +{{% /notice %}} +
diff --git a/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/_index.md b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/_index.md new file mode 100644 index 0000000000..eff0cd79e7 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/5-create-custom-neap/_index.md @@ -0,0 +1,31 @@ +--- +title: カスタム NEAP の作成 +linkTitle: 5. カスタム NEAP の作成 +weight: 5 +time: 10 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+ +## ベンダー間のアラート相関 + +ネットワークイベントが発生すると、運用チームは何が起こったのか、どこから始まったのか、どのサービスやユーザーが影響を受けているのかを把握するために、接続されていない複数のツールを手作業で調査しなければなりません。共通の相関レイヤーがなければ、アラートノイズは高くなり、調査は遅くなり、ネットワーク障害のビジネスへの影響は顧客からの問い合わせが来るまで見えないままです。 + +ITSI の真の価値は、関連するイベントを **Notable Event Aggregation Policy (NEAP)** を使用して、単一のアクション可能なエピソードに相関させる能力にあります。 + +NEAP は、ITSI がノータブルイベントをグループ化するルールを定義します。この場合の目標は、同じネットワークサイトに関連する Catalyst Center と SolarWinds の両方のアラートを単一のエピソードにグループ化することです。これにより、運用チームは調査する場所が1つになり、対応するチケットが1つになり、どのサイトが影響を受けているか、そして何件のアラートソースが問題を裏付けているかを明確に把握できます。 + +ITSI には事前設定された NEAP が多数含まれていますが、このワークショップではロケーションごとのアラートのグループ化に特に焦点を当てます。このセクションでは、Catalyst Center と SolarWinds のアラートをサイトごとに相関させるカスタム NEAP を構築し、サービスヘルスとエピソードの状態を一緒に確認してポリシーが正しく機能していることを検証します。 + +![Episode Review](../images/episode-review.png?width=40vw) + +## このセクションで行うこと + +このセクションを完了すると、以下のことが達成されます + +- Catalyst Center と SolarWinds の両方のアラートをネットワークサイトごとにグループ化する**カスタム Notable Event Aggregation Policy** の作成 +- ネットワークヘルスが正常に戻った際のエピソード自動解決の設定 +- Service Analyzer と Episode Review がリアルタイムのサイトヘルスを反映していることの検証 + +
diff --git a/content/ja/scenarios/network-event-intelligence/6-scenario-review/_index.md b/content/ja/scenarios/network-event-intelligence/6-scenario-review/_index.md new file mode 100644 index 0000000000..d230ebeb3a --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/6-scenario-review/_index.md @@ -0,0 +1,137 @@ +--- +title: シナリオレビュー +linkTitle: 6. シナリオレビュー +weight: 6 +time: 10 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +--- + +
+ +## シナリオ: 小売店舗でのネットワーク障害 + +このシナリオでは、キャンパス、ブランチ、および店舗拠点を持つ組織を対象としています。ネットワーク障害が発生した場合、運用チームはどのサイトが影響を受けているか、またネットワークのどのコンポーネントが正常でないかを迅速に把握する必要があります。このシナリオのウォークスルーでは、ITSI が Cisco Catalyst Center からのデバイスヘルスデータを使用し、他のツール（この場合は Solarwinds）からのアラートと相関させることで、数分で障害の全体像を把握する方法を示します。 + +実際の環境では、同じシステムを多くの異なるツールで監視していることが一般的です。障害が発生すると、すべてのツールがアラートやアラームを発報し始めます。これによりアラートストームが発生し、どこからトラブルシューティングを始めればよいか理解することが非常に困難になります。その結果、障害解決に大幅な遅延が生じ、運用チーム全体にアラート疲れが広がります。 + +ITSI は、サイトおよびネットワークレイヤーごとにネットワークの健全性を把握し、任意の数の異なる監視ソリューションからのアラートを相関させる高度にアクション可能なエピソードを提供することで、この課題に対処します。コンソール間を行き来する代わりに、チームは何が起きているか、どこで起きているか、どのツールのどのアラートが関連しているかを単一のビューで確認できます。 + +## シナリオフロー: Catalyst Center による根本原因分析 + +
+{{% notice title="シナリオレビュー" style="primary" icon="play" %}} + +**1.** ITSI で **Service Analyzer** を開きます。**Access Points** KPI のヘルスステータスが低下していることに注目してください + +
+{{% notice style="Info" %}} +
+Service Analyzer は、インポートされたすべての Catalyst Center サイトサービスとその現在のヘルス状態の概要ビューを提供します +
+ +![Service Analyzer](../images/service-analyzer.png?width=40vw) +{{% / notice %}} +
+ +**2.** 右側の **Tree** を選択して **Service Tree** を表示します + +**3.** **Store-SJC12** サービスを選択して KPI を展開します。**Access Points** KPI が正常でないことに注目してください。これは、この拠点でワイヤレスの問題が発生していることを示しています + +**4.** **Access Points** KPI を選択してエンティティの詳細にドリルダウンします。この問題がこの拠点の **Floor-1** に影響していることが確認できるはずです + +
+{{% notice style="Info" %}} +
+サービスを選択すると、個々の KPI が表示されます。Access Points KPI のヘルススコアが低下した状態を示しています +
+ +![Store-SJC12 Access Points KPI](../images/service-kpis.png?width=40vw) +{{% / notice %}} +
+ +{{% notice title="ボーナス" style="primary" icon="lightbulb" %}} +**Site Health Summary** リンクを使用してエンティティにドリルダウンし、この店舗のワイヤレスアクセスポイントのヘルス状態をより詳細に確認します。このダッシュボードは、Catalyst Center から直接取得された個々のデバイスヘルススコアの詳細なビューを提供します。 + +
+ +
+Site Health Summary ダッシュボードは、選択した拠点の個々のアクセスポイントのヘルススコアを表示します +
+ +![Site Health Summary](../images/site-health.png?width=40vw) + +
+{{% / notice %}} + +**5.** KPI ヘルス詳細の下にある **Episode Review** セクションを確認します。このサイトで現在オープンしている **High** または **Critical** のエピソードがある場合、ここに表示されます。 + +{{% notice style="info" %}} +このシナリオは **Medium** の重大度から始まり、追加のアラートが生成されるにつれて **High** にエスカレートします。30分の休止サイクルのどの時点にいるかによっては、このリストにまだエピソードが表示されない場合があります。表示されない場合は、次のステップに進み、Alerts and Episodes の完全なビューを確認してください。 +{{% / notice %}} + +現在 **High** または **Critical** のエピソードがない場合は、**Alerts and Episodes** に移動してエピソードの完全なリストを確認します。シナリオの実行時間に応じて、このサイトの以前に解決されたエピソードが表示される場合があります。これは、ITSI が基盤となる問題が解消された際に、オープンなエピソードを自動的にクローズし、ステータスを **Resolved** に設定できることを示しています + +**6.** 進行中のエピソードがある場合は、それを選択します。ない場合は、最近解決されたエピソードの1つを選択してレビューします + +**7.** エピソード詳細で**影響を受けたサービスと KPI** を確認します。このビューは、このエピソード中にどのサービスと KPI が影響を受けたかを正確に示します。 + +
+{{% notice style="Info" %}} +
+エピソード詳細は、アラートを影響を受けたサービスと KPI に紐付け、ビジネスへの影響の全体像を提供します +
+ +![Episode Review under KPI](../images/ongoing-episode-overview.png?width=40vw) +{{% / notice %}} +
+ +**8.** **Events Timeline** タブを選択して、イベントが発生した順序を確認します + +**9.** **Sort** ドロップダウンから **Root cause analysis** を選択して、イベントを時系列順に並べ替えます + +
+{{% notice style="Info" %}} +
+Root Cause Analysis でソートされた Events Timeline は、アラートが発報された順序を明らかにし、最初の障害からカスケードする影響への進行を示します +
+ +![Episode Detail](../images/ongoing-episode.png?width=40vw) +{{% / notice %}} +
+ +**10.** リストから個々のアラートを選択して確認します。このエピソードには **Solarwinds** と **Catalyst Center** の両方からのアラートが含まれていることに注目してください。これは、エピソードが前のセクションで作成した **Network Events by Location NEAP** を使用しているためで、ソースに関係なく特定のサイトのすべてのアラートをグループ化します + +
+{{% notice style="Info" %}} +
+単一のエピソードでのクロスベンダーアラート相関。Catalyst Center と Solarwinds の両方のアラートが拠点ごとにグループ化されています +
+ +![Alert Detail](../images/ongoing-episode-event-view.png?width=40vw) +{{% / notice %}} +
+ +これで、アラートをコンテキスト内で確認し、発生時刻を把握し、状況の進展に伴う重大度の変化を追跡できるようになりました。Catalyst Center または Solarwinds からクリアリングイベントを受信すると、アラートの重大度は自動的に **Normal** に変更されます。NEAP で設定したアクションルールにより、すべての関連アラートが正常に戻った後、エピソードが自動的に解決され、手動介入なしにループが閉じられます。 + +{{% notice style="Primary" title="ワークショップ完了!" %}} +
+ +**これが重要な理由** + +このワークショップを通じて、Catalyst Center のトポロジーデータを使用した**拠点ベースのネットワーク可視性**を提供するように ITSI を設定し、**2つの独立した監視ツール**からのアラートを取り込んで正規化し、それらのアラートを**サイトごとの単一のアクション可能なエピソード**に相関させるカスタム集約ポリシーを構築しました。 + +その結果、ツール間の切り替えを排除し、アラートノイズを削減し、運用チームに3つの重要な質問に対する即座の回答を提供するシステムが構築されました: *問題はどこにあるのか？何が影響を受けているのか？状況は改善しているのか悪化しているのか？* + +エピソードの作成と解決を自動化することで、ITSI は平均復旧時間を短縮し、チームが切り離されたコンソール間で重複するアラートを追いかけるのではなく、実際の問題の調査に時間を費やせるようにします。 + +### Happy Splunking + +![Dancing Buttercup](../../../ninja-workshops/11-ingest-processor-for-observability-cloud/images/Splunk-dancing-buttercup-GIF-103.gif?width=40vw) + +
+{{% / notice %}} + +{{% /notice %}} +
+ +
diff --git a/content/ja/scenarios/network-event-intelligence/_index.md b/content/ja/scenarios/network-event-intelligence/_index.md new file mode 100644 index 0000000000..a8d7d21b62 --- /dev/null +++ b/content/ja/scenarios/network-event-intelligence/_index.md @@ -0,0 +1,50 @@ +--- +title: Splunk IT Service Intelligence による Network Event Intelligence +linkTitle: Network Event Intelligence +weight: 10 +archetype: chapter +time: 2 minutes +authors: ["Chris Putnam", "Sam Scudere-Weiss", "Tim Hard"] +description: Cisco Catalyst Center、Solarwinds、Splunk ITSI を統合し、ベンダー横断でネットワークイベントを相関分析することで、アラートノイズを削減し、ネットワークインシデントのビジネスへの影響を把握します。 +--- + +
+ +## ようこそ + +このハンズオンワークショップは、Network Event Intelligence のユースケースにおける IT Service Intelligence (ITSI) の威力を効果的にデモンストレーションし、ポジショニングしたいすべての方を対象に設計されています。参加者は、潜在的なクライアントに響く実際のシナリオやユースケースに焦点を当てながら、これらのプラットフォームを統合する実践的な経験を積むことができます。このワークショップでは、Cisco Networking ポートフォリオ全体およびサードパーティ監視ソリューションにまたがる複数のソースの相関分析を重視しており、ソリューションアーキテクトが、効果的なネットワークイベント相関という顧客の重要な課題に Splunk がどのように対応できるかを自信を持って紹介できるようになります。 + +## はじめに・概要 + +今日の複雑な IT 環境において、アプリケーションやサービスのパフォーマンスと可用性を確保することは極めて重要です。このワークショップでは、Cisco Catalyst Center、Solarwinds、Splunk Enterprise、Splunk IT Service Intelligence (ITSI) を含む強力なツールの組み合わせを紹介します。これらのツールが連携することで、包括的な監視およびアラート機能を提供します。 + +### 現代のネットワークオブザーバビリティにおける課題 + +現代のエンタープライズネットワークは、Cisco Catalyst Center、Meraki、ThousandEyes などの Cisco ソリューションから、SolarWinds、HPE Aruba Networking、Palo Alto Networks などのサードパーティツールまで、ベンダーやプラットフォームの組み合わせが拡大し続けています。それぞれが独自のフォーマットで、独自のコンソールを通じて、独自のアラートを生成します。ネットワークイベントが発生すると、運用チームは何が起きたのか、どこから始まったのか、どのサービスやユーザーが影響を受けているのかを把握するために、分断されたツール間を手作業で調査しなければなりません。共通の相関レイヤーがなければ、アラートノイズは高く、調査は遅くなり、ネットワークインシデントのビジネスへの影響は、顧客からの問い合わせが入るまで見えないままです。 + +### ソリューション: Network Event Intelligence + +包括的な Network Intelligence 戦略には、さまざまなソースからのデータを統合し、相関分析を行うことで実用的なインサイトを得ることが必要です。このワークショップでは、Splunk Platform と ITSI がどのように連携してこれを実現するかをデモンストレーションします。 + +* **Cisco Enterprise Networks:** Catalyst Center、Meraki、ThousandEyes などの Cisco Data Fabric からの主要なデータソースを提供します。 + +* **Splunk:** ログ分析、あらゆるソースからのデータの収集と相関分析の中央プラットフォームとして機能し、強力な検索、可視化、相関分析機能を実現します。Splunk は IT 環境の全体的なビューを提供します。 + +* **Splunk IT Service Intelligence (ITSI):** 他のすべてのプラットフォームからのデータを相関分析することで、サービスインテリジェンスを提供します。ITSI では、サービスの定義、依存関係のマッピング、サービスの全体的な健全性とパフォーマンスを反映する主要パフォーマンス指標（KPI）の監視が可能です。ITSI は IT の問題がもたらす**ビジネスへの影響**を理解するために不可欠です。 + +## ワークショップの目標 + +このワークショップの終了時には、以下の設定が完了します。 +* Cisco Catalyst Center のデータを使用して、複数のロケーションからネットワークの健全性を監視する ITSI の設定 +* アラートを相関分析するための Catalyst Center と Solarwinds 双方からのインバウンド通知の設定 +* Catalyst Center と Solarwinds 双方からの通知を使用した相関エピソードの設定 +* 劣化したサービスの健全性が正常に戻った際に自動的に解決するエピソードの設定 + +{{% notice title="ヒント" style="primary" icon="lightbulb" %}} +このワークショップを進めるには、以下の方法が最も簡単です: + +* このページの右上にある左右の矢印（**<** | **>**）を使用する +* キーボードの左（◀️）および右（▶️）カーソルキーを使用する + {{% /notice %}} + +
diff --git a/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/_index.md b/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/_index.md index 0eeabd5722..c8122379a6 100644 --- a/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/_index.md +++ b/content/ja/scenarios/thousandeyes-integration/4-distributed-tracing/_index.md @@ -3,74 +3,75 @@ title: 分散トレーシングと双方向ドリルダウン linkTitle: 4. Distributed Tracing weight: 4 time: 25 minutes -description: ThousandEyes と Splunk APM の間でサポートされているトレース相関を有効にし、調査時にチームが2つの製品間を行き来できるようにします。 +description: ThousandEyes と Splunk APM 間のトレース相関を有効にし、調査中にチームが両製品間をシームレスに移動できるようにします。 --- -このセクションでは、ThousandEyes と Splunk の統合を真の調査ワークフローに変えていきます。前のセクションでは、ThousandEyes が合成メトリクスを Splunk Observability Cloud にストリームしました。このセクションでは、サポートされている **ThousandEyes <-> Splunk APM の分散トレーシング統合**を有効にして、ネットワーク、プラットフォーム、アプリケーションの各チームが同じリクエストを見ながら両方のツール間をピボットできるようにします。 +このセクションでは、ThousandEyes と Splunk の統合を本格的な調査ワークフローに変えます。前のセクションでは、ThousandEyes がシンセティックメトリクスを Splunk Observability Cloud にストリーミングしました。このセクションでは、サポートされている **ThousandEyes <-> Splunk APM 分散トレーシング統合** を有効にし、ネットワーク、プラットフォーム、アプリケーションの各チームが同じリクエストを見ながら両ツール間を行き来できるようにします。 -{{% notice title="なぜ重要か" style="primary" icon="lightbulb" %}} -これが2つの環境間で**双方向アクセス**を可能にする要素です。ThousandEyes は関連するトレースを Splunk APM で開けるようになり、Splunk APM は元の ThousandEyes テストに戻れるようになります。 +{{% notice title="Why This Matters" style="primary" icon="lightbulb" %}} +これは、2つの環境間の **双方向アクセス** を実現するための重要な要素です。ThousandEyes から Splunk APM の関連トレースを開くことができ、Splunk APM から元の ThousandEyes テストに戻ることもできます。 {{% /notice %}} -## 学べる内容 +## 学習内容 -このセクションを終えると、次のことができるようになります。 +このセクションを完了すると、以下のことができるようになります -- 内部サービスを計装して、Splunk APM にトレースを送信できる -- ThousandEyes の **HTTP Server** または **API** テストで分散トレーシングを有効にできる -- ThousandEyes の **Generic Connector** を Splunk APM 用に設定できる -- ThousandEyes の **Service Map** を開き、対応する Splunk のトレースに直接ジャンプできる -- Splunk APM の ThousandEyes メタデータを使用して、元の ThousandEyes テストに戻れる +- 付属の Spring PetClinic Kubernetes アプリケーションをトレースターゲットとしてデプロイおよび使用する +- 内部サービスを計装して Splunk APM にトレースを送信する +- ThousandEyes の **HTTP Server** または **API** テストで分散トレーシングを有効にする +- ThousandEyes の **Generic Connector** を Splunk APM 用に設定する +- ThousandEyes の **Service Map** を開き、対応する Splunk トレースに直接ジャンプする +- Splunk APM 内の ThousandEyes メタデータを使用して元の ThousandEyes テストに戻る -## サポートされているワークフロー +## サポートされるワークフロー -この学習シナリオは、ThousandEyes と Splunk によってドキュメント化されているサポート対象のワークフローに従います。 +この学習シナリオは、ThousandEyes と Splunk がドキュメント化しているサポート対象のワークフローに従います -- 分散トレーシングが有効な場合、ThousandEyes は **HTTP Server** および **API** テストに `b3`、`traceparent`、`tracestate` ヘッダーを自動的に挿入します。 +- ThousandEyes は、分散トレーシングが有効になっている場合、**HTTP Server** および **API** テストに `b3`、`traceparent`、`tracestate` ヘッダーを自動的にインジェクトします。 - 監視対象のエンドポイントは、ヘッダーを受け入れ、OpenTelemetry で計装され、トレースコンテキストを伝播し、オブザーバビリティバックエンドにトレースを送信する必要があります。 -- Splunk APM の場合、ThousandEyes は `https://api..signalfx.com` を指す **Generic Connector** を使用し、**API スコープ**の Splunk トークンで認証します。 -- Splunk APM は、`thousandeyes.test.id` や `thousandeyes.permalink` などの ThousandEyes 属性で一致するトレースをエンリッチし、ThousandEyes に戻る逆方向のジャンプを可能にします。 +- Splunk APM の場合、ThousandEyes は `https://api..signalfx.com` を指す **Generic Connector** を使用し、**API スコープ** の Splunk トークンで認証します。 +- Splunk APM は、一致するトレースに `thousandeyes.test.id` や `thousandeyes.permalink` などの ThousandEyes 属性を付与し、ThousandEyes への逆方向ジャンプを可能にします。 -## これらのヘッダーが実際に意味するもの +## ヘッダーの意味 -この部分は読み流しがちですが、重要です。トレースの相関は、サービスが ThousandEyes が挿入するヘッダーを理解し、トレースを正しく継続する場合にのみ機能します。 +この部分は読み飛ばしがちですが、そうすべきではありません。トレース相関は、サービスが ThousandEyes がインジェクトするヘッダーを理解し、トレースを正しく継続する場合にのみ機能します。 - `traceparent` と `tracestate` は W3C Trace Context ヘッダーです。 - `b3` は Zipkin B3 シングルヘッダー形式です。 -- ThousandEyes が両方を挿入するのは、実際の環境にはプロキシ、メッシュ、ゲートウェイ、アプリランタイムが混在しており、それらすべてが同じ伝播形式を好むわけではないためです。 +- ThousandEyes が両方をインジェクトするのは、実際の環境にはプロキシ、メッシュ、ゲートウェイ、アプリケーションランタイムが混在しており、すべてが同じ伝播形式を優先するわけではないためです。 -OpenTelemetry の用語では、重要な設定は propagator のリストです。 +OpenTelemetry の用語では、重要な設定はプロパゲーターリストです ```text OTEL_PROPAGATORS=baggage,b3,tracecontext ``` -これにより、次の2つが実現されます。 +これにより2つのことが実現されます -1. サービスが、受信した ThousandEyes リクエストから **B3** または **W3C** のコンテキストを抽出できるようになります。 -2. `tracecontext` を有効にしておくことで、W3C `tracestate` が保持されます。 +1. サービスが受信した ThousandEyes リクエストから **B3** または **W3C** コンテキストのいずれかを抽出できるようになります。 +2. `tracecontext` を有効にしたままにすることで、W3C `tracestate` が保持されます。 -{{% notice title="重要な詳細" style="warning" %}} -`tracestate` を別の OpenTelemetry propagator として追加する必要は**ありません**。`tracecontext` propagator が `traceparent` と `tracestate` の両方を処理します。 +{{% notice title="Important Detail" style="warning" %}} +`tracestate` を個別の OpenTelemetry プロパゲーターとして追加する必要は **ありません**。`tracecontext` プロパゲーターが `traceparent` と `tracestate` の両方を処理します。 {{% /notice %}} -## 「適切に行われた」状態とは +## 「正しい構成」とは -Collector はこのセットアップの一部に過ぎません。Kubernetes における正しい ThousandEyes トレーシングのデプロイには、**3つのレイヤー**があります。 +コレクターはこのセットアップの一部に過ぎません。Kubernetes における正しい ThousandEyes トレーシングデプロイメントには **3つのレイヤー** があります -1. **デプロイメントのアノテーション** OpenTelemetry Operator がランタイム固有のインストルメンテーションを注入できるようにします。 -2. **Instrumentation リソース** 注入された SDK が、トレースの送信先と使用する propagator を認識できるようにします。 -3. **Collector のトレースパイプライン** OTLP トレースが実際に受信され、Splunk APM にエクスポートされるようにします。 +1. **Deployment アノテーション** - OpenTelemetry Operator がランタイム固有の計装をインジェクトするため。 +2. **Instrumentation リソース** - インジェクトされた SDK がトレースの送信先と使用するプロパゲーターを把握するため。 +3. **Collector トレースパイプライン** - OTLP トレースが実際に受信され、Splunk APM にエクスポートされるため。 -最も多い間違いは、collector のみに焦点を当ててしまうことです。Collector は、生の `b3`、`traceparent`、`tracestate` リクエストヘッダーを直接見ることはありません。アプリケーションまたは自動計装ライブラリが最初にそれらのヘッダーを抽出し、span コンテキストを継続し、その後 OTLP 経由で collector に span を送信する必要があります。 +最もよくある間違いは、コレクターだけに注目することです。コレクターは生の `b3`、`traceparent`、`tracestate` リクエストヘッダーを直接見ることはありません。アプリケーションまたは自動計装ライブラリがまずそれらのヘッダーを抽出し、スパンコンテキストを継続してから、OTLP 経由でコレクターにスパンを送信する必要があります。 -## 現在のクラスターからの実環境設定 +## 現在のクラスターの実際の構成 -以下の例は、このワークショップを現在実行しているライブクラスターから抜粋したものです。Kubernetes で実際に動作しているパターンを示しています。 +以下の例は、このワークショップを実行しているライブクラスターからの抜粋です。現在 Kubernetes で実際に動作しているパターンを示しています。 -### 1. デプロイメントのアノテーション +### 1. Deployment アノテーション -ライブクラスターでは、`teastore` アプリケーションが `teastore/default` Instrumentation リソースを指しています。 +ライブクラスターでは、`teastore` アプリケーションが `teastore/default` Instrumentation リソースを指しています ```yaml apiVersion: apps/v1 @@ -86,11 +87,11 @@ spec: instrumentation.opentelemetry.io/inject-java: teastore/default ``` -ThousandEyes のリクエストがトレースに変換されない場合、まずここを確認します。 +ThousandEyes のリクエストがトレースに変換されない場合、最初に確認すべき箇所です。 ### 2. Instrumentation リソース -これは `teastore` のライブの `Instrumentation` オブジェクトで、ThousandEyes に関係するフィールドのみに絞り込んだものです。 +これは `teastore` のライブ `Instrumentation` オブジェクトで、ThousandEyes に関連するフィールドのみを抜粋しています ```yaml apiVersion: opentelemetry.io/v1alpha1 @@ -112,16 +113,16 @@ spec: value: deployment.environment=teastore ``` -これが ThousandEyes シナリオにおいて重要な部分です。 +ThousandEyes シナリオにおける重要なポイントは以下のとおりです -- `endpoint` は、クラスター内ローカルの OTel エージェントサービスに span を送信します。 -- `b3` により、ThousandEyes の B3 ヘッダーを抽出できます。 -- `tracecontext` により、`traceparent` と `tracestate` が保持されます。 -- `parentbased_always_on` により、ThousandEyes がリクエストを開始した時点でトレースが継続されます。 +- `endpoint` はクラスターローカルの OTel エージェントサービスにスパンを送信します。 +- `b3` は ThousandEyes の B3 ヘッダーの抽出を可能にします。 +- `tracecontext` は `traceparent` と `tracestate` を保持します。 +- `parentbased_always_on` は ThousandEyes がリクエストを開始した後もトレースが継続されることを保証します。 -### 3. 注入されたPodが実際に取得するもの +### 3. インジェクトされた Pod が実際に受け取る内容 -実行中の `teastore-webui-v1` Pod では、Operator が次の環境変数を注入しています。 +実行中の `teastore-webui-v1` Pod では、Operator が以下の環境変数をインジェクトしました ```yaml - name: JAVA_TOOL_OPTIONS @@ -136,11 +137,11 @@ spec: value: parentbased_always_on ``` -これは、抽象的な設定オブジェクトで宣言されているだけでなく、propagator が実際にワークロードに適用されていることを証明する有用な検証ポイントです。 +これは、プロパゲーターが抽象的な設定オブジェクトで宣言されているだけでなく、実際にワークロードに適用されていることを証明する有用な検証チェックポイントです。 -### 4. エージェント Collector のトレースパイプライン +### 4. Agent Collector トレースパイプライン -`otel-splunk` のライブのエージェント collector は、OTLP、Jaeger、Zipkin のトラフィックを受信し、トレースを上流に転送しています。これは実行中の ConfigMap からの抜粋です。 +`otel-splunk` のライブ Agent Collector は OTLP、Jaeger、Zipkin トラフィックを受信し、上流にトレースを転送しています。以下は実行中の ConfigMap からの抜粋です ```yaml receivers: @@ -168,11 +169,11 @@ service: exporters: [otlp, signalfx] ``` -ThousandEyes にとって重要なのは、collector の特殊な B3 オプションではありません。重要なのは、collector が `4317` と `4318` で OTLP を公開しており、サービスがそこに span をエクスポートしているという点です。 +ThousandEyes にとって重要なのは、コレクターに特別な B3 オプションを設定することではありません。重要なのは、コレクターが `4317` と `4318` で OTLP を公開しており、サービスがそこにスパンをエクスポートしていることです。 -### 5. ゲートウェイ Collector の Splunk APM へのエクスポート +### 5. Gateway Collector から Splunk APM へのエクスポート -その後、ライブのゲートウェイ collector がトレースを Splunk Observability Cloud に転送します。これは、実行中のゲートウェイ ConfigMap の関連部分です。 +ライブの Gateway Collector はトレースを Splunk Observability Cloud に転送します。以下は実行中の Gateway ConfigMap の関連部分です ```yaml exporters: @@ -200,21 +201,21 @@ service: exporters: [otlphttp, signalfx] ``` -これは、span を Splunk APM に届ける部分です。このパイプラインが壊れていると、ThousandEyes はリクエストにヘッダーを挿入することはできても、相関したトレースは Splunk に表示されません。 +これは、スパンを Splunk APM に到達させるための部分です。このパイプラインが壊れている場合、ThousandEyes はリクエストにヘッダーをインジェクトできますが、相関するトレースが Splunk に表示されることはありません。 -{{% notice title="現在のクラスターからの教訓" style="info" %}} -ライブクラスターでは、`teastore/default` Instrumentation リソースが、`b3` と `tracecontext` を明示的に組み合わせているため、ThousandEyes に従うべきパターンとなっています。これは、このシナリオで複製したい設定です。 +{{% notice title="Current Cluster Takeaway" style="info" %}} +ライブクラスターでは、`teastore/default` Instrumentation リソースが ThousandEyes 用のパターンとして適しています。`b3` と `tracecontext` を明示的に含んでいるためです。これがこのシナリオで再現したい構成です。 {{% /notice %}} -{{% notice title="重要" style="warning" %}} -このセクションでは、ブラウザのページ URL は使用**しないでください**。ThousandEyes は、ブラウザがこのワークフローに必要なカスタムトレースヘッダーを受け入れないことをドキュメント化しています。代わりに、**HTTP Server** または **API** テストの背後にある計装済みのバックエンドエンドポイントを使用してください。 +{{% notice title="Important" style="warning" %}} +このセクションではブラウザのページ URL を使用 **しないでください**。ThousandEyes のドキュメントによると、ブラウザはこのワークフローに必要なカスタムトレースヘッダーを受け入れません。代わりに、**HTTP Server** または **API** テストの背後にある計装済みバックエンドエンドポイントを使用してください。 {{% /notice %}} ## ステップ 1: ワークロードが Splunk APM にトレースを送信していることを確認する -アプリケーションが既に計装され、Splunk APM でトレースが表示されている場合は、ステップ 2 にスキップできます。そうでない場合、Kubernetes における最速の学習パスは、Operator を有効にした Splunk OpenTelemetry Collector を使用してゼロコード計装を行うことです。 +アプリケーションがすでに計装されており、Splunk APM でトレースが表示されている場合は、ステップ 2 に進んでください。そうでない場合、Kubernetes で最も速い学習パスは、ゼロコード計装用の Operator を有効にした Splunk OpenTelemetry Collector を使用することです。 -### Operator を有効にした Splunk OpenTelemetry Collector のインストール +### Operator 付き Splunk OpenTelemetry Collector のインストール ```bash helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart @@ -228,133 +229,228 @@ helm install splunk-otel-collector splunk-otel-collector-chart/splunk-otel-colle --set clusterName=$CLUSTER_NAME \ --set environment="thousandeyes-$INSTANCE" \ --set operator.enabled=true \ - --set operatorcrds.install=true + --set operatorcrds.install=true \ + --set agent.service.enabled=true ``` -### 自動計装のためのデプロイメントのアノテーション +### ワークショップのトレースターゲットとして Spring PetClinic をデプロイする -Java ワークロードの一般的な例は次のとおりです。 +このプロジェクトには、`workshop/petclinic/deployment.yaml` に Spring PetClinic マイクロサービスアプリケーションの Kubernetes デプロイメントが含まれています。ワークショップ VM では、`~/workshop/petclinic/deployment.yaml` のコピーを使用してください。 + +PetClinic マニフェストは、RUM およびロードジェネレーション設定用の `workshop-secret` を必要とします。また、いくつかのサービスに Java 自動計装アノテーションが含まれているため、アプリケーションマニフェストを適用する前に PetClinic の namespace と Instrumentation リソースを作成してください。 + +```bash +PETCLINIC_NAMESPACE=default +OTEL_COLLECTOR_NAMESPACE=otel-splunk +OTEL_INSTRUMENTATION=splunk-otel-collector + +kubectl create namespace $PETCLINIC_NAMESPACE --dry-run=client -o yaml | kubectl apply -f - +``` + +PetClinic namespace に `Instrumentation` リソースを作成または更新します。インジェクトされた Java エージェントはこのリソースを使用して、Splunk OTel Collector にスパンを送信し、ThousandEyes が送信するトレースヘッダーを受け入れます + +```bash +cat < Integrations > Integrations 2.0** に移動します。 -3. **Generic Connector** を作成し、次のように設定します。 - - **Target URL** `https://api..signalfx.com` - - **Header** `X-SF-Token: ` +1. Splunk Observability Cloud で、**API** スコープのアクセストークンを作成します。 +2. ThousandEyes で、**Manage > Integrations > Integrations 2.0** に移動します。 +3. 以下の設定で **Generic Connector** を作成します + - **Target URL**: `https://api..signalfx.com` + - **Header**: `X-SF-Token: ` 4. 新しい **Operation** を作成し、**Splunk Observability APM** を選択します。 -5. オペレーションを有効にし、統合を保存します。 +5. Operation を有効にして統合を保存します。 -![Splunk APM Generic Connector in ThousandEyes](../images/splunk-apm-generic-connector.png) +![ThousandEyes での Splunk APM Generic Connector](../images/splunk-apm-generic-connector.png) -![Splunk APM Operation in ThousandEyes](../images/splunk-apm-operation.png) +![ThousandEyes での Splunk APM Operation](../images/splunk-apm-operation.png) -## ステップ 4: 双方向の調査ループを検証する +## ステップ 4: 双方向調査ループを検証する -テストが実行され、コネクタが有効になったら、両方向のワークフローを検証します。 +テストが実行中でコネクターが有効になったら、両方向のワークフローを検証します。 ### ThousandEyes から開始する 1. ThousandEyes でテストを開きます。 2. **Service Map** タブに移動します。 -3. トレースパス、サービスのレイテンシー、下流のエラーを確認できることを確認します。 -4. ThousandEyes のリンクから **Splunk APM** に入り、完全なトレースを調査します。 +3. トレースパス、サービスレイテンシー、ダウンストリームエラーが表示されることを確認します。 +4. ThousandEyes から **Splunk APM** へのリンクを使用して、完全なトレースを検査します。 -![ThousandEyes Service Map with Splunk APM correlation](../images/thousandeyes-service-map.png) +![Splunk APM 相関が表示された ThousandEyes Service Map](../images/thousandeyes-service-map.png) ### Splunk APM で続行する -Splunk APM 内で、トレースに次のような ThousandEyes メタデータが含まれていることを確認します。 +Splunk APM 内で、トレースに以下のような ThousandEyes メタデータが含まれていることを確認します - `thousandeyes.account.id` - `thousandeyes.test.id` - `thousandeyes.permalink` - `thousandeyes.source.agent.id` -`thousandeyes.permalink` フィールド、または trace waterfall ビュー内の **Go to ThousandEyes test** ボタンを使用して、元の ThousandEyes テストに戻ります。 +`thousandeyes.permalink` フィールドまたはトレースウォーターフォールビューの **Go to ThousandEyes test** ボタンを使用して、元の ThousandEyes テストに戻ります。 -![Splunk APM trace linked back to ThousandEyes](../images/splunk-apm-trace.png) +![ThousandEyes にリンクされた Splunk APM トレース](../images/splunk-apm-trace.png) ## 推奨される学習シナリオ -ワークショップ中は次のフローを使用します。 +ワークショップでは以下のフローを使用してください 1. 複数のサービスを呼び出す内部 API ルートに対して ThousandEyes テストを作成します。 -2. ThousandEyes に問題を最初に表面化させ、ネットワークおよび合成監視の観点からクラスを開始します。 -3. ThousandEyes で **Service Map** を開き、レイテンシーやエラーが発生し始める場所を特定します。 -4. **Splunk APM** にジャンプして span レベルの分析を行います。 -5. **ThousandEyes** に戻って、テスト、エージェント、ネットワークパスを再確認します。 +2. まず ThousandEyes で問題を表面化させ、クラスがネットワークとシンセティックモニタリングの観点から開始できるようにします。 +3. ThousandEyes で **Service Map** を開き、レイテンシーやエラーの発生箇所を特定します。 +4. **Splunk APM** にジャンプしてスパンレベルの分析を行います。 +5. **ThousandEyes** に戻り、テスト、エージェント、ネットワークパスを再度検査します。 -これは、各チームが実際にどのように作業するかを反映しているため、強力な指導ループとなります。 +これは、異なるチームが実際にどのように作業するかを反映しているため、優れた学習ループとなります -- ネットワークおよびエッジチームは ThousandEyes から開始することが多い -- SRE およびプラットフォームチームは Splunk のダッシュボードまたはアラートから開始することが多い -- アプリケーションチームは通常、Splunk APM のトレースを必要とする +- ネットワークおよびエッジチームは多くの場合 ThousandEyes から開始します。 +- SRE およびプラットフォームチームは多くの場合 Splunk のダッシュボードやアラートから開始します。 +- アプリケーションチームは通常 Splunk APM のトレースを求めます。 -この統合があれば、誰もがコンテキストを失うことなく移動できます。 +この統合により、全員がコンテキストを失うことなく切り替えることができます。 ## よくある落とし穴 -- テストが Splunk のダッシュボードに表示されているのに、トレース相関がない場合があります。これは通常、**メトリクス**ストリームのみが設定されており、**Splunk APM Generic Connector** が設定されていないことを意味します。 -- トレースが Splunk APM に存在していても、監視対象のエンドポイントが下流にトレースヘッダーを伝播していない場合、ThousandEyes には表示されません。 -- `/health` のような浅いエンドポイントでは、設定が正しくてもトレースの価値が限定的なことがよくあります。 +- テストが Splunk ダッシュボードに表示されているにもかかわらず、トレース相関がない場合があります。これは通常、**メトリクス** ストリームのみが設定されており、**Splunk APM Generic Connector** が設定されていないことを意味します。 +- 監視対象のエンドポイントがトレースヘッダーをダウンストリームに伝播しない場合、Splunk APM にトレースが存在していても ThousandEyes に表示されないことがあります。 +- `/health` のような浅いエンドポイントは、構成が正しくても限られたトレース価値しか生成しないことが多いです。 -## 参考資料 +## リファレンス - [ThousandEyes Distributed Tracing](https://docs.thousandeyes.com/product-documentation/integration-guides/custom-built-integrations/distributed-tracing) - [ThousandEyes Distributed Tracing with Splunk Observability APM](https://docs.thousandeyes.com/product-documentation/integration-guides/custom-built-integrations/distributed-tracing/distributed-tracing-splunk-apm) diff --git a/content/ja/scenarios/thousandeyes-integration/4-kubernetes-testing/_index.md b/content/ja/scenarios/thousandeyes-integration/4-kubernetes-testing/_index.md index 656fc7c34a..b707cef0bc 100644 --- a/content/ja/scenarios/thousandeyes-integration/4-kubernetes-testing/_index.md +++ b/content/ja/scenarios/thousandeyes-integration/4-kubernetes-testing/_index.md @@ -1,38 +1,194 @@ --- -title: Kubernetes サービステストと相関 +title: Kubernetes サービステストと相関分析 linkTitle: 5. Kubernetes テスト weight: 5 time: 20 minutes -description: シンセティック監視とトレース相関の両方に役立つ、内部 Kubernetes テストと外部依存関係テストを作成します。 +description: シンセティック監視とトレース相関分析の両方に役立つ、内部 Kubernetes テストおよび外部依存関係テストを作成します。 --- -## AppDynamics テスト推奨機能の再現 +## AppDynamics テスト推奨の再現 -AppDynamicsには、アプリケーションのエンドポイントに対するシンセティックテストを自動的に提案する「Test Recommendations」という機能があります。ThousandEyesをKubernetesクラスター内にデプロイすることで、KubernetesのサービスディスカバリとSplunk Observability Cloudの統合ビューを組み合わせて、この機能を再現できます。 +AppDynamics には「Test Recommendations」と呼ばれる機能があり、アプリケーションのエンドポイントに対するシンセティックテストを自動的に提案します。Kubernetes クラスター内に ThousandEyes をデプロイすることで、Kubernetes のサービスディスカバリと Splunk Observability Cloud の統合ビューを組み合わせて、この機能を再現できます。 -ThousandEyes Enterprise Agentは**クラスター内部**で実行されるため、サービス名をホスト名として使用して内部Kubernetesサービスを直接テストできます。これにより、外部に公開されていないバックエンドサービスを監視する強力な方法が得られます。 +ThousandEyes Enterprise Agent は**クラスター内部**で動作するため、サービス名をホスト名として使用して内部 Kubernetes サービスを直接テストできます。これにより、外部に公開されていないバックエンドサービスを監視する強力な方法が提供されます。 ## 仕組み 1. **サービスディスカバリ**: `kubectl get svc` を使用してクラスター内のサービスを列挙します -2. **ホスト名の構築**: Kubernetes DNS命名規則を使用してテストURLを構築します: `..svc.cluster.local` +2. **ホスト名の構築**: Kubernetes DNS の命名規則 `..svc.cluster.local` を使用してテスト URL を構築します 3. **テストの作成**: 内部サービスに対して可用性テストとトレース対応トランザクションテストの両方を作成します -4. **Splunk での相関**: シンセティックテストの結果をAPMトレースおよびインフラストラクチャメトリクスと並べて表示します +4. **Splunk での相関分析**: シンセティックテストの結果を APM トレースやインフラストラクチャメトリクスと並べて表示します -## クラスター内テストのメリット +## クラスター内テストの利点 -- **内部サービス監視**: インターネットに公開されていないバックエンドサービスをテストできます +- **内部サービスの監視**: インターネットに公開されていないバックエンドサービスをテストできます - **サービスメッシュ対応**: Istio、Linkerd、その他のサービスメッシュの背後にあるサービスを監視できます -- **DNS 解決テスト**: Kubernetes DNSとサービスディスカバリを検証できます -- **ネットワークポリシー検証**: ネットワークポリシーが適切な通信を許可していることを確認できます +- **DNS 解決テスト**: Kubernetes DNS とサービスディスカバリを検証できます +- **ネットワークポリシーの検証**: ネットワークポリシーが適切な通信を許可していることを確認できます - **レイテンシベースライン**: クラスター内部のネットワークパフォーマンスを測定できます -- **本番前テスト**: Ingress/LoadBalancer経由で公開する前にサービスをテストできます +- **本番前テスト**: Ingress/LoadBalancer で公開する前にサービスをテストできます + +## ワークショップターゲット: Spring PetClinic + +このリポジトリには、ThousandEyes ガイドの Kubernetes ターゲットとして使用できる Spring PetClinic マイクロサービスアプリケーションが既に含まれています。デプロイメントマニフェストは `workshop/petclinic/deployment.yaml` にあり、ワークショップ VM では `~/workshop/petclinic/deployment.yaml` で利用可能です。 + +このマニフェストは、PetClinic のフロントエンド/API ゲートウェイ、バックエンドサービス、MySQL データベース、およびロードジェネレーターをデプロイします。また、以下も作成されます: + +- ポート `82` の `ClusterIP` サービスとしての `api-gateway` +- ポート `81` の `LoadBalancer` サービスとしての `api-gateway-external` +- 内部バックエンドサービスとしての `customers-service`、`vets-service`、`visits-service` + +{{% notice title="トレーシングのセットアップ" style="info" %}} +既に Splunk OpenTelemetry Operator をインストール済みで、PetClinic をトレース相関分析に使用する予定の場合は、このマニフェストを適用する前に Distributed Tracing セクションで PetClinic のインストルメンテーションセットアップを完了してください。PetClinic マニフェストには一部のサービスに Java インジェクションアノテーションが含まれており、Operator Webhook がアクティブな場合、これらのアノテーションには対応する `Instrumentation` リソースが必要です。 +{{% /notice %}} + +選択した Namespace に PetClinic をデプロイします: + +```bash +PETCLINIC_NAMESPACE=default + +kubectl create namespace $PETCLINIC_NAMESPACE --dry-run=client -o yaml | kubectl apply -f - + +kubectl create secret generic workshop-secret \ + -n $PETCLINIC_NAMESPACE \ + --from-literal=app=${INSTANCE:-thousandeyes}-petclinic-service \ + --from-literal=env=${INSTANCE:-thousandeyes}-petclinic \ + --from-literal=realm=${REALM:-us1} \ + --from-literal=rum_token=${RUM_TOKEN:-not-used} \ + --from-literal=url=http://api-gateway:82 \ + --dry-run=client -o yaml | kubectl apply -f - + +kubectl apply -n $PETCLINIC_NAMESPACE -f ~/workshop/petclinic/deployment.yaml +``` + +以下の例では、PetClinic が `default` Namespace にデプロイされていることを前提としています。別の Namespace にデプロイした場合は、サービス DNS 名の `default` を使用した Namespace に置き換えてください。 + +アプリケーションリソースを確認します: + +```bash +kubectl get pods -n $PETCLINIC_NAMESPACE +kubectl get svc -n $PETCLINIC_NAMESPACE api-gateway api-gateway-external customers-service vets-service visits-service +``` + +ThousandEyes エージェントが動作している Namespace からクラスター内部の到達性を検証します: + +```bash +kubectl run te-petclinic-curl \ + -n te-demo \ + --rm -it \ + --restart=Never \ + --image=curlimages/curl \ + --command -- curl -sS http://api-gateway.$PETCLINIC_NAMESPACE.svc.cluster.local:82/api/customer/owners +``` + +ThousandEyes テストに使用する PetClinic の URL です: + +```text +Availability test: +http://api-gateway.default.svc.cluster.local:82/ + +Trace-enabled API test: +http://api-gateway.default.svc.cluster.local:82/api/customer/owners + +Additional API test targets: +http://api-gateway.default.svc.cluster.local:82/api/vet/vets +http://api-gateway.default.svc.cluster.local:82/api/visit/owners/1/pets/1/visits +``` + +{{% notice title="Namespace に関する注意" style="info" %}} +ThousandEyes Enterprise Agent は `te-demo` で動作し、PetClinic は `default` で動作できます。エージェントとターゲットアプリケーションが異なる Namespace にある場合は、`api-gateway.default.svc.cluster.local` のような完全な Kubernetes DNS 名を使用してください。 +{{% /notice %}} + +## PetClinic 用の ThousandEyes テストの設定 + +少なくとも 2 つの PetClinic テストを作成します: フロントエンド用のシンプルな可用性テストと、APM 相関分析用のトレース対応 API テストです。両方のテストで同じ Kubernetes Enterprise Agent を使用し、クラスター内部から測定を行います。 + +エンドポイントを検証する際のターゲット URL のシェル変数を設定します: + +```bash +PETCLINIC_NAMESPACE=default +PETCLINIC_BASE_URL="http://api-gateway.$PETCLINIC_NAMESPACE.svc.cluster.local:82" + +kubectl run te-petclinic-curl \ + -n te-demo \ + --rm -it \ + --restart=Never \ + --image=curlimages/curl \ + --command -- curl -sS "$PETCLINIC_BASE_URL/api/customer/owners" +``` + +### テスト 1: PetClinic フロントエンドの可用性 + +このテストは、ThousandEyes Enterprise Agent からアプリケーションフロントエンドに到達可能であることを確認するために使用します。 + +1. ThousandEyes で **Cloud & Enterprise Agents > Test Settings** に移動します。 +2. **Add New Test** をクリックし、**HTTP Server** を選択します。 +3. テストを設定します: + - **Test Name**: `[PetClinic] Frontend Availability` + - **URL**: `http://api-gateway.default.svc.cluster.local:82/` + - **Interval**: `2 minutes` + - **Agents**: このガイドの前の手順でデプロイした Kubernetes Enterprise Agent を選択します + - **HTTP Response Code**: `200` + - **Verify Content**: オプション。返されるページコンテンツを検証したい場合は `PetClinic` を使用します +4. テストを保存します。 + +### テスト 2: 分散トレーシング付き PetClinic Owners API + +このテストは、ThousandEyes と Splunk APM のドリルダウンワークフローに使用します。API ゲートウェイをターゲットにし、`customers-service` にルーティングされるため、浅いヘルスチェックよりも有用なトレースが得られます。 + +1. ThousandEyes で **Cloud & Enterprise Agents > Test Settings** に移動します。 +2. **Add New Test** をクリックし、**HTTP Server** または **API** を選択します。 +3. テストを設定します: + - **Test Name**: `[Trace] PetClinic Owners API` + - **URL**: `http://api-gateway.default.svc.cluster.local:82/api/customer/owners` + - **Method**: `GET` + - **Interval**: `2 minutes` + - **Agents**: 同じ Kubernetes Enterprise Agent を選択します + - **HTTP Response Code**: `200` + - **Advanced Settings > Distributed Tracing**: Enabled + +**Basic Settings** でハイライトされたフィールドは、PetClinic API ターゲットとクラスター内の Enterprise Agent に一致する必要があります: + +![PetClinic ThousandEyes HTTP Server の基本設定](../images/te-petclinic-basic-settings.png) + +**HTTP Communication and Performance** で分散トレーシングを有効にし、API リクエストは `GET` のまま、デフォルトの `2xx` または `3xx` レスポンス検証を維持します: + +![PetClinic ThousandEyes HTTP Server のトレーシング設定](../images/te-petclinic-http-settings.png) + +4. テストを保存し、数回のインターバル分実行させます。 + +{{% notice title="トレーステストの要件" style="warning" %}} +分散トレーシングの演習には **HTTP Server** または **API** テストを使用してください。ブラウザスタイルのページロードおよびトランザクションテストはエンドユーザー監視に有用ですが、ThousandEyes と Splunk APM のワークフローに必要なトレースヘッダーを注入するための適切なテストタイプではありません。 +{{% /notice %}} + +### オプションの PetClinic API テスト + +最初の 2 つのテストが動作した後、他の PetClinic サービスをカバーする API テストを追加します: + +```text +[Trace] PetClinic Vets API +http://api-gateway.default.svc.cluster.local:82/api/vet/vets + +[Trace] PetClinic Owner Visits API +http://api-gateway.default.svc.cluster.local:82/api/visit/owners/1/pets/1/visits +``` + +同じベースライン設定を使用します: + +- **Test Type**: HTTP Server または API +- **Method**: `GET` +- **Interval**: `2 minutes` +- **Agent**: Kubernetes Enterprise Agent +- **Expected Response Code**: `200` +- **Distributed Tracing**: Splunk APM 相関分析が必要な場合は Enabled + +PetClinic を `default` Namespace 以外にデプロイした場合は、各 URL の `default` を PetClinic の Namespace に置き換えてください。 ## ステップバイステップガイド ### 1. Kubernetes サービスの検出 -クラスター内または特定のnamespace内のすべてのサービスを一覧表示します: +クラスター内のすべてのサービスまたは特定の Namespace のサービスを一覧表示します: ```bash # Get all services in all namespaces @@ -57,7 +213,7 @@ production postgres ClusterIP 10.96.100.53 5432/TCP 5d ### 2. テストホスト名の構築 -Kubernetesサービスは、以下の命名パターンを使用してDNS経由でアクセスできます: +Kubernetes サービスは以下の命名パターンを使用して DNS 経由でアクセスできます: ``` ..svc.cluster.local @@ -69,20 +225,20 @@ Kubernetesサービスは、以下の命名パターンを使用してDNS経由 - `payment-svc.production.svc.cluster.local:8080` - `auth-service.production.svc.cluster.local:9000` -**同じ namespace 内での省略形:** -ThousandEyesエージェントと同じnamespace内のサービスをテストする場合は、サービス名のみを使用できます: +**同一 Namespace 内の短縮形:** +ThousandEyes エージェントと同じ Namespace のサービスをテストする場合、サービス名のみで指定できます: - `api-gateway:8080` - `payment-svc:8080` ### 3. 内部サービス用の ThousandEyes テストの作成 -最良の学習成果を得るために、**2 種類のテスト**を作成します: +最良の学習成果を得るには、**2 種類のテスト**を作成します: -- `/health` または `/readiness` エンドポイントに対する**可用性テスト**で、到達可能性と応答時間を検証します +- `/health` または `/readiness` エンドポイントに対する**可用性テスト**で、到達性とレスポンスタイムを検証します - 複数のサービスを横断するビジネスエンドポイントに対する**トレース対応トランザクションテスト** -最初のテストはシンセティック監視を学ぶためのものです。2番目のテストはSplunk APMを使用したクロスツールトラブルシューティングを学ぶためのものです。 +最初のテストではシンセティック監視を学びます。2 番目のテストでは Splunk APM を使用したクロスツールトラブルシューティングを学びます。 #### ThousandEyes UI 経由 @@ -92,13 +248,13 @@ ThousandEyesエージェントと同じnamespace内のサービスをテスト - **Test Name**: `[K8s] API Gateway Health` - **URL**: `http://api-gateway.production.svc.cluster.local:8080/health` - **Interval**: 2 minutes - - **Agents**: KubernetesにデプロイされたEnterprise Agentを選択します + - **Agents**: Kubernetes にデプロイした Enterprise Agent を選択します - **HTTP Response Code**: `200` 4. トレース対応トランザクションテストを設定します: - **Test Name**: `[Trace] API Gateway Orders` - **URL**: `http://api-gateway.production.svc.cluster.local:8080/api/v1/orders` - **Interval**: 2 minutes - - **Agents**: KubernetesにデプロイされたEnterprise Agentを選択します + - **Agents**: Kubernetes にデプロイした Enterprise Agent を選択します - **Advanced Settings > Distributed Tracing**: Enabled 5. **Create Test** をクリックします @@ -121,44 +277,44 @@ curl -X POST https://api.thousandeyes.com/v6/tests/http-server/new \ }' ``` -トレース対応バージョンの場合は、`url` をビジネストランザクションエンドポイントに切り替え、ThousandEyesテスト設定でdistributed tracingを有効にします。 +トレース対応バージョンの場合は、`url` をビジネストランザクションエンドポイントに切り替え、ThousandEyes テスト設定で分散トレーシングを有効にします。 {{% notice title="ベストプラクティス" style="success" icon="check" %}} -distributed tracingを教えることが目的の場合、`/health` だけを例として使用することは避けてください。ヘルスチェックは稼働時間の監視には便利ですが、ThousandEyesとSplunk APMの統合を魅力的にするマルチサービストレースを生成することはほとんどありません。 +分散トレーシングを教えることが目的の場合、`/health` のみを例として使用することは避けてください。ヘルスチェックは稼働時間の監視に有用ですが、ThousandEyes と Splunk APM の統合を説得力のあるものにするマルチサービストレースを生成することはほとんどありません。 {{% /notice %}} ### 4. アラートルールの設定 一般的な障害シナリオに対するアラートを設定します: -- **可用性アラート**: HTTPレスポンスが200でない場合にトリガーします +- **可用性アラート**: HTTP レスポンスが 200 でない場合にトリガーします - **パフォーマンスアラート**: レスポンスタイムがベースラインを超えた場合にトリガーします -- **DNS 解決アラート**: サービスDNSが解決できない場合にトリガーします +- **DNS 解決アラート**: サービス DNS が解決できない場合にトリガーします -### 5. Splunk Observability Cloud での結果表示 +### 5. Splunk Observability Cloud での結果の表示 -テストが実行され、Splunkと統合されたら: +テストが実行され、Splunk と統合された後: -1. Splunk Observability Cloudで **ThousandEyes Dashboard** に移動します -2. **テスト名でフィルター**します（例: `[K8s]` プレフィックス）、すべてのKubernetes内部テストを表示します -3. **トレース対応テストの場合は、まず ThousandEyes から開始します**: +1. Splunk Observability Cloud の **ThousandEyes ダッシュボード**に移動します +2. **テスト名でフィルター**します（例: `[K8s]` プレフィックス）。すべての Kubernetes 内部テストを表示できます +3. **トレース対応テストの場合、まず ThousandEyes から開始します**: - **Service Map** を開きます - - サービスレベルのレイテンシとダウンストリームエラーを調べます + - サービスレベルのレイテンシとダウンストリームエラーを調査します - **Splunk APM** へのリンクをたどります -4. **APM データとの相関**: - - シンセティックテストの失敗をAPMエラー率と並べて表示します +4. **APM データとの相関分析**: + - シンセティックテストの失敗を APM のエラー率と並べて表示します - 問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを特定します - - Splunkトレースメタデータを使用して、元のThousandEyesテストに戻ります -5. 以下を組み合わせた**カスタムダッシュボードを作成**します: - - ThousandEyes HTTP可用性メトリクス - - APMサービスレイテンシとエラー率 - - Kubernetesインフラストラクチャメトリクス（CPU、メモリ、Pod再起動） + - Splunk のトレースメタデータを使用して、元の ThousandEyes テストに戻ります +5. **カスタムダッシュボードの作成**。以下を組み合わせます: + - ThousandEyes HTTP 可用性メトリクス + - APM サービスのレイテンシとエラー率 + - Kubernetes インフラストラクチャメトリクス（CPU、メモリ、Pod の再起動） -## ユースケース例 +## ユースケースの例 -### ユースケース 1: マイクロサービスヘルスチェック +### ユースケース 1: マイクロサービスのヘルスチェック -複数のマイクロサービスヘルスエンドポイントをテストします: +複数のマイクロサービスのヘルスエンドポイントをテストします: ```bash http://user-service.production.svc.cluster.local:8080/actuator/health @@ -168,7 +324,7 @@ http://inventory-service.production.svc.cluster.local:8080/actuator/health ### ユースケース 2: API Gateway エンドポイントテスト -有用なトレースを生成する可能性が高いAPI Gatewayルートをテストします: +有用なトレースを生成しやすい API Gateway ルートをテストします: ```bash http://api-gateway.production.svc.cluster.local:8080/api/v1/users @@ -178,7 +334,7 @@ http://api-gateway.production.svc.cluster.local:8080/api/v1/products ### ユースケース 3: データベース接続テスト -ThousandEyesは主にHTTPテスト用ですが、データベースプロキシをテストできます: +ThousandEyes は主に HTTP テスト用ですが、データベースプロキシもテストできます: ```bash # Test PgBouncer or database HTTP management interfaces @@ -186,13 +342,13 @@ http://pgbouncer.production.svc.cluster.local:8080/stats http://redis-exporter.production.svc.cluster.local:9121/metrics ``` -### ユースケース 4: 外部サービス依存関係 +### ユースケース 4: 外部サービスの依存関係 -クラスター内ThousandEyesエージェントの最も価値のある機能の1つは、サービスと同じネットワークの視点からアプリケーションの外部依存関係を監視することです。これにより、問題がインフラストラクチャ、ネットワークパス、または外部サービス自体のいずれに起因するかを特定できます。 +クラスター内の ThousandEyes エージェントの最も価値のある機能の 1 つは、サービスと同じネットワーク視点からアプリケーションの外部依存関係を監視できることです。これにより、問題がインフラストラクチャ、ネットワークパス、または外部サービス自体のいずれに起因するかを特定できます。 #### 決済ゲートウェイのテスト -重要な決済ゲートウェイエンドポイントの可用性とパフォーマンスを確保するためのテストを作成します: +重要な決済ゲートウェイエンドポイントの可用性とパフォーマンスを確認するテストを作成します: **Stripe API:** @@ -234,13 +390,13 @@ curl -X POST https://api.thousandeyes.com/v6/tests/http-server/new \ }' ``` -#### なぜ外部依存関係を監視するのか？ +#### 外部依存関係を監視する理由 - **プロアクティブな問題検出**: 顧客から報告される前に決済ゲートウェイの障害を把握できます -- **ネットワークパス検証**: Kubernetesエグレスネットワークが外部サービスに到達できることを確認します -- **パフォーマンスベースライン**: クラスターから外部APIへのレイテンシを追跡します -- **コンプライアンスと SLA 監視**: サードパーティサービスがSLAコミットメントを満たしていることを確認します -- **根本原因分析**: 問題がネットワーク関連か、インフラストラクチャか、外部プロバイダーかを迅速に判断します +- **ネットワークパスの検証**: Kubernetes のエグレスネットワークが外部サービスに到達できることを確認できます +- **パフォーマンスベースライン**: クラスターから外部 API へのレイテンシを追跡できます +- **コンプライアンスと SLA の監視**: サードパーティサービスが SLA コミットメントを満たしていることを検証できます +- **根本原因分析**: 問題がネットワーク関連、自社インフラストラクチャ、または外部プロバイダーのいずれに起因するかを迅速に判断できます #### 監視を推奨する外部サービス @@ -253,23 +409,23 @@ curl -X POST https://api.thousandeyes.com/v6/tests/http-server/new \ - **サードパーティ API**: 重要なビジネスパートナー API {{% notice title="ベストプラクティス" style="success" icon="check" %}} -テスト名に `[External]` プレフィックスを使用して、ダッシュボードで内部Kubernetesサービスと外部依存関係を簡単に区別できるようにします。 +テスト名に `[External]` プレフィックスを使用すると、ダッシュボードで内部 Kubernetes サービスと外部依存関係を簡単に区別できます。 {{% /notice %}} ## ベストプラクティス -1. **一貫した命名を使用する**: フィルタリングを容易にするため、テスト名に `[K8s]` または `[Internal]` プレフィックスを付けます -2. **まずヘルスエンドポイントをテストする**: ビジネスロジックをテストする前に `/health` または `/readiness` エンドポイントから始めます -3. **適切な間隔を設定する**: 重要なサービスには短い間隔（1〜2分）を使用します -4. **テストにタグを付ける**: ThousandEyesのラベル/タグを使用してテストをグループ化します: +1. **一貫した命名規則を使用する**: テスト名に `[K8s]` や `[Internal]` などのプレフィックスを付けてフィルタリングを容易にします +2. **まずヘルスエンドポイントをテストする**: ビジネスロジックをテストする前に `/health` や `/readiness` エンドポイントから始めます +3. **適切なインターバルを設定する**: 重要なサービスにはより短いインターバル（1～2 分）を使用します +4. **テストにタグを付ける**: ThousandEyes のラベル/タグを使用して、以下の基準でテストをグループ化します: - 環境（dev、staging、production） - サービスタイプ（API、database、cache） - - チームオーナーシップ -5. **テストエージェントの健全性を監視する**: ThousandEyesエージェントPodが健全で、十分なリソースがあることを確認します -6. **両方のテストタイプを使用する**: 各重要なサービスパスに対して、シンプルな可用性テストとトレース対応ビジネストランザクションテストをペアにします -7. **APM との相関**: シンセティックデータとAPMデータを並べて表示するSplunkダッシュボードを作成します -8. **トレースラボには計装されたバックエンドを使用する**: distributed tracingは、ThousandEyesのターゲットがOpenTelemetryで計装されたサービスによってバックアップされたHTTP ServerまたはAPIエンドポイントである場合に最も効果的です + - チームの所有者 +5. **テストエージェントの健全性を監視する**: ThousandEyes エージェント Pod が正常で、十分なリソースを持っていることを確認します +6. **両方のテストタイプを使用する**: 重要な各サービスパスに対して、シンプルな可用性テストとトレース対応のビジネストランザクションテストを組み合わせます +7. **APM との相関分析**: シンセティックデータと APM データを並べて表示する Splunk ダッシュボードを作成します +8. **トレースラボにはインストルメント済みバックエンドを使用する**: 分散トレーシングは、ThousandEyes のターゲットが OpenTelemetry でインストルメントされたサービスに支えられた HTTP Server または API エンドポイントである場合に最も効果的です {{% notice title="ヒント" style="primary" icon="lightbulb" %}} -内部サービスを外部に公開する前にテストすることで、問題を早期に発見し、ユーザートラフィックが到達する前にインフラストラクチャが健全であることを確認できます。 +内部サービスを外部に公開する前にテストすることで、問題を早期に発見し、ユーザートラフィックが到達する前にインフラストラクチャが正常であることを確認できます。 {{% /notice %}} diff --git a/content/ja/scenarios/thousandeyes-integration/_index.md b/content/ja/scenarios/thousandeyes-integration/_index.md index ad27fc7873..ef7e60da6f 100644 --- a/content/ja/scenarios/thousandeyes-integration/_index.md +++ b/content/ja/scenarios/thousandeyes-integration/_index.md @@ -5,19 +5,20 @@ weight: 5 archetype: chapter authors: ["Alec Chamberlain"] time: 120 minutes -description: ThousandEyes Enterprise Agent を Kubernetes にデプロイし、シンセティックデータを Splunk Observability Cloud にストリーミングし、ThousandEyes と Splunk APM 間の双方向ドリルダウンを有効にします。 +description: Kubernetes に ThousandEyes Enterprise Agent をデプロイし、シンセティックデータを Splunk Observability Cloud にストリーミングし、ThousandEyes と Splunk APM 間の双方向ドリルダウンを有効にします。 --- -このワークショップでは、**ThousandEyes と Splunk Observability Cloud** を統合し、シンセティックモニタリングとオブザーバビリティデータ全体にわたる統合的な可視性を提供する方法を紹介します。 +このワークショップでは、**ThousandEyes と Splunk Observability Cloud** を統合して、シンセティックモニタリングとオブザーバビリティデータ全体にわたる統一されたビジビリティを提供する方法を実演します。 ## 学習内容 このワークショップを完了すると、以下のことができるようになります -- ThousandEyes Enterprise Agent を Kubernetes のコンテナ化されたワークロードとしてデプロイする -- OpenTelemetry を使用して ThousandEyes メトリクスを Splunk Observability Cloud に統合する -- ThousandEyes と Splunk APM が同じリクエストにリンクできるよう分散トレーシングを設定する -- 内部の Kubernetes サービスおよび外部依存関係に対するシンセティックテストを作成する +- Kubernetes にコンテナ化されたワークロードとして ThousandEyes Enterprise Agent をデプロイする +- 内部 Kubernetes テストターゲットとして付属の Spring PetClinic アプリケーションをデプロイする +- OpenTelemetry を使用して ThousandEyes メトリクスを Splunk Observability Cloud と統合する +- ThousandEyes と Splunk APM が同じリクエストにリンクできるように分散トレーシングを設定する +- 内部 Kubernetes サービスおよび外部依存関係に対するシンセティックテストを作成する - Splunk Observability Cloud ダッシュボードでテスト結果を監視する - ThousandEyes から Splunk APM トレースに移動し、元の ThousandEyes テストに戻る @@ -26,26 +27,26 @@ description: ThousandEyes Enterprise Agent を Kubernetes にデプロイし、 ### コアパス - [概要](./1-overview/_index.md) - ThousandEyes のエージェントタイプとアーキテクチャを理解する -- [デプロイ](./2-deployment/_index.md) - Kubernetes に Enterprise Agent をデプロイする +- [デプロイメント](./2-deployment/_index.md) - Kubernetes に Enterprise Agent をデプロイする - [Splunk 統合](./3-splunk-integration/_index.md) - ThousandEyes メトリクスを Splunk Observability Cloud にストリーミングする - [分散トレーシング](./4-distributed-tracing/_index.md) - ThousandEyes と Splunk APM 間のサポートされた双方向ドリルダウンを有効にする ### シナリオ拡張 -- [Kubernetes テスト](./4-kubernetes-testing/_index.md) - シンセティックモニタリングとトレース相関の両方に有用な内部テストを作成する -- [RUM](./6-rum-thousandeyes/_index.md) - ThousandEyes のネットワークシグナルと Splunk RUM を関連付けてエンドユーザー調査に活用する +- [Kubernetes テスト](./4-kubernetes-testing/_index.md) - シンセティックモニタリングとトレース相関の両方に役立つ内部テストを作成する +- [RUM](./6-rum-thousandeyes/_index.md) - ThousandEyes のネットワークシグナルと Splunk RUM を相関させてエンドユーザー調査を行う ### サポート -- [トラブルシューティング](./5-troubleshooting/_index.md) - よくある問題と解決方法 +- [トラブルシューティング](./5-troubleshooting/_index.md) - よくある問題と解決策 -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このシナリオは2つの連携した統合として考えてください：OpenTelemetry ストリームが ThousandEyes メトリクスを Splunk に取り込み、分散トレーシングが Splunk APM から ThousandEyes への逆方向のパスを提供します。 +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +このシナリオは、2つの連携した統合として考えてください。OpenTelemetry ストリームが ThousandEyes メトリクスを Splunk に取り込み、分散トレーシングが Splunk APM から ThousandEyes への逆方向のパスを提供します。 {{% /notice %}} ## 前提条件 -- Kubernetes クラスター（v1.16以上） +- Kubernetes クラスター（v1.16+） - 選択した namespace にリソースをデプロイするための RBAC 権限 - Enterprise Agent トークンにアクセスできる ThousandEyes アカウント - インジェストトークンへのアクセスと APM ルックアップ用の API トークンを作成する権限を持つ Splunk Observability Cloud アカウント @@ -54,9 +55,9 @@ description: ThousandEyes Enterprise Agent を Kubernetes にデプロイし、 ThousandEyes を Splunk Observability Cloud に接続することで、以下のメリットが得られます -- 🔗 **統合的な可視性**: シンセティックテスト結果を RUM、APM トレース、およびインフラストラクチャメトリクスと相関付ける -- 📊 **強化されたダッシュボード**: 既存の Splunk オブザーバビリティメトリクスと並べて ThousandEyes データを可視化する -- 🔄 **双方向ドリルダウン**: ThousandEyes Service Map から Splunk トレースへ、また Splunk APM からリクエストを生成した ThousandEyes テストへ移動する -- 🚨 **一元化されたアラート**: Splunk 内で ThousandEyes テスト結果に基づくアラートを設定する -- 🔍 **根本原因分析**: 問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを迅速に特定する -- 📈 **包括的な分析**: Splunk の強力な分析エンジンでシンセティックモニタリングのトレンドを分析する +- 🔗 **統一されたビジビリティ**: シンセティックテスト結果を RUM、APM トレース、およびインフラストラクチャメトリクスと相関させます +- 📊 **強化されたダッシュボード**: 既存の Splunk オブザーバビリティメトリクスと並べて ThousandEyes データを可視化します +- 🔄 **双方向ドリルダウン**: ThousandEyes Service Map から Splunk トレースに移動し、Splunk APM からリクエストを生成した ThousandEyes テストに戻ることができます +- 🚨 **一元化されたアラート**: Splunk 内で ThousandEyes テスト結果に基づいたアラートを設定します +- 🔍 **根本原因分析**: 問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを迅速に特定します +- 📈 **包括的な分析**: Splunk の強力な分析エンジンでシンセティックモニタリングのトレンドを分析します diff --git a/content/ja/splunk4rookies/observability-cloud-short/2-online-boutique/_index.md b/content/ja/splunk4rookies/observability-cloud-short/2-online-boutique/_index.md new file mode 100644 index 0000000000..859b4c08f4 --- /dev/null +++ b/content/ja/splunk4rookies/observability-cloud-short/2-online-boutique/_index.md @@ -0,0 +1,48 @@ +--- +title: ショッピングに出かけましょう 💶 +linkTitle: 2. Online Boutique でお買い物 +weight: 2 +time: 5 minutes +description: Online Boutique ウェブアプリケーションを操作して、Splunk Observability Cloud 用のデータを生成します。 +--- + +{{< presenter title="Timing" >}} +Allow ~10 minutes for attendees to finish this section. +{{< /presenter >}} + +{{% notice icon="user" style="orange" title="ペルソナ" %}} + +あなたは**流行に敏感な都会のプロフェッショナル**です。有名な Online Boutique ショップで次のおしゃれアイテムを購入したいと思っています。Online Boutique は、あらゆるトレンドニーズに応えてくれる場所だと聞いています。 + +> [!splunk] この演習の目的は、Online Boutique ウェブアプリケーションを操作することです。これは Splunk Observability Cloud の機能を実演するために使用されるサンプルアプリケーションです。このアプリケーションはシンプルな EC サイトで、商品の閲覧、カートへの追加、そしてチェックアウトができます。いくつかの問題を体験し、生成したデータを使用してその問題の根本原因を特定します。 + +{{% /notice %}} + +{{% notice style="green" icon="running" title="演習 - ショッピングに出かけましょう" %}} + +* アプリケーションはデプロイ済みです。インストラクターが Online Boutique ウェブサイトへのリンクを提供します（例: `http://.show:81/`）。ポート 81 に接続できない場合は、ポート 80 および 443 も利用可能です。 +* Online Boutique を閲覧し、いくつかの商品をカートに追加して、チェックアウトを完了してください。 +* アプリケーションに意図的に組み込まれたパフォーマンスの問題を表面化させるために、これを少なくとも 3〜5 回繰り返してください。 + +--- + +{{< tabs >}} +{{% tab title="質問" %}} + +**チェックアウトプロセス全体はミリ秒単位で完了するはずです。チェックアウトプロセスで何か気づいたことはありましたか？** + +{{% /tab %}} +{{% tab title="回答" %}} + +**遅い！** 🐌 + +{{% /tab %}} +{{< /tabs >}} + +* チェックアウトプロセスが遅いと、ユーザー体験にフラストレーションを与えます。これは顧客満足度に直接影響するため、問題の調査と解決を優先すべきです。 + +![Online Boutique](images/shop.png) + +{{% /notice %}} + +次のページに進み、Splunk Observability Cloud の使用を開始して、**Splunk Real User Monitoring (RUM)** でデータがどのように表示されるかを確認しましょう。 diff --git a/content/ja/workshop-setup/5-presenter-mode.md b/content/ja/workshop-setup/5-presenter-mode.md new file mode 100644 index 0000000000..164f96de11 --- /dev/null +++ b/content/ja/workshop-setup/5-presenter-mode.md @@ -0,0 +1,64 @@ +--- +title: 5. プレゼンターモード +weight: 5 +--- + +##### **プレゼンターモードとは？** + +プレゼンターモードは、進行のヒント（タイミングの目安、「今のうちにバックグラウンドで開始してください」といったプロンプト、ワークショップを進行する人向けのその他のガイダンスなど）を表示します。これらは通常、参加者には非表示になっています。ノートは関連するステップの横にインラインで記述されるため、プレゼンテーション中にコンテキストを確認しながら進行できます。 + +--- + +##### **プレゼンターモードをオンにする** + +**任意の**ワークショップ URL に `?presenter=1` を追加し、ページを一度読み込みます。例 + +```text +https://splunk.github.io/observability-workshop/en/?presenter=1 +``` + +読み込み後、すべてのページの右下にマゼンタ色の **Presenter on** ピルが表示され、プレゼンターノートが見えるようになります。この設定はブラウザに記憶されるため、デバイスごとに一度だけ行えば十分です。 + +{{% notice style="tip" title="ブックマークのすすめ" %}} +`?presenter=1` を含めたワークショップのホームページをブックマークしておきましょう。新しいブラウザやデバイスでそのブックマークを開くだけで、プレゼンターモードが自動的にオンになります。 +{{% /notice %}} + +--- + +##### **プレゼンターモードをオフにする** + +右下にあるマゼンタ色の **Presenter on** ピルをクリックします。ピルが消え、ノートが再び非表示になります。 + +--- + +##### **プレゼンターノートの作成** + +ガイダンスを `presenter` ショートコードで囲みます。ノートには通常の Markdown（リスト、コード、リンク、画像）を含めることができます + +```markdown +{{}} +Start the EC2 instance now — boot takes ~3 minutes. +{{}} + +{{}} +Allow ~10 minutes for attendees to finish this section. +{{}} +``` + +オプションの `title` 属性を使用すると、ノート上部の小さなラベルを変更できます（デフォルトは "Presenter note"）。 + +以下はライブ例です。現在プレゼンターモードがオンの場合のみ表示されます + +{{< presenter title="Example" >}} +This is what a presenter note looks like. If you can read this, presenter mode is on. +{{< /presenter >}} + +--- + +##### **参加者に見える内容** + +何も表示されません。ノートはレンダリングされず、トグルピルも参加者には表示されません。 + +{{% notice style="warning" title="非表示ですが秘密ではありません" %}} +プレゼンターノートは CSS で非表示になっていますが、ページの HTML ソースには**含まれています**。この機能は進行のヒントやタイミングの案内にご利用ください。解答キー、認証情報、参加者に本当に見せたくない情報には使用**しないでください**。 +{{% /notice %}}