PetClinic モノリスワークショップ

このワークショップの目的は、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 アプリケーションログへのトレースメタデータの自動インジェクションによって生成されたログを確認します。

Kubernetes 上の Spring PetClinic SpringBoot ベースのマイクロサービス

このワークショップの目的は、Java 向けの Splunk 自動ディスカバリーおよび設定機能を紹介することです。

ワークショップのシナリオは、Kubernetes にシンプルな（計装されていない）Java マイクロサービスアプリケーションをインストールすることで作成されます。

既存の Java ベースのデプロイメント向けに自動ディスカバリー機能付きの Splunk OpenTelemetry Collector をインストールする簡単な手順に従うことで、メトリクス、トレース、ログを Splunk Observability Cloud に送信することがいかに簡単かを確認できます。

このワークショップでは、以下のコンポーネントをカバーします：

• 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 は少し寂しそうですが、他のワークショップでカバーしています

1. Real Browser Test

はじめに

このワークショップでは、Chrome DevTools Recorder を使用して、Splunk デモインスタンスに対する Synthetic トランザクションを作成する方法を説明します。

Chrome DevTools Recorder からエクスポートした JSON を使用して、Splunk Synthetic Monitoring の Real Browser Test を作成します。

また、API Test や Uptime Test など、他の Splunk Synthetic Monitoring チェックについても学びます。

前提条件

• Google Chrome ブラウザがインストールされていること
• Splunk Observability Cloud へのアクセス権があること

API Test

API Test は、API エンドポイントの機能とパフォーマンスを柔軟にチェックする方法を提供します。API ファーストの開発へのシフトにより、フロントエンドのコア機能を提供するバックエンドサービスをモニタリングする必要性が高まっています。

マルチステップの API インタラクションのテストに興味がある場合でも、エンドポイントのパフォーマンスを可視化したい場合でも、API Test は目標の達成を支援します。

セットアップ

前提条件

Observability ワークショップインスタンス

Observability ワークショップは、多くの場合、Splunk が提供する事前設定済みの Ubuntu EC2 インスタンス上で実施されます。

ワークショップのインストラクターから、割り当てられたワークショップインスタンスの認証情報が提供されます。

インスタンスには以下の環境変数が既に設定されているはずです：

• ACCESS_TOKEN
• REALM
  • これらはワークショップ用の Splunk Observability Cloud の Access Token と Realm です。
  • これらは OpenTelemetry Collector によって、データを正しい Splunk Observability Cloud 組織に転送するために使用されます。

AWS Command Line Interface (awscli)

AWS Command Line Interface、またはawscliは、AWS リソースと対話するために使用される API です。このワークショップでは、特定のスクリプトがデプロイするリソースと対話するために使用されます。

Splunk が提供するワークショップインスタンスには、既に awscli がインストールされているはずです。

• インスタンスに aws コマンドがインストールされているか、次のコマンドで確認します：

  which aws

  • 予想される出力は /usr/local/bin/aws です

• インスタンスに aws コマンドがインストールされていない場合は、次のコマンドを実行します：

  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 コマンドがインストールされているか確認します：

  which terraform

  • 予想される出力は /usr/local/bin/terraform です

• インスタンスに terraform コマンドがインストールされていない場合は、以下の Terraform が推奨するインストールコマンドを実行してください：

  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 ベースのアプリケーションの自動計装と手動計装の両方を完了するための、すべての設定ファイルとスクリプトを含むリポジトリです。

• ホームディレクトリにワークショップディレクトリがあることを確認します：

  cd && ls

  • 予想される出力には o11y-lambda-workshop が含まれるはずです

• o11y-lambda-workshop ディレクトリがホームディレクトリにない場合は、次のコマンドでクローンします：

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 で構成します：

  aws configure

  • このコマンドは以下のようなプロンプトを表示するはずです：

    AWS Access Key ID [None]: XXXXXXXXXXXXXXXX
    AWS Secret Acces Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Default region name [None]: us-east-1
    Default outoput format [None]:

• インスタンスで awscli が設定されていない場合は、次のコマンドを実行し、インストラクターから提供される値を入力してください。

  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 ファイルを開きます

  vi ~/o11y-lambda-workshop/auto/terraform.tfvars

• 変数に値を設定します。CHANGEME プレースホルダーをインストラクターから提供された値に置き換えてください。

  o11y_access_token = "CHANGEME"
  o11y_realm        = "CHANGEME"
  otel_lambda_layer = ["CHANGEME"]
  prefix            = "CHANGEME"

  • 引用符（"）や括弧 ( [ ] ) はそのまま残し、プレースホルダーCHANGEMEのみを変更してください。
  • prefix は、他の参加者のリソースと区別するため、任意の文字列で設定する固有の識別子です。氏名やメールアドレスのエイリアスを使用することをお勧めします。
  • prefix には小文字のみを使用してください。S3 のような特定の AWS リソースでは、大文字を使用するとエラーが発生します。

• ファイルを保存してエディタを終了します。

• 最後に、編集した terraform.tfvars ファイルを他のディレクトリにコピーします。

  cp ~/o11y-lambda-workshop/auto/terraform.tfvars ~/o11y-lambda-workshop/manual

  • これは、自動計装と手動計装の両方の部分で同じ値を使用するためです

ファイル権限

