まず、メトリクス、トレース、およびログの収集を開始するために、Datadog Serverless Monitoring をインストールします。インストールが完了したら、監視ニーズに合わせてインストールを構成する方法については、以下のトピックを参照してください。

• タグを使ったテレメトリー接続
• リクエストとレスポンスのペイロードを収集する
• 非 Lambda リソースからトレースを収集する
• Datadog SDK を構成する
• APM スパンを取り込む際のサンプリングレートの選択
• トレースから機密情報をフィルタリングまたはスクラブする
• トレース収集の有効化/無効化
• ログとトレースの接続
• ソースコードにエラーをリンクする
• カスタムメトリクスの送信
• プロファイリングデータの収集
• PrivateLink またはプロキシ経由でテレメトリーを送信する
• 複数の Datadog 組織にテレメトリーを送信する
• FIPS コンプライアンスを有効にする
• AWS リソース上でトレースコンテキストを伝播させる
• X-Ray と Datadog のトレースをマージする
• AWS Lambda のコード署名を有効にする
• Datadog Lambda Extension に移行する
• Datadog Lambda Extension を使用した x86 から arm64 への移行
• ローカルテスト用の Datadog Lambda Extension の構成
• OpenTelemetry API を使用した AWS Lambda のインスツルメンテーション
• Datadog Lambda Extension v67+ を使用する
• DynamoDB PutItem の自動リンクを構成する
• AWS サービスを正しく可視化およびモデル化する
• Observability Pipelines にログを送信する
• API キーのシークレットを定期的に再読み込みする
• トラブルシューティング
• 参考資料

脅威の検出を有効にして攻撃の試みを観測する

サーバーレスアプリケーションを標的にしている攻撃者についてアラートを受け取り、素早く対応できます。

まずは、関数でトレーシングが有効になっていることを確認します。

脅威の監視を有効にするには、デプロイに次の環境変数を追加します。

environment:
  DD_SERVERLESS_APPSEC_ENABLED: true
  AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper

関数を再デプロイし、呼び出します。数分後、AAP ビューに表示されます。

App and API Protection の脅威検出を実際に確認するには、既知の攻撃パターンをアプリケーションに送信します。例えば、値 acunetix-product の HTTP ヘッダーを送信して、セキュリティスキャナ攻撃の試行をトリガーします。

curl -H 'My-AAP-Test-Header: acunetix-product' https://<YOUR_FUNCTION_URL>/<EXISTING_ROUTE>

アプリケーションを有効化し、攻撃パターンを送信してから数分後、脅威情報が Application Signals Explorer に表示されます。

タグを使ったテレメトリー接続

予約済みの (env, service、version) およびカスタムタグを使用して Datadog テレメトリを接続します。これらのタグを使用して、メトリクス、トレース、およびログ間をシームレスにナビゲートできます。使用しているインストール方法に応じて、以下の追加パラメーターを設定します。

datadog-ci lambda instrument \
    --env dev \
    --service web \
    --version v1.2.3 \
    --extra-tags "team:avengers,project:marvel"
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    env: dev
    service: web
    version: v1.2.3
    tags: "team:avengers,project:marvel"

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      env: dev
      service: web
      version: v1.2.3
      tags: "team:avengers,project:marvel"

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    env: "dev",
    service: "web",
    version: "v1.2.3",
    tags: "team:avengers,project:marvel"
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

また、Datadog は、Lambda 関数に定義された既存の AWS リソースタグで、数分遅れで収集したテレメトリーをリッチ化することができます。

• Datadog Lambda extension を使用して Lambda 関数からテレメトリーを収集している場合、Datadog AWS インテグレーションを有効にします。この機能は、テレメトリをカスタムタグで強化することを目的としています。Datadog の予約タグ (env、service、および version) は、対応する環境変数 (DD_ENV、DD_SERVICE、および DD_VERSION) を通じて設定する必要があります。予約タグは、サーバーレス開発ツール向けの Datadog インテグレーションが提供するパラメーターでも設定できます。この機能は、コンテナイメージでデプロイされた Lambda 関数には対応していません。

• Datadog Forwarder Lambda function を使って Lambda 関数からテレメトリーを収集している場合、Datadog Forwarder の CloudFormation スタックで、DdFetchLambdaTags オプションを true に設定します。このオプションはバージョン 3.19.0 以降、デフォルトで true になります。

リクエストとレスポンスのペイロードを収集する

