自動計装

ワークショップの最初の部分では、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の実行を検討してください。