他のすべてのファイルはそのままでよいですが、autoとmanualの両方にあるsend_message.pyスクリプトは、ワークショップの一部として実行する必要があります。そのため、期待通りに実行するには、適切な権限が必要です。以下の手順に従って設定してください。

• まず、o11y-lambda-workshopディレクトリにいることを確認します：

  cd ~/o11y-lambda-workshop

• 次に、以下のコマンドを実行してsend_message.pyスクリプトに実行権限を設定します：

  sudo chmod 755 auto/send_message.py manual/send_message.py

これで前提条件が整いましたので、ワークショップを始めることができます！

自動計装

ワークショップの最初の部分では、OpenTelemetry による自動計装がどのようにして OpenTelemetry Collector に関数がどの言語で書かれているかを自動検出させ、それらの関数のトレースの取得を開始させるかを示します。

自動計装ワークショップディレクトリとコンテンツ

まず、o11y-lambda-workshop/autoディレクトリとそのファイルの一部を見てみましょう。ここにはワークショップの自動計装部分のすべてのコンテンツがあります。

auto ディレクトリ

• 以下のコマンドを実行して o11y-lambda-workshop/auto ディレクトリに移動します：

  cd ~/o11y-lambda-workshop/auto

• このディレクトリの内容を確認します：

  ls

  • 出力には以下のファイルとディレクトリが含まれるはずです：

    handler             outputs.tf          terraform.tf        variables.tf
    main.tf             send_message.py     terraform.tfvars

  • 出力には以下のファイルとディレクトリが含まれるはずです：

    get_logs.py    main.tf       send_message.py
    handler        outputs.tf    terraform.tf

main.tf ファイル

• main.tf ファイルをより詳しく見てみましょう：

  cat main.tf

各 Lambda 関数の環境変数が設定されているセクションが見つかるはずです。

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 に伝えています。

  SPLUNK_ACCESS_TOKEN = var.o11y_access_token
  SPLUNK_ACCESS_TOKEN = var.o11y_realm

• また、OpenTelemetry が関数/サービスを識別し、それが属する環境/アプリケーションを認識するのに役立つ変数も設定しています。

  OTEL_SERVICE_NAME = "producer-lambda" # consumer関数の場合はconsumer-lambda
  OTEL_RESOURCE_ATTRIBUTES = "deployment.environment=${var.prefix}-lambda-shop"

• コード言語に基づいて、関数のハンドラーに自動的にトレースデータを取得するために適用する必要があるラッパーを OpenTelemetry に知らせる環境変数を設定しています。

  AWS_LAMBDA_EXEC_WRAPPER - "/opt/nodejs-otel-handler"

• producer-lambda関数の場合、レコードを配置する Kinesis ストリームを関数に知らせるための環境変数を設定しています。

  KINESIS_STREAM = aws_kinesis_stream.lambda_streamer.name

• これらの値は、「前提条件」セクションで設定した環境変数、および、この Terraform 構成ファイルの一部としてデプロイされるリソースから取得されます。

また、各関数に Splunk OpenTelemetry Lambda layer を設定する引数も確認できるはずです

layers = var.otel_lambda_layer

• OpenTelemetry Lambda layer は、Lambda 関数の呼び出し時に計測データを収集、処理、およびエクスポートするために必要なライブラリと依存関係を含むパッケージです。

• すべての OpenTelemetry サポート言語のライブラリと依存関係を持つ一般的な OTel Lambda layer がありますが、関数をさらに軽量化するための言語固有の Lambda layer も存在します。

  • 各 AWS リージョンの関連する Splunk OpenTelemetry Lambda layer ARN（Amazon Resource Name）と最新バージョンはこちらで確認できます

producer.mjs ファイル

次に、producer-lambda関数のコードを見てみましょう：

• 以下のコマンドを実行してproducer.mjsファイルの内容を表示します：

  cat ~/o11y-lambda-workshop/auto/handler/producer.mjs

  • この NodeJS モジュールにはプロデューサー関数のコードが含まれています。
  • 基本的に、この関数はメッセージを受け取り、そのメッセージを対象の Kinesis ストリームにレコードとして配置します

Lambda 関数のデプロイとトレースデータの生成

autoディレクトリの内容に慣れたところで、ワークショップ用のリソースをデプロイし、Lambda 関数からトレースデータを生成していきます。

autoディレクトリで Terraform を初期化する

main.tfファイルで定義されたリソースをデプロイするには、まず Terraform がそのファイルと同じフォルダで初期化されていることを確認する必要があります。

• auto ディレクトリにいることを確認します:

  pwd

  • 予想される出力は ~/o11y-lambda-workshop/auto です

• auto ディレクトリにいない場合は、次のコマンドを実行します：

  cd ~/o11y-lambda-workshop/auto

• 次のコマンドを実行して、このディレクトリで Terraform を初期化します

  terraform init

  • このコマンドは同じフォルダにいくつかの要素を作成します：
    • .terraform.lock.hcl ファイル：リソースを提供するために使用するプロバイダーを記録します
    • .terraform ディレクトリ：プロバイダーの構成を保存します
  • 上記のファイルに加えて、apply サブコマンドを使用して terraform を実行すると、デプロイされたリソースの状態を追跡するために terraform.tfstate ファイルが作成されます。
  • これらにより、Terraform は auto ディレクトリの main.tf ファイル内で定義されたとおりに、リソースの作成、状態、破棄を管理できます

Lambda 関数とその他の AWS リソースをデプロイする