Datadog は AWS Lambda 関数の JSON リクエストとレスポンスのペイロードを収集し可視化することで、サーバーレスアプリケーションへの深い洞察と Lambda 関数障害のトラブルシューティングを支援することが可能です。

この機能はデフォルトで無効です。使用しているインストール方法に応じて、以下の手順に従います。

datadog-ci lambda instrument \
    --capture-lambda-payload true
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    captureLambdaPayload: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      captureLambdaPayload: true

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    captureLambdaPayload: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

リクエストやレスポンスの JSON オブジェクト内の機密データが Datadog に送信されないようにするには、特定のパラメーターをスクラブすることが可能です。

これを行うには、Lambda 関数コードと同じフォルダーに新しいファイル datadog.yaml を追加します。Lambda ペイロード内のフィールドの難読化は、datadog.yaml の apm_config 設定内の replace_tags ブロックを通じて利用可能です。

apm_config:
  replace_tags:
    # Replace all the occurrences of "foobar" in any tag with "REDACTED":
    - name: "*"
      pattern: "foobar"
      repl: "REDACTED"
    # Replace "auth" from request headers with an empty string
    - name: "function.request.headers.auth"
      pattern: "(?s).*"
      repl: ""
    # Replace "apiToken" from response payload with "****"
    - name: "function.response.apiToken"
      pattern: "(?s).*"
      repl: "****"

別の方法として、Lambda 関数に環境変数 DD_APM_REPLACE_TAGSを設定し、特定のフィールドを難読化することもできます。

DD_APM_REPLACE_TAGS=[
      {
        "name": "*",
        "pattern": "foobar",
        "repl": "REDACTED"
      },
      {
        "name": "function.request.headers.auth",
        "pattern": "(?s).*",
        "repl": ""
      },
      {
        "name": "function.response.apiToken",
        "pattern": "(?s).*"
        "repl": "****"
      }
]

AWS サービスからのペイロードを収集するには、AWS サービスからリクエストおよびレスポンスをキャプチャを参照してください。

非 Lambda リソースからトレースを収集する

Datadog は、Lambda 関数をトリガーする AWS マネージドリソースからの Lambda イベントに基づいて、APM スパンを推定できます。これにより、AWS マネージドリソース間の関係を可視化し、サーバーレスアプリケーションのパフォーマンス問題の特定に役立ちます。追加の製品詳細を参照してください。

現在、以下のリソースがサポートされています。

• API ゲートウェイ (REST API、HTTP API、WebSocket)
• 関数 URL
• SQS
• SNS (SQS 経由で配信される SNS メッセージもサポートされています)
• Kinesis Streams (データが JSON 文字列または base64 エンコードされた JSON 文字列の場合)
• EventBridge (カスタムイベント。Details は JSON 文字列)
• S3
• DynamoDB

この機能を無効にするには、DD_TRACE_MANAGED_SERVICES を false に設定します。

DD_SERVICE_MAPPING

DD_SERVICE_MAPPING は、アップストリームの非 Lambda サービス名をリネームする環境変数です。old-service:new-service のペアで動作します。

構文

DD_SERVICE_MAPPING=key1:value1,key2:value2…

この変数を操作する方法は 2 つあります。

タイプのすべてのサービス名を変更

AWS Lambda インテグレーションに関連するすべてのアップストリームサービスの名前を変更するには、これらの識別子を使用します。

特定のサービス名を変更

より詳細なアプローチは、これらのサービス固有の識別子を使用します。

例と説明

ダウンストリームサービスの名前の変更については、トレーサーの構成ドキュメントの DD_SERVICE_MAPPING を参照してください。

Datadog SDK を構成する

Datadog APM クライアントによって自動的にインスツルメントされるライブラリやフレームワークについては、APM の互換性要件を参照してください。カスタムアプリケーションをインスツルメントするには、Datadog の APM ガイドのカスタムインスツルメンテーションを参照してください。

APM スパンを取り込む際のサンプリングレートの選択

サーバーレス関数の APM トレース付き呼び出しサンプリングレートを管理するには、関数上で DD_TRACE_SAMPLING_RULES 環境変数を 0.000 (Lambda 関数呼び出しのトレースなし) と 1.000 (Lambda 関数呼び出しのすべてトレース) の間の値に設定します。

注:

• DD_TRACE_SAMPLE_RATE の使用は非推奨です。代わりに DD_TRACE_SAMPLING_RULES を使用してください。たとえば、すでに DD_TRACE_SAMPLE_RATE を 0.1 に設定している場合は、代わりに DD_TRACE_SAMPLING_RULES を [{"sample_rate":0.1}] に設定してください。
• trace.<OPERATION_NAME>.hitsなどの全体的トラフィックメトリクスは、Lambda 内のサンプリングされた呼び出しのみに基づいて計算されます。

トレースデータは非常に反復性が高いため、高スループットのサービスでは、通常、すべてのリクエストを収集する必要はありません。十分重要な問題は、常に複数のトレースで症状を示すはずです。取り込みのコントロールは、予算の範囲内で、問題のトラブルシューティングに必要な可視性を確保するのに役立ちます。

取り込みのデフォルトのサンプリングメカニズムはヘッドベースサンプリングと呼ばれます。トレースを保持するか削除するかの判断は、トレースの最初の段階、つまりルートスパンの開始時に行われます。この決定はその後、リクエストコンテキストの一部として、たとえば HTTP リクエストヘッダーとして他のサービスに伝播されます。判断はトレースの開始時に行われ、その後トレース全体に伝達されるため、効果を反映させるにはルートサービスでサンプリングレートを構成設定する必要があります。

Datadog にスパンが取り込まれた後、Datadog Intelligent Retention Filter は、アプリケーションの健全性を監視するのに役立つトレースの一部をインデックスします。カスタム保持フィルターを定義して、組織の目標をサポートするために長期間保持したいトレースデータをインデックス化することもできます。

Datadog Trace Pipeline の詳細についてはこちらをご覧ください。

トレースから機密情報をフィルタリングまたはスクラブする

Datadog に送信する前にトレースをフィルタリングするには、APM で不要なリソースを無視するを参照してください。

データセキュリティのためにトレース属性をスクラブするには、データセキュリティのための Datadog Agent またはトレーサーの構成を参照してください。

トレース収集の有効化/無効化

Datadog Lambda Extension によるトレース収集は、デフォルトで有効になっています。

Lambda 関数のトレース収集を開始したい場合は、以下の構成を適用します。

datadog-ci lambda instrument \
    --tracing true
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    enableDDTracing: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      enableDDTracing: true

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    enableDatadogTracing: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

トレース収集の無効化

Lambda 関数のトレース収集を停止したい場合は、以下の構成を適用します。

datadog-ci lambda instrument \
    --tracing false
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    enableDDTracing: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      enableDDTracing: false

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    enableDatadogTracing: false
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

ログとトレースの接続

Lambda extension を使用してトレースとログを収集している場合、Datadog は AWS Lambda リクエスト ID を aws.lambda スパンの request_id タグに自動的に追加します。さらに、同じリクエストの Lambda ログは lambda.request_id 属性の下に追加されます。Datadog のトレースとログのビューは、AWS Lambda リクエスト ID を使用して接続されます。

Forwarder Lambda function を使用してトレースとログを収集している場合、dd.trace_id はログに自動的に挿入されます (環境変数 DD_LOGS_INJECTION でデフォルトで有効)。Datadog のトレースとログのビューは、Datadog トレース ID を使用して接続されます。この機能は、一般的なランタイムおよびロガーを使用しているほとんどのアプリケーションでサポートされています (ランタイム別サポートを参照)。

サポートされていないランタイムまたはカスタムロガーを使用している場合は、以下の手順に従ってください。

• JSON でログを記録する場合、dd-trace を使用して Datadog のトレース ID を取得し、それをログの dd.trace_id フィールドに追加する必要があります。

  {
    "message": "This is a log",
    "dd": {
      "trace_id": "4887065908816661012"
    }
    // ... the rest of your log
  }
  

• 平文でログを記録する場合、以下を行う必要があります。
  1. dd-trace を使用して Datadog のトレース ID を取得し、ログに追加します。
  2. デフォルトの Lambda ログパイプラインを複製します (読み取り専用)。
  3. 複製したパイプラインを有効にし、デフォルトのパイプラインを無効にします。
  4. 複製したパイプラインの Grok parser ルールを更新して、Datadog トレース ID を dd.trace_id 属性に解析します。例えば、my_rule \[%{word:level}\]\s+dd.trace_id=%{word:dd.trace_id}.* のようなログに対してルール [INFO] dd.trace_id=4887065908816661012 My log message を使用します。

ソースコードにエラーをリンクする

