}}
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md
new file mode 100644
index 0000000000..eb460f833b
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md
@@ -0,0 +1,147 @@
+---
+title: 3. アプリケーション負荷の生成
+weight: 3
+description: このセクションでは、サンプルアプリケーションをインストールし、負荷生成を開始します
+---
+このエクササイズでは、以下のアクションを実行します。
+
+* サンプルアプリが実行されていることを確認します。
+* サンプルアプリケーション向けの負荷生成を開始します。
+* Controller でトランザクション負荷を確認します。
+
+## サンプルアプリケーションが実行されていることを確認する
+
+サンプルアプリケーションのホームページは、以下の形式の URL でウェブブラウザからアクセスできます。EC2 インスタンスの IP アドレスに置き換えて、その URL をブラウザのアドレスバーに入力してください。
+
+```bash
+http://[ec2-ip-address]:8080/Supercar-Trader/home.do
+```
+
+Supercar Trader アプリケーションのホームページが表示されるはずです。
+
+
+## 負荷生成を開始する
+
+EC2 インスタンスに SSH 接続し、負荷生成を開始します。すべてのスクリプトの実行には数分かかる場合があります。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./start_load.sh
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+Cleaning up artifacts from previous load...
+Starting home-init-01
+Waiting for additional JVMs to initialize... 1
+Waiting for additional JVMs to initialize... 2
+Waiting for additional JVMs to initialize... 3
+Waiting for additional JVMs to initialize... 4
+Waiting for additional JVMs to initialize... 5
+Waiting for additional JVMs to initialize... 6
+Waiting for additional JVMs to initialize... 7
+Waiting for additional JVMs to initialize... 8
+Waiting for additional JVMs to initialize... 9
+Waiting for additional JVMs to initialize... 10
+Waiting for additional JVMs to initialize... 11
+Waiting for additional JVMs to initialize... 12
+Waiting for additional JVMs to initialize... 13
+Waiting for additional JVMs to initialize... 14
+Waiting for additional JVMs to initialize... 15
+Waiting for additional JVMs to initialize... 16
+Waiting for additional JVMs to initialize... 17
+Waiting for additional JVMs to initialize... 18
+Waiting for additional JVMs to initialize... 19
+Waiting for additional JVMs to initialize... 20
+Starting slow-query-01
+Starting slow-query-02
+Starting slow-query-03
+Starting slow-query-04
+Starting sessions-01
+Starting sessions-02
+Starting sell-car-01
+Starting sell-car-02
+Starting sessions-03
+Starting sessions-04
+Starting search-01
+Starting request-error-01
+Starting mem-leak-insurance
+Finished starting load generator scripts 100% 22MB 255.5KB/s 01:26
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Controller でトランザクション負荷を確認する
+
+Getting Started Wizard をウェブブラウザで開いたままにしている場合、エージェントが接続され、Controller がデータを受信していることが確認できるはずです。
+
+
+
+**Continue** をクリックすると、**Application Flow Map** に移動します（以下の Flow Map の画像までスキップしても構いません）。
+
+Controller のブラウザウィンドウを既に閉じている場合は、Controller に再度ログインしてください。
+
+1. Overview ページ（ランディングページ）から、左側のナビゲーションパネルにある **Applications** タブをクリックします。
+
+ 
+
+2. **Applications** ページ内で、アプリケーションを手動で検索するか、右上の検索バーを使って検索を絞り込むことができます。
+
+ 
+
+アプリケーション名をクリックすると、**Application Flow Map** に移動します。12 分後にすべてのアプリケーションコンポーネントが表示されるはずです。
+
+12 分経ってもすべてのアプリケーションコンポーネントが表示されない場合は、もう少し待ってからブラウザのタブを更新してみてください。
+
+
+
+エージェントのダウンロード手順では、Tomcat サーバー用に Tier 名と Node 名を割り当てました。
+
+``` bash
+
Web-Portal
+
Web-Portal_Node-01
+```
+
+他の 4 つのサービスにどのように Tier 名と Node 名が割り当てられたのか疑問に思うかもしれません。サンプルアプリケーションは、最初の Tomcat JVM から 4 つの追加の JVM を動的に作成し、4 つの各サービス向けに Tier 名と Node 名を JVM 起動コマンドの -D プロパティとして渡すことで割り当てます。JVM 起動コマンドラインに含まれる -D プロパティは、Java エージェントの ```controller-info.xml``` ファイルで定義されたプロパティよりも優先されます。
+
+動的に起動された 4 つの各サービスに使用された JVM 起動パラメータを確認するには、EC2 インスタンスのターミナルウィンドウで以下のコマンドを実行してください。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+ps -ef | grep appdynamics.agent.tierName
+```
+
+{{% /tab %}}
+{{% tab title="Loadgen Output" %}}
+
+``` bash
+splunk 47131 46757 3 15:34 pts/1 00:08:17 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Api-Services -Dappdynamics.agent.nodeName=Api-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.api.ApiService
+splunk 47133 46757 2 15:34 pts/1 00:08:11 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Inventory-Services -Dappdynamics.agent.nodeName=Inventory-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.inventory.InventoryService
+splunk 47151 46757 1 15:34 pts/1 00:04:58 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Insurance-Services -Dappdynamics.agent.nodeName=Insurance-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx68m -XX:MaxPermSize=256m supercars.services.insurance.InsuranceService
+splunk 47153 46757 3 15:34 pts/1 00:08:17 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -javaagent:/opt/appdynamics/javaagent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Supercar-Trader-AppD-Workshop -Dappdynamics.agent.tierName=Enquiry-Services -Dappdynamics.agent.nodeName=Enquiry-Services_Node-01 -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj6a4d7h2cuq -Xms64m -Xmx512m -XX:MaxPermSize=256m supercars.services.enquiry.EnquiryService
+splunk 144789 46722 0 20:09 pts/1 00:00:00 grep --color=auto appdynamics.agent.tierName
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+すべてのコンポーネントがフローマップに表示されると、Insurance-Services Tier から呼び出されている 3 つの HTTP バックエンドを表す HTTP クラウドアイコンが見えるはずです。
+
+以下の手順に従って、3 つの HTTP バックエンドのグループを解除します。
+
+1. 「3 HTTP backends」とラベル付けされた HTTP クラウドアイコンを右クリックします
+2. ドロップダウンメニューから「Ungroup Backends」を選択します
+
+
+
+HTTP バックエンドのグループが解除されると、以下の画像のように 3 つの HTTP バックエンドがすべて表示されるはずです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md
new file mode 100644
index 0000000000..f1159f4fec
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md
@@ -0,0 +1,91 @@
+---
+title: 4. AppDynamics のコアコンセプト
+weight: 4
+description: このセクションでは、Splunk AppDynamics APM 機能のコアコンセプトについて学びます
+---
+
+このセクションでは、Splunk AppDynamics APM 機能のコアコンセプトについて学びます。このセクションを終える頃には、以下の概念を理解できるようになります。
+
+- Application Flow Maps
+- Business Transactions (BTs)
+- Snapshots
+- Call Graphs
+
+## Flow Maps
+
+AppDynamics アプリエージェントは、最も一般的なアプリケーションフレームワークやサービスを自動的に検出します。組み込みのアプリケーション検出機能と設定を使用して、エージェントはアプリケーションのデータとメトリクスを収集し、Flow Maps を構築します。
+
+AppDynamics はすべてのトランザクションを自動的にキャプチャしてスコアリングします。Flow Maps は、選択した時間枠のコンテキストに沿って、監視対象のアプリケーション環境のコンポーネントとアクティビティを動的にビジュアル表現します。
+
+Flow Map のさまざまな機能について慣れていきましょう。
+
+1. さまざまなレイアウトオプションを試してみてください（Flow Map 上の各アイコンをクリックしてドラッグし、位置を変更することもできます）。
+2. スライダーやマウスのスクロールホイールを使ってズームレベルを調整してみましょう。
+3. Transaction Scorecard を確認します。
+4. Flow Map を編集するためのオプションを確認します。
+
+Flow Maps の詳細については[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-applications/flow-maps/flow-map-overview)をご覧ください。
+
+
+
+## Business Transactions
+
+AppDynamics のモデルにおいて、Business Transaction はリクエスト（多くの場合ユーザーリクエスト）に対するデータ処理フローを表します。実際のシステムでは、アプリケーションの多くの異なるコンポーネントが連携して、以下のようなリクエストを処理するためのサービスを提供します。
+
+- e コマースアプリケーションでは、ユーザーがログインしたり、商品を検索したり、商品をカートに追加したりする操作。
+- コンテンツポータルでは、ユーザーがスポーツ、ビジネス、エンターテインメントなどのニュースコンテンツをリクエストする操作。
+- 株式取引アプリケーションでは、株価情報の取得、株式の売買などの操作。
+AppDynamics はパフォーマンス監視を Business Transactions を中心に構成しているため、ユーザー視点でアプリケーションコンポーネントのパフォーマンスにフォーカスできます。コンポーネントが利用可能な状態にあるか、パフォーマンスの問題が発生しているかを素早く特定できます。例えば、ユーザーがログイン、チェックアウト、データ閲覧などの操作を実行できているかを確認できます。ユーザーへのレスポンスタイムや、問題発生時の原因を確認できます。
+
+Business Transactions の詳細については[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/overview-of-application-monitoring/business-transactions)および[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-transactions)をご覧ください。
+
+## Business Transactions の確認
+
+以下の手順で、Business Transactions が自動的に検出されていることを確認します。
+
+1. 左メニューの **Business Transactions** オプションをクリックします。
+2. Business Transactions の一覧とそのパフォーマンスを確認します。
+
+
+
+## Snapshots
+
+AppDynamics は、計装された環境において Business Transaction の実行をすべて監視し、メトリクスはこれらすべての実行を反映します。ただし、トラブルシューティングを目的として、AppDynamics は問題が発生している特定のトランザクションインスタンスについて、深い診断情報を含むスナップショットを取得します。
+
+以下の手順で、トランザクションスナップショットが自動的に収集されていることを確認します。
+
+1. 左メニューの **Application Dashboard** オプションをクリックします。
+2. **Transaction Snapshots** タブをクリックします。
+3. **Exe Time (ms)** カラムをクリックして、実行時間が最も長いスナップショット順にソートします。
+4. Business Transaction のスナップショットをダブルクリックすると、スナップショットビューアーが表示されます。
+
+
+
+トランザクションスナップショットは、トランザクションの 1 回の呼び出しについて、ティアをまたいだ処理フローを確認できます。
+
+**Potential Issues** パネルでは、遅いメソッドや遅いリモートサービス呼び出しが強調表示され、パフォーマンス問題の根本原因の調査に役立ちます。
+
+## Drill Downs と Call Graphs
+
+Call graphs と drill downs は、ティア上でのトランザクション実行に関する重要な情報、例えば最も遅いメソッド、エラー、リモートサービス呼び出しなどを提供します。drill down には、部分的または完全な call graph が含まれる場合があります。Call graphs は、特定のティアにおける Business Transaction の処理をコードレベルで可視化します。
+
+Business Transaction スナップショットの Flow Map 上で、Drill Down リンクが付いているティアは、AppDynamics がそのティアで call graph を取得していることを示します。
+
+以下の手順で、トランザクションスナップショットの call graph にドリルダウンします。
+
+1. 左側の Potential Issues リストで遅い呼び出しをクリックします。
+2. Drill Down into Call Graph をクリックします。
+
+
+
+call graph ビューには以下の詳細情報が表示されます。
+
+1. メソッド実行シーケンスは、このノード上で Business Transaction の処理に関わったクラスとメソッドの名前を、制御フローの順序で表示します。
+2. 各メソッドについて、処理に費やされた時間と割合、ソースコード内の行番号を確認できるため、トランザクションのパフォーマンスに影響を与えている可能性のあるコード位置を特定できます。
+3. call graph には、データベースクエリやウェブサービス呼び出しなど、他のコンポーネントへの外部呼び出しを行うメソッドの exit call リンクが表示されます。
+
+Transaction Snapshots の詳細については[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-transactions/troubleshoot-business-transaction-performance-with-transaction-snapshots)をご覧ください。
+
+Call Graphs の詳細については[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-transactions/troubleshoot-business-transaction-performance-with-transaction-snapshots/call-graphs)をご覧ください。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md
new file mode 100644
index 0000000000..da7f2fa656
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md
@@ -0,0 +1,73 @@
+---
+title: 5. Controller の設定
+weight: 5
+description: このセクションでは、Controller でさまざまな APM 設定を構成する方法を学びます
+---
+
+
+この演習では、以下のタスクを実施します。
+
+- Business Transaction の設定を調整します。
+- Call Graph の設定を調整します。
+- Business Transaction の変化を観察します。
+
+## Business Transaction 設定の調整
+
+前の演習で、Business Transaction が自動検出されていることを確認しました。Business Transaction の自動検出ルールを最適な状態にするために、ルールを調整したい場合があります。今回のサンプルアプリケーションは古い Apache Struts フレームワークで構築されており、まさにそうしたケースに該当します。
+
+次の画像でハイライトされている Business Transaction を見ると、それぞれのペアが Struts Action (.execute) と Servlet タイプ (.jsp) で構成されていることがわかります。これら 2 種類のトランザクションが 1 つに統合されるように、トランザクション検出ルールの設定を調整していきます。
+
+AppDynamics UI で時間枠セレクターが表示されているときは、表示されているビューは選択した時間枠のコンテキストを表します。あらかじめ定義された時間枠から選ぶことも、確認したい日付や時間範囲を指定したカスタム時間枠を作成することもできます。
+
+1. **last 1 hour** の時間枠を選択します。
+2. マウスを青いアイコンの上にホバーして、トランザクションの Entry Point Type を確認します。
+
+
+
+以下の手順でトランザクション検出を最適化します。
+
+1. 左下メニューの **Configuration** オプションをクリックします。
+2. **Instrumentation** リンクをクリックします。
+
+ 
+
+3. Instrumentation メニューから **Transaction Detection** を選択します。
+4. **Java Auto Discovery Rule** を選択します。
+5. **Edit** をクリックします。
+
+ 
+
+6. Rule Editor で **Rule Configuration** タブを選択します。
+7. **Struts Action** セクションのチェックボックスをすべてオフにします。
+8. **Web Service** セクションのチェックボックスをすべてオフにします。
+9. 下にスクロールして Servlet 設定を見つけます。
+10. **Enable Servlet Filter Detection** のチェックボックスをオンにします（Servlet 設定では 3 つのチェックボックスがすべてオンになっている状態にします）。
+11. **Save** をクリックして変更を保存します。
+
+Transaction Detection Rules の詳細は[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/configure-instrumentation/transaction-detection-rules)で確認できます。
+
+
+
+
+## Call Graph 設定の調整
+
+以下の Call Graph Settings ウィンドウを使用すると、トランザクションスナップショット内の Call Graph で取得されるデータを制御できます。このステップでは、各 SQL クエリのパラメータを完全なクエリと共に取得するように SQL Capture 設定を変更します。SQL Capture の設定は以下の手順で変更できます。
+
+1. Instrumentation ウィンドウから **Call Graph Settings** タブを選択します。これは前の演習で開いた **Instrumentation** 設定の中にあります。
+2. 設定内で **Java** タブが選択されていることを確認します。
+3. **SQL Capture Settings** が表示されるまで下にスクロールします。
+4. **Capture Raw SQL** オプションをクリックします。
+5. **Save** をクリックします。
+
+Call Graph 設定の詳細は[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/configure-instrumentation/call-graph-settings)で確認できます。
+
+
+
+## Business Transaction の変化を観察する
+
+新しい Business Transaction が以前のトランザクションを置き換えるまで、最大で 30 分かかることがあります。新しいトランザクションが検出された後の Business Transaction のリストは、次の例のような表示になります。
+
+1. 左メニューの **Business Transactions** をクリックします。
+2. 時間範囲ピッカーを **last 15 minutes** に調整します。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md
new file mode 100644
index 0000000000..7044715ca7
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md
@@ -0,0 +1,108 @@
+---
+title: 6. 遅いトランザクションのトラブルシューティング
+weight: 6
+description: このセクションでは、スナップショットを利用して遅いトランザクションをトラブルシューティングする方法を学びます
+---
+
+この演習では、以下のタスクを実行します。
+
+- アプリケーションダッシュボードとフローマップを監視する。
+- 遅いトランザクションのスナップショットをトラブルシューティングする。
+
+## アプリケーションダッシュボードとフローマップの監視
+
+これまでの演習では、Application Flow Map の基本的な機能をいくつか確認してきました。ここでは、Application Dashboard と Flow Map を活用して、アプリケーション内の問題を即座に特定する方法をより深く見ていきます。
+
+1. Health Rule Violations、Node Health の問題、および Business Transactions の健全性は、選択した時間枠について常にこのエリアに表示されます。ここで利用できるリンクをクリックすると、詳細にドリルダウンできます。
+2. Transaction Scorecard では、normal、slow、very slow、stalled、およびエラーが発生したトランザクションの数と割合が表示されます。スコアカードでは、例外タイプの上位カテゴリも確認できます。ここで利用できるリンクをクリックすると、詳細にドリルダウンできます。
+3. 異なるアプリケーションコンポーネントを接続している青い線のいずれかを左クリック（シングルクリック）すると、2 つのコンポーネント間のやり取りの概要が表示されます。
+4. Tier の色付きリングの中を左クリック（シングルクリック）すると、Flow Map に留まったまま、その Tier に関する詳細情報が表示されます。
+5. ダッシュボード下部にある 3 つのチャート（Load、Response Time、Errors）のいずれかの時系列にカーソルを合わせると、記録されたメトリクスの詳細が表示されます。
+
+ 
+
+次に、Dynamic Baselines と、ダッシュボード下部のチャートのオプションについて見ていきます。
+
+1. チャート上のメトリクスを、各メトリクスについて自動的に計算された Dynamic Baseline と比較します。
+2. Dynamic Baseline は、以下の画像に示されているように、load チャートと response time チャートに青い点線で表示されます。
+3. ダッシュボード下部にある 3 つのチャートのいずれかで見られるスパイクをハイライトするには、左クリックしたままマウスボタンを押し続け、左から右にドラッグします。
+4. マウスボタンを離し、ポップアップメニューに表示される 3 つのオプションのいずれかを選択します。
+
+ 
+
+AppDynamics 独自の Dynamic Baselining の精度は時間の経過とともに向上し、アプリケーション、そのコンポーネント、およびビジネストランザクションの状態を正確に把握できるようにします。これにより、状況がクリティカルな状態になる前にプロアクティブにアラートを受け取り、エンドユーザーに影響が及ぶ前に対応できます。
+
+AppDynamics の Dynamic Baselines については、[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/business-transactions/monitor-the-business-transaction-performance/dynamic-baselines) で詳しく説明しています。
+
+## 遅いトランザクションスナップショットのトラブルシューティング
+
+次の手順に従って、ビジネストランザクションを確認し、very slow なトランザクションが最も多いものを見つけてみましょう。
+
+1. 左メニューの **Business Transactions** オプションをクリックします。
+2. **View Options** ボタンをクリックします。
+3. オプションのチェックボックスを、以下の画像と一致するようにオンまたはオフにします。
+
+ 
+
+4. /Supercar-Trader/car.do という名前の Business Transaction を見つけ、その Very Slow Transactions の数値をクリックして、very slow なトランザクションのスナップショットにドリルダウンします。
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+/Supercar-Trader/car.do BT に Very Slow Transactions が存在しない場合は、Very Slow Transactions が発生している別の Business Transaction を見つけ、その列の数値をクリックしてください。スクリーンショットは多少異なる場合がありますが、概念は同じです。
+{{% /notice %}}
+
+ 
+
+5. very slow なトランザクションのスナップショット一覧が表示されます。以下のように、最も応答時間が長いスナップショットをダブルクリックします。
+
+ 
+
+ トランザクションスナップショットビューアが開くと、この特定のトランザクションに含まれていたすべてのコンポーネントの flow map ビューが表示されます。このスナップショットでは、トランザクションが以下のコンポーネントを順に通過したことが示されています。
+
+ - Web-Portal Tier
+ - Api-Services Tier
+ - Enquiry-Services Tier
+ - MySQL Database
+
+ 左側の Potential Issues パネルでは、slow methods と slow remote services がハイライト表示されます。Potential Issues パネルからコールグラフへ直接ドリルダウンすることもできますが、この例ではスナップショット内の Flow Map を使用してトランザクション全体を追跡します。
+
+6. スナップショットの Flow Map に表示されている Web-Portal Tier の Drill Down をクリックします。
+
+ 
+
+ 開いたタブには、Web-Portal Tier のコールグラフが表示されます。ほとんどの時間が outbound HTTP call で消費されていることがわかります。
+
+7. ブロックをクリックして、問題が発生しているセグメントにドリルダウンします。HTTP リンクをクリックして、ダウンストリーム呼び出しの詳細を表示します。
+
+ 
+
+ ダウンストリーム呼び出しの詳細パネルには、Web-Portal Tier が Api-Services Tier に対して outbound HTTP call を行ったことが示されています。HTTP call をたどって Api-Services Tier に進みます。
+
+8. Drill Down into Downstream Call をクリックします。
+
+ 
+
+ 次に開くタブには、Api-Services Tier のコールグラフが表示されます。100% の時間が outbound HTTP call によるものだったことがわかります。
+
+9. HTTP リンクをクリックして、ダウンストリーム呼び出しの詳細パネルを開きます。
+
+ 
+
+ ダウンストリーム呼び出しの詳細パネルには、Api-Services Tier が Enquiry-Services Tier に対して outbound HTTP call を行ったことが示されています。HTTP call をたどって Enquiry-Services Tier に進みます。
+
+10. Drill Down into Downstream Call をクリックします。
+
+ 
+
+ 次に開くタブには、Enquiry-Services Tier のコールグラフが表示されます。データベースへの JDBC calls がトランザクションの問題を引き起こしていたことがわかります。
+
+11. 最も時間がかかっている JDBC リンクをクリックして、JDBC calls の詳細パネルを開きます。
+
+ 
+
+ JDBC exit calls の詳細パネルには、最も時間を消費した特定のクエリが表示されます。完全な SQL ステートメントと、SQL パラメータの値を確認できます。
+
+ 
+
+## まとめ
+
+このラボでは、まず Business Transactions を使用して、トラブルシューティングが必要な very slow なトランザクションを特定しました。次にコールグラフを調査して、遅延の原因となっているコードの具体的な箇所を特定しました。その後、ダウンストリームサービスとデータベースにドリルダウンして、遅延の根本原因をさらに分析しました。最終的に、パフォーマンスの問題の原因となっていた非効率な SQL クエリを正確に特定することができました。この一連のアプローチは、AppDynamics がトランザクションのボトルネックを効果的に切り分けて解決するのにどのように役立つかを示しています。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md
new file mode 100644
index 0000000000..9fc0181baa
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md
@@ -0,0 +1,106 @@
+---
+title: 7. エラーと例外のトラブルシューティング
+weight: 7
+description: このセクションでは、アプリケーション内のエラーをトラブルシューティングする方法を学びます
+---
+
+この演習では、アプリケーション内のエラーを効果的に検出・診断し、根本原因を特定する方法を学びます。さらに、パフォーマンスが低下していたりエラーが発生していたりする特定のノードを特定する方法を学び、これらのパフォーマンス問題を解決するためのトラブルシューティング手法を適用します。このハンズオンの経験により、アプリケーションの健全性を維持し、最適なパフォーマンスを確保する能力が向上します。
+
+## アプリケーション内の特定のエラーを見つける
+
+AppDynamics を使用すると、アプリケーション内のエラーや例外を簡単に見つけることができます。**Errors** ダッシュボードを使用して、エラーを伴うトランザクションのスナップショットを確認したり、最も頻繁に発生している例外を見つけたりすることができます。エラーを迅速に特定することで、アプリケーションの安定性とユーザー体験を向上させる修正の優先順位付けが容易になります。例外の種類と頻度を理解することで、最も影響の大きい問題に集中することができます。
+
+1. 左メニューの **Troubleshoot** オプションをクリックします。
+2. 左メニューの **Errors** オプションをクリックします。これにより、エラーを伴うビジネストランザクションを迅速に特定できる Errors ダッシュボードに移動します。
+3. いくつかのエラートランザクションスナップショットを確認します。スナップショットを確認することで、エラーが発生したときの正確なコンテキストとフローを把握できます。
+4. **Exceptions** タブをクリックして、タイプ別にグループ化された例外を確認します。例外タイプ別にグループ化することで、繰り返し発生する問題やパターンを特定しやすくなります。
+
+ 
+
+ **Exceptions** タブには、アプリケーション内で最も多く発生している例外のタイプが表示されるため、最も影響の大きいものから優先的に修正することができます。
+
+5. **Exceptions per minute** と **Exception count** (6) を観察し、エラーの頻度を把握します。頻度の高い例外は、即座に対応が必要な重大な問題を示していることがよくあります。
+6. 例外が発生している **Tier** に注目して、アプリケーションアーキテクチャ内での問題箇所を特定します。影響を受けている tier を知ることで、根本原因の絞り込みに役立ちます。
+7. MySQLIntegrityConstraintViolationException タイプをダブルクリックして、さらに詳しく調べます。
+
+ 
+
+8. この例外タイプが発生したスナップショットを表示する概要ダッシュボードを確認します。
+9. **Stack Traces for this Exception** というラベルのタブには、この例外タイプによって生成された一意のスタックトレースの集計リストが表示されます。スタックトレースは、エラーを引き起こしている正確なコードパスを示しており、デバッグに不可欠です。
+10. スナップショットをダブルクリックして開き、コンテキスト内でエラーを確認します。
+これにより、トランザクションフローが表示され、エラーが発生した場所が特定されます。
+
+ 
+
+ 例外画面からエラースナップショットを開くと、スナップショット内のエラーが発生した特定のセグメントが開きます。
+
+11. エラーや例外を示す赤いテキストの exit call に注目します。
+12. exit call をドリルダウンして、詳細なエラー情報を表示します。
+13. **Error Details** をクリックして、完全なスタックトレースを表示します。完全なスタックトレースは、開発者がバグを追跡して修正するために重要です。
+
+{{% notice title="Tip" style="primary" icon="lightbulb" %}}
+エラー処理と例外について詳しく学びたい場合は、次のリンクから AppDynamics の公式ドキュメントを参照してください: [here](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/troubleshooting-applications/errors-and-exceptions)。
+{{% /notice %}}
+
+
+
+## ノードの問題のトラブルシューティング
+
+ノードの健全性は、アプリケーションのパフォーマンスと可用性に直接影響します。ノードの問題を早期に検出することで、障害を防ぎ、スムーズな運用を確保できます。AppDynamics は UI 全体に視覚的なインジケーターを提供しており、問題を迅速に特定することが容易になります。
+
+ノードの問題のインジケーターは、Application Dashboard の 3 つの領域で確認できます。
+
+1. **Application Dashboard** を観察して、ノードの問題の視覚的なインジケーターを確認します。色の変化やアイコンによって、問題が即座に通知されます。
+2. **Events** パネルには、Node Health に関連するものを含む Health Rule Violations が表示されます。
+3. **Node Health** パネルには、ノードで発生している critical または warning の問題の数が表示されます。**Node Health** パネルの Node Health リンクをクリックして、**Tiers & Nodes dashboard** にドリルダウンします。
+
+ 
+
+4. または、左メニューの **Tiers & Nodes** をクリックして、**Tiers & Nodes dashboard** にアクセスすることもできます。
+5. Grid View に切り替えて、整理されたノードのリストを表示します。Grid view を使用すると、警告のあるノードのスキャンと検索が容易になります。
+6. Insurance-Services_Node-01 ノードの警告アイコンをクリックします。
+
+ 
+
+7. Health Rule Violations の概要を確認し、違反の説明をクリックします。
+8. **Details** ボタンをクリックして、詳細を表示します。
+
+ 
+
+ **Health Rule Violation** の詳細ビューアには、次の情報が表示されます。
+
+9. 違反の現在の状態。
+10. 違反が発生していた時間のタイムライン。
+11. 違反の具体的な内容と、それをトリガーした条件。
+12. **View Dashboard During Health Rule Violation** をクリックして、問題発生時のノードのメトリクスを確認します。違反とパフォーマンスメトリクスを関連付けることで、診断に役立ちます。
+
+ 
+
+ **View Dashboard During Health Rule Violation** ボタンをクリックすると、デフォルトでノードダッシュボードの **Server** タブが開きます。
+
+ AppDynamics Server Visibility Monitoring agent をまだインストールしていない場合は、ノードのホストのリソースメトリクスは表示されません。これらのメトリクスは次のラボで確認できます。AppDynamics Java agent は、JMX を介して JVM からメモリメトリクスを収集します。
+
+ 以下の手順で JVM ヒープデータを調査します。
+
+13. **Memory** タブをクリックします。
+14. 現在のヒープ使用率を確認します。
+15. 発生している Major Garbage Collections に注目します。
+
+注: Memory 画面の表示に問題がある場合は、別のブラウザを使用してみてください (Firefox は Windows、Linux、Mac で正しくレンダリングされます)。
+
+ 
+
+16. 外側のスクロールバーを使用して、画面の最下部までスクロールします。
+17. **PS Old Gen** メモリ使用量が高い場合は、メモリリークまたは非効率なガベージコレクションの兆候である可能性があるため注意します。メモリ圧迫を早期に特定することで、障害を防ぐことができます。
+
+ノードと JVM のモニタリングについては、[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/tiers-and-nodes/troubleshoot-node-problems) と [こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/tiers-and-nodes/monitor-jvms) で詳しく説明しています。
+
+
+
+## まとめ
+
+このラボでは、AppDynamics を効果的に使用して、アプリケーションのエラーとノードの健全性の問題を特定およびトラブルシューティングする方法を学びました。まず、Errors ダッシュボードを使用して特定のエラーや例外を見つけ、その頻度、タイプ、アプリケーションへの影響を理解しました。エラースナップショットとスタックトレースをドリルダウンして、障害の根本原因を特定しました。
+
+次に、Application Dashboard の視覚的なインジケーターを解釈し、Health Rule Violations を調査することで、ノードの健全性モニタリングを探索しました。JVM メモリメトリクスを分析して、ガベージコレクションとヒープ使用量に関連する潜在的なパフォーマンスのボトルネックを検出する方法を学びました。
+
+これらのスキルを組み合わせることで、プロアクティブなモニタリングと迅速なトラブルシューティングが可能になり、アプリケーションのパフォーマンスと信頼性を維持できます。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/_index.md
new file mode 100644
index 0000000000..193dd42d83
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/1-application-performance-monitoring/_index.md
@@ -0,0 +1,42 @@
+---
+title: Application Performance Monitoring (APM)
+time: 2 minutes
+weight: 1
+description: このラボでは、Splunk AppDynamics を使用してアプリケーションサービスの健全性を監視する方法を学びます。
+---
+
+## 目的
+
+このラボでは、AppDynamics を使用してアプリケーションサービスの健全性を監視する方法を学びます。本ワークショップの他のラボを開始する前に、まずこのラボを完了する必要があります。
+
+このラボを完了すると、以下のことができるようになります。
+
+- AppDynamics Java APM Agent をダウンロードする。
+- AppDynamics Java APM Agent をインストールする。
+- サンプルアプリケーションに負荷をかけて初期化する。
+- AppDynamics APM のコアコンセプトを理解する。
+- Controller でコレクション設定を構成する。
+- アプリケーションの健全性を監視する。
+- アプリケーションパフォーマンスの問題をトラブルシューティングし、根本原因を特定する。
+- AppDynamics によって収集されたデータに基づいて、AppDynamics の監視サービスのアラートを監視する。
+
+## ワークショップ環境
+
+ワークショップ環境には 2 つのホストがあります。
+
+- 1 つ目のホストは AppDynamics Controller を実行しており、以降「Controller」と呼びます。
+- 2 つ目のホストはラボで使用する Supercar Trader アプリケーションを実行しています。AppDynamics エージェントをインストールするホストであり、以降「Application VM」と呼びます。
+
+## Controller
+
+このワークショップでは [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を使用します。
+
+
+
+## Application VM
+
+Supercar Trader は Java ベースの Web アプリケーションです。
+
+Supercar-Trader collection の目的は、AppDynamics Controller のために動的なトラフィック（Business Transactions）を生成することです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md
new file mode 100644
index 0000000000..fde4be6167
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md
@@ -0,0 +1,107 @@
+---
+title: ラボの前提条件
+time: 2 minutes
+weight: 1
+description: この演習では、Splunk AppDynamics コントローラーへのアクセス、アプリケーションへのトランザクション負荷の確認、必要に応じてアプリケーションとトランザクション負荷の再起動を行います。
+draft: true
+---
+
+## コントローラーへのログイン
+
+Cisco の認証情報を使用して、[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインします。
+
+## アプリケーションへのトランザクション負荷を確認する
+
+アプリケーションのフローマップを確認します。
+
+1. 過去 1 時間の時間枠を選択します。
+2. フローマップ上で 5 つの異なる Tier が表示されていることを確認します。
+3. 過去 1 時間の間に一貫した負荷があることを確認します。
+
+
+
+ビジネストランザクションの一覧を確認します。
+
+1. 左側のメニューから Business Transactions オプションをクリックします。
+2. 以下に示す 11 件のビジネストランザクションが表示されていることを確認します。
+3. 過去 1 時間の間に何らかの数の呼び出しがあったことを確認します。
+
+注: Calls 列が表示されていない場合は、View Options ツールバーボタンをクリックして該当の列を表示できます。
+
+
+
+ノードのエージェントステータスを確認します。
+
+1. 左側のメニューから Tiers & Nodes オプションをクリックします。
+2. Grid View をクリックします。
+3. 過去 1 時間の間、各ノードの App Agent Status が 90% を超えていることを確認します。
+
+
+
+## 必要に応じてアプリケーションとトランザクション負荷を再起動する
+
+前のステップで実行したチェックのいずれかが確認できなかった場合は、Application VM に SSH 接続し、以下の手順に従ってアプリケーションとトランザクション負荷を再起動します。インスタンスへの SSH 接続に必要な EC2 インスタンスの IP アドレス、ユーザー名、パスワードが手元にあることを確認してください。ローカルマシンでターミナルを開き、以下を入力します。
+
+``` bash
+ssh -P 2222 [username]@http://[ec2-ip-address]
+```
+
+パスワードの入力を求められます。
+
+実行中の Apache Tomcat インスタンスを停止するには、以下のコマンドを使用します。
+
+```bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./shutdown.sh
+```
+
+以下のコマンドを使用して、まだ実行中のアプリケーション JVM が残っていないか確認します。
+
+```bash
+ps -ef | grep Supercar-Trader
+```
+
+実行中のアプリケーション JVM が残っている場合は、以下のコマンドを使用して残りの JVM を終了させます。
+
+```bash
+sudo pkill -f Supercar-Trader
+```
+
+アプリケーションの負荷生成を停止するには、以下のコマンドを使用します。
+
+```bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./stop_load.sh
+```
+
+以下の画像のような出力が表示されるはずです。
+
+
+
+次に、以下のコマンドを使用して Apache Tomcat を起動します。
+
+```bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./startup.sh
+```
+
+2 分間待ってから、以下のコマンドを使用して Apache Tomcat がポート 8080 で動作していることを確認します。
+
+```bash
+sudo netstat -tulpn | grep LISTEN
+```
+
+以下の画像のような出力が表示され、ポート 8080 が Apache Tomcat によって使用されていることが示されるはずです。
+
+
+
+アプリケーションの負荷生成を開始するには、以下のコマンドを使用します。
+
+```bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./start_load.sh
+```
+
+以下の画像のような出力が表示されるはずです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md
new file mode 100644
index 0000000000..2ec5764a8b
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md
@@ -0,0 +1,82 @@
+---
+title: Server Agent のデプロイ - Option 1
+time: 2 minutes
+weight: 2
+description: ご利用の AppDynamics Controller のバージョンによっては、Option 1 で示すように Controller から Server Visibility エージェントをダウンロードできる場合とできない場合があります。
+draft: true
+---
+
+{{% notice title="前提条件" style="primary" icon="lightbulb" %}}
+これは Application Performance Monitoring ラボの続きです。アプリケーションが起動しており、過去 1 時間にわたって負荷がかかっていることを確認してください。必要に応じて generate-application-load セクションに戻り、ロードジェネレーターを再起動してください。
+{{% /notice %}}
+
+以下の手順を Select the agent type for download セクションまで進めてください。Servers タイルが表示されない場合は、Deploy Server Agent - Option 2 のアプローチを使用する必要があります。
+
+Option 1 を使用する利点は、エージェントが Controller に接続するように事前構成されている点です。一方 Option 2 を使用する場合は、Controller に接続するためにエージェントの構成を編集する必要があります。
+
+## Controller へのログイン
+
+[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の資格情報でログインします。
+
+## Getting Started Wizard への移動
+
+1. 画面左上の Home タブを選択します。
+2. Getting Started タブを選択します。
+3. Getting Started Wizard をクリックします。
+
+
+
+## ダウンロードするエージェントタイプの選択
+
+1. Servers ボタンをクリックします。
+
+
+
+## Server Agent のダウンロード
+
+1. Platform Bundle は Linux と 64-bit のままにしておきます。
+2. Controller connection はデフォルトのままにしておきます。
+3. Click Here to Download をクリックします。
+
+
+
+Server Visibility Agent ファイルをローカルのワークステーションに保存します。
+
+ブラウザは、以下の画像のように（OS によって異なります）、エージェントファイルをローカルファイルシステムに保存するよう促します。
+
+
+
+## Server Agent をアプリケーション VM にアップロード
+
+Server エージェントファイルをアップロードするプロセスは、ワークステーションのオペレーティングシステムによって異なります。OS が MAC/Linux の場合は SCP を、Windows の場合は WinSCP を使用して Server エージェントの ZIP ファイルをコピーしてください。
+
+## Server Agent のインストール
+
+Server エージェントの zip ファイルを解凍するディレクトリ構造を作成します。
+
+```bash
+cd /opt/appdynamics
+mkdir machineagent
+```
+
+以下のコマンドを使用して、Server Visibility エージェントの zip ファイルをディレクトリにコピーし、ファイルを解凍します。Server Visibility エージェントファイルの名前は、以下の例と若干異なる場合があります。（zip ファイルを /tmp ディレクトリにアップロードしたことを前提としています）
+
+```bash
+cp /tmp/machineagent-bundle-64bit-linux-20.4.0.2571.zip /opt/appdynamics/machineagent/
+cd /opt/appdynamics/machineagent
+unzip machineagent-bundle-64bit-linux-20.4.0.2571.zip
+```
+
+## Server Visibility エージェントの起動
+
+以下のコマンドを使用して Server Visibility エージェントを起動し、起動したことを確認します。
+
+```bash
+cd /opt/appdynamics/machineagent/bin
+nohup ./machine-agent &
+ps -ef | grep machine
+```
+
+以下の画像のような出力が表示されるはずです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md
new file mode 100644
index 0000000000..86d696b08c
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md
@@ -0,0 +1,88 @@
+---
+title: Machine Agent のデプロイ
+time: 5 minutes
+weight: 3
+description: サーバーエージェントを手動でインストールします。
+---
+
+この演習では、以下の作業を行います。
+
+1. Machine Agent をインストールするスクリプトを実行する
+2. Machine Agent を構成する
+3. Machine Agent を起動する
+
+{{% notice title="Note" style="orange" %}}
+スクリプトを使用して、EC2 インスタンスに Machine Agent をダウンロードします。通常は [https://accounts.appdynamics.com/](https://accounts.appdynamics.com/) にログインして Machine Agent をダウンロードする必要がありますが、アクセス制限の可能性があるため、ポータルから直接ダウンロードするスクリプトを使用します。AppDynamics ポータルへのアクセス権があり、Machine Agent をダウンロードしたい場合は、以下の手順でダウンロードし、APM ラボの Install Agent セクションで使用した手順を参照して VM に SCP で転送できます。
+
+1. [AppDynamics Portal](https://accounts.appdynamics.com/) にログインします
+2. 左側のメニューで **Downloads** をクリックします
+3. **Type** で **Machine Agent** を選択します
+4. **Operating System** で **Linux** を選択します
+5. **Machine Agent Bundle - 64-bit linux (zip)** を見つけて **Download** ボタンをクリックします
+6. Install Agent セクションの手順に従って、ダウンロードしたファイルを EC2 インスタンスに SCP で転送します
+7. zip ファイルを /opt/appdynamics/machineagent ディレクトリに展開し、このラボの構成セクションに進みます
+{{% /notice %}}
+
+## インストールスクリプトの実行
+
+以下のコマンドを使用して、スクリプトが配置されているディレクトリに移動します。スクリプトは Machine Agent をダウンロードして展開します。
+
+```bash
+cd /opt/appdynamics/lab-artifacts/machineagent/
+```
+
+以下のコマンドを使用して、インストールスクリプトを実行します。
+
+```bash
+chmod +x install_machineagent.sh
+./install_machineagent.sh
+```
+
+以下の画像のような出力が表示されるはずです。
+
+
+
+## サーバーエージェントの構成
+
+以下に記載されている構成プロパティの値を Java Agent の "controller-info.xml" から取得し、次の手順で使用できるように準備しておきます。
+
+```bash
+cat /opt/appdynamics/javaagent/conf/controller-info.xml
+```
+
+- controller-host
+- controller-port
+- controller-ssl-enabled
+- account-name
+- account-access-key
+
+Machine Agent の "controller-info.xml" ファイルを編集し、Java Agent の構成ファイルから取得した以下のプロパティの値を入力します。
+
+- controller-host
+- controller-port
+- controller-ssl-enabled
+- account-name
+- account-access-key
+
+"sim-enabled" プロパティを true に設定してからファイルを保存する必要があります。以下の画像のようになるはずです。
+
+```bash
+cd /opt/appdynamics/machineagent/conf
+nano controller-info.xml
+```
+
+
+
+## Server Visibility エージェントの起動
+
+以下のコマンドを使用して、Server Visibility エージェントを起動し、起動したことを確認します。
+
+```bash
+cd /opt/appdynamics/machineagent/bin
+nohup ./machine-agent &
+ps -ef | grep machine
+```
+
+以下の画像のような出力が表示されるはずです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md
new file mode 100644
index 0000000000..47142fb4e1
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md
@@ -0,0 +1,111 @@
+---
+title: サーバーヘルスの監視
+time: 2 minutes
+weight: 4
+description: この演習では、サーバーのヘルスを監視するためのいくつかのダッシュボードを確認し、サーバーとアプリケーションのコンテキスト間を移動します。
+---
+
+この演習では、以下のタスクを完了します。
+
+- Server Main ダッシュボードの確認
+- Server Processes ダッシュボードの確認
+- Server Volumes ダッシュボードの確認
+- Server Network ダッシュボードの確認
+- サーバーとアプリケーションのコンテキスト間の移動
+
+## Server Main ダッシュボードの確認
+
+Machine agent をインストールしたので、Server Visibility モジュールで利用可能ないくつかの機能を見ていきましょう。**Application Dashboard** から **Servers** タブをクリックし、以下の手順でサーバーのメインダッシュボードへドリルダウンします。
+
+1. 左メニューの **Servers** タブをクリックします。
+2. サーバーの左側の **checkbox** をオンにします。
+3. **View Details** をクリックします。
+
+
+
+これでサーバーダッシュボードを確認できます。このダッシュボードでは、以下のタスクを実行できます。
+
+選択した監視対象サーバーの主要なパフォーマンスメトリクスのチャートを確認できます。含まれる項目は以下のとおりです。
+
+- サーバーの可用性
+- CPU、メモリ、ネットワーク使用率
+- サーバーのプロパティ
+- ディスク、パーティション、ボリュームのメトリクス
+- CPU リソースとメモリを最も消費している上位 10 のプロセス
+
+Server Main ダッシュボードの詳細については[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/server-dashboard)を参照してください。
+
+ダッシュボードの **Top Pane** を確認すると、以下の情報が表示されます。
+
+- Host Id: Splunk AppDynamics Controller 内でサーバーを一意に識別する ID です
+- Health: サーバーの全体的なヘルス状態を表示します。
+- Hierachy: サーバーをグループ化するための任意の階層構造です。詳細についてはドキュメント[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/machine-agent/configure-the-machine-agent/machine-agent-configuration-properties)を参照してください
+
+1. ヘルスサーバーアイコンをクリックすると、**Violations * Anomalies** パネルが表示されます。パネルを確認して潜在的な問題を特定します
+2. **Current Health Rule Evaluation Status** をクリックして、このサーバーで現在アラートが発生している問題があるかどうかを確認します
+
+
+
+
+1. **CPU Usage too high** ルールをクリックします
+2. **Edit Health Rule** をクリックします。**Edit Health Rule** パネルが開きます
+
+
+
+このパネルでは Health Rule を設定できます。Health Rule の作成とカスタマイズの詳細については別のラボで扱います。ここでは既存のルールを確認するだけです
+
+1. **Warning Criteria** をクリックします
+
+
+
+この例では、CPU が 5% を超えると警告基準が設定されていることがわかります。これが Health Rule が healthy 状態ではなく warning を表示している理由です。**Edit Health Rule** パネルをキャンセルして **Server Dashboard** に戻ります
+
+## Server Processes ダッシュボードの確認
+
+1. **Processes** タブをクリックします。
+2. **View Options** をクリックして、異なるデータ列を選択します。表示可能な KPI を確認します
+
+これで Server Processes ダッシュボードを確認できます。このダッシュボードでは、以下のタスクを実行できます。
+
+- 選択した期間中にアクティブだったすべてのプロセスを表示します。プロセスは ServerMonitoring.yml ファイルで指定されたクラスごとにグループ化されます。
+- Command Line 列のプロセスエントリにマウスオーバーすることで、このプロセスを開始した完全なコマンドラインを表示します。
+- プロセスクラスを展開して、そのクラスに関連付けられたプロセスを表示します。
+- View Options を使用して、チャートに表示する列を構成します。
+- 表示されるメトリクスの期間を変更します。
+- 列をソートキーとしてチャートをソートします。スパークラインチャート（CPU Trend と Memory Trend）はソートできません。
+- CPU とメモリの使用傾向を一目で確認します。
+
+Server Processes ダッシュボードの詳細については[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/server-process-metrics)を参照してください。
+
+
+
+## Server Volumes ダッシュボードの確認
+
+1. **Volumes** タブをクリックします。
+
+これで Server Volumes ダッシュボードを確認できます。このダッシュボードでは、以下のタスクを実行できます。
+
+- ボリュームのリスト、使用率、ディスク・パーティション・ボリュームで利用可能な合計ストレージスペースを確認します。
+- ディスク使用量と I/O 使用率、レート、1 秒あたりの操作数、待機時間を確認します。
+- 収集および表示されるメトリクスの期間を変更します。
+- チャート上の任意のポイントをクリックして、その時点のメトリクス値を確認します。
+
+Server Volumes ダッシュボードの詳細については[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/server-volumes-metrics)を参照してください。
+
+
+
+## Server Network ダッシュボードの確認
+
+1. Network タブをクリックします。
+
+これで **Server Network** ダッシュボードを確認できます。このダッシュボードでは、以下のタスクを実行できます。
+
+- 各ネットワークインターフェイスの MAC、IPv4、IPv6 アドレスを確認します。
+- ネットワークインターフェイスが有効かつ機能しているか、その動作状態（イーサネットケーブルが接続されているか、全二重または半二重モードで動作しているか）、最大転送単位（MTU）またはネットワークインターフェイスが転送できる最大プロトコルデータユニットのサイズ（バイト単位）、イーサネット接続の速度（Mbit/sec）を確認します。
+- ネットワークスループット（kilobytes/sec）とパケットトラフィックを表示します。
+- 表示されるメトリクスの期間を変更します。
+- チャート上の任意のポイントにマウスオーバーして、その時点のメトリクス値を確認します。
+
+Server Network ダッシュボードの詳細については[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/server-network-metrics)を参照してください。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md
new file mode 100644
index 0000000000..d7e03b8f02
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md
@@ -0,0 +1,32 @@
+---
+title: サーバーと APM の相関分析
+time: 3 minutes
+weight: 5
+description: サーバーメトリクスとサーバー上で稼働するアプリケーションの相関分析方法を確認します
+---
+
+## サーバーとアプリケーションのコンテキスト間を移動する
+
+Server Visibility Monitoring エージェントは、同一ホスト上で実行されている Splunk AppDynamics APM エージェントと自動的に関連付けられます。
+
+Server Visibility を有効化すると、アプリケーションのコンテキストでサーバーのパフォーマンスメトリクスにアクセスできます。サーバーとアプリケーションのコンテキスト間は、さまざまな方法で切り替えられます。以下の手順に従って、サーバーのメインダッシュボードから、そのサーバー上で稼働している Node へと移動します。
+
+1. **Dashboard** タブをクリックし、メインの Server Dashboard に戻ります。
+2. **APM Correlation** リンクをクリックします。
+
+
+
+1. 表示されている Tier のいずれかの下矢印をクリックします。
+2. Tier の Node リンクをクリックします。
+
+
+
+これで **Node Dashboard** に遷移します。
+
+1. **Server** タブをクリックすると、関連するホストメトリクスが表示されます。
+
+
+
+Server Visibility Monitoring エージェントをインストールしている場合、ホストメトリクスは関連する Node のコンテキストで常に参照できます。
+
+サーバーとアプリケーションのコンテキスト間の移動については、[こちら](https://help.splunk.com/en/appdynamics-saas/infrastructure-visibility/25.7.0/server-visibility/monitor-your-servers-using-server-visibility/navigating-between-server-and-application-contexts)で詳しく確認できます。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/_index.md
new file mode 100644
index 0000000000..6eb31e94f0
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/2-server-visibility-monitoring/_index.md
@@ -0,0 +1,43 @@
+---
+title: Server Visibility Monitoring
+time: 2 minutes
+weight: 2
+description: このラボでは、AppDynamics Server Visibility Monitoring と Service Availability Monitoring について学びます。
+---
+
+{{% notice title="前提条件" style="primary" icon="lightbulb" %}}
+これは Application Performance Monitoring ラボの続きです。アプリケーションが稼働しており、過去 1 時間分の負荷がかかっていることを確認してください。必要に応じて Generate Application Load セクションに戻り、負荷生成ツールを再起動してください。
+{{% /notice %}}
+
+## Objectives
+
+このラボでは、AppDynamics Server Visibility Monitoring と Service Availability Monitoring について学びます。
+
+このラボを完了すると、次のことができるようになります。
+
+- AppDynamics Server Visibility Agent をダウンロードする。
+- AppDynamics Server Visibility Agent をインストールする。
+- サーバーのヘルス状態を監視する。
+- エージェントが提供する拡張ハードウェアメトリクスを理解する。
+- アプリケーションのパフォーマンスに影響を及ぼす基盤インフラストラクチャの問題を素早く把握する。
+
+## Workshop Environment
+
+ラボ環境には 2 台のホストがあります。
+
+- 1 台目のホストでは AppDynamics Controller が稼働しており、以降は Controller と呼びます。
+- 2 台目のホストでは、ラボで使用する Supercar Trader アプリケーションが稼働しています。このホストには AppDynamics エージェントをインストールするため、以降は Application VM と呼びます。
+
+## Controller
+
+このワークショップでは [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を使用します。
+
+
+
+## Application VM
+
+Supercar Trader は Java ベースの Web アプリケーションです。
+
+Supercar-Trader コレクションの目的は、AppDynamics Controller 向けに動的なトラフィック (ビジネストランザクション) を生成することです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md
new file mode 100644
index 0000000000..66e5e14eb1
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md
@@ -0,0 +1,139 @@
+---
+title: ラボの前提条件
+time: 3 minutes
+weight: 1
+description: この演習では、Controllerにアクセスしてアプリケーションの負荷を確認します。
+---
+
+この演習では、次のタスクを実施します。
+
+* Webブラウザから AppDynamics Controller にアクセスします。
+* アプリケーションへのトランザクション負荷を確認します。
+* 必要に応じてアプリケーションとトランザクション負荷を再起動します。
+
+## Controllerへのログイン
+
+[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の認証情報でログインします。
+
+## アプリケーションへのトランザクション負荷の確認
+
+アプリケーションのフローマップを確認します。
+
+1. **last 1 hour** の時間枠を選択します。
+2. フローマップ上に 5 つの異なる Tier が表示されていることを確認します。
+3. 過去 1 時間にわたって一貫した負荷が発生していることを確認します。
+
+
+
+ビジネストランザクションの一覧を確認します。
+
+1. 左側のメニューから **Business Transactions** オプションをクリックします。
+2. 以下に示す 11 個のビジネストランザクションが表示されていることを確認します。
+3. 過去 1 時間に何らかのコール数が記録されていることを確認します。
+
+**Note:** **Calls** 列が表示されていない場合は、**View Options** ツールバーボタンをクリックすると列を表示できます。
+
+
+
+Node のエージェントステータスを確認します。
+
+1. 左側のメニューから **Tiers & Nodes** オプションをクリックします。
+2. **Grid View** をクリックします。
+3. 過去 1 時間において、各 Node の **App Agent Status** が 90% を超えていることを確認します。
+
+
+
+## 必要に応じたアプリケーションと負荷生成の再起動
+
+前のステップでいずれかの確認項目が満たせなかった場合は、**Application VM** に SSH 接続し、次の手順に従ってアプリケーションとトランザクション負荷を再起動します。
+
+実行中の Apache Tomcat インスタンスを停止するには、次のコマンドを使用します。
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./shutdown.sh
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+実行中のアプリケーション JVM が残っているかを確認するには、以下のコマンドを使用します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+ps -ef | grep Supercar-Trader
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+実行中のアプリケーション JVM が残っていた場合は、以下のコマンドで残っている JVM を強制終了します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+sudo pkill -f Supercar-Trader
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+アプリケーションの負荷生成を停止するには、以下のコマンドを使用します。すべてのプロセスが停止するまで待機してください。
+
+``` bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./stop_load.sh
+```
+
+Tomcat サーバーを再起動します。
+
+``` bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./startup.sh
+```
+
+2 分間待ってから、以下のコマンドで Apache Tomcat がポート 8080 で稼働していることを確認します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+curl localhost:8080
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+
+
+
+
+
Apache Tomcat/9.0.50
+
+
+
+
+
+
}}
+
+アプリケーションの負荷生成を開始するには、以下のコマンドを使用します。
+
+``` bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./start_load.sh
+```
+
+以下の画像のような出力が表示されるはずです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md
new file mode 100644
index 0000000000..b7a59ad3aa
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md
@@ -0,0 +1,35 @@
+---
+title: アプリケーションでの Analytics の有効化
+time: 2 minutes
+weight: 2
+description: この演習では、Web ブラウザから AppDynamics Controller にアクセスし、そこから Agentless Analytics を有効化します。
+
+---
+
+Analytics はかつて Machine Agent にバンドルされた別個のエージェントを必要としていました。しかし現在は agentless となり、Controller >= 4.5.16 上で .NET Agent >= 20.10 および Java Agent >= 4.5.15 の両方で APM Agent に組み込まれています。
+
+この演習では、Web ブラウザから AppDynamics Controller にアクセスし、そこから Agentless Analytics を有効化します。
+
+## Controller へのログイン
+
+Cisco の認証情報を使用して [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインします。
+
+## Analytics 設定への移動
+
+1. ** 画面左上の **Analytics** タブを選択します。
+2. ** 左側の **Configuration** タブを選択します。
+3. ** **Transaction Analytics - Configuration** タブを選択します。
+4. ** お使いのアプリケーション **Supercat-Trader-YOURINITIALS** の隣の **チェックボックスをマーク** します。
+5. ** **Save** ボタンをクリックします。
+
+
+
+## トランザクションサマリーの検証
+
+そのアプリケーションで Analytics が動作し、トランザクションが表示されていることを確認します。
+
+1. 左メニューの **Analytics tab** タブを選択します。
+2. **Home** タブを選択します。
+3. **Transactions from** で、お使いのアプリケーション **Supercar-Trader-YOURINITIALS** にフィルターします。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md
new file mode 100644
index 0000000000..c30fe786aa
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md
@@ -0,0 +1,104 @@
+---
+title: HTTP データコレクターの設定
+time: 2 minutes
+weight: 3
+description: この演習では、HTTP データコレクターを有効化して使用します。
+
+---
+データコレクターを使用すると、ビジネストランザクションおよびトランザクション分析データをアプリケーションデータで補強できます。アプリケーションデータは、ビジネストランザクションのパフォーマンス問題にコンテキストを追加できます。たとえば、パフォーマンス問題の影響を受けているビジネストランザクションについて、特定のユーザー、注文、製品といった特定のパラメータの値や戻り値を表示できます。
+
+HTTP データコレクターは、ビジネストランザクションでやり取りされる HTTP メッセージの URL、パラメータ値、ヘッダー、Cookie をキャプチャします。
+
+この演習では、以下のタスクを実行します。
+
+* すべての HTTP データコレクターを有効化します。
+* 関連する HTTP データコレクターを観察して選定します。
+* HTTP パラメータを使用して Analytics でビジネスデータをキャプチャします。
+* HTTP パラメータに対する Analytics を検証します。
+
+## すべての HTTP データコレクターを有効化する
+
+最初は、すべての HTTP データコレクターをキャプチャすることで、Analytics に取り込んでダッシュボードで活用できる有用なパラメータを把握できます。
+
+{{% notice title="ヒント" style="orange" icon="lightbulb" %}}
+この手順は本番環境ではなく、UAT 環境で実施することを強く推奨します。
+{{% /notice %}}
+
+1. 画面左上の **Applications** タブを選択します。
+2. **Supercar-Trader-YOURINITIALS** アプリケーションを選択します。
+3. 左側の **Configuration** タブを選択します。
+4. **Instrumentation** リンクをクリックします。
+5. **Data Collectors** タブを選択します。
+6. **HTTP Request Data Collectors** にある **Add** ボタンをクリックします。
+
+
+
+これから、すべての HTTP パラメータをキャプチャするように HTTP データコレクターを設定します。Transaction Analytics で必要となる正確なパラメータを特定するまでオーバーヘッドを避けるため、Transaction Snapshots でのみ有効化します。
+
+1. **Name** には **All HTTP Param** を指定します。
+2. **Enable Data Collector for** で **Transaction Snapshots** のチェックボックスをオンにします。
+3. Transaction Analytics は **有効化しないでください**。
+4. HTTP Parameters セクションの **\+ Add** をクリックします。
+5. 新しいパラメータの Display Name に **All** を指定します。
+6. 次に、HTTP Parameter name にアスタリスク **\*** を指定します。
+7. **Save** をクリックします。
+
+
+
+1. "Ok" をクリックしてデータコレクターを確定します。
+2. **/Supercar-Trader/sell.do** トランザクションを有効化します。
+3. **Save** をクリックします。
+
+
+
+## 関連する HTTP データコレクターの観察と選定
+
+1. アプリケーション、特に **SellCar** トランザクションに負荷をかけます。Full Call Graph 付きのスナップショットを開き、**Data Collectors Tab** を選択します。
+
+これですべての HTTP パラメータが表示されます。Car Price、Color、Year など、いくつかの重要なメトリクスが確認できます。
+
+1. **HTTP Parameters** リストに再度追加して Transaction Analytics で有効化するため、正確なパラメータ名を控えておきます。
+2. 追加が完了したら、**All HTTP Param** HTTP データコレクターを削除します。
+
+
+
+## HTTP パラメータを使用して Analytics でビジネスデータをキャプチャする
+
+これから HTTP データコレクターを再度設定しますが、今回は有用な HTTP パラメータのみをキャプチャし、Transaction Analytics で有効化します。新しい HTTP データコレクターを追加します。Application -> Configuration -> Instrumentation -> Data Collector タブ -> **HTTP Request Data Collectors** セクションの **Add** をクリックします。
+
+1. Name には **CarDetails** を指定します。
+2. **Transaction Snapshots** を有効化します。
+3. **Transaction Analytics** を有効化します。
+4. HTTP Parameters セクションの **\+ Add** をクリックします。
+5. 新しいパラメータの Display Name に **CarPrice\_http** を指定します。
+6. 次に、HTTP Parameter name に **carPrice** を指定します。
+7. 以下に示すように、残りの Car パラメータについても繰り返します。
+8. **Save** をクリックします。
+9. **Ok** をクリックしてデータコレクターの実装を確認します。
+
+
+
+
+1. **/Supercar-Trader/sell.do** トランザクションを有効化します。
+2. **Save** をクリックします。
+
+
+
+1. **All HTTP Param** コレクターをクリックし、**Delete** ボタンをクリックして削除します。
+
+## HTTP パラメータに対する Analytics の検証
+
+これから、HTTP データコレクターによってビジネスデータが AppDynamics Analytics でキャプチャされたかを検証します。
+
+1. 画面左上の **Analytics** タブを選択します。
+2. **Searches** タブを選択します。
+3. **+ Add** ボタンをクリックして、新しい **Drag and Drop Search** を作成します。
+
+
+
+1. **+ Add Criteria** をクリックします。
+2. **Application** を選択し、ご自身のアプリケーション名 **Supercar-Trader-YOURINITIALS** を検索します。
+3. **Fields** パネルで、**Business Parameters** が Custom HTTP Request Data のフィールドとして表示されることを確認します。
+4. **CarPrice_http** のチェックボックスをオンにし、フィールドにデータが入っていることを検証します。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md
new file mode 100644
index 0000000000..286a3bd43b
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md
@@ -0,0 +1,181 @@
+---
+title: メソッドデータコレクターの設定
+time: 2 minutes
+weight: 4
+description: この演習では、Web ブラウザから AppDynamics Controller にアクセスし、そこから Agentless Analytics を有効化します。
+---
+メソッド呼び出しデータコレクターは、メソッドの引数、変数、戻り値などのコードデータをキャプチャします。HTTP データコレクターで十分なビジネスデータが取得できない場合でも、コード実行からこれらの情報をキャプチャできます。
+
+この演習では、以下のタスクを実行します。
+
+* メソッドを検出する。
+* ディスカバリーセッションを開く。
+* メソッドのパラメーターを検出する。
+* コード内のオブジェクトをドリルダウンする。
+* メソッド呼び出しデータコレクターを作成する。
+* メソッド呼び出しデータコレクターのアナリティクスを検証する。
+
+## ディスカバリーセッションを開く
+
+ソースコードからメソッドやパラメーターを特定できるアプリケーション開発者がいない場合もあります。しかし、AppDynamics から直接アプリケーションのメソッドやオブジェクトを検出する方法があります。
+
+1. 画面左上の **Applications** タブを選択します。
+2. **Supercar-Trader-YOURINITIALS** アプリケーションを選択します。
+3. **Configuration** タブを選択します。
+4. **Instrumentation** リンクをクリックします。
+5. **Transaction Detection** タブを選択します。
+6. 右側の **Live Preview Button** をクリックします。
+
+
+
+1. **Start Discovery Session** ボタンをクリックします。
+2. ポップアップウィンドウで **Web-Portal Node** を選択します。これは、調査対象のメソッドが実行されているノードと同じである必要があります。
+3. **Ok** をクリックします。
+
+
+
+1. 右側のトグルで **Tools** を選択します。
+2. ドロップダウンリストで **Classes/Methods** を選択します。
+3. **Search** セクションで **Classes** with name を選択します。
+4. テキストボックスにクラス名 **supercars.dataloader.CarDataLoader** を入力します。クラス名を見つけるには、コールグラフを検索するか、できればソースコードから探します。
+5. **Apply** をクリックして、一致するクラスメソッドを検索します。
+6. 結果が表示されたら、検索に一致するクラスを展開します。
+7. **saveCar** メソッドを探します。
+
+
+
+**saveCar** メソッドは入力パラメーターとして **CarForm** オブジェクトを受け取ることに注意してください。
+
+## オブジェクトへのドリルダウン
+
+メソッドが見つかりましたので、そのパラメーターを調べて、車の詳細プロパティをどこから取得できるかを確認します。
+
+**saveCar** メソッドが入力パラメーターとして複合オブジェクト **CarForm** を受け取ることが分かりました。このオブジェクトには、アプリケーションの Web ページで入力されたフォームデータが格納されます。次に、そのオブジェクトを検査して、そこから車の詳細を取得する方法を確認する必要があります。
+
+1. テキストボックスに入力オブジェクトのクラス名 **supercars.form.CarForm** を入力します。
+2. **Apply** をクリックしてクラスメソッドを検索します。
+3. 結果が表示されたら、検索に一致する **supercars.form.CarForm** クラスを展開します。
+4. 必要な車の詳細を返すメソッドを探します。価格、モデル、色などの **get** メソッドが見つかります。
+
+
+
+## メソッド呼び出しデータコレクターの作成
+
+これまでの演習で得た情報をもとに、メソッド呼び出しデータコレクターを設定して、ランタイムで実行中のコードから直接車の詳細を取得できます。
+
+1. **Applications** タブを選択します。
+2. **Supercar-Trader-YOURINITIALS** アプリケーションを選択します。
+3. **Configuration** タブを選択します。
+4. **Instrumentation** リンクをクリックします。
+5. **Data Collectors** タブを選択します。
+6. **Method Invocation Data Collectors** で **Add** をクリックします。
+
+
+
+車の詳細をキャプチャするためのメソッド呼び出しデータコレクターを作成します。
+
+1. **Name** には **SellCarMI-YOURINITIALS** を指定します。
+2. **Transaction Snapshots** を有効化します。
+3. **Transaction Analytics** を有効化します。
+4. **with a Class Name that** を選択します。
+5. **Class Name** として **supercars.dataloader.CarDataLoader** を追加します。
+6. **Method Name** として **saveCar** を追加します。
+
+
+
+確認したように、SaveCar メソッドのインデックス 0 の入力パラメーターは **CarForm** クラスのオブジェクトであり、そのオブジェクト内に **getPrice()** などの車の詳細プロパティを返す Getter メソッドがあります。
+
+そのため、MIDC でその値を取得する方法を説明するために、以下の手順を実行します。
+
+1. MIDC パネルの下部にある **Add** をクリックして、収集したい新しいデータを指定します。
+2. Display Name には **CarPrice_MIDC** を指定します。
+3. Collect Data From では、**Method Parameter of Index 0** を選択します。これは **CarForm Object** です。
+4. **Operation on Method Parameter** には、**Use Getter Chain** を選択します。CarForm 内のメソッドを呼び出して車の詳細を取得します。
+5. 次に、**CarForm** クラス内で価格を返す Getter メソッドである **getPrice()** を指定します。
+6. **Save** をクリックします。
+
+
+
+1. 上記の手順を、色、モデル、その他データを収集したいすべてのプロパティに対して繰り返します。
+
+
+
+1. **Save MIDC** をクリックして、**”/Supercar-Trader/sell.do”** ビジネストランザクションに適用します。
+
+MIDC を反映させるには、JVM を再起動する必要があります。
+
+1. EC2 インスタンスに SSH 接続します。
+2. Tomcat サーバーをシャットダウンします。
+
+``` bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./shutdown.sh
+```
+
+アプリケーションの JVM がまだ実行中の場合は、以下のコマンドで残りの JVM を強制終了します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+sudo pkill -f Supercar-Trader
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+1. Tomcat サーバーを再起動します。
+
+``` bash
+./startup.sh
+```
+
+1. Tomcat サーバーが起動していることを確認します。これには数分かかる場合があります。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+curl localhost:8080
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+
+
+
+
+
Apache Tomcat/9.0.50
+
+
+
+
+
+
}}
+
+## MD パラメーターのアナリティクスを検証する
+
+Web サイトにアクセスし、Sell Car ページでフォームを数回送信して、手動で負荷をかけます。
+
+次に、AppDynamics Analytics で HTTP データコレクターによってビジネスデータがキャプチャされたかどうかを確認します。
+
+1. **Analytics** タブを選択します。
+2. **Searches** タブを選択し、新しい **Drag and Drop Search** を追加します。
+3. **+ Add** ボタンをクリックして、新しい **Drag and Drop Search** を作成します。
+4. **+ Add Criteria** をクリックします。
+5. **Application** を選択し、アプリケーション名 **Supercar-Trader-YOURINITIALS** を検索します。
+6. **Custom Method Data** に **Business Parameters** がフィールドとして表示されることを確認します。
+7. **CarPrice Field** にデータが入っていることを確認します。
+
+
+
+## まとめ
+
+これで、ランタイム中のノードから Sell Car トランザクションのビジネスデータをキャプチャできました。このデータは、AppDynamics 内のアナリティクスやダッシュボード機能で利用でき、ビジネスへのコンテキスト提供や、IT がビジネスに与える影響の測定に役立ちます。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md
new file mode 100644
index 0000000000..881b8b7d6f
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md
@@ -0,0 +1,135 @@
+---
+title: ダッシュボードコンポーネント
+time: 2 minutes
+weight: 5
+description: この演習では、魅力的なダッシュボードを構築するために使用できるダッシュボードコンポーネントのいくつかを扱います。
+---
+ダッシュボードを構築する機能は、AppDynamicsの機能と価値を支える重要なコンポーネントです。この演習では、魅力的なダッシュボードを構築するために使用できるダッシュボードコンポーネントのいくつかを扱います。
+
+## 新しいダッシュボードを作成する
+
+1. **Dashboard & Reports** タブを選択します。
+2. **Create Dashboard** をクリックします。
+3. **SuperCar-Dashboard-YOURINITIALS** のようなダッシュボード名を入力します。
+4. **Canvas Type** として **Absolute Layout** を選択します。
+5. **OK** をクリックします。
+
+
+
+新しく作成された空のダッシュボードを開きます。これからさまざまなウィジェットタイプを追加していきます。
+
+## ダッシュボードコンポーネントのカスタムウィジェットビルダー
+
+カスタムウィジェットビルダーは、数値ビュー、時系列、円グラフなど、データのさまざまな表現を生成できる柔軟性の高いツールです。AppDynamics AD Query Languageに基づいています。
+
+ウィジェットを作成するには、以下の手順に従います。
+
+1. ダッシュボード左上の **Edit Mode** を切り替えます。
+2. **Add Widget** をクリックします。
+3. 左側の **Analytics** タブを選択します。
+4. **Custom Widget Builder** をクリックします。
+
+
+
+Custom Widget Builderでは多数のチャートタイプを作成できます。情報を単純にドラッグ＆ドロップすることも、Advancedペインで AD Query を作成することもできます。
+
+
+
+ここでは、Numeric、Bar、Pie Chartsを取り上げます。
+
+### Numeric charts
+
+**演習:** エラーによる影響を金額で定量化することで、ITパフォーマンスがビジネス収益に与える影響を示すことができます。
+
+1. **Numeric** チャートタイプを選択します。
+2. Application フィールドにフィルターを追加し、アプリケーション名 **Supercar-Trader-YOURINITIALS** を選択します。
+3. **/Supercar-Trader/sell.do** ビジネストランザクションにフィルターを追加します。
+4. User Experience フィールドにフィルターを追加し、エラーの影響を表示するために **Error** のみを選択します。
+5. 左パネルで **CarPrice_MIDC** フィールドを見つけ、Y軸にドラッグ＆ドロップします。SUMがモデルごとの合計価格を取得するための集計として使用されていることに注目してください。
+6. 視認性を高めるため、フォントの色を赤に変更します。
+7. **Save** をクリックします。
+
+
+
+User Experience フィルターをNORMAL、SLOW、VERY SLOWのみを含むように変更すれば、**$ Amount Transacted Successfully** 基準に対しても同じことができることに注意してください。
+
+また、Analyticsモジュールでカスタムメトリクスを作成し、**$ Amount Impacted** がベースライン以上であるかを示すヘルスルールを定義することで、このメトリクスをベースライン化することもできます。通貨のラベルを追加することもできます。
+
+
+
+### Bar charts
+
+**演習:** ここからは、影響を受けた上位の車種モデル(Top Impacted Car Models)を可視化する棒グラフを作成します。このチャートでは、すべての **SellCar** トランザクションの車種モデルを、User Experienceで分類して表示します。
+
+1. **+ Add Widget**、**Analytics**、**Custom Widger Builder** をクリックして新しいウィジェットを作成します。
+2. **Column** チャートタイプを選択します。
+3. 以下のフィルターを追加します: Application = **Supercar-Trader-YOURINITIALS** および Business Transaction = **/Supercar-Trader/sell.do**。
+4. **CarModel\_MIDC** と **User Experience** をX軸に追加します。
+5. **Save** をクリックします。
+
+
+
+このチャートタイプはニーズに応じて調整できます。たとえば、X軸を Customer Type、Company、Organizationなどでグループ化できます。次の例を参照してください。
+
+
+
+### Pie charts
+
+ここからは、`sellCar` トランザクションで報告されたすべての車種モデルとモデルごとの価格合計を表示する円グラフを作成します。これにより、アプリケーション内で最も需要の高いモデルが表示されます。
+
+1. 新しいウィジェットを作成します。
+2. **Pie** チャートタイプを選択します。
+3. 以下のフィルターを追加します: Application = **Supercar-Trader-YOURINITIALS** および Business Transaction = **/Supercar-Trader/sell.do**。
+4. **CarModel\_MIDC** をX軸に追加します。
+5. **CarPrice\_MIDC** をY軸に追加します。**SUM** がモデルごとの合計価格を取得するための集計として使用されていることに注目してください。
+6. タイトル **Sold by Car Model** を追加します。
+7. **Save** をクリックします。
+
+
+
+円グラフウィジェットの追加の使用例については、次の例を参照してください。
+
+
+
+## ダッシュボードコンポーネント: コンバージョンファネル
+
+コンバージョンファネルは、複数のステップからなるプロセスを通過するユーザーやイベントの流れを可視化するのに役立ちます。これにより、より高いコンバージョンを実現するためにどのステップを最適化できるかをよりよく理解できます。また、コンバージョンファネルを使用して各ステップのITパフォーマンスを調査し、ユーザーエクスペリエンスにどのような影響を与えるかを理解し、ユーザーの離脱原因を特定することもできます。
+
+ファネルは、各ステップへの総訪問数ではなく、特定の順序でこのパスを実行したユーザーに従ってフィルタリングされる点に注意してください。
+
+ファネル作成の最初のステップは、ファネルを通過する各ユーザーのナビゲーションを表すことができるトランザクションの一意の識別子を選択することです。通常、Session ID はファネルの各ステップを通じて持続するため、最適な選択肢となります。
+
+Session ID はトランザクションから取得できます。ファネルトランザクションのカウンタとして使用するために、**SessionId** データコレクターが必要です。
+
+JavaアプリケーションでAppDynamicsは、デフォルトのHTTPデータコレクターでSession IDを扱う機能を備えています。これが有効になっていることを確認し、すべてのビジネストランザクションに適用して、すべてのトランザクションのSession IDを取得します。
+
+1. **Applications** タブを選択します。
+2. **Supercar-Trader-YOURINITIALS** アプリケーションを選択します。
+3. 左側の **Configuration** タブを選択します。
+4. **Instrumentation** をクリックします。
+5. **Data Collectors** タブを選択します。
+6. **Default HTTP Request Request Data Collectors** を編集します。
+7. **Transaction Analytics** を選択します。
+8. **SessionID** が選択されていることを確認します。
+9. **Save** をクリックします。
+
+
+
+次に、**/Supercar-Trader/home.do** ページから複数回ナビゲートして負荷をかけます。その後、アプリケーションの **/Supercar-Trader/sell.do** ページに直接ナビゲートします。
+
+ダッシュボードに戻ってファネルウィジェットを作成します。
+
+1. **Edit** スライダーを切り替えます。
+2. **Add Widget** をクリックします。
+3. **Analytics** タブを選択します。
+4. **Funnel Analysis** をクリックします。
+5. ドロップダウンリストから **Transactions** を選択します。
+6. **Count Distinct of** で、ドロップダウンリストから **uniqueSessionId** を選択します。
+7. **Add Step** をクリックします。**Home Page** という名前を付けます。
+8. **Add Criteria** をクリックします。次の条件を追加します: **Application**: Supercar-Trader-YOURINITIALS および **Business Transactions**: **/Supercar-Trader/home.do**。
+9. **Add Step** をクリックします。**SellCar Page** という名前を付けます。
+10. **Add Criteria** をクリックします。次の条件を追加します: **Application:** Supercar-Trader-YOURINITIALS および **Business Transactions:** /Supercar-Trader/sell.do。
+11. 右パネルの **Show Health** チェックボックスを選択して、フローマップでトランザクションの健全性を可視化します。
+12. **Save** をクリックします。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md
new file mode 100644
index 0000000000..26d9d44543
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md
@@ -0,0 +1,15 @@
+---
+title: ダッシュボードの構築
+time: 20 minutes
+weight: 6
+description: この演習では、先の演習でメソッド呼び出しデータコレクターを使用して取得したビジネスデータと、ダッシュボードコンポーネントに関する理解を活用して、IT ビジネスインパクトダッシュボードを構築します。
+---
+## 演習 - 自分のダッシュボードを構築する
+
+この Learning Lab の締めくくりとして、先の演習でメソッド呼び出しデータコレクターを使用して取得したビジネスデータと、ダッシュボードコンポーネントに関する理解を活用して、IT ビジネスインパクトダッシュボードを構築してください。
+
+以下の例を参考にして、同じデータとウィジェットを使用して自分のダッシュボードを構築してください。
+
+
+
+**おめでとうございます！BusinessIQ Fundamentals Learning Lab を完了しました！**
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/_index.md
new file mode 100644
index 0000000000..aa0bccfb99
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/3-business-iq/_index.md
@@ -0,0 +1,33 @@
+---
+title: Business iQ
+time: 2 minutes
+weight: 3
+description: この Learning Lab では、AppDynamics Business iQ について学びます。
+---
+
+## 目的
+
+この Learning Lab では、AppDynamics Business iQ について学びます。
+
+このラボを完了すると、次のことができるようになります。
+
+* 新しい Agentless Analytics Java Agent (v 4.5.15 +) で分析を有効化する。
+* HTTP データコレクターを構成する。
+* メソッド呼び出しデータコレクターを構成する。
+* ダッシュボードのコンポーネントを理解する。
+* ビジネスダッシュボードを構築する。
+
+## ワークショップ環境
+
+ラボ環境には、2 つのホストがあります。
+
+* 1 つ目のホストは AppDynamics Controller を実行しており、ここからは Controller と呼びます。
+* 2 つ目のホストはラボで使用する Supercar Trader アプリケーションを実行しています。AppDynamics エージェントをインストールするホストであり、ここからは Application VM と呼びます。
+
+#### Controller VM
+
+
+
+#### Application VM
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md
new file mode 100644
index 0000000000..50f01125eb
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md
@@ -0,0 +1,119 @@
+---
+title: BRUM ラボ前提条件
+time: 2 minutes
+weight: 1
+description: この演習では、Controller にアクセスし、アプリケーションの負荷を確認します。
+---
+
+この演習では、以下のタスクを完了します。
+
+* Web ブラウザから AppDynamics Controller にアクセスします。
+* アプリケーションへのトランザクション負荷を確認します。
+* 必要に応じてアプリケーションとトランザクション負荷を再起動します。
+
+## Controller へのログイン
+
+Cisco の認証情報を使用して [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインします。
+
+## アプリケーションへのトランザクション負荷の確認
+
+アプリケーションのフローマップを確認します。
+
+1. **last 1 hour** の時間範囲を選択します。
+2. フローマップ上に 5 つの異なる Tier が表示されていることを確認します。
+3. 過去 1 時間にわたって安定した負荷があったことを確認します。
+
+
+
+ビジネストランザクションのリストを確認します。
+
+1. 左側のメニューから **Business Transactions** オプションをクリックします。
+2. 以下に示す 11 個のビジネストランザクションが表示されていることを確認します。
+3. 過去 1 時間にいくつかの呼び出しが行われていることを確認します。
+
+**Note:** **Calls** カラムが表示されていない場合は、**View Options** ツールバーボタンをクリックしてそのカラムを表示できます。
+
+
+
+Node のエージェントステータスを確認します。
+
+1. 左側のメニューから **Tiers & Nodes** オプションをクリックします。
+2. **Grid View** をクリックします。
+3. 各 Node の **App Agent Status** が過去 1 時間において 90% 以上であることを確認します。
+
+
+
+## 必要に応じてアプリケーションと負荷生成を再起動する
+
+前のステップで実行した確認のいずれかが検証できなかった場合は、**Application VM** に SSH 接続し、以下の手順に従ってアプリケーションとトランザクション負荷を再起動します。
+
+実行中の Apache Tomcat インスタンスを停止するには、以下のコマンドを使用します。
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./shutdown.sh
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+以下のコマンドを使用して、まだ実行中のアプリケーション JVM が残っていないか確認します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+ps -ef | grep Supercar-Trader
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+まだ実行中のアプリケーション JVM が残っている場合は、以下のコマンドを使用して残りの JVM を強制終了します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+sudo pkill -f Supercar-Trader
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+以下のコマンドを使用して、アプリケーションの負荷生成を停止します。すべてのプロセスが停止するまで待ちます。
+
+``` bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./stop_load.sh
+```
+
+Tomcat サーバーを再起動します。
+
+``` bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./startup.sh
+```
+
+2 分間待ってから、以下のコマンドを使用して Apache Tomcat がポート 8080 で実行されていることを確認します。
+
+``` bash
+sudo netstat -tulpn | grep LISTEN
+```
+
+以下の画像のような出力が表示され、ポート 8080 が Apache Tomcat によって使用されていることが確認できます。
+
+
+
+以下のコマンドを使用して、アプリケーションの負荷生成を開始します。
+
+``` bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./start_load.sh
+```
+
+以下の画像のような出力が表示されます。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md
new file mode 100644
index 0000000000..6684d300a1
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md
@@ -0,0 +1,53 @@
+---
+title: ブラウザアプリケーションの作成
+time: 2 minutes
+weight: 2
+description: この演習では、Controller でアプリケーションを作成および構成します。
+---
+
+この演習では、以下のタスクを完了します。
+
+* Web ブラウザから AppDynamics Controller にアクセスします。
+* Controller でブラウザアプリケーションを作成します。
+* ブラウザアプリケーションを構成します。
+
+## Controller へのログイン
+
+[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の認証情報を使用してログインします。
+
+## Controller でのブラウザアプリケーションの作成
+
+以下の手順で新しいブラウザアプリケーションを作成します。
+
+{{% notice title="Note" style="primary" %}}
+下記のステップ 5 でブラウザアプリケーションに一意の名前を付けることが**非常に重要**です。
+{{% /notice %}}
+
+1. トップメニューの **User Experience** タブをクリックします。
+2. **User Experience** の下にある **Browser Apps** オプションをクリックします。
+3. **Add App** をクリックします。
+4. **Create an Application manually** オプションを選択します。
+5. ブラウザアプリケーションの一意の名前を _Supercar-Trader-Web-
-_ の形式で入力します。
+ * 例 1: Supercar-Trader-Web-JFK-3179
+ * 例 2: Supercar-Trader-Web-JohnSmith-0953
+6. **OK** をクリックします。
+
+
+
+これで **Supercar-Trader-Web-##-####** アプリケーションの **Browser App Dashboard** が表示されるはずです。
+
+1. 左メニューの **Configuration** タブをクリックします。
+2. **Instrumentation** オプションをクリックします。
+
+
+
+以下の手順に従って、ブラウザモニタリングエージェントが取得したデータと一緒に IP アドレスを保存するようにデフォルトの構成を変更します。
+
+1. **Settings** タブをクリックします。
+2. 右側のスクロールバーを使用して画面の一番下までスクロールします。
+3. **Store IP Address** チェックボックスをオンにします。
+4. **Save** をクリックします。
+
+Browser RUM 用の Controller UI の構成について詳しくは、[こちら](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/overview-of-the-controller-ui-for-browser-rum/configure-the-controller-ui-for-browser-rum) を参照してください。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md
new file mode 100644
index 0000000000..e3cfdee891
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md
@@ -0,0 +1,55 @@
+---
+title: エージェント挿入の設定
+time: 3 minutes
+weight: 3
+description: この演習では、JavaScript の挿入を有効化し、挿入対象の BT を選択します。
+---
+
+この演習では、以下のタスクを実行します。
+
+* JavaScript Agent の挿入を有効化する。
+* 挿入対象の Business Transaction を選択する。
+
+## JavaScript Agent の挿入を有効化する
+
+AppDynamics は JavaScript Agent を挿入するためのさまざまな方法をサポートしていますが、このラボでは Auto-Injection の方式を使用します。次の手順に従って、JavaScript Agent の Auto-Injection を有効化してください。
+
+1. 左メニューの **Applications** タブをクリックし、Supercar-Trader-## アプリケーションにドリルダウンします。
+2. 左メニューの一番下にある **Configuration** タブをクリックします。
+3. **User Experience App Integration** オプションをクリックします。
+
+
+
+1. **JavaScript Agent Injection** タブをクリックします。
+2. **Enable** をクリックして青色になるようにします。
+3. 選択されているブラウザーアプリが **Supercar-Trader-Web-##-####** であることを確認します。前のセクションで作成したアプリケーションを選択してください。
+4. **Enable JavaScript Injection** の下にある **Enable** チェックボックスをオンにします。
+5. **Save** をクリックします。
+
+
+
+Auto-Injection が候補となる Business Transaction を検出するまでに数分かかります。その間に、以下の手順で Business Transaction Correlation を有効化します。新しい APM エージェントでは、これは自動的に行われます。
+
+1. **Business Transaction Correlation** タブをクリックします。
+2. **Manually Enable Business Transactions** セクションの下にある **Enable** ボタンをクリックします。
+3. **Save** をクリックします。
+
+
+
+## 挿入対象の Business Transaction を選択する
+
+次の手順で、Auto-Injection の対象となる Business Transaction を選択します。
+
+1. **JavaScript Agent Injection** タブをクリックします。
+2. 検索ボックスに **.do** と入力します。
+3. 9 つの BT がすべて表示されるまで、Business Transaction の **Refresh List** リンクをクリックします。
+4. 右側のリストボックスからすべての Business Transaction を選択します。
+5. 矢印ボタンをクリックして、左側のリストボックスに移動します。
+6. すべての Business Transaction が左側のリストボックスに移動されたことを確認します。
+7. **Save** をクリックします。
+
+JavaScript Agent の Automatic Injection の設定について詳しくは、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/inject-the-javascript-agent/automatic-injection-of-the-javascript-agent)を参照してください。
+
+
+
+数分待つと、Browser Application に負荷が表示され始めます。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md
new file mode 100644
index 0000000000..af4a2b7cf7
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md
@@ -0,0 +1,152 @@
+---
+title: モニタリングとトラブルシューティング - パート 1
+time: 2 minutes
+weight: 4
+description: この演習では、ダッシュボードを確認し、デモアプリを操作します。
+---
+
+この演習では、以下のタスクを実行します。
+
+* Browser Application Overview ダッシュボードの確認
+* Browser Application Geo ダッシュボードの確認
+* Browser Application Usage Stats ダッシュボードの確認
+* Supercar-Trader アプリケーション Web ページの操作
+
+## Browser Application Overview ダッシュボードの確認
+
+User Experience ダッシュボードに移動し、以下の手順で Browser Application Overview ダッシュボードにドリルダウンします。
+
+1. 左メニューの **User Experience** タブをクリックします。
+2. ご自身の Web アプリケーション **Supercar-Trader-Web-##-###** を検索します。
+3. **Details** をクリックするか、アプリケーション名をダブルクリックします。
+
+
+
+Overview ダッシュボードには、設定可能なウィジェットのセットが表示されます。デフォルトのウィジェットには、アプリケーションパフォーマンスの一般的なハイレベル指標を示す複数のグラフとリストが含まれています。たとえば次のとおりです。
+
+* End User Response Time Distribution
+* End User Response Time Trend
+* Total Page Requests by Geo
+* End User Response Time by Geo
+* Top 10 Browsers
+* Top 10 Devices
+* Page Requests per Minute
+* Top 5 Pages by Total Requests
+* Top 5 Countries by Total Page Requests
+
+ダッシュボードの機能を試してみましょう。
+
+1. **+** をクリックして、ダッシュボードに追加するグラフやウィジェットを選択します。
+2. 任意のウィジェットの右下隅をクリックしてドラッグすると、サイズを変更できます。
+3. ウィジェット内の枠線で囲まれた領域を選択し、ダッシュボード上で移動・配置します。
+4. 任意のウィジェットのタイトルをクリックすると、詳細ダッシュボードにドリルダウンします。
+5. 任意のウィジェットの右上隅にある **X** をクリックすると、ダッシュボードからウィジェットを削除できます。
+
+ダッシュボードのウィジェットレイアウトに加えた変更は自動的に保存されます。
+
+Browser Application Overview ダッシュボードの詳細については、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/overview) を参照してください。
+
+
+
+## Browser Application Geo ダッシュボードの確認
+
+Geo Dashboard では、ページロードに基づいて地理的な位置ごとの主要パフォーマンス指標が表示されます。ダッシュボード全体に表示される指標は、マップまたはグリッドで現在選択されているリージョンのものです。マップビューには、右側のパネルに表示されるキータイミングメトリクスに該当する国のラベル付きロードサークルが表示されます。ただし、一部の国やリージョンはグリッドビューにのみ表示されます。
+
+Browser Application Geo ダッシュボードに移動し、以下に説明するダッシュボードの機能を試してみましょう。
+
+1. **Geo Dashboard** オプションをクリックします。
+2. ロードサークルの 1 つをクリックして、リージョンにドリルダウンします。
+3. リージョンの 1 つにマウスオーバーすると、リージョンの詳細が表示されます。
+4. ズームスライダーを使用してズームレベルを調整します。
+5. **Configuration** をクリックして、マップオプションを試してみましょう。
+6. グリッドビューとマップビューを切り替えます。
+
+Browser Application Geo ダッシュボードの詳細については、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/geo-tab) を参照してください。
+
+
+
+## Browser Application Usage Stats ダッシュボードの確認
+
+**Usage Stats** ダッシュボードでは、ユーザーのブラウザタイプとデバイス/プラットフォームに基づき、集計されたページロードの利用統計データが表示されます。
+
+Browser Application Usage Stats ダッシュボードでは、以下の点を把握できます。
+
+* エンドユーザー応答時間の合計が最も遅いブラウザ
+* 応答ページのレンダリングが最も遅いブラウザ
+* 多くのエンドユーザーが使用しているブラウザ
+* 特定の国または地域で多くのエンドユーザーが使用しているブラウザ
+
+Browser Application Usage Stats ダッシュボードに移動し、以下に説明するダッシュボードの機能を試してみましょう。
+
+1. **Usage Stats** オプションをクリックします。
+2. **Show Versions** オプションをクリックします。
+3. ロード別に、さまざまなブラウザとバージョンを確認します。
+4. 円グラフのセクションにマウスオーバーすると、詳細が表示されます。
+
+
+
+以下の手順で、ブラウザとバージョン別にさらに多くのメトリクスを確認します。
+
+1. 右側のスクロールバーを使用して、ページの一番下までスクロールします。
+2. ブラウザとバージョン別に利用可能なメトリクスを確認します。
+3. 国別に利用可能なメトリクスを確認します。
+
+
+
+Devices ダッシュボードに移動し、以下に説明するダッシュボードの機能を試してみましょう。
+
+1. **Devices** オプションをクリックします。
+2. デバイス別のロード内訳を確認します。
+3. 円グラフのセクションにマウスオーバーすると、詳細が表示されます。
+4. デバイス別に利用可能なパフォーマンスメトリクスを確認します。
+
+Browser Application Usage Stats ダッシュボードの詳細については、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/usage-stats) を参照してください。
+
+
+
+## Supercar-Trader アプリケーション Web ページの操作
+
+Browser Real User Monitoring エージェントを設定し、最初の一連の機能を確認できたので、次は Supercar-Trader アプリケーションの Web ページを操作して、追加のロードを生成し、固有のブラウザセッションを記録してみましょう。
+
+Web ブラウザでアプリのメインページを開きます。以下の URL の例では、ご自身の Application VM の IP アドレスまたは完全修飾ドメイン名に置き換えてください。
+
+``` bash
+http://[application-vm-ip-address]:8080/Supercar-Trader/home.do
+```
+
+アプリケーションのホームページが表示されます。
+
+
+
+利用可能な Ferrari の一覧を開きます。
+
+1. 上部メニューの **Supercars** タブをクリックします。
+2. Ferrari のロゴをクリックします。
+
+
+
+Ferrari の一覧が表示されます。
+
+
+
+最初の Ferrari の画像をクリックします。
+
+1. **View Enquiries** をクリックします。
+2. **Enquire** をクリックします。
+
+
+
+その車に関する問い合わせを送信します。
+
+1. 問い合わせフォームの各項目に適切なデータを入力します。
+2. **Submit** をクリックします。
+
+
+
+車を検索し、引き続きサイトを閲覧します。
+
+1. 上部メニューの **Search** タブをクリックします。
+2. 検索ボックスに **A** の文字を入力し、**Search** をクリックします。
+3. 残りのタブをクリックして、Web サイトを操作してみましょう。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md
new file mode 100644
index 0000000000..71538eb0b6
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md
@@ -0,0 +1,117 @@
+---
+title: モニタリングとトラブルシューティング - パート 2
+time: 2 minutes
+weight: 5
+description: この演習では、ダッシュボードを確認し、Browser Snapshot のトラブルシューティングを行います。
+---
+
+この演習では、以下のタスクを完了します。
+
+* 作成した Browser Session を確認します。
+* Pages & AJAX Requests Dashboard を確認します。
+* 特定の Base Page のダッシュボードを確認します。
+* Browser Snapshot のトラブルシューティングを行います。
+
+## 作成した Browser Session を確認する
+
+セッションは、ユーザーがアプリケーションを操作する体験を分析するための時間ベースのコンテキストとして考えることができます。ブラウザセッションを調べることで、アプリケーションがどのように動作しているか、ユーザーがどのように操作しているかを理解できます。これにより、UI の修正やサーバー側のパフォーマンス最適化など、アプリケーションをより適切に管理し改善することが可能になります。
+
+Sessions ダッシュボードに移動し、前の演習で Web アプリケーションのページを操作することによって作成したブラウザセッションを見つけます。以下の手順に従ってください。
+
+{{% notice title="Note" style="orange" %}}
+Web アプリケーションで最後のページにアクセスしてから、ブラウザセッションがセッションリストに表示されるまで 10 分ほど待つ必要がある場合があります。10 分経ってもセッションが表示されない場合は、使用している Java Agent のバージョンに問題がある可能性があります。
+{{% /notice %}}
+
+1. 左メニューの **Sessions** タブをクリックします。
+2. Session Fields リストで **IP Address** にチェックを入れます。
+3. ご自身の IP アドレスで作成したセッションを見つけます。
+4. ご自身のセッションをクリックし、**View Details** をクリックします。
+
+
+
+作成したセッションを見つけて開いたら、以下の手順に従ってセッションビューのさまざまな機能を探索します。
+
+> _Note:_ ご自身のセッションでは、いずれのページにも **View Snapshot** リンクがない場合があります（手順 5 のように）。この演習の後半で、リンクがあるセッションを見つけて探索します。
+
+1. **Session Summary** リンクをクリックして、サマリーデータを表示します。
+2. 左側に表示されているページをクリックすると、そのページの詳細が右側に表示されます。
+3. 左側のリストで選択しているページの完全な名前は常に確認できます。
+4. ウォーターフォールビューの水平な青色のバーをクリックすると、その項目の詳細が表示されます。
+5. ページによっては、サーバー側で取得された相関スナップショットへのリンクがある場合があります。
+6. 設定アイコンをクリックすると、ページリストに表示される列を変更できます。
+
+Browser RUM Sessions の詳細については、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/overview-of-the-controller-ui-for-browser-rum/browser-rum-sessions) を参照してください。
+
+
+
+## Pages & AJAX Requests Dashboard を確認する
+
+Pages & AJAX Requests ダッシュボードに移動し、そこにあるオプションを確認して、特定の Base Page ダッシュボードを開きます。以下の手順に従ってください。
+
+1. 左メニューの **Pages & AJAX Requests** タブをクリックします。
+2. ツールバーのオプションを探索します。
+3. **localhost:8080/supercar-trader/car.do** ページをクリックします。
+4. **Details** をクリックして Base Page ダッシュボードを開きます。
+
+
+
+## 特定の Base Page のダッシュボードを確認する
+
+Base Page ダッシュボードの上部には、Controller UI の右上にある時間範囲ドロップダウンで選択された期間における主要なパフォーマンス指標として、End User Response Time、Load、Cache Hits、Page Views with JS errors が表示されます。Cache Hits は、ソースからではなく、CDN などのキャッシュから取得されたリソースを示します。
+
+Timing Breakdown セクションには、ページ読み込みプロセスの各側面に必要な平均時間を表示するウォーターフォールグラフが表示されます。各メトリクスが何を測定しているかの詳細については、左側にある名前にカーソルを合わせてください。定義のポップアップが表示されます。さらに詳細な情報については、[**Browser RUM Metrics**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/browser-rum-metrics) を参照してください。
+
+以下の手順に従って、**localhost:8080/supercar-trader/car.do** Base Page の詳細を確認します。
+
+1. 時間範囲ドロップダウンを **last 2 hours** に変更します。
+2. 主要なパフォーマンス指標を探索します。
+3. ウォーターフォールビューのメトリクスを探索します。
+4. 縦のスクロールバーを使用してページを下に移動します。
+5. すべての KPI Trends のグラフを探索します。
+
+Base Page ダッシュボードの詳細については、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-real-user-monitoring/overview-of-the-controller-ui-for-browser-rum/pages-and-ajax-requests/page-ajax-and-iframe-dashboards/page-and-iframe-dashboards) を参照してください。
+
+
+
+## Browser Snapshot のトラブルシューティング
+
+{{% notice title="Note" style="orange" %}}
+ご自身のアプリケーションには Browser Snapshot が存在しない場合があり、その場合はワークフロー全体を進めることができません。別のデモアプリケーションでこのセクションを進めたい場合は、ブラウザアプリケーション **AD-Ecommerce-Browser** に切り替えることができます。
+{{% /notice %}}
+
+Browser Snapshots リストダッシュボードに移動し、特定の Browser Snapshot を開きます。以下の手順に従ってください。
+
+1. **Browser Snapshots** オプションをクリックします。
+2. **End User Response Time** 列のヘッダーを 2 回クリックして、最大の応答時間が上に表示されるようにします。
+3. 左から 3 列目にグレーまたは青のアイコンがある Browser Snapshot をクリックします。
+4. **Details** をクリックして Browser Snapshot を開きます。
+
+
+
+Browser Snapshot を開いたら、以下の手順に従って詳細を確認し、応答時間が長くなった根本原因を見つけます。
+
+1. ウォーターフォールビューを確認して、応答時間がどこで影響を受けたかを把握します。
+2. 延長された **Server Time** メトリクスに注目します。**Server Time** のラベルにカーソルを合わせてその意味を理解します。
+3. Browser Snapshot に自動的にキャプチャされ相関付けされたサーバー側のトランザクションをクリックします。
+4. **View Details** をクリックして、関連するサーバー側のスナップショットを開きます。
+
+
+
+相関付けされたサーバー側のスナップショットを開いたら、以下の手順を使用してパフォーマンス低下の根本原因を特定します。
+
+1. ブラウザで費やされたトランザクション時間の割合が最小限であることがわかります。
+2. ブラウザと Web-Portal Tier の間のタイミングは、ブラウザからの初期接続から完全な応答が返されるまでを表しています。
+3. JDBC 呼び出しが最も時間を要していることがわかります。
+4. **Drill Down** をクリックして、Enquiry-Services Tier 内のコードレベルビューを確認します。
+
+
+
+Enquiry-Services Tier のスナップショットセグメントを開くと、トランザクションに問題を引き起こしたデータベースへの JDBC 呼び出しがあったことがわかります。
+
+1. 最大時間がかかっている **JDBC** リンクをクリックして、JDBC 呼び出しの詳細パネルを開きます。
+2. JDBC 終了呼び出しの詳細パネルには、最も時間を要した特定のクエリが表示されます。
+3. SQL パラメータ値とともに、完全な SQL ステートメントを確認できます。
+
+Browser Snapshots の詳細については、[**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/browser-snapshots_1) および [**こちら**](https://help.splunk.com/en/appdynamics-saas/end-user-monitoring/25.7.0/end-user-monitoring/browser-monitoring/browser-app-dashboard/browser-snapshots_1/page-snapshots) を参照してください。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/_index.md
new file mode 100644
index 0000000000..e27abcbb9c
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/4-brum-monitoring/_index.md
@@ -0,0 +1,37 @@
+---
+title: Browser Real User Monitoring (BRUM)
+time: 2 minutes
+weight: 4
+description: このLearning Labでは、AppDynamicsを使用してブラウザベースのアプリケーションのヘルスを監視する方法を学びます。
+---
+
+## 目的
+
+このLearning Labでは、AppDynamicsを使用してブラウザベースのアプリケーションのヘルスを監視する方法を学びます。
+
+このラボを完了すると、以下を実施できるようになります。
+
+- Controllerでブラウザアプリケーションを作成する
+- Browser Real User Monitoring (BRUM) エージェントを構成して、Webアプリケーションのヘルスを監視する
+- パフォーマンス問題のトラブルシューティングを行い、トランザクションのブラウザ側とサーバー側のどちらで発生しているかにかかわらず、根本原因を特定する
+
+## ワークショップ環境
+
+ワークショップ環境には2つのホストがあります。
+
+- 1つ目のホストはAppDynamics Controllerを実行しており、以降はControllerと呼びます。
+- 2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。AppDynamicsエージェントをインストールするホストであり、以降はApplication VMと呼びます。
+
+## Controller
+
+このワークショップでは、 [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を使用します。
+
+
+
+## Application VM
+
+Supercar TraderはJavaベースのWebアプリケーションです。
+
+Supercar-Traderコレクションの目的は、AppDynamics Controller向けに動的なトラフィック（ビジネストランザクション）を生成することです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md
new file mode 100644
index 0000000000..07ec1f9f67
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md
@@ -0,0 +1,119 @@
+---
+title: ラボの前提条件
+time: 3 minutes
+weight: 1
+description: この演習では、Controller へアクセスし、アプリケーションの負荷を確認します。
+---
+
+この演習では、以下のタスクを実施します。
+
+* Web ブラウザから AppDynamics Controller にアクセスします。
+* アプリケーションへのトランザクション負荷を確認します。
+* 必要に応じて、アプリケーションとトランザクション負荷を再起動します。
+
+## Controller へのログイン
+
+[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の資格情報でログインします。
+
+## アプリケーションへのトランザクション負荷を確認する
+
+アプリケーションのフローマップを確認します。
+
+1. 時間範囲として **last 1 hour** を選択します。
+2. フローマップ上で 5 つの異なる Tier が表示されていることを確認します。
+3. 過去 1 時間にわたり一貫した負荷がかかっていることを確認します。
+
+
+
+ビジネストランザクションの一覧を確認します。
+
+1. 左側のメニューの **Business Transactions** オプションをクリックします。
+2. 以下に示す 11 個のビジネストランザクションが表示されていることを確認します。
+3. 過去 1 時間に何らかの数の呼び出しがあることを確認します。
+
+**Note:** **Calls** 列が表示されていない場合は、**View Options** ツールバーボタンをクリックして列を表示できます。
+
+
+
+Node のエージェントステータスを確認します。
+
+1. 左側のメニューの **Tiers & Nodes** オプションをクリックします。
+2. **Grid View** をクリックします。
+3. 過去 1 時間における各 Node の **App Agent Status** が 90% を超えていることを確認します。
+
+
+
+## 必要に応じてアプリケーションと負荷生成を再起動する
+
+前述のステップで実施したチェックのいずれかが確認できない場合は、**Application VM** に SSH 接続し、以下の手順に従ってアプリケーションとトランザクション負荷を再起動します。
+
+実行中の Apache Tomcat インスタンスを停止するには、以下のコマンドを使用します。
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./shutdown.sh
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+以下のコマンドを使用して、まだ実行中のアプリケーション JVM が残っていないか確認します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+ps -ef | grep Supercar-Trader
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+実行中のアプリケーション JVM が残っている場合は、以下のコマンドで残っている JVM を停止します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+sudo pkill -f Supercar-Trader
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+以下のコマンドを使用して、アプリケーションの負荷生成を停止します。すべてのプロセスが停止するまで待機します。
+
+``` bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./stop_load.sh
+```
+
+Tomcat サーバーを再起動します。
+
+``` bash
+cd /usr/local/apache/apache-tomcat-9/bin
+./startup.sh
+```
+
+2 分間待機してから、以下のコマンドを使用して Apache Tomcat がポート 8080 で実行中であることを確認します。
+
+``` bash
+sudo netstat -tulpn | grep LISTEN
+```
+
+以下の画像のように、ポート 8080 が Apache Tomcat により使用されていることを示す出力が表示されるはずです。
+
+
+
+以下のコマンドを使用して、アプリケーションの負荷生成を開始します。
+
+``` bash
+cd /opt/appdynamics/lab-artifacts/phantomjs
+./start_load.sh
+```
+
+以下の画像のような出力が表示されるはずです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md
new file mode 100644
index 0000000000..f7b61decd3
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md
@@ -0,0 +1,38 @@
+---
+title: Database Agent のダウンロード
+time: 2 minutes
+weight: 2
+description: この演習では、Web ブラウザから AppDynamics Controller にアクセスし、そこから Database Visibility agent をダウンロードします。
+---
+
+この演習では、Web ブラウザから AppDynamics Controller にアクセスし、そこから Database Visibility agent をダウンロードします。
+
+## Controller へのログイン
+
+[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の認証情報でログインします。
+
+## Database Agent のダウンロード
+
+1. 画面左上の Home タブを選択します。
+2. **Getting Started** タブを選択します。
+3. **Getting Started Wizard** をクリックします。
+
+
+
+1. **Databases** をクリックします。
+
+
+
+## Database Agent のダウンロード
+
+1. Select Database Type のドロップダウンメニューから **MySQL** を選択します。
+2. Controller の接続設定はデフォルトのままにします。
+3. **Click Here to Download** をクリックします。
+
+
+
+Database Visibility Agent のファイルをローカルファイルシステムに保存します。
+
+ブラウザから、以下の画像のような形式（OS によって異なります）で agent ファイルをローカルファイルシステムに保存するよう促されます。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md
new file mode 100644
index 0000000000..c458da61be
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md
@@ -0,0 +1,77 @@
+---
+title: Database Agent のインストール
+time: 2 minutes
+weight: 3
+description: この演習では、Database Visibility エージェントをアップロードし、ダウンロードしたファイルを解凍して、Database Visibility エージェントを起動します。
+---
+
+AppDynamics Database Agent は、データベースインスタンスおよびデータベースサーバーに関するパフォーマンスメトリクスを収集するスタンドアロンの Java プログラムです。Database Agent は Java 1.8 以上が動作する任意のマシンにデプロイできます。マシンは、AppDynamics Controller および監視対象のデータベースインスタンスへのネットワークアクセスが必要です。
+
+メモリ 16 GB の一般的なマシンで動作する Database Agent は、約 25 個のデータベースを監視できます。より大きなマシンでは、Database Agent は最大 200 個のデータベースを監視できます。
+
+この演習では、以下のタスクを実行します。
+
+- Database Visibility エージェントファイルを Application VM にアップロードする
+- ファイルシステム上の特定のディレクトリにファイルを解凍する
+- Database Visibility エージェントを起動する
+
+## Database Agent を Application VM にアップロードする
+
+この時点で、本ワークショップで使用する EC2 インスタンスに関する情報を受け取っているはずです。EC2 インスタンスの IP アドレス、SSH 接続に必要なユーザー名およびパスワードを準備してください。
+
+ローカルマシンでターミナルウィンドウを開き、Database Agent ファイルをダウンロードしたディレクトリに移動します。以下のコマンドを使用して、ファイルを EC2 インスタンスにアップロードします。完了までに時間がかかる場合があります。Windows OS をご利用の場合は、WinSCP などのプログラムを使用する必要があるかもしれません。
+
+- インスタンスの IP アドレスまたはパブリック DNS を更新してください。
+- お使いの正確なバージョンに合わせてファイル名を更新してください。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+cd ~/Downloads
+scp -P 2222 db-agent-*.zip splunk@i-0267b13f78f891b64.splunk.show:/home/splunk
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+splunk@i-0267b13f78f891b64.splunk.show's password:
+db-agent-25.7.0.5137.zip 100% 70MB 5.6MB/s 00:12
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Database Agent をインストールする
+
+Database Agent の zip ファイルを解凍するディレクトリ構造を作成します。
+
+```bash
+cd /opt/appdynamics
+mkdir dbagent
+```
+
+以下のコマンドを使用して、Database Agent の zip ファイルをディレクトリにコピーし、ファイルを解凍します。Database Agent ファイルの名前は、以下の例と少し異なる場合があります。
+
+```bash
+cp ~/db-agent-*.zip /opt/appdynamics/dbagent/
+cd /opt/appdynamics/dbagent
+unzip db-agent-*.zip
+```
+
+## Database Visibility エージェントを起動する
+
+以下のコマンドを使用して Database Agent を起動し、起動したことを確認します。
+
+**db agent 名にあなたのイニシャルを付加してください**。これは次のセクションで使用します。例: DBMon-Lab-Agent-IO
+
+```bash
+cd /opt/appdynamics/dbagent
+nohup java -Dappdynamics.agent.maxMetrics=300000 -Ddbagent.name=DBMon-Lab-Agent-YOURINITIALS -jar db-agent.jar &
+ps -ef | grep db-agent
+```
+
+以下の画像のような出力が表示されるはずです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md
new file mode 100644
index 0000000000..70fb471890
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md
@@ -0,0 +1,73 @@
+---
+title: Database Collector の設定
+time: 2 minutes
+weight: 4
+description: この演習では、コントローラーにアクセスし、Database Collector を設定し、Database Collector がデータを収集していることを確認します。
+---
+
+## Database Collector の設定
+
+Database Agent Collector は、Database Agent 内で実行され、データベースインスタンスおよびデータベースサーバーに関するパフォーマンスメトリクスを収集するプロセスです。1 つの Collector は 1 つのデータベースインスタンスのメトリクスを収集します。1 つの Database Agent 内で複数の Collector を実行できます。Database Agent がコントローラーに接続されると、コントローラー上で 1 つ以上の Collector を設定できます。
+
+この演習では、次のタスクを実行します。
+
+- Web ブラウザから AppDynamics コントローラーにアクセスする
+- コントローラーで Database Collector を設定する
+- Database Collector がデータを収集していることを確認する
+
+## コントローラーへのログイン
+
+Cisco の認証情報を使用して、[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインします。
+
+## コントローラーでの Database Collector の設定
+
+次の手順で、クエリリテラルの設定を変更し、Collector の設定画面に移動します。
+
+1. 左側のメニューで **Databases** タブをクリックします。
+2. 左下の **Configuration** タブをクリックします。
+3. **Remove literals from the queries** のチェックボックスをオフにします。
+4. **Collectors** オプションをクリックします。
+
+
+
+次の手順で、新しい Database Collector を設定します。
+
+1. **Add** ボタンをクリックします。
+2. データベースタイプとして **MySQL** を選択します。
+3. データベースエージェントとして **DBMon-Lab-Agent** を選択し、次のパラメータを入力します。
+4. Collector Name: **Supercar-MySQL-YOURINITIALS**
+5. Hostname or IP Address: **localhost**
+6. Listener Port: **3306**
+
+
+
+1. Username: **root**
+2. Password: **Welcome1!**
+
+
+
+1. **Advanced Options** の下にある **Monitor Operating System** チェックボックスを選択します。
+2. オペレーティングシステムとして **Linux** を選択し、次のパラメータを入力します。
+3. SSH Port: **22**
+4. Username: **splunk**
+5. Password: **インストラクターから提供された、EC2 インスタンスへ SSH 接続するためのパスワード**
+6. **OK** をクリックして Collector を保存します。
+
+
+
+## Database Collector がデータを収集していることの確認
+
+Collector が実行されデータが送信されるまで 10 分間待機し、次の手順で Database Collector がデータベースに接続してデータベースメトリクスを収集していることを確認します。
+
+1. 左側のメニューで **Databases** タブをクリックします
+2. 前のセクションで作成した Collector を検索します: **Supercar-MySQL-YOURINITIALS**
+3. ステータスが緑色であり、エラーが表示されていないことを確認します。
+4. Supercar-MySQL のリンクをクリックして、データベースの詳細を表示します。
+
+_注: Collector を設定してから Top 10 SQL Wait States や Queries タブの各クエリが表示されるまでに、最大 18 分かかる場合があります。_
+
+
+
+
+
+Database Collector の設定について詳しくは、[こちら](https://docs.appdynamics.com/appd/24.x/latest/en/database-visibility/add-database-collectors) を参照してください
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md
new file mode 100644
index 0000000000..08e40aa14c
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md
@@ -0,0 +1,102 @@
+---
+title: Monitor and Troubleshoot - Part 1
+time: 2 minutes
+weight: 4
+description: この演習では、データベースとサーバー全体のダッシュボードを確認し、メインのダッシュボードを確認し、データベースアクティビティウィンドウのレポートを確認します。
+---
+
+## Monitor and Troubleshoot - Part 1
+
+この演習では、以下のタスクを実行します。
+
+- Overall Database and Server Performance Dashboard を確認する
+- Main Database Dashboard を確認する
+- Database Activity Window のレポートを確認する
+
+## Overall Database and Server Performance Dashboard を確認する
+
+Overall Database and Server Performance Dashboard を使用すると、各データベースの健全性を一目で素早く確認できます。
+
+1. Filters: ヘルス、負荷、データベース内の時間、またはタイプによってフィルタリングするオプションを探索できます。
+2. Actions: このウィンドウのデータを .csv 形式のファイルにエクスポートします。
+3. View Options: スパークチャートのオン/オフを切り替えます。
+4. View: カードビューとリストビューを切り替えます。
+5. Sort: 並べ替えオプションを表示します。
+6. Supercar-MySQL: メインのデータベースダッシュボードにドリルダウンします。
+
+
+
+## Main Database Dashboard を確認する
+
+メインのデータベースダッシュボードでは、以下を含むデータベースの主要な情報を確認できます。
+
+- データベースを実行しているサーバーの健全性。
+- 指定された期間中のコールの総数。
+- 任意の時点のコール数。
+- 指定された期間中に SQL ステートメントの実行に費やされた合計時間。
+- 上位 10 件のクエリ待機状態。
+- 平均接続数。
+- データベースのタイプまたはベンダー。
+- ダッシュボードの機能を探索します。
+
+1. ヘルスステータスの円をクリックして、サーバーの健全性の詳細を確認します。
+
+- Green: サーバーは正常です。
+- Yellow: 警告レベルの違反があるサーバー。
+- Red: 重大レベルの違反があるサーバー。
+
+1. データベースのタイプまたはベンダーは常にここに表示されます。
+2. 指定された期間中に SQL ステートメントの実行に費やされた合計時間を確認します。
+3. 指定された期間中の実行の総数を確認します。
+4. チャートの時系列にカーソルを合わせると、記録されたメトリクスの詳細を確認できます。
+
+データポイントの上部にあるオレンジ色の円をクリックすると、選択した時刻の 15 分前から 15 分後までのクエリ実行時間と待機状態を示す時間比較レポートが表示されます。
+
+1. マウスの左ボタンを押したまま左から右にドラッグして、チャートで見られるスパイクをハイライトします。
+2. 設定ボタンをクリックして、不要な待機状態を上位 10 件から除外します。
+3. 各待機状態のラベルにカーソルを合わせると、より詳細な説明が表示されます。
+4. 選択した期間中にクエリを実行している、アクティブな接続の平均数を確認します。
+
+
+
+選択した期間の DB サーバーの OS メトリクスを表示するには、以下を行います。
+
+1. 右側のスクロールバーを使ってダッシュボードの一番下までスクロールします
+2. CPU
+3. Memory
+4. Disk IO
+5. Network IO
+
+
+
+## Database Activity Window のレポートを確認する
+
+Database Visibility の Database Activity Window では、最大 9 種類の異なるレポートを利用できます。利用可能なレポートは、監視対象のデータベースプラットフォームによって異なります。この演習では、最も一般的な 3 つのレポートを確認します。
+
+- Wait State Report
+- Top Activity Report
+- Query Wait State Report
+
+## Wait State Report
+
+このレポートは、データベース内の Wait Events (states) の時系列データを表示します。それぞれ異なる待機は色分けされ、Y 軸には秒単位の時間が表示されます。このレポートでは、データを表形式でも表示し、各 SQL ステートメントの各待機状態に費やされた時間をハイライト表示します。
+
+最も時間を消費している待機状態は、パフォーマンスのボトルネックを示している可能性があります。たとえば、db file sequential reads は、インデックスのセグメントヘッダー競合やディスク競合によって発生する可能性があります。
+
+
+
+## Top Activity Report
+
+このレポートは、データベース内で時間を要している上位の SQL ステートメントを時系列ビューで表示します。このレポートでは、データを表形式でも表示し、上位 10 件の SQL ステートメントごとにデータベース内で費やされた時間をハイライト表示します。
+
+このレポートを使用して、どの SQL ステートメントが最も多くのデータベース時間を使用しているかを確認します。これにより、特定の SQL ステートメントがシステム全体のパフォーマンスに与える影響を判断でき、データベースパフォーマンスへの影響が最も大きいステートメントにチューニング作業を集中させることができます。
+
+
+
+## Query Wait State Report
+
+このレポートは、上位 (10、50、100、200) のクエリの待機時間を表示します。このレポートでは、データを表形式でも表示し、各クエリがさまざまな待機状態に費やしている時間をハイライト表示します。列を使って、異なる待機状態でクエリを並べ替えることができます。
+
+Database Activity Window のレポートの詳細については、[こちら](https://help.splunk.com/en/appdynamics-on-premises/database-visibility/25.4.0/monitor-databases-and-database-servers/monitor-database-performance/database-activity-window/features-of-the-database-activity-windows) を参照してください。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md
new file mode 100644
index 0000000000..d02abb6155
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md
@@ -0,0 +1,77 @@
+---
+title: Monitor and Troubleshoot - Part 2
+weight: 5
+description: この演習では、Queries ダッシュボードを確認し、コストの高いクエリの詳細を確認し、コストの高いクエリのトラブルシューティングを行います。
+---
+
+## Queries ダッシュボードを確認する
+
+Queries 画面には、データベースで最も時間を消費している SQL ステートメントとストアドプロシージャが表示されます。クエリの重み付けを SQL 待機時間などの他のメトリクスと比較することで、チューニングが必要な SQL を特定できます。
+
+1. **Queries** タブ: queries 画面を表示します。
+2. **Top Queries** ドロップダウン: 上位 5、10、100、200 件のクエリを表示します。
+3. **Filter by Wait States**: 待機状態を選択して Query リストをフィルタリングできます。
+4. **Group Similar**: 同じ構文のクエリをグループ化します。
+5. 最大の **Weight (%)** を使用しているクエリをクリックします。
+6. **View Query Details**: クエリの詳細を掘り下げます。
+
+
+
+## コストの高いクエリの詳細を確認する
+
+Database Queries 画面でデータベース内で最も多くの時間を費やしているステートメントを特定したら、それらの SQL ステートメントのチューニングに役立つ詳細をさらに掘り下げることができます。データベースインスタンスの Query Details 画面には、Database Queries 画面で選択したクエリの詳細が表示されます。
+
+1. **Resource consumption over time**: クエリがリソースを使用してデータベース内で費やした時間、実行回数、消費した CPU 時間を表示します。
+2. **Wait states**: 選択した SQL ステートメントのデータベース処理にかかる時間に寄与するアクティビティです。最も時間を消費している待機状態は、パフォーマンスのボトルネックを示している可能性があります。
+3. **Components Executing Similar Queries**: このクエリと類似したクエリを実行する Node を表示します。
+4. **Business Transactions Executing Similar Queries**: このクエリと類似したクエリを実行する Java ビジネストランザクションを表示します。
+
+
+
+1. 右側の外側のスクロールバーを使用して下にスクロールします。
+2. **Clients**: 選択した SQL ステートメントを実行したマシンと、各マシンがステートメントの実行に要した合計時間に対する割合を表示します。
+3. **Sessions**: 各データベースインスタンス使用のセッションです。
+4. **Query Active in Database**: この SQL によってアクセスされたスキーマを表示します。
+5. **Users**: このクエリを実行したユーザーを表示します。
+6. **Query Hashcode**: クエリの一意の ID を表示します。これにより、データベースサーバーがキャッシュ内でこの SQL ステートメントをより迅速に検索できます。
+7. **Query**: 選択した SQL ステートメントの構文全体を表示します。Query カードの右上にある鉛筆アイコンをクリックして、識別しやすいようにクエリ名を編集できます。
+8. **Execution Plan**: クエリ実行計画ウィンドウを表示します。
+
+
+
+## コストの高いクエリのトラブルシューティング
+
+Database Query Execution Plan 画面は、クエリにとって最も効率的な実行計画を判断するのに役立ちます。問題のある可能性があるクエリを発見したら、EXPLAIN PLAN ステートメントを実行して、データベースが作成した実行計画を確認できます。
+
+クエリの実行計画では、クエリがインデックスの使用を最適化し、効率的に実行されているかどうかが明らかになります。この情報は、実行が遅いクエリのトラブルシューティングに役立ちます。
+
+1. **Execution Plan** タブをクリックします。
+2. **Type** 列の結合タイプが各テーブルで ALL になっていることに注目してください。
+3. 結合タイプの 1 つにマウスオーバーして、結合タイプの説明を確認します。
+4. **Extras** 列のエントリを調べます。
+5. 各エントリにマウスオーバーして、エントリの説明を確認します。
+
+
+
+次に、Object Browser を使用してテーブルのインデックスを調査します。
+
+1. **Object Browser** オプションをクリックして、テーブルのスキーマの詳細を表示します。
+2. **Database** オプションをクリックします。
+3. **supercars** スキーマをクリックして、テーブルのリストを展開します。
+4. **CARS** テーブルをクリックして、テーブルの詳細を確認します。
+5. CAR_ID 列が主キーとして定義されていることがわかります。
+
+
+
+1. 外側のスクロールバーを使用してページを下にスクロールします。
+2. テーブルに定義された主キーインデックスに注目してください。
+
+
+
+1. **MANUFACTURER** テーブルをクリックして、その詳細を表示します。
+2. **MANUFACTURER_ID** 列が主キーとして定義されていないことに注目してください。
+3. ページを下にスクロールすると、テーブルにインデックスが定義されていないことがわかります。
+
+
+
+テーブルに対するクエリのパフォーマンスを向上させるためには、MANUFACTURER_ID 列にインデックスを作成する必要があります。別のクエリを分析した場合、根本的な問題は異なるかもしれませんが、このラボで示される最も一般的な問題は、クエリが MANUFACTURER テーブルとの結合を実行しているか、そのテーブルを直接クエリしていることに起因します。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/_index.md
new file mode 100644
index 0000000000..5fc16f24e0
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/5-database-monitoring/_index.md
@@ -0,0 +1,39 @@
+---
+title: Database Monitoring
+time: 2 minutes
+weight: 5
+description: このラボでは、AppDynamics Database Visibility Monitoring について学習します。
+---
+
+## 目的
+
+このラボでは、AppDynamics Database Visibility Monitoring について学習します。
+
+このラボを完了すると、次のことができるようになります。
+
+- AppDynamics Database Visibility Agent をダウンロードする。
+- AppDynamics Database Visibility Agent をインストールする。
+- Controller で Database Collector を構成する。
+- データベースのヘルス状態を監視する。
+- データベースのパフォーマンス問題をトラブルシュートする。
+
+## ワークショップ環境
+
+ラボ環境には 2 台のホストがあります。
+
+- 1 台目のホストでは AppDynamics Controller が稼働しており、以降このホストを Controller と呼びます。
+- 2 台目のホストではラボで使用する Supercar Trader アプリケーションが稼働しています。AppDynamics エージェントをインストールするホストであり、以降このホストを Application VM と呼びます。
+
+## Controller VM
+
+このワークショップでは [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を使用します。
+
+
+
+## Application VM
+
+Supercar Trader は Java ベースの Web アプリケーションです。
+
+Supercar-Trader collection の目的は、AppDynamics Controller 向けに動的なトラフィック（ビジネストランザクション）を生成することです。
+
+
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md
new file mode 100644
index 0000000000..df06e47970
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md
@@ -0,0 +1,95 @@
+---
+title: 1. 前提条件
+weight: 1
+---
+
+リモートホストへの Smart Agent のインストールを開始する前に、以下の前提条件が整っていることを確認してください。
+
+## 必要なアクセス権
+
+- **SSH アクセス**: Smart Agent をインストールする予定のすべてのリモートホストに対して SSH アクセスが必要です
+- **SSH 秘密鍵**: 認証用に構成された SSH 秘密鍵
+- **sudo 権限**: コントロールノードのユーザーに smartagentctl を実行するための sudo 権限が必要です
+- **リモート SSH**: リモートホストで SSH が有効化され、アクセス可能である必要があります
+
+## ディレクトリ構造
+
+Smart Agent のインストールディレクトリは、コントロールノード上に配置する必要があります。
+
+```bash
+cd /home/ubuntu/appdsm
+```
+
+ディレクトリには以下が含まれます。
+
+- `smartagentctl` - SmartAgent を管理するためのコマンドラインユーティリティ
+- `smartagent` - SmartAgent のバイナリ
+- `config.ini` - メイン構成ファイル
+- `remote.yaml` - リモートホスト構成ファイル
+- `conf/` - 追加の構成ファイル
+- `lib/` - 必要なライブラリ
+
+## AppDynamics アカウント情報
+
+AppDynamics アカウントから以下の情報が必要です。
+
+- **Controller URL**: AppDynamics SaaS コントローラーのエンドポイント（例: `fso-tme.saas.appdynamics.com`）
+- **Account Name**: AppDynamics のアカウント名
+- **Account Access Key**: AppDynamics のアカウントアクセスキー
+- **Controller Port**: 通常は HTTPS 接続用の 443
+
+## ターゲットホストの要件
+
+リモートホストは以下の要件を満たしている必要があります。
+
+- **オペレーティングシステム**: Ubuntu/Linux ベースのシステム
+- **SSH サーバー**: SSH デーモンが起動しており、接続を受け付けている
+- **ユーザーアカウント**: 適切な権限を持つユーザーアカウント（通常は root）
+- **ネットワークアクセス**: AppDynamics Controller に到達可能であること
+- **ディスク容量**: Smart Agent のインストールに十分な空き容量（通常は 100MB 未満）
+
+## セキュリティ上の考慮事項
+
+作業を進める前に、以下のセキュリティのベストプラクティスを確認してください。
+
+1. **SSH 鍵**: 強力な SSH 鍵を使用する（RSA 4096 ビットまたは ED25519）
+2. **アクセスキー**: AccountAccessKey を安全に保管する
+3. **ホスト鍵の検証**: 本番環境ではホスト鍵を検証する計画を立てる
+4. **SSL/TLS**: コントローラーとの通信には常に SSL/TLS を使用する
+5. **ログファイル**: 機密情報を含むログファイルへのアクセスを制限する
+
+## 前提条件の確認
+
+### SSH 接続性の確認
+
+リモートホストへの SSH 接続をテストします。
+
+```bash
+ssh -i /home/ubuntu/.ssh/id_rsa ubuntu@
+```
+
+### SSH 鍵のパーミッション確認
+
+SSH 鍵に適切なパーミッションが設定されていることを確認します。
+
+```bash
+chmod 600 /home/ubuntu/.ssh/id_rsa
+```
+
+### ネットワーク接続性の確認
+
+リモートホスト同士、およびインターネットに到達できることを確認します。
+
+```bash
+ping
+```
+
+### sudo アクセスの確認
+
+sudo 権限があることを確認します。
+
+```bash
+sudo -v
+```
+
+すべての前提条件が満たされていれば、構成のステップに進む準備が整っています。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md
new file mode 100644
index 0000000000..7bc4806d7f
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md
@@ -0,0 +1,310 @@
+---
+title: 2. 設定
+weight: 2
+---
+
+Smart Agent のリモートインストールには、2 つの主要な設定ファイルが必要です。Smart Agent の設定用の `config.ini` と、リモートホストおよび接続パラメータを定義する `remote.yaml` です。
+
+## 設定ファイルの概要
+
+両方の設定ファイルは Smart Agent インストールディレクトリ内に配置する必要があります。
+
+```bash
+cd /home/ubuntu/appdsm
+```
+
+設定する 2 つのファイルは次のとおりです。
+
+- `config.ini` - すべてのリモートホストにデプロイされる Smart Agent 設定
+- `remote.yaml` - リモートホストおよび SSH 接続設定
+
+## config.ini - Smart Agent の設定
+
+`config.ini` ファイルには、すべてのリモートホストにデプロイされる Smart Agent のメイン設定が含まれます。
+
+**場所:** `/home/ubuntu/appdsm/config.ini`
+
+### Controller の設定
+
+AppDynamics Controller への接続を設定します。
+
+```ini
+ControllerURL = fso-tme.saas.appdynamics.com
+ControllerPort = 443
+FMServicePort = 443
+AccountAccessKey = your-access-key-here
+AccountName = your-account-name
+EnableSSL = true
+```
+
+**主要なパラメータ:**
+
+- `ControllerURL`: AppDynamics SaaS コントローラーのエンドポイント
+- `ControllerPort`: コントローラー用の HTTPS ポート (デフォルト: 443)
+- `FMServicePort`: Flow Monitoring サービスのポート
+- `AccountAccessKey`: AppDynamics アカウントのアクセスキー
+- `AccountName`: AppDynamics アカウント名
+- `EnableSSL`: SSL/TLS 暗号化を有効化 (本番環境では `true` を推奨)
+
+### 共通設定
+
+エージェントのアイデンティティとポーリング動作を定義します。
+
+```ini
+[CommonConfig]
+AgentName = smartagent
+PollingIntervalInSec = 300
+Tags = environment:production,region:us-east
+ServiceName = my-application
+```
+
+**パラメータ:**
+
+- `AgentName`: エージェントの名前識別子
+- `PollingIntervalInSec`: エージェントがデータをポーリングする頻度 (秒単位)
+- `Tags`: エージェントを分類するためのカスタムタグ (カンマ区切り)
+- `ServiceName`: 論理的なグループ化のためのオプションのサービス名
+
+### Telemetry 設定
+
+ロギングとプロファイリングを設定します。
+
+```ini
+[Telemetry]
+LogLevel = DEBUG
+LogFile = /opt/appdynamics/appdsmartagent/log.log
+Profiling = false
+```
+
+**パラメータ:**
+
+- `LogLevel`: ロギングの詳細度 (`DEBUG`, `INFO`, `WARN`, `ERROR`)
+- `LogFile`: リモートホストでログが書き込まれるパス
+- `Profiling`: パフォーマンスプロファイリングの有効化 (`true`/`false`)
+
+### TLS クライアント設定
+
+プロキシおよび TLS の設定を行います。
+
+```ini
+[TLSClientSetting]
+Insecure = false
+AgentHTTPProxy =
+AgentHTTPSProxy =
+AgentNoProxy =
+```
+
+**パラメータ:**
+
+- `Insecure`: TLS 証明書の検証をスキップ (本番環境では非推奨)
+- `AgentHTTPProxy`: HTTP プロキシサーバーの URL (必要な場合)
+- `AgentHTTPSProxy`: HTTPS プロキシサーバーの URL (必要な場合)
+- `AgentNoProxy`: プロキシをバイパスするホストのカンマ区切りリスト
+
+### 自動検出
+
+アプリケーションの自動検出を設定します。
+
+```ini
+[AutoDiscovery]
+RunAutoDiscovery = false
+ExcludeLabels = process.cpu.usage,process.memory.usage
+ExcludeProcesses =
+ExcludeUsers =
+AutoDiscoveryTimeInterval = 4h
+AutoInstall = false
+```
+
+**パラメータ:**
+
+- `RunAutoDiscovery`: アプリケーションを自動検出する (`true`/`false`)
+- `ExcludeLabels`: 検出から除外するメトリクス
+- `ExcludeProcesses`: 監視から除外するプロセス名
+- `ExcludeUsers`: 監視から除外するユーザーアカウント
+- `AutoDiscoveryTimeInterval`: 検出を実行する頻度 (例: `4h`、`30m`)
+- `AutoInstall`: 検出されたアプリケーションを自動インストール
+
+### タスク設定
+
+ネイティブインスツルメンテーションを設定します。
+
+```ini
+[TaskConfig]
+NativeEnable = true
+UserPortalUserName =
+UserPortalPassword =
+UserPortalAuth = none
+AutoUpdateLdPreload = true
+```
+
+**パラメータ:**
+
+- `NativeEnable`: ネイティブインスツルメンテーションを有効化
+- `AutoUpdateLdPreload`: LD_PRELOAD 設定を自動更新
+
+## remote.yaml - リモートホストの設定
+
+`remote.yaml` ファイルでは、Smart Agent をインストールするリモートホストと接続パラメータを定義します。
+
+**場所:** `/home/ubuntu/appdsm/remote.yaml`
+
+### 設定例
+
+```yaml
+max_concurrency: 4
+remote_dir: "/opt/appdynamics/appdsmartagent"
+protocol:
+ type: ssh
+ auth:
+ username: ubuntu
+ private_key_path: /home/ubuntu/.ssh/id_rsa
+ privileged: true
+ ignore_host_key_validation: true
+ known_hosts_path: /home/ubuntu/.ssh/known_hosts
+hosts:
+ - host: "172.31.1.243"
+ port: 22
+ user: root
+ group: root
+ - host: "172.31.1.48"
+ port: 22
+ user: root
+ group: root
+ - host: "172.31.1.142"
+ port: 22
+ user: root
+ group: root
+ - host: "172.31.1.5"
+ port: 22
+ user: root
+ group: root
+```
+
+### グローバル設定
+
+**max_concurrency:** 同時に処理するホストの最大数
+
+- デフォルト: `4`
+- 多数のホストへ高速にデプロイする場合は増やします
+- ネットワークやリソースの制約がある場合は減らします
+
+**remote_dir:** リモートホスト上のインストールディレクトリ
+
+- デフォルト: `/opt/appdynamics/appdsmartagent`
+- 絶対パスである必要があります
+- ユーザーには書き込み権限が必要です
+
+### プロトコル設定
+
+**type:** 接続プロトコル
+
+- 値: `ssh`
+
+**auth.username:** 認証用の SSH ユーザー名
+
+- 例: `ubuntu`、`ec2-user`、`centos`
+- リモートホストで設定されているユーザーと一致する必要があります
+
+**auth.private_key_path:** SSH 秘密鍵のパス
+
+- 絶対パスである必要があります
+- 鍵にアクセスでき、適切なパーミッション (600) が設定されている必要があります
+
+**auth.privileged:** 昇格された権限でエージェントを実行
+
+- `true`: root / systemd サービスとしてインストール
+- `false`: ユーザープロセスとしてインストール
+- 推奨: 本番デプロイでは `true`
+
+**auth.ignore_host_key_validation:** SSH ホストキー検証をスキップ
+
+- `true`: 検証をスキップ (テストに便利)
+- `false`: ホストキーを検証 (本番環境で推奨)
+
+**auth.known_hosts_path:** SSH known_hosts ファイルのパス
+
+- デフォルト: `/home/ubuntu/.ssh/known_hosts`
+- ホストキー検証が有効な場合に使用されます
+
+### ホスト定義
+
+各ホストエントリには以下が必要です。
+
+**host:** リモートマシンの IP アドレスまたはホスト名
+
+- IPv4、IPv6、またはホスト名が使用可能です
+- 制御ノードから到達可能である必要があります
+
+**port:** SSH ポート
+
+- デフォルト: `22`
+- SSH が標準以外のポートで動作している場合は変更します
+
+**user:** Smart Agent プロセスを所有するユーザーアカウント
+
+- システム全体のインストールでは通常 `root`
+- ユーザー固有のインストールでは一般ユーザーも指定可能
+
+**group:** Smart Agent プロセスを所有するグループ
+
+- 通常はユーザーと一致します (例: `root`)
+
+### ホストの追加
+
+リモートホストを追加するには、`hosts` リストに追記します。
+
+```yaml
+hosts:
+ - host: "10.0.1.10"
+ port: 22
+ user: root
+ group: root
+ - host: "10.0.1.11"
+ port: 22
+ user: root
+ group: root
+```
+
+{{% notice title="ヒント" style="info" icon="info-circle" %}}
+必要に応じて任意の数のホストを追加できます。`max_concurrency` 設定によって並列処理されるホスト数が制御されます。
+{{% /notice %}}
+
+## 設定の確認
+
+インストールに進む前に、設定ファイルを確認します。
+
+### remote.yaml の確認
+
+```bash
+cat /home/ubuntu/appdsm/remote.yaml
+```
+
+次の点を確認します。
+
+- すべてのホスト IP アドレスが正しいこと
+- SSH キーのパスが有効であること
+- リモートディレクトリのパスが適切であること
+
+### config.ini の確認
+
+```bash
+cat /home/ubuntu/appdsm/config.ini
+```
+
+次の点を確認します。
+
+- Controller URL とアカウント情報が正しいこと
+- ログファイルのパスが有効であること
+- 設定が環境要件に合致していること
+
+### YAML 構文の検証
+
+YAML ファイルが正しくフォーマットされていることを確認します。
+
+```bash
+python3 -c "import yaml; yaml.safe_load(open('/home/ubuntu/appdsm/remote.yaml'))"
+```
+
+コマンドがエラーなく完了すれば、YAML 構文は有効です。
+
+設定ファイルの準備が完了したら、インストールに進みます。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md
new file mode 100644
index 0000000000..a1084ac486
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md
@@ -0,0 +1,229 @@
+---
+title: 3. インストールと起動
+weight: 3
+---
+
+設定ファイルの準備が完了したので、`smartagentctl` コマンドラインツールを使用してリモートホストに Smart Agent をインストールして起動できます。
+
+## インストールプロセスの概要
+
+インストールプロセスには以下が含まれます。
+
+1. **接続**: 定義されたすべてのホストに対して SSH 接続を確立します
+2. **転送**: Smart Agent のバイナリと設定をリモートホストにコピーします
+3. **インストール**: 各ホストの `/opt/appdynamics/appdsmartagent/` に Smart Agent をインストールします
+4. **起動**: 各リモートホストで Smart Agent プロセスを起動します
+5. **ロギング**: コンソールとログファイルに詳細な進行状況を出力します
+
+## ステップ 1: インストールディレクトリへの移動
+
+Smart Agent インストールディレクトリに移動します。
+
+```bash
+cd /home/ubuntu/appdsm
+```
+
+## ステップ 2: 設定ファイルの確認
+
+インストールを開始する前に、設定ファイルが正しくセットアップされていることを確認します。
+
+### リモートホスト設定の確認
+
+```bash
+cat remote.yaml
+```
+
+すべてのホスト IP アドレス、ポート、SSH 設定が正しいことを確認してください。
+
+### エージェント設定の確認
+
+```bash
+cat config.ini
+```
+
+コントローラーの URL、アカウント認証情報、その他の設定が正確であることを確認してください。
+
+## ステップ 3: リモートホストでの Smart Agent の起動
+
+`remote.yaml` で定義されたすべてのリモートホストで Smart Agent を起動するには、次のコマンドを実行します。
+
+```bash
+sudo ./smartagentctl start --remote --verbose
+```
+
+### コマンドの内訳
+
+- `sudo`: 特権操作に必要です
+- `./smartagentctl`: 制御ユーティリティです
+- `start`: Smart Agent を起動するコマンドです
+- `--remote`: リモートホストへデプロイします（`remote.yaml` から読み込みます）
+- `--verbose`: 詳細なデバッグログを有効にします
+
+{{% notice title="注意" style="warning" icon="triangle-exclamation" %}}
+`--verbose` フラグは、インストールの進行状況に関する詳細な出力を提供し、問題の特定に役立つため、強く推奨されます。
+{{% /notice %}}
+
+## ステップ 4: インストールの監視
+
+`--verbose` フラグは、以下を含む詳細な出力を提供します。
+
+- SSH 接続ステータス
+- ファイル転送の進行状況
+- 各ホストでのインストール手順
+- エージェントの起動ステータス
+- エラーや警告
+
+### 期待される出力
+
+次のような出力が表示されるはずです。
+
+```
+Starting Smart Agent deployment to remote hosts...
+Connecting to 172.31.1.243:22...
+Connection successful: 172.31.1.243
+Transferring Smart Agent binaries...
+Installing Smart Agent on 172.31.1.243...
+Starting Smart Agent on 172.31.1.243...
+Smart Agent started successfully on 172.31.1.243
+
+Connecting to 172.31.1.48:22...
+...
+```
+
+## ステップ 5: インストールの確認
+
+インストールが完了したら、リモートホストで Smart Agent が稼働していることを確認します。
+
+### リモートでのステータス確認
+
+status コマンドを使用して、すべてのリモートホストを確認します。
+
+```bash
+sudo ./smartagentctl status --remote --verbose
+```
+
+これにより、各ホストにクエリを実行し、Smart Agent が稼働しているかどうかを報告します。
+
+### コントロールノードでのログ確認
+
+コントロールノードでログを表示します。
+
+```bash
+tail -f /home/ubuntu/appdsm/log.log
+```
+
+### リモートホストへの SSH 接続による確認
+
+リモートホストに SSH で接続して、直接確認することもできます。
+
+```bash
+ssh ubuntu@172.31.1.243
+tail -f /opt/appdynamics/appdsmartagent/log.log
+ps aux | grep smartagent
+```
+
+## 追加コマンド
+
+### 起動せずにインストール
+
+Smart Agent を起動せずにインストールするには、以下を実行します。
+
+```bash
+sudo ./smartagentctl install --remote --verbose
+```
+
+これは、バイナリと設定をコピーしますが、エージェントプロセスは起動しません。
+
+### Smart Agent の停止
+
+すべてのリモートホストで Smart Agent を停止するには、以下を実行します。
+
+```bash
+sudo ./smartagentctl stop --remote --verbose
+```
+
+### システムサービスとしてのインストール
+
+Smart Agent を systemd サービスとしてインストールするには（本番環境では推奨）、以下を実行します。
+
+```bash
+sudo ./smartagentctl start --remote --verbose --service
+```
+
+サービスとしてインストールした場合、
+
+- Smart Agent はシステム起動時に自動的に開始します
+- `systemctl` コマンドを使用して管理できます
+- システムロギングとの統合が向上します
+
+### Smart Agent のアンインストール
+
+リモートホストから Smart Agent を完全に削除するには、以下を実行します。
+
+```bash
+sudo ./smartagentctl uninstall --remote --verbose
+```
+
+{{% notice title="警告" style="danger" icon="exclamation-triangle" %}}
+uninstall コマンドは、リモートホストからすべての Smart Agent ファイルを削除します。重要な設定ファイルやログファイルのバックアップがあることを確認してください。
+{{% /notice %}}
+
+## AppDynamics Controller での確認
+
+リモートホストで Smart Agent を起動した後、
+
+1. **AppDynamics Controller へのログイン**: コントローラーの URL に移動します
+2. **Servers への移動**: Controller UI の Servers セクションを確認します
+3. **エージェントの確認**: リストに Smart Agent が表示されるはずです
+4. **メトリクスの確認**: 各ホストからメトリクスが収集されていることを確認します
+
+### 期待されるタイムライン
+
+- **エージェント登録**: エージェントは通常 1〜2 分以内に Controller に表示されます
+- **初期メトリクス**: 最初のメトリクスは通常 5 分以内に到着します
+- **完全なデータ**: 完全なデータ収集は、最初のポーリング間隔（`config.ini` で設定）の後に開始します
+
+## ログファイルの場所
+
+ログはコントロールノードとリモートホストの両方に書き込まれます。
+
+| 場所 | パス | 説明 |
+|----------|------|-------------|
+| **コントロールノード** | `/home/ubuntu/appdsm/log.log` | インストールおよびデプロイのログ |
+| **リモートホスト** | `/opt/appdynamics/appdsmartagent/log.log` | エージェントのランタイムログ |
+
+## 並列処理について
+
+`remote.yaml` の `max_concurrency` 設定は、並列実行を制御します。
+
+- **低い値 (1〜2)**: 順次処理、低速だが安全
+- **デフォルト (4)**: ほとんどの環境で適切なバランス
+- **高い値 (8 以上)**: 多数のホストへの高速デプロイ、より多くのリソースが必要
+
+例: 12 個のホストと `max_concurrency: 4` の場合、
+
+- 第 1 バッチ: ホスト 1〜4 が同時に処理されます
+- 第 2 バッチ: ホスト 5〜8 が同時に処理されます
+- 第 3 バッチ: ホスト 9〜12 が同時に処理されます
+
+## 各リモートホストで何が起こるか
+
+start コマンドを実行すると、各リモートホストで以下が発生します。
+
+1. **ディレクトリ作成**: `/opt/appdynamics/appdsmartagent/` を作成します
+2. **ファイル転送**: `smartagent` バイナリ、`config.ini`、ライブラリをコピーします
+3. **権限設定**: 適切なファイル権限を設定します
+4. **プロセス開始**: Smart Agent プロセスを起動します
+5. **検証**: プロセスが稼働していることを確認します
+
+## 次のステップ
+
+Smart Agent のインストールと起動が成功したら、
+
+1. ✅ AppDynamics Controller UI にエージェントが表示されることを確認します
+2. ✅ メトリクスが収集されていることを確認します
+3. ✅ 必要に応じてアプリケーション監視を設定します
+4. ✅ アラートとダッシュボードをセットアップします
+5. ✅ エージェントのヘルスとパフォーマンスを監視します
+
+問題が発生した場合は、Troubleshooting セクションに進んでください。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md
new file mode 100644
index 0000000000..1e9a13546c
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md
@@ -0,0 +1,465 @@
+---
+title: 4. Troubleshooting
+weight: 4
+---
+
+このセクションでは、Smart Agent をリモートホストへデプロイする際に発生しうる一般的な問題と、その解決方法について説明します。
+
+## SSH 接続の問題
+
+### 問題: リモートホストに接続できない
+
+**症状:**
+
+- 接続タイムアウトエラー
+- "Permission denied" メッセージ
+- ホストキー検証エラー
+
+**解決方法:**
+
+#### 1. SSH キーのパーミッションを確認する
+
+SSH キーには正しいパーミッションが設定されている必要があります。
+
+```bash
+chmod 600 /home/ubuntu/.ssh/id_rsa
+chmod 644 /home/ubuntu/.ssh/id_rsa.pub
+chmod 700 /home/ubuntu/.ssh
+```
+
+#### 2. SSH 接続を手動でテストする
+
+各リモートホストへの接続をテストします。
+
+```bash
+ssh -i /home/ubuntu/.ssh/id_rsa ubuntu@172.31.1.243
+```
+
+これが失敗する場合、問題は smartagentctl ではなく SSH 設定にあります。
+
+#### 3. リモートホストへの到達性を確認する
+
+ネットワーク接続性を確認します。
+
+```bash
+ping 172.31.1.243
+telnet 172.31.1.243 22
+```
+
+#### 4. SSH ユーザーを確認する
+
+`remote.yaml` 内のユーザー名が SSH ユーザーと一致していることを確認します。
+
+```yaml
+protocol:
+ auth:
+ username: ubuntu # Must match your SSH user
+```
+
+#### 5. known_hosts を確認する
+
+ホストキーの検証が有効な場合、ホストが known_hosts に登録されていることを確認します。
+
+```bash
+ssh-keyscan 172.31.1.243 >> /home/ubuntu/.ssh/known_hosts
+```
+
+または、`remote.yaml` 内で一時的にホストキー検証を無効にします。
+
+```yaml
+protocol:
+ auth:
+ ignore_host_key_validation: true
+```
+
+{{% notice title="Warning" style="danger" icon="exclamation-triangle" %}}
+ホストキー検証の無効化はテスト目的のみで使用してください。本番環境では必ず有効にしてください。
+{{% /notice %}}
+
+## パーミッションの問題
+
+### 問題: インストール時に Permission Denied が発生する
+
+**症状:**
+
+- ディレクトリ作成時の "Permission denied"
+- `/opt/appdynamics/` への書き込み不可
+- 権限不足エラー
+
+**解決方法:**
+
+#### 1. コントロールノードでの sudo アクセスを確認する
+
+```bash
+sudo -v
+```
+
+#### 2. Privileged 設定を確認する
+
+`remote.yaml` で `privileged: true` が設定されていることを確認します。
+
+```yaml
+protocol:
+ auth:
+ privileged: true
+```
+
+#### 3. リモートユーザーの権限を確認する
+
+リモートユーザーは sudo 権限を持っているか root である必要があります。リモートホスト上で以下をテストします。
+
+```bash
+ssh ubuntu@172.31.1.243
+sudo mkdir -p /opt/appdynamics/test
+sudo rm -rf /opt/appdynamics/test
+```
+
+#### 4. リモートディレクトリのパーミッションを確認する
+
+カスタムインストールディレクトリを使用している場合、そのディレクトリが書き込み可能であることを確認します。
+
+```bash
+ssh ubuntu@172.31.1.243
+ls -la /opt/appdynamics/
+```
+
+## Agent が起動しない
+
+### 問題: エージェントのインストールは成功するがエージェントが起動しない
+
+**症状:**
+
+- インストールはエラーなく完了する
+- リモートホスト上でエージェントプロセスが動作していない
+- コントロールノードのログにエラーがない
+
+**解決方法:**
+
+#### 1. リモートホストのログを確認する
+
+リモートホストに SSH 接続し、エージェントログを確認します。
+
+```bash
+ssh ubuntu@172.31.1.243
+tail -100 /opt/appdynamics/appdsmartagent/log.log
+```
+
+以下を示すエラーメッセージを探します。
+
+- 設定エラー
+- ネットワーク接続性の問題
+- 依存関係の不足
+
+#### 2. エージェントプロセスを確認する
+
+エージェントプロセスが動作しているか確認します。
+
+```bash
+ssh ubuntu@172.31.1.243
+ps aux | grep smartagent
+```
+
+動作していない場合、手動で起動を試みます。
+
+```bash
+ssh ubuntu@172.31.1.243
+cd /opt/appdynamics/appdsmartagent
+sudo ./smartagent
+```
+
+#### 3. 設定ファイルを確認する
+
+`config.ini` が正しく転送されているか確認します。
+
+```bash
+ssh ubuntu@172.31.1.243
+cat /opt/appdynamics/appdsmartagent/config.ini
+```
+
+以下を確認します。
+
+- Controller URL が正しい
+- アカウント認証情報が有効である
+- 必須フィールドがすべて入力されている
+
+#### 4. Controller への接続をテストする
+
+リモートホストから AppDynamics Controller への接続を確認します。
+
+```bash
+ssh ubuntu@172.31.1.243
+curl -I https://fso-tme.saas.appdynamics.com
+```
+
+#### 5. システムリソースを確認する
+
+リモートホストに十分なリソースがあることを確認します。
+
+```bash
+ssh ubuntu@172.31.1.243
+df -h # Check disk space
+free -m # Check memory
+```
+
+## 設定エラー
+
+### 問題: 設定が無効である
+
+**症状:**
+
+- YAML パースエラー
+- 無効な設定パラメータエラー
+- 設定エラーによりエージェントが起動しない
+
+**解決方法:**
+
+#### 1. YAML 構文を検証する
+
+`remote.yaml` の YAML 構文エラーを確認します。
+
+```bash
+python3 -c "import yaml; yaml.safe_load(open('/home/ubuntu/appdsm/remote.yaml'))"
+```
+
+YAML でよくある問題:
+
+- 不正なインデント (タブではなくスペースを使用)
+- コロンの欠落
+- 引用符で囲まれていない特殊文字
+
+#### 2. INI ファイルの形式を確認する
+
+`config.ini` の構文エラーを確認します。
+
+```bash
+cat /home/ubuntu/appdsm/config.ini
+```
+
+INI でよくある問題:
+
+- セクションヘッダーの欠落 (例: `[CommonConfig]`)
+- 無効なパラメータ名
+- イコール記号の欠落
+
+#### 3. Controller の認証情報を検証する
+
+AppDynamics の認証情報が正しいことを確認します。
+
+- **ControllerURL**: `https://` や `/controller` を含めるべきではありません
+- **AccountAccessKey**: 完全なアクセスキーである必要があります
+- **AccountName**: アカウント名と完全一致する必要があります
+
+正しい形式の例:
+
+```ini
+ControllerURL = fso-tme.saas.appdynamics.com
+AccountAccessKey = abc123xyz789
+AccountName = fso-tme
+```
+
+## Agent が Controller に表示されない
+
+### 問題: エージェントは起動するが Controller UI に表示されない
+
+**症状:**
+
+- リモートホスト上でエージェントプロセスが動作している
+- エージェントログにエラーがない
+- Controller UI にエージェントが表示されない
+
+**解決方法:**
+
+#### 1. 初回登録を待つ
+
+エージェントは起動後、Controller に表示されるまでに 1〜5 分かかる場合があります。
+
+#### 2. Controller の設定を確認する
+
+エージェントが Controller に到達できるかを確認します。
+
+```bash
+ssh ubuntu@172.31.1.243
+ping fso-tme.saas.appdynamics.com
+curl -I https://fso-tme.saas.appdynamics.com
+```
+
+#### 3. エージェントログで接続エラーを確認する
+
+Controller への接続エラーを探します。
+
+```bash
+ssh ubuntu@172.31.1.243
+grep -i "error\|fail\|controller" /opt/appdynamics/appdsmartagent/log.log
+```
+
+#### 4. SSL/TLS 設定を確認する
+
+`config.ini` で SSL が有効になっていることを確認します。
+
+```ini
+EnableSSL = true
+```
+
+#### 5. ファイアウォールルールを確認する
+
+リモートホストから Controller へのアウトバウンド HTTPS (ポート 443) が許可されていることを確認します。
+
+#### 6. アカウント認証情報を確認する
+
+Controller UI で AccountAccessKey と AccountName が正しいかを再確認します。
+
+- AppDynamics Controller にログインします
+- Settings → License に移動します
+- アカウント名とアクセスキーを確認します
+
+## パフォーマンスとスケーリングの問題
+
+### 問題: デプロイが遅い、またはタイムアウトする
+
+**症状:**
+
+- デプロイに時間がかかりすぎる
+- 多数のホストにデプロイする際のタイムアウトエラー
+- システムリソースの枯渇
+
+**解決方法:**
+
+#### 1. 同時実行数を調整する
+
+問題が発生する場合は `remote.yaml` の `max_concurrency` を減らします。
+
+```yaml
+max_concurrency: 2 # Lower value for slower, more stable deployment
+```
+
+リソースに余裕がある場合は、より高速なデプロイのために増やします。
+
+```yaml
+max_concurrency: 8 # Higher value for faster deployment
+```
+
+#### 2. バッチでデプロイする
+
+非常に大規模なデプロイでは、ホストを複数のグループに分割します。
+
+**remote-batch1.yaml:**
+
+```yaml
+hosts:
+ - host: "172.31.1.1"
+ - host: "172.31.1.2"
+ - host: "172.31.1.3"
+```
+
+**remote-batch2.yaml:**
+
+```yaml
+hosts:
+ - host: "172.31.1.4"
+ - host: "172.31.1.5"
+ - host: "172.31.1.6"
+```
+
+その後、各バッチを個別にデプロイします。
+
+#### 3. ネットワーク帯域幅を確認する
+
+デプロイ中のネットワーク使用状況を監視します。
+
+```bash
+iftop
+```
+
+帯域幅が飽和している場合、同時実行数を減らすか、オフピーク時間帯にデプロイします。
+
+## ログ分析
+
+### コントロールノードのログを確認する
+
+詳細なデプロイログを表示します。
+
+```bash
+tail -f /home/ubuntu/appdsm/log.log
+```
+
+以下を探します。
+
+- SSH 接続の失敗
+- ファイル転送エラー
+- パーミッション拒否エラー
+- タイムアウトメッセージ
+
+### リモートホストのログを確認する
+
+リモートホスト上のエージェントランタイムログを表示します。
+
+```bash
+ssh ubuntu@172.31.1.243
+tail -f /opt/appdynamics/appdsmartagent/log.log
+```
+
+以下を探します。
+
+- Controller への接続エラー
+- 設定エラー
+- エージェントの起動失敗
+- ネットワークの問題
+
+### ログの詳細度を上げる
+
+より詳細なロギングのため、`config.ini` で `LogLevel` を `DEBUG` に設定します。
+
+```ini
+[Telemetry]
+LogLevel = DEBUG
+```
+
+## ヘルプの取得
+
+それでも問題が解決しない場合:
+
+1. **ドキュメントを確認する**: smartagentctl のヘルプを確認します。
+
+ ```bash
+ ./smartagentctl --help
+ ./smartagentctl start --help
+ ```
+
+2. **AppDynamics ドキュメントを確認する**: AppDynamics のドキュメントポータルを参照します。
+
+3. **ログファイルを確認する**: コントロールノードとリモートホストの両方のログを必ず確認します。
+
+4. **コンポーネントを個別にテストする**:
+ - SSH 接続性を個別にテストする
+ - 単一ホストでエージェントの起動を手動でテストする
+ - Controller への接続性を個別に検証する
+
+5. **診断情報を収集する**:
+ - コントロールノードのログ
+ - リモートホストのログ
+ - 設定ファイル (機密データはマスクする)
+ - エラーメッセージとスタックトレース
+
+## 一般的なエラーメッセージ
+
+| エラーメッセージ | 原因 | 解決方法 |
+|--------------|-------|----------|
+| "Permission denied (publickey)" | SSH キー認証の失敗 | SSH キーのパスとパーミッションを確認する |
+| "Connection refused" | SSH ポートにアクセスできない | ファイアウォールルールと SSH デーモンを確認する |
+| "No such file or directory" | 設定ファイルの欠落 | 設定ファイルが存在しパスが正しいことを確認する |
+| "YAML parse error" | 無効な YAML 構文 | パーサーで YAML 構文を検証する |
+| "Controller unreachable" | ネットワーク接続性の問題 | リモートホストから Controller への接続をテストする |
+| "Invalid credentials" | アカウントキーまたは名前が誤っている | AppDynamics の認証情報を確認する |
+
+## トラブルシューティングのベストプラクティス
+
+1. **常に --verbose フラグを使用する**: デバッグのための詳細な出力を提供します
+2. **まず単一ホストでテストする**: スケールする前に 1 台のホストにデプロイします
+3. **すぐにログを確認する**: デプロイ直後にログを確認します
+4. **前提条件を確認する**: デプロイ前にすべての要件が満たされていることを確認します
+5. **接続性を個別にテストする**: SSH とネットワークの接続性を個別に検証します
+6. **手動コマンドを使用する**: 手動の SSH とエージェント起動をテストして問題を切り分けます
+
+{{% notice title="Tip" style="info" icon="lightbulb" %}}
+トラブルシューティングを行う際は、複雑な問題に取り組む前に、まず最も単純なテスト (例: ping、SSH 接続性) から始めてください。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/_index.md
new file mode 100644
index 0000000000..b606457130
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/1-remote-installation/_index.md
@@ -0,0 +1,81 @@
+---
+title: Remote Installation
+weight: 1
+time: 2 minutes
+description: smartagentctl を使用して、複数のリモートホストに AppDynamics Smart Agent をインストールおよび管理する方法を学びます。
+---
+
+## はじめに
+
+このワークショップでは、**smartagentctl** コマンドラインツールを使用して、複数のリモートホストに **AppDynamics Smart Agent** を同時にインストールおよび管理する方法を紹介します。このアプローチは、Jenkins や GitHub Actions などの追加の自動化ツールを必要とせずに、SSH ベースのリモート実行を使用してサーバー群に Smart Agent を迅速にデプロイするのに理想的です。
+
+
+
+## 学習内容
+
+このワークショップでは、以下の方法を学習します。
+
+- `remote.yaml` ファイルを使用した**リモートホストの設定**
+- `config.ini` を使用した **Smart Agent の設定**
+- SSH 経由で複数のホストに **Smart Agent を同時にデプロイ**
+- インフラ全体で**エージェントをリモートで開始および停止**
+- すべてのリモートホストで**エージェントのステータスを確認**
+- 一般的なインストールおよび接続の問題の**トラブルシューティング**
+
+## 主な機能
+
+- 🚀 **直接 SSH デプロイメント** - 追加の自動化プラットフォームは不要
+- 🔄 **完全なライフサイクル管理** - エージェントのインストール、開始、停止、アンインストール
+- 🏗️ **Configuration as Code** - YAML および INI ベースの設定ファイル
+- 🔐 **セキュア** - SSH 鍵ベースの認証
+- 📈 **並行実行** - 並列デプロイメント用の設定可能な並行性
+- 🎛️ **シンプルな CLI** - 使いやすい smartagentctl コマンドラインインターフェイス
+
+## アーキテクチャ概要
+
+```text
+┌─────────────────────────────────────────────────────────────────┐
+│ Remote Installation Architecture │
+├─────────────────────────────────────────────────────────────────┤
+│ │
+│ Control Node (smartagentctl) ──▶ SSH Connection │
+│ │ │
+│ ├──▶ Host 1 (SSH) │
+│ ├──▶ Host 2 (SSH) │
+│ ├──▶ Host 3 (SSH) │
+│ └──▶ Host N (SSH) │
+│ │
+│ All hosts send metrics ──▶ AppDynamics Controller │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+## ワークショップ構成
+
+このワークショップには以下が含まれます。
+
+1. **前提条件** - 必要なアクセス、ツール、権限
+2. **設定** - `config.ini` および `remote.yaml` のセットアップ
+3. **インストールと起動** - リモートホストへの Smart Agent のデプロイと起動
+4. **トラブルシューティング** - 一般的な問題と解決策
+
+## 前提条件
+
+- smartagentctl がインストールされたコントロールノード
+- すべてのリモートホストへの SSH アクセス
+- 認証用に設定された SSH 秘密鍵
+- コントロールノードでの sudo 権限
+- SSH が有効化されたリモートホスト
+- AppDynamics アカウントの認証情報
+
+## 利用可能なコマンド
+
+`smartagentctl` ツールは以下のリモート操作をサポートしています。
+
+- `start --remote` - リモートホストに Smart Agent をインストールして開始
+- `stop --remote` - リモートホストで Smart Agent を停止
+- `status --remote` - リモートホストで Smart Agent のステータスを確認
+- `install --remote` - 開始せずに Smart Agent をインストール
+- `uninstall --remote` - リモートホストから Smart Agent を削除
+- `--service` フラグ - systemd サービスとしてインストール
+
+すべてのコマンドで詳細ログ用の `--verbose` フラグがサポートされています。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md
new file mode 100644
index 0000000000..36af7fb6a2
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md
@@ -0,0 +1,306 @@
+---
+title: アーキテクチャと設計
+weight: 1
+time: 5 minutes
+---
+
+## システムアーキテクチャ
+
+Jenkins ベースの Smart Agent デプロイメントシステムは、ハブアンドスポーク型のアーキテクチャを採用しており、AWS VPC 内の Jenkins agent が SSH 経由で複数のターゲットホストへのデプロイメントをオーケストレーションします。
+
+### ハイレベルアーキテクチャ
+
+```mermaid
+graph TB
+ subgraph "Jenkins Infrastructure"
+ JM[Jenkins Master
Web UI + Orchestration]
+ JA[Jenkins Agent
EC2 in VPC
Label: linux]
+ end
+
+ subgraph "AWS VPC - Private Network"
+ subgraph "Target EC2 Instances"
+ H1[Host 1
172.31.1.243]
+ H2[Host 2
172.31.1.48]
+ H3[Host 3
172.31.1.5]
+ HN[Host N
172.31.x.x]
+ end
+ end
+
+ DEV[Developer/Operator]
+ APPD[AppDynamics
Controller]
+
+ DEV -->|1. Triggers Pipeline| JM
+ JM -->|2. Assigns Job| JA
+ JA -->|3. SSH Deploy
Private IPs| H1
+ JA -->|3. SSH Deploy
Private IPs| H2
+ JA -->|3. SSH Deploy
Private IPs| H3
+ JA -->|3. SSH Deploy
Private IPs| HN
+
+ H1 -.->|Metrics| APPD
+ H2 -.->|Metrics| APPD
+ H3 -.->|Metrics| APPD
+ HN -.->|Metrics| APPD
+
+ style JM fill:#d4e6f1
+ style JA fill:#a9cce3
+ style H1 fill:#aed6f1
+ style H2 fill:#aed6f1
+ style H3 fill:#aed6f1
+ style HN fill:#aed6f1
+```
+
+## ネットワークアーキテクチャ
+
+すべてのインフラストラクチャは、共有のセキュリティグループを持つ単一の AWS VPC 内で稼働します。Jenkins agent はプライベート IP を介してターゲットホストと通信するため、ターゲットホストにパブリック IP アドレスを割り当てる必要はありません。
+
+### VPC レイアウト
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ AWS VPC (10.0.0.0/16) │
+│ ┌───────────────────────────────────────────────────────────┐ │
+│ │ Security Group: app-agents-sg │ │
+│ │ Rules: │ │
+│ │ - Inbound: SSH (22) from Jenkins Agent only │ │
+│ │ - Outbound: HTTPS (443) to AppDynamics Controller │ │
+│ └───────────────────────────────────────────────────────────┘ │
+│ │
+│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
+│ │ Jenkins Agent│ │ Target EC2 │ │ Target EC2 │ │
+│ │ │ │ │ │ │ │
+│ │ Private IP: │───▶│ Private IP: │ │ Private IP: │ │
+│ │ 172.31.50.10 │SSH │ 172.31.1.243 │ │ 172.31.1.48 │ │
+│ │ │───▶│ │ │ │ │
+│ │ Label: linux │ │ Ubuntu 20.04 │ │ Ubuntu 20.04 │ │
+│ └──────────────┘ └──────────────┘ └──────────────┘ │
+│ │ │ │ │
+│ │ │ │ │
+│ └────────────────────┴────────────────────┘ │
+│ │ │
+└──────────────────────────────┼──────────────────────────────────┘
+ │
+ ▼
+ ┌──────────────────┐
+ │ AppDynamics │
+ │ Controller │
+ │ (SaaS/On-Prem) │
+ └──────────────────┘
+```
+
+## デプロイメントフロー
+
+### デプロイメントの全体シーケンス
+
+```mermaid
+sequenceDiagram
+ participant Dev as Developer
+ participant JM as Jenkins Master
+ participant JA as Jenkins Agent
(VPC)
+ participant TH as Target Hosts
(VPC)
+ participant AppD as AppDynamics
Controller
+
+ Dev->>JM: 1. Trigger Pipeline
+ JM->>JM: 2. Load Credentials
+ JM->>JA: 3. Schedule Job
+ JA->>JA: 4. Prepare Batches
+
+ loop For Each Batch
+ JA->>TH: 5. SSH Copy Files (SCP)
+ JA->>TH: 6. SSH Execute Commands
+ TH->>TH: 7. Install/Config Agent
+ TH-->>JA: 8. Return Status
+ end
+
+ JA->>JM: 9. Report Results
+ JM->>Dev: 10. Show Build Status
+
+ TH->>AppD: 11. Send Metrics (Post-Install)
+ AppD-->>Dev: 12. View Monitoring Data
+```
+
+## コンポーネントの詳細
+
+### Jenkins Master
+
+**役割:**
+
+- ユーザー向け Web UI
+- パイプラインのオーケストレーション
+- 認証情報の管理
+- ビルド履歴とログ
+- ジョブのスケジューリング
+
+**要件:**
+
+- Jenkins 2.300+
+- プラグイン: Pipeline、SSH Agent、Credentials、Git
+- agent へのネットワークアクセス
+
+### Jenkins Agent
+
+**配置場所:**
+
+- AWS VPC（ターゲットと同一の VPC）
+- プライベートネットワークアクセス
+
+**役割:**
+
+- パイプラインステージの実行
+- ターゲットホストへの SSH 接続
+- ファイル転送 (SCP)
+- バッチ処理ロジック
+- エラーの収集
+
+**要件:**
+
+- ラベル: `linux`
+- Java 11+
+- SSH クライアント
+- ネットワーク: すべてのターゲットへの SSH 接続
+- ディスク: アーティファクト用に約 20GB
+
+### ターゲットホスト
+
+**前提条件:**
+
+- Ubuntu 20.04+
+- SSH サーバーが稼働していること
+- sudo 権限を持つユーザー
+- 認可された SSH キー
+
+**デプロイメント後:**
+
+```
+/opt/appdynamics/
+└── appdsmartagent/
+ ├── smartagentctl
+ ├── config.ini
+ └── agents/
+ ├── machine/
+ ├── java/
+ ├── node/
+ └── db/
+```
+
+## セキュリティアーキテクチャ
+
+### セキュリティレイヤー
+
+1. **AWS VPC による分離**
+ - agent 用のプライベートサブネット
+ - インターネットへの直接アクセスは不要
+ - VPC フローログを有効化
+
+2. **セキュリティグループ**
+ - Jenkins Agent の IP をホワイトリスト登録
+ - ポート 22 (SSH) のみを許可
+ - ステートフルなファイアウォールルール
+
+3. **SSH キー認証**
+ - パスワード認証は使用しない
+ - キーは Jenkins credentials に保管
+ - 一時的なキーファイル (600 パーミッション)
+ - 各ビルド完了後にキーを削除
+
+4. **Jenkins RBAC**
+ - ロールベースのアクセス制御
+ - パイプラインレベルの権限管理
+ - 認証情報へのアクセス制限
+ - 監査ログを有効化
+
+5. **シークレット管理**
+ - コードやログにシークレットを含めない
+ - Credentials binding のみを使用
+ - 環境変数のマスキング
+ - シークレットの自動ローテーション (オプション)
+
+### 認証情報のフロー
+
+```mermaid
+flowchart LR
+ subgraph "Jenkins Master"
+ CS[Credentials Store
Encrypted at Rest]
+ JM[Jenkins Master]
+ end
+
+ subgraph "Jenkins Agent"
+ WS[Workspace
Temp Files]
+ KEY[SSH Key File
600 permissions]
+ end
+
+ subgraph "Target Hosts"
+ TH[EC2 Instances
Authorized Keys]
+ end
+
+ CS -->|Binding| JM
+ JM -->|Secure Copy| KEY
+ KEY -->|SSH Auth| TH
+ WS -.->|Cleanup| X[Deleted]
+ KEY -.->|Cleanup| X
+
+ style CS fill:#fdeaa8
+ style KEY fill:#fadbd8
+ style X fill:#e8e8e8
+```
+
+## バッチ処理
+
+このシステムは、あらゆる規模のデプロイメントに対応するため自動バッチ処理を採用しています。デフォルトでは、ホストは 256 台ずつのバッチで処理され、各バッチ内のすべてのホストは並列にデプロイされます。
+
+### バッチ処理の仕組み
+
+```
+HOST LIST (1000 hosts) BATCH_SIZE = 256
+
+Host 001: 172.31.1.1 ┌──────────────────┐
+Host 002: 172.31.1.2 ────────▶ │ BATCH 1 │
+ ... │ Hosts 1-256 │ ───┐
+Host 256: 172.31.1.256 │ Sequential │ │
+ └──────────────────┘ │
+Host 257: 172.31.1.257 ┌──────────────────┐ │
+Host 258: 172.31.1.258 ────────▶ │ BATCH 2 │ │ SEQUENTIAL
+ ... │ Hosts 257-512 │ │ EXECUTION
+Host 512: 172.31.1.512 │ Sequential │ │
+ └──────────────────┘ │
+Host 513: 172.31.1.513 ┌──────────────────┐ │
+ ... │ BATCH 3 │ │
+Host 768: 172.31.1.768 ────────▶ │ Hosts 513-768 │ ───┘
+ └──────────────────┘
+Host 769: 172.31.1.769 ┌──────────────────┐
+ ... │ BATCH 4 │
+Host 1000: 172.31.2.232 ────────▶ │ Hosts 769-1000 │
+ │ (232 hosts) │
+ └──────────────────┘
+
+WITHIN EACH BATCH:
+┌────────────────────────────────────────┐
+│ All hosts deploy in PARALLEL │
+│ │
+│ Host 1 ──┐ │
+│ Host 2 ──┤ │
+│ Host 3 ──┼─▶ Background processes (&)│
+│ ... │ │
+│ Host 256─┘ └─▶ wait command │
+└────────────────────────────────────────┘
+```
+
+### スケーリング特性
+
+**デプロイメント速度 (デフォルト BATCH_SIZE=256):**
+
+- 10 ホスト → 1 バッチ → 約 2 分
+- 100 ホスト → 1 バッチ → 約 3 分
+- 500 ホスト → 2 バッチ → 約 6 分
+- 1,000 ホスト → 4 バッチ → 約 12 分
+- 5,000 ホスト → 20 バッチ → 約 60 分
+
+**速度に影響する要因:**
+
+- ネットワーク帯域幅 (ホスト 1 台あたり 19MB のパッケージ)
+- SSH 接続のオーバーヘッド (ホスト 1 台あたり約 1 秒)
+- ターゲットホストの CPU とディスク速度
+- Jenkins agent のリソース
+
+## 次のステップ
+
+アーキテクチャの理解が得られたら、次は Jenkins のセットアップと認証情報の構成に進みます。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md
new file mode 100644
index 0000000000..9068609867
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md
@@ -0,0 +1,294 @@
+---
+title: Jenkins セットアップ
+weight: 2
+time: 10 minutes
+---
+
+## 前提条件
+
+開始する前に、以下が揃っていることを確認してください。
+
+- Jenkins サーバー（バージョン 2.300 以降）
+- ターゲット EC2 インスタンスと同じ AWS VPC 内にある Jenkins エージェント
+- ターゲットホストへの認証用 SSH キーペア
+- AppDynamics Smart Agent パッケージ
+- SSH アクセス可能なターゲット Ubuntu EC2 インスタンス
+
+## 必要な Jenkins プラグイン
+
+**Manage Jenkins → Plugins → Available Plugins** から以下のプラグインをインストールします。
+
+1. **Pipeline**（コアプラグイン、通常はプリインストール済み）
+2. **SSH Agent Plugin**
+3. **Credentials Plugin**（通常はプリインストール済み）
+4. **Git Plugin**（SCM を使用する場合）
+
+インストール手順は次のとおりです。
+
+1. **Manage Jenkins → Plugins** に移動します
+2. **Available** タブをクリックします
+3. 各プラグインを検索します
+4. 選択して **Install** をクリックします
+
+## Jenkins エージェントの構成
+
+Jenkins エージェントは、プライベート IP 経由でターゲット EC2 インスタンスに到達できる必要があります。主に 2 つのオプションがあります。
+
+### オプション A: EC2 インスタンスをエージェントとして使用
+
+1. **EC2 インスタンスをターゲットホストと同じ VPC 内で起動** します
+
+2. **Java をインストール** します（Jenkins に必要）。
+
+ ```bash
+ sudo apt-get update
+ sudo apt-get install -y openjdk-11-jdk
+ ```
+
+3. **Jenkins にエージェントを追加** します。
+ - **Manage Jenkins → Nodes → New Node** に移動します
+ - Name: `aws-vpc-agent`（または任意の名前）
+ - Type: **Permanent Agent**
+ - 設定:
+ - **Remote root directory**: `/home/ubuntu/jenkins`
+ - **Labels**: `linux`（パイプラインのエージェントラベルと一致させる必要があります）
+ - **Launch method**: Launch agent via SSH
+ - **Host**: EC2 のプライベート IP
+ - **Credentials**: エージェント用の SSH 認証情報を追加します
+
+### オプション B: 既存の Linux エージェントを使用
+
+- エージェントに `linux` ラベルが付いていることを確認します
+- ターゲットホストへのネットワーク接続を確認します
+- SSH クライアントがインストールされていることを確認します
+
+### エージェントラベルの構成
+
+{{% notice style="warning" %}}
+このワークショップのすべてのパイプラインは `linux` ラベルを使用します。エージェントがこのラベルで構成されていることを確認してください。
+{{% /notice %}}
+
+ラベルを設定または変更するには、次の手順に従います。
+
+1. **Manage Jenkins → Nodes** に移動します
+2. エージェントをクリックします
+3. **Configure** をクリックします
+4. **Labels** を `linux` に設定します
+5. **Save** をクリックします
+
+## 認証情報のセットアップ
+
+**Manage Jenkins → Credentials → System → Global credentials (unrestricted)** に移動します。
+
+パイプラインを動作させるために、3 つの認証情報を作成する必要があります。
+
+### 1. ターゲットホスト用の SSH 秘密鍵
+
+この認証情報により、Jenkins がターゲット EC2 インスタンスに SSH 接続できます。
+
+**Type**: SSH Username with private key
+
+- **ID**: `ssh-private-key`（完全に一致する必要があります）
+- **Description**: `SSH key for EC2 target hosts`
+- **Username**: `ubuntu`（または使用する SSH ユーザー）
+- **Private Key**: 次のいずれかを選択します:
+ - **Enter directly**: PEM ファイルの内容を貼り付けます
+ - **From file**: PEM ファイルをアップロードします
+ - **From Jenkins master**: パスを指定します
+
+**フォーマット例**:
+
+```
+-----BEGIN RSA PRIVATE KEY-----
+MIIEpAIBAAKCAQEA...
+...
+-----END RSA PRIVATE KEY-----
+```
+
+### 2. デプロイ先ホスト一覧
+
+この認証情報には、Smart Agent をデプロイするすべてのターゲットホストの一覧が含まれます。
+
+**Type**: Secret text
+
+- **ID**: `deployment-hosts`（完全に一致する必要があります）
+- **Description**: `List of target EC2 host IPs`
+- **Secret**: 改行区切りの IP を入力します
+
+**例**:
+
+```
+172.31.1.243
+172.31.1.48
+172.31.1.5
+172.31.10.20
+172.31.10.21
+```
+
+{{% notice style="important" %}}
+**フォーマット要件:**
+
+- 1 行に 1 つの IP
+- カンマなし
+- スペースなし
+- 余分な文字なし
+- Unix 形式の改行コードを使用（CRLF ではなく LF）
+{{% /notice %}}
+
+### 3. AppDynamics アカウントアクセスキー
+
+この認証情報には、Smart Agent 認証用の AppDynamics アカウントアクセスキーが含まれます。
+
+**Type**: Secret text
+
+- **ID**: `account-access-key`（完全に一致する必要があります）
+- **Description**: `AppDynamics account access key`
+- **Secret**: AppDynamics のアクセスキー
+
+**例**: `abcd1234-ef56-7890-gh12-ijklmnopqrst`
+
+{{% notice style="tip" %}}
+AppDynamics のアクセスキーは、Controller の **Settings → License → Account** で確認できます。
+{{% /notice %}}
+
+## 認証情報のセキュリティに関するベストプラクティス
+
+認証情報の管理にあたっては、以下のベストプラクティスに従ってください。
+
+- ✅ Jenkins の認証情報暗号化（組み込み機能）を使用する
+- ✅ Jenkins のロールベース認可によりアクセスを制限する
+- ✅ SSH キーを定期的にローテーションする
+- ✅ EC2 インスタンスには最小権限の IAM ロールを使用する
+- ✅ 認証情報アクセスの監査ログを有効化する
+- ✅ 認証情報をバージョン管理にコミットしない
+
+## Smart Agent パッケージのセットアップ
+
+Smart Agent の ZIP ファイルは、Jenkins からアクセス可能な場所に配置する必要があります。推奨されるアプローチは、Jenkins ホームディレクトリに保存することです。
+
+### Smart Agent のダウンロード
+
+```bash
+# Download from AppDynamics
+curl -o appdsmartagent_64_linux.zip \
+ "https://download.appdynamics.com/download/prox/download-file/smart-agent/latest/appdsmartagent_64_linux.zip"
+
+# Verify the download
+ls -lh appdsmartagent_64_linux.zip
+```
+
+### 保存場所
+
+パイプラインは、Smart Agent の ZIP を `/var/jenkins_home/smartagent/appdsmartagent.zip` で参照します。
+
+次のいずれかを選択できます。
+
+1. ZIP をこの正確な場所に配置する
+2. `SMARTAGENT_ZIP_PATH` パイプラインパラメーターを変更して、ZIP の場所を指定する
+
+## 構成の検証
+
+パイプラインの作成に進む前に、セットアップを検証します。
+
+### 1. エージェントのステータス確認
+
+1. **Manage Jenkins → Nodes** に移動します
+2. エージェントが「online」と表示されていることを確認します
+3. ラベルが `linux` に設定されていることを確認します
+
+### 2. SSH 接続のテスト
+
+SSH が動作することを確認するために、シンプルなテストパイプラインを作成します。
+
+```groovy
+pipeline {
+ agent { label 'linux' }
+ stages {
+ stage('Test SSH') {
+ steps {
+ withCredentials([
+ sshUserPrivateKey(credentialsId: 'ssh-private-key',
+ keyFileVariable: 'SSH_KEY',
+ usernameVariable: 'SSH_USER'),
+ string(credentialsId: 'deployment-hosts', variable: 'HOSTS')
+ ]) {
+ sh '''
+ echo "Testing SSH credentials..."
+ echo "$HOSTS" | head -1 | while read HOST; do
+ ssh -i $SSH_KEY \
+ -o StrictHostKeyChecking=no \
+ -o ConnectTimeout=10 \
+ $SSH_USER@$HOST \
+ "echo 'Connection successful'"
+ done
+ '''
+ }
+ }
+ }
+ }
+}
+```
+
+### 3. 認証情報の存在確認
+
+1. **Manage Jenkins → Credentials** に移動します
+2. 3 つの認証情報がすべてリストされていることを確認します:
+ - `ssh-private-key`
+ - `deployment-hosts`
+ - `account-access-key`
+
+## よくある問題のトラブルシューティング
+
+### エージェントが利用できない
+
+**症状**: パイプライン実行時に「No agent available」エラーが表示される
+
+**解決策**:
+
+- **Manage Jenkins → Nodes** を確認します
+- エージェントがオンラインであることを確認します
+- エージェントに `linux` ラベルが付いていることを確認します
+- エージェントの接続性をテストします
+
+### SSH 接続の失敗
+
+**症状**: SSH 経由でターゲットホストに接続できない
+
+**解決策**:
+
+```bash
+# Test from Jenkins agent machine
+ssh -i /path/to/key ubuntu@172.31.1.243 -o ConnectTimeout=10
+
+# Check security group allows SSH from agent
+# Verify private key matches public key on target
+```
+
+### 認証情報が見つからない
+
+**症状**: 「Credential not found」エラーが表示される
+
+**解決策**:
+
+- 認証情報の ID が完全に一致することを確認します:
+ - `ssh-private-key`
+ - `deployment-hosts`
+ - `account-access-key`
+- 認証情報のスコープが **Global** に設定されていることを確認します
+
+### ターゲットホストでのパーミッション拒否
+
+**症状**: SSH は成功するが、コマンドが permission denied で失敗する
+
+**解決策**:
+
+```bash
+# On target host, verify user is in sudoers
+sudo visudo
+# Add line:
+ubuntu ALL=(ALL) NOPASSWD: ALL
+```
+
+## 次のステップ
+
+これで Jenkins に認証情報とエージェントが構成されたので、デプロイパイプラインを作成する準備が整いました。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md
new file mode 100644
index 0000000000..81ce8ff634
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md
@@ -0,0 +1,268 @@
+---
+title: パイプラインの作成
+weight: 3
+time: 10 minutes
+---
+
+## 概要
+
+GitHubリポジトリには、Smart Agentのライフサイクルを管理するための4つの主要なパイプラインが含まれています。
+
+1. **Deploy Smart Agent** - Smart Agentサービスのインストールと起動
+2. **Install Machine Agent** - smartagentctl経由でMachine Agentをインストール
+3. **Install Database Agent** - smartagentctl経由でDatabase Agentをインストール
+4. **Cleanup All Agents** - /opt/appdynamicsディレクトリを削除
+
+すべてのパイプラインコードは、[sm-jenkins GitHubリポジトリ](https://github.com/chambear2809/sm-jenkins)で入手できます。
+
+## パイプラインファイル
+
+リポジトリには、以下のJenkinsfileパイプライン定義が含まれています。
+
+```
+sm-jenkins/
+└── pipelines/
+ ├── Jenkinsfile.deploy # Deploy Smart Agent
+ ├── Jenkinsfile.install-machine-agent # Install Machine Agent
+ ├── Jenkinsfile.install-db-agent # Install Database Agent
+ └── Jenkinsfile.cleanup # Cleanup All Agents
+```
+
+## Jenkinsでのパイプライン作成
+
+使用したい各Jenkinsfileについて、以下の手順に従ってJenkinsでパイプラインを作成します。
+
+### 方法1: SCMからのパイプライン（推奨）
+
+この方法では、パイプラインコードをバージョン管理下に保ち、変更を自動的に同期します。
+
+#### ステップ1: リポジトリのフォークまたはクローン
+
+まず、リポジトリを自身のGitHubアカウントまたは組織にフォークするか、元のリポジトリを直接使用します。
+
+**Repository URL**: `https://github.com/chambear2809/sm-jenkins`
+
+#### ステップ2: Jenkinsでパイプラインを作成
+
+1. **Jenkins Dashboard** に移動します
+2. **New Item** をクリックします
+3. アイテム名を入力します（例: `Deploy-Smart-Agent`）
+4. **Pipeline** を選択します
+5. **OK** をクリックします
+
+#### ステップ3: パイプラインの構成
+
+パイプラインの構成ページで以下を設定します。
+
+**General Section:**
+
+- **Description**: `Deploys AppDynamics Smart Agent to multiple hosts`
+- **Discard old builds** はチェックを外したままにします（または必要に応じて設定）
+
+**Build Triggers:**
+
+- 手動実行のみとする場合はチェックを外したままにします
+- 必要に応じてwebhookやポーリングを構成します
+
+**Pipeline Section:**
+
+- **Definition**: `Pipeline script from SCM` を選択します
+- **SCM**: `Git` を選択します
+- **Repository URL**: `https://github.com/chambear2809/sm-jenkins`
+- **Credentials**: プライベートリポジトリを使用する場合は追加します
+- **Branch Specifier**: `*/main`（または `*/master`）
+- **Script Path**: `pipelines/Jenkinsfile.deploy`
+
+#### ステップ4: 保存
+
+**Save** をクリックしてパイプラインを作成します。
+
+#### ステップ5: 他のパイプラインに対しても繰り返し
+
+作成したい各パイプラインに対して、適切なスクリプトパスを使用してステップ2〜4を繰り返します。
+
+| Pipeline Name | Script Path |
+|---------------|-------------|
+| Deploy-Smart-Agent | `pipelines/Jenkinsfile.deploy` |
+| Install-Machine-Agent | `pipelines/Jenkinsfile.install-machine-agent` |
+| Install-Database-Agent | `pipelines/Jenkinsfile.install-db-agent` |
+| Cleanup-All-Agents | `pipelines/Jenkinsfile.cleanup` |
+
+### 方法2: 直接パイプラインスクリプト
+
+代わりに、Jenkinsfileの内容を直接Jenkinsにコピーすることもできます。
+
+1. **Create New Item**（方法1と同じ）
+2. **Pipeline** セクションで以下を設定します:
+ - **Definition**: `Pipeline script` を選択します
+ - **Script**: GitHubから Jenkinsfile の内容全体をコピー＆ペーストします
+3. **Save**
+
+{{% notice style="tip" %}}
+方法1（SCM）は、パイプラインをバージョン管理下に保ち、更新を容易にするため推奨されます。
+{{% /notice %}}
+
+## パイプラインパラメーター
+
+各パイプラインは構成可能なパラメーターを受け取ります。メインのデプロイメントパイプラインの主要なパラメーターは以下のとおりです。
+
+### Deploy Smart Agent パイプラインのパラメーター
+
+| Parameter | Default | Description |
+|-----------|---------|-------------|
+| `SMARTAGENT_ZIP_PATH` | `/var/jenkins_home/smartagent/appdsmartagent.zip` | JenkinsサーバーのSmart Agent ZIPへのパス |
+| `REMOTE_INSTALL_DIR` | `/opt/appdynamics/appdsmartagent` | ターゲットホストのインストールディレクトリ |
+| `APPD_USER` | `ubuntu` | Smart Agentプロセスを実行するユーザー |
+| `APPD_GROUP` | `ubuntu` | Smart Agentプロセスを実行するグループ |
+| `SSH_PORT` | `22` | リモートホスト用のSSHポート |
+| `AGENT_NAME` | `smartagent` | Smart Agentの名前 |
+| `LOG_LEVEL` | `DEBUG` | ログレベル（DEBUG、INFO、WARN、ERROR） |
+
+### Cleanup パイプラインのパラメーター
+
+| Parameter | Default | Description |
+|-----------|---------|-------------|
+| `REMOTE_INSTALL_DIR` | `/opt/appdynamics/appdsmartagent` | 削除するディレクトリ |
+| `SSH_PORT` | `22` | リモートホスト用のSSHポート |
+| `CONFIRM_CLEANUP` | `false` | クリーンアップを進めるためにチェックする必要があります |
+
+{{% notice style="warning" %}}
+クリーンアップパイプラインには、誤った削除を防ぐための確認パラメーターが含まれています。クリーンアップを実行するには、`CONFIRM_CLEANUP` をチェックする必要があります。
+{{% /notice %}}
+
+## パイプライン構造の理解
+
+デプロイメントパイプラインの主要なコンポーネントを確認してみましょう。
+
+### 1. Agent宣言
+
+```groovy
+agent { label 'linux' }
+```
+
+これにより、`linux` ラベルを持つJenkinsエージェント上でパイプラインが実行されることが保証されます。
+
+### 2. Parametersブロック
+
+```groovy
+parameters {
+ string(name: 'SMARTAGENT_ZIP_PATH', ...)
+ string(name: 'REMOTE_INSTALL_DIR', ...)
+ // ... more parameters
+}
+```
+
+ビルドのトリガー時に設定可能な構成パラメーターを定義します。
+
+### 3. Stages
+
+デプロイメントパイプラインには、以下のステージがあります。
+
+1. **Preparation** - 認証情報からターゲットホストを読み込みます
+2. **Extract Smart Agent** - ZIPファイルをステージングディレクトリに展開します
+3. **Configure Smart Agent** - config.iniテンプレートを作成します
+4. **Deploy to Remote Hosts** - 各ホストにファイルをコピーし、Smart Agentを起動します
+5. **Verify Installation** - 全ホストでSmart Agentのステータスを確認します
+
+### 4. Credentialsバインディング
+
+```groovy
+withCredentials([
+ sshUserPrivateKey(credentialsId: 'ssh-private-key', ...),
+ string(credentialsId: 'account-access-key', ...)
+]) {
+ // Pipeline code with access to credentials
+}
+```
+
+ログに認証情報を露出させることなく、安全に認証情報を読み込みます。
+
+### 5. Post Actions
+
+```groovy
+post {
+ success { ... }
+ failure { ... }
+ always { ... }
+}
+```
+
+成功・失敗に関わらず、パイプライン完了後に実行するアクションを定義します。
+
+## パイプラインの命名規則
+
+明確さと整理のために、一貫した命名規則を使用します。
+
+**推奨される名前:**
+
+```
+01-Deploy-Smart-Agent
+02-Install-Machine-Agent
+03-Install-Database-Agent
+04-Cleanup-All-Agents
+```
+
+数値プレフィックスは、Jenkinsダッシュボードでの論理的な順序を維持するのに役立ちます。
+
+## フォルダーによるパイプラインの整理
+
+より良い整理のために、Jenkinsフォルダーを使用できます。
+
+1. **フォルダーの作成**:
+ - **New Item** をクリックします
+ - 名前を入力します: `AppDynamics Smart Agent`
+ - **Folder** を選択します
+ - **OK** をクリックします
+
+2. **フォルダー内にパイプラインを作成**:
+ - フォルダーに入ります
+ - 上記の手順に従ってパイプラインを作成します
+
+**構造の例:**
+
+```
+AppDynamics Smart Agent/
+├── Deployment/
+│ └── 01-Deploy-Smart-Agent
+├── Agent Installation/
+│ ├── 02-Install-Machine-Agent
+│ └── 03-Install-Database-Agent
+└── Cleanup/
+ └── 04-Cleanup-All-Agents
+```
+
+## パイプラインコードの参照
+
+GitHubリポジトリで、完全なパイプラインコードを参照できます。
+
+**メインのデプロイメントパイプライン:**
+[https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.deploy](https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.deploy)
+
+**その他のパイプライン:**
+
+- [Jenkinsfile.install-machine-agent](https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.install-machine-agent)
+- [Jenkinsfile.install-db-agent](https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.install-db-agent)
+- [Jenkinsfile.cleanup](https://github.com/chambear2809/sm-jenkins/blob/main/pipelines/Jenkinsfile.cleanup)
+
+## パイプライン構成のテスト
+
+完全なデプロイメントを実行する前に、パイプライン構成をテストします。
+
+### 1. 単一ホストでのドライラン
+
+1. 1つのIPのみを持つテスト認証情報 `deployment-hosts-test` を作成します
+2. パイプラインを一時的に変更して、この認証情報を使用するようにします
+3. パイプラインを実行し、単一ホストで動作することを確認します
+4. 確認できたら、完全なホストリストを使用するように更新します
+
+### 2. 構文チェック
+
+Jenkinsには組み込みの構文バリデーターが提供されています。
+
+1. パイプラインに移動します
+2. **Pipeline Syntax** リンクをクリックします
+3. **Declarative Directive Generator** を使用して構文を検証します
+
+## 次のステップ
+
+パイプラインが作成できたので、最初のSmart Agentデプロイメントを実行する準備が整いました！
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md
new file mode 100644
index 0000000000..51e7ae6f5f
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md
@@ -0,0 +1,366 @@
+---
+title: デプロイメントワークフロー
+weight: 4
+time: 15 minutes
+---
+
+## 初回デプロイメント
+
+パイプラインの設定が完了したので、初めての Smart Agent デプロイメントを実行する手順を説明します。
+
+### Step 1: パイプラインへ移動する
+
+1. **Jenkins Dashboard** に移動します
+2. **Deploy-Smart-Agent** パイプラインをクリックします
+
+### Step 2: パラメーター付きでビルドする
+
+1. 左サイドバーの **Build with Parameters** をクリックします
+2. デフォルトパラメーターを確認します:
+ - **SMARTAGENT_ZIP_PATH**: パスが正しいか確認します
+ - **REMOTE_INSTALL_DIR**: `/opt/appdynamics/appdsmartagent`
+ - **APPD_USER**: `ubuntu` (または使用している SSH ユーザー)
+ - **APPD_GROUP**: `ubuntu`
+ - **SSH_PORT**: `22`
+ - **AGENT_NAME**: `smartagent`
+ - **LOG_LEVEL**: `DEBUG`
+
+3. 必要に応じてパラメーターを調整します
+4. **Build** をクリックします
+
+{{% notice style="tip" %}}
+初回デプロイメントでは、IP アドレスを1つだけ記載した別の認証情報を作成し、単一ホストでテストすることを検討してください。
+{{% /notice %}}
+
+### Step 3: パイプライン実行を監視する
+
+**Build** をクリックすると、以下が表示されます:
+
+1. **Build added to queue** - Build History にビルド番号が表示されます
+2. **ビルド番号をクリック** (例: #1) して詳細を表示します
+3. **Console Output をクリック** してリアルタイムのログを表示します
+
+### Step 4: コンソール出力を理解する
+
+コンソール出力にはデプロイメントの各ステージが表示されます:
+
+```
+Started by user admin
+Running in Durability level: MAX_SURVIVABILITY
+[Pipeline] Start of Pipeline
+[Pipeline] node
+Running on aws-vpc-agent in /home/ubuntu/jenkins/workspace/Deploy-Smart-Agent
+[Pipeline] {
+[Pipeline] stage
+[Pipeline] { (Preparation)
+[Pipeline] script
+[Pipeline] {
+Preparing Smart Agent deployment to 3 hosts: 172.31.1.243, 172.31.1.48, 172.31.1.5
+...
+```
+
+表示される主なステージ:
+
+1. ✅ **Preparation** - ホストリストを読み込み、検証します
+2. ✅ **Extract Smart Agent** - ZIP ファイルを展開します
+3. ✅ **Configure Smart Agent** - config.ini を作成します
+4. ✅ **Deploy to Remote Hosts** - 各ホストへデプロイします
+5. ✅ **Verify Installation** - Smart Agent のステータスを確認します
+
+### Step 5: 結果を確認する
+
+完了後、以下が表示されます:
+
+**成功:**
+
+```
+Smart Agent successfully deployed to all hosts
+Finished: SUCCESS
+```
+
+**部分的な成功:**
+
+```
+Deployment completed with some failures
+Failed hosts: 172.31.1.48
+Finished: UNSTABLE
+```
+
+**失敗:**
+
+```
+Smart Agent deployment failed. Check logs for details.
+Finished: FAILURE
+```
+
+## インストールの検証
+
+デプロイメントが成功したら、対象ホストで Smart Agent が稼働していることを検証します。
+
+### Smart Agent ステータスの確認
+
+対象ホストへ SSH 接続し、ステータスを確認します:
+
+```bash
+# SSH to target host
+ssh ubuntu@172.31.1.243
+
+# Navigate to installation directory
+cd /opt/appdynamics/appdsmartagent
+
+# Check Smart Agent status
+sudo ./smartagentctl status
+```
+
+**期待される出力:**
+
+```
+Smart Agent is running (PID: 12345)
+Service: appdsmartagent.service
+Status: active (running)
+```
+
+### インストール済みエージェントの一覧表示
+
+```bash
+cd /opt/appdynamics/appdsmartagent
+sudo ./smartagentctl list
+```
+
+**期待される出力:**
+
+```
+No agents currently installed
+(Use install-machine-agent or install-db-agent pipelines to add agents)
+```
+
+### ログの確認
+
+```bash
+cd /opt/appdynamics/appdsmartagent
+tail -f log.log
+```
+
+AppDynamics コントローラーへの接続成功メッセージを確認します。
+
+### AppDynamics Controller での検証
+
+1. AppDynamics Controller にログインします
+2. **Servers → Servers** に移動します
+3. 新しくデプロイされたホストを探します
+4. Smart Agent がメトリクスを送信していることを確認します
+
+## 追加エージェントのインストール
+
+Smart Agent がデプロイされたら、他のパイプラインを使用して特定のエージェントタイプをインストールできます。
+
+### Machine Agent のインストール
+
+1. **Install-Machine-Agent** パイプラインへ移動します
+2. **Build with Parameters** をクリックします
+3. パラメーターを確認します:
+ - **AGENT_NAME**: `machine-agent`
+ - **SSH_PORT**: `22`
+4. **Build** をクリックします
+
+パイプラインは各ホストへ SSH 接続し、以下を実行します:
+
+```bash
+cd /opt/appdynamics/appdsmartagent
+sudo ./smartagentctl install --component machine
+```
+
+### Database Agent のインストール
+
+1. **Install-Database-Agent** パイプラインへ移動します
+2. **Build with Parameters** をクリックします
+3. データベース接続パラメーターを設定します
+4. **Build** をクリックします
+
+パイプラインは全ホストに Database Agent をインストールおよび設定します。
+
+### エージェントインストールの検証
+
+エージェントをインストール後、表示されることを検証します:
+
+```bash
+cd /opt/appdynamics/appdsmartagent
+sudo ./smartagentctl list
+```
+
+**期待される出力:**
+
+```
+Installed agents:
+- machine-agent (running)
+- db-agent (running)
+```
+
+## 一般的なデプロイメントシナリオ
+
+### シナリオ 1: 初回デプロイメント
+
+**ワークフロー:**
+
+1. **Deploy-Smart-Agent** パイプラインを実行します
+2. 完了を待ち、検証します
+3. 必要に応じて **Install-Machine-Agent** を実行します
+4. 必要に応じて **Install-Database-Agent** を実行します
+
+### シナリオ 2: Smart Agent の更新
+
+Smart Agent を新しいバージョンに更新する場合:
+
+1. 新しい Smart Agent ZIP をダウンロードします
+2. 設定済みのパスで Jenkins に配置します
+3. **Deploy-Smart-Agent** パイプラインを再度実行します
+
+パイプラインは自動的に以下を実行します:
+
+- 既存の Smart Agent を停止する
+- 古いファイルを削除する
+- 新しいバージョンをインストールする
+- Smart Agent を再起動する
+
+### シナリオ 3: 新規ホストの追加
+
+新しいホストに Smart Agent を追加する場合:
+
+1. Jenkins の `deployment-hosts` 認証情報を更新します
+2. 新しい IP アドレスを追加します (1 行に 1 つ)
+3. **Deploy-Smart-Agent** パイプラインを実行します
+
+パイプラインは以下を実行します:
+
+- 設定済みのホストをスキップする (冪等な場合)
+- 新しいホストにのみデプロイする
+
+### シナリオ 4: 完全な削除
+
+全ホストから Smart Agent を完全に削除する場合:
+
+1. **Cleanup-All-Agents** パイプラインへ移動します
+2. **Build with Parameters** をクリックします
+3. `CONFIRM_CLEANUP` チェックボックスを **チェック** します
+4. **Build** をクリックします
+
+{{% notice style="danger" %}}
+これにより `/opt/appdynamics/appdsmartagent` ディレクトリが全ホストから完全に削除されます。この操作は取り消せません。
+{{% /notice %}}
+
+## デプロイメントのトラブルシューティング
+
+### Preparation ステージでビルドが失敗する
+
+**症状**: ホストリストの読み込み時にパイプラインが失敗します
+
+**原因**: `deployment-hosts` 認証情報が不足または不正です
+
+**解決策**:
+
+1. **Manage Jenkins → Credentials** へ移動します
+2. `deployment-hosts` 認証情報が存在することを確認します
+3. フォーマットを確認します (1 行に 1 IP、カンマなし)
+4. 末尾のスペースがないことを確認します
+
+### SSH 接続の失敗
+
+**症状**: "Permission denied" または "Connection refused" エラー
+
+**解決策**:
+
+**セキュリティグループの確認:**
+
+```bash
+# Verify Jenkins agent can reach target
+ping 172.31.1.243
+telnet 172.31.1.243 22
+```
+
+**SSH を手動でテスト:**
+
+```bash
+# From Jenkins agent machine
+ssh -i /path/to/key ubuntu@172.31.1.243
+```
+
+**SSH キーの検証:**
+
+1. `ssh-private-key` 認証情報が正しいことを確認します
+2. 公開キーが対象ホストの `~/.ssh/authorized_keys` にあることを確認します
+
+### Smart Agent が起動しない
+
+**症状**: デプロイメントは完了するが Smart Agent が稼働していません
+
+**解決策**:
+
+**対象ホストのログを確認:**
+
+```bash
+cd /opt/appdynamics/appdsmartagent
+cat log.log
+```
+
+**よくある問題:**
+
+- **アクセスキーが無効**: `account-access-key` 認証情報を確認します
+- **ネットワーク接続**: Controller への送信 HTTPS を確認します
+- **権限の問題**: APPD_USER に正しい権限があることを確認します
+
+### 部分的なデプロイメント成功
+
+**症状**: 一部のホストは成功し、他は失敗します
+
+**解決策**:
+
+1. **Console Output を確認** - どのホストが失敗したかを特定します
+2. **失敗したホストを調査** - SSH 接続して手動でテストします
+3. **パイプラインを再実行** - Jenkins は再試行が必要なホストを追跡します
+
+## パイプラインのベストプラクティス
+
+### 1. まず単一ホストでテストする
+
+新しい設定は、本番環境にデプロイする前に必ず単一ホストでテストします:
+
+```
+1. Create deployment-hosts-test credential (1 IP)
+2. Create test pipeline pointing to this credential
+3. Verify success
+4. Deploy to full host list
+```
+
+### 2. 説明的なビルド説明を使用する
+
+ビルドをトリガーした後、説明を追加します:
+
+1. ビルドページへ移動します
+2. **Edit Build Information** をクリックします
+3. 説明を追加します: "Production deployment - Q4 2024"
+
+### 3. ビルド履歴を監視する
+
+定期的にビルド履歴のパターンを確認します:
+
+- 失敗したビルド
+- 実行時間の傾向
+- エラーメッセージ
+
+### 4. メンテナンスウィンドウ中にデプロイメントをスケジュールする
+
+本番システムの場合:
+
+- Jenkins のスケジュールビルドを使用する
+- トラフィックの少ない時間帯にデプロイする
+- ロールバック計画を準備しておく
+
+### 5. 認証情報を最新に保つ
+
+- SSH キーを四半期ごとにローテーションする
+- インフラストラクチャの変更に応じてホストリストを更新する
+- AppDynamics アクセスキーの有効性を検証する
+
+## Next Steps
+
+次に、大規模デプロイメントに向けたスケーリングと運用上の考慮事項を見ていきます。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md
new file mode 100644
index 0000000000..580be6eb77
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md
@@ -0,0 +1,80 @@
+---
+title: Jenkins Automation
+weight: 2
+time: 2 minutes
+description: Jenkins パイプラインを使用して、複数のホストにまたがる AppDynamics Smart Agent のデプロイとライフサイクル管理を自動化する方法を学びます。
+---
+
+## はじめに
+
+このワークショップでは、**Jenkins** を使用して、複数の EC2 インスタンスにまたがる **AppDynamics Smart Agent** のデプロイとライフサイクル管理を自動化する方法を解説します。10 台のホストを管理する場合でも、10,000 台のホストを管理する場合でも、本ガイドではスケーラブルでセキュア、かつ再現性のある Smart Agent 運用のために Jenkins パイプラインを活用する方法を紹介します。
+
+ 
+
+## 学習内容
+
+このワークショップでは、以下の方法を学びます。
+
+- Jenkins を使って複数のホストへ **Smart Agent をデプロイ** する
+- セキュアな SSH および AppDynamics アクセスのために **Jenkins クレデンシャルを構成** する
+- 柔軟なデプロイシナリオに対応する **パラメータ化されたパイプラインを作成** する
+- 数千台のホストへスケールさせるために **バッチ処理を実装** する
+- インストール、構成、停止、クリーンアップなど **エージェントの完全なライフサイクルを管理** する
+- 自動的なエラー追跡とレポーティングにより **失敗を適切に処理** する
+
+## 主な特徴
+
+- 🚀 **並列デプロイ** - 複数のホストへ同時にデプロイ
+- 🔄 **完全なライフサイクル管理** - エージェントのインストール、アンインストール、停止、クリーンアップ
+- 🏗️ **Infrastructure as Code** - すべてのパイプラインをバージョン管理
+- 🔐 **セキュア** - Jenkins クレデンシャル経由の SSH 鍵ベース認証
+- 📈 **大規模にスケール可能** - 自動バッチ処理で数千台のホストへデプロイ
+- 🎛️ **Jenkins Agent** - AWS VPC 内で実行
+
+## アーキテクチャ概要
+
+```text
+┌─────────────────────────────────────────────────────────────────┐
+│ Jenkins-based Deployment │
+├─────────────────────────────────────────────────────────────────┤
+│ │
+│ Developer ──▶ Jenkins Master ──▶ Jenkins Agent (AWS VPC) │
+│ │ │
+│ ├──▶ Host 1 (SSH) │
+│ ├──▶ Host 2 (SSH) │
+│ ├──▶ Host 3 (SSH) │
+│ └──▶ Host N (SSH) │
+│ │
+│ All hosts send metrics ──▶ AppDynamics Controller │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+## ワークショップの構成
+
+このワークショップには以下が含まれます。
+
+1. **アーキテクチャと設計** - システム設計とネットワークトポロジーの理解
+2. **Jenkins のセットアップ** - Jenkins、クレデンシャル、エージェントの構成
+3. **パイプラインの作成** - デプロイパイプラインの作成と構成
+4. **デプロイワークフロー** - デプロイの実行とインストールの検証
+
+## 前提条件
+
+- Pipeline プラグインを備えた Jenkins サーバー（2.300 以降）
+- ターゲット EC2 インスタンスと同じ VPC 内にある Jenkins agent
+- 認証用の SSH 鍵ペア
+- AppDynamics Smart Agent パッケージ
+- SSH アクセス可能なターゲット Ubuntu EC2 インスタンス
+
+## GitHub リポジトリ
+
+すべてのパイプラインコードと構成ファイルは GitHub リポジトリで提供されています。
+
+**[https://github.com/chambear2809/sm-jenkins](https://github.com/chambear2809/sm-jenkins)**
+
+リポジトリには以下が含まれます。
+
+- 完全な Jenkinsfile パイプライン定義
+- 詳細なセットアップドキュメント
+- 構成例
+- トラブルシューティングガイド
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md
new file mode 100644
index 0000000000..5d8a79a332
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md
@@ -0,0 +1,312 @@
+---
+title: アーキテクチャと設計
+weight: 1
+time: 5 minutes
+---
+
+## システムアーキテクチャ
+
+GitHub Actions ベースの Smart Agent デプロイメントシステムは、AWS VPC 内のセルフホストランナーを使用して、SSH 経由で複数のターゲットホストへのデプロイメントを調整します。
+
+### 高レベルアーキテクチャ
+
+```mermaid
+graph TB
+ subgraph Internet
+ GH[GitHub.com
Repository & Actions]
+ User[Developer
Local Machine]
+ end
+
+ subgraph AWS["AWS VPC (172.31.0.0/16)"]
+ subgraph SG["Security Group: smartagent-lab"]
+ Runner[Self-hosted Runner
EC2 Instance
172.31.1.x]
+
+ subgraph Targets["Target Hosts"]
+ T1[Target Host 1
Ubuntu EC2
172.31.1.243]
+ T2[Target Host 2
Ubuntu EC2
172.31.1.48]
+ T3[Target Host 3
Ubuntu EC2
172.31.1.5]
+ end
+ end
+ end
+
+ User -->|git push| GH
+ GH <-->|HTTPS:443
Poll for jobs| Runner
+ Runner -->|SSH:22
Private IPs| T1
+ Runner -->|SSH:22
Private IPs| T2
+ Runner -->|SSH:22
Private IPs| T3
+
+ style GH fill:#24292e,color:#fff
+ style User fill:#0366d6,color:#fff
+ style Runner fill:#28a745,color:#fff
+ style T1 fill:#ffd33d,color:#000
+ style T2 fill:#ffd33d,color:#000
+ style T3 fill:#ffd33d,color:#000
+```
+
+## ネットワークアーキテクチャ
+
+すべてのインフラストラクチャは、共有のセキュリティグループを持つ単一の AWS VPC 上で稼働します。セルフホストランナーは、プライベート IP を介してターゲットホストと通信します。
+
+### VPC レイアウト
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ AWS VPC (172.31.0.0/16) │
+│ ┌───────────────────────────────────────────────────────────┐ │
+│ │ Security Group: smartagent-lab │ │
+│ │ Rules: │ │
+│ │ - Inbound: SSH (22) from same security group │ │
+│ │ - Outbound: HTTPS (443) to GitHub │ │
+│ └───────────────────────────────────────────────────────────┘ │
+│ │
+│ ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │
+│ │ Self-hosted │ │ Target EC2 │ │ Target EC2 │ │
+│ │ Runner │ │ │ │ │ │
+│ │ │───▶│ Private IP: │ │ Private IP: │ │
+│ │ 172.31.1.x │SSH │ 172.31.1.243 │ │ 172.31.1.48 │ │
+│ │ │───▶│ │ │ │ │
+│ │ Polls GitHub│ │ Ubuntu 20.04 │ │ Ubuntu 20.04 │ │
+│ └─────────────┘ └──────────────┘ └──────────────┘ │
+│ │ │ │ │
+│ │ │ │ │
+│ └────────────────────┴────────────────────┘ │
+│ │ │
+└──────────────────────────────┼──────────────────────────────────┘
+ │
+ ▼
+ ┌──────────────────┐
+ │ AppDynamics │
+ │ Controller │
+ │ (SaaS/On-Prem) │
+ └──────────────────┘
+```
+
+## ワークフロー実行フロー
+
+### 完全なデプロイメントシーケンス
+
+```mermaid
+sequenceDiagram
+ participant Dev as Developer
+ participant GH as GitHub
+ participant Runner as Self-hosted Runner
+ participant Target as Target Host(s)
+
+ Dev->>GH: 1. Push code or trigger workflow
+ GH->>GH: 2. Workflow event triggered
+ Runner->>GH: 3. Poll for jobs (HTTPS:443)
+ GH->>Runner: 4. Assign job to runner
+ Runner->>Runner: 5. Execute prepare job
(load host matrix)
+
+ par Parallel Execution
+ Runner->>Target: 6a. SSH to Host 1
(port 22)
+ Runner->>Target: 6b. SSH to Host 2
(port 22)
+ Runner->>Target: 6c. SSH to Host 3
(port 22)
+ end
+
+ Target->>Target: 7. Execute commands
(install/uninstall/stop/clean)
+ Target-->>Runner: 8. Return results
+ Runner-->>GH: 9. Report job status
+ GH-->>Dev: 10. Notify completion
+```
+
+## コンポーネントの詳細
+
+### GitHub リポジトリ
+
+**保管対象:**
+
+- 11 個のワークフロー YAML ファイル
+- Smart Agent インストールパッケージ
+- 設定ファイル (config.ini)
+
+**シークレット:**
+
+- SSH 秘密鍵
+
+**変数:**
+
+- ホストリスト (DEPLOYMENT_HOSTS)
+- ユーザー/グループ設定 (オプション)
+
+### セルフホストランナー
+
+**配置場所:**
+
+- AWS VPC (ターゲットと同じ)
+- プライベートネットワークアクセス
+
+**役割:**
+
+- GitHub のワークフロージョブをポーリング
+- ワークフローステップの実行
+- ターゲットホストへの SSH 接続
+- ファイル転送 (SCP)
+- 並列実行
+- エラー収集
+
+**要件:**
+
+- Ubuntu/Amazon Linux 2
+- GitHub への送信 HTTPS (443)
+- ターゲットホストへの送信 SSH (22)
+- SSH 鍵認証
+
+**アクセス:**
+
+- GitHub への送信 HTTPS (443)
+- ターゲットホストへの送信 SSH (22)
+- SSH 鍵認証を使用
+
+### ターゲットホスト
+
+**前提条件:**
+
+- Ubuntu 20.04 以上
+- SSH サーバーが稼働中
+- sudo 権限を持つユーザー
+- 認証済み SSH 鍵
+
+**デプロイ後:**
+
+```
+/opt/appdynamics/
+└── appdsmartagent/
+ ├── smartagentctl
+ ├── config.ini
+ └── agents/
+ ├── machine/
+ ├── java/
+ ├── node/
+ └── db/
+```
+
+## セキュリティアーキテクチャ
+
+### セキュリティレイヤー
+
+1. **AWS VPC の分離**
+ - ホスト用のプライベートサブネット
+ - インターネットへの直接アクセスは不要
+ - VPC フローログを有効化
+
+2. **セキュリティグループ**
+ - SSH (22) は同一セキュリティグループ内のみ
+ - GitHub アクセス用の送信 HTTPS (443)
+ - ステートフルなファイアウォールルール
+
+3. **SSH 鍵認証**
+ - パスワード認証なし
+ - 鍵は GitHub Secrets に保存
+ - ランナー上の一時的な鍵ファイル
+ - ワークフロー終了後に鍵を削除
+
+4. **GitHub のセキュリティ**
+ - リポジトリのアクセス制御
+ - ブランチ保護ルール
+ - シークレットがログに出力されることはない
+ - 環境変数のマスキング
+
+5. **ネットワークセキュリティ**
+ - プライベート IP 通信のみ
+ - パブリック IP は不要
+ - ランナーをターゲットと同一の VPC に配置
+
+## ワークフローのカテゴリ
+
+このシステムには、4 つのカテゴリに整理された 11 個のワークフローが含まれています。
+
+```
+GitHub Actions Workflows (11 Total)
+├── Deployment (1 workflow)
+│ └── Deploy Smart Agent (Batched)
+├── Agent Installation (4 workflows)
+│ ├── Install Node Agent (Batched)
+│ ├── Install Machine Agent (Batched)
+│ ├── Install DB Agent (Batched)
+│ └── Install Java Agent (Batched)
+├── Agent Uninstallation (4 workflows)
+│ ├── Uninstall Node Agent (Batched)
+│ ├── Uninstall Machine Agent (Batched)
+│ ├── Uninstall DB Agent (Batched)
+│ └── Uninstall Java Agent (Batched)
+└── Smart Agent Management (2 workflows)
+ ├── Stop and Clean Smart Agent (Batched)
+ └── Cleanup All Agents (Batched)
+```
+
+## バッチ処理戦略
+
+すべてのワークフローは、あらゆる規模のデプロイメントに対応するため、自動バッチ処理を採用しています。
+
+### バッチ処理の仕組み
+
+```
+HOST LIST (1000 hosts) BATCH_SIZE = 256
+
+Host 001: 172.31.1.1 ┌──────────────────┐
+Host 002: 172.31.1.2 ────────▶ │ BATCH 1 │
+ ... │ Hosts 1-256 │ ───┐
+Host 256: 172.31.1.256 │ Sequential │ │
+ └──────────────────┘ │
+Host 257: 172.31.1.257 ┌──────────────────┐ │
+Host 258: 172.31.1.258 ────────▶ │ BATCH 2 │ │ SEQUENTIAL
+ ... │ Hosts 257-512 │ │ EXECUTION
+Host 512: 172.31.1.512 │ Sequential │ │
+ └──────────────────┘ │
+Host 513: 172.31.1.513 ┌──────────────────┐ │
+ ... │ BATCH 3 │ │
+Host 768: 172.31.1.768 ────────▶ │ Hosts 513-768 │ ───┘
+ └──────────────────┘
+Host 769: 172.31.1.769 ┌──────────────────┐
+ ... │ BATCH 4 │
+Host 1000: 172.31.2.232 ────────▶ │ Hosts 769-1000 │
+ │ (232 hosts) │
+ └──────────────────┘
+
+WITHIN EACH BATCH:
+┌────────────────────────────────────────┐
+│ All hosts deploy in PARALLEL │
+│ │
+│ Host 1 ──┐ │
+│ Host 2 ──┤ │
+│ Host 3 ──┼─▶ Background processes (&)│
+│ ... │ │
+│ Host 256─┘ └─▶ wait command │
+└────────────────────────────────────────┘
+```
+
+### なぜバッチを逐次実行するのか
+
+**リソース管理:**
+
+- セルフホストランナーへの過剰な負荷を防止
+- 各バッチで 256 個の SSH 接続を並列に開く
+- 逐次処理により安定したパフォーマンスを確保
+
+**設定可能:**
+
+- デフォルトのバッチサイズ: 256 (GitHub Actions のマトリクス上限)
+- ワークフロー入力により、より小さなバッチに調整可能
+- 速度とリソース使用量のバランス調整
+
+### スケーリング特性
+
+**デプロイメント速度 (デフォルト BATCH_SIZE=256):**
+
+- 10 ホスト → 1 バッチ → 約 2 分
+- 100 ホスト → 1 バッチ → 約 3 分
+- 500 ホスト → 2 バッチ → 約 6 分
+- 1,000 ホスト → 4 バッチ → 約 12 分
+- 5,000 ホスト → 20 バッチ → 約 60 分
+
+**速度に影響する要因:**
+
+- ネットワーク帯域幅 (ホストあたり 19MB のパッケージ)
+- SSH 接続のオーバーヘッド (ホストあたり約 1 秒)
+- ターゲットホストの CPU/ディスク速度
+- ランナーのリソース (CPU/メモリ)
+
+## 次のステップ
+
+アーキテクチャを理解できたところで、次は GitHub のセットアップとセルフホストランナーの構成に進みます。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md
new file mode 100644
index 0000000000..0bde92e7c6
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md
@@ -0,0 +1,286 @@
+---
+title: GitHub Setup
+weight: 2
+time: 10 minutes
+---
+
+## 前提条件
+
+開始する前に、以下を準備していることを確認してください。
+
+- リポジトリアクセス権限のある GitHub アカウント
+- Ubuntu EC2 インスタンスを含む AWS VPC
+- ターゲットホストへの認証用 SSH キーペア（PEM ファイル）
+- AppDynamics Smart Agent パッケージ
+- SSH アクセス可能なターゲット Ubuntu EC2 インスタンス
+
+## リポジトリの Fork または Clone
+
+最初に、GitHub Actions ラボリポジトリへのアクセスを取得します。
+
+**Repository URL**: [https://github.com/chambear2809/github-actions-lab](https://github.com/chambear2809/github-actions-lab)
+
+```bash
+# Option 1: Fork the repository via GitHub UI
+# Go to https://github.com/chambear2809/github-actions-lab
+# Click "Fork" button
+
+# Option 2: Clone directly (for testing)
+git clone https://github.com/chambear2809/github-actions-lab.git
+cd github-actions-lab
+```
+
+## セルフホストランナーの構成
+
+セルフホストランナーは、ターゲット EC2 インスタンスと同じ AWS VPC にデプロイする必要があります。
+
+### EC2 インスタンスへのランナーのインストール
+
+1. VPC 内に **EC2 インスタンスを起動** します（Ubuntu または Amazon Linux 2）
+
+2. Fork したリポジトリで **ランナー設定に移動** します:
+
+ ```
+ Settings → Actions → Runners → New self-hosted runner
+ ```
+
+3. **ランナーインスタンスに SSH 接続** し、インストールコマンドを実行します:
+
+```bash
+# Create runner directory
+mkdir actions-runner && cd actions-runner
+
+# Download runner (check GitHub for latest version)
+curl -o actions-runner-linux-x64-2.311.0.tar.gz -L \
+ https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz
+
+# Extract
+tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz
+
+# Configure (use token from GitHub UI)
+./config.sh --url https://github.com/YOUR_USERNAME/github-actions-lab --token YOUR_TOKEN
+
+# Install as service
+sudo ./svc.sh install
+
+# Start service
+sudo ./svc.sh start
+```
+
+### ランナーステータスの確認
+
+以下の場所でランナーが **"Idle"**（緑色）として表示されていることを確認します:
+
+```
+Settings → Actions → Runners
+```
+
+{{% notice style="tip" %}}
+ワークフロージョブを取得するには、ランナーがオンラインかつアイドル状態を維持している必要があります。オフラインと表示されている場合は、サービスステータスを確認してください: `sudo ./svc.sh status`
+{{% /notice %}}
+
+## GitHub Secrets の構成
+
+以下に移動します: **Settings → Secrets and variables → Actions → Secrets**
+
+### SSH Private Key Secret
+
+このシークレットには、ターゲットホストにアクセスするための SSH 秘密鍵が含まれます。
+
+1. **"New repository secret"** をクリックします
+2. **Name**: `SSH_PRIVATE_KEY`
+3. **Value**: PEM ファイルの内容を貼り付けます
+
+```bash
+# View your PEM file
+cat /path/to/your-key.pem
+```
+
+形式の例:
+
+```
+-----BEGIN RSA PRIVATE KEY-----
+MIIEpAIBAAKCAQEA...
+...
+-----END RSA PRIVATE KEY-----
+```
+
+1. **"Add secret"** をクリックします
+
+{{% notice style="important" %}}
+SSH キーをリポジトリにコミットしないでください。機密性の高い認証情報には常に GitHub Secrets を使用してください。
+{{% /notice %}}
+
+## GitHub Variables の構成
+
+以下に移動します: **Settings → Secrets and variables → Actions → Variables**
+
+### Deployment Hosts Variable（必須）
+
+この変数には、Smart Agent をデプロイするすべてのターゲットホストのリストが含まれます。
+
+1. **"New repository variable"** をクリックします
+2. **Name**: `DEPLOYMENT_HOSTS`
+3. **Value**: ターゲットホストの IP を入力します（1 行に 1 つ）
+
+```
+172.31.1.243
+172.31.1.48
+172.31.1.5
+172.31.10.20
+172.31.10.21
+```
+
+**形式の要件:**
+
+- 1 行に 1 つの IP
+- カンマなし
+- スペースなし
+- 余計な文字なし
+- Unix 改行コードを使用（CRLF ではなく LF）
+
+1. **"Add variable"** をクリックします
+
+### オプション変数
+
+これらの変数はオプションで、Smart Agent サービスのユーザー/グループ構成に使用されます。
+
+#### SMARTAGENT_USER
+
+1. **"New repository variable"** をクリックします
+2. **Name**: `SMARTAGENT_USER`
+3. **Value**: 例: `appdynamics`
+4. **"Add variable"** をクリックします
+
+#### SMARTAGENT_GROUP
+
+1. **"New repository variable"** をクリックします
+2. **Name**: `SMARTAGENT_GROUP`
+3. **Value**: 例: `appdynamics`
+4. **"Add variable"** をクリックします
+
+## ネットワーク構成
+
+すべての EC2 インスタンスを同じ VPC およびセキュリティグループに配置するラボセットアップでは、以下の構成を行います。
+
+### セキュリティグループルール
+
+**インバウンドルール:**
+
+- 同じセキュリティグループからの SSH（ポート 22）（送信元: 同じ SG）
+
+**アウトバウンドルール:**
+
+- 0.0.0.0/0 への HTTPS（ポート 443）（GitHub API アクセス用）
+- 同じセキュリティグループへの SSH（ポート 22）（ターゲットアクセス用）
+
+### ネットワークのベストプラクティス
+
+- ✅ `DEPLOYMENT_HOSTS` にはプライベート IP アドレス（172.31.x.x）を使用する
+- ✅ ランナーとターゲットを同じセキュリティグループに配置する
+- ✅ ターゲットホストにパブリック IP は不要
+- ✅ ランナーはプライベートネットワーク経由で通信する
+- ✅ GitHub ポーリングのためにアウトバウンド HTTPS が必要
+
+## 構成の確認
+
+ワークフローを実行する前に、セットアップを確認します。
+
+### 1. ランナーステータスの確認
+
+1. **Settings → Actions → Runners** に移動します
+2. ランナーが "Idle"（緑色）として表示されることを確認します
+3. "Last seen" のタイムスタンプが最近のものであることを確認します
+
+### 2. SSH 接続のテスト
+
+ランナーインスタンスからターゲットホストへ SSH 接続します:
+
+```bash
+# On runner instance
+ssh -i ~/.ssh/your-key.pem ubuntu@172.31.1.243
+```
+
+成功した場合、ターゲットホスト上のシェルプロンプトが表示されます。
+
+### 3. Secrets と Variables の確認
+
+1. **Settings → Secrets and variables → Actions** に移動します
+2. Secrets タブに `SSH_PRIVATE_KEY` が表示されることを確認します
+3. Variables タブに `DEPLOYMENT_HOSTS` が表示されることを確認します
+
+### 4. リポジトリアクセスの確認
+
+ランナーがリポジトリにアクセスできることを確認します:
+
+```bash
+# On runner instance, as the runner user
+cd ~/actions-runner
+./run.sh # Test run (Ctrl+C to stop)
+```
+
+"Listening for Jobs" と表示されるはずです。
+
+## よくある問題のトラブルシューティング
+
+### ランナーがジョブを取得しない
+
+**症状**: ワークフローが "queued" 状態のままになる
+
+**解決策**:
+
+- ランナーのステータスを確認する: `sudo systemctl status actions.runner.*`
+- ランナーを再起動する: `sudo ./svc.sh restart`
+- GitHub への HTTPS（443）アウトバウンド接続を確認する
+
+### SSH 接続の失敗
+
+**症状**: ワークフローが "Permission denied" または "Connection refused" で失敗する
+
+**解決策**:
+
+```bash
+# Test from runner
+ssh -i ~/.ssh/test-key.pem ubuntu@172.31.1.243 -o ConnectTimeout=10
+
+# Check security group allows SSH from runner
+# Verify private key matches public key on targets
+```
+
+### ホスト名に無効な文字が含まれる
+
+**症状**: エラー: "hostname contains invalid characters"
+
+**解決策**:
+
+- `DEPLOYMENT_HOSTS` 変数を編集する
+- 末尾のスペースがないことを確認する
+- Unix 改行コードを使用する（CRLF ではなく LF）
+- 1 行に 1 つの IP、余計な文字を入れない
+
+### Secrets が見つからない
+
+**症状**: エラー: "Secret SSH_PRIVATE_KEY not found"
+
+**解決策**:
+
+- シークレット名が `SSH_PRIVATE_KEY` と完全に一致することを確認する
+- シークレットがリポジトリ Secrets（環境シークレットではなく）にあることを確認する
+- リポジトリの管理者権限があることを確認する
+
+## セキュリティのベストプラクティス
+
+セキュアな運用のために以下のベストプラクティスに従ってください。
+
+- ✅ すべての秘密鍵に GitHub Secrets を使用する
+- ✅ SSH キーを定期的にローテーションする
+- ✅ ランナーをプライベート VPC サブネット内に配置する
+- ✅ ランナーのセキュリティグループのアクセスを最小限に制限する
+- ✅ ランナーのソフトウェアを定期的に更新する
+- ✅ ブランチ保護ルールを有効化する
+- ✅ 環境ごとに異なるキーを使用する
+- ✅ リポジトリアクセスの監査ログを有効化する
+
+## 次のステップ
+
+GitHub の構成とランナーのセットアップが完了したので、利用可能なワークフローを確認し、最初のデプロイを実行する準備が整いました。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md
new file mode 100644
index 0000000000..3dd6478f3e
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md
@@ -0,0 +1,229 @@
+---
+title: ワークフローの理解
+weight: 3
+time: 10 minutes
+---
+
+## 利用可能なワークフロー
+
+この GitHub Actions ラボには、Smart Agent のライフサイクル全体を管理するための **11 個のワークフロー** が含まれています。すべてのワークフローファイルは、リポジトリの `.github/workflows/` で参照できます。
+
+**Repository**: [https://github.com/chambear2809/github-actions-lab](https://github.com/chambear2809/github-actions-lab)
+
+## ワークフローのカテゴリ
+
+### 1. デプロイメント (1 ワークフロー)
+
+#### Deploy Smart Agent (Batched)
+
+- **File**: `deploy-agent-batched.yml`
+- **目的**: Smart Agent をインストールし、サービスを開始します
+- **特徴**:
+ - 自動バッチ処理 (デフォルト: 1 バッチあたり 256 ホスト)
+ - バッチサイズの設定が可能
+ - 各バッチ内では並列デプロイ
+ - バッチ間は順次処理
+- **Inputs**:
+ - `batch_size`: バッチあたりのホスト数 (デフォルト: 256)
+- **Trigger**: 手動のみ (`workflow_dispatch`)
+
+### 2. エージェントのインストール (4 ワークフロー)
+
+すべてのインストールワークフローは、`smartagentctl` を使用して特定の種類のエージェントをインストールします。
+
+#### Install Node Agent (Batched)
+
+- **File**: `install-node-batched.yml`
+- **Command**: `smartagentctl install node`
+- **Batched**: あり (設定可能)
+
+#### Install Machine Agent (Batched)
+
+- **File**: `install-machine-batched.yml`
+- **Command**: `smartagentctl install machine`
+- **Batched**: あり (設定可能)
+
+#### Install DB Agent (Batched)
+
+- **File**: `install-db-batched.yml`
+- **Command**: `smartagentctl install db`
+- **Batched**: あり (設定可能)
+
+#### Install Java Agent (Batched)
+
+- **File**: `install-java-batched.yml`
+- **Command**: `smartagentctl install java`
+- **Batched**: あり (設定可能)
+
+### 3. エージェントのアンインストール (4 ワークフロー)
+
+すべてのアンインストールワークフローは、`smartagentctl` を使用して特定の種類のエージェントを削除します。
+
+#### Uninstall Node Agent (Batched)
+
+- **File**: `uninstall-node-batched.yml`
+- **Command**: `smartagentctl uninstall node`
+- **Batched**: あり (設定可能)
+
+#### Uninstall Machine Agent (Batched)
+
+- **File**: `uninstall-machine-batched.yml`
+- **Command**: `smartagentctl uninstall machine`
+- **Batched**: あり (設定可能)
+
+#### Uninstall DB Agent (Batched)
+
+- **File**: `uninstall-db-batched.yml`
+- **Command**: `smartagentctl uninstall db`
+- **Batched**: あり (設定可能)
+
+#### Uninstall Java Agent (Batched)
+
+- **File**: `uninstall-java-batched.yml`
+- **Command**: `smartagentctl uninstall java`
+- **Batched**: あり (設定可能)
+
+### 4. Smart Agent の管理 (2 ワークフロー)
+
+#### Stop and Clean Smart Agent (Batched)
+
+- **File**: `stop-clean-smartagent-batched.yml`
+- **Commands**:
+ - `smartagentctl stop`
+ - `smartagentctl clean`
+- **目的**: Smart Agent サービスを停止し、すべてのデータを削除します
+- **Batched**: あり (設定可能)
+
+#### Cleanup All Agents (Batched)
+
+- **File**: `cleanup-appdynamics.yml`
+- **Command**: `sudo rm -rf /opt/appdynamics`
+- **目的**: /opt/appdynamics ディレクトリを完全に削除します
+- **Batched**: あり (設定可能)
+- **警告**: この操作はすべての AppDynamics コンポーネントを完全に削除します
+
+{{% notice style="danger" %}}
+"Cleanup All Agents" ワークフローは `/opt/appdynamics` を完全に削除します。この操作は元に戻せません。慎重に使用してください。
+{{% /notice %}}
+
+## ワークフローの構造
+
+すべてのバッチ処理対応ワークフローは、一貫した 2 ジョブ構造に従います。
+
+### Job 1: Prepare
+
+```yaml
+prepare:
+ runs-on: self-hosted
+ outputs:
+ batches: ${{ steps.create-batches.outputs.batches }}
+ steps:
+ - name: Load hosts and create batches
+ run: |
+ # Load DEPLOYMENT_HOSTS variable
+ # Split into batches of N hosts
+ # Output as JSON array
+```
+
+**目的**: GitHub variables から対象ホストを読み込み、バッチマトリックスを作成します
+
+### Job 2: Deploy/Install/Uninstall
+
+```yaml
+deploy:
+ needs: prepare
+ runs-on: self-hosted
+ strategy:
+ matrix:
+ batch: ${{ fromJson(needs.prepare.outputs.batches) }}
+ steps:
+ - name: Setup SSH key
+ - name: Execute operation on all hosts in batch (parallel)
+```
+
+**目的**: 各バッチに対して並列に実行され、バッチ内のすべてのホストで指定された操作を実行します
+
+## バッチ処理の動作
+
+### 仕組み
+
+1. **Prepare Job** が `DEPLOYMENT_HOSTS` を読み込み、バッチに分割します
+2. **Deploy Job** が各バッチに対して 1 つのマトリックスエントリを作成します
+3. **バッチは順次処理** され、ランナーへの過負荷を防ぎます
+4. **各バッチ内** では、バックグラウンドプロセスを使用してすべてのホストへ並列でデプロイします
+
+### バッチサイズの設定
+
+すべてのワークフローは `batch_size` 入力を受け付けます (デフォルト: 256)。
+
+```bash
+# Via GitHub CLI
+gh workflow run "Deploy Smart Agent" -f batch_size=128
+
+# Via GitHub UI
+Actions → Select workflow → Run workflow → Set batch_size
+```
+
+### 例
+
+- **100 ホスト、batch_size=256**: 1 バッチ、約 3 分
+- **500 ホスト、batch_size=256**: 2 バッチ、約 6 分
+- **1,000 ホスト、batch_size=128**: 8 バッチ、約 16 分
+- **5,000 ホスト、batch_size=256**: 20 バッチ、約 60 分
+
+## ワークフローの実行順序
+
+### 一般的なデプロイメントの流れ
+
+1. **Deploy Smart Agent** - 初期デプロイ
+2. **Install Machine Agent** - 必要に応じて特定のエージェントをインストール
+3. **Install DB Agent** - データベース監視のインストール
+4. (必要に応じて他のインストールワークフローを使用)
+
+### メンテナンス・更新の流れ
+
+1. **Stop and Clean Smart Agent** - サービスを停止し、データをクリーンアップ
+2. **Deploy Smart Agent** - 更新版で再デプロイ
+3. **Install agents again** - 必要なエージェントを再インストール
+
+### 完全削除の流れ
+
+1. **Stop and Clean Smart Agent** - サービスを停止
+2. **Cleanup All Agents** - /opt/appdynamics ディレクトリを削除
+
+## ワークフローのコードを確認する
+
+リポジトリで完全なワークフロー YAML ファイルを確認できます。
+
+**メインのデプロイメントワークフロー:**
+[https://github.com/chambear2809/github-actions-lab/blob/main/.github/workflows/deploy-agent-batched.yml](https://github.com/chambear2809/github-actions-lab/blob/main/.github/workflows/deploy-agent-batched.yml)
+
+**すべてのワークフロー:**
+[https://github.com/chambear2809/github-actions-lab/tree/main/.github/workflows](https://github.com/chambear2809/github-actions-lab/tree/main/.github/workflows)
+
+## ワークフローの機能
+
+### 組み込みのエラーハンドリング
+
+- ホスト単位のエラー追跡
+- 失敗したホストのレポート
+- バッチレベルでの失敗処理
+- 必ず実行されるサマリー
+
+### 並列実行
+
+- バッチ内のすべてのホストへ同時にデプロイ
+- SSH のバックグラウンドプロセス (`&`) を使用
+- wait コマンドですべての完了を保証
+- リソース制限内での最大限の並列性
+
+### セキュリティ
+
+- SSH キーがログに表示されることはありません
+- 認証情報は環境変数としてバインドされます
+- 自動化のため厳密なホストキーチェックは無効化されています
+- ワークフロー完了後にキーは削除されます
+
+## 次のステップ
+
+利用可能なワークフローを理解したところで、最初のデプロイを実行してみましょう。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md
new file mode 100644
index 0000000000..60cc775b14
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md
@@ -0,0 +1,401 @@
+---
+title: ワークフローの実行
+weight: 4
+time: 15 minutes
+---
+
+## ワークフローのトリガー
+
+すべてのワークフローは `workflow_dispatch` で構成されており、手動でトリガーする必要があります。ワークフローを実行する主な方法は2つあります。
+
+1. **GitHub UI** - ビジュアルインターフェースで、ほとんどのユーザーにとって最も簡単です
+2. **GitHub CLI** - コマンドラインインターフェースで、自動化に最適です
+
+## 方法1: GitHub UI
+
+### ステップ1: Actionsタブに移動
+
+1. GitHub上のフォークしたリポジトリに移動します
+2. 上部の **Actions** タブをクリックします
+
+### ステップ2: ワークフローを選択
+
+左側のサイドバーに、利用可能なすべてのワークフローが表示されます。
+
+- Deploy Smart Agent
+- Install Node Agent (Batched)
+- Install Machine Agent (Batched)
+- Install DB Agent (Batched)
+- Install Java Agent (Batched)
+- Uninstall Node Agent (Batched)
+- Uninstall Machine Agent (Batched)
+- Uninstall DB Agent (Batched)
+- Uninstall Java Agent (Batched)
+- Stop and Clean Smart Agent (Batched)
+- Cleanup All Agents
+
+実行したいワークフローをクリックします。
+
+### ステップ3: ワークフローを実行
+
+1. **"Run workflow"** ボタン（右上）をクリックします
+2. ブランチを選択します: **main**
+3. （オプション）必要に応じて **batch_size** を調整します
+4. **"Run workflow"** ボタンをクリックします
+
+### ステップ4: 実行を監視
+
+1. ワークフローが下のリストに表示されます
+2. ワークフロー実行をクリックして詳細を表示します
+3. リアルタイムで進行状況を確認します
+4. ジョブ名をクリックして詳細なログを確認します
+
+## 方法2: GitHub CLI
+
+### GitHub CLIをインストール
+
+```bash
+# macOS
+brew install gh
+
+# Linux
+curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
+sudo apt update
+sudo apt install gh
+```
+
+### 認証
+
+```bash
+gh auth login
+```
+
+### ワークフローの実行
+
+```bash
+# Deploy Smart Agent (default batch size)
+gh workflow run "Deploy Smart Agent" --repo YOUR_USERNAME/github-actions-lab
+
+# Deploy with custom batch size
+gh workflow run "Deploy Smart Agent" \
+ --repo YOUR_USERNAME/github-actions-lab \
+ -f batch_size=128
+
+# Install agents
+gh workflow run "Install Node Agent (Batched for Large Scale)" \
+ --repo YOUR_USERNAME/github-actions-lab
+
+gh workflow run "Install Machine Agent (Batched for Large Scale)" \
+ --repo YOUR_USERNAME/github-actions-lab
+
+# Uninstall agents
+gh workflow run "Uninstall Node Agent (Batched for Large Scale)" \
+ --repo YOUR_USERNAME/github-actions-lab
+
+# Stop and clean
+gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)" \
+ --repo YOUR_USERNAME/github-actions-lab
+
+# Complete cleanup
+gh workflow run "Cleanup All Agents" \
+ --repo YOUR_USERNAME/github-actions-lab
+```
+
+### ワークフローの監視
+
+```bash
+# List recent workflow runs
+gh run list --repo YOUR_USERNAME/github-actions-lab
+
+# View specific run
+gh run view RUN_ID --repo YOUR_USERNAME/github-actions-lab
+
+# Watch run in progress
+gh run watch RUN_ID --repo YOUR_USERNAME/github-actions-lab
+
+# View failed logs
+gh run view RUN_ID --log-failed --repo YOUR_USERNAME/github-actions-lab
+```
+
+## 初回デプロイのウォークスルー
+
+完全な初回デプロイの手順を見ていきましょう。
+
+### ステップ1: セットアップを確認
+
+ワークフローを実行する前に、以下を確認します。
+
+- ✅ セルフホストランナーが "Idle"（緑色）と表示されている
+- ✅ `SSH_PRIVATE_KEY` シークレットが構成されている
+- ✅ `DEPLOYMENT_HOSTS` 変数にターゲットIPが含まれている
+- ✅ ネットワーク接続が確認されている
+
+### ステップ2: Smart Agentをデプロイ
+
+**GitHub UI経由:**
+
+1. **Actions** タブに移動します
+2. **"Deploy Smart Agent"** を選択します
+3. **"Run workflow"** をクリックします
+4. デフォルトの batch_size (256) を受け入れます
+5. **"Run workflow"** をクリックします
+
+**GitHub CLI経由:**
+
+```bash
+gh workflow run "Deploy Smart Agent" --repo YOUR_USERNAME/github-actions-lab
+```
+
+### ステップ3: 実行を監視
+
+ワークフローには次のように表示されます。
+
+1. **Prepare** ジョブ - バッチマトリックスを作成
+2. **Deploy** ジョブ（バッチごとに1つ） - ホストへのデプロイ
+
+各ジョブをクリックして詳細なログを確認します。
+
+### ステップ4: インストールを確認
+
+ターゲットホストにSSH接続して確認します。
+
+```bash
+# SSH to target
+ssh ubuntu@172.31.1.243
+
+# Check Smart Agent status
+cd /opt/appdynamics/appdsmartagent
+sudo ./smartagentctl status
+```
+
+**期待される出力:**
+
+```
+Smart Agent is running (PID: 12345)
+Service: appdsmartagent.service
+Status: active (running)
+```
+
+### ステップ5: 追加のエージェントをインストール（オプション）
+
+必要に応じて、特定のエージェントタイプをインストールします。
+
+```bash
+# Install Machine Agent
+gh workflow run "Install Machine Agent (Batched for Large Scale)" \
+ --repo YOUR_USERNAME/github-actions-lab
+
+# Install DB Agent
+gh workflow run "Install DB Agent (Batched for Large Scale)" \
+ --repo YOUR_USERNAME/github-actions-lab
+```
+
+## ワークフロー出力の理解
+
+### Prepareジョブの出力
+
+```
+Loading deployment hosts...
+Total hosts: 1000
+Batch size: 256
+Creating 4 batches...
+Batch 1: Hosts 1-256
+Batch 2: Hosts 257-512
+Batch 3: Hosts 513-768
+Batch 4: Hosts 769-1000
+```
+
+### Deployジョブの出力（バッチごと）
+
+```
+Processing batch 1 of 4
+Deploying to 256 hosts in parallel...
+Host 172.31.1.1: SUCCESS
+Host 172.31.1.2: SUCCESS
+Host 172.31.1.3: SUCCESS
+...
+Batch 1 complete: 256/256 succeeded
+```
+
+### 完了サマリー
+
+```
+Deployment Summary:
+Total hosts: 1000
+Successful: 998
+Failed: 2
+Failed hosts:
+ - 172.31.1.48
+ - 172.31.1.125
+```
+
+## 一般的なデプロイシナリオ
+
+### シナリオ1: 初回デプロイ
+
+```bash
+# 1. Deploy Smart Agent
+gh workflow run "Deploy Smart Agent"
+
+# 2. Verify deployment
+# SSH to a host and check status
+
+# 3. Install agents as needed
+gh workflow run "Install Machine Agent (Batched for Large Scale)"
+gh workflow run "Install DB Agent (Batched for Large Scale)"
+```
+
+### シナリオ2: Smart Agentの更新
+
+```bash
+# 1. Stop and clean current installation
+gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)"
+
+# 2. Update Smart Agent ZIP in repository
+# (Push new version to repository)
+
+# 3. Deploy new version
+gh workflow run "Deploy Smart Agent"
+
+# 4. Reinstall agents
+gh workflow run "Install Machine Agent (Batched for Large Scale)"
+```
+
+### シナリオ3: 新しいホストの追加
+
+```bash
+# 1. Update DEPLOYMENT_HOSTS variable in GitHub
+# Add new IPs
+
+# 2. Deploy to all hosts (will skip existing ones with idempotent logic)
+gh workflow run "Deploy Smart Agent"
+```
+
+### シナリオ4: 完全削除
+
+```bash
+# 1. Stop and clean
+gh workflow run "Stop and Clean Smart Agent (Batched for Large Scale)"
+
+# 2. Complete removal
+gh workflow run "Cleanup All Agents"
+```
+
+{{% notice style="danger" %}}
+"Cleanup All Agents" は `/opt/appdynamics` を完全に削除します。これは元に戻せません！
+{{% /notice %}}
+
+## ワークフロー失敗のトラブルシューティング
+
+### ワークフローが "Queued" のままになる
+
+**症状**: ワークフローが開始しない
+
+**原因**: ランナーが利用できないか、オフラインになっている
+
+**解決策**:
+
+1. ランナーのステータスを確認: Settings → Actions → Runners
+2. ランナーが "Idle"（緑色）と表示されていることを確認します
+3. 必要に応じてランナーを再起動: `sudo ./svc.sh restart`
+
+### SSH接続の失敗
+
+**症状**: "Permission denied" または "Connection refused" エラー
+
+**解決策**:
+
+**SSHを手動でテスト:**
+
+```bash
+# From runner instance
+ssh -i ~/.ssh/test-key.pem ubuntu@172.31.1.243
+```
+
+**セキュリティグループを確認:**
+
+- SSH (22) がランナーから許可されているか確認します
+- ランナーとターゲットが同じセキュリティグループにあることを確認します
+
+**SSHキーを確認:**
+
+- `SSH_PRIVATE_KEY` シークレットが実際のキーと一致していることを確認します
+- 公開キーがターゲットホストにあることを確認します
+
+### バッチの部分的な失敗
+
+**症状**: 一部のホストは成功し、他のホストは失敗する
+
+**解決策**:
+
+1. ワークフローのログを表示して失敗したホストを特定します
+2. 失敗したホストにSSH接続して調査します
+3. ワークフローを再実行します（冪等性により、成功したホストはスキップされます）
+
+### バッチジョブのエラー
+
+**症状**: "Error splitting hosts into batches"
+
+**解決策**:
+
+- `DEPLOYMENT_HOSTS` 変数のフォーマットを確認します
+- 1行に1つのIPであることを確認します
+- 末尾のスペースや特殊文字がないことを確認します
+- Unixの改行コード（CRLFではなくLF）を使用します
+
+## パフォーマンスチューニング
+
+### バッチサイズの調整
+
+**小さなバッチ**（リソース少、処理遅）:
+
+```bash
+gh workflow run "Deploy Smart Agent" -f batch_size=128
+```
+
+**大きなバッチ**（リソース多、処理速い）:
+
+```bash
+gh workflow run "Deploy Smart Agent" -f batch_size=256
+```
+
+### ランナーリソースの推奨値
+
+| ホスト数 | CPU | メモリ | バッチサイズ |
+|-------|-----|--------|------------|
+| 1-100 | 2 cores | 4 GB | 256 |
+| 100-500 | 4 cores | 8 GB | 256 |
+| 500-2000 | 8 cores | 16 GB | 256 |
+| 2000+ | 16 cores | 32 GB | 256 |
+
+## ベストプラクティス
+
+1. **まず単一ホストでテスト**
+ - 1つのIPでテスト変数を作成します
+ - ワークフローを実行して確認します
+ - その後、完全なリストにデプロイします
+
+2. **ワークフロー実行を監視**
+ - ログをリアルタイムで監視します
+ - エラーをすぐに確認します
+ - サンプルホストで確認します
+
+3. **適切なバッチサイズを使用**
+ - デフォルト (256) はほとんどの場合に機能します
+ - ランナーが苦戦する場合は減らします
+ - ランナーのリソース使用量を監視します
+
+4. **ワークフローを最新の状態に保つ**
+ - リポジトリから最新の変更をプルします
+ - 非本番環境で更新をテストします
+ - カスタマイズを文書化します
+
+5. **ランナーの正常性を維持**
+ - ランナーをオンラインでアイドル状態に保ちます
+ - ランナーソフトウェアを定期的に更新します
+ - ディスク容量とリソースを監視します
+
+## 次のステップ
+
+おめでとうございます！GitHub Actionsを使用してAppDynamics Smart Agentのデプロイを自動化する方法を学びました。詳細については、[完全なリポジトリ](https://github.com/chambear2809/github-actions-lab)を参照してください。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/_index.md
new file mode 100644
index 0000000000..b9b2414dbd
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/3-github-actions/_index.md
@@ -0,0 +1,93 @@
+---
+title: GitHub Actions による自動化
+weight: 3
+time: 2 minutes
+description: GitHub Actions とセルフホストランナーを利用して、AppDynamics Smart Agent のデプロイを自動化する方法を学びます。
+---
+
+## はじめに
+
+このワークショップでは、**GitHub Actions** とセルフホストランナーを使用して、複数の EC2 インスタンスへの **AppDynamics Smart Agent** のデプロイとライフサイクル管理を自動化する方法を解説します。10 台のホストを管理する場合でも、10,000 台のホストを管理する場合でも、本ガイドではスケーラブルかつセキュアで再現可能な Smart Agent オペレーションを実現するための GitHub Actions ワークフロー活用方法を紹介します。
+
+ 
+
+## このワークショップで学ぶこと
+
+このワークショップでは、以下の内容を学習します。
+
+- GitHub Actions ワークフローを利用して、複数のホストに **Smart Agent をデプロイ**する方法
+- 安全な認証情報管理のために **GitHub の secrets と variables を設定**する方法
+- AWS VPC 内に**セルフホストランナーをセットアップ**する方法
+- 数千台のホストに対応するための**自動バッチ処理を実装**する方法
+- インストール、アンインストール、停止、クリーンアップを含む**エージェントの完全なライフサイクル管理**
+- **ワークフローの実行状況を監視**し、問題をトラブルシュートする方法
+
+## 主な機能
+
+- 🚀 **並列デプロイ** - 複数のホストに同時にデプロイ
+- 🔄 **完全なライフサイクル管理** - エージェントの全オペレーションを網羅する 11 個のワークフロー
+- 🏗️ **Infrastructure as Code** - すべてのワークフローを GitHub でバージョン管理
+- 🔐 **セキュア** - SSH キーを GitHub secrets として保存し、プライベート VPC ネットワーキングを使用
+- 📈 **大規模なスケーラビリティ** - 自動バッチ処理により数千台のホストへのデプロイに対応
+- 🎛️ **セルフホストランナー** - 自身の AWS VPC 内で実行
+
+## アーキテクチャ概要
+
+```text
+┌─────────────────────────────────────────────────────────────────┐
+│ GitHub Actions-based Deployment │
+├─────────────────────────────────────────────────────────────────┤
+│ │
+│ Developer ──▶ GitHub.com ──▶ Self-hosted Runner (AWS VPC) │
+│ │ │
+│ ├──▶ Host 1 (SSH) │
+│ ├──▶ Host 2 (SSH) │
+│ ├──▶ Host 3 (SSH) │
+│ └──▶ Host N (SSH) │
+│ │
+│ All hosts send metrics ──▶ AppDynamics Controller │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+## ワークショップの構成
+
+このワークショップには、以下の内容が含まれます。
+
+1. **アーキテクチャと設計** - GitHub Actions ワークフローのアーキテクチャを理解する
+2. **GitHub のセットアップ** - secrets、variables、セルフホストランナーの設定
+3. **ワークフローの作成** - 利用可能な 11 個のワークフローの理解と使用方法
+4. **デプロイの実行** - ワークフローの実行とインストールの検証
+
+## 利用可能なワークフロー
+
+このソリューションには、Smart Agent の完全なライフサイクル管理のための **11 個のワークフロー**が含まれています。
+
+| カテゴリ | ワークフロー数 | 説明 |
+| -------- | --------- | ----------- |
+| **デプロイ** | 1 | Smart Agent のデプロイと起動 |
+| **エージェントのインストール** | 4 | Node、Machine、DB、Java の各エージェントをインストール |
+| **エージェントのアンインストール** | 4 | 特定のエージェントタイプをアンインストール |
+| **エージェント管理** | 2 | 停止／クリーンアップと完全クリーンアップ |
+
+すべてのワークフローはスケーラビリティのための自動バッチ処理に対応しています。
+
+## 前提条件
+
+- リポジトリへのアクセス権を持つ GitHub アカウント
+- Ubuntu EC2 インスタンスを含む AWS VPC
+- 同じ VPC 内のセルフホスト GitHub Actions ランナー
+- 認証用の SSH キーペア
+- AppDynamics Smart Agent パッケージ
+
+## GitHub リポジトリ
+
+すべてのワークフローコードと設定ファイルは、以下の GitHub リポジトリで公開されています。
+
+**[https://github.com/chambear2809/github-actions-lab](https://github.com/chambear2809/github-actions-lab)**
+
+リポジトリには以下が含まれます。
+
+- 11 個の完全なワークフロー YAML ファイル
+- 詳細なセットアップドキュメント
+- アーキテクチャ図
+- トラブルシューティングガイド
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md
new file mode 100644
index 0000000000..0a4d2583ae
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md
@@ -0,0 +1,95 @@
+---
+title: セットアップと設定
+weight: 2
+time: 10 minutes
+---
+
+## Step 2: ファイルとディレクトリ構造の準備
+
+Ansible デプロイメント用のプロジェクトディレクトリを作成します。次のファイルを含めてください。
+
+```text
+.
+├── appdsmartagent_64_linux_24.6.0.2143.deb # Debian package
+├── appdsmartagent_64_linux_24.6.0.2143.rpm # RedHat package
+├── inventory-cloud.yaml # Inventory file
+├── smartagent.yaml # Playbook
+└── variables.yaml # Variables file
+```
+
+ターゲット環境用に適切な Smart Agent パッケージをダウンロード済みであることを確認してください。
+
+## Step 3: ファイルの理解
+
+### 1. Inventory ファイル (`inventory-cloud.yaml`)
+
+inventory ファイルには Smart Agent をデプロイするホストを記載します。ここでホストと認証情報を定義します。
+
+```yaml
+all:
+ hosts:
+ smartagent-host-1:
+ ansible_host: 54.173.1.106
+ ansible_username: ec2-user
+ ansible_password: ins3965!
+ ansible_become: yes
+ ansible_become_method: sudo
+ ansible_become_password: ins3965!
+ ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
+
+ smartagent-host-2:
+ ansible_host: 192.168.86.107
+ ansible_username: aleccham
+ ansible_password: ins3965!
+ ansible_become: yes
+ ansible_become_method: sudo
+ ansible_become_password: ins3965!
+
+ smartagent-host-3:
+ ansible_host: 54.82.95.69
+ ansible_username: ubuntu
+ ansible_password: ins3965!
+ ansible_become: yes
+ ansible_become_method: sudo
+ ansible_become_password: ins3965!
+```
+
+**作業内容**: `ansible_host` の IP と認証情報を、実際のラボ環境の値に更新してください。
+
+### 2. 変数ファイル (`variables.yaml`)
+
+このファイルには Smart Agent の設定情報が含まれています。
+
+```yaml
+smart_agent:
+ controller_url: 'CONTROLLER URL HERE, JUST THE BASE URL' # o11y.saas.appdynamics.com
+ account_name: 'Account Name Here'
+ account_access_key: 'YOUR ACCESS KEY HERE'
+ fm_service_port: '443' # Use 443 or 8080 depending on your environment.
+ ssl: true
+
+smart_agent_package_debian: 'appdsmartagent_64_linux_24.6.0.2143.deb' # or the appropriate package name
+smart_agent_package_redhat: 'appdsmartagent_64_linux_24.6.0.2143.rpm' # or the appropriate package name
+```
+
+**作業内容**: `smart_agent` セクションを、ご自身のコントローラー URL、アカウント名、アクセスキーで更新してください。
+
+### 3. Playbook (`smartagent.yaml`)
+
+この playbook は Cisco AppDynamics Distribution of OpenTelemetry Collector のデプロイメントを統括します。タスクの概要は次のとおりです。
+
+1. **前提条件**: 必要なパッケージをインストールします (RedHat 系は `yum-utils`、Debian 系は `curl`/`apt-transport-https`)。
+2. **ディレクトリの準備**: `/opt/appdynamics/appdsmartagent` ディレクトリが存在することを確認します。
+3. **設定**:
+ * `config.ini` が存在するか確認します。
+ * 存在しない場合は、`variables.yaml` の値を使用してデフォルトの `config.ini` を作成します。
+ * `lineinfile` を使用して設定キー (AccountAccessKey、ControllerURL など) を更新し、設定が正しいことを保証します。
+4. **パッケージ管理**:
+ * OS ファミリ (Debian/RedHat) に応じて正しいパッケージパスを判定します。
+ * パッケージがローカルに存在しない場合は失敗します。
+ * パッケージをターゲットホストの `/tmp` ディレクトリにコピーします。
+ * `dpkg` または `yum` を使用してパッケージをインストールします。
+5. **サービス管理**: `smartagent` サービスを再起動します。
+6. **クリーンアップ**: 一時的なパッケージファイルを削除します。
+
+この playbook は `when: ansible_os_family == ...` 条件分岐を使用して、同じワークフロー内で RedHat 系と Debian 系の両方のシステムに対応しています。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md
new file mode 100644
index 0000000000..cf22bf2d0c
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md
@@ -0,0 +1,25 @@
+---
+title: デプロイ
+weight: 3
+time: 5 minutes
+---
+
+## ステップ4: Playbook の実行
+
+Smart Agent をデプロイするには、プロジェクトディレクトリから次のコマンドを実行します。
+
+```bash
+ansible-playbook -i inventory-cloud.yaml smartagent.yaml
+```
+
+別の名前で作成している場合は、 `inventory-cloud.yaml` をご利用の環境に合った inventory ファイルに置き換えてください。
+
+### 検証
+
+Playbook が正常に完了したら、対象ホストのいずれかにログインしてサービスの状態を確認することで、デプロイを検証できます。
+
+```bash
+systemctl status smartagent
+```
+
+サービスが active (running) になっていることが確認できるはずです。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md
new file mode 100644
index 0000000000..35caefebcf
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md
@@ -0,0 +1,72 @@
+---
+title: Monitoring as Code with Smart Agent and Ansible
+linkTitle: Ansible Automation
+weight: 4
+time: 10 minutes
+description: Ansible を使用して AppDynamics Smart Agent のデプロイを自動化する方法を学びます。
+---
+
+## はじめに
+
+このガイドでは、Ansible を使用して Cisco AppDynamics Smart Agent を複数のホストにデプロイする方法について詳しく説明します。自動化を活用することで、監視インフラストラクチャの一貫性、堅牢性、そして容易なスケーラビリティを確保できます。
+
+## アーキテクチャの概要
+
+このデプロイアーキテクチャでは、Ansible Control Node を活用して、ターゲットホストへの Smart Agent のインストールと構成をオーケストレーションします。
+
+```mermaid
+graph TD
+ CN[Ansible Control Node
(macOS/Linux)] -->|SSH| H1[Target Host 1
(Debian/RedHat)]
+ CN -->|SSH| H2[Target Host 2
(Debian/RedHat)]
+ CN -->|SSH| H3[Target Host N
(Debian/RedHat)]
+
+ subgraph "Target Host Configuration"
+ SA[Smart Agent Service]
+ Config[config.ini]
+ Package[Installer .deb/.rpm]
+ end
+
+ H1 --> SA
+ H2 --> SA
+ H3 --> SA
+```
+
+### 主要なコンポーネント
+
+* **Ansible Control Node**: Playbook を実行するマシン（例: 自身のラップトップやジャンプホスト）です。
+* **Target Hosts**: Smart Agent をインストールするサーバーです。
+* **Inventory**: ターゲットホストとその接続情報の一覧です。
+* **Playbook**: デプロイタスクを定義した YAML ファイルです。
+
+## 前提条件
+
+開始する前に、以下を満たしていることを確認してください。
+
+* SSH 経由でターゲットホストにアクセスできること。
+* ターゲットホストで sudo 権限を持っていること。
+* Smart Agent のインストールパッケージ（`.deb` または `.rpm`）をダウンロード済みであること。
+* AppDynamics Controller のアカウント情報（Access Key、Account Name、URL）。
+
+## ステップ 1: macOS に Ansible をインストールする
+
+まず、Control Node に Ansible をインストールする必要があります。
+
+1. **Homebrew のインストール**（まだインストールしていない場合）:
+
+ ```bash
+ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
+ ```
+
+2. **Ansible のインストール**:
+
+ ```bash
+ brew install ansible
+ ```
+
+3. **インストールの検証**:
+
+ ```bash
+ ansible --version
+ ```
+
+ インストールされた Ansible のバージョンが出力されているはずです。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/_index.md
new file mode 100644
index 0000000000..8822385cd4
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/6-smartagent/_index.md
@@ -0,0 +1,155 @@
+---
+title: SmartAgent Deployment
+weight: 6
+time: 2 minutes
+description: AppDynamics Smart Agent をインフラ全体にスケールしてデプロイ・管理するための複数のアプローチを学びます。
+---
+
+## はじめに
+
+AppDynamics **Smart Agent** は、インフラに対して包括的な監視機能を提供する軽量でインテリジェントなエージェントです。このセクションでは 4 つの異なるデプロイアプローチを取り上げ、組織のニーズや既存のツールに最も適した方法を選択できるようにします。
+
+
+
+## Smart Agent とは
+
+Smart Agent は AppDynamics の次世代監視エージェントで、以下を提供します。
+
+- **統合監視**: インフラ、アプリケーション、サービスを単一のエージェントで監視
+- **軽量設計**: 最小限のリソースフットプリント
+- **自動検出**: アプリケーションを自動的に検出して監視
+- **ネイティブ計装**: アプリケーションパフォーマンスへの深い可視性
+- **柔軟なデプロイ**: 複数のインストール・管理オプション
+
+## デプロイアプローチ
+
+このセクションでは、Smart Agent をスケールしてデプロイするための 4 つの異なるアプローチを取り上げます。
+
+### 1. リモートインストール (smartagentctl)
+
+`smartagentctl` CLI ツールを使用して SSH 経由でデプロイする最も直接的なアプローチです。
+
+**最適な用途:**
+
+- 中規模な数のホストへの迅速なデプロイ
+- 既存の CI/CD インフラを持たない環境
+- テストおよび概念実証のシナリオ
+- デプロイプロセスを直接制御したい場合
+
+**主な特徴:**
+
+- 直接 SSH ベースのデプロイ
+- シンプルな YAML 設定
+- 追加ツール不要
+- 並列実行サポート
+
+### 2. Jenkins Automation
+
+Jenkins パイプラインを使用してライフサイクル全体を管理する、エンタープライズグレードのデプロイ方法です。
+
+**最適な用途:**
+
+- すでに Jenkins を使用している組織
+- 複雑なデプロイワークフロー
+- 承認ゲートを必要とする環境
+- 既存の CI/CD パイプラインとの統合
+
+**主な特徴:**
+
+- パラメータ化されたパイプライン
+- 数千台のホストに対するバッチ処理
+- 完全なライフサイクル管理
+- 集中ログとレポート
+
+### 3. GitHub Actions Automation
+
+セルフホスト型ランナーを使用した GitHub Actions ワークフローによる、モダンな CI/CD アプローチです。
+
+**最適な用途:**
+
+- バージョン管理に GitHub を使用しているチーム
+- クラウドネイティブな環境
+- GitOps ワークフロー
+- Web ベースの管理を好む分散チーム
+
+**主な特徴:**
+
+- 11 個の専用ワークフロー
+- VPC 内のセルフホスト型ランナー
+- GitHub Secrets との統合
+- スケーラビリティのための自動バッチ処理
+
+### 4. Ansible Automation
+
+Ansible playbook を使用した Infrastructure as Code による設定管理アプローチです。
+
+**最適な用途:**
+
+- 設定管理に Ansible を使用しているチーム
+- 宣言的なインフラ定義
+- フリート全体での一貫した状態管理
+
+**主な特徴:**
+
+- Infrastructure as Code (IaC)
+- 冪等な playbook
+- インベントリ管理
+- ロールベースの構成
+
+## 適切なアプローチの選択
+
+| 要素 | リモートインストール | Jenkins | GitHub Actions | Ansible |
+|--------|-------------------|---------|----------------|---------|
+| **セットアップの複雑さ** | 低 | 中 | 中 | 低 |
+| **スケーラビリティ** | 良 (数百台のホスト) | 優 (数千台) | 優 (数千台) | 優 (数千台) |
+| **前提条件** | SSH アクセスのみ | Jenkins サーバー | GitHub アカウント | Ansible コントロールノード |
+| **学習曲線** | 最小限 | 中程度 | 中程度 | 低～中程度 |
+| **自動化レベル** | 手動実行 | 完全自動化 | 完全自動化 | 完全自動化 |
+| **最適なユースケース** | 迅速なデプロイ | エンタープライズ CI/CD | モダン DevOps | Infrastructure as Code |
+
+## すべてのアプローチに共通する機能
+
+どのデプロイ方法を選択しても、すべてのアプローチで以下が提供されます。
+
+- ✅ リモートホストへの **SSH ベースのデプロイ**
+- ✅ より高速なデプロイのための **並列実行**
+- ✅ **完全なライフサイクル管理** (インストール、起動、停止、アンインストール)
+- ✅ コントローラー設定の **構成管理**
+- ✅ **エラーハンドリング** とログ記録
+- ✅ 数百～数千台のホストへの **スケーラビリティ**
+
+## ワークショップ構成
+
+各デプロイアプローチには専用のセクションがあります。
+
+1. **Remote Installation** - 直接 CLI ベースのデプロイ
+2. **Jenkins Automation** - パイプラインベースのエンタープライズデプロイ
+3. **GitHub Actions** - モダンなワークフローベースのデプロイ
+4. **Ansible Automation** - Infrastructure as Code デプロイ
+
+ニーズに応じて、1 つまたはすべてのアプローチを実施できます。
+
+{{% notice title="Tip" style="primary" icon="lightbulb" %}}
+Smart Agent のデプロイが初めての方は、より自動化されたソリューションに進む前に、まず **Remote Installation** アプローチから始めて基本を理解することをおすすめします。
+{{% /notice %}}
+
+## 前提条件
+
+いずれかのデプロイアプローチを進める前に、以下を確認してください。
+
+- コントローラーへのアクセスが可能な AppDynamics アカウント
+- アカウント名とアクセスキー
+- SSH アクセス可能なターゲットホスト
+- ホストから AppDynamics Controller へのネットワーク接続
+- ターゲットホスト上の適切な権限
+
+## 次のステップ
+
+優先するデプロイアプローチを選択して、該当するセクションに進んでください。
+
+- **シンプルに始める**: Remote Installation から始めて基本を学習
+- **Jenkins でスケール**: エンタープライズグレードの自動化のために Jenkins へ移行
+- **GitHub でモダン化**: クラウドネイティブなワークフローのために GitHub Actions を採用
+- **Ansible で自動化**: 宣言的な設定管理のために Ansible を活用
+
+各セクションでは、Smart Agent をスケールしてデプロイするための完全なハンズオンガイドを提供します。
diff --git a/content/ja/ninja-workshops/apm/15-appd-workshop/_index.md b/content/ja/ninja-workshops/apm/15-appd-workshop/_index.md
new file mode 100644
index 0000000000..1efa8587b7
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/15-appd-workshop/_index.md
@@ -0,0 +1,38 @@
+---
+title: Splunk4Ninjas AppDynamics
+weight: 15
+time: 90 minutes
+description: フルスタック AppDynamics ウォークスルー — Java APM、サーバー可視化、ブラウザ RUM、データベース監視、Business iQ アナリティクス。
+aliases:
+ - /ninja-workshops/15-appd-workshop/
+---
+
+## はじめに
+
+Splunk AppDynamics は、ビジネスクリティカルなアプリケーション向けのフルスタック性能監視ソリューションであり、以下の機能を提供します。
+
+- 従来型、ハイブリッド、クラウドネイティブを問わず、環境を選ばない一貫したエンドツーエンドのアプリケーション監視。
+- デプロイ先を問わず、アプリケーションに対するクラウド移行の加速とエンタープライズグレードのエンドツーエンドの洞察。
+- 性能問題がビジネス上の問題に発展する前に迅速に解決でき、3 クリックで根本原因にたどり着ける統合監視。
+
+従来型、クラウド、ハイブリッドのいずれのデプロイメントにおいても、AppDynamics プラットフォームに関する既存の人材、プロセス、トレーニングを活用することで、総所有コスト (TCO) を最適化できます。
+
+
+
+## ワークショップ概要
+
+このワークショップでは、Splunk AppDynamics の基本を扱います。Splunk AppDynamics を使って、アプリケーションサービス、Web アプリケーション、データベースなどの健全性をどのように監視できるかを実演します。本ワークショップを完了すると、以下のことができるようになります。
+
+- AppDynamics Java APM Agent のダウンロードとインストール。
+- Controller における収集設定の構成。
+- アプリケーションのパフォーマンスの健全性の監視とトラブルシューティング。
+- AppDynamics が取得したデータに基づくモニタリングサービスのアラート監視。
+- サーバーの健全性の監視と問題のトラブルシューティング。
+- BRUM を用いたブラウザベースのアプリケーションの健全性の監視。
+- データベースのパフォーマンスの監視とトラブルシューティング。
+- Splunk AppDynamics Business IQ によるユーザー行動への深い可視性の獲得。
+
+## 今後追加予定の作業
+
+- ヘルスルールに関するセクションの追加（既存のヘルスルールの確認方法、新しいヘルスルールの作成）。
+- アプリケーションセキュリティ。
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/1-overview/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/1-overview/_index.md
new file mode 100644
index 0000000000..47db911ca7
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/1-overview/_index.md
@@ -0,0 +1,105 @@
+---
+title: ワークショップ概要
+linkTitle: 1. 概要
+weight: 1
+archetype: chapter
+time: 5 minutes
+description: ユースケース、アーキテクチャ、前提条件、およびハイブリッドモードとデュアルシグナルモードの違いについて解説します。
+---
+
+## ユースケース
+
+あなたの組織では現在、APM として AppDynamics を運用しています。データの可視性とガバナンスに関する取り組みの一環として、経営陣はアプリケーションパフォーマンスデータを **Splunk Observability Cloud** にも流し込み、すでに Splunk に存在するインフラストラクチャメトリクス、ログ、その他のシグナルと並べて、チームに統一されたビューを提供したいと考えています。
+
+すべてのサービスを別個の OpenTelemetry SDK で再計装する代わりに、AppDynamics Java Agent は **デュアルシグナルモード** をサポートしています。これは、単一のエージェントが AppDynamics APM データと OpenTelemetry トレースの両方を同時に生成する仕組みです。これにより、AppDynamics の機能をフルに維持しながら、同じテレメトリーを OpenTelemetry Collector 経由で Splunk Observability Cloud にストリーミングできます。
+
+これは、現在 AppDynamics を熟知し、依存している L1 および L2 チームにとって特に有用です。デュアルインジェストは、彼らが担当するアプリケーションとサービスがクラウド上の SaaS プラットフォームでホストされる新しいサービスとますます連携していく中で、コンテキストを維持するのに役立ちます。
+
+## このワークショップで学ぶこと
+
+このワークショップを終える頃には、次のことができるようになります。
+
+- AppDynamics Java Agent を使ったシンプルな Java サービスのビルドと実行
+- **ハイブリッドモード** と **デュアルシグナルモード** の違いの理解
+- デュアルシグナルモードを有効化して、APM データを AppDynamics と Splunk Observability Cloud の両方に送信
+- 両プラットフォームでのトレースとメトリクスの確認
+- ワンクリックで AppDynamics に遷移できる **global data link** を Splunk Observability Cloud で作成
+
+## アーキテクチャ
+
+このワークショップでは、Spring Boot Java アプリケーションを EC2 インスタンス上で直接実行します。AppDynamics Java Agent は JVM プロセスにアタッチされます。
+
+**フェーズ 1: 通常の AppD 計装:**
+
+```text
+Java App + AppD Agent ──▶ AppD Controller
+```
+
+**フェーズ 2: デュアルシグナルモード有効化:**
+
+```text
+Java App + AppD Agent ──▶ AppD Controller (AppD protocol, unchanged)
+ ──▶ OTel Collector (OTLP on localhost:4317)
+ │
+ ▼
+ Splunk Observability Cloud
+```
+
+OpenTelemetry Collector は同じ EC2 インスタンス上で実行され、エージェントから OTLP を受信し、トレースとメトリクスを Splunk Observability Cloud にエクスポートします。
+
+**Note:** Collector を介さずにエージェントから直接当社の [OTLP ingest endpoint](https://dev.splunk.com/observability/docs/datamodel/ingest/#Send-data-points) にデータを送信することも可能ですが、OTel 設定で関与する一部の属性や関連付けが失われる可能性があります。
+
+## ハイブリッドモード vs デュアルシグナルモード
+
+AppDynamics Java Agent は、OpenTelemetry データを送出するための 2 つのモードをサポートしています。
+
+両者の違いを理解することは重要です。
+
+### ハイブリッドモード - 古くて埃をかぶった方式 (GA, Java Agent 22.3+)
+
+- AppDynamics 独自の **計装ルール** が OTel フォーマットのスパンを生成
+- エージェントは既存の計装を再利用して OTel データを生成 (古いセマンティックバージョン)
+- フレームワークのカバレッジは AppDynamics が計装するものに限定
+- 有効化方法: `-Dagent.deployment.mode=hybrid`
+
+### デュアルシグナルモード - 新しく注目の方式 (Beta, Java Agent 25.6+)
+
+- 完全な [OpenTelemetry Java auto-instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/) が AppD エージェントと **並行して** 実行
+- 2 つの独立した計装エンジンが並列で動作
+- **より広範なフレームワークカバレッジ** OTel Java エージェントがサポートするすべて
+- CPU とメモリの消費量が増加
+- 有効化方法: `-Dagent.deployment.mode=dual` または環境変数 `AGENT_DEPLOYMENT_MODE=dual`
+
+### このワークショップでデュアルモードを使う理由
+
+デュアルシグナルモードでは、ハイブリッドモードにはない **相関属性** がルートスパンに追加されます。
+
+| 属性 | 説明 |
+|---|---|
+| `appd.app.name` | AppDynamics アプリケーション名 |
+| `appd.tier.name` | AppDynamics ティア名 (ティアが変化する際にはトレースの途中にも現れます) |
+| `appd.bt.name` | AppDynamics ビジネストランザクション名 |
+| `appd.request.guid` | AppDynamics リクエスト GUID |
+
+これらの属性により、**global data links** が利用可能になります。これは Splunk Observability Cloud のトレース上のクリック可能なリンクで、対応する AppDynamics ビューに直接遷移できます。さらに、デュアルモードでキャプチャされた AppDynamics スナップショットには、Data Collectors タブに OTel `TraceId` が含まれるため、双方向のナビゲーションが可能です。
+
+## 前提条件
+
+ワークショップインスタンスには、必要なツールがあらかじめ設定されています。
+
+| 要件 | ワークショップインスタンスでの状態 |
+|---|---|
+| Linux ホスト (Ubuntu) | 提供済み |
+| OpenJDK 17 | プリインストール済み |
+| Maven | プリインストール済み |
+| ワークショップ資材 | `~/workshop/appd/` にデプロイ済み |
+
+また、以下も必要です。
+
+| 要件 | 取得方法 |
+|---|---|
+| Splunk Observability Cloud アカウント | インストラクターから提供 |
+| **Splunk Access Token** (Ingest) | インスタンス上で `echo $ACCESS_TOKEN` を実行 |
+| **Splunk Realm** (例 `us0`, `us1`, `eu0`) | インスタンス上で `echo $REALM` を実行 |
+| **Instance name** | インスタンス上で `echo $INSTANCE` を実行 |
+| AppDynamics Controller アクセス | [SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco の認証情報でログイン |
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/1-build-the-app.md b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/1-build-the-app.md
new file mode 100644
index 0000000000..7a49aaee37
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/1-build-the-app.md
@@ -0,0 +1,91 @@
+---
+title: 1. アプリケーションのビルド
+weight: 1
+---
+
+このワークショップには、いくつかの REST エンドポイントを持つシンプルな Spring Boot アプリケーションが含まれています。まずはこれをビルドしましょう。
+
+## Java と Maven の確認
+
+インスタンスには OpenJDK 17 と Maven がプリインストールされています。以下のコマンドで確認します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+java -version && mvn -version
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+openjdk version "17.0.x" ...
+Apache Maven 3.x.x ...
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## アプリケーションのビルド
+
+ワークショップアプリのディレクトリに移動し、fat JAR をビルドします。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+cd ~/workshop/appd/app
+mvn package -DskipTests
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+[INFO] BUILD SUCCESS
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+{{% notice title="初回ビルド" style="info" icon="info-circle" %}}
+最初の `mvn package` 実行時には Spring Boot の依存関係をダウンロードします。この処理には 30〜60 秒ほどかかります。2 回目以降のビルドは大幅に高速になります。
+{{% /notice %}}
+
+## アプリケーションのテスト（AppD なし）
+
+アプリが起動することを確認するため、短時間実行します。
+
+```bash
+java -jar target/ingest-workshop-1.0.0.jar &
+```
+
+数秒待ってから return キーを押してプロンプトに戻り、以下のコマンドでテストします。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+curl -s localhost:8080/health | jq .
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```json
+{
+ "status": "healthy"
+}
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+次に進む前に、アプリを停止します。
+
+```bash
+kill %1
+```
+
+アプリケーションが正常に動作することを確認できました。次に、このプロセスにアタッチするための AppDynamics Java Agent をダウンロードします。
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md
new file mode 100644
index 0000000000..ffeefbcc52
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md
@@ -0,0 +1,32 @@
+---
+title: 2. AppD エージェントのダウンロード
+weight: 2
+---
+
+dual signal モードを使用するには、AppDynamics Java Agent (バージョン 25.6.0 以上) が必要です。これをインスタンスに追加します。
+
+## エージェントの解凍
+
+インスタンスに SSH 接続してダウンロードスクリプトを実行すると、先ほど作成した `agent` ディレクトリにエージェントが展開されます。
+
+```bash
+cd ~/workshop/appd
+mkdir -p agent
+chmod +x ./download-appd-agent.sh
+./download-appd-agent.sh
+```
+
+これで `~/workshop/appd/agent/javaagent.jar` にエージェントの 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 で次のように確認できます。
+
+1. 画面右上の自分の名前をクリックします
+2. **Admin** → **License** に移動します
+3. 左側のサイドバーで **Account** をクリックします
+4. **Account** の下にある **Name** (`se-lab`) と **Access Key** を控えておきます
+
+{{% notice title="手元に控えておきましょう" style="primary" icon="lightbulb" %}}
+次のステップで Account Name と Access Key を JVM プロパティとして使用します。これらはエージェントを Controller に認証させるために使われます。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/3-run-and-verify.md b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/3-run-and-verify.md
new file mode 100644
index 0000000000..b4e4044c37
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/3-run-and-verify.md
@@ -0,0 +1,98 @@
+---
+title: 3. AppD で実行して検証
+weight: 3
+---
+
+ここでは AppDynamics エージェントをアタッチした状態でアプリケーションを実行します。これは「通常」のシングル宛先計装です。
+
+## AppDynamics エージェントで実行する
+
+`` を前のステップで取得した AppDynamics トークンに置き換えてください。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+環境変数をエクスポートします
+
+```bash
+export APPD_ACCESS_KEY=
+```
+
+および
+
+```bash
+export APPD_APP_NAME=Dual-Ingest-${INSTANCE}
+```
+
+その後、エージェント付きで java を起動できます。
+
+```bash
+cd ~/workshop/appd
+
+java -javaagent:agent/javaagent.jar \
+ -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com \
+ -Dappdynamics.controller.port=443 \
+ -Dappdynamics.controller.ssl.enabled=true \
+ -Dappdynamics.agent.applicationName=${APPD_APP_NAME} \
+ -Dappdynamics.agent.tierName=OrderService \
+ -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 &
+```
+
+{{% /tab %}}
+{{% tab title="Example" %}}
+
+```text
+java -javaagent:agent/javaagent.jar \
+ -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com \
+ -Dappdynamics.controller.port=443 \
+ -Dappdynamics.controller.ssl.enabled=true \
+ -Dappdynamics.agent.applicationName=Dual-Ingest-shw-4267 \
+ -Dappdynamics.agent.tierName=OrderService \
+ -Dappdynamics.agent.nodeName=OrderService-Node \
+ -Dappdynamics.agent.accountName=se-lab \
+ -Dappdynamics.agent.accountAccessKey="hj9999999999" \
+ -jar app/target/ingest-workshop-1.0.0.jar &
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+Spring Boot の起動バナーが表示されるまで待ちます (約 10〜15 秒)。
+Enter キーを押してプロンプトに戻ります。
+
+## 負荷を生成する
+
+シンプルな負荷生成スクリプトをバックグラウンドで起動します。
+
+```bash
+while true; do
+ curl -s localhost:8080/order > /dev/null
+ curl -s localhost:8080/inventory > /dev/null
+ sleep 2
+done &
+```
+
+## AppDynamics Controller で検証する
+
+1. [AppDynamics Controller](https://se-lab.saas.appdynamics.com/controller/) を開きます
+2. **Applications** に移動して自分のアプリケーション (例: `Dual-Ingest-`) を見つけます
+3. アプリケーションをクリックして **Flow Map** を表示します
+
+{{% notice title="しばらくお待ちください" style="info" icon="info-circle" %}}
+アプリケーションが登録され、ビジネストランザクションがフローマップに表示されるまで 2〜5 分かかる場合があります。必要に応じてページを更新してください。
+{{% /notice %}}
+
+以下が表示されるはずです。
+
+- フローマップ上の **OrderService** ティア
+- `/order` および `/inventory` エンドポイントのビジネストランザクション
+- Controller に流れ込むメトリックデータ
+
+この時点では、データは **AppDynamics のみ** に流れています。アプリケーションは Splunk Observability Cloud に接続されていません。次のフェーズでは、デュアルシグナルモードを有効にしてこれを変更します。
+
+
+{{% notice title="実行を継続してください" style="warning" icon="exclamation-triangle" %}}
+アプリケーションと負荷生成スクリプトは起動したままにしておいてください。次のセクションでデュアルモードフラグを追加するために停止します。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/_index.md
new file mode 100644
index 0000000000..e860394fc2
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/2-run-with-appd/_index.md
@@ -0,0 +1,12 @@
+---
+title: "Phase 1: Run with AppDynamics"
+linkTitle: 2. Run with AppD
+weight: 2
+archetype: chapter
+time: 15 minutes
+description: ワークショップアプリをビルドし、AppDynamics Java Agentをダウンロードしてサービスを実行し、AppDynamics Controllerにデータが表示されることを確認します。
+---
+
+このフェーズでは、シンプルなJavaアプリケーションをビルドし、AppDynamics Java Agentをアタッチして、APMデータがAppDynamics Controllerに表示されることを確認します。
+
+これは、現在ほとんどのAppDynamicsのお客様が利用している「通常」の単一宛先への計装方法です。
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md
new file mode 100644
index 0000000000..8fad5a4adb
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md
@@ -0,0 +1,161 @@
+---
+title: 1. OTel Collector のインストール
+weight: 1
+---
+
+dual モードの AppDynamics エージェントは OpenTelemetry データを OTLP で出力します。そのデータを受信して Splunk Observability Cloud に転送するため、同じホスト上にコレクターが必要です。
+
+## 環境変数の確認
+
+インスタンスにはこれらの変数があらかじめ設定されているはずです。`env` または以下のコマンドで利用可能であることを確認してください。
+
+```bash
+echo "REALM=$REALM"
+echo "ACCESS_TOKEN=$ACCESS_TOKEN"
+echo "INSTANCE=$INSTANCE"
+```
+
+3 つすべてに値が設定されている必要があります。いずれかが空の場合は、講師に確認してください。
+
+## Splunk OpenTelemetry Collector のインストール
+
+Splunk OTel Collector のインストールスクリプトを実行します。これによりコレクターが `systemd` サービスとしてインストールされます。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh && \
+ sudo sh /tmp/splunk-otel-collector.sh --realm $REALM --deployment-environment ${INSTANCE}-appd-dual --hec-token ${HEC_TOKEN} --hec-url ${HEC_URL} -- $ACCESS_TOKEN
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+Splunk OpenTelemetry Collector has been successfully installed.
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+ここでは `--deployment-environment` で環境を、`--hec-token` と `--hec-url` で HEC ログエクスポートの詳細を確実に渡しています。これはログを取得して相関させるために重要です。
+
+## Workshop 用 Collector 設定の適用
+
+デフォルトのコレクター設定は汎用的なものです。これを、AppDynamics エージェントから OTLP を受信し Splunk Observability Cloud にエクスポートするワークショップ専用の設定に置き換えます。その前に、何を追加するのか見てみましょう。
+
+```bash
+vim ~/workshop/appd/collector-config.yaml
+```
+
+`processors:` の下にある以下のセクションを探してください。
+{{< tabs >}}
+{{% tab title="collector-config.yaml" %}}
+
+```yaml
+ transform/drop_dims_high_cardinality:
+ error_mode: ignore
+ metric_statements:
+ - context: resource
+ conditions:
+ - Len(resource.attributes) + Len(attributes) > 34
+ statements:
+ # Delete from datapoint attributes (where the Java agent puts them)
+ - delete_key(attributes, "process.command_args") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "process.executable.path") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "process.runtime.description") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "process.runtime.name") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "process.runtime.version") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "process.pid") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "os.description") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "os.version") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "host.arch") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "host.image.id") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "telemetry.distro.name") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "telemetry.distro.version") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "telemetry.sdk.version") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "telemetry.sdk.name") where Len(resource.attributes) + Len(attributes) >= 34
+ - delete_key(attributes, "telemetry.sdk.language") where Len(resource.attributes) + Len(attributes) >= 34
+
+ # Add marker
+ - set(resource.attributes["cardinality.trimmed"], "true")
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+`transform/drop_dims_high_cardinality` プロセッサーは [OpenTelemetry Transformation Language (OTTL)](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/LANGUAGE.md) を使用して、属性が 34 を超えるメトリクスがないかチェックします（メトリクスにアタッチされた実際の値も 1 ポイントとしてカウントされます）。
+
+- **重要: 現在、属性が多すぎる（>36）メトリクスはバックエンドでドロップされます。** これは追加の属性により AppDynamics のテレメトリーで発生する可能性があります。
+
+`transform` 設定では、メトリクスの属性数の合計が 34 を超えるかをチェックし、超えている場合は重要度の低い属性を順次削除しています。
+最後に、削除された属性を持つメトリクスを簡単に識別できるよう、空きがあれば `cardinality.trimmed` のディメンションを追加するチェックを行います。
+
+これらのプロセッサーはそれぞれ、設定内のメトリクス用 `pipeline:` の末尾に組み込まれています。
+
+次に、このカスタム設定を `agent_config.yaml` に上書きコピーします。
+
+```bash
+sudo cp ~/workshop/appd/collector-config.yaml /etc/otel/collector/agent_config.yaml
+```
+
+## Collector の再起動
+
+新しい設定を反映させるために再起動します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+sudo systemctl restart splunk-otel-collector
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Collector が稼働していることの確認
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+sudo systemctl status splunk-otel-collector --no-pager
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+● splunk-otel-collector.service - Splunk OpenTelemetry Collector
+ Loaded: loaded (/lib/systemd/system/splunk-otel-collector.service; enabled)
+ Active: active (running) since ...
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+ヘルスエンドポイントを確認します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+curl -s http://localhost:13133/ | jq
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+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 >}}
+
+これでコレクターはポート **4317**（gRPC）および **4318**（HTTP）で OTLP をリッスンするようになりました。
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md
new file mode 100644
index 0000000000..df5acb222c
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md
@@ -0,0 +1,96 @@
+---
+title: 2. デュアルモードを有効化する
+weight: 2
+---
+
+JVMコマンドラインにデュアルシグナルモードのフラグを追加して、アプリケーションを再起動します。
+
+## 実行中のアプリケーションを停止する
+
+Phase 1 のアプリと負荷生成プロセスを停止します:
+
+```bash
+kill %2 2>/dev/null # stop load generator
+kill %1 2>/dev/null # stop the java app
+```
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+`kill %1` がうまくいかない場合は、`ps aux | grep ingest-workshop` で PID を確認し、直接 kill してください。
+{{% /notice %}}
+
+## デュアルモードで再起動する
+
+同じ AppD のフラグに加え、デュアルモードと OTel エクスポーターのフラグを指定してアプリを再度実行します。Phase 1 で使用した値と同じ `${APPD_ACCESS_KEY}` および `${APPD_APP_NAME}` の変数をそのまま利用します:
+
+アプリケーション起動行 `-jar app/target/ingest-workshop-1.0.0.jar &` の直前に 4 行を追加します。
+
+```bash
+cd ~/workshop/appd
+
+java -javaagent:agent/javaagent.jar \
+ -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com \
+ -Dappdynamics.controller.port=443 \
+ -Dappdynamics.controller.ssl.enabled=true \
+ -Dappdynamics.agent.applicationName=${APPD_APP_NAME} \
+ -Dappdynamics.agent.tierName=OrderService \
+ -Dappdynamics.agent.nodeName=OrderService-Node \
+ -Dappdynamics.agent.accountName=se-lab \
+ -Dappdynamics.agent.accountAccessKey=${APPD_ACCESS_KEY} \
+ -Dagent.deployment.mode=dual \
+ -Dotel.traces.exporter=otlp \
+ -Dotel.exporter.otlp.endpoint=http://localhost:4318 \
+ -Dotel.resource.attributes=service.name=OrderService,service.namespace=Dual-Ingest-${INSTANCE},deployment.environment=${INSTANCE}-appd-dual,deployment.environment.name=${INSTANCE}-appd-dual \
+ -jar app/target/ingest-workshop-1.0.0.jar &
+```
+
+Spring Boot の起動バナーが表示されるまで待機します。
+return キーを押してプロンプトに戻ります。
+
+### 新しく追加したフラグの役割
+
+| フラグ | 目的 |
+|---|---|
+| `-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`/`deployment.environment.name` はワークショップのインスタンス向けにデータをタグ付けします |
+
+## 負荷生成プロセスを再起動する
+
+```bash
+while true; do
+ curl -s localhost:8080/order > /dev/null
+ curl -s localhost:8080/inventory > /dev/null
+ sleep 2
+done &
+```
+
+## デュアルモードが有効化されていることを確認する
+
+アプリケーションログでデュアルモードが起動したことを確認します:
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+ps aux | grep "deployment.mode=dual"
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+splunk@ip-172-31-77-108 ~/workshop/appd $ ps aux | grep "deployment.mode=dual" | grep -v grep
+splunk 181598 172 2.1 14402900 717736 pts/0 SNl 21:31 1:02 java -javaagent:agent/javaagent.jar -Dappdynamics.controller.hostName=se-lab.saas.appdynamics.com -Dappdynamics.controller.port=443 -Dappdynamics.controller.ssl.enabled=true -Dappdynamics.agent.applicationName=Dual-Ingest-shw-1123 -Dappdynamics.agent.tierName=OrderService -Dappdynamics.agent.nodeName=OrderService-Node -Dappdynamics.agent.accountName=se-lab -Dappdynamics.agent.accountAccessKey=hj9999999999 -Dagent.deployment.mode=dual -Dotel.traces.exporter=otlp -Dotel.exporter.otlp.endpoint=http://localhost:4318 -Dotel.resource.attributes=service.name=OrderService,service.namespace=Dual-Ingest-shw-a79e,deployment.environment=shw-a79e-appd-dual -jar app/target/ingest-workshop-1.0.0.jar
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+`deployment.mode=dual` フラグが付与された java プロセスが確認できるはずです。
+
+これで AppDynamics エージェントは以下を送信しています:
+
+- **AppD APM データ** を AppDynamics Controller へ送信 (変更なし)
+- **OTLP トレース** を `localhost:4318` のローカル OTel Collector へ送信し、そこから Splunk Observability Cloud へ転送
+ - 自分のインスタンスで `env` を実行すると、環境で使用されている `{INSTANCE}` の値が確認できます (`deployment.environment=${INSTANCE}-appd-dual`)
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md
new file mode 100644
index 0000000000..3fe9a8b295
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md
@@ -0,0 +1,57 @@
+---
+title: 3. 両プラットフォームで確認する
+weight: 3
+---
+
+デュアルモードが有効になり負荷が流れている状態で、トレースは数分以内に Splunk Observability Cloud に到着しているはずです。両方の宛先を確認しましょう。
+
+## AppDynamics の確認（変更なし）
+
+[AppDynamics Controller](https://se-lab.saas.appdynamics.com/controller/) に戻ってアプリケーションを開き、以下を確認します。
+
+- **OrderService** ティアが引き続きフローマップに表示されている
+- `/order` および `/inventory` のビジネストランザクションが引き続き記録されている
+- デュアルモードを追加したことによるエラーや性能劣化がない
+
+デュアルモードは AppDynamics のデータ収集に影響を与えないはずです。両方のストリームは独立して動作します。
+
+## Splunk Observability Cloud の確認
+
+1. [Splunk Observability Cloud](https://app.signalfx.com) に移動し、講師から提供された資格情報でログインします。
+2. 左側のナビゲーションパネルで **APM** をクリックします。
+3. **Environment** ドロップダウンで `-appd-dual` を選択します（これはリソース属性で設定した `deployment.environment` の値と一致します）。
+
+
+{{% notice title="数分待ちましょう" style="info" icon="info-circle" %}}
+デュアルモードを有効にしてからトレースが表示されるまで 2〜5 分かかることがあります。サービスがまだ表示されない場合は、少し待ってからページを更新してください。
+{{% /notice %}}
+
+1. サービスリストに **OrderService** が表示されているはずです。
+
+## トレースを探索する
+
+1. **OrderService** サービスをクリックします。
+2. **Traces** をクリックして個々のトレースを表示します。
+3. `GET /order` のトレースを選択して、トレース詳細のウォーターフォールを開きます。
+
+トレースウォーターフォールには、OTel Java 自動計装によって生成されたスパンが表示されます。これらは AppDynamics も監視しているのと同じリクエストです。
+
+
+## AppDynamics 相関属性を確認する
+
+**ルートスパン** をクリックしてスパン属性を確認します。AppDynamics の相関属性が表示されているはずです。
+
+| 属性 | 値の例 |
+|---|---|
+| `appd.app.name` | `Dual-Ingest-YOURINITIALS` |
+| `appd.tier.name` | `OrderService` |
+| `appd.bt.name` | `/order` または `/inventory` |
+| `appd.request.guid` | *(AppDynamics リクエスト GUID)* |
+
+これらの属性は、デュアルモードの AppDynamics エージェントによって自動的に追加されます。これらにより、この OTel トレースと AppDynamics Controller 内の対応するデータの間に直接的なリンクが作成されます。
+
+{{% notice title="重要なポイント" style="primary" icon="lightbulb" %}}
+`appd.tier.name` 属性は、ティアが変わるたびにトレースの中間にあるスパンにも付与されます。マルチティアアプリケーションでは、各スパンが正しい AppDynamics ティアの識別子を保持します。
+{{% /notice %}}
+
+これで、同じアプリケーションが単一のエージェントから **2 つのプラットフォームに同時に** APM データを送信するようになりました。次のセクションでは、グローバルデータリンクを作成することで両者を接続します。
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/_index.md
new file mode 100644
index 0000000000..d74c31b835
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/3-enable-dual-mode/_index.md
@@ -0,0 +1,12 @@
+---
+title: "Phase 2: Enable Dual Signal Mode"
+linkTitle: 3. デュアルモードの有効化
+weight: 3
+archetype: chapter
+time: 15 minutes
+description: OpenTelemetry Collector をインストールし、AppDynamics エージェントでデュアルシグナルモードを有効化して、AppDynamics と Splunk Observability Cloud の両方にトレースが表示されることを確認します。
+---
+
+このフェーズでは、Splunk Observability Cloud にデータを転送するための OpenTelemetry Collector をデプロイし、デュアルシグナルモードを有効化した状態でアプリケーションを再起動します。
+
+これまで AppDynamics のみにデータを送信していた同じエージェントが、両方の宛先に同時に送信するようになります。
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/4-global-data-links/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/4-global-data-links/_index.md
new file mode 100644
index 0000000000..748654842a
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/4-global-data-links/_index.md
@@ -0,0 +1,77 @@
+---
+title: "Phase 3: Global Data Links"
+linkTitle: 4. Global Data Links
+weight: 4
+archetype: chapter
+time: 10 minutes
+description: appd.* スパン属性を使用して、対応する AppDynamics の tier ビューに直接遷移する global data link を Splunk Observability Cloud に作成します。
+---
+
+{{% notice title="NOTICE" style="primary" icon="lightbulb" %}}
+グループワークショップに参加している場合は、インストラクターの操作を確認するだけにとどめ、追加の global data link を作成しないでください。
+このセクションをご自身で完了する必要はありません。手順は学習目的とドキュメント目的で記載されています。
+ご協力ありがとうございます。
+{{% /notice %}}
+
+トレース上の `appd.*` 属性は単なるメタデータではありません。これらは **global data links** を実現するための情報源となり、Splunk Observability Cloud でトレースを閲覧している人なら誰でも、対応する AppDynamics のビューにワンクリックで直接ジャンプできるようにします。
+
+## Global Data Links とは
+
+Global data links は Splunk Observability Cloud の機能で、スパン属性、タグ値、メトリクスのディメンションに対してクリック可能なリンクを作成します。ユーザーがリンクされた値をクリックすると、定義した外部 URL に遷移し、URL テンプレートには実際の属性値が代入されます。
+
+### Data Link の前提条件
+
+AppDynamics 内のアプリケーションへの URL をコピーします。アプリケーションを識別する URL の重要な部分は、URL のクエリパラメーターです（例： `&application=99999`）。
+application クエリパラメーターを含む完全な URL を使用して global data link を構築します。
+
+
+## Global Data Link の作成
+
+1. Splunk Observability Cloud で、左側のナビゲーションパネルにある **Settings**（歯車アイコン）をクリックします。
+2. **Global Data Links** をクリックします。
+3. **New Link** をクリックします。
+4. リンクを設定します。
+
+| Field | Value |
+| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Link Label** | `Open in AppDynamics` |
+| **Link to** | `Custom URL` |
+| **Show on** | `Property:Value pair` - `appd.app.name:` を選択（例： `appd.app.name:Dual-Ingest-JRH`） |
+| **URL** | `https://se-lab.saas.appdynamics.com/controller/#/location=APP_DASHBOARD&timeRange=Custom_Time_Range.BETWEEN_TIMES.{{ end_time }}.{{ start_time }}.6&application=&dashboardMode=force` |
+| **Time format** | `Unix time: epoch milliseconds` |
+| **Minimum trigger** | `appd.tier.name` |
+
+{{% notice title="URL Template Syntax" style="primary" icon="lightbulb" %}}
+二重中括弧の `{{ end_time }}` および `{{ start_time }}` はテンプレート変数です。Splunk Observability Cloud は、クリック時にこれらを実際の値に置き換えます。
+
+`` は、特定のアプリケーションのクエリパラメーターから取得した番号です。
+{{% /notice %}}
+
+
+1. **Save** をクリックします。
+
+## Global Data Link のテスト
+
+1. **APM** に戻り、**OrderService** サービスのトレースを開きます。
+2. ルートスパンをクリックして、その属性を表示します。
+3. 属性リストから `appd.app.name` を見つけます。**Open in AppDynamics** とラベル付けされたクリック可能なリンクになっているはずです。
+4. リンクをクリックします。新しいブラウザタブが開き、AppDynamics Controller の **OrderService** アプリケーションビューに直接遷移します。
+
+
+{{% notice title="Note" style="info" icon="info-circle" %}}
+リンクが機能するためには、同じブラウザで AppDynamics Controller にログインしている必要があります。ログインを求められた場合は、Cisco の認証情報を使用してください。
+{{% /notice %}}
+
+## 逆方向のナビゲーション（AppD から Splunk へ）
+
+逆方向のナビゲーションも可能です。dual モードでキャプチャされた AppDynamics スナップショットには、**Data Collectors** タブの下に OTel の `TraceId` が含まれます。
+
+Splunk Observability Cloud で対応するトレースを見つけるには、以下を行います。
+
+1. AppDynamics Controller で、ビジネストランザクションの **Transaction Snapshot** を開きます。
+2. **Data Collectors** タブに移動します。
+3. `TraceId` の値を見つけます。
+4. Splunk Observability Cloud で **APM → Traces** に移動し、そのトレース ID を検索します。
+
+これにより、両プラットフォーム間の **双方向の関連付け** が可能になります。
+
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/5-wrap-up/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/5-wrap-up/_index.md
new file mode 100644
index 0000000000..4ecee4f1cd
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/5-wrap-up/_index.md
@@ -0,0 +1,52 @@
+---
+title: Wrap Up
+linkTitle: 5. Wrap Up
+weight: 5
+archetype: chapter
+time: 5 minutes
+description: まとめ、クリーンアップ、次のステップ。
+---
+
+## 達成したこと
+
+このワークショップでは、以下を行いました。
+
+1. **通常の AppDynamics インストルメンテーションで Java サービスをビルドして実行**: APM データを AppDynamics Controller のみに送信する単一エージェントを使用しました。
+
+2. **hybrid モードと dual signal モードの違いを理解**: hybrid は AppD 自身のインストルメンテーションを再利用して OTel スパンを生成します（オーバーヘッドが低く、カバー範囲は狭い）。一方、dual は AppD と並行して OTel Java auto-instrumentation の全機能を実行します（カバー範囲が広く、相関属性が追加されます）。
+
+3. **dual signal モードを有効化**: 同一プロセスに 4 つの JVM フラグを追加するだけで実現しました。コード変更も、2 つ目のエージェントも、再コンパイルも不要です。同じ AppDynamics エージェントが、AppDynamics と Splunk Observability Cloud の両方に同時にデータを送信できるようになりました。
+
+4. **Global data link を作成**: Splunk Observability Cloud で `appd.*` スパン属性を使用し、対応する AppDynamics tier ビューに直接遷移できるようにしました。
+
+## クリーンアップ
+
+アプリケーションと負荷生成ツールを停止します。
+
+```bash
+kill %2 2>/dev/null # load generator
+kill %1 2>/dev/null # java app
+```
+
+必要に応じて collector を停止します。
+
+```bash
+sudo systemctl stop splunk-otel-collector
+```
+
+## 重要なポイント
+
+- **dual モードはコード変更ではなく、設定変更です。** すでにインストルメント済みのアプリケーションに JVM フラグを追加するだけで有効化できました。これにより、アプリケーションコードに手を加えることなく、組織全体への展開が現実的になります。
+
+- **`appd.*` 相関属性こそが、この統合に価値をもたらします。** これらが無い場合（hybrid モード）、Splunk O11y で OTel トレースは取得できますが、特定の AppDynamics ビジネストランザクション、tier、アプリケーションに紐付ける手段がありません。dual モードはその紐付けを提供します。
+
+- **Global data link は相関をワークフローへと変換します。** 2 つのツールを手作業で相互参照する代わりに、エンジニアは Splunk O11y のトレースから AppDynamics のビューに直接クリックで移動できます。
+
+- **このパターンは段階的な移行を可能にします。** 組織は一定期間 dual モードを実行することで、Splunk Observability Cloud が同等のシグナル品質を捕捉していることを検証できます。その後、サービスごとに dual を継続するか、Splunk のみのインストルメンテーションに切り替えるか、AppDynamics に留まるかを判断できます。
+
+## 参考情報
+
+- [Enable Dual Signal Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-dual-signal-mode) (AppDynamics ドキュメント)
+- [Enable Hybrid Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-hybrid-mode) (AppDynamics ドキュメント)
+- [Java Agent Frameworks for OpenTelemetry](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/support-for-appdynamics-for-opentelemetry/java-agent-frameworks-for-opentelemetry) (サポート対象フレームワーク一覧)
+- [Global Data Links](https://docs.splunk.com/observability/en/data-visualization/navigate-with-data-links.html) (Splunk Observability ドキュメント)
diff --git a/content/ja/ninja-workshops/apm/17-appd-ingest/_index.md b/content/ja/ninja-workshops/apm/17-appd-ingest/_index.md
new file mode 100644
index 0000000000..3321fa2dc5
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/17-appd-ingest/_index.md
@@ -0,0 +1,15 @@
+---
+draft: false
+hidden: false
+title: AppDynamics Dual Ingest to Splunk Observability
+linkTitle: AppD Dual Ingest
+weight: 17
+archetype: chapter
+time: 45 minutes
+authors: ["Jeremy Hicks"]
+description: 単一の AppDynamics Java Agent から AppDynamics と Splunk Observability Cloud の両方に APM データをストリーミングし、グローバルデータリンクで両者を連携します。
+aliases:
+ - /ninja-workshops/17-appd-ingest/
+---
+
+AppDynamics Java エージェントを使った Dual Ingest について、AppDynamics と Splunk Observability Cloud の両方にデータを送信する方法を学びます。
diff --git a/content/ja/ninja-workshops/apm/_index.md b/content/ja/ninja-workshops/apm/_index.md
new file mode 100644
index 0000000000..1aa1378962
--- /dev/null
+++ b/content/ja/ninja-workshops/apm/_index.md
@@ -0,0 +1,9 @@
+---
+title: APM & AppDynamics
+linkTitle: APM
+weight: 4
+description: Splunk AppDynamics の詳細解説と Observability Cloud へのデュアル取り込みを扱います。
+time: 2 hours 15 minutes
+layout: "hero"
+---
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md
new file mode 100644
index 0000000000..c22b6b3a0d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md
@@ -0,0 +1,76 @@
+---
+title: OpenTelemetry Collector のインストール
+linkTitle: 1. OpenTelemetry Collector
+weight: 1
+---
+
+Splunk OpenTelemetry Collector は、インフラストラクチャとアプリケーションを計装するためのコアコンポーネントです。その役割は、以下のデータを収集して送信することです。
+
+* インフラストラクチャメトリクス（disk、CPU、memory など）
+* Application Performance Monitoring（APM）トレース
+* プロファイリングデータ
+* ホストおよびアプリケーションログ
+
+{{% notice title="既存の OpenTelemetry Collector を削除する" style="warning" %}}
+Splunk IM ワークショップを完了している場合は、続行する前に Kubernetes 上で動作している collector を削除しておいてください。以下のコマンドを実行することで削除できます。
+
+``` bash
+helm delete splunk-otel-collector
+```
+
+EC2 インスタンスには、すでに古いバージョンの collector がインストールされている可能性があります。collector をアンインストールするには、以下のコマンドを実行してください。
+
+``` bash
+curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh
+sudo sh /tmp/splunk-otel-collector.sh --uninstall
+```
+
+{{% /notice %}}
+
+インスタンスが正しく構成されていることを確認するため、このワークショップで必要となる環境変数が正しく設定されているかを確認する必要があります。ターミナルで以下のコマンドを実行してください。
+
+``` bash
+. ~/workshop/petclinic/scripts/check_env.sh
+```
+
+出力結果で、以下のすべての環境変数が存在し、値が設定されていることを確認してください。不足しているものがある場合は、講師にお問い合わせください。
+
+```text
+ACCESS_TOKEN
+REALM
+RUM_TOKEN
+HEC_TOKEN
+HEC_URL
+INSTANCE
+```
+
+確認できたら、Collector をインストールできます。インストールスクリプトには、いくつかの追加パラメーターが渡されます。
+
+* `--with-instrumentation` - Splunk distribution of OpenTelemetry Java からエージェントをインストールします。これは PetClinic の Java アプリケーション起動時に自動的に読み込まれます。設定は不要です！
+* `--deployment-environment` - リソース属性 `deployment.environment` に渡された値を設定します。これは UI でビューをフィルタリングするために使用されます。
+* `--enable-profiler` - Java アプリケーション用のプロファイラーを有効化します。これにより、アプリケーションの CPU プロファイルが生成されます。
+* `--enable-profiler-memory` - Java アプリケーション用のプロファイラーを有効化します。これにより、アプリケーションのメモリプロファイルが生成されます。
+* `--enable-metrics` - Micrometer メトリクスのエクスポートを有効化します。
+* `--hec-token` - collector が使用する HEC トークンを設定します。
+* `--hec-url` - collector が使用する HEC URL を設定します。
+
+``` bash
+curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh && \
+sudo sh /tmp/splunk-otel-collector.sh --realm $REALM -- $ACCESS_TOKEN --mode agent --with-instrumentation --deployment-environment $INSTANCE-petclinic --enable-profiler --enable-profiler-memory --enable-metrics --hec-token $HEC_TOKEN --hec-url $HEC_URL
+```
+
+次に、AWS インスタンス ID ではなくインスタンスのホスト名を公開するように、collector にパッチを当てます。これにより、UI でデータをフィルタリングしやすくなります。
+
+``` bash
+sudo sed -i 's/gcp, ecs, ec2, azure, system/system, gcp, ecs, ec2, azure/g' /etc/otel/collector/agent_config.yaml
+```
+
+`agent_config.yaml` にパッチを当てたら、collector を再起動する必要があります。
+
+``` bash
+sudo systemctl restart splunk-otel-collector
+```
+
+インストールが完了すると、**Hosts with agent installed** ダッシュボードに移動して、ホストからのデータを確認できます。**Dashboards → Hosts with agent installed** の順に進んでください。
+
+フィルターパネルの「Host」フィールド内をクリックし、ワークショップインスタンスのホスト名を入力または選択します（ホスト名はターミナルセッションのコマンドプロンプトから取得できます）。ホストのデータが流れていることを確認できたら、APM コンポーネントを開始する準備が整いました。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md
new file mode 100644
index 0000000000..f697833191
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md
@@ -0,0 +1,55 @@
+---
+title: Spring PetClinic アプリケーションのビルド
+linkTitle: 2. PetClinic のビルド
+weight: 2
+---
+
+APM をセットアップするためにまず必要なものは…そう、アプリケーションです。この演習では、Spring PetClinic アプリケーションを使用します。これは Spring framework（Spring Boot 経由）で構築された、非常によく使われる Java のサンプルアプリケーションです。
+
+まず、Spring PetClinic の GitHub リポジトリをクローンします。後ほど、アプリケーションのコンパイル、ビルド、パッケージング、テストを行います。
+
+```bash
+git clone https://github.com/spring-projects/spring-petclinic
+```
+
+`spring-petclinic` ディレクトリに移動します。
+
+
+
+```bash
+cd spring-petclinic
+git checkout b26f235250627a235a2974a22f2317dbef27338d
+```
+
+Docker を使用して、PetClinic が利用する MySQL データベースを起動します。
+
+```bash
+docker run -d -e MYSQL_USER=petclinic -e MYSQL_PASSWORD=petclinic -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=petclinic -p 3306:3306 docker.io/biarms/mysql:5.7
+```
+
+次に、Spring PetClinic アプリケーションに対してトラフィックを生成するため、Locust を実行する別のコンテナを起動します。Locust はシンプルな負荷テストツールです。
+
+```bash
+docker run --network="host" -d -p 8090:8090 -v ~/workshop/petclinic:/mnt/locust docker.io/locustio/locust -f /mnt/locust/locustfile.py --headless -u 1 -r 1 -H http://127.0.0.1:8083
+```
+
+続いて、`maven` を使用してアプリケーションをコンパイル、ビルド、パッケージングします。
+
+```bash
+./mvnw package -Dmaven.test.skip=true
+```
+
+> [!INFO]
+> このコマンドは、初回実行時にはアプリケーションをコンパイルする前に多くの依存関係をダウンロードするため、完了するまでに数分かかります。2 回目以降のビルドはより高速になります。
+
+ビルドが完了したら、実行中のインスタンスのパブリック IP アドレスを取得する必要があります。次のコマンドを実行することで取得できます。
+
+```bash
+curl http://ifconfig.me
+```
+
+このコマンドで返された IP アドレスは、アプリケーションが動作していることを確認するために必要となるため、メモしておいてください。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md
new file mode 100644
index 0000000000..eec7c4853c
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md
@@ -0,0 +1,64 @@
+---
+title: Java 向けの自動検出と自動構成
+linkTitle: 3. Automatic Discovery
+weight: 3
+---
+
+これで、以下のコマンドでアプリケーションを起動できます。アプリケーションには `mysql` プロファイルを渡している点に注意してください。これにより、アプリケーションは先ほど起動した MySQL データベースを使用するようになります。また、`otel.service.name` と `otel.resource.attributes` には、インスタンス名を使用した論理的な名前を設定しています。これらは UI でのフィルタリングにも使用されます。
+
+```bash
+java \
+-Dserver.port=8083 \
+-Dotel.service.name=$INSTANCE-petclinic-service \
+-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env \
+-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql
+```
+
+`http://:8083` にアクセスすると、アプリケーションが動作していることを確認できます（`` は先ほど取得した IP アドレスに置き換えてください）。
+
+Collector をインストールした際、**AlwaysOn Profiling** と **Metrics** を有効化するよう構成しました。これにより、Collector はアプリケーションの CPU およびメモリのプロファイルを自動的に生成し、Splunk Observability Cloud に送信します。
+
+PetClinic アプリケーションを起動すると、Collector がアプリケーションを自動的に検出し、トレースとプロファイリングのために計装する様子を確認できます。
+
+{{% tab title="Example output" %}}
+
+``` text {wrap="false"}
+Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/lib/splunk-instrumentation/splunk-otel-javaagent.jar
+OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
+[otel.javaagent 2024-08-20 11:35:58:970 +0000] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: splunk-2.6.0-otel-2.6.0
+[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - -----------------------
+[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - Profiler configuration:
+[otel.javaagent 2024-08-20 11:35:59:730 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.enabled : true
+[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.directory : /tmp
+[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.recording.duration : 20s
+[otel.javaagent 2024-08-20 11:35:59:731 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.keep-files : false
+[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.logs-endpoint : null
+[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - otel.exporter.otlp.endpoint : null
+[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.memory.enabled : true
+[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.memory.event.rate : 150/s
+[otel.javaagent 2024-08-20 11:35:59:732 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.call.stack.interval : PT10S
+[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.include.internal.stacks : false
+[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.tracing.stacks.only : false
+[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - -----------------------
+[otel.javaagent 2024-08-20 11:35:59:733 +0000] [main] INFO com.splunk.opentelemetry.profiler.JfrActivator - Profiler is active.
+```
+
+{{% /tab %}}
+
+ここで Splunk APM UI にアクセスし、アプリケーションコンポーネント、トレース、プロファイリング、DB Query Performance、メトリクスを確認できます。左側のメニューから **APM** をクリックし、**Environment** ドロップダウンをクリックして、自身の環境（例：`-petclinic`）を選択してください（`` は先ほど控えた値に置き換えます）。
+
+確認が完了したら、`Ctrl-c` を押してアプリケーションを停止できます。
+
+リソース属性は、レポートされる各スパンに追加できます。例えば `version=0.314` のように指定します。`key1=val1,key2=val2` のように、カンマ区切りでリソース属性のリストを定義することもできます。
+
+新しいリソース属性を使用して PetClinic を再度起動してみましょう。なお、実行コマンドにリソース属性を追加すると、Collector のインストール時に定義した内容を上書きする点に注意してください。新しいリソース属性 `version=0.314` を追加してみましょう。
+
+```bash
+java \
+-Dserver.port=8083 \
+-Dotel.service.name=$INSTANCE-petclinic-service \
+-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env,version=0.314 \
+-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql
+```
+
+Splunk APM UI に戻り、最近のトレースをドリルダウンすると、スパンに新しい `version` 属性が表示されていることを確認できます。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/4-rum.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/4-rum.md
new file mode 100644
index 0000000000..2931553b23
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/4-rum.md
@@ -0,0 +1,78 @@
+---
+title: 3. Real User Monitoring
+weight: 3
+---
+
+Real User Monitoring (RUM) のインストルメンテーションでは、Open Telemetry Javascript [**https://github.com/signalfx/splunk-otel-js-web**](https://github.com/signalfx/splunk-otel-js-web) のスニペットをページに追加します。再びウィザード **Data Management → Add Integration → RUM Instrumentation → Browser Instrumentation** を使用します。
+
+ドロップダウンから使用するトークンについてはインストラクターから案内があります。トークンを選択したら **Next** をクリックします。**App name** と **Environment** を以下の構文で入力してください。
+
+- `-petclinic-service` - `` は先ほどメモした値に置き換えてください。
+- `-petclinic-env` - `` は先ほどメモした値に置き換えてください。
+
+ウィザードでは、ページの `` セクション先頭に配置する HTML コードのスニペットが表示されます。以下はその例です（このスニペットは使用せず、ウィザードで生成されたものを使用してください）。
+
+``` html
+/*
+
+IMPORTANT: Replace the placeholder in the src URL with a
+version from https://github.com/signalfx/splunk-otel-js-web/releases
+
+*/
+
+
+```
+
+Spring PetClinic アプリケーションでは、単一の HTML ページを「レイアウト」ページとして使用しており、これがアプリケーションのすべてのページで再利用されています。Splunk RUM Instrumentation Library を挿入するには最適な場所であり、すべてのページで自動的に読み込まれます。
+
+それでは、レイアウトページを編集しましょう。
+
+```bash
+vi src/main/resources/templates/fragments/layout.html
+```
+
+次に、上で生成したスニペットをページの `` セクションに挿入します。コメント部分は含めないようにし、source URL の `` を `latest` に置き換えてください。例：
+
+```html
+
+
+
+
+
+
+...
+```
+
+コードの変更が完了したら、アプリケーションをリビルドして再度実行する必要があります。`maven` コマンドを実行して PetClinic をコンパイル/ビルド/パッケージ化します。
+
+```bash
+./mvnw package -Dmaven.test.skip=true
+```
+
+```bash
+java \
+-Dserver.port=8083 \
+-Dotel.service.name=$INSTANCE-petclinic-service \
+-Dotel.resource.attributes=deployment.environment=$INSTANCE-petclinic-env,version=0.314 \
+-jar target/spring-petclinic-*.jar --spring.profiles.active=mysql
+```
+
+次にブラウザで `http://:8083` にアクセスし、実ユーザーのトラフィックを生成します。
+
+RUM では、上記の RUM スニペットで定義した environment で絞り込み、ダッシュボードまでクリックして進みます。
+
+RUM トレースをドリルダウンすると、スパン内に APM へのリンクが表示されます。trace ID をクリックすると、現在の RUM トレースに対応する APM トレースに移動できます。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md
new file mode 100644
index 0000000000..6df314a2f0
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md
@@ -0,0 +1,24 @@
+---
+title: 4. Log Observer
+weight: 4
+---
+
+Splunk Log Observer コンポーネントについては、Splunk OpenTelemetry Collector が Spring PetClinic アプリケーションのログを自動的に収集し、OTLP エクスポーターを使用して Splunk Observability Cloud に送信します。その際、ログイベントには `trace_id`、`span_id` およびトレースフラグが付与されます。
+
+Log Observer は、アプリケーションやインフラストラクチャのログをリアルタイムで表示します。ログを検索、フィルタリング、分析することで、問題のトラブルシューティングや環境のモニタリングが可能です。
+
+PetClinic Web アプリケーションに戻り、**Error** リンクを数回クリックしてください。これにより、PetClinic アプリケーションのログにいくつかのログメッセージが生成されます。
+
+
+
+左側のメニューから **Log Observer** をクリックし、**Index** が **splunk4rookies-workshop** に設定されていることを確認します。
+
+次に、**Add Filter** をクリックして `service.name` フィールドを検索し、`-petclinic-service` の値を選択して `=`（include）をクリックします。これで、PetClinic アプリケーションのログメッセージのみが表示されるようになります。
+
+PetClinic アプリケーションで **Error** リンクをクリックして生成されたログエントリのいずれかを選択してください。ログメッセージと、ログメッセージに自動的に挿入されたトレースメタデータが表示されます。また、APM とインフラストラクチャの Related Content が利用可能であることがわかります。
+
+
+
+これでワークショップは終了です。ここまで非常に多くの内容を扱ってきました。この時点で、メトリクス、トレース（APM および RUM）、ログ、データベースクエリのパフォーマンス、コードプロファイリングが Splunk Observability Cloud にレポートされているはずです。しかも、PetClinic アプリケーションのコードを変更することなく実現できています（ただし RUM は例外です）。
+
+**おめでとうございます!**
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/_index.md
new file mode 100644
index 0000000000..54f6963ce0
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/1-petclinic-monolith/_index.md
@@ -0,0 +1,36 @@
+---
+title: PetClinic モノリスワークショップ
+weight: 1
+description: Spring PetClinic サンプルアプリケーションを用いて、Java アプリケーション向けの Splunk Observability Cloud の自動検出・自動設定機能を体験するハンズオンワークショップです。
+archetype: chapter
+authors: ["Robert Castley"]
+time: 30 minutes
+---
+
+このワークショップの目的は、**Splunk Observability Cloud** プラットフォームの以下のコンポーネントを設定する基本的な手順を一通り体験することです。
+
+* Splunk Infrastructure Monitoring (IM)
+* Splunk Automatic Discovery for Java (APM)
+ * Database Query Performance
+ * AlwaysOn Profiling
+* Splunk Real User Monitoring (RUM)
+* RUM to APM Correlation
+* Splunk Log Observer (LO)
+
+また、サンプルの Java アプリケーション (Spring PetClinic) のクローン (ダウンロード)、コンパイル、パッケージング、実行の手順も併せて確認します。
+
+アプリケーションが起動すると、**Splunk APM** で利用される Java 2.x 向けの **自動検出と自動設定 (automatic discovery and configuration)** によって、メトリクス、トレース、ログがすぐに確認できるようになります。
+
+その後、PetClinic のエンドユーザーインターフェース (アプリケーションがレンダリングする HTML ページ) を **Splunk OpenTelemetry Javascript Libraries (RUM)** で計装し、エンドユーザーが行うすべてのクリックやページロードに関する RUM トレースを生成します。
+
+最後に、PetClinic アプリケーションログにトレースメタデータが自動的に注入されることで生成されるログを確認します。
+
+{{% notice title="前提条件" style="primary" icon="info" %}}
+
+* ポート `2222` へのアウトバウンド SSH アクセス。
+* ポート `8083` へのアウトバウンド HTTP アクセス。
+* `bash` シェルおよび `vi/vim` エディタの基本的な操作に慣れていること。
+
+{{% /notice %}}
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md
new file mode 100644
index 0000000000..4f008a7189
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md
@@ -0,0 +1,18 @@
+---
+title: Architecture
+linkTitle: 1. アーキテクチャ
+weight: 2
+time: 5 minutes
+---
+
+Spring PetClinic Java アプリケーションは、フロントエンドサービスとバックエンドサービスで構成されるシンプルなマイクロサービスアプリケーションです。フロントエンドサービスは Spring Boot アプリケーションで、バックエンドサービスとやり取りするための Web インターフェイスを提供します。バックエンドサービスは Spring Boot アプリケーションで、MySQL データベースとやり取りするための RESTful API を提供します。
+
+このワークショップを完了するころには、Kubernetes 上で動作する Java ベースのアプリケーションに対して **automatic discovery and configuration** を有効化する方法について、より深く理解できるようになります。
+
+下図は、Splunk OpenTelemetry Operator と automatic discovery and configuration を有効化した状態で、Kubernetes 上で動作する Spring PetClinic Java アプリケーションのアーキテクチャを示しています。
+
+
+
+---
+
+**Josh Voravong** が作成した [**example**](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/examples/enable-operator-and-auto-instrumentation/spring-petclinic-java.md) をベースにしています。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md
new file mode 100644
index 0000000000..bf31267f7b
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md
@@ -0,0 +1,138 @@
+---
+
+title: Splunk OpenTelemetry Collector のデプロイ
+linkTitle: 1. OpenTelemetry Collector のデプロイ
+weight: 1
+---
+
+Observability シグナル（**メトリクス、トレース**、**ログ**）を **Splunk Observability Cloud** に取り込むには、Splunk OpenTelemetry Collector を Kubernetes クラスターにデプロイする必要があります。
+
+このワークショップでは、Splunk OpenTelemetry Collector Helm Chart を使用します。まず、Helm chart リポジトリを Helm に追加し、`helm repo update` を実行して最新バージョンを取得します。
+
+{{< tabs >}}
+{{% tab title="Install Helm Chart" %}}
+
+``` bash
+helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart && helm repo update
+```
+
+{{% /tab %}}
+{{% tab title="Output" %}}
+
+```text
+Using ACCESS_TOKEN={REDACTED}
+Using REALM=eu0
+"splunk-otel-collector-chart" has been added to your repositories
+Using ACCESS_TOKEN={REDACTED}
+Using REALM=eu0
+Hang tight while we grab the latest from your chart repositories...
+...Successfully got an update from the "splunk-otel-collector-chart" chart repository
+Update Complete. ⎈Happy Helming!⎈
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+**Splunk Observability Cloud** には、Kubernetes 上での OpenTelemetry Collector のセットアップを案内する UI ウィザードが用意されていますが、時間短縮のため、ここでは下記の Helm install コマンドを使用します。自動検出と設定、コードプロファイリングのために operator を有効化する追加パラメーターも設定しています。
+
+* `--set="operator.enabled=true"` - 自動検出と設定を扱う OpenTelemetry operator がインストールされます。
+* `--set="splunkObservability.profilingEnabled=true"` - operator 経由でコードプロファイリングを有効化します。
+
+Collector をインストールするには、以下のコマンドを実行します。**編集はしないでください**。
+
+{{< tabs >}}
+{{% tab title="Helm Install" %}}
+
+```bash
+helm install splunk-otel-collector --version {{< otel-version >}} \
+--set="operatorcrds.install=true", \
+--set="operator.enabled=true", \
+--set="splunkObservability.realm=$REALM" \
+--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
+--set="clusterName=$INSTANCE-k3s-cluster" \
+--set="splunkObservability.profilingEnabled=true" \
+--set="agent.service.enabled=true" \
+--set="environment=$INSTANCE-workshop" \
+--set="splunkPlatform.endpoint=$HEC_URL" \
+--set="splunkPlatform.token=$HEC_TOKEN" \
+--set="splunkPlatform.index=splunk4rookies-workshop" \
+splunk-otel-collector-chart/splunk-otel-collector \
+-f ~/workshop/k3s/otel-collector.yaml
+
+{{% /tab %}}
+{{% tab title="Output" %}}
+
+``` plaintext
+LAST DEPLOYED: Fri Apr 19 09:39:54 2024
+NAMESPACE: default
+STATUS: deployed
+REVISION: 1
+NOTES:
+Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Platform endpoint "https://http-inputs-o11y-workshop-eu0.splunkcloud.com:443/services/collector/event".
+
+Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm eu0.
+
+[INFO] You've enabled the operator's auto-instrumentation feature (operator.enabled=true)! The operator can automatically instrument Kubernetes hosted applications.
+ - Status: Instrumentation language maturity varies. See `operator.instrumentation.spec` and documentation for utilized instrumentation details.
+ - Splunk Support: We offer full support for Splunk distributions and best-effort support for native OpenTelemetry distributions of auto-instrumentation libraries.
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+次に進む前に、Pod が **Running** として報告されていることを確認してください（通常は約 30 秒かかります）。
+
+{{< tabs >}}
+{{% tab title="kubectl get pods" %}}
+
+``` bash
+kubectl get pods | grep splunk-otel
+```
+
+{{% /tab %}}
+{{% tab title="Output" %}}
+
+``` text
+splunk-otel-collector-k8s-cluster-receiver-6bd5567d95-5f8cj 1/1 Running 0 10m
+splunk-otel-collector-agent-tspd2 1/1 Running 0 10m
+splunk-otel-collector-operator-69d476cb7-j7zwd 2/2 Running 0 10m
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+Splunk OpenTelemetry Collector からエラーが報告されていないことを確認します（終了するには `ctrl + c` を押します）。あるいは、ボーナスポイントとしてインストール済みの **awesome** な `k9s` ターミナル UI を使用してみてください。
+
+{{< tabs >}}
+{{% tab title="kubectl logs" %}}
+
+``` bash
+kubectl logs -l app=splunk-otel-collector -f --container otel-collector
+```
+
+{{% /tab %}}
+{{% tab title="Output" %}}
+
+```text
+2021-03-21T16:11:10.900Z INFO service/service.go:364 Starting receivers...
+2021-03-21T16:11:10.900Z INFO builder/receivers_builder.go:70 Receiver is starting... {"component_kind": "receiver", "component_type": "prometheus", "component_name": "prometheus"}
+2021-03-21T16:11:11.009Z INFO builder/receivers_builder.go:75 Receiver started. {"component_kind": "receiver", "component_type": "prometheus", "component_name": "prometheus"}
+2021-03-21T16:11:11.009Z INFO builder/receivers_builder.go:70 Receiver is starting... {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"}
+2021-03-21T16:11:11.009Z INFO k8sclusterreceiver@v0.21.0/watcher.go:195 Configured Kubernetes MetadataExporter {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster", "exporter_name": "signalfx"}
+2021-03-21T16:11:11.009Z INFO builder/receivers_builder.go:75 Receiver started. {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"}
+2021-03-21T16:11:11.009Z INFO healthcheck/handler.go:128 Health Check state change {"component_kind": "extension", "component_type": "health_check", "component_name": "health_check", "status": "ready"}
+2021-03-21T16:11:11.009Z INFO service/service.go:267 Everything is ready. Begin running and processing data.
+2021-03-21T16:11:11.009Z INFO k8sclusterreceiver@v0.21.0/receiver.go:59 Starting shared informers and wait for initial cache sync. {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"}
+2021-03-21T16:11:11.281Z INFO k8sclusterreceiver@v0.21.0/receiver.go:75 Completed syncing shared informer caches. {"component_kind": "receiver", "component_type": "k8s_cluster", "component_name": "k8s_cluster"}
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+>[!INFO] 失敗したインストールの削除
+>OpenTelemetry Collector のインストールでエラーが発生した場合は、以下のコマンドで
+>インストールを削除してやり直すことができます。
+>
+>``` bash
+>helm delete splunk-otel-collector
+>```
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md
new file mode 100644
index 0000000000..421a7fbc6e
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md
@@ -0,0 +1,120 @@
+---
+title: Deploy the PetClinic Application
+linkTitle: 2. Deploy PetClinic Application
+weight: 3
+---
+
+アプリケーションの最初のデプロイでは、事前にビルドされたコンテナを使用して、観測対象としたい Kubernetes 上で動作する一般的な Java マイクロサービスベースのアプリケーションというベースシナリオを構築します。それでは、アプリケーションをデプロイしましょう。
+
+{{< tabs >}}
+{{% tab title="kubectl apply" %}}
+
+``` bash
+kubectl apply -f ~/workshop/petclinic/deployment.yaml
+```
+
+{{% /tab %}}
+{{% tab title="Output" %}}
+
+``` text
+deployment.apps/config-server created
+service/config-server created
+deployment.apps/discovery-server created
+service/discovery-server created
+deployment.apps/api-gateway created
+service/api-gateway created
+service/api-gateway-external created
+deployment.apps/customers-service created
+service/customers-service created
+deployment.apps/vets-service created
+service/vets-service created
+deployment.apps/visits-service created
+service/visits-service created
+deployment.apps/admin-server created
+service/admin-server created
+service/petclinic-db created
+deployment.apps/petclinic-db created
+configmap/petclinic-db-initdb-config created
+deployment.apps/petclinic-loadgen-deployment created
+configmap/scriptfile created
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+ここで、Pod が動作していることを確認することで、デプロイが成功したかを検証できます。コンテナはダウンロードして起動する必要があるため、数分かかる場合があります。
+
+{{< tabs >}}
+{{% tab title="kubectl get pods" %}}
+
+``` bash
+kubectl get pods
+```
+
+{{% /tab %}}
+{{% tab title="Output" %}}
+
+```bash
+NAME READY STATUS RESTARTS AGE
+splunk-otel-collector-k8s-cluster-receiver-655dcd9b6b-dcvkb 1/1 Running 0 114s
+splunk-otel-collector-agent-dg2vj 1/1 Running 0 114s
+splunk-otel-collector-operator-57cbb8d7b4-dk5wf 2/2 Running 0 114s
+petclinic-db-64d998bb66-2vzpn 1/1 Running 0 58s
+api-gateway-d88bc765-jd5lg 1/1 Running 0 58s
+visits-service-7f97b6c579-bh9zj 1/1 Running 0 58s
+admin-server-76d8b956c5-mb2zv 1/1 Running 0 58s
+customers-service-847db99f79-mzlg2 1/1 Running 0 58s
+vets-service-7bdcd7dd6d-2tcfd 1/1 Running 0 58s
+petclinic-loadgen-deployment-5d69d7f4dd-xxkn4 1/1 Running 0 58s
+config-server-67f7876d48-qrsr5 1/1 Running 0 58s
+discovery-server-554b45cfb-bqhgt 1/1 Running 0 58s
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+`kubectl get pods` の出力が、上記の Output タブに表示されている出力と一致することを確認してください。すべてのサービスが **Running** と表示されていることを確認します（または `k9s` を使用してステータスを継続的に監視します）。
+
+アプリケーションをテストするには、インスタンスのパブリック IP アドレスを取得する必要があります。次のコマンドを実行して取得できます。
+
+``` bash
+curl http://ifconfig.me
+
+```
+
+**http://:81** にアクセスして、アプリケーションが動作しているかを確認します（**** は上記で取得した IP アドレスに置き換えてください）。PetClinic アプリケーションが動作しているはずです。ポート **81** に到達できない場合や、別のポートを使用したい場合は、ポート **80** および **443** でも動作しています。
+
+
+
+**All Owners** **(1)** および **Veterinarians** **(2)** タブにアクセスして、それぞれのページに名前のリストが表示されることを確認し、アプリケーションが正しく動作していることを確かめてください。
+
+
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md
new file mode 100644
index 0000000000..d8810af3d4
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md
@@ -0,0 +1,61 @@
+---
+title: ワークショップインスタンスの準備
+linkTitle: 2. 準備
+weight: 3
+archetype: chapter
+time: 15 minutes
+---
+
+ワークショップ中に使用するインスタンスのログイン情報は、インストラクターから提供されます。
+
+インスタンスに初めてログインすると、以下のように Splunk のロゴが表示されます。ワークショップインスタンスへの接続に問題がある場合は、インストラクターまでご連絡ください。
+
+``` text
+$ ssh -p 2222 splunk@
+
+███████╗██████╗ ██╗ ██╗ ██╗███╗ ██╗██╗ ██╗ ██╗
+██╔════╝██╔══██╗██║ ██║ ██║████╗ ██║██║ ██╔╝ ╚██╗
+███████╗██████╔╝██║ ██║ ██║██╔██╗ ██║█████╔╝ ╚██╗
+╚════██║██╔═══╝ ██║ ██║ ██║██║╚██╗██║██╔═██╗ ██╔╝
+███████║██║ ███████╗╚██████╔╝██║ ╚████║██║ ██╗ ██╔╝
+╚══════╝╚═╝ ╚══════╝ ╚═════╝ ╚═╝ ╚═══╝╚═╝ ╚═╝ ╚═╝
+Last login: Mon Feb 5 11:04:54 2024 from [Redacted]
+splunk@show-no-config-i-0d1b29d967cb2e6ff ~ $
+```
+
+インスタンスが正しく構成されていることを確認するため、このワークショップで必要な環境変数が正しく設定されているかをチェックする必要があります。ターミナルで以下のスクリプトを実行し、環境変数が存在し、有効な値が設定されていることを確認してください。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+. ~/workshop/petclinic/scripts/check_env.sh
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+ACCESS_TOKEN =
+REALM =
+RUM_TOKEN =
+HEC_TOKEN =
+HEC_URL = https://<...>/services/collector/event
+INSTANCE =
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+`INSTANCE` 環境変数の値は、後ほど **Splunk Observability Cloud** でデータをフィルタリングする際に使用するため、メモしておいてください。
+
+このワークショップでは、上記の環境変数が **すべて** 必要です。値が不足しているものがある場合は、インストラクターまでお問い合わせください。
+
+> [!SPLUNK] 既存の OpenTelemetry Collector を削除する
+>この EC2 インスタンスで以前に Splunk Observability ワークショップを完了したことがある場合は、
+>既存の Splunk OpenTelemetry Collector のインストールが
+>削除されていることを確認する必要があります。以下のコマンドを実行することで削除できます。
+>
+>``` bash
+>helm delete splunk-otel-collector
+>```
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md
new file mode 100644
index 0000000000..a719d0ca87
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md
@@ -0,0 +1,28 @@
+---
+title: Kubernetes クラスターメトリクスの確認
+linkTitle: 3. クラスターメトリクスの確認
+weight: 4
+time: 10 minutes
+---
+
+インストールが完了したら、**Splunk Observability Cloud** にログインし、Kubernetes クラスターからメトリクスが流れ込んでいることを確認します。
+
+左側のメニューから **Infrastructure** をクリックし、**Kubernetes** を選択して、**Kubernetes nodes** タイルを選択します。
+
+
+
+**Kubernetes nodes** の概要画面に入ったら、**Time** フィルターを **-1h** から直近 15 分 **(-15m)** に変更して最新のデータに焦点を当て、**Table** を選択してメトリクスをレポートしているすべてのノードを一覧表示します。
+
+次に、**Refine by:** パネルで **Cluster name** を選択し、リストからご自身のクラスターを選択します。
+
+{{% notice title="ヒント" style="info" icon="lightbulb" %}}
+ご自身のクラスターを特定するには、セットアップ時に実行したシェルスクリプトの出力にある `INSTANCE` の値を使用します。この一意の識別子により、リスト内の他のノードの中からワークショップ用のクラスターを見つけることができます。
+{{% /notice %}}
+
+これにより、リストにはご自身のクラスターのノードのみが表示されるようにフィルターされます。
+
+
+
+**K8s node logs** ビューに切り替えて、ノードからのログを確認します。
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md
new file mode 100644
index 0000000000..3b8def4505
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md
@@ -0,0 +1,79 @@
+---
+title: Patching the Deployment
+linkTitle: 1. Patching the Deployment
+weight: 1
+---
+
+**自動検出と設定（automatic discovery and configuration）**を構成するには、計装用のアノテーションを追加するために Deployment にパッチを適用する必要があります。パッチが適用されると、OpenTelemetry Collector が自動検出と設定のライブラリを注入し、Pod が再起動されてトレースとプロファイリングデータの送信が開始されます。まず、以下を実行して `api-gateway` に `splunk-otel-java` イメージが含まれていないことを確認します。
+
+{{< tabs >}}
+{P}{{% tab title="Describe api-gateway" %}}
+
+``` bash
+kubectl describe pods api-gateway | grep Image:
+```
+
+{{% /tab %}}
+{{% tab title="Describe Output" %}}
+
+``` text
+Image: quay.io/phagen/spring-petclinic-api-gateway:0.0.2
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+次に、Deployment にアノテーションを追加して、すべてのサービスに対して Java の自動検出と設定を有効にします。次のコマンドはすべての Deployment にパッチを適用します。これにより、OpenTelemetry Operator がトリガーされ、`splunk-otel-java` イメージが Pod に注入されます。
+
+{{< tabs >}}
+{{% tab title="Patch all PetClinic services" %}}
+
+``` bash
+kubectl get deployments -l app.kubernetes.io/part-of=spring-petclinic -o name | xargs -I % kubectl patch % -p "{\"spec\": {\"template\":{\"metadata\":{\"annotations\":{\"instrumentation.opentelemetry.io/inject-java\":\"default/splunk-otel-collector\"}}}}}"
+```
+
+{{% /tab %}}
+{{% tab title="Patch Output" %}}
+
+``` text
+deployment.apps/config-server patched (no change)
+deployment.apps/admin-server patched (no change)
+deployment.apps/customers-service patched
+deployment.apps/visits-service patched
+deployment.apps/discovery-server patched (no change)
+deployment.apps/vets-service patched
+deployment.apps/api-gateway patched
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+**config-server**、**discovery-server**、**admin-server** はすでにパッチが適用されているため、変更はありません。
+
+`api-gateway` Pod のコンテナイメージを再度確認するには、次のコマンドを実行します。
+
+{{< tabs >}}
+{{% tab title="Describe api-gateway" %}}
+
+``` bash
+kubectl describe pods api-gateway | grep Image:
+```
+
+{{% /tab %}}
+{{% tab title="Describe Output" %}}
+
+```text
+Image: ghcr.io/signalfx/splunk-otel-java/splunk-otel-java:v1.30.0
+Image: quay.io/phagen/spring-petclinic-api-gateway:0.0.2
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+`api-gateway` に新しいイメージが追加され、`ghcr.io` から `splunk-otel-java` がプルされます（注：`api-gateway` コンテナが2つ表示される場合、元のコンテナがまだ終了処理中である可能性が高いので、数秒待ってください）。
+
+**Splunk Observability Cloud** の Kubernetes Navigator に戻ります。数分後、Operator によって Pod が再起動され、自動検出と設定のコンテナが追加されることが確認できます。これは以下のスクリーンショットのように表示されます。
+
+
+
+Kubernetes Navigator で Pod が緑色になるまで待ってから、次のセクションに進んでください。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md
new file mode 100644
index 0000000000..5c0ca863c0
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md
@@ -0,0 +1,16 @@
+---
+title: Splunk APM でのデータの確認
+linkTitle: 2. APM データの確認
+weight: 2
+---
+
+左側のメニューで **APM** をクリックし、新しく計装されたサービスのトレースから生成されたデータを確認します。
+
+**Environment** フィルター **(1)** を、ドロップダウンボックスでお使いのワークショップインスタンスの名前に変更します。
+
+> [!NOTE]
+> これは **`-workshop`** となります。**`INSTANCE`** は、先ほど実行したシェルスクリプトの値です。これだけが選択されていることを確認してください。
+
+
+
+次のセクションの準備として、**Service Map** **(2)** ペインをクリックします。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md
new file mode 100644
index 0000000000..a470dab453
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md
@@ -0,0 +1,49 @@
+---
+title: APM 向け自動検出と自動構成のセットアップ
+linkTitle: 4. 自動検出と自動構成
+weight: 5
+time: 10 minutes
+---
+
+このセクションでは、Kubernetes 上で実行されている Java サービスに対して **自動検出と自動構成** を有効にします。これにより、OpenTelemetry Collector は Pod のアノテーションを参照して、Java アプリケーションを Splunk OpenTelemetry Java エージェントでインストルメントすべきかどうかを判断します。これによって、クラスター上で実行されている Java サービスからトレース、スパン、プロファイリングデータを取得できるようになります。
+
+{{% notice title="自動検出と自動構成" style="note" %}}
+
+自動検出と自動構成は、**コードの変更や再コンパイルを必要とせずに**、アプリケーションから **トレース、スパン、プロファイリング** データを取得することを目的に設計されている点を理解しておくことが重要です。
+
+これは APM を始めるうえで非常に便利な方法ですが、手動インストルメンテーションの代替には **なりません**。手動インストルメンテーションでは、カスタムスパン、タグ、ログをアプリケーションに追加でき、トレースに対してより多くのコンテキストと詳細情報を付与できます。
+
+{{% /notice %}}
+
+Java アプリケーションの場合、OpenTelemetry Collector はアノテーション `instrumentation.opentelemetry.io/inject-java` を参照します。
+
+このアノテーションには、値として `true` を指定するか、OpenTelemetry Collector の `namespace/daemonset`（例：`default/splunk-otel-collector`）を指定できます。後者の方式を使うと名前空間をまたいで動作させることができ、本ワークショップではこちらを使用します。
+
+{{% notice title="deployment.yaml の使用" style="info" %}}
+
+Pod が自動的にトレースを送信するようにしたい場合は、以下のように `deployment.yaml` にアノテーションを追加できます。これによって、初回のデプロイ時にインストルメンテーションライブラリが追加されます。作業を効率化するため、以下の Pod についてはすでにこの設定を行っています:
+
+- **admin-server**
+- **config-server**
+- **discovery-server**
+
+``` yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: admin-server
+ labels:
+ app.kubernetes.io/part-of: spring-petclinic
+spec:
+ selector:
+ matchLabels:
+ app: admin-server
+ template:
+ metadata:
+ labels:
+ app: admin-server
+ annotations:
+ instrumentation.opentelemetry.io/inject-java: "default/splunk-otel-collector"
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md
new file mode 100644
index 0000000000..c7ea769063
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md
@@ -0,0 +1,19 @@
+---
+title: APM Service Map
+linkTitle: 1. APM Service Map
+weight: 1
+---
+
+
+
+上記のマップは、すべてのサービス間のインタラクションを示しています。PetClinic Microservice アプリケーションが起動して完全に同期されるまで数分かかるため、マップはまだ中間状態である可能性があります。**-2m** と入力して時間フィルターをカスタム時間 **2 minutes** に短縮すると見やすくなります。画面右上の **Refresh** ボタン **(1)** をクリックしてください。赤い円で示される起動時の初期エラーは、最終的に消えていきます。
+
+次に、request, error, and duration (RED) メトリクスダッシュボードを確認することで、計装された各サービスで利用可能なメトリクスを調べてみましょう。
+
+この演習では、サービスのオペレーションで高いレイテンシやエラーが発生している場合に使用する一般的なシナリオを使用します。
+
+Dependency map で **customers-service** をクリックし、**Services** ドロップダウンボックス **(1)** で `customers-service` が選択されていることを確認します。次に、Service 名の隣にある Operations ドロップダウン **(2)** から `GET /owners` を選択します。
+
+これにより、以下に示すように `GET /owners` でフィルタリングされたワークフローが表示されます。
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md
new file mode 100644
index 0000000000..46317cbde8
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md
@@ -0,0 +1,23 @@
+---
+title: APM Trace
+linkTitle: 2. APM Trace
+weight: 2
+---
+
+トレースを選択するには、`Service Requests & Errors` チャート内の行を選択します **(1)**。関連するトレースの一覧が表示されます。
+
+関連トレースの一覧が表示されたら、青色の **(2)** Trace ID リンクをクリックします。その際、選択するトレースの Services 列に、これまでに言及された 3 つのサービスが含まれていることを確認してください。
+
+
+
+これにより、選択したトレースが Waterfall ビューで表示されます。
+
+ここでは、いくつかのセクションが確認できます。
+
+* Waterfall ペイン **(1)** では、トレースおよび計装されたすべての関数がスパンとして表示され、その所要時間や順序・関係性を視覚的に確認できます。
+* Trace Info ペイン **(2)** では、選択したスパンの情報が表示されます（Waterfall ペイン内で対象のスパンが枠で強調表示されます）。
+* Span ペイン **(3)** では、選択したスパンに送信されたすべてのタグを確認できます。下にスクロールするとすべてのタグを参照できます。
+* Process ペインでは、スパンを生成したプロセスに関連するタグが表示されます（スクリーンショットには含まれていないため、下にスクロールして確認してください）。
+* Trace Properties はペインの右上に位置し、デフォルトでは折りたたまれた状態になっています。
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md
new file mode 100644
index 0000000000..f786536056
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md
@@ -0,0 +1,46 @@
+---
+title: APM Span
+linkTitle: 3. APM Spans
+weight: 3
+---
+
+スパンを確認しながら、トレースに加えて **automatic discovery and configuration** を使用した際に **コードを変更することなく** 利用できる、いくつかのアウトオブザボックス機能を見ていきましょう。
+
+まず、Waterfall Pane で、以下のスクリーンショットのように `customers-service:SELECT petclinic` または類似のスパンが選択されていることを確認してください。
+
+
+
+* 基本的なレイテンシー情報は、計装された関数または呼び出しに対するバーとして表示されます。上記の例では、17.8 ミリ秒かかっています。
+* Several similar Spans **(1)** は、スパンが複数回繰り返されている場合にのみ表示されます。この例では、10 回繰り返されています。`10x` をクリックすると、すべてのスパンを表示／非表示にでき、すべてのスパンが順番に表示されます。
+* **Inferred Services**: 計装されていない外部システムへの呼び出しは、グレーの「inferred」スパンとして表示されます。この例における Inferred Service またはスパンは、上記の通り Mysql Database への呼び出し `mysql:petclinic SELECT petclinic` **(2)** です。
+* **Span Tags**: Tag Pane では、automatic discovery and configuration によって生成された標準的なタグを確認できます。この場合、スパンはデータベースを呼び出しているため、`db.statement` タグ **(3)** が含まれています。このタグには DB クエリ ステートメントが格納され、このスパン中に実行されたデータベース呼び出しで使用されます。これは DB-Query Performance 機能で利用されます。DB-Query Performance については次のセクションで見ていきます。
+* **Always-on Profiling**: スパンのライフサイクル中にプロファイリング データをキャプチャするようにシステムが設定されている **場合**、スパンのタイムラインにキャプチャされたコール スタックの数が表示されます。上記の例では、`customer-service:GET /owners` スパンに対して 18 個のコール スタックが表示されています。**(4)**
+
+プロファイリングについては次のセクションで見ていきます。
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md
new file mode 100644
index 0000000000..bf42dac848
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md
@@ -0,0 +1,13 @@
+---
+title: Service Centric View
+linkTitle: 4. Service Centric View
+weight: 4
+---
+
+Splunk APM は **Service Centric Views** を提供しており、エンジニアはサービスのパフォーマンスを一元的なビューで深く理解できます。すべてのサービスにわたって、エンジニアはサービスの基盤となるインフラストラクチャからエラーやボトルネックを素早く特定し、新しいデプロイによるパフォーマンス低下をピンポイントで把握し、すべてのサードパーティ依存関係の健全性を可視化できます。
+
+`api-gateway` のこのダッシュボードを表示するには、左側のメニューから **APM** をクリックし、続いてリスト内の `api-gateway` サービスをクリックします。これにより、Service Centric View ダッシュボードが表示されます。
+
+
+
+計装されたすべてのサービスで利用可能なこのビューでは、**Service metrics**、**Error breakdown**、**Runtime metrics (Java)**、**Infrastructure metrics** の概要が確認できます。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md
new file mode 100644
index 0000000000..5db17e19a5
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md
@@ -0,0 +1,13 @@
+---
+title: APM の機能
+linkTitle: 5. APM の機能
+weight: 6
+archetype: chapter
+time: 15 minutes
+---
+
+前のセクションで見てきたように、サービス上で **automatic discovery and configuration** を有効にすると、トレースが **Splunk Observability Cloud** に送信されます。
+
+これらのトレースを利用して、Splunk は **Service Maps** と **RED Metrics** を自動的に生成します。これらはサービスの動作と、サービス同士がどのように相互作用しているかを理解するための最初のステップです。
+
+次のセクションでは、トレースそのものと、それが提供する情報を詳しく見ていきます。コードに一切手を加えることなく、サービスの動作を理解するのに役立ちます。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md
new file mode 100644
index 0000000000..2ef6af8de0
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md
@@ -0,0 +1,69 @@
+---
+title: Always-On Profiling & Metrics
+linkTitle: 1. Always-On Profiling
+weight: 1
+---
+
+先ほど Helm chart を使って Splunk Distribution of the OpenTelemetry Collector をインストールした際に、**AlwaysOn Profiling** と **Metrics** が有効になるよう設定しました。これにより、OpenTelemetry Java はアプリケーションの CPU およびメモリのプロファイリングを自動的に生成し、Splunk Observability Cloud に送信します。
+
+PetClinic アプリケーションをデプロイしてアノテーションを設定すると、Collector はアプリケーションを自動検出し、トレースとプロファイリングのためのインスツルメンテーションを行います。次のスクリプトを実行して、インスツルメントしている Java コンテナのいずれかの起動ログを確認することで、これを検証できます。
+
+ログには、Java の自動検出と設定で読み込まれたフラグが表示されます。
+
+{{< tabs >}}
+{{% tab title="Run the script" %}}
+
+``` logs
+. ~/workshop/petclinic/scripts/get_logs.sh
+```
+
+{{% /tab %}}
+{{% tab title="Example output" %}}
+
+``` text {wrap="false"}
+2024/02/15 09:42:00 Problem with dial: dial tcp 10.43.104.25:8761: connect: connection refused. Sleeping 1s
+2024/02/15 09:42:01 Problem with dial: dial tcp 10.43.104.25:8761: connect: connection refused. Sleeping 1s
+2024/02/15 09:42:02 Connected to tcp://discovery-server:8761
+Picked up JAVA_TOOL_OPTIONS: -javaagent:/otel-auto-instrumentation-java/javaagent.jar
+Picked up _JAVA_OPTIONS: -Dspring.profiles.active=docker,mysql -Dsplunk.profiler.call.stack.interval=150
+OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
+[otel.javaagent 2024-02-15 09:42:03:056 +0000] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: splunk-1.30.1-otel-1.32.1
+[otel.javaagent 2024-02-15 09:42:03:768 +0000] [main] INFO com.splunk.javaagent.shaded.io.micrometer.core.instrument.push.PushMeterRegistry - publishing metrics for SignalFxMeterRegistry every 30s
+[otel.javaagent 2024-02-15 09:42:07:478 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - -----------------------
+[otel.javaagent 2024-02-15 09:42:07:478 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - Profiler configuration:
+[otel.javaagent 2024-02-15 09:42:07:480 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.enabled : true
+[otel.javaagent 2024-02-15 09:42:07:505 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.directory : /tmp
+[otel.javaagent 2024-02-15 09:42:07:505 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.recording.duration : 20s
+[otel.javaagent 2024-02-15 09:42:07:506 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.keep-files : false
+[otel.javaagent 2024-02-15 09:42:07:510 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.logs-endpoint : http://10.13.2.38:4317
+[otel.javaagent 2024-02-15 09:42:07:513 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - otel.exporter.otlp.endpoint : http://10.13.2.38:4317
+[otel.javaagent 2024-02-15 09:42:07:513 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.memory.enabled : true
+[otel.javaagent 2024-02-15 09:42:07:515 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.tlab.enabled : true
+[otel.javaagent 2024-02-15 09:42:07:516 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.memory.event.rate : 150/s
+[otel.javaagent 2024-02-15 09:42:07:516 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.call.stack.interval : PT0.15S
+[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.include.internal.stacks : false
+[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - splunk.profiler.tracing.stacks.only : false
+[otel.javaagent 2024-02-15 09:42:07:517 +0000] [main] INFO com.splunk.opentelemetry.profiler.ConfigurationLogger - -----------------------
+[otel.javaagent 2024-02-15 09:42:07:518 +0000] [main] INFO com.splunk.opentelemetry.profiler.JfrActivator - Profiler is active.
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+ここで注目するのは、`com.splunk.opentelemetry.profiler.ConfigurationLogger` によって出力されているセクション、つまり **Profiling Configuration** の部分です。
+
+`splunk.profiler.directory` のように、制御可能なさまざまな設定を確認できます。これは、エージェントが Splunk に送信する前にコールスタックを書き込む場所です（コンテナの構成方法によっては異なる場合があります）。
+
+変更を検討したいもう一つのパラメータは `splunk.profiler.call.stack.interval` です。これは、システムが CPU スタックトレースをキャプチャする頻度です。Pet Clinic アプリケーションのような短いスパンがある場合は、このインターバル設定を短くすることを検討するとよいでしょう。デモアプリケーションではデフォルトのインターバル値を変更していないため、スパンに常に CPU コールスタックが関連付けられているとは限りません。
+
+これらのパラメータの設定方法は[こちら](https://help.splunk.com/en/splunk-observability-cloud/manage-data/available-data-sources/supported-integrations-in-splunk-observability-cloud/apm-instrumentation/instrument-a-java-application/configure-the-java-agent#profiling-configuration-java)で確認できます。以下の例では、`deployment.yaml` の JAVA_OPTIONS 設定セクションでこの値を設定することにより、コールスタックの収集レートを高くする方法を示しています。
+
+``` yaml
+env:
+- name: JAVA_OPTIONS
+ value: "-Xdebug -Dsplunk.profiler.call.stack.interval=150"
+```
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md
new file mode 100644
index 0000000000..0cb7615bfb
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md
@@ -0,0 +1,32 @@
+---
+title: Always-On Profiling in the Trace Waterfall
+linkTitle: 2. Trace Waterfall
+weight: 2
+---
+
+APM Waterfall ビューで元の (または類似の) Trace と Span **(1)** を選択していることを確認し、右側のペインから **Memory Stack Traces (2)** を選択してください。
+
+
+
+ペインに Memory Stack Trace Flame Graph **(3)** が表示されます。スクロールしたり、ペインの右端をドラッグして拡大したりできます。
+
+AlwaysOn Profiling はアプリケーションのコードのスナップショット (スタックトレース) を継続的に取得しています。何千ものスタックトレースを読み込まなければならないことを想像してみてください。これは現実的ではありません。これを支援するために、AlwaysOn Profiling はプロファイリングデータを集約・サマライズし、**Flame Graph** と呼ばれるビューで Call Stack を簡単に探索できるようにしています。これはアプリケーションから取得したすべてのスタックトレースのサマリーを表しています。Flame Graph を使用して、どのコード行がパフォーマンス問題を引き起こしている可能性があるかを発見し、コードに加えた変更が意図した効果をもたらすかを確認できます。
+
+Always-on Profiling をさらに詳しく調べるには、Profiling ペインの **Memory Stack Traces** の下にある Span **(3)** (上記画像で参照) を選択します。これにより、Memory ビューが事前選択された状態で Always-on Profiling のメイン画面が開きます。
+
+
+
+* Time フィルターは、選択した Span の時間枠に設定されます **(1)**
+* Java Memory Metric Charts **(2)** では、`Monitor Heap Memory, Application Activity` として `Memory Allocation Rate` や `Garbage Collecting` などのメトリクスを確認できます。
+* Span に関連するメトリクスとスタックトレースのみにフォーカス/表示する機能 **(3)**。これにより、必要に応じて Java アプリケーションで実行されているバックグラウンドアクティビティをフィルタリングできます。
+* 識別された Java 関数呼び出し **(4)**。その関数から呼び出されたメソッドにドリルダウンできます。
+* Flame Graph **(5)**。プロファイル対象サービスのスタックトレースに基づいた階層を可視化します。
+* サービスが自身の複数バージョンを起動する場合に Service インスタンスを選択する機能 **(6)**。
+
+さらなる調査のために、UI ではスタックトレースをクリックして、呼び出された関数と Flame Chart 内の関連する行を確認できます。これを使えば、コーディングプラットフォーム (もちろんお好みのコーディングプラットフォームによります) で実際のコード行を表示することができます。
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md
new file mode 100644
index 0000000000..e7a448f104
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md
@@ -0,0 +1,54 @@
+---
+title: Database Query Performance
+linkTitle: 3. Database Query Performance
+weight: 3
+---
+
+Database Query Performance を使用すると、データベースクエリがサービスの可用性に与える影響を Splunk APM で直接モニタリングできます。これにより、データベースをインストルメントすることなく、長時間実行されているクエリ、最適化されていないクエリ、重いクエリを迅速に特定し、それらが引き起こしている可能性のある問題を軽減できます。
+
+データベースクエリのパフォーマンスを確認するには、ブラウザで戻るか、メニューバーの APM セクションに移動して **Service Map** タイルをクリックし、APM の **Service Map** ページにいることを確認してください。
+
+Dependency map で推論されたデータベースサービス `mysql:petclinic` Inferred Database server を選択し **(1)**、右側のペインをスクロールして **Database Query Performance** ペインを見つけます **(2)**。
+
+
+
+マップで選択したサービスが実際に（推論された）データベースサーバーである場合、このペインは継続時間に基づく上位 90%（P90）のデータベース呼び出しで埋められます。db-query performance 機能をさらに深く掘り下げるには、ペイン上部の **Database Query Performance** という単語のあたりをクリックします。
+
+これにより、DB-query Performance 概要画面が表示されます。
+
+
+
+{{% notice title="Database Query Normalization" style="info" %}}
+デフォルトでは、Splunk APM のインストルメンテーションは、シークレットや個人を特定できる情報（PII）などの機密データを `db.statements` から削除またはマスクするためにデータベースクエリをサニタイズします。データベースクエリの正規化を無効にする方法は[こちら](https://help.splunk.com/en/splunk-observability-cloud/monitor-application-performance/monitor-database-query-performance/troubleshoot-database-query-performance#turn-off-database-query-normalization)で確認できます。
+{{% /notice %}}
+
+この画面では、Splunk Observability Cloud に送信された Traces と Spans に基づいて、アプリケーションからデータベースに対して行われたすべてのデータベースクエリ **(1)** が表示されます。時間ブロック間で比較したり、Total Time、P90 Latency、Requests でソートしたりできることに注意してください **(2)**。
+
+リスト内の各データベースクエリについて、最も高いレイテンシー、時間枠内の総呼び出し回数、1 秒あたりのリクエスト数が表示されます **(3)**。これにより、クエリを最適化できる箇所を特定できます。
+
+右側のペインの 2 つのチャート **(5)** を介して、データベース呼び出しを含むトレースを選択できます。Tag Spotlight ペイン **(6)** を使用して、エンドポイントやタグに基づいて、データベース呼び出しに関連するタグを掘り下げて確認します。
+
+クエリの詳細ビューを確認する必要がある場合は、次のとおりです。
+
+
+
+特定のクエリをクリックします **(1)**。これにより、Query Details ペイン **(2)** が開き、より詳細な調査に使用できます。
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md
new file mode 100644
index 0000000000..72d08541a2
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md
@@ -0,0 +1,16 @@
+---
+title: Always-On Profiling & DB Query Performance
+linkTitle: 6. Advanced Features
+weight: 7
+archetype: chapter
+time: 15 minutes
+---
+
+前章で見てきたように、APM を使えばコードに手を加えることなく各サービス間のやり取りをトレースでき、問題をより迅速に特定できます。
+
+トレースに加えて、**自動検出と構成** はすぐに使える追加機能を提供しており、問題をさらに素早く発見するのに役立ちます。本セクションでは、その中から次の 2 つを取り上げます。
+
+- **Always-on Profiling と Java メトリクス**
+- **Database Query Performance**
+
+Always-on Profiling や DB-Query Performance についてさらに深く学びたい場合は、別の Ninja Workshop である [**Debug Problems in Microservices**](/en/scenarios/debug_problems/) を参照してください。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md
new file mode 100644
index 0000000000..03904e6319
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md
@@ -0,0 +1,21 @@
+---
+title: ログの表示
+linkTitle: 1. ログの表示
+weight: 2
+---
+
+ログを確認するには、左側のメニューから  **Log Observer** をクリックします。Log Observer に入ったら、フィルターバーの **Index** が **splunk4rookies-workshop** に設定されていることを確認してください。**(1)**
+
+次に、**Add Filter** をクリックし、*Fields* **(2)** オプションを使ってフィールド `deployment.environment` **(3)** を検索します。続いて、ドロップダウンリストから自分のワークショップインスタンスを選択し **(4)**、`=`（含める）をクリックします。これで、PetClinic アプリケーションからのログメッセージのみが表示されるようになります。
+
+
+
+次に、フィールド `service.name` を検索し、値 `customers-service` を選択して `=`（含める）をクリックします。これがフィルターバーに表示されるはずです **(1)**。続いて **Run Search** ボタン **(2)** をクリックします。
+
+
+
+これによりログエントリが更新され、`customers-service` のみのエントリに絞り込まれて表示されます。
+
+
+
+*"Saving pet"* で始まるエントリをクリックします **(1)**。サイドペインが開き、関連するトレース ID およびスパン ID を含む詳細情報を確認できます **(2)**。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md
new file mode 100644
index 0000000000..52d99d2a4a
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md
@@ -0,0 +1,15 @@
+---
+title: Related Content
+linkTitle: 2. Related Content
+weight: 3
+---
+
+下部のペインには、関連するコンテンツが表示されます。次のスクリーンショットでは、APM がこのログ行に関連するトレースを検出していることが確認できます **(1)**。
+
+
+
+**Trace for 960432ac9f16b98be84618778905af50** を **(2)** クリックすると、このログ行が生成された特定のトレースの APM 内のウォーターフォール画面に移動します。
+
+
+
+ここで、Logs 用の **Related Content** ペインが表示されている **(1)** ことに注目してください。これをクリックすると Log Observer に戻り、このトレースに含まれるすべてのログ行が表示されます。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md
new file mode 100644
index 0000000000..5b59805b07
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md
@@ -0,0 +1,17 @@
+---
+title: Log Observer
+linkTitle: 7. Log Observer
+weight: 8
+archetype: chapter
+time: 10 minutes
+---
+
+ここまでの工程では**コードの変更は一切行っていません**が、トレース、プロファイリング、Database Query Performance のデータが Splunk Observability Cloud に送信されています。
+
+次は **Splunk Log Observer** を使って、Spring PetClinic アプリケーションからログデータを取得します。
+
+**Splunk OpenTelemetry Collector** は Spring PetClinic アプリケーションからログを自動的に収集し、OTLP exporter を使って Splunk Observability Cloud に送信します。その際、ログイベントには `trace_id`、`span_id`、トレースフラグが付与されます。
+
+そして **Splunk Log Observer** を使ってログを表示し、ログ情報をサービスやトレースと自動的に相関付けします。
+
+この機能は [**Related Content**](https://help.splunk.com/en/splunk-observability-cloud/data-tools/related-content) と呼ばれます。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md
new file mode 100644
index 0000000000..390a42d039
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md
@@ -0,0 +1,22 @@
+---
+title: Petclinic アプリの RUM ビューを選択する
+linkTitle: 1. RUM データを確認する
+weight: 1
+---
+
+まずは RUM の概要をざっと見ていきましょう。左側のメニューから **RUM** をクリックしてください。次に **Environment** フィルター **(1)** を、ドロップダウンボックスからワークショップインスタンスの名前に変更し、**`-workshop`** **(1)** を選択します（**`INSTANCE`** は先ほど実行したシェルスクリプトの値です）。これだけが選択されている状態にしてください。
+
+続いて、**App** **(2)** ドロップダウンボックスをアプリの名前（**`-store`**）に変更します。
+
+
+
+**Environment** と **App** を選択すると、アプリケーションの RUM ステータスを示す概要ページが表示されます。（Summary Dashboard が数値の 1 行だけになっている場合は、縮小表示の状態です。アプリケーション名の前にある **> (1)** をクリックして展開できます。）JavaScript エラーが発生していた場合は、以下のように表示されます。
+
+
+
+続けるには、青いリンク（ワークショップ名が表示されているもの）をクリックして詳細ページに移動します。すると、UX Metrics、Front-end Health、Back-end Health、Custom Events ごとにインタラクションを分解し、過去のメトリクス（デフォルトでは 1 時間）と比較する新しいダッシュボードビューが表示されます。
+
+
+通常、最初のチャートには 1 本の線だけが表示されます。Petclinic ショップに関連するリンクをクリックしてください。この例では です。
+
+これにより、Tag Spotlight ページに移動します。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md
new file mode 100644
index 0000000000..e998b650d6
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md
@@ -0,0 +1,14 @@
+---
+title: RUMトレースのウォーターフォールビューとAPMへのリンク
+linkTitle: 2. RUMトレースをたどる
+weight: 2
+---
+TAG Spotlightビューでは、RUMデータに関連付けられたすべてのタグが表示されます。タグは、データを識別するために使用されるキーと値のペアです。今回の場合、タグはOpenTelemetryのインストルメンテーションによって自動的に生成されています。タグは、データをフィルタリングしたり、チャートやテーブルを作成するために使用されます。Tag Spotlightビューでは、挙動のトレンドを検出し、ユーザーセッションをドリルダウンして調査できます。
+
+
+
+User Sessions **(1)** をクリックすると、その時間帯に発生したユーザーセッションの一覧が表示されます。
+
+そのうちの1つを確認したいので、*Duration* **(2)** をクリックして所要時間でソートし、所要時間が長いセッションのいずれかのリンク **(3)** をクリックしてください。
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md
new file mode 100644
index 0000000000..91228941ef
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md
@@ -0,0 +1,19 @@
+---
+title: RUMトレースウォーターフォールビューとAPMへのリンク
+linkTitle: 3. RUMウォーターフォール
+weight: 3
+---
+
+ここではRUMトレースウォーターフォールを見ています。これにより、ユーザーがpetclinicアプリケーションのページを訪問した際に、ユーザーのデバイス上でセッション中に何が起こったかを確認できます。
+
+ウォーターフォールを下にスクロールして右側の **#!/owners/details** セグメント **(1)** をクリックすると、Vetsリクエストの処理中に発生したアクションのリストが表示されます。HTTPリクエストには、リターンコードの前に青色の **APM** リンクが表示されていることに注目してください。いずれか1つを選び、APMリンクをクリックします。これにより、Kubernetes上でホストされているこのバックエンドサービス呼び出しのAPM情報が表示されます。
+
+
+
+リクエストで何が起こったかをドリルダウンして確認したい場合は、Trace IDのURLをクリックしてください。
+
+これにより、RUMからのリクエストに関連するトレースが表示されます:
+
+
+
+サービスへのエントリポイントに **RUM (1)** 関連のコンテンツリンクが追加され、バックエンドサービスで何が起こったかを検証した後にRUMセッションへ戻れるようになっていることがわかります。
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md
new file mode 100644
index 0000000000..7b964c115a
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md
@@ -0,0 +1,53 @@
+---
+title: Real User Monitoring
+linkTitle: 8. Real User Monitoring
+weight: 9
+time: 10 minutes
+archetype: chapter
+---
+
+アプリケーションに対して Real User Monitoring (RUM) のインストルメンテーションを有効化するには、Open Telemetry Javascript の [**https://github.com/signalfx/splunk-otel-js-web**](https://github.com/signalfx/splunk-otel-js-web) スニペットをコードベースに追加する必要があります。
+
+Spring PetClinic アプリケーションは、アプリケーションのすべてのビューで再利用される単一の [**index**](https://github.com/spring-petclinic/spring-petclinic-microservices/blob/main/spring-petclinic-api-gateway/src/main/resources/static/index.html) HTML ページを使用しています。このページは、すべてのページで自動的に読み込まれるため、Splunk RUM インストルメンテーションライブラリを挿入するのに最適な場所です。
+
+`api-gateway` サービスではすでにインストルメンテーションが動作しており、RUM トレースを Splunk Observability Cloud に送信しています。次のセクションでこのデータを確認します。
+
+スニペットを確認したい場合は、ブラウザでページを右クリックし、**View Page Source** を選択してページソースを表示できます。
+
+``` html
+
+
+
+
+
+```
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md
new file mode 100644
index 0000000000..d6927c6599
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md
@@ -0,0 +1,17 @@
+---
+title: ワークショップのまとめ 🎁
+linkTitle: 9. ワークショップのまとめ
+weight: 9
+archetype: chapter
+description: おめでとうございます、Get the Most Out of Your Existing Kubernetes Java Applications Using Automatic Discovery and Configuration With OpenTelemetry を完了しました。本日は、Kubernetes 上の既存の Java アプリケーションに Tracing、Code Profiling、Database Query Performance を追加して、アプリケーションとインフラストラクチャのオブザーバビリティを即座に向上させる方法がいかに簡単かを学びました。
+---
+
+おめでとうございます、**Get the Most Out of Your Existing Kubernetes Java Applications Using Automatic Discovery and Configuration With OpenTelemetry** ワークショップを完了しました。
+
+本日は、Kubernetes 上の既存の Java アプリケーションに Tracing、Code Profiling、Database Query Performance を追加することがいかに簡単かを学びました。
+
+**Automatic Discovery and Configuration** を使用することで、コードや設定を一行も変更することなく、アプリケーションとインフラストラクチャのオブザーバビリティを即座に向上させることができました。
+
+また、シンプルな設定変更だけで、エンドツーエンドのオブザーバビリティを実現するために、アプリケーションにさらに多くのオブザーバビリティ（**logging** と **RUM**）を追加できることも学びました。
+
+
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/_index.md
new file mode 100644
index 0000000000..b69c7a1b50
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/2-petclinic-kubernetes/_index.md
@@ -0,0 +1,32 @@
+---
+title: Spring PetClinic SpringBoot Based Microservices On Kubernetes
+linkTitle: PetClinic Kubernetes Workshop
+weight: 2
+archetype: chapter
+authors: ["Pieter Hagen"]
+description: Kubernetes 上で稼働する Java ベースのアプリケーションに対して、自動検出と自動設定を有効化する方法を学びます。エンドツーエンドの可視性によりアプリケーションの動作を最大限に把握できる、リアルタイム監視を体験してください。
+time: 90 minutes
+---
+
+このワークショップの目的は、Java 向けの Splunk の **automatic discovery and configuration**（自動検出と自動設定）の機能を紹介することです。
+
+ワークショップのシナリオは、シンプルな（**計装されていない**）Java マイクロサービスアプリケーションを Kubernetes にインストールして構築します。
+
+既存の Java ベースのデプロイメントに対して自動検出機能付きの Splunk OpenTelemetry Collector をインストールするシンプルな手順に従うことで、メトリクス、トレース、ログを **Splunk Observability Cloud** へ送信することがいかに簡単であるかを確認します。
+
+> [!SPLUNK]前提条件
+>
+> * ポート **2222** へのアウトバウンド SSH アクセス。
+> * ポート **81** へのアウトバウンド HTTP アクセス。
+> * Linux コマンドラインの基本的な知識。
+
+このワークショップでは、以下のコンポーネントを取り上げます。
+
+* Splunk Infrastructure Monitoring (**IM**)
+* Splunk automatic discovery and configuration for Java (**APM**)
+ * Database Query Performance
+ * AlwaysOn Profiling
+* Splunk Log Observer (**LO**)
+* Splunk Real User Monitoring (**RUM**)
+
+_Splunk Synthetics は今回少し蚊帳の外ですが、他のワークショップでカバーしています_ {{% icon icon="heart" %}}
diff --git a/content/ja/ninja-workshops/foundations/1-automatic-discovery/_index.md b/content/ja/ninja-workshops/foundations/1-automatic-discovery/_index.md
new file mode 100644
index 0000000000..fd3957ac97
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/1-automatic-discovery/_index.md
@@ -0,0 +1,9 @@
+---
+title: Automatic Discovery ワークショップ
+description: ゼロコードでの Java インスツルメンテーションの実例 — モノリスおよび Kubernetes 環境におけるサービスの自動検出と、メトリクス、トレース、ログの送信を体験します。
+weight: 1
+time: 60 minutes
+aliases:
+ - /ninja-workshops/1-automatic-discovery/
+layout: "hero"
+---
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md
new file mode 100644
index 0000000000..95e6549d21
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md
@@ -0,0 +1,310 @@
+---
+title: Installing OpenTelemetry Collector Contrib
+linkTitle: 1.1 Confirm Installation
+weight: 1
+---
+
+## Collector が動作していることを確認する
+
+Collector は現在動作しているはずです。`systemctl` コマンドを使って root 権限で確認します。ステータス表示を終了するには `q` を押すだけです。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+sudo systemctl status otelcol-contrib
+```
+
+{{% /tab %}}
+{{% tab title="Status Output" %}}
+
+``` text
+● otelcol-contrib.service - OpenTelemetry Collector Contrib
+ Loaded: loaded (/lib/systemd/system/otelcol-contrib.service; enabled; vendor preset: enabled)
+ Active: active (running) since Mon 2024-10-07 10:27:49 BST; 52s ago
+ Main PID: 17113 (otelcol-contrib)
+ Tasks: 13 (limit: 19238)
+ Memory: 34.8M
+ CPU: 155ms
+ CGroup: /system.slice/otelcol-contrib.service
+ └─17113 /usr/bin/otelcol-contrib --config=/etc/otelcol-contrib/config.yaml
+
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Descriptor:
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: -> Name: up
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: -> Description: The scraping was successful
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: -> Unit:
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: -> DataType: Gauge
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: NumberDataPoints #0
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: StartTimestamp: 1970-01-01 00:00:00 +0000 UTC
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Timestamp: 2024-10-07 09:28:36.942 +0000 UTC
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: Value: 1.000000
+Oct 07 10:28:36 petclinic-rum-testing otelcol-contrib[17113]: {"kind": "exporter", "data_type": "metrics", "name": "debug"}
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+これから複数の設定ファイルの変更や環境変数の設定、Collector の再起動を行うため、Collector サービスを停止し、起動時に自動起動しないように無効化します。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+``` bash
+sudo systemctl stop otelcol-contrib && sudo systemctl disable otelcol-contrib
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+---
+
+{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Open Telemetry Collector Builder (ocb) を使って独自の Collector をビルドする{{% /badge %}}" %}}
+このパートでは、システムに以下のものがインストールされている必要があります。
+
+- Golang (最新バージョン)
+
+ ``` bash
+ cd /tmp
+ wget https://golang.org/dl/go1.20.linux-amd64.tar.gz
+ sudo tar -C /usr/local -xzf go1.20.linux-amd64.tar.gz
+ ```
+
+ `.profile` を編集し、以下の環境変数を追加します。
+
+ ``` bash
+ export GOROOT=/usr/local/go
+ export GOPATH=$HOME/go
+ export PATH=$GOPATH/bin:$GOROOT/bin:$PATH
+ ```
+
+ シェルセッションを更新します。
+
+ ``` bash
+ source ~/.profile
+ ```
+
+ Go のバージョンを確認します。
+
+ ``` bash
+ go version
+ ```
+
+- ocb のインストール
+ - [project releases](https://github.com/open-telemetry/opentelemetry-collector/releases/tag/cmd%2Fbuilder%2Fv0.80.0) から ocb バイナリをダウンロードし、以下のコマンドを実行します。
+
+ ```bash
+ mv ocb_0.80.0_darwin_arm64 /usr/bin/ocb
+ chmod 755 /usr/bin/ocb
+ ```
+
+ 別のアプローチとして、golang のツールチェインを使ってバイナリをローカルでビルドする方法もあります。
+
+ ```bash
+ go install go.opentelemetry.io/collector/cmd/builder@v0.80.0
+ mv $(go env GOPATH)/bin/builder /usr/bin/ocb
+ ```
+
+- (オプション) Docker
+
+## なぜ独自の Collector をビルドするのか?
+
+Collector のデフォルトのディストリビューション (core および contrib) は、提供されている内容が多すぎるか、少なすぎるかのいずれかになりがちです。
+
+また、contrib Collector は、デプロイで必要としない可能性が高いコンポーネントが多数インストールされているため、本番環境での実行は推奨されません。
+
+## 独自の Collector をビルドするメリット
+
+独自の Collector バイナリ (一般的にディストリビューションと呼ばれます) を作成することは、必要なものだけをビルドすることを意味します。
+
+メリットは以下のとおりです。
+
+1. バイナリサイズが小さくなる
+2. 既存の Go の脆弱性スキャナーを使用できる
+3. 組織と連携できる内部コンポーネントを含めることができる
+
+## 独自の Collector をビルドする際の考慮事項
+
+さて、🥷 Ninja ゾーンと呼ばれるからには、いくつかの欠点もあります。
+
+1. Go の経験は必須ではないが推奨される
+1. Splunk のサポートは**ありません**
+1. 配布とライフサイクル管理の責任が生じる
+
+プロジェクトは安定化に向けて取り組んでいますが、変更によってワークフローが壊れないという保証はないことに注意してください。Splunk のチームは、より手厚いサポートと高い安定性を提供しており、デプロイのニーズに応じてキュレーションされたエクスペリエンスを提供できます。
+
+## The Ninja Zone
+
+開始するために必要なツールがすべてインストールされたら、`otelcol-builder.yaml` という名前の新しいファイルを作成し、以下のディレクトリ構造に従う必要があります。
+
+``` bash
+.
+└── otelcol-builder.yaml
+```
+
+ファイルを作成したら、追加のメタデータとともにインストールするコンポーネントのリストを追加する必要があります。
+
+この例では、introduction の設定で必要なコンポーネントのみをインストールするビルダーマニフェストを作成します。
+
+```yaml
+dist:
+ name: otelcol-ninja
+ description: A custom build of the Open Telemetry Collector
+ output_path: ./dist
+
+extensions:
+- gomod: go.opentelemetry.io/collector/extension/ballastextension v0.80.0
+- gomod: go.opentelemetry.io/collector/extension/zpagesextension v0.80.0
+- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/httpforwarder v0.80.0
+- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.80.0
+
+exporters:
+- gomod: go.opentelemetry.io/collector/exporter/loggingexporter v0.80.0
+- gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.80.0
+- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/splunkhecexporter v0.80.0
+- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/signalfxexporter v0.80.0
+
+processors:
+- gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.80.0
+- gomod: go.opentelemetry.io/collector/processor/memorylimiterprocessor v0.80.0
+
+receivers:
+- gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.80.0
+- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver v0.80.0
+- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.80.0
+- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.80.0
+- gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/zipkinreceiver v0.80.0
+```
+
+_ocb_ 用の yaml ファイルを更新したら、以下のコマンドを実行します。
+
+```shell
+ocb --config=otelcol-builder.yaml
+```
+
+実行すると、以下のディレクトリ構造になります。
+
+``` text
+├── dist
+│ ├── components.go
+│ ├── components_test.go
+│ ├── go.mod
+│ ├── go.sum
+│ ├── main.go
+│ ├── main_others.go
+│ ├── main_windows.go
+│ └── otelcol-ninja
+└── otelcol-builder.yaml
+```
+
+### References
+
+1. [https://opentelemetry.io/docs/collector/custom-collector/](https://opentelemetry.io/docs/collector/custom-collector/)
+
+{{% /expand %}}
+
+---
+
+## デフォルトの設定
+
+OpenTelemetry は YAML ファイルを通じて設定されます。これらのファイルにはデフォルトの設定があり、ニーズに合わせて変更できます。提供されているデフォルトの設定を見てみましょう。
+
+{{< tabs >}}
+{{% tab title="Command" %}}
+
+```bash
+cat /etc/otelcol-contrib/config.yaml
+```
+
+{{% /tab %}}
+{{% tab title="config.yaml" %}}
+
+```yaml { lineNos="table" wrap="true"}
+# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
+# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks
+
+extensions:
+ health_check:
+ pprof:
+ endpoint: 0.0.0.0:1777
+ zpages:
+ endpoint: 0.0.0.0:55679
+
+receivers:
+ otlp:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:4317
+ http:
+ endpoint: 0.0.0.0:4318
+
+ opencensus:
+ endpoint: 0.0.0.0:55678
+
+ # Collect own metrics
+ prometheus:
+ config:
+ scrape_configs:
+ - job_name: 'otel-collector'
+ scrape_interval: 10s
+ static_configs:
+ - targets: ['0.0.0.0:8888']
+
+ jaeger:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:14250
+ thrift_binary:
+ endpoint: 0.0.0.0:6832
+ thrift_compact:
+ endpoint: 0.0.0.0:6831
+ thrift_http:
+ endpoint: 0.0.0.0:14268
+
+ zipkin:
+ endpoint: 0.0.0.0:9411
+
+processors:
+ batch:
+
+exporters:
+ debug:
+ verbosity: detailed
+
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [otlp, opencensus, prometheus]
+ processors: [batch]
+ exporters: [debug]
+
+ logs:
+ receivers: [otlp]
+ processors: [batch]
+ exporters: [debug]
+
+ extensions: [health_check, pprof, zpages]
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+おめでとうございます! OpenTelemetry Collector のダウンロードとインストールに成功しました。OTel Ninja への道のりは順調です。しかし、その前に、設定ファイルと OpenTelemetry Collector のさまざまなディストリビューションについて見ていきましょう。
+
+{{% notice style="note" %}}
+
+Splunk は、完全にサポートされた独自の OpenTelemetry Collector ディストリビューションを提供しています。このディストリビューションは、[**Splunk GitHub Repository**](https://github.com/signalfx/splunk-otel-collector) からインストールできるほか、Splunk Observability Cloud のウィザードを使ってシンプルなインストールスクリプトをコピー&ペーストする形でも利用できます。このディストリビューションには、OpenTelemetry Collector Contrib ディストリビューションでは利用できない多くの追加機能と拡張機能が含まれています。
+
+- Splunk Distribution of the OpenTelemetry Collector は本番環境でテスト済みです。多くのお客様が本番環境で使用しています。
+- 当社のディストリビューションを利用するお客様は、SLA の範囲内で公式の Splunk サポートから直接支援を受けられます。
+- お客様は、メトリクスとトレース収集に関するコア設定エクスペリエンスにおける将来の破壊的変更を心配することなく、Splunk Distribution of the OpenTelemetry Collector を使用または移行できます (OpenTelemetry のログ収集設定はベータ版です)。Collector のメトリクスについては破壊的変更がある可能性があります。
+
+{{% /notice %}}
+
+これから設定ファイルの各セクションを順に見ていき、ホストメトリクスを Splunk Observability Cloud に送信するように変更します。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md
new file mode 100644
index 0000000000..e95aad38d3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md
@@ -0,0 +1,41 @@
+---
+title: OpenTelemetry Collector Contrib のインストール
+linkTitle: 1. インストール
+weight: 1
+---
+
+## OpenTelemetry Collector Contrib ディストリビューションのダウンロード
+
+OpenTelemetry Collector をインストールする最初のステップは、ダウンロードすることです。本ラボでは、`wget` コマンドを使用して OpenTelemetry の GitHub リポジトリから `.deb` パッケージをダウンロードします。
+
+お使いのプラットフォーム向けの `.deb` パッケージを [**OpenTelemetry Collector Contrib releases page**](https://github.com/open-telemetry/opentelemetry-collector-releases/releases) から取得してください。
+
+``` bash
+wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.111.0/otelcol-contrib_0.111.0_linux_amd64.deb
+```
+
+## OpenTelemetry Collector Contrib ディストリビューションのインストール
+
+`dpkg` を使用して `.deb` パッケージをインストールします。インストールが成功した際の出力例については、下記の **dpkg Output** タブをご確認ください。
+
+{{< tabs >}}
+{{% tab title="Install" %}}
+
+``` bash
+sudo dpkg -i otelcol-contrib_0.111.0_linux_amd64.deb
+```
+
+{{% /tab %}}
+{{% tab title="dpkg Output" %}}
+
+``` text
+Selecting previously unselected package otelcol-contrib.
+(Reading database ... 89232 files and directories currently installed.)
+Preparing to unpack otelcol-contrib_0.111.0_linux_amd64.deb ...
+Unpacking otelcol-contrib (0.111.0) ...
+Setting up otelcol-contrib (0.111.0) ...
+Created symlink /etc/systemd/system/multi-user.target.wants/otelcol-contrib.service → /lib/systemd/system/otelcol-contrib.service.
+```
+
+{{% /tab %}}
+{{< /tabs >}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md
new file mode 100644
index 0000000000..349b38802f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md
@@ -0,0 +1,58 @@
+---
+title: OpenTelemetry Collector Extensions
+linkTitle: 2.1 Health Check
+weight: 1
+---
+
+## Health Check
+
+Extensions は、インストール手順で参照したのと同じ `config.yaml` ファイル内で構成します。`config.yaml` ファイルを編集して Extensions を構成しましょう。なお、**pprof** および **zpages** Extension はデフォルトの `config.yaml` ファイルですでに構成されています。このワークショップでは、Collector のヘルス状態にアクセスできるポートをすべてのネットワークインターフェースで公開するため、**health_check** Extension のみを更新します。
+
+{{% tab title="Command" %}}
+
+``` bash
+sudo vi /etc/otelcol-contrib/config.yaml
+```
+
+{{% /tab %}}
+
+{{% tab title="Extensions Configuration" %}}
+
+```yaml {hl_lines="3"}
+extensions:
+ health_check:
+ endpoint: 0.0.0.0:13133
+```
+
+{{% /tab %}}
+
+Collector を起動します:
+
+{{% tab title="Command" %}}
+
+``` bash
+otelcol-contrib --config=file:/etc/otelcol-contrib/config.yaml
+```
+
+{{% /tab %}}
+
+この Extension は、OpenTelemetry Collector のステータスをチェックするためにプローブできる HTTP URL を有効化します。この Extension は、Kubernetes の liveness プローブや readiness プローブとしても使用できます。`curl` コマンドの詳細については、[curl man page](https://curl.se/docs/manpage.html) を参照してください。
+
+新しいターミナルセッションを開いてインスタンスに SSH 接続し、次のコマンドを実行します:
+
+{{< tabs >}}
+{{% tab title="curl Command" %}}
+
+```bash
+curl http://localhost:13133
+```
+
+{{% /tab %}}
+{{% tab title="curl Output" %}}
+
+``` text
+{"status":"Server available","upSince":"2024-10-07T11:00:08.004685295+01:00","uptime":"12.56420005s"}
+```
+
+{{% /tab %}}
+{{< /tabs >}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md
new file mode 100644
index 0000000000..9e104197f8
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md
@@ -0,0 +1,9 @@
+---
+title: OpenTelemetry Collector Extensions
+linkTitle: 2.2 Performance Profiler
+weight: 2
+---
+
+## Performance Profiler
+
+[**Performance Profiler**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/extension/pprofextension/README.md) extension は、golang net/http/pprof エンドポイントを有効にします。これは通常、開発者がパフォーマンスプロファイルを収集し、サービスの問題を調査するために使用されます。**このワークショップでは扱いません**。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md
new file mode 100644
index 0000000000..83c8df6784
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md
@@ -0,0 +1,363 @@
+---
+title: OpenTelemetry Collector Extensions
+linkTitle: 2.3 zPages
+weight: 3
+---
+
+## zPages
+
+[**zPages**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/extension/zpagesextension/README.md) は、外部 exporter の代替となるインプロセスの仕組みです。有効化すると、トレースとメトリクスの情報をバックグラウンドで収集および集約し、リクエストに応じて Web ページとして提供します。zPages は Collector が想定どおりに動作していることを確認するうえで非常に有用な診断機能です。
+
+{{< tabs >}}
+{{% tab title="ServiceZ" %}}
+
+**ServiceZ** は Collector のサービス概要を提供し、pipelinez、extensionz、featurez の各 zPages へすばやくアクセスできるようにします。このページではビルド情報やランタイム情報も確認できます。
+
+URL の例: [**http://localhost:55679/debug/servicez**](http://localhost:55679/debug/servicez) （`localhost` は実際の環境に合わせて変更してください）。
+
+
+
+{{% /tab %}}
+{{% tab title="PipelineZ" %}}
+
+**PipelineZ** は Collector で稼働中のパイプラインに関する情報を提供します。タイプ、データが変換されるかどうか、各パイプラインで利用されている receiver、processor、exporter の情報を確認できます。
+
+URL の例: [**http://localhost:55679/debug/pipelinez**](http://localhost:55679/debug/pipelinez) （`localhost` は実際の環境に合わせて変更してください）。
+
+
+
+{{% /tab %}}
+{{% tab title="ExtensionZ" %}}
+
+**ExtensionZ** は Collector でアクティブになっている extension を表示します。
+
+URL の例: [**http://localhost:55679/debug/extensionz**](http://localhost:55679/debug/extensionz) （`localhost` は実際の環境に合わせて変更してください）。
+
+
+
+{{% /tab %}}
+{{% /tabs %}}
+
+---
+
+{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** storage extension でデータの耐久性を高める{{% /badge %}}" %}}
+
+これを行うには、利用しているディストリビューションに `file_storage` extension がインストールされていることを確認する必要があります。これは `otelcol-contrib components` コマンドを実行することで確認でき、次のような結果が表示されます。
+
+{{< tabs >}}
+{{% tab title="Truncated Output" %}}
+
+```yaml
+# ... truncated for clarity
+extensions:
+ - file_storage
+```
+
+{{% /tab %}}
+{{% tab title="Full Output" %}}
+
+```yaml
+buildinfo:
+ command: otelcol-contrib
+ description: OpenTelemetry Collector Contrib
+ version: 0.80.0
+receivers:
+ - prometheus_simple
+ - apache
+ - influxdb
+ - purefa
+ - purefb
+ - receiver_creator
+ - mongodbatlas
+ - vcenter
+ - snmp
+ - expvar
+ - jmx
+ - kafka
+ - skywalking
+ - udplog
+ - carbon
+ - kafkametrics
+ - memcached
+ - prometheus
+ - windowseventlog
+ - zookeeper
+ - otlp
+ - awsecscontainermetrics
+ - iis
+ - mysql
+ - nsxt
+ - aerospike
+ - elasticsearch
+ - httpcheck
+ - k8sobjects
+ - mongodb
+ - hostmetrics
+ - signalfx
+ - statsd
+ - awsxray
+ - cloudfoundry
+ - collectd
+ - couchdb
+ - kubeletstats
+ - jaeger
+ - journald
+ - riak
+ - splunk_hec
+ - active_directory_ds
+ - awscloudwatch
+ - sqlquery
+ - windowsperfcounters
+ - flinkmetrics
+ - googlecloudpubsub
+ - podman_stats
+ - wavefront
+ - k8s_events
+ - postgresql
+ - rabbitmq
+ - sapm
+ - sqlserver
+ - redis
+ - solace
+ - tcplog
+ - awscontainerinsightreceiver
+ - awsfirehose
+ - bigip
+ - filelog
+ - googlecloudspanner
+ - cloudflare
+ - docker_stats
+ - k8s_cluster
+ - pulsar
+ - zipkin
+ - nginx
+ - opencensus
+ - azureeventhub
+ - datadog
+ - fluentforward
+ - otlpjsonfile
+ - syslog
+processors:
+ - resource
+ - batch
+ - cumulativetodelta
+ - groupbyattrs
+ - groupbytrace
+ - k8sattributes
+ - experimental_metricsgeneration
+ - metricstransform
+ - routing
+ - attributes
+ - datadog
+ - deltatorate
+ - spanmetrics
+ - span
+ - memory_limiter
+ - redaction
+ - resourcedetection
+ - servicegraph
+ - transform
+ - filter
+ - probabilistic_sampler
+ - tail_sampling
+exporters:
+ - otlp
+ - carbon
+ - datadog
+ - f5cloud
+ - kafka
+ - mezmo
+ - skywalking
+ - awsxray
+ - dynatrace
+ - loki
+ - prometheus
+ - logging
+ - azuredataexplorer
+ - azuremonitor
+ - instana
+ - jaeger
+ - loadbalancing
+ - sentry
+ - splunk_hec
+ - tanzuobservability
+ - zipkin
+ - alibabacloud_logservice
+ - clickhouse
+ - file
+ - googlecloud
+ - prometheusremotewrite
+ - awscloudwatchlogs
+ - googlecloudpubsub
+ - jaeger_thrift
+ - logzio
+ - sapm
+ - sumologic
+ - otlphttp
+ - googlemanagedprometheus
+ - opencensus
+ - awskinesis
+ - coralogix
+ - influxdb
+ - logicmonitor
+ - signalfx
+ - tencentcloud_logservice
+ - awsemf
+ - elasticsearch
+ - pulsar
+extensions:
+ - zpages
+ - bearertokenauth
+ - oidc
+ - host_observer
+ - sigv4auth
+ - file_storage
+ - memory_ballast
+ - health_check
+ - oauth2client
+ - awsproxy
+ - http_forwarder
+ - jaegerremotesampling
+ - k8s_observer
+ - pprof
+ - asapclient
+ - basicauth
+ - headers_setter
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+この extension は、exporter が設定済みのエンドポイントへデータを送信できない場合に、ディスクへデータをキューイングする機能を提供します。
+
+この extension を構成するには、以下の情報を含むように設定を更新する必要があります。最初に /tmp/otel-data ディレクトリを作成し、読み書き権限を付与してください。
+
+```yaml
+extensions:
+...
+ file_storage:
+ directory: /tmp/otel-data
+ timeout: 10s
+ compaction:
+ directory: /tmp/otel-data
+ on_start: true
+ on_rebound: true
+ rebound_needed_threshold_mib: 5
+ rebound_trigger_threshold_mib: 3
+
+# ... truncated for clarity
+
+service:
+ extensions: [health_check, pprof, zpages, file_storage]
+```
+
+## なぜデータをディスクへキューイングするのか?
+
+これにより Collector はネットワーク中断（さらには Collector の再起動）にも耐えられるようになり、データが上流のプロバイダーに確実に送信されることを保証できます。
+
+## データをディスクへキューイングする際の考慮事項
+
+ディスクのパフォーマンス次第では、データのスループット性能に影響が出る可能性があります。
+
+### 参考資料
+
+1. [https://community.splunk.com/t5/Community-Blog/Data-Persistence-in-the-OpenTelemetry-Collector/ba-p/624583](https://community.splunk.com/t5/Community-Blog/Data-Persistence-in-the-OpenTelemetry-Collector/ba-p/624583)
+2. [https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/storage/filestorage](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/storage/filestorage)
+
+{{% /expand %}}
+
+---
+
+## 設定の確認
+
+extension について一通り確認したので、設定の変更内容をチェックしましょう。
+
+---
+
+{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定を確認する{{% /badge %}}" %}}
+{{< tabs >}}
+{{% tab title="config.yaml" %}}
+
+```yaml { lineNos="table" wrap="true" hl_lines="5" }
+# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks
+
+extensions:
+ health_check:
+ endpoint: 0.0.0.0:13133
+ pprof:
+ endpoint: 0.0.0.0:1777
+ zpages:
+ endpoint: 0.0.0.0:55679
+
+receivers:
+ otlp:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:4317
+ http:
+ endpoint: 0.0.0.0:4318
+
+ opencensus:
+ endpoint: 0.0.0.0:55678
+
+ # Collect own metrics
+ prometheus:
+ config:
+ scrape_configs:
+ - job_name: 'otel-collector'
+ scrape_interval: 10s
+ static_configs:
+ - targets: ['0.0.0.0:8888']
+
+ jaeger:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:14250
+ thrift_binary:
+ endpoint: 0.0.0.0:6832
+ thrift_compact:
+ endpoint: 0.0.0.0:6831
+ thrift_http:
+ endpoint: 0.0.0.0:14268
+
+ zipkin:
+ endpoint: 0.0.0.0:9411
+
+processors:
+ batch:
+
+exporters:
+ debug:
+ verbosity: detailed
+
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [otlp, opencensus, prometheus]
+ processors: [batch]
+ exporters: [debug]
+
+ logs:
+ receivers: [otlp]
+ processors: [batch]
+ exporters: [debug]
+
+ extensions: [health_check, pprof, zpages]
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+{{% /expand %}}
+
+---
+
+extension の確認が完了したので、ワークショップのデータパイプラインの部分に進みましょう。パイプラインとは、Collector におけるデータの経路を定義するもので、データの受信から始まり、追加の処理や変換を経て、最終的に exporter を介して Collector から出ていくまでを指します。
+
+OpenTelemetry Collector のデータパイプラインは、**receiver**、**processor**、**exporter** で構成されています。まずは receiver から見ていきます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md
new file mode 100644
index 0000000000..da7e0a1276
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md
@@ -0,0 +1,37 @@
+---
+title: OpenTelemetry Collector Extensions
+linkTitle: 2. Extensions
+weight: 2
+---
+
+OpenTelemetry Collector のインストールが完了したので、次は OpenTelemetry Collector の拡張機能 (Extensions) について見ていきましょう。Extensions はオプションであり、主にテレメトリデータの処理を伴わないタスク向けに提供されます。Extensions の例としては、ヘルスモニタリング、サービスディスカバリ、データ転送などがあります。
+
+{{< mermaid >}}
+%%{
+ init:{
+ "theme": "base",
+ "themeVariables": {
+ "primaryColor": "#ffffff",
+ "clusterBkg": "#eff2fb",
+ "defaultLinkColor": "#333333"
+ }
+ }
+}%%
+
+flowchart LR;
+ style E fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
+ subgraph Collector
+ A[OTLP] --> M(Receivers)
+ B[JAEGER] --> M(Receivers)
+ C[Prometheus] --> M(Receivers)
+ end
+ subgraph Processors
+ M(Receivers) --> H(Filters, Attributes, etc)
+ E(Extensions)
+ end
+ subgraph Exporters
+ H(Filters, Attributes, etc) --> S(OTLP)
+ H(Filters, Attributes, etc) --> T(JAEGER)
+ H(Filters, Attributes, etc) --> U(Prometheus)
+ end
+{{< /mermaid >}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md
new file mode 100644
index 0000000000..1d38fea4f9
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md
@@ -0,0 +1,44 @@
+---
+title: OpenTelemetry Collector Receivers
+linkTitle: 1. Host Metrics
+weight: 1
+---
+
+## Host Metrics Receiver
+
+[**The Host Metrics Receiver**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/README.md) は、さまざまなソースからスクレイピングしたホストシステムに関するメトリクスを生成します。これは Collector がエージェントとしてデプロイされる際に使用することを想定しており、本ワークショップでもその構成で進めます。
+
+`/etc/otel-contrib/config.yaml` ファイルを更新して **hostmetrics** receiver を設定しましょう。**receivers** セクションの下に、次の YAML を 2 スペースのインデントに注意して挿入してください。
+
+``` bash
+sudo vi /etc/otelcol-contrib/config.yaml
+```
+
+{{% tab title="Host Metrics Receiver Configuration" %}}
+
+```yaml {hl_lines="2-22"}
+receivers:
+ hostmetrics:
+ collection_interval: 10s
+ scrapers:
+ # CPU utilization metrics
+ cpu:
+ # Disk I/O metrics
+ disk:
+ # File System utilization metrics
+ filesystem:
+ # Memory utilization metrics
+ memory:
+ # Network interface I/O metrics & TCP connection metrics
+ network:
+ # CPU load metrics
+ load:
+ # Paging/Swap space utilization and I/O metrics
+ paging:
+ # Process count metrics
+ processes:
+ # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
+ # process:
+```
+
+{{% /tab %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md
new file mode 100644
index 0000000000..c831bdb32f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md
@@ -0,0 +1,35 @@
+---
+title: OpenTelemetry Collector Receivers
+linkTitle: 2. Prometheus
+weight: 2
+---
+
+## Prometheus Receiver
+
+**prometheus** という別の receiver にも気づくはずです。[**Prometheus**](https://prometheus.io/docs/introduction/overview/) は OpenTelemetry Collector で利用されているオープンソースのツールキットです。この receiver は OpenTelemetry Collector 自身からメトリクスをスクレイピングするために使用されます。これらのメトリクスは Collector の健全性を監視するために利用できます。
+
+`prometheus` receiver が Collector 自身からメトリクスを収集していることを明確に示すよう変更してみましょう。receiver の名前を `prometheus` から `prometheus/internal` に変更することで、その receiver が何をしているのかがより分かりやすくなります。設定ファイルを以下のように更新します:
+
+{{% tab title="Prometheus Receiver Configuration" %}}
+
+```yaml {hl_lines="1"}
+prometheus/internal:
+ config:
+ scrape_configs:
+ - job_name: 'otel-collector'
+ scrape_interval: 10s
+ static_configs:
+ - targets: ['0.0.0.0:8888']
+```
+
+{{% /tab %}}
+
+## ダッシュボードの例 - Prometheus メトリクス
+
+次のスクリーンショットは、Prometheus internal receiver が OpenTelemetry Collector から収集するメトリクスのいくつかをダッシュボードで示した例です。ここでは、受け入れられた、および送信された spans、metrics、log records を確認できます。
+
+{{% notice style="note" %}}
+次のスクリーンショットは、Splunk Observability Cloud のすぐに使える (OOTB) ダッシュボードであり、Splunk OpenTelemetry Collector のインストール基盤を簡単に監視できます。
+{{% /notice %}}
+
+
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md
new file mode 100644
index 0000000000..e9766c9f53
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md
@@ -0,0 +1,170 @@
+---
+title: OpenTelemetry Collector Receivers
+linkTitle: 3. Other Receivers
+weight: 3
+---
+
+## その他のReceiver
+
+デフォルト設定には他にも **otlp**、**opencensus**、**jaeger**、**zipkin** といったReceiverが含まれていることに気付くでしょう。これらは他のソースからテレメトリデータを受信するために使われます。本ワークショップではこれらのReceiverは扱わないため、そのままにしておいて構いません。
+
+---
+
+{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Receiverを動的に作成する{{% /badge %}}" %}}
+
+dockerコンテナ、kubernetes pod、sshセッションなどの短命なタスクを観測するために、[receiver creator](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/receivercreator) と [observer extensions](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/observer) を使って、これらのサービスが起動した際に新しいReceiverを作成することができます。
+
+## 必要なもの
+
+receiver creatorと関連するobserver extensionsを使い始めるには、これらをCollectorのビルドマニフェストに含める必要があります。
+
+詳細は [installation](../1-installation/) を参照してください。
+
+## 考慮すべきこと
+
+短命なタスクの中には、_username_ や _password_ などの追加設定が必要になるものもあります。
+これらの値は [environment variables](https://opentelemetry.io/docs/collector/configuration/#configuration-environment-variables) で参照したり、`${file:./path/to/database/password}` のようなscheme expand構文を使うことができます。
+この方法を取る場合は、所属組織のシークレット管理ポリシーに従ってください。
+
+## The Ninja Zone
+
+このninja zoneで必要なのは2つだけです。
+
+1. receiver createrとobserver extensionsをbuilderマニフェストに追加していることを確認する。
+2. 検出されたエンドポイントとマッチングするための設定を作成する。
+
+テンプレート化された設定を作成するには、次のようにします。
+
+```yaml
+receiver_creator:
+ watch_observers: [host_observer]
+ receivers:
+ redis:
+ rule: type == "port" && port == 6379
+ config:
+ password: ${env:HOST_REDIS_PASSWORD}
+```
+
+その他の例は、こちらの [receiver creator's examples](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/receivercreator#examples) を参照してください。
+
+{{% /expand %}}
+
+---
+
+## 設定のチェックイン
+
+ここまででReceiverについて説明したので、設定の変更内容を確認してみましょう。
+
+---
+
+{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定を確認する{{% /badge %}}" %}}
+{{< tabs >}}
+{{% tab title="config.yaml" %}}
+
+```yaml {lineNos="table" wrap="true" hl_lines="13-33 45"}
+# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
+# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks
+
+extensions:
+ health_check:
+ endpoint: 0.0.0.0:13133
+ pprof:
+ endpoint: 0.0.0.0:1777
+ zpages:
+ endpoint: 0.0.0.0:55679
+
+receivers:
+ hostmetrics:
+ collection_interval: 10s
+ scrapers:
+ # CPU utilization metrics
+ cpu:
+ # Disk I/O metrics
+ disk:
+ # File System utilization metrics
+ filesystem:
+ # Memory utilization metrics
+ memory:
+ # Network interface I/O metrics & TCP connection metrics
+ network:
+ # CPU load metrics
+ load:
+ # Paging/Swap space utilization and I/O metrics
+ paging:
+ # Process count metrics
+ processes:
+ # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
+ # process:
+ otlp:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:4317
+ http:
+ endpoint: 0.0.0.0:4318
+
+ opencensus:
+ endpoint: 0.0.0.0:55678
+
+ # Collect own metrics
+ prometheus/internal:
+ config:
+ scrape_configs:
+ - job_name: 'otel-collector'
+ scrape_interval: 10s
+ static_configs:
+ - targets: ['0.0.0.0:8888']
+
+ jaeger:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:14250
+ thrift_binary:
+ endpoint: 0.0.0.0:6832
+ thrift_compact:
+ endpoint: 0.0.0.0:6831
+ thrift_http:
+ endpoint: 0.0.0.0:14268
+
+ zipkin:
+ endpoint: 0.0.0.0:9411
+
+processors:
+ batch:
+
+exporters:
+ debug:
+ verbosity: detailed
+
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [otlp, opencensus, prometheus]
+ processors: [batch]
+ exporters: [debug]
+
+ logs:
+ receivers: [otlp]
+ processors: [batch]
+ exporters: [debug]
+
+ extensions: [health_check, pprof, zpages]
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+{{% /expand %}}
+
+---
+
+ReceiverによってOpenTelemetry Collectorにデータが入ってくる仕組みを確認したので、次はCollectorが受信したデータをどのように処理するかを見ていきましょう。
+
+{{% notice style="warning" %}}
+`/etc/otelcol-contrib/config.yaml` はまだ完成していないため、この時点ではCollectorを再起動 **しないでください**。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md
new file mode 100644
index 0000000000..8d75ac99cc
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md
@@ -0,0 +1,39 @@
+---
+title: OpenTelemetry Collector Receivers
+linkTitle: 3. Receivers
+weight: 3
+---
+
+ワークショップの receiver パートへようこそ！ここは OpenTelemetry Collector におけるデータパイプラインの起点となる部分です。さっそく見ていきましょう。
+
+receiver は push 型または pull 型のいずれかで動作し、Collector にデータを取り込む仕組みです。receiver は 1 つ以上のデータソースをサポートできます。一般的に、receiver は指定されたフォーマットでデータを受け取り、それを内部フォーマットに変換したうえで、該当するパイプラインに定義された processor や exporter へ受け渡します。
+
+{{< mermaid >}}
+%%{
+ init:{
+ "theme":"base",
+ "themeVariables": {
+ "primaryColor": "#ffffff",
+ "clusterBkg": "#eff2fb",
+ "defaultLinkColor": "#333333"
+ }
+ }
+}%%
+
+flowchart LR;
+ style M fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
+ subgraph Collector
+ A[OTLP] --> M(Receivers)
+ B[JAEGER] --> M(Receivers)
+ C[Prometheus] --> M(Receivers)
+ end
+ subgraph Processors
+ M(Receivers) --> H(Filters, Attributes, etc)
+ E(Extensions)
+ end
+ subgraph Exporters
+ H(Filters, Attributes, etc) --> S(OTLP)
+ H(Filters, Attributes, etc) --> T(JAEGER)
+ H(Filters, Attributes, etc) --> U(Prometheus)
+ end
+{{< /mermaid >}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md
new file mode 100644
index 0000000000..66f5f0f358
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md
@@ -0,0 +1,15 @@
+---
+title: OpenTelemetry Collector Processors
+linkTitle: 4.1 Batch
+weight: 1
+---
+
+## Batch Processor
+
+デフォルトでは、**batch** プロセッサーのみが有効になっています。このプロセッサーは、データをエクスポートする前にバッチ処理するために使用されます。これにより、エクスポーターへのネットワーク呼び出し回数を削減できます。本ワークショップでは、Collector にハードコードされている以下のデフォルト値を継承します。
+
+- `send_batch_size` (default = 8192): タイムアウトに関わらずバッチが送信される、スパン、メトリックデータポイント、またはログレコードの数です。send_batch_size はトリガーとして機能し、バッチのサイズには影響しません。パイプラインの次のコンポーネントに送信するバッチサイズの上限を強制したい場合は、send_batch_max_size を参照してください。
+- `timeout` (default = 200ms): サイズに関わらずバッチが送信されるまでの時間です。ゼロに設定すると、send_batch_size は無視され、データは send_batch_max_size のみを条件として直ちに送信されます。
+- `send_batch_max_size` (default = 0): バッチサイズの上限です。0 はバッチサイズに上限がないことを意味します。このプロパティは、より大きなバッチが小さな単位に分割されることを保証します。send_batch_size 以上の値である必要があります。
+
+Batch プロセッサーの詳細については、[**Batch Processor documentation**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/batchprocessor/README.md) を参照してください。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md
new file mode 100644
index 0000000000..5bdbf9bd18
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md
@@ -0,0 +1,53 @@
+---
+title: OpenTelemetry Collector Processors
+linkTitle: 4.2 Resource Detection
+weight: 2
+---
+
+## Resource Detection Processor
+
+**resourcedetection** プロセッサーは、ホストからリソース情報を検出し、その情報をテレメトリーデータのリソース値として追加または上書きするために使用できます。
+
+デフォルトでは、可能な場合は FQDN がホスト名として設定され、それ以外の場合は OS が提供するホスト名がフォールバックとして使用されます。この動作は `hostname_sources` 設定オプションを使用して変更できます。FQDN の取得を避けて OS が提供するホスト名を使用するために、`hostname_sources` を `os` に設定します。
+
+{{% tab title="System Resource Detection Processor Configuration" %}}
+
+``` yaml {hl_lines="3-7"}
+processors:
+ batch:
+ resourcedetection/system:
+ detectors: [system]
+ system:
+ hostname_sources: [os]
+```
+
+{{% /tab %}}
+
+ワークショップのインスタンスが AWS/EC2 インスタンス上で実行されている場合、EC2 メタデータ API から以下のタグを取得できます（これは他のプラットフォームでは利用できません）。
+
+- `cloud.provider ("aws")`
+- `cloud.platform ("aws_ec2")`
+- `cloud.account.id`
+- `cloud.region`
+- `cloud.availability_zone`
+- `host.id`
+- `host.image.id`
+- `host.name`
+- `host.type`
+
+これらのタグをメトリクスに追加するために、もう1つのプロセッサーを作成します。
+
+{{% tab title="EC2 Resource Detection Processor Configuration" %}}
+
+``` yaml {hl_lines="7-8"}
+processors:
+ batch:
+ resourcedetection/system:
+ detectors: [system]
+ system:
+ hostname_sources: [os]
+ resourcedetection/ec2:
+ detectors: [ec2]
+```
+
+{{% /tab %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md
new file mode 100644
index 0000000000..802240b19f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md
@@ -0,0 +1,200 @@
+---
+title: OpenTelemetry Collector Processors
+linkTitle: 4.3 Attributes
+weight: 3
+---
+
+## Attributes Processor
+
+attributes processor は、span、log、metric の属性を変更します。このプロセッサーは、入力データをフィルタリング・マッチングして、指定したアクションの対象に含めるか除外するかを判定する機能もサポートしています。
+
+設定で指定された順番で実行される一連のアクションを受け取ります。サポートされているアクションは次のとおりです。
+
+- `insert`: キーがまだ存在しない場合に、入力データへ新しい属性を挿入します。
+- `update`: キーが存在する場合に、入力データの属性を更新します。
+- `upsert`: insert または update を実行します。キーが存在しない場合は新しい属性を挿入し、キーが存在する場合は属性を更新します。
+- `delete`: 入力データから属性を削除します。
+- `hash`: 既存の属性値をハッシュ化（SHA1）します。
+- `extract`: 正規表現ルールを使用して、入力キーからルールに指定されたターゲットキーへ値を抽出します。ターゲットキーが既に存在する場合は上書きされます。
+
+これから、すべてのホストメトリクスに `participant.name` という新しい属性を `insert` する attributes processor を作成します。値にはご自身の名前（例: `marge_simpson`）を設定します。
+
+{{% notice style="warning" %}}
+
+`INSERT_YOUR_NAME_HERE` は必ずご自身の名前に置き換えてください。また、名前にスペースを **使用しない** ようにしてください。
+
+{{% /notice %}}
+
+ワークショップの後半では、この属性を使用して Splunk Observability Cloud のメトリクスをフィルタリングします。
+
+{{% tab title="Attributes Processor Configuration" %}}
+
+``` yaml {hl_lines="9-13"}
+processors:
+ batch:
+ resourcedetection/system:
+ detectors: [system]
+ system:
+ hostname_sources: [os]
+ resourcedetection/ec2:
+ detectors: [ec2]
+ attributes/conf:
+ actions:
+ - key: participant.name
+ action: insert
+ value: "INSERT_YOUR_NAME_HERE"
+```
+
+{{%/ tab %}}
+
+---
+
+{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Using connectors to gain internal insights{{% /badge %}}" %}}
+
+Collector に最近追加されたものの一つに [**connector**](https://opentelemetry.io/docs/collector/configuration/#connectors) という概念があり、あるパイプラインの出力を別のパイプラインの入力につなぐことができます。
+
+これがどのように役立つかの例として、エクスポートされたデータポイントの量、エラーステータスを含むログの数、あるデプロイ環境から送信されたデータの量に基づいてメトリクスを発行するサービスがあります。count connector はこれを標準で対応してくれます。
+
+## なぜプロセッサーではなくコネクターなのか?
+
+プロセッサーは、処理したデータをそのまま渡さなければならないため、追加で生成できるデータが限られており、追加情報を公開するのが困難です。コネクターは受け取ったデータをそのまま発行する必要がないため、求めているインサイトを生み出す機会を提供してくれます。
+
+例えば、デプロイ環境属性を持たないログ、メトリクス、トレースの数をカウントするコネクターを作成できます。
+
+非常にシンプルな例として、デプロイ環境ごとにデータ使用量を分解して出力できます。
+
+## コネクターを使う際の考慮事項
+
+コネクターは、あるパイプラインからエクスポートされ、別のパイプラインで受信されるデータのみを受け付けます。これを活用するためには、Collector の設定をどのように構成するかを考慮する必要があります。
+
+## References
+
+1. [**https://opentelemetry.io/docs/collector/configuration/#connectors**](https://opentelemetry.io/docs/collector/configuration/#connectors)
+2. [**https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/countconnector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/countconnector)
+
+{{% /expand %}}
+
+---
+
+## Configuration Check-in
+
+プロセッサーについては以上です。設定の変更内容を確認してみましょう。
+
+---
+
+{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}Review your configuration{{% /badge %}}" %}}
+{{< tabs >}}
+{{% tab title="config.yaml" %}}
+
+```yaml {lineNos="table" wrap="true" hl_lines="69-79"}
+# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
+# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks
+
+extensions:
+ health_check:
+ endpoint: 0.0.0.0:13133
+ pprof:
+ endpoint: 0.0.0.0:1777
+ zpages:
+ endpoint: 0.0.0.0:55679
+
+receivers:
+ hostmetrics:
+ collection_interval: 10s
+ scrapers:
+ # CPU utilization metrics
+ cpu:
+ # Disk I/O metrics
+ disk:
+ # File System utilization metrics
+ filesystem:
+ # Memory utilization metrics
+ memory:
+ # Network interface I/O metrics & TCP connection metrics
+ network:
+ # CPU load metrics
+ load:
+ # Paging/Swap space utilization and I/O metrics
+ paging:
+ # Process count metrics
+ processes:
+ # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
+ # process:
+ otlp:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:4317
+ http:
+ endpoint: 0.0.0.0:4318
+
+ opencensus:
+ endpoint: 0.0.0.0:55678
+
+ # Collect own metrics
+ prometheus/internal:
+ config:
+ scrape_configs:
+ - job_name: 'otel-collector'
+ scrape_interval: 10s
+ static_configs:
+ - targets: ['0.0.0.0:8888']
+
+ jaeger:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:14250
+ thrift_binary:
+ endpoint: 0.0.0.0:6832
+ thrift_compact:
+ endpoint: 0.0.0.0:6831
+ thrift_http:
+ endpoint: 0.0.0.0:14268
+
+ zipkin:
+ endpoint: 0.0.0.0:9411
+
+processors:
+ batch:
+ resourcedetection/system:
+ detectors: [system]
+ system:
+ hostname_sources: [os]
+ resourcedetection/ec2:
+ detectors: [ec2]
+ attributes/conf:
+ actions:
+ - key: participant.name
+ action: insert
+ value: "INSERT_YOUR_NAME_HERE"
+
+exporters:
+ debug:
+ verbosity: detailed
+
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [otlp, opencensus, prometheus]
+ processors: [batch]
+ exporters: [debug]
+
+ logs:
+ receivers: [otlp]
+ processors: [batch]
+ exporters: [debug]
+
+ extensions: [health_check, pprof, zpages]
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+{{% /expand %}}
+
+---
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md
new file mode 100644
index 0000000000..54ee4e4052
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md
@@ -0,0 +1,37 @@
+---
+title: OpenTelemetry Collector Processors
+linkTitle: 4. Processors
+weight: 4
+---
+
+[**Processors**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/README.md) は、データが受信されてからエクスポートされるまでの間に実行されます。Processors はオプションですが、推奨されるものもあります。OpenTelemetry contrib Collector には [**多数の Processors**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor) が含まれています。
+
+{{< mermaid >}}
+%%{
+ init:{
+ "theme":"base",
+ "themeVariables": {
+ "primaryColor": "#ffffff",
+ "clusterBkg": "#eff2fb",
+ "defaultLinkColor": "#333333"
+ }
+ }
+}%%
+
+flowchart LR;
+ style Processors fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
+ subgraph Collector
+ A[OTLP] --> M(Receivers)
+ B[JAEGER] --> M(Receivers)
+ C[Prometheus] --> M(Receivers)
+ end
+ subgraph Processors
+ M(Receivers) --> H(Filters, Attributes, etc)
+ E(Extensions)
+ end
+ subgraph Exporters
+ H(Filters, Attributes, etc) --> S(OTLP)
+ H(Filters, Attributes, etc) --> T(JAEGER)
+ H(Filters, Attributes, etc) --> U(Prometheus)
+ end
+{{< /mermaid >}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md
new file mode 100644
index 0000000000..702520c338
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md
@@ -0,0 +1,199 @@
+---
+title: OpenTelemetry Collector Exporters
+linkTitle: 5.1 OTLP HTTP
+weight: 1
+---
+
+## OTLP HTTP Exporter
+
+メトリクスを HTTP 経由で Splunk Observability Cloud に送信するには、**otlphttp** exporter を設定する必要があります。
+
+`/etc/otelcol-contrib/config.yaml` ファイルを編集して、**otlphttp** exporter を設定してみましょう。**exporters** セクションの下に、以下の YAML を 2 スペースのインデントに注意して挿入します。
+
+また、ディスクが満杯になるのを防ぐために、logging exporter のログレベルも変更します。デフォルトの `detailed` は非常に冗長です。
+
+```yaml {hl_lines="3-4"}
+exporters:
+ debug:
+ verbosity: normal
+ otlphttp/splunk:
+```
+
+次に、`metrics_endpoint` を定義してターゲット URL を設定する必要があります。
+
+{{% notice style="note" %}}
+Splunk 主催のワークショップに参加されている方は、使用しているインスタンスにすでに Realm 環境変数が設定されています。設定ファイルでその環境変数を参照します。それ以外の場合は、新しい環境変数を作成して Realm を設定する必要があります。例：
+
+``` bash
+export REALM="us1"
+```
+
+{{% /notice %}}
+
+使用する URL は `https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp` です。（Splunk はデータレジデンシーのために、世界中の主要な地理的拠点に Realm を持っています。）
+
+**otlphttp** exporter は、`traces_endpoint` と `logs_endpoint` のターゲット URL をそれぞれ定義することで、トレースとログを送信するように設定することもできます。これらの設定は本ワークショップの範囲外です。
+
+```yaml {hl_lines="5"}
+exporters:
+ debug:
+ verbosity: normal
+ otlphttp/splunk:
+ metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
+```
+
+デフォルトでは、すべてのエンドポイントで `gzip` 圧縮が有効になっています。これは exporter の設定で `compression: none` を指定することで無効にできます。本ワークショップでは、これがデータ送信の最も効率的な方法であるため、圧縮を有効のままにしてデフォルトを採用します。
+
+メトリクスを Splunk Observability Cloud に送信するには、Access Token を使用する必要があります。これは Splunk Observability Cloud UI で新しいトークンを作成することで行えます。トークンの作成方法の詳細については、[Create a token](https://docs.splunk.com/Observability/admin/authentication-tokens/org-tokens.html) を参照してください。トークンは **INGEST** タイプである必要があります。
+
+{{% notice style="note" %}}
+Splunk 主催のワークショップに参加されている方は、使用しているインスタンスにすでに Access Token が（環境変数として）設定されています。設定ファイルでその環境変数を参照します。それ以外の場合は、新しいトークンを作成して環境変数として設定する必要があります。例：
+
+``` bash
+export ACCESS_TOKEN=
+```
+
+{{% /notice %}}
+
+トークンは、設定ファイル内で `headers:` セクションの下に `X-SF-TOKEN: ${env:ACCESS_TOKEN}` を挿入することで定義します。
+
+```yaml {hl_lines="6-8"}
+exporters:
+ debug:
+ verbosity: normal
+ otlphttp/splunk:
+ metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
+ headers:
+ X-SF-TOKEN: ${env:ACCESS_TOKEN}
+```
+
+## Configuration Check-in
+
+exporter について説明したので、設定変更を確認しましょう。
+
+---
+
+{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}Review your configuration{{% /badge %}}" %}}
+{{< tabs >}}
+{{% tab title="config.yaml" %}}
+
+```yaml {lineNos="table" wrap="true" hl_lines="83-87"}
+# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
+# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks
+
+extensions:
+ health_check:
+ endpoint: 0.0.0.0:13133
+ pprof:
+ endpoint: 0.0.0.0:1777
+ zpages:
+ endpoint: 0.0.0.0:55679
+
+receivers:
+ hostmetrics:
+ collection_interval: 10s
+ scrapers:
+ # CPU utilization metrics
+ cpu:
+ # Disk I/O metrics
+ disk:
+ # File System utilization metrics
+ filesystem:
+ # Memory utilization metrics
+ memory:
+ # Network interface I/O metrics & TCP connection metrics
+ network:
+ # CPU load metrics
+ load:
+ # Paging/Swap space utilization and I/O metrics
+ paging:
+ # Process count metrics
+ processes:
+ # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
+ # process:
+ otlp:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:4317
+ http:
+ endpoint: 0.0.0.0:4318
+
+ opencensus:
+ endpoint: 0.0.0.0:55678
+
+ # Collect own metrics
+ prometheus/internal:
+ config:
+ scrape_configs:
+ - job_name: 'otel-collector'
+ scrape_interval: 10s
+ static_configs:
+ - targets: ['0.0.0.0:8888']
+
+ jaeger:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:14250
+ thrift_binary:
+ endpoint: 0.0.0.0:6832
+ thrift_compact:
+ endpoint: 0.0.0.0:6831
+ thrift_http:
+ endpoint: 0.0.0.0:14268
+
+ zipkin:
+ endpoint: 0.0.0.0:9411
+
+processors:
+ batch:
+ resourcedetection/system:
+ detectors: [system]
+ system:
+ hostname_sources: [os]
+ resourcedetection/ec2:
+ detectors: [ec2]
+ attributes/conf:
+ actions:
+ - key: participant.name
+ action: insert
+ value: "INSERT_YOUR_NAME_HERE"
+
+exporters:
+ debug:
+ verbosity: normal
+ otlphttp/splunk:
+ metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
+ headers:
+ X-SF-Token: ${env:ACCESS_TOKEN}
+
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [otlp, opencensus, prometheus]
+ processors: [batch]
+ exporters: [debug]
+
+ logs:
+ receivers: [otlp]
+ processors: [batch]
+ exporters: [debug]
+
+ extensions: [health_check, pprof, zpages]
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+{{% /expand %}}
+
+---
+
+もちろん、`metrics_endpoint` を **OTLP** プロトコルをサポートする他のソリューションを指すように簡単に設定することもできます。
+
+次に、`config.yaml` の service セクションで、設定したばかりの receiver、processor、exporter を有効化する必要があります。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md
new file mode 100644
index 0000000000..9ed5a81d75
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md
@@ -0,0 +1,39 @@
+---
+title: OpenTelemetry Collector Exporters
+linkTitle: 5. Exporters
+weight: 5
+---
+
+エクスポーターは、push 型または pull 型のいずれかで動作し、データを 1 つ以上のバックエンドや宛先へ送信する仕組みです。エクスポーターは 1 つまたは複数のデータソースに対応します。
+
+このワークショップでは、[**otlphttp**](https://opentelemetry.io/docs/specs/otel/protocol/exporter/) エクスポーターを使用します。OpenTelemetry Protocol (OTLP) は、テレメトリデータを送信するためのベンダー中立で標準化されたプロトコルです。OTLP エクスポーターは、OTLP プロトコルを実装したサーバーへデータを送信します。OTLP エクスポーターは [**gRPC**](https://grpc.io/) と [**HTTP**](https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview)/[**JSON**](https://www.json.org/json-en.html) の両方のプロトコルをサポートしています。
+
+{{< mermaid >}}
+%%{
+ init:{
+ "theme":"base",
+ "themeVariables": {
+ "primaryColor": "#ffffff",
+ "clusterBkg": "#eff2fb",
+ "defaultLinkColor": "#333333"
+ }
+ }
+}%%
+
+flowchart LR;
+ style Exporters fill:#e20082,stroke:#333,stroke-width:4px,color:#fff
+ subgraph Collector
+ A[OTLP] --> M(Receivers)
+ B[JAEGER] --> M(Receivers)
+ C[Prometheus] --> M(Receivers)
+ end
+ subgraph Processors
+ M(Receivers) --> H(Filters, Attributes, etc)
+ E(Extensions)
+ end
+ subgraph Exporters
+ H(Filters, Attributes, etc) --> S(OTLP)
+ H(Filters, Attributes, etc) --> T(JAEGER)
+ H(Filters, Attributes, etc) --> U(Prometheus)
+ end
+{{< /mermaid >}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md
new file mode 100644
index 0000000000..850631ad1f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md
@@ -0,0 +1,27 @@
+---
+title: OpenTelemetry Collector Service
+linkTitle: 6.1 Host Metrics
+weight: 1
+---
+
+## Hostmetrics Receiver
+
+ワークショップの Receivers セクションを思い出してください。[**Host Metrics Receiver**](../3-receivers/#host-metrics-receiver) は、さまざまなソースからスクレイピングされる、ホストシステムに関するメトリクスを生成するために定義しました。このレシーバーを有効化するには、metrics パイプラインに `hostmetrics` レシーバーを含める必要があります。
+
+`metrics` パイプラインの `receivers` セクションに `hostmetrics` を追加します。
+
+```yaml {hl_lines="11"}
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [hostmetrics, otlp, opencensus, prometheus]
+ processors: [batch]
+ exporters: [debug]
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md
new file mode 100644
index 0000000000..6e3989fd9b
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md
@@ -0,0 +1,27 @@
+---
+title: OpenTelemetry Collector Service
+linkTitle: 6.2 Prometheus
+weight: 2
+---
+
+## Prometheus Internal Receiver
+
+ワークショップの前半で、`prometheus` レシーバーが Collector 内部のメトリクスを収集していることを反映させるため、`prometheus/internal` という名前に変更しました。
+
+ここで、メトリクスパイプラインで `prometheus/internal` レシーバーを有効化する必要があります。`receivers` セクションを更新し、`metrics` パイプラインに `prometheus/internal` を追加してください:
+
+```yaml {hl_lines="11"}
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
+ processors: [batch]
+ exporters: [debug]
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md
new file mode 100644
index 0000000000..15c671d5a5
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md
@@ -0,0 +1,27 @@
+---
+title: OpenTelemetry Collector Service
+linkTitle: 6.3 Resource Detection
+weight: 3
+---
+
+## Resource Detection Processor
+
+Collector がインスタンスのホスト名や AWS/EC2 メタデータを取得できるよう、`resourcedetection/system` と `resourcedetection/ec2` プロセッサーも追加しました。これら 2 つのプロセッサーを metrics パイプラインで有効化する必要があります。
+
+`processors` セクションを更新して、`metrics` パイプラインに `resourcedetection/system` と `resourcedetection/ec2` を含めます。
+
+```yaml {hl_lines="12"}
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
+ processors: [batch, resourcedetection/system, resourcedetection/ec2]
+ exporters: [debug]
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md
new file mode 100644
index 0000000000..af2ef0765a
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md
@@ -0,0 +1,27 @@
+---
+title: OpenTelemetry Collector Service
+linkTitle: 6.4 Attributes
+weight: 4
+---
+
+## Attributes Processor
+
+このワークショップの Processors セクションでも、`attributes/conf` プロセッサーを追加して、Collector がすべてのメトリクスに `participant.name` という新しい属性を挿入するようにしました。次に、これを metrics パイプラインで有効化する必要があります。
+
+`processors` セクションを更新して、`metrics` パイプラインに `attributes/conf` を含めます。
+
+```yaml {hl_lines="12"}
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
+ processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf]
+ exporters: [debug]
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md
new file mode 100644
index 0000000000..25fc40bb3c
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md
@@ -0,0 +1,243 @@
+---
+title: OpenTelemetry Collector Service
+linkTitle: 6.5 OTLP HTTP
+weight: 5
+---
+
+## OTLP HTTP Exporter
+
+ワークショップの Exporters セクションでは、Splunk Observability Cloud にメトリクスを送信するための `otlphttp` exporter を構成しました。次は、これを metrics パイプラインで有効化する必要があります。
+
+`exporters` セクションを更新し、`metrics` パイプラインに `otlphttp/splunk` を含めます。
+
+```yaml {hl_lines="13"}
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
+ processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf]
+ exporters: [debug, otlphttp/splunk]
+```
+
+---
+
+{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Collector の内部観測{{% /badge %}}" %}}
+
+Collector は自身の振る舞いに関する内部シグナルを取得しており、これには稼働中のコンポーネントから得られる追加のシグナルも含まれます。
+これは、データの流れに関する判断を行うコンポーネントが、その情報をメトリクスやトレースとして表面化する手段を必要とするためです。
+
+## なぜ Collector を監視するのか？
+
+これは「監視者を監視するのは誰か？」という、いわば鶏と卵の問題ですが、こうした情報を表面化できることは重要です。Collector の歴史的に興味深いもう 1 つの点として、Collector は Go の metrics SDK が安定版とみなされる前から存在していたため、現時点ではこの機能を提供する目的で Prometheus エンドポイントを公開している、という事情があります。
+
+## 考慮事項
+
+組織内で稼働中の各 Collector の内部使用状況を監視すると、新しい Metric Time Series (MTS) が大量に発生する可能性があります。Splunk ディストリビューションではこれらのメトリクスを精選しており、想定される増加分の予測を支援できます。
+
+## The Ninja Zone
+
+Collector の内部可観測性を公開するには、いくつかの追加設定を調整できます。
+
+{{< tabs >}}
+{{% tab title="telemetry schema" %}}
+
+```yaml
+service:
+ telemetry:
+ logs:
+ level:
+ development:
+ encoding:
+ disable_caller:
+ disable_stacktrace:
+ output_paths: [, paths...]
+ error_output_paths: [, paths...]
+ initial_fields:
+ key: value
+ metrics:
+ level:
+ # Address binds the promethues endpoint to scrape
+ address:
+```
+
+{{% /tab %}}
+{{% tab title="example-config.yml" %}}
+
+```yaml
+service:
+ telemetry:
+ logs:
+ level: info
+ encoding: json
+ disable_stacktrace: true
+ initial_fields:
+ instance.name: ${env:INSTANCE}
+ metrics:
+ address: localhost:8888
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## 参考情報
+
+1. [https://opentelemetry.io/docs/collector/configuration/#service](https://opentelemetry.io/docs/collector/configuration/#service)
+
+{{% /expand %}}
+
+---
+
+## 最終的な構成
+
+---
+
+{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}最終的な構成を確認する{{% /badge %}}" %}}
+{{< tabs >}}
+{{% tab title="config.yaml" %}}
+
+``` yaml {lineNos="table" wrap="true"}
+# To limit exposure to denial of service attacks, change the host in endpoints below from 0.0.0.0 to a specific network interface.
+# See https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks
+
+extensions:
+ health_check:
+ endpoint: 0.0.0.0:13133
+ pprof:
+ endpoint: 0.0.0.0:1777
+ zpages:
+ endpoint: 0.0.0.0:55679
+
+receivers:
+ hostmetrics:
+ collection_interval: 10s
+ scrapers:
+ # CPU utilization metrics
+ cpu:
+ # Disk I/O metrics
+ disk:
+ # File System utilization metrics
+ filesystem:
+ # Memory utilization metrics
+ memory:
+ # Network interface I/O metrics & TCP connection metrics
+ network:
+ # CPU load metrics
+ load:
+ # Paging/Swap space utilization and I/O metrics
+ paging:
+ # Process count metrics
+ processes:
+ # Per process CPU, Memory and Disk I/O metrics. Disabled by default.
+ # process:
+ otlp:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:4317
+ http:
+ endpoint: 0.0.0.0:4318
+
+ opencensus:
+ endpoint: 0.0.0.0:55678
+
+ # Collect own metrics
+ prometheus/internal:
+ config:
+ scrape_configs:
+ - job_name: 'otel-collector'
+ scrape_interval: 10s
+ static_configs:
+ - targets: ['0.0.0.0:8888']
+
+ jaeger:
+ protocols:
+ grpc:
+ endpoint: 0.0.0.0:14250
+ thrift_binary:
+ endpoint: 0.0.0.0:6832
+ thrift_compact:
+ endpoint: 0.0.0.0:6831
+ thrift_http:
+ endpoint: 0.0.0.0:14268
+
+ zipkin:
+ endpoint: 0.0.0.0:9411
+
+processors:
+ batch:
+ resourcedetection/system:
+ detectors: [system]
+ system:
+ hostname_sources: [os]
+ resourcedetection/ec2:
+ detectors: [ec2]
+ attributes/conf:
+ actions:
+ - key: participant.name
+ action: insert
+ value: "INSERT_YOUR_NAME_HERE"
+
+exporters:
+ debug:
+ verbosity: normal
+ otlphttp/splunk:
+ metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp
+ headers:
+ X-SF-Token: ${env:ACCESS_TOKEN}
+
+service:
+
+ pipelines:
+
+ traces:
+ receivers: [otlp, opencensus, jaeger, zipkin]
+ processors: [batch]
+ exporters: [debug]
+
+ metrics:
+ receivers: [hostmetrics, otlp, opencensus, prometheus/internal]
+ processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf]
+ exporters: [debug, otlphttp/splunk]
+
+ logs:
+ receivers: [otlp]
+ processors: [batch]
+ exporters: [debug]
+
+ extensions: [health_check, pprof, zpages]
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% /expand %}}
+
+---
+
+{{% notice style="tip" %}}
+Collector を再起動する前に、構成ファイルを検証することを推奨します。`config.yaml` ファイルの内容を **[otelbin.io](https://www.otelbin.io/)** に貼り付けることで検証できます。
+
+{{% expand title="{{% badge color=green title=**Screenshot** %}}OTelBin{{% /badge %}}" %}}
+
+{{% /expand %}}
+
+{{% /notice %}}
+
+動作する構成ができたので、Collector を起動し、[zPages](../2-extensions/#zpages) が何を報告しているか確認しましょう。
+
+{{% tab title="Command" %}}
+
+``` bash
+otelcol-contrib --config=file:/etc/otelcol-contrib/config.yaml
+```
+
+{{% /tab %}}
+
+ブラウザで zPages を開きます: [**http://localhost:55679/debug/pipelinez**](http://localhost:55679/debug/pipelinez) （`localhost` は自身の環境に合わせて変更してください）。
+
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md
new file mode 100644
index 0000000000..e20b0b8c10
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md
@@ -0,0 +1,26 @@
+---
+title: OpenTelemetry Collector Service
+linkTitle: 6. Service
+weight: 6
+---
+
+**Service** セクションは、receivers、processors、exporters、extensions の各セクションに定義された設定をもとに、Collector で有効化するコンポーネントを指定するために使用します。
+
+{{% notice style="info" %}}
+コンポーネントが設定されていても、**Service** セクション内で定義されていなければ、そのコンポーネントは有効化**されません**。
+{{% /notice %}}
+
+service セクションは、次の3つのサブセクションで構成されています。
+
+- extensions
+- pipelines
+- telemetry
+
+デフォルトの設定では、extension セクションに `health_check`、`pprof`、`zpages` を有効化する設定が記述されており、これらは先ほど Extensions モジュールで設定した内容です。
+
+``` yaml
+service:
+ extensions: [health_check, pprof, zpages]
+```
+
+それでは、Metric Pipeline を設定していきましょう！
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md
new file mode 100644
index 0000000000..0ee8f7345d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md
@@ -0,0 +1,38 @@
+---
+title: Data Visualisations
+linkTitle: 7. Visualisation
+weight: 7
+---
+
+## Splunk Observability Cloud
+
+OpenTelemetry Collector が Splunk Observability Cloud にメトリクスを送信するように設定できたので、Splunk Observability Cloud でデータを確認してみましょう。Splunk Observability Cloud への招待を受け取っていない場合は、講師がログイン認証情報を提供します。
+
+その前に、もう少し面白くするために、インスタンスに対してストレステストを実行します。これによりダッシュボードが活性化されます。
+
+``` bash
+sudo apt install stress
+while true; do stress -c 2 -t 40; stress -d 5 -t 40; stress -m 20 -t 40; done
+```
+
+Splunk Observability Cloud にログインしたら、左側のナビゲーションを使用して、メインメニューから **Dashboards** に移動します。これにより Teams ビューが表示されます。このビューの上部で **All Dashboards** をクリックします。
+
+
+
+検索ボックスで **OTel Contrib** を検索します。
+
+
+
+{{% notice style="info" %}}
+ダッシュボードが存在しない場合、講師が素早く追加できます。Splunk がホストするバージョンのワークショップに参加していない場合、インポートする Dashboard Group はこのページの下部にあります。
+{{% /notice %}}
+
+**OTel Contrib Dashboard** ダッシュボードをクリックして開き、次にダッシュボード上部の **Participant Name** ボックスをクリックし、`config.yaml` で `participant.name` に設定した名前をドロップダウンリストから選択するか、検索のために名前を入力し始めます。
+
+
+
+これで、OpenTelemetry Collector を設定したホストのホストメトリクスを確認できるようになります。
+
+
+
+{{% resources sort="asc" style="info" title="Download Dashboard Group JSON for importing" /%}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md
new file mode 100644
index 0000000000..fda54d5236
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md
@@ -0,0 +1,34 @@
+---
+title: OpenTelemetry Collector Development
+linkTitle: 8.1 Project Setup
+weight: 9
+---
+
+## Project Setup {{% badge style=primary icon=user-ninja %}}**Ninja**{{% /badge %}}
+
+{{% notice style="note" %}}
+
+このセクションを完了するまでにかかる時間は、経験により異なります。
+
+詰まったときやインストラクターと一緒に進めたい場合は、完成版のソリューションを[**こちら**](https://github.com/splunk/collector-workshop-example)で確認できます。
+
+{{% /notice %}}
+
+新しい _Jenkins CI_ receiver の開発を始めるために、まずは Golang プロジェクトをセットアップする必要があります。
+新しい Golang プロジェクトを作成する手順は以下のとおりです。
+
+1. `${HOME}/go/src/jenkinscireceiver` という名前の新しいディレクトリを作成し、そこに移動します
+ 1. 実際のディレクトリ名や場所に厳密な決まりはなく、ご自身の開発ディレクトリを自由に選んで作成して構いません。
+1. `go mod init splunk.conf/workshop/example/jenkinscireceiver` を実行して golang モジュールを初期化します
+ 1. これにより `go.mod` というファイルが作成され、直接および間接の依存関係を追跡するために使用されます
+ 1. 最終的には `go.sum` も作成され、これはインポートされる依存関係のチェックサム値を保持します。
+
+{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}Review your go.mod{{% /badge %}}" %}}
+
+``` text
+module splunk.conf/workshop/example/jenkinscireceiver
+
+go 1.20
+```
+
+{{% /expand %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md
new file mode 100644
index 0000000000..a494959de3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md
@@ -0,0 +1,93 @@
+---
+title: OpenTelemetry Collector Development
+linkTitle: 8.2 Configuration
+weight: 10
+---
+
+## 設定の構築
+
+コンポーネントの設定部分は、ユーザーがコンポーネントに対して入力を与えるための手段です。
+そのため、設定で使用される値は次のような特性を備えている必要があります。
+
+1. そのフィールドが何を制御するのかをユーザーが直感的に理解できること
+1. 必須項目と任意項目が明示されていること
+1. 共通の名称やフィールドを再利用していること
+1. オプションをシンプルに保つこと
+
+{{% tabs %}}
+{{% tab title="bad config" %}}
+
+```yaml
+---
+jenkins_server_addr: hostname
+jenkins_server_api_port: 8089
+interval: 10m
+filter_builds_by:
+ - name: my-awesome-build
+ status: amber
+track:
+ values:
+ example.metric.1: yes
+ example.metric.2: yes
+ example.metric.3: no
+ example.metric.4: no
+```
+
+{{% /tab %}}
+{{% tab title="good config" %}}
+
+``` yaml
+---
+# Required Values
+endpoint: http://my-jenkins-server:8089
+auth:
+ authenticator: basicauth/jenkins
+# Optional Values
+collection_interval: 10m
+metrics:
+ example.metric.1:
+ enabled: true
+ example.metric.2:
+ enabled: true
+ example.metric.3:
+ enabled: true
+ example.metric.4:
+ enabled: true
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+bad configuration の例は、設定に関する推奨事項とは逆のことを行うとコンポーネントの使い勝手にどのような影響を与えるかを示しています。フィールドの値がどうあるべきかが明確でなく、既存のプロセッサに任せられる機能まで含めてしまっており、フィールドの命名も collector 内の他のコンポーネントと一貫していません。
+
+good configuration の例は、必須の値をシンプルに保ち、他のコンポーネントから命名規則を再利用し、コンポーネントが Jenkins と collector の連携のみに集中するようにしています。
+
+コードタブは、自分たちで追加する必要のある部分と、collector 内の共有ライブラリによってすでに提供されている部分の量を示しています。これらについては、ビジネスロジックに進んだ際にさらに詳しく説明します。設定は最初は小さく始めるべきであり、ビジネスロジックで必要となる追加機能を含めていく過程で変化していきます。
+
+## コードを書く
+
+設定に必要なコードを実装するために、`config.go` という名前の新しいファイルを以下の内容で作成します。
+
+``` go
+package jenkinscireceiver
+
+import (
+ "go.opentelemetry.io/collector/config/confighttp"
+ "go.opentelemetry.io/collector/receiver/scraperhelper"
+
+ "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
+)
+
+type Config struct {
+ // HTTPClientSettings contains all the values
+ // that are commonly shared across all HTTP interactions
+ // performed by the collector.
+ confighttp.HTTPClientSettings `mapstructure:",squash"`
+ // ScraperControllerSettings will allow us to schedule
+ // how often to check for updates to builds.
+ scraperhelper.ScraperControllerSettings `mapstructure:",squash"`
+ // MetricsBuilderConfig contains all the metrics
+ // that can be configured.
+ metadata.MetricsBuilderConfig `mapstructure:",squash"`
+}
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md
new file mode 100644
index 0000000000..f6d9ad2179
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md
@@ -0,0 +1,64 @@
+---
+title: OpenTelemetry Collector Development
+linkTitle: 8.3 コンポーネントの復習
+weight: 11
+---
+
+## コンポーネントの復習
+
+Jenkins からメトリクスを取得するために必要なコンポーネントの種類について、これまでの内容を振り返ります。
+
+{{% tabs %}}
+{{% tab title="Extension" %}}
+extension が解決するビジネスユースケースは以下のとおりです。
+
+1. ランタイム設定が必要な共有機能を提供する
+1. Collector のランタイムを観測する間接的な手助けをする
+
+詳細は [**Extensions Overview**](../2-extensions) を参照してください。
+{{% /tab %}}
+{{% tab title="Receiver" %}}
+receiver が解決するビジネスユースケースは以下のとおりです。
+
+- リモートソースからデータを取得する
+- リモートソースからデータを受信する
+
+これは一般的に _pull_ 型と _push_ 型のデータ収集と呼ばれ、詳細は [Receiver Overview](../3-receivers) で確認できます。
+{{% /tab %}}
+{{% tab title="Processor" %}}
+processor が解決するビジネスユースケースは以下のとおりです。
+
+- データ、フィールド、または値の追加や削除
+- データを観測し、判断を行う
+- バッファリング、キューイング、並び替え
+
+ここで覚えておくべき点は、processor を流れるデータタイプは、下流のコンポーネントに同じデータタイプを転送する必要があるということです。詳細は [Processor Overview](../4-processors) を読んでください。
+
+{{% /tab %}}
+{{% tab title="Exporter" %}}
+exporter が解決するビジネスユースケースは以下のとおりです。
+
+- ツール、サービス、またはストレージにデータを送信する
+
+OpenTelemetry Collector は「バックエンド」やオールインワンの可観測性スイートになることを目指していません。むしろ、OpenTelemetry が当初から掲げてきた原則、つまり「すべての人にベンダーニュートラルな可観測性を」という理念を守ることを重視しています。
+詳細を改めて確認するには、[**Exporter Overview**](../5-exporters) を読んでください。
+
+{{% /tab %}}
+{{% tab title="{{% badge style=primary icon=user-ninja %}}**Ninja:** Connectors{{% /badge %}}" %}}
+
+これは、Collector に比較的最近追加されたコンポーネントタイプであるため、本ワークショップでは触れていなかったものです。connector を理解する最良の方法は、異なるテレメトリータイプやパイプラインをまたいで使用できる processor のようなものだと考えることです。つまり、connector はログとしてデータを受け取ってメトリクスとして出力したり、あるパイプラインからメトリクスを受け取って観測したデータに基づくメトリクスを提供したりできます。
+
+connector が解決するビジネスケースは以下のとおりです。
+
+- 異なるテレメトリータイプ間の変換
+ - logs から metrics へ
+ - traces から metrics へ
+ - metrics から logs へ
+- 受信データを観測し、独自のデータを生成
+ - メトリクスを受け取って、そのデータの分析メトリクスを生成する
+
+[Processor Overview](../4-processors) の **Ninja** セクションで簡単な概要を紹介していますので、新しい connector コンポーネントの追加状況についてもプロジェクトを必ず確認してください。
+{{% /tab %}}
+{{% /tabs %}}
+
+これらのコンポーネント概要から、Jenkins 用には pull 型の receiver を開発することが明らかです。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md
new file mode 100644
index 0000000000..4ca8113ab6
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md
@@ -0,0 +1,247 @@
+---
+title: OpenTelemetry Collector Development
+linkTitle: 8.4 Designing the Metrics
+weight: 12
+---
+
+### メトリクスの設計
+
+レシーバーで収集するメトリクスを定義してエクスポートしやすくするため、[**mdatagen**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/cmd/mdatagen) を使用します。これは、YAML で定義したメトリクスをコードに変換するために Collector 向けに開発されたツールです。
+
+{{% tabs %}}
+{{% tab title="metadata.yaml"%}}
+
+``` yaml
+---
+# Type defines the name to reference the component
+# in the configuration file
+type: jenkins
+
+# Status defines the component type and the stability level
+status:
+ class: receiver
+ stability:
+ development: [metrics]
+
+# Attributes are the expected fields reported
+# with the exported values.
+attributes:
+ job.name:
+ description: The name of the associated Jenkins job
+ type: string
+ job.status:
+ description: Shows if the job had passed, or failed
+ type: string
+ enum:
+ - failed
+ - success
+ - unknown
+
+# Metrics defines all the pontentially exported values from this receiver.
+metrics:
+ jenkins.jobs.count:
+ enabled: true
+ description: Provides a count of the total number of configured jobs
+ unit: "{Count}"
+ gauge:
+ value_type: int
+ jenkins.job.duration:
+ enabled: true
+ description: Show the duration of the job
+ unit: "s"
+ gauge:
+ value_type: int
+ attributes:
+ - job.name
+ - job.status
+ jenkins.job.commit_delta:
+ enabled: true
+ description: The calculation difference of the time job was finished minus commit timestamp
+ unit: "s"
+ gauge:
+ value_type: int
+ attributes:
+ - job.name
+ - job.status
+```
+
+{{% /tab %}}
+{{% tab title="gen.go" %}}
+
+``` go
+// To generate the additional code needed to capture metrics,
+// the following command to be run from the shell:
+// go generate -x ./...
+
+//go:generate go run github.com/open-telemetry/opentelemetry-collector-contrib/cmd/mdatagen@v0.80.0 metadata.yaml
+package jenkinscireceiver
+
+// There is no code defined within this file.
+```
+
+{{% /tab%}}
+{{% /tabs %}}
+
+次のセクションに進む前に、これらのファイルをプロジェクトフォルダ内に作成してください。
+
+## Factory の構築
+
+Factory は、提供された設定に基づいてオブジェクト（このケースでは `jenkinscireceiver`）を動的に生成できるようにするソフトウェアデザインパターンです。より身近な例で説明すると、携帯電話ショップに行き、自分の希望に合った電話を伝え、それを店員から渡してもらうようなものです。
+
+`go generate -x ./...` コマンドを実行すると、新しいフォルダ `jenkinscireceiver/internal/metadata` が作成され、定義されたメトリクスをエクスポートするために必要なすべてのコードが生成されます。必要なコードは次のとおりです。
+
+{{% tabs %}}
+{{% tab title="factory.go" %}}
+
+``` go
+package jenkinscireceiver
+
+import (
+ "errors"
+
+ "go.opentelemetry.io/collector/component"
+ "go.opentelemetry.io/collector/config/confighttp"
+ "go.opentelemetry.io/collector/receiver"
+ "go.opentelemetry.io/collector/receiver/scraperhelper"
+
+ "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
+)
+
+func NewFactory() receiver.Factory {
+ return receiver.NewFactory(
+ metadata.Type,
+ newDefaultConfig,
+ receiver.WithMetrics(newMetricsReceiver, metadata.MetricsStability),
+ )
+}
+
+func newMetricsReceiver(_ context.Context, set receiver.CreateSettings, cfg component.Config, consumer consumer.Metrics) (receiver.Metrics, error) {
+ // Convert the configuration into the expected type
+ conf, ok := cfg.(*Config)
+ if !ok {
+ return nil, errors.New("can not convert config")
+ }
+ sc, err := newScraper(conf, set)
+ if err != nil {
+ return nil, err
+ }
+ return scraperhelper.NewScraperControllerReceiver(
+ &conf.ScraperControllerSettings,
+ set,
+ consumer,
+ scraperhelper.AddScraper(sc),
+ )
+}
+```
+
+{{% /tab %}}
+{{% tab title="config.go" %}}
+
+``` go
+package jenkinscireceiver
+
+import (
+ "go.opentelemetry.io/collector/config/confighttp"
+ "go.opentelemetry.io/collector/receiver/scraperhelper"
+
+ "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
+)
+
+type Config struct {
+ // HTTPClientSettings contains all the values
+ // that are commonly shared across all HTTP interactions
+ // performed by the collector.
+ confighttp.HTTPClientSettings `mapstructure:",squash"`
+ // ScraperControllerSettings will allow us to schedule
+ // how often to check for updates to builds.
+ scraperhelper.ScraperControllerSettings `mapstructure:",squash"`
+ // MetricsBuilderConfig contains all the metrics
+ // that can be configured.
+ metadata.MetricsBuilderConfig `mapstructure:",squash"`
+}
+
+func newDefaultConfig() component.Config {
+ return &Config{
+ ScraperControllerSettings: scraperhelper.NewDefaultScraperControllerSettings(metadata.Type),
+ HTTPClientSettings: confighttp.NewDefaultHTTPClientSettings(),
+ MetricsBuilderConfig: metadata.DefaultMetricsBuilderConfig(),
+ }
+}
+```
+
+{{% /tab %}}
+{{% tab title="scraper.go" %}}
+
+``` go
+package jenkinscireceiver
+
+type scraper struct {}
+
+func newScraper(cfg *Config, set receiver.CreateSettings) (scraperhelper.Scraper, error) {
+ // Create a our scraper with our values
+ s := scraper{
+ // To be filled in later
+ }
+ return scraperhelper.NewScraper(metadata.Type, s.scrape)
+}
+
+func (scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
+ // To be filled in
+ return pmetrics.NewMetrics(), nil
+}
+```
+
+{{% /tab %}}
+{{% tab title="build-config.yaml" %}}
+
+``` yaml
+---
+dist:
+ name: otelcol
+ description: "Conf workshop collector"
+ output_path: ./dist
+ version: v0.0.0-experimental
+
+extensions:
+ - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/basicauthextension v0.80.0
+ - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/extension/healthcheckextension v0.80.0
+
+receivers:
+ - gomod: go.opentelemetry.io/collector/receiver/otlpreceiver v0.80.0
+ - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/jaegerreceiver v0.80.0
+ - gomod: github.com/open-telemetry/opentelemetry-collector-contrib/receiver/prometheusreceiver v0.80.0
+ - gomod: splunk.conf/workshop/example/jenkinscireceiver v0.0.0
+ path: ./jenkinscireceiver
+
+processors:
+ - gomod: go.opentelemetry.io/collector/processor/batchprocessor v0.80.0
+
+exporters:
+ - gomod: go.opentelemetry.io/collector/exporter/loggingexporter v0.80.0
+ - gomod: go.opentelemetry.io/collector/exporter/otlpexporter v0.80.0
+ - gomod: go.opentelemetry.io/collector/exporter/otlphttpexporter v0.80.0
+
+# This replace is a go directive that allows for redefine
+# where to fetch the code to use since the default would be from a remote project.
+replaces:
+- splunk.conf/workshop/example/jenkinscireceiver => ./jenkinscireceiver
+```
+
+{{% /tab %}}
+{{% tab title="project layout" %}}
+
+``` text
+├── build-config.yaml
+└── jenkinscireceiver
+ ├── go.mod
+ ├── config.go
+ ├── factory.go
+ ├── scraper.go
+ └── internal
+ └── metadata
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+これらのファイルを期待される内容でプロジェクトに書き込んだら、`go mod tidy` を実行してください。これによりすべてのリモート依存関係が取得され、`go.mod` が更新されて `go.sum` ファイルが生成されます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md
new file mode 100644
index 0000000000..ffe78ed15f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md
@@ -0,0 +1,224 @@
+---
+title: OpenTelemetry Collector Development
+linkTitle: 8.5 Building Business Logic
+weight: 13
+---
+
+## ビジネスロジックの構築
+
+現時点では、まだ何も処理を行わないカスタムコンポーネントがあるだけなので、Jenkins からデータを取得するために必要なロジックを追加する必要があります。
+
+ここから先に行う手順は次のとおりです。
+
+1. Jenkins に接続するクライアントを作成する
+1. 設定されているすべてのジョブを取得する
+1. 設定されたジョブの直近のビルドのステータスをレポートする
+1. コミットのタイムスタンプとジョブ完了時刻の差を計算する
+
+変更は `scraper.go` に対して行います。
+
+{{% tabs %}}
+{{% tab title="1. Add Jenkins client" %}}
+
+Jenkins サーバーに接続するために、Jenkins サーバーからデータを読み取るのに必要な機能を提供するパッケージ ["github.com/yosida95/golang-jenkins"](https://pkg.go.dev/github.com/yosida95/golang-jenkins) を使用します。
+
+さらに、["go.opentelemetry.io/collector/receiver/scraperhelper"](https://pkg.go.dev/go.opentelemetry.io/collector/receiver/scraperhelper) ライブラリのヘルパー関数を活用して、コンポーネントの起動が完了した時点で Jenkins サーバーに接続できるよう、start 関数を作成します。
+
+```go
+package jenkinscireceiver
+
+import (
+ "context"
+
+ jenkins "github.com/yosida95/golang-jenkins"
+ "go.opentelemetry.io/collector/component"
+ "go.opentelemetry.io/collector/pdata/pmetric"
+ "go.opentelemetry.io/collector/receiver"
+ "go.opentelemetry.io/collector/receiver/scraperhelper"
+
+ "splunk.conf/workshop/example/jenkinscireceiver/internal/metadata"
+)
+
+type scraper struct {
+ mb *metadata.MetricsBuilder
+ client *jenkins.Jenkins
+}
+
+func newScraper(cfg *Config, set receiver.CreateSettings) (scraperhelper.Scraper, error) {
+ s := &scraper{
+ mb : metadata.NewMetricsBuilder(cfg.MetricsBuilderConfig, set),
+ }
+
+ return scraperhelper.NewScraper(
+ metadata.Type,
+ s.scrape,
+ scraperhelper.WithStart(func(ctx context.Context, h component.Host) error {
+ client, err := cfg.ToClient(h, set.TelemetrySettings)
+ if err != nil {
+ return err
+ }
+ // The collector provides a means of injecting authentication
+ // on our behalf, so this will ignore the libraries approach
+ // and use the configured http client with authentication.
+ s.client = jenkins.NewJenkins(nil, cfg.Endpoint)
+ s.client.SetHTTPClient(client)
+ return nil
+ }),
+ )
+}
+
+func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
+ // To be filled in
+ return pmetric.NewMetrics(), nil
+}
+
+```
+
+これで Jenkins receiver の初期化に必要なセットアップコードはすべて完了です。
+{{% /tab%}}
+{{% tab title="2. Capture all configured jobs" %}}
+
+ここからは、これまで未実装のままになっていた `scrape` メソッドに焦点を当てていきます。このメソッドは、設定で指定された間隔（デフォルトでは1分ごと）で実行されます。
+
+設定済みのジョブ数を取得したい理由は、Jenkins サーバーの成長を可視化し、どれだけのプロジェクトがオンボーディングされたかを測定するためです。これを実現するために、jenkins クライアントを呼び出してすべてのジョブを一覧表示します。エラーが返された場合はメトリクスを返さずにそのエラーを返し、それ以外の場合は metric builder からデータを発行します。
+
+```go
+func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
+ jobs, err := s.client.GetJobs()
+ if err != nil {
+ return pmetric.Metrics{}, err
+ }
+
+ // Recording the timestamp to ensure
+ // all captured data points within this scrape have the same value.
+ now := pcommon.NewTimestampFromTime(time.Now())
+
+ // Casting to an int64 to match the expected type
+ s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))
+
+ // To be filled in
+
+ return s.mb.Emit(), nil
+}
+```
+
+{{% /tab%}}
+{{% tab title="3. Report the status of each job" %}}
+
+前のステップでは、すべてのジョブを取得して、その個数をレポートできるようにしました。このステップでは、各ジョブを調査し、レポートされた値からメトリクスを取得します。
+
+```go
+func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
+ jobs, err := s.client.GetJobs()
+ if err != nil {
+ return pmetric.Metrics{}, err
+ }
+
+ // Recording the timestamp to ensure
+ // all captured data points within this scrape have the same value.
+ now := pcommon.NewTimestampFromTime(time.Now())
+
+ // Casting to an int64 to match the expected type
+ s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))
+
+ for _, job := range jobs {
+ // Ensure we have valid results to start off with
+ var (
+ build = job.LastCompletedBuild
+ status = metadata.AttributeJobStatusUnknown
+ )
+
+ // This will check the result of the job, however,
+ // since the only defined attributes are
+ // `success`, `failure`, and `unknown`.
+ // it is assume that anything did not finish
+ // with a success or failure to be an unknown status.
+
+ switch build.Result {
+ case "aborted", "not_built", "unstable":
+ status = metadata.AttributeJobStatusUnknown
+ case "success":
+ status = metadata.AttributeJobStatusSuccess
+ case "failure":
+ status = metadata.AttributeJobStatusFailed
+ }
+
+ s.mb.RecordJenkinsJobDurationDataPoint(
+ now,
+ int64(job.LastCompletedBuild.Duration),
+ job.Name,
+ status,
+ )
+ }
+
+ return s.mb.Emit(), nil
+}
+```
+
+{{% /tab%}}
+{{% tab title="4. Report the delta" %}}
+
+最後のステップでは、コミットからジョブ完了までにかかった時間を計算し、DORA メトリクスを推定するのに役立てます。
+
+```go
+func (s scraper) scrape(ctx context.Context) (pmetric.Metrics, error) {
+ jobs, err := s.client.GetJobs()
+ if err != nil {
+ return pmetric.Metrics{}, err
+ }
+
+ // Recording the timestamp to ensure
+ // all captured data points within this scrape have the same value.
+ now := pcommon.NewTimestampFromTime(time.Now())
+
+ // Casting to an int64 to match the expected type
+ s.mb.RecordJenkinsJobsCountDataPoint(now, int64(len(jobs)))
+
+ for _, job := range jobs {
+ // Ensure we have valid results to start off with
+ var (
+ build = job.LastCompletedBuild
+ status = metadata.AttributeJobStatusUnknown
+ )
+
+ // Previous step here
+
+ // Ensure that the `ChangeSet` has values
+ // set so there is a valid value for us to reference
+ if len(build.ChangeSet.Items) == 0 {
+ continue
+ }
+
+ // Making the assumption that the first changeset
+ // item is the most recent change.
+ change := build.ChangeSet.Items[0]
+
+ // Record the difference from the build time
+ // compared against the change timestamp.
+ s.mb.RecordJenkinsJobCommitDeltaDataPoint(
+ now,
+ int64(build.Timestamp-change.Timestamp),
+ job.Name,
+ status,
+ )
+ }
+
+ return s.mb.Emit(), nil
+}
+```
+
+{{% /tab%}}
+{{% /tabs %}}
+
+これらの手順をすべて完了すると、カスタムの Jenkins CI receiver の構築が完了です！
+
+## 次は何でしょうか？
+
+このコンポーネントに対して、他にも欲しい機能が思い浮かぶかもしれません。たとえば次のようなものです。
+
+- ジョブで使用されたブランチ名を含めることはできますか？
+- ジョブのプロジェクト名を含めることはできますか？
+- プロジェクト全体のジョブ実行時間を合計するにはどうすればよいでしょうか？
+- 変更が動作することをどのように検証すればよいでしょうか？
+
+ぜひこの時間を使って、いろいろ試したり、あえて壊してみたり、設定を変更してみたり、さらにはビルドからログを取得することにも挑戦してみてください。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md
new file mode 100644
index 0000000000..6e38a6e4f6
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md
@@ -0,0 +1,37 @@
+---
+title: OpenTelemetry Collector の開発
+linkTitle: 8. Develop
+weight: 8
+---
+
+## カスタムコンポーネントの開発
+
+Open Telemetry Collector のコンポーネントを構築するには、3 つの重要な要素が必要です。
+
+1. Configuration - _ユーザーが設定するために公開される値_
+1. Factory - _提供された値を用いてコンポーネントを生成する_
+1. Business Logic - _コンポーネントが実行すべき処理_
+
+ここでは、プロジェクトの重要な DevOps メトリクスを追跡できるように、Jenkins と連携するコンポーネントを構築する例を使用します。
+
+測定対象としたいメトリクスは次のとおりです。
+
+1. Lead time for changes - _「コミットが本番環境に到達するまでにかかる時間」_
+1. Change failure rate - _「本番環境で障害を引き起こすデプロイの割合」_
+1. Deployment frequency - _「[チーム] が本番環境にリリースする頻度」_
+1. Mean time to recover - _「[チーム] が本番環境の障害から復旧するまでにかかる時間」_
+
+これらの指標は、ソフトウェア開発チームのパフォーマンスを示すために、Google の DevOps Research and Assesment (DORA)[^1] チームによって特定されました。_Jenkins CI_ を選んだ理由は、同じオープンソースソフトウェアのエコシステムにとどまることで、将来的にベンダーが管理する CI ツールが採用する際の例として役立てられるためです。
+
+## Instrument と Component の比較
+
+組織における Observability のレベルを向上させる際には、いくつかのトレードオフが生じるため、考慮すべき点があります。
+
+| | 長所 | 短所 |
+| ----- | ----- | ----- |
+| **(Auto) Instrumented** | システムを観測するために外部 API を監視する必要がない。 | 計装を変更するにはプロジェクトへの変更が必要となる。 |
+| | システムのオーナーや開発者が Observability を変更できる。 | 追加のランタイム依存関係が必要となる。 |
+| | システムのコンテキストを理解し、取得したデータを _Exemplars_ と関連付けることができる。 | システムのパフォーマンスに影響を与える可能性がある。 |
+| **Component** | - データ名やセマンティクスの変更を、システムのリリースサイクルとは独立して展開できる。 | 破壊的な API 変更には、システムと collector の間で連携したリリースが必要となる。 |
+| | 収集データの更新や拡張は、ユーザーから見てシームレスな変更となる。 | 取得したデータのセマンティクスが、新しいシステムリリースと整合せずに予期せず壊れることがある。 |
+| | 支援チームが Observability の実践について深く理解している必要がない。 | システムから表に出せるのは、厳密に外部公開されている情報に限られる。 |
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md
new file mode 100644
index 0000000000..57d8fd2348
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md
@@ -0,0 +1,79 @@
+---
+title: OpenTelemetry でオブザーバビリティをクラウドネイティブに
+linkTitle: OpenTelemetry Collector の概念
+weight: 1
+description: OpenTelemetry Collector の概念と、Splunk Observability Cloud にデータを送信するための使い方を学びます。
+authors: ["Robert Castley"]
+time: 1 hour
+---
+
+## 概要
+
+OpenTelemetry を使い始める組織は、まずオブザーバビリティバックエンドにデータを直接送信することから着手するかもしれません。これは初期テストには適していますが、オブザーバビリティアーキテクチャの一部として OpenTelemetry collector を利用すると多くのメリットがあり、本番環境のデプロイメントには推奨されるアプローチです。
+
+このワークショップでは、OpenTelemetry collector の利用に焦点を当て、Splunk Observability Cloud で利用するための receivers、processors、exporters の設定の基礎から始めます。このワークショップを通じて、参加者は初心者から、分散プラットフォームのビジネス上のオブザーバビリティニーズを解決するためにカスタムコンポーネントを追加できるレベルへと成長することができます。
+
+### Ninja セクション
+
+ワークショップ全体を通じて、展開可能な {{% badge style=primary icon=user-ninja %}}**Ninja** セクション{{% /badge %}}が用意されています。これらはより実践的で、さらに踏み込んだ技術的な詳細について解説しており、ワークショップ中またはご自身のお時間に合わせて探求していただけます。
+
+OpenTelemetry プロジェクトは頻繁に開発が進められているため、これらのセクションの内容は古くなっている可能性がある点にご注意ください。詳細が同期していない場合に備えてリンクを提供しますので、更新が必要な箇所を見つけた場合はお知らせください。
+
+---
+
+{{% expand title="{{% badge style=primary icon=user-ninja %}}**Ninja:** 自分を試そう！{{% /badge %}}" %}}
+**このワークショップを完了すれば、あなたは正式に OpenTelemetry Collector の Ninja です！**
+{{% /expand %}}
+
+---
+
+## 対象者
+
+このインタラクティブなワークショップは、OpenTelemetry Collector のアーキテクチャとデプロイメントについてさらに学びたい開発者およびシステム管理者を対象としています。
+
+## 前提条件
+
+- 参加者はデータ収集について基本的な理解があること
+- コマンドラインおよび vim/vi の経験があること
+- Ubuntu 20.04 LTS または 22.04 LTS が動作するインスタンス/ホスト/VM
+ - 最小要件は AWS/EC2 t2.micro（1 CPU、1GB RAM、8GB ストレージ）
+
+## 学習目標
+
+このワークショップを終えるまでに、参加者は以下のことができるようになります：
+
+- OpenTelemetry のコンポーネントを理解する
+- receivers、processors、exporters を使用してデータを収集・分析する
+- OpenTelemetry を使用するメリットを把握する
+- ビジネスニーズを解決するためのカスタムコンポーネントを構築する
+
+## OpenTelemetry のアーキテクチャ
+
+{{< mermaid >}}
+%%{
+ init:{
+ "theme":"base",
+ "themeVariables": {
+ "primaryColor": "#ffffff",
+ "clusterBkg": "#eff2fb",
+ "defaultLinkColor": "#333333"
+ }
+ }
+}%%
+
+flowchart LR;
+ subgraph Collector
+ A[OTLP] --> M(Receivers)
+ B[JAEGER] --> M(Receivers)
+ C[Prometheus] --> M(Receivers)
+ end
+ subgraph Processors
+ M(Receivers) --> H(Filters, Attributes, etc)
+ E(Extensions)
+ end
+ subgraph Exporters
+ H(Filters, Attributes, etc) --> S(OTLP)
+ H(Filters, Attributes, etc) --> T(JAEGER)
+ H(Filters, Attributes, etc) --> U(Prometheus)
+ end
+{{< /mermaid >}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-1-validation.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-1-validation.md
new file mode 100644
index 0000000000..16ac0c0f59
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-1-validation.md
@@ -0,0 +1,60 @@
+---
+title: 1.1 Validation & Load Generation
+linkTitle: 1.1 Validation & Load Generation
+weight: 1
+---
+
+このワークショップでは、[**https://otelbin.io**](https://otelbin.io/) を使用して YAML 構文を素早く検証し、OpenTelemetry の構成が正確であることを確認します。このステップは、セッション中にテストを実行する前にエラーを回避するのに役立ちます。
+
+{{% notice title="Exercise" style="green" icon="running" %}}
+構成を検証する方法は次のとおりです。
+
+1. [**https://otelbin.io**](https://otelbin.io/) を開き、左ペインに YAML を貼り付けて既存の構成を置き換えます。
+ > [!INFO]
+ > Mac を使用しており、Splunk Workshop インスタンスを使用していない場合は、次のコマンドを実行することで、`agent.yaml` ファイルの内容を素早くクリップボードにコピーできます。
+ >
+ > ```bash
+ > cat agent.yaml | pbcopy
+ > ```
+
+2. ページの上部で、検証対象として **Splunk OpenTelemetry Collector** が選択されていることを確認してください。このオプションを選択し**ない**場合、UI に `Receiver "hostmetrics" is unused. (Line 8)` という警告が表示されます。
+
+3. 検証が完了したら、以下の画像表現を参照して、パイプラインが正しく設定されていることを確認してください。
+
+ほとんどの場合、**主要なパイプライン**のみを表示します。ただし、3 つのパイプライン (Traces、Metrics、Logs) すべてが同じ構造を共有している場合は、それぞれを個別に示すのではなく、その旨を記載します。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resourcedetection
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-traces
+ subgraph " "
+ subgraph subID1[**Traces/Metrics/Logs**]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> EXP1
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fff,stroke-width:1px, color:#fff,stroke-dasharray: 3 3;
+```
+
+{{% /notice %}}
+
+---
+
+## Load Generation Tool
+
+このワークショップのために、`loadgen` ツールを特別に開発しました。`loadgen` は、トレースおよびロギングアクティビティをシミュレートするための柔軟な負荷生成ツールです。デフォルトで base、health、security のトレースをサポートし、オプションでランダムな引用をプレーンテキストまたは JSON 形式でファイルにロギングする機能も備えています。
+
+`loadgen` によって生成される出力は、OpenTelemetry インストルメンテーションライブラリによって生成されるものを模倣しており、Collector の処理ロジックをテストすることを可能にし、現実のシナリオを模倣するためのシンプルかつ強力な方法を提供します。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-2-test-agent.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-2-test-agent.md
new file mode 100644
index 0000000000..1d0235644c
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-2-test-agent.md
@@ -0,0 +1,95 @@
+---
+title: 1.2 Test Agent Configuration
+linkTitle: 1.2 Test Agent Configuration
+weight: 2
+---
+
+新しく作成した `agent.yaml` を使って OpenTelemetry Collector を起動する準備が整いました。この演習では、OpenTelemetry Collector を通じてデータがどのように流れていくのかを理解するための基礎を築きます。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Agent を起動する**: **Agent terminal** ウィンドウで次のコマンドを実行します。
+
+```bash { title="Start Collector" }
+../otelcol --config=agent.yaml
+```
+
+**デバッグ出力を確認する**: すべてが正しく構成されていれば、出力の最初と最後の行は次のようになります。
+
+```text
+2025/01/13T12:43:51 settings.go:478: Set config to [agent.yaml]
+
+2025-01-13T12:43:51.747+0100 info service@v0.120.0/service.go:261 Everything is ready. Begin running and processing data.
+```
+
+**テスト用 Span を送信する**: アプリケーションを計装する代わりに、`loadgen` ツールを使って OpenTelemetry Collector へトレースデータを送信する動作をシミュレートします。
+
+**Spans terminal** ウィンドウで `1-agent` ディレクトリに移動し、次のコマンドを実行して Span を 1 件送信します。
+
+{{% tabs %}}
+{{% tab title="Start Load Generator" %}}
+
+```bash
+../loadgen -count 1
+```
+
+{{% /tab %}}
+{{% tab title="Load Generator Output" %}}
+
+```text
+Sending traces. Use Ctrl-C to stop.
+Response: {"partialSuccess":{}}
+
+Base trace sent with traceId: 1aacb1db8a6d510f10e52f154a7fdb90 and spanId: 7837a3a2d3635d9f
+ ```
+
+`{"partialSuccess":{}}`: `partialSuccess` フィールドが空であるため、100% 成功したことを示しています。一部が失敗した場合は、このフィールドに失敗した部分の詳細が含まれます。
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**デバッグ出力を確認する**:
+
+**Agent terminal** ウィンドウで Collector のデバッグ出力を確認します。
+
+```text
+2025-03-06T10:11:35.174Z info Traces {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 1}
+2025-03-06T10:11:35.174Z info ResourceSpans #0
+Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
+Resource attributes:
+ -> service.name: Str(cinema-service)
+ -> deployment.environment: Str(production)
+ -> host.name: Str(workshop-instance)
+ -> os.type: Str(linux)
+ -> otelcol.service.mode: Str(agent)
+ScopeSpans #0
+ScopeSpans SchemaURL:
+InstrumentationScope cinema.library 1.0.0
+InstrumentationScope attributes:
+ -> fintest.scope.attribute: Str(Starwars, LOTR)
+Span #0
+ Trace ID : 0ef4daa44a259a7199a948231bc383c0
+ Parent ID :
+ ID : e8fdd442c36cbfb1
+ Name : /movie-validator
+ Kind : Server
+ Start time : 2025-03-06 10:11:35.163557 +0000 UTC
+ End time : 2025-03-06 10:11:36.163557 +0000 UTC
+ Status code : Ok
+ Status message : Success
+Attributes:
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ -> payment.amount: Double(86.48)
+ {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces"}
+```
+
+> [!IMPORTANT]
+> **Agent terminal** ウィンドウで `Ctrl-C` を使って `agent` を停止します。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/1-test-fileexporter.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/1-test-fileexporter.md
new file mode 100644
index 0000000000..b7d605dd9b
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/1-test-fileexporter.md
@@ -0,0 +1,188 @@
+---
+title: 1.3.1 File Exporter のテスト
+linkTitle: 1.3.1 File Exporter のテスト
+weight: 1
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Agent を再起動する**: **Agent ターミナル** ウィンドウを開き、変更した構成を使って `agent` を (再) 起動します。
+
+{{% tabs %}}
+{{% tab title="Start the Agent" %}}
+
+```bash
+../otelcol --config=agent.yaml
+```
+
+{{% /tab %}}
+{{% tab title="Agent Output" %}}
+
+```text
+2025-01-13T12:43:51.747+0100 info service@v0.120.0/service.go:261 Everything is ready. Begin running and processing data.
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**トレースを送信する**: **Spans ターミナル** ウィンドウから別のスパンを送信し、これまでと同じ出力がコンソールに表示されることを確認します。
+
+```bash { title="Start Load Generator" }
+../loadgen -count 1
+```
+
+ここで **Agent ターミナル** ウィンドウの `agent` を `Ctrl-C` で停止し、`agent.out` ファイルが書き出されたことを確認できるようにします。
+
+**`agent.out` ファイルが書き出されたことを確認する**: 現在のディレクトリに `agent.out` という名前のファイルが書き出されているか確認します。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.out # OTLP/Json output created by the File Exporter
+└── agent.yaml
+```
+
+**スパンの形式を確認する**:
+
+1. File Exporter が `agent.out` にスパンを書き出す際に使用する形式を確認します。
+2. 出力は **OTLP/JSON** 形式の 1 行になります。
+3. `agent.out` の内容を表示するには、`cat ./agent.out` コマンドを使用できます。より読みやすい整形済みの表示にするには、`cat ./agent.out | jq` のように `jq` に出力をパイプしてください。
+
+{{% tabs %}}
+{{% tab title="cat ./agent.out" %}}
+
+```json
+{"resourceSpans":[{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"cinema-service"}},{"key":"deployment.environment","value":{"stringValue":"production"}},{"key":"host.name","value":{"stringValue":"workshop-instance"}},{"key":"os.type","value":{"stringValue":"linux"}},{"key":"otelcol.service.mode","value":{"stringValue":"agent"}}]},"scopeSpans":[{"scope":{"name":"cinema.library","version":"1.0.0","attributes":[{"key":"fintest.scope.attribute","value":{"stringValue":"Starwars, LOTR"}}]},"spans":[{"traceId":"d824a28db5aa5f5a3011f19c452e5af0","spanId":"ab4cde146f77eacf","parentSpanId":"","name":"/movie-validator","kind":2,"startTimeUnixNano":"1741256991405300000","endTimeUnixNano":"1741256992405300000","attributes":[{"key":"user.name","value":{"stringValue":"George Lucas"}},{"key":"user.phone_number","value":{"stringValue":"+1555-867-5309"}},{"key":"user.email","value":{"stringValue":"george@deathstar.email"}},{"key":"user.password","value":{"stringValue":"LOTR>StarWars1-2-3"}},{"key":"user.visa","value":{"stringValue":"4111 1111 1111 1111"}},{"key":"user.amex","value":{"stringValue":"3782 822463 10005"}},{"key":"user.mastercard","value":{"stringValue":"5555 5555 5555 4444"}},{"key":"payment.amount","value":{"doubleValue":56.24}}],"status":{"message":"Success","code":1}}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.6.1"}]}
+```
+
+{{% /tab %}}
+{{% tab title="cat ./agent.out | jq" %}}
+
+```json
+{
+ "resourceSpans": [
+ {
+ "resource": {
+ "attributes": [
+ {
+ "key": "service.name",
+ "value": {
+ "stringValue": "cinema-service"
+ }
+ },
+ {
+ "key": "deployment.environment",
+ "value": {
+ "stringValue": "production"
+ }
+ },
+ {
+ "key": "host.name",
+ "value": {
+ "stringValue": "RCASTLEY-M-YQRY.local"
+ }
+ },
+ {
+ "key": "os.type",
+ "value": {
+ "stringValue": "darwin"
+ }
+ },
+ {
+ "key": "otelcol.service.mode",
+ "value": {
+ "stringValue": "agent"
+ }
+ }
+ ]
+ },
+ "scopeSpans": [
+ {
+ "scope": {
+ "name": "cinema.library",
+ "version": "1.0.0",
+ "attributes": [
+ {
+ "key": "fintest.scope.attribute",
+ "value": {
+ "stringValue": "Starwars, LOTR"
+ }
+ }
+ ]
+ },
+ "spans": [
+ {
+ "traceId": "d824a28db5aa5f5a3011f19c452e5af0",
+ "spanId": "ab4cde146f77eacf",
+ "parentSpanId": "",
+ "name": "/movie-validator",
+ "kind": 2,
+ "startTimeUnixNano": "1741256991405300000",
+ "endTimeUnixNano": "1741256992405300000",
+ "attributes": [
+ {
+ "key": "user.name",
+ "value": {
+ "stringValue": "George Lucas"
+ }
+ },
+ {
+ "key": "user.phone_number",
+ "value": {
+ "stringValue": "+1555-867-5309"
+ }
+ },
+ {
+ "key": "user.email",
+ "value": {
+ "stringValue": "george@deathstar.email"
+ }
+ },
+ {
+ "key": "user.password",
+ "value": {
+ "stringValue": "LOTR>StarWars1-2-3"
+ }
+ },
+ {
+ "key": "user.visa",
+ "value": {
+ "stringValue": "4111 1111 1111 1111"
+ }
+ },
+ {
+ "key": "user.amex",
+ "value": {
+ "stringValue": "3782 822463 10005"
+ }
+ },
+ {
+ "key": "user.mastercard",
+ "value": {
+ "stringValue": "5555 5555 5555 4444"
+ }
+ },
+ {
+ "key": "payment.amount",
+ "value": {
+ "doubleValue": 56.24
+ }
+ }
+ ],
+ "status": {
+ "message": "Success",
+ "code": 1
+ }
+ }
+ ]
+ }
+ ],
+ "schemaUrl": "https://opentelemetry.io/schemas/1.6.1"
+ }
+ ]
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/_index.md
new file mode 100644
index 0000000000..b966bd73cc
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-3-fileexporter/_index.md
@@ -0,0 +1,97 @@
+---
+title: 1.3 File Exporter
+linkTitle: 1.3 File Exporter
+weight: 2
+---
+
+画面上のデバッグ出力だけでなく、パイプラインのエクスポートフェーズでも出力を生成したい場合があります。そのために、比較用に OTLP データをファイルへ書き出す **File Exporter** を追加します。
+
+OpenTelemetry の **debug exporter** と **file exporter** の違いは、用途と出力先にあります。
+
+| 機能 | Debug Exporter | File Exporter |
+|-----------------|--------------------------|-------------------------|
+| **出力先** | コンソール／ログ | ディスク上のファイル |
+| **用途** | リアルタイムデバッグ | 永続的なオフライン分析 |
+| **適した用途** | テスト中の素早い確認 | 一時的な保存と共有 |
+| **本番利用** | 不可 | 稀だが可能 |
+| **永続性** | なし | あり |
+
+まとめると、**Debug Exporter** はリアルタイムの開発時トラブルシューティングに適しており、**File Exporter** はテレメトリデータをローカルに保存して後で利用するのに適しています。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Agent terminal** ウィンドウで Collector が起動していないことを確認してから、`agent.yaml` を編集して **File Exporter** を構成します。
+
+1. **`file` exporter の構成**: [**File Exporter**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/fileexporter/README.md) はテレメトリデータをディスク上のファイルに書き出します。
+
+ ```yaml
+ file: # File Exporter
+ path: "./agent.out" # Save path (OTLP/JSON)
+ append: false # Overwrite the file each time
+ ```
+
+1. **Pipelines セクションの更新**: `file` exporter を `traces` パイプラインにのみ追加します。
+
+ ```yaml
+ pipelines:
+ traces:
+ receivers:
+ - otlp # OTLP Receiver
+ processors:
+ - memory_limiter # Memory Limiter processor
+ - resourcedetection # Add system attributes to the data
+ - resource/add_mode # Add collector mode metadata
+ exporters:
+ - debug # Debug Exporter
+ - file # File Exporter
+ metrics:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ exporters:
+ - debug
+ logs:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ exporters:
+ - debug
+ ```
+
+{{% /notice %}}
+
+[**https://otelbin.io**](https://otelbin.io/) を使用して、agent の設定を検証します。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resourcedetection
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2( file
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-traces
+ subgraph " "
+ subgraph subID1["`**Traces**`"]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> EXP1
+ PRO3 --> EXP2
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/1-4-1-test-metadata.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/1-4-1-test-metadata.md
new file mode 100644
index 0000000000..7a4c2bc2f5
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/1-4-1-test-metadata.md
@@ -0,0 +1,182 @@
+---
+title: 1.4.1 リソースメタデータのテスト
+linkTitle: 1.4.1 リソースメタデータのテスト
+weight: 1
+---
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Agent を再起動する**: **Agent ターミナル** ウィンドウで、変更内容をテストするために更新された設定を使って `agent` を再起動します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+すべてが正しくセットアップされていれば、出力の最後の行で collector が稼働していることが確認できるはずです。
+
+```text
+ 2025-01-13T12:43:51.747+0100 info service@v0.120.0/service.go:261 Everything is ready. Begin running and processing data.
+```
+
+**トレースを送信する**: **Spans ターミナル** ウィンドウから（`1-agent` ディレクトリにいることを確認したうえで）、`loadgen` バイナリで再度 span を送信し、新しい `agent.out` を作成します。
+
+```bash { title="Start Load Generator" }
+../loadgen
+```
+
+**Agent のデバッグ出力を確認する**: `resource attributes` セクションに 3 つの新しい行（`host.name`、`os.type`、`otelcol.service.mode`）が表示されているはずです。
+
+```text
+
+Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
+Resource attributes:
+ -> service.name: Str(cinema.service)
+ -> deployment.environment: Str(production)
+ -> host.name: Str([MY_HOST_NAME])
+ -> os.type: Str([MY_OS])
+ -> otelcol.service.mode: Str(agent)
+
+```
+
+**メタデータが span に追加されていることを確認する**: `Ctrl-C` で `loadgen` を停止します。新しい `agent.out` ファイルで以下を確認します。
+
+1. `resourceSpans` セクションに `otelcol.service.mode` 属性が存在し、その値が `agent` であることを確認します。
+2. `resourcedetection` の属性（`host.name` と `os.type`）も存在することを確認します。
+
+これらの値は、パイプラインに設定された processor によって、お使いのデバイスに基づいて自動的に追加されます。
+
+{{% tabs %}}
+{{% tab title="cat ./agent.out" %}}
+
+```json
+{"resourceSpans":[{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"cinema-service"}},{"key":"deployment.environment","value":{"stringValue":"production"}},{"key":"host.name","value":{"stringValue":"RCASTLEY-M-YQRY.local"}},{"key":"os.type","value":{"stringValue":"darwin"}},{"key":"otelcol.service.mode","value":{"stringValue":"agent"}}]},"scopeSpans":[{"scope":{"name":"cinema.library","version":"1.0.0","attributes":[{"key":"fintest.scope.attribute","value":{"stringValue":"Starwars, LOTR"}}]},"spans":[{"traceId":"ae921957a4d93fa11cee640cd7908eb8","spanId":"f6b0f29825efe585","parentSpanId":"","name":"/movie-validator","kind":2,"startTimeUnixNano":"1740994347431796000","endTimeUnixNano":"1740994348431796000","attributes":[{"key":"user.name","value":{"stringValue":"George Lucas"}},{"key":"user.phone_number","value":{"stringValue":"+1555-867-5309"}},{"key":"user.email","value":{"stringValue":"george@deathstar.email"}},{"key":"user.account_password","value":{"stringValue":"LOTR>StarWars1-2-3"}},{"key":"user.visa","value":{"stringValue":"4111 1111 1111 1111"}},{"key":"user.amex","value":{"stringValue":"3782 822463 10005"}},{"key":"user.mastercard","value":{"stringValue":"5555 5555 5555 4444"}}],"status":{"message":"Success","code":1}}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.6.1"}]}
+```
+
+{{% /tab %}}
+{{% tab title="cat ./agent.out | jq" %}}
+
+```json
+{
+ "resourceSpans": [
+ {
+ "resource": {
+ "attributes": [
+ {
+ "key": "service.name",
+ "value": {
+ "stringValue": "cinema-service"
+ }
+ },
+ {
+ "key": "deployment.environment",
+ "value": {
+ "stringValue": "production"
+ }
+ },
+ {
+ "key": "host.name",
+ "value": {
+ "stringValue": "RCASTLEY-M-YQRY.local"
+ }
+ },
+ {
+ "key": "os.type",
+ "value": {
+ "stringValue": "darwin"
+ }
+ },
+ {
+ "key": "otelcol.service.mode",
+ "value": {
+ "stringValue": "agent"
+ }
+ }
+ ]
+ },
+ "scopeSpans": [
+ {
+ "scope": {
+ "name": "cinema.library",
+ "version": "1.0.0",
+ "attributes": [
+ {
+ "key": "fintest.scope.attribute",
+ "value": {
+ "stringValue": "Starwars, LOTR"
+ }
+ }
+ ]
+ },
+ "spans": [
+ {
+ "traceId": "ab984cd113463aa919ac200751fcfc1d",
+ "spanId": "db651e116290a8f2",
+ "parentSpanId": "",
+ "name": "/movie-validator",
+ "kind": 2,
+ "startTimeUnixNano": "1740994462515044000",
+ "endTimeUnixNano": "1740994463515044000",
+ "attributes": [
+ {
+ "key": "user.name",
+ "value": {
+ "stringValue": "George Lucas"
+ }
+ },
+ {
+ "key": "user.phone_number",
+ "value": {
+ "stringValue": "+1555-867-5309"
+ }
+ },
+ {
+ "key": "user.email",
+ "value": {
+ "stringValue": "george@deathstar.email"
+ }
+ },
+ {
+ "key": "user.account_password",
+ "value": {
+ "stringValue": "LOTR>StarWars1-2-3"
+ }
+ },
+ {
+ "key": "user.visa",
+ "value": {
+ "stringValue": "4111 1111 1111 1111"
+ }
+ },
+ {
+ "key": "user.amex",
+ "value": {
+ "stringValue": "3782 822463 10005"
+ }
+ },
+ {
+ "key": "user.mastercard",
+ "value": {
+ "stringValue": "5555 5555 5555 4444"
+ }
+ }
+ ],
+ "status": {
+ "message": "Success",
+ "code": 1
+ }
+ }
+ ]
+ }
+ ],
+ "schemaUrl": "https://opentelemetry.io/schemas/1.6.1"
+ }
+ ]
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルウィンドウで `Ctrl-C` を使って `agent` プロセスと `loadgen` プロセスを停止します。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/_index.md
new file mode 100644
index 0000000000..8e97b06330
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/1-4-metadata/_index.md
@@ -0,0 +1,90 @@
+---
+title: 1.4 Resource Metadata
+linkTitle: 1.4 Resource Metadata
+weight: 3
+hidden: true
+---
+
+ここまでは、OpenTelemetry Collector を経由するスパンをそのまま複製してエクスポートしてきました。
+
+ここからは、プロセッサーを使ってメタデータを追加し、ベースとなるスパンを充実させていきます。これらの追加情報は、トラブルシューティングや相関分析に役立ちます。
+
+{{% notice title="Exercise" style="green" icon="running" %}}
+**Collector を停止する**: **Agent ターミナル**ウィンドウで `Ctrl-C` を押し、実行中の Collector を停止してください。`agent` が停止したら、`agent.yaml` を開きます。
+
+**すべてのパイプラインを更新する**: 両方のプロセッサー(`resourcedetection` と `resource/add_mode`)を、**すべてのパイプライン**の `processors` 配列に追加してください。`memory_limiter` が最初のプロセッサーであり続けるようにしてください。
+
+- [**Resource Detection Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md) は、ホストからリソース情報を検出し、その情報をテレメトリデータのリソース値に追加または上書きするために使用されます。
+- [**Resource Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourceprocessor/README.md) は、リソース属性に変更を適用するために使用されます。今回のデフォルト設定では、新しい属性 `otelcol.service.mode` を値 `agent` で追加します。
+
+```yaml
+service: # Services configured for this Collector
+ extensions: # Enabled extensions
+ - health_check
+ pipelines: # Array of configured pipelines
+ traces:
+ receivers:
+ - otlp # OTLP Receiver
+ processors:
+ - memory_limiter # Memory Limiter Processor
+ - resourcedetection # Adds system attributes to the data
+ - resource/add_mode # Adds collector mode metadata
+ exporters:
+ - debug # Debug Exporter
+ - file # File Exporter
+ metrics:
+ receivers:
+ - otlp # OTLP Receiver
+ processors:
+ - memory_limiter # Memory Limiter Processor
+ - resourcedetection # Adds system attributes to the data
+ - resource/add_mode # Adds collector mode metadata
+ exporters:
+ - debug # Debug Exporter
+ - file # File Exporter
+ logs:
+ receivers:
+ - otlp # OTLP Receiver
+ processors:
+ - memory_limiter # Memory Limiter Processor
+ - resourcedetection # Adds system attributes to the data
+ - resource/add_mode # Adds collector mode metadata
+ exporters:
+ - debug # Debug Exporter
+ - file # File Exporter
+
+```
+
+{{% /notice %}}
+
+これらのプロセッサーを追加することで、システムのメタデータと Agent の動作モードでデータを充実させることができ、トラブルシューティングに役立つほか、関連コンテンツに有用なコンテキストを提供します。
+
+**[otelbin.io](https://www.otelbin.io/)** を使用して Agent の設定を検証してください。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resourcedetection
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2( file
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-traces
+ subgraph " "
+ subgraph subID1[**Traces/Metrics/Logs**]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> EXP1
+ PRO3 --> EXP2
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fff,stroke-width:1px, color:#fff,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/_index.md
new file mode 100644
index 0000000000..d2085a1b09
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/1-agent/_index.md
@@ -0,0 +1,107 @@
+---
+title: 1. Agent Configuration
+linkTitle: 1. Agent Setup
+time: 10 minutes
+weight: 3
+---
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+このワークショップでは、最大 5 つのターミナルウィンドウを同時に使用します。整理しやすくするため、各ターミナルやシェルにそれぞれ固有の名前と色を設定することをお勧めします。これにより、必要に応じて素早く識別し、切り替えることができます。
+
+これらのターミナルは、**Agent**、**Gateway**、**Spans**、**Logs**、**Tests** と呼びます。
+{{% /notice %}}
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+1. **Agent ターミナル**ウィンドウで `[WORKSHOP]` ディレクトリに移動し、`1-agent` という名前の新しいサブディレクトリを作成します。
+
+ ```bash
+ mkdir 1-agent && \
+ cd 1-agent
+ ```
+
+2. `agent.yaml` という名前のファイルを作成します。このファイルでは、OpenTelemetry Collector 設定の基本構造を定義します。
+
+3. 以下の初期設定をコピーして `agent.yaml` に貼り付けます。
+
+ ```yaml
+ # Extensions
+ extensions:
+ health_check: # Health Check Extension
+ endpoint: 0.0.0.0:13133 # Health Check Endpoint
+
+ # Receivers
+ receivers:
+ hostmetrics: # Host Metrics Receiver
+ collection_interval: 3600s # Collection Interval (1hr)
+ scrapers:
+ cpu: # CPU Scraper
+ otlp: # OTLP Receiver
+ protocols:
+ http: # Configure HTTP protocol
+ endpoint: "0.0.0.0:4318" # Endpoint to bind to
+
+ # Exporters
+ exporters:
+ debug: # Debug Exporter
+ verbosity: detailed # Detailed verbosity level
+
+ # Processors
+ processors:
+ memory_limiter: # Limits memory usage
+ check_interval: 2s # Check interval
+ limit_mib: 512 # Memory limit in MiB
+ resourcedetection: # Resource Detection Processor
+ detectors: [system] # Detect system resources
+ override: true # Overwrites existing attributes
+ resource/add_mode: # Resource Processor
+ attributes:
+ - action: insert # Action to perform
+ key: otelcol.service.mode # Key name
+ value: "agent" # Key value
+
+ # Connectors
+ #connectors: # leave this commented out; we will uncomment in an upcoming exercise
+
+ # Service Section - Enabled Pipelines
+ service:
+ extensions:
+ - health_check # Health Check Extension
+ pipelines:
+ traces:
+ receivers:
+ - otlp # OTLP Receiver
+ processors:
+ - memory_limiter # Memory Limiter processor
+ - resourcedetection # Add system attributes to the data
+ - resource/add_mode # Add collector mode metadata
+ exporters:
+ - debug # Debug Exporter
+ metrics:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ exporters:
+ - debug
+ logs:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ exporters:
+ - debug
+ ```
+
+4. ディレクトリ構造は次のようになっているはずです。
+
+ ```text
+ .
+ └── agent.yaml # OpenTelemetry Collector configuration file
+ ```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-1-start-gateway.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-1-start-gateway.md
new file mode 100644
index 0000000000..b37f1d8740
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-1-start-gateway.md
@@ -0,0 +1,57 @@
+---
+title: 2.1 Start Gateway
+linkTitle: 2.1 Start Gateway
+weight: 1
+---
+
+`gateway` の設定は、機能させるために追加の設定変更を必要としません。これは、時間を節約し、**Gateway** の中核となる概念に集中するためです。
+
+**[otelbin.io](https://www.otelbin.io/)** を使用して `gateway` の設定を検証します。参考までに、パイプラインの `logs:` セクションは次のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resource
fa:fa-microchip
add_mode):::processor
+ PRO3(batch
fa:fa-microchip):::processor
+ EXP1( file
fa:fa-upload
logs):::exporter
+ EXP2( debug
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-logs
+ subgraph " "
+ subgraph subID1[**Logs**]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> EXP2
+ PRO3 --> EXP1
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
+```
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway の起動**: **Gateway ターミナル** ウィンドウで、次のコマンドを実行して `gateway` を起動します。
+
+```bash {title="Start the Gateway"}
+../otelcol --config=gateway.yaml
+```
+
+すべて正しく設定されていれば、出力の最初と最後の行は次のようになります。
+
+```text
+2025/01/15 15:33:53 settings.go:478: Set config to [gateway.yaml]
+
+2025-01-13T12:43:51.747+0100 info service@v0.120.0/service.go:261 Everything is ready. Begin running and processing data.
+```
+
+{{% /notice %}}
+
+次に、新しく作成した `gateway` にデータを送信するように `agent` を設定します。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-2-configure-agent.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-2-configure-agent.md
new file mode 100644
index 0000000000..8bd77ac14f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-2-configure-agent.md
@@ -0,0 +1,111 @@
+---
+title: 2.2 Configure Agent
+linkTitle: 2.2 Configure Agent
+weight: 2
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**`otlphttp` exporterを追加する**: [**OTLP/HTTP Exporter**](https://help.splunk.com/en/splunk-observability-cloud/manage-data/splunk-distribution-of-the-opentelemetry-collector/get-started-with-the-splunk-distribution-of-the-opentelemetry-collector/collector-components/exporters/otlphttp-exporter) は、**OTLP/HTTP** プロトコルを使用してagentからgatewayにデータを送信するために使用されます。
+
+1. **Agentターミナル** ウィンドウに切り替えます。
+2. 新しく生成された `gateway-logs.out`、`gateway-metrics.out`、`gateway-traces.out` がディレクトリに存在することを確認します。
+3. エディタで `agent.yaml` ファイルを開きます。
+4. `exporters:` セクションに `otlphttp` exporterの設定を追加します:
+
+```yaml
+ otlphttp: # Exporter Type
+ endpoint: "http://localhost:5318" # Gateway OTLP endpoint
+```
+
+**Batch Processorの設定を追加する**: [**Batch Processor**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/batchprocessor/README.md) は、span、metrics、またはlogsを受け取り、それらをバッチにまとめます。バッチ化することで、データをより効率的に圧縮し、データ送信に必要な送信接続の数を減らすことができます。すべてのcollectorでbatch processorを設定することが強く推奨されます。
+
+1. `processors:` セクションに `batch` processorの設定を追加します:
+
+```yaml
+ batch: # Processor Type
+```
+
+**Pipelinesを更新する**:
+
+1. **Hostmetrics Receiverを有効化**:
+ - `metrics` pipelineに `hostmetrics` を追加します。[**HostMetrics Receiver**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver#readme) は、現在の設定では1時間に1回ホストCPUメトリクスを生成します。
+2. **Batch Processorを有効化**:
+ - `traces`、`metrics`、`logs` pipelineに（`resource/add_mode` processorの後に）`batch` processorを追加します。
+3. **OTLPHTTP Exporterを有効化**:
+ - `traces`、`metrics`、`logs` pipelineに `otlphttp` exporterを追加します。
+
+```yaml
+ pipelines:
+ traces:
+ receivers:
+ - otlp # OTLP Receiver
+ processors:
+ - memory_limiter # Memory Limiter processor
+ - resourcedetection # Add system attributes to the data
+ - resource/add_mode # Add collector mode metadata
+ - batch # Batch processor
+ exporters:
+ - debug # Debug Exporter
+ - file # File Exporter
+ - otlphttp # OTLP/HTTP Exporter
+ metrics:
+ receivers:
+ - otlp
+ - hostmetrics # Host Metrics Receiver
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - otlphttp
+ logs:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - otlphttp
+```
+
+{{% /notice %}}
+
+**[otelbin.io](https://www.otelbin.io/)** を使用してagentの設定を検証します。参考までに、pipelinesの `metrics:` セクションは次のようになります:
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ REC2(hostmetrics
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resourcedetection
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(batch
fa:fa-microchip):::processor
+ EXP1(otlphttp
fa:fa-upload):::exporter
+ EXP2( debug
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-metrics
+ subgraph " "
+ subgraph subID1["`**Metrics**`"]
+ direction LR
+ REC1 --> PRO1
+ REC2 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> PRO4
+ PRO4 --> EXP2
+ PRO4 --> EXP1
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-3-send-metrics.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-3-send-metrics.md
new file mode 100644
index 0000000000..7817c89acd
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-3-send-metrics.md
@@ -0,0 +1,77 @@
+---
+title: 2.3 Agent から Gateway へメトリクスを送信する
+linkTitle: 2.3 Send Metrics
+weight: 3
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Agent を起動する**: **Agent ターミナル** ウィンドウで、更新された設定を使って agent を起動します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**CPU メトリクスを確認する**:
+
+1. `agent` が起動したら、ただちに **CPU** メトリクスの送信を開始することを確認します。
+2. `agent` と `gateway` の両方が、デバッグ出力にこの動作を表示します。出力は次のスニペットのようになるはずです。
+
+```text
+
+NumberDataPoints #37
+Data point attributes:
+ -> cpu: Str(cpu0)
+ -> state: Str(system)
+StartTimestamp: 2024-12-09 14:18:28 +0000 UTC
+Timestamp: 2025-01-15 15:27:51.319526 +0000 UTC
+Value: 9637.660000
+```
+
+この段階で、`agent` は 1 時間ごと、または再起動のたびに **CPU** メトリクスを収集し続け、それらを gateway に送信します。
+
+`gateway` はこれらのメトリクスを処理し、`./gateway-metrics.out` という名前のファイルにエクスポートします。このファイルは、パイプラインサービスの一部としてエクスポートされたメトリクスを保存します。
+
+**データが Gateway に到達したことを確認する**: CPU メトリクス、特に `cpu0` のメトリクスが gateway に正常に到達したことを確認するため、`jq` コマンドを使って `gateway-metrics.out` ファイルを調査します。
+
+次のコマンドは、`system.cpu.time` メトリクスをフィルタリングして抽出し、`cpu0` に焦点を当てます。メトリクスの state（例: `user`、`system`、`idle`、`interrupt`）と対応する値を表示します。
+
+**Tests ターミナル** で以下のコマンドを実行し、`system.cpu.time` メトリクスを確認します。
+
+{{% tabs %}}
+{{% tab title="Check CPU Metrics" %}}
+
+```bash
+jq '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "system.cpu.time") | .sum.dataPoints[] | select(.attributes[0].value.stringValue == "cpu0") | {cpu: .attributes[0].value.stringValue, state: .attributes[1].value.stringValue, value: .asDouble}' gateway-metrics.out
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```json
+{
+ "cpu": "cpu0",
+ "state": "user",
+ "value": 123407.02
+}
+{
+ "cpu": "cpu0",
+ "state": "system",
+ "value": 64866.6
+}
+{
+ "cpu": "cpu0",
+ "state": "idle",
+ "value": 216427.87
+}
+{
+ "cpu": "cpu0",
+ "state": "interrupt",
+ "value": 0
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-4-send-traces.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-4-send-traces.md
new file mode 100644
index 0000000000..cdd535a851
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-4-send-traces.md
@@ -0,0 +1,92 @@
+---
+title: 2.4 Agent から Gateway へトレースを送信する
+linkTitle: 2.4 トレースの送信
+weight: 4
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**テストトレースを送信する**:
+
+1. `agent` と `gateway` がまだ実行中であることを確認します。
+2. **Spans terminal** ウィンドウで、次のコマンドを実行して 5 つのスパンを送信し、`agent` と `gateway` のデバッグログの出力を検証します。
+
+{{% tabs %}}
+{{% tab title="Start the Load Generator" %}}
+
+```bash
+../loadgen -count 5
+```
+
+{{% /tab %}}
+{{% tab title="Agent/Gateway Debug Output" %}}
+
+```text
+2025-03-06T11:49:00.456Z info Traces {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 1}
+2025-03-06T11:49:00.456Z info ResourceSpans #0
+Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
+Resource attributes:
+ -> service.name: Str(cinema-service)
+ -> deployment.environment: Str(production)
+ -> host.name: Str(workshop-instance)
+ -> os.type: Str(linux)
+ -> otelcol.service.mode: Str(agent)
+ScopeSpans #0
+ScopeSpans SchemaURL:
+InstrumentationScope cinema.library 1.0.0
+InstrumentationScope attributes:
+ -> fintest.scope.attribute: Str(Starwars, LOTR)
+Span #0
+ Trace ID : 97fb4e5b13400b5689e3306da7cff077
+ Parent ID :
+ ID : 413358465e5b4f15
+ Name : /movie-validator
+ Kind : Server
+ Start time : 2025-03-06 11:49:00.431915 +0000 UTC
+ End time : 2025-03-06 11:49:01.431915 +0000 UTC
+ Status code : Ok
+ Status message : Success
+Attributes:
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ -> payment.amount: Double(87.01)
+ {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces"}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**Gateway がスパンを処理したことを確認する**: Gateway は受信したスパンを処理すると、トレースデータを `gateway-traces.out` というファイルに書き込みます。スパンが正常に処理されたことを確認するには、このファイルを調べます。
+
+**Tests terminal** で `jq` コマンドを使用して、各スパンの `spanId` やファイル内の位置などの主要な詳細情報を抽出して表示します。また、**Hostmetrics Receiver** がスパンに追加した属性も抽出できます。
+
+{{% tabs %}}
+{{% tab title="Inspect the Gateway Trace File" %}}
+
+```bash
+jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | "Span \(input_line_number) found with spanId \(.spanId), hostname \($resource.resource.attributes[] | select(.key == "host.name") | .value.stringValue), os \($resource.resource.attributes[] | select(.key == "os.type") | .value.stringValue)"' ./gateway-traces.out
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+"Span 1 found with spanId d71fe6316276f97d, hostname workshop-instance, os linux"
+"Span 2 found with spanId e8d19489232f8c2a, hostname workshop-instance, os linux"
+"Span 3 found with spanId 9dfaf22857a6bd05, hostname workshop-instance, os linux"
+"Span 4 found with spanId c7f544a4b5fef5fc, hostname workshop-instance, os linux"
+"Span 5 found with spanId 30bb49261315969d, hostname workshop-instance, os linux"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、`agent` と `gateway` のプロセスを停止します。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-5-addendum.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-5-addendum.md
new file mode 100644
index 0000000000..7d4d72c6de
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/2-5-addendum.md
@@ -0,0 +1,89 @@
+---
+title: 2.5 補足 - アクセストークンとバッチ処理に関する情報
+linkTitle: 2.5 Addendum
+weight: 5
+hidden: true
+---
+
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+
+## otlphttp Exporter の概要
+
+`otlphttp` exporter は、Splunk Observability Cloud にメトリクスとトレースを送信する際の現在のデフォルトの方式です。この exporter は、OpenTelemetry Protocol (OTLP) を HTTP 経由で利用し、テレメトリデータを標準化された効率的な方法で送信できます。
+
+Splunk Distribution of the OpenTelemetry Collector をホスト監視 (agent) モードでデプロイする場合、`otlphttp` exporter はデフォルトで含まれています。これは `sapm` や `signalfx` といった旧来の exporter を置き換えるもので、これらの旧 exporter は段階的に廃止されつつあります。
+
+{{% /notice %}}
+
+## Splunk アクセストークンの設定
+
+Splunk Observability Cloud に対して認証を行いデータを送信するには、アクセストークンを適切に設定する必要があります。
+OpenTelemetry では、認証は HTTP ヘッダーを介して処理されます。アクセストークンを渡すには、`headers:` キーとそのサブキーである `X-SF-Token:` を使用します。この設定は agent モードと gateway モードの両方で機能します。
+
+例:
+
+```yaml
+exporters:
+ otlphttp:
+ endpoint: "https://ingest..signalfx.com"
+ headers:
+ X-SF-Token: "your-access-token"
+```
+
+### Pass-Through モード
+
+ヘッダーをパイプライン経由で転送する必要がある場合は、OTLP receiver の設定で `include_metadata:` を `true` に設定し、pass-through モードを有効にしてください。これにより、collector が受信した認証ヘッダーが保持され、データとともに転送されます。
+
+例:
+
+```yaml
+receivers:
+ otlp:
+ protocols:
+ http:
+ include_metadata: true
+```
+
+これは特に gateway モードにおいて有用で、複数の agent からのデータが Splunk へ送信される前に集約された gateway を経由するケースで役立ちます。
+
+## バッチ処理の理解
+
+Batch Processor は、データ送信効率を最適化するための重要なコンポーネントです。トレース、メトリクス、ログをバッチにまとめてからバックエンドに送信します。バッチ処理は以下の点でパフォーマンスを向上させます。
+
+- 送信リクエスト数を削減します。
+- 圧縮効率を向上させます。
+- ネットワークオーバーヘッドを低減します。
+
+### Batch Processor の設定
+
+バッチ処理を有効にするには、`batch:` セクションを設定し、`X-SF-Token:` キーを含めてください。これにより、Splunk Observability Cloud に送信される前にデータが正しくグループ化されます。
+
+例:
+
+```yaml
+processors:
+ batch:
+ metadata_keys: [X-SF-Token] # Array of metadata keys to batch
+ send_batch_size: 100
+ timeout: 5s
+```
+
+### バッチ処理のベストプラクティス
+
+最適なパフォーマンスを得るためには、すべての collector のデプロイに Batch Processor を使用することが推奨されます。Batch Processor の最適な配置位置は、**memory limiter およびサンプリング processor の後** です。これにより、必要なデータのみがバッチ化され、ドロップされたデータに対する不要な処理を回避できます。
+
+### Batch Processor を使った Gateway の設定
+
+gateway をデプロイする際は、Batch Processor がパイプラインに含まれていることを確認してください。
+
+```yaml
+service:
+ pipelines:
+ traces:
+ processors: [memory_limiter, tail_sampling, batch]
+```
+
+## まとめ
+
+`otlphttp` exporter は、Splunk Observability Cloud にテレメトリデータを送信する際に現在推奨される方式です。Splunk アクセストークンを適切に設定することで安全なデータ送信が可能になり、Batch Processor によりネットワークオーバーヘッドを削減してパフォーマンスを最適化できます。これらのベストプラクティスを実践することで、オブザーバビリティデータを大規模に効率よく収集・送信できます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/_index.md
new file mode 100644
index 0000000000..34db82bf77
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/2-gateway/_index.md
@@ -0,0 +1,116 @@
+---
+title: 2. Gateway の構成
+linkTitle: 2. Gateway のセットアップ
+time: 10 minutes
+weight: 4
+---
+
+OpenTelemetry Gateway は、テレメトリーデータの受信・処理・エクスポートを行うように設計されています。テレメトリーソース（アプリケーションやサービスなど）と、バックエンド（Prometheus、Jaeger、Splunk Observability Cloud などの可観測性プラットフォーム）の間の中継役として動作します。
+
+Gateway が有用なのは、テレメトリーデータの収集を一元化し、データのフィルタリング、変換、複数の宛先へのルーティングといった機能を実現できるためです。また、テレメトリー処理をオフロードすることで個々のサービスの負荷を軽減し、分散システム全体で一貫したデータフォーマットを保証します。これにより、複雑な環境でテレメトリーデータの管理、スケール、分析が容易になります。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- **Gateway terminal** ウィンドウで `[WORKSHOP]` ディレクトリに移動し、`2-gateway` という名前のサブディレクトリを新規作成します。
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `[WORKSHOP]/2-gateway` ディレクトリに移動してください。**
+
+- **Gateway terminal** ウィンドウに戻り、`1-agent` ディレクトリの `agent.yaml` を `2-gateway` にコピーします。
+- `gateway.yaml` というファイルを作成し、以下の初期設定を追加します。
+
+```yaml { title="gateway.yaml" }
+########################### This section holds all the
+## Configuration section ## configurations that can be
+########################### used in this OpenTelemetry Collector
+extensions: # List of extensions
+ health_check: # Health check extension
+ endpoint: 0.0.0.0:14133 # Custom port to avoid conflicts
+
+receivers:
+ otlp: # OTLP receiver
+ protocols:
+ http: # HTTP protocol
+ endpoint: "0.0.0.0:5318" # Custom port to avoid conflicts
+ include_metadata: true # Required for token pass-through
+
+exporters: # List of exporters
+ debug: # Debug exporter
+ verbosity: detailed # Enable detailed debug output
+ file/traces: # Exporter Type/Name
+ path: "./gateway-traces.out" # Path for OTLP JSON output
+ append: false # Overwrite the file each time
+ file/metrics: # Exporter Type/Name
+ path: "./gateway-metrics.out" # Path for OTLP JSON output
+ append: false # Overwrite the file each time
+ file/logs: # Exporter Type/Name
+ path: "./gateway-logs.out" # Path for OTLP JSON output
+ append: false # Overwrite the file each time
+
+processors: # List of processors
+ memory_limiter: # Limits memory usage
+ check_interval: 2s # Memory check interval
+ limit_mib: 512 # Memory limit in MiB
+ batch: # Batches data before exporting
+ metadata_keys: # Groups data by token
+ - X-SF-Token
+ resource/add_mode: # Adds metadata
+ attributes:
+ - action: upsert # Inserts or updates a key
+ key: otelcol.service.mode # Key name
+ value: "gateway" # Key value
+
+# Connectors
+#connectors: # leave this commented out; we will uncomment in an upcoming exercise
+
+###########################
+### Activation Section ###
+###########################
+service: # Service configuration
+ telemetry:
+ metrics:
+ level: none # Disable metrics
+ extensions: [health_check] # Enabled extensions
+ pipelines: # Configured pipelines
+ traces: # Traces pipeline
+ receivers:
+ - otlp # OTLP receiver
+ processors: # Processors for traces
+ - memory_limiter
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug # Debug exporter
+ - file/traces
+ metrics: # Metrics pipeline
+ receivers:
+ - otlp # OTLP receiver
+ processors: # Processors for metrics
+ - memory_limiter
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug # Debug exporter
+ - file/metrics
+ logs: # Logs pipeline
+ receivers:
+ - otlp # OTLP receiver
+ processors: # Processors for logs
+ - memory_limiter
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug # Debug exporter
+ - file/logs
+```
+
+> [!NOTE]
+> `gateway` を起動すると、`gateway-traces.out`、`gateway-metrics.out`、`gateway-logs.out` の 3 つのファイルが生成されます。これらのファイルには、最終的に Gateway が受信したテレメトリーデータが書き込まれます。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-1-configuration.md
new file mode 100644
index 0000000000..68df3f729e
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-1-configuration.md
@@ -0,0 +1,73 @@
+---
+title: 3.1 Configuration
+linkTitle: 3.1 Configuration
+weight: 1
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+**Agent terminal** ウィンドウで `agent.yaml` を編集し、FileLog レシーバーを設定します。
+
+1. **FileLog レシーバーの設定**: `filelog` レシーバーは、ファイルからログデータを読み取り、ログデータにカスタムリソース属性を含めます。
+
+ ```yaml
+ filelog/quotes: # Receiver Type/Name
+ include: ./quotes.log # The file to read log data from
+ include_file_path: true # Include file path in the log data
+ include_file_name: false # Exclude file name from the log data
+ resource: # Add custom resource attributes
+ com.splunk.source: ./quotes.log # Source of the log data
+ com.splunk.sourcetype: quotes # Source type of the log data
+ ```
+
+2. **`logs` パイプラインの更新**: `logs` パイプラインにのみ `filelog/quotes` レシーバーを追加します。
+
+ ```yaml
+ logs:
+ receivers:
+ - otlp
+ - filelog/quotes # Filelog Receiver
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - otlphttp
+ ```
+
+3. **設定の検証**: 更新した `agent.yaml` を **[otelbin.io](https://www.otelbin.io/)** に貼り付けます。参考までに、パイプラインの `logs:` セクションは次のような表示になります。
+
+ ```mermaid
+ %%{init:{"fontFamily":"monospace"}}%%
+ graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ REC2(filelog
fa:fa-download
quotes):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resourcedetection
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(batch
fa:fa-microchip):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2(otlphttp
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-logs
+ subgraph " "
+ subgraph subID1[**Logs**]
+ direction LR
+ REC1 --> PRO1
+ REC2 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> PRO4
+ PRO4 --> EXP1
+ PRO4 --> EXP2
+ end
+ end
+ classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+ classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+ classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+ classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
+ ```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-2-test-filelog.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-2-test-filelog.md
new file mode 100644
index 0000000000..6b10b3ab04
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/3-2-test-filelog.md
@@ -0,0 +1,150 @@
+---
+title: 3.2 Test FileLog Receiver
+linkTitle: 3.2 Test FileLog Receiver
+weight: 4
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway を起動する**: **Gateway terminal** ウィンドウで `gateway` を起動します。
+
+**Agent を起動する**: **Agent terminal** ウィンドウで `agent` を起動します。
+
+`quotes.log` からのログデータの連続的なストリームが、`agent` と `gateway` のデバッグログに表示されます。
+
+```text { title="Agent/Gateway Debug Output" }
+Timestamp: 1970-01-01 00:00:00 +0000 UTC
+SeverityText:
+SeverityNumber: Unspecified(0)
+Body: Str(2025-03-06 15:18:32 [ERROR] - There is some good in this world, and it's worth fighting for. LOTR)
+Attributes:
+ -> log.file.path: Str(quotes.log)
+Trace ID:
+Span ID:
+Flags: 0
+LogRecord #1
+```
+
+**`loadgen` を停止する**: **Logs terminal** ウィンドウで、`Ctrl-C` を使って `loadgen` を停止します。
+
+**gateway を確認する**: `gateway` が `./gateway-logs.out` ファイルを書き出しているかを確認します。
+
+この時点で、ディレクトリ構造は以下のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.out
+├── agent.yaml
+├── gateway-logs.out # Output from the logs pipeline
+├── gateway-metrics.out # Output from the metrics pipeline
+├── gateway-traces.out # Output from the traces pipeline
+├── gateway.yaml
+└── quotes.log # File containing Random log lines
+```
+
+**ログ行を調べる**: `gateway-logs.out` の中のログ行を、以下のスニペットと比較します。ログエントリに、以前メトリクスやトレースのデータで見たものと同じ属性が含まれていることを確認します。
+
+{{% tabs %}}
+{{% tab title="cat /gateway-logs.out" %}}
+
+```json
+{"resourceLogs":[{"resource":{"attributes":[{"key":"com.splunk.source","value":{"stringValue":"./quotes.log"}},{"key":"com.splunk.sourcetype","value":{"stringValue":"quotes"}},{"key":"host.name","value":{"stringValue":"workshop-instance"}},{"key":"os.type","value":{"stringValue":"linux"}},{"key":"otelcol.service.mode","value":{"stringValue":"gateway"}}]},"scopeLogs":[{"scope":{},"logRecords":[{"observedTimeUnixNano":"1741274312475540000","body":{"stringValue":"2025-03-06 15:18:32 [DEBUG] - All we have to decide is what to do with the time that is given us. LOTR"},"attributes":[{"key":"log.file.path","value":{"stringValue":"quotes.log"}}],"traceId":"","spanId":""},{"observedTimeUnixNano":"1741274312475560000","body":{"stringValue":"2025-03-06 15:18:32 [DEBUG] - Your focus determines your reality. SW"},"attributes":[{"key":"log.file.path","value":{"stringValue":"quotes.log"}}],"traceId":"","spanId":""}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.6.1"}]}
+```
+
+{{% /tab %}}
+{{% tab title="cat ./gateway-logs.out | jq" %}}
+
+```json
+{
+ "resourceLogs": [
+ {
+ "resource": {
+ "attributes": [
+ {
+ "key": "com.splunk.source",
+ "value": {
+ "stringValue": "./quotes.log"
+ }
+ },
+ {
+ "key": "com.splunk.sourcetype",
+ "value": {
+ "stringValue": "quotes"
+ }
+ },
+ {
+ "key": "host.name",
+ "value": {
+ "stringValue": "workshop-instance"
+ }
+ },
+ {
+ "key": "os.type",
+ "value": {
+ "stringValue": "linux"
+ }
+ },
+ {
+ "key": "otelcol.service.mode",
+ "value": {
+ "stringValue": "gateway"
+ }
+ }
+ ]
+ },
+ "scopeLogs": [
+ {
+ "scope": {},
+ "logRecords": [
+ {
+ "observedTimeUnixNano": "1741274312475540000",
+ "body": {
+ "stringValue": "2025-03-06 15:18:32 [DEBUG] - All we have to decide is what to do with the time that is given us. LOTR"
+ },
+ "attributes": [
+ {
+ "key": "log.file.path",
+ "value": {
+ "stringValue": "quotes.log"
+ }
+ }
+ ],
+ "traceId": "",
+ "spanId": ""
+ },
+ {
+ "observedTimeUnixNano": "1741274312475560000",
+ "body": {
+ "stringValue": "2025-03-06 15:18:32 [DEBUG] - Your focus determines your reality. SW"
+ },
+ "attributes": [
+ {
+ "key": "log.file.path",
+ "value": {
+ "stringValue": "quotes.log"
+ }
+ }
+ ],
+ "traceId": "",
+ "spanId": ""
+ }
+ ]
+ }
+ ],
+ "schemaUrl": "https://opentelemetry.io/schemas/1.6.1"
+ }
+ ]
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+すべてのログ行に、`"traceId":""` と `"spanId":""` の空のプレースホルダーが含まれていることに気付いたかもしれません。
+FileLog receiver は、これらのフィールドがログ行にまだ存在しない場合にのみ、これらを設定します。
+たとえば、ログ行が OpenTelemetry のインストルメンテーションライブラリで計装されたアプリケーションによって生成された場合、これらのフィールドはすでに含まれており、上書きされることはありません。
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、`agent` と `gateway` のプロセスを停止してください。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/_index.md
new file mode 100644
index 0000000000..2d53e9f74c
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/3-filelog/_index.md
@@ -0,0 +1,66 @@
+---
+title: 3. FileLog Setup
+linkTitle: 3. FileLog Setup
+time: 10 minutes
+weight: 5
+---
+
+OpenTelemetry Collector の [**FileLog Receiver**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/filelogreceiver/README.md) は、ファイルからログを取り込むために使用します。
+
+指定されたファイルを監視して新しいログエントリを検出し、それらのログを Collector にストリーミングして、後続の処理やエクスポートを行います。テストや開発の用途にも便利です。
+
+ワークショップのこのパートでは、`loadgen` がランダムな名言を使ってログを生成します:
+
+```golang
+lotrQuotes := []string{
+ "One does not simply walk into Mordor.",
+ "Even the smallest person can change the course of the future.",
+ "All we have to decide is what to do with the time that is given us.",
+ "There is some good in this world, and it's worth fighting for.",
+}
+
+starWarsQuotes := []string{
+ "Do or do not, there is no try.",
+ "The Force will be with you. Always.",
+ "I find your lack of faith disturbing.",
+ "In my experience, there is no such thing as luck.",
+}
+```
+
+`agent` Collector の **FileLog receiver** は、これらのログ行を読み取って `gateway` に送信します。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- **Logs ターミナル** ウィンドウで、`[WORKSHOP]` ディレクトリに移動し、`3-filelog` という新しいサブディレクトリを作成します。
+- 次に、`2-gateway` から `*.yaml` を `3-filelog` にコピーします。
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `[WORKSHOP]/3-filelog` ディレクトリに変更してください。**
+
+`loadgen` を起動すると、`quotes.log` というファイルに行の書き込みが始まります:
+
+{{% tabs %}}
+{{% tab title="Log Load Generator" %}}
+
+```bash
+../loadgen -logs
+```
+
+{{% /tab %}}
+{{% tab title="Log Load Generator Output" %}}
+
+```text
+Writing logs to quotes.log. Press Ctrl+C to stop.
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+├── gateway.yaml
+└── quotes.yaml
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-1-configuration.md
new file mode 100644
index 0000000000..cf0977d13e
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-1-configuration.md
@@ -0,0 +1,91 @@
+---
+title: 4.1 File Storage の設定
+linkTitle: 4.1 設定
+weight: 1
+---
+
+この演習では、`agent.yaml` ファイルの `extensions:` セクションを更新します。このセクションは OpenTelemetry の設定 YAML の一部であり、OpenTelemetry Collector の挙動を拡張または変更するオプションコンポーネントを定義します。
+
+これらのコンポーネントはテレメトリデータを直接処理するわけではありませんが、Collector の機能を強化する有用な機能やサービスを提供します。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**`agent.yaml` の更新**: **Agent ターミナル** ウィンドウで、`file_storage` エクステンションを追加し、`checkpoint` という名前を付けます。
+
+```yaml
+ file_storage/checkpoint: # Extension Type/Name
+ directory: "./checkpoint-dir" # Define directory
+ create_directory: true # Create directory
+ timeout: 1s # Timeout for file operations
+ compaction: # Compaction settings
+ on_start: true # Start compaction at Collector startup
+ # Define compaction directory
+ directory: "./checkpoint-dir/tmp"
+ max_transaction_size: 65536 # Max. size limit before compaction occurs
+```
+
+**既存の `otlphttp` エクスポーターに `file_storage` を追加**: `otlphttp:` エクスポーターを変更してリトライおよびキューイングのメカニズムを設定し、障害発生時にデータを保持して再送できるようにします。
+
+```yaml
+ otlphttp:
+ endpoint: "http://localhost:5318"
+ retry_on_failure:
+ enabled: true # Enable retry on failure
+ sending_queue: #
+ enabled: true # Enable sending queue
+ num_consumers: 10 # No. of consumers
+ queue_size: 10000 # Max. queue size
+ storage: file_storage/checkpoint # File storage extension
+```
+
+**`services` セクションの更新**: 既存の `extensions:` セクションに `file_storage/checkpoint` エクステンションを追加します。これによりエクステンションが有効になります。
+
+```yaml
+service:
+ extensions:
+ - health_check
+ - file_storage/checkpoint # Enabled extensions for this collector
+```
+
+**`metrics` パイプラインの更新**: この演習では、デバッグやログのノイズを減らすために、Metrics パイプラインから `hostmetrics` レシーバーを削除します。
+
+```yaml
+ metrics:
+ receivers:
+ - otlp
+ # - hostmetrics # Hostmetrics Receiver
+```
+
+{{% /notice %}}
+
+**[otelbin.io](https://www.otelbin.io/)** を使って `agent` の設定を検証してください。参考までに、パイプラインの `metrics:` セクションは以下のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resourcedetection
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(batch
fa:fa-microchip):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2(otlphttp
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-metrics
+ subgraph " "
+ subgraph subID1["`**Metrics**`"]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> PRO4
+ PRO4 --> EXP1
+ PRO4 --> EXP2
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-2-test-environment.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-2-test-environment.md
new file mode 100644
index 0000000000..279253ba65
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-2-test-environment.md
@@ -0,0 +1,33 @@
+---
+title: 4.2 レジリエンステスト用の環境構築
+linkTitle: 4.2 環境構築
+weight: 2
+---
+
+次に、**File Storage** 設定をテストする準備として、環境を構成していきます。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway を起動**: **Gateway terminal** ウィンドウで `[WORKSHOP]/4-resilience` ディレクトリに移動し、次のコマンドを実行します。
+
+```bash { title="Start the Gateway" }
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動**: **Agent terminal** ウィンドウで `[WORKSHOP]/4-resilience` ディレクトリに移動し、次のコマンドを実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**5 件のテスト span を送信**: **Spans terminal** ウィンドウで `[WORKSHOP]/4-resilience` ディレクトリに移動し、次のコマンドを実行します。
+
+```bash { title="Start Load Generator" }
+../loadgen -count 5
+```
+
+`agent` と `gateway` の両方でデバッグログが表示され、`gateway` 側には `./gateway-traces.out` ファイルが作成されているはずです。
+
+{{% /notice %}}
+
+すべて正常に動作していれば、システムのレジリエンステストに進めます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-3-failure.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-3-failure.md
new file mode 100644
index 0000000000..22db061b7f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-3-failure.md
@@ -0,0 +1,46 @@
+---
+title: 4.3 障害をシミュレートする
+linkTitle: 4.3 障害をシミュレートする
+weight: 3
+---
+
+**Agent** のレジリエンスを評価するため、`gateway` の一時的な停止をシミュレートし、`agent` がどのように対処するかを観察します。
+
+**概要**:
+
+1. **Agent にトレースを送信** – `agent` にトレースを送信してトラフィックを生成します。
+2. **Gateway を停止** – これにより `agent` がリトライモードに入ります。
+3. **Gateway を再起動** – `agent` は永続キューからトレースを復元し、正常に転送します。永続キューがなければ、これらのトレースは永久に失われていたでしょう。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**ネットワーク障害をシミュレートする**: **Gateway terminal** で `Ctrl-C` を使って `gateway` を停止し、gateway のコンソールに停止したことが表示されるまで待ちます。
+
+```text
+2025-01-28T13:24:32.785+0100 info service@v0.120.0/service.go:309 Shutdown complete.
+```
+
+**トレースを送信する**: **Spans terminal** ウィンドウで、`loadgen` を使ってさらに 5 つのトレースを送信します。
+
+agent がデータの再送信を継続的に試みることでリトライメカニズムが起動することに注目してください。agent のコンソール出力には、以下のような繰り返しメッセージが表示されます。
+
+```text
+2025-01-28T14:22:47.020+0100 info internal/retry_sender.go:126 Exporting failed. Will retry the request after interval. {"kind": "exporter", "data_type": "traces", "name": "otlphttp", "error": "failed to make an HTTP request: Post \"http://localhost:5318/v1/traces\": dial tcp 127.0.0.1:5318: connect: connection refused", "interval": "9.471474933s"}
+```
+
+**Agent を停止する**: **Agent terminal** ウィンドウで、`Ctrl-C` を使って agent を停止します。agent のコンソールに停止したことが表示されるまで待ちます。
+
+```text
+2025-01-28T14:40:28.702+0100 info extensions/extensions.go:66 Stopping extensions...
+2025-01-28T14:40:28.702+0100 info service@v0.120.0/service.go:309 Shutdown complete.
+```
+
+{{% /notice %}}
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+agent を停止すると、リトライ試行が停止し、以降のリトライ動作が発生しなくなります。
+
+agent がデータを正常に配信できないまま長時間動作し続けると、リトライ設定によってはメモリを節約するためにトレースをドロップし始める場合があります。agent を停止することで、メモリ内に現在保持されているメトリクス、トレース、ログがドロップされる前に失われ、復旧時に利用可能な状態を保つことができます。
+
+このステップは、agent を再起動した際の復旧プロセスを明確に観察するために不可欠です。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-4-recovery.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-4-recovery.md
new file mode 100644
index 0000000000..3576822df3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/4-4-recovery.md
@@ -0,0 +1,78 @@
+---
+title: 4.4 Recovery
+linkTitle: 4.4 Recovery
+weight: 4
+---
+
+この演習では、**Gateway** コレクターを再起動することで、**OpenTelemetry Collector** がネットワーク障害からどのように回復するかをテストします。`gateway` が再び利用可能になると、`agent` は最後にチェックポイントが記録された状態からデータの送信を再開し、データ損失が発生しないことを保証します。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway を再起動する**: **Gateway ターミナル** ウィンドウで以下を実行します。
+
+```bash {title="Gateway"}
+../otelcol --config=gateway.yaml
+```
+
+**Agent を再起動する**: **Agent ターミナル** ウィンドウで以下を実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+{{% /notice %}}
+
+`agent` が起動して稼働を開始すると、**File_Storage** 拡張機能はチェックポイントフォルダー内にバッファリングされたデータを検出します。
+そして、最後のチェックポイントフォルダーから保存済みのスパンをデキューし始め、データが失われないようにします。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Agent のデバッグ出力を確認する**
+Agent のデバッグ画面は変化**しない**ことに注意してください。次の行が表示されたままで、新しいデータがエクスポートされていないことを示しています。
+
+ ```text
+ 2025-02-07T13:40:12.195+0100 info service@v0.120.0/service.go:253 Everything is ready. Begin running and processing data.
+ ```
+
+**Gateway のデバッグ出力を観察する**
+`gateway` のデバッグ画面では、追加の操作を一切行わなくても、それまで送信できなかったトレースの受信を開始したことが確認できるはずです。
+
+ ```txt
+ 2025-02-07T12:44:32.651+0100 info service@v0.120.0/service.go:253 Everything is ready. Begin running and processing data.
+ 2025-02-07T12:47:46.721+0100 info Traces {"kind": "exporter", "data_type": "traces", "name": "debug", "resource spans": 4, "spans": 4}
+ 2025-02-07T12:47:46.721+0100 info ResourceSpans #0
+ Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
+ Resource attributes:
+ ```
+
+**`gateway-traces.out` ファイルを確認する**
+`jq` を使用して、再生成された `gateway-traces.out` 内のトレース数をカウントします。`gateway` がダウンしていた間に送信した数と一致しているはずです。
+
+{{% tabs %}}
+{{% tab title="Check Gateway Traces Out File" %}}
+
+```bash
+jq '.resourceSpans | length | "\(.) resourceSpans found"' gateway-traces.out
+```
+
+{{% /tab %}}
+
+{{% tab title="Example output" %}}
+
+```text
+"5 resourceSpans found"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、`agent` プロセスと `gateway` プロセスを停止してください。
+
+{{% /notice %}}
+
+### まとめ
+
+この演習では、`file_storage` 拡張機能を構成し、`otlp` エクスポーターのリトライ機構を有効化し、ファイルバックアップキューを一時的なデータ保存に使用することで、OpenTelemetry Collector のレジリエンスをどのように高められるかを示しました。
+
+ファイルベースのチェックポイント処理とキューの永続化を実装することで、テレメトリーパイプラインは一時的な中断から優雅に回復できるようになり、本番環境においてより堅牢で信頼性の高いものとなります。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/_index.md
new file mode 100644
index 0000000000..b341832b07
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/4-building-resilience/_index.md
@@ -0,0 +1,36 @@
+---
+title: 4. レジリエンスの組み込み
+linkTitle: 4. レジリエンスの構築
+time: 10 minutes
+weight: 6
+---
+
+OpenTelemetry Collector の [**FileStorage Extension**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/19bc7d6ee854c0c1b5c97d8d348e5b9d1199e8aa/extension/storage/filestorage/README.md) は、信頼性の高いチェックポイント機能、リトライ管理、および一時的な障害への効果的な対応を提供することで、テレメトリーパイプラインのレジリエンスを高めます。
+
+この拡張機能を有効にすると、OpenTelemetry Collector は中間状態をディスクに保存できるようになり、ネットワーク障害時のデータ損失を防ぎ、シームレスに処理を再開できます。
+
+{{% notice note %}}
+
+このソリューションは、接続ダウンタイムが短時間（最大 15 分）であればメトリクスでも動作します。ダウンタイムがこれを超えると、データポイントの順序が崩れることにより Splunk Observability Cloud はデータをドロップします。
+
+ログについては、今後の Splunk OpenTelemetry Collector のリリースで、よりエンタープライズ向けのソリューションを実装する計画があります。
+
+{{% /notice %}}
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- `[WORKSHOP]` ディレクトリ内に、`4-resilience` という名前の新しいサブディレクトリを作成します。
+- 次に、`3-filelog` ディレクトリから `*.yaml` を `4-resilience` にコピーします。
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `[WORKSHOP]/4-resilience` ディレクトリに変更してください。**
+
+更新後のディレクトリ構造は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-1-configuration.md
new file mode 100644
index 0000000000..3cfb26703c
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-1-configuration.md
@@ -0,0 +1,73 @@
+---
+title: 5.1 Configuration
+linkTitle: 5.1 Configuration
+weight: 1
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway ターミナル** ウィンドウに切り替え、`gateway.yaml` ファイルを開いてください。`processors` セクションを以下の設定で更新します。
+
+1. **`filter` プロセッサーを追加する**:
+ `/_healthz` という名前のスパンを除外するように Gateway を設定します。`error_mode: ignore` ディレクティブは、フィルタリング中に発生したエラーを無視し、パイプラインが問題なく稼働し続けることを保証します。`traces` セクションではフィルタリングルールを定義しており、特に `/_healthz` という名前のスパンを除外対象とします。
+
+ ```yaml
+ filter/health: # Defines a filter processor
+ error_mode: ignore # Ignore errors
+ traces: # Filtering rules for traces
+ span: # Exclude spans named "/_healthz"
+ - 'name == "/_healthz"'
+ ```
+
+2. **`filter` プロセッサーを `traces` パイプラインに追加する**:
+ `filter/health` プロセッサーを `traces` パイプラインに含めます。最適なパフォーマンスを得るために、フィルターはできるだけ早い段階、つまり `memory_limiter` の直後、`batch` プロセッサーの前に配置します。設定は以下のようになります。
+
+ ```yaml
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - filter/health # Filters data based on rules
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file/traces
+ ```
+
+この構成により、ヘルスチェック関連のスパン (`/_healthz`) がパイプラインの早い段階で除外され、テレメトリーデータ内の不要なノイズが削減されます。
+
+{{% /notice %}}
+
+**[otelbin.io](https://www.otelbin.io/)** を使用してエージェントの設定を検証してください。参考までに、パイプラインの `traces:` セクションは以下のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(filter
fa:fa-microchip
health):::processor
+ PRO5(batch
fa:fa-microchip):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2( file
fa:fa-upload
traces):::exporter
+ %% Links
+ subID1:::sub-traces
+ subgraph " "
+ subgraph subID1["`**Traces**`"]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO4
+ PRO4 --> PRO3
+ PRO3 --> PRO5
+ PRO5 --> EXP1
+ PRO5 --> EXP2
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-2-test-filter.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-2-test-filter.md
new file mode 100644
index 0000000000..aeaa11d583
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/5-2-test-filter.md
@@ -0,0 +1,128 @@
+---
+title: 5.2 Test Filter Processor
+linkTitle: 5.2 Test Filter Processor
+weight: 2
+---
+
+設定をテストするには、`"/_healthz"` という名前のスパンを含むトレースデータを生成する必要があります。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway を起動する**: **Gateway terminal** ウィンドウで `gateway` を起動します。
+
+```bash
+../otelcol --config ./gateway.yaml
+```
+
+**Agent を起動する**: **Agent terminal** ウィンドウで `agent` を起動します。
+
+```bash
+../otelcol --config ./agent.yaml
+```
+
+**Loadgen を起動する**: **Spans terminal** ウィンドウで、ベースのスパンと併せて `healthz` スパンも送信するフラグを付けて `loadgen` を実行します。
+
+```bash
+../loadgen -health -count 5
+```
+
+**`agent.out` を確認する**: `jq` を使って、`agent` が受信したスパンの名前を確認します。
+
+{{% tabs %}}
+{{% tab title="Check spans in agent.out" %}}
+
+```bash
+jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./agent.out
+```
+
+{{% /tab %}}
+{{% tab title="Example output" %}}
+
+```text
+"Span 1 found with name /movie-validator"
+"Span 2 found with name /_healthz"
+"Span 3 found with name /movie-validator"
+"Span 4 found with name /_healthz"
+"Span 5 found with name /movie-validator"
+"Span 6 found with name /_healthz"
+"Span 7 found with name /movie-validator"
+"Span 8 found with name /_healthz"
+"Span 9 found with name /movie-validator"
+"Span 10 found with name /_healthz"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**Gateway のデバッグ出力を確認する**: `jq` を使って、`gateway` が受信したスパンの名前を確認します。
+
+{{% tabs %}}
+{{% tab title="Check spans in gateway-traces.out" %}}
+
+```bash { title="Check spans in gateway-traces.out" }
+jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./gateway-traces.out
+```
+
+{{% /tab %}}
+{{% tab title="Example output" %}}
+
+`gateway-metrics.out` ファイルには `/_healthz` という名前のスパンは含まれません。
+
+```text
+"Span 1 found with name /movie-validator"
+"Span 2 found with name /movie-validator"
+"Span 3 found with name /movie-validator"
+"Span 4 found with name /movie-validator"
+"Span 5 found with name /movie-validator"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% /notice %}}
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+
+`Filter` プロセッサを使用する際は、入力データの形式を必ず把握し、設定を十分にテストしてください。誤ったデータが破棄されるリスクを下げるために、原則として **可能な限り具体的な設定** を使用してください。
+
+この設定をさらに拡張して、別の属性、タグ、その他の条件に基づいてスパンをフィルタリングすることで、OpenTelemetry Collector を観測ニーズに合わせてよりカスタマイズしやすく、効率的に運用できます。
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、`agent` と `gateway` のプロセスを停止します。
+
+{{% /notice %}}
+
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/_index.md
new file mode 100644
index 0000000000..c0ad94ae5d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/5-dropping-spans/_index.md
@@ -0,0 +1,30 @@
+---
+title: 5. スパンの削除
+linkTitle: 5. スパンの削除
+time: 10 minutes
+weight: 7
+---
+
+このセクションでは、[**Filter Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/filterprocessor/README.md) を使用して、特定の条件に基づいてスパンを選択的に削除する方法について説明します。
+
+具体的には、スパン名に基づいてトレースを削除します。これは、ヘルスチェックや内部通信トレースなどの不要なスパンを除外するためによく使用されます。今回の例では、ヘルスチェックリクエストに関連付けられることが多く、通常は非常に「**ノイジー**」であるスパン名 `"/_healthz"` を除外します。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- `[WORKSHOP]` ディレクトリ内に、`5-dropping-spans` という新しいサブディレクトリを作成します。
+- 次に、`4-resilience` ディレクトリから `*.yaml` を `5-dropping-spans` にコピーします。
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `[WORKSHOP]/5-dropping-spans` ディレクトリに変更してください。**
+
+更新後のディレクトリ構造は以下のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /notice %}}
+
+次に、**filter processor** とそれぞれのパイプラインを設定します。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-1-configuration.md
new file mode 100644
index 0000000000..442e76389f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-1-configuration.md
@@ -0,0 +1,126 @@
+---
+title: 6.1 Configuration
+linkTitle: 6.1 Configuration
+weight: 1
+---
+
+このステップでは、`agent.yaml` を変更して `attributes` プロセッサーと `redaction` プロセッサーを追加します。これらのプロセッサーは、スパン属性内の機密データがログ出力やエクスポートされる前に適切に処理されるようにするために役立ちます。
+
+これまでに、コンソールに表示されるスパン属性の一部に個人情報や機密データが含まれていることに気付いたかもしれません。次は、これらの情報を効果的にフィルタリングおよび編集（redact）するために必要なプロセッサーを設定します。
+
+```text
+
+Attributes:
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.account_password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ {"kind": "exporter", "data_type": "traces", "name": "debug"}
+```
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Agent terminal** ウィンドウに切り替え、エディタで `agent.yaml` ファイルを開きます。テレメトリデータのセキュリティとプライバシーを強化するために、Attributes Processor と Redaction Processor の 2 つのプロセッサーを追加します。
+
+**`attributes` プロセッサーの追加**: [**Attributes Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor) を使用すると、スパン属性（タグ）の値を更新、削除、ハッシュ化することで変更できます。これは、エクスポートされる前に機密情報を難読化する際に特に有用です。
+
+このステップでは、以下を行います:
+
+1. `user.phone_number` 属性を静的な値 `("UNKNOWN NUMBER")` に **Update** します。
+2. `user.email` 属性を **Hash** 化して、元のメールアドレスが露出しないようにします。
+3. `user.password` 属性を **Delete** して、スパンから完全に削除します。
+
+```yaml
+ attributes/update:
+ actions: # Actions
+ - key: user.phone_number # Target key
+ action: update # Update action
+ value: "UNKNOWN NUMBER" # New value
+ - key: user.email # Target key
+ action: hash # Hash the email value
+ - key: user.password # Target key
+ action: delete # Delete the password
+ ```
+
+**`redaction` プロセッサーの追加**: [**The Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor) は、クレジットカード番号やその他の個人を特定できる情報（PII）など、定義済みのパターンに基づいてスパン属性内の機密データを検出して編集（redact）します。
+
+このステップでは、以下のように設定します:
+
+- `allow_all_keys: true` を設定して、すべての属性が処理されるようにします（`false` に設定した場合、明示的に許可されたキーのみが保持されます）。
+
+- `blocked_values` に正規表現を定義して、**Visa** および **MasterCard** のクレジットカード番号を検出して編集（redact）します。
+
+- `summary: debug` オプションは、デバッグ目的で編集（redaction）処理に関する詳細情報をログに記録します。
+
+```yaml
+ redaction/redact:
+ allow_all_keys: true # If false, only allowed keys will be retained
+ blocked_values: # List of regex patterns to block
+ - '\b4[0-9]{3}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # Visa
+ - '\b5[1-5][0-9]{2}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # MasterCard
+ summary: debug # Show debug details about redaction
+```
+
+**`traces` パイプラインの更新**: 両方のプロセッサーを `traces` パイプラインに統合します。最初は redaction プロセッサーをコメントアウトしておくようにしてください（後の別の演習で有効化します）:
+
+> [!NOTE]
+> この演習では `redaction/redact` プロセッサーをコメントアウトしたままにしておいてください。今後の演習で有効化します。
+
+```yaml
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - attributes/update # Update, hash, and remove attributes
+ #- redaction/redact # Redact sensitive fields using regex
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file
+ - otlphttp
+```
+
+{{% /notice %}}
+
+**[otelbin.io](https://www.otelbin.io/)** を使用してエージェント設定を検証します。参考までに、パイプラインの `traces:` セクションは次のようになります:
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRML(memory_limiter
fa:fa-microchip):::processor
+ PRRD(resourcedetection
fa:fa-microchip):::processor
+ PRRS(resource
fa:fa-microchip
add_mode):::processor
+ PRBA(batch
fa:fa-microchip):::processor
+ PRUP(attributes
fa:fa-microchip
update):::processor
+ EXP1(otlphttp
fa:fa-upload):::exporter
+ EXP2( debug
fa:fa-upload):::exporter
+ EXP3(file
fa:fa-upload):::exporter
+
+ %% Links
+ subID1:::sub-traces
+ subgraph " "
+ subgraph subID1["`**Traces**`"]
+ direction LR
+ REC1 --> PRML
+ PRML --> PRUP
+ PRUP --> PRRD
+ PRRD --> PRRS
+ PRRS --> PRBA
+ PRBA --> EXP2
+ PRBA --> EXP3
+ PRBA --> EXP1
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-2-test-delete-tag.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-2-test-delete-tag.md
new file mode 100644
index 0000000000..70e420754d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-2-test-delete-tag.md
@@ -0,0 +1,92 @@
+---
+title: 6.2 Test Attribute Processor
+linkTitle: 6.2 Test Attribute Processor
+weight: 2
+---
+
+この演習では、`agent` がスパンデータをエクスポートする前に、`user.account_password` を **削除** し、`user.phone_number` の **属性** を **更新** し、`user.email` を **ハッシュ化** します。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway を起動する**: **Gateway terminal** ウィンドウで `gateway` を起動します。
+
+```bash
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動する**: **Agent terminal** ウィンドウで `agent` を起動します。
+
+```bash
+../otelcol --config=agent.yaml
+```
+
+**Load Generator を起動する**: **Spans terminal** ウィンドウで `loadgen` を起動します。
+
+```bash
+../loadgen -count 1
+```
+
+**デバッグ出力を確認する**: `agent` と `gateway` の両方のデバッグ出力で、`user.account_password` が削除され、`user.phone_number` と `user.email` の両方が更新されていることを確認します。
+
+{{% tabs %}}
+{{% tab title="New Debug Output" %}}
+
+ ```text
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(UNKNOWN NUMBER)
+ -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287)
+ -> payment.amount: Double(51.71)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ ```
+
+{{% /tab %}}
+{{% tab title="Original Debug Output" %}}
+
+ ```text
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ -> payment.amount: Double(95.22)
+ ```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**ファイル出力を確認する**: `jq` を使用して、`gateway-taces.out` 内で `user.account_password` が削除され、`user.phone_number` と `user.email` が更新されていることを検証します。
+
+{{% tabs %}}
+{{% tab title="Validate attribute changes" %}}
+
+```bash
+jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.password" or .key == "user.phone_number" or .key == "user.email") | {key: .key, value: .value.stringValue}' ./gateway-traces.out
+```
+
+{{% /tabs %}}
+{{% tab title="Output" %}}
+
+`user.account_password` が削除され、`user.phone_number` と `user.email` が更新されていることを確認します。
+
+```json
+{
+ "key": "user.phone_number",
+ "value": "UNKNOWN NUMBER"
+}
+{
+ "key": "user.email",
+ "value": "62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287"
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> 各ターミナルで `Ctrl-C` を押して、`agent` と `gateway` のプロセスを停止してください。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-3-test-redaction.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-3-test-redaction.md
new file mode 100644
index 0000000000..71b2bdd14d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/6-3-test-redaction.md
@@ -0,0 +1,141 @@
+---
+title: 6.3 Redaction Processor のテスト
+linkTitle: 6.3 Redaction Processor のテスト
+weight: 3
+---
+
+`redaction` プロセッサーは、テレメトリーデータから **許可** または **削除** する属性と値を、きめ細かく制御できます。
+
+この演習では、`agent` がエクスポートする前のスパンデータに含まれる `user.visa` と `user.mastercard` の **値** を **マスク** します。
+{{% notice title="演習" style="green" icon="running" %}}
+
+**ターミナルの準備**: `*.out` ファイルを削除し、画面をクリアします。
+
+**Gateway の起動**: **Gateway terminal** ウィンドウで `gateway` を起動します。
+
+```bash
+../otelcol --config=gateway.yaml
+```
+
+**`redaction/redact` プロセッサーの有効化**: **Agent terminal** ウィンドウで `agent.yaml` を編集し、前の演習で挿入した `#` を削除します。
+
+```yaml
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - attributes/update # Update, hash, and remove attributes
+ - redaction/redact # Redact sensitive fields using regex
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file
+ - otlphttp
+```
+
+**Agent の起動**: **Agent terminal** ウィンドウで `agent` を起動します。
+
+```bash
+../otelcol --config=agent.yaml
+```
+
+**Load Generator の起動**: **Spans terminal** ウィンドウで `loadgen` を起動します。
+
+```bash
+../loadgen -count 1
+```
+
+**デバッグ出力の確認**: `agent` と `gateway` の両方で、`user.visa` と `user.mastercard` の値が更新されていることを確認します。`user.amex` 属性の値は、`blocked_values` に一致する正規表現パターンが追加されていないため、マスクされていない点に注目してください。
+
+{{% tabs %}}
+{{% tab title="新しいデバッグ出力" %}}
+
+ ```text
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(UNKNOWN NUMBER)
+ -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287)
+ -> payment.amount: Double(69.71)
+ -> user.visa: Str(****)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(****)
+ -> redaction.masked.keys: Str(user.mastercard,user.visa)
+ -> redaction.masked.count: Int(2)
+ ```
+
+{{% /tab %}}
+{{% tab title="元のデバッグ出力" %}}
+
+ ```text
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ -> payment.amount: Double(65.54)
+ ```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% notice note %}}
+redaction プロセッサーに `summary:debug` を含めると、どの一致キー値がマスクされたかの概要情報と、マスクされた値の件数がデバッグ出力に含まれます。
+
+```text
+ -> redaction.masked.keys: Str(user.mastercard,user.visa)
+ -> redaction.masked.count: Int(2)
+ ```
+
+{{% /notice %}}
+
+**ファイル出力の確認**: `jq` を使用して、`gateway-traces.out` 内で `user.visa` と `user.mastercard` が更新されていることを確認します。
+
+{{% tabs %}}
+{{% tab title="属性変更の検証" %}}
+
+```bash
+jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.visa" or .key == "user.mastercard" or .key == "user.amex") | {key: .key, value: .value.stringValue}' ./gateway-traces.out
+```
+
+{{% /tabs %}}
+{{% tab title="出力" %}}
+
+`user.amex` は、`blocked_values` に一致する正規表現パターンが追加されていないため、マスクされていない点に注目してください。
+
+```json
+{
+ "key": "user.visa",
+ "value": "****"
+}
+{
+ "key": "user.amex",
+ "value": "3782 822463 10005"
+}
+{
+ "key": "user.mastercard",
+ "value": "****"
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+これらは、機密データを保護するために `attributes` プロセッサーと `redaction` プロセッサーをどのように構成できるかを示すほんの一例です。
+
+> [!IMPORTANT]
+> `agent` と `gateway` のプロセスは、それぞれのターミナルで `Ctrl-C` を押して停止してください。
+
+{{% /notice %}}
+
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/_index.md
new file mode 100644
index 0000000000..25922f1289
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/6-sensitive-data/_index.md
@@ -0,0 +1,31 @@
+---
+title: 6. 機密データの編集
+linkTitle: 6. 機密データ
+time: 10 minutes
+weight: 8
+---
+
+このセクションでは、OpenTelemetry Collector を設定して特定のタグを削除し、テレメトリー span から機密データを編集する方法を学びます。これは、クレジットカード番号、個人情報、またはその他のセキュリティ関連の詳細など、処理またはエクスポートされる前に匿名化する必要がある機密情報を保護するために重要です。
+
+OpenTelemetry Collector の主要なプロセッサーの設定方法を説明します。具体的には次のものです。
+
+- **[Attributes Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/attributesprocessor/README.md)**: 特定の span 属性を変更または削除します。
+- [**Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/redactionprocessor/README.md): 機密データが保存または送信される前にサニタイズされることを保証します。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- `[WORKSHOP]` ディレクトリ内に、`6-sensitive-data` という名前の新しいサブディレクトリを作成します。
+- 次に、`5-dropping-spans` ディレクトリから `*.yaml` を `6-sensitive-data` にコピーします。
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `[WORKSHOP]/6-sensitive-data` ディレクトリに変更してください。**
+
+更新後のディレクトリ構造は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-1-configuration.md
new file mode 100644
index 0000000000..7cf5729ebf
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-1-configuration.md
@@ -0,0 +1,118 @@
+---
+title: 7.1 Configuration
+linkTitle: 7.1 Configuration
+weight: 1
+---
+
+{{% notice title="Exercise" style="green" icon="running" %}}
+**`transform` プロセッサーの追加**: **Agent terminal** ウィンドウに切り替えて `agent.yaml` を編集し、以下の `transform` プロセッサーを追加します。
+
+```yaml
+ transform/logs: # Processor Type/Name
+ log_statements: # Log Processing Statements
+ - context: resource # Log Context
+ statements: # List of attribute keys to keep
+ - keep_keys(attributes, ["com.splunk.sourcetype", "host.name", "otelcol.service.mode"])
+```
+
+`-context: resource` キーを使用することで、ログの `resourceLog` 属性を対象としています。
+
+この設定により、関連するリソース属性（`com.splunk.sourcetype`、`host.name`、`otelcol.service.mode`）のみが保持され、ログの効率が向上し、不要なメタデータが削減されます。
+
+**ログ重大度マッピングのためのコンテキストブロックの追加**: ログレコードの `severity_text` および `severity_number` フィールドを適切に設定するために、`log_statements` 内に `log` コンテキストブロックを追加します。この設定では、ログ本文から `level` 値を抽出し、`severity_text` にマッピングして、ログレベルに対応する `severity_number` を割り当てます。
+
+```yaml
+ - context: log # Log Context
+ statements: # Transform Statements Array
+ - set(cache, ParseJSON(body)) where IsMatch(body, "^\\{") # Parse JSON log body into a cache object
+ - flatten(cache, "") # Flatten nested JSON structure
+ - merge_maps(attributes, cache, "upsert") # Merge cache into attributes, updating existing keys
+ - set(severity_text, attributes["level"]) # Set severity_text from the "level" attribute
+ - set(severity_number, 1) where severity_text == "TRACE" # Map severity_text to severity_number
+ - set(severity_number, 5) where severity_text == "DEBUG"
+ - set(severity_number, 9) where severity_text == "INFO"
+ - set(severity_number, 13) where severity_text == "WARN"
+ - set(severity_number, 17) where severity_text == "ERROR"
+ - set(severity_number, 21) where severity_text == "FATAL"
+```
+
+`merge_maps` 関数は、2つのマップ（ディクショナリ）を1つに結合するために使用されます。ここでは、`cache` オブジェクト（ログ本文から解析された JSON データを含む）を `attributes` マップにマージします。
+
+- **パラメータ**:
+ - `attributes`: データがマージされる対象のマップです。
+ - `cache`: 解析された JSON データを含むソースマップです。
+ - `"upsert"`: このモードでは、`attributes` マップ内にキーが既に存在する場合、その値が `cache` の値で更新されます。キーが存在しない場合は挿入されます。
+
+このステップは非常に重要で、ログ本文に含まれるすべての関連フィールド（例: `level`、`message` など）が `attributes` マップに追加され、後続の処理やエクスポートで利用可能になることを保証します。
+
+**主な変換処理のまとめ**:
+
+- **JSON の解析**: ログ本文から構造化データを抽出します。
+- **JSON のフラット化**: ネストされた JSON オブジェクトをフラットな構造に変換します。
+- **属性のマージ**: 抽出したデータをログの属性に統合します。
+- **重大度テキストのマッピング**: ログの level 属性から severity_text を割り当てます。
+- **重大度番号の割り当て**: 重大度レベルを標準化された数値に変換します。
+
+最終的に、`resource` 用と `log` 用の2つのコンテキストブロックを含む **1つの** `transform` プロセッサーが構成されている必要があります。
+
+この設定により、ログの重大度が正しく抽出、標準化、構造化され、効率的な処理が可能になります。
+
+{{% notice title="Tip" style="primary" icon="lightbulb" %}}
+すべての JSON フィールドをトップレベル属性にマッピングするこの方法は、**OTTL のテストとデバッグ** にのみ使用してください。本番環境のシナリオでは高カーディナリティを引き起こします。
+{{% /notice %}}
+
+**`logs` パイプラインの更新**: `transform/logs:` プロセッサーを `logs:` パイプラインに追加します。
+
+```yaml
+ logs:
+ receivers:
+ - otlp
+ - filelog/quotes
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - transform/logs # Transform logs processor
+ - batch
+ exporters:
+ - debug
+ - otlphttp
+```
+
+{{% /notice %}}
+
+[**https://otelbin.io**](https://otelbin.io/) を使用してエージェント設定を検証します。参考までに、パイプラインの `logs:` セクションは以下のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ REC2(filelog
fa:fa-download
quotes):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resourcedetection
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(transform
fa:fa-microchip
logs):::processor
+ PRO5(batch
fa:fa-microchip):::processor
+ EXP1(otlphttp
fa:fa-upload):::exporter
+ EXP2( debug
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-logs
+ subgraph " "
+ subgraph subID1[**Logs**]
+ direction LR
+ REC1 --> PRO1
+ REC2 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> PRO4
+ PRO4 --> PRO5
+ PRO5 --> EXP2
+ PRO5 --> EXP1
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-2-setup.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-2-setup.md
new file mode 100644
index 0000000000..9467dd65e9
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-2-setup.md
@@ -0,0 +1,32 @@
+---
+title: 7.2 Setup Environment
+linkTitle: 7.2 Setup Environment
+weight: 2
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway を起動**: **Gateway terminal** で以下を実行します。
+
+```bash { title="Start the Gateway" }
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動**: **Agent terminal** で以下を実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**Load Generator を起動**: **Logs terminal** ウィンドウを開き、`loadgen` を実行します。
+
+> [!IMPORTANT]
+> ログを JSON 形式で構造化するため、スクリプト起動時に `-json` フラグを必ず指定してください。
+
+```bash { title="Log Generator" }
+../loadgen -logs -json -count 5
+```
+
+`loadgen` は `./quotes.log` に JSON 形式で 5 行のログを書き込みます。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-3-test-transform.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-3-test-transform.md
new file mode 100644
index 0000000000..d9350d7daa
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/7-3-test-transform.md
@@ -0,0 +1,129 @@
+---
+title: 7.3 Transform Processor のテスト
+linkTitle: 7.3 Transform Processor のテスト
+weight: 3
+---
+
+このテストでは、`agent` によってエクスポートされる前に、ログのリソース属性から `com.splunk/source` および `os.type` メタデータが**削除**されていることを検証します。さらに、このテストでは以下の点を確認します。
+
+1. ログ本文がパースされ、severity 情報が抽出されること。
+ - `LogRecord` に `SeverityText` および `SeverityNumber` が設定されること。
+2. ログ本文の JSON フィールドがログの `attributes` に昇格されること。
+
+これにより、エクスポート前に、メタデータの適切なフィルタリング、severity マッピング、構造化ログのエンリッチメントが正しく行われていることが確認できます。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**デバッグ出力を確認します**: `agent` と `gateway` の両方で、`com.splunk/source` と `os.type` が削除されていることを確認します。
+
+{{% tabs %}}
+{{% tab title="新しいデバッグ出力" %}}
+
+ ```text
+Resource attributes:
+ -> com.splunk.sourcetype: Str(quotes)
+ -> host.name: Str(workshop-instance)
+ -> otelcol.service.mode: Str(agent)
+ ```
+
+{{% /tab %}}
+{{% tab title="元のデバッグ出力" %}}
+
+ ```text
+Resource attributes:
+ -> com.splunk.source: Str(./quotes.log)
+ -> com.splunk.sourcetype: Str(quotes)
+ -> host.name: Str(workshop-instance)
+ -> os.type: Str(linux)
+ -> otelcol.service.mode: Str(agent)
+ ```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+`agent` と `gateway` の両方で、`LogRecord` 内の `SeverityText` と `SeverityNumber` がログ本文の severity `level` に基づいて定義されていることを確認します。また、本文の JSON フィールドが、トップレベルのログ `Attributes` としてアクセスできることを確認します。
+
+{{% tabs %}}
+{{% tab title="新しいデバッグ出力" %}}
+
+```text
+
+SeverityText: WARN
+SeverityNumber: Warn(13)
+Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"})
+Attributes:
+ -> log.file.path: Str(quotes.log)
+ -> level: Str(WARN)
+ -> message: Str(Your focus determines your reality.)
+ -> movie: Str(SW)
+ -> timestamp: Str(2025-03-07 11:17:26)
+
+```
+
+{{% /tab %}}
+{{% tab title="元のデバッグ出力" %}}
+
+```text
+
+SeverityText:
+SeverityNumber: Unspecified(0)
+Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"})
+Attributes:
+ -> log.file.path: Str(quotes.log)
+
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**ファイル出力を確認します**: 新しい `gateway-logs.out` ファイルで、データが変換されていることを検証します。
+
+{{% tabs %}}
+{{% tab title="jq クエリ" %}}
+
+```bash
+jq '[.resourceLogs[].scopeLogs[].logRecords[] | {severityText, severityNumber, body: .body.stringValue}]' gateway-logs.out
+```
+
+{{% /tabs %}}
+{{% tab title="出力例" %}}
+
+```json
+[
+ {
+ "severityText": "DEBUG",
+ "severityNumber": 5,
+ "body": "{\"level\":\"DEBUG\",\"message\":\"All we have to decide is what to do with the time that is given us.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ },
+ {
+ "severityText": "WARN",
+ "severityNumber": 13,
+ "body": "{\"level\":\"WARN\",\"message\":\"The Force will be with you. Always.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ },
+ {
+ "severityText": "ERROR",
+ "severityNumber": 17,
+ "body": "{\"level\":\"ERROR\",\"message\":\"One does not simply walk into Mordor.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ },
+ {
+ "severityText": "DEBUG",
+ "severityNumber": 5,
+ "body": "{\"level\":\"DEBUG\",\"message\":\"Do or do not, there is no try.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ }
+]
+[
+ {
+ "severityText": "ERROR",
+ "severityNumber": 17,
+ "body": "{\"level\":\"ERROR\",\"message\":\"There is some good in this world, and it's worth fighting for.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ }
+]
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、`agent` と `gateway` のプロセスを停止します。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/_index.md
new file mode 100644
index 0000000000..23d6470843
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/7-transform-data/_index.md
@@ -0,0 +1,44 @@
+---
+title: 7. Transform Data
+linkTitle: 7. Transform Data
+time: 10 minutes
+weight: 9
+---
+
+[**Transform Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md) は、ログ、メトリクス、トレースといったテレメトリーデータがパイプラインを流れる際に、それらを変更できるプロセッサーです。**OpenTelemetry Transformation Language (OTTL)** を使用することで、アプリケーションコードに手を加えることなく、データのフィルタリング、エンリッチ、変換をリアルタイムに実行できます。
+
+この演習では、`agent.yaml` を更新して、以下の処理を行う **Transform Processor** を追加します。
+
+- ログのリソース属性を **Filter** します。
+- JSON 形式の構造化ログデータを属性に **Parse** します。
+- ログメッセージの本文に基づいてログの重要度レベルを **Set** します。
+
+これまでのログでは、`SeverityText` や `SeverityNumber` といったフィールドが未定義になっていることに気づいたかもしれません。これは `filelog` レシーバーで一般的な動作です。しかし、重要度はログ本文の中に埋め込まれています。
+
+```text
+
+SeverityText:
+SeverityNumber: Unspecified(0)
+Body: Str(2025-01-31 15:49:29 [WARN] - Do or do not, there is no try.)
+
+```
+
+ログには、JSON でエンコードされた構造化データがログ本文の中に含まれていることがよくあります。これらのフィールドを属性として抽出することで、インデックス作成、フィルタリング、クエリの効率が向上します。下流のシステムで JSON を手動でパースする代わりに、OTTL を使えばテレメトリーパイプラインのレベルで自動的に変換できます。
+
+{{% notice title="Exercise" style="green" icon="running" %}}
+
+- `[WORKSHOP]` ディレクトリ内に、`7-transform-data` という名前の新しいサブディレクトリを作成します。
+- 次に、`6-sensitve-data` ディレクトリから `*.yaml` を `7-transform-data` にコピーします。
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `[WORKSHOP]/7-transform-data` ディレクトリに変更してください。**
+
+更新後のディレクトリ構成は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-1-connector.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-1-connector.md
new file mode 100644
index 0000000000..1c38c8934d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-1-connector.md
@@ -0,0 +1,42 @@
+---
+title: 8.1 Routing Connector の設定
+linkTitle: 8.1 Routing 設定
+weight: 1
+---
+
+この演習では、`gateway.yaml` ファイルで **Routing Connector** を設定します。この設定により、`gateway` は送信されたスパンの `deployment.environment` 属性に基づいてトレースをルーティングできるようになります。これを実装することで、属性に応じてトレースを異なる方法で処理できます。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+OpenTelemetry の設定ファイルでは、`connectors` は receivers や processors と同様に、専用のセクションを持ちます。
+
+**`routing` コネクターを追加します**:
+**Gateway ターミナル** ウィンドウで `gateway.yaml` を編集し、`#connectors:` セクションのコメントを解除します。次に、`connectors:` セクションの下に以下を追加します:
+
+```yaml
+connectors:
+ routing:
+ default_pipelines: [traces/standard] # Default pipeline if no rule matches
+ error_mode: ignore # Ignore errors in routing
+ table: # Define routing rules
+ # Routes spans to a target pipeline if the resourceSpan attribute matches the rule
+ - statement: route() where attributes["deployment.environment"] == "security-applications"
+ pipelines: [traces/security] # Target pipeline
+```
+
+上記のルールはトレースに適用されますが、このアプローチは `metrics` や `logs` にも適用でき、`resourceMetrics` または `resourceLogs` の属性に基づいてルーティングできます。
+
+**`file:` exporter を設定します**: `routing` コネクターは、ルーティング先として個別のターゲットを必要とします。`exporters:` セクションに、`file/traces/security` と `file/traces/standard` の 2 つの file exporter を追加し、データが正しく送信されるようにします。
+
+```yaml
+ file/traces/standard: # Exporter for regular traces
+ path: "./gateway-traces-standard.out" # Path for saving trace data
+ append: false # Overwrite the file each time
+ file/traces/security: # Exporter for security traces
+ path: "./gateway-traces-security.out" # Path for saving trace data
+ append: false # Overwrite the file each time
+```
+
+{{% /notice %}}
+
+`routing` の設定が完了したら、次のステップではこれらのルーティングルールを適用するために `pipelines` を設定します。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-2-pipelines.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-2-pipelines.md
new file mode 100644
index 0000000000..df59e4a25d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-2-pipelines.md
@@ -0,0 +1,110 @@
+---
+title: 8.2 パイプラインの設定
+linkTitle: 8.2 パイプライン設定
+weight: 2
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**`traces` パイプラインを更新してルーティングを使用するようにします**:
+
+1. `routing` を有効にするには、元の `traces:` パイプラインを更新し、`routing` を唯一のエクスポーターとして使用します。これにより、すべてのスパンデータが評価のためにルーティングコネクターを通じて送信されるようになります。
+2. すべてのプロセッサーを削除し、空の配列(`[]`)に置き換えます。これらは現在 `traces/standard` および `traces/security` パイプラインで定義されています。
+
+ ```yaml
+ pipelines:
+ traces: # Original traces pipeline
+ receivers:
+ - otlp # OTLP Receiver
+ processors: []
+ exporters:
+ - routing # Routing Connector
+ ```
+
+**`standard` および `security` の両方の traces パイプラインを追加します**:
+
+1. **Security パイプラインを構成する**: このパイプラインは、`security` のルーティングルールに一致するすべてのスパンを処理します。
+これは `routing` をレシーバーとして使用します。既存の `traces:` パイプラインの下に配置してください:
+
+ ```yaml
+ traces/security: # New Security Traces/Spans Pipeline
+ receivers:
+ - routing # Receive data from the routing connector
+ processors:
+ - memory_limiter # Memory Limiter Processor
+ - resource/add_mode # Adds collector mode metadata
+ - batch
+ exporters:
+ - debug # Debug Exporter
+ - file/traces/security # File Exporter for spans matching rule
+ ```
+
+2. **Standard パイプラインを追加する**: このパイプラインは、ルーティングルールに一致しないすべてのスパンを処理します。
+このパイプラインも `routing` をレシーバーとして使用します。`traces/security` の下に追加してください:
+
+ ```yaml
+ traces/standard: # Default pipeline for unmatched spans
+ receivers:
+ - routing # Receive data from the routing connector
+ processors:
+ - memory_limiter # Memory Limiter Processor
+ - resource/add_mode # Adds collector mode metadata
+ - batch
+ exporters:
+ - debug # Debug exporter
+ - file/traces/standard # File exporter for unmatched spans
+ ```
+
+{{% /notice %}}
+
+**[otelbin.io](https://www.otelbin.io/)** を使用してエージェントの構成を検証します。参考までに、パイプラインの `traces:` セクションは次のようになります:
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(memory_limiter
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(resource
fa:fa-microchip
add_mode):::processor
+ PRO5(batch
fa:fa-microchip):::processor
+ PRO6(batch
fa:fa-microchip):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2( file
fa:fa-upload
traces):::exporter
+ EXP3( debug
fa:fa-upload):::exporter
+ EXP4( file
fa:fa-upload
traces):::exporter
+ ROUTE1( routing
fa:fa-route):::con-export
+ ROUTE2( routing
fa:fa-route):::con-receive
+ ROUTE3( routing
fa:fa-route):::con-receive
+ %% Links
+ subID1:::sub-traces
+ subID2:::sub-traces
+ subID3:::sub-traces
+ subgraph " "
+ direction LR
+ subgraph subID1["`**Traces**`"]
+ REC1 --> ROUTE1
+ end
+ subgraph subID2[**Traces/standard**]
+ ROUTE1 --> ROUTE2
+ ROUTE2 --> PRO1
+ PRO1 --> PRO3
+ PRO3 --> PRO5
+ PRO5 --> EXP1
+ PRO5 --> EXP2
+ end
+ subgraph subID3[**Traces/security**]
+ ROUTE1 --> ROUTE3
+ ROUTE3 --> PRO2
+ PRO2 --> PRO4
+ PRO4 --> PRO6
+ PRO6 --> EXP3
+ PRO6 --> EXP4
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-3-test-routing.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-3-test-routing.md
new file mode 100644
index 0000000000..3e5572cd06
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/8-3-test-routing.md
@@ -0,0 +1,78 @@
+---
+title: 8.3 Routing Connector のテスト
+linkTitle: 8.3 Routing Connector のテスト
+weight: 3
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+このセクションでは、**Gateway** に設定した `routing` ルールをテストします。期待される結果は、`loadgen` によって生成された `span` が `gateway-traces-security.out` ファイルに送信されることです。
+
+**Gateway を起動する**: **Gateway ターミナル**ウィンドウで `gateway` を起動します。
+
+```bash
+../otelcol --config gateway.yaml
+```
+
+**Agent を起動する**: **Agent ターミナル**ウィンドウで `agent` を起動します。
+
+```bash
+../otelcol --config agent.yaml
+```
+
+**通常の Span を送信する**: **Spans ターミナル**ウィンドウで、`loadgen` を使用して通常の span を送信します。
+
+```bash
+../loadgen -count 1
+```
+
+`agent` と `gateway` の両方がデバッグ情報を表示します。gateway は新しい `gateway-traces-standard.out` ファイルも生成します。これは通常の span の指定された送信先となったためです。
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+`gateway-traces-standard.out` を確認すると、`loadgen` によって送信された `span` が含まれています。また、空の `gateway-traces-security.out` ファイルも表示されます。これは、ルーティング設定によって、まだ一致する span が処理されていなくても、出力ファイルが即座に作成されるためです。
+{{% /notice %}}
+
+**Security Span を送信する**: **Spans ターミナル**ウィンドウで、`security` フラグを使用して security span を送信します。
+
+```bash
+../loadgen -security -count 1
+```
+
+再度、`agent` と `gateway` の両方が、送信した span を含むデバッグ情報を表示するはずです。今度は、`gateway` が `gateway-traces-security.out` ファイルに 1 行書き込みます。このファイルは、`deployment.environment` リソース属性が `"security-applications"` に一致する span 用に指定されています。
+`gateway-traces-standard.out` は変更されないはずです。
+
+{{% tabs %}}
+{{% tab title="リソース属性の一致を検証する" %}}
+
+```bash
+jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | {spanId: .spanId, deploymentEnvironment: ($resource.resource.attributes[] | select(.key == "deployment.environment") | .value.stringValue)}' gateway-traces-security.out
+```
+
+{{% /tabs %}}
+{{% tab title="出力" %}}
+
+```json
+{"spanId":"cb799e92e26d5782","deploymentEnvironment":"security-applications"}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+このシナリオは複数回繰り返すことができ、各トレースは対応する出力ファイルに書き込まれます。
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、`agent` と `gateway` のプロセスを停止します。
+
+{{% /notice %}}
+
+## まとめ
+
+このセクションでは、異なる span を送信してそれぞれの送信先を検証することで、gateway の routing connector のテストに成功しました。
+
+- **通常の span** は `gateway-traces-standard.out` に正しくルーティングされ、`deployment.environment` 属性に一致しない span がデフォルトのパイプラインに従うことを確認しました。
+
+- **セキュリティ関連の span** は `gateway-traces-security.out` にルーティングされ、`"deployment.environment": "security-applications"` に基づくルーティングルールが期待どおりに機能することを示しました。
+
+出力ファイルを確認することで、OpenTelemetry Collector が *span 属性を正しく評価し、適切な送信先にルーティングする* ことを確認しました。これにより、ルーティングルールがさまざまなユースケース向けにテレメトリーデータを効果的に分離・転送できることが検証されました。
+
+このアプローチを拡張して、追加のルーティングルールを定義することで、さまざまな属性に基づいて span、メトリクス、ログをさらに分類できます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/_index.md
new file mode 100644
index 0000000000..892321a103
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/8-routing-data/_index.md
@@ -0,0 +1,28 @@
+---
+title: 8. データのルーティング
+linkTitle: 8. データのルーティング
+time: 10 minutes
+weight: 10
+---
+
+OpenTelemetry の [**Routing Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/routingconnector) は、特定の条件に基づいてデータ（`traces`、`metrics`、`logs`）を異なるパイプラインに振り分けることができる強力な機能です。これは、テレメトリーデータのサブセットに対して異なる処理やエクスポートのロジックを適用したい場合に特に有用です。
+
+例えば、*production* のデータを 1 つの Exporter に送信し、*test* や *development* のデータを別の Exporter に送る、といった使い方ができます。同様に、サービス名、環境、Span 名などの属性に基づいて特定の Span をルーティングし、カスタムの処理やストレージのロジックを適用することも可能です。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- `[WORKSHOP]` ディレクトリ内に `8-routing-data` という新しいサブディレクトリを作成します。
+- 次に、`7-transform-data` ディレクトリから `*.yaml` を `8-routing-data` にコピーします。
+- **すべての** ターミナルウィンドウを `[WORKSHOP]/8-routing-data` ディレクトリに変更します。
+
+更新後のディレクトリ構造は以下のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /notice %}}
+
+次に、Routing Connector とそれぞれのパイプラインを設定します。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-1-count-test.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-1-count-test.md
new file mode 100644
index 0000000000..0cf35f81f4
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-1-count-test.md
@@ -0,0 +1,94 @@
+---
+title: 9.1 Count Connector のテスト
+linkTitle: 9.1 Count Connector のテスト
+weight: 1
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway を起動する**:
+**Gateway terminal** ウィンドウで `[WORKSHOP]/9-sum-count` ディレクトリに移動して、次のコマンドを実行します。
+
+```bash { title="Start the Gateway" }
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動する**:
+**Agent terminal** ウィンドウで `[WORKSHOP]/9-sum-count` ディレクトリに移動して、次のコマンドを実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**Loadgen で 12 行のログを送信する**:
+**Spans terminal** ウィンドウで `[WORKSHOP]/9-sum-count` ディレクトリに移動します。
+12 行のログを送信します。これらは 2 つのインターバルで読み込まれます。次の `loadgen` コマンドで実行します。
+
+```bash { title="Loadgen" }
+../loadgen -logs -json -count 12
+```
+
+`agent` と `gateway` の両方が、データを処理していることを示すデバッグ情報を表示します。loadgen が完了するまで待機してください。
+
+**メトリクスが生成されたことを確認する**
+ログが処理されると、**Agent** はメトリクスを生成し、**Gateway** に転送します。**Gateway** はそれを `gateway-metrics.out` に書き込みます。
+
+メトリクス `logs.full.count`、`logs.sw.count`、`logs.lotr.count`、`logs.error.count` が出力に含まれているかを確認するため、次の **jq** クエリを実行します。
+
+{{% tabs %}}
+{{% tab title="jq query command" %}}
+
+```bash
+jq '.resourceMetrics[].scopeMetrics[].metrics[]
+ | select(.name == "logs.full.count" or .name == "logs.sw.count" or .name == "logs.lotr.count" or .name == "logs.error.count")
+ | {name: .name, value: (.sum.dataPoints[0].asInt // "-")}' gateway-metrics.out
+```
+
+{{% /tab %}}
+{{% tab title="jq example output" %}}
+
+```json
+{
+ "name": "logs.sw.count",
+ "value": "2"
+}
+{
+ "name": "logs.lotr.count",
+ "value": "2"
+}
+{
+ "name": "logs.full.count",
+ "value": "4"
+}
+{
+ "name": "logs.error.count",
+ "value": "2"
+}
+{
+ "name": "logs.error.count",
+ "value": "1"
+}
+{
+ "name": "logs.sw.count",
+ "value": "2"
+}
+{
+ "name": "logs.lotr.count",
+ "value": "6"
+}
+{
+ "name": "logs.full.count",
+ "value": "8"
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+補足: 通常 `logs.full.count` は `logs.sw.count` + `logs.lotr.count` と等しくなりますが、`logs.error.count` はランダムな数値になります。
+{{% /notice %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、`agent` と `gateway` のプロセスを停止してください。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-2-sum.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-2-sum.md
new file mode 100644
index 0000000000..b1dff9c4e9
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-2-sum.md
@@ -0,0 +1,158 @@
+---
+title: Sum Connectorでメトリクスを作成する
+linkTitle: 9.2 Sum Connector
+time: 10 minutes
+weight: 2
+---
+
+このセクションでは、[**Sum Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/sumconnector) がスパンから値を抽出し、メトリクスに変換する方法を見ていきます。
+
+具体的には、ベーススパンに含まれるクレジットカードの請求額を使用し、Sum Connectorを活用して請求合計額をメトリクスとして取得します。
+
+このコネクターは、スパン、スパンイベント、メトリクス、データポイント、ログレコードから属性値を収集（**sum**）するために使用できます。各値を個別に取得し、メトリクスに変換して送信します。ただし、これらのメトリクスとその属性を使用して計算やさらなる処理を行うのは、**バックエンド** の役割です。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Agentターミナル** ウィンドウに切り替えて、エディタで `agent.yaml` ファイルを開いてください。
+
+- **Sum Connectorを追加する**
+設定の connectors セクションに Sum Connector を追加し、メトリクスカウンターを定義します:
+
+```yaml
+ sum:
+ spans:
+ user.card-charge:
+ source_attribute: payment.amount
+ conditions:
+ - attributes["payment.amount"] != "NULL"
+ attributes:
+ - key: user.name
+
+```
+
+{{% /notice %}}
+
+上記の例では、スパンの `payment.amount` 属性をチェックしています。有効な値が含まれている場合、**Sum** コネクターは `user.card-charge` というメトリクスを生成し、`user.name` を属性として含めます。これにより、バックエンドは請求サイクルなどの長期間にわたるユーザーの請求合計額を追跡し、表示できるようになります。
+
+以下のパイプライン設定では、コネクターのエクスポーターを traces セクションに追加し、コネクターのレシーバーを metrics セクションに追加しています。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- **パイプラインで Count Connector を設定する**
+
+```yaml
+ pipelines:
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - attributes/update # Update, hash, and remove attributes
+ - redaction/redact # Redact sensitive fields using regex
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file
+ - otlphttp
+ - sum # Sum connector which aggregates payment.amount from spans and sends to metrics pipeline
+ metrics:
+ receivers:
+ - sum # Receives metrics from the sum exporter in the traces pipeline
+ - count # Receives count metric from logs count exporter in logs pipeline.
+ - otlp
+ #- hostmetrics # Host Metrics Receiver
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - otlphttp
+ logs:
+ receivers:
+ - otlp
+ - filelog/quotes
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - transform/logs # Transform logs processor
+ - batch
+ exporters:
+ - count # Count Connector that exports count as a metric to metrics pipeline.
+ - debug
+ - otlphttp
+```
+
+- **[otelbin.io](https://www.otelbin.io/)** を使用して、agentの設定を **検証** してください。参考までに、パイプラインの `traces` および `metrics:` セクションは以下のようになります:
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1(otlp
fa:fa-download
):::receiver
+ REC3(otlp
fa:fa-download
):::receiver
+ PRO1(memory_limiter
fa:fa-microchip
):::processor
+ PRO2(memory_limiter
fa:fa-microchip
):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(resource
fa:fa-microchip
add_mode):::processor
+ PRO5(batch
fa:fa-microchip
):::processor
+ PRO6(batch
fa:fa-microchip
):::processor
+ PRO7(resourcedetection
fa:fa-microchip
):::processor
+ PRO8(resourcedetection
fa:fa-microchip
):::processor
+
+ PROA(attributes
fa:fa-microchip
redact):::processor
+ PROB(redaction
fa:fa-microchip
update):::processor
+ EXP1( debug
fa:fa-upload
):::exporter
+ EXP2( file
fa:fa-upload
):::exporter
+ EXP3( debug
fa:fa-upload
):::exporter
+ EXP4( otlphttp
fa:fa-upload
):::exporter
+ EXP5( otlphttp
fa:fa-upload
):::exporter
+ ROUTE1( sum
fa:fa-route
):::con-export
+ ROUTE2( count
fa:fa-route
):::con-receive
+ ROUTE3( sum
fa:fa-route
):::con-receive
+
+ %% Links
+ subID1:::sub-traces
+ subID2:::sub-metrics
+ subgraph " "
+ direction LR
+ subgraph subID1["`**Traces**`"]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PROA
+ PROA --> PROB
+ PROB --> PRO7
+ PRO7 --> PRO3
+ PRO3 --> PRO5
+ PRO5 --> EXP1
+ PRO5 --> EXP2
+ PRO5 --> EXP5
+ PRO5 --> ROUTE1
+ end
+
+ subgraph subID2["`**Metrics**`"]
+ direction LR
+ ROUTE1 --> ROUTE3
+ ROUTE3 --> PRO2
+ ROUTE2 --> PRO2
+ REC3 --> PRO2
+ PRO2 --> PRO8
+ PRO8 --> PRO4
+ PRO4 --> PRO6
+ PRO6 --> EXP3
+ PRO6 --> EXP4
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
+classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-3-sum-test.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-3-sum-test.md
new file mode 100644
index 0000000000..af47509273
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/9-3-sum-test.md
@@ -0,0 +1,67 @@
+---
+title: 9.3 Count Connector のテスト
+linkTitle: 9.3 Sum Connector のテスト
+weight: 3
+---
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**Gateway を起動する**:
+**Gateway ターミナル** ウィンドウで `[WORKSHOP]/9-sum-count` ディレクトリに移動し、以下を実行します。
+
+```bash { title="Start the Gateway" }
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動する**:
+**Agent ターミナル** ウィンドウで `[WORKSHOP]/9-sum-count` ディレクトリに移動し、以下を実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**Loadgen を起動する**:
+**Spans ターミナル** ウィンドウで `[WORKSHOP]/9-sum-count` ディレクトリに移動します。以下の `loadgen` コマンドで 8 個のスパンを送信します。
+
+```bash { title="Loadgen" }
+../loadgen -count 8
+```
+
+`agent` と `gateway` の両方がデバッグ情報を表示し、データを処理していることが確認できます。loadgen が完了するまで待ちます。
+
+**メトリクスを検証する**
+スパンの処理中に、**Agent** はメトリクスを生成して **Gateway** に渡しています。**Gateway** はそれらを `gateway-metrics.out` に書き込んでいます。
+
+メトリクス出力に `user.card-charge` が存在することを確認し、それぞれに `user.name` 属性が付与されていることを検証するために、以下の jq クエリを実行します。
+
+{{% tabs %}}
+{{% tab title="jq query command" %}}
+
+```bash
+
+jq -r '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "user.card-charge") | .sum.dataPoints[] | "\(.attributes[] | select(.key == "user.name").value.stringValue)\t\(.asDouble)"' gateway-metrics.out | while IFS=$'\t' read -r name charge; do
+ printf "%-20s %s\n" "$name" "$charge"
+done
+```
+
+{{% /tab %}}
+{{% tab title="jq example output" %}}
+
+```text
+George Lucas 67.49
+Frodo Baggins 87.14
+Thorin Oakenshield 90.98
+Luke Skywalker 51.37
+Luke Skywalker 65.56
+Thorin Oakenshield 67.5
+Thorin Oakenshield 66.66
+Peter Jackson 94.39
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、`agent` と `gateway` のプロセスを停止してください。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/_index.md
new file mode 100644
index 0000000000..e2e5ee0384
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/9-sum-count/_index.md
@@ -0,0 +1,191 @@
+---
+title: Count Connector でメトリクスを作成する
+linkTitle: 9. Count & Sum Connector
+time: 10 minutes
+weight: 11
+---
+このセクションでは、[**Count Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/countconnector) を使用して、ログから属性値を抽出し、意味のあるメトリクスへ変換する方法を紹介します。
+
+具体的には、Count Connector を使ってログに登場する「Star Wars」と「Lord of the Rings」の引用の数を追跡し、計測可能なデータポイントへ変換します。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- `[WORKSHOP]` ディレクトリ内に、`9-sum-count` という名前の新しいサブディレクトリを作成します。
+- 次に、`8-routing-data` ディレクトリから `*.yaml` を `9-sum-count` にコピーします。
+- **すべての** ターミナルウィンドウを `[WORKSHOP]/9-sum-count` ディレクトリに変更します。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+- **agent.yaml を更新** して、ログを読み取る頻度を変更します。
+`agent.yaml` 内の `filelog/quotes` レシーバーを見つけ、`poll_interval` 属性を追加します。
+
+```yaml
+ filelog/quotes: # Receiver Type/Name
+ poll_interval: 10s # Only read every ten seconds
+```
+
+{{% /notice %}}
+
+遅延を設ける理由は、OpenTelemetry Collector の Count Connector が処理間隔ごとにログをカウントするためです。つまり、データが読み取られるたびに、次の間隔に向けてカウントがゼロにリセットされます。`Filelog reciever` のデフォルト間隔である 200ms では、loadgen が書き込んだすべての行が読み取られ、カウントが 1 になってしまいます。この間隔を設けることで、確実に複数のエントリをカウントできるようになります。
+
+Collector では、以下のように条件を省略することで、各読み取り間隔の累積カウントを保持できます。ただし、より長い期間にわたって追跡できるため、累積カウントの処理はバックエンドに任せるのがベストプラクティスです。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- **Count Connector を追加する**
+
+設定の connectors セクションに Count Connector を含め、使用するメトリクスカウンターを定義します。
+
+```yaml
+connectors:
+ count:
+ logs:
+ logs.full.count:
+ description: "Running count of all logs read in interval"
+ logs.sw.count:
+ description: "StarWarsCount"
+ conditions:
+ - attributes["movie"] == "SW"
+ logs.lotr.count:
+ description: "LOTRCount"
+ conditions:
+ - attributes["movie"] == "LOTR"
+ logs.error.count:
+ description: "ErrorCount"
+ conditions:
+ - attributes["level"] == "ERROR"
+```
+
+- **メトリクスカウンターの説明**
+
+ - `logs.full.count`: 各読み取り間隔で処理されたログの合計数を追跡します。
+ このメトリクスにはフィルタリング条件がないため、システムを通過するすべてのログがカウントに含まれます。
+ - `logs.sw.count`: Star Wars 映画の引用を含むログをカウントします。
+ - `logs.lotr.count`: Lord of the Rings 映画の引用を含むログをカウントします。
+ - `logs.error.count`: 読み取り間隔中に重要度レベルが ERROR のログをカウントすることで、実際のシナリオを表現します。
+
+- **パイプラインで Count Connector を設定する**
+以下のパイプライン設定では、コネクターのエクスポーターは `logs` セクションに、コネクターのレシーバーは `metrics` セクションに追加されます。
+
+```yaml
+ pipelines:
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - attributes/update # Update, hash, and remove attributes
+ - redaction/redact # Redact sensitive fields using regex
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file
+ - otlphttp
+ metrics:
+ receivers:
+ - count # Count Connector that receives count metric from logs count exporter in logs pipeline.
+ - otlp
+ #- hostmetrics # Host Metrics Receiver
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - otlphttp
+ logs:
+ receivers:
+ - otlp
+ - filelog/quotes
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - transform/logs # Transform logs processor
+ - batch
+ exporters:
+ - count # Count Connector that exports count as a metric to metrics pipeline.
+ - debug
+ - otlphttp
+```
+
+{{% /notice %}}
+
+ここではログを属性に基づいてカウントしています。ログデータが属性ではなくログ本文に格納されている場合は、パイプラインで `Transform` プロセッサーを使用して key/value のペアを抽出し、属性として追加する必要があります。
+
+このワークショップでは、`07-transform` セクションですでに `merge_maps(attributes, cache, "upsert")` を追加しています。これにより、処理対象のすべての関連データがログ属性に含まれるようになっています。
+
+属性を作成するフィールドを選択する際は注意が必要です。すべてのフィールドを無差別に追加することは、本番環境にとって一般的に望ましくありません。不要なデータの混乱を避けるために、本当に必要なフィールドのみを選択してください。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+- **[otelbin.io](https://www.otelbin.io/)** を使用してエージェント設定を **検証** します。参考までに、パイプラインの `logs` および `metrics:` セクションは以下のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1(otlp
fa:fa-download):::receiver
+ REC2(filelog
fa:fa-download
quotes):::receiver
+ REC3(otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(memory_limiter
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(resource
fa:fa-microchip
add_mode):::processor
+ PRO5(batch
fa:fa-microchip):::processor
+ PRO6(batch
fa:fa-microchip):::processor
+ PRO7(resourcedetection
fa:fa-microchip):::processor
+ PRO8(resourcedetection
fa:fa-microchip):::processor
+ PRO9(transfrom
fa:fa-microchip
logs):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2( otlphttp
fa:fa-upload):::exporter
+ EXP3( debug
fa:fa-upload):::exporter
+ EXP4( otlphttp
fa:fa-upload):::exporter
+ ROUTE1( count
fa:fa-route):::con-export
+ ROUTE2( count
fa:fa-route):::con-receive
+
+ %% Links
+ subID1:::sub-logs
+ subID2:::sub-metrics
+ subgraph " "
+ direction LR
+ subgraph subID1[**Logs**]
+ direction LR
+ REC1 --> PRO1
+ REC2 --> PRO1
+ PRO1 --> PRO7
+ PRO7 --> PRO3
+ PRO3 --> PRO9
+ PRO9 --> PRO5
+ PRO5 --> ROUTE1
+ PRO5 --> EXP1
+ PRO5 --> EXP2
+ end
+
+ subgraph subID2["`**Metrics**`"]
+ direction LR
+ ROUTE1 --> ROUTE2
+ ROUTE2 --> PRO2
+ REC3 --> PRO2
+ PRO2 --> PRO8
+ PRO8 --> PRO4
+ PRO4 --> PRO6
+ PRO6 --> EXP3
+ PRO6 --> EXP4
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
+classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/99-end/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/99-end/_index.md
new file mode 100644
index 0000000000..65378fdc6f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/99-end/_index.md
@@ -0,0 +1,7 @@
+---
+title: まとめ
+linkTitle: 10. まとめ
+weight: 12
+---
+
+
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/_index.md
new file mode 100644
index 0000000000..2c1b884d07
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/_index.md
@@ -0,0 +1,38 @@
+---
+title: Advanced Collector Configuration
+description: ゼロから OpenTelemetry Collector の設定を行う方法を実践し、いくつかの高度な設定シナリオを学習します。
+weight: 2
+archetype: chapter
+authors: ["Robert Castley", "Charity Anderson", "Pieter Hagen", "Geoff Higginbottom"]
+time: 90 minutes
+hidden: true
+---
+
+このワークショップの目的は、OpenTelemetry Collector の設定ファイルの作成と編集に自信を持っていただくことです。最小限の `agent.yaml` ファイルから始めて、段階的に高度で実践的なシナリオに対応できるよう拡張していきます。
+
+このワークショップで重点を置くのは、サードパーティベンダーのバックエンドに送信するのではなく、テレメトリデータをローカルに保存するように OpenTelemetry Collector を設定する方法です。このアプローチはデバッグやトラブルシューティングを簡素化するだけでなく、本番システムへのデータ送信を避けたいテストや開発環境にも最適です。
+
+このワークショップを最大限に活用するために、以下の知識が必要です。
+
+- OpenTelemetry Collector とその設定ファイル構造に関する基本的な理解
+- YAML ファイルの編集に関する習熟
+
+このワークショップのすべての内容はローカルで実行できるように設計されており、ハンズオン形式でアクセスしやすい学習体験を提供します。それでは早速、構築を始めましょう。
+
+## Workshop Overview
+
+このワークショップでは、以下のトピックを扱います。
+
+- **エージェントをローカルにセットアップする**: メタデータを追加し、debug および file exporter を導入します。
+- **gateway を設定する**: エージェントから gateway へトラフィックをルーティングします。
+- **FileLog receiver を設定する**: さまざまなログファイルからログデータを収集します。
+- **エージェントのレジリエンス向上**: フォールトトレランスのための基本設定を行います。
+- **processor を設定する**:
+ - 特定の span (例: ヘルスチェック) を除外してノイズをフィルタリングします。
+ - 不要なタグを削除し、機密データを処理します。
+ - エクスポート前のパイプラインで OTTL (OpenTelemetry Transformation Language) を使用してデータを変換します。
+- **Connector を設定する**:
+ - 受信した値に基づいてデータを異なるエンドポイントへルーティングします。
+ - ログと span のデータを metric に変換します。
+
+このワークショップを終える頃には、さまざまな実践的ユースケースに対応した OpenTelemetry Collector の設定方法に習熟しているでしょう。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/prerequisites.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/prerequisites.md
new file mode 100644
index 0000000000..45d49a0c5e
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector-old/prerequisites.md
@@ -0,0 +1,79 @@
+---
+title: 事前準備
+weight: 2.1
+archetype: chapter
+time: 90 minutes
+---
+
+### 前提条件
+
+- `vi`、`vim`、`nano`、またはお好みのテキストエディタを使った YAML ファイルの編集に習熟していること。
+- サポートされる環境:
+ - Splunk Workshop Instance（推奨）
+ - Apple Mac (Apple Silicon)。`jq` のインストールが必要です - [**https://jqlang.org/download/**](https://jqlang.org/download/)
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**ワークショップ用ディレクトリの作成**: ご自身の環境で新しいディレクトリ（例: `advanced-otel-workshop`）を作成します。本ワークショップでは以降、このディレクトリを `[WORKSHOP]` と表記します。
+
+**ワークショップ用バイナリのダウンロード**: `[WORKSHOP]` ディレクトリに移動し、OpenTelemetry Collector とロードジェネレーターのバイナリをダウンロードします。
+
+{{% tabs %}}
+{{% tab title="Splunk Workshop Instance" %}}
+
+```bash
+curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v{{< otel-version >}}/otelcol_linux_amd64 -o otelcol && \
+curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-linux-amd64 -o loadgen
+```
+
+**ファイルパーミッションの更新**: ダウンロードが完了したら、両方のファイルに実行権限を付与するためにパーミッションを更新します。
+
+```bash
+chmod +x otelcol loadgen && \
+./otelcol -v && \
+./loadgen --help
+```
+
+{{% /tab %}}
+{{% tab title="Apple Silicon" %}}
+
+```bash
+curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v{{< otel-version >}}/otelcol_darwin_arm64 -o otelcol && \
+curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-darwin-arm64 -o loadgen
+```
+
+{{% notice style="warning" title="macOS ユーザーの方へ" icon="desktop" %}}
+macOS でバイナリを実行する前に、ダウンロードしたファイルに macOS が付与する quarantine 属性を削除する必要があります。この手順により、制限なくバイナリを実行できるようになります。
+
+ターミナルで次のコマンドを実行してください。
+
+```bash { title="Remove Quarantine Attribute"}
+xattr -dr com.apple.quarantine otelcol && \
+xattr -dr com.apple.quarantine loadgen
+```
+
+**ファイルパーミッションの更新**: ダウンロードが完了したら、両方のファイルに実行権限を付与するためにパーミッションを更新します。
+
+```bash
+chmod +x otelcol loadgen && \
+./otelcol -v && \
+./loadgen --help
+```
+
+{{% /notice %}}
+
+{{% /tab %}}
+{{% /tabs %}}
+
+```text { title="Initial Directory Structure" }
+[WORKSHOP]
+├── otelcol # OpenTelemetry Collector binary
+└── loadgen # Load Generator binary
+```
+
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md
new file mode 100644
index 0000000000..5c35e510eb
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md
@@ -0,0 +1,61 @@
+---
+title: 1.1 Gateway 設定の確認
+linkTitle: 1.1 Gateway 設定
+weight: 1
+---
+
+**OpenTelemetry Gateway** は、テレメトリデータの受信、処理、エクスポートを行う中央ハブとして機能します。テレメトリのソース（アプリケーションやサービスなど）と、Splunk Observability Cloud のような可観測性バックエンドとの間に配置されます。
+
+テレメトリトラフィックを集中管理することで、Gateway はデータのフィルタリング、エンリッチメント、変換、複数の宛先へのルーティングといった高度な機能を実現します。テレメトリ処理をオフロードすることで個々のサービスへの負荷を軽減し、分散システム全体で一貫した標準化されたデータを保証します。
+
+これにより、特に複雑なマルチサービス環境において、可観測性パイプラインの管理、スケール、分析が容易になります。
+
+{{% exercise title="Gateway 設定の確認" %}}
+
+2 つ目のターミナルウィンドウを開くか作成し、**Gateway** という名前を付けます。最初の演習ディレクトリ `[WORKSHOP]/1-agent-gateway` に移動し、`gateway.yaml` ファイルの内容を確認します。
+
+このファイルは、**Gateway** モードでデプロイされる OpenTelemetry Collector の中核構造を示しています。
+
+{{% /exercise %}}
+
+## Gateway 設定の理解
+
+このワークショップで OpenTelemetry Collector を **Gateway** モードとして構成する `gateway.yaml` ファイルを見ていきましょう。この **Gateway** は **Agent** からテレメトリを受信し、検査または転送のために処理してエクスポートする役割を担います。
+
+* **OTLP Receiver（カスタムポート）**
+
+ ```yaml
+ receivers:
+ otlp:
+ protocols:
+ http:
+ endpoint: "0.0.0.0:5318"
+ ```
+
+ ポート `5318` は **Agent** 設定の `otlphttp` エクスポーターと一致しており、**Agent** が送信するすべてのテレメトリデータが **Gateway** で受け付けられるようにしています。
+
+ > [!NOTE]
+ > このようにポートを分離することで、競合を回避し、Agent と Gateway の役割を明確に保ちます。
+
+* **File Exporter**
+
+ **Gateway** は 3 つの File Exporter を使用して、テレメトリデータをローカルファイルに出力します。これらのエクスポーターは次のように定義されています。
+
+ ```yaml
+ exporters: # List of exporters
+ debug: # Debug exporter
+ verbosity: detailed # Enable detailed debug output
+ file/traces: # Exporter Type/Name
+ path: "./gateway-traces.out" # Path for OTLP JSON output for traces
+ append: false # Overwrite the file each time
+ file/metrics: # Exporter Type/Name
+ path: "./gateway-metrics.out" # Path for OTLP JSON output for metrics
+ append: false # Overwrite the file each time
+ file/logs: # Exporter Type/Name
+ path: "./gateway-logs.out" # Path for OTLP JSON output for logs
+ append: false # Overwrite the file each time
+ ```
+
+ 各エクスポーターは、特定のシグナルタイプを対応するファイルに書き出します。
+
+ これらのファイルは Gateway の起動時に作成され、Agent がデータを送信するにつれて実際のテレメトリで満たされていきます。これらのファイルをリアルタイムで監視することで、パイプラインを流れるテレメトリの動きを観察できます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md
new file mode 100644
index 0000000000..b6fc28bff4
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md
@@ -0,0 +1,99 @@
+---
+title: 1.2 設定の検証とテスト
+linkTitle: 1.2 設定の検証とテスト
+weight: 3
+---
+
+これで **Gateway** と **Agent** を起動できるようになりました。**Agent** は起動時に自動で **Host Metrics** を送信するように設定されています。これにより、**Agent** から **Gateway** へデータが正しくルーティングされていることを検証します。
+
+{{% exercise title="Gateway と Agent の起動" %}}
+
+**Gateway**: **Gateway terminal** ウィンドウで、次のコマンドを実行して **Gateway** を起動します。
+
+```bash {title="Start the Gateway"}
+../otelcol --config=gateway.yaml
+```
+
+すべてが正しく構成されている場合、コレクターが起動し、出力に `Everything is ready. Begin running and processing data.` と表示されます。次のような出力になります。
+
+```text
+2025-06-09T09:22:11.944+0100 info service@v0.126.0/service.go:289 Everything is ready. Begin running and processing data. {"resource": {}}
+```
+
+**Gateway** が稼働すると、ポート `5318` で受信データを待ち受け、受信したデータを次のファイルにエクスポートします。
+
+* `gateway-traces.out`
+* `gateway-metrics.out`
+* `gateway-logs.out`
+
+**Agent の起動**: **Agent terminal** ウィンドウで、agent 構成を使って agent を起動します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**CPU メトリクスの確認**:
+
+1. **Agent** が起動すると、ただちに **CPU** メトリクスの送信を開始することを確認します。
+2. **Agent** と **Gateway** の両方が、デバッグ出力にこの動作を表示します。出力は次のスニペットのようになります。
+
+```text
+
+NumberDataPoints #31
+Data point attributes:
+ -> cpu: Str(cpu3)
+ -> state: Str(wait)
+StartTimestamp: 2025-07-07 16:49:42 +0000 UTC
+Timestamp: 2025-07-09 09:36:21.190226459 +0000 UTC
+Value: 77.380000
+ {"resource": {}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "metrics"}
+```
+
+この段階では、**Agent** は1時間に1回、または再起動のたびに **CPU** メトリクスを収集し続け、それを gateway へ送信します。**Gateway** はこれらのメトリクスを処理し、`gateway-metrics.out` という名前のファイルにエクスポートします。このファイルは、パイプラインサービスの一部としてエクスポートされたメトリクスを保存します。
+
+**データが Gateway に到達したことの確認**: CPU メトリクス、特に `cpu0` のメトリクスが gateway に正しく届いていることを確認するために、`jq` コマンドで `gateway-metrics.out` ファイルを確認します。
+
+次のコマンドは、`system.cpu.time` メトリクスをフィルタリングして抽出し、`cpu0` に焦点を当てます。メトリクスの state（例: `user`、`system`、`idle`、`interrupt`）と、対応する値が表示されます。
+
+3つ目のターミナルウィンドウを開くか作成し、**Tests** という名前を付けてください。**Tests terminal** で次のコマンドを実行して、`system.cpu.time` メトリクスを確認します。
+
+{{% tabs %}}
+{{% tab title="Check CPU Metrics" %}}
+
+```bash
+jq '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "system.cpu.time") | .sum.dataPoints[] | select(.attributes[0].value.stringValue == "cpu0") | {cpu: .attributes[0].value.stringValue, state: .attributes[1].value.stringValue, value: .asDouble}' gateway-metrics.out
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```json
+{
+ "cpu": "cpu0",
+ "state": "user",
+ "value": 123407.02
+}
+{
+ "cpu": "cpu0",
+ "state": "system",
+ "value": 64866.6
+}
+{
+ "cpu": "cpu0",
+ "state": "idle",
+ "value": 216427.87
+}
+{
+ "cpu": "cpu0",
+ "state": "interrupt",
+ "value": 0
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止してください。
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md
new file mode 100644
index 0000000000..a10ed177aa
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md
@@ -0,0 +1,96 @@
+---
+title: 1.3 Agent から Gateway へトレースを送信する
+linkTitle: 1.3 トレースの送信
+weight: 4
+hidden: true
+draft: true
+---
+
+{{% exercise title="テストトレースを送信する" %}}
+
+**テストトレースの送信**:
+
+1. **Agent** と **Gateway** が動作していることを確認します。
+2. **Loadgen ターミナル** ウィンドウで以下のコマンドを実行して 5 つのスパンを送信し、**Agent** と **Gateway** のデバッグログの出力を確認します。
+
+{{% tabs %}}
+{{% tab title="Start the Load Generator" %}}
+
+```bash
+../loadgen -count 5
+```
+
+{{% /tab %}}
+{{% tab title="Agent/Gateway Debug Output" %}}
+
+```text
+2025-03-06T11:49:00.456Z info Traces {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces", "resource spans": 1, "spans": 1}
+2025-03-06T11:49:00.456Z info ResourceSpans #0
+Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
+Resource attributes:
+ -> service.name: Str(cinema-service)
+ -> deployment.environment: Str(production)
+ -> host.name: Str(workshop-instance)
+ -> os.type: Str(linux)
+ -> otelcol.service.mode: Str(agent)
+ScopeSpans #0
+ScopeSpans SchemaURL:
+InstrumentationScope cinema.library 1.0.0
+InstrumentationScope attributes:
+ -> fintest.scope.attribute: Str(Starwars, LOTR)
+Span #0
+ Trace ID : 97fb4e5b13400b5689e3306da7cff077
+ Parent ID :
+ ID : 413358465e5b4f15
+ Name : /movie-validator
+ Kind : Server
+ Start time : 2025-03-06 11:49:00.431915 +0000 UTC
+ End time : 2025-03-06 11:49:01.431915 +0000 UTC
+ Status code : Ok
+ Status message : Success
+Attributes:
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ -> payment.amount: Double(87.01)
+ {"otelcol.component.id": "debug", "otelcol.component.kind": "Exporter", "otelcol.signal": "traces"}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**Gateway がスパンを処理したことを確認する**: Gateway は受信したスパンを処理すると、`gateway-traces.out` という名前のファイルにトレースデータを書き込みます。スパンが正常に処理されたかどうかは、このファイルを確認することで検証できます。
+
+**Tests ターミナル** で `jq` コマンドを使用して、各スパンの `spanId` やファイル内の位置などの主要な情報を抽出して表示します。また、**Hostmetrics Receiver** がスパンに追加した属性も抽出できます。
+
+{{% tabs %}}
+{{% tab title="Inspect the Gateway Trace File" %}}
+
+```bash
+jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | "Span \(input_line_number) found with spanId \(.spanId), hostname \($resource.resource.attributes[] | select(.key == "host.name") | .value.stringValue), os \($resource.resource.attributes[] | select(.key == "os.type") | .value.stringValue)"' ./gateway-traces.out
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+"Span 1 found with spanId d71fe6316276f97d, hostname workshop-instance, os linux"
+"Span 2 found with spanId e8d19489232f8c2a, hostname workshop-instance, os linux"
+"Span 3 found with spanId 9dfaf22857a6bd05, hostname workshop-instance, os linux"
+"Span 4 found with spanId c7f544a4b5fef5fc, hostname workshop-instance, os linux"
+"Span 5 found with spanId 30bb49261315969d, hostname workshop-instance, os linux"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md
new file mode 100644
index 0000000000..cea7996de3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md
@@ -0,0 +1,152 @@
+---
+title: 1.4 ログの送信
+linkTitle: 1.4 ログの送信
+weight: 5
+hidden: true
+draft: true
+---
+
+{{% exercise title="パイプラインを通してログを送信する" %}}
+
+**ログのロードジェネレーターを起動する:** **Loadgen terminal** ウィンドウで、次のコマンドを実行して `loadgen` を起動します。
+
+```bash
+../loadgen -logs
+```
+
+`quotes.log` からのログデータの連続ストリームが、**Agent** と **Gateway** のデバッグログに出力されます。
+
+```text { title="Agent/Gateway Debug Output" }
+Timestamp: 1970-01-01 00:00:00 +0000 UTC
+SeverityText:
+SeverityNumber: Unspecified(0)
+Body: Str(2025-03-06 15:18:32 [ERROR] - There is some good in this world, and it's worth fighting for. LOTR)
+Attributes:
+ -> log.file.path: Str(quotes.log)
+Trace ID:
+Span ID:
+Flags: 0
+LogRecord #1
+```
+
+**`loadgen` を停止する**: **Loadgen terminal** ウィンドウで、`Ctrl-C` を使って `loadgen` を停止します。
+
+**Gateway の確認**: **Gateway** が `./gateway-logs.out` ファイルを書き出しているかを確認します。
+
+この時点で、ディレクトリ構造は次のようになっています。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.out
+├── agent.yaml
+├── gateway-logs.out # Output from the logs pipeline
+├── gateway-metrics.out # Output from the metrics pipeline
+├── gateway-traces.out # Output from the traces pipeline
+├── gateway.yaml
+└── quotes.log # File containing Random log lines
+```
+
+**ログ行の確認**: `gateway-logs.out` 内のログ行を、以下のスニペットと比較してください。ログのエントリに、これまでメトリクスやトレースのデータで見てきたものと同じ属性が含まれていることを確認します。
+
+{{% tabs %}}
+{{% tab title="cat /gateway-logs.out" %}}
+
+```json
+{"resourceLogs":[{"resource":{"attributes":[{"key":"com.splunk.source","value":{"stringValue":"./quotes.log"}},{"key":"com.splunk.sourcetype","value":{"stringValue":"quotes"}},{"key":"host.name","value":{"stringValue":"workshop-instance"}},{"key":"os.type","value":{"stringValue":"linux"}},{"key":"otelcol.service.mode","value":{"stringValue":"gateway"}}]},"scopeLogs":[{"scope":{},"logRecords":[{"observedTimeUnixNano":"1741274312475540000","body":{"stringValue":"2025-03-06 15:18:32 [DEBUG] - All we have to decide is what to do with the time that is given us. LOTR"},"attributes":[{"key":"log.file.path","value":{"stringValue":"quotes.log"}}],"traceId":"","spanId":""},{"observedTimeUnixNano":"1741274312475560000","body":{"stringValue":"2025-03-06 15:18:32 [DEBUG] - Your focus determines your reality. SW"},"attributes":[{"key":"log.file.path","value":{"stringValue":"quotes.log"}}],"traceId":"","spanId":""}]}],"schemaUrl":"https://opentelemetry.io/schemas/1.6.1"}]}
+```
+
+{{% /tab %}}
+{{% tab title="cat ./gateway-logs.out | jq" %}}
+
+```json
+{
+ "resourceLogs": [
+ {
+ "resource": {
+ "attributes": [
+ {
+ "key": "com.splunk.source",
+ "value": {
+ "stringValue": "./quotes.log"
+ }
+ },
+ {
+ "key": "com.splunk.sourcetype",
+ "value": {
+ "stringValue": "quotes"
+ }
+ },
+ {
+ "key": "host.name",
+ "value": {
+ "stringValue": "workshop-instance"
+ }
+ },
+ {
+ "key": "os.type",
+ "value": {
+ "stringValue": "linux"
+ }
+ },
+ {
+ "key": "otelcol.service.mode",
+ "value": {
+ "stringValue": "gateway"
+ }
+ }
+ ]
+ },
+ "scopeLogs": [
+ {
+ "scope": {},
+ "logRecords": [
+ {
+ "observedTimeUnixNano": "1741274312475540000",
+ "body": {
+ "stringValue": "2025-03-06 15:18:32 [DEBUG] - All we have to decide is what to do with the time that is given us. LOTR"
+ },
+ "attributes": [
+ {
+ "key": "log.file.path",
+ "value": {
+ "stringValue": "quotes.log"
+ }
+ }
+ ],
+ "traceId": "",
+ "spanId": ""
+ },
+ {
+ "observedTimeUnixNano": "1741274312475560000",
+ "body": {
+ "stringValue": "2025-03-06 15:18:32 [DEBUG] - Your focus determines your reality. SW"
+ },
+ "attributes": [
+ {
+ "key": "log.file.path",
+ "value": {
+ "stringValue": "quotes.log"
+ }
+ }
+ ],
+ "traceId": "",
+ "spanId": ""
+ }
+ ]
+ }
+ ],
+ "schemaUrl": "https://opentelemetry.io/schemas/1.6.1"
+ }
+ ]
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+すべてのログ行に `"traceId":""` と `"spanId":""` の空のプレースホルダーが含まれていることに気づいたかもしれません。FileLog receiver は、これらのフィールドがログ行にまだ存在していない場合にのみ、これらのフィールドを補完します。たとえば、OpenTelemetry のインストルメンテーションライブラリで計装されたアプリケーションから生成されたログ行であれば、これらのフィールドはすでに含まれており、上書きされることはありません。
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止してください。
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md
new file mode 100644
index 0000000000..84f577dec1
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md
@@ -0,0 +1,98 @@
+---
+title: 1. エージェント設定の確認
+linkTitle: 1. エージェント設定
+time: 15 minutes
+weight: 3
+---
+ようこそ！ このセクションでは、**Agent** と **Gateway** の両方を含む完全に動作する OpenTelemetry のセットアップから始めます。
+
+まずは設定ファイルをざっと確認し、全体の構造を把握するとともに、テレメトリパイプラインを制御する重要なセクションに注目していきます。
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+ワークショップ全体を通して、複数のターミナルウィンドウを使用します。整理しやすくするために、各ターミナルに固有の名前や色を付けてください。これにより、演習中にターミナルを簡単に識別して切り替えられるようになります。
+
+これらのターミナルは、**Agent**、**Gateway**、**Loadgen**、**Test** と呼びます。
+{{% /notice %}}
+
+{{% exercise title="エージェントファイルの確認" %}}
+
+1. 最初のターミナルウィンドウを作成し、**Agent** という名前を付けます。最初の演習用のディレクトリ `[WORKSHOP]/1-agent-gateway` に移動し、必要なファイルが生成されていることを確認します。
+
+ ```bash
+ cd 1-agent-gateway
+ ls -l
+ ```
+
+2. ディレクトリ内に以下のファイルが表示されるはずです。表示されない場合は、**Pre-requisites** セクションの説明に従って `setup-workshop.sh` スクリプトを再実行してください。
+
+ ```text { title="Directory Structure" }
+ .
+ ├── agent.yaml
+ └── gateway.yaml
+ ```
+
+{{% /exercise %}}
+
+## エージェント設定の理解
+
+このワークショップで使用する `agent.yaml` ファイルの主要なコンポーネントを確認しましょう。メトリクス、トレース、ログをサポートするためにいくつかの重要な追加を行っています。
+
+### Receivers
+
+`receivers` セクションでは、**Agent** がどのようにテレメトリデータを取り込むかを定義します。このセットアップでは、3 種類のレシーバーが設定されています。
+
+* **Host Metrics Receiver**
+
+ ```yaml
+ hostmetrics: # Host Metrics Receiver
+ collection_interval: 3600s # Collection Interval (1hr)
+ scrapers:
+ cpu: # CPU Scraper
+ ```
+
+ ローカルシステムから 1 時間ごとに CPU 使用率を収集します。これを使ってメトリクスデータのサンプルを生成します。
+
+* **OTLP Receiver (HTTP protocol)**
+
+ ```yaml
+ otlp: # OTLP Receiver
+ protocols:
+ http: # Configure HTTP protocol
+ endpoint: "0.0.0.0:4318" # Endpoint to bind to
+ ```
+
+ エージェントがポート `4318` で HTTP 経由でメトリクス、トレース、ログを受信できるようにします。これは今後の演習でコレクターにデータを送信するために使用されます。
+
+* **FileLog Receiver**
+
+ ```yaml
+ filelog/quotes: # Receiver Type/Name
+ include: ./quotes.log # The file to read log data from
+ include_file_path: true # Include file path in the log data
+ include_file_name: false # Exclude file name from the log data
+ resource: # Add custom resource attributes
+ com.splunk.source: ./quotes.log # Source of the log data
+ com.splunk.sourcetype: quotes # Source type of the log data
+ ```
+
+ エージェントがローカルのログファイル (`quotes.log`) を tail し、`source` や `sourceType` などのメタデータで強化された構造化ログイベントに変換できるようにします。
+
+### Exporters
+
+* **Debug Exporter**
+
+ ```yaml
+ debug: # Exporter Type
+ verbosity: detailed # Enabled detailed debug output
+ ```
+
+* **OTLPHTTP Exporter**
+
+ ```yaml
+ otlphttp: # Exporter Type
+ endpoint: "http://localhost:5318" # Gateway OTLP endpoint
+ ```
+
+ `debug` エクスポーターは、ワークショップ中の可視化とデバッグのためにコンソールにデータを送信し、`otlphttp` エクスポーターはすべてのテレメトリをローカルの **Gateway** インスタンスに転送します。
+
+ **この二重エクスポート戦略により、ローカルで生データを確認しながら、下流に送信してさらなる処理とエクスポートを行うことができます。**
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md
new file mode 100644
index 0000000000..e25d7bc794
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md
@@ -0,0 +1,100 @@
+---
+title: 2.1 File Storage の設定
+linkTitle: 2.1 設定
+weight: 1
+---
+
+この演習では、`agent.yaml` ファイルの `extensions:` セクションを更新します。このセクションは OpenTelemetry の設定 YAML の一部であり、OpenTelemetry Collector の動作を拡張または変更するためのオプションコンポーネントを定義します。
+
+これらのコンポーネントはテレメトリーデータを直接処理するわけではありませんが、Collector の機能を強化するための有用な機能やサービスを提供します。
+
+{{% exercise title="Agent に file storage を追加する" %}}
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `2-building-resilience` ディレクトリに移動し、`clear` コマンドを実行してください。**
+
+ディレクトリ構造は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+**`agent.yaml` を更新する**: **Agent ターミナル** ウィンドウで、既存の `health_check` extension の下に `file_storage` extension を追加します。
+
+```yaml
+ file_storage/checkpoint: # Extension Type/Name
+ directory: "./checkpoint-dir" # Define directory
+ create_directory: true # Create directory
+ timeout: 1s # Timeout for file operations
+ compaction: # Compaction settings
+ on_start: true # Start compaction at Collector startup
+ # Define compaction directory
+ directory: "./checkpoint-dir/tmp"
+ max_transaction_size: 65536 # Max. size limit before compaction occurs
+```
+
+**exporter に `file_storage` を追加する**: `otlphttp` exporter を変更してリトライおよびキューイングのメカニズムを設定し、障害が発生した場合にデータを保持して再送できるようにします。`endpoint: "http://localhost:5318"` の下に以下を追加し、インデントが `endpoint` と一致していることを確認してください。
+
+```yaml
+ retry_on_failure:
+ enabled: true # Enable retry on failure
+ sending_queue: #
+ enabled: true # Enable sending queue
+ num_consumers: 10 # No. of consumers
+ queue_size: 10000 # Max. queue size
+ storage: file_storage/checkpoint # File storage extension
+```
+
+**`services` セクションを更新する**: 既存の `extensions:` セクションに `file_storage/checkpoint` extension を追加します。設定は次のようになります。
+
+```yaml
+service:
+ extensions:
+ - health_check
+ - file_storage/checkpoint # Enabled extensions for this collector
+```
+
+**`metrics` パイプラインを更新する**: この演習では、デバッグおよびログのノイズを減らすために、Metric パイプラインから `hostmetrics` receiver をコメントアウトします。設定は次のようになります。
+
+```yaml
+ metrics:
+ receivers:
+ # - hostmetrics # Hostmetric reciever (cpu only)
+ - otlp
+```
+
+{{% /exercise %}}
+
+**[otelbin.io](https://www.otelbin.io/)** を使用して **Agent** の設定を検証してください。参考として、パイプラインの `metrics:` セクションは次のようになります。
+
+{{% mermaid %}}
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(resourcedetection
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2(otlphttp
fa:fa-upload):::exporter
+ EXP3( file
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-metrics
+ subgraph " "
+ subgraph subID1["`**Metrics**`"]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO2
+ PRO2 --> PRO3
+ PRO3 --> EXP1
+ PRO3 --> EXP3
+ PRO3 --> EXP2
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;
+{{% /mermaid %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md
new file mode 100644
index 0000000000..726b78c81d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md
@@ -0,0 +1,32 @@
+---
+title: 2.2 レジリエンステスト環境のセットアップ
+linkTitle: 2.2 環境のセットアップ
+weight: 2
+---
+
+次に、**File Storage** 構成をテストする準備として、環境を設定していきます。
+
+{{% exercise title="レジリエンステストのセットアップ" %}}
+
+**Gateway を起動する**: **Gateway terminal** ウィンドウで以下を実行します。
+
+```bash { title="Start the Gateway" }
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動する**: **Agent terminal** ウィンドウで以下を実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**5 つのテストスパンを送信する**: **Loadgen terminal** ウィンドウで以下を実行します。
+
+```bash { title="Start Load Generator" }
+../loadgen -count 5
+```
+
+**Agent** と **Gateway** の両方でデバッグログが表示され、**Gateway** によって `./gateway-traces.out` ファイルが作成されます。
+
+すべてが正しく動作していれば、システムのレジリエンステストに進むことができます。
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md
new file mode 100644
index 0000000000..13e8bb2fa0
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md
@@ -0,0 +1,40 @@
+---
+title: 2.3 障害をシミュレートする
+linkTitle: 2.3 障害をシミュレートする
+weight: 3
+---
+
+**Agent** の回復力を評価するために、**Gateway** の一時的な障害をシミュレートし、**Agent** がそれをどのように処理するかを観察します。
+
+{{% exercise title="Gateway の障害をシミュレートする" %}}
+
+**ネットワーク障害をシミュレートする**: **Gateway terminal** で `Ctrl-C` を使って **Gateway** を停止し、ゲートウェイのコンソールに停止したと表示されるまで待ちます。**Agent** は実行を継続しますが、データをゲートウェイに送信できなくなります。**Gateway terminal** の出力は次のようになります。
+
+```text
+2025-07-09T10:22:37.941Z info service@v0.126.0/service.go:345 Shutdown complete. {"resource": {}}
+```
+
+**トレースを送信する**: **Loadgen terminal** ウィンドウで `loadgen` を使ってさらに 5 件のトレースを送信します。
+
+```bash { title="Start Load Generator" }
+../loadgen -count 5
+```
+
+エージェントのリトライ機構が動作し、データの再送を継続的に試みていることに気づくでしょう。エージェントのコンソール出力には、次のようなメッセージが繰り返し表示されます。
+
+```text
+2025-01-28T14:22:47.020+0100 info internal/retry_sender.go:126 Exporting failed. Will retry the request after interval. {"kind": "exporter", "data_type": "traces", "name": "otlphttp", "error": "failed to make an HTTP request: Post \"http://localhost:5318/v1/traces\": dial tcp 127.0.0.1:5318: connect: connection refused", "interval": "9.471474933s"}
+```
+
+**Agent を停止する**: **Agent terminal** ウィンドウで `Ctrl-C` を使ってエージェントを停止します。エージェントのコンソールに停止が確認されるまで待ちます。
+
+```text
+2025-07-09T10:25:59.344Z info service@v0.126.0/service.go:345 Shutdown complete. {"resource": {}}
+```
+
+{{% /exercise %}}
+
+> [!IMPORTANT]
+> エージェントを停止すると、リトライのためにメモリに保持されているメトリクス、トレース、ログは失われます。ただし、FileStorage Extension を構成しているため、ターゲットエンドポイントによってまだ受け入れられていないテレメトリーはすべてディスクに安全にチェックポイントされます。
+>
+> エージェントを停止することは、エージェントが再起動された際にシステムがどのように回復するかを明確に示すための重要なステップです。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md
new file mode 100644
index 0000000000..f25751dbdd
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md
@@ -0,0 +1,76 @@
+---
+title: 2.4 Recovery
+linkTitle: 2.4 Recovery
+weight: 4
+---
+
+このエクササイズでは、**Gateway** Collector を再起動することで、**OpenTelemetry Collector** がネットワーク障害からどのように回復するかをテストします。**Gateway** が再び利用可能になると、**Agent** は最後のチェックポイント状態からデータの送信を再開し、データロスが発生しないことを保証します。
+
+{{% exercise title="Restart and verify recovery" %}}
+
+**Gateway を再起動する**: **Gateway terminal** ウィンドウで以下を実行します:
+
+```bash {title="Start the Gateway"}
+../otelcol --config=gateway.yaml
+```
+
+**Agent を再起動する**: **Agent terminal** ウィンドウで以下を実行します:
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+> **Agent** が起動すると、**File_Storage** 拡張機能が checkpoint フォルダー内のバッファされたデータを検出します。最後の checkpoint フォルダーから保存されたスパンのデキューを開始し、データが失われないことを保証します。
+
+**Agent デバッグ出力を確認する:** **Agent** のデバッグ出力は変化せず、以下の行が表示され続け、新しいデータがエクスポートされていないことを示している点に注意してください:
+
+ ```text
+ 2025-07-11T08:31:58.176Z info service@v0.126.0/service.go:289 Everything is ready. Begin running and processing data. {"resource": {}}
+ ```
+
+**Gateway デバッグ出力を観察する**
+**Gateway** のデバッグ画面から、追加の操作を行わなくても、それまで欠落していたトレースの受信を開始していることが確認できるはずです。例:
+
+ ```txt
+Attributes:
+ -> user.name: Str(Luke Skywalker)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ -> payment.amount: Double(75.75)
+ {"resource": {}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "traces"}
+ ```
+
+**`gateway-traces.out` ファイルを確認する:** `jq` を使用して、再作成された `gateway-traces.out` 内のトレースの数をカウントします。**Gateway** がダウンしていた間に送信した数と一致するはずです。
+
+{{% tabs %}}
+{{% tab title="Check Gateway Traces Out File" %}}
+
+```bash
+jq '.resourceSpans | length | "\(.) resourceSpans found"' gateway-traces.out
+```
+
+{{% /tab %}}
+
+{{% tab title="Example output" %}}
+
+```text
+"5 resourceSpans found"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% /exercise %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止します。
+
+### Conclusion
+
+このエクササイズでは、`file_storage` 拡張機能を構成し、`otlp` exporter のリトライ機構を有効化し、一時データ保存用にファイルバックドキューを使用することで、OpenTelemetry Collector のレジリエンスを強化する方法を実演しました。
+
+ファイルベースのチェックポイントとキューの永続化を実装することで、テレメトリーパイプラインが一時的な中断から正常に回復できるようになり、本番環境向けに、より堅牢で信頼性の高いものにできます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md
new file mode 100644
index 0000000000..b9cab17b17
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md
@@ -0,0 +1,19 @@
+---
+title: 2. Building In Resilience
+linkTitle: 2. Building Resilience
+time: 10 minutes
+weight: 4
+---
+
+OpenTelemetry Collector の [**FileStorage Extension**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/19bc7d6ee854c0c1b5c97d8d348e5b9d1199e8aa/extension/storage/filestorage/README.md) は、より回復力のあるテレメトリーパイプラインを構築するための重要なコンポーネントです。この機能により、Collector は処理中のデータを確実にチェックポイントし、リトライを効率的に管理し、一時的な障害発生時にも貴重なテレメトリーを失うことなく適切に対処できます。
+
+FileStorage を有効にすると、Collector は中間状態をディスクに永続化できるため、ネットワークの中断、バックエンドの停止、または Collector の再起動が発生しても、トレース、メトリクス、ログが失われないことが保証されます。つまり、ネットワーク接続が切断されたり、バックエンドが一時的に利用不可になったりしても、Collector はテレメトリーの受信とバッファリングを継続し、接続が復旧次第シームレスに配信を再開します。
+
+FileStorage Extension をパイプラインに統合することで、オブザーバビリティスタックの耐久性を強化し、接続が不安定になりがちな環境においても、高品質なテレメトリーの取り込みを維持できます。
+{{% notice note %}}
+
+このソリューションは、メトリクスについては接続のダウンタイムが短時間（最大 15 分）であれば機能します。ダウンタイムがこれを超えると、Splunk Observability Cloud はデータポイントの順序が乱れないようにするため、データを破棄する可能性があります。
+
+ログについては、今後の Splunk OpenTelemetry Collector のリリースで、エンタープライズ対応の完全なソリューションを実装する計画があります。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md
new file mode 100644
index 0000000000..96423889f3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md
@@ -0,0 +1,73 @@
+---
+title: 3.1 Configuration
+linkTitle: 3.1 Configuration
+weight: 1
+---
+
+{{% exercise title="Add a `filter` processor" %}}
+
+**Gateway terminal** ウィンドウに切り替え、`gateway.yaml` ファイルを開きます。`processors` セクションを以下の設定で更新します。
+
+1. **`filter` プロセッサーを追加する**:
+ `/_healthz` という名前の span を除外するように gateway を構成します。`error_mode: ignore` ディレクティブは、フィルタリング中に発生したエラーを無視することを保証し、パイプラインがスムーズに実行され続けるようにします。`traces` セクションでは、フィルタリングルールを定義し、特に `/_healthz` という名前の span を除外対象としています。
+
+ ```yaml
+ filter/health: # Defines a filter processor
+ error_mode: ignore # Ignore errors
+ traces: # Filtering rules for traces
+ span: # Exclude spans named "/_healthz"
+ - 'name == "/_healthz"'
+ ```
+
+2. **`filter` プロセッサーを `traces` パイプラインに追加する**:
+ `filter/health` プロセッサーを `traces` パイプラインに含めます。最適なパフォーマンスを得るために、フィルターはできるだけ早い段階、つまり `memory_limiter` の直後、`batch` プロセッサーの前に配置します。設定は以下のようになります。
+
+ ```yaml
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - filter/health # Filters data based on rules
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file/traces
+ ```
+
+この設定により、ヘルスチェック関連の span (`/_healthz`) がパイプラインの早い段階でフィルタリングされ、テレメトリーデータ内の不要なノイズが削減されます。
+
+{{% /exercise %}}
+
+**[otelbin.io](https://www.otelbin.io/)** を使用して agent の構成を検証します。参考までに、パイプラインの `traces:` セクションは以下のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(filter
fa:fa-microchip
health):::processor
+ PRO5(batch
fa:fa-microchip):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2( file
fa:fa-upload
traces):::exporter
+ %% Links
+ subID1:::sub-traces
+ subgraph " "
+ subgraph subID1["`**Traces**`"]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO4
+ PRO4 --> PRO3
+ PRO3 --> PRO5
+ PRO5 --> EXP1
+ PRO5 --> EXP2
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md
new file mode 100644
index 0000000000..9a66240fd2
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md
@@ -0,0 +1,146 @@
+---
+title: 3.2 Filter Processor のテスト
+linkTitle: 3.2 Filter Processor のテスト
+weight: 2
+---
+
+設定をテストするには、`"/_healthz"` という名前の span を含むトレースデータを生成する必要があります。
+
+{{% exercise title="span がドロップされていることを検証する" %}}
+
+**Gateway を起動する**: **Gateway terminal** ウィンドウで **Gateway** を起動します。
+
+```bash
+../otelcol --config ./gateway.yaml
+```
+
+**Agent を起動する**: **Agent terminal** ウィンドウで **Agent** を起動します。
+
+```bash
+../otelcol --config ./agent.yaml
+```
+
+**Loadgen を起動する**: **Loadgen terminal** ウィンドウで、以下のコマンドを実行し、ヘルスチェック span を有効にした状態でロードジェネレーターを起動します。
+
+```bash
+../loadgen -health -count 5
+```
+
+ **Agent terminal** のデバッグ出力に `_healthz` span が表示されます。
+
+ ```text
+ InstrumentationScope healthz 1.0.0
+Span #0
+ Trace ID : 0cce8759b5921c8f40b346b2f6e2f4b6
+ Parent ID :
+ ID : bc32bd0e4ddcb174
+ Name : /_healthz
+ Kind : Server
+ Start time : 2025-07-11 08:47:50.938703979 +0000 UTC
+ End time : 2025-07-11 08:47:51.938704091 +0000 UTC
+ Status code : Ok
+ Status message : Success
+```
+
+これらの span は、先ほど設定した filter processor によってドロップされるため、**Gateway** のデバッグ出力には現れません。
+
+**`agent.out` を検証する**: **Test terminal** で `jq` を使用して、**Agent** が受信した span の名前を確認します。
+
+{{% tabs %}}
+{{% tab title="agent.out 内の span を確認する" %}}
+
+```bash
+jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./agent.out
+```
+
+{{% /tab %}}
+{{% tab title="出力例" %}}
+
+```text
+"Span 1 found with name /movie-validator"
+"Span 2 found with name /_healthz"
+"Span 3 found with name /movie-validator"
+"Span 4 found with name /_healthz"
+"Span 5 found with name /movie-validator"
+"Span 6 found with name /_healthz"
+"Span 7 found with name /movie-validator"
+"Span 8 found with name /_healthz"
+"Span 9 found with name /movie-validator"
+"Span 10 found with name /_healthz"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**Gateway のデバッグ出力を確認する**: `jq` を使用して、**Gateway** が受信した span の名前を確認します。
+
+{{% tabs %}}
+{{% tab title="gateway-traces.out 内の span を確認する" %}}
+
+```bash
+jq -c '.resourceSpans[].scopeSpans[].spans[] | "Span \(input_line_number) found with name \(.name)"' ./gateway-traces.out
+```
+
+{{% /tab %}}
+{{% tab title="出力例" %}}
+
+`gateway-metrics.out` ファイルには `/_healthz` という名前の span は含まれません。
+
+```text
+"Span 1 found with name /movie-validator"
+"Span 2 found with name /movie-validator"
+"Span 3 found with name /movie-validator"
+"Span 4 found with name /movie-validator"
+"Span 5 found with name /movie-validator"
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% /exercise %}}
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+
+Filter processor で最適なパフォーマンスを得るには、入力データのフォーマットを十分に理解し、設定を厳密にテストしてください。**できる限り具体的なフィルタ条件を使用** することで、重要なデータを誤ってドロップしてしまうリスクを最小化できます。
+
+この設定は、さまざまな属性、タグ、またはカスタム条件に基づいて span をフィルタリングするように拡張可能で、特定のオブザーバビリティ要件に応じて OpenTelemetry Collector の柔軟性と効率性を高められます。
+{{% /notice %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して **Agent** および **Gateway** プロセスを停止してください。
+
+
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md
new file mode 100644
index 0000000000..71b8bac8f3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md
@@ -0,0 +1,27 @@
+---
+title: 3. スパンのドロップ
+linkTitle: 3. スパンのドロップ
+time: 5 minutes
+weight: 5
+---
+
+このセクションでは、[**Filter Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/filterprocessor/README.md) を使用して、特定の条件に基づいてスパンを選択的にドロップする方法を確認します。
+
+具体的には、スパン名に基づいてトレースをドロップします。これは、ヘルスチェックや内部通信トレースなど、不要なスパンをフィルタリングするためによく使用されます。今回のケースでは、`"/_healthz"` を含むスパンをフィルタリングします。これは通常、ヘルスチェックリクエストに関連しており、一般的に非常に「**ノイジー**」です。
+
+{{% exercise title="`3-dropping-spans` ディレクトリのセットアップ" %}}
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `3-dropping-spans` ディレクトリに変更し、`clear` コマンドを実行してください。**
+
+`2-building-resilience` ディレクトリから `*.yaml` を `3-dropping-spans` にコピーします。更新後のディレクトリ構造は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /exercise %}}
+
+次に、**filter processor** と関連するパイプラインを設定します。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md
new file mode 100644
index 0000000000..3aee4c6120
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md
@@ -0,0 +1,120 @@
+---
+title: 4.1 Configuration
+linkTitle: 4.1 Configuration
+weight: 1
+---
+
+このステップでは、`agent.yaml` を変更して `attributes` プロセッサーと `redaction` プロセッサーを追加します。これらのプロセッサーは、スパン属性内の機密データがログ出力やエクスポートされる前に、適切に処理されるようにするのに役立ちます。
+
+これまでに、コンソールに表示されるスパン属性の中に、個人情報や機密データが含まれていることに気づいたかもしれません。ここでは、これらの情報を効果的にフィルタリングしたり、編集 (redact) したりするために必要なプロセッサーを設定していきます。
+
+```text
+Attributes:
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.account_password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ {"kind": "exporter", "data_type": "traces", "name": "debug"}
+```
+
+{{% exercise title="attributes プロセッサーと redaction プロセッサーを追加する" %}}
+
+**Agent ターミナル** ウィンドウに切り替えて、エディターで `agent.yaml` ファイルを開きます。テレメトリーデータのセキュリティとプライバシーを強化するため、2 つのプロセッサーを追加します。
+
+**1. `attributes` プロセッサーの追加**: [**Attributes Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor) は、スパン属性 (タグ) の値を更新、削除、ハッシュ化することで変更できます。これは、機密情報をエクスポート前に難読化する場合に特に役立ちます。
+
+このステップでは、以下のことを行います。
+
+1. `user.phone_number` 属性を、固定値 `("UNKNOWN NUMBER")` に **更新** します。
+2. `user.email` 属性を **ハッシュ化** して、元のメールアドレスが露出しないようにします。
+3. `user.password` 属性を **削除** して、スパンから完全に取り除きます。
+
+```yaml
+ attributes/update:
+ actions: # Actions
+ - key: user.phone_number # Target key
+ action: update # Update action
+ value: "UNKNOWN NUMBER" # New value
+ - key: user.email # Target key
+ action: hash # Hash the email value
+ - key: user.password # Target key
+ action: delete # Delete the password
+ ```
+
+**2. `redaction` プロセッサーの追加**: [**Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor) は、クレジットカード番号やその他の個人を特定できる情報 (PII) などの事前定義されたパターンに基づいて、スパン属性内の機密データを検出し、編集 (redact) します。
+
+このステップでは、以下を行います。
+
+- すべての属性が処理されるように `allow_all_keys: true` を設定します (`false` に設定した場合は、明示的に許可されたキーだけが保持されます)。
+
+- **Visa** および **MasterCard** のクレジットカード番号を検出し編集するための正規表現を、`blocked_values` で定義します。
+
+- `summary: debug` オプションを指定すると、編集処理に関する詳細情報がデバッグ用にログ出力されます。
+
+```yaml
+ redaction/redact:
+ allow_all_keys: true # If false, only allowed keys will be retained
+ blocked_values: # List of regex patterns to block
+ - '\b4[0-9]{3}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # Visa
+ - '\b5[1-5][0-9]{2}[\s-]?[0-9]{4}[\s-]?[0-9]{4}[\s-]?[0-9]{4}\b' # MasterCard
+ summary: debug # Show debug details about redaction
+```
+
+**`traces` パイプラインを更新する**: 両方のプロセッサーを `traces` パイプラインに統合します。最初は redaction プロセッサーをコメントアウトしておくことを忘れないでください (後の別の演習で有効化します)。設定は以下のようになります。
+
+```yaml
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - attributes/update # Update, hash, and remove attributes
+ #- redaction/redact # Redact sensitive fields using regex
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file
+ - otlphttp
+```
+
+{{% /exercise %}}
+
+**[otelbin.io](https://www.otelbin.io/)** を使用して、エージェントの設定を検証します。参考までに、パイプラインの `traces:` セクションは以下のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRML(memory_limiter
fa:fa-microchip):::processor
+ PRRD(resourcedetection
fa:fa-microchip):::processor
+ PRRS(resource
fa:fa-microchip
add_mode):::processor
+ PRUP(attributes
fa:fa-microchip
update):::processor
+ EXP1(otlphttp
fa:fa-upload):::exporter
+ EXP2( debug
fa:fa-upload):::exporter
+ EXP3(file
fa:fa-upload):::exporter
+
+ %% Links
+ subID1:::sub-traces
+ subgraph " "
+ subgraph subID1["`**Traces**`"]
+ direction LR
+ REC1 --> PRML
+ PRML --> PRUP
+ PRUP --> PRRD
+ PRRD --> PRRS
+ PRRS --> EXP2
+ PRRS --> EXP3
+ PRRS --> EXP1
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md
new file mode 100644
index 0000000000..d4fbc7d2ce
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md
@@ -0,0 +1,92 @@
+---
+title: 4.2 Attribute Processor のテスト
+linkTitle: 4.2 Attribute Processor のテスト
+weight: 2
+---
+
+この演習では、**Agent** によってエクスポートされる前のスパンデータから `user.account_password` を**削除**し、`user.phone_number` **属性**を**更新**し、`user.email` を**ハッシュ化**します。
+
+{{% exercise title="attributes processor をテストする" %}}
+
+**Gateway を起動する**: **Gateway ターミナル**ウィンドウで **Gateway** を起動します。
+
+```bash
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動する**: **Agent ターミナル**ウィンドウで **Agent** を起動します。
+
+```bash
+../otelcol --config=agent.yaml
+```
+
+**Load Generator を起動する**: **Loadgen ターミナル**ウィンドウで `loadgen` を起動します。
+
+```bash
+../loadgen -count 1
+```
+
+**デバッグ出力を確認する**: **Agent** と **Gateway** の両方で、`user.account_password` が削除され、`user.phone_number` と `user.email` の両方が更新されていることを確認します。
+
+{{% tabs %}}
+{{% tab title="New Debug Output" %}}
+
+ ```text
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(UNKNOWN NUMBER)
+ -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287)
+ -> payment.amount: Double(51.71)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ ```
+
+{{% /tab %}}
+{{% tab title="Original Debug Output" %}}
+
+ ```text
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ -> payment.amount: Double(95.22)
+ ```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**ファイル出力を確認する**: `jq` を使用して、`gateway-taces.out` 内で `user.account_password` が削除され、`user.phone_number` と `user.email` が更新されていることを検証します。
+
+{{% tabs %}}
+{{% tab title="Validate attribute changes" %}}
+
+```bash
+jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.password" or .key == "user.phone_number" or .key == "user.email") | {key: .key, value: .value.stringValue}' ./gateway-traces.out
+```
+
+{{% /tabs %}}
+{{% tab title="Output" %}}
+
+`user.account_password` が削除され、`user.phone_number` と `user.email` が更新されていることを確認します。
+
+```json
+{
+ "key": "user.phone_number",
+ "value": "UNKNOWN NUMBER"
+}
+{
+ "key": "user.email",
+ "value": "62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287"
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止してください。
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md
new file mode 100644
index 0000000000..96b4c83ec3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md
@@ -0,0 +1,140 @@
+---
+title: 4.3 Redaction プロセッサーのテスト
+linkTitle: 4.3 Redaction プロセッサーのテスト
+weight: 3
+---
+
+`redaction` プロセッサーは、テレメトリーデータから **許可** または **削除** する属性と値を細かく制御できます。
+
+この演習では、**Agent** がエクスポートする前のスパンデータの `user.visa` と `user.mastercard` の値を **リダクション** します。
+{{% exercise title="redaction プロセッサーのテスト" %}}
+
+**Gateway を起動する**: **Gateway terminal** ウィンドウで **Gateway** を起動します。
+
+```bash
+../otelcol --config=gateway.yaml
+```
+
+**`redaction/redact` プロセッサーを有効にする**: **Agent terminal** ウィンドウで `agent.yaml` を編集し、前の演習で挿入した `#` を削除します。
+
+```yaml
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - attributes/update # Update, hash, and remove attributes
+ - redaction/redact # Redact sensitive fields using regex
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file
+ - otlphttp
+```
+
+**Agent を起動する**: **Agent terminal** ウィンドウで **Agent** を起動します。
+
+```bash
+../otelcol --config=agent.yaml
+```
+
+**Load Generator を起動する**: **Loadgen terminal** ウィンドウで `loadgen` を起動します。
+
+```bash
+../loadgen -count 1
+```
+
+**デバッグ出力を確認する**: **Agent** と **Gateway** の両方で `user.visa` と `user.mastercard` の値が更新されていることを確認します。`user.amex` 属性の値は `blocked_values` に一致する正規表現パターンが追加されていないため、**リダクションされていない** ことに注意してください。
+
+{{% tabs %}}
+{{% tab title="新しいデバッグ出力" %}}
+
+ ```text
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(UNKNOWN NUMBER)
+ -> user.email: Str(62d5e03d8fd5808e77aee5ebbd90cf7627a470ae0be9ffd10e8025a4ad0e1287)
+ -> payment.amount: Double(69.71)
+ -> user.visa: Str(****)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(****)
+ -> redaction.masked.keys: Str(user.mastercard,user.visa)
+ -> redaction.masked.count: Int(2)
+ ```
+
+{{% /tab %}}
+{{% tab title="元のデバッグ出力" %}}
+
+ ```text
+ -> user.name: Str(George Lucas)
+ -> user.phone_number: Str(+1555-867-5309)
+ -> user.email: Str(george@deathstar.email)
+ -> user.password: Str(LOTR>StarWars1-2-3)
+ -> user.visa: Str(4111 1111 1111 1111)
+ -> user.amex: Str(3782 822463 10005)
+ -> user.mastercard: Str(5555 5555 5555 4444)
+ -> payment.amount: Double(65.54)
+ ```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% notice note %}}
+redaction プロセッサーに `summary:debug` を含めると、どの一致したキーの値がリダクションされたかについての概要情報と、マスクされた値の数がデバッグ出力に含まれます。
+
+```text
+ -> redaction.masked.keys: Str(user.mastercard,user.visa)
+ -> redaction.masked.count: Int(2)
+ ```
+
+{{% /notice %}}
+
+**ファイル出力を確認する**: `jq` を使用して、`gateway-traces.out` 内の `user.visa` と `user.mastercard` が更新されていることを確認します。
+
+{{% tabs %}}
+{{% tab title="属性の変更を検証する" %}}
+
+```bash
+jq '.resourceSpans[].scopeSpans[].spans[].attributes[] | select(.key == "user.visa" or .key == "user.mastercard" or .key == "user.amex") | {key: .key, value: .value.stringValue}' ./gateway-traces.out
+```
+
+{{% /tabs %}}
+{{% tab title="出力" %}}
+
+`user.amex` は `blocked_values` に一致する正規表現パターンが追加されていないため、リダクションされていないことに注意してください。
+
+```json
+{
+ "key": "user.visa",
+ "value": "****"
+}
+{
+ "key": "user.amex",
+ "value": "3782 822463 10005"
+}
+{
+ "key": "user.mastercard",
+ "value": "****"
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+これらは `attributes` プロセッサーと `redaction` プロセッサーが機密データを保護するために設定可能な方法のほんの一例です。
+
+{{% /exercise %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止してください。
+
+
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md
new file mode 100644
index 0000000000..0e6a59ba27
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md
@@ -0,0 +1,28 @@
+---
+title: 4. 機密データの編集
+linkTitle: 4. 機密データ
+time: 10 minutes
+weight: 6
+---
+
+このセクションでは、OpenTelemetry Collector を設定して特定のタグを削除し、テレメトリスパンから機密データを編集する方法を学びます。これは、クレジットカード番号、個人データ、その他セキュリティ関連の詳細など、処理または送信される前に匿名化する必要がある機密情報を保護するために重要です。
+
+OpenTelemetry Collector の主要なプロセッサーの設定方法を確認していきます。具体的には次のとおりです。
+
+- **[Attributes Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/attributesprocessor/README.md)**: 特定のスパン属性を変更または削除します。
+- [**Redaction Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/redactionprocessor/README.md): 機密データが保存または送信される前にサニタイズされていることを保証します。
+
+{{% exercise title="`4-sensitive-data` ディレクトリのセットアップ" %}}
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `4-sensitive-data` ディレクトリに移動し、`clear` コマンドを実行してください。**
+
+`3-dropping-spans` ディレクトリから `*.yaml` を `4-sensitive-data` にコピーします。更新されたディレクトリ構造は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md
new file mode 100644
index 0000000000..203d3f74cb
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md
@@ -0,0 +1,113 @@
+---
+title: 5.1 Configuration
+linkTitle: 5.1 Configuration
+weight: 1
+---
+
+{{% exercise title="`transform` プロセッサーを追加する" %}}
+**`transform` プロセッサーを追加する**: **Gateway terminal** ウィンドウに切り替えて `gateway.yaml` を編集し、以下の `transform` プロセッサーを追加します。
+
+```yaml
+ transform/logs: # Processor Type/Name
+ log_statements: # Log Processing Statements
+ - context: resource # Log Context
+ statements: # List of attribute keys to keep
+ - keep_keys(attributes, ["com.splunk.sourcetype", "host.name", "otelcol.service.mode"])
+```
+
+`-context: resource` キーを使うことで、ログの `resourceLog` 属性を対象としています。
+
+この設定により、関連するリソース属性（`com.splunk.sourcetype`、`host.name`、`otelcol.service.mode`）のみが保持され、ログの効率が向上し、不要なメタデータが削減されます。
+
+**ログ重要度マッピング用のコンテキストブロックを追加する**: ログレコードの `severity_text` および `severity_number` フィールドを適切に設定するため、`log_statements` 内に `log` コンテキストブロックを追加します。この設定では、ログ本文から `level` 値を抽出して `severity_text` にマッピングし、ログレベルに応じて対応する `severity_number` を割り当てます。
+
+```yaml
+ - context: log # Log Context
+ statements: # Transform Statements Array
+ - set(cache, ParseJSON(body)) where IsMatch(body, "^\\{") # Parse JSON log body into a cache object
+ - flatten(cache, "") # Flatten nested JSON structure
+ - merge_maps(attributes, cache, "upsert") # Merge cache into attributes, updating existing keys
+ - set(severity_text, attributes["level"]) # Set severity_text from the "level" attribute
+ - set(severity_number, 1) where severity_text == "TRACE" # Map severity_text to severity_number
+ - set(severity_number, 5) where severity_text == "DEBUG"
+ - set(severity_number, 9) where severity_text == "INFO"
+ - set(severity_number, 13) where severity_text == "WARN"
+ - set(severity_number, 17) where severity_text == "ERROR"
+ - set(severity_number, 21) where severity_text == "FATAL"
+```
+
+`merge_maps` 関数は、2つのマップ（辞書）を1つに結合するために使用します。ここでは、`cache` オブジェクト（ログ本文から解析された JSON データを含む）を `attributes` マップに結合します。
+
+- **パラメータ**:
+ - `attributes`: データの結合先となるターゲットマップ。
+ - `cache`: 解析された JSON データを含むソースマップ。
+ - `"upsert"`: このモードでは、`attributes` マップ内に既に存在するキーがあれば、その値が `cache` の値で更新されます。キーが存在しない場合は新たに挿入されます。
+
+このステップは重要です。なぜなら、ログ本文の関連フィールド（例: `level`、`message` など）がすべて `attributes` マップに追加され、後続の処理やエクスポートで利用できるようになるためです。
+
+**主要な変換処理のまとめ**:
+
+- **Parse JSON**: ログ本文から構造化データを抽出します。
+- **Flatten JSON**: ネストされた JSON オブジェクトをフラットな構造に変換します。
+- **Merge Attributes**: 抽出されたデータをログ属性に統合します。
+- **Map Severity Text**: ログの level 属性から severity_text を割り当てます。
+- **Assign Severity Numbers**: 重要度レベルを標準化された数値に変換します。
+
+> [!IMPORTANT]
+> `transform` プロセッサーは **1つだけ** 持ち、その中に2つのコンテキストブロック（一方は `resource` 用、もう一方は `log` 用）を含める必要があります。
+
+この設定により、ログの重要度が正しく抽出、標準化、構造化され、効率的な処理が可能になります。
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+すべての JSON フィールドをトップレベル属性にマッピングするこの方法は、**OTTL のテストおよびデバッグ目的のみ** で使用してください。本番環境では高カーディナリティを引き起こします。
+{{% /notice %}}
+
+**`logs` パイプラインを更新する**: `logs:` パイプラインに `transform/logs:` プロセッサーを追加し、設定が以下のようになるようにします。
+
+```yaml
+ logs: # Logs pipeline
+ receivers:
+ - otlp # OTLP receiver
+ processors: # Processors for logs
+ - memory_limiter
+ - resource/add_mode
+ - transform/logs
+ - batch
+ exporters:
+ - debug # Debug exporter
+ - file/logs
+```
+
+{{% /exercise %}}
+
+エージェントの設定を [**https://otelbin.io**](https://otelbin.io/) で検証してください。参考までに、パイプラインの `logs:` セクションは以下のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(transform
fa:fa-microchip
logs):::processor
+ PRO5(batch
fa:fa-microchip):::processor
+ EXP1(file
fa:fa-upload
logs):::exporter
+ EXP2( debug
fa:fa-upload):::exporter
+ %% Links
+ subID1:::sub-logs
+ subgraph " "
+ subgraph subID1["`**Logs**`"]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PRO3
+ PRO3 --> PRO4
+ PRO4 --> PRO5
+ PRO5 --> EXP2
+ PRO5 --> EXP1
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md
new file mode 100644
index 0000000000..6510361df6
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md
@@ -0,0 +1,29 @@
+---
+title: 5.2 環境のセットアップ
+linkTitle: 5.2 環境のセットアップ
+weight: 2
+---
+
+{{% exercise title="transform テストのセットアップ" %}}
+
+**Gateway を起動する**: **Gateway terminal** で以下を実行します。
+
+```bash { title="Start the Gateway" }
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動する**: **Agent terminal** で以下を実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**Load Generator を起動する**: **Loadgen terminal** ウィンドウで、**JSON を有効化** した状態で以下のコマンドを実行し、ロードジェネレーターを起動します。
+
+```bash { title="Log Generator" }
+../loadgen -logs -json -count 5
+```
+
+`loadgen` は JSON 形式で 5 行のログを `./quotes.log` に書き込みます。
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md
new file mode 100644
index 0000000000..b3de7b96d3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md
@@ -0,0 +1,129 @@
+---
+title: 5.3 Test Transform Processor
+linkTitle: 5.3 Test Transform Processor
+weight: 3
+---
+
+このテストでは、**Agent** によってエクスポートされる前に、`com.splunk/source` および `os.type` メタデータがログのリソース属性から **削除** されていることを確認します。さらに、このテストでは以下も確認します。
+
+1. ログ本文が解析され、重大度情報が抽出されていること。
+ - `SeverityText` および `SeverityNumber` が `LogRecord` に設定されていること。
+2. ログ本文の JSON フィールドがログの `attributes` に昇格されていること。
+
+これにより、エクスポート前に適切なメタデータのフィルタリング、重大度のマッピング、構造化ログのエンリッチメントが行われることが保証されます。
+
+{{% exercise title="属性が削除されていることを確認する" %}}
+
+**デバッグ出力を確認する**: **Agent** と **Gateway** の両方で、`com.splunk/source` および `os.type` が削除されていることを確認します。
+
+{{% tabs %}}
+{{% tab title="Gateway Debug Output" %}}
+
+ ```text
+Resource attributes:
+ -> com.splunk.sourcetype: Str(quotes)
+ -> host.name: Str(workshop-instance)
+ -> otelcol.service.mode: Str(agent)
+ ```
+
+{{% /tab %}}
+{{% tab title="Agent Debug Output" %}}
+
+ ```text
+Resource attributes:
+ -> com.splunk.source: Str(./quotes.log)
+ -> com.splunk.sourcetype: Str(quotes)
+ -> host.name: Str(workshop-instance)
+ -> os.type: Str(linux)
+ -> otelcol.service.mode: Str(agent)
+ ```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**Agent** と **Gateway** の両方で、`LogRecord` の `SeverityText` および `SeverityNumber` がログ本文の重大度 `level` を用いて定義されていることを確認します。本文の JSON フィールドが、トップレベルのログ `Attributes` としてアクセスできることを確認します。
+
+{{% tabs %}}
+{{% tab title="Gateway Debug Output" %}}
+
+```text
+
+SeverityText: WARN
+SeverityNumber: Warn(13)
+Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"})
+Attributes:
+ -> log.file.path: Str(quotes.log)
+ -> level: Str(WARN)
+ -> message: Str(Your focus determines your reality.)
+ -> movie: Str(SW)
+ -> timestamp: Str(2025-03-07 11:17:26)
+
+```
+
+{{% /tab %}}
+{{% tab title="Agemt Debug Output" %}}
+
+```text
+
+SeverityText:
+SeverityNumber: Unspecified(0)
+Body: Str({"level":"WARN","message":"Your focus determines your reality.","movie":"SW","timestamp":"2025-03-07 11:17:26"})
+Attributes:
+ -> log.file.path: Str(quotes.log)
+
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+**ファイル出力を確認する**: 新しい `gateway-logs.out` ファイルで、データが変換されていることを確認します。
+
+{{% tabs %}}
+{{% tab title="jq Query" %}}
+
+```bash
+jq '[.resourceLogs[].scopeLogs[].logRecords[] | {severityText, severityNumber, body: .body.stringValue}]' gateway-logs.out
+```
+
+{{% /tabs %}}
+{{% tab title="Example Output" %}}
+
+```json
+[
+ {
+ "severityText": "DEBUG",
+ "severityNumber": 5,
+ "body": "{\"level\":\"DEBUG\",\"message\":\"All we have to decide is what to do with the time that is given us.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ },
+ {
+ "severityText": "WARN",
+ "severityNumber": 13,
+ "body": "{\"level\":\"WARN\",\"message\":\"The Force will be with you. Always.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ },
+ {
+ "severityText": "ERROR",
+ "severityNumber": 17,
+ "body": "{\"level\":\"ERROR\",\"message\":\"One does not simply walk into Mordor.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ },
+ {
+ "severityText": "DEBUG",
+ "severityNumber": 5,
+ "body": "{\"level\":\"DEBUG\",\"message\":\"Do or do not, there is no try.\",\"movie\":\"SW\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ }
+]
+[
+ {
+ "severityText": "ERROR",
+ "severityNumber": 17,
+ "body": "{\"level\":\"ERROR\",\"message\":\"There is some good in this world, and it's worth fighting for.\",\"movie\":\"LOTR\",\"timestamp\":\"2025-03-07 11:56:29\"}"
+ }
+]
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{% /exercise %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** プロセスを停止してください。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md
new file mode 100644
index 0000000000..d0636ca5c7
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md
@@ -0,0 +1,39 @@
+---
+title: 5. Transform Data
+linkTitle: 5. Transform Data
+time: 10 minutes
+weight: 7
+---
+
+[**Transform Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md) を使うと、ログ、メトリクス、トレースなどのテレメトリーデータがパイプラインを流れる際に変更できます。**OpenTelemetry Transformation Language (OTTL)** を使用することで、アプリケーションコードに触れることなく、データのフィルタリング、エンリッチメント、変換をその場で実行できます。
+
+この演習では、`gateway.yaml` を更新して **Transform Processor** を組み込み、以下の処理を行います。
+
+- ログのリソース属性を**フィルタリング**します。
+- JSON 構造化ログデータを**パース**して属性に変換します。
+- ログメッセージ本文に基づいてログのシビリティレベルを**設定**します。
+
+これまでのログでは、`SeverityText` や `SeverityNumber` といったフィールドが未定義になっていることに気づいたかもしれません。これは `filelog` レシーバーの典型的な挙動です。ただし、シビリティはログ本文の中に埋め込まれています。例えば次のような形式です。
+
+```text
+SeverityText:
+SeverityNumber: Unspecified(0)
+Body: Str(2025-01-31 15:49:29 [WARN] - Do or do not, there is no try.)
+```
+
+ログには、ログ本文内に JSON としてエンコードされた構造化データが含まれていることがよくあります。これらのフィールドを属性として抽出することで、インデックス作成、フィルタリング、クエリの効率が向上します。下流システムで JSON を手作業でパースする代わりに、OTTL を使えばテレメトリーパイプラインレベルで自動的に変換できます。
+
+{{% exercise title="Set up the `5-transform-data` directory" %}}
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウで `5-transform-data` ディレクトリに移動し、`clear` コマンドを実行してください。**
+
+`4-sensitve-data` ディレクトリから `*.yaml` を `5-transform-data` にコピーします。更新後のディレクトリ構造は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md
new file mode 100644
index 0000000000..2751a3befb
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md
@@ -0,0 +1,40 @@
+---
+title: 6.1 Routing Connector の設定
+linkTitle: 6.1 Routing の設定
+weight: 1
+---
+
+この演習では、`gateway.yaml` 内で **Routing Connector** を設定します。Routing Connector はメトリクス、トレース、ログを任意の属性に基づいてルーティングできますが、ここでは `deployment.environment` 属性に基づくトレースのルーティングに絞って扱います（任意の span / log / metric 属性を使用可能です）。
+
+{{% exercise title="Configure the routing connector" %}}
+
+**新しい `file` exporter を追加します**: `routing` connector はルーティング先として複数のターゲットを必要とします。**Gateway ターミナル**で、`gateway.yaml` の `exporters` セクションに、データが正しく振り分けられるよう、`file/traces/route1-regular` と `file/traces/route2-security` の 2 つの新しい file exporter を作成します。
+
+```yaml
+ file/traces/route1-regular: # Exporter for regular traces
+ path: "./gateway-traces-route1-regular.out" # Path for saving trace data
+ append: false # Overwrite the file each time
+ file/traces/route2-security: # Exporter for security traces
+ path: "./gateway-traces-route2-security.out" # Path for saving trace data
+ append: false # Overwrite the file each time
+```
+
+`routing` connector を追加して**ルーティングを有効化**します。OpenTelemetry の設定ファイルでは、`connectors` は receivers や processors と同様に専用のセクションを持っています。
+
+`#connectors:` セクションを見つけてコメントアウトを解除します。次に、`connectors:` セクションの下に以下を追加します。
+
+```yaml
+ routing:
+ default_pipelines: [traces/route1-regular] # Default pipeline if no rule matches
+ error_mode: ignore # Ignore errors in routing
+ table: # Define routing rules
+ # Routes spans to a target pipeline if the resourceSpan attribute matches the rule
+ - statement: route() where attributes["deployment.environment"] == "security-applications"
+ pipelines: [traces/route2-security] # Security target pipeline
+```
+
+{{% /exercise %}}
+
+設定ファイル内の default pipeline は Catch all として機能します。これはルーティングルールテーブル内のどのルールにも一致しないデータ（ここでは span）に対するルーティング先となります。このテーブルでは、次のルール `["deployment.environment"] == "security-applications"` に一致する span のルーティング先となる pipeline を定義しています。
+
+`routing` の設定が完了したら、次のステップではこれらのルーティングルールを適用するために `pipelines` を設定します。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md
new file mode 100644
index 0000000000..ffe0383fe3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md
@@ -0,0 +1,107 @@
+---
+title: 6.2 パイプラインの構成
+linkTitle: 6.2 パイプラインの構成
+weight: 2
+---
+
+{{% exercise title="ルーティングパイプラインを接続する" %}}
+
+**元の `traces` パイプラインをルーティングを使用するように更新します**:
+
+1. `routing` を有効にするため、元の `traces` パイプラインを更新して `routing` を唯一のエクスポーターとして使用します。これにより、すべてのスパンデータが評価のために **Routing Connector** を通過し、その後接続されたパイプラインへ送られます。また、**すべての** プロセッサーを削除し、空の配列（`[]`）に置き換えます。これらは `traces/route1-regular` および `traces/route2-security` パイプラインで処理され、それぞれのルートでカスタムの動作を実現できるようになります。`traces:` の構成は以下のようになります:
+
+ ```yaml
+ traces: # Traces pipeline
+ receivers:
+ - otlp # OTLP receiver
+ processors: [] # Processors for traces
+ exporters:
+ - routing
+ ```
+
+**既存の `traces` パイプラインの下に、`route1-regular` と `route2-security` の両方のトレースパイプラインを追加します**:
+
+1. **Route1-regular パイプラインを構成する**: このパイプラインは、コネクター内のルーティングテーブルで **一致しなかった** すべてのスパンを処理します。
+これは唯一のレシーバーとして `routing` を使用しており、元のトレースパイプラインから `connection` を通じてデータを受け取る点に注目してください。
+
+ ```yaml
+ traces/route1-regular: # Default pipeline for unmatched spans
+ receivers:
+ - routing # Receive data from the routing connector
+ processors:
+ - memory_limiter # Memory Limiter Processor
+ - resource/add_mode # Adds collector mode metadata
+ - batch
+ exporters:
+ - debug # Debug Exporter
+ - file/traces/route1-regular # File Exporter for unmatched spans
+ ```
+
+2. **route2-security パイプラインを追加する**: このパイプラインは、ルーティングルール `"[deployment.environment"] == "security-applications"` に一致するすべてのスパンを処理します。このパイプラインもレシーバーとして `routing` を使用します。このパイプラインを `traces/route1-regular` の下に追加してください。
+
+ ```yaml
+ traces/route2-security: # Default pipeline for unmatched spans
+ receivers:
+ - routing # Receive data from the routing connector
+ processors:
+ - memory_limiter # Memory Limiter Processor
+ - resource/add_mode # Adds collector mode metadata
+ - batch
+ exporters:
+ - debug # Debug exporter
+ - file/traces/route2-security # File exporter for unmatched spans
+ ```
+
+{{% /exercise %}}
+
+エージェント構成を **[otelbin.io](https://www.otelbin.io/)** で検証します。参考として、パイプラインの `traces:` セクションは以下のようになります:
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1( otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(memory_limiter
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(resource
fa:fa-microchip
add_mode):::processor
+ PRO5(batch
fa:fa-microchip):::processor
+ PRO6(batch
fa:fa-microchip):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2( file
fa:fa-upload
traces):::exporter
+ EXP3( debug
fa:fa-upload):::exporter
+ EXP4( file
fa:fa-upload
traces):::exporter
+ ROUTE1( routing
fa:fa-route):::con-export
+ ROUTE2( routing
fa:fa-route):::con-receive
+ ROUTE3( routing
fa:fa-route):::con-receive
+ %% Links
+ subID1:::sub-traces
+ subID2:::sub-traces
+ subID3:::sub-traces
+ subgraph " "
+ direction LR
+ subgraph subID1["`**Traces**`"]
+ REC1 --> ROUTE1
+ end
+ subgraph subID2["`**Traces/route2-security**`"]
+ ROUTE1 --> ROUTE2
+ ROUTE2 --> PRO1
+ PRO1 --> PRO3
+ PRO3 --> PRO5
+ PRO5 --> EXP1
+ PRO5 --> EXP2
+ end
+ subgraph subID3["`**Traces/route1-regular**`"]
+ ROUTE1 --> ROUTE3
+ ROUTE3 --> PRO2
+ PRO2 --> PRO4
+ PRO4 --> PRO6
+ PRO6 --> EXP3
+ PRO6 --> EXP4
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px, color:#fbbf24,stroke-dasharray: 3 3;
+```
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md
new file mode 100644
index 0000000000..0691a1f7f7
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md
@@ -0,0 +1,77 @@
+---
+title: 6.3 Test Routing Connector
+linkTitle: 6.3 Test Routing Connector
+weight: 3
+---
+
+{{% exercise title="Verify spans route to the security file" %}}
+
+このセクションでは、**Gateway** に設定した `routing` ルールをテストします。期待される結果は、`loadgen` によって生成された `span` のうち `"[deployment.environment"] == "security-applications"` ルールに一致するものが、`gateway-traces-route2-security.out` ファイルに送信されることです。
+
+**Gatewayを起動します**: **Gateway terminal** ウィンドウで **Gateway** を起動します。
+
+```bash
+../otelcol --config gateway.yaml
+```
+
+**Agentを起動します**: **Agent terminal** ウィンドウで **Agent** を起動します。
+
+```bash
+../otelcol --config agent.yaml
+```
+
+**通常のSpanを送信します**: **Loadgen terminal** ウィンドウで `loadgen` を使用して通常のスパンを送信します。
+
+```bash
+../loadgen -count 1
+```
+
+**Agent** と **Gateway** の両方がデバッグ情報を表示します。Gatewayは新しい `gateway-traces-route1-regular.out` ファイルも生成します。これは、通常のスパンの送信先として指定されたためです。
+
+{{% notice title="Tip" style="primary" icon="lightbulb" %}}
+`gateway-traces-route1-regular.out` を確認すると、`loadgen` によって送信された `span` が含まれています。また、空の `gateway-traces-route2-security..out` ファイルも確認できます。これは、ルーティング設定が、一致するスパンがまだ処理されていない場合でも出力ファイルを即座に作成するためです。
+{{% /notice %}}
+
+**Security Spanを送信します**: **Loadgen terminal** ウィンドウで `security` フラグを使用してセキュリティスパンを送信します。
+
+```bash
+../loadgen -security -count 1
+```
+
+再び、**Agent** と **Gateway** の両方がデバッグ情報（先ほど送信したスパンを含む）を表示するはずです。今回は、**Gateway** が `gateway-traces-route2-security.out` ファイルに行を書き込みます。このファイルは、`deployment.environment` リソース属性が `"security-applications"` に一致するスパン用に指定されたものです。
+
+{{% tabs %}}
+{{% tab title="Validate resource attribute matches" %}}
+
+```bash
+jq -c '.resourceSpans[] as $resource | $resource.scopeSpans[].spans[] | {spanId: .spanId, deploymentEnvironment: ($resource.resource.attributes[] | select(.key == "deployment.environment") | .value.stringValue)}' gateway-traces-route2-security.out
+```
+
+{{% /tabs %}}
+{{% tab title="Output" %}}
+
+```json
+{"spanId":"cb799e92e26d5782","deploymentEnvironment":"security-applications"}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+このシナリオは複数回繰り返すことができ、各トレースは対応する出力ファイルに書き込まれます。
+
+{{% /exercise %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止します。
+
+## Conclusion
+
+このセクションでは、異なるスパンを送信して送信先を検証することで、Gatewayにおけるルーティングコネクタのテストに成功しました。
+
+- **通常のスパン** は `gateway-traces-route1-regular.out` に正しくルーティングされました。これにより、`deployment.environment` 属性が一致しないスパンがデフォルトのパイプラインに従うことが確認されました。
+
+- **セキュリティ関連のスパン** は `gateway-traces-route2-security.out` にルーティングされました。これにより、`"deployment.environment": "security-applications"` に基づくルーティングルールが期待どおりに動作することが実証されました。
+
+出力ファイルを検査することで、OpenTelemetry Collectorが *スパンの属性を正しく評価し、適切な送信先にルーティングする* ことを確認しました。これにより、ルーティングルールが異なるユースケースに応じてテレメトリーデータを効果的に分離し、振り分けられることが検証されます。
+
+このアプローチを拡張して、異なる属性に基づいてスパン、メトリクス、ログをさらに分類するための追加のルーティングルールを定義することができます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md
new file mode 100644
index 0000000000..c571b0c147
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md
@@ -0,0 +1,27 @@
+---
+title: 6. データのルーティング
+linkTitle: 6. データのルーティング
+time: 10 minutes
+weight: 8
+---
+
+OpenTelemetry の [**Routing Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/routingconnector) は、特定の条件に基づいてデータ（`traces`、`metrics`、`logs`）を異なるパイプラインや宛先に振り分けることができる強力な機能です。これは、テレメトリーデータのサブセットに対して異なる処理やエクスポートロジックを適用したい場合に特に役立ちます。
+
+例えば、*production* のデータを 1 つのエクスポーターに送信しつつ、*test* や *development* のデータを別のエクスポーターに振り分けることができます。同様に、サービス名、環境、スパン名などの属性に基づいて特定のスパンをルーティングし、カスタムの処理や保存ロジックを適用することも可能です。
+
+{{% exercise title="`6-routing-data` ディレクトリのセットアップ" %}}
+
+> [!IMPORTANT]
+> ***すべての* ターミナルウィンドウで `6-routing-data` ディレクトリに移動し、`clear` コマンドを実行してください。**
+
+`5-transform-data` ディレクトリから `*.yaml` を `6-routing-data` にコピーします。更新されたディレクトリ構造は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+{{% /exercise %}}
+
+次に、routing connector とそれぞれのパイプラインを設定していきます。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md
new file mode 100644
index 0000000000..c7af716783
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md
@@ -0,0 +1,93 @@
+---
+title: 7.1 Count Connector のテスト
+linkTitle: 7.1 Count Connector のテスト
+weight: 1
+---
+
+{{% exercise title="Count Connector のテスト" %}}
+
+**Gateway を起動します**:
+**Gateway ターミナル** ウィンドウで次のコマンドを実行します。
+
+```bash { title="Start the Gateway" }
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動します**:
+**Agent ターミナル** ウィンドウで次のコマンドを実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**Loadgen で 12 行のログを送信します**:
+**Spans ターミナル** ウィンドウで 12 行のログを送信します。これらは 2 つのインターバルに分けて読み取られます。次の `loadgen` コマンドを実行してください。
+
+```bash { title="Loadgen" }
+../loadgen -logs -json -count 12
+```
+
+**Agent** と **Gateway** の両方がデバッグ情報を表示し、データを処理していることを示します。`loadgen` が完了するまで待ちます。
+
+**メトリクスが生成されたことを確認します**
+ログが処理されると、**Agent** はメトリクスを生成して **Gateway** に転送し、**Gateway** はそれらを `gateway-metrics.out` に書き込みます。
+
+`logs.full.count`、`logs.sw.count`、`logs.lotr.count`、`logs.error.count` のメトリクスが出力に含まれているかを確認するには、次の **jq** クエリを実行します。
+
+{{% tabs %}}
+{{% tab title="jq query command" %}}
+
+```bash
+jq '.resourceMetrics[].scopeMetrics[].metrics[]
+ | select(.name == "logs.full.count" or .name == "logs.sw.count" or .name == "logs.lotr.count" or .name == "logs.error.count")
+ | {name: .name, value: (.sum.dataPoints[0].asInt // "-")}' gateway-metrics.out
+```
+
+{{% /tab %}}
+{{% tab title="jq example output" %}}
+
+```json
+{
+ "name": "logs.sw.count",
+ "value": "2"
+}
+{
+ "name": "logs.lotr.count",
+ "value": "2"
+}
+{
+ "name": "logs.full.count",
+ "value": "4"
+}
+{
+ "name": "logs.error.count",
+ "value": "2"
+}
+{
+ "name": "logs.error.count",
+ "value": "1"
+}
+{
+ "name": "logs.sw.count",
+ "value": "2"
+}
+{
+ "name": "logs.lotr.count",
+ "value": "6"
+}
+{
+ "name": "logs.full.count",
+ "value": "8"
+}
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+注: `logs.full.count` は通常 `logs.sw.count` + `logs.lotr.count` と等しくなりますが、`logs.error.count` はランダムな数値になります。
+{{% /notice %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止します。
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md
new file mode 100644
index 0000000000..0647aa6c1d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md
@@ -0,0 +1,159 @@
+---
+title: 7.2 Sum Connector でメトリクスを作成する
+linkTitle: 7.2 Sum Connector
+time: 10 minutes
+weight: 2
+---
+
+このセクションでは、[**Sum Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/sumconnector) がスパンから値を抽出してメトリクスに変換する方法を見ていきます。
+
+具体的には、ベーススパンに含まれるクレジットカードの請求額を利用し、Sum Connector を活用して請求額の合計をメトリクスとして取得します。
+
+このコネクターは、スパン、スパンイベント、メトリクス、データポイント、ログレコードから属性値を収集（**sum**）するために使用できます。各値を個別にキャプチャし、メトリクスに変換して受け渡します。ただし、これらのメトリクスとその属性を使って計算やさらなる処理を行うのは **バックエンド** の役割です。
+
+{{% exercise title="Sum Connector を追加する" %}}
+
+**Agent ターミナル** ウィンドウに切り替えて、エディターで `agent.yaml` ファイルを開きます。
+
+- **Sum Connector を追加する**
+設定ファイルの connectors セクションに Sum Connector を追加し、メトリクスカウンターを定義します。
+
+```yaml
+ sum:
+ spans:
+ user.card-charge:
+ source_attribute: payment.amount
+ conditions:
+ - attributes["payment.amount"] != "NULL"
+ attributes:
+ - key: user.name
+
+```
+
+{{% /exercise %}}
+
+上記の例では、スパン内の `payment.amount` 属性をチェックします。有効な値が含まれている場合、**Sum** コネクターは `user.card-charge` というメトリクスを生成し、`user.name` を属性として含めます。これにより、バックエンドは請求サイクルなどの長期間にわたるユーザーの請求合計額を追跡・表示できるようになります。
+
+以下のパイプライン設定では、コネクターのエクスポーターを traces セクションに追加し、コネクターのレシーバーを metrics セクションに追加します。
+
+{{% exercise title="コネクターをパイプラインに組み込む" %}}
+
+- **Count Connector をパイプラインに設定する**
+
+```yaml
+ pipelines:
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - attributes/update # Update, hash, and remove attributes
+ - redaction/redact # Redact sensitive fields using regex
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file
+ - otlphttp
+ - sum # Sum connector which aggregates payment.amount from spans and sends to metrics pipeline
+ metrics:
+ receivers:
+ - sum # Receives metrics from the sum exporter in the traces pipeline
+ - count # Receives count metric from logs count exporter in logs pipeline.
+ - otlp
+ #- hostmetrics # Host Metrics Receiver
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - otlphttp
+ logs:
+ receivers:
+ - otlp
+ - filelog/quotes
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - transform/logs # Transform logs processor
+ - batch
+ exporters:
+ - count # Count Connector that exports count as a metric to metrics pipeline.
+ - debug
+ - otlphttp
+```
+
+- **[otelbin.io](https://www.otelbin.io/)** を使って Agent の設定を **検証** します。参考として、パイプラインの `traces` および `metrics:` セクションは次のような図になります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1(otlp
fa:fa-download
):::receiver
+ REC3(otlp
fa:fa-download
):::receiver
+ PRO1(memory_limiter
fa:fa-microchip
):::processor
+ PRO2(memory_limiter
fa:fa-microchip
):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(resource
fa:fa-microchip
add_mode):::processor
+ PRO5(batch
fa:fa-microchip
):::processor
+ PRO6(batch
fa:fa-microchip
):::processor
+ PRO7(resourcedetection
fa:fa-microchip
):::processor
+ PRO8(resourcedetection
fa:fa-microchip
):::processor
+
+ PROA(attributes
fa:fa-microchip
redact):::processor
+ PROB(redaction
fa:fa-microchip
update):::processor
+ EXP1( debug
fa:fa-upload
):::exporter
+ EXP2( file
fa:fa-upload
):::exporter
+ EXP3( debug
fa:fa-upload
):::exporter
+ EXP4( otlphttp
fa:fa-upload
):::exporter
+ EXP5( otlphttp
fa:fa-upload
):::exporter
+ ROUTE1( sum
fa:fa-route
):::con-export
+ ROUTE2( count
fa:fa-route
):::con-receive
+ ROUTE3( sum
fa:fa-route
):::con-receive
+
+ %% Links
+ subgraph wrapper[" "]
+ direction LR
+ subgraph subID1["`**Traces**`"]
+ direction LR
+ REC1 --> PRO1
+ PRO1 --> PROA
+ PROA --> PROB
+ PROB --> PRO7
+ PRO7 --> PRO3
+ PRO3 --> PRO5
+ PRO5 --> EXP1
+ PRO5 --> EXP2
+ PRO5 --> EXP5
+ PRO5 --> ROUTE1
+ end
+
+ subgraph subID2["`**Metrics**`"]
+ direction LR
+ ROUTE1 --> ROUTE3
+ ROUTE3 --> PRO2
+ ROUTE2 --> PRO2
+ REC3 --> PRO2
+ PRO2 --> PRO8
+ PRO8 --> PRO4
+ PRO4 --> PRO6
+ PRO6 --> EXP3
+ PRO6 --> EXP4
+ end
+ end
+ class subID1 sub-traces
+ class subID2 sub-metrics
+
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-logs stroke:#34d399,stroke-width:1px,color:#34d399,stroke-dasharray: 3 3;
+classDef sub-traces stroke:#fbbf24,stroke-width:1px,color:#fbbf24,stroke-dasharray: 3 3;
+classDef sub-metrics stroke:#38bdf8,stroke-width:1px,color:#38bdf8,stroke-dasharray: 3 3;
+```
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md
new file mode 100644
index 0000000000..99b6e3b490
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md
@@ -0,0 +1,67 @@
+---
+title: 7.3 Count Connector のテスト
+linkTitle: 7.3 Sum Connector のテスト
+weight: 3
+---
+
+{{% exercise title="Sum Connector のテスト" %}}
+
+**Gateway を起動します**:
+**Gateway terminal** ウィンドウで次のコマンドを実行します。
+
+```bash { title="Start the Gateway" }
+../otelcol --config=gateway.yaml
+```
+
+**Agent を起動します**:
+**Agent terminal** ウィンドウで次のコマンドを実行します。
+
+```bash { title="Start the Agent" }
+../otelcol --config=agent.yaml
+```
+
+**Loadgen を起動します**:
+**Spans terminal** ウィンドウで、次の `loadgen` コマンドを使用して 8 個のスパンを送信します。
+
+```bash { title="Loadgen" }
+../loadgen -count 8
+```
+
+**Agent** と **Gateway** の両方がデバッグ情報を表示し、データを処理していることを示します。loadgen が完了するまでお待ちください。
+
+**メトリクスを確認します**:
+スパンの処理中に、**Agent** はメトリクスを生成し、**Gateway** に渡しています。**Gateway** はそれらを `gateway-metrics.out` に書き込んでいます。
+
+メトリクス出力に `user.card-charge` が存在することを確認し、それぞれが `user.name` 属性を持っていることを検証するために、次の jq クエリを実行します。
+
+{{% tabs %}}
+{{% tab title="jq query command" %}}
+
+```bash
+
+jq -r '.resourceMetrics[].scopeMetrics[].metrics[] | select(.name == "user.card-charge") | .sum.dataPoints[] | "\(.attributes[] | select(.key == "user.name").value.stringValue)\t\(.asDouble)"' gateway-metrics.out | while IFS=$'\t' read -r name charge; do
+ printf "%-20s %s\n" "$name" "$charge"
+done
+```
+
+{{% /tab %}}
+{{% tab title="jq example output" %}}
+
+```text
+George Lucas 67.49
+Frodo Baggins 87.14
+Thorin Oakenshield 90.98
+Luke Skywalker 51.37
+Luke Skywalker 65.56
+Thorin Oakenshield 67.5
+Thorin Oakenshield 66.66
+Peter Jackson 94.39
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+> [!IMPORTANT]
+> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止します。
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md
new file mode 100644
index 0000000000..a26ae0a7b6
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md
@@ -0,0 +1,192 @@
+---
+title: 7. Count Connector でメトリクスを作成する
+linkTitle: 7. Count & Sum Connector
+time: 10 minutes
+weight: 9
+---
+このセクションでは、[**Count Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/countconnector) を使用して、ログから属性値を抽出し、意味のあるメトリクスに変換する方法を探ります。
+
+具体的には、Count Connector を使用してログに出現する「Star Wars」と「Lord of the Rings」の引用回数を追跡し、計測可能なデータポイントに変換します。
+
+{{% exercise title="`7-sum-count` ディレクトリのセットアップ" %}}
+
+> [!IMPORTANT]
+> **_すべての_ ターミナルウィンドウを `7-sum-count` ディレクトリに切り替え、`clear` コマンドを実行してください。**
+
+`6-routing-data` ディレクトリから `*.yaml` を `7-sum-count` にコピーします。更新後のディレクトリ構造は次のようになります。
+
+```text { title="Updated Directory Structure" }
+.
+├── agent.yaml
+└── gateway.yaml
+```
+
+- **agent.yaml を更新** して、ログを読み取る頻度を変更します。
+`agent.yaml` 内の `filelog/quotes` レシーバーを見つけて、`poll_interval` 属性を追加してください。
+
+```yaml
+ filelog/quotes: # Receiver Type/Name
+ poll_interval: 10s # Only read every ten seconds
+```
+
+{{% /exercise %}}
+
+遅延を設ける理由は、OpenTelemetry Collector の Count Connector が各処理間隔内のログのみをカウントするためです。つまり、データが読み取られるたびに、次の間隔のためにカウントがゼロにリセットされます。デフォルトの `Filelog reciever` の間隔である 200ms では、loadgen が書き込むすべての行を読み取り、カウントが 1 になってしまいます。この間隔を設定することで、カウント対象のエントリが複数になることを保証します。
+
+Collector は、以下に示すように条件を省略することで、各読み取り間隔のランニングカウントを維持できます。ただし、ランニングカウントはより長い期間にわたって追跡できるバックエンドに任せるのがベストプラクティスです。
+
+{{% exercise title="Count Connector の追加" %}}
+
+- **Count Connector の追加**
+
+設定の connectors セクションに Count Connector を含め、使用するメトリクスカウンターを定義します。
+
+```yaml
+connectors:
+ count:
+ logs:
+ logs.full.count:
+ description: "Running count of all logs read in interval"
+ logs.sw.count:
+ description: "StarWarsCount"
+ conditions:
+ - attributes["movie"] == "SW"
+ logs.lotr.count:
+ description: "LOTRCount"
+ conditions:
+ - attributes["movie"] == "LOTR"
+ logs.error.count:
+ description: "ErrorCount"
+ conditions:
+ - attributes["level"] == "ERROR"
+```
+
+- **メトリクスカウンターの説明**
+
+ - `logs.full.count`: 各読み取り間隔で処理されたログの総数を追跡します。
+ このメトリクスにはフィルタリング条件がないため、システムを通過するすべてのログがカウントに含まれます。
+ - `logs.sw.count` Star Wars 映画の引用を含むログをカウントします。
+ - `logs.lotr.count`: Lord of the Rings 映画の引用を含むログをカウントします。
+ - `logs.error.count`: 読み取り間隔内で重大度レベルが ERROR のログをカウントすることで、現実世界のシナリオを表現します。
+
+- **パイプラインで Count Connector を構成する**
+以下のパイプライン構成では、コネクターのエクスポーターが `logs` セクションに追加され、コネクターのレシーバーが `metrics` セクションに追加されています。
+
+```yaml
+ pipelines:
+ traces:
+ receivers:
+ - otlp
+ processors:
+ - memory_limiter
+ - attributes/update # Update, hash, and remove attributes
+ - redaction/redact # Redact sensitive fields using regex
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - file
+ - otlphttp
+ metrics:
+ receivers:
+ - count # Count Connector that receives count metric from logs count exporter in logs pipeline.
+ - otlp
+ #- hostmetrics # Host Metrics Receiver
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - batch
+ exporters:
+ - debug
+ - otlphttp
+ logs:
+ receivers:
+ - otlp
+ - filelog/quotes
+ processors:
+ - memory_limiter
+ - resourcedetection
+ - resource/add_mode
+ - transform/logs # Transform logs processor
+ - batch
+ exporters:
+ - count # Count Connector that exports count as a metric to metrics pipeline.
+ - debug
+ - otlphttp
+```
+
+{{% /exercise %}}
+
+ログは属性に基づいてカウントします。ログデータが属性ではなくログ本文に格納されている場合は、パイプラインで `Transform` プロセッサーを使用してキー/値のペアを抽出し、属性として追加する必要があります。
+
+このワークショップでは、`05-transform-data` セクションですでに `merge_maps(attributes, cache, "upsert")` を追加しています。これにより、処理に必要なすべての関連データがログ属性に含まれることが保証されます。
+
+属性を作成するフィールドを選択する際は注意が必要です。すべてのフィールドを無差別に追加することは、本番環境では一般的に望ましくありません。代わりに、不要なデータの乱雑さを避けるため、本当に必要なフィールドのみを選択してください。
+
+{{% exercise title="エージェント設定の検証" %}}
+
+- **[otelbin.io](https://www.otelbin.io/)** を使用してエージェント設定を **検証** してください。参考までに、パイプラインの `logs` および `metrics:` セクションは次のようになります。
+
+```mermaid
+%%{init:{"fontFamily":"monospace"}}%%
+graph LR
+ %% Nodes
+ REC1(otlp
fa:fa-download):::receiver
+ REC2(filelog
fa:fa-download
quotes):::receiver
+ REC3(otlp
fa:fa-download):::receiver
+ PRO1(memory_limiter
fa:fa-microchip):::processor
+ PRO2(memory_limiter
fa:fa-microchip):::processor
+ PRO3(resource
fa:fa-microchip
add_mode):::processor
+ PRO4(resource
fa:fa-microchip
add_mode):::processor
+ PRO5(batch
fa:fa-microchip):::processor
+ PRO6(batch
fa:fa-microchip):::processor
+ PRO7(resourcedetection
fa:fa-microchip):::processor
+ PRO8(resourcedetection
fa:fa-microchip):::processor
+ PRO9(transfrom
fa:fa-microchip
logs):::processor
+ EXP1( debug
fa:fa-upload):::exporter
+ EXP2( otlphttp
fa:fa-upload):::exporter
+ EXP3( debug
fa:fa-upload):::exporter
+ EXP4( otlphttp
fa:fa-upload):::exporter
+ ROUTE1( count
fa:fa-route):::con-export
+ ROUTE2( count
fa:fa-route):::con-receive
+
+ %% Links
+ subID1:::sub-logs
+ subID2:::sub-metrics
+ subgraph " "
+ direction LR
+ subgraph subID1[**Logs**]
+ direction LR
+ REC1 --> PRO1
+ REC2 --> PRO1
+ PRO1 --> PRO7
+ PRO7 --> PRO3
+ PRO3 --> PRO9
+ PRO9 --> PRO5
+ PRO5 --> ROUTE1
+ PRO5 --> EXP1
+ PRO5 --> EXP2
+ end
+
+ subgraph subID2["`**Metrics**`"]
+ direction LR
+ ROUTE1 --> ROUTE2
+ ROUTE2 --> PRO2
+ REC3 --> PRO2
+ PRO2 --> PRO8
+ PRO8 --> PRO4
+ PRO4 --> PRO6
+ PRO6 --> EXP3
+ PRO6 --> EXP4
+ end
+ end
+classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
+classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
+classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
+classDef sub-logs stroke:#34d399,stroke-width:1px, color:#34d399,stroke-dasharray: 3 3;
+classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;
+```
+
+{{% /exercise %}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md
new file mode 100644
index 0000000000..fc0ba8599e
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md
@@ -0,0 +1,7 @@
+---
+title: 8. まとめ
+linkTitle: 8. まとめ
+weight: 10
+---
+
+
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md
new file mode 100644
index 0000000000..bf2bb0a297
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md
@@ -0,0 +1,35 @@
+---
+title: Advanced OpenTelemetry Collector
+description: OpenTelemetry Collector の設定をゼロから構築する練習を行い、いくつかの高度な設定シナリオを通して学習します。
+weight: 2
+type: chapter
+authors: ["Robert Castley", "Charity Anderson", "Pieter Hagen", "Geoff Higginbottom"]
+time: 75 minutes
+---
+
+このワークショップの目的は、OpenTelemetry Collector の設定ファイルの作成と変更に自信を持てるようにすることです。最小限の `agent.yaml` と `gateway.yaml` ファイルから始めて、段階的に拡張しながら、いくつかの高度な実践的シナリオに対応できるように構築していきます。
+
+このワークショップで重視するポイントは、テレメトリーデータをサードパーティベンダーのバックエンドに送信するのではなく、ローカルに保存するように OpenTelemetry Collector を設定する方法を学ぶことです。このアプローチはデバッグやトラブルシューティングを容易にするだけでなく、本番システムへのデータ送信を避けたいテストや開発環境にも最適です。
+
+このワークショップを最大限に活用するためには、以下が必要です。
+
+- OpenTelemetry Collector とその設定ファイル構造に関する基本的な理解。
+- YAML ファイルの編集に関する習熟。
+
+このワークショップのすべての内容は、ローカルで実行できるように設計されており、ハンズオン形式でアクセスしやすい学習体験を提供します。それでは、構築を始めていきましょう！
+
+## Workshop Overview
+
+このワークショップでは、以下のトピックを取り上げます。
+
+- **agent と gateway をローカルにセットアップする**: メトリクス、トレース、ログが agent を経由して gateway に送られることをテストします。
+- **agent のレジリエンス強化**: フォールトトレランスのための基本的な設定。
+- **プロセッサーの設定**:
+ - 特定のスパン（例：ヘルスチェック）を破棄することでノイズをフィルタリングします。
+ - 不要なタグを削除し、機密データを取り扱います。
+ - エクスポート前に、パイプライン内で OTTL（OpenTelemetry Transformation Language）を使ってデータを変換します。
+- **コネクターの設定**:
+ - 受信した値に基づいて、異なるエンドポイントへデータをルーティングします。
+
+
+このワークショップを終える頃には、さまざまな実践的なユースケースに対応した OpenTelemetry Collector の設定に慣れているはずです。
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md
new file mode 100644
index 0000000000..ca373dc91f
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md
@@ -0,0 +1,175 @@
+---
+title: 前提条件
+weight: 2.1
+archetype: chapter
+time: 5 minutes
+---
+
+## 前提条件
+
+- `vi`、`vim`、`nano`、またはお好みのテキストエディターを使用してYAMLファイルを編集できること。
+- サポートされている環境:
+ - 提供されるSplunk Workshop Instance（推奨）。`ssh` アクセスのため、ポート `2222` への送信アクセスが必要です。
+ - Apple Mac (Apple Silicon)。`jq` のインストールが必要です - [**https://jqlang.org/download/**](https://jqlang.org/download/)
+
+{{% exercise title="ワークショップ用ディレクトリの作成" %}}
+
+{{< step "初期セットアップ" "1" >}}
+
+ご利用の環境で新しいディレクトリを作成し、そのディレクトリに移動します:
+
+``` bash
+mkdir advanced-otel-workshop && \
+cd advanced-otel-workshop
+```
+
+このディレクトリは、ワークショップの残りの部分で `[WORKSHOP]` として参照します。
+
+{{% notice title="既存のOpenTelemetry Collectorを削除する" style="warning" %}}
+Splunk IMワークショップを完了している場合、続行する前にKubernetes上で動作しているcollectorが削除されていることを確認してください。これは以下のコマンドを実行することで実施できます:
+
+``` bash
+helm delete splunk-otel-collector
+```
+
+その場合のEC2インスタンスでは、本ワークショップに干渉する可能性のあるサービスが動作している場合があるため、以下のコマンドを実行して、それらが存在する場合は確実に停止させてください:
+
+``` bash
+kubectl delete ~/workshop/apm/deployment.yaml
+```
+
+{{% /notice %}}
+{{< /step >}}
+
+{{< step "ワークショップのバイナリをダウンロード" "2" >}}
+
+`[WORKSHOP]` ディレクトリに移動し、OpenTelemetry Collector、Load Generatorのバイナリ、およびセットアップスクリプトをダウンロードします:
+
+{{% tabs %}}
+{{% tab title="Splunk Workshop Instance" %}}
+
+```bash
+curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v{{< otel-version >}}/otelcol_linux_amd64 -o otelcol && \
+curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-linux-amd64 -o loadgen && \
+curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/setup-workshop.sh -o setup-workshop.sh && \
+chmod +x setup-workshop.sh
+```
+
+{{% /tab %}}
+{{% tab title="Apple Silicon" %}}
+
+```bash
+curl -L https://github.com/signalfx/splunk-otel-collector/releases/download/v{{< otel-version >}}/otelcol_darwin_arm64 -o otelcol && \
+curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/loadgen/build/loadgen-darwin-arm64 -o loadgen && \
+curl -L https://github.com/splunk/observability-workshop/raw/refs/heads/main/workshop/ninja/advanced-otel/setup-workshop.sh -o setup-workshop.sh && \
+chmod +x setup-workshop.sh
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+{{< /step >}}
+
+{{< step "セットアップを実行する" "3" >}}
+`setup-workshop.sh` スクリプトを実行します。このスクリプトは正しい権限を設定するとともに、**Agent** および **Gateway** の初期設定を作成します:
+
+{{% tabs %}}
+{{% tab title="Setup Workshop" %}}
+
+```bash
+./setup-workshop.sh
+```
+
+{{% /tab %}}
+{{% tab title="Verify Setup" %}}
+
+```text
+███████╗██████╗ ██╗ ██╗ ██╗███╗ ██╗██╗ ██╗ ██╗
+██╔════╝██╔══██╗██║ ██║ ██║████╗ ██║██║ ██╔╝ ╚██╗
+███████╗██████╔╝██║ ██║ ██║██╔██╗ ██║█████╔╝ ╚██╗
+╚════██║██╔═══╝ ██║ ██║ ██║██║╚██╗██║██╔═██╗ ██╔╝
+███████║██║ ███████╗╚██████╔╝██║ ╚████║██║ ██╗ ██╔╝
+╚══════╝╚═╝ ╚══════╝ ╚═════╝ ╚═╝ ╚═══╝╚═╝ ╚═╝ ╚═╝
+
+Welcome to the Splunk Advanced OpenTelemetry Workshop!
+======================================================
+
+macOS detected. Removing quarantine attributes...
+otelcol version v0.126.0
+Usage: loadgen [OPTIONS]
+Options:
+ -base Send base traces (enabled by default)
+ -health Send health traces
+ -security Send security traces
+ -logs Enable logging of random quotes to quotes.log
+ -json Output logs in JSON format (only applicable with -logs)
+ -count Number of traces or logs to send (default: infinite)
+ -h, --help Display this help message
+
+Example:
+ loadgen -health -security -count 10 Send 10 health and security traces
+ loadgen -logs -json -count 5 Write 5 random quotes in JSON format to quotes.log
+Creating workshop directories...
+✓ Created subdirectories:
+ ├── 1-agent-gateway
+ ├── 2-building-resilience
+ ├── 3-dropping-spans
+ ├── 4-sensitive-data
+ ├── 5-transform-data
+ ├── 6-routing-data
+ └── 7-sum-count
+
+Creating configuration files for 1-agent-gateway...
+Creating OpenTelemetry Collector agent configuration file: 1-agent-gateway/agent.yaml
+✓ Configuration file created successfully: 1-agent-gateway/agent.yaml
+✓ File size: 4355 bytes
+
+Creating OpenTelemetry Collector gateway configuration file: 1-agent-gateway/gateway.yaml
+✓ Configuration file created successfully: 1-agent-gateway/gateway.yaml
+✓ File size: 3376 bytes
+
+✓ Completed configuration files for 1-agent-gateway
+
+Creating configuration files for 2-building-resilience...
+Creating OpenTelemetry Collector agent configuration file: 2-building-resilience/agent.yaml
+✓ Configuration file created successfully: 2-building-resilience/agent.yaml
+✓ File size: 4355 bytes
+
+Creating OpenTelemetry Collector gateway configuration file: 2-building-resilience/gateway.yaml
+✓ Configuration file created successfully: 2-building-resilience/gateway.yaml
+✓ File size: 3376 bytes
+
+✓ Completed configuration files for 2-building-resilience
+
+Workshop environment setup complete!
+Configuration files created in the following directories:
+ 1-agent-gateway/
+ ├── agent.yaml
+ └── gateway.yaml
+ 2-building-resilience/
+ ├── agent.yaml
+ └── gateway.yaml
+```
+
+{{% /tab %}}
+{{% /tabs %}}
+
+```text { title="Initial Directory Structure" }
+[WORKSHOP]
+├── 1-agent-gateway
+├── 2-building-resilience
+├── 3-dropping-spans
+├── 4-sensitive-data
+├── 5-transform-data
+├── 6-routing-data
+├── 7-sum-count
+├── loadgen
+├── otelcol
+└── setup-workshop.sh
+```
+
+{{< /step >}}
+
+{{% /exercise %}}
+
+{{< checkpoint "ワークショップ環境の準備が完了しました — **第1章: Agent Configuration** へ進みましょう。" >}}
diff --git a/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/_index.md b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/_index.md
new file mode 100644
index 0000000000..ea18a89f82
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/3-opentelemetry-collector-workshops/_index.md
@@ -0,0 +1,9 @@
+---
+title: OpenTelemetry Collector ワークショップ
+weight: 3
+time: 2 hours 15 minutes
+description: OpenTelemetry Collector を 2 部構成で深く掘り下げます。前半では receiver / processor / exporter の基礎を学び、後半では実践的なシナリオを通じて agent および gateway の構成をゼロから構築します。
+aliases:
+ - /ninja-workshops/3-opentelemetry-collector-workshops/
+layout: "hero"
+---
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/_index.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/_index.md
new file mode 100644
index 0000000000..e2d315d99a
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/_index.md
@@ -0,0 +1,42 @@
+---
+title: Dashboard Workshop
+description: Splunk Observability Cloud でカスタムダッシュボードを構築します — チャート、フィルター、分析関数、SignalFlow 数式。
+weight: 7
+archetype: chapter
+authors: ["Pieter Hagen"]
+time: 45 minutes
+draft: false
+aliases:
+ - /ninja-workshops/7-dashboards-detectors/
+---
+Splunk Observability Cloud の **Dashboards** に関するワークショップへようこそ。このセッションでは、洞察に富んだビジュアライゼーションの構築をハンズオンで体験していただけます。
+
+
+
+Splunk Observability Suite で利用可能な既存のデモデータを使って作業を進めます。アクセス可能な **trial** または **production** の Splunk Observability 組織であれば、どれでも使ってこのワークショップを進めることができます。
+
+## このワークショップで学ぶこと
+
+### Dashboards
+
+ワークショップの前半では、ダッシュボードとチャートに焦点を当てます。
+
+* ダッシュボードの理解とチャートの役割
+* 既存チャートの編集と新規チャートの作成
+* フィルターの適用と分析関数の利用
+* 数式の構築とカスタマイズ
+* 再利用するためのダッシュボードへのチャート保存
+* 高度なチャート作成のための SignalFlow 入門
+
+
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-01-sample_data.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-01-sample_data.md
new file mode 100644
index 0000000000..e7ae68282a
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-01-sample_data.md
@@ -0,0 +1,27 @@
+---
+title: サンプルデータの場所を確認する
+linkTitle: 1.01. Sample Data
+weight: 1.01
+time: 10 minutes
+---
+
+## 1. サンプルデータを探索する
+
+利用可能なダッシュボードの一覧から、**Sample Data (2)** という名前のグループを探します。
+
+このグループには、サンプルメトリクスを使用して構築された可視化を紹介するダッシュボードが含まれています。これらのダッシュボードを通じて、Splunk Observability のチャートやダッシュボードでさまざまなデータをどのように表現できるかを把握できます。
+
+
+
+---
+
+**Sample Data** ダッシュボードグループをクリックして展開し、**Sample Charts (3)** ダッシュボードを選択します。
+
+このダッシュボードでは、Splunk Observability で利用できるさまざまなチャートタイプ、スタイル、フォーマットオプションを紹介しています。ダッシュボードがいかに柔軟でカスタマイズ可能かを体感するのに最適です。
+
+サンプルデータは 10 分周期で動作し、時間の経過とともに異なるパターンや挙動を生成します。
+これらの変化を実際に確認するには、ダッシュボード右上の時間範囲を **Last 15 minutes** に変更するか、より広い範囲で確認したい場合は **Last 1 hour** を選択してください。これにより、データが更新され、さまざまな状態を周期的に変化していく様子を観察できます。
+
+少し時間を取ってこのダッシュボード内のチャートを探索してみてください。それぞれが、サンプルデータをどのように可視化できるかについて異なる視点を提供しています。
+
+
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-02-exploring_charts.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-02-exploring_charts.md
new file mode 100644
index 0000000000..027df61d54
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-02-exploring_charts.md
@@ -0,0 +1,42 @@
+---
+title: Exploring Charts
+linkTitle: 1.02. Exploring Charts
+weight: 1.02
+---
+このセクションでは、Splunk Observability におけるチャートの構築方法と表示方法を確認していきます。既存のチャートを観察し操作することで、チャートエディタの動作の仕組み（データソースの選択方法、ビジュアルオプションの構成方法、各種設定が表示にどう影響するか）を体感できます。
+
+## 1. チャートを選択する
+
+まずは **SAMPLE CHARTS** ダッシュボードを開いた状態にし、ダッシュボード右上の時間範囲を **-5M** (Last 5 Minutes) に戻すか、**reset to default** を選択してください。
+
+**Latency histogram** チャートを見つけ、チャート右上の **三点リーダー** (...) **(1)** をクリックします。メニューから **Open (3)** を選択します。あるいは、チャートタイトル（**Latency histogram**）**(2)** を直接クリックして開くこともできます。
+
+
+
+---
+チャートエディタが開くと、Latency histogram チャートの構成設定が表示されます。
+
+チャートエディタは、データの可視化方法を制御するための場所です。チャートタイプの変更、変換関数の適用、時間設定の調整、その他のビジュアル関連やデータ関連のオプションを、目的に合わせてカスタマイズできます。
+
+
+
+---
+
+**Plot Editor (1)** タブの **Signal (2)** セクションには、現在使用されているメトリクス `demo.trans.latency` **(3)** が表示されています。このシグナルは、チャートでプロットされているレイテンシーデータを表しています。このエリアでは、シグナルを編集したり、比較や情報の追加のために別のシグナルを追加したりできます。
+
+チャートには、複数の **Line** プロットが表示されていることがわかります。`18 ts` **(4)** というラベルは、チャートが現在 **18 個の個別のメトリクス時系列** をプロットしていることを示しています。
+
+
+さまざまな可視化スタイルを試すために、エディタにある各チャートタイプのアイコンをクリックしてみてください。各アイコンにマウスカーソルを合わせると名前が表示され、それぞれのタイプが何を表しているかを把握できます。
+
+
+
+たとえば、**Heat Map** アイコンをクリックして、同じデータが別の形式でどのように表現されるかを確認してみましょう。
+
+
+
+{{% notice title="Note" style="info" %}}
+メトリクスはさまざまなチャートタイプで可視化できます。強調したいインサイトを最もよく表すものを選んでください。
+
+利用可能なチャートタイプとその使い分けの詳細については、[Choosing a chart type.](https://docs.splunk.com/Observability/data-visualization/charts/chart-types.html#chart-types) を参照してください。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-03-editing-chart.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-03-editing-chart.md
new file mode 100644
index 0000000000..0a75222958
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-03-editing-chart.md
@@ -0,0 +1,45 @@
+---
+title: Editing Charts
+linkTitle: 1.04. Editing Charts
+weight: 1.04
+---
+このセクションでは、既存のチャートを編集することで、チャートがどのように構成されているかを探っていきます。これは、チャートエディターを実際に操作しながら、チャートの設定、データソース、可視化オプションがどのように組み合わさっているかを理解するうえで最適な方法です。
+
+---
+**Latency histogram** チャートをチャートエディターで開いた状態で、ワークショップ用の設定を始めましょう。
+
+**visualization** ペインの **Line chart** タイプアイコン **(1)** をクリックして、チャートタイプを変更します。データが折れ線プロットとして表示されるようになります。
+
+
+
+## 2. チャートの時間ウィンドウの変更
+
+チャートの時間範囲を調整して、より過去のデータを表示できます。これを行うには、チャートエディター右上隅の **Time (1)** ドロップダウンをクリックし、**Past 15 minutes (2)** を選択します。
+
+これにより時間ウィンドウが拡大され、より長い期間にわたるメトリクスの傾向を確認できるようになります。
+
+
+
+## 3. データテーブルの探索
+
+チャートエディターの **Data Table (1)** タブをクリックします。
+
+**Data Table** では、チャートを支えているメトリクス時系列の内部を確認できます。
+
+
+
+テーブルの各行は1つの時系列を表し、各列はその時系列に関連付けられたディメンションを示します。メトリクス `demo.trans.latency` には、以下のディメンションが表示されます:
+
+- `demo_datacenter` **(2)**
+- `demo_customer` **(3)**
+- `demo_host` **(4)**
+
+**`demo_datacenter`** 列には、2つのデータセンター: **Paris (5)** と **Tokyo (6)** があることがわかります。
+それぞれに複数の時系列が関連付けられています。
+
+カーソルをチャート上で（時間軸方向に水平に）移動させると、**Data Table** はリアルタイムで更新され、現在の時点の値が反映されます。チャート内の特定の線をクリックすると、その時系列がテーブル上にピン留めされ、固定値が表示されます。これは **pinned value (7)** で示されます。
+
+---
+準備ができたら、**Plot editor (8)** タブをクリックしてデータテーブルを閉じます。
+
+次に、後で再利用できるように、このチャートをダッシュボードに保存しましょう！
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-04-saving-charts.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-04-saving-charts.md
new file mode 100644
index 0000000000..ede2c4ce68
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-04-saving-charts.md
@@ -0,0 +1,67 @@
+---
+title: チャートとダッシュボードの保存
+linkTitle: 1.04. チャートの保存
+weight: 1.04
+---
+
+ニーズに合わせてチャートをカスタマイズしたら、次のステップとしてダッシュボードの一部として保存します。作成したチャートを保存することで、再利用、共有、そして時間の経過とともに重要な可視化を監視することが可能になります。このセクションでは、チャートに名前と説明を付ける方法、および後で簡単にアクセスできるようにダッシュボードに追加する方法を学びます。
+
+## 1. チャートの保存
+
+まず、チャートを保存するために、わかりやすい名前と説明を付けましょう。
+
+現在 **Copy of Latency Histogram** とラベル付けされているチャートタイトルをクリックし、**「Active Latency」(1)** に名前を変更します。
+
+次に、チャートの説明を更新します。既存のテキスト **Spread of latency values across time** をクリックし、以下のように変更します：
+**Overview of latency values in real-time**。**(2)**
+
+これらの更新により、チャートが大規模なダッシュボードの一部となったり、他の人と共有されたりした際に、識別と理解が容易になります。
+
+
+
+{{% button style="blue" %}}Save As{{% /button %}} **(3**) ボタンをクリックして、保存プロセスを開始します。チャートには先ほど設定した **Active Latency** という名前が使用されますが、必要に応じてここで名前を更新することもできます。
+
+準備ができたら、{{% button style="blue" %}}Ok{{% /button %}} **(1)**
+ ボタンをクリックして確認し、続行します。
+
+
+
+## 2. ダッシュボードの作成
+
+これでチャートを保存できるようになりましたが、それを保存する場所、つまり**ダッシュボード**が必要です。
+
+ダッシュボードは、関連するチャートを整理してグループ化するのに役立ち、重要なメトリクスを 1 つのビューで監視しやすくします。このワークショップでは、これから構築するチャートを格納するための**新しいダッシュボード**を作成します。
+
+**Choose dashboard** ダイアログで、{{% button style="blue" %}}New Dashboard{{% /button %}} **(1)** ボタンをクリックします。
+
+**重要**: 既存のダッシュボードを選択しないでください。この演習では必ず新しいダッシュボードを作成してください。
+
+
+
+**New Dashboard** ダイアログが表示され、新しいダッシュボードの詳細を設定できます。
+
+まず、ダッシュボードに名前を付けます。このワークショップでは、次の形式を使用します：**YOUR_NAME-Dashboard**
+**YOUR_NAME** をご自身の名前に置き換えて、ダッシュボードを識別しやすくしてください。
+
+次に、**permissions** を更新します。**Restricted Read and Write access** に設定し、自分（または特定のユーザー）のみがダッシュボードを表示および変更できるようにします。ご自身のユーザーアカウントが含まれており、読み取りと書き込みの両方のアクセス権を持っていることを確認してください。
+
+
+
+これで、permissions に自分のユーザーアカウントが表示されるはずです。これは、**現在このダッシュボードを編集できるのは自分だけである**ことを意味します。
+
+必要に応じて、下のドロップダウンから追加のユーザーやチームを選択して追加できます。
+
+このワークショップの目的のため、制限を解除しましょう。セッション中にアクセスが制限されないように、permissions の設定を ***Everyone can Read and Write*** に変更します。
+
+
+
+{{% button style="blue" %}}Save{{% /button %}} ボタンをクリックして続行します。
+新しいダッシュボードが作成され、自動的に選択されるため、チャートを直接そのダッシュボードに保存できます。
+
+
+
+新しく作成したダッシュボードが選択されていることを確認し **(1)**、{{% button style="blue" %}}Ok{{% /button %}} ボタン **(2)** をクリックして続行します。
+
+これでダッシュボードに移動します。左上隅に、**YOUR_NAME-DASHBOARD** が同じ名前のダッシュボードグループの一部として表示されます。このダッシュボードグループに追加のダッシュボードを追加して、さまざまなユースケース、システム、またはプロジェクトに関連するチャートを整理できます。
+
+
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-05-new-chart.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-05-new-chart.md
new file mode 100644
index 0000000000..b03be997fd
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-05-new-chart.md
@@ -0,0 +1,28 @@
+---
+title: Create New Chart
+linkTitle: 1.05. Create New Chart
+weight: 1.05
+---
+
+### 1 新しいチャートの作成
+
+それでは、新しいチャートを作成し、これまで作業してきたダッシュボードに追加してみましょう。
+
+まず、画面上部中央のプラスアイコン **(1)** をクリックします。ドロップダウンから **Chart (2)** を選択してください。
+あるいは、{{< button style="blue">}}+ New Chart{{< /button >}} ボタン **(3)** をクリックすることで、直接新しいチャートを作成することもできます。
+
+
+
+これで、設定可能な空のチャートテンプレートが表示されます:
+
+
+
+可視化するメトリクスを追加することから始めましょう。今回の例では、これまでと同じく **`demo.trans.latency`** を引き続き使用します。
+
+**Plot Editor (1)** の **Signal (2)** セクションに移動し、入力フィールドに **`demo.trans.latency`(3)** を入力します。これにより、レイテンシーの時系列データがチャートに読み込まれ、可視化の構築とカスタマイズを開始できるようになります。
+
+
+
+これで、見慣れたラインチャートに **18 個の時系列 (4)** が表示されているはずです。最近のアクティビティを確認するには、**Time dropdown (1)** から **Past 15 minutes** を選択して時間範囲を変更してください。
+
+
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-06-filtering.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-06-filtering.md
new file mode 100644
index 0000000000..bbab1a1fbf
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-06-filtering.md
@@ -0,0 +1,37 @@
+---
+title: Using Filters & Analytics
+linkTitle: 1.06. Filters & Analytics
+weight: 1.06
+---
+
+### 1. フィルタリングと分析
+
+**Splunk Observability** では、**フィルター**と**分析関数**を活用することで、大量のメトリックデータを簡単に探索できます。フィルターは特定のサービス、ホスト、ロケーションなど、データの特定のセグメントに焦点を絞り込むのに役立ち、分析関数はそのデータを変換・分析してより深い洞察を得るために使用します。
+
+ここでは **Paris データセンター**にデータを絞り込むことで、よりターゲットを絞った分析を適用できるようにします。これは**フィルター**を使用して行います。
+
+まず **Plot Editor** タブに戻ります。下のスクリーンショットに示すように、{{% button style="blue" %}}Add Filter{{% /button %}} ボタン **(2)** をクリックします。
+
+利用可能なディメンションが表示されるまで少し待ちます。次に、以下を実行します:
+
+* フィルターのディメンションとして **demo_datacenter (1)** を選択します。
+* フィルタリングする値として **Paris (2)** を選択します。
+
+このフィルターにより、チャートには Paris データセンターからのタイムシリーズのみが表示されるようになり、分析がより焦点を絞った意義のあるものになります。
+
+
+
+---
+チャートエディターの **F(x) (1)** カラムで、{{% button style="blue" %}}Add Analytics{{% /button %}} ボタンをクリックして分析関数を適用します。
+ドロップダウンリストから **`Percentile` (2)** を選択し、続いて **`Percentile:Aggregation` (3)** オプションを選択します。
+表示されるパネルでは、パーセンタイル値を 90 のままにしておきます。これにより、選択したタイムシリーズの 90 パーセンタイルがチャートに表示されます。
+
+このコンテキストにおいて、90 パーセンタイルとは、レイテンシー測定値の 90% がそれを下回る値、言い換えれば、**最も高い 10%** の値だけがこのポイントを超えるという値を表します。これは「最悪のケースとしての通常値」のパフォーマンスを理解するのに有用な方法であり、時折発生するスパイクを除外しつつ、レイテンシーが許容できないレベルに近づいているときには表示されます。
+
+関数を適用するには、パネルの外側の任意の場所をクリックして選択を確定するだけです **(4)**。
+
+
+
+**Percentile** 関数およびその他の関数の詳細については、[Chart Analytics](https://docs.splunk.com/Observability/data-visualization/charts/gain-insights-through-chart-analytics.html#gain-insights-through-chart-analytics) を参照してください。
+
+---
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-07-timeshift.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-07-timeshift.md
new file mode 100644
index 0000000000..b3fd9f6d1e
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-07-timeshift.md
@@ -0,0 +1,57 @@
+---
+title: Using TimeShift & Formula's
+linkTitle: 1.07. TimeShift & Formula's
+weight: 1.07
+---
+
+### 1. Timeshift 分析関数の利用
+
+多くの場合、現在のパフォーマンスを過去のデータと比較することは有用です。たとえば、トレンド、リグレッション、または時間の経過に伴う改善を特定する際に役立ちます。**Timeshift** 関数を使用すると、時系列データを過去にシフトして、過去の値と現在の値を並べて表示できるため、この比較が簡単になります。
+
+まず、**Signal A** の横にある **`...`** メニュー **(1)** をクリックし、ドロップダウンから **Clone (2)** を選択して **Signal A** をクローンします。
+
+シグナルを **クローン** すると、同じメトリクス、フィルター、設定を持つ同一のコピーが作成されます。この複製（**Signal B**）は、元のシグナルを変更することなく、**Timeshift** を適用して 1 週間前のメトリクスがどのようなものだったかを可視化するなど、さらなる計算や比較に使用できます。
+
+
+---
+クローン後、**Signal B (1)** という名前の新しいシグナルが表示されます。これは **Signal A** の正確なコピーであるため、両方のシグナルは同じ時間範囲で同じデータを表示します。その結果、チャート上で **完全に重なって** 表示され、1 本の線しか存在しないように見えます。
+
+比較を意味のあるものにするため、**Signal B** に **Timeshift** を適用して、そのデータを 1 週間前にシフトさせます。これにより、現在のレイテンシのトレンドを先週の同時刻のトレンドと比較できるようになります。
+
+Signal B の横にある **F(x)** 列で {{% button style="blue" %}} **+** {{% /button %}} **(2)** をクリックし、リストから **Timeshift (3)** 関数を選択します。
+
+
+---
+プロンプトが表示されたら、タイムシフト値として **1w**（または 7 日の場合は **7d**）**(4)** を入力します。パネルの外側 **(5)** をクリックして変更を確定します。
+
+これにより、**Signal B** のデータが 1 週間前にシフトされ、現在のレイテンシのトレンドを先週の同時刻のトレンドと視覚的に比較できるようになります。
+
+
+---
+**Signal B** の色を変更するには、その行の右端にある ⚙️ 設定アイコン **(1)** をクリックして設定メニューを開きます。次に、**Plot Color** としてピンク **(2)** などを選択し、チャート上で **Signal B** を元のシグナルと視覚的に区別できるようにします。
+完了したら、{{% button style="gray" %}} Close {{% /button %}} **(3)** をクリックします。
+
+
+---
+これで、チャート上に 2 つのプロットが表示されるはずです。青色で表示された現在のレイテンシの *p90*（**Signal A**）と、ピンク色で表示された 1 週間前の *p90*（**Signal B**）です。
+
+両者の違いを解釈しやすくするため、**Area chart** アイコン **(1)** をクリックして可視化スタイルを変更します。これにより曲線の下の領域が強調され、先週のレイテンシが現在の値より高かった場合を見つけやすくなります。
+
+次に、Override バーの **Time (2)** の横にあるフィールドをクリックし、ドロップダウンから **Past Hour (3)** を選択して時間範囲を更新します。
+
+
+---
+
+### 2. Formulas（数式）の利用
+
+次に、さらに一歩進んで、2 つの時間シフトされたメトリクス値の差分を計算してみましょう。たとえば、本日のデータをちょうど 1 週間前のデータと比較します。
+
+行 **C (1)** で {{% button style=blue %}}Enter Formula{{% /button %}} ボタンをクリックし、**A - B** **(2)** と入力して **Signal A** から **Signal B** を引きます。これにより、**C** とラベル付けされた新しい計算済みシグナルが作成されます。
+
+この数式の結果のみに注目するため、**A (3)** と **B (4)** の横にある目のアイコンをクリックして他のシグナルを非表示にし、**C** のみが表示されるようにします。
+
+
+
+これで、現在のメトリクス値（**A**）と 1 週間前の値（**B**）の差分を表す 1 本の線が表示されるはずです。チャートでは、一部の値が負として表示される場合があります。これは、その時点で古いメトリクス（**B**）が現在のメトリクス（**A**）よりも高かった場合に発生します。
+
+ビジュアルチャート分析について見てきましたので、次のセクションでは内部に目を向け、チャートとディテクターを支える SignalFlow を確認していきましょう！
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-08-signalflow.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-08-signalflow.md
new file mode 100644
index 0000000000..09dd18d46d
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-08-signalflow.md
@@ -0,0 +1,54 @@
+---
+title: Using SignalFlow
+linkTitle: 1.08. Signalflow
+weight: 1.08
+---
+
+## 1. SignalFlow の紹介
+
+ここでは、Splunk Observability Cloud を支える強力な分析言語である **SignalFlow** について詳しく見ていきます。SignalFlow を使うと、監視ロジックをコードとして定義でき、メトリクスを柔軟かつリアルタイムに扱い、アラート発行を自動化できます。
+
+**Splunk Infrastructure Monitoring** の中核には、ストリーミングメトリクスデータをリアルタイムに処理する **SignalFlow analytics engine** があります。SignalFlow は Python に似た構文で記述し、**metric time series (MTS)** を入力として受け取り、変換や計算を行い、新しい MTS を出力する計算処理を構築できます。
+
+SignalFlow の代表的なユースケースには以下のようなものがあります。
+
+* 現在値と過去のトレンドの比較 (例: 週次比較)
+* 分散パーセンタイルチャートを使った母集団レベルの洞察の作成
+* 変化率やしきい値の監視 (例: Service Level Objective (SLO) 違反の検知)
+* 相関するディメンションの特定 (例: ディスク容量不足アラートの増加と関連するサービスの特定)
+
+SignalFlow ベースの計算処理は、メトリクスを選択し分析関数をビジュアル的に適用することで、**Chart Builder** インターフェイス上で直接作成できます。より高度なユースケースでは、**SignalFlow API** を使って SignalFlow プログラムを直接記述・実行することもできます。
+
+SignalFlow には時系列データに対して動作する豊富な組み込み関数が用意されており、複雑なシステム全体にわたる動的かつリアルタイムな監視に最適です。
+
+{{% notice title="Info" style="info" %}}
+SignalFlow の詳細については [Analyze incoming data using SignalFlow](https://docs.splunk.com/Observability/infrastructure/analytics/signalflow.html) を参照してください。
+{{% /notice %}}
+
+## 2. SignalFlow の表示
+
+Chart Builder で **View SignalFlow** をクリックすると、チャートを動かしている内部コードを開けます。
+
+
+
+**View SignalFlow** をクリックすると、チャートのロジックと変換処理を定義している **SignalFlow program (1)** が表示されます。このビューでは、可視化を支えているコードに直接アクセスできるため、ビジュアルエディタでは実現できない範囲の微調整や拡張が可能になります。
+
+以下は、先ほど作成したチャートの SignalFlow コードの例です。このスニペットでは、2 つのパーセンタイルシグナル (現在と 1 週間前) を定義し、タイムシフトを適用し、それらの差分を計算する方法を示しています。コードを確認することで、各ステップが最終的なチャートにどう寄与しているかを理解しやすくなります。
+
+{{< tabs >}}
+{{% tab title="SignalFlow" %}}
+
+```python
+A = data('demo.trans.latency', filter=filter('demo_datacenter', 'Paris')).percentile(pct=95).publish(label='A', enable=False)
+B = data('demo.trans.latency', filter=filter('demo_datacenter', 'Paris')).percentile(pct=95).timeshift('1w').publish(label='B', enable=False)
+C = (A-B).publish(label='C')
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+**View Builder (2)** をクリックすると、Chart **Builder** UI に戻れます。
+
+
+
+それでは、この新しいチャートをダッシュボードに保存しましょう。
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-09-adding-charts.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-09-adding-charts.md
new file mode 100644
index 0000000000..c512d39ff3
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-09-adding-charts.md
@@ -0,0 +1,68 @@
+---
+title: ダッシュボードへのチャート追加
+linkTitle: 1.09. チャートの追加
+weight: 1.09
+---
+
+## 1. 既存ダッシュボードへの保存
+
+チャートを保存する前に、左上の表示が **YOUR_NAME-Dashboard: YOUR_NAME-Dashboard (1)** になっていることを確認します。これにより、正しいダッシュボードにチャートが保存されます。
+
+次に、チャートに名前を付けます。**Latency History** **(2)** と入力し、必要に応じて **Chart Description (3)** に簡単な説明を例のように追加します。
+
+
+---
+準備ができたら、{{% button style=blue %}}Save And Close{{% /button %}} ボタン **(4)** をクリックします。ダッシュボードに戻り、チャートが 2 つ表示されているはずです。
+
+
+---
+
+## 2. チャートのコピーと貼り付け
+
+先ほど作成したチャートを複製して、もう一つチャートを素早く追加してみましょう。
+
+ダッシュボードで **Latency History** チャートを見つけ、チャート右上の三点リーダー **`...`** **(1)** をクリックします。メニューから **Copy (2)** を選択します。
+
+コピー後、ページ上部の **+** アイコン **(3)** の前に小さな白い **1** が表示されているのに気付くでしょう。これは、1 つのチャートが貼り付け可能な状態であることを示しています。
+
+
+---
+ページ上部の **+** アイコン **(1)** をクリックし、ドロップダウンメニューから **(2)** を選択します。
+その行の末尾にも **1** が表示されており、コピーされたチャートが追加可能な状態であることを確認できます。
+
+
+これにより、先ほどのチャートのコピーがダッシュボードに配置されます。
+
+
+---
+
+## 3. 貼り付けたチャートの編集
+
+複製したチャートを編集するには、ダッシュボード上のいずれかの **Latency History** チャートの三点リーダー **`...`** をクリックし、**Open** を選択します。または、チャートのタイトル **Latency History** を直接クリックしてエディタで開くこともできます。
+
+これにより、再びエディタ環境に移動します。
+
+まず、チャート右上の時間範囲を調整します。**Past 1 Hour (1)** に設定して、より広範囲な最近のデータを確認できるようにします。
+
+次に、チャートをカスタマイズして独自のものにします。**Signal A (2)** の隣の目のアイコンをクリックして再表示します。
+そして、**Signal C (3)** の目のアイコンをクリックして非表示にします。
+
+チャートのタイトルを *Latency history* から **Latency vs Load (4)** に変更し、必要に応じて更新された内容を反映するようにチャートの説明を追加または編集します **(5)**。
+
+
+---
+{{% button style=blue %}}Add Metric Or Event{{% /button %}} ボタンをクリックして新しいシグナルを作成します。表示される入力フィールドに `demo.trans.count` **(1)** と入力して選択し、**Signal D** として追加します。
+
+これにより、新しいシグナル **Signal D** がチャートに追加されます。これは処理中のアクティブなリクエスト数を表します。
+
+**Paris データセンター**にフォーカスするため、**demo_datacenter: Paris (2)** のフィルターを追加します。次に、Configure Plot ⚙️ **(3)** ボタンをクリックして、データの表示方法を調整します。**rollup** タイプを **Auto (Delta)** から **Rate/sec (4)** に変更し、1 秒あたりの受信リクエスト数を表示するようにします。
+
+最後に、シグナル名を `demo.trans.count` から `Latency vs Load` **(5)** に変更して、チャート内での役割をより明確に反映させます。
+
+
+
+最後に {{% button %}}Save And Close{{% /button %}} ボタンを押します。これでダッシュボードに戻り、3 つの異なるチャートが表示されるようになります！
+
+
+
+「instruction」ノートを追加して、チャートを整理しましょう！
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md
new file mode 100644
index 0000000000..883116babe
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md
@@ -0,0 +1,107 @@
+---
+title: ノートの追加とダッシュボードレイアウト
+linkTitle: 1.10 ノートとレイアウト
+weight: 1.10
+---
+
+## 1. ノートの追加
+
+ダッシュボードでは、利用者を支援する短い「説明」ペインを配置することがよくあります。{{% button %}}**New Text Note**{{% /button %}} ボタンをクリックして追加してみましょう。
+
+
+
+これによりノートエディターが開きます。
+
+
+
+テキスト以外の要素もノートに追加できるよう、Splunk ではこれらのノート/ペインで Markdown が使用できるようになっています。
+Markdown は、プレーンテキストを使ってフォーマット済みのテキストを作成するための軽量なマークアップ言語で、Web ページなどでよく利用されています。
+
+利用できる要素には以下が含まれます (ただしこれらに限定されません):
+
+* ヘッダー (様々なサイズ)
+* 強調スタイル
+* リストとテーブル
+* リンク。外部 Web ページ (ドキュメント等) や、他の Splunk IM ダッシュボードへの直接リンクなど
+
+以下は、ノートで使用できる上記の Markdown オプションの例です。
+
+{{% tab title="Sample Markdown text" %}}
+
+``` markdown
+# h1 Big headings
+
+###### h6 To small headings
+
+##### Emphasis
+
+**This is bold text**, *This is italic text* , ~~Strikethrough~~
+
+##### Lists
+
+Unordered
+
++ Create a list by starting a line with `+`, `-`, or `*`
+- Sub-lists are made by indenting 2 spaces:
+- Marker character change forces new list start:
+ * Ac tristique libero volutpat at
+ + Facilisis in pretium nisl aliquet
+* Very easy!
+
+Ordered
+
+1. Lorem ipsum dolor sit amet
+2. Consectetur adipiscing elit
+3. Integer molestie lorem at massa
+
+##### Tables
+
+| Option | Description |
+| ------ | ----------- |
+| chart | path to data files to supply the data that will be passed into templates. |
+| engine | engine to be used for processing templates. Handlebars is the default. |
+| ext | extension to be used for dest files. |
+
+#### Links
+
+[link to webpage](https://www.splunk.com)
+
+[link to dashboard with title](https://app.eu0.signalfx.com/#/dashboard/EaJHrbPAEAA?groupId=EaJHgrsAIAA&configId=EaJHsHzAEAA "Link to the Sample chart Dashboard!")
+```
+
+{{% /tab %}}
+
+コピーボタンで上記をコピーし、*Edit* ボックスに貼り付けてください。
+プレビューには、表示される見た目が示されます。
+
+---
+
+## 2. チャートの保存
+
+ノートチャートに名前を付けます。例では *Example text chart* を使用しました。次に {{% button style="blue" %}}Save And Close{{% /button %}} ボタンを押してください。
+
+
+
+ダッシュボードに戻ると、ノートが追加された状態になっています。
+
+
+
+---
+
+## 3. チャートの並び替えとサイズ変更
+
+チャートのデフォルトの順序やサイズが好みに合わない場合は、ウィンドウのドラッグ操作で目的の場所に移動したり、サイズを変更したりできます。
+
+チャートの **上端** をつかむと、マウスポインターがドラッグアイコンに変わります (下図参照)。
+
+
+
+それでは、**Latency vs Load** チャートをドラッグして、**Latency History** チャートと **Example text chart** の間に配置してください。
+
+
+
+また、ウィンドウの左端、右端、下端をドラッグしてリサイズすることもできます。
+
+最後の演習として、ノートチャートの幅を他のチャートの約 3 分の 1 まで縮小してください。チャートはサポートされているサイズのいずれかに自動的にスナップします。他の 3 つのチャートをダッシュボードの約 3 分の 1 の幅まで広げます。ノートを他のチャートの右側にドラッグし、3 つのチャートと高さが揃うようサイズを調整してください。**Time** を **-1h** に設定すれば、以下のようなダッシュボードができあがります!
+
+
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/_index.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/_index.md
new file mode 100644
index 0000000000..0973084ca4
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/dashboards/_index.md
@@ -0,0 +1,28 @@
+---
+title: ダッシュボード入門
+linkTitle: 1. Dashboards
+weight: 1.0
+time: 10 minutes
+---
+
+## 1. Dashboards
+
+ダッシュボードとは、主要なメトリクスを一箇所に表示するチャートやビジュアライゼーションの集合です。よく設計されたダッシュボードは、システムの健全性とパフォーマンスに関する、迅速で実用的なインサイトを提供します。ダッシュボードは、必要に応じてシンプルにも詳細にもでき、いくつかの焦点を絞ったチャートから、複数のサービスにまたがる複雑なビューまで、さまざまな構成が可能です。
+
+このモジュールでは、いくつかのチャートを作成し、それらをまとめて以下のカスタムダッシュボードを構築します。
+
+
+
+---
+
+## 2. Accessing Dashboards
+
+まず、Splunk Observability suite 内のダッシュボードの場所を確認しましょう。
+
+左側のナビゲーションメニューにある **Dashboards (1)** ボタンをクリックします。メニューが折りたたまれている場合は、画面左上のハンバーガーアイコンをクリックして展開できます。
+
+これにより、メインの Dashboard ビューが表示され、Splunk Observability が提供するビルトインのダッシュボードを含む、利用可能なすべてのダッシュボードが表示されます。
+
+組織が Cloud API インテグレーションや Splunk OpenTelemetry Agent を介して既にデータを取り込んでいる場合は、それらのサービスに関連する追加のダッシュボードも表示されることがあります。
+
+
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/_index.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/_index.md
new file mode 100644
index 0000000000..49a73e413b
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/_index.md
@@ -0,0 +1,115 @@
+---
+title: Detector の活用
+linkTitle: 2. Detectors
+weight: 2.0
+time: 10 minutes
+hidden: true
+---
+
+* チャートから Detector を作成する
+* アラート条件を設定する
+* プリフライトチェックを実行する
+* ミューティングルールを操作する
+
+---
+
+## 1. はじめに
+
+Splunk Observability Cloud では、特定の条件が満たされたときに通知するために、detector、event、alert、notification を使用します。たとえば、CPU 使用率が 95% に達したときや、同時接続ユーザー数が AWS インスタンスの追加が必要になる可能性のある上限に近づいたときに、Ops チームの Slack チャンネルやメールアドレスにメッセージを送信したい場合などです。
+
+これらの条件は、ルール内の条件が満たされたときにアラートをトリガーする 1 つ以上のルールとして表現されます。detector の個々のルールには、重要度に応じて Info、Warning、Minor、Major、Critical のラベルが付けられます。
+
+## 2. Detector の作成
+
+**Dashboards** で、（前のモジュールで作成した）**Custom Dashboard Group** をクリックし、続いてダッシュボード名をクリックします。
+
+
+
+ここからは、このダッシュボード上のチャートから新しい detector を作成します。**Latency vs Load** チャートのベルアイコンをクリックし、**New Detector From Chart** をクリックします。
+
+
+
+**Detector Name** の横のテキストフィールドで、提案された detector 名の前に **イニシャルを追加** します。
+
+{{% notice title="detector の命名" style="info" %}}
+提案された detector 名の先頭にイニシャルを追加することが重要です。
+
+たとえば次のようになります: **XYZ's Latency Chart Detector**。
+{{% /notice %}}
+
+{{% button style="blue" %}}Create Alert Rule{{% /button %}} をクリックします。
+
+
+
+Detector ウィンドウの **Alert signal** 内で、アラート対象となる Signal は **Alert on** 列の（青い）ベルでマークされています。このベルは、アラートの生成に使用されている Signal を示します。
+
+{{% button style="blue" %}}Proceed to Alert Condition{{% /button %}} をクリックします。
+
+
+
+## 3. アラート条件の設定
+
+**Alert condition** で **Static Threshold** をクリックし、続いて {{% button style="blue" %}}Proceed to Alert Settings{{% /button %}} をクリックします。
+
+
+
+**Alert Settings** の **Threshold** フィールドに値 **`290`** を入力します。同じウィンドウで、右上の **Time** を past day (**-1d**) に変更します。
+
+---
+
+## 4. アラートのプリフライトチェック
+
+5 秒後にプリフライトチェックが実行されます。**Estimated alert count** を確認してください。現在のアラート設定に基づくと、1 日に受け取るアラートの数は **3** 件となります。
+
+
+
+{{% notice title="プリフライトチェックについて" style="info" %}}
+アラート条件を設定すると、UI は現在の設定および右上隅で設定された期間（このケースでは過去 1 日間）に基づいて、受け取る可能性のあるアラート数を推定します。
+
+すぐにプラットフォームは現在の設定で signal の分析を開始し、Pre-flight Check と呼ばれる処理を実行します。これにより、プラットフォーム内の過去データを使用してアラート条件をテストできるため、設定が論理的であり、誤ってアラートストームを引き起こさないことを確認できます。Splunk Observability Cloud でのみ利用可能な、シンプルかつ非常に強力な方法でアラート設定の試行錯誤を排除します。
+
+detector のプレビューについて詳しくは、こちらのリンクをご覧ください
+[Preview detector alerts.](https://docs.splunk.com/Observability/alerts-detectors-notifications/preview-detector-alerts.html#nav-Preview-detector-alerts)
+{{% /notice %}}
+
+{{% button style="blue" %}}Proceed to Alert Message{{% /button %}} をクリックします。
+
+---
+
+## 5. アラートメッセージ
+
+**Alert message** の **Severity** で **Major** を選択します。
+
+
+
+{{% button style="blue" %}}Proceed to Alert Recipients{{% /button %}} をクリックします。
+
+**Add Recipient** をクリックし、最初のオプションとして表示されているご自身のメールアドレスをクリックします。
+
+
+
+{{% notice title="Notification Services" style="info" %}}
+これは、そのメールアドレスを入力するのと同じです。または、**E-mail...** をクリックして別のメールアドレスを入力することもできます。
+
+これは、プラットフォームで利用可能な多くの **Notification Services** の一例にすぎません。トップメニューの **Integrations** タブから **Notification Services** を確認できます。
+{{% /notice %}}
+
+---
+
+## 6. アラートの有効化
+
+{{% button style="blue" %}}Proceed to Alert Activation{{% /button %}} をクリックします。
+
+**Activate...** で {{% button style="blue" %}}Activate Alert Rule{{% /button %}} をクリックします。
+
+
+
+より早くアラートを受け取りたい場合は、ルールを編集して値を **`290`** から **`280`** などに下げてください。
+
+**Time** を **-1h** に変更すると、過去 1 時間のメトリクスに基づき、選択したしきい値で受け取る可能性のあるアラート数を確認できます。
+
+ナビゲーションバーの  をクリックし、続いて **Detectors** をクリックします。必要に応じてご自身のイニシャルでフィルタリングできます。ここに作成した detector が一覧表示されます。表示されない場合は、ブラウザを更新してください。
+
+
+
+**おめでとうございます**! 最初の detector を作成し、有効化しました!
diff --git a/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/muting.md b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/muting.md
new file mode 100644
index 0000000000..a564d290bf
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/7-dashboards-detectors/detectors/muting.md
@@ -0,0 +1,58 @@
+---
+title: Muting Rules の使用
+linkTitle: 2.1 Muting Rule の作成
+weight: 2.1
+---
+
+* Muting Rules を設定する方法を学びます
+* 通知を再開する方法を学びます
+
+---
+
+## 1. Muting Rules の設定
+
+特定の通知をミュートしたい場合があります。例えば、サーバーやサーバー群のメンテナンスのためのダウンタイムをスケジュールしたい場合や、新しいコードや設定をテストしている場合などです。そのような場合には、Splunk Observability Cloud の muting rules を使用できます。さっそく作成してみましょう。
+
+サイドバーの **Alerts & Detectors** をクリックし、**Detectors** をクリックしてアクティブな detector の一覧を表示します。
+
+
+
+**Creating a Detector** で detector を作成済みであれば、その detector の右端にある三点リーダー **`...`** をクリックします。作成していない場合は、別の detector で同じ操作を行ってください。
+
+ドロップダウンから **Create Muting Rule...** をクリックします。
+
+
+
+**Muting Rule** ウィンドウで **Mute Indefinitely** にチェックを入れ、理由を入力します。
+
+{{% notice title="重要" style="info" %}}
+これにより、ここに戻ってチェックを外すか、この detector の通知を再開するまで、通知は永続的にミュートされます。
+{{% /notice %}}
+
+
+
+**Next** をクリックし、新しいモーダルウィンドウで muting rule の設定を確認します。
+
+
+
+{{% button style="blue" %}}Mute Indefinitely{{% /button %}} をクリックして確定します。
+
+
+
+通知を再開するまで、この detector からメール通知は届きません。次に、その方法を見ていきましょう。
+
+---
+
+## 2. 通知の再開
+
+通知を再開するには、**Muting Rules** をクリックします。**Detector** という見出しの下に、通知をミュートした detector の名前が表示されます。
+
+右端の三点リーダー **`...`** をクリックし、**Resume Notifications** をクリックします。
+
+
+
+{{% button style="blue" %}}Resume{{% /button %}} をクリックして確定し、この detector の通知を再開します。
+
+
+
+**おめでとうございます！** アラート通知を再開できました。
diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md
new file mode 100644
index 0000000000..e314f86f7a
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md
@@ -0,0 +1,40 @@
+---
+title: EC2 インスタンスへの接続
+linkTitle: 1. EC2 インスタンスへの接続
+weight: 1
+time: 5 minutes
+---
+
+## EC2 インスタンスへの接続
+
+参加者ごとに AWS/EC2 上に Ubuntu Linux インスタンスを用意しています。講師から提供される IP アドレスとパスワードを使用して、以下のいずれかの方法で EC2 インスタンスに接続してください。
+
+* macOS / Linux
+ * `ssh splunk@IP address`
+* Windows 10 以降
+ * OpenSSH クライアントを使用してください
+* それ以前のバージョンの Windows
+ * Putty を使用してください
+
+## ファイルの編集
+
+ワークショップでは `vi` を使用してファイルを編集します。簡単な使い方を以下に示します。
+
+ファイルを編集用に開くには：
+
+```bash
+vi
+```
+
+* ファイルを編集するには、`i` を押して **Insert モード** に切り替え、通常通りテキストを入力します。`Esc` で **Command モード** に戻ります。
+* エディタを終了せずに変更を保存するには、`Esc` を押してコマンドモードに戻り、`:w` を入力します。
+* 変更を保存せずにエディタを終了するには、`Esc` を押してコマンドモードに戻り、`:q!` を入力します。
+* 変更を保存してエディタを終了するには、`Esc` を押してコマンドモードに戻り、`:wq` を入力します。
+
+`vi` の詳しい使い方については [**An introduction to the vi editor**](https://www.redhat.com/en/blog/introduction-vi-editor) を参照してください。
+
+別のエディタを使用したい場合は、代わりに `nano` を使用することもできます：
+
+```bash
+nano
+```
diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/2-deploy-collector.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/2-deploy-collector.md
new file mode 100644
index 0000000000..afbed6a60a
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/2-deploy-collector.md
@@ -0,0 +1,323 @@
+---
+title: OpenTelemetry Collector のデプロイと設定のカスタマイズ
+linkTitle: 2. OpenTelemetry Collector のデプロイと設定のカスタマイズ
+weight: 2
+time: 15 minutes
+---
+
+「データを取り込む」ための最初のステップは、OpenTelemetry collector をデプロイすることです。Collector は環境内でテレメトリデータを受信して処理し、Splunk Observability Cloud にエクスポートします。
+
+このワークショップでは Kubernetes を使用し、Helm を使って K8s クラスター上に collector をデプロイします。
+
+## Helm とは何か
+
+Helm は Kubernetes のパッケージマネージャーで、次のようなメリットがあります。
+
+* 複雑さの管理
+ * 多数のマニフェストファイルではなく、単一の values.yaml ファイルで管理できます
+* 簡単な更新
+ * インプレースアップグレードが可能です
+* ロールバックのサポート
+ * helm rollback を使うだけで、リリースの古いバージョンに戻せます
+
+## Helm を使った Collector のインストール
+
+該当ディレクトリに移動して、collector をインストールするスクリプトを実行しましょう。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+cd /home/splunk/workshop/tagging
+./1-deploy-otel-collector.sh
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+"splunk-otel-collector-chart" has been added to your repositories
+Hang tight while we grab the latest from your chart repositories...
+...Successfully got an update from the "splunk-otel-collector-chart" chart repository
+Update Complete. ⎈Happy Helming!⎈
+NAME: splunk-otel-collector
+LAST DEPLOYED: Mon Dec 23 18:47:38 2024
+NAMESPACE: default
+STATUS: deployed
+REVISION: 1
+NOTES:
+Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1.
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+> このスクリプトの実行には1分ほどかかる場合があります。
+
+このスクリプトはどのように collector をインストールしたのでしょうか？まず、`~./profile` ファイルに設定された環境変数が読み込まれることを確認します。
+
+> 重要: 以下のコマンドは `1-deploy-otel-collector.sh` スクリプトによって既に実行されているため、改めて実行する必要はありません。
+
+``` bash
+source ~/.profile
+```
+
+次に `splunk-otel-collector-chart` Helm チャートをインストールし、最新の状態に更新します。
+
+``` bash
+ helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart
+ helm repo update
+```
+
+最後に、`helm install` を使って collector をインストールします。
+
+``` bash
+ helm install splunk-otel-collector --version 0.149.0 \
+ --set="splunkObservability.realm=$REALM" \
+ --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
+ --set="clusterName=$INSTANCE-k3s-cluster" \
+ --set="environment=tagging-workshop-$INSTANCE" \
+ splunk-otel-collector-chart/splunk-otel-collector \
+ -f otel/values.yaml
+```
+
+> `helm install` コマンドは `values.yaml` ファイルを参照しており、これによって collector の設定をカスタマイズします。詳細については後ほど見ていきます。
+
+## Collector が動作していることの確認
+
+次のコマンドで collector が動作しているかどうかを確認できます。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl get pods
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+NAME READY STATUS RESTARTS AGE
+splunk-otel-collector-agent-kfvjb 1/1 Running 0 2m33s
+splunk-otel-collector-certmanager-7d89558bc9-2fqnx 1/1 Running 0 2m33s
+splunk-otel-collector-certmanager-cainjector-796cc6bd76-hz4sp 1/1 Running 0 2m33s
+splunk-otel-collector-certmanager-webhook-6959cd5f8-qd5b6 1/1 Running 0 2m33s
+splunk-otel-collector-k8s-cluster-receiver-57569b58c8-8ghds 1/1 Running 0 2m33s
+splunk-otel-collector-operator-6fd9f9d569-wd5mn 2/2 Running 0 2m33s
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## K8s クラスターが O11y Cloud に表示されていることの確認
+
+Splunk Observability Cloud で **Infrastructure** → **Kubernetes** → **Kubernetes Clusters** に移動し、自分のクラスター名（`$INSTANCE-k3s-cluster`）を検索します。
+
+
+
+## Collector の設定の取得
+
+Collector の設定をカスタマイズする前に、現在の設定がどのようになっているかをどうやって確認すればよいでしょうか？
+
+Kubernetes 環境では、collector の設定は Config Map に保存されます。
+
+クラスター内に存在する config map は次のコマンドで確認できます。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl get cm -l app=splunk-otel-collector
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+NAME DATA AGE
+splunk-otel-collector-otel-k8s-cluster-receiver 1 3h37m
+splunk-otel-collector-otel-agent 1 3h37m
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+次のコマンドで collector agent の config map を確認できます。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl describe cm splunk-otel-collector-otel-agent
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+Name: splunk-otel-collector-otel-agent
+Namespace: default
+Labels: app=splunk-otel-collector
+ app.kubernetes.io/instance=splunk-otel-collector
+ app.kubernetes.io/managed-by=Helm
+ app.kubernetes.io/name=splunk-otel-collector
+ app.kubernetes.io/version=0.113.0
+ chart=splunk-otel-collector-0.113.0
+ helm.sh/chart=splunk-otel-collector-0.113.0
+ heritage=Helm
+ release=splunk-otel-collector
+Annotations: meta.helm.sh/release-name: splunk-otel-collector
+ meta.helm.sh/release-namespace: default
+
+Data
+====
+relay:
+----
+exporters:
+ otlphttp:
+ headers:
+ X-SF-Token: ${SPLUNK_OBSERVABILITY_ACCESS_TOKEN}
+ metrics_endpoint: https://ingest.us1.signalfx.com/v2/datapoint/otlp
+ traces_endpoint: https://ingest.us1.signalfx.com/v2/trace/otlp
+ (followed by the rest of the collector config in yaml format)
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## K8s での Collector 設定の更新方法
+
+K8s では `values.yaml` ファイルを使って collector の設定をカスタマイズできます。
+
+> `values.yaml` ファイルで利用できるカスタマイズオプションの完全な一覧は、[このファイル](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/helm-charts/splunk-otel-collector/values.yaml) を参照してください。
+
+例を見てみましょう。
+
+### Debug Exporter の追加
+
+Collector に送信されるトレースを確認したいとします。この用途には debug exporter が利用でき、OpenTelemetry 関連の問題のトラブルシューティングに役立ちます。
+
+`values.yaml` ファイルの編集には `vi` または `nano` を使用できます。ここでは vi を使った例を示します。
+
+``` bash
+vi /home/splunk/workshop/tagging/otel/values.yaml
+```
+
+次のテキストをコピーして `values.yaml` ファイルの末尾に貼り付け、debug exporter を追加します。
+
+> vi では、以下のテキストを追加する前に `i` キーを押して挿入モードに入ります。
+
+``` yaml
+ # NEW CONTENT
+ exporters:
+ debug:
+ verbosity: detailed
+ service:
+ pipelines:
+ traces:
+ exporters:
+ - otlp_http
+ - signalfx
+ - debug
+```
+
+これらの変更後、`values.yaml` ファイルには次のような内容が含まれているはずです。
+
+``` yaml
+splunkObservability:
+ profilingEnabled: true
+ infrastructureMonitoringEventsEnabled: true
+certmanager:
+ enabled: true
+operator:
+ enabled: true
+operatorcrds:
+ install: true
+
+agent:
+ config:
+ receivers:
+ kubeletstats:
+ insecure_skip_verify: true
+ auth_type: serviceAccount
+ endpoint: ${K8S_NODE_IP}:10250
+ metric_groups:
+ - container
+ - pod
+ - node
+ - volume
+ k8s_api_config:
+ auth_type: serviceAccount
+ extra_metadata_labels:
+ - container.id
+ - k8s.volume.type
+ extensions:
+ zpages:
+ endpoint: 0.0.0.0:55679
+ # NEW CONTENT
+ exporters:
+ debug:
+ verbosity: detailed
+ service:
+ pipelines:
+ traces:
+ exporters:
+ - otlp_http
+ - signalfx
+ - debug
+```
+
+> vi で変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力して `enter/return` キーを押します。
+
+ファイルを保存したら、次のコマンドで変更を適用できます。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+cd /home/splunk/workshop/tagging
+
+helm upgrade splunk-otel-collector \
+--set="splunkObservability.realm=$REALM" \
+--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
+--set="clusterName=$INSTANCE-k3s-cluster" \
+--set="environment=tagging-workshop-$INSTANCE" \
+splunk-otel-collector-chart/splunk-otel-collector \
+-f otel/values.yaml
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+Release "splunk-otel-collector" has been upgraded. Happy Helming!
+NAME: splunk-otel-collector
+LAST DEPLOYED: Mon Dec 23 19:08:08 2024
+NAMESPACE: default
+STATUS: deployed
+REVISION: 2
+NOTES:
+Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1.
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+`values.yaml` ファイルで collector の設定を変更した際は、config map を確認して、collector に実際に適用されている設定をレビューすると役立ちます。
+
+``` bash
+kubectl describe cm splunk-otel-collector-otel-agent
+```
+
+期待どおり、debug exporter が traces パイプラインに追加されていることが確認できます。
+
+``` yaml
+ traces:
+ exporters:
+ - otlp_http
+ - signalfx
+ - debug
+```
+
+Debug exporter の出力については、クラスターにアプリケーションをデプロイし、トレースのキャプチャを開始したあとで確認していきます。
diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md
new file mode 100644
index 0000000000..04944da036
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md
@@ -0,0 +1,247 @@
+---
+title: サンプルアプリケーションのデプロイと OpenTelemetry によるインストルメンテーション
+linkTitle: 3. サンプルアプリケーションのデプロイと OpenTelemetry によるインストルメンテーション
+weight: 3
+time: 15 minutes
+---
+
+ここまでで、K8s クラスターに OpenTelemetry collector をデプロイし、インフラストラクチャメトリクスの収集に成功しています。
+
+次のステップは、サンプルアプリケーションをデプロイし、OpenTelemetry でインストルメントしてトレースをキャプチャすることです。
+
+Python で書かれたマイクロサービスベースのアプリケーションを使用します。ワークショップをシンプルに保つため、credit check service と credit processor service の 2 つのサービスに焦点を当てます。
+
+## アプリケーションのデプロイ
+
+時間を節約するため、これらのサービスの Docker イメージはすでにビルドされており、Docker Hub から利用できます。次のコマンドで K8s クラスターに credit check service をデプロイできます。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl apply -f /home/splunk/workshop/tagging/creditcheckservice-py-with-tags/creditcheckservice-dockerhub.yaml
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+deployment.apps/creditcheckservice created
+service/creditcheckservice created
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+次に、credit processor service をデプロイしましょう。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl apply -f /home/splunk/workshop/tagging/creditprocessorservice/creditprocessorservice-dockerhub.yaml
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+deployment.apps/creditprocessorservice created
+service/creditprocessorservice created
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+最後に、トラフィックを生成するロードジェネレーターをデプロイしましょう。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl apply -f /home/splunk/workshop/tagging/loadgenerator/loadgenerator-dockerhub.yaml
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+deployment.apps/loadgenerator created
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## アプリケーションの探索
+
+このセクションではアプリケーションの概要を説明します。アプリケーションの完全なソースコードを確認したい場合は、[GitHub の Observability Workshop リポジトリ](https://github.com/splunk/observability-workshop/tree/main/workshop/tagging) を参照してください。
+
+### OpenTelemetry によるインストルメンテーション
+
+credit check service と credit processor service のビルドに使用されている Dockerfile を見ると、すでに OpenTelemetry でインストルメントされていることがわかります。たとえば、`/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/Dockerfile` を見てみましょう。
+
+``` dockerfile
+FROM python:3.11-slim
+
+# Set working directory
+WORKDIR /app
+
+# Copy requirements over
+COPY requirements.txt .
+
+RUN apt-get update && apt-get install --yes gcc python3-dev
+
+ENV PIP_ROOT_USER_ACTION=ignore
+
+# Install Python dependencies
+RUN pip install --no-cache-dir -r requirements.txt
+
+# Copy main app
+COPY main.py .
+
+# Bootstrap OTel
+RUN opentelemetry-bootstrap -a install
+
+# Set the entrypoint command to run the application
+CMD ["opentelemetry-instrument", "python3", "main.py"]
+```
+
+`opentelemetry-bootstrap` が含まれていることがわかります。これにより、アプリケーションが使用するサポート対象パッケージ向けの OpenTelemetry インストルメンテーションがインストールされます。また、アプリケーションを起動するコマンドの一部として `opentelemetry-instrument` が使用されていることもわかります。
+
+そして `/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/requirements.txt` ファイルを確認すると、パッケージリストに `splunk-opentelemetry[all]` が含まれていることがわかります。
+
+最後に、このサービスをデプロイするために使用した Kubernetes マニフェスト (`/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/creditcheckservice-dockerhub.yaml`) を確認すると、OTLP データのエクスポート先を OpenTelemetry に伝えるために、コンテナ内で環境変数が設定されていることがわかります。
+
+``` yaml
+ env:
+ - name: PORT
+ value: "8888"
+ - name: NODE_IP
+ valueFrom:
+ fieldRef:
+ fieldPath: status.hostIP
+ - name: OTEL_EXPORTER_OTLP_ENDPOINT
+ value: "http://$(NODE_IP):4317"
+ - name: OTEL_SERVICE_NAME
+ value: "creditcheckservice"
+ - name: OTEL_PROPAGATORS
+ value: "tracecontext,baggage"
+```
+
+OpenTelemetry でサービスをインストルメントするために必要なのは、これだけです！
+
+### アプリケーションの探索
+
+アプリケーションでいくつかのカスタムタグをキャプチャしており、まもなくそれらを探索します。その前に、タグの概念とその重要性について紹介します。
+
+### タグとは何か？
+
+タグは、トレース内のスパンに関する追加のメタデータを提供するキーと値のペアであり、**Splunk APM** に送信するスパンのコンテキストを充実させることができます。
+
+たとえば、決済処理アプリケーションでは、次のような情報を追跡することが有用です。
+
+* 使用された決済タイプ (クレジットカード、ギフトカードなど)
+* 決済をリクエストした顧客の ID
+
+このようにすれば、決済処理中にエラーやパフォーマンスの問題が発生した場合でも、トラブルシューティングに必要なコンテキストを得られます。
+
+一部のタグは OpenTelemetry collector で追加できますが、このワークショップで扱うタグはより粒度が細かく、アプリケーション開発者が OpenTelemetry SDK を使用して追加します。
+
+### なぜタグはそれほど重要なのか？
+
+タグは、アプリケーションが真に観測可能であるために不可欠です。タグはトレースにコンテキストを追加し、なぜ一部のユーザーは優れた体験を得て、他のユーザーはそうでないのかを理解するのに役立ちます。そして **Splunk Observability Cloud** の強力な機能はタグを活用して、根本原因に素早くたどり着くことを支援します。
+
+> 先に進む前に用語について一言。このワークショップでは **tags** について説明し、これは **Splunk Observability Cloud** で使用する用語ですが、OpenTelemetry では代わりに **attributes** という用語を使用します。そのため、このワークショップで tags という記述を見かけたら、attributes と同義として扱ってかまいません。
+
+### タグはどのようにキャプチャされるのか？
+
+Python アプリケーションでタグをキャプチャするには、まず `/home/splunk/workshop/tagging/creditcheckservice-py-with-tags/main.py` ファイルの先頭に import 文を追加して、trace モジュールをインポートします。
+
+```` python
+import requests
+from flask import Flask, request
+from waitress import serve
+from opentelemetry import trace # <--- ADDED BY WORKSHOP
+...
+````
+
+次に、現在のスパンへの参照を取得して、属性 (タグ) を追加できるようにします。
+
+```` python
+def credit_check():
+ current_span = trace.get_current_span() # <--- ADDED BY WORKSHOP
+ customerNum = request.args.get('customernum')
+ current_span.set_attribute("customer.num", customerNum) # <--- ADDED BY WORKSHOP
+...
+````
+
+とても簡単でしたよね？ credit check service では合計 4 つのタグをキャプチャしており、最終的な結果は次のようになります。
+
+```` python
+def credit_check():
+ current_span = trace.get_current_span() # <--- ADDED BY WORKSHOP
+ customerNum = request.args.get('customernum')
+ current_span.set_attribute("customer.num", customerNum) # <--- ADDED BY WORKSHOP
+
+ # Get Credit Score
+ creditScoreReq = requests.get("http://creditprocessorservice:8899/getScore?customernum=" + customerNum)
+ creditScoreReq.raise_for_status()
+ creditScore = int(creditScoreReq.text)
+ current_span.set_attribute("credit.score", creditScore) # <--- ADDED BY WORKSHOP
+
+ creditScoreCategory = getCreditCategoryFromScore(creditScore)
+ current_span.set_attribute("credit.score.category", creditScoreCategory) # <--- ADDED BY WORKSHOP
+
+ # Run Credit Check
+ creditCheckReq = requests.get("http://creditprocessorservice:8899/runCreditCheck?customernum=" + str(customerNum) + "&score=" + str(creditScore))
+ creditCheckReq.raise_for_status()
+ checkResult = str(creditCheckReq.text)
+ current_span.set_attribute("credit.check.result", checkResult) # <--- ADDED BY WORKSHOP
+
+ return checkResult
+````
+
+## トレースデータの確認
+
+Splunk Observability Cloud でトレースデータを確認する前に、次のコマンドで agent collector のログを tail して、debug exporter がキャプチャした内容を確認しましょう。
+
+``` bash
+kubectl logs -l component=otel-collector-agent -f
+```
+
+ヒント: ログの tail を停止するには `CTRL+C` を使用してください。
+
+agent collector のログには、次のようなトレースが書き込まれているのが確認できるはずです。
+
+````
+InstrumentationScope opentelemetry.instrumentation.flask 0.44b0
+Span #0
+ Trace ID : 9f9fc109903f25ba57bea9b075aa4833
+ Parent ID :
+ ID : 6d71519f454f6059
+ Name : /check
+ Kind : Server
+ Start time : 2024-12-23 19:55:25.815891965 +0000 UTC
+ End time : 2024-12-23 19:55:27.824664949 +0000 UTC
+ Status code : Unset
+ Status message :
+Attributes:
+ -> http.method: Str(GET)
+ -> http.server_name: Str(waitress.invalid)
+ -> http.scheme: Str(http)
+ -> net.host.port: Int(8888)
+ -> http.host: Str(creditcheckservice:8888)
+ -> http.target: Str(/check?customernum=30134241)
+ -> net.peer.ip: Str(10.42.0.19)
+ -> http.user_agent: Str(python-requests/2.31.0)
+ -> net.peer.port: Str(47248)
+ -> http.flavor: Str(1.1)
+ -> http.route: Str(/check)
+ -> customer.num: Str(30134241)
+ -> credit.score: Int(443)
+ -> credit.score.category: Str(poor)
+ -> credit.check.result: Str(OK)
+ -> http.status_code: Int(200)
+````
+
+トレースには、`credit.score` や `credit.score.category` のように、コードでキャプチャしたタグ (属性) が含まれていることに注意してください。これらは次のセクションで、Splunk Observability Cloud でトレースを分析してパフォーマンス問題の根本原因を特定するときに使用します。
diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md
new file mode 100644
index 0000000000..8459ec5997
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md
@@ -0,0 +1,31 @@
+---
+title: Troubleshooting MetricSet を作成する
+linkTitle: 4. Troubleshooting MetricSet を作成する
+weight: 4
+time: 5 minutes
+---
+
+## タグのインデックス化
+
+**Splunk Observability Cloud** の **Tag Spotlight** などの高度な機能を使用するには、まず 1 つ以上のタグをインデックス化する必要があります。
+
+これを行うには、**Settings** -> **APM & RUM MetricSets** に移動し、**APM** タブが選択されていることを確認します。
+次に、**Add MetricSet Configuration** ドロップダウンをクリックし、**Add Custom MetricSet** を選択します。
+
+`credit.score.category` タグをインデックス化するために、以下の詳細を入力します（**注意**：ワークショップ参加者全員が同じ組織を使用しているため、この手順はインストラクターが代わりに実施します）：
+
+
+
+**Start Analysis** をクリックして次に進みます。
+
+分析が実行されている間、タグは **Pending MetricSets** のリストに表示されます。
+
+
+
+分析が完了したら、**Actions** 列のチェックマークをクリックします。
+
+## Troubleshooting MetricSet と Monitoring MetricSet の違い
+
+このタグをインデックス化するために、**Troubleshooting MetricSet** と呼ばれるものを作成したことにお気づきかもしれません。Troubleshooting MetricSet（TMS）という名前が付けられているのは、**Tag Spotlight** などの機能を使用してこのタグに関する問題をトラブルシューティングできるためです。
+
+また、選択しなかったもう 1 つのオプションとして **Monitoring MetricSet**（MMS）があることにもお気づきかもしれません。Monitoring MetricSets はトラブルシューティングを超えて、アラートやダッシュボードでタグを使用できるようにします。本ワークショップではこの機能を扱いませんが、強力な機能ですので、ぜひご自身で試してみてください。
diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md
new file mode 100644
index 0000000000..8c4d1a5955
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md
@@ -0,0 +1,92 @@
+---
+title: Tag Spotlight を使用した問題のトラブルシューティング
+linkTitle: 5. Tag Spotlight を使用した問題のトラブルシューティング
+weight: 5
+time: 15 minutes
+---
+
+## APM データの探索
+
+キャプチャした APM データの一部を探索して、アプリケーションのパフォーマンスを確認してみましょう。
+
+**APM** に移動し、**Environment** ドロップダウンから自分の環境（例：`tagging-workshop-instancename`）を選択します。
+
+サービス一覧に `creditprocessorservice` と `creditcheckservice` が表示されているはずです。
+
+
+
+右側の **Service Map** をクリックして、サービスマップを表示します。`creditcheckservice` が `creditprocessorservice` を呼び出しており、平均応答時間が少なくとも 3 秒であることがわかります。
+
+
+
+次に、右側の **Traces** をクリックして、このアプリケーションでキャプチャされたトレースを確認します。一部のトレースは比較的高速（数ミリ秒程度）ですが、他のトレースは数秒かかることがわかります。
+
+
+
+実行時間が長いトレースの 1 つをクリックします。この例では、トレースに 5 秒かかっており、ほとんどの時間が `creditprocessorservice` の一部である `/runCreditCheck` 操作の呼び出しに費やされていることがわかります。
+
+
+
+しかし、なぜ一部のトレースは遅く、他のトレースは比較的速いのでしょうか？
+
+トレースを閉じて Trace Analyzer に戻ります。**Errors only** を `on` に切り替えると、エラーが発生しているトレースもあることに気づくでしょう。
+
+
+
+エラートレースの 1 つを見ると、`creditprocessorservice` が `otherservice` という別のサービスを呼び出そうとしたときにエラーが発生していることがわかります。しかし、なぜ一部のリクエストは `otherservice` の呼び出しを引き起こし、他のリクエストはそうならないのでしょうか？
+
+
+
+一部のリクエストが遅く、一部のリクエストでエラーが発生する理由を特定するために、トレースを 1 つずつ確認して、問題の背後にあるパターンを見つけ出すこともできます。
+
+**Splunk Observability Cloud** には、問題の根本原因を見つけるためのより良い方法があります。次にこれを探索します。
+
+## Tag Spotlight の使用
+
+`credit.score.category` タグをインデックス化したので、これを **Tag Spotlight** と組み合わせてアプリケーションのトラブルシューティングに使用できます。
+
+**APM** に移動し、右側の **Tag Spotlight** をクリックします。**Service** ドロップダウンから `creditcheckservice` サービスが選択されていることを確認してください（まだ選択されていない場合）。
+
+**Tag Spotlight** を使用すると、`impossible` のスコア結果になるクレジットスコアリクエストの 100% でエラーが発生している一方で、他のすべてのクレジットスコアタイプのリクエストではエラーがまったく発生していないことがわかります。
+
+****
+
+これが **Tag Spotlight** の威力です。これがなければパターンを見つけるのに時間がかかり、何百ものトレースを手作業で確認してパターンを特定する必要があり（それでも見つかる保証はありません）、非常に手間がかかります。
+
+エラーを見てきましたが、レイテンシーはどうでしょうか？ **Requests & errors distribution** ドロップダウンをクリックし、**Latency distribution** に変更しましょう。
+
+> IMPORTANT: **Cards display** の横にある設定アイコンをクリックして、P50 および P99 メトリクスを追加します。
+
+ここでは、`poor` クレジットスコアのリクエストが遅く実行されており、P50、P90、P99 の時間がいずれも約 3 秒であることがわかります。これはユーザーが待つには長すぎる時間で、他のリクエストよりもはるかに遅くなっています。
+
+また、`exceptional` クレジットスコアのリクエストの一部も遅く、P99 時間が約 5 秒となっていますが、P50 応答時間は比較的高速であることもわかります。
+
+****
+
+## Dynamic Service Maps の使用
+
+リクエストに関連付けられたクレジットスコアカテゴリーがパフォーマンスとエラー率に影響を与える可能性があることがわかったので、インデックス化されたタグを活用する別の機能である **Dynamic Service Maps** を探索しましょう。
+
+Dynamic Service Maps を使用すると、特定のサービスをタグごとに分解できます。たとえば、**APM** をクリックしてから **Service Map** をクリックしてサービスマップを表示します。
+
+`creditcheckservice` をクリックします。次に、右側のメニューで **Breakdown** と表示されているドロップダウンをクリックし、`credit.score.category` タグを選択します。
+
+この時点で、サービスマップは動的に更新され、`creditcheckservice` にヒットするリクエストのパフォーマンスがクレジットスコアカテゴリー別に分解されて表示されます。
+
+****
+
+このビューから、`good` および `fair` クレジットスコアのパフォーマンスは優れている一方で、`poor` および `exceptional` スコアははるかに遅く、`impossible` スコアはエラーを引き起こしていることが明確になります。
+
+## 調査結果
+
+**Tag Spotlight** は、このサービスを所有するエンジニアがさらに調査すべきいくつかの興味深いパターンを明らかにしました。
+
+* なぜすべての `impossible` クレジットスコアリクエストでエラーが発生するのか？
+* なぜすべての `poor` クレジットスコアリクエストが遅いのか？
+* なぜ一部の `exceptional` リクエストが遅いのか？
+
+SRE として、このコンテキストをエンジニアリングチームに伝えることは、彼らの調査において非常に有用です。サービスが「時々遅い」とだけ伝えるよりも、はるかに迅速に問題を追跡できるようになるからです。
+
+興味があれば、`creditprocessorservice` のソースコードを見てみてください。impossible、poor、exceptional のクレジットスコアを持つリクエストはそれぞれ異なる方法で処理されており、これが私たちが明らかにしたエラー率とレイテンシーの違いを引き起こしていることがわかります。
+
+このアプリケーションで観察された動作は、サービスに渡されるさまざまな入力が異なるコードパスを引き起こし、その一部がパフォーマンスの低下やエラーを引き起こす、現代のクラウドネイティブアプリケーションでは典型的なものです。たとえば、実際のクレジットチェックサービスでは、低いクレジットスコアになるリクエストはリスクをさらに評価するために別のダウンストリームサービスに送信される場合があり、より高いスコアになるリクエストよりも実行が遅くなったり、エラー率が高くなったりすることがあります。
diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/6-summary.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/6-summary.md
new file mode 100644
index 0000000000..b81c28d6f8
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/6-summary.md
@@ -0,0 +1,25 @@
+---
+title: Summary
+linkTitle: 6. まとめ
+weight: 6
+time: 2 minutes
+---
+
+このワークショップでは、以下の概念をハンズオンで体験しました。
+
+* Helm を使用した **Splunk Distribution of the OpenTelemetry Collector** のデプロイ方法。
+* [**OpenTelemetry**](https://opentelemetry.io) を使用したアプリケーションのインストルメンテーション方法。
+* OpenTelemetry SDK を使用して、アプリケーションから関心のあるタグを取得する方法。
+* **Troubleshooting MetricSets** を使用して、**Splunk Observability Cloud** でタグをインデックスする方法。
+* **Tag Spotlight** および **Dynamic Service Map** 機能を使用して、**Splunk Observability Cloud** でタグを活用し「unknown unknowns（未知の未知）」を発見する方法。
+
+このワークショップで紹介したベストプラクティスに沿ってタグを収集することで、**Splunk Observability Cloud** に送信するデータからさらに大きな価値を引き出すことができます。このワークショップを完了した今、ご自身のアプリケーションからタグを収集し始めるために必要な知識を身につけました！
+
+今すぐタグの取得を始めるには、[サポートされている各種言語でタグを追加する方法](https://docs.splunk.com/observability/en/apm/span-tags/add-context-trace-span.html#instrument-your-application-code-to-add-tags-to-spans)を参照し、続いて [Tag Spotlight で分析できるよう Troubleshooting MetricSets を作成する方法](https://docs.splunk.com/observability/en/apm/span-tags/index-span-tags.html#apm-index-span-tags) を確認してください。さらにサポートが必要な場合は、お気軽に [Splunk のエキスパートにお問い合わせください](https://www.splunk.com/en_us/about-splunk/contact-us.html)。
+
+また、他の言語や環境で OpenTelemetry がどのようにインストルメントされているかを確認するには、
+[Splunk OpenTelemetry Examples GitHub リポジトリ](https://github.com/signalfx/splunk-opentelemetry-examples) をご覧ください。
+
+{{% notice title="ワークショップ運営者へのヒント" style="primary" icon="lightbulb" %}}
+ワークショップが完了したら、先ほど `credit.score.category` タグ用に作成した APM MetricSet を忘れずに削除してください。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/_index.md b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/_index.md
new file mode 100644
index 0000000000..9324e48197
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/9-solving-problems-with-o11y-cloud/_index.md
@@ -0,0 +1,23 @@
+---
+title: O11y Cloud で問題を解決する
+linkTitle: O11y Cloud で問題を解決する
+weight: 9
+archetype: chapter
+time: 45 minutes
+authors: ["Derek Mitchell"]
+description: OpenTelemetry Collector をデプロイし、アプリケーションを計装し、Troubleshooting MetricSet と Tag Spotlight を使ってパフォーマンス問題の根本原因を特定します。
+draft: false
+hidden: false
+aliases:
+ - /ninja-workshops/9-solving-problems-with-o11y-cloud/
+---
+
+このワークショップでは、以下の内容をハンズオン形式で体験します：
+
+* **OpenTelemetry Collector** をデプロイし、コレクター設定をカスタマイズする
+* アプリケーションをデプロイし、**OpenTelemetry** で計装する
+* **OpenTelemetry SDK** を使ってタグがどのようにキャプチャされるかを確認する
+* **Troubleshooting MetricSet** を作成する
+* **Tag Spotlight** を使って問題のトラブルシューティングを行い、根本原因を特定する
+
+それでは始めましょう！
diff --git a/content/ja/ninja-workshops/foundations/_index.md b/content/ja/ninja-workshops/foundations/_index.md
new file mode 100644
index 0000000000..96ea12d018
--- /dev/null
+++ b/content/ja/ninja-workshops/foundations/_index.md
@@ -0,0 +1,10 @@
+---
+title: Foundations
+hero_title: Foundations
+layout: "hero"
+weight: 1
+description: OpenTelemetryの基礎、ダッシュボード、そして日々のトラブルシューティングワークフローを学びます。
+time: 4 時間 45 分
+
+---
+
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md
new file mode 100644
index 0000000000..6f198cefd2
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md
@@ -0,0 +1,30 @@
+---
+title: AWS Setup
+linkTitle: 1. AWS Setup
+weight: 1
+time: 10 minutes
+---
+
+## AWS で Red Hat OpenShift サービスを有効化する
+
+AWS アカウントに OpenShift をデプロイするために、まず [AWS console](https://us-east-1.console.aws.amazon.com/rosa/home?region=us-east-1#/) を使用して Red Hat OpenShift サービスを有効化する必要があります。
+
+次に、画面の指示に従って AWS アカウントと Red Hat アカウントを連携させます。
+
+## EC2 インスタンスをプロビジョニングする
+
+Red Hat クラスターのデプロイに使用する EC2 インスタンスをプロビジョニングしましょう。これにより、Mac OS 上で ROSA コマンドラインインターフェースを実行する際の制約を回避できます。
+
+ワークショップを作成する際には、Ubuntu 24.04 LTS を使用した t3.xlarge インスタンスタイプを使用しましたが、より小さいインスタンスタイプでも利用可能です。
+
+インスタンスが起動したら、ssh で接続してください。
+
+## GitHub リポジトリをクローンする
+
+EC2 インスタンスに GitHub リポジトリをクローンします。
+
+``` bash
+git clone https://github.com/splunk/observability-workshop.git
+
+cd observability-workshop/workshop/cisco-ai-pods
+```
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md
new file mode 100644
index 0000000000..8ac97a65b2
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md
@@ -0,0 +1,49 @@
+---
+title: クリーンアップ
+linkTitle: 10. クリーンアップ
+weight: 10
+time: 5 minutes
+---
+
+## クリーンアップの手順
+
+ワークショップが完了したら、このセクションの手順に従って OpenShift クラスターをアンインストールします。
+
+次のコマンドを実行して、クラスター ID、クラスター固有の Operator ロールの Amazon Resource Names (ARNs)、および OIDC プロバイダーのエンドポイント URL を取得します。
+
+``` bash
+rosa describe cluster --cluster=$CLUSTER_NAME
+```
+
+次のコマンドを使用してクラスターを削除します。
+
+``` bash
+rosa delete cluster --cluster=$CLUSTER_NAME --watch
+```
+
+クラスター固有の Operator IAM ロールを削除します。
+
+> Note: プロンプトが表示されたら、デフォルト値をそのまま受け入れてください。
+
+``` bash
+rosa delete operator-roles --prefix $OPERATOR_ROLES_PREFIX
+```
+
+OIDC プロバイダーを削除します。
+
+> Note: プロンプトが表示されたら、デフォルト値をそのまま受け入れてください。
+
+``` bash
+rosa delete oidc-provider --oidc-config-id $OIDC_ID
+```
+
+ネットワークを削除します。
+
+> Note: 次のコマンドを実行する前に、ネットワークの作成に使用した CloudFormation
+> スタックの名前を追加してください。
+
+``` bash
+aws cloudformation delete-stack --region $AWS_REGION --stack-name
+```
+
+Red Hat OpenShift Service を AWS アカウントから完全に削除したい場合は、[OpenShift ドキュメント](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/install_clusters/rosa-hcp-deleting-cluster)を参照してください。
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md
new file mode 100644
index 0000000000..11d08f29b5
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md
@@ -0,0 +1,155 @@
+---
+title: OpenShift Prerequisites
+linkTitle: 2. OpenShift Prerequisites
+weight: 2
+time: 15 minutes
+---
+
+以下の手順は、AWS に OpenShift クラスターをデプロイする前に必要となるものです。
+
+## Create a Red Hat Login
+
+最初に行う必要があるのは、Red Hat のアカウント作成です。
+[こちら](https://www.redhat.com/wapps/ugc/register.html?_flowId=register-flow&_flowExecutionKey=e1s1)
+のフォームに入力することで作成できます。
+
+## Install the AWS CLI
+
+事前にプロビジョニングした EC2 インスタンスに AWS CLI をインストールするには、以下のコマンドを実行します。
+
+``` bash
+curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
+sudo apt install unzip
+unzip awscliv2.zip
+sudo ./aws/install
+```
+
+以下のコマンドを使用して、正常にインストールされたことを確認します。
+
+``` bash
+aws --version
+```
+
+次のような出力が返されるはずです。
+
+````
+aws-cli/2.30.5 Python/3.13.7 Linux/6.14.0-1011-aws exe/x86_64.ubuntu.24
+````
+
+任意の方法で AWS アカウントにログインします。手順については
+[ドキュメント](https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html)
+を参照してください。例えば、`aws configure` コマンドを実行してログインできます。
+
+`aws ec2 describe-instances` などのコマンドを実行して、正常にログインできているか確認します。
+
+その後、以下のコマンドでアカウントの ID を確認します。
+
+``` bash
+aws sts get-caller-identity
+```
+
+ELB（Elastic Load Balancing）のサービスロールが存在するかを確認します。
+
+``` bash
+aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing"
+```
+
+ロールが存在しない場合は、以下のコマンドを実行して作成します。
+
+``` bash
+aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"
+```
+
+## Install the ROSA CLI
+
+デプロイには ROSA コマンドラインインターフェース（CLI）を使用します。手順は
+[Red Hat のドキュメント](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws_classic_architecture/4/html-single/install_rosa_classic_clusters/index#rosa-installing-and-configuring-the-rosa-cli_rosa-installing-cli)
+に基づいています。
+
+お使いのオペレーティングシステム向けの ROSA CLI の最新リリースは
+[こちら](https://console.redhat.com/openshift/downloads)からダウンロードできます。
+
+代わりに、以下のコマンドを使用して CLI バイナリを EC2 インスタンスに直接ダウンロードすることもできます。
+
+````
+curl -L -O https://mirror.openshift.com/pub/cgw/rosa/latest/rosa-linux.tar.gz
+````
+
+内容を展開します。
+
+````
+tar -xvzf rosa-linux.tar.gz
+````
+
+展開されたファイル（`rosa`）を、パスに含まれる場所に移動します。例えば次のようにします。
+
+``` bash
+sudo mv rosa /usr/local/bin/rosa
+```
+
+以下のコマンドを実行して Red Hat アカウントにログインし、コマンド出力の指示に従います。
+
+````
+rosa login --use-device-code
+````
+
+## Install the OpenShift CLI (oc)
+
+以下のコマンドを使用して、OpenShift CLI バイナリを EC2 インスタンスに直接ダウンロードできます。
+
+````
+curl -L -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
+````
+
+内容を展開します。
+
+````
+tar -xvzf openshift-client-linux.tar.gz
+````
+
+展開されたファイル（`oc` および `kubectl`）を、パスに含まれる場所に移動します。例えば次のようにします。
+
+``` bash
+sudo mv oc /usr/local/bin/oc
+sudo mv kubectl /usr/local/bin/kubectl
+```
+
+## Create Account-Wide Roles and Policies
+
+以下のコマンドを使用して、必要なアカウント全体のロールとポリシーを作成します。
+
+``` bash
+rosa create account-roles --mode auto
+```
+
+## Create an AWS VPC for ROSA HCP
+
+OpenShift クラスターのデプロイには、Hosted Control Plane（HCP）デプロイオプションを使用します。
+これを行うには、以下のコマンドを使用して AWS アカウントに新しい VPC を作成する必要があります。
+
+> Note: お使いの環境に合わせてリージョンを更新してください。
+
+``` bash
+rosa create network network-template --param Region=us-east-2 --param Name=rosa-network-stack --template-dir='.'
+```
+
+> Important: このコマンドの結果として作成されるサブネット ID は、クラスター作成時に必要になるので
+> メモしておいてください。また、後でネットワークを削除する際に必要になるため、CloudFormation
+> スタック名もメモしておいてください。
+
+> Note: デフォルトでは、各 AWS リージョンは 5 つの Elastic IP アドレスに制限されています。
+> 以下のエラーが表示された場合：
+> "The maximum number of addresses has been reached."
+> AWS に連絡してこの上限の引き上げをリクエストするか、
+> ROSA 用の VPC を作成する別の AWS リージョンを選択する必要があります。
+
+## Create an OpenID Connect configuration
+
+Red Hat OpenShift Service on AWS クラスターを作成する前に、以下のコマンドで
+OpenID Connect（OIDC）設定を作成します。
+
+``` bash
+rosa create oidc-config --mode=auto --yes
+```
+
+> Important: 作成された oidc-provider id をメモしておいてください。
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md
new file mode 100644
index 0000000000..2035791080
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md
@@ -0,0 +1,88 @@
+---
+title: AWS への OpenShift クラスターのデプロイ
+linkTitle: 3. AWS への OpenShift クラスターのデプロイ
+weight: 3
+time: 25 minutes
+---
+
+## OpenShift クラスターのデプロイ
+
+ROSA CLI を使って OpenShift クラスターをデプロイします。
+
+まず、いくつかの環境変数を設定する必要があります。
+
+> 注意: EXPORT コマンドを実行する前に、Subnet ID と OIDC ID を必ず記入してください。
+
+``` bash
+export CLUSTER_NAME=rosa-test
+export AWS_REGION=us-east-2
+export AWS_INSTANCE_TYPE=g5.4xlarge
+export SUBNET_IDS=
+export OIDC_ID=
+export OPERATOR_ROLES_PREFIX=rosa-test-a6x9
+```
+
+次のコマンドで、OIDC 構成用のオペレーターロールを作成します。
+
+> 注意: プロンプトが表示されたら、デフォルト値をそのまま受け入れてください。
+
+``` bash
+rosa create operator-roles --hosted-cp --prefix $OPERATOR_ROLES_PREFIX --oidc-config-id $OIDC_ID
+```
+
+続いて、以下のようにクラスターを作成します。
+
+``` bash
+rosa create cluster \
+ --cluster-name $CLUSTER_NAME \
+ --mode auto \
+ --hosted-cp \
+ --sts \
+ --create-admin-user \
+ --operator-roles-prefix $OPERATOR_ROLES_PREFIX \
+ --oidc-config-id $OIDC_ID \
+ --subnet-ids $SUBNET_IDS \
+ --compute-machine-type $AWS_INSTANCE_TYPE \
+ --replicas 2 \
+ --region $AWS_REGION \
+ --tags "splunkit_environment_type:non-prd,splunkit_data_classification:private"
+```
+
+> ここでは `g5.4xlarge` インスタンスタイプを指定しています。これにはワークショップの後半で使用する NVIDIA
+> GPU が含まれています。このインスタンスタイプは比較的高価で、執筆時点で 1 時間あたり約 $1.64 です。
+> さらに 2 つのレプリカを要求しているため、コストが急速に積み上がる点に注意して、
+> クラスターの稼働時間を意識してください。
+
+クラスターが Ready になったかどうかを確認するには、次を実行します。
+
+``` bash
+rosa describe cluster -c $CLUSTER_NAME
+```
+
+クラスターのインストールログを監視するには、次を実行します。
+
+``` bash
+rosa logs install -c $CLUSTER_NAME --watch
+```
+
+## OpenShift クラスターへの接続
+
+以下のコマンドを使用して、oc CLI を OpenShift クラスターに接続します。
+
+> 注意: `rosa describe cluster -c $CLUSTER_NAME` コマンドを実行し、結果として得られた
+> API Server URL を以下のコマンドに置き換えてから実行してください。例えば、
+> サーバー名は `https://api.rosa-test.aaa.bb.openshiftapps.com:443` のような形式になります。
+
+``` bash
+ oc login -u cluster-admin
+```
+
+クラスターに接続したら、ノードが起動して動作していることを確認します。
+
+``` bash
+oc get nodes
+
+NAME STATUS ROLES AGE VERSION
+ip-10-0-1-184.us-east-2.compute.internal Ready worker 14m v1.31.11
+ip-10-0-1-50.us-east-2.compute.internal Ready worker 20m v1.31.11
+```
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md
new file mode 100644
index 0000000000..c712c9d757
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md
@@ -0,0 +1,329 @@
+---
+title: NVIDIA NIM Operator のデプロイ
+linkTitle: 4. NVIDIA NIM Operator のデプロイ
+weight: 4
+time: 20 minutes
+---
+
+**NVIDIA GPU Operator** は、Kubernetes クラスター内で GPU をプロビジョニングするために必要な、すべての NVIDIA ソフトウェアコンポーネントのデプロイ、設定、管理を自動化する Kubernetes Operator です。
+
+**NVIDIA NIM Operator** は、本ワークショップで先ほど作成した OpenShift クラスターのような Kubernetes 環境に LLM をデプロイするために使用します。
+
+このワークショップのセクションでは、OpenShift クラスターに NVIDIA GPU Operator と NIM Operator の両方をデプロイするために必要な手順を順を追って説明します。
+
+## NVIDIA NGC アカウントの作成
+
+LLM をダウンロードして NVIDIA NIM Operator を使用してデプロイするには、NVIDIA GPU CLOUD (NGC) アカウントが必要です。アカウントは [こちら](https://ngc.nvidia.com/signin) から登録できます。
+
+## NVIDIA Developer Program への登録
+
+[NVIDIA Developer Program](https://developer.nvidia.com/) に登録することで、ワークショップの後半で LLM のデプロイに使用する NVIDIA NIM へのアクセスが可能になります。
+
+NGC の NVIDIA サブスクリプション一覧に `NVIDIA Developer Program` が表示されていることを確認してください。
+
+
+
+## NGC API キーの生成
+
+NGC ウェブサイトにログインしたら、画面右上のユーザーアカウントアイコンをクリックし、**Setup** を選択します。
+
+次に **Generate API Key** をクリックし、指示に従ってください。キーが **NGC Catalog** および **Secrets Manager** サービスに関連付けられていることを確認してください。
+
+生成されたキーは、ワークショップの後半で使用するため、安全な場所に保存しておきます。
+
+NGC API キーの生成に関する詳細は、[NVIDIA ドキュメント](https://docs.nvidia.com/ngc/gpu-cloud/ngc-user-guide/index.html#generating-api-key) を参照してください。
+
+## Node Feature Discovery Operator のインストール
+
+このセクションの手順は、[Installing the NFD Operator using the CLI](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/specialized_hardware_and_driver_enablement/psap-node-feature-discovery-operator#install-operator-cli_psap-node-feature-discovery-operator) に基づいています。
+
+次のスクリプトを実行して、Node Feature Discovery Operator をインストールします。
+
+``` bash
+cd nvidia
+./install-nfd-operator.sh
+```
+
+Operator のデプロイが成功したことを確認するには、次のコマンドを実行します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+oc get pods
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+NAME READY STATUS RESTARTS AGE
+nfd-controller-manager-7f86ccfb58-vgr4x 2/2 Running 0 10m
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## NodeFeatureDiscovery CR の作成
+
+このセクションの手順は、[Creating a NodeFeatureDiscovery CR by using the CLI](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/specialized_hardware_and_driver_enablement/psap-node-feature-discovery-operator#creating-nfd-cr-cli_psap-node-feature-discovery-operator) に基づいています。
+
+次のスクリプトを実行して、Node Feature Discovery CR を作成します。
+
+``` bash
+./create-nfd-cr.sh
+```
+
+## NVIDIA GPU Operator のインストール
+
+このセクションの手順は、[Installing the NVIDIA GPU Operator on OpenShift](https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/install-gpu-ocp.html#installing-the-nvidia-gpu-operator-on-openshift) に基づいています。
+
+次のスクリプトを実行して、NVIDIA GPU Operator をインストールします。
+
+``` bash
+./install-nvidia-gpu-operator.sh
+```
+
+インストールプランが作成されるまで待機します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+oc get installplan -n nvidia-gpu-operator
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+NAME CSV APPROVAL APPROVED
+install-mmlxq gpu-operator-certified.v25.3.4 Manual false
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+次のコマンドでインストールプランを承認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+INSTALL_PLAN=$(oc get installplan -n nvidia-gpu-operator -oname)
+oc patch $INSTALL_PLAN -n nvidia-gpu-operator --type merge --patch '{"spec":{"approved":true }}'
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+installplan.operators.coreos.com/install-rc9xq patched
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## クラスターポリシーの作成
+
+このセクションの手順は、[Create the cluster policy using the CLI](https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/install-gpu-ocp.html#create-the-cluster-policy-using-the-cli) に基づいています。
+
+``` bash
+./create-cluster-policy.sh
+```
+
+## NVIDIA GPU Operator のインストール確認
+
+次のコマンドを使用して、NVIDIA GPU Operator が正常にインストールされていることを確認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+oc get pods,daemonset -n nvidia-gpu-operator
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+NAME READY STATUS RESTARTS AGE
+pod/gpu-feature-discovery-sblkn 1/1 Running 0 5m5s
+pod/gpu-feature-discovery-zpt94 1/1 Running 0 4m58s
+pod/gpu-operator-6579bc6fdc-cp28l 1/1 Running 0 23m
+pod/nvidia-container-toolkit-daemonset-qfcl9 1/1 Running 0 5m5s
+pod/nvidia-container-toolkit-daemonset-zbwb6 1/1 Running 0 4m59s
+pod/nvidia-cuda-validator-f7tl2 0/1 Completed 0 78s
+pod/nvidia-cuda-validator-t7n9g 0/1 Completed 0 71s
+pod/nvidia-dcgm-exporter-gk66x 1/1 Running 0 4m59s
+pod/nvidia-dcgm-exporter-w8kr8 1/1 Running 2 (52s ago) 5m5s
+pod/nvidia-dcgm-lrnzr 1/1 Running 0 4m58s
+pod/nvidia-dcgm-tvrdm 1/1 Running 0 5m5s
+pod/nvidia-device-plugin-daemonset-d62nk 1/1 Running 0 5m5s
+pod/nvidia-device-plugin-daemonset-fnv4j 1/1 Running 0 4m59s
+pod/nvidia-driver-daemonset-418.94.202509100653-0-5xbvq 2/2 Running 0 5m48s
+pod/nvidia-driver-daemonset-418.94.202509100653-0-hmkdl 2/2 Running 0 5m48s
+pod/nvidia-node-status-exporter-2kqwr 1/1 Running 0 5m44s
+pod/nvidia-node-status-exporter-n8d9s 1/1 Running 0 5m44s
+pod/nvidia-operator-validator-r2nm2 1/1 Running 0 5m5s
+pod/nvidia-operator-validator-w2fpn 1/1 Running 0 4m59s
+
+NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
+daemonset.apps/gpu-feature-discovery 2 2 2 2 2 nvidia.com/gpu.deploy.gpu-feature-discovery=true 5m45s
+daemonset.apps/nvidia-container-toolkit-daemonset 2 2 2 2 2 nvidia.com/gpu.deploy.container-toolkit=true 5m48s
+daemonset.apps/nvidia-dcgm 2 2 2 2 2 nvidia.com/gpu.deploy.dcgm=true 5m46s
+daemonset.apps/nvidia-dcgm-exporter 2 2 2 2 2 nvidia.com/gpu.deploy.dcgm-exporter=true 5m46s
+daemonset.apps/nvidia-device-plugin-daemonset 2 2 2 2 2 nvidia.com/gpu.deploy.device-plugin=true 5m47s
+daemonset.apps/nvidia-device-plugin-mps-control-daemon 0 0 0 0 0 nvidia.com/gpu.deploy.device-plugin=true,nvidia.com/mps.capable=true 5m47s
+daemonset.apps/nvidia-driver-daemonset-418.94.202509100653-0 2 2 2 2 2 feature.node.kubernetes.io/system-os_release.OSTREE_VERSION=418.94.202509100653-0,nvidia.com/gpu.deploy.driver=true 5m48s
+daemonset.apps/nvidia-mig-manager 0 0 0 0 0 nvidia.com/gpu.deploy.mig-manager=true 5m45s
+daemonset.apps/nvidia-node-status-exporter 2 2 2 2 2 nvidia.com/gpu.deploy.node-status-exporter=true 5m44s
+daemonset.apps/nvidia-operator-validator 2 2 2 2 2 nvidia.com/gpu.deploy.operator-validator=true 5m48s
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Operator SDK のインストール
+
+このセクションの手順は、[Install from GitHub release](https://sdk.operatorframework.io/docs/installation/#install-from-github-release) に基づいています。
+
+### リリースバイナリのダウンロード
+
+プラットフォーム情報を設定します。
+
+``` bash
+export ARCH=$(case $(uname -m) in x86_64) echo -n amd64 ;; aarch64) echo -n arm64 ;; *) echo -n $(uname -m) ;; esac)
+export OS=$(uname | awk '{print tolower($0)}')
+```
+
+お使いのプラットフォーム向けのバイナリをダウンロードします。
+
+``` bash
+export OPERATOR_SDK_DL_URL=https://github.com/operator-framework/operator-sdk/releases/download/v1.41.1
+curl -LO ${OPERATOR_SDK_DL_URL}/operator-sdk_${OS}_${ARCH}
+```
+
+### ダウンロードしたバイナリの検証
+
+keyserver.ubuntu.com から operator-sdk リリースの GPG キーをインポートします。
+
+``` bash
+gpg --keyserver keyserver.ubuntu.com --recv-keys 052996E2A20B5C7E
+```
+
+チェックサムファイルとその署名をダウンロードし、署名を検証します。
+
+``` bash
+curl -LO ${OPERATOR_SDK_DL_URL}/checksums.txt
+curl -LO ${OPERATOR_SDK_DL_URL}/checksums.txt.asc
+gpg -u "Operator SDK (release) " --verify checksums.txt.asc
+```
+
+次のような出力が表示されるはずです。
+
+``` bash
+gpg: assuming signed data in 'checksums.txt'
+gpg: Signature made Fri 30 Oct 2020 12:15:15 PM PDT
+gpg: using RSA key ADE83605E945FA5A1BD8639C59E5B47624962185
+gpg: Good signature from "Operator SDK (release) " [ultimate]
+```
+
+チェックサムが一致することを確認します。
+
+``` bash
+grep operator-sdk_${OS}_${ARCH} checksums.txt | sha256sum -c -
+```
+
+次のような出力が表示されるはずです。
+
+``` bash
+operator-sdk_linux_amd64: OK
+```
+
+### リリースバイナリを PATH にインストール
+
+``` bash
+chmod +x operator-sdk_${OS}_${ARCH} && sudo mv operator-sdk_${OS}_${ARCH} /usr/local/bin/operator-sdk
+```
+
+## NGC CLI のインストール
+
+このセクションの手順は、[NGC CLI Install](https://org.ngc.nvidia.com/setup/installers/cli) に基づいています。
+
+Download CLI をクリックしてバイナリを含む zip ファイルをダウンロードし、権限のあるディレクトリに転送してから、解凍してバイナリを実行します。実行権限のあるディレクトリに移動して次のコマンドを実行することで、コマンドラインからダウンロード、解凍、インストールを行うこともできます。
+
+``` bash
+wget --content-disposition https://api.ngc.nvidia.com/v2/resources/nvidia/ngc-apps/ngc_cli/versions/4.3.0/files/ngccli_linux.zip -O ngccli_linux.zip && unzip ngccli_linux.zip
+```
+
+ダウンロード時にファイルが破損していないことを確認するため、バイナリの md5 ハッシュをチェックします。
+
+``` bash
+find ngc-cli/ -type f -exec md5sum {} + | LC_ALL=C sort | md5sum -c ngc-cli.md5
+```
+
+ダウンロード時にファイルが破損していないことを確認するため、バイナリの SHA256 ハッシュをチェックします。次のコマンドを実行してください。
+
+``` bash
+sha256sum ngccli_linux.zip
+```
+
+リソースのリリースノートにも記載されている、次の値と比較します。
+
+``` bash
+5f01eff85a66c895002f3c87db2933c462f3b86e461e60d515370f647b4ffc21
+```
+
+値を確認したら、NGC CLI バイナリを実行可能にし、現在のディレクトリを PATH に追加します。
+
+``` bash
+chmod u+x ngc-cli/ngc
+echo "export PATH=\"\$PATH:$(pwd)/ngc-cli\"" >> ~/.bash_profile && source ~/.bash_profile
+```
+
+コマンドを実行できるようにするため、NGC CLI を設定する必要があります。
+
+次のコマンドを入力し、プロンプトが表示されたら API キーを入力します。
+
+``` bash
+ngc config set
+```
+
+NGC API キーを環境変数として定義します。
+
+``` bash
+export NGC_API_KEY=
+```
+
+## NVIDIA NIM Operator のインストール
+
+このセクションの手順は、[Installing NIM Operator on Red Hat OpenShift Using operator-sdk (for Development-Only)](https://docs.nvidia.com/nim-operator/latest/install.html#installing-nim-operator-on-red-hat-openshift-using-operator-sdk-for-development-only) に基づいています。
+
+次のスクリプトを実行して、NIM Operator をインストールします。
+
+``` bash
+./install-nim-operator.sh
+```
+
+コントローラー Pod が実行中であることを確認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+oc get pods -n nvidia-nim-operator
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+NAME READY STATUS RESTARTS AGE
+ec60a4439c710b89fc2582f5384382b4241f9aee62bb3182b8d128e69dx54dc 0/1 Completed 0 61s
+ghcr-io-nvidia-k8s-nim-operator-bundle-latest-main 1/1 Running 0 71s
+k8s-nim-operator-86d478b55c-w5cf5 1/1 Running 0 50s
+```
+
+{{% /tab %}}
+{{< /tabs >}}
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md
new file mode 100644
index 0000000000..4bc84e5f8f
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md
@@ -0,0 +1,172 @@
+---
+title: ユーザーのセットアップ
+linkTitle: 6. ユーザーのセットアップ
+weight: 6
+time: 5 minutes
+---
+
+このセクションでは、ワークショップ参加者ごとにユーザーを作成し、それぞれに namespace とリソース
+クォータを割り当てます。
+
+## ユーザー namespace とリソースクォータの作成
+
+``` bash
+cd user-setup
+./create-namespaces.sh
+```
+
+## ユーザーの作成
+
+参加者の認証情報を含む HTPasswd ファイルを作成し、ROSA が管理する HTPasswd IdP を
+カスタムのものに置き換えます。
+
+``` bash
+./create-users.sh
+```
+
+## cluster-admin ユーザーの再作成と再ログイン
+
+cluster-admin ユーザーを再作成し、再度ログインします。
+
+``` bash
+rosa create admin -c rosa-test
+oc login --username cluster-admin --password
+```
+
+## ユーザーへのロール追加
+
+各ユーザーに、自身の namespace のみへのアクセス権を付与します。
+
+``` bash
+./add-role-to-users.sh
+```
+
+注意: 以下のようなエラーが表示される場合がありますが、無視して問題ありません。
+
+````
+Warning: User 'participant1' not found
+clusterrole.rbac.authorization.k8s.io/admin added: "participant1"
+````
+
+## ログインのテスト
+
+### OpenShift CLI のインストール
+
+ローカルマシンからログインをテストするために、OpenShift CLI をインストールする必要があります。
+
+MacOS の場合は、Homebrew パッケージマネージャーを使用して OpenShift CLI をインストールできます。
+
+``` bash
+brew install openshift-cli
+```
+
+その他のインストール方法については、[OpenShift ドキュメント](https://docs.redhat.com/en/documentation/openshift_container_platform/4.8/html/cli_tools/openshift-cli-oc) を参照してください。
+
+### ワークショップユーザーとしてのログイン
+
+ローカルマシンからワークショップユーザーの 1 人としてログインを試みます。
+
+``` bash
+oc login https://api.:443 -u participant1 -p 'TempPass123!'
+```
+
+以下のようなメッセージが表示されるはずです。
+
+````
+Login successful.
+
+You have one project on this server: "workshop-participant-1"
+````
+
+### LLM へのアクセス確認
+
+ワークショップユーザーアカウントから LLM にアクセスできることを確認します。
+
+curl コマンドを使用できる pod を起動します。
+
+``` bash
+oc run curl --rm -it --image=curlimages/curl:latest \
+ --overrides='{
+ "spec": {
+ "containers": [{
+ "name": "curl",
+ "image": "curlimages/curl:latest",
+ "stdin": true,
+ "tty": true,
+ "command": ["sh"],
+ "resources": {
+ "limits": {
+ "cpu": "50m",
+ "memory": "100Mi"
+ },
+ "requests": {
+ "cpu": "50m",
+ "memory": "100Mi"
+ }
+ }
+ }]
+ }
+ }'
+```
+
+次に、以下のコマンドを実行して LLM にプロンプトを送信します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+curl -X "POST" \
+ 'http://meta-llama-3-2-1b-instruct.nim-service:8000/v1/chat/completions' \
+ -H 'Accept: application/json' \
+ -H 'Content-Type: application/json' \
+ -d '{
+ "model": "meta/llama-3.2-1b-instruct",
+ "messages": [
+ {
+ "content":"What is the capital of Canada?",
+ "role": "user"
+ }],
+ "top_p": 1,
+ "n": 1,
+ "max_tokens": 1024,
+ "stream": false,
+ "frequency_penalty": 0.0,
+ "stop": ["STOP"]
+ }'
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+{
+ "id": "chatcmpl-2ccfcd75a0214518aab0ef0375f8ca21",
+ "object": "chat.completion",
+ "created": 1758919002,
+ "model": "meta/llama-3.2-1b-instruct",
+ "choices": [
+ {
+ "index": 0,
+ "message": {
+ "role": "assistant",
+ "reasoning_content": null,
+ "content": "The capital of Canada is Ottawa.",
+ "tool_calls": []
+ },
+ "logprobs": null,
+ "finish_reason": "stop",
+ "stop_reason": null
+ }
+ ],
+ "usage": {
+ "prompt_tokens": 42,
+ "total_tokens": 50,
+ "completion_tokens": 8,
+ "prompt_tokens_details": null
+ },
+ "prompt_logprobs": null
+}
+```
+
+{{% /tab %}}
+{{< /tabs >}}
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md
new file mode 100644
index 0000000000..f50c81978c
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md
@@ -0,0 +1,107 @@
+---
+title: OpenTelemetry Collector のインストール
+linkTitle: 7. OpenTelemetry Collector のインストール
+weight: 7
+time: 5 minutes
+---
+
+このセクションでは、clusterReceiver のみを有効化した OpenTelemetry collector をインストールします
+（ワークショップ参加者は各自の namespace に独自のエージェントをインストールするため）。
+その後、この collector のインストールによって作成された ClusterRole を、
+各ワークショップ参加者の namespace にバインドします。
+
+## OpenTelemetry Collector のインストール
+
+まず、collector 用の新しいプロジェクトを作成し、そのプロジェクトに切り替えます:
+
+```bash
+oc new-project admin-otel
+```
+
+Splunk OpenTelemetry Collector for Kubernetes の Helm chart リポジトリを追加します:
+
+```bash
+helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart
+````
+
+リポジトリが最新であることを確認します:
+
+```bash
+helm repo update
+````
+
+OpenTelemetry collector のインストールに使用する `./admin-otel-collector/admin-otel-collector-values.yaml`
+ファイルの内容を確認してください。
+
+collector がデータを送信する Splunk 環境を設定するため、環境変数を設定します:
+
+``` bash
+export CLUSTER_NAME=ai-pod-workshop-admin
+export ENVIRONMENT_NAME=ai-pod-workshop-admin
+export SPLUNK_ACCESS_TOKEN=
+export SPLUNK_REALM=
+export SPLUNK_HEC_URL=:443/services/collector/event>
+export SPLUNK_HEC_TOKEN=
+export SPLUNK_INDEX=splunk4rookies-workshop
+```
+
+次に、以下のコマンドで collector をインストールします:
+
+```bash
+helm install splunk-otel-collector \
+ --set="clusterName=$CLUSTER_NAME" \
+ --set="environment=$ENVIRONMENT_NAME" \
+ --set="splunkObservability.accessToken=$SPLUNK_ACCESS_TOKEN" \
+ --set="splunkObservability.realm=$SPLUNK_REALM" \
+ --set="splunkPlatform.endpoint=$SPLUNK_HEC_URL" \
+ --set="splunkPlatform.token=$SPLUNK_HEC_TOKEN" \
+ --set="splunkPlatform.index=$SPLUNK_INDEX" \
+ -f ./admin-otel-collector/admin-otel-collector-values.yaml \
+ -n admin-otel \
+ splunk-otel-collector-chart/splunk-otel-collector
+```
+
+以下のコマンドを実行して、すべての collector の pod が動作していることを確認します:
+
+````
+oc get pods -n admin-otel
+
+NAME READY STATUS RESTARTS AGE
+splunk-otel-collector-k8s-cluster-receiver-7b7f5cdc5b-rhxsj 1/1 Running 0 6m40s
+````
+
+## 各ワークショップ参加者用の Service Account の作成と Cluster Role へのバインド
+
+``` bash
+for i in {1..30}; do
+ ns="workshop-participant-$i"
+
+ oc get ns "$ns" >/dev/null 2>&1 || continue
+ oc -n "$ns" create sa splunk-otel-collector 2>/dev/null || true
+
+ oc apply -f - </dev/null 2>&1 || continue
+ oc -n "$ns" adm policy add-scc-to-user splunk-otel-collector -z splunk-otel-collector
+done
+```
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md
new file mode 100644
index 0000000000..9ee7b1d763
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md
@@ -0,0 +1,79 @@
+---
+title: Deploy the Vector Database
+linkTitle: 8. Deploy the Vector Database
+weight: 8
+time: 10 minutes
+---
+
+このステップでは、OpenShiftクラスターにベクトルデータベースをデプロイし、ワークショップ参加者が使用するテストデータを投入します。
+
+## Deploy a Vector Database
+
+このワークショップでは、オープンソースのベクトルデータベースである [Weaviate](https://weaviate.io/) をデプロイします。
+
+まず、Weaviate helm chartが含まれているWeaviate helmリポジトリを追加します。
+
+``` bash
+helm repo add weaviate https://weaviate.github.io/weaviate-helm
+helm repo update
+```
+
+`weaviate/weaviate-values.yaml` ファイルには、Weaviateベクトルデータベースをデプロイするために使用する設定が含まれています。
+
+後ほどPrometheus receiverでスクレイプできるメトリクスをWeaviateが公開するように、以下の環境変数を `TRUE` に設定しています。
+
+````
+ PROMETHEUS_MONITORING_ENABLED: true
+ PROMETHEUS_MONITORING_GROUP: true
+````
+
+利用可能なその他のカスタマイズオプションについては、[Weaviate documentation](https://docs.weaviate.io/deploy/installation-guides/k8s-installation) を参照してください。
+
+新しいnamespaceを作成します。
+
+``` bash
+oc create namespace weaviate
+```
+
+Weaviateが特権コンテナを実行できるように、以下のコマンドを実行します。
+
+> 注: このアプローチは本番環境では推奨されません
+
+``` bash
+oc adm policy add-scc-to-user privileged -z default -n weaviate
+```
+
+続いてWeaviateをデプロイします。
+
+``` bash
+helm upgrade --install \
+ "weaviate" \
+ weaviate/weaviate \
+ --namespace "weaviate" \
+ --values ./weaviate/weaviate-values.yaml
+```
+
+## Populate the Vector Database
+
+Weaviateが起動したので、カスタムアプリケーションを使ってワークショップで利用するデータを投入していきます。
+
+このために使用するアプリケーションは、[LangChain Playbook for NeMo Retriever Text Embedding NIM](https://docs.nvidia.com/nim/nemo-retriever/text-embedding/latest/playbook.html#generate-embeddings-with-text-embedding-nim) をベースにしています。
+
+`./load-embeddings/k8s-job.yaml` の設定に従い、[datasheet for the NVIDIA H200 Tensor Core GPU](https://nvdam.widen.net/content/udc6mzrk7a/original/hpc-datasheet-sc23-h200-datasheet-3002446.pdf) をベクトルデータベースにロードします。
+
+このドキュメントには、私たちが利用する大規模言語モデルが学習していないNVIDIA H200 GPUに関する情報が含まれています。ワークショップの次のパートでは、このドキュメントをベクトルデータベースにロードしたうえで、その内容をコンテキストとして利用してLLMが質問に回答するアプリケーションを構築します。
+
+OpenShiftクラスターにKubernetes Jobをデプロイして、エンベディングをロードします。このプロセスを一度だけ実行することを保証するため、PodではなくKubernetes Jobを使用します。
+
+``` bash
+oc create namespace llm-app
+oc apply -f ./load-embeddings/k8s-job.yaml
+```
+
+> 注: エンベディングをWeaviateにロードするPythonアプリケーションのDockerイメージをビルドする際には、以下のコマンドを実行しました。
+>
+> ``` bash
+> cd workshop/cisco-ai-pods/load-embeddings
+> docker build --platform linux/amd64 -t derekmitchell399/load-embeddings:1.0 .
+> docker push derekmitchell399/load-embeddings:1.0
+> ```
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md
new file mode 100644
index 0000000000..cb73211371
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md
@@ -0,0 +1,50 @@
+---
+title: Portworx メトリクスエンドポイントのデプロイ
+linkTitle: 9. Portworx メトリクスエンドポイント
+weight: 9
+time: 10 minutes
+---
+
+このステップでは、Portworx のメトリクスエンドポイントを模倣する Python サービスをデプロイします。
+これは、ワークショップで Pure Storage の監視を設定するために使用します。
+
+## Portworx メトリクスエンドポイントのデプロイ
+
+以下のコマンドを実行して、Portworx メトリクスエンドポイントサービスをデプロイします。
+
+``` bash
+oc new-project portworx
+oc apply -f ./portworx/k8s.yaml -n portworx
+```
+
+## Portworx メトリクスエンドポイントのテスト
+
+Portworx メトリクスエンドポイントが想定どおりに動作していることを確認しましょう。
+
+curl コマンドを利用できる Pod を起動します。
+
+``` bash
+oc run --rm -it -n default curl --image=curlimages/curl:latest -- sh
+```
+
+続いて、以下のコマンドを実行してエンドポイントにリクエストを送信します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+curl http://portworx-metrics-sim.portworx:17001/metrics
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+# HELP px_cluster_cpu_percent Percentage of CPU Used
+# TYPE px_cluster_cpu_percent gauge
+px_cluster_cpu_percent{cluster="ocp-pxclus-32430549-ad99-4839-bf9b-d6beb8ddc2d6",clusterUUID="e870909b-6150-4d72-87cb-a012630e42ae",node="worker2.flashstack.local",nodeID="f63312a2-0884-4878-be4e-51935613aa80"} 1.91
+...
+```
+
+{{% /tab %}}
+{{< /tabs >}}
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md
new file mode 100644
index 0000000000..cf8e36b511
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md
@@ -0,0 +1,17 @@
+---
+title: Workshop Setup
+linkTitle: 1. Workshop Setup
+weight: 1
+---
+
+このセクションには、ワークショップ主催者がワークショップをセットアップするために実行すべき手順が含まれます。
+
+* AWS アカウントのセットアップ
+* OpenShift の前提条件
+* AWS ROSA を使用して、GPU ベースのワーカーノードを持つ **RedHat OpenShift** クラスターをデプロイします。
+* **NVIDIA NIM Operator** と **NVIDIA GPU Operator** をデプロイします。
+* NVIDIA NIM を使用してクラスターに **Large Language Model (LLM)** をデプロイします。
+* 適切な権限を持つ OpenShift ログインと名前空間を、各ワークショップユーザー向けに作成します。
+* **Splunk OpenTelemetry collector** の Cluster Receiver コンポーネントをインストールします。
+* クラスターに **Weviate vector database** をデプロイします。
+* **Portworx Prometheus exporter** を模倣するサービスをデプロイします。
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md
new file mode 100644
index 0000000000..3f72cbb6b6
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md
@@ -0,0 +1,57 @@
+---
+title: ワークショップ環境の概要
+linkTitle: 1. ワークショップ環境の概要
+weight: 1
+time: 5 minutes
+---
+
+**Cisco's AI-ready PODs** は、最先端のハードウェアとソフトウェアを組み合わせ、
+堅牢でスケーラブル、かつ効率的なAIインフラストラクチャを提供します。
+**Splunk Observability Cloud** は、インフラストラクチャからアプリケーションコンポーネントに至るまで、
+このスタック全体を包括的に可視化します。
+
+このハンズオンワークショップでは、OpenTelemetryとPrometheusを使用してAIインフラストラクチャを監視する方法を、
+**実際のCisco AI PODへのアクセスを必要とせずに** 学習します。
+現実的な環境で監視技術をデプロイし設定する実践的な経験を得られます。
+
+## ラボ環境
+
+このワークショップでは、AWS上で動作する共有 **OpenShift Cluster** を使用します。
+このクラスターはNVIDIA GPUおよびNVIDIA AI Enterpriseソフトウェアを備えています。
+
+### 事前デプロイ済みのインフラストラクチャ
+
+ワークショップのインストラクターは、以下の共有コンポーネントをワークショップ環境にデプロイ済みです:
+
+* **NVIDIA NIM models**:
+ * `meta/llama-3.2-1b-instruct` - ユーザープロンプトを処理します
+ * `nvidia/llama-3.2-nv-embedqa-1b-v2` - エンベディングを生成します
+* **Weaviate** - セマンティック検索と取得のためのベクトルデータベースです
+* **Prometheus exporter** - 本番AI PODに典型的なPure Storageメトリクスをシミュレートします
+
+### あなたのワークスペース
+
+各参加者には共有クラスター内に専用の名前空間が割り当てられ、
+独立した作業のための分離された環境が確保されます。
+
+## ワークショップのアクティビティ
+
+ワークショップの中で、各参加者は以下のタスクを実行します:
+
+1. 自分の名前空間に **OpenTelemetry collector** をデプロイして設定します
+2. クラスターインフラストラクチャとオブザーバビリティデータ収集を統合します
+3. NVIDIA NIM modelsを活用する **Python application** をデプロイします
+4. Splunk Observability Cloudを使用してアプリケーションのパフォーマンスとインフラストラクチャメトリクスを監視します
+
+## Prometheusとは
+
+**Prometheus** は通常、ストレージとアラート用途に使われるフルスタックの監視システムを指しますが、
+このワークショップではPrometheusエコシステムのデータ標準に焦点を当てます。
+
+ここでは **Prometheus Exporters** を活用します。これは、コンポーネントの内部状態を標準化された
+メトリクスエンドポイント (例: ) に変換する小さなユーティリティです。
+
+このデータの収集にPrometheusサーバー全体を使用する代わりに、
+**OpenTelemetry Collector** を使用します。コレクターの **Prometheus receiver** を使うことで、
+これらのエンドポイントを **scrape** することができ、広くサポートされた業界標準フォーマットを用いて
+豊富なテレメトリデータを収集できます。
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md
new file mode 100644
index 0000000000..f5363044bc
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md
@@ -0,0 +1,79 @@
+---
+title: LLM アプリケーションのデプロイ
+linkTitle: 10. LLM アプリケーションのデプロイ
+weight: 10
+time: 10 minutes
+---
+
+## LLM アプリケーションのデプロイ
+
+以下のコマンドを使用して、このアプリケーションを OpenShift クラスターにデプロイします。
+
+``` bash
+cd ~/workshop/cisco-ai-pods
+oc apply -f ./llm-app/k8s-manifest.yaml
+```
+
+> 注意: この Python アプリケーションの Docker イメージをビルドするために、以下のコマンドを実行しました。
+>
+> ``` bash
+> cd workshop/cisco-ai-pods/llm-app
+> docker build --platform linux/amd64 -t ghcr.io/splunk/cisco-ai-pod-workshop-app:1.0 .
+> docker push ghcr.io/splunk/cisco-ai-pod-workshop-app:1.0
+> ```
+
+## LLM アプリケーションのテスト
+
+アプリケーションが期待どおりに動作していることを確認しましょう。
+
+curl コマンドを利用できる Pod を起動します。
+
+``` bash
+oc run curl --rm -it --image=curlimages/curl:latest \
+ --overrides='{
+ "spec": {
+ "containers": [{
+ "name": "curl",
+ "image": "curlimages/curl:latest",
+ "stdin": true,
+ "tty": true,
+ "command": ["sh"],
+ "resources": {
+ "limits": {
+ "cpu": "50m",
+ "memory": "100Mi"
+ },
+ "requests": {
+ "cpu": "50m",
+ "memory": "100Mi"
+ }
+ }
+ }]
+ }
+ }'
+```
+
+続いて、以下のコマンドを実行して LLM に質問を送信します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+curl -X "POST" \
+ 'http://llm-app:8080/askquestion' \
+ -H 'Accept: application/json' \
+ -H 'Content-Type: application/json' \
+ -d '{
+ "question": "How much memory does the NVIDIA H200 have?"
+ }'
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+The NVIDIA H200 has 141GB of HBM3e memory, which is twice the capacity of the NVIDIA H100 Tensor Core GPU with 1.4X more memory bandwidth.
+```
+
+{{% /tab %}}
+{{< /tabs >}}
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/11-review-traces.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/11-review-traces.md
new file mode 100644
index 0000000000..e8c8ed7427
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/11-review-traces.md
@@ -0,0 +1,39 @@
+---
+title: メトリクス、トレース、ログの確認
+linkTitle: 11. メトリクス、トレース、ログの確認
+weight: 11
+time: 10 minutes
+---
+
+## Splunk Observability Cloud でトレースデータを表示する
+
+Splunk Observability Cloud で `APM` に移動し、`Service Map` を選択します。
+環境名（例：`ai-pod-workshop-participant-1`）が選択されていることを確認します。
+以下のようなサービスマップが表示されるはずです。
+
+
+
+右側のメニューにある `Traces` をクリックします。次に、実行時間が比較的長いトレースの 1 つを選択します。以下の例のように表示されるはずです。
+
+
+
+このトレースは、ユーザーの質問（例：「How much memory does the NVIDIA H200 have?」）に回答を返すためにアプリケーションが実行したすべてのインタラクションを示しています。
+
+例えば、Weaviate ベクトルデータベース内で当該質問に関連するドキュメントを探すために、アプリケーションが類似検索を実行した箇所を確認できます。
+
+また、ベクトルデータベースから取得したコンテキストを含めて、アプリケーションが LLM に送信するプロンプトをどのように作成したかも確認できます。
+
+
+
+> 注：トレースのウォーターフォールビューに `chat` および `invoke_workflow` の AI インタラクションが表示されない場合、または右側に `AI details` タブが表示されない場合は、有効化が必要な superpowers について講師に確認してください。
+
+最後に、LLM からのレスポンス、所要時間、および使用された入出力トークン数を確認できます。
+
+
+
+## メトリクスが Splunk に送信されていることを確認する
+
+Splunk Observability Cloud で `Dashboards` に移動し、`Built-in dashboard groups` に含まれている `Cisco AI PODs Dashboard` を検索します。
+`NIM FOR LLMS` タブに移動し、ダッシュボードが自分の OpenShift クラスター名でフィルタリングされていることを確認します。以下の例のようにチャートにデータが表示されるはずです。
+
+
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/12-wrapup.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/12-wrapup.md
new file mode 100644
index 0000000000..edf23c1682
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/12-wrapup.md
@@ -0,0 +1,22 @@
+---
+title: Wrap-Up
+linkTitle: 12. まとめ
+weight: 12
+time: 5 minutes
+---
+
+## まとめ
+
+このワークショップでは、Splunk Observability Cloud で Cisco AI POD を監視するために使用される
+いくつかの技術のデプロイと操作をハンズオンで体験していただきました。
+具体的には、以下の機会を提供しました。
+
+* GPU ベースのワーカーノードを持つ RedHat OpenShift クラスターでの作業
+* NVIDIA NIM Operator および NVIDIA GPU Operator の操作
+* NVIDIA NIM を使用してクラスターにデプロイされた大規模言語モデル（LLM）の操作
+* Red Hat OpenShift クラスターへの OpenTelemetry Collector のデプロイ
+* インフラストラクチャメトリクスを取り込むための Prometheus レシーバーをコレクターに追加
+* クラスター内の Weaviate ベクトルデータベースの監視
+* Prometheus を使用した Pure Storage メトリクスの監視設定
+* 大規模言語モデル（LLM）と連携する Python サービスを OpenTelemetry で計装
+* LLM と連携するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細の理解
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md
new file mode 100644
index 0000000000..ea1a59d6b0
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md
@@ -0,0 +1,84 @@
+---
+title: OpenShift クラスターへの接続
+linkTitle: 2. OpenShift クラスターへの接続
+weight: 2
+time: 5 minutes
+---
+
+## EC2 インスタンスへの接続
+
+参加者の皆さま向けに、AWS/EC2 上に Ubuntu Linux インスタンスを用意しています。
+
+インストラクターから提供された IP アドレスとパスワードを使って、以下のいずれかの方法で EC2 インスタンスに接続してください。
+
+* Mac OS / Linux
+ * ssh splunk@IP address
+* Windows 10 以降
+ * OpenSSH クライアントを使用してください
+* それ以前のバージョンの Windows
+ * Putty を使用してください
+
+## ワークショップ参加者番号の設定
+
+インストラクターから各参加者に 1 から 30 までの番号が割り当てられます。
+この番号は、ワークショップ全体を通じて使用するため、環境変数に保存し、忘れないようにしてください。
+
+``` bash
+export PARTICIPANT_NUMBER=
+```
+
+## OpenShift CLI のインストール
+
+OpenShift クラスターにアクセスするために、OpenShift CLI をインストールする必要があります。
+
+以下のコマンドを使用して、OpenShift CLI のバイナリを EC2 インスタンスに直接ダウンロードできます。
+
+````
+curl -L -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
+````
+
+ファイルを展開します。
+
+````
+tar -xvzf openshift-client-linux.tar.gz
+````
+
+展開されたファイル（`oc` と `kubectl`）を、PATH に含まれる場所に移動します。例えば次のように実行します。
+
+``` bash
+sudo mv oc /usr/local/bin/oc
+sudo mv kubectl /usr/local/bin/kubectl
+```
+
+## OpenShift クラスターへの接続
+
+splunk ユーザーが Kube 設定ファイルを変更できるようにします。
+
+``` bash
+chmod 600 /home/splunk/.kube/config
+```
+
+ワークショップの主催者から提供されたクラスター API URL とパスワードを使用して、OpenShift クラスターにログインします。
+
+``` bash
+oc login https://api.:443 -u participant$PARTICIPANT_NUMBER -p ''
+```
+
+OpenShift クラスターに接続できていることを確認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+oc whoami --show-server
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+https://api.***.openshiftapps.com:443
+```
+
+{{% /tab %}}
+{{< /tabs >}}
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md
new file mode 100644
index 0000000000..e53a366466
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md
@@ -0,0 +1,146 @@
+---
+title: OpenTelemetry Collectorのデプロイ
+linkTitle: 3. OpenTelemetry collectorのデプロイ
+weight: 3
+time: 10 minutes
+---
+
+このセクションでは、OpenShiftのネームスペースにOpenTelemetry Collectorをデプロイします。
+OpenTelemetry Collectorは、クラスター上で稼働するインフラストラクチャやアプリケーションから
+メトリクス、ログ、トレースを収集し、そのデータをSplunk Observability Cloudに送信します。
+
+## OpenTelemetry Collectorのデプロイ
+
+### Helmのインストール確認
+
+以下のコマンドを実行して、Helmがインストールされていることを確認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+helm version
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+version.BuildInfo{Version:"v3.19.4", GitCommit:"7cfb6e486dac026202556836bb910c37d847793e", GitTreeState:"clean", GoVersion:"go1.24.11"}
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+インストールされていない場合は、以下のコマンドを実行してください。
+
+``` bash
+sudo apt-get install curl gpg apt-transport-https --yes
+curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
+echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
+sudo apt-get update
+sudo apt-get install helm
+```
+
+### Splunk OpenTelemetry Collector Helm Chartの追加
+
+Splunk OpenTelemetry Collector for KubernetesのHelm chartリポジトリを追加します。
+
+```bash
+helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart
+````
+
+リポジトリが最新であることを確認します。
+
+```bash
+helm repo update
+````
+
+### 環境変数の設定
+
+Collectorがデータを送信するSplunk環境を構成するために、環境変数を設定します。
+
+``` bash
+export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER
+export CLUSTER_NAME=ai-pod-$USER_NAME
+export ENVIRONMENT_NAME=ai-pod-$USER_NAME
+export SPLUNK_INDEX=splunk4rookies-workshop
+```
+
+環境名が設定されていることを確認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+echo $ENVIRONMENT_NAME
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` bash
+ai-pod-workshop-participant-1
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### Collectorのデプロイ
+
+ワークショップディレクトリへ移動します。
+
+``` bash
+cd ~/workshop/cisco-ai-pods
+```
+
+次に、以下のコマンドを使用してネームスペースにCollectorをインストールします。
+
+```bash
+{ [ -z "$CLUSTER_NAME" ] || \
+ [ -z "$ENVIRONMENT_NAME" ] || \
+ [ -z "$USER_NAME" ]; } && \
+ echo "Error: Missing variables" || \
+ helm upgrade --install splunk-otel-collector \
+ --set="clusterName=$CLUSTER_NAME" \
+ --set="environment=$ENVIRONMENT_NAME" \
+ --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
+ --set="splunkObservability.realm=$REALM" \
+ --set="splunkPlatform.endpoint=$HEC_URL" \
+ --set="splunkPlatform.token=$HEC_TOKEN" \
+ --set="splunkPlatform.index=$SPLUNK_INDEX" \
+ -f ./otel-collector/otel-collector-values.yaml \
+ -n $USER_NAME \
+ splunk-otel-collector-chart/splunk-otel-collector
+```
+
+> 注: `Missing variables`というエラーが表示された場合は、環境変数を再度定義する必要があります。
+> 以下のコマンドを実行する前に、参加者番号を追加してください。
+>
+> ``` bash
+> export PARTICIPANT_NUMBER=
+> export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER
+> export CLUSTER_NAME=ai-pod-$USER_NAME
+> export ENVIRONMENT_NAME=ai-pod-$USER_NAME
+> export SPLUNK_INDEX=splunk4rookies-workshop
+> ```
+
+以下のコマンドを実行して、Collectorのpodが稼働していることを確認します。
+
+````
+watch -n 1 oc get pods
+
+NAME READY STATUS RESTARTS AGE
+splunk-otel-collector-agent-58rwm 1/1 Running 0 6m40s
+splunk-otel-collector-agent-8dndr 1/1 Running 0 6m40s
+````
+
+> 注: OpenShift環境では、Collectorが起動して`Running`状態に遷移するまでに約3分かかります。
+
+### Splunk Observability CloudでのCollectorデータの確認
+
+**Splunk Observability Cloud**でクラスターが表示されることを確認します。
+**Infrastructure Monitoring** -> **Kubernetes** -> **Kubernetes Clusters**に移動し、
+`k8s.cluster.name`に対して自分のクラスター名（例: `ai-pod-workshop-participant-1`）でフィルターを追加してください。
+
+
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md
new file mode 100644
index 0000000000..137bbbf89e
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md
@@ -0,0 +1,225 @@
+---
+title: NVIDIA コンポーネントの監視
+linkTitle: 4. NVIDIA コンポーネントの監視
+weight: 4
+time: 10 minutes
+---
+
+このセクションでは、OpenTelemetry collector で Prometheus **receiver** を使って、
+OpenShift クラスタ上で稼働している NVIDIA コンポーネントを監視します。
+まず、collector の設定ファイルが格納されているディレクトリへ移動します。
+
+``` bash
+cd otel-collector
+```
+
+## NVIDIA DCGM Exporter のメトリクスを取得する
+
+[NVIDIA DCGM exporter](https://github.com/NVIDIA/dcgm-exporter) は OpenShift クラスタで稼働しています。
+これは Splunk へ送信できる GPU メトリクスを公開しています。
+
+これを行うために、collector のデプロイ時に使用した `otel-collector-values.yaml` ファイルを編集して、
+collector の設定をカスタマイズしましょう。
+
+`kubeletstats` **receiver** の直下に、以下の内容を追加します。
+
+``` yaml
+ receiver_creator/nvidia:
+ # Name of the extensions to watch for endpoints to start and stop.
+ watch_observers: [ k8s_observer ]
+ receivers:
+ prometheus/dcgm:
+ config:
+ config:
+ scrape_configs:
+ - job_name: gpu-metrics
+ scrape_interval: 60s
+ static_configs:
+ - targets:
+ - '`endpoint`:9400'
+ rule: type == "pod" && labels["app"] == "nvidia-dcgm-exporter"
+```
+
+これにより、collector は `app=nvidia-dcgm-exporter` というラベルを持つ Pod を探すようになります。
+このラベルを持つ Pod を見つけると、その Pod のポート 9400 に接続し、
+デフォルトのメトリクスエンドポイント (`/v1/metrics`) をスクレイピングします。
+
+> なぜ **Prometheus** receiver だけでなく **receiver_creator** receiver を使うのでしょうか？
+>
+> * **Prometheus** receiver は、事前に定義されたエンドポイントからメトリクスをスクレイピングする静的な設定を使用します。
+> * **receiver_creator** receiver は、ランタイム情報に基づいて受信機（Prometheus receiver を含む）を動的に作成できるため、スケーラブルで柔軟なスクレイピング構成を実現できます。
+> * **receiver_creator** を使用することで、複数の Prometheus スクレイピング対象の管理を自動化し、動的な環境における設定をシンプルにできます。
+
+この新しい **receiver** が使われるようにするため、`otel-collector-values.yaml` ファイルに新しい **pipeline** も追加する必要があります。
+
+ファイルの末尾に以下のコードを追加します。
+
+``` yaml
+ service:
+ pipelines:
+ metrics/nvidia-metrics:
+ exporters:
+ - signalfx
+ processors:
+ - memory_limiter
+ - batch
+ - resourcedetection
+ - resource
+ receivers:
+ - receiver_creator/nvidia
+```
+
+NVIDIA に関連する Prometheus **receiver** を、次のセクションでもう 1 つ追加します。
+
+## NVIDIA NIM のメトリクスを取得する
+
+`meta-llama-3-2-1b-instruct` 大規模言語モデルは、NVIDIA NIM を使用して OpenShift クラスタにデプロイされています。
+このモデルには、collector でスクレイピング可能な Prometheus エンドポイントが含まれています。
+先ほど追加した `prometheus/dcgm` **receiver** の直下に、以下の内容を `otel-collector-values.yaml` ファイルへ追加します。
+
+``` yaml
+ prometheus/nim-llm:
+ config:
+ config:
+ scrape_configs:
+ - job_name: nim-for-llm-metrics
+ scrape_interval: 60s
+ metrics_path: /v1/metrics
+ static_configs:
+ - targets:
+ - '`endpoint`:8000'
+ rule: type == "pod" && labels["app"] == "meta-llama-3-2-1b-instruct"
+```
+
+これにより、collector は `app=meta-llama-3-2-1b-instruct` というラベルを持つ Pod を探すようになります。
+このラベルを持つ Pod を見つけると、その Pod のポート 8000 に接続し、
+`/v1/metrics` メトリクスエンドポイントをスクレイピングします。
+
+この **receiver** は `receiver_creator/nvidia` receiver の一部として既に取り込まれるため、
+**pipeline** に変更を加える必要はありません。
+
+## Filter Processor を追加する
+
+Prometheus エンドポイントのスクレイピングでは、メトリクスが大量に発生し、カーディナリティが高くなる場合があります。
+
+Splunk へ送信するメトリクスを正確に定義するため、フィルター **processor** を追加しましょう。
+具体的には、ダッシュボードのチャートまたはアラートディテクターで使用されるメトリクス**のみ**を送信するようにします。
+
+`otel-collector-values.yaml` ファイルの **exporters** セクションの後、**receivers** セクションの前に、
+以下のコードを追加します。
+
+``` yaml
+ processors:
+ filter/metrics_to_be_included:
+ metrics:
+ # Include only metrics used in charts and detectors
+ include:
+ match_type: strict
+ metric_names:
+ - DCGM_FI_DEV_FB_FREE
+ - DCGM_FI_DEV_FB_USED
+ - DCGM_FI_DEV_GPU_TEMP
+ - DCGM_FI_DEV_GPU_UTIL
+ - DCGM_FI_DEV_MEM_CLOCK
+ - DCGM_FI_DEV_MEM_COPY_UTIL
+ - DCGM_FI_DEV_MEMORY_TEMP
+ - DCGM_FI_DEV_POWER_USAGE
+ - DCGM_FI_DEV_SM_CLOCK
+ - DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION
+ - DCGM_FI_PROF_DRAM_ACTIVE
+ - DCGM_FI_PROF_GR_ENGINE_ACTIVE
+ - DCGM_FI_PROF_PCIE_RX_BYTES
+ - DCGM_FI_PROF_PCIE_TX_BYTES
+ - DCGM_FI_PROF_PIPE_TENSOR_ACTIVE
+ - generation_tokens_total
+ - go_info
+ - go_memstats_alloc_bytes
+ - go_memstats_alloc_bytes_total
+ - go_memstats_buck_hash_sys_bytes
+ - go_memstats_frees_total
+ - go_memstats_gc_sys_bytes
+ - go_memstats_heap_alloc_bytes
+ - go_memstats_heap_idle_bytes
+ - go_memstats_heap_inuse_bytes
+ - go_memstats_heap_objects
+ - go_memstats_heap_released_bytes
+ - go_memstats_heap_sys_bytes
+ - go_memstats_last_gc_time_seconds
+ - go_memstats_lookups_total
+ - go_memstats_mallocs_total
+ - go_memstats_mcache_inuse_bytes
+ - go_memstats_mcache_sys_bytes
+ - go_memstats_mspan_inuse_bytes
+ - go_memstats_mspan_sys_bytes
+ - go_memstats_next_gc_bytes
+ - go_memstats_other_sys_bytes
+ - go_memstats_stack_inuse_bytes
+ - go_memstats_stack_sys_bytes
+ - go_memstats_sys_bytes
+ - go_sched_gomaxprocs_threads
+ - gpu_cache_usage_perc
+ - gpu_total_energy_consumption_joules
+ - http.server.active_requests
+ - num_request_max
+ - num_requests_running
+ - num_requests_waiting
+ - process_cpu_seconds_total
+ - process_max_fds
+ - process_open_fds
+ - process_resident_memory_bytes
+ - process_start_time_seconds
+ - process_virtual_memory_bytes
+ - process_virtual_memory_max_bytes
+ - promhttp_metric_handler_requests_in_flight
+ - promhttp_metric_handler_requests_total
+ - prompt_tokens_total
+ - python_gc_collections_total
+ - python_gc_objects_collected_total
+ - python_gc_objects_uncollectable_total
+ - python_info
+ - request_finish_total
+ - request_success_total
+ - system.cpu.time
+ - e2e_request_latency_seconds
+ - time_to_first_token_seconds
+ - time_per_output_token_seconds
+ - request_prompt_tokens
+ - request_generation_tokens
+```
+
+先ほど追加した `metrics/nvidia-metrics` **pipeline** に、`filter/metrics_to_be_included` **processor** が含まれていることを確認します。
+
+``` bash
+ service:
+ pipelines:
+ metrics/nvidia-metrics:
+ exporters:
+ - signalfx
+ processors:
+ - memory_limiter
+ - filter/metrics_to_be_included
+ - batch
+ - resourcedetection
+ - resource
+ receivers:
+ - receiver_creator/nvidia
+```
+
+## 変更内容を確認する
+
+少し時間をとって、変更した `otel-collector-values.yaml` ファイルの内容を、
+`otel-collector-values-with-nvidia.yaml` ファイルと比較してみてください。
+`yaml` ファイルではインデントが重要であり、正確である必要があることを覚えておきましょう。
+
+``` bash
+diff otel-collector-values.yaml otel-collector-values-with-nvidia.yaml
+```
+
+内容が一致するように、必要に応じてファイルを更新してください。
+
+{{% notice title="まだ collector を再起動しないでください" style="warning" %}}
+
+OpenShift 環境では collector の再起動にノードあたり 3 分かかるため、
+すべての設定変更が完了するまで待ってから再起動を行います。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md
new file mode 100644
index 0000000000..7d812df197
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md
@@ -0,0 +1,117 @@
+---
+title: ベクターデータベースの監視
+linkTitle: 5. ベクターデータベースの監視
+weight: 5
+time: 5 minutes
+---
+
+このステップでは、Weaviate ベクターデータベースを監視するために Prometheus レシーバーを設定します。
+
+## ベクターデータベースとは
+
+**ベクターデータベース**は、データを数値の「ベクター埋め込み (vector embeddings)」として保存・インデックス化するデータベースで、テキストや画像などの情報の**意味的な意味 (semantic meaning)** を捉えます。従来のデータベースとは異なり、完全一致ではなく概念的に関連したデータポイントを見つける**類似検索 (similarity searches)** に優れています。
+
+## ベクターデータベースの利用方法
+
+ベクターデータベースは、**Retrieval Augmented Generation (RAG)** と呼ばれるパターンで重要な役割を果たします。このパターンは、大規模言語モデル (LLM) を活用するアプリケーションで広く使用されています。
+
+このパターンは次のとおりです。
+
+* エンドユーザーがアプリケーションに質問する
+* アプリケーションが質問を受け取り、ベクター埋め込みを計算する
+* アプリケーションがベクターデータベースで類似検索を行い、関連ドキュメントを探す
+* アプリケーションは元の質問と関連ドキュメントを LLM にコンテキストとして送信する
+* LLM はコンテキストを確認し、アプリケーションに応答を返す
+
+## Prometheus で Weaviate のメトリクスを取得する
+
+OpenTelemetry コレクターの設定を変更して、Weaviate の Prometheus メトリクスをスクレイプするようにします。
+
+そのために、`otel-collector-values.yaml` ファイルに追加の Prometheus **receiver** creator セクションを追加します。`receiver_creator/nvidia` セクションの後、かつ `pipelines` セクションの前に追加してください。
+
+``` yaml
+ receiver_creator/weaviate:
+ # Name of the extensions to watch for endpoints to start and stop.
+ watch_observers: [ k8s_observer ]
+ receivers:
+ prometheus/weaviate:
+ config:
+ config:
+ scrape_configs:
+ - job_name: weaviate-metrics
+ scrape_interval: 60s
+ static_configs:
+ - targets:
+ - '`endpoint`:2112'
+ rule: type == "pod" && labels["app"] == "weaviate"
+```
+
+Weaviate のメトリクスを `filter/metrics_to_be_included` フィルタープロセッサーの設定にも追加する必要があります。
+
+``` yaml
+ processors:
+ filter/metrics_to_be_included:
+ metrics:
+ # Include only metrics used in charts and detectors
+ include:
+ match_type: strict
+ metric_names:
+ - DCGM_FI_DEV_FB_FREE
+ - ...
+ - object_count
+ - vector_index_size
+ - vector_index_operations
+ - vector_index_tombstones
+ - vector_index_tombstone_cleanup_threads
+ - vector_index_tombstone_cleanup_threads
+ - requests_total
+ - objects_durations_ms_sum
+ - objects_durations_ms_count
+ - batch_delete_durations_ms_sum
+ - batch_delete_durations_ms_count
+```
+
+> 注意: `object_count` で始まる新しいメトリクスのみを追加してください
+
+また、設定ファイルに以下の設定で Resource **processor** を追加します。`filter/metrics_to_be_included` **processor** の後、かつ `receivers` セクションの前に追加してください。
+
+``` yaml
+ resource/weaviate:
+ attributes:
+ - key: weaviate.instance.id
+ from_attribute: service.instance.id
+ action: insert
+```
+
+この **processor** は、Weaviate メトリクスの `service.instance.id` プロパティを取得し、`weaviate.instance.id` という新しいプロパティにコピーします。これは、`service.instance.id`（Splunk Observability Cloud で使用される標準的な OpenTelemetry プロパティ）を使用する他のメトリクスと Weaviate メトリクスをより簡単に区別できるようにするためです。
+
+Weaviate メトリクス用の新しいメトリクス **pipeline** も追加する必要があります（`weaviate.instance.id` メトリクスを Weaviate 以外のメトリクスに追加したくないため、別の **pipeline** を使用する必要があります）。ファイルの末尾に次の内容を追加してください。
+
+``` yaml
+ metrics/weaviate:
+ exporters:
+ - signalfx
+ processors:
+ - memory_limiter
+ - filter/metrics_to_be_included
+ - resource/weaviate
+ - batch
+ - resourcedetection
+ - resource
+ receivers:
+ - receiver_creator/weaviate
+```
+
+少し時間をとって、変更した `otel-collector-values.yaml` ファイルの内容を `otel-collector-values-with-weaviate.yaml` ファイルと比較してください。`yaml` ファイルではインデントが重要で、正確である必要があることを忘れないでください。
+
+``` bash
+diff otel-collector-values.yaml otel-collector-values-with-weaviate.yaml
+```
+
+内容が一致するように、必要に応じてファイルを更新してください。
+
+{{% notice title="まだコレクターを再起動しないでください" style="warning" %}}
+
+OpenShift 環境でコレクターを再起動するにはノードあたり 3 分かかるため、すべての設定変更が完了してから再起動を実行します。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/6-monitor-storage.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/6-monitor-storage.md
new file mode 100644
index 0000000000..58846b2560
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/6-monitor-storage.md
@@ -0,0 +1,100 @@
+---
+title: Monitor Storage
+linkTitle: 6. Monitor Storage
+weight: 6
+time: 5 minutes
+---
+
+このステップでは、ストレージを監視するために Prometheus receiver を設定します。
+
+## Cisco AI PODs はどのようなストレージを利用していますか？
+
+Cisco AI PODs には、Pure Storage、VAST、NetApp など、さまざまなストレージオプションがあります。
+
+本ワークショップでは Pure Storage に焦点を当てます。
+
+## Pure Storage のメトリクスをどのように取得しますか？
+
+Pure Storage を利用する Cisco AI PODs は、Kubernetes に永続ストレージを提供する Portworx と呼ばれる技術も利用しています。
+
+Portworx にはメトリクスエンドポイントが含まれており、Prometheus receiver を使ってスクレイピングできます。
+
+## Prometheus でストレージメトリクスを取得する
+
+OpenTelemetry collector の設定を変更し、Prometheus **receiver** で Portworx メトリクスをスクレイピングするようにします。
+
+そのために、`otel-collector-values.yaml` ファイルに Prometheus **receiver creator** セクションを追加します。`receiver_creator/weaviate` セクションの後、`pipelines` セクションの前に追加してください。
+
+``` yaml
+ receiver_creator/storage:
+ # Name of the extensions to watch for endpoints to start and stop.
+ watch_observers: [ k8s_observer ]
+ receivers:
+ prometheus/portworx:
+ config:
+ config:
+ scrape_configs:
+ - job_name: portworx-metrics
+ static_configs:
+ - targets:
+ - '`endpoint`:17001'
+ - '`endpoint`:17018'
+ rule: type == "pod" && labels["app"] == "portworx-metrics-sim"
+```
+
+また、`filter/metrics_to_be_included` フィルタープロセッサーの設定にも Portworx メトリクスが追加されていることを確認する必要があります。
+
+``` yaml
+ processors:
+ filter/metrics_to_be_included:
+ metrics:
+ # Include only metrics used in charts and detectors
+ include:
+ match_type: strict
+ metric_names:
+ - DCGM_FI_DEV_FB_FREE
+ - ...
+ - px_cluster_cpu_percent
+ - px_cluster_disk_total_bytes
+ - px_cluster_disk_utilized_bytes
+ - px_cluster_status_nodes_offline
+ - px_cluster_status_nodes_online
+ - px_volume_read_latency_seconds
+ - px_volume_reads_total
+ - px_volume_readthroughput
+ - px_volume_write_latency_seconds
+ - px_volume_writes_total
+ - px_volume_writethroughput
+```
+
+> 注意: `px_cluster_cpu_percent` から始まる新しいメトリクスのみを追加してください
+
+Portworx メトリクス用の新しいメトリクス **pipeline** も追加する必要があります。ファイルの末尾に以下を追加してください。
+
+``` yaml
+ metrics/storage:
+ exporters:
+ - signalfx
+ processors:
+ - memory_limiter
+ - filter/metrics_to_be_included
+ - batch
+ - resourcedetection
+ - resource
+ receivers:
+ - receiver_creator/storage
+```
+
+ここで、変更した `otel-collector-values.yaml` ファイルの内容を `otel-collector-values-with-portworx.yaml` ファイルと比較してみましょう。`yaml` ファイルではインデントが重要であり、正確である必要があることを覚えておいてください。
+
+``` bash
+diff otel-collector-values.yaml otel-collector-values-with-portworx.yaml
+```
+
+内容が一致するように、必要に応じてファイルを更新してください。
+
+{{% notice title="まだ collector を再起動しないでください" style="warning" %}}
+
+OpenShift 環境では collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動の開始は待ちます。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md
new file mode 100644
index 0000000000..621d385523
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md
@@ -0,0 +1,63 @@
+---
+title: AI POD ダッシュボードの確認
+linkTitle: 7. AI POD ダッシュボードの確認
+weight: 7
+time: 10 minutes
+---
+
+このセクションでは、Splunk Observability Cloud の AI POD ダッシュボードを確認し、NVIDIA、Pure Storage、Weaviate からのデータが期待どおりに取得されていることを確認します。
+
+## OpenTelemetry Collector の設定を更新する
+
+次の Helm コマンドを実行することで、Collector の設定変更を適用できます。
+
+``` bash
+{ [ -z "$CLUSTER_NAME" ] || \
+ [ -z "$ENVIRONMENT_NAME" ] || \
+ [ -z "$USER_NAME" ]; } && \
+ echo "Error: Missing variables" || \
+ helm upgrade splunk-otel-collector \
+ --set="clusterName=$CLUSTER_NAME" \
+ --set="environment=$ENVIRONMENT_NAME" \
+ --set="splunkObservability.accessToken=$ACCESS_TOKEN" \
+ --set="splunkObservability.realm=$REALM" \
+ --set="splunkPlatform.endpoint=$HEC_URL" \
+ --set="splunkPlatform.token=$HEC_TOKEN" \
+ --set="splunkPlatform.index=$SPLUNK_INDEX" \
+ -f ./otel-collector-values.yaml \
+ -n $USER_NAME \
+ splunk-otel-collector-chart/splunk-otel-collector
+```
+
+> 注意: `Missing variables` というエラーが表示された場合は、環境変数を再度定義する必要があります。次のコマンドを実行する前に、参加者番号を追加してください。
+>
+> ``` bash
+> export PARTICIPANT_NUMBER=
+> export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER
+> export CLUSTER_NAME=ai-pod-$USER_NAME
+> export ENVIRONMENT_NAME=ai-pod-$USER_NAME
+> export SPLUNK_INDEX=splunk4rookies-workshop
+> ```
+
+## AI POD Overview ダッシュボードタブの確認
+
+Splunk Observability Cloud で `Dashboards` に移動し、`Built-in dashboard groups` に含まれている `Cisco AI PODs Dashboard` を検索します。
+ダッシュボードが、ご自分の OpenShift クラスター名でフィルタリングされていることを確認してください。
+チャートは次の例のように表示されているはずです。
+
+
+
+## Pure Storage ダッシュボードタブの確認
+
+`PURE STORAGE` タブに移動し、ダッシュボードがご自分の OpenShift クラスター名でフィルタリングされていることを確認します。チャートは次の例のように表示されているはずです。
+
+
+
+## Weaviate Infrastructure Navigator の確認
+
+Weaviate は AI POD にデフォルトで含まれていないため、標準の AI POD ダッシュボードには含まれていません。代わりに、Infrastructure Navigator の 1 つを使用して Weaviate のパフォーマンスデータを表示できます。
+
+Splunk Observability Cloud で、`Infrastructure` -> `AI Frameworks` -> `Weaviate` に移動します。
+対象の `k8s.cluster.name` でフィルタリングし、Navigator が次の例のように表示されていることを確認してください。
+
+
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/8-review-llm-app.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/8-review-llm-app.md
new file mode 100644
index 0000000000..7d53a32f52
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/8-review-llm-app.md
@@ -0,0 +1,112 @@
+---
+title: LLM アプリケーションの確認
+linkTitle: 8. LLM アプリケーションの確認
+weight: 8
+time: 15 minutes
+---
+
+ワークショップの最後のステップでは、instruct モデルと embeddings モデルを使用するアプリケーションを OpenShift クラスターにデプロイします。
+
+## LangChain とは
+
+LLM とやり取りするほとんどのアプリケーションと同様に、このアプリケーションも Python で書かれています。また、[LangChain](https://www.langchain.com/) を使用しています。LangChain は、LLM を活用したアプリケーションの開発を簡素化するオープンソースのオーケストレーションフレームワークです。
+
+## アプリケーションの概要
+
+### LLM への接続
+
+アプリケーションはまず、使用する 2 つの LLM に接続します。
+
+* `meta/llama-3.2-1b-instruct`: ユーザープロンプトへの応答に使用
+* `nvidia/llama-3.2-nv-embedqa-1b-v2`: embeddings の計算に使用
+
+``` python
+# connect to a LLM NIM at the specified endpoint, specifying a specific model
+llm = ChatNVIDIA(base_url=INSTRUCT_MODEL_URL, model="meta/llama-3.2-1b-instruct")
+
+# Initialize and connect to a NeMo Retriever Text Embedding NIM (nvidia/llama-3.2-nv-embedqa-1b-v2)
+embeddings_model = NVIDIAEmbeddings(model="nvidia/llama-3.2-nv-embedqa-1b-v2",
+ base_url=EMBEDDINGS_MODEL_URL)
+```
+
+> なぜ 2 つのモデルがあるのでしょうか？ わかりやすい例えを紹介します。
+>
+> * Embedding モデルは「司書」のような役割です（適切な本を見つける手助けをします）。
+> * Instruct モデルは「執筆者」のような役割です（本を読んで回答を書きます）。
+
+### プロンプトテンプレートの定義
+
+次に、アプリケーションは `meta/llama-3.2-1b-instruct` LLM とのやり取りで使用するプロンプトテンプレートを定義します。
+
+``` python
+prompt = ChatPromptTemplate.from_messages([
+ ("system",
+ "You are a helpful and friendly AI!"
+ "Your responses should be concise and no longer than two sentences."
+ "Do not hallucinate. Say you don't know if you don't have this information."
+ "Answer the question using only the context"
+ "\n\nQuestion: {question}\n\nContext: {context}"
+ ),
+ ("user", "{question}")
+])
+```
+
+> LLM に対して、答えを知らない場合は知らないと明示的に答えるように指示している点に注目してください。これによりハルシネーションを最小限に抑えることができます。また、LLM が質問に答える際に使用できるコンテキストを提供するためのプレースホルダーも用意されています。
+
+### ベクトルデータベースへの接続
+
+次に、アプリケーションは NVIDIA データシートのドキュメントが事前に格納されたベクトルデータベースに接続します。
+
+``` python
+ weaviate_client = weaviate.connect_to_custom(
+ http_host=os.getenv('WEAVIATE_HTTP_HOST'),
+ http_port=os.getenv('WEAVIATE_HTTP_PORT'),
+ http_secure=False,
+ grpc_host=os.getenv('WEAVIATE_GRPC_HOST'),
+ grpc_port=os.getenv('WEAVIATE_GRPC_PORT'),
+ grpc_secure=False
+ )
+
+ vector_store = WeaviateVectorStore(
+ client=weaviate_client,
+ embedding=embeddings_model,
+ index_name="CustomDocs",
+ text_key="page_content"
+ )
+```
+
+### Chain の定義
+
+アプリケーションは **LCEL (LangChain Expression Language)** を使用して chain を定義します。`|` (パイプ) 記号は組み立てラインのように動作し、あるステップの出力が次のステップの入力になります。
+
+``` python
+ chain = (
+ {
+ "context": vector_store.as_retriever(),
+ "question": RunnablePassthrough()
+ }
+ | prompt
+ | llm
+ | StrOutputParser()
+ )
+```
+
+これをステップごとに見ていきましょう。
+
+* **ステップ 1: 入力マップ {…}**: プロンプトのための材料を準備します。
+ * context: ベクトルストアを retriever に変換します。これは検索エンジンのように動作し、ユーザーの質問に基づいて NVIDIA データシートから最も関連性の高い箇所を見つけます。
+ * question: `RunnablePassthrough()` を使用して、ユーザーの元の質問がプロンプトに直接渡されるようにします。
+ * **注意**: これらのキー (context と question) は、先ほどプロンプトテンプレートで定義した `{context}` と `{question}` のプレースホルダーに直接対応しています。
+* **ステップ 2: prompt**: これは指示書です。コンテキストと質問を受け取り、プロンプトテンプレートを使用してフォーマットします (例: "Answer the question using only the context...")。
+* **ステップ 3: llm**: これは「エンジン」です (GPT-4 のようなもの)。フォーマットされたプロンプトを読み取り、応答を生成します。
+* **ステップ 4: StrOutputParser()**: デフォルトでは、AI モデルは複雑なオブジェクトを返します。この「クリーナー」により、シンプルで読みやすいテキスト文字列を取得できます。
+
+### Chain の呼び出し
+
+最後に、アプリケーションはエンドユーザーの質問を入力として渡すことで chain を呼び出します。
+
+``` python
+ response = chain.invoke(question)
+```
+
+これは「スタート」ボタンです。エンドユーザーの質問をパイプラインの最初に投入すると、retriever、prompt、LLM を経由して、最終的に答えが反対側から出てきます。
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md
new file mode 100644
index 0000000000..79bd546ece
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md
@@ -0,0 +1,78 @@
+---
+title: Instrument the LLM Application
+linkTitle: 9. Instrument the LLM Application
+weight: 9
+time: 10 minutes
+---
+
+## OpenTelemetry でアプリケーションを計装する
+
+### 計装パッケージ
+
+アプリケーションからメトリクス、トレース、ログを取得するために、OpenTelemetry で計装しています。
+そのために、`requirements.txt` ファイルに次のパッケージを追加する必要がありました（最終的に `pip install` でインストールされます）。
+
+````
+splunk-opentelemetry==2.8.0
+````
+
+また、このアプリケーションのコンテナイメージをビルドするために使用する `Dockerfile` に、追加の OpenTelemetry 計装パッケージをインストールするための以下を追記しました。
+
+``` dockerfile
+# Add additional OpenTelemetry instrumentation packages
+RUN opentelemetry-bootstrap --action=install
+```
+
+次に、アプリケーション実行時に `opentelemetry-instrument` を呼び出すよう、`Dockerfile` の `ENTRYPOINT` を変更しました。
+
+``` dockerfile
+ENTRYPOINT ["opentelemetry-instrument", "flask", "run", "-p", "8080", "--host", "0.0.0.0"]
+```
+
+最後に、この LangChain アプリケーションから OpenTelemetry で収集するトレースとメトリクスを強化するため、追加の Splunk 計装パッケージを追加しました。
+
+````
+splunk-otel-instrumentation-langchain==0.1.4
+splunk-otel-util-genai==0.1.4
+````
+
+### 環境変数
+
+OpenTelemetry でアプリケーションを計装するために、アプリケーションのデプロイに使用する Kubernetes マニフェストファイルにいくつかの環境変数も追加しました。
+
+``` yaml
+ env:
+ - name: OTEL_SERVICE_NAME
+ value: "llm-app"
+ - name: OTEL_EXPORTER_OTLP_ENDPOINT
+ value: "http://splunk-otel-collector-agent:4317"
+ - name: OTEL_EXPORTER_OTLP_PROTOCOL
+ value: "grpc"
+ # filter out health check requests to the root URL
+ - name: OTEL_PYTHON_EXCLUDED_URLS
+ value: "^(https?://)?[^/]+(/)?$"
+ - name: OTEL_PYTHON_DISABLED_INSTRUMENTATIONS
+ value: "httpx,requests"
+ - name: OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT
+ value: "true"
+ - name: OTEL_LOGS_EXPORTER
+ value: "otlp"
+ - name: OTEL_PYTHON_LOG_CORRELATION
+ value: "true"
+ - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
+ value: "delta"
+ - name: OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED
+ value: "true"
+ - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT
+ value: "true"
+ - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE
+ value: "SPAN_AND_EVENT"
+ - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS
+ value: "span_metric_event,splunk"
+ - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS_EVALUATION
+ value: "replace-category:SplunkEvaluationResults"
+ - name: SPLUNK_PROFILER_ENABLED
+ value: "true"
+```
+
+`OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT` と `OTEL_INSTRUMENTATION_GENAI_*` の環境変数は、ここで使用している LangChain 計装に固有のものである点に注意してください。
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/_index.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/_index.md
new file mode 100644
index 0000000000..60fa1b258d
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/_index.md
@@ -0,0 +1,14 @@
+---
+title: Workshop
+linkTitle: 2. Workshop
+weight: 2
+---
+
+このセクションでは、ワークショップ参加者が実施する手順を紹介します。
+
+* Red Hat OpenShift クラスターに **OpenTelemetry Collector** をデプロイする練習を行います。
+* インフラストラクチャメトリクスを取り込むために、Collector へ **Prometheus** レシーバーを追加する練習を行います。
+* クラスター内の **Weaviate** ベクトルデータベースを監視する練習を行います。
+* Prometheus を使って **Pure Storage** のメトリクスを収集する練習を行います。
+* 大規模言語モデル (LLMs) と連携する Python サービスを **OpenTelemetry** で計装する練習を行います。
+* LLMs と連携するアプリケーションのトレースから、OpenTelemetry がどのような情報を取得しているかを理解します。
diff --git a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/_index.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/_index.md
new file mode 100644
index 0000000000..2142eaf575
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/_index.md
@@ -0,0 +1,31 @@
+---
+title: Splunk Observability Cloud で Cisco AI Pods を監視する
+linkTitle: Splunk Observability Cloud で Cisco AI Pods を監視する
+weight: 14
+archetype: chapter
+time: 60 minutes
+authors: ["Derek Mitchell"]
+description: Red Hat OpenShift 上に OpenTelemetry Collector をデプロイし、Prometheus 経由で Cisco AI Pod のメトリクスをスクレイピングしながら、LLM を呼び出す Python サービスをトレースします。
+draft: false
+hidden: false
+aliases:
+ - /ninja-workshops/14-cisco-ai-pods/
+---
+
+**Cisco の AI-ready POD** は、ハードウェアとソフトウェアの優れた技術を組み合わせ、多様なニーズに対応する堅牢でスケーラブルかつ効率的な AI 対応インフラを実現します。
+
+**Splunk Observability Cloud** は、こうしたインフラ全体に加え、このスタック上で稼働するすべてのアプリケーションコンポーネントに対する包括的な可視化を提供します。
+
+Cisco AI POD 環境向けに Splunk Observability Cloud を構成する手順は [完全なドキュメント](https://github.com/signalfx/splunk-opentelemetry-examples/tree/main/collector/cisco-ai-ready-pods) として公開されています。
+
+ただし、インストール手順を実際に試すために Cisco AI POD 環境へアクセスできるとは限りません。
+
+このワークショップでは、実際の Cisco AI POD へのアクセスを必要とせずに、Splunk Observability Cloud で Cisco AI POD を監視する際に使用される複数の技術をデプロイし、操作するハンズオン体験を提供します。具体的には次の内容を扱います。
+
+* Red Hat OpenShift クラスタへの **OpenTelemetry Collector** のデプロイを実践します。
+* Collector に **Prometheus** レシーバーを追加し、インフラメトリクスを取り込む方法を実践します。
+* **Weaviate** ベクターデータベースをクラスタにデプロイする方法を実践します。
+* 大規模言語モデル (LLM) と連携する Python サービスを **OpenTelemetry** で計装する方法を実践します。
+* LLM と連携するアプリケーションのトレースから、OpenTelemetry がどのような詳細情報を取得するかを理解します。
+
+> 注: ワークショップのセットアップセクションは、ワークショップ主催者のみが実行する必要があります。
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/1-deploy-otel.md b/content/ja/ninja-workshops/infrastructure/2-hpa/1-deploy-otel.md
new file mode 100644
index 0000000000..df82f289cd
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/1-deploy-otel.md
@@ -0,0 +1,113 @@
+---
+title: Kubernetes における OpenTelemetry Collector のデプロイ
+linkTitle: 1. OTel Collector のデプロイ
+weight: 1
+---
+
+## 1. EC2 インスタンスへの接続
+
+ワークショップインスタンスへは、Mac、Linux、Windows いずれのデバイスからも SSH を使用して接続できます。インストラクターから提供されたシートのリンクを開いてください。このシートには、ワークショップインスタンスの IP アドレスとパスワードが記載されています。
+
+{{% notice style="info" %}}
+ワークショップインスタンスには、本ワークショップ用の正しい **Access Token** と **Realm** が事前に設定されています。これらを設定する必要はありません。
+{{% /notice %}}
+
+## 2. Helm を使用した Splunk OTel のインストール
+
+Splunk Helm chart を使用して OpenTelemetry Collector をインストールします。まず、Splunk Helm chart リポジトリを追加し、更新します。
+
+{{< tabs >}}
+{{% tab title="helm repo add" %}}
+
+```bash
+helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart && helm repo update
+```
+
+{{% /tab %}}
+{{% tab title="helm repo add output" %}}
+
+```text
+Using ACCESS_TOKEN=
+Using REALM=eu0
+"splunk-otel-collector-chart" has been added to your repositories
+Using ACCESS_TOKEN=
+Using REALM=eu0
+Hang tight while we grab the latest from your chart repositories...
+...Successfully got an update from the "splunk-otel-collector-chart" chart repository
+Update Complete. ⎈Happy Helming!⎈
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+以下のコマンドで OpenTelemetry Collector の Helm をインストールします。このコマンドは編集**しないでください**。
+
+{{< tabs >}}
+{{% tab title="helm install" %}}
+
+``` bash
+helm install splunk-otel-collector --version {{< otel-version >}} \
+--set="splunkObservability.realm=$REALM" \
+--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
+--set="clusterName=$INSTANCE-k3s-cluster" \
+--set="splunkPlatform.endpoint=$HEC_URL" \
+--set="splunkPlatform.token=$HEC_TOKEN" \
+--set="splunkPlatform.index=splunk4rookies-workshop" \
+splunk-otel-collector-chart/splunk-otel-collector \
+-f ~/workshop/k3s/otel-collector.yaml
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## 3. デプロイの確認
+
+`kubectl get pods` を実行することで、デプロイの進行状況を監視できます。通常、約 30 秒後に新しい Pod が起動して実行中であることが報告されます。
+
+続行する前に、ステータスが **Running** と報告されていることを確認してください。
+
+{{< tabs >}}
+{{% tab title="kubectl get pods" %}}
+
+``` bash
+kubectl get pods
+```
+
+{{% /tab %}}
+{{% tab title="kubectl get pods Output" %}}
+
+``` text
+NAME READY STATUS RESTARTS AGE
+splunk-otel-collector-agent-ks9jn 1/1 Running 0 27s
+splunk-otel-collector-agent-lqs4j 0/1 Running 0 27s
+splunk-otel-collector-agent-zsqbt 1/1 Running 0 27s
+splunk-otel-collector-k8s-cluster-receiver-76bb6b555-7fhzj 0/1 Running 0 27s
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+`helm` インストール時に設定されたラベルを使って、ログを tail します（終了するには `ctrl + c` を押す必要があります）。
+
+{{< tabs >}}
+{{% tab title="kubectl logs" %}}
+
+``` bash
+kubectl logs -l app=splunk-otel-collector -f --container otel-collector
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+または、インストール済みの `k9s` ターミナル UI を使用することもできます。
+
+
+
+{{% notice title="失敗したインストールの削除" style="warning" %}}
+Splunk OpenTelemetry Collector のインストール中にエラーが発生した場合は、以下のコマンドでインストールを削除してやり直すことができます。
+
+``` sh
+helm delete splunk-otel-collector
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/2-k8s-namespaces-dns.md b/content/ja/ninja-workshops/infrastructure/2-hpa/2-k8s-namespaces-dns.md
new file mode 100644
index 0000000000..ddf80f21fb
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/2-k8s-namespaces-dns.md
@@ -0,0 +1,41 @@
+---
+title: K8s Namespaces and DNS
+linkTitle: 2. K8s Namespaces and DNS
+weight: 2
+---
+
+## 1. Kubernetes における Namespace
+
+ほとんどのお客様は、Kubernetes を実行するために何らかのプライベートまたはパブリッククラウドサービスを利用します。中央集約的に管理しやすいため、大規模な Kubernetes クラスターを少数だけ運用する選択をされることがよくあります。
+
+Namespace は、こうした大規模な Kubernetes クラスターを仮想的なサブクラスターに整理する仕組みです。複数のチームやプロジェクトが Kubernetes クラスターを共有する場合に、それぞれのチームが自分たちのリソースだけを簡単に確認して操作できるようになるため、便利な機能です。
+
+クラスター内では任意の数の Namespace がサポートされ、それぞれが論理的に分離されつつも、相互に通信できる能力を持っています。コンポーネントは Namespace を選択した場合、または `kubectl` に `--all-namespaces` フラグを追加した場合にのみ**表示**されます。これにより、自分の Namespace を選択することで、プロジェクトに関連するコンポーネントだけを表示できます。
+
+ほとんどのお客様は、アプリケーションを個別の Namespace にインストールしたいと考えるでしょう。本ワークショップではそのベストプラクティスに従います。
+
+## 2. Kubernetes における DNS と Service
+
+Domain Name System (DNS) は、IP アドレスのようなさまざまな情報を、覚えやすい名前と紐付けるための仕組みです。リクエスト名を IP アドレスに変換する DNS システムを使用することで、エンドユーザーは目的のドメイン名に容易にアクセスできます。
+
+ほとんどの Kubernetes クラスターには、サービスディスカバリーのための軽量なアプローチを提供するため、デフォルトで内部 DNS サービスが構成されています。Pod や Service が作成、削除、またはノード間で移動された場合でも、組み込みのサービスディスカバリーにより、アプリケーションは Kubernetes クラスター上の Service を簡単に識別して通信できます。
+
+要するに、Kubernetes 用の DNS システムは、各 Pod および Service に対して DNS エントリを作成します。一般に、Pod は次のような DNS 解決を持ちます。
+
+``` text
+pod-name.my-namespace.pod.cluster-domain.example
+```
+
+例えば、`default` Namespace 内の Pod が `my_pod` という Pod 名を持ち、クラスターのドメイン名が `cluster.local` である場合、その Pod の DNS 名は次のようになります。
+
+``` text
+my_pod.default.pod.cluster.local
+```
+
+Service によって公開された Pod では、次のような DNS 解決が利用できます。
+
+``` text
+my_pod.service-name.my-namespace.svc.cluster-domain.example
+```
+
+詳細は次を参照してください: [**DNS for Service and Pods**](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/3-apache-otel-receiver.md b/content/ja/ninja-workshops/infrastructure/2-hpa/3-apache-otel-receiver.md
new file mode 100644
index 0000000000..9394a5ff43
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/3-apache-otel-receiver.md
@@ -0,0 +1,105 @@
+---
+title: Apache OTel Receiver
+linkTitle: 3. Apache OTel Receiver
+weight: 3
+---
+
+## 1. PHP/Apache 用 OTel receiver の確認
+
+YAML ファイル `~/workshop/k3s/otel-apache.yaml` を確認するため、以下のコマンドで内容を検証します。
+
+``` bash
+cat ~/workshop/k3s/otel-apache.yaml
+```
+
+このファイルには、PHP/Apache デプロイメントを監視するための OpenTelemetry エージェントの設定が含まれています。
+
+```yaml
+agent:
+ config:
+ receivers:
+ receiver_creator:
+ receivers:
+ apache:
+ rule: type == "port" && pod.name matches "apache" && port == 80
+ config:
+ endpoint: http://php-apache-svc.apache.svc.cluster.local/server-status?auto
+```
+
+## 2. OpenTelemetry 設定における Observation Rule
+
+上記のファイルには、OTel の `receiver_creator` を用いた Apache の観測ルール（observation rule）が含まれています。この receiver は、観測されたエンドポイントが設定されたルールに合致するかどうかに基づき、実行時に他の receiver をインスタンス化できます。
+
+設定されたルールは、検出された各エンドポイントに対して評価されます。ルールが true と評価されると、そのルールに対応する receiver が、合致したエンドポイントに対して設定通りに起動されます。
+
+上記のファイルでは、OpenTelemetry エージェントに、名前が `apache` に合致し、ポート `80` が開いている Pod を探すように指示しています。見つかると、エージェントは設定された URL から Apache メトリクスを読み取るように Apache receiver を構成します。なお、上記の YAML 内のサービスに対する URL は、K8s の DNS ベースの URL になっている点に注意してください。
+
+Apache の設定を利用するには、以下のコマンドで既存の Splunk OpenTelemetry Collector Helm チャートをアップグレードし、`otel-apache.yaml` ファイルを利用するようにします。
+
+{{< tabs >}}
+{{% tab title="Helm Upgrade" %}}
+
+``` bash
+helm upgrade splunk-otel-collector \
+--set="splunkObservability.realm=$REALM" \
+--set="splunkObservability.accessToken=$ACCESS_TOKEN" \
+--set="clusterName=$INSTANCE-k3s-cluster" \
+--set="splunkPlatform.endpoint=$HEC_URL" \
+--set="splunkPlatform.token=$HEC_TOKEN" \
+--set="splunkPlatform.index=splunk4rookies-workshop" \
+splunk-otel-collector-chart/splunk-otel-collector \
+-f ~/workshop/k3s/otel-collector.yaml \
+-f ~/workshop/k3s/otel-apache.yaml
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+{{% notice title="NOTE" style="info" %}}
+デプロイメントの **REVISION** 番号が変更されており、これは変更履歴を追跡するのに役立ちます。
+
+``` text
+Release "splunk-otel-collector" has been upgraded. Happy Helming!
+NAME: splunk-otel-collector
+LAST DEPLOYED: Mon Nov 4 14:56:25 2024
+NAMESPACE: default
+STATUS: deployed
+REVISION: 2
+TEST SUITE: None
+NOTES:
+Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Platform endpoint "https://http-inputs-workshop.splunkcloud.com:443/services/collector/event".
+
+Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm eu0.
+```
+
+{{% /notice %}}
+
+## 3. Kubernetes ConfigMaps
+
+ConfigMap は、アプリケーションに注入可能なキーと値のペアで構成される Kubernetes のオブジェクトです。ConfigMap を利用することで、設定を Pod から分離できます。
+
+ConfigMap を使うことで、設定データのハードコーディングを避けられます。ConfigMap は、機密性のない暗号化されていない設定情報を保存・共有するのに便利です。
+
+OpenTelemetry collector/agent は、エージェントと K8s Cluster receiver の設定を保存するために ConfigMap を使用します。変更後にエージェントの現在の設定を確認するには、いつでも以下のコマンドを実行できます。
+
+``` bash
+kubectl get cm
+```
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+collector はいくつの ConfigMap を使用していますか？
+{{% /notice %}}
+
+namespace 内の ConfigMap 一覧を取得したら、`otel-agent` 用のものを選択し、以下のコマンドで内容を確認します。
+
+``` bash
+kubectl get cm splunk-otel-collector-otel-agent -o yaml
+```
+
+{{% notice title="NOTE" style="info" %}}
+`-o yaml` オプションを指定すると、ConfigMap の内容が読みやすい YAML 形式で出力されます。
+{{% /notice %}}
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+`otel-apache.yaml` の設定が、collector agent の ConfigMap で確認できますか？
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/4-deploy-apache.md b/content/ja/ninja-workshops/infrastructure/2-hpa/4-deploy-apache.md
new file mode 100644
index 0000000000..b448eef75c
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/4-deploy-apache.md
@@ -0,0 +1,94 @@
+---
+title: Deploy Apache
+linkTitle: 4. Deploy Apache
+weight: 4
+---
+
+## 1. PHP/Apache のデプロイメント YAML を確認する
+
+YAML ファイル `~/workshop/k3s/php-apache.yaml` を確認し、以下のコマンドで内容を検証します。
+
+``` bash
+cat ~/workshop/k3s/php-apache.yaml
+```
+
+ このファイルには PHP/Apache のデプロイメント構成が含まれており、PHP/Apache イメージのレプリカを 1 つ持つ新しい StatefulSet を作成します。
+
+ステートレスなアプリケーションは、使用するネットワークを問わず、永続的なストレージも必要としません。ステートレスアプリの例としては、Apache、Nginx、Tomcat などの Web サーバーが挙げられます。
+
+```yaml
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+ name: php-apache
+spec:
+ updateStrategy:
+ type: RollingUpdate
+ selector:
+ matchLabels:
+ run: php-apache
+ serviceName: "php-apache-svc"
+ replicas: 1
+ template:
+ metadata:
+ labels:
+ run: php-apache
+ spec:
+ containers:
+ - name: php-apache
+ image: ghcr.io/splunk/php-apache:latest
+ ports:
+ - containerPort: 80
+ resources:
+ limits:
+ cpu: "8"
+ memory: "8Mi"
+ requests:
+ cpu: "6"
+ memory: "4Mi"
+
+---
+apiVersion: v1
+kind: Service
+metadata:
+ name: php-apache-svc
+ labels:
+ run: php-apache
+spec:
+ ports:
+ - port: 80
+ selector:
+ run: php-apache
+```
+
+## 2. PHP/Apache をデプロイする
+
+`apache` ネームスペースを作成し、PHP/Apache アプリケーションをクラスターにデプロイします。
+
+`apache` ネームスペースを作成します。
+
+``` bash
+kubectl create namespace apache
+```
+
+PHP/Apache アプリケーションをデプロイします。
+
+``` bash
+kubectl apply -f ~/workshop/k3s/php-apache.yaml -n apache
+```
+
+デプロイメントが作成されたことを確認します。
+
+``` bash
+kubectl get statefulset -n apache
+```
+
+{{% notice title="ワークショップの質問" style="tip" icon="question" %}}
+**Apache web servers (OTel) Navigator** では、Apache インスタンスに関するどのようなメトリクスがレポートされていますか？
+{{% /notice %}}
+
+{{% notice title="ワークショップの質問" style="tip" icon="question" %}}
+Log Observer を使用して、PHP/Apache デプロイメントの問題点は何ですか？
+
+**ヒント:** フィルターを次のように調整してください: `k8s.namespace.name = apache` および `k8s.cluster.name = `。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/5-fix-apache.md b/content/ja/ninja-workshops/infrastructure/2-hpa/5-fix-apache.md
new file mode 100644
index 0000000000..0ba967ee4f
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/5-fix-apache.md
@@ -0,0 +1,130 @@
+---
+title: Fix PHP/Apache Issue
+linkTitle: 5. Fix PHP/Apache Issue
+weight: 5
+---
+## 1. Kubernetes リソース
+
+特に本番環境の Kubernetes クラスターでは、CPU とメモリは貴重なリソースとみなされます。クラスター運用者は通常、Pod やサービスがデプロイ時に必要とする CPU とメモリの量を指定するよう求めます。これにより、クラスターはどの Node にソリューションを配置するかを自動的に管理できます。
+
+これを実現するには、アプリケーションや Pod のデプロイメントに Resource セクションを記述します。
+
+**例:**
+
+``` yaml
+resources:
+ limits: # Maximum amount of CPU & memory for peek use
+ cpu: "8" # Maximum of 8 cores of CPU allowed at for peek use
+ memory: "8Mi" # Maximum allowed 8Mb of memory
+ requests: # Request are the expected amount of CPU & memory for normal use
+ cpu: "6" # Requesting 4 cores of a CPU
+ memory: "4Mi" # Requesting 4Mb of memory
+```
+
+詳細はこちらを参照してください: [**Resource Management for Pods and Containers**](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)
+
+アプリケーションや Pod がデプロイメントに設定された制限を超えた場合、Kubernetes は他のアプリケーションを保護するために Pod を停止して再起動します。
+
+もう 1 つ遭遇するシナリオは、Node に十分なメモリや CPU がない場合です。この場合、クラスターはより多くの空きがある別の Node に Pod を再スケジュールしようとします。
+
+それも失敗した場合、またはアプリケーションのデプロイ時に十分な空きがない場合、クラスターはワークロード/デプロイメントをスケジュール待ちモードにし、利用可能な Node のいずれかに、設定された制限に従って Pod をデプロイできる十分な空きが確保されるまで待機します。
+
+## 2. PHP/Apache デプロイメントの修正
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+
+開始する前に、PHP/Apache デプロイメントの現在の状態を確認しましょう。**Alerts & Detectors** の下で、どの Detector が発火していますか? この情報は他にどこで確認できますか?
+
+{{% /notice %}}
+
+PHP/Apache の StatefulSet を修正するには、次のコマンドで `~/workshop/k3s/php-apache.yaml` を編集して CPU リソースを減らします。
+
+``` bash
+vim ~/workshop/k3s/php-apache.yaml
+```
+
+resources セクションを見つけて、CPU の limits を **1** に、CPU の requests を **0.5** に減らします。
+
+``` yaml
+resources:
+ limits:
+ cpu: "1"
+ memory: "8Mi"
+ requests:
+ cpu: "0.5"
+ memory: "4Mi"
+```
+
+変更を保存します。(ヒント: `Esc` の後に `:wq!` で変更を保存します)
+
+次に、既存の StatefulSet を削除して再作成する必要があります。StatefulSet はイミュータブルであるため、既存のものを削除し、新しい変更を反映して再作成する必要があります。
+
+``` bash
+kubectl delete statefulset php-apache -n apache
+```
+
+それでは、変更をデプロイします。
+
+``` bash
+kubectl apply -f ~/workshop/k3s/php-apache.yaml -n apache
+```
+
+## 3. 変更の検証
+
+次のコマンドを実行して、変更が適用されたことを検証できます。
+
+``` bash
+kubectl describe statefulset php-apache -n apache
+```
+
+Splunk Observability Cloud で Pod が稼働していることを確認します。
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+**Apache Web Servers** ダッシュボードにデータが表示されていますか?
+
+**ヒント:** フィルターと時間範囲を使ってデータを絞り込むことを忘れないでください。
+{{% /notice %}}
+
+Apache Web サーバーの Navigator ダッシュボードを数分間モニタリングします。
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+
+# Hosts reporting チャートでは何が起こっていますか?
+
+{{% /notice %}}
+
+## 4. メモリ問題の修正
+
+Apache ダッシュボードに戻ると、メトリクスが届かなくなっていることに気づくでしょう。別のリソース問題が発生しており、今回はメモリ不足です。次の画像のように StatefulSet を編集してメモリを増やしましょう。
+
+``` bash
+kubectl edit statefulset php-apache -n apache
+```
+
+``` yaml
+resources:
+ limits:
+ cpu: "1"
+ memory: 16Mi
+ requests:
+ cpu: 500m
+ memory: 12Mi
+```
+
+変更を保存します。
+
+{{% notice title="Hint" style="info" icon="exclamation" %}}
+`kubectl edit` は `vi` エディターでコンテンツを開きます。`Esc` の後に `:wq!` を入力して変更を保存してください。
+{{% /notice %}}
+
+StatefulSet はイミュータブルであるため、既存の Pod を削除し、新しい変更を反映して StatefulSet が再作成するようにします。
+
+``` bash
+kubectl delete pod php-apache-0 -n apache
+```
+
+次のコマンドを実行して、変更が適用されたことを検証します。
+
+``` bash
+kubectl describe statefulset php-apache -n apache
+```
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/6-deploy-loadgen.md b/content/ja/ninja-workshops/infrastructure/2-hpa/6-deploy-loadgen.md
new file mode 100644
index 0000000000..5854add210
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/6-deploy-loadgen.md
@@ -0,0 +1,88 @@
+---
+title: 負荷生成ツールのデプロイ
+linkTitle: 6. 負荷生成ツールのデプロイ
+weight: 6
+---
+
+それでは `php-apache` Pod に対して負荷をかけてみましょう。これを行うには、クライアントとして動作する別の Pod を起動する必要があります。クライアント Pod 内のコンテナは無限ループで動作し、`php-apache` サービスに対して HTTP GET リクエストを送信し続けます。
+
+## 1. loadgen YAML の確認
+
+YAML ファイル `~/workshop/k3s/loadgen.yaml` を確認し、以下のコマンドで内容を検証します。
+
+``` bash
+cat ~/workshop/k3s/loadgen.yaml
+```
+
+このファイルには負荷生成ツールの設定が含まれており、負荷生成イメージのレプリカを 2 つ持つ新しい ReplicaSet を作成します。
+
+``` yaml
+apiVersion: apps/v1
+kind: ReplicaSet
+metadata:
+ name: loadgen
+ labels:
+ app: loadgen
+spec:
+ replicas: 2
+ selector:
+ matchLabels:
+ app: loadgen
+ template:
+ metadata:
+ name: loadgen
+ labels:
+ app: loadgen
+ spec:
+ containers:
+ - name: infinite-calls
+ image: busybox
+ command:
+ - /bin/sh
+ - -c
+ - "while true; do wget -q -O- http://php-apache-svc.apache.svc.cluster.local; done"
+```
+
+## 2. 新しい namespace を作成する
+
+``` text
+kubectl create namespace loadgen
+```
+
+## 3. loadgen YAML をデプロイする
+
+``` text
+kubectl apply -f ~/workshop/k3s/loadgen.yaml --namespace loadgen
+```
+
+負荷生成ツールをデプロイすると、`loadgen` namespace で Pod が稼働している様子を確認できます。これまでと同様のコマンドを使い、コマンドラインから Pod のステータスを確認してください。
+
+{{% notice title="ワークショップの設問" style="tip" icon="question" %}}
+Apache Navigator のどのメトリクスが大幅に増加したでしょうか？
+{{% /notice %}}
+
+## 4. 負荷生成ツールをスケールする
+
+ReplicaSet は、Pod の複数インスタンスを稼働させ、指定された数の Pod を一定に保つプロセスです。その目的は、クラスター内で指定された数の Pod インスタンスを常に稼働させることで、Pod が障害を起こしたりアクセスできなくなったりした際にユーザーがアプリケーションへアクセスできなくなることを防ぐことにあります。
+
+ReplicaSet は、既存の Pod が障害を起こしたときに新しいインスタンスを立ち上げたり、稼働中のインスタンス数が指定数に満たない場合にスケールアップしたり、同じラベルを持つインスタンスが別途作成された場合に Pod をスケールダウンまたは削除したりすることを支援します。ReplicaSet は、指定された数の Pod レプリカが継続的に稼働していることを保証し、リソース使用率の増加時には負荷分散にも役立ちます。
+
+以下のコマンドで ReplicaSet を 4 レプリカにスケールしてみましょう。
+
+``` text
+kubectl scale replicaset/loadgen --replicas 4 -n loadgen
+```
+
+コマンドラインと Splunk Observability Cloud の両方から、レプリカが稼働していることを検証してください。
+
+``` text
+kubectl get replicaset loadgen -n loadgen
+```
+
+
+
+{{% notice title="ワークショップの設問" style="tip" icon="question" %}}
+Apache Navigator にどのような影響が見られるでしょうか？
+{{% /notice %}}
+
+負荷生成ツールを 2〜3 分ほど稼働させ、Kubernetes Navigator と Apache Navigator のメトリクスを継続して観察してください。
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/7-setup-hpa.md b/content/ja/ninja-workshops/infrastructure/2-hpa/7-setup-hpa.md
new file mode 100644
index 0000000000..f49ad0044d
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/7-setup-hpa.md
@@ -0,0 +1,92 @@
+---
+title: Setup Horizontal Pod Autoscaling (HPA)
+linkTitle: 7. Setup HPA
+weight: 7
+---
+
+Kubernetes において、HorizontalPodAutoscaler はワークロードリソース（Deployment や StatefulSet など）を自動的に更新し、需要に合わせてワークロードを自動スケールさせます。
+
+水平スケーリングとは、負荷の増加に対してより多くの Pod をデプロイすることで対応することを意味します。これは垂直スケーリングとは異なります。Kubernetes における垂直スケーリングとは、ワークロード用にすでに稼働している Pod により多くのリソース（メモリや CPU など）を割り当てることを指します。
+
+負荷が減少し、Pod の数が設定された最小値を上回っている場合、HorizontalPodAutoscaler はワークロードリソース（Deployment、StatefulSet、またはその他の類似リソース）にスケールダウンするよう指示します。
+
+## 1. Setup HPA
+
+`~/workshop/k3s/hpa.yaml` ファイルを確認し、次のコマンドで内容を検証します:
+
+``` bash
+cat ~/workshop/k3s/hpa.yaml
+```
+
+このファイルには Horizontal Pod Autoscaler の設定が含まれており、`php-apache` デプロイメント用に新しい HPA を作成します。
+
+``` yaml
+apiVersion: autoscaling/v2
+kind: HorizontalPodAutoscaler
+metadata:
+ name: php-apache
+ namespace: apache
+spec:
+ maxReplicas: 4
+ metrics:
+ - type: Resource
+ resource:
+ name: cpu
+ target:
+ averageUtilization: 50
+ type: Utilization
+ - type: Resource
+ resource:
+ name: memory
+ target:
+ averageUtilization: 75
+ type: Utilization
+ minReplicas: 1
+ scaleTargetRef:
+ apiVersion: apps/v1
+ kind: StatefulSet
+ name: php-apache
+```
+
+デプロイされると、`php-apache` は平均 CPU 使用率が 50% を超えるか、デプロイメントの平均メモリ使用率が 75% を超えた場合に、最小 1 Pod から最大 4 Pod の範囲で自動スケールします。
+
+``` text
+kubectl apply -f ~/workshop/k3s/hpa.yaml
+```
+
+## 2. Validate HPA
+
+``` text
+kubectl get hpa -n apache
+```
+
+Kubernetes の **Workloads** または **Node Detail** タブに移動し、HPA のデプロイメントを確認します。
+
+{{% notice title="Workshop Questions" style="tip" icon="question" %}}
+
+1. 追加で作成された `php-apache-x` Pod はいくつありますか？
+2. **Apache web servers (OTel) Navigator** のどのメトリクスが再び大幅に増加しましたか？
+
+{{% /notice %}}
+
+## 3. Increase the HPA replica count
+
+`maxReplicas` を 8 に増やします。
+
+``` bash
+kubectl edit hpa php-apache -n apache
+```
+
+変更を保存します。（ヒント: `Esc` を押した後 `:wq!` で変更を保存します）。
+
+{{% notice title="Workshop Questions" style="tip" icon="question" %}}
+
+1. 現在いくつの Pod が稼働していますか？
+
+2. いくつの Pod が pending 状態ですか？
+
+3. なぜ pending 状態なのですか？
+
+{{% /notice %}}
+
+**Congratulations!** ワークショップは完了です。
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/_index.md b/content/ja/ninja-workshops/infrastructure/2-hpa/_index.md
new file mode 100644
index 0000000000..14e2d9e439
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/_index.md
@@ -0,0 +1,18 @@
+---
+title: Kubernetes における Horizontal Pod Autoscaling のモニタリング
+linkTitle: Horizontal Pod Autoscaling
+description: Splunk OpenTelemetry Collector で Kubernetes HPA をモニタリングし、スケールアップおよびスケールダウンのイベントをリアルタイムで観察します。
+weight: 2
+authors: ["Robert Castley"]
+time: 45 minutes
+aliases:
+ - /ninja-workshops/2-hpa/
+---
+
+このハンズオンワークショップでは、Splunk OpenTelemetry Collector を使用して Kubernetes の Horizontal Pod Autoscaling (HPA) をモニタリングする方法を学びます。PHP/Apache アプリケーションと負荷生成ツールをデプロイして自動スケーリングイベントを発生させ、スケーリングのライフサイクル全体を観察します。
+
+実践的な演習を通じて、OpenTelemetry Receiver、Kubernetes Namespace、ReplicaSet、および HPA の仕組みを探求しながら、すべてを Splunk Observability Cloud でモニタリングします。Kubernetes Navigator を使いこなし、カスタムダッシュボードを構築し、メトリクスとイベントを分析し、スケーリングアクティビティに対するアラートを通知する Detector を設定します。
+
+このワークショップ用に、Splunk が AWS/EC2 上に Ubuntu Linux インスタンスを事前構成して用意しています。
+
+ワークショップで使用するインスタンスへのアクセス方法については、ワークショップリーダーから提供される URL をご確認ください。
diff --git a/content/ja/ninja-workshops/infrastructure/2-hpa/kubernetes-navigator.md b/content/ja/ninja-workshops/infrastructure/2-hpa/kubernetes-navigator.md
new file mode 100644
index 0000000000..716f40e332
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/2-hpa/kubernetes-navigator.md
@@ -0,0 +1,120 @@
+---
+title: Kubernetes Navigator のツアー
+linkTitle: 2. Kubernetes Navigator
+weight: 2
+hidden: true
+---
+
+## 1. Cluster ビューと Workload ビュー
+
+Kubernetes Navigator では、Kubernetes データを表示するための 2 つの異なるユースケースが提供されています。
+
+* **K8s workloads** はワークロード、つまり *デプロイメント* に関する情報の提供にフォーカスしています。
+* **K8s nodes** はクラスター、ノード、Pod、コンテナのパフォーマンスに関するインサイトの提供にフォーカスしています。
+
+最初に必要に応じてどちらかのビューを選択します（必要であればビューを動的に切り替えることもできます）。このワークショップで主に使用するのは workload ビューであり、こちらに焦点を当てて進めていきます。
+
+### 1.1 K8s クラスター名の確認
+
+最初のタスクは、ご自身のクラスターを特定することです。クラスターは事前構成された環境変数 `INSTANCE` に基づいて命名されています。クラスター名を確認するため、ターミナルで以下のコマンドを実行してください。
+
+``` bash
+echo $INSTANCE-k3s-cluster
+```
+
+ワークショップの後半でフィルタリングに使用するため、クラスター名をメモしておいてください。
+
+## 2. Workloads と Workload Details ペイン
+
+Observability UI で **Infrastructure** ページに移動し、**Kubernetes** を選択します。Kubernetes サービスのセットが表示され、その中の 1 つが **Kubernetes workloads** ペインです。このペインには小さなグラフが表示され、すべてのワークロードで処理されている負荷を俯瞰的に確認できます。**Kubernetes workloads** ペインをクリックすると、workload ビューに移動します。
+
+最初は、Observability Cloud Org にレポートされているすべてのクラスターのすべてのワークロードが表示されます。いずれかのワークロードでアラートが発火している場合は、下の画像の右上にハイライト表示されます。
+
+
+
+それでは、フィルターツールバーの **Cluster** でフィルタリングして、ご自身のクラスターを見つけましょう。
+
+{{% notice title="Note" style="info" %}}
+検索ボックスに `emea-ws-7*` のような部分一致の名前を入力すると、素早くクラスターを見つけることができます。
+
+また、デフォルトの時間を **-4h** から直近 15 分（**-15m**）に変更しておくことを強くおすすめします。
+{{% /notice %}}
+
+
+
+これで、ご自身のクラスターのデータのみが表示されるようになりました。
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+ご自身のクラスターでは、いくつのワークロードが実行されており、いくつの Namespace がありますか？
+{{% /notice %}}
+
+### 2.1 Navigator Selection Chart の使用
+
+デフォルトでは、**Kubernetes Workloads** テーブルは `k8s.namespace.name` でグループ化された `# Pods Failed` でフィルタリングされています。`default` namespace を展開して、その namespace 内のワークロードを確認しましょう。
+
+
+
+次に、**Map** アイコン（**Table** アイコンの隣）を選択してリストビューをヒートマップビューに変更しましょう。このオプションを変更すると、以下のような可視化（または類似のもの）になります。
+
+
+
+このビューでは、各ワークロードが色付きの四角形になっていることがわかります。これらの四角形は、選択した **Color by** オプションに応じて色が変化します。色は健全性や使用状況を視覚的に示しています。ヒートマップ右下の **legend** の感嘆符アイコン {{% icon icon="exclamation-circle" %}} にカーソルを合わせると、その意味を確認できます。
+
+この画面のもう 1 つの便利なオプションが **Find outliers** で、**Color by** ドロップダウンで選択された内容に基づいて、クラスターの履歴分析を提供します。
+
+それでは、**Color by** ドロップダウンボックスから **Network transferred (bytes)** を選択し、**Find outliers** をクリックして、ダイアログ内の **Scope** を **Per k8s.namespace.name** に、**Deviation from Median** を以下のように変更しましょう。
+
+
+
+**Find Outliers** ビューは、ワークロード（または使用している Navigator によっては任意のサービス）の一部を確認し、何かが変化したかどうかを素早く把握する必要があるときに非常に便利です。
+
+通常とは異なる動作（増加・減少どちらの場合も）をしているアイテム（ここではワークロード）を素早くインサイトとして得られるため、問題の発見が容易になります。
+
+### 2.2 Deployment Overview ペイン
+
+Deployment Overview ペインでは、デプロイメントのステータスを素早く把握できます。デプロイメントの Pod が Pending、Running、Succeeded、Failed、Unknown のいずれの状態にあるかを一目で確認できます。
+
+
+
+* *Running:* Pod がデプロイされ、実行中の状態
+* *Pending:* デプロイ待ちの状態
+* *Succeeded:* Pod がデプロイされ、ジョブが完了して終了した状態
+* *Failed:* Pod 内のコンテナが実行され、何らかのエラーを返した状態
+* *Unknown:* Kubernetes が既知のいずれの状態も報告していない状態（例えば Pod の起動中や停止中など）
+
+ワークロード名がチャートで表示しきれない場合は、名前にカーソルを合わせると展開できます。
+
+特定のワークロードにフィルタリングするには、**k8s.workload.name** 列のワークロード名の隣にある 3 つのドット **...** をクリックし、ドロップダウンから **Filter** を選択します。
+
+
+
+これにより、選択したワークロードがフィルターに追加されます。その結果、**default** namespace 内の単一のワークロードがリスト表示されます。
+
+
+
+上記のヒートマップから、**default** namespace 内の **splunk-otel-collector-k8s-cluster-receiver** を見つけ、四角形をクリックしてワークロードに関する詳細情報を確認します。
+
+
+
+{{% notice title="Workshop Question" style="tip" icon="question" %}}
+otel-collector の CPU request と CPU limit の単位はそれぞれ何ですか？
+{{% /notice %}}
+
+この時点で Pod の情報をさらに掘り下げて確認することもできますが、それは本ワークショップの範囲外です。
+
+## 3. Navigator Sidebar
+
+ワークショップの後半で、クラスターに Apache サーバーをデプロイすると、**Navigator Sidebar** にアイコンが表示されます。
+
+Kubernetes 用の Navigator では、依存するサービスやコンテナを Navigator Sidebar で追跡できます。Navigator Sidebar を最大限に活用するには、`service.name` という追加 dimension を構成して、追跡したいサービスを設定します。本ワークショップでは、Apache を監視するために、コレクター構成内の `extraDimensions` を以下のようにすでに構成しています。
+
+```yaml
+extraDimensions:
+ service.name: php-apache
+```
+
+下の画像のように、Navigator Sidebar が展開され、検出されたサービスへのリンクが追加されます。
+
+
+
+これにより、Navigator 間を簡単に切り替えることができます。同じことが Apache サーバーインスタンスにも当てはまり、Navigator Sidebar から Kubernetes Navigator にすばやく戻ることができます。
diff --git a/content/ja/ninja-workshops/infrastructure/_index.md b/content/ja/ninja-workshops/infrastructure/_index.md
new file mode 100644
index 0000000000..7cf7f7bf44
--- /dev/null
+++ b/content/ja/ninja-workshops/infrastructure/_index.md
@@ -0,0 +1,8 @@
+---
+title: Infrastructure & Platform
+linkTitle: Infrastructure
+weight: 3
+description: Kubernetes のスケーリングや Cisco AI Pods のようなプラットフォーム固有のスタックを監視します。
+time: 1 hour 45 minutes
+layout: "hero"
+---
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/1-workshop-overview/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/1-workshop-overview/_index.md
new file mode 100644
index 0000000000..364ea07dae
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/1-workshop-overview/_index.md
@@ -0,0 +1,132 @@
+---
+title: ワークショップの概要
+linkTitle: 1. ワークショップの概要
+weight: 1
+archetype: chapter
+time: 5 minutes
+description: OBI ワークショップの目標、前提条件、アーキテクチャ。
+---
+
+## このワークショップで学ぶこと
+
+このワークショップを終える頃には、次のことができるようになります。
+
+- eBPF が Linux カーネルレベルでのゼロコード計装をどのように実現するかを理解する
+- ベアホスト上で動作中のアプリケーションを OBI バイナリで計装する
+- ポリグロット（複数言語）のマイクロサービススタックを Docker Compose でデプロイし、コンテナ 1 つで分散トレーシングを追加する
+- 同じスタックを Splunk OTel Collector Helm chart を使って Kubernetes にデプロイし、フラグ 1 つで OBI を有効化する
+- Splunk APM をナビゲートして、分散トレース、サービスマップ、リクエストフローを確認する
+
+## 前提条件
+
+ワークショップインスタンスには必要なものがすべて事前構成されています。
+
+| 要件 | ワークショップインスタンスでの状態 |
+|---|---|
+| Linux ホスト | 提供済み（Ubuntu） |
+| Python 3.9+ | インストール済み |
+| Docker & Docker Compose | インストール済み |
+| K3s（Kubernetes） | インストール済み |
+| kubectl | インストール済み |
+| Helm 3 | インストール済み |
+| ワークショップアセット | `~/workshop/obi/` にデプロイ済み |
+
+さらに次のものも必要です。
+
+| 要件 | 入手方法 |
+|---|---|
+| Splunk Observability Cloud アカウント | インストラクターから提供されます |
+| **Splunk Access Token**（Ingest） | インスタンスで `env` と入力し、`ACCESS_TOKEN` を確認してください |
+| **Splunk Realm**（例：`us0`、`us1`、`eu0`） | インスタンスで `env` と入力し、`REALM` を確認してください |
+| **一意の名前**（例：`shw-2c74`） | `env` で `INSTANCE` を確認してください。`host.name` として使用されます |
+
+## アーキテクチャ
+
+このワークショップでは、リクエストチェーンを構成する 3 つのシンプルなマイクロサービスを使用します。
+
+```text
+Frontend (Node.js :3000) → Order-Processor (Go :8080) → Payment-Service (Go :8081)
+```
+
+これらのサービスには **オブザーバビリティに関するコードが一切ありません**。OpenTelemetry SDK もトレーシングヘッダーも、いかなる計装もありません。OBI は eBPF プローブを使用してカーネルからこれらのサービスを計装し、OpenTelemetry 互換のトレースを生成して、Splunk OTel Collector に送信します。Collector はそれを Splunk Observability Cloud に転送します。
+
+## OBI とは何か
+
+[OBI（OpenTelemetry eBPF Instrumentation）](https://opentelemetry.io/docs/zero-code/obi/) は、Linux カーネルの eBPF プローブを使用して、アプリケーションを流れる HTTP/gRPC トラフィックを観測するスタンドアロンエージェントです。**カーネルから** プロセスにアタッチします。SDK もコード変更も再コンパイルも不要です。リクエストを観測し、OpenTelemetry 互換のトレーススパンを生成して、Collector に送信します。
+
+これは、SDK で計装することが **できない** または **したくない** 組織にとって価値があります。
+
+- ソースコードにアクセスできないレガシーシステム
+- 再コンパイルが選択肢にないコンパイル済み言語
+- 開発者の抵抗（「計装を追加する時間がない」）
+- あらゆるコード変更が完全な監査サイクルをトリガーしてしまう規制上の制約
+
+## 価値提案
+
+多くの組織には、OpenTelemetry SDK で計装することが **できない** または **したくない** アプリケーションがあります。
+
+- **レガシーシステム**：COBOL から Java への移行、10 年前の .NET Framework アプリ、ソースアクセスなしのベンダー提供バイナリ
+- **コンパイル済み言語**：再コンパイルが選択肢にない、またはチームが移ってしまった Go、Rust、C++ サービス
+- **開発者の抵抗**：「時間がない」「スプリントに入っていない」「動いているコードは変更しない」
+- **規制上の制約**：あらゆるコード変更が完全な監査・認証サイクルをトリガーする
+
+OBI は **コード変更なしで完全な分散トレーシング** を提供します。
+
+- **SDK 統合不要**：import も依存関係もコンパイル時の変更も不要
+- **アプリケーション再起動不要**：OBI は eBPF を介してすでに実行中のプロセスにアタッチします
+- **言語非依存**：Go、Node.js、Python、Java、Rust、C++、その他 HTTP または gRPC を話すあらゆるものに対応
+- **コンテナ 1 つまたは Helm フラグ 1 つ**：compose に追加するか、Helm chart で `obi.enabled=true` を有効化するだけで完了
+
+## OBI と従来のゼロコード計装の比較
+
+OBI と既存の従来型の言語固有ゼロコード計装（Java、JS、.NET、Python、Go、PHP）は、オブザーバビリティ戦略において互いを補完する役割を果たします。違いを理解することで、どのアプローチをいつ使うべきか判断できます。
+
+### 1. 計装モデル
+
+| 観点 | OBI | 従来のゼロコード計装 |
+|---|---|---|
+| 実行モデル | プロセス外 | プロセス内 |
+| 計装レイヤー | Linux カーネル / ネットワーク | アプリケーションランタイム |
+| コード変更が必要か | 不要 | 不要または最小限 |
+| アプリケーション再起動が必要か | 不要 | 必要 |
+| セキュリティプロファイル | 隔離 | アプリケーションと同じ権限プロファイル |
+
+### 2. 可視性のレベル
+
+| 機能 | OBI | 従来のゼロコード計装 |
+|---|---|---|
+| 分散トレーシング | プロトコルレベル | フルフィデリティ |
+| RED メトリクス | 対応 | 対応 |
+| アプリケーションログの収集 | 非対応 | 対応 |
+| アプリケーションのログとトレースの相関 | 対応 | 対応 |
+| アプリケーション内部（フレームワーク、関数） | 非対応（部分的、主に Go） | 対応 |
+| カスタムスパン / ビジネス属性 | 非対応 | 対応 |
+| ランタイムメトリクス（JVM、メモリ、スレッド） | 現時点では非対応 | 対応 |
+
+### 3. カバレッジと互換性
+
+| シナリオ | OBI | 従来のゼロコード計装 |
+|---|---|---|
+| マルチ言語環境 | 強力（プロトコルベース） | 言語固有 |
+| サードパーティアプリケーション | 対応 | 限定的、contrib リポジトリ |
+| レガシーシステム | 対応 | 限定的 |
+| コンパイル済み言語（C/C++/Rust） | 対応（async に一部制限あり） | 限定的 |
+| 非同期 / 複雑なフレームワーク | 一部のケースで制限あり | 強力 |
+
+### 4. 運用上の特性
+
+| 観点 | OBI | 従来のゼロコード計装 |
+|---|---|---|
+| デプロイ作業量 | 低（ドロップイン） | 中（エージェントアタッチ） |
+| 最初の可視化までの時間 | 数分 | より長い数分 |
+| アプリケーションライフサイクルへの変更 | なし | あり |
+| パフォーマンスオーバーヘッド | 最小限かつ隔離 | 言語/ランタイムによる |
+
+### 5. Splunk Distro の機能
+
+| 機能 | OBI | 従来のゼロコード計装 |
+|---|---|---|
+| Always-on Profiling | 非対応（将来 eBPF プロファイラーと統合される可能性あり） | ほとんどで CPU、一部でメモリに対応 |
+| コールグラフ | 非対応 | ほとんどで CPU、一部でメモリに対応 |
+| ファイルベースの設定 | 対応予定 | Java、Node.js、.NET、Python（対応予定） |
+| ノーコード計装 | 該当なし | 対応 |
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/1-install-and-run.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/1-install-and-run.md
new file mode 100644
index 0000000000..7a4a56a743
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/1-install-and-run.md
@@ -0,0 +1,90 @@
+---
+title: 1. アプリのインストールと実行
+weight: 1
+---
+
+## Python 環境のセットアップ
+
+Phase 0 のディレクトリに移動し、仮想環境を作成します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+cd ~/workshop/obi/01-obi-python
+python3 -m venv .venv
+source .venv/bin/activate
+pip3 install -r requirements.txt
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+Collecting flask>=3.0,<4.0
+ Downloading ...
+Successfully installed flask-3.x.x ...
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Splunk 認証情報の設定
+
+認証情報を環境変数としてエクスポートします。各プレースホルダーを実際の値に置き換えてください。
+
+{{% notice title="Exercise" style="green" icon="running" %}}
+`env` を実行したときに、環境変数として `ACCESS_TOKEN`、`REALM`、`INSTANCE` の値が設定されている必要があります。
+
+**設定されていない場合は、次のようにエクスポートしてください**
+
+``` bash
+export ACCESS_TOKEN=""
+export REALM=""
+export INSTANCE=""
+```
+
+{{% /notice %}}
+
+## アプリの実行
+
+Flask アプリをバックグラウンドで起動します。
+
+``` bash
+python3 app.py &
+```
+
+起動時に、アプリは `app.heartbeat` メトリクスを Splunk Ingest API に直接 1 件送信します。次のような出力が表示されます。
+
+``` text
+Heartbeat sent to Splunk (200)
+ * Running on http://0.0.0.0:5150
+```
+
+まず Return キーを押してプロンプトに戻ります。
+次に、エンドポイントにアクセスして動作を確認します。
+
+``` bash
+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!"
+}
+```
+
+## 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) します）。
+2. 設定した値と一致する `host.name` 属性を持つメトリクスが表示されているはずです。
+
+
+
+{{% notice title="Note" style="info" %}}
+この時点で、アプリは稼働しており、Splunk がデータを受信できることも確認できました。しかし、**トレースは 1 件もありません**。APM は空のままです。アプリには計装コードがまったく組み込まれていないからです。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md
new file mode 100644
index 0000000000..7f472d501e
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md
@@ -0,0 +1,97 @@
+---
+title: 2. OBI でインストルメントする
+weight: 2
+---
+
+実行中のこのアプリケーションに対して、**コードを 1 行も変更することなく** APM トレーシングを追加します。
+
+## OBI のダウンロード
+
+[GitHub releases page](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases) からビルド済みの OBI バイナリをダウンロードします。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+```bash
+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"
+sha256sum -c SHA256SUMS --ignore-missing
+tar -xzf "obi-v$VERSION-linux-$ARCH.tar.gz"
+ls -la ./obi
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+```text
+obi-v0.6.0-linux-amd64.tar.gz: OK
+-rwxr-xr-x 1 splunk splunk 112345678 Feb 27 14:47 ./obi
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## OBI の実行
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**別のターミナル** で、`sudo` を使って OBI を実行します。3 つのプレースホルダーを、前のステップで取得した realm、token、hostname に置き換えてください（完了までに 1 〜 2 分かかる場合があります）。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+```bash
+cd ~/workshop/obi/01-obi-python
+
+sudo env \
+ OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="https://ingest.${REALM}.signalfx.com:443" \
+ OTEL_EXPORTER_OTLP_TRACES_PROTOCOL="grpc" \
+ OTEL_EXPORTER_OTLP_HEADERS="X-SF-Token=${ACCESS_TOKEN}" \
+ OTEL_SERVICE_NAME="warmup-app" \
+ OTEL_RESOURCE_ATTRIBUTES="deployment.environment=ebpf-bare-app,host.name=${INSTANCE}" \
+ OTEL_EBPF_OPEN_PORT=5150 \
+ ./obi
+```
+
+{{% /tab %}}
+{{% tab title="Look for this in your Output" %}}
+トラフィックを生成し、次のような出力が表示されることを確認します。
+
+```text
+...
+time=2026-02-27T19:29:56.296Z level=INFO msg="instrumenting process" component=discover.traceAttacher cmd=/usr/bin/python3.10 pid=245031 ino=7094 type=python service=warmup-app logenricher=false
+...
+time=2026-02-27T19:29:58.278Z level=INFO msg="Launching p.Tracer" component=generic.Tracer
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+{{% /notice %}}
+
+### これらの変数の役割
+
+| 変数 | 目的 |
+|---|---|
+| `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 に指示します |
+
+{{% notice title="Note" style="info" %}}
+OBI のログに `failed to upload metrics: 404 Not Found` のような警告が表示されることがあります。これは想定された動作です。Splunk の direct ingest には標準の OTLP メトリクスエンドポイントが存在しないためです。トレースは引き続き正しくエクスポートされます。Phase 2 では、collector がトレースとメトリクスの両方を適切に処理します。
+{{% /notice %}}
+
+## トラフィックの生成
+
+最初のターミナルに戻り、いくつかリクエストを生成します。
+
+```bash
+for i in $(seq 1 20); do curl -s "http://localhost:5150/hello"; sleep 1; done
+```
+
+***NOTE:*** 404 エラーが発生した場合、curl で指定している URL の末尾に `\` が付いていないか再確認してください。一部のターミナルでは `;` がエスケープされ、不正な URL になることがあります。
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md
new file mode 100644
index 0000000000..8fa44878e8
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md
@@ -0,0 +1,35 @@
+---
+title: 3. Splunk APM での確認
+weight: 3
+---
+
+## Splunk APM の確認
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+1. Splunk Observability Cloud で **APM** に移動します。
+2. サービス名 `warmup-app` でフィルタリングします。
+3. `/hello` エンドポイントのトレースが表示されているはずです。
+**注意: 最初のトレースが取り込まれるまで数分かかる場合があります**
+
+{{% /notice %}}
+
+## 何が起こったのか?
+
+1. Flask アプリは「裸」の状態で、オブザーバビリティのコードはまったく含まれていません。hello を返すこととハートビートメトリクスを送信することしかできません。
+2. OBI はカーネルのネットワーキングスタックに eBPF プローブをアタッチし、アプリのプロセスを通過する HTTP トラフィックを観察しました。
+3. OBI は OpenTelemetry 互換のトレーススパンを生成し、Splunk に直接送信しました。
+
+**カーネルから実行中のプロセスに分散トレーシングを追加したことになります。SDK もコード変更も再起動も不要です。**
+
+これは Phase 1 と 2 で使用するのと同じテクノロジーですが、ベアプロセスではなく Docker コンテナ内で動作します。
+
+## Phase 0 のクリーンアップ
+
+次に進む前に、Python アプリと OBI を停止します。
+
+``` bash
+kill %1 2>/dev/null
+sudo pkill -f ./obi 2>/dev/null
+deactivate
+```
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/_index.md
new file mode 100644
index 0000000000..7a85c2613a
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/2-python-warmup/_index.md
@@ -0,0 +1,16 @@
+---
+title: "Phase 0: Python ウォームアップ"
+linkTitle: 2. Python ウォームアップ
+weight: 2
+archetype: chapter
+time: 15 minutes
+description: ホスト上で素の Python アプリを実行し、カスタムメトリクスで Splunk への接続性を確認した後、Docker を使わずに OBI バイナリで APM トレーシングを追加します。
+---
+
+このフェーズでは、OBI が素の Linux プロセスに対して**カーネルレベル**で動作することを確認します。コンテナもサイドカーも SDK も不要で、カーネルからアプリを監視する eBPF バイナリだけで動きます。
+
+このセクションの終わりまでに、以下が完成します。
+
+1. observability コードがゼロの状態で動作する Python Flask アプリ
+2. Splunk org がデータを受信していることの証明（カスタムメトリクス経由）
+3. コード変更ゼロでカーネルから追加された、アプリの完全な APM トレース
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md
new file mode 100644
index 0000000000..7482b87d36
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md
@@ -0,0 +1,72 @@
+---
+title: 1. スタックの構成と起動
+weight: 1
+---
+
+## Splunk 認証情報の追加
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+**注意:** ご自身の環境で `ACCESS_TOKEN`、`REALM`、`INSTANCE` を取得してください。これらを config に貼り付ける必要があります。
+
+``` 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 つのプレースホルダー値を実際の認証情報に置き換えます。
+
+``` yaml
+ environment:
+ SPLUNK_INGEST_TOKEN: "YOUR_ACCESS_TOKEN_HERE" # <-- Your Splunk ingest token
+ SPLUNK_REALM: "YOUR_REALM" # <-- Your realm (us0, us1, eu0, etc.)
+ WORKSHOP_HOST_NAME: "" # <-- the value from INSTANCE when you use `env` on terminal
+ WORKSHOP_ENVIRONMENT: "" # <-- The hostname value above suffixed with `-ebpf`
+```
+
+ファイルを保存します。
+
+{{% /notice %}}
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+**なぜ `WORKSHOP_HOST_NAME` と `WORKSHOP_ENVIRONMENT` が必要なのか？** ワークショップの参加者全員が同じ Splunk org にテレメトリを送信します。これらの値は、すべてのメトリクスとトレースに `host.name` および `deployment.environment` 属性として設定されるため、Splunk 上で**自分の**データだけをフィルタリングできます。
+{{% /notice %}}
+
+## スタックの起動
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+docker-compose up --build -d
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+[+] Building 12.3s (24/24) FINISHED
+[+] Running 6/6
+ ✔ Container 02-obi-docker-payment-service-1 Started
+ ✔ Container 02-obi-docker-order-processor-1 Started
+ ✔ Container 02-obi-docker-frontend-1 Started
+ ✔ Container 02-obi-docker-splunk-otel-collector-1 Started
+ ✔ Container 02-obi-docker-load-generator-1 Started
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+このコマンドが完了するまで数分かかります。3 つのアプリケーションイメージをソースからビルドし、以下を起動します。
+
+- **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/instrumentation/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md
new file mode 100644
index 0000000000..90760a02ab
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md
@@ -0,0 +1,47 @@
+---
+title: 2. トラフィックの生成
+weight: 2
+---
+
+## フロントエンドへのアクセス
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+curl を使ってトラフィックを生成します。
+
+``` bash
+curl -s http://localhost:3000/create-order | jq
+```
+
+{{% /notice %}}
+
+次のような JSON レスポンスが返ってくるはずです。
+
+``` json
+{
+ "order": "confirmed",
+ "payment": {
+ "status": "success",
+ "transaction_id": "txn-a1b2c3d4e5f6",
+ "amount": 42
+ }
+}
+```
+
+リクエストは 3 つのサービスすべてを経由しました。しかし、現時点では誰もそれを観測していません。
+
+## コードを確認する
+
+少し時間を取ってソースコードを調査し、計装が一切行われていないことを確認しましょう。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+``` bash
+grep -r "opentelemetry\|otel\|tracing\|instrument" ~/workshop/obi/02-obi-docker/frontend/
+grep -r "opentelemetry\|otel\|tracing\|instrument" ~/workshop/obi/02-obi-docker/order-processor/
+grep -r "opentelemetry\|otel\|tracing\|instrument" ~/workshop/obi/02-obi-docker/payment-service/
+```
+
+{{% /notice %}}
+
+3 つのコマンドはいずれも何も返しません。アプリケーションコードのどこにも、**トレーシングヘッダーも、SDK も、計装も一切存在しません**。
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md
new file mode 100644
index 0000000000..94bdf6f0ca
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md
@@ -0,0 +1,30 @@
+---
+title: 3. Splunk で確認する
+weight: 3
+---
+
+## インフラストラクチャメトリクスを確認する
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+1. [Metric Finder](https://app.us1.signalfx.com/#/metrics) を開く（または [チャートを作成](https://app.us1.signalfx.com/#/chart/new?template=default&filters=sf_metric%3Aworkshop_heartbeat)）して `workshop_heartbeat` を検索します。
+2. `host.name` が `WORKSHOP_HOST_NAME` の値と一致するメトリクスが表示されるはずです。
+3. その `host.name` で検索して、collector が送信している他のメトリクス（CPU、メモリ、ディスクなど）を確認します。
+
+{{% /notice %}}
+
+## APM が空であることを確認する
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+1. Splunk Observability Cloud で **APM** に移動します。
+2. 定義した environment（`WORKSHOP_ENVIRONMENT`）でフィルタします。
+3. **空** になっている（または存在しない）はずです。サービスもトレースもサービスマップもありません。
+
+{{% /notice %}}
+
+collector はデフォルトの動作としてインフラストラクチャメトリクスを送信していますが、トレースを生成するものがないため、エクスポートするトレースはありません。
+
+{{% notice title="Note" style="info" %}}
+これが「before」の状態です。実際のリクエストを処理する 3 つのサービスが稼働していますが、Splunk APM はそれらのリクエストをまったく可視化できていません。次のセクションでは、**アプリケーションコードに手を加えることなく** これを解決します。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/_index.md
new file mode 100644
index 0000000000..51374dc5ac
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/3-docker-before-obi/_index.md
@@ -0,0 +1,14 @@
+---
+title: "Phase 1: Docker (Before OBI)"
+linkTitle: 3. Docker Before OBI
+weight: 3
+archetype: chapter
+time: 15 minutes
+description: Docker Compose で 3 つのマイクロサービスをデプロイし、APM が空であることを確認します。インストルメンテーションがないため、トレースは一切存在しません。
+---
+
+このフェーズでは、ポリグロット（またこの言葉です！）なマイクロサービススタックをデプロイし、「Before」の状態を確立します。インフラストラクチャメトリクスは Splunk に流れますが、アプリケーションにはインストルメンテーションが一切ないため、APM にトレースは 1 件もありません。
+
+```text
+Frontend (Node.js :3000) → Order-Processor (Go :8080) → Payment-Service (Go :8081)
+```
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md
new file mode 100644
index 0000000000..2c58c2a2d9
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md
@@ -0,0 +1,80 @@
+---
+title: 1. OBI サービスの追加
+weight: 1
+---
+
+## docker-compose.yaml に OBI を追加する
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+エディタで `docker-compose.yaml` を開きます。
+
+``` bash
+cd ~/workshop/obi/02-obi-docker
+docker-compose down
+vim docker-compose.yaml #or editor of choice
+```
+
+ファイルの一番下までスクロールすると、`PHASE 2` というコメントブロックがあります。**そのコメントの直下**に以下のブロックを貼り付けます。`frontend:` や `load-generator:` などの他のサービスと揃うように、**2スペースのインデント**を維持してください。
+
+``` yaml
+ obi:
+ image: otel/ebpf-instrument:main
+ pid: host
+ privileged: true
+ network_mode: host
+ volumes:
+ - ./obi-config.yaml:/config/obi-config.yaml
+ - /sys/fs/cgroup:/sys/fs/cgroup
+ environment:
+ OTEL_EBPF_CONFIG_PATH: /config/obi-config.yaml
+```
+
+**注意:** vim で貼り付ける際は、貼り付け前に `:set paste` を実行するとフォーマットが維持されます。
+
+ファイルを保存します。
+
+{{% /notice %}}
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+`obi:` が 2 スペースインデントされていること（`frontend:` や `load-generator:` などと同じレベル）を確認してください。インデントなしで一番左にある場合、Docker Compose は `Additional property obi is not allowed` というエラーで拒否します。`services:` ブロックの**内側**に配置する必要があります。
+{{% /notice %}}
+
+### 各行の役割
+
+| 行 | 内容 | 重要性 |
+|---|---|---|
+| `image: otel/ebpf-instrument:main` | [OBI コンテナイメージ](https://hub.docker.com/r/otel/ebpf-instrument) | スタックに追加するのはこれだけです |
+| `pid: host` | ホストの PID 名前空間を共有します | OBI が**他の**コンテナで実行されているプロセスを参照できる必要があります |
+| `privileged: true` | カーネルレベルのアクセス権を付与します | eBPF プログラムはカーネル関数にプローブをアタッチする必要があります |
+| `network_mode: host` | ホストのネットワークスタックを共有します | コンテキスト伝播に必要です。OBI はネットワークレベルでトレースコンテキストを注入します |
+| `volumes: ./obi-config.yaml:...` | サービスディスカバリ設定をマウントします | OBI に対して、計装するプロセスとその名前を指定します |
+| `volumes: /sys/fs/cgroup:...` | cgroup ファイルシステムをマウントします | OBI はこれを使用して、コンテナ内で実行されているプロセスを検出します |
+| `OTEL_EBPF_CONFIG_PATH` | コンテナ内の設定ファイルを指定します | OBI 設定用の標準環境変数です |
+
+## OBI を起動する
+
+Docker Compose は `obi` サービスのみが新規であることを検出し、それを起動します。既存のサービスはそのまま実行され続けます。
+
+{{< tabs >}}
+{{% tab title="スクリプト" %}}
+
+``` bash
+docker-compose up -d
+```
+
+{{% /tab %}}
+{{% tab title="出力例" %}}
+
+``` text
+[+] Running 6/6
+ ✔ Container 02-obi-docker-payment-service-1 Running
+ ✔ Container 02-obi-docker-order-processor-1 Running
+ ✔ Container 02-obi-docker-frontend-1 Running
+ ✔ Container 02-obi-docker-splunk-otel-collector-1 Running
+ ✔ Container 02-obi-docker-load-generator-1 Running
+ ✔ Container 02-obi-docker-obi-1 Started
+```
+
+{{% /tab %}}
+{{< /tabs >}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md
new file mode 100644
index 0000000000..a6b651b850
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md
@@ -0,0 +1,45 @@
+---
+title: 2. OBI 設定の理解
+weight: 2
+---
+
+## OBI 設定ファイル
+
+`obi-config.yaml`（リポジトリに既に含まれています）を開いて、OBI がどのようにサービスを検出し、計装するのかを理解しましょう。
+
+``` bash
+cat ~/workshop/obi/02-obi-docker/obi-config.yaml
+```
+
+``` yaml
+discovery:
+ instrument:
+ - name: "frontend"
+ open_ports: 3000
+ - name: "order-processor"
+ open_ports: 8080
+ - name: "payment-service"
+ open_ports: 8081
+
+ebpf:
+ context_propagation: all
+
+otel_traces_export:
+ endpoint: http://localhost:4318
+```
+
+### 各セクションの動作
+
+**`discovery.instrument`** は、OBI に対してサービスを見つける方法と、そのサービスに付ける名前を指示します。リッスンしているポートでプロセスをマッチングし、`name` を生成されるトレースの `service.name` 属性に割り当てます。これがない場合、OBI は実行ファイルのパス（例: `/usr/local/bin/order-processor`）をサービス名として使用します。
+
+**`context_propagation: all`** は分散トレーシングの鍵となります。OBI はカーネルレベルで送信 HTTP リクエストに `Traceparent` ヘッダーを注入します。これにより、`frontend` で開始されたトレースが、これらのサービスがトレーシングについて何も知らなくても、`order-processor` を経由して `payment-service` まで接続されます。
+
+**`otel_traces_export.endpoint`** は、OBI にトレースの送信先を指示します。OBI は `network_mode: host` を使用しているため、`localhost:4318` は compose ファイルでホストにマッピングされている collector のポートに到達します。
+
+{{% notice title="ヒント" style="primary" icon="lightbulb" %}}
+より詳細な設定オプションについては、OBI のドキュメントを参照してください。
+
+* [Service discovery](https://opentelemetry.io/docs/zero-code/obi/configure/service-discovery)
+* [Context propagation](https://opentelemetry.io/docs/zero-code/obi/configure/metrics-traces-attributes/#context-propagation)
+* [Config example](https://opentelemetry.io/docs/zero-code/obi/configure/example/)
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md
new file mode 100644
index 0000000000..ee102ac7d5
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md
@@ -0,0 +1,69 @@
+---
+title: 3. Splunk でトレースを確認する
+weight: 3
+---
+
+## クイック検証
+
+まず、すべてが正常に動作していることを確認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+docker-compose ps
+curl -s localhost:3000/create-order | jq
+docker-compose logs obi | head -30
+```
+
+{{% /tab %}}
+{{% tab title="Expected" %}}
+
+``` text
+# docker-compose ps - all 6 containers running
+# curl - returns JSON order confirmation
+# obi logs - shows "instrumenting process" for each service
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+OBI のログで、次のような行を探してください。
+
+``` text
+level=INFO msg="instrumenting process" cmd=/usr/local/bin/payment-service service=payment-service
+level=INFO msg="instrumenting process" cmd=/usr/local/bin/order-processor service=order-processor
+level=INFO msg="instrumenting process" cmd=node service=frontend
+```
+
+## Splunk APM を確認する
+
+トレースが流れ始めるまで 30〜60 秒待ってから、Splunk APM を確認します。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+1. **Service Map**: APM に移動し、環境でフィルタリングします。`frontend` -> `order-processor` -> `payment-service` の 3 つのサービスが表示されるはずです。
+2. **Traces**: 任意のトレースをクリックします。3 つのサービスすべてにわたる完全な分散トレースと、各ホップのタイミングが表示されます。
+3. **フェーズ 1 との比較**: 数分前まで完全に空だった APM ダッシュボードに、完全なサービストポロジーが表示されるようになりました。
+
+{{% /notice %}}
+
+**Compose ファイルに 1 つのコンテナを追加しただけです。アプリケーションコードは 1 行も変更していません。それでも、完全な分散トレーシングが利用できるようになりました。**
+
+## 解答例
+
+途中でつまずいた場合は、すべての変更が適用された最終版の `docker-compose.yaml` が次の場所に用意されています。
+
+``` bash
+cat ~/workshop/obi/02-obi-docker/docker-compose.final.yaml
+```
+
+ご自身の `docker-compose.yaml` と比較して、相違点を確認してください。
+
+## Docker のクリーンアップ
+
+Kubernetes フェーズに進む前に、Docker スタックを停止します。
+
+``` bash
+docker-compose down
+```
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/_index.md
new file mode 100644
index 0000000000..6639d06be2
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/4-docker-obi-magic/_index.md
@@ -0,0 +1,14 @@
+---
+title: "Phase 2: The OBI Magic"
+linkTitle: 4. Docker with OBI
+weight: 4
+archetype: chapter
+time: 20 minutes
+description: Docker Compose スタックに OBI eBPF エージェントを追加します。アプリケーションコードを一切変更せずに、Splunk APM で完全な分散トレースが表示されます。
+---
+
+このフェーズでは、Docker Compose スタックに 1 つのコンテナを追加します。アプリケーションコードを一切変更せずに、3 つのサービスすべてにわたる完全な分散トレースが Splunk APM に表示されます。
+
+{{% notice icon="user" style="orange" title="The Key Moment" %}}
+これはワークショップの中核となるデモです。**1 つのコンテナ**を追加し、アプリケーションコードを**一行も変更せず**に、**トレースゼロ**の状態から**完全な分散トレーシング**へと進もうとしています。
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md
new file mode 100644
index 0000000000..e0f77e4035
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md
@@ -0,0 +1,125 @@
+---
+title: 1. イメージのビルドとロード
+weight: 1
+---
+
+## クラスターの確認
+
+ワークショップインスタンスには K3d がプリインストールされています。動作していることを確認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl get nodes
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+NAME STATUS ROLES AGE VERSION
+k3d-shw-ece9-cluster-agent-0 Ready 4h6m v1.33.4+k3s1
+k3d-shw-ece9-cluster-agent-1 Ready 4h6m v1.33.4+k3s1
+k3d-shw-ece9-cluster-server-0 Ready control-plane,master 4h6m v1.33.4+k3s1
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## アプリケーションイメージのビルド
+
+K8s マニフェストはローカルでビルドしたイメージを参照します。`02-obi-docker/` のソースからビルドします。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+cd ~/workshop/obi/03-obi-k8s
+docker build -t obi-workshop-frontend:latest ../02-obi-docker/frontend
+docker build -t obi-workshop-order-processor:latest ../02-obi-docker/order-processor
+docker build -t obi-workshop-payment-service:latest ../02-obi-docker/payment-service
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+[+] Building 8.2s (10/10) FINISHED
+ => => naming to docker.io/library/obi-workshop-frontend:latest
+[+] Building 12.1s (11/11) FINISHED
+ => => naming to docker.io/library/obi-workshop-order-processor:latest
+[+] Building 11.8s (11/11) FINISHED
+ => => naming to docker.io/library/obi-workshop-payment-service:latest
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## イメージを K3d にインポート
+
+K3d は Docker ではなく containerd を使用するため、イメージをクラスターにインポートする必要があります。まず、クラスター名を確認します。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+k3d cluster list
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+NAME SERVERS AGENTS LOADBALANCER
+shw-ece9-cluster 1/1 2/2 true
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+次にイメージをインポートします。`CLUSTER_NAME` は `env` で利用可能になっているはずですが、設定されていない場合は次を実行してください。
+
+```
+export CLUSTER_NAME=$(k3d cluster list -o json | jq -r '.[].name')
+```
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+k3d image import -c $CLUSTER_NAME \
+ obi-workshop-frontend:latest \
+ obi-workshop-order-processor:latest \
+ obi-workshop-payment-service:latest
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+INFO[0000] Importing image(s) into cluster 'shw-ece9-cluster'
+INFO[0000] Starting new tools node...
+INFO[0000] Starting node 'k3d-shw-ece9-cluster-tools'
+INFO[0000] Saving 3 image(s) from runtime...
+INFO[0003] Importing images into nodes...
+INFO[0003] Importing images from tarball '/k3d/images/k3d-shw-ece9-cluster-images-20260227211818.tar' into node 'k3d-shw-ece9-cluster-server-0'...
+INFO[0003] Importing images from tarball '/k3d/images/k3d-shw-ece9-cluster-images-20260227211818.tar' into node 'k3d-shw-ece9-cluster-agent-1'...
+INFO[0003] Importing images from tarball '/k3d/images/k3d-shw-ece9-cluster-images-20260227211818.tar' into node 'k3d-shw-ece9-cluster-agent-0'...
+INFO[0015] Removing the tarball(s) from image volume...
+INFO[0016] Removing k3d-tools node...
+INFO[0020] Successfully imported image(s)
+INFO[0020] Successfully imported 3 image(s) into 1 cluster(s)
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+{{% notice title="Tip" style="primary" icon="lightbulb" %}}
+上記のスクリプトはクラスター名を自動検出します。複数の k3d クラスターがある場合は、明示的に指定できます。
+
+``` bash
+k3d image import -c shw-ece9-cluster obi-workshop-frontend:latest obi-workshop-order-processor:latest obi-workshop-payment-service:latest
+```
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md
new file mode 100644
index 0000000000..9a886e9baf
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md
@@ -0,0 +1,145 @@
+---
+title: 2. ベースラインのデプロイ
+weight: 2
+---
+
+## ワークショップアプリケーションのデプロイ
+
+アプリケーションは独自の名前空間にデプロイします。
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+cd ~/workshop/obi/03-obi-k8s
+kubectl apply -f namespace.yaml
+kubectl apply -f apps.yaml
+kubectl apply -f load-generator.yaml
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+namespace/obi-workshop created
+deployment.apps/frontend created
+service/frontend created
+deployment.apps/order-processor created
+service/order-processor created
+deployment.apps/payment-service created
+service/payment-service created
+deployment.apps/load-generator created
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## Splunk OTel Collector のインストール
+
+[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart) は、Collector を Kubernetes にデプロイする本番運用向けの方法です。Collector のデプロイメント、サービス、設定を自動的に処理します。
+
+### Helm リポジトリの追加
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart
+helm repo update
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+"splunk-otel-collector-chart" has been added to your repositories
+Hang tight while we grab the latest from your chart repositories...
+...Successfully got an update from the "splunk-otel-collector-chart" chart repository
+Update Complete. ⎈Happy Helming!⎈
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+### Collector のインストール
+
+ここでは OBI を有効化**せずに** Splunk OTel Collector をインストールします。次のステップで OBI を有効化し、有効化前後の違いを確認します。
+
+{{% notice title="Note" style="info" %}}
+環境変数 `ACCESS_TOKEN`、`REALM`、`INSTANCE` は、ワークショップインスタンスにあらかじめ設定されています。`env` を実行して存在を確認してください。
+{{% /notice %}}
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+helm -n obi-workshop install splunk-otel-collector \
+ splunk-otel-collector-chart/splunk-otel-collector \
+ --set="splunkObservability.realm=${REALM}" \
+ --set="splunkObservability.accessToken=${ACCESS_TOKEN}" \
+ --set="clusterName=${INSTANCE}-k8s" \
+ --set="environment=${INSTANCE}-ebpf"
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+NAME: splunk-otel-collector
+LAST DEPLOYED: Thu Feb 27 22:30:15 2026
+NAMESPACE: default
+STATUS: deployed
+REVISION: 1
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## すべてが稼働していることの確認
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl get pods -n obi-workshop
+```
+
+{{% /tab %}}
+{{% tab title="Example Output" %}}
+
+``` text
+NAME READY STATUS RESTARTS AGE
+frontend-7d8b9f4c5-x2k4n 1/1 Running 0 30s
+load-generator-5c6d7e8f9-m3j2k 1/1 Running 0 28s
+order-processor-8e9f0a1b2-p4q5r 1/1 Running 0 30s
+payment-service-9f0a1b2c3-s6t7u 1/1 Running 0 30s
+
+NAME READY STATUS RESTARTS AGE
+splunk-otel-collector-agent-abc12 1/1 Running 0 45s
+splunk-otel-collector-cluster-receiver-xyz34 1/1 Running 0 45s
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+## アプリケーションのテスト
+
+NodePort 経由でフロントエンドにアクセスします。
+
+``` bash
+kubectl port-forward -n obi-workshop svc/frontend 30000:3000 &; sleep 5
+```
+
+ポートフォワードが完了したら、curl でページにアクセスできます。
+
+``` bash
+curl -s http://localhost:30000/create-order | jq
+```
+
+## APM が空であることの確認
+
+{{% notice title="Exercise" style="green" icon="running" %}}
+
+Splunk APM を開き、environment `-ebpf` でフィルタリングしてください。Collector からのインフラメトリクスは表示されますが、**新規のアプリケーショントレースはまだ表示されない**はずです。サービスは稼働していますが、まだ計装されていない状態です。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md
new file mode 100644
index 0000000000..b2fe74b663
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md
@@ -0,0 +1,87 @@
+---
+title: 3. Helm を使って OBI を有効化する
+weight: 3
+---
+
+これで、アプリケーションコードを一切変更することなく、たった 1 回の Helm アップグレードでクラスター全体にトレーシングを追加できます。
+
+## OBI を有効にして Collector をアップグレードする
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+``` bash
+helm -n obi-workshop upgrade splunk-otel-collector \
+ splunk-otel-collector-chart/splunk-otel-collector \
+ --set="splunkObservability.realm=${REALM}" \
+ --set="splunkObservability.accessToken=${ACCESS_TOKEN}" \
+ --set="clusterName=${INSTANCE}-k8s" \
+ --set="environment=${INSTANCE}-ebpf" \
+ --set="obi.enabled=true"
+```
+
+{{% /notice %}}
+
+変更点はこの `--set="obi.enabled=true"` ただ 1 つだけです。残りはすべて Helm チャートが処理してくれます。
+
+- **OBI DaemonSet** をデプロイする（ノードごとに 1 つの Pod）
+- RBAC（ServiceAccount、ClusterRole、ClusterRoleBinding）を構成する
+- OBI を自動的に Collector に向ける
+- eBPF に必要な Linux capabilities を付与する
+
+### OBI に必要なものは？
+
+eBPF はカーネルレベルで動作するため、OBI Pod は昇格された権限で実行されます。
+
+``` yaml
+hostPID: true # See all processes on the node, including other pods
+hostNetwork: true # Observe and inject trace context into network traffic
+privileged: true # Attach eBPF probes to the kernel
+```
+
+クラスターのポリシー上、権限を縮小する必要がある場合は、[OBI Security Documentation](https://opentelemetry.io/docs/zero-code/obi/security/) を参照してください。
+
+## OBI が稼働していることを確認する
+
+{{< tabs >}}
+{{% tab title="Script" %}}
+
+``` bash
+kubectl get pods -n obi-workshop -l app.kubernetes.io/name=obi
+kubectl logs -n obi-workshop -l app.kubernetes.io/name=obi --tail=20
+```
+
+{{% /tab %}}
+{{% tab title="Example Output to look for" %}}
+
+``` text
+NAME READY STATUS RESTARTS AGE
+obi-abc12 1/1 Running 0 45s
+
+...
+level=INFO msg="instrumenting process" service=payment-service
+...
+level=INFO msg="instrumenting process" service=order-processor
+...
+level=INFO msg="instrumenting process" service=frontend
+```
+
+{{% /tab %}}
+{{< /tabs >}}
+
+トラフィックを生成します。
+
+``` bash
+curl -s http://localhost:30000/create-order | jq
+```
+
+## Splunk APM を確認する
+
+トレースが流れてくるまで 30〜60 秒待ちます。
+
+{{% notice title="演習" style="green" icon="running" %}}
+
+1. **Service Map**: `frontend` -> `order-processor` -> `payment-service` の 3 つのサービスが表示されているはずです。
+2. **Traces**: 任意のトレースをクリックします。3 つのサービスすべてにまたがる分散トレース全体と、各ホップの所要時間を確認できます。
+3. **Phase 2 と同じ流れ**: コード変更はゼロ。フラグを 1 つ付けた `helm upgrade` を 1 回実行するだけです。
+
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/4-how-this-scales.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/4-how-this-scales.md
new file mode 100644
index 0000000000..be2385e21a
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/4-how-this-scales.md
@@ -0,0 +1,76 @@
+---
+title: 4. スケーリングの仕組み
+weight: 4
+---
+
+## 環境を横断するパターン
+
+Phase 0 ではバイナリを実行しました。Phase 2 (Docker) ではコンテナを 1 つ追加しました。Phase 3 (K8s) では `helm upgrade` を 1 回実行しました。パターンは同じです。
+
+| 環境 | OBI のデプロイ | 変更内容 |
+|---|---|---|
+| ベアホスト | `sudo` 経由のバイナリ | 何も変えない: OBI がカーネルからプロセスを監視 |
+| Docker Compose | コンテナ 1 つ | `docker-compose.yaml` にサービスを追加 |
+| Kubernetes | Helm chart のフラグ | `helm upgrade` を `--set="obi.enabled=true"` で実行 |
+
+[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/zero-code-ebpf-instrumentation.md) は、collector と OBI の両方をデプロイする本番向けの方法です。さらなる自動化のために、[OpenTelemetry Operator](https://opentelemetry.io/docs/kubernetes/operator/) はアノテーションを使って OBI をサイドカーとして自動的にインジェクトできます。
+
+## 価値の整理
+
+多くの組織には、OpenTelemetry SDK で計装**できない**、または計装**したくない**アプリケーションがあります。
+
+- **レガシーシステム**: COBOL から Java への移行、10 年前の .NET Framework アプリ、ソースコードにアクセスできないベンダー提供のバイナリ
+- **コンパイル言語**: Go、Rust、C++ のサービスで、再コンパイルが選択肢にない、もしくはチームが既に他へ移っている
+- **開発者の抵抗**: 「時間がない」「スプリントに入っていない」「動いているコードは変えない」
+- **規制上の制約**: コードを変更すると監査・認証サイクル全体が再走する
+
+OBI は**コード変更なしで完全な分散トレーシング**を提供します。
+
+- **SDK 統合不要**: import なし、依存関係なし、コンパイル時の変更なし
+- **アプリケーションの再起動不要**: OBI は eBPF を介して既に動作中のプロセスにアタッチ
+- **言語非依存**: HTTP または gRPC を話すものなら Go、Node.js、Python、Java、Rust、C++ で動作
+- **コンテナ 1 つ、または Helm のフラグ 1 つ**: compose に追加するか Helm chart で `obi.enabled=true` を有効化すれば完了
+
+## 環境によっては obi/eBPF の設定にカスタマイズが必要な場合があります
+
+OpenShift などのケースでは、obi の設定に追加情報が必要になることがあります。
+この例を提供してくれた Leandro de Oliveira e Ferreira に感謝します！
+
+```
+# obi-scc.yaml
+apiVersion: security.openshift.io/v1
+kind: SecurityContextConstraints
+metadata:
+ name: splunk-otel-obi-scc
+allowPrivilegedContainer: true
+allowHostPID: true
+allowHostDirVolumePlugin: true
+allowHostNetwork: true
+allowHostPorts: true
+allowPrivilegeEscalation: true
+readOnlyRootFilesystem: false
+runAsUser:
+ type: RunAsAny
+seLinuxContext:
+ type: RunAsAny
+fsGroup:
+ type: RunAsAny
+supplementalGroups:
+ type: RunAsAny
+volumes:
+ - configMap
+ - emptyDir
+ - hostPath
+ - secret
+ - projected
+allowedCapabilities:
+ - BPF
+ - PERFMON
+ - SYS_PTRACE
+ - DAC_READ_SEARCH
+ - NET_ADMIN
+ - NET_RAW
+ - CHECKPOINT_RESTORE
+ - SYS_ADMIN
+users: []
+```
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/_index.md
new file mode 100644
index 0000000000..0a0392a937
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/5-kubernetes/_index.md
@@ -0,0 +1,12 @@
+---
+title: "Phase 3: Kubernetes"
+linkTitle: 5. Kubernetes
+weight: 5
+archetype: chapter
+time: 25 minutes
+description: 同じ3つのサービスをKubernetesにデプロイし、OBI DaemonSetを追加することで、完全な分散トレーシングを実現します。ゼロコードのまま、エンタープライズグレードのオーケストレーションを利用できます。
+---
+
+このフェーズでは、Phase 2で使用した「素の」アプリケーションコードをそのまま流用し、[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart)を使用してKubernetesにデプロイします。
+
+CollectorはHelmでデプロイされ、`obi.enabled=true`という単一のフラグでOBIを有効化することで、すべてのノード上のすべてのPodをインストルメントするOBI DaemonSetがデプロイされます。
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/6-wrap-up/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/6-wrap-up/_index.md
new file mode 100644
index 0000000000..9b98264b1c
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/6-wrap-up/_index.md
@@ -0,0 +1,75 @@
+---
+title: Wrap Up
+linkTitle: 6. Wrap Up
+weight: 6
+archetype: chapter
+time: 5 minutes
+description: 主な学びのポイント、クリーンアップ手順、ワークショップを発展させるためのアイデアを紹介します。
+---
+
+## 主な学びのポイント
+
+1. **OBI はカーネルから計装します。** SDK もコード変更も再コンパイルも不要です。eBPF プローブがネットワークレベルで HTTP/gRPC トラフィックを観測します。
+
+2. **コンテキスト伝播はネットワークレベルで行われます。** OBI は送信される HTTP リクエストに `Traceparent` ヘッダーを注入し、トレーシングをまったく認識していないサービス間でもトレースを連結します。
+
+3. **デプロイメントパターンは一貫しています。** ベアメタル、Docker、Kubernetes のいずれの場合でも、アプローチは同じです。アプリと並べて OBI を実行し、コレクターを指し示すだけです。
+
+4. **これは現実のエンタープライズの課題を解決します。** レガシーアプリ、コンパイル済みバイナリ、規制上の制約、開発者からの抵抗 OBI はコードを変更せずにオブザーバビリティを実現します。
+
+## クリーンアップ
+
+### Kubernetes
+
+``` bash
+kill %1 2>/dev/null; # kill port forward
+helm -n obi-workshop uninstall splunk-otel-collector
+kubectl delete namespace obi-workshop
+```
+
+### Docker
+
+``` bash
+cd ~/workshop/obi/02-obi-docker
+docker-compose down
+```
+
+### Phase 0 (Python)
+
+``` bash
+sudo pkill -f ./obi 2>/dev/null
+kill %1 2>/dev/null
+```
+
+## ワークショップを発展させる
+
+すべてのフェーズを完了したら、LLM（Cursor、Copilot、ChatGPT など）を使ってワークショップを発展させるアイデアをいくつか紹介します。
+
+### 新しいエンドポイントを追加する
+
+LLM に依頼して `order-processor` に `GET /order-status/:id` エンドポイントを追加してみてください。OBI は設定変更なしで自動的にトレースします（すでにポート 8080 を監視しています）。
+
+### 新しいサービスを追加する
+
+LLM に依頼してポート 8082 で動作する Python（Flask）の `inventory-service` を作成してみてください。以下の作業が必要です。
+
+- サービスのコードと Dockerfile を作成する
+- `docker-compose.yaml` に追加する
+- `obi-config.yaml` にポート 8082 を追加する
+
+### エラーシナリオを追加する
+
+LLM に依頼して `payment-service` が 20% の確率でランダムに 500 ステータスで失敗するようにしてみてください。そして `order-processor` にリトライロジックを追加します。Splunk APM にエラー率が表示されるのを確認してください。
+
+### レイテンシーシミュレーションを追加する
+
+LLM に依頼して `payment-service` に 100〜500ms のランダムなレイテンシーを追加してみてください。Splunk APM のサービスビューにレイテンシー分布が表示されるのを確認してください。
+
+{{% notice title="Note" style="info" %}}
+発展させる際の注意点
+
+- OpenTelemetry SDK は **追加しないでください**。ゼロコード計装こそがポイントです
+- サービスは Docker ネットワーク上に保ち、サービス間通信に `localhost` を使わないでください
+- 新しいポートを追加する際は `obi-config.yaml` を更新してください
+- コード変更後は再ビルドしてください: `docker-compose up --build -d`
+{{% /notice %}}
diff --git a/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/_index.md b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/_index.md
new file mode 100644
index 0000000000..01c6c24d3b
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/16-obi-ebpf/_index.md
@@ -0,0 +1,35 @@
+---
+draft: false
+hidden: false
+title: Zero-Code APM with OBI and eBPF
+linkTitle: Zero-Code APM with OBI
+weight: 16
+archetype: chapter
+time: 90 minutes
+authors: ["Jeremy Hicks"]
+description: Add full distributed tracing to apps with zero code changes using OpenTelemetry eBPF Instrumentation, streaming telemetry to Splunk Observability Cloud.
+aliases:
+ - /ninja-workshops/16-obi-ebpf/
+---
+
+このワークショップでは、**OpenTelemetry eBPF Instrumentation (OBI)** の威力を体験します。OBI は Linux カーネルから直接サービスを計装する、ゼロコードのアプリケーションパフォーマンスモニタリング手法です。
+
+3 つのフェーズを順番に進め、それぞれ前のフェーズの上に積み重ねていきます。
+
+- **Phase 0 -- Python Warm-up**: ホスト上で素の Python アプリを実行します。OBI バイナリを使用してカーネルから APM トレーシングを追加します。SDK もコード変更も不要です。
+- **Phase 1 -- Docker (Before OBI)**: 3 つの多言語マイクロサービス (Node.js + Go + Go) を Docker Compose でデプロイします。APM が空であることを確認します。
+- **Phase 2 -- Docker (The Magic)**: OBI コンテナを 1 つ追加します。3 つすべてのサービスで完全な分散トレースが Splunk APM に表示されます。コード変更はゼロです。
+- **Phase 3 -- Kubernetes**: 同じサービスを Splunk OTel Collector Helm chart を使用して K8s にデプロイします。1 つのフラグで OBI を有効化します。同じゼロコードトレーシングを、エンタープライズグレードのオーケストレーションで実現します。
+
+```text
+Phase 0: Python (:5150) ──── instrumented by OBI binary on host
+
+Phase 1: Frontend (Node.js :3000) → Order-Processor (Go :8080) → Payment-Service (Go :8081)
+ ↑ infrastructure metrics only, APM is empty
+
+Phase 2: Same three services + one OBI container
+ ↑ full distributed traces, zero code changes
+
+Phase 3: Same services on Kubernetes + Splunk OTel Collector Helm chart + obi.enabled=true
+ ↑ same tracing, scales to any cluster
+```
diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md
new file mode 100644
index 0000000000..69f71b54cf
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md
@@ -0,0 +1,196 @@
+---
+title: 1.1 テストの記録
+weight: 1
+---
+
+このステップでは、Chrome DevTools Recorder を使用して、デモ用 Online Boutique ストアフロントでの一連のユーザージャーニーをキャプチャします。Recorder はあなたの操作を監視し、各クリック、キー入力、ナビゲーションを構造化されたステップとして記録します。操作対象の各要素について、**複数のセレクター戦略**（CSS、XPath など）をキャプチャするため、結果として得られるテストはほとんどのフロントエンド変更に対して堅牢です。あるセレクターが機能しなくなった場合は、次のセレクターが順番に試行されます。記録は JSON ファイルに保存し、次のステップで Splunk Synthetic Monitoring にインポートします。
+
+## 開始 URL を開く
+
+ワークショップの開始 URL を Chrome で開きます。下記の該当するリンクをクリックして、新しいタブでサイトを開いてください。
+
+{{% notice note %}}
+ワークショップの開始 URL は **EMEA** と **AMER/APAC** で異なります。お住まいのリージョンに応じた正しい URL を使用してください。
+
+{{% tabs %}}
+{{% tab title="EMEA Workshop URL" %}}
+
+[https://online-boutique-eu.splunko11y.com/](https://online-boutique-eu.splunko11y.com/)
+
+{{% /tab %}}
+{{% tab title="AMER/APAC Workshop URL" %}}
+
+[https://online-boutique-us.splunko11y.com/](https://online-boutique-us.splunko11y.com/)
+
+{{% /tab %}}
+{{% /tabs %}}
+{{% /notice %}}
+
+## Chrome DevTools Recorder を開く
+
+次に、上記で開いた新しいタブで、Windows では `Ctrl + Shift + I`、Mac では `Cmd + Option + I` を押して Developer Tools を開き、トップレベルメニューまたは **More tools** フライアウトメニューから **Recorder** を選択します。
+
+
+
+{{% notice title="Note" style="info" %}}
+サイトの要素はビューポート幅によって変化することがあります。記録を開始する前に、作成したいテスト（Desktop、Tablet、または Mobile）に合わせてブラウザウィンドウの幅を設定してください。レスポンシブサイトでは、ブレークポイント以下になるとメニュー項目がハンバーガーアイコンの背後に隠れることがよくあります。広いウィンドウで「カートリンクをクリック」と記録しても、テストがモバイルビューポートで実行される場合は正しく再生されません。役立つ場合は、DevTools の「dock side」を変更して別ウィンドウとしてポップアウトさせてください。
+{{% /notice %}}
+
+## 新しい記録を作成する
+
+DevTools ウィンドウで Recorder パネルを開いた状態で、{{% button style="blue" %}}Create a new recording{{% /button %}} ボタンをクリックして開始します。
+
+
+
+**Recording Name** には、自分のイニシャルを記録名のプレフィックスとして使用します（例: **`` - Online Boutique**）。**Start Recording** をクリックして、操作の記録を開始します。
+
+
+
+記録が開始されたら、サイトで以下の操作を実行してください。
+
+- **Vintage Camera Lens** をクリック
+- **Add to Cart** をクリック
+- **Place Order** をクリック
+- Recorder パネルの **End recording** をクリック
+
+
+
+## 記録のエクスポート
+
+**Export** ボタンをクリックします。
+
+
+
+形式として **JSON** を選択し、**Save** をクリックします。
+
+
+
+
+
+**おめでとうございます！** Chrome DevTools Recorder を使用して記録を作成できました。次は、この記録を使用して Splunk Synthetic Monitoring で Real Browser Test を作成します。
+
+### JSON の中身は実際にどうなっているか
+
+記録の内容を確認したい場合は、下の展開可能なセクションを開いてください。注目すべき点をいくつか挙げます。
+
+- 各操作は `type`（`navigate`、`click` など）と `selectors` のリストを持つオブジェクトです。これは冒頭で説明した複数戦略のフォールバックです。Recorder は優先順位順にセレクターをリスト化し、テストランナーは一致するものが見つかるまで各セレクターを試行します。
+- 最初のステップは `setViewport` で、ウィンドウの寸法を固定します。これにより、どのロケーションから実行しても、テストは常に同じサイズで再生されます。
+- ほとんどのクリックステップには、`navigation` の URL とページ `title` を含む `assertedEvents` が含まれます。これは Recorder が期待される結果を固定する方法です。クリックが `/cart` へのナビゲーションを発生させる*べき*なのに発生しない場合、ステップは失敗します。実行結果には、曖昧なタイムアウトではなく、明確なアサーション失敗として表示されます。
+
+---
+
+{{% expand "Click here to view the JSON file" %}}
+
+```json
+{
+ "title": "RWC - Online Boutique",
+ "steps": [
+ {
+ "type": "setViewport",
+ "width": 1430,
+ "height": 1016,
+ "deviceScaleFactor": 1,
+ "isMobile": false,
+ "hasTouch": false,
+ "isLandscape": false
+ },
+ {
+ "type": "navigate",
+ "url": "https://online-boutique-eu.splunko11y.com/",
+ "assertedEvents": [
+ {
+ "type": "navigation",
+ "url": "https://online-boutique-eu.splunko11y.com/",
+ "title": "Online Boutique"
+ }
+ ]
+ },
+ {
+ "type": "click",
+ "target": "main",
+ "selectors": [
+ [
+ "div:nth-of-type(2) > div:nth-of-type(2) a > div"
+ ],
+ [
+ "xpath//html/body/main/div/div/div[2]/div[2]/div/a/div"
+ ],
+ [
+ "pierce/div:nth-of-type(2) > div:nth-of-type(2) a > div"
+ ]
+ ],
+ "offsetY": 170,
+ "offsetX": 180,
+ "assertedEvents": [
+ {
+ "type": "navigation",
+ "url": "https://online-boutique-eu.splunko11y.com/product/66VCHSJNUP",
+ "title": ""
+ }
+ ]
+ },
+ {
+ "type": "click",
+ "target": "main",
+ "selectors": [
+ [
+ "aria/ADD TO CART"
+ ],
+ [
+ "button"
+ ],
+ [
+ "xpath//html/body/main/div[1]/div/div[2]/div/form/div/button"
+ ],
+ [
+ "pierce/button"
+ ],
+ [
+ "text/Add to Cart"
+ ]
+ ],
+ "offsetY": 35.0078125,
+ "offsetX": 46.4140625,
+ "assertedEvents": [
+ {
+ "type": "navigation",
+ "url": "https://online-boutique-eu.splunko11y.com/cart",
+ "title": ""
+ }
+ ]
+ },
+ {
+ "type": "click",
+ "target": "main",
+ "selectors": [
+ [
+ "aria/PLACE ORDER"
+ ],
+ [
+ "div > div > div.py-3 button"
+ ],
+ [
+ "xpath//html/body/main/div/div/div[4]/div/form/div[4]/button"
+ ],
+ [
+ "pierce/div > div > div.py-3 button"
+ ],
+ [
+ "text/Place order"
+ ]
+ ],
+ "offsetY": 29.8125,
+ "offsetX": 66.8203125,
+ "assertedEvents": [
+ {
+ "type": "navigation",
+ "url": "https://online-boutique-eu.splunko11y.com/cart/checkout",
+ "title": ""
+ }
+ ]
+ }
+ ]
+}
+```
+
+{{% /expand %}}
diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md
new file mode 100644
index 0000000000..fe9f67d508
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md
@@ -0,0 +1,20 @@
+---
+title: 1.2 Real Browser Test の作成
+weight: 2
+---
+
+先ほど保存したレコーディングはローカルファイルにすぎません。アラートを発報することも、ロンドンから午前3時に実行することも、昨日のチェックアウトが遅かったかどうかを教えてくれることもできません。レコーディングから Splunk Synthetic Monitoring テストへ移行することで、これらすべてが可能になります。同じユーザージャーニーが、選択したクラウドロケーションから継続的に実行され、その結果はメトリクス、ログ、トレースと同じ Observability Cloud 組織に流れ込みます。
+
+Splunk Observability Cloud で **Synthetics** に移動します。ランディングページには Synthetic Monitoring の3種類のチェックが表示されています:
+
+- **Browser tests** — 本日構築する、完全な Chromium による実ユーザージャーニーチェックです。
+- **Uptime tests** — 軽量なポートおよび HTTP の可用性チェックです。
+- **API tests** — 複数ステップの HTTP トランザクションチェックです (Part 2 で構築します)。
+
+{{% button style="blue" %}}Add new test{{% /button %}} をクリックし、ドロップダウンから **Browser test** を選択します。
+
+
+
+続いて **Browser test content** 設定ページが表示されます。ここで、先ほどエクスポートした JSON をインポートし、テストの実行場所と頻度を設定し、各ステップに名前を付けます。これにより、オンコールエンジニアが実行結果を一目で読み取れるようになります。
+
+
diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/3-import-json.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/3-import-json.md
new file mode 100644
index 0000000000..38b32a4abd
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/3-import-json.md
@@ -0,0 +1,26 @@
+---
+title: 1.3 JSONのインポート
+weight: 3
+---
+
+テストの構成を開始するには、Chrome DevTools Recorder からエクスポートした JSON ファイルをインポートする必要があります。Splunk Synthetic Monitoring は Recorder のネイティブな JSON 形式を直接理解できるため、変換手順は不要です。インポーターが記録された各ステップを読み取り、対応する Synthetic テストステップを作成し、セレクター、ビューポート、アサートされたナビゲーションイベントを保持します。
+
+{{% button %}}**Import**{{% /button %}} ボタンを有効化するには、まずテストに名前を付ける必要があります。記録時と同じ命名規則を使用してください。イニシャルの後にジャーニー名を続けます。例えば **`` - Online Boutique** のようにします。イニシャルを接頭辞として付けることで、共有された組織内でトレーナーやチームメンバーがお互いの作業を見つけやすくなります。
+
+
+
+{{% button %}}**Import**{{% /button %}} ボタンが有効になったら、それをクリックし、Chrome DevTools Recorder からエクスポートした JSON ファイルをドロップするか、ブラウズして選択してください。
+
+
+
+JSON が解析されると、インポートされたステップ数を示す緑色の確認メッセージが表示されます。ここで予期したよりも少ない数が表示された場合、通常は記録されたアクションのいずれかが Synthetics インポーターが認識できる形式ではなかったことを意味します。その特定のインタラクションを再記録すると、通常は解決します。
+
+{{% button style="blue" %}}Continue to edit steps{{% /button %}} をクリックします。
+
+
+
+**Edit steps** ビューには、インポートされた各ステップが順番に表示され、アクションタイプ、ターゲットセレクター、待機条件などが確認できます。ここからステップを並べ替えたり、追加したり、削除したりできますが、それについては後のセクションで扱います。
+
+
+
+ステップ自体を編集する前に、まずテストの実行時設定を構成しましょう。どこから実行するか、どの程度の頻度で実行するか、どのデバイスで実行するかを設定します。{{% button style="blue" %}}< Return to test{{% /button %}} をクリックしてください。
diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md
new file mode 100644
index 0000000000..dbb9a8d5dc
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md
@@ -0,0 +1,63 @@
+---
+title: 1.4 設定
+weight: 4
+---
+
+このページのすべての設定は、カバレッジ、コスト、シグナル品質、監視対象システムへの負荷の間の現実的なトレードオフに直接対応しています。クリックして進む前に、各コントロールが実際に何を制御するのか、値を選ぶ際の経験則を確認しましょう。
+
+## Name
+
+テストの表示名で、UI、アラートメッセージ、リンクされたダッシュボード、ディテクタータイトルなど、あらゆる場所で使用されます。コンテキストを盛り込みましょう。サービス名、ジャーニー、（共有組織の場合は）自分のイニシャルを含めます。本ワークショップでは **`` - Online Boutique** が適切です。
+
+## Locations
+
+Splunk がテストを実行するクラウドリージョンです。主要な AWS リージョン全体に分散した 50 を超えるロケーションから選択できます。**ロケーションの選択は想像以上に重要です**。返されるメトリクスは、そのロケーションから見た *実測の* ユーザー体験であり、ネットワーク遅延、TLS ハンドシェイク時間、地理的な CDN ルーティングがすべて含まれているためです。N. Virginia から 800 ms でロードされるサイトでも、CDN がキャッシュしていなければ Mumbai からは 2.4 秒かかる可能性があります。
+
+ベストプラクティス: 実際のユーザーがいる場所に合致するロケーションを選択します。米国東部に顧客ベースがあり、EMEA に別の顧客ベースがある場合は、両方から監視します。さらに、どのユーザーからも *遠い* ロケーションを少なくとも 1 つ追加し（例: 米国専用製品なら Melbourne）、グローバルルーティングや DNS 問題の早期警戒カナリアとして使います。
+
+本ワークショップでは、3 大陸にまたがる 3 つのロケーションを使用します:
+
+- **AWS - N. Virginia**
+- **AWS - London**
+- **AWS - Melbourne**
+
+**Locations** フィールドをクリックし、ドロップダウンからそれぞれを選択します。
+
+
+
+## Device
+
+特定のデバイスプロファイルをエミュレートし、ビューポート寸法、ユーザーエージェント文字列、そしてそのデバイスを近似する *スロットルされた* CPU とネットワークプロファイルを設定します。ビューポートは、テストがどのロケーションから実行されるかに関わらず一貫しています。
+
+これが重要な理由: 4× CPU スローダウンの fast-3G スロットル iPhone X では、スロットルされていないデスクトップテストでは完全に見えなくなる実ユーザーの痛みが顕在化します。ユーザーの大半がモバイルなら、モバイルで監視しましょう。
+
+## Frequency
+
+各ロケーションからテストを実行する頻度です。間隔が短いほどリグレッションを早く検知できますが、消費するキャパシティが増え、対象サイトへの負荷も大きくなります。ディテクターに有用なシグナルを与える範囲で、最も低い頻度を選びます:
+
+| Frequency | 典型的な用途 |
+| --- | --- |
+| 1 min | トラフィックが多く収益性の高いサイトのクリティカルユーザージャーニー |
+| 5 min | 本番ジャーニーの大半におけるデフォルト（本ワークショップの設定） |
+| 10–15 min | プリプロダクション、ステージング、優先度の低いフロー |
+| 30–60 min | マーケティングページ、変更頻度が低い静的コンテンツ |
+
+アラートの計算を思い出しましょう。5 分間隔ということは、リグレッションを *最初に* 検知するまで **最大 5 分** かかる可能性があり、ほとんどのディテクターは発火に 2〜3 回連続の失敗を必要とします。したがって 5 分間隔のテストは、インシデント発生から 10〜15 分間アラートを出さないことがあります。
+
+## Round-robin
+
+複数のロケーションを選択している場合、**round-robin** はそのスケジューリング方法を変更します。Off（デフォルト）の場合、選択したすべてのロケーションが毎インターバルで実行されます。3 ロケーション × 5 分ごと = 1 時間あたり 36 回の実行です。On の場合、Splunk はロケーションをローテーションし、インターバルごとに 1 つを実行します。3 ロケーション × 5 分ごと = 1 時間あたり 12 回の実行ですが、個別のロケーションのサンプリングは 15 分ごとになります。
+
+トレードオフ: round-robin は実行消費を大幅に削減し、対象への負荷を軽減しますが、ロケーション単位のシグナルが希薄化します（ロケーション固有のリグレッションが顕在化するまで時間がかかります）。本ワークショップでは off のままにします。
+
+## Active
+
+テストのオン/オフを切り替えます。オンのままにします。実行履歴の蓄積を望まなくなった場合、後でテスト一覧から無効化できます。
+
+---
+
+名前を設定し、3 つのロケーションを選択したら、下にスクロールして {{% button style="blue" %}}Submit{{% /button %}} をクリックし、テストを保存します。
+
+これでテストは、N. Virginia、London、Melbourne から 5 分ごとに実行されるようスケジュールされました。最初の実行はディスパッチされるまで通常数分かかります（スケジューラーが各リージョンでブラウザスロットを割り当てる必要があるため）。すぐに結果が表示されなくても心配しないでください。
+
+待っている間、{{% button %}}Edit test{{% /button %}} をクリックして、**Advanced** 設定を確認しましょう。
diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md
new file mode 100644
index 0000000000..7a710d15b7
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md
@@ -0,0 +1,27 @@
+---
+title: 1.5 Advanced Settings
+weight: 5
+---
+
+デフォルト設定は、認証不要の公開ジャーニーであればほとんどの場合で十分ですが、実際の本番サイトでは **Advanced** にあるコントロールのうち少なくとも1つが必要になることがよくあります。本ワークショップではこれらの設定は行いませんが、後で適切なツールを選べるよう、それぞれが何のためにあるのかを知っておく価値はあります。
+
+**Advanced** をクリックしてパネルを展開します。
+
+{{% notice note %}}
+本ワークショップでは情報提供のみを目的としているため、これらの設定は **使用しません**。
+{{% /notice %}}
+
+
+
+## Security
+
+- **TLS/SSL validation** — 有効化すると、証明書の有効期限、ホスト名の不一致、信頼されない発行者チェーンの検証を強制します。自己署名証明書を使用するステージング環境に対してテストを行う場合、この設定を *オフ* にする必要があることもありますが、本番テストではオフのままにしてはいけません。証明書関連の障害に対する最も低コストな早期警告シグナルの1つを無効化してしまうためです。
+- **Authentication** — すべてのリクエストとともに送信される認証情報で、HTTP Basic認証の背後にあるサイト（内部ツールやpre-prod環境では今でも一般的です）に有用です。認証情報はインラインで入力するのではなく [concealed global variables](https://docs.splunk.com/Observability/synthetics/test-config/global-variables.html) として保存してください。concealed値はテスト設定を読む誰にも見えず、それを使うすべてのテストを編集することなく一箇所でローテーションできます。
+
+## Custom Content
+
+- **Custom headers** — テストが行うすべてのリクエストに送信される追加のヘッダーです。一般的な用途としては、バックエンドが分析ダッシュボードやRUMの集計から合成トラフィックを除外するために使用できる `X-Synthetics: true`（または類似の）ヘッダー、コールドキャッシュのパフォーマンスをテストするための `Cache-Control: no-cache` ヘッダー、特定のバリアントにテストを固定するためのA/Bテスト用Cookieやフィーチャーフラグのオーバーライドヘッダーなどがあります。
+- **Cookies** — テスト開始 *前* にブラウザで設定されます。典型的な用途は、テストがクリックする必要のある要素を覆い隠してしまう一回限りのモーダル（Cookieバナー、「ニュースレターを購読する」ポップアップ）の抑制です。Cookieは開始URLのドメインにスコープされており、Splunk Synthetic Monitoringは登録可能なドメインを判定するために [public suffix list](https://publicsuffix.org/) を使用します。
+- **Host overrides** — DNS解決時にあるホストから別のホストへリクエストをリルートします。一般的なパターンは2つあります。1つは、これからプロモートしようとしているCDNエッジノードに対して本番URLをテストすること（`www.example.com` を特定のエッジIPにオーバーライド）。もう1つは、ジャーニーのすべてのステップを書き換えることなく、ステージング形状のバックエンドに対して本番形状のテストを実行すること（`api.example.com` を `api-staging.example.com` にオーバーライド）です。
+
+次に、テストステップを編集して、それぞれに意味のある名前を付けます。これは、ステップが失敗し始め、チームメイトがアラートを読まなければならなくなった瞬間に重要になります。
diff --git a/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md
new file mode 100644
index 0000000000..044ddb97f6
--- /dev/null
+++ b/content/ja/ninja-workshops/instrumentation/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md
@@ -0,0 +1,51 @@
+---
+title: 1.6 テストステップの編集
+weight: 6
+---
+
+デフォルトでは、Chrome Recorder から出力されるステップは **"Go to URL"** や **"Click on `