ワークショップ

このセクションには、ワークショップ参加者が実行する手順が含まれています：

Red Hat OpenShift クラスターへの OpenTelemetry Collector のデプロイを練習します。
インフラストラクチャメトリクスを取り込むために、コレクターに Prometheus receiverを追加する練習をします。
クラスター内の Weaviate ベクトルデータベースのモニタリングを練習します。
Prometheus を使用した Pure Storage メトリクスの収集を練習します。
大規模言語モデル（LLM）と連携する Python サービスを OpenTelemetry でインストルメントする練習をします。
LLM と連携するアプリケーションのトレースで OpenTelemetry がキャプチャする詳細情報を理解します。

ワークショップ環境の概要

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 を割り当てられ、独立した作業のための隔離された環境が確保されます。

ワークショップの内容

ワークショップ中、各参加者は以下のタスクを実行します。

自分の Namespace に OpenTelemetry Collector をデプロイおよび設定する
クラスターインフラストラクチャとのオブザーバビリティデータ収集を統合する
NVIDIA NIM モデルを活用する Python アプリケーション をデプロイする
Splunk Observability Cloud を使用してアプリケーションのパフォーマンスとインフラストラクチャメトリクスをモニタリングする

Prometheus とは

Prometheus は通常、ストレージとアラートに使用されるフルスタックモニタリングシステムを指しますが、このワークショップでは Prometheus エコシステムのデータ標準に焦点を当てます。

このワークショップでは Prometheus Exporter を活用します。これは、コンポーネントの内部ヘルスを標準化されたメトリクスエンドポイント（例: http://localhost:9100/metrics）に変換する小さなユーティリティです。

フル構成の Prometheus サーバーを使用してこのデータを収集する代わりに、OpenTelemetry Collector を使用します。Prometheus receiver を使用することで、Collector はこれらのエンドポイントを スクレイプ でき、広くサポートされている業界フォーマットを使用してリッチなテレメトリデータを収集できます。

OpenShift クラスターへの接続

5 minutes

EC2 インスタンスへの接続

各参加者用に AWS/EC2 上に Ubuntu Linux インスタンスを用意しています。

講師から提供された IP アドレスとパスワードを使用して、以下のいずれかの方法で EC2 インスタンスに接続します。

Mac OS / Linux
- ssh splunk@IP address
Windows 10+
- OpenSSH クライアントを使用
それ以前のバージョンの Windows
- Putty を使用

ワークショップ参加者番号の設定

講師が各参加者に 1 から 30 までの番号を割り当てます。この番号を環境変数に保存してください。ワークショップ全体を通して使用するため、番号を覚えておいてください。

export PARTICIPANT_NUMBER=<your 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）を、パスに含まれている場所に移動します。例えば以下のようにします。

sudo mv oc /usr/local/bin/oc
sudo mv kubectl /usr/local/bin/kubectl

OpenShift クラスターへの接続

Kube config ファイルが splunk ユーザーによって変更可能であることを確認します。

chmod 600 /home/splunk/.kube/config

ワークショップ主催者から提供されたクラスター API URL とパスワードを使用して、OpenShift クラスターにログインします。

oc login https://api.<cluster-domain>:443 -u participant$PARTICIPANT_NUMBER -p '<password>'

OpenShift クラスターに接続されていることを確認します。

oc whoami --show-server

https://api.***.openshiftapps.com:443

OpenTelemetry Collector のデプロイ

10 minutes

このセクションでは、OpenShift の Namespace に OpenTelemetry Collector をデプロイします。 Collector は、クラスター内で動作するインフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、結果のデータを Splunk Observability Cloud に送信します。

OpenTelemetry Collector のデプロイ

Helm がインストールされていることを確認する

以下のコマンドを実行して、Helm がインストールされていることを確認します。

helm version

version.BuildInfo{Version:"v3.19.4", GitCommit:"7cfb6e486dac026202556836bb910c37d847793e", GitTreeState:"clean", GoVersion:"go1.24.11"}

インストールされていない場合は、以下のコマンドを実行します。

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 リポジトリを追加します。

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart

