自動計装
ワークショップの最初の部分では、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
メッセージ
- 1 行目のプロセス ID(この例では
nohup
コマンドはスクリプトがバックグラウンドに送られた時に切断されないようにします。また、コマンドからの curl 出力を、現在いるフォルダと同じフォルダにある nohup.out ファイルにキャプチャします。&
はシェルプロセスにこのプロセスをバックグラウンドで実行するよう指示し、シェルが他のコマンドを実行できるようにします。
- ここで重要な情報は 2 つあります:
次に、
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-extension-wrapperが読み込まれているのを見るために