このワークショップでは、AWS Lambda で実行される小規模なサーバーレスアプリケーションの分散トレースを構築し、AWS Kinesis を介してメッセージを produce および consume する方法を学びます。
まず、OpenTelemetry の自動計装がどのようにトレースをキャプチャし、選択した宛先にエクスポートするかを確認します。
次に、手動計装によってコンテキスト伝播を有効にする方法を見ていきます。
このワークショップのために、Splunk は AWS/EC2 上の Ubuntu Linux インスタンスを事前に構成しています。このインスタンスにアクセスするには、ワークショップインストラクターが提供する URL にアクセスしてください。
Observability ワークショップは、多くの場合、Splunk が提供する事前設定済みの Ubuntu EC2 インスタンス上で実施されます。
ワークショップのインストラクターから、割り当てられたワークショップインスタンスの認証情報が提供されます。
インスタンスには以下の環境変数が既に設定されているはずです：
また、Multipass を使用してローカルの Observability ワークショップインスタンスをデプロイすることもできます。
AWS Command Line Interface、またはawscliは、AWS リソースと対話するために使用される API です。このワークショップでは、特定のスクリプトがデプロイするリソースと対話するために使用されます。
Splunk が提供するワークショップインスタンスには、既に awscli がインストールされているはずです。
インスタンスに aws コマンドがインストールされているか、次のコマンドで確認します：
which awsインスタンスに aws コマンドがインストールされていない場合は、次のコマンドを実行します：
sudo apt install awscliTerraform は、リソースを構成ファイルで定義することで、デプロイ、管理、破棄するための Infrastructure as Code（IaC）プラットフォームです。Terraform は HCL を使用してこれらのリソースを定義し、さまざまなプラットフォームやテクノロジのための複数のプロバイダーをサポートしています。
このワークショップでは、コマンドラインで Terraform を使用して、以下のリソースをデプロイします：
Splunk が提供するワークショップインスタンスには、既に terraform がインストールされているはずです。
インスタンスに terraform コマンドがインストールされているか確認します：
which 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 は、今日使用する例の Lambda ベースのアプリケーションの自動計装と手動計装の両方を完了するための、すべての設定ファイルとスクリプトを含むリポジトリです。
ホームディレクトリにワークショップディレクトリがあることを確認します：
cd && lso11y-lambda-workshop ディレクトリがホームディレクトリにない場合は、次のコマンドでクローンします：
git clone https://github.com/gkono-splunk/o11y-lambda-workshop.gitAWS の 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 configureTerraform では、機密情報や動的データを.tf 設定ファイルにハードコーディングさせない、またはそれらの値をリソース定義全体で再利用できるようにするため、変数の受け渡しをサポートしています。
このワークショップでは、OpenTelemetry Lambda layer の適切な値で Lambda 関数をデプロイするため、Splunk Observability Cloud の取り込み値のため、そして環境とリソースを独自で即座に認識できるようにするための変数を Terraform で必要とします。
Terraform 変数(variable)は以下の方法で定義されます：
このワークショップでは、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のみを変更してください。ファイルを保存してエディタを終了します。
最後に、編集した 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.tfmain.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_layerOpenTelemetry Lambda layer は、Lambda 関数の呼び出し時に計測データを収集、処理、およびエクスポートするために必要なライブラリと依存関係を含むパッケージです。
すべての OpenTelemetry サポート言語のライブラリと依存関係を持つ一般的な OTel Lambda layer がありますが、関数をさらに軽量化するための言語固有の Lambda layer も存在します。
producer.mjs ファイル次に、producer-lambda関数のコードを見てみましょう：
以下のコマンドを実行してproducer.mjsファイルの内容を表示します：
cat ~/o11y-lambda-workshop/auto/handler/producer.mjsautoディレクトリの内容に慣れたところで、ワークショップ用のリソースをデプロイし、Lambda 関数からトレースデータを生成していきます。
autoディレクトリで Terraform を初期化するmain.tfファイルで定義されたリソースをデプロイするには、まず Terraform がそのファイルと同じフォルダで初期化されていることを確認する必要があります。
auto ディレクトリにいることを確認します:
pwdauto ディレクトリにいない場合は、次のコマンドを実行します：
cd ~/o11y-lambda-workshop/auto次のコマンドを実行して、このディレクトリで Terraform を初期化します
terraform init.terraform.lock.hcl ファイル：リソースを提供するために使用するプロバイダーを記録します.terraform ディレクトリ：プロバイダーの構成を保存しますapply サブコマンドを使用して terraform を実行すると、デプロイされたリソースの状態を追跡するために terraform.tfstate ファイルが作成されます。auto ディレクトリの main.tf ファイル内で定義されたとおりに、リソースの作成、状態、破棄を管理できますこのディレクトリで Terraform を初期化したら、リソースのデプロイに進むことができます。
まず、terraform plan コマンドを実行して、Terraform が問題なくリソースを作成できることを確認します。
terraform plan次に、terraform apply コマンドを実行して、main.tf ファイルから Lambda 関数とその他のサポートリソースをデプロイします：
terraform applyEnter 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"producer-lambda URL (base_url) にトラフィックを送信するデプロイした Lambda 関数からトレースを取得し始めるには、トラフィックを生成する必要があります。producer-lambda関数のエンドポイントにメッセージを送信し、それを Kinesis ストリームにレコードとして配置し、その後consumer-lambda関数によってストリームから取得されるようにします。
auto ディレクトリにいることを確認します：
pwdauto ディレクトリにいない場合は、次のコマンドを実行します
cd ~/o11y-lambda-workshop/autosend_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.out79829）、および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 関数のログを確認しましょう。
producer-lambda ログを表示するには、producer.logs ファイルを確認します：
cat producer.logsconsumer-lambda ログを表示するには、consumer.logs ファイルを確認します：
cat consumer.logsログを注意深く調べてください。
splunk-extension-wrapperのある行に注目してくださいhead -n 50 producer.logsまたはhead -n 50 consumer.logsの実行を検討してください。Lambda 関数は相当量のトレースデータを生成しているはずで、それを確認する必要があります。Lambda 関数のリソース定義で構成された環境変数と OpenTelemetry Lambda layer の組み合わせにより、Splunk APM で関数とトレースを表示する準備が整いました。
まず、Splunk APM が受信しているトレースデータからEnvironmentを認識していることを確認しましょう。これはmain.tfの Lambda 関数定義で設定したOTEL_RESOURCE_ATTRIBUTES変数の一部として設定したdeployment.nameです。これは先ほど実行したterraform applyコマンドの出力の 1 つでもありました。
Splunk Observability Cloud で：
左側のメインメニューからAPMボタンをクリックします。これにより Splunk APM 概要に移動します。
Environment:ドロップダウンからあなたの APM 環境を選択します。
PREFIX-lambda-shop形式になっているはずです。PREFIXは前提条件セクションで設定した環境変数から取得されますトレースが Splunk APM に表示されるまで数分かかる場合があります。環境のリストにあなたの環境名が表示されるまで、ブラウザの更新ボタンを押してみてください
Environment ドロップダウンから環境名を選択したら、Lambda 関数のサービスマップを確認できます。
Service Mapボタンをクリックします。これによりサービスマップビューに移動します。
producer-lambda関数とそのレコードを配置するために Kinesis ストリームに対して行っている呼び出しが表示されるはずです。
あなたのconsumer-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]を押してプロセスを終了できます。Terraform は個々のリソースの状態をデプロイメントとして管理するのに優れています。定義に変更があっても、デプロイされたリソースを更新することもできます。しかし、一からやり直すために、リソースを破棄し、このワークショップの手動計装部分の一部として再デプロイします。
以下の手順に従ってリソースを破棄してください：
autoディレクトリにいることを確認します：
pwdautoディレクトリにいない場合は、以下のコマンドを実行します：
cd ~/o11y-lambda-workshop/auto先ほどデプロイした Lambda 関数とその他の AWS リソースを破棄します：
terraform destroyEnter a value:プロンプトが表示されたらyesと応答しますこのプロセスにより、私たちの活動の結果として作成されたファイルとディレクトリは残ります。それらについては心配する必要はありません。
ワークショップの第 2 部では、OpenTelemetry による手動計装が計測データ収集を強化する方法を実演することに焦点を当てます。より具体的には、今回のケースでは、producer-lambda関数からconsumer-lambda関数にトレースコンテキストデータを伝播させることができるようになります。これにより、現在は自動コンテキスト伝播をサポートしていない Kinesis ストリームを介しても、2 つの関数間の関係を見ることができるようになります。
再度、作業ディレクトリとそのファイルの一部を確認することから始めます。今回は o11y-lambda-workshop/manual ディレクトリです。ここにはワークショップの手動計装部分のすべてのコンテンツがあります。
manual ディレクトリ以下のコマンドを実行して o11y-lambda-workshop/manual ディレクトリに移動します：
cd ~/o11y-lambda-workshop/manualls コマンドでこのディレクトリの内容を確認します：
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.mjsimport { context, propagation, trace } from "@opentelemetry/api";最後に、consumer.mjs ファイルを比較します：
diff ~/o11y-lambda-workshop/auto/handler/consumer.mjs ~/o11y-lambda-workshop/manual/handler/consumer.mjsここにもいくつかの注目すべき違いがあります。より詳しく見てみましょう：
cat handler/consumer.mjsname と superpower に基づいた新しいスパン属性を追加します以下のコードはプロデューサー関数内で次のステップを実行します：
...
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 関数を再度デプロイして、producer-lambdaエンドポイントに対するトラフィックを生成していきましょう。
manual ディレクトリで Terraform を初期化する新しいディレクトリにいるので、ここでもう一度 Terraform を初期化する必要があります。
manual ディレクトリにいることを確認します：
pwdmanual ディレクトリにいない場合は、次のコマンドを実行します：
cd ~/o11y-lambda-workshop/manual次のコマンドを実行して、このディレクトリで Terraform を初期化します：
terraform initそれでは、これらのリソースを再度デプロイしましょう！
問題がないことを確認するために、terraform plan コマンドを実行します。
terraform plan続いて、terraform apply コマンドを使用して main.tf ファイルから Lambda 関数とその他のサポートリソースをデプロイします：
terraform applyEnter 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 ディレクトリにいることを確認します：
pwdmanual ディレクトリにいない場合は、次のコマンドを実行します：
cd ~/o11y-lambda-workshop/manualsend_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"}これが発生した場合は、ワークショップ進行役の一人に支援を求めてください。
ログがどのようになっているか見てみましょう。
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 番目の文字グループです
ログの外部でコンテキスト伝播の結果を確認するために、もう一度Splunk APM UIを参照します。
もう一度 APM で環境のサービスマップを確認してみましょう。
Splunk Observability Cloud で：
メインメニューのAPMボタンをクリックします。
Environment:ドロップダウンからあなたの APM 環境を選択します。
APM 概要ページの右側にあるService Mapボタンをクリックします。これによりサービスマップビューに移動します。
違いに気づきましたか？
producer-lambdaとconsumer-lambda関数が見えるはずです！
次に、環境に関連するトレースをもう一度確認します。
View Trace ID検索ボックスに貼り付け、Goをクリックします
トレース ID は、私たちが伝播したトレースコンテキストの一部でした。
最も一般的な 2 つの伝播規格について読むことができます：
私たちはどちらを使用していますか？
W3C標準を使用していますボーナス質問：W3C ヘッダーと B3 ヘッダーを混在させるとどうなりますか？
consumer-lambdaスパンをクリックしてください。
あなたのメッセージからの属性を見つけることができますか？
いよいよワークショップの最後に来ました。後片付けをしましょう！
send_messageの停止send_message.pyスクリプトがまだ実行中の場合は、次のコマンドで停止します：
fg[CONTROL-C]を押してプロセスを終了できます。Terraform は個々のリソースの状態をデプロイメントとして管理するのに優れています。定義に変更があっても、デプロイされたリソースを更新することもできます。しかし、一からやり直すために、リソースを破棄し、このワークショップの手動計装部分の一部として再デプロイします。
以下の手順に従ってリソースを破棄してください：
manualディレクトリにいることを確認します：
pwdmanualディレクトリにいない場合は、次のコマンドを実行します：
cd ~/o11y-lambda-workshop/manual以前にデプロイした Lambda 関数とその他の AWS リソースを破棄します：
terraform destroyEnter a value:プロンプトが表示されたらyesと応答しますLambda Tracing ワークショップを終えたことをおめでとうございます！自動計装を手動のステップで補完して、producer-lambda関数のコンテキストを Kinesis ストリーム内のレコードを介してconsumer-lambda関数に送信する方法を見てきました。これにより、期待される分散トレースを構築し、Splunk APM で両方の関数間の関係をコンテキスト化することができました。
これで、2 つの異なる関数を手動でリンクしてトレースを構築することができます。これは、自動計装や第三者のシステムがコンテキスト伝播を標準でサポートしていない場合や、より関連性の高いトレース分析のためにカスタム属性をトレースに追加したい場合に役立ちます。