リポジトリが最新であることを確認します。

helm repo update

環境変数の設定

Collector がデータを送信する Splunk 環境を設定するための環境変数を設定します。

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

環境名が設定されていることを確認します：

echo $ENVIRONMENT_NAME

ai-pod-workshop-participant-1

Collector のデプロイ

ワークショップディレクトリに移動します。

cd ~/workshop/cisco-ai-pods

以下のコマンドを使用して、自分の Namespace に Collector をインストールします。

{ [ -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 というエラーが表示された場合は、環境変数を再度定義する必要があります。以下のコマンドを実行する前に、参加者番号を追加してください:
export PARTICIPANT_NUMBER=<your 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）でフィルターを追加します。

NVIDIA コンポーネントのモニタリング

10 minutes

このセクションでは、OpenTelemetry Collector で Prometheus receiverを使用して、OpenShift クラスターで動作している NVIDIA コンポーネントをモニタリングします。まず、Collector の設定ファイルが保存されているディレクトリに移動します。

cd otel-collector

NVIDIA DCGM Exporter メトリクスの取得

NVIDIA DCGM exporter は OpenShift クラスターで動作しています。これは Splunk に送信できる GPU メトリクスを公開します。

これを行うために、Collector のデプロイ時に使用した otel-collector-values.yaml ファイルを編集して、Collector の設定をカスタマイズしましょう。

kubeletstats receiverの直下に、以下の内容を追加します。

      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 ファイルに新しいパイプラインも追加する必要があります。

以下のコードをファイルの末尾に追加します。

    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の直下に追加しましょう。

          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 セクションの前に追加します。

    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が含まれていることを確認します。

    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 ファイルではインデントが重要であり、正確である必要があることを忘れないでください。

diff otel-collector-values.yaml otel-collector-values-with-nvidia.yaml

必要に応じてファイルを更新し、内容が一致することを確認してください。

まだ Collector を再起動しないでください

OpenShift 環境では Collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動は待ちます。

ベクターデータベースのモニタリング

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 セクションの前に追加してください：

      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の設定にも追加されていることを確認する必要があります：

    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 セクションの前に以下の設定を追加してください：

      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 メトリクスが追加されないように、別のパイプラインを使用する必要があります）。以下をファイルの末尾に追加してください：

        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 ファイルではインデントが重要であり、正確である必要があることを忘れないでください：

diff otel-collector-values.yaml otel-collector-values-with-weaviate.yaml

必要に応じてファイルを更新し、内容が一致することを確認してください。

まだ Collector を再起動しないでください

OpenShift 環境では Collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動は待ちます。

ストレージのモニタリング

5 minutes

このステップでは、ストレージをモニタリングするために Prometheus receiverを設定します。

Cisco AI PODs はどのようなストレージを使用しているか？

Cisco AI PODs には、Pure Storage、VAST、NetApp など、さまざまなストレージオプションがあります。

このワークショップでは Pure Storage に焦点を当てます。

Pure Storage メトリクスをどのように取得するか？

Pure Storage を使用する Cisco AI PODs は、Kubernetes に永続ストレージを提供する Portworx というテクノロジーも使用しています。

Portworx には Prometheus receiverでスクレイプできるメトリクスエンドポイントがあります。

Prometheus でストレージメトリクスを取得する

OpenTelemetry Collector の設定を変更して、Prometheus receiverで Portworx メトリクスをスクレイプしましょう。

otel-collector-values.yaml ファイルに追加の Prometheus receiver creatorセクションを追加します。receiver_creator/weaviate セクションの後、pipelines セクションの前に追加してください：

      receiver_creator/storage:
        # Name of the extensions to watch for endpoints to start and stop.
        watch_observers: [ k8s_observer ]
        receivers:
          prometheus/portworx:
            config:
              config:
                scrape_configs:
                  - job_name: portworx-metrics
                    static_configs:
                      - targets:
                          - '`endpoint`:17001'
                          - '`endpoint`:17018'
            rule: type == "pod" && labels["app"] == "portworx-metrics-sim"

Portworx メトリクスが filter/metrics_to_be_included filter processorの設定にも追加されていることを確認する必要があります：

    processors:
      filter/metrics_to_be_included:
        metrics:
          # Include only metrics used in charts and detectors
          include:
            match_type: strict
            metric_names:
              - DCGM_FI_DEV_FB_FREE
              - ...
              - px_cluster_cpu_percent
              - px_cluster_disk_total_bytes
              - px_cluster_disk_utilized_bytes
              - px_cluster_status_nodes_offline
              - px_cluster_status_nodes_online
              - px_volume_read_latency_seconds
              - px_volume_reads_total
              - px_volume_readthroughput
              - px_volume_write_latency_seconds
              - px_volume_writes_total
              - px_volume_writethroughput

注意: px_cluster_cpu_percent から始まる新しいメトリクスのみを追加してください。

Portworx メトリクス用の新しいメトリクスパイプラインも追加する必要があります。以下をファイルの末尾に追加してください：

        metrics/storage:
          exporters:
            - signalfx
          processors:
            - memory_limiter
            - filter/metrics_to_be_included
            - batch
            - resourcedetection
            - resource
          receivers:
            - receiver_creator/storage

変更した otel-collector-values.yaml ファイルの内容を otel-collector-values-with-portworx.yaml ファイルと比較してください。yaml ファイルではインデントが重要であり、正確である必要があることを忘れないでください：

diff otel-collector-values.yaml otel-collector-values-with-portworx.yaml

必要に応じてファイルを更新し、内容が一致することを確認してください。

まだ Collector を再起動しないでください

OpenShift 環境では Collector の再起動にノードあたり 3 分かかるため、すべての設定変更が完了するまで再起動は待ちます。

AI POD ダッシュボードの確認

10 minutes

このセクションでは、Splunk Observability Cloud の AI POD ダッシュボードを確認し、NVIDIA、Pure Storage、および Weaviate からのデータが期待通りに取得されていることを確認します。

OpenTelemetry Collector の設定を更新する

以下の Helm コマンドを実行して、Collector の設定変更を適用できます：

{ [ -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 というエラーが表示された場合は、環境変数を再度定義する必要があります。以下のコマンドを実行する前に、参加者番号を追加してください：
export PARTICIPANT_NUMBER=<your 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 クラスター名でフィルタリングされていることを確認してください。チャートは以下の例のように表示されるはずです：

Pure Storage ダッシュボードタブの確認

PURE STORAGE タブに移動し、ダッシュボードが OpenShift クラスター名でフィルタリングされていることを確認してください。チャートは以下の例のように表示されるはずです：

Weaviate Infrastructure Navigator の確認

Weaviate は AI POD にデフォルトで含まれていないため、すぐに使える AI POD ダッシュボードには含まれていません。代わりに、Infrastructure Navigator の1つを使用して Weaviate のパフォーマンスデータを確認できます。

Splunk Observability Cloud で Infrastructure -> AI Frameworks -> Weaviate に移動してください。対象の k8s.cluster.name でフィルタリングし、以下の例のように Navigator が表示されていることを確認してください：

LLM アプリケーションの確認

15 minutes

ワークショップの最後のステップでは、instruct モデルと embeddings モデルを使用するアプリケーションを OpenShift クラスターにデプロイします。

LangChain とは？

LLM とやり取りするほとんどのアプリケーションと同様に、このアプリケーションは Python で書かれています。また、LLM を活用したアプリケーションの開発を簡素化するオープンソースのオーケストレーションフレームワークである LangChain を使用しています。

アプリケーション概要

LLM への接続

アプリケーションはまず、使用する2つの LLM に接続します：

meta/llama-3.2-1b-instruct：ユーザーのプロンプトへの応答に使用
nvidia/llama-3.2-nv-embedqa-1b-v2：埋め込みの計算に使用

# 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 とのやり取りで使用するプロンプトテンプレートを定義します：

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 のデータシートドキュメントが事前に格納されたベクターデータベースに接続します：

    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） を使用してチェーンを定義します。|（パイプ）記号はアセンブリラインのように機能し、あるステップの出力が次のステップの入力になります。

    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 モデルは複雑なオブジェクトを返します。この「クリーナー」により、シンプルで読みやすいテキスト文字列が返されるようになります。

チェーンの実行

最後に、アプリケーションはエンドユーザーの質問を入力として渡してチェーンを実行します：

    response = chain.invoke(question)

これが「スタート」ボタンです。エンドユーザーの質問をパイプラインの最初に投入すると、リトリーバー、プロンプト、LLM を経由して、最終的に答えが出力されます。

LLM アプリケーションの計装

10 minutes

OpenTelemetry によるアプリケーションの計装

計装パッケージ

アプリケーションからメトリクス、トレース、およびログを取得するために、OpenTelemetry で計装を行いました。これには、requirements.txt ファイルに以下のパッケージを追加する必要がありました（最終的に pip install でインストールされます）:

splunk-opentelemetry==2.8.0

また、このアプリケーションのコンテナイメージをビルドするために使用する Dockerfile に、追加の OpenTelemetry 計装パッケージをインストールする以下の記述を追加しました:

# Add additional OpenTelemetry instrumentation packages
RUN opentelemetry-bootstrap --action=install

次に、Dockerfile の ENTRYPOINT を変更し、アプリケーション実行時に opentelemetry-instrument を呼び出すようにしました:

ENTRYPOINT ["opentelemetry-instrument", "flask", "run", "-p", "8080", "--host", "0.0.0.0"]

最後に、この LangChain アプリケーションから OpenTelemetry で収集されるトレースとメトリクスを強化するために、追加の Splunk 計装パッケージを追加しました:

splunk-otel-instrumentation-langchain==0.1.4
splunk-otel-util-genai==0.1.4

環境変数

OpenTelemetry でアプリケーションを計装するために、アプリケーションのデプロイに使用する Kubernetes マニフェストファイルにいくつかの環境変数も含めました:

  env:
    - name: OTEL_SERVICE_NAME
      value: "llm-app"
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: "http://splunk-otel-collector-agent:4317"
    - name: OTEL_EXPORTER_OTLP_PROTOCOL
      value: "grpc"
      # filter out health check requests to the root URL
    - name: OTEL_PYTHON_EXCLUDED_URLS
      value: "^(https?://)?[^/]+(/)?$"
    - name: OTEL_PYTHON_DISABLED_INSTRUMENTATIONS
      value: "httpx,requests"
    - name: OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT
      value: "true"
    - name: OTEL_LOGS_EXPORTER
      value: "otlp"
    - name: OTEL_PYTHON_LOG_CORRELATION
      value: "true"
    - name: OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE
      value: "delta"
    - name: OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED
      value: "true"
    - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT
      value: "true"
    - name: OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT_MODE
      value: "SPAN_AND_EVENT"
    - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS
      value: "span_metric_event,splunk"
    - name: OTEL_INSTRUMENTATION_GENAI_EMITTERS_EVALUATION
      value: "replace-category:SplunkEvaluationResults"
    - name: SPLUNK_PROFILER_ENABLED
      value: "true"

OTEL_INSTRUMENTATION_LANGCHAIN_CAPTURE_MESSAGE_CONTENT および OTEL_INSTRUMENTATION_GENAI_* 環境変数は、使用している LangChain 計装に固有のものです。

LLM アプリケーションのデプロイ

10 minutes

LLM アプリケーションのデプロイ

以下のコマンドを使用して、このアプリケーションを OpenShift クラスターにデプロイします:

cd ~/workshop/cisco-ai-pods
oc apply -f ./llm-app/k8s-manifest.yaml

注意: この Python アプリケーションの Docker イメージをビルドするために、以下のコマンドを実行しました:
cd workshop/cisco-ai-pods/llm-app
docker build --platform linux/amd64 -t ghcr.io/splunk/cisco-ai-pod-workshop-app:1.0 .
docker push ghcr.io/splunk/cisco-ai-pod-workshop-app:1.0

LLM アプリケーションのテスト

アプリケーションが期待どおりに動作していることを確認しましょう。

curl コマンドにアクセスできる Pod を起動します:

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 に質問を送信します:

curl -X "POST" \
 'http://llm-app:8080/askquestion' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
    "question": "How much memory does the NVIDIA H200 have?"
  }'

The NVIDIA H200 has 141GB of HBM3e memory, which is twice the capacity of the NVIDIA H100 Tensor Core GPU with 1.4X more memory bandwidth.

メトリクス、トレース、およびログの確認

10 minutes

Splunk Observability Cloud でトレースデータを表示する

Splunk Observability Cloud で APM に移動し、Service Map を選択します。お使いの環境名が選択されていることを確認してください（例: ai-pod-workshop-participant-1）。以下のようなサービスマップが表示されるはずです:

右側のメニューで Traces をクリックします。次に、実行時間の長いトレースを1つ選択します。以下の例のように表示されるはずです:

このトレースは、ユーザーの質問（例: 「How much memory does the NVIDIA H200 have?」）に対する回答を返すために、アプリケーションが実行したすべてのインタラクションを示しています。

例えば、アプリケーションが Weaviate ベクトルデータベースで質問に関連するドキュメントを検索するために類似度検索を実行した箇所を確認できます。

また、ベクトルデータベースから取得したコンテキストを含め、アプリケーションが LLM に送信するプロンプトをどのように作成したかも確認できます:

注意: トレースウォーターフォールビューで chat と invoke_workflow の AI インタラクションが表示されない場合、または右側に AI details タブが表示されない場合は、有効化が必要な superpowers についてインストラクターに確認してください。

最後に、LLM からのレスポンス、所要時間、および使用された入力トークンと出力トークンの数を確認できます:

メトリクスが Splunk に送信されていることを確認する

Splunk Observability Cloud で Dashboards に移動し、Built-in dashboard groups に含まれる Cisco AI PODs Dashboard を検索します。 NIM FOR LLMS タブに移動し、お使いの OpenShift クラスター名でダッシュボードがフィルタリングされていることを確認します。以下の例のようにチャートにデータが表示されているはずです:

まとめ

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 がキャプチャする詳細情報の理解。

ワークショップ

2. ワークショップのサブセクション

ワークショップ環境の概要

ラボ環境

デプロイ済みのインフラストラクチャ

ワークスペース

ワークショップの内容

Prometheus とは

OpenShift クラスターへの接続

EC2 インスタンスへの接続

ワークショップ参加者番号の設定

OpenShift CLI のインストール

OpenShift クラスターへの接続

OpenTelemetry Collector のデプロイ

OpenTelemetry Collector のデプロイ

Helm がインストールされていることを確認する

Splunk OpenTelemetry Collector Helm Chart の追加

環境変数の設定

Collector のデプロイ

Splunk Observability Cloud で Collector データを確認する

NVIDIA コンポーネントのモニタリング

NVIDIA DCGM Exporter メトリクスの取得

NVIDIA NIM メトリクスの取得

filter processorの追加

変更の確認

ベクターデータベースのモニタリング

ベクターデータベースとは？

ベクターデータベースはどのように使用されるのか？

Prometheus で Weaviate メトリクスを取得する

ストレージのモニタリング

Cisco AI PODs はどのようなストレージを使用しているか？

Pure Storage メトリクスをどのように取得するか？

Prometheus でストレージメトリクスを取得する

AI POD ダッシュボードの確認

OpenTelemetry Collector の設定を更新する

AI POD 概要ダッシュボードタブの確認

Pure Storage ダッシュボードタブの確認

Weaviate Infrastructure Navigator の確認

LLM アプリケーションの確認

LangChain とは？

アプリケーション概要

LLM への接続

プロンプトテンプレートの定義

ベクターデータベースへの接続

チェーンの定義

チェーンの実行

LLM アプリケーションの計装

OpenTelemetry によるアプリケーションの計装

計装パッケージ

環境変数

LLM アプリケーションのデプロイ

LLM アプリケーションのデプロイ

LLM アプリケーションのテスト

メトリクス、トレース、およびログの確認

Splunk Observability Cloud でトレースデータを表示する

メトリクスが Splunk に送信されていることを確認する

まとめ

まとめ