サーバーレスモニタリングの構成

まず、Datadog サーバーレスモニタリングをインストールし、メトリクス、トレース、ログの収集を開始します。インストールが完了したら、以下のトピックを参照して、モニタリングのニーズに合わせてインストールを構成します。

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

予約タグ (env、service、version) とカスタムタグを使用して、Datadog のテレメトリーを一緒に接続します。これらのタグを使用して、メトリクス、トレース、ログをシームレスに操作することができます。使用するインストール方法に応じて、以下の追加パラメーターを追加してください。

Datadog CLI の最新バージョンを使用していることを確認し、適切な追加引数を指定して datadog-ci lambda instrument コマンドを実行します。例えば、以下のようになります。

datadog-ci lambda instrument \
    --env dev \
    --service web \
    --version v1.2.3 \
    --extra-tags "team:avengers,project:marvel"
    # ... その他の必要な引数 (関数名など)

Datadog サーバーレスプラグインの最新バージョンを使用していることを確認し、env、service、version、tags パラメーターを使用してタグを適用します。例えば、以下のようになります。

custom:
  datadog:
    # ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
    env: dev
    service: web
    version: v1.2.3
    tags: "team:avengers,project:marvel"

デフォルトでは、env と service を定義しない場合、プラグインは自動的にサーバーレスアプリケーションの定義にある stage と service の値を使用します。この機能を無効にするには、enableTags を false に設定します。

Datadog サーバーレスマクロの最新バージョンを使用していることを確認し、env、service、version、tags パラメーターを使用してタグを適用します。例えば、以下のようになります。

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
      env: dev
      service: web
      version: v1.2.3
      tags: "team:avengers,project:marvel"

Datadog サーバーレス cdk コンストラクトの最新バージョンを使用していることを確認し、env、service、version、tags パラメーターを使用してタグを適用します。例えば、以下のようになります。

const datadog = new Datadog(this, "Datadog", {
    // ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
    env: "dev",
    service: "web",
    version: "v1.2.3",
    tags: "team:avengers,project:marvel"
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

Datadog Lambda 拡張機能を使用して Lambda 関数からテレメトリーを収集している場合、Lambda 関数に以下の環境変数を設定します。例えば、以下のようになります。

DD_ENV: dev
DD_SERVICE: web
DD_VERSION: v1.2.3
DD_TAGS: team:avengers,project:marvel

Datadog Forwarder Lambda 関数を使って Lambda 関数からテレメトリーを収集している場合、Lambda 関数に env、service、version および追加のタグを AWS リソースタグとして設定します。Datadog Forwarder の CloudFormation スタックで、DdFetchLambdaTags オプションが true に設定されていることを確認します。このオプションは、バージョン 3.19.0 以降、デフォルトで true に設定されています。

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

Datadog Lambda 拡張機能を使って Lambda 関数からテレメトリーを収集している場合、Datadog AWS インテグレーションを有効にしてください。この機能は、テレメトリーをカスタムタグでリッチ化するためのものです。Datadog の予約タグ (env、service、version) は、対応する環境変数 (それぞれ DD_ENV、DD_SERVICE、DD_VERSION) で設定する必要があります。予約タグは、サーバーレス開発者向けツールと Datadog のインテグレーションで提供されるパラメーターで設定することも可能です。この機能は、コンテナイメージでデプロイされた Lambda 関数では機能しません。
Datadog Forwarder Lambda 関数を使って Lambda 関数からテレメトリーを収集している場合、Datadog Forwarder の CloudFormation スタックで、DdFetchLambdaTags オプションを true に設定します。このオプションは、バージョン 3.19.0 以降、デフォルトで true に設定されています。

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

この機能は現在、Python、Node.js、Java、.NET でサポートされています。

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

この機能は、デフォルトでは無効になっています。使用するインストール方法については、以下の説明に従ってください。

Datadog CLI の最新バージョンを使用していることを確認し、追加引数 --capture-lambda-payload を指定して datadog-ci lambda instrument コマンドを実行します。例えば、以下のようになります。

datadog-ci lambda instrument \
    --capture-lambda-payload true
    # ... その他の必要な引数 (関数名など)

Datadog サーバーレスプラグインの最新バージョンを使用していることを確認し、captureLambdaPayload を true に設定します。例えば、以下のようになります。

custom:
  datadog:
    # ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
    captureLambdaPayload: true

Datadog サーバーレスマクロの最新バージョンを使用していることを確認し、captureLambdaPayload パラメーターを true に設定します。例えば、以下のようになります。

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
      captureLambdaPayload: true

Datadog サーバーレス cdk コンストラクトの最新バージョンを使用していることを確認し、captureLambdaPayload パラメーターを true に設定します。例えば、以下のようになります。

const datadog = new Datadog(this, "Datadog", {
    // ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
    captureLambdaPayload: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

Lambda 関数で環境変数 DD_CAPTURE_LAMBDA_PAYLOAD を true に設定します。

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

そのためには、Lambda 関数のコードと同じフォルダに、新しいファイル datadog.yaml を追加してください。Lambda ペイロードのフィールドの難読化は、datadog.yaml の apm_config 設定内の replace_tags ブロックで行うことができます。

apm_config:
  replace_tags:
    # 任意のタグに出現する "foobar" をすべて "REDACTED" に置き換えます:
    - name: "*"
      pattern: "foobar"
      repl: "REDACTED"
    # リクエストヘッダーの "auth "を空の文字列に置き換えます
    - name: "function.request.headers.auth"
      pattern: "(?s).*"
      repl: ""
    # レスポンスペイロードの "apiToken" を "****" に置き換えます
    - 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": "****"
      }
]

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

Datadog Lambda 拡張メトリクスのリアルタイム収集に加え、Datadog は API Gateway、AppSync、SQS などの AWS マネージドリソースに対するメトリクスを収集し、サーバーレスアプリケーション全体の監視を支援することが可能です。また、メトリクスは対応する AWS リソースタグでリッチ化されます。

これらのメトリクスを収集するには、Datadog AWS インテグレーションを設定します。

非 Lambda リソースからログを収集する

AWS Lambda 関数以外のマネージドリソースで生成されたログは、サーバーレスアプリケーションの問題の根本的な原因を特定するのに役立ちます。Datadog では、お使いの環境の以下の AWS マネージドリソースからログを収集することをお勧めします。

API: API Gateway、AppSync、ALB
キューとストリーム: SQS、SNS、Kinesis
データストア: DynamoDB、S3、RDS

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

この機能は現在、Python、Node.js、Java、.NET でサポートされています。

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 に設定します。

ログから情報をフィルタリングまたはスクラブする

START と END のログを除外するには、環境変数 DD_LOGS_CONFIG_PROCESSING_RULES を [{"type": "exclude_at_match", "name": "exclude_start_and_end_logs", "pattern": "(START|END) RequestId"}] に設定します。また、プロジェクトのルートディレクトリに datadog.yaml ファイルを追加して、以下の内容を記述することも可能です。

logs_config:
  processing_rules:
    - type: exclude_at_match
      name: exclude_start_and_end_logs
      pattern: (START|END) RequestId

Datadog では、REPORT ログを残すことを推奨しています。これは、サーバーレス関数のビューで呼び出しリストを生成するために使用されるからです。

Datadog に送信する前に他のログをスクラブまたはフィルタリングするには、高度なログ収集を参照してください。

ログ収集の無効化

Datadog Lambda 拡張機能によるログ収集は、デフォルトで有効になっています。

Datadog Forwarder Lambda 関数を使用したログ収集を停止したい場合は、自身の Lambda 関数の CloudWatch ロググループからサブスクリプションフィルターを削除します。

Datadog Lambda 拡張機能を使用してログの収集を停止したい場合は、使用するインストール方法に応じて以下の手順に従ってください。

custom:
  datadog:
    # ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
    enableDDLogs: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
      enableDDLogs: false

const datadog = new Datadog(this, "Datadog", {
    // ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
    enableDatadogLogs: false
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

Lambda 関数で環境変数 DD_SERVERLESS_LOGS_ENABLED を false に設定します。

ログのパースと変換

Datadog でログをパースして変換するには、Datadog ログパイプラインのドキュメントを参照してください。

Datadog トレーサーの構成

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

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

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

メトリクスは、アプリケーションの 100% のトラフィックに基づいて計算され、どのようなサンプリング構成であっても正確な値を維持します。

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

デフォルトのサンプリングメカニズムはヘッドベースサンプリングと呼ばれています。トレースを維持するか削除するかの決定は、トレースの一番最初、ルートスパンの開始時に行われます。この決定は、HTTP リクエストヘッダーなどのリクエストコンテキストの一部として、他のサービスに伝搬されます。

この判断はトレースの最初に行われ、その後トレースのすべての部分に伝えられるため、トレースは全体として保持または削除されることが保証されます。

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

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

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

トレース収集の無効化

Datadog Lambda 拡張機能によるトレース収集は、デフォルトで有効になっています。Lambda 関数からのトレース収集を停止したい場合は、以下の手順に従ってください。

datadog-ci lambda instrument \
    --tracing false
    # ... その他の必要な引数 (関数名など)

custom:
  datadog:
    # ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
    enableDDTracing: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
      enableDDTracing: false

const datadog = new Datadog(this, "Datadog", {
    // ... その他の必要なパラメーター (Datadog のサイトや API キーなど)
    enableDatadogTracing: false
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

Lambda 関数で環境変数 DD_TRACE_ENABLED を false に設定します。

ログとトレースの接続

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

Forwarder Lambda 関数を使用してトレースとログを収集している場合、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 パーサールールを更新して、Datadog トレース ID を dd.trace_id 属性にパースするようにします。例えば、[INFO] dd.trace_id=4887065908816661012 My log messageのようなログには、ルール my_rule \[%{word:level}\]\s+dd.trace_id=%{word:dd.trace_id}.* が使用されます。

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

この機能は、Go と Java でサポートされています。

Datadog ソースコードインテグレーションでは、GitHub で Lambda 関数のソースコードにテレメトリー (スタックトレースなど) をリンクさせることができます。以下の手順で機能を有効化してください。注: ダーティでもリモートより先でもない、ローカルの Git リポジトリからデプロイする必要があります。

datadog-ci lambda instrument を --source-code-integration true で実行すると、現在のローカルディレクトリの Git メタデータが自動的に送信され、Lambda 関数に必要なタグが追加されます。

注: Git のメタデータをアップロードするためには、環境変数 DATADOG_API_KEY を datadog-ci に設定する必要があります。DATADOG_API_KEY は、テレメトリーを送信する Lambda 関数にも設定されますが、 DATADOG_API_KEY_SECRET_ARN も定義されている場合は、DATADOG_API_KEY より優先的に設定されます。

# ... その他の必要な環境変数 (DATADOG_SITE など)

# 必須、git メタデータをアップロードするため
export DATADOG_API_KEY=<DATADOG_API_KEY>

# オプション、未定義の場合は DATADOG_API_KEY が使用されます
export DATADOG_API_KEY_SECRET_ARN=<DATADOG_API_KEY_SECRET_ARN>

datadog-ci lambda instrument \
    --source-code-integration true
    # ... その他の必要な引数 (関数名など)

enableSourceCodeIntegration を true に設定すると、Datadog サーバーレスプラグインは自動的に現在のローカルディレクトリの Git メタデータを送信し、Lambda 関数に必要なタグを追加します。

注: Git のメタデータをアップロードするためには、プラグインに apiKey パラメーターを設定する必要があります。また、テレメトリーを送信する Lambda 関数にも apiKey が設定されますが、apiKeySecretArn も定義されている場合は apiKey よりも優先されます。

custom:
  datadog:
    # ... その他の必要なパラメーター (Datadog のサイトなど)
    apiKey: <apiKey> # required, to upload git metadata
    apiKeySecretArn: <apiKeySecretArn> # オプション、未定義の場合は apiKey が使用されます
    enableSourceCodeIntegration: true # default is true

初期化関数を次のように変更し、CDK スタックに gitHash の値を渡します。

async function main() {
  // パッケージマネージャーで @datadog/datadog-ci を追加することを確認します
  const datadogCi = require("@datadog/datadog-ci");
  const gitHash = await datadogCi.gitMetadata.uploadGitCommitHash('{Datadog_API_Key}', '<SITE>')

  const app = new cdk.App();
  // ExampleStack のコンストラクタにハッシュを渡します
  new ExampleStack(app, "ExampleStack", {}, gitHash);
}

スタックのコンストラクタで、オプションの gitHash パラメーターを追加して、addGitCommitMetadata() を呼び出します。

export class ExampleStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps, gitHash?: string) {
    ...
    ...
    datadog.addGitCommitMetadata([<YOUR_FUNCTIONS>], gitHash)
  }
}

Lambda 関数に環境変数 DD_TAGS="git.commit.sha:<GIT_COMMIT_SHA>,git.repository_url=<REPOSITORY_URL>" を設定します
CI パイプラインで datadog-ci git-metadata upload を実行し、Git メタデータをアップロードします
オプションで、GitHub アプリをインストールすると、インラインでソースコードのスニペットを表示することができます。

カスタムメトリクスの送信

カスタムメトリクスの送信により、カスタムビジネスロジックを監視することができます。

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

Datadog Lambda 拡張機能は、Datadog にデータを送信するために公衆インターネットにアクセスする必要があります。Lambda 関数が公衆インターネットにアクセスできない VPC にデプロイされている場合、datadoghq.com Datadog サイトには AWS PrivateLink 経由でデータを送信し、それ以外のサイトにはプロキシ経由でデータを送信することができます。

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

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

複数の Datadog 組織にデータを送信したい場合は、デュアルシッピングの手順に従って、プロジェクトのルートディレクトリに datadog.yaml ファイルを含めます。

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

Datadog は、発信する AWS SDK のリクエストにトレースコンテキストを自動的に挿入し、Lambda イベントからトレースコンテキストを抽出します。これにより、Datadog は分散サービス上でリクエストやトランザクションをトレースすることができます。サーバーレスのトレース伝播を参照してください。

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

AWS X-Ray は、AppSync や Step Functions などの特定の AWS マネージドサービスを通じたトレースをサポートしていますが、Datadog APM ではネイティブにサポートされていません。Datadog X-Ray インテグレーションを有効にし、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 拡張機能に移行する

Datadog は、Forwarder Lambda 関数または Lambda 拡張機能を使用して、Lambda 関数から監視データを収集することができます。Datadog は、新規インストールには Lambda 拡張機能を推奨しています。迷っている場合は、Datadog Lambda 拡張機能への移行を決定するを参照してください。

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

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

datadog/datadog-ci を最新バージョンにアップグレードする
引数 --layer-version を更新し、ランタイムの最新バージョンに設定します。
引数 --extension-version を最新の拡張機能バージョンに設定します。最新の拡張機能バージョンは 28 です。
必要な環境変数 DATADOG_SITE と DATADOG_API_KEY_SECRET_ARN を設定します。
引数 --forwarder を削除します。
Lambda のロググループに Forwarder を自動的にサブスクライブするように Datadog AWS インテグレーションを構成した場合、その地域の Lambda 関数を_すべて_移行した後にそれを無効にしてください。

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

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

datadog-cdk-constructs または datadog-cdk-constructs-v2 を最新バージョンにアップグレードします。
extensionLayerVersion パラメーターを最新の拡張機能バージョンに設定します。最新の拡張機能バージョンは 28 です。
必要なパラメーター site と apiKeySecretArn を設定します。
Lambda のリソースタグとして env、service、version パラメーターを設定していた場合は、それらを設定します。このコンストラクトは、拡張機能を使用する際に、代わりに DD_ENV などの Datadog で予約された環境変数を通して自動的にそれらを設定します。
forwarderArn パラメーターを削除します。
Lambda のロググループに Forwarder を自動的にサブスクライブするように Datadog AWS インテグレーションを構成した場合、その地域の Lambda 関数を_すべて_移行した後にそれを無効にしてください。

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

ローカルテスト用の Datadog Lambda 拡張機能の構成

Datadog Lambda 拡張機能をインストールして、Lambda 関数のコンテナイメージをローカルでテストするには、ローカルのテスト環境で DD_LOCAL_TEST を true に設定する必要があります。そうしないと、拡張機能は AWS Extensions API からのレスポンスを待ち、呼び出しをブロックします。