Datadog ソースコードインテグレーションを使用すると、テレメトリー (スタックトレースなど) を Git リポジトリ内の Lambda 関数のソースコードにリンクできます。

サーバーレスアプリケーションでソースコードインテグレーションを設定する手順については、ビルドアーティファクトに Git 情報を埋め込むセクションを参照してください。

プロファイリングデータの収集

Datadog の Continuous Profiler は、Python tracer バージョン 4.62.0 および layer バージョン 62 以前でプレビューとして利用可能です。このオプション機能は、DD_PROFILING_ENABLED 環境変数を true に設定することで有効になります。

Continuous Profiler は、実行中のすべての Python コードの CPU およびヒープのスナップショットを定期的に取得するスレッドを生成して動作します。これにはプロファイラー自体も含まれる可能性があります。プロファイラーが自分自身を無視するようにしたい場合は、DD_PROFILING_IGNORE_PROFILER を true に設定します。

PrivateLink またはプロキシ経由でテレメトリーを送信する

Datadog Lambda Extension は、Datadog にデータを送信するためにインターネットへのアクセスが必要です。Lambda 関数がインターネットにアクセスできない VPC にデプロイされている場合、AWS PrivateLink 経由でデータを送信して datadoghq.com Datadog サイトに送信するか、その他のサイトにはプロキシ経由でデータを送信できます。

Datadog Forwarder を使用している場合は、こちらの手順に従ってください。

複数の Datadog 組織にテレメトリーを送信する

複数の組織にデータを送信したい場合は、平文の API キー、AWS Secrets Manager、または AWS KMS を使用してデュアルシッピングを有効にすることができます。

