- はじめに
- エージェント
- インテグレーション
- Watchdog
- イベント
- ダッシュボード
- モバイルアプリケーション
- インフラストラクチャー
- サーバーレス
- メトリクス
- ノートブック
- アラート設定
- APM & Continuous Profiler
- CI Visibility
- RUM & セッションリプレイ
- データベース モニタリング
- ログ管理
- セキュリティプラットフォーム
- Synthetic モニタリング
- ネットワークモニタリング
- 開発者
- API
- アカウントの管理
- データセキュリティ
- ヘルプ
まず、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 関数に以下の環境変数を設定します。例えば、以下のようになります。
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 に設定されています。
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": "****"
}
]
Datadog Lambda 拡張メトリクスのリアルタイム収集に加え、Datadog は API Gateway、AppSync、SQS などの AWS マネージドリソースに対するメトリクスを収集し、サーバーレスアプリケーション全体の監視を支援することが可能です。また、メトリクスは対応する AWS リソースタグでリッチ化されます。
これらのメトリクスを収集するには、Datadog AWS インテグレーションを設定します。
AWS Lambda 関数以外のマネージドリソースで生成されたログは、サーバーレスアプリケーションの問題の根本的な原因を特定するのに役立ちます。Datadog では、お使いの環境の以下の AWS マネージドリソースからログを収集することをお勧めします。
Datadog は、Lambda 関数をトリガーする AWS マネージドリソースの受信 Lambda イベントに基づいて APM スパンを推測することができます。これは、AWS マネージドリソース間の関係を視覚化し、サーバーレスアプリケーションにおけるパフォーマンス問題を特定するのに役立ちます。追加の製品詳細をご覧ください。
現在、以下のリソースがサポートされています。
Details
は JSON 文字列)この機能を無効にするには、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 APM クライアントによって自動的にインスツルメントされるライブラリやフレームワークについては、APM の互換性要件を参照してください。カスタムアプリケーションをインスツルメントするには、Datadog の 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 を使用して接続されています。この機能は一般的なランタイムとロガーを使用しているほとんどのアプリケーションでサポートされています (ランタイムによるサポートを参照)。
サポートされていないランタイムまたはカスタムロガーを使用している場合は、以下の手順に従ってください。
dd-trace
を使用して Datadog のトレース ID を取得し、それをログの dd.trace_id
フィールドに追加する必要があります。{
"message": "This is a log",
"dd": {
"trace_id": "4887065908816661012"
}
// ... the rest of your log
}
dd-trace
を使用して 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-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)
}
}
DD_TAGS="git.commit.sha:<GIT_COMMIT_SHA>,git.repository_url=<REPOSITORY_URL>"
を設定しますカスタムメトリクスの送信により、カスタムビジネスロジックを監視することができます。
Datadog Lambda 拡張機能は、Datadog にデータを送信するために公衆インターネットにアクセスする必要があります。Lambda 関数が公衆インターネットにアクセスできない VPC にデプロイされている場合、datadoghq.com
Datadog サイト には AWS PrivateLink 経由でデータを送信し、それ以外のサイトにはプロキシ経由でデータを送信することができます。
Datadog Forwarder を使用している場合は、こちらの手順に従ってください。
複数の Datadog 組織にデータを送信したい場合は、デュアルシッピングの手順に従って、プロジェクトのルートディレクトリに datadog.yaml
ファイルを含めます。
Datadog は、発信する AWS SDK のリクエストにトレースコンテキストを自動的に挿入し、Lambda イベントからトレースコンテキストを抽出します。これにより、Datadog は分散サービス上でリクエストやトランザクションをトレースすることができます。サーバーレスのトレース伝播を参照してください。
AWS X-Ray は、AppSync や Step Functions などの特定の AWS マネージドサービスを通じたトレースをサポートしていますが、Datadog APM ではネイティブにサポートされていません。Datadog X-Ray インテグレーションを有効にし、X-Ray トレースを Datadog ネイティブトレースとマージすることが可能です。追加詳細を参照してください。
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 は、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
を削除します。serverless-plugin-datadog
を最新バージョンにアップグレードします。このバージョンでは、addExtension
を false
に設定しない限り、Datadog Lambda 拡張機能がデフォルトでインストールされます。site
と apiKeySecretArn
を設定します。env
、service
、version
パラメーターを設定していた場合は、それらを設定します。このプラグインは、拡張機能を使用する際に、代わりに DD_ENV
などの Datadog で予約された環境変数を通して自動的にそれらを設定します。subscribeToApiGatewayLogs
、subscribeToHttpApiLogs
、subscribeToWebsocketLogs
を true
に設定している場合は、forwarderArn
パラメーターは削除してください。datadog-serverless-macro
CloudFormation スタックを更新して、最新バージョンを取得します。extensionLayerVersion
パラメーターを最新の拡張機能バージョンに設定します。最新の拡張機能バージョンは 28
です。site
と apiKeySecretArn
を設定します。forwarderArn
パラメーターを削除します。datadog-cdk-constructs
または datadog-cdk-constructs-v2
を最新バージョンにアップグレードします。extensionLayerVersion
パラメーターを最新の拡張機能バージョンに設定します。最新の拡張機能バージョンは 28
です。site
と apiKeySecretArn
を設定します。env
、service
、version
パラメーターを設定していた場合は、それらを設定します。このコンストラクトは、拡張機能を使用する際に、代わりに DD_ENV
などの Datadog で予約された環境変数を通して自動的にそれらを設定します。forwarderArn
パラメーターを削除します。DD_SITE
と DD_API_KEY_SECRET_ARN
を設定します。DD_ENV
、DD_SERVICE
、DD_VERSION
を Lambda のリソースタグとして設定したことがある場合は、それを設定します。Datadog Lambda 拡張機能をインストールして、Lambda 関数のコンテナイメージをローカルでテストするには、ローカルのテスト環境で DD_LOCAL_TEST
を true
に設定する必要があります。そうしないと、拡張機能は AWS Extensions API からのレスポンスを待ち、呼び出しをブロックします。
インストール時の構成に問題がある場合は、環境変数 DD_LOG_LEVEL
を debug
に設定すると、デバッグ用のログが出力されます。その他のトラブルシューティングのヒントについては、サーバーレスモニタリングのトラブルシューティングガイドを参照してください。
お役に立つドキュメント、リンクや記事: