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

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

メトリクス

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

ログ管理

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

APM

• Datadog トレーサーの構成
• APM トレースサンプリングレートの選択
• トレースから機密情報をフィルターまたはスクラブする
• トレース収集の無効化
• リクエストとレスポンスのペイロードを収集する
• 非 Lambda リソースからトレースを収集する
• AWS リソース上でトレースコンテキストを伝播させる
• X-Ray と Datadog のトレースをマージする
• ソースコードにエラーをリンクさせる

その他

• タグを使ったテレメトリー接続
• AWS PrivateLink またはプロキシ経由でテレメトリーを送信する
• 複数の Datadog 組織にテレメトリーを送信する
• Datadog Lambda 拡張機能に移行する
• AWS Lambda のコード署名を有効にする
• ローカルテスト用の Datadog Lambda 拡張機能の構成
• トラブルシューティング

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

予約タグ (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 文字列)
• 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>]);

ログのパースと変換

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

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

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

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

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

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 Lambda 拡張機能の構成

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

トラブルシューティング

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

その他の参考資料

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

サーバーレスモニタリングのインストールドキュメント サーバーレスモニタリングのトラブルシューティングドキュメント