このディレクトリで Terraform を初期化したら、リソースのデプロイに進むことができます。

• まず、terraform plan コマンドを実行して、Terraform が問題なくリソースを作成できることを確認します。

  terraform plan

  • これにより、リソースをデプロイするプランといくつかのデータが出力され、意図したとおりに動作することを確認できます。
  • プランに表示される値の一部は、作成後に判明するか、セキュリティ上の理由でマスクされていることに注意してください。

• 次に、terraform apply コマンドを実行して、main.tf ファイルから Lambda 関数とその他のサポートリソースをデプロイします：

  terraform apply

  • Enter a value: プロンプトが表示されたら yes と応答します

  • これにより、以下のような出力が得られます：

    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 ディレクトリにいることを確認します：

  pwd

  • 予想される出力は ~/o11y-lambda-workshop/auto です

• auto ディレクトリにいない場合は、次のコマンドを実行します

  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 引数が必要です

  nohup ./send_message.py --name CHANGEME --superpower CHANGEME &

  • メッセージが成功した場合は、以下のような出力が表示されるはずです

    [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 エンドポイントへのリクエストが成功したことを確認します：

  cat response.logs

  • メッセージが成功していれば、画面に印刷された行の中に次の出力が表示されるはずです：

  {"message": "Message placed in the Event Stream: {prefix}-lambda_stream"}

  • 失敗した場合は、次のように表示されます：

  {"message": "Internal server error"}

Lambda 関数のログを表示する

次に、Lambda 関数のログを確認しましょう。

• producer-lambda ログを表示するには、producer.logs ファイルを確認します：

  cat producer.logs

• consumer-lambda ログを表示するには、consumer.logs ファイルを確認します：

  cat consumer.logs

ログを注意深く調べてください。

Splunk APM、Lambda関数およびトレース

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は前提条件セクションで設定した環境変数から取得されます

環境のサービスマップを表示する

Environment ドロップダウンから環境名を選択したら、Lambda 関数のサービスマップを確認できます。

• APM 概要ページの右側にあるService Mapボタンをクリックします。これによりサービスマップビューに移動します。

producer-lambda関数とそのレコードを配置するために Kinesis ストリームに対して行っている呼び出しが表示されるはずです。

Lambda 関数からのトレースを調査する

• Tracesボタンをクリックしてトレースアナライザーを表示します。

このページでは、producer-lambda関数の OpenTelemetry Lambda layer から取り込まれたトレースを確認できます。

• リストからハイパーリンクされたTrace IDをクリックして、調査するトレースを選択します。

producer-lambda関数が Kinesis ストリームにレコードを配置しているのが確認できます。しかし、consumer-lambda関数のアクションが見当たりません！

これはトレースコンテキストが伝播されていないためです。このワークショップの時点では、Kinesis サービスはトレースコンテキスト伝播をすぐには対応していません。分散トレースは Kinesis サービスで止まっており、そのコンテキストがストリームを通じて自動的に伝播されないため、それ以上先を見ることができません。

少なくとも、今はまだ…

次のセクションでこの問題にどう対処するか見ていきましょう。しかしその前に、後片付けをしましょう！

クリーンアップ

この自動計装演習の一部としてデプロイしたリソースはクリーンアップする必要があります。同様に、producer-lambdaエンドポイントに対してトラフィックを生成していたスクリプトも、まだ実行中であれば停止する必要があります。以下の手順に従ってクリーンアップを行ってください。

send_messageの停止

• send_message.pyスクリプトがまだ実行中の場合は、次のコマンドで停止します：

  fg

  • これによりバックグラウンドプロセスがフォアグラウンドに移動します。
  • 次に[CONTROL-C]を押してプロセスを終了できます。

全ての AWS リソースを破棄する

Terraform は個々のリソースの状態をデプロイメントとして管理するのに優れています。定義に変更があっても、デプロイされたリソースを更新することもできます。しかし、一からやり直すために、リソースを破棄し、このワークショップの手動計装部分の一部として再デプロイします。

以下の手順に従ってリソースを破棄してください：

• autoディレクトリにいることを確認します：

  pwd

  • 期待される出力は ~/o11y-lambda-workshop/auto です

• autoディレクトリにいない場合は、以下のコマンドを実行します：

  cd ~/o11y-lambda-workshop/auto

• 先ほどデプロイした Lambda 関数とその他の AWS リソースを破棄します：

  terraform destroy

  • Enter a value:プロンプトが表示されたらyesと応答します
  • これによりリソースが破棄され、クリーンな環境が残ります

このプロセスにより、私たちの活動の結果として作成されたファイルとディレクトリは残ります。それらについては心配する必要はありません。

手動計装

ワークショップの第 2 部では、OpenTelemetry による手動計装が計測データ収集を強化する方法を実演することに焦点を当てます。より具体的には、今回のケースでは、producer-lambda関数からconsumer-lambda関数にトレースコンテキストデータを伝播させることができるようになります。これにより、現在は自動コンテキスト伝播をサポートしていない Kinesis ストリームを介しても、2 つの関数間の関係を見ることができるようになります。

手動計装ワークショップディレクトリとコンテンツ

再度、作業ディレクトリとそのファイルの一部を確認することから始めます。今回は o11y-lambda-workshop/manual ディレクトリです。ここにはワークショップの手動計装部分のすべてのコンテンツがあります。

manual ディレクトリ

• 以下のコマンドを実行して o11y-lambda-workshop/manual ディレクトリに移動します：

  cd ~/o11y-lambda-workshop/manual

• ls コマンドでこのディレクトリの内容を確認します：

  ls

  • 出力には以下のファイルとディレクトリが含まれるはずです：

    handler             outputs.tf          terraform.tf        variables.tf
    main.tf             send_message.py     terraform.tfvars

auto と manual のファイルを比較する

見た目が同じように見えるこれらのファイルが実際に同じかどうか確認しましょう。

• auto と manual ディレクトリの main.tf ファイルを比較します：

  diff ~/o11y-lambda-workshop/auto/main.tf ~/o11y-lambda-workshop/manual/main.tf

  • 違いはありません！(違いがあるはずはありません。もし違いがあれば、ワークショップ進行役に支援を求めてください)

• 次に、producer.mjs ファイルを比較してみましょう：

  diff ~/o11y-lambda-workshop/auto/handler/producer.mjs ~/o11y-lambda-workshop/manual/handler/producer.mjs

  • ここにはかなりの違いがあります！

• ファイル全体を表示してその内容を調べたい場合は以下を実行します：

  cat ~/o11y-lambda-workshop/handler/producer.mjs

  • 必要な手動計装タスクを処理するために、いくつかの OpenTelemetry オブジェクトを関数に直接インポートしていることに注目してください。

  import { context, propagation, trace } from "@opentelemetry/api";

  • プロデューサー関数でコンテキストを伝播するために、@opentelemetry/api から次のオブジェクトをインポートしています：
    • context
    • propagation
    • trace

• 最後に、consumer.mjs ファイルを比較します：

  diff ~/o11y-lambda-workshop/auto/handler/consumer.mjs ~/o11y-lambda-workshop/manual/handler/consumer.mjs

  • ここにもいくつかの注目すべき違いがあります。より詳しく見てみましょう：

    cat handler/consumer.mjs

    • このファイルでは、次の @opentelemetry/api オブジェクトをインポートしています：
      • propagation
      • trace
      • ROOT_CONTEXT
    • これらを使用して、プロデューサー関数から伝播されたトレースコンテキストを抽出します
    • その後、抽出したトレースコンテキストに name と superpower に基づいた新しいスパン属性を追加します

プロデューサー関数からのトレースコンテキスト伝播

以下のコードはプロデューサー関数内で次のステップを実行します：

1. このトレース用のトレーサーを取得する
2. コンテキストキャリアオブジェクトを初期化する
3. アクティブスパンのコンテキストをキャリアオブジェクトに注入する
4. Kinesis ストリームに配置しようとしているレコードを修正し、アクティブスパンのコンテキストをコンシューマーに運ぶキャリアを含める

...
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. 完了したら、スパンを終了する

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();

これでどのような違いが生まれるか見てみましょう！

Lambda関数のデプロイとトレースデータの生成

トレースデータを収集したい関数やサービスに手動計装を適用する方法がわかったので、Lambda 関数を再度デプロイして、producer-lambdaエンドポイントに対するトラフィックを生成していきましょう。

manual ディレクトリで Terraform を初期化する

新しいディレクトリにいるので、ここでもう一度 Terraform を初期化する必要があります。

• manual ディレクトリにいることを確認します：

  pwd

  • 予想される出力は ~/o11y-lambda-workshop/manual です

• manual ディレクトリにいない場合は、次のコマンドを実行します：

  cd ~/o11y-lambda-workshop/manual

• 次のコマンドを実行して、このディレクトリで Terraform を初期化します：

  terraform init

Lambda 関数とその他の AWS リソースをデプロイする

それでは、これらのリソースを再度デプロイしましょう！

• 問題がないことを確認するために、terraform plan コマンドを実行します。

  terraform plan

• 続いて、terraform apply コマンドを使用して main.tf ファイルから Lambda 関数とその他のサポートリソースをデプロイします：

  terraform apply

  • Enter a value: プロンプトが表示されたら yes と応答します

  • これにより、以下のような出力が得られます：

    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 ディレクトリにいることを確認します：

  pwd

  • 予想される出力は ~/o11y-lambda-workshop/manual です

• manual ディレクトリにいない場合は、次のコマンドを実行します：

  cd ~/o11y-lambda-workshop/manual

• send_message.py スクリプトをバックグラウンドプロセスとして実行します：

  nohup ./send_message.py --name CHANGEME --superpower CHANGEME &

• 次に、response.logs ファイルの内容を確認して、producer-lambdaエンドポイントへの呼び出しが成功しているか確認します：

  cat response.logs

  • メッセージが成功していれば、画面に表示される行の中に次の出力が表示されるはずです：

    {"message": "Message placed in the Event Stream: hostname-eventStream"}

  • 失敗した場合は、次のように表示されます：

    {"message": "Internal server error"}

Lambda 関数のログの確認

ログがどのようになっているか見てみましょう。

• producer.logs ファイルを確認します：

  cat producer.logs

• そして consumer.logs ファイルを確認します：

  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 をコピーして保存してください。 このワークショップの後のステップで必要になります

Splunk APM、Lambda関数とトレース、再び！

ログの外部でコンテキスト伝播の結果を確認するために、もう一度Splunk APM UIを参照します。

Splunk APM サービスマップで Lambda 関数を表示する

もう一度 APM で環境のサービスマップを確認してみましょう。

Splunk Observability Cloud で：

• メインメニューのAPMボタンをクリックします。

• Environment:ドロップダウンからあなたの APM 環境を選択します。

• APM 概要ページの右側にあるService Mapボタンをクリックします。これによりサービスマップビューに移動します。

• 今回は、伝播されたコンテキストによってリンクされたproducer-lambdaとconsumer-lambda関数が見えるはずです！

トレース ID で Lambda トレースを調査する

次に、環境に関連するトレースをもう一度確認します。

• コンシューマー関数のログからコピーしたトレース ID を、Traces 下のView Trace ID検索ボックスに貼り付け、Goをクリックします

最も一般的な 2 つの伝播規格について読むことができます：

1. W3C
2. B3

consumer-lambdaスパンをクリックしてください。

クリーンアップ

いよいよワークショップの最後に来ました。後片付けをしましょう！

send_messageの停止

• send_message.pyスクリプトがまだ実行中の場合は、次のコマンドで停止します：

  fg

  • これによりバックグラウンドプロセスがフォアグラウンドに移動します。
  • 次に[CONTROL-C]を押してプロセスを終了できます。

すべての AWS リソースを破棄する

Terraform は個々のリソースの状態をデプロイメントとして管理するのに優れています。定義に変更があっても、デプロイされたリソースを更新することもできます。しかし、一からやり直すために、リソースを破棄し、このワークショップの手動計装部分の一部として再デプロイします。

以下の手順に従ってリソースを破棄してください：

• manualディレクトリにいることを確認します：

  pwd

  • 予想される出力は ~/o11y-lambda-workshop/manual です

• manualディレクトリにいない場合は、次のコマンドを実行します：

  cd ~/o11y-lambda-workshop/manual

• 以前にデプロイした Lambda 関数とその他の AWS リソースを破棄します：

  terraform destroy

  • Enter a value:プロンプトが表示されたらyesと応答します
  • これにより、リソースが破棄され、クリーンな環境が残ります

結論

Lambda Tracing ワークショップを終えたことをおめでとうございます！自動計装を手動のステップで補完して、producer-lambda関数のコンテキストを Kinesis ストリーム内のレコードを介してconsumer-lambda関数に送信する方法を見てきました。これにより、期待される分散トレースを構築し、Splunk APM で両方の関数間の関係をコンテキスト化することができました。

これで、2 つの異なる関数を手動でリンクしてトレースを構築することができます。これは、自動計装や第三者のシステムがコンテキスト伝播を標準でサポートしていない場合や、より関連性の高いトレース分析のためにカスタム属性をトレースに追加したい場合に役立ちます。

EC2インスタンスへの接続

EC2 インスタンスへ接続

各参加者のために、AWS/EC2 に Ubuntu Linux インスタンスを用意しました。

インストラクターから提供された IP アドレスとパスワードを使用して、以下のいずれかの方法で EC2 インスタンスに接続してください：

• Mac OS / Linux
  • ssh splunk@IP アドレス
• Windows 10+
  • OpenSSH クライアントを使用
• 以前のバージョンの Windows
  • Putty を使用

OpenTelemetryコレクターのデプロイ

OpenTelemetry コレクターのアンインストール

EC2 インスタンスには、すでに Splunk Distribution の OpenTelemetry コレクターの古いバージョンが インストールされている可能性があります。先に進む前に、次のコマンドを使用してアンインストールしましょう：

curl -sSL https://dl.signalfx.com/splunk-otel-collector.sh > /tmp/splunk-otel-collector.sh;
sudo sh /tmp/splunk-otel-collector.sh --uninstall

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

OpenTelemetry collector のデプロイ

Linux EC2 インスタンスに、Splunk Distribution の OpenTelemetry コレクターの最新バージョンをデプロイしましょう。

これはcurlを使用してコレクターバイナリをダウンロードし、特定の引数を指定して実行することで可能です。 これらの引数は、データを送信する realm、使用するアクセストークン、 およびデータを送信するデプロイメント環境をコレクターに指示します。

Splunk Observability Cloud におけるデプロイメント環境とは、システムまたはアプリケーションの個別のデプロイメントであり、同じアプリケーションの他のデプロイメントの設定と重複しない設定を行うことができます。

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

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.

詳細については、インストーラースクリプトを使用した Linux 用コレクターのインストール を参照してください。

コレクターが実行中であることを確認

インスタンスでコレクターが正常に実行されていることを確認しましょう。

ステータスコマンドを終了するには、Ctrl + C を押します。

sudo systemctl status splunk-otel-collector

● 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

コレクターログの確認方法

journalctlを使用してコレクターログを表示できます：

ログの監視を終了するには、Ctrl + C を押します。

sudo journalctl -u splunk-otel-collector -f -n 100

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.

コレクターの設定

このコレクターが使用している設定はどこで見つけられるでしょうか？

その設定は/etc/otel/collectorディレクトリにあります。コレクターをagentモードで インストールしたため、コレクター設定はagent_config.yamlファイルにあります。

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

前提条件

アプリケーションをデプロイする前に、インスタンスに.NET 8 SDK をインストールする必要があります。

sudo apt-get update && \
  sudo apt-get install -y dotnet-sdk-8.0

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.

詳細については、Ubuntu に.NET SDK または.NET Runtime をインストールする を参照してください。

.NET アプリケーションの確認

ターミナルで、アプリケーションディレクトリに移動します：

cd ~/workshop/docker-k8s-otel/helloworld

このワークショップでは、シンプルな「Hello World」.NET アプリケーションを使用します。主要なロジックは HelloWorldController.cs ファイルにあります：

public class HelloWorldController : ControllerBase
{
    private ILogger<HelloWorldController> logger;

    public HelloWorldController(ILogger<HelloWorldController> 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 アプリケーションのビルドと実行

以下のコマンドを使用してアプリケーションをビルドできます：

dotnet build

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

ビルドが成功したら、次のように実行できます：

dotnet run

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

実行したら、Ubuntu インスタンスへの SSH 接続を 2 つ目のターミナルで開き、curl を使用してアプリケーションにアクセスします：

curl http://localhost:8080/hello

Hello, World!

名前を渡すこともできます：

curl http://localhost:8080/hello/Tom

Hello, Tom!

次のステップに進む前に、Ctrl + C を押して Helloworld アプリを終了してください。

次のステップ

アプリケーションを OpenTelemetry で計装するために使用できる 3 つの方法は何でしょうか？

オプションの詳細については、Splunk Observability Cloud 用の.NET アプリケーションの計装 を参照してください。

OpenTelemetryで.NETアプリケーションを計装する

Splunk Distribution of OpenTelemetry のダウンロード

このワークショップでは、NuGet パッケージを使用せず、Splunk Distribution of OpenTelemetry を 手動でインストールします。

最新のsplunk-otel-dotnet-install.shファイルをダウンロードすることから始めます。 これを使用して.NET アプリケーションを計装します：

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 の手動インストール を参照してください。

ディストリビューションのインストール

ターミナルで、以下のようにディストリビューションをインストールします

sh ./splunk-otel-dotnet-install.sh

Downloading v1.8.0 for linux-glibc (/tmp/tmp.m3tSdtbmge/splunk-opentelemetry-dotnet-linux-glibc-x64.zip)...

注意：上記のコマンドを実行する際には、ARCHITECTURE 環境変数を含める必要がある場合があります：

ARCHITECTURE=x64 sh ./splunk-otel-dotnet-install.sh

計装の有効化

次に、OpenTelemetry 計装を有効化できます：

. $HOME/.splunk-otel-dotnet/instrument.sh

デプロイメント環境の設定

デプロイメント環境を設定して、データが Splunk Observability Cloud 内の独自の 環境に流れるようにしましょう：

export OTEL_RESOURCE_ATTRIBUTES=deployment.environment=otel-$INSTANCE

計装を使用したアプリケーションの実行

以下のようにアプリケーションを実行できます：

dotnet run

チャレンジ

Linux インスタンスから C#アプリケーションによってエクスポートされているトレースをどのように確認できるでしょうか？

OTEL_TRACES_EXPORTER=otlp,console dotnet run

exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    traces:
      receivers: [jaeger, otlp, zipkin]
      processors:
        - memory_limiter
        - batch
        - resourcedetection
      exporters: [otlphttp, signalfx, debug]

アプリケーションへのアクセス

アプリケーションが実行中になったら、2 つ目の SSH ターミナルを使用して curl でアクセスします：

curl http://localhost:8080/hello

以前と同様に、Hello, World!が返されるはずです。

トレースログを有効にした場合は、以下のようなトレースがコンソールまたはコレクターログに書き込まれているのを確認できるはずです：

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が表示されるはずです：

右側のService Mapをクリックしてサービスマップを表示します。

次に、右側のTracesをクリックして、このアプリケーションでキャプチャされたトレースを確認します。

個別のトレースは以下のように表示されるはずです：

次のステップに進む前に、Ctrl + C を押して Helloworld アプリを終了してください。

アプリケーションのDocker化

このワークショップの後半では、.NET アプリケーションを Kubernetes クラスターにデプロイします。

しかし、どのようにそれを行うのでしょうか？

最初のステップは、アプリケーション用の Docker イメージを作成することです。これは アプリケーションの「Docker 化」として知られており、プロセスはDockerfileの作成から始まります。

しかし、まず重要な用語を定義しましょう。

重要な用語

Docker とは何ですか？

「Docker は、コンテナと呼ばれる緩い分離環境でアプリケーションをパッケージ化して実行する機能を提供します。分離とセキュリティにより、指定されたホスト上で同時に多くのコンテナを実行できます。コンテナは軽量で、アプリケーションの実行に必要なすべてを含んでいるため、ホストにインストールされているものに依存する必要がありません。」

ソース: https://docs.docker.com/get-started/docker-overview/

コンテナとは何ですか？

「コンテナは、アプリのコンポーネントごとの分離されたプロセスです。各コンポーネントは…独自の分離された環境で実行され、マシン上の他のすべてのものから完全に分離されています。」

ソース: https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/

コンテナイメージとは何ですか？

「コンテナイメージは、コンテナを実行するためのすべてのファイル、バイナリ、ライブラリ、および設定を含む標準化されたパッケージです。」

Dockerfile

「Dockerfile は、コンテナイメージを作成するために使用されるテキストベースのドキュメントです。実行するコマンド、コピーするファイル、起動コマンドなどに関するイメージビルダーへの指示を提供します。」

Dockerfile の作成

/home/splunk/workshop/docker-k8s-otel/helloworldディレクトリにDockerfileという名前のファイルを作成しましょう。

cd /home/splunk/workshop/docker-k8s-otel/helloworld

ファイルの作成には vi または nano を使用できます。vi を使用した例を示します：

vi Dockerfile

新しく開いたファイルに以下の内容をコピー＆ペーストします：

以下のテキストを貼り付ける前に、vi で「i」を押して挿入モードに入ってください。

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イメージをベースにしています：

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で確認できます。

Build ステージ

Dockerfile の次のステージは build ステージです。このステージでは、 mcr.microsoft.com/dotnet/sdk:8.0イメージが使用されます。これも Debian 12 がベースになっていますが、 runtime だけでなく完全な.NET SDKが含まれています。

このステージでは.csprojファイルを build イメージにコピーし、その後dotnet restoreを使用して アプリケーションが使用する依存関係をダウンロードします。

次に、アプリケーションコードを build イメージにコピーし、 dotnet buildを使用してプロジェクトとその依存関係を .dllバイナリのセットにビルドします：

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 用にパッケージ化します：

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 を定義します：

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .

ENTRYPOINT ["dotnet", "helloworld.dll"]

Docker イメージのビルド

Dockerfileができたので、これを使用してアプリケーションを含む Docker イメージを ビルドできます：

docker build -t helloworld:1.0 .

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,

これは、現在のディレクトリのDockerfileを使用してhelloworld:1.0のタグでイメージをビルドするよう Docker に指示します。

以下のコマンドで正常に作成されたことを確認できます：

docker images

REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
helloworld   1.0       db19077b9445   20 seconds ago   217MB

Docker イメージのテスト

続行する前に、以前に開始したアプリケーションがインスタンス上で実行されていないことを確認してください。

Docker イメージを使用して以下のようにアプリケーションを実行できます：

docker run --name helloworld \
--detach \
--expose 8080 \
--network=host \
helloworld:1.0

注意：--network=hostパラメータを含めて、Docker コンテナが インスタンス上のリソースにアクセスできるようにしています。これは後でアプリケーションが localhost 上で実行されているコレクターにデータを送信する必要がある場合に重要です。

Docker コンテナが実行されていることを確認しましょう：

docker ps

$ docker ps
CONTAINER ID   IMAGE            COMMAND                  CREATED       STATUS       PORTS     NAMES
5f5b9cd56ac5   helloworld:1.0   "dotnet helloworld.d…"   2 mins ago    Up 2 mins              helloworld

以前と同様にアプリケーションにアクセスできます：

curl http://localhost:8080/hello/Docker

Hello, Docker!

おめでとうございます。ここまで到達したということは、.NET アプリケーションの Docker 化に成功したということです。

Dockerfileに計装を追加する

アプリケーションを正常に 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 を開きましょう：

vi /home/splunk/workshop/docker-k8s-otel/helloworld/Dockerfile

vi では「i」キーを押して編集モードに入ります ‘NEW CODE’とマークされている行を 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を実行することで確認できます。

# 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を実行することで確認できます。

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という名前のファイルを 以下の内容で作成する必要があります：

vi /home/splunk/workshop/docker-k8s-otel/helloworld/entrypoint.sh

次に、新しく作成したファイルに以下のコードを貼り付けます：

#!/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 instrumentation を有効化したときのように、 Dockerfile に以下のコマンドを含めるだけではだめなのか？」と疑問に思うかもしれません。

RUN . $HOME/.splunk-otel-dotnet/instrument.sh

この方法の問題点は、各 Dockerfile RUN ステップが新しいコンテナと新しいシェルで実行されることです。 あるシェルで環境変数を設定しようとしても、後で見ることはできません。 この問題は、ここで行ったようにエントリポイントスクリプトを使用することで解決されます。 この問題についての詳細は、こちらのStack Overflow の投稿を参照してください。

Docker イメージのビルド

OpenTelemetry .NET instrumentation を含む新しい Docker イメージをビルドしましょう：

docker build -t helloworld:1.1 .

注：以前のバージョンと区別するために、異なるバージョン（1.1）を使用しています。 古いバージョンをクリーンアップするには、以下のコマンドでコンテナ ID を取得します：

docker ps -a

次に、以下のコマンドでコンテナを削除します：

docker rm <old container id> --force

次にコンテナイメージ ID を取得します：

docker images | grep 1.0

最後に、以下のコマンドで古いイメージを削除できます：

docker image rm <old image id>

アプリケーションの実行

新しい Docker イメージを実行しましょう：

docker run --name helloworld \
--detach \
--expose 8080 \
--network=host \
helloworld:1.1

以下を使用してアプリケーションにアクセスできます：

curl http://localhost:8080/hello

トラフィックを生成するために上記のコマンドを数回実行しましょう。

1 分ほど経過したら、Splunk Observability Cloud に新しいトレースが表示されることを確認します。

あなたの特定の環境でトレースを探すことを忘れないでください。

トラブルシューティング

Splunk Observability Cloud にトレースが表示されない場合は、以下のようにトラブルシューティングを行うことができます。

まず、コレクター設定ファイルを編集用に開きます：

sudo vi /etc/otel/collector/agent_config.yaml

次に、トレースパイプラインにデバッグエクスポーターを追加します。これにより、トレースがコレクターログに書き込まれるようになります：

service:
  extensions: [health_check, http_forwarder, zpages, smartagent]
  pipelines:
    traces:
      receivers: [jaeger, otlp, zipkin]
      processors:
        - memory_limiter
        - batch
        - resourcedetection
      #- resource/add_environment
      # NEW CODE: デバッグエクスポーターをここに追加
      exporters: [otlphttp, signalfx, debug]

その後、コレクターを再起動して設定変更を適用します：

sudo systemctl restart splunk-otel-collector

journalctlを使用してコレクターログを表示できます：

ログの追跡を終了するには、Ctrl + C を押します。

sudo journalctl -u splunk-otel-collector -f -n 100

K8sでOpenTelemetryコレクターをインストール

ワークショップパート 1 の振り返り

ワークショップのこの時点で、以下を正常に完了しました：

• Linux ホストに Splunk distribution of OpenTelemetry コレクターをデプロイ
• Splunk Observability Cloud にトレースとメトリクスを送信するよう設定
• .NET アプリケーションをデプロイし、OpenTelemetry で計装
• .NET アプリケーションを Docker 化し、o11y cloud にトレースが流れることを確認

上記のステップを完了していない場合は、ワークショップの残りの部分に進む前に以下のコマンドを実行してください：

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 を実行することで確認できます。

ワークショップパート 2 の紹介

ワークショップの次の部分では、Kubernetes でアプリケーションを実行したいと思います。 そのため、Kubernetes クラスターに Splunk distribution of OpenTelemetry コレクターを デプロイする必要があります。

まず、いくつかの重要な用語を定義しましょう。

重要な用語

Kubernetes とは何ですか？

「Kubernetes は、宣言的な設定と自動化の両方を促進する、コンテナ化されたワークロードとサービスを管理するためのポータブルで拡張可能なオープンソースプラットフォームです。」

Source: https://kubernetes.io/docs/concepts/overview/

Dockerfile に小さな修正を加えた後、アプリケーション用に以前ビルドした Docker イメージを Kubernetes クラスターにデプロイします。

Helm とは何ですか？

Helm は Kubernetes 用のパッケージマネージャーです。

「最も複雑な Kubernetes アプリケーションだとしても、定義、インストール、アップグレード役立ちます」

Helm を使用したコレクターのインストール

プロダクト内ウィザードではなくコマンドラインを使用して、コレクターをインストールするための独自の helmコマンドを作成しましょう。

まず、helm リポジトリを追加する必要があります：ます。」

Source: https://helm.sh/

Helm を使用して K8s クラスターに OpenTelemetry コレクターをデプロイします。

Helm の利点

• 複雑性の管理
  • 数十のマニフェストファイルではなく、単一の values.yaml ファイルを扱う
• 簡単な更新
  • インプレースアップグレード
• ロールバックサポート
  • helm rollback を使用してリリースの古いバージョンにロールバック

ホストコレクターのアンインストール

先に進む前に、Linux ホストに先ほどインストールしたコレクターを削除しましょう： \

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 をインストールする

ウィザードの代わりに、コマンドラインを利用して collector をインストールします。

まず初めに、Helm リポジトリに登録する必要があります

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

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

helm repo update

helm チャートのデプロイメントを設定するために、/home/splunkディレクトリにvalues.yamlという名前の新しいファイルを作成しましょう：

# swith to the /home/splunk dir
cd /home/splunk
# create a values.yaml file in vi
vi values.yaml

Press ‘i’ to enter into insert mode in vi before pasting the text below.　“i"を押下すると vi はインサートモードになります。ペースト前に押下してください

そして、下記のコードをコピーしてください

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キーを押します。

次のコマンドを使用してコレクターをインストールできます：

  helm install splunk-otel-collector --version 0.136.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

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.

コレクターが実行中であることを確認

以下のコマンドでコレクターが実行されているかどうかを確認できます：

kubectl get pods

NAME                                                         READY   STATUS    RESTARTS   AGE
splunk-otel-collector-agent-8xvk8                            1/1     Running   0          49s
splunk-otel-collector-k8s-cluster-receiver-d54857c89-tx7qr   1/1     Running   0          49s

O11y Cloud で K8s クラスターを確認

Splunk Observability Cloud で、Infrastructure -> Kubernetes -> Kubernetes Clustersにナビゲートし、 クラスター名（$INSTANCE-cluster）を検索します：

アプリケーションをK8sにデプロイ

Dockerfile の更新

Kubernetes では、環境変数は通常、Docker イメージに組み込むのではなく.yamlマニフェストファイルで管理されます。そこで、Dockerfile から以下の 2 つの環境変数を削除しましょう：

vi /home/splunk/workshop/docker-k8s-otel/helloworld/Dockerfile

次に、以下の 2 つの環境変数を削除します：

ENV OTEL_SERVICE_NAME=helloworld
ENV OTEL_RESOURCE_ATTRIBUTES='deployment.environment=otel-$INSTANCE'

vi での変更を保存するには、escキーを押してコマンドモードに入り、:wq!と入力してからenter/returnキーを押します。

新しい Docker イメージのビルド

環境変数を除外した新しい Docker イメージをビルドしましょう：

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:

docker ps -a

Then run the following command to delete the container:

docker rm <old container id> --force

Now we can get the container image id:

docker images | grep 1.1

Finally, we can run the following command to delete the old image:

docker image rm <old image id>

Docker イメージを Kubernetes にインポート

通常であれば、Docker イメージを Docker Hub などのリポジトリにプッシュします。 しかし、今回のセッションでは、k3s に直接インポートする回避策を使用します。

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という名前のファイルを作成しましょう：

vi /home/splunk/deployment.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"