- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
Datadog アカウントを構成して、独自のクラウドストレージシステムへ収集されたすべてのログ (インデックス化の有無にかかわらず) を転送します。ストレージに最適化されたアーカイブにログを長期間保管し、コンプライアンス要件を満たすことができると同時に、アドホック調査のための監査適合性をリハイドレートで維持できます。
Log Forwarding ページに移動して、取り込んだログをクラウドホストのストレージバケットに転送するためのアーカイブをセットアップします。
read
および write
許可を設定します。まだ構成されていない場合は、S3 バケットを保持する AWS アカウントの AWS インテグレーションをセットアップします。
新しいストレージアカウントのあるサブスクリプション内で Azure インテグレーションをセットアップしていない場合、セットアップします。これには、Datadog が統合に使用できるアプリ登録の作成も含まれます。
注: Azure ChinaCloud、GermanyCloud、GovCloud へのアーカイブはサポートされていません。
GCS ストレージバケットを持つプロジェクト用の Google Cloud インテグレーションをセットアップしていない場合、セットアップします。これには Datadog が統合に使用できる Google Cloud サービスアカウントの作成 も含まれます。
AWS コンソールにアクセスし、アーカイブを転送する S3 バケットを作成します。
注:
バケットは一般ユーザーが読み取り可能になるよう設定してください。
まれに最後のデータを書き換える必要があるため、オブジェクトロックを設定しないでください (通常はタイムアウト)。
US1、US3、US5 サイトの場合、地域間データ転送料とクラウドストレージコストへの影響については、AWS Pricing を参照してください。地域間のデータ転送料を管理するために、ストレージバケットを us-east-1
に作成することを検討してください。
注: まれに最後のデータを書き換える必要があるため、不変性ポリシーを設定しないでください (通常はタイムアウト)。
Google Cloud アカウントにアクセスし、アーカイブを転送する GCS バケットを作成します。「Choose how to control access to objects」で、「Set object-level and bucket-level permissions」を選択します。
注: まれに最後のデータを書き換える必要があるため、保持ポリシーを追加しないでください (通常はタイムアウト)。
logs_write_archive
権限のある Datadog ユーザーだけがログアーカイブ構成を作成、変更、または削除できます。
次の権限ステートメントを持つポリシーを作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DatadogUploadAndRehydrateLogArchives",
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": [
"arn:aws:s3:::<MY_BUCKET_NAME_1_/_MY_OPTIONAL_BUCKET_PATH_1>/*",
"arn:aws:s3:::<MY_BUCKET_NAME_2_/_MY_OPTIONAL_BUCKET_PATH_2>/*"
]
},
{
"Sid": "DatadogRehydrateLogArchivesListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::<MY_BUCKET_NAME_1>",
"arn:aws:s3:::<MY_BUCKET_NAME_2>"
]
}
]
}
GetObject
および ListBucket
アクセス許可は、アーカイブからリハイドレートを可能にします。PutObject
アクセス許可で十分です。s3:PutObject
と s3:GetObject
アクションのリソース値は /*
で終わっていることを確認してください。これらの権限はバケット内のオブジェクトに適用されるからです。バケット名を編集します。
オプションで、ログアーカイブを含むパスを指定します。
Datadog のインテグレーションロールに新しいポリシーをアタッチします。
Datadog Google Cloud サービスアカウントに、バケットへアーカイブを書き込むための許可を与えます。
Google Cloud IAM Admin ページから Datadog の Google Cloud サービスアカウントのプリンシパルを選択し、Edit principal を選択します。
ADD ANOTHER ROLE をクリックし、Storage Object Admin ロールを選択し、保存します。
Log Forwarding ページに移動し、Archives タブで Add a new archive を選択します。
注:
logs_write_archive
権限のある Datadog ユーザーだけがこの手順と次の手順を完了させることができます。S3 バケットに適した AWS アカウントとロールの組み合わせを選択します。
バケット名を入力します。任意: ログアーカイブのすべてのコンテンツにプレフィックスディレクトリを入力します。
Azure Storage アーカイブタイプを選択し、ストレージアカウントで Storage Blob Data Contributor ロールのある Datadog アプリ用の Azure テナントとクライアントを選択します。
ストレージアカウント名とアーカイブのコンテナ名を入力します。任意: ログアーカイブのすべてのコンテンツにプレフィックスディレクトリを入力します。
GCS のアーカイブタイプを選択し、ストレージバケットに書き込む権限を持つ GCS サービスアカウントを選択します。バケット名を入力します。
バケット名を入力します。任意: ログアーカイブのすべてのコンテンツにプレフィックスディレクトリを入力します。
デフォルト:
オプションで、コンフィギュレーションステップを使用し、アーカイブにロールを割り当て、以下を実行できるユーザーを設定できます。
logs_write_archive
権限を参照してください。logs_read_archives
と logs_write_historical_view
権限を参照してください。read_index_data
権限を使用する場合に、リハイドレートされたログにアクセスします。以下のためにこのオプションの構成ステップを使用します。
logs_read_data
権限を参照してください。このオプションの構成ステップを使用して、ログアーカイブでリハイドレートのためにスキャンできるログデータの最大量 (GB 単位) を定義します。
最大スキャンサイズが定義されているアーカイブの場合、すべてのユーザーは、リハイドレートを開始する前にスキャンサイズを推定する必要があります。推定されたスキャンサイズがそのアーカイブで許可されているものより大きい場合、ユーザーはリハイドレートを要求する時間範囲を狭めなければなりません。時間範囲を減らすと、スキャンサイズが小さくなり、ユーザーがリハイドレートを開始できるようになります。
S3 バケットにライフサイクルコンフィギュレーションを設定して、ログアーカイブを最適なストレージクラスに自動的に移行できます。
リハイドレートは、以下のストレージクラスのみをサポートします。
他のストレージクラスにあるアーカイブからリハイドレートする場合は、まず上記のサポートされているストレージクラスのいずれかに移動させる必要があります。
アーカイブとリハイドレートは、以下のアクセス層にのみ対応しています。
他のアクセス層にあるアーカイブからリハイドレートする場合は、まず上記のサポートされている層のいずれかに移動させる必要があります。
Amazon S3 バケットのデフォルトの暗号化は、Amazon S3 管理キー (SSE-S3) によるサーバーサイド暗号化です。
S3 バケットが SSE-S3 で暗号化されていることを確認するには
また、Datadog は CMK を利用した AWS KMS からのサーバーサイド暗号化もサポートしています。有効化するには次の手順に従ってください。
{
"Id": "key-consolepolicy-3",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<MY_AWS_ACCOUNT_NUMBER>:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<MY_AWS_ACCOUNT_NUMBER>:role/<MY_DATADOG_IAM_ROLE_NAME>"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<MY_AWS_ACCOUNT_NUMBER>:role/<MY_DATADOG_IAM_ROLE_NAME>"
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
既存の KSM キーに変更を加える場合は、Datadog サポートにお問い合わせください。
Datadog アカウントでアーカイブ設定が正常に構成された時点から、処理パイプラインは Datadog が収集したすべてのログを加工し始めます。その後アーカイブに転送されます。
ただし、アーカイブの構成を作成または更新した後、次のアーカイブのアップロードが試行されるまでに数分かかることがあります。アーカイブがアップロードされる頻度は、さまざまです。アーカイブが Datadog アカウントから正常にアップロードされていることを確認するために、15 分後にストレージバケットを再確認してください。
その後、アーカイブがまだ保留状態である場合、包含フィルターを確認して、クエリが有効で、Live Tail のログイベントに一致することを確認します。設定や権限の意図しない変更により、Datadog が外部アーカイブへのログのアップロードに失敗した場合、構成ページで該当する Log Archive がハイライトされます。
アーカイブにカーソルを合わせると、エラーの詳細と問題を解決するためのアクションが表示されます。また、イベントエクスプローラーにイベントが生成されます。これらのイベントに対するモニターを作成することで、障害を迅速に検出し、修復することができます。
複数のアーカイブが定義されている場合、フィルターに基づき、最初のアーカイブにログが入力されます。
アーカイブの順序を慎重に決めることが重要です。例えば、env:prod
タグでフィルターされた最初のアーカイブと、フィルターなしの 2 番目のアーカイブ (*
に相当) を作成すると、すべてのプロダクションログは一方のストレージバケットまたはパスに送られ、残りはもう一方に送られることになるでしょう。
Datadog がストレージバケットに転送するログアーカイブは、圧縮 JSON 形式 (.json.gz
) です。指定したプレフィックス (ない場合は /
) を使用して、以下のようなアーカイブファイルが生成された日時を示すディレクトリ構造でアーカイブファイルが保存されます。
/my/bucket/prefix/dt=20180515/hour=14/archive_143201.1234.7dq1a9mnSya3bFotoErfxl.json.gz
/my/bucket/prefix/dt=<YYYYMMDD>/hour=<HH>/archive_<HHmmss.SSSS>.<DATADOG_ID>.json.gz
このディレクトリ構造により、過去のログアーカイブを日付に基づいてクエリする処理が簡略化されます。
圧縮 JSON ファイル内の各イベントは、以下の形式で内容が表されます。
{
"_id": "123456789abcdefg",
"date": "2018-05-15T14:31:16.003Z",
"host": "i-12345abced6789efg",
"source": "source_name",
"service": "service_name",
"status": "status_level",
"message": "2018-05-15T14:31:16.003Z INFO rid='acb-123' status=403 method=PUT",
"attributes": { "rid": "abc-123", "http": { "status_code": 403, "method": "PUT" } },
"tags": [ "env:prod", "team:acme" ]
}
お役に立つドキュメント、リンクや記事: