AWS Lambda のためのサーバーレスモニタリングの構成

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

メトリクス

• 非 Lambda リソースからメトリクスを収集する
• カスタムメトリクスの送信

ログ管理

• ログから情報をフィルターまたはスクラブする
• ログ収集の有効化/無効化
• 非 Lambda リソースからログを収集する
• ログのパースと変換
• ログとトレースを接続する

APM

• タグを使ったテレメトリー接続
• リクエストとレスポンスのペイロードを収集する
• 非 Lambda リソースからメトリクスを収集する
• 非 Lambda リソースからログを収集する
• 非 Lambda リソースからトレースを収集する
• ログから情報をフィルターまたはスクラブする
• ログ収集の有効化/無効化
• ログのパースと変換
• Datadog トレーサーの構成
• APM スパンを取り込む際のサンプリングレートの選択
• トレースから機密情報をフィルターまたはスクラブする
• トレース収集の有効化/無効化
• ログとトレースを接続する
• ソースコードにエラーをリンクさせる
• カスタムメトリクスの送信
• OpenTelemetry のデータを Datadog に送信する
• プロファイリングデータの収集 (公開ベータ版)
• PrivateLink またはプロキシ経由でテレメトリーを送信する
• 複数の Datadog 組織にテレメトリーを送信する
• AWS リソース上でトレースコンテキストを伝播させる
• X-Ray と Datadog のトレースをマージする
• AWS Lambda のコード署名を有効にする
• Datadog Lambda 拡張機能に移行する
• Datadog Lambda 拡張機能による x86 から arm64 への移行
• ローカルテスト用の Datadog Lambda 拡張機能の構成
• トラブルシューティング
• 参考文献

セキュリティ

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

その他

• タグを使ったテレメトリー接続
• リクエストとレスポンスのペイロードを収集する
• 非 Lambda リソースからメトリクスを収集する
• 非 Lambda リソースからログを収集する
• 非 Lambda リソースからトレースを収集する
• ログから情報をフィルターまたはスクラブする
• ログ収集の無効化
• ログのパースと変換
• Datadog トレーサーの構成
• APM スパンを取り込む際のサンプリングレートの選択
• トレースから機密情報をフィルターまたはスクラブする
• トレース収集の無効化
• ログとトレースを接続する
• ソースコードにエラーをリンクさせる
• カスタムメトリクスの送信
• OpenTelemetry のデータを Datadog に送信する
• PrivateLink またはプロキシ経由でテレメトリーを送信する
• 複数の Datadog 組織にテレメトリーを送信する
• AWS リソース上でトレースコンテキストを伝播させる
• X-Ray と Datadog のトレースをマージする
• AWS Lambda のコード署名を有効にする
• Datadog Lambda 拡張機能に移行する
• Datadog Lambda 拡張機能による x86 から arm64 への移行
• ローカルテスト用の Datadog Lambda 拡張機能の構成
• トラブルシューティング
• 参考文献

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

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

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

脅威の監視を有効にするには、言語に応じて次の環境変数を追加します。

environment:
  DD_SERVERLESS_APPSEC_ENABLED: true

Go の関数の場合のみ、さらに以下を追加します。

environment:
  DD_UNIVERSAL_INSTRUMENTATION: true

NodeJS または Python の関数の場合は、さらに以下を追加します。

environment:
  DD_EXPERIMENTAL_ENABLE_PROXY: true
  AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper

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

アプリケーションセキュリティ管理の脅威検出のアクションを見るには、既知の攻撃パターンをアプリケーションに送信します。例えば、acunetix-product という値を持つ HTTP ヘッダーを送信すると、セキュリティスキャナー攻撃の試行がトリガーされます。

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

アプリケーションを攻撃パターンを送信すると、数分後にアプリケーションシグナルエクスプローラーに脅威情報が表示されます。

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

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

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

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

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

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 関数に定義された既存の 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 に設定されています。

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

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

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

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

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

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

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

リクエストやレスポンスの 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 リソースからトレースを収集する

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 文字列)
• 注: 2 つ以上のソースにサブスクライブする場合、このセットアップを完了後、新しい Kinesis ストリームにサブスクライブすることができます。
• 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 を参照してください。

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

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 拡張機能によるログ収集は、デフォルトで有効になっています。

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

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

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

ログ収集の無効化

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>]);

詳しくは、ログ管理 をご覧ください。

ログのパースと変換

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

Datadog トレーサーの構成

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

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

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

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

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

取り込みのためのデフォルトのサンプリングメカニズムはヘッドベースサンプリングと呼ばれています。トレースを維持するか削除するかの決定は、トレースの一番最初、ルートスパンの開始時に行われます。この決定は、HTTP リクエストヘッダーなどのリクエストコンテキストの一部として、他のサービスに伝搬されます。この判断はトレースの最初に行われ、その後トレースのすべての部分に伝えられるため、ルートサービスのサンプリングレートを構成しないと有効になりません。

Datadog がスパンを取り込んだ後、Datadog インテリジェント保持フィルターはトレースの一定割合をインデックス化し、アプリケーションの健全性を監視するのに役立てることができます。また、カスタムの保持フィルターを定義して、組織の目標をサポートするために長く保存しておきたいトレースデータのインデックスを作成することも可能です。

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

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

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

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

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

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

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

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

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

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

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

トレース収集の無効化

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 拡張機能を使ってトレースやログを収集している場合、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}.* が使用されます。

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

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

# ... その他の必要な環境変数 (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
    # ... その他の必要な引数 (関数名など)

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

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);
}

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

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

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

OpenTelemetry のデータを Datadog に送信する

1. OpenTelemetry にスパンを Datadog Lambda 拡張機能にエクスポートするよう指示します。

   // instrument.js
   
   const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");
   const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');
   const { Resource } = require('@opentelemetry/resources');
   const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
   const { SimpleSpanProcessor } = require('@opentelemetry/sdk-trace-base');
   
   const provider = new NodeTracerProvider({
      resource: new Resource({
          [ SemanticResourceAttributes.SERVICE_NAME ]: 'rey-app-otlp-dev-node',
      })
   });
   
   provider.addSpanProcessor(
      new SimpleSpanProcessor(
          new OTLPTraceExporter(
              { url: 'http://localhost:4318/v1/traces' },
          ),
      ),
   );
   provider.register();
   

2. AWS Lambda 用の OpenTelemetry のインスツルメンテーションを追加します。これはトレースレイヤーを追加するようなものです。

   // instrument.js
   
   const { AwsInstrumentation } = require('@opentelemetry/instrumentation-aws-sdk');
   const { AwsLambdaInstrumentation } = require('@opentelemetry/instrumentation-aws-lambda');
   const { registerInstrumentations } = require('@opentelemetry/instrumentation');
   
   registerInstrumentations({
      instrumentations: [
          new AwsInstrumentation({
              suppressInternalInstrumentation: true,
          }),
          new AwsLambdaInstrumentation({
              disableAwsContextPropagation: true,
          }),
      ],
   });
   

3. 実行時にインスツルメンテーションを適用します。例えば、Node.js の場合、NODE_OPTIONS を使用します。

   # serverless.yml
   
   functions:
     node:
       handler: handler.handler
       environment:
         NODE_OPTIONS: --require instrument
   

4. DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT または DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_GRPC_ENDPOINT 環境変数を使って OpenTelemetry を有効にします。Datadog 拡張機能 v41 以降を追加してください。Datadog のトレーシングレイヤーを追加しないでください。

   # serverless.yml
   
   provider:
     name: aws
     region: sa-east-1
     runtime: nodejs18.x
     environment:
       DD_API_KEY: ${env:DD_API_KEY}
       DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_HTTP_ENDPOINT: localhost:4318
     layers:
       - arn:aws:lambda:sa-east-1:464622532012:layer:Datadog-Extension:42
   

5. デプロイします。

プロファイリングデータの収集 (公開ベータ版)

Datadog の Continuous Profiler は、Python ではバージョン 4.62.0、Layer ではバージョン 62 以前のベータ版で利用できます。このオプション機能は、環境変数 DD_PROFILING_ENABLED を true に設定することで有効になります。

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

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

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

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

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

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

# メトリクスでデュアルシッピングを有効にします
DD_ADDITIONAL_ENDPOINTS={"https://app.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://app.datadoghq.eu": ["<your_api_key_4>"]}
# APM (トレース) でデュアルシッピングを有効にします
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>"]}
# APM (プロファイリング) でデュアルシッピングを有効にします
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>"]}
# ログでデュアルシッピングを有効にします
DD_LOGS_CONFIG_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}]

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

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

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 Lambda 拡張機能で x86 と arm64 の切り替えを行う

Datadog 拡張機能はコンパイル済みのバイナリコードで、x86 と rm64 の2種類が用意されています。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 拡張機能の構成

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

トラブルシューティング

インストール時の構成に問題がある場合は、環境変数 DD_LOG_LEVEL を debug に設定すると、デバッグ用のログが出力されます。その他のトラブルシューティングのヒントについては、サーバーレスモニタリングのトラブルシューティングガイドを参照してください。

その他の参考資料

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

AWS Lambda のためのサーバーレスモニタリングのインストールDOCUMENTATION AWS Lambda のためのサーバーレスモニタリングのトラブルシューティングDOCUMENTATION Datadog GitHub インテグレーションDOCUMENTATION