概要
Datadog アカウントを構成して、独自のクラウドストレージシステムへ収集されたすべてのログ (インデックス化の有無にかかわらず) を転送します。ストレージに最適化されたアーカイブにログを長期間保管し、コンプライアンス要件を満たすことができると同時に、アドホック調査のための監査適合性をリハイドレートで維持できます。
Log Forwarding ページに移動して、取り込んだログを自分のクラウドホストのストレージバケットに転送するためのアーカイブをセットアップします。
- まだの場合は、お使いのクラウドプロバイダーと Datadogのインテグレーションを設定してください。
- ストレージバケットを作成します。
- そのアーカイブへの
read
および write
権限を設定します。 - アーカイブへ、およびアーカイブからログをルーティングします。
- 暗号化、ストレージクラス、タグなどの詳細設定を構成します。
- 設定を検証し、Datadog で検出される可能性のある構成ミスがないか確認します。
環境から直接ストレージに最適化されたアーカイブにログをルーティングしたい場合は、Observability Pipelines でログをアーカイブする方法を参照してください。
ログアーカイブを構成します
インテグレーションを設定します
ロール委任を使用した S3 アーカイブの設定は現在限定的に利用可能です。Datadog for Government アカウントでこの機能をリクエストするには、Datadog サポートにお問い合わせください。
まだ構成されていない場合は、S3 バケットを保持する AWS アカウントの AWS インテグレーションをセットアップします。
- 一般的なケースでは、これには、Datadog が AWS S3 との統合に使用できるロールの作成が含まれます。
- 特に AWS China アカウントの場合は、ロール委任の代わりにアクセスキーを使用します。
ストレージバケットを作成
アーカイブへのログの送信は、Datadog GovCloud 環境の外部であり、Datadog の管理外です。Datadog は、Datadog GovCloud 環境から出たログについて、FedRAMP、DoD Impact Levels、ITAR、輸出コンプライアンス、データレジデンシー、または当該ログに適用される類似の規制に関連するユーザーの義務または要件を含むが、これらに限定されることなく、一切の責任を負わないものとします。
- Azure ポータルにアクセスし、アーカイブを転送するストレージアカウントを作成します。標準パフォーマンスまたは Block blobs プレミアムアカウントタイプを選択し、hot または cool アクセス層を選択します。
- そのストレージアカウントに container サービスを作成します。Datadog アーカイブページに追加する必要があるため、コンテナ名をメモしてください。
注: まれに最後のデータを書き換える必要があるため、不変性ポリシーを設定しないでください (通常はタイムアウト)。
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 のインテグレーションロールに新しいポリシーをアタッチします。
- AWS IAM コンソールで Roles に移動します。
- Datadog インテグレーションで使用されるロールを見つけます。デフォルトでは、 DatadogIntegrationRole という名前になっていますが、組織で名前を変更した場合は、名前が異なる場合があります。ロール名をクリックすると、ロールのサマリーページが表示されます。
- Add permissions、Attach policies の順にクリックします。
- 上記で作成したポリシーの名称を入力します。
- Attach policies をクリックします。
- Datadog アプリに、ストレージアカウントへの書き込みおよびリハイドレートを行うための権限を付与します。
- ストレージアカウントのページでストレージアカウントを選択し、Access Control (IAM) で Add -> Add Role Assignment を選択します。
- Role に Storage Blob Data Contributor を入力し、Azure と統合するために作成した 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 ユーザーだけがこの手順と次の手順を完了させることができます。- Azure Blob Storage へのログのアーカイブには、App Registration が必要です。Azure インテグレーションページの手順を参照し、ドキュメントページの右側にある「サイト」を「US」に設定してください。アーカイブ目的で作成された App Registration は、“Storage Blob Data Contributor” ロールのみが必要です。ストレージバケットが Datadog Resource を通じて監視されているサブスクリプションにある場合、App Registration が冗長である旨の警告が表示されます。この警告は無視することができます。
- バケットでネットワークアクセスを特定の IP に制限している場合は、IP 範囲リストから Webhook の IP を許可リストに追加してください。
- US1-FED サイトの場合、Datadog を構成して、ログを Datadog GovCloud 環境外の宛先に送信することができます。Datadog は、Datadog GovCloud 環境を離れたログに対して一切の責任を負いません。また、これらのログが GovCloud 環境を離れた後に適用される FedRAMP、DoD 影響レベル、ITAR、輸出コンプライアンス、データ居住地、またはそれに類する規制に関する義務や要件についても、Datadog は一切の責任を負いません。
S3 バケットに適した AWS アカウントとロールの組み合わせを選択します。
バケット名を入力します。任意: ログアーカイブのすべてのコンテンツにプレフィックスディレクトリを入力します。
Azure Storage アーカイブタイプを選択し、ストレージアカウントで Storage Blob Data Contributor ロールのある Datadog アプリ用の Azure テナントとクライアントを選択します。
ストレージアカウント名とアーカイブのコンテナ名を入力します。任意: ログアーカイブのすべてのコンテンツにプレフィックスディレクトリを入力します。
GCS のアーカイブタイプを選択し、ストレージバケットに書き込む権限を持つ GCS サービスアカウントを選択します。バケット名を入力します。
バケット名を入力します。任意: ログアーカイブのすべてのコンテンツにプレフィックスディレクトリを入力します。
高度な設定
Datadog の権限
デフォルト:
- すべての Datadog 管理者ユーザーは、アーカイブの作成、編集、並べ替えができます。詳しくは、複数アーカイブの構成を参照してください。
- すべての Datadog 監理者および標準ユーザーは、アーカイブからリハイドレーションできます。
- Datadog の読み取り専用ユーザーを含むすべてのユーザーは、リハイドレーションされたログにアクセスできます。
オプションで、コンフィギュレーションステップを使用し、アーカイブにロールを割り当て、以下を実行できるユーザーを設定できます。
Datadog タグ
以下のためにこのオプションの構成ステップを使用します。
- アーカイブ内のすべてのログタグを含める (デフォルトでは、すべての新規アーカイブに有効化されています)。注: 結果のアーカイブサイズが増大します。
- リハイドレートされたログに、制限クエリポリシーに従ってタグを追加します。
logs_read_data
権限を参照してください。
最大スキャンサイズを定義する
このオプションの構成ステップを使用して、ログアーカイブでリハイドレートのためにスキャンできるログデータの最大量 (GB 単位) を定義します。
最大スキャンサイズが定義されているアーカイブの場合、すべてのユーザーは、リハイドレートを開始する前にスキャンサイズを推定する必要があります。推定されたスキャンサイズがそのアーカイブで許可されているものより大きい場合、ユーザーはリハイドレートを要求する時間範囲を狭めなければなりません。時間範囲を減らすと、スキャンサイズが小さくなり、ユーザーがリハイドレートを開始できるようになります。
ストレージクラス
S3 バケットにライフサイクルコンフィギュレーションを設定して、ログアーカイブを最適なストレージクラスに自動的に移行できます。
リハイドレートは、以下のストレージクラスのみをサポートします。
- S3 Standard
- S3 Standard-IA
- S3 One Zone-IA
- S3 Glacier Instant Retrieval
他のストレージクラスにあるアーカイブからリハイドレートする場合は、まず上記のサポートされているストレージクラスのいずれかに移動させる必要があります。
アーカイブとリハイドレートは、以下のアクセス層にのみ対応しています。
他のアクセス層にあるアーカイブからリハイドレートする場合は、まず上記のサポートされている層のいずれかに移動させる必要があります。
サーバー側の暗号化 (SSE)
SSE-S3
Amazon S3 バケットのデフォルトの暗号化は、Amazon S3 管理キー (SSE-S3) によるサーバーサイド暗号化です。
S3 バケットが SSE-S3 で暗号化されていることを確認するには
- S3 バケットに移動します。
- Properties タブをクリックします。
- Default Encryption セクションで、Encryption key type が Amazon S3 managed keys (SSE-S3) であることを確認します。
SSE-KMS
また、Datadog は CMK を利用した AWS KMS からのサーバーサイド暗号化もサポートしています。有効化するには次の手順に従ってください。
- CMK を作成します。
- CMK に付随する CMK ポリシーに以下のコンテンツを添加して、AWS アカウント番号と Datadog IAM ロール名を適切なものに置き換えます。
{
"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"
}
}
}
]
}
- S3 バケットの Properties タブに移動し、Default Encryption を選択します。“AWS-KMS” オプション、CMK ARN の順に選択して保存します。
既存の 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" ]
}
その他の参考資料
*Logging without Limits は Datadog, Inc. の商標です。