Splunk APM、Lambda Functions とトレース

まず、Splunk APM が受信しているトレースデータから Environment を認識していることを確認しましょう。これは main.tf の Lambda 関数定義で OTEL_RESOURCE_ATTRIBUTES 変数の一部として設定した deployment.name です。また、先ほど実行した terraform apply コマンドの出力の一つでもあります。

Splunk Observability Cloud で以下を行います

• 左側のメインメニューから APM ボタンをクリックします。Splunk APM の概要ページに移動します。
• Environment: ドロップダウンから APM 環境を選択します。
  • APM 環境は PREFIX-lambda-shop の形式になっています。PREFIX は前提条件セクションで設定した環境変数から取得されます。

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

• APM 概要ページの右側にある Service Map ボタンをクリックします。Service Map ビューに移動します。

producer-lambda 関数と、レコードを配置するために Kinesis Stream に対して行っている呼び出しを確認できるはずです。

Lambda 関数からのトレースを探索する #

• Traces ボタンをクリックして Trace Analyzer を表示します。

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

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

producer-lambda 関数が Kinesis Stream にレコードを配置していることがわかります。しかし、consumer-lambda 関数のアクションが見つかりません！

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

まだ、ですが…

このワークショップの次のセクションで、この問題を回避する方法を見ていきましょう。その前に、クリーンアップを行いましょう！

メッセージを停止する #

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

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

fg

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

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

Terraform はリソースを個別に、またデプロイメントとして状態管理するのに優れています。定義の変更に応じてデプロイ済みリソースを更新することもできます。しかし、新たに始めるために、このワークショップの手動計装部分の一部としてリソースを破棄して再デプロイします。

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

• auto ディレクトリに移動します

cd ~/workshop/lambda/auto

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

terraform destroy

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

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