diff --git a/content/ja/_index.html.old b/content/ja/_index.html.old deleted file mode 100644 index 272fb9e689..0000000000 --- a/content/ja/_index.html.old +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Splunk -linkTitle: Splunk Observability ワークショップ -description: Splunkのオブザーバビリティソリューションの構築方法を学びましょう -isCJKLanguage: true ---- - -{{< blocks/cover title="Splunk Observability ワークショップへようこそ！" image_anchor="top" height="auto" color="orange" >}} -
- - 始める - - - -

- Splunk Observability Cloud の監視、分析、応答ツールを使用して、アプリケーションとインフラストラクチャをリアルタイムで把握することができます。 - -

-
-{{< /blocks/cover >}} - - -{{< blocks/lead color="primary" >}} -このワークショップでは、メトリクス、トレース、スパンを取り込み、監視し、可視化し、分析するためのクラス最高のオブザーバビリティプラットフォームをご紹介します。 -{{< /blocks/lead >}} - -{{< blocks/section color="dark" type="features" >}} - -{{% blocks/feature icon="fab fa-wpexplorer" title="OpenTelemetry" url="https://opentelemetry.io/" %}} -このワークショップでは、OpenTelemetryを使用して、アプリケーションやインフラの分析に役立つテレメトリデータ（メトリクス、トレース、ログ）の計測、生成、収集、エクスポートを行います。 -{{% /blocks/feature %}} - -{{% blocks/feature icon="fab fa-github" title="Contributions welcome!" url="https://github.com/splunk/observability-workshop" %}} -このドキュメントには、issue や pull request で貢献することができます。より良いワークショップにするために、遠慮なくご協力ください。 -{{% /blocks/feature %}} - - -{{% blocks/feature icon="fab fa-twitter" title="Follow us on Twitter!" url="https://twitter.com/splunk" %}} -SplunkのTwitterチャンネルでは、アップデート情報や様々な読み物が紹介されています。 -{{% /blocks/feature %}} - - -{{< /blocks/section >}} diff --git a/content/ja/background.jpeg b/content/ja/background.jpeg deleted file mode 100644 index 841caa5164..0000000000 Binary files a/content/ja/background.jpeg and /dev/null differ diff --git a/content/ja/images/observability-hero-dashboard.gif b/content/ja/images/observability-hero-dashboard.gif index 48c4fef91b..1c27fbaaae 100644 Binary files a/content/ja/images/observability-hero-dashboard.gif and b/content/ja/images/observability-hero-dashboard.gif differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md deleted file mode 100644 index 8dbabd0dc1..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/1-otel-collector.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: OpenTelemetry Collector のインストール -linkTitle: 1. OpenTelemetry Collector -weight: 1 ---- - -Splunk OpenTelemetry Collectorは、インフラストラクチャとアプリケーションの計装における中核コンポーネントです。その役割は以下のデータを収集して送信することです - -* インフラストラクチャメトリクス（ディスク、CPU、メモリなど） -* 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ディストリビューションの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 --without-fluentd --with-instrumentation --deployment-environment $INSTANCE-petclinic --enable-profiler --enable-profiler-memory --enable-metrics --hec-token $HEC_TOKEN --hec-url $HEC_URL -``` - -次に、Collectorにパッチを適用して、AWSインスタンスIDではなくインスタンスのホスト名を公開するようにします。これにより、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.name` を選択し、ワークショップインスタンスのホスト名を入力または選択してください（これはターミナルセッションのコマンドプロンプトから取得できます）。ホストのデータが流れていることを確認したら、APMコンポーネントの作業を開始する準備が整いました。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md deleted file mode 100644 index a2120b11b5..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/2-building-petclinic.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Spring PetClinic アプリケーションのビルド -linkTitle: 2. PetClinic のビルド -weight: 2 ---- - -APMをセットアップするために最初に必要なのは...そう、アプリケーションです。この演習では、Spring PetClinicアプリケーションを使用します。これは、Springフレームワーク（Springboot）で構築された非常に人気のあるサンプルJavaアプリケーションです。 - -まず、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 -``` - -次に、PetClinicアプリケーションにシンプルなトラフィックを生成するLocustを実行する別のコンテナを起動します。Locustは、Webアプリケーションにトラフィックを生成するために使用できるシンプルな負荷テストツールです。 - -```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` を使用してPetClinicをコンパイル、ビルド、パッケージ化します - -```bash -./mvnw package -Dmaven.test.skip=true -``` - -> [!INFO] -> 初回実行時は数分かかり、アプリケーションをコンパイルする前に多くの依存関係をダウンロードします。以降のビルドはより高速になります。 - -ビルドが完了したら、実行しているインスタンスのパブリックIPアドレスを取得する必要があります。以下のコマンドを実行して取得できます - -```bash -curl http://ifconfig.me -``` - -IPアドレスが返されます。アプリケーションが実行されていることを確認するために必要になるので、このIPアドレスをメモしておいてください。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md deleted file mode 100644 index 29ca91a218..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/3-auto-discovery.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Java 向け自動ディスカバリーおよび設定 -linkTitle: 3. 自動ディスカバリー -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="出力例" %}} - -``` 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パフォーマンス、メトリクスを確認できます。左側のメニューから **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/1-automatic-discovery/1-petclinic-monolith/4-rum.md b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/4-rum.md deleted file mode 100644 index e5307a6ef1..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/4-rum.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: 3. Real User Monitoring -weight: 3 ---- - -Real User Monitoring (RUM) の計装では、ページにOpenTelemetry 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計装ライブラリを挿入するには、すべてのページで自動的に読み込まれるため、この場所が最適です。 - -それでは、レイアウトページを編集しましょう - -```bash -vi src/main/resources/templates/fragments/layout.html -``` - -次に、上記で生成したスニペットをページの `` セクションに挿入します。コメントは含めず、ソース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スニペットで定義された環境にフィルタリングし、ダッシュボードをクリックして開きます。 - -RUMトレースをドリルダウンすると、スパン内にAPMへのリンクが表示されます。トレースIDをクリックすると、現在のRUMトレースに対応するAPMトレースに移動します。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md deleted file mode 100644 index 024ff86ef4..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/5-log-observer.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -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アプリケーションログにいくつかのログメッセージが生成されます。 - -![PetClinic Error](../images/petclinic-error.png) - -左側のメニューから **Log Observer** をクリックし、**Index** が **splunk4rookies-workshop** に設定されていることを確認してください。 - -次に、**Add Filter** をクリックし、フィールド `service.name` を検索して、値 `-petclinic-service` を選択し、`=`（include）をクリックします。これで、PetClinicアプリケーションからのログメッセージのみが表示されるはずです。 - -PetClinicアプリケーションの **Error** リンクをクリックして生成されたログエントリの1つを選択してください。ログメッセージと、ログメッセージに自動的にインジェクションされたトレースメタデータが表示されます。また、APMとInfrastructureのRelated Contentが利用可能であることにも注目してください。 - -![Log Observer](../images/log-observer.png) - -これでワークショップは終了です。多くの内容をカバーしました。この時点で、メトリクス、トレース（APMとRUM）、ログ、データベースクエリパフォーマンス、コードプロファイリングがSplunk Observability Cloudに報告されているはずです。しかも、PetClinicアプリケーションのコードを変更することなく実現できました（RUMを除く）。 - -**おめでとうございます！** diff --git a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/_index.md deleted file mode 100644 index 82fe56d7d5..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/_index.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -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からAPMへの相関 -* Splunk Log Observer (LO) - -また、サンプルJavaアプリケーション（Spring PetClinic）のクローン（ダウンロード）方法、およびアプリケーションのコンパイル、パッケージ化、実行方法についても説明します。 - -アプリケーションが起動して実行されると、**Splunk APM** 製品で使用されるJava 2.x向けの**自動ディスカバリーおよび設定**機能により、メトリクス、トレース、ログが即座に表示されるようになります。 - -その後、**Splunk OpenTelemetry Javascript Libraries (RUM)** を使用してPetClinicのエンドユーザーインターフェース（アプリケーションがレンダリングするHTMLページ）を計装します。これにより、エンドユーザーが実行するすべてのクリックやページ読み込みに対してRUMトレースが生成されます。 - -最後に、PetClinicアプリケーションログへのトレースメタデータの自動インジェクションによって生成されたログを確認します。 - -{{% notice title="前提条件" style="primary" icon="info" %}} - -* ポート `2222` へのアウトバウンドSSHアクセス -* ポート `8083` へのアウトバウンドHTTPアクセス -* `bash` シェルおよび `vi/vim` エディタの基本的な知識 - -{{% /notice %}} - -![PetClinic Exercise](images/petclinic-exercise.png) diff --git a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/log-observer.png b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/log-observer.png deleted file mode 100644 index ef2b31f93c..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/log-observer.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/petclinic-error.png b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/petclinic-error.png deleted file mode 100644 index 452b276189..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/petclinic-error.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/petclinic-exercise.png b/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/petclinic-exercise.png deleted file mode 100644 index caebe8c6c0..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/1-petclinic-monolith/images/petclinic-exercise.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md deleted file mode 100644 index 330bc8cd3b..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/1-architecture/_index.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: アーキテクチャ -linkTitle: 1. アーキテクチャ -weight: 2 -time: 5 minutes ---- - -Spring PetClinic Javaアプリケーションは、フロントエンドとバックエンドのサービスで構成されるシンプルなマイクロサービスアプリケーションです。フロントエンドサービスは、バックエンドサービスと対話するためのWebインターフェースを提供するSpring Bootアプリケーションです。バックエンドサービスは、MySQLデータベースと対話するためのRESTful APIを提供するSpring Bootアプリケーションです。 - -このワークショップを終えるころには、Kubernetesで実行されるJavaベースのアプリケーション向けの**自動ディスカバリーおよび設定**を有効にする方法をより深く理解できるようになります。 - -以下の図は、Splunk OpenTelemetry Operatorと自動ディスカバリーおよび設定を有効にした状態でKubernetes上で実行されるSpring PetClinic Javaアプリケーションのアーキテクチャを詳しく示しています。 - -![Splunk Otel Architecture](../images/auto-instrumentation-java-diagram.png) - ---- - -**Josh Voravong** が作成した[**サンプル**](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/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md deleted file mode 100644 index d40270a71e..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/1-otel.md +++ /dev/null @@ -1,138 +0,0 @@ ---- - -title: Splunk OpenTelemetry Collector のデプロイ -linkTitle: 1. OpenTelemetry Collector のデプロイ -weight: 1 ---- - -オブザーバビリティシグナル（**メトリクス、トレース**、**ログ**）を **Splunk Observability Cloud** に送信するには、KubernetesクラスターにSplunk OpenTelemetry Collectorをデプロイする必要があります。 - -このワークショップでは、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コマンドを使用します。自動ディスカバリーおよび設定とコードプロファイリング用のオペレーターを有効にするための追加パラメータが設定されています。 - -* `--set="operator.enabled=true"` - 自動ディスカバリーおよび設定を処理するためのOpenTelemetryオペレーターをインストールします。 -* `--set="splunkObservability.profilingEnabled=true"` - オペレーター経由でコードプロファイリングを有効にします。 - -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` で終了）。または、インストール済みの**素晴らしい** `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/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md deleted file mode 100644 index c72a16d837..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/2-petclinic.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: PetClinic アプリケーションのデプロイ -linkTitle: 2. PetClinic アプリケーションのデプロイ -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アプリケーションが実行されているのが確認できるはずです。アプリケーションはポート **80** と **443** でも実行されているので、これらを使用するか、ポート **81** に到達できない場合はそちらを使用してください。 - -![Pet shop](../../images/petclinic.png) - -**All Owners** **(1)** タブと **Veterinarians** **(2)** タブにアクセスして、各ページに名前のリストが表示されることを確認し、アプリケーションが正しく動作していることを確認してください。 - -![Owners](../../images/petclinic-owners.png) - - diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md deleted file mode 100644 index 95180f9c80..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/2-preparation/_index.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -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/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md deleted file mode 100644 index c35ffde11d..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/3-verify-setup/_index.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Kubernetes クラスターメトリクスの確認 -linkTitle: 3. クラスターメトリクスの確認 -weight: 4 -time: 10 minutes ---- - -インストールが完了したら、**Splunk Observability Cloud** にログインして、Kubernetesクラスターからメトリクスが流れてきていることを確認できます。 - -左側のメニューから **Infrastructure** をクリックし、**Kubernetes** を選択してから、**Kubernetes nodes** タイルを選択します。 - -![NavigatorList](../images/navigatorlist.png) - -**Kubernetes nodes** の概要画面に入ったら、**Time** フィルタを **-1h** から過去15分 **(-15m)** に変更して最新のデータに焦点を当て、次に **Table** を選択してメトリクスを報告しているすべてのノードをリスト表示します。 - -次に、**Refine by:** パネルで **Cluster name** を選択し、リストからご自身のクラスターを選択します。 - -{{% notice title="Tip" style="info" icon="lightbulb" %}} -特定のクラスターを識別するには、セットアップ中に実行したシェルスクリプト出力の `INSTANCE` 値を使用してください。この一意の識別子により、リスト内の他のノードの中からワークショップクラスターを見つけることができます。 -{{% /notice %}} - -これにより、ご自身のクラスターのノードのみを表示するようにリストがフィルタリングされます。 - -![K8s Nodes](../images/k8s-nodes.png) - -**K8s node logs** ビューに切り替えて、ノードからのログを確認します。 - -![Logs](../images/k8s-peek-at-logs.png) diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md deleted file mode 100644 index d70929790b..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/1-patching-deployment.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: デプロイメントのパッチ適用 -linkTitle: 1. デプロイメントのパッチ適用 -weight: 1 ---- - -**自動検出と設定**を構成するには、デプロイメントに計装アノテーションを追加するためのパッチを適用する必要があります。パッチが適用されると、OpenTelemetry Collectorが自動検出と設定ライブラリを注入し、Podが再起動されてトレースとプロファイリングデータの送信が開始されます。まず、以下を実行して `api-gateway` に `splunk-otel-java` イメージがないことを確認します - -{{< tabs >}} -{{% 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 >}} - -次に、デプロイメントにアノテーションを追加して、すべてのサービスのJava自動検出と設定を有効にします。以下のコマンドは、すべてのデプロイメントにパッチを適用します。これにより、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` がプルされます（注：2つの `api-gateway` コンテナが表示される場合、元のコンテナがまだ終了処理中の可能性があるため、数秒待ってください）。 - -**Splunk Observability Cloud**のKubernetes Navigatorに戻ります。数分後、Podがオペレーターによって再起動され、自動検出と設定コンテナが追加されることが確認できます。以下のスクリーンショットのような表示になります - -![restart](../../images/k8s-navigator-restarted-pods.png) - -Kubernetes NavigatorでPodが緑色になるまで待ってから、次のセクションに進んでください。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md deleted file mode 100644 index 07756331eb..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/2-apm-data.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Splunk APMでのデータの表示 -linkTitle: 2. APMデータの表示 -weight: 2 ---- - -左側のメニューで**APM**をクリックして、新しく計装されたサービスからのトレースによって生成されたデータを確認します。 - -ドロップダウンボックスで**Environment**フィルター **(1)** をワークショップインスタンスの名前に変更します。 - -> [!NOTE] -> これは**`-workshop`**になります。ここで**`INSTANCE`**は、先ほど実行したシェルスクリプトの値です。これのみが選択されていることを確認してください。 - -![apm](../../images/zero-config-first-services-overview.png) - -**Service Map** **(2)** ペインをクリックして、次のセクションの準備をします。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md deleted file mode 100644 index c697aafe9d..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/4-apm/_index.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: APMの自動検出と設定のセットアップ -linkTitle: 4. 自動検出と設定 -weight: 5 -time: 10分 ---- - -このセクションでは、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/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md deleted file mode 100644 index dd6b8510c1..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/1-service-map.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: APM Service Map -linkTitle: 1. APM Service Map -weight: 1 ---- - -![apm map](../../images/zero-config-first-services-map.png) - -上記のマップは、すべてのサービス間のすべての相互作用を示しています。PetClinic Microserviceアプリケーションが起動して完全に同期するまで数分かかるため、マップはまだ中間状態にある可能性があります。時間フィルタを**-2m**と入力してカスタム時間の**2分**に減らすと役立ちます。画面右上の**Refresh**ボタン**(1)**をクリックできます。赤い円で示される初期起動関連のエラーは最終的に消えます。 - -次に、各サービスで利用可能なメトリクスを調べるために、リクエスト、エラー、期間（RED）メトリクスダッシュボードを見てみましょう。 - -この演習では、サービスオペレーションが高いレイテンシやエラーを示している場合に使用する一般的なシナリオを使用します。 - -依存関係マップで**customers-service**をクリックし、**Services**ドロップダウンボックス**(1)**で `customers-service` が選択されていることを確認します。次に、サービス名に隣接するOperationsドロップダウン**(2)**から `GET /owners` を選択します。 - -これにより、以下に示すように `GET /owners` でフィルタリングされたワークフローが表示されます - -![select a trace](../../images/select-workflow.png) diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md deleted file mode 100644 index ca7ab6790d..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/2-trace.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: APM Trace -linkTitle: 2. APM Trace -weight: 2 ---- - -トレースを選択するには、`Service Requests & Errors` チャート**(1)**の線を選択します。関連するトレースの選択肢が表示されます。 - -関連するトレースのリストが表示されたら、青い**(2)** Trace ID Linkをクリックします。選択するトレースがServicesカラムに記載されている3つのサービスと同じものであることを確認してください。 - -![workflow-trace-pick](../../images/selecting-a-trace.png) - -これにより、ウォーターフォールビューで選択されたトレースが表示されます - -ここにはいくつかのセクションがあります - -* Waterfall Pane **(1)**：トレースとスパンとして表示されるすべてのインストルメントされた関数が、その期間表示と順序/関係とともに表示されます。 -* Trace Info Pane **(2)**：選択されたスパン情報が表示されます（Waterfall Pane内でスパンの周りにボックスでハイライトされています）。 -* Span Pane **(3)**：選択されたスパンで送信されたすべてのタグを見つけることができます。下にスクロールしてすべてを確認できます。 -* Process Pane：スパンを作成したプロセスに関連するタグが表示されます（スクリーンショットに含まれていないため、下にスクロールして確認してください）。 -* Trace Properties：ペインの右上にあり、デフォルトでは折りたたまれています。 - -![waterfall](../../images/waterfall-view.png) diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md deleted file mode 100644 index fc2b5c7e8f..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/3-spans.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: APM Span -linkTitle: 3. APM Spans -weight: 3 ---- - -スパンを調べる際、トレーシングの上で**自動検出と設定**を使用すると、**コード変更なし**で得られるいくつかの標準機能を見てみましょう - -まず、Waterfall Paneで、以下のスクリーンショットに示すように `customers-service:SELECT petclinic` または類似のスパンが選択されていることを確認してください - -![DB-query](../../images/db-query.png) - -* 基本的なレイテンシ情報は、インストルメントされた関数または呼び出しのバーとして表示されます。上記の例では、17.8ミリ秒かかりました。 -* いくつかの類似したスパン**(1)**は、スパンが複数回繰り返される場合にのみ表示されます。この場合、例では10回の繰り返しがあります。`10x` をクリックすると、すべてのスパンが順番に表示されるように表示/非表示を切り替えることができます。 -* **Inferred Services**：インストルメントされていない外部システムへの呼び出しは、グレーの「推測された」スパンとして表示されます。この例のInferred Serviceまたはスパンは、上記に示すようにMysqlデータベース `mysql:petclinic SELECT petclinic` **(2)**への呼び出しです。 -* **Span Tags**：Tag Paneには、自動検出と設定によって生成された標準タグが表示されます。この場合、スパンはデータベースを呼び出しているため、`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/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md deleted file mode 100644 index ed79ec55e6..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/4-red-metrics.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Service Centric View -linkTitle: 4. Service Centric View -weight: 4 ---- - -Splunk APMは、エンジニアに1つの集中ビューでサービスパフォーマンスの深い理解を提供する**Service Centric Views**を提供します。すべてのサービスにわたって、エンジニアはサービスの基盤となるインフラストラクチャからのエラーやボトルネックを迅速に特定し、新しいデプロイによるパフォーマンス低下を特定し、すべてのサードパーティ依存関係の健全性を可視化できます。 - -`api-gateway` のこのダッシュボードを表示するには、左側のメニューから**APM**をクリックし、リストの `api-gateway` サービスをクリックします。これにより、Service Centric Viewダッシュボードが表示されます - -![service_maps](../../images/service-view.png) - -インストルメントされた各サービスで利用可能なこのビューは、**Service metrics**、**Error breakdown**、**Runtime metrics (Java)**、**Infrastructure metrics**の概要を提供します。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md deleted file mode 100644 index 72a6c2a5fc..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/5-traces/_index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: APM Features -linkTitle: 5. APM Features -weight: 6 -archetype: chapter -time: 15 minutes ---- - -前のセクションで見てきたように、サービスで**自動検出と設定**を有効にすると、トレースが**Splunk Observability Cloud**に送信されます。 - -これらのトレースにより、Splunkは自動的に**Service Maps**と**RED Metrics**を生成します。これらは、サービスの動作とサービス間の相互作用を理解するための最初のステップです。 - -次のセクションでは、トレース自体と、コードに触れることなくサービスの動作を理解するのに役立つ情報を詳しく見ていきます。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md deleted file mode 100644 index 68aecfe0eb..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/1-profiling.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Always-On Profiling & Metrics -linkTitle: 1. Always-On Profiling -weight: 1 ---- - -先ほどHelmチャートを使用してSplunk Distribution of the OpenTelemetry Collectorをインストールした際、**AlwaysOn Profiling**と**Metrics**を有効にするように設定しました。これにより、OpenTelemetry JavaはアプリケーションのCPUとメモリのプロファイリングを自動的に生成し、Splunk Observability Cloudに送信します。 - -PetClinicアプリケーションをデプロイしてアノテーションを設定すると、collectorは自動的にアプリケーションを検出し、トレースとプロファイリングのためにインストルメントします。これを確認するために、次のスクリプトを実行して、インストルメントしているJavaコンテナの1つの起動ログを調べることができます - -ログには、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に送信する前にコールスタックを書き込む場所です。（これは、コンテナの設定方法によって異なる場合があります。） - -変更したいもう1つのパラメータは `splunk.profiler.call.stack.interval` です。これは、システムがCPU Stack traceをキャプチャする頻度です。Pet Clinicアプリケーションのような短いスパンがある場合は、このインターバル設定を短くすることをお勧めします。デモアプリケーションでは、デフォルトのインターバル値を変更しなかったため、スパンに常にCPU Call Stackが関連付けられているとは限りません。 - -これらのパラメータを設定する方法は[こちら](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 configセクションでこの値を設定することで行います。 - -``` yaml -env: -- name: JAVA_OPTIONS - value: "-Xdebug -Dsplunk.profiler.call.stack.interval=150" -``` - - diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md deleted file mode 100644 index b3797a6584..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/2-waterfall.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Trace Waterfall内のAlways-On Profiling -linkTitle: 2. Trace Waterfall -weight: 2 ---- - -APM WaterfallビューでオリジナルのTrace & Span **(1)**（または類似のもの）を選択し、右側のペインから**Memory Stack Traces (2)**を選択してください - -![profiling from span](../../images/flamechart-in-waterfall.png) - -ペインにMemory Stack Trace Flame Graph **(3)**が表示されます。スクロールするか、ペインの右側をドラッグして拡大できます。 - -AlwaysOn Profilingは、アプリケーションのコードのスナップショット、つまりスタックトレースを常に取得しています。何千ものスタックトレースを読まなければならないことを想像してみてください！それは現実的ではありません。これを支援するために、AlwaysOn Profilingはプロファイリングデータを集約して要約し、**Flame Graph**と呼ばれるビューでCall Stacksを探索する便利な方法を提供します。これは、アプリケーションからキャプチャされたすべてのスタックトレースの要約を表します。Flame Graphを使用して、パフォーマンスの問題を引き起こしている可能性のあるコードの行を発見し、コードに加えた変更が意図した効果を持っているかどうかを確認できます。 - -Always-on Profilingをさらに詳しく調べるには、**Memory Stack Traces**の下のProfiling Paneで上の画像で参照されているSpan **(3)**を選択してください。これにより、Always-on Profilingのメイン画面が開き、Memoryビューがあらかじめ選択されています - -![Profiling main](../../images/profiling-memory.png) - -- Timeフィルタは、選択したスパンの時間枠に設定されます **(1)** -- Java Memory Metric Charts **(2)**では、`Heap Memoryのモニター`、`Memory Allocation Rate` や `Garbage Collecting` Metricsなどの `Application Activity` を確認できます。 -- スパン **(3)**に関連するメトリクスとStack Tracesのみにフォーカス/表示する機能。これにより、必要に応じてJavaアプリケーションで実行されているバックグラウンドアクティビティをフィルタで除外できます。 -- 識別されたJava Function calls **(4)**により、その関数から呼び出されたメソッドにドリルダウンできます。 -- プロファイルされたサービスのスタックトレースに基づく階層の視覚化を持つFlame Graph **(5)**。 -- サービスが複数のバージョンを起動する場合に備えて、Service instance **(6)**を選択する機能。 - -さらなる調査のために、UIではスタックトレースをクリックして、呼び出された関数と、フレームチャートから関連する行を確認できます。これを使用して、コーディングプラットフォームで実際のコードの行を表示できます（もちろん、お好みのコーディングプラットフォームによって異なります）。 - - diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md deleted file mode 100644 index ecb5ba3656..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/3-dbquery.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Database Query Performance -linkTitle: 3. Database Query Performance -weight: 3 ---- - -Database Query Performanceを使用すると、Splunk APMで直接、データベースクエリがサービスの可用性に与える影響をモニターできます。これにより、データベースをインストルメントすることなく、長時間実行されるクエリ、最適化されていないクエリ、または重いクエリを迅速に特定し、それらが引き起こしている可能性のある問題を軽減できます。 - -データベースクエリのパフォーマンスを確認するには、ブラウザで戻るか、メニューバーのAPMセクションに移動してAPMの**Service Map**ページに移動し、**Service Map**タイルをクリックします。 - -Dependency mapで推論されたデータベースサービス `mysql:petclinic` Inferred Database serverを選択し **(1)**、次に右側のペインをスクロールして**Database Query Performance** Pane **(2)**を見つけます。 - -![DB-query from map](../../images/db-query-map.png) - -マップで選択したサービスが実際に（推論された）データベースサーバーである場合、このペインには期間に基づく上位90%（P90）のデータベースコールが表示されます。db-queryパフォーマンス機能をさらに詳しく調べるには、ペインの上部にある**Database Query Performance**という単語のどこかをクリックします。 - -これにより、DB-query Performanceの概要画面が表示されます - -![DB-query full](../../images/db-query-full.png) - -{{% notice title="Database Query Normalization" style="info" %}} -デフォルトでは、Splunk APMインストルメンテーションはデータベースクエリをサニタイズして、`db.statements` からシークレットや個人を特定できる情報（PII）などの機密データを削除またはマスクします。データベースクエリの正規化をオフにする方法は[こちら](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に基づいて、アプリケーションからデータベースに対して実行されたすべてのDatabase queries **(1)**が表示されます。時間ブロック間で比較したり、Total Time、P90 Latency & Requests **(2)**でソートしたりできることに注意してください。 - -リスト内の各Database queryについて、時間ウィンドウ中の最高レイテンシ、コールの総数、および1秒あたりのリクエスト数 **(3)**が表示されます。これにより、クエリを最適化できる場所を特定できます。 - -右側のペイン **(5)**の2つのチャートを使用して、Database Callsを含むトレースを選択できます。Tag Spotlightペイン **(6)**を使用して、エンドポイントやタグに基づいて、データベースコールに関連するタグを確認します。 - -クエリの詳細ビューを表示する必要がある場合 - -![details](../../images/query-details.png) - -特定のQuery **(1)**をクリックします。これにより、Query Details pane **(2)**が開き、より詳細な調査に使用できます。 - - diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md deleted file mode 100644 index 9feb863e33..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/6-profiling-db-query/_index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Always-On Profiling & DB Query Performance -linkTitle: 6. Advanced Features -weight: 7 -archetype: chapter -time: 15 minutes ---- - -前の章で見てきたように、APMを使用して、コードに触れることなく、さまざまなサービス間のインタラクションをトレースすることができ、問題をより迅速に特定できます。 - -トレーシングに加えて、**automatic discovery and configuration**は、問題をさらに迅速に発見するのに役立つ追加機能を最初から提供します。このセクションでは、そのうちの2つを見ていきます - -- **Always-on Profiling and Java Metrics** -- **Database Query Performance** - -**Always-on Profiling**または**Database Query Performance**についてさらに深く学びたい場合は、[**Debug Problems in Microservices**](/en/scenarios/debug_problems/)という別のNinja Workshopがありますので、そちらをご覧ください。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md deleted file mode 100644 index d0e19b6f2f..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/1-view-logs.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: ログを確認する -linkTitle: 1. ログを確認する -weight: 2 ---- - -ログを表示するには、左側のメニューで ![Logo](../images/logo-icon.png?classes=inline&height=25px) **Log Observer** をクリックします。Log Observerに入ったら、フィルターバーの **Index** が **splunk4rookies-workshop** に設定されていることを確認してください。**(1)** - -次に、**Add Filter** をクリックし、_Fields_ **(2)** オプションを使用して `deployment.environment` フィールド **(3)** を検索します。ドロップダウンリストから、あなたのワークショップインスタンスを選択し **(4)**、`=` (含める) をクリックします。これで、PetClinicアプリケーションからのログメッセージのみが表示されます。 - -![Log Observer sort](../../images/log-observer-sort.png) - -次に、`service.name` フィールドを検索し、値 `customers-service` を選択して `=` (含める) をクリックします。これがフィルターバー **(1)** に表示されます。次に、**Run Search** ボタン **(2)** をクリックします。 - -![Log Observer run](../../images/log-observer-run.png) - -これによりログエントリがリフレッシュされ、`customers-service` からのエントリのみが表示されるように絞り込まれます。 - -![Log Observer](../../images/log-observer-trace-info.png) - -_"Saving pet"_ で始まるエントリ **(1)** をクリックします。サイドペーンが開き、関連するトレースIDやスパンID **(2)** を含む詳細情報を確認できます。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md deleted file mode 100644 index d5f9c20edc..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/2-related-content.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Related Content -linkTitle: 2. Related Content -weight: 3 ---- - -下部のペインには、関連するコンテンツが表示されます。以下のスクリーンショットでは、APMがこのログ行に関連するトレースを見つけたことがわかります **(1)**: - -![RC](../../images/log-apm-rc.png) - -**Trace for 960432ac9f16b98be84618778905af50** **(2)** をクリックすると、このログ行が生成された特定のトレースのAPMウォーターフォールに移動します: - -![waterfall logs](../../images/waterfall-with-logs.png) - -ログに関する **Related Content** ペーンが表示されていることに注意してください **(1)**。これをクリックすると、Log Observerに戻り、このトレースの一部であるすべてのログ行が表示されます。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md deleted file mode 100644 index cc72b4f993..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/7-log-observer-connect/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Log Observer -linkTitle: 7. Log Observer -weight: 8 -archetype: chapter -time: 10 minutes ---- - -この時点まで、**コード変更は一切なく**、トレーシング、プロファイリング、データベースクエリパフォーマンスのデータがSplunk Observability Cloudに送信されています。 - -次に、**Splunk Log Observer** を使用してSpring PetClinicアプリケーションからログデータを取得します。 - -**Splunk OpenTelemetry Collector** は、Spring PetClinicアプリケーションからログを自動的に収集し、OTLPエクスポーターを使用して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/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md deleted file mode 100644 index a358a95ce3..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/1-rum-tour.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Select the RUM view for the Petclinic App -linkTitle: 1. Verify RUM Data -weight: 1 ---- - -左側のメニューで **RUM** をクリックして、RUMの簡単な概要ツアーを始めましょう。次に、**Environment** フィルター **(1)** をドロップダウンボックスから変更し、ワークショップインスタンスの名前 **`-workshop`** **(1)** を選択します (ここで **`INSTANCE`** は、以前に実行したシェルスクリプトの値です)。これのみが選択されていることを確認してください。 - -次に、**App** **(2)** ドロップダウンボックスをアプリの名前に変更します。これは **`-store`** になります。 - -![rum select](../../images/rum-env-select.png) - -**Environment** と **App** を選択すると、アプリケーションのRUMステータスを示す概要ページが表示されます。(Summary Dashboardが単一行の数値だけの場合は、縮小表示になっています。アプリケーション名の前にある **> (1)** をクリックして展開できます)。JavaScriptエラーが発生した場合は、以下のように表示されます: - -![rum overview](../../images/rum-overview.png) - -続けるには、青いリンク (ワークショップ名) をクリックして詳細ページに移動します。これにより、UX Metrics、Front-end Health、Back-end Health、Custom Eventsによるインタラクションの内訳が表示され、過去のメトリクス (デフォルトでは1時間) と比較される新しいダッシュボードビューが表示されます。 - -![rum main](../../images/rum-main.png) -通常、最初のチャートには1つの線のみがあります。Petclinicショップに関連するリンクをクリックしてください。 -この例では http://198.19.249.202:81 です: - -これにより、Tag Spotlightページに移動します。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md deleted file mode 100644 index 3e889f2c2c..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/2-rum-tour.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: RUM trace Waterfall view & linking to APM -linkTitle: 2. Follow RUM Traces -weight: 2 ---- -TAG Spotlightビューでは、RUMデータに関連付けられたすべてのタグが表示されます。タグは、データを識別するために使用されるキーバリューペアです。この場合、タグはOpenTelemetryインストルメンテーションによって自動的に生成されます。タグは、データをフィルタリングし、チャートやテーブルを作成するために使用されます。Tag Spotlightビューでは、動作の傾向を検出し、ユーザーセッションにドリルダウンできます。 - -![RUM TAG](../../images/rum-tag-spotlight.png) - -User Sessions **(1)** をクリックすると、タイムウィンドウ中に発生したユーザーセッションのリストが表示されます。 - -セッションの1つを見たいので、*Duration* **(2)** をクリックして期間でソートし、長いものの1つのリンク **(3)** をクリックしてください: - -![User sessions](../../images/rum-user-sessions.png) diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md deleted file mode 100644 index 9d7aaccde1..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/3-rum-tour.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: RUM trace Waterfall view & linking to APM -linkTitle: 3. RUM Waterfall -weight: 3 ---- - -RUMトレースウォーターフォールを見ています。これは、ユーザーがpetclinicアプリケーションのページにアクセスしたときに、ユーザーデバイス上で何が起こったかを示します。 - -ウォーターフォールを下にスクロールして、右側の **#!/owners/details** セグメント **(1)** を見つけてクリックすると、Vetsリクエストの処理中に発生したアクションのリストが表示されます。HTTPリクエストには、リターンコードの前に青い **APM** リンクがあることに注意してください。1つを選択し、APMリンクをクリックします。これにより、KubernetesでホストされているこのバックエンドサービスコールのAPM情報が表示されます。 - -![rum apm link](../../images/rum-trace.png) - -リクエストで何が起こったかを確認するためにドリルダウンしたい場合は、Trace IDのURLをクリックしてください。 - -これにより、RUMからのリクエストに関連するトレースが表示されます: - -![RUm-apm linked](../../images/rum-apm-waterfall.png) - -サービスへのエントリーポイントに **RUM (1)** 関連コンテンツリンクが追加されており、バックエンドサービスで何が起こったかを確認した後、RUMセッションに戻ることができるようになっていることがわかります。 diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md deleted file mode 100644 index fb8b6dbe1e..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/8-rum/_index.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -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/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md deleted file mode 100644 index 49407f1ce1..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Workshop Wrap-up 🎁 -linkTitle: 9. Workshop Wrap-up -weight: 9 -archetype: chapter -description: おめでとうございます。OpenTelemetry の自動検出と設定を使用して既存の Kubernetes Java アプリケーションを最大限に活用するワークショップを完了しました。今日、既存の Kubernetes 上の Java アプリケーションにトレース、コードプロファイリング、データベースクエリパフォーマンスを追加することがいかに簡単かを学びました。これにより、アプリケーションとインフラストラクチャの可観測性を即座に向上させることができます。 ---- - -おめでとうございます。**Get the Most Out of Your Existing Kubernetes Java Applications Using Automatic Discovery and Configuration With OpenTelemetry** ワークショップを完了しました。 - -今日、既存のKubernetes上のJavaアプリケーションにトレース、コードプロファイリング、データベースクエリパフォーマンスを追加することがいかに簡単かを学びました。 - -**Automatic Discovery and Configuration** を使用して、コードや設定に一切触れることなく、アプリケーションとインフラストラクチャの可観測性を即座に向上させました。 - -また、シンプルな設定変更により、さらに多くの可観測性 (**logging** や **RUM**) をアプリケーションに追加して、エンドツーエンドの可観測性を提供できることも学びました。 - -![Champagne](images/champagne.png?width=45vw) diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/images/champagne.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/images/champagne.png deleted file mode 100644 index 98c0014827..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/9-wrap-up/images/champagne.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/_index.md deleted file mode 100644 index d00c85aa69..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/_index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Kubernetes 上の Spring PetClinic SpringBoot ベースのマイクロサービス -linkTitle: PetClinic Kubernetes ワークショップ -weight: 2 -archetype: chapter -authors: ["Pieter Hagen"] -description: Kubernetes で実行される Java ベースのアプリケーション向けの自動ディスカバリーおよび設定を有効にする方法を学びます。リアルタイムモニタリングを体験し、エンドツーエンドの可視性でアプリケーションの動作を最大限に活用しましょう。 -time: 90 minutes ---- - -このワークショップの目的は、Java向けのSplunk **自動ディスカバリーおよび設定**機能を紹介することです。 - -ワークショップのシナリオは、Kubernetesにシンプルな（**計装されていない**）Javaマイクロサービスアプリケーションをインストールすることで作成されます。 - -既存の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/1-automatic-discovery/2-petclinic-kubernetes/images/auto-instrumentation-java-diagram.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/auto-instrumentation-java-diagram.png deleted file mode 100644 index 2293c72c70..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/auto-instrumentation-java-diagram.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query-full.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query-full.png deleted file mode 100644 index 22dd135b7b..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query-full.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query-map.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query-map.png deleted file mode 100644 index b052e9c13a..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query-map.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query.png deleted file mode 100644 index 45808155ee..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/db-query.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/flamechart-in-waterfall.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/flamechart-in-waterfall.png deleted file mode 100644 index 06c582f458..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/flamechart-in-waterfall.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-navigator-restarted-pods.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-navigator-restarted-pods.png deleted file mode 100644 index 92929bfc93..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-navigator-restarted-pods.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-nodes.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-nodes.png deleted file mode 100644 index 55fad8e82a..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-nodes.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-peek-at-logs.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-peek-at-logs.png deleted file mode 100644 index 0e25e8a924..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/k8s-peek-at-logs.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-apm-rc.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-apm-rc.png deleted file mode 100644 index da0620d4f0..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-apm-rc.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-run.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-run.png deleted file mode 100644 index b6ebdc3a4b..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-run.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-sort.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-sort.png deleted file mode 100644 index 7fa8775555..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-sort.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-trace-info.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-trace-info.png deleted file mode 100644 index ed09b9d33f..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/log-observer-trace-info.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/logo-icon.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/logo-icon.png deleted file mode 100644 index 2e7b098b39..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/logo-icon.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/navigatorlist.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/navigatorlist.png deleted file mode 100644 index db81f331d9..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/navigatorlist.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/petclinic-owners.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/petclinic-owners.png deleted file mode 100644 index bda39a5c28..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/petclinic-owners.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/petclinic.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/petclinic.png deleted file mode 100644 index c4dc2cb55b..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/petclinic.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/profiling-memory.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/profiling-memory.png deleted file mode 100644 index 64da21936d..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/profiling-memory.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/query-details.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/query-details.png deleted file mode 100644 index 307651329d..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/query-details.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-apm-waterfall.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-apm-waterfall.png deleted file mode 100644 index b0f8bc0c04..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-apm-waterfall.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-env-select.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-env-select.png deleted file mode 100644 index adbeb96fc7..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-env-select.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-main.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-main.png deleted file mode 100644 index ad5682471e..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-main.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-overview.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-overview.png deleted file mode 100644 index 2a528b03bf..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-overview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-tag-spotlight.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-tag-spotlight.png deleted file mode 100644 index ef7e5cc4b9..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-tag-spotlight.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-trace.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-trace.png deleted file mode 100644 index 76565dd6c8..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-trace.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-user-sessions.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-user-sessions.png deleted file mode 100644 index 54300a92fd..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/rum-user-sessions.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/select-workflow.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/select-workflow.png deleted file mode 100644 index b3dd42b459..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/select-workflow.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/selecting-a-trace.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/selecting-a-trace.png deleted file mode 100644 index 9db88edb78..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/selecting-a-trace.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/service-view.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/service-view.png deleted file mode 100644 index 0f11a3ab33..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/service-view.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/waterfall-view.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/waterfall-view.png deleted file mode 100644 index 0aa98ec210..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/waterfall-view.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/waterfall-with-logs.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/waterfall-with-logs.png deleted file mode 100644 index 74805a980f..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/waterfall-with-logs.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/zero-config-first-services-map.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/zero-config-first-services-map.png deleted file mode 100644 index 507f41c688..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/zero-config-first-services-map.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/zero-config-first-services-overview.png b/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/zero-config-first-services-overview.png deleted file mode 100644 index 435b46076d..0000000000 Binary files a/content/ja/ninja-workshops/1-automatic-discovery/2-petclinic-kubernetes/images/zero-config-first-services-overview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/1-automatic-discovery/_index.md b/content/ja/ninja-workshops/1-automatic-discovery/_index.md deleted file mode 100644 index 2cadf2bee6..0000000000 --- a/content/ja/ninja-workshops/1-automatic-discovery/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: 自動ディスカバリーワークショップ -description: Java アプリケーション向けの Splunk 自動ディスカバリーおよび設定機能の活用方法を学びます。これらのワークショップでは、ゼロコード計装を使用して、モノリスおよび Kubernetes デプロイメント全体でメトリクス、トレース、ログを即座に生成し、包括的なオブザーバビリティを実現する方法をデモンストレーションします。 -weight: 1 ---- - -{{% children type="card" depth="1" description="true" %}} diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/1-introduction/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/1-introduction/_index.md deleted file mode 100644 index 2d52b4ea1b..0000000000 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/1-introduction/_index.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Splunk Observability Cloud における AI の概要 -linkTitle: 1. Introduction -weight: 1 ---- - -## 概要 - -人工知能（AI）と機械学習（ML）は、オブザーバビリティへのアプローチ方法を変革しています。ルールやしきい値を手動で作成したり、膨大な量のデータを検索したりする代わりに、AIは以下のことを支援します： - -- 学習したパターンに基づいて**異常を自動的に検出**する -- 問題を調査する際に**関連するコンテキストを表示**する -- インテリジェントな相関分析により**根本原因をより迅速に特定**する -- ユーザーに影響が及ぶ前に**将来の問題を予測**する -- よりスマートでコンテキストを考慮した通知で**アラートノイズを削減**する - -## Splunk Observability Cloud の AI 機能 - -Splunk Observability Cloudは、プラットフォーム全体にAIとMLを統合しています： - -### 1. Related Content - -現在表示している内容に基づいて、関連するダッシュボード、ディテクター、リソースを表示するコンテキストAIです。複雑な環境をより効率的にナビゲートするのに役立ちます。 - -### 2. AutoDetect - -機械学習を活用したディテクター作成機能です。手動でしきい値を設定することなく、自動的にベースラインを確立し、お客様の環境に固有の異常を検出します。 - -### 3. Tag Spotlight - -メタデータとタグ全体のパターンを分析し、パフォーマンス低下の原因を特定するAI駆動の根本原因分析機能です。 - -### 4. Log Observer AI - -ログにおける高度なパターン認識と異常検出機能です。複雑なログデータを理解するための自然言語機能を備えています。 - -### 5. APM AI Assistant - -アプリケーションパフォーマンスのトラブルシューティングをインテリジェントにガイドし、トレースデータの理解とボトルネックの特定を支援します。 - -### 6. Predictive Analytics - -MLモデルを使用して将来のトレンドとキャパシティのニーズを予測する予測機能です。 - -## ワークショップの前提条件 - -このワークショップには以下が必要です： - -- Splunk Observability Cloud組織へのアクセス（トライアルまたは本番環境） -- Splunk Observability Cloudのナビゲーションに関する基本的な知識 -- オブザーバビリティの基本概念（メトリクス、トレース、ログ）の理解 - -{{% notice title="Note" style="info" %}} -このワークショップでは、Splunk Observability Cloudで利用可能なデモデータと実際の機能を使用します。一部のAI機能には特定のエンタイトルメントが必要な場合や、プレビューモードの場合があります。 -{{% /notice %}} - -それでは、AIがオブザーバビリティの実践をどのように強化できるかを探っていきましょう！ diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/2-related-content/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/2-related-content/_index.md deleted file mode 100644 index 5ebc7f5f38..0000000000 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/2-related-content/_index.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Related Content -linkTitle: 2. Related Content -weight: 2 ---- - -## Related Content とは？ - -Related Contentは、Splunk Observability CloudのAIを活用した機能で、オブザーバビリティデータを確認する際に、コンテキストに関連する情報を自動的に表示します。関連するダッシュボード、ディテクター、トレースを手動で検索する代わりに、AIエンジンが現在のコンテキストを分析し、最も関連性の高いリソースを提示します。 - -## Related Content の仕組み - -AIエンジンは複数の要素を考慮します： - -- **現在の表示コンテキスト**: 確認しているサービス、ホスト、またはメトリクス -- **メタデータとタグ**: 共通のディメンションとプロパティ -- **ユーザーの行動パターン**: 他のユーザーが類似のコンテキストで通常表示する内容 -- **時間的関係**: リソース間の時間ベースの相関関係 -- **意味的関係**: 名前付きエンティティとその論理的な接続 - -## 主なメリット - -1. **迅速なナビゲーション**: 手動検索なしで関連リソースに直接移動できます -2. **隠れた関係の発見**: 存在を知らなかったつながりを見つけることができます -3. **効率的な調査**: インシデント対応中にAIが提案するパスをたどることができます -4. **ナレッジの発見**: 他のチームが作成したダッシュボードやディテクターについて学べます - -## Related Content が表示される場所 - -Related Contentはプラットフォーム全体のいくつかの場所に表示されます： - -- **Dashboard ページ**: 関連するダッシュボードとディテクターを表示 -- **APM サービスページ**: 関連するトレース、ログ、インフラストラクチャを表示 -- **Detector ページ**: 関連するダッシュボードと他のディテクターを検索 -- **Chart ページ**: 関連する可視化とメトリクスを発見 - -## ハンズオン演習 - -{{% notice title="演習" style="primary" icon="tasks" %}} - -### APM で Related Content を探索する - -1. Splunk Observability Cloud組織で **APM** → **Services** に移動します -2. リストから任意のサービスを選択します -3. **Related Content** セクションを探します（通常は右サイドバーまたはページ下部にあります） -4. 提案されるリソースの種類に注目します： - - 関連するダッシュボード - - 関連するディテクター - - 接続されたサービス - - インフラストラクチャコンポーネント -5. 提案された項目の1つをクリックして、コンテキストがどのように変化するか観察します -6. 新しいビューでRelated Contentを確認します - 現在のコンテキストにどのように適応するかに注目してください - -{{% /notice %}} - -## 推奨事項を理解する - -Related Contentの提案が表示されたら、以下を考慮してください： - -- **なぜ関連しているのか？**: 共通のタグ、命名パターン、または依存関係を確認します -- **関係の強さ**: 上部に表示される項目は通常、より強く関連しています -- **カバレッジ**: 期待するコンテンツが表示されない場合は、より良いタグ付けやメタデータが必要かもしれません - -## ベストプラクティス - -Related Contentを最大限に活用するには： - -1. サービス、ダッシュボード、ディテクターに**一貫した命名規則を使用**します -2. リソースに**包括的なタグを適用**します -3. **カスタムプロパティを活用**して意味的な関係を作成します -4. 調査中に**提案に従って**新しいインサイトを発見します - -{{% notice title="ヒント" style="info" icon="lightbulb" %}} -一貫したタグ付けと命名でSplunk Observability Cloudを使用すればするほど、Related Content AIは関連情報をより効果的に表示できるようになります。 -{{% /notice %}} - -## 次のステップ - -Related Contentを理解したので、次はAutoDetectがMLを使用してインテリジェントなディテクターを自動的に作成する方法を見ていきましょう。 diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/3-autodetect/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/3-autodetect/_index.md deleted file mode 100644 index 33ef412144..0000000000 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/3-autodetect/_index.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -title: AutoDetect と ML 駆動の異常検知 -linkTitle: 3. AutoDetect -weight: 3 ---- - -## AutoDetect とは？ - -AutoDetectは、手動でのしきい値設定を必要とせずに、メトリクスに対してインテリジェントなディテクターを自動的に作成する機械学習を活用した機能です。静的なしきい値を推測する代わりに、AutoDetectはメトリクスの正常な動作パターンを学習し、逸脱が発生したときにアラートを発します。 - -## AutoDetect の仕組み - -AutoDetectは複数のML技術を使用します： - -1. **ベースライン学習**: 過去のデータを分析して正常なパターンを理解します -2. **季節性認識**: 日次、週次、月次のパターンを認識します -3. **動的しきい値**: メトリクスの変動性に基づいて感度を調整します -4. **コンテキスト異常**: よりスマートなアラートのために複数のシグナルを一緒に考慮します - -## ML 駆動ディテクターの種類 - -### 急激な変化の検知 - -学習したパターンを超えてメトリクスが急激にスパイクまたは低下したときにアラートを発します。 - -### 履歴異常検知 - -時間帯や曜日のパターンを考慮して、現在の値を過去の基準値と比較します。 - -### リソースディテクター - -一般的なインフラストラクチャリソース（CPU、メモリ、ディスク）用の事前設定されたMLディテクターです。 - -## ハンズオン演習：AutoDetect ディテクターの作成 - -{{% notice title="演習" style="primary" icon="tasks" %}} - -### ステップ 1：ディテクター作成画面への移動 - -1. **Alerts & Detectors** → **Detectors** に移動します -2. **New Detector** をクリックします -3. **AutoDetect** または **From Template** を選択します - -### ステップ 2：メトリクスの選択 - -1. 一貫したトラフィックがあるメトリクスを選択します（例：`demo.trans.latency` または `cpu.utilization`） -2. 関連するフィルター（環境、サービスなど）を追加します -3. チャートを確認してデータが流れていることを確認します - -### ステップ 3：ML 設定の構成 - -1. **Sudden Change** または **Historical Anomaly** モードを選択します -2. 感度を調整します： - - **Low**: アラート数が少なく、大きな逸脱のみを検知 - - **Medium**: バランスの取れたアプローチ（推奨） - - **High**: より敏感で、微妙な変化も検知 -3. 観測ウィンドウ（考慮する履歴の長さ）を設定します - -### ステップ 4：アラート設定の構成 - -1. アラートの重要度（Critical、Warning、Info）を設定します -2. 通知の受信者を設定します -3. アラートメッセージをカスタマイズします -4. 確認してディテクターを有効化します - -{{% /notice %}} - -## ML ディテクターの動作を理解する - -### 学習期間 - -AutoDetectディテクターはベースラインを確立するために時間が必要です： - -- **最小**: 24時間のデータ -- **推奨**: 安定したベースラインのために1〜2週間 -- **季節パターン**: 週次パターンのために4週間以上 - -### 感度のチューニング - -感度設定はディテクターの検知強度を制御します： - -```text -Low Sensitivity → Fewer false positives, might miss subtle issues -Medium Sensitivity → Balanced (default) -High Sensitivity → Catches more anomalies, more noise possible -``` - -## ベストプラクティス - -1. **Medium 感度から始める**: アラート量に基づいて調整します -2. **適切なメトリクスを使用する**: AutoDetectは以下のようなメトリクスで最も効果的です： - - 明確なパターンを持つメトリクス（レイテンシ、リクエストレート） - - 安定した連続的なデータストリーム - - 十分な履歴データ -3. **関連するディメンションでグループ化**: タグを使用して焦点を絞ったディテクターを作成します -4. **学習時間を確保**: 最初の48時間で効果を判断しないでください -5. **レビューとチューニング**: トリガーされたアラートを定期的にレビューして感度を調整します - -## AutoDetect と静的しきい値の使い分け - -| AutoDetect を使用する場合... | 静的しきい値を使用する場合... | -|------------------------|-------------------------------| -| メトリクスに自然な変動がある | 既知の固定された制限がある | -| パターンが時間とともに変化する | 要件が規制や契約に基づいている | -| トラフィックが季節的または周期的 | シンプルな二値条件（稼働/停止） | -| 「正しい」しきい値がわからない | しきい値が確立されている | - -## AutoDetect のパフォーマンス監視 - -MLディテクターを作成した後： - -1. **アラート履歴のレビュー**: 誤検知・検知漏れを確認します -2. **感度の調整**: アラートの品質に基づいて微調整します -3. **ベースラインの更新**: MLモデルは変化に自動的に適応します -4. **従来のディテクターとの比較**: MLがより早く問題を検知するか確認します - -{{% notice title="ヒント" style="info" icon="lightbulb" %}} -AutoDetectは、ユーザートラフィック、トランザクション量、APIリクエストレートなど、時間帯や曜日によって変動するメトリクスに特に効果的です。 -{{% /notice %}} - -## よくある落とし穴 - -- **データ不足**: パターンを学習するのに十分な履歴が必要です -- **ディメンションが多すぎる**: 多くのタグで分割するとMLモデルが希薄化する可能性があります -- **不安定なメトリクス**: 非常に不規則なメトリクスはノイズの多いアラートを生成する可能性があります -- **最近のデプロイ**: 新しいサービスにはベースラインデータがありません - -## 次のステップ - -AutoDetectを理解したところで、AI駆動の根本原因分析のためのTag Spotlightを探索しましょう。 diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/4-tag-spotlight/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/4-tag-spotlight/_index.md deleted file mode 100644 index 235f13c0cf..0000000000 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/4-tag-spotlight/_index.md +++ /dev/null @@ -1,204 +0,0 @@ ---- -title: Tag Spotlight - AIによる根本原因分析 -linkTitle: 4. Tag Spotlight -weight: 4 ---- - -## Tag Spotlight とは - -Tag Spotlightは、タグやメタデータ全体のパターンを自動的に分析することで、パフォーマンス問題の根本原因を迅速に特定できるAI搭載の分析機能です。数百ものタグの組み合わせを手動でフィルタリングする代わりに、Tag Spotlightは機械学習を使用して、パフォーマンス低下と最も強く相関するタグ値をハイライト表示します。 - -## Tag Spotlight が解決する問題 - -以下のようなサービスがあると想像してください： - -- 10の異なるリージョン -- リージョンごとに5つのアベイラビリティゾーン -- 20の異なるサービスエンドポイント -- 3つのデプロイバージョン - -手動でチェックする組み合わせは最大3,000にもなります！Tag Spotlightはすべての組み合わせを自動的に分析し、問題のあるものを表面化させます。 - -## Tag Spotlight の仕組み - -Tag Spotlightはいくつかの分析技術を使用します： - -1. **統計分析**：すべてのタグ値にわたるパフォーマンスを比較します -2. **パターン認識**：多次元データの異常なパターンを識別します -3. **貢献度分析**：どのタグが問題に最も貢献しているかを計算します -4. **相関スコアリング**：問題との関連性でタグをランク付けします - -## Tag Spotlight へのアクセス - -Tag Spotlightは主に2つの場所で利用できます： - -### APM Service Maps 内 - -1. **APM** → **Services** に移動します -2. 問題が発生しているサービスを選択します -3. トラブルシューティングパネルで **Tag Spotlight** をクリックします - -### Troubleshooting MetricSets 内 - -1. Troubleshooting MetricSet (TMS) を作成またはアクセスします -2. Tag SpotlightはTMS分析ビューに組み込まれています - -## ハンズオン演習：Tag Spotlight の使用 - -{{% notice title="演習" style="primary" icon="tasks" %}} - -### ステップ 1：APM で Tag Spotlight にアクセス - -1. **APM** → **Services** に移動します -2. 複数のタグを持つサービスを選択します（例：異なるリージョン、バージョン、エンドポイント） -3. **Tag Spotlight** または **Troubleshooting** セクションを探します - -### ステップ 2：結果を分析 - -Tag Spotlightは以下を表示します： - -- パフォーマンス問題への**貢献度でランク付けされたタグ** -- タグ値ごとのパフォーマンスを示す**比較チャート** -- 各タグの**貢献率** -- **統計的有意性**のインジケーター - -### ステップ 3：結果を解釈 - -以下を探します： - -- **高貢献度のタグ**：上位にあるタグが最も影響が大きい -- **外れ値**：異なるパフォーマンスを示す特定のタグ値 -- **時間相関**：乖離はいつ始まったか？ - -### ステップ 4：ドリルダウン - -1. ハイライトされたタグ値をクリックしてビューをフィルタリングします -2. そのタグの特定のトレースまたはメトリクスを調べます -3. パフォーマンスが良好なタグ値と比較します -4. 根本原因を特定します（コード、インフラストラクチャ、設定） - -{{% /notice %}} - -## Tag Spotlight の結果を理解する - -### 貢献度スコア - -各タグに関連するパフォーマンス問題の割合を示します： - -```text -Region: us-west-2 → 78% contribution -Version: v2.3.1 → 45% contribution -Endpoint: /checkout → 23% contribution -``` - -パーセンテージが高いほど、問題との相関が強いことを示します。 - -### 統計的有意性 - -Tag Spotlightは以下も考慮します： - -- **サンプルサイズ**：十分なデータポイントがあるか？ -- **分散**：パターンはどの程度一貫しているか？ -- **ベースライン比較**：通常と比較してどうか？ - -## 実世界のユースケース - -### ユースケース 1：リージョンのパフォーマンス低下 - -**症状**：全体的なレイテンシが300ms増加 - -**Tag Spotlight が明らかにすること**： - -- `aws_region: eu-central-1` → 92% の貢献度 -- 他のリージョンは正常に動作 - -**根本原因**：EUリージョンでのデータベースレプリケーションの遅延 - -### ユースケース 2：バージョンロールアウトの問題 - -**症状**：デプロイ後にエラー率が急上昇 - -**Tag Spotlight が明らかにすること**： - -- `version: v3.0.1` → 85% の貢献度 -- `endpoint: /api/search` → 67% の貢献度 - -**根本原因**：新しい検索エンドポイントがメモリリークを引き起こした - -### ユースケース 3：顧客セグメントへの影響 - -**症状**：チェックアウトのレイテンシが増加 - -**Tag Spotlight が明らかにすること**： - -- `tenant: enterprise-tier` → 71% の貢献度 -- `payment_method: invoice` → 58% の貢献度 - -**根本原因**：新しい請求検証がエンタープライズの請求書発行を遅くしている - -## Tag Spotlight のベストプラクティス - -### 1. 豊富なタグ付けを確保する - -Tag Spotlightはタグの質に依存します。以下を含めてください： - -- **インフラストラクチャタグ**：リージョン、AZ、クラスター、ノード -- **アプリケーションタグ**：バージョン、環境、機能フラグ -- **ビジネスタグ**：テナント、顧客ティア、製品ライン -- **カスタムディメンション**：ドメインに関連するもの - -### 2. 一貫したタグ名を使用する - -- サービス間で標準的な命名規則を使用する -- 同義語を避ける（例：`region` と `aws_region` を混在させない） -- タグ付け戦略を文書化する - -### 3. 他のツールと組み合わせる - -Tag Spotlightを以下と併用します： - -- **APM トレース**：実際のトレースデータで結果を検証 -- **メトリクス**：時系列データでパターンを確認 -- **ログ**：特定されたタグのエラーメッセージを検索 - -### 4. Troubleshooting MetricSets を作成する - -重要なサービスには、以下を含むTroubleshooting MetricSetsを事前に設定します： - -- 主要なパフォーマンス指標（レイテンシ、エラー率、スループット） -- 重要なディメンション（リージョン、バージョン、エンドポイント） -- 適切なベースライン比較期間 - -## Troubleshooting MetricSets (TMS) - -TMSはTag Spotlight用に設計されたカスタムメトリクス集計です： - -### TMS の作成 - -1. **APM** → **Troubleshooting MetricSets** に移動します -2. **Create Troubleshooting MetricSet** をクリックします -3. サービスとメトリクスを選択します -4. 分析するディメンションを選択します -5. 保存して有効化します - -### TMS を作成するタイミング - -- **重要なサービス**：厳格なSLAを持つサービス -- **複雑なアーキテクチャ**：多くのディメンションを持つサービス -- **繰り返し発生する問題**：頻繁にパフォーマンス変動があるサービス -- **マルチテナントシステム**：顧客への影響が異なる場合 - -## 制限事項と考慮事項 - -- **十分なデータが必要**：タグ値ごとに十分なサンプルが必要 -- **相関 ≠ 因果関係**：Tag Spotlightは相関を示します。根本原因は検証してください -- **タグのカーディナリティ**：非常に高いカーディナリティのタグ（例：ユーザー ID）は有用でない場合があります -- **時間枠が重要**：適切な比較期間を選択してください - -{{% notice title="ヒント" style="info" icon="lightbulb" %}} -Tag Spotlightは、分析対象となる明確なパフォーマンス低下期間がある場合に最も効果的に機能します。正確な結果を得るために、ベースラインと比較ウィンドウを慎重に定義してください。 -{{% /notice %}} - -## 次のステップ - -Tag Spotlightを理解したところで、Log ObserverのAI機能を見ていきましょう。 diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/5-log-observer-ai/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/5-log-observer-ai/_index.md deleted file mode 100644 index c840bb47bb..0000000000 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/5-log-observer-ai/_index.md +++ /dev/null @@ -1,255 +0,0 @@ ---- -title: AIを活用したログ分析 -linkTitle: 5. Log Observer AI -weight: 5 ---- - -## Log Observer の AI 機能 - -Splunk Observability CloudのLog Observerには、大量のログデータを理解するのに役立つAI搭載機能がいくつか含まれています： - -- **パターン検出**: ログ内の一般的なパターンを自動的に識別 -- **異常のハイライト**: 異常なログエントリやパターンを表面化 -- **ログクラスタリング**: 類似したログメッセージをグループ化 -- **インテリジェントフィルタリング**: コンテキストに基づいたAI推奨フィルター -- **自然言語クエリ**: 自然言語を使用したログのクエリ（利用可能な場合） - -## パターン検出 - -### ログパターン検出とは - -個々のログ行を表示する代わりに、パターン検出はログを構造でグループ化し、以下のことを容易にします： - -- 頻出パターンと稀なパターンの識別 -- 新しいまたは異常なログパターンの発見 -- 異常なエントリへの集中 -- 繰り返しログからのノイズ削減 - -### 仕組み - -AIエンジンは： - -1. ログメッセージの構造を分析 -2. 可変部分（ID、タイムスタンプ、値）を識別 -3. パターンテンプレートを作成 -4. テンプレートでログをグループ化 -5. パターンの頻度と変化を追跡 - -## ハンズオン演習：ログパターンの探索 - -{{% notice title="演習" style="primary" icon="tasks" %}} - -### ステップ 1: Log Observer にアクセス - -1. **Log Observer** に移動します -2. アクティブなログデータがある時間範囲を選択します -3. 多様なログを持つサービスまたはインデックスを選択します - -### ステップ 2: パターンビューを有効化 - -1. **Patterns** または **Pattern Analysis** ビューを探します -2. 個別ログビューからパターンビューに切り替えます -3. ログがどのようにクラスタリングされているかを観察します - -### ステップ 3: パターンを分析 - -パターンリストを確認します： - -- **高頻度パターン**: 通常の、予想されるログ -- **新しいパターン**: 最近出現した（潜在的な問題） -- **稀なパターン**: 低頻度、調査の価値あり -- **エラーパターン**: 構造化されたエラーメッセージ - -### ステップ 4: 異常を調査 - -1. 稀なパターンまたは新しいパターンをクリックします -2. そのパターンのログ例を表示します -3. ベースライン/通常パターンと比較します -4. 問題を示しているかどうかを判断します - -{{% /notice %}} - -## ログ異常検出 - -### 検出される異常の種類 - -1. **頻度の異常**: ログ量の急激な増加/減少 -2. **コンテンツの異常**: 異常なフィールド値またはメッセージ内容 -3. **パターンの異常**: ベースラインで見られない新しいパターン -4. **タイミングの異常**: 異常な時間に出現するログ - -### 異常検出の設定 - -MLを使用したログベースのディテクターを設定します： - -1. **Alerts & Detectors** に移動します -2. Log Observerから新しいディテクターを作成します -3. **Anomaly Detection** モードを選択します -4. 設定項目： - - ベースライン期間 - - 感度レベル - - アラート条件 - - 通知チャンネル - -## インテリジェントログフィルタリング - -### AI 推奨フィルター - -調査中に、Log Observerは以下を提案する場合があります： - -- **関連フィールド**: フィルタリングする価値のあるタグや属性 -- **一般的な値**: 頻繁に出現するフィールド値 -- **異常な値**: 注目に値する異常なフィールド値 -- **相関属性**: 一緒に出現することが多いフィールド - -### 推奨フィルターの使用 - -1. UIでフィルターの提案を探します -2. クリックして推奨フィルターを適用します -3. 結果に基づいて絞り込みます -4. 有用なフィルターの組み合わせを保存します - -## APM およびインフラストラクチャとのログ相関 - -### 自動コンテキストリンク - -AIはログを以下と接続するのを助けます： - -- **トレース**: ログエントリを分散トレースにリンク -- **サービス**: ログをAPMサービスに関連付け -- **インフラストラクチャ**: ホスト、コンテナ、Podに接続 -- **メトリクス**: ログパターンをメトリクスの変化と相関 - -### AI のパンくずリストをたどる - -調査中： - -1. ログエントリまたはパターンから開始します -2. **Related Content** の提案を探します -3. 相関するトレース、メトリクス、またはインフラストラクチャにジャンプします -4. Tag Spotlightを使用して問題を絞り込みます -5. ログに戻って調査結果を確認します - -## ログの要約とインサイト - -### 主要インサイトパネル - -AI生成のインサイトには以下が含まれる場合があります： - -- **エラー率のサマリー**: エラータイプ別にグループ化 -- **サービスの健全性**: ログの重大度に基づく -- **トレンド分析**: 時間の経過に伴うログパターンの変化 -- **比較分析**: 現在とベースライン期間の比較 - -### インサイトの例 - -```text -⚠️ Error rate increased 340% in the last hour - → Top error: "Database connection timeout" (1,247 occurrences) - → Affected services: checkout-service, payment-service - → Started at: 14:23 UTC - -📊 New log pattern detected - → "WARN: Cache miss for key {key}" appeared 892 times - → First seen: 14:25 UTC - → May indicate cache invalidation issue -``` - -## AI を活用したログ分析のベストプラクティス - -### 1. ログを構造化する - -構造化ログを使用してAIを支援します： - -```json -{ - "timestamp": "2024-01-15T14:23:45Z", - "level": "ERROR", - "service": "checkout-service", - "message": "Payment processing failed", - "error_code": "PAYMENT_TIMEOUT", - "transaction_id": "txn_123456", - "customer_tier": "enterprise" -} -``` - -### 2. 一貫したフィールド名を使用する - -- サービス間でフィールド命名を標準化します -- 共通のタクソノミーを使用します（例：`serviceName` や `service_id` ではなく `service.name`） -- すべてのログに必須のコンテキストを含めます - -### 3. 適切なログレベルを設定する - -- **DEBUG**: 詳細な診断情報（開発用） -- **INFO**: 一般的な情報メッセージ -- **WARN**: 潜在的に有害な状況 -- **ERROR**: アプリが継続できる可能性のあるエラーイベント -- **FATAL**: 早期終了を引き起こす重大なエラー - -### 4. ログサンプリングを活用する - -大量のログの場合： - -- AIを使用して代表的なサンプルを識別します -- エラーログと異常に焦点を当てます -- インテリジェントサンプリングを適用してコストを削減します - -### 5. ログベースのディテクターを作成する - -以下に対するアラートを設定します： - -- 重大なエラーパターン -- 異常なログ量 -- 新しいエラータイプ -- セキュリティ関連のパターン - -## ユースケース - -### ユースケース 1: メモリリークの特定 - -**観察結果**: パターン分析で「GC pressure」警告の増加を表示 - -**AI の支援**： - -- GC関連のログパターンをグループ化 -- 頻度の増加をハイライト -- メモリメトリクスと相関 -- 影響を受けるサービスのトレースにリンク - -### ユースケース 2: セキュリティ問題の検出 - -**観察結果**: 新しいパターン「Authentication failed」が出現 - -**AI の支援**： - -- 新規/稀なパターンとしてフラグ付け -- ソースIPでクラスタリング -- 異常なアクセスパターンをハイライト -- セキュリティ関連のフィルターを提案 - -### ユースケース 3: データベースパフォーマンスの低下 - -**観察結果**: スロークエリの警告が増加 - -**AI の支援**： - -- パターンでクエリをグループ化 -- 最も遅いクエリタイプを特定 -- データベースメトリクスと相関 -- アプリケーショントレースにリンク - -## 制限事項と考慮事項 - -- **パターンの品質はログ構造に依存**: 非構造化ログはパターン化が困難 -- **高カーディナリティフィールド**: UUIDや一意のIDはパターンを分割する可能性 -- **学習期間**: AIは異常検出のためにベースラインデータが必要 -- **コンテキストが重要**: ログAIを他のオブザーバビリティシグナルと組み合わせる - -{{% notice title="ヒント" style="info" icon="lightbulb" %}} -最も効果的なログ分析は、AIを活用したパターン検出とドメイン知識を組み合わせます。AIを使用してシグナルを表面化し、あなたの専門知識を適用して解釈します。 -{{% /notice %}} - -## 次のステップ - -Log ObserverのAI機能を理解したところで、アプリケーションのトラブルシューティングのためのAPM AI Assistantを探索しましょう。 diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/6-apm-assistant/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/6-apm-assistant/_index.md deleted file mode 100644 index 86c7840cc5..0000000000 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/6-apm-assistant/_index.md +++ /dev/null @@ -1,262 +0,0 @@ ---- -title: APM AI Assistant とインテリジェントトラブルシューティング -linkTitle: 6. APM AI Assistant -weight: 6 ---- - -## APM AI Assistant とは？ - -APM AI Assistantは、コンテキストに応じたガイダンスの提供、トレースの分析、調査中の次のステップの提案により、アプリケーションパフォーマンスの問題のトラブルシューティングを支援するインテリジェントな機能です。APMデータを理解し、解決策に導く仮想エキスパートとして機能します。 - -{{% notice title="Note" style="info" %}} -AI Assistantの機能は、Splunk Observability Cloudのバージョンとライセンスによって異なる場合があります。ここで説明する機能の一部は、プレビュー段階であるか、特定のライセンスが必要な場合があります。 -{{% /notice %}} - -## 主な機能 - -### 1. トレース分析 - -- **自動スパン分析**: 遅いスパンや問題のあるスパンを特定します -- **ボトルネック検出**: 分散トレースにおけるパフォーマンスのボトルネックをハイライトします -- **エラーパターン認識**: エラートレースをグループ化して分析します -- **依存関係のインサイト**: サービスの依存関係と呼び出しパターンを理解します - -### 2. ガイド付きトラブルシューティング - -- **根本原因の提案**: トレースデータに基づいて可能性の高い根本原因を提案します -- **調査の経路**: 次に調べるべき項目を提案します -- **過去との比較**: 現在の問題を過去のパターンと比較します -- **解決策の推奨**: 類似の問題に基づいて潜在的な修正を提案します - -### 3. コンテキストに応じたインサイト - -- **自然言語による要約**: 複雑なトレースを平易な言葉で説明します -- **影響評価**: 問題の範囲と深刻度を推定します -- **サービスヘルスのインサイト**: サービスパフォーマンスの傾向を要約します -- **異常の説明**: なぜそれが異常と見なされるかを説明します - -## AI Assistant がどのように役立つか - -### シナリオ 1: 遅いトレースの調査 - -**従来のアプローチ:** - -1. トレースウォーターフォールを開く -2. すべてのスパンを手動でスキャン -3. 所要時間を計算 -4. 最も遅い操作を特定 -5. 他のトレースと相互参照 -6. 根本原因についての仮説を立てる - -**AI Assistant を使用した場合:** - -1. トレースを開く -2. AIがハイライト: "Database query in checkout-service took 2.3s (95th percentile: 45ms)" -3. 提案: "Check database index on orders table" -4. 同じパターンの類似トレースにリンク -5. パターンがいつ始まったかを表示 - -### シナリオ 2: エラーパターンの理解 - -**AI Assistant が提供するもの:** - -- 類似エラーのグループ化 -- 発生頻度の分析 -- 最初の発生タイムスタンプ -- 影響を受けたエンドポイントとサービス -- エラートレース全体に共通する属性 -- 推奨される調査手順 - -## ハンズオン演習: AI を活用した APM 機能の使用 - -{{% notice title="Exercise" style="primary" icon="tasks" %}} - -### ステップ 1: サービスインサイトの探索 - -1. **APM** → **Services** に移動します -2. パフォーマンスデータのあるサービスを選択します -3. AIが生成したインサイトや要約を探します: - - サービスヘルススコア - - パフォーマンスの傾向 - - 異常インジケーター - - 主な問題やボトルネック - -### ステップ 2: AI アシスタンスを使用したトレースの分析 - -1. **APM** → **Traces** に移動します -2. 遅いトレースまたはエラートレースでフィルタリングします -3. トレースウォーターフォールビューを開きます -4. AIを活用した機能を探します: - - ハイライトされた問題のあるスパン - - 自動クリティカルパス特定 - - ベースライントレースとの比較 - - 提案された根本原因 - -### ステップ 3: 自動根本原因検出の活用 - -1. トレースビューで **Root Cause** または **Insights** パネルを見つけます -2. AIの提案を確認します: - - どのスパンがボトルネックか？ - - 通常の動作と比較して何が変わったか？ - - どのタグや属性が問題と相関しているか？ -3. 提案された調査パスに従います -4. 特定されたコンポーネントをドリルダウンします - -### ステップ 4: トレース比較の使用 - -1. 問題のあるトレースを選択します -2. **Compare** または **Similar Traces** 機能を探します -3. AIが表示するもの: - - 類似の正常なトレース（ベースライン） - - 遅いトレースで何が異なるか - - 統計的な比較 -4. 異常なコンポーネントを特定します - -{{% /notice %}} - -## インテリジェントトレース機能 - -### クリティカルパスのハイライト - -AIは分散トレースを通じてクリティカルパスを自動的に特定します: - -- **クリティカルスパン**: 合計レイテンシに直接寄与したスパン -- **並列化可能なスパン**: 非同期処理で最適化できるスパン -- **待機時間**: ダウンストリームサービスを待機している時間 - -### スパン異常検出 - -AIは以下を考慮して異常なスパンを検出します: - -- **所要時間**: 過去のベースラインとの比較 -- **頻度**: このスパンがどのくらい頻繁に出現するか -- **エラー率**: このスパンのエラー vs通常時 -- **コンテキスト**: 通常とは異なるタグや属性 - -### サービス依存関係のインテリジェンス - -AIはサービスアーキテクチャを理解します: - -- **依存関係マッピング**: サービス間の関係を自動的にマッピング -- **影響分析**: サービスの問題が依存先にどのように影響するかを予測 -- **循環依存の検出**: 問題のある呼び出しパターンを特定 -- **最適化の提案**: アーキテクチャの改善を推奨 - -## AI を活用した APM アラート - -### スマートアラート優先順位付け - -AIは以下によりアラートの優先順位付けを支援します: - -- **ビジネス影響スコアリング**: ユーザー/収益への影響を推定 -- **過去のコンテキスト**: 過去の類似アラートと比較 -- **相関分析**: 関連するアラートをグループ化 -- **ノイズ削減**: 誤検知の可能性が高いものを抑制 - -### 適応型しきい値 - -APMベースのディテクター向け: - -- **動的ベースライン**: トラフィックパターンに基づいてしきい値を調整 -- **季節性の認識**: 時間帯/曜日のパターンを考慮 -- **デプロイメントの認識**: デプロイメントイベントを認識 -- **トラフィック比例アラート**: トラフィック量の変化に応じて調整 - -## 自然言語機能 - -### 質問する（利用可能な場合） - -一部のAI Assistant実装では、自然言語クエリが可能です: - -**質問の例:** - -- "Why is checkout-service slow?" -- "What changed in the last hour?" -- "Which endpoints are experiencing errors?" -- "Show me traces from customer tier enterprise" -- "Compare current performance with last week" - -**AI が提供するもの:** - -- 自然言語での回答 -- 関連するトレースとメトリクス -- データの可視化 -- 推奨される次のステップ - -## AI Assistant のベストプラクティス - -### 1. 豊富なコンテキストを提供する - -AIがあなたを助けられるようにしましょう: - -- 説明的なスパン名を使用する -- 関連するタグと属性を追加する -- スパンにエラーの詳細を含める -- デプロイメントイベントにタグを付ける - -### 2. 信頼しつつ検証する - -- AIの提案を出発点として使用する -- 実際のデータで発見を検証する -- メトリクスとログと相互参照する -- ドメイン知識を適用する - -### 3. AI パターンから学ぶ - -- AIが特定する一般的な根本原因に注目する -- どのタグが最も有用かを観察する -- AIが提案する調査パスを研究する -- 繰り返しパターンに基づいて自動化を構築する - -### 4. フィードバックを提供する - -AI Assistantがフィードバックをサポートしている場合: - -- 役立った提案をマークする -- 不正確な分析を報告する -- システムはあなたのフィードバックから学習します - -## AI Assistant と他の AI 機能の組み合わせ - -### 統合ワークフロー - -1. **アラート発火** (AutoDetect MLディテクター) -2. **Tag Spotlight** で問題を絞り込む -3. **APM AI Assistant** が影響を受けたトレースを分析 -4. **Related Content** が関連ダッシュボードを表示 -5. **Log Observer AI** が相関するログパターンを表示 -6. 完全なコンテキストで**解決** - -### 調査フローの例 - -```text -Alert: "Latency increased on payment-service" - ↓ -Tag Spotlight: "Region: us-west-1 (87% contribution)" - ↓ -APM AI: "Database span duration increased 450%" - ↓ -Trace Analysis: "Connection pool exhausted" - ↓ -Log Observer AI: Pattern "Connection pool timeout" increased - ↓ -Related Content: Dashboard "Database Connection Health" - ↓ -Root Cause: Recent traffic spike exceeded DB connection limits -``` - -## 制限事項と考慮事項 - -- **学習期間**: AIは比較のために過去のデータが必要です -- **データ品質**: 精度はトレースの完全性とタグ付けに依存します -- **コンテキストの境界**: AIはあなたのビジネスロジックを知りません -- **プレビュー機能**: 一部の機能は進化中の可能性があります -- **プライバシー**: 機密データがトレース属性に含まれないようにしてください - -{{% notice title="Tip" style="info" icon="lightbulb" %}} -APM AI Assistantは、アプリケーションが包括的なタグと属性で適切に計装されている場合に最も効果的です。トレースデータが豊富であればあるほど、AIのインサイトも優れたものになります。 -{{% /notice %}} - -## 次のステップ - -ワークショップのまとめと追加リソースで締めくくりましょう。 diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/7-wrap-up/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/7-wrap-up/_index.md deleted file mode 100644 index d6dd4dd4fc..0000000000 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/7-wrap-up/_index.md +++ /dev/null @@ -1,243 +0,0 @@ ---- -title: まとめと次のステップ -linkTitle: 7. まとめ -weight: 7 ---- - -## ワークショップの概要 - -おめでとうございます！「Using AI in Splunk Observability Cloud」ワークショップを完了しました。プラットフォームのAIとML機能について学んだことを振り返りましょう。 - -## 重要なポイント - -### 1. Related Content - -- AIがコンテキストに関連するダッシュボード、ディテクター、リソースを表示します -- 調査中のナビゲーションと発見を加速します -- 使用パターンとメタデータの関係性から学習します -- **ベストプラクティス**: 一貫したタグ付けと命名規則を使用してください - -### 2. AutoDetect と ML 駆動のディテクター - -- 機械学習がインテリジェントなディテクターを自動的に作成します -- 環境固有のパターンと季節性に適応します -- 動的しきい値によりアラートノイズを削減します -- **ベストプラクティス**: ベースライン確立のために1〜2週間の期間を確保してください - -### 3. Tag Spotlight - -- すべてのタグディメンションにわたるAI駆動の根本原因分析 -- パフォーマンス問題に寄与するタグを自動的に特定します -- 手動でのフィルタリングと調査の時間を何時間も節約します -- **ベストプラクティス**: すべてのリソースに包括的で一貫したタグを適用してください - -### 4. Log Observer AI - -- パターン検出により類似のログを自動的にグループ化します -- 異常検出により通常と異なるログエントリをハイライトします -- インテリジェントフィルタリングが関連フィールドを提案します -- **ベストプラクティス**: 一貫したフィールド名で構造化ログを使用してください - -### 5. APM AI Assistant - -- アプリケーション問題のトラブルシューティングのためのインテリジェントなガイダンス -- トレース内のボトルネックと異常の自動検出 -- 自然言語によるインサイトと要約 -- **ベストプラクティス**: 包括的なタグと属性でトレースを充実させてください - -### 6. Predictive Analytics - -- MLモデルが将来のトレンドとキャパシティニーズを予測します -- 潜在的な問題をプロアクティブに特定します -- キャパシティプランニングのためのトラフィック予測 -- **ベストプラクティス**: 正確な予測のために一貫した履歴データを維持してください - -## AI 駆動の調査ワークフロー - -これらすべてのAI機能がどのように連携するかを示します： - -```text -1. Issue Detected - ├─→ AutoDetect ML Detector triggers alert - └─→ Anomaly clearly identified with dynamic baseline - -2. Context Gathering - ├─→ Related Content surfaces relevant dashboards - ├─→ APM AI Assistant provides service health summary - └─→ Log Observer AI shows correlated log patterns - -3. Root Cause Analysis - ├─→ Tag Spotlight identifies problematic tag values - ├─→ APM AI analyzes traces and highlights bottlenecks - └─→ Log patterns confirm findings - -4. Impact Assessment - ├─→ AI estimates scope (which customers/regions affected) - ├─→ Historical comparison shows severity - └─→ Dependency analysis shows downstream impact - -5. Resolution - ├─→ AI suggests potential fixes based on similar past issues - ├─→ Monitor AI metrics to confirm resolution - └─→ AI learns from the incident for future detection -``` - -## AI の効果を最大化する - -### データ品質が鍵 - -AIは提供されるデータの品質に依存します。以下を確認してください： - -- **包括的なタグ付け**: すべてのリソースに一貫してタグを付ける -- **豊富なメタデータ**: ビジネスと技術的なコンテキストを含める -- **構造化ログ**: JSONまたはキーバリュー形式のログを使用する -- **完全なトレース**: すべてのサービスと依存関係を計装する -- **一貫した命名**: 標準的な命名規則を使用する - -### シンプルに始めて、スケールアップする - -1. **1つの AI 機能から始める**: まずAutoDetectまたはTag Spotlightをマスターする -2. **検証と調整**: アラートをレビューして感度を調整する -3. **機能を追加**: 徐々に追加のAI機能を組み込む -4. **ワークフローを統合**: 調査で複数のAI機能を組み合わせる -5. **自動化**: AIのインサイトに基づいてランブックと自動化を構築する - -### 継続的な改善 - -- **AI の提案を定期的にレビュー**: 正確で有用ですか？ -- **感度レベルを調整**: アラートの品質に基づいて調整する -- **タグ付けを拡張**: 価値を発見したら新しいディメンションを追加する -- **ベースラインを更新**: MLモデルが現在の正常を反映していることを確認する -- **知識を共有**: AIが発見を助けたパターンを文書化する - -## 避けるべき一般的な落とし穴 - -| 落とし穴 | 影響 | 解決策 | -|---------|--------|----------| -| 履歴データの不足 | ベースラインが不十分、異常検出が不正確 | 効果を判断する前に1〜2週間待つ | -| 一貫性のないタグ付け | Tag Spotlight が適切に相関できない | タグ名と値を標準化する | -| 感度が高すぎる | 誤検知によるアラート疲労 | 中程度から始めて、結果に基づいて調整する | -| AI の提案を無視 | 貴重なインサイトを見逃す | 提案を調査し、フィードバックを提供する | -| 非構造化ログ | パターン検出機能が制限される | 構造化ログ形式に移行する | -| AI への過度な依存 | コンテキスト固有の問題を見逃す | AI のインサイトとドメイン専門知識を組み合わせる | - -## AI の効果を測定する - -AIの効果を測定するためにこれらのメトリクスを追跡します： - -### 検出メトリクス - -- **MTTD（平均検出時間）**: 問題をより早く発見していますか？ -- **誤検知率**: AutoDetectのアラートは正確ですか？ -- **カバレッジ**: インシデントの何パーセントがAIで検出されましたか？ - -### 調査メトリクス - -- **MTTR（平均復旧時間）**: より早く解決していますか？ -- **根本原因までの時間**: Tag Spotlightがどれだけ早く問題を特定しますか？ -- **調査ステップ数**: 必要な手動ステップが減りましたか？ - -### 効率メトリクス - -- **レビューしたアラート**: シグナルが増え、ノイズが減りましたか？ -- **ダッシュボードの使用状況**: 適切なダッシュボードをより早く見つけていますか？ -- **チームの速度**: 同じリソースでより多くの問題を解決していますか？ - -## 追加リソース - -### ドキュメント - -- [Splunk Observability Cloud Documentation](https://docs.splunk.com/observability) -- [AutoDetect Documentation](https://docs.splunk.com/observability/alerts-detectors-notifications/autodetect.html) -- [Tag Spotlight Guide](https://docs.splunk.com/observability/apm/tag-spotlight.html) -- [Log Observer Documentation](https://docs.splunk.com/observability/logs/intro-logconnect.html) - -### トレーニングと認定 - -- Splunk Observability Cloud Certification -- Advanced APM Training -- ML and AI in Observability webinars - -### コミュニティ - -- Splunk Community Forums -- Splunk Observability Cloud User Group -- Splunk Answers - -### 最新情報を入手 - -- Splunk製品アップデートを購読する -- Splunk AI/ML機能リリースをフォローする -- 新しいAI機能のプレビュープログラムに参加する - -## ハンズオン練習 - -### 学習の次のステップ - -1. **AutoDetect ディテクターを作成**: 重要なサービス用に作成する -2. **Tag Spotlight を構成**: Troubleshooting MetricSetsで構成する -3. **ログパターンを探索**: 実際のログデータで探索する -4. **AI 対応のランブックを構築**: これらの機能を活用したランブックを構築する -5. **チームと共有**: ベストプラクティスを確立して共有する - -### チャレンジ演習 - -さらに挑戦したいですか？これらの上級演習を試してください： - -#### チャレンジ 1: AI 駆動のランブックを構築する - -複数のAI機能を組み合わせたランブックを作成します： - -- AutoDetectディテクターがトリガー -- Tag Spotlightがスコープを特定 -- Related Contentが関連ダッシュボードを検索 -- Log Observer AIが根本原因を確認 - -#### チャレンジ 2: タグ付け戦略を最適化する - -- サービス全体の現在のタグを監査する -- Tag Spotlightが困難になる箇所のギャップを特定する -- 追加のディメンションを実装する -- 調査速度の改善を測定する - -#### チャレンジ 3: ML ディテクターを調整する - -- 重要なメトリクス用にAutoDetectをデプロイする -- 2週間モニタリングする -- アラートの品質（真陽性vs偽陽性）を分析する -- 感度を調整して結果を比較する - -#### チャレンジ 4: AI 強化ダッシュボードを作成する - -- 以下を組み合わせたダッシュボードを構築します： - - ML予測値 - - 異常インジケーター - - Tag Spotlightのインサイト - - Related Contentリンク - -## フィードバックの提供 - -皆様のフィードバックはAI機能の改善に役立ちます： - -- 不正確なAIの提案をSplunkサポートを通じて報告する -- Splunkアカウントチームと成功事例を共有する -- 新しいAI機能のプレビュープログラムに参加する -- コミュニティでの議論に貢献する - -## ありがとうございました - -このワークショップにご参加いただきありがとうございました。AIとMLはオブザーバビリティを変革し、大規模で複雑なシステムの管理を容易にしています。これらのツールをマスターすることで、あなた自身と組織を現代のクラウドネイティブ環境での成功に向けて準備することができます。 - -### ご質問は？ - -- Splunkアカウントチームにお問い合わせください -- [Splunk Community](https://community.splunk.com/) にアクセスしてください -- [Splunk Docs](https://docs.splunk.com/) をご確認ください - -{{% notice title="次のワークショップ" style="primary" icon="forward" %}} -さらに学びたいですか？他の [Splunk4Ninjas ワークショップ](/ninja-workshops/) をチェックして、Splunk Observability Cloudの特定分野の専門知識を深めてください。 -{{% /notice %}} - ---- - -**ワークショップ完了！** このワークショップがお役に立てば幸いです。AIを活用してオブザーバビリティの実践を強化してください！ diff --git a/content/ja/ninja-workshops/10-using-ai-in-o11y/_index.md b/content/ja/ninja-workshops/10-using-ai-in-o11y/_index.md deleted file mode 100644 index d0d8ae7ca8..0000000000 --- a/content/ja/ninja-workshops/10-using-ai-in-o11y/_index.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Splunk Observability Cloud での AI 活用 -linkTitle: Splunk Observability Cloud での AI 活用 -weight: 10 -archetype: chapter -time: 90 minutes -authors: ["Pieter Hagen"] -description: Splunk Observability Cloud に組み込まれた人工知能と機械学習の機能を活用して、トラブルシューティングを加速し、異常を検出し、アプリケーションとインフラストラクチャのパフォーマンスに関するより深いインサイトを得る方法を学びます。 -draft: true -hidden: false ---- - -**Splunk Observability Cloud** は、プラットフォーム全体に高度なAIと機械学習の機能を統合しており、よりスマートに、より速く、より効率的に作業することができます。これらのAI搭載機能により、問題をより迅速に特定し、関係性をより深く理解し、データに基づいた意思決定を自信を持って行うことができます。 - -このワークショップでは、Splunk Observability Cloudで利用可能なさまざまなAIとMLの機能をハンズオン形式で体験します。以下の内容が含まれます： - -* **Related Content**: オブザーバビリティデータをナビゲートする際に、AIがどのようにコンテキストに関連するダッシュボード、アラート、リソースを表示するかを学びます。 -* **AutoDetect**: 機械学習が環境固有のパターンと動作に適応するインテリジェントなディテクターを自動的に作成する方法を学びます。 -* **Tag Spotlight**: AIを活用した分析が、タグとメタデータ全体のパターンを分析することで、パフォーマンス問題の根本原因を迅速に特定する方法を探ります。 -* **Log Observer AI**: AIがインテリジェントなパターン検出、異常識別、自然言語によるインサイトでログ分析をどのように強化するかを確認します。 -* **APM AI Assistant**: アプリケーションパフォーマンスの問題のトラブルシューティングと複雑なトレースの理解に対するAI駆動のガイダンスを体験します。 -* **Predictive Analytics**: MLモデルが将来のトレンドを予測し、ユーザーに影響を与える前に潜在的な問題に事前に対処する方法を理解します。 - -このワークショップを終えると、Splunk Observability CloudのAI機能を効果的に使用して以下を実現する方法を理解できます： - -* 平均検出時間（MTTD）と平均復旧時間（MTTR）の短縮 -* 異常や通常とは異なるパターンの自動検出 -* サービス、インフラストラクチャ、ログ間の複雑な関係性のナビゲーション -* AIによるインサイトに基づいた情報に基づく意思決定 - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです： - -* このページの右上にある左右の矢印（**<** | **>**） -* キーボードの左（◀️）と右（▶️）のカーソルキー -{{% /notice %}} diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/1-getting-started/1-access-cloud-instances.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/1-getting-started/1-access-cloud-instances.md deleted file mode 100644 index 738d86a5a4..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/1-getting-started/1-access-cloud-instances.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: ワークショップ環境への接続方法 -linkTitle: 1.1 ワークショップ環境への接続方法 -weight: 2 ---- - -1. Splunk Enterprise CloudインスタンスのURLを取得する方法 -2. Splunk Observability Cloudワークショップ組織にアクセスする方法 - ---- - -## 1. Splunk Cloud インスタンス - -このワークショップ全体で使用される3つのインスタンスが、すでにプロビジョニングされています： - -1. Splunk Enterprise Cloud -2. Splunk Ingest Processor (SCS Tenant) -3. Splunk Observability Cloud - -Splunk Enterprise CloudとIngest Processorインスタンスは [Splunk Show](https://show.splunk.com) でホストされています。ワークショップに招待された場合、[Splunk Show](https://show.splunk.com) のイベントへの招待メールを受け取っているはずです。または、ワークショップの開始時にイベントへのリンクが提供されます。 - -[splunk.com](https://login.splunk.com/) の認証情報を使用してSplunk Showにログインしてください。このワークショップのイベントが表示されるはずです。イベントを開いて、Splunk CloudおよびIngest Processorインスタンスの詳細を確認してください。 - -{{% notice title="Note" style="primary" icon="lightbulb" %}} - -Splunk Showイベントの詳細に記載されている `User Id` をメモしてください。この番号は、Kubernetesデータの検索とフィルタリングに使用する `sourcetype` に含まれます。これは共有環境であるため、他の参加者のデータに影響を与えないよう、提供された参加者番号のみを使用してください。 - -{{% /notice %}} - -![Splunk Show Instance Information](../../images/show_instance_information.png) - -## 2. Splunk Observability Cloud インスタンス - -Splunk Observability Cloudワークショップ組織にアクセスするためのメールも受け取っているはずです（スパムフォルダを確認する必要があるかもしれません）。メールを受け取っていない場合は、ワークショップのインストラクターにお知らせください。環境にアクセスするには、**Join Now** ボタンをクリックしてください。 - -![Splunk Observability Cloud Invitation](../../images/workshop_invitation.png) - -{{% notice title="Important" style="info" %}} -ワークショップ開始時刻前にイベントにアクセスした場合、インスタンスがまだ利用できない可能性があります。ご心配なく、ワークショップが始まると提供されます。 -{{% /notice %}} - -さらに、Splunk Observability Cloudワークショップ組織に招待されています。招待には環境へのリンクが含まれています。まだSplunk Observability Cloudアカウントをお持ちでない場合は、作成を求められます。すでにお持ちの場合は、インスタンスにログインすると、利用可能な組織にワークショップ組織が表示されます。 diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/1-getting-started/_index.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/1-getting-started/_index.md deleted file mode 100644 index aa320928b3..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/1-getting-started/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: はじめに -linkTitle: 1. はじめに -weight: 1 ---- - -この _**テクニカル**_ なSplunk Observability Cloud向けIngest Processor[^1] ワークショップでは、Splunk Enterprise CloudでIngest Processorを実際に操作する機会があります。 - -ワークショップモジュールを簡素化するために、事前設定されたSplunk Enterprise Cloudインスタンスが提供されます。 - -このインスタンスは、Ingest Processorパイプラインを作成するためのすべての要件が事前に設定されています。 - -このワークショップでは、Ingest Processorを使用して充実したログをメトリクスに変換し、それらのメトリクスをSplunk Observability Cloudに送信するメリットを紹介します。このテクニカルワークショップを終える頃には、Splunk Enterprise CloudにおけるIngest Processorの主要な機能と能力、およびIngest Processorパイプライン内の宛先としてSplunk Observability Cloudを使用する価値について十分に理解できるようになります。 - -事前設定された [Splunk Enterprise Cloud](./1-access-cloud-instances/) インスタンスにアクセスする方法については、以下の手順を参照してください。 - -![Splunk Ingest Processor Architecture](../images/IngestProcessor-architecture-diagram_release_updated2.png) - -[^1]: [**Ingest Processor**](https://docs.splunk.com/Documentation/SplunkCloud/9.3.2408/IngestProcessor/AboutIngestProcessorSolution) は、Splunk Cloud Platformデプロイメント内で動作するデータ処理機能です。Ingest Processorを使用して、データフローの設定、データ形式の制御、インデックス作成前の変換ルールの適用、および宛先へのルーティングを行います。 diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/2-ingest-processor-pipelines/_index.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/2-ingest-processor-pipelines/_index.md deleted file mode 100644 index bc3fd5164c..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/2-ingest-processor-pipelines/_index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Ingest Processor の仕組み -linkTitle: 2. Ingest Processor の仕組み -weight: 1 ---- - -###### システムアーキテクチャ - -Ingest Processorサービスの主要コンポーネントには、Ingest Processorサービスとデータ処理をサポートするSPL2パイプラインが含まれます。以下の図は、Ingest Processorソリューションのコンポーネントがどのように連携するかの概要を示しています： - -![Splunk Ingest Processor Architecture](../images/IngestProcessor-architecture-diagram_release_updated2.png) - -###### Ingest Processor サービス - -Ingest Processorサービスは、Splunkがホストするクラウドサービスです。これはデータ管理エクスペリエンスの一部であり、さまざまなデータ取り込みと処理のユースケースに対応するサービスセットです。 - -Ingest Processorサービスを使用して、以下のことができます： - -* 各Ingest Processorが受信したデータをどのように処理してルーティングするかを決定するSPL2パイプラインを作成して適用する -* 処理したいデータの種類を識別し、Ingest Processorがそのデータを個別のイベントに分割およびマージする方法を決定するソースタイプを定義する -* Ingest Processorが処理済みデータを送信する宛先への接続を作成する - -###### パイプライン - -パイプラインは、SPL2で記述されたデータ処理命令のセットです。パイプラインを作成する際、どのデータを処理するか、どのように処理するか、結果をどこに送信するかを指定する専用のSPL2ステートメントを記述します。パイプラインを適用すると、Ingest Processorはそれらの命令を使用して、Splunkフォワーダー、HTTPクライアント、ロギングエージェントなどのデータソースから受信したすべてのデータを処理します。 - -各パイプラインは、Ingest Processorが受信するすべてのデータのサブセットを選択して処理します。たとえば、受信データからソースタイプ `cisco_syslog` のイベントを選択し、Splunk Cloud Platformの指定されたインデックスに送信するパイプラインを作成できます。この選択されたデータのサブセットはパーティションと呼ばれます。詳細については、[Partitions](http://docs.splunk.com/Documentation/SplunkCloud/latest/IngestProcessor/Architecture#Partitions) を参照してください。 - -Ingest Processorソリューションは、`IngestProcessor` プロファイルの一部であるコマンドと関数のみをサポートしています。Ingest Processor用のパイプラインを記述するために使用できる特定のSPL2コマンドと関数の詳細については、[Ingest Processor pipeline syntax](http://docs.splunk.com/Documentation/SplunkCloud/latest/IngestProcessor/PipelinesOverview) を参照してください。`IngestProcessor` プロファイルが他のSPL2プロファイルと比較して異なるコマンドと関数をどのようにサポートするかの概要については、*SPL2 Search Reference* の以下のページを参照してください： - -* [Compatibility Quick Reference for SPL2 commands](http://docs.splunk.com/Documentation/SCS/current/SearchReference/CompatibilityQuickReferenceforSPL2commands) -* [Compatibility Quick Reference for SPL2 evaluation functions](http://docs.splunk.com/Documentation/SCS/current/SearchReference/CompatibilityQuickReferenceforSPL2evaluationfunctions) diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/1-login-to-splunk.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/1-login-to-splunk.md deleted file mode 100644 index 58185e709b..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/1-login-to-splunk.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Splunk Cloud へのログイン -linkTitle: 3.1 Splunk Cloud へのログイン -weight: 2 ---- - -このセクションでは、Kubernetes AuditログをSplunk Observability Cloudワークショップ組織に送信されるメトリクスに変換するIngest Pipelineを作成します。開始する前に、Splunk Showイベントの詳細に記載されているSplunk CloudおよびIngest Processor SCS Tenant環境にアクセスする必要があります。 - -{{% notice title="前提条件: Splunk Enterprise Cloudへのログイン" style="green" icon="running" %}} - -**1.** Splunk Showイベントの詳細に記載されている **Ingest Processor Cloud Stack** URLを開きます。 - -![Splunk Cloud Instance Details](../../images/show_instances_sec.png) - -**2.** Connection infoで **Stack URL** リンクをクリックして、Splunk Cloudスタックを開きます。 - -![Splunk Cloud Connection Details](../../images/sec_connection_details.png) - -**3.** `admin` ユーザー名とパスワードを使用してSplunk Cloudにログインします。 - -![Splunk Cloud Login](../../images/sec_login.png) - -**4.** ログイン後、プロンプトが表示されたら、利用規約に同意して **OK** をクリックします。 - -![Splunk Cloud Login](../../images/sec_terms.png) - -**5.** Splunk Showイベントの詳細に戻り、Ingest Processor SCS Tenantを選択します。 - -![Ingest Processor Connection Details](../../images/show_instances_scs.png) - -**6.** **Console URL** をクリックして **Ingest Processor SCS Tenant** にアクセスします。 - -{{% notice title="Note" style="primary" icon="lightbulb" %}} -**Single Sign-On (SSO)** -Splunk Data Managementサービス（'SCS Tenant'）とSplunk Cloud環境の間でSingle Sign-on (SSO) が設定されているため、すでにSplunk Cloudスタックにログインしている場合は、Splunk Data Managementサービスにも自動的にログインされます。認証情報の入力を求められた場合は、Splunk ShowイベントのSplunk Cloud Stackに記載されている認証情報を使用してください（'Splunk Cloud Stack' セクションに記載されています）。 -{{% /notice %}} - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/2-review-k8s-events.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/2-review-k8s-events.md deleted file mode 100644 index fce08b03d0..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/2-review-k8s-events.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Kubernetes Audit ログの確認 -linkTitle: 3.2 Kubernetes Audit ログの確認 -weight: 3 ---- - -このセクションでは、収集されているKubernetes Auditログを確認します。イベントが非常に充実していることがわかります。これにより、チャート作成が非効率になる可能性があります。これに対処するために、Ingest ProcessorでIngest Pipelineを作成し、これらのイベントをSplunk Observability Cloudに送信されるメトリクスに変換します。これにより、イベントをより効率的にチャート化し、Splunk Observability Cloudのリアルタイムストリーミングメトリクスを活用できるようになります。 - -{{% notice title="演習: Ingest Pipelineの作成" style="green" icon="running" %}} - -**1.** Splunk Showワークショップの詳細に記載されているURLを使用して、**Ingest Processor Cloud Stack** インスタンスを開きます。 - -**2.** **Apps** → **Search and Reporting** に移動します。 - -![Search and Reporting](../../images/search_and_reporting.png?width=20vw) - -**3.** 検索バーに、以下のSPL検索文字列を入力します。 - -{{% notice title="Note" style="primary" icon="lightbulb" %}} -`USER_ID` をSplunk Showインスタンス情報に記載されているUser IDに置き換えてください。 -{{% /notice %}} - -``` sh -### Replace USER_ID with the User ID provided in your Splunk Show instance information -index=main sourcetype="kube:apiserver:audit:USER_ID" -``` - -**4.** **Enter** を押すか、緑色の虫眼鏡をクリックして検索を実行します。 - -![Kubernetes Audit Log](../../images/k8s_audit_log.png) - -{{% notice title="Note" style="info" %}} -これで、環境のKubernetes Auditログが表示されるはずです。イベントがかなり充実していることに注目してください。利用可能なフィールドを探索し、どの情報がメトリクスとディメンションの良い候補になるか考え始めてください。自問してください：どのフィールドをチャート化したいか、それらのフィールドをどのようにフィルタリング、グループ化、または分割したいか？ -{{% /notice %}} - -{{%/ notice %}} diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/3-create-ingest-pipeline.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/3-create-ingest-pipeline.md deleted file mode 100644 index 4a8f7554c4..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/3-create-ingest-pipeline.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: Ingest Pipeline の作成 -linkTitle: 3.3 Ingest Pipeline の作成 -weight: 4 ---- - -このセクションでは、Kubernetes AuditログをSplunk Observability Cloudワークショップ組織に送信されるメトリクスに変換するIngest Pipelineを作成します。 - -{{% notice title="演習: Ingest Pipelineの作成" style="green" icon="running" %}} - -**1.** Splunk Showイベントで提供された接続情報を使用して、**Ingest Processor SCS Tenant** を開きます。 - -![Launch Splunk Cloud Platform](../../images/data_management_home.png?width=40vw) - -{{% notice title="Note" style="primary" icon="lightbulb" %}} - -**Ingest Processor SCS Tenant** を開いた際、ウェルカムページに移動した場合は、**Splunk Cloud Platform** の下にある **Launch** をクリックして、Ingest Pipelineを設定するData Managementページに移動してください。 - -![Launch Splunk Cloud Platform](../../images/launch_scp.png) - -{{% /notice %}} - -**2.** Splunk Data Managementコンソールから **Pipelines** → **New pipeline** → **Ingest Processor pipeline** を選択します。 - -![New Ingest Processor Pipeline](../../images/new_pipeline.png?width=40vw) - -**3.** Ingest Processor設定ページの **Get started** ステップで、**Blank Pipeline** を選択し、**Next** をクリックします。 - -![Blank Ingest Processor Pipeline](../../images/blank_pipeline.png?width=40vw) - -**4.** Ingest Processor設定ページの **Define your pipeline's partition** ステップで、**Partition by sourcetype** を選択します。**= equals** Operatorを選択し、値として `kube:apiserver:audit:USER_ID` を入力します（USER_IDを割り当てられたUser IDに置き換えてください）。**Apply** をクリックします。 - -![Add Partition](../../images/add_partition.png?width=40vw) - -**5.** **Next** をクリックします。 - -**6.** Ingest Processor設定ページの **Add sample data** ステップで、**Capture new snapshot** を選択します。Snapshot nameに `k8s_audit_USER_ID` と入力し（USER_IDを割り当てられたUser IDに置き換えてください）、**Capture** をクリックします。 - -![Capture Snapshot](../../images/capture_snapshot.png?width=40vw) - -**7.** 新しく作成したスナップショット（`k8s_audit_USER_ID`）が選択されていることを確認し、**Next** をクリックします。 - -![Configure Snapshot Sourcetype](../../images/capture_snapshot_sourcetype.png?width=20vw) - -**8.** Ingest Processor設定ページの **Select a metrics destination** ステップで、**show_o11y_org** を選択します。**Next** をクリックします。 - -![Metrics Destination](../../images/metrics_destination.png?width=20vw) - -**9.** Ingest Processor設定ページの **Select a data destination** ステップで、**splunk_indexer** を選択します。**Specify how you want your events to be routed to an index** の下で、**Default** を選択します。**Done** をクリックします。 - -![Event Routing](../../images/event_routing.png?width=20vw) - -**10.** **Pipeline search field** で、デフォルトの検索を以下に置き換えます。 - -{{% notice title="Note" style="primary" icon="lightbulb" %}} -**メトリクス名の `UNIQUE_FIELD` を、Observability Cloud でメトリクスを識別するために使用する一意の値（イニシャルなど）に置き換えてください。** -{{% /notice %}} - -```text -/*A valid SPL2 statement for a pipeline must start with "$pipeline", and include "from $source" and "into $destination".*/ -/* Import logs_to_metrics */ -import logs_to_metrics from /splunk/ingest/commands -$pipeline = -| from $source -| thru [ - //define the metric name, type, and value for the Kubernetes Events - // - // REPLACE UNIQUE_FIELD WITH YOUR INITIALS - // - | logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time - | into $metrics_destination - ] -| eval index = "kube_logs" -| into $destination; -``` - -{{% notice title="SPL2が初めてですか？" style="info" icon="lightbulb" %}} - -SPL2クエリが行っていることの内訳は以下の通りです： - -* まず、Kubernetesイベントをメトリクスに変換するために使用される組み込みの `logs_to_metrics` コマンドをインポートしています。 -* 右側に表示されている、`kube:apiserver:audit` sourcetypeからの任意のイベントであるソースデータを使用しています。 -* 次に、`thru` コマンドを使用して、ソースデータセットを次のコマンド（この場合は `logs_to_metrics`）に書き込みます。 -* メトリクス名（`k8s_audit`）、メトリクスタイプ（`counter`）、値、タイムスタンプがすべてメトリクスに提供されていることがわかります。イベントが発生した回数をカウントしたいため、このメトリクスには値として1を使用しています。 -* 次に、into `$metrics_destintation` コマンドを使用してメトリクスの宛先を選択します。これはSplunk Observability Cloud組織です。 -* 最後に、生のログイベントを別の宛先（この場合は別のインデックス）に送信できるため、アクセスが必要になった場合に保持されます。 - -{{% /notice %}} - -**11.** 右上隅の **Preview** ボタン ![Preview Button](../../images/preview.png?height=20px&classes=inline) をクリックするか、CTRL+Enter（MacではCMD+Enter）を押します。**Previewing $pipeline** ドロップダウンから **$metrics_destination** を選択します。Splunk Observability Cloudに送信されるメトリクスのプレビューが表示されていることを確認します。 - -![Preview Pipeline](../../images/preview_pipeline.png?width=40vw) - -**12.** 右上隅の **Save pipeline** ボタン ![Save Pipeline Button](../../images/save_pipeline_btn.png?height=20px&classes=inline) をクリックします。パイプライン名に `Kubernetes Audit Logs2Metrics USER_ID` と入力し、**Save** をクリックします。 - -![Save Pipeline Dialog](../../images/save_pipeline_dialog.png?width=40vw) - -**13.** 保存をクリックすると、新しく作成したパイプラインを適用するかどうか尋ねられます。**Yes, apply** をクリックします。 - -![Apply Pipeline Dialog](../../images/apply_pipeline_dialog.png?width=40vw) - -{{% notice title="Note" style="info" %}} -Ingest Pipelineは現在Splunk Observability Cloudにメトリクスを送信しているはずです。次のセクションで再び使用するため、このタブを開いたままにしておいてください。 - -次のステップでは、Splunk Observability Cloudで作成したメトリクスを表示して、パイプラインが動作していることを確認します。 -{{% /notice %}} - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/4-confirm-metrics.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/4-confirm-metrics.md deleted file mode 100644 index 624e019bb7..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/4-confirm-metrics.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Observability Cloud でのメトリクス確認 -linkTitle: 3.4 Observability Cloud でのメトリクス確認 -weight: 5 ---- - -Kubernetes Auditログをメトリクスに変換してSplunk Observability Cloudに送信するIngest Pipelineが設定されたので、メトリクスが利用可能になっているはずです。メトリクスが収集されていることを確認するには、以下の手順を完了してください： - -{{% notice title="演習: Splunk Observability Cloudでのメトリクス確認" style="green" icon="running" %}} - -**1.** ワークショップ用に招待された **Splunk Observability Cloud** 組織にログインします。右上隅の **+** アイコン → **Chart** をクリックして、新しいチャートを作成します。 - -![Create New Chart](../../images/create_new_chart.png?width=40vw) - -**2.** 新しく作成したチャートの **Plot Editor** で、**Ingest Pipeline** の設定時に使用したメトリクス名を入力します。 - -![Review Metric](../../images/review_metric.png?width=40vw) - -{{% notice title="Info" style="info" %}} -Ingest Pipelineで作成したメトリクスが表示されるはずです。次のセクションで再び使用するため、このタブを開いたままにしておいてください。 - -次のステップでは、Ingest Pipelineを更新してメトリクスにディメンションを追加し、アラートとトラブルシューティングのための追加コンテキストを得られるようにします。 -{{% /notice %}} - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/_index.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/_index.md deleted file mode 100644 index da15eebf9c..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/3-create-an-ingest-pipeline/_index.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Ingest Pipeline の作成 -linkTitle: 3. Ingest Pipeline の作成 -weight: 1 ---- - -## シナリオ概要 - -このシナリオでは、組織のSplunk Enterprise Cloud環境の管理を担当するSplunk管理者の役割を担います。最近、社内のアプリケーションチームと協力して、重要なマイクロサービスアプリケーションを監視するために、OpenTelemetryを使用してSplunk APMとInfrastructure MonitoringでKubernetes環境を計装しました。 - -Kubernetes環境からのログも収集され、Splunk Enterprise Cloudに送信されています。これらのログには以下が含まれます： - -* Podログ（アプリケーションログ） -* Kubernetes Events -* Kubernetes Clusterログ - * Control Plane Nodeログ - * Worker Nodeログ - * Auditログ - -Splunk管理者として、収集しているデータが最適化されていることを確認し、可能な限り効率的な方法で分析できるようにしたいと考えています。このアプローチを採用することで、トラブルシューティングが加速され、ライセンスの効率的な利用が確保されます。 - -これを達成する1つの方法は、Ingest Processorを使用して充実したログをメトリクスに変換し、それらのメトリクスの宛先としてSplunk Observability Cloudを使用することです。これにより、ログの収集がより効率的になるだけでなく、新しく作成されたメトリクスをSplunk Observabilityで使用できるようになり、Splunk APMデータ（トレース）やSplunk Infrastructure Monitoringデータと相関させて、追加のトラブルシューティングコンテキストを提供できます。Splunk Observability Cloudはストリーミングメトリクスパイプラインを使用しているため、メトリクスに対してリアルタイムでアラートを設定でき、問題の特定を高速化できます。さらに、Metrics Pipeline Management機能を使用して、集約、不要なフィールドの削除、重要度の低いまたは不要なメトリクスのアーカイブによってデータをさらに最適化できます。 - -次のステップでは、Kubernetes AuditログをObservability Cloudに送信されるメトリクスに変換するIngest Processor Pipelineを作成します。 diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/1-update-ingest-pipeline.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/1-update-ingest-pipeline.md deleted file mode 100644 index ed9f654b16..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/1-update-ingest-pipeline.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Ingest Pipeline の更新 -linkTitle: 4.1 Ingest Pipeline の更新 -weight: 2 ---- - -{{% notice title="演習: Ingest Pipelineの更新" style="green" icon="running" %}} - -**1.** 前のステップで作成したIngest Pipelineの設定ページに戻ります。 - -![Ingest Pipeline](../../images/ingest_pipeline.png?width=40vw) - -**2.** 生のKubernetes Auditログからメトリクスにディメンションを追加するには、パイプライン用に作成したSPL2クエリの `logs_to_metrics` 部分を以下に置き換えて更新します： - -{{% notice title="Note" style="primary" icon="lightbulb" %}} -**メトリクス名フィールド（`name="k8s_audit_UNIQUE_FIELD"`）を、元のパイプラインで指定した名前に更新してください。** -{{% /notice %}} - -```text -| logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time dimensions={"level": _raw.level, "response_status": _raw.responseStatus.code, "namespace": _raw.objectRef.namespace, "resource": _raw.objectRef.resource, "user": _raw.user.username, "action": _raw.verb} -``` - -{{% notice title="Note" style="info" icon="info" %}} -SPL2クエリの `dimensions` フィールドを使用して、生のイベントからのディメンションをSplunk Observability Cloudに送信されるメトリクスに追加できます。この場合、イベントのレスポンスステータス、名前空間、Kubernetesリソース、ユーザー、およびverb（実行されたアクション）を追加しています。これらのディメンションを使用して、より詳細なダッシュボードとアラートを作成できます。 - -Splunk Observability Cloudでコンテキスト伝播と関連コンテンツを活用できるように、サービス全体で共通のタグを追加することを検討してください。 -{{% /notice %}} - -更新されたパイプラインは以下のようになります： - -```text -/*A valid SPL2 statement for a pipeline must start with "$pipeline", and include "from $source" and "into $destination".*/ -/* Import logs_to_metrics */ -import logs_to_metrics from /splunk/ingest/commands -$pipeline = -| from $source -| thru [ - //define the metric name, type, and value for the Kubernetes Events - // - // REPLACE UNIQUE_FIELD WITH YOUR INITIALS - // - | logs_to_metrics name="k8s_audit_UNIQUE_FIELD" metrictype="counter" value=1 time=_time dimensions={"level": _raw.level, "response_status": _raw.responseStatus.code, "namespace": _raw.objectRef.namespace, "resource": _raw.objectRef.resource, "user": _raw.user.username, "action": _raw.verb} - | into $metrics_destination - ] -| eval index = "kube_logs" -| into $destination; -``` - -**3.** 右上隅の **Preview** ボタン ![Preview Button](../../images/preview.png?height=20px&classes=inline) をクリックするか、CTRL+Enter（MacではCMD+Enter）を押します。**Previewing $pipeline** ドロップダウンから **$metrics_destination** を選択します。Splunk Observability Cloudに送信されるメトリクスのプレビューが表示されていることを確認します。 - -![Ingest Pipeline Dimensions](../../images/ingest_pipeline_dimensions.png?width=40vw) - -**4.** プレビューテーブルのdimensions列にディメンションが表示されていることを確認します。テーブルをクリックすると、dimensionsオブジェクト全体を表示できます。 - -![Ingest Pipeline Dimensions Review](../../images/ingest_pipeline_dimensions_field.png?width=40vw) - -**5.** 右上隅の **Save pipeline** ボタン ![Save Pipeline Button](../../images/save_pipeline_btn.png?height=20px&classes=inline) をクリックします。「You are editing an active pipeline」モーダルで **Save** をクリックします。 - -![Save Updated Pipeline](../../images/save_updated_pipeline.png?width=30vw) - -{{% notice title="Note" style="info" %}} -このパイプラインはすでにアクティブであるため、行った変更はすぐに有効になります。追加したディメンションを使用して、メトリクスは複数のメトリクス時系列に分割されるはずです。 - -次のステップでは、Kubernetes Auditイベントからの異なるディメンションを使用して可視化を作成します。 -{{% /notice %}} - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/2-create-dashboard.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/2-create-dashboard.md deleted file mode 100644 index 200cdcea16..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/2-create-dashboard.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -title: Kubernetes Audit イベントメトリクスの可視化 -linkTitle: 4.2 Kubernetes Audit イベントメトリクスの可視化 -weight: 3 ---- - -メトリクスにディメンションが追加されたので、イベントの `verb` ディメンションを使用して、さまざまなKubernetesアクションの健全性を示すチャートを作成します。 - -{{% notice title="演習: Kubernetes Auditイベントメトリクスの可視化" style="green" icon="running" %}} - -**1.** 前のセクションで作成したチャートを閉じた場合は、右上隅の **+** アイコン → **Chart** をクリックして、新しいチャートを作成します。 - -![Create New Chart](../../images/create_new_chart.png?width=40vw) - -**2.** 新しく作成したチャートの **Plot Editor** で、メトリクス名フィールドに `k8s_audit*` と入力します。ここでワイルドカードを使用して、取り込まれているすべてのメトリクスを表示できるようにします。 - -![Review Metric](../../images/review_metric.png?width=40vw) - -**3.** 1つから多くのメトリクスへの変化に注目してください。これは、パイプラインを更新してディメンションを含めた時点からの変化です。このメトリクスが利用可能になったので、アクションにエラーが関連付けられているかどうかを示すようにチャートを調整しましょう。 - -![Metric Timeseries](../../images/metric_timeseries.png?width=40vw) - -まず、**response_status** フィールドで利用可能なHTTPレスポンスコードを使用して、成功しなかったKubernetesイベントのみにフィルタリングします。レスポンスコードが **409**（競合を示す、たとえばすでに存在するリソースを作成しようとした場合）または **503**（リクエストに対してAPIが応答しなかった場合）のイベントのみが必要です。 - -**4.** チャートのプロットエディタで **Add filter** をクリックし、フィールドに **response_status** を使用し、値として **409.0** と **503.0** を選択します。 - -次に、**resource**、**action**、および **response status** でグループ化されたイベントの総数を計算する関数をチャートに追加します。これにより、どのアクションと関連するリソースにエラーがあったかを正確に確認できます。これで、成功しなかったKubernetesイベントのみを見ています。 - -**5.** **Add analytics** → **Sum** → **Sum:Aggregation** をクリックし、**Group by** フィールドに **resource**、**action**、および **response_status** を追加します。 - -![Add Metric Filters](../../images/add_metric_filters.png?width=40vw) - -**6.** 上部のボタンにあるチャートタイプを使用して、チャートを **heatmap** に変更します。**Plot editor** の隣にある **Chart options** をクリックします。**Group by** セクションで **response_status** を選択し、次に **action** を選択します。**Color threshold** を **Auto** から **Fixed** に変更します。青い **+ button** をクリックして、別のしきい値を追加します。**Down arrow を Yellow** に、**Middle を orange** に変更します。**Up arrow は red のまま**にします。**middle threshold に 5** を、**upper threshold に 20** を入力します。 - -![Configure Thresholds](../../images/configure_thresholds.png?width=40vw) - -**7.** チャートの右上隅にある青い **Save as...** ![Preview Button](../../images/save_as_btn.png?height=20px&classes=inline) ボタンをクリックします。チャートの名前を入力します（例：Kubernetes Audit Logs - Conflicts and Failures）。 - -![Chart Name](../../images/chart_name.png) - -**8.** **Choose a dashboard** で **New dashboard** を選択します。 - -![New Dashboard](../../images/new_dashboard.png) - -**9.** 後で簡単に見つけられるように、イニシャルを含むダッシュボード名を入力します。**Save** をクリックします。 - -![New Dashboard Name](../../images/dashboard_name.png) - -**10.** 作成した新しいダッシュボードが選択されていることを確認し、**Ok** をクリックします。 - -![Save New Dashboard](../../images/save_new_dashboard.png) - -これで、作成したチャートを含む新しいKubernetes Audit Eventsダッシュボードに移動するはずです。Kubernetesクラスターで実行されているアプリケーションからのアプリケーションエラーとレスポンスタイム、またはpod phase、podメモリ使用率などの他のKubernetesメトリクスなど、環境内の他のメトリクスから新しいチャートを追加できます。これにより、クラスターイベントからアプリケーションの健全性まで、Kubernetes環境の相関ビューが得られます。 - -![Audit Dashboard](../../images/audit_dashboard.png?width=40vw) - -チャートの可視化ボックスの右上にある3つのドット `...` を使用して、このチャートのコピーを作成します。 - -![Copy chart button](../../images/copy_chart_button.png?width=40vw) - -UIの右上にある `+` アイコンを使用して、作業中の同じダッシュボードに貼り付けます。 - -![Paste chart into dashboard](../../images/paste_chart_into_dashboard.png?width=40vw) - -貼り付けたチャートをクリックして、可視化を **Column** チャートに変更します。 - -![Change to column chart visualization](../../images/change_to_column_chart_visualization.png?width=40vw) - -SUMを `resource`、`namespace` のみに変更します（フィルターは問題のあるコードのみにフィルタリングします）。 - -![Group chart by resource and namespace](../../images/group_chart_by_resource_and_namespace.png?width=40vw) - -Chart optionsでタイトルを `Kubernetes Audit Logs - Conflicts by Namespace` に変更します。 - -![Change chart title](../../images/change_chart_title.png?width=40vw) - -**Save** をクリックして閉じます。 - -![Save and close chart](../../images/save_and_close_chart.png) - -{{% /notice %}} - -{{% notice title="演習: Kubernetes Auditログに基づくディテクターの作成" style="green" icon="running" %}} - -Conflicts by Namespaceチャートで、小さなベルアイコンをクリックし、New detector from chartを選択します。 - -![Bell icon to create detector](../../images/bell_icon_create_detector.png?width=40vw) - -名前を選択し、**Create alert rule** をクリックします。 - -![Enter name for alert rule](../../images/enter_name_alert_rule.png?width=40vw) - -Alert conditionで **Static Threshold** をクリックし、Proceed to **Alert Settings** をクリックします。 - -![Select static threshold condition](../../images/select_static_threshold_condition.png?width=40vw) - -**Threshold** に `20` を入力します。 - -![Enter threshold value](../../images/enter_threshold_value.png?width=40vw) - -このアラートの受信者は選択しないので、**Activate** をクリックし、**Activate Alert Rule** と **Save** を選択します。 - -![Activate alert rule and save](../../images/activate_alert_rule_and_save.png?width=40vw) - -右上の **Save** を最後にもう一度クリックして、ディテクターを保存します。 - -![Final save for detector](../../images/final_save_detector.png?width=40vw) - -ダッシュボードに戻ると、チャートに関連付けられたディテクターが、チャート上の点灯したベルアイコンで示されているのが確認できます。 - -![Detector bell icon on chart](../../images/detector_bell_icon_on_chart.png?width=40vw) - -{{% /notice %}} - -{{% notice title="演習: Splunk Cloud - Dashboard Studioで時系列データを可視化する" style="green" icon="running" %}} - -時系列メトリクスがSplunk Observability Cloudデータストアに取り込まれたので、Splunk Cloudでこれらの時系列メトリクスを簡単に可視化できます！ - -Splunk Cloudインスタンスで **Dashboards** に移動し、**Create New Dashboard** を選択します。 - -![Create new dashboard in Splunk Cloud](../../images/create_new_dashboard_splunk_cloud.png) - -ダッシュボードのタイトル、権限、**Dashboard Studio** を選択し、任意のLayout Modeを選択します。 -**Create** をクリックします。 - -![Dashboard title and layout options](../../images/dashboard_title_layout_options.png) - -Dashboard Studioでチャートアイコンをクリックし、**Column** を選択します。 - -![Select column chart in Dashboard Studio](../../images/select_column_chart_dashboard_studio.png) - -**Select data source** で **Create splunk observability cloud metric search** を選択します。 - -![Choose observability cloud metric search as data source](../../images/choose_observability_cloud_metric_search.png) - -新しいデータソースの名前を選択し、**Search for metric or metadata** の下にある **Content Import** リンクをクリックします。 - -チャートのURLをコピーして **Content URL** フィールドに貼り付けます。 - -![Paste chart URL and import](../../images/paste_chart_url_and_import.png?width=40vw) - -**Import** をクリックします。 - -![Chart imported to dashboard](../../images/chart_imported_to_dashboard.png) - -![Chart visible in dashboard](../../images/chart_visible_in_dashboard.png) - -チャートのサイズをダッシュボードに合わせて調整します。 - -![Resize chart in dashboard](../../images/resize_chart_in_dashboard.png?width=40vw) - -チャートの **Configuration** の右側にある **Interactions** を展開し、**Add Interaction** をクリックします。 - -![Expand interactions and add interaction](../../images/expand_interactions_add_interaction.png) - -Splunk ObservabilityのダッシュボードからURLをコピーします。 - -![Apply interaction settings](../../images/apply_interaction_settings.png?width=40vw) - -**On click** で **Link to custom URL** を選択し、ソースデータに簡単に戻れるようにSplunk Observability CloudのダッシュボードのURLを追加します。 -また、使いやすいナビゲーションのために **Open in new tab** を選択します。 - -![Interaction added](../../images/interaction_added.png) - -右上の **Save** をクリックしてダッシュボードを保存します。 - -![Save dashboard in Splunk Cloud](../../images/save_dashboard_splunk_cloud.png) - -チャートのColumnまたは名前をハイライトしてクリックします。 - -![Click column or name in chart](../../images/click_column_or_name_in_chart.png) - -Splunk Observabilityに戻ることが通知されます。**Continue** をクリックします。 - -![Continue navigation to Splunk Observability](../../images/continue_navigation_splunk_observability.png) - -これで、Splunk Cloudから対応するSplunk Observabilityダッシュボードに戻りました。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/_index.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/_index.md deleted file mode 100644 index 23c16cff6b..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/_index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: パイプラインの更新とメトリクスの可視化 -linkTitle: 4. パイプラインの更新とメトリクスの可視化 -weight: 1 ---- - -## コンテキストの重要性 - -前のセクションでは、生のKubernetes Auditログを確認し、それらをメトリクスに変換してSplunk Observability Cloudに送信するIngest Processor Pipelineを作成しました。 - -このパイプラインが定義されたことで、Splunk Observability Cloudで新しいメトリクスを収集しています。これは素晴らしいスタートですが、特定の期間におけるKubernetes Auditイベントの総数を示す単一のメトリクスしか表示されません。イベントタイプ、ユーザー、レスポンスステータスなどでメトリクスを分割できるようにディメンションを追加すると、はるかに価値が高くなります。 - -このセクションでは、Ingest Processor Pipelineを更新して、収集されているメトリクスにKubernetes Auditログからの追加ディメンションを含めます。これにより、Auditログの特定の側面をさらにフィルタリング、グループ化、可視化、アラート設定できるようになります。メトリクスを更新した後、ログに関連付けられたさまざまなタイプのアクションのステータスを示す新しいダッシュボードを作成します。 diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/5-workshop-conclusion/_index.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/5-workshop-conclusion/_index.md deleted file mode 100644 index e00c45d222..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/5-workshop-conclusion/_index.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: まとめ -linkTitle: 5. まとめ -weight: 1 ---- - -このワークショップでは、**Splunk Ingest Pipelines** を使用して詳細なログイベントを実用的なメトリクスに変換することで、Kubernetesログ管理を最適化するプロセス全体を体験しました。まず、Kubernetes Auditログをメトリクスに効率的に変換するパイプラインを定義し、重要な情報を保持しながらデータ量を大幅に削減しました。次に、生のログイベントが長期保持とより深い分析のためにS3に安全に保存されることを確認しました。 - -![Kubernetes Audit Event](../images/audit_event.png?width=40vw) - -次に、生のイベントから主要なディメンションを追加してこれらのメトリクスを強化する方法を示し、特定のアクションとリソースにドリルダウンできるようにしました。エラーに焦点を当てるためにメトリクスをフィルタリングし、リソースとアクションごとに分類するチャートを作成しました。これにより、問題が発生している場所をリアルタイムで正確に特定できるようになりました。 - -![Ingest Pipeline](../images/ingest_pipeline_dimensions.png?width=40vw) - -**Splunk Observability Cloud** のリアルタイムアーキテクチャにより、これらのメトリクスは問題が検出された瞬間にアラートをトリガーでき、平均検出時間（MTTD）を大幅に短縮できます。さらに、このチャートを新規または既存のダッシュボードに簡単に保存して、重要なメトリクスの継続的な可視性と監視を確保する方法を示しました。 - -![Audit Dashboard](../images/audit_dashboard.png?width=40vw) - -このアプローチの価値は明確です：**Ingest Processor** を使用してログをメトリクスに変換することで、データ処理を効率化し、ストレージコストを削減するだけでなく、**Splunk Observability Cloud** を使用してリアルタイムで問題を監視し対応する能力も得られます。これにより、コンプライアンスやより深い分析のために元のログを保持してアクセスする能力を維持しながら、問題解決の高速化、システム信頼性の向上、およびより効率的なリソース利用が実現します。 - -

Happy Splunking!

- -![Dancing Buttercup](../images/Splunk-dancing-buttercup-GIF-103.gif?width=30vw) diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/_index.md b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/_index.md deleted file mode 100644 index 1bedf9d4a8..0000000000 --- a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/_index.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Ingest Processor for Observability Cloud -linkTitle: Ingest Processor for Observability Cloud -weight: 11 -archetype: chapter -authors: ["Tim Hard"] -description: Splunk Ingest Processor を使用してログをメトリクスに変換し、オブザーバビリティコストを最適化し、MTTD を改善する方法を、Splunk Observability Cloud でのハンズオン演習を通じて学びます。 ---- - -インフラストラクチャとアプリケーション環境がますます複雑になるにつれて、それらが生成するデータ量は大幅に増加し続けています。このデータ量と種類の増加により、実用的なインサイトを得ることが困難になり、問題の特定やトラブルシューティングの効率に影響を与える可能性があります。さらに、このデータを保存してアクセスするコストは急上昇する可能性があります。多くのデータソース、特にログとイベントは、システム運用への重要な可視性を提供します。しかし、ほとんどの場合、効果的な監視とアラートに実際に必要なのは、これらの膨大なログからのわずかな詳細情報のみです。 - -**一般的な課題:** - -* インフラストラクチャとアプリケーション環境の複雑性の増加 -* これらの環境から生成されるデータ量の大幅な増加 -* 大量のデータから実用的なインサイトを得ることの困難さ -* 膨大なデータの保存とアクセスに関連する高いコスト -* ログとイベントは重要な可視性を提供するが、多くの場合、必要な詳細情報はわずか - -これらの課題に対処するために、Splunk Ingest Processorは強力な新機能を提供します：ログイベントをメトリクスに変換する機能です。メトリクスは保存と処理がより効率的であり、問題の迅速な特定を可能にし、それによって平均検出時間（MTTD）を短縮します。元のログやイベントを保持する必要がある場合は、S3などの安価なストレージソリューションに保存できるため、データ取り込みと検索に必要な計算の全体的なコストを削減できます。 - -**ソリューション:** - -* 可能な場合はログイベントをメトリクスに変換する -* 必要に応じて元のログまたはイベントを安価なストレージソリューションに保持する -* 保持されたログへのアクセスと分析にフェデレーテッド検索を活用する - -**成果:** - -* メトリクスはより効率的に保存および処理される -* 問題のより迅速な特定により、平均検出時間（MTTD）を短縮 -* データ取り込みと計算の全体的なコストの削減 -* 監視効率とリソース最適化の向上 -* 運用コストを削減しながらシステム運用への高い可視性を維持 - -このワークショップでは、Ingest ProcessorとSplunk Observability Cloudを使用して、上記で説明した課題にどのように対処できるかを実際に体験する機会があります。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです： - -* このページの右上にある左右の矢印（**<** | **>**） -* キーボードの左（◀️）および右（▶️）カーソルキー - {{% /notice %}} - \ No newline at end of file diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/IngestProcessor-architecture-diagram_release_updated2.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/IngestProcessor-architecture-diagram_release_updated2.png deleted file mode 100644 index 07ddeb99cf..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/IngestProcessor-architecture-diagram_release_updated2.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/Splunk-dancing-buttercup-GIF-103.gif b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/Splunk-dancing-buttercup-GIF-103.gif deleted file mode 100644 index 2be04726f2..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/Splunk-dancing-buttercup-GIF-103.gif and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/activate_alert_rule_and_save.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/activate_alert_rule_and_save.png deleted file mode 100644 index 081e94d503..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/activate_alert_rule_and_save.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/add_metric_filters.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/add_metric_filters.png deleted file mode 100644 index cad353a9d3..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/add_metric_filters.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/add_partition.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/add_partition.png deleted file mode 100644 index 8b541ef091..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/add_partition.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/apply_interaction_settings.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/apply_interaction_settings.png deleted file mode 100644 index 5866610cc7..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/apply_interaction_settings.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/apply_pipeline_dialog.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/apply_pipeline_dialog.png deleted file mode 100644 index b4687918cb..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/apply_pipeline_dialog.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/audit_dashboard.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/audit_dashboard.png deleted file mode 100644 index ad3e49e127..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/audit_dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/audit_event.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/audit_event.png deleted file mode 100644 index a9aae7e2e3..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/audit_event.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/bell_icon_create_detector.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/bell_icon_create_detector.png deleted file mode 100644 index 92c1366908..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/bell_icon_create_detector.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/blank_pipeline.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/blank_pipeline.png deleted file mode 100644 index ba03e7c426..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/blank_pipeline.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/capture_snapshot.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/capture_snapshot.png deleted file mode 100644 index 1ca01a0b28..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/capture_snapshot.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/capture_snapshot_sourcetype.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/capture_snapshot_sourcetype.png deleted file mode 100644 index 4d81da4ccf..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/capture_snapshot_sourcetype.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/change_chart_title.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/change_chart_title.png deleted file mode 100644 index 4b4fba22b6..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/change_chart_title.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/change_to_column_chart_visualization.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/change_to_column_chart_visualization.png deleted file mode 100644 index 8d4e8f0d99..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/change_to_column_chart_visualization.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_imported_to_dashboard.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_imported_to_dashboard.png deleted file mode 100644 index e4f4273c62..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_imported_to_dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_name.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_name.png deleted file mode 100644 index c495216a8c..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_name.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_visible_in_dashboard.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_visible_in_dashboard.png deleted file mode 100644 index 9bfae237f0..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/chart_visible_in_dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/choose_observability_cloud_metric_search.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/choose_observability_cloud_metric_search.png deleted file mode 100644 index 5114af8186..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/choose_observability_cloud_metric_search.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/click_column_or_name_in_chart.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/click_column_or_name_in_chart.png deleted file mode 100644 index 795cc2a951..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/click_column_or_name_in_chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/configure_thresholds.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/configure_thresholds.png deleted file mode 100644 index 50e509b496..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/configure_thresholds.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/continue_navigation_splunk_observability.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/continue_navigation_splunk_observability.png deleted file mode 100644 index c1c955d131..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/continue_navigation_splunk_observability.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/copy_chart_button.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/copy_chart_button.png deleted file mode 100644 index 1767ae137a..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/copy_chart_button.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/create_new_chart.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/create_new_chart.png deleted file mode 100644 index e557f9754b..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/create_new_chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/create_new_dashboard_splunk_cloud.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/create_new_dashboard_splunk_cloud.png deleted file mode 100644 index 465df04e32..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/create_new_dashboard_splunk_cloud.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/dashboard_name.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/dashboard_name.png deleted file mode 100644 index 096fb724ca..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/dashboard_name.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/dashboard_title_layout_options.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/dashboard_title_layout_options.png deleted file mode 100644 index 020379925a..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/dashboard_title_layout_options.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/data_management_home.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/data_management_home.png deleted file mode 100644 index 7e96617129..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/data_management_home.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/detector_bell_icon_on_chart.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/detector_bell_icon_on_chart.png deleted file mode 100644 index 356216c65d..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/detector_bell_icon_on_chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/enter_name_alert_rule.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/enter_name_alert_rule.png deleted file mode 100644 index 1d08359782..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/enter_name_alert_rule.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/enter_threshold_value.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/enter_threshold_value.png deleted file mode 100644 index f771f23bbf..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/enter_threshold_value.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/event_routing.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/event_routing.png deleted file mode 100644 index 6692515a13..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/event_routing.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/expand_interactions_add_interaction.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/expand_interactions_add_interaction.png deleted file mode 100644 index a0319f4c5f..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/expand_interactions_add_interaction.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/final_save_detector.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/final_save_detector.png deleted file mode 100644 index 391e578200..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/final_save_detector.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/group_chart_by_resource_and_namespace.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/group_chart_by_resource_and_namespace.png deleted file mode 100644 index e8df6ff2e5..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/group_chart_by_resource_and_namespace.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline.png deleted file mode 100644 index b33dc7a4b8..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline_dimensions.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline_dimensions.png deleted file mode 100644 index c8ffc3cf27..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline_dimensions.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline_dimensions_field.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline_dimensions_field.png deleted file mode 100644 index f8c6711143..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/ingest_pipeline_dimensions_field.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/interaction_added.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/interaction_added.png deleted file mode 100644 index 23d7f60eb5..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/interaction_added.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/k8s_audit_log.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/k8s_audit_log.png deleted file mode 100644 index 89e6a4802a..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/k8s_audit_log.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/launch_scp.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/launch_scp.png deleted file mode 100644 index 53f44279e5..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/launch_scp.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/metric_timeseries.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/metric_timeseries.png deleted file mode 100644 index 6699b3033d..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/metric_timeseries.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/metrics_destination.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/metrics_destination.png deleted file mode 100644 index d95eac2880..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/metrics_destination.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/new_dashboard.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/new_dashboard.png deleted file mode 100644 index 2bc2feb3c2..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/new_dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/new_pipeline.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/new_pipeline.png deleted file mode 100644 index 2366b93c98..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/new_pipeline.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/paste_chart_into_dashboard.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/paste_chart_into_dashboard.png deleted file mode 100644 index 9e967c639c..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/paste_chart_into_dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/paste_chart_url_and_import.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/paste_chart_url_and_import.png deleted file mode 100644 index d7c6b85fa0..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/paste_chart_url_and_import.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/preview.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/preview.png deleted file mode 100644 index 040e8d24d8..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/preview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/preview_pipeline.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/preview_pipeline.png deleted file mode 100644 index a55455eb27..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/preview_pipeline.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/resize_chart_in_dashboard.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/resize_chart_in_dashboard.png deleted file mode 100644 index 965a98ed2d..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/resize_chart_in_dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/review_metric.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/review_metric.png deleted file mode 100644 index 1afced4ec3..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/review_metric.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_and_close_chart.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_and_close_chart.png deleted file mode 100644 index b0568f195b..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_and_close_chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_as_btn.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_as_btn.png deleted file mode 100644 index 8a2271745b..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_as_btn.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_dashboard_splunk_cloud.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_dashboard_splunk_cloud.png deleted file mode 100644 index 777066ef8b..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_dashboard_splunk_cloud.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_new_dashboard.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_new_dashboard.png deleted file mode 100644 index fe326ea17f..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_new_dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_pipeline_btn.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_pipeline_btn.png deleted file mode 100644 index 09b16833b1..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_pipeline_btn.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_pipeline_dialog.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_pipeline_dialog.png deleted file mode 100644 index 97d7334971..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_pipeline_dialog.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_updated_pipeline.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_updated_pipeline.png deleted file mode 100644 index d2c24c807c..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/save_updated_pipeline.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/search_and_reporting.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/search_and_reporting.png deleted file mode 100644 index 0eaddc3735..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/search_and_reporting.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_connection_details.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_connection_details.png deleted file mode 100644 index 7d57b81734..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_connection_details.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_login.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_login.png deleted file mode 100644 index f66eedb678..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_login.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_terms.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_terms.png deleted file mode 100644 index 6267ff67da..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/sec_terms.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/select_column_chart_dashboard_studio.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/select_column_chart_dashboard_studio.png deleted file mode 100644 index 08dd983ee7..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/select_column_chart_dashboard_studio.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/select_static_threshold_condition.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/select_static_threshold_condition.png deleted file mode 100644 index ae31268b08..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/select_static_threshold_condition.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instance_information.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instance_information.png deleted file mode 100644 index 322eafc981..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instance_information.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instances_scs.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instances_scs.png deleted file mode 100644 index bac2547334..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instances_scs.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instances_sec.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instances_sec.png deleted file mode 100644 index 5462617969..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/show_instances_sec.png and /dev/null differ diff --git a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/workshop_invitation.png b/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/workshop_invitation.png deleted file mode 100644 index 6434f230a3..0000000000 Binary files a/content/ja/ninja-workshops/11-ingest-processor-for-observability-cloud/images/workshop_invitation.png and /dev/null differ diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/1-getting-started/1-access-cloud-instances.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/1-getting-started/1-access-cloud-instances.md deleted file mode 100644 index 5e25fb5391..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/1-getting-started/1-access-cloud-instances.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: ワークショップ環境への接続方法 -linkTitle: 1.1 ワークショップ環境への接続方法 -weight: 2 ---- - -# ワークショップの起動 - -このワークショップは Splunk Show で利用可能で、すべてのリソースの起動には少し時間がかかります。IT Service Intelligence、Splunk Infrastructure Monitoring Add-On、および最近更新された AppDynamics Add-on がすべて事前設定された Splunk 環境が含まれています。 - -ワークショップのタイトルは **"Tech Summit 2025: OBS-122"** です。[Splunk Show](https://show.splunk.com/template/646/) のエントリから直接アクセスすることもできます。起動には約15分かかりますが、データの生成と取り込みには最大30分かかります。 - -![show-entry](../../images/show_entry.png?classes=inline) - -# Splunk Observability Cloud へのアクセス - -Observability Cloud でのアラート作成は、Observability Cloud US1 の [Show Playground](https://app.us1.signalfx.com/#/home) Org で行ってください。 diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/1-getting-started/_index.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/1-getting-started/_index.md deleted file mode 100644 index 36322ebe75..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/1-getting-started/_index.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: はじめに -linkTitle: 1. はじめに -weight: 1 ---- - -# Splunk、AppDynamics、および Splunk Observability Cloud による監視とアラート - -## イントロダクションと概要 - -今日の複雑なIT環境において、アプリケーションとサービスのパフォーマンスと可用性を確保することは最も重要です。このワークショップでは、包括的な監視とアラート機能を提供するために連携する強力なツールの組み合わせ、すなわちSplunk、AppDynamics、Splunk Observability Cloud、およびSplunk IT Service Intelligence (ITSI) をご紹介します。 - -### 現代の監視における課題 - -現代のアプリケーションは、分散アーキテクチャ、マイクロサービス、クラウドインフラストラクチャに依存していることが多いです。この複雑さにより、パフォーマンス問題や障害の根本原因を特定することが困難になっています。従来の監視ツールは個々のコンポーネントに焦点を当てることが多く、サービス全体の健全性とパフォーマンスを理解する上でギャップが生じます。 - -### ソリューション: 統合されたオブザーバビリティ - -包括的なオブザーバビリティ戦略には、さまざまなソースからのデータを統合し、実用的なインサイトを得るために相関させることが必要です。このワークショップでは、Splunk、AppDynamics、Splunk Observability Cloud、およびITSIがどのように連携してこれを実現するかをデモンストレーションします: - -* **Splunk:** ログ分析、セキュリティ情報およびイベント管理 (SIEM)、広範なデータ分析のための中央プラットフォームとして機能します。AppDynamics、Splunk Observability Cloud、およびその他のソースからデータを取り込み、強力な検索、可視化、相関機能を実現します。SplunkはIT環境の包括的なビューを提供します。 - -* **Splunk Observability Cloud:** インフラストラクチャメトリクス、分散トレース、ログを含むフルスタックオブザーバビリティを提供します。サーバーやコンテナからクラウドサービス、カスタムアプリケーションまで、インフラストラクチャ全体の健全性とパフォーマンスの統一ビューを提供します。Splunk Observability Cloudは、スタック全体にわたるパフォーマンス問題の相関に役立ちます。 - -* **AppDynamics:** 詳細なApplication Performance Monitoring (APM) を提供します。アプリケーションを計装して、トランザクショントレース、コードレベルの診断、ユーザーエクスペリエンスデータを含む詳細なパフォーマンスメトリクスをキャプチャします。AppDynamicsは、アプリケーション*内部*のパフォーマンスボトルネックの特定に優れています。 - -* **Splunk IT Service Intelligence (ITSI):** 他のすべてのプラットフォームからのデータを相関させることで、サービスインテリジェンスを提供します。ITSIを使用すると、サービスを定義し、依存関係をマッピングし、サービス全体の健全性とパフォーマンスを反映するKey Performance Indicators (KPIs) を監視できます。ITSIは、IT問題の*ビジネスへの影響*を理解するために不可欠です。 - -### データフローと統合 - -これらのプラットフォーム間でデータがどのように流れるかを理解することが重要な概念です: - -1. **Splunk Observability Cloud と AppDynamics がデータを収集:** アプリケーションとインフラストラクチャを監視し、パフォーマンスメトリクスとトレースを収集します。 - -2. **データが Splunk に送信される:** AppDynamicsとSplunk Observability CloudはSplunkと統合され、Splunkに直接送信されるログとともに収集したデータを転送します。 - -3. **Splunk がデータを分析およびインデックス化:** Splunkはデータを処理して保存し、検索および分析可能にします。 - -4. **ITSI が Splunk データを活用:** ITSIはSplunk内のデータを使用してサービスを作成し、KPIを定義し、IT運用全体の健全性を監視します。 - -### ワークショップの目標 - -このワークショップの終了時には、以下のことができるようになります: - -* Splunk、AppDynamics、Splunk Observability Cloud、およびITSIの相互補完的な役割を理解する。 -* Splunk、Observability Cloud、およびAppDynamicsで基本的なアラートを作成する。 -* ITSIで新しいサービスとシンプルなKPIおよびアラートを設定する。 -* ITSIにおけるエピソードの概念を理解する。 - -このワークショップは、堅牢なオブザーバビリティプラクティスを構築するための基盤を提供します。アラート設定のワークフローに焦点を当て、独自の環境でより高度な機能と設定を探索する準備を整えます。ITSIまたはアドオンのインストールと設定については**扱いません**。 - -事前設定された [Splunk Enterprise Cloud](./1-access-cloud-instances/) インスタンスへのアクセス方法についてはこちらをご覧ください。 diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/2-creating-basic-alerts/_index.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/2-creating-basic-alerts/_index.md deleted file mode 100644 index 7448cc7223..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/2-creating-basic-alerts/_index.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: 基本的なアラートの作成 -linkTitle: 2. 基本的なアラートの作成 -weight: 1 ---- - -# Splunk Enterprise、AppDynamics、および Splunk Observability Cloud での基本的なアラートの設定 - -このセクションでは、Splunk Enterprise、AppDynamics、およびSplunk Observability Cloudでの基本的なアラートの作成について説明します。これらの例は、シンプルさと核となる概念のデモンストレーションに焦点を当てています。実際のアラートシナリオでは、より複雑な設定としきい値が必要になることが多いことを覚えておいてください。 - -## 1. Splunk Enterprise アラート - -Splunkアラートは、特定の条件に一致する検索結果によってトリガーされます。特定の条件が満たされたときに通知するリアルタイムアラートを作成します。 - -**シナリオ:** 過去5分間に "main" インデックス内の "Invalid user" イベントの数が100を超えた場合にアラートを発生させます。 - -**手順:** - -1. **検索を作成:** アラートを発生させたいイベントを特定するSplunk検索を作成することから始めます。例えば: - - ```splunk - index=main "Invalid user" - ``` - - タイムピッカーを使用して "Last 15 minutes" を選択します。 - -2. **アラートを設定:** - * **Save As** をクリックし、**Alert** を選択します。 - * アラートにわかりやすい名前を付けます（例: "Numerous Invalid User Logins Attempted"）。 - * **Alert type:** - * **Scheduled:** 設定されたスケジュールで検索を評価するには **Scheduled** を選択します。Scheduledの下に頻度を選択するボタンがあるので、**Run on Cron Schedule** を選択します。 - * **Cron Expression:** */15* ** * - * **Triggered when:** **Number of results** **is greater than** **100** を選択します。 - * **Time Range:** "15 minutes" に設定します。 - * **Trigger Actions:** - * この基本的な例では、**Add to Triggered Alerts** を選択します。実際のシナリオでは、メール通知、Slack統合、またはその他のアクションを設定することになります。 - * **Save:** アラートを保存します。 - -![show-entry](../images/save_as_alert.png?classes=inline) - -**説明:** このアラートは15分ごとに検索を実行し、検索結果が100件を超えるとトリガーされます。**Add to Triggered Alerts** アクションは、単にSplunkのTriggered Alertsリストにアラートを追加します。 - -**時間範囲と頻度:** Splunkコアのすべては検索であるため、検索の期間と頻度を考慮する必要があります。これにより、a) 期間の重複により同じデータを複数回検索すること、b) 期間と頻度のギャップによりイベントを見逃すこと、c) 頻繁に実行しすぎてオーバーヘッドが増加すること、d) 実行頻度が低すぎてアラートに遅延が発生すること、を防ぐことができます。 - -## 2. Splunk Observability Cloud アラート (Detectors) - -**Detector を作成:** - -* 左側のメニューで **Detectors & SLOs** をクリックします -* **Create Detector -> Custom Detector** をクリックします -* Detectorにわかりやすい名前を付けます（例: "High CPU Utilization Alert - INITIALS"）。 -* **Signal:** - * 監視したいメトリクスを選択します ("cpu.utilization")。 - * ホストを指定するために必要なフィルターを追加します (`service.name:otelshop-loadgenerator`)。 - * **Proceed to Alert Condition** をクリックします -* **Condition:** - * Static Thresholdを選択します - * しきい値を設定します: **is above** **90** -* **Notifications:** - * この例では、シンプルな通知方法を選択します（例: テスト用のWebhook）。実際のシナリオでは、PagerDuty、Slack、またはその他の通知システムとの統合を設定することになります。 -* **Save:** Detectorを保存します。 - -![show-entry](../images/detector_preview.png?classes=inline) - -**説明:** このDetectorは、指定されたサービスのCPU使用率メトリクスを監視します。CPU使用率が設定された "for" 期間にわたって90% を超えると、Detectorがアラートをトリガーして通知を送信します。 - -**すべてのプラットフォームに関する重要な考慮事項:** - -* **しきい値:** アラートに設定するしきい値を慎重に検討してください。しきい値が敏感すぎるとアラート疲れにつながる可能性があり、しきい値が高すぎると重大な問題を見逃す可能性があります。 -* **通知チャネル:** アラートシステムを適切な通知チャネル（メール、SMS、Slack、PagerDuty）と統合して、アラートが適切な人に適切なタイミングで配信されるようにしてください。 -* **アラートのグループ化と相関:** 複雑なシステムでは、ノイズを減らし、実用的なインサイトに焦点を当てるために、アラートのグループ化と相関を実装してください。ITSIはこれにおいて重要な役割を果たします。 -* **ドキュメント:** アラートをトリガーする条件と適切な対応手順を含め、アラートを明確に文書化してください。 - -これらの例は、基本的なアラートを作成するための出発点を提供します。これらのプラットフォームに慣れてきたら、特定の監視ニーズに合わせて、より高度なアラート機能と設定を探索することができます。 diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/1-creating-o11y-service.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/1-creating-o11y-service.md deleted file mode 100644 index b2a18ac229..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/1-creating-o11y-service.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: O11y ベースのサービスの作成 -linkTitle: 3.1 O11y ベースのサービスの作成 -weight: 2 ---- - -# Observability Cloud ベースのサービスから始める - -1. **Services にアクセス:** ITSIで **Configuration** をクリックし、**Services** をクリックします。 - -2. **新しいサービスを作成: PaymentService2:** **Create New Service** をクリックします。 - -3. **サービスの詳細 (PaymentService2):** - * **Title:** "PaymentService2" - * **Description (Optional):** 例: "Payment Service for Hipster Shop - version 2" - -4. **テンプレートを選択:** **Link service to a service template** を選択し、テンプレートのドロップダウンから "Splunk APM Business Workflow KPIs" を検索します。**Create** をクリックして新しいサービスを保存します。 - -5. **エンティティの割り当て:** - * ページが読み込まれ、新しいサービスが表示され、Entitiesページが表示されます。このデモでは、デフォルトで *paymentservice:grpc.hipstershop.PaymentService/Charge* エンティティが選択されます。実際の状況では、ワークフローをエンティティ名に手動でマッチさせる必要があります。 - * **Direct Entity Selection (利用可能な場合):** `sf_workflow="paymentservice:grpc.hipstershop.PaymentService/Charge"` を使用してエンティティを検索し、選択します。 - -6. **サービスを保存 (PaymentService2):** **Save** をクリックして "PaymentService2" を作成します。 - -7. **Settings:** **Settings** タブをクリックし、*Backfill* を有効にして標準の7日間を維持します。サービスを有効にし、**Save** をクリックします。 - -## PaymentService2 の Service Health を Online-Boutique-US の依存関係として設定 - -1. **Online-Boutique-US を見つける:** サービスリストで "Online-Boutique-US" サービスを見つけます。 - -2. **Online-Boutique-US を編集:** **Edit** をクリックします。 - -3. **Service Dependencies:** **Service Dependencies** セクションを探します。 - -4. **依存関係を追加:** 依存サービスを追加するオプションがあるはずです。"PaymentService2" を検索します。 - -5. **KPI を選択:** PaymentService2のServiceHealthScoreの横にあるチェックボックスをオンにします。 - -6. **変更を保存:** "Online-Boutique-US" サービスへの変更を保存します。 - -## 確認 - -* **Service Analyzer** をクリックし、**Default Analyzer** を選択します -* サービスを "Buttercup Business Health" のみにフィルタリングします -* *PaymentService2* が *Online-Boutique-US* の下に表示され、グレーのステータスになっていることを確認します。 - -![show-entry](../images/service_tree_o11y.png?classes=inline) diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/2-creating-appd-service.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/2-creating-appd-service.md deleted file mode 100644 index 99af3ecb2a..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/2-creating-appd-service.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: AppD ベースのサービスの作成 -linkTitle: 3.2 AppD ベースのサービスの作成 -weight: 3 ---- - -# AppDynamics ベースのサービスから始める - -1. **Services にアクセス:** ITSIで **Configuration** をクリックし、**Services** をクリックします。 - -2. **サービスを作成: AD-Ecommerce2:** **Create Service -> Create Service** をクリックします。 - -3. **サービスの詳細 (AD-Ecommerce2):** - * **Title:** "AD-Ecommerce2" - * **Description (Optional):** 例: "Ecommerce Service - version 2" - -4. **テンプレートを選択:** **Link service to a service template** を選択し、テンプレートのドロップダウンから "AppDynamics App Performance Monitoring" を検索します。**Create** をクリックして新しいサービスを保存します。 - -5. **エンティティの割り当て:** - * ページが読み込まれ、新しいサービスが表示され、Entitiesページが表示されます。このデモでは、デフォルトで *AD-Ecommerce:18112:demo1.saas.appdynamics.com* エンティティが選択されます。実際の状況では、entity_nameをエンティティ名に手動でマッチさせる必要があります。 - * **Direct Entity Selection (利用可能な場合):** `entity_name="AD-Ecommerce:18112:demo1.saas.appdynamics.com"` を使用してエンティティを検索し、選択します。 - -6. **Settings:** **Settings** タブをクリックし、*Backfill* を有効にして標準の7日間を維持します。サービスを有効にし、**Save** をクリックします。 - -## AD-Ecommerce2 の Service Health を AD.Ecommerce の依存関係として設定 - -1. **Services ページに戻る:** **Configuration -> Services** をクリックします - -2. **AD.Ecommerce を見つける:** サービスリストで "AD.Ecommerce" サービスを見つけます。 - -3. **AD.Ecommerce を編集:** **Edit** をクリックします。 - -4. **Service Dependencies:** **Service Dependencies** セクションを探します。 - -5. **依存関係を追加:** 依存サービスを追加するオプションがあるはずです。"AD-Ecommerce2" を検索します。 - -6. **KPI を選択:** AD-Ecommerce2のServiceHealthScoreの横にあるチェックボックスをオンにします。 - -7. **変更を保存:** "AD.Ecommerce" サービスへの変更を保存します。 - -## 確認 - -* **Service Analyzer** をクリックし、**Default Analyzer** を選択します -* サービスを "Buttercup Business Health" のみにフィルタリングします -* *AD-Ecommerce2* が *AD.Ecommerce* の下に表示され、グレーのステータスになっていることを確認します。 - -![show-entry](../images/service_tree_appd.png?classes=inline) diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/_index.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/_index.md deleted file mode 100644 index 81c03230f3..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/3-creating-services-in-itsi/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: ITSI でのサービスの作成 -linkTitle: 3. ITSI でのサービスの作成 -weight: 1 ---- - -# エンティティタイプに基づく依存関係を持つ ITSI でのサービスの作成 - -このワークショップでは、既存のエンティティを使用してSplunk IT Service Intelligence (ITSI) でサービスを作成し、エンティティのタイプに基づいて依存関係を確立する方法について説明します。Splunk Observability Cloudからのビジネスワークフローを表すエンティティと、AppDynamics Business Transactionsを表すエンティティを区別します。 - -**シナリオ:** - -2つの既存サービスがあります: "Online-Boutique-US"（Kubernetesで実行され、Splunk Observability Cloudによって監視されているアプリケーションを表す）と "AD.ECommerce"（AppDynamicsによって監視されているアプリケーションを表す）。新しいサービスを作成し、これらのサービスの1つの依存関係として追加したいと思います。このワークショップの最初の実行時に両方のサービスを作成する必要はないので、まずは興味のある方を選択してください。 - -![show-entry](../images/service_tree_start.png?classes=inline) - -**Splunk 環境に戻り、Apps から IT Service Intelligence を選択してください** - -Default Analyzerでフィルターを "Buttercup Business Health" に更新してください diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/4-creating-alerts-in-itsi/_index.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/4-creating-alerts-in-itsi/_index.md deleted file mode 100644 index 6f084db1ef..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/4-creating-alerts-in-itsi/_index.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: ITSI でのアラートの作成 -linkTitle: 4. ITSI でのアラートの作成 -weight: 1 ---- - -# Splunk ITSI での基本的なアラートの設定 - -このセクションでは、Splunk IT Service Intelligence (ITSI) で基本的なアラートを設定する方法を説明します。以前作成したサービスがKPIのしきい値を超えたときにトリガーされるアラートを設定します。 - -**作成したサービスに応じて、このアラートに使用する KPI が変わります。以下の手順では、Service Name と KPI を適切に置き換えてください** - -* **PaymentService2:** Business Workflow Error Rate -* **AD-Ecommerce2:** Availability - -**手順:** - -1. **KPI に移動:** - * ITSIで **Configuration** -> **Correlation Searches** に移動します - * **Create New Search** をクリックします - -2. **新しい検索を設定:** - * **Search Title:** *Service Name* *KPI* Critical - * **Description:** *Service Name* *KPI* Critical - * **Search:** - - ``` - index=itsi_summary kpi="*KPI*" alert_severity=critical - ``` - - * **Time Range:** Last 15 minutes - * **Service:** *Service Name* - * **Entity Lookup Field:** itsi_service_id - * **Run Every:** minutes - * **Notable Event Title:** *Service Name* *KPI* Critical - * **Severity:** Critical - * **Notable Event Identified Fields:** source - -**アラート作成後:** - -* アラートが実行されるまで5〜10分待つ必要があります -* アラートはITSIの **Alerts and Episodes** ペインにリストされます。 - -![show-entry](../images/alerts.png?classes=inline) - -**重要な考慮事項:** - -* **アラート疲れ:** アラートを多く設定しすぎたり、しきい値が敏感すぎるアラートを設定したりしないようにしてください。これはアラート疲れにつながり、人々がアラートに鈍感になって重大な問題を見逃す可能性があります。 diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/5-episodes-in-itsi/_index.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/5-episodes-in-itsi/_index.md deleted file mode 100644 index 1b8c0ee873..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/5-episodes-in-itsi/_index.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: ITSI でのエピソードの作成 -linkTitle: 5. ITSI でのエピソードの作成 -weight: 1 ---- - -# Splunk ITSI での Aggregation Policy の作成 - -このセクションでは、先ほど設定したアラートに一致するSplunk ITSIでのAggregation Policyを作成する手順について説明します。このポリシーは関連するアラートをグループ化し、ノイズを減らしてインシデント管理を改善します。 - -**作成したアラートに応じて、このアラートに使用するタイトルが変わります。以下の手順では、AlertName を使用した Service Name に置き換えてください** - -* **PaymentService2** または -* **AD-Ecommerce2** - -## 手順 - -1. **Notable Event Aggregation Policies に移動:** Splunkで **Configuration** -> **Notable Event Aggregation Policies** に移動します。 - -2. **新しいポリシーを作成:** 右上隅にある緑色の **Create Notable Event Aggregation Policy** ボタンをクリックします。 - -3. **フィルタリング条件:** これが最も重要な部分です。このポリシーによってグループ化されるアラートの条件を定義します。**Add Rule (OR)** をクリックします - - * **Field:** ドロップダウンメニューから **title** を選択します。 - * **Operator:** **matches** を選択します。 - * **Value:** "*Service Name**" という文字列を入力します（* を含めることを忘れないでください）。 - -4. **イベントの分割:** デフォルトで提供されている "hosts" フィールドを削除し、"service" フィールドを使用するように更新します。これにより、見つかった各サービスごとに新しいエピソードが生成されます。この例では、1つだけになるはずです。 - -5. **終了条件:** エピソードがどのように終了するかを設定します。デフォルトの *"If an event occurs for which severity = Normal"* のままにします。右側のPreviewをクリックして、アラートが正しく検出されていることを確認します - -6. **Next をクリック** - -7. **アクション（オプション）:** 集約されたアラートに対して実行するアクションを定義します。例えば、ServiceNowでチケットを自動作成したり、メール通知を送信したりできます。この部分はスキップします。 - -8. **Next をクリック** - -9. **ポリシーのタイトルと説明:** - * **Policy Title:** *Service Name* Alert Grouping - * **Description:** Grouping *Service Name* alerts together. - -10. **ポリシーを保存:** **Next** ボタンをクリックしてAggregation Policyを作成します。 - -## 確認 - -ポリシーを保存した後、**Go to Episode Review** ページに移動し、過去15分間のアラートをフィルタリングし、status=Newのフィルターを追加して、検索ボックスでService Nameを検索します。 - -特定のアラートの名前が付いたエピソードがすでに存在する場合は、それを閉じて、新しいタイトルで新しいエピソードが生成されるのを待ちます。 - -![show-entry](../images/episode.png?classes=inline) diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/6-detectors-to-itsi/_index.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/6-detectors-to-itsi/_index.md deleted file mode 100644 index 6c06cf8a53..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/6-detectors-to-itsi/_index.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: ITSI での Observability Cloud Detectors の使用 -linkTitle: 6. ITSI での Observability Cloud Detectors の使用 -weight: 1 ---- - -## パート 2: Splunk Observability Cloud から Splunk ITSI へのアラート送信 - -先ほど設定したSplunk Observability CloudのDetectorがあるため、次のステップは、アラートがトリガーされたときに、そのアラートがSplunk IT Service Intelligence (ITSI) に送信されるようにすることです。この統合により、ITSIはこれらのアラートをNotable Eventとして取り込み、他のイベントと相関させてサービスヘルススコアに貢献させることができます。これを実現する最も一般的な方法は、Splunk Observability CloudのWebhookを使用して、Splunk ITSIで設定されたHTTP Event Collector (HEC) エンドポイントにアラートデータを送信することです。 - -**ステップ 1: Splunk (ITSI) で HTTP Event Collector (HEC) を設定** - -Splunk Observability CloudがITSIにアラートを送信する前に、それらを受信するためにSplunkインスタンス（ITSIが実行されている場所）にHECエンドポイントが必要です。 - -1. ITSIをホストしているSplunk EnterpriseまたはSplunk Cloudインスタンスにログインします。 -2. **Settings > Data Inputs** に移動します。 -3. **HTTP Event Collector** をクリックします。 -4. **Global Settings** をクリックします。HECが有効になっていることを確認します。有効になっていない場合は、有効にしてデフォルトポート（例: 8088、ただしSplunk Cloudでは異なる管理方法の場合があります）を指定します。 -5. **New Token** をクリックします。 -6. HECトークンにわかりやすい名前を付けます。例: `o11y_alerts_for_itsi`。 -7. **Source name override** については、オプションでsourcetypeを指定するか、空白のままにしてObservability Cloudで指定するか、デフォルトを使用できます。 -8. **Default Index** については、ITSIがこれらのイベントにアクセスできる適切なインデックスを選択します。多くの場合、ITSIイベント専用のインデックスがあるか、`main` や `itsi_event_management` などの一般的なイベントインデックスを使用することがあります。 -9. トークンが有効になっていることを確認し、**Submit** をクリックします。 -10. 生成された **Token Value** をコピーします。これはSplunk Observability CloudでのWebhook設定に必要です。 - -**ステップ 2: Splunk Observability Cloud で Webhook 統合を設定** - -次に、Splunk Observability Cloudに戻り、作成したHECトークンを使用するWebhookを設定します。 - -1. Splunk Observability Cloudで **Data Management > Available Integrations** に移動します。 -2. 新しい **Splunk platform** を追加するオプションを探します。 -3. 統合に名前を付けます。例: `Splunk ITSI HEC`。 -4. **URL** フィールドに、SplunkインスタンスのHECエンドポイントURIを入力します。通常、`https://:/services/collector/event` の形式になります。 -5. 先ほど作成した **HEC token** を追加する必要があります。 -6. **Payload** については、ITSIが理解できるJSONペイロードを構築する必要があります。Splunk Observability Cloudは、ITSIイベント相関に必要なフィールドを含むように設定された、すぐに使えるペイロードを提供しています。 -7. 統合を確認し、**Save** をクリックします - -**ステップ 3: Webhook を使用するように Detector を更新** - -次に、パート1で作成したDetectorに戻り、新しく設定したWebhookを使用するように通知設定を更新します。 - -1. Splunk Observability Cloudで **Detectors & SLOs** に移動します。 -2. EC2 CPU使用率用に作成したDetectorを見つけて編集します。 -3. 先ほど作成したAlert ruleをクリックします -4. **Alert Recipients** セクションに移動します。 -5. **Add recipient > Splunk platform** をクリックし、設定した統合（`Splunk ITSI HEC`）を目的のアラート重大度（例: Critical、Warning）に対して選択します。 -6. Detectorへの変更を保存します。 - -**ステップ 4: 検証** - -統合をテストするには、本物のアラートがトリガーされるのを待つか、Detectorの設定で許可されている場合は、テストアラートを手動でトリガーするか、しきい値を一時的に下げてアラートを強制的に発生させることができます。Splunk Observability Cloudでアラートがトリガーされると、Webhookを介してSplunk HECエンドポイントにペイロードが送信されるはずです。 - -Splunkでターゲットインデックスを検索して確認します（例: `index=itsi_event_management sourcetype=o11y:itsi:alert host=`）。Splunk Observability Cloudからのイベントデータが到着していることが確認できるはずです。 - -これらの手順により、Splunk Observability CloudのDetectorからのアラートがSplunk ITSIに送信されるようになりました。イベントの相関とNotableの生成は、このワークショップで先ほど説明したのとまったく同じように機能します。 diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/_index.md b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/_index.md deleted file mode 100644 index 9316bd7803..0000000000 --- a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/_index.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: Splunk IT Service Intelligence によるアラートと監視 -linkTitle: Splunk IT Service Intelligence によるアラートと監視 -weight: 12 -archetype: chapter -authors: ["Doug Erkkila"] -description: シナリオの説明 -hidden: false ---- - -# ワークショップ: Splunk IT Service Intelligence による監視とアラート - -このハンズオンワークショップは、Splunk Enterprise、AppDynamics、Splunk Observability Cloud、およびSplunk IT Service Intelligence (ITSI) の統合されたパワーを効果的にデモンストレーションし、ポジショニングしたい方を対象に設計されています。参加者は、潜在的なクライアントに響く実世界のシナリオとユースケースに焦点を当てながら、これらのプラットフォームを統合する実践的な経験を得ることができます。このワークショップは、技術的な機能をビジネス価値に変換することを重視し、ソリューションアーキテクトが重要な顧客課題にどのように対応するかを自信を持ってデモンストレーションできるようにします。 - -## イントロダクションと概要 - -今日の複雑なIT環境において、アプリケーションとサービスのパフォーマンスと可用性を確保することは最も重要です。このワークショップでは、包括的な監視とアラート機能を提供するために連携する強力なツールの組み合わせ、すなわちSplunk、AppDynamics、Splunk Observability Cloud、およびSplunk IT Service Intelligence (ITSI) をご紹介します。 - -### 現代の監視における課題 - -現代のアプリケーションは、分散アーキテクチャ、マイクロサービス、クラウドインフラストラクチャに依存していることが多いです。この複雑さにより、パフォーマンス問題や障害の根本原因を特定することが困難になっています。従来の監視ツールは個々のコンポーネントに焦点を当てることが多く、サービス全体の健全性とパフォーマンスを理解する上でギャップが生じます。 - -### ソリューション: 統合されたオブザーバビリティ - -包括的なオブザーバビリティ戦略には、さまざまなソースからのデータを統合し、実用的なインサイトを得るために相関させることが必要です。このワークショップでは、Splunk、AppDynamics、Splunk Observability Cloud、およびITSIがどのように連携してこれを実現するかをデモンストレーションします: - -* **AppDynamics:** 詳細なApplication Performance Monitoring (APM) を提供します。アプリケーションを計装して、トランザクショントレース、コードレベルの診断、ユーザーエクスペリエンスデータを含む詳細なパフォーマンスメトリクスをキャプチャします。AppDynamicsは、アプリケーション*内部*のパフォーマンスボトルネックの特定に優れています。 - -* **Splunk Observability Cloud:** インフラストラクチャメトリクス、分散トレース、ログを含むフルスタックオブザーバビリティを提供します。サーバーやコンテナからクラウドサービス、カスタムアプリケーションまで、インフラストラクチャ全体の健全性とパフォーマンスの統一ビューを提供します。Splunk Observability Cloudは、スタック全体にわたるパフォーマンス問題の相関に役立ちます。 - -* **Splunk:** ログ分析、セキュリティ情報およびイベント管理 (SIEM)、広範なデータ分析のための中央プラットフォームとして機能します。AppDynamics、Splunk Observability Cloud、およびその他のソースからデータを取り込み、強力な検索、可視化、相関機能を実現します。SplunkはIT環境の包括的なビューを提供します。 - -* **Splunk IT Service Intelligence (ITSI):** 他のすべてのプラットフォームからのデータを相関させることで、サービスインテリジェンスを提供します。ITSIを使用すると、サービスを定義し、依存関係をマッピングし、サービス全体の健全性とパフォーマンスを反映するKey Performance Indicators (KPIs) を監視できます。ITSIは、IT問題の*ビジネスへの影響*を理解するために不可欠です。 - -## ワークショップの目標 - -このワークショップの終了時には、参加者は以下のことができるようになります: - -* 包括的なオブザーバビリティ戦略におけるSplunk、AppDynamics、Splunk Observability Cloud、およびSplunk IT Service Intelligenceの相互補完的な価値提案を明確に説明する。 -* データフローと相関機能を強調しながら、これらのプラットフォーム間の統合ポイントを自信を持ってデモンストレーションする。 -* 実践的なアラートシナリオを紹介しながら、Splunk Enterprise、AppDynamics、およびSplunk Observability Cloudで基本的なアラートを作成および設定する。 -* サービス中心の監視を強調しながら、Splunk ITSIでのKey Performance Indicator (KPI) の作成とアラートの説得力のあるデモンストレーションを構築および提示する。 -* インシデント管理の改善とMTTRの短縮のためのSplunk ITSIにおけるエピソードの価値を説明およびデモンストレーションする。 -* ROIに焦点を当て、特定の顧客の課題に対処しながら、技術的な機能をビジネス成果に変換する。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下の通りです: - -* このページの右上にある左右の矢印 (**<** | **>**) を使用する -* キーボードの左 (◀️) および右 (▶️) カーソルキーを使用する - {{% /notice %}} - \ No newline at end of file diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/alerts.png b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/alerts.png deleted file mode 100644 index 7bb4b81ad2..0000000000 Binary files a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/alerts.png and /dev/null differ diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/detector_preview.png b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/detector_preview.png deleted file mode 100644 index c0c0294526..0000000000 Binary files a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/detector_preview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/episode.png b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/episode.png deleted file mode 100644 index 41901d15a6..0000000000 Binary files a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/episode.png and /dev/null differ diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/save_as_alert.png b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/save_as_alert.png deleted file mode 100644 index f39193fcdf..0000000000 Binary files a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/save_as_alert.png and /dev/null differ diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_appd.png b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_appd.png deleted file mode 100644 index d3e7a1930a..0000000000 Binary files a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_appd.png and /dev/null differ diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_o11y.png b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_o11y.png deleted file mode 100644 index 9f29228d73..0000000000 Binary files a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_o11y.png and /dev/null differ diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_start.png b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_start.png deleted file mode 100644 index 1ff6840ed9..0000000000 Binary files a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/service_tree_start.png and /dev/null differ diff --git a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/show_entry.png b/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/show_entry.png deleted file mode 100644 index 2b9204d9e8..0000000000 Binary files a/content/ja/ninja-workshops/12-alerting-monitoring-with-itsi/images/show_entry.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md b/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md deleted file mode 100644 index f4ebcc6564..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -title: OpenShiftの前提条件 -linkTitle: 2. OpenShiftの前提条件 -weight: 2 -time: 15 minutes ---- - -以下の手順は、AWSにOpenShiftクラスターをデプロイする前に必要です。 - -## Red Hatログインの作成 - -最初に行う必要があるのは、Red Hatのアカウントを作成することです。[こちら](https://www.redhat.com/wapps/ugc/register.html?_flowId=register-flow&_flowExecutionKey=e1s1)のフォームに記入して作成できます。 - -## 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" -``` - -## 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 -```` - -## 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 -``` - -## アカウント全体のロールとポリシーの作成 - -以下のコマンドを使用して、必要なアカウント全体のロールとポリシーを作成します： - -``` bash -rosa create account-roles --mode auto -``` - -## ROSA HCP用のAWS VPCの作成 - -OpenShiftクラスターをデプロイするために、Hosted Control Plane (HCP)デプロイオプションを使用します。これを行うには、以下のコマンドを使用してAWSアカウントに新しいVPCを作成する必要があります： - -> 注意: リージョンを環境に合わせて更新してください。 - -``` bash -rosa create network network-template --param Region=us-east-2 --param Name=rosa-network-stack --template-dir='.' -``` - -> 重要: このコマンドの結果として作成されたサブネットIDをメモしておいてください。クラスターを作成する際に必要になります。また、ネットワークを削除する場合に後で必要になるCloudFormationスタック名もメモしておいてください。 - -> 注意: デフォルトでは、各AWSリージョンはElastic IPアドレスが5つに制限されています。「The maximum number of addresses has been reached.」というエラーが発生した場合は、AWSに連絡してこの制限の引き上げをリクエストするか、ROSA用のVPCを作成するために別のAWSリージョンを選択する必要があります。 - -## OpenID Connect設定の作成 - -Red Hat OpenShift Service on AWSクラスターを作成する前に、以下のコマンドでOpenID Connect (OIDC)設定を作成しましょう： - -``` bash -rosa create oidc-config --mode=auto --yes -``` - -> 重要: 作成されたoidc-provider idをメモしておいてください。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md b/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md deleted file mode 100644 index 012b024d78..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md +++ /dev/null @@ -1,329 +0,0 @@ ---- -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と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`が表示されていることを確認してください： - -![NVIDIAサブスクリプション](../../images/NVIDIA-Subscriptions.png) - -## 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のインストール - -このセクションの手順は、[CLIを使用したNFD Operatorのインストール](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の作成 - -このセクションの手順は、[CLIを使用したNodeFeatureDiscovery CRの作成](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のインストール - -このセクションの手順は、[OpenShiftへのNVIDIA GPU Operatorのインストール](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 >}} - -## クラスターポリシーの作成 - -このセクションの手順は、[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のインストール - -このセクションの手順は、[GitHubリリースからのインストール](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インストール](https://org.ngc.nvidia.com/setup/installers/cli)に基づいています。 - -Download CLIをクリックしてバイナリを含むzipファイルをダウンロードし、権限のあるディレクトリに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バイナリを実行可能にし、現在のディレクトリをパスに追加します： - -``` 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のインストール - -このセクションの手順は、[operator-sdkを使用したRed Hat OpenShiftへのNIM Operatorのインストール（開発専用）](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/14-cisco-ai-pods/1-workshop-setup/5-deploy-llm.md b/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/5-deploy-llm.md deleted file mode 100644 index 905127b408..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/5-deploy-llm.md +++ /dev/null @@ -1,247 +0,0 @@ ---- -title: LLMのデプロイ -linkTitle: 5. LLMのデプロイ -weight: 5 -time: 20 minutes ---- - -このセクションでは、NVIDIA NIM Operatorを使用して、2つのLarge Language ModelsをOpenShiftクラスターにデプロイします。 - -## Namespaceの作成 - -``` bash -oc create namespace nim-service -``` - -## NGC APIキーを使用したSecretの追加 - -NVIDIA NGCからコンテナイメージをダウンロードするためのDockerレジストリSecretを追加します： - -``` bash -oc create secret -n nim-service docker-registry ngc-secret \ - --docker-server=nvcr.io \ - --docker-username='$oauthtoken' \ - --docker-password=$NGC_API_KEY -``` - -モデルプーラーコンテナがNVIDIA NGCからモデルをダウンロードするために使用する汎用Secretを追加します： - -``` bash -oc create secret -n nim-service generic ngc-api-secret \ - --from-literal=NGC_API_KEY=$NGC_API_KEY -``` - -## LLMのデプロイ - -以下のコマンドを実行して、NIMCacheとNIMServiceを作成します： - -``` bash -oc apply -n nim-service -f nvidia-llm.yaml -``` - -Persistent Volumeが作成され、Persistent Volume Claimが正常にバインドされたことを確認します： - -> 注意: これには数分かかる場合があります - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -oc get pv,pvc -n nim-service -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` bash -NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE -persistentvolume/pvc-1af12c04-29ad-497f-b018-7d9a3aea3019 100Gi RWO Delete Bound openshift-monitoring/prometheus-data-prometheus-k8s-1 gp3-csi 4h15m -persistentvolume/pvc-9c389d79-13fb-4169-9d99-a77efd6e7919 100Gi RWO Delete Bound openshift-monitoring/prometheus-data-prometheus-k8s-0 gp3-csi 4h15m -persistentvolume/pvc-a603b8a7-1445-4b03-945a-3ed68338834c 50Gi RWO Delete Bound nim-service/meta-llama-3-2-1b-instruct-pvc gp3-csi 114s - -NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE -persistentvolumeclaim/meta-llama-3-2-1b-instruct-pvc Bound pvc-a603b8a7-1445-4b03-945a-3ed68338834c 50Gi RWO gp3-csi 7m8s -``` - -{{% /tab %}} -{{< /tabs >}} - -NIMCacheがReadyであることを確認します： - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -oc get nimcache.apps.nvidia.com -n nim-service -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` bash -NAME STATUS PVC AGE -meta-llama-3-2-1b-instruct Ready meta-llama-3-2-1b-instruct-pvc 9m50s -``` - -{{% /tab %}} -{{< /tabs >}} - -NIMServiceがReadyであることを確認します： - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -oc get nimservices.apps.nvidia.com -n nim-service -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` bash -NAME STATUS AGE -meta-llama-3-2-1b-instruct Ready 11m -``` - -{{% /tab %}} -{{< /tabs >}} - -## LLMのテスト - -LLMが期待通りに動作していることを確認しましょう。 - -curlコマンドにアクセスできるPodを起動します： - -``` bash -oc run --rm -it -n default curl --image=curlimages/curl:latest -- sh -``` - -次に、以下のコマンドを実行して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 >}} - -## Embeddingsモデルのデプロイ - -また、クラスターに[embeddingsモデル](https://build.nvidia.com/nvidia/llama-3_2-nv-embedqa-1b-v2/deploy)をデプロイします。これは、このワークショップの後半でRetrieval Augmented Generation (RAG)を実装するために使用されます。 - -以下のコマンドを実行して、embeddingsモデルをデプロイします： - -``` bash -oc apply -n nim-service -f nvidia-embeddings.yaml -``` - -NIMServiceがReadyであることを確認します： - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -oc get nimservices.apps.nvidia.com llama-32-nv-embedqa-1b-v2 -n nim-service -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` bash -NAME STATUS AGE -llama-32-nv-embedqa-1b-v2 Ready 82s -``` - -{{% /tab %}} -{{< /tabs >}} - -## Embeddingsモデルのテスト - -embeddingsモデルが期待通りに動作していることを確認しましょう。 - -curlコマンドにアクセスできるPodを起動します： - -``` bash -oc run --rm -it -n default curl --image=curlimages/curl:latest -- sh -``` - -次に、以下のコマンドを実行してLLMにプロンプトを送信します： - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash - curl -X POST http://llama-32-nv-embedqa-1b-v2.nim-service:8000/v1/embeddings \ - -H 'Accept: application/json' \ - -H "Content-Type: application/json" \ - -d '{ - "input": ["What is the capital of France?"], - "model": "nvidia/llama-3.2-nv-embedqa-1b-v2", - "input_type": "query", - "encoding_format": "float", - "truncate": "NONE" - }' -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` bash -{"object":"list","data":[{"index":0,"embedding":[-0.016632080078125,0.041259765625,-0.0156707763671875,0.032379150390625,0.045074462890625,0.0169830322265625,-0.03546142578125,-0.0003402233123779297,-0.038909912109375,-0.0023651123046875,-0.0001741647720336914,-0.01377105712890625,-0.01200103759765625,-0.00659942626953125,0.002536773681640625,0.0185394287109375,0.01546478271484375,0.0216827392578125,0.0139923095703125,-0.0121612548828125,-0.015869140625,0.005313873291015625,-0.020599365234375,0.02984619140625,-0.031982421875,0.0005679130554199219,-0.021697998046875,-0.0305938720703125,0.027618408203125,0.005340576171875,0.011993408203125,0.0135345458984375,-0.015625,0.036651611328125,-0.0210113525390625,0.0033321380615234375,0.033172607421875,-0.009552001953125,0.0226287841796875,0.01448822021484375,-0.05474853515625,-0.00861358642578125,-0.01513671875,-0.028656005859375,-0.0095977783203125,-0.025146484375,-0.0352783203125,0.03106689453125,-0.00726318359375,0.0157623291015625,0.01319122314453125,-0.005218505859375,-0.0013561248779296875,0.01277923583984375,-0.007328033447265625,0.01486968994140625,-0.05413818359375,-0.022125244140625,-0.015869140625,-0.00917816162109375,0.0186309814453125,-0.00814056396484375,-0.04730224609375,0.01406097412109375,-0.0248260498046875,0.0094757080078125,0.0309600830078125,0.0196533203125,-0.0270843505859375,-0.01113128662109375,-0.0056915283203125,-0.01154327392578125,0.037750244140625,-0.0028896331787109375,-0.00376129150390625,0.03692626953125,0.020416259765625,0.00200653076171875,0.0396728515625,0.004985809326171875,-0.04425048828125,-0.034820556640625,-0.0102386474609375,0.0218505859375,0.003604888916015625,0.00940704345703125,0.01468658447265625,0.0089111328125,-0.0032196044921875,-0.043243408203125,0.015411376953125,-0.00653839111328125,-0.01128387451171875,-0.052734375,0.032684326171875,-0.0101470947265625,-0.018218994140625,-0.003955841064453125,0.007648468017578125,-0.02044677734375,-0.0285186767578125,0.0153350830078125,0.03692626953125,0.0147247314453125,0.01043701171875,0.0007462501525878906,0.0261077880859375,0.024169921875,-0.040283203125,-0.005828857421875,0.00736236572265625,-0.00909423828125,0.00920867919921875,-0.00243377685546875,-0.03204345703125,-0.0232696533203125,0.01131439208984375,-0.0192413330078125,-0.025482177734375,-0.0267333984375,-0.03350830078125,-0.0008440017700195312,-0.040496826171875,0.0281982421875,-0.03533935546875,-0.0005216598510742188,0.061859130859375,0.0439453125,-0.00656890869140625,0.004627227783203125,-0.05615234375,0.027801513671875,-0.0027790069580078125,-0.011322021484375,-0.00841522216796875,0.027191162109375,-0.0018453598022460938,-0.00560760498046875,0.020263671875,-0.0295867919921875,0.03759765625,-0.00951385498046875,0.014190673828125,-0.039764404296875,-0.0199127197265625,-0.007427215576171875,-0.021392822265625,0.00946807861328125,0.03955078125,0.0015478134155273438,0.0227203369140625,0.020843505859375,-0.00531768798828125,0.0087432861328125,-0.01617431640625,0.002574920654296875,0.0104217529296875,0.01215362548828125,0.00970458984375,0.003803253173828125,0.005451202392578125,-0.001972198486328125,-0.01171875,-0.0216217041015625,0.033355712890625,-0.007137298583984375,0.00890350341796875,-0.01293182373046875,0.0189666748046875,-0.0168609619140625,-0.0153350830078125,0.0113525390625,-0.0123443603515625,0.046905517578125,0.0082244873046875,-0.019500732421875,0.004482269287109375,0.01007080078125,0.0037708282470703125,0.053619384765625,0.0171051025390625,-0.0305023193359375,-0.0240478515625,0.007648468017578125,-0.03973388671875,0.00847625732421875,-0.0207061767578125,-0.025115966796875,0.0168914794921875,0.03619384765625,0.00720977783203125,0.00803375244140625,0.022064208984375,-0.01111602783203125,-0.0024890899658203125,0.0047760009765625,-0.02374267578125,-0.0197296142578125,0.0203704833984375,0.00572967529296875,0.0254058837890625,0.0186920166015625,-0.022796630859375,-0.02191162109375,-0.0182952880859375,-0.00365447998046875,-0.01262664794921875,-0.0128326416015625,0.0157318115234375,-0.004596710205078125,0.033843994140625,0.01313018798828125,0.00656890869140625,0.0004596710205078125,-0.020355224609375,0.03411865234375,0.00034546852111816406,0.0205230712890625,0.02960205078125,-0.0157318115234375,-0.051483154296875,-0.0255584716796875,0.039825439453125,0.0258636474609375,0.038238525390625,-0.03424072265625,0.0188140869140625,0.03216552734375,-0.048126220703125,-0.0227203369140625,0.0032215118408203125,-0.0156097412109375,-0.003170013427734375,0.01444244384765625,-0.0232086181640625,0.002437591552734375,0.012451171875,-0.0066680908203125,0.01158905029296875,0.026397705078125,-0.00373077392578125,0.008087158203125,-0.00798797607421875,-0.0173187255859375,-0.013580322265625,0.033660888671875,-0.0028629302978515625,0.046295166015625,0.0299530029296875,-0.0159759521484375,-0.005580902099609375,0.0015277862548828125,0.01123046875,0.0031585693359375,-0.01151275634765625,0.00814056396484375,-0.0369873046875,0.0267181396484375,0.0013856887817382812,0.028656005859375,0.01409149169921875,0.035614013671875,-0.01189422607421875,-0.01190185546875,-0.053619384765625,0.037139892578125,-0.02288818359375,-0.024139404296875,0.01678466796875,-0.01020050048828125,-0.0222930908203125,-0.01059722900390625,0.044525146484375,0.006526947021484375,0.006084442138671875,-0.0015411376953125,-0.040618896484375,0.027801513671875,-0.00839996337890625,-0.01126861572265625,-0.01000213623046875,0.01197052001953125,-0.01062774658203125,-0.0155487060546875,0.011688232421875,0.01044464111328125,-0.0528564453125,0.031005859375,-0.0007734298706054688,8.52346420288086e-6,-0.00894927978515625,-0.005870819091796875,0.04254150390625,-0.03216552734375,0.0215911865234375,-0.01029205322265625,-0.01015472412109375,-0.036285400390625,0.0111083984375,0.0018520355224609375,-0.01177215576171875,0.01256561279296875,-0.004901885986328125,-0.006866455078125,-0.0084381103515625,-0.01160430908203125,-0.044891357421875,0.00632476806640625,0.0015001296997070312,-0.0016727447509765625,-0.013031005859375,-0.01404571533203125,-0.035888671875,-0.013397216796875,-0.0006346702575683594,0.00981903076171875,-0.0134735107421875,-0.022705078125,-0.02606201171875,-0.018402099609375,-0.046966552734375,-0.012542724609375,0.0183563232421875,0.0179901123046875,-0.0225067138671875,0.02801513671875,-0.032379150390625,-0.0079803466796875,0.0070953369140625,0.017333984375,0.026611328125,-0.03778076171875,-0.023590087890625,-0.005245208740234375,0.024383544921875,-0.02105712890625,0.020843505859375,0.033905029296875,0.0225372314453125,0.00942230224609375,0.0005245208740234375,-0.0284881591796875,0.01499176025390625,-0.0124664306640625,-0.0267333984375,0.023040771484375,0.01265716552734375,-0.0026264190673828125,0.00955963134765625,-0.0036773681640625,-0.0394287109375,0.015716552734375,-0.01300048828125,0.0187225341796875,-0.01275634765625,-0.0273590087890625,0.045562744140625,-0.00913238525390625,-0.004268646240234375,-0.005107879638671875,-0.026702880859375,0.0015077590942382812,-0.02862548828125,0.0003228187561035156,0.0099334716796875,-0.0305328369140625,-0.0362548828125,0.0114898681640625,-0.00025653839111328125,-0.0022735595703125,0.0106201171875,0.01090240478515625,0.00992584228515625,0.00998687744140625,-0.00634002685546875,0.00711822509765625,-0.02337646484375,-0.01367950439453125,-0.006389617919921875,-0.006000518798828125,0.01027679443359375,-0.00838470458984375,0.004673004150390625,0.002841949462890625,0.014404296875,-0.02838134765625,0.023834228515625,-0.00823974609375,-0.038970947265625,0.003002166748046875,-0.04510498046875,-0.0265655517578125,-0.0036182403564453125,-0.046661376953125,-0.01062774658203125,-0.05804443359375,-0.02117919921875,-0.029815673828125,0.036712646484375,-0.0069122314453125,0.0079345703125,0.0164794921875,-0.007534027099609375,-0.01111602783203125,0.0135650634765625,-0.0017242431640625,0.009490966796875,-0.0222320556640625,0.043853759765625,0.054718017578125,-0.003208160400390625,-0.004199981689453125,0.01529693603515625,-0.007190704345703125,0.00637054443359375,-0.004749298095703125,-0.0217132568359375,-0.0093841552734375,-0.0335693359375,-0.0017490386962890625,0.0081939697265625,0.0247802734375,0.0148468017578125,0.026763916015625,0.002079010009765625,0.0292816162109375,0.04705810546875,0.02166748046875,-0.0120697021484375,0.01050567626953125,0.0131988525390625,0.0169525146484375,0.0291595458984375,-0.00270843505859375,-0.0095062255859375,-0.0211944580078125,-0.035980224609375,0.006805419921875,0.002735137939453125,0.043731689453125,-0.01515960693359375,0.0010576248168945312,-0.00913238525390625,0.001293182373046875,-0.00027489662170410156,-0.00868988037109375,0.007389068603515625,0.0023212432861328125,-0.01528167724609375,0.017852783203125,-0.03643798828125,0.045623779296875,-0.0030364990234375,-0.0271453857421875,0.0268402099609375,-0.0033473968505859375,0.0186920166015625,-0.0225067138671875,0.0125732421875,-0.01386260986328125,-0.0218658447265625,0.01248931884765625,0.025848388671875,0.021453857421875,0.008056640625,0.025421142578125,0.01224517822265625,0.0208740234375,-0.003856658935546875,-0.021209716796875,-0.00545501708984375,-0.0254058837890625,0.04388427734375,0.0204315185546875,-0.0072174072265625,-0.0110626220703125,0.0007481575012207031,-0.0022411346435546875,-0.046905517578125,-0.028472900390625,0.0196533203125,0.014129638671875,0.0130615234375,-0.01288604736328125,-0.03607177734375,-0.01568603515625,-0.00814056396484375,-0.01499176025390625,0.0112152099609375,-0.00360870361328125,0.024688720703125,-0.0189361572265625,-0.007122039794921875,0.00634002685546875,-0.00626373291015625,-0.000766754150390625,0.0193939208984375,-0.002841949462890625,0.041717529296875,-0.00016701221466064453,-0.043365478515625,-0.023773193359375,0.0283660888671875,0.0245208740234375,-0.055450439453125,0.01096343994140625,-0.0180511474609375,0.0189056396484375,0.0164947509765625,-0.033111572265625,0.0262603759765625,0.0294189453125,0.00084686279296875,0.0279388427734375,-0.003910064697265625,0.002910614013671875,0.00890350341796875,-0.033843994140625,0.004856109619140625,0.00033974647521972656,-0.056549072265625,-0.0110626220703125,-0.0178375244140625,0.006381988525390625,0.018798828125,0.0205230712890625,-0.05609130859375,-0.01023101806640625,-0.001201629638671875,-0.02227783203125,0.01910400390625,0.006931304931640625,0.0017032623291015625,-0.01849365234375,-0.0249786376953125,-0.0176849365234375,0.007389068603515625,-0.01025390625,0.036407470703125,-0.0275421142578125,0.021514892578125,-0.0198822021484375,-0.0189056396484375,-0.0156402587890625,0.01025390625,0.02197265625,-0.007740020751953125,-0.034515380859375,0.0011262893676757812,0.024566650390625,0.0229339599609375,0.004810333251953125,-0.01171875,-0.0238189697265625,0.021392822265625,0.0008301734924316406,0.019378662109375,-0.00894927978515625,-0.01496124267578125,0.01558685302734375,-0.0229339599609375,0.00020587444305419922,-0.0202178955078125,0.0298919677734375,0.00969696044921875,-0.0011949539184570312,-0.007144927978515625,-0.0198211669921875,0.0030422210693359375,-0.037811279296875,-0.039306640625,-0.027587890625,-0.0274810791015625,0.025390625,-0.0333251953125,-0.0062103271484375,-0.016876220703125,0.002651214599609375,-0.0020275115966796875,0.042144775390625,0.013092041015625,0.01690673828125,0.0268707275390625,0.0082244873046875,0.066650390625,0.0053253173828125,0.08526611328125,-0.0146331787109375,-0.0261688232421875,-0.04266357421875,0.004474639892578125,-0.005229949951171875,-0.01806640625,0.00479888916015625,0.00183868408203125,-0.01030731201171875,0.0028285980224609375,-0.0239410400390625,0.0166778564453125,0.0006723403930664062,-0.00923919677734375,-0.00504302978515625,0.0159759521484375,-0.0248260498046875,0.03179931640625,-0.01517486572265625,-0.0006771087646484375,-0.0117645263671875,0.016510009765625,0.00168609619140625,-0.016387939453125,0.0421142578125,-0.00951385498046875,-0.00388336181640625,-0.04559326171875,-0.0194091796875,0.043853759765625,-0.007541656494140625,0.0275421142578125,-0.005645751953125,0.003803253173828125,-0.01438140869140625,0.018218994140625,-0.006381988525390625,-0.012664794921875,-0.011962890625,0.035186767578125,0.0225067138671875,-0.005321502685546875,-0.007659912109375,0.0022792816162109375,-0.00830078125,-0.0092926025390625,-0.0278778076171875,-0.00011402368545532227,0.0027523040771484375,0.0082855224609375,0.0175933837890625,0.0029430389404296875,0.0721435546875,0.01525115966796875,-0.059967041015625,-0.0626220703125,0.0222625732421875,-0.05810546875,-0.01192474365234375,-0.0056610107421875,0.0173492431640625,-0.0008497238159179688,-0.01050567626953125,-0.01558685302734375,0.0032196044921875,0.00745391845703125,-0.05029296875,0.00310516357421875,0.0333251953125,-0.01166534423828125,-0.0347900390625,-0.00830078125,0.01305389404296875,0.01030731201171875,0.017730712890625,-0.007415771484375,-0.00287628173828125,0.01197052001953125,-0.004016876220703125,-0.038421630859375,0.000743865966796875,-0.006237030029296875,0.0511474609375,-0.003826141357421875,-0.00838470458984375,-0.007572174072265625,0.00522613525390625,0.01514434814453125,0.00557708740234375,-0.035186767578125,0.0077056884765625,-0.0330810546875,-0.0043487548828125,-0.0307464599609375,-0.00670623779296875,0.01395416259765625,-0.0247039794921875,-0.03399658203125,0.0176849365234375,-0.00827789306640625,-0.0132293701171875,0.011016845703125,0.00740814208984375,-0.022735595703125,0.01110076904296875,-0.0127105712890625,-0.01074981689453125,-0.04150390625,-0.05438232421875,-0.0014743804931640625,-0.00507354736328125,-0.05291748046875,-0.0126800537109375,0.032135009765625,0.0266571044921875,-0.0240020751953125,-0.0033702850341796875,0.0021076202392578125,0.0206756591796875,0.01454925537109375,-0.00954437255859375,0.0178680419921875,0.004734039306640625,-0.0014028549194335938,0.0109710693359375,-0.0200042724609375,-0.030029296875,0.04022216796875,-0.0190887451171875,0.028594970703125,0.0205841064453125,-0.0028095245361328125,0.0024242401123046875,-0.0151214599609375,0.0025386810302734375,-0.006633758544921875,0.01265716552734375,-0.019073486328125,0.0030384063720703125,-0.024871826171875,-0.01148223876953125,0.00914764404296875,-0.004367828369140625,-0.0186920166015625,0.021514892578125,-0.027435302734375,0.00736236572265625,0.037872314453125,-0.00222015380859375,0.0041351318359375,-0.0224151611328125,-0.0255279541015625,0.03271484375,-0.0242919921875,0.0097198486328125,-0.02008056640625,-0.01003265380859375,-0.0215606689453125,-0.00974273681640625,-0.0428466796875,-0.0343017578125,-0.0006017684936523438,-0.0230865478515625,0.020782470703125,0.01134490966796875,0.0107421875,-0.0165863037109375,-0.0043487548828125,0.0165252685546875,0.0276947021484375,0.0051116943359375,0.03497314453125,0.0288848876953125,0.0205230712890625,-0.0099029541015625,0.0014505386352539062,-0.045074462890625,-0.0226898193359375,0.002422332763671875,0.0013151168823242188,-0.0031642913818359375,-0.0247344970703125,0.013885498046875,-0.002410888671875,0.046051025390625,0.0328369140625,0.04193115234375,0.006710052490234375,-0.004138946533203125,-0.031768798828125,0.024658203125,0.00417327880859375,-0.01116943359375,0.0097198486328125,-0.021270751953125,0.0285491943359375,0.02581787109375,0.0167083740234375,0.0206298828125,0.009185791015625,0.00794219970703125,-0.0022792816162109375,0.004337310791015625,-0.01166534423828125,-0.01227569580078125,0.00905609130859375,0.0156707763671875,-0.04217529296875,0.025054931640625,-0.01058197021484375,0.0171356201171875,0.001369476318359375,0.003917694091796875,-0.00817108154296875,0.026123046875,0.0200042724609375,-0.0294189453125,0.032440185546875,-0.0297393798828125,-0.0109100341796875,-0.00856781005859375,0.0034465789794921875,0.0186920166015625,0.0199737548828125,-0.03558349609375,-0.025146484375,-0.009307861328125,0.0081024169921875,0.0131378173828125,0.0117340087890625,0.0063018798828125,0.0000546574592590332,0.01898193359375,-0.0167694091796875,0.01666259765625,0.0374755859375,0.02374267578125,-0.0103912353515625,0.01207733154296875,-0.032989501953125,-0.004108428955078125,-0.0026798248291015625,0.01166534423828125,0.0257568359375,-0.056732177734375,0.0282745361328125,-0.0034351348876953125,-0.007415771484375,0.0081634521484375,0.029998779296875,0.0019369125366210938,-0.0014734268188476562,0.004573822021484375,0.04296875,0.025665283203125,-0.0121307373046875,0.029266357421875,0.016815185546875,-0.002536773681640625,-0.015045166015625,-0.0211334228515625,0.0020351409912109375,0.008087158203125,-0.004528045654296875,-0.0172882080078125,0.023712158203125,0.0305633544921875,0.0213470458984375,-0.0154266357421875,-0.035675048828125,0.0002543926239013672,0.01149749755859375,0.00833892822265625,0.01506805419921875,0.019500732421875,-0.01265716552734375,0.01947021484375,0.0242767333984375,-0.017486572265625,-0.01294708251953125,-0.012603759765625,-0.0093994140625,-0.00226593017578125,0.020355224609375,-0.0369873046875,0.0166168212890625,0.034332275390625,-0.0240631103515625,-0.03558349609375,0.036376953125,-0.009246826171875,0.0041656494140625,0.0439453125,-0.023284912109375,0.004749298095703125,-0.0232391357421875,-0.0105743408203125,-0.01030731201171875,-0.01318359375,0.0220184326171875,0.005840301513671875,0.0217437744140625,-0.01007080078125,0.01398468017578125,0.0019063949584960938,-0.011383056640625,-0.00424957275390625,-0.0208282470703125,0.012237548828125,0.01526641845703125,0.00959014892578125,0.027191162109375,0.001735687255859375,0.0177154541015625,-0.01139068603515625,0.0218963623046875,0.03814697265625,-0.018951416015625,0.011016845703125,-0.01287078857421875,0.046875,-0.007415771484375,0.01198577880859375,-0.02532958984375,0.00311279296875,0.018524169921875,0.005390167236328125,-0.01435089111328125,0.0018949508666992188,0.0421142578125,0.0045928955078125,-0.006099700927734375,0.007049560546875,0.00502777099609375,-0.00963592529296875,0.00894927978515625,-0.034515380859375,-0.0035114288330078125,-0.0142974853515625,-0.034515380859375,-0.02142333984375,0.017608642578125,-0.014892578125,-0.01244354248046875,-0.017486572265625,0.00013899803161621094,0.00011283159255981445,-0.00756072998046875,-0.0132293701171875,0.0108489990234375,0.0305328369140625,-0.001163482666015625,-0.002880096435546875,-0.0007386207580566406,0.00370025634765625,0.00797271728515625,-0.010528564453125,-0.0073089599609375,-0.0279693603515625,-0.01343536376953125,-0.005908966064453125,-0.0003764629364013672,0.053955078125,0.0237884521484375,-0.053497314453125,-0.01165771484375,-0.037628173828125,0.0099639892578125,-0.02386474609375,0.032958984375,0.0239715576171875,0.0016231536865234375,-0.033111572265625,0.0007448196411132812,0.0245819091796875,-0.0094757080078125,-0.03131103515625,-0.02459716796875,0.021453857421875,0.01398468017578125,-0.0017442703247070312,0.054107666015625,0.0193328857421875,0.0057373046875,0.03485107421875,0.0258636474609375,0.004131317138671875,-0.02239990234375,-0.002368927001953125,0.01102447509765625,-0.017181396484375,0.01454925537109375,-0.0119781494140625,-0.0017871856689453125,-0.0166778564453125,0.008544921875,-0.0135345458984375,-0.03192138671875,0.0030956268310546875,-0.0279083251953125,0.0235595703125,-0.017974853515625,0.0108184814453125,0.0031032562255859375,-0.003093719482421875,-0.014129638671875,0.01361083984375,-0.03619384765625,-0.00826263427734375,0.033477783203125,-0.004150390625,0.0157012939453125,0.0011501312255859375,0.059844970703125,-0.01555633544921875,0.031219482421875,0.0177001953125,-0.0307464599609375,0.01264190673828125,0.0291290283203125,0.01045989990234375,-0.0097503662109375,0.01226806640625,0.00598907470703125,0.01849365234375,-0.02801513671875,-0.0112152099609375,-0.006011962890625,-0.006664276123046875,0.00928497314453125,0.0002186298370361328,-0.0012874603271484375,-0.0233001708984375,-0.0065155029296875,-0.0220947265625,-0.00310516357421875,0.049041748046875,-0.04925537109375,0.0262451171875,-0.0028095245361328125,-0.0091400146484375,0.0240631103515625,-0.002864837646484375,0.0120391845703125,-0.021942138671875,0.0347900390625,0.023834228515625,-0.0134429931640625,0.00028228759765625,0.0277557373046875,0.03082275390625,0.006237030029296875,-0.015350341796875,-0.005039215087890625,0.0145416259765625,0.01226806640625,-0.01474761962890625,-0.004917144775390625,-0.005733489990234375,-0.010986328125,0.0223236083984375,0.0224609375,-0.035736083984375,-0.008544921875,-0.0009150505065917969,-0.0119476318359375,0.0178070068359375,-0.005352020263671875,-0.01558685302734375,-0.0208740234375,-0.0160675048828125,0.0069122314453125,-0.0357666015625,0.01319122314453125,-0.00457000732421875,0.00502777099609375,-0.0006170272827148438,0.0032196044921875,-0.008209228515625,0.0026721954345703125,-0.022705078125,0.01666259765625,-0.0217132568359375,-0.024017333984375,-0.00527191162109375,0.0005908012390136719,0.0028228759765625,-0.0205841064453125,-0.05108642578125,0.02947998046875,-0.00861358642578125,-0.035552978515625,-0.0090484619140625,-0.044464111328125,-0.0284881591796875,0.004901885986328125,0.00669097900390625,0.020538330078125,0.01218414306640625,0.01477813720703125,0.0011930465698242188,0.027587890625,-0.037811279296875,0.0273284912109375,-0.0006680488586425781,0.0179901123046875,0.047393798828125,0.033355712890625,-0.018646240234375,-0.031585693359375,-0.0190887451171875,0.0059051513671875,-0.005916595458984375,0.0247802734375,0.00881195068359375,-0.004108428955078125,-0.0091552734375,0.021697998046875,-0.0207061767578125,0.0207977294921875,-0.048095703125,-0.01544189453125,0.015533447265625,0.0228424072265625,0.0255126953125,-0.0172119140625,-0.0450439453125,0.0005936622619628906,0.0027103424072265625,0.03704833984375,-0.018218994140625,-0.00972747802734375,0.0067901611328125,-0.000598907470703125,-0.00482940673828125,-0.00786590576171875,0.0011510848999023438,0.0364990234375,-0.0128631591796875,-0.0198822021484375,0.0000896453857421875,-0.022735595703125,0.01479339599609375,-0.0034351348876953125,0.0120086669921875,0.0070037841796875,-0.01971435546875,0.04010009765625,0.0034389495849609375,-0.0109100341796875,0.01395416259765625,0.03509521484375,0.01096343994140625,-0.0209808349609375,-0.0009293556213378906,-0.00043487548828125,0.005519866943359375,-0.016448974609375,0.032470703125,0.0284881591796875,0.0144195556640625,-0.0307464599609375,0.0217437744140625,-0.0303497314453125,-0.05926513671875,0.01444244384765625,-0.01264190673828125,0.040313720703125,-0.012603759765625,-0.0178375244140625,-0.04339599609375,0.01222991943359375,-0.0025005340576171875,-0.010406494140625,-0.003086090087890625,-0.0214385986328125,0.01045989990234375,0.005886077880859375,-0.0175933837890625,0.04840087890625,-0.0168914794921875,0.01800537109375,-0.01354217529296875,-0.01383209228515625,0.04083251953125,0.034271240234375,0.021514892578125,0.04022216796875,0.0231781005859375,-0.01110076904296875,-0.0224151611328125,0.0021991729736328125,-0.01206207275390625,-0.01557159423828125,0.0548095703125,0.02618408203125,0.023956298828125,-0.00994110107421875,-0.004299163818359375,0.007030487060546875,-0.0113372802734375,0.0140228271484375,-0.01084136962890625,0.010711669921875,-0.0236358642578125,0.01776123046875,0.04461669921875,-0.0460205078125,-0.012969970703125,0.0078277587890625,-0.040313720703125,-0.004344940185546875,-0.00681304931640625,-0.00937652587890625,0.00601959228515625,-0.0086669921875,0.038238525390625,-0.00726318359375,-0.00667572021484375,-0.0282745361328125,-0.01448822021484375,-0.004566192626953125,0.002193450927734375,0.0408935546875,-0.018951416015625,-0.0347900390625,-0.0038661956787109375,0.0011167526245117188,0.00603485107421875,0.004985809326171875,0.004299163818359375,0.009552001953125,-0.04736328125,0.018310546875,0.004238128662109375,0.028839111328125,-0.02349853515625,0.00798797607421875,0.021270751953125,-0.01384735107421875,-0.02392578125,0.03662109375,0.0032825469970703125,0.056182861328125,-0.007129669189453125,-0.0014019012451171875,0.030426025390625,-0.017974853515625,-0.0118560791015625,0.0104827880859375,-0.0132293701171875,0.01959228515625,-0.0006871223449707031,-0.038055419921875,0.03125,0.01332855224609375,0.0675048828125,0.0005002021789550781,0.0117950439453125,0.0179901123046875,-0.0034618377685546875,-0.029205322265625,0.0136871337890625,-0.01409149169921875,-0.020111083984375,-0.06976318359375,-0.03985595703125,-0.020965576171875,0.002532958984375,-0.000797271728515625,0.00029206275939941406,-0.04278564453125,0.01293182373046875,-0.0178375244140625,-0.01496124267578125,-0.0289154052734375,-0.00551605224609375,-0.0135498046875,-0.0019350051879882812,-0.0008111000061035156,0.032958984375,0.005794525146484375,-0.00988006591796875,0.0147247314453125,0.0008878707885742188,-0.0347900390625,0.04827880859375,0.03656005859375,0.0005245208740234375,0.0078887939453125,0.0218048095703125,0.0177764892578125,0.02093505859375,-0.028656005859375,0.0273284912109375,-0.038818359375,0.01300811767578125,0.0174102783203125,0.01216888427734375,-0.0258941650390625,0.028778076171875,-0.024658203125,0.00337982177734375,-0.00594329833984375,-0.00948333740234375,0.036773681640625,-0.006595611572265625,-0.01033782958984375,0.001506805419921875,-0.03656005859375,-0.0239105224609375,0.041229248046875,-0.04071044921875,-0.0152435302734375,0.0151214599609375,0.037994384765625,-0.01058197021484375,-0.01062774658203125,0.002964019775390625,0.0294189453125,0.01041412353515625,0.038299560546875,-0.036163330078125,-0.036346435546875,-0.00850677490234375,-0.0098876953125,-0.051788330078125,0.02398681640625,-0.0219268798828125,0.023406982421875,0.008941650390625,0.010772705078125,-0.0265960693359375,-0.0099639892578125,-0.00727081298828125,0.0234222412109375,0.0023441314697265625,-0.01409912109375,0.01169586181640625,0.0023250579833984375,-0.0189208984375,-0.01013946533203125,-0.01739501953125,-0.0309295654296875,-0.00823974609375,0.029205322265625,0.01111602783203125,-0.01509857177734375,-0.01160430908203125,0.0173187255859375,0.0169830322265625,-0.00464630126953125,0.0253448486328125,0.0095062255859375,-0.0179443359375,0.0223846435546875,-0.0219879150390625,-0.0004260540008544922,-0.025421142578125,-0.007659912109375,-0.01485443115234375,-0.0166168212890625,0.011444091796875,0.0185394287109375,-0.02984619140625,0.061767578125,0.0189971923828125,-0.016693115234375,0.002613067626953125,-0.01242828369140625,0.0262298583984375,0.029388427734375,-0.0711669921875,-0.0263519287109375,0.01184844970703125,0.00977325439453125,-0.0232696533203125,-0.0131072998046875,0.00910186767578125,0.0251617431640625,0.04644775390625,-0.00033926963806152344,0.00894927978515625,0.01216888427734375,-0.00942230224609375,0.01220703125,0.002918243408203125,0.0167694091796875,0.0286865234375,0.01436614990234375,-0.02581787109375,-0.0123138427734375,-0.0143890380859375,0.0200042724609375,-0.020660400390625,-0.017791748046875,-0.006740570068359375,0.02484130859375,-0.028472900390625,-0.0142364501953125,-0.007534027099609375,0.021697998046875,-0.013580322265625,-0.003910064697265625,0.01214599609375,-0.01267242431640625,-0.005466461181640625,0.0239410400390625,0.01348876953125,0.0171661376953125,-0.00982666015625,-0.009613037109375,0.0189208984375,-0.01146697998046875,-0.01364898681640625,-0.021820068359375,-0.017181396484375,0.0097503662109375,-0.0240478515625,0.031829833984375,0.0172271728515625,0.01308441162109375,0.006938934326171875,0.0212249755859375,-0.007843017578125,-0.041839599609375,0.003757476806640625,-0.01332855224609375,-0.0081024169921875,-0.0252227783203125,0.0125732421875,0.00164794921875,-0.009490966796875,-0.0182647705078125,-0.03497314453125,-0.0187225341796875,-0.001026153564453125,-0.06793212890625,-0.05291748046875,-0.0297393798828125,-0.005031585693359375,-0.026519775390625,-0.00891876220703125,0.0096893310546875,-0.0189056396484375,0.01444244384765625,-0.0270233154296875,-0.0010528564453125,0.006771087646484375,-0.00942230224609375,0.03399658203125,-0.0203094482421875,-0.004795074462890625,0.0025959014892578125,0.01538848876953125,-0.00620269775390625,-0.035675048828125,-0.01142120361328125,0.0011234283447265625,-0.0278778076171875,0.00807952880859375,-0.017547607421875,0.0211639404296875,0.037139892578125,-0.0108642578125,-0.0287017822265625,-0.0008664131164550781,-0.00862884521484375,-0.006320953369140625,-0.00901031494140625,-0.012451171875,0.017913818359375,0.005092620849609375,-0.04345703125,-0.027801513671875,0.023040771484375,0.007328033447265625,-0.013916015625,-0.007678985595703125,-0.0031185150146484375,0.01546478271484375,0.02020263671875,-0.01259613037109375,0.0040130615234375,0.005023956298828125,0.00421142578125,-0.0018835067749023438,0.0369873046875,-0.0006284713745117188,0.007049560546875,-0.0213165283203125,-0.02215576171875,-0.05023193359375,-0.006420135498046875,0.001811981201171875,0.01995849609375,0.007694244384765625,-0.0081329345703125,-0.0347900390625,0.01042938232421875,-0.03131103515625,0.0312042236328125,-0.00971221923828125,-0.0352783203125,0.021209716796875,-0.009490966796875,0.00710296630859375,-0.004848480224609375,-0.01030731201171875,0.0037136077880859375,0.0234222412109375,0.004337310791015625,-0.03436279296875,0.0008835792541503906,-0.036712646484375,0.007740020751953125,0.003978729248046875,-0.0178985595703125,-0.0027065277099609375,0.035491943359375,0.01148223876953125,0.01496124267578125,-0.0025386810302734375,0.014404296875,0.007572174072265625,0.016876220703125,-0.0023212432861328125,0.002727508544921875,-0.005374908447265625,0.01690673828125,-0.020599365234375,-0.00002384185791015625,0.0305328369140625,-0.052734375,0.01496124267578125,0.0039215087890625,-0.00762176513671875,0.031585693359375,-0.01617431640625,-0.01222991943359375,0.00873565673828125,-0.033966064453125,0.01061248779296875,-0.0209197998046875,-0.0198516845703125,0.035247802734375,0.0244598388671875,0.0082550048828125,-0.00787353515625,-0.01544952392578125,0.01302337646484375,-0.0166168212890625,-0.0147247314453125,0.02618408203125,-0.0158233642578125,-0.0394287109375,0.0151214599609375,-0.004146575927734375,-0.035369873046875,0.045928955078125,0.04241943359375,0.01354217529296875,0.0343017578125,-0.007183074951171875,0.0129241943359375,-0.004955291748046875,0.025299072265625,0.01538848876953125,-0.0054779052734375,-0.00630950927734375,-0.010711669921875,0.043914794921875,-0.004856109619140625,0.05169677734375,-0.020111083984375,0.023406982421875,-0.0021114349365234375,-0.039215087890625,-0.01314544677734375,-0.0036773681640625,0.01031494140625,-0.00981903076171875,0.01366424560546875,0.0101776123046875,0.0274658203125,-0.0386962890625,0.0194244384765625,-0.04803466796875,0.033172607421875,0.0269775390625,-0.0176849365234375,-0.0016927719116210938,-0.02783203125,0.0015516281127929688,0.01325225830078125,-0.028472900390625,0.01470947265625,0.036773681640625,-0.038482666015625,-0.0009303092956542969,0.0236053466796875,-0.00498199462890625,0.0165557861328125,0.00003445148468017578,-0.03741455078125,-0.0517578125,-0.0090179443359375,-0.033966064453125,-0.0170440673828125,0.0013637542724609375,-0.04473876953125,-0.059478759765625,-0.0165557861328125,-0.047119140625,-0.033721923828125,0.018890380859375,0.00160980224609375,0.050811767578125,-0.0221099853515625,0.0306396484375,-0.01096343994140625,-0.007175445556640625,0.01580810546875,-0.00650787353515625,-0.00467681884765625,0.0256500244140625,0.006931304931640625,0.00316619873046875,-0.0170745849609375,-0.003265380859375,0.00554656982421875,-0.0166473388671875,0.0006661415100097656,0.0297393798828125,-0.00568389892578125,0.01043701171875,-0.03863525390625,0.01531982421875,0.021087646484375,0.002185821533203125,0.00977325439453125,-0.028594970703125,-0.0166473388671875,-0.00018537044525146484,-0.0014066696166992188,0.014312744140625,0.025299072265625,-0.0149383544921875,0.001495361328125,0.03692626953125,0.00438690185546875,0.05572509765625,-0.00350189208984375,0.0156402587890625,0.005992889404296875,-0.005748748779296875,-0.01739501953125,0.017059326171875,0.0006203651428222656,-0.0163726806640625,-0.0203704833984375,-0.005962371826171875,0.006130218505859375,-0.00022983551025390625,-0.014007568359375,-0.0025844573974609375,-0.0171356201171875,0.0130157470703125,-0.005809783935546875,0.0174560546875,-0.0196075439453125,-0.017486572265625,-0.035369873046875,0.0016012191772460938,-0.02008056640625,-0.0213775634765625,0.04119873046875,-0.0125732421875,-0.00983428955078125,0.01010894775390625,-0.01099395751953125,-0.009613037109375,-0.01091766357421875,0.0032520294189453125,-0.004924774169921875,-0.041656494140625,0.01227569580078125,0.011077880859375,-0.040740966796875,0.002017974853515625,-0.0193023681640625,0.014739990234375,-0.0018491744995117188,0.008636474609375,0.017791748046875,-0.0012598037719726562,-0.004123687744140625,-0.006511688232421875,-0.0179443359375,-0.03619384765625,-0.0009822845458984375,0.0066680908203125,-0.0012950897216796875,0.0031185150146484375,-0.05401611328125,0.0266876220703125,-0.035308837890625,-0.0234375,0.0234222412109375,-0.037384033203125,0.002349853515625,0.01290130615234375,-0.0321044921875,0.019622802734375,-0.052337646484375,-0.00556182861328125,0.005496978759765625,0.0078125,0.010101318359375,-0.0055084228515625,0.021087646484375,0.016754150390625,0.0192413330078125,-0.024261474609375,0.0457763671875,-0.0185394287109375,0.0007729530334472656,0.0173187255859375,0.0224456787109375,0.0283355712890625,0.00576019287109375,0.04150390625,-0.005279541015625,0.01000213623046875,0.01496124267578125,0.003604888916015625,-0.033447265625,0.013824462890625,-0.0014410018920898438,-0.0225067138671875,-0.0017547607421875,0.0235443115234375,0.0171966552734375,0.0234375,-0.00482177734375,-0.0062103271484375,0.01885986328125,-0.003917694091796875,0.0172119140625,0.0240478515625,-0.006069183349609375,-0.0166015625,-0.00955963134765625,-0.01861572265625,0.0198822021484375,-0.046875,-0.0011920928955078125,-0.00972747802734375,0.01349639892578125,-0.00629425048828125,-0.0087738037109375,0.01393890380859375,0.0006022453308105469,-0.007038116455078125,-0.017181396484375,-0.00965118408203125,0.0133514404296875,-0.0025787353515625,0.017547607421875,-0.0276641845703125,0.018890380859375,0.01517486572265625,-0.0311737060546875,-0.016815185546875,0.00264739990234375,-0.0214080810546875,0.0181884765625,-0.01145172119140625,-0.0011072158813476562,0.02880859375,0.00782012939453125,-0.0238037109375,0.039031982421875,-0.00690460205078125,0.0018301010131835938,0.0305023193359375,0.005344390869140625,-0.003803253173828125,-0.033782958984375,0.01241302490234375,0.0206146240234375,0.00766754150390625,0.0177459716796875,-0.002201080322265625,-0.01444244384765625,0.031402587890625,-0.04498291015625,-0.02203369140625,-0.017486572265625,0.031341552734375,0.032562255859375,-0.031951904296875,0.0182037353515625,-0.01207733154296875,0.0235748291015625,0.0391845703125,0.00971221923828125,0.029388427734375,-0.038360595703125,0.025726318359375,-0.0040435791015625,0.020233154296875,0.0009427070617675781,0.0347900390625,-0.0226287841796875,0.01318359375,0.01505279541015625,0.01042938232421875,-0.011749267578125,-0.022705078125,-0.006938934326171875,0.008087158203125,-0.00205230712890625,-0.018463134765625,0.02960205078125,-0.0309600830078125,-0.024749755859375,0.004817962646484375,-0.01258087158203125,0.00850677490234375,-0.00560760498046875,-0.021881103515625,-0.004638671875,0.0244903564453125,-0.020416259765625,0.02655029296875,-0.0226287841796875,0.030029296875,0.024139404296875,0.03497314453125,0.0161285400390625,0.0206756591796875,-0.040924072265625,0.01042938232421875,0.048126220703125,0.006565093994140625,-0.00260162353515625,0.037139892578125,0.0006361007690429688,-0.01007843017578125,0.0282745361328125,-0.013702392578125,0.044525146484375,-0.006237030029296875,0.034637451171875,0.0285186767578125,0.0124053955078125,-0.034423828125,0.0007100105285644531,-0.045501708984375,-0.0219268798828125,-0.00836181640625,-0.03704833984375,-0.07000732421875,0.006748199462890625,-0.0036602020263671875,0.00751495361328125,-0.0162353515625,-0.0137176513671875,0.0227203369140625,0.001644134521484375,-0.028656005859375,-0.00397491455078125,-0.0088043212890625,-0.0007772445678710938,0.035797119140625,0.0389404296875,0.0380859375,-0.005031585693359375,0.0059967041015625,-0.016815185546875,-0.0027980804443359375,0.0127410888671875,0.03399658203125,-0.0003867149353027344,0.00679779052734375,-0.0079193115234375,-0.02294921875,0.023101806640625,0.0009560585021972656,0.042694091796875,-0.031768798828125,-0.00247955322265625,0.0197296142578125,0.0196075439453125,-0.0229339599609375,-0.0250396728515625,-0.0006723403930664062,0.011871337890625,0.0308990478515625,0.002803802490234375,0.003803253173828125,-0.0112762451171875,0.0016689300537109375,-0.040985107421875,0.0175933837890625,0.029083251953125,-0.00962066650390625,-0.0384521484375,-0.006683349609375,0.00439453125,0.0269012451171875,0.02252197265625,-0.027587890625,0.003749847412109375,-0.004119873046875,-0.015228271484375,-0.031036376953125,-0.0042724609375,-0.043853759765625,-0.0016918182373046875,-0.015411376953125,0.03643798828125,-0.03814697265625,0.020599365234375,-0.007030487060546875,-0.02532958984375,-0.0216522216796875,0.0016412734985351562,0.00982666015625,0.0205230712890625,0.02484130859375,0.0078887939453125,-0.0261077880859375,0.0247039794921875,-0.01251983642578125,0.0090789794921875,0.013092041015625,0.0082550048828125,0.006603240966796875,-0.00423431396484375,0.01424407958984375,0.01349639892578125,-0.02264404296875,0.0236358642578125,-0.001506805419921875,0.007030487060546875,-0.01727294921875,-0.0249481201171875,-0.00611114501953125,0.0177459716796875,-0.0077056884765625,0.023773193359375,0.01357269287109375,0.012237548828125,0.0338134765625,-0.029022216796875,0.02880859375,-0.0018472671508789062,-0.024139404296875,-0.032989501953125,0.055084228515625,0.02984619140625,0.040618896484375,0.0006160736083984375,0.03814697265625,0.022552490234375,-0.01071929931640625,0.0250091552734375,0.033782958984375,0.00806427001953125,-0.005443572998046875,-0.00899505615234375,-0.00969696044921875,0.01045989990234375,0.037384033203125,0.01308441162109375,-0.01435089111328125,-0.0032367706298828125,0.0186004638671875,-0.0330810546875,-0.014617919921875,0.01088714599609375,-0.00847625732421875,0.02984619140625,-0.0283355712890625,0.023162841796875,0.019134521484375,-0.01218414306640625,-0.033966064453125,-0.028839111328125,-0.022552490234375,-0.02001953125,0.005214691162109375,-0.01418304443359375,0.0035915374755859375,-0.011993408203125,0.0076751708984375,-0.0098876953125,-0.002002716064453125,-0.0008831024169921875,-0.01294708251953125,-0.05120849609375,0.0008082389831542969,0.0205535888671875,-0.0017843246459960938,0.006366729736328125,0.0137939453125,0.060699462890625,-0.0177459716796875,-0.005641937255859375,0.0170440673828125,0.0026397705078125,0.009857177734375,-0.024658203125,0.006175994873046875,0.04205322265625,0.0253143310546875,0.00972747802734375,0.0031375885009765625,-0.022064208984375,0.0006480216979980469,-0.004180908203125,-0.00794219970703125,-0.015106201171875,-0.00901031494140625,-0.00812530517578125,-0.01406097412109375,-0.0247039794921875,-0.0221405029296875,0.025543212890625,0.037353515625,-0.01702880859375,-0.0021762847900390625,0.0237274169921875,0.016632080078125,-0.0335693359375,0.002178192138671875,-0.022705078125,-0.011810302734375,0.01666259765625,0.0287628173828125,-0.02313232421875,-0.011199951171875,0.026702880859375,-0.0195770263671875,0.0278778076171875,0.0106658935546875,-0.0199432373046875,-0.035919189453125,0.028656005859375,0.0009784698486328125,-0.004291534423828125,-0.0309906005859375,0.03277587890625,0.011260986328125,0.0112457275390625,-0.034698486328125,-0.01111602783203125,0.0309906005859375,0.042236328125],"object":"embedding"}],"model":"nvidia/llama-3.2-nv-embedqa-1b-v2","usage":{"prompt_tokens":10,"total_tokens":10}} -``` - -{{% /tab %}} -{{< /tabs >}} diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md b/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md deleted file mode 100644 index b2fc397460..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: ベクターデータベースのデプロイ -linkTitle: 8. ベクターデータベースのデプロイ -weight: 8 -time: 10 minutes ---- - -このステップでは、OpenShift クラスターにベクターデータベースをデプロイし、ワークショップ参加者が使用するテストデータを投入します。 - -## ベクターデータベースのデプロイ - -このワークショップでは、オープンソースのベクターデータベースである [Weaviate](https://weaviate.io/) をデプロイします。 - -まず、Weaviate の Helm チャートを含む Weaviate Helm リポジトリを追加します。 - -``` bash -helm repo add weaviate https://weaviate.github.io/weaviate-helm -helm repo update -``` - -`weaviate/weaviate-values.yaml` ファイルには、Weaviate ベクターデータベースのデプロイに使用する設定が含まれています。 - -Weaviate が Prometheus receiverでスクレイピングできるメトリクスを公開するように、以下の環境変数を `TRUE` に設定しています。 - -```` - PROMETHEUS_MONITORING_ENABLED: true - PROMETHEUS_MONITORING_GROUP: true -```` - -追加のカスタマイズオプションについては、[Weaviate のドキュメント](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 -``` - -## ベクターデータベースへのデータ投入 - -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` の設定に従い、[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 をデプロイしてエンベディングをロードします。 -このプロセスが1回だけ実行されるようにするために、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/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md b/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md deleted file mode 100644 index d232a7a08d..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -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="スクリプト" %}} - -``` bash -curl http://portworx-metrics-sim.portworx:17001/metrics -``` - -{{% /tab %}} -{{% tab title="出力例" %}} - -``` 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/14-cisco-ai-pods/1-workshop-setup/_index.md b/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/_index.md deleted file mode 100644 index a29bb79be5..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: ワークショップセットアップ -linkTitle: 1. ワークショップセットアップ -weight: 1 ---- - -このセクションには、ワークショップ主催者がワークショップをセットアップするために実行する手順が含まれています： - -* AWS アカウントのセットアップ -* OpenShift の前提条件 -* AWS ROSA を使用して、GPU ベースのワーカーノードを持つ **Red Hat OpenShift** クラスターをデプロイします。 -* **NVIDIA NIM Operator** と **NVIDIA GPU Operator** をデプロイします。 -* NVIDIA NIM を使用して **大規模言語モデル（LLM）** をクラスターにデプロイします。 -* 適切な権限を持つ各ワークショップユーザー用の OpenShift ログインとネームスペースを作成します。 -* **Splunk OpenTelemetry Collector** の Cluster Receiver コンポーネントをインストールします。 -* クラスターに **Weaviate ベクトルデータベース** をデプロイします。 -* **Portworx Prometheus exporter** を模倣するサービスをデプロイします。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md deleted file mode 100644 index 75c39e3ab0..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: ワークショップ環境の概要 -linkTitle: 1. ワークショップ環境の概要 -weight: 1 -time: 5 minutes ---- - -**Cisco の AI 対応 POD** は、最先端のハードウェアとソフトウェアを組み合わせて、堅牢でスケーラブルかつ効率的な AI インフラストラクチャを提供します。 -**Splunk Observability Cloud** は、インフラストラクチャからアプリケーションコンポーネントまで、このスタック全体に対する包括的な可視性を提供します。 - -このハンズオンワークショップでは、OpenTelemetry と Prometheus を使用して AI インフラストラクチャをモニタリングする方法を学びます。**実際の Cisco AI POD へのアクセスは不要です**。現実的な環境でモニタリング技術のデプロイと設定に関する実践的な経験を得ることができます。 - -## ラボ環境 - -このワークショップでは、AWS 上で動作する共有の **OpenShift クラスター** を使用します。このクラスターには NVIDIA GPU と NVIDIA AI Enterprise ソフトウェアが搭載されています。 - -### デプロイ済みのインフラストラクチャ - -ワークショップの講師が、以下の共有コンポーネントをワークショップ環境にデプロイ済みです。 - -* **NVIDIA NIM モデル**: - * `meta/llama-3.2-1b-instruct` - ユーザーのプロンプトを処理 - * `nvidia/llama-3.2-nv-embedqa-1b-v2` - エンベディングを生成 -* **Weaviate** - セマンティック検索と検索取得のためのベクトルデータベース -* **Prometheus exporter** - 本番環境の AI POD で一般的な Pure Storage メトリクスをシミュレート - -### ワークスペース - -各参加者は共有クラスター内の専用 Namespace を割り当てられ、独立した作業のための隔離された環境が確保されます。 - -## ワークショップの内容 - -ワークショップ中、各参加者は以下のタスクを実行します。 - -1. 自分の Namespace に **OpenTelemetry Collector** をデプロイおよび設定する -2. クラスターインフラストラクチャとのオブザーバビリティデータ収集を統合する -3. NVIDIA NIM モデルを活用する **Python アプリケーション** をデプロイする -4. Splunk Observability Cloud を使用してアプリケーションのパフォーマンスとインフラストラクチャメトリクスをモニタリングする - -## Prometheus とは - -**Prometheus** は通常、ストレージとアラートに使用されるフルスタックモニタリングシステムを指しますが、このワークショップでは Prometheus エコシステムのデータ標準に焦点を当てます。 - -このワークショップでは **Prometheus Exporter** を活用します。これは、コンポーネントの内部ヘルスを標準化されたメトリクスエンドポイント（例: http://localhost:9100/metrics）に変換する小さなユーティリティです。 - -フル構成の Prometheus サーバーを使用してこのデータを収集する代わりに、**OpenTelemetry Collector** を使用します。**Prometheus receiver** を使用することで、Collector はこれらのエンドポイントを **スクレイプ** でき、広くサポートされている業界フォーマットを使用してリッチなテレメトリデータを収集できます。 - - diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/11-review-traces.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/11-review-traces.md deleted file mode 100644 index 8cfdb4dbf9..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/11-review-traces.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: メトリクス、トレース、およびログの確認 -linkTitle: 11. メトリクス、トレース、およびログの確認 -weight: 11 -time: 10 minutes ---- - -## Splunk Observability Cloud でトレースデータを表示する - -Splunk Observability Cloud で `APM` に移動し、`Service Map` を選択します。 -お使いの環境名が選択されていることを確認してください（例: `ai-pod-workshop-participant-1`）。 -以下のようなサービスマップが表示されるはずです: - -![Service Map](../../images/ServiceMap.png) - -右側のメニューで `Traces` をクリックします。次に、実行時間の長いトレースを1つ選択します。以下の例のように表示されるはずです: - -![Trace](../../images/Trace.png) - -このトレースは、ユーザーの質問（例: 「How much memory does the NVIDIA H200 have?」）に対する回答を返すために、アプリケーションが実行したすべてのインタラクションを示しています。 - -例えば、アプリケーションが Weaviate ベクトルデータベースで質問に関連するドキュメントを検索するために類似度検索を実行した箇所を確認できます。 - -また、ベクトルデータベースから取得したコンテキストを含め、アプリケーションが LLM に送信するプロンプトをどのように作成したかも確認できます: - -![Prompt Template](../../images/PromptTemplate.png) - -> 注意: トレースウォーターフォールビューで `chat` と `invoke_workflow` の AI インタラクションが表示されない場合、または右側に `AI details` タブが表示されない場合は、有効化が必要な superpowers についてインストラクターに確認してください。 - -最後に、LLM からのレスポンス、所要時間、および使用された入力トークンと出力トークンの数を確認できます: - -![LLM Response](../../images/LLMResponse.png) - -## メトリクスが Splunk に送信されていることを確認する - -Splunk Observability Cloud で `Dashboards` に移動し、`Built-in dashboard groups` に含まれる `Cisco AI PODs Dashboard` を検索します。 -`NIM FOR LLMS` タブに移動し、お使いの OpenShift クラスター名でダッシュボードがフィルタリングされていることを確認します。以下の例のようにチャートにデータが表示されているはずです: - -![NIM LLMS Dashboard](../../images/NIMLLM.png) diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/12-wrapup.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/12-wrapup.md deleted file mode 100644 index 135ffb629f..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/12-wrapup.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: まとめ -linkTitle: 12. まとめ -weight: 12 -time: 5 minutes ---- - -## まとめ - -このワークショップをお楽しみいただけたことを願っています。本ワークショップでは、Splunk Observability Cloud を使用して Cisco AI PODs をモニタリングするために使用されるいくつかの技術を、ハンズオン形式でデプロイおよび操作する体験を提供しました。具体的には、以下の内容を体験していただきました: - -* GPU ベースのワーカーノードを持つ RedHat OpenShift クラスターでの作業。 -* NVIDIA NIM Operator および NVIDIA GPU Operator での作業。 -* NVIDIA NIM を使用してクラスターにデプロイされた Large Language Models (LLMs) での作業。 -* Red Hat OpenShift クラスターへの OpenTelemetry Collector のデプロイ。 -* インフラストラクチャメトリクスを取り込むための Prometheus receiverの Collector への追加。 -* クラスター内の Weaviate ベクトルデータベースのモニタリング。 -* Prometheus を使用した Pure Storage メトリクスのモニタリング設定。 -* Large Language Models (LLMs) と対話する Python サービスの OpenTelemetry による計装。 -* LLM と対話するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報の理解。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md deleted file mode 100644 index 377209dfc3..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -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`）を、パスに含まれている場所に移動します。例えば以下のようにします。 - -``` bash -sudo mv oc /usr/local/bin/oc -sudo mv kubectl /usr/local/bin/kubectl -``` - -## OpenShift クラスターへの接続 - -Kube config ファイルが splunk ユーザーによって変更可能であることを確認します。 - -``` 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="スクリプト" %}} - -``` bash -oc whoami --show-server -``` - -{{% /tab %}} -{{% tab title="出力例" %}} - -``` bash -https://api.***.openshiftapps.com:443 -``` - -{{% /tab %}} -{{< /tabs >}} diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md deleted file mode 100644 index e2aa023062..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: OpenTelemetry Collector のデプロイ -linkTitle: 3. OpenTelemetry Collector のデプロイ -weight: 3 -time: 10 minutes ---- - -このセクションでは、OpenShift の Namespace に OpenTelemetry Collector をデプロイします。 -Collector は、クラスター内で動作するインフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、結果のデータを Splunk Observability Cloud に送信します。 - -## OpenTelemetry Collector のデプロイ - -### Helm がインストールされていることを確認する - -以下のコマンドを実行して、Helm がインストールされていることを確認します。 - -{{< tabs >}} -{{% tab title="スクリプト" %}} - -``` bash -helm version -``` - -{{% /tab %}} -{{% tab title="出力例" %}} - -``` 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="スクリプト" %}} - -``` bash -echo $ENVIRONMENT_NAME -``` - -{{% /tab %}} -{{% tab title="出力例" %}} - -``` bash -ai-pod-workshop-participant-1 -``` - -{{% /tab %}} -{{< /tabs >}} - -### Collector のデプロイ - -ワークショップディレクトリに移動します。 - -``` bash -cd ~/workshop/cisco-ai-pods -``` - -以下のコマンドを使用して、自分の Namespace に 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`）でフィルターを追加します。 - -![Kubernetes Pods](../../images/KubernetesPods.png) diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md deleted file mode 100644 index 315f6e826e..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md +++ /dev/null @@ -1,208 +0,0 @@ ---- -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は、ランタイム情報に基づいてreceiver（Prometheus receiverを含む）を動的に作成でき、スケーラブルで柔軟なスクレイプ設定を可能にします。 -> * **receiver_creator** を使用すると、動的な環境で複数の Prometheus スクレイプターゲットの管理を自動化し、設定を簡素化できます。 - -この新しい**receiver**が使用されるようにするために、`otel-collector-values.yaml` ファイルに新しい**パイプライン**も追加する必要があります。 - -以下のコードをファイルの末尾に追加します。 - -``` yaml - service: - pipelines: - metrics/nvidia-metrics: - exporters: - - signalfx - processors: - - memory_limiter - - batch - - resourcedetection - - resource - receivers: - - receiver_creator/nvidia -``` - -次のセクションで、NVIDIA に関連するもう 1 つの Prometheus **receiver**を追加します。 - -## NVIDIA NIM メトリクスの取得 - -`meta-llama-3-2-1b-instruct` 大規模言語モデルは、NVIDIA NIM を使用して OpenShift クラスターにデプロイされました。Collector でスクレイプできる Prometheus エンドポイントが含まれています。以下を `otel-collector-values.yaml` ファイルの、先ほど追加した `prometheus/dcgm` **receiver**の直下に追加しましょう。 - -``` 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の一部として既に取得されるため、**パイプライン**を変更する必要はありません。 - -## filter processorの追加 - -Prometheus エンドポイントのスクレイプは、大量のメトリクスを生成することがあり、カーディナリティが高くなる場合があります。 - -Splunk に送信するメトリクスを正確に定義する filter **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` **パイプライン**に `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/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md deleted file mode 100644 index e640b54395..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: ベクターデータベースのモニタリング -linkTitle: 5. ベクターデータベースのモニタリング -weight: 5 -time: 5 minutes ---- - -このステップでは、Weaviate ベクターデータベースをモニタリングするために Prometheus receiverを設定します。 - -## ベクターデータベースとは？ - -**ベクターデータベース** は、テキストや画像などの情報の **意味的な意味** を捉えた数値的な「ベクター埋め込み」としてデータを保存し、インデックス化します。従来のデータベースとは異なり、完全一致ではなく概念的に関連するデータポイントを見つける **類似性検索** に優れています。 - -## ベクターデータベースはどのように使用されるのか？ - -ベクターデータベースは、Large Language Models（LLM）を活用するアプリケーションで広く使用されている **Retrieval Augmented Generation（RAG）** と呼ばれるパターンにおいて重要な役割を果たします。 - -パターンは以下の通りです： - -* エンドユーザーがアプリケーションに質問します -* アプリケーションはその質問を受け取り、ベクター埋め込みを計算します -* アプリケーションは類似性検索を実行し、ベクターデータベース内の関連ドキュメントを探します -* アプリケーションは元の質問と関連ドキュメントをコンテキストとして LLM に送信します -* LLM はコンテキストを確認し、アプリケーションにレスポンスを返します - -## Prometheus で Weaviate メトリクスを取得する - -OpenTelemetry Collector の設定を変更して、Weaviate の Prometheus メトリクスをスクレイプしましょう。 - -`otel-collector-values.yaml` ファイルに追加の Prometheus **receiver**クリエーターセクションを追加します。`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` filter processorの設定にも追加されていることを確認する必要があります： - -``` 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` という新しいプロパティにコピーします。これにより、Splunk Observability Cloud で標準的な OpenTelemetry プロパティとして使用される `service.instance.id` を持つ他のメトリクスと、Weaviate メトリクスをより簡単に区別できるようになります。 - -Weaviate メトリクス用の新しいメトリクス**パイプライン**も追加する必要があります（Weaviate 以外のメトリクスに `weaviate.instance.id` メトリクスが追加されないように、別の**パイプライン**を使用する必要があります）。以下をファイルの末尾に追加してください： - -``` 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="まだ Collector を再起動しないでください" style="warning" %}} - -OpenShift 環境では Collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動は待ちます。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md deleted file mode 100644 index 1473a7cc0c..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -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 概要ダッシュボードタブの確認 - -Splunk Observability Cloud で `Dashboards` に移動し、`Built-in dashboard groups` に含まれている `Cisco AI PODs Dashboard` を検索してください。ダッシュボードが OpenShift クラスター名でフィルタリングされていることを確認してください。チャートは以下の例のように表示されるはずです： - -![Kubernetes Pods](../../images/Cisco-AI-Pod-dashboard.png) - -## Pure Storage ダッシュボードタブの確認 - -`PURE STORAGE` タブに移動し、ダッシュボードが OpenShift クラスター名でフィルタリングされていることを確認してください。チャートは以下の例のように表示されるはずです： - -![Pure Storage Dashboard](../../images/PureStorage.png) - -## Weaviate Infrastructure Navigator の確認 - -Weaviate は AI POD にデフォルトで含まれていないため、すぐに使える AI POD ダッシュボードには含まれていません。代わりに、Infrastructure Navigator の1つを使用して Weaviate のパフォーマンスデータを確認できます。 - -Splunk Observability Cloud で `Infrastructure` -> `AI Frameworks` -> `Weaviate` に移動してください。対象の `k8s.cluster.name` でフィルタリングし、以下の例のように Navigator が表示されていることを確認してください： - -![Kubernetes Pods](../../images/WeaviateNavigator.png) diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/8-review-llm-app.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/8-review-llm-app.md deleted file mode 100644 index b2cc577be9..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/8-review-llm-app.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: LLM アプリケーションの確認 -linkTitle: 8. LLM アプリケーションの確認 -weight: 8 -time: 15 minutes ---- - -ワークショップの最後のステップでは、instruct モデルと embeddings モデルを使用するアプリケーションを OpenShift クラスターにデプロイします。 - -## LangChain とは？ - -LLM とやり取りするほとんどのアプリケーションと同様に、このアプリケーションは Python で書かれています。また、LLM を活用したアプリケーションの開発を簡素化するオープンソースのオーケストレーションフレームワークである [LangChain](https://www.langchain.com/) を使用しています。 - -## アプリケーション概要 - -### LLM への接続 - -アプリケーションはまず、使用する2つの LLM に接続します： - -* `meta/llama-3.2-1b-instruct`：ユーザーのプロンプトへの応答に使用 -* `nvidia/llama-3.2-nv-embedqa-1b-v2`：埋め込みの計算に使用 - -``` 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" - ) -``` - -### チェーンの定義 - -アプリケーションは **LCEL（LangChain Expression Language）** を使用してチェーンを定義します。`|`（パイプ）記号はアセンブリラインのように機能し、あるステップの出力が次のステップの入力になります。 - -``` python - chain = ( - { - "context": vector_store.as_retriever(), - "question": RunnablePassthrough() - } - | prompt - | llm - | StrOutputParser() - ) -``` - -これをステップごとに分解してみましょう： - -* **ステップ1：入力マップ {…}**：プロンプトの材料を準備しています。 - * context：ベクターストアをリトリーバーに変換します。これはユーザーの質問に基づいて、NVIDIA データシートから最も関連性の高いスニペットを見つける検索エンジンのように機能します。 - * question：RunnablePassthrough() を使用して、ユーザーの元の質問がそのままプロンプトに渡されるようにします。 - * **注意**：これらのキー（context と question）は、先ほど定義したプロンプトテンプレートの {context} と {question} プレースホルダーに直接対応しています。 -* **ステップ2：prompt**：これは指示書です。context と question を受け取り、プロンプトテンプレートを使用してフォーマットします（例：「コンテキストのみを使用して質問に答えてください...」）。 -* **ステップ3：llm**：これは「エンジン」です（GPT-4 のようなもの）。フォーマットされたプロンプトを読み取り、レスポンスを生成します。 -* **ステップ4：StrOutputParser()**：デフォルトでは、AI モデルは複雑なオブジェクトを返します。この「クリーナー」により、シンプルで読みやすいテキスト文字列が返されるようになります。 - -### チェーンの実行 - -最後に、アプリケーションはエンドユーザーの質問を入力として渡してチェーンを実行します： - -``` python - response = chain.invoke(question) -``` - -これが「スタート」ボタンです。エンドユーザーの質問をパイプラインの最初に投入すると、リトリーバー、プロンプト、LLM を経由して、最終的に答えが出力されます。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/_index.md b/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/_index.md deleted file mode 100644 index d74632efba..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/_index.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: ワークショップ -linkTitle: 2. ワークショップ -weight: 2 ---- - -このセクションには、ワークショップ参加者が実行する手順が含まれています： - -* Red Hat OpenShift クラスターへの **OpenTelemetry Collector** のデプロイを練習します。 -* インフラストラクチャメトリクスを取り込むために、コレクターに **Prometheus** receiverを追加する練習をします。 -* クラスター内の **Weaviate** ベクトルデータベースのモニタリングを練習します。 -* Prometheus を使用した **Pure Storage** メトリクスの収集を練習します。 -* 大規模言語モデル（LLM）と連携する Python サービスを **OpenTelemetry** でインストルメントする練習をします。 -* LLM と連携するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報を理解します。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/_index.md b/content/ja/ninja-workshops/14-cisco-ai-pods/_index.md deleted file mode 100644 index ee084dd783..0000000000 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/_index.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Splunk Observability Cloud による Cisco AI Pods のモニタリング -linkTitle: Splunk Observability Cloud による Cisco AI Pods のモニタリング -weight: 14 -archetype: chapter -time: 2 minutes -authors: ["Derek Mitchell"] -description: This hands-on workshop demonstrates how to monitor Cisco AI Pods with Splunk Observability Cloud. Learn to deploy the OpenTelemetry Collector in Red Hat OpenShift, ingest infrastructure metrics using Prometheus receivers, and configure APM to monitor Python services that interact with Large Language Models (LLMs). -draft: false -hidden: false ---- - -**Cisco の AI 対応 PODs** は、ハードウェアとソフトウェアの最高の技術を組み合わせ、多様なニーズに合わせた堅牢でスケーラブルかつ効率的な 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 PODs をモニタリングするために使用されるいくつかの技術をデプロイし、操作するハンズオン体験を提供します。以下の内容が含まれます： - -* Red Hat OpenShift クラスターへの **OpenTelemetry Collector** のデプロイを練習します。 -* インフラストラクチャメトリクスを取り込むために、コレクターに **Prometheus** receiverを追加する練習をします。 -* クラスターへの **Weaviate** ベクトルデータベースのデプロイを練習します。 -* 大規模言語モデル（LLM）と連携する Python サービスを **OpenTelemetry** でインストルメントする練習をします。 -* LLM と連携するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報を理解します。 - -> 注意：ワークショップセットアップセクションは、ワークショップ主催者のみが実行する必要があります - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下の通りです： - -* このページの右上にある左右の矢印（ **<** | **>** ）を使用する -* キーボードの左（◀️）および右（▶️）カーソルキーを使用する - {{% /notice %}} diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/Cisco-AI-Pod-dashboard.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/Cisco-AI-Pod-dashboard.png deleted file mode 100644 index fb25c6c6c7..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/Cisco-AI-Pod-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/KubernetesPods.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/KubernetesPods.png deleted file mode 100644 index 49777f4363..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/KubernetesPods.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/LLMResponse.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/LLMResponse.png deleted file mode 100644 index 9c4f5d3fcd..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/LLMResponse.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/NIMLLM.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/NIMLLM.png deleted file mode 100644 index b4537ffdaa..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/NIMLLM.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/NVIDIA-Subscriptions.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/NVIDIA-Subscriptions.png deleted file mode 100644 index 7ecfa1f27b..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/NVIDIA-Subscriptions.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/PromptTemplate.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/PromptTemplate.png deleted file mode 100644 index 731182c52c..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/PromptTemplate.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/PureStorage.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/PureStorage.png deleted file mode 100644 index b1b4164034..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/PureStorage.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/ServiceMap.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/ServiceMap.png deleted file mode 100644 index d92da2389b..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/ServiceMap.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/Trace.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/Trace.png deleted file mode 100644 index ac39537621..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/Trace.png and /dev/null differ diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/images/WeaviateNavigator.png b/content/ja/ninja-workshops/14-cisco-ai-pods/images/WeaviateNavigator.png deleted file mode 100644 index a637007144..0000000000 Binary files a/content/ja/ninja-workshops/14-cisco-ai-pods/images/WeaviateNavigator.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/_index.md b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/_index.md deleted file mode 100644 index c4584b77b9..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/_index.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: 1. Java Agent のダウンロード -weight: 1 -description: この演習では、Web ブラウザから AppDynamics Controller にアクセスし、Java APM エージェントをダウンロードします。 ---- -この演習では、WebブラウザからAppDynamics Controllerにアクセスし、Java APMエージェントをダウンロードします。 - -## Controller へのログイン - -Ciscoの資格情報を使用して [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインします。 - -## アプリケーションの設定 - -1. 左側のナビゲーションパネルで **Overview** を選択します -2. **Getting Started** タブをクリックします -3. **Getting Started Wizard** ボタンをクリックします - -![Getting Started Wizard](images/agent-wizard-rz.png) - -Javaアプリケーションタイプを選択します - -![Java Application](images/select-java-rz.png) - -## Java Agent のダウンロード - -1. JVMタイプとして **Sun/JRockit - Legacy** を選択します -2. Controller接続のデフォルト設定を受け入れます -3. **Set Application and Tier** で **Create a new Application:** を選択します -4. アプリケーション名として **Supercar-Trader-YOURINITIALS** を入力します -5. 新しいTierとして **Web Portal** を入力します -6. Node Nameとして **Web-Portal_Node-01** を入力します -7. **Continue** をクリックします -8. **Click Here to Download** をクリックします - -{{% notice title="Warning" style="primary" icon="lightbulb" %}} -アプリケーション名は一意である必要があります。アプリケーション名にイニシャルを追加するか、一意の識別子を追加してください -{{% /notice %}} - -![Agent Configuration1](images/java-agent-config1-rz.png) - -![Agent Configuration2](images/java-agent-config2-rz.png) - -ブラウザにエージェントがローカルファイルシステムにダウンロードされていることを示すプロンプトが表示されます。ファイルがダウンロードされた場所と完全なファイル名をメモしておいてください。 - -![Agent Bundle](images/agent-bundle-rz.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/agent-bundle-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/agent-bundle-rz.png deleted file mode 100644 index 5dcd334377..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/agent-bundle-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/agent-wizard-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/agent-wizard-rz.png deleted file mode 100644 index 9981953a77..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/agent-wizard-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/java-agent-config1-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/java-agent-config1-rz.png deleted file mode 100644 index dfae12b91d..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/java-agent-config1-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/java-agent-config2-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/java-agent-config2-rz.png deleted file mode 100644 index 35dff45684..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/java-agent-config2-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/select-java-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/select-java-rz.png deleted file mode 100644 index 597e99f517..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/1-download-agent/images/select-java-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/2-install-agent/_index.md b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/2-install-agent/_index.md deleted file mode 100644 index 9f49f48ca6..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/2-install-agent/_index.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: 2. Java Agent のインストール -weight: 2 -description: この演習では、サーバーに SSH 接続し、Java エージェントをインストールします。 ---- - -この演習では、以下のアクションを実行します - -- JavaエージェントファイルをEC2インスタンスにアップロードする -- ファイルを特定のディレクトリに解凍する -- JavaエージェントのXML設定ファイルを更新する（オプション） -- Apache Tomcatの起動スクリプトを変更してJavaエージェントを追加する - -## Application VM への Java Agent のアップロード - -この時点で、このワークショップで使用するEC2インスタンスに関する情報を受け取っているはずです。EC2インスタンスのIPアドレス、インスタンスにSSH接続するために必要なユーザー名とパスワードを確認してください。 - -ローカルマシンでターミナルウィンドウを開き、Javaエージェントファイルがダウンロードされたディレクトリに移動します。以下のコマンドを使用してファイルをEC2インスタンスにアップロードします。これには時間がかかる場合があります。 - -- インスタンスのIPアドレスまたはパブリックDNSを更新してください。 -- ファイル名を正確なバージョンに合わせて更新してください。 - -{{< tabs >}} -{{% tab title="Command" %}} - -``` bash -cd ~/Downloads -scp -P 2222 AppServerAgent-22.4.0.33722.zip splunk@i-0b6e3c9790292be66.splunk.show:/home/splunk -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` bash -(splunk@44.247.206.254) Password: -AppServerAgent-22.4.0.33722.zip 100% 22MB 255.5KB/s 01:26 -``` - -{{% /tab %}} -{{< /tabs >}} - -## Java Agent の解凍 - -インストラクターから割り当てられたインスタンスとパスワードを使用してEC2インスタンスにSSH接続します。 - -``` bash -ssh -P 2222 splunk@i-0b6e3c9790292be66.splunk.show -``` - -Javaエージェントバンドルを新しいディレクトリに解凍します。 - -``` bash -cd /opt/appdynamics -mkdir javaagent -cp /home/splunk/AppServerAgent-*.zip /opt/appdynamics/javaagent -cd /opt/appdynamics/javaagent -unzip AppServerAgent-*.zip -``` - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -ControllerのGetting Started Wizardを使用してJavaエージェントを事前設定しました。AppDynamics Portalからエージェントをダウンロードした場合は、JavaエージェントのXML設定ファイルを手動で更新する必要があります。 - -Javaエージェントの設定プロパティを設定するには、主に3つの方法があります。これらは以下の順序で優先されます - -1. システム環境変数 -2. コマンドラインで渡されるJVMプロパティ -3. ```controller-info.xml``` ファイル内のプロパティ -{{% /notice %}} - -## Tomcat Server への Java Agent の追加 - -まず、Tomcatサーバーが実行されていないことを確認します - -``` bash -cd /usr/local/apache/apache-tomcat-9/bin -./shutdown.sh -``` - -次に、catalinaスクリプトを変更してJavaエージェントの環境変数を設定します。 - -``` bash -cd /usr/local/apache/apache-tomcat-9/bin -nano catalina.sh -``` - -125行目（最初のコメントの後）に以下の行を追加してファイルを保存します - -``` bash -export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/opt/appdynamics/javaagent/javaagent.jar" -``` - -サーバーを再起動します - -``` bash -./startup.sh -``` - -Tomcatサーバーが実行されていることを確認します。これには数分かかる場合があります - -{{< tabs >}} -{{% tab title="Command" %}} - -``` bash -curl localhost:8080 -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` bash - - - - - Apache Tomcat/9.0.50 - - - - - -
}} diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md deleted file mode 100644 index d1b9e35c1a..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/_index.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -title: 3. アプリケーション負荷の生成 -weight: 3 -description: このセクションでは、サンプルアプリケーションをインストールし、負荷生成を開始します ---- -この演習では、以下のアクションを実行します - -* サンプルアプリが実行されていることを確認する -* サンプルアプリケーションの負荷生成を開始する -* Controllerでトランザクション負荷を確認する - -## サンプルアプリケーションが実行されていることの確認 - -サンプルアプリケーションのホームページには、以下の形式のURLを使用してWebブラウザからアクセスできます。EC2インスタンスのIPアドレスに置き換えて、ブラウザのナビゲーションバーにURLを入力してください。 - -```bash -http://[ec2-ip-address]:8080/Supercar-Trader/home.do -``` - -Supercar Traderアプリケーションのホームページが表示されるはずです。 -![Supercar Trade Home Page](images/SuperCarHomePage-rz.png) - -## 負荷生成の開始 - -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 でのトランザクション負荷の確認 - -WebブラウザでGetting Started Wizardがまだ開いている場合、エージェントが接続され、Controllerがデータを受信していることが確認できるはずです。 - -![Agent Connected](images/agent_connected.png) - -**Continue** をクリックすると、**Application Flow Map** に移動します（以下のFlow Mapの画像にジャンプできます）。 - -Controllerのブラウザウィンドウを以前に閉じた場合は、Controllerに再度ログインしてください。 - -1. Overviewページ（ランディングページ）から、左側のナビゲーションパネルの **Applications** タブをクリックします。 - - ![Controller Overview Page](images/ControllerOverviewPage.png) - -2. **Applications** ページでは、アプリケーションを手動で検索するか、右上の検索バーを使用して検索を絞り込むことができます。 - - ![Applications Search](images/ApplicationsSearch.png) - -アプリケーション名をクリックすると、**Application Flow Map** に移動します。12分後にすべてのアプリケーションコンポーネントが表示されるはずです。 - -12分経ってもすべてのアプリケーションコンポーネントが表示されない場合は、さらに数分待ってからブラウザタブを更新してください。 - -![FlowMap](images/SuperCarTrader_FlowMap-rz.png) - -エージェントのダウンロード手順で、TomcatサーバーのTier名とNode名を割り当てました。 - -``` bash -Web-Portal -Web-Portal_Node-01 -``` - -他の4つのサービスのTier名とNode名がどのように割り当てられたか疑問に思うかもしれません。サンプルアプリケーションは、最初のTomcat JVMから4つの追加JVMを動的に作成し、4つのサービスそれぞれのJVM起動コマンドに -Dプロパティとしてこれらのプロパティを渡すことでTier名とNode名を割り当てます。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** を選択します - -![Ungroup Http](images/ungroup-http-rz.png) - -HTTPバックエンドのグループ化が解除されると、以下の画像のように3つすべてのHTTPバックエンドが表示されます。 - -![Ungroup flow](images/ungrouped_flow-rz.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ApplicationsSearch.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ApplicationsSearch.png deleted file mode 100644 index dd92a7001f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ApplicationsSearch.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ControllerOverviewPage.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ControllerOverviewPage.png deleted file mode 100644 index 52c3c52628..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ControllerOverviewPage.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/SuperCarHomePage-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/SuperCarHomePage-rz.png deleted file mode 100644 index 67d2d3da8c..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/SuperCarHomePage-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/SuperCarTrader_FlowMap-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/SuperCarTrader_FlowMap-rz.png deleted file mode 100644 index 4724ef0825..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/SuperCarTrader_FlowMap-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/agent_connected.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/agent_connected.png deleted file mode 100644 index ed8a795878..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/agent_connected.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/business_transactions.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/business_transactions.png deleted file mode 100644 index fb022f0db7..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/business_transactions.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ungroup-http-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ungroup-http-rz.png deleted file mode 100644 index ed616da0a2..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ungroup-http-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ungrouped_flow-rz.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ungrouped_flow-rz.png deleted file mode 100644 index a92fa86af3..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/3-generate-application-load/images/ungrouped_flow-rz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md deleted file mode 100644 index 67e83ebe5b..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/_index.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -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)をご覧ください。 - -![Flow Map Components](images/FlowMapComponents.png) - -## 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のリストとそのパフォーマンスを確認します。 - -![Business Transactions](images/business-transactions.png) - -## Snapshots - -AppDynamicsは、計装された環境内のすべてのBusiness Transactionの実行を監視し、メトリクスはそれらすべての実行を反映します。ただし、トラブルシューティングの目的で、AppDynamicsは問題が発生しているトランザクションの特定のインスタンスのスナップショット（詳細な診断情報を含む）を取得します。 - -以下の手順に従って、トランザクションスナップショットが自動的に収集されていることを確認します。 - -1. 左側のメニューで **Application Dashboard** オプションをクリックします。 -2. **Transaction Snapshots** タブをクリックします。 -3. **Exe Time (ms)** 列をクリックして、実行時間が最も長いスナップショットでソートします。 -4. Business Transactionスナップショットをダブルクリックしてスナップショットビューアを表示します - -![Snapshots](images/snapshots.png) - -トランザクションスナップショットは、単一のトランザクション呼び出しの処理フローをクロスティアビューで表示します。 - -**Potential Issues** パネルは、遅いメソッドと遅いリモートサービスコールを強調表示し、パフォーマンス問題の根本原因を調査するのに役立ちます。 - -## Drill Downs と Call Graphs - -Call graphsとdrill downsは、Tierでのトランザクション実行に関する重要な情報を提供します。これには、最も遅いメソッド、エラー、リモートサービスコールが含まれます。drill downには、部分的または完全なcall graphが含まれる場合があります。Call graphsは、特定のTierでのBusiness Transactionの処理をコードレベルで表示します。 - -Business TransactionスナップショットのFlow Mapで、Drill DownリンクがあるTierは、AppDynamicsがそのTierのcall graphを取得したことを示しています。 - -以下の手順に従って、トランザクションスナップショットのcall graphにドリルダウンします。 - -1. 左側のPotential Issuesリストで遅いコールをクリックします。 -2. **Drill Down into Call Graph** をクリックします。 - -![Snapshot Drill Down](images/SnapShotDrillDown.png) - -call graphビューには、以下の詳細が表示されます。 - -1. メソッド実行シーケンスは、このノードでBusiness Transactionの処理に参加したクラスとメソッドの名前を、制御フローの進行順序で表示します。 -2. 各メソッドについて、処理に費やされた時間と割合、およびソースコード内の行番号を確認でき、トランザクションのパフォーマンスに影響を与えている可能性のあるコード内の場所を特定できます。 -3. call graphは、データベースクエリやWebサービスコールなど、他のコンポーネントへの発信コールを行うメソッドの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)をご覧ください。 - -![Call Graph](images/call-graph.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/FlowMapComponents.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/FlowMapComponents.png deleted file mode 100644 index 0968686bca..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/FlowMapComponents.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/SnapShotDrillDown.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/SnapShotDrillDown.png deleted file mode 100644 index 4f13199330..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/SnapShotDrillDown.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/business-transactions.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/business-transactions.png deleted file mode 100644 index a72df26ef6..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/business-transactions.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/call-graph.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/call-graph.png deleted file mode 100644 index 30b3f7922d..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/call-graph.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/snapshots.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/snapshots.png deleted file mode 100644 index fb022f0db7..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/4-apm-core-concepts/images/snapshots.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md deleted file mode 100644 index db7727a33f..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/_index.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: 5. Controller 設定の構成 -weight: 5 -description: このセクションでは、Controller 内のさまざまな APM 設定を構成する方法を学びます ---- - - -この演習では、以下のタスクを完了します - -- Business Transaction設定を調整する -- Call Graph設定を調整する -- Business Transactionの変更を確認する - -## Business Transaction 設定の調整 - -前の演習で、Business Transactionsが自動検出されていることを確認しました。Business Transactionの自動検出ルールを最適な状態に調整したい場合があります。これは、古いApache Strutsフレームワーク上に構築されたサンプルアプリケーションの場合に当てはまります。 - -以下の画像で強調表示されているBusiness Transactionsは、各ペアにStruts Action（.execute）とServletタイプ（.jsp）があることを示しています。これら2種類のトランザクションが1つに統合されるように、トランザクション検出ルールの設定を調整します。 - -AppDynamics UIに時間枠セレクターが表示されている場合、表示されるビューは選択した時間枠のコンテキストを表します。事前定義された時間枠の1つを選択するか、表示したい特定の日付と時間範囲でカスタム時間枠を作成できます。 - -1. 過去1時間の時間枠を選択します。 -2. マウスを青いアイコンの上に移動して、トランザクションのEntry Point Typeを確認します。 - -![List of Business Transactions](images/business-transactions-list.png) - -以下の手順に従ってトランザクション検出を最適化します - -1. 左下のメニューで **Configuration** オプションをクリックします。 -2. **Instrumentation** リンクをクリックします。 - - ![Configure Instrumentation](images/configure-instrumentation.png) - -3. Instrumentationメニューから **Transaction Detection** を選択します。 -4. **Java Auto Discovery Rule** を選択します。 -5. **Edit** をクリックします。 - - ![Edit Java Rules](images/edit-java-rule.png) - -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)をご覧ください。 - -![Rule Configuration](images/rule-configuration1.png) -![Rule Configuration Cont](images/rule-configuration2.png) - -## Call Graph 設定の調整 - -以下に示すCall Graph Settingsウィンドウで、トランザクションスナップショット内のcall graphsでキャプチャされるデータを制御できます。このステップでは、各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)をご覧ください。 - -![Call Graph Configuration](images/call-graph-config.png) - -## Business Transaction の変更の確認 - -新しいBusiness Transactionsが以前のトランザクションを置き換えるまでに最大30分かかる場合があります。新しいトランザクションが検出されると、Business Transactionsのリストは以下の例のようになります。 - -1. 左側のメニューで **Business Transactions** をクリックします。 -2. 時間範囲ピッカーを調整して **last 15 minutes** を確認します - -![Updated BTs](images/updated_business_transactions.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/business-transactions-list.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/business-transactions-list.png deleted file mode 100644 index 584c8d8ecf..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/business-transactions-list.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/call-graph-config.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/call-graph-config.png deleted file mode 100644 index 36f11a6d6a..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/call-graph-config.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/configure-instrumentation.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/configure-instrumentation.png deleted file mode 100644 index 0de6b89397..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/configure-instrumentation.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/edit-java-rule.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/edit-java-rule.png deleted file mode 100644 index 6127db78d6..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/edit-java-rule.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/rule-configuration1.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/rule-configuration1.png deleted file mode 100644 index b6dd39cd99..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/rule-configuration1.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/rule-configuration2.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/rule-configuration2.png deleted file mode 100644 index b45ae9963d..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/rule-configuration2.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/updated_business_transactions.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/updated_business_transactions.png deleted file mode 100644 index d9821e591c..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/5-configure-controller/images/updated_business_transactions.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md deleted file mode 100644 index ba274baac0..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/_index.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: 6. 遅いトランザクションのトラブルシューティング -weight: 6 -description: このセクションでは、スナップショットを活用して遅いトランザクションをトラブルシューティングする方法を学びます ---- - -この演習では、以下のタスクを完了します - -- アプリケーションダッシュボードとフローマップを監視する -- 遅いトランザクションスナップショットをトラブルシューティングする - -## アプリケーションダッシュボードとフローマップの監視 - -前の演習では、Application Flow Mapの基本的な機能をいくつか見てきました。Application DashboardとFlow Mapを使用してアプリケーション内の問題を即座に特定する方法をより深く見ていきましょう。 - -1. Health Rule Violations、Node Healthの問題、およびBusiness Transactionsの健全性は、選択した時間枠についてこのエリアに常に表示されます。ここで利用可能なリンクをクリックして詳細にドリルダウンできます。 -2. Transaction Scorecardは、正常、遅い、非常に遅い、停止、エラーのあるトランザクションの数と割合を表示します。スコアカードには、例外タイプの高レベルのカテゴリも表示されます。ここで利用可能なリンクをクリックして詳細にドリルダウンできます。 -3. 異なるアプリケーションコンポーネントを接続する青い線のいずれかを左クリック（シングルクリック）すると、2つのコンポーネント間のインタラクションの概要が表示されます。 -4. Tierの色付きリング内を左クリック（シングルクリック）すると、Flow Mapに留まりながらそのTierに関する詳細情報が表示されます。 -5. ダッシュボードの下部にある3つのチャート（Load、Response Time、Errors）のいずれかの時系列にマウスを合わせると、記録されたメトリクスの詳細が表示されます。 - - ![Flow Map Components](images/flow-map-components.png) - -次に、Dynamic Baselinesとダッシュボードの下部にあるチャートのオプションを見てみましょう。 - -1. チャートのメトリクスを、各メトリクスに対して自動的に計算されたDynamic Baselineと比較します。 -2. Dynamic Baselineは、以下の画像に示すように、負荷と応答時間のチャートに青い点線で表示されます。 -3. ダッシュボードの下部にある3つのチャートのいずれかでスパイクを強調表示するには、マウスボタンを押したまま左から右にドラッグします。 -4. マウスボタンを離し、ポップアップメニューの3つのオプションのいずれかを選択します。 - - ![Flow Map Components](images/flowmap_components2.png) - -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)をご覧ください。 - -## 遅いトランザクションスナップショットのトラブルシューティング - -以下の手順に従って、Business Transactionsを確認し、非常に遅いトランザクションが最も多いものを見つけましょう。 - -1. 左側のメニューで **Business Transactions** オプションをクリックします。 -2. **View Options** ボタンをクリックします。 -3. 以下の画像と一致するようにオプションのボックスのチェックを入れたり外したりします - - ![BTs Column Config](images/bt-configure-columns.png) - -4. /Supercar-Trader/car.doという名前のBusiness Transactionを見つけ、そのBusiness TransactionのVery Slow Transactionsの数をクリックして、非常に遅いトランザクションスナップショットにドリルダウンします。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -/Supercar-Trader/car.do BTにVery Slow Transactionsがない場合は、それがあるBusiness Transactionを見つけて、その列の数字をクリックしてください。今後のスクリーンショットは若干異なる場合がありますが、概念は同じです。 -{{% /notice %}} - - ![Very Slow Transaction](images/very-slow-transaction.png) - -5. 非常に遅いトランザクションスナップショットのリストが表示されるはずです。以下に示すように、最も応答時間が長いスナップショットをダブルクリックします。 - - ![snapshot list](images/snapshot.png) - - トランザクションスナップショットビューアが開くと、この特定のトランザクションの一部であったすべてのコンポーネントのフローマップビューが表示されます。このスナップショットは、トランザクションが以下のコンポーネントを順番に通過したことを示しています。 - - - Web-Portal Tier - - Api-Services Tier - - Enquiry-Services Tier - - MySQL Database - - 左側のPotential Issuesパネルは、遅いメソッドと遅いリモートサービスを強調表示します。Potential Issuesパネルを使用してcall graphに直接ドリルダウンすることもできますが、この例ではスナップショット内のFlow Mapを使用して完全なトランザクションを追跡します。 - -6. スナップショットのFlow Mapに表示されているWeb-Portal Tierの **Drill Down** をクリックします。 - - ![Web Portal Drilldown](images/webportal-drilldown.png) - - 開いたタブにはWeb-Portal Tierのcall graphが表示されます。ほとんどの時間がアウトバウンドHTTPコールによるものであることがわかります。 - -7. ブロックをクリックして、問題が発生しているセグメントにドリルダウンします。HTTPリンクをクリックしてダウンストリームコールの詳細を表示します。 - - ![Call Graph](images/callgraph.png) - - ダウンストリームコールの詳細パネルは、Web-Portal TierがApi-Services TierへのアウトバウンドHTTPコールを行ったことを示しています。HTTPコールを追跡してApi-Services Tierに進みます。 - -8. **Drill Down into Downstream Call** をクリックします。 - - ![Call Graph Downstream](images/callgraph_downstream.png) - - 次に開くタブにはApi-Services Tierのcall graphが表示されます。時間の100%がアウトバウンドHTTPコールによるものであることがわかります。 - -9. HTTPリンクをクリックしてダウンストリームコールの詳細パネルを開きます。 - - ![Downstream Call Graph](images/downstream_callgraph.png) - - ダウンストリームコールの詳細パネルは、Api-Services TierがEnquiry-Services TierへのアウトバウンドHTTPコールを行ったことを示しています。HTTPコールを追跡してEnquiry-Services Tierに進みます。 - -10. **Drill Down into Downstream Call** をクリックします。 - - ![API service downstream](images/apiservices-downstream.png) - - 次に開くタブにはEnquiry-Services Tierのcall graphが表示されます。トランザクションに問題を引き起こしたデータベースへのJDBCコールがあったことがわかります。 - -11. 最も時間がかかったJDBCリンクをクリックして、JDBCコールの詳細パネルを開きます。 - - ![JDBC Callgraph](images/jdbc-callgraph.png) - - JDBC exitコールの詳細パネルには、最も時間がかかった特定のクエリが表示されます。SQLパラメータ値とともに完全なSQLステートメントを確認できます。 - - ![DB Call Details](images/db-query-details.png) - -## まとめ - -このラボでは、まずBusiness Transactionsを使用して、トラブルシューティングが必要な非常に遅いトランザクションを特定しました。次に、call graphを調べて、遅延を引き起こしているコードの特定の部分を特定しました。その後、ダウンストリームサービスとデータベースにドリルダウンして、遅延の根本原因をさらに分析しました。最後に、パフォーマンスの問題の原因となっている非効率なSQLクエリを正確に特定することに成功しました。この包括的なアプローチは、AppDynamicsがトランザクションのボトルネックを効果的に分離して解決するのにどのように役立つかを示しています。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/apiservices-downstream.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/apiservices-downstream.png deleted file mode 100644 index b6e492c53f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/apiservices-downstream.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/bt-configure-columns.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/bt-configure-columns.png deleted file mode 100644 index 9807fdf8a6..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/bt-configure-columns.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/callgraph.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/callgraph.png deleted file mode 100644 index 3d3e1745e7..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/callgraph.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/callgraph_downstream.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/callgraph_downstream.png deleted file mode 100644 index 7283b50ba2..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/callgraph_downstream.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/db-query-details.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/db-query-details.png deleted file mode 100644 index 46ad3819f3..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/db-query-details.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/downstream_callgraph.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/downstream_callgraph.png deleted file mode 100644 index afc88fd770..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/downstream_callgraph.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/flow-map-components.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/flow-map-components.png deleted file mode 100644 index 00d6ab74fe..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/flow-map-components.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/flowmap_components2.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/flowmap_components2.png deleted file mode 100644 index e9af1d23fb..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/flowmap_components2.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/jdbc-callgraph.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/jdbc-callgraph.png deleted file mode 100644 index ec281e8380..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/jdbc-callgraph.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/snapshot.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/snapshot.png deleted file mode 100644 index ca16d0c28f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/snapshot.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/very-slow-transaction.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/very-slow-transaction.png deleted file mode 100644 index ab85eabbeb..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/very-slow-transaction.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/webportal-drilldown.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/webportal-drilldown.png deleted file mode 100644 index f70c95e918..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/6-apm-part1/images/webportal-drilldown.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md deleted file mode 100644 index d65ee1be48..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/_index.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: 7. エラーと例外のトラブルシューティング -weight: 7 -description: このセクションでは、アプリケーション内のエラーをトラブルシューティングする方法を学びます ---- - -この演習では、アプリケーション内のエラーを効果的に検出および診断して根本原因を特定する方法を学びます。さらに、パフォーマンスが低下しているか、エラーが発生している特定のノードを特定し、これらのパフォーマンスの問題を解決するためのトラブルシューティング手法を適用する方法を探ります。このハンズオン体験により、アプリケーションの健全性を維持し、最適なパフォーマンスを確保する能力が向上します。 - -## アプリケーション内の特定のエラーの検出 - -AppDynamicsを使用すると、アプリケーション内のエラーと例外を簡単に見つけることができます。**Errors** ダッシュボードを使用して、エラーのあるトランザクションスナップショットを確認し、最も頻繁に発生している例外を見つけることができます。エラーを迅速に特定することで、アプリケーションの安定性とユーザーエクスペリエンスを向上させる修正の優先順位付けに役立ちます。例外のタイプと頻度を理解することで、最も影響の大きい問題に集中できます。 - -1. 左側のメニューで **Troubleshoot** オプションをクリックします。 -2. 左側のメニューで **Errors** オプションをクリックします。これにより、エラーのあるBusiness Transactionsをすばやく特定できるErrorsダッシュボードに移動します。 -3. いくつかのエラートランザクションスナップショットを調べます。スナップショットを確認すると、エラーが発生したときの正確なコンテキストとフローを確認できます。 -4. **Exceptions** タブをクリックして、タイプ別にグループ化された例外を表示します。例外タイプ別にグループ化することで、繰り返し発生する問題とパターンを特定できます。 - - ![Errors Dashboard](images/errors-dashboard.png) - - **Exceptions** タブには、アプリケーション内で最も多く発生している例外のタイプが表示されるため、最も影響の大きいものの修正を優先できます。 - -5. **Exceptions per minute** と **Exception count**（6）を確認して、エラーの頻度を把握します。高頻度の例外は、即座に対応が必要な重大な問題を示していることが多いです。 -6. 例外が発生している **Tier** を確認して、アプリケーションアーキテクチャ内で問題を特定します。影響を受けているTierを知ることで、根本原因を絞り込むことができます。 -7. MySQLIntegrityConstraintViolationExceptionタイプをダブルクリックして、より深くドリルダウンします。 - - ![Exception Dashboard](images/exception-dashboard.png) - -8. この例外タイプが発生したスナップショットを示す概要ダッシュボードを確認します。 -9. **Stack Traces for this Exception** というラベルのタブには、この例外タイプによって生成された一意のスタックトレースの集約リストが表示されます。スタックトレースは、エラーを引き起こしている正確なコードパスを提供し、デバッグに不可欠です。 -10. スナップショットをダブルクリックして開き、コンテキスト内でエラーを確認します。 -これにより、トランザクションフローとエラーが発生した場所が表示されます。 - - ![MySQL Exception](images/MySQL-exception.png) - - 例外画面からエラースナップショットを開くと、スナップショットはエラーが発生したスナップショット内の特定のセグメントで開きます。 - -11. 赤いテキストで表示されているexitコールに注目してください。これはエラーまたは例外を示しています。 -12. exitコールにドリルインして、詳細なエラー情報を表示します。 -13. **Error Details** をクリックして、完全なスタックトレースを表示します。完全なスタックトレースは、開発者がバグを追跡して修正するために不可欠です。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -エラー処理と例外について詳しく知りたい場合は、次のリンクの公式AppDynamicsドキュメントを参照してください：[こちら](https://help.splunk.com/en/appdynamics-saas/application-performance-monitoring/25.7.0/troubleshooting-applications/errors-and-exceptions) -{{% /notice %}} - -![Call Graph Error](images/callgraph-error.png) - -## ノードの問題のトラブルシューティング - -ノードの健全性は、アプリケーションのパフォーマンスと可用性に直接影響します。ノードの問題を早期に検出することで、停止を防ぎ、スムーズな運用を確保できます。AppDynamicsはUI全体で視覚的なインジケーターを提供し、問題をすばやく特定しやすくしています。 - -Application Dashboardの3つのエリアでノードの問題のインジケーターを確認できます。 - -1. **Application Dashboard** でノードの問題の視覚的なインジケーターを確認します。色の変化とアイコンは、問題に対する即座のアラートを提供します。 -2. **Events** パネルには、Node Healthに関連するものを含むHealth Rule Violationsが表示されます。 -3. **Node Health** パネルには、ノードで発生している重大または警告の問題の数が表示されます。**Node Health** パネルのNode Healthリンクをクリックして、**Tiers & Nodes dashboard** にドリルダウンします。 - - ![Application Dashboard](images/application-dashboard.png) - -4. または、左側のメニューで **Tiers & Nodes** をクリックして **Tiers & Nodes dashboard** にアクセスすることもできます。 -5. Grid Viewに切り替えて、整理されたノードのリストを表示します。Grid viewを使用すると、警告のあるノードをスキャンして見つけやすくなります。 -6. Insurance-Services_Node-01ノードの警告アイコンをクリックします。 - - ![Tiers and Nodes List](images/tiers-nodes-list.png) - -7. Health Rule Violationsのサマリーを確認し、違反の説明をクリックします。 -8. **Details** ボタンをクリックして詳細を表示します。 - - ![Health Rule Violation](images/health-rule-violations.png) - - **Health Rule Violation** 詳細ビューアには以下が表示されます - -9. 違反の現在の状態。 -10. 違反が発生していた時間のタイムライン。 -11. 違反の詳細と、それをトリガーした条件。 -12. **View Dashboard During Health Rule Violation** をクリックして、問題発生時のノードメトリクスを確認します。違反とパフォーマンスメトリクスを関連付けることで、診断に役立ちます。 - - ![Health Rule Violation Details](images/health-rule-violation-details.png) - - **View Dashboard During Health Rule Violation** ボタンをクリックすると、デフォルトでNodeダッシュボードの **Server** タブが開きます。 - - AppDynamics Server Visibility Monitoringエージェントをまだインストールしていない場合、ノードのホストのリソースメトリクスは表示されません。これらのメトリクスは次のラボで確認できます。AppDynamics Javaエージェントは、JMX経由でJVMからメモリメトリクスを収集します。 - - 以下の手順でJVMヒープデータを調査します。 - -13. **Memory** タブをクリックします。 -14. 現在のヒープ使用率を確認します。 -15. 発生しているMajor Garbage Collectionsに注目します。 - -注：Memory画面の表示に問題がある場合は、別のブラウザを試してください（FirefoxはWindows、Linux、Macで正しくレンダリングされるはずです）。 - - ![Memory Dashboard](images/memory-dashboard.png) - -16. 外側のスクロールバーを使用して、画面の下部までスクロールします。 -17. **PS Old Gen** のメモリ使用量が高い場合は、メモリリークまたは非効率なガベージコレクションの潜在的な兆候として注意してください。メモリ圧力を早期に特定することで、停止を防ぐことができます。 - -Nodeと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)をご覧ください。 - -![PS Old Gen](images/ps-old-gen.png) - -## まとめ - -このラボでは、AppDynamicsを効果的に使用してアプリケーションエラーとノードの健全性の問題を特定およびトラブルシューティングする方法を学びました。まず、Errorsダッシュボードを使用して特定のエラーと例外を見つけ、その頻度、タイプ、およびアプリケーションへの影響を理解しました。エラースナップショットとスタックトレースにドリルダウンして、障害の根本原因を特定しました。 - -次に、Application Dashboardの視覚的なインジケーターを解釈し、Health Rule Violationsを調査することで、ノードの健全性監視を探りました。ガベージコレクションとヒープ使用量に関連する潜在的なパフォーマンスボトルネックを検出するために、JVMメモリメトリクスを分析する方法を学びました。 - -これらのスキルを組み合わせることで、アプリケーションのパフォーマンスと信頼性を維持するためのプロアクティブな監視と迅速なトラブルシューティングが可能になります。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/MySQL-exception.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/MySQL-exception.png deleted file mode 100644 index 48ece14abd..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/MySQL-exception.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/application-dashboard.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/application-dashboard.png deleted file mode 100644 index 6df80b5043..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/application-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/callgraph-error.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/callgraph-error.png deleted file mode 100644 index c1e0c02496..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/callgraph-error.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/errors-dashboard.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/errors-dashboard.png deleted file mode 100644 index b6a603efb6..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/errors-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/exception-dashboard.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/exception-dashboard.png deleted file mode 100644 index e704f31e2c..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/exception-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/health-rule-violation-details.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/health-rule-violation-details.png deleted file mode 100644 index ed296e00d1..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/health-rule-violation-details.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/health-rule-violations.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/health-rule-violations.png deleted file mode 100644 index a97f5827bc..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/health-rule-violations.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/memory-dashboard.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/memory-dashboard.png deleted file mode 100644 index 3e5cf643c9..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/memory-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/ps-old-gen.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/ps-old-gen.png deleted file mode 100644 index 3573b0b8d4..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/ps-old-gen.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/tiers-nodes-list.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/tiers-nodes-list.png deleted file mode 100644 index aaa5ecfd58..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/7-apm-part2/images/tiers-nodes-list.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/_index.md b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/_index.md deleted file mode 100644 index 89dc31b405..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/_index.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -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/) を使用します。 - -![Controller](images/controller-vm.png) - -## Application VM - -Supercar TraderはJavaベースのWebアプリケーションです。 - -Supercar-Traderコレクションの目的は、AppDynamics Controllerのための動的なトラフィック（Business Transactions）を生成することです。 - -![Application VM](images/application-vm.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/images/application-vm.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/images/application-vm.png deleted file mode 100644 index 3152db2402..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/images/application-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/images/controller-vm.png b/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/images/controller-vm.png deleted file mode 100644 index 21b0cce620..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/1-application-performance-monitoring/images/controller-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md deleted file mode 100644 index 62c3ca02ca..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/_index.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: ラボの前提条件 -time: 2 minutes -weight: 1 -description: この演習では、Splunk AppDynamics Controller にアクセスし、アプリケーションへのトランザクション負荷を確認し、必要に応じてアプリケーションとトランザクション負荷を再起動します。 -draft: true ---- - -## Controller へのログイン - -Ciscoの認証情報を使用して [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインしてください。 - -## アプリケーションへのトランザクション負荷の確認 - -アプリケーションフローマップを確認します - -1. 過去1時間の時間枠を選択します。 -2. フローマップに5つの異なるTierが表示されていることを確認します。 -3. 過去1時間にわたって一貫した負荷があったことを確認します。 - -![Verify App Load](images/verify-app-load-01.png) - -ビジネストランザクションのリストを確認します - -1. 左側のメニューで **Business Transactions** オプションをクリックします。 -2. 以下に示す11個のビジネストランザクションが表示されていることを確認します。 -3. 過去1時間に何らかのコール数があることを確認します。 - -注：**Calls** カラムが表示されていない場合は、**View Options** ツールバーボタンをクリックしてそのカラムを表示できます。 - -![Verify App Load](images/verify-app-load-02.png) - -Nodeのエージェントステータスを確認します - -1. 左側のメニューで **Tiers & Nodes** オプションをクリックします。 -2. **Grid View** をクリックします。 -3. 各NodeのApp Agent Statusが過去1時間で90%以上であることを確認します。 - -![Verify App Load](images/verify-app-load-03.png) - -## 必要に応じてアプリケーションとトランザクション負荷を再起動する - -前のステップで実行した確認のいずれかが確認できなかった場合は、Application VMにSSH接続し、以下のステップに従ってアプリケーションとトランザクション負荷を再起動してください。EC2インスタンスのIPアドレス、SSH接続に必要なユーザー名とパスワードを用意してください。ローカルマシンでターミナルを開き、以下を入力します - -``` 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 -``` - -以下の画像のような出力が表示されるはずです。 - -![Restart App And Load](images/restart-app-and-load-02.png) - -次に、以下のコマンドを使用してApache Tomcatを起動します。 - -```bash -cd /usr/local/apache/apache-tomcat-9/bin -./startup.sh -``` - -2分待ってから、以下のコマンドを使用してApache Tomcatがポート8080で実行されていることを確認します。 - -```bash -sudo netstat -tulpn | grep LISTEN -``` - -Apache Tomcatがポート8080を使用していることを示す、以下の画像のような出力が表示されるはずです。 - -![Restart App](images/restart-app-and-load-01.png) - -以下のコマンドを使用して、アプリケーションの負荷生成を開始します。 - -```bash -cd /opt/appdynamics/lab-artifacts/phantomjs -./start_load.sh -``` - -以下の画像のような出力が表示されるはずです。 - -![Restart App And Load](images/restart-app-and-load-03.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png deleted file mode 100644 index c8704770fc..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png deleted file mode 100644 index 20d5aec2fe..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png deleted file mode 100644 index 69051b3f57..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-01.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-01.png deleted file mode 100644 index e6b23e1e3d..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-01.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-02.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-02.png deleted file mode 100644 index 6980f5198c..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-02.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-03.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-03.png deleted file mode 100644 index d40f6a9a26..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/1-lab-prerequisites/images/verify-app-load-03.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md deleted file mode 100644 index 41e8190752..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/_index.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Server Agent のデプロイ - オプション 1 -time: 2 minutes -weight: 2 -description: 使用している AppDynamics Controller のバージョンによっては、オプション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のアプローチを使用する必要があります。 - -オプション1を使用する利点は、エージェントがControllerに接続するように事前設定されていることです。一方、オプション2を使用する場合は、エージェントの設定を編集してControllerに接続する必要があります。 - -## Controller へのログイン - -Ciscoの認証情報を使用して [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインしてください。 - -## Getting Started Wizard への移動 - -1. 画面左上の **Home** タブを選択します。 -2. **Getting Started** タブを選択します。 -3. **Getting Started Wizard** をクリックします。 - -![Download Wizard](images/download-wizard-01.png) - -## ダウンロードするエージェントタイプの選択 - -1. **Servers** ボタンをクリックします。 - -![Servers](images/download-wizard-02.png) - -## Server Agent のダウンロード - -1. Platform BundleはLinuxと64-bitのままにします。 -2. Controller接続のデフォルトを受け入れます。 -3. **Click Here to Download** をクリックします。 - -![Download](images/download-wizard-03.png) - -Server Visibility Agentファイルをローカルワークステーションに保存します。 - -ブラウザがエージェントファイルをローカルファイルシステムに保存するようプロンプトを表示します。以下の画像のような表示になります（OSによって異なります）。 - -![Save Download](images/download-wizard-04.png) - -## Application VM への Server Agent のアップロード - -Server Agentファイルのアップロードプロセスは、ワークステーションのオペレーティングシステムによって異なります。OSがMAC/Linuxの場合はSCPを使用し、OSがWindowsの場合はWinSCPを使用してServer AgentのZIPファイルをコピーしてください。 - -## Server Agent のインストール - -Server Agentのzipファイルを解凍するディレクトリ構造を作成します。 - -```bash -cd /opt/appdynamics -mkdir machineagent -``` - -以下のコマンドを使用して、Server Visibility Agentのzipファイルをディレクトリにコピーし、ファイルを解凍します。Server Visibility Agentファイルの名前は、以下の例とは若干異なる場合があります（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 Agent の起動 - -以下のコマンドを使用して、Server Visibility Agentを起動し、起動したことを確認します。 - -```bash -cd /opt/appdynamics/machineagent/bin -nohup ./machine-agent & -ps -ef | grep machine -``` - -以下の画像のような出力が表示されるはずです。 - -![Install](images/svm-install-01.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-01.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-01.png deleted file mode 100644 index 2eb4637962..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-01.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-02.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-02.png deleted file mode 100644 index 8a3b801104..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-02.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-03.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-03.png deleted file mode 100644 index d625173cfb..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-03.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-04.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-04.png deleted file mode 100644 index 6e232812aa..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/download-wizard-04.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/svm-install-01.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/svm-install-01.png deleted file mode 100644 index 69547c8fde..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/2-deploy-server-agent-option-1/images/svm-install-01.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md deleted file mode 100644 index bfd1e5fac6..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/_index.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Machine Agent のデプロイ -time: 5 minutes -weight: 3 -description: Server Agent を手動でインストールします。 ---- - -この演習では、以下のアクションを実行します - -1. Machine Agentをインストールするスクリプトを実行する -2. Machine Agentを設定する -3. Machine Agentを起動する - -{{% notice title="注意" style="orange" %}} -スクリプトを使用してMachine AgentをEC2インスタンスにダウンロードします。通常は [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 -``` - -以下の画像のような出力が表示されるはずです。 - -![Install Output](images/install-script-output.png) - -## Server Agent の設定 - -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 -``` - -![Example Config](images/controller-example.png) - -## Server Visibility Agent の起動 - -以下のコマンドを使用して、Server Visibility Agentを起動し、起動したことを確認します。 - -```bash -cd /opt/appdynamics/machineagent/bin -nohup ./machine-agent & -ps -ef | grep machine -``` - -以下の画像のような出力が表示されるはずです。 - -![Example Output](images/run-machine-agent.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/controller-example.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/controller-example.png deleted file mode 100644 index 887df27dd8..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/controller-example.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/install-script-output.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/install-script-output.png deleted file mode 100644 index 58d490350c..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/install-script-output.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/run-machine-agent.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/run-machine-agent.png deleted file mode 100644 index 157e973051..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/3-deploy-server-agent/images/run-machine-agent.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md deleted file mode 100644 index 441e6cfc8f..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/_index.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: サーバーの健全性を監視する -time: 2 minutes -weight: 4 -description: この演習では、サーバーの健全性を監視するためのいくつかのダッシュボードを確認し、サーバーとアプリケーションのコンテキスト間を移動します。 ---- - -この演習では、以下のタスクを完了します - -- Server Mainダッシュボードを確認する -- Server Processesダッシュボードを確認する -- Server Volumesダッシュボードを確認する -- Server Networkダッシュボードを確認する -- サーバーとアプリケーションのコンテキスト間を移動する - -## Server Main Dashboard の確認 - -Machine Agentがインストールされたので、Server Visibilityモジュールで利用可能な機能のいくつかを見てみましょう。**Application Dashboard** から **Servers** タブをクリックし、以下のステップに従ってサーバーメインダッシュボードにドリルダウンします。 - -1. 左側のメニューで **Servers** タブをクリックします。 -2. サーバーの左側にある **checkbox** をチェックします。 -3. **View Details** をクリックします。 - -![Server Dashboard](images/svm-viewDetails.png) - -これでサーバーダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます - -選択した監視対象サーバーの主要なパフォーマンスメトリクスのチャートを表示します。これには以下が含まれます - -- サーバーの可用性 -- 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: サーバーの全体的な健全性を表示します -- Hierarchy: サーバーをグループ化するための任意の階層です。詳細については[こちら](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** をクリックして、このサーバーに対して現在アラートが発生している問題があるかどうかを確認します - -![Server Health](images/server-health.png) -![Server violations](images/server-health-violations.png) - -1. **CPU Usage too high** ルールをクリックします -2. **Edit Health Rule** をクリックします。**Edit Health Rule** パネルが開きます - -![Edit Health Rule](images/server-edit-hr.png) - -このパネルではHealth Ruleを設定できます。別のラボでHealth Ruleの作成とカスタマイズについて詳しく説明します。ここでは既存のルールを確認するだけにします。 - -1. **Warning Criteria** をクリックします - -![Edit Health Rule - Warning](images/server-warning.png) - -この例では、CPUが5%を超えたときに警告条件が設定されていることがわかります。これが、Health Ruleが正常な状態ではなく警告を表示している理由です。**Edit Health Rule** パネルをキャンセルして **Server Dashboard** に戻ります。 - -## Server Processes Dashboard の確認 - -1. **Processes** タブをクリックします。 -2. **View Options** をクリックして異なるデータカラムを選択します。表示可能なKPIを確認します。 - -これでサーバープロセスダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます - -- 選択した期間中にアクティブなすべてのプロセスを表示します。プロセスは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)をご覧ください。 - -![Dashboard Processes](images/server-process-dashboard.png) - -## Server Volumes Dashboard の確認 - -1. **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)をご覧ください。 - -![Dashboard Example](images/server-volumes.png) - -## Server Network Dashboard の確認 - -1. **Network** タブをクリックします。 - -これで **Server Network** ダッシュボードを探索できます。このダッシュボードでは、以下のタスクを実行できます - -- 各ネットワークインターフェースのMAC、IPv4、IPv6アドレスを確認できます。 -- ネットワークインターフェースが有効かどうか、機能しているかどうか、イーサネットケーブルが接続された動作状態、全二重または半二重モードで動作しているか、ネットワークインターフェースが渡すことができる最大プロトコルデータユニットの最大転送単位（MTU）またはサイズ（バイト単位）、Mbit/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)をご覧ください。 - -![Network Dashboard](images/server-network.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-edit-hr.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-edit-hr.png deleted file mode 100644 index a4191561a3..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-edit-hr.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-health-violations.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-health-violations.png deleted file mode 100644 index 75be740e86..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-health-violations.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-health.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-health.png deleted file mode 100644 index 04be6028dd..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-health.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-network.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-network.png deleted file mode 100644 index edeb4bc9b9..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-network.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-process-dashboard.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-process-dashboard.png deleted file mode 100644 index 250c127953..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-process-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-volumes.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-volumes.png deleted file mode 100644 index 115b50ea39..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-volumes.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-warning.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-warning.png deleted file mode 100644 index f5e17e0f1a..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/4-monitor-server-health/images/server-warning.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md deleted file mode 100644 index fce5d4e6bb..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/_index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: サーバーと APM の相関 -time: 3 minutes -weight: 5 -description: サーバーメトリクスとサーバー上で実行されているアプリケーション間の相関方法を確認します。 ---- - -## サーバーとアプリケーションのコンテキスト間の移動 - -Server Visibility Monitoringエージェントは、同じホスト上で実行されているSplunk AppDynamics APMエージェントと自動的に関連付けられます。 - -Server Visibilityを有効にすると、アプリケーションのコンテキストでサーバーパフォーマンスメトリクスにアクセスできます。さまざまな方法でサーバーとアプリケーションのコンテキストを切り替えることができます。以下のステップに従って、サーバーメインダッシュボードからサーバー上で実行されているNodeの1つに移動します。 - -1. **Dashboard** タブをクリックしてメインのServer Dashboardに戻ります。 -2. **APM Correlation** リンクをクリックします。 - -![Server to APM](images/server-apm-link.png) - -1. リストされているTierの1つで下矢印をクリックします。 -2. TierのNodeリンクをクリックします。 - -![Dashboard Example](images/server-tier-link.png) - -これで **Node Dashboard** に移動しました。 - -1. **Server** タブをクリックして関連するホストメトリクスを確認します。 - -![Dashboard Example](images/server-node-server.png) - -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/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-apm-link.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-apm-link.png deleted file mode 100644 index aa1355248a..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-apm-link.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-node-server.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-node-server.png deleted file mode 100644 index 5a42b7e79f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-node-server.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-tier-link.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-tier-link.png deleted file mode 100644 index 34bf9720e2..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/5-apm-to-server/images/server-tier-link.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/_index.md b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/_index.md deleted file mode 100644 index f59fe35bda..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/_index.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -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 %}} - -## 目標 - -このラボでは、AppDynamics Server Visibility MonitoringとService Availability Monitoringについて学びます。 - -このラボを完了すると、以下のことができるようになります - -- AppDynamics Server Visibility Agentをダウンロードする -- AppDynamics Server Visibility Agentをインストールする -- サーバーの健全性を監視する -- エージェントの拡張ハードウェアメトリクスを理解する -- アプリケーションパフォーマンスに影響を与えている基盤インフラストラクチャの問題を迅速に確認する - -## ワークショップ環境 - -ラボ環境には2つのホストがあります - -- 1つ目のホストはAppDynamics Controllerを実行しており、以降はControllerと呼びます。 -- 2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。このホストにAppDynamicsエージェントをインストールし、以降はApplication VMと呼びます。 - -## Controller - -このワークショップでは [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) を使用します。 - -![Controller](images/controller-vm.png) - -## Application VM - -Supercar TraderはJavaベースのWebアプリケーションです。 - -Supercar-Traderコレクションの目的は、AppDynamics Controllerに対して動的なトラフィック（ビジネストランザクション）を生成することです。 - -![Application VM](images/application-vm.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/images/application-vm.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/images/application-vm.png deleted file mode 100644 index 3152db2402..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/images/application-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/images/controller-vm.png b/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/images/controller-vm.png deleted file mode 100644 index b31c55d3b6..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/2-server-visibility-monitoring/images/controller-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md deleted file mode 100644 index abba0115c1..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/_index.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -title: ラボの前提条件 -time: 3 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時間にわたって一貫した負荷があったことを確認します。 - -![Verify Load 1](images/01-prereque-appload.png) - -ビジネストランザクションのリストを確認します - -1. 左メニューの **Business Transactions** オプションをクリックします。 -2. 下記に示す11個のビジネストランザクションが表示されていることを確認します。 -3. 過去1時間に何らかの呼び出し数があることを確認します。 - -**注意:** **Calls** 列が表示されない場合は、**View Options** ツールバーボタンをクリックしてその列を表示できます。 - -![Verify Business transactions](images/01-prereq-bts.png) - -Nodeのエージェントステータスを確認します - -1. 左メニューの **Tiers & Nodes** オプションをクリックします。 -2. **Grid View** をクリックします。 -3. 各Nodeの **App Agent Status** が過去1時間で90%以上であることを確認します。 - -![Verify Agents](images/01-prereq-tiersnodes.png) - -## 必要に応じてアプリケーションと負荷生成の再起動 - -前のステップで実行した確認のいずれかが検証できなかった場合は、**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 -``` - -以下の画像のような出力が表示されるはずです。 - -![Restart App 3](images/restart-app-and-load-03.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereq-bts.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereq-bts.png deleted file mode 100644 index 383cb29c68..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereq-bts.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereq-tiersnodes.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereq-tiersnodes.png deleted file mode 100644 index 11626f9886..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereq-tiersnodes.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereque-appload.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereque-appload.png deleted file mode 100644 index 409c41d897..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/01-prereque-appload.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-01.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-01.png deleted file mode 100644 index c8704770fc..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-01.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-02.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-02.png deleted file mode 100644 index 20d5aec2fe..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-02.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-03.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-03.png deleted file mode 100644 index 69051b3f57..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/1-lab-prerequisites/images/restart-app-and-load-03.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md deleted file mode 100644 index ac1469728e..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/2-enable-analytics/_index.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: アプリケーションでAnalyticsを有効化 -time: 2 minutes -weight: 2 -description: この演習では、WebブラウザからAppDynamics Controllerにアクセスし、エージェントレスAnalyticsを有効化します。 - ---- - -Analyticsは以前、Machine Agentにバンドルされた別のエージェントが必要でした。しかし、現在Analyticsはエージェントレスで、Controller 4.5.16以降の.NET Agent 20.10以降およびJava Agent 4.5.15以降のAPM Agentに組み込まれています。 - -この演習では、WebブラウザからAppDynamics Controllerにアクセスし、エージェントレス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** ボタンをクリックします。 - -![Enable Analytics](images/05-biq-transaction-analytics.png) - -## Transaction Summaryの検証 - -Analyticsがそのアプリケーションで機能し、トランザクションが表示されていることを確認します。 - -1. 左メニューの **Analytics tab** タブを選択します。 -2. **Home** タブを選択します。 -3. **Transactions from** でアプリケーション **Supercar-Trader-YOURINITIALS** にフィルターします。 - -![Validate Analytics](images/05-biq-transaction-analytics.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/2-enable-analytics/images/05-biq-transaction-analytics.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/2-enable-analytics/images/05-biq-transaction-analytics.png deleted file mode 100644 index ff0ef70a03..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/2-enable-analytics/images/05-biq-transaction-analytics.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md deleted file mode 100644 index 0cd2b9646d..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/_index.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: HTTPデータコレクターの設定 -time: 2 minutes -weight: 3 -description: この演習では、HTTPデータコレクターを有効化して使用します。 - ---- - -データコレクターを使用すると、ビジネストランザクションとTransaction Analyticsデータをアプリケーションデータで補完できます。アプリケーションデータは、ビジネストランザクションのパフォーマンス問題にコンテキストを追加できます。例えば、パフォーマンス問題の影響を受けたビジネストランザクションの特定のパラメータや戻り値（特定のユーザー、注文、製品など）を表示します。 - -HTTPデータコレクターは、ビジネストランザクションで交換されるHTTPメッセージのURL、パラメータ値、ヘッダー、Cookieをキャプチャします。 - -この演習では、以下のタスクを実行します - -* すべてのHTTPデータコレクターを有効化する。 -* 関連するHTTPデータコレクターを観察して選択する。 -* HTTPパラメータを使用してAnalyticsでビジネスデータをキャプチャする。 -* HTTPパラメータのAnalyticsを検証する。 - -## すべてのHTTPデータコレクターの有効化 - -最初に、すべてのHTTPデータコレクターをキャプチャして、Analyticsにキャプチャしてダッシュボードで使用できる有用なパラメータを把握します。 - -{{% notice title="Tip" 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** ボタンをクリックします。 - -![HTTPDataCollectors 1](images/05-biq-datacollectors.png) - -次に、すべての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** をクリックします。 - -![HTTPDataCollectors 2](images/05-biq-http-collector.png) - -1. "Ok"をクリックしてデータコレクターを確認します。 -2. **/Supercar-Trader/sell.do** トランザクションを有効にします。 -3. **Save** をクリックします。 - -![HTTPDataCollectors 2](images/05-biq-bt-enble.png) - -## 関連するHTTPデータコレクターの観察と選択 - -1. アプリケーションに負荷をかけ、特に **SellCar** トランザクションに負荷をかけます。Full Call Graphを含むスナップショットの1つを開き、**Data Collectors Tab** を選択します。 - -これですべてのHTTPパラメータを確認できます。Car Price、Color、Yearなど、多くの重要なメトリクスが表示されます。 - -1. 正確なパラメータ名をメモし、**HTTP Parameters** リストに再度追加してTransaction Analyticsで有効にします。 -2. 追加したら、**All HTTP Param** HTTPデータコレクターを削除します。 - -![HTTPDataCollectors 2](images/05-biq-snapshot-collector.png) - -## HTTPパラメータを使用したAnalyticsでのビジネスデータのキャプチャ - -次に、HTTPデータコレクターを再度設定しますが、今回は有用なHTTPパラメータのみをキャプチャしてTransaction Analyticsで有効にします。新しいHTTP Data Collectorを追加します：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** をクリックしてData Collectorの実装を確認します。 - -![SaveHttpDataCollectors](images/05-biq-httpcollector-cardetails.png) -![Car Params](images/05-biq-car-params.png) - -1. **/Supercar-Trader/sell.do** トランザクションを有効にします。 -2. **Save** をクリックします。 - -![HTTPDataCollectors 2](images/05-biq-cardetails-bt.png) - -1. **All HTTP Param** コレクターをクリックして選択し、**Delete** ボタンをクリックして削除します。 - -## HTTPパラメータのAnalyticsの検証 - -次に、ビジネスデータがHTTPデータコレクターによってAppDynamics Analyticsでキャプチャされたかどうかを検証します。 - -1. 画面左上の **Analytics** タブを選択します。 -2. **Searches** タブを選択します。 -3. **+ Add** ボタンをクリックし、新しい **Drag and Drop Search** を作成します。 - -![Drag and Drop Search](images/05-biq-search.png) - -1. **+ Add Criteria** をクリックします。 -2. **Application** を選択し、アプリケーション名 **Supercar-Trader-YOURINITIALS** を検索します。 -3. **Fields** パネルで、**Business Parameters** がCustom HTTP Request Dataのフィールドとして表示されていることを確認します。 -4. **CarPrice_http** のチェックボックスをオンにし、フィールドにデータがあることを確認します。 - -![ValidateHttpDataCollectors](images/05-biq-search-validation.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-bt-enble.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-bt-enble.png deleted file mode 100644 index a59c734faf..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-bt-enble.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-car-params.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-car-params.png deleted file mode 100644 index 783e630e32..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-car-params.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-cardetails-bt.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-cardetails-bt.png deleted file mode 100644 index fb657fbc6e..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-cardetails-bt.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-datacollectors.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-datacollectors.png deleted file mode 100644 index defc7b4101..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-datacollectors.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-http-collector.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-http-collector.png deleted file mode 100644 index 3f213f1810..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-http-collector.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-httpcollector-cardetails.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-httpcollector-cardetails.png deleted file mode 100644 index 051597f992..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-httpcollector-cardetails.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-search-validation.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-search-validation.png deleted file mode 100644 index a3d129b104..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-search-validation.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-search.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-search.png deleted file mode 100644 index 5757f8b9f5..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-search.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-snapshot-collector.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-snapshot-collector.png deleted file mode 100644 index 58cff3fbc8..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/3-configure-http-data-collectors/images/05-biq-snapshot-collector.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md deleted file mode 100644 index 48749bd940..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/_index.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: メソッドデータコレクターの設定 -time: 2 minutes -weight: 4 -description: この演習では、WebブラウザからAppDynamics Controllerにアクセスし、エージェントレスAnalyticsを有効化します。 ---- - -メソッド呼び出しデータコレクターは、メソッド引数、変数、戻り値などのコードデータをキャプチャします。HTTPデータコレクターに十分なビジネスデータがない場合でも、コード実行からこれらの情報をキャプチャできます。 - -この演習では、以下のタスクを実行します - -* メソッドを発見する。 -* ディスカバリーセッションを開く。 -* メソッドパラメータを発見する。 -* コード内のオブジェクトにドリルダウンする。 -* メソッド呼び出しデータコレクターを作成する。 -* メソッド呼び出しデータコレクターのAnalyticsを検証する。 - -## ディスカバリーセッションを開く - -ソースコードからメソッドやパラメータを特定するアプリケーション開発者がいない場合があります。しかし、AppDynamicsから直接アプリケーションメソッドとオブジェクトを発見するアプローチがあります。 - -1. 画面左上の **Applications** タブを選択します。 -2. **Supercar-Trader-YOURINITIALS** アプリケーションを選択します。 -3. **Configuration** タブを選択します。 -4. **Instrumentation** リンクをクリックします。 -5. **Transaction Detection** タブを選択します。 -6. 右側の **Live Preview Button** をクリックします。 - -![OpenDiscoverySession](images/05-live-preview.png) - -1. **Start Discovery Session** ボタンをクリックします。 -2. ポップアップウィンドウで **Web-Portal Node** を選択します。調査しているメソッドが実行されているのと同じNodeである必要があります。 -3. **Ok** をクリックします。 - -![OpenDiscoverySession](images/05-biq-trans-disco.png) - -1. 右側のトグルで **Tools** を選択します。 -2. ドロップダウンリストで **Classes/Methods** を選択します。 -3. **Search** セクションで **Classes** with nameを選択します。 -4. テキストボックスにクラス名 **supercars.dataloader.CarDataLoader** を入力します。クラス名を見つけるには、コールグラフを検索するか、理想的にはソースコードで見つけます。 -5. **Apply** をクリックして一致するクラスメソッドを検索します。 -6. 結果が表示されたら、検索に一致するクラスを展開します。 -7. 同じメソッド **saveCar** を探します。 - -![OpenDiscoverySession](images/05-biq-trans-disco-config.png) - -**saveCar** メソッドは入力パラメータとして **CarForm** オブジェクトを取ることに注意してください。 - -## オブジェクトへのドリルダウン - -メソッドを見つけたら、そのパラメータを調べて車の詳細プロパティを取得できる場所を見つけます。 - -**saveCar** メソッドは入力パラメータとして複合オブジェクト **CarForm** を取ることがわかりました。このオブジェクトにはアプリケーションWebページで入力されたフォームデータが保持されます。次に、そのオブジェクトを検査して、車の詳細をどのように取得できるかを見つける必要があります。 - -1. テキストボックスに入力オブジェクトのクラス名 **supercars.form.CarForm** を入力します。 -2. **Apply** をクリックしてクラスメソッドを検索します。 -3. 結果が表示されたら、検索に一致する **supercars.form.CarForm** クラスを展開します。 -4. 必要な車の詳細を返すメソッドを探します。price、model、colorなどの **get** メソッドが見つかります。 - -![ObjectDrillDown](images/05-biq-object-drilldown.png) - -## メソッド呼び出しデータコレクターの作成 - -前の演習で得た知見を使用して、実行時に実行中のコードから車の詳細を直接取得するメソッド呼び出しデータコレクターを設定できます。 - -1. **Applications** タブを選択します。 -2. **Supercar-Trader-YOURINITIALS** アプリケーションを選択します。 -3. **Configuration** タブを選択します。 -4. **Instrumentation** リンクをクリックします。 -5. **Data Collectors** タブを選択します。 -6. **Method Invocation Data Collectors** の **Add** をクリックします。 - -![MIDCDataCollector](images/05-biq-method-collector.png) - -車の詳細をキャプチャするメソッド呼び出しデータコレクターを作成します。 - -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** を追加します。 - -![NewMIDCDataCollector](images/05-biq-midc-config.png) - -観察したように、SaveCarメソッドのインデックス0の入力パラメータはクラス **CarForm** のオブジェクトであり、そのオブジェクト内には **getPrice()** などの車の詳細プロパティを返すGetterメソッドがあります。 - -MIDCでその値をどのように取得したかを説明すると、以下のようになります - -1. MIDCパネルの下部にある **Add** をクリックして、収集する新しいデータを指定します。 -2. Display Nameに **CarPrice_MIDC** を指定します。 -3. Collect Data Fromで、**CarForm Object** である **Method Parameter of Index 0** を選択します。 -4. **Operation on Method Parameter** で **Use Getter Chain** を選択します。CarForm内のメソッドを呼び出して車の詳細を返します。 -5. 次に、価格を返す **CarForm** クラス内のGetterメソッド **getPrice()** を指定します。 -6. **Save** をクリックします。 - -![CreateMIDCDataCollector1](images/05-biq-midc-datacoll.png) - -1. color、modelなど、データを収集したいすべてのプロパティについて、上記の手順を繰り返します。 - -![CreateMIDCDataCollector2](images/05-biq-midc-details.png) - -1. **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パラメータのAnalyticsの検証 - -Webサイトにアクセスし、Sell Carページでフォームを数回送信して手動で負荷をかけます。 - -次に、ビジネスデータがHTTPデータコレクターによってAppDynamics Analyticsでキャプチャされたかどうかを検証します。 - -1. **Analytics** タブを選択します。 -2. **Searches** タブを選択し、新しい **Drag and Drop Search** を追加します。 -3. **+ Add** ボタンをクリックし、新しい **Drag and Drop Search** を作成します。 -4. **+ Add Criteria** をクリックします。 -5. **Application** を選択し、アプリケーション名 **Supercar-Trader-YOURINITIALS** を検索します。 -6. **Business Parameters** が **Custom Method Data** のフィールドとして表示されていることを確認します。 -7. **CarPrice Field** にデータがあることを確認します。 - -![ValidateMIDCDataCollector](images/05-biq-search-results.png) - -## まとめ - -これで、実行時にNodeからSell Carトランザクションのビジネスデータをキャプチャしました。このデータは、AppDynamicsのAnalyticsおよびダッシュボード機能で使用でき、ビジネスにより多くのコンテキストを提供し、ITがビジネスに与える影響を測定できます。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-method-collector.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-method-collector.png deleted file mode 100644 index 5b3e530314..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-method-collector.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-config.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-config.png deleted file mode 100644 index 228e513642..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-config.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-datacoll.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-datacoll.png deleted file mode 100644 index 066aea42c6..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-datacoll.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-details.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-details.png deleted file mode 100644 index eef4657d0d..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-midc-details.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-object-drilldown.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-object-drilldown.png deleted file mode 100644 index 8be76b379f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-object-drilldown.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-search-results.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-search-results.png deleted file mode 100644 index 631c96b4fd..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-search-results.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-trans-disco-config.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-trans-disco-config.png deleted file mode 100644 index 278f51c6f0..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-trans-disco-config.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-trans-disco.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-trans-disco.png deleted file mode 100644 index 8efd775562..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-biq-trans-disco.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-live-preview.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-live-preview.png deleted file mode 100644 index 1525885a9f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/4-configure-method-data-collectors/images/05-live-preview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md deleted file mode 100644 index 556e292372..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/_index.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -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** をクリックします。 - -![NewDashboard](images/05-biq-create-dashboard.png) - -新しく作成した空のダッシュボードを開きます。次に、さまざまなウィジェットタイプを追加します。 - -## ダッシュボードコンポーネント：カスタムウィジェットビルダー - -カスタムウィジェットビルダーは、数値ビュー、時系列、円グラフなど、データの表現を生成できる非常に柔軟なツールです。AppDynamics ADクエリ言語に基づいています。 - -ウィジェットを作成するには、以下の手順に従います - -1. ダッシュボードの左上隅にある **Edit Mode** を切り替えます。 -2. **Add Widget** をクリックします。 -3. 左側の **Analytics** タブを選択します。 -4. **Custom Widget Builder** をクリックします。 - -![NewCustomWidgetBuilder](images/05-biq-widget-builder.png) - -カスタムウィジェットビルダーでは、多くのチャートタイプを作成できます。情報をドラッグアンドドロップするか、Advancedペインでクエリを作成できます。 - -![NewCustomWidgetBuilder](images/05-biq-add-widget.png) - -ここでは、数値チャート、棒グラフ、円グラフについて説明します。 - -### 数値チャート - -**演習：** エラーによって影響を受けた金額を定量化することで、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** をクリックします。 - -![NumericChartWidget](images/05-biq-lost-revenue.png) - -User ExperienceフィルターをNORMAL、SLOW、VERY SLOWのみに変更することで、**正常に処理された金額**についても同様のことができます。 - -また、Analyticsモジュールでカスタムメトリクスを作成し、**影響を受けた金額**がベースライン以上かどうかを示すヘルスルールを定義することで、このメトリクスをベースライン化することもできます。通貨のラベルを追加することもできます。 - -![NumericChartSamples](images/06-numeric-chart-widget-samples-09.png) - -### 棒グラフ - -**演習：** 次に、影響を受けた車種のトップを視覚化する棒グラフを作成します。このチャートは、User Experienceで分類されたすべての **SellCar** トランザクションの車種を表示します。 - -1. **+ Add Widget**、**Analytics**、**Custom Widger Builder** をクリックして新しいウィジェットを作成します。 -2. **Column** チャートタイプを選択します。 -3. 以下のフィルターを追加します：Application = **Supercar-Trader-YOURINITIALS** およびBusiness Transaction = **/Supercar-Trader/sell.do**。 -4. X軸に **CarModel\_MIDC** と **User Experience** を追加します。 -5. **Save** をクリックします。 - -![BarChartWidget](images/05-biq-bar-chart.png) - -このチャートタイプは、ニーズに応じて調整できます。例えば、X軸を顧客タイプ、会社、組織などでグループ化できます。以下の例を参照してください。 - -![BarChartSamples](images/06-bar-chart-widget-samples-05.png) - -### 円グラフ - -次に、`sellCar` トランザクションによって報告されたすべての車種とモデルごとの価格の合計を表示する円グラフを作成します。これにより、アプリケーションで最も需要の高いモデルが表示されます。 - -1. 新しいウィジェットを作成します。 -2. **Pie** チャートタイプを選択します。 -3. 以下のフィルターを追加します：Application = **Supercar-Trader-YOURINITIALS** およびBusiness Transaction = **/Supercar-Trader/sell.do**。 -4. X軸に **CarModel\_MIDC** を追加します。 -5. Y軸に **CarPrice\_MIDC** を追加します。**SUM** がモデルごとの合計価格をキャプチャするために使用される集計であることに注意してください。 -6. タイトルに **Sold by Car Model** を追加します。 -7. **Save** をクリックします。 - -![PieChartWidget](images/05-biq-pie-chart.png) - -円グラフウィジェットのその他の使用例については、以下の例を参照してください。 - -![PieChartSamples](images/06-pie-chart-widget-samples-07.png) - -## ダッシュボードコンポーネント：コンバージョンファネル - -コンバージョンファネルは、複数のステップからなるプロセスを通じたユーザーまたはイベントのフローを視覚化するのに役立ちます。これにより、より成功した収束のためにどのステップを最適化できるかをより良く理解できます。また、コンバージョンファネルを使用して各ステップの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** をクリックします。 - -![EnableSessionId](images/05-biq-session-id.png) - -次に、**/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** をクリックします。 - -![FunnelWidget](images/05-biq-funnel-chart.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-add-widget.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-add-widget.png deleted file mode 100644 index d6f42896f5..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-add-widget.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-bar-chart.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-bar-chart.png deleted file mode 100644 index c82a13355c..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-bar-chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-create-dashboard.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-create-dashboard.png deleted file mode 100644 index fe46449d54..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-create-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-funnel-chart.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-funnel-chart.png deleted file mode 100644 index bddaf8e010..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-funnel-chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-lost-revenue.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-lost-revenue.png deleted file mode 100644 index cf06dfc845..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-lost-revenue.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-pie-chart.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-pie-chart.png deleted file mode 100644 index 67c9c2c830..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-pie-chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-session-id.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-session-id.png deleted file mode 100644 index e31ba5a805..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-session-id.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-widget-builder.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-widget-builder.png deleted file mode 100644 index b26ace301f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/5-dashboard-components/images/05-biq-widget-builder.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md deleted file mode 100644 index 5970f4d2c3..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/6-build-your-dashboard/_index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: ダッシュボードを構築する -time: 20 minutes -weight: 6 -description: この演習では、前の演習でメソッド呼び出しデータコレクターを使用してキャプチャしたビジネスデータとダッシュボードコンポーネントの理解を使用して、ITビジネスインパクトダッシュボードを構築します。 ---- - -## 演習 - 独自のダッシュボードを構築する - -このラーニングラボの締めくくりとして、前の演習でメソッド呼び出しデータコレクターを使用してキャプチャしたビジネスデータとダッシュボードコンポーネントの理解を使用して、ITビジネスインパクトダッシュボードを構築します。 - -以下の例を参照し、同じデータとウィジェットを使用して独自のダッシュボードを構築してください。 - -![DiscoverCallGraphMethods 1](images/06-BusinessDashboard-01.png) - -**おめでとうございます！BusinessIQ Fundamentalsラーニングラボを完了しました！** diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/6-build-your-dashboard/images/06-BusinessDashboard-01.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/6-build-your-dashboard/images/06-BusinessDashboard-01.png deleted file mode 100644 index 1100fc3181..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/6-build-your-dashboard/images/06-BusinessDashboard-01.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/_index.md b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/_index.md deleted file mode 100644 index 611efebf3c..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/_index.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Business iQ -time: 2 minutes -weight: 3 -description: このラーニングラボでは、AppDynamics Business iQについて学習します。 ---- - -## 目標 - -このラーニングラボでは、AppDynamics Business iQについて学習します。 - -このラボを完了すると、以下のことができるようになります - -* 新しいエージェントレスAnalytics Java Agent（v 4.5.15以降）でAnalyticsを有効化する。 -* HTTPデータコレクターを設定する。 -* メソッド呼び出しデータコレクターを設定する。 -* ダッシュボードコンポーネントを理解する。 -* ビジネスダッシュボードを構築する。 - -## ワークショップ環境 - -ラボ環境には2つのホストがあります - -* 1つ目のホストはAppDynamics Controllerを実行しており、以降Controllerと呼びます。 -* 2つ目のホストはラボで使用するSupercar Traderアプリケーションを実行しています。このホストにAppDynamicsエージェントをインストールし、以降Application VMと呼びます。 - -#### Controller VM - -![image](images/controller-vm.png) - -#### Application VM - -![image](images/application-vm.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/images/application-vm.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/images/application-vm.png deleted file mode 100644 index 3152db2402..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/images/application-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/images/controller-vm.png b/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/images/controller-vm.png deleted file mode 100644 index 21b0cce620..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/3-business-iq/images/controller-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md deleted file mode 100644 index 7379c4a455..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/_index.md +++ /dev/null @@ -1,119 +0,0 @@ ---- -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時間にわたって一貫した負荷があったことを確認します。 - -![Verify Load 1](images/01-prereque-appload.png) - -ビジネストランザクションのリストを確認します - -1. 左メニューの **Business Transactions** オプションをクリックします。 -2. 下記に示す11個のビジネストランザクションが表示されていることを確認します。 -3. 過去1時間に何らかの呼び出し数があることを確認します。 - -**注意:** **Calls** 列が表示されない場合は、**View Options** ツールバーボタンをクリックしてその列を表示できます。 - -![Verify Business transactions](images/01-prereq-bts.png) - -Nodeのエージェントステータスを確認します - -1. 左メニューの **Tiers & Nodes** オプションをクリックします。 -2. **Grid View** をクリックします。 -3. 各Nodeの **App Agent Status** が過去1時間で90%以上であることを確認します。 - -![Verify Agents](images/01-prereq-tiersnodes.png) - -## 必要に応じてアプリケーションと負荷生成の再起動 - -前のステップで実行した確認のいずれかが検証できなかった場合は、**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によって使用されていることが確認できるはずです。 - -![Restart App 1](images/restart-app-and-load-01.png) - -以下のコマンドを使用して、アプリケーションの負荷生成を開始します。 - -``` bash -cd /opt/appdynamics/lab-artifacts/phantomjs -./start_load.sh -``` - -以下の画像のような出力が表示されるはずです。 - -![Restart App 3](images/restart-app-and-load-03.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereq-bts.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereq-bts.png deleted file mode 100644 index 383cb29c68..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereq-bts.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereq-tiersnodes.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereq-tiersnodes.png deleted file mode 100644 index 11626f9886..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereq-tiersnodes.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereque-appload.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereque-appload.png deleted file mode 100644 index 409c41d897..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/01-prereque-appload.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png deleted file mode 100644 index c8704770fc..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png deleted file mode 100644 index 20d5aec2fe..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png deleted file mode 100644 index 69051b3f57..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md deleted file mode 100644 index 2da49fff42..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/_index.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: ブラウザアプリケーションの作成 -time: 2 minutes -weight: 2 -description: この演習では、Controllerでアプリケーションを作成および設定します。 ---- - -この演習では、以下のタスクを完了します - -* WebブラウザからAppDynamics Controllerにアクセスする。 -* ControllerでBrowser Applicationを作成する。 -* Browser Applicationを設定する。 - -## Controllerへのログイン - -Ciscoの認証情報を使用して[AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/)にログインします。 - -## ControllerでのBrowser Applicationの作成 - -以下の手順に従って、新しいブラウザアプリケーションを作成します。 - -{{% 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** をクリックします。 - -![Create App](images/02-brum-create-app.png) - -これで **Supercar-Trader-Web-##-####** アプリケーションの **Browser App Dashboard** が表示されるはずです。 - -1. 左メニューの **Configuration** タブをクリックします。 -2. **Instrumentation** オプションをクリックします。 - -![Instrumentation](images/02-brum-instrument.png) - -以下の手順に従って、ブラウザ監視エージェントによってキャプチャされるデータと一緒に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)をご覧ください。 - -![IPAddress Config](images/02-brum-ipaddress.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-create-app.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-create-app.png deleted file mode 100644 index 1c8eb20f43..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-create-app.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-instrument.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-instrument.png deleted file mode 100644 index a82c5be38d..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-instrument.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-ipaddress.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-ipaddress.png deleted file mode 100644 index 7724f1f67d..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/2-create-browser-application/images/02-brum-ipaddress.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md deleted file mode 100644 index 2d254848b1..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/_index.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: エージェントインジェクションの設定 -time: 3 minutes -weight: 3 -description: この演習では、JavaScript Injectionを有効化し、インジェクション用のBTを選択します。 ---- - -この演習では、以下のタスクを完了します - -* JavaScript Agentインジェクションを有効化する。 -* インジェクション用のビジネストランザクションを選択する。 - -## JavaScript Agentインジェクションの有効化 - -AppDynamicsはJavaScript Agentをインジェクトするさまざまな方法をサポートしていますが、このラボではAuto-Injection方式を使用します。以下の手順に従ってJavaScript Agentの自動インジェクションを有効化します。 - -1. 左メニューの **Applications** タブをクリックし、Supercar-Trader-##アプリケーションにドリルダウンします。 -2. 下部にある左メニューの **Configuration** タブをクリックします。 -3. **User Experience App Integration** オプションをクリックします。 - -![BRUM Dash 1](images/03-brum-app-integration.png) - -1. **JavaScript Agent Injection** タブをクリックします。 -2. **Enable** をクリックして青色に切り替えます。 -3. **Supercar-Trader-Web-##-####** が選択されたブラウザアプリであることを確認します。前のセクションで作成したアプリケーションを選択してください。 -4. **Enable JavaScript Injection** の下にある **Enable** チェックボックスをオンにします。 -5. **Save** をクリックします。 - -![BRUM Dash 2](images/03-brum-agent-injection.png) - -Auto-Injectionが潜在的なビジネストランザクションを検出するまで数分かかります。この間に、以下の手順でBusiness Transaction Correlationを有効化します。新しいAPMエージェントでは、これは自動的に行われます。 - -1. **Business Transaction Correlation** タブをクリックします。 -2. **Manually Enable Business Transactions** セクションの下にある **Enable** ボタンをクリックします。 -3. **Save** をクリックします。 - -![BRUM Dash 3](images/03-brum-bt-manual.png) - -## インジェクション用のビジネストランザクションの選択 - -以下の手順に従って、Auto-Injection用のビジネストランザクションを選択します。 - -1. **JavaScript Agent Injection** タブをクリックします。 -2. 検索ボックスに **.do** と入力します。 -3. すべての9つのBTが表示されるまで **Refresh List** リンクをクリックします。 -4. 右側のリストボックスからすべてのビジネストランザクションを選択します。 -5. 矢印ボタンをクリックして左側のリストボックスに移動します。 -6. すべてのビジネストランザクションが左側のリストボックスに移動されていることを確認します。 -7. **Save** をクリックします。 - -JavaScript Agentの自動インジェクションの設定について詳しくは、[**こちら**](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)をご覧ください。 - -![BRUM Dash 5](images/03-brum-bts-auto-inject.png) - -ブラウザアプリケーションに負荷が表示され始めるまで数分待ちます。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-agent-injection.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-agent-injection.png deleted file mode 100644 index 03e8c7fa45..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-agent-injection.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-app-integration.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-app-integration.png deleted file mode 100644 index 2e67ae2e97..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-app-integration.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-bt-manual.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-bt-manual.png deleted file mode 100644 index 88a09cd82b..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-bt-manual.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-bts-auto-inject.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-bts-auto-inject.png deleted file mode 100644 index 3c44d2d812..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/3-configure-agent-injection/images/03-brum-bts-auto-inject.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md deleted file mode 100644 index 240b6e3621..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/_index.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -title: 監視とトラブルシューティング - パート1 -time: 2 minutes -weight: 4 -description: この演習では、ダッシュボードをレビューし、デモアプリをナビゲートします。 ---- - -この演習では、以下のタスクを完了します - -* Browser Application Overviewダッシュボードをレビューする -* Browser Application Geoダッシュボードをレビューする -* Browser Application Usage Statsダッシュボードをレビューする -* Supercar-Traderアプリケーションのウェブページをナビゲートする - -## Browser Application Overviewダッシュボードのレビュー - -User Experienceダッシュボードに移動し、以下の手順に従ってブラウザアプリケーションのOverviewダッシュボードにドリルダウンします。 - -1. 左メニューの **User Experience** タブをクリックします。 -2. Webアプリケーション **Supercar-Trader-Web-##-###** を検索します。 -3. **Details** をクリックするか、アプリケーション名をダブルクリックします。 - -![BRUM Dash 1](images/04-brum-app.png) - -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)をご覧ください。 - -![BRUM Dash 2](images/04-brum-overview.png) - -## Browser Application Geoダッシュボードのレビュー - -Geoダッシュボードは、ページロードに基づいて地理的な場所ごとに主要なパフォーマンスメトリクスを表示します。ダッシュボード全体に表示されるメトリクスは、マップまたはグリッドで現在選択されているリージョンのものです。マップビューは、右側のパネルに表示されるキータイミングメトリクスの国に対してラベル付きの負荷円を表示します。ただし、一部の国とリージョンはグリッドビューでのみ表示されます。 - -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)をご覧ください。 - -![BRUM Dash 3](images/04-brum-geomap.png) - -## Browser Application Usage Statsダッシュボードのレビュー - -**Usage Stats** ダッシュボードは、ユーザーのブラウザタイプとデバイス/プラットフォームに基づいて集約されたページロード使用データを表示します。 - -Browser Application Usage Statsダッシュボードは、以下のことを発見するのに役立ちます - -* 合計エンドユーザー応答時間の面で最も遅いブラウザ。 -* 応答ページをレンダリングするのに最も遅いブラウザ。 -* エンドユーザーの大半が使用しているブラウザ。 -* 特定の国やリージョンでエンドユーザーの大半が使用しているブラウザ。 - -Browser Application Usage Statsダッシュボードに移動し、以下に説明するダッシュボードの機能を探索します。 - -1. **Usage Stats** オプションをクリックします。 -2. **Show Versions** オプションをクリックします。 -3. 負荷ごとにさまざまなブラウザとバージョンを確認します。 -4. 円グラフのセクションにカーソルを合わせて詳細を確認します。 - -![BRUM Dash 4](images/04-brum-usage-stats.png) - -以下の手順を使用して、ブラウザとバージョンごとのその他のメトリクスを探索します。 - -1. 右側のスクロールバーを使用してページの下部までスクロールします。 -2. ブラウザとバージョンごとの利用可能なメトリクスを探索します。 -3. 国ごとの利用可能なメトリクスを探索します。 - -![BRUM Dash 5](images/04-brum-usage-stats2.png) - -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)をご覧ください。 - -![BRUM Dash 6](images/04-brum-device.png) - -## 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 -``` - -アプリケーションのホームページが表示されるはずです。 - -![App Page 1](images/04-brum-supercar-homepage.jpeg) - -利用可能なフェラーリのリストを開きます。 - -1. トップメニューの **Supercars** タブをクリックします。 -2. フェラーリのロゴをクリックします。 - -![App Page 2](images/05-app-page-02.png) - -フェラーリのリストが表示されるはずです。 - -![App Page 3](images/05-app-page-03.png) - -最初のフェラーリの画像をクリックします。 - -1. **View Enquiries** をクリックします。 -2. **Enquire** をクリックします。 - -![App Page 4](images/05-app-page-04.png) - -車に関する問い合わせを送信します。 - -1. 問い合わせフォームのフィールドに適切なデータを入力します。 -2. **Submit** をクリックします。 - -![App Page 5](images/05-app-page-05.png) - -車を検索し、サイトの閲覧を続けます。 - -1. トップメニューの **Search** タブをクリックします。 -2. 検索ボックスに文字 **A** を入力し、**Search** をクリックします。 -3. 残りのタブをクリックしてWebサイトを探索します。 - -![App Page 6](images/05-app-page-06.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-app.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-app.png deleted file mode 100644 index 1deee92e75..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-app.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-device.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-device.png deleted file mode 100644 index d4d0d8fd2e..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-device.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-geomap.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-geomap.png deleted file mode 100644 index 6061acbc1e..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-geomap.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-overview.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-overview.png deleted file mode 100644 index 9e53272b2e..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-overview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-supercar-homepage.jpeg b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-supercar-homepage.jpeg deleted file mode 100644 index b4ffd83e54..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-supercar-homepage.jpeg and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-usage-stats.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-usage-stats.png deleted file mode 100644 index ab96c9528c..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-usage-stats.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-usage-stats2.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-usage-stats2.png deleted file mode 100644 index b68ceb4f66..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/04-brum-usage-stats2.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-02.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-02.png deleted file mode 100644 index d2d64dfcd4..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-02.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-03.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-03.png deleted file mode 100644 index 400349e94e..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-03.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-04.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-04.png deleted file mode 100644 index 0ed1af9dcf..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-04.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-05.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-05.png deleted file mode 100644 index cd59121533..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-05.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-06.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-06.png deleted file mode 100644 index 8a0e3dc590..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/4-monitor-and-troubleshoot-part-1/images/05-app-page-06.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md deleted file mode 100644 index dff91faa45..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/_index.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: 監視とトラブルシューティング - パート2 -time: 2 minutes -weight: 5 -description: この演習では、ダッシュボードをレビューし、Browser Snapshotをトラブルシューティングします。 ---- - -この演習では、以下のタスクを完了します - -* 作成したBrowser Sessionをレビューする。 -* Pages & AJAX Requestsダッシュボードをレビューする。 -* 特定の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アドレスのチェックをオンにします。 -3. IPアドレスで作成したセッションを見つけます。 -4. セッションをクリックし、**View Details** をクリックします。 - -![BRUM Dash 1](images/05-brum-sessions.png) - -作成したセッションを見つけて開いたら、以下の手順に従ってセッションビューのさまざまな機能を探索します。 - -> _注意:_ ステップ5に示されているように、セッション内のどのページにも **View Snapshot** リンクがない場合があります。後でこの演習で、リンクがあるセッションを見つけて探索します。 - -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)をご覧ください。 - -![BRUM Dash 2](images/05-brum-session-details.png) - -## Pages & AJAX Requestsダッシュボードのレビュー - -Pages & AJAX Requestsダッシュボードに移動し、そこにあるオプションを確認し、以下の手順に従って特定のBase Pageダッシュボードを開きます。 - -1. 左メニューの **Pages & AJAX Requests** タブをクリックします。 -2. ツールバーのオプションを探索します。 -3. **localhost:8080/supercar-trader/car.do** ページをクリックします。 -4. **Details** をクリックしてBase Pageダッシュボードを開きます。 - -![BRUM Dash 3](images/05-brum-ajax-list.png) - -## 特定の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)をご覧ください。 - -![BRUM Dash 4](images/05-brum-main-page-summary.png) - -## Browser Snapshotのトラブルシューティング - -{{% notice title="Note" style="orange" %}} -アプリケーションにブラウザスナップショットがない場合があり、その場合はワークフロー全体を実行できません。このセクションを別のデモアプリケーションで実行したい場合は、ブラウザアプリケーション **AD-Ecommerce-Browser** に切り替えることができます。 -{{% /notice %}} - -Browser Snapshotsリストダッシュボードに移動し、以下の手順に従って特定のBrowser Snapshotを開きます。 - -1. **Browser Snapshots** オプションをクリックします。 -2. **End User Response Time** 列ヘッダーを2回クリックして、最も長い応答時間を上部に表示します。 -3. 左から3番目の列にグレーまたは青のアイコンがあるブラウザスナップショットをクリックします。 -4. **Details** をクリックしてブラウザスナップショットを開きます。 - -![BRUM Dash 6](images/06-brum-dashboard-06.png) - -ブラウザスナップショットを開いたら、詳細を確認し、以下の手順に従って長い応答時間の根本原因を見つけます。 - -1. ウォーターフォールビューを確認して、応答時間がどこで影響を受けたかを理解します。 -2. **Server Time** メトリクスが長くなっていることに注意してください。**Server Time** のラベルにカーソルを合わせてその意味を理解します。 -3. ブラウザスナップショットに自動的にキャプチャされ相関付けられたサーバー側トランザクションをクリックします。 -4. **View Details** をクリックして、関連するサーバー側スナップショットを開きます。 - -![BRUM Dash 7](images/06-brum-dashboard-07.png) - -相関するサーバー側スナップショットを開いたら、以下の手順を使用してパフォーマンス低下の根本原因を特定します。 - -1. ブラウザで費やされたトランザクション時間の割合が最小限であることがわかります。 -2. ブラウザとWeb-Portal Tier間のタイミングは、ブラウザからの初期接続から完全な応答が返されるまでを表しています。 -3. JDBCコールが最も時間がかかっていたことがわかります。 -4. **Drill Down** をクリックして、Enquiry-Services Tier内のコードレベルビューを確認します。 - -![BRUM Dash 8](images/06-brum-dashboard-08.png) - -Enquiry-Services Tierのスナップショットセグメントを開くと、データベースへのJDBCコールがトランザクションの問題を引き起こしていたことがわかります。 - -1. 最も時間がかかった **JDBC** リンクをクリックして、JDBCコールの詳細パネルを開きます。 -2. JDBC exit callの詳細パネルには、最も時間がかかった特定のクエリが表示されます。 -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)をご覧ください。 - -![BRUM Dash 9](images/06-brum-dashboard-09.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-ajax-list.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-ajax-list.png deleted file mode 100644 index 0d88db7228..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-ajax-list.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-main-page-summary.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-main-page-summary.png deleted file mode 100644 index b14cb98e08..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-main-page-summary.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-session-details.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-session-details.png deleted file mode 100644 index a127a57e71..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-session-details.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-sessions.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-sessions.png deleted file mode 100644 index f826b42664..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/05-brum-sessions.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-06.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-06.png deleted file mode 100644 index aacc1aacbf..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-06.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-07.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-07.png deleted file mode 100644 index 24a5fc08e3..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-07.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-08.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-08.png deleted file mode 100644 index 55c7fab4d1..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-08.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-09.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-09.png deleted file mode 100644 index f1e5bb2a2b..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/5-monitor-and-troubleshoot-part-2/images/06-brum-dashboard-09.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/_index.md b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/_index.md deleted file mode 100644 index 38c82ad4f5..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/_index.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Browser Real User Monitoring (BRUM) -time: 2 minutes -weight: 4 -description: このラーニングラボでは、AppDynamicsを使用してブラウザベースのアプリケーションの正常性を監視する方法を学習します。 ---- - -## 目標 - -このラーニングラボでは、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/)を使用します。 - -![Controller](images/controller-vm.png) - -## Application VM - -Supercar TraderはJavaベースのWebアプリケーションです。 - -Supercar-Traderコレクションの目的は、AppDynamics Controllerの動的なトラフィック（ビジネストランザクション）を生成することです。 - -![Application VM](images/application-vm.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/images/application-vm.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/images/application-vm.png deleted file mode 100644 index 3152db2402..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/images/application-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/images/controller-vm.png b/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/images/controller-vm.png deleted file mode 100644 index 1e9998cab8..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/4-brum-monitoring/images/controller-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md deleted file mode 100644 index e9f6a58b9c..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/_index.md +++ /dev/null @@ -1,119 +0,0 @@ ---- -title: ラボの前提条件 -time: 3 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つの異なるティアが表示されていることを確認します。 -3. 過去1時間にわたって一貫した負荷があったことを確認します。 - -![Verify Load 1](images/01-prereque-appload.png) - -ビジネストランザクションのリストを確認します - -1. 左メニューの **Business Transactions** オプションをクリックします。 -2. 以下に示す11個のビジネストランザクションが表示されていることを確認します。 -3. 過去1時間にいくらかの呼び出し回数があることを確認します。 - -**注意:** **Calls** 列が表示されていない場合は、**View Options** ツールバーボタンをクリックしてその列を表示できます。 - -![Verify Business transactions](images/01-prereq-bts.png) - -ノードのエージェントステータスを確認します - -1. 左メニューの **Tiers & Nodes** オプションをクリックします。 -2. **Grid View** をクリックします。 -3. 過去1時間の各ノードの **App Agent Status** が90%を超えていることを確認します。 - -![Verify Agents](images/01-prereq-tiersnodes.png) - -## 必要に応じてアプリケーションと負荷生成を再起動 - -前のステップで行った確認のいずれかが検証できなかった場合は、**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によって使用されていることが確認できます。 - -![Restart App 1](images/restart-app-and-load-01.png) - -以下のコマンドを使用して、アプリケーションの負荷生成を開始します。 - -``` bash -cd /opt/appdynamics/lab-artifacts/phantomjs -./start_load.sh -``` - -以下の画像のような出力が表示されます。 - -![Restart App 3](images/restart-app-and-load-03.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereq-bts.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereq-bts.png deleted file mode 100644 index 383cb29c68..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereq-bts.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereq-tiersnodes.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereq-tiersnodes.png deleted file mode 100644 index 11626f9886..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereq-tiersnodes.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereque-appload.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereque-appload.png deleted file mode 100644 index 409c41d897..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/01-prereque-appload.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png deleted file mode 100644 index c8704770fc..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-01.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png deleted file mode 100644 index 20d5aec2fe..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-02.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png deleted file mode 100644 index 69051b3f57..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/1-lab-prerequisites/images/restart-app-and-load-03.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md deleted file mode 100644 index 78b36bd1c8..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/_index.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Database Agent のダウンロード -time: 2 minutes -weight: 2 -description: この演習では、Web ブラウザから AppDynamics Controller にアクセスし、Database Visibility エージェントをダウンロードします。 ---- - -この演習では、WebブラウザからAppDynamics Controllerにアクセスし、Database Visibilityエージェントをダウンロードします。 - -## Controller へのログイン - -Ciscoの認証情報を使用して [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインします。 - -## Database Agent のダウンロード - -1. 画面左上のHomeタブを選択します。 -2. **Getting Started** タブを選択します。 -3. **Getting Started Wizard** をクリックします。 - -![Getting Started](images/04-download-gettingstarted.png) - -1. **Databases** をクリックします。 - -![Select Agent](images/04-download-db-agent.png) - -## Database Agent のダウンロード - -1. Select Database Typeドロップダウンメニューから **MySQL** を選択します。 -2. Controller接続のデフォルト設定を受け入れます。 -3. **Click Here to Download** をクリックします。 - -![Download](images/04-download-download.png) - -Database Visibility Agentファイルをローカルファイルシステムに保存します。 - -ブラウザから、以下の画像のようにエージェントファイルをローカルファイルシステムに保存するよう求められます（OSによって表示が異なる場合があります）。 - -![Save](images/04-download-local-agent.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-db-agent.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-db-agent.png deleted file mode 100644 index f0a8fb2495..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-db-agent.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-download.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-download.png deleted file mode 100644 index f38e98d509..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-download.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-gettingstarted.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-gettingstarted.png deleted file mode 100644 index 1a282d42fc..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-gettingstarted.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-local-agent.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-local-agent.png deleted file mode 100644 index 1e646389a5..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/2-download-database-agent/images/04-download-local-agent.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md deleted file mode 100644 index 8091118745..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/3-install-database-agent/_index.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -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エージェントを起動する - -## Application VM への Database Agent のアップロード - -この時点で、このワークショップで使用する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 エージェント名にイニシャルを追加してください**。これは次のセクションで使用します。例：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 -``` - -以下の画像のような出力が表示されます。 - -![Output](images/04-dbagent-install.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/3-install-database-agent/images/04-dbagent-install.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/3-install-database-agent/images/04-dbagent-install.png deleted file mode 100644 index 03afe073d5..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/3-install-database-agent/images/04-dbagent-install.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md deleted file mode 100644 index 755ee02f1e..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/_index.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Database Collector の構成 -time: 2 minutes -weight: 4 -description: この演習では、Controller にアクセスし、Database Collector を構成して、Database Collector がデータを収集していることを確認します。 ---- - -## Database Collector の構成 - -Database Agent Collectorは、Database Agent内で実行され、データベースインスタンスとデータベースサーバーのパフォーマンスメトリクスを収集するプロセスです。1つのコレクターは1つのデータベースインスタンスのメトリクスを収集します。1つのDatabase Agentで複数のコレクターを実行できます。Database AgentがControllerに接続されると、Controllerで1つ以上のコレクターを構成できます。 - -この演習では、以下のタスクを実行します - -- WebブラウザからAppDynamics Controllerにアクセスする -- ControllerでDatabase Collectorを構成する -- Database Collectorがデータを収集していることを確認する - -## Controller へのログイン - -Ciscoの認証情報を使用して [AppDynamics SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) にログインします。 - -## Controller での Database Collector の構成 - -以下の手順に従って、クエリリテラルの設定を変更し、コレクター構成に移動します。 - -1. 左メニューの **Databases** タブをクリックします。 -2. 左下の **Configuration** タブをクリックします。 -3. **Remove literals from the queries** のチェックボックスのチェックを外します。 -4. **Collectors** オプションをクリックします。 - -![Configuration](images/05-db-configure-collector.png) - -以下の手順に従って、新しいDatabase Collectorを構成します。 - -1. **Add** ボタンをクリックします。 -2. データベースタイプとして **MySQL** を選択します。 -3. Database Agentとして **DBMon-Lab-Agent** を選択し、以下のパラメータを入力します。 -4. Collector Name: **Supercar-MySQL-YOURINITIALS** -5. Hostname or IP Address: **localhost** -6. Listener Port: **3306** - -![Configuration1](images/05-db-collector-config1.png) - -1. Username: **root** -2. Password: **Welcome1!** - -![Configuration2](images/05-db-username.png) - -1. **Advanced Options** の下にある **Monitor Operating System** チェックボックスを選択します。 -2. オペレーティングシステムとして **Linux** を選択し、以下のパラメータを入力します。 -3. SSH Port: **22** -4. Username: **splunk** -5. Password: **EC2 インスタンスに SSH 接続するためにインストラクターから提供されたパスワード** -6. **OK** をクリックしてコレクターを保存します。 - -![Advance Options](images/05-db-advance-options.png) - -## Database Collector がデータを収集していることの確認 - -コレクターが実行されてデータを送信するまで10分間待ってから、以下の手順に従ってDatabase Collectorがデータベースに接続し、データベースメトリクスを収集していることを確認します。 - -1. 左メニューの **Databases** タブをクリックします。 -2. 前のセクションで作成したCollectorを検索します：**Supercar-MySQL-YOURINITIALS** -3. ステータスが緑色で、エラーが表示されていないことを確認します。 -4. Supercar-MySQLリンクをクリックしてデータベースの詳細を表示します。 - -_注意：コレクターを構成してから Top 10 SQL Wait States と Queries タブのクエリが表示されるまで、最大18分かかる場合があります。_ - -![Application](images/04-db-db-controller.png) - -![Application](images/04-db-db-dashboard.png) - -Database Collectorの構成の詳細については、[こちら](https://docs.appdynamics.com/appd/24.x/latest/en/database-visibility/add-database-collectors)を参照してください。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/04-db-db-controller.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/04-db-db-controller.png deleted file mode 100644 index 7c4aff06bc..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/04-db-db-controller.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/04-db-db-dashboard.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/04-db-db-dashboard.png deleted file mode 100644 index 4db0f5c4eb..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/04-db-db-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-advance-options.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-advance-options.png deleted file mode 100644 index 475ffd497c..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-advance-options.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-collector-config1.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-collector-config1.png deleted file mode 100644 index 4f1ab381be..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-collector-config1.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-configure-collector.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-configure-collector.png deleted file mode 100644 index 99c5243907..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-configure-collector.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-username.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-username.png deleted file mode 100644 index 534aa370b5..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/4-configure-database-collector/images/05-db-username.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md deleted file mode 100644 index f376cbe908..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/_index.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: 監視とトラブルシューティング - パート1 -time: 2 minutes -weight: 4 -description: この演習では、データベースとサーバーの全体的なダッシュボード、メインダッシュボード、およびデータベースアクティビティウィンドウのレポートを確認します。 ---- - -## 監視とトラブルシューティング - パート1 - -この演習では、以下のタスクを実行します - -- データベースとサーバーのパフォーマンス全体ダッシュボードの確認 -- メインデータベースダッシュボードの確認 -- データベースアクティビティウィンドウのレポートの確認 - -## データベースとサーバーのパフォーマンス全体ダッシュボードの確認 - -データベースとサーバーのパフォーマンス全体ダッシュボードでは、各データベースの健全性を一目で確認できます。 - -1. Filters：健全性、負荷、データベースの時間、またはタイプでフィルタリングするオプションを探索できます。 -2. Actions：このウィンドウのデータを .csv形式のファイルでエクスポートします。 -3. View Options：スパークチャートのオン/オフを切り替えます。 -4. View：カードビューとリストビューを切り替えます。 -5. Sort：ソートオプションを表示します。 -6. Supercar-MySQL：メインデータベースダッシュボードにドリルダウンします。 - -![Overall Database and Server Performance Dashboard](images/04-db-collector.png) - -## メインデータベースダッシュボードの確認 - -メインデータベースダッシュボードには、以下を含むデータベースの主要なインサイトが表示されます - -- データベースを実行しているサーバーの健全性 -- 指定された時間期間中の合計呼び出し回数 -- 任意の時点での呼び出し回数 -- 指定された時間期間中にSQL文の実行に費やされた合計時間 -- 上位10件のクエリ待機状態 -- 平均接続数 -- データベースタイプまたはベンダー -- ダッシュボードの機能を探索します - -1. ヘルスステータスの円をクリックして、サーバーの健全性の詳細を確認します - -- Green（緑）：サーバーは正常 -- Yellow（黄）：警告レベルの違反があるサーバー -- Red（赤）：重大レベルの違反があるサーバー - -1. データベースタイプまたはベンダーは常にここに表示されます。 -2. 指定された時間期間中にSQL文の実行に費やされた合計時間を確認します。 -3. 指定された時間期間中の合計実行回数を確認します。 -4. チャート上の時系列にマウスを合わせて、記録されたメトリクスの詳細を確認します。 - -データポイントの上部にあるオレンジ色の円をクリックすると、選択した時間の前後15分のクエリ実行時間と待機状態を表示する時間比較レポートが表示されます。 - -1. チャートに表示されるスパイクを強調表示するには、マウスの左ボタンを押したまま左から右にドラッグします。 -2. 構成ボタンをクリックして、上位10件から不要な待機状態を除外します。 -3. 各待機状態のラベルにマウスを合わせて、より詳細な説明を確認します。 -4. 選択した時間期間中にクエリを実行しているアクティブな接続の平均数を確認します。 - -![Main Database Dashboard](images/04-db-overview.png) - -選択した時間期間のDBサーバーのOSメトリクスを表示するには - -1. 右側のスクロールバーを使用してダッシュボードの下部にスクロールします -2. CPU -3. Memory -4. Disk IO -5. Network IO - -![OS Metrics](images/04-db-os-metrics.png) - -## データベースアクティビティウィンドウのレポートの確認 - -Database Visibilityのデータベースアクティビティウィンドウには、最大9種類のレポートがあります。利用可能なレポートは、監視対象のデータベースプラットフォームによって異なります。この演習では、最も一般的な3つのレポートを確認します。 - -- Wait State Report -- Top Activity Report -- Query Wait State Report - -## Wait State Report - -このレポートは、データベース内のWait Events（待機状態）の時系列データを表示します。各待機状態は色分けされており、Y軸は秒単位の時間を表示します。このレポートは、テーブル形式でもデータを表示し、各SQL文の各待機状態に費やされた時間を強調表示します。 - -最も時間を消費している待機状態は、パフォーマンスのボトルネックを示している可能性があります。たとえば、db file sequential readsは、インデックスのセグメントヘッダー競合またはディスク競合が原因である可能性があります。 - -![Wait State](images/04-db-waitstate.png) - -## Top Activity Report - -このレポートは、データベースSQL文の上位の時間を時系列ビューで表示します。このレポートは、テーブル形式でもデータを表示し、上位10件のSQL文それぞれがデータベースで費やした時間を強調表示します。 - -このレポートを使用して、どのSQL文が最もデータベース時間を使用しているかを確認します。これにより、特定のSQL文がシステム全体のパフォーマンスに与える影響を判断でき、データベースパフォーマンスに最も影響を与えている文にチューニングの努力を集中させることができます。 - -![Top Activity Report](images/04-db-top-activity.png) - -## Query Wait State Report - -このレポートは、上位（10、50、100、200）クエリの待機時間を表示します。このレポートは、テーブル形式でもデータを表示し、各クエリが異なる待機状態で費やしている時間を強調表示します。列を使用して、異なる待機状態でクエリをソートします。 - -データベースアクティビティウィンドウのレポートの詳細については、[こちら](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)を参照してください。 - -![Query Wait State Report](images/04-db-query-waitstate.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-collector.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-collector.png deleted file mode 100644 index 8c8d0c9242..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-collector.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-os-metrics.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-os-metrics.png deleted file mode 100644 index bfd7a4e52f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-os-metrics.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-overview.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-overview.png deleted file mode 100644 index aa95fca27f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-overview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-query-waitstate.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-query-waitstate.png deleted file mode 100644 index 520a5986f1..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-query-waitstate.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-top-activity.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-top-activity.png deleted file mode 100644 index 78e18e591e..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-top-activity.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-waitstate.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-waitstate.png deleted file mode 100644 index 64c452369b..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/5-monitor-and-troubleshoot-option-1/images/04-db-waitstate.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md deleted file mode 100644 index 3de1106a99..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/_index.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: 監視とトラブルシューティング - パート2 -weight: 5 -description: この演習では、クエリダッシュボードの確認、コストの高いクエリの詳細確認、およびコストの高いクエリのトラブルシューティングを行います。 ---- - -## クエリダッシュボードの確認 - -Queriesウィンドウには、データベースで最も時間を消費しているSQL文とストアドプロシージャが表示されます。クエリの重みをSQL待機時間などの他のメトリクスと比較して、チューニングが必要なSQLを特定できます。 - -1. **Queries** タブ：クエリウィンドウを表示します。 -2. **Top Queries** ドロップダウン：上位5、10、100、または200件のクエリを表示します。 -3. **Filter by Wait States**：クエリリストをフィルタリングする待機状態を選択できます。 -4. **Group Similar**：同じ構文を持つクエリをグループ化します。 -5. **Weight (%)** が最も大きいクエリをクリックします。 -6. **View Query Details**：クエリの詳細にドリルダウンします。 - -![Queries Dashboard](images/04-db-queries-overview.png) - -## コストの高いクエリの詳細確認 - -Database Queriesウィンドウでデータベースで最も時間を費やしている文を特定したら、それらのSQL文をチューニングするのに役立つ詳細をさらに掘り下げることができます。データベースインスタンスのQuery Detailsウィンドウには、Database Queriesウィンドウで選択したクエリの詳細が表示されます。 - -1. **Resource consumption over time**：クエリがリソースを使用してデータベースで費やした時間、実行回数、および消費したCPU時間を表示します。 -2. **Wait states**：選択したSQL文をデータベースが処理するのにかかる時間に寄与するアクティビティです。最も時間を消費している待機状態は、パフォーマンスのボトルネックを示している可能性があります。 -3. **Components Executing Similar Queries**：このクエリに類似したクエリを実行しているノードを表示します。 -4. **Business Transactions Executing Similar Queries**：このクエリに類似したクエリを実行しているJavaビジネストランザクションを表示します。 - -![Expensive Query Details](images/04-db-queries-details.png) - -1. 右側の外側のスクロールバーを使用して下にスクロールします。 -2. **Clients**：選択したSQL文を実行したマシンと、各マシンが文の実行に要した合計時間の割合を表示します。 -3. **Sessions**：各データベースインスタンスの使用状況のセッションです。 -4. **Query Active in Database**：このSQLによってアクセスされたスキーマを表示します。 -5. **Users**：このクエリを実行したユーザーを表示します。 -6. **Query Hashcode**：データベースサーバーがキャッシュ内でこのSQL文をより迅速に見つけるための一意のIDを表示します。 -7. **Query**：選択したSQL文の完全な構文を表示します。Queryカードの右上隅にある鉛筆アイコンをクリックして、識別しやすいようにクエリ名を編集できます。 -8. **Execution Plan**：クエリ実行プランウィンドウを表示します。 - -![Expensive Query Details2](images/04-db-queries-details2.png) - -## コストの高いクエリのトラブルシューティング - -Database Query Execution Planウィンドウは、クエリに最も効率的な実行プランを決定するのに役立ちます。問題のある可能性のあるクエリを発見したら、EXPLAIN PLAN文を実行して、データベースが作成した実行プランを確認できます。 - -クエリの実行プランは、クエリがインデックスの使用を最適化し、効率的に実行されているかどうかを示します。この情報は、実行が遅いクエリのトラブルシューティングに役立ちます。 - -1. **Execution Plan** タブをクリックします。 -2. **Type** 列の結合タイプが各テーブルでALLであることに注目してください。 -3. 結合タイプの1つにマウスを合わせて、結合タイプの説明を確認します。 -4. **Extras** 列のエントリを調べます。 -5. 各エントリにマウスを合わせて、エントリの説明を確認します。 - -![Troubleshoot Expensive Query](images/04-db-execution-plan.png) - -次に、Object Browserを使用してテーブルのインデックスを調査しましょう。 - -1. **Object Browser** オプションをクリックして、テーブルのスキーマの詳細を表示します。 -2. **Database** オプションをクリックします。 -3. **supercars** スキーマをクリックして、テーブルのリストを展開します。 -4. **CARS** テーブルをクリックして、テーブルの詳細を表示します。 -5. CAR_ID列が主キーとして定義されていることがわかります。 - -![Troubleshoot Expensive Query](images/04-db-object-browser.png) - -1. 外側のスクロールバーを使用してページを下にスクロールします。 -2. テーブルに定義された主キーインデックスに注目してください。 - -![Troubleshoot Car Index](images/04-db-cars-index.png) - -1. **MANUFACTURER** テーブルをクリックして、その詳細を表示します。 -2. **MANUFACTURER_ID** 列が主キーとして定義されていないことに注目してください。 -3. ページを下にスクロールして、テーブルにインデックスが定義されていないことを確認します。 - -![Troubleshoot Expensive Query](images/04-db-man-table.png) - -MANUFACTURER_ID列には、テーブルに対するクエリのパフォーマンスを向上させるためにインデックスを作成する必要があります。異なるクエリを分析した場合、根本的な問題は異なる可能性がありますが、このラボで示される最も一般的な問題は、クエリがMANUFACTURERテーブルとの結合を実行しているか、そのテーブルを直接クエリしていることが原因です。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-cars-index.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-cars-index.png deleted file mode 100644 index ffb473d16b..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-cars-index.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-execution-plan.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-execution-plan.png deleted file mode 100644 index b44ee0bf7f..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-execution-plan.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-man-table.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-man-table.png deleted file mode 100644 index ed50252219..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-man-table.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-object-browser.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-object-browser.png deleted file mode 100644 index df057ed797..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-object-browser.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-details.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-details.png deleted file mode 100644 index 59d5d82354..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-details.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-details2.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-details2.png deleted file mode 100644 index 200eb6c55e..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-details2.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-overview.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-overview.png deleted file mode 100644 index f8f09bfe51..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/6-monitor-and-troubleshoot-option-2/images/04-db-queries-overview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/_index.md b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/_index.md deleted file mode 100644 index f34783a7bd..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/_index.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -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/) を使用します。 - -![Controller](images/controller-vm.png) - -## Application VM - -Supercar TraderはJavaベースのWebアプリケーションです。 - -Supercar-Traderコレクションの目的は、AppDynamics Controller向けに動的なトラフィック（ビジネストランザクション）を生成することです。 - -![Application](images/application-vm.png) diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/images/application-vm.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/images/application-vm.png deleted file mode 100644 index 3152db2402..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/images/application-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/images/controller-vm.png b/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/images/controller-vm.png deleted file mode 100644 index 319513a3de..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/5-database-monitoring/images/controller-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md deleted file mode 100644 index 2bf3cca13f..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/1-prerequisites.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: 1. 前提条件 -weight: 1 ---- - -リモートホストにSmart Agentをインストールする前に、以下の前提条件が満たされていることを確認してください - -## 必要なアクセス - -- **SSH アクセス**：Smart Agentをインストールする予定のすべてのリモートホストへのSSHアクセスが必要です -- **SSH 秘密鍵**：認証用に構成されたSSH秘密鍵 -- **Sudo 権限**：Control Nodeユーザーはsmartagentctlを実行するためにsudo権限が必要です -- **リモート SSH**：リモートホストでSSHが有効になっており、アクセス可能である必要があります - -## ディレクトリ構造 - -Smart Agentのインストールディレクトリは、Control Nodeに設定されている必要があります - -```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/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md deleted file mode 100644 index d5d591c558..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/2-configuration.md +++ /dev/null @@ -1,310 +0,0 @@ ---- -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` にする必要があります） - -### Common Configuration - -エージェントのIDとポーリング動作を定義します - -```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`：プロキシをバイパスするホストのカンマ区切りリスト - -### Auto Discovery - -自動アプリケーション検出を構成します - -```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`：検出されたアプリケーションを自動的にインストール - -### Task Configuration - -ネイティブ計装を構成します - -```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` -- 絶対パスである必要があります -- ユーザーは書き込み権限を持っている必要があります - -### Protocol 構成 - -**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、またはホスト名が使用可能 -- Control Nodeから到達可能である必要があります - -**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="Tip" 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/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md deleted file mode 100644 index 8687015da1..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/3-installation.md +++ /dev/null @@ -1,229 +0,0 @@ ---- -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接続ステータス -- ファイル転送の進捗 -- 各ホストでのインストール手順 -- エージェントの起動ステータス -- エラーや警告 - -### 期待される出力 - -以下のような出力が表示されます - -```text -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. **Metric の確認**: 各ホストからMetricが収集されていることを確認します - -### 期待されるタイムライン - -- **エージェントの登録**: エージェントは通常、起動後1～2分以内にControllerに表示されます -- **初期 Metric**: 最初のMetricは通常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. Metricが収集されていることを確認します -3. 必要に応じてアプリケーションモニタリングを設定します -4. アラートとDashboardを設定します -5. エージェントの正常性とパフォーマンスを監視します - -問題が発生した場合は、トラブルシューティングセクションに進みます。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md deleted file mode 100644 index 2619bc9478..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/4-troubleshooting.md +++ /dev/null @@ -1,465 +0,0 @@ ---- -title: 4. トラブルシューティング -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="警告" style="danger" icon="exclamation-triangle" %}} -ホストキー検証の無効化はテスト目的でのみ使用してください。本番環境では必ず有効にしてください。 -{{% /notice %}} - -## 権限の問題 - -### 問題: インストール中に権限が拒否される - -**症状:** - -- ディレクトリ作成時の "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/ -``` - -## エージェントが起動しない - -### 問題: エージェントのインストールは成功するが起動しない - -**症状:** - -- インストールはエラーなく完了 -- リモートホストでエージェントプロセスが実行されていない -- コントロールノードのログにエラーなし - -**解決方法:** - -#### 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 -``` - -以下を確認します: - -- コントローラーURLが正しいこと -- アカウント認証情報が有効であること -- 必須フィールドがすべて入力されていること - -#### 4. コントローラーへの接続テスト - -リモートホストから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. コントローラー認証情報の検証 - -AppDynamicsの認証情報が正しいことを確認します: - -- **ControllerURL**: `https://` や `/controller` を含めないこと -- **AccountAccessKey**: 完全なアクセスキーであること -- **AccountName**: アカウント名と正確に一致すること - -正しい形式の例: - -```ini -ControllerURL = fso-tme.saas.appdynamics.com -AccountAccessKey = abc123xyz789 -AccountName = fso-tme -``` - -## エージェントが Controller に表示されない - -### 問題: エージェントが起動するが Controller UI に表示されない - -**症状:** - -- リモートホストでエージェントプロセスが実行中 -- エージェントログにエラーなし -- Controller UIにエージェントが表示されない - -**解決方法:** - -#### 1. 初期登録を待つ - -エージェントが起動してからControllerに表示されるまで1～5分かかる場合があります。 - -#### 2. コントローラー設定の確認 - -エージェントがコントローラーに到達できることを確認します: - -```bash -ssh ubuntu@172.31.1.243 -ping fso-tme.saas.appdynamics.com -curl -I https://fso-tme.saas.appdynamics.com -``` - -#### 3. エージェントログで接続エラーを確認 - -コントローラー接続エラーを確認します: - -```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 -``` - -以下を確認します: - -- コントローラー接続エラー -- 設定エラー -- エージェント起動の失敗 -- ネットワークの問題 - -### ログの詳細度を上げる - -より詳細なログが必要な場合、`config.ini` で `LogLevel` を `DEBUG` に設定します: - -```ini -[Telemetry] -LogLevel = DEBUG -``` - -## ヘルプの取得 - -問題が解決しない場合: - -1. **ドキュメントの確認**: smartagentctlのヘルプを確認します: - - ```bash - ./smartagentctl --help - ./smartagentctl start --help - ``` - -2. **AppDynamics ドキュメントの確認**: AppDynamicsドキュメントポータルを参照します - -3. **ログファイルの確認**: コントロールノードとリモートホストの両方のログを必ず確認します - -4. **コンポーネントを個別にテスト**: - - SSH接続性を個別にテストします - - 単一のホストでエージェントの起動を手動でテストします - - コントローラーへの接続性を個別に確認します - -5. **診断情報の収集**: - - コントロールノードのログ - - リモートホストのログ - - 設定ファイル（機密データは削除） - - エラーメッセージとスタックトレース - -## 一般的なエラーメッセージ - -| エラーメッセージ | 原因 | 解決方法 | -| --- | --- | --- | -| "Permission denied (publickey)" | SSHキー認証の失敗 | SSHキーのパスと権限を確認 | -| "Connection refused" | SSHポートにアクセスできない | ファイアウォールルールとSSHデーモンを確認 | -| "No such file or directory" | 設定ファイルが見つからない | 設定ファイルの存在とパスが正しいことを確認 | -| "YAML parse error" | 無効なYAML構文 | YAMLパーサーで構文を検証 | -| "Controller unreachable" | ネットワーク接続の問題 | リモートホストからコントローラーへの接続性をテスト | -| "Invalid credentials" | アカウントキーまたは名前が不正 | AppDynamics の認証情報を確認 | - -## トラブルシューティングのベストプラクティス - -1. **常に --verbose フラグを使用**: デバッグのための詳細な出力を提供します -2. **最初に単一のホストでテスト**: スケールアウトする前に1台のホストにデプロイします -3. **すぐにログを確認**: デプロイ直後にログを確認します -4. **前提条件の確認**: デプロイ前にすべての要件が満たされていることを確認します -5. **接続性を個別にテスト**: SSHとネットワーク接続性を個別に確認します -6. **手動コマンドを使用**: 手動でのSSHとエージェント起動をテストして問題を切り分けます - -{{% notice title="ヒント" style="info" icon="lightbulb" %}} -トラブルシューティングでは、より複雑な問題に移る前に、最も簡単なテスト（例: ping、SSH接続性）から始めてください。 -{{% /notice %}} diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/_index.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/_index.md deleted file mode 100644 index 0767ad6422..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/1-remote-installation/_index.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: リモートインストール -weight: 1 -time: 2 minutes -description: smartagentctl を使用して、複数のリモートホストに AppDynamics Smart Agent をインストールおよび管理する方法を学びます。 ---- - -## はじめに - -このワークショップでは、**smartagentctl** コマンドラインツールを使用して、複数のリモートホストに同時に **AppDynamics Smart Agent** をインストールおよび管理する方法を紹介します。このアプローチは、JenkinsやGitHub Actionsなどの追加の自動化ツールを必要とせずに、SSHベースのリモート実行を使用してサーバーフリートにSmart Agentを迅速にデプロイするのに最適です。 - -![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) - -## 学習内容 - -このワークショップでは、以下の方法を学びます - -- `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がインストールされたControl Node -- すべてのリモートホストへのSSHアクセス -- 認証用に構成されたSSH秘密鍵 -- Control Nodeでの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` フラグをサポートしています。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです - -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）と右（▶️）のカーソルキー -{{% /notice %}} diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md deleted file mode 100644 index 9b6bc7c9ea..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/1-architecture.md +++ /dev/null @@ -1,306 +0,0 @@ ---- -title: アーキテクチャと設計 -weight: 1 -time: 5 minutes ---- - -## システムアーキテクチャ - -JenkinsベースのSmart Agentデプロイシステムは、ハブ・アンド・スポーク型のアーキテクチャを採用しています。AWS VPC内のJenkinsエージェントが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エージェントはプライベートIP経由でターゲットホストと通信するため、ターゲットホストにパブリックIPアドレスは不要です。 - -### VPC レイアウト - -```text -┌─────────────────────────────────────────────────────────────────┐ -│ 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 -- エージェントへのネットワークアクセス - -### Jenkins Agent - -**配置場所:** - -- AWS VPC（ターゲットと同一） -- プライベートネットワークアクセス - -**役割:** - -- パイプラインステージの実行 -- ターゲットホストへのSSH接続 -- ファイル転送（SCP） -- バッチ処理ロジック -- エラー収集 - -**要件:** - -- ラベル: `linux` -- Java 11以降 -- SSHクライアント -- ネットワーク: すべてのターゲットへのSSH接続 -- ディスク: アーティファクト用に約20GB - -### ターゲットホスト - -**前提条件:** - -- Ubuntu 20.04以降 -- SSHサーバーが稼働していること -- sudoアクセス権を持つユーザー -- SSH鍵が認証済みであること - -**デプロイ後:** - -```text -/opt/appdynamics/ -└── appdsmartagent/ - ├── smartagentctl - ├── config.ini - └── agents/ - ├── machine/ - ├── java/ - ├── node/ - └── db/ -``` - -## セキュリティアーキテクチャ - -### セキュリティレイヤー - -1. **AWS VPC 分離** - - エージェント用のプライベートサブネット - - 直接のインターネットアクセスは不要 - - VPCフローログの有効化 - -2. **セキュリティグループ** - - Jenkins AgentのIPをホワイトリスト登録 - - ポート22（SSH）のみ - - ステートフルファイアウォールルール - -3. **SSH 鍵認証** - - パスワード認証なし - - Jenkins認証情報に鍵を保存 - - 一時鍵ファイル（600パーミッション） - - 各ビルド後に鍵を削除 - -4. **Jenkins RBAC** - - ロールベースのアクセス制御 - - パイプラインレベルの権限 - - 認証情報のアクセス制限 - - 監査ログの有効化 - -5. **シークレット管理** - - コードやログにシークレットを含めない - - 認証情報のバインディングのみ - - 環境変数のマスキング - - 自動シークレットローテーション（オプション） - -### 認証情報のフロー - -```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台ずつのバッチで処理され、バッチ内のすべてのホストは並列でデプロイされます。 - -### バッチ処理の仕組み - -```text -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分 - -**速度に影響する要因:** - -- ネットワーク帯域幅（ホストあたり19MBのパッケージ） -- SSH接続のオーバーヘッド（ホストあたり約1秒） -- ターゲットホストのCPU/ディスク速度 -- Jenkinsエージェントのリソース - -## 次のステップ - -アーキテクチャを理解したところで、Jenkinsのセットアップと認証情報の設定に進みます。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md deleted file mode 100644 index 726e81dce4..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/2-jenkins-setup.md +++ /dev/null @@ -1,294 +0,0 @@ ---- -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 Agent の設定 - -JenkinsエージェントはプライベートIP経由でターゲットEC2インスタンスに到達できる必要があります。主に2つの方法があります: - -### オプション A: EC2 インスタンスをエージェントとして使用 - -1. ターゲットホストと **同じ VPC に EC2 インスタンスを起動** します - -2. **Java をインストール** します（Jenkinsに必要）: - - ```bash - sudo apt-get update - sudo apt-get install -y openjdk-11-jdk - ``` - -3. **Jenkins にエージェントを追加** します: - - **Manage Jenkins → Nodes → New Node** に移動します - - 名前: `aws-vpc-agent`（または任意の名前） - - タイプ: **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**: パスを指定 - -**フォーマット例**: - -```text ------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アドレスを入力 - -**例**: - -```text -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改行コード（LF、CRLFではない）を使用 -{{% /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 -# AppDynamics からダウンロード -curl -o appdsmartagent_64_linux.zip \ - "https://download.appdynamics.com/download/prox/download-file/smart-agent/latest/appdsmartagent_64_linux.zip" - -# ダウンロードを確認 -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 -# Jenkins エージェントマシンからテスト -ssh -i /path/to/key ubuntu@172.31.1.243 -o ConnectTimeout=10 - -# セキュリティグループがエージェントからの SSH を許可していることを確認 -# 秘密鍵がターゲットの公開鍵と一致していることを確認 -``` - -### 認証情報が見つからない - -**症状**:「Credential not found」エラーが発生する - -**解決策**: - -- 認証情報のIDが正確に一致していることを確認します: - - `ssh-private-key` - - `deployment-hosts` - - `account-access-key` -- 認証情報のスコープが **Global** に設定されていることを確認します - -### ターゲットホストでの権限拒否 - -**症状**: SSHは成功するがコマンドが権限拒否で失敗する - -**解決策**: - -```bash -# ターゲットホストで、ユーザーが sudoers に含まれていることを確認 -sudo visudo -# 以下の行を追加: -ubuntu ALL=(ALL) NOPASSWD: ALL -``` - -## 次のステップ - -Jenkinsの認証情報とエージェントの設定が完了したら、デプロイパイプラインの作成に進みます。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md deleted file mode 100644 index 5bef8100ac..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/3-pipeline-creation.md +++ /dev/null @@ -1,268 +0,0 @@ ---- -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パイプライン定義が含まれています: - -```text -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アカウントまたは組織にフォークするか、元のリポジトリを直接使用します。 - -**リポジトリ 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 セクション:** - -- **Description**: `Deploys AppDynamics Smart Agent to multiple hosts` -- **Discard old builds** はチェックしないままにします（または必要に応じて設定） - -**Build Triggers:** - -- 手動実行のみの場合はチェックしないままにします -- 必要に応じてWebhookやポーリングを設定します - -**Pipeline セクション:** - -- **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を繰り返します: - -| パイプライン名 | スクリプトパス | -| --- | --- | -| 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. **New Item を作成** します（方法1と同様） -2. **Pipeline** セクションで: - - **Definition**: `Pipeline script` を選択します - - **Script**: GitHubからJenkinsfileの内容全体をコピー/ペーストします -3. **Save** をクリックします - -{{% notice style="tip" %}} -方法1（SCM）を推奨します。パイプラインをバージョン管理に保持でき、更新が容易になります。 -{{% /notice %}} - -## パイプラインパラメータ - -各パイプラインは設定可能なパラメータを受け付けます。メインデプロイパイプラインの主要なパラメータを以下に示します: - -### Deploy Smart Agent パイプラインのパラメータ - -| パラメータ | デフォルト値 | 説明 | -| --- | --- | --- | -| `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 パイプラインのパラメータ - -| パラメータ | デフォルト値 | 説明 | -| --- | --- | --- | -| `REMOTE_INSTALL_DIR` | `/opt/appdynamics/appdsmartagent` | 削除するディレクトリ | -| `SSH_PORT` | `22` | リモートホストの SSH ポート | -| `CONFIRM_CLEANUP` | `false` | クリーンアップを実行するにはチェックが必要 | - -{{% notice style="warning" %}} -Cleanupパイプラインには、誤って削除することを防ぐための確認パラメータがあります。クリーンアップを実行するには `CONFIRM_CLEANUP` にチェックを入れる必要があります。 -{{% /notice %}} - -## パイプライン構造の理解 - -デプロイパイプラインの主要なコンポーネントを見ていきます: - -### 1. エージェント宣言 - -```groovy -agent { label 'linux' } -``` - -これにより、パイプラインが `linux` ラベルを持つJenkinsエージェントで実行されることが保証されます。 - -### 2. パラメータブロック - -```groovy -parameters { - string(name: 'SMARTAGENT_ZIP_PATH', ...) - string(name: 'REMOTE_INSTALL_DIR', ...) - // ... その他のパラメータ -} -``` - -ビルドをトリガーする際に設定できるパラメータを定義します。 - -### 3. ステージ - -デプロイパイプラインには以下のステージがあります: - -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. 認証情報バインディング - -```groovy -withCredentials([ - sshUserPrivateKey(credentialsId: 'ssh-private-key', ...), - string(credentialsId: 'account-access-key', ...) -]) { - // 認証情報にアクセスできるパイプラインコード -} -``` - -ログに公開することなく、安全に認証情報を読み込みます。 - -### 5. Post アクション - -```groovy -post { - success { ... } - failure { ... } - always { ... } -} -``` - -パイプライン完了後に、成功・失敗に関わらず実行するアクションを定義します。 - -## パイプラインの命名規則 - -明確さと整理のために、一貫した命名規則を使用します: - -**推奨名称:** - -```text -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. **フォルダー内にパイプラインを作成**: - - フォルダーに入ります - - 上記の手順でパイプラインを作成します - -**構成例:** - -```text -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. IPが1つだけのテスト認証情報 `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/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md deleted file mode 100644 index 887e06c85e..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/4-deployment-workflow.md +++ /dev/null @@ -1,366 +0,0 @@ ---- -title: デプロイワークフロー -weight: 4 -time: 15 minutes ---- - -## 初回デプロイ - -パイプラインの設定が完了したので、最初のSmart Agentデプロイを実行してみましょう。 - -### ステップ1: パイプラインに移動 - -1. **Jenkins Dashboard** に移動します -2. **Deploy-Smart-Agent** パイプラインをクリックします - -### ステップ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 %}} - -### ステップ3: パイプラインの実行を監視 - -**Build** をクリックすると、以下が表示されます: - -1. **Build added to queue** - Build Historyにビルド番号が表示されます -2. **ビルド番号をクリック** します（例: #1） -3. **Console Output** をクリックしてリアルタイムのログを表示します - -### ステップ4: コンソール出力の理解 - -コンソール出力にはデプロイの各ステージが表示されます: - -```text -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の状態確認 - -### ステップ5: 結果の確認 - -完了後、以下のいずれかが表示されます: - -**成功:** - -```text -Smart Agent successfully deployed to all hosts -Finished: SUCCESS -``` - -**部分的な成功:** - -```text -Deployment completed with some failures -Failed hosts: 172.31.1.48 -Finished: UNSTABLE -``` - -**失敗:** - -```text -Smart Agent deployment failed. Check logs for details. -Finished: FAILURE -``` - -## インストールの検証 - -デプロイが成功したら、ターゲットホストでSmart Agentが稼働していることを確認します。 - -### Smart Agent の状態確認 - -ターゲットホストにSSH接続して状態を確認します: - -```bash -# ターゲットホストに SSH 接続 -ssh ubuntu@172.31.1.243 - -# インストールディレクトリに移動 -cd /opt/appdynamics/appdsmartagent - -# Smart Agent の状態を確認 -sudo ./smartagentctl status -``` - -**期待される出力:** - -```text -Smart Agent is running (PID: 12345) -Service: appdsmartagent.service -Status: active (running) -``` - -### インストール済みエージェントの一覧表示 - -```bash -cd /opt/appdynamics/appdsmartagent -sudo ./smartagentctl list -``` - -**期待される出力:** - -```text -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 Controllerへの接続成功メッセージを確認します。 - -### AppDynamics Controller での確認 - -1. AppDynamics Controllerにログインします -2. **Servers → Servers** に移動します -3. 新しくデプロイされたホストを探します -4. Smart AgentがMetricをレポートしていることを確認します - -## 追加エージェントのインストール - -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 -``` - -**期待される出力:** - -```text -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 -# Jenkins エージェントからターゲットに到達できることを確認 -ping 172.31.1.243 -telnet 172.31.1.243 22 -``` - -**SSH の手動テスト:** - -```bash -# Jenkins エージェントマシンから -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. まず単一ホストでテスト - -本番環境にデプロイする前に、必ず単一ホストで新しい設定をテストします: - -```text -1. deployment-hosts-test 認証情報を作成（IP 1つ） -2. この認証情報を使用するテストパイプラインを作成 -3. 成功を確認 -4. 完全なホストリストにデプロイ -``` - -### 2. 説明的なビルド説明を使用 - -ビルドをトリガーした後、説明を追加します: - -1. ビルドページに移動します -2. **Edit Build Information** をクリックします -3. 説明を追加します:「本番環境デプロイ - 2024年第4四半期」 - -### 3. ビルド履歴の監視 - -ビルド履歴を定期的にチェックしてパターンを確認します: - -- 失敗したビルド -- 所要時間の傾向 -- エラーメッセージ - -### 4. メンテナンスウィンドウ中にデプロイをスケジュール - -本番システムの場合: - -- Jenkinsのスケジュールビルドを使用します -- トラフィックの少ない時間帯にデプロイします -- ロールバック計画を準備しておきます - -### 5. 認証情報を最新に保つ - -- SSH鍵を四半期ごとにローテーションします -- インフラストラクチャの変更に合わせてホストリストを更新します -- AppDynamicsアクセスキーの有効性を確認します - -## 次のステップ - -大規模デプロイのスケーリングと運用上の考慮事項について見ていきましょう。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md deleted file mode 100644 index fb64feaa51..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/2-jenkins-automation/_index.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Jenkins 自動化 -weight: 2 -time: 2 minutes -description: Jenkins パイプラインを使用して、複数のホストにわたる AppDynamics Smart Agent のデプロイとライフサイクル管理を自動化する方法を学びます。 ---- - -## はじめに - -このワークショップでは、**Jenkins** を使用して複数のEC2インスタンスにわたる **AppDynamics Smart Agent** のデプロイとライフサイクル管理を自動化する方法を紹介します。10台のホストでも10,000台のホストでも、Jenkinsパイプラインを活用したスケーラブルで安全かつ再現性のあるSmart Agent運用方法を説明します。 - -![Jenkins and AppDynamics](https://img.shields.io/badge/Jenkins-D24939?style=flat&logo=jenkins&logoColor=white) ![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) - -## 学習内容 - -このワークショップでは、以下の内容を学びます: - -- 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. **デプロイワークフロー** - デプロイの実行とインストールの検証 - -## 前提条件 - -- Jenkinsサーバー（2.300以降）とPipelineプラグイン -- ターゲットEC2インスタンスと同じVPC内のJenkinsエージェント -- 認証用のSSHキーペア -- AppDynamics Smart Agentパッケージ -- SSHアクセス可能なターゲットUbuntu EC2インスタンス - -## GitHub リポジトリ - -すべてのパイプラインコードと設定ファイルはGitHubリポジトリで公開されています: - -**[https://github.com/chambear2809/sm-jenkins](https://github.com/chambear2809/sm-jenkins)** - -リポジトリには以下が含まれます: - -- 完全なJenkinsfileパイプライン定義 -- 詳細なセットアップドキュメント -- 設定例 -- トラブルシューティングガイド - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートするには、以下を使用します: - -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）および右（▶️）カーソルキー -{{% /notice %}} diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md deleted file mode 100644 index 0be61f41c6..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/1-architecture.md +++ /dev/null @@ -1,312 +0,0 @@ ---- -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 レイアウト - -```text -┌─────────────────────────────────────────────────────────────────┐ -│ 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） - -**Secrets:** - -- SSH秘密鍵 - -**Variables:** - -- ホストリスト（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キー - -**デプロイ後:** - -```text -/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 セキュリティ** - - リポジトリアクセス制御 - - ブランチ保護ルール - - Secretsはログに公開されない - - 環境変数のマスキング - -5. **ネットワークセキュリティ** - - プライベートIP通信のみ - - パブリックIPは不要 - - ランナーはターゲットと同じVPC内 - -## ワークフローカテゴリ - -システムには4つのカテゴリに分類された11のワークフローが含まれています: - -```text -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) -``` - -## バッチ処理戦略 - -すべてのワークフローは、あらゆるスケールのデプロイをサポートするために自動バッチ処理を使用します。 - -### バッチ処理の仕組み - -```text -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/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md deleted file mode 100644 index a121aa12bc..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/2-github-setup.md +++ /dev/null @@ -1,286 +0,0 @@ ---- -title: GitHub のセットアップ -weight: 2 -time: 10 minutes ---- - -## 前提条件 - -開始する前に、以下を確認します: - -- リポジトリアクセス権を持つGitHubアカウント -- Ubuntu EC2インスタンスを持つAWS VPC -- ターゲットホストへの認証用SSHキーペア（PEMファイル） -- AppDynamics Smart Agentパッケージ -- SSHアクセス可能なターゲットUbuntu EC2インスタンス - -## リポジトリのフォークまたはクローン - -まず、GitHub Actionsラボリポジトリへのアクセスを取得します。 - -**リポジトリ 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. フォークしたリポジトリの **ランナー設定に移動** します: - - ```text - 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"**（緑色）と表示されていることを確認します: - -```text -Settings → Actions → Runners -``` - -{{% notice style="tip" %}} -ランナーはワークフロージョブを受け取るためにオンラインかつアイドル状態を維持する必要があります。オフラインと表示される場合は、サービスステータスを確認します: `sudo ./svc.sh status` -{{% /notice %}} - -## GitHub Secrets の設定 - -**Settings → Secrets and variables → Actions → Secrets** に移動します。 - -### SSH 秘密鍵の Secret - -この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 -``` - -フォーマット例: - -```text ------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** に移動します。 - -### デプロイホスト Variable（必須） - -このVariableには、Smart Agentをデプロイするすべてのターゲットホストのリストが含まれます。 - -1. **"New repository variable"** をクリックします -2. **Name**: `DEPLOYMENT_HOSTS` -3. **Value**: ターゲットホストのIPを入力します（1行に1つ） - -```text -172.31.1.243 -172.31.1.48 -172.31.1.5 -172.31.10.20 -172.31.10.21 -``` - -**フォーマット要件:** - -- 1行に1つのIP -- カンマなし -- スペースなし -- 余分な文字なし -- Unix改行コード（LF、CRLFではなく）を使用 - -1. **"Add variable"** をクリックします - -### オプションの Variables - -これらの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"** をクリックします - -## ネットワーク設定 - -同じVPCおよびセキュリティグループ内のすべてのEC2インスタンスを使用するラボセットアップの場合: - -### セキュリティグループルール - -**インバウンドルール:** - -- 同じセキュリティグループからの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` Variableを編集します -- 末尾にスペースがないことを確認します -- Unix改行コード（LF、CRLFではなく）を使用します -- 1行に1つのIP、余分な文字なし - -### Secrets が見つからない - -**症状**: エラー「Secret SSH_PRIVATE_KEY not found」 - -**解決策**: - -- Secret名が正確に一致していることを確認します: `SSH_PRIVATE_KEY` -- SecretがリポジトリSecrets（環境Secretsではなく）にあることを確認します -- リポジトリの管理者アクセス権があることを確認します - -## セキュリティのベストプラクティス - -安全な運用のために、以下のベストプラクティスに従います: - -- すべての秘密鍵にGitHub Secretsを使用 -- SSHキーを定期的にローテーション -- ランナーをプライベートVPCサブネットに配置 -- ランナーのセキュリティグループを最小限のアクセスに制限 -- ランナーソフトウェアを定期的にアップデート -- ブランチ保護ルールを有効化 -- 環境ごとに別のキーを使用 -- リポジトリアクセスの監査ログを有効化 - -## 次のステップ - -GitHubの設定とランナーのセットアップが完了したら、利用可能なワークフローを確認し、最初のデプロイを実行しましょう。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md deleted file mode 100644 index d3c7321f26..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/3-workflows.md +++ /dev/null @@ -1,229 +0,0 @@ ---- -title: ワークフローの理解 -weight: 3 -time: 10 minutes ---- - -## 利用可能なワークフロー - -GitHub Actionsラボには、Smart Agentの完全なライフサイクル管理のための **11のワークフロー** が含まれています。すべてのワークフローファイルはリポジトリの `.github/workflows/` で利用できます。 - -**リポジトリ**: [https://github.com/chambear2809/github-actions-lab](https://github.com/chambear2809/github-actions-lab) - -## ワークフローカテゴリ - -### 1. デプロイ（1ワークフロー） - -#### Deploy Smart Agent（バッチ処理） - -- **ファイル**: `deploy-agent-batched.yml` -- **目的**: Smart Agentのインストールとサービスの起動 -- **機能**: - - 自動バッチ処理（デフォルト: バッチあたり256ホスト） - - 設定可能なバッチサイズ - - 各バッチ内での並列デプロイ - - シーケンシャルバッチ処理 -- **入力**: - - `batch_size`: バッチあたりのホスト数（デフォルト: 256） -- **トリガー**: 手動のみ（`workflow_dispatch`） - -### 2. エージェントのインストール（4ワークフロー） - -すべてのインストールワークフローは、特定のエージェントタイプをインストールするために `smartagentctl` を使用します: - -#### Install Node Agent（バッチ処理） - -- **ファイル**: `install-node-batched.yml` -- **コマンド**: `smartagentctl install node` -- **バッチ処理**: あり（設定可能） - -#### Install Machine Agent（バッチ処理） - -- **ファイル**: `install-machine-batched.yml` -- **コマンド**: `smartagentctl install machine` -- **バッチ処理**: あり（設定可能） - -#### Install DB Agent（バッチ処理） - -- **ファイル**: `install-db-batched.yml` -- **コマンド**: `smartagentctl install db` -- **バッチ処理**: あり（設定可能） - -#### Install Java Agent（バッチ処理） - -- **ファイル**: `install-java-batched.yml` -- **コマンド**: `smartagentctl install java` -- **バッチ処理**: あり（設定可能） - -### 3. エージェントのアンインストール（4ワークフロー） - -すべてのアンインストールワークフローは、特定のエージェントタイプを削除するために `smartagentctl` を使用します: - -#### Uninstall Node Agent（バッチ処理） - -- **ファイル**: `uninstall-node-batched.yml` -- **コマンド**: `smartagentctl uninstall node` -- **バッチ処理**: あり（設定可能） - -#### Uninstall Machine Agent（バッチ処理） - -- **ファイル**: `uninstall-machine-batched.yml` -- **コマンド**: `smartagentctl uninstall machine` -- **バッチ処理**: あり（設定可能） - -#### Uninstall DB Agent（バッチ処理） - -- **ファイル**: `uninstall-db-batched.yml` -- **コマンド**: `smartagentctl uninstall db` -- **バッチ処理**: あり（設定可能） - -#### Uninstall Java Agent（バッチ処理） - -- **ファイル**: `uninstall-java-batched.yml` -- **コマンド**: `smartagentctl uninstall java` -- **バッチ処理**: あり（設定可能） - -### 4. Smart Agent 管理（2ワークフロー） - -#### Stop and Clean Smart Agent（バッチ処理） - -- **ファイル**: `stop-clean-smartagent-batched.yml` -- **コマンド**: - - `smartagentctl stop` - - `smartagentctl clean` -- **目的**: Smart Agentサービスの停止とすべてのデータのパージ -- **バッチ処理**: あり（設定可能） - -#### Cleanup All Agents（バッチ処理） - -- **ファイル**: `cleanup-appdynamics.yml` -- **コマンド**: `sudo rm -rf /opt/appdynamics` -- **目的**: /opt/appdynamicsディレクトリの完全な削除 -- **バッチ処理**: あり（設定可能） -- **警告**: すべてのAppDynamicsコンポーネントが完全に削除されます - -{{% notice style="danger" %}} -「Cleanup All Agents」ワークフローは `/opt/appdynamics` を完全に削除します。この操作は元に戻せません。注意して使用してください。 -{{% /notice %}} - -## ワークフローの構造 - -すべてのバッチ処理ワークフローは、一貫した2ジョブ構成に従います: - -### ジョブ 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からターゲットホストを読み込み、バッチマトリックスを作成 - -### ジョブ 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 ジョブ** が `DEPLOYMENT_HOSTS` を読み込み、バッチに分割 -2. **Deploy ジョブ** がバッチごとに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. **エージェントの再インストール** - 必要なエージェントの再インストール - -### 完全な削除シーケンス - -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/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md deleted file mode 100644 index 427e356a38..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/4-running-workflows.md +++ /dev/null @@ -1,401 +0,0 @@ ---- -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` Secretが設定されている -- `DEPLOYMENT_HOSTS` Variableにターゲット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 -``` - -**期待される出力:** - -```text -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 ジョブの出力 - -```text -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 ジョブの出力（バッチごと） - -```text -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 -``` - -### 完了サマリー - -```text -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` Secretが実際のキーと一致していることを確認 -- ターゲットホストに公開鍵があることを確認 - -### 部分的なバッチの失敗 - -**症状**: 一部のホストが成功し、他が失敗 - -**解決策**: - -1. ワークフローログで失敗したホストを特定 -2. 失敗したホストにSSH接続して調査 -3. ワークフローを再実行（冪等性 - 成功したホストはスキップ） - -### バッチジョブエラー - -**症状**:「Error splitting hosts into batches」 - -**解決策**: - -- `DEPLOYMENT_HOSTS` Variableのフォーマットを確認 -- 1行に1つのIPであることを確認 -- 末尾のスペースや特殊文字がないことを確認 -- Unix改行コード（LF、CRLFではなく）を使用 - -## パフォーマンスチューニング - -### バッチサイズの調整 - -**小さなバッチ**（リソース使用量が少ない、速度は低下）: - -```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コア | 4 GB | 256 | -| 100-500 | 4コア | 8 GB | 256 | -| 500-2000 | 8コア | 16 GB | 256 | -| 2000+ | 16コア | 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/15-appd-workshop/6-smartagent/3-github-actions/_index.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/_index.md deleted file mode 100644 index b851e8b1b7..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/3-github-actions/_index.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -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 and AppDynamics](https://img.shields.io/badge/GitHub%20Actions-2088FF?style=flat&logo=github-actions&logoColor=white) ![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) - -## 学習内容 - -このワークショップでは、以下の内容を学びます: - -- 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ファイル -- 詳細なセットアップドキュメント -- アーキテクチャ図 -- トラブルシューティングガイド - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートするには、以下を使用します: - -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）および右（▶️）カーソルキー -{{% /notice %}} diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md deleted file mode 100644 index b34e87761c..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/2-setup.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: セットアップと設定 -weight: 2 -time: 10 minutes ---- - -## ステップ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パッケージをダウンロード済みであることを確認してください。 - -## ステップ3: ファイルの内容を理解する - -### 1. インベントリファイル（`inventory-cloud.yaml`） - -インベントリファイルには、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! -``` - -**Action**: `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 -``` - -**Action**: `smart_agent` セクションを、使用するController URL、アカウント名、アクセスキーに更新します。 - -### 3. プレイブック（`smartagent.yaml`） - -このプレイブックは、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. **クリーンアップ**: 一時パッケージファイルを削除します。 - -このプレイブックは、`when: ansible_os_family == ...` の条件分岐を使用して、同じワークフロー内でRedHatとDebianの両方のシステムに対応しています。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md deleted file mode 100644 index 9580d39fe5..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/3-deployment.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: デプロイ -weight: 3 -time: 5 minutes ---- - -## ステップ4: プレイブックを実行する - -Smart Agentをデプロイするには、プロジェクトディレクトリから以下のコマンドを実行します - -```bash -ansible-playbook -i inventory-cloud.yaml smartagent.yaml -``` - -インベントリファイルに別の名前を付けた場合は、`inventory-cloud.yaml` を適切なファイル名に置き換えます。 - -### 確認 - -プレイブックが正常に完了したら、ターゲットホストの1つにログインしてサービスの状態を確認することで、デプロイを検証できます - -```bash -systemctl status smartagent -``` - -サービスがactive (running) と表示されます。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md deleted file mode 100644 index 3ff2540be5..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/4-ansible-automation/_index.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: Smart Agent と Ansible によるモニタリングのコード化 -linkTitle: Ansible 自動化 -weight: 4 -time: 10 minutes -description: Ansible を使用した AppDynamics Smart Agent デプロイの自動化について学びます。 ---- - -## はじめに - -このガイドでは、Ansibleを使用してCisco AppDynamics Smart Agentを複数のホストにデプロイする方法を説明します。自動化を活用することで、モニタリングインフラストラクチャの一貫性、堅牢性、スケーラビリティを確保できます。 - -## アーキテクチャの概要 - -デプロイアーキテクチャは、Ansibleコントロールノードを活用して、ターゲットホストへの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**: プレイブックを実行するマシン（例: ラップトップやジャンプホスト）です。 -* **Target Hosts**: Smart Agentがインストールされるサーバーです。 -* **Inventory**: ターゲットホストとその接続情報の一覧です。 -* **Playbook**: デプロイタスクを定義するYAMLファイルです。 - -## 前提条件 - -開始する前に、以下を確認してください - -* SSH経由でターゲットホストにアクセスできること。 -* ターゲットホストでsudo権限を持っていること。 -* Smart Agentインストールパッケージ（`.deb` または `.rpm`）をダウンロード済みであること。 -* AppDynamics Controllerのアカウント情報（Access Key、Account Name、URL）を用意していること。 - -## ステップ1: macOS に Ansible をインストールする - -まず、コントロールノードに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/15-appd-workshop/6-smartagent/_index.md b/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/_index.md deleted file mode 100644 index 92105f67e4..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/6-smartagent/_index.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: SmartAgent Deployment -weight: 6 -time: 2 minutes -description: インフラストラクチャ全体で AppDynamics Smart Agent を大規模にデプロイおよび管理するための複数のアプローチを学びます。 ---- - -## はじめに - -AppDynamics **Smart Agent** は、インフラストラクチャの包括的な監視機能を提供する軽量でインテリジェントなエージェントです。このセクションでは、4つの異なるデプロイアプローチについて説明します。これにより、組織のニーズと既存のツールに最適な方法を選択できます。 - -![AppDynamics](https://img.shields.io/badge/AppDynamics-0078D4?style=flat) - -## Smart Agent とは - -Smart Agentは、AppDynamicsの次世代監視エージェントであり、以下を提供します - -- **統合監視**：インフラストラクチャ、アプリケーション、サービスを単一のエージェントで監視 -- **軽量設計**：最小限のリソースフットプリント -- **自動検出**：アプリケーションを自動的に検出して監視 -- **ネイティブ計装**：アプリケーションパフォーマンスへの深い可視性 -- **柔軟なデプロイ**：複数のインストールと管理オプション - -## デプロイアプローチ - -このセクションでは、Smart Agentを大規模にデプロイするための4つの異なるアプローチについて説明します - -### 1. リモートインストール（smartagentctl） - -SSH経由でデプロイするための `smartagentctl` CLIツールを使用する最も直接的なアプローチです。 - -**最適な用途：** - -- 中程度の数のホストへの迅速なデプロイ -- 既存のCI/CDインフラストラクチャがない環境 -- テストおよび概念実証シナリオ -- デプロイプロセスの直接制御 - -**主な機能：** - -- SSHベースの直接デプロイ -- シンプルなYAML構成 -- 追加のツールが不要 -- 同時実行のサポート - -### 2. Jenkins 自動化 - -完全なライフサイクル管理のためのJenkinsパイプラインを使用したエンタープライズグレードのデプロイです。 - -**最適な用途：** - -- すでにJenkinsを使用している組織 -- 複雑なデプロイワークフロー -- 承認ゲートが必要な環境 -- 既存のCI/CDパイプラインとの統合 - -**主な機能：** - -- パラメータ化されたパイプライン -- 数千のホストへのバッチ処理 -- 完全なライフサイクル管理 -- 集中ログとレポート - -### 3. GitHub Actions 自動化 - -セルフホストランナーを使用したGitHub Actionsワークフローによる最新のCI/CDアプローチです。 - -**最適な用途：** - -- バージョン管理にGitHubを使用しているチーム -- クラウドネイティブ環境 -- GitOpsワークフロー -- Webベースの管理を好む分散チーム - -**主な機能：** - -- 11の専用ワークフロー -- VPC内のセルフホストランナー -- GitHubシークレット統合 -- スケーラビリティのための自動バッチ処理 - -### 4. Ansible 自動化 - -Infrastructure as CodeのためのAnsibleプレイブックを使用した構成管理アプローチです。 - -**最適な用途：** - -- 構成管理にAnsibleを使用しているチーム -- 宣言的なインフラストラクチャ定義 -- フリート全体での一貫した状態管理 - -**主な機能：** - -- Infrastructure as Code（IaC） -- 冪等性のあるプレイブック -- インベントリ管理 -- ロールベースの構成 - -## 適切なアプローチの選択 - -| 要素 | リモートインストール | Jenkins | GitHub Actions | Ansible | -| -------- | ------------------- | --------- | ---------------- | --------- | -| **セットアップの複雑さ** | 低 | 中 | 中 | 低 | -| **スケーラビリティ** | 良好（数百ホスト） | 優秀（数千） | 優秀（数千） | 優秀（数千） | -| **前提条件** | SSH アクセスのみ | Jenkins サーバー | GitHub アカウント | Ansible Control Node | -| **学習曲線** | 最小 | 中程度 | 中程度 | 低/中程度 | -| **自動化レベル** | 手動実行 | 完全自動化 | 完全自動化 | 完全自動化 | -| **最適なユースケース** | 迅速なデプロイ | エンタープライズ CI/CD | モダン DevOps | Infrastructure as Code | - -## すべてのアプローチに共通する機能 - -どのデプロイ方法を選択しても、すべてのアプローチで以下の項目が提供されます - -- ✅ リモートホストへの **SSH ベースのデプロイ** -- ✅ より高速なデプロイのための **同時実行** -- ✅ **完全なライフサイクル管理**（インストール、開始、停止、アンインストール） -- ✅ コントローラー設定の **構成管理** -- ✅ **エラー処理** とログ -- ✅ 数百から数千のホストへの **スケーラビリティ** - -## ワークショップ構成 - -各デプロイアプローチには専用のセクションがあります - -1. **リモートインストール** - CLIベースの直接デプロイ -2. **Jenkins 自動化** - パイプラインベースのエンタープライズデプロイ -3. **GitHub Actions** - 最新のワークフローベースのデプロイ -4. **Ansible 自動化** - Infrastructure as Codeデプロイ - -ニーズに応じて、1つまたはすべてのアプローチに従うことができます。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -Smart Agentのデプロイが初めての場合は、より自動化されたソリューションに進む前に、基本を理解するために **リモートインストール** アプローチから始めることをお勧めします。 -{{% /notice %}} - -## 前提条件 - -いずれのデプロイアプローチに進む場合でも、以下の項目を確認してください - -- コントローラーアクセスを持つAppDynamicsアカウント -- アカウント名とアクセスキー -- SSHアクセスを持つターゲットホスト -- ホストからAppDynamics Controllerへのネットワーク接続 -- ターゲットホストでの適切な権限 - -## 次のステップ - -お好みのデプロイアプローチを選択し、そのセクションに進んでください - -- **シンプルに始める**：基礎を学ぶためにリモートインストールから始める -- **Jenkins でスケール**：エンタープライズグレードの自動化のためにJenkinsに移行 -- **GitHub でモダン化**：クラウドネイティブワークフローのためにGitHub Actionsを採用 -- **Ansible で自動化**：宣言的な構成管理のためにAnsibleを使用 - -各セクションでは、Smart Agentを大規模にデプロイするための完全なハンズオンガイダンスを提供します。 diff --git a/content/ja/ninja-workshops/15-appd-workshop/_index.md b/content/ja/ninja-workshops/15-appd-workshop/_index.md deleted file mode 100644 index 1802472bd6..0000000000 --- a/content/ja/ninja-workshops/15-appd-workshop/_index.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Splunk4Ninjas AppDynamics -weight: 15 -time: 2 minutes -description: Splunk AppDynamics を使用したフルスタックアプリケーションパフォーマンス監視について学びます。Java APM エージェントのインストール、アプリケーションの健全性監視、パフォーマンス問題のトラブルシューティング、BRUM によるブラウザメトリクスの追跡、データベースパフォーマンスの分析、Business IQ によるビジネスインサイトの取得まで幅広くカバーします。 ---- - -## はじめに - -Splunk AppDynamicsは、ビジネスクリティカルなアプリケーション向けのフルスタックパフォーマンス監視ソリューションであり、以下の機能を提供します - -- 従来型、ハイブリッド、クラウドネイティブなど、環境を問わない一貫したエンドツーエンドのアプリケーション監視 -- クラウド移行の加速と、デプロイ先を問わないエンタープライズグレードのエンドツーエンドインサイト -- パフォーマンス問題がビジネス上の問題になる前に迅速に解決できる統合監視（3クリックで根本原因を特定） - -従来型、クラウド、またはハイブリッドデプロイメントにおいて、AppDynamicsプラットフォームの既存の人員、プロセス、トレーニングを活用することで、総所有コストを最適化できます。 - -![Screenshot of AppDynamics Dashboard](images/controller-vm.png) - -## ワークショップ概要 - -このワークショップでは、Splunk AppDynamicsの基本について説明します。Splunk AppDynamicsを使用して、アプリケーションサービス、Webアプリケーション、データベースなどの健全性を監視する方法を紹介します。このワークショップを完了すると、以下のことができるようになります - -- AppDynamics Java APM Agentのダウンロードとインストール -- Controllerでの収集設定の構成 -- アプリケーションのパフォーマンス健全性の監視とトラブルシューティング -- AppDynamicsがキャプチャしたデータに基づくAppDynamics監視サービスでのアラート監視 -- サーバーの健全性監視と問題のトラブルシューティング -- BRUMを使用したブラウザベースアプリケーションの健全性監視 -- データベースパフォーマンスの監視とトラブルシューティング -- Splunk AppDynamics Business IQによるユーザーに関するより深いインサイトの取得 - -## 今後追加予定の内容 - -- ヘルスルールに関するセクションの追加（既存のヘルスルールの確認方法、新規ヘルスルールの作成方法） -- Application Security diff --git a/content/ja/ninja-workshops/15-appd-workshop/images/controller-vm.png b/content/ja/ninja-workshops/15-appd-workshop/images/controller-vm.png deleted file mode 100644 index 21b0cce620..0000000000 Binary files a/content/ja/ninja-workshops/15-appd-workshop/images/controller-vm.png and /dev/null differ diff --git a/content/ja/ninja-workshops/16-obi-ebpf/1-workshop-overview/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/1-workshop-overview/_index.md deleted file mode 100644 index 2930fb1ded..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/1-workshop-overview/_index.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -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 host | 提供済み (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 に送信します。Splunk OTel Collector はそれを Splunk Observability Cloud に転送します。 - -## OBI とは？ - -[OBI (OpenTelemetry eBPF Instrumentation)](https://opentelemetry.io/docs/zero-code/obi/) は、Linux カーネルの eBPF プローブを使用してアプリケーションを流れる HTTP/gRPC トラフィックを観測するスタンドアロンエージェントです。**カーネルから**プロセスにアタッチするため、SDK もコード変更も再コンパイルも不要です。リクエストを検出し、OpenTelemetry 互換のトレーススパンを生成して、コレクターに送信します。 - -これは SDK で計装**できない**、または**したくない**組織にとって価値があります - -- ソースアクセスのないレガシーシステム -- 再コンパイルが選択肢にないコンパイル言語 -- 開発者の抵抗（「計装を追加する時間がない」） -- コード変更によって完全な監査サイクルが発生する規制上の制約 - -## 価値提案 - -多くの組織には、OpenTelemetry SDK で計装**できない**、または**したくない**アプリケーションがあります - -- **レガシーシステム**: COBOL から Java への移行、10年以上前の .NET Framework アプリ、ソースアクセスのないベンダー提供バイナリ -- **コンパイル言語**: 再コンパイルが選択肢にない、またはチームが離れてしまった Go、Rust、C++ サービス -- **開発者の抵抗**: 「時間がない」、「スプリントに入っていない」、「動いているコードは変えない」 -- **規制上の制約**: コード変更によって完全な監査・認証サイクルが発生する - -OBI は**コード変更なしで完全な分散トレーシング**を提供します - -- **SDK 統合不要**: インポートなし、依存関係なし、コンパイル時の変更なし -- **アプリケーション再起動不要**: OBI は eBPF を介して実行中のプロセスにアタッチします -- **言語非依存**: Go、Node.js、Python、Java、Rust、C++ など、HTTP または gRPC を使用するあらゆるものに対応 -- **1つのコンテナまたは1つの Helm フラグ**: compose に追加するか、Helm chart で `obi.enabled=true` を有効にするだけで完了 - -## OBI と従来のゼロコード計装の比較 - -OBI と既存の従来型言語固有ゼロコード計装（Java、JS、.NET、Python、Go、PHP）は、オブザーバビリティ戦略において補完的な役割を果たします。違いを理解することで、各アプローチをいつ使用すべきかを判断できます。 - -### 1. 計装モデル - -| 項目 | OBI | 従来のゼロコード計装 | -|---|---|---| -| 実行モデル | プロセス外 | プロセス内 | -| 計装レイヤー | Linux カーネル / ネットワーク | アプリケーションランタイム | -| コード変更の必要性 | なし | なし、または最小限 | -| アプリケーション再起動の必要性 | なし | あり | -| セキュリティプロファイル | 分離 | アプリケーションと同じ権限プロファイル | - -### 2. 可視性のレベル - -| 機能 | OBI | 従来のゼロコード計装 | -|---|---|---| -| 分散トレーシング | プロトコルレベル | フルフィデリティ | -| RED メトリクス | あり | あり | -| アプリケーションログ収集 | なし | あり | -| アプリケーションログとトレースの相関 | あり | あり | -| アプリケーション内部（フレームワーク、関数） | なし（部分的、主に Go） | あり | -| カスタムスパン / ビジネス属性 | なし | あり | -| ランタイムメトリクス（JVM、メモリ、スレッド） | 現時点ではなし | あり | - -### 3. カバレッジと互換性 - -| シナリオ | OBI | 従来のゼロコード計装 | -|---|---|---| -| マルチ言語環境 | 強い（プロトコルベース） | 言語固有 | -| サードパーティアプリケーション | サポート | 限定的、contrib リポジトリ | -| レガシーシステム | サポート | 限定的 | -| コンパイル言語 (C/C++/Rust) | サポート（非同期に一部制限あり） | 限定的 | -| 非同期 / 複雑なフレームワーク | 一部のケースで限定的 | 強い | - -### 4. 運用特性 - -| 項目 | OBI | 従来のゼロコード計装 | -|---|---|---| -| デプロイの手間 | 低い（ドロップイン） | 中程度（エージェントアタッチ） | -| 最初の可視化までの時間 | 数分 | 「もう少し」かかる | -| アプリケーションライフサイクルへの変更 | なし | あり | -| パフォーマンスオーバーヘッド | 最小限で分離されている | 言語/ランタイムにより異なる | - -### 5. Splunk ディストリビューション機能 - -| 機能 | OBI | 従来のゼロコード計装 | -|---|---|---| -| Always-on Profiling | なし（将来 eBPF プロファイラーとバンドルされる可能性あり） | ほとんどで CPU、一部で Memory | -| コールグラフ | なし | ほとんどで CPU、一部で Memory | -| ファイルベース設定 | 対応予定 | Java、Node.js、.NET、Python（対応予定） | -| No-code instrumentation | N/A | あり | diff --git a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/1-install-and-run.md b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/1-install-and-run.md deleted file mode 100644 index 6155d3edc6..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/1-install-and-run.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -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 に送信します。以下のように表示されるはずです - -``` text -Heartbeat sent to Splunk (200) - * Running on http://0.0.0.0:5150 -``` - -エンドポイントにアクセスして、動作していることを確認します - -``` bash -curl http://localhost:5150/hello -``` - -以下のレスポンスが返ってくるはずです - -``` json -{ - "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` 属性を持つメトリクスが表示されるはずです。 - -![app.heartbeat](./images/heartbeat.png) - -{{% notice title="Note" style="info" %}} -この時点で、アプリが動作しており、Splunk がデータを受信できることが確認できました。しかし、**トレースはゼロ**で APM は空です。アプリにはインストルメンテーションコードがまったくありません。 -{{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md deleted file mode 100644 index 5639b75e9b..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/2-instrument-with-obi.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: 2. OBI でインストルメントする -weight: 2 ---- - -実行中のアプリに**コードを一行も変更せずに** APM トレーシングを追加します。 - -## OBI のダウンロード - -[GitHub リリースページ](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases)からビルド済みの OBI バイナリをダウンロードします。 - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -VERSION=0.6.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="Exercise" 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 の直接取り込みには標準的な OTLP メトリクスエンドポイントがありません。トレースは正常にエクスポートされます。Phase 2 では、Collector がトレースとメトリクスの両方を適切に処理します。 -{{% /notice %}} - -## トラフィックの生成 - -最初のターミナルに戻り、いくつかのリクエストを生成します。 - -```bash -for i in $(seq 1 20); do curl -s "http://localhost:5150/hello"; sleep 1; done -``` - -***注意:*** 404 エラーが発生した場合は、curl している URL の末尾に `\` が付加されていないか確認してください。一部のターミナルでは `;` がエスケープされ、無効な URL になることがあります diff --git a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md deleted file mode 100644 index 4ee7a0cf46..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/3-verify-in-splunk.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -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 を返すことと heartbeat メトリクスを送信することしかできません。 -2. OBI はカーネルのネットワークスタックに eBPF プローブをアタッチし、アプリのプロセスを流れる HTTP トラフィックを観測しました。 -3. OBI は OpenTelemetry 互換のトレーススパンを生成し、Splunk に直接送信しました。 - -**SDK なし、コード変更なし、再起動なしで、カーネルから実行中のプロセスに分散トレーシングを追加しました。** - -これは Phase 1 と Phase 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/16-obi-ebpf/2-python-warmup/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/_index.md deleted file mode 100644 index 31d36c6578..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/2-python-warmup/_index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: "Phase 0: Python ウォームアップ" -linkTitle: 2. Python Warm-up -weight: 2 -archetype: chapter -time: 15 minutes -description: ホスト上で素の Python アプリを実行し、カスタムメトリクスを使用して Splunk への接続を確認した後、OBI バイナリを使用して APM トレースを追加します。すべて Docker なしで行います。 ---- - -このフェーズでは、OBI が生の Linux プロセス上で**カーネルレベル**で動作することを示します。コンテナなし、サイドカーなし、SDK なし、ただ eBPF バイナリがカーネルからアプリを監視するだけです。 - -このセクションの終了時には、以下が完了します - -1. オブザーバビリティコードがゼロの Python Flask アプリの実行 -2. Splunk 組織がデータを受信していることの確認（カスタムメトリクス経由） -3. コード変更なしでカーネルからアプリに追加された完全な APM トレース diff --git a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md deleted file mode 100644 index e2f8b8ad3d..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/1-configure-and-start.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: 1. スタックの設定と起動 -weight: 1 ---- - -## Splunk 認証情報の追加 - -{{% notice title="演習" style="green" icon="running" %}} - -**注:** 環境で `env` コマンドを使用して `ACCESS_TOKEN`、`REALM`、`INSTANCE` を取得してください。これらを設定ファイルに貼り付ける必要があります。 - -Phase 1/2 ディレクトリに移動し、エディタで `docker-compose.yaml` を開きます: - -``` bash -cd ~/workshop/obi/02-obi-docker -vim docker-compose.yaml #or editor of choice -``` - -`splunk-otel-collector` サービスを見つけ、4つのプレースホルダー値を実際の認証情報に置き換えます: - -``` 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 組織にテレメトリを送信します。これらの値はすべてのメトリクスとトレースの `host.name` および `deployment.environment` 属性になるため、Splunk で**自分の**データをフィルタリングできます。 -{{% /notice %}} - -## スタックの起動 - -{{< tabs >}} -{{% tab title="スクリプト" %}} - -``` bash -docker-compose up --build -d -``` - -{{% /tab %}} -{{% tab title="出力例" %}} - -``` 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/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md deleted file mode 100644 index 689ab87a5f..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/2-generate-traffic.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: 2. トラフィックの生成 -weight: 2 ---- - -## フロントエンドへのアクセス - -{{% notice title="演習" style="green" icon="running" %}} - -curlを使用してトラフィックを生成します: - -``` bash -curl -s http://localhost:3000/create-order | python3 -m json.tool -``` - -{{% /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/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md deleted file mode 100644 index 72556f117c..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/3-check-splunk.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -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. 定義した環境（`WORKSHOP_ENVIRONMENT`）でフィルタリングします -3. **空**であるはずです（または存在しないはずです）。サービス、トレース、サービスマップはありません - -{{% /notice %}} - -Collector はインフラストラクチャメトリクスを送信しています。これはデフォルトの動作ですが、何もトレースを生成していないため、エクスポートするトレースがありません。 - -{{% notice title="注記" style="info" %}} -これが「導入前」の状態です。3つのサービスが実際のリクエストを処理していますが、Splunk APM からはそれらのリクエストがまったく見えていません。次のセクションでは、**アプリケーションコードに触れることなく**、これを解決します。 -{{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/_index.md deleted file mode 100644 index caccfbd274..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/3-docker-before-obi/_index.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "フェーズ 1: Docker (OBI 適用前)" -linkTitle: 3. OBI 適用前の Docker -weight: 3 -archetype: chapter -time: 15 minutes -description: Docker Compose で 3 つのマイクロサービスをデプロイし、APM が空であることを確認します。計装がないため、トレースは存在しません。 ---- - -このフェーズでは、ポリグロット（またこの言葉です！）マイクロサービススタックをデプロイし、「適用前」の状態を確認します。インフラストラクチャメトリクスは Splunk に送信されますが、アプリケーションには計装が一切ないため、APM にはトレースがまったくありません。 - -```text -Frontend (Node.js :3000) → Order-Processor (Go :8080) → Payment-Service (Go :8081) -``` diff --git a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md deleted file mode 100644 index f0218b0a93..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/1-add-obi-service.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: 1. OBI サービスの追加 -weight: 1 ---- - -## docker-compose.yaml に OBI を追加する - -{{% notice title="Exercise" 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` と書かれたコメントブロックがあります。以下のブロックを**そのコメントの直下に**貼り付けてください。**2スペースのインデント**を維持して、他のサービス（`frontend:`、`load-generator:` など）と揃うようにします - -``` 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="Tip" 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="Script" %}} - -``` bash -docker-compose up -d -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` 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/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md deleted file mode 100644 index 23012aa5b3..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/2-understand-config.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -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 にサービスの検出方法と名前の付け方を指示します。リッスンしているポートでプロセスをマッチングし、生成されたトレースの `service.name` 属性として `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 ファイルでホストにマッピングされたコレクターのポートに到達します。 - -{{% notice title="Tip" 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/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md deleted file mode 100644 index 080a9938a0..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/3-verify-traces.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: 3. Splunk でトレースを確認する -weight: 3 ---- - -## クイック検証 - -まず、すべてが正常に動作していることを確認します： - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -docker-compose ps -curl -s localhost:3000/create-order | python3 -m json.tool -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="Exercise" style="green" icon="running" %}} - -1. **Service Map**: APMに移動し、ご自身の環境でフィルタリングします。3つのサービスが表示されるはずです: `frontend` -> `order-processor` -> `payment-service`。 -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/16-obi-ebpf/4-docker-obi-magic/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/_index.md deleted file mode 100644 index b040b9d4cb..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/4-docker-obi-magic/_index.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "フェーズ 2: OBI マジック" -linkTitle: 4. Docker with OBI -weight: 4 -archetype: chapter -time: 20 minutes -description: OBI eBPF エージェントを Docker Compose スタックに追加します。アプリケーションコードを一切変更せずに、完全な分散トレースが Splunk APM に表示されます。 ---- - -このフェーズでは、Docker Composeスタックに1つのコンテナを追加します。アプリケーションコードを一切変更せずに、3つすべてのサービスにわたる完全な分散トレースがSplunk APMに表示されます。 - -{{% notice icon="user" style="orange" title="重要なポイント" %}} -これがこのワークショップのコアデモです。**1つのコンテナ**を追加し、**アプリケーションコードを1行も変更せずに**、**トレースゼロ**から**完全な分散トレーシング**へ移行します。 -{{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md deleted file mode 100644 index a1775e03f6..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/1-build-and-load-images.md +++ /dev/null @@ -1,125 +0,0 @@ ---- -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="ヒント" 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/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md deleted file mode 100644 index 6418557449..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/2-deploy-baseline.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: 2. ベースラインのデプロイ -weight: 2 ---- - -## ワークショップアプリケーションのデプロイ - -アプリケーションは専用の namespace にデプロイされます: - -{{< 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) は、Kubernetes に Collector をデプロイするための本番環境向けの方法です。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 | python3 -m json.tool -``` - -## APM が空であることを確認 - -{{% notice title="Exercise" style="green" icon="running" %}} - -Splunk APM で環境 `-ebpf` でフィルタリングして確認してください。Collector からのインフラストラクチャメトリクスは表示されますが、**新しいアプリケーショントレースはまだ表示されません**。サービスは実行中ですが、まだ計装されていません。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md deleted file mode 100644 index 8f46005d8f..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/3-add-obi-daemonset.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: 3. Helm で OBI を有効化 -weight: 3 ---- - -アプリケーションコードを一切変更せずに、Helm のアップグレード1回だけでクラスター全体にトレーシングを追加します。 - -## OBI を有効にして Collector をアップグレード - -{{% notice title="Exercise" 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 ケーパビリティを付与 - -### OBI に必要なものは？ - -OBI Pod は、eBPF がカーネルレベルで動作するため、昇格した権限で実行されます - -``` 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 | python3 -m json.tool -``` - -## Splunk APM を確認 - -トレースが流れるまで30〜60秒待ちます。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -1. **Service Map**: `frontend` -> `order-processor` -> `payment-service` の3つのサービスが表示されるはずです。 -2. **Traces**: 任意のトレースをクリックします。3つのサービスすべてにまたがる完全な分散トレースと、各ホップのタイミングが表示されます。 -3. **フェーズ2と同じストーリー**: コード変更ゼロ。1つのフラグを付けた `helm upgrade` 1回だけです。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/4-how-this-scales.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/4-how-this-scales.md deleted file mode 100644 index 944691b417..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/4-how-this-scales.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: 4. スケーリングの仕組み -weight: 4 ---- - -## 環境全体に共通するパターン - -フェーズ0ではバイナリを実行しました。フェーズ2（Docker）ではコンテナを1つ追加しました。フェーズ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) は、コレクターと OBI の両方を本番環境にデプロイするための方法です。さらなる自動化のために、[OpenTelemetry Operator](https://opentelemetry.io/docs/kubernetes/operator/) はアノテーションを使用して OBI をサイドカーとして自動的にインジェクトすることができます。 - -## 価値提案（まとめ） - -多くの組織には、OpenTelemetry SDK で計装**できない**、または**しない**アプリケーションがあります - -- **レガシーシステム**: COBOL から Java への移行、10年以上前の .NET Framework アプリ、ソースアクセスのないベンダー提供のバイナリ -- **コンパイル言語**: Go、Rust、C++ のサービスで、再コンパイルができない、またはチームがすでに離れている場合 -- **開発者の抵抗**: 「時間がない」「スプリントに入っていない」「動いているコードは変えたくない」 -- **規制上の制約**: コード変更により完全な監査/認証サイクルが発生する場合 - -OBI は**コード変更なしで完全な分散トレーシング**を提供します - -- **SDK 統合不要**: インポート不要、依存関係不要、コンパイル時の変更不要 -- **アプリケーションの再起動不要**: OBI は eBPF を介して実行中のプロセスにアタッチします -- **言語に依存しない**: Go、Node.js、Python、Java、Rust、C++ など、HTTP または gRPC を使用するあらゆる言語で動作します -- **コンテナ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/16-obi-ebpf/5-kubernetes/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/_index.md deleted file mode 100644 index 5e54ed1fe2..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/5-kubernetes/_index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "Phase 3: Kubernetes" -linkTitle: 5. Kubernetes -weight: 5 -archetype: chapter -time: 25 minutes -description: Deploy the same three services to Kubernetes, add the OBI DaemonSet, and get full distributed tracing same zero-code story, enterprise-grade orchestration. ---- - -このフェーズでは、Phase 2 とまったく同じ「素の」アプリケーションコードを使用し、[Splunk OTel Collector Helm chart](https://github.com/signalfx/splunk-otel-collector-chart) を使って Kubernetes にデプロイします。 - -Collector は Helm を通じてデプロイされ、OBI は `obi.enabled=true` という単一のフラグで有効化されます。これにより、すべてのノードのすべての Pod を計装する OBI DaemonSet がデプロイされます。 diff --git a/content/ja/ninja-workshops/16-obi-ebpf/6-wrap-up/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/6-wrap-up/_index.md deleted file mode 100644 index c20fade2ce..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/6-wrap-up/_index.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: まとめ -linkTitle: 6. まとめ -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 -helm 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/16-obi-ebpf/_index.md b/content/ja/ninja-workshops/16-obi-ebpf/_index.md deleted file mode 100644 index 5c7042b45f..0000000000 --- a/content/ja/ninja-workshops/16-obi-ebpf/_index.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -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: OpenTelemetry eBPF Instrumentation (OBI) がコードを一切変更せずにアプリケーションへ完全な分散トレーシングを追加し、Splunk Observability Cloud にテレメトリを送信する方法を体験するハンズオンワークショップです。 ---- - -このワークショップでは、**OpenTelemetry eBPF Instrumentation (OBI)** のパワーを体験します。OBI は、Linux カーネルから直接サービスを計装する、コード変更不要のアプリケーションパフォーマンスモニタリング手法です。 - -3つのフェーズを順に進めていきます。各フェーズは前のフェーズを基に構築されています: - -- **Phase 0 -- Python ウォームアップ**: ホスト上で素の Python アプリを実行します。OBI バイナリを使用してカーネルから APM トレーシングを追加します -- SDK もコード変更も不要です。 -- **Phase 1 -- Docker (OBI 導入前)**: 3つのポリグロットマイクロサービス (Node.js + Go + Go) を Docker Compose でデプロイします。APM が空であることを確認します。 -- **Phase 2 -- Docker (マジック)**: OBI コンテナを1つ追加します。3つのサービスすべてにわたる完全な分散トレースが Splunk APM に表示されます。コード変更はゼロです。 -- **Phase 3 -- Kubernetes**: 同じサービスを K8s にデプロイし、Splunk OTel Collector Helm chart を使用します。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 -``` - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを進める最も簡単な方法は以下を使用することです: - -- このページの右上にある左右の矢印 (**<** | **>**) -- キーボードの左右カーソルキー -{{% /notice %}} diff --git a/content/ja/ninja-workshops/17-appd-ingest/1-overview/_index.md b/content/ja/ninja-workshops/17-appd-ingest/1-overview/_index.md deleted file mode 100644 index eb3efad432..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/1-overview/_index.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: ワークショップの概要 -linkTitle: 1. Overview -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 の両方に送信する -- 両方のプラットフォームでトレースとメトリクスを確認する -- Splunk Observability Cloud で AppDynamics へのワンクリックナビゲーション用の**グローバルデータリンク**を作成する - -## アーキテクチャ - -このワークショップでは、EC2 インスタンス上で Spring Boot Java アプリケーションを直接実行します。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 にエクスポートします。 - -**注意:** Collector を使用せずにエージェントから直接 [OTLP インジェストエンドポイント](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 | - -これらの属性により、**グローバルデータリンク**が有効になります。これは 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` を実行 | -| **インスタンス名** | インスタンスで `echo $INSTANCE` を実行 | -| AppDynamics Controller アクセス | [SE Lab Controller](https://se-lab.saas.appdynamics.com/controller/) に Cisco 資格情報でログイン | diff --git a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/1-build-the-app.md b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/1-build-the-app.md deleted file mode 100644 index ac8db700ab..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/1-build-the-app.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -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 & -``` - -数秒待ってからテストします： - -{{< 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/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md deleted file mode 100644 index b8b55cf122..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/2-download-appd-agent.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: 2. AppD エージェントのダウンロード -weight: 2 ---- - -デュアルシグナルモードを使用するには、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. **Settings**（歯車アイコン）→ **License** に移動します -2. 左側のサイドバーで **Account** をクリックします -2. **Account** の下にある **Name**（`se-lab`）と **Access Key** をメモします - -{{% notice title="手元に控えておきましょう" style="primary" icon="lightbulb" %}} -次のステップで Account Name と Access Key を JVM プロパティとして使用します。これらはエージェントをコントローラーに認証するために必要です。 -{{% /notice %}} diff --git a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/3-run-and-verify.md b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/3-run-and-verify.md deleted file mode 100644 index 100388ad53..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/3-run-and-verify.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -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` エンドポイントのビジネストランザクション -- コントローラーに流れるメトリクスデータ - -この時点では、データは **AppDynamics にのみ**送信されています。アプリケーションは Splunk Observability Cloud に接続されていません。次のフェーズでは、デュアルシグナルモードを有効にしてこれを変更します。 -![AppDynamics Application](../../_images/appd-service.png?width=30vw) - -{{% notice title="実行を継続してください" style="warning" icon="exclamation-triangle" %}} -アプリケーションと負荷生成ツールは実行したままにしてください。次のセクションでデュアルモードフラグを追加するために停止します。 -{{% /notice %}} diff --git a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/_index.md b/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/_index.md deleted file mode 100644 index 33c9d72a7a..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/2-run-with-appd/_index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "フェーズ 1: AppDynamics で実行する" -linkTitle: 2. AppD で実行 -weight: 2 -archetype: chapter -time: 15 minutes -description: ワークショップアプリをビルドし、AppDynamics Java Agent をダウンロードし、サービスを実行して、AppDynamics Controller でデータを確認します。 ---- - -このフェーズでは、シンプルなJavaアプリケーションをビルドし、AppDynamics Java Agentをアタッチして、AppDynamics ControllerにAPMデータが表示されることを確認します。 - -これは、現在ほとんどのAppDynamicsユーザーが使用している「通常の」単一送信先インストルメンテーションです。 diff --git a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md deleted file mode 100644 index 14d705c6c8..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/1-install-otel-collector.md +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: 1. OTel Collector のインストール -weight: 1 ---- - -デュアルモードの AppDynamics エージェントは、OTLP 経由で OpenTelemetry データを送信します。そのデータを受信して 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 ログエクスポートの詳細を渡しています。これはログを出力し、相関させるために重要です。 - -## ワークショップ用コレクター設定の適用 - -デフォルトのコレクター設定は汎用的なものです。これを、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 を超える属性を持つメトリクスをチェックします（メトリクスに付随する実際の値もポイントとしてカウントされます）。 - -- **重要: 現在、バックエンドでは属性が多すぎる（36 を超える）メトリクスはドロップされます。** これは、追加の属性により AppDynamics テレメトリで発生する可能性があります。 - -`transform` 設定では、メトリクスの合計属性数が 34 を超えているかどうかを確認し、超えている場合は価値の低い属性を段階的に削除します。 -最後に、利用可能なスペースを確認した後、`cardinality.trimmed` ディメンションを追加して、属性が削除されたメトリクスを簡単に特定できるようにします。 - -これらの各プロセッサは、設定内のメトリクス用 `pipeline:` の末尾に含まれています。 - -次に、そのカスタム設定を `agent_config.yaml` にコピーします - -```bash -sudo cp ~/workshop/appd/collector-config.yaml /etc/otel/collector/agent_config.yaml -``` - -## コレクターの再起動 - -新しい設定を反映するために再起動します - -{{< tabs >}} -{{% tab title="Command" %}} - -```bash -sudo systemctl restart splunk-otel-collector -``` - -{{% /tab %}} -{{< /tabs >}} - -## コレクターの動作確認 - -{{< 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/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md deleted file mode 100644 index e96541f28f..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/2-enable-dual-mode.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: 2. デュアルモードの有効化 -weight: 2 ---- - -JVM コマンドラインにデュアルシグナルモードのフラグを追加して、アプリケーションを再起動します。 - -## 実行中のアプリケーションを停止する - -フェーズ 1 のアプリケーションとロードジェネレーターを停止します - -```bash -kill %2 2>/dev/null # stop load generator -kill %1 2>/dev/null # stop the java app -``` - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -`kill %1` が動作しない場合は、`ps aux | grep ingest-workshop` で PID を確認し、直接 kill してください。 -{{% /notice %}} - -## デュアルモードで再起動する - -同じ AppD フラグに加えて、デュアルモードと OTel エクスポーターのフラグを追加してアプリケーションを再度実行します。フェーズ 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 の起動バナーが表示されるまで待ちます。 -Enter キーを押してプロンプトに戻ります。 - -### 新しいフラグの説明 - -| フラグ | 目的 | -|---|---| -| `-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 トレース** をローカル OTel Collector（`localhost:4318`）へ送信し、そこから Splunk Observability Cloud に転送されます - - インスタンスで `env` を使用して、環境 `deployment.environment=${INSTANCE}-appd-dual` に使用される `{INSTANCE}` の値を確認できます diff --git a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md deleted file mode 100644 index a5acad4347..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/3-verify-in-both.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -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` の値と一致します）。 -![AppDynamics Application](../../_images/o11y-service.png?width=30vw) - -{{% notice title="数分お待ちください" style="info" icon="info-circle" %}} -デュアルモードを有効にしてからトレースが表示されるまで 2〜5 分かかることがあります。サービスがまだ表示されない場合は、しばらく待ってからページを更新してください。 -{{% /notice %}} - -4. サービスリストに **OrderService** が表示されるはずです。 - -## トレースを探索する - -1. **OrderService** サービスをクリックします。 -2. **Traces** をクリックして個々のトレースを表示します。 -3. `GET /order` のトレースを選択して、トレース詳細のウォーターフォールを開きます。 - -トレースウォーターフォールには、OTel Java 自動計装によって生成されたスパンが表示されます。これらは AppDynamics も監視しているのと同じリクエストです。 -![APM waterall](../../_images/waterfall.png) - -## 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/17-appd-ingest/3-enable-dual-mode/_index.md b/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/_index.md deleted file mode 100644 index 236cf083c9..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/3-enable-dual-mode/_index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "フェーズ 2: デュアルシグナルモードの有効化" -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/17-appd-ingest/4-global-data-links/_index.md b/content/ja/ninja-workshops/17-appd-ingest/4-global-data-links/_index.md deleted file mode 100644 index abef045661..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/4-global-data-links/_index.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: "フェーズ 3: Global Data Links" -linkTitle: 4. Global Data Links -weight: 4 -archetype: chapter -time: 10 minutes -description: appd.* スパン属性を使用して、対応する AppDynamics ティアビューに直接ナビゲートするグローバルデータリンクを Splunk Observability Cloud で作成します。 ---- - -{{% notice title="注意" style="primary" icon="lightbulb" %}} -グループワークショップに参加している場合は、インストラクターの指示に従い、追加のグローバルデータリンクを作成しないでください。 -このセクションを自分で完了する必要はありません。これらの手順は、学習および文書化の目的で含まれています。 -ご協力ありがとうございます！ -{{% /notice %}} - -トレースに付与された `appd.*` 属性は単なるメタデータではありません。**グローバルデータリンク**を活用することで、Splunk Observability Cloud でトレースを表示しているユーザーがワンクリックで対応する AppDynamics ビューに直接ジャンプできるようになります。 - -## グローバルデータリンクとは？ - -グローバルデータリンクは、スパン属性、タグ値、またはメトリクスディメンションにクリック可能なリンクを作成する Splunk Observability Cloud の機能です。ユーザーがリンクされた値をクリックすると、定義した外部 URL に実際の属性値が代入された状態で遷移します。 - -### データリンクの前提条件 - -AppDynamics でアプリケーションの URL をコピーします。アプリケーションを識別する URL の重要な部分は、URL のクエリパラメータです（例: `&application=99999`）。 -アプリケーションクエリパラメータを含む完全な URL を使用して、グローバルデータリンクを構築します。 -![AppD Application ID](../_images/app-url.png) - -## グローバルデータリンクの作成 - -1. Splunk Observability Cloud で、左側のナビゲーションパネルにある **Settings**（歯車アイコン）をクリックします。 -2. **Global Data Links** をクリックします。 -3. **New Link** をクリックします。 -4. リンクを設定します: - -| フィールド | 値 | -| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -| **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 テンプレート構文" style="primary" icon="lightbulb" %}} -二重波括弧 `{{ end_time }}` と `{{ start_time }}` はテンプレート変数です。Splunk Observability Cloud がクリック時に実際の値に置き換えます。 - -`` は、特定のアプリケーションのクエリパラメータから取得した番号です。 -{{% /notice %}} -![Global Datalink Config](../_images/global-datalink-config.png?width=50vw) - -5. **Save** をクリックします。 - -## グローバルデータリンクのテスト - -1. **APM** に戻り、**OrderService** サービスのトレースを開きます。 -2. ルートスパンをクリックして属性を表示します。 -3. 属性リストで `appd.app.name` を見つけます。**Open in AppDynamics** というラベルのクリック可能なリンクになっているはずです。 -4. リンクをクリックします。新しいブラウザタブが開き、AppDynamics Controller の **OrderService** アプリケーションビューに直接遷移します。 -![Global Datalink Config](../_images/datalink.png?width=20vw) - -{{% notice title="注意" style="info" icon="info-circle" %}} -リンクが機能するためには、同じブラウザで AppDynamics Controller にログインしている必要があります。ログインを求められた場合は、Cisco の資格情報を使用してください。 -{{% /notice %}} - -## 逆方向のナビゲーション（AppD から Splunk へ） - -逆方向のナビゲーションも可能です。デュアルモードでキャプチャされた 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 を検索します。 - -これにより、2つのプラットフォーム間の**双方向の関連付け**が実現されます。 -![AppDynamics Trace ID](../_images/appd-traceid.png?width=30vw) diff --git a/content/ja/ninja-workshops/17-appd-ingest/5-wrap-up/_index.md b/content/ja/ninja-workshops/17-appd-ingest/5-wrap-up/_index.md deleted file mode 100644 index 86a8775871..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/5-wrap-up/_index.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: まとめ -linkTitle: 5. まとめ -weight: 5 -archetype: chapter -time: 5 minutes -description: まとめ、クリーンアップ、次のステップ。 ---- - -## 達成したこと - -このワークショップでは、以下のことを行いました - -1. **通常の AppDynamics 計装で Java サービスをビルドして実行しました**：単一のエージェントが APM データを AppDynamics Controller にのみ送信します。 - -2. **ハイブリッドモードとデュアルシグナルモードの違いを学びました**：ハイブリッドは AppD 独自の計装を再利用して OTel スパンを生成します（オーバーヘッドが低く、カバレッジが狭い）。一方、デュアルは AppD と並行して完全な OTel Java 自動計装を実行します（カバレッジが広く、相関属性を追加）。 - -3. **デュアルシグナルモードを有効化しました**：同じプロセスに 4 つの JVM フラグを追加することで実現しました。コード変更なし、追加エージェントなし、再コンパイルなし。同じ AppDynamics エージェントが AppDynamics と Splunk Observability Cloud の両方に同時にデータを送信するようになりました。 - -4. **グローバルデータリンクを作成しました**：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 -``` - -## 重要なポイント - -- **デュアルモードはコード変更ではなく、設定変更です。** すでに計装されたアプリケーションに JVM フラグを追加することで有効化しました。これにより、アプリケーションコードに触れることなく組織全体に展開することが現実的になります。 - -- **`appd.*` 相関属性が統合を価値あるものにしています。** これらがなければ（ハイブリッドモード）、Splunk O11y で OTel トレースを取得できますが、特定の AppDynamics ビジネストランザクション、tier、またはアプリケーションにリンクする方法がありません。デュアルモードはそのリンケージを提供します。 - -- **グローバルデータリンクは相関をワークフローに変えます。** 2 つのツールを手動でクロスリファレンスする代わりに、エンジニアは Splunk O11y トレースから AppDynamics ビューに直接クリックできます。 - -- **このパターンは段階的な移行をサポートします。** 組織はデュアルモードを一定期間実行して、Splunk Observability Cloud が同じシグナル品質をキャプチャすることを検証できます。その後、サービスごとにデュアルを継続するか、Splunk のみの計装に切り替えるか、AppDynamics を維持するかを決定します。 - -## 参考資料 - -- [Enable Dual Signal Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-dual-signal-mode) (AppDynamics ドキュメント) -- [Enable Hybrid Mode](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/instrument-applications-with-splunk-appdynamics-for-opentelemetry/enable-opentelemetry-in-the-java-agent/enable-hybrid-mode) (AppDynamics ドキュメント) -- [Java Agent Frameworks for OpenTelemetry](https://help.splunk.com/en/appdynamics-on-premises/virtual-appliance-self-hosted/25.7.0/splunk-appdynamics-for-opentelemetry/support-for-appdynamics-for-opentelemetry/java-agent-frameworks-for-opentelemetry) (サポートされるフレームワーク一覧) -- [Global Data Links](https://docs.splunk.com/observability/en/data-visualization/navigate-with-data-links.html) (Splunk Observability ドキュメント) diff --git a/content/ja/ninja-workshops/17-appd-ingest/_index.md b/content/ja/ninja-workshops/17-appd-ingest/_index.md deleted file mode 100644 index b72cf9a541..0000000000 --- a/content/ja/ninja-workshops/17-appd-ingest/_index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -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 のデュアルシグナルモードを使用して、APM データを AppDynamics と Splunk Observability Cloud の両方に同時に送信し、グローバルデータリンクで両者を接続する方法を紹介するハンズオンワークショップです。 ---- - -AppDynamics Java Agent のデュアルインジェストについて学び、AppDynamics と Splunk Observability Cloud の両方にデータを送信する方法を習得します diff --git a/content/ja/ninja-workshops/18-agentic-ai/1-connect-to-instance.md b/content/ja/ninja-workshops/18-agentic-ai/1-connect-to-instance.md deleted file mode 100644 index 7aa5b41f7b..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/1-connect-to-instance.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: EC2 インスタンスへの接続 -linkTitle: 1. EC2 インスタンスへの接続 -weight: 1 -time: 5 minutes ---- - -## EC2 インスタンスに接続する - -各参加者用に AWS/EC2 に Ubuntu Linux インスタンスを用意しています: - -* お住まいのリージョンのリンクをクリックして **Splunk Show** イベントにアクセスします -* 右上の **Enroll** をクリックします -* ページの下部付近で EC2 インスタンスの詳細を確認します - -以下のような接続情報が表示されます: - -![Connection Information](../images/ConnectionInformation.png) - -**Connection Information** に含まれる IP アドレス（**SSH Command** の一部）と **SSH Password** を使用して、以下のいずれかの方法で EC2 インスタンスに接続します: - -* Mac OS / Linux - * ssh splunk@IP address -* Windows 10+ - * OpenSSH クライアントを使用します -* それ以前のバージョンの Windows - * Putty を使用します - -{{% notice title="注意: 接続を続行するか聞かれたら「yes」と回答してください" style="primary" icon="running" %}} - -![SSH Connection](../images/ssh-connection.png) - -{{% / notice %}} - -{{% notice title="VPN 接続" style="green" icon="running" %}} - -オフィスから作業していて接続に問題がある場合は、まず企業 VPN に接続してみてください。 - -{{% /notice %}} - -## インスタンス名の取得 - -SSH で EC2 インスタンスにログインしたら、以下のコマンドでインスタンス名を取得します: - -```bash -echo $INSTANCE -``` - -このインスタンス名はあなた固有のもので、ワークショップの後半で Splunk Observability Cloud にてデータを検索する際に使用しますので、メモしておいてください。 - -## Visual Studio Code の接続（オプション） - -このワークショップでは複数のファイルを編集します。ワークショップの手順には `vi` エディターを使用するヒントが含まれていますが、参加者は `nano` エディターも使用できます。 - -本格的な IDE を使用したい場合は、ラップトップで実行している Visual Studio Code を接続して、EC2 インスタンス上のリモートファイルを編集できます。 - -手順の概要は以下のとおりです: - -1. [このリンク](https://code.visualstudio.com/download)を使用して、マシンに VS Code をダウンロードしてインストールします。 -2. VS Code で **Settings**、次に **Extensions** に移動します。 -3. **Remote – SSH extension**（Microsoft 製）を検索してインストールします。 - -![Install Remote SSH Extension](../images/InstallRemoteSSH.png) - -4. F1 キー（Windows では Ctrl+Shift+P / Mac OS では Cmd+Shift+P）を押します。 -5. **Remote-SSH: Connect to Host** を実行します。 -6. Splunk Show から SSH コマンドをコピーします: `ssh -p 2222 splunk@EC2_PUBLIC_IP` -7. プロンプトが表示されたら、デフォルトの SSH 設定ファイルを選択します。 -8. もう一度 F1 キー（Windows では Ctrl+Shift+P / Mac OS では Cmd+Shift+P）を押します。 -9. **Remote-SSH: Connect to Host** を実行します。 -10. 先ほど追加したホストを選択します。VS Code が新しいウィンドウを開き、接続を開始します。 -11. VS Code の上部に **SSH password** を求めるプロンプトが表示されます。Splunk Show からパスワードをコピーして入力します。 -12. **Open Folder** をクリックし、フォルダー名として `/home/splunk` を入力します: - -![Open Remote Folder](../images/OpenRemoteFolder.png) - -これで VS Code を使用してリモートファイルを編集できます！ diff --git a/content/ja/ninja-workshops/18-agentic-ai/10-add-ai-defense-instrumentation.md b/content/ja/ninja-workshops/18-agentic-ai/10-add-ai-defense-instrumentation.md deleted file mode 100644 index 58cb88b194..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/10-add-ai-defense-instrumentation.md +++ /dev/null @@ -1,178 +0,0 @@ ---- -title: AI Defense インストルメンテーションの追加 -linkTitle: 10. AI Defense インストルメンテーションの追加 -weight: 10 -time: 15 minutes ---- - -> 注: このワークショップのセクションでは、複数のファイルを変更する必要があります。 -> どこを変更すればよいかわからない場合や、アプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-ai-defense` フォルダにあるこのセクションの -> 期待される解答を参照してください。 - -Splunk Observability Cloud は -[Cisco AI Defense](https://www.cisco.com/site/us/en/products/security/ai-defense/index.html) -と統合し、AI エージェントのランタイムで検出された[セキュリティおよびプライバシーリスク](https://securitydocs.cisco.com/docs/ai-def/user/105473.dita)の -統合ビューを提供します。これにより、パフォーマンスとリスクを一箇所で監視できます。 - -これは **Splunk AI Security Monitoring** と呼ばれ、以下のことが可能になります - -* プロンプトインジェクションや PII 漏洩など、検出またはブロックされたセキュリティおよびプライバシーリスクに関与するエージェント、インタラクション、サービスを特定する -* リスクの傾向をレイテンシ、エラー、その他のパフォーマンスメトリクスとともに経時的に追跡する -* トレースコンテキスト内でリスクのあるインタラクションを、特定のプロンプトとレスポンスのレベルまで調査する - -このセクションでは、Agentic AI アプリケーションに AI Defense インテグレーションを追加し、 -Splunk Observability Cloud で結果のデータを確認します。 - -## 仕組み - -Splunk AI Security Monitoring は、Python ベースの AI エージェント向けにセキュリティおよびプライバシーリスクのトレーシングを自動化するインストルメンテーションライブラリ -[opentelemetry-instrumentation-aidefense](https://github.com/signalfx/splunk-otel-python-contrib/tree/main/instrumentation-genai/opentelemetry-instrumentation-aidefense) -を提供します。 -このライブラリは、AI エージェントが LLM（OpenAI など）やオーケストレーションフレームワーク（LangChain など）に対して行う呼び出しにセキュリティテレメトリをキャプチャして付加し、 -すべてのプロンプトとレスポンスがセキュリティガードレールに対して監査され、統合された -OpenTelemetry トレース内に記録されることを保証します。これは LLM またはワークフロースパンに -`gen_ai.security.event_id attribute` を追加することで実現されます。 - -## SDK モード vs. Gateway モード - -`opentelemetry-instrumentation-aidefense` ライブラリは SDK モードまたは Gateway モードのいずれかで動作できます - -* SDK モードでは、開発者は `inspect_prompt()` を使用して明示的なセキュリティチェックを追加します。このオプションは、セキュリティチェックの実装方法と問題への対処方法を完全に制御したい開発者に最適です。 -* Gateway モードでは、LLM 呼び出しが Cisco AI Defense Gateway を経由してプロキシされるため、アプリケーションコードの変更は不要です。このモードは OpenAI、Anthropic などの一般的な商用 LLM でサポートされています。 - -このワークショップでは、Azure OpenAI で Gateway モードを使用します。 - -## Cisco AI Defense インテグレーションのセットアップ - -最初のステップは [Cisco AI Defense とのインテグレーションをセットアップ](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-security-monitoring/set-up-an-integration-with-cisco-ai-defense)することです。 - -**Data Management -> Deployed integrations** に移動して `AI Defense` を検索すると、 -このインテグレーションがすでに構成されていることがわかります - -> 注: このインテグレーションを表示するには `aiDefenseIntegration` フィーチャーフラグを有効にする必要があります - -![AI Defense Config](../images/AIDefenseConfig.png) - -## インストルメンテーションパッケージの追加 - -次に、いくつかのインストルメンテーションパッケージをインストールする必要があります。 -`~/workshop/agentic-ai/base-app/requirements.txt` を編集用に開き、以下のパッケージを追加します - -```` -# AI Defense instrumentation (Gateway Mode support in v0.2.0+) -splunk-otel-instrumentation-aidefense>=0.2.0 -# We may need to include the AI Defense SDK even with Gateway mode -cisco-aidefense-sdk>=2.0.0 -# HTTP client (httpx is required for Gateway Mode to work) -httpx>=0.24.0 -```` - -{{% notice title="先に進む前に作業を確認してください" style="primary" icon="running" %}} - -以下のコマンドを実行して、変更内容を期待される解答と比較します - -```bash -diff ~/workshop/agentic-ai/base-app/requirements.txt ~/workshop/agentic-ai/app-with-ai-defense/requirements.txt -``` - -{{% / notice %}} - -### 更新された Docker イメージのビルド - -新しいタグで更新された Docker イメージをビルドします - -``` bash -cd ~/workshop/agentic-ai/base-app -docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-ai-defense . -docker push localhost:9999/agentic-ai-app:app-with-ai-defense -``` - -> ヒント: イメージのビルドに時間がかかりすぎる場合は、代わりにビルド済みイメージの使用を検討してください。 -> その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイル内のイメージ名を -> `localhost:9999/agentic-ai-app:app-with-ai-defense` の代わりに -> `ghcr.io/splunk/agentic-ai-app:app-with-ai-defense` に更新してください。 - -### AI Defense Gateway 用の Secret の作成 - -ワークショップインストラクターが提供するドキュメントには、AI Defense Gateway URL を -保存するための Secret を作成する `kubectl create secret` コマンドが記載されています。 - -ドキュメントからこの `kubectl create secret` コマンドをコピーして、 -ssh ターミナルで実行してください。 - -### Kubernetes マニフェストの更新 - -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを編集用に開き、 -`AZURE_OPENAI_ENDPOINT` 環境変数の定義を以下のように置き換えます。 -これにより、Azure OpenAI 宛てのリクエストが代わりに AI Defense Gateway を経由して送信されるようになります - -```yaml - - name: AZURE_OPENAI_ENDPOINT - valueFrom: - secretKeyRef: - name: ai-defense-secret - key: ai-defense-gateway-url -``` - -同じファイル内で、インストルメンテーションを含むイメージを使用するようにイメージを更新します - -```yaml - image: localhost:9999/agentic-ai-app:app-with-ai-defense -``` - -{{% notice title="先に進む前に作業を確認してください" style="primary" icon="running" %}} - -以下のコマンドを実行して、変更内容を期待される解答と比較します - -```bash -diff ~/workshop/agentic-ai/base-app/k8s.yaml ~/workshop/agentic-ai/app-with-ai-defense/k8s.yaml -``` - -{{% / notice %}} - -### 更新されたアプリケーションのデプロイ - -以下のようにマニフェストファイルを使用して、更新されたアプリケーションをデプロイできます - -``` bash -kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml -``` - -### Kubernetes でのアプリケーションのテスト - -新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -kubectl get pods -n travel-agent -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```` -NAME READY STATUS RESTARTS AGE -travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s -```` - -{{% /tab %}} -{{< /tabs >}} - -次に、以下のコマンドを実行してアプリケーションをテストします - -``` bash -curl http://travel-planner.localhost/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", - "travelers": 2 - }' -``` - -今のところ、アプリケーションがまだ動作していることを確認するだけで大丈夫です。次のセクションでは、 -セキュリティリスクを追加し、それがどのように検出されるかを示します。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/10-detect-quality-issue.md b/content/ja/ninja-workshops/18-agentic-ai/10-detect-quality-issue.md deleted file mode 100644 index a7bde109d8..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/10-detect-quality-issue.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: 品質問題の検出 -linkTitle: 10. 品質問題の検出 -weight: 10 -time: 15分 ---- diff --git a/content/ja/ninja-workshops/18-agentic-ai/11-add-ai-defense-instrumentation.md b/content/ja/ninja-workshops/18-agentic-ai/11-add-ai-defense-instrumentation.md deleted file mode 100644 index 1ab397b9e0..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/11-add-ai-defense-instrumentation.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: AI Defense 計装の追加 -linkTitle: 11. AI Defense 計装の追加 -weight: 11 -time: 20 minutes ---- - -Splunk AI Security Monitoringは、Splunk Observability for AIと [Cisco AI Defense](https://www.cisco.com/site/us/en/products/security/ai-defense/index.html) を統合します。 -AIエージェントのランタイムで検出された[セキュリティおよびプライバシーリスク](https://securitydocs.cisco.com/docs/ai-def/user/105473.dita)を一元的に表示し、パフォーマンスとリスクを一箇所で監視できます。 - -Splunk AI Security Monitoringでは、以下のことが可能です： - -* プロンプトインジェクションやPII漏洩などの検出またはブロックされたセキュリティおよびプライバシーリスクに関連するエージェント、インタラクション、サービスを特定する -* リスクの傾向をレイテンシ、エラー、その他のパフォーマンスメトリクスとともに時系列で追跡する -* トレースコンテキスト内でリスクのあるインタラクションを、特定のプロンプトとレスポンスまで掘り下げて調査する - -このセクションでは、Agentic AIアプリケーションにAI Defense統合を追加し、Splunk Observability Cloudで結果のデータを確認します。 - -## 仕組み - -Splunk AI Security Monitoringは、PythonベースのAIエージェント向けにセキュリティおよびプライバシーリスクのトレースを自動化する計装ライブラリ [opentelemetry-instrumentation-aidefense](https://github.com/signalfx/splunk-otel-python-contrib/tree/main/instrumentation-genai/opentelemetry-instrumentation-aidefense) を提供します。 -このライブラリは、AIエージェントがLLM（OpenAIなど）やオーケストレーションフレームワーク（LangChainなど）に対して行う呼び出しにセキュリティテレメトリをキャプチャしてアタッチし、すべてのプロンプトとレスポンスがセキュリティガードレールに対して監査され、統一されたOpenTelemetryトレース内に記録されることを保証します。これは、LLMまたはワークフロースパンに `gen_ai.security.event_id attribute` を追加することで実現されます。 - -## SDK モード vs. Gateway モード - -`opentelemetry-instrumentation-aidefense` ライブラリは、SDKモードまたはGatewayモードのいずれかで動作できます： - -* SDKモードでは、開発者は `inspect_prompt()` を使用して明示的なセキュリティチェックを追加します。このオプションは、セキュリティチェックの実装方法と問題への対処方法を完全に制御したい開発者に最適です。 -* Gatewayモードでは、LLM呼び出しがCisco AI Defense Gatewayを経由してプロキシされるため、アプリケーションコードの変更は不要です。このモードは、OpenAI、Anthropicなどの一般的な商用LLMでサポートされています。 - -このワークショップでは、Azure OpenAIでGatewayモードを使用します。 - -## Cisco AI Defense 統合のセットアップ - -最初のステップは、[Cisco AI Defense との統合をセットアップ](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-security-monitoring/set-up-an-integration-with-cisco-ai-defense)することです。 - -**Data Management -> Deployed integrations** に移動し、`AI Defense` を検索すると、この統合がすでに構成されていることがわかります： - -![AI Defense Config](../images/AIDefenseConfig.png) - -## 計装パッケージの追加 - -次に、いくつかの計装パッケージをインストールする必要があります。`~/workshop/agentic-ai/base-app/requirements.txt` を開いて編集し、以下のパッケージを追加します： - -```` -# AI Defense instrumentation (Gateway Mode support in v0.2.0+) -splunk-otel-instrumentation-aidefense>=0.2.0 -# We may need to include the AI Defense SDK even with Gateway mode -cisco-aidefense-sdk>=2.0.0 -# HTTP client (httpx is required for Gateway Mode to work) -httpx>=0.24.0 -```` - -### 更新された Docker イメージのビルド - -新しいタグを付けて更新されたDockerイメージをビルドします： - -``` bash -docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-ai-defense . -docker push localhost:9999/agentic-ai-app:app-with-ai-defense -``` - -### Kubernetes マニフェストの更新 - -Kubernetesマニフェストファイルを更新する前に、AI Defense Gateway URLを保存するためのシークレットを作成しましょう： - -> 注意：インストラクターがシークレット作成時に使用する実際の AI Defense URL を提供します - -```bash -kubectl create secret generic ai-defense-secret -n travel-agent --from-literal=ai-defense-gateway-url='https://us.gateway.aidefense.security.cisco.com/{tenant}/connections/{conn}' -``` - -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集し、以下の環境変数のみが含まれていることを確認します： - -> `AZURE_OPENAI_ENDPOINT` は AI Defense Gateway URL を使用するように構成されていることに注意してください。これにより、Azure OpenAI 宛てのリクエストが代わりにゲートウェイを経由して送信されます - -```yaml - - name: AZURE_OPENAI_DEPLOYMENT_NAME - value: "gpt-4.1-mini" - - name: AZURE_OPENAI_ENDPOINT - valueFrom: - secretKeyRef: - name: ai-defense-secret - key: ai-defense-gateway-url - - name: AZURE_OPENAI_API_VERSION - value: "2024-12-01-preview" - - name: AZURE_OPENAI_API_KEY - valueFrom: - secretKeyRef: - name: azure-openai-api - key: azure-openai-api-key - # OpenAI Model - - name: OPENAI_MODEL - value: "gpt-4.1-mini" - # Service Name - - name: OTEL_SERVICE_NAME - value: "travel-planner" - # Additional OTEL configuration - - name: OTEL_RESOURCE_ATTRIBUTES - valueFrom: - configMapKeyRef: - name: instance-config - key: OTEL_RESOURCE_ATTRIBUTES - - name: SPLUNK_OTEL_AGENT - valueFrom: - fieldRef: - fieldPath: status.hostIP - - name: OTEL_EXPORTER_OTLP_ENDPOINT - value: "http://$(SPLUNK_OTEL_AGENT):4317" - - name: OTEL_EXPORTER_OTLP_PROTOCOL - value: "grpc" - - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE - value: "DELTA" - - name: OTEL_PYTHON_EXCLUDED_URLS - value: "^(https?://)?[^/]+(/health)?$" - - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT - value: "true" - - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE - value: "SPAN" - - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS - value: "span_metric,splunk" - - name: SPLUNK_PROFILER_ENABLED - value: "true" -``` - -同じファイルで、計装を含むイメージを使用するようにイメージを更新します： - -```yaml - image: localhost:9999/agentic-ai-app:app-with-ai-defense -``` - -### 更新されたアプリケーションのデプロイ - -マニフェストファイルを使用して、更新されたアプリケーションを以下のようにデプロイできます： - -``` bash -kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml -``` - -### Kubernetes でのアプリケーションのテスト - -以下のコマンドを実行してアプリケーションをテストします。AI DefenseのPII検出をトリガーするために（偽の）クレジットカード番号を含めます： - -``` bash -curl http://travel-planner.localhost/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences. My credit card number is 4111 1111 1111 1111.", - "travelers": 2 - }' -``` - -## Cisco AI Defense でのイベントの表示 - -AI Defenseアプリケーションに直接ログインすると、リクエストに対してイベントがログに記録され、AI Defenseがプロンプトに含めたクレジットカード番号を自動的にマスキングしたことがわかります： - -![AI Defense Events](../images/AIDefenseEvents.png) - -AI Defenseでは、特定のタイプのセキュリティ問題を監視するかブロックするかを指定するポリシーを構成できることに注意してください。この場合、PCI関連の問題を監視するだけに設定しています。 - -## Splunk Observability Cloud でのデータの表示 - -Splunk Observability Cloudに戻り、トレースがどのように見えるか確認しましょう。 - -`APM` に移動し、`Agents` を選択します。環境名が選択されていることを確認してください（例：`agentic-ai-$INSTANCE`）。ページにセキュリティリスクが含まれるようになったことがわかります！ - -![Agents with Security Risks](../images/AgentsWithSecurityRisks.png) - -`APM -> Trace Analyzer` に移動します。 - -環境名が選択されていることを確認してください（例：`agentic-ai-$INSTANCE`）。 -新しいトレースの一つを選択します。トレースにセキュリティリスクが含まれるようになったことがわかります！ -具体的には、アプリケーションで **Privacy - PCI risk** が検出された（ただしブロックされていない）ことがわかります： - -![Trace with Security Risks](../images/TraceWithSecurityRisks.png) diff --git a/content/ja/ninja-workshops/18-agentic-ai/11-detect-security-risks.md b/content/ja/ninja-workshops/18-agentic-ai/11-detect-security-risks.md deleted file mode 100644 index 34cc09be03..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/11-detect-security-risks.md +++ /dev/null @@ -1,211 +0,0 @@ ---- -title: セキュリティリスクの検出 -linkTitle: 11. Detect Security Risks -weight: 11 -time: 15 minutes ---- - -> 注意: このセクションのワークショップでは、複数のファイルを変更する必要があります。 -> どこを変更すればよいかわからない場合、またはアプリケーションが -> 動作しなくなった場合は、このセクションのモデルソリューション -> （`~/workshop/agentic-ai/app-with-security-risk` フォルダ内）を参照してください。 - -前のセクションでは、アプリケーションエージェントの1つの出力に品質問題を -注入するラッパーを追加しました。 - -このセクションでは、同様の方法でセキュリティリスクを作成します。 - -その後、これらのリスクを Splunk Observability Cloud でどのように可視化できるかを紹介します。 - -## Activity Specialist の出力を汚染する - -Activity Specialist エージェントを変更して、このラッパーを使用し -LLM の出力を改変しましょう。 - -`~/workshop/agentic-ai/base-app/main.py` ファイルを編集用に開きます。 - -`activity_specialist_node` 関数の定義を以下のバージョンに置き換えます。 -これにより、LLM がレスポンスの一部としてユーザーのクレジットカード番号を -含めるシナリオを効果的にシミュレートします。これは明らかなセキュリティリスクであり -PCI 違反です。 - -> ヒント: `vi` エディタで大量の行を一括削除するには、`Shift` + `v` を押して `Visual -> Line` モードにし、下矢印キーで削除したい行をすべて選択してから、`d` -> を押して選択した行を削除します。 - -```python -def activity_specialist_node( - state: PlannerState -) -> PlannerState: - base_llm = _create_llm( - "activity_specialist", temperature=0.6, session_id=state["session_id"] - ) - - poisoned_llm = PoisonedChatWrapper( - inner_llm=base_llm, - poison_snippet="Note: I've charged your Visa on file with credit card number 4111 1111 1111 1111." - ) - - agent = _create_react_agent(poisoned_llm, tools=[mock_search_activities]).with_config( - { - "run_name": "activity_specialist", - "tags": ["agent", "agent:activity_specialist"], - "metadata": { - "agent_name": "activity_specialist", - "session_id": state["session_id"], - }, - } - ) - step = f"Curate signature activities for travellers spending a week in {state['destination']}." - - # IMPORTANT: pass a proper list of messages (not stringified) - messages = [ - SystemMessage(content="You are a hotel booking specialist. Provide concise options."), - HumanMessage(content=step), - ] - - result = agent.invoke({"messages": messages}) - - final_message = result["messages"][-1] - state["activities_summary"] = ( - final_message.content - if isinstance(final_message, BaseMessage) - else str(final_message) - ) - state["messages"].append( - final_message - if isinstance(final_message, BaseMessage) - else AIMessage(content=str(final_message)) - ) - state["current_agent"] = "plan_synthesizer" - return state -``` - -{{% notice title="進める前に作業内容を確認してください" style="primary" icon="running" %}} - -次のコマンドを実行して、変更内容を期待されるソリューションと比較します: - -```bash -diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-security-risk/main.py -``` - -{{% / notice %}} - -## 更新された Docker イメージのビルド - -新しいタグで更新された Docker イメージをビルドします: - -``` bash -cd ~/workshop/agentic-ai/base-app -docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-security-risk . -docker push localhost:9999/agentic-ai-app:app-with-security-risk -``` - -> ヒント: イメージのビルドに時間がかかりすぎる場合は、事前にビルドされた -> イメージの使用を検討してください。そうするには、 -> `~/workshop/agentic-ai/base-app/k8s.yaml` ファイルのイメージ名を -> `localhost:9999/agentic-ai-app:app-with-security-risk` の代わりに `ghcr.io/splunk/agentic-ai-app:app-with-security-risk` -> に更新します。 - -### Kubernetes マニフェストの更新 - -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを編集用に開き、 -セキュリティリスク付きのイメージを使用するようにイメージを更新します: - -```yaml - image: localhost:9999/agentic-ai-app:app-with-security-risk -``` - -### 更新されたアプリケーションのデプロイ - -次のようにマニフェストファイルを使用して、更新されたアプリケーションをデプロイできます: - -``` bash -kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml -``` - -### Kubernetes でのアプリケーションのテスト - -新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します: - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -kubectl get pods -n travel-agent -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```` -NAME READY STATUS RESTARTS AGE -travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s -```` - -{{% /tab %}} -{{< /tabs >}} - -次に、以下のコマンドを実行してアプリケーションをテストします: - -``` bash -curl http://travel-planner.localhost/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", - "travelers": 2 - }' -``` - -## Cisco AI Defense でのイベントの表示 - -ワークショップの参加者は AI Defense アプリケーションに直接ログインすることはできません。 -しかし、AI Defense ダッシュボードを表示できた場合、このリクエストに対して -イベントがログに記録され、プロンプトに含まれていたクレジットカード番号が -自動的にリダクションされたことがわかります。 - -![AI Defense Events](../images/AIDefenseEvents.png) - -AI Defense でポリシーを設定することで、特定の種類のセキュリティ問題を監視するか -ブロックするかを指定できることに注意してください。この場合、PCI 関連の問題を -監視のみに設定しています。 - -## Splunk Observability Cloud でのデータの表示 - -Splunk Observability Cloud に戻って、トレースがどのように表示されるか確認しましょう。 - -`APM` に移動し、`AI agents` を選択します。お使いの環境名 -（例: `agentic-ai-$INSTANCE`）が選択されていることを確認してください。ページに -セキュリティリスクが表示されるようになったことがわかります！ - -![Agents with Security Risks](../images/AgentsWithSecurityRisks.png) - -> `AI overview` ページや `plan_synthesizer` エージェントの -> `AI agent` ページでもセキュリティリスクが表示されるはずです。 - -`APM -> AI trace data` に移動し、最新のトレースを読み込みます。 - -エージェントフローで、セキュリティリスクが検出されたことが確認できます: - -![Agent Flow With Security Risk](../images/AgentFlowWithSecurityRisk.png) - -`activity_specialist` エージェントの `invoke_agent` スパンを見ると、LLM がレスポンスで -顧客のクレジットカード番号を平文で開示したため、PCI セキュリティリスクが -検出されブロックされたことがわかります: - -![Trace With Security Risk](../images/TraceWithSecurityRisk.png) - -セキュリティリスクをクリックすると、追加の詳細情報と -Cisco AI Defense でイベントを表示するためのリンクが表示されます: - -![Security Risk Details](../images/SecurityRiskDetails.png) - -このスパンの `Span details` を表示すると、`gen_ai.security.event_id` -属性がこのスパンに含まれていることが確認できます: - -![Security Event Span Attribute](../images/SecurityEventSpanAttribute.png) - -この属性により、Splunk Observability Cloud のスパンを -Cisco AI Defense の対応するイベントと関連付けることができます。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/12-detect-security-risks.md b/content/ja/ninja-workshops/18-agentic-ai/12-detect-security-risks.md deleted file mode 100644 index 445c86fc04..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/12-detect-security-risks.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: セキュリティリスクの検出 -linkTitle: 12. セキュリティリスクの検出 -weight: 12 -time: 15 minutes ---- diff --git a/content/ja/ninja-workshops/18-agentic-ai/12-explore-other-ai-frameworks.md b/content/ja/ninja-workshops/18-agentic-ai/12-explore-other-ai-frameworks.md deleted file mode 100644 index 5e7cbaf6e2..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/12-explore-other-ai-frameworks.md +++ /dev/null @@ -1,223 +0,0 @@ ---- -title: その他のエージェント AI フレームワークの探索 -linkTitle: 12. その他のエージェント AI フレームワークの探索 -weight: 12 -time: 15 minutes ---- - -このワークショップの前のセクションでは、**LangChain** と **LangGraph** を使用して構築されたエージェント AI アプリケーションを OpenTelemetry で計装することに焦点を当てました。 - -このセクションでは、範囲を広げて**その他の一般的なエージェント AI フレームワーク**を取り上げ、利用可能な計装アプローチの概要を説明します。 - -大まかに言うと、エージェント AI アプリケーションを OpenTelemetry で計装するには**2つの主要なオプション**があります。最適なアプローチは、使用するフレームワークとアプリケーションに既存の計装が含まれているかどうかによって異なります。 - -## 適切な計装アプローチの選択 - -### オプション 1: Splunk OpenTelemetry 計装（利用可能な場合に推奨） - -Splunk は、以下を含む広く使用されているエージェント AI フレームワーク向けに OpenTelemetry 計装パッケージを提供しています: - -* CrewAI -* LangChain/LangGraph -* LlamaIndex -* OpenAI SDK -* OpenAI Agents SDK - -#### このオプションを使用する場合 - -以下の場合にこのアプローチを選択します: - -* アプリケーションが上記のフレームワークのいずれかを使用している場合。 -* 最小限の設定で Splunk Observability Cloud 向けに最適化された **OpenTelemetry 計装**が必要な場合。 -* **ゼロコード**の計装体験を希望する場合。 - -#### 仕組み - -[Zero-code instrumentation integrations](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-monitoring/set-up-ai-agent-monitoring/zero-code-instrumentation#zero-code-instrumentation-integrations-0) の手順に従ってアプリケーションを計装します。 - -フレームワークによっては、以下が必要になる場合があります: - -* 追加の Splunk OpenTelemetry パッケージのインストール -* 以下のようなオプション機能を有効にするための特定の環境変数の設定: - * LLM のプロンプトと補完のキャプチャ - * LLM レスポンスのセマンティック品質の評価 - * Cisco AI Defense との統合 - -**注**: これは、ワークショップの前半で LangChain と LangGraph に使用したアプローチと同じであり、オプションのプロンプトおよび補完キャプチャも含まれています。 - -### オプション 2: サードパーティ計装ライブラリ - -フレームワークが Splunk OpenTelemetry 計装で**直接サポートされていない**場合は、より広範なフレームワークカバレッジを提供するサードパーティライブラリを使用できます。 - -一般的に使用されるサードパーティ計装ライブラリには以下があります: - -* [LangSmith](https://docs.langchain.com/langsmith/observability): -* [OpenLIT](https://docs.openlit.io/latest/sdk/overview) -* [Traceloop / OpenLLMetry](https://www.traceloop.com/docs/openllmetry/introduction) - -#### このオプションを使用する場合 - -このアプローチは以下の場合に適しています: - -* アプリケーションがオプション 1 に記載されていないエージェント AI フレームワークを使用している場合 -* アプリケーションがサードパーティ計装ライブラリで**すでに計装されている**場合 -* 既存のコードの再計装を避けたい場合 - -#### 仕組み - -サードパーティライブラリは通常、独自のフォーマットまたは以前の OpenTelemetry スキーマでテレメトリを出力します。このデータを Splunk Observability Cloud と統合するには: - -1. 出力されたテレメトリを最新の OpenTelemetry セマンティック規約に変換する**変換レイヤー**を有効にします。 -2. OpenTelemetry Collector を以下のように設定します: - -* 変換されたデータを受信する -* Splunk Observability Cloud にエクスポートする - -手順の詳細については、以下を参照してください: -[Translate and collect data from AI applications instrumented with third-party libraries](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-agent-monitoring/set-up-ai-agent-monitoring/translate-data-from-third-party-instrumentation-libraries) - -### まとめ - -| シナリオ | 推奨オプション | -|--------------------------------------|-----------------------------------------| -| サポートされているフレームワーク、最小限のセットアップ | Splunk OpenTelemetry 計装 | -| サポートされていないフレームワーク | サードパーティ計装ライブラリ | -| 既存のサードパーティ計装 | サードパーティ + OpenTelemetry 変換 | - -## CrewAI の例 - -CrewAI を使用した例を見ていきましょう。ワークショップで使用してきた旅行プランナーアプリケーションは、CrewAI を使用して書き直されています。ソースコードは `~/workshop/agentic-ai/crewai` フォルダにあります。 - -CrewAI は宣言的なアプローチを使用してエージェントとタスクを定義することに注意してください。例えば、`~/workshop/agentic-ai/crewai/config/agents.yaml` ファイルでは、以下のようなエージェントが定義されています: - -```yaml -coordinator: - role: Travel Coordinator - goal: Extract traveler intent and define a clear execution plan for specialists. - backstory: You are a lead travel coordinator managing specialist agents for flights, hotels, and activities. - verbose: true - allow_delegation: false - -flight_specialist: - role: Flight Booking Specialist - goal: Find an appealing and practical round-trip flight option. - backstory: You specialize in concise, high-signal flight recommendations. - verbose: true - allow_delegation: false -``` - -また、`~/workshop/agentic-ai/crewai/config/tasks.yaml` ファイルでは、以下のようなタスクが定義されています: - -```yaml -coordinate_trip: - description: > - Read the user request and extract key trip details: - origin, destination, travel style, and constraints. - Provide a short execution brief for specialists. - User request: {user_request} - Origin: {origin} - Destination: {destination} - Departure: {departure} - Return: {return_date} - Travellers: {travellers} - expected_output: > - A concise planning brief with extracted details and assumptions. - agent: coordinator -``` - -CrewAI アプリケーションを計装するために、以下のパッケージが `requirements.txt` ファイルに追加されていることに注目してください: - -```` -splunk-opentelemetry==2.8.0 -splunk-otel-instrumentation-crewai==0.1.3 -splunk-otel-instrumentation-openai==0.1.0 -splunk-otel-genai-emitters-splunk==0.1.7 -splunk-otel-util-genai==0.1.9 -opentelemetry-instrumentation-flask==0.59b0 -```` - -### CrewAI の例をデプロイする - -まず、新しい Docker イメージをビルドして CrewAI の例をデプロイしましょう: - -``` bash -cd ~/workshop/agentic-ai/crewai -docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:crewai . -docker push localhost:9999/agentic-ai-app:crewai -``` - -このバージョンのアプリケーションには別の環境名を使用しましょう: - -```bash -kubectl create configmap instance-config-crewai \ ---from-literal=OTEL_RESOURCE_ATTRIBUTES=deployment.environment=agentic-ai-crewai-$INSTANCE \ --n travel-agent -``` - -次に、以下のようにマニフェストファイルを使用して CrewAI アプリケーションをデプロイします: - -``` bash -kubectl apply -f ~/workshop/agentic-ai/crewai/k8s.yaml -``` - -### Kubernetes でアプリケーションをテストする - -新しいアプリケーション Pod が正常に起動し、古い Pod が存在しないことを確認します: - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -kubectl get pods -n travel-agent -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```` -NAME READY STATUS RESTARTS AGE -travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s -```` - -{{% /tab %}} -{{< /tabs >}} - -次に、以下のコマンドを実行してアプリケーションをテストします: - -``` bash -curl http://travel-planner.localhost/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", - "travelers": 2 - }' -``` - -### Splunk Observability Cloud でデータを表示する - -Splunk Observability Cloud に戻り、CrewAI アプリケーションのトレースを表示しましょう。 - -`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認してください（例: `agentic-ai-crewai-$INSTANCE`）。エージェント名が若干異なることに気づくでしょう: - -![CrewAI Agents](../images/CrewAiAgents.png) - -`APM -> AI trace data` に移動し、最新のトレースを読み込みます。 - -トレースには、LangChain/LangGraph バージョンのアプリケーションでキャプチャしたものと同様の詳細が表示されるはずです: - -![CrewAI Trace Details](../images/CrewAiTraceDetails.png) - -CrewAI のトレースと LangChain/LangGraph のトレースで異なる点に気づきましたか？ - -
- ここをクリックして回答を表示 - -いくつかの違いがあります: - -* エージェント名が異なります（`Hotel Booking Specialist` と `hotel_specialist`） -* CrewAI バージョンでは coordinator と plan synthesizer エージェントが表示されません -* `crewai` 推定サービスのスパンには、ウォーターフォールビューの一部としてエージェントの指示が含まれています - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/13-explore-other-ai-frameworks.md b/content/ja/ninja-workshops/18-agentic-ai/13-explore-other-ai-frameworks.md deleted file mode 100644 index 05162e31b9..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/13-explore-other-ai-frameworks.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: 他のエージェント AI フレームワークを探索する -linkTitle: 13. 他のエージェント AI フレームワークを探索する -weight: 13 -time: 15分 ---- diff --git a/content/ja/ninja-workshops/18-agentic-ai/13-wrapup.md b/content/ja/ninja-workshops/18-agentic-ai/13-wrapup.md deleted file mode 100644 index 161cfa05c0..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/13-wrapup.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: まとめ -linkTitle: 13. まとめ -weight: 13 -time: 5分 ---- - -おめでとうございます！**Splunk Observability Cloud を使用したエージェント型 AI アプリケーションの監視**ワークショップを完了しました！ - -本ワークショップで達成したこと - -* **Azure** アカウントを **Splunk Observability Cloud** に接続して、AI インフラストラクチャ関連のメトリクスを取得する方法の理解。 -* AI インフラストラクチャに関連する標準の**ダッシュボード**と**ナビゲーター**の探索経験。 -* **LangChain** と **LangGraph** で構築されたエージェント型 AI アプリケーションの**アーキテクチャ**の理解。 -* エージェント型 AI アプリケーションのデプロイと **OpenTelemetry** による**計装**の実践。 -* Splunk Observability Cloud で**メトリクス、トレース、ログ**を使用してエージェントのパフォーマンスを理解する方法の探索経験。 -* **ツール呼び出し**と**エージェント**を使用するようにエージェント型 AI アプリケーションを変更する実践。 -* アプリケーションに**品質問題**を追加し、**セマンティック品質評価**を使用して Splunk Observability Cloud で検出する実践。 -* アプリケーションに **AI Defense instrumentation** と**セキュリティリスク**を追加し、Splunk Observability Cloud で検出する実践。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/14-wrapup.md b/content/ja/ninja-workshops/18-agentic-ai/14-wrapup.md deleted file mode 100644 index f9528a34cd..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/14-wrapup.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: まとめ -linkTitle: 14. まとめ -weight: 14 -time: 5 minutes ---- diff --git a/content/ja/ninja-workshops/18-agentic-ai/2-review-azure-ai-metrics.md b/content/ja/ninja-workshops/18-agentic-ai/2-review-azure-ai-metrics.md deleted file mode 100644 index 0dadec4c86..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/2-review-azure-ai-metrics.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Azure OpenAI メトリクス、ダッシュボード、ナビゲーターの確認 -linkTitle: 2. Azure OpenAI メトリクス、ダッシュボード、ナビゲーターの確認 -weight: 2 -time: 10 minutes ---- - -このワークショップでは、Azure で動作する OpenAI モデルを使用します。 - -Azure OpenAI アプリケーションから Splunk Observability Cloud にメトリクスを送信するように設定することで、Azure OpenAI アプリケーションのパフォーマンスを監視できます。 - -[ドキュメント](https://help.splunk.com/en/splunk-observability-cloud/observability-for-ai/splunk-ai-infrastructure-monitoring/set-up-data-integrations/cloud-services/azure-openai)に記載されている手順に従って、ワークショップ用の Splunk Observability Cloud インスタンスと Azure アカウントの統合は既に完了しています。 - -Azure OpenAI メトリクスが含まれるようにするため、`Cognitive Services` からメトリクスを取得するように接続を設定しました - -![Azure connection](../images/AzureConnection.png) - -## Azure OpenAI メトリクス - -Azure OpenAI では、以下のメトリクスが取得されます - -* ProcessedPromptTokens -* GeneratedTokens -* AzureOpenAIRequests -* AzureOpenAITimeToResponse -* AzureOpenAIAvailabilityRate -* AzureOpenAITokenPerSecond -* AzureOpenAIContextTokensCacheMatchRate - -**Metrics** -> **Metric finder** に移動し、`ProcessedPromptTokens` メトリクスを検索して **View in chart** をクリックします - -> 注: [このリンク](https://app.us1.signalfx.com/#/chart/v2/new?template=default&filters=sf_metric:ProcessedPromptTokens)を使用して **Metric finder** でこのメトリクスを表示することもできます。 - -![Processed Prompt Tokens Metric](../images/ProcessedPromptTokensMetric.png) - -## Azure OpenAI ナビゲーター - -Splunk Observability Cloud は、OpenTelemetry の生成 AI クライアントおよびモデルサーバーのメトリクスを収集し、Azure で動作する Open AI 大規模言語モデル（LLM）サービスのトークン使用量を追跡します。 - -これらのメトリクスは Azure OpenAI ナビゲーターを使用して確認できます。**Infrastructure** -> **Overview** -> **AI Frameworks** に移動し、**Azure OpenAI** をクリックします - -![Azure OpenAI Navigator](../images/AzureOpenAINavigator.png) - -## Azure OpenAI ダッシュボード - -Splunk Observability Cloud は、Azure OpenAI 用の組み込みダッシュボードを提供しており、以下の項目を即座に可視化できます - -* アクティブな Azure OpenAI モデル -* トークン使用量 -* 呼び出しレイテンシー -* モデル別の呼び出し数 -* 最初のバイトまでの時間 -* 合計レスポンス時間 -* モデルの可用性 -* リクエストあたりのトークン数 -* モデルごとの処理済みトークン数 -* モデルごとの生成済みトークン数 - -**Dashboards** に移動し、**Azure OpenAI** を検索してダッシュボードを表示します - -![Azure OpenAI Dashboard](../images/AzureOpenAIDashboard.png) diff --git a/content/ja/ninja-workshops/18-agentic-ai/3-deploy-collector.md b/content/ja/ninja-workshops/18-agentic-ai/3-deploy-collector.md deleted file mode 100644 index 38618d119b..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/3-deploy-collector.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: OpenTelemetry Collector のデプロイ -linkTitle: 3. OpenTelemetry Collector のデプロイ -weight: 3 -time: 10 minutes ---- - -このワークショップでは、Kubernetes 上で動作する Agentic AI アプリケーションからメトリクス、トレース、ログをキャプチャするために OpenTelemetry を使用します。このセクションでは、Helm を使用して Kubernetes クラスターに OpenTelemetry Collector をインストールします。これにより、環境からメトリクス、トレース、ログをキャプチャし、Splunk に送信できるようになります。 - -## Helm を使用して Collector をインストールする - -まず、Helm リポジトリを追加する必要があります: - -``` bash -helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart -``` - -次に、リポジトリが最新であることを確認します: - -``` bash -helm repo update -``` - -Helm チャートのデプロイメントを設定するために、`/home/splunk` ディレクトリに `values.yaml` という名前の新しいファイルを作成します: - -``` bash -# swith to the /home/splunk dir -cd /home/splunk -# create a values.yaml file in vi -vi values.yaml -``` - -次に、以下の内容を貼り付けます: - -> 貼り付ける前に `:set paste` と入力してください。これにより、`vi` が貼り付けたコードを自動インデントするのを防ぐことができます。 - -``` yaml -agent: - config: - exporters: - signalfx: - send_otlp_histograms: true -``` - -> vi で変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力してから `enter/return` キーを押します。 - -このカスタム設定により、エクスポーターが受信したヒストグラムメトリクスは、SignalFx 形式に変換されることなく OTLP 形式で Splunk Observability バックエンドに送信されます。この設定は、`gen_ai.evaluation.score` などの AI Agent Monitoring で使用されるヒストグラムメトリクスが期待通りに処理されるようにするために重要です。 - -次のコマンドを使用して Collector をインストールできます: - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash - helm upgrade --install splunk-otel-collector --version {{< otel-version >}} \ - --set="splunkObservability.realm=$REALM" \ - --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ - --set="clusterName=$INSTANCE-cluster" \ - --set="environment=agentic-ai-$INSTANCE" \ - --set="splunkPlatform.token=$HEC_TOKEN" \ - --set="splunkPlatform.endpoint=$HEC_URL" \ - --set="splunkPlatform.index=splunk4rookies-workshop" \ - -f values.yaml \ - splunk-otel-collector-chart/splunk-otel-collector -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -``` bash -NAME: splunk-otel-collector -LAST DEPLOYED: Fri Dec 20 01:01:43 2024 -NAMESPACE: default -STATUS: deployed -REVISION: 1 -TEST SUITE: None -NOTES: -Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1. -``` - -{{% /tab %}} -{{< /tabs >}} - -## 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-dkn88 1/1 Running 0 53s -splunk-otel-collector-agent-ksmh4 1/1 Running 0 53s -splunk-otel-collector-agent-lc2lf 1/1 Running 0 53s -splunk-otel-collector-k8s-cluster-receiver-dbf64995b-xgm9b 1/1 Running 0 53s -``` - -{{% /tab %}} -{{< /tabs >}} - -## K8s クラスターが O11y Cloud に表示されていることを確認する - -### 新しい Kubernetes エクスペリエンスを使用する場合 - -O11y Cloud で新しい Kubernetes エクスペリエンスを使用するように設定されている場合は、このセクションの手順に従ってください。そうでない場合は、代わりに **従来の Kubernetes エクスペリエンスを使用する場合** のセクションを参照してください。 - -Splunk Observability Cloud で、**Infrastructure** -> **Kubernetes overview** に移動し、クラスター名（`-cluster`）を追加します: - -> ヒント: インスタンス名を忘れた場合は、`echo $INSTANCE` コマンドを使用してください - -![Kubernetes overview filter](../images/k8sOverviewFilter.png) - -**Apply Filters** をクリックすると、以下のようなクラスターの概要が表示されます: - -![Kubernetes overview new experience](../images/k8sOverviewNewExperience.png) - -### 従来の Kubernetes エクスペリエンスを使用する場合 - -Splunk Observability Cloud で、**Infrastructure** -> **Kubernetes** -> **Kubernetes Clusters** に移動し、クラスター名（`-cluster`）を検索します: - -> ヒント: インスタンス名を忘れた場合は、`echo $INSTANCE` コマンドを使用してください - -![Kubernetes cluster](../images/k8scluster.png) diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app.md deleted file mode 100644 index 8a5ec34305..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app.md +++ /dev/null @@ -1,332 +0,0 @@ ---- -title: Agentic AI アプリケーションアーキテクチャ -linkTitle: 4. Agentic AI アプリケーションアーキテクチャ -weight: 4 -time: 15 minutes ---- - -## アプリケーション概要 - -このワークショップでは、旅行予約用の **Agentic AI** アプリケーションを使用します。 -**OpenTelemetry** でアプリケーションを計装する前に、アプリケーションの仕組みを理解しておくと役立ちます。 - -![Application Architecture](../images/travel-planner-app-architecture.png) - -このアプリケーションは、旅行計画リクエストを受け付け、LangChain を活用した複数の LLM ノードで構成される **LangGraph** ワークフローを通じて処理する **Flask API** です。各ノードは特定の役割を持ち、共有状態を更新し、次のステップに引き継ぎます。 - -このパートでは、以下の内容を確認します: - -* リクエストのライフサイクル -* 共有状態モデル -* LangGraph ノードの動作 -* コードで使用される LangChain の抽象化 -* 後でオブザーバビリティが重要になる箇所 - -### アプリケーションの機能 - -大まかに言うと、このアプリケーションはリクエストを受け取り、マルチステップのワークフローに変換します: - -* coordinator -* flight specialist -* hotel specialist -* activity specialist -* synthesizer - -メインのフローは次のようになっています: - -```python -@app.route("/travel/plan", methods=["POST"]) -def plan(): - data = request.get_json() - - origin = data.get("origin", "Seattle") - destination = data.get("destination", "Paris") - user_request = data.get( - "user_request", - f"Planning a week-long trip from {origin} to {destination}. " - "Looking for boutique hotel, flights and unique experiences.", - ) - travellers = int(data.get("travellers", 2)) - - result = plan_travel_internal( - origin=origin, - destination=destination, - user_request=user_request, - travellers=travellers - ) - - return jsonify(result), 200 -``` - -これを分かりやすく説明すると: - -1. Flask がリクエストを受け取る -2. `plan_travel_internal()` がワークフロー状態を構築する -3. LangGraph がノードを実行する -4. 各ノードが状態を更新する -5. 最終的な旅程が JSON として返される - -### LangGraph における共有状態 - -このアプリケーションで最も重要な LangGraph の概念は、共有状態オブジェクトです: - -```python -class PlannerState(TypedDict): - messages: Annotated[List[AnyMessage], add_messages] - user_request: str - session_id: str - origin: str - destination: str - departure: str - return_date: str - travellers: int - flight_summary: Optional[str] - hotel_summary: Optional[str] - activities_summary: Optional[str] - final_itinerary: Optional[str] - current_agent: str -``` - -この状態はグラフ内をノードからノードへと移動します。 - -各ノードは: - -* 状態から値を読み取る -* 何らかの処理を行う -* 新しい値を状態に書き戻す -* current_agent を設定して次の動作を制御する - -これが LangGraph の重要なメンタルモデルです: **ステートフルなワークフローオーケストレーション**。 - -また、このフィールドも注目に値します: - -```python -messages: Annotated[List[AnyMessage], add_messages] -``` - -これは LangGraph に対して、リストを上書きするのではなく新しいメッセージを追加するよう指示します。これにより、アプリケーションはステップ間で会話履歴を保持します。 - -### 実行の開始位置 - -メインのオーケストレーションは `plan_travel_internal()` で行われます: - -```python -def plan_travel_internal( - origin: str, - destination: str, - user_request: str, - travellers: int, - ) -> Dict[str, object]: - session_id = str(uuid4()) - departure, return_date = _compute_dates() - - initial_state: PlannerState = { - "messages": [HumanMessage(content=user_request)], - "user_request": user_request, - "session_id": session_id, - "origin": origin, - "destination": destination, - "departure": departure, - "return_date": return_date, - "travellers": travellers, - "flight_summary": None, - "hotel_summary": None, - "activities_summary": None, - "final_itinerary": None, - "current_agent": "start", - } - - workflow = build_workflow() - compiled_app = workflow.compile() - - for step in compiled_app.stream(initial_state, config): - node_name, node_state = next(iter(step.items())) - final_state = node_state -``` - -この関数は以下のアプリケーションライフサイクルを実装しています: - -* 初期状態を構築する -* グラフを構築する -* コンパイルする -* ステップごとにストリーム実行する - -### グラフの定義方法 - -グラフは `build_workflow()` で明示的に構築されます: - -```python -def build_workflow() -> StateGraph: - graph = StateGraph(PlannerState) - graph.add_node("coordinator", lambda state: coordinator_node(state)) - graph.add_node("flight_specialist", lambda state: flight_specialist_node(state)) - graph.add_node("hotel_specialist", lambda state: hotel_specialist_node(state)) - graph.add_node("activity_specialist", lambda state: activity_specialist_node(state)) - graph.add_node("plan_synthesizer", lambda state: plan_synthesizer_node(state)) - graph.add_conditional_edges(START, should_continue) - graph.add_conditional_edges("coordinator", should_continue) - graph.add_conditional_edges("flight_specialist", should_continue) - graph.add_conditional_edges("hotel_specialist", should_continue) - graph.add_conditional_edges("activity_specialist", should_continue) - graph.add_conditional_edges("plan_synthesizer", should_continue) - return graph -``` - -ルーティングロジックはここにあります: - -```python -def should_continue(state: PlannerState) -> str: - mapping = { - "start": "coordinator", - "flight_specialist": "flight_specialist", - "hotel_specialist": "hotel_specialist", - "activity_specialist": "activity_specialist", - "plan_synthesizer": "plan_synthesizer", - } - return mapping.get(state["current_agent"], END) -``` - -条件付きエッジを使用していますが、ワークフローは実質的に線形です: - -* start -* coordinator -* flight specialist -* hotel specialist -* activity specialist -* synthesizer -* end - -### ノードの動作 - -このアプリケーションの LangGraph ノードは、状態を受け取り、更新された状態を返す単純な Python 関数です。 - -例えば、flight specialist の場合: - -```python -def flight_specialist_node(state: PlannerState) -> PlannerState: - llm = _create_llm( - "flight_specialist", temperature=0.4, session_id=state["session_id"] - ) - - step = ( - f"Find an appealing flight from {state['origin']} to {state['destination']} " - f"departing {state['departure']} for {state['travellers']} travellers." - ) - - messages = [ - SystemMessage(content="You are a flight booking specialist. Provide concise options."), - HumanMessage(content=step), - ] - - result = llm.invoke(messages) - state["flight_summary"] = result.content - state["messages"].append(result) - state["current_agent"] = "hotel_specialist" - return state -``` - -これは一般的なノードパターンを示しています: - -1. LLM を作成またはアクセスする -2. 構造化された状態からプロンプトを構築する -3. モデルを呼び出す -4. 結果を状態に保存する -5. 次のノードを設定する - -hotel ノードと activity ノードも同じ構造に従っており、ワークフローを説明しやすくしています。 - -### ノードで使用される LangChain の概念 - -このアプリケーションは、1つの長いプロンプト文字列ではなく、LangChain のメッセージ抽象化を使用しています。 - -``` python -from langchain_core.messages import ( - AIMessage, - BaseMessage, - HumanMessage, - SystemMessage, -) -``` - -これが重要なのは、各ノードで以下を分離できるからです: - -* システムロール -* ユーザータスク -* モデルの応答 - -例えば: - -```python -messages = [ - SystemMessage(content="You are a flight booking specialist. Provide concise options."), - HumanMessage(content=step), -] -result = llm.invoke(messages) -``` - -LLM 自体はここで作成されます: - -```python -def _create_llm(agent_name: str, *, temperature: float, session_id: str) -> AzureChatOpenAI: - azure_deployment_name = os.getenv("AZURE_OPENAI_DEPLOYMENT_NAME") - azure_openai_api_version = os.getenv("AZURE_OPENAI_API_VERSION") - - return AzureChatOpenAI( - azure_deployment=azure_deployment_name, - openai_api_version=azure_openai_api_version, - temperature=temperature, - model_name = azure_deployment_name, - # AZURE_OPENAI_API_KEY and AZURE_OPENAI_ENDPOINT environment variables will be used to connect to the LLM - ) -``` - -このアプローチにより、モデル設定とワークフローロジックが分離されます。 -各ノードは、どの程度決定的または創造的であるべきかに応じて、異なる temperature を使用できます。 - -### synthesizer は分解パターンを示す - -最後のノードは、specialist の出力を1つの回答に統合します。 - -```python -def plan_synthesizer_node(state: PlannerState) -> PlannerState: - llm = _create_llm( - "plan_synthesizer", temperature=0.3, session_id=state["session_id"] - ) - - content = json.dumps( - { - "flight": state["flight_summary"], - "hotel": state["hotel_summary"], - "activities": state["activities_summary"], - }, - indent=2, - ) - - response = llm.invoke( - [ - SystemMessage( - content="You are the travel plan synthesiser. Combine the specialist insights into a concise, structured itinerary." - ), - HumanMessage( - content=( - f"Traveller request: {state['user_request']}\n\n" - f"Origin: {state['origin']} | Destination: {state['destination']}\n" - f"Dates: {state['departure']} to {state['return_date']}\n\n" - f"Specialist summaries:\n{content}" - ) - ), - ] - ) - state["final_itinerary"] = response.content - state["messages"].append(response) - state["current_agent"] = "completed" - return state -``` - -これは agentic アプリケーションの典型的なパターンです: - -* 作業を specialist に分解する -* 中間出力を収集する -* 最終的な応答に統合する - -これが、この概要から持ち帰るべき主要なアーキテクチャのアイデアの1つです。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-1-request-lifecycle.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-1-request-lifecycle.md deleted file mode 100644 index d82b9962ca..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-1-request-lifecycle.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: 4.1 リクエストのライフサイクル -linkTitle: 4.1 リクエストのライフサイクル -weight: 1 ---- - -## アプリケーションの動作 - -大まかに言うと、このアプリケーションはリクエストを受け取り、それを複数ステップのワークフローに変換します - -* coordinator -* flight specialist -* hotel specialist -* activity specialist -* synthesizer - -メインのフローは次のようになっています - -```python -@app.route("/travel/plan", methods=["POST"]) -def plan(): - data = request.get_json() - - origin = data.get("origin", "Seattle") - destination = data.get("destination", "Paris") - user_request = data.get( - "user_request", - f"Planning a week-long trip from {origin} to {destination}. " - "Looking for boutique hotel, flights and unique experiences.", - ) - travellers = int(data.get("travellers", 2)) - - result = plan_travel_internal( - origin=origin, - destination=destination, - user_request=user_request, - travellers=travellers - ) - - return jsonify(result), 200 -``` - -この流れを分かりやすく説明すると、次のようになります - -1. Flask がリクエストを受信します -2. `plan_travel_internal()` がワークフローの状態を構築します -3. LangGraph がノードを実行します -4. 各ノードが状態を更新します -5. 最終的な旅程が JSON として返されます - -### 知識チェック - -この API フローにおいて、LangGraph のワークフローは実際にどこで実行が開始されますか？ - -
- ここをクリックして回答を表示 - -`plan_travel_internal()` の内部で開始されます。Flask のルートはリクエストの受信と -パラメータの抽出のみを行います。`plan_travel_internal()` がワークフローの状態を初期化し、 -LangGraph のグラフを呼び出します。その後、ノード（coordinator、specialist、synthesizer）が -状態を更新しながら実行され、最終的な旅程が生成されます。 - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-2-shared-state.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-2-shared-state.md deleted file mode 100644 index 5706852777..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-2-shared-state.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: 4.2 共有ステート -linkTitle: 4.2 共有ステート -weight: 2 ---- - -## LangGraph における共有ステート - -このアプリで最も重要な LangGraph のコンセプトは、共有ステートオブジェクトです - -```python -class PlannerState(TypedDict): - messages: Annotated[List[AnyMessage], add_messages] - user_request: str - session_id: str - origin: str - destination: str - departure: str - return_date: str - travellers: int - flight_summary: Optional[str] - hotel_summary: Optional[str] - activities_summary: Optional[str] - final_itinerary: Optional[str] - current_agent: str -``` - -このステートは、グラフ内のノードからノードへと移動します。 - -各ノードは以下を行います - -* ステートから値を読み取る -* 何らかの処理を実行する -* 新しい値をステートに書き戻す -* `current_agent` を設定して次の処理を制御する - -これは LangGraph の重要なメンタルモデルです**ステートフルなワークフローオーケストレーション**。 - -### 知識チェック - -`messages` フィールドに使用されている構文をどのように説明しますか？ - -```python -messages: Annotated[List[AnyMessage], add_messages] -``` - -
- ここをクリックして回答を確認 - -`messages: Annotated[List[AnyMessage], add_messages]` は2つのことを行います。 - -* `List[AnyMessage]` はフィールドの**型**を定義します：LangChain のメッセージオブジェクト（system、human、または AI メッセージ）のリストです。 -* `Annotated[..., add_messages]` は **LangGraph の動作**を追加し、**このフィールドの更新をどのように処理するか**をグラフに指示します。 - -具体的には、`add_messages` はノードが新しいメッセージを書き込んだ際に、LangGraph が**既存のリストを上書きするのではなく、追記する**ことを意味します。 -そのため、各ノードがメッセージを追加するたびに、会話履歴が増えていきます。 - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-3-orchestration.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-3-orchestration.md deleted file mode 100644 index 709db0dc14..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-3-orchestration.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: 4.3 オーケストレーション -linkTitle: 4.3 オーケストレーション -weight: 3 ---- -### 実行が始まる場所 - -メインのオーケストレーションは `plan_travel_internal()` で行われます - -```python -def plan_travel_internal( - origin: str, - destination: str, - user_request: str, - travellers: int, - ) -> Dict[str, object]: - session_id = str(uuid4()) - departure, return_date = _compute_dates() - - initial_state: PlannerState = { - "messages": [HumanMessage(content=user_request)], - "user_request": user_request, - "session_id": session_id, - "origin": origin, - "destination": destination, - "departure": departure, - "return_date": return_date, - "travellers": travellers, - "flight_summary": None, - "hotel_summary": None, - "activities_summary": None, - "final_itinerary": None, - "current_agent": "start", - } - - workflow = build_workflow() - compiled_app = workflow.compile() - - for step in compiled_app.stream(initial_state, config): - node_name, node_state = next(iter(step.items())) - final_state = node_state -``` - -この関数は以下のアプリケーションライフサイクルを実装しています - -* 初期ステートを構築する -* グラフを構築する -* コンパイルする -* ステップごとにストリーム実行する - -### 知識チェック - -#### 質問 1 - -なぜコードは単にグラフを一度呼び出して最終結果を取得するのではなく、`compiled_app.stream(initial_state, config)` を使用しているのですか？ - -
- ここをクリックして回答を確認 - -ストリーミングはワークフローを**各ノードの実行ごとにステップバイステップで**実行するためです。これにより、アプリケーションは中間ステートを観察し、どのノードが実行中かを追跡し、最終出力を待つだけでなくリアルタイムでワークフローを監視できます。 - -
- -#### 質問 2 - -なぜグラフを実行する前に `initial_state` を作成するのですか？ - -
- ここをクリックして回答を確認 - -LangGraph のワークフローは共有ステートオブジェクト上で動作するためです。`initial_state` は、ワークフローの進行に伴ってノードが読み取り、更新し、受け渡す開始データを提供します。 - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-4-graph-definition.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-4-graph-definition.md deleted file mode 100644 index d0b4ad099d..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-4-graph-definition.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: 4.4 グラフの定義 -linkTitle: 4.4 グラフの定義 -weight: 4 ---- - -## グラフの定義方法 - -グラフは `build_workflow()` で明示的に構築されます - -```python -def build_workflow() -> StateGraph: - graph = StateGraph(PlannerState) - graph.add_node("coordinator", lambda state: coordinator_node(state)) - graph.add_node("flight_specialist", lambda state: flight_specialist_node(state)) - graph.add_node("hotel_specialist", lambda state: hotel_specialist_node(state)) - graph.add_node("activity_specialist", lambda state: activity_specialist_node(state)) - graph.add_node("plan_synthesizer", lambda state: plan_synthesizer_node(state)) - graph.add_conditional_edges(START, should_continue) - graph.add_conditional_edges("coordinator", should_continue) - graph.add_conditional_edges("flight_specialist", should_continue) - graph.add_conditional_edges("hotel_specialist", should_continue) - graph.add_conditional_edges("activity_specialist", should_continue) - graph.add_conditional_edges("plan_synthesizer", should_continue) - return graph -``` - -ルーティングロジックは以下の通りです - -```python -def should_continue(state: PlannerState) -> str: - mapping = { - "start": "coordinator", - "flight_specialist": "flight_specialist", - "hotel_specialist": "hotel_specialist", - "activity_specialist": "activity_specialist", - "plan_synthesizer": "plan_synthesizer", - } - return mapping.get(state["current_agent"], END) -``` - -条件付きエッジを使用していますが、ワークフローは実質的にリニア（直線的）です - -* start -* coordinator -* flight specialist -* hotel specialist -* activity specialist -* synthesizer -* end - -### 理解度チェック - -ワークフローが実質的にリニアであるなら、なぜグラフは `add_conditional_edges` と `should_continue()` ルーターを使用しているのでしょうか？ - -
- ここをクリックして回答を表示 - -ワークフローを**柔軟で拡張可能**にするためです。現在のフローはリニアですが、ルーティング関数によりグラフはステートに基づいて次のノードを動的に決定できます。これにより、グラフを再設計することなく、分岐、リトライ、異なる実行パスを後から簡単に追加できます。 - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-5-node-definition.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-5-node-definition.md deleted file mode 100644 index 4fd763d9b8..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-5-node-definition.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: 4.5 ノードの定義 -linkTitle: 4.5 ノードの定義 -weight: 5 ---- - -## ノードの仕組み - -このアプリにおける LangGraph のノードは、state を受け取り、更新された state を返す Python 関数です。 - -例えば、flight specialist は以下のようになります: - -```python -def flight_specialist_node(state: PlannerState) -> PlannerState: - llm = _create_llm( - "flight_specialist", temperature=0.4, session_id=state["session_id"] - ) - - step = ( - f"Find an appealing flight from {state['origin']} to {state['destination']} " - f"departing {state['departure']} for {state['travellers']} travellers." - ) - - messages = [ - SystemMessage(content="You are a flight booking specialist. Provide concise options."), - HumanMessage(content=step), - ] - - result = llm.invoke(messages) - state["flight_summary"] = result.content - state["messages"].append(result) - state["current_agent"] = "hotel_specialist" - return state -``` - -これは一般的なノードパターンを示しています: - -1. LLM を作成またはアクセスする -2. 構造化された state からプロンプトを構築する -3. モデルを呼び出す -4. 結果を state に保存する -5. 次のノードを設定する - -hotel ノードと activity ノードも同じ構造に従っているため、ワークフローの説明が容易です。 - -### 知識チェック - -`flight_specialist` ノードの LLM を作成する際に、temperature を `0.4` に指定しました。これはどういう意味でしょうか？ - -
- ここをクリックして回答を確認 - -Temperature は、モデルの応答がどの程度ランダムまたは創造的になるかを制御します。 - -* **低い temperature（例: 0.0〜0.3）**: より決定論的で一貫した応答になります -* **中程度（約 0.4〜0.7）**: 正確性と創造性のバランスが取れています -* **高い（0.8 以上）**: より多様で創造的ですが、予測しにくくなります - -つまり、**temperature=0.4** に設定すると、`flight_specialist` エージェントは**おおむね一貫性があり信頼できる応答を生成しつつ、わずかなバリエーション**を持たせることができます。これは正確性が求められるが、完全に固定的な回答は不要なタスクに適しています。 - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-6-message-abstractions.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-6-message-abstractions.md deleted file mode 100644 index 7c9432f4d0..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-6-message-abstractions.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: 4.6 Message Abstractions -linkTitle: 4.6 Message Abstractions -weight: 6 ---- - -## LangChain Message Abstractions - -このアプリケーションは、1つの長いプロンプト文字列ではなく、LangChain のメッセージ抽象化を使用しています。 - -``` python -from langchain_core.messages import ( - AIMessage, - BaseMessage, - HumanMessage, - SystemMessage, -) -``` - -これは、各ノードで以下を分離できるため重要です - -* システムロール -* ユーザータスク -* モデルの応答 - -例 - -```python -messages = [ - SystemMessage(content="You are a flight booking specialist. Provide concise options."), - HumanMessage(content=step), -] -result = llm.invoke(messages) -``` - -### 理解度チェック - -system、human、AI メッセージをどのように定義しますか？ - -
- ここをクリックして回答を表示 - -LangChain と LangGraph では、メッセージは通常、誰が話しているか、および会話を導く上でどのような役割を果たしているかによって分類されます - -* **System message**: AI の動作に関するルールとコンテキストを設定します。インタラクション全体を通じてモデルがどのように応答すべきかを導く指示、制約、トーン、および目標を定義します。 -* **Human message**: ユーザーからの入力です。AI が応答すべき質問、リクエスト、または情報を含みます。 -* **AI message**: モデルの応答です。システムの指示とユーザーの入力に基づいて、アシスタントが生成した出力を表します。 - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-7-llm-creation.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-7-llm-creation.md deleted file mode 100644 index f053f56a08..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-7-llm-creation.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: 4.7 LLMの作成 -linkTitle: 4.7 LLMの作成 -weight: 7 ---- - -## LLMの作成 - -LLM自体はここで作成されます - -```python -def _create_llm(agent_name: str, *, temperature: float, session_id: str) -> AzureChatOpenAI: - azure_deployment_name = os.getenv("AZURE_OPENAI_DEPLOYMENT_NAME") - azure_openai_api_version = os.getenv("AZURE_OPENAI_API_VERSION") - - return AzureChatOpenAI( - azure_deployment=azure_deployment_name, - openai_api_version=azure_openai_api_version, - temperature=temperature, - model_name = azure_deployment_name, - # AZURE_OPENAI_API_KEY and AZURE_OPENAI_ENDPOINT environment variables will be used to connect to the LLM - ) -``` - -このアプローチでは、モデルの設定をワークフローロジックから分離しています。 -各ノードは、どの程度決定論的または創造的であるべきかに応じて、異なるtemperatureを使用できます。 - -### 理解度チェック - -OpenAI（Azure OpenAIではなく）用のLLMをどのように作成しますか？ - -
- クリックして回答を表示 - -OpenAI用のLLMの作成にはいくつかの違いがあります。関数は `AzureChatOpenAI` の代わりに `ChatOpenAI` オブジェクトを返します。 - -OpenAIを直接使用する場合、Azure固有のパラメータ（`azure_deployment`、`openai_api_version`、`Azure endpoint`）は使用しません。代わりに、モデル名を指定し、標準の `OPENAI_API_KEY` 環境変数を使用します。 - -以下は例です - -```python -def _create_llm(agent_name: str, *, temperature: float, session_id: str) -> ChatOpenAI: - model_name = os.getenv("OPENAI_MODEL_NAME", "gpt-4o-mini") - - return ChatOpenAI( - model=model_name, - temperature=temperature, - # Uses OPENAI_API_KEY automatically from environment - ) -``` - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-8-decomposition-pattern.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-8-decomposition-pattern.md deleted file mode 100644 index ef38e973f7..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/4-8-decomposition-pattern.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: 4.8 Decomposition Pattern -linkTitle: 4.8 Decomposition Pattern -weight: 8 ---- - -### シンセサイザーが分解パターンを示します - -最後のノードは、各専門エージェントの出力を1つの回答にまとめます。 - -```python -def plan_synthesizer_node(state: PlannerState) -> PlannerState: - llm = _create_llm( - "plan_synthesizer", temperature=0.3, session_id=state["session_id"] - ) - - content = json.dumps( - { - "flight": state["flight_summary"], - "hotel": state["hotel_summary"], - "activities": state["activities_summary"], - }, - indent=2, - ) - - response = llm.invoke( - [ - SystemMessage( - content="You are the travel plan synthesiser. Combine the specialist insights into a concise, structured itinerary." - ), - HumanMessage( - content=( - f"Traveller request: {state['user_request']}\n\n" - f"Origin: {state['origin']} | Destination: {state['destination']}\n" - f"Dates: {state['departure']} to {state['return_date']}\n\n" - f"Specialist summaries:\n{content}" - ) - ), - ] - ) - state["final_itinerary"] = response.content - state["messages"].append(response) - state["current_agent"] = "completed" - return state -``` - -これはエージェントアプリの典型的なパターンです - -* 作業を専門エージェントに分解する -* 中間出力を収集する -* 最終的な応答に統合する - -これは、この概要から得るべき主要なアーキテクチャのアイデアの1つです。 - -### 理解度チェック - -アプリが1つのエージェントに旅行プラン全体を生成させるのではなく、個別の `plan_synthesizer` ノードを使用するのはなぜですか？ - -
- ここをクリックして回答を表示 - -システムはまず問題を**専門的なタスク**（フライト、ホテル、アクティビティ）に分解するためです。各専門エージェントが焦点を絞った要約を生成し、`plan_synthesizer` ノードがそれらの**出力を1つのまとまった旅程に統合**します。 - -このパターンは**モジュール性、信頼性、オブザーバビリティ**を向上させます。各エージェントがより小さな問題を処理し、最後のノードが結果を統合するためです。 - -
diff --git a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/_index.md b/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/_index.md deleted file mode 100644 index 72a090a893..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/4-review-agentic-ai-app/_index.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Agentic AI アプリケーションアーキテクチャ -linkTitle: 4. Agentic AI アプリケーションアーキテクチャ -weight: 4 -time: 15 minutes ---- - -## アプリケーション概要 - -このワークショップでは、旅行予約のための **Agentic AI** アプリケーションを使用します。 -**OpenTelemetry** でアプリケーションを計装する前に、アプリケーションの仕組みを理解しておくと役立ちます。 - -![Application Architecture](../images/travel-planner-app-architecture.jpg) - -このアプリケーションは **Flask API** であり、旅行プランニングのリクエストを受け付け、複数の LangChain ベースの LLM ノードで構成された **LangGraph** ワークフローを通じて処理します。各ノードは特定の役割を果たし、共有ステートを更新して、次のステップに引き渡します。 - -ワークショップのこのパートでは、以下の内容を確認します: - -* リクエストライフサイクル -* 共有ステートモデル -* LangGraph ノードの仕組み -* コードで使用されている LangChain の抽象化 -* 後の工程でオブザーバビリティが重要になる箇所 - -アプリケーションのアーキテクチャと実装の詳細については、各サブセクションに進んでください。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/5-deploy-the-app.md b/content/ja/ninja-workshops/18-agentic-ai/5-deploy-the-app.md deleted file mode 100644 index ef92a1f246..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/5-deploy-the-app.md +++ /dev/null @@ -1,174 +0,0 @@ ---- -title: Agentic AI アプリケーションのデプロイ -linkTitle: 5. Agentic AI アプリケーションのデプロイ -weight: 5 -time: 15 minutes ---- - -## Agentic AI アプリケーションのデプロイ (Linux) - -まず、Linux EC2 インスタンス上でアプリケーションを直接実行します。 - -### 環境変数の設定 - -コマンドターミナルで、以下の環境変数を設定します。これらはアプリケーションが Azure でホストされている OpenAI モデルに接続するために使用されます: - -> 注: `AZURE_OPENAI_ENDPOINT` と `AZURE_OPENAI_API_KEY` の値はワークショップの講師から提供されます。 - -``` bash -export AZURE_OPENAI_DEPLOYMENT_NAME=gpt-4.1-mini -export AZURE_OPENAI_API_VERSION=2024-12-01-preview -export AZURE_OPENAI_ENDPOINT=your_azure_openai_endpoint -export AZURE_OPENAI_API_KEY=your_azure_openai_api_key -``` - -### 仮想環境の作成 - -次に、Python 仮想環境を作成し、アプリケーションの実行に必要なパッケージをインストールします: - -``` bash -cd ~/workshop/agentic-ai/base-app -python3 -m venv .venv -source .venv/bin/activate -pip install -r requirements.txt -``` - -### アプリケーションの実行 - -以下のコマンドでアプリケーションを実行します: - -``` bash -python3 main.py -``` - -### アプリケーションのテスト - -EC2 インスタンスに接続した2つ目のターミナルセッションを開き、以下のコマンドを実行してアプリケーションをテストします。提案された旅行プランが JSON 形式で返されます: - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -curl http://localhost:8080/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", - "travelers": 2 - }' -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```json -{"activities_summary":"Sure! Here are signature activities for a week in Tokyo:\n\n1. Day 1: Explore Asakusa and Senso-ji Temple, then stroll Nakamise Shopping Street.\n2. Day 2: Visit Tsukiji Outer Market for fresh sushi breakfast, then tour Ginza for upscale shopping.\n3. Day 3: Spend the day in Shibuya\u2014cross the famous scramble, visit Hachiko statue, and shop in trendy boutiques.\n4. Day 4: Explore Harajuku\u2019s Takeshita Street and Meiji Shrine, followed by Omotesando\u2019s stylish cafes.\n5. Day 5: Discover Akihabara\u2019s electronics and anime culture, with a visit to a themed caf\u00e9.\n6. Day 6: Take a day trip to Odaiba for teamLab Borderless digital art museum and waterfront views.\n7. Day 7: Relax in Ueno Park, visit museums, and shop at Ameya-Yokocho market.\n\nWould you like hotel or dining recommendations as well?","agent_steps":[{"agent":"coordinator","status":"completed"},{"agent":"flight_specialist","status":"completed"},{"agent":"hotel_specialist","status":"completed"} -``` - -{{% /tab %}} -{{< /tabs >}} - -## Agentic AI アプリケーションのデプロイ (Kubernetes) - -アプリケーションが正常に動作することを確認できたので、Kubernetes にデプロイしましょう。 - -### Dockerfile の作成 - -ビルド済みの Dockerfile が `~/workshop/agentic-ai/base-app/Dockerfile` にあります。`requirements.txt` ファイルのすべてのパッケージが Docker イメージのビルド時にインストールされることが確認できます: - -```` -RUN pip install --no-cache-dir -r requirements.txt -```` - -コンテナは以下のコマンドで起動されます: - -```` -CMD ["python", "main.py"] -```` - -### Docker イメージのビルド - -``` bash -cd ~/workshop/agentic-ai/base-app -docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:base-app . -docker push localhost:9999/agentic-ai-app:base-app -``` - -### Azure 認証情報を含む Secret の作成 - -Kubernetes の Secret を使用して Azure OpenAI のエンドポイントとキーを保存します: - -``` bash -kubectl create ns travel-agent - -kubectl create secret generic azure-openai-api -n travel-agent --from-literal=azure-openai-api-endpoint=$AZURE_OPENAI_ENDPOINT --from-literal=azure-openai-api-key=$AZURE_OPENAI_API_KEY -``` - -### Kubernetes マニフェストファイルを使用したアプリケーションのデプロイ - -ビルド済みの Kubernetes マニフェストが `~/workshop/agentic-ai/base-app/k8s.yaml` にあります。 - -以下のようにマニフェストファイルを使用してアプリケーションをデプロイします: - -``` bash -kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml -``` - -### アプリケーションの実行確認 - -以下のコマンドを使用して、アプリケーション Pod のステータスが `Running` であることを確認します: - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -kubectl get pods -n travel-agent -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```` -NAME READY STATUS RESTARTS AGE -travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s -```` - -{{% /tab %}} -{{< /tabs >}} - -### Kubernetes でのアプリケーションのテスト - -以下のコマンドを実行してアプリケーションをテストします: - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -curl http://travel-planner.localhost/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", - "travelers": 2 - }' -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```json -{"activities_summary":"Sure! Here are signature activities for a week in Tokyo:\n\n1. Day 1: Explore Asakusa and Senso-ji Temple, then stroll Nakamise Shopping Street.\n2. Day 2: Visit Tsukiji Outer Market for fresh sushi breakfast, then tour Ginza for upscale shopping.\n3. Day 3: Spend the day in Shibuya\u2014cross the famous scramble, visit Hachiko statue, and shop in trendy boutiques.\n4. Day 4: Explore Harajuku\u2019s Takeshita Street and Meiji Shrine, followed by Omotesando\u2019s stylish cafes.\n5. Day 5: Discover Akihabara\u2019s electronics and anime culture, with a visit to a themed caf\u00e9.\n6. Day 6: Take a day trip to Odaiba for teamLab Borderless digital art museum and waterfront views.\n7. Day 7: Relax in Ueno Park, visit museums, and shop at Ameya-Yokocho market.\n\nWould you like hotel or dining recommendations as well?","agent_steps":[{"agent":"coordinator","status":"completed"},{"agent":"flight_specialist","status":"completed"},{"agent":"hotel_specialist","status":"completed"} -``` - -{{% /tab %}} -{{< /tabs >}} - -## トラブルシューティング - -トラブルシューティングが必要な場合は、以下のコマンドを使用してアプリケーションのログを確認します: - -```bash -kubectl logs -l app=travel-planner-langchain -n travel-agent -f -``` diff --git a/content/ja/ninja-workshops/18-agentic-ai/6-instrument-the-app.md b/content/ja/ninja-workshops/18-agentic-ai/6-instrument-the-app.md deleted file mode 100644 index 211b608767..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/6-instrument-the-app.md +++ /dev/null @@ -1,242 +0,0 @@ ---- -title: エージェント型AIアプリケーションの計装 -linkTitle: 6. エージェント型AIアプリケーションの計装 -weight: 6 -time: 15 minutes ---- - -> 注意: このセクションでは複数のファイルを変更する必要があります。 -> 変更箇所が不明な場合、またはアプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-instrumentation` フォルダにある -> このセクションの想定される解答を参照してください。 - -エージェント型AIアプリケーションをOpenTelemetryで計装し、Kubernetesにデプロイするには、 -いくつかの手順が必要です: - -1. `requirements.txt` ファイルに計装パッケージを追加する -2. `opentelemetry-instrument` を使用してアプリケーションを起動するようDockerfileを更新する -3. 計装パッケージを含む新しいDockerイメージをビルドする -4. 環境変数を使用してKubernetesマニフェストを更新する -5. Kubernetesマニフェストをデプロイする - -## 計装パッケージの追加 - -次に、いくつかの計装パッケージをインストールする必要があります。`~/workshop/agentic-ai/base-app/requirements.txt` を -編集用に開き、ファイルの末尾に以下のパッケージを追加します: - -```` -splunk-opentelemetry==2.8.0 -splunk-otel-instrumentation-langchain==0.1.7 -splunk-otel-genai-emitters-splunk==0.1.7 -splunk-otel-util-genai==0.1.9 -opentelemetry-instrumentation-flask==0.59b0 -```` - -これらのパッケージの説明は以下の通りです: - -* `splunk-opentelemetry`: Splunk版のOpenTelemetry Pythonディストリビューションで、Pythonアプリケーションを計装して分散トレースをキャプチャし、Splunk APMにレポートします。 -* `splunk-otel-instrumentation-langchain`: LangChain LLM/チャットワークフロー向けのOpenTelemetry計装を提供するパッケージです。 -* `splunk-otel-genai-emitters-splunk`: Splunk Platformでのストレージとフィルタリングを最適化するために、Splunkスキーマの評価結果ログ用エミッターを提供するパッケージです。 -* `splunk-otel-util-genai`: OpenTelemetryセマンティック規約を使用した生成AIワークロードの計装を容易にするAPIとデータ型を提供するユーティリティ関数を含むパッケージです。 -* `opentelemetry-instrumentation-flask`: OpenTelemetry WSGIミドルウェアを基盤として、FlaskアプリケーションのWebリクエストを追跡するライブラリです。 - -{{% notice title="進む前に作業内容を確認してください" style="primary" icon="running" %}} - -以下のコマンドを実行して、変更内容を想定される解答と比較します: - -```bash -diff ~/workshop/agentic-ai/base-app/requirements.txt ~/workshop/agentic-ai/app-with-instrumentation/requirements.txt -``` - -{{% / notice %}} - -## Dockerfileの更新 - -次に、OpenTelemetry計装を有効にする必要があります。これはDockerfileを更新して、 -アプリケーションが `opentelemetry-instrument` で起動されるようにすることで実現します。`~/workshop/agentic-ai/base-app/Dockerfile` -ファイルを編集用に開き、最後の行を以下のように更新します: - -```dockerfile -# Run the server with instrumentation -CMD ["opentelemetry-instrument", "python", "main.py"] -``` - -{{% notice title="進む前に作業内容を確認してください" style="primary" icon="running" %}} - -以下のコマンドを実行して、変更内容を想定される解答と比較します: - -```bash -diff ~/workshop/agentic-ai/base-app/Dockerfile ~/workshop/agentic-ai/app-with-instrumentation/Dockerfile -``` - -{{% / notice %}} - -### 更新されたDockerイメージのビルド - -新しいタグを付けて更新されたDockerイメージをビルドします: - -``` bash -cd ~/workshop/agentic-ai/base-app -docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-instrumentation . -docker push localhost:9999/agentic-ai-app:app-with-instrumentation -``` - -> ヒント: イメージのビルドに時間がかかりすぎる場合は、ビルド済みのイメージを使用することを -> 検討してください。その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルのイメージ名を -> `localhost:9999/agentic-ai-app:app-with-instrumentation` の代わりに -> `ghcr.io/splunk/agentic-ai-app:app-with-instrumentation` に更新してください。 - -### ConfigMapの定義 - -アプリケーションをKubernetesにデプロイする際、テレメトリー（メトリクス、トレース、ログ）を -明確で一意な環境識別子とともにSplunk Observability Cloudに送信したいと考えています。 -これにより、異なるデプロイメント間でデータのフィルタリング、比較、トラブルシューティングが容易になります。 - -これを実現するために、`deployment.environment` という名前のOpenTelemetryリソース属性を設定します。 -値をハードコーディングする代わりに、EC2インスタンスに既に存在する `INSTANCE` 環境変数から -値を導出します。これにより、各デプロイメントが正しい環境名で自動的にタグ付けされます。 - -この設定をKubernetes ConfigMapに保存し、後でアプリケーションPodに環境変数として -注入できるようにします。 - -以下のコマンドでConfigMapを作成します: - -```bash -kubectl create configmap instance-config \ ---from-literal=OTEL_RESOURCE_ATTRIBUTES=deployment.environment=agentic-ai-$INSTANCE \ --n travel-agent -``` - -このコマンドの動作: - -* OpenTelemetryが期待する `OTEL_RESOURCE_ATTRIBUTES` 環境変数を定義します。 -* `$INSTANCE` の値に応じて、`deployment.environment` を `agentic-ai-shw-1c43` のような値に設定します。 -* `travel-agent` ネームスペースにConfigMapを作成します。 - -次のステップでKubernetesデプロイメントを構成する際に、このConfigMapを参照します。 - -### Kubernetesマニフェストの更新 - -OpenTelemetry計装、特にAI Agent Monitoringでは、計装データの収集、処理、エクスポートの -方法を定義する多数の環境変数を設定する必要があります。 - -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを編集用に開きます。計装を含むイメージを -使用するように**イメージタグ**を更新します: - -```yaml - image: localhost:9999/agentic-ai-app:app-with-instrumentation -``` - -同じファイルで、`Begin: Add Environment Variables` と `End: Add Environment Variables` の -コメントの間に以下の**環境変数**を追加します: - -> ヒント: 貼り付ける前に `:set paste` と入力すると、`vi` が貼り付けたコードを自動インデントするのを防げます。 - -```yaml - # Begin: Add Environment Variables - # Service Name - - name: OTEL_SERVICE_NAME - value: "travel-planner" - # Additional OTEL configuration - - name: OTEL_RESOURCE_ATTRIBUTES - valueFrom: - configMapKeyRef: - name: instance-config - key: OTEL_RESOURCE_ATTRIBUTES - - name: SPLUNK_OTEL_AGENT - valueFrom: - fieldRef: - fieldPath: status.hostIP - - name: OTEL_EXPORTER_OTLP_ENDPOINT - value: "http://$(SPLUNK_OTEL_AGENT):4317" - - name: OTEL_EXPORTER_OTLP_PROTOCOL - value: "grpc" - - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE - value: "DELTA" - - name: OTEL_PYTHON_EXCLUDED_URLS - value: "^(https?://)?[^/]+(/health)?$" - - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT - value: "true" - - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE - value: "SPAN" - - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS - value: "span_metric,splunk" - - name: SPLUNK_PROFILER_ENABLED - value: "true" - # End: Add Environment Variables -``` - -> 注意: スクロールしないとテキストの一部が表示されない場合があります。 -> 右上の `Copy text to clipboard` ボタンを使用して、 -> すべてのテキストをコピーしたことを確認してください。 - -> 注意: yamlではインデントが重要です。新しい環境変数が既存の環境変数と -> 揃っていることを確認してください。 - -以下の環境変数はエージェント型AIモニタリングに固有のもので、説明は以下の通りです: - -* `OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE`: OTLPメトリクスエクスポーターが、出力するメトリクスに対して累積合計、デルタ、またはメモリ効率の良いテンポラリティのどれを報告するかを決定します。エージェント型AIモニタリングでは `DELTA` に設定することが推奨されます。 -* `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT`: エージェント型AIアプリケーションからのメッセージキャプチャを有効/無効にするために使用します。このワークショップでは `true` に設定しています。 -* `OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE`: メッセージのキャプチャ方法を定義します。このワークショップでは `SPAN` に設定しており、スパンイベントストアを使用してメッセージがキャプチャされます。 -* `OTEL_INSTRUMENTATION_GENAI_EMITTERS`: このワークショップでは `span_metric,splunk` に設定しており、スパンとメトリクスの両方のデータ、およびSplunk固有の機能がキャプチャされます。 - -{{% notice title="進む前に作業内容を確認してください" style="primary" icon="running" %}} - -以下のコマンドを実行して、変更内容を想定される解答と比較します: - -```bash -diff ~/workshop/agentic-ai/base-app/k8s.yaml ~/workshop/agentic-ai/app-with-instrumentation/k8s.yaml -``` - -{{% / notice %}} - -### 更新されたアプリケーションのデプロイ - -以下のようにマニフェストファイルを使用して、更新されたアプリケーションをデプロイできます: - -``` bash -kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml -``` - -### Kubernetesでのアプリケーションテスト - -新しいアプリケーションPodが正常に起動し、古いPodが存在しないことを確認します: - -{{< tabs >}} -{{% tab title="コマンド" %}} - -``` bash -kubectl get pods -n travel-agent -``` - -{{% /tab %}} -{{% tab title="出力例" %}} - -```` -NAME READY STATUS RESTARTS AGE -travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s -```` - -{{% /tab %}} -{{< /tabs >}} - -次に、以下のコマンドを実行してアプリケーションをテストします: - -``` bash -curl http://travel-planner.localhost/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", - "travelers": 2 - }' -``` - -## トラブルシューティング - -トラブルシューティングが必要な場合は、以下のコマンドを使用してアプリケーションログを確認します: - -```bash -kubectl logs -l app=travel-planner-langchain -n travel-agent -f -``` diff --git a/content/ja/ninja-workshops/18-agentic-ai/7-review-agent-trace-data.md b/content/ja/ninja-workshops/18-agentic-ai/7-review-agent-trace-data.md deleted file mode 100644 index 55b6ec89ae..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/7-review-agent-trace-data.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: エージェントトレースデータの確認 -linkTitle: 7. エージェントトレースデータの確認 -weight: 7 -time: 10 minutes ---- - -## LLM プロバイダー設定の確認 - -Splunk Observability Cloud には、Large Language Model (LLM) を接続するためのインテグレーションが含まれています。Splunk はこの接続を使用して、アプリケーションが生成した LLM レスポンスの**セマンティック品質**を評価します。 - -このインテグレーションは、ワークショップの組織ですでに設定済みです。 - -設定を確認するには、**Data Management → Deployed Integrations** に移動し、**LLM Providers** を検索して選択します。以下のプロバイダーが表示されるはずです - -![LLM Providers](../images/LLMProviders.png) - -`Azure OpenAI O11y Specialists` プロバイダーをクリックして詳細を表示します - -![LLM Provider Details](../images/LLMProviderDetails.png) - -この組織では、サンプリングレートが **20%** に設定されています。これは、平均してアプリケーションが生成した **LLM レスポンスの 20%** に対して Splunk がセマンティック品質を評価することを意味します。 - -**1分あたり50件の評価というレート制限**も設定されています。サンプリングレートとレート制限はどちらも、お客様のニーズに応じて調整できます。サンプリングレートを高くすると、より多くの評価データが得られますが、トークン使用量と関連コストも増加します。 - -## AI Agent Monitoring 設定の確認 - -Splunk Observability Cloud には、AI Agent Monitoring に関連する詳細の保存に使用するデータソースを設定するページも含まれています。選択肢は以下の通りです - -* Data source – Splunk Observability Cloud -* Data source – Splunk logs - -これらの設定は **Settings -> AI Agent Monitoring** に移動すると確認できます - -![AI Agent Monitoring Configuration](../images/AIAgentMonitoringConfiguration.png) - -Splunk は、AI Agent Monitoring 関連の詳細の保存に Splunk Observability Cloud を使用することを推奨しています。このワークショップではこの設定を使用しています。 - -## AI Monitoring 権限の確認 - -LLM の会話データは機密性が高い可能性があるため、この情報にアクセスして表示できるユーザーを制御するための `ai_monitoring` という新しいロールが Splunk Observability Cloud に追加されています - -![AI Monitoring Role](../images/AIMonitoringRole.png) - -## Splunk Observability Cloud でのトレースデータの表示 - -Splunk Observability Cloud で `APM` に移動し、`Service Map` を選択します。環境名が選択されていることを確認します（例: `agentic-ai-$INSTANCE`）。以下のようなサービスマップが表示されるはずです - -![Service Map](../images/ServiceMap.png) - -右側のメニューで `Traces` をクリックします。次に、実行時間が長いトレースの1つを選択します。以下の例のように表示されるはずです - -![Trace](../images/Trace.png) - -**Agent flow** セクションにエージェント名（coordinator、flight-specialist など）が表示されていないことに注目してください。 - -下にスクロールして、トレース内の AI インタラクションの1つをクリックしましょう。ここでは、プロンプトとレスポンスがキャプチャされていることが確認できます。また、このトレースのセマンティック品質評価の結果も確認できます - -![Trace Details](../images/TraceDetails.png) - -次に、`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認します（例: `agentic-ai-$INSTANCE`）。ページが空であることに気付くでしょう。 - -![Agents](../images/Agents.png) - -これらのインストルメンテーションの問題は、次のセクションで対処します。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/8-add-tool-calls.md b/content/ja/ninja-workshops/18-agentic-ai/8-add-tool-calls.md deleted file mode 100644 index 3c06bc6854..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/8-add-tool-calls.md +++ /dev/null @@ -1,451 +0,0 @@ ---- -title: Add Tool Calls -linkTitle: 8. Add Tool Calls -weight: 8 -time: 15 minutes ---- - -> 注意: このセクションでは複数のファイルを変更する必要があります。 -> どこを変更すればよいか分からない場合や、アプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-agents-and-tools` フォルダにあるモデルソリューションを参照してください。 - -前のセクションでは、エージェントが新しい **Agents** ページや、トレース上部の **Agent flow** に表示されないことを確認しました。 - -その理由は、アプリケーションが現在エージェントを使用しておらず、LLM を直接呼び出しているためです。 - -つまり、現在のアプリは台本のある演劇のようなものです。すべてのセリフとアクションがコードに記述されています。LLM を呼び出す際、特定のセリフを読み上げるよう依頼しているだけです。LLM が選択を行っていないため、Observability for AI のインストルメンテーションはそれを自律的なエージェントとして認識しません。 - -次のセクションでは、LLM に**ツール**とそれらの使用方法を決定する権限を与えます。エージェントモデルに移行することで、LLM は **Tool Calls** を生成するようになります。OpenTelemetry のインストルメンテーションがこれらのインタラクションをキャプチャし、LLM の思考プロセスとツールの使用状況を確認できるようになり、各エージェントが Splunk Observability Cloud に表示されるようになります。 - -## 直接呼び出しとエージェントトレースの比較 - -これらの変更を行う前に、LLM を直接呼び出した場合とエージェント経由で呼び出した場合のトレースのキャプチャ方法の違いを詳しく見てみましょう。 - -**直接呼び出しのトレース:** - -`llm.invoke()` を呼び出すと、インストルメンテーションは標準的な "Chat" または "Completion" スパンを認識します。プロンプトとレスポンスが記録されます。エージェントフレームワークによって管理される「ループ」や「ツール呼び出し」ロジックがないため、Splunk Observability Cloud はスパンを「Agent」として分類するために必要なメタデータを検出できません。 - -**エージェントトレース:** - -エージェント（例: `create_react_agent`）を使用すると、フレームワークは実行を特定の "Agent" および "Tool" スパンでラップします。これらのスパンには OpenTelemetry に「これは単なるチャットではなく、特定のツールを持つ推論ループです」と伝えるメタデータが含まれています。これが Agents ページとトレース可視化の Agent Flow ダイアグラムを表示させるものです。 - -## バックアップの作成 - -Python コードを変更する前に、以下のコマンドで `main.py` ファイルのバックアップを作成します: - -```bash -cp ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/base-app/main.py.bak -``` - -## Import 文の追加 - -`~/workshop/agentic-ai/base-app/main.py` ファイルを編集用に開きます。 - -`Begin: Add Import Statements` と `End: Add Import Statements` の間に以下の import 文を追加します: - -```python -# Begin: Add Import Statements - -from langchain_core.tools import tool -from langchain.agents import ( - create_agent as _create_react_agent, # type: ignore[attr-defined] -) - -# End: Add Import Statements -``` - -## ツールの追加 - -同じ `main.py` ファイルで、`Begin: Tool Definitions` と `End: Tool Definitions` の間にツール定義を追加します: - -```python -# Begin: Tool Definitions - -@tool -def mock_search_flights(origin: str, destination: str, departure: str) -> str: - """Return mock flight options for a given origin/destination pair.""" - # create a local random.Random instance - seed = hash((origin, destination, departure)) % (2**32) - rng = random.Random(seed) - airline = rng.choice(["SkyLine", "AeroJet", "CloudNine"]) - fare = rng.randint(700, 1250) - - return ( - f"Top choice: {airline} non-stop service {origin}->{destination}, " - f"depart {departure} 09:15, arrive {departure} 17:05. " - f"Premium economy fare ${fare} return." - ) - - -@tool -def mock_search_hotels(destination: str, check_in: str, check_out: str) -> str: - """Return mock hotel recommendation for the stay.""" - seed = hash((destination, check_in, check_out)) % (2**32) - rng = random.Random(seed) - name = rng.choice(["Grand Meridian", "Hotel Lumière", "The Atlas"]) - rate = rng.randint(240, 410) - - return ( - f"{name} near the historic centre. Boutique suites, rooftop bar, " - f"average nightly rate ${rate} including breakfast." - ) - - -@tool -def mock_search_activities(destination: str) -> str: - """Return a short list of signature activities for the destination.""" - data = DESTINATIONS.get(destination.lower(), DESTINATIONS["paris"]) - bullets = "\n".join(f"- {item}" for item in data["highlights"]) - return f"Signature experiences in {destination.title()}:\n{bullets}" - -# End: Tool Definitions -``` - -## AI Agent Monitoring 用のアプリケーション設定 - -現在、アプリケーションは以下のように LLM を作成して呼び出しています: - -```python -def flight_specialist_node(state: PlannerState) -> PlannerState: - llm = _create_llm( - "flight_specialist", temperature=0.4, session_id=state["session_id"] - ) - ... - result = llm.invoke(messages) - ... -``` - -AI Agent Monitoring のためには、エージェント名を含むメタデータ付きのエージェントを作成し、LLM ではなくエージェントを呼び出す必要があります。 - -{{% notice title="LangChain Agents" style="green" icon="running" %}} - -次のステップでは、アプリケーションに**エージェント**を追加します。しかし、LangChain のコンテキストにおけるエージェントとは正確には何でしょうか? - -[LangChain のドキュメント](https://docs.langchain.com/oss/python/langchain/agents)によると: - -「エージェントは言語モデルとツールを組み合わせて、タスクについて推論し、使用するツールを決定し、反復的にソリューションに向けて作業するシステムを作成します。」 - -実際には、モデルはテキスト生成に限定されなくなります。代わりに、タスクを完了するために利用可能な**ツール**のセット（API、データベース、コード実行など）から選択できるようになります。 - -このスタイルのエージェントは一般的に **LangChain ReAct agent** と呼ばれます。 - -ReAct は **Reasoning + Acting**（推論＋行動）の略です。エージェントは以下のループで動作します: - -* タスクについて簡潔に推論する -* 関連するツールを選択して呼び出す -* 結果を観察する -* その新しい情報を使って次のステップを決定する - -このプロセスは、エージェントが最終的な回答を生成するのに十分な情報を収集するまで繰り返されます。 - -{{% /notice %}} - -`coordinator_node`、`flight_specialist_node`、`hotel_specialist_node`、`activity_specialist_node`、`plan_synthesizer_node` 関数の定義を以下に置き換えます: - -> ヒント: `vi` エディタで大量の行を一括削除するには、`Shift` + `v` を押して `Visual Line` モードにし、下矢印キーで削除したい行をすべて選択してから、`d` を押して選択した行を削除します。 - -```python -def coordinator_node( - state: PlannerState -) -> PlannerState: - llm = _create_llm("coordinator", temperature=0.2, session_id=state["session_id"]) - agent = _create_react_agent(llm, tools=[]).with_config( - { - "run_name": "coordinator", - "tags": ["agent", "agent:coordinator"], - "metadata": { - "agent_name": "coordinator", - "session_id": state["session_id"], - }, - } - ) - system_message = SystemMessage( - content=( - "You are the lead travel coordinator. Extract the key details from the " - "traveller's request and describe the plan for the specialist agents." - ) - ) - - result = agent.invoke({"messages": [system_message] + list(state["messages"])}) - final_message = result["messages"][-1] - state["messages"].append( - final_message - if isinstance(final_message, BaseMessage) - else AIMessage(content=str(final_message)) - ) - state["current_agent"] = "flight_specialist" - return state - - -def flight_specialist_node( - state: PlannerState -) -> PlannerState: - llm = _create_llm( - "flight_specialist", temperature=0.4, session_id=state["session_id"] - ) - agent = _create_react_agent(llm, tools=[mock_search_flights]).with_config( - { - "run_name": "flight_specialist", - "tags": ["agent", "agent:flight_specialist"], - "metadata": { - "agent_name": "flight_specialist", - "session_id": state["session_id"], - }, - } - ) - step = ( - f"Find an appealing flight from {state['origin']} to {state['destination']} " - f"departing {state['departure']} for {state['travellers']} travellers." - ) - - # IMPORTANT: pass a proper list of messages (not stringified) - messages = [ - SystemMessage(content="You are a flight booking specialist. Provide concise options."), - HumanMessage(content=step), - ] - - result = agent.invoke({"messages": messages}) - final_message = result["messages"][-1] - state["flight_summary"] = final_message.content if isinstance(final_message, BaseMessage) else str(final_message) - state["messages"].append(final_message if isinstance(final_message, BaseMessage) else AIMessage(content=str(final_message))) - state["current_agent"] = "hotel_specialist" - return state - - -def hotel_specialist_node( - state: PlannerState -) -> PlannerState: - llm = _create_llm( - "hotel_specialist", temperature=0.5, session_id=state["session_id"] - ) - agent = _create_react_agent(llm, tools=[mock_search_hotels]).with_config( - { - "run_name": "hotel_specialist", - "tags": ["agent", "agent:hotel_specialist"], - "metadata": { - "agent_name": "hotel_specialist", - "session_id": state["session_id"], - }, - } - ) - step = ( - f"Recommend a boutique hotel in {state['destination']} between {state['departure']} " - f"and {state['return_date']} for {state['travellers']} travellers." - ) - - # IMPORTANT: pass a proper list of messages (not stringified) - messages = [ - SystemMessage(content="You are a hotel booking specialist. Provide concise options."), - HumanMessage(content=step), - ] - - result = agent.invoke({"messages": messages}) - - final_message = result["messages"][-1] - state["hotel_summary"] = ( - final_message.content - if isinstance(final_message, BaseMessage) - else str(final_message) - ) - state["messages"].append( - final_message - if isinstance(final_message, BaseMessage) - else AIMessage(content=str(final_message)) - ) - state["current_agent"] = "activity_specialist" - return state - - -def activity_specialist_node( - state: PlannerState -) -> PlannerState: - llm = _create_llm( - "activity_specialist", temperature=0.6, session_id=state["session_id"] - ) - agent = _create_react_agent(llm, tools=[mock_search_activities]).with_config( - { - "run_name": "activity_specialist", - "tags": ["agent", "agent:activity_specialist"], - "metadata": { - "agent_name": "activity_specialist", - "session_id": state["session_id"], - }, - } - ) - step = f"Curate signature activities for travellers spending a week in {state['destination']}." - - # IMPORTANT: pass a proper list of messages (not stringified) - messages = [ - SystemMessage(content="You are a hotel booking specialist. Provide concise options."), - HumanMessage(content=step), - ] - - result = agent.invoke({"messages": messages}) - - final_message = result["messages"][-1] - state["activities_summary"] = ( - final_message.content - if isinstance(final_message, BaseMessage) - else str(final_message) - ) - state["messages"].append( - final_message - if isinstance(final_message, BaseMessage) - else AIMessage(content=str(final_message)) - ) - state["current_agent"] = "plan_synthesizer" - return state - -def plan_synthesizer_node(state: PlannerState) -> PlannerState: - llm = _create_llm( - "plan_synthesizer", temperature=0.3, session_id=state["session_id"] - ) - - agent = _create_react_agent(llm, tools=[]).with_config( - { - "run_name": "plan_synthesizer", - "tags": ["agent", "agent:plan_synthesizer"], - "metadata": { - "agent_name": "plan_synthesizer", - "session_id": state["session_id"], - }, - } - ) - - system_content = ( - "You are the travel plan synthesiser. Combine the specialist insights into a " - "concise, structured itinerary covering flights, accommodation and activities." - ) - - content = json.dumps( - { - "flight": state["flight_summary"], - "hotel": state["hotel_summary"], - "activities": state["activities_summary"], - }, - indent=2, - ) - - out = agent.invoke( - { - "messages": [ - SystemMessage(content=system_content), - HumanMessage( - content=( - f"Traveller request: {state['user_request']}\n\n" - f"Origin: {state['origin']} | Destination: {state['destination']}\n" - f"Dates: {state['departure']} to {state['return_date']}\n\n" - f"Specialist summaries:\n{content}" - ) - ), - ] - } - ) - # 1) Extract the assistant's final text - final_msg = next(m for m in reversed(out["messages"]) if isinstance(m, AIMessage)) - state["final_itinerary"] = final_msg.content - - # 2) Append the new messages to your ongoing conversation - state["messages"].extend(out["messages"]) # or append just final_msg - - state["current_agent"] = "completed" - return state -``` - -フライト、ホテル、アクティビティのスペシャリストエージェントを作成する際にツールを渡していることに注目してください。エージェントが呼び出されると、LLM はリクエストを満たすためにツールを呼び出すべきかどうかを判断します。 - -{{% notice title="次に進む前に作業を確認してください" style="primary" icon="running" %}} - -以下のコマンドを実行して、変更内容を期待されるソリューションと比較します: - -```bash -diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-agents-and-tools/main.py -``` - -{{% / notice %}} - -## 更新された Docker イメージのビルド - -新しいタグで更新された Docker イメージをビルドします: - -``` bash -cd ~/workshop/agentic-ai/base-app -docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-agents-and-tools . -docker push localhost:9999/agentic-ai-app:app-with-agents-and-tools -``` - -> ヒント: イメージのビルドに時間がかかりすぎる場合は、事前にビルドされたイメージの使用を検討してください。その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルのイメージ名を `localhost:9999/agentic-ai-app:app-with-agents-and-tools` の代わりに `ghcr.io/splunk/agentic-ai-app:app-with-agents-and-tools` に更新してください。 - -### Kubernetes マニフェストの更新 - -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを編集用に開き、エージェントとツールを含むイメージを使用するようにイメージを更新します: - -```yaml - image: localhost:9999/agentic-ai-app:app-with-agents-and-tools -``` - -### 更新されたアプリケーションのデプロイ - -以下のようにマニフェストファイルを使用して更新されたアプリケーションをデプロイできます: - -``` bash -kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml -``` - -### Kubernetes でのアプリケーションテスト - -新しいアプリケーション Pod が正常に起動し、古い Pod がなくなっていることを確認します: - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -kubectl get pods -n travel-agent -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```` -NAME READY STATUS RESTARTS AGE -travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s -```` - -{{% /tab %}} -{{< /tabs >}} - -次に、以下のコマンドを実行してアプリケーションをテストします: - -``` bash -curl http://travel-planner.localhost/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", - "travelers": 2 - }' -``` - -## Splunk Observability Cloud でのデータ確認 - -Splunk Observability Cloud に戻り、トレースがどのように表示されるか確認しましょう。 - -`APM` に移動し、`AI agents` を選択します。環境名が選択されていることを確認してください（例: `agentic-ai-$INSTANCE`）。ページにデータが表示されるようになりました! - -![Agents](../images/Agents-v2.png) - -`APM -> AI trace data` に移動します。これは AI 関連のコンテンツを含むトレースを検索できる新しいページです: - -![Agents](../images/AI-trace-data.png) - -環境名が選択されていることを確認してください（例: `agentic-ai-$INSTANCE`）。 -新しいトレースの1つを選択します。すべてのエージェントが Agent flow に表示されるようになりました! - -![Trace](../images/Trace-v2.png) - -Tool Calls も確認できます: - ->注意: ツール呼び出しの詳細を確認するには、画面右側の `AI details` から `Span details` に切り替えてください。 - -![Trace](../images/TraceWithToolCalls.png) diff --git a/content/ja/ninja-workshops/18-agentic-ai/9-add-quality-issue.md b/content/ja/ninja-workshops/18-agentic-ai/9-add-quality-issue.md deleted file mode 100644 index 747f203d64..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/9-add-quality-issue.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: 品質問題の追加 -linkTitle: 9. 品質問題の追加 -weight: 9 -time: 20 minutes ---- diff --git a/content/ja/ninja-workshops/18-agentic-ai/9-detect-quality-issue.md b/content/ja/ninja-workshops/18-agentic-ai/9-detect-quality-issue.md deleted file mode 100644 index 2ae76e4294..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/9-detect-quality-issue.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: 品質問題の検出 -linkTitle: 9. Detect Quality Issue -weight: 9 -time: 15 minutes ---- - -> 注意: このセクションのワークショップでは、複数のファイルを変更する必要があります。 -> 変更箇所が分からない場合や、アプリケーションが動作しなくなった場合は、 -> `~/workshop/agentic-ai/app-with-quality-issue` フォルダにあるこのセクションの -> モデルソリューションを参照してください。 - -前のセクションでは、アプリケーションに OpenTelemetry を組み込み、エージェントの応答のセマンティック品質を評価するように設定しました。 - -このセクションでは、アプリケーションにいくつかの品質問題を追加し、Splunk Observability Cloud がそのような問題をどのように検出できるかを確認します。 - -## Poisoned Chat Wrapper について - -このセクションでは、既存の `ChatModel` をラップして出力をインターセプトし「汚染」する `PoisonedChatWrapper` というカスタムクラスを使用します。このアプローチを採用したのは、OpenTelemetry インストルメンテーションでキャプチャされる前に出力をインターセプトできるようにするためです。 - -この仕組みに興味がある場合は、`poison_chat_wrapper.py` ファイルを確認してください。 - -## Hotel Specialist の出力を汚染する - -次に、hotel specialist エージェントがこのラッパーを使用して LLM の出力を変更するように修正します。まず、`~/workshop/agentic-ai/base-app/main.py` ファイルを編集し、`Begin: Add Import Statements` と `End: Add Import Statements` の間に以下のインポート文を追加します - -```python -from poison_chat_wrapper import PoisonedChatWrapper -``` - -> 注意: この新しいインポート文は、先ほど追加した他のインポート文に加えて追加するものです。 - -次に、`hotel_specialist_node` 関数の定義を以下のように置き換えます - -> ヒント: `vi` エディタで大量の行を一括削除するには、`Shift` + `v` を押して `Visual -> Line` モードにし、下矢印キーで削除したい行をすべて選択してから、`d` を押して -> 選択した行を削除します。 - -```python -def hotel_specialist_node( - state: PlannerState -) -> PlannerState: - base_llm = _create_llm( - "hotel_specialist", temperature=0.5, session_id=state["session_id"] - ) - - poisoned_llm = PoisonedChatWrapper( - inner_llm=base_llm, - poison_snippet="Note: I think this hotel is pretty terrible, best of luck if you stay there!" - ) - - agent = _create_react_agent(poisoned_llm, tools=[mock_search_hotels]).with_config( - { - "run_name": "hotel_specialist", - "tags": ["agent", "agent:hotel_specialist"], - "metadata": { - "agent_name": "hotel_specialist", - "session_id": state["session_id"], - }, - } - ) - step = ( - f"Recommend a boutique hotel in {state['destination']} between {state['departure']} " - f"and {state['return_date']} for {state['travellers']} travellers." - ) - - # IMPORTANT: pass a proper list of messages (not stringified) - messages = [ - SystemMessage(content="You are a hotel booking specialist. Provide concise options."), - HumanMessage(content=step), - ] - - result = agent.invoke({"messages": messages}) - - final_message = result["messages"][-1] - state["hotel_summary"] = ( - final_message.content - if isinstance(final_message, BaseMessage) - else str(final_message) - ) - state["messages"].append( - final_message - if isinstance(final_message, BaseMessage) - else AIMessage(content=str(final_message)) - ) - state["current_agent"] = "activity_specialist" - return state -``` - -{{% notice title="進む前に作業内容を確認してください" style="primary" icon="running" %}} - -以下のコマンドを実行して、変更内容を期待されるソリューションと比較します - -```bash -diff ~/workshop/agentic-ai/base-app/main.py ~/workshop/agentic-ai/app-with-quality-issue/main.py -``` - -{{% / notice %}} - -## 更新された Docker イメージのビルド - -新しいタグで更新された Docker イメージをビルドします - -``` bash -cd ~/workshop/agentic-ai/base-app -docker build --platform linux/amd64 -t localhost:9999/agentic-ai-app:app-with-quality-issue . -docker push localhost:9999/agentic-ai-app:app-with-quality-issue -``` - -> ヒント: イメージのビルドに時間がかかりすぎる場合は、代わりにビルド済みのイメージを使用することを検討してください。 -> その場合は、`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルのイメージ名を -> `localhost:9999/agentic-ai-app:app-with-quality-issue` の代わりに -> `ghcr.io/splunk/agentic-ai-app:app-with-quality-issue` に更新してください。 - -### Kubernetes マニフェストの更新 - -`~/workshop/agentic-ai/base-app/k8s.yaml` ファイルを開いて編集し、品質問題のあるイメージを使用するようにイメージを更新します - -```yaml - image: localhost:9999/agentic-ai-app:app-with-quality-issue -``` - -### 更新されたアプリケーションのデプロイ - -以下のようにマニフェストファイルを使用して、更新されたアプリケーションをデプロイします - -``` bash -kubectl apply -f ~/workshop/agentic-ai/base-app/k8s.yaml -``` - -### Kubernetes でのアプリケーションのテスト - -新しいアプリケーション Pod が正常に起動し、古い Pod が存在しないことを確認します - -{{< tabs >}} -{{% tab title="Script" %}} - -``` bash -kubectl get pods -n travel-agent -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```` -NAME READY STATUS RESTARTS AGE -travel-planner-langchain-68977dc5c4-4w7p9 1/1 Running 0 41s -```` - -{{% /tab %}} -{{< /tabs >}} - -次に、以下のコマンドを実行してアプリケーションをテストします - -``` bash -curl http://travel-planner.localhost/travel/plan \ - -H "Content-Type: application/json" \ - -d '{ - "origin": "Seattle", - "destination": "Tokyo", - "user_request": "We are planning a week-long trip to Seattle from Tokyo. Looking for boutique hotel, business-class flights and unique experiences.", - "travelers": 2 - }' -``` - -## Splunk Observability Cloud でのデータ確認 - -Splunk Observability Cloud に戻り、トレースがどのように表示されるか確認しましょう。 - -`hotel_specialist` エージェントの `invoke_agent` スパンを見ると、エージェントがホテルを推薦した後にそれを `pretty terrible` と呼んでいるため、いくつかの品質問題があることがわかります - -![Trace With Quality Issue](../images/TraceWithQualityIssue.png) - -> 注意: すべてのエージェント呼び出しが評価されるわけではありません。ワークショップの組織では -> 20% の確率でのみ評価するように設定されています。これは組織レベルで設定可能です。 -> `hotel_specialist` エージェントの `invoke_agent` スパンに評価が表示されない場合は、 -> 別のリクエストを送信してみてください。 diff --git a/content/ja/ninja-workshops/18-agentic-ai/_index.md b/content/ja/ninja-workshops/18-agentic-ai/_index.md deleted file mode 100644 index 8bb4a35c07..0000000000 --- a/content/ja/ninja-workshops/18-agentic-ai/_index.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: Splunk Observability Cloud によるエージェント型 AI アプリケーションの監視 -linkTitle: Splunk Observability Cloud によるエージェント型 AI アプリケーションの監視 -weight: 18 -archetype: chapter -time: 2 minutes -authors: ["Derek Mitchell"] -description: このハンズオンワークショップでは、Splunk Observability Cloud を使用してエージェント型 AI アプリケーションを監視する方法を紹介します。OpenTelemetry Collector のデプロイ、LangChain を使用した Python アプリケーションの計装、品質の問題やセキュリティリスクを特定するための LLM インタラクションの評価設定について学びます。 -draft: false -hidden: false ---- - -**Splunk Observability for AI** は、AI アプリケーションスタックのパフォーマンス、品質、セキュリティ、 -コストを監視します。以下の機能が含まれます - -* **AI Agent Monitoring** - LLM およびエージェント型アプリケーションのパフォーマンス、品質、セキュリティ、コストを監視します。 -* **AI Infrastructure Monitoring** - AI インフラストラクチャの健全性、可用性、消費量（使用量）を監視します。 - -このワークショップでは、Splunk Observability Cloud でこれらの機能をデプロイし、活用するためのハンズオン体験を提供します。以下の内容が含まれます - -* **Azure** アカウントを **Splunk Observability Cloud** に接続して、AI インフラストラクチャ関連のメトリクスを取得する方法を理解します。 -* AI インフラストラクチャに関連するすぐに使える**ダッシュボード**と**ナビゲーター**を探索します。 -* **LangChain** と **LangGraph** で構築されたエージェント型 AI アプリケーションの**アーキテクチャ**を確認します。 -* エージェント型 AI アプリケーションをデプロイし、**OpenTelemetry** で**計装**する練習をします。 -* Splunk Observability Cloud で**メトリクス、トレース、ログ**を使用してエージェントのパフォーマンスを理解する方法を探索します。 -* エージェント型 AI アプリケーションを変更して**ツールコール**と**エージェント**を使用する練習をします。 -* アプリケーションに**品質の問題**を追加し、**セマンティック品質評価**を使用して Splunk Observability Cloud で検出する練習をします。 -* アプリケーションに **AI Defense の計装**と**セキュリティリスク**を追加し、Splunk Observability Cloud で検出する練習をします。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下のとおりです - -* このページの右上にある左右の矢印（**<** | **>**）を使用する -* キーボードの左（◀️）と右（▶️）カーソルキーを使用する - {{% /notice %}} diff --git a/content/ja/ninja-workshops/19-agent-primer/1-types-of-telemetry.md b/content/ja/ninja-workshops/19-agent-primer/1-types-of-telemetry.md new file mode 100644 index 0000000000..54ea49a835 --- /dev/null +++ b/content/ja/ninja-workshops/19-agent-primer/1-types-of-telemetry.md @@ -0,0 +1,73 @@ +--- +title: テレメトリの種類 +linkTitle: 1. テレメトリの種類 +weight: 1 +time: 5 minutes +--- + +## サポートされるテレメトリ + +OTelは公式に4種類のテレメトリ（シグナル）をサポートしています。 + +ここでは [OTelドキュメント](https://opentelemetry.io/docs/concepts/signals/)で提供されている定義を使用します。 + +### Metrics + +> メトリクスは、実行時にキャプチャされたサービスの測定値です。測定値がキャプチャされる瞬間はメトリクスイベントと呼ばれ、測定値そのものだけでなく、キャプチャされた時刻と関連するメタデータで構成されます。 + +> アプリケーションとリクエストのメトリクスは、可用性とパフォーマンスの重要な指標です。カスタムメトリクスは、可用性の指標がユーザーエクスペリエンスやビジネスにどのように影響するかについてのインサイトを提供できます。収集されたデータは、障害のアラートや、高需要時にデプロイメントを自動的にスケールアップするスケジューリング決定のトリガーに使用できます。 + +メトリクスの良い例は以下の通りです。 + +- システム + - CPU使用率 + - メモリ使用率 + - ディスク使用量 +- アプリケーションパフォーマンス + - レスポンスタイム + - エラー数 +- ビジネス + - 総売上 + - 顧客数 + +### Traces + +> Traceは、アプリケーションにリクエストが行われたときに何が起こるかの全体像を示します。アプリケーションが単一のデータベースを持つモノリスであっても、洗練されたサービスメッシュであっても、Traceはアプリケーション内でリクエストがたどる完全な「パス」を理解するために不可欠です。 + +Traceは複数のSpanで構成されます。通常、特定のサービスやメソッドで時間がどこで費やされているかを簡単に確認できるよう、ウォーターフォール形式で表示されます。 + +### Logs + +> ログは、タイムスタンプ付きのテキストレコードで、構造化（推奨）または非構造化のいずれかであり、オプションのメタデータを含みます。すべてのテレメトリシグナルの中で、ログは最も長い歴史を持っています。ほとんどのプログラミング言語には、組み込みのロギング機能や、よく知られた広く使用されているロギングライブラリがあります。 + +構造化ログには多くの利点があり、多くの点でSpanは非常に構造化されたログとして機能します。アプリケーションログとホストログには、他のシグナルと簡単に関連付けることができるメタデータが含まれます。 + +一方で、ログは非構造化にすることもできます。Splunkは、あらゆる種類のデータを収集できるソリューションとして広く認知されています。 + +### Baggage + +> OpenTelemetryにおいて、Baggageはコンテキストの隣に存在するコンテキスト情報です。Baggageはキー・バリューストアであり、コンテキストと一緒に任意のデータを伝播できることを意味します。 + +> Baggageにより、サービスやプロセス間でデータを渡すことができ、それらのサービスのTrace、Metric、またはLogに追加できるようになります。 + +多くの場合、計装がこれを処理してくれるため、Baggageについて意識する必要はありません。しかし、標準機能では対処できない課題に直接対応する必要がある場合もあるため、このテレメトリタイプを理解することは重要です。 + +## その他のテレメトリ + +その他のシグナルはOpenTelemetryではまだ提案段階にあります。ただし、これらはどちらもSplunk Observabilityで現在使用されており、サポートされています。 + +### Events + +> EventsはOpenTelemetryのLogRecordsの標準化されたフォーマットです。ログに定義されたすべてのセマンティック規約はEventsとしてフォーマットされるべきです。Eventフォーマットの要件と詳細はセマンティック規約に記載されています。 + +> EventsはOpenTelemetryの計装で使用されることを意図しています。すべてのLogRecordsがEventsとしてフォーマットされる必要はありません。 + +Splunk Observability CloudはAPI経由でイベントを受信でき、これらはチャート上にデータを表示する際に特に有用です。 + +### Profiles + +> プロファイルは、実行中にアプリケーションがどこでリソースを消費しているかを示すサンプルと関連メタデータのコレクションです。サンプルは、あるプログラムコンテキスト（通常はスタックトレース）で検出された値を記録し、オプションで上位レベルのリクエストに対応するTrace IDなどの補助情報で拡張されます。 + +> サンプルがキャプチャされる瞬間はサンプルイベントと呼ばれ、観測データポイントだけでなく、キャプチャされた時刻も含まれます。 + +ProfilesはSplunk Observability Cloudで、サービス内で時間がどこで費やされているかをより深く理解するために使用されます。特に、典型的なマイクロサービスよりもはるかに多くのコード行を持つ大規模なサービスで有用です。 diff --git a/content/ja/ninja-workshops/19-agent-primer/2-what-is-an-agent.md b/content/ja/ninja-workshops/19-agent-primer/2-what-is-an-agent.md new file mode 100644 index 0000000000..ca506314b5 --- /dev/null +++ b/content/ja/ninja-workshops/19-agent-primer/2-what-is-an-agent.md @@ -0,0 +1,50 @@ +--- +title: エージェントとは +linkTitle: 2. エージェントとは +weight: 2 +time: 5 minutes +--- + +## エージェントの用語 + +さまざまなタイプのエージェントについて説明する前に、混乱を避けるために使用する用語を確認しておきましょう。 + +## OpenTelemetry + +OpenTelemetryには、システムからデータを収集するために使用されるさまざまなコンポーネントがあります。 + +### Collector + +OpenTelemetryではCollectorを次のように定義しています: +> The OpenTelemetry Collector offers a vendor-agnostic implementation of how to receive, process and export telemetry data. It removes the need to run, operate, and maintain multiple agents/collectors. This works with improved scalability and supports open source observability data formats (e.g. Jaeger, Prometheus, Fluent Bit, etc.) sending to one or more open source or commercial backends. + +- 出典: [Open Telemetry Docs](https://opentelemetry.io/docs/collector/) + +**Collectorはそれ自体がエージェントなのでしょうか？** ある意味ではそうです。データを収集するための **Receiver** を持ち、それを処理するための **Processor** を持ち、そしてデータを1つ以上の宛先（ルーティング用のゲートウェイやオブザーバビリティバックエンドなど）に送信するための **Exporter** を持っています。 + +#### Receivers + +**Receiver** は、その名前に反して、データのプッシュとプルの両方で動作できます。例えば、ホストのCPU、メモリ、ディスク情報をスクレイピングして収集できます。また、他のシステムが情報をプッシュできるエンドポイントを提供することもできます。 + +#### Processors + +**Processor** はデータを処理します。例えば、Processorは以下のことができます: +- [redact](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor) +- [filter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor) +- [sample (tail)](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor) +- [sample (probabilistic)](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/probabilisticsamplerprocessor) +- [transform](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/metricstransformprocessor) + +よく使用されるコアProcessorとして、[memory limit processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/memorylimiterprocessor)（メモリ不足の状況を緩和するのに役立ちます）や[batch processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/batchprocessor)（テレメトリデータを圧縮し、より少ない接続でバッチ送信します）があります。 + +#### Exporters + +データをどこかに送信する必要があり、それを行うのが **Exporter** です。Splunk Platformへのログは通常、[hec exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/splunkhecexporter)を使用します。その他のテレメトリは、宛先に応じて異なるExporterを使用します。 + +#### パイプライン + +これらのReceiver、Processor、Exporterはすべて[パイプライン](https://opentelemetry.io/docs/collector/configuration/#basics)で統合されます。 + +### 計装エージェント + +Collectorはデータ収集のための優れた基盤を提供しますが、アプリケーション側からデータを収集するにはどうすればよいでしょうか？ そこで計装エージェントが登場します。 diff --git a/content/ja/ninja-workshops/19-agent-primer/_index.md b/content/ja/ninja-workshops/19-agent-primer/_index.md new file mode 100644 index 0000000000..534ef96ffa --- /dev/null +++ b/content/ja/ninja-workshops/19-agent-primer/_index.md @@ -0,0 +1,34 @@ +--- +title: Splunk Observability Agent Primer +linkTitle: Splunk Observability Agent Primer +weight: 19 +archetype: chapter +time: 2 minutes +authors: ["Bill Grant", "Others TBD"] +description: このワークショップでは、Splunkで使用されるさまざまなエージェントを理解するための背景を提供します。その後、OpenTelemetryについてより深く掘り下げます。このワークショップは、特定の課題に取り組む他のNinjaワークショップに参加する前の入門として活用できます。 +draft: false +hidden: true +--- + +**Splunk** には、**Observability** のためにデータを収集するさまざまな方法を表す複数のエージェントがあります。 + +ある意味では、オブザーバビリティバックエンドは中立的です。期待される形式でデータが提供される限り、バックエンドはどのエージェントがデータを送信したかを技術的には気にしません。 + +どのエージェントを使用するかは重要な決定であり、オブザーバビリティの実装を開始する際に行われることが多いです。 + +SplunkはOpenTelemetryへの最大の貢献者であり、OpenTelemetryはデータ収集の民主化を目指しています。より多くのベンダーや顧客がこの領域で標準化すると、ソフトウェアの共同開発の恩恵を受けることで、オブザーバビリティのユーザーにとってメリットがあります。また、ビジネスへの影響を最小限に抑えながらベンダーを切り替えられることも意味します。 + +**OpenTelemetry** は、オブザーバビリティのユースケースに対して **Splunk** が最も一般的に推奨するテクノロジーです。しかし、それだけでしょうか？また、どの **OpenTelemetry** エージェント（または複数のエージェント）を使うべきでしょうか？この入門ガイドはそれを理解する助けとなります。 + +この内容は2026年4月時点で正確ですが、この分野は変化し続けるため、**Splunk** からの最新の推奨事項を確認することが重要です。 + +このワークショップでは、これらのさまざまなエージェントと、それぞれをいつ使用するかについて解説します。 + +最初の数ページでは、シグナルとOpenTelemetryの入門を提供します。これらの概念に既に精通している場合は、これらのセッションを読み飛ばしても構いません。 + +{{% notice title="Tip" style="primary" icon="lightbulb" %}} +このワークショップ内を移動する最も簡単な方法は以下の通りです。 + +* このページの右上にある左右の矢印（**<** | **>**）を使用する +* キーボードの左（◀️）と右（▶️）カーソルキーを使用する + {{% /notice %}} diff --git a/content/ja/ninja-workshops/2-hpa/2-k8s-namespaces-dns.md b/content/ja/ninja-workshops/2-hpa/2-k8s-namespaces-dns.md deleted file mode 100644 index 4b4e739a70..0000000000 --- a/content/ja/ninja-workshops/2-hpa/2-k8s-namespaces-dns.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: K8s Namespaces と DNS -linkTitle: 2. K8s Namespaces と DNS -weight: 2 ---- - -## 1. Kubernetes における Namespaces - -多くのお客様は、Kubernetesを実行するために何らかのプライベートまたはパブリッククラウドサービスを利用しています。一元管理が容易であるため、少数の大規模なKubernetesクラスターのみを持つことを選択することが多いです。 - -Namespacesは、これらの大規模なKubernetesクラスターを仮想的なサブクラスターに整理する方法です。異なるチームやプロジェクトがKubernetesクラスターを共有する場合に役立ちます。これにより、自分のリソースだけを簡単に表示して作業できるようになります。 - -クラスター内では任意の数のNamespacesがサポートされており、それぞれが論理的に分離されていますが、相互に通信する機能を持っています。コンポーネントは、Namespaceを選択した場合、または `kubectl` に `--all-namespaces` フラグを追加した場合にのみ**表示**されます。Namespaceを選択することで、プロジェクトに関連するコンポーネントのみを表示できます。 - -ほとんどのお客様は、アプリケーションを別のNamespaceにインストールすることを望んでいます。このワークショップでは、そのベストプラクティスに従います。 - -## 2. Kubernetes における DNS とサービス - -Domain Name System（DNS）は、IPアドレスなどのさまざまな情報を覚えやすい名前にリンクするメカニズムです。DNSシステムを使用してリクエスト名をIPアドレスに変換することで、エンドユーザーは目的のドメイン名に簡単にアクセスできます。 - -ほとんどのKubernetesクラスターには、サービスディスカバリのための軽量なアプローチを提供するデフォルトで設定された内部DNSサービスが含まれています。Podやサービスが作成、削除、またはノード間で移動された場合でも、組み込みのサービスディスカバリにより、アプリケーションはKubernetesクラスター上のサービスを識別して通信することが簡素化されます。 - -簡単に言えば、KubernetesのDNSシステムは、各Podとサービスに対して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 -``` - -サービスによって公開される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/2-hpa/5-fix-apache.md b/content/ja/ninja-workshops/2-hpa/5-fix-apache.md deleted file mode 100644 index 7f63a900d7..0000000000 --- a/content/ja/ninja-workshops/2-hpa/5-fix-apache.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -title: PHP/Apache の問題の修正 -linkTitle: 5. PHP/Apache の問題の修正 -weight: 5 ---- -## 1. Kubernetes リソース - -特に本番環境のKubernetesクラスターでは、CPUとメモリは貴重なリソースと見なされています。クラスター運用者は通常、デプロイメントでPodまたはサービスが必要とするCPUとメモリの量を指定するよう求めます。これにより、クラスターがソリューションを配置するノードを自動的に管理できます。 - -これは、アプリケーション/Podのデプロイメントにリソースセクションを配置することで行います。 - -**例:** - -``` 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つのシナリオは、ノードに十分なメモリまたはCPUがない場合です。その場合、クラスターはより多くのスペースがある別のノードにPodを再スケジュールしようとします。 - -それが失敗した場合、またはアプリケーションをデプロイするときに十分なスペースがない場合、クラスターはワークロード/デプロイメントをスケジュールモードにして、利用可能なノードのいずれかに制限に従ってPodをデプロイするのに十分なスペースができるまで待機します。 - -## 2. PHP/Apache デプロイメントの修正 - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} - -開始する前に、PHP/Apacheデプロイメントの現在の状態を確認しましょう。**Alerts & Detectors** で、どのディテクターが発火しましたか？この情報は他にどこで見つけることができますか？ - -{{% /notice %}} - -PHP/Apache StatefulSetを修正するには、以下のコマンドを使用して `~/workshop/k3s/php-apache.yaml` を編集し、CPUリソースを削減します: - -``` bash -vim ~/workshop/k3s/php-apache.yaml -``` - -リソースセクションを見つけて、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 -``` - -PodがSplunk Observability Cloudで実行中であることを確認します。 - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -**Apache Web Servers** ダッシュボードにデータが表示されていますか？ - -**ヒント:** フィルターと時間枠を使用してデータを絞り込むことを忘れないでください。 -{{% /notice %}} - -数分間、Apache web servers Navigatorダッシュボードを監視してください。 - -{{% notice title="ワークショップの質問" 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="ヒント" 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/2-hpa/6-deploy-loadgen.md b/content/ja/ninja-workshops/2-hpa/6-deploy-loadgen.md deleted file mode 100644 index d89f512759..0000000000 --- a/content/ja/ninja-workshops/2-hpa/6-deploy-loadgen.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -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 -``` - -![ReplicaSet](../images/k8s-workload-replicaset.png) - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -Apache Navigatorでどのような影響が見られますか？ -{{% /notice %}} - -ロードジェネレーターを約2〜3分間実行し、Kubernetes NavigatorとApache Navigatorでメトリクスを観察し続けてください。 diff --git a/content/ja/ninja-workshops/2-hpa/_index.md b/content/ja/ninja-workshops/2-hpa/_index.md deleted file mode 100644 index 434ce032ed..0000000000 --- a/content/ja/ninja-workshops/2-hpa/_index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Kubernetes における Horizontal Pod Autoscaling の監視 -linkTitle: Horizontal Pod Autoscaling -description: Splunk OpenTelemetry Collector を使用して Kubernetes Horizontal Pod Autoscaling (HPA) を監視し、メトリクス、イベント、オートスケーリングの動作をリアルタイムで確認する方法を学びます -weight: 2 -authors: ["Robert Castley"] -time: 45 minutes ---- - -このハンズオンワークショップでは、Splunk OpenTelemetry Collectorを使用してKubernetes Horizontal Pod Autoscaling (HPA) を監視する方法を学びます。PHP/Apacheアプリケーションとロードジェネレーターをデプロイしてオートスケーリングイベントをトリガーし、スケーリングのライフサイクル全体を観察します。 - -実践的な演習を通じて、OpenTelemetry Receivers、Kubernetes Namespaces、ReplicaSets、HPAのメカニズムを探求しながら、すべてをSplunk Observability Cloudで監視します。Kubernetes Navigatorの使い方をマスターし、カスタムダッシュボードを構築し、メトリクスとイベントを分析し、スケーリングアクティビティに対するアラートを設定するディテクターを構成します。 - -このワークショップでは、Splunkが事前設定済みのAWS/EC2上のUbuntu Linuxインスタンスを用意しています。 - -ワークショップで使用するインスタンスにアクセスするには、ワークショップリーダーから提供されるURLにアクセスしてください。 diff --git a/content/ja/ninja-workshops/2-hpa/docker/Dockerfile b/content/ja/ninja-workshops/2-hpa/docker/Dockerfile deleted file mode 100644 index af12a8a98d..0000000000 --- a/content/ja/ninja-workshops/2-hpa/docker/Dockerfile +++ /dev/null @@ -1,8 +0,0 @@ -FROM php:8.0-apache -WORKDIR /var/www/html - -COPY status.conf /etc/apache2/mods-available/status.conf -COPY index.php index.php -EXPOSE 80 - -LABEL org.opencontainers.image.source=https://github.com/splunk/observability-workshop diff --git a/content/ja/ninja-workshops/2-hpa/docker/index.php b/content/ja/ninja-workshops/2-hpa/docker/index.php deleted file mode 100644 index 719be75048..0000000000 --- a/content/ja/ninja-workshops/2-hpa/docker/index.php +++ /dev/null @@ -1,6 +0,0 @@ - diff --git a/content/ja/ninja-workshops/2-hpa/docker/status.conf b/content/ja/ninja-workshops/2-hpa/docker/status.conf deleted file mode 100644 index 876746d0f0..0000000000 --- a/content/ja/ninja-workshops/2-hpa/docker/status.conf +++ /dev/null @@ -1,27 +0,0 @@ - - # Allow server status reports generated by mod_status, - # with the URL of http://servername/server-status - # Uncomment and change the "192.0.2.0/24" to allow access from other hosts - - - SetHandler server-status - #Require local - #Require ip 192.0.2.0/24 - - - # Keep track of extended status information for each request - ExtendedStatus On - - # Determine if mod_status displays the first 63 characters of a request or - # the last 63, assuming the request itself is greater than 63 chars. - # Default: Off - #SeeRequestTail On - - - - # Show Proxy LoadBalancer status in mod_status - ProxyStatus On - - - - diff --git a/content/ja/ninja-workshops/2-hpa/images/heatmap-filter-down.png b/content/ja/ninja-workshops/2-hpa/images/heatmap-filter-down.png deleted file mode 100644 index 1a758ac4ab..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/heatmap-filter-down.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/k8s-deployment-overview.png b/content/ja/ninja-workshops/2-hpa/images/k8s-deployment-overview.png deleted file mode 100644 index 77bcddd741..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/k8s-deployment-overview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/k8s-workload-detail.png b/content/ja/ninja-workshops/2-hpa/images/k8s-workload-detail.png deleted file mode 100644 index faf3320d94..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/k8s-workload-detail.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/k8s-workload-replicaset.png b/content/ja/ninja-workshops/2-hpa/images/k8s-workload-replicaset.png deleted file mode 100644 index 89a323e9dc..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/k8s-workload-replicaset.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/k8s-workloads-filter.png b/content/ja/ninja-workshops/2-hpa/images/k8s-workloads-filter.png deleted file mode 100644 index 4de038414b..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/k8s-workloads-filter.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/k8s-workloads-screen.png b/content/ja/ninja-workshops/2-hpa/images/k8s-workloads-screen.png deleted file mode 100644 index b25826ab71..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/k8s-workloads-screen.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/k9s.png b/content/ja/ninja-workshops/2-hpa/images/k9s.png deleted file mode 100644 index 2f1855bb03..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/k9s.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/pivotbar.png b/content/ja/ninja-workshops/2-hpa/images/pivotbar.png deleted file mode 100644 index d94a151cc8..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/pivotbar.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/set-find-outliers.png b/content/ja/ninja-workshops/2-hpa/images/set-find-outliers.png deleted file mode 100644 index 8faa7a7741..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/set-find-outliers.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/workload-add-filter.png b/content/ja/ninja-workshops/2-hpa/images/workload-add-filter.png deleted file mode 100644 index d434742a81..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/workload-add-filter.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/workload-selection.png b/content/ja/ninja-workshops/2-hpa/images/workload-selection.png deleted file mode 100644 index 249b528a5c..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/workload-selection.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/images/workloads-heatmap.png b/content/ja/ninja-workshops/2-hpa/images/workloads-heatmap.png deleted file mode 100644 index c496ff7cc7..0000000000 Binary files a/content/ja/ninja-workshops/2-hpa/images/workloads-heatmap.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/kubernetes-navigator.md b/content/ja/ninja-workshops/2-hpa/kubernetes-navigator.md deleted file mode 100644 index 0012e4b060..0000000000 --- a/content/ja/ninja-workshops/2-hpa/kubernetes-navigator.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: Kubernetes Navigator のツアー -linkTitle: 2. Kubernetes Navigator -weight: 2 -hidden: true ---- - -## 1. クラスタービューとワークロードビュー - -Kubernetes Navigatorは、Kubernetesデータを表示するための2つの異なるユースケースを提供します。 - -* **K8s workloads** は、ワークロード（*デプロイメント*）に関する情報の提供に焦点を当てています。 -* **K8s nodes** は、クラスター、ノード、Pod、コンテナのパフォーマンスに関する洞察を提供することに焦点を当てています。 - -最初に、必要に応じてどちらかのビューを選択します（必要に応じてビューを切り替えることができます）。このワークショップで最もよく使用するのはワークロードビューであり、特にそれに焦点を当てます。 - -### 1.1 K8s クラスター名の確認 - -最初のタスクは、クラスターを識別して見つけることです。クラスターは、事前設定された環境変数 `INSTANCE` によって決定された名前が付けられます。クラスター名を確認するには、ターミナルで以下のコマンドを入力します: - -``` bash -echo $INSTANCE-k3s-cluster -``` - -ワークショップの後半でフィルタリングに必要になるため、クラスター名をメモしておいてください。 - -## 2. ワークロードとワークロード詳細ペイン - -Observability UIの **Infrastructure** ページに移動し、**Kubernetes** を選択します。これにより、一連のKubernetesサービスが表示され、その1つが **Kubernetes workloads** ペインです。このペインには、すべてのワークロードで処理されている負荷の概要を示す小さなグラフが表示されます。**Kubernetes workloads** ペインをクリックすると、ワークロードビューに移動します。 - -最初は、Observability Cloud組織に報告されているすべてのクラスターのすべてのワークロードが表示されます。いずれかのワークロードでアラートが発火した場合、以下の画像の右上にハイライト表示されます。 - -![workloads](../images/k8s-workloads-screen.png) - -次に、フィルターツールバーで **Cluster** をフィルタリングしてクラスターを見つけましょう。 - -{{% notice title="注意" style="info" %}} -`emea-ws-7*` のような部分的な名前を検索ボックスに入力して、クラスターをすばやく見つけることができます。 - -また、デフォルトの時間を **-4h** から過去15分（**-15m**）に切り替えることを強くお勧めします。 -{{% /notice %}} - -![workloads-filter](../images/k8s-workloads-filter.png) - -これで、自分のクラスターのデータのみが表示されます。 - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -クラスターで実行されているワークロードの数とNamespaceの数はいくつですか？ -{{% /notice %}} - -### 2.1 Navigator 選択チャートの使用 - -デフォルトでは、**Kubernetes Workloads** テーブルは `k8s.namespace.name` でグループ化された `# Pods Failed` でフィルタリングされます。`default` Namespaceを展開して、Namespace内のワークロードを確認してください。 - -![k8s-workload-selection](../images/workload-selection.png) - -次に、**Map** アイコン（**Table** アイコンの横）を選択して、リストビューをヒートマップビューに変更しましょう。このオプションを変更すると、以下のような（または類似の）可視化が表示されます: - -![k8s-Heat-map](../images/workloads-heatmap.png) - -このビューでは、各ワークロードが色付きの四角形になっていることに気付くでしょう。これらの四角形は、選択した **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** に変更します: - -![k8s-Heat-map](../images/set-find-outliers.png) - -**Find Outliers** ビューは、ワークロード（または使用するNavigatorに応じて任意のサービス）の選択を表示し、何かが変更されたかどうかをすばやく把握する必要がある場合に非常に便利です。 - -これにより、パフォーマンスが異なる（増加または減少）項目（この場合はワークロード）に関する迅速な洞察が得られ、問題を見つけやすくなります。 - -### 2.2 デプロイメント概要ペイン - -デプロイメント概要ペインでは、デプロイメントのステータスをすばやく把握できます。デプロイメントのPodがPending、Running、Succeeded、Failed、またはUnknown状態にあるかどうかを一目で確認できます。 - -![k8s-workload-overview](../images/k8s-deployment-overview.png) - -* *Running:* Podがデプロイされ、実行中の状態 -* *Pending:* デプロイ待ち -* *Succeeded:* Podがデプロイされ、ジョブを完了して終了 -* *Failed:* Pod内のコンテナが実行され、何らかのエラーを返した -* *Unknown:* Kubernetesが既知のステータスのいずれも報告していない（例えば、Podの起動中または停止中の場合など） - -名前がチャートの許容範囲より長い場合は、マウスをワークロード名の上に置くと展開できます。 - -特定のワークロードにフィルタリングするには、**k8s.workload.name** 列のワークロード名の横にある三点リーダー **...** をクリックし、ドロップダウンボックスから **Filter** を選択します: - -![workload-add-filter](../images/workload-add-filter.png) - -これにより、選択したワークロードがフィルターに追加されます。その後、**default** Namespace内の単一のワークロードが表示されます: - -![workload-add-filter](../images/heatmap-filter-down.png) - -上記のヒートマップから、**default** Namespace内の **splunk-otel-collector-k8s-cluster-receiver** を見つけて、四角形をクリックしてワークロードの詳細情報を確認します: - -![workload-add-filter](../images/k8s-workload-detail.png) - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -otel-collectorのCPU requestとCPU limitの単位は何ですか？ -{{% /notice %}} - -この時点で、Podの情報にドリルダウンできますが、それはこのワークショップの範囲外です。 - -## 3. Navigator サイドバー - -ワークショップの後半で、クラスターにApacheサーバーをデプロイします。これにより、**Navigator Sidebar** にアイコンが表示されます。 - -KubernetesのNavigatorでは、Navigatorサイドバーで依存するサービスとコンテナを追跡できます。Navigatorサイドバーを最大限に活用するには、`service.name` という追加ディメンションを設定して、追跡するサービスを構成します。このワークショップでは、Apacheを監視するための `extraDimensions` をCollector設定で既に構成しています。例: - -```yaml -extraDimensions: - service.name: php-apache -``` - -Navigatorサイドバーが展開し、以下の画像のように検出されたサービスへのリンクが追加されます: - -![Pivotbar](../images/pivotbar.png) - -これにより、Navigator間を簡単に切り替えることができます。Apacheサーバーインスタンスにも同様にNavigatorサイドバーがあり、Kubernetes Navigatorにすばやく戻ることができます。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md deleted file mode 100644 index bb0905a6de..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/1-confirmation.md +++ /dev/null @@ -1,310 +0,0 @@ ---- -title: OpenTelemetry Collector Contrib のインストール -linkTitle: 1.1 インストールの確認 -weight: 1 ---- - -## Collector が動作していることを確認する - -Collector が動作しているはずです。`systemctl` コマンドを使用して root として確認します。ステータス表示を終了するには `q` を押してください。 - -{{< tabs >}} -{{% tab title="コマンド" %}} - -``` bash -sudo systemctl status otelcol-contrib -``` - -{{% /tab %}} -{{% tab title="ステータス出力" %}} - -``` 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="コマンド" %}} - -``` bash -sudo systemctl stop otelcol-contrib && sudo systemctl disable otelcol-contrib -``` - -{{% /tab %}} -{{< /tabs >}} - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**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 のインストール - - [プロジェクトリリース](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 のチームは、より高いサポートと安定性を提供しており、デプロイメントのニーズに応じたキュレーションされた体験を提供できます。 - -## Ninja ゾーン - -必要なツールがすべてインストールされたら、`otelcol-builder.yaml` という名前の新しいファイルを作成し、以下のディレクトリ構造に従います - -``` bash -. -└── otelcol-builder.yaml -``` - -ファイルを作成したら、いくつかの追加メタデータとともにインストールするコンポーネントのリストを追加する必要があります。 - -この例では、入門用の設定に必要なコンポーネントのみをインストールするビルダーマニフェストを作成します - -```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 -``` - -yaml ファイルが _ocb_ 用に更新されたら、以下のコマンドを実行します - -```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 -``` - -### 参考資料 - -1. [https://opentelemetry.io/docs/collector/custom-collector/](https://opentelemetry.io/docs/collector/custom-collector/) - -{{% /expand %}} - ---- - -## デフォルト設定 - -OpenTelemetry は YAML ファイルを通じて設定されます。これらのファイルには、ニーズに合わせて変更できるデフォルト設定があります。提供されるデフォルト設定を見てみましょう - -{{< tabs >}} -{{% tab title="コマンド" %}} - -```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 リポジトリ**](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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md deleted file mode 100644 index a414accad8..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/1-installation/_index.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: OpenTelemetry Collector Contrib のインストール -linkTitle: 1. インストール -weight: 1 ---- - -## OpenTelemetry Collector Contrib ディストリビューションのダウンロード - -OpenTelemetry Collector をインストールする最初のステップは、ダウンロードです。このラボでは、`wget` コマンドを使用して OpenTelemetry の GitHub リポジトリから `.deb` パッケージをダウンロードします。 - -お使いのプラットフォーム用の `.deb` パッケージを [**OpenTelemetry Collector Contrib リリースページ**](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="インストール" %}} - -``` bash -sudo dpkg -i otelcol-contrib_0.111.0_linux_amd64.deb -``` - -{{% /tab %}} -{{% tab title="dpkg 出力" %}} - -``` 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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md deleted file mode 100644 index 64fec98957..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/1-health.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: OpenTelemetry Collector Extensions -linkTitle: 2.1 Health Check -weight: 1 ---- - -## Health Check - -拡張機能は、インストール手順で参照した同じ `config.yaml` ファイルで設定します。`config.yaml` ファイルを編集して拡張機能を設定しましょう。**pprof** と **zpages** 拡張機能はデフォルトの `config.yaml` ファイルに既に設定されていることに注意してください。このワークショップでは、Collector のヘルス状態にアクセスできるよう、すべてのネットワークインターフェースでポートを公開するように **health_check** 拡張機能のみを更新します。 - -{{% 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 %}} - -この拡張機能により、OpenTelemetry Collector のステータスを確認するためにプローブできる HTTP URL が有効になります。この拡張機能は、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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md deleted file mode 100644 index 203375c9bd..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/2-performance.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -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) 拡張機能は、golang の net/http/pprof エンドポイントを有効にします。これは通常、開発者がパフォーマンスプロファイルを収集し、サービスの問題を調査するために使用されます。**このワークショップではこれを扱いません**。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md deleted file mode 100644 index b8bd2a08ef..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/3-zpages.md +++ /dev/null @@ -1,363 +0,0 @@ ---- -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) は、外部エクスポーターの代わりにインプロセスで使用できる機能です。組み込まれると、バックグラウンドでトレースとメトリクス情報を収集・集約し、リクエストされたときにウェブページでこのデータを提供します。zPages は、Collector が期待どおりに動作していることを確認するための非常に便利な診断機能です。 - -{{< tabs >}} -{{% tab title="ServiceZ" %}} - -**ServiceZ** は、Collector サービスの概要と、pipelinez、extensionz、featurez の各 zPages へのクイックアクセスを提供します。このページには、ビルド情報とランタイム情報も表示されます。 - -サンプル URL: [**http://localhost:55679/debug/servicez**](http://localhost:55679/debug/servicez)（`localhost` をご自身の環境に合わせて変更してください）。 - -![ServiceZ](../../images/servicez.png) - -{{% /tab %}} -{{% tab title="PipelineZ" %}} - -**PipelineZ** は、Collector で実行されているパイプラインに関する洞察を提供します。タイプ、データが変更されるかどうかの情報を確認でき、各パイプラインで使用されているレシーバー、プロセッサー、エクスポーターの情報も確認できます。 - -サンプル URL: [**http://localhost:55679/debug/pipelinez**](http://localhost:55679/debug/pipelinez)（`localhost` をご自身の環境に合わせて変更してください）。 - -![PipelineZ](../../images/pipelinez.png) - -{{% /tab %}} -{{% tab title="ExtensionZ" %}} - -**ExtensionZ** は、Collector でアクティブな拡張機能を表示します。 - -サンプル URL: [**http://localhost:55679/debug/extensionz**](http://localhost:55679/debug/extensionz)（`localhost` をご自身の環境に合わせて変更してください）。 - -![ExtensionZ](../../images/extensionz.png) - -{{% /tab %}} -{{% /tabs %}} - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**Ninja:** storage 拡張機能でデータの耐久性を向上させる{{% /badge %}}" %}} - -このためには、使用しているディストリビューションに `file_storage` 拡張機能がインストールされていることを確認する必要があります。これは、`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 >}} - -この拡張機能は、エクスポーターが設定されたエンドポイントにデータを送信できない場合に、エクスポーターがデータをディスクにキューイングする機能を提供します。 - -拡張機能を設定するには、以下の情報を含めるように設定を更新する必要があります。まず、/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 %}} - ---- - -## 設定の確認 - -拡張機能について学んだので、設定の変更を確認しましょう。 - ---- - -{{% 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 %}} - ---- - -拡張機能について確認したので、次はワークショップのデータパイプライン部分に進みましょう。パイプラインは、Collector 内でデータが辿る経路を定義し、受信から始まり、さらなる処理や変更を経て、最終的にエクスポーターを通じて Collector を出ていきます。 - -OpenTelemetry Collector のデータパイプラインは、**レシーバー**、**プロセッサー**、**エクスポーター**で構成されています。まずはレシーバーから始めます。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md deleted file mode 100644 index 8a47d9b726..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/2-extensions/_index.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: OpenTelemetry Collector Extensions -linkTitle: 2. Extensions -weight: 2 ---- - -OpenTelemetry Collector がインストールできたので、OpenTelemetry Collector の拡張機能について見ていきましょう。拡張機能はオプションであり、主にテレメトリデータの処理を伴わないタスクに使用されます。拡張機能の例としては、ヘルスモニタリング、サービスディスカバリ、データ転送などがあります。 - -{{< mermaid >}} -%%{ - init:{ - "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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md deleted file mode 100644 index 8d540f2f0d..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/1-hostmetrics.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: OpenTelemetry Collector Receivers -linkTitle: 1. Host Metrics -weight: 1 ---- - -## Host Metrics Receiver - -[**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 を設定しましょう。以下の YAML を **receivers** セクションの下に挿入してください。インデントはスペース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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md deleted file mode 100644 index 7d4745429c..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/2-prometheus.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -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 から収集するメトリクスの一部を表示するダッシュボード例です。ここでは、受け入れられたスパン、メトリクス、ログレコードと送信されたものを確認できます。 - -{{% notice style="note" %}} -以下のスクリーンショットは、Splunk Observability Cloud の標準（OOTB）ダッシュボードで、Splunk OpenTelemetry Collector のインストール状況を簡単に監視できます。 -{{% /notice %}} - -![otel-charts](../../images/otel-charts.png) diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md deleted file mode 100644 index ad36ab4c28..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/3-other-receivers.md +++ /dev/null @@ -1,171 +0,0 @@ ---- -title: OpenTelemetry Collector Receivers -linkTitle: 3. Other Receivers -weight: 3 ---- - -## その他の Receiver - -デフォルト設定には、**otlp**、**opencensus**、**jaeger**、**zipkin** などの他の Receiver があることに気づくでしょう。これらは他のソースからテレメトリデータを受信するために使用されます。このワークショップではこれらの Receiver については取り上げませんので、そのままにしておいてください。 - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**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 extension を使い始めるには、それらが Collector のビルドマニフェストに含まれている必要があります。 - -詳細は [installation](../1-installation/) を参照してください。 - -## 考慮すべき事項 - -一部の短期間のタスクでは、_username_ や _password_ などの追加設定が必要な場合があります。 -これらの値は [環境変数](https://opentelemetry.io/docs/collector/configuration/#configuration-environment-variables) で参照するか、 -`${file:./path/to/database/password}` のようなスキーム展開構文を使用できます。 -この方法を採用する場合は、組織のシークレット管理のベストプラクティスに従ってください。 - -## Ninja ゾーン - -この Ninja ゾーンに必要なことは2つだけです - -1. ビルダーマニフェストに receiver creator と observer extension が追加されていることを確認します。 -2. 検出されたエンドポイントとマッチングするために使用できる設定を作成します。 - -テンプレート化された設定を作成するには、以下のようにします - -```yaml -receiver_creator: - watch_observers: [host_observer] - receivers: - redis: - rule: type == "port" && port == 6379 - config: - password: ${env:HOST_REDIS_PASSWORD} -``` - -その他の例については、[receiver creator の例](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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md deleted file mode 100644 index ee9fa9764c..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/3-receivers/_index.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: OpenTelemetry Collector Receivers -linkTitle: 3. Receivers -weight: 3 ---- - -ワークショップの Receiver セクションへようこそ！ここは OpenTelemetry Collector のデータパイプラインの出発点です。早速始めましょう。 - -Receiver は、プッシュベースまたはプルベースであり、データを Collector に取り込む方法です。Receiver は1つ以上のデータソースをサポートできます。一般的に、Receiver は指定された形式でデータを受け取り、内部形式に変換してから、該当するパイプラインで定義された Processor と Exporter に渡します。 - -{{< mermaid >}} -%%{ - init:{ - - "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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md deleted file mode 100644 index 36d3e1e5b2..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/1-batch-processor.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: OpenTelemetry Collector Processors -linkTitle: 4.1 Batch -weight: 1 ---- - -## Batch Processor - -デフォルトでは、**batch** processor のみが有効になっています。この processor は、データをエクスポートする前にバッチ処理するために使用されます。これは、exporter へのネットワーク呼び出しの回数を減らすのに役立ちます。このワークショップでは、Collector にハードコードされている以下のデフォルト値を継承します - -- `send_batch_size`（デフォルト = 8192）：タイムアウトに関係なくバッチが送信されるスパン、メトリクスデータポイント、またはログレコードの数。send_batch_size はトリガーとして機能し、バッチのサイズには影響しません。パイプラインの次のコンポーネントに送信されるバッチサイズの制限を強制する必要がある場合は、send_batch_max_size を参照してください。 -- `timeout`（デフォルト = 200ms）：サイズに関係なくバッチが送信されるまでの時間。ゼロに設定すると、send_batch_max_size のみに従ってデータが即座に送信されるため、send_batch_size は無視されます。 -- `send_batch_max_size`（デフォルト = 0）：バッチサイズの上限。0 はバッチサイズに上限がないことを意味します。このプロパティは、大きなバッチを小さな単位に分割することを保証します。send_batch_size 以上である必要があります。 - -Batch processor の詳細については、[**Batch Processor のドキュメント**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/batchprocessor/README.md)を参照してください。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md deleted file mode 100644 index 482303f929..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/2-resource-detection.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: OpenTelemetry Collector Processors -linkTitle: 4.2 Resource Detection -weight: 2 ---- - -## Resource Detection Processor - -**resourcedetection** processor は、ホストからリソース情報を検出し、テレメトリデータのリソース値にこの情報を追加または上書きするために使用できます。 - -デフォルトでは、ホスト名は可能であれば 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` - -これらのタグをメトリクスに追加するために、別の processor を作成します。 - -{{% 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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md deleted file mode 100644 index 60a2852307..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/3-attributes.md +++ /dev/null @@ -1,200 +0,0 @@ ---- -title: OpenTelemetry Collector Processors -linkTitle: 4.3 Attributes -weight: 3 ---- - -## Attributes Processor - -attributes processor は、スパン、ログ、またはメトリクスの属性を変更します。この processor は、指定されたアクションに含めるか除外するかを決定するために、入力データをフィルタリングおよびマッチングする機能もサポートしています。 - -設定で指定された順序で実行されるアクションのリストを受け取ります。サポートされているアクションは以下の通りです - -- `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=star %}}**Ninja:** connector を使用して内部インサイトを取得する{{% /badge %}}" %}} - -Collector への最新の追加機能の1つは [**connector**](https://opentelemetry.io/docs/collector/configuration/#connectors) の概念で、あるパイプラインの出力を別のパイプラインの入力に接続できます。 - -これが有益な例として、一部のサービスはエクスポートされるデータポイントの量、エラーステータスを含むログの数、または特定のデプロイ環境から送信されるデータ量に基づいてメトリクスを出力します。count connector はこれをすぐに使える形で対処するのに役立ちます。 - -## processor の代わりに connector を使用する理由 - -processor は処理したデータを渡す必要があるため、追加データを生成する点で制限があり、追加情報を公開するのが困難です。connector は受信したデータを出力する必要がないため、求めているインサイトを作成する機会を提供します。 - -例えば、デプロイ環境属性を持たないログ、メトリクス、トレースの数をカウントする connector を作成できます。 - -デプロイ環境別にデータ使用量を分類できる非常にシンプルな例です。 - -## connector に関する考慮事項 - -connector は、あるパイプラインからエクスポートされ、別のパイプラインで受信されたデータのみを受け入れます。これは、connector を活用するために Collector の設定をどのように構成するかを検討する必要があることを意味します。 - -## 参考資料 - -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 %}} - ---- - -## 設定の確認 - -processors について説明しました。設定の変更を確認しましょう。 - ---- - -{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定を確認する{{% /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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md deleted file mode 100644 index 49db179d88..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/4-processors/_index.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -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:{ - - "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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md deleted file mode 100644 index 65004ef74d..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/1-otlphttp.md +++ /dev/null @@ -1,199 +0,0 @@ ---- -title: OpenTelemetry Collector Exporters -linkTitle: 5.1 OTLP HTTP -weight: 1 ---- - -## OTLP HTTP Exporter - -HTTP 経由で Splunk Observability Cloud にメトリクスを送信するには、**otlphttp** エクスポーターを設定する必要があります。 - -`/etc/otelcol-contrib/config.yaml` ファイルを編集して、**otlphttp** エクスポーターを設定しましょう。以下の YAML を **exporters** セクションの下に挿入してください。インデントは2スペースで揃えます。 - -また、ディスクがいっぱいになるのを防ぐために、ロギングエクスポーターの詳細度も変更します。デフォルトの `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** エクスポーターは、`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` 圧縮が有効になっています。これはエクスポーター設定で `compression: none` を設定することで無効にできます。このワークショップでは、データを送信する最も効率的な方法であるため、圧縮を有効のままにしてデフォルトを使用します。 - -Splunk Observability Cloud にメトリクスを送信するには、アクセストークンを使用する必要があります。これは Splunk Observability Cloud UI で新しいトークンを作成することで行えます。トークンの作成方法の詳細については、[Create a token](https://docs.splunk.com/Observability/admin/authentication-tokens/org-tokens.html) を参照してください。トークンのタイプは **INGEST** である必要があります。 - -{{% notice style="note" %}} -Splunk 主催のワークショップに参加している場合、使用しているインスタンスにはすでにアクセストークンが設定されています（環境変数として設定済み）。設定ファイルでその環境変数を参照します。それ以外の場合は、新しいトークンを作成して環境変数として設定する必要があります。例 - -``` 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} -``` - -## 設定の確認 - -エクスポーターについて説明したので、設定の変更を確認しましょう - ---- - -{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定を確認する{{% /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 セクションで、設定したレシーバー、プロセッサー、エクスポーターを有効にする必要があります。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md deleted file mode 100644 index 0861170b5c..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/5-exporters/_index.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: OpenTelemetry Collector Exporters -linkTitle: 5. Exporters -weight: 5 ---- - -Exporter はプッシュ型またはプル型で、1つ以上のバックエンド/宛先にデータを送信する方法です。Exporter は1つ以上のデータソースをサポートする場合があります。 - -このワークショップでは、[**otlphttp**](https://opentelemetry.io/docs/specs/otel/protocol/exporter/) exporter を使用します。OpenTelemetry Protocol (OTLP) は、テレメトリデータを送信するためのベンダー中立で標準化されたプロトコルです。OTLP exporter は、OTLP プロトコルを実装しているサーバーにデータを送信します。OTLP exporter は [**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:{ - - "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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md deleted file mode 100644 index 388dcd053e..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/1-hostmetrics.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector Service -linkTitle: 6.1 Host Metrics -weight: 1 ---- - -## Hostmetrics Receiver - -ワークショップの Receivers セクションで、さまざまなソースからスクレイプされるホストシステムに関するメトリクスを生成する [**Host Metrics Receiver**](../3-receivers/#host-metrics-receiver) を定義したことを思い出してください。この receiver を有効にするには、metrics パイプラインに `hostmetrics` receiver を含める必要があります。 - -`metrics` パイプラインで、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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md deleted file mode 100644 index bc9d1151d6..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/2-prometheus.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector Service -linkTitle: 6.2 Prometheus -weight: 2 ---- - -## Prometheus Internal Receiver - -ワークショップの前半で、Collector 内部のメトリクスを収集していることを反映するために `prometheus` receiver の名前を `prometheus/internal` に変更しました。 - -ここで、metrics パイプラインで `prometheus/internal` receiver を有効にする必要があります。`metrics` パイプラインの `receivers` セクションに `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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md deleted file mode 100644 index 8f8aa8917e..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/3-resourcedetection.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector Service -linkTitle: 6.3 Resource Detection -weight: 3 ---- - -## Resource Detection Processor - -また、Collector がインスタンスのホスト名と AWS/EC2 メタデータをキャプチャできるように、`resourcedetection/system` と `resourcedetection/ec2` processor を追加しました。ここで、metrics パイプラインでこれら2つの processor を有効にする必要があります。 - -`metrics` パイプラインの `processors` セクションに `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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md deleted file mode 100644 index 40e346aca2..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/4-attributes.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector Service -linkTitle: 6.4 Attributes -weight: 4 ---- - -## Attributes Processor - -また、このワークショップの Processors セクションで、Collector がすべてのメトリクスに `participant.name` という新しい属性を挿入するように `attributes/conf` processor を追加しました。ここで、metrics パイプラインでこれを有効にする必要があります。 - -`metrics` パイプラインの `processors` セクションに `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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md deleted file mode 100644 index dd8ae272c1..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/5-otlphttp.md +++ /dev/null @@ -1,243 +0,0 @@ ---- -title: OpenTelemetry Collector Service -linkTitle: 6.5 OTLP HTTP -weight: 5 ---- - -## OTLP HTTP Exporter - -ワークショップの Exporters セクションで、メトリクスを Splunk Observability Cloud に送信するための `otlphttp` exporter を設定しました。ここで、metrics パイプラインでこれを有効にする必要があります。 - -`metrics` パイプラインの `exporters` セクションに `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=star %}}**Ninja:** Collector の内部を観察する{{% /badge %}}" %}} - -Collector は、実行中のコンポーネントからの追加シグナルを含む、自身の動作に関する内部シグナルをキャプチャします。 -これは、データフローに関する判断を行うコンポーネントが、その情報をメトリクスまたはトレースとして公開する方法を必要とするためです。 - -## なぜ Collector を監視するのか？ - -これは「監視者を誰が監視するのか？」という、鶏と卵のような問題ですが、この情報を公開できることは重要です。Collector の歴史において興味深い点は、Go メトリクス SDK が安定版と見なされる前から存在していたため、当面の間、Collector はこの機能を提供するために Prometheus エンドポイントを公開しているということです。 - -## 考慮事項 - -組織内で実行中の各 Collector の内部使用状況を監視すると、大量の新しい Metric Time Series (MTS) が発生する可能性があります。Splunk ディストリビューションでは、これらのメトリクスが厳選されており、予想される増加を予測するのに役立ちます。 - -## 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 %}}" %}} -![otelbin-validator](../../images/otelbin.png) -{{% /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` を自分の環境に合わせて変更してください）。 -![pipelinez-full-config](../../images/pipelinez-full-config.png) diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md deleted file mode 100644 index 79b38dea2b..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/6-service/_index.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/OpenTelemetry-Contrib-Dashboard-Group.json b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/OpenTelemetry-Contrib-Dashboard-Group.json deleted file mode 100644 index cf3425ead6..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/OpenTelemetry-Contrib-Dashboard-Group.json +++ /dev/null @@ -1,1415 +0,0 @@ -{ - "chartExports": [ - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "GAvqZAwAABc", - "importOf": "FybsAETAwAM", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "CPU Load Average (1m)", - "options": { - "colorBy": "Dimension", - "colorScale": null, - "colorScale2": null, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "system.cpu.load_average.1m", - "label": "A", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "None", - "showSparkLine": false, - "time": { - "range": 300000, - "rangeEnd": 0, - "type": "relative" - }, - "timestampHidden": true, - "type": "SingleValue", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.cpu.load_average.1m').publish(label='A')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "Operations/sec", - "id": "GAvqZAwAABg", - "importOf": "FybsAETAwAs", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Disk I/O", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Read ops - RED", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Write ops - BLUE", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - } - ], - "axisPrecision": null, - "colorBy": "Metric", - "defaultPlotType": "LineChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": null, - "onChartLegendOptions": { - "dimensionInLegend": null, - "showLegend": false - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Read ops/sec", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Write ops/sec", - "label": "B", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 1 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('disk_ops.read',rollup='rate').sum().publish(label='A')\nB = data('disk_ops.write',rollup='rate').sum().publish(label='B')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "GAvqZAwAABk", - "importOf": "FybsAETAwA0", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Load average", - "options": { - "colorBy": "Dimension", - "colorScale2": null, - "hideMissingValues": false, - "legendOptions": { - "fields": null - }, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "1m Average", - "label": "A", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "5m Average", - "label": "B", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "15m Average", - "label": "C", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "Sparkline", - "sortBy": "+sf_metric", - "time": { - "range": 900000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "List", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.cpu.load_average.1m').mean().publish(label='A')\nB = data('system.cpu.load_average.5m').mean().publish(label='B')\nC = data('system.cpu.load_average.15m').mean().publish(label='C')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "Bits/sec", - "id": "GAvqZAwAABo", - "importOf": "FybsAETAwAc", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Network I/O", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Input bits/s - RED", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Output bits/s - BLUE", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - } - ], - "axisPrecision": null, - "colorBy": "Metric", - "defaultPlotType": "LineChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": "device", - "showLegend": true - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Input bits/sec", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Output bits/sec", - "label": "B", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 1 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Binary" - }, - "packageSpecifications": "", - "programText": "A = data('system.network.io', filter=filter('direction', 'receive')).sum(by=['device']).publish(label='A')\nB = data('system.network.io', filter=filter('direction', 'transmit'), rollup='delta').sum(by=['device']).publish(label='B')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "GAvqZAwAABs", - "importOf": "FybsAETAwAk", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Disk used", - "options": { - "colorBy": "Dimension", - "colorScale2": null, - "hideMissingValues": false, - "legendOptions": { - "fields": [ - { - "enabled": true, - "property": "device" - }, - { - "enabled": false, - "property": "fs_type" - }, - { - "enabled": false, - "property": "host" - }, - { - "enabled": false, - "property": "sf_originatingMetric" - }, - { - "enabled": true, - "property": "mountpoint" - }, - { - "enabled": false, - "property": "sf_metric" - }, - { - "enabled": false, - "property": "plugin_instance" - }, - { - "enabled": false, - "property": "plugin" - }, - { - "enabled": false, - "property": "dsname" - }, - { - "enabled": false, - "property": "AWSUniqueId" - }, - { - "enabled": false, - "property": "os.type" - }, - { - "enabled": true, - "property": "type" - }, - { - "enabled": false, - "property": "mode" - }, - { - "enabled": true, - "property": "state" - }, - { - "enabled": false, - "property": "host.id" - }, - { - "enabled": false, - "property": "participant.name" - }, - { - "enabled": false, - "property": "my.name" - } - ] - }, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "system.filesystem.usage", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "A", - "label": "B", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "Sparkline", - "sortBy": "-value", - "time": { - "range": 900000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "List", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "B = (A).publish(label='B')\nA = data('system.filesystem.usage', filter=filter('state', 'used')).publish(label='A', enable=False)", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "GAvqZAwAABw", - "importOf": "FybsAETAwAo", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "CPU %", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": null - } - ], - "axisPrecision": null, - "colorBy": "Dimension", - "defaultPlotType": "AreaChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": null, - "showLegend": false - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "CPU utilization (%)", - "label": "A", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.cpu.time', filter=filter('state', 'user')).scale(10).publish(label='A')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "GAvqZAwAAB0", - "importOf": "FybsAETAwAw", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Total network bits/sec", - "options": { - "colorBy": "Metric", - "colorScale2": null, - "hideMissingValues": false, - "legendOptions": { - "fields": null - }, - "maximumPrecision": 4, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Input bits/sec", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Output bits/sec", - "label": "B", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 1 - } - ], - "refreshInterval": null, - "secondaryVisualization": "Sparkline", - "sortBy": "+sf_metric", - "time": { - "range": 900000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "List", - "unitPrefix": "Binary" - }, - "packageSpecifications": "", - "programText": "A = data('system.network.io', filter=filter('direction', 'receive')).sum().publish(label='A')\nB = data('system.network.io', filter=filter('direction', 'transmit'), rollup='rate').sum().publish(label='B')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "GAvqZAwAAB4", - "importOf": "FybsAETAwAY", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Memory used", - "options": { - "colorBy": "Metric", - "colorScale": null, - "colorScale2": null, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Used", - "label": "A", - "paletteIndex": 14, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "None", - "showSparkLine": false, - "time": { - "range": 300000, - "rangeEnd": 0, - "type": "relative" - }, - "timestampHidden": true, - "type": "SingleValue", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.memory.usage', filter=filter('state', 'used')).publish(label='A')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "Errors/sec", - "id": "GAvqZAwAAB8", - "importOf": "FybsAETAwAg", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Network errors", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Interface errors - RED", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Retransmits - BLUE", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - } - ], - "axisPrecision": null, - "colorBy": "Metric", - "defaultPlotType": "LineChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": null, - "showLegend": false - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Errors/sec", - "label": "A", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "system.network.errors", - "label": "B", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Interface errors/sec", - "label": "C", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.network.errors', filter=filter('direction', 'receive')).publish(label='A', enable=False)\nB = data('system.network.errors', filter=filter('direction', 'transmit')).publish(label='B', enable=False)\nC = (A+B).sum().publish(label='C')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "GAvqZAwAACA", - "importOf": "FybsAETAwAU", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Memory", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Bytes", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": null - } - ], - "axisPrecision": null, - "colorBy": "Metric", - "defaultPlotType": "AreaChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": [ - { - "enabled": true, - "property": "sf_originatingMetric" - }, - { - "enabled": true, - "property": "sf_metric" - }, - { - "enabled": false, - "property": "plugin" - }, - { - "enabled": false, - "property": "dsname" - }, - { - "enabled": false, - "property": "host" - }, - { - "enabled": false, - "property": "AWSUniqueId" - }, - { - "enabled": true, - "property": "my.name" - }, - { - "enabled": true, - "property": "os.type" - }, - { - "enabled": true, - "property": "host.id" - }, - { - "enabled": true, - "property": "state" - }, - { - "enabled": true, - "property": "participant.name" - } - ] - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": "state", - "showLegend": true - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Inactive", - "label": "T", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Slab Unreclaimable", - "label": "U", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Buffered", - "label": "V", - "paletteIndex": 5, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Used", - "label": "W", - "paletteIndex": 7, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Free", - "label": "X", - "paletteIndex": 14, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Cached", - "label": "Y", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Slab Reclaimable", - "label": "Z", - "paletteIndex": 15, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "showEventLines": false, - "stacked": true, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Binary" - }, - "packageSpecifications": "", - "programText": "T = data('system.memory.usage', filter=filter('state', 'inactive')).publish(label='T')\nU = data('system.memory.usage', filter=filter('state', 'slab_unreclaimable')).publish(label='U')\nV = data('system.memory.usage', filter=filter('state', 'buffered')).publish(label='V')\nW = data('system.memory.usage', filter=filter('state', 'used')).publish(label='W')\nX = data('system.memory.usage', filter=filter('state', 'free')).publish(label='X')\nY = data('system.memory.usage', filter=filter('state', 'cached')).publish(label='Y')\nZ = data('system.memory.usage', filter=filter('state', 'slab_reclaimable')).publish(label='Z')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "Page swaps/sec", - "id": "GAvqZAwAACE", - "importOf": "FybsAETAwAQ", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Memory Paging", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Page in - RED", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Page out - BLUE", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - } - ], - "axisPrecision": null, - "colorBy": "Dimension", - "defaultPlotType": "LineChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": null, - "showLegend": false - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Page In", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Page Out", - "label": "B", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 1 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.paging.operations', filter=filter('direction', 'page_in'), rollup='delta').publish(label='A')\nB = data('system.paging.operations', filter=filter('direction', 'page_out'), rollup='delta').publish(label='B')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "GAvqZAwAACI", - "importOf": "FybsAETAwAI", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Disk free", - "options": { - "colorBy": "Dimension", - "colorScale2": null, - "hideMissingValues": false, - "legendOptions": { - "fields": [ - { - "enabled": false, - "property": "dsname" - }, - { - "enabled": false, - "property": "host" - }, - { - "enabled": false, - "property": "sf_originatingMetric" - }, - { - "enabled": false, - "property": "sf_metric" - }, - { - "enabled": false, - "property": "plugin" - }, - { - "enabled": true, - "property": "plugin_instance" - }, - { - "enabled": false, - "property": "fs_type" - }, - { - "enabled": false, - "property": "device" - }, - { - "enabled": true, - "property": "mountpoint" - }, - { - "enabled": true, - "property": "os.type" - }, - { - "enabled": true, - "property": "type" - }, - { - "enabled": true, - "property": "mode" - }, - { - "enabled": true, - "property": "state" - }, - { - "enabled": false, - "property": "host.id" - }, - { - "enabled": false, - "property": "participant.name" - }, - { - "enabled": false, - "property": "my.name" - } - ] - }, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Used bytes", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "Sparkline", - "sortBy": "-value", - "time": { - "range": 900000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "List", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.filesystem.usage', filter=filter('state', 'free')).publish(label='A')", - "relatedDetectorIds": [], - "tags": null - } - } - ], - "crossLinkExports": [], - "dashboardExports": [ - { - "dashboard": { - "authorizedWriters": null, - "chartDensity": "DEFAULT", - "charts": [ - { - "chartId": "GAvqZAwAAB4", - "column": 3, - "height": 1, - "row": 0, - "width": 3 - }, - { - "chartId": "GAvqZAwAAB0", - "column": 6, - "height": 1, - "row": 0, - "width": 3 - }, - { - "chartId": "GAvqZAwAABs", - "column": 9, - "height": 1, - "row": 0, - "width": 3 - }, - { - "chartId": "GAvqZAwAABc", - "column": 0, - "height": 1, - "row": 0, - "width": 3 - }, - { - "chartId": "GAvqZAwAABw", - "column": 0, - "height": 1, - "row": 1, - "width": 6 - }, - { - "chartId": "GAvqZAwAABk", - "column": 6, - "height": 1, - "row": 1, - "width": 6 - }, - { - "chartId": "GAvqZAwAACA", - "column": 0, - "height": 1, - "row": 2, - "width": 6 - }, - { - "chartId": "GAvqZAwAACE", - "column": 6, - "height": 1, - "row": 2, - "width": 6 - }, - { - "chartId": "GAvqZAwAABg", - "column": 0, - "height": 1, - "row": 3, - "width": 6 - }, - { - "chartId": "GAvqZAwAACI", - "column": 6, - "height": 1, - "row": 3, - "width": 6 - }, - { - "chartId": "GAvqZAwAABo", - "column": 0, - "height": 1, - "row": 4, - "width": 6 - }, - { - "chartId": "GAvqZAwAAB8", - "column": 6, - "height": 1, - "row": 4, - "width": 6 - } - ], - "created": 0, - "creator": null, - "customProperties": null, - "description": "", - "discoveryOptions": null, - "eventOverlays": null, - "filters": { - "sources": null, - "time": { - "end": "Now", - "start": "-5m" - }, - "variables": [ - { - "alias": "Participant Name", - "applyIfExists": false, - "description": "Name of Participant", - "preferredSuggestions": [], - "property": "participant.name", - "propertyMappings": [ - "participant.name" - ], - "replaceOnly": false, - "required": false, - "restricted": false, - "value": "" - } - ] - }, - "groupId": "GAvqZAwAABY", - "groupName": "OpenTelemetry Contrib", - "id": "GAvqZAwAACM", - "importOf": "FybsAETAwA4", - "lastUpdated": 0, - "lastUpdatedBy": null, - "maxDelayOverride": null, - "name": "OTel Contrib Dashboard", - "permissions": null, - "selectedEventOverlays": [], - "tags": null - } - } - ], - "groupExport": { - "group": { - "authorizedWriters": null, - "created": 0, - "creator": null, - "dashboardConfigs": [ - { - "configId": "FwPCYY8AICU", - "dashboardId": "GAvqZAwAACM", - "descriptionOverride": null, - "filtersOverride": null, - "nameOverride": null - } - ], - "dashboards": [ - "GAvqZAwAACM" - ], - "description": "", - "email": null, - "id": "GAvqZAwAABY", - "importDetails": { - "hashCode": 390745185, - "importOf": "FybsAETAwAE", - "importTime": 1701960702839 - }, - "importOf": "FybsAETAwAE", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "OpenTelemetry Contrib", - "permissions": null, - "teams": null - } - }, - "hashCode": 2140540413, - "id": "GAvqZAwAABY", - "modelVersion": 1, - "packageType": "GROUP" -} \ No newline at end of file diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md deleted file mode 100644 index 83f633bea2..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/7-visualisation/index.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: データの可視化 -linkTitle: 7. 可視化 -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** に移動します。これによりチームビューが表示されます。このビューの上部にある **All Dashboards** をクリックします - -![menu-dashboards](../images/menu-dashboards.png) - -検索ボックスで **OTel Contrib** を検索します - -![search-dashboards](../images/search-dashboards.png) - -{{% notice style="info" %}} -ダッシュボードが存在しない場合は、インストラクターがすぐに追加できます。Splunk 主催のワークショップに参加していない場合は、インポートするダッシュボードグループをこのページの下部で見つけることができます。 -{{% /notice %}} - -**OTel Contrib Dashboard** ダッシュボードをクリックして開き、次にダッシュボード上部の **Participant Name** ボックスをクリックして、`config.yaml` で `participant.name` に設定した名前をドロップダウンリストから選択するか、名前を入力して検索します - -![select-conf-attendee-name](../images/select-participant-name.png) - -これで、OpenTelemetry Collector を設定したホストのホストメトリクスを確認できます。 - -![participant-dashboard](../images/participant-dashboard.png) - -{{% resources sort="asc" style="info" title="Download Dashboard Group JSON for importing" /%}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md deleted file mode 100644 index 71ff3df0c5..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/1-project-setup.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: OpenTelemetry Collector 開発 -linkTitle: 8.1 Project Setup -weight: 9 ---- - -## プロジェクトのセットアップ {{% badge style=primary icon=star %}}**Ninja**{{% /badge %}} - -{{% notice style="note" %}} - -このワークショップセクションを完了するまでの時間は、経験によって異なります。 - -行き詰まった場合やインストラクターに沿って進めたい場合は、[**こちら**](https://github.com/splunk/collector-workshop-example)に完全なソリューションがあります。 - -{{% /notice %}} - -新しい _Jenkins CI_ レシーバーの開発を始めるには、まず 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** %}}go.mod を確認する{{% /badge %}}" %}} - -``` text -module splunk.conf/workshop/example/jenkinscireceiver - -go 1.20 -``` - -{{% /expand %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md deleted file mode 100644 index ef9a4c893b..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/2-configuration.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: OpenTelemetry Collector 開発 -linkTitle: 8.2 Configuration -weight: 10 ---- - -## Configuration の構築 - -コンポーネントの Configuration 部分は、ユーザーがコンポーネントに対して入力を行う方法です。そのため、設定に使用される値は以下の条件を満たす必要があります - -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 %}} - -悪い設定例は、設定のベストプラクティスの逆を行うことがコンポーネントの使いやすさにどのように影響するかを示しています。フィールド値が何であるべきかが明確ではなく、既存のプロセッサにプッシュできる機能が含まれており、フィールド名が Collector に存在する他のコンポーネントと一貫していません。 - -良い設定例は、必須の値をシンプルに保ち、他のコンポーネントからフィールド名を再利用し、コンポーネントが Jenkins と Collector 間の相互作用のみに焦点を当てることを確保しています。 - -コードタブは、私たちが追加する必要がある量と、Collector 内の共有ライブラリによってすでに提供されているものを示しています。これらはビジネスロジックに到達したときにより詳細に説明します。Configuration は小さく始まり、追加機能が必要になるとビジネスロジックが含まれるようになると変更されます。 - -## コードを書く - -Configuration に必要なコードを実装するために、以下の内容で `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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md deleted file mode 100644 index c6c8e3278a..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/3-component.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: OpenTelemetry Collector 開発 -linkTitle: 8.3 Component Review -weight: 11 ---- - -## コンポーネントのレビュー - -Jenkins からメトリクスをキャプチャするために必要なコンポーネントの種類を振り返ります - -{{% tabs %}} -{{% tab title="Extension" %}} -Extension が解決するビジネスユースケースは以下の通りです - -1. ランタイム設定が必要な共有機能を持つこと -1. Collector のランタイムを観測することを間接的に支援すること - -詳細は [**Extensions の概要**](../2-extensions) を参照してください。 -{{% /tab %}} -{{% tab title="Receiver" %}} -Receiver が解決するビジネスユースケースは以下の通りです - -- リモートソースからデータをフェッチする -- リモートソースからデータを受信する - -これは一般的に _pull_ 型と _push_ 型のデータ収集と呼ばれ、詳細は [Receiver の概要](../3-receivers) で読むことができます。 -{{% /tab %}} -{{% tab title="Processor" %}} -Processor が解決するビジネスユースケースは以下の通りです - -- データ、フィールド、または値の追加や削除 -- データを観測し、意思決定を行う -- バッファリング、キューイング、並び替え - -留意すべき点は、Processor を流れるデータタイプは、下流のコンポーネントに同じデータタイプを転送する必要があるということです。詳細は [Processor の概要](../4-processors) をお読みください。 - -{{% /tab %}} -{{% tab title="Exporter" %}} -Exporter が解決するビジネスユースケースは以下の通りです - -- ツール、サービス、またはストレージにデータを送信する - -OpenTelemetry Collector は「バックエンド」、つまりオールインワンのオブザーバビリティスイートになることを望んでおらず、むしろ OpenTelemetry を創設した原則を維持しています。つまり、すべての人のためのベンダーに依存しないオブザーバビリティです。詳細を再確認するには、[**Exporter の概要**](../5-exporters) をお読みください。 - -{{% /tab %}} -{{% tab title="{{% badge style=primary icon=star %}}**Ninja:** Connectors{{% /badge %}}" %}} - -これはワークショップで見逃されたコンポーネントタイプです。比較的新しい Collector への追加であるためです。Connector を考える最良の方法は、異なるテレメトリタイプとパイプライン間で使用できる Processor のようなものです。つまり、Connector はログとしてデータを受け入れ、メトリクスを出力したり、あるパイプラインからメトリクスを受け入れ、観測したデータに関するメトリクスを提供したりできます。 - -Connector が解決するビジネスケースは以下の通りです - -- 異なるテレメトリタイプ間の変換 - - ログからメトリクス - - トレースからメトリクス - - メトリクスからログ -- 受信データを観測し、独自のデータを生成する - - メトリクスを受け入れ、データの分析メトリクスを生成する。 - -[Processor の概要](../4-processors) の **Ninja** セクションに簡単な概要がありました。新しい Connector コンポーネントの更新についてはプロジェクトを確認してください。 -{{% /tab %}} -{{% /tabs %}} - -コンポーネントの概要から、Jenkins 用のプルベースのレシーバーを開発することが明確です。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md deleted file mode 100644 index 89e9032997..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/4-design.md +++ /dev/null @@ -1,247 +0,0 @@ ---- -title: OpenTelemetry Collector 開発 -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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md deleted file mode 100644 index 176f7fbaa0..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/5-business-logic.md +++ /dev/null @@ -1,225 +0,0 @@ ---- -title: OpenTelemetry Collector 開発 -linkTitle: 8.5 Building Business Logic -weight: 13 ---- - -## ビジネスロジックの構築 - -この時点で、現在何もしないカスタムコンポーネントがあるため、Jenkins からこのデータをキャプチャするために必要なロジックを追加する必要があります。 - -ここから、実行する必要があるステップは以下の通りです - -1. Jenkins に接続するクライアントを作成する -1. 設定されたすべてのジョブをキャプチャする -1. 設定されたジョブの最後のビルドのステータスを報告する -1. コミットのタイムスタンプとジョブ完了の時間差を計算する - -変更は `scraper.go` に対して行われます。 - -{{% tabs %}} -{{% tab title="1. Add Jenkins client" %}} - -Jenkins サーバーに接続できるようにするために、["github.com/yosida95/golang-jenkins"](https://pkg.go.dev/github.com/yosida95/golang-jenkins) パッケージを使用します。このパッケージは、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 レシーバーを初期化するために必要なすべてのセットアップコードが完了しました。 -{{% /tab%}} -{{% tab title="2. Capture all configured jobs" %}} - -ここからは、入力を待っていた `scrape` メソッドに焦点を当てます。このメソッドは、設定で構成された間隔（デフォルトでは毎分）で実行されます。 - -設定されたジョブの数をキャプチャしたい理由は、Jenkins サーバーの成長を確認し、オンボードしたプロジェクトの数を測定できるようにするためです。これを行うために、Jenkins クライアントを呼び出してすべてのジョブをリストし、エラーが報告された場合はメトリクスなしでそれを返し、そうでなければメトリクスビルダーからデータを出力します。 - -```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 レシーバーの構築が完了です！ - -## 次のステップ - -コンポーネントから欲しい機能がおそらくもっとあるでしょう。例えば - -- ジョブが使用したブランチ名を含めることはできますか？ -- ジョブのプロジェクト名を含めることはできますか？ -- プロジェクトの累積ジョブ期間をどのように計算しますか？ -- 変更が機能することをどのように検証しますか？ - -この時間を使って、遊んでみたり、壊してみたり、変更したり、ビルドからログをキャプチャしてみたりしてください。 - diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md deleted file mode 100644 index 35732586f7..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/8-develop/_index.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: OpenTelemetry Collector 開発 -linkTitle: 8. Develop -weight: 8 ---- - -## カスタムコンポーネントの開発 - -OpenTelemetry 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 Assessment（DORA）[^1] チームによって特定されました。_Jenkins CI_ を選択した理由は、同じオープンソースソフトウェアのエコシステム内にとどまることで、将来ベンダーが管理する CI ツールが採用するための例として機能できるからです。 - -## 計装 vs コンポーネント - -組織内のオブザーバビリティのレベルを向上させる際に考慮すべきことがあります。いくつかのトレードオフが生じるためです。 - -| | メリット | デメリット | -| ----- | ----- | ----- | -| **（自動）計装** | システムを監視するために外部 API を監視する必要がありません。 | 計装を変更するにはプロジェクトへの変更が必要です。 | -| | システムオーナー/開発者がオブザーバビリティを変更する権限を持てます。 | 追加のランタイム依存関係が必要です。 | -| | システムコンテキストを理解し、キャプチャしたデータを _Exemplars_ と関連付けることができます。 | システムのパフォーマンスに影響を与える可能性があります。 | -| **コンポーネント** | データ名やセマンティクスへの変更をシステムのリリースサイクルとは独立して展開できます。 | API の破壊的な変更には、システムと Collector の間で調整されたリリースが必要です。 | -| | 収集されるデータの更新/拡張は、ユーザーにとってシームレスな変更です。 | キャプチャされたデータのセマンティクスが、新しいシステムリリースと一致しない形で予期せず壊れる可能性があります。 | -| | サポートチームがオブザーバビリティの実践について深い理解を持つ必要がありません。 | システムから外部に公開された情報のみを表面化できます。 | diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md deleted file mode 100644 index ac6874cce5..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/_index.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -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 で使用するための Receiver、Processor、Exporter の設定の基本から始めます。参加者は初心者から、分散プラットフォームのビジネスオブザーバビリティニーズを解決するためのカスタムコンポーネントを追加できるレベルまで到達します。 - -### Ninja セクション - -ワークショップを通じて、展開可能な {{% badge style=primary icon=star %}}**Ninja** セクション{{% /badge %}} があります。これらはより実践的で、ワークショップ中または自分の時間に探求できる詳細な技術情報を提供します。 - -OpenTelemetry プロジェクトは頻繁に開発が行われているため、これらのセクションの内容が古くなる可能性があることに注意してください。詳細が同期していない場合はリンクが提供されます。更新が必要な箇所を見つけた場合はお知らせください。 - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**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 のコンポーネントを理解する -- Receiver、Processor、Exporter を使用してデータを収集・分析する -- OpenTelemetry を使用するメリットを理解する -- ビジネスニーズを解決するカスタムコンポーネントを構築する - -## OpenTelemetry アーキテクチャ - -{{< mermaid >}} -%%{ - init:{ - - "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/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/extensionz.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/extensionz.png deleted file mode 100644 index d543bed0a9..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/extensionz.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/menu-dashboards.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/menu-dashboards.png deleted file mode 100644 index 5bb91aa46a..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/menu-dashboards.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/otel-charts.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/otel-charts.png deleted file mode 100644 index d956d99570..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/otel-charts.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/otelbin.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/otelbin.png deleted file mode 100644 index aaf680218a..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/otelbin.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/participant-dashboard.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/participant-dashboard.png deleted file mode 100644 index 77ecc28985..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/participant-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/pipelinez-full-config.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/pipelinez-full-config.png deleted file mode 100644 index 31a3b4035c..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/pipelinez-full-config.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/pipelinez.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/pipelinez.png deleted file mode 100644 index 560c1e64eb..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/pipelinez.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/search-dashboards.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/search-dashboards.png deleted file mode 100644 index 272ec63d05..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/search-dashboards.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/select-participant-name.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/select-participant-name.png deleted file mode 100644 index 694ee7381a..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/select-participant-name.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/servicez.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/servicez.png deleted file mode 100644 index d96a04bb39..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/1-opentelemetry-collector/images/servicez.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md deleted file mode 100644 index bdcf71526b..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-1-gateway.md +++ /dev/null @@ -1,151 +0,0 @@ ---- -title: 1.1 Gateway 設定の確認 -linkTitle: 1.1 Gateway Configuration -weight: 1 ---- - -**OpenTelemetry Gateway** は、テレメトリーデータの受信、処理、エクスポートのための中央ハブとして機能します。テレメトリーソース（アプリケーションやサービスなど）と Splunk Observability Cloud のようなオブザーバビリティバックエンドの間に位置します。 - -テレメトリートラフィックを集中化することで、Gateway はデータのフィルタリング、エンリッチメント、変換、および1つ以上の宛先へのルーティングなどの高度な機能を実現します。個々のサービスからテレメトリー処理をオフロードすることで負担を軽減し、分散システム全体で一貫した標準化されたデータを確保します。 - -これにより、オブザーバビリティパイプラインの管理、スケーリング、分析が容易になります。特に複雑なマルチサービス環境では効果的です。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -2つ目のターミナルウィンドウを開くか作成し、**Gateway** と名前を付けます。最初の演習ディレクトリ `[WORKSHOP]/1-agent-gateway` に移動し、`gateway.yaml` ファイルの内容を確認します。 - -このファイルは、**Gateway** モードでデプロイされた OpenTelemetry Collector のコア構造を示しています。 - - -{{% /notice %}} - -### Gateway 設定の理解 - -このワークショップで **Gateway** モードの OpenTelemetry Collector がどのように設定されているかを定義する `gateway.yaml` ファイルを確認しましょう。この **Gateway** は、**Agent** からテレメトリーを受信し、処理してから検査または転送のためにエクスポートする役割を担います。 - -* **OTLP Receiver（カスタムポート）** - - ```yaml - receivers: - otlp: - protocols: - http: - endpoint: "0.0.0.0:5318" - ``` - - ポート `5318` は **Agent** 設定の `otlphttp` Exporter と一致しており、**Agent** が送信するすべてのテレメトリーデータが **Gateway** で受け入れられることを保証します。 - -> [!NOTE] -> このポートの分離により、競合を回避し、Agent と Gateway の役割間の責任を明確に保ちます。 - -* **File Exporter** - - **Gateway** は3つの File Exporter を使用して、テレメトリーデータをローカルファイルに出力します。これらの 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 - ``` - - 各 Exporter は、特定のシグナルタイプを対応するファイルに書き込みます。 - - これらのファイルは Gateway が起動すると作成され、Agent がデータを送信すると実際のテレメトリーが書き込まれます。これらのファイルをリアルタイムで監視して、パイプラインを通過するテレメトリーの流れを観察できます。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md deleted file mode 100644 index 7509fd5fe8..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-2-send-metrics.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: 1.2 設定の検証とテスト -linkTitle: 1.2 Validate & Test Configuration -weight: 3 ---- - -次に、**Gateway** と **Agent** を起動します。**Agent** は起動時に自動的に **Host Metrics** を送信するよう設定されています。これにより、データが **Agent** から **Gateway** に正しくルーティングされることを確認します。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -**Gateway**: **Gateway ターミナル** ウィンドウで、以下のコマンドを実行して **Gateway** を起動します - -```bash {title="Start the Gateway"} -../otelcol --config=gateway.yaml -``` - -すべてが正しく設定されている場合、Collector が起動し、出力に `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 ターミナル** ウィンドウで、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時間ごとまたは再起動ごとに **CPU** メトリクスを収集し、Gateway に送信し続けます。**Gateway** はこれらのメトリクスを処理し、`gateway-metrics.out` という名前のファイルにエクスポートします。このファイルは、パイプラインサービスの一部としてエクスポートされたメトリクスを保存します。 - -**Gateway にデータが到着したことの確認**: CPU メトリクス（特に `cpu0`）が Gateway に正常に到達したことを確認するために、`jq` コマンドを使用して `gateway-metrics.out` ファイルを検査します。 - -以下のコマンドは、`system.cpu.time` メトリクスをフィルタリングして抽出し、`cpu0` に焦点を当てます。メトリクスの状態（例：`user`、`system`、`idle`、`interrupt`）と対応する値を表示します。 - -3つ目のターミナルウィンドウを開くか作成し、**Tests** と名前を付けます。**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 %}} - -> [!IMPORTANT] -> **Agent** と **Gateway** のプロセスを、それぞれのターミナルで `Ctrl-C` を押して停止してください。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md deleted file mode 100644 index 1a612c41ca..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-3-send-traces.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: 1.3 Agent から Gateway へトレースを送信 -linkTitle: 1.3 Send Traces -weight: 4 -hidden: true -draft: true ---- - -{{% notice title="Exercise" style="green" icon="running" %}} - -**テストトレースの送信**: - -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 %}} - - - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md deleted file mode 100644 index 5d58fd19da..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/1-4-send-logs.md +++ /dev/null @@ -1,154 +0,0 @@ ---- -title: 1.4 ログの送信 -linkTitle: 1.4 Send Logs -weight: 5 -hidden: true -draft: true ---- - -{{% notice title="Exercise" style="green" icon="running" %}} - -**ログ Load Generator の起動:** **Loadgen ターミナル** ウィンドウで、以下のコマンドを実行して `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 ターミナル** ウィンドウで、`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] -> **Agent** と **Gateway** のプロセスを、それぞれのターミナルで `Ctrl-C` を押して停止してください。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md deleted file mode 100644 index 5400066163..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/1-agent-gateway/_index.md +++ /dev/null @@ -1,198 +0,0 @@ ---- -title: 1. Agent 設定の確認 -linkTitle: 1. Agent Configuration - - -time: 15 minutes -weight: 3 ---- -ようこそ！このセクションでは、**Agent** と **Gateway** の両方を含む完全に機能する OpenTelemetry セットアップから始めます。 - -まず、設定ファイルを簡単に確認して、全体的な構造に慣れ、テレメトリーパイプラインを制御する重要なセクションを確認します。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -ワークショップを通じて、複数のターミナルウィンドウを使用します。整理しやすくするために、各ターミナルに固有の名前または色を付けてください。これにより、演習中にターミナルを簡単に識別して切り替えることができます。 - -これらのターミナルを **Agent**、**Gateway**、**Loadgen**、**Test** と呼びます。 -{{% /notice %}} - -{{% notice title="Exercise" style="green" icon="running" %}} - -1. 最初のターミナルウィンドウを作成し、**Agent** と名前を付けます。最初の演習用ディレクトリ `[WORKSHOP]/1-agent-gateway` に移動し、必要なファイルが生成されていることを確認します - - ```bash - cd 1-agent-gateway - ls -l - ``` - -2. ディレクトリに以下のファイルが表示されるはずです。表示されない場合は、**前提条件** セクションで説明されている `setup-workshop.sh` スクリプトを再実行してください - - ```text { title="Directory Structure" } - . - ├── agent.yaml - └── gateway.yaml - ``` - -{{% /notice %}} - -### Agent 設定の理解 - -このワークショップで使用する `agent.yaml` ファイルの主要なコンポーネントを確認しましょう。メトリクス、トレース、ログをサポートするために重要な追加が行われています。 - -#### Receiver - -`receivers` セクションは、**Agent** がテレメトリーデータを取り込む方法を定義します。このセットアップでは、3種類の Receiver が設定されています - -* **Host Metrics Receiver** - - ```yaml - hostmetrics: # Host Metrics Receiver - collection_interval: 3600s # Collection Interval (1hr) - scrapers: - cpu: # CPU Scraper - ``` - - ローカルシステムから1時間ごとに CPU 使用率を収集します。これを使用してサンプルメトリクスデータを生成します。 - -* **OTLP Receiver（HTTP プロトコル）** - - ```yaml - otlp: # OTLP Receiver - protocols: - http: # Configure HTTP protocol - endpoint: "0.0.0.0:4318" # Endpoint to bind to - ``` - - Agent がポート `4318` で HTTP 経由でメトリクス、トレース、ログを受信できるようにします。これは、今後の演習で Collector にデータを送信するために使用されます。 - -* **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 - ``` - - Agent がローカルログファイル（`quotes.log`）を tail し、`source` や `sourceType` などのメタデータで強化された構造化ログイベントに変換できるようにします。 - -#### Exporter - -* **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` Exporter はワークショップ中の可視性とデバッグのためにデータをコンソールに送信し、`otlphttp` Exporter はすべてのテレメトリーをローカルの **Gateway** インスタンスに転送します。 - - **このデュアルエクスポート戦略により、生データをローカルで確認しながら、さらなる処理とエクスポートのためにダウンストリームに送信することができます。** diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md deleted file mode 100644 index 7e952ce133..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-1-configuration.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: 2.1 File Storage の設定 -linkTitle: 2.1 Configuration -weight: 1 ---- - -この演習では、`agent.yaml` ファイルの `extensions:` セクションを更新します。このセクションは OpenTelemetry 設定 YAML の一部であり、OpenTelemetry Collector の動作を拡張または変更するオプションのコンポーネントを定義します。 - -これらのコンポーネントはテレメトリーデータを直接処理しませんが、Collector の機能を向上させる貴重な機能とサービスを提供します。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -> [!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 -``` - -{{% /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 - 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; -``` diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md deleted file mode 100644 index e859e3108f..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-2-test-environment.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: 2.2 耐障害性テスト用の環境セットアップ -linkTitle: 2.2 Setup environment -weight: 2 ---- - -次に、**File Storage** 設定をテストする準備として環境を設定します。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -**Gateway の起動**: **Gateway ターミナル** ウィンドウで以下を実行します - -```bash { title="Start the Gateway" } -../otelcol --config=gateway.yaml -``` - -**Agent の起動**: **Agent ターミナル** ウィンドウで以下を実行します - -```bash { title="Start the Agent" } -../otelcol --config=agent.yaml -``` - -**5つのテストスパンを送信**: **Loadgen ターミナル** ウィンドウで以下を実行します - -```bash { title="Start Load Generator" } -../loadgen -count 5 -``` - -**Agent** と **Gateway** の両方がデバッグログを表示し、**Gateway** が `./gateway-traces.out` ファイルを作成するはずです。 - -すべてが正常に機能している場合、システムの耐障害性のテストに進むことができます。 -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md deleted file mode 100644 index 944b5541d5..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-3-failure.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: 2.3 障害のシミュレーション -linkTitle: 2.3 Simulate Failure -weight: 3 ---- - -**Agent** の耐障害性を評価するために、一時的な **Gateway** の停止をシミュレートし、**Agent** がそれをどのように処理するかを観察します - -{{% notice title="Exercise" style="green" icon="running" %}} - -**ネットワーク障害のシミュレーション**: **Gateway ターミナル** で `Ctrl-C` を使用して **Gateway** を停止し、Gateway のコンソールが停止したことを示すまで待ちます。**Agent** は引き続き実行されますが、Gateway にデータを送信できません。**Gateway ターミナル** の出力は以下のようになります - -```text -2025-07-09T10:22:37.941Z info service@v0.126.0/service.go:345 Shutdown complete. {"resource": {}} -``` - -**トレースの送信**: **Loadgen ターミナル** ウィンドウで、`loadgen` を使用してさらに5つのトレースを送信します。 - -```bash { title="Start Load Generator" } -../loadgen -count 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 ターミナル** ウィンドウで、`Ctrl-C` を使用して Agent を停止します。Agent のコンソールが停止を確認するまで待ちます - -```text -2025-07-09T10:25:59.344Z info service@v0.126.0/service.go:345 Shutdown complete. {"resource": {}} -``` - -{{% /notice %}} - -> [!IMPORTANT] -> Agent を停止すると、リトライ用にメモリに保持されているメトリクス、トレース、ログは失われます。ただし、FileStorage Extension を設定しているため、ターゲットエンドポイントでまだ受け入れられていないすべてのテレメトリーはディスクに安全にチェックポイントされています。 -> -> Agent の停止は、Agent が再起動されたときにシステムがどのように復旧するかを明確に示すための重要なステップです。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md deleted file mode 100644 index 32fce7ffa3..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/2-4-recovery.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: 2.4 復旧 -linkTitle: 2.4 Recovery -weight: 4 ---- - -この演習では、**Gateway** Collector を再起動することで、**OpenTelemetry Collector** がネットワーク障害からどのように復旧するかをテストします。**Gateway** が再び利用可能になると、**Agent** は最後にチェックポイントされた状態からデータの送信を再開し、データ損失がないことを保証します。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -**Gateway の再起動**: **Gateway ターミナル** ウィンドウで以下を実行します - -```bash {title="Start the Gateway"} -../otelcol --config=gateway.yaml -``` - -**Agent の再起動**: **Agent ターミナル** ウィンドウで以下を実行します - -```bash { title="Start the Agent" } -../otelcol --config=agent.yaml -``` - -> **Agent** が起動して実行されると、**File_Storage** Extension がチェックポイントフォルダー内のバッファされたデータを検出します。最後のチェックポイントフォルダーから保存されたスパンをデキューし始め、データが失われないことを保証します。 - -**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 %}} - -{{% /notice %}} - -> [!IMPORTANT] -> **Agent** と **Gateway** のプロセスを、それぞれのターミナルで `Ctrl-C` を押して停止してください。 - -### まとめ - -この演習では、`file_storage` Extension の設定、`otlp` Exporter のリトライメカニズムの有効化、および一時的なデータ保存用のファイルベースのキューの使用により、OpenTelemetry Collector の耐障害性を強化する方法を示しました。 - -ファイルベースのチェックポイントとキューの永続化を実装することで、テレメトリーパイプラインが一時的な中断から適切に復旧できることを保証し、本番環境でより堅牢で信頼性の高いものにします。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md deleted file mode 100644 index 59d6aecb96..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/2-building-resilience/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: 2. 耐障害性の構築 -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/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md deleted file mode 100644 index fdec2a5b7d..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-1-configuration.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: 3.1 設定 -linkTitle: 3.1 設定 -weight: 1 ---- - -{{% notice title="Exercise" style="green" icon="running" %}} - -**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. **`traces` パイプラインに `filter` プロセッサを追加する** - `traces` パイプラインに `filter/health` プロセッサを追加します。最適なパフォーマンスを得るために、フィルターはできるだけ早い段階に配置します。`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`）がパイプラインの早い段階でフィルタリングされ、テレメトリーデータの不要なノイズが削減されます。 - -{{% /notice %}} - -**[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/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md deleted file mode 100644 index 9172623ff2..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/3-2-test-filter.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -title: 3.2 Filter Processorのテスト -linkTitle: 3.2 Filter Processorのテスト -weight: 2 ---- - -設定をテストするには、`"/_healthz"` という名前のSpanを含むトレースデータを生成する必要があります。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -**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 -``` - -これらは、先ほど設定したFilter Processorによってドロップされるため、**Gateway** のデバッグ出力には表示されません。 - -**`agent.out` を確認する**：**Test terminal** で `jq` を使用して、**Agent** が受信したSpanの名前を確認します - -{{% 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** が受信したSpanの名前を確認します - -{{% tabs %}} -{{% tab title="Check spans in gateway-traces.out" %}} - -```bash -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` という名前の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 %}} - -{{% /notice %}} - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} - -Filter Processorで最適なパフォーマンスを確保するには、受信データの形式を十分に理解し、設定を厳密にテストしてください。**できるだけ具体的なフィルタリング条件を使用**して、重要なデータを誤ってドロップするリスクを最小限に抑えてください。 - -この設定は、さまざまな属性、タグ、またはカスタム条件に基づいてSpanをフィルタリングするように拡張でき、特定のオブザーバビリティ要件に合わせて OpenTelemetry Collector の柔軟性と効率を向上させることができます。 -{{% /notice %}} - -> [!IMPORTANT] -> **Agent** と **Gateway** プロセスを、それぞれのターミナルで `Ctrl-C` を押して停止してください。 - - diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md deleted file mode 100644 index 180c49ce69..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/3-dropping-spans/_index.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: 3. Spanのドロップ -linkTitle: 3. Spanのドロップ -time: 5 minutes -weight: 5 ---- - -このセクションでは、[**Filter Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/filterprocessor/README.md) を使用して、特定の条件に基づいてSpanを選択的にドロップする方法を説明します。 - -具体的には、Span名に基づいてトレースをドロップします。これは、ヘルスチェックや内部通信トレースなどの不要なSpanをフィルタリングするためによく使用されます。今回は、ヘルスチェックリクエストに関連付けられることが多く、通常は非常に「**ノイジー**」な `"/_healthz"` を含むSpanをフィルタリングします。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -> [!IMPORTANT] -> **すべてのターミナルウィンドウを `3-dropping-spans` ディレクトリに移動し、`clear` コマンドを実行してください。** - -`2-building-resilience` ディレクトリから `*.yaml` を `3-dropping-spans` にコピーします。更新後のディレクトリ構造は次のようになります - -```text { title="Updated Directory Structure" } -. -├── agent.yaml -└── gateway.yaml -``` - -{{% /notice %}} - -次に、**filter processor** と対応するパイプラインを設定します。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md deleted file mode 100644 index 79cfb38423..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-1-configuration.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: 4.1 設定 -linkTitle: 4.1 設定 -weight: 1 ---- - -このステップでは、`agent.yaml` を修正して `attributes` と `redaction` プロセッサを追加します。これらのプロセッサは、Span属性内の機密データがログに記録またはエクスポートされる前に適切に処理されるようにします。 - -以前、コンソールに表示されたSpan属性の一部に個人情報や機密データが含まれていることに気づいたかもしれません。これから、この情報を効果的にフィルタリングおよび秘匿化するために必要なプロセッサを設定します。 - -```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="Exercise" style="green" icon="running" %}} - -**Agent terminal** ウィンドウに切り替えて、エディタで `agent.yaml` ファイルを開きます。テレメトリーデータのセキュリティとプライバシーを強化するために、2つのプロセッサを追加します。 - -**1. `attributes` プロセッサを追加する**：[**Attributes Processor**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor) を使用すると、Span属性（タグ）の値を更新、削除、またはハッシュ化して変更できます。これは、機密情報をエクスポートする前に難読化する場合に特に便利です。 - -このステップでは - -1. `user.phone_number` 属性を静的な値（`"UNKNOWN NUMBER"`）に**更新**します。 -2. `user.email` 属性を**ハッシュ化**して、元のメールアドレスが公開されないようにします。 -3. `user.password` 属性を**削除**して、Spanから完全に取り除きます。 - -```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）などの定義済みパターンに基づいて、Span属性内の機密データを検出して秘匿化します。 - -このステップでは - -- すべての属性が処理されるように `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 -``` - -{{% /notice %}} - -**[otelbin.io](https://www.otelbin.io/)** を使用してAgent設定を検証します。参考として、パイプラインの `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/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md deleted file mode 100644 index f3fe3a4983..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-2-test-delete-tag.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: 4.2 Attribute Processorのテスト -linkTitle: 4.2 Attribute Processorのテスト -weight: 2 ---- - -この演習では、**Agent** がエクスポートする前に、Spanデータから `user.account_password` を**削除**し、`user.phone_number` **属性**を**更新**し、`user.email` を**ハッシュ化**します。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -**Gatewayを起動する**：**Gateway terminal** ウィンドウで **Gateway** を起動します。 - -```bash -../otelcol --config=gateway.yaml -``` - -**Agentを起動する**：**Agent terminal** ウィンドウで **Agent** を起動します。 - -```bash -../otelcol --config=agent.yaml -``` - -**Load Generatorを起動する**：**Loadgen 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-traces.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] -> **Agent** と **Gateway** プロセスを、それぞれのターミナルで `Ctrl-C` を押して停止してください。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md deleted file mode 100644 index 2bc028b520..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/4-3-test-redaction.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -title: 4.3 Redaction Processorのテスト -linkTitle: 4.3 Redaction Processorのテスト -weight: 3 ---- - -`redaction` プロセッサは、テレメトリーデータからどの属性と値を**許可**または**削除**するかを正確に制御できます。 - -この演習では、**Agent** がエクスポートする前に、Spanデータの `user.visa` と `user.mastercard` の値を**秘匿化**します。 -{{% notice title="Exercise" style="green" icon="running" %}} - -**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="New Debug Output" %}} - - ```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="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(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="Validate attribute changes" %}} - -```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="Output" %}} - -`blocked_values` に一致する正規表現パターンが追加されていないため、`user.amex` は秘匿化されていないことに注意してください - -```json -{ - "key": "user.visa", - "value": "****" -} -{ - "key": "user.amex", - "value": "3782 822463 10005" -} -{ - "key": "user.mastercard", - "value": "****" -} -``` - -{{% /tab %}} -{{% /tabs %}} - -これらは、`attributes` と `redaction` プロセッサを設定して機密データを保護する方法のほんの一例です。 - -{{% /notice %}} - -> [!IMPORTANT] -> **Agent** と **Gateway** プロセスを、それぞれのターミナルで `Ctrl-C` を押して停止してください。 - - diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md deleted file mode 100644 index 4069176ef8..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/4-sensitive-data/_index.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: 4. 機密データの秘匿化 -linkTitle: 4. 機密データ -time: 10 minutes -weight: 6 ---- - -このセクションでは、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="Exercise" style="green" icon="running" %}} - -> [!IMPORTANT] -> **すべてのターミナルウィンドウを `4-sensitive-data` ディレクトリに移動し、`clear` コマンドを実行してください。** - -`3-dropping-spans` ディレクトリから `*.yaml` を `4-sensitive-data` にコピーします。更新後のディレクトリ構造は次のようになります - -```text { title="Updated Directory Structure" } -. -├── agent.yaml -└── gateway.yaml -``` - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md deleted file mode 100644 index c8dd91720f..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-1-configuration.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: 5.1 Configuration -linkTitle: 5.1 Configuration -weight: 1 ---- - -{{% notice title="Exercise" style="green" icon="running" %}} -**`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] -> `resource` 用のコンテキストブロックと `log` 用のコンテキストブロックの2つを含む **単一の** `transform` プロセッサーが必要です。 - -この設定により、ログの重大度が正しく抽出、標準化され、効率的な処理のために構造化されます。 - -{{% notice title="Tip" 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 -``` - -{{% /notice %}} - -[**https://otelbin.io**](https://otelbin.io/) を使用して Agent の設定を検証します。参考として、パイプラインの `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/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md deleted file mode 100644 index 3f5ed5fcbf..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-2-setup.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: 5.2 Setup Environment -linkTitle: 5.2 Setup Environment -weight: 2 ---- - -{{% notice title="Exercise" 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 を起動する**: **Loadgen terminal** ウィンドウで、次のコマンドを実行して **JSON を有効**にした Load Generator を起動します - -```bash { title="Log Generator" } -../loadgen -logs -json -count 5 -``` - -`loadgen` は JSON 形式で 5 行のログを `./quotes.log` に書き込みます。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md deleted file mode 100644 index 7ac5a3b1ec..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/5-3-test-transform.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -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` に昇格していること - -これにより、エクスポート前に適切なメタデータフィルタリング、重大度マッピング、および構造化ログのエンリッチメントが行われることが保証されます。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -**デバッグ出力を確認する**: **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 %}} - -{{% /notice %}} - -> [!IMPORTANT] -> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止してください。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md deleted file mode 100644 index 16ec156b53..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/5-transform-data/_index.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -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を使用してテレメトリパイプラインレベルで自動的に変換できます。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -> [!IMPORTANT] -> **すべてのターミナルウィンドウを `5-transform-data` ディレクトリに移動し、`clear` コマンドを実行してください。** - -`4-sensitve-data` ディレクトリから `*.yaml` を `5-transform-data` にコピーします。更新後のディレクトリ構造は次のようになります - -```text { title="Updated Directory Structure" } -. -├── agent.yaml -└── gateway.yaml -``` - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md deleted file mode 100644 index a71618f16c..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-1-connector.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: 6.1 Configure the Routing Connector -linkTitle: 6.1 Routing Configuration -weight: 1 ---- - -この演習では、`gateway.yaml` で **Routing Connector** を設定します。Routing Connector はメトリクス、トレース、ログを任意の属性に基づいてルーティングできますが、ここでは `deployment.environment` 属性に基づくトレースルーティングに焦点を当てます（ただし、任意のスパン/ログ/メトリクス属性を使用できます）。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -**新しい `file` エクスポーターを追加する**: `routing` コネクターには、ルーティング用に異なるターゲットが必要です。**Gateway terminal** で、`gateway.yaml` の `exporters` セクションに 2 つの新しいファイルエクスポーター `file/traces/route1-regular` と `file/traces/route2-security` を作成し、データが正しく振り分けられるようにします - -```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` コネクターを追加します。OpenTelemetry の設定ファイルでは、`connectors` はレシーバーやプロセッサーと同様に専用のセクションを持っています。 - -`#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 -``` - -{{% /notice %}} - -設定ファイルのデフォルトパイプラインは、キャッチオールとして機能します。ルーティングルールテーブルのルールに一致しないすべてのデータ（この場合はスパン）のルーティング先となります。このテーブルには、`["deployment.environment"] == "security-applications"` ルールに一致するスパンのターゲットパイプラインが定義されています。 - -`routing` の設定が完了したら、次のステップはこれらのルーティングルールを適用する `pipelines` を設定することです。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md deleted file mode 100644 index cae8d0dc3b..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-2-pipelines.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: 6.2 Configuring the Pipelines -linkTitle: 6.2 Pipeline Configuration -weight: 2 ---- - -{{% notice title="Exercise" style="green" icon="running" %}} - -**元の `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` を使用し、元の traces パイプラインからの `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 - ``` - -{{% /notice %}} - -**[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 - 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/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md deleted file mode 100644 index 48bcca35ac..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/6-3-test-routing.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: 6.3 Test Routing Connector -linkTitle: 6.3 Test Routing Connector -weight: 3 ---- - -{{% notice title="Exercise" style="green" icon="running" %}} - -このセクションでは、**Gateway** 用に設定した `routing` ルールをテストします。期待される結果は、`"[deployment.environment"] == "security-applications"` ルールに一致する `loadgen` によって生成された `span` が `gateway-traces-route2-security.out` ファイルに送信されることです。 - -**Gateway を起動する**: **Gateway terminal** ウィンドウで **Gateway** を起動します。 - -```bash -../otelcol --config gateway.yaml -``` - -**Agent を起動する**: **Agent terminal** ウィンドウで **Agent** を起動します。 - -```bash -../otelcol --config agent.yaml -``` - -**通常のスパンを送信する**: **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 %}} - -**セキュリティスパンを送信する**: **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 %}} - -このシナリオを複数回繰り返すことができ、各トレースは対応する出力ファイルに書き込まれます。 - -{{% /notice %}} - -> [!IMPORTANT] -> それぞれのターミナルで `Ctrl-C` を押して、**Agent** と **Gateway** のプロセスを停止してください。 - -## まとめ - -このセクションでは、異なるスパンを送信し、その宛先を確認することで、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/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md deleted file mode 100644 index d7a4cd938f..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/6-routing-data/_index.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: 6. Routing Data -linkTitle: 6. Routing Data -time: 10 minutes -weight: 8 ---- - -OpenTelemetry の [**Routing Connector**](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/routingconnector) は、特定の条件に基づいてデータ（`traces`、`metrics`、または `logs`）を異なるパイプライン/宛先に振り分けることができる強力な機能です。これは、テレメトリデータのサブセットに異なる処理やエクスポートロジックを適用したい場合に特に有用です。 - -例えば、*本番環境* のデータを1つのエクスポーターに送信し、*テスト* や *開発* のデータを別のエクスポーターに振り分けることができます。同様に、サービス名、環境、スパン名などの属性に基づいて特定のスパンをルーティングし、カスタムの処理やストレージロジックを適用することもできます。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -> [!IMPORTANT] -> **すべてのターミナルウィンドウを `6-routing-data` ディレクトリに移動し、`clear` コマンドを実行してください。** - -`5-transform-data` ディレクトリから `*.yaml` を `6-routing-data` にコピーします。更新後のディレクトリ構造は次のようになります - -```text { title="Updated Directory Structure" } -. -├── agent.yaml -└── gateway.yaml -``` - -{{% /notice %}} - -次に、Routing Connector とそれぞれのパイプラインを設定します。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md deleted file mode 100644 index 75164e6d53..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-1-count-test.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: 7.1 Count Connector のテスト -linkTitle: 7.1 Test Count Connector -weight: 1 ---- - -{{% notice title="Exercise" 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 -``` - -**Loadgen で12行のログを送信する** -**Spans terminal** ウィンドウで、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="Tip" 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/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md deleted file mode 100644 index f9905aac37..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-2-sum.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -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 を活用して合計請求額をメトリクスとして取得します。 - -この connector は、スパン、スパンイベント、メトリクス、データポイント、およびログレコードから属性値を収集（**sum**）するために使用できます。各個別の値をキャプチャし、メトリクスに変換して転送します。ただし、これらのメトリクスと属性を使用して計算やさらなる処理を行うのは**バックエンド**の役割です。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -**Agent terminal** ウィンドウに切り替えて、エディターで `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** connector は `user.card-charge` というメトリクスを生成し、`user.name` を属性として含めます。これにより、バックエンドは請求サイクルなどの長期間にわたってユーザーの合計請求額を追跡して表示できます。 - -以下のパイプライン設定では、connector exporter が traces セクションに追加され、connector receiver が metrics セクションに追加されています。 - -{{% notice title="Exercise" 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/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md deleted file mode 100644 index cef3e222e8..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/7-3-sum-test.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: 7.3 Sum Connector のテスト -linkTitle: 7.3 Test Sum Connector -weight: 3 ---- - -{{% notice title="Exercise" 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 -``` - -**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** のプロセスを停止してください。 - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md deleted file mode 100644 index a734b2e20c..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/7-sum-count/_index.md +++ /dev/null @@ -1,192 +0,0 @@ ---- -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」の名言の数を追跡し、測定可能なデータポイントに変換します。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -> [!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 -``` - -{{% /notice %}} - -遅延を設定する理由は、OpenTelemetry Collector の Count Connector が各処理インターバル内でのみログをカウントするためです。つまり、データが読み取られるたびに、次のインターバルでカウントがゼロにリセットされます。デフォルトの `Filelog receiver` インターバル 200ms では、loadgen が書き込むすべての行を読み取り、カウントが1になります。このインターバルを設定することで、複数のエントリをカウントできるようになります。 - -以下に示すように、条件を省略することで、Collector は各読み取りインターバルの累計カウントを維持できます。ただし、バックエンドは長期間にわたってカウントを追跡できるため、累計カウントはバックエンドに任せるのがベストプラクティスです。 - -{{% notice title="Exercise" 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 を設定する** -以下のパイプライン設定では、connector exporter が `logs` セクションに追加され、connector receiver が `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` プロセッサーを使用して、キー/バリューのペアを抽出し、属性として追加する必要があります。 - -このワークショップでは、`05-transform-data` セクションで既に `merge_maps(attributes, cache, "upsert")` を追加しています。これにより、関連するすべてのデータが処理用のログ属性に含まれるようになります。 - -属性を作成するフィールドを選択する際は注意が必要です。すべてのフィールドを無差別に追加することは、本番環境では一般的に理想的ではありません。不要なデータの乱雑さを避けるため、本当に必要なフィールドのみを選択してください。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -- **[otelbin.io](https://www.otelbin.io/)** を使用して agent 設定を**検証**してください。参考として、パイプラインの `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/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md deleted file mode 100644 index 7825ab5d76..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/8-wrap-up/_index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: 8. まとめ -linkTitle: 8. Wrap-up -weight: 10 ---- - -![Well done](../images/welldone.png) diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md deleted file mode 100644 index fe2eeb2f19..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/_index.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: Advanced OpenTelemetry Collector -description: OpenTelemetry Collector の設定をゼロから行う練習を行い、いくつかの高度な設定シナリオを体験します。 -weight: 2 -archetype: chapter -authors: ["Robert Castley", "Charity Anderson", "Pieter Hagen", "Geoff Higginbottom"] -time: 75 minutes ---- - -このワークショップの目的は、OpenTelemetry Collector の設定ファイルを作成・変更する際の自信を深めることです。最小限の `agent.yaml` と `gateway.yaml` ファイルから始め、いくつかの高度な実際のシナリオに対応できるよう段階的に構築していきます。 - -このワークショップの重要なポイントは、テレメトリーデータをサードパーティベンダーのバックエンドに送信するのではなく、ローカルに保存するよう OpenTelemetry Collector を設定する方法を学ぶことです。このアプローチはデバッグやトラブルシューティングを簡素化するだけでなく、本番システムへのデータ送信を避けたいテストや開発環境にも最適です。 - -このワークショップを最大限に活用するために、以下の知識が必要です - -- OpenTelemetry Collector とその設定ファイル構造の基本的な理解 -- YAML ファイルの編集スキル - -このワークショップのすべての内容はローカルで実行できるよう設計されており、実践的でアクセスしやすい学習体験を提供します。それでは、構築を始めましょう！ - -## ワークショップの概要 - -このワークショップでは、以下のトピックを取り上げます - -- **Agent と Gateway をローカルでセットアップ**: メトリクス、トレース、ログが Agent 経由で Gateway に送られることをテストします。 -- **Agent の耐障害性を強化**: フォールトトレランスのための基本設定を行います。 -- **Processor の設定**: - - 特定のスパン（例：ヘルスチェック）をドロップしてノイズをフィルタリングします。 - - 不要なタグを削除し、機密データを処理します。 - - エクスポート前にパイプラインで OTTL（OpenTelemetry Transformation Language）を使用してデータを変換します。 -- **Connector の設定**: - - 受信した値に基づいて、データを異なるエンドポイントにルーティングします。 - - -このワークショップを終了すると、さまざまな実際のユースケースに対応する OpenTelemetry Collector の設定に精通しているでしょう。 diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/images/welldone.png b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/images/welldone.png deleted file mode 100644 index b041ff09bf..0000000000 Binary files a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/images/welldone.png and /dev/null differ diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md deleted file mode 100644 index fc84050d8d..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/2-advanced-collector/prerequisites.md +++ /dev/null @@ -1,192 +0,0 @@ ---- -title: 前提条件 -weight: 2.1 -archetype: chapter -time: 5 minutes ---- - -### 前提条件 - -- `vi`、`vim`、`nano`、またはお好みのテキストエディタを使用して YAML ファイルを編集するスキル -- サポートされている環境 - - 提供される Splunk Workshop インスタンス（推奨）。`ssh` アクセス用にポート `2222` への外部アクセスが必要です。 - - Apple Mac（Apple Silicon）。`jq` のインストールが必要です - [**https://jqlang.org/download/**](https://jqlang.org/download/) - -{{% notice title="Exercise" style="green" icon="running" %}} - -**ディレクトリの作成**: 環境内で新しいディレクトリを作成し、そのディレクトリに移動します - -``` 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 %}} - -**ワークショップバイナリのダウンロード**: `[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 %}} - - - -`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 -``` - - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/_index.md b/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/_index.md deleted file mode 100644 index 8b1a9dccd0..0000000000 --- a/content/ja/ninja-workshops/3-opentelemetry-collector-workshops/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: OpenTelemetry Collector ワークショップ -weight: 3 ---- - -{{% children type="card" depth="1" description="true" %}} diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md b/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md deleted file mode 100644 index 01f78b68ee..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/1-recording-a-test.md +++ /dev/null @@ -1,186 +0,0 @@ ---- -title: 1.1 テストの記録 -weight: 1 ---- - -## 開始 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 を開く - -次に、（上記で開いた新しいタブで）Developer Toolsを開きます。Windowsでは `Ctrl + Shift + I`、Macでは `Cmd + Option + I` を押し、トップレベルメニューまたは **More tools** フライアウトメニューから **Recorder** を選択します。 - -![Open Recorder](../../img/open-recorder.png) - -{{% notice title="注意" style="info" %}} -サイトの要素はビューポートの幅によって変わる場合があります。記録する前に、作成するテストの種類（デスクトップ、タブレット、モバイル）に応じてブラウザウィンドウを適切な幅に設定してください。必要に応じて、DevToolsの「dock side」を別ウィンドウとしてポップアウトさせると便利です。 -{{% /notice %}} - -## 新しい記録を作成 - -DevToolsウィンドウでRecorderパネルを開いた状態で、{{% button style="blue" %}}Create a new recording{{% /button %}} ボタンをクリックして開始します。 - -![Recorder](../../img/recorder.png) - -**Recording Name** には、イニシャルを接頭辞として使用します（例: **`` - Online Boutique**）。**Start Recording** をクリックして、アクションの記録を開始します。 - -![Recording Name](../../img/recording-name.png) - -記録が開始されたら、サイトで以下のアクションを実行します: - -- **Vintage Camera Lens** をクリック -- **Add to Cart** をクリック -- **Place Order** をクリック -- Recorderパネルの **End recording** をクリック - -![End Recording](../../img/end-recording.png) - -## 記録のエクスポート - -**Export** ボタンをクリックします: - -![Export button](../../img/export-button.png) - -フォーマットとして **JSON** を選択し、**Save** をクリックします。 - -![Export JSON](../../img/export-json.png) - -![Save JSON](../../img/save-json.png) - -**おめでとうございます！** Chrome DevTools Recorderを使用した記録の作成に成功しました。次に、この記録を使用してSplunk Synthetic MonitoringでReal Browser Testを作成します。 - ---- - -{{% expand "JSONファイルを表示するにはここをクリック" %}} - -```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/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md b/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md deleted file mode 100644 index 8e2d7c55a5..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/2-create-real-browser-test.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: 1.2 Real Browser Test の作成 -weight: 2 ---- - -Splunk Observability Cloudで **Synthetics** に移動し、{{% button style="blue" %}}Add new test{{% /button %}} をクリックします。 - -ドロップダウンから **Browser test** を選択します。 - -![Add new test](../../img/add-new-test.png) - -**Browser test content** 設定ページが表示されます。 - -![New Test](../../img/new-test.png) diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/3-import-json.md b/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/3-import-json.md deleted file mode 100644 index b18580f5d4..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/3-import-json.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: 1.3 JSON のインポート -weight: 3 ---- - -テストの設定を開始するには、Chrome DevTools RecorderからエクスポートしたJSONをインポートする必要があります。{{% button %}}**Import**{{% /button %}} ボタンを有効にするには、まずテストに名前を付ける必要があります（例: **`` - Online Boutique**）。 - -![Import](../../img/import.png) - -{{% button %}}**Import**{{% /button %}} ボタンが有効になったら、クリックしてChrome DevTools RecorderからエクスポートしたJSONファイルをドロップするか、ファイルをアップロードします。 - -![Import JSON](../../img/import-json.png) - -JSONファイルがアップロードされたら、{{% button style="blue" %}}Continue to edit steps{{% /button %}} をクリックします。 - -![Import Complete](../../img/import-complete.png) - -![Edit Steps](../../img/edit-steps.png) - -テストを編集する前に、まず設定を構成します。{{% button style="blue" %}}< Return to test{{% /button %}} をクリックします。 diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md b/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md deleted file mode 100644 index 1841c186a1..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/4-edit-test-settings.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: 1.4 設定 -weight: 4 ---- - -シンプル設定では、テストの基本を構成できます: - -- **Name**: テストの名前（例: RWC - Online Boutique） -- **Details**: - - **Locations**: テストを実行するロケーション - - **Device**: 異なるデバイスと接続速度をエミュレート。選択したデバイスに合わせてビューポートも調整されます - - **Frequency**: テストの実行頻度 - - **Round-robin**: 複数のロケーションを選択した場合、すべてのロケーションで同時に実行するのではなく、一度に1つのロケーションからテストを実行します - - **Active**: テストをアクティブまたは非アクティブに設定 - -![Return to Test]このワークショップでは、モニタリングを行うロケーションを設定します。**Locations** フィールドをクリックすると、グローバルロケーションのリスト（合計50以上）が表示されます。 - -![Global Locations](../../img/global-locations.png) - -以下のロケーションを選択します: - -- **AWS - N. Virginia** -- **AWS - London** -- **AWS - Melbourne** - -完了したら、下にスクロールして {{% button style="blue" %}}Submit{{% /button %}} をクリックしてテストを保存します。 - -これで、選択した3つのロケーションから5分ごとにテストが実行されるようスケジュールされます。スケジュールの作成には数分かかります。 - -テストのスケジュール作成を待つ間、{{% button %}}Edit test{{% /button %}} をクリックしてAdvanced設定を確認しましょう。 diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md b/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md deleted file mode 100644 index ee03191d43..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/5-advanced-settings.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: 1.5 Advanced 設定 -weight: 5 ---- - -**Advanced** をクリックします。これらの設定はオプションで、テストをさらに詳細に構成するために使用できます。 - -{{% notice note %}} -このワークショップでは、これらの設定は情報提供のみを目的としており、実際には使用しません。 -{{% /notice %}} - -![Advanced Settings](../../img/advanced-settings.png) - -- **Security**: - - **TLS/SSL validation**: 有効にすると、SSL/TLS証明書の有効期限切れ、無効なホスト名、信頼できない発行者の検証を強制します - - **Authentication**: 企業ネットワーク内など、追加のセキュリティプロトコルを必要とするサイトで認証するための資格情報を追加します。Authenticationフィールドで [concealed global variables](https://docs.splunk.com/Observability/synthetics/test-config/global-variables.html) を使用することで、資格情報のセキュリティレイヤーを追加し、チェック間で資格情報を共有しやすくなります -- **Custom Content**: - - **Custom headers**: 各リクエストで送信するカスタムヘッダーを指定します。たとえば、リクエストに特定のヘッダーを送信することで、バックエンドの分析からリクエストを除外するヘッダーを追加できます。カスタムヘッダーを使用してCookieを設定することもできます - - **Cookies**: テスト開始前にブラウザにCookieを設定します。たとえば、ポップアップモーダルがランダムに表示されてテストに干渉するのを防ぐためにCookieを設定できます。設定されたCookieは、チェックの開始URLのドメインに適用されます。Splunk Synthetics Monitoringはpublic suffix listを使用してドメインを判定します - - **Host overrides**: あるホストから別のホストにリクエストをリルーティングするホストオーバーライドルールを追加します。たとえば、既存の本番サイトを開発サイトや特定のCDNエッジノードから読み込まれたページリソースに対してテストするホストオーバーライドを作成できます - -次に、テストステップを編集して、各ステップにより意味のある名前を付けます。 diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md b/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md deleted file mode 100644 index bfbf3adefe..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/6-edit-steps.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: 1.6 テストステップの編集 -weight: 6 ---- - -ステップを編集するには、{{< button >}}+ Edit steps or synthetic transactions{{< /button >}} ボタンをクリックします。ここから、各ステップに意味のある名前を付けていきます。 - -![Edit steps](../../img/edit-steps.png) - -4つのステップそれぞれに意味のある名前を付けます。 - -- **Step 1**: **Go to URL** というテキストを **HomePage - Online Boutique** に置き換えます -- **Step 2**: **Select Vintage Camera Lens** と入力します -- **Step 3**: **Add to Cart** と入力します -- **Step 4**: **Place Order** と入力します - -![Step names](../../img/step-names.png) - -{{% button style="blue" %}}< Return to test{{% /button %}} をクリックしてテスト設定ページに戻り、{{% button style="blue" %}}Save{{% /button %}} をクリックしてテストを保存します。 - -テストダッシュボードに戻り、テスト結果が表示され始めます。 - -![Scatterplot](../../img/scatterplot.png) - -**おめでとうございます！** Splunk Synthetic MonitoringでReal Browser Testの作成に成功しました。次に、テスト結果をより詳しく見ていきます。 diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/7-view-test-results.md b/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/7-view-test-results.md deleted file mode 100644 index 81b1ff2454..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/7-view-test-results.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: 1.7 テスト結果の表示 -weight: 7 ---- - -前のステップの散布図で、いずれかのドットをクリックしてテスト実行データにドリルダウンします。できれば、最新のテスト実行（最も右側）を選択してください。 - -![Drilldown](../../img/drilldown.png) diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/_index.md b/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/_index.md deleted file mode 100644 index e87d518a1d..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/1-real-browser-test/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: 1. Real Browser Test -weight: 1 ---- - -## はじめに - -このワークショップでは、[Chrome DevTools Recorder](https://developer.chrome.com/docs/devtools/recorder/) を使用して、Splunkデモインスタンスに対するSyntheticトランザクションを作成する方法を説明します。 - -Chrome DevTools RecorderからエクスポートしたJSONを使用して、Splunk Synthetic MonitoringのReal Browser Testを作成します。 - -また、[API Test](https://docs.splunk.com/Observability/synthetics/api-test/api-test.html) や [Uptime Test](https://docs.splunk.com/Observability/synthetics/uptime-test/uptime-test.html) など、他のSplunk Synthetic Monitoringチェックについても学びます。 - -## 前提条件 - -- Google Chromeブラウザがインストールされていること -- Splunk Observability Cloudへのアクセス権があること diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/1-global-varilables.md b/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/1-global-varilables.md deleted file mode 100644 index bbfbc11124..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/1-global-varilables.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Global Variables -linkTitle: 1.1 Global Variables -weight: 1 ---- - -## Global Variables - -APIテストを実行するために使用するグローバル変数を確認します。歯車アイコンの下にある **Global Variables** をクリックします。`env.encoded_auth` という名前のグローバル変数を使用して、Spotify APIトランザクションを構築します。 - -![placeholder](../../img/global-variables.png) diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/2-create-new-check.md b/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/2-create-new-check.md deleted file mode 100644 index e8c5ea0c27..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/2-create-new-check.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: 新しい API テストの作成 -linkTitle: 1.2 Create new API test -weight: 2 ---- - -## 新しい API テストを作成 - -{{< button style="blue" >}}Add new test{{< /button >}} ボタンをクリックし、ドロップダウンから **API test** を選択して新しいAPIテストを作成します。テスト名には **イニシャル** に続けて **Spotify API** と入力します（例: **RWC - Spotify API**）。 - -![placeholder](../../img/new-api-check.png) diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/3-authentication-request.md b/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/3-authentication-request.md deleted file mode 100644 index 99a40bf9d4..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/3-authentication-request.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: 認証リクエスト -linkTitle: 1.3 Authentication Request -weight: 3 ---- - -## 認証リクエストの追加 - -{{< button >}}+ Add requests{{< /button >}} をクリックし、リクエストステップ名を入力します（例: **Authenticate with Spotify API**）。 - -![placeholder](../../img/add-request.png) - -Requestセクションを展開し、ドロップダウンからリクエストメソッドを **POST** に変更して、以下のURLを入力します: - -``` text -https://accounts.spotify.com/api/token -``` - -**Payload body** セクションに以下を入力します: - -``` text -grant_type=client_credentials -``` - -次に、以下のキー/値のペアで2つのリクエストヘッダーを追加します: - -- **CONTENT-TYPE: application/x-www-form-urlencoded** -- **AUTHORIZATION: Basic {{env.encoded_auth}}** - -**Validation** セクションを展開し、以下の抽出を追加します: - -- **Extract** from **Response body** **JSON** **$.access_token** **as** **access_token** - -これにより、Spotify APIから受信したJSONペイロードを解析し、アクセストークンを抽出してカスタム変数として保存します。 - -![Add payload token](../../img/add-payload-token.png) diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/4-search-request.md b/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/4-search-request.md deleted file mode 100644 index b61b20ed74..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/4-search-request.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: 検索リクエスト -linkTitle: 1.4 Search Request -weight: 4 -hidden: false ---- - -## 検索リクエストの追加 - -{{< button >}}+ Add Request{{< /button >}} をクリックして次のステップを追加します。ステップ名を **Search for Tracks named "Up around the bend"** とします。 - -**Request** セクションを展開し、リクエストメソッドを **GET** に変更して、以下のURLを入力します: - -``` text -https://api.spotify.com/v1/search?q=Up%20around%20the%20bend&type=track&offset=0&limit=5 -``` - -次に、以下のキー/値のペアで2つのリクエストヘッダーを追加します: - -- **CONTENT-TYPE: application/json** -- **AUTHORIZATION: Bearer {{custom.access_token}}** - -![Add search request](../../img/add-search-request.png) - -**Validation** セクションを展開し、以下の抽出を追加します: - -- **Extract** from **Response body** **JSON** **$.tracks.items[0].id** **as** **track.id** - -![Add search payload](../../img/add-search-payload.png) - -{{< button style="blue" >}}< Return to test{{< /button >}} をクリックしてテスト設定ページに戻ります。次に {{< button style="blue" >}}Save{{< /button >}} をクリックしてAPIテストを保存します。 diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/5-view-results.md b/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/5-view-results.md deleted file mode 100644 index 6874cf5c23..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/5-view-results.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: 結果の表示 -linkTitle: 1.5 View Results -weight: 5 -hidden: false ---- - -## 結果の表示 - -テストがプロビジョニングされて実行されるまで数分待ちます。テストが正常に実行されたら、実行をクリックしてテスト結果を表示します: - -![API test result](../../img/api-test-result.png) - -## 6. リソース - -- [API テストの作成方法](https://docs.splunk.com/Observability/synthetics/api-test/set-up-api-test.html) - -- [API Test 概要](https://docs.splunk.com/Observability/synthetics/api-test/api-test.html) diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/_index.md b/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/_index.md deleted file mode 100644 index b65c1d61f4..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/2-api-test/_index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: API Test -linkTitle: 2. API Test -weight: 2 -hidden: false ---- - -API Testは、APIエンドポイントの機能とパフォーマンスを柔軟にチェックする方法を提供します。APIファーストの開発へのシフトにより、フロントエンドのコア機能を提供するバックエンドサービスをモニタリングする必要性が高まっています。 - -マルチステップのAPIインタラクションのテストに興味がある場合でも、エンドポイントのパフォーマンスを可視化したい場合でも、API Testは目標の達成を支援します。 - -![API test result](../img/api-test-result.png) diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/_index.md b/content/ja/ninja-workshops/4-synthetics-scripting/_index.md deleted file mode 100644 index f862dcfbf7..0000000000 --- a/content/ja/ninja-workshops/4-synthetics-scripting/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Splunk Synthetic Scripting -description: ユーザーフロー、ビジネストランザクション、API 全体のパフォーマンス問題をプロアクティブに検出・修正し、より優れたデジタルエクスペリエンスを提供します。 -weight: 4 -authors: ["Robert Castley"] -time: 45 minutes ---- - -問題がユーザーに影響を与える前に、Webアプリケーションのパフォーマンスをプロアクティブにモニタリングします。**Splunk Synthetic Monitoring** を使用すると、技術チームとビジネスチームは詳細なテストを作成し、開発サイクルのあらゆる段階でWebサイト、Webアプリケーション、リソースの速度と信頼性を継続的にモニタリングできます。 - -**Splunk Synthetic Monitoring** は、唯一の完全なオブザーバビリティスイートであるSplunk Observability Cloudの一部として、稼働時間とWebパフォーマンス最適化のための最も包括的で詳細な機能を提供します。 - -API、サービスエンドポイント、エンドユーザーエクスペリエンスのモニタリングを簡単にセットアップできます。**Splunk Synthetic Monitoring** を使用すると、基本的な稼働時間とパフォーマンスモニタリングを超えて、問題のプロアクティブな検出と修正、Webパフォーマンスの最適化、顧客への最高のユーザーエクスペリエンス提供に集中できます。 - -**Splunk Synthetic Monitoring** では以下のことが可能です: - -- 重要なユーザーフロー、ビジネストランザクション、APIエンドポイント全体で問題を迅速に検出・解決 -- インテリジェントなWeb最適化エンジンにより、Webパフォーマンスの問題が顧客に影響を与える前に防止 -- すべてのページリソースとサードパーティ依存関係のパフォーマンスを改善 diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-new-test.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/add-new-test.png deleted file mode 100644 index db155b191a..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-new-test.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-payload-token.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/add-payload-token.png deleted file mode 100644 index d9936e8df1..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-payload-token.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-request.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/add-request.png deleted file mode 100644 index cf94765b11..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-request.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-search-payload.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/add-search-payload.png deleted file mode 100644 index 0f78b64125..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-search-payload.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-search-request.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/add-search-request.png deleted file mode 100644 index c0aa94f678..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/add-search-request.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/advanced-settings.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/advanced-settings.png deleted file mode 100644 index e2e740845d..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/advanced-settings.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/api-test-result.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/api-test-result.png deleted file mode 100644 index f16af440ae..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/api-test-result.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/drilldown.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/drilldown.png deleted file mode 100644 index 94989c85c1..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/drilldown.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/edit-steps.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/edit-steps.png deleted file mode 100644 index 34bbffd1ee..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/edit-steps.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/end-recording.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/end-recording.png deleted file mode 100644 index 21c0f4e4ae..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/end-recording.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/export-button.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/export-button.png deleted file mode 100644 index 73e218b6ff..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/export-button.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/export-json.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/export-json.png deleted file mode 100644 index e10e22ee78..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/export-json.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/global-locations.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/global-locations.png deleted file mode 100644 index 0cfb9f6cff..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/global-locations.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/global-variables.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/global-variables.png deleted file mode 100644 index cb9a3c57b1..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/global-variables.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/import-complete.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/import-complete.png deleted file mode 100644 index 5021e13095..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/import-complete.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/import-json.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/import-json.png deleted file mode 100644 index 3fe2e2d38b..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/import-json.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/import.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/import.png deleted file mode 100644 index 085fbfab4d..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/import.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/new-api-check.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/new-api-check.png deleted file mode 100644 index c010820c5c..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/new-api-check.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/new-test.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/new-test.png deleted file mode 100644 index 554f2927cd..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/new-test.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/open-recorder.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/open-recorder.png deleted file mode 100644 index 91e5d1a7a3..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/open-recorder.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/recorder.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/recorder.png deleted file mode 100644 index 53577a052c..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/recorder.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/recording-name.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/recording-name.png deleted file mode 100644 index f81cd98103..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/recording-name.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/save-json.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/save-json.png deleted file mode 100644 index 230e021e9a..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/save-json.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/scatterplot.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/scatterplot.png deleted file mode 100644 index 862de9cb5b..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/scatterplot.png and /dev/null differ diff --git a/content/ja/ninja-workshops/4-synthetics-scripting/img/step-names.png b/content/ja/ninja-workshops/4-synthetics-scripting/img/step-names.png deleted file mode 100644 index 25b1245360..0000000000 Binary files a/content/ja/ninja-workshops/4-synthetics-scripting/img/step-names.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/1-setup.md b/content/ja/ninja-workshops/6-lambda-kinesis/1-setup.md deleted file mode 100644 index c9dcfa3a83..0000000000 --- a/content/ja/ninja-workshops/6-lambda-kinesis/1-setup.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -title: セットアップ -linkTitle: 1. セットアップ -weight: 1 ---- - -![手動計装されていないLambdaアプリケーション](../images/01-Architecture.png) - -## 前提条件 - -### Observability ワークショップインスタンス - -Observabilityワークショップは、多くの場合、Splunkが提供する事前設定済みのUbuntu EC2インスタンス上で実施されます。 - -ワークショップのインストラクターから、割り当てられたワークショップインスタンスの認証情報が提供されます。 - -インスタンスには以下の環境変数が既に設定されているはずです - -- **ACCESS_TOKEN** -- **REALM** - - _これらはワークショップ用の Splunk Observability Cloud の **Access Token** と **Realm** です。_ - - _これらは OpenTelemetry Collector によって、データを正しい Splunk Observability Cloud 組織に転送するために使用されます。_ - -> [!NOTE]\ -> _また、Multipass を使用してローカルの Observability ワークショップインスタンスをデプロイすることもできます。_ - -### AWS Command Line Interface (awscli) - -AWS Command Line Interface、または `awscli` は、AWSリソースと対話するために使用されるAPIです。このワークショップでは、特定のスクリプトがデプロイするリソースと対話するために使用されます。 - -Splunkが提供するワークショップインスタンスには、既に **awscli** がインストールされているはずです。 - -- インスタンスに **aws** コマンドがインストールされているか、次のコマンドで確認します - - ```bash - which aws - ``` - - - _予想される出力は **/usr/local/bin/aws** です_ - -- インスタンスに **aws** コマンドがインストールされていない場合は、次のコマンドを実行します - - ```bash - sudo apt install awscli - ``` - -### Terraform - -Terraformは、リソースを構成ファイルで定義することで、デプロイ、管理、破棄するためのInfrastructure as Code（IaC）プラットフォームです。TerraformはHCLを使用してこれらのリソースを定義し、さまざまなプラットフォームやテクノロジのための複数のプロバイダーをサポートしています。 - -このワークショップでは、コマンドラインでTerraformを使用して、以下のリソースをデプロイします - -1. AWS API Gateway -2. Lambda関数 -3. Kinesis Stream -4. CloudWatchロググループ -5. S3バケット - - _およびその他のサポートリソース_ - -Splunkが提供するワークショップインスタンスには、既に **terraform** がインストールされているはずです。 - -- インスタンスに **terraform** コマンドがインストールされているか確認します - - ```bash - which terraform - ``` - - - _予想される出力は **/usr/local/bin/terraform** です_ - -- インスタンスに **terraform** コマンドがインストールされていない場合は、以下のTerraformが推奨するインストールコマンドを実行してください - - ```bash - wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg - - echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list - - sudo apt update && sudo apt install terraform - ``` - -### ワークショップディレクトリ (o11y-lambda-workshop) - -ワークショップディレクトリ `o11y-lambda-workshop` は、今日使用する例のLambdaベースのアプリケーションの自動計装と手動計装の両方を完了するための、すべての設定ファイルとスクリプトを含むリポジトリです。 - -- ホームディレクトリにワークショップディレクトリがあることを確認します - - ```bash - cd && ls - ``` - - - _予想される出力には **o11y-lambda-workshop** が含まれるはずです_ - -- **o11y-lambda-workshop** ディレクトリがホームディレクトリにない場合は、次のコマンドでクローンします - -```bash -git clone https://github.com/gkono-splunk/o11y-lambda-workshop.git -``` - -### AWS & Terraform 変数 - -#### AWS - -AWSのCLIでは、サービスによってデプロイされたリソースにアクセスし管理するための認証情報が必要です。このワークショップでは、TerraformとPythonスクリプトの両方がタスクを実行するためにこれらの変数を必要とします。 - -- このワークショップのために **awscli** を _**access key ID**_、_**secret access key**_ および _**region**_ で構成します - - ```bash - aws configure - ``` - - - _このコマンドは以下のようなプロンプトを表示するはずです：_ - - ```bash - AWS Access Key ID [None]: XXXXXXXXXXXXXXXX - AWS Secret Acces Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - Default region name [None]: us-east-1 - Default outoput format [None]: - ``` - -- インスタンスで **awscli** が設定されていない場合は、次のコマンドを実行し、インストラクターから提供される値を入力してください。 - - ```bash - aws configure - ``` - -#### Terraform - -Terraformでは、機密情報や動的データを.tf設定ファイルにハードコーディングさせない、またはそれらの値をリソース定義全体で再利用できるようにするため、変数の受け渡しをサポートしています。 - -このワークショップでは、OpenTelemetry Lambda layerの適切な値でLambda関数をデプロイするため、Splunk Observability Cloudの取り込み値のため、そして環境とリソースを独自で即座に認識できるようにするための変数をTerraformで必要とします。 - -Terraform変数(variable)は以下の方法で定義されます - -- 変数を _**main.tf**_ ファイルまたは _**variables.tf**_ に定義する -- 以下のいずれかの方法で変数の値を設定する - - ホストレベルで環境変数を設定し、その定義と同じ変数名を使用して、接頭辞として _**TF_VAR**_ をつける - - _**terraform.tfvars**_ ファイルに変数の値を設定する - - terraform apply実行時に引数として値を渡す - -このワークショップでは、_**variables.tf**_ と _**terraform.tfvars**_ ファイルの組み合わせを使用して変数を設定します。 - -- **vi** または **nano** のいずれかを使用して、**auto** または **manual** ディレクトリにある _**terraform.tfvars**_ ファイルを開きます - - ```bash - vi ~/o11y-lambda-workshop/auto/terraform.tfvars - ``` - -- 変数に値を設定します。**CHANGEME** プレースホルダーをインストラクターから提供された値に置き換えてください。 - - ```bash - o11y_access_token = "CHANGEME" - o11y_realm = "CHANGEME" - otel_lambda_layer = ["CHANGEME"] - prefix = "CHANGEME" - ``` - - - _引用符（"）や括弧 ( [ ] ) はそのまま残し、プレースホルダー`CHANGEME` のみを変更してください。_ - - _**prefix**_ は、他の参加者のリソースと区別するため、任意の文字列で設定する固有の識別子です。氏名やメールアドレスのエイリアスを使用することをお勧めします。 - - _**prefix** には小文字のみを使用してください。S3 のような特定の AWS リソースでは、大文字を使用するとエラーが発生します。_ - -- ファイルを保存してエディタを終了します。 -- 最後に、編集した _**terraform.tfvars**_ ファイルを他のディレクトリにコピーします。 - - ```bash - cp ~/o11y-lambda-workshop/auto/terraform.tfvars ~/o11y-lambda-workshop/manual - ``` - - - _これは、自動計装と手動計装の両方の部分で同じ値を使用するためです_ - -### ファイル権限 - -他のすべてのファイルはそのままでよいですが、`auto` と `manual` の両方にある**send_message.py**スクリプトは、ワークショップの一部として実行する必要があります。そのため、期待通りに実行するには、適切な権限が必要です。以下の手順に従って設定してください。 - -- まず、`o11y-lambda-workshop` ディレクトリにいることを確認します - - ```bash - cd ~/o11y-lambda-workshop - ``` - -- 次に、以下のコマンドを実行して `send_message.py` スクリプトに実行権限を設定します - - ```bash - sudo chmod 755 auto/send_message.py manual/send_message.py - ``` - -これで前提条件が整いましたので、ワークショップを始めることができます！ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/2-auto-instrumentation.md b/content/ja/ninja-workshops/6-lambda-kinesis/2-auto-instrumentation.md deleted file mode 100644 index e3b4dd1c00..0000000000 --- a/content/ja/ninja-workshops/6-lambda-kinesis/2-auto-instrumentation.md +++ /dev/null @@ -1,285 +0,0 @@ ---- -title: 自動計装 -linkTitle: 2. 自動計装 -weight: 2 ---- - -ワークショップの最初の部分では、OpenTelemetryによる自動計装がどのようにしてOpenTelemetry Collectorに関数がどの言語で書かれているかを自動検出させ、それらの関数のトレースの取得を開始させるかを示します。 - -### 自動計装ワークショップディレクトリとコンテンツ - -まず、`o11y-lambda-workshop/auto` ディレクトリとそのファイルの一部を見てみましょう。ここにはワークショップの自動計装部分のすべてのコンテンツがあります。 - -#### `auto` ディレクトリ - -- 以下のコマンドを実行して **o11y-lambda-workshop/auto** ディレクトリに移動します - - ```bash - cd ~/o11y-lambda-workshop/auto - ``` - -- このディレクトリの内容を確認します - - ```bash - ls - ``` - - - _出力には以下のファイルとディレクトリが含まれるはずです：_ - - ```bash - handler outputs.tf terraform.tf variables.tf - main.tf send_message.py terraform.tfvars - ``` - - - _出力には以下のファイルとディレクトリが含まれるはずです：_ - - ```bash - get_logs.py main.tf send_message.py - handler outputs.tf terraform.tf - ``` - -#### `main.tf` ファイル - -- `main.tf` ファイルをより詳しく見てみましょう - - ```bash - cat main.tf - ``` - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} - -- このテンプレートによってどのAWSリソースが作成されているか特定できますか？ -- OpenTelemetry計装がどこでセットアップされているか特定できますか？ - - _ヒント: Lambda 関数の定義を調べてください_ -- 以前に設定した環境変数によってどの計装情報が提供されているか判断できますか？ - {{% /notice %}} - -各Lambda関数の環境変数が設定されているセクションが見つかるはずです。 - -```bash -environment { - variables = { - SPLUNK_ACCESS_TOKEN = var.o11y_access_token - SPLUNK_REALM = var.o11y_realm - OTEL_SERVICE_NAME = "producer-lambda" - OTEL_RESOURCE_ATTRIBUTES = "deployment.environment=${var.prefix}-lambda-shop" - AWS_LAMBDA_EXEC_WRAPPER = "/opt/nodejs-otel-handler" - KINESIS_STREAM = aws_kinesis_stream.lambda_streamer.name - } -} -``` - -これらの環境変数を使用することで、いくつかの方法で自動計装を構成しています - -- 環境変数を設定して、データのエクスポート先となるSplunk Observability Cloud組織をOpenTelemetry collectorに伝えています。 - - ```bash - SPLUNK_ACCESS_TOKEN = var.o11y_access_token - SPLUNK_ACCESS_TOKEN = var.o11y_realm - ``` - -- また、OpenTelemetryが関数/サービスを識別し、それが属する環境/アプリケーションを認識するのに役立つ変数も設定しています。 - - ```bash - OTEL_SERVICE_NAME = "producer-lambda" # consumer関数の場合はconsumer-lambda - OTEL_RESOURCE_ATTRIBUTES = "deployment.environment=${var.prefix}-lambda-shop" - ``` - -- コード言語に基づいて、関数のハンドラーに自動的にトレースデータを取得するために適用する必要があるラッパーをOpenTelemetryに知らせる環境変数を設定しています。 - - ```bash - AWS_LAMBDA_EXEC_WRAPPER - "/opt/nodejs-otel-handler" - ``` - -- `producer-lambda` 関数の場合、レコードを配置するKinesisストリームを関数に知らせるための環境変数を設定しています。 - - ```bash - KINESIS_STREAM = aws_kinesis_stream.lambda_streamer.name - ``` - -- これらの値は、「前提条件」セクションで設定した環境変数、および、このTerraform構成ファイルの一部としてデプロイされるリソースから取得されます。 - -また、各関数にSplunk OpenTelemetry Lambda layerを設定する引数も確認できるはずです - -```bash -layers = var.otel_lambda_layer -``` - -- OpenTelemetry Lambda layerは、Lambda関数の呼び出し時に計測データを収集、処理、およびエクスポートするために必要なライブラリと依存関係を含むパッケージです。 - -- すべてのOpenTelemetryサポート言語のライブラリと依存関係を持つ一般的なOTel Lambda layerがありますが、関数をさらに軽量化するための言語固有のLambda layerも存在します。 - - _各 AWS リージョンの関連する Splunk OpenTelemetry Lambda layer ARN（Amazon Resource Name）と最新バージョンは[こちら](https://github.com/signalfx/lambda-layer-versions/blob/main/splunk-apm/splunk-apm.md)で確認できます_ - -#### `producer.mjs` ファイル - -次に、`producer-lambda` 関数のコードを見てみましょう - -- 以下のコマンドを実行して `producer.mjs` ファイルの内容を表示します - - ```bash - cat ~/o11y-lambda-workshop/auto/handler/producer.mjs - ``` - - - このNodeJSモジュールにはプロデューサー関数のコードが含まれています。 - - 基本的に、この関数はメッセージを受け取り、そのメッセージを対象のKinesisストリームにレコードとして配置します - -### Lambda 関数のデプロイとトレースデータの生成 - -`auto` ディレクトリの内容に慣れたところで、ワークショップ用のリソースをデプロイし、Lambda関数からトレースデータを生成していきます。 - -#### `auto` ディレクトリで Terraform を初期化する - -`main.tf` ファイルで定義されたリソースをデプロイするには、まずTerraformがそのファイルと同じフォルダで初期化されていることを確認する必要があります。 - -- `auto` ディレクトリにいることを確認します: - - ```bash - pwd - ``` - - - _予想される出力は **~/o11y-lambda-workshop/auto** です_ - -- `auto` ディレクトリにいない場合は、次のコマンドを実行します - - ```bash - cd ~/o11y-lambda-workshop/auto - ``` - -- 次のコマンドを実行して、このディレクトリでTerraformを初期化します - - ```bash - terraform init - ``` - - - このコマンドは同じフォルダにいくつかの要素を作成します - - `.terraform.lock.hcl` ファイル：リソースを提供するために使用するプロバイダーを記録します - - `.terraform` ディレクトリ：プロバイダーの構成を保存します - - 上記のファイルに加えて、`apply` サブコマンドを使用してterraformを実行すると、デプロイされたリソースの状態を追跡するために `terraform.tfstate` ファイルが作成されます。 - - これらにより、Terraformは `auto` ディレクトリの `main.tf` ファイル内で定義されたとおりに、リソースの作成、状態、破棄を管理できます - -#### Lambda 関数とその他の AWS リソースをデプロイする - -このディレクトリでTerraformを初期化したら、リソースのデプロイに進むことができます。 - -- まず、**terraform plan** コマンドを実行して、Terraformが問題なくリソースを作成できることを確認します。 - - ```bash - terraform plan - ``` - - - _これにより、リソースをデプロイするプランといくつかのデータが出力され、意図したとおりに動作することを確認できます。_ - - _プランに表示される値の一部は、作成後に判明するか、セキュリティ上の理由でマスクされていることに注意してください。_ - -- 次に、**terraform apply** コマンドを実行して、**main.tf** ファイルからLambda関数とその他のサポートリソースをデプロイします - - ```bash - terraform apply - ``` - - - _**Enter a value:** プロンプトが表示されたら **yes** と応答します_ - - - これにより、以下のような出力が得られます - - ```bash - Outputs: - - base_url = "https://______.amazonaws.com/serverless_stage/producer" - consumer_function_name = "_____-consumer" - consumer_log_group_arn = "arn:aws:logs:us-east-1:############:log-group:/aws/lambda/______-consumer" - consumer_log_group_name = "/aws/lambda/______-consumer" - environment = "______-lambda-shop" - lambda_bucket_name = "lambda-shop-______-______" - producer_function_name = "______-producer" - producer_log_group_arn = "arn:aws:logs:us-east-1:############:log-group:/aws/lambda/______-producer" - producer_log_group_name = "/aws/lambda/______-producer" - ``` - - - _Terraform 出力は **outputs.tf** ファイルで定義されています。_ - - _これらの出力は、ワークショップの他の部分でもプログラム的に使用されます。_ - -#### `producer-lambda` URL (`base_url`) にトラフィックを送信する - -デプロイしたLambda関数からトレースを取得し始めるには、トラフィックを生成する必要があります。`producer-lambda` 関数のエンドポイントにメッセージを送信し、それをKinesisストリームにレコードとして配置し、その後 `consumer-lambda` 関数によってストリームから取得されるようにします。 - -- `auto` ディレクトリにいることを確認します - - ```bash - pwd - ``` - - - _予想される出力は **~/o11y-lambda-workshop/auto** です_ - -- `auto` ディレクトリにいない場合は、次のコマンドを実行します - - ```bash - cd ~/o11y-lambda-workshop/auto - ``` - -`send_message.py` スクリプトは、コマンドラインで入力を受け取り、JSONディクショナリに追加し、whileループの一部として `producer-lambda` 関数のエンドポイントに繰り返し送信するPythonスクリプトです。 - -- Run the `send_message.py` script as a background process - - - _`--name` と `--superpower` 引数が必要です_ - - ```bash - nohup ./send_message.py --name CHANGEME --superpower CHANGEME & - ``` - - - メッセージが成功した場合は、以下のような出力が表示されるはずです - - ```bash - [1] 79829 - user@host manual % appending output to nohup.out - ``` - - - _ここで重要な情報は 2 つあります:_ - - _1 行目のプロセス ID（この例では `79829`）、および_ - - _`appending output to nohup.out` メッセージ_ - - _`nohup` コマンドはスクリプトがバックグラウンドに送られた時に切断されないようにします。また、コマンドからの curl 出力を、現在いるフォルダと同じフォルダにある nohup.out ファイルにキャプチャします。_ - - _`&` はシェルプロセスにこのプロセスをバックグラウンドで実行するよう指示し、シェルが他のコマンドを実行できるようにします。_ - -- 次に、`response.logs` ファイルの内容を確認して、`producer-lambda` エンドポイントへのリクエストが成功したことを確認します - - ```bash - cat response.logs - ``` - - - メッセージが成功していれば、画面に印刷された行の中に次の出力が表示されるはずです - - ```bash - {"message": "Message placed in the Event Stream: {prefix}-lambda_stream"} - ``` - - - 失敗した場合は、次のように表示されます - - ```bash - {"message": "Internal server error"} - ``` - -> [!IMPORTANT] -> この場合は、ワークショップ進行役の一人に支援を求めてください。 - -#### Lambda 関数のログを表示する - -次に、Lambda関数のログを確認しましょう。 - -- **producer-lambda** ログを表示するには、**producer.logs** ファイルを確認します - - ```bash - cat producer.logs - ``` - -- **consumer-lambda** ログを表示するには、**consumer.logs** ファイルを確認します - - ```bash - cat consumer.logs - ``` - -ログを注意深く調べてください。 - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} - -- OpenTelemetryが読み込まれているのが見えますか？`splunk-extension-wrapper` のある行に注目してください - - - _**splunk-extension-wrapper**が読み込まれているのを見るために `head -n 50 producer.logs` または `head -n 50 consumer.logs` の実行を検討してください。_ - -{{% /notice %}} diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/3-lambdas-in-splunk.md b/content/ja/ninja-workshops/6-lambda-kinesis/3-lambdas-in-splunk.md deleted file mode 100644 index efdba707b3..0000000000 --- a/content/ja/ninja-workshops/6-lambda-kinesis/3-lambdas-in-splunk.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Splunk APM、Lambda関数およびトレース -linkTitle: 3. Splunk APMでのLambdaトレース -weight: 3 ---- - -Lambda関数は相当量のトレースデータを生成しているはずで、それを確認する必要があります。Lambda関数のリソース定義で構成された環境変数とOpenTelemetry Lambda layerの組み合わせにより、Splunk APMで関数とトレースを表示する準備が整いました。 - -#### Splunk APM 概要で環境名を確認する - -まず、Splunk APMが受信しているトレースデータから `Environment` を認識していることを確認しましょう。これは `main.tf` のLambda関数定義で設定した `OTEL_RESOURCE_ATTRIBUTES` 変数の一部として設定した `deployment.name` です。これは先ほど実行した `terraform apply` コマンドの出力の1つでもありました。 - -Splunk Observability Cloudで - -- 左側のメインメニューから `APM` ボタンをクリックします。これによりSplunk APM概要に移動します。 - -- `Environment:` ドロップダウンからあなたのAPM環境を選択します。 - - _APM 環境は `PREFIX-lambda-shop` 形式になっているはずです。`PREFIX` は前提条件セクションで設定した環境変数から取得されます_ - -> [!NOTE] -> トレースが Splunk APM に表示されるまで数分かかる場合があります。環境のリストにあなたの環境名が表示されるまで、ブラウザの更新ボタンを押してみてください - -![Splunk APM, Environment Name](../images/02-Auto-APM-EnvironmentName.png) - -#### 環境のサービスマップを表示する - -Environmentドロップダウンから環境名を選択したら、Lambda関数のサービスマップを確認できます。 - -- APM概要ページの右側にある `Service Map` ボタンをクリックします。これによりサービスマップビューに移動します。 - -![Splunk APM、サービスマップボタン](../images/03-Auto-ServiceMapButton.png) - -`producer-lambda` 関数とそのレコードを配置するためにKinesisストリームに対して行っている呼び出しが表示されるはずです。 - -![Splunk APM、サービスマップ](../images/04-Auto-ServiceMap.png) - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -あなたの `consumer-lambda` 関数はどうなっていますか？ -{{% /notice %}} - -#### Lambda 関数からのトレースを調査する - -- `Traces` ボタンをクリックしてトレースアナライザーを表示します。 - -![Splunk APM、トレースボタン](../images/05-Auto-TraceButton.png) - -このページでは、`producer-lambda` 関数のOpenTelemetry Lambda layerから取り込まれたトレースを確認できます。 - -![Splunk APM、トレースアナライザー](../images/06-Auto-TraceAnalyzer.png) - -- リストからハイパーリンクされた `Trace ID` をクリックして、調査するトレースを選択します。 - -![Splunk APM、トレースとスパン](../images/07-Auto-TraceNSpans.png) - -`producer-lambda` 関数がKinesisストリームにレコードを配置しているのが確認できます。しかし、`consumer-lambda` 関数のアクションが見当たりません！ - -これはトレースコンテキストが伝播されていないためです。このワークショップの時点では、Kinesisサービスはトレースコンテキスト伝播をすぐには対応していません。分散トレースはKinesisサービスで止まっており、そのコンテキストがストリームを通じて自動的に伝播されないため、それ以上先を見ることができません。 - -少なくとも、今はまだ... - -次のセクションでこの問題にどう対処するか見ていきましょう。しかしその前に、後片付けをしましょう！ - -### クリーンアップ - -この自動計装演習の一部としてデプロイしたリソースはクリーンアップする必要があります。同様に、`producer-lambda` エンドポイントに対してトラフィックを生成していたスクリプトも、まだ実行中であれば停止する必要があります。以下の手順に従ってクリーンアップを行ってください。 - -#### `send_message` の停止 - -- `send_message.py` スクリプトがまだ実行中の場合は、次のコマンドで停止します - - ```bash - fg - ``` - - - これによりバックグラウンドプロセスがフォアグラウンドに移動します。 - - 次に `[CONTROL-C]` を押してプロセスを終了できます。 - -#### 全ての AWS リソースを破棄する - -Terraformは個々のリソースの状態をデプロイメントとして管理するのに優れています。定義に変更があっても、デプロイされたリソースを更新することもできます。しかし、一からやり直すために、リソースを破棄し、このワークショップの手動計装部分の一部として再デプロイします。 - -以下の手順に従ってリソースを破棄してください - -- `auto` ディレクトリにいることを確認します - - ```bash - pwd - ``` - - - _期待される出力は **~/o11y-lambda-workshop/auto** です_ - -- `auto` ディレクトリにいない場合は、以下のコマンドを実行します - - ```bash - cd ~/o11y-lambda-workshop/auto - ``` - -- 先ほどデプロイしたLambda関数とその他のAWSリソースを破棄します - - ```bash - terraform destroy - ``` - - - `Enter a value:` プロンプトが表示されたら `yes` と応答します - - これによりリソースが破棄され、クリーンな環境が残ります - -このプロセスにより、私たちの活動の結果として作成されたファイルとディレクトリは残ります。それらについては心配する必要はありません。 diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/4-manual-instrumentation.md b/content/ja/ninja-workshops/6-lambda-kinesis/4-manual-instrumentation.md deleted file mode 100644 index 914883df42..0000000000 --- a/content/ja/ninja-workshops/6-lambda-kinesis/4-manual-instrumentation.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: 手動計装 -linkTitle: 4. 手動計装 -weight: 4 ---- - -ワークショップの第2部では、OpenTelemetryによる手動計装が計測データ収集を強化する方法を実演することに焦点を当てます。より具体的には、今回のケースでは、`producer-lambda` 関数から `consumer-lambda` 関数にトレースコンテキストデータを伝播させることができるようになります。これにより、現在は自動コンテキスト伝播をサポートしていないKinesisストリームを介しても、2つの関数間の関係を見ることができるようになります。 - -### 手動計装ワークショップディレクトリとコンテンツ - -再度、作業ディレクトリとそのファイルの一部を確認することから始めます。今回は `o11y-lambda-workshop/manual` ディレクトリです。ここにはワークショップの手動計装部分のすべてのコンテンツがあります。 - -#### `manual` ディレクトリ - -- 以下のコマンドを実行して `o11y-lambda-workshop/manual` ディレクトリに移動します - - ```bash - cd ~/o11y-lambda-workshop/manual - ``` - -- `ls` コマンドでこのディレクトリの内容を確認します - - ```bash - ls - ``` - - - _出力には以下のファイルとディレクトリが含まれるはずです：_ - - ```bash - handler outputs.tf terraform.tf variables.tf - main.tf send_message.py terraform.tfvars - ``` - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -このディレクトリと最初に始めたautoディレクトリに何か違いがありますか？ -{{% /notice %}} - -#### `auto` と `manual` のファイルを比較する - -見た目が同じように見えるこれらのファイルが実際に同じかどうか確認しましょう。 - -- `auto` と `manual` ディレクトリの `main.tf` ファイルを比較します - - ```bash - diff ~/o11y-lambda-workshop/auto/main.tf ~/o11y-lambda-workshop/manual/main.tf - ``` - - - 違いはありません！_(違いがあるはずはありません。もし違いがあれば、ワークショップ進行役に支援を求めてください)_ - -- 次に、`producer.mjs` ファイルを比較してみましょう - - ```bash - diff ~/o11y-lambda-workshop/auto/handler/producer.mjs ~/o11y-lambda-workshop/manual/handler/producer.mjs - ``` - - - ここにはかなりの違いがあります！ - -- ファイル全体を表示してその内容を調べたい場合は以下を実行します - - ```bash - cat ~/o11y-lambda-workshop/handler/producer.mjs - ``` - - - 必要な手動計装タスクを処理するために、いくつかのOpenTelemetryオブジェクトを関数に直接インポートしていることに注目してください。 - - ```js - import { context, propagation, trace } from "@opentelemetry/api"; - ``` - - - プロデューサー関数でコンテキストを伝播するために、[@opentelemetry/api](https://www.npmjs.com/package/@opentelemetry/api) から次のオブジェクトをインポートしています - - context - - propagation - - trace - -- 最後に、`consumer.mjs` ファイルを比較します - - ```bash - diff ~/o11y-lambda-workshop/auto/handler/consumer.mjs ~/o11y-lambda-workshop/manual/handler/consumer.mjs - ``` - - - ここにもいくつかの注目すべき違いがあります。より詳しく見てみましょう - - ```bash - cat handler/consumer.mjs - ``` - - - このファイルでは、次の [@opentelemetry/api](https://www.npmjs.com/package/@opentelemetry/api) オブジェクトをインポートしています - - propagation - - trace - - ROOT_CONTEXT - - これらを使用して、プロデューサー関数から伝播されたトレースコンテキストを抽出します - - その後、抽出したトレースコンテキストに `name` と `superpower` に基づいた新しいスパン属性を追加します - -#### プロデューサー関数からのトレースコンテキスト伝播 - -以下のコードはプロデューサー関数内で次のステップを実行します - -1. このトレース用のトレーサーを取得する -2. コンテキストキャリアオブジェクトを初期化する -3. アクティブスパンのコンテキストをキャリアオブジェクトに注入する -4. Kinesisストリームに配置しようとしているレコードを修正し、アクティブスパンのコンテキストをコンシューマーに運ぶキャリアを含める - -```js -... -import { context, propagation, trace, } from "@opentelemetry/api"; -... -const tracer = trace.getTracer('lambda-app'); -... - return tracer.startActiveSpan('put-record', async(span) => { - let carrier = {}; - propagation.inject(context.active(), carrier); - const eventBody = Buffer.from(event.body, 'base64').toString(); - const data = "{\"tracecontext\": " + JSON.stringify(carrier) + ", \"record\": " + eventBody + "}"; - console.log( - `Record with Trace Context added: - ${data}` - ); - - try { - await kinesis.send( - new PutRecordCommand({ - StreamName: streamName, - PartitionKey: "1234", - Data: data, - }), - message = `Message placed in the Event Stream: ${streamName}` - ) -... - span.end(); -``` - -#### コンシューマー関数でのトレースコンテキスト抽出 - -以下のコードはコンシューマー関数内で次のステップを実行します - -1. `producer-lambda` から取得したコンテキストをキャリアオブジェクトに抽出する -2. 現在のコンテキストからトレーサーを抽出する -3. 抽出したコンテキスト内でトレーサーを使用して新しいスパンを開始する -4. ボーナス：メッセージからの値を含むカスタム属性など、追加の属性をスパンに追加する！ -5. 完了したら、スパンを終了する - -```js -import { propagation, trace, ROOT_CONTEXT } from "@opentelemetry/api"; -... - const carrier = JSON.parse( message ).tracecontext; - const parentContext = propagation.extract(ROOT_CONTEXT, carrier); - const tracer = trace.getTracer(process.env.OTEL_SERVICE_NAME); - const span = tracer.startSpan("Kinesis.getRecord", undefined, parentContext); - - span.setAttribute("span.kind", "server"); - const body = JSON.parse( message ).record; - if (body.name) { - span.setAttribute("custom.tag.name", body.name); - } - if (body.superpower) { - span.setAttribute("custom.tag.superpower", body.superpower); - } -... - span.end(); -``` - -これでどのような違いが生まれるか見てみましょう！ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/5-redeploy-lambdas.md b/content/ja/ninja-workshops/6-lambda-kinesis/5-redeploy-lambdas.md deleted file mode 100644 index c17299bdcc..0000000000 --- a/content/ja/ninja-workshops/6-lambda-kinesis/5-redeploy-lambdas.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: Lambda関数のデプロイとトレースデータの生成 -linkTitle: 5. Lambda関数の再デプロイ -weight: 5 ---- - -トレースデータを収集したい関数やサービスに手動計装を適用する方法がわかったので、Lambda関数を再度デプロイして、`producer-lambda` エンドポイントに対するトラフィックを生成していきましょう。 - -#### `manual` ディレクトリで Terraform を初期化する - -新しいディレクトリにいるので、ここでもう一度Terraformを初期化する必要があります。 - -- `manual` ディレクトリにいることを確認します - - ```bash - pwd - ``` - - - _予想される出力は **~/o11y-lambda-workshop/manual** です_ - -- `manual` ディレクトリにいない場合は、次のコマンドを実行します - - ```bash - cd ~/o11y-lambda-workshop/manual - ``` - -- 次のコマンドを実行して、このディレクトリでTerraformを初期化します - - ```bash - terraform init - ``` - -#### Lambda 関数とその他の AWS リソースをデプロイする - -それでは、これらのリソースを再度デプロイしましょう！ - -- 問題がないことを確認するために、**terraform plan** コマンドを実行します。 - - ```bash - terraform plan - ``` - -- 続いて、**terraform apply** コマンドを使用して **main.tf** ファイルからLambda関数とその他のサポートリソースをデプロイします - - ```bash - terraform apply - ``` - - - _**Enter a value:** プロンプトが表示されたら **yes** と応答します_ - - - これにより、以下のような出力が得られます - - ```bash - Outputs: - - base_url = "https://______.amazonaws.com/serverless_stage/producer" - consumer_function_name = "_____-consumer" - consumer_log_group_arn = "arn:aws:logs:us-east-1:############:log-group:/aws/lambda/______-consumer" - consumer_log_group_name = "/aws/lambda/______-consumer" - environment = "______-lambda-shop" - lambda_bucket_name = "lambda-shop-______-______" - producer_function_name = "______-producer" - producer_log_group_arn = "arn:aws:logs:us-east-1:############:log-group:/aws/lambda/______-producer" - producer_log_group_name = "/aws/lambda/______-producer" - ``` - -見ての通り、base_urlの最初の部分とログループARN以外は、このワークショップの自動計装部分をこの同じ時点まで実行したときと出力は概ね同じはずです。 - -#### `producer-lambda` エンドポイント (base_url) にトラフィックを送信する - -もう一度、`name` と `superpower` をメッセージとしてエンドポイントに送信します。これはトレースコンテキストとともに、Kinesisストリーム内のレコードに追加されます。 - -- `manual` ディレクトリにいることを確認します - - ```bash - pwd - ``` - - - _予想される出力は **~/o11y-lambda-workshop/manual** です_ - -- `manual` ディレクトリにいない場合は、次のコマンドを実行します - - ```bash - cd ~/o11y-lambda-workshop/manual - ``` - -- `send_message.py` スクリプトをバックグラウンドプロセスとして実行します - - ```bash - nohup ./send_message.py --name CHANGEME --superpower CHANGEME & - ``` - -- 次に、response.logsファイルの内容を確認して、**producer-lambda**エンドポイントへの呼び出しが成功しているか確認します - - ```bash - cat response.logs - ``` - - - メッセージが成功していれば、画面に表示される行の中に次の出力が表示されるはずです - - ```bash - {"message": "Message placed in the Event Stream: hostname-eventStream"} - ``` - - - 失敗した場合は、次のように表示されます - - ```bash - {"message": "Internal server error"} - ``` - -> [!IMPORTANT] -> これが発生した場合は、ワークショップ進行役の一人に支援を求めてください。 - -#### Lambda 関数のログの確認 - -ログがどのようになっているか見てみましょう。 - -- **producer.logs** ファイルを確認します - - ```bash - cat producer.logs - ``` - -- そして **consumer.logs** ファイルを確認します - - ```bash - cat consumer.logs - ``` - -ログを注意深く調べてください。 - -##### _ワークショップの質問_ - -> 違いに気づきましたか？ - -#### `consumer-lambda` ログからのトレース ID のコピー - -今回は、consumer-lambdaのロググループが、我々が伝播した `tracecontext` とともに、メッセージを `record` としてログに記録しているのが確認できます。 - -トレースIDをコピーするには - -- `Kinesis Message` ログの1つを見てみましょう。その中には `data` ディクショナリがあります -- ネストされた `tracecontext` ディクショナリを見るために、`data` をより詳しく見てください -- `tracecontext` ディクショナリ内には、`traceparent` というキーと値のペアがあります -- `traceparent` キーと値のペアには、私たちが探しているトレースIDが含まれています - - `-` で区切られた4つの値のグループがあります。トレースIDは2番目の文字グループです -- **トレース ID をコピーして保存してください。** このワークショップの後のステップで必要になります - -![Lambda Consumer Logs、手動計装](../images/08-Manual-ConsumerLogs.png) diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/6-updated-lambdas.md b/content/ja/ninja-workshops/6-lambda-kinesis/6-updated-lambdas.md deleted file mode 100644 index d81607451a..0000000000 --- a/content/ja/ninja-workshops/6-lambda-kinesis/6-updated-lambdas.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Splunk APM、Lambda関数とトレース、再び！ -linkTitle: 6. Splunk APMでの更新されたLambda -weight: 6 ---- - -ログの外部でコンテキスト伝播の結果を確認するために、もう一度[Splunk APM UI](https://app.us1.signalfx.com/#/apm)を参照します。 - -#### Splunk APM サービスマップで Lambda 関数を表示する - -もう一度APMで環境のサービスマップを確認してみましょう。 - -Splunk Observability Cloudで - -- メインメニューの `APM` ボタンをクリックします。 - -- `Environment:` ドロップダウンからあなたのAPM環境を選択します。 - -- APM概要ページの右側にある `Service Map` ボタンをクリックします。これによりサービスマップビューに移動します。 - -> [!NOTE] > _注意：トレースが Splunk APM に表示されるまで数分かかる場合があります。環境のリストにあなたの環境名が表示されるまで、ブラウザの更新ボタンを押してみてください_ - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -違いに気づきましたか？ -{{% /notice %}} - -- 今回は、伝播されたコンテキストによってリンクされた `producer-lambda` と `consumer-lambda` 関数が見えるはずです！ - -![Splunk APM、サービスマップ](../images/09-Manual-ServiceMap.png) - -#### トレース ID で Lambda トレースを調査する - -次に、環境に関連するトレースをもう一度確認します。 - -- コンシューマー関数のログからコピーしたトレースIDを、Traces下の `View Trace ID` 検索ボックスに貼り付け、`Go` をクリックします - -![Splunk APM、トレースボタン](../images/10-Manual-TraceButton.png) - -> [!NOTE] -> トレース ID は、私たちが伝播したトレースコンテキストの一部でした。 - -最も一般的な2つの伝播規格について読むことができます - -1. [W3C](https:///www.w3.org/TR/trace-context/#traceparent-header) -2. [B3](https://github.com/openzipkin/b3-propagation#overall-process) - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -私たちはどちらを使用していますか？ - -- _私たちの NodeJS 関数をサポートする Splunk Distribution of Opentelemetry JS は、[デフォルト](https://docs.splunk.com/observability/en/gdi/get-data-in/application/nodejs/splunk-nodejs-otel-distribution.html#defaults-of-the-splunk-distribution-of-opentelemetry-js)で `W3C` 標準を使用しています_ - -{{% /notice %}} - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -ボーナス質問：W3CヘッダーとB3ヘッダーを混在させるとどうなりますか？ -{{% /notice %}} - -![Splunk APM、IDによるトレース](../images/11-Manual-TraceByID.png) - -`consumer-lambda` スパンをクリックしてください。 - -{{% notice title="ワークショップの質問" style="tip" icon="question" %}} -あなたのメッセージからの属性を見つけることができますか？ -{{% /notice %}} - -![Splunk APM、スパンタグ](../images/12-Manual-SpanTags.png) - -### クリーンアップ - -いよいよワークショップの最後に来ました。後片付けをしましょう！ - -#### `send_message` の停止 - -- `send_message.py` スクリプトがまだ実行中の場合は、次のコマンドで停止します - - ```bash - fg - ``` - - - これによりバックグラウンドプロセスがフォアグラウンドに移動します。 - - 次に `[CONTROL-C]` を押してプロセスを終了できます。 - -#### すべての AWS リソースを破棄する - -Terraformは個々のリソースの状態をデプロイメントとして管理するのに優れています。定義に変更があっても、デプロイされたリソースを更新することもできます。しかし、一からやり直すために、リソースを破棄し、このワークショップの手動計装部分の一部として再デプロイします。 - -以下の手順に従ってリソースを破棄してください - -- `manual` ディレクトリにいることを確認します - - ```bash - pwd - ``` - - - _予想される出力は **~/o11y-lambda-workshop/manual** です_ - -- `manual` ディレクトリにいない場合は、次のコマンドを実行します - - ```bash - cd ~/o11y-lambda-workshop/manual - ``` - -- 以前にデプロイしたLambda関数とその他のAWSリソースを破棄します - - ```bash - terraform destroy - ``` - - - `Enter a value:` プロンプトが表示されたら `yes` と応答します - - これにより、リソースが破棄され、クリーンな環境が残ります diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/7-summary.md b/content/ja/ninja-workshops/6-lambda-kinesis/7-summary.md deleted file mode 100644 index 527bea4771..0000000000 --- a/content/ja/ninja-workshops/6-lambda-kinesis/7-summary.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: 結論 -linkTitle: 7. 結論 -weight: 7 ---- - -Lambda Tracingワークショップを終えたことをおめでとうございます！自動計装を手動のステップで補完して、`producer-lambda` 関数のコンテキストをKinesisストリーム内のレコードを介して `consumer-lambda` 関数に送信する方法を見てきました。これにより、期待される分散トレースを構築し、Splunk APMで両方の関数間の関係をコンテキスト化することができました。 - -![完全に計装されたLambdaアプリケーション](../images/13-Architecture_Instrumented.png) - -これで、2つの異なる関数を手動でリンクしてトレースを構築することができます。これは、自動計装や第三者のシステムがコンテキスト伝播を標準でサポートしていない場合や、より関連性の高いトレース分析のためにカスタム属性をトレースに追加したい場合に役立ちます。 diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/_index.md b/content/ja/ninja-workshops/6-lambda-kinesis/_index.md deleted file mode 100644 index 12ecf399ee..0000000000 --- a/content/ja/ninja-workshops/6-lambda-kinesis/_index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: AWS Lambda関数の分散トレーシング -linkTitle: Lambdaトレーシング -description: このワークショップでは、AWS Lambdaで実行される小規模なサーバーレスアプリケーションの分散トレースを構築し、AWS Kinesisを介してメッセージをproduceおよびconsumeする方法を学びます -weight: 6 -authors: ["Guy-Francis Kono"] -time: 45 minutes ---- - -このワークショップでは、AWS Lambdaで実行される小規模なサーバーレスアプリケーションの分散トレースを構築し、AWS Kinesisを介してメッセージをproduceおよびconsumeする方法を学びます。 - -まず、OpenTelemetryの自動計装がどのようにトレースをキャプチャし、選択した宛先にエクスポートするかを確認します。 - -次に、手動計装によってコンテキスト伝播を有効にする方法を見ていきます。 - -このワークショップのために、SplunkはAWS/EC2上のUbuntu Linuxインスタンスを事前に構成しています。このインスタンスにアクセスするには、ワークショップインストラクターが提供するURLにアクセスしてください。 diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/01-Architecture.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/01-Architecture.png deleted file mode 100644 index 97ed118158..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/01-Architecture.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/02-Auto-APM-EnvironmentName.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/02-Auto-APM-EnvironmentName.png deleted file mode 100644 index 94f2f0e5d4..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/02-Auto-APM-EnvironmentName.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/03-Auto-ServiceMapButton.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/03-Auto-ServiceMapButton.png deleted file mode 100644 index bc8a3bd45a..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/03-Auto-ServiceMapButton.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/04-Auto-ServiceMap.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/04-Auto-ServiceMap.png deleted file mode 100644 index 6fa9b04897..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/04-Auto-ServiceMap.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/05-Auto-TraceButton.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/05-Auto-TraceButton.png deleted file mode 100644 index faa9173d95..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/05-Auto-TraceButton.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/06-Auto-TraceAnalyzer.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/06-Auto-TraceAnalyzer.png deleted file mode 100644 index ec271c9146..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/06-Auto-TraceAnalyzer.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/07-Auto-TraceNSpans.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/07-Auto-TraceNSpans.png deleted file mode 100644 index 41b769cb45..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/07-Auto-TraceNSpans.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/08-Manual-ConsumerLogs.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/08-Manual-ConsumerLogs.png deleted file mode 100644 index 4f68dcdbb1..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/08-Manual-ConsumerLogs.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/09-Manual-ServiceMap.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/09-Manual-ServiceMap.png deleted file mode 100644 index bb1111a03f..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/09-Manual-ServiceMap.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/10-Manual-TraceButton.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/10-Manual-TraceButton.png deleted file mode 100644 index bdbe46a225..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/10-Manual-TraceButton.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/11-Manual-TraceByID.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/11-Manual-TraceByID.png deleted file mode 100644 index 5855cfe90c..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/11-Manual-TraceByID.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/12-Manual-SpanTags.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/12-Manual-SpanTags.png deleted file mode 100644 index 000e6bbc4f..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/12-Manual-SpanTags.png and /dev/null differ diff --git a/content/ja/ninja-workshops/6-lambda-kinesis/images/13-Architecture_Instrumented.png b/content/ja/ninja-workshops/6-lambda-kinesis/images/13-Architecture_Instrumented.png deleted file mode 100644 index 98823f8ba3..0000000000 Binary files a/content/ja/ninja-workshops/6-lambda-kinesis/images/13-Architecture_Instrumented.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/_index.md b/content/ja/ninja-workshops/7-dashboards-detectors/_index.md deleted file mode 100644 index 574c9d2c3b..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/_index.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Dashboard Workshop -description: Splunk Observability Cloud のチャート機能、フィルター、分析関数、SignalFlow を使用して、洞察に満ちた可視化とカスタムダッシュボードを構築する方法を学びます -weight: 7 -archetype: chapter -authors: ["Pieter Hagen"] -time: 45 minutes -draft: false ---- -Splunk Observability Cloudの **Dashboards** に関するワークショップへようこそ。このセッションでは、洞察に満ちた可視化を構築するためのハンズオン体験を提供します。 - - - -Splunk Observability Suiteで利用可能な既存のデモデータを使用して作業します。アクセス可能な **trial** または **production** のSplunk Observability組織を使用してフォローできます。 - -### 学習内容 - -### ダッシュボード - -ワークショップの最初のパートでは、ダッシュボードとチャートに焦点を当てます： - -* ダッシュボードの理解とチャートの役割 -* 既存のチャートの編集と新しいチャートの作成 -* フィルターの適用と分析関数の使用 -* 数式の構築とカスタマイズ -* 再利用のためのダッシュボードへのチャートの保存 -* 高度なチャート作成のためのSignalFlow入門 - - diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-01-sample_data.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-01-sample_data.md deleted file mode 100644 index 0eb60b2be9..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-01-sample_data.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: サンプルデータの場所 -linkTitle: 1.01. Sample Data -weight: 1.01 -time: 10 minutes ---- - -## 1. サンプルデータの探索 - -利用可能なダッシュボードのリストで、**Sample Data (2)** というグループを探してください。 - -このグループには、サンプルメトリクスから構築された可視化を紹介するダッシュボードが含まれています。これらは、Splunk Observabilityのチャートとダッシュボードを使用してさまざまなデータをどのように表現できるかを理解するのに役立ちます。 - -![Sample Data](../../images/sample-data.png) - ---- - -**Sample Data** ダッシュボードグループをクリックして展開し、**Sample Charts (3)** ダッシュボードを選択します。 - -このダッシュボードでは、Splunk Observabilityで利用可能なさまざまなチャートタイプ、スタイル、およびフォーマットオプションを紹介しています。ダッシュボードがどれほど柔軟でカスタマイズ可能かを体感するのに最適な方法です。 - -サンプルデータは10分サイクルで実行され、時間の経過とともにさまざまなパターンと動作を生成します。 -これらの変化を実際に確認するには、ダッシュボードの右上隅にある時間範囲を **Last 15 minutes** に調整するか、より良い概要を得るために **Last 1 hour** を選択してください。これにより、データがどのように更新され、さまざまな条件を循環するかを観察できます。 - -このダッシュボードのチャートを少し探索してみてください。各チャートは、サンプルデータを可視化する方法について異なる視点を提供しています。 - -![Sample Charts](../../images/sample-charts.png) diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-02-exploring_charts.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-02-exploring_charts.md deleted file mode 100644 index 5af4593fee..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-02-exploring_charts.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: チャートの探索 -linkTitle: 1.02. Exploring Charts -weight: 1.02 ---- -このセクションでは、Splunk Observabilityでチャートがどのように構築され表示されるかを探索することから始めます。既存のチャートを調べて操作することで、チャートエディタの動作方法、データソースの選択方法、ビジュアルオプションの設定方法、そしてさまざまな設定が表示内容にどのように影響するかを理解できます。 - -## 1. チャートの選択 - -開始するには、**SAMPLE CHARTS** ダッシュボードを開いていることを確認し、ダッシュボードの右上隅にある時間範囲を **-5M**（過去5分間）に戻すか、**reset to default** を選択してください。 - -**Latency histogram** チャートを見つけて、チャートの右上隅にある **three dots** (...) **(1)** をクリックします。メニューから **Open (3)** を選択します。また、チャートタイトル (**Latency histogram**) **(2)** をクリックして直接開くこともできます。 - -![Sample Charts](../../images/latency-histogram-open.png) - ---- -チャートエディタが開くと、Latency histogramチャートの設定が表示されます。 - -チャートエディタは、データの可視化方法を制御できる場所です。チャートタイプの変更、変換関数の適用、時間設定の調整、その他のビジュアルおよびデータ関連のオプションを特定のニーズに合わせてカスタマイズできます。 - -![Latency Histogram](../../images/latency-histogram.png) - ---- - -**Plot Editor (1)** タブの **Signal (2)** セクションで、現在使用されているメトリクス `demo.trans.latency` **(3)** を確認できます。このシグナルは、チャートがプロットしているレイテンシデータを表しています。このエリアを使用して、シグナルを編集したり、追加のシグナルを追加して可視化を比較または充実させることができます。 - -チャートには複数の **Line** プロットが表示されています。ラベル `18 ts` **(4)** は、チャートが現在 **18個の個別のメトリクス時系列** をプロットしていることを示しています。 -![Plot Editor](../../images/plot-editor.png) - -さまざまな可視化スタイルを探索するには、エディタ内のさまざまなチャートタイプアイコンをクリックしてみてください。各アイコンにカーソルを合わせると、その名前が表示され、各タイプが何を表すかを理解するのに役立ちます。 - -![Chart Types](../../images/chartbartypes.png) - -たとえば、**Heat Map** アイコンをクリックして、同じデータが異なるフォーマットでどのように表現されるかを確認してみてください。 - -![Change to Heatmap](../../images/change-to-heatmap.png) - -{{% 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/7-dashboards-detectors/dashboards/1-03-editing-chart.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-03-editing-chart.md deleted file mode 100644 index 7df0e2380f..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-03-editing-chart.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: チャートの編集 -linkTitle: 1.04. Editing Charts -weight: 1.04 ---- -このセクションでは、既存のチャートを編集することで、チャートがどのように構成されているかを探索し始めます。これは、チャートエディタのハンズオン体験を得て、チャート設定、データソース、および可視化オプションがどのように連携するかを理解するための素晴らしい方法です。 - ---- -チャートエディタで **Latency histogram** チャートを開いた状態で、ワークショップ用に設定を始めましょう。 - -**visualization** ペインで **Line chart** タイプアイコン **(1)** をクリックしてチャートタイプを変更します。データは折れ線グラフとして表示されるようになります。 - -![Line Chart](../../images/change-to-line.png) - -## 2. チャートの時間ウィンドウの変更 - -より多くの履歴データを表示するために、チャートの時間範囲を調整できます。これを行うには、チャートエディタの右上隅にある **Time (1)** ドロップダウンをクリックし、**Past 15 minutes (2)** を選択します。 - -これにより時間ウィンドウが拡大され、より長い期間にわたるメトリクスの傾向を確認できます。 - -![Line Chart](../../images/time_window.png) - -## 3. Data Table の探索 - -チャートエディタで **Data Table (1)** タブをクリックします。 - -**Data Table** は、チャートを駆動するメトリクス時系列の舞台裏を見ることができます。 - -![Data Table](../../images/data-table.png) - -テーブルの各行は単一の時系列を表し、各列はその時系列に関連付けられたディメンションを示しています。メトリクス `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)** タブをクリックしてData Tableを閉じます。 - -次に、このチャートをダッシュボードに保存して、後で再利用できるようにしましょう！ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-04-saving-charts.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-04-saving-charts.md deleted file mode 100644 index e0fcd21a69..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-04-saving-charts.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: チャートとダッシュボードの保存 -linkTitle: 1.04. Saving Charts -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)** - -これらの更新により、チャートが大きなダッシュボードの一部になった場合や他のユーザーと共有された場合に、識別と理解がしやすくなります。 - -![Save Chart](../../images/save-chart.png) - -{{% button style="blue" %}}Save As{{% /button %}} **(3)** ボタンをクリックして保存プロセスを開始します。チャートは先ほど設定した **Active Latency** という名前を使用しますが、必要に応じてここで名前を更新できます。 - -準備ができたら、{{% button style="blue" %}}Ok{{% /button %}} **(1)** ボタンをクリックして確認し続行します。 - -![Name Chart](../../images/name-chart.png) - -## 2. ダッシュボードの作成 - -チャートを保存するので、それを格納する場所、つまり **ダッシュボード** が必要です。 - -ダッシュボードは、関連するチャートを整理してグループ化するのに役立ち、1つのビューで主要なメトリクスを監視しやすくします。このワークショップでは、作成するチャートを保持するための **新しいダッシュボード** を作成します。 - -**Choose dashboard** ダイアログで、{{% button style="blue" %}}New Dashboard{{% /button %}} **(1)** ボタンをクリックします。 - -**重要**: 既存のダッシュボードを選択しないでください。この演習では必ず新しいダッシュボードを作成してください。 - -![Create Dashboard](../../images/create-dashboard.png) - -**New Dashboard** ダイアログが表示され、新しいダッシュボードの詳細を設定できます。 - -まず、ダッシュボードに名前を付けます。このワークショップでは、次の形式を使用してください：**YOUR_NAME-Dashboard** -**YOUR_NAME** を実際の名前に置き換えて、ダッシュボードを識別しやすくしてください。 - -次に、**permissions** を更新します。**Restricted Read and Write access** に設定して、あなた（または特定のユーザー）のみがダッシュボードを表示および変更できるようにします。ユーザーアカウントが含まれており、読み取りと書き込みの両方のアクセス権があることを確認してください。 - -![Secure Dashboard](../../images/secure-dashboard.png) - -権限に自分のユーザーアカウントがリストされているはずです。これは **現在、このダッシュボードを編集できるのはあなただけ** であることを意味します。 - -必要に応じて、下のドロップダウンから追加のユーザーまたはチームを追加できます。 - -このワークショップの目的上、制限を解除しましょう。セッション中にアクセスが制限されないように、権限設定を ***Everyone can Read and Write*** に変更します。 - -![Name Dashboard](../../images/name-dashboard.png) - -次に、{{% button style="blue" %}}Save{{% /button %}} ボタンをクリックして続行します。 -新しいダッシュボードが作成され、自動的に選択されるので、チャートを直接保存できます。 - -![Choose Dashboard](../../images/choose-dashboard.png) - -新しく作成したダッシュボードが選択されていることを確認し **(1)**、{{% button style="blue" %}}Ok{{% /button %}} ボタン **(2)** をクリックして続行します。 - -ダッシュボードに移動します。左上隅に、**YOUR_NAME-DASHBOARD** が同じ名前のDashboard Groupの一部であることが表示されます。このダッシュボードグループに追加のダッシュボードを追加して、異なるユースケース、システム、またはプロジェクトごとにチャートを整理できます。 - -![New Dashboard Group](../../images/new-dashboard-group.png) diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-05-new-chart.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-05-new-chart.md deleted file mode 100644 index 550767594e..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-05-new-chart.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: 新しいチャートの作成 -linkTitle: 1.05. Create New Chart -weight: 1.05 ---- - -### 1 新しいチャートの作成 - -それでは、新しいチャートを作成して、作業中のダッシュボードに追加しましょう！ - -開始するには、インターフェースの上部中央にあるプラスアイコン **(1)** をクリックします。ドロップダウンから **Chart (2)** を選択します。 -または、{{< button style="blue">}}+ New Chart{{< /button >}} ボタン **(3)** をクリックして、新しいチャートを直接作成することもできます。 - -![Create new chart](../../images/new-chart.png) - -設定の準備ができた空白のチャートテンプレートが表示されます： - -![Empty Chart](../../images/empty-new-chart.png) - -まず、可視化するメトリクスを追加しましょう。この例では、先ほど使用したのと同じメトリクス **`demo.trans.latency`** を引き続き使用します。 - -**Plot Editor (1)** で、**Signal (2)** セクションに移動し、入力フィールドに **`demo.trans.latency`(3)** を入力します。これにより、レイテンシの時系列データがチャートにロードされ、可視化の構築とカスタマイズを開始できます。 - -![Signal](../../images/plot-editor.png) - -**18個の時系列 (4)** を表示する見慣れた折れ線グラフが表示されるはずです。最近のアクティビティを表示するには、**Time dropdown (1)** から **Past 15 minutes** を選択して時間範囲を変更します。 - -![Signal](../../images/line-chart-15-mins.png) diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-06-filtering.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-06-filtering.md deleted file mode 100644 index 73e18e3d2f..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-06-filtering.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: フィルターと分析の使用 -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データセンターからの時系列のみを表示するように制限され、分析がより焦点を絞った意味のあるものになります。 - -![Filter](../../images/select-filter.png) - ---- -チャートエディタの **F(x) (1)** 列で、{{% button style="blue" %}}Add Analytics{{% /button %}} ボタンをクリックして分析関数を適用します。 -ドロップダウンリストから **`Percentile` (2)** を選択し、次に **`Percentile:Aggregation` (3)** オプションを選択します。 -フォローアップパネルで、パーセンタイル値を90のままにしておきます。これにより、チャートは選択した時系列の90パーセンタイルを表示します。 - -このコンテキストでは、90パーセンタイルは、レイテンシ測定値の90%がこの値を下回ることを表します。つまり、**最も高い10%** の値のみがこの点を超えます。これは「最悪のケースの通常」パフォーマンスを理解するのに役立つ方法です。時折発生するスパイクを除外しながら、レイテンシが許容できないレベルに近づいているときを表示します。 - -関数を適用するには、パネルの外側の任意の場所をクリックして選択を確認します **(4)**。 - -![Analytics](../../images/prepare_filter.png) - -**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/7-dashboards-detectors/dashboards/1-07-timeshift.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-07-timeshift.md deleted file mode 100644 index a9bdd6d9c1..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-07-timeshift.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: TimeShift と数式の使用 -linkTitle: 1.07. TimeShift & Formula's -weight: 1.07 ---- - -### 1. Timeshift 分析関数の使用 - -多くの場合、現在のパフォーマンスを過去のデータと比較することが有用です。たとえば、時間の経過に伴うトレンド、回帰、または改善を特定するためです。**Timeshift** 関数は、時系列を過去にシフトさせることでこれを簡単にし、過去の値を現在と並べて表示できるようにします。 - -開始するには、**Signal A** の横にある **`...`** メニュー **(1)** をクリックし、ドロップダウンから **Clone (2)** を選択してクローンを作成します。 - -シグナルを **クローン** すると、同じメトリクス、フィルター、および設定を持つ同一のコピーが作成されます。この複製、**Signal B** は、元のシグナルを変更せずに、1週間前のメトリクスがどのように見えたかを可視化するための **Timeshift** の適用など、さらなる計算や比較に使用できます。 -![Clone Signal](../../images/timeshift-filter.png) - ---- -クローン作成後、**Signal B (1)** というラベルの新しいシグナルが表示されます。これは **Signal A** の正確なコピーであるため、両方のシグナルは同じ時間範囲で同じデータを表示します。その結果、チャート上で **完全に重なって** 表示され、1本の線しかないように見えます。 - -比較を意味のあるものにするために、**Signal B** に **Timeshift** を適用し、データを1週間過去にシフトさせます。これにより、現在のレイテンシのトレンドが先週の同時期と比較してどうなっているかを確認できます。 - -Signal Bの横にある **F(x)** 列で、{{% button style="blue" %}} **+** {{% /button %}} **(2)** をクリックし、リストから **Timeshift (3)** 関数を選択します。 -![Plot Editor](../../images/ab-plot-full.png) - ---- -プロンプトが表示されたら、タイムシフト値として **1w**（または7日間の場合は **7d**）**(4)** を入力します。パネルの外側の任意の場所をクリック **(5)** して変更を確認します。 - -これにより、**Signal B** のデータが1週間過去にシフトされ、現在のレイテンシのトレンドを先週の同時期と視覚的に比較できます。 -![Timeshift](../../images/b-shifted.png) - ---- -**Signal B** の色を変更するには、その行の右端にある ⚙️ 設定アイコン **(1)** をクリックして設定メニューを開きます。次に、ピンクなどの **Plot Color** **(2)** を選択して、チャート上で **Signal B** を元のシグナルと視覚的に区別します。 -完了したら、{{% button style="gray" %}} Close {{% /button %}} **(3)** をクリックします。 -![Change Plot Color](../../images/b-pink.png) - ---- -チャートに2つのプロットが表示されるはずです：現在のレイテンシの *p90*（**Signal A**）が青で表示され、1週間前の *p90*（**Signal B**）がピンクで表示されます。 - -それらの違いを解釈しやすくするために、**Area chart** アイコン **(1)** をクリックして可視化スタイルを変更します。これにより、曲線の下の領域が強調表示され、先週のレイテンシが現在の値より高かった時期を見つけやすくなります。 - -次に、Overrideバーの **Time (2)** の横にあるフィールドをクリックし、ドロップダウンから **Past Hour (3)** を選択して時間範囲を更新します。 -![Timeframe](../../images/a-b-area.png) - ---- - -### 2. 数式の使用 - -次に、2つの時間シフトされたメトリクス値の差を計算することで、さらに一歩進めましょう。たとえば、今日のデータをちょうど1週間前のデータと比較します。 - -行 **C (1)** の {{% button style=blue %}}Enter Formula{{% /button %}} ボタンをクリックし、**A - B** **(2)** と入力して **Signal B** を **Signal A** から減算します。これにより、**C** というラベルの新しい計算シグナルが作成されます。 - -この数式の結果のみに焦点を当てるには、**A (3)** と **B (4)** の横にある目のアイコンをクリックして他のシグナルを非表示にし、**C** のみを表示したままにします。 - -![C only](../../images/c-only.png) - -現在のメトリクス値（**A**）と1週間前の値（**B**）の差を表す単一の線が表示されるはずです。チャートでは、一部の値が負になることがあります。これは、その時点で古いメトリクス（**B**）が現在のもの（**A**）より高かった場合に発生します。 - -ビジュアルチャート分析を探索したので、次のセクションでチャートとDetectorを駆動するSignalFlowの仕組みを見てみましょう！ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-08-signalflow.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-08-signalflow.md deleted file mode 100644 index ff0255ca21..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-08-signalflow.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: SignalFlow の使用 -linkTitle: 1.08. Signalflow -weight: 1.08 ---- - -## 1. SignalFlow の紹介 - -それでは、Splunk Observability Cloudを支える強力な分析言語である **SignalFlow** を詳しく見てみましょう。SignalFlowを使用すると、監視ロジックをコードとして定義でき、メトリクスを扱いアラートを自動化するための柔軟でリアルタイムな方法を提供します。 - -**Splunk Infrastructure Monitoring** の中核には、ストリーミングメトリクスデータをリアルタイムで処理する **SignalFlow 分析エンジン** があります。SignalFlowはPythonに似た構文で記述され、**メトリクス時系列（MTS）** を取り込み、変換や計算を実行し、新しいMTSを出力する計算を構築できます。 - -SignalFlowの一般的なユースケースには以下が含まれます： - -* 週次比較など、現在の値と過去のトレンドの比較 -* 分散パーセンタイルチャートを使用した母集団レベルの洞察の作成 -* Service Level Objective（SLO）違反の検出など、変化率やしきい値の監視 -* ディスク容量不足アラートの増加に関連するサービスの特定など、相関ディメンションの識別 - -**Chart Builder** インターフェースでメトリクスを選択し、分析関数を視覚的に適用することで、SignalFlowベースの計算を直接作成できます。より高度なユースケースでは、**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** をクリックして、チャートを駆動する基盤となるコードを開きます。 - -![SignalFlow](../../images/view-signalflow.png) - -**View SignalFlow** をクリックすると、チャートの背後にあるロジックと変換を定義する **SignalFlow プログラム (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に戻ります。 - -![View Builder](../../images/show-signalflow.png) - -この新しいチャートをダッシュボードに保存しましょう！ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-09-adding-charts.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-09-adding-charts.md deleted file mode 100644 index 2f31e9a9ea..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-09-adding-charts.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: ダッシュボードへのチャートの追加 -linkTitle: 1.09. Adding more charts -weight: 1.09 ---- - -## 1. 既存のダッシュボードへの保存 - -チャートを保存する前に、左上隅で **YOUR_NAME-Dashboard: YOUR_NAME-Dashboard (1)** が選択されていることを確認してください。これにより、チャートが正しいダッシュボードに保存されます。 - -次に、チャートに名前を付けます。**Latency History** **(2)** と入力し、必要に応じて **Chart Description (3)** に簡単な説明を追加してください（例のように）。 -![Save Chart 1](../../images/morecharts-1.png) - ---- -準備ができたら、{{% button style=blue %}}Save And Close{{% /button %}} ボタン **(4)** をクリックします。ダッシュボードに戻り、2つのチャートが含まれるようになります。 -![Save Chart 2](../../images/morecharts-2.png) - ---- - -## 2. チャートのコピーと貼り付け - -次に、先ほど作成したチャートを複製して、別のチャートをすばやく追加しましょう。 - -ダッシュボードで **Latency History** チャートを見つけ、チャートの右上隅にあるthree dots **`...`** **(1)** をクリックします。メニューから **Copy (2)** を選択します。 - -コピー後、ページ上部の **+** アイコン **(3)** の前に小さな白い **1** が表示されます。これは、1つのチャートが貼り付け可能であることを示しています。 -![Copy chart](../../images/morecharts-3.png) - ---- -ページ上部の **+** アイコン **(1)** をクリックし、ドロップダウンメニューで **(2)** を選択します。 -その行の末尾にも **1** が表示され、コピーしたチャートが追加可能であることを確認できます。 -![Past charts](../../images/morecharts-4.png) - -これにより、前のチャートのコピーがダッシュボードに配置されます。 -![Three Dashboard](../../images/morecharts-5.png) - ---- - -## 3. 貼り付けたチャートの編集 - -複製したチャートを編集するには、ダッシュボード内の **Latency History** チャートの1つでthree dots **`...`** をクリックし、**Open** を選択します。または、チャートのタイトル **Latency History** を直接クリックしてエディタで開くこともできます。 - -これにより、再びエディタ環境に移動します。 - -まず、チャートの右上隅にある時間範囲を調整します。最近のデータをより広く表示するために **Past 1 Hour (1)** に設定します。 - -次に、チャートをカスタマイズしてユニークにしましょう。**Signal A (2)** の横にある目のアイコンをクリックして、再び表示させます。 -次に、**Signal C (3)** の目のアイコンをクリックして非表示にします。 - -チャートタイトルを *Latency history* から **Latency vs Load (4)** に更新し、必要に応じてチャートの説明を追加または編集して、更新されたフォーカスを反映させます **(5)**。 -![Set Visibility](../../images/morecharts-6.png) - ---- -{{% 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)** に変更して、チャート内での役割をより明確に反映させます。 - -![rollup change](../../images/rollout-change.png) - -最後に {{% button %}}Save And Close{{% /button %}} ボタンを押します。これにより、3つの異なるチャートを持つダッシュボードに戻ります！ - -![three charts](../../images/3-charts.png) - -「説明」ノートを追加してチャートを配置しましょう！ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md deleted file mode 100644 index ea23f6840e..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/1-10-notes-and-layout.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: ノートとダッシュボードレイアウトの追加 -linkTitle: 1.10 Notes and layout -weight: 1.10 ---- - -## 1. ノートの追加 - -ダッシュボードでは、ユーザーを支援する短い「説明」ペインを配置することが有効な場合がよくあります。{{% button %}}**New Text Note**{{% /button %}} ボタンをクリックして、今すぐ追加しましょう。 - -![three charts](../../images/add-notes.png) - -これによりノートエディタが開きます。 - -![Notes 1](../../images/notes-editor.png) - -テキストだけでなくさらに多くのものをノートに追加できるように、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 %}} ボタンを押します。 - -![saving note](../../images/notes-with-example.png) - -これにより、ノートを含むダッシュボードに戻ります。 - -![three charts and note](../../images/3-charts-and-note.png) - ---- - -## 3. チャートの順序とサイズ - -チャートのデフォルトの順序とサイズが気に入らない場合は、ウィンドウのドラッグ技術を使用して、目的の場所に移動およびサイズ変更できます。 - -チャートの **上部** の境界線をつかむと、マウスポインターがドラッグアイコンに変わるのが確認できます（下の図を参照）。 - -![dragging charts](../../images/M-Notes-4.png) - -**Latency vs Load** チャートを **Latency History** チャートと **Example text chart** の間にドラッグします。 - -![sizing](../../images/M-Notes-5.png) - -左、右、下の端からドラッグして、ウィンドウのサイズを変更することもできます。 - -最後の演習として、ノートチャートの幅を他のチャートの約3分の1に縮小します。チャートは、サポートするサイズの1つに自動的にスナップします。他の3つのチャートをダッシュボードの約3分の1の幅に広げます。ノートを他のチャートの右側にドラッグし、他の3つのチャートと一致するようにサイズを変更します。**Time** を **-1h** に設定すると、以下のようなダッシュボードができあがります！ - -![TaDA!](../../images/M-Notes-6.png) diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/_index.md b/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/_index.md deleted file mode 100644 index 4762fb6a8d..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/dashboards/_index.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: ダッシュボード入門 -linkTitle: 1. Dashboards -weight: 1.0 -time: 10 minutes ---- - -## 1. ダッシュボード - -ダッシュボードは、主要なメトリクスを1か所に表示するチャートと可視化のコレクションです。適切に設計されたダッシュボードは、システムの健全性とパフォーマンスに関する迅速で実用的な洞察を提供します。シンプルなものから詳細なものまで、いくつかのフォーカスされたチャートから複数のサービスにまたがる複雑なビューまで、必要に応じて作成できます。 - -このモジュールでは、いくつかのチャートを作成し、それらを以下のカスタムダッシュボードにまとめます。 - -![Example Dashboard](../images/example-dashboard.png) - ---- - -## 2. ダッシュボードへのアクセス - -まず、Splunk Observability Suiteでダッシュボードを見つけましょう。 - -左側のナビゲーションメニューで **Dashboards (1)** ボタンをクリックします。メニューが折りたたまれている場合は、画面左上のハンバーガーアイコンをクリックして展開できます。 - -これにより、メインのダッシュボードビューに移動し、Splunk Observabilityによって提供される事前構築されたダッシュボードを含むすべての利用可能なダッシュボードが表示されます。 - -組織がCloud API統合またはSplunk OpenTelemetry Agentを通じてすでにデータを取り込んでいる場合は、それらのサービスに関連する追加のダッシュボードも表示されることがあります。 - -![Sample Data](../images/sample-data.png) diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/detectors/_index.md b/content/ja/ninja-workshops/7-dashboards-detectors/detectors/_index.md deleted file mode 100644 index 6ac930124c..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/detectors/_index.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Detector の操作 -linkTitle: 2. Detectors -weight: 2.0 -time: 10 minutes -hidden: true ---- - -* チャートからDetectorを作成する -* アラート条件の設定 -* プリフライトチェックの実行 -* ミュートルールの操作 - ---- - -## 1. はじめに - -Splunk Observability Cloudは、特定の条件が満たされたときに通知するために、Detector、イベント、アラート、および通知を使用します。たとえば、CPU使用率が95% に達したとき、または同時ユーザー数が追加のAWSインスタンスを起動する必要があるかもしれない制限に近づいているときに、SlackチャンネルまたはOpsチームのメールアドレスにメッセージを送信したい場合があります。 - -これらの条件は、ルール内の条件が満たされたときにアラートをトリガーする1つ以上のルールとして表現されます。Detector内の個々のルールは、重要度に応じてラベル付けされます：Info、Warning、Minor、Major、およびCritical。 - -## 2. Detector の作成 - -**Dashboards** で、（前のモジュールで作成した）**Custom Dashboard Group** をクリックし、ダッシュボード名をクリックします。 - -![Custom Dashboard Group](../images/custom-dashboard-group.png) - -このダッシュボードのチャートから新しいDetectorを作成します。**Latency vs Load** チャートのベルアイコンをクリックし、次に **New Detector From Chart** をクリックします。 - -![New Detector](../images/new-detector.png) - -**Detector Name** の横にあるテキストフィールドで、提案されたDetector名の前に **イニシャルを追加** してください。 - -{{% notice title="Naming the detector" style="info" %}} -提案されたDetector名の前にイニシャルを追加することが重要です。 - -次のようになるはずです：**XYZ's Latency Chart Detector**。 -{{% /notice %}} - -{{% button style="blue" %}}Create Alert Rule{{% /button %}} をクリックします。 - -![Create Alert Rule](../images/create-alert-rule.png) - -Detectorウィンドウの **Alert signal** 内で、アラートを発するシグナルは **Alert on** 列に（青い）ベルでマークされています。ベルは、アラートの生成に使用されているシグナルを示しています。 - -{{% button style="blue" %}}Proceed to Alert Condition{{% /button %}} をクリックします。 - -![Alert Signal](../images/alert-signal.png) - -## 3. アラート条件の設定 - -**Alert condition** で、**Static Threshold** をクリックし、次に {{% button style="blue" %}}Proceed to Alert Settings{{% /button %}} をクリックします。 - -![Alert Condition](../images/alert-condition.png) - -**Alert Settings** で、**Threshold** フィールドに値 **`290`** を入力します。同じウィンドウで、右上の **Time** を過去1日（**-1d**）に変更します。 - ---- - -## 4. アラートのプリフライトチェック - -5秒後にプリフライトチェックが実行されます。**Estimated alert count** を確認してください。現在のアラート設定に基づくと、1日で受信したはずのアラート数は **3** です。 - -![Alert Threshold](../images/alert-threshold.png) - -{{% notice title="About pre-flight checks" style="info" %}} -アラート条件を設定すると、UIは現在の設定と、右上隅に設定された時間枠（この場合は過去1日）に基づいて、受信する可能性のあるアラート数を推定します。 - -すぐに、プラットフォームは現在の設定でシグナルの分析を開始し、プリフライトチェックと呼ばれるものを実行します。これにより、プラットフォーム内の履歴データを使用してアラート条件をテストでき、設定が論理的であり、意図せずアラートストームを生成しないことを確認できます。これは、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** を選択します。 - -![Alert Message](../images/alert-message.png) - -{{% button style="blue" %}}Proceed to Alert Recipients{{% /button %}} をクリックします。 - -**Add Recipient** をクリックし、最初のオプションとして表示されているメールアドレスをクリックします。 - -![Add Recipient](../images/add-recipient.png) - -{{% 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 %}} をクリックします。 - -![Activate Alert](../images/activate-alert.png) - -アラートをより早く受け取りたい場合は、ルールを編集して値を **`290`** から **`280`** などに下げることができます。 - -**Time** を **-1h** に変更すると、過去1時間のメトリクスに基づいて、選択したしきい値でいくつのアラートを受け取る可能性があるかを確認できます。 - -ナビゲーションバーの ![alerts and detectors button](../images/alerts-and-detectors.png?classes=inline&height=25px) をクリックし、次に **Detectors** をクリックします。オプションでイニシャルでフィルターできます。ここにDetectorがリストされているはずです。表示されない場合は、ブラウザを更新してください。 - -![Detector List](../images/detectors.png) - -**おめでとうございます**！最初のDetectorを作成し、有効化しました！ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/detectors/muting.md b/content/ja/ninja-workshops/7-dashboards-detectors/detectors/muting.md deleted file mode 100644 index 4f93cc1ecf..0000000000 --- a/content/ja/ninja-workshops/7-dashboards-detectors/detectors/muting.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: ミュートルールの操作 -linkTitle: 2.1 Creating a Muting Rule -weight: 2.1 ---- - -* ミュートルールの設定方法を学ぶ -* 通知の再開方法を学ぶ - ---- - -## 1. ミュートルールの設定 - -特定の通知をミュートしたい場合があります。たとえば、サーバーまたはサーバーセットのメンテナンスのためにダウンタイムをスケジュールする場合や、新しいコードや設定をテストする場合などです。そのために、Splunk Observability Cloudでミュートルールを使用できます。作成してみましょう！ - -サイドバーの **Alerts & Detectors** をクリックし、**Detectors** をクリックしてアクティブなDetectorのリストを表示します。 - -![detectors list](../../images/detectors.png) - -**Creating a Detector** でDetectorを作成した場合は、そのDetectorの右端にあるthree dots **`...`** をクリックできます。作成していない場合は、別のDetectorで同様に行ってください。 - -ドロップダウンから **Create Muting Rule...** をクリックします。 - -![Create Muting Rule](../../images/create-muting-rule.png) - -**Muting Rule** ウィンドウで **Mute Indefinitely** にチェックを入れ、理由を入力します。 - -{{% notice title="Important" style="info" %}} -これにより、ここに戻ってこのチェックボックスをオフにするか、このDetectorの通知を再開するまで、通知は永続的にミュートされます。 -{{% /notice %}} - -![Mute Indefinitely](../../images/mute-indefinitely.png) - -**Next** をクリックし、新しいモーダルウィンドウでミュートルールの設定を確認します。 - -![Confirm Rule](../../images/confirm-rule.png) - -{{% button style="blue" %}}Mute Indefinitely{{% /button %}} をクリックして確認します。 - -![List muted rule](../../images/alert-muted.png) - -通知を再開するまで、Detectorからのメール通知は届きません。それでは、その方法を見てみましょう！ - ---- - -## 2. 通知の再開 - -通知を再開するには、**Muting Rules** をクリックすると、**Detector** の見出しの下に通知をミュートしたDetectorの名前が表示されます。 - -右端のthree dots **`...`** をクリックし、**Resume Notifications** をクリックします。 - -![Resume](../../images/muting-list.png) - -{{% button style="blue" %}}Resume{{% /button %}} をクリックして、このDetectorの通知を確認して再開します。 - -![Resume](../../images/resume.png) - -**おめでとうございます**！アラート通知を再開しました！ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/3-charts-and-note.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/3-charts-and-note.png deleted file mode 100644 index ed08c9049c..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/3-charts-and-note.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/3-charts.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/3-charts.png deleted file mode 100644 index 29e477d11c..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/3-charts.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-4.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-4.png deleted file mode 100644 index f4609a2b17..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-4.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-5.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-5.png deleted file mode 100644 index 29e0168616..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-5.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-6.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-6.png deleted file mode 100644 index 8e9569f9f3..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/M-Notes-6.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/a-b-area.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/a-b-area.png deleted file mode 100644 index 6c417897e1..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/a-b-area.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/ab-plot-full.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/ab-plot-full.png deleted file mode 100644 index 38c508e617..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/ab-plot-full.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/add-notes.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/add-notes.png deleted file mode 100644 index 90e0d6bd9d..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/add-notes.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/b-pink.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/b-pink.png deleted file mode 100644 index 6ff20a66dd..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/b-pink.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/b-shifted.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/b-shifted.png deleted file mode 100644 index b58e810fe2..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/b-shifted.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/c-only.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/c-only.png deleted file mode 100644 index 6ab641a7a4..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/c-only.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/change-to-heatmap.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/change-to-heatmap.png deleted file mode 100644 index 329038d28a..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/change-to-heatmap.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/change-to-line.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/change-to-line.png deleted file mode 100644 index 87809ac95d..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/change-to-line.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/chartbartypes.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/chartbartypes.png deleted file mode 100644 index fe46177eab..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/chartbartypes.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/choose-dashboard.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/choose-dashboard.png deleted file mode 100644 index adf513441b..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/choose-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/create-dashboard.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/create-dashboard.png deleted file mode 100644 index ad897b2adb..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/create-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/data-table.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/data-table.png deleted file mode 100644 index c6d0086332..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/data-table.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/empty-new-chart.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/empty-new-chart.png deleted file mode 100644 index a4a6ccb4dc..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/empty-new-chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/example-dashboard.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/example-dashboard.png deleted file mode 100644 index 5dc5c99577..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/example-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/latency-histogram-open.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/latency-histogram-open.png deleted file mode 100644 index 94460ac89c..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/latency-histogram-open.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/latency-histogram.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/latency-histogram.png deleted file mode 100644 index 32d108ec8f..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/latency-histogram.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/line-chart-15-mins.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/line-chart-15-mins.png deleted file mode 100644 index 3fb58c3474..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/line-chart-15-mins.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-1.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-1.png deleted file mode 100644 index 8a76410956..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-1.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-2.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-2.png deleted file mode 100644 index c52bd0b121..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-2.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-3.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-3.png deleted file mode 100644 index 6808c6a545..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-3.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-4.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-4.png deleted file mode 100644 index 11d5a72ab6..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-4.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-5.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-5.png deleted file mode 100644 index f58339fabf..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-5.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-6.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-6.png deleted file mode 100644 index e58bf5df9b..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/morecharts-6.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/name-chart.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/name-chart.png deleted file mode 100644 index 39979785b5..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/name-chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/name-dashboard.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/name-dashboard.png deleted file mode 100644 index 1132c8dba6..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/name-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/new-chart.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/new-chart.png deleted file mode 100644 index ae50812ddc..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/new-chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/new-dashboard-group.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/new-dashboard-group.png deleted file mode 100644 index bccce1717a..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/new-dashboard-group.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/notes-editor.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/notes-editor.png deleted file mode 100644 index 22d8dc881c..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/notes-editor.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/notes-with-example.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/notes-with-example.png deleted file mode 100644 index d40fe3acc1..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/notes-with-example.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/plot-editor.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/plot-editor.png deleted file mode 100644 index e1e190ceca..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/plot-editor.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/prepare_filter.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/prepare_filter.png deleted file mode 100644 index dc5586cc8b..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/prepare_filter.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/rollout-change.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/rollout-change.png deleted file mode 100644 index f6695ebdf3..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/rollout-change.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/sample-charts.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/sample-charts.png deleted file mode 100644 index 991635727b..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/sample-charts.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/sample-data.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/sample-data.png deleted file mode 100644 index 763a6495e1..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/sample-data.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/save-chart.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/save-chart.png deleted file mode 100644 index bcc9d64211..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/save-chart.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/secure-dashboard.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/secure-dashboard.png deleted file mode 100644 index 8c6d8bdc2b..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/secure-dashboard.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/select-filter.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/select-filter.png deleted file mode 100644 index f50c7b588e..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/select-filter.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/show-signalflow.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/show-signalflow.png deleted file mode 100644 index aec9c258f1..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/show-signalflow.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/time_window.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/time_window.png deleted file mode 100644 index 0244478340..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/time_window.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/timeshift-filter.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/timeshift-filter.png deleted file mode 100644 index b4dd710186..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/timeshift-filter.png and /dev/null differ diff --git a/content/ja/ninja-workshops/7-dashboards-detectors/images/view-signalflow.png b/content/ja/ninja-workshops/7-dashboards-detectors/images/view-signalflow.png deleted file mode 100644 index 0191d75fd3..0000000000 Binary files a/content/ja/ninja-workshops/7-dashboards-detectors/images/view-signalflow.png and /dev/null differ diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/1-connect-to-instance.md b/content/ja/ninja-workshops/8-docker-k8s-otel/1-connect-to-instance.md deleted file mode 100644 index d249d9b1cb..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/1-connect-to-instance.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: EC2インスタンスへの接続 -linkTitle: 1. EC2インスタンスへの接続 -weight: 1 -time: 5 minutes ---- - -## EC2 インスタンスへ接続 - -各参加者のために、AWS/EC2にUbuntu Linuxインスタンスを用意しました。 - -インストラクターから提供されたIPアドレスとパスワードを使用して、以下のいずれかの方法でEC2インスタンスに接続してください - -- Mac OS / Linux - - ssh splunk@IPアドレス -- Windows 10+ - - OpenSSHクライアントを使用 -- 以前のバージョンのWindows - - Puttyを使用 diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/10-troubleshoot-collector.md b/content/ja/ninja-workshops/8-docker-k8s-otel/10-troubleshoot-collector.md deleted file mode 100644 index b1fd77733e..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/10-troubleshoot-collector.md +++ /dev/null @@ -1,348 +0,0 @@ ---- -title: OpenTelemetry Collectorの問題をトラブルシュート -linkTitle: 10. OpenTelemetry Collectorの問題をトラブルシュート -weight: 10 -time: 20 minutes ---- - -前のセクションでは、コレクター設定にdebug exporterを追加し、 -traceとlogのパイプラインの一部として設定しました。期待通り、debug出力が -agent collectorのlogに書き込まれていることが確認できます。 - -しかし、traceがo11y cloudに送信されなくなりました。原因を特定して修正しましょう。 - -## コレクター設定の確認 - -`values.yaml` ファイルを使用してコレクター設定を変更した場合は、 -config mapを確認して、コレクターに適用された実際の設定を確認すると便利です - -``` bash -kubectl describe cm splunk-otel-collector-otel-agent -``` - -agent collectorの設定にあるlogとtraceのパイプラインを確認しましょう。以下のように -なっているはずです - -``` yaml - pipelines: - logs: - exporters: - - debug - processors: - - memory_limiter - - k8s_attributes - - filter/logs - - batch - - resourcedetection - - resource - - resource/logs - - resource/add_environment - receivers: - - filelog - - otlp - ... - traces: - exporters: - - debug - processors: - - memory_limiter - - k8s_attributes - - batch - - resourcedetection - - resource - - resource/add_environment - receivers: - - otlp - - jaeger - - zipkin -``` - -問題がわかりますか？traceとlogのパイプラインにはdebug exporterしか含まれていません。 -以前traceパイプラインの設定に存在していた `otlp_http` と `signalfx` のexporterがなくなっています。 -これが、o11y cloudでtraceが表示されなくなった原因です。また、logパイプラインからは -`splunk_hec/platform_logs` exporterが削除されています。 - -> 以前どの特定のexporterが含まれていたかをどうやって知ったのでしょうか？確認するには、 -> 以前のカスタマイズを元に戻してからconfig mapを確認し、traceパイプラインに -> 元々何が含まれていたかを確認する方法があります。あるいは、 -> [GitHub repo for splunk-otel-collector-chart](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/examples/default/rendered_manifests/configmap-agent.yaml) -> の例を参照して、Helmチャートで使用されるデフォルトのagent設定を確認することもできます。 - -## これらのexporterはなぜ削除されたのか？ - -`values.yaml` ファイルに追加したカスタマイズを確認しましょう - -``` yaml -logsEngine: otel -splunkObservability: - infrastructureMonitoringEventsEnabled: true -agent: - config: - receivers: - ... - exporters: - debug: - verbosity: detailed - service: - pipelines: - traces: - exporters: - - debug - logs: - exporters: - - debug -``` - -`helm upgrade` を使用して `values.yaml` ファイルをコレクターに適用すると、 -カスタム設定が以前のコレクター設定とマージされます。 -この際、パイプラインセクションのexporterリストのように、リストを含む `yaml` 設定の -セクションは、`values.yaml` ファイルに含めた内容（この場合はdebug exporterのみ）で -置き換えられます。 - -## 問題を修正しましょう - -そのため、既存のパイプラインをカスタマイズする場合は、設定のその部分を完全に再定義する必要があります。 -`values.yaml` ファイルを以下のように更新する必要があります - -``` yaml -logsEngine: otel -splunkObservability: - infrastructureMonitoringEventsEnabled: true -agent: - config: - receivers: - ... - exporters: - debug: - verbosity: detailed - service: - pipelines: - traces: - exporters: - - otlp_http - - signalfx - - debug - logs: - exporters: - - splunk_hec/platform_logs - - debug -``` - -変更を適用しましょう - -``` bash -helm upgrade splunk-otel-collector \ - --set="splunkObservability.realm=$REALM" \ - --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ - --set="clusterName=$INSTANCE-cluster" \ - --set="environment=otel-$INSTANCE" \ - --set="splunkPlatform.token=$HEC_TOKEN" \ - --set="splunkPlatform.endpoint=$HEC_URL" \ - --set="splunkPlatform.index=splunk4rookies-workshop" \ - -f values.yaml \ -splunk-otel-collector-chart/splunk-otel-collector -``` - -次に、agent config mapを確認します - -``` bash -kubectl describe cm splunk-otel-collector-otel-agent -``` - -今回は、logとtraceの両方で完全に定義されたexporterパイプラインが表示されるはずです - -``` bash - pipelines: - logs: - exporters: - - splunk_hec/platform_logs - - debug - processors: - ... - traces: - exporters: - - otlp_http - - signalfx - - debug - processors: - ... -``` - -## ログ出力の確認 - -**Splunk Distribution of OpenTelemetry .NET** は、`Microsoft.Extensions.Logging` を使用してログを記録する -アプリケーション（サンプルアプリもこれを使用しています）から、トレーシングコンテキストが付与されたログを -自動的にエクスポートします。 - -アプリケーションログにはトレーシングメタデータが付与され、OTLP形式でローカルの -OpenTelemetry Collectorインスタンスにエクスポートされます。 - -debug exporterでキャプチャされたログを詳しく確認して、これが実際に行われているか見てみましょう。 -コレクターのログをtailするには、以下のコマンドを使用します - -``` bash -kubectl logs -l component=otel-collector-agent -f -``` - -ログをtailしている状態で、curlを使用してトラフィックを生成します。すると、以下のような -出力が表示されるはずです - -```` -2024-12-20T21:56:30.858Z info Logs {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 1} -2024-12-20T21:56:30.858Z info ResourceLog #0 -Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 -Resource attributes: - -> splunk.distro.version: Str(1.8.0) - -> telemetry.distro.name: Str(splunk-otel-dotnet) - -> telemetry.distro.version: Str(1.8.0) - -> os.type: Str(linux) - -> os.description: Str(Debian GNU/Linux 12 (bookworm)) - -> os.build_id: Str(6.8.0-1021-aws) - -> os.name: Str(Debian GNU/Linux) - -> os.version: Str(12) - -> host.name: Str(derek-1) - -> process.owner: Str(app) - -> process.pid: Int(1) - -> process.runtime.description: Str(.NET 8.0.11) - -> process.runtime.name: Str(.NET) - -> process.runtime.version: Str(8.0.11) - -> container.id: Str(5bee5b8f56f4b29f230ffdd183d0367c050872fefd9049822c1ab2aa662ba242) - -> telemetry.sdk.name: Str(opentelemetry) - -> telemetry.sdk.language: Str(dotnet) - -> telemetry.sdk.version: Str(1.9.0) - -> service.name: Str(helloworld) - -> deployment.environment: Str(otel-derek-1) - -> k8s.node.name: Str(derek-1) - -> k8s.cluster.name: Str(derek-1-cluster) -ScopeLogs #0 -ScopeLogs SchemaURL: -InstrumentationScope HelloWorldController -LogRecord #0 -ObservedTimestamp: 2024-12-20 21:56:28.486804 +0000 UTC -Timestamp: 2024-12-20 21:56:28.486804 +0000 UTC -SeverityText: Information -SeverityNumber: Info(9) -Body: Str(/hello endpoint invoked by {name}) -Attributes: - -> name: Str(Kubernetes) -Trace ID: 78db97a12b942c0252d7438d6b045447 -Span ID: 5e9158aa42f96db3 -Flags: 1 - {"kind": "exporter", "data_type": "logs", "name": "debug"} -```` - -この例では、OpenTelemetry .NETの計装によって、Trace IDとSpan IDがログ出力に -自動的に書き込まれていることがわかります。これにより、Splunk Observability Cloudで -ログとトレースを関連付けることができます。 - -ただし、Helmを使用してK8sクラスターにOpenTelemetry Collectorをデプロイし、 -ログ収集オプションを含めた場合、OpenTelemetry CollectorはFile Log receiverを使用して -コンテナログを自動的にキャプチャすることを覚えているかもしれません。 - -これにより、アプリケーションのログが重複してキャプチャされることになります。例えば、以下のスクリーンショットでは、 -サービスへの各リクエストに対して2つのログエントリが表示されています - -![Duplicate Log Entries](../images/duplicate_logs.png) - -これをどのように回避すればよいでしょうか？ - -## K8sでのログの重複を回避する - -ログの重複キャプチャを回避するには、`OTEL_LOGS_EXPORTER` 環境変数を `none` に設定して、 -Splunk Distribution of OpenTelemetry .NETがOTLPを使用してコレクターにログをエクスポートしないように -指定します。これは、`deployment.yaml` ファイルに `OTEL_LOGS_EXPORTER` 環境変数を追加することで -実現できます - -``` yaml - env: - - name: PORT - value: "8080" - - name: NODE_IP - valueFrom: - fieldRef: - fieldPath: status.hostIP - - name: OTEL_EXPORTER_OTLP_ENDPOINT - value: "http://$(NODE_IP):4318" - - name: OTEL_SERVICE_NAME - value: "helloworld" - - name: OTEL_RESOURCE_ATTRIBUTES - value: "deployment.environment=otel-$INSTANCE" - - name: OTEL_LOGS_EXPORTER - value: "none" -``` - -そして以下を実行します - -``` bash -# update the deployment -kubectl apply -f deployment.yaml -``` - -`OTEL_LOGS_EXPORTER` 環境変数を `none` に設定するのは簡単です。しかし、Trace IDと -Span IDはアプリケーションが生成するstdoutログには書き込まれないため、 -ログとトレースを関連付けることができなくなります。 - -これを解決するには、カスタムロガーを定義する必要があります。例えば、 -`/home/splunk/workshop/docker-k8s-otel/helloworld/SplunkTelemetryConfigurator.cs` に -定義されている例を使用できます。 - -`Program.cs` ファイルを以下のように更新することで、アプリケーションに組み込むことができます - -``` cs -using SplunkTelemetry; -using Microsoft.Extensions.Logging.Console; - -var builder = WebApplication.CreateBuilder(args); - -builder.Services.AddControllers(); - -SplunkTelemetryConfigurator.ConfigureLogger(builder.Logging); - -var app = builder.Build(); - -app.MapControllers(); - -app.Run(); -``` - -次に、カスタムログ設定を含む新しいDockerイメージをビルドします - -``` bash -cd /home/splunk/workshop/docker-k8s-otel/helloworld - -docker build -t helloworld:1.3 . -``` - -そして、更新されたイメージをローカルコンテナリポジトリにインポートします - -``` bash -cd /home/splunk - -# Tag the image -docker tag helloworld:1.3 localhost:9999/helloworld:1.3 - -# Import the image into our local container repo -docker push localhost:9999/helloworld:1.3 -``` - -最後に、コンテナイメージのバージョン1.3を使用するように `deployment.yaml` ファイルを -更新する必要があります - -``` yaml - spec: - containers: - - name: helloworld - image: localhost:9999/helloworld:1.3 -``` - -そして変更を適用します - -``` bash -# update the deployment -kubectl apply -f deployment.yaml -``` - -これで、重複したログエントリが解消されたことが確認できます。残りのログエントリは -JSON形式でフォーマットされ、spanとtrace IDが含まれています - -![JSON Format Logs](../images/logs_json_format.png) diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/11-summary.md b/content/ja/ninja-workshops/8-docker-k8s-otel/11-summary.md deleted file mode 100644 index 65cf362a1d..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/11-summary.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Summary -linkTitle: 11. Summary -weight: 11 -time: 2 minutes ---- - -このワークショップでは、以下の概念についてハンズオンで体験しました - -- Linuxホストに**Splunk Distribution of the OpenTelemetry Collector**をデプロイする方法。 -- **Splunk Distribution of OpenTelemetry .NET**で.NETアプリケーションを計装する方法。 -- .NETアプリケーションを「Docker化」し、**Splunk Distribution of OpenTelemetry .NET**で計装する方法。 -- Helmを使用してKubernetesクラスターに**Splunk Distribution of the OpenTelemetry Collector**をデプロイする方法。 -- コレクター設定をカスタマイズして問題をトラブルシューティングする方法。 - -他の言語と環境でOpenTelemetryがどのように計装されるかを確認するには、 -[Splunk OpenTelemetry Examples GitHub リポジトリ](https://github.com/signalfx/splunk-opentelemetry-examples)をご覧ください。 - -将来このワークショップを独自に実行するには、これらの手順を参照して、Splunk Showの**Splunk4Rookies - Observability** -ワークショップテンプレートを使用してEC2インスタンスをプロビジョニングしてください。 diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/2-deploy-collector.md b/content/ja/ninja-workshops/8-docker-k8s-otel/2-deploy-collector.md deleted file mode 100644 index 53aaf489d7..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/2-deploy-collector.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -title: OpenTelemetryコレクターのデプロイ -linkTitle: 2. OpenTelemetryコレクターのデプロイ -weight: 2 -time: 10 minutes ---- - -## OpenTelemetry コレクターのアンインストール - -EC2インスタンスには、すでにSplunk DistributionのOpenTelemetryコレクターの古いバージョンが -インストールされている可能性があります。先に進む前に、次のコマンドを使用してアンインストールしましょう - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh; -sudo sh /tmp/splunk-otel-collector.sh --uninstall -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Reading package lists... Done -Building dependency tree... Done -Reading state information... Done -The following packages will be REMOVED: - splunk-otel-collector* -0 upgraded, 0 newly installed, 1 to remove and 167 not upgraded. -After this operation, 766 MB disk space will be freed. -(Reading database ... 157441 files and directories currently installed.) -Removing splunk-otel-collector (0.92.0) ... -(Reading database ... 147373 files and directories currently installed.) -Purging configuration files for splunk-otel-collector (0.92.0) ... -Scanning processes... -Scanning candidates... -Scanning linux images... - -Running kernel seems to be up-to-date. - -Restarting services... - systemctl restart fail2ban.service falcon-sensor.service -Service restarts being deferred: - systemctl restart networkd-dispatcher.service - systemctl restart unattended-upgrades.service - -No containers need to be restarted. - -No user sessions are running outdated binaries. - -No VM guests are running outdated hypervisor (qemu) binaries on this host. -Successfully removed the splunk-otel-collector package -``` - -{{% /tab %}} -{{< /tabs >}} - -## OpenTelemetry collector のデプロイ - -Linux EC2インスタンスに、Splunk DistributionのOpenTelemetryコレクターの最新バージョンをデプロイしましょう。 - -これは `curl` を使用してコレクターバイナリをダウンロードし、特定の引数を指定して実行することで可能です。 -これらの引数は、データを送信するrealm、使用するアクセストークン、 -およびデータを送信するデプロイメント環境をコレクターに指示します。 - -> Splunk Observability Cloud におけるデプロイメント環境とは、システムまたはアプリケーションの個別のデプロイメントであり、同じアプリケーションの他のデプロイメントの設定と重複しない設定を行うことができます。 - -{{< tabs >}} -{{% tab title="Script" %}} - -```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 \ ---mode agent \ ---without-instrumentation \ ---deployment-environment otel-$INSTANCE \ --- $ACCESS_TOKEN -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Splunk OpenTelemetry Collector Version: latest -Memory Size in MIB: 512 -Realm: us1 -Ingest Endpoint: https://ingest.us1.signalfx.com -API Endpoint: https://api.us1.signalfx.com -HEC Endpoint: https://ingest.us1.signalfx.com/v1/log -etc. -``` - -{{% /tab %}} -{{< /tabs >}} - -詳細については、[インストーラースクリプトを使用した Linux 用コレクターのインストール](https://docs.splunk.com/observability/en/gdi/opentelemetry/collector-linux/install-linux.html#otel-install-linux) -を参照してください。 - -## コレクターが実行中であることを確認 - -インスタンスでコレクターが正常に実行されていることを確認しましょう。 - -> ステータスコマンドを終了するには、Ctrl + C を押します。 - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -sudo systemctl status splunk-otel-collector -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -● splunk-otel-collector.service - Splunk OpenTelemetry Collector - Loaded: loaded (/lib/systemd/system/splunk-otel-collector.service; enabled; vendor preset: enabled) - Drop-In: /etc/systemd/system/splunk-otel-collector.service.d - └─service-owner.conf - Active: active (running) since Fri 2024-12-20 00:13:14 UTC; 45s ago - Main PID: 14465 (otelcol) - Tasks: 9 (limit: 19170) - Memory: 117.4M - CPU: 681ms - CGroup: /system.slice/splunk-otel-collector.service - └─14465 /usr/bin/otelcol - -``` - -{{% /tab %}} -{{< /tabs >}} - -## コレクターログの確認方法 - -`journalctl` を使用してコレクターログを表示できます - -> ログの監視を終了するには、Ctrl + C を押します。 - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -sudo journalctl -u splunk-otel-collector -f -n 100 -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Dec 20 00:13:14 derek-1 systemd[1]: Started Splunk OpenTelemetry Collector. -Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:483: Set config to /etc/otel/collector/agent_config.yaml -Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:539: Set memory limit to 460 MiB -Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:524: Set soft memory limit set to 460 MiB -Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:373: Set garbage collection target percentage (GOGC) to 400 -Dec 20 00:13:14 derek-1 otelcol[14465]: 2024/12/20 00:13:14 settings.go:414: set "SPLUNK_LISTEN_INTERFACE" to "127.0.0.1" -etc. -``` - -{{% /tab %}} -{{< /tabs >}} - -## コレクターの設定 - -このコレクターが使用している設定はどこで見つけられるでしょうか？ - -その設定は `/etc/otel/collector` ディレクトリにあります。コレクターを `agent` モードで -インストールしたため、コレクター設定は `agent_config.yaml` ファイルにあります。 diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/3-deploy-dotnet-app.md b/content/ja/ninja-workshops/8-docker-k8s-otel/3-deploy-dotnet-app.md deleted file mode 100644 index 2a2004b7ac..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/3-deploy-dotnet-app.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -title: .NETアプリケーションのデプロイ -linkTitle: 3. .NETアプリケーションのデプロイ -weight: 3 -time: 10 minutes ---- - -## 前提条件 - -アプリケーションをデプロイする前に、インスタンスに.NET 8 SDKをインストールする必要があります。 - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -sudo apt-get update && \ - sudo apt-get install -y dotnet-sdk-8.0 -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Hit:1 http://us-west-1.ec2.archive.ubuntu.com/ubuntu jammy InRelease -Hit:2 http://us-west-1.ec2.archive.ubuntu.com/ubuntu jammy-updates InRelease -Hit:3 http://us-west-1.ec2.archive.ubuntu.com/ubuntu jammy-backports InRelease -Hit:4 http://security.ubuntu.com/ubuntu jammy-security InRelease -Ign:5 https://splunk.jfrog.io/splunk/otel-collector-deb release InRelease -Hit:6 https://splunk.jfrog.io/splunk/otel-collector-deb release Release -Reading package lists... Done -Reading package lists... Done -Building dependency tree... Done -Reading state information... Done -The following additional packages will be installed: - aspnetcore-runtime-8.0 aspnetcore-targeting-pack-8.0 dotnet-apphost-pack-8.0 dotnet-host-8.0 dotnet-hostfxr-8.0 dotnet-runtime-8.0 dotnet-targeting-pack-8.0 dotnet-templates-8.0 liblttng-ust-common1 - liblttng-ust-ctl5 liblttng-ust1 netstandard-targeting-pack-2.1-8.0 -The following NEW packages will be installed: - aspnetcore-runtime-8.0 aspnetcore-targeting-pack-8.0 dotnet-apphost-pack-8.0 dotnet-host-8.0 dotnet-hostfxr-8.0 dotnet-runtime-8.0 dotnet-sdk-8.0 dotnet-targeting-pack-8.0 dotnet-templates-8.0 - liblttng-ust-common1 liblttng-ust-ctl5 liblttng-ust1 netstandard-targeting-pack-2.1-8.0 -0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded. -Need to get 138 MB of archives. -After this operation, 495 MB of additional disk space will be used. -etc. -``` - -{{% /tab %}} -{{< /tabs >}} - -詳細については、[Ubuntu に.NET SDK または.NET Runtime をインストールする](https://learn.microsoft.com/en-us/dotnet/core/install/linux-ubuntu-install?tabs=dotnet8&pivots=os-linux-ubuntu-2404) -を参照してください。 - -## .NET アプリケーションの確認 - -ターミナルで、アプリケーションディレクトリに移動します - -```bash -cd ~/workshop/docker-k8s-otel/helloworld -``` - -このワークショップでは、シンプルな「Hello World」.NETアプリケーションを使用します。主要なロジックは -HelloWorldController.csファイルにあります - -```cs -public class HelloWorldController : ControllerBase -{ - private ILogger logger; - - public HelloWorldController(ILogger logger) - { - this.logger = logger; - } - - [HttpGet("/hello/{name?}")] - public string Hello(string name) - { - if (string.IsNullOrEmpty(name)) - { - logger.LogInformation("/hello endpoint invoked anonymously"); - return "Hello, World!"; - } - else - { - logger.LogInformation("/hello endpoint invoked by {name}", name); - return String.Format("Hello, {0}!", name); - } - } -} -``` - -## .NET アプリケーションのビルドと実行 - -以下のコマンドを使用してアプリケーションをビルドできます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -dotnet build -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -MSBuild version 17.8.5+b5265ef37 for .NET - Determining projects to restore... - All projects are up-to-date for restore. - helloworld -> /home/splunk/workshop/docker-k8s-otel/helloworld/bin/Debug/net8.0/helloworld.dll - -Build succeeded. - 0 Warning(s) - 0 Error(s) - -Time Elapsed 00:00:02.04 -``` - -{{% /tab %}} -{{< /tabs >}} - -ビルドが成功したら、次のように実行できます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -dotnet run -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Building... -info: Microsoft.Hosting.Lifetime[14] - Now listening on: http://localhost:8080 -info: Microsoft.Hosting.Lifetime[0] - Application started. Press Ctrl+C to shut down. -info: Microsoft.Hosting.Lifetime[0] - Hosting environment: Development -info: Microsoft.Hosting.Lifetime[0] - Content root path: /home/splunk/workshop/docker-k8s-otel/helloworld -``` - -{{% /tab %}} -{{< /tabs >}} - -実行したら、UbuntuインスタンスへのSSH接続を2つ目のターミナルで開き、curlを使用してアプリケーションにアクセスします - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -curl http://localhost:8080/hello -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Hello, World! -``` - -{{% /tab %}} -{{< /tabs >}} - -名前を渡すこともできます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -curl http://localhost:8080/hello/Tom -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Hello, Tom! -``` - -{{% /tab %}} -{{< /tabs >}} - -> 次のステップに進む前に、Ctrl + C を押して Helloworld アプリを終了してください。 - -## 次のステップ - -アプリケーションをOpenTelemetryで計装するために使用できる3つの方法は何でしょうか？ - -![Traces](../images/NetInstrumentation.png) - -オプションの詳細については、[Splunk Observability Cloud 用の.NET アプリケーションの計装](https://docs.splunk.com/observability/en/gdi/get-data-in/application/otel-dotnet/instrumentation/instrument-dotnet-application.html) -を参照してください。 diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/4-instrument-app-with-otel.md b/content/ja/ninja-workshops/8-docker-k8s-otel/4-instrument-app-with-otel.md deleted file mode 100644 index fe3a23b182..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/4-instrument-app-with-otel.md +++ /dev/null @@ -1,190 +0,0 @@ ---- -title: OpenTelemetryで.NETアプリケーションを計装する -linkTitle: 4. OpenTelemetryで.NETアプリケーションを計装する -weight: 4 -time: 20 minutes ---- - -## Splunk Distribution of OpenTelemetry のダウンロード - -このワークショップでは、NuGetパッケージを使用せず、Splunk Distribution of OpenTelemetryを -手動でインストールします。 - -最新の `splunk-otel-dotnet-install.sh` ファイルをダウンロードすることから始めます。 -これを使用して.NETアプリケーションを計装します - -```bash -cd ~/workshop/docker-k8s-otel/helloworld - -curl -sSfL https://github.com/signalfx/splunk-otel-dotnet/releases/latest/download/splunk-otel-dotnet-install.sh -O -``` - -インストールプロセスの詳細については、[Splunk Distribution of OpenTelemetry .NET の手動インストール](https://docs.splunk.com/observability/en/gdi/get-data-in/application/otel-dotnet/instrumentation/instrument-dotnet-application.html#install-the-splunk-distribution-of-opentelemetry-net-manually) -を参照してください。 - -## ディストリビューションのインストール - -ターミナルで、以下のようにディストリビューションをインストールします - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -sh ./splunk-otel-dotnet-install.sh -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Downloading v1.8.0 for linux-glibc (/tmp/tmp.m3tSdtbmge/splunk-opentelemetry-dotnet-linux-glibc-x64.zip)... -``` - -{{% /tab %}} -{{< /tabs >}} - -> 注意：上記のコマンドを実行する際には、ARCHITECTURE 環境変数を含める必要がある場合があります -> -> ```bash -> ARCHITECTURE=x64 sh ./splunk-otel-dotnet-install.sh -> ``` - -## 計装の有効化 - -次に、OpenTelemetry計装を有効化できます - -```bash -. $HOME/.splunk-otel-dotnet/instrument.sh -``` - -## デプロイメント環境の設定 - -デプロイメント環境を設定して、データがSplunk Observability Cloud内の独自の -環境に流れるようにしましょう - -```bash -export OTEL_RESOURCE_ATTRIBUTES=deployment.environment=otel-$INSTANCE -``` - -## 計装を使用したアプリケーションの実行 - -以下のようにアプリケーションを実行できます - -```bash -dotnet run -``` - -## チャレンジ - -LinuxインスタンスからC#アプリケーションによってエクスポートされているトレースをどのように確認できるでしょうか？ - -
- 答えを見るにはここをクリック - -これを行う方法は2つあります - -1. `dotnet run` コマンドの開始時に `OTEL_TRACES_EXPORTER=otlp,console` を追加することで、トレースがOTLP経由でコレクターに書き込まれるとともに、コンソールにも書き込まれるようになります。 - -```bash -OTEL_TRACES_EXPORTER=otlp,console dotnet run -``` - -2. あるいは、コレクター設定にデバッグエクスポーターを追加し、それをトレースパイプラインに追加することで、トレースがコレクターログに書き込まれるようになります。 - -```yaml -exporters: - debug: - verbosity: detailed -service: - pipelines: - traces: - receivers: [jaeger, otlp, zipkin] - processors: - - memory_limiter - - batch - - resourcedetection - exporters: [otlphttp, signalfx, debug] -``` - -
- -## アプリケーションへのアクセス - -アプリケーションが実行中になったら、2つ目のSSHターミナルを使用してcurlでアクセスします - -```bash -curl http://localhost:8080/hello -``` - -以前と同様に、`Hello, World!` が返されるはずです。 - -トレースログを有効にした場合は、以下のようなトレースがコンソールまたはコレクターログに書き込まれているのを確認できるはずです - -```bash -info: Program[0] - /hello endpoint invoked anonymously -Activity.TraceId: c7bbf57314e4856447508cd8addd49b0 -Activity.SpanId: 1c92ac653c3ece27 -Activity.TraceFlags: Recorded -Activity.ActivitySourceName: Microsoft.AspNetCore -Activity.DisplayName: GET /hello/{name?} -Activity.Kind: Server -Activity.StartTime: 2024-12-20T00:45:25.6551267Z -Activity.Duration: 00:00:00.0006464 -Activity.Tags: - server.address: localhost - server.port: 8080 - http.request.method: GET - url.scheme: http - url.path: /hello - network.protocol.version: 1.1 - user_agent.original: curl/7.81.0 - http.route: /hello/{name?} - http.response.status_code: 200 -Resource associated with Activity: - splunk.distro.version: 1.8.0 - telemetry.distro.name: splunk-otel-dotnet - telemetry.distro.version: 1.8.0 - service.name: helloworld - os.type: linux - os.description: Ubuntu 22.04.5 LTS - os.build_id: 6.8.0-1021-aws - os.name: Ubuntu - os.version: 22.04 - host.name: derek-1 - host.id: 20cf15fcc7054b468647b73b8f87c556 - process.owner: splunk - process.pid: 16997 - process.runtime.description: .NET 8.0.11 - process.runtime.name: .NET - process.runtime.version: 8.0.11 - container.id: 2 - telemetry.sdk.name: opentelemetry - telemetry.sdk.language: dotnet - telemetry.sdk.version: 1.9.0 - deployment.environment: otel-derek-1 -``` - -## Splunk Observability Cloud でのアプリケーションの確認 - -セットアップが完了したので、トレースが**Splunk Observability Cloud**に送信されていることを確認しましょう。アプリケーションが初回デプロイされた場合、データが表示されるまでに数分かかる場合があることに注意してください。 - -APMにナビゲートし、Environmentドロップダウンを使用してあなたの環境（つまり `otel-instancename`）を選択します。 - -すべてが正しくデプロイされている場合、サービスのリストに `helloworld` が表示されるはずです - -![APM Overview](../images/apm_overview.png) - -右側の**Service Map**をクリックしてサービスマップを表示します。 - -![Service Map](../images/service_map.png) - -次に、右側の**Traces**をクリックして、このアプリケーションでキャプチャされたトレースを確認します。 - -![Traces](../images/traces.png) - -個別のトレースは以下のように表示されるはずです - -![Traces](../images/trace.png) - -> 次のステップに進む前に、Ctrl + C を押して Helloworld アプリを終了してください。 diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/5-dockerize-app.md b/content/ja/ninja-workshops/8-docker-k8s-otel/5-dockerize-app.md deleted file mode 100644 index f93ddd4dc9..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/5-dockerize-app.md +++ /dev/null @@ -1,286 +0,0 @@ ---- -title: アプリケーションのDocker化 -linkTitle: 5. アプリケーションのDocker化 -weight: 5 -time: 15 minutes ---- - -このワークショップの後半では、.NETアプリケーションをKubernetesクラスターにデプロイします。 - -しかし、どのようにそれを行うのでしょうか？ - -最初のステップは、アプリケーション用のDockerイメージを作成することです。これは -アプリケーションの「Docker化」として知られており、プロセスは `Dockerfile` の作成から始まります。 - -しかし、まず重要な用語を定義しましょう。 - -## 重要な用語 - -### Docker とは何ですか？ - -> 「Docker は、コンテナと呼ばれる緩い分離環境でアプリケーションをパッケージ化して実行する機能を提供します。分離とセキュリティにより、指定されたホスト上で同時に多くのコンテナを実行できます。コンテナは軽量で、アプリケーションの実行に必要なすべてを含んでいるため、ホストにインストールされているものに依存する必要がありません。」 - -ソース: - -### コンテナとは何ですか？ - -> 「コンテナは、アプリのコンポーネントごとの分離されたプロセスです。各コンポーネントは...独自の分離された環境で実行され、マシン上の他のすべてのものから完全に分離されています。」 - -ソース: - -### コンテナイメージとは何ですか？ - -> 「コンテナイメージは、コンテナを実行するためのすべてのファイル、バイナリ、ライブラリ、および設定を含む標準化されたパッケージです。」 - -### Dockerfile - -> 「Dockerfile は、コンテナイメージを作成するために使用されるテキストベースのドキュメントです。実行するコマンド、コピーするファイル、起動コマンドなどに関するイメージビルダーへの指示を提供します。」 - -## Dockerfile の作成 - -`/home/splunk/workshop/docker-k8s-otel/helloworld` ディレクトリに `Dockerfile` という名前のファイルを作成しましょう。 - -```bash -cd /home/splunk/workshop/docker-k8s-otel/helloworld -``` - -ファイルの作成にはviまたはnanoを使用できます。viを使用した例を示します - -```bash -vi Dockerfile -``` - -新しく開いたファイルに以下の内容をコピー＆ペーストします - -> 以下のテキストを貼り付ける前に、vi で「i」を押して挿入モードに入ってください。 - -```dockerfile -FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base -USER app -WORKDIR /app -EXPOSE 8080 - -FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build -ARG BUILD_CONFIGURATION=Release -WORKDIR /src -COPY ["helloworld.csproj", "helloworld/"] -RUN dotnet restore "./helloworld/./helloworld.csproj" -WORKDIR "/src/helloworld" -COPY . . -RUN dotnet build "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/build - -FROM build AS publish -ARG BUILD_CONFIGURATION=Release -RUN dotnet publish "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false - -FROM base AS final -WORKDIR /app -COPY --from=publish /app/publish . - -ENTRYPOINT ["dotnet", "helloworld.dll"] -``` - -> vi での変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力してから `enter/return` キーを押します。 - -これはすべて何を意味するのでしょうか？詳しく見てみましょう。 - -## Dockerfile の詳細解説 - -この例では、マルチステージDockerfileを使用しており、Dockerイメージ作成プロセスを以下のステージに分けています - -- Base（ベース） -- Build（ビルド） -- Publish（パブリッシュ） -- Final（最終） - -マルチステージアプローチはより複雑ですが、デプロイメント用により -軽量なランタイムイメージを作成することができます。以下では、 -これらの各ステージの目的を説明します。 - -### ベースステージ - -ベースステージでは、アプリを実行するユーザー、作業ディレクトリを定義し、 -アプリにアクセスするために使用されるポートを公開します。 -これはMicrosoftの `mcr.microsoft.com/dotnet/aspnet:8.0` イメージをベースにしています - -```dockerfile -FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base -USER app -WORKDIR /app -EXPOSE 8080 -``` - -なお、`mcr.microsoft.com/dotnet/aspnet:8.0` イメージには.NET runtimeのみが含まれており、 -SDKは含まれていないため、比較的軽量です。これはDebian 12 Linux -distributionがベースになっています。ASP.NET Core Runtime Dockerイメージの詳細については -[GitHub](https://github.com/dotnet/dotnet-docker/blob/main/README.aspnet.md)で確認できます。 - -### Build ステージ - -Dockerfileの次のステージはbuildステージです。このステージでは、 -`mcr.microsoft.com/dotnet/sdk:8.0` イメージが使用されます。これもDebian 12がベースになっていますが、 -runtimeだけでなく完全な[.NET SDK](https://github.com/dotnet/dotnet-docker/blob/main/README.sdk.md)が含まれています。 - -このステージでは `.csproj` ファイルをbuildイメージにコピーし、その後 `dotnet restore` を使用して -アプリケーションが使用する依存関係をダウンロードします。 - -次に、アプリケーションコードをbuildイメージにコピーし、 -`dotnet build` を使用してプロジェクトとその依存関係を -`.dll` バイナリのセットにビルドします - -```dockerfile -FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build -ARG BUILD_CONFIGURATION=Release -WORKDIR /src -COPY ["helloworld.csproj", "helloworld/"] -RUN dotnet restore "./helloworld/./helloworld.csproj" -WORKDIR "/src/helloworld" -COPY . . -RUN dotnet build "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/build -``` - -### Publish ステージ - -3番目のステージはpublishで、これはMicrosoftイメージではなくbuildステージイメージをベースにしています。このステージでは、`dotnet publish` を使用して -アプリケーションとその依存関係をdeployment用にパッケージ化します - -```dockerfile -FROM build AS publish -ARG BUILD_CONFIGURATION=Release -RUN dotnet publish "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false -``` - -### Final ステージ - -4番目のステージは最終ステージで、これはbase -ステージイメージをベースにしています（buildとpublishステージよりも軽量）。publishステージイメージからの出力をコピーし、 -アプリケーションのentry pointを定義します - -```dockerfile -FROM base AS final -WORKDIR /app -COPY --from=publish /app/publish . - -ENTRYPOINT ["dotnet", "helloworld.dll"] -``` - -## Docker イメージのビルド - -`Dockerfile` ができたので、これを使用してアプリケーションを含むDockerイメージを -ビルドできます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -docker build -t helloworld:1.0 . -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -DEPRECATED: The legacy builder is deprecated and will be removed in a future release. - Install the buildx component to build images with BuildKit: - https://docs.docker.com/go/buildx/ - -Sending build context to Docker daemon 281.1kB -Step 1/19 : FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base -8.0: Pulling from dotnet/aspnet -af302e5c37e9: Pull complete -91ab5e0aabf0: Pull complete -1c1e4530721e: Pull complete -1f39ca6dcc3a: Pull complete -ea20083aa801: Pull complete -64c242a4f561: Pull complete -Digest: sha256:587c1dd115e4d6707ff656d30ace5da9f49cec48e627a40bbe5d5b249adc3549 -Status: Downloaded newer image for mcr.microsoft.com/dotnet/aspnet:8.0 - ---> 0ee5d7ddbc3b -Step 2/19 : USER app -etc, -``` - -{{% /tab %}} -{{< /tabs >}} - -これは、現在のディレクトリの `Dockerfile` を使用して `helloworld:1.0` のタグでイメージをビルドするようDockerに指示します。 - -以下のコマンドで正常に作成されたことを確認できます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -docker images -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -REPOSITORY TAG IMAGE ID CREATED SIZE -helloworld 1.0 db19077b9445 20 seconds ago 217MB -``` - -{{% /tab %}} -{{< /tabs >}} - -## Docker イメージのテスト - -> 続行する前に、以前に開始したアプリケーションがインスタンス上で実行されていないことを確認してください。 - -Dockerイメージを使用して以下のようにアプリケーションを実行できます - -```bash -docker run --name helloworld \ ---detach \ ---expose 8080 \ ---network=host \ -helloworld:1.0 -``` - -> 注意：`--network=host` パラメータを含めて、Docker コンテナが -> インスタンス上のリソースにアクセスできるようにしています。これは後でアプリケーションが -> localhost 上で実行されているコレクターにデータを送信する必要がある場合に重要です。 - -Dockerコンテナが実行されていることを確認しましょう - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -docker ps -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -$ docker ps -CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES -5f5b9cd56ac5 helloworld:1.0 "dotnet helloworld.d…" 2 mins ago Up 2 mins helloworld -``` - -{{% /tab %}} -{{< /tabs >}} - -以前と同様にアプリケーションにアクセスできます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -curl http://localhost:8080/hello/Docker -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Hello, Docker! -``` - -{{% /tab %}} -{{< /tabs >}} - -おめでとうございます。ここまで到達したということは、.NETアプリケーションのDocker化に成功したということです。 diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/6-add-instrumentation-to-dockerfile.md b/content/ja/ninja-workshops/8-docker-k8s-otel/6-add-instrumentation-to-dockerfile.md deleted file mode 100644 index af3b034919..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/6-add-instrumentation-to-dockerfile.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -title: Dockerfileに計装を追加する -linkTitle: 6. Dockerfileに計装を追加する -weight: 6 -time: 10 minutes ---- - -アプリケーションのDocker化に成功したので、OpenTelemetry計装を追加しましょう。 - -これはLinux上で実行しているアプリケーションを計装したときの手順と似ていますが、 -いくつかの重要な違いがあります。 - -## Dockerfile の更新 - -`/home/splunk/workshop/docker-k8s-otel/helloworld` ディレクトリにある `Dockerfile` を更新しましょう。 - -Dockerfileで.NETアプリケーションがビルドされた後、以下を行います - -* `splunk-otel-dotnet-install.sh` のダウンロードと実行に必要な依存関係を追加する -* Splunk OTel .NET インストーラーをダウンロードする -* ディストリビューションをインストールする - -Dockerfileのビルドステージに以下を追加します。viでDockerfileを開きましょう - -``` bash -vi /home/splunk/workshop/docker-k8s-otel/helloworld/Dockerfile -``` - -> i キーを押してviの編集モードに入ります - -> 'NEW CODE' とマークされた行をDockerfileのビルドステージセクションに貼り付けてください - -``` dockerfile -# CODE ALREADY IN YOUR DOCKERFILE: -FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build -ARG BUILD_CONFIGURATION=Release -WORKDIR /src -COPY ["helloworld.csproj", "helloworld/"] -RUN dotnet restore "./helloworld/./helloworld.csproj" -WORKDIR "/src/helloworld" -COPY . . -RUN dotnet build "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/build - -# NEW CODE: add dependencies for splunk-otel-dotnet-install.sh -RUN apt-get update && \ - apt-get install -y unzip - -# NEW CODE: download Splunk OTel .NET installer -RUN curl -sSfL https://github.com/signalfx/splunk-otel-dotnet/releases/latest/download/splunk-otel-dotnet-install.sh -O - -# NEW CODE: install the distribution -RUN sh ./splunk-otel-dotnet-install.sh -``` - -次に、Dockerfileの最終ステージを以下の変更で更新します - -* ビルドイメージから最終イメージに /root/.splunk-otel-dotnet/ をコピーする -* entrypoint.sh ファイルもコピーする -* `OTEL_SERVICE_NAME` と `OTEL_RESOURCE_ATTRIBUTES` 環境変数を設定する -* `ENTRYPOINT` を `entrypoint.sh` に設定する - -最終ステージ全体を以下で置き換えるのが最も簡単です - -> **重要** Dockerfileの `$INSTANCE` をインスタンス名に置き換えてください。 -> インスタンス名は `echo $INSTANCE` を実行して確認できます。 - -``` dockerfile -# CODE ALREADY IN YOUR DOCKERFILE -FROM base AS final - -# NEW CODE: Copy instrumentation file tree -WORKDIR "//home/app/.splunk-otel-dotnet" -COPY --from=build /root/.splunk-otel-dotnet/ . - -# CODE ALREADY IN YOUR DOCKERFILE -WORKDIR /app -COPY --from=publish /app/publish . - -# NEW CODE: copy the entrypoint.sh script -COPY entrypoint.sh . - -# NEW CODE: set OpenTelemetry environment variables -ENV OTEL_SERVICE_NAME=helloworld -ENV OTEL_RESOURCE_ATTRIBUTES='deployment.environment=otel-$INSTANCE' - -# NEW CODE: replace the prior ENTRYPOINT command with the following two lines -ENTRYPOINT ["sh", "entrypoint.sh"] -CMD ["dotnet", "helloworld.dll"] -``` - -> vi での変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力してから `enter/return` キーを押します。 - -すべての変更を適用した後、Dockerfileは以下のようになります - -> **重要** この内容を自分のDockerfileにコピー＆ペーストする場合は、 -> Dockerfileの `$INSTANCE` をインスタンス名に置き換えてください。 -> インスタンス名は `echo $INSTANCE` を実行して確認できます。 - -``` dockerfile -FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base -USER app -WORKDIR /app -EXPOSE 8080 - -FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build -ARG BUILD_CONFIGURATION=Release -WORKDIR /src -COPY ["helloworld.csproj", "helloworld/"] -RUN dotnet restore "./helloworld/./helloworld.csproj" -WORKDIR "/src/helloworld" -COPY . . -RUN dotnet build "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/build - -# NEW CODE: add dependencies for splunk-otel-dotnet-install.sh -RUN apt-get update && \ - apt-get install -y unzip - -# NEW CODE: download Splunk OTel .NET installer -RUN curl -sSfL https://github.com/signalfx/splunk-otel-dotnet/releases/latest/download/splunk-otel-dotnet-install.sh -O - -# NEW CODE: install the distribution -RUN sh ./splunk-otel-dotnet-install.sh - -FROM build AS publish -ARG BUILD_CONFIGURATION=Release -RUN dotnet publish "./helloworld.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false - -FROM base AS final - -# NEW CODE: Copy instrumentation file tree -WORKDIR "//home/app/.splunk-otel-dotnet" -COPY --from=build /root/.splunk-otel-dotnet/ . - -WORKDIR /app -COPY --from=publish /app/publish . - -# NEW CODE: copy the entrypoint.sh script -COPY entrypoint.sh . - -# NEW CODE: set OpenTelemetry environment variables -ENV OTEL_SERVICE_NAME=helloworld -ENV OTEL_RESOURCE_ATTRIBUTES='deployment.environment=otel-$INSTANCE' - -# NEW CODE: replace the prior ENTRYPOINT command with the following two lines -ENTRYPOINT ["sh", "entrypoint.sh"] -CMD ["dotnet", "helloworld.dll"] -``` - -## entrypoint.sh ファイルの作成 - -`/home/splunk/workshop/docker-k8s-otel/helloworld` フォルダに `entrypoint.sh` という名前のファイルも作成する必要があります。 -内容は以下の通りです - -``` bash -vi /home/splunk/workshop/docker-k8s-otel/helloworld/entrypoint.sh -``` - -次に、新しく作成したファイルに以下のコードを貼り付けます - -``` bash -#!/bin/sh -# Read in the file of environment settings -. /$HOME/.splunk-otel-dotnet/instrument.sh - -# Then run the CMD -exec "$@" -``` - -> vi での変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力してから `enter/return` キーを押します。 - -`entrypoint.sh` スクリプトは、計装に含まれている instrument.sh スクリプトから環境変数を読み込むために必要です。これにより、各プラットフォームの環境変数が正しくセットアップされます。 - -> Linuxホスト上でOpenTelemetry .NET計装を有効化したときのように、Dockerfileに以下のコマンドを -> 含めるだけではだめなのかと思われるかもしれません。 -> -> ``` dockerfile -> RUN . $HOME/.splunk-otel-dotnet/instrument.sh -> ``` -> -> この方法の問題は、DockerfileのRUNステップごとに新しいコンテナと新しいシェルが実行されることです。 -> あるシェルで環境変数を設定しても、後のステップでは参照できません。 -> この問題は、ここで行ったようにエントリーポイントスクリプトを使用することで解決されます。 -> この問題の詳細については、こちらの [Stack Overflow の投稿](https://stackoverflow.com/questions/55921914/how-to-source-a-script-with-environment-variables-in-a-docker-build-process) -> を参照してください。 - -## Docker イメージのビルド - -OpenTelemetry .NET計装を含む新しいDockerイメージをビルドしましょう - -``` bash -docker build -t helloworld:1.1 . -``` - -> 注意：以前のバージョンと区別するために、異なるバージョン（1.1）を使用しています。 -> 古いバージョンをクリーンアップするには、以下のコマンドでコンテナIDを取得します -> -> ``` bash -> docker ps -a | grep helloworld -> ``` -> -> 次に、以下のコマンドでコンテナを削除します -> -> ``` bash -> docker rm --force -> ``` -> -> コンテナイメージIDを取得します -> -> ``` bash -> docker images | grep 1.0 -> ``` -> -> 最後に、以下のコマンドで古いイメージを削除できます -> -> ``` bash -> docker image rm -> ``` - -## アプリケーションの実行 - -新しいDockerイメージを実行しましょう - -``` bash -docker run --name helloworld \ ---detach \ ---expose 8080 \ ---network=host \ -helloworld:1.1 -``` - -以下のコマンドでアプリケーションにアクセスできます - -``` bash -curl http://localhost:8080/hello -``` - -上記のコマンドを数回実行してトラフィックを生成してください。 - -1分ほど経ったら、Splunk Observability Cloud に新しいトレースが表示されることを確認してください。 - -> あなた自身の Environment でトレースを探すことを忘れないでください。 - -## トラブルシューティング - -Splunk Observability Cloud にトレースが表示されない場合、以下の方法でトラブルシューティングできます。 - -まず、コレクター設定ファイルを編集用に開きます - -``` bash -sudo vi /etc/otel/collector/agent_config.yaml -``` - -次に、トレースパイプラインに debug エクスポーターを追加します。これにより、トレースがコレクターログに書き込まれるようになります - -``` yaml -service: - telemetry: - logs: - level: ${env:SPLUNK_COLLECTOR_LOG_LEVEL:-info} - metrics: - readers: - - pull: - exporter: - prometheus: - host: '127.0.0.1' - port: 8888 - extensions: [headers_setter, health_check, http_forwarder, zpages, smartagent] - pipelines: - traces: - receivers: [jaeger, otlp, zipkin] - processors: - - memory_limiter - - batch - - resourcedetection - #- resource/add_environment - # NEW CODE: add the debug exporter here - exporters: [otlp_http, signalfx, debug] -``` - -次に、コレクターを再起動して設定変更を適用します - -``` bash -sudo systemctl restart splunk-otel-collector -``` - -`journalctl` を使用してコレクターログを確認できます - -> Ctrl + C を押してログのテーリングを終了します。 - -``` bash -sudo journalctl -u splunk-otel-collector -f -n 100 -``` diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/7-install-collector-k8s.md b/content/ja/ninja-workshops/8-docker-k8s-otel/7-install-collector-k8s.md deleted file mode 100644 index 521169ded9..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/7-install-collector-k8s.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -title: K8s に OpenTelemetry Collector をインストールする -linkTitle: 7. Install the OpenTelemetry Collector in K8s -weight: 7 -time: 15 minutes ---- - -## ワークショップの Part 1 のおさらい - -ここまでのワークショップで、次の内容を完了しました。 - -* Splunk distribution of the OpenTelemetry Collector を Linux ホストにデプロイ -* トレースとメトリクスを Splunk Observability Cloud に送信するように設定 -* .NET アプリケーションをデプロイし、OpenTelemetry で計装 -* .NET アプリケーションを Docker 化し、トレースが o11y cloud に流れていることを確認 - -上記のステップを**完了していない**場合は、ワークショップの残りの部分に進む前に、次のコマンドを実行してください。 - -```bash -cp /home/splunk/workshop/docker-k8s-otel/docker/Dockerfile /home/splunk/workshop/docker-k8s-otel/helloworld/ -cp /home/splunk/workshop/docker-k8s-otel/docker/entrypoint.sh /home/splunk/workshop/docker-k8s-otel/helloworld/ -``` - -> **重要** これらのファイルをコピーしたら、`/home/splunk/workshop/docker-k8s-otel/helloworld/Dockerfile` をエディタで開き、Dockerfile 内の `$INSTANCE` をインスタンス名に置き換えてください。インスタンス名は `echo $INSTANCE` を実行することで確認できます。 - -## ワークショップの Part 2 の概要 - -ワークショップの次のパートでは、アプリケーションを Kubernetes で実行したいので、Splunk distribution of the OpenTelemetry Collector を Kubernetes クラスターにデプロイする必要があります。 - -まずいくつかの重要な用語を定義しましょう。 - -### 重要な用語 - -#### Kubernetes とは - -_「Kubernetes は、コンテナ化されたワークロードとサービスを管理するための、ポータブルで拡張可能なオープンソースプラットフォームであり、宣言的な構成と自動化の両方を促進します。」_ - -ソース: - -先ほど Docker イメージとしてビルドしたアプリケーションを、Dockerfile に少し変更を加えた上で Kubernetes クラスターにデプロイします。 - -#### Helm とは - -Helm は Kubernetes のパッケージマネージャーです。 - -_「Helm は、最も複雑な Kubernetes アプリケーションでさえ定義、インストール、アップグレードするのに役立ちます。」_ - -ソース: - -K8s クラスターに OpenTelemetry collector をデプロイするために Helm を使用します。 - -#### Helm の利点 - -* 複雑さの管理 - * 多数のマニフェストファイルではなく、1つの values.yaml ファイルを扱う -* 簡単なアップデート - * インプレースアップグレード -* ロールバックのサポート - * `helm rollback` を使うだけで、リリースを以前のバージョンに戻せる - -## ホスト Collector のアンインストール - -先に進む前に、Linux ホストに先ほどインストールした 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 -``` - -## Helm を使った Collector のインストール - -製品内のウィザードではなくコマンドラインを使って、独自の `helm` コマンドで collector をインストールしましょう。 - -まず helm リポジトリを追加します。 - -```bash -helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart -``` - -そしてリポジトリが最新であることを確認します。 - -```bash -helm repo update -``` - -helm chart のデプロイ設定のため、`/home/splunk` ディレクトリに `values.yaml` という新しいファイルを作成します。 - -```bash -# /home/splunk ディレクトリに移動 -cd /home/splunk -# vi で values.yaml ファイルを作成 -vi values.yaml -``` - -> 以下のテキストを貼り付ける前に、vi で `i` を押してインサートモードに入ります。 - -その後、次の内容を貼り付けます。 - -```yaml -logsEngine: otel -agent: - config: - receivers: - hostmetrics: - collection_interval: 10s - root_path: /hostfs - scrapers: - cpu: null - disk: null - filesystem: - exclude_mount_points: - match_type: regexp - mount_points: - - /var/* - - /snap/* - - /boot/* - - /boot - - /opt/orbstack/* - - /mnt/machines/* - - /Users/* - load: null - memory: null - network: null - paging: null - processes: null -``` - -> vi で変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力した後に `enter/return` キーを押します。 - -これで、次のコマンドを使って collector をインストールできます。 - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash - helm install splunk-otel-collector --version 0.149.0 \ - --set="splunkObservability.realm=$REALM" \ - --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ - --set="clusterName=$INSTANCE-cluster" \ - --set="environment=otel-$INSTANCE" \ - --set="splunkPlatform.token=$HEC_TOKEN" \ - --set="splunkPlatform.endpoint=$HEC_URL" \ - --set="splunkPlatform.index=splunk4rookies-workshop" \ - -f values.yaml \ - splunk-otel-collector-chart/splunk-otel-collector -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -NAME: splunk-otel-collector -LAST DEPLOYED: Fri Dec 20 01:01:43 2024 -NAMESPACE: default -STATUS: deployed -REVISION: 1 -TEST SUITE: None -NOTES: -Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1. -``` - -{{% /tab %}} -{{< /tabs >}} - -## 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-dkn88 1/1 Running 0 53s -splunk-otel-collector-agent-ksmh4 1/1 Running 0 53s -splunk-otel-collector-agent-lc2lf 1/1 Running 0 53s -splunk-otel-collector-k8s-cluster-receiver-dbf64995b-xgm9b 1/1 Running 0 53s -``` - -{{% /tab %}} -{{< /tabs >}} - -## K8s クラスターが O11y Cloud に表示されているか確認 - -Splunk Observability Cloud で **Infrastructure** -> **Kubernetes** -> **Kubernetes Clusters** に移動し、クラスター名（`$INSTANCE-cluster`）で検索します。 - -![Kubernetes node](../images/k8snode.png) diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/8-deploy-app-k8s.md b/content/ja/ninja-workshops/8-docker-k8s-otel/8-deploy-app-k8s.md deleted file mode 100644 index 13879e3ca2..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/8-deploy-app-k8s.md +++ /dev/null @@ -1,397 +0,0 @@ ---- -title: アプリケーションをK8sにデプロイ -linkTitle: 8. アプリケーションをK8sにデプロイ -weight: 8 -time: 15 minutes ---- - -## Dockerfile の更新 - -Kubernetesでは、環境変数は通常、Dockerイメージに組み込むのではなく `.yaml` マニフェストファイルで管理されます。そこで、Dockerfileから以下の2つの環境変数を削除しましょう - -```bash -vi /home/splunk/workshop/docker-k8s-otel/helloworld/Dockerfile -``` - -次に、以下の2つの環境変数を削除します - -```dockerfile -ENV OTEL_SERVICE_NAME=helloworld -ENV OTEL_RESOURCE_ATTRIBUTES='deployment.environment=otel-$INSTANCE' -``` - -> vi での変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力してから `enter/return` キーを押します。 - -## 新しい Docker イメージのビルド - -環境変数を除外した新しいDockerイメージをビルドしましょう - -```bash -cd /home/splunk/workshop/docker-k8s-otel/helloworld - -docker build -t helloworld:1.2 . -``` - -> Note: we've used a different version (1.2) to distinguish the image from our earlier version. -> To clean up the older versions, run the following command to get the container id: -> -> ```bash -> docker ps -a -> ``` -> -> Then run the following command to delete the container: -> -> ```bash -> docker rm --force -> ``` -> -> Now we can get the container image id: -> -> ```bash -> docker images | grep 1.1 -> ``` -> -> Finally, we can run the following command to delete the old image: -> -> ```bash -> docker image rm -> ``` - -## Docker イメージを Kubernetes にインポート - -通常であれば、DockerイメージをDocker Hubなどのリポジトリにプッシュします。 -しかし、今回のセッションでは、k3sに直接インポートする回避策を使用します。 - -```bash -cd /home/splunk - -# Import the image into k3d -sudo k3d image import helloworld:1.2 --cluster $INSTANCE-cluster -``` - -## .NET アプリケーションのデプロイ - -> ヒント：vi で編集モードに入るには「i」キーを押します。変更を保存するには、`esc` キーを押してコマンドモードに入り、`:wq!` と入力してから `enter/return` キーを押します。 - -.NETアプリケーションをK8sにデプロイするために、`/home/splunk` に `deployment.yaml` という名前のファイルを作成しましょう - -```bash -vi /home/splunk/deployment.yaml -``` - -そして以下を貼り付けます - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: helloworld -spec: - selector: - matchLabels: - app: helloworld - replicas: 1 - template: - metadata: - labels: - app: helloworld - spec: - containers: - - name: helloworld - image: docker.io/library/helloworld:1.2 - imagePullPolicy: Never - ports: - - containerPort: 8080 - env: - - name: PORT - value: "8080" -``` - -> [!tip]- Kubernetes における Deployment とは？ -> deployment.yaml ファイルは、deployment リソースを定義するために使用される kubernetes 設定ファイルです。このファイルは Kubernetes でアプリケーションを管理するための基盤となります！deployment 設定は deployment の **_望ましい状態_** を定義し、Kubernetes が **_実際の状態_** がそれと一致するよう保証します。これにより、アプリケーション pod の自己修復が可能になり、アプリケーションの簡単な更新やロールバックも可能になります。 - -次に、同じディレクトリに `service.yaml` という名前の2つ目のファイルを作成します - -```bash -vi /home/splunk/service.yaml -``` - -そして以下を貼り付けます - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: helloworld - labels: - app: helloworld -spec: - type: ClusterIP - selector: - app: helloworld - ports: - - port: 8080 - protocol: TCP -``` - -> [!tip]- Kubernetes における Service とは？ -> Kubernetes の Service は抽象化レイヤーであり、仲介者のような役割を果たします。Pod にアクセスするための固定 IP アドレスや DNS 名を提供し、時間の経過とともに Pod が追加、削除、または交換されても同じままです。 - -これらのマニフェストファイルを使用してアプリケーションをデプロイできます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -# create the deployment -kubectl apply -f deployment.yaml - -# create the service -kubectl apply -f service.yaml -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -deployment.apps/helloworld created -service/helloworld created -``` - -{{% /tab %}} -{{< /tabs >}} - -## アプリケーションのテスト - -アプリケーションにアクセスするには、まずIPアドレスを取得する必要があります - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -kubectl describe svc helloworld | grep IP: -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -IP: 10.43.102.103 -``` - -{{% /tab %}} -{{< /tabs >}} - -その後、前のコマンドから返されたCluster IPを使用してアプリケーションにアクセスできます。 - -例： - -```bash -curl http://10.43.102.103:8080/hello/Kubernetes -``` - -## OpenTelemetry の設定 - -.NET OpenTelemetry計装はすでにDockerイメージに組み込まれています。しかし、データの送信先を指定するためにいくつかの環境変数を設定する必要があります。 - -先ほど作成した `deployment.yaml` ファイルに以下を追加します - -> **重要** 以下の YAML の `$INSTANCE` をあなたのインスタンス名に置き換えてください。 -> インスタンス名は `echo $INSTANCE` を実行することで確認できます。 - -```yaml -env: - - name: PORT - value: "8080" - - name: NODE_IP - valueFrom: - fieldRef: - fieldPath: status.hostIP - - name: OTEL_EXPORTER_OTLP_ENDPOINT - value: "http://$(NODE_IP):4318" - - name: OTEL_SERVICE_NAME - value: "helloworld" - - name: OTEL_RESOURCE_ATTRIBUTES - value: "deployment.environment=otel-$INSTANCE" -``` - -完全な `deployment.yaml` ファイルは以下のようになります（`$INSTANCE` ではなく**あなたの**インスタンス名を使用してください） - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: helloworld -spec: - selector: - matchLabels: - app: helloworld - replicas: 1 - template: - metadata: - labels: - app: helloworld - spec: - containers: - - name: helloworld - image: docker.io/library/helloworld:1.2 - imagePullPolicy: Never - ports: - - containerPort: 8080 - env: - - name: PORT - value: "8080" - - name: NODE_IP - valueFrom: - fieldRef: - fieldPath: status.hostIP - - name: OTEL_EXPORTER_OTLP_ENDPOINT - value: "http://$(NODE_IP):4318" - - name: OTEL_SERVICE_NAME - value: "helloworld" - - name: OTEL_RESOURCE_ATTRIBUTES - value: "deployment.environment=otel-$INSTANCE" -``` - -以下のコマンドで変更を適用します - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -kubectl apply -f deployment.yaml -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -deployment.apps/helloworld configured -``` - -{{% /tab %}} -{{< /tabs >}} - -その後、`curl` を使用してトラフィックを生成します。 - -1分ほど経過すると、o11y cloudでトレースが流れているのが確認できるはずです。ただし、より早くトレースを確認したい場合は、以下の方法があります... - -## チャレンジ - -開発者として、トレースIDを素早く取得するか、コンソールフィードバックを見たい場合、deployment.yamlファイルにどのような環境変数を追加できるでしょうか？ - -
- 答えを見るにはここをクリック - -セクション4「.NET ApplicationをOpenTelemetryで計装する」のチャレンジで思い出していただければ、`OTEL_TRACES_EXPORTER` 環境変数を使ってtraceをconsoleに書き込むトリックをお見せしました。この変数をdeployment.yamlに追加し、アプリケーションを再deployして、helloworldアプリからlogをtailすることで、trace idを取得してSplunk Observability Cloudでtraceを見つけることができます。（ワークショップの次のセクションでは、debug exporterの使用についても説明します。これはK8s環境でアプリケーションをdebugする際の典型的な方法です。） - -まず、viでdeployment.yamlファイルを開きます - -```bash -vi deployment.yaml - -``` - -次に、`OTEL_TRACES_EXPORTER` 環境変数を追加します - -```yaml -env: - - name: PORT - value: "8080" - - name: NODE_IP - valueFrom: - fieldRef: - fieldPath: status.hostIP - - name: OTEL_EXPORTER_OTLP_ENDPOINT - value: "http://$(NODE_IP):4318" - - name: OTEL_SERVICE_NAME - value: "helloworld" - - name: OTEL_RESOURCE_ATTRIBUTES - value: "deployment.environment=YOURINSTANCE" - # NEW VALUE HERE: - - name: OTEL_TRACES_EXPORTER - value: "otlp,console" -``` - -変更を保存してからアプリケーションを再deployします - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -kubectl apply -f deployment.yaml -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -deployment.apps/helloworld configured -``` - -{{% /tab %}} -{{< /tabs >}} - -helloworldのlogをtailします - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -kubectl logs -l app=helloworld -f -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -info: HelloWorldController[0] - /hello endpoint invoked by K8s9 -Activity.TraceId: 5bceb747cc7b79a77cfbde285f0f09cb -Activity.SpanId: ac67afe500e7ad12 -Activity.TraceFlags: Recorded -Activity.ActivitySourceName: Microsoft.AspNetCore -Activity.DisplayName: GET hello/{name?} -Activity.Kind: Server -Activity.StartTime: 2025-02-04T15:22:48.2381736Z -Activity.Duration: 00:00:00.0027334 -Activity.Tags: - server.address: 10.43.226.224 - server.port: 8080 - http.request.method: GET - url.scheme: http - url.path: /hello/K8s9 - network.protocol.version: 1.1 - user_agent.original: curl/7.81.0 - http.route: hello/{name?} - http.response.status_code: 200 -Resource associated with Activity: - splunk.distro.version: 1.8.0 - telemetry.distro.name: splunk-otel-dotnet - telemetry.distro.version: 1.8.0 - os.type: linux - os.description: Debian GNU/Linux 12 (bookworm) - os.build_id: 6.2.0-1018-aws - os.name: Debian GNU/Linux - os.version: 12 - host.name: helloworld-69f5c7988b-dxkwh - process.owner: app - process.pid: 1 - process.runtime.description: .NET 8.0.12 - process.runtime.name: .NET - process.runtime.version: 8.0.12 - container.id: 39c2061d7605d8c390b4fe5f8054719f2fe91391a5c32df5684605202ca39ae9 - telemetry.sdk.name: opentelemetry - telemetry.sdk.language: dotnet - telemetry.sdk.version: 1.9.0 - service.name: helloworld - deployment.environment: otel-jen-tko-1b75 - -``` - -{{% /tab %}} -{{< /tabs >}} - -次に、別のterminal windowでcurlコマンドを使ってtraceを生成します。logをtailしているconsoleでtrace idが表示されるはずです。`Activity.TraceId:` の値をコピーして、APMのTrace検索フィールドに貼り付けてください。 - -
diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/9-customize-collector-config.md b/content/ja/ninja-workshops/8-docker-k8s-otel/9-customize-collector-config.md deleted file mode 100644 index e79a32d4e8..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/9-customize-collector-config.md +++ /dev/null @@ -1,331 +0,0 @@ ---- -title: OpenTelemetryコレクター設定のカスタマイズ -linkTitle: 9. OpenTelemetryコレクター設定のカスタマイズ -weight: 9 -time: 20 minutes ---- - -デフォルト設定を使用してK8sクラスターにSplunk Distribution of OpenTelemetryコレクターを -デプロイしました。このセクションでは、コレクター設定をカスタマイズする方法をいくつかの例で -説明します。 - -## コレクター設定の取得 - -コレクター設定をカスタマイズする前に、現在の設定がどのようになっているかを -どのように確認するのでしょうか？ - -Kubernetes環境では、コレクター設定は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 >}} - -> なぜ 2 つの config map があるのでしょうか？ - -次に、以下のようにコレクターエージェントの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 でコレクター設定を更新する方法 - -Linuxインスタンスでコレクターを実行した以前の例では、コレクター設定は -`/etc/otel/collector/agent_config.yaml` ファイルで利用可能でした。その場合にコレクター設定を -変更する必要があれば、単純にこのファイルを編集し、変更を保存してから -コレクターを再起動すればよかったのです。 - -K8sでは、少し異なる動作をします。`agent_config.yaml` を直接変更する代わりに、 -helmチャートをデプロイするために使用される `values.yaml` ファイルを変更することで -コレクター設定をカスタマイズします。 - -[GitHub](https://github.com/signalfx/splunk-otel-collector-chart/blob/main/helm-charts/splunk-otel-collector/values.yaml)のvalues.yamlファイルには、 -利用可能なカスタマイズオプションが記載されています。 - -例を見てみましょう。 - -## Infrastructure Events Monitoring の追加 - -最初の例として、K8sクラスターのinfrastructure events monitoringを有効にしましょう。 - -> これにより、charts の Events Feed セクションの一部として Kubernetes イベントを確認できるようになります。 -> cluster receiver は、kubernetes-events -> monitor を使用して Smart Agent receiver で設定され、custom イベントを送信します。詳細については[Collect Kubernetes events](https://docs.splunk.com/observability/en/gdi/opentelemetry/collector-kubernetes/kubernetes-config-logs.html#collect-kubernetes-events)を参照してください。 - -これは `values.yaml` ファイルに以下の行を追加することで実行されます - -> ヒント：vi での開き方と保存方法は前のステップにあります。 - -```yaml -logsEngine: otel -splunkObservability: - infrastructureMonitoringEventsEnabled: true -agent: -``` - -ファイルが保存されたら、以下のコマンドで変更を適用できます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -helm upgrade splunk-otel-collector \ - --set="splunkObservability.realm=$REALM" \ - --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ - --set="clusterName=$INSTANCE-cluster" \ - --set="environment=otel-$INSTANCE" \ - --set="splunkPlatform.token=$HEC_TOKEN" \ - --set="splunkPlatform.endpoint=$HEC_URL" \ - --set="splunkPlatform.index=splunk4rookies-workshop" \ - -f values.yaml \ -splunk-otel-collector-chart/splunk-otel-collector -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Release "splunk-otel-collector" has been upgraded. Happy Helming! -NAME: splunk-otel-collector -LAST DEPLOYED: Fri Dec 20 01:17:03 2024 -NAMESPACE: default -STATUS: deployed -REVISION: 2 -TEST SUITE: None -NOTES: -Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1. -``` - -{{% /tab %}} -{{< /tabs >}} - -その後、config mapを表示して変更が適用されたことを確認できます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -kubectl describe cm splunk-otel-collector-otel-k8s-cluster-receiver -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -`smartagent/kubernetes-events` がagent configに含まれていることを確認してください - -```bash - smartagent/kubernetes-events: - alwaysClusterReporter: true - type: kubernetes-events - whitelistedEvents: - - involvedObjectKind: Pod - reason: Created - - involvedObjectKind: Pod - reason: Unhealthy - - involvedObjectKind: Pod - reason: Failed - - involvedObjectKind: Job - reason: FailedCreate -``` - -{{% /tab %}} -{{< /tabs >}} - -> これらの特定の変更が適用されるのは -> cluster receiver config map なので、そちらを指定していることに注意してください。 - -## Debug Exporter の追加 - -collectorに送信されるtraceとlogを確認して、 -Splunkに送信する前に検査したいとします。この目的のためにdebug exporterを使用できます。これは -OpenTelemetry関連の問題のトラブルシューティングに役立ちます。 - -values.yamlファイルの下部に以下のようにdebug exporterを追加しましょう - -```yaml -logsEngine: otel -splunkObservability: - infrastructureMonitoringEventsEnabled: true -agent: - config: - receivers: ... - exporters: - debug: - verbosity: detailed - service: - pipelines: - traces: - exporters: - - debug - logs: - exporters: - - debug -``` - -ファイルが保存されたら、以下のコマンドで変更を適用できます - -{{< tabs >}} -{{% tab title="Script" %}} - -```bash -helm upgrade splunk-otel-collector \ - --set="splunkObservability.realm=$REALM" \ - --set="splunkObservability.accessToken=$ACCESS_TOKEN" \ - --set="clusterName=$INSTANCE-cluster" \ - --set="environment=otel-$INSTANCE" \ - --set="splunkPlatform.token=$HEC_TOKEN" \ - --set="splunkPlatform.endpoint=$HEC_URL" \ - --set="splunkPlatform.index=splunk4rookies-workshop" \ - -f values.yaml \ -splunk-otel-collector-chart/splunk-otel-collector -``` - -{{% /tab %}} -{{% tab title="Example Output" %}} - -```bash -Release "splunk-otel-collector" has been upgraded. Happy Helming! -NAME: splunk-otel-collector -LAST DEPLOYED: Fri Dec 20 01:32:03 2024 -NAMESPACE: default -STATUS: deployed -REVISION: 3 -TEST SUITE: None -NOTES: -Splunk OpenTelemetry Collector is installed and configured to send data to Splunk Observability realm us1. -``` - -{{% /tab %}} -{{< /tabs >}} - -curlを使用してアプリケーションを数回実行してから、以下のコマンドでagent collectorのlogをtailします - -```bash -kubectl logs -l component=otel-collector-agent -f -``` - -以下のようなtraceがagent collectorのlogに書き込まれているのが確認できるはずです - -``` -2024-12-20T01:43:52.929Z info Traces {"kind": "exporter", "data_type": "traces", "name": "debug", "resource spans": 1, "spans": 2} -2024-12-20T01:43:52.929Z info ResourceSpans #0 -Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 -Resource attributes: - -> splunk.distro.version: Str(1.8.0) - -> telemetry.distro.name: Str(splunk-otel-dotnet) - -> telemetry.distro.version: Str(1.8.0) - -> os.type: Str(linux) - -> os.description: Str(Debian GNU/Linux 12 (bookworm)) - -> os.build_id: Str(6.8.0-1021-aws) - -> os.name: Str(Debian GNU/Linux) - -> os.version: Str(12) - -> host.name: Str(derek-1) - -> process.owner: Str(app) - -> process.pid: Int(1) - -> process.runtime.description: Str(.NET 8.0.11) - -> process.runtime.name: Str(.NET) - -> process.runtime.version: Str(8.0.11) - -> container.id: Str(78b452a43bbaa3354a3cb474010efd6ae2367165a1356f4b4000be031b10c5aa) - -> telemetry.sdk.name: Str(opentelemetry) - -> telemetry.sdk.language: Str(dotnet) - -> telemetry.sdk.version: Str(1.9.0) - -> service.name: Str(helloworld) - -> deployment.environment: Str(otel-derek-1) - -> k8s.pod.ip: Str(10.42.0.15) - -> k8s.pod.labels.app: Str(helloworld) - -> k8s.pod.name: Str(helloworld-84865965d9-nkqsx) - -> k8s.namespace.name: Str(default) - -> k8s.pod.uid: Str(38d39bc6-1309-4022-a569-8acceef50942) - -> k8s.node.name: Str(derek-1) - -> k8s.cluster.name: Str(derek-1-cluster) -``` - -そして以下のようなlogエントリも確認できます - -``` -2024-12-20T01:43:53.215Z info Logs {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 2} -2024-12-20T01:43:53.215Z info ResourceLog #0 -Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1 -Resource attributes: - -> splunk.distro.version: Str(1.8.0) - -> telemetry.distro.name: Str(splunk-otel-dotnet) - -> telemetry.distro.version: Str(1.8.0) - -> os.type: Str(linux) - -> os.description: Str(Debian GNU/Linux 12 (bookworm)) - -> os.build_id: Str(6.8.0-1021-aws) - -> os.name: Str(Debian GNU/Linux) - -> os.version: Str(12) - -> host.name: Str(derek-1) - -> process.owner: Str(app) - -> process.pid: Int(1) - -> process.runtime.description: Str(.NET 8.0.11) - -> process.runtime.name: Str(.NET) - -> process.runtime.version: Str(8.0.11) - -> container.id: Str(78b452a43bbaa3354a3cb474010efd6ae2367165a1356f4b4000be031b10c5aa) - -> telemetry.sdk.name: Str(opentelemetry) - -> telemetry.sdk.language: Str(dotnet) - -> telemetry.sdk.version: Str(1.9.0) - -> service.name: Str(helloworld) - -> deployment.environment: Str(otel-derek-1) - -> k8s.node.name: Str(derek-1) - -> k8s.cluster.name: Str(derek-1-cluster) -``` - -ただし、Splunk Observability Cloudに戻ると、アプリケーションからtraceとlogが -もはやそこに送信されていないことに気づくでしょう。 - -なぜそうなったと思いますか？次のセクションで詳しく説明します。 diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/_index.md b/content/ja/ninja-workshops/8-docker-k8s-otel/_index.md deleted file mode 100644 index 59cf5aeee3..0000000000 --- a/content/ja/ninja-workshops/8-docker-k8s-otel/_index.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: OpenTelemetry、Docker、K8sを実践で学ぶ -linkTitle: OpenTelemetry、Docker、K8sを実践で学ぶ -weight: 8 -archetype: chapter -time: 2 minutes -authors: ["Derek Mitchell"] -description: このワークショップでは、これらの概念を説明するためにシンプルな.NETアプリケーションを使用します。さあ、始めましょう！ワークショップの終わりまでに、OpenTelemetryを使用した.NETアプリケーションの計装の実践経験を積み、そのアプリケーションのDocker化およびKubernetesへのデプロイを行います。また、Helmを使用したOpenTelemetryコレクターのデプロイ、コレクター設定のカスタマイズ、コレクター設定の問題のトラブルシューティングの経験も得られます。 -draft: false -hidden: false ---- - -このワークショップでは、以下の項目について実践経験を積むことができます - -- LinuxおよびKubernetes環境で、SplunkディストリビューションのOpenTelemetry .NETを使用してコレクターのデプロイと.NETアプリケーションの計装を実践します。 -- .NETアプリケーションの「Docker化」、Dockerでの実行、そしてSplunk OpenTelemetry計装の追加を実践します。 -- Helmを使用したK8s環境でのSplunkディストロのコレクターのデプロイを実践します。その後、コレクター設定をカスタマイズし、問題のトラブルシューティングを行います。 - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下を使用することです - -- このページの右上にある左右の矢印（**<** | **>**） -- キーボードの左（◀️）と右（▶️）のカーソルキー - {{% /notice %}} diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/images/NetInstrumentation.png b/content/ja/ninja-workshops/8-docker-k8s-otel/images/NetInstrumentation.png deleted file mode 100644 index 42f0376327..0000000000 Binary files a/content/ja/ninja-workshops/8-docker-k8s-otel/images/NetInstrumentation.png and /dev/null differ diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/images/apm_overview.png b/content/ja/ninja-workshops/8-docker-k8s-otel/images/apm_overview.png deleted file mode 100644 index e7a829ccff..0000000000 Binary files a/content/ja/ninja-workshops/8-docker-k8s-otel/images/apm_overview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/images/duplicate_logs.png b/content/ja/ninja-workshops/8-docker-k8s-otel/images/duplicate_logs.png deleted file mode 100644 index 63b3dcdbbb..0000000000 Binary files a/content/ja/ninja-workshops/8-docker-k8s-otel/images/duplicate_logs.png and /dev/null differ diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/images/k8snode.png b/content/ja/ninja-workshops/8-docker-k8s-otel/images/k8snode.png deleted file mode 100644 index e6f8fd0037..0000000000 Binary files a/content/ja/ninja-workshops/8-docker-k8s-otel/images/k8snode.png and /dev/null differ diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/images/logs_json_format.png b/content/ja/ninja-workshops/8-docker-k8s-otel/images/logs_json_format.png deleted file mode 100644 index 3cdd46a48b..0000000000 Binary files a/content/ja/ninja-workshops/8-docker-k8s-otel/images/logs_json_format.png and /dev/null differ diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/images/service_map.png b/content/ja/ninja-workshops/8-docker-k8s-otel/images/service_map.png deleted file mode 100644 index 9afb33e3e8..0000000000 Binary files a/content/ja/ninja-workshops/8-docker-k8s-otel/images/service_map.png and /dev/null differ diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/images/trace.png b/content/ja/ninja-workshops/8-docker-k8s-otel/images/trace.png deleted file mode 100644 index 86aa28ea32..0000000000 Binary files a/content/ja/ninja-workshops/8-docker-k8s-otel/images/trace.png and /dev/null differ diff --git a/content/ja/ninja-workshops/8-docker-k8s-otel/images/traces.png b/content/ja/ninja-workshops/8-docker-k8s-otel/images/traces.png deleted file mode 100644 index 3d88cfb3f5..0000000000 Binary files a/content/ja/ninja-workshops/8-docker-k8s-otel/images/traces.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md deleted file mode 100644 index 77df342c17..0000000000 --- a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/1-connect-to-instance.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -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 mode** に切り替え、通常通りテキストを入力します。`Esc` を押すと **Command mode** に戻ります。 -* エディタを終了せずに変更を保存するには、`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/9-solving-problems-with-o11y-cloud/2-deploy-collector.md b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/2-deploy-collector.md deleted file mode 100644 index 158611a5eb..0000000000 --- a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/2-deploy-collector.md +++ /dev/null @@ -1,327 +0,0 @@ ---- -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 用のパッケージマネージャーで、以下のメリットがあります - -* 複雑さの管理 - * 数十のマニフェストファイルの代わりに、1つの 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`）を検索します。 - -![Kubernetes node](../images/k8snode.png) - -## 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 エージェントの 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 の設定を更新する方法 - -`values.yaml` ファイルを使用して、K8s の 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 関連の問題のトラブルシューティングに役立ちます。 - -`vi` または `nano` を使用して `values.yaml` ファイルを編集できます。ここでは 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 がトレースパイプラインに追加されていることが確認できます。 - -``` yaml - traces: - exporters: - - otlp_http - - signalfx - - debug -``` - -アプリケーションをクラスターにデプロイしてトレースのキャプチャを開始したら、debug exporter の出力を確認します。 diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md deleted file mode 100644 index 3ebe2d39c3..0000000000 --- a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/3-deploy-sample-app.md +++ /dev/null @@ -1,247 +0,0 @@ ---- -title: サンプルアプリケーションのデプロイと OpenTelemetry による計装 -linkTitle: 3. サンプルアプリケーションのデプロイと OpenTelemetry による計装 -weight: 3 -time: 15 minutes ---- - -ここまでで、K8s クラスターに OpenTelemetry Collector をデプロイし、インフラストラクチャメトリクスの収集に成功しました。 - -次のステップは、サンプルアプリケーションをデプロイし、OpenTelemetry で計装してトレースをキャプチャすることです。 - -Python で書かれたマイクロサービスベースのアプリケーションを使用します。ワークショップをシンプルにするため、credit check サービスと credit processor サービスの2つのサービスに焦点を当てます。 - -## アプリケーションのデプロイ - -時間を節約するため、両方のサービスの Docker イメージはすでにビルド済みで、Docker Hub で利用可能です。以下のコマンドで K8s クラスターに credit check サービスをデプロイできます。 - -{{< 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 サービスをデプロイします。 - -{{< 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 サービスと credit processor サービスのビルドに使用された 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** という用語を使用します。そのため、このワークショップ全体でタグに言及している箇所は、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 サービスでは合計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 でトレースデータを確認する前に、以下のコマンドでエージェント Collector のログを tail して、debug exporter がキャプチャした内容を確認しましょう。 - -``` bash -kubectl logs -l component=otel-collector-agent -f -``` - -ヒント: ログの tail を停止するには `CTRL+C` を使用します。 - -エージェント 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/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md deleted file mode 100644 index 40589febf9..0000000000 --- a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/4-create-troubleshooting-metricset.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Troubleshooting MetricSet を作成する -linkTitle: 4. Create a 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` タグをインデックス化します（**注意**: ワークショップに参加する全員が同じ組織を使用しているため、このステップはインストラクターが代行します）。 - -![Create Troubleshooting MetricSet](../images/create_troubleshooting_metric_set.png) - -**Start Analysis** をクリックして次に進みます。 - -分析が実行されている間、タグは **Pending MetricSets** のリストに表示されます。 - -![Pending MetricSets](../images/pending_metric_set.png) - -分析が完了したら、**Actions** カラムのチェックマークをクリックします。 - -## Troubleshooting MetricSet と Monitoring MetricSet の違い - -このタグをインデックス化するために、**Troubleshooting MetricSet** と呼ばれるものを作成したことに気付いたかもしれません。Troubleshooting MetricSet（TMS）は、**Tag Spotlight** などの機能を使用してこのタグに関する問題のトラブルシューティングを行えるため、このように名付けられています。 - -選択しなかったもう1つのオプションとして、**Monitoring MetricSet**（MMS）と呼ばれるものがあることにも気付いたかもしれません。Monitoring MetricSet はトラブルシューティングを超えた機能を提供し、タグをアラートやダッシュボードに利用できるようにします。このワークショップでは扱いませんが、強力な機能ですので、ぜひ各自で試してみてください。 diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md deleted file mode 100644 index 08db22ad00..0000000000 --- a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/5-troubleshoot-using-tag-spotlight.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Tag Spotlight を使用して問題をトラブルシューティングする -linkTitle: 5. Tag Spotlight を使用して問題をトラブルシューティングする -weight: 5 -time: 15 minutes ---- - -## APM データを確認する - -キャプチャしたAPMデータの一部を確認して、アプリケーションのパフォーマンスを見てみましょう。 - -**APM** に移動し、**Environment** ドロップダウンを使用して環境を選択します（例：`tagging-workshop-instancename`）。 - -サービスのリストに `creditprocessorservice` と `creditcheckservice` が表示されているはずです： - -![APM Overview](../images/apm_overview.png) - -右側の **Service Map** をクリックしてサービスマップを表示します。`creditcheckservice` が `creditprocessorservice` を呼び出しており、平均応答時間が少なくとも3秒であることがわかります： - -![Service Map](../images/service_map.png) - -次に、右側の **Traces** をクリックして、このアプリケーションでキャプチャされたトレースを確認します。一部のトレースは比較的高速（数ミリ秒程度）に実行される一方、他のトレースは数秒かかることがわかります。 - -![Traces](../images/traces.png) - -実行時間の長いトレースの1つをクリックします。この例では、トレースに5秒かかり、ほとんどの時間が `creditprocessorservice` の一部である `/runCreditCheck` 操作の呼び出しに費やされていることがわかります： - -![Long Running Trace](../images/long_running_trace.png) - -しかし、なぜ一部のトレースは遅く、他のトレースは比較的速いのでしょうか？ - -トレースを閉じてTrace Analyzerに戻ります。**Errors only** を `on` に切り替えると、一部のトレースにエラーがあることにも気づくでしょう： - -![Traces](../images/traces_with_errors.png) - -エラートレースの1つを見ると、`creditprocessorservice` が `otherservice` という別のサービスを呼び出そうとしたときにエラーが発生していることがわかります。しかし、なぜ一部のリクエストは `otherservice` への呼び出しを行い、他のリクエストは行わないのでしょうか？ - -![Trace with Errors](../images/error_trace.png) - -一部のリクエストがなぜ遅く実行され、一部のリクエストがなぜエラーになるのかを特定するために、 -トレースを1つずつ確認して問題の背後にあるパターンを見つけようとすることもできます。 - -**Splunk Observability Cloud** は、問題の根本原因を見つけるためのより良い方法を提供します。次にこれを確認しましょう。 - -## Tag Spotlight を使用する - -`credit.score.category` タグをインデックスしたので、**Tag Spotlight** と一緒に使用してアプリケーションをトラブルシューティングできます。 - -**APM** に移動し、右側の **Tag Spotlight** をクリックします。**Service** ドロップダウンから `creditcheckservice` サービスが選択されていることを確認します（まだ選択されていない場合）。 - -**Tag Spotlight** を使用すると、`impossible` のスコアになるクレジットスコアリクエストの100%にエラーがあることがわかります。一方、他のすべてのクレジットスコアタイプのリクエストにはまったくエラーがありません！ - -**![Tag Spotlight with Errors](../images/tag_spotlight_errors.png)** - -これは **Tag Spotlight** の威力を示しています！この機能がなければ、このパターンを見つけるのは時間がかかります。数百のトレースを手動で確認してパターンを特定する必要があり（それでも見つかる保証はありません）。 - -エラーを確認しましたが、レイテンシはどうでしょうか？**Requests & errors distribution** ドロップダウンをクリックして **Latency distribution** に変更しましょう。 - -> 重要：**Cards display** の横にある設定アイコンをクリックして、P50 と P99 のメトリクスを追加します。 - -ここでは、`poor` クレジットスコアのリクエストが遅く実行されていることがわかります。P50、P90、P99の時間は約3秒で、これはユーザーが待つには長すぎ、他のリクエストよりもはるかに遅いです。 - -また、`exceptional` クレジットスコアの一部のリクエストも遅く実行されていることがわかります。P99の時間は約5秒ですが、P50の応答時間は比較的速いです。 - -**![Tag Spotlight with Latency](../images/tag_spotlight_latency.png)** - -## Dynamic Service Maps を使用する - -リクエストに関連付けられたクレジットスコアカテゴリがパフォーマンスとエラー率に影響を与える可能性があることがわかったので、インデックスされたタグを活用する別の機能を確認しましょう：**Dynamic Service Maps** です。 - -Dynamic Service Mapsを使用すると、特定のサービスをタグ別に分解できます。例えば、**APM** をクリックし、次に **Service Map** をクリックしてサービスマップを表示しましょう。 - -`creditcheckservice` をクリックします。次に、右側のメニューで **Breakdown** というドロップダウンをクリックし、`credit.score.category` タグを選択します。 - -この時点で、サービスマップは動的に更新され、`creditcheckservice` に到達するリクエストのパフォーマンスがクレジットスコアカテゴリ別に分解されて表示されます： - -**![Service Map Breakdown](../images/service_map_breakdown.png)** - -このビューにより、`good` と `fair` のクレジットスコアのパフォーマンスは優れている一方、`poor` と `exceptional` のスコアははるかに遅く、`impossible` のスコアはエラーになることが明確にわかります。 - -## 発見事項 - -**Tag Spotlight** により、このサービスを担当するエンジニアがさらに調査すべきいくつかの興味深いパターンが明らかになりました： - -* なぜすべての `impossible` クレジットスコアリクエストがエラーになるのか？ -* なぜすべての `poor` クレジットスコアリクエストが遅く実行されるのか？ -* なぜ一部の `exceptional` リクエストが遅く実行されるのか？ - -SREとして、このコンテキストをエンジニアリングチームに伝えることは、彼らの調査に非常に役立ちます。サービスが「時々遅い」と単に伝えるよりも、はるかに迅速に問題を追跡できるからです。 - -興味があれば、`creditprocessorservice` のソースコードを確認してください。impossible、poor、exceptionalのクレジットスコアを持つリクエストは異なる方法で処理されており、そのため我々が発見したエラー率とレイテンシの違いが生じていることがわかります。 - -アプリケーションで見られた動作は、モダンなクラウドネイティブアプリケーションでは一般的なものです。サービスに渡される異なる入力が異なるコードパスにつながり、その一部がパフォーマンスの低下やエラーを引き起こします。例えば、実際のクレジットチェックサービスでは、低いクレジットスコアになるリクエストは、リスクをさらに評価するために別のダウンストリームサービスに送信される場合があり、高いスコアになるリクエストよりも遅く実行されたり、より高いエラー率に遭遇したりする可能性があります。 diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/6-summary.md b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/6-summary.md deleted file mode 100644 index 9e540f2c80..0000000000 --- a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/6-summary.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: まとめ -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** でタグを活用し、「未知の未知」を発見する方法 - -このワークショップで共有したベストプラクティスに沿ってタグを収集することで、**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="Tip for Workshop Facilitator(s)" style="primary" icon="lightbulb" %}} -ワークショップが完了したら、以前に `credit.score.category` タグ用に作成したAPM MetricSetを削除することを忘れないでください。 -{{% /notice %}} diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/_index.md b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/_index.md deleted file mode 100644 index e0e123b6d2..0000000000 --- a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/_index.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: O11y Cloud で問題を解決する -linkTitle: O11y Cloud で問題を解決する -weight: 9 -archetype: chapter -time: 2 minutes -authors: ["Derek Mitchell"] -description: OpenTelemetry Collector のデプロイと設定、OpenTelemetry によるアプリケーションの計装、Troubleshooting MetricSets と Tag Spotlight を活用した Splunk Observability Cloud でのパフォーマンス問題の特定と解決方法を学びます。 -draft: false -hidden: false ---- - -このワークショップでは、以下の内容をハンズオン形式で体験します： - -* **OpenTelemetry Collector** をデプロイし、Collectorの設定をカスタマイズする -* アプリケーションをデプロイし、**OpenTelemetry** で計装する -* **OpenTelemetry SDK** を使用してタグがどのようにキャプチャされるかを確認する -* **Troubleshooting MetricSet** を作成する -* **Tag Spotlight** を使用して問題をトラブルシューティングし、根本原因を特定する - -それでは始めましょう！ - -{{% notice title="Tip" style="primary" icon="lightbulb" %}} -このワークショップを最も簡単にナビゲートする方法は以下の通りです： - -* このページの右上にある左右の矢印（**<** | **>**）を使用する -* キーボードの左（◀️）および右（▶️）カーソルキーを使用する - {{% /notice %}} diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/apm_overview.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/apm_overview.png deleted file mode 100644 index a94e5d4a02..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/apm_overview.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/create_troubleshooting_metric_set.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/create_troubleshooting_metric_set.png deleted file mode 100644 index d914ebbe9c..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/create_troubleshooting_metric_set.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/error_trace.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/error_trace.png deleted file mode 100644 index a6050b9891..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/error_trace.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/k8snode.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/k8snode.png deleted file mode 100644 index e46567b615..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/k8snode.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/long_running_trace.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/long_running_trace.png deleted file mode 100644 index 5aff1206fb..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/long_running_trace.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/pending_metric_set.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/pending_metric_set.png deleted file mode 100644 index c57691b1e9..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/pending_metric_set.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/service_map.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/service_map.png deleted file mode 100644 index 49ba00e560..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/service_map.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/service_map_breakdown.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/service_map_breakdown.png deleted file mode 100644 index b0077537a2..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/service_map_breakdown.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/tag_spotlight_errors.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/tag_spotlight_errors.png deleted file mode 100644 index e46e7ebbc0..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/tag_spotlight_errors.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/tag_spotlight_latency.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/tag_spotlight_latency.png deleted file mode 100644 index 7607395147..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/tag_spotlight_latency.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/traces.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/traces.png deleted file mode 100644 index acd06d6578..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/traces.png and /dev/null differ diff --git a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/traces_with_errors.png b/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/traces_with_errors.png deleted file mode 100644 index 1f94325271..0000000000 Binary files a/content/ja/ninja-workshops/9-solving-problems-with-o11y-cloud/images/traces_with_errors.png and /dev/null differ diff --git a/content/ja/ninja-workshops/2-hpa/1-deploy-otel.md b/content/ja/ninja-workshops/infrastructure/1-hpa/1-deploy-otel.md similarity index 76% rename from content/ja/ninja-workshops/2-hpa/1-deploy-otel.md rename to content/ja/ninja-workshops/infrastructure/1-hpa/1-deploy-otel.md index 706522d31e..3fa7558f4f 100644 --- a/content/ja/ninja-workshops/2-hpa/1-deploy-otel.md +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/1-deploy-otel.md @@ -1,20 +1,20 @@ --- -title: Kubernetes への OpenTelemetry Collector のデプロイ -linkTitle: 1. OTel Collector のデプロイ +title: KubernetesにOpenTelemetry Collectorをデプロイする +linkTitle: 1. OTel Collectorのデプロイ weight: 1 --- -## 1. EC2 インスタンスへの接続 +## 1. EC2インスタンスに接続する -Mac、Linux、またはWindowsデバイスからSSHを使用してワークショップインスタンスに接続できます。インストラクターから提供されたシートへのリンクを開いてください。このシートには、ワークショップインスタンスのIPアドレスとパスワードが記載されています。 +Mac、Linux、またはWindowsデバイスからSSHを使用してワークショップインスタンスに接続できます。インストラクターから提供されたシートへのリンクを開きます。このシートにはワークショップインスタンスのIPアドレスとパスワードが記載されています。 {{% notice style="info" %}} -ワークショップインスタンスには、このワークショップ用の正しい **Access Token** と **Realm** が事前設定されています。これらを設定する必要はありません。 +ワークショップインスタンスには、このワークショップ用の正しい **Access Token** と **Realm** が事前に設定されています。これらを設定する必要はありません。 {{% /notice %}} -## 2. Helm を使用した Splunk OTel のインストール +## 2. Helmを使用してSplunk OTelをインストールする -Splunk Helmチャートを使用してOpenTelemetry Collectorをインストールします。まず、Splunk Helmチャートリポジトリを追加して更新します: +Splunk Helmチャートを使用してOpenTelemetry Collectorをインストールします。まず、Splunk Helmチャートリポジトリを追加して更新します。 {{< tabs >}} {{% tab title="helm repo add" %}} @@ -40,7 +40,7 @@ Update Complete. ⎈Happy Helming!⎈ {{% /tab %}} {{< /tabs >}} -以下のコマンドでOpenTelemetry Collector Helmをインストールします。**編集しないでください**: +以下のコマンドでOpenTelemetry Collector Helmをインストールします。編集 **しないで** ください。 {{< tabs >}} {{% tab title="helm install" %}} @@ -60,9 +60,9 @@ splunk-otel-collector-chart/splunk-otel-collector \ {{% /tab %}} {{< /tabs >}} -## 3. デプロイの確認 +## 3. デプロイメントの確認 -`kubectl get pods` を実行してデプロイの進行状況を監視できます。通常、約30秒後に新しいPodが起動して実行中であることが報告されます。 +`kubectl get pods` を実行してデプロイメントの進行状況を確認できます。通常、約30秒後に新しいPodが起動して実行中であることが報告されます。 続行する前に、ステータスが **Running** と報告されていることを確認してください。 @@ -87,7 +87,7 @@ splunk-otel-collector-k8s-cluster-receiver-76bb6b555-7fhzj 0/1 Running 0 {{% /tab %}} {{< /tabs >}} -`helm` インストールで設定されたラベルを使用してログを追跡します（終了するには `ctrl + c` を押す必要があります）。 +`helm` インストールで設定されたラベルを使用してログを確認します（終了するには `ctrl + c` を押す必要があります）。 {{< tabs >}} {{% tab title="kubectl logs" %}} @@ -104,7 +104,7 @@ kubectl logs -l app=splunk-otel-collector -f --container otel-collector ![k9s](../images/k9s.png) {{% notice title="失敗したインストールの削除" style="warning" %}} -Splunk OpenTelemetry Collectorのインストールでエラーが発生した場合は、以下のコマンドを使用してインストールを削除し、やり直すことができます: +Splunk OpenTelemetry Collectorのインストールでエラーが発生した場合、以下のコマンドでインストールを削除してやり直すことができます。 ``` sh helm delete splunk-otel-collector diff --git a/content/ja/ninja-workshops/infrastructure/1-hpa/2-k8s-namespaces-dns.md b/content/ja/ninja-workshops/infrastructure/1-hpa/2-k8s-namespaces-dns.md new file mode 100644 index 0000000000..3c19c8d9de --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/2-k8s-namespaces-dns.md @@ -0,0 +1,41 @@ +--- +title: K8s NamespaceとDNS +linkTitle: 2. K8s Namespaceと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アドレスなどのさまざまな情報を覚えやすい名前に紐付けるメカニズムです。DNSシステムを使用してリクエスト名をIPアドレスに変換することで、エンドユーザーはターゲットのドメイン名に容易に到達できます。 + +ほとんどのKubernetesクラスターには、サービスディスカバリのための軽量なアプローチを提供するように、デフォルトで設定された内部DNSサービスが含まれています。PodやServiceが作成、削除、またはノード間で移動された場合でも、組み込みのサービスディスカバリにより、アプリケーションはKubernetesクラスター上のサービスを容易に識別し通信できます。 + +つまり、KubernetesのDNSシステムは、各PodとServiceにDNSエントリを作成します。一般的に、Podは次のようなDNS名前解決を持ちます。 + +``` text +pod-name.my-namespace.pod.cluster-domain.example +``` + +例えば、`default` Namespace内のPodのPod名が `my_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/2-hpa/3-apache-otel-receiver.md b/content/ja/ninja-workshops/infrastructure/1-hpa/3-apache-otel-receiver.md similarity index 56% rename from content/ja/ninja-workshops/2-hpa/3-apache-otel-receiver.md rename to content/ja/ninja-workshops/infrastructure/1-hpa/3-apache-otel-receiver.md index b98a4505d9..a4842a5d17 100644 --- a/content/ja/ninja-workshops/2-hpa/3-apache-otel-receiver.md +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/3-apache-otel-receiver.md @@ -4,15 +4,15 @@ linkTitle: 3. Apache OTel Receiver weight: 3 --- -## 1. PHP/Apache 用の OTel Receiver の確認 +## 1. PHP/Apache用OTel Receiverの確認 -YAMLファイル `~/workshop/k3s/otel-apache.yaml` を確認し、以下のコマンドで内容を検証します: +YAMLファイル `~/workshop/k3s/otel-apache.yaml` を確認し、以下のコマンドで内容を検証します。 ``` bash cat ~/workshop/k3s/otel-apache.yaml ``` -このファイルには、PHP/Apacheデプロイメントを監視するためのOpenTelemetryエージェントの設定が含まれています。 +このファイルには、PHP/Apacheデプロイメントをモニタリングするための OpenTelemetry エージェントの設定が含まれています。 ```yaml agent: @@ -26,15 +26,15 @@ agent: endpoint: http://php-apache-svc.apache.svc.cluster.local/server-status?auto ``` -## 2. OpenTelemetry 設定における観測ルール +## 2. OpenTelemetry設定におけるObservation Rules -上記のファイルには、OTel `receiver_creator` を使用したApacheの観測ルールが含まれています。このReceiverは、観測されたエンドポイントが設定されたルールに一致するかどうかに基づいて、実行時に他のReceiverをインスタンス化できます。 +上記のファイルには、OTelの `receiver_creator` を使用したApacheのobservation ruleが含まれています。このReceiverは、観測されたエンドポイントが設定されたルールに一致するかどうかに基づいて、実行時に他のReceiverをインスタンス化できます。 -設定されたルールは、検出された各エンドポイントに対して評価されます。ルールがtrueと評価された場合、そのルールのReceiverは、一致したエンドポイントに対して設定どおりに開始されます。 +設定されたルールは、検出された各エンドポイントに対して評価されます。ルールがtrueと評価された場合、そのルールに対応するReceiverが、一致したエンドポイントに対して設定どおりに起動されます。 -上記のファイルでは、OpenTelemetryエージェントに対して、名前が `apache` に一致し、ポート `80` が開いているPodを探すように指示しています。見つかると、エージェントは設定されたURLからApacheメトリクスを読み取るApache Receiverを設定します。上記のYAML内のサービス用のK8s DNSベースのURLに注目してください。 +上記のファイルでは、OpenTelemetryエージェントに対して、名前が `apache` に一致し、ポート `80` が開いているPodを探すよう指示しています。見つかると、エージェントは設定されたURLからApacheメトリクスを読み取るためのApache Receiverを構成します。上記のYAMLに記載されているサービス用のK8s DNSベースURLに注目してください。 -Apache設定を使用するには、以下のコマンドで既存のSplunk OpenTelemetry Collector Helmチャートをアップグレードして `otel-apache.yaml` ファイルを使用します: +Apache設定を使用するには、以下のコマンドで既存のSplunk OpenTelemetry Collector Helmチャートをアップグレードして `otel-apache.yaml` ファイルを適用します。 {{< tabs >}} {{% tab title="Helm Upgrade" %}} @@ -56,7 +56,7 @@ splunk-otel-collector-chart/splunk-otel-collector \ {{< /tabs >}} {{% notice title="注意" style="info" %}} -デプロイメントの **REVISION** 番号が変更されました。これは変更を追跡するのに便利な方法です。 +デプロイメントの **REVISION** 番号が変更されています。これは変更を追跡するのに便利な方法です。 ``` text Release "splunk-otel-collector" has been upgraded. Happy Helming! @@ -78,28 +78,28 @@ Splunk OpenTelemetry Collector is installed and configured to send data to Splun ConfigMapは、アプリケーションに注入できるキーと値のペアで構成されるKubernetesのオブジェクトです。ConfigMapを使用すると、設定をPodから分離できます。 -ConfigMapを使用すると、設定データのハードコーディングを防ぐことができます。ConfigMapは、機密性のない暗号化されていない設定情報を保存および共有するのに便利です。 +ConfigMapを使用することで、設定データのハードコーディングを防止できます。ConfigMapは、機密性のない暗号化されていない設定情報の保存と共有に役立ちます。 -OpenTelemetry Collector/エージェントは、ConfigMapを使用してエージェントとK8s Cluster Receiverの設定を保存します。変更後にエージェントの現在の設定を確認するには、以下のコマンドを実行します: +OpenTelemetry Collector/エージェントは、ConfigMapを使用してエージェントとK8s Cluster Receiverの設定を保存します。変更後は、以下のコマンドを実行してエージェントの現在の設定を確認できます。 ``` bash kubectl get cm ``` {{% notice title="ワークショップの質問" style="tip" icon="question" %}} -Collectorで使用されているConfigMapはいくつありますか？ +Collectorが使用しているConfigMapはいくつありますか？ {{% /notice %}} -NamespaceからConfigMapのリストを取得したら、`otel-agent` 用のものを選択し、以下のコマンドで表示します: +namespaceからConfigMapの一覧を取得したら、`otel-agent` 用のものを選択し、以下のコマンドで表示します。 ``` bash kubectl get cm splunk-otel-collector-otel-agent -o yaml ``` {{% notice title="注意" style="info" %}} -オプション `-o yaml` は、ConfigMapの内容を読みやすいYAML形式で出力します。 +`-o yaml` オプションを使用すると、ConfigMapの内容が読みやすいYAML形式で出力されます。 {{% /notice %}} {{% notice title="ワークショップの質問" style="tip" icon="question" %}} -`otel-apache.yaml` の設定は、CollectorエージェントのConfigMapに表示されていますか？ +`otel-apache.yaml` の設定はCollectorエージェントのConfigMapに反映されていますか？ {{% /notice %}} diff --git a/content/ja/ninja-workshops/2-hpa/4-deploy-apache.md b/content/ja/ninja-workshops/infrastructure/1-hpa/4-deploy-apache.md similarity index 54% rename from content/ja/ninja-workshops/2-hpa/4-deploy-apache.md rename to content/ja/ninja-workshops/infrastructure/1-hpa/4-deploy-apache.md index b6c99b2ad4..7af76b28d9 100644 --- a/content/ja/ninja-workshops/2-hpa/4-deploy-apache.md +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/4-deploy-apache.md @@ -1,20 +1,20 @@ --- -title: Apache のデプロイ -linkTitle: 4. Apache のデプロイ +title: Apacheのデプロイ +linkTitle: 4. Apacheのデプロイ weight: 4 --- -## 1. PHP/Apache デプロイメント YAML の確認 +## 1. PHP/ApacheデプロイメントYAMLの確認 -YAMLファイル `~/workshop/k3s/php-apache.yaml` を確認し、以下のコマンドで内容を検証します: +YAMLファイル `~/workshop/k3s/php-apache.yaml` を確認し、以下のコマンドで内容を検証します。 ``` bash cat ~/workshop/k3s/php-apache.yaml ``` -このファイルには、PHP/Apacheデプロイメントの設定が含まれており、PHP/Apacheイメージの単一レプリカを持つ新しいStatefulSetを作成します。 +このファイルにはPHP/Apacheデプロイメントの設定が含まれており、PHP/Apacheイメージのレプリカを1つ持つ新しいStatefulSetを作成します。 -ステートレスアプリケーションは、どのネットワークを使用しているかを気にせず、永続ストレージを必要としません。ステートレスアプリの例としては、Apache、Nginx、TomcatなどのWebサーバーがあります。 +ステートレスアプリケーションは、使用するネットワークを問わず、永続ストレージも必要としません。ステートレスアプリの例としては、Apache、Nginx、Tomcatなどのウェブサーバーがあります。 ```yaml apiVersion: apps/v1 @@ -61,34 +61,34 @@ spec: run: php-apache ``` -## 2. PHP/Apache のデプロイ +## 2. PHP/Apacheのデプロイ -`apache` Namespaceを作成し、PHP/Apacheアプリケーションをクラスターにデプロイします。 +`apache` namespaceを作成し、PHP/Apacheアプリケーションをクラスターにデプロイします。 -`apache` Namespaceを作成します: +`apache` namespaceを作成します。 ``` bash kubectl create namespace apache ``` -PHP/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インスタンスのどのメトリクスが報告されていますか？ +Apacheインスタンスのどのメトリクスが **Apache web servers (OTel) Navigator** で報告されていますか？ {{% /notice %}} {{% notice title="ワークショップの質問" style="tip" icon="question" %}} Log Observerを使用して、PHP/Apacheデプロイメントの問題は何ですか？ -**ヒント:** フィルターを調整して、`k8s.namespace.name = apache` および `k8s.cluster.name = ` を使用してください。 +**ヒント:** フィルターを `k8s.namespace.name = apache` および `k8s.cluster.name = ` に調整してください。 {{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/1-hpa/5-fix-apache.md b/content/ja/ninja-workshops/infrastructure/1-hpa/5-fix-apache.md new file mode 100644 index 0000000000..510cf86913 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/5-fix-apache.md @@ -0,0 +1,130 @@ +--- +title: PHP/Apacheの問題を修正する +linkTitle: 5. PHP/Apacheの問題を修正する +weight: 5 +--- +## 1. Kubernetesリソース + +特に本番環境のKubernetesクラスターでは、CPUとメモリは貴重なリソースと見なされます。クラスターオペレーターは通常、デプロイメントでPodやサービスが必要とするCPUとメモリの量を指定するよう求めます。これにより、クラスターがソリューションを配置するノードを自動的に管理できるようになります。 + +これは、アプリケーション/Podのデプロイメントにリソースセクションを配置することで行います。 + +**例:** + +``` 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つのシナリオは、ノード上に十分なメモリやCPUがない場合です。その場合、クラスターはより空きのある別のノードにPodを再スケジュールしようとします。 + +それが失敗した場合、またはアプリケーションのデプロイ時に十分な空きがない場合、クラスターは利用可能なノードのいずれかにリミットに従ってPodをデプロイするのに十分な空きができるまで、ワークロード/デプロイメントをスケジュールモードにします。 + +## 2. PHP/Apacheデプロイメントの修正 + +{{% notice title="ワークショップの質問" style="tip" icon="question" %}} + +開始する前に、PHP/Apacheデプロイメントの現在のステータスを確認しましょう。 **Alerts & Detectors** の下で、どのディテクターが発火しましたか？この情報は他にどこで確認できますか？ + +{{% /notice %}} + +PHP/Apache StatefulSetを修正するには、以下のコマンドを使用して `~/workshop/k3s/php-apache.yaml` を編集し、CPUリソースを減らします。 + +``` bash +vim ~/workshop/k3s/php-apache.yaml +``` + +リソースセクションを見つけて、CPUリミットを **1** に、CPUリクエストを **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="ワークショップの質問" style="tip" icon="question" %}} +**Apache Web Servers** ダッシュボードにデータが表示されていますか？ + +**ヒント:** フィルターと時間範囲を使用してデータを絞り込むことを忘れないでください。 +{{% /notice %}} + +Apache Web Servers Navigatorダッシュボードを数分間モニタリングします。 + +{{% notice title="ワークショップの質問" style="tip" icon="question" %}} + +# Hosts reportingチャートに何が起きていますか？ + +{{% /notice %}} + +## 4. メモリの問題を修正する + +Apacheダッシュボードに戻ると、メトリクスが送信されなくなっていることに気づくでしょう。別のリソースの問題があり、今回はメモリ不足（Out of Memory）です。StatefulSetを編集して、以下のイメージに示されている値にメモリを増やしましょう。 + +``` bash +kubectl edit statefulset php-apache -n apache +``` + +``` yaml +resources: + limits: + cpu: "1" + memory: 16Mi + requests: + cpu: 500m + memory: 12Mi +``` + +変更を保存します。 + +{{% notice title="ヒント" 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/1-hpa/6-deploy-loadgen.md b/content/ja/ninja-workshops/infrastructure/1-hpa/6-deploy-loadgen.md new file mode 100644 index 0000000000..0f9b93008c --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/6-deploy-loadgen.md @@ -0,0 +1,88 @@ +--- +title: Load Generatorのデプロイ +linkTitle: 6. Load Generatorのデプロイ +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 +``` + +このファイルにはLoad Generatorの設定が含まれており、Load Generatorイメージのレプリカを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 +``` + +Load Generatorをデプロイすると、`loadgen` namespaceでPodが実行されていることを確認できます。以前使用した同様のコマンドを使って、コマンドラインからPodのステータスを確認します。 + +{{% notice title="ワークショップの質問" style="tip" icon="question" %}} +Apache Navigatorでどのメトリクスが大幅に増加しましたか？ +{{% /notice %}} + +## 4. Load Generatorのスケール + +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 +``` + +![ReplicaSet](../images/k8s-workload-replicaset.png) + +{{% notice title="ワークショップの質問" style="tip" icon="question" %}} +Apache Navigatorでどのような影響が見られますか？ +{{% /notice %}} + +Load Generatorを約2〜3分間実行し続け、Kubernetes NavigatorとApache Navigatorでメトリクスを観察し続けてください。 diff --git a/content/ja/ninja-workshops/2-hpa/7-setup-hpa.md b/content/ja/ninja-workshops/infrastructure/1-hpa/7-setup-hpa.md similarity index 50% rename from content/ja/ninja-workshops/2-hpa/7-setup-hpa.md rename to content/ja/ninja-workshops/infrastructure/1-hpa/7-setup-hpa.md index 30cfea3bc1..fc33a4dae6 100644 --- a/content/ja/ninja-workshops/2-hpa/7-setup-hpa.md +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/7-setup-hpa.md @@ -1,24 +1,24 @@ --- title: Horizontal Pod Autoscaling (HPA) のセットアップ -linkTitle: 7. HPA のセットアップ +linkTitle: 7. HPAのセットアップ weight: 7 --- -Kubernetesでは、HorizontalPodAutoscalerがワークロードリソース（DeploymentやStatefulSetなど）を自動的に更新し、需要に合わせてワークロードを自動的にスケーリングします。 +Kubernetesでは、HorizontalPodAutoscalerがワークロードリソース（DeploymentやStatefulSetなど）を自動的に更新し、需要に合わせてワークロードを自動的にスケールします。 -水平スケーリングとは、負荷の増加に対応してより多くのPodをデプロイすることを意味します。これは垂直スケーリングとは異なります。Kubernetesにおける垂直スケーリングは、ワークロードですでに実行されているPodにより多くのリソース（メモリやCPUなど）を割り当てることを意味します。 +水平スケーリングとは、負荷の増加に対してより多くのPodをデプロイすることで対応することを意味します。これは垂直スケーリングとは異なり、Kubernetesにおける垂直スケーリングは、ワークロードのために既に実行されているPodにより多くのリソース（例: メモリやCPU）を割り当てることを意味します。 -負荷が減少し、Podの数が設定された最小値を超えている場合、HorizontalPodAutoscalerはワークロードリソース（Deployment、StatefulSet、またはその他の類似リソース）にスケールダウンするよう指示します。 +負荷が減少し、Podの数が設定された最小値を超えている場合、HorizontalPodAutoscalerはワークロードリソース（Deployment、StatefulSet、またはその他の類似リソース）にスケールダウンを指示します。 -## 1. HPA のセットアップ +## 1. HPAのセットアップ -`~/workshop/k3s/hpa.yaml` ファイルを確認し、以下のコマンドで内容を検証します: +`~/workshop/k3s/hpa.yaml` ファイルを確認し、以下のコマンドで内容を検証します。 ``` bash cat ~/workshop/k3s/hpa.yaml ``` -このファイルには、Horizontal Pod Autoscalerの設定が含まれており、`php-apache` デプロイメント用の新しいHPAを作成します。 +このファイルにはHorizontal Pod Autoscalerの設定が含まれており、`php-apache` デプロイメント用の新しいHPAを作成します。 ``` yaml apiVersion: autoscaling/v2 @@ -48,45 +48,45 @@ spec: name: php-apache ``` -デプロイされると、`php-apache` は平均CPU使用率が50% を超えるか、デプロイメントの平均メモリ使用率が75% を超えると自動スケールします。最小1 Pod、最大4 Podです。 +デプロイされると、`php-apache` は平均CPU使用率が50%を超えるか、デプロイメントの平均メモリ使用率が75%を超えた場合にオートスケールします。最小1Pod、最大4Podの範囲でスケールします。 ``` text kubectl apply -f ~/workshop/k3s/hpa.yaml ``` -## 2. HPA の検証 +## 2. HPAの検証 ``` text kubectl get hpa -n apache ``` -Kubernetesの **Workloads** または **Node Detail** タブに移動し、HPAデプロイメントを確認します。 +Kubernetesの **Workloads** または **Node Detail** タブに移動し、HPAのデプロイメントを確認します。 {{% notice title="ワークショップの質問" style="tip" icon="question" %}} -1. 追加で作成された `php-apache-x` Podはいくつありますか？ -2. **Apache web servers (OTel) Navigator** でどのメトリクスが再び大幅に増加しましたか？ +1. 追加の `php-apache-x` Podはいくつ作成されましたか？ +2. **Apache web servers (OTel) Navigator** のどのメトリクスが再び大幅に増加しましたか？ {{% /notice %}} -## 3. HPA レプリカ数の増加 +## 3. HPAのレプリカ数を増やす -`maxReplicas` を8に増やします +`maxReplicas` を8に増やします。 ``` bash kubectl edit hpa php-apache -n apache ``` -変更を保存します（ヒント: `Esc` を押してから `:wq!` を入力して変更を保存します）。 +変更を保存します（ヒント: `Esc` に続けて `:wq!` を使用して変更を保存します）。 {{% notice title="ワークショップの質問" style="tip" icon="question" %}} -1. 現在実行中のPodはいくつありますか？ +1. 現在いくつのPodが実行されていますか？ -2. 保留中のPodはいくつありますか？ +2. いくつのPodがpending状態ですか？ -3. なぜ保留中なのですか？ +3. なぜpending状態なのですか？ {{% /notice %}} -**おめでとうございます！** ワークショップが完了しました。 +**おめでとうございます！** ワークショップを完了しました。 diff --git a/content/ja/ninja-workshops/infrastructure/1-hpa/_index.md b/content/ja/ninja-workshops/infrastructure/1-hpa/_index.md new file mode 100644 index 0000000000..4b3d22db53 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/_index.md @@ -0,0 +1,19 @@ +--- +title: KubernetesにおけるHorizontal Pod Autoscalingのモニタリング +linkTitle: Horizontal Pod Autoscaling +description: Splunk OpenTelemetry CollectorでKubernetes HPAをモニタリングし、スケールアップおよびスケールダウンイベントをリアルタイムで監視します。 +weight: 1 +authors: ["Robert Castley"] +time: 45 minutes +aliases: + - /ninja-workshops/2-hpa/ +product: "Observability Cloud" +--- + +このハンズオンワークショップでは、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/1-hpa/kubernetes-navigator.md b/content/ja/ninja-workshops/infrastructure/1-hpa/kubernetes-navigator.md new file mode 100644 index 0000000000..892318be4d --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/1-hpa/kubernetes-navigator.md @@ -0,0 +1,120 @@ +--- +title: Kubernetes Navigatorツアー +linkTitle: 2. Kubernetes Navigator +weight: 2 +hidden: true +--- + +## 1. クラスターとワークロードビュー + +Kubernetes Navigatorでは、Kubernetesデータを表示するための2つのユースケースが提供されています。 + +* **K8s workloads** はワークロード、つまり *デプロイメント* に関する情報を提供することに重点を置いています。 +* **K8s nodes** はクラスター、ノード、Pod、コンテナのパフォーマンスに関するインサイトを提供することに重点を置いています。 + +最初に必要に応じてどちらかのビューを選択します（必要に応じていつでもビューを切り替えることができます）。このワークショップで最もよく使用するのはワークロードビューであり、そちらに焦点を当てます。 + +### 1.1 K8sクラスター名の確認 + +最初のタスクは、自分のクラスターを特定して見つけることです。クラスター名は、事前設定された環境変数 `INSTANCE` によって決定されます。クラスター名を確認するには、ターミナルで次のコマンドを実行します。 + +``` bash +echo $INSTANCE-k3s-cluster +``` + +クラスター名をメモしておいてください。ワークショップの後半でフィルタリングに使用します。 + +## 2. ワークロードとワークロード詳細ペイン + +Observability UIの **Infrastructure** ページに移動し、**Kubernetes** を選択します。Kubernetesサービスのセットが表示され、その中に **Kubernetes workloads** ペインがあります。このペインには、すべてのワークロードで処理されている負荷の概要を示す小さなグラフが表示されます。**Kubernetes workloads** ペインをクリックすると、ワークロードビューに移動します。 + +最初は、Observability Cloud Orgに報告されているすべてのクラスターのすべてのワークロードが表示されます。いずれかのワークロードでアラートが発生している場合、下の画像の右上にハイライト表示されます。 + +![workloads](../images/k8s-workloads-screen.png) + +次に、フィルターツールバーで **Cluster** でフィルタリングして自分のクラスターを見つけます。 + +{{% notice title="注意" style="info" %}} +検索ボックスに `emea-ws-7*` のような部分的な名前を入力すると、クラスターをすばやく見つけることができます。 + +また、デフォルトの時間範囲を **-4h** から直近15分（**-15m**）に切り替えることをお勧めします。 +{{% /notice %}} + +![workloads-filter](../images/k8s-workloads-filter.png) + +これで、自分のクラスターのデータのみが表示されます。 + +{{% notice title="ワークショップの質問" style="tip" icon="question" %}} +クラスターで実行されているワークロードの数と、ネームスペースの数はいくつですか？ +{{% /notice %}} + +### 2.1 Navigator選択チャートの使用 + +デフォルトでは、**Kubernetes Workloads** テーブルは `# Pods Failed` でフィルタリングされ、`k8s.namespace.name` でグループ化されています。`default` ネームスペースを展開して、そのネームスペース内のワークロードを確認します。 + +![k8s-workload-selection](../images/workload-selection.png) + +次に、**Map** アイコン（**Table** アイコンの隣）を選択して、リストビューをヒートマップビューに変更します。このオプションを変更すると、次のような表示になります。 + +![k8s-Heat-map](../images/workloads-heatmap.png) + +このビューでは、各ワークロードが色付きの四角形で表示されています。これらの四角形は、選択した **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** に変更します。 + +![k8s-Heat-map](../images/set-find-outliers.png) + +**Find Outliers** ビューは、ワークロード（または使用するNavigatorに応じて任意のサービス）の選択を表示し、何か変化があったかどうかをすばやく把握する必要がある場合に非常に便利です。 + +パフォーマンスが異なる（増加または減少した）項目（この場合はワークロード）を素早く把握でき、問題を発見しやすくなります。 + +### 2.2 Deployment Overviewペイン + +Deployment Overviewペインでは、デプロイメントのステータスを素早く把握できます。デプロイメントのPodがPending、Running、Succeeded、Failed、Unknownのいずれの状態にあるかを一目で確認できます。 + +![k8s-workload-overview](../images/k8s-deployment-overview.png) + +* *Running:* Podがデプロイされ、実行中の状態 +* *Pending:* デプロイ待ち +* *Succeeded:* Podがデプロイされ、ジョブが完了して終了した状態 +* *Failed:* Pod内のコンテナが実行され、何らかのエラーが返された状態 +* *Unknown:* Kubernetesが既知の状態を報告していない状態（例えば、Podの起動中や停止中の場合など） + +ワークロード名がチャートの表示幅を超えている場合は、マウスをホバーすることで名前を展開できます。 + +特定のワークロードにフィルタリングするには、**k8s.workload.name** 列のワークロード名の横にある3つのドット **...** をクリックし、ドロップダウンボックスから **Filter** を選択します。 + +![workload-add-filter](../images/workload-add-filter.png) + +これにより、選択したワークロードがフィルターに追加されます。**default** ネームスペース内の単一のワークロードが表示されます。 + +![workload-add-filter](../images/heatmap-filter-down.png) + +上のヒートマップから **default** ネームスペース内の **splunk-otel-collector-k8s-cluster-receiver** を見つけて、四角形をクリックしてワークロードの詳細情報を表示します。 + +![workload-add-filter](../images/k8s-workload-detail.png) + +{{% notice title="ワークショップの質問" style="tip" icon="question" %}} +otel-collectorのCPUリクエストとCPUリミットの単位は何ですか？ +{{% /notice %}} + +この時点でPodの情報をさらに掘り下げることができますが、それはこのワークショップの範囲外です。 + +## 3. Navigator Sidebar + +ワークショップの後半で、Apacheサーバーをクラスターにデプロイします。デプロイすると **Navigator Sidebar** にアイコンが表示されます。 + +KubernetesのNavigatorでは、Navigator Sidebarで依存するサービスやコンテナを追跡できます。Navigator Sidebarを最大限に活用するには、`service.name` という追加ディメンションを設定して追跡するサービスを構成します。このワークショップでは、Apache監視用のCollector設定で `extraDimensions` をすでに構成しています。 + +```yaml +extraDimensions: + service.name: php-apache +``` + +Navigator Sidebarが展開され、下の画像のように検出されたサービスへのリンクが追加されます。 + +![Pivotbar](../images/pivotbar.png) + +これにより、Navigator間を簡単に切り替えることができます。Apacheサーバーインスタンスについても同様で、Navigator Sidebarから素早くKubernetes Navigatorに戻ることができます。 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 deleted file mode 100644 index 88f59f2006..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: AWS Setup -linkTitle: 1. AWS Setup -weight: 1 -time: 10 minutes ---- - -## AWS で Red Hat OpenShift Service を有効にする - -AWS アカウントに OpenShift をデプロイするには、まず [AWS console](https://us-east-1.console.aws.amazon.com/rosa/home?region=us-east-1#/) を使用して Red Hat OpenShift service を有効にする必要があります。 - -次に、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 deleted file mode 100644 index 381c3a6aa0..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -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 -``` - -AWS アカウントから Red Hat OpenShift Service を完全に削除したい場合は、[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/6-setup-users.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md deleted file mode 100644 index b763e86e45..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md +++ /dev/null @@ -1,170 +0,0 @@ ---- -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)を参照してください。 - -### ワークショップユーザーとしてログイン - -ローカルマシンからワークショップユーザーの一人としてログインしてみます - -``` 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 deleted file mode 100644 index eecfdc9eeb..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: OpenTelemetry Collector のインストール -linkTitle: 7. OpenTelemetry Collector のインストール -weight: 7 -time: 5 minutes ---- - -このセクションでは、clusterReceiver のみを有効にした状態で OpenTelemetry Collector をインストールします（ワークショップ参加者は各自のネームスペースに独自のエージェントをインストールするため）。次に、この Collector のインストールによって作成された ClusterRole を各ワークショップ参加者のネームスペースにバインドします。 - -## OpenTelemetry Collector のインストール - -まず、Collector 用の新しいプロジェクトを作成し、そのプロジェクトに切り替えます: - -```bash -oc new-project admin-otel -``` - -Splunk OpenTelemetry Collector for Kubernetes の Helm チャートリポジトリを追加します: - -```bash -helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart -```` - -リポジトリを最新の状態に更新します: - -```bash -helm repo update -```` - -`./admin-otel-collector/admin-otel-collector-values.yaml` というファイルを確認してください。このファイルを使用して OpenTelemetry Collector をインストールします。 - -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 -```` - -## 各ワークショップ参加者のサービスアカウント作成と 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 deleted file mode 100644 index 888f0babb9..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: ベクトルデータベースのデプロイ -linkTitle: 8. ベクトルデータベースのデプロイ -weight: 8 -time: 10 minutes ---- - -このステップでは、OpenShift クラスターにベクトルデータベースをデプロイし、ワークショップ参加者が使用するテストデータを投入します。 - -## ベクトルデータベースのデプロイ - -このワークショップでは、オープンソースのベクトルデータベースである [Weaviate](https://weaviate.io/) をデプロイします。 - -まず、Weaviate helm チャートを含む Weaviate helm リポジトリを追加します - -``` bash -helm repo add weaviate https://weaviate.github.io/weaviate-helm -helm repo update -``` - -`weaviate/weaviate-values.yaml` ファイルには、Weaviate ベクトルデータベースのデプロイに使用する設定が含まれています。 - -Weaviate が Prometheus receiver で後からスクレイプできるメトリクスを公開するように、以下の環境変数を `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 -``` - -## ベクトルデータベースへのデータ投入 - -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` の設定に従い、[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/_index.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md deleted file mode 100644 index 0b41f40d0a..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/_index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: ワークショップのセットアップ -linkTitle: 1. ワークショップのセットアップ -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 deleted file mode 100644 index 146efa4dfa..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: ワークショップ環境の概要 -linkTitle: 1. ワークショップ環境の概要 -weight: 1 -time: 5 minutes ---- - -**Cisco の AI 対応 POD** は、最先端のハードウェアとソフトウェアを組み合わせて、 -堅牢でスケーラブルかつ効率的な 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 メトリクスをシミュレートします - -### 参加者のワークスペース - -各参加者は共有クラスター内の専用の namespace を受け取り、 -独立した作業のための分離された環境が確保されます。 - -## ワークショップのアクティビティ - -ワークショップ中、各参加者は以下のタスクを実行します - -1. 自分の namespace に **OpenTelemetry collector** をデプロイして構成する -2. オブザーバビリティデータ収集をクラスターインフラストラクチャと統合する -3. NVIDIA NIM models を活用する **Python アプリケーション**をデプロイする -4. Splunk Observability Cloud を使用してアプリケーションのパフォーマンスとインフラストラクチャメトリクスを監視する - -## Prometheus とは？ - -**Prometheus** は通常、ストレージとアラートに使用されるフルスタック監視システムを指しますが、 -このワークショップでは Prometheus エコシステムのデータ標準に焦点を当てます。 - -**Prometheus Exporters** を活用します。これは、コンポーネントの内部状態を -標準化されたメトリクスエンドポイント（例）に -変換する小さなユーティリティです。 - -フル Prometheus サーバーを使用してこのデータを収集する代わりに、 -**OpenTelemetry Collector** を使用します。その **Prometheus receiver** を使用することで、 -コレクターはこれらのエンドポイントを**スクレイプ**でき、広くサポートされている業界標準フォーマットを使用して -リッチなテレメトリデータを収集できます。 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 deleted file mode 100644 index 6de64780e2..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/11-review-traces.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: メトリクス、トレース、ログの確認 -linkTitle: 11. メトリクス、トレース、ログの確認 -weight: 11 -time: 10 minutes ---- - -## Splunk Observability Cloud でトレースデータを表示する - -Splunk Observability Cloud で `APM` に移動し、`Service Map` を選択します。 -お使いの環境名が選択されていることを確認してください（例: `ai-pod-workshop-participant-1`）。 -以下のようなサービスマップが表示されるはずです: - -![Service Map](../../images/ServiceMap.png) - -右側のメニューで `Traces` をクリックします。次に、実行時間が長いトレースの1つを選択します。以下の例のように表示されるはずです: - -![Trace](../../images/Trace.png) - -このトレースは、ユーザーの質問（例: "How much memory does the NVIDIA H200 have?"）に対する回答を返すためにアプリケーションが実行したすべてのインタラクションを示しています。 - -例えば、アプリケーションが Weaviate ベクトルデータベース内で質問に関連するドキュメントを検索するために類似性検索を実行した箇所を確認できます。 - -また、ベクトルデータベースから取得したコンテキストを含め、アプリケーションが LLM に送信するプロンプトをどのように作成したかも確認できます: - -![Prompt Template](../../images/PromptTemplate.png) - -> 注意: トレースのウォーターフォールビューに `chat` および `invoke_workflow` の AI インタラクションが表示されない場合、または右側に `AI details` タブが表示されない場合は、有効にする必要がある superpowers についてインストラクターに確認してください。 - -最後に、LLM からのレスポンス、所要時間、使用された入力トークンと出力トークンの数を確認できます: - -![LLM Response](../../images/LLMResponse.png) - -## メトリクスが Splunk に送信されていることを確認する - -Splunk Observability Cloud で `Dashboards` に移動し、`Built-in dashboard groups` に含まれている `Cisco AI PODs Dashboard` を検索します。 -`NIM FOR LLMS` タブに移動し、ダッシュボードがお使いの OpenShift クラスター名でフィルタリングされていることを確認します。以下の例のようにチャートにデータが表示されているはずです: - -![NIM LLMS Dashboard](../../images/NIMLLM.png) 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 deleted file mode 100644 index ec4389d0d0..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/12-wrapup.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: まとめ -linkTitle: 12. Wrap-Up -weight: 12 -time: 5 minutes ---- - -## まとめ - -このワークショップをお楽しみいただけたことを願っています。このワークショップでは、Splunk Observability Cloud を使用して Cisco AI PODs を監視するために使用されるいくつかの技術をデプロイし、操作するハンズオン体験を提供しました。具体的には、以下の内容を体験していただきました - -* GPU ベースのワーカーノードを持つ RedHat OpenShift クラスターの操作。 -* NVIDIA NIM Operator および NVIDIA GPU Operator の操作。 -* NVIDIA NIM を使用してクラスターにデプロイされた Large Language Models (LLMs) の操作。 -* Red Hat OpenShift クラスターへの OpenTelemetry Collector のデプロイ。 -* インフラストラクチャメトリクスを取り込むための Prometheus レシーバーのコレクターへの追加。 -* クラスター内の Weaviate ベクターデータベースの監視。 -* Prometheus を使用した Pure Storage メトリクスの監視設定。 -* Large Language Models (LLMs) と連携する Python サービスへの OpenTelemetry によるインストルメンテーション。 -* LLMs と連携するアプリケーションのトレースにおいて 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 deleted file mode 100644 index 8508f0cbb0..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -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 client を使用 -* それ以前のバージョンの 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`）をパスに含まれる場所に移動します。例 - -``` bash -sudo mv oc /usr/local/bin/oc -sudo mv kubectl /usr/local/bin/kubectl -``` - -## OpenShift クラスターへの接続 - -Kube config ファイルが splunk ユーザーによって変更可能であることを確認します - -``` 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/5-monitor-vector-db.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md deleted file mode 100644 index 2ad00c4660..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/5-monitor-vector-db.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: ベクトルデータベースの監視 -linkTitle: 5. ベクトルデータベースの監視 -weight: 5 -time: 5 minutes ---- - -このステップでは、Weaviate ベクトルデータベースを監視するために Prometheus レシーバーを設定します。 - -## ベクトルデータベースとは？ - -**ベクトルデータベース**は、テキストや画像などの情報の**意味的な意味**を捉える数値的な「ベクトル埋め込み」としてデータを保存し、インデックスを作成します。従来のデータベースとは異なり、完全一致ではなく概念的に関連するデータポイントを見つける**類似性検索**に優れています。 - -## ベクトルデータベースはどのように使用されるか？ - -ベクトルデータベースは、Large Language Models (LLMs) を活用するアプリケーションで広く使用されている **Retrieval Augmented Generation (RAG)** と呼ばれるパターンで重要な役割を果たします。 - -パターンは以下の通りです - -* エンドユーザーがアプリケーションに質問をします -* アプリケーションが質問を受け取り、そのベクトル埋め込みを計算します -* アプリがベクトルデータベース内の関連ドキュメントを探す類似性検索を実行します -* アプリが元の質問と関連ドキュメントをコンテキストとして LLM に送信します -* LLM がコンテキストを確認し、アプリケーションにレスポンスを返します - -## Prometheus で Weaviate メトリクスを収集する - -OpenTelemetry コレクターの設定を変更して、Weaviate の Prometheus メトリクスをスクレイプしましょう。 - -`otel-collector-values.yaml` ファイルに追加の Prometheus **receiver** クリエーターセクションを追加します。`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` という新しいプロパティにコピーします。これは、Splunk Observability Cloud で使用される標準的な OpenTelemetry プロパティである `service.instance.id` を使用する他のメトリクスと 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/7-review-ai-pod-dashboards.md b/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md deleted file mode 100644 index 425d7c48df..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -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 クラスター名でフィルタリングされていることを確認してください。チャートは以下の例のように表示されるはずです - -![Kubernetes Pods](../../images/Cisco-AI-Pod-dashboard.png) - -## Pure Storage ダッシュボードタブの確認 - -`PURE STORAGE` タブに移動し、ダッシュボードが自分の OpenShift クラスター名でフィルタリングされていることを確認してください。チャートは以下の例のように表示されるはずです - -![Pure Storage Dashboard](../../images/PureStorage.png) - -## Weaviate Infrastructure Navigator の確認 - -Weaviate は AI POD にデフォルトで含まれていないため、すぐに使える AI POD ダッシュボードには含まれていません。代わりに、Infrastructure Navigator を使用して Weaviate のパフォーマンスデータを確認できます。 - -Splunk Observability Cloud で `Infrastructure` -> `AI Frameworks` -> `Weaviate` に移動します。対象の `k8s.cluster.name` でフィルタリングし、以下の例のように Navigator が表示されることを確認してください - -![Kubernetes Pods](../../images/WeaviateNavigator.png) 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 deleted file mode 100644 index 83fe7ed5b9..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/8-review-llm-app.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -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`: エンベディングの計算に使用します - -``` 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" - ) -``` - -### チェーンの定義 - -アプリケーションは **LCEL (LangChain Expression Language)** を使用してチェーンを定義します。`|`（パイプ）記号は組み立てラインのように機能し、あるステップの出力が次のステップの入力になります。 - -``` python - chain = ( - { - "context": vector_store.as_retriever(), - "question": RunnablePassthrough() - } - | prompt - | llm - | StrOutputParser() - ) -``` - -各ステップを詳しく見ていきましょう - -* **ステップ 1: 入力マップ {…}**: プロンプトの材料を準備します。 - * context: ベクトルストアをリトリーバーに変換します。これはユーザーの質問に基づいて NVIDIA データシートから最も関連性の高いスニペットを検索する検索エンジンとして機能します。 - * question: RunnablePassthrough() を使用して、ユーザーの元の質問がそのままプロンプトに渡されるようにします。 - * **注意**: これらのキー（context と question）は、先ほどプロンプトテンプレートで定義した {context} と {question} のプレースホルダーに直接マッピングされます。 -* **ステップ 2: prompt**: これは指示書です。context と question を受け取り、プロンプトテンプレートを使用してフォーマットします（例：「コンテキストのみを使用して質問に回答してください...」）。 -* **ステップ 3: llm**: これは「エンジン」です（GPT-4 のようなもの）。フォーマットされたプロンプトを読み取り、応答を生成します。 -* **ステップ 4: StrOutputParser()**: デフォルトでは、AI モデルは複雑なオブジェクトを返します。この「クリーナー」により、シンプルで読みやすいテキスト文字列が返されるようになります。 - -### チェーンの呼び出し - -最後に、アプリケーションはエンドユーザーの質問を入力として渡してチェーンを呼び出します - -``` python - response = chain.invoke(question) -``` - -これは「スタート」ボタンです。エンドユーザーの質問をパイプラインの先頭に投入すると、リトリーバー、プロンプト、LLM を順に通過して、最終的に回答が出力されます。 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 deleted file mode 100644 index 6b78eec775..0000000000 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/_index.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Workshop -linkTitle: 2. Workshop -weight: 2 ---- - -このセクションでは、ワークショップ参加者が実施する手順を説明します: - -* Red Hat OpenShift クラスターに **OpenTelemetry Collector** をデプロイする練習を行います。 -* コレクターに **Prometheus** レシーバーを追加してインフラストラクチャメトリクスを取り込む練習を行います。 -* クラスター内の **Weaviate** ベクターデータベースを監視する練習を行います。 -* Prometheus を使用して **Pure Storage** メトリクスを収集する練習を行います。 -* 大規模言語モデル (LLM) と対話する Python サービスを **OpenTelemetry** で計装する練習を行います。 -* LLM と対話するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報について理解します。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/1-aws-setup.md similarity index 57% rename from content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/1-aws-setup.md index ebc83c4993..7e02033681 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/1-aws-setup.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/1-aws-setup.md @@ -9,19 +9,19 @@ time: 10 minutes AWSアカウントにOpenShiftをデプロイするには、まず[AWSコンソール](https://us-east-1.console.aws.amazon.com/rosa/home?region=us-east-1#/)を使用してRed Hat OpenShiftサービスを有効にする必要があります。 -次に、AWSアカウントをRed Hatアカウントに接続する手順に従ってください。 +次に、AWSアカウントとRed Hatアカウントを接続する手順に従います。 ## EC2インスタンスのプロビジョニング -Red Hatクラスターをデプロイするために使用するEC2インスタンスをプロビジョニングしましょう。これにより、Mac OSでROSAコマンドラインインターフェースを実行する際の制限を回避できます。 +Red Hatクラスターのデプロイに使用するEC2インスタンスをプロビジョニングします。これにより、Mac OSでROSAコマンドラインインターフェースを実行する際の制限を回避できます。 -このワークショップの作成時にはUbuntu 24.04 LTSを使用したt3.xlargeインスタンスタイプを使用しましたが、より小さなインスタンスタイプも使用できます。 +このワークショップの作成時にはUbuntu 24.04 LTSを使用したt3.xlargeインスタンスタイプを使用しましたが、より小さいインスタンスタイプも使用できます。 -インスタンスが起動したら、sshで接続してください。 +インスタンスが起動したら、sshで接続します。 ## GitHubリポジトリのクローン -GitHubリポジトリをEC2インスタンスにクローンします： +EC2インスタンスにGitHubリポジトリをクローンします。 ``` bash git clone https://github.com/splunk/observability-workshop.git diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/10-cleanup.md similarity index 55% rename from content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/10-cleanup.md index d721078a41..105b9187de 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/10-cleanup.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/10-cleanup.md @@ -7,9 +7,9 @@ time: 5 minutes ## クリーンアップ手順 -ワークショップが完了したら、このセクションの手順に従って OpenShift クラスターをアンインストールします。 +ワークショップが完了したら、このセクションの手順に従ってOpenShiftクラスターをアンインストールします。 -以下のコマンドを実行して、クラスター ID、クラスター固有の Operator ロールの Amazon Resource Names（ARN）、および OIDC プロバイダーのエンドポイント URL を取得します。 +以下のコマンドを実行して、クラスターID、クラスター固有のOperatorロールのAmazon Resource Names（ARN）、およびOIDCプロバイダーのエンドポイントURLを取得します。 ``` bash rosa describe cluster --cluster=$CLUSTER_NAME @@ -21,7 +21,7 @@ rosa describe cluster --cluster=$CLUSTER_NAME rosa delete cluster --cluster=$CLUSTER_NAME --watch ``` -クラスター固有の Operator IAM ロールを削除します。 +クラスター固有のOperator IAMロールを削除します。 > 注意: プロンプトが表示されたら、デフォルト値をそのまま受け入れてください。 @@ -29,7 +29,7 @@ rosa delete cluster --cluster=$CLUSTER_NAME --watch rosa delete operator-roles --prefix $OPERATOR_ROLES_PREFIX ``` -OIDC プロバイダーを削除します。 +OIDCプロバイダーを削除します。 > 注意: プロンプトが表示されたら、デフォルト値をそのまま受け入れてください。 @@ -39,10 +39,10 @@ rosa delete oidc-provider --oidc-config-id $OIDC_ID ネットワークを削除します。 -> 注意: 以下のコマンドを実行する前に、ネットワークの作成に使用した CloudFormation スタックの名前を追加してください。 +> 注意: 以下のコマンドを実行する前に、ネットワークの作成に使用したCloudFormationスタックの名前を追加してください。 ``` bash aws cloudformation delete-stack --region $AWS_REGION --stack-name ``` -AWS アカウントから Red Hat OpenShift Service を完全に削除したい場合は、[OpenShift のドキュメント](https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/4/html/install_clusters/rosa-hcp-deleting-cluster)を参照してください。 +AWSアカウントからRed Hat OpenShift Serviceを完全に削除したい場合は、[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/2-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md new file mode 100644 index 0000000000..6d7024fcb4 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/2-openshift-prereqs.md @@ -0,0 +1,149 @@ +--- +title: OpenShiftの前提条件 +linkTitle: 2. OpenShiftの前提条件 +weight: 2 +time: 15 minutes +--- + +以下の手順は、AWSにOpenShiftクラスターをデプロイする前に必要です。 + +## Red Hatログインの作成 + +最初に、Red Hatのアカウントを作成する必要があります。[こちらのフォーム](https://www.redhat.com/wapps/ugc/register.html?_flowId=register-flow&_flowExecutionKey=e1s1)に記入して作成できます。 + +## 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 +``` + +以下のような出力が返されます: + +```test +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" +``` + +## 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インスタンスに直接ダウンロードできます: + +```bash +curl -L -O https://mirror.openshift.com/pub/cgw/rosa/latest/rosa-linux.tar.gz +``` + +内容を展開します: + +```bash +tar -xvzf rosa-linux.tar.gz +``` + +作成されたファイル（`rosa`）をパスに含まれる場所に移動します。例: + +```bash +sudo mv rosa /usr/local/bin/rosa +``` + +以下のコマンドを実行してRed Hatアカウントにログインし、コマンド出力の指示に従います: + +```bash +rosa login --use-device-code +``` + +## OpenShift CLI（oc）のインストール + +以下のコマンドを使用して、OpenShift CLIバイナリをEC2インスタンスに直接ダウンロードできます: + +```bash +curl -L -O https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz +``` + +内容を展開します: + +```bash +tar -xvzf openshift-client-linux.tar.gz +``` + +作成されたファイル（`oc` と `kubectl`）をパスに含まれる場所に移動します。例: + +```bash +sudo mv oc /usr/local/bin/oc +sudo mv kubectl /usr/local/bin/kubectl +``` + +## アカウント全体のロールとポリシーの作成 + +以下のコマンドを使用して、必要なアカウント全体のロールとポリシーを作成します: + +``` bash +rosa create account-roles --mode auto +``` + +## ROSA HCP用のAWS VPCの作成 + +Hosted Control Plane（HCP）デプロイオプションを使用してOpenShiftクラスターをデプロイします。そのために、以下のコマンドを使用して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リージョンはElastic IPアドレスが5つに制限されています。 +> 次のエラーが表示された場合: +> "The maximum number of addresses has been reached." +> AWSに連絡してこの制限の引き上げをリクエストするか、別のAWSリージョンを選択してROSA用のVPCを作成してください。 + +## OpenID Connect設定の作成 + +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/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md similarity index 58% rename from content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md index e72ee5e705..a4a951307b 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/3-deploy-openshift-cluster.md @@ -9,9 +9,10 @@ time: 25 minutes ROSA CLIを使用してOpenShiftクラスターをデプロイします。 -まず、いくつかの環境変数を設定する必要があります： +まず、いくつかの環境変数を設定する必要があります。 -> 注意: EXPORTコマンドを実行する前に、サブネットIDとOIDC IDを入力してください。 +> [!NOTE] +> EXPORTコマンドを実行する前に、Subnet IDとOIDC IDを必ず入力してください ``` bash export CLUSTER_NAME=rosa-test @@ -22,15 +23,15 @@ export OIDC_ID= 注意: プロンプトが表示されたら、デフォルト値をそのまま使用してください。 +> 注意: プロンプトが表示されたら、デフォルト値をそのまま受け入れてください。 ``` bash rosa create operator-roles --hosted-cp --prefix $OPERATOR_ROLES_PREFIX --oidc-config-id $OIDC_ID ``` -次に、以下のようにしてクラスターを作成できます： +次に、以下のようにクラスターを作成します。 ``` bash rosa create cluster \ @@ -48,15 +49,15 @@ rosa create cluster \ --tags "splunkit_environment_type:non-prd,splunkit_data_classification:private" ``` -> `g5.4xlarge`インスタンスタイプを指定していることに注意してください。これには、このワークショップの後半で使用するNVIDIA GPUが含まれています。このインスタンスタイプは比較的高価で、執筆時点で1時間あたり約$1.64であり、2つのレプリカをリクエストしているため、クラスターの実行時間に注意してください。コストはすぐに蓄積されます。 +> ワークショップの後半で使用するNVIDIA GPUを搭載した `g5.4xlarge` インスタンスタイプを指定しています。このインスタンスタイプは比較的高価で、執筆時点で1時間あたり約$1.64です。2つのレプリカを要求しているため、クラスターの稼働時間に注意してください。コストは急速に蓄積されます。 -クラスターの準備ができたかどうかを確認するには、以下を実行します： +クラスターがReadyになったかどうかを確認するには、次のコマンドを実行します。 ``` bash rosa describe cluster -c $CLUSTER_NAME ``` -クラスターのインストールログを監視するには、以下を実行します： +クラスターのインストールログを監視するには、次のコマンドを実行します。 ``` bash rosa logs install -c $CLUSTER_NAME --watch @@ -64,15 +65,15 @@ rosa logs install -c $CLUSTER_NAME --watch ## OpenShiftクラスターへの接続 -以下のコマンドを使用して、oc CLIをOpenShiftクラスターに接続します： +以下のコマンドを使用して、oc CLIをOpenShiftクラスターに接続します。 -> 注意: `rosa describe cluster -c $CLUSTER_NAME`コマンドを実行し、結果のAPI Server URLを以下のコマンドに代入してから実行してください。例えば、サーバー名は`https://api.rosa-test.aaa.bb.openshiftapps.com:443`のようになります。 +> 注意: `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 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/2-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md similarity index 67% rename from content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md index a654dd5333..17cad63417 100644 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/4-deploy-nvidia-nim.md @@ -1,50 +1,50 @@ --- -title: NVIDIA NIM Operator のデプロイ -linkTitle: 4. NVIDIA NIM Operator のデプロイ +title: NVIDIA NIM Operatorのデプロイ +linkTitle: 4. NVIDIA NIM Operatorのデプロイ weight: 4 time: 20 minutes --- -**NVIDIA GPU Operator** は、Kubernetes クラスター内で GPU をプロビジョニングするために必要なすべての NVIDIA ソフトウェアコンポーネントのデプロイ、設定、管理を自動化する Kubernetes Operator です。 +**NVIDIA GPU Operator** は、Kubernetesクラスター内でGPUをプロビジョニングするために必要なすべてのNVIDIAソフトウェアコンポーネントのデプロイ、設定、管理を自動化するKubernetes Operatorです。 -**NVIDIA NIM Operator** は、このワークショップで先ほど作成した OpenShift クラスターなどの Kubernetes 環境に LLM をデプロイするために使用されます。 +**NVIDIA NIM Operator** は、このワークショップで先ほど作成したOpenShiftクラスターなどのKubernetes環境にLLMをデプロイするために使用されます。 -このワークショップのセクションでは、OpenShift クラスターに NVIDIA GPU Operator と NIM Operator の両方をデプロイするために必要な手順を説明します。 +このセクションでは、OpenShiftクラスターにNVIDIA GPUおよびNIM Operatorの両方をデプロイするために必要な手順を説明します。 -## NVIDIA NGC アカウントの作成 +## NVIDIA NGCアカウントの作成 -LLM をダウンロードして NVIDIA NIM Operator を使用してデプロイするには、NVIDIA GPU CLOUD (NGC) アカウントが必要です。[こちら](https://ngc.nvidia.com/signin)からアカウントを作成できます。 +LLMをダウンロードしてNVIDIA NIM Operatorを使用してデプロイするには、NVIDIA GPU CLOUD（NGC）アカウントが必要です。[こちら](https://ngc.nvidia.com/signin)からアカウントを作成できます。 -## NVIDIA Developer Program への登録 +## NVIDIA Developer Programへの登録 -[NVIDIA Developer Program](https://developer.nvidia.com/) に登録すると、NVIDIA NIM にアクセスできるようになります。これはワークショップの後半で LLM をデプロイする際に使用します。 +[NVIDIA Developer Program](https://developer.nvidia.com/)に登録すると、NVIDIA NIMにアクセスできるようになります。これはワークショップの後半でLLMをデプロイする際に使用します。 -NGC の NVIDIA サブスクリプション一覧に `NVIDIA Developer Program` が表示されていることを確認してください +NGCのNVIDIAサブスクリプション一覧に `NVIDIA Developer Program` が表示されていることを確認してください。 ![NVIDIA Subscriptions](../../images/NVIDIA-Subscriptions.png) -## NGC API キーの生成 +## NGC APIキーの生成 -NGC ウェブサイトにログインしたら、画面右上のユーザーアカウントアイコンをクリックし、**Setup** を選択します。 +NGCのWebサイトにログインしたら、画面右上のユーザーアカウントアイコンをクリックし、 **Setup** を選択します。 -次に **Generate API Key** をクリックし、指示に従ってください。キーが **NGC Catalog** および **Secrets Manager** サービスに関連付けられていることを確認してください。 +次に **Generate API Key** をクリックし、指示に従います。キーが **NGC Catalog** と **Secrets Manager** サービスに関連付けられていることを確認してください。 生成されたキーはワークショップの後半で使用するため、安全な場所に保存してください。 -NGC API キーの生成に関する詳細は、[NVIDIA Documentation](https://docs.nvidia.com/ngc/gpu-cloud/ngc-user-guide/index.html#generating-api-key) を参照してください。 +NGC APIキーの生成に関する詳細は、[NVIDIAドキュメント](https://docs.nvidia.com/ngc/gpu-cloud/ngc-user-guide/index.html#generating-api-key)を参照してください。 -## Node Feature Discovery Operator のインストール +## 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) に基づいています。 +このセクションの手順は、[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 をインストールします +以下のスクリプトを実行してNode Feature Discovery Operatorをインストールします。 ``` bash cd nvidia ./install-nfd-operator.sh ``` -Operator のデプロイが成功したことを確認するには、以下を実行します +Operatorのデプロイが成功したことを確認するには、以下を実行します。 {{< tabs >}} {{% tab title="Script" %}} @@ -64,27 +64,27 @@ nfd-controller-manager-7f86ccfb58-vgr4x 2/2 Running 0 10m {{% /tab %}} {{< /tabs >}} -## NodeFeatureDiscovery CR の作成 +## 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) に基づいています。 +このセクションの手順は、[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 を作成します +以下のスクリプトを実行してNode Feature Discovery CRを作成します。 ``` bash ./create-nfd-cr.sh ``` -## NVIDIA GPU Operator のインストール +## 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) に基づいています。 +このセクションの手順は、[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 をインストールします +以下のスクリプトを実行してNVIDIA GPU Operatorをインストールします。 ``` bash ./install-nvidia-gpu-operator.sh ``` -インストールプランが作成されるまで待ちます +インストールプランが作成されるまで待ちます。 {{< tabs >}} {{% tab title="Script" %}} @@ -104,7 +104,7 @@ install-mmlxq gpu-operator-certified.v25.3.4 Manual false {{% /tab %}} {{< /tabs >}} -以下のコマンドでインストールプランを承認します +以下のコマンドでインストールプランを承認します。 {{< tabs >}} {{% tab title="Script" %}} @@ -124,17 +124,17 @@ installplan.operators.coreos.com/install-rc9xq patched {{% /tab %}} {{< /tabs >}} -## Cluster Policy の作成 +## Cluster Policyの作成 -このセクションの手順は、[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) に基づいています。 +このセクションの手順は、[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のインストール確認 -以下のコマンドを使用して、NVIDIA GPU Operator が正常にインストールされたことを確認します +以下のコマンドを使用して、NVIDIA GPU Operatorが正常にインストールされたことを確認します。 {{< tabs >}} {{% tab title="Script" %}} @@ -184,20 +184,20 @@ daemonset.apps/nvidia-operator-validator 2 2 {{% /tab %}} {{< /tabs >}} -## Operator SDK のインストール +## Operator SDKのインストール -このセクションの手順は、[Install from GitHub release](https://sdk.operatorframework.io/docs/installation/#install-from-github-release) に基づいています。 +このセクションの手順は、[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 @@ -206,13 +206,13 @@ curl -LO ${OPERATOR_SDK_DL_URL}/operator-sdk_${OS}_${ARCH} ### ダウンロードしたバイナリの検証 -keyserver.ubuntu.com から operator-sdk リリースの GPG キーをインポートします +keyserver.ubuntu.comからoperator-sdkリリースのGPGキーをインポートします。 ``` bash gpg --keyserver keyserver.ubuntu.com --recv-keys 052996E2A20B5C7E ``` -チェックサムファイルとその署名をダウンロードし、署名を検証します +チェックサムファイルとその署名をダウンロードし、署名を検証します。 ``` bash curl -LO ${OPERATOR_SDK_DL_URL}/checksums.txt @@ -220,7 +220,7 @@ 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' @@ -229,84 +229,84 @@ 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 にインストール +### リリースバイナリをPATHにインストール ``` bash chmod +x operator-sdk_${OS}_${ARCH} && sudo mv operator-sdk_${OS}_${ARCH} /usr/local/bin/operator-sdk ``` -## NGC CLI のインストール +## NGC CLIのインストール -このセクションの手順は、[NGC CLI Install](https://org.ngc.nvidia.com/setup/installers/cli) に基づいています。 +このセクションの手順は、[NGC CLI Install](https://org.ngc.nvidia.com/setup/installers/cli)に基づいています。 -Download CLI をクリックしてバイナリを含む zip ファイルをダウンロードし、権限のあるディレクトリに zip ファイルを転送してから解凍してバイナリを実行します。また、実行権限のあるディレクトリに移動してから以下のコマンドを実行することで、コマンドラインからダウンロード、解凍、インストールを行うこともできます +Download CLIをクリックしてバイナリを含むzipファイルをダウンロードし、権限のあるディレクトリに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 ハッシュを確認して、ダウンロード中にファイルが破損していないことを確認します +バイナリのmd5ハッシュを確認して、ダウンロード中にファイルが破損していないことを確認します。 ``` bash find ngc-cli/ -type f -exec md5sum {} + | LC_ALL=C sort | md5sum -c ngc-cli.md5 ``` -バイナリの SHA256 ハッシュを確認して、ダウンロード中にファイルが破損していないことを確認します。以下のコマンドを実行してください +バイナリのSHA256ハッシュを確認して、ダウンロード中にファイルが破損していないことを確認します。以下のコマンドを実行します。 ``` bash sha256sum ngccli_linux.zip ``` -以下の値と比較してください。この値はリソースのリリースノートにも記載されています +以下の値と比較します。この値はリソースのRelease Notesにも記載されています。 ``` bash 5f01eff85a66c895002f3c87db2933c462f3b86e461e60d515370f647b4ffc21 ``` -値を検証した後、NGC CLI バイナリを実行可能にし、現在のディレクトリをパスに追加します +値を確認したら、NGC CLIバイナリを実行可能にし、現在のディレクトリをパスに追加します。 ``` bash chmod u+x ngc-cli/ngc echo "export PATH=\"\$PATH:$(pwd)/ngc-cli\"" >> ~/.bash_profile && source ~/.bash_profile ``` -コマンドを実行できるように NGC CLI を設定する必要があります。 +コマンドを実行できるように、NGC CLIを設定する必要があります。 -プロンプトが表示されたら API キーを入力して、以下のコマンドを実行します +プロンプトが表示されたらAPIキーを含めて、以下のコマンドを入力します。 ``` bash ngc config set ``` -NGC API キーを環境変数として定義します +NGC APIキーの環境変数を定義します。 ``` bash export NGC_API_KEY= ``` -## NVIDIA NIM Operator のインストール +## 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) に基づいています。 +このセクションの手順は、[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 をインストールします +以下のスクリプトを実行してNIM Operatorをインストールします。 ``` bash ./install-nim-operator.sh ``` -コントローラー Pod が実行中であることを確認します +コントローラーPodが実行中であることを確認します。 {{< tabs >}} {{% tab title="Script" %}} diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/6-setup-users.md similarity index 67% rename from content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/6-setup-users.md index 68be9b735e..635ed42ded 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/6-setup-users.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/6-setup-users.md @@ -5,9 +5,9 @@ weight: 6 time: 5 minutes --- -このセクションでは、ワークショップの各参加者用にユーザーを作成し、それぞれに Namespace とリソースクォータを割り当てます。 +このセクションでは、ワークショップの各参加者にネームスペースとリソースクォータを割り当てたユーザーを作成します。 -## ユーザーの Namespace とリソースクォータの作成 +## ユーザーネームスペースとリソースクォータの作成 ``` bash cd user-setup @@ -16,30 +16,31 @@ cd user-setup ## ユーザーの作成 -参加者の認証情報を含む HTPasswd ファイルを作成し、ROSA が管理する HTPasswd IdP をカスタムのものに置き換えます。 +参加者の認証情報を含むHTPasswdファイルを作成し、ROSAが管理するHTPasswd IdPをカスタムのものに置き換えます。 ``` bash ./create-users.sh ``` -## cluster-admin ユーザーの再作成と再ログイン +## cluster-adminユーザーの再作成と再ログイン -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" @@ -47,27 +48,27 @@ clusterrole.rbac.authorization.k8s.io/admin added: "participant1" ## ログインのテスト -### OpenShift CLI のインストール +### OpenShift CLIのインストール -ローカルマシンからログインをテストするには、OpenShift CLI をインストールする必要があります。 +ローカルマシンからログインをテストするには、OpenShift CLIをインストールする必要があります。 -MacOS の場合、Homebrew パッケージマネージャーを使用して 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)を参照してください。 +その他のインストールオプションについては、[OpenShiftドキュメント](https://docs.redhat.com/en/documentation/openshift_container_platform/4.8/html/cli_tools/openshift-cli-oc)を参照してください。 ### ワークショップユーザーとしてログイン -ローカルマシンからワークショップユーザーの1人としてログインしてみます。 +ローカルマシンからワークショップユーザーの1人としてログインを試みます。 ``` bash oc login https://api.:443 -u participant1 -p 'TempPass123!' ``` -以下のように表示されるはずです。 +以下のように表示されます。 ```` Login successful. @@ -75,11 +76,11 @@ Login successful. You have one project on this server: "workshop-participant-1" ```` -### LLM へのアクセスの確認 +### LLMへのアクセス確認 -ワークショップユーザーアカウントから LLM にアクセスできることを確認します。 +ワークショップユーザーアカウントからLLMにアクセスできることを確認します。 -curl コマンドを使用できる Pod を起動します。 +curlコマンドにアクセスできるPodを起動します。 ``` bash oc run curl --rm -it --image=curlimages/curl:latest \ @@ -106,7 +107,7 @@ oc run curl --rm -it --image=curlimages/curl:latest \ }' ``` -次に、以下のコマンドを実行して LLM にプロンプトを送信します。 +次に、以下のコマンドを実行してLLMにプロンプトを送信します。 {{< tabs >}} {{% tab title="スクリプト" %}} diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md similarity index 59% rename from content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md index 58ae7fa1ae..9cba4b73c1 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/7-install-otel-collector.md @@ -1,36 +1,35 @@ --- -title: OpenTelemetry Collector のインストール -linkTitle: 7. OpenTelemetry Collector のインストール +title: OpenTelemetry Collectorのインストール +linkTitle: 7. OpenTelemetry Collectorのインストール weight: 7 time: 5 minutes --- -このセクションでは、clusterReceiver のみを有効にした OpenTelemetry Collector をインストールします（ワークショップ参加者は自分の Namespace に独自のエージェントをインストールします）。 -次に、この Collector のインストールによって作成された ClusterRole を、各ワークショップ参加者の Namespace にバインドします。 +このセクションでは、clusterReceiverのみを有効にしたOpenTelemetry Collectorをインストールします（ワークショップ参加者は各自のnamespaceに自分のエージェントをインストールするため）。次に、このCollectorインストールで作成されたClusterRoleを各ワークショップ参加者のnamespaceにバインドします。 -## OpenTelemetry Collector のインストール +## OpenTelemetry Collectorのインストール -まず、Collector 用の新しいプロジェクトを作成し、そのプロジェクトに切り替えます。 +まず、Collector用の新しいプロジェクトを作成し、そのプロジェクトに切り替えます。 ```bash oc new-project admin-otel ``` -Splunk OpenTelemetry Collector for Kubernetes の Helm チャートリポジトリを追加します。 +Splunk OpenTelemetry Collector for KubernetesのHelmチャートリポジトリを追加します。 ```bash helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart ```` -リポジトリが最新であることを確認します。 +リポジトリを最新の状態に更新します。 ```bash helm repo update ```` -`./admin-otel-collector/admin-otel-collector-values.yaml` ファイルを確認します。このファイルを使用して OpenTelemetry Collector をインストールします。 +`./admin-otel-collector/admin-otel-collector-values.yaml` ファイルを確認します。このファイルをOpenTelemetry Collectorのインストールに使用します。 -Collector のデータ送信先となる Splunk 環境を設定するための環境変数を設定します。 +Collectorがデータを送信するSplunk環境を設定するための環境変数を設定します。 ``` bash export CLUSTER_NAME=ai-pod-workshop-admin @@ -42,7 +41,7 @@ export SPLUNK_HEC_TOKEN= export SPLUNK_INDEX=splunk4rookies-workshop ``` -次に、以下のコマンドを使用して Collector をインストールします。 +次のコマンドを使用してCollectorをインストールします。 ```bash helm install splunk-otel-collector \ @@ -58,7 +57,7 @@ helm install splunk-otel-collector \ splunk-otel-collector-chart/splunk-otel-collector ``` -以下のコマンドを実行して、すべての Collector Pod が実行中であることを確認します。 +次のコマンドを実行して、すべてのCollector Podが実行中であることを確認します。 ```` oc get pods -n admin-otel @@ -67,7 +66,7 @@ NAME READY STATUS splunk-otel-collector-k8s-cluster-receiver-7b7f5cdc5b-rhxsj 1/1 Running 0 6m40s ```` -## 各ワークショップ参加者のサービスアカウント作成と ClusterRole へのバインド +## 各ワークショップ参加者のService Accountを作成しCluster Roleにバインド ``` bash for i in {1..30}; do @@ -93,7 +92,7 @@ EOF done ``` -また、各 Namespace の ServiceAccount に SecurityContextConstraint（SCC）を付与する必要があります。 +各namespaceのServiceAccountにSecurityContextConstraint（SCC）を付与する必要もあります。 ``` bash for i in {1..30}; do diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md new file mode 100644 index 0000000000..b55aed7df0 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/8-deploy-vector-db.md @@ -0,0 +1,79 @@ +--- +title: ベクトルデータベースのデプロイ +linkTitle: 8. ベクトルデータベースのデプロイ +weight: 8 +time: 10 minutes +--- + +このステップでは、OpenShiftクラスターにベクトルデータベースをデプロイし、ワークショップ参加者が使用するテストデータを投入します。 + +## ベクトルデータベースのデプロイ + +このワークショップでは、オープンソースのベクトルデータベースである[Weaviate](https://weaviate.io/)をデプロイします。 + +まず、Weaviate Helmチャートを含むWeaviate Helmリポジトリを追加します。 + +``` bash +helm repo add weaviate https://weaviate.github.io/weaviate-helm +helm repo update +``` + +`weaviate/weaviate-values.yaml` ファイルには、Weaviateベクトルデータベースのデプロイに使用する設定が含まれています。 + +WeaviateがPrometheus Receiverで後からスクレイプできるメトリクスを公開するように、以下の環境変数を `TRUE` に設定しています。 + +```` + PROMETHEUS_MONITORING_ENABLED: true + PROMETHEUS_MONITORING_GROUP: true +```` + +利用可能な追加のカスタマイズオプションについては、[Weaviateドキュメント](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 +``` + +## ベクトルデータベースへのデータ投入 + +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` の設定に従い、[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/2-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md new file mode 100644 index 0000000000..80fdb75b4c --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/9-deploy-portworx-service.md @@ -0,0 +1,50 @@ +--- +title: Portworx Metrics Endpointのデプロイ +linkTitle: 9. Portworx Metrics Endpoint +weight: 9 +time: 10 minutes +--- + +このステップでは、Portworx Metrics Endpointを模倣するPythonサービスをデプロイします。 +これはワークショップでPure Storageのモニタリングを設定するために使用されます。 + +## Portworx Metrics Endpointのデプロイ + +以下のコマンドを実行して、Portworx Metrics Endpointサービスをデプロイします。 + +``` bash +oc new-project portworx +oc apply -f ./portworx/k8s.yaml -n portworx +``` + +## Portworx Metrics Endpointのテスト + +Portworx Metrics Endpointが期待通りに動作していることを確認します。 + +curlコマンドにアクセスできるPodを起動します。 + +``` bash +oc run --rm -it -n default curl --image=curlimages/curl:latest -- sh +``` + +次に、以下のコマンドを実行してエンドポイントにプロンプトを送信します。 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +``` bash +curl http://portworx-metrics-sim.portworx:17001/metrics +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` 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/2-cisco-ai-pods/1-workshop-setup/_index.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/_index.md new file mode 100644 index 0000000000..d3159fd118 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/1-workshop-setup/_index.md @@ -0,0 +1,17 @@ +--- +title: ワークショップのセットアップ +linkTitle: 1. ワークショップのセットアップ +weight: 1 +--- + +このセクションでは、ワークショップの主催者がワークショップをセットアップするために実施する手順を説明します。 + +* AWSアカウントのセットアップ +* OpenShiftの前提条件 +* AWS ROSAを使用して、GPUベースのワーカーノードを持つ **RedHat OpenShift** クラスターをデプロイします +* **NVIDIA NIM Operator** と **NVIDIA GPU Operator** をデプロイします +* NVIDIA NIMを使用して **Large Language Model（LLM）** をクラスターにデプロイします +* ワークショップの各ユーザーに対して、適切な権限を持つOpenShiftログインとNamespaceを作成します +* **Splunk OpenTelemetry collector** のCluster Receiverコンポーネントをインストールします +* **Weviate vector database** をクラスターにデプロイします +* **Portworx Prometheus exporter** を模倣するサービスをデプロイします diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md new file mode 100644 index 0000000000..e8f79c2724 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/1-overview-of-workshop-environment.md @@ -0,0 +1,46 @@ +--- +title: ワークショップ環境の概要 +linkTitle: 1. ワークショップ環境の概要 +weight: 1 +time: 5 minutes +--- + +**Cisco AI-ready PODs** は最先端のハードウェアとソフトウェアを組み合わせ、堅牢でスケーラブルかつ効率的なAIインフラストラクチャを提供します。 +**Splunk Observability Cloud** は、インフラストラクチャからアプリケーションコンポーネントまで、このスタック全体の包括的な可視性を提供します。 + +このハンズオンワークショップでは、OpenTelemetryとPrometheusを使用してAIインフラストラクチャをモニタリングする方法を学びます。**実際のCisco AI PODへのアクセスは不要です**。現実的な環境でモニタリング技術のデプロイと設定の実践的な経験を得ることができます。 + +## ラボ環境 + +このワークショップでは、NVIDIA GPUとNVIDIA AI Enterpriseソフトウェアを備えた、AWSで稼働する共有 **OpenShift Cluster** を使用します。 + +### デプロイ済みインフラストラクチャ + +ワークショップのインストラクターが、以下の共有コンポーネントをワークショップ環境にデプロイしています。 + +* **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モデルを活用する **Pythonアプリケーション** をデプロイする +4. Splunk Observability Cloudを使用してアプリケーションパフォーマンスとインフラストラクチャメトリクスをモニタリングする + +## Prometheusとは + +**Prometheus** は通常、ストレージとアラートに使用されるフルスタックモニタリングシステムを指しますが、このワークショップではPrometheusエコシステムのデータ標準に焦点を当てます。 + +このワークショップでは **Prometheus Exporters** を活用します。これは、コンポーネントの内部ヘルス情報を標準化されたメトリクスエンドポイント（例: ）に変換する小さなユーティリティです。 + +このデータを収集するためにフルのPrometheusサーバーを使用する代わりに、**OpenTelemetry Collector** を使用します。その **Prometheus receiver** を使用することで、Collectorはこれらのエンドポイントを **scrape** でき、広くサポートされている業界標準フォーマットを使用してリッチなテレメトリデータを収集できます。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/10-deploy-llm-app.md similarity index 67% rename from content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/10-deploy-llm-app.md index 4a2df8230a..ddef395668 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/10-deploy-llm-app.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/10-deploy-llm-app.md @@ -1,31 +1,33 @@ --- -title: LLM アプリケーションのデプロイ -linkTitle: 10. LLM アプリケーションのデプロイ +title: LLMアプリケーションのデプロイ +linkTitle: 10. LLMアプリケーションのデプロイ weight: 10 time: 10 minutes --- -## LLM アプリケーションのデプロイ +## LLMアプリケーションのデプロイ -以下のコマンドを使用して、このアプリケーションを OpenShift クラスターにデプロイします: +以下のコマンドを使用して、このアプリケーションをOpenShiftクラスターにデプロイします。 ``` bash cd ~/workshop/cisco-ai-pods oc apply -f ./llm-app/k8s-manifest.yaml ``` -> 注意: この Python アプリケーションの Docker イメージをビルドするために、以下のコマンドを実行しました: +> [!NOTE] +> この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 アプリケーションのテスト +## LLMアプリケーションのテスト -アプリケーションが期待どおりに動作していることを確認しましょう。 +アプリケーションが期待通りに動作していることを確認しましょう。 -curl コマンドにアクセスできる Pod を起動します: +curlコマンドにアクセスできるPodを起動します。 ``` bash oc run curl --rm -it --image=curlimages/curl:latest \ @@ -52,7 +54,7 @@ oc run curl --rm -it --image=curlimages/curl:latest \ }' ``` -次に、以下のコマンドを実行して LLM に質問を送信します: +次に、以下のコマンドを実行してLLMに質問を送信します。 {{< tabs >}} {{% tab title="スクリプト" %}} diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/11-review-traces.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/11-review-traces.md new file mode 100644 index 0000000000..0771a8a017 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/11-review-traces.md @@ -0,0 +1,39 @@ +--- +title: Metrics、Traces、Logsの確認 +linkTitle: 11. Metrics、Traces、Logsの確認 +weight: 11 +time: 10 minutes +--- + +## Splunk Observability CloudでTraceデータを表示する + +Splunk Observability Cloudで `APM` に移動し、`Service Map` を選択します。 +環境名が選択されていることを確認します（例: `ai-pod-workshop-participant-1`）。 +以下のようなサービスマップが表示されます。 + +![Service Map](../../images/ServiceMap.png) + +右側のメニューで `Traces` をクリックします。次に、実行時間が長いTraceの1つを選択します。以下の例のように表示されます。 + +![Trace](../../images/Trace.png) + +Traceには、ユーザーの質問（例:「NVIDIA H200のメモリはどのくらいですか？」）に対する回答を返すためにアプリケーションが実行したすべてのインタラクションが表示されます。 + +例えば、Weaviateベクトルデータベースで質問に関連するドキュメントを検索するために、アプリケーションが類似性検索を実行した箇所を確認できます。 + +また、ベクトルデータベースから取得したコンテキストを含め、アプリケーションがLLMに送信するプロンプトをどのように作成したかも確認できます。 + +![Prompt Template](../../images/PromptTemplate.png) + +> 注意: Traceのウォーターフォールビューに `chat` と `invoke_workflow` のAIインタラクションが表示されない場合、または右側に `AI details` タブが表示されない場合は、有効にする必要があるスーパーパワーについてインストラクターに確認してください。 + +最後に、LLMからのレスポンス、所要時間、使用された入力トークン数と出力トークン数を確認できます。 + +![LLM Response](../../images/LLMResponse.png) + +## MetricsがSplunkに送信されていることを確認する + +Splunk Observability Cloudで `Dashboards` に移動し、`Built-in dashboard groups` に含まれている `Cisco AI PODs Dashboard` を検索します。 +`NIM FOR LLMS` タブに移動し、ダッシュボードがOpenShiftクラスター名でフィルタリングされていることを確認します。以下の例のようにチャートにデータが表示されます。 + +![NIM LLMS Dashboard](../../images/NIMLLM.png) diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/12-wrapup.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/12-wrapup.md new file mode 100644 index 0000000000..bd43ae5692 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/12-wrapup.md @@ -0,0 +1,20 @@ +--- +title: まとめ +linkTitle: 12. まとめ +weight: 12 +time: 5 minutes +--- + +## まとめ + +このワークショップを楽しんでいただけたことを願っています。このワークショップでは、Splunk Observability Cloudを使用してCisco AI PODsを監視するために使用されるいくつかの技術をデプロイし、操作するハンズオン体験を提供しました。具体的には、以下の内容を体験しました。 + +* GPUベースのワーカーノードを持つRedHat OpenShiftクラスターの操作 +* NVIDIA NIM OperatorとNVIDIA GPU Operatorの操作 +* NVIDIA NIMを使用してクラスターにデプロイされたLarge Language Models（LLMs）の操作 +* Red Hat OpenShiftクラスターへのOpenTelemetry Collectorのデプロイ +* インフラストラクチャメトリクスを取り込むためのPrometheus Receiverの追加 +* クラスター内のWeaviateベクターデータベースのモニタリング +* Prometheusを使用したPure Storageメトリクスのモニタリング設定 +* Large Language Models（LLMs）と連携するPythonサービスへのOpenTelemetryによる計装 +* LLMsと連携するアプリケーションのトレースでOpenTelemetryがキャプチャする詳細の理解 diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/2-connect-to-openshift-cluster.md new file mode 100644 index 0000000000..2f04ce0633 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-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アドレス +* 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`）をパスに含まれる場所に移動します。例えば以下のようにします。 + +``` bash +sudo mv oc /usr/local/bin/oc +sudo mv kubectl /usr/local/bin/kubectl +``` + +## OpenShiftクラスターへの接続 + +Kube設定ファイルがsplunkユーザーによって変更可能であることを確認します。 + +``` 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="スクリプト" %}} + +``` bash +oc whoami --show-server +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` 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/2-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md similarity index 65% rename from content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md index 6bedce5e76..8b17b7495d 100644 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/3-deploy-otel-collector.md @@ -1,17 +1,17 @@ --- -title: OpenTelemetry Collector のデプロイ -linkTitle: 3. OpenTelemetry Collector のデプロイ +title: OpenTelemetry Collectorのデプロイ +linkTitle: 3. OpenTelemetry Collectorのデプロイ weight: 3 time: 10 minutes --- -このセクションでは、OpenShift ネームスペースに OpenTelemetry Collector をデプロイします。これにより、クラスター内で実行されているインフラストラクチャやアプリケーションからメトリクス、ログ、トレースを収集し、Splunk Observability Cloud にデータを送信します。 +このセクションでは、OpenShift名前空間にOpenTelemetry Collectorをデプロイします。Collectorはクラスター内で実行されているインフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、Splunk Observability Cloudにデータを送信します。 -## OpenTelemetry Collector のデプロイ +## OpenTelemetry Collectorのデプロイ -### Helm がインストールされていることを確認する +### Helmがインストールされていることを確認 -以下のコマンドを実行して、Helm がインストールされていることを確認します +以下のコマンドを実行して、Helmがインストールされていることを確認します。 {{< tabs >}} {{% tab title="Script" %}} @@ -30,7 +30,7 @@ version.BuildInfo{Version:"v3.19.4", GitCommit:"7cfb6e486dac026202556836bb910c37 {{% /tab %}} {{< /tabs >}} -インストールされていない場合は、以下のコマンドを実行します +インストールされていない場合は、以下のコマンドを実行します。 ``` bash sudo apt-get install curl gpg apt-transport-https --yes @@ -40,15 +40,15 @@ sudo apt-get update sudo apt-get install helm ``` -### Splunk OpenTelemetry Collector Helm Chart の追加 +### Splunk OpenTelemetry Collector Helm Chartの追加 -Splunk OpenTelemetry Collector for Kubernetes の Helm チャートリポジトリを追加します +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 @@ -56,7 +56,7 @@ helm repo update ### 環境変数の設定 -Collector がデータを送信する Splunk 環境を設定するための環境変数を設定します +Collectorがデータを送信するSplunk環境を設定するための環境変数を設定します。 ``` bash export USER_NAME=workshop-participant-$PARTICIPANT_NUMBER @@ -65,7 +65,7 @@ export ENVIRONMENT_NAME=ai-pod-$USER_NAME export SPLUNK_INDEX=splunk4rookies-workshop ``` -環境名が設定されていることを確認します +環境名が設定されていることを確認します。 {{< tabs >}} {{% tab title="Script" %}} @@ -84,15 +84,15 @@ ai-pod-workshop-participant-1 {{% /tab %}} {{< /tabs >}} -### Collector のデプロイ +### Collectorのデプロイ -ワークショップディレクトリに移動します +ワークショップディレクトリに移動します。 ``` bash cd ~/workshop/cisco-ai-pods ``` -次に、以下のコマンドを使用して、ネームスペースに Collector をインストールします +次に、以下のコマンドを使用して名前空間にCollectorをインストールします。 ```bash { [ -z "$CLUSTER_NAME" ] || \ @@ -112,7 +112,7 @@ cd ~/workshop/cisco-ai-pods splunk-otel-collector-chart/splunk-otel-collector ``` -> 注意: `Missing variables` というエラーが表示された場合は、環境変数を再度定義する必要があります。以下のコマンドを実行する前に、参加者番号を設定してください +> 注意: `Missing variables` というエラーが表示された場合は、環境変数を再度定義する必要があります。以下のコマンドを実行する前に、参加者番号を追加してください。 > > ``` bash > export PARTICIPANT_NUMBER= @@ -122,7 +122,7 @@ cd ~/workshop/cisco-ai-pods > export SPLUNK_INDEX=splunk4rookies-workshop > ``` -以下のコマンドを実行して、Collector の Pod が実行中であることを確認します +以下のコマンドを実行して、Collector Podが実行中であることを確認します。 ```` watch -n 1 oc get pods @@ -132,10 +132,10 @@ splunk-otel-collector-agent-58rwm 1/1 Running splunk-otel-collector-agent-8dndr 1/1 Running 0 6m40s ```` -> 注意: OpenShift 環境では、Collector が起動して `Running` 状態に遷移するまで約3分かかります。 +> 注意: OpenShift環境では、Collectorが起動して `Running` 状態に遷移するまでに約3分かかります。 -### Splunk Observability Cloud で Collector データを確認する +### Splunk Observability CloudでCollectorデータを確認 -**Splunk Observability Cloud** でクラスターが表示されることを確認します。**Infrastructure Monitoring** -> **Kubernetes** -> **Kubernetes Clusters** に移動し、`k8s.cluster.name` でクラスター名（例: `ai-pod-workshop-participant-1`）のフィルターを追加します +**Splunk Observability Cloud** でクラスターが表示されることを確認します。**Infrastructure Monitoring** -> **Kubernetes** -> **Kubernetes Clusters** に移動し、`k8s.cluster.name` でクラスター名（例: `ai-pod-workshop-participant-1`）のフィルターを追加します。 ![Kubernetes Pods](../../images/KubernetesPods.png) 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/2-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md similarity index 60% rename from content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md index a0594dc446..512e6b909f 100644 --- a/content/ja/ninja-workshops/infrastructure/14-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/4-monitor-nvidia-components.md @@ -1,23 +1,23 @@ --- -title: NVIDIA コンポーネントの監視 -linkTitle: 4. NVIDIA コンポーネントの監視 +title: NVIDIAコンポーネントのモニタリング +linkTitle: 4. NVIDIAコンポーネントのモニタリング weight: 4 time: 10 minutes --- -このセクションでは、OpenTelemetry Collector で Prometheus **receiver** を使用して、OpenShift クラスターで実行されている NVIDIA コンポーネントを監視します。まず、Collector の設定ファイルが保存されているディレクトリに移動します +このセクションでは、OpenTelemetry CollectorでPrometheus **receiver** を使用して、OpenShiftクラスターで実行されているNVIDIAコンポーネントをモニタリングします。まず、Collectorの設定ファイルが格納されているディレクトリに移動します。 ``` bash cd otel-collector ``` -## NVIDIA DCGM Exporter メトリクスの取得 +## NVIDIA DCGM Exporterメトリクスの取得 -[NVIDIA DCGM exporter](https://github.com/NVIDIA/dcgm-exporter) が OpenShift クラスターで実行されています。これは Splunk に送信できる GPU メトリクスを公開しています。 +[NVIDIA DCGM exporter](https://github.com/NVIDIA/dcgm-exporter)がOpenShiftクラスターで実行されています。これはSplunkに送信できるGPUメトリクスを公開しています。 -これを行うために、Collector のデプロイ時に使用した `otel-collector-values.yaml` ファイルを編集して、Collector の設定をカスタマイズしましょう。 +これを行うために、Collectorのデプロイ時に使用した `otel-collector-values.yaml` ファイルを編集して、Collectorの設定をカスタマイズします。 -以下の内容を `kubeletstats` **receiver** のすぐ下に追加します +以下の内容を `kubeletstats` **receiver** のすぐ下に追加します。 ``` yaml receiver_creator/nvidia: @@ -36,17 +36,17 @@ cd otel-collector rule: type == "pod" && labels["app"] == "nvidia-dcgm-exporter" ``` -これにより、Collector は `app=nvidia-dcgm-exporter` というラベルを持つ Pod を検索します。このラベルを持つ Pod が見つかると、その Pod のポート 9400 に接続し、デフォルトのメトリクスエンドポイント（`/v1/metrics`）をスクレイプします。 +これにより、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** receiver は、ランタイム情報に基づいてレシーバー（Prometheus receiver を含む）を動的に作成でき、スケーラブルで柔軟なスクレイピング設定を可能にします。 -> * **receiver_creator** を使用することで、動的な環境において複数の Prometheus スクレイピングターゲットの管理を自動化し、設定を簡素化できます。 +> * **Prometheus** receiver は、事前定義されたエンドポイントからメトリクスをスクレイプする静的な設定を使用します。 +> * **receiver_creator** receiver は、ランタイム情報に基づいてReceiver（Prometheus Receiverを含む）を動的に作成でき、スケーラブルで柔軟なスクレイプ設定を可能にします。 +> * **receiver_creator** を使用すると、動的な環境で複数のPrometheusスクレイプターゲットの管理を自動化し、設定を簡素化できます。 -この新しい **receiver** が使用されるようにするために、`otel-collector-values.yaml` ファイルに新しい **pipeline** を追加する必要があります。 +この新しい **receiver** が使用されるようにするため、`otel-collector-values.yaml` ファイルに新しい **pipeline** を追加する必要があります。 -ファイルの末尾に以下のコードを追加します +ファイルの末尾に以下のコードを追加します。 ``` yaml service: @@ -63,11 +63,11 @@ cd otel-collector - receiver_creator/nvidia ``` -次のセクションで、NVIDIA に関連するもう1つの Prometheus **receiver** を追加します。 +次のセクションで、NVIDIAに関連するもう1つのPrometheus **receiver** を追加します。 -## NVIDIA NIM メトリクスの取得 +## NVIDIA NIMメトリクスの取得 -`meta-llama-3-2-1b-instruct` 大規模言語モデルは、NVIDIA NIM を使用して OpenShift クラスターにデプロイされました。これには、Collector でスクレイプできる Prometheus エンドポイントが含まれています。以下の内容を、先ほど追加した `prometheus/dcgm` **receiver** のすぐ下にある `otel-collector-values.yaml` ファイルに追加しましょう +`meta-llama-3-2-1b-instruct` 大規模言語モデルは、NVIDIA NIMを使用してOpenShiftクラスターにデプロイされています。これにはCollectorでスクレイプできるPrometheusエンドポイントが含まれています。以下を `otel-collector-values.yaml` ファイルの、先ほど追加した `prometheus/dcgm` **receiver** のすぐ下に追加します。 ``` yaml prometheus/nim-llm: @@ -83,17 +83,17 @@ cd otel-collector 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` メトリクスエンドポイントをスクレイプします。 +これにより、Collectorは `app=meta-llama-3-2-1b-instruct` というラベルを持つPodを探します。このラベルを持つPodを見つけると、そのPodのポート8000に接続し、`/v1/metrics` メトリクスエンドポイントをスクレイプします。 -この **receiver** は `receiver_creator/nvidia` receiver の一部として自動的に検出されるため、**pipeline** を変更する必要はありません。 +この **receiver** は `receiver_creator/nvidia` Receiverの一部として既に取得されるため、**pipeline** を変更する必要はありません。 -## Filter Processor の追加 +## Filter Processorの追加 -Prometheus エンドポイントのスクレイピングにより、カーディナリティの高い大量のメトリクスが生成されることがあります。 +Prometheusエンドポイントのスクレイプにより、大量のメトリクスが生成されることがあり、カーディナリティが高くなる場合があります。 -Splunk に送信するメトリクスを正確に定義するフィルター **processor** を追加しましょう。具体的には、ダッシュボードチャートまたはアラートディテクターで使用されるメトリクス**のみ**を送信します。 +Splunkに送信するメトリクスを正確に定義するフィルター **processor** を追加します。具体的には、ダッシュボードのチャートまたはアラートディテクターで使用されるメトリクス **のみ** を送信します。 -以下のコードを `otel-collector-values.yaml` ファイルの **exporters** セクションの後、**receivers** セクションの前に追加します +以下のコードを `otel-collector-values.yaml` ファイルの **exporters** セクションの後、**receivers** セクションの前に追加します。 ``` yaml processors: @@ -174,7 +174,7 @@ Splunk に送信するメトリクスを正確に定義するフィルター **p - request_generation_tokens ``` -先ほど追加した `metrics/nvidia-metrics` **pipeline** に `filter/metrics_to_be_included` **processor** が含まれていることを確認します +先ほど追加した `metrics/nvidia-metrics` **pipeline** に `filter/metrics_to_be_included` **processor** が含まれていることを確認します。 ``` bash service: @@ -194,16 +194,16 @@ Splunk に送信するメトリクスを正確に定義するフィルター **p ## 変更の確認 -変更した `otel-collector-values.yaml` ファイルの内容を `otel-collector-values-with-nvidia.yaml` ファイルと比較してみましょう。`yaml` ファイルではインデントが重要であり、正確である必要があることを忘れないでください +変更した `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" %}} +{{% notice title="まだCollectorを再起動しないでください" style="warning" %}} -OpenShift 環境では Collector の再起動にノードあたり3分かかるため、すべての設定変更が完了するまで再起動を待ちます。 +OpenShift環境ではCollectorの再起動にノードあたり3分かかるため、すべての設定変更が完了するまで再起動を待ちます。 {{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/5-monitor-vector-db.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/5-monitor-vector-db.md new file mode 100644 index 0000000000..92894caba6 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/5-monitor-vector-db.md @@ -0,0 +1,117 @@ +--- +title: ベクトルデータベースのモニタリング +linkTitle: 5. ベクトルデータベースのモニタリング +weight: 5 +time: 5 minutes +--- + +このステップでは、Weaviateベクトルデータベースをモニタリングするために Prometheus Receiver を設定します。 + +## ベクトルデータベースとは + +**ベクトルデータベース** は、テキストや画像などの情報の **意味的な意味** を捉える数値的な「ベクトル埋め込み」としてデータを保存し、インデックスを作成します。従来のデータベースとは異なり、完全一致ではなく概念的に関連するデータポイントを見つける **類似性検索** に優れています。 + +## ベクトルデータベースの使われ方 + +ベクトルデータベースは、大規模言語モデル（LLM）を活用するアプリケーションで広く使用されている **Retrieval Augmented Generation（RAG）** と呼ばれるパターンで重要な役割を果たします。 + +パターンは以下のとおりです。 + +* エンドユーザーがアプリケーションに質問をする +* アプリケーションが質問を受け取り、ベクトル埋め込みを計算する +* アプリがベクトルデータベース内の関連ドキュメントを類似性検索で探す +* アプリが元の質問と関連ドキュメントをコンテキストとしてLLMに送信する +* LLMがコンテキストを確認し、アプリケーションにレスポンスを返す + +## PrometheusでWeaviateメトリクスを取得する + +OpenTelemetry Collectorの設定を変更して、WeaviateのPrometheusメトリクスをスクレイプします。 + +`otel-collector-values.yaml` ファイルに追加のPrometheus **Receiver** クリエーターセクションを追加します。`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` フィルター Processor の設定にも追加する必要があります。 + +``` 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` という新しいプロパティにコピーします。これは、Splunk Observability Cloudで使用される標準的なOpenTelemetryプロパティである `service.instance.id` を使用する他のメトリクスと、Weaviateメトリクスをより簡単に区別するために行います。 + +Weaviateメトリクス用の新しいメトリクス **pipeline** も追加する必要があります（Weaviate以外のメトリクスに `weaviate.instance.id` が追加されないように、別の **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="まだCollectorを再起動しないでください" style="warning" %}} + +OpenShift環境ではCollectorの再起動にノードごとに3分かかるため、すべての設定変更が完了するまで再起動を待ちます。 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/6-monitor-storage.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/6-monitor-storage.md similarity index 50% rename from content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/6-monitor-storage.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/6-monitor-storage.md index af566db754..f0a92a24d0 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/6-monitor-storage.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/6-monitor-storage.md @@ -1,29 +1,29 @@ --- title: ストレージのモニタリング -linkTitle: 6. ストレージのモニタリング +linkTitle: 6. Monitor Storage weight: 6 time: 5 minutes --- -このステップでは、ストレージをモニタリングするために Prometheus receiverを設定します。 +このステップでは、ストレージをモニタリングするためにPrometheus Receiverを設定します。 -## Cisco AI PODs はどのようなストレージを使用しているか？ +## Cisco AI PODsはどのようなストレージを利用しているか -Cisco AI PODs には、Pure Storage、VAST、NetApp など、さまざまなストレージオプションがあります。 +Cisco AI PODsには、Pure Storage、VAST、NetAppなど、さまざまなストレージオプションがあります。 -このワークショップでは Pure Storage に焦点を当てます。 +このワークショップではPure Storageに焦点を当てます。 -## Pure Storage メトリクスをどのように取得するか？ +## Pure Storageのメトリクスをどのように取得するか -Pure Storage を使用する Cisco AI PODs は、Kubernetes に永続ストレージを提供する Portworx というテクノロジーも使用しています。 +Pure Storageを利用するCisco AI PODsは、Kubernetesの永続ストレージを提供するPortworxというテクノロジーも使用しています。 -Portworx には Prometheus receiverでスクレイプできるメトリクスエンドポイントがあります。 +Portworxには、Prometheus Receiverを使用してスクレイピングできるメトリクスエンドポイントが含まれています。 -## Prometheus でストレージメトリクスを取得する +## Prometheusでストレージメトリクスを取得する -OpenTelemetry Collector の設定を変更して、Prometheus **receiver**で Portworx メトリクスをスクレイプしましょう。 +OpenTelemetry Collectorの設定を変更して、Prometheusの **Receiver** でPortworxメトリクスをスクレイピングします。 -`otel-collector-values.yaml` ファイルに追加の Prometheus **receiver creator**セクションを追加します。`receiver_creator/weaviate` セクションの後、`pipelines` セクションの前に追加してください： +追加のPrometheus **receiver creator** セクションを `otel-collector-values.yaml` ファイルに追加します。`receiver_creator/weaviate` セクションの後、`pipelines` セクションの前に追加してください。 ``` yaml receiver_creator/storage: @@ -42,7 +42,7 @@ OpenTelemetry Collector の設定を変更して、Prometheus **receiver**で Po rule: type == "pod" && labels["app"] == "portworx-metrics-sim" ``` -Portworx メトリクスが `filter/metrics_to_be_included` filter processorの設定にも追加されていることを確認する必要があります： +Portworxメトリクスを `filter/metrics_to_be_included` フィルターのProcessor設定にも追加する必要があります。 ``` yaml processors: @@ -67,9 +67,9 @@ Portworx メトリクスが `filter/metrics_to_be_included` filter processorの - px_volume_writethroughput ``` -> 注意: `px_cluster_cpu_percent` から始まる新しいメトリクスのみを追加してください。 +> 注意: `px_cluster_cpu_percent` から始まる新しいメトリクスのみを追加します -Portworx メトリクス用の新しいメトリクス**パイプライン**も追加する必要があります。以下をファイルの末尾に追加してください： +Portworxメトリクス用の新しいメトリクス **pipeline** も追加する必要があります。ファイルの末尾に以下を追加します。 ``` yaml metrics/storage: @@ -85,16 +85,16 @@ Portworx メトリクス用の新しいメトリクス**パイプライン**も - receiver_creator/storage ``` -変更した `otel-collector-values.yaml` ファイルの内容を `otel-collector-values-with-portworx.yaml` ファイルと比較してください。`yaml` ファイルではインデントが重要であり、正確である必要があることを忘れないでください： +変更した `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" %}} +{{% notice title="まだCollectorを再起動しないでください" style="warning" %}} -OpenShift 環境では Collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動は待ちます。 +OpenShift環境ではCollectorの再起動にノードあたり3分かかるため、すべての設定変更が完了するまで再起動を待ちます。 {{% /notice %}} diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md new file mode 100644 index 0000000000..f1fb90353e --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/7-review-ai-pod-dashboards.md @@ -0,0 +1,60 @@ +--- +title: AI POD Dashboardの確認 +linkTitle: 7. AI POD Dashboardの確認 +weight: 7 +time: 10 minutes +--- + +このセクションでは、Splunk Observability CloudのAI POD Dashboardを確認し、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 Dashboardタブの確認 + +Splunk Observability Cloudで `Dashboards` に移動し、`Built-in dashboard groups` に含まれている `Cisco AI PODs Dashboard` を検索します。ダッシュボードがOpenShiftクラスター名でフィルタリングされていることを確認します。以下の例のようにチャートが表示されます。 + +![Kubernetes Pods](../../images/Cisco-AI-Pod-dashboard.png) + +## Pure Storage Dashboardタブの確認 + +`PURE STORAGE` タブに移動し、ダッシュボードがOpenShiftクラスター名でフィルタリングされていることを確認します。以下の例のようにチャートが表示されます。 + +![Pure Storage Dashboard](../../images/PureStorage.png) + +## Weaviate Infrastructure Navigatorの確認 + +WeaviateはデフォルトではAI PODに含まれていないため、標準のAI POD Dashboardには含まれていません。代わりに、Infrastructure Navigatorを使用してWeaviateのパフォーマンスデータを確認できます。 + +Splunk Observability Cloudで `Infrastructure` -> `AI Frameworks` -> `Weaviate` に移動します。対象の `k8s.cluster.name` でフィルタリングし、以下の例のようにNavigatorが表示されていることを確認します。 + +![Kubernetes Pods](../../images/WeaviateNavigator.png) diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/8-review-llm-app.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/8-review-llm-app.md new file mode 100644 index 0000000000..55676d7ebb --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-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/)を使用しています。これはLLMを活用したアプリケーションの開発を簡素化するオープンソースのオーケストレーションフレームワークです。 + +## アプリケーション概要 + +### LLMへの接続 + +アプリケーションは、使用する2つのLLMに接続することから始まります。 + +* `meta/llama-3.2-1b-instruct`: ユーザーのプロンプトへの応答に使用 +* `nvidia/llama-3.2-nv-embedqa-1b-v2`: エンベディングの計算に使用 + +``` 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" + ) +``` + +### チェーンの定義 + +アプリケーションは **LCEL（LangChain Expression Language）** を使用してチェーンを定義します。`|`（パイプ）記号はアセンブリラインのように機能し、あるステップの出力が次のステップの入力になります。 + +``` 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モデルは複雑なオブジェクトを返します。この「クリーナー」により、シンプルで読みやすいテキスト文字列が返されるようになります。 + +### チェーンの実行 + +最後に、アプリケーションはエンドユーザーの質問を入力として渡し、チェーンを実行します。 + +``` python + response = chain.invoke(question) +``` + +これが「スタート」ボタンです。エンドユーザーの質問をパイプラインの先頭に投入すると、Retriever、プロンプト、LLMを経由して、最終的に回答が出力されます。 diff --git a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/9-instrument-llm-app.md similarity index 61% rename from content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md rename to content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/9-instrument-llm-app.md index 79b0c3525a..730bb7222a 100644 --- a/content/ja/ninja-workshops/14-cisco-ai-pods/2-workshop/9-instrument-llm-app.md +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/9-instrument-llm-app.md @@ -1,35 +1,35 @@ --- -title: LLM アプリケーションの計装 -linkTitle: 9. LLM アプリケーションの計装 +title: LLMアプリケーションの計装 +linkTitle: 9. LLMアプリケーションの計装 weight: 9 time: 10 minutes --- -## OpenTelemetry によるアプリケーションの計装 +## OpenTelemetryによるアプリケーションの計装 ### 計装パッケージ -アプリケーションからメトリクス、トレース、およびログを取得するために、OpenTelemetry で計装を行いました。 -これには、`requirements.txt` ファイルに以下のパッケージを追加する必要がありました（最終的に `pip install` でインストールされます）: +アプリケーションからメトリクス、トレース、ログを収集するために、OpenTelemetryで計装しています。 +これには、`requirements.txt` ファイルに以下のパッケージを追加する必要があります（最終的に `pip install` でインストールされます）。 ```` splunk-opentelemetry==2.8.0 ```` -また、このアプリケーションのコンテナイメージをビルドするために使用する `Dockerfile` に、追加の OpenTelemetry 計装パッケージをインストールする以下の記述を追加しました: +また、このアプリケーションのコンテナイメージをビルドするために使用する `Dockerfile` に、追加のOpenTelemetry計装パッケージをインストールする以下の記述を追加しました。 ``` dockerfile # Add additional OpenTelemetry instrumentation packages RUN opentelemetry-bootstrap --action=install ``` -次に、`Dockerfile` の `ENTRYPOINT` を変更し、アプリケーション実行時に `opentelemetry-instrument` を呼び出すようにしました: +次に、アプリケーション実行時に `opentelemetry-instrument` を呼び出すよう、`Dockerfile` の `ENTRYPOINT` を変更しました。 ``` dockerfile ENTRYPOINT ["opentelemetry-instrument", "flask", "run", "-p", "8080", "--host", "0.0.0.0"] ``` -最後に、この LangChain アプリケーションから OpenTelemetry で収集されるトレースとメトリクスを強化するために、追加の Splunk 計装パッケージを追加しました: +最後に、このLangChainアプリケーションからOpenTelemetryで収集されるトレースとメトリクスを強化するために、追加のSplunk計装パッケージを追加しました。 ```` splunk-otel-instrumentation-langchain==0.1.4 @@ -38,7 +38,7 @@ splunk-otel-util-genai==0.1.4 ### 環境変数 -OpenTelemetry でアプリケーションを計装するために、アプリケーションのデプロイに使用する Kubernetes マニフェストファイルにいくつかの環境変数も含めました: +OpenTelemetryでアプリケーションを計装するために、アプリケーションのデプロイに使用するKubernetesマニフェストファイルにいくつかの環境変数を含めています。 ``` yaml env: @@ -75,4 +75,4 @@ OpenTelemetry でアプリケーションを計装するために、アプリケ value: "true" ``` -`OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT` および `OTEL_INSTRUMENTATION_GENAI_*` 環境変数は、使用している LangChain 計装に固有のものです。 +注意: `OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT` および `OTEL_INSTRUMENTATION_GENAI_*` 環境変数は、使用しているLangChain計装に固有のものです。 diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/_index.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/_index.md new file mode 100644 index 0000000000..bf5d14bc48 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/2-workshop/_index.md @@ -0,0 +1,14 @@ +--- +title: ワークショップ +linkTitle: 2. ワークショップ +weight: 2 +--- + +このセクションでは、ワークショップ参加者が実施する手順を説明します + +* Red Hat OpenShiftクラスターに **OpenTelemetry Collector** をデプロイする練習をします。 +* Collectorに **Prometheus** Receiverを追加してインフラストラクチャメトリクスを取り込む練習をします。 +* クラスター内の **Weaviate** ベクトルデータベースをモニタリングする練習をします。 +* Prometheusを使用して **Pure Storage** メトリクスを収集する練習をします。 +* 大規模言語モデル（LLM）と連携するPythonサービスを **OpenTelemetry** で計装する練習をします。 +* LLMと連携するアプリケーションのトレースでOpenTelemetryがキャプチャする詳細情報を理解します。 diff --git a/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/_index.md b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/_index.md new file mode 100644 index 0000000000..0f11a6b6d0 --- /dev/null +++ b/content/ja/ninja-workshops/infrastructure/2-cisco-ai-pods/_index.md @@ -0,0 +1,32 @@ +--- +title: Cisco AI Podsのモニタリング +weight: 2 +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/ +product: "Observability Cloud" +--- + +**Cisco AI-ready PODs** は、ハードウェアとソフトウェアの最高の技術を組み合わせ、多様なニーズに対応する堅牢でスケーラブルかつ効率的な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 PODsを監視するために使用される複数の技術のデプロイと操作を実践的に体験できます。内容は以下の通りです + +* Red Hat OpenShiftクラスターに **OpenTelemetry Collector** をデプロイする練習 +* Collectorに **Prometheus** Receiverを追加してインフラストラクチャメトリクスを取り込む練習 +* クラスターに **Weaviate** ベクターデータベースをデプロイする練習 +* 大規模言語モデル（LLM）と連携するPythonサービスを **OpenTelemetry** で計装する練習 +* LLMと連携するアプリケーションからOpenTelemetryがトレースでキャプチャする詳細の理解 + +> [!NOTE] +> ワークショップのセットアップセクションは、ワークショップの主催者のみが実行する必要があります diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/01-prerequisites.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/01-prerequisites.md new file mode 100644 index 0000000000..e0a636aed8 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/01-prerequisites.md @@ -0,0 +1,103 @@ +--- +title: 前提条件 +linkTitle: 01. Prerequisites +weight: 1 +time: 5 minutes + +--- + +このワークショップを開始する前に、以下のツールがインストールされていること、およびSplunk Observability Cloudアカウントが準備されていることを確認してください。 + +## 必要な知識 + +このワークショップでは、以下に関する基本的な知識があることを前提としています。 + +- 基本的なKubernetesの概念（Pod、Deployment、Service） +- HTTPリクエスト/レスポンスのフロー +- 分散トレーシングの概念（Span、Traceなど） + +OpenTelemetryの経験が必要です。コンテキスト伝播の課題については、ワークショップの中で説明します。 + +## 必要なソフトウェア + +以下のツールがインスタンスにインストールされます。 + +| ツール | 最小バージョン | 確認方法 | +|------|-----------------|--------| +| [Docker](https://docs.docker.com/get-docker/) | 24.x | `docker --version` | +| [kubectl](https://kubernetes.io/docs/tasks/tools/) | 1.28+ | `kubectl version --client` | +| [k3d](https://k3d.io/) | 5.6+ | `k3d version` | +| [Git](https://git-scm.com/) | 2.x | `git --version` | +| [Helm](https://helm.sh/docs/intro/install/) | 3.12+ | `helm version` | +| [Node.js](https://nodejs.org/)（オプション） | 20.x | `node --version` | + +## Splunk Observability Cloudへのアクセス + +以下の権限を持つSplunk Observability Cloud組織へのアクセスが必要です。 + +1. **orgアクセストークンの作成** - OTel CollectorとAPMエージェントが使用 +2. **RUMアクセストークンの作成** - ブラウザエージェントが使用（公開トークン） +3. **APMトレースの表示** - APM → Service Map & APM → Traces +4. **RUMセッションの表示** - Digital Experience → Session Search + +### ステップ2の前にこれらの値を収集してください + +| 変数 | 確認場所 | +|----------|------------------| +| `SPLUNK_REALM` | 組織のURL（例: `https://app.us0.signalfx.com` の `us0`） | +| `SPLUNK_ACCESS_TOKEN` | Settings → Access Tokens → Create Token（Ingestスコープ） | +| `SPLUNK_RUM_ACCESS_TOKEN` | Data Management → RUM → Create RUM access token | + +## 検証チェックリスト + +続行する前に、割り当てられたインスタンスで以下のコマンドを実行してください。各セクションには期待される出力が含まれているため、準備ができていることを確認できます。 + +#### 1. 必要なツールの確認 + +**期待される出力（バージョンは異なる場合があります）:** + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +docker --version +kubectl version --client +k3d version +helm version --short +git --version +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` text +Docker version 27.4.0, build bde2b89 +Client Version: v1.31.0 +k3d version v5.7.4 +v3.16.2+gf786678 +git version 2.47.0 +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 2. 必要なポートが空いていることの確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +lsof -i :30080 -i :5111 -i :15672 2>/dev/null || echo "Ports 30080, 5111, and 15672 are available" +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` text +Ports 30080, 5111, and 15672 are available +``` + +**ポートが使用中の場合:** 出力に表示されるプロセス名を確認して停止するか、 `scripts/setup-k3d.sh` を編集して別のポートを使用してください。 + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/02-configure-environment.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/02-configure-environment.md new file mode 100644 index 0000000000..34055de3d9 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/02-configure-environment.md @@ -0,0 +1,59 @@ +--- +title: 環境の設定 +linkTitle: 02. 環境の設定 +weight: 2 +time: 5 minutes + +--- +このステップでは、Splunk Observability Cloudの認証情報とワークショップの設定を含む `.env` ファイルを作成します。 + +{{% notice title="検証チェックリスト" style="green" icon="running" %}} +環境には `SPLUNK_ACCESS_TOKEN`、`SPLUNK_REALM`、`SPLUNK_RUM_ACCESS_TOKEN` の値がすでに設定されている必要があります。 + +プロジェクトルートから以下のコマンドを実行して `.env` を確認します。 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +grep -E '^SPLUNK_(REALM|ACCESS_TOKEN|RUM_ACCESS_TOKEN)=' .env | cut -d= -f1 +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +SPLUNK_REALM +SPLUNK_ACCESS_TOKEN +SPLUNK_RUM_ACCESS_TOKEN +``` + +{{% /tab %}} +{{< /tabs >}} + +**存在しない場合は、以下の手順で設定します** + +```bash +cp .env.example .env +``` + +エディタで `.env` を開き、プレースホルダーの値を置き換えます。 + +```bash +# Splunk Observability Cloud +SPLUNK_REALM= +SPLUNK_ACCESS_TOKEN= + +# RUM browser agent +SPLUNK_RUM_ACCESS_TOKEN= +SPLUNK_RUM_APP_NAME=cosmic-observatory-shop +SPLUNK_DEPLOYMENT_ENV=workshop-context-prop + +# Kubernetes +K3D_CLUSTER_NAME=cosmic-shop +CLUSTER_NAME=cosmic-shop-cluster +REGISTRY=localhost:5111 +TAG=latest +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/03-create-cluster.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/03-create-cluster.md new file mode 100644 index 0000000000..82d2f2bf5f --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/03-create-cluster.md @@ -0,0 +1,168 @@ +--- +title: クラスターの作成 +linkTitle: 03. クラスターの作成 +weight: 3 +time: 15 minutes + +--- +このステップでは、k3dを使用してワークショップイメージ用のローカルコンテナレジストリを備えた軽量なKubernetesクラスターを作成します。 + +セットアップスクリプトは以下を作成します: + +- `cosmic-shop` という名前のシングルサーバーk3dクラスター +- ワークショップイメージをプッシュするためのポート **5111** のローカルDockerレジストリ +- ショップUI（**30080**）とRabbitMQ管理UI（**15672**）のNodePortマッピング + +## クラスターの作成 + +プロジェクトルートから実行します + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +make setup-k3d +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` text +Creating k3d cluster 'cosmic-shop' with local registry on port 5111... +... +k3d cluster 'cosmic-shop' ready. +``` + +{{% /tab %}} +{{< /tabs >}} + +## 検証チェックリスト + +#### 1. k3dクラスターの存在を確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +k3d cluster list +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +NAME SERVERS AGENTS LOADBALANCER +cosmic-shop 1/1 1/1 true +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 2. Kubernetesへの接続を確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +kubectl cluster-info +kubectl get nodes +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +Kubernetes control plane is running at https://0.0.0.0:6443 +... + +NAME STATUS ROLES AGE VERSION +k3d-cosmic-shop-server-0 Ready control-plane,master 45s v1.28.x+k3s1 +k3d-cosmic-shop-agent-0 Ready 40s v1.28.x+k3s1 +``` + +すべてのノードのSTATUS列に `Ready` と表示されている必要があります。 + +{{% /tab %}} +{{< /tabs >}} + +#### 3. k3dコンテナの実行を確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +docker ps --filter name=k3d-cosmic-shop --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +NAMES STATUS PORTS +k3d-cosmic-shop-serverlb Up 2 minutes 0.0.0.0:30080->30080/tcp, 0.0.0.0:15672->15672/tcp, ... +k3d-cosmic-shop-server-0 Up 2 minutes +k3d-cosmic-shop-agent-0 Up 2 minutes +``` + +ロードバランサーがポート **30080** と **15672** を公開していることが表示されます。 + +{{% /tab %}} +{{< /tabs >}} + +#### 4. RabbitMQのポートマッピングを明示的に確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +docker ps --filter name=k3d-cosmic-shop-serverlb --format '{{.Ports}}' +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +0.0.0.0:30080->30080/tcp, 0.0.0.0:15672->15672/tcp, ... +``` + +**15672が表示されない** 場合、クラスターはRabbitMQのポートマッピングなしで作成されています。`make setup-k3d` でクラスターを再作成するまで、管理UIは で読み込めません（下記の[トラブルシューティング](#troubleshooting)を参照）。 + +{{% /tab %}} +{{< /tabs >}} + +## トラブルシューティング + +このステップで発生する可能性のある問題と推奨される対処方法を以下に示します。 + +{{< details summary="トラブルシューティングガイダンスはこちら" >}} + +#### 問題1: ポートが既に使用されている + +ポート30080または5111が使用中の場合、競合しているサービスを停止するか、`scripts/setup-k3d.sh` を編集して別のポートを使用してください。 + +#### 問題2: RabbitMQ UIが読み込めない（ロードバランサーに15672がない） + + が読み込めない場合、k3dがポートをマッピングしているか確認します + +```bash +docker ps --filter name=k3d-cosmic-shop-serverlb --format '{{.Ports}}' +``` + +**`15672` がない場合: クラスターを再作成せずに回避する方法** - 別のターミナルでport-forwardを実行します + +```bash +kubectl -n cosmic-shop port-forward svc/rabbitmq 15672:15672 +``` + +そのターミナルを開いたまま、 / `guest`）を開きます。 + +#### 問題3: クラスターが既に存在する + +`cosmic-shop` という名前のクラスターが既に存在する場合、スクリプトは作成をスキップします。最初からやり直すには以下を実行します + +```bash +k3d cluster delete cosmic-shop +make setup-k3d +``` + +{{< /details >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/04-deploy-splunk-otel-collector.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/04-deploy-splunk-otel-collector.md new file mode 100644 index 0000000000..2257e1864f --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/04-deploy-splunk-otel-collector.md @@ -0,0 +1,161 @@ +--- +title: OTel Collectorのインストール +linkTitle: 04. OTel Collectorのインストール +weight: 4 +time: 15 minutes + +--- + +このステップでは、Helmを使用してk3dクラスターにSplunk Distribution of the OpenTelemetry Collectorをデプロイします。Collectorは計装されたサービスからトレースとメトリクスを受信し、Splunk Observability Cloudに転送します。 + +{{% notice title="注意" style="info" %}} + +各アプリケーションPodはノードIPを経由してCollectorにデータを送信します。 + +```text +Pod → http://$(NODE_IP):4318 → Splunk OTel Collector DaemonSet → Splunk O11y Cloud +``` + +{{% /notice %}} + +## Helmによるインストール + +`.env` ファイルが設定されていることを確認し、以下を実行します。 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +make collector +``` + +{{% /tab %}} +{{% tab title="手動" %}} + +```bash +source .env + +helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart +helm repo update + +helm upgrade --install splunk-otel-collector splunk-otel-collector-chart/splunk-otel-collector \ + --namespace cosmic-shop \ + --create-namespace \ + -f deploy/helm/splunk-otel-values.yaml \ + --set="splunkObservability.realm=${SPLUNK_REALM}" \ + --set="splunkObservability.accessToken=${SPLUNK_ACCESS_TOKEN}" \ + --set="clusterName=${CLUSTER_NAME}" \ + --set="environment=${SPLUNK_DEPLOYMENT_ENV}" +``` + +{{% /tab %}} +{{< /tabs >}} + +## 検証チェックリスト + +`make collector` が完了したら、以下のコマンドを実行します。 + +#### 1. Helmリリースがインストールされていることを確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +helm list -n cosmic-shop +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` +NAME NAMESPACE REVISION STATUS CHART APP VERSION +splunk-otel-collector cosmic-shop 1 deployed splunk-otel-collector-0.x.x 0.x.x +``` + +STATUSが `deployed` であることを確認します。`failed` と表示される場合は、`.env` の `SPLUNK_REALM` と `SPLUNK_ACCESS_TOKEN` を再確認してください。 + +{{% /tab %}} +{{< /tabs >}} + +#### 2. Collector Podが稼働していることを確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +kubectl -n cosmic-shop get pods -l 'app=splunk-otel-collector,component=otel-collector-agent' +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` +NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE +splunk-otel-collector-agent 1 1 1 1 1 2m + +NAME READY STATUS RESTARTS AGE +splunk-otel-collector-agent-xxxxx 1/1 Running 0 60s +``` + +READYが `1/1`、STATUSが `Running` であることを確認します。STATUSが `CrashLoopBackOff` の場合は、ステップ3でログを確認してください。 + +{{% /tab %}} +{{< /tabs >}} + +#### 3. Collectorログに認証エラーがないことを確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +kubectl -n cosmic-shop logs -l 'app=splunk-otel-collector,component=otel-collector-agent' --tail=30 +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` +... Everything is ready. Begin running and processing data. +``` + +**注意すべきエラーの兆候:** + +``` +401 Unauthorized +access token is invalid +failed to export +connection refused +``` + +認証エラーが表示される場合は、`.env` のアクセストークンとrealmを確認し、再インストールします。 + +```bash +make collector +``` + +{{% /tab %}} +{{< /tabs >}} + +## Splunk Observability Cloudでクラスターを確認 + +1. Splunk Observability Cloudを開きます +2. **Infrastructure → Kubernetes → Kubernetes Entities → Clusters** に移動します +3. クラスター名（`cosmic-shop-cluster` または `.env` の `CLUSTER_NAME` の値）を検索します + +Collectorの起動から数分以内にクラスターが表示されます。 + +## トラブルシューティング + +このステップで発生する可能性のある問題と推奨される対処方法を以下に示します。 + +{{< details summary="トラブルシューティングガイドを表示するにはここをクリック" >}} + +#### 問題1. Helmインストールが認証エラーで失敗する + +`.env` の `SPLUNK_ACCESS_TOKEN` と `SPLUNK_REALM` が正しいこと、およびトークンにingest権限があることを確認してください。 + +#### 問題2. Infrastructureナビゲーターにクラスターが表示されない + +2〜3分待ちます。Collector Podが稼働していることを確認し、ログにエクスポートエラーがないか確認してください。 + +{{< /details >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/1-deploy-to-k8s.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/1-deploy-to-k8s.md new file mode 100644 index 0000000000..df9c5a114d --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/1-deploy-to-k8s.md @@ -0,0 +1,213 @@ +--- +title: K8sへのデプロイ +linkTitle: 1. K8sへのデプロイ +weight: 1 +time: 10 minutes + +--- +このステップでは、Helmを使用してSplunk Distribution of the OpenTelemetry Collectorをk3dクラスターにデプロイします。 + +## Kubernetesへのデプロイ + +```bash +make deploy +``` + +このスクリプトは以下を実行します。 + +1. `deploy/k8s/` からすべてのKubernetesマニフェストを適用する +2. `.env` の認証情報から `splunk-otel` Secretを作成する +3. デプロイメントをレジストリのイメージに向ける +4. すべてのロールアウトが完了するまで待機する + +## 検証チェックリスト - デプロイ + +#### 1. すべてのPodが実行中であることを確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +kubectl -n cosmic-shop get pods +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +NAME READY STATUS RESTARTS AGE +catalog-api-xxxxxxxxxx-xxxxx 1/1 Running 0 2m +frontend-xxxxxxxxxx-xxxxx 1/1 Running 0 2m +gateway-xxxxxxxxxx-xxxxx 1/1 Running 0 2m +order-worker-xxxxxxxxxx-xxxxx 1/1 Running 0 2m +rabbitmq-xxxxxxxxxx-xxxxx 1/1 Running 0 2m +splunk-otel-collector-agent-xxxxx 1/1 Running 0 10m +storefront-api-xxxxxxxxxx-xxxxx 1/1 Running 0 2m +``` + +**失敗の指標:** + +| STATUS | 考えられる原因 | +|--------|--------------| +| `ImagePullBackOff` | イメージがプッシュされていない - `make build` を再実行してください | +| `CrashLoopBackOff` | `kubectl -n cosmic-shop logs deployment/` でログを確認してください | +| `Pending` | クラスターリソースが不足している - `kubectl describe pod ` で確認してください | + +{{% /tab %}} +{{< /tabs >}} + +#### 2. サービスとNodePortの確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +kubectl -n cosmic-shop get svc +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +catalog-api ClusterIP 10.43.xxx.xxx 3002/TCP 2m +frontend NodePort 10.43.xxx.xxx 80:30080/TCP 2m +gateway ClusterIP 10.43.xxx.xxx 80/TCP 2m +order-worker ClusterIP 10.43.xxx.xxx 3003/TCP 2m +rabbitmq NodePort 10.43.xxx.xxx 5672:xxxxx/TCP,15672:15672/TCP 2m +storefront-api ClusterIP 10.43.xxx.xxx 3001/TCP 2m +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 3. バックエンドのヘルスエンドポイントの確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +kubectl -n cosmic-shop exec deploy/frontend-api -- wget -qO- http://localhost:3007/health +kubectl -n cosmic-shop exec deploy/catalog-api -- wget -qO- http://localhost:3002/health +kubectl -n cosmic-shop exec deploy/order-api -- wget -qO- http://localhost:3001/health +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```json +{"status":"ok","service":"frontend-api","stage":"bff"} +{"status":"ok","service":"catalog-api"} +{"status":"ok","service":"order-api","stage":"order"} +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 4. ショップUIの応答確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +curl -s -o /dev/null -w "HTTP %{http_code}\n" http://localhost:30080/ +curl -s http://localhost:30080/ | head -5 +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +HTTP 200 + + + + +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 5. ゲートウェイ経由でAPIカタログエンドポイントの確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +curl -s http://localhost:30080/api/catalog | python3 -m json.tool | head -20 +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```json +{ + "products": [ + { + "id": "telescope-orion-8", + "name": "Orion 8\" Dobsonian Telescope", + "price": 449.99, + ... + } + ] +} +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 6. RabbitMQ管理UIの確認 + +RabbitMQサービスは **NodePort 15672** を使用しており、k3dがロードバランサーを通じて管理UIを公開できるようにしています。 + +#### k3dロードバランサーがポート15672にマッピングされていることを確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +docker ps --filter name=k3d-cosmic-shop-serverlb --format '{{.Ports}}' +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +0.0.0.0:30080->30080/tcp, 0.0.0.0:15672->15672/tcp, ... +``` + +出力に **15672が含まれていない** 場合、クラスターがRabbitMQのポートマッピングなしで作成されています。下記の「RabbitMQ UIが読み込めない場合」を参照してください。 + +{{% /tab %}} +{{< /tabs >}} + +#### HTTPの応答確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +curl -s -o /dev/null -w "HTTP %{http_code}\n" http://localhost:15672/ +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +HTTP 200 +``` + +{{% /tab %}} +{{< /tabs >}} + +#### RabbitMQへのログイン（オプション） + +ブラウザで **** を開き、`guest` / `guest` でログインします。 + +**RabbitMQ UIが読み込めない場合**、 **別のターミナル** でport-forwardを使用します（開いたままにしてください）。 + +```bash +kubectl -n cosmic-shop port-forward svc/rabbitmq 15672:15672 +``` + +その後、再度 を開きます。 diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/2-generate-traffic.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/2-generate-traffic.md new file mode 100644 index 0000000000..ec72e956a4 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/2-generate-traffic.md @@ -0,0 +1,41 @@ +--- +title: トラフィックの生成 +linkTitle: 2. トラフィックの生成 +weight: 2 +time: 15 minutes + +--- + +このステップでは、Cosmic Observatory Shopにトラフィックを生成します。 + +## アプリケーションへのアクセス + +ブラウザでCosmic Observatory Shopを開きます。 + +**** + +望遠鏡、アイピース、天体撮影機器などの天文機器カタログが表示されます。 + +![cosmic-shop](../images/cosmic-shop.png) + +オプション - RabbitMQ管理UI + +**: `guest` / `guest`） + +![rabbitmq](../images/rabbitmq.png) + +UIが読み込まれない場合は、ロードバランサーのポートを確認し、port-forwardを使用します。 + +```bash +docker ps --filter name=k3d-cosmic-shop-serverlb --format '{{.Ports}}' +kubectl -n cosmic-shop port-forward svc/rabbitmq 15672:15672 +``` + +## 初期トラフィックの生成 + +1. でショップを開きます +2. メールアドレスを入力します（例: `observer@cosmic.shop`） +3. 任意の商品の **Purchase** をクリックします +4. モーダルで注文を確認します + +トレースデータを生成するために、これを数回繰り返します。 diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/3-check-splunk-apm.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/3-check-splunk-apm.md new file mode 100644 index 0000000000..c9c5c3f0cc --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/3-check-splunk-apm.md @@ -0,0 +1,101 @@ +--- +title: Splunk APMで確認する +linkTitle: 3. Splunk APMで確認する +weight: 3 +time: 10 minutes + +--- + +このステップでは、Splunk Observability Cloudで切断されたトレースがどのように表示されるかを確認します。これはワークショップの残りの部分で修正する「問題のある状態」です。 + +## APMリクエストパス + +**Place order** をクリックしたとき、リクエストは以下の経路を通ります。 + +``` +Browser (RUM span) + → Frontend NGINX + → Edge Gateway NGINX ← break #1: trace headers dropped + → Order API + → Catalog API ← direct HTTP + → Payment Gateway ← break #2: strips headers to payment-api + → Payment API + → RabbitMQ ← break #3: no trace context in message + → Fulfillment Worker ← orphan root trace +``` + +3つの断絶が発生します。 + +1. **HTTP break #1** Edge NGINXゲートウェイ（browser → order API） +2. **HTTP break #2** payment-gatewayプロキシ（order API → payment API） +3. **Messaging break** RabbitMQ（payment API → fulfillment worker） + +## Splunk APMで確認する + +{{% notice title="注意" style="green" icon="running" %}} +データ生成後、メトリクスが表示されるまで **2〜5分** かかります。 +{{% /notice %}} + +### Service map + +1. **APM → Service Map** に移動します +2. 環境をフィルタリングします: `workshop-context-prop` +3. 以下のサービスが表示されます: `order-api`, `payment-gateway`, `payment-api`, `fulfillment-worker`, `catalog-api` + +![servicemap](../images/servicemap-b4.png) + +### Trace search + +1. **APM → Trace Analyzer** に移動します +2. フィルタを設定します: + - Environment: `workshop-context-prop` + - Service: `order-api` + - Operation: `POST /api/orders`（または `storefront.place_order`） +3. 最近のトレースを開きます + +**表示される内容（断絶状態）:** + +![trace-b4](../images/trace-b4.png) + +## 理解度チェック + +#### NGINXがプロパゲーションを断絶する理由 + +{{< details summary="ここをクリックして回答を表示" >}} +ゲートウェイは本番環境で一般的なNGINXパターンを使用しています。 + +```nginx +location /api/ { + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + proxy_pass http://storefront_api; +} +``` + +``` text +いずれかの `proxy_set_header` ディレクティブが存在すると、NGINXはクライアントヘッダーのアップストリームへの自動転送を停止します。`traceparent`、`tracestate`、`baggage` などのヘッダーは、明示的に設定しない限り暗黙的にドロップされます。 + +これは本番環境でトレースの相関が断絶する最も一般的な原因の1つです。 +``` + +{{< /details >}} + +#### RabbitMQがプロパゲーションを断絶する理由 + +{{< details summary="ここをクリックして回答を表示" >}} +ストアフロントは以下のように注文を発行しています（断絶状態）。 + +```javascript +channel.sendToQueue(ordersQueue, Buffer.from(JSON.stringify(order)), { + persistent: true, + headers: { 'x-order-id': order.orderId }, // no traceparent +}); +``` + +``` text +HTTPとは異なり、メッセージブローカーはW3C Trace Contextに自動的に参加しません。プロデューサーはメッセージヘッダーにトレースコンテキストを注入（inject）し、コンシューマーはそれを抽出（extract）する必要があります。これがないと、コンシューマーは新しいルートトレースを開始します。 +``` + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/4-check-splunk-rum.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/4-check-splunk-rum.md new file mode 100644 index 0000000000..1ca4453969 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/4-check-splunk-rum.md @@ -0,0 +1,48 @@ +--- +title: SplunkでRUMを確認する +linkTitle: 4. SplunkでRUMを確認する +weight: 4 +time: 10 minutes + +--- +このステップでは、RUMセッションがリクエストにコンテキストを追加する仕組みと、Splunk Observability Cloudでの表示を確認します。これはAPMの問題がRUMにどのように反映されるかを示す「問題状態」です。 + +## RUMリクエストパス + +1. **** を開きます +2. ブラウザのDevToolsを開き、 **Network** タブを選択します +3. 異なる商品を3〜5件注文します +4. Networkタブで `POST /api/orders` リクエストを確認します +5. リクエストに `traceparent` ヘッダーが含まれていることを確認します（Splunk RUMによって注入されます） + +ヘッダーの例: + +``` +traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 +``` + +ブラウザは正しく計装されており、リクエストが期待どおりに処理されています。 + +{{% notice title="注意" style="green" icon="running" %}} +デプロイ後、RUMデータが表示されるまで **2〜5分** かかります。 +{{% /notice %}} + +## Splunk RUMで確認する + +1. **Digital Experience → Session Search** に移動します +2. **Environment → `workshop-context-prop`** でフィルタリングします +3. 最新のセッションを開きます +4. `/api/orders` の `fetch` または `Click` リソースをクリックします +4. **Backend Trace** リンクを探します + +![rum](../images/rumsesh-b4.png) + +## チェックポイント + +{{% notice title="注意" style="green" icon="running" %}} +RUMとAPMの両方が **Broken state（壊れた状態）** を示しています。 + +ゲートウェイが `traceparent` ヘッダーを `storefront-api` に到達する前に除去したため、RUMはバックエンドのAPM Traceにリンクできません。Splunk RUMは相関のために `Server-Timing` と一致するTrace IDに依存しています。 + +次のステップで、これらの問題を解決します。 +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/_index.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/_index.md new file mode 100644 index 0000000000..159c6aa4b7 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/05-build-and-deploy-app/_index.md @@ -0,0 +1,75 @@ +--- +title: アプリケーションのビルドとデプロイ +linkTitle: 05. アプリケーションのビルドとデプロイ +weight: 5 +time: 10 minutes + +--- +このステップでは、Cosmic Observatory Shopの全サービスのDockerイメージをビルドし、k3dローカルレジストリにプッシュして、Kubernetesにフルスタックをデプロイします。 + +## コンテナイメージのビルド + +プロジェクトルートで `.env` が設定済みであることを確認してください + +```bash +make build +``` + +これにより4つのイメージがビルドされ、`localhost:5111` にプッシュされます + +| イメージ | サービス | +|-------|---------| +| `cosmic-shop/frontend` | Splunk RUMを使用したReactショップUI | +| `cosmic-shop/storefront-api` | Splunk APMを使用した注文API | +| `cosmic-shop/catalog-api` | Splunk APMを使用した商品カタログ | +| `cosmic-shop/order-worker` | Splunk APMを使用したRabbitMQコンシューマー | + +## 検証チェックリスト - ビルド + +#### 1. 4つのイメージすべてがプッシュされたことを確認する + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +curl -s http://localhost:5111/v2/_catalog | python3 -m json.tool +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +```json +{ + "repositories": [ + "cosmic-shop/catalog-api", + "cosmic-shop/frontend", + "cosmic-shop/order-worker", + "cosmic-shop/storefront-api" + ] +} +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 2. 関連するすべてのイメージが存在することを確認する + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +docker images | grep cosmic-shop +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` +localhost:5111/cosmic-shop/frontend latest abc123def456 2 minutes ago 45MB +localhost:5111/cosmic-shop/storefront-api latest def456abc789 2 minutes ago 180MB +localhost:5111/cosmic-shop/catalog-api latest ... +localhost:5111/cosmic-shop/order-worker latest ... +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/1-redeploy.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/1-redeploy.md new file mode 100644 index 0000000000..f757a9c552 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/1-redeploy.md @@ -0,0 +1,159 @@ +--- +title: NGINX修正後の再デプロイ +weight: 1 +time: 5 minutes + +--- + +## 保存後の再デプロイ + +ファイルを保存しただけでは、実行中のgatewayは更新 **されません** 。ConfigMapを適用し、deploymentを再起動して、NGINXに新しい設定を読み込ませる必要があります。 + +プロジェクトルートから以下を実行します。 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +kubectl apply -f deploy/k8s/gateway-config.yaml +kubectl -n cosmic-shop rollout restart deployment/gateway +kubectl -n cosmic-shop rollout status deployment/gateway --timeout=180s +``` + +Podが変更を反映したことを確認します。 + +```bash +kubectl -n cosmic-shop exec deploy/gateway -- grep traceparent /etc/nginx/conf.d/default.conf +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +proxy_set_header traceparent $http_traceparent; +``` + +{{% /tab %}} +{{< /tabs >}} + +## 検証チェックリスト + +再デプロイ完了後に以下のコマンドを実行します。 + +#### 1. gateway Podが再起動したことを確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +kubectl -n cosmic-shop rollout status deployment/gateway +kubectl -n cosmic-shop get pods -l app=gateway +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` +deployment "gateway" successfully rolled out + +NAME READY STATUS RESTARTS AGE +gateway-xxxxxxxxxx-xxxxx 1/1 Running 0 30s +``` + +AGEが最近の値であることを確認します（設定変更後にPodが再作成されたことを示します）。 + +{{% /tab %}} +{{< /tabs >}} + +#### 2. ConfigMapにトレースヘッダーが含まれていることを確認 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +kubectl -n cosmic-shop get configmap gateway-nginx-config -o yaml | grep traceparent +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +``` + proxy_set_header traceparent $http_traceparent; +``` + +出力に `traceparent`、`tracestate`、`baggage` が表示されます。 + +{{% /tab %}} +{{< /tabs >}} + +#### 3. traceparentがorder-apiに到達することを確認 + +既知のトレースヘッダーを付けて **エッジgateway経由で** リクエストを送信します。 + +{{< tabs >}} +{{% tab title="Script" %}} + +```bash +kubectl -n cosmic-shop port-forward svc/gateway 8888:80 & +sleep 2 + +TRACE_ID="deadbeefdeadbeefdeadbeefdeadbeef" +curl -s -H "traceparent: 00-${TRACE_ID}-deadc0dedeadbeef-01" \ + -X POST http://localhost:8888/api/orders \ + -H "Content-Type: application/json" \ + -d '{"productId":"eyepiece-plossl-set","quantity":1,"customerEmail":"trace-test@cosmic.shop"}' \ + | python3 -m json.tool + +kill %1 2>/dev/null +``` + +{{% /tab %}} +{{% tab title="Example Output" %}} + +```json +{ + "message": "Order created", + "order": { "orderId": "ORD-...", ... }, + "traceHint": { + "traceId": "deadbeefdeadbeefdeadbeefdeadbeef", + ... + } +} +``` + +`traceHint.traceId` が `traceparent` ヘッダーで送信したトレースIDと一致することを確認します。これにより、gatewayが `order-api` にヘッダーを転送したことが確認できます。 + +{{% /tab %}} +{{< /tabs >}} + +### $ 4. 新しいブラウザトラフィックを生成 + +**新しいシークレットウィンドウ** またはハードリフレッシュ（Cmd+Shift+R）を使用して、ショップで2〜3件の新しい注文を行います。 + +## トラブルシューティング + +このステップで発生する可能性のある問題と、推奨される対処方法を以下に示します。 + +{{< details summary="トラブルシューティングガイダンスはこちら" >}} + +#### 問題1: 修正後もトレースが切断されたまま + +- `deploy/k8s/gateway-config.yaml` を **保存** し、 **`make fix-nginx`** （または手動の `kubectl apply` + restartコマンド）を実行したことを確認します +- gateway Podが再起動したことを確認します: `kubectl -n cosmic-shop get pods -l app=gateway` +- ConfigMapを確認します: `kubectl -n cosmic-shop get configmap gateway-nginx-config -o yaml | grep traceparent` +- Pod内部を確認します: `kubectl -n cosmic-shop exec deploy/gateway -- cat /etc/nginx/conf.d/default.conf` +- **新しい** トラフィックを生成します。古いトレースは遡って変更されません + +#### 問題2: ConfigMapは更新されたがPodに古い設定が残っている + +NGINXは既存のPod上でConfigMapボリュームの変更をホットリロードしません。YAMLを編集した後は必ず **`rollout restart deployment/gateway`** を実行してください。 + +#### 問題3: CORSプリフライトがヘッダーを除去している + +NGINXにCORSを追加する場合、`Access-Control-Allow-Headers` に `traceparent` と `tracestate` を含めてください。 + +```nginx +add_header Access-Control-Allow-Headers 'Content-Type, traceparent, tracestate, baggage'; +``` + +{{< /details >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/2-observe-in-splunk.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/2-observe-in-splunk.md new file mode 100644 index 0000000000..cac126844b --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/2-observe-in-splunk.md @@ -0,0 +1,20 @@ +--- +title: Splunkで確認する +weight: 2 +time: 5 minutes + +--- + +## Splunkを確認する + +#### 1. RUMで部分的な相関を確認する + +RUMセッションにAPMの相関が表示されます。 + +![nginx-aft](../images/r-nginx-aft.png) + +#### 2. Traceで部分的な相関を確認する + +**APM → Traces** ビューで、最新の `frontend-api` Traceを開きます。この修正により、フロントエンドのSpanがブラウザ/RUMセッションとTrace IDを共有するようになります。 + +![nginx-aft](../images/t-nginx-aft.png) diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/_index.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/_index.md new file mode 100644 index 0000000000..b6131f6178 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/06-fix-nginx-propagation/_index.md @@ -0,0 +1,102 @@ +--- +title: NGINXのプロパゲーション修正 +linkTitle: 06. NGINXのプロパゲーション修正 +weight: 6 +time: 15 minutes +description: このステップでは、エッジゲートウェイのNGINX設定を **編集** してW3C Trace Contextヘッダーを転送し、ゲートウェイを **再デプロイ** して変更を反映させます。これにより、注文パスにおけるSplunk RUMとバックエンドAPMトレース間の相関が復元されます。 + +--- + +{{% notice title="注意" style="info" %}} +このワークショップでは **2つの別々のNGINXインスタンス** を実行しています。このステップでは **エッジゲートウェイ** のみを変更します。 + +#### なぜエッジゲートウェイだけなのか？ + +これは注文トラフィックのパス（break #1が発生する箇所）だからです。 + +``` +Browser + → Frontend NGINX (port 30080, NodePort) + → frontend-api (Node.js BFF) + → Edge Gateway NGINX (ClusterIP service gateway:80) ← ここに修正を適用します + → order-api:3001 +``` + +`/api/purchases`のトレースヘッダーは **frontend-api → gateway → order-api** を通過する必要があります。エッジゲートウェイが `order-api` へのプロキシホップで `traceparent`、`tracestate`、`baggage` を削除しています。 +{{% /notice %}} + +## 修正内容 + +各 `location` ブロックに3つのW3Cコンテキストヘッダーの明示的な転送を追加する必要があります。 + +```nginx +proxy_set_header traceparent $http_traceparent; +proxy_set_header tracestate $http_tracestate; +proxy_set_header baggage $http_baggage; +``` + +これらのディレクティブは、クライアント（Splunk RUM）からの受信トレースコンテキストを上流のサービスに渡すようNGINXに指示します。 + +## 修正の適用 + +``` +vi deploy/k8s/gateway-config.yaml +``` + +`default.conf` セクション（`data:` 配下のインデントされたNGINX設定）内の **`location /api/`** ブロックを見つけます。 + +標準の `proxy_set_header` 行の **後** 、`proxy_http_version` / `proxy_pass` の **前** に、3つのW3Cコンテキストヘッダーの明示的な転送を追加します。 + +```nginx + # W3C Trace Context propagation + proxy_set_header traceparent $http_traceparent; + proxy_set_header tracestate $http_tracestate; + proxy_set_header baggage $http_baggage; +``` + +{{% notice title="注意" style="green" icon="running" %}} +これらのディレクティブは、`frontend-api` からの受信トレースコンテキストを `order-api` に渡すようNGINXに指示します。 +{{% /notice %}} + +## 変更前と変更後 + +{{% notice title="注意" style="info" %}} +**エッジゲートウェイ** の **`location /api/`** ブロックのみが更新されます（フロントエンドNGINXではありません）。 +{{% /notice %}} + +{{< tabs >}} +{{% tab title="変更前" %}} + +```nginx + location /api/ { + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + proxy_http_version 1.1; + proxy_pass http://order_api; + } +``` + +{{% /tab %}} +{{% tab title="変更後" %}} + +```nginx + location /api/ { + proxy_set_header Host $host; + proxy_set_header X-Real-IP $remote_addr; + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + + # W3C Trace Context propagation + proxy_set_header traceparent $http_traceparent; + proxy_set_header tracestate $http_tracestate; + proxy_set_header baggage $http_baggage; + + proxy_http_version 1.1; + proxy_pass http://order_api; + } +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/1-rebuild-and-deploy.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/1-rebuild-and-deploy.md new file mode 100644 index 0000000000..d979bae376 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/1-rebuild-and-deploy.md @@ -0,0 +1,113 @@ +--- +title: Gateway修正の再デプロイ +weight: 1 +time: 5 minutes + +--- + +## 保存後のリビルドと再デプロイ + +{{% notice title="注意" style="info" %}} +`server.js` を保存しただけでは、リビルドと再起動を行うまで実行中のPodは更新 **されません** 。 +{{% /notice %}} + +プロジェクトルートから実行します: + +```bash +bash scripts/build-images.sh payment-gateway +bash scripts/import-images-k3d.sh payment-gateway +kubectl -n cosmic-shop rollout restart deployment/payment-gateway +kubectl -n cosmic-shop rollout status deployment/payment-gateway --timeout=180s +``` + +## 検証チェックリスト + +再デプロイが完了した後、以下のコマンドを実行します。 + +#### 1. ヘルスエンドポイントがpropagationを報告していることを確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +kubectl -n cosmic-shop exec deploy/payment-gateway -- wget -qO- http://localhost:3004/health +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +```json +{"status":"ok","service":"payment-gateway","stage":"proxy","propagation":true} +``` + +ヘルスチェックは、Spanがアクティブなときに `buildUpstreamHeaders()` が `traceparent` ヘッダーを追加するかどうかを検査します。`propagation.inject()` を追加すると自動的に `true` に変わります。 + +{{% /tab %}} +{{< /tabs >}} + +#### 2. テスト注文を行いTraceを確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +curl -s -X POST http://localhost:30080/api/purchases \ + -H "Content-Type: application/json" \ + -d '{"productId":"telescope-orion-8","quantity":1,"customerEmail":"gateway-test@cosmic.shop"}' \ + | python3 -m json.tool +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +```text +**APM → Traces** で、`payment-api` の最新のTraceを開きます。この修正後は以下のようになります: + +| チェック項目 | 期待される結果 | +|-------|----------| +| `payment-api` SpanのParent | `payment-gateway` の子 | +| `payment-gateway` SpanのParent | frontend-apiの購入フローに接続 | +| 同じTrace内の `fulfillment-worker` | **いいえ** — ステップ09まで未修正 | +``` + +{{% /tab %}} +{{< /tabs >}} + +{{% notice title="注意" style="info" %}} +このワークショップではNode.jsプロキシを使用して、 **アプリケーション層** のpropagationバグ（BFFやカスタムゲートウェイでよく見られる）を実践します。ステップ06のNGINX ConfigMapアプローチは、 **インフラストラクチャプロキシ** 層で断絶が発生している場合に適用されます。 +{{% /notice %}} + +## トラブルシューティング + +{{< details summary="トラブルシューティングガイダンスはこちらをクリック" >}} + +#### 問題1. 修正後もTraceが切断されたまま + +- `services/payment-gateway/server.js` を **保存** し、 **`make fix-payment-gateway`** （リビルド + インポート + 再起動）を実行したことを確認します +- Podが最近のAGEで再起動されていることを確認します: `kubectl -n cosmic-shop get pods -l app=payment-gateway` +- ヘルスが `"propagation": true` を表示していることを確認します +- **新しい** トラフィックを生成します。古いTraceは遡って変更されません + +#### 問題2. ヘルスが `"propagation": false` のまま + +- `propagation.inject()` が `buildUpstreamHeaders()` 内にあり、`return headers` の **前に** 実行されることを確認します +- upstream fetchパスから `suppressTracing()` を削除したことを確認します +- フルリビルドチェーンを再実行します。イメージがリビルドされていない場合、再起動だけでは不十分です + +#### 問題3. ゲートウェイのセットアップがNGINX / ConfigMapプロキシを使用している場合 + +一部のチームでは、Node.jsプロキシの代わりに **APIゲートウェイまたはNGINXサイドカー** で決済ルーティングを実装しています。障害モードはステップ06と同じで、`proxy_set_header traceparent` ディレクティブが欠落しています。 + +組織でそのパターンを使用している場合、修正はJavaScriptではなく **ConfigMap** の変更（`gateway-config.yaml`）になります: + +```nginx +location /payments/ { + proxy_set_header Host $host; + proxy_set_header traceparent $http_traceparent; + proxy_set_header tracestate $http_tracestate; + proxy_set_header baggage $http_baggage; + proxy_pass http://payment_api; +} +``` + +{{< /details >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/2-observe-in-splunk.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/2-observe-in-splunk.md new file mode 100644 index 0000000000..b9c2ea84df --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/2-observe-in-splunk.md @@ -0,0 +1,20 @@ +--- +title: Splunkで確認する +weight: 2 +time: 5 minutes + +--- + +## Splunkを確認する + +#### 1. Service Mapで部分的な相関を確認する + +payment-gatewayとpayment-api間のAPM相関がService Mapに表示されます。 + +![gtway-aft](../images/s-gateway-aft.png) + +#### 2. Tracesで部分的な相関を確認する + +**APM → Traces** ビューで、最近の `order-api` トレースを開きます。orderのSpanにorder-apiとの相関が表示されます。 + +![gtway-aft](../images/t-gateway-aft.png) diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/_index.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/_index.md new file mode 100644 index 0000000000..4e5aa812df --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/07-fix-payment-gateway-propagation/_index.md @@ -0,0 +1,104 @@ +--- +title: Payment Gatewayのプロパゲーション修正 +linkTitle: 7. Payment Gatewayのプロパゲーション修正 +weight: 7 +time: 15 minutes + +--- + +このステップでは、payment gatewayプロキシの **アプリケーションコードを編集** し、W3C Trace Contextを `payment-api` に転送するようにしてから、サービスを **リビルドして再デプロイ** します。 + +{{% notice title="注意" style="info" %}} +エッジNGINXゲートウェイを修正した後（ステップ06）、ブラウザから `frontend-api` を経由して `order-api` までトレースが接続される場合があります。しかし、 **frontend-api** が `payment-gateway` 経由で支払いを送信する際、プロキシはW3Cトレースヘッダー **なしで** `payment-api` に転送します。 + +この断絶は一般的な **Node.jsプロキシのバグ** です。サービスは計装されAPMに表示されますが、送信側の `fetch` がトレースコンテキストを伝播しません。 +{{% /notice %}} + +Splunk APMでは次の動作が確認できます。 + +- `frontend-api` → `payment-gateway` - 接続済み +- `payment-gateway` → `payment-api` - **切断** + +![nginx-aft1](./images/07-index.png) + +payment gatewayは独自の **Span** を生成するため（サービスマップに表示されます）、上流の呼び出しは `payment-api` で新しいトレースを開始します。これは、カスタムBFF/プロキシを追加して送信HTTPコールでのコンテキスト伝播を忘れた実際のチームや、「二重Span」を避けようとして `suppressTracing()` を使用し、誤ってプロパゲーションを壊してしまうケースを再現しています。 + +## 修正方法 + +server.jsファイルを開き、 **`buildUpstreamHeaders()`** を見つけます。 + +``` +vi services/payment-gateway/server.js +``` + +### 1. W3Cトレースコンテキストを上流ヘッダーに注入する + +returnの前に `propagation.inject()` のコメントを解除/追加します。 + +```javascript +function buildUpstreamHeaders() { + const headers = { + 'Content-Type': 'application/json', + }; + + propagation.inject(context.active(), headers, { + set: (carrier, key, value) => { + carrier[key] = value; + }, + }); + + return headers; +} +``` + +### 2. 上流fetchから `suppressTracing` を削除する + +`POST /payments` 内の上流呼び出しを見つけます。 + +```javascript +// Before (broken): +const upstreamContext = suppressTracing(context.active()); + +// After (fixed): +const upstreamContext = context.active(); +``` + +## 修正前と修正後 + +{{< tabs >}} +{{% tab title="修正前" %}} + +```javascript +function buildUpstreamHeaders() { + const headers = { + 'Content-Type': 'application/json', + }; + return headers; +} + +const upstreamContext = suppressTracing(context.active()); +``` + +{{% /tab %}} +{{% tab title="修正後" %}} + +```javascript +function buildUpstreamHeaders() { + const headers = { + 'Content-Type': 'application/json', + }; + + propagation.inject(context.active(), headers, { + set: (carrier, key, value) => { + carrier[key] = value; + }, + }); + + return headers; +} + +const upstreamContext = context.active(); +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/08-fix-rabbitmq-propagation/1-rebuild-and-deploy.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/08-fix-rabbitmq-propagation/1-rebuild-and-deploy.md new file mode 100644 index 0000000000..12a6a388fd --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/08-fix-rabbitmq-propagation/1-rebuild-and-deploy.md @@ -0,0 +1,125 @@ +--- +title: RabbitMQ修正の再デプロイ +weight: 1 +time: 5 minutes + +--- + +## 保存後のリビルドと再デプロイ + +プロジェクトルートから以下の手順を実行します。 + +```bash +bash scripts/build-images.sh payment-api fulfillment-worker +bash scripts/import-images-k3d.sh payment-api fulfillment-worker +kubectl -n cosmic-shop rollout restart deployment/payment-api +kubectl -n cosmic-shop rollout restart deployment/fulfillment-worker +kubectl -n cosmic-shop rollout status deployment/payment-api --timeout=180s +kubectl -n cosmic-shop rollout status deployment/fulfillment-worker --timeout=180s +``` + +## 検証チェックリスト + +再デプロイ完了後に以下のコマンドを実行します。 + +#### 1. ヘルスエンドポイントでpropagationが有効であることを確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +kubectl -n cosmic-shop get pods -l app=fulfillment-worker +kubectl -n cosmic-shop exec deploy/fulfillment-worker -- wget -qO- http://localhost:3006/health +kubectl -n cosmic-shop exec deploy/payment-api -- wget -qO- http://localhost:3005/health +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +```json +{"status":"ok","service":"payment-api","stage":"payment","rabbitmq":true,"propagation":true} +{"status":"ok","service":"fulfillment-worker","stage":"fulfillment","propagation":true} +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 2. ロールアウトの完了を確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +kubectl -n cosmic-shop rollout status deployment/payment-api +kubectl -n cosmic-shop rollout status deployment/fulfillment-worker +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 3. 起動ログにpropagationが記載されていることを確認 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +kubectl -n cosmic-shop logs deployment/payment-api --tail=3 +kubectl -n cosmic-shop logs deployment/fulfillment-worker --tail=3 +``` + +{{% /tab %}} +{{% tab title="出力例" %}} + +``` +RabbitMQ context propagation: ENABLED +RabbitMQ context propagation: ENABLED +``` + +{{% /tab %}} +{{< /tabs >}} + +#### 4. テスト注文を行い、ワーカーの処理を確認 + +{{% notice title="検証" style="green" icon="running" %}} +再デプロイ後に **新しい** 注文を行ってください。修正前に発行されたメッセージにはトレースコンテキストが含まれていません。 +{{% /notice %}} + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +curl -s -X POST http://localhost:30080/api/purchases \ + -H "Content-Type: application/json" \ + -d '{"productId":"filter-nebula-uhc","quantity":1,"customerEmail":"propagation-test@cosmic.shop"}' \ + | python3 -m json.tool + +sleep 2 +kubectl -n cosmic-shop logs deployment/fulfillment-worker --tail=3 +``` + +{{% /tab %}} +{{< /tabs >}} + +## トラブルシューティング + +{{< details summary="トラブルシューティングガイダンスはこちら" >}} + +#### 問題1. Fulfillment workerがまだ孤立したトレースを表示する + +- **両方** のファイルが編集されていることを確認します（producerのinject + consumerのextract） +- **`make fix-rabbitmq`** を実行したことを確認します（両方のイメージをリビルドします。再起動だけでは不十分です） +- 両方のヘルスエンドポイントで `"propagation": true` が表示されることを確認します +- 修正後に **新しい** 注文を生成します + +#### 問題2. payment-apiのヘルスのみがtrueになる + +consumerのスタブを `extractTraceContext()` に置き換える必要があります。producerのみを修正するだけでは不十分です。 + +#### 問題3. 代替パターン: 自動計装 + +一部のチームでは、手動のinject/extractの代わりに **`@opentelemetry/instrumentation-amqplib`**（OpenTelemetry JS contrib）を使用しています。 + +障害モードは同じで、計装が無効または設定ミスの場合ですが、publish/consumeコードを編集する代わりに `instrumentation.js` でライブラリを有効にすることで解決します。 + +このワークショップでは生の `amqplib` を使用しています。これはNode.jsサービスでまだ一般的であり、inject/extractの契約を明示的にするためです。 +{{< /details >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/08-fix-rabbitmq-propagation/_index.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/08-fix-rabbitmq-propagation/_index.md new file mode 100644 index 0000000000..a537ef4526 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/08-fix-rabbitmq-propagation/_index.md @@ -0,0 +1,93 @@ +--- +title: RabbitMQ Propagationの修正 +linkTitle: 8. RabbitMQ Propagationの修正 +weight: 8 +time: 15 minutes + +--- + +このステップでは、メッセージの **producer** と **consumer** の**アプリケーションコードを編集**し、W3C Trace ContextがRabbitMQ AMQPヘッダーを通じて伝搬されるようにします。 + +{{% notice title="注意" style="info" %}} +RabbitMQにはブローカーレベルのトレース設定がありません。伝搬は常にアプリケーションコードで実装されます。 + +`payment-api`から `fulfillment-worker` への**非同期ハンドオフ**には、AMQPメッセージヘッダーでの**手動コンテキストインジェクションとエクストラクション**が必要です。 + +いずれかの側でこれを省略すると、消費された各メッセージは**新しいルートTrace**を開始します。これは本番環境で最もよく見られる非同期オブザーバビリティのギャップの1つです。 +{{% /notice %}} + +## 修正方法 + +### 1. Producer -（payment-api） + +``` +vi services/payment-api/server.js +``` + +**`buildFulfillmentMessageHeaders()`** を見つけ、戻り値を `injectTraceHeaders()` でラップします。 + +{{< tabs >}} +{{% tab title="修正前" %}} + +```javascript +function buildFulfillmentMessageHeaders(order, payment) { + return { + 'x-order-id': order.orderId, + 'x-payment-id': payment.paymentId, + }; +} +``` + +{{% /tab %}} +{{% tab title="修正後" %}} + +```javascript +function buildFulfillmentMessageHeaders(order, payment) { + return injectTraceHeaders({ + 'x-order-id': order.orderId, + 'x-payment-id': payment.paymentId, + }); +} +``` + +{{% /tab %}} +{{< /tabs >}} + +### 2. Consumer -（fulfillment-worker） + +ファイルを開いて編集します。 + +``` +vi services/fulfillment-worker/worker.js +``` + +先頭にimportを追加します。 + +```javascript +import { extractTraceContext } from './shared/propagation.js'; +``` + +**`extractMessageContext()`** スタブを共有エクストラクターに置き換えます。 + +{{< tabs >}} +{{% tab title="修正前" %}} + +```javascript +// Remove this stub: +function extractMessageContext(_headers) { + return context.active(); // ignores AMQP headers +} +``` + +{{% /tab %}} +{{% tab title="修正後" %}} + +```javascript +import { extractTraceContext } from './shared/propagation.js'; + +// Instead of ignoring AMQP headers, use the shared helper in processFulfillment instead: +const parentContext = extractTraceContext(msg.properties.headers ?? {}); +``` + +{{% /tab %}} +{{< /tabs >}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/09-verify-correlation/_index.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/09-verify-correlation/_index.md new file mode 100644 index 0000000000..0ad6e45494 --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/09-verify-correlation/_index.md @@ -0,0 +1,126 @@ +--- +title: 相関の検証 +linkTitle: 9. 相関の検証 +weight: 9 +time: 10 minutes + +--- +この最後のステップでは、ブラウザのクリックからNGINXゲートウェイ、APIサービス、RabbitMQ、バックグラウンドワーカーまで、トレースが途切れなく流れていることを確認します。すべてがSplunk Observability Cloudで単一のトレースとして表示されます。 + +## エンドツーエンドの検証 + +### 新しいWebリクエストの送信 + +{{< tabs >}} +{{% tab title="スクリプト" %}} + +```bash +curl -s -X POST http://localhost:30080/api/purchases \ + -H "Content-Type: application/json" \ + -d '{"productId":"mount-eq6-pro","quantity":1,"customerEmail":"final-test@cosmic.shop"}' \ + | python3 -m json.tool +``` + +{{% /tab %}} +{{% tab title="期待される出力" %}} + +```json +{ + "message": "Order accepted for fulfillment", + "order": { + "orderId": "ORD-1719763200456", + "productName": "SkyWatcher EQ6-R Pro Mount", + "total": 1899.0 + }, + "traceHint": { + "traceId": "4bf92f3577b34da6a3ce929d0e0e4736", + "spanId": "..." + } +} +``` + +{{% /tab %}} +{{< /tabs >}} + +{{% notice title="タスク" style="info" %}} +トレースID（32文字の16進数）をコピーします。Splunk APMでの検索に使用します。 +{{% /notice %}} + +{{< tabs >}} +{{% tab title="スクリプト" %}} +{{% notice title="注意" style="info" %}} +fulfilment-apiを検証するために2秒待ちます +{{% /notice %}} + +```bash +kubectl -n cosmic-shop logs deployment/order-worker --tail=3 +``` + +{{% /tab %}} +{{% tab title="期待される出力" %}} + +``` +Fulfilled order ORD-1719763200456 for SkyWatcher EQ6-R Pro Mount +``` + +{{% /tab %}} +{{< /tabs >}} + +## Splunk RUMでの検証 + +1. **Digital Experience → Sessions** に移動します +2. セッションを見つけます（環境 `workshop-context-prop`） +3. セッションタイムラインをクリックします +4. `POST /api/orders` フェッチイベントを選択します +5. 以下を確認します + - レスポンスタイムが表示されている + - **Backend Trace** リンクがAPMに遷移する + - トレースIDがブラウザの `traceparent` ヘッダーと一致している + +### ToDO: Update Image + +![trace-b4](./images/trace-b4.png) + +## Splunk APMでの検証 + +1. **APM → Traces** に移動します +2. フィルター条件 + - Environment: `workshop-context-prop` + - Minimum duration: any +3. RUMからリンクされたトレースを開きます（または `traceparent` ヘッダーのトレースIDで検索します） + +### 期待されるSpan階層 + +``` +Trace ID: 4bf92f3577b34da6a3ce929d0e0e4736 (example) + +├─ documentLoad / routeChange [RUM] +├─ HTTP GET /api/catalog [RUM → storefront-api] +│ └─ GET /api/catalog [storefront-api] +│ └─ catalog.list_products [catalog-api] +└─ HTTP POST /api/orders [RUM → storefront-api] + └─ POST /api/orders [storefront-api] + ├─ catalog.get_product [catalog-api] + ├─ storefront.publish_order [storefront-api, PRODUCER] + │ └─ order-worker.process_order [order-worker, CONSUMER] + │ ├─ validate_inventory + │ ├─ prepare_shipment + │ └─ send_confirmation + └─ (response 202) +``` + +### TODO UPDATE Image + +![trace-aft1](./images/trace-aft.png) + +## Service Mapの検証 + +1. **APM → Service Map** に移動します +2. 環境をフィルタリングします: `workshop-context-prop` +3. すべてのサービスがトラフィックエッジ付きで表示されていることを確認します + - `storefront-api` → `catalog-api` + - `storefront-api` → `order-worker`（RabbitMQ経由） + +### TODO: UPDATE Image + +![servicemap-aft1](./images/servicemap-aft.png) diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/10-wrap-up/_index.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/10-wrap-up/_index.md new file mode 100644 index 0000000000..c424c004fb --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/10-wrap-up/_index.md @@ -0,0 +1,30 @@ +--- +title: まとめ +weight: 10 +time: 5 minutes + +--- + +## サマリー + +このワークショップでは、Splunk RUMから注文 → 決済 → フルフィルメントパイプラインを通る単一のチェックアウトをトレースし、トレースが途切れやすい3つのポイントで相関を復元しました。 + +1つ目は、エッジのNGINXゲートウェイです。明示的なproxy_set_headerルールがリクエストを転送していましたが、W3C Trace Contextは転送していませんでした。そこで、proxy_set_header traceparent $http_traceparent（およびtracestateとbaggage）を追加し、リバースプロキシを通じてヘッダーを渡すようにしました。 + +2つ目は、決済ゲートウェイです。計装済みのNode.jsプロキシが、送信HTTPコールでコンテキストを伝播しなかったためチェーンが切れていました。これはBFF/プロキシでよくあるバグで、アプリケーションコードでpropagation.inject()を使用し、上流のfetchからsuppressTracing()を削除することで修正しました。 + +3つ目は、RabbitMQを跨ぐ部分です。ブローカー自体はTrace Contextを運びません。プロデューサーがW3CヘッダーをAMQPメッセージプロパティにインジェクトせず、コンシューマーがそれらを抽出していなかったため、非同期のハンドオフが失敗していました。そこで、パブリッシュ時のインジェクトとコンシューム時の抽出を実装しました（これはOTelメッセージング計装が他のスタックで自動化しているのと同じ規約です）。 + +これらの修正により、ブラウザ/RUM Span、プロキシおよびアプリケーション層ゲートウェイを通る同期HTTPホップ、非同期フルフィルメント処理が1つのトレースに再接続され、Splunk APMでエンドツーエンドに追跡できるようになります。 + +{{% notice title="注意" style="info" %}} +おめでとうございます。プロキシとメッセージバスを跨ぐフルスタックオブザーバビリティを復元できました！ +{{% /notice %}} + +## クリーンアップ + +ローカルのワークショップリソース（k3dクラスター、Splunk Collector、アプリケーションワークロード、ローカルイメージ）をすべて削除します。 + +```bash +make cleanup +``` diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/11-additional-samples/_index.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/11-additional-samples/_index.md new file mode 100644 index 0000000000..6659ed64fd --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/11-additional-samples/_index.md @@ -0,0 +1,13 @@ +--- +title: 付録 +weight: 11 +archetype: chapter + +--- +このワークショップで使用する技術には多くのソリューションの選択肢があります。コンテキスト伝播の管理方法について具体的な手順を示す、追加の技術別サンプルを順次追加していきます。 + +{{% notice icon="Note" style="orange" title="技術別サンプル" %}} + +## 近日公開 + +{{% /notice %}} diff --git a/content/ja/ninja-workshops/instrumentation/20-context-propagation/_index.md b/content/ja/ninja-workshops/instrumentation/20-context-propagation/_index.md new file mode 100644 index 0000000000..5ba738ed7a --- /dev/null +++ b/content/ja/ninja-workshops/instrumentation/20-context-propagation/_index.md @@ -0,0 +1,39 @@ +--- +draft: true +title: Context Propagation +linkTitle: Context Propagation +weight: 20 +layout: chapter +time: 90 minutes +authors: ["Diana Omuoyo"] +description: プロキシやメッセージバスがW3Cトレースコンテキストを破棄すると、分散トレーシングはサイレントに壊れます。このワークショップでは、よくあるコンテキストと相関の断絶を含むサンプルEコマースアプリケーションを使用します +aliases: + - /ninja-workshops/20-context-propagation/ +--- + +## 概要 + +このワークショップでは、天文機器のストアフロントである **Cosmic Observatory Shop** をデプロイし、Splunk RUMとSplunk APMで計装します。 + +必要なW3Cヘッダーが以下の **3つ** のレイヤーで除去された場合に、サービスマップとトレースが断片化される様子を観察します。 + +1. **Edge NGINX gateway** - W3Cトレースヘッダーを破棄（frontend-api → order API） +2. **Payment gateway proxy** - 計装済みのNode.jsプロキシがヘッダーを破棄（frontend-api → payment API） +3. **RabbitMQ message bus** - AMQPヘッダーにトレースコンテキストがない非同期のpayment → fulfillment + +その後、問題を修正して、すべてのサービスおよびインフラストラクチャレイヤーにわたるエンドツーエンドのコンテキスト伝搬を復元します。 + +## アーキテクチャ | 期待される出力 + +```text +Browser (RUM) + → Frontend → Frontend API (BFF) + ├─ catalog path ──► Catalog API + └─ purchase workflow ──► Edge Gateway → Order API + └─► Payment Gateway → Payment API → RabbitMQ → Fulfillment Worker + ▲ ▲ ▲ + Break #1 Break #2 Break #3 + (Step 06) (Step 07) (Step 08) +``` + +それでは始めましょう！ diff --git a/content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/2-create-dashboard.md b/content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/2-create-dashboard.md deleted file mode 100644 index 0d5f48fd97..0000000000 --- a/content/ja/ninja-workshops/operations/11-ingest-processor-for-observability-cloud/4-update-pipeline-and-visualize/2-create-dashboard.md +++ /dev/null @@ -1,179 +0,0 @@ ---- -title: Kubernetes 監査イベントメトリクスの可視化 -linkTitle: 4.2 Kubernetes 監査イベントメトリクスの可視化 -weight: 3 ---- - -メトリクスにディメンションが追加されたので、イベントの `verb` ディメンションを使用して、さまざまな Kubernetes アクションの状態を示すチャートを作成します。 - -{{% notice title="演習: Kubernetes 監査イベントメトリクスの可視化" style="green" icon="running" %}} - -**1.** 前のセクションで作成したチャートを閉じた場合は、右上の **+** アイコン → **Chart** をクリックして新しいチャートを作成します。 - -![Create New Chart](../../images/create_new_chart.png?width=40vw) - -**2.** 新しく作成したチャートの **Plot Editor** で、メトリクス名フィールドに `k8s_audit*` と入力します。ここではワイルドカードを使用して、取り込まれているすべてのメトリクスを確認できるようにします。 - -![Review Metric](../../images/review_metric.png?width=40vw) - -**3.** メトリクスが1つから複数に変化したことに注目してください。これは、パイプラインを更新してディメンションを含めた時点での変化です。このメトリクスが利用可能になったので、アクションにエラーが関連付けられているかどうかを確認できるようにチャートを調整しましょう。 - -![Metric Timeseries](../../images/metric_timeseries.png?width=40vw) - -まず、**response_status** フィールドで利用可能な HTTP レスポンスコードを使用して、成功しなかった Kubernetes イベントのみにフィルタリングします。レスポンスコードが **409**（コンフリクトを示す。例えば、既に存在するリソースを作成しようとした場合）または **503**（リクエストに対して API が応答しなかったことを示す）のイベントのみを対象とします。 - -**4.** チャートの Plot Editor で **Add filter** をクリックし、フィールドに **response_status** を使用し、値として **409.0** と **503.0** を選択します。 - -次に、**resource**、**action**、**response status** でグループ化されたイベントの合計数を計算する関数をチャートに追加します。これにより、どのアクションと関連リソースにエラーがあったかを正確に確認できます。これで、成功しなかった Kubernetes イベントのみを表示しています。 - -**5.** **Add analytics** → **Sum** → **Sum:Aggregation** をクリックし、**Group by** フィールドに **resource**、**action**、**response_status** を追加します。 - -![Add Metric Filters](../../images/add_metric_filters.png?width=40vw) - -**6.** 上部のボタンにあるチャートタイプを使用して、チャートを **heatmap** に変更します。**Plot editor** の隣にある **Chart options** をクリックします。**Group by** セクションで **response_status**、次に **action** を選択します。**Color threshold** を **Auto** から **Fixed** に変更します。青い **+ button** をクリックして別のしきい値を追加します。**下矢印を Yellow**、**中間を orange** に変更します。**上矢印は red のまま**にします。**中間しきい値に 5**、**上限しきい値に 20** を入力します。 - -![Configure Thresholds](../../images/configure_thresholds.png?width=40vw) - -**7.** チャートの右上にある青い **Save as...** ![Preview Button](../../images/save_as_btn.png?height=20px&classes=inline) ボタンをクリックします。チャートの名前を入力します（例: Kubernetes Audit Logs - Conflicts and Failures）。 - -![Chart Name](../../images/chart_name.png) - -**8.** **Choose a dashboard** で **New dashboard** を選択します。 - -![New Dashboard](../../images/new_dashboard.png) - -**9.** 後で簡単に見つけられるように、イニシャルを含むダッシュボード名を入力します。**Save** をクリックします。 - -![New Dashboard Name](../../images/dashboard_name.png) - -**10.** 作成した新しいダッシュボードが選択されていることを確認し、**Ok** をクリックします。 - -![Save New Dashboard](../../images/save_new_dashboard.png) - -これで、作成したチャートが含まれる新しい Kubernetes Audit Events ダッシュボードに移動します。環境内の他のメトリクスから新しいチャートを追加できます。例えば、Kubernetes クラスター上で実行されているアプリケーションのエラーやレスポンスタイム、Pod フェーズ、Pod メモリ使用率などの他の Kubernetes メトリクスを追加して、クラスターイベントからアプリケーションの状態まで、Kubernetes 環境の相関ビューを構築できます。 - -![Audit Dashboard](../../images/audit_dashboard.png?width=40vw) - -チャートのビジュアライゼーションボックスの右上にある三点リーダー `...` を使用して、このチャートのコピーを作成します。 - -![Copy chart button](../../images/copy_chart_button.png?width=40vw) - -UI の右上にある `+` アイコンを使用して、作業中の同じダッシュボードに貼り付けます。 - -![Paste chart into dashboard](../../images/paste_chart_into_dashboard.png?width=40vw) - -貼り付けたチャートをクリックし、ビジュアライゼーションを **Column** チャートに変更します。 - -![Change to column chart visualization](../../images/change_to_column_chart_visualization.png?width=40vw) - -SUM を `resource`、`namespace` のみに変更します（フィルターにより問題のあるコードのみに絞り込まれています）。 - -![Group chart by resource and namespace](../../images/group_chart_by_resource_and_namespace.png?width=40vw) - -Chart options でタイトルを `Kubernetes Audit Logs - Conflicts by Namespace` に変更します。 - -![Change chart title](../../images/change_chart_title.png?width=40vw) - -**Save** をクリックして閉じます。 - -![Save and close chart](../../images/save_and_close_chart.png) - -{{% /notice %}} - -{{% notice title="演習: Kubernetes 監査ログに基づくディテクターの作成" style="green" icon="running" %}} - -Conflicts by Namespace チャートで小さなベルアイコンをクリックし、New detector from chart を選択します。 - -![Bell icon to create detector](../../images/bell_icon_create_detector.png?width=40vw) - -名前を入力し、**Create alert rule** をクリックします。 - -![Enter name for alert rule](../../images/enter_name_alert_rule.png?width=40vw) - -Alert condition で **Static Threshold** をクリックし、Proceed to **Alert Settings** をクリックします。 - -![Select static threshold condition](../../images/select_static_threshold_condition.png?width=40vw) - -**Threshold** に `20` を入力します。 - -![Enter threshold value](../../images/enter_threshold_value.png?width=40vw) - -このアラートの受信者は選択しないので、**Activate** をクリックし、**Activate Alert Rule** と **Save** を選択します。 - -![Activate alert rule and save](../../images/activate_alert_rule_and_save.png?width=40vw) - -右上の **Save** を最後にもう一度クリックして、ディテクターを保存します。 - -![Final save for detector](../../images/final_save_detector.png?width=40vw) - -ダッシュボードに戻ると、チャートに関連付けられたディテクターが、チャート上の点灯したベルアイコンで示されていることが確認できます。 - -![Detector bell icon on chart](../../images/detector_bell_icon_on_chart.png?width=40vw) - -{{% /notice %}} - -{{% notice title="演習: Splunk Cloud - Dashboard Studio で時系列データを可視化する" style="green" icon="running" %}} - -時系列メトリクスが Splunk Observability Cloud のデータストアに取り込まれたので、これらの時系列メトリクスを Splunk Cloud で簡単に可視化できます。 - -Splunk Cloud インスタンスで **Dashboards** に移動し、**Create New Dashboard** を選択します。 - -![Create new dashboard in Splunk Cloud](../../images/create_new_dashboard_splunk_cloud.png) - -Dashboard のタイトル、権限、**Dashboard Studio** を選択し、任意の Layout Mode を選びます。 -**Create** をクリックします。 - -![Dashboard title and layout options](../../images/dashboard_title_layout_options.png) - -Dashboard Studio でチャートアイコンをクリックし、**Column** を選択します。 - -![Select column chart in Dashboard Studio](../../images/select_column_chart_dashboard_studio.png) - -**Select data source** で **Create splunk observability cloud metric search** を選択します。 - -![Choose observability cloud metric search as data source](../../images/choose_observability_cloud_metric_search.png) - -新しいデータソースの名前を入力し、**Search for metric or metadata** の下にある **Content Import** リンクをクリックします。 - -チャートの URL をコピーして **Content URL** フィールドに貼り付けます。 - -![Paste chart URL and import](../../images/paste_chart_url_and_import.png?width=40vw) - -**Import** をクリックします。 - -![Chart imported to dashboard](../../images/chart_imported_to_dashboard.png) - -![Chart visible in dashboard](../../images/chart_visible_in_dashboard.png) - -チャートのサイズをダッシュボードに合わせて調整します。 - -![Resize chart in dashboard](../../images/resize_chart_in_dashboard.png?width=40vw) - -チャートの **Configuration** の右側にある **Interactions** を展開し、**Add Interaction** をクリックします。 - -![Expand interactions and add interaction](../../images/expand_interactions_add_interaction.png) - -Splunk Observability のダッシュボードから URL をコピーします。 - -![Apply interaction settings](../../images/apply_interaction_settings.png?width=40vw) - -**On click** で **Link to custom URL** を選択し、ソースデータに簡単に戻れるように Splunk Observability Cloud のダッシュボードの URL を追加します。 -また、ナビゲーションを便利にするために **Open in new tab** を選択します。 - -![Interaction added](../../images/interaction_added.png) - -右上の **Save** をクリックしてダッシュボードを保存します。 - -![Save dashboard in Splunk Cloud](../../images/save_dashboard_splunk_cloud.png) - -チャート内のカラムまたは名前をハイライトしてクリックします。 - -![Click column or name in chart](../../images/click_column_or_name_in_chart.png) - -Splunk Observability に戻ることが通知されます。**Continue** をクリックします。 - -![Continue navigation to Splunk Observability](../../images/continue_navigation_splunk_observability.png) - -これで、Splunk Cloud から対応する Splunk Observability ダッシュボードに戻ることができました。 - -{{% /notice %}} diff --git a/content/ja/other/_index.md b/content/ja/other/_index.md deleted file mode 100644 index e647c99d5d..0000000000 --- a/content/ja/other/_index.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -archetype: "home" -title: その他のワークショップ -# menuPost: " " -weight: 19 ---- - -{{%children type="card" description="true" %}} diff --git a/content/ja/other/opentelemetry-collector/1-installation/1-confirmation.md b/content/ja/other/opentelemetry-collector/1-installation/1-confirmation.md deleted file mode 100644 index bda894f5ba..0000000000 --- a/content/ja/other/opentelemetry-collector/1-installation/1-confirmation.md +++ /dev/null @@ -1,320 +0,0 @@ ---- -title: OpenTelemetry Collector Contribをインストールする -linkTitle: 1.1 インストールを確認する -weight: 1 ---- - -## Collector が動作していることを確認する - -これで、Collectorが動いているはずです。root権限で `systemctl` コマンドを使って、それを確かめてみましょう。 - -{{< 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 Tue 2023-05-16 08:23:23 UTC; 25s ago - Main PID: 1415 (otelcol-contrib) - Tasks: 5 (limit: 1141) - Memory: 22.2M - CPU: 125ms - CGroup: /system.slice/otelcol-contrib.service - └─1415 /usr/bin/otelcol-contrib --config=/etc/otelcol-contrib/config.yaml - -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: NumberDataPoints #0 -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: Data point attributes: -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: -> exporter: Str(logging) -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: -> service_instance_id: Str(df8a57f4-abdc-46b9-a847-acd62db1001f) -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: -> service_name: Str(otelcol-contrib) -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: -> service_version: Str(0.75.0) -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: StartTimestamp: 2023-05-16 08:23:39.006 +0000 UTC -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: Timestamp: 2023-05-16 08:23:39.006 +0000 UTC -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: Value: 0.000000 -May 16 08:23:39 ip-10-0-9-125 otelcol-contrib[1415]: {"kind": "exporter", "data_type": "metrics", "name": "logging"} -``` - -{{% /tab %}} -{{< /tabs >}} - -{{% notice title="Tips: status表示を中止するには" style="info" %}} -`systemctl status` コマンドの表示を中止するときは `q` キーを押してください。 -{{% /notice %}} - -サービスを停止するときは、 `stop` コマンドを使います。 - -{{< tabs >}} -{{% tab title="Command" %}} - -``` bash -sudo systemctl stop otelcol-contrib -``` - -{{% /tab %}} -{{< /tabs >}} - -更新した設定ファイルを読み込ませるときは、 `restart` コマンドでサービスの再起動をしましょう。 - -{{< tabs >}} -{{% tab title="Command" %}} - -``` bash -sudo systemctl restart otelcol-contrib -``` - -{{% /tab %}} -{{< /tabs >}} - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**Ninja:** Open Telemetry Collector Builder (ocb) を使って、独自のコレクターを作る {{% /badge %}}" %}} - -このパートでは、お使いのシステムに以下のものがインストールされている必要があります - -- Go (latest version) - - ``` 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のインストール - - ocbバイナリーを [project releases](https://github.com/open-telemetry/opentelemetry-collector/releases/tag/cmd%2Fbuilder%2Fv0.80.0) - からダウンロードして、次のコマンドを実行します: - - ```bash - mv ocb_0.80.0_darwin_arm64 /usr/bin/ocb - chmod 755 /usr/bin/ocb - ``` - - 別のアプローチとして、Goのツールチェーンを使ってバイナリをローカルにビルドする方法もあります: - - ```bash - go install go.opentelemetry.io/collector/cmd/builder@v0.80.0 - mv $(go env GOPATH)/bin/builder /usr/bin/ocb - ``` - -- (Optional) Docker - -## なぜ独自のコレクターをビルドするの？ - -コレクターのデフォルトのディストリビューション（coreおよびcontrib）は、含まれれるコンポーネントが少なすぎたり、もしくは多すぎたりします。 - -本番環境でcontribコレクターを実行することはできますが、インストールされているコンポーネントの量が多く、デプロイに必要ではないものも含まれるため、一般的には推奨されません。 - -## 独自のコレクターをビルドする利点は？ - -独自のコレクターバイナリー（通常は「ディストリビューション」と呼ばれる）を作成することで、必要なものだけをビルドすることができます。 - -メリットは次のとおりです: - -1. バイナリーのサイズが小さい -2. 一般的なGoの脆弱性スキャナーを利用できる -3. 組織独自のコンポーネントを組み込むことができる - -## カスタムコレクターをビルドするときの注意事項は？ - -さて、これはNinjaゾーンの人たちにあえて言うことではないかもしれませんが: - -1. Goの開発経験を、必須ではないが、推奨される -1. Splunkの **サポートがない** -1. ディストリビューションのライフサイクルを管理しなければならない - -プロジェクトは安定性に向けて進んでいますが、行われた変更がワークフローを壊す可能性があることに注意してください。Splunkチームは、より高い安定性とサポートを提供し、デプロイメントニーズに対応するためのキュレーションされた経験を提供しています。 - -## Ninja ゾーン - -必要なツールをすべてインストールしたら、以下のディレクトリ構造に従い、 `otelcol-builder.yaml` という新しいファイルを作成します: - -``` bash -. -└── otelcol-builder.yaml -``` - -ファイルを作成したら、インストールするコンポーネントのリストと追加のメタデータを追加する必要があります。 - -この例では、導入設定に必要なコンポーネントのみをインストールするためのビルダーマニフェストを作成します: - -```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 -``` - -最後に、 `./dist/otelcol-ninja` を実行すれば、独自ビルドのCollectorが動作することがわかります。このコマンドを実行する前に、 `otelcol-contrib` サービスが停止していることを確認してください。 - -```shell -./dist/otelcol-ninja --config=file:/etc/otelcol-contrib/config.yaml -``` - - **この設定ファイルで記述されているコンポーネントは、ビルドに含まれていないかもしれません。エラーの内容を含めて、何が起こるかを見てみましょう** 。 - -### リファレンス - -1. [https://opentelemetry.io/docs/collector/custom-collector/](https://opentelemetry.io/docs/collector/custom-collector/) - -{{% /expand %}} - ---- - -## デフォルト設定 - -OpenTelemetry CollectorはYAMLファイルを使って設定をしていきます。これらのファイルには、必要に応じて変更できるデフォルト設定が含まれています。提供されているデフォルト設定を見てみましょう: - -{{< tabs >}} -{{% tab title="Command" %}} - -```bash -cat /etc/otelcol-contrib/config.yaml -``` - -{{% /tab %}} -{{% tab title="config.yaml" %}} - -```yaml { lineNos="table" wrap="true"} -extensions: - health_check: - pprof: - endpoint: 0.0.0.0:1777 - zpages: - endpoint: 0.0.0.0:55679 - -receivers: - otlp: - protocols: - grpc: - http: - - opencensus: - - # 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: - thrift_binary: - thrift_compact: - thrift_http: - - zipkin: - -processors: - batch: - -exporters: - logging: - verbosity: detailed - -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [otlp, opencensus, prometheus] - processors: [batch] - exporters: [logging] - - 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のOpenTelemetry Collectorディストリビューションは本番環境でテスト済みであり、多くの顧客が本番環境で使用しています。 -- このディストリビューションを使用する顧客は、公式のSplunkサポートから、SLAの範囲内で直接支援を受けることができます。 -- メトリクスとトレース収集のコア構成体験に将来的な破壊的変更がないことを心配せずに、SplunkのOpenTelemetry Collectorディストリビューションを使用または移行することができます（OpenTelemetryログ収集の設定はベータ版です）。Collector自身のメトリクスに破壊的変更がある可能性はあります。 - -{{% /notice %}} - -このセクションでは、ホストメトリクスをSplunk Observability Cloudに送信するために、設定ファイルの各セクションを詳しく見ていき、変更する方法について説明します。 diff --git a/content/ja/other/opentelemetry-collector/1-installation/_index.md b/content/ja/other/opentelemetry-collector/1-installation/_index.md deleted file mode 100644 index a44ca397cc..0000000000 --- a/content/ja/other/opentelemetry-collector/1-installation/_index.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: OpenTelemetry Collector Contrib をインストールする -linkTitle: 1. インストール -weight: 1 ---- - -## OpenTelemetry Collector の Contrib ディストリビューションをダウンロードする - -OpenTelemetry Collectorのインストールのために、まずはダウンロードするのが最初のステップです。このラボでは、 `wget` コマンドを使ってOpenTelemetryのGitHubリポジトリから `.deb` パッケージをダウンロードしていきます。 - -[OpenTelemetry Collector Contrib releases page](https://github.com/open-telemetry/opentelemetry-collector-releases/releases) -から、ご利用のプラットフォーム用の `.deb` パッケージを入手してください。 - -``` bash -wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v0.80.0/otelcol-contrib_0.80.0_linux_amd64.deb -``` - -## OpenTelemetry Collector の Contrib ディストリビューションをインストールする - -`dpkg` を使って、 `.deb` パッケージをインストールします。下記の **dpkg Output** のようになれば、インストールは成功です！ - -{{< tabs >}} -{{% tab title="Install" %}} - -``` bash -sudo dpkg -i otelcol-contrib_0.80.0_linux_amd64.deb -``` - -{{% /tab %}} -{{% tab title="dpkg Output" %}} - -``` text -Selecting previously unselected package otelcol-contrib. -(Reading database ... 64218 files and directories currently installed.) -Preparing to unpack otelcol-contrib_0.75.0_linux_amd64.deb ... -Unpacking otelcol-contrib (0.75.0) ... -Setting up otelcol-contrib (0.75.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/other/opentelemetry-collector/2-extensions/1-health.md b/content/ja/other/opentelemetry-collector/2-extensions/1-health.md deleted file mode 100644 index 5403e9d118..0000000000 --- a/content/ja/other/opentelemetry-collector/2-extensions/1-health.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: OpenTelemetry Collector エクステンション -linkTitle: 2.1 Health Check -weight: 1 ---- - -## Health Check エクステンション - -他のコンポーネントと同様に、エクステンションは `config.yaml` ファイルで設定できます。ここでは実際に `config.yaml` ファイルを編集して、エクステンションを設定していきましょう。デフォルトの `config.yaml` では、すでに **pprof** エクステンションと **zpages** エクステンションが設定されていることを確認してみてください。このワークショップでは、設定ファイルをアップデートして **health_check** エクステンションを追加し、ポートを解放し、外部ネットワークからコレクターのヘルスチェックにアクセスできるようにしていきます。 - -{{% 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 %}} - -コレクターを起動します: - -{{% tab title="Command" %}} - -```bash -sudo systemctl restart otelcol-contrib -``` - -{{% /tab %}} - -このエクステンションはHTTPのURLを公開し、OpenTelemetry Collectorの稼働状況をチェックするプローブを提供します。このエクステンションはKubernetes環境でのLiveness/Readinessプローブとしても使われています。 `curl` コマンドの使い方は、[curl man page](https://curl.se/docs/manpage.html) を参照してください。 - -次のコマンドを実行します: - -{{< tabs >}} -{{% tab title="curl Command" %}} - -```bash -curl http://localhost:13133 -``` - -{{% /tab %}} -{{% tab title="curl Output" %}} - -```text -{"status":"Server available","upSince":"2023-04-27T10:11:22.153295874+01:00","uptime":"16m24.684476004s"} -``` - -{{% /tab %}} -{{< /tabs >}} diff --git a/content/ja/other/opentelemetry-collector/2-extensions/2-performance.md b/content/ja/other/opentelemetry-collector/2-extensions/2-performance.md deleted file mode 100644 index cf7227f794..0000000000 --- a/content/ja/other/opentelemetry-collector/2-extensions/2-performance.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: OpenTelemetry Collector エクステンション -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) エクステンションは、Goのnet/http/pprofエンドポイントを有効化します。これは通常、開発者がパフォーマンスプロファイルを収集し、サービスの問題を調査するために使用します。**このワークショップでは詳しく紹介はしません**。 diff --git a/content/ja/other/opentelemetry-collector/2-extensions/3-zpages.md b/content/ja/other/opentelemetry-collector/2-extensions/3-zpages.md deleted file mode 100644 index 72440d8325..0000000000 --- a/content/ja/other/opentelemetry-collector/2-extensions/3-zpages.md +++ /dev/null @@ -1,355 +0,0 @@ ---- -title: OpenTelemetry Collector エクステンション -linkTitle: 2.3 zPages -weight: 3 ---- - -## zPages エクステンション - -[**zPages**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/extension/zpagesextension/README.md) は、外部エクスポータに代わるプロセス内部の機能です。有効化すると、バックグラウンドでトレースとメトリクス情報を収集し、集計し、どのようなデータを扱ったかのWebページを公開します。zpagesは、コレクターが期待どおりに動作していることを確認するための非常に便利な診断機能です。 - -{{< tabs >}} -{{% tab title="ServiceZ" %}} - -**ServiceZ** は、コレクターサービスの概要と、pipelinez、extensionz、featurez zPagesへのクイックアクセスを提供します。このページでは、ビルドとランタイムの情報も提供します。 - -URL: [http://localhost:55679/debug/servicez](http://localhost:55679/debug/servicez) (`localhost` は、適切なホスト名に切り替えてください) - -![ServiceZ](../../images/servicez.png) - -{{% /tab %}} -{{% tab title="PipelineZ" %}} - -**PipelineZ** は、コレクターで実行中のパイプラインに関する情報を提供します。タイプ、データが変更されているか、各パイプラインで使用されているレシーバー、プロセッサー、エクスポーターの情報を見ることができます。 - -URL: [http://localhost:55679/debug/pipelinez](http://localhost:55679/debug/pipelinez) (`localhost` は、適切なホスト名に切り替えてください) - -![PipelineZ](../../images/pipelinez.png) - -{{% /tab %}} -{{% tab title="ExtensionZ" %}} - -**ExtensionZ** は、コレクターで有効化されたエクステンションを確認できます。 - -Example URL: [http://localhost:55679/debug/extensionz](http://localhost:55679/debug/extensionz) (`localhost` は、適切なホスト名に切り替えてください) - -![ExtensionZ](../../images/extensionz.png) - -{{% /tab %}} -{{% /tabs %}} - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**Ninja:** storageエクステンションでデータの耐久性を向上させる{{% /badge %}}" %}} - -これをこなうには、ディストリビューションに `file_storage` エクステンションモジュールがインストールされていることを確認する必要があります。確認するには、`otelcol-contrib components` コマンドを実行します: - -{{< tabs >}} -{{% tab title="Command" %}} - -```bash -otelcol-contrib components -``` - -{{% /tab %}} -{{% 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 >}} - -このエクステンションは、エクスポーターが設定されたエンドポイントにデータを送信できない事象が発生したときに、データをディスクにキューイングする機能をエクスポーターに提供します。 - -このエクステンションを設定するには、以下の情報を含むように設定を更新する必要があります。まず、 /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] -``` - -## なぜキューデータをディスクに書くの？ - -コレクターはネットワークの不調（および、コレクターの再起動）を乗り切って、アップストリームプロバイダーに確実にデータを送信できるようになります。 - -## キューデータをディスクに書く時の注意事項は？ - -ディスクの性能により、データスループットの性能に影響を与える可能性があります - -### 参照 - -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 %}} - ---- - -## 設定を確認しましょう - -さて、エクステンションについて説明したので、設定の変更箇所を確認していきましょう。 - ---- - -{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定ファイルを確認してください{{% /badge %}}" %}} -{{< tabs >}} -{{% tab title="config.yaml" %}} - -```yaml { lineNos="table" wrap="true" hl_lines="3" } -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: - http: - - opencensus: - - # 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: - thrift_binary: - thrift_compact: - thrift_http: - - zipkin: - -processors: - batch: - -exporters: - logging: - verbosity: detailed - -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [otlp, opencensus, prometheus] - processors: [batch] - exporters: [logging] - - extensions: [health_check, pprof, zpages] -``` - -{{% /tab %}} -{{< /tabs >}} -{{% /expand %}} - ---- - -さて、エクステンションについて復習したところで、ワークショップのデータパイプラインの部分に飛び込んでみましょう。パイプラインとは、コレクター内でデータがたどる経路を定義するもので、レシーバーから始まり、追加の処理や変更をし、最終的にエクスポーターを経由してコレクターを出ます。 - -OpenTelemetry Collectorのデータパイプラインは、レシーバー、プロセッサー、エクスポーターで構成されています。まずは、レシーバーから見ていきましょう。 diff --git a/content/ja/other/opentelemetry-collector/2-extensions/_index.md b/content/ja/other/opentelemetry-collector/2-extensions/_index.md deleted file mode 100644 index 42d4819783..0000000000 --- a/content/ja/other/opentelemetry-collector/2-extensions/_index.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: OpenTelemetry Collector エクステンション -linkTitle: 2. エクステンション -weight: 2 ---- - -さて、OpenTelemetry Collectorはインストールできました。次はOpenTelemetry Collectorのエクステンション（拡張機能）を見てみましょう。エクステンションはオプションで、主にテレメトリーデータの処理を伴わないタスクで使用できます。例としては、ヘルスモニタリング、サービスディスカバリ、データ転送などがあります。 - -{{< mermaid >}} -%%{ - init:{ - "themeVariables": { - "primaryColor": "#ffffff", - "clusterBkg": "#eff2fb", - "defaultLinkColor": "#333333" - } - } -}%% - -flowchart LR; - style E fill:#e20082,stroke:#333,stroke-width:4px,color:#fff - subgraph Receivers - 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/other/opentelemetry-collector/3-receivers/1-hostmetrics.md b/content/ja/other/opentelemetry-collector/3-receivers/1-hostmetrics.md deleted file mode 100644 index 1e2a0ef47b..0000000000 --- a/content/ja/other/opentelemetry-collector/3-receivers/1-hostmetrics.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: OpenTelemetry Collector レシーバー -linkTitle: 1. Host Metrics -weight: 1 ---- - -## Host Metrics レシーバー - -[**Host Metrics レシーバー**](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/README.md) は、さまざまなソースからスクレイピングされたホストシステムに関するメトリクスを生成します。これは、コレクターがエージェントとしてデプロイされるときに使用さます。 - -`etc/otel-contrib/config.yaml` ファイルを更新して、**hostmetrics** レシーバーを設定してみましょう。以下のYAMLを **receivers** セクションの下に挿入します。 - -``` bash -sudo vi /etc/otelcol-contrib/config.yaml -``` - -{{% notice title="Tips: vi or nano" style="info" %}} -vi/vimの操作に慣れていない場合は、[nano](https://www.nano-editor.org/) もお試しいただくと良いかもしれません。nanoはLinux環境でよく使われる、シンプルなエディタの一つです。 - -``` bash -sudo nano /etc/otelcol-contrib/config.yaml -``` - -* `Alt-U` で、アンドゥができます。Macの場合は `Esc` キーを押したあとに `U` を押してください！ -* `ctrl-_` のあとに数字を入力すると、指定した行数にジャンプします。 -* `ctrl-O` のあとに `Enter` で、ファイルを保存します。 -* `ctrl-X` で、nanoを終了します。 - -{{% /notice %}} - -{{% 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/other/opentelemetry-collector/3-receivers/2-prometheus.md b/content/ja/other/opentelemetry-collector/3-receivers/2-prometheus.md deleted file mode 100644 index 1fbf3aec11..0000000000 --- a/content/ja/other/opentelemetry-collector/3-receivers/2-prometheus.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: OpenTelemetry Collector レシーバー -linkTitle: 2. Prometheus -weight: 2 ---- - -## Prometheus レシーバー - -**Prometheus** のレシーバーも、もちろんあります。[Prometheus](https://prometheus.io/docs/introduction/overview/) はOpenTelemetry Collectorで使われているオープンソースのツールキットです。このレシーバーは、OpenTelemetry Collector自身からメトリクスをスクレイピングするためにも使われます。これらのメトリクスは、コレクタの健全性をモニタリングするために使用できる。 - -ここでは、**prometheus** レシーバーを変更して、コレクター自身からメトリクスを収集できるようにしてみます。レシーバーの名前を **prometheus** から **prometheus/internal** に変更して、レシーバーが何をしているのかをより明確しましょう。設定ファイルを以下のように更新します - -{{% 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 %}} - - -上記の設定では、OpenTelemetry Collector自身が公開しているPrometheusエンドポイントをスクレイピングしています。どのような情報が得られるか、`curl` コマンドで試すことができます: - -```bash -curl http://localhost:8888/metrics -``` - - -{{% notice title="Tips: コンポーネントに名前をつける" style="info" %}} -レシーバー、プロセッサー、エクスポーター、パイプラインなどのコンポーネントは、 `otlp` や `otlp/2` のように、 `type[/name]` 形式に従った識別子によって定義されます。識別子が一意である限り、与えられたタイプのコンポーネントを複数回定義することができるようになります。 - -ここでは `prometheus/internal` という識別子でこのコンポーネントを特定できるようにしたので、別の `prometheus` レシーバーを追加して、監視対象インスタンスのPrometheusエンドポイントをスクレイピングさせることもできます。 -{{% /notice %}} - - -## ダッシュボード例 - Prometheus メトリクス - -このスクリーンショットは、 `prometheus/internal` レシーバーがOpenTelemetry Collectorから収集したメトリクスの、spmeのダッシュボードの例です。ここではスパン・メトリクス・ログの、それぞれの受信および送信の様子を見ることができます。 - -{{% notice style="note" %}} -このダッシュボードはSplunk Observability Cloudにある組み込みダッシュボードで、Splunk OpenTelemetry Collectorのインストールの状況を簡単にモニタリングできます。 -{{% /notice %}} - - -![otel-charts](../../images/otel-charts.png) diff --git a/content/ja/other/opentelemetry-collector/3-receivers/3-other-receivers.md b/content/ja/other/opentelemetry-collector/3-receivers/3-other-receivers.md deleted file mode 100644 index 78158345a5..0000000000 --- a/content/ja/other/opentelemetry-collector/3-receivers/3-other-receivers.md +++ /dev/null @@ -1,154 +0,0 @@ ---- -title: OpenTelemetry Collector レシーバー -linkTitle: 3. その他のレシーバー -weight: 3 ---- - -## その他のレシーバー - -デフォルトの設定には、他のレシーバーがあることに気づくはずです。 **[otlp](https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/otlpreceiver)**、**[opencensus](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/opencensusreceiver)**、**[jaeger](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/jaegerreceiver)**、**[zipkin](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/zipkinreceiver)** が定義されています。これらは他のソースからテレメトリーデータを受信するために使われます。このワークショップでは、これらのレシーバーについては取り上げませんので、そのままにしておきましょう。 - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**Ninja:** レシーバーを動的に生成する{{% /badge %}}" %}} - -dockerコンテナ、kubernetesポッド、sshセッションのような短時間のタスクを観測するために、[receiver creator](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/receivercreator) レシーバーと [observer](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/observer) エクステンションを使って、対象のサービスが起動するタイミングで新しいレシーバーを作成することができます。 - -## 何が必要なの？ - -receiver creatorとそれに関連するobserverエクステンションの使用を開始するには、collector build manifestに追加する必要があります。 - -詳細は [installation](../1-installation/) を参照してください。 - -## 注意事項はある？ - -短命なタスクの中には、_username_ や _password_ のような追加設定を必要とするものがあります。それらの値は[環境変数](https://opentelemetry.io/docs/collector/configuration/#configuration-environment-variables) を参照したり、 `${file:./path/to/database/password}` のようなスキーム展開構文を使うこともできます。 - -組織における機密情報の取り扱い規定に従って、どのような方法を取るかを検討してください。 - -## Ninja ゾーン - -このNinjaゾーンに必要なものは2つだけです: - -1. builder manifestに、 receiver creatorレシーバーとobserverエクステンションを追加する -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 %}} - ---- - -## 設定を確認しましょう - -これで、レシーバーをカバーできました。ここで、設定のの変更内容をチェックしてみましょう。 - ---- - -{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定をレビューしてください{{% /badge %}}" %}} -{{< tabs >}} -{{% tab title="config.yaml" %}} - -```yaml {lineNos="table" wrap="true" hl_lines="10-30 39"} -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: - http: - - opencensus: - - # 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: - thrift_binary: - thrift_compact: - thrift_http: - - zipkin: - -processors: - batch: - -exporters: - logging: - verbosity: detailed - -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [otlp, opencensus, prometheus/internal] - processors: [batch] - exporters: [logging] - - extensions: [health_check, pprof, zpages] -``` - -{{% /tab %}} -{{< /tabs >}} -{{% /expand %}} - ---- - -これで、レシーバーを通してOpenTelemetry Collectorにデータがどのように取り込まれるかを確認しました。次に、コレクターが受信したデータをどのように処理するかを見てみましょう。 - -{{% notice style="warning" %}} -**ここではコレクターを再起動しないでください**！　 `/etc/otelcol-contrib/config.yaml` の変更はまだ完了していません。 -{{% /notice %}} diff --git a/content/ja/other/opentelemetry-collector/3-receivers/_index.md b/content/ja/other/opentelemetry-collector/3-receivers/_index.md deleted file mode 100644 index 7c37c8d817..0000000000 --- a/content/ja/other/opentelemetry-collector/3-receivers/_index.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: OpenTelemetry Collector レシーバー -linkTitle: 3. レシーバー -weight: 3 ---- - -レシーバーワークショップへようこそ！OpenTelemetry Collectorのデータパイプラインのスタート地点です。さあ、始めましょう。 - -レシーバーはデータをCollectorに取り込む方法で、プッシュベースとプルベースのものがあります。レシーバーは1つ以上のデータソースをサポートします。一般的に、レシーバーは指定されたフォーマットでデータを受け入れ、内部フォーマットに変換し、該当するパイプラインで定義されたプロセッサやエクスポータにデータを渡します。 - -プッシュまたはプルベースのレシーバは、データをCollectorに取り込む方法です。レシーバは1つまたは複数のデータソースをサポートします。通常、レシーバは指定されたフォーマットでデータを受け入れ、内部フォーマットに変換し、該当するパイプラインで定義されたプロセッサーやエクスポーターにデータを渡します。 - -{{< mermaid >}} -%%{ - init:{ - - "themeVariables": { - "primaryColor": "#ffffff", - "clusterBkg": "#eff2fb", - "defaultLinkColor": "#333333" - } - } -}%% - -flowchart LR; - style M fill:#e20082,stroke:#333,stroke-width:4px,color:#fff - subgraph Receivers - 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/other/opentelemetry-collector/4-processors/1-batch-processor.md b/content/ja/other/opentelemetry-collector/4-processors/1-batch-processor.md deleted file mode 100644 index 681cf88f3d..0000000000 --- a/content/ja/other/opentelemetry-collector/4-processors/1-batch-processor.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: OpenTelemetry Collector プロセッサー -linkTitle: 4.1 Batch -weight: 1 ---- - -## Batch プロセッサー - -デフォルトでは、**batch** プロセッサーだけが有効になっています。このプロセッサーは、データをエクスポートする前にバッチ処理して、エクスポーターへのネットワーク・コールの回数を減らすために使われます。このワークショップではデフォルトの設定を使用します - -- `send_batch_size` (デフォルト = 8192): タイムアウトに関係なく、バッチを送信するスパン、メトリクスデータポイント、またはログレコードの数。パイプラインの次のコンポーネントに送信されるバッチサイズを制限する場合には、 `send_batch_max_size` を使います。 -- `timeout` (デフォルト = 200ms): サイズに関係なく、バッチが送信されるまでの時間。ゼロに設定すると、`send_batch_size` の設定を無視して `send_batch_max_size` だけが適用され、データは直ちに送信されます。 -- `send_batch_max_size` (デフォルト = 0): バッチサイズの上限。`0` を設定すると、バッチサイズの上限がないことして扱われます。この設定は、大きなバッチが小さなユニットに分割されることを保証します。`send_batch_size` 以上でなければななりません。 diff --git a/content/ja/other/opentelemetry-collector/4-processors/2-resource-detection.md b/content/ja/other/opentelemetry-collector/4-processors/2-resource-detection.md deleted file mode 100644 index 2b500bb5bb..0000000000 --- a/content/ja/other/opentelemetry-collector/4-processors/2-resource-detection.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: OpenTelemetry Collector プロセッサー -linkTitle: 4.2 Resource Detection -weight: 2 ---- - -## Resource Detection プロセッサー - -**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 %}} - -If the workshop instance is running on an AWS/EC2 instance we can gather the following tags from the EC2 metadata API (this is not available on other platforms). -ワークショップのインスタンスが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` - -これらのタグをメトリクスに追加するために、別のプロセッサーとして定義してみましょう。 - -{{% 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/other/opentelemetry-collector/4-processors/3-attributes.md b/content/ja/other/opentelemetry-collector/4-processors/3-attributes.md deleted file mode 100644 index a7ed385c7f..0000000000 --- a/content/ja/other/opentelemetry-collector/4-processors/3-attributes.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -title: OpenTelemetry Collector プロセッサー -linkTitle: 4.3 Attributes -weight: 3 ---- - -## Attributes プロセッサー - -attributeプロセッサーを使うと、スパン、ログ、またはメトリクスの属性を変更できます。また、このプロセッサーは、入力データをフィルタリングし、マッチさせ、指定されたアクションに含めるべきか、除外すべきかを決定する機能もサポートしています。 - -アクションを設定するには、指定された順序で実行されるアクションのリストを記述します。サポートされるアクションは以下の通りです - -- `insert`: その属性がない場合に、新しい属性値を挿入します。 -- `update`: その属性がある場合に、その属性値を更新します。 -- `upsert`: insertまたはupdateを実行します。属性がない場合には新しい属性値を挿入し、属性がある場合にはその値を更新します。 -- `delete`: 入力データから属性値を削除します。 -- `hash`: 属性値をハッシュ化 (SHA1) します。 -- `extract`: 入力キーの値を正規表現ルールを使って抽出し、対象キーの値を更新します。対象キーがすでに存在する場合は、その値は上書きされます。 - -次の例のように、attributeプロセッサーを使って、キーは `participant.name`、あたいはあなたの名前（例: `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=star %}}**Ninja:** コネクターを使って内部への洞察を加速する{{% /badge %}}" %}} - -最近追加されたものの一つとして、[connector](https://opentelemetry.io/docs/collector/configuration/#connectors) というコンセプトがあります。これを使うと、あるパイプラインの出力を別のパイプラインの入力に結合できるようになります。 - -利用シーンとして、送信するデータポイントの量、エラーステータスを含むログの数をメトリクスをとして出力するサービスがあります。他には、あるデプロイ環境から送信されるデータ量のメトリクスを生成するサービスがあります。このような場合に、countコネクターですぐに対応できます。 - -## プロセッサーではなくコネクターなのはなぜ？ - -プロセッサーは、処理したデータを次に渡すものであり、追加の情報を出力することはできません。コネクターはレシーバーで受け取ったデータを出力せずに、私たちが求める洞察を作り出す機会を提供します。 - -たとえば、countコネクターを使うと、環境変数 `deployment` を持たないログ、メトリクス、トレースの数をカウントすることができます。 - -また、非常にシンプルな例として、`deployment` 別にデータ使用量を分解して出力することもできます。 - -## コネクターの注意事項 - -コネクターは、あるパイプラインからエクスポートされ、別のパイプラインでレシーバーで定義されたデータのみを受け入れます。コレクターをどう構築してどう利用するか、設定を検討する必要があります。 - -## 参照 - -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 %}} - ---- - -## 設定を確認しましょう - -これで、プロセッサーがカバーできました。ここで、設定のの変更内容をチェックしてみましょう。 - ---- - -{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定をレビューしてください{{% /badge %}}" %}} -{{< tabs >}} -{{% tab title="config.yaml" %}} - -```yaml {lineNos="table" wrap="true" hl_lines="58-68"} -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: - http: - - opencensus: - - # 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: - thrift_binary: - thrift_compact: - thrift_http: - - zipkin: - -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: - logging: - verbosity: detailed - -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [otlp, opencensus, prometheus] - processors: [batch] - exporters: [logging] - - extensions: [health_check, pprof, zpages] -``` - -{{% /tab %}} -{{< /tabs >}} -{{% /expand %}} - ---- diff --git a/content/ja/other/opentelemetry-collector/4-processors/_index.md b/content/ja/other/opentelemetry-collector/4-processors/_index.md deleted file mode 100644 index 64a8415463..0000000000 --- a/content/ja/other/opentelemetry-collector/4-processors/_index.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: OpenTelemetry Collector プロセッサー -linkTitle: 4. プロセッサー -weight: 4 ---- - - -[**プロセッサー**](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/README.md)は、レシーバーとエクスポーターとの間で、データに対して実行される処理です。プロセッサーはオプションですが、いくつかは推奨されています。OpenTelemetry Collector Contribには[多数のプロセッサー](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor)が含まれています。 - -{{< mermaid >}} -%%{ - init:{ - - "themeVariables": { - "primaryColor": "#ffffff", - "clusterBkg": "#eff2fb", - "defaultLinkColor": "#333333" - } - } -}%% - -flowchart LR; - style Processors fill:#e20082,stroke:#333,stroke-width:4px,color:#fff - subgraph Receivers - 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/other/opentelemetry-collector/5-exporters/_index.md b/content/ja/other/opentelemetry-collector/5-exporters/_index.md deleted file mode 100644 index c7f45f3ed7..0000000000 --- a/content/ja/other/opentelemetry-collector/5-exporters/_index.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: OpenTelemetry Collector エクスポーター -linkTitle: 5. エクスポーター -weight: 5 ---- - -エクスポーターは、プッシュまたはプルベースであり、一つ以上のバックエンド/デスティネーションにデータを送信する方法です。エクスポーターは、一つまたは複数のデータソースをサポートすることがあります。 - -このワークショップでは、[**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:{ - - "themeVariables": { - "primaryColor": "#ffffff", - "clusterBkg": "#eff2fb", - "defaultLinkColor": "#333333" - } - } -}%% - -flowchart LR; - style Exporters fill:#e20082,stroke:#333,stroke-width:4px,color:#fff - subgraph Receivers - 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/other/opentelemetry-collector/5-exporters/otlphttp.md b/content/ja/other/opentelemetry-collector/5-exporters/otlphttp.md deleted file mode 100644 index 9a685ac8f1..0000000000 --- a/content/ja/other/opentelemetry-collector/5-exporters/otlphttp.md +++ /dev/null @@ -1,183 +0,0 @@ ---- -title: OpenTelemetry Collector エクスポーター -linkTitle: 5.1 OTLP HTTP -weight: 1 ---- - -## OTLP HTTP エクスポーター - -Splunk Observability CloudへHTTP経由でメトリックスを送信するためには、**otlphttp** エクスポーターを設定する必要があります。 - -`/etc/otelcol-contrib/config.yaml` ファイルを編集し、**otlphttp** エクスポーターを設定しましょう。以下のYAMLを **exporters** セクションの下に挿入し、例えば2スペースでインデントしてください。 - -また、ディスクの容量不足を防ぐために、ロギングエクスポーターの詳細度を変更します。デフォルトの `detailed` は非常に詳細です。 - -```yaml {hl_lines="3-4"} -exporters: - logging: - 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** エクスポーターは、`traces_endpoint` と `logs_endpoint` それぞれのターゲットURLを定義することにより、トレースとログを送信するようにも設定できますが、そのような設定はこのワークショップの範囲外とします。 - -```yaml {hl_lines="5"} -exporters: - logging: - verbosity: normal - otlphttp/splunk: - metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp -``` - -デフォルトでは、すべてのエンドポイントで `gzip` 圧縮が有効になっています。エクスポーターの設定で `compression: none` を設定することにより、圧縮を無効にすることができます。このワークショップでは圧縮を有効にしたままにし、データを送信する最も効率的な方法としてデフォルト設定を使っていきます。 - -Splunk Observability Cloudにメトリクスを送信するためには、アクセストークンを使用する必要があります。これは、Splunk Observability Cloud UIで新しいトークンを作成することにより行うことができます。トークンの作成方法についての詳細は、[Create a token](https://docs.splunk.com/Observability/admin/authentication-tokens/org-tokens.html) を参照してください。トークンは **INGEST** タイプである必要があります。 - -{{% notice style="note" %}} -Splunk主催のワークショップの参加者である場合、使用しているインスタンスにはすでにアクセストークンが設定されています（環境変数として設定されています）ので、その環境変数を設定ファイルで参照します。それ以外の場合は、新しいトークンを作成し、それを環境変数として設定する必要があります。例えば - -``` bash -export ACCESS_TOKEN= -``` - -{{% /notice %}} - -トークンは、設定ファイル内で `headers:` セクションの下に `X-SF-TOKEN: ${env:ACCESS_TOKEN}` を挿入することにで定義します - -```yaml {hl_lines="6-8"} -exporters: - logging: - verbosity: normal - otlphttp/splunk: - metrics_endpoint: https://ingest.${env:REALM}.signalfx.com/v2/datapoint/otlp - headers: - X-SF-TOKEN: ${env:ACCESS_TOKEN} -``` - -## 設定を確認しましょう - -これで、エクスポーターもカバーできました。設定を確認していきましょう - ---- - -{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}設定をレビューしてください{{% /badge %}}" %}} -{{< tabs >}} -{{% tab title="config.yaml" %}} - -```yaml {lineNos="table" wrap="true" hl_lines="72-76"} -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: - http: - - opencensus: - - # 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: - thrift_binary: - thrift_compact: - thrift_http: - - zipkin: - -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: - logging: - 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: [logging] - - metrics: - receivers: [otlp, opencensus, prometheus] - processors: [batch] - exporters: [logging] - - extensions: [health_check, pprof, zpages] -``` - -{{% /tab %}} -{{< /tabs >}} -{{% /expand %}} - ---- - -もちろん、**OTLP** プロトコルをサポートする他のソリューションを指すように `metrics_endpoint` を簡単に設定することができます。 - -次に、`config.yaml` のサービスセクションで、今設定したレシーバー、プロセッサー、エクスポーターを有効にしていきます。 diff --git a/content/ja/other/opentelemetry-collector/6-service/1-hostmetrics.md b/content/ja/other/opentelemetry-collector/6-service/1-hostmetrics.md deleted file mode 100644 index 4a78edd39f..0000000000 --- a/content/ja/other/opentelemetry-collector/6-service/1-hostmetrics.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector サービス -linkTitle: 6.1 Host Metrics -weight: 1 ---- - -## Hostmetrics レシーバー - -ワークショップのレシーバー部分で振り返ると、ホストシステムに関するメトリクスを生成するために、様々なソースからスクレイピングする [Host Metrics](../3-receivers/#host-metrics-receiver) レシーバーを定義しました。このレシーバーを有効にするためには、メトリクスパイプラインに `hostmetrics` レシーバーを含める必要があります。 - -`metrics` パイプラインで、メトリクスの `receivers` セクションに `hostmetrics` を追加します。 - -```yaml {hl_lines="11"} -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [hostmetrics, otlp, opencensus, prometheus] - processors: [batch] - exporters: [logging] -``` diff --git a/content/ja/other/opentelemetry-collector/6-service/2-prometheus.md b/content/ja/other/opentelemetry-collector/6-service/2-prometheus.md deleted file mode 100644 index 7ab0327112..0000000000 --- a/content/ja/other/opentelemetry-collector/6-service/2-prometheus.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector サービス -linkTitle: 6.2 Prometheus -weight: 2 ---- - -## Prometheus Internal レシーバー - -ワークショップの前半で、`prometheus` レシーバーの名前を変更し、コレクター内部のメトリクスを収集していることを反映して、`prometheus/internal` という名前にしました。 - -現在、メトリクスパイプラインの下で `prometheus/internal` レシーバーを有効にする必要があります。`metrics` パイプラインの下の `receivers` セクションを更新して、`prometheus/internal` を含めます - -```yaml {hl_lines="11"} -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [hostmetrics, otlp, opencensus, prometheus/internal] - processors: [batch] - exporters: [logging] -``` diff --git a/content/ja/other/opentelemetry-collector/6-service/3-resourcedetection.md b/content/ja/other/opentelemetry-collector/6-service/3-resourcedetection.md deleted file mode 100644 index f6fbd5b97a..0000000000 --- a/content/ja/other/opentelemetry-collector/6-service/3-resourcedetection.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector サービス -linkTitle: 6.3 Resource Detection -weight: 3 ---- - -## Resource Detection プロセッサー - -また、コレクターがインスタンスのホスト名やAWS/EC2のメタデータを取得できるように、`resourcedetection/system` および `resourcedetection/ec2` プロセッサーを追加しました。これらのプロセッサーをメトリクスパイプライン下で有効にする必要があります。 - -`metrics` パイプラインの下の `processors` セクションを更新して、`resourcedetection/system` および `resourcedetection/ec2` を追加します - -```yaml {hl_lines="12"} -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [hostmetrics, otlp, opencensus, prometheus/internal] - processors: [batch, resourcedetection/system, resourcedetection/ec2] - exporters: [logging] -``` diff --git a/content/ja/other/opentelemetry-collector/6-service/4-attributes.md b/content/ja/other/opentelemetry-collector/6-service/4-attributes.md deleted file mode 100644 index 45c956a96b..0000000000 --- a/content/ja/other/opentelemetry-collector/6-service/4-attributes.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector サービス -linkTitle: 6.4 Attributes -weight: 4 ---- - -## Attributes プロセッサー - -また、このワークショップのプロセッサーセクションでは、`attributes/conf` プロセッサーを追加し、コレクターがすべてのメトリクスに `participant.name` という新しい属性を挿入するようにしました。これをメトリクスパイプライン下で有効にする必要があります。 - -`metrics` パイプラインの下の `processors` セクションを更新して、`attributes/conf` を追加します - -```yaml {hl_lines="12"} -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [hostmetrics, otlp, opencensus, prometheus/internal] - processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf] - exporters: [logging] -``` diff --git a/content/ja/other/opentelemetry-collector/6-service/5-otlphttp.md b/content/ja/other/opentelemetry-collector/6-service/5-otlphttp.md deleted file mode 100644 index f670b37aa6..0000000000 --- a/content/ja/other/opentelemetry-collector/6-service/5-otlphttp.md +++ /dev/null @@ -1,246 +0,0 @@ ---- -title: OpenTelemetry Collector サービス -linkTitle: 6.5 OTLP HTTP -weight: 5 ---- - -## OTLP HTTP エクスポーター - -ワークショップのエクスポーターセクションでは、`otlphttp` エクスポーターを設定して、メトリクスをSplunk Observability Cloudに送信するようにしました。これをメトリクスパイプライン下で有効にする必要があります。 - -`metrics` パイプラインの下の `exporters` セクションを更新して、`otlphttp/splunk` を追加します - -```yaml {hl_lines="13"} -service: - - pipelines: - - traces: - receivers: [otlp, opencensus, jaeger, zipkin] - processors: [batch] - exporters: [logging] - - metrics: - receivers: [hostmetrics, otlp, opencensus, prometheus/internal] - processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf] - exporters: [logging, otlphttp/splunk] -``` - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**Ninja:** コレクターの内部を観測する{{% /badge %}}" %}} - -コレクターは、その動作に関する内部シグナルを捕捉しています。これには実行中のコンポーネントからの追加されるシグナルも含まれます。これは、データの流れに関する決定を行うコンポーネントが、その情報をメトリクスやトレースとして表面化する方法を必要とするためです。 - -## なぜコレクターを監視するの？ - -これは「監視者を監視するのは誰か？」という種類の問題ですが、このような情報を表面化できることは重要です。コレクターの歴史の興味深い部分は、GoメトリクスのSDKが安定と考えられる前に存在していたことで、コレクターは当面の間、この機能を提供するためにPrometheusエンドポイントを公開しています。 - -## 注意点 - -組織内で稼働している各コレクターの内部使用状況を監視することは、新しいメトリクス量（MTS）を大幅な増加させる可能性があります。Splunkディストリビューションはこれらのメトリクスをキュレーションしており、増加を予測するのに役立ちます。 - -## Ninja ゾーン - -コレクターの内部オブザーバビリティを公開するためには、いくつかの設定を追加することがあります - -{{< 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" hl_lines="88-90"} -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: - http: - - opencensus: - - # 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: - thrift_binary: - thrift_compact: - thrift_http: - - zipkin: - -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: - logging: - 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: [logging] - - metrics: - receivers: [hostmetrics, otlp, opencensus, prometheus/internal] - processors: [batch, resourcedetection/system, resourcedetection/ec2, attributes/conf] - exporters: [logging, otlphttp/splunk] - - extensions: [health_check, pprof, zpages] -``` - -{{% /tab %}} -{{% /tabs %}} - -{{% /expand %}} - ---- - -{{% notice style="tip" %}} -コレクターを再起動する前に、設定ファイルを検証することをお勧めします。これは、組み込みの `validate` コマンドを使用して行うことができます - -{{< tabs >}} -{{% tab title="Command" %}} - -``` bash -otelcol-contrib validate --config=file:/etc/otelcol-contrib/config.yaml -``` - -{{% /tab %}} -{{% tab title="Example error output" %}} - -``` text -Error: failed to get config: cannot unmarshal the configuration: 1 error(s) decoding: - -* error decoding 'processors': error reading configuration for "attributes/conf": 1 error(s) decoding: - -* 'actions[0]' has invalid keys: actions -2023/06/29 09:41:28 collector server run finished with error: failed to get config: cannot unmarshal the configuration: 1 error(s) decoding: - -* error decoding 'processors': error reading configuration for "attributes/conf": 1 error(s) decoding: - -* 'actions[0]' has invalid keys: actions -``` - -{{% /tab %}} -{{< /tabs >}} -{{% /notice %}} - -動作する設定ができたので、コレクターを起動し、その後 [zPages](../2-extensions/#zpages) が報告している内容を確認しましょう。 - -{{% tab title="Command" %}} - -``` bash -sudo systemctl restart otelcol-contrib -``` - -{{% /tab %}} - -![pipelinez-full-config](../../images/pipelinez-full-config.png) diff --git a/content/ja/other/opentelemetry-collector/6-service/_index.md b/content/ja/other/opentelemetry-collector/6-service/_index.md deleted file mode 100644 index 51f3e596e6..0000000000 --- a/content/ja/other/opentelemetry-collector/6-service/_index.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: OpenTelemetry Collector サービス -linkTitle: 6. サービス -weight: 6 ---- - -**Service** セクションでは、レシーバー、プロセッサー、エクスポーター、およびエクステンションにある設定に基づいて、コレクターで有効にするコンポーネントを設定していきます。 - - -{{% notice style="info" %}} -コンポーネントが設定されていても、**Service** セクション内で定義されていない場合、そのコンポーネントは**有効化されません**。 -{{% /notice %}} - -サービスのセクションは、以下の3つのサブセクションで構成されています - -- extensions（拡張機能） -- pipelines（パイプライン） -- telemetry（テレメトリー） - -デフォルトの設定では、拡張機能セクションが `health_check`、`pprof`、`zpages` を有効にするように設定されており、これらは以前のエクステンションのモジュールで設定しました。 - -``` yaml -service: - extensions: [health_check, pprof, zpages] -``` - -それでは、メトリックパイプラインを設定していきましょう！ diff --git a/content/ja/other/opentelemetry-collector/7-visualisation/index.files/dashboard_OTel-Contrib-Dashboard.json b/content/ja/other/opentelemetry-collector/7-visualisation/index.files/dashboard_OTel-Contrib-Dashboard.json deleted file mode 100644 index 672c86cad5..0000000000 --- a/content/ja/other/opentelemetry-collector/7-visualisation/index.files/dashboard_OTel-Contrib-Dashboard.json +++ /dev/null @@ -1,1418 +0,0 @@ -{ - "chartExports": [ - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "FybsAETAwAI", - "importOf": "FwPCYY8AIB0", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Disk free", - "options": { - "colorBy": "Dimension", - "colorScale2": null, - "hideMissingValues": false, - "legendOptions": { - "fields": [ - { - "enabled": false, - "property": "dsname" - }, - { - "enabled": false, - "property": "host" - }, - { - "enabled": false, - "property": "sf_originatingMetric" - }, - { - "enabled": false, - "property": "sf_metric" - }, - { - "enabled": false, - "property": "plugin" - }, - { - "enabled": true, - "property": "plugin_instance" - }, - { - "enabled": false, - "property": "fs_type" - }, - { - "enabled": false, - "property": "device" - }, - { - "enabled": true, - "property": "mountpoint" - }, - { - "enabled": true, - "property": "os.type" - }, - { - "enabled": true, - "property": "type" - }, - { - "enabled": true, - "property": "mode" - }, - { - "enabled": true, - "property": "state" - }, - { - "enabled": false, - "property": "host.id" - }, - { - "enabled": false, - "property": "participant.name" - }, - { - "enabled": false, - "property": "my.name" - } - ] - }, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Used bytes", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "Sparkline", - "sortBy": "-value", - "time": { - "range": 900000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "List", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.filesystem.usage', filter=filter('state', 'free')).publish(label='A')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "FybsAETAwAM", - "importOf": "FwPCYY8AIBk", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "CPU Load Average (1m)", - "options": { - "colorBy": "Dimension", - "colorScale": null, - "colorScale2": null, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "system.cpu.load_average.1m", - "label": "A", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "None", - "showSparkLine": false, - "time": { - "range": 300000, - "rangeEnd": 0, - "type": "relative" - }, - "timestampHidden": true, - "type": "SingleValue", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.cpu.load_average.1m').publish(label='A')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "Page swaps/sec", - "id": "FybsAETAwAQ", - "importOf": "FwPCYY8AIBo", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Memory Paging", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Page in - RED", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Page out - BLUE", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - } - ], - "axisPrecision": null, - "colorBy": "Dimension", - "defaultPlotType": "LineChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": null, - "showLegend": false - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Page In", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Page Out", - "label": "B", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 1 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.paging.operations', filter=filter('direction', 'page_in'), rollup='delta').publish(label='A')\nB = data('system.paging.operations', filter=filter('direction', 'page_out'), rollup='delta').publish(label='B')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "FybsAETAwAU", - "importOf": "FwPCYY8AIBw", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Memory", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Bytes", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": null - } - ], - "axisPrecision": null, - "colorBy": "Metric", - "defaultPlotType": "AreaChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": [ - { - "enabled": true, - "property": "sf_originatingMetric" - }, - { - "enabled": true, - "property": "sf_metric" - }, - { - "enabled": false, - "property": "plugin" - }, - { - "enabled": false, - "property": "dsname" - }, - { - "enabled": false, - "property": "host" - }, - { - "enabled": false, - "property": "AWSUniqueId" - }, - { - "enabled": true, - "property": "my.name" - }, - { - "enabled": true, - "property": "os.type" - }, - { - "enabled": true, - "property": "host.id" - }, - { - "enabled": true, - "property": "state" - }, - { - "enabled": true, - "property": "participant.name" - } - ] - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": "state", - "showLegend": true - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Inactive", - "label": "T", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Slab Unreclaimable", - "label": "U", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Buffered", - "label": "V", - "paletteIndex": 5, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Used", - "label": "W", - "paletteIndex": 7, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Free", - "label": "X", - "paletteIndex": 14, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Cached", - "label": "Y", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Slab Reclaimable", - "label": "Z", - "paletteIndex": 15, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "showEventLines": false, - "stacked": true, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Binary" - }, - "packageSpecifications": "", - "programText": "T = data('system.memory.usage', filter=filter('state', 'inactive')).publish(label='T')\nU = data('system.memory.usage', filter=filter('state', 'slab_unreclaimable')).publish(label='U')\nV = data('system.memory.usage', filter=filter('state', 'buffered')).publish(label='V')\nW = data('system.memory.usage', filter=filter('state', 'used')).publish(label='W')\nX = data('system.memory.usage', filter=filter('state', 'free')).publish(label='X')\nY = data('system.memory.usage', filter=filter('state', 'cached')).publish(label='Y')\nZ = data('system.memory.usage', filter=filter('state', 'slab_reclaimable')).publish(label='Z')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "FybsAETAwAY", - "importOf": "FwPCYY8AIBg", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Memory used", - "options": { - "colorBy": "Metric", - "colorScale": null, - "colorScale2": null, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Used", - "label": "A", - "paletteIndex": 14, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "None", - "showSparkLine": false, - "time": { - "range": 300000, - "rangeEnd": 0, - "type": "relative" - }, - "timestampHidden": true, - "type": "SingleValue", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.memory.usage', filter=filter('state', 'used')).publish(label='A')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "Bits/sec", - "id": "FybsAETAwAc", - "importOf": "FwPCYY8AICE", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Network I/O", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Input bits/s - RED", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Output bits/s - BLUE", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - } - ], - "axisPrecision": null, - "colorBy": "Metric", - "defaultPlotType": "LineChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": "device", - "showLegend": true - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Input bits/sec", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Output bits/sec", - "label": "B", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 1 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Binary" - }, - "packageSpecifications": "", - "programText": "A = data('system.network.io', filter=filter('direction', 'receive')).sum(by=['device']).publish(label='A')\nB = data('system.network.io', filter=filter('direction', 'transmit'), rollup='delta').sum(by=['device']).publish(label='B')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "Errors/sec", - "id": "FybsAETAwAg", - "importOf": "FwPCYY8AICI", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Network errors", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Interface errors - RED", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Retransmits - BLUE", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - } - ], - "axisPrecision": null, - "colorBy": "Metric", - "defaultPlotType": "LineChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": null, - "showLegend": false - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Errors/sec", - "label": "A", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "system.network.errors", - "label": "B", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Interface errors/sec", - "label": "C", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.network.errors', filter=filter('direction', 'receive')).publish(label='A', enable=False)\nB = data('system.network.errors', filter=filter('direction', 'transmit')).publish(label='B', enable=False)\nC = (A+B).sum().publish(label='C')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "FybsAETAwAk", - "importOf": "FwPCYY8AIB4", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Disk used", - "options": { - "colorBy": "Dimension", - "colorScale2": null, - "hideMissingValues": false, - "legendOptions": { - "fields": [ - { - "enabled": true, - "property": "device" - }, - { - "enabled": false, - "property": "fs_type" - }, - { - "enabled": false, - "property": "host" - }, - { - "enabled": false, - "property": "sf_originatingMetric" - }, - { - "enabled": true, - "property": "mountpoint" - }, - { - "enabled": false, - "property": "sf_metric" - }, - { - "enabled": false, - "property": "plugin_instance" - }, - { - "enabled": false, - "property": "plugin" - }, - { - "enabled": false, - "property": "dsname" - }, - { - "enabled": false, - "property": "AWSUniqueId" - }, - { - "enabled": false, - "property": "os.type" - }, - { - "enabled": true, - "property": "type" - }, - { - "enabled": false, - "property": "mode" - }, - { - "enabled": true, - "property": "state" - }, - { - "enabled": false, - "property": "host.id" - }, - { - "enabled": false, - "property": "participant.name" - }, - { - "enabled": false, - "property": "my.name" - } - ] - }, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "system.filesystem.usage", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "A", - "label": "B", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "Sparkline", - "sortBy": "-value", - "time": { - "range": 900000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "List", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "B = (A).publish(label='B')\nA = data('system.filesystem.usage', filter=filter('state', 'used')).publish(label='A', enable=False)", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "FybsAETAwAo", - "importOf": "FwPCYY8AIBs", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "CPU %", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": null - } - ], - "axisPrecision": null, - "colorBy": "Dimension", - "defaultPlotType": "AreaChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "onChartLegendOptions": { - "dimensionInLegend": null, - "showLegend": false - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "CPU utilization (%)", - "label": "A", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.cpu.time', filter=filter('state', 'user')).scale(10).publish(label='A')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "Operations/sec", - "id": "FybsAETAwAs", - "importOf": "FwPCYY8AIB8", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Disk I/O", - "options": { - "areaChartOptions": { - "showDataMarkers": false - }, - "axes": [ - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Read ops - RED", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - }, - { - "highWatermark": null, - "highWatermarkLabel": null, - "label": "Write ops - BLUE", - "lowWatermark": null, - "lowWatermarkLabel": null, - "max": null, - "min": 0 - } - ], - "axisPrecision": null, - "colorBy": "Metric", - "defaultPlotType": "LineChart", - "eventPublishLabelOptions": [], - "histogramChartOptions": { - "colorThemeIndex": 16 - }, - "includeZero": false, - "legendOptions": { - "fields": null - }, - "lineChartOptions": { - "showDataMarkers": false - }, - "noDataOptions": null, - "onChartLegendOptions": { - "dimensionInLegend": null, - "showLegend": false - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Read ops/sec", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Write ops/sec", - "label": "B", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 1 - } - ], - "showEventLines": false, - "stacked": false, - "time": { - "range": 7200000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "TimeSeriesChart", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('disk_ops.read',rollup='rate').sum().publish(label='A')\nB = data('disk_ops.write',rollup='rate').sum().publish(label='B')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "FybsAETAwAw", - "importOf": "FwPCYY8AICA", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Total network bits/sec", - "options": { - "colorBy": "Metric", - "colorScale2": null, - "hideMissingValues": false, - "legendOptions": { - "fields": null - }, - "maximumPrecision": 4, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "Input bits/sec", - "label": "A", - "paletteIndex": 4, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "Output bits/sec", - "label": "B", - "paletteIndex": 1, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 1 - } - ], - "refreshInterval": null, - "secondaryVisualization": "Sparkline", - "sortBy": "+sf_metric", - "time": { - "range": 900000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "List", - "unitPrefix": "Binary" - }, - "packageSpecifications": "", - "programText": "A = data('system.network.io', filter=filter('direction', 'receive')).sum().publish(label='A')\nB = data('system.network.io', filter=filter('direction', 'transmit'), rollup='rate').sum().publish(label='B')", - "relatedDetectorIds": [], - "tags": null - } - }, - { - "chart": { - "autoDetectRelatedDetectorIds": [], - "created": 0, - "creator": null, - "customProperties": {}, - "description": "", - "id": "FybsAETAwA0", - "importOf": "FwPCYY8AICM", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "Load average", - "options": { - "colorBy": "Dimension", - "colorScale2": null, - "hideMissingValues": false, - "legendOptions": { - "fields": null - }, - "maximumPrecision": 3, - "noDataOptions": { - "linkText": null, - "linkUrl": null, - "noDataMessage": null - }, - "programOptions": { - "disableSampling": false, - "maxDelay": null, - "minimumResolution": 0, - "timezone": null - }, - "publishLabelOptions": [ - { - "displayName": "1m Average", - "label": "A", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "5m Average", - "label": "B", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - }, - { - "displayName": "15m Average", - "label": "C", - "paletteIndex": null, - "plotType": null, - "valuePrefix": null, - "valueSuffix": null, - "valueUnit": null, - "yAxis": 0 - } - ], - "refreshInterval": null, - "secondaryVisualization": "Sparkline", - "sortBy": "+sf_metric", - "time": { - "range": 900000, - "rangeEnd": 0, - "type": "relative" - }, - "type": "List", - "unitPrefix": "Metric" - }, - "packageSpecifications": "", - "programText": "A = data('system.cpu.load_average.1m').mean().publish(label='A')\nB = data('system.cpu.load_average.5m').mean().publish(label='B')\nC = data('system.cpu.load_average.15m').mean().publish(label='C')", - "relatedDetectorIds": [], - "tags": null - } - } - ], - "crossLinkExports": [], - "dashboardExports": [ - { - "dashboard": { - "authorizedWriters": null, - "chartDensity": "DEFAULT", - "charts": [ - { - "chartId": "FybsAETAwAY", - "column": 3, - "height": 1, - "row": 0, - "width": 3 - }, - { - "chartId": "FybsAETAwAw", - "column": 6, - "height": 1, - "row": 0, - "width": 3 - }, - { - "chartId": "FybsAETAwAk", - "column": 9, - "height": 1, - "row": 0, - "width": 3 - }, - { - "chartId": "FybsAETAwAM", - "column": 0, - "height": 1, - "row": 0, - "width": 3 - }, - { - "chartId": "FybsAETAwAo", - "column": 0, - "height": 1, - "row": 1, - "width": 6 - }, - { - "chartId": "FybsAETAwA0", - "column": 6, - "height": 1, - "row": 1, - "width": 6 - }, - { - "chartId": "FybsAETAwAU", - "column": 0, - "height": 1, - "row": 2, - "width": 6 - }, - { - "chartId": "FybsAETAwAQ", - "column": 6, - "height": 1, - "row": 2, - "width": 6 - }, - { - "chartId": "FybsAETAwAs", - "column": 0, - "height": 1, - "row": 3, - "width": 6 - }, - { - "chartId": "FybsAETAwAI", - "column": 6, - "height": 1, - "row": 3, - "width": 6 - }, - { - "chartId": "FybsAETAwAc", - "column": 0, - "height": 1, - "row": 4, - "width": 6 - }, - { - "chartId": "FybsAETAwAg", - "column": 6, - "height": 1, - "row": 4, - "width": 6 - } - ], - "created": 0, - "creator": null, - "customProperties": null, - "description": "", - "discoveryOptions": null, - "eventOverlays": null, - "filters": { - "sources": null, - "time": { - "end": "Now", - "start": "-5m" - }, - "variables": [ - { - "alias": "host", - "applyIfExists": false, - "description": "Host running collectd", - "preferredSuggestions": [], - "property": "host", - "propertyMappings": [ - "host", - "host.name" - ], - "replaceOnly": false, - "required": true, - "restricted": false, - "value": [ - "*" - ] - } - ] - }, - "groupId": "FybsAETAwAE", - "groupName": "OpenTelemetry Contrib", - "id": "FybsAETAwA4", - "importOf": "FwPCYY8AICQ", - "lastUpdated": 0, - "lastUpdatedBy": null, - "maxDelayOverride": null, - "name": "OTel Contrib Dashboard", - "permissions": null, - "selectedEventOverlays": [], - "tags": null - } - } - ], - "groupExport": { - "group": { - "authorizedWriters": null, - "created": 0, - "creator": null, - "dashboardConfigs": [ - { - "configId": "FwPCYY8AICU", - "dashboardId": "FybsAETAwA4", - "descriptionOverride": null, - "filtersOverride": null, - "nameOverride": null - } - ], - "dashboards": [ - "FybsAETAwA4" - ], - "description": "", - "email": null, - "id": "FybsAETAwAE", - "importDetails": { - "hashCode": -1470956163, - "importOf": "FwOxtI_AEB4", - "importTime": 1686585381165 - }, - "importOf": "FwOxtI_AEB4", - "lastUpdated": 0, - "lastUpdatedBy": null, - "name": "OpenTelemetry Contrib", - "permissions": null, - "teams": null - } - }, - "hashCode": 390745185, - "id": "FybsAETAwAE", - "modelVersion": 1, - "packageType": "GROUP" -} \ No newline at end of file diff --git a/content/ja/other/opentelemetry-collector/7-visualisation/index.md b/content/ja/other/opentelemetry-collector/7-visualisation/index.md deleted file mode 100644 index 193bbb3886..0000000000 --- a/content/ja/other/opentelemetry-collector/7-visualisation/index.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: データの可視化 -linkTitle: 7. 可視化 -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** に移動します - -![menu-dashboards](../images/menu-dashboards.png) - -検索ボックスで **OTel Contrib** を検索します - -![search-dashboards](../images/search-dashboards.png) - -{{% notice style="info" %}} -ダッシュボードが存在しない場合は、講師が迅速に追加します。このワークショップのSplunk主催版に参加していない場合、インポートするダッシュボードグループはこのページの下部にあります。 -{{% /notice %}} - -**OTel Contrib Dashboard** ダッシュボードをクリックして開きます - -![otel-dashboard](../images/otel-dashboard.png) - -ダッシュボードの上部にある **Filter** 欄に「participant」の途中まで入力し、候補に出る **participant.name** を選択します - -![search-filter](../images/search-filter.png) - -`participant.name` で、`config.yaml` 内で設定したあなたの名前を入力するか、リストから選択することができます - -![select-conf-attendee-name](../images/select-participant-name.png) - -これで、OpenTelemetry Collectorを設定したホストの、ホストメトリクスを確認することができます。 - -{{% resources sort="asc" style="info" title="ダッシュボードJSONのダウンロード方法" /%}} diff --git a/content/ja/other/opentelemetry-collector/8-develop/1-project-setup.md b/content/ja/other/opentelemetry-collector/8-develop/1-project-setup.md deleted file mode 100644 index 24b9790b3a..0000000000 --- a/content/ja/other/opentelemetry-collector/8-develop/1-project-setup.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: OpenTelemetry Collector を開発する -linkTitle: 8.1 セットアップ -weight: 9 ---- - -## プロジェクトのセットアップ {{% badge style=primary icon=star %}}**Ninja**{{% /badge %}} - -{{% notice style="note" %}} - -このワークショップのセクションを完了する時間は経験によって異なる場合があります。 - -完成したものは[こちら](https://github.com/splunk/collector-workshop-example)にあります。詰まった場合や講師と一緒に進めたい場合に利用してください。 - -{{% /notice %}} - -新しい _Jenkins CI_ レシーバーの開発を始めるため、まずはGoプロジェクトのセットアップから始めていきます。 -新しいGoプロジェクトを作成する手順は以下の通りです - -1. `${HOME}/go/src/jenkinscireceiver` という名前の新しいディレクトリを作成し、そのディレクトリに移動します。 - 1. 実際のディレクトリ名や場所は厳密ではありません。自分の開発ディレクトリを自由に選ぶことができます。 -1. `go mod init splunk.conf/workshop/example/jenkinscireceiver` を実行して、Goのモジュールを初期化します。 - 1. 依存関係を追跡するために使用される `go.mod` というファイルが作成されます。 - 1. インポートされている依存関係のチェックサム値が `go.sum` として保存されます。 - -{{% expand title="{{% badge icon=check color=green title=**Check-in** %}}go.modをレビューする{{% /badge %}}" %}} - -``` text -module splunk.conf/workshop/example/jenkinscireceiver - -go 1.20 -``` - -{{% /expand %}} diff --git a/content/ja/other/opentelemetry-collector/8-develop/2-configuration.md b/content/ja/other/opentelemetry-collector/8-develop/2-configuration.md deleted file mode 100644 index f7d0e369ed..0000000000 --- a/content/ja/other/opentelemetry-collector/8-develop/2-configuration.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: OpenTelemetry Collector を開発する -linkTitle: 8.2 Configuration -weight: 10 ---- - -## Configuration の構築 - -コンポーネントのConfiguration部分は、ユーザーがコンポーネントに対する入力を行う方法であり、設定に使用される値は以下のようである必要があります - -1. そのフィールドが何を制御するのか、ユーザーが直感的に理解できる -1. 必須項目とオプション項目が明確である -1. 共通の名前とフィールドを再利用する -1. オプションをシンプルに保つ - -{{% tabs %}} -{{% tab title="良い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 %}} -{{% tab title="悪い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 %}} -{{% /tabs %}} - -悪い例では、Configurationのベストプラクティスに反するとコンポーネントが使いにくくなってしまうことが理解できるはずです。 -フィールドの値が何であるべきかを明確ではなく、既存のプロセッサーに移譲できる機能を含み、コレクター内の他のコンポーネントと比較してフィールドの命名に一貫性がありません。 - -良い例では、必要な値をシンプルに保ち、他のコンポーネントからのフィールド名を再利用し、コンポーネントがJenkinsとコレクター間の相互作用にのみ焦点を当てています。 - -設定値の中には、このコンポーネントで独自に追加するものと、コレクター内部の共有ライブラリによって提供されているものがあります。これらはビジネスロジックに取り組む際にさらに詳しく説明します。Configurationは小さく始めるべきで、ビジネスロジックに追加の機能が必要になったら、設定も追加していきましょう。 - -## コードを書く - -Configurationに必要なコードを実装するために、`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/other/opentelemetry-collector/8-develop/3-component.md b/content/ja/other/opentelemetry-collector/8-develop/3-component.md deleted file mode 100644 index 6f0b8fbd0a..0000000000 --- a/content/ja/other/opentelemetry-collector/8-develop/3-component.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: OpenTelemetry Collector を開発する -linkTitle: 8.3 コンポーネントを検討する -weight: 11 ---- - -## コンポーネントを検討する - -Jenkinsからメトリクスを取得するために必要なコンポーネントの種類をおさらいしましょう - -{{% tabs %}} -{{% tab title="エクステンション" %}} -エクステンションが解決するビジネスユースケースは以下の通りです - -1. 実行時の設定が必要な共有機能を持つ -1. コレクターの実行時間の観察に間接的に役立つ - -詳細については、[エクステンションの概要](../2-extensions)を参照してください。 -{{% /tab %}} -{{% tab title="レシーバー" %}} -レシーバーが解決するビジネスユースケースは以下の通りです - -- リモートソースからのデータの取得 -- リモートソースからのデータの受信 - -これらは一般的に _pull_ 対 _push_ ベースのデータ収集と呼ばれ、詳細については[レシーバーの概要](../3-receivers)で読むことができます。 -{{% /tab %}} -{{% tab title="プロセッサー" %}} -プロセッサーが解決するビジネスユースケースは以下の通りです - -- データ、フィールド、または値の追加または削除 -- データの観察と意思決定 -- バッファリング、キューイング、および並べ替え - -プロセッサーを通過するデータタイプは、下流のコンポーネントに同じデータタイプを転送する必要があることを覚えておいてください。 -詳細については、[プロセッサーの概要](../4-processors)をご覧ください。 -{{% /tab %}} -{{% tab title="エクスポーター" %}} -エクスポーターが解決するビジネスユースケースは以下の通りです - -- データをツール、サービス、またはストレージに送信する - -OpenTelemetryコレクターは「バックエンド」、すべてを一元化した観測可能性スイートを目指すのではなく、OpenTelemetryの創設原則に忠実であり続けることを目指しています。つまり、ベンダーに依存しない全ての人のための観測可能性です。詳細については、[エクスポーターの概要](../5-exporters)をお読みください。 - -{{% /tab %}} -{{% tab title="{{% badge style=primary icon=star %}}**Ninja:** コネクター{{% /badge %}}" %}} - -コネクターは比較的新しいコンポーネントで、このワークショップではあまり触れていません。 -コネクターは、異なるテレメトリタイプやパイプラインをまたいで使用できるプロセッサーのようなものだといえます。たとえば、コネクターはログとしてデータを受け取り、メトリクスとして出力したり、あるパイプラインからメトリクスを受け取り、テレメトリーデータに関するメトリクスを提供したりすることができます。 - -コネクターが解決するビジネスケースは以下の通りです - -- 異なるテレメトリタイプ間の変換 - - ログからメトリクスへ - - トレースからメトリクスへ - - メトリクスからログへ -- 受信したデータを観察し、自身のデータを生成する - - メトリクスを受け取り、データの分析メトリクスを生成する。 - -**Ninja**セクションの一部として[プロセッサーの概要](../4-processors)内で簡単に概要が説明されています。 -{{% /tab %}} -{{% /tabs %}} - -これらのコンポーネントについて考えると、Jenkinsに対応する場合はプルベースのレシーバーを開発する必要があることがわかります。 diff --git a/content/ja/other/opentelemetry-collector/8-develop/4-design.md b/content/ja/other/opentelemetry-collector/8-develop/4-design.md deleted file mode 100644 index 413f4b9164..0000000000 --- a/content/ja/other/opentelemetry-collector/8-develop/4-design.md +++ /dev/null @@ -1,247 +0,0 @@ ---- -title: OpenTelemetry Collector を開発する -linkTitle: 8.4 メトリクスを設計する -weight: 12 ---- - -### メトリクスを設計する - -レシーバーによってキャプチャされるメトリクスを定義し、エクスポートするために、コレクターのために開発された [mdatagen](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/cmd/mdatagen) を使って、yamlで定義したメトリクスをコードに変換していきます。 - -{{% 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はソフトウェアデザインパターンの一種で、提供されたConfigurationを使って、動的にオブジェクト（この場合は `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` が更新されます。 diff --git a/content/ja/other/opentelemetry-collector/8-develop/5-business-logic.md b/content/ja/other/opentelemetry-collector/8-develop/5-business-logic.md deleted file mode 100644 index 79a490408f..0000000000 --- a/content/ja/other/opentelemetry-collector/8-develop/5-business-logic.md +++ /dev/null @@ -1,225 +0,0 @@ ---- -title: OpenTelemetry Collector を開発する -linkTitle: 8.5 ビジネスロジックを作る -weight: 13 ---- - -## ビジネスロジックを作る - -この時点では、何も行っていないカスタムコンポーネントが作成されています。ここから、Jenkinsからデータを取得するための必要なロジックを追加していきましょう。 - -ここからのステップは以下の通りです - -1. Jenkinsに接続するクライアントを作成する -1. 設定されたすべてのジョブをキャプチャする -1. 設定されたジョブの最後のビルドのステータスを報告する -1. コミットタイムスタンプとジョブ完了の時間差を計算する - -変更を `scraper.go` に加えていきます。 - -{{% tabs %}} -{{% tab title="1. Jenkinsクライアントを追加する" %}} - -Jenkinsサーバーに接続するために、パッケージ ["github.com/yosida95/golang-jenkins"](https://pkg.go.dev/github.com/yosida95/golang-jenkins) を使用します。これには、Jenkinsサーバーからデータを読み取るために必要な機能が提供されています。 - -次に、["go.opentelemetry.io/collector/receiver/scraperhelper"](https://pkg.go.dev/go.opentelemetry.io/collector/receiver/scraperhelper) ライブラリのいくつかのヘルパー関数を利用して、コンポーネントの起動が完了したらJenkinsサーバーに接続できるようにするスタート関数を作成します。 - -```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レシーバーを初期化するために必要なすべてのコードが完成しました。 - -{{% /tab%}} -{{% tab title="2. ジョブをキャプチャする" %}} - -ここから先は、実装が必要な `scrape` メソッドに焦点を当てます。このメソッドは、設定された間隔（デフォルトでは1分）ごとに実行されます。 - -Jenkinsサーバーの負荷状況や、どの程度のプロジェクトが実行されているかを測定するために、Jenkinsで設定されているジョブの数をキャプチャしたいと考えています。これを行うために、Jenkinsクライアントを呼び出してすべてのジョブをリスト化し、エラーが報告された場合はメトリクスなしでそれを返し、そうでなければメトリクスビルダーからのデータを発行します。 - -```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. ジョブの状態を報告する" %}} - -前のステップにより、すべてのジョブをキャプチャしてジョブの数をレポートできるようになりました。 -このステップでは、それぞれのジョブを調査し、レポートされた値を使用してメトリクスをキャプチャしていきます。 - -```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. 差分を報告する" %}} - -最後のステップでは、コミットからジョブ完了までにかかった時間を計算して、[DORA メトリクス](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) を推測するのに役立てていきます。 - -```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レシーバーが完成します！ - -## 次は何をするの？ - -コンポーネントに必要な機能は、おそらく他にもたくさん思いつくでしょう。例えば - -- ジョブで使用されたブランチ名を含めることはできますか？ -- ジョブのプロジェクト名を含めることはできますか？ -- プロジェクトのジョブの総持続時間をどのように計算しますか？ -- 変更が機能するかどうかをどのように検証しますか？ - -この時間を使って遊んでみたり、壊してみたり、変更してみたり、ビルドからのログをキャプチャしてみるなどしてください。 diff --git a/content/ja/other/opentelemetry-collector/8-develop/_index.md b/content/ja/other/opentelemetry-collector/8-develop/_index.md deleted file mode 100644 index 16ae21b2e6..0000000000 --- a/content/ja/other/opentelemetry-collector/8-develop/_index.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: OpenTelemetry Collector を開発する -linkTitle: 8. Develop -weight: 8 ---- - -## カスタムコンポーネントの開発 - -Open Telemetry Collectorのためのコンポーネントを構築するには、以下の3つの主要な部分が必要です - -1. Configuration - _ユーザーが設定できる値は何か_ -1. Factory - _提供された値を使ってコンポーネントを作成する_ -1. Business Logic - _コンポーネントが実行する必要があること_ - -これについて、プロジェクトの重要なDevOpsメトリクスを追跡するためにJenkinsと連携するコンポーネントを構築する例を考えていきます。 - -測定しようとしているメトリクスは次のとおりです - -1. 変更に対するリードタイム - _「コミットが本番環境に入るまでにかかる時間」_ -1. 変更失敗率 - _「本番環境での障害を引き起こすデプロイの割合」_ -1. デプロイ頻度 - _「[チーム]が本番環境に成功してリリースする頻度」_ -1. 平均復旧時間 - _「[チーム]が本番環境の障害から復旧するのにかかる時間」_ - -これらの指標はGoogleの [DevOps Research and Assessment (DORA)](https://dora.dev/) チームによって特定されたもので、ソフトウェア開発チームのパフォーマンスを示すのに役立ちます。_Jenkins CI_ を選択した理由は、私たちが同じオープンソースソフトウェアエコシステムに留まり、将来的にベンダー管理のCIツールが採用する例となることができるためです。 - -## 計装 🆚 コンポーネント - -組織内でオブザーバビリティを向上させる際には、トレードオフが発生するため、考慮する点があります。 - -| | 長所 | 短所 | -| ----- | ----- | ----- | -| **（自動）計装**[^1] | システムを観測するために外部APIが不要 | 計装を変更するにはプロジェクトの変更が必要 | -| | システム所有者/開発者は可観測性の変更が可能 | ランタイムへの追加の依存が必要 | -| | システムの文脈を理解し、_Exemplar_ とキャプチャされたデータを関連付けることが可能 | システムのパフォーマンスに影響を与える可能性がある | -| **コンポーネント** | データ名や意味の変更をシステムのリリースサイクルから独立した展開が可能 | APIの破壊的な変更の可能性があり、システムとコレクター間でリリースの調整が必要 | -| | その後の利用に合わせて収集されるデータの更新/拡張が容易 | キャプチャされたデータの意味がシステムリリースと一致せず、予期せず壊れる可能性がある | - - -[^1]: 計装（instrument, インストゥルメント）とは、アプリケーションなどのシステムコンポーネントに対して、トレースやメトリクス、ログなどのテレメトリーデータを出力させる実装。計装ライブラリを最低限セットアップするだけで一通りのトレースやメトリクスなどを出力できるような対応を「自動計装」と呼びます。 diff --git a/content/ja/other/opentelemetry-collector/_index.md b/content/ja/other/opentelemetry-collector/_index.md deleted file mode 100644 index 36f81fdfae..0000000000 --- a/content/ja/other/opentelemetry-collector/_index.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: OpenTelemetryでクラウドネイティブ環境のオブザーバビリティを実現する -linkTitle: OpenTelemetry Collector -weight: 10 -alwaysopen: false -description: OpenTelemetry Collectorのコンセプトを学び、Splunk Observability Cloudにデータを送信する方法を理解しましょう。 ---- - -## 概要 - -OpenTelemetryを使い始める場合は、バックエンドに直接データを送ることから始めるかもしれません。最初のステップとしてはよいですが、OpenTelemetry Collectorをオブザーバビリティのアーキテクチャとして使用するのは多くの利点があり、本番環境ではCollectorを使ったデプロイを推奨しています。 - -このワークショップでは、OpenTelemetry Collectorを使用することに焦点を当て、Splunk Observability Cloudで使用するためのレシーバー、プロセッサー、エクスポーターを定義し、実際にテレメトリデータを送信するためのパイプラインを設定することで、環境に合わせてCollectorを活用を学びます。また、分散プラットフォームのビジネスニーズに対応するための、カスタムコンポーネントを追加できるようになるまでの道のりを進むことになります。 - -### Ninja セクション - -ワークショップの途中には、展開できる {{% badge style=primary icon=star %}}Ninjaセクション{{% /badge %}} があります。これらはより実践的で、ワークショップ中、もしくは自分の時間を使って、さらに技術的な詳細に取り組むことができます。 - -OpenTelemetryプロジェクトは頻繁に開発されているため、Ninjaセクションの内容が古くなる可能性があることに注意してください。コンテンツが古い場合には更新のリクエストを出すこともできますので、必要なものを見つけた場合はお知らせください。 - ---- - -{{% expand title="{{% badge style=primary icon=star %}}**Ninja:** をテストして！{{% /badge %}}" %}} -**このワークショップを完了すると、正式に OpenTelemetry Collector ニンジャになります！** -{{% /expand %}} - ---- - -## 対象者 - -このワークショップは、OpenTelemetry Collectorのアーキテクチャとデプロイメントについてさらに学びたいと考えている開発者やシステム管理者を対象としています。 - -## 前提条件 - -- データ収集に関する基本的な理解 -- コマンドラインとvim/viの経験 -- Ubuntu 20.04 LTSまたは22.04 LTSが稼働するインスタンス/ホスト/VM - - 最小要件はAWS/EC2 t2.micro（1 CPU、1GB RAM、8GBストレージ） - -## 学習目標 - -このセッションの終わりまでに、参加者は以下を行うことができるようになります - -- OpenTelemetryのコンポーネントを理解する -- レシーバー、プロセッサー、エクスポーターを使用してデータを収集・分析する -- OpenTelemetryを使用する利点を特定する -- 自分たちのビジネスニーズに対応するカスタムコンポーネントを構築する - -## OpenTelemetry のアーキテクチャー - -{{< mermaid >}} -%%{ - init:{ - - "themeVariables": { - "primaryColor": "#ffffff", - "clusterBkg": "#eff2fb", - "defaultLinkColor": "#333333" - } - } -}%% - -flowchart LR; - subgraph Receivers - 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/other/opentelemetry-collector/images/extensionz.png b/content/ja/other/opentelemetry-collector/images/extensionz.png deleted file mode 100644 index d543bed0a9..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/extensionz.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/menu-dashboards.png b/content/ja/other/opentelemetry-collector/images/menu-dashboards.png deleted file mode 100644 index 77b5d43775..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/menu-dashboards.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/otel-charts.png b/content/ja/other/opentelemetry-collector/images/otel-charts.png deleted file mode 100644 index d956d99570..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/otel-charts.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/otel-dashboard.png b/content/ja/other/opentelemetry-collector/images/otel-dashboard.png deleted file mode 100644 index fa9810e9d9..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/otel-dashboard.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/pipelinez-full-config.png b/content/ja/other/opentelemetry-collector/images/pipelinez-full-config.png deleted file mode 100644 index c78e0bc9c7..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/pipelinez-full-config.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/pipelinez.png b/content/ja/other/opentelemetry-collector/images/pipelinez.png deleted file mode 100644 index e68533f0ea..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/pipelinez.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/search-dashboards.png b/content/ja/other/opentelemetry-collector/images/search-dashboards.png deleted file mode 100644 index 2bd56e0b7b..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/search-dashboards.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/search-filter.png b/content/ja/other/opentelemetry-collector/images/search-filter.png deleted file mode 100644 index 38a718a884..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/search-filter.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/select-participant-name.png b/content/ja/other/opentelemetry-collector/images/select-participant-name.png deleted file mode 100644 index 9924208aa1..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/select-participant-name.png and /dev/null differ diff --git a/content/ja/other/opentelemetry-collector/images/servicez.png b/content/ja/other/opentelemetry-collector/images/servicez.png deleted file mode 100644 index 8cf28051d4..0000000000 Binary files a/content/ja/other/opentelemetry-collector/images/servicez.png and /dev/null differ diff --git a/content/ja/other/pet-clinic/_index.md b/content/ja/other/pet-clinic/_index.md deleted file mode 100644 index b593e9a2ae..0000000000 --- a/content/ja/other/pet-clinic/_index.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Pet Clinic Java ワークショップ -alwaysopen: false -weight: 1 -description: JavaアプリケーションをつかったSplunk Oservabilityのワークショップです ---- - -このワークショップでは、Splunk Observabilityプラットフォームの以下のコンポーネントを構成するための、基本的なステップを体験できます - -* Splunk Infrastructure Monitoring (IM) -* Splunk APM - * Endpoint Performance - * Database Query Performance - * AlwaysOn Profiling -* Splunk Real User Monitoring (RUM) -* Splunk LogObserver - -ワークショップの中では、Javaのサンプルアプリケーション（Spring Pet Clinic）をクローン（ダウンロード）し、アプリケーションのコンパイル、パッケージ、実行していきます。 - -アプリケーションを起動すると、OpenTelemetry Javaエージェントを通じて、Splunk APMでメトリクスとトレースが即座に表示されるようになります。 - -その後、Splunk OpenTelemetry Javascript Libraries (RUM)を使用して、Pet Clinicのエンドユーザーインターフェース（アプリケーションによってレンダリングされるHTMLページ）を計装し、エンドユーザーが実行する個々のクリックとページロードのすべてについて、RUMトレースを生成していきます。 - -{{% notice title="前提条件" style="info" %}} -このワークショップは、ホスト/インスタンスが提供されるSplunk実行ワークショップ **または** 自前のホスト/[Multipassインスタンス](https://github.com/splunk/observability-workshop/tree/main/multipass) で行う、自己主導型のワークショップです。 - -ご自身のシステムには、以下のものがインストールされ、有効になっている必要があります - -1. JDK 17 -2. ポート `8083` が開いていること（インバウンド/アウトバウンド） -{{% /notice %}} - -![PetClinic Exercise](images/petclinic-exercise.png) diff --git a/content/ja/other/pet-clinic/docs/apm.md b/content/ja/other/pet-clinic/docs/apm.md deleted file mode 100644 index ef1bf0d4c9..0000000000 --- a/content/ja/other/pet-clinic/docs/apm.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: OpenTelemetry Javaエージェントをインストールする -linkTitle: 2. Javaエージェント -weight: 2 ---- - -## 1. Spring PetClinic アプリケーションを動かす - -APMをセットアップするためにまず必要なのは...そう、アプリケーションです！この演習では、Spring PetClinicアプリケーションを使用します。これはSpringフレームワーク（Spring Boot）で作られた、非常に人気のあるサンプルJavaアプリケーションです。 - -まずはPetClinicリポジトリをクローンし、そして、アプリケーションをコンパイル、ビルド、パッケージ、テストしていきます。 - -```bash -git clone https://github.com/spring-projects/spring-petclinic -``` - -`spring-petclinic` ディレクトリに移動します: - -```bash -cd spring-petclinic -``` - -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 -``` - -そして、Splunk版のOpenTelemetry Java APMエージェントをダウンロードしておきましょう。 - -```bash -curl -L https://github.com/signalfx/splunk-otel-java/releases/latest/download/splunk-otel-javaagent.jar \ --o splunk-otel-javaagent.jar -``` - -次に、mavenコマンドを実行してPetClinicをコンパイル/ビルド/パッケージ化します: - -```bash -./mvnw package -Dmaven.test.skip=true -``` - -{{% notice title="情報" style="info" %}} -実際にアプリをコンパイルする前に、mavenが多くの依存ライブラリをダウンロードするため、初回実行時には数分かかるでしょう。2回目以降の実行はもっと短くなります。 -{{% /notice %}} - -そして、以下のコマンドでアプリケーションを実行することができます: - - -```bash -java -javaagent:./splunk-otel-javaagent.jar \ --Dserver.port=8083 \ --Dotel.service.name=$(hostname).service \ --Dotel.resource.attributes=deployment.environment=$(hostname),version=0.314 \ --Dsplunk.profiler.enabled=true \ --Dsplunk.profiler.memory.enabled=true \ --Dsplunk.metrics.enabled=true \ --jar target/spring-petclinic-*.jar --spring.profiles.active=mysql -``` - - -アプリケーションが動作しているかどうかは、`http://:8083` にアクセスして確認することができます。 -次に、トラフィックを生成し、クリックしまくり、エラーを生成し、ペットを追加するなどしてください。 - -* `-Dotel.service.name=$(hostname).service` では、アプリケーションの名前を定義しています。サービスマップ上のアプリケーションの名前等に反映されます。 -* `-Dotel.resource.attributes=deployment.environment=$(hostname),version=0.314` では、Environmentと、versionを定義しています。 - - `deployment.environment=$(hostname)` は、Splunk APM UIの上部「Environment」に反映されます。 - - `version=0.314` はここでは、アプリケーションのバージョンを示しています。トレースをドリルダウンしたり、サービスマップのBreakdownの機能で分析したり、Tag Spotlightを開くと `version` 毎のパフォーマンス分析が使えます。 -* `-Dsplunk.profiler.enabled=true` および `splunk.profiler.memory.enabled=true` では、CPUとメモリのプロファイリングを有効にしています。Splunk APM UIから、AlwaysOn Profilingを開いてみてください。 -* `-Dsplunk.metrics.enabled=true` では、メモリやスレッドなどJVMメトリクスの送信を有効にしています。Dashboardsから、APM java servicesを開いてみてください。 - -その後、Splunk APM UIにアクセスして、それぞれのテレメトリーデータを確認してみましょう！ - - -{{% notice title="Troubleshooting MetricSetsを追加する" style="info" %}} -サービスマップやTab Spotlightで、 `version` などのカスタム属性で分析できるようにするためには、Troubleshooting MetricSetsの設定をあらかじめ追加する必要があります。 -左メニューの **Settings → APM MetricSets** で、設定を管理することができます。 もしお使いのアカウントで分析できなければ、設定を追加してみましょう。 -{{% /notice %}} - - -次のセクションではカスタム計装を追加して、OpenTelemetryでは何ができるのか、さらに見ていきます。 diff --git a/content/ja/other/pet-clinic/docs/imt.md b/content/ja/other/pet-clinic/docs/imt.md deleted file mode 100644 index c65ac34589..0000000000 --- a/content/ja/other/pet-clinic/docs/imt.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: OpenTelemetry Collectorをインストールする -linkTitle: 1. OpenTelemetry Collector -weight: 1 ---- - -## 1. はじめに - -OpenTelemetry Collectorは、インフラストラクチャーとアプリケーションを計装するためのコアコンポーネントです。 その役割は収集と送信です - -- インフラストラクチャーのメトリクス（ディスク、CPU、メモリなど） -- Application Performance Monitoring（APM）のトレース情報 -- プロファイリングに関するデータ -- ホストおよびアプリケーションのログ - -Splunk Observability Cloudでは、インフラストラクチャーとアプリケーションの両方でCollectorのセットアップを案内するウィザードを提供しています。デフォルトでは、ウィザードはコレクターのインストールのみを行うコマンドのみを提供します。 - -## 2. 環境変数を設定する - -すでに **Splunk IM** ワークショップを終了している場合は、既存の環境変数を利用することができます。そうでない場合は、`ACCESS_TOKEN` と `REALM` の環境変数を設定して、OpenTelemetry Collectorのインストールコマンドを実行していきます。 - -例えば、Realmが `us1` の場合、`export REALM=us1` と入力し、`eu0` の場合は `export REALM=eu0` と入力します。 - -{{< tabs >}} -{{% tab title="ACCESS TOKENを環境変数に設定する" %}} - -```bash -export ACCESS_TOKEN="" -``` - -{{% /tab %}} -{{< /tabs >}} - -{{< tabs >}} -{{% tab title="REALMを環境変数に設定する" %}} - -```bash -export REALM="" -``` - -{{% /tab %}} -{{< /tabs >}} - -{{% notice title="既存のOpenTelemetryコレクターをすべて削除する" style="warning" %}} -同じVMインスタンスにSplunk IMワークショップのセットアップをしている場合、Otel Collectorをインストールする前にKubernetesで実行中のCollectorを削除していることを確認してください。これは、以下のコマンドを実行することで行うことができます - -```bash -helm delete splunk-otel-collector -``` - -{{% /notice %}} - -## 3. OpenTelemetry Collector をインストールする - -次に、Collectorをインストールします。インストールスクリプトに渡される追加のパラメータは `--deployment-environment` です。 - -```bash -curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh && \ -sudo sh /tmp/splunk-otel-collector.sh --deployment-environment $(hostname)-petclinic --realm $REALM -- $ACCESS_TOKEN -``` - -{{% notice style="info" title="AWS/EC2インスタンスの場合" %}}。 -AWS/EC2インスタンス上でこのワークショップを行う場合、インスタンスのホスト名を公開するためにコレクターにパッチを適用する必要があります - -```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 -``` - -{{% /notice %}} - -インストールが完了したら、Splunk Observabilityの **Hosts with agent installed** ダッシュボードに移動して、**Dashboards → Hosts with agent installed** からホストのデータを確認してみましょう。 - -ダッシュボードのフィルタを使用して `host.name` を選択し、仮想マシンのホスト名を入力または選択します。ホストのデータが表示されたら、APMコンポーネントを使用する準備が整いました。 diff --git a/content/ja/other/pet-clinic/docs/logobserver.md b/content/ja/other/pet-clinic/docs/logobserver.md deleted file mode 100644 index 9058205a92..0000000000 --- a/content/ja/other/pet-clinic/docs/logobserver.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: Log Observer -linktitle: 5. Log Observer -weight: 5 ---- - -このセクションでは、Spring PetClinicアプリケーションをファイルシステムのファイルにログを書き込むように設定し、 -Splunk OpenTelemetry Collectorがそのログファイルを読み取り（tail）、Splunk Observability Platformに情報を報告するように設定していきます。 - -## 1. FluentDの設定 - -Splunk OpenTelemetry Collectorを、Spring PetClinicのログファイルをtailし -Splunk Observability Cloudエンドポイントにデータを報告するように設定する必要があります。 - -Splunk OpenTelemetry Collectorは、FluentDを使用してログの取得/報告を行い、 -Spring PetClinicのログを報告するための適切な設定を行うには、 -デフォルトディレクトリ（`/etc/otel/collector/fluentd/conf.d/`）にFluentDの設定ファイルを追加するだけです。 - -以下は、サンプルのFluentD設定ファイル `petclinic.conf` を新たに作成し、 - -```bash -sudo nano /etc/otel/collector/fluentd/conf.d/petclinic.conf -``` - - -ファイル `/tmp/spring-petclinic.log` を読み取るよう設定を記述します。 - -``` - - @type tail - @label @SPLUNK - tag petclinic.app - path /tmp/spring-petclinic.log - pos_file /tmp/spring-petclinic.pos_file - read_from_head false - - @type none - - -``` - - -このとき、ファイル `petclinic.conf` のアクセス権と所有権を変更する必要があります。 - -```bash -sudo chown td-agent:td-agent /etc/otel/collector/fluentd/conf.d/petclinic.conf -sudo chmod 755 /etc/otel/collector/fluentd/conf.d/petclinic.conf -``` - -ファイルが作成されたら、FluentDプロセスを再起動しましょう。 - -```bash -sudo systemctl restart td-agent -``` - - -## 3. Logbackの設定 - -Spring Pet Clinicアプリケーションは、いくつかのJavaログライブラリを使用することができます。 -このシナリオでは、logbackを使ってみましょう。 - -リソースフォルダに `logback.xml` という名前のファイルを作成して… - -```bash -nano src/main/resources/logback.xml -``` - - -以下の設定を保存しましょう: - -```xml - - - - - true - - - - /tmp/spring-petclinic.log - - springLogFile.%d{yyyy-MM-dd}.log - 5 - 1GB - - - - %d{yyyy-MM-dd HH:mm:ss} - %logger{36} - %msg trace_id=%X{trace_id} span_id=%X{span_id} trace_flags=%X{trace_flags} service.name=%property{otel.resource.service.name}, deployment.environment=%property{otel.resource.deployment.environment} %n - - - - - - - -``` - -その後、アプリケーションを再構築して再度実行していきます。 - - -```bash -./mvnw package -Dmaven.test.skip=true -``` - -```bash -java -javaagent:./splunk-otel-javaagent.jar \ --Dserver.port=8083 \ --Dotel.service.name=$(hostname).service \ --Dotel.resource.attributes=deployment.environment=$(hostname),version=0.317 \ --Dsplunk.profiler.enabled=true \ --Dsplunk.profiler.memory.enabled=true \ --Dsplunk.metrics.enabled=true \ --jar target/spring-petclinic-*.jar --spring.profiles.active=mysql -``` - - -これまで通り、アプリケーション `http://:8083` にアクセスしてトラフィックを生成すると、ログメッセージが報告されるようになります。 - -左側のLog Observerアイコンをクリックして、ホストとSpring PetClinicアプリケーションからのログメッセージのみを選択するためのフィルタを追加できます。 - -1. Add Filter → Field → host.name → <あなたのホスト名> -2. Add Filter → Field → service.name → <あなたのホスト名>.service - - -## 4. まとめ - -これでワークショップは終了です。 -これまでに、Splunk Observability Cloudにメトリクス、トレース、ログ、データベースクエリのパフォーマンス、コードプロファイリングが報告されるようになりました。 -おめでとうございます！ diff --git a/content/ja/other/pet-clinic/docs/manual_instrumentation.md b/content/ja/other/pet-clinic/docs/manual_instrumentation.md deleted file mode 100644 index 05c6a736a8..0000000000 --- a/content/ja/other/pet-clinic/docs/manual_instrumentation.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: マニュアル計装 -linkTitle: 3. マニュアル計装 -weight: 3 ---- - -## 1. 依存ライブラリを追加する - -前のセクション足したような、プロセス全体に渡る属性は便利なのですが、ときにはさらに、リクエストの内容に応じた状況を知りたくなるかもしれません。 -心配ありません、OpenTelemetryのAPIを通じてそれらを計装し、データを送り、Splunk Observabilityで分析できるようになります。 - -最初に、JavaアプリケーションがOpenTelemetryのAPIを使えるように、ライブラリの依存を追加していきます。 -もちろん、vimなどのお好みのエディタをお使い頂いても大丈夫です！ - -アプリケーションが起動中であれば、一旦停止しましょう。ターミナルで **`Ctrl-c`** を押すと、停止することができます。 - -```bash -nano pom.xml -``` - - -そして、`` セクションの中（33行目）に↓を追加してください。 -ファイル修正後、 **`ctrl-O`** のあとに **`Enter`** で、ファイルを保存します。次に **`ctrl-X`** で、nanoを終了します。 - - -``` - - io.opentelemetry - opentelemetry-api - -``` - -念のため、コンパイルできるか確かめてみましょう: - -``` -./mvnw package -Dmaven.test.skip=true -``` - -{{% notice title="Tips: nanoの使い方と壊れたファイルの直し方" style="info" %}} -nanoはLinux環境でよく使われる、シンプルなエディタの一つです。 - -* `Alt-U` で、アンドゥができます。Macの場合は `Esc` キーを押したあとに `U` を押してください！ -* `ctrl-_` のあとに数字を入力すると、指定した行数にジャンプします。 -* `ctrl-O` のあとに `Enter` で、ファイルを保存します。 -* `ctrl-X` で、nanoを終了します。 - -もしファイルをどうしようもなく壊してしまって元に戻したい場合は、gitを使って次のようにするとよいでしょう。 - -```bash -git checkout pom.xml -``` - -{{% /notice %}} - -これで、JavaのアプリケーションでOpenTelemetryのAPIが使う準備ができました。 - -## 2. Javaのコードにマニュアル計装を追加する - -では、アプリケーションコードをちょっと変更して、リクエストのコンテキストのデータをスパン属性に追加してみましょう。 - -ここではPet Clinicアプリケーションの中で `Find Owners` が使われたときに、どのような検索文字列が指定されたのかを調査できるようにしていきます。 -検索条件によってパフォーマンスが劣化してしまうケース、よくありませんか？そんなときは `OwnerController` に計装を追加していきましょう！ - -```bash -nano src/main/java/org/springframework/samples/petclinic/owner/OwnerController.java -``` - -このコードを **変更するのは2箇所** です。 - -まず、`import jakarta.validation.Valid;` の下、37行目付近に↓を足します: - -```java -import io.opentelemetry.api.trace.Span; -``` - -次に、 `// find owners by last name` のコメントがある箇所（おそらく95行目付近にあります）の下に、次のコードを足していきましょう: - -```java - Span span = Span.current(); - span.setAttribute("lastName", owner.getLastName()); -``` - - -このコードで、Last Nameとして指定された検索条件が、スパン属性 `lastName` としてSplunk Observabilityに伝えるようになりました。 - -アプリケーションをコンパイルし直ししますが、Javaコードを多少汚してしまったかもしれません。 `spring-javaformat:apply` を指定しながらコンパイルしてみましょう。 - -```bash -./mvnw spring-javaformat:apply package -Dmaven.test.skip=true -``` - - -アプリケーションを起動します。せっかくなので、バージョンを一つあげて `version=0.315` としましょう。 - -```bash -java -javaagent:./splunk-otel-javaagent.jar \ --Dserver.port=8083 \ --Dotel.service.name=$(hostname).service \ --Dotel.resource.attributes=deployment.environment=$(hostname),version=0.315 \ --Dsplunk.profiler.enabled=true \ --Dsplunk.profiler.memory.enabled=true \ --Dsplunk.metrics.enabled=true \ --jar target/spring-petclinic-*.jar --spring.profiles.active=mysql -``` - - -`http://:8083` にアクセスして、オーナー検索をいくつか試してましょう。そしてSplunk APM UIからExploreを開き、アプリケーションのトレースを見ていきます。 - -{{% notice title="さらなる情報: マニュアル計装について" style="info" %}} -マニュアル計装で何ができるか、他の言語でのやり方などは、OpenTelemetryの公式ウェブサイトにある [Instrumentation](https://opentelemetry.io/docs/instrumentation/) ページをご覧ください。 -{{% /notice %}} - -検証が完了したら、ターミナルで **`Ctrl-c`** を押すと、アプリケーションを停止することができます。 - -次のセクションでは、RUMを使ってブラウザ上のパフォーマンスデータを収集してみましょう。 diff --git a/content/ja/other/pet-clinic/docs/rum.md b/content/ja/other/pet-clinic/docs/rum.md deleted file mode 100644 index 0d21742edb..0000000000 --- a/content/ja/other/pet-clinic/docs/rum.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Real User Monitoring -linkTitle: 4. Real User Monitoring -weight: 4 ---- - -## 1. RUMを有効にする - -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ボタン → Monitor user experience（画面上部タブ） → Browser Instrumentation**を開きます。 - -ドロップダウンから設定済みの **RUM ACCESS TOKEN** を選択し、**Next** をクリックします。以下の構文で **App name** と**Environment** を入力します - -次に、ワークショップのRUMトークンを選択し、 App nameとEnvironmentを定義します。ウィザードでは、ページ上部の `` セクションに配置する必要のあるHTMLコードの断片が表示されます。この例では、次のように記述していますが、ウィザードでは先程入力した値が反映されてるはずです。 - -- Application Name: `-petclinic-service` -- Environment: `-petclinic-env` - -ウィザードで編集済みコードスニペットをコピーするか、以下のスニペットをコピーして適宜編集してください。ただし - -- `[hostname]-petclinic-service` - `[hostname]` をお使いのホスト名に書き換えてください -- `[hostname]-petclinic-env` - `[hostname]` をお使いのホスト名に書き換えてください - -``` html - - -``` - -Spring PetClinicアプリケーションでは、1つのHTMLページを「レイアウト」ページとして使用し、アプリケーションのすべてのページで再利用しています。これは、Splunk RUM計装ライブラリを挿入するのに最適な場所であり、すべてのページで自動的に読み込まれます。 - -では、レイアウトページを編集してみましょう - -```bash -nano src/main/resources/templates/fragments/layout.html -``` - - -そして、上で生成したスニップをページの `` セクションに挿入してみましょう。さて、アプリケーションを再構築して、再び実行する必要があります。 - -## 2. PetClinicを再ビルドする - -mavenコマンドを実行して、PetClinicをコンパイル/ビルド/パッケージ化します - -```bash -./mvnw package -Dmaven.test.skip=true -``` - - -そして、アプリケーションを動かしてみましょう。バージョンを `version=0.316` とするのをお忘れなく。 - -```bash -java -javaagent:./splunk-otel-javaagent.jar \ --Dserver.port=8083 \ --Dotel.service.name=$(hostname).service \ --Dotel.resource.attributes=deployment.environment=$(hostname),version=0.316 \ --Dsplunk.profiler.enabled=true \ --Dsplunk.profiler.memory.enabled=true \ --Dsplunk.metrics.enabled=true \ --jar target/spring-petclinic-*.jar --spring.profiles.active=mysql -``` - - -{{% notice title="versionを自動で設定する" style="info" %}} -ここまできて `version` を毎回変えるためにコマンドラインを修正するのは大変だと思うことでしょう。実際、修正が漏れた人もいるかもしれません。 -本番環境では、環境変数でアプリケーションバージョンを与えたり、コンテナイメージの作成時にビルドIDを与えたりすることになるはずです。 -{{% /notice %}} - -次に、より多くのトラフィックを生成するために、アプリケーションに再度アクセスしてみましょう。 `http://:8083` にアクセスすると、今度はRUMトレースが報告されるはずです。 - -RUMにアクセスして、トレースとメトリクスのいくつかを見てみましょう。左のメニューから **RUM** を選ぶと、Spring Pet Clinicでのユーザー（あなたです！）が体験したパフォーマンスが表示されます。 diff --git a/content/ja/other/pet-clinic/images/petclinic-exercise.png b/content/ja/other/pet-clinic/images/petclinic-exercise.png deleted file mode 100644 index caebe8c6c0..0000000000 Binary files a/content/ja/other/pet-clinic/images/petclinic-exercise.png and /dev/null differ diff --git a/content/ja/resources/dimensions_properties_tags.md b/content/ja/resources/dimensions_properties_tags.md deleted file mode 100644 index 359e4b2727..0000000000 --- a/content/ja/resources/dimensions_properties_tags.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: ディメンション、プロパティ、タグ -weight: 2 -description: ディメンションとプロパティの比較で、どちらかを使うべきかというのはよく議論されます。 -draft: false ---- - -## メトリクスにコンテキストを与える - -ディメンションとプロパティの違いや、どちらを使うべきかというのは、よく話題にされます。それぞれの説明から始めるのではなく、私たちがどのように使い、どのように似ているのかを理解してから、それぞれの違いや、なぜどちらかを使うのかの例を見ていくことにしましょう。 - -## ディメンションとプロパティの類似点 - -最も単純な答えは、ディメンションとプロパティはともに、メトリクスにコンテキスト（状況）を追加するメタデータの `key:value` ペアであるということです。メトリクス自体は、`cpu.utilization` のような標準的なインフラストラクチャメトリクスであろうと、API呼び出しの回数のようなカスタムメトリクスであろうと、実際に測定しているものなら全てに当てはまります。 - -`cpu.utilization` メトリクスの値が50%であっても、それがどこから来たのかなどのコンテキストを知らなければ、それは単なる数字であり、私たちにとって有用ではありません。少なくとも、どのホストから来たのかを知る必要があります。 - -現在では、個々のホストのパフォーマンスや利用率よりも、クラスターやデータセンター全体のパフォーマンスや利用率をより気にすることが多く、ホストのクラスター全体の平均 `cpu.utilization`、あるホストの `cpu.utilization` が同じサービスを実行する他のホストと比べて外れ値である場合、あるいは環境間での平均 `cpu.utilization` を比較することに興味を持っています。 - -このように `cpu.utilization` メトリクスをスライス、集約、またはグループ化するためには、受け取る `cpu.utilization` メトリクスのメタデータに、ホストが属するクラスター、ホスト上で実行されているサービス、およびそれが属する環境などの情報が必要です。このメタデータは、ディメンションまたはプロパティの `key:value` ペアの形で存在することができます。 - -例えば、ダッシュボードでフィルターを適用したり、分析関数を実行する際にグループ化機能を使用したりするとき、プロパティまたはディメンションを使用することができます。 - -## では、ディメンションとプロパティはどう違うの？ - -ディメンションはメトリクスと共に取り込み時に送信されるのに対し、プロパティは取り込み後にメトリクスやディメンションに適用されます。これは、`cpu.utilization`` の値がどのホストから来ているかのような、データポイント（メトリクスの単一の報告値）をユニークにするために必要なメタデータはディメンションでなければならないことを意味します。メトリクス名 + ディメンションはMTS（メトリクスの時間系列）をユニークに定義します。 - -例：特定のホスト（server1）によって送信される `cpu.utilization` メトリクスで、ディメンション `host:server1` があれば、それはユニークな時間系列と見なされます。もし10台のサーバーがそのメトリクスを送信していれば、メトリクス名 `cpu.utilization` を共有し、ディメンションのキー値ペア（host:server1, host:server2...host:server10）でユニークに識別される10の時間系列があります。 - -しかし、サーバー名がデータセンター内でのみユニークである場合、データセンターの場所を示す2番目のディメンションdcを追加する必要があります。これにより、可能なMTSの数は倍になります。受信された `cpu.utilization` メトリクスは、2組のディメンションのキー値ペアによってユニークに識別されます。 - -`cpu.utilization` に `dc:east` と `host:server1` を加えたものは、`cpu.utilization` に `dc:west` と `host:server1` を加えたものとは異なる時間系列を作り出します。 - -## ディメンションは不変だが、プロパティは可変である - -上記で述べたように、メトリクス名 + ディメンションの組み合わせで、ユニークなMTSを作ります。したがって、ディメンションの値が変わると、メトリクス名 + ディメンション値の新しいユニークな組み合わせが生まれ、新しいMTSが作成されます。 - -一方、プロパティはメトリクス（またはディメンション）が取り込まれた後に適用されます。メトリクスにプロパティを適用すると、そのメトリクスが属するすべてのMTSに伝播して適用されます。または、ディメンションにプロパティを適用する場合、例えば `host:server1` とすると、そのホストからのすべてのメトリクスにそのプロパティが添付されます。プロパティの値を変更すると、そのプロパティが添付されているすべてのMTSのプロパティ値が更新されます。これが重要な理由は何でしょうか？　プロパティの歴史的な値にこだわる場合、それをディメンションにする必要があることを意味しています。 - -例：私たちはアプリケーションに関するカスタムメトリクスを収集しています。1つのメトリクスは `latency` で、アプリケーションへのリクエストのレイテンシーをカウントします。顧客ごとにレイテンシーを分類して比較できるように `customer` ディメンションを持っています。私たちは、顧客が使用しているバージョン別にアプリケーションの `latency` を分類して比較したいと考え、プロパティ `version` を `customer` ディメンションに添付しました。最初はすべての顧客がアプリケーションバージョン1を使用しているので、`version:1` です。 - -現在、いくつかの顧客がアプリケーションのバージョン2を使用しているため、それらの顧客に対してプロパティを `version:2` に更新します。これらの顧客の `version` プロパティの値を更新すると、その顧客に関連するすべてのMTSに伝播します。これにより、これらの顧客が以前に `version:1` を使用していたという歴史が失われるため、歴史的な期間にわたって `version:1` と `version:2` の `latency` を比較する場合、正確なデータを得ることはできません。この場合、メトリクスの時間系列をユニークにするためにアプリケーションの `version` が必要ではないかもしれませんが、歴史的な値にこだわるために `version` をディメンションにする必要があります。 - -## 結局、いつ、ディメンションじゃなくてプロパティを使うの？ - -メトリクスに添付したいメタデータがあるが、取り込み時にはそれを知らない場合が第一の理由です。第二の理由は、ベストプラクティスとして、ディメンションである必要がなければ、それをプロパティにすることです。なぜでしょうか？ - -一つの理由は、現在、分析ジョブやチャートレンダリングあたりのMTSの上限が5Kであり、ディメンションが多いほど多くのMTSを生成することです。プロパティは完全に自由形式であり、MTSの数を増やすことなく、メトリクスやディメンションに必要な情報を追加することができます。 - -ディメンションは各データポイントと共に送信されるため、ディメンションが多いほど、より多くのデータを送信することになります。これは、クラウドプロバイダーがデータ転送に料金を請求する場合、コストが高くなる可能性があります。 - -プロパティを使う良い例としては、ホスト情報の追加などがあります。 `machine_type`, `processor`, `os` などの情報を確認することが重要ですが、これらをディメンションとして設定し、各ホストからのすべてのメトリクスと共に送信するのではなく、プロパティとして設定し、ホストディメンションに添付することができます。 - -例えば `host:server1` では、プロパティ `machine_type:ucs`, `processor:xeon-5560`, `os:rhel71` を設定します。`host:server1` というディメンションを持つメトリクスが入ってくるたびに、上記のすべてのプロパティが自動的に適用されます。 - -プロパティの使用例としては、各サービスのエスカレーション連絡先や、各顧客のSLAレベルを知りたい場合があります。これらの項目は、メトリクスをユニークに識別するために必要ではなく、歴史的な値にも関心がないため、プロパティにすることができます。プロパティはサービスディメンションや顧客ディメンションに追加され、これらのディメンションを持つすべてのメトリクスやMTSに適用されます。 - -## タグについてはどうですか？ - -タグは、メトリクスにコンテキストを与えたり整理するのに使われる、メタデータの3番目のタイプです。ディメンションやプロパティとは異なり、タグは `key:value` ペアではありません。タグはラベルやキーワードとして考えることができます。プロパティと同様に、タグは取り込み後にUIのCatalogやAPIを通じてプログラム的にデータに適用されます。タグはメトリクス、ディメンション、ディテクターなどの他のオブジェクトに適用することができます。 - -## タグを使う場面はどこですか？ - -タグが必要とされるのは、タグとオブジェクトの間に多対一の関係がある場合や、タグとそれに適用されるオブジェクト間に一対多の関係がある場合です。本質的に関連していないメトリクスをまとめるのに役立ちます。 - -例として、複数のアプリケーションを実行しているホストがある場合です。各アプリケーションに対してタグ（ラベル）を作成し、それぞれのホストに複数のタグを適用して、その上で実行されているアプリケーションをラベル付けします。 - -例：Server1は3つのアプリケーションを実行しています。タグ `app1`, `app2`, `app3` を作成し、ディメンション `host:server1` にこれら3つのタグをすべて適用します。 - -上記の例を拡張すると、アプリケーションからのメトリクスも収集しているとします。作成したタグを、アプリケーション自体から来るメトリクスに適用することができます。タグに基づいてフィルタリングすることで、アプリケーションに基づいてフィルタリングしながら、アプリケーションと関連するホストメトリクスの全体像を得ることができます。 - -例：App1は `service:application1` というディメンションでメトリクスを送信します。`service:application1` のディメンションにタグ `app1` を適用します。その後、チャートやダッシュボードでタグ `app1` でフィルタリングすることができます。 - -タグの他の使用例には、単一の可能な値を持つ二進状態があります。例として、カナリアテストを行い、カナリアデプロイを行った際に新しいコードを受け取ったホストをマークして、新しいコードを受け取らなかったホストとのパフォーマンスを比較しやすくすることがあります。単一の値 `canary` しかないため、`key:value` ペアは必要ありません。 - -ただし、タグでフィルタリングはできますが、groupBy関数では使用できないことに注意してください。groupBy関数は `key:value` ペアのキー部分を指定して実行され、そのキーの値に基づいて結果がグループ化されます。 - -## さらなる情報 - -カスタムメトリクスのディメンションを送信する方法に関する情報については、お使いのライブラリに関するクライアントライブラリのドキュメントをご覧ください。 - -APIを通じてメトリクスやディメンションにプロパティやタグを適用する方法については、 `/metric/:name`、`/dimension/:key/:value` に関するAPIドキュメントを参照してください。 - -UIのメタデータカタログでプロパティやタグを追加または編集する方法については、[Search the Metric Finder and Metadata catalog](https://docs.splunk.com/Observability/metrics-and-metadata/metrics-finder-metadata-catalog.html#use-the-metadata-catalog)で、**​Add or edit metadata** セクションをご覧ください。 diff --git a/content/ja/resources/faq.md b/content/ja/resources/faq.md deleted file mode 100644 index c55e5da18c..0000000000 --- a/content/ja/resources/faq.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: よくある質問とその回答 -titleTitle: FAQ -weight: 1 -description: オブザーバビリティ、DevOps、インシデント対応、Splunk On-Callに関連する一般的な質問とその回答を集めました。 -draft: false ---- - -オブザーバビリティ、DevOps、インシデント対応、Splunk On-Callに関連する一般的な質問とその回答を集めました。 - - -## Q: アラートとインシデント対応、インシデント管理の違いは？ - -A: アラート、インシデント対応、インシデント管理は関連する機能です。これらは一緒にインシデント対応および解決プロセスを構成します。 - -モニタリングやオブザーバビリティのツールはインシデント対応プラットフォームにアラートを送信します。これらのプラットフォームはアラートのコレクションを収集し、それらをインシデントとして相関させます。 - -これらのインシデントは記録のためにインシデント管理（ITSM）プラットフォームに記録されます。アラートは何かが起こったことを示すトリガーであり、インシデントへのコンテキストを提供します。 - -インシデントには、アラートの内容、インシデントが作成されてから関連するすべての活動、およびフォローされるオンコールポリシーが含まれます。ITSMは、インシデントがアクティブであるときおよび解決された後のインシデントを記録するシステムです。 - -インシデント対応および管理をより良く実践するために、これらのコンポーネントが必要になります。 - -{{% button %}}On-Call{{% /button %}} - -## Q: オブザーバビリティはモニタリングとは違うものですか？ - -A: モニタリングとオブザーバビリティの主な違いは、「既知の未知」と「未知の未知」の違いです。 - -モニタリングでは、オペレーターは通常、システムのアーキテクチャと要素に関する事前の知識を持っています。彼らは要素間の関係とそれに関連するメタデータを確実に予測することができます。モニタリングは、頻繁に変更されない状態のインフラストラクチャに適しています。 - -オブザーバビリティは、オペレーターがシステム内のすべての要素とそれらの関係を予測し、追跡する能力が限定されているシステム向けです。 - -オブザーバビリティは、従来のメトリクスのモニタリングを含む一連のプラクティスと技術です。 - -これらのプラクティスと技術を組み合わせることで、オペレーターはシステムのすべての要素に関する事前の知識がなくても、頻繁に変更がある複雑な環境を理解することができます。オブザーバビリティ技術は、環境の変動やメタデータの変化（カーディナリティ）を従来のモニタリングよりもよく考慮できるため、より静的なモニタリングと比較して優れています。 - -{{% button %}}Observability{{% /button %}} - -## Q: トレースとスパンとは何ですか？ - -A: トレースとスパンは、メトリクスとログと共に、現代のオブザーバビリティツールにフィードされるコアタイプのデータを構成します。それらは特定の要素と機能を持っていますが、一緒にうまく機能します。 - -マイクロサービスベースのアーキテクチャは分散しているため、システム内のトランザクションは完了する前に複数のサービスにアクセスします。これにより、問題の場所を正確に特定することが困難になります。トレースは、分散システム内のすべてのサービスを通るリクエストの完全なパスを追跡するための方法です。スパンは、各サービスでの時間のかかる操作です。トレースはスパンの結合したものであり、一緒になると個々のサービスプロセスについてより詳細な情報を提供します。メトリクスはシステムの健康状態の良いスナップショットを提供し、ログは問題を調査する際に深さを提供しますが、トレースとスパンはオペレーターに問題の源泉をより多くのコンテキストでナビゲートするのに役立ちます。これにより、インシデントの調査にかかる時間が節約され、現代のアーキテクチャの複雑さがサポートされます。 - -{{% button %}}APM{{% /button %}} - -## Q: サイドカーパターンとは何ですか？ - -A: サイドカーパターンは、関連するサービスをインフラストラクチャによって直接接続するためのデザインパターンです。関連するサービスは、接続されているアプリケーションロジックに機能を追加したりサポートしたりすることができます。これは、管理計画に関連するエージェントをアプリケーションサービスと共に展開する方法として広く使用されます。 - -オブザーバビリティでは、サイドカーサービスはアプリケーションロジックであり、そのサービスからデータを収集するエージェントです。このセットアップには、アプリケーションサービスを含むコンテナと、エージェントを実行するコンテナの2つが必要です。コンテナはポッドを共有し、ディスク、ネットワーク、名前空間などのリソースを共有します。また、一緒にデプロイされ、同じライフサイクルを共有します。 - -{{% button %}}Observability{{% /button %}} diff --git a/content/ja/resources/otel_tagging.md b/content/ja/resources/otel_tagging.md deleted file mode 100644 index 6068e52d59..0000000000 --- a/content/ja/resources/otel_tagging.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: OpenTelemetryとSplunkにおける、タグ付けのための命名規則 -linkTitle: OpenTelemetryでのタグ付け -description: 大規模な組織で OpenTelemetry を展開する際には、タグ付けのための標準化された命名規則を定義し、規則が遵守されるようにガバナンスプロセスを確立することが重要です。 -weight: 3 ---- - -## はじめに - -大規模な組織でOpenTelemetryを展開する際には、タグ付けのための標準化された命名規則を定義し、その規則が遵守されるようにガバナンスプロセスを設定することが非常に重要です。 - -これにより、OpenTelemetryを通じて収集されるMELTデータ（メトリクス、イベント、ログ、トレース）を、アラート、ダッシュボード作成、トラブルシューティングの目的で効率的に活用することが可能になります。また、Splunk Observability Cloudのユーザーが探しているデータを迅速に見つけることができます。 - -命名規則はまた、データを効果的に集約するためにも重要です。例えば、環境ごとのユニークなホストの数を数えたい場合、ホスト名と環境名を捉えるための標準化された規則を使用する必要があります。 - -## 属性 vs タグ - -先に進む前に、用語についての注意をしておきましょう。OpenTelemetryの「タグ」は「属性（attribute）」と呼ばれます。属性は、手動または自動の計装を通じて、メトリクス、ログ、トレースに添付することができます。 - -属性はまた、[Resource Detection processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourcedetectionprocessor)などのさまざまなプロセッサを使用して、OpenTelemetryコレクターレベルでメトリクス、ログ、トレースに添付することもできます。 - -Splunk Observability Cloudに属性付きのトレースが取り込まれると、それらは「タグ」として利用可能になります。オプションとして、トレースの一部として収集された属性は、[Troubleshooting Metric Sets](https://docs.splunk.com/Observability/apm/span-tags/metricsets.html#troubleshooting-metricsets)の作成に使用され、[Tag Spotlight](https://docs.splunk.com/Observability/apm/span-tags/tag-spotlight.html)などのさまざまな機能と共に使用することができます。 - -また、属性は[Monitoring Metric Sets](https://docs.splunk.com/Observability/apm/span-tags/metricsets.html#monitoring-metricsets)の作成に使用され、アラートのトリガーとして使用することもできます。 - -## リソースに関するセマンティック規約 - -[OpenTelemetry リソースセマンティック規約](https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/resource/semantic_conventions#resource-semantic-conventions)は、組織が標準化すべき属性を決定する際の出発点として使用できます。以下のセクションでは、よく使用される属性のいくつか見ていきましょう。 - -### サービス属性 - -監視されるサービスを記述するために多くの属性が使用されます。 - -`service.name` はサービスの論理名を定義する必須の属性です。OpenTelemetry SDKによって自動的に追加されますが、カスタマイズすることができます。これはシンプルに保つことが最善です（例えば、`inventoryservice` は `inventoryservice-prod-hostxyz` よりも良いでしょう。他の属性を使用してサービスの他の側面を捉えることができます）。 - -以下のサービス属性が推奨されます - -- `service.namespace` はサービスを所有するチームを識別するために使用されます -- `service.instance.id` はサービスのユニークなインスタンスを識別するために使用されます -- `service.version` はサービスのバージョンを識別するために使用されます - -### テレメトリSDK - -これらの属性はSDKによって自動的に設定され、使用されている計測ライブラリに関する情報を記録します - -- `telemetry.sdk.name` は通常 `opentelemetry` に設定されます。 -- `telemetry.sdk.language` はSDKの言語で、例えば `java` です。 -- `telemetry.sdk.version` は使用されているSDKのバージョンを識別します。 - -### コンテナ - - -コンテナで実行されるサービスには、`container.id`、`container.name`、`container.image.name` など、コンテナのランタイムを記述するための多くの属性が使用されます。完全なリストは[こちら](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/container.md)で確認できます。 - -### ホスト - -これらの属性は、サービスが実行されているホストを記述し、`host.id`、`host.name`、`host.arch` などの属性を含みます。完全なリストは[こちら](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/host.md)で確認できます。 - -### デプロイ環境 - -`deployment.environment` 属性は、サービスがデプロイされている環境（**staging** や **production** など）を識別するために使用されます。 - -Splunk Observability Cloudは、この属性を使用して関連コンテンツを有効する（詳細は[こちら](https://docs.splunk.com/observability/metrics-and-metadata/enablerelatedcontent.html)）ため、この属性を含めることが重要です。 - -### クラウド - -AWSなどのパブリッククラウド環境で実行されるサービスに関する情報を捉えるための属性もあります。これには、`cloud.provider`、`cloud.account.id`、`cloud.region` が含まれます。 - -属性の完全なリストは[こちら](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/cloud.md)で確認できます。 - -一部のクラウドプロバイダー、例えば [GCP](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/cloud_provider/gcp/README.md) は、独自のセマンティック規則を定義しています。 - -### Kubernetes - - -Kubernetesで実行されるアプリケーションにも、いくつかの標準化された属性があります。これらの多くは、SplunkのOpenTelemetryコレクター配布によって自動的に追加されます（詳細は[こちら](https://docs.splunk.com/observability/metrics-and-metadata/enablerelatedcontent.html#splunk-infrastructure-monitoring)）。 - -属性は、例えば `k8s.cluster.name`、`k8s.node.name`、`k8s.pod.name`、`k8s.namespace.name`、`kubernetes.workload.name` などがあります。 - -## カスタム属性のベストプラクティス - -多くの組織では、OpenTelemetryのリソースセマンティック規約で定義されているもの以上の属性が欲しくなります。 - -この場合、セマンティック規約にすでに含まれている属性名との命名競合を避けることが重要です。つまり、特定の属性名を命名規則に決定する前に、セマンティック規約をチェックすると良いでしょう。 - -属性名の命名規則に加えて、属性値も考慮する必要があります。例えば、アプリケーションが属する特定のビジネスユニットをキャプチャしたい場合、簡単にかつ効果的にフィルタリングするために、標準化されたビジネスユニット値のリストも持ちたいでしょう。 - -OpenTelemetryコミュニティでは、属性の命名に従うべきガイドラインも提供しています。[こちら](https://opentelemetry.io/docs/specs/otel/common/attribute-naming/)で見つけることができます。 - -[Recommendations for Application Developers](https://opentelemetry.io/docs/specs/otel/common/attribute-naming/#recommendations-for-application-developers)は、私たちの議論に最も関連しています。 - -そこでは、以下を推奨しています - -* `com.acme.shopname` のように、会社のドメイン名で属性名を接頭辞として付けること（属性が社内だけでなく外部で使用される可能性がある場合） -* 属性が特定のアプリケーションに固有であり、組織内でのみ使用される場合は、アプリケーション名で属性名に接頭辞を付けること -* 既存のOpenTelemetryセマンティック規約の名前を属性名の接頭辞として使用しないこと -* 異なる組織や業界全体で一般的なニーズがある場合は、あなたの属性名をOpenTelemetry仕様に追加する提案を検討すること -* `otel.*` で始まる属性名は避けること。これはOpenTelemetry仕様の使用に予約されています - -## カーディナリティに関する考慮事項 - -属性名と値の命名基準を決定する際に考慮すべき最後の点は、メトリクスのカーディナリティに関連しています。 - -のカーディナリティは、メトリクス名とそれに関連する次元の組み合わせによって生成されるユニークなメトリクス時系列（MTS: Metric Time Series）の数として定義されます。 - -メトリクスは、ディメンションの数とそれらのディメンションが持つユニークな値の数が多い場合に、高いカーディナリティを持つことになります。 - -例えば、あなたのアプリケーションが `custom.metric` という名前のメトリクスのデータを送信するとします。属性がない場合、`custom.metric` は単一のメトリクス時系列（MTS）を生成します。 - -一方で、`custom.metric` が `customer.id` という属性を含み、数千の顧客ID値がある場合、これは数千のメトリクス時系列を生成し、コストやクエリ性能に影響を与える可能性があります。 - -Splunk Observability Cloudは、メトリクスの使用量を管理するための[レポート](https://docs.splunk.com/Observability/infrastructure/metrics-pipeline/metrics-usage-report.html)を提供しています。そして、望ましくないディメンションを削除する[ルール](https://docs.splunk.com/Observability/infrastructure/metrics-pipeline/use-metrics-pipeline.html)を作成することができます。しかし、最初の防衛線は、属性名と値の組み合わせがどのようにメトリクスのカーディナリティを増加させるかを理解することです。 - -## まとめ - -このドキュメントでは、大規模なOpenTelemetry計装の展開を開始する前に、OpenTelemetryタグの命名規則を定義することの重要性を強調しました。 - -OpenTelemetryのリソースセマンティック規約がいくつかの属性の命名規則を定義し、多くの属性がOpenTelemetry SDKやOpenTelemetryコレクター内で動作するプロセッサーを通じて自動的に収集される方法について説明しました。 - -最後に、リソースセマンティック規約が組織のニーズに十分でない場合に、属性名を作成するためのベストプラクティスを共有しました。 diff --git a/content/ja/scenarios/isovalent-cilium-integration/examples/Cilium by Isovalent.json b/content/ja/scenarios/isovalent-cilium-integration/examples/Cilium by Isovalent.json new file mode 100644 index 0000000000..cc209ee2aa --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/examples/Cilium by Isovalent.json @@ -0,0 +1,5071 @@ +{ + "chartExports": [ + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYhpKA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Agent not running", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Agent not running", + "label": "Agent not running", + "paletteIndex": 4, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-*') and (filter('k8s.pod.phase', 'Pending') or filter('k8s.pod.phase', 'Failed') or filter('k8s.pod.phase', 'Unknown'))).count().publish(label='Agent not running')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYhpLA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Envoy restarts", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Envoy restarts", + "label": "Envoy restarts", + "paletteIndex": 1, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "C = data('k8s.container.restarts', filter('k8s.container.name', 'cilium-envoy'), rollup='sum').publish(label='Envoy restarts')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYk_TA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Agent Running", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Agent running", + "label": "Agent running", + "paletteIndex": 13, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "B = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-*') and filter('k8s.pod.phase', 'Running')).count().publish(label='Agent running')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYl2xAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Proxy running", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "DNS Proxy running", + "label": "DNS Proxy running", + "paletteIndex": 11, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "\nF = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-dnsproxy-*') and filter('k8s.pod.phase', 'Running')).count().publish(label='DNS Proxy running', color='yellow')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYmN4A0Aw", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Operator Running", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Operator running", + "label": "Operator running", + "paletteIndex": 13, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "\nD = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-operator-*') and filter('k8s.pod.phase', 'Running')).count().publish(label='Operator running', color='blue')\n\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYmRsAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Proxy not running", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "DNS Proxy not running", + "label": "DNS Proxy not running", + "paletteIndex": 1, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "\nE = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-dnsproxy-*') and (filter('k8s.pod.phase', 'Pending') or filter('k8s.pod.phase', 'Failed') or filter('k8s.pod.phase', 'Unknown'))).count().publish(label='DNS Proxy not running', color='purple')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYmT3A0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Client Agent Error Rate", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "${pod} ${level}", + "label": "${pod} ${level}", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_errors_warnings_total', filter=filter('k8s_app', 'cilium', 'pod', 'cilium-*', 'namespace', 'kube-system', 'level', 'error'), rollup='rate').sum(by=['pod', 'level']).above(0).top(count=3).publish(label='${pod} ${level}')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYmrGA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": " ", + "options": { + "markdown": "
\nCilium Pod Restarts\n
", + "type": "Text" + }, + "packageSpecifications": "", + "programText": "", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYnRdAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Agent Restarts", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Agent restarts", + "label": "Agent restarts", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('k8s.container.restarts', filter=filter('k8s.container.name', 'cilium-agent')).sum().publish(label='Agent restarts')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYnZmA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Operator not Running", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Operator not running", + "label": "Operator not running", + "paletteIndex": 4, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "\nC = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-operator-*') and (filter('k8s.pod.phase', 'Pending') or filter('k8s.pod.phase', 'Failed') or filter('k8s.pod.phase', 'Unknown'))).count().publish(label='Operator not running', color='orange')\n\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "Tracks the running state of Cilium Pods such as the Agent and the Operator.", + "id": "G2xYnfDAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Pod Running State", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_metric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Agent not running", + "label": "Agent not running", + "paletteIndex": 8, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "Agent running", + "label": "Agent running", + "paletteIndex": 14, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "Operator not running", + "label": "Operator not running", + "paletteIndex": 5, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "Operator running", + "label": "Operator running", + "paletteIndex": 1, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "DNS Proxy not running", + "label": "DNS Proxy not running", + "paletteIndex": 11, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "DNS Proxy running", + "label": "DNS Proxy running", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-*') and (filter('k8s.pod.phase', 'Pending') or filter('k8s.pod.phase', 'Failed') or filter('k8s.pod.phase', 'Unknown'))).count().publish(label='Agent not running', color='red')\n\nB = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-*') and filter('k8s.pod.phase', 'Running')).count().publish(label='Agent running', color='green')\n\nC = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-operator-*') and (filter('k8s.pod.phase', 'Pending') or filter('k8s.pod.phase', 'Failed') or filter('k8s.pod.phase', 'Unknown'))).count().publish(label='Operator not running', color='orange')\n\nD = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-operator-*') and filter('k8s.pod.phase', 'Running')).count().publish(label='Operator running', color='blue')\n\nE = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-dnsproxy-*') and (filter('k8s.pod.phase', 'Pending') or filter('k8s.pod.phase', 'Failed') or filter('k8s.pod.phase', 'Unknown'))).count().publish(label='DNS Proxy not running', color='purple')\n\nF = data('k8s.pod.phase', filter=filter('k8s.pod.name', 'cilium-dnsproxy-*') and filter('k8s.pod.phase', 'Running')).count().publish(label='DNS Proxy running', color='yellow')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYn6ZA0BE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": " ", + "options": { + "markdown": "
\nCilium Pod Running State\n
", + "type": "Text" + }, + "packageSpecifications": "", + "programText": "", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xYz29A0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Operator restarts", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Operator restarts", + "label": "Operator restarts", + "paletteIndex": 4, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "B = data('k8s.container.restarts', filter=filter('k8s.container.name', 'cilium-operator')).sum().publish(label='Operator restarts')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xbGwNA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Max CNI Add Latency", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Max CNI Add Latency", + "label": "Max CNI Add Latency", + "paletteIndex": 11, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_api_limiter_processing_duration_seconds', \n filter=filter('api_call', 'endpoint-create') and\n filter('value', 'mean')).max().publish(label='Max CNI Add Latency')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xbWUkA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Max CNI Delete Latency", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Max CNI Delete Latency", + "label": "Max CNI Delete Latency", + "paletteIndex": 4, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_api_limiter_processing_duration_seconds', \n filter=filter('api_call', 'endpoint-delete') and\n filter('value', 'mean')).max().publish(label='Max CNI Delete Latency')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xbut_A0AE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Max CNI Error Rate", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Max CNI Error Rate", + "label": "Max CNI Error Rate", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_api_limiter_processed_requests_total', filter=filter('api_call', 'endpoint*') and filter('outcome', 'fail'), rollup='rate').sum().max().publish(label='Max CNI Error Rate')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xcD2WA4AE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Max CNI Delete Latency", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Max CNI Delete Latency", + "label": "Max CNI Delete Latency", + "paletteIndex": 4, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_api_limiter_processing_duration_seconds', filter=filter('api_call', 'endpoint-delete') and filter('value', 'mean')).max().publish(label='Max CNI Delete Latency')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xcTMAAwAE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Max CNI Add Latency", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Max CNI Add Latency", + "label": "Max CNI Add Latency", + "paletteIndex": 11, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_api_limiter_processing_duration_seconds', filter=filter('api_call', 'endpoint-create') and filter('value', 'mean')).max().publish(label='Max CNI Add Latency')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xcdR5AwAM", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Max CNI Error Rate", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Max CNI Error Rate", + "label": "Max CNI Error Rate", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_api_limiter_processed_requests_total', filter=filter('api_call', 'endpoint*') and filter('outcome', 'fail'), rollup='rate').sum().max().publish(label='Max CNI Error Rate')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xdLAdA4AE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cluster IPv4 IPAM Utilization", + "options": { + "colorBy": "Scale", + "colorScale": null, + "colorScale2": [ + { + "gt": 90, + "gte": null, + "lt": null, + "lte": 100, + "paletteIndex": 16 + }, + { + "gt": 80, + "gte": null, + "lt": null, + "lte": 90, + "paletteIndex": 17 + }, + { + "gt": 70, + "gte": null, + "lt": null, + "lte": 80, + "paletteIndex": 18 + }, + { + "gt": null, + "gte": 0, + "lt": null, + "lte": 70, + "paletteIndex": 20 + } + ], + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "IPv4 IPAM Utilization %", + "label": "IPv4 IPAM Utilization %", + "paletteIndex": null, + "plotType": null, + "valuePrefix": "%", + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Radial", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "capacity = data('cilium_ipam_capacity', filter('family', 'ipv4')).sum()\n\nused = data('cilium_ip_addresses', filter('family', 'ipv4')).sum()\n\nutilization = (used / capacity * 100).publish(label='IPv4 IPAM Utilization %')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xfPJWA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Bottom-K Node Capacity IPv4", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.node.name" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": false, + "property": "k8s.container.name" + }, + { + "enabled": false, + "property": "k8s.namespace.name" + }, + { + "enabled": false, + "property": "k8s.cluster.name" + }, + { + "enabled": false, + "property": "k8s.pod.uid" + }, + { + "enabled": false, + "property": "os.type" + }, + { + "enabled": true, + "property": "url.scheme" + }, + { + "enabled": false, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "service.instance.id" + }, + { + "enabled": true, + "property": "server.port" + }, + { + "enabled": false, + "property": "host.name" + }, + { + "enabled": false, + "property": "k8s.daemonset.name" + }, + { + "enabled": false, + "property": "service.name" + }, + { + "enabled": false, + "property": "family" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_ipam_capacity - Sum by k8s.node.name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "cilium_ip_addresses - Sum by k8s.node.name", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A-B - Sum by k8s.node.name - Bottom 3", + "label": "C", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_ipam_capacity', filter=filter('k8s.namespace.name', 'kube-system') and filter('family', 'ipv4')).sum(by=['k8s.node.name']).publish(label='A', enable=False)\nB = data('cilium_ip_addresses', filter=filter('k8s.namespace.name', 'kube-system') and filter('family', 'ipv4')).sum(by=['k8s.node.name']).publish(label='B', enable=False)\nC = (A-B).sum(by=['k8s.node.name']).bottom(count=3).publish(label='C')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G2xfY84A0A4", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "% of Pods in State", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "endpoint_state", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "${endpoint_state}", + "label": "${endpoint_state}", + "paletteIndex": null, + "plotType": null, + "valuePrefix": "%", + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "by_state = data('cilium_endpoint_state').sum(by=['endpoint_state'])\n\ntotal = data('cilium_endpoint_state').sum()\n\npercentage = (by_state / total * 100).publish(label='${endpoint_state}')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3Ixp4NA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Kubernetes Event Rate", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "status", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_kubernetes_events_total - Sum by status", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": "", + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_kubernetes_events_total', filter=filter('k8s.namespace.name', 'kube-system')).sum(by=['status']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3IybEOAwAE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Kubernetes Client API Latency", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "Histogram", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_metric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "P99", + "label": "P99", + "paletteIndex": 5, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + }, + { + "displayName": "P95", + "label": "P95", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + }, + { + "displayName": "P50", + "label": "P50", + "paletteIndex": 1, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_k8s_client_api_latency_time_seconds_bucket').percentile(pct=99).publish(label='P99')\nB = data('cilium_k8s_client_api_latency_time_seconds_bucket').percentile(pct=95).publish(label='P95')\nC = data('cilium_k8s_client_api_latency_time_seconds_bucket').percentile(pct=50).publish(label='P50')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3I0aqVAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Kubernetes Client API Rate Limiter Latency", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "Histogram", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_metric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "P99", + "label": "P99", + "paletteIndex": 4, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + }, + { + "displayName": "P95", + "label": "P95", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + }, + { + "displayName": "P50", + "label": "P50", + "paletteIndex": 1, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "C = data('cilium_k8s_client_rate_limiter_duration_seconds_bucket').percentile(pct=99).publish(label='P99')\nD = data('cilium_k8s_client_rate_limiter_duration_seconds_bucket').percentile(pct=95).publish(label='P95')\nE = data('cilium_k8s_client_rate_limiter_duration_seconds_bucket').percentile(pct=50).publish(label='P50')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3I3r0eA4AI", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Map Pressure", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "map_name", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_bpf_map_pressure", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": "", + "valueSuffix": "", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_bpf_map_pressure').publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3I3r4BAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Error Rate by Map", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "map_name", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_bpf_map_ops_total - Sum by map_name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_bpf_map_ops_total', filter=filter('k8s.namespace.name', 'kube-system') and filter('outcome', 'fail')).sum(by=['map_name']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3I4Tv-AwBE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Map Pressure (Top 3)", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": 100, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "map_name", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_bpf_map_pressure - Top 3 by map_name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_bpf_map_pressure').top(by=['map_name'], count=3).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3I6czPA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Controller Run Outcome Rate", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_controllers_runs_total - Sum by status", + "label": "A", + "paletteIndex": 14, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Second", + "yAxis": 0 + } + ], + "refreshInterval": 1000, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_controllers_runs_total').sum(by=['status']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3I6xhLA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Per Controller Error Rate", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_controllers_group_runs_total - Sum by group_name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_controllers_group_runs_total', filter=filter('status', 'failure')).sum(by=['group_name']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3I7KPkA0DY", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Controller Run Outcome Rate", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "status", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_controllers_runs_total - Sum by status", + "label": "A", + "paletteIndex": null, + "plotType": "AreaChart", + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Second", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_controllers_runs_total').sum(by=['status']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3I8dvpA4Aw", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Failed Reconciliation Tasks", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_controllers_group_runs_total - Sum by group_name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_controllers_group_runs_total', filter=filter('status', 'failure')).sum(by=['group_name']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JCeQnAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "L7 Request Processing Rate", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "rule", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_policy_l7_total - Sum by proxy_type,rule", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_policy_l7_total').sum(by=['proxy_type', 'rule']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JCe47A4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Proxy Upstream Reply Seconds Duration", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_proxy_upstream_reply_seconds_bucket - P95 by le,error", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_proxy_upstream_reply_seconds_bucket').percentile(pct=95, by=['le', 'error']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JCfXbA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Proxy Upstream Reply Seconds Duration", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "protocol_l7", + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "", + "label": "A", + "paletteIndex": 4, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + }, + { + "displayName": "", + "label": "B", + "paletteIndex": 10, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Millisecond", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_proxy_upstream_reply_seconds_bucket', rollup='delta').percentile(pct=50, by=['le', 'protocol_l7']).publish(label='A')\nB = data('cilium_proxy_upstream_reply_seconds_bucket', rollup='delta').percentile(pct=95, by=['le', 'protocol_l7']).publish(label='B')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JCq_aA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "L7 Request Processing Rate", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": true, + "legendOptions": { + "fields": [ + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": true, + "property": "proxy_type" + }, + { + "enabled": true, + "property": "rule" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "cilium_policy_l7_total - Sum by proxy_type,rule", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "-value", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('cilium_policy_l7_total').sum(by=['proxy_type', 'rule']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JNojHA0A0", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Agent Container Memory Utilization", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "container.memory.rss - Sum by k8s.pod.name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A - Top 3", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Megabit", + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('container.memory.rss', filter=filter('k8s.namespace.name', 'kube-system')).sum(by=['k8s.pod.name']).publish(label='A', enable=False)\nB = (A).top(count=3).publish(label='B')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JNpbiA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Agent CPU Runtime Latency", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_metric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "P95", + "label": "A", + "paletteIndex": 14, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Microsecond", + "yAxis": 0 + }, + { + "displayName": "P50", + "label": "C", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Microsecond", + "yAxis": 0 + }, + { + "displayName": "A*100", + "label": "D", + "paletteIndex": 14, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Microsecond", + "yAxis": 0 + }, + { + "displayName": "C*100", + "label": "E", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Microsecond", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = histogram('go_sched_latencies_seconds', filter=filter('k8s.pod.name', 'cilium-*')).percentile(pct=95, by=['k8s.pod.name']).percentile(pct=50).publish(label='A', enable=False)\nC = histogram('go_sched_latencies_seconds', filter=filter('k8s.pod.name', 'cilium-*')).percentile(pct=50, by=['k8s.pod.name']).percentile(pct=50).publish(label='C', enable=False)\nD = (A*100).publish(label='D')\nE = (C*100).publish(label='E')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JNp-mA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Agent CPU Runtime Latency (P50)", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": true, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "go_sched_latencies_seconds", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": "", + "valueSuffix": "", + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A*100 - Top 3", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Microsecond", + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "-value", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = histogram('go_sched_latencies_seconds', filter=filter('k8s.pod.name', 'cilium-*')).percentile(pct=50, by=['k8s.pod.name']).publish(label='A', enable=False)\nB = (A*100).top(count=3).publish(label='B')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JNp_qA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Agent Container CPU Utilization", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": true, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": true, + "property": "k8s.container.name" + }, + { + "enabled": true, + "property": "k8s.namespace.name" + }, + { + "enabled": true, + "property": "k8s.cluster.name" + }, + { + "enabled": true, + "property": "host.image.id" + }, + { + "enabled": true, + "property": "k8s.pod.uid" + }, + { + "enabled": true, + "property": "os.type" + }, + { + "enabled": true, + "property": "host.type" + }, + { + "enabled": true, + "property": "cloud.availability_zone" + }, + { + "enabled": true, + "property": "host.name" + }, + { + "enabled": true, + "property": "cloud.platform" + }, + { + "enabled": true, + "property": "host.id" + }, + { + "enabled": true, + "property": "cloud.region" + }, + { + "enabled": true, + "property": "cloud.provider" + }, + { + "enabled": true, + "property": "k8s.node.name" + }, + { + "enabled": true, + "property": "cloud.account.id" + }, + { + "enabled": true, + "property": "host" + }, + { + "enabled": true, + "property": "container.image.tag" + }, + { + "enabled": true, + "property": "aws.ecs.container.image.id" + }, + { + "enabled": true, + "property": "container.id" + }, + { + "enabled": true, + "property": "aws.ecs.docker.name" + }, + { + "enabled": true, + "property": "container.name" + }, + { + "enabled": true, + "property": "aws.ecs.container.know_status" + }, + { + "enabled": true, + "property": "container.image.name" + }, + { + "enabled": true, + "property": "aws.ecs.launchtype" + }, + { + "enabled": true, + "property": "aws.ecs.task.pull_stopped_at" + }, + { + "enabled": true, + "property": "aws.log.group.arns" + }, + { + "enabled": true, + "property": "aws.ecs.task.pull_started_at" + }, + { + "enabled": true, + "property": "aws.ecs.task.version" + }, + { + "enabled": true, + "property": "aws.log.stream.names" + }, + { + "enabled": true, + "property": "aws.ecs.task.launch_type" + }, + { + "enabled": true, + "property": "aws.log.stream.arns" + }, + { + "enabled": true, + "property": "aws.ecs.container.created_at" + }, + { + "enabled": true, + "property": "aws.ecs.task.arn" + }, + { + "enabled": true, + "property": "aws.ecs.service.name" + }, + { + "enabled": true, + "property": "aws.ecs.cluster.name" + }, + { + "enabled": true, + "property": "aws.ecs.task.known_status" + }, + { + "enabled": true, + "property": "aws.ecs.task.family" + }, + { + "enabled": true, + "property": "aws.ecs.task.id" + }, + { + "enabled": true, + "property": "aws.ecs.container.started_at" + }, + { + "enabled": true, + "property": "aws.ecs.cluster.arn" + }, + { + "enabled": true, + "property": "aws.log.group.names" + }, + { + "enabled": true, + "property": "aws.ecs.task.revision" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "container.cpu.usage - Rate by k8s.pod.name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "container.cpu.usage.total", + "label": "C", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A - Top 3", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Megabit", + "yAxis": 0 + }, + { + "displayName": "container.cpu.usage.total", + "label": "D", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('container.cpu.usage', filter=filter('k8s.namespace.name', 'kube-system')).rate(by=['k8s.pod.name']).publish(label='A', enable=False)\nC = data('container.cpu.usage.total').publish(label='C', enable=False)\nB = (A).top(count=3).publish(label='B')\nD = data('container.cpu.usage.total').publish(label='D', enable=False)", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JNqCnAwAM", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Agent CPU Runtime Latency (P95)", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": true, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "go_sched_latencies_seconds", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": "", + "valueSuffix": "", + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A*100 - Top 3", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Microsecond", + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "-value", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = histogram('go_sched_latencies_seconds').percentile(pct=95, by=['k8s.pod.name']).publish(label='A', enable=False)\nB = (A*100).top(count=3).publish(label='B')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JNzVIA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Agent Container Memory Utilization", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "container.memory.rss - Sum by k8s.pod.name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A - Top 3", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Megabit", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('container.memory.rss', filter=filter('k8s.namespace.name', 'kube-system')).sum(by=['k8s.pod.name']).publish(label='A', enable=False)\nB = (A).top(count=3).publish(label='B')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3JOUIJA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium Agent Container CPU Utilization", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": true, + "property": "k8s.container.name" + }, + { + "enabled": true, + "property": "k8s.namespace.name" + }, + { + "enabled": true, + "property": "k8s.cluster.name" + }, + { + "enabled": true, + "property": "host.image.id" + }, + { + "enabled": true, + "property": "k8s.pod.uid" + }, + { + "enabled": true, + "property": "os.type" + }, + { + "enabled": true, + "property": "host.type" + }, + { + "enabled": true, + "property": "cloud.availability_zone" + }, + { + "enabled": true, + "property": "host.name" + }, + { + "enabled": true, + "property": "cloud.platform" + }, + { + "enabled": true, + "property": "host.id" + }, + { + "enabled": true, + "property": "cloud.region" + }, + { + "enabled": true, + "property": "cloud.provider" + }, + { + "enabled": true, + "property": "k8s.node.name" + }, + { + "enabled": true, + "property": "cloud.account.id" + }, + { + "enabled": true, + "property": "host" + }, + { + "enabled": true, + "property": "container.image.tag" + }, + { + "enabled": true, + "property": "aws.ecs.container.image.id" + }, + { + "enabled": true, + "property": "container.id" + }, + { + "enabled": true, + "property": "aws.ecs.docker.name" + }, + { + "enabled": true, + "property": "container.name" + }, + { + "enabled": true, + "property": "aws.ecs.container.know_status" + }, + { + "enabled": true, + "property": "container.image.name" + }, + { + "enabled": true, + "property": "aws.ecs.launchtype" + }, + { + "enabled": true, + "property": "aws.ecs.task.pull_stopped_at" + }, + { + "enabled": true, + "property": "aws.log.group.arns" + }, + { + "enabled": true, + "property": "aws.ecs.task.pull_started_at" + }, + { + "enabled": true, + "property": "aws.ecs.task.version" + }, + { + "enabled": true, + "property": "aws.log.stream.names" + }, + { + "enabled": true, + "property": "aws.ecs.task.launch_type" + }, + { + "enabled": true, + "property": "aws.log.stream.arns" + }, + { + "enabled": true, + "property": "aws.ecs.container.created_at" + }, + { + "enabled": true, + "property": "aws.ecs.task.arn" + }, + { + "enabled": true, + "property": "aws.ecs.service.name" + }, + { + "enabled": true, + "property": "aws.ecs.cluster.name" + }, + { + "enabled": true, + "property": "aws.ecs.task.known_status" + }, + { + "enabled": true, + "property": "aws.ecs.task.family" + }, + { + "enabled": true, + "property": "aws.ecs.task.id" + }, + { + "enabled": true, + "property": "aws.ecs.container.started_at" + }, + { + "enabled": true, + "property": "aws.ecs.cluster.arn" + }, + { + "enabled": true, + "property": "aws.log.group.names" + }, + { + "enabled": true, + "property": "aws.ecs.task.revision" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "k8s.pod.name", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "container.cpu.usage - Rate by k8s.pod.name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A - Top 3", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": "Megabit", + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('container.cpu.usage', filter=filter('k8s.namespace.name', 'kube-system')).rate(by=['k8s.pod.name']).publish(label='A', enable=False)\nB = (A).top(count=3).publish(label='B')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PuRQWA0AI", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Egress Policy Verdict Rate by Match", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "match", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_policy_verdicts_total - Sum by match", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_policy_verdicts_total', filter=filter('direction', 'egress'), rollup='rate').sum(by=['match']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PuRr_A0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Egress Policy Verdict Rate by Action", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "action", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_policy_verdicts_total - Sum by action", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_policy_verdicts_total', filter=filter('direction', 'egress'), rollup='rate').sum(by=['action']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PufbiAwAE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Ingress Policy Verdict Rate by Match", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "match", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_policy_verdicts_total - Sum by match", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_policy_verdicts_total', filter=filter('direction', 'ingress'), rollup='rate').sum(by=['match']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3Pu8VQA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Ingress Policy Verdict Rate by Action", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "action", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_policy_verdicts_total - Sum by action", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_policy_verdicts_total', filter=filter('direction', 'ingress'), rollup='rate').sum(by=['action']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PwUk3A0AE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Current Egress Policy Verdict Rate Per Minute", + "options": { + "columnSizes": {}, + "groupBy": [], + "groupBySort": "Descending", + "hideMissingValues": false, + "legendOptions": { + "fields": null + }, + "maximumPrecision": null, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Policy Verdicts by Source and Destination", + "label": "Policy Verdicts by Source and Destination", + "valuePrefix": "", + "valueSuffix": "", + "valueUnit": null + } + ], + "refreshInterval": null, + "sortBy": "", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "TableChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "data('hubble_policy_verdicts_total', filter=filter('direction','egress')).mean(over='1m').sum(by=['destination_namespace', 'destination', 'source_namespace', 'source', 'match','action']).scale(60).publish(label='Policy Verdicts by Source and Destination')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PwgqdA4AI", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Current ingress Policy Verdict Rate Per Minute", + "options": { + "columnSizes": {}, + "groupBy": [ + "None" + ], + "groupBySort": "Descending", + "hideMissingValues": false, + "legendOptions": { + "fields": null + }, + "maximumPrecision": null, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Policy Verdicts by Source and Destination", + "label": "Policy Verdicts by Source and Destination", + "valuePrefix": "", + "valueSuffix": "", + "valueUnit": null + } + ], + "refreshInterval": null, + "sortBy": "", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "TableChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "data('hubble_policy_verdicts_total', filter=filter('direction','ingress')).mean(over='1m').sum(by=['destination_namespace', 'destination', 'source_namespace', 'source', 'match','action']).scale(60).publish(label='Policy Verdicts by Source and Destination')", + "relatedDetectorIds": [], + "tags": [] + } + } + ], + "crossLinkExports": [], + "dashboardExports": [ + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G2xYnfDAwAA", + "column": 0, + "height": 1, + "row": 0, + "width": 12 + }, + { + "chartId": "G2xYn6ZA0BE", + "column": 0, + "height": 2, + "row": 1, + "width": 3 + }, + { + "chartId": "G2xYl2xAwAA", + "column": 9, + "height": 1, + "row": 1, + "width": 3 + }, + { + "chartId": "G2xYk_TA0AA", + "column": 3, + "height": 1, + "row": 1, + "width": 3 + }, + { + "chartId": "G2xYmN4A0Aw", + "column": 6, + "height": 1, + "row": 1, + "width": 3 + }, + { + "chartId": "G2xYhpKA4AA", + "column": 3, + "height": 1, + "row": 2, + "width": 3 + }, + { + "chartId": "G2xYnZmA0AA", + "column": 6, + "height": 1, + "row": 2, + "width": 3 + }, + { + "chartId": "G2xYmRsAwAA", + "column": 9, + "height": 1, + "row": 2, + "width": 3 + }, + { + "chartId": "G2xYmrGA0AA", + "column": 0, + "height": 1, + "row": 3, + "width": 3 + }, + { + "chartId": "G2xYnRdAwAA", + "column": 3, + "height": 1, + "row": 3, + "width": 3 + }, + { + "chartId": "G2xYz29A0AA", + "column": 6, + "height": 1, + "row": 3, + "width": 3 + }, + { + "chartId": "G2xYhpLA0AA", + "column": 9, + "height": 1, + "row": 3, + "width": 3 + }, + { + "chartId": "G2xYmT3A0AA", + "column": 0, + "height": 1, + "row": 4, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "Provides high level health indicators on Cilium components.", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [ + { + "NOT": false, + "applyIfExists": false, + "property": "k8s.cluster.name", + "value": "ocp-vbridge" + } + ], + "time": null, + "variables": [] + }, + "groupId": "G2xYdM9AwAA", + "groupName": "Cilium by Isovalent", + "id": "G2xYjdwAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "High-Level Health", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3JNpbiA4AA", + "column": 8, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G3JNqCnAwAM", + "column": 0, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G3JNp-mA0AA", + "column": 4, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G3JNp_qA4AA", + "column": 6, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3JNzVIA4AA", + "column": 0, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3JNojHA0A0", + "column": 0, + "height": 1, + "row": 2, + "width": 6 + }, + { + "chartId": "G3JOUIJA0AA", + "column": 6, + "height": 1, + "row": 2, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [], + "time": null, + "variables": [] + }, + "groupId": "G2xYdM9AwAA", + "groupName": "Cilium by Isovalent", + "id": "G3JNp-rA0AM", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "Cilium System CPU/Memory Utilization", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G2xbut_A0AE", + "column": 0, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G2xbGwNA0AA", + "column": 4, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G2xbWUkA0AA", + "column": 8, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G2xcdR5AwAM", + "column": 0, + "height": 1, + "row": 1, + "width": 4 + }, + { + "chartId": "G2xcD2WA4AE", + "column": 8, + "height": 1, + "row": 1, + "width": 4 + }, + { + "chartId": "G2xcTMAAwAE", + "column": 4, + "height": 1, + "row": 1, + "width": 4 + }, + { + "chartId": "G2xdLAdA4AE", + "column": 0, + "height": 1, + "row": 2, + "width": 4 + }, + { + "chartId": "G2xfPJWA4AA", + "column": 4, + "height": 1, + "row": 2, + "width": 8 + }, + { + "chartId": "G2xfY84A0A4", + "column": 0, + "height": 1, + "row": 3, + "width": 12 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "These metrics cover the Cilium-specific component of Pod Scheduling: CNI operations.", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [], + "time": null, + "variables": [] + }, + "groupId": "G2xYdM9AwAA", + "groupName": "Cilium by Isovalent", + "id": "G2xYdXbA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "CNI (Pod Scheduling)", + "permissions": null, + "selectedEventOverlays": null, + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3JCq_aA4AA", + "column": 0, + "height": 2, + "row": 0, + "width": 6 + }, + { + "chartId": "G3JCeQnAwAA", + "column": 6, + "height": 2, + "row": 0, + "width": 6 + }, + { + "chartId": "G3JCfXbA0AA", + "column": 0, + "height": 1, + "row": 2, + "width": 6 + }, + { + "chartId": "G3JCe47A4AA", + "column": 6, + "height": 1, + "row": 2, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [], + "time": null, + "variables": [] + }, + "groupId": "G2xYdM9AwAA", + "groupName": "Cilium by Isovalent", + "id": "G3JCeI_A4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "Policy: L7 Proxy", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3PufbiAwAE", + "column": 0, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3PuRQWA0AI", + "column": 6, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3PuRr_A0AA", + "column": 6, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3Pu8VQA0AA", + "column": 0, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3PwUk3A0AE", + "column": 6, + "height": 2, + "row": 2, + "width": 6 + }, + { + "chartId": "G3PwgqdA4AI", + "column": 0, + "height": 2, + "row": 2, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [ + { + "NOT": false, + "applyIfExists": false, + "property": "k8s.cluster.name", + "value": "k8s-02.uktme.cisco.com" + }, + { + "NOT": false, + "applyIfExists": false, + "property": "source_namespace", + "value": "tenant-jobs" + } + ], + "time": null, + "variables": [] + }, + "groupId": "G2xYdM9AwAA", + "groupName": "Cilium by Isovalent", + "id": "G3PuOK-A0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "Policy Verdicts", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3I3r4BAwAA", + "column": 0, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3I3r0eA4AI", + "column": 6, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3I4Tv-AwBE", + "column": 0, + "height": 1, + "row": 1, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [], + "time": null, + "variables": [] + }, + "groupId": "G2xYdM9AwAA", + "groupName": "Cilium by Isovalent", + "id": "G3I3rvKA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "BPF Map Health", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3Ixp4NA0AA", + "column": 0, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3IybEOAwAE", + "column": 6, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3I0aqVAwAA", + "column": 0, + "height": 1, + "row": 1, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [], + "time": null, + "variables": [] + }, + "groupId": "G2xYdM9AwAA", + "groupName": "Cilium by Isovalent", + "id": "G3IxoeYA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "Kubernetes Events Processing", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3I6czPA4AA", + "column": 0, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3I7KPkA0DY", + "column": 6, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3I6xhLA4AA", + "column": 0, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3I8dvpA4Aw", + "column": 6, + "height": 1, + "row": 1, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [], + "time": null, + "variables": [] + }, + "groupId": "G2xYdM9AwAA", + "groupName": "Cilium by Isovalent", + "id": "G3I6cS1A0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "Reconciliation", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + } + ], + "groupExport": { + "group": { + "authorizedWriters": null, + "created": 0, + "creator": null, + "dashboardConfigs": [ + { + "configId": "G2xYkiIA0AI", + "dashboardId": "G2xYjdwAwAA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3JNp-rA0AQ", + "dashboardId": "G3JNp-rA0AM", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G2xYe03AwAE", + "dashboardId": "G2xYdXbA0AA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3JCfdqAwAI", + "dashboardId": "G3JCeI_A4AA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3PuOLNA4AA", + "dashboardId": "G3PuOK-A0AA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3I3rvdAwAA", + "dashboardId": "G3I3rvKA4AA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3IxpNBA4AA", + "dashboardId": "G3IxoeYA0AA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3I6cWbA4AE", + "dashboardId": "G3I6cS1A0AA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + } + ], + "dashboards": [ + "G2xYjdwAwAA", + "G3JNp-rA0AM", + "G2xYdXbA0AA", + "G3JCeI_A4AA", + "G3PuOK-A0AA", + "G3I3rvKA4AA", + "G3IxoeYA0AA", + "G3I6cS1A0AA" + ], + "description": "", + "email": null, + "id": "G2xYdM9AwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Cilium by Isovalent", + "permissions": null, + "teams": null + } + }, + "hashCode": 2082292469, + "id": "G2xYdM9AwAA", + "modelVersion": 1, + "packageType": "GROUP" +} \ No newline at end of file diff --git a/content/ja/scenarios/isovalent-cilium-integration/examples/Hubble by Isovalent.json b/content/ja/scenarios/isovalent-cilium-integration/examples/Hubble by Isovalent.json new file mode 100644 index 0000000000..57ed3f7113 --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/examples/Hubble by Isovalent.json @@ -0,0 +1,5007 @@ +{ + "chartExports": [ + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PFnGbA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Queries", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "source", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_queries_total - Sum by source", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "req/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_queries_total').sum(by=['source']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PGlrdA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Top 10 DNS Queries", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "query" + }, + { + "enabled": false, + "property": "destination" + }, + { + "enabled": false, + "property": "destination_namespace" + }, + { + "enabled": false, + "property": "destination_workload" + }, + { + "enabled": false, + "property": "host.name" + }, + { + "enabled": false, + "property": "ips_returned" + }, + { + "enabled": false, + "property": "k8s.cluster.name" + }, + { + "enabled": false, + "property": "k8s.container.name" + }, + { + "enabled": false, + "property": "k8s.daemonset.name" + }, + { + "enabled": false, + "property": "k8s.namespace.name" + }, + { + "enabled": false, + "property": "k8s.node.name" + }, + { + "enabled": false, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "k8s.pod.uid" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "os.type" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": false, + "property": "qtypes" + }, + { + "enabled": false, + "property": "server.port" + }, + { + "enabled": false, + "property": "service.instance.id" + }, + { + "enabled": false, + "property": "service.name" + }, + { + "enabled": true, + "property": "source" + }, + { + "enabled": false, + "property": "source_namespace" + }, + { + "enabled": false, + "property": "source_workload" + }, + { + "enabled": false, + "property": "url.scheme" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_queries_total - Top 10 by query", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_queries_total').top(by=['query'], count=10).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PI0BGAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Errors", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "destination" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": true, + "property": "rcode" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "destination", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_responses_total", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "data('hubble_dns_responses_total', filter=not filter('rcode', 'No Error')).sum(by=['destination', 'rcode']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PNUxEA0AI", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Missing DNS Responses", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "Histogram", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Queries without responses", + "label": "Queries without responses", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_queries_total').mean(over='1m').sum()\nB = data('hubble_dns_responses_total').mean(over='1m').sum()\nC = (A - B).publish(label='Queries without responses')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PN6omA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Flows processed by type", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "ops/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "type" + }, + { + "enabled": true, + "property": "subtype" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "subtype", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_flows_processed_total - Sum by type,subtype", + "label": "A", + "paletteIndex": null, + "plotType": "AreaChart", + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total').sum(by=['type', 'subtype']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3POqbdA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Flows processed by verdict", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "ops/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "type" + }, + { + "enabled": true, + "property": "subtype" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": true, + "property": "verdict" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "verdict", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_flows_processed_total - Sum by verdict", + "label": "A", + "paletteIndex": null, + "plotType": "AreaChart", + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total').sum(by=['verdict']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PTfUCA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Top 10 sources", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": false, + "legendOptions": { + "fields": [ + { + "enabled": false, + "property": "destination" + }, + { + "enabled": false, + "property": "destination_namespace" + }, + { + "enabled": false, + "property": "destination_workload" + }, + { + "enabled": false, + "property": "host.name" + }, + { + "enabled": false, + "property": "k8s.cluster.name" + }, + { + "enabled": false, + "property": "k8s.container.name" + }, + { + "enabled": false, + "property": "k8s.daemonset.name" + }, + { + "enabled": false, + "property": "k8s.namespace.name" + }, + { + "enabled": false, + "property": "k8s.node.name" + }, + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "k8s.pod.uid" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "os.type" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": false, + "property": "protocol" + }, + { + "enabled": false, + "property": "server.port" + }, + { + "enabled": false, + "property": "service.instance.id" + }, + { + "enabled": false, + "property": "service.name" + }, + { + "enabled": true, + "property": "source" + }, + { + "enabled": false, + "property": "source_namespace" + }, + { + "enabled": false, + "property": "source_workload" + }, + { + "enabled": false, + "property": "subtype" + }, + { + "enabled": false, + "property": "type" + }, + { + "enabled": false, + "property": "url.scheme" + }, + { + "enabled": false, + "property": "verdict" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_flows_processed_total - Sum by source", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A - Top 10", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total').sum(by=['source']).publish(label='A')\nB = (A).top(count=10).publish(label='B')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PTtQOA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Top 10 destinations", + "options": { + "colorBy": "Dimension", + "colorScale2": null, + "hideMissingValues": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": true, + "property": "destination" + }, + { + "enabled": false, + "property": "destination_namespace" + }, + { + "enabled": false, + "property": "destination_workload" + }, + { + "enabled": false, + "property": "host.name" + }, + { + "enabled": false, + "property": "k8s.cluster.name" + }, + { + "enabled": false, + "property": "k8s.container.name" + }, + { + "enabled": false, + "property": "k8s.daemonset.name" + }, + { + "enabled": false, + "property": "k8s.namespace.name" + }, + { + "enabled": false, + "property": "k8s.node.name" + }, + { + "enabled": false, + "property": "k8s.pod.uid" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "os.type" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": false, + "property": "protocol" + }, + { + "enabled": false, + "property": "server.port" + }, + { + "enabled": false, + "property": "service.instance.id" + }, + { + "enabled": false, + "property": "service.name" + }, + { + "enabled": false, + "property": "source" + }, + { + "enabled": false, + "property": "source_namespace" + }, + { + "enabled": false, + "property": "source_workload" + }, + { + "enabled": false, + "property": "subtype" + }, + { + "enabled": false, + "property": "type" + }, + { + "enabled": false, + "property": "url.scheme" + }, + { + "enabled": false, + "property": "verdict" + } + ] + }, + "maximumPrecision": null, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_flows_processed_total - Sum by destination", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A - Top 10", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "Sparkline", + "sortBy": "", + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "List", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total').sum(by=['destination']).publish(label='A')\nB = (A).top(count=10).publish(label='B')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PVToNA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Missing TCP SYN-ACKs", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "p/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_originatingMetric", + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_tcp_flags_total - Mean(1m) - Sum", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "hubble_tcp_flags_total - Mean(1m) - Sum", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "Unanswered SYN packets", + "label": "Unanswered SYN packets", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_tcp_flags_total', filter=filter('flag', 'SYN')).mean(over='1m').sum().publish(label='A', enable=False)\nB = data('hubble_tcp_flags_total', filter=filter('flag', 'SYN-ACK')).mean(over='1m').sum().publish(label='B', enable=False)\nC = (A-B).publish(label='Unanswered SYN packets')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PWmLcAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Missing ICMP Echo Replys", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "p/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "sf_originatingMetric" + }, + { + "enabled": true, + "property": "sf_metric" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_icmp_total - Mean(1m) - Sum", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "hubble_icmp_total - Mean(1m) - Sum", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "Unanswered ICMP Echo Requests", + "label": "Unanswered ICMP Echo Requests", + "paletteIndex": 5, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_icmp_total', filter=filter('type', 'EchoRequest')).mean(over='1m').sum().publish(label='A', enable=False)\nB = data('hubble_icmp_total', filter=filter('type', 'EchoReply')).mean(over='1m').sum().publish(label='B', enable=False)\nC = (A-B).publish(label='Unanswered ICMP Echo Requests')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PXjcmAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Network Policy drops by source", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "p/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": true, + "property": "reason" + }, + { + "enabled": true, + "property": "source" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": true, + "property": "destination" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": false, + "property": "k8s.container.name" + }, + { + "enabled": false, + "property": "k8s.namespace.name" + }, + { + "enabled": false, + "property": "k8s.cluster.name" + }, + { + "enabled": false, + "property": "k8s.pod.uid" + }, + { + "enabled": false, + "property": "os.type" + }, + { + "enabled": false, + "property": "url.scheme" + }, + { + "enabled": false, + "property": "protocol" + }, + { + "enabled": false, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "service.instance.id" + }, + { + "enabled": false, + "property": "server.port" + }, + { + "enabled": false, + "property": "host.name" + }, + { + "enabled": false, + "property": "k8s.daemonset.name" + }, + { + "enabled": false, + "property": "service.name" + }, + { + "enabled": false, + "property": "k8s.node.name" + }, + { + "enabled": false, + "property": "destination_namespace" + }, + { + "enabled": false, + "property": "source_namespace" + }, + { + "enabled": false, + "property": "source_workload" + }, + { + "enabled": false, + "property": "destination_workload" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "reason", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_drop_total - Sum by source,reason", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_drop_total').sum(by=['source', 'reason']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PYfNlA4AE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Network Policy drops by destination", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "p/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "reason", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_drop_total - Sum by destination,reason", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_drop_total').sum(by=['destination', 'reason']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PZKqHAwAM", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Incoming Request Volume", + "options": { + "colorBy": "Dimension", + "colorScale": null, + "colorScale2": null, + "maximumPrecision": 3, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Incoming Request Volume", + "label": "Incoming Request Volume", + "paletteIndex": 14, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "req/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "refreshInterval": null, + "secondaryVisualization": "None", + "showSparkLine": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "timestampHidden": false, + "type": "SingleValue", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "data('hubble_http_requests_total').mean(over='1m').sum().scale(0.001).publish(label='Incoming Request Volume')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PpRTAA0AQ", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Incoming Request Success Rate (non-5xx responses)", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "%", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_originatingMetric", + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Success Rate", + "label": "Success Rate", + "paletteIndex": 14, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_http_requests_total', filter=not filter('status', '5*')).mean(over='1m').sum()\nB = data('hubble_http_requests_total').mean(over='1m').sum()\n(A/B).scale(100).publish(label='Success Rate')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PqLGoAwAM", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Request Duration - (p50, p95,p99)", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "ms", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_metric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "P99", + "label": "A", + "paletteIndex": 5, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "P95", + "label": "B", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "P50", + "label": "C", + "paletteIndex": 14, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_http_request_duration_seconds_bucket').percentile(pct=99).publish(label='A')\nB = data('hubble_http_request_duration_seconds_bucket').percentile(pct=95).publish(label='B')\nC = data('hubble_http_request_duration_seconds_bucket').percentile(pct=50).publish(label='C')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3Pq3cmA0AI", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Incoming Requests by Source & Response Code", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "req/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "status", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_http_requests_total - Sum by status,k8s.cluster.name,k8s.namespace.name,k8s.workload.name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_http_requests_total').mean(over='1m').sum(by=['status', 'k8s.cluster.name', 'k8s.namespace.name', 'k8s.workload.name']).scale(0.001).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PrMJZAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Incoming Request Success Rate (non-5xx responses) By Source", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "%", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "source_workload", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Success Rate", + "label": "Success Rate", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_http_requests_total', filter=not filter('status', '5*')).mean(over='1m').sum(by=['source_namespace','source_workload'])\nB = data('hubble_http_requests_total').mean(over='1m').sum(by=['source_namespace', 'source_workload'])\n(A/B).scale(100).publish(label='Success Rate')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PrmTPA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "HTTP Request Duration by Source (P50, P95, P99)", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "ms", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "source_workload", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "P50 by Source", + "label": "P50 by Source", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "P95 by Source", + "label": "P95 by Source", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "P99 by Source", + "label": "P99 by Source", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "data('hubble_http_request_duration_seconds_bucket').histogram_percentile(pct=50, bucket_name='le').sum(by=['k8s.cluster.name','source_namespace','source_workload','le']).scale(1000).publish(label='P50 by Source')\ndata('hubble_http_request_duration_seconds_bucket').histogram_percentile(pct=95, bucket_name='le').sum(by=['k8s.cluster.name','source_namespace','source_workload','le']).scale(1000).publish(label='P95 by Source')\ndata('hubble_http_request_duration_seconds_bucket').histogram_percentile(pct=99, bucket_name='le').sum(by=['k8s.cluster.name','source_namespace','source_workload','le']).scale(1000).publish(label='P99 by Source')\n", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3Pr7wHAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "CPU Usage by source", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "CPU Usage by Source", + "label": "CPU Usage by Source", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "data('node_namespace_pod_container:container_cpu_usage_seconds_total:sum_irate').sum(by=['namespace','workload']).publish(label='CPU Usage by Source')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PsIwgA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Incoming Requests by Destination and Response Code", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "req/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "destination_workload", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Requests by Destination and Status", + "label": "Requests by Destination and Status", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "data('hubble_http_requests_total').mean(over='1m').sum(by=['k8s.cluster.name', 'destination_namespace', 'destination_workload', 'status']).scale(0.001).publish(label='Requests by Destination and Status')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PseXYAwAE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Incoming Request Success Rate (non-5xx responses) By Destination", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "%", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "destination_workload", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Success Rate by Destination", + "label": "Success Rate by Destination", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_http_requests_total', filter=not filter('status', '5*')).mean(over='1m').sum(by=['k8s.cluster.name','destination_namespace', 'destination_workload'])\nB = data('hubble_http_requests_total').mean(over='1m').sum(by=['k8s.cluster.name', 'destination_namespace', 'destination_workload'])\n(A/B).scale(100).publish(label='Success Rate by Destination')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PsxTVAwAQ", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "HTTP Request Duration by Destination (P50, P95, P99)", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "ms", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "destination_workload", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "P50 by Source", + "label": "P50 by Source", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "P95 by Source", + "label": "P95 by Source", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "P99 by Source", + "label": "P99 by Source", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "data('hubble_http_request_duration_seconds_bucket').histogram_percentile(pct=50, bucket_name='le').sum(by=['k8s.cluster.name','destination_namespace','destination_workload','le']).scale(1000).publish(label='P50 by Source')\ndata('hubble_http_request_duration_seconds_bucket').histogram_percentile(pct=95, bucket_name='le').sum(by=['k8s.cluster.name','destination_namespace','destination_workload','le']).scale(1000).publish(label='P95 by Source')\ndata('hubble_http_request_duration_seconds_bucket').histogram_percentile(pct=99, bucket_name='le').sum(by=['k8s.cluster.name','destination_namespace','destination_workload','le']).scale(1000).publish(label='P99 by Source')\n\n\n#data('hubble_http_request_duration_seconds').percentile(50, by=['cluster', 'destination_namespace','destination_workload']).publish(label='P50 by Destination')\n#data('hubble_http_request_duration_seconds').percentile(95, by=['cluster', 'destination_namespace','destination_workload']).publish(label='P95 by Destination')\n#data('hubble_http_request_duration_seconds').percentile(99, by=['cluster', 'destination_namespace','destination_workload']).publish(label='P99 by Destination')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3PtIPaA4BE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "CPU Usage", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "k8s.workload.name", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "container.cpu.usage - Sum by k8s.namespace.name,k8s.workload.name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('container.cpu.usage').sum(by=['k8s.namespace.name', 'k8s.workload.name']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P0oYNA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "L7 Flow Distribution", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "subtype", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_flows_processed_total - Sum by subtype", + "label": "A", + "paletteIndex": null, + "plotType": "AreaChart", + "valuePrefix": null, + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total', filter=filter('type', 'L7'), rollup='rate').sum(by=['subtype']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P1XlCA4AE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Flows Types", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_originatingMetric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_flows_processed_total - Sum by type", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total', rollup='rate').sum(by=['type']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P1i5RAwAI", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Flows processed per node", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "ops/s", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "sf_metric" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_metric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Maximum", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "Minimum", + "label": "B", + "paletteIndex": 6, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "Mean", + "label": "C", + "paletteIndex": 14, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": true, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total', rollup='rate').max().publish(label='A')\nB = data('hubble_flows_processed_total', rollup='rate').min().publish(label='B')\nC = data('hubble_flows_processed_total', rollup='rate').mean().publish(label='C')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P1nYOA0AI", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Trace Flow Distribution", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "subtype", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_flows_processed_total - Sum by subtype", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total', filter=filter('type', 'Trace'), rollup='rate').sum(by=['subtype']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P1xkqA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Drop Reason", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "reason", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_drop_total - Sum by reason", + "label": "A", + "paletteIndex": 2, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_drop_total', rollup='rate').sum(by=['reason']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P2AHpA4Ag", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Forwarded vs Dropped", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "verdict", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_flows_processed_total - Sum by verdict", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_flows_processed_total', rollup='rate').sum(by=['verdict']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P3KisA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "TCPv4", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "flag", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_tcp_flags_total - Sum by flag", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_tcp_flags_total', rollup='rate').sum(by=['flag']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P3bh1A0AI", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "ICMPv4", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "type", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_icmp_total - Sum by type", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_icmp_total', filter=filter('family', 'IPv4'), rollup='rate').sum(by=['type']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P3j3qA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Missing TCPv4 SYN-ACKs", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Unanswered SYN packets by pod", + "label": "Unanswered SYN packets by pod", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_tcp_flags_total', filter=filter('family', 'IPv4') and filter('flag','SYN')).mean(over='1m').sum(by='pod')\nB = data('hubble_tcp_flags_total', filter=filter('family', 'IPv4') and filter('flag','SYN-ACK')).mean(over='1m').sum(by='pod')\n(A - B).publish(label='Unanswered SYN packets by pod')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P3loGA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Missing ICMPv4 Echo-Reply", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "Unanswered ICMP Echo Requests by pod", + "label": "Unanswered ICMP Echo Requests by pod", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_icmp_total', filter=filter('family', 'IPv4') and filter('type',\n 'EchoRequest')).mean(over='1m').sum(by='pod')\nB = data('hubble_icmp_total', filter=filter('family', 'IPv4') and filter('type',\n 'EchoReply')).mean(over='1m').sum(by='pod')\n(A - B).publish(label='Unanswered ICMP Echo Requests by pod')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P3mZ6A4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "HTTP Requests", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": null, + "showLegend": false + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_http_requests_total - Sum by method", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "ops/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_http_requests_total', rollup='rate').sum(by=['method']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P5LoFA0AM", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Requests", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "qtypes", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_queries_total - Sum by qtypes", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "req/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_queries_total', rollup='rate').sum(by=['qtypes']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P5PJNA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "HTTP Protocol Usage", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "protocol", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_http_requests_total - Sum by protocol", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_http_requests_total', rollup='rate').sum(by=['protocol']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P6BmzAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Missing DNS Responses", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "qtypes", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_queries_total - Sum by qtypes", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "hubble_dns_responses_total - Sum by qtypes", + "label": "B", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + }, + { + "displayName": "A-B", + "label": "C", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_queries_total', rollup='rate').sum(by=['qtypes']).publish(label='A', enable=False)\nB = data('hubble_dns_responses_total', rollup='rate').sum(by=['qtypes']).publish(label='B', enable=False)\nC = (A-B).publish(label='C')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P6z4kAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Responses", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_originatingMetric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_responses_total - Sum by qtypes", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": "req/s", + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_responses_total', filter=filter('rcode', 'No Error'), rollup='rate').sum(by=['qtypes']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P60olA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Response IPs Returned", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": true, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_originatingMetric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_responses_total - Sum by ips_returned", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_responses_total', filter=filter('rcode', 'No Error'), rollup='rate').sum(by=['ips_returned']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P7QBsA4AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "DNS Errors", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_originatingMetric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_responses_total - Sum by qtypes", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_responses_total', filter=(not filter('rcode', 'No Error'))).sum(by=['qtypes']).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P7WNrA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Pods with DNS Errors", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "AreaChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": [ + { + "enabled": false, + "property": "destination" + }, + { + "enabled": false, + "property": "destination_namespace" + }, + { + "enabled": false, + "property": "destination_workload" + }, + { + "enabled": false, + "property": "host.name" + }, + { + "enabled": false, + "property": "ips_returned" + }, + { + "enabled": false, + "property": "k8s.cluster.name" + }, + { + "enabled": false, + "property": "k8s.container.name" + }, + { + "enabled": false, + "property": "k8s.daemonset.name" + }, + { + "enabled": false, + "property": "k8s.namespace.name" + }, + { + "enabled": false, + "property": "k8s.node.name" + }, + { + "enabled": true, + "property": "k8s.pod.name" + }, + { + "enabled": false, + "property": "k8s.pod.uid" + }, + { + "enabled": false, + "property": "sf_originatingMetric" + }, + { + "enabled": false, + "property": "os.type" + }, + { + "enabled": false, + "property": "sf_metric" + }, + { + "enabled": false, + "property": "qtypes" + }, + { + "enabled": false, + "property": "query" + }, + { + "enabled": false, + "property": "rcode" + }, + { + "enabled": false, + "property": "server.port" + }, + { + "enabled": false, + "property": "service.instance.id" + }, + { + "enabled": false, + "property": "service.name" + }, + { + "enabled": false, + "property": "source" + }, + { + "enabled": false, + "property": "source_namespace" + }, + { + "enabled": false, + "property": "source_workload" + }, + { + "enabled": false, + "property": "url.scheme" + } + ] + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "sf_originatingMetric", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_responses_total - Top 10 by k8s.pod.name", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_responses_total', filter=(not filter('rcode', 'No Error'))).top(by=['k8s.pod.name'], count=10).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + }, + { + "chart": { + "autoDetectRelatedDetectorIds": [], + "chartLinks": [], + "created": 0, + "creator": null, + "customProperties": {}, + "description": "", + "id": "G3P8XVWAwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Top 10 queries ", + "options": { + "areaChartOptions": { + "showDataMarkers": false + }, + "axes": [ + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + }, + { + "highWatermark": null, + "highWatermarkLabel": null, + "label": "", + "lowWatermark": null, + "lowWatermarkLabel": null, + "max": null, + "min": null + } + ], + "axisPrecision": null, + "colorBy": "Dimension", + "defaultPlotType": "LineChart", + "eventPublishLabelOptions": [], + "histogramChartOptions": { + "colorThemeIndex": 16 + }, + "includeZero": false, + "legendOptions": { + "fields": null + }, + "lineChartOptions": { + "showDataMarkers": false + }, + "noDataOptions": { + "linkText": null, + "linkUrl": null, + "noDataMessage": null + }, + "onChartLegendOptions": { + "dimensionInLegend": "query", + "showLegend": true + }, + "programOptions": { + "disableSampling": false, + "maxDelay": 0, + "minimumResolution": 0, + "timezone": null + }, + "publishLabelOptions": [ + { + "displayName": "hubble_dns_queries_total - Top 10 by query", + "label": "A", + "paletteIndex": null, + "plotType": null, + "valuePrefix": null, + "valueSuffix": null, + "valueUnit": null, + "yAxis": 0 + } + ], + "showEventLines": false, + "stacked": false, + "time": { + "range": 900000, + "rangeEnd": 0, + "type": "relative" + }, + "type": "TimeSeriesChart", + "unitPrefix": "Metric" + }, + "packageSpecifications": "", + "programText": "A = data('hubble_dns_queries_total', rollup='rate').top(by=['query'], count=10).publish(label='A')", + "relatedDetectorIds": [], + "tags": [] + } + } + ], + "crossLinkExports": [], + "dashboardExports": [ + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3PN6omA4AA", + "column": 0, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3POqbdA4AA", + "column": 6, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3PTfUCA0AA", + "column": 0, + "height": 2, + "row": 1, + "width": 6 + }, + { + "chartId": "G3PTtQOA0AA", + "column": 6, + "height": 2, + "row": 1, + "width": 6 + }, + { + "chartId": "G3PVToNA4AA", + "column": 0, + "height": 1, + "row": 3, + "width": 6 + }, + { + "chartId": "G3PWmLcAwAA", + "column": 6, + "height": 1, + "row": 3, + "width": 6 + }, + { + "chartId": "G3PXjcmAwAA", + "column": 0, + "height": 1, + "row": 4, + "width": 6 + }, + { + "chartId": "G3PYfNlA4AE", + "column": 6, + "height": 1, + "row": 4, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [ + { + "NOT": false, + "applyIfExists": false, + "property": "k8s.cluster.name", + "value": "k8s-02.uktme.cisco.com" + } + ], + "time": null, + "variables": [] + }, + "groupId": "G3PE8nhA4AM", + "groupName": "Hubble by Isovalent", + "id": "G3POSj3AwAA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "Network Overview", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3PFnGbA4AA", + "column": 0, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3PGlrdA4AA", + "column": 6, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3PNUxEA0AI", + "column": 6, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3PI0BGAwAA", + "column": 0, + "height": 1, + "row": 1, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [ + { + "NOT": false, + "applyIfExists": false, + "property": "k8s.cluster.name", + "value": "k8s-02.uktme.cisco.com" + } + ], + "time": null, + "variables": [] + }, + "groupId": "G3PE8nhA4AM", + "groupName": "Hubble by Isovalent", + "id": "G3PE97wAwAo", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "DNS Overview", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "HIGH", + "charts": [ + { + "chartId": "G3PZKqHAwAM", + "column": 0, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G3PpRTAA0AQ", + "column": 4, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G3PqLGoAwAM", + "column": 8, + "height": 1, + "row": 0, + "width": 4 + }, + { + "chartId": "G3Pq3cmA0AI", + "column": 0, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3PrMJZAwAA", + "column": 6, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3PrmTPA0AA", + "column": 0, + "height": 1, + "row": 2, + "width": 6 + }, + { + "chartId": "G3Pr7wHAwAA", + "column": 6, + "height": 1, + "row": 2, + "width": 6 + }, + { + "chartId": "G3PseXYAwAE", + "column": 6, + "height": 1, + "row": 3, + "width": 6 + }, + { + "chartId": "G3PsIwgA4AA", + "column": 0, + "height": 1, + "row": 3, + "width": 6 + }, + { + "chartId": "G3PsxTVAwAQ", + "column": 0, + "height": 1, + "row": 4, + "width": 6 + }, + { + "chartId": "G3PtIPaA4BE", + "column": 6, + "height": 1, + "row": 4, + "width": 6 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [ + { + "NOT": false, + "applyIfExists": false, + "property": "k8s.cluster.name", + "value": "k8s-02.uktme.cisco.com" + } + ], + "time": { + "end": "Now", + "start": "-15m" + }, + "variables": [] + }, + "groupId": "G3PE8nhA4AM", + "groupName": "Hubble by Isovalent", + "id": "G3PZT8nA0AA", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "L7 HTTP Metrics", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + }, + { + "dashboard": { + "authorizedWriters": null, + "chartDensity": "DEFAULT", + "charts": [ + { + "chartId": "G3P1i5RAwAI", + "column": 0, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3P1XlCA4AE", + "column": 6, + "height": 1, + "row": 0, + "width": 6 + }, + { + "chartId": "G3P0oYNA4AA", + "column": 0, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3P1nYOA0AI", + "column": 6, + "height": 1, + "row": 1, + "width": 6 + }, + { + "chartId": "G3P2AHpA4Ag", + "column": 0, + "height": 1, + "row": 2, + "width": 6 + }, + { + "chartId": "G3P1xkqA0AA", + "column": 6, + "height": 1, + "row": 2, + "width": 6 + }, + { + "chartId": "G3P3KisA4AA", + "column": 0, + "height": 1, + "row": 3, + "width": 6 + }, + { + "chartId": "G3P3j3qA4AA", + "column": 6, + "height": 1, + "row": 3, + "width": 6 + }, + { + "chartId": "G3P3bh1A0AI", + "column": 0, + "height": 1, + "row": 4, + "width": 6 + }, + { + "chartId": "G3P3loGA4AA", + "column": 6, + "height": 1, + "row": 4, + "width": 6 + }, + { + "chartId": "G3P3mZ6A4AA", + "column": 0, + "height": 1, + "row": 5, + "width": 6 + }, + { + "chartId": "G3P5PJNA4AA", + "column": 6, + "height": 1, + "row": 5, + "width": 6 + }, + { + "chartId": "G3P5LoFA0AM", + "column": 0, + "height": 1, + "row": 6, + "width": 4 + }, + { + "chartId": "G3P6z4kAwAA", + "column": 4, + "height": 1, + "row": 6, + "width": 4 + }, + { + "chartId": "G3P6BmzAwAA", + "column": 8, + "height": 1, + "row": 6, + "width": 4 + }, + { + "chartId": "G3P60olA4AA", + "column": 0, + "height": 1, + "row": 7, + "width": 6 + }, + { + "chartId": "G3P7QBsA4AA", + "column": 6, + "height": 1, + "row": 7, + "width": 6 + }, + { + "chartId": "G3P7WNrA0AA", + "column": 0, + "height": 1, + "row": 8, + "width": 6 + }, + { + "chartId": "G3P8XVWAwAA", + "column": 0, + "height": 1, + "row": 9, + "width": 12 + } + ], + "created": 0, + "creator": null, + "customProperties": null, + "description": "", + "discoveryOptions": null, + "eventOverlays": null, + "filters": { + "sources": [ + { + "NOT": false, + "applyIfExists": false, + "property": "k8s.cluster.name", + "value": "k8s-02.uktme.cisco.com" + } + ], + "time": null, + "variables": [] + }, + "groupId": "G3PE8nhA4AM", + "groupName": "Hubble by Isovalent", + "id": "G3P1n6KA4AE", + "lastUpdated": 0, + "lastUpdatedBy": null, + "maxDelayOverride": null, + "name": "Metrics & Monitoring", + "permissions": null, + "selectedEventOverlays": [], + "tags": [] + } + } + ], + "groupExport": { + "group": { + "authorizedWriters": null, + "created": 0, + "creator": null, + "dashboardConfigs": [ + { + "configId": "G3POTKcA0AA", + "dashboardId": "G3POSj3AwAA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3PE--WA0AA", + "dashboardId": "G3PE97wAwAo", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3PZUS1A4AE", + "dashboardId": "G3PZT8nA0AA", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + }, + { + "configId": "G3P1oVwAwAE", + "dashboardId": "G3P1n6KA4AE", + "descriptionOverride": null, + "filtersOverride": null, + "nameOverride": null + } + ], + "dashboards": [ + "G3POSj3AwAA", + "G3PE97wAwAo", + "G3PZT8nA0AA", + "G3P1n6KA4AE" + ], + "description": "", + "email": null, + "id": "G3PE8nhA4AM", + "importQualifiers": [ + { + "filters": [], + "metric": "" + } + ], + "lastUpdated": 0, + "lastUpdatedBy": null, + "name": "Hubble by Isovalent", + "permissions": null, + "teams": null + } + }, + "hashCode": -2072164354, + "id": "G3PE8nhA4AM", + "modelVersion": 1, + "packageType": "GROUP" +} \ No newline at end of file diff --git a/content/ja/scenarios/isovalent-cilium-integration/examples/cilium-dns-proxy-ha-values.yaml b/content/ja/scenarios/isovalent-cilium-integration/examples/cilium-dns-proxy-ha-values.yaml new file mode 100644 index 0000000000..43f1c1dafe --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/examples/cilium-dns-proxy-ha-values.yaml @@ -0,0 +1,4 @@ +enableCriticalPriorityClass: true +metrics: + serviceMonitor: + enabled: true diff --git a/content/ja/scenarios/isovalent-cilium-integration/examples/cilium-enterprise-values.yaml b/content/ja/scenarios/isovalent-cilium-integration/examples/cilium-enterprise-values.yaml new file mode 100644 index 0000000000..580c57c61c --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/examples/cilium-enterprise-values.yaml @@ -0,0 +1,101 @@ +# Enable/disable debug logging +debug: + enabled: false + verbose: ~ + +# Configure unique cluster name & ID +cluster: + name: isovalent-demo + id: 0 + +# Configure ENI specifics +eni: + enabled: true + updateEC2AdapterLimitViaAPI: true + awsEnablePrefixDelegation: true + +enableIPv4Masquerade: false +loadBalancer: + serviceTopology: true + +ipam: + mode: eni + +routingMode: native + +# BPF / KubeProxyReplacement +# IMPORTANT: Replace with your actual EKS API server endpoint +# Get it with: kubectl cluster-info | grep 'Kubernetes control plane' | awk '{print $NF}' | sed 's|https://||' +kubeProxyReplacement: "true" +k8sServiceHost: +k8sServicePort: 443 + +# Configure TLS configuration in the agent. +tls: + ca: + certValidityDuration: 3650 # 10 years + +# Enable Cilium Hubble to gain visibility +hubble: + enabled: true + metrics: + enableOpenMetrics: true + enabled: + - dns:labelsContext=source_namespace,destination_namespace + - drop:labelsContext=source_namespace,destination_namespace + - tcp:labelsContext=source_namespace,destination_namespace + - port-distribution:labelsContext=source_namespace,destination_namespace + - icmp:labelsContext=source_namespace,destination_namespace;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity + - flow:sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity + - "httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity" + - "policy:sourceContext=app|workload-name|pod|reserved-identity;destinationContext=app|workload-name|pod|dns|reserved-identity;labelsContext=source_namespace,destination_namespace" + - flow_export + serviceMonitor: + enabled: true + tls: + enabled: true + auto: + enabled: true + method: cronJob + certValidityDuration: 1095 # 3 years + relay: + enabled: true + tls: + server: + enabled: true + prometheus: + enabled: true + serviceMonitor: + enabled: true + timescape: + enabled: true + +# Enable Cilium Operator metrics +operator: + prometheus: + enabled: true + serviceMonitor: + enabled: true + +# Enable Cilium Agent metrics +prometheus: + enabled: true + serviceMonitor: + enabled: true + +# Configure Cilium Envoy options. +envoy: + prometheus: + enabled: true + serviceMonitor: + enabled: true + +# Enable Cilium agent's support for Cilium DNS Proxy HA +extraConfig: + external-dns-proxy: "true" + +enterprise: + featureGate: + approved: + - DNSProxyHA + - HubbleTimescape diff --git a/content/ja/scenarios/isovalent-cilium-integration/examples/cluster.yaml b/content/ja/scenarios/isovalent-cilium-integration/examples/cluster.yaml new file mode 100644 index 0000000000..ff7706894b --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/examples/cluster.yaml @@ -0,0 +1,12 @@ +apiVersion: eksctl.io/v1alpha5 +kind: ClusterConfig +metadata: + name: isovalent-demo + region: us-east-1 + version: "1.30" +iam: + withOIDC: true +addonsConfig: + disableDefaultAddons: true +addons: +- name: coredns diff --git a/content/ja/scenarios/isovalent-cilium-integration/examples/nodegroup.yaml b/content/ja/scenarios/isovalent-cilium-integration/examples/nodegroup.yaml new file mode 100644 index 0000000000..b38c91992f --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/examples/nodegroup.yaml @@ -0,0 +1,10 @@ +apiVersion: eksctl.io/v1alpha5 +kind: ClusterConfig +metadata: + name: isovalent-demo + region: us-east-1 +managedNodeGroups: +- name: standard + instanceType: m5.xlarge + desiredCapacity: 2 + privateNetworking: true diff --git a/content/ja/scenarios/isovalent-cilium-integration/examples/splunk-otel-isovalent.yaml b/content/ja/scenarios/isovalent-cilium-integration/examples/splunk-otel-isovalent.yaml new file mode 100644 index 0000000000..009e0e7052 --- /dev/null +++ b/content/ja/scenarios/isovalent-cilium-integration/examples/splunk-otel-isovalent.yaml @@ -0,0 +1,207 @@ +terminationGracePeriodSeconds: 30 +agent: + config: + extensions: + # The k8s_observer detects and reports Kubernetes pod and port endpoints. + k8s_observer: + auth_type: serviceAccount # Use serviceAccount for in-cluster authentication + observe_pods: true # Enable 'watching' of pods and their ports via k8s API + receivers: + kubeletstats: + collection_interval: 30s + insecure_skip_verify: true + # Receiver for Cilium metrics on port 9962, and Hubble metrics on port 9965 + prometheus/isovalent_cilium: + config: + scrape_configs: + - job_name: 'cilium_metrics_9962' + scrape_interval: 30s + metrics_path: /metrics + kubernetes_sd_configs: + - role: pod + relabel_configs: + # Keep only DaemonSet pods + - source_labels: [__meta_kubernetes_pod_label_k8s_app] + action: keep + regex: cilium + - source_labels: [__meta_kubernetes_pod_ip] + target_label: __address__ + replacement: ${__meta_kubernetes_pod_ip}:9962 + # Add helpful labels + - target_label: job + replacement: 'cilium_metrics_9962' + - job_name: 'hubble_metrics_9965' + scrape_interval: 30s + metrics_path: /metrics + kubernetes_sd_configs: + - role: pod + relabel_configs: + - source_labels: [__meta_kubernetes_pod_label_k8s_app] + action: keep + regex: cilium + - source_labels: [__meta_kubernetes_pod_ip] + target_label: __address__ + replacement: ${__meta_kubernetes_pod_ip}:9965 + - target_label: job + replacement: 'hubble_metrics_9965' + prometheus/isovalent_envoy: + config: + scrape_configs: + - job_name: 'envoy_metrics_9964' + scrape_interval: 30s + metrics_path: /metrics + kubernetes_sd_configs: + - role: pod + relabel_configs: + # Keep only DaemonSet pods + - source_labels: [__meta_kubernetes_pod_label_k8s_app] + action: keep + regex: cilium-envoy + - source_labels: [__meta_kubernetes_pod_ip] + target_label: __address__ + replacement: ${__meta_kubernetes_pod_ip}:9964 + # Add helpful labels + - target_label: job + replacement: 'cilium_metrics_9964' + prometheus/isovalent_operator: + config: + scrape_configs: + - job_name: 'cilium_operator_metrics_9963' + scrape_interval: 30s + metrics_path: /metrics + kubernetes_sd_configs: + - role: pod + relabel_configs: + # Keep only Deployment pods + - source_labels: [__meta_kubernetes_pod_label_io_cilium_app] + action: keep + regex: operator + # Add helpful labels + - target_label: job + replacement: 'cilium_metrics_9963' + prometheus/isovalent_tetragon: + config: + scrape_configs: + - job_name: 'tetragon_metrics_2112' + scrape_interval: 30s + metrics_path: /metrics + kubernetes_sd_configs: + - role: pod + relabel_configs: + # Keep only Deployment pods + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name] + action: keep + regex: tetragon + - source_labels: [__meta_kubernetes_pod_ip] + target_label: __address__ + replacement: ${__meta_kubernetes_pod_ip}:2112 + # Add helpful labels + - target_label: job + replacement: 'tetragon_metrics_2112' + processors: + # Only include selected metrics to ensure to reduce data volume for Splunk Observability Cloud. + filter/includemetrics: + metrics: + include: + match_type: strict + metric_names: + - container.cpu.usage + - container.memory.rss + - k8s.container.restarts + - k8s.pod.phase + - node_namespace_pod_container + - tcp.resets + - tcp.syn_timeouts + # Include selected Cilium metrics + - cilium_api_limiter_processed_requests_total + - cilium_api_limiter_processing_duration_seconds + - cilium_bpf_map_ops_total + - cilium_controllers_group_runs_total + - cilium_controllers_runs_total + - cilium_endpoint_state + - cilium_errors_warnings_total + - cilium_ip_addresses + - cilium_ipam_capacity + - cilium_kubernetes_events_total + - cilium_policy_l7_total + - cilium_proxy_upstream_reply_seconds_bucket + # Include selected Hubble metrics + - hubble_dns_queries_total + - hubble_dns_responses_total + - hubble_drop_total + - hubble_flows_processed_total + - hubble_http_request_duration_seconds_bucket + - hubble_http_requests_total + - hubble_icmp_total + - hubble_policy_verdicts_total + - hubble_tcp_flags_total + # Include selected Tetragon metrics + - tetragon_dns_cache_evictions_total + - tetragon_dns_cache_misses_total + - tetragon_dns_total + - tetragon_http_response_total + - tetragon_http_stats_latency_bucket + - tetragon_http_stats_latency_count + - tetragon_http_stats_latency_sum + - tetragon_layer3_event_errors_total + - tetragon_socket_stats_retransmitsegs_total + - tetragon_socket_stats_rxsegs_total + - tetragon_socket_stats_srtt_count + - tetragon_socket_stats_srtt_sum + - tetragon_socket_stats_txbytes_total + - tetragon_socket_stats_txsegs_total + - tetragon_socket_stats_udp_retrieve_total + - tetragon_socket_stats_udp_txbytes_total + - tetragon_socket_stats_udp_txsegs_total + resourcedetection: + detectors: [system] + system: + hostname_sources: [os] + service: + # telemetry: + # logs: + # level: debug + pipelines: + metrics: + receivers: + - prometheus/isovalent_cilium + - prometheus/isovalent_envoy + - prometheus/isovalent_operator + - prometheus/isovalent_tetragon + - hostmetrics + - kubeletstats + - otlp + processors: + - filter/includemetrics + - resourcedetection +autodetect: + prometheus: true +clusterName: isovalent-demo + +# IMPORTANT: Replace with your actual Splunk Observability Cloud access token +# Get it from: Splunk Observability Cloud > Settings > Access Tokens +splunkObservability: + accessToken: + # IMPORTANT: Replace with your actual Splunk realm (e.g., us0, us1, eu0, ap0) + # Find it from: Splunk Observability Cloud > Settings > Account + realm: + profilingEnabled: true + +cloudProvider: aws +distribution: eks + +gateway: + enabled: true + resources: + requests: + cpu: 250m + memory: 512Mi + limits: + cpu: 1 + memory: 1Gi + +certmanager: + enabled: true + +operator: + enabled: true diff --git a/content/ja/scenarios/thousandeyes-integration/5-kubernetes-testing/_index.md b/content/ja/scenarios/thousandeyes-integration/5-kubernetes-testing/_index.md deleted file mode 100644 index e5118bf98d..0000000000 --- a/content/ja/scenarios/thousandeyes-integration/5-kubernetes-testing/_index.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: Kubernetes サービステストと相関 -linkTitle: 5. Kubernetes テスト -weight: 5 -time: 20 minutes -description: シンセティック監視とトレース相関の両方に役立つ、内部 Kubernetes テストと外部依存関係テストを作成します。 ---- - -## AppDynamics テスト推奨機能の再現 - -AppDynamicsには、アプリケーションのエンドポイントに対するシンセティックテストを自動的に提案する「Test Recommendations」という機能があります。ThousandEyesをKubernetesクラスター内にデプロイすることで、KubernetesのサービスディスカバリとSplunk Observability Cloudの統合ビューを組み合わせて、この機能を再現できます。 - -ThousandEyes Enterprise Agentは**クラスター内部**で実行されるため、サービス名をホスト名として使用して内部Kubernetesサービスを直接テストできます。これにより、外部に公開されていないバックエンドサービスを監視する強力な方法が得られます。 - -## 仕組み - -1. **サービスディスカバリ**: `kubectl get svc` を使用してクラスター内のサービスを列挙します -2. **ホスト名の構築**: Kubernetes DNS命名規則を使用してテストURLを構築します: `..svc.cluster.local` -3. **テストの作成**: 内部サービスに対して可用性テストとトレース対応トランザクションテストの両方を作成します -4. **Splunk での相関**: シンセティックテストの結果をAPMトレースおよびインフラストラクチャメトリクスと並べて表示します - -## クラスター内テストのメリット - -- **内部サービス監視**: インターネットに公開されていないバックエンドサービスをテストできます -- **サービスメッシュ対応**: Istio、Linkerd、その他のサービスメッシュの背後にあるサービスを監視できます -- **DNS 解決テスト**: Kubernetes DNSとサービスディスカバリを検証できます -- **ネットワークポリシー検証**: ネットワークポリシーが適切な通信を許可していることを確認できます -- **レイテンシベースライン**: クラスター内部のネットワークパフォーマンスを測定できます -- **本番前テスト**: Ingress/LoadBalancer経由で公開する前にサービスをテストできます - -## ワークショップ対象: Spring PetClinic - -このリポジトリには、この ThousandEyes ガイドの既知の Kubernetes ターゲットとして使える Spring PetClinic マイクロサービスアプリケーションが含まれています。デプロイメントマニフェストは `workshop/petclinic/deployment.yaml` にあり、ワークショップ VM では `~/workshop/petclinic/deployment.yaml` として利用できます。 - -このマニフェストは、PetClinic のフロントエンド/API gateway、バックエンドサービス、MySQL データベース、ロードジェネレーターをデプロイします。主なサービスは次のとおりです。 - -- `api-gateway`: port `82` の `ClusterIP` サービス -- `api-gateway-external`: port `81` の `LoadBalancer` サービス -- `customers-service`、`vets-service`、`visits-service`: 内部バックエンドサービス - -{{% notice title="トレーシング設定" style="info" %}} -Splunk OpenTelemetry Operator をすでにインストールしており、PetClinic をトレース相関に使う場合は、このマニフェストを適用する前に Distributed Tracing セクションの PetClinic 計装セットアップを完了してください。PetClinic マニフェストには一部サービスの Java injection アノテーションが含まれており、Operator webhook が有効な場合は対応する `Instrumentation` リソースが必要です。 -{{% /notice %}} - -PetClinic を選択した namespace にデプロイします。 - -```bash -PETCLINIC_NAMESPACE=default - -kubectl create namespace $PETCLINIC_NAMESPACE --dry-run=client -o yaml | kubectl apply -f - - -kubectl create secret generic workshop-secret \ - -n $PETCLINIC_NAMESPACE \ - --from-literal=app=${INSTANCE:-thousandeyes}-petclinic-service \ - --from-literal=env=${INSTANCE:-thousandeyes}-petclinic \ - --from-literal=realm=${REALM:-us1} \ - --from-literal=rum_token=${RUM_TOKEN:-not-used} \ - --from-literal=url=http://api-gateway:82 \ - --dry-run=client -o yaml | kubectl apply -f - - -kubectl apply -n $PETCLINIC_NAMESPACE -f ~/workshop/petclinic/deployment.yaml -``` - -アプリケーションリソースを確認します。 - -```bash -kubectl get pods -n $PETCLINIC_NAMESPACE -kubectl get svc -n $PETCLINIC_NAMESPACE api-gateway api-gateway-external customers-service vets-service visits-service -``` - -ThousandEyes agent が動作している namespace から、クラスター内部の到達性を確認します。 - -```bash -kubectl run te-petclinic-curl \ - -n te-demo \ - --rm -it \ - --restart=Never \ - --image=curlimages/curl \ - --command -- curl -sS http://api-gateway.$PETCLINIC_NAMESPACE.svc.cluster.local:82/api/customer/owners -``` - -ThousandEyes テストでは、次の PetClinic URL を使用します。 - -```text -Availability test: -http://api-gateway.default.svc.cluster.local:82/ - -Trace-enabled API test: -http://api-gateway.default.svc.cluster.local:82/api/customer/owners - -Additional API test targets: -http://api-gateway.default.svc.cluster.local:82/api/vet/vets -http://api-gateway.default.svc.cluster.local:82/api/visit/owners/1/pets/1/visits -``` - -{{% notice title="Namespace に関する注意" style="info" %}} -ThousandEyes Enterprise Agent は `te-demo` で実行し、PetClinic は `default` で実行できます。agent とターゲットアプリケーションが別 namespace にある場合は、`api-gateway.default.svc.cluster.local` のような完全な Kubernetes DNS 名を使用してください。 -{{% /notice %}} - -## PetClinic 用 ThousandEyes テストを設定する - -PetClinic テストを少なくとも 2 つ作成します。1 つはフロントエンドのシンプルな可用性テスト、もう 1 つは APM 相関用のトレース対応 API テストです。どちらも同じ Kubernetes Enterprise Agent を使用します。 - -### Test 1: PetClinic Frontend Availability - -1. ThousandEyes で **Cloud & Enterprise Agents > Test Settings** に移動します。 -2. **Add New Test** をクリックし、**HTTP Server** を選択します。 -3. 次のように設定します。 - - **Test Name**: `[PetClinic] Frontend Availability` - - **URL**: `http://api-gateway.default.svc.cluster.local:82/` - - **Interval**: `2 minutes` - - **Agents**: このガイドでデプロイした Kubernetes Enterprise Agent - - **HTTP Response Code**: `200` - - **Verify Content**: 任意。返却ページの内容を検証したい場合は `PetClinic` -4. テストを保存します。 - -### Test 2: PetClinic Owners API With Distributed Tracing - -このテストは ThousandEyes と Splunk APM のドリルダウンワークフローに使用します。API gateway をターゲットにして `customers-service` にルーティングされるため、単純なヘルスチェックより有用なトレースを生成します。 - -1. ThousandEyes で **Cloud & Enterprise Agents > Test Settings** に移動します。 -2. **Add New Test** をクリックし、**HTTP Server** または **API** を選択します。 -3. 次のように設定します。 - - **Test Name**: `[Trace] PetClinic Owners API` - - **URL**: `http://api-gateway.default.svc.cluster.local:82/api/customer/owners` - - **Method**: `GET` - - **Interval**: `2 minutes` - - **Agents**: 同じ Kubernetes Enterprise Agent - - **HTTP Response Code**: `200` - - **Advanced Settings > Distributed Tracing**: Enabled - -**Basic Settings** のハイライトされたフィールドが PetClinic API ターゲットとクラスター内 Enterprise Agent に一致していることを確認します。 - -![PetClinic ThousandEyes HTTP Server basic settings](../images/te-petclinic-basic-settings.png) - -**HTTP Communication and Performance** で distributed tracing を有効にし、API リクエストを `GET` のままにします。 - -![PetClinic ThousandEyes HTTP Server tracing settings](../images/te-petclinic-http-settings.png) - -4. テストを保存し、数回の実行間隔を待ちます。 - -{{% notice title="トレーステストの要件" style="warning" %}} -分散トレーシング演習では **HTTP Server** または **API** テストを使用してください。ブラウザ形式の page load や transaction テストはエンドユーザー監視には有用ですが、ThousandEyes と Splunk APM ワークフローに必要なトレースヘッダーを注入する用途には適していません。 -{{% /notice %}} - -### 任意の PetClinic API テスト - -最初の 2 つのテストが動作したら、他の PetClinic サービスもカバーできます。 - -```text -[Trace] PetClinic Vets API -http://api-gateway.default.svc.cluster.local:82/api/vet/vets - -[Trace] PetClinic Owner Visits API -http://api-gateway.default.svc.cluster.local:82/api/visit/owners/1/pets/1/visits -``` - -PetClinic を `default` 以外の namespace にデプロイした場合は、各 URL の `default` を PetClinic の namespace に置き換えてください。 diff --git a/content/ja/scenarios/thousandeyes-integration/6-rum-thousandeyes/_index.md b/content/ja/scenarios/thousandeyes-integration/6-rum-thousandeyes/_index.md deleted file mode 100644 index c173f0e3eb..0000000000 --- a/content/ja/scenarios/thousandeyes-integration/6-rum-thousandeyes/_index.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: ThousandEyes と Splunk RUM -linkTitle: 6. RUM -weight: 6 -time: 10 minutes -description: ThousandEyes のネットワークメトリクスと Splunk RUM を関連付けて、エンドユーザー体験とネットワークの問題を一緒に調査できるようにします。 ---- -ThousandEyesとSplunk RUMを統合して、ネットワークの問題がエンドユーザーの問題と関連しているかどうかを把握します。 - -## 前提条件 - -1. Splunk Observability CloudとThousandEyes両方の管理者権限 -1. Splunk RUMにデータを送信しているアプリケーションが少なくとも1つ -1. Splunk RUMのアプリと**同じドメイン**で、ThousandEyesで以下のタイプのテストが少なくとも1つ実行されていること： - - [agent-to-server](https://docs.thousandeyes.com/product-documentation/tests/network-tests#agent-to-server-tests) - - [HTTP server](https://docs.thousandeyes.com/product-documentation/tests/http-server-tests) - - [page load](https://docs.thousandeyes.com/product-documentation/tests/web-layer-tests#page-load-test) - - [transaction](https://docs.thousandeyes.com/product-documentation/tests/web-layer-tests#transaction-test) - -## 統合手順 - -1. ThousandEyesでOAuth Bearerトークンを作成します： - - 右上隅のユーザー名を選択し、`Profile` を選択します。 - - User API Tokensの下で `Create` を選択してOAuth Bearer Tokenを生成します。 - - Observability Cloudのデータ統合ウィザードで使用するため、トークンをコピーまたはメモしておきます。 -1. Splunk Observability Cloudで、Data Management > Available Integrations > ThousandEyes Integration with RUMを開きます。 - - [前回の Splunk 統合](/observability-workshop/en/scenarios/thousandeyes-integration/3-splunk-integration/index.html#step-1-create-a-splunk-observability-cloud-access-token)で使用したものと同じ `Ingest` トークンを使用するか、RUM統合のデータ使用量をより適切に追跡するために専用の `Ingest` トークンを作成して選択します。 - - ThousandEyesからのOAuth Bearerトークンを入力します。 - - テストのマッチングを確認し、必要に応じて選択を変更し、推定データ取り込み量を確認してから `Done` を選択します。 - -## 統合の確認 - -ThousandEyesテストが実行されているRUMアプリケーションに移動し、Mapを表示します。 -ThousandEyesテストも実行されているロケーションにカーソルを合わせると、ThousandEyesメトリクスのプレビューが表示されます： -![Splunk RUM の地図表示、ThousandEyes からのネットワークレイテンシが表示されている](../images/rum-thousandeyes-map-preview.png) - -ThousandEyesでアクティブなアラートがある場合、RUMの該当するロケーションのバブル上にThousandEyesアイコンが表示されます： -![Splunk RUM の地図表示](../images/rum-thousandeyes-map.png) - -該当するリージョンをクリックすると、RUMの他のメトリクスと一緒にネットワークメトリクスが表示されます。`View ThousandEyes Tests` を開いてThousandEyesの関連テストに移動できます： -![RUM メトリクスと ThousandEyes メトリクス、Tests ダイアログが開いた状態](../images/rum-thousandeyes-tests-dialog.png) - -## カスタムダッシュボードで RUM と ThousandEyes のメトリクスを表示する - -これで、関連するThousandEyesテストからのシグナルと他のObservability CloudのKPIを関連付けることができます！ - -1. Dashboards > "RUM" で検索 > `RUM applications` グループ内のすぐに使えるRUMダッシュボードの1つをクリックします。 -1. 興味のあるRUM KPIのチャートをコピーするか、右上のダッシュボードのアクションメニューを開いて `Save As` で自分のダッシュボードグループにコピーを作成します。 -1. 新しいダッシュボードで、シグナル `network.latency` を使用して新しいチャートを作成します。 - - extrapolation policyを `Last value` に変更します。 - - 測定単位をTime > `Millisecond` に変更します。 - - Chart Optionsで、`Show on-chart legend` を選択し、値を `thousandeyes.source.agent.name` にします。これにより、ThousandEyesのエージェントロケーション別にチャートが分割されます。 -1. 新しいチャートに名前を付けて保存し、それをコピーして `network.jitter` と `network.loss` の類似チャートを作成します。コピーしたチャートのシグナルでメトリクスを変更し、必要に応じて測定単位と可視化オプションを調整します。 - -カスタムダッシュボードとチャートの作成に関する詳細なガイダンスは、[Dashboard Workshop](/en/ninja-workshops/7-dashboards-detectors/) を参照してください。 - -{{% notice title="ヒント" style="primary" icon="lightbulb" %}} -ThousandEyesのテストメトリクスと並べて表示すると便利なObservability Cloudの他のメトリクスについて考えてみてください。 - -例えば、SyntheticsでAPIテストを実行している場合は、ロケーション別のAPIテスト成功率のヒートマップを追加することを検討してください。 - - {{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/1-login/_index.md b/content/ja/splunk4rookies/database-monitoring/1-login/_index.md deleted file mode 100644 index 1b368e4ba3..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/1-login/_index.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Splunk Observability Cloud へのログイン -linkTitle: 1. ログイン -weight: 1 -archetype: chapter -time: 5 minutes -description: Splunk Observability Cloud にログインし、お使いの Realm で Database Monitoring が有効になっていることを確認します。 ---- - -データベースのパフォーマンスを調査する前に、Splunk Observability Cloud にログインし、**Database Monitoring** にアクセスできることを確認する必要があります。Database Monitoring の利用可否は Splunk の Realm に依存するため、すべてのリージョンで利用できるわけではありません。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -* Splunk から Workshop Org への招待メールが届いているはずです。見つからない場合は、迷惑メール/スパムフォルダを確認するか、インストラクターにお知らせください。 -* 続行するには、メール内の **Join Now** ボタンをクリックするか、記載されているリンクをクリックしてください。 -* すでに登録プロセスを完了している場合は、残りの手順をスキップして、直接 Splunk Observability Cloud にログインできます - * **[https://app.eu0.signalfx.com](https://app.eu0.signalfx.com)** (EMEA) - * **[https://app.us1.signalfx.com](https://app.us1.signalfx.com)** (APAC/AMER) - - -![login](images/login-password.png) - -* Splunk Observability Cloud のホームページが表示されます。 - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/2-overview/1-what-is-dbm.md b/content/ja/splunk4rookies/database-monitoring/2-overview/1-what-is-dbm.md deleted file mode 100644 index 7f921d59e6..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/2-overview/1-what-is-dbm.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: 1. Database Monitoring とは？ -weight: 1 ---- - -**Splunk Database Monitoring** は、複数のデータベースプラットフォームにわたる詳細なパフォーマンスの可視性を、単一の統合インターフェースで提供します。SQL Server Management Studio、Oracle Enterprise Manager、`pg_stat_statements` を行き来する代わりに、すべての監視対象インスタンスを同じ画面から調査できます。 - -DBA として関心のある3つの情報を収集します - -- **クエリパフォーマンス分析** — 待機時間、CPU 時間、読み取り行数と返却行数、およびオプティマイザが実際に選択した実行プランです。 -- **サーバーメトリクス** — 基盤となるデータベースサーバーの健全性とパフォーマンスです。 -- **アプリケーションの相関** — 対象のクエリの発生元であるアプリケーション、ホスト、APM トレースを特定できます。 - -サポートされているプラットフォームは **Microsoft SQL Server**、**Oracle Database**、および **PostgreSQL** です。 - -{{% notice title="Realm の可用性" style="info" %}} -Database Monitoring の利用可否は Splunk の Realm に依存し、すべてのリージョンで有効になっているわけではありません。次の演習で Database Monitoring のエントリポイントが表示されない場合は、ワークショップの組織がサポートされている Realm にあるかどうかをインストラクターに確認してください。 -{{% /notice %}} - -{{% notice title="演習" style="green" icon="running" %}} - -製品を開く前に、ご自身の環境について少し考えてみましょう。 - -{{< tabs >}} -{{% tab title="質問" %}} -**お使いのデータベースプラットフォーム（SQL Server、Oracle、PostgreSQL）のうち、統合パフォーマンスビューの恩恵を最も受けるのはどれですか？またその理由は何ですか？** -{{% /tab %}} -{{% tab title="回答" %}} -**クエリレベルのパフォーマンスを確認するために、現在ベンダー固有の別ツールに依存しているプラットフォームです。** 統合ビューは、複数のデータベースエンジンを担当している場合に最も効果を発揮します。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/2-overview/2-navigate-to-dbm.md b/content/ja/splunk4rookies/database-monitoring/2-overview/2-navigate-to-dbm.md deleted file mode 100644 index 349849e492..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/2-overview/2-navigate-to-dbm.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: 2. Database Monitoring への移動 -weight: 2 ---- - -Database Monitoring は、Splunk Observability Cloud の APM 機能の一部として提供されています。ワークショップの残りの部分で共通の出発点となるように、ここで開いておきましょう。 - -{{% notice title="Exercise" style="green" icon="running" %}} - -* Splunk Observability Cloud の左側のナビゲーションから **APM** **(1)** をクリックします。 -* APM のランディングページで **Database Monitoring** セクションを見つけ、**Overview** **(2)** をクリックします。 - - -![Database Monitoring への移動](../images/navigate-to-dbm.png) - -* **Database Monitoring Overview** ページが表示されます。このページには、組織にテレメトリを送信しているすべてのデータベースインスタンスが表示されます。 - -{{< tabs >}} -{{% tab title="Question" %}} -**Overview ページに表示されているデータベースインスタンスはおおよそいくつありますか？** -{{% /tab %}} -{{% tab title="Answer" %}} -**ワークショップ環境によって異なります** — 重要なのは、複数のデータベースプラットフォームのインスタンスが同じページに並んで表示されていることです。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/2-overview/_index.md b/content/ja/splunk4rookies/database-monitoring/2-overview/_index.md deleted file mode 100644 index 8ee3a761ec..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/2-overview/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Database Monitoring の概要 -linkTitle: 2. Database Monitoring の概要 -weight: 2 -archetype: chapter -time: 5 minutes -description: Splunk Database Monitoring の概要、サポートされているデータベースプラットフォーム、および UI での場所について理解します。 ---- - -{{% notice icon="user" style="orange" title="ペルソナ" %}} - -あなたは **Database Administrator (DBA)** または **SRE** で、「データベースが遅い」と報告を受けたばかりです。Splunk Observability Cloud にアクセスでき、どこから調査を始めるべきかを把握する必要があります。 - -> [!splunk] これから *Splunk Database Monitoring* を見ていきます。これは **Microsoft SQL Server**、**Oracle Database**、**PostgreSQL** にわたる統合ビューで、クエリパフォーマンス、サーバーメトリクス、および各データベースに依存するアプリケーションを可視化します。この章の目標は、製品がカバーする範囲と、そこへの移動方法を把握することです。 - -{{% /notice %}} - - -![メッセージ](images/messages.png?width=750px) diff --git a/content/ja/splunk4rookies/database-monitoring/3-instances/1-overview-page.md b/content/ja/splunk4rookies/database-monitoring/3-instances/1-overview-page.md deleted file mode 100644 index 1406097e15..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/3-instances/1-overview-page.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: 1. Overview ページ -weight: 1 ---- - -Database Monitoring の **Overview** ページは、すべての調査の出発点です。このページには2つの情報が同時に表示されます。 - -- 選択したメトリクスでランク付けされた、上位5インスタンスの**時系列チャート** -- チャートの下に表示される、すべての監視対象インスタンスの**リスト**（合計クエリ実行時間順にソート） - -リスト内の主要な列は **Total duration** と **Total CPU time** です。この2つの差は重要な意味を持ちます。インスタンスの Total duration が高いにもかかわらず CPU time が比較的低い場合、クエリは有用な処理ではなく、ロック、I/O、ネットワークなどの*待機*に時間を費やしていることを意味します。 - -{{% notice title="演習" style="green" icon="running" %}} - -- **Database Monitoring Overview** ページの上部にある時系列チャートを確認します **(1)**。 -- チャートの下にあるインスタンスリストを確認します **(2)**。 -- 右上のタイムピッカーが適切な時間枠に設定されていることを確認します — **Last 1 hour** がデフォルトとして適切です。 - - -![Database Monitoring Overview](../images/overview-page.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**インスタンスリストの中で、Total duration が最も高いインスタンスはどれですか？** -{{% /tab %}} -{{% tab title="回答" %}} -**リストの最上位の行です** — テーブルはデフォルトで Total duration の降順でソートされるため、最も問題のあるインスタンスは常に最上位に表示されます。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/3-instances/2-rank-by-metric.md b/content/ja/splunk4rookies/database-monitoring/3-instances/2-rank-by-metric.md deleted file mode 100644 index dd6081370c..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/3-instances/2-rank-by-metric.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: 2. 異なるメトリクスでインスタンスをランク付けする -weight: 2 ---- - -Total duration でソートすると、最も多くの処理を行っているインスタンスが見つかります。しかし、別の観点が重要な場合もあります。たとえば、異常に多い*数*のクエリを実行しているインスタンス（ノイズの多いアプリケーションを示唆）や、最も多くの CPU を消費しているインスタンス（単なる高負荷ではなく、非効率なクエリを示唆）などです。 - -Overview ページ上部のチャートでは、3つのランキングを切り替えることができます。 - -- **Execution count** — 実行されたクエリの数です。 -- **Duration** — クエリに費やされた合計時間です。 -- **CPU time** — クエリによって消費された合計 CPU 時間です。 - -{{% notice title="演習" style="green" icon="running" %}} - -- 上位5インスタンスのトレンドチャートで、メトリクスセレクターをクリックし、**Duration** から **Execution count** に切り替えます。 -- 上位5に表示されるインスタンスがどれに変わったか確認します。 -- セレクターを **CPU time** に切り替え、新たに表示されるインスタンスがあるか確認します。 - - -![Rank instances by metric](../images/rank-by-metric.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**3つのランキングすべてで同じインスタンスが最上位に表示されましたか？表示された場合、または表示されなかった場合、それはどのような意味を持ちますか？** -{{% /tab %}} -{{% tab title="回答" %}} -**1つのインスタンスが3つのランキングすべてで上位を占めている場合、そのインスタンスが調査の明らかな出発点です。** 各ランキングで異なるインスタンスが上位に表示される場合、問題は分散している可能性があります。たとえば、あるインスタンスはビジー状態（高い Execution count）で、別のインスタンスは非効率（クエリあたりの CPU が高い）であるといった状況です。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/3-instances/3-pick-an-instance.md b/content/ja/splunk4rookies/database-monitoring/3-instances/3-pick-an-instance.md deleted file mode 100644 index fc3316b9c3..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/3-instances/3-pick-an-instance.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: 3. インスタンスを選択して Navigator を開く -weight: 3 ---- - -対象となるインスタンスが見つかったら、それをクリックして **Navigator** を開きます。Navigator はインスタンス固有のビューで、このワークショップの残りの部分で主に使用する画面です。 - -Navigator の上部には5つのタブがあります: - -- **Queries** — このインスタンスで実行されている上位の SQL ステートメントです。 -- **Query samples** — パラメータや実行プランを含む、キャプチャされた個々の実行です。 -- **Query metrics** — クエリごとの経時的なトレンドです。 -- **Dependencies** — このインスタンスを呼び出しているアプリケーションとホストです。 -- **Metadata** — エンジンバージョン、ホスト、および設定の詳細です。 - -インスタンスに対するアクティブなアラートは、右上隅に表示されます。 - -{{% notice title="演習" style="green" icon="running" %}} - -- **Overview** ページに戻り、チャートを **Duration** に切り替えて、最も遅いインスタンスを対象にします。 -- インスタンスリストで、**上位のインスタンス**の名前をクリックして開きます。 -- そのインスタンスの **Navigator** ビューが表示されます。 -- 上部にある5つのタブ **(1)** と右上のアラートエリア **(2)** を確認してください。 - - -![Navigator ビュー](../images/navigator.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**Navigator を開いたとき、デフォルトで選択されているタブはどれですか？** -{{% /tab %}} -{{% tab title="回答" %}} -**Queries** — Navigator はトップクエリビューで開きます。これは、概要からの調査がほぼ常にここから続行されるためです。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/3-instances/_index.md b/content/ja/splunk4rookies/database-monitoring/3-instances/_index.md deleted file mode 100644 index 1c934514c5..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/3-instances/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Database Instances -linkTitle: 3. Database Instances -weight: 3 -archetype: chapter -time: 15 minutes -description: Database Monitoring の Overview ダッシュボードを使用してインスタンスをランク付けし、最も問題のあるインスタンスを選択します。 ---- - -{{% notice icon="user" style="orange" title="ペルソナ" %}} - -あなたは引き続き **DBA** として、データベースが遅いという苦情のトリアージを行っています。SQL Server、Oracle、PostgreSQL にまたがる多数のデータベースインスタンスを管理しています。さらに深く調査する前に、問題の原因である可能性が最も高い1つ（または2つ）のインスタンスを見つける必要があります。 - -> [!splunk] **Database Monitoring Overview** ページは、監視対象のすべてのデータベースインスタンスを *execution count*、*total duration*、または *total CPU time* でランク付けします。これを利用して、最も忙しく、最も遅いインスタンスを特定し、**Navigator** ビューに移動して本格的な調査を開始します。 - -{{% /notice %}} - - -![Database Instances](images/db-instances-overview.png?width=750px) diff --git a/content/ja/splunk4rookies/database-monitoring/4-queries/1-top-queries.md b/content/ja/splunk4rookies/database-monitoring/4-queries/1-top-queries.md deleted file mode 100644 index fa365ca66b..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/4-queries/1-top-queries.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: 1. インスタンス上のトップクエリ -weight: 1 ---- - -Navigator の **Queries** タブには、このインスタンスで実行されている SQL ステートメントが一覧表示され、最も問題のあるものが上位に表示されます。各クエリについて、選択した時間範囲における集計メトリクス（通常は実行回数、合計実行時間、合計 CPU 時間、読み取り行数と返却行数）が表示されます。 - -**rows read vs. rows returned**（読み取り行数と返却行数）の比率は、最も有用なカラムの1つです。10行を返すために100万行を読み取るクエリは、ほぼ確実にフルスキャンを実行しているか、インデックスが欠落しています。単独では高速に見えても、CPU と I/O の両方を消費しています。 - -{{% notice title="演習" style="green" icon="running" %}} - -* **Queries** タブで、リストをスキャンし、最初のカラムに表示されるクエリテキストを確認します。 -* **Total duration** でソートされていない場合は、そのカラムでソートします。 -* **Rows read** が **Rows returned** よりもはるかに大きいクエリを探します。それらが非効率の疑いがあるクエリです。 - - -![トップクエリ](../images/top-queries.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**平均実行時間が妥当であっても、読み取り行数と返却行数の比率が高いクエリが問題である理由は何ですか？** -{{% /tab %}} -{{% tab title="回答" %}} -**そのクエリは、結果に必要な量をはるかに超える処理を行っています。** 負荷がかかると遅くなり、同じインスタンス上の他のクエリも必要とする I/O を消費しています。 -{{% /tab %}} -{{< /tabs >}} - -* 最も問題のあるクエリの**クエリテキスト**をクリックして開きます。右側のペインに詳細が表示されます。次のページからそこを起点に進めていきます。 - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/4-queries/2-query-samples.md b/content/ja/splunk4rookies/database-monitoring/4-queries/2-query-samples.md deleted file mode 100644 index a4b3324486..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/4-queries/2-query-samples.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: 2. Query Samples -weight: 2 ---- - -**query sample** とは、実際のパラメータ値とタイミングを含む、クエリの実行結果を実際にキャプチャしたものです。集計されたクエリメトリクスは「このクエリは平均的に遅い」と教えてくれます。クエリサンプルは「*この特定の*実行は、これらのパラメータで4.2秒かかった」と教えてくれます。 - -サンプルは、自分の SQL クライアントで遅いクエリを再現する手段になります。また、クエリが一様に遅いのか、それとも特定のパラメータセットが平均値を引き上げているのかを判断する手段にもなります。 - -{{% notice title="演習" style="green" icon="running" %}} - -* 候補となるクエリを選択した状態で、**Query samples** タブをクリックします。 -* このクエリの個別にキャプチャされた実行のリストが表示されます。それぞれに固有の実行時間とパラメータ値があります。 -* リストの中で**最も遅い**サンプルをクリックします **(1)**。 - - -![Query Samples](../images/query-samples.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**最も遅いサンプルのパラメータ値と、より高速なサンプルのパラメータ値を比較したとき、何か意味のある違いはありますか？** -{{% /tab %}} -{{% tab title="回答" %}} -**多くの場合、遅いサンプルは特定のパラメータ値を共有しています** — たとえば、平均よりもはるかに多くの行を所有する顧客 ID などです。これが、*なぜ*そのクエリが遅いのかについての最初の具体的な手がかりとなります。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/4-queries/3-execution-plan.md b/content/ja/splunk4rookies/database-monitoring/4-queries/3-execution-plan.md deleted file mode 100644 index 5920c6fde5..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/4-queries/3-execution-plan.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: 3. 実行プラン -weight: 3 ---- - -**実行プラン（execution plan）**は、クエリを実行するためにデータベースオプティマイザーが選択した戦略です。どのインデックスを使用するか、どの結合アルゴリズムを適用するか、どの順序で実行するかなどが含まれます。クエリが遅い場合、プランを見れば通常その理由がわかります。 - -Splunk Database Monitoring は各クエリサンプルに使用されたプランをキャプチャするため、SQL から推測するのではなく、エンジンが実際に何を行ったかを確認できます。 - -{{% notice title="プランで確認すべきポイント" style="info" %}} -最も一般的な警告サインは、**table scans**（使用可能なインデックスが存在しないためにエンジンがテーブル全体を読み取ること）、より適切なインデックスがあれば回避できる **expensive sorts**、および大量の行に対する **nested loop joins** です。これらを見つけるためにクエリチューニングの専門家である必要はありません。プランの可視化によって明示されます。 -{{% /notice %}} - -{{% notice title="演習" style="green" icon="running" %}} - -* 遅いサンプルが選択された状態で、右側のペインの **Execution plan** セクションまでスクロールします。 -* プランを確認し、主要な操作を記録します。**Index Seek**、**Index Scan**、**Table Scan** のいずれですか？ - - -![実行プラン](../images/execution-plan.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**プランが大きなテーブルで Table Scan を示している場合、考えられる修正方法は何ですか？** -{{% /tab %}} -{{% tab title="回答" %}} -**WHERE 句のカラムにカバリングインデックスを追加します。** その後、オプティマイザーが実際にそのインデックスを使用していることを確認します。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/4-queries/_index.md b/content/ja/splunk4rookies/database-monitoring/4-queries/_index.md deleted file mode 100644 index 1e135670f1..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/4-queries/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Queries と Query Samples -linkTitle: 4. Queries と Query Samples -weight: 4 -archetype: chapter -time: 15 minutes -description: インスタンス上で最も遅いクエリを特定し、個々のクエリサンプルと実行プランを調査します。 ---- - -{{% notice icon="user" style="orange" title="ペルソナ" %}} - -あなたは **DBA** で、最もデータベース時間を消費しているインスタンスを特定しました。次に、*どのクエリ*が原因なのかを把握する必要があります。さらに、最も問題のあるクエリについては、*個々の実行が実際にどのように行われたか*を確認する必要があります。 - -> [!splunk] **Queries** タブには、待機時間、CPU 時間、または読み取り行数の順に並んだ上位の SQL ステートメントが表示されます。**Query samples** タブには、パラメータ、実行時間、データベースオプティマイザが選択した**実行プラン**を含む、それらのクエリの実際にキャプチャされた実行が表示されます。これらを組み合わせることで、「データベースが遅い」という状態から「このクエリが、これらのパラメータで、フルテーブルスキャンを実行している」という具体的な原因特定に至ることができます。 - -{{% /notice %}} - - -![上位クエリ](images/queries-tab.png?width=750px) diff --git a/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/1-query-metrics.md b/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/1-query-metrics.md deleted file mode 100644 index 92a7f157e7..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/1-query-metrics.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: 1. クエリメトリクスの時系列推移 -weight: 1 ---- - -**Query metrics** タブは、選択した時間範囲におけるクエリごとのトレンド（実行回数、平均実行時間、CPU 時間、読み取り行数）をプロットします。**Queries** タブの集計値はクエリが*合計で*何を行ってきたかを示しますが、metrics タブは*それがどのように変化したか*を示します。 - -これが重要なのは、トレンドを見るまでは2つの問題が同じに見えるからです。 - -- 「このクエリはずっと遅い」→ インデックスの欠落や初期からの設計上の問題の可能性が高いです。 -- 「このクエリは先週まで速かったのに今は遅い」→ データ増加の問題、統計情報の問題、または最近のコード変更の可能性が高いです。 - -{{% notice title="演習" style="green" icon="running" %}} - -- Navigator で **Query metrics** タブをクリックします。 -- タイムピッカーでより長い時間範囲（例**Last 24 hours**）を選択し、トレンドが見えるようにします。 -- 調査対象のクエリの **Average duration** チャートを確認します。 - - -![クエリメトリクス](../images/query-metrics.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**クエリの平均実行時間は安定していますか、上昇傾向にありますか、それとも特定の時間帯にスパイクしていますか？** -{{% /tab %}} -{{% tab title="回答" %}} -**上昇傾向は通常、データ増加や統計情報の陳腐化を意味します。特定の時間帯のスパイクは通常、スケジュールジョブとの競合を意味します — 例えば、バックアップや ETL 実行などです。** -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/2-dependencies.md b/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/2-dependencies.md deleted file mode 100644 index 4c6e9e4928..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/2-dependencies.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: 2. 依存関係 -weight: 2 ---- - -**Dependencies** タブは、従来のデータベースツールでは答えられない問いに答えます。*実際にこのデータベースを呼び出しているのはどのアプリケーションとホストか？* Database Monitoring は、検出した接続を Splunk Observability Cloud にすでに存在するアプリケーションテレメトリと相関させることで、匿名の接続文字列のリストではなく、クライアントのリストを提供します。 - -これにより、データベースの調査が*エンジニアリング*の調査に変わります。オンコールの DBA を呼び出す代わりに、負荷の高い呼び出し元を所有するチームに直接問題を転送できます。 - -{{% notice title="演習" style="green" icon="running" %}} - -* Navigator で **Dependencies** タブをクリックします。 -* 選択した時間範囲でこのインスタンスに接続したアプリケーションとホストのリストを確認します。 -* クエリボリュームの最大シェアを占めるアプリケーションを特定します。 - - -![依存関係](../images/dependencies.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**候補となるクエリがあり、それを呼び出しているアプリケーションもわかっています。次に誰に話しますか？** -{{% /tab %}} -{{% tab title="回答" %}} -**呼び出し元のアプリケーションを所有するチーム**です — クエリだけでなく、次の章ではトレースへの直接リンクも渡すことができます。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/3-metadata.md b/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/3-metadata.md deleted file mode 100644 index 5a7cf315be..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/3-metadata.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: 3. メタデータ -weight: 3 ---- - -**Metadata** タブは Navigator の中で最も小さく、見落としやすいタブですが、調査対象のインスタンスに関する基本情報を確認する場所です。エンジンバージョン、ホスト、エディション、設定パラメータがすべてここに表示されます。 - -次のような疑問に答えるために使用します。*これは想定しているエンジンバージョンか？プライマリかレプリカか？同じクラスター内の他のインスタンスと設定は同じか？* - -{{% notice title="演習" style="green" icon="running" %}} - -* Navigator で **Metadata** タブをクリックします。 -* メタデータフィールドを確認し、インスタンスの **engine version** と **host** を記録します。 - - -![メタデータ](../images/metadata.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**クエリのチューニングに時間を費やす前に、エンジンバージョンを確認する価値があるのはなぜですか？** -{{% /tab %}} -{{% tab title="回答" %}} -**オプティマイザの動作、サポートされる構文、さらにはデフォルトのインデックス戦略はバージョン間で変わります** — 別のバージョンで有効だった修正が適用できない場合があり、発生している問題がより新しいバージョンでは既に修正されている可能性もあります。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/_index.md b/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/_index.md deleted file mode 100644 index aaf8db72fa..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/5-metrics-dependencies/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Query Metrics と Dependencies -linkTitle: 5. Query Metrics と Dependencies -weight: 5 -archetype: chapter -time: 10 minutes -description: Query Metrics、Dependencies、Metadata タブを使用して、クエリの時系列トレンドとそのクエリを呼び出しているアプリケーションを確認します。 ---- - -{{% notice icon="user" style="orange" title="ペルソナ" %}} - -あなたは **DBA** で、調査対象のクエリの目星がついています。アプリケーションチームに変更を依頼する前に、そのクエリが本当に時間の経過とともに遅くなっているのかを確認し、どのアプリケーションとホストがそのクエリを呼び出しているのかを正確に把握したいと考えています。 - -> [!splunk] **Query metrics**、**Dependencies**、**Metadata** タブがこれらの疑問に答えます。クエリのトレンド、どのクライアントアプリケーションやホストがそのクエリに依存しているか、そしてデータベースエンジンがインスタンス自体について把握している情報を確認できます。 - -{{% /notice %}} - - -![Query Metrics](images/query-metrics-tab.png?width=750px) diff --git a/content/ja/splunk4rookies/database-monitoring/6-apm-correlation/1-from-query-to-trace.md b/content/ja/splunk4rookies/database-monitoring/6-apm-correlation/1-from-query-to-trace.md deleted file mode 100644 index 3a6cf4e27d..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/6-apm-correlation/1-from-query-to-trace.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: 1. 遅いクエリから APM トレースへ -weight: 1 ---- - -遅いクエリを呼び出しているアプリケーションが **Splunk APM**（.NET または Java）でインストルメントされている場合、Database Monitoring にはそのクエリを実行した APM トレースに直接移動できる **Related Content** リンクが表示されます。クエリ ID を別のツールにコピーしたり、適切なトレース検索を推測したりする必要はありません。 - -これがループを閉じる瞬間です。「データベースが遅い気がする」から始まり、開発者が開いて修正できる特定のアプリケーショントレースにたどり着きます。 - -{{% notice title=".NET and Java" style="info" %}} -クエリからトレースへの相関には、呼び出し元のアプリケーションが Splunk distribution of OpenTelemetry for **.NET** または **Java** でインストルメントされており、データベースクエリの相関が有効になっている必要があります。Related Content リンクが表示されない場合、アプリケーションがインストルメントされていないか、相関機能が有効になっていない可能性があります。 -{{% /notice %}} - -{{% notice title="演習" style="green" icon="running" %}} - -* Navigator の **Queries** タブに戻り、調査対象のクエリを再度選択します。 -* 右側の詳細ペインで、ページ下部にある **Related Content** セクションを探します。 -* **APM** リンクをクリックして、このクエリを実行したトレースの一覧に移動します **(1)**。 -* トレースを1つ選択し、**Trace Waterfall** をクリックして、クエリに至るまでのバックエンドの呼び出しチェーン全体を確認します。 - - -![Database to APM correlation](../images/db-to-apm-link.png) - -{{< tabs >}} -{{% tab title="質問" %}} -**Trace Waterfall を見て、どのアプリケーションサービスがクエリを発行したか、またリクエストがデータベースに到達する前にどのような処理を行ったかを確認できますか？** -{{% /tab %}} -{{% tab title="回答" %}} -**はい — Waterfall にはリクエスト内のすべての span が表示され、データベースコールはリーフ span として現れます。** これにより、アプリケーションチームは呼び出し元を修正するために必要な完全なコンテキストを得ることができます。 -{{% /tab %}} -{{< /tabs >}} - -{{% /notice %}} diff --git a/content/ja/splunk4rookies/database-monitoring/6-apm-correlation/_index.md b/content/ja/splunk4rookies/database-monitoring/6-apm-correlation/_index.md deleted file mode 100644 index 3c87df1b5d..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/6-apm-correlation/_index.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: APM トレースとの関連付け -linkTitle: 6. APM トレースとの関連付け -weight: 6 -archetype: chapter -time: 5 minutes -description: 遅いデータベースクエリから、それを呼び出した .NET や Java アプリケーションのトレースに Splunk APM を使用してジャンプします。 ---- - -{{% notice icon="user" style="orange" title="ペルソナ" %}} - -あなたは **DBA** ですが、遅いクエリはアプリケーションによって発生しています。開発者は呼び出し箇所の修正を始めるためにトレースが必要です。あなたは彼らに直接リンクを渡したいと考えています。 - -> [!splunk] アプリケーションが Splunk APM でインストルメントされている場合、Database Monitoring は**データベースクエリを .NET および Java のトレースと関連付ける**ことができます。Database Monitoring のクエリから、それを実行した APM トレースに直接ピボットできます。これにより、アプリケーションチームは SQL ステートメントだけでなく、バックエンドの完全なコンテキストを得ることができます。 - -{{% /notice %}} - - -![Database と APM の関連付け](images/db-to-apm.png?width=750px) diff --git a/content/ja/splunk4rookies/database-monitoring/7-wrap-up/_index.md b/content/ja/splunk4rookies/database-monitoring/7-wrap-up/_index.md deleted file mode 100644 index cc6e276dbf..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/7-wrap-up/_index.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: ワークショップ まとめ 🎁 -linkTitle: 7. ワークショップ まとめ -weight: 7 -archetype: chapter -time: 1 minute -description: おめでとうございます。ワークショップを修了しました。 ---- - -おめでとうございます。**Splunk4Rookies - Database Monitoring ワークショップ**を修了しました。今日は**Splunk Database Monitoring**を使用して、データベースインスタンスのランク付け、スロークエリの特定、クエリサンプルと実行計画の検査、各クエリに依存するアプリケーションの確認、そしてスロークエリからそれを呼び出したAPMトレースへの直接ピボットを行う方法に慣れました。 - -この修了証をあなたの{{< badge style="blue" icon="linkedin" >}}{{< linkedin color="#0a66c2" >}}{{< /badge >}}プロフィールに追加して成果をアピールしましょう。 - - -![シャンパン](images/champagne.png?width=20vw) diff --git a/content/ja/splunk4rookies/database-monitoring/_index.md b/content/ja/splunk4rookies/database-monitoring/_index.md deleted file mode 100644 index c4c7993967..0000000000 --- a/content/ja/splunk4rookies/database-monitoring/_index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Database Monitoring -weight: 4 -authors: ["Robert Castley"] -time: 60 minutes -description: Splunk Database Monitoring を実際に操作して、遅いクエリを調査し、実行プランを確認し、データベースのパフォーマンスをそれに依存するアプリケーションと相関させる方法を学びます。 -params: - images: - - images/featured-dbm.png -hidden: true ---- - -## はじめに - -データベースはほぼすべてのアプリケーションの中心に位置しており、データベースが遅くなるとそれに依存するすべてのものが遅くなります。**Splunk Database Monitoring** は、Microsoft SQL Server、Oracle Database、PostgreSQL を横断する統一ビューを提供し、問題を引き起こしているクエリ、インスタンス、アプリケーションを特定できるようにします。 - -このハンズオンセッションでは、パフォーマンスに関する苦情に対応するデータベース管理者（DBA）の役割を演じます。本番環境で使用するのと同じ画面を通じて作業を進めます。インスタンスのランク付け、最も遅いクエリへのドリルダウン、クエリサンプルと実行プランの確認、そしてそれらのクエリを呼び出しているアプリケーションへの関連付けまで行います。 - -## ワークショップの概要 - -この1時間のハンズオンセッションでは、以下を扱います。 - -- **Database Monitoring Overview** - Database Monitoring とは何か、どのプラットフォームがサポートされているか、Splunk Observability Cloud のどこで利用できるかを学びます -- **Database Instances** - Overview ダッシュボードを使用して、実行回数、実行時間、CPU 時間でインスタンスをランク付けします -- **Queries と Query Samples** - インスタンス上で最も遅いクエリを特定し、クエリサンプルと実行プランを確認します -- **Query Metrics と Dependencies** - クエリごとのパフォーマンスメトリクスを確認し、各クエリにどのアプリケーションが依存しているかを把握します -- **APM トレースとの相関** - 遅いデータベースクエリから、それをトリガーした .NET または Java アプリケーションのトレースへ移動します - - -![Database Monitoring](images/featured-dbm.png) - -**それでは、データベースに踏み込んでいきましょう。** diff --git a/content/ja/splunk4rookies/financial-services-observability-cloud/_index.md b/content/ja/splunk4rookies/financial-services-observability-cloud/_index.md new file mode 100644 index 0000000000..79398c98cc --- /dev/null +++ b/content/ja/splunk4rookies/financial-services-observability-cloud/_index.md @@ -0,0 +1,31 @@ +--- +title: Finserv Observability Cloud +weight: 3 +authors: ["Robert Castley", "Pieter Hagen", "Jeremy Hicks", "Deepti Bhutani"] +time: 30 minutes +aliases: + - /s4r/financial-services-observability-cloud/ +description: 金融サービスチーム向け。Splunk Observability Cloudが30分のハンズオンセッションでFSIデジタルエコシステム全体にリアルタイムの可視性を提供する方法を確認できます。 +params: + images: + - /images/featured.png +--- + +このワークショップでは、Splunk Observability Cloudが金融サービスのお客様にどのような価値を提供するかをデモンストレーションします。インフラストラクチャからアプリケーション、ユーザーエクスペリエンスまで、デジタルエコシステム全体にわたるリアルタイム、フルフィデリティ、AI駆動のモニタリングを提供する能力を備えています。モダンなクラウドネイティブのマイクロサービスベース環境向けに構築されています。他のオブザーバビリティソリューションとは一線を画す、プラットフォームの最も強力な機能を探索する機会があります。 + +- **Infrastructure Monitoring** +- **NoSampleフルフィデリティApplication Performance Monitoring（APM）による完全なエンドツーエンドのTrace可視性** +- **ノーコードログクエリ** +- **タグ分析とエラースタックによる根本原因分析** +- **コンポーネント間のシームレスなナビゲーションを実現するRelated Content** + +Splunk Observability Cloudの核となる強みの一つは、テレメトリデータを統合し、エンドユーザーエクスペリエンスとアプリケーションスタック全体の包括的な全体像を作成する能力です。 + +このワークショップでは、Kubernetes上にデプロイされたマイクロサービスベースの送金アプリケーションに焦点を当てます。ユーザーは送金を開始でき、ユーザー確認、残高確認、コンプライアンスチェックなど、すべての適切な検証が処理されます。このアプリケーションはOpenTelemetryで完全に計装されており、詳細なパフォーマンスデータをキャプチャします。 + +**OpenTelemetryとは？** +OpenTelemetryは、テレメトリデータ（Metric、Trace、ログなど）の計装、生成、収集、エクスポートを支援するために設計されたオープンソースのツール、API、ソフトウェア開発キット（SDK）のコレクションです。このデータにより、ソフトウェアのパフォーマンスと動作の詳細な分析が可能になります。 + +OpenTelemetryコミュニティは急速に成長しており、Splunk、Google、Microsoft、Amazonなどの主要企業によってサポートされています。現在、Cloud Native Computing Foundation内でKubernetesに次いで2番目に多くのコントリビューターを有しています。 + +![Full Stack](images/featured.png) diff --git a/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/1-login/_index.md b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/1-login/_index.md new file mode 100644 index 0000000000..c97c33bda6 --- /dev/null +++ b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/1-login/_index.md @@ -0,0 +1,29 @@ +--- +title: ログイン +linkTitle: 1. ログイン +weight: 1 +archetype: chapter +time: 5 minutes +description: Splunk Observability Cloudにログインして、すべてのワークショップ参加者が生成したテレメトリを確認します。 +--- + +すべてのワークショップ参加者のブラウザセッションから受信したテレメトリによって提供される実際のユーザーデータを確認します。目標は、パフォーマンスが低下したブラウザ、モバイル、またはタブレットのセッションを見つけ、トラブルシューティングプロセスを開始することです。 + +{{% exercise title="ログイン" %}} + +* Splunkからワークショップ組織への招待メールが届いているはずです。見つからない場合は、迷惑メールフォルダを確認するか、インストラクターに連絡してください。 +* 続行するには、メール内の **Join Now** ボタンをクリックするか、提供されたリンクをクリックします。 +* すでに登録プロセスを完了している場合は、残りの手順をスキップして、直接Splunk Observability Cloudにログインできます: + * **[https://app.eu0.signalfx.com](https://app.eu0.signalfx.com)** (EMEA) + * **[https://app.us1.signalfx.com](https://app.us1.signalfx.com)** (APAC/AMER) + +![login](images/login-password.png) + +* Splunk Observability Cloudのホームページが表示されます。 + +{{% /exercise %}} + + diff --git a/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/2-astronomy-shop/_index.md b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/2-astronomy-shop/_index.md new file mode 100644 index 0000000000..974dd358b8 --- /dev/null +++ b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/2-astronomy-shop/_index.md @@ -0,0 +1,39 @@ +--- +title: Astronomy Shop +linkTitle: 2. Astronomy Shop +weight: 2 +archetype: chapter +time: 10 minutes +description: OpenTelemetryデモアプリケーションを探索し、ワークショップモジュールで使用するテレメトリデータを生成します。 +--- + +{{% notice icon="user" style="orange" title="ペルソナ" %}} + +あなたは **好奇心旺盛な天文学者** です。Astronomy Shopで望遠鏡、星図、アクセサリーを探しています。 + +{{% /notice %}} + +> >[!IMPORTANT] +> **Astronomy Shop** は、OpenTelemetryデモのSplunkバージョンです。OpenTelemetryで完全に計装されたマイクロサービスベースのEコマースアプリケーションで、異なる言語で書かれた複数のサービスにわたってメトリクス、トレース、ログを生成します。ここで生成したテレメトリデータは、トレーナーが選択するモジュールで使用されます。 + +{{% notice title="演習" style="green" icon="running" %}} + +* インストラクターがAstronomy ShopのURLを提供します。 +* カタログを閲覧します — 商品の詳細を確認し、説明を読みます。 +* カートにいくつかのアイテムを追加します。 +* チェックアウトに進み、購入を完了します。 +* 十分なテレメトリデータを生成するために **3〜5回繰り返します** 。 +* 可能であれば、モバイルデバイスやタブレットからもAstronomy Shopを試します。 + +![ui](images/1-shop.png) + +{{< tabs >}} +{{% tab title="質問" %}} +**すべてスムーズに動作しましたか？チェックアウト中に何か異常に気づきましたか？** +{{% /tab %}} +{{% tab title="回答" %}} +Astronomy Shopの一部のサービスには、意図的に問題が注入されています。チェックアウト中にレスポンスが遅かったり、エラーが発生したりしたかもしれません。これは意図的なもので、ワークショップモジュールで調査します。 +{{% /tab %}} +{{< /tabs >}} + +{{% /notice %}} diff --git a/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/1-rum-overview.md b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/1-rum-overview.md new file mode 100644 index 0000000000..b49e4177ac --- /dev/null +++ b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/1-rum-overview.md @@ -0,0 +1,29 @@ +--- +title: RUM Overview +linkTitle: 1. RUM Overview +weight: 1 +time: 5 minutes +--- + +この演習では、RUM Overviewダッシュボードを開きます。ここで表示されるデータは生成されたものであり、あなた自身を含むすべての参加者のデータも含まれています。先ほどAstronomy Shopで行ったブラウジングやショッピングが、ページビュー、エラー、読み込みパフォーマンスなどの実ユーザーメトリクスとして表示されます。Real User Monitoringを通じて自分のセッションを確認できます。 + +{{% exercise title="ストアでフィルタリング" %}} + +* Splunk Observability Cloudのメインメニューで **Digital Experience** にカーソルを合わせ、以下に示すように **Real User Monitoring** セクションから **Overview** **(1)** をクリックします。 + +![RUM](../images/rum-de.png) + +* **Application Summary Dashboard** が開きます。このセクションでは、モニタリングされている **すべての** アプリケーションの概要が表示されます。 + +* Splunk Observability CloudのReal User Monitoring（RUM）Overviewダッシュボードは、実際のユーザーがWebアプリケーションをどのように体験しているかを可視化します。実際のユーザーセッションで発生するブラウザ側のパフォーマンスメトリクス、JavaScriptエラー、ネットワークリクエストの失敗をキャプチャします。ダッシュボードはCore Web Vitals（LCP、INP、CLS）を表示してページ読み込みパフォーマンスを測定し、時系列のエラートレンドを表示し、最近のアラートを表示することで、フロントエンドチームがエンドユーザー体験に影響する問題を特定して解決するために必要なインサイトを提供します。 +* 正しいデータを表示していることを確認するために、自分のストアにフィルタリングして、以降のモジュールが自分の環境に焦点を当てるようにします。 +* フィルターを以下のように設定します **(2)** + * **Time frame** を **-15m** に設定します。 + * **Environment** で **[NAME OF WORKSHOP]-workshop** を選択します。 + * **App** で **[NAME OF WORKSHOP]-store** を選択します。 + * **Source** を **Browser** に設定します。 +* 次に、**Page Views / JavaScript Errors** チャートの上にある **[NAME OF WORKSHOP]-store** **(3)** をクリックします。 + +![main page](../images/rum-dashboard.png) + +{{% /exercise %}} diff --git a/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/2-rum-app-view.md b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/2-rum-app-view.md new file mode 100644 index 0000000000..6da8b27e38 --- /dev/null +++ b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/2-rum-app-view.md @@ -0,0 +1,44 @@ +--- +title: 2. Application View +weight: 2 +--- + +{{% exercise title="RUMダッシュボードを探索する" %}} + +* **UX Metrics**、**Front-end Health**、**Back-end Health**、**Custom Workflows**、**Network Requests**、**Pages**、**Map View** ごとにメトリクスを分類したダッシュボードビューが表示され、過去のメトリクス（デフォルトでは1時間）と比較できます。 + +![RUM Dashboard](../images/rum-metric-map-charts.png) + +* このページで利用可能なタブは以下の通りです + * **UX Metrics** ページビュー、ページロード、Web Vitalsメトリクス + * **Front-end Health** JavaScriptエラーとLong Taskの期間およびカウントの内訳 + * **Back-end Health** ネットワークエラー、リクエスト、Time to First Byte + * **Custom Workflows** カスタムワークフローのREDメトリクス（Rate、Error、Duration） + * **Network Requests** ネットワークURLのグループ化と主要メトリクス + * **Pages** URLのグループ化と主要メトリクスおよびWeb Vitals + * **Map View** 地理的なロケーション別リクエスト + +* 各タブをクリックしてデータを確認します。 + +{{< tabs >}} +{{% tab title="質問" %}} + +1. **Custom Workflows** タブのチャートを確認すると、レイテンシスパイクが明確に表示されているチャートはどれですか？ +2. **Map View** タブで、最もリクエスト量が多いのはどこですか？ + +{{% /tab %}} +{{% tab title="回答" %}} + +1. **Custom Workflow Duration P75** +2. **Ireland** + +{{% /tab %}} +{{< /tabs >}} + +* **Custom Workflows** タブが表示されていることを確認してください。 +* 問題のあるユーザーセッションを特定するために、**Custom Workflow Duration P75** チャートのレイテンシスパイクを使用します。 +* **Custom Workflows Duration** チャートのタイトル下にある **see all** **(1)** リンクをクリックします。 + +![RUM See All](../images/rum-see-all.png) + +{{% /exercise %}} diff --git a/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/3-tag-spotlight.md b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/3-tag-spotlight.md new file mode 100644 index 0000000000..356a1b09a6 --- /dev/null +++ b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/3-tag-spotlight.md @@ -0,0 +1,22 @@ +--- +title: 3. Tag Spotlight +weight: 3 +--- + +{{% exercise title="遅いPlaceOrderセッションのフィルタリング" %}} + +* このダッシュボードには、RUMデータに関連するすべてのタグが表示されます。タグはRUM計装によって自動生成されるキーと値のペアです。タグはデータのフィルタリングやチャート、テーブルの作成に使用されます。Tag Spotlightビューでは、個々のユーザーセッションにドリルダウンできます。 + +![RUM Tag Spotlight](../images/rum-tag-spotlight.png) + +* 時間枠を **Last 1 hour** **(1)** に変更します。 + +* **Custom Workflow Name** チャートを見つけ、リスト内の **PlaceOrder** **(2)** を探してクリックし、 **Add to filter** **(2)** を選択します。 +* **User Sessions** タブ **(3)** をクリックします。 +* **Duration** 見出しを2回クリックして、セッションを期間の長い順（降順）に並べ替えます **(4)**。 + +* これで、期間の長い順（降順）に並べ替えられたUser Sessionsテーブルが表示され、サイトで買い物をしていたユーザーが確認できます。OSバージョン、ブラウザバージョンなどのフィルターを追加して、データをさらに絞り込むこともできます。 + +![RUM Tag Spotlight](../images/rum-user-sessions.png) + +{{% /exercise %}} diff --git a/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/_index.md b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/_index.md new file mode 100644 index 0000000000..35263cef57 --- /dev/null +++ b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/3-rum/_index.md @@ -0,0 +1,27 @@ +--- +title: Digital Experience (RUM) +linkTitle: 3 . Digital Experience (RUM) +weight: 3 +archetype: chapter +time: 15 minutes +description: このセクションでは、Splunk RUMを使用してエンドユーザーの視点からアプリケーションのパフォーマンスをモニタリングする方法を説明します。 +--- + +{{% notice icon="user" style="orange" title="ペルソナ" %}} + +あなたは **フロントエンドエンジニア** 、またはパフォーマンス問題の最初のトリアージを担当する **SRE** です。Online Boutiqueアプリケーションの顧客満足度に関する潜在的な問題を調査するよう依頼されました。 + +{{% /notice %}} + +>[!IMPORTANT] +> ここでは、Online Boutiqueを使用しているあなたや他の参加者によって生成された *Real User Monitoring*（**RUM**）データを確認します。目的は、パフォーマンスが低下したブラウザ、モバイル、またはタブレットのセッションを見つけ、トラブルシューティングプロセスを開始することです。 + +{{< webex chat="Bill Grant" date="Today • 28/01/2026" seenby="PH" >}} +{{< webex-msg from="BG" name="Bill Grant" time="09:42" >}} +やあ！Astronomy shopアプリケーションで顧客満足度に問題がある可能性があるという報告が来ています。最初のトリアージをして、何が起きているか確認してもらえますか？ +{{< /webex-msg >}} + +{{< webex-msg me=true time="09:43" >}} +了解です。まずSplunk ObservabilityのRUMを確認して、ユーザーが何を体験しているか見てみます。👍 +{{< /webex-msg >}} +{{< /webex >}} diff --git a/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/_index.md b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/_index.md new file mode 100644 index 0000000000..daed009643 --- /dev/null +++ b/content/ja/splunk4rookies/o11y-rookies-26/1-modules/1-intro/_index.md @@ -0,0 +1,30 @@ +--- +title: Observability Cloudの紹介 +linkTitle: イントロ +weight: 1 +archetype: chapter +time: 60 minutes +description: 1時間で、Splunk Observability Cloudを使用して、完全に計装されたKubernetesマイクロサービスアプリケーションに対するハンズオントラブルシューティングを体験します。これは後続のレッスンの導入と基礎となります。 +params: + images: + - images/featured-o11y.png +--- + +## はじめに + +Splunk Observability Cloudを使用して問題のトラブルシューティングを行うハンズオン体験を行います。完全に計装されたマイクロサービスアプリケーション — **Astronomy Shop** — がKubernetes上で動作し、メトリクス、トレース、ログをリアルタイム分析のために送信しています。 + + + +## ワークショップの概要 + +この1時間のハンズオンセッションでは、以下の内容をカバーします + +- **実際のユーザーデータの生成** - Astronomy Shopのウェブサイトを閲覧して、メトリクス、トレース、ログを生成します +- **RUM** - パフォーマンスの低いブラウザセッションを特定し、トラブルシューティングを開始します +- **APM** - フロントエンドのRUMトレースをバックエンドのAPMトレースにリンクし、異常やエラーを検出します +- **Log Observer** - 「Related Content」を使用して、APMトレースから関連するログに移動します +- **Synthetics** - 毎分実行されるSyntheticテストで24時間365日のモニタリングを設定します + +>**Astronomy Shopを使って、データを生成しましょう。さあ、買い物に行きましょう！** 🛰️ diff --git a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/1-homepage/images/home-page.png b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/1-homepage/images/home-page.png new file mode 100644 index 0000000000..c127563253 Binary files /dev/null and b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/1-homepage/images/home-page.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/2-rum-home/images/rum-main.png b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/2-rum-home/images/rum-main.png index af6c1236cd..07de041f10 100644 Binary files a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/2-rum-home/images/rum-main.png and b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/2-rum-home/images/rum-main.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/3-apm-home/images/apm-main.png b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/3-apm-home/images/apm-main.png index cb03cc342b..2d02121dc8 100644 Binary files a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/3-apm-home/images/apm-main.png and b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/3-apm-home/images/apm-main.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/5-synthetics-home/images/synthetics-main.png b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/5-synthetics-home/images/synthetics-main.png index e1f65c32de..e383edf6a4 100644 Binary files a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/5-synthetics-home/images/synthetics-main.png and b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/5-synthetics-home/images/synthetics-main.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/6-infrastructure-home/images/infrastructure-overview-old.png b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/6-infrastructure-home/images/infrastructure-overview-old.png new file mode 100644 index 0000000000..14d362a04d Binary files /dev/null and b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/6-infrastructure-home/images/infrastructure-overview-old.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/6-infrastructure-home/images/infrastructure-overview.png b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/6-infrastructure-home/images/infrastructure-overview.png index 14d362a04d..bb1d4ea211 100644 Binary files a/content/ja/splunk4rookies/observability-cloud/3-quick-tour/6-infrastructure-home/images/infrastructure-overview.png and b/content/ja/splunk4rookies/observability-cloud/3-quick-tour/6-infrastructure-home/images/infrastructure-overview.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/7-log-observer/images/linking.png b/content/ja/splunk4rookies/observability-cloud/7-log-observer/images/linking.png index acd2691285..b25d42dd9d 100644 Binary files a/content/ja/splunk4rookies/observability-cloud/7-log-observer/images/linking.png and b/content/ja/splunk4rookies/observability-cloud/7-log-observer/images/linking.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/7-log-observer/images/log-observer-custom-dashboard.png b/content/ja/splunk4rookies/observability-cloud/7-log-observer/images/log-observer-custom-dashboard.png index 8d080b58e4..6e74a95af0 100644 Binary files a/content/ja/splunk4rookies/observability-cloud/7-log-observer/images/log-observer-custom-dashboard.png and b/content/ja/splunk4rookies/observability-cloud/7-log-observer/images/log-observer-custom-dashboard.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/8-synthetics/images/synth-waterfall.png b/content/ja/splunk4rookies/observability-cloud/8-synthetics/images/synth-waterfall.png index aa7e6a46fe..5e3bde1c35 100644 Binary files a/content/ja/splunk4rookies/observability-cloud/8-synthetics/images/synth-waterfall.png and b/content/ja/splunk4rookies/observability-cloud/8-synthetics/images/synth-waterfall.png differ diff --git a/content/ja/splunk4rookies/observability-cloud/_index.md b/content/ja/splunk4rookies/observability-cloud/_index.md index 6e576d7dc6..ec18579aa1 100644 --- a/content/ja/splunk4rookies/observability-cloud/_index.md +++ b/content/ja/splunk4rookies/observability-cloud/_index.md @@ -4,7 +4,7 @@ weight: 1 authors: ["Robert Castley", "Pieter Hagen"] time: 2 minutes aliases: - - /ja/s4r/ + - /s4r/observability-cloud/ description: このワークショップでは、Splunk Observability Cloudがフロントエンドアプリケーションからバックエンドサービスまで、ユーザー体験の視点からどのように即座に可視性を提供するかをお見せします - Splunk Observability Cloudの最も魅力的な機能と差別化要因を体験していただきます。 --- diff --git a/content/ja/splunk4rookies/observability-cloud/images/splunk-full-stack.png b/content/ja/splunk4rookies/observability-cloud/images/featured.png similarity index 100% rename from content/ja/splunk4rookies/observability-cloud/images/splunk-full-stack.png rename to content/ja/splunk4rookies/observability-cloud/images/featured.png