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

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

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

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

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

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

environment:
  DD_SERVERLESS_APPSEC_ENABLED: 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 関数をトリガーする 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 トレーサーの構成

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 ソースコードインテグレーションでは、テレメトリー (スタックトレースなど) を Git リポジトリにある Lambda 関数のソースコードにリンクさせることができます。

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

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

Datadog の Continuous Profiler は Python バージョン 4.62.0 とレイヤーバージョン 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 と arm64 の 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 からのレスポンスを待ち、呼び出しをブロックします。

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

インストール時に Datadog Lambda 拡張機能に含まれる Datadog トレーシングライブラリは、OpenTelemetry でインスツルメントされたコードによって生成されたスパンとトレースを受け入れ、テレメトリーを処理して Datadog に送信します。

例えば、コードがすでに OpenTelemetry API でインスツルメントされている場合に、このアプローチを使用することができます。また、OpenTelemetry API を使ってベンダーに依存しないコードでインスツルメントしたいが、Datadog トレーシングライブラリを使用するメリットを得たい場合にも、このアプローチを使用することができます。

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

トラブルシューティング

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

その他の参考資料

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

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