# Enable dual shipping for metrics
DD_ADDITIONAL_ENDPOINTS={"https://app.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://app.datadoghq.eu": ["<your_api_key_4>"]}
# Enable dual shipping for APM (traces)
DD_APM_ADDITIONAL_ENDPOINTS={"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
# Enable dual shipping for APM (profiling)
DD_APM_PROFILING_ADDITIONAL_ENDPOINTS={"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
# Enable dual shipping for logs
DD_LOGS_CONFIG_FORCE_USE_HTTP=true
DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS=[{"api_key": "<your_api_key_2>", "Host": "agent-http-intake.logs.datadoghq.com", "Port": 443, "is_reliable": true}]

より高度な使用方法については、デュアルシッピングガイドを参照してください。

FIPS コンプライアンスを有効にする

AWS Lambda 関数の FIPS コンプライアンスの全体像については、専用の AWS Lambda FIPS コンプライアンスページを参照してください。

AWS Lambda 関数の FIPS コンプライアンスを有効にするには、次のステップに従います。

1. 適切な ARN を参照して FIPS コンプライアンス対応の拡張レイヤーを使用します。

arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-FIPS:99
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-ARM-FIPS:99

arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension-FIPS:99
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension-ARM-FIPS:99

2. Python、JavaScript、または Go を使用する Lambda 関数の場合、環境変数 DD_LAMBDA_FIPS_MODE を true に設定します。この環境変数:

   • FIPS モードでは、Lambda メトリックヘルパー関数はメトリック送信のために FIPS コンプライアンス対応の拡張機能を必要とします。
   • API キーの検索に AWS FIPS エンドポイントを使用します。
   • GovCloud 環境ではデフォルトで有効になっています。

3. Ruby、.NET、または Java を使用する Lambda 関数の場合、追加の環境変数設定は必要ありません。

4. エンドツーエンドで FIPS コンプライアンスを完全に達成するには、Lambda 関数を Datadog for Government サイトを使用するように設定します。

   • DD_SITE をddog-gov.com (US1-FED) または us2.ddog-gov.com (US2-FED) に設定します。 注: FIPS コンプライアンス対応の Lambda コンポーネントは任意の Datadog サイトで動作しますが、FIPS コンプライアンス対応のインテークエンドポイントを持つのは Datadog for Government サイトのみです。

AWS リソース上でトレースコンテキストを伝播させる

Datadog は、アウトゴーイングの AWS SDK リクエストにトレースコンテキストを自動的に注入し、Lambda イベントからトレースコンテキストを抽出します。これにより、Datadog は分散サービス全体でリクエストやトランザクションをトレースできるようになります。サーバーレストレースの伝搬を参照してください。

X-Ray と Datadog のトレースをマージする

AWS X-Ray は、AppSync や Step Functions などの特定の AWS 管理サービスを通じたトレースをサポートしていますが、Datadog APM はネイティブではサポートしていません。Datadog X-Ray integration を有効にし、X-Ray トレースを Datadog ネイティブトレースとマージできます。追加の詳細を参照してください。

AWS Lambda のコード署名を有効にする

AWS Lambda のコード署名により、信頼できるコードのみを Lambda 関数から AWS へデプロイすることができます。関数でコード署名を有効にすると、デプロイメントのすべてのコードが信頼できるソースにより署名されていることが AWS で検証されます。このソースは、コード署名コンフィギュレーションで定義します。

Lambda 関数がコード署名を使用するように構成されている場合、Datadog が公開する Lambda レイヤーを使用して Lambda 関数をデプロイする前に、関数のコード署名構成に Datadog の Signing Profile ARN を追加する必要があります。

Datadog の Signing Profile ARN:

arn:aws:signer:us-east-1:464622532012:/signing-profiles/DatadogLambdaSigningProfile/9vMI9ZAGLc

Datadog Lambda Extension に移行する

Datadog は、Forwarder Lambda function または Lambda extension を使用して、Lambda 関数から監視データを収集できます。Datadog は、新規インストールには Lambda extension を推奨しています。不明な場合は、Datadog Lambda extension への移行を判断するを参照してください。

移行するには、Datadog Lambda Extension を使用したインストール手順と Datadog Forwarder を使用した手順を比較してみてください。ご参考までに、主な相違点を以下にまとめます。

注: Datadog では、まず開発用とステージング用のアプリケーションを移行し、本番用のアプリケーションを 1 つずつ移行していくことを推奨しています。

Datadog Lambda extension は、デフォルトでログ収集を有効にします。Forwarder から extension に移行する場合は、ログのサブスクリプションを削除してください。そうしないと、ログが重複して表示される可能性があります。

1. @datadog/datadog-ci を最新バージョンにアップグレードします。
2. 引数 --layer-version を更新し、ランタイムの最新バージョンに設定します。
3. --extension-version 引数を最新の拡張機能バージョンに設定します。最新の拡張機能バージョンは 99.
4. Set the required environment variables DATADOG_SITE and DATADOG_API_KEY_SECRET_ARN.
5. Remove the --forwarder 引数です。
6. Lambda のロググループに Forwarder を自動的にサブスクライブするように Datadog AWS インテグレーションを構成した場合、その地域の Lambda 関数を_すべて_移行した後にそれを無効にしてください。

1. serverless-plugin-datadog を最新バージョンにアップグレードしてください。これにより、addExtension を false に設定しない限り、Datadog Lambda Extension がデフォルトでインストールされます。
2. 必要なパラメーター site と apiKeySecretArn を設定します。
3. 以前に Lambda リソースタグとして設定した場合は、env、service、および version パラメーターを設定します。プラグインは、拡張機能を使用する際に、DD_ENV などの Datadog の予約環境変数を通じてそれらを自動的に設定します。
4. Forwarder を非 Lambda リソースからのログ収集のために保持したい場合、かつ subscribeToApiGatewayLogs、subscribeToHttpApiLogs、または subscribeToWebsocketLogs が true に設定されている場合を除き、forwarderArn パラメーターを削除してください。
5. Lambda のロググループに Forwarder を自動的にサブスクライブするように Datadog AWS インテグレーションを構成した場合、その地域の Lambda 関数を_すべて_移行した後にそれを無効にしてください。

1. datadog-serverless-macro CloudFormation スタックを更新して、最新バージョンを取得します。
2. extensionLayerVersion パラメーターを最新の拡張バージョンに設定します。最新の拡張機能バージョンは 99.
3. Set the required parameters site and apiKeySecretArn.
4. Remove the forwarderArn パラメーター。
5. Lambda のロググループに Forwarder を自動的にサブスクライブするように Datadog AWS インテグレーションを構成した場合、その地域の Lambda 関数を_すべて_移行した後にそれを無効にしてください。

1. datadog-cdk-constructs または datadog-cdk-constructs-v2 を最新バージョンにアップグレードします。
2. extensionLayerVersion パラメーターを最新の拡張バージョンに設定します。最新の拡張機能バージョンは 99.
3. Set the required parameters site and apiKeySecretArn.
4. Set the env, service, and version parameters if you previously set them as Lambda resource tags. The construct will automatically set them through the Datadog reserved environment variables instead, such as DD_ENV, when using the extension.
5. Remove the forwarderArn パラメーター。
6. Lambda のロググループに Forwarder を自動的にサブスクライブするように Datadog AWS インテグレーションを構成した場合、その地域の Lambda 関数を_すべて_移行した後にそれを無効にしてください。

1. ランタイム用の Datadog Lambda ライブラリレイヤーを最新バージョンにアップグレードします。
2. 最新バージョンの Datadog Lambda Extension をインストールします。
3. 必要な環境変数 DD_SITE と DD_API_KEY_SECRET_ARN を設定します。
4. 以前に Lambda リソースタグとして設定した場合は、DD_ENV、DD_SERVICE、および DD_VERSION 環境変数を設定します。
5. Lambda 関数のロググループから Datadog Forwarder にログをストリーミングするサブスクリプションフィルターを削除します。
6. Lambda のロググループに Forwarder を自動的にサブスクライブするように Datadog AWS インテグレーションを構成した場合、その地域の Lambda 関数を_すべて_移行した後にそれを無効にしてください。

Datadog Lambda Extension を使用した x86 から arm64 への移行

Datadog Extension は、x86 と arm64 の両方のバリアントで利用可能なコンパイル済みバイナリです。CDK、Serverless Framework、SAM などのデプロイメントツールを使用して x86 Lambda 関数を arm64 (または arm64 から x86) に移行する場合、サービスインテグレーション (API Gateway、SNS、Kinesis など) が Lambda 関数のバージョンまたはエイリアスを使用するように構成されていることを確認してください。そうしないと、デプロイメント中に関数が約 10 秒間利用できなくなる可能性があります。

これは、x86 から arm64 への Lambda 関数の移行が updateFunction と updateFunctionConfiguration の 2 つの並行 API 呼び出しで構成されるために発生します。これらの呼び出しの間、Lambda updateFunction 呼び出しが完了し、コードが新しいアーキテクチャを使用するように更新される短いウィンドウがありますが、updateFunctionConfiguration 呼び出しはまだ完了していないため、古いアーキテクチャが拡張機能に対してまだ構成されています。

Layer のバージョンを利用できない場合、Datadog では、アーキテクチャの移行プロセス中に Datadog Forwarder の構成を行うことを推奨しています。

ローカルテスト用の Datadog Lambda Extension の構成

すべての Lambda エミュレーターが AWS Lambda テレメトリー API をサポートしているわけではありません。Datadog Lambda Extension がインストールされた状態で、Lambda 関数のコンテナイメージをローカルでテストするには、ローカルテスト環境で DD_SERVERLESS_FLUSH_STRATEGY を periodically,1 に設定する必要があります。そうしないと、拡張機能は AWS Lambda テレメトリー API からの応答を待機し、呼び出しをブロックします。

OpenTelemetry API を使用した AWS Lambda のインスツルメンテーション

Datadog Lambda Extension のインストール時に含まれる Datadog SDK は、OpenTelemetry でインスツルメンテーションされたコードで生成されたスパンとトレースを受け入れ、テレメトリーを処理し、Datadog に送信します。

たとえば、コードがすでに OpenTelemetry API でインツルメンテーションされている場合、このアプローチを使用できます。また、OpenTelemetry API を使用してベンダー非依存のコードでインスツルメンテーションを行いながら、Datadog SDK の利点を得たい場合にもこのアプローチを使用できます。

OpenTelemetry API を使用して AWS Lambda をインスツルメンテーションするには、環境変数 DD_TRACE_OTEL_ENABLED を true に設定します。詳細については、OpenTelemetry API によるカスタムインスツルメンテーションを参照してください。

Datadog Lambda Extension v67+ を使用する

Datadog Extension のバージョン 67+ は、コールドスタート時間を大幅に短縮するように最適化されています。 最適化された拡張機能を使用するには、環境変数 DD_SERVERLESS_APPSEC_ENABLED を false に設定します。 環境変数 DD_SERVERLESS_APPSEC_ENABLED が true に設定されている場合、Datadog Extension は完全に互換性のある古いバージョンをデフォルトで使用します。また、環境変数 DD_EXTENSION_VERSION を compatibility に設定することで、拡張機能を古いバージョンに強制的に使用させることができます。Datadog は、フィードバックやバグを報告するために GitHub Issue を追加し、その問題に version/next タグを付けることを推奨しています。

DynamoDB PutItem の自動リンクを構成する

Python および Node.js ランタイムで利用可能です。 非同期リクエストのセグメントがトレースコンテキストを伝播できない場合、Datadog の Span Auto-linking 機能が自動的にリンクされたスパンを検出します。 DynamoDB Change Streams の PutItem 操作に対してスパン自動リンクを有効にするには、テーブルのプライマリキー名を設定します。

ddtrace.config.botocore['dynamodb_primary_key_names_for_tables'] = {
    'table_name': {'key1', 'key2'},
    'other_table': {'other_key'},
}

// Initialize the tracer with the configuration
const tracer = require('dd-trace').init({
  dynamoDb: {
    tablePrimaryKeys: {
      'table_name': ['key1', 'key2'],
      'other_table': ['other_key']
    }
  }
})

export DD_BOTOCORE_DYNAMODB_TABLE_PRIMARY_KEYS='{
    "table_name": ["key1", "key2"],
    "other_table": ["other_key"]
}'

これにより、DynamoDB PutItem 呼び出しがスパンポインタでインスツルメントされるようになります。多くの DynamoDB API 呼び出しでは、アイテムのプライマリキーフィールドが個別の値として含まれないため、SDK に別途指定する必要があります。上記の設定は、辞書 (dict) またはテーブル名を文字列 (str) としてキーにしたオブジェクトとして構成されています。各値は、関連するテーブルのプライマリキーフィールド名 (文字列) のセットです。セットは、テーブルのプライマリキーのスキーマに応じて、1 つまたは 2 つの要素を持つことができます。

リソース名による AWS サービスの可視化とモデリング

これらの Node.js、Python、および Java Lambda レイヤーのバージョンでは、AWS 管理サービスを正しく命名、モデリング、可視化するための変更がリリースされました。

サービス名は、AWS サービス名だけでなく、実際の AWS リソース名を反映しています。

• aws.lambda → [function_name]
• aws.dynamodb → [table_name]
• aws.sns → [topic_name]
• aws.sqs → [queue_name]
• aws.kinesis → [stream_name]
• aws.s3 → [bucket_name]
• aws.eventbridge → [event_name]

ダッシュボードやモニターが従来の命名規則に依存している場合は、古いサービス表現モデルを使用することを好むかもしれません。以前の動作を復元するには、環境変数を設定します。DD_TRACE_AWS_SERVICE_REPRESENTATION_ENABLED=false

更新されたサービスモデリング設定を推奨します。

Observability Pipelines にログを送信する

Version 87+ of the Datadog Lambda Extension allows users to send logs to Observability Pipelines.

To enable this feature, set these environment variables:

• DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_ENABLED: true
• DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_URL: <YOUR_OBSERVABILITY_PIPELINE_URL>

詳細については、Datadog Lambda Extension Forwarder ログを Observability Pipelines に送信する方法を参照してください。

API キーのシークレットを定期的に再読み込みする

Datadog API キーを DD_API_KEY_SECRET_ARN で指定する場合、DD_API_KEY_SECRET_RELOAD_INTERVAL を設定してシークレットを定期的に再読み込みすることもできます。例えば、DD_API_KEY_SECRET_RELOAD_INTERVAL を 43200 に設定すると、API キーがデータ送信のために必要となり、かつ最後の読み込みから 43200 秒以上経過している場合に、シークレットが再読み込みされます。

使用例: セキュリティのために、毎日 (86 400 秒)、API キーがローテーションされ、シークレットが新しいキーに更新され、古い API キーは猶予期間としてさらに 1 日有効になります。この場合、DD_API_KEY_SECRET_RELOAD_INTERVAL を 43200 に設定することで、古い API キーの猶予期間中に API キーが再読み込みされます。

これは Datadog Lambda Extension のバージョン 88 以上で利用可能です。

トラブルシューティング

インストールの設定に問題がある場合は、デバッグログのために環境変数 DD_LOG_LEVEL を debug に設定してください。追加のトラブルシューティングのヒントについては、サーバーレスモニタリングのトラブルシューティングガイドを参照してください。

参考資料

役立つドキュメント、リンク、記事:

AWS Lambda のためのサーバーレスモニタリングのインストールドキュメント AWS Lambda のためのサーバーレスモニタリングのトラブルシューティングドキュメント Datadog GitHub インテグレーションドキュメント Datadog の Serverless Monitoring 用 AWS Lambda の構成ラーニングセンター