AWS Lambda関数の分散トレーシング

45 minutes Author Guy-Francis Kono

このワークショップでは、AWS Lambdaで実行される小規模なサーバーレスアプリケーションの分散トレースを構築し、AWS Kinesisを介してメッセージをproduceおよびconsumeする方法を学びます。

まず、OpenTelemetryの自動計装がどのようにトレースをキャプチャし、選択した宛先にエクスポートするかを確認します。

次に、手動計装によってコンテキスト伝播を有効にする方法を見ていきます。

このワークショップのために、SplunkはAWS/EC2上のUbuntu Linuxインスタンスを事前に構成しています。このインスタンスにアクセスするには、ワークショップインストラクターが提供するURLにアクセスしてください。

セットアップ

前提条件

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

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

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

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

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

また、Multipass を使用してローカルの Observability ワークショップインスタンスをデプロイすることもできます。

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を使用して、以下のリソースをデプロイします

AWS API Gateway
Lambda関数
Kinesis Stream
CloudWatchロググループ
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
```

ワークショップの質問

このテンプレートによってどのAWSリソースが作成されているか特定できますか？
OpenTelemetry計装がどこでセットアップされているか特定できますか？
- ヒント: Lambda 関数の定義を調べてください
以前に設定した環境変数によってどの計装情報が提供されているか判断できますか？

各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
```

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

ワークショップの質問

OpenTelemetryが読み込まれているのが見えますか？splunk-extension-wrapper のある行に注目してください
- - splunk-extension-wrapperが読み込まれているのを見るために head -n 50 producer.logs または head -n 50 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 は前提条件セクションで設定した環境変数から取得されます

メモ

トレースが Splunk APM に表示されるまで数分かかる場合があります。環境のリストにあなたの環境名が表示されるまで、ブラウザの更新ボタンを押してみてください

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

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

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

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

ワークショップの質問

あなたの consumer-lambda 関数はどうなっていますか？

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ディレクトリに何か違いがありますか？

`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 に基づいた新しいスパン属性を追加します

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

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

このトレース用のトレーサーを取得する
コンテキストキャリアオブジェクトを初期化する
アクティブスパンのコンテキストをキャリアオブジェクトに注入する
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();

コンシューマー関数でのトレースコンテキスト抽出

以下のコードはコンシューマー関数内で次のステップを実行します

producer-lambda から取得したコンテキストをキャリアオブジェクトに抽出する
現在のコンテキストからトレーサーを抽出する
抽出したコンテキスト内でトレーサーを使用して新しいスパンを開始する
ボーナス：メッセージからの値を含むカスタム属性など、追加の属性をスパンに追加する！
完了したら、スパンを終了する

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 ボタンをクリックします。これによりサービスマップビューに移動します。

> 注意：トレースが Splunk APM に表示されるまで数分かかる場合があります。環境のリストにあなたの環境名が表示されるまで、ブラウザの更新ボタンを押してみてください

ワークショップの質問

違いに気づきましたか？

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

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

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

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

メモ

トレース ID は、私たちが伝播したトレースコンテキストの一部でした。

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

ワークショップの質問

私たちはどちらを使用していますか？

私たちの NodeJS 関数をサポートする Splunk Distribution of Opentelemetry JS は、デフォルトで W3C 標準を使用しています

ワークショップの質問

ボーナス質問：W3CヘッダーとB3ヘッダーを混在させるとどうなりますか？

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

ワークショップの質問

あなたのメッセージからの属性を見つけることができますか？

クリーンアップ

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

`send_message` の停止

send_message.py スクリプトがまだ実行中の場合は、次のコマンドで停止します
```
fg
```
- これによりバックグラウンドプロセスがフォアグラウンドに移動します。
- 次に [CONTROL-C] を押してプロセスを終了できます。

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

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

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

AWS Lambda関数の分散トレーシング

Lambdaトレーシングのサブセクション

セットアップ

前提条件

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

AWS Command Line Interface (awscli)

Terraform

ワークショップディレクトリ (o11y-lambda-workshop)

AWS & Terraform 変数

AWS

Terraform

ファイル権限

自動計装

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

auto ディレクトリ

main.tf ファイル

producer.mjs ファイル

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

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

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

producer-lambda URL (base_url) にトラフィックを送信する

Lambda 関数のログを表示する

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

Splunk APM 概要で環境名を確認する

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

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

クリーンアップ

send_message の停止

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

手動計装

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

manual ディレクトリ

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

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

コンシューマー関数でのトレースコンテキスト抽出

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

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

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

producer-lambda エンドポイント (base_url) にトラフィックを送信する

Lambda 関数のログの確認

ワークショップの質問

consumer-lambda ログからのトレース ID のコピー

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

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

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

クリーンアップ

send_message の停止

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

結論

`auto` ディレクトリ

`main.tf` ファイル

`producer.mjs` ファイル

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

`producer-lambda` URL (`base_url`) にトラフィックを送信する

`send_message` の停止

`manual` ディレクトリ

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

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

`producer-lambda` エンドポイント (base_url) にトラフィックを送信する

`consumer-lambda` ログからのトレース ID のコピー

`send_message` の停止