はじめに
以下のようなよくある構成図について、
ログ出力先や出力されるログ内容まで意識したことはありますか?
本記事は、各サービスにおいてログの出力設定方法、
どのようなログが確認できるのかを記載した記事になります。
1.サービス構成
S3静的Webホスティング+サーバレスのよくある構成。
サービスイメージとしてはニュース情報収集サイトであり、
処理フローは以下の通りです。
処理フロー
①:ユーザがDNS名を対象にウェブサイトへアクセス
②:Route53がリクエストを受け取り、CloudFrontにルーティング
③:CloudFrontがコンテンツをキャッシュしていれば、ユーザにレスポンス
キャッシュしていなければS3にリクエストを転送
④:S3に格納された静的ウェブサイトが呼び出され、ユーザーに表示
⑤:ユーザが静的Webサイトのボタンを押下するとAPIGatewayへリクエスト
⑥:APIGatewayがスクレイピング用Lambda関数を呼び出す
⑥:Lambdaが受け取ったデータをDynamoDBに書き込み
⑦:別のLambdaがDyanmoDBからデータ取得/整形し、静的Webサイトに表示
利用サービス
利用AWSサービス名 | サービス説明 |
---|---|
Amazon Route53 | ドメイン登録とDNSルーティング機能を持つ DNSサービス |
Amazon CloudFront | 静的および動的ウェブコンテンツを高速配信するCDNサービス |
AWS CertificateManager | SSL/TLS証明書の管理サービス |
Amazon S3 | 高可用性かつ安価なストレージサービス |
API Gateway | APIの作成、公開、管理のためのサービス |
AWS Lambda | イベント駆動型のサーバレスコンピューティングサービス |
Amazon Dynamodb | フルマネージド型のNoSQLデータベースサービス |
2.結論となるサービス構成
3.各サービスにおけるログ出力設定とログ内容
(1)Amazon Route53
注意点としてRoute53のログをCloudWtachLogsに送付する場合は、
バージニア北部リージョンでの確認となる
取得できるログの種類
- DNSクエリログ
- 概要:Route53が応答したDNSクエリに関する情報を記録
- 記録情報:ログには、クエリ元IPアドレス、クエリの種類、クエリ対象のドメイン名、Route 53の応答などが含まれる
- 用途:トラフィック分析/監視など
ログの出力先
- DNSクエリログ
- 出力先:CloudWatchLogs
ログ出力設定方法
ログを出力したいRoute53ホストゾーンから「クエリログの設定」を押下
出力先ロググループを選択or新しいロググループ名を入力。
「アクセス許可を付与」を押下する。
※アクセス許可とはクエリログをCloudwatchLogsに出力するための、
Cloudwatchlogs側のリソースポリシー
「バージニア北部」リージョンのCloudWatchLogsロググループが作成され、
ログが出力されていることを確認
念のため「アクセス許可を付与」で設定した、
CloudWatchLogsリソースポリシーを確認
※GUIでは確認できないため、CloudShellより以下コマンドを実行
$ aws logs describe-resource-policies
{
"resourcePolicies": [
{
"policyName": "AWSServiceRoleForRoute53",
"policyDocument":※内容は割愛
ログ内容
- DNSクエリログ
以下ログファイルの1行分となる。
※一部情報をマスク
1.0 2024-04-05T23:35:37Z Z07769365M0YJ16XXXXX test.click A NOERROR UDP HKG62-C2 1xx.xx.xxx.1 -
半角スペース区切りで項目が列挙されているので、どのような項目があるのか確認してみました。
1.0[クエリログのバージョン番号。特に考慮不要]
2024-04-05T23:35:37Z[クエリが行われた日時(UTC)]
Z07769365M0YJ16XXXXX[クエリが発生したRoute 53ホストゾーンのID]
test.click[リクエストで指定されたドメインまたはサブドメイン]
A[リクエストで指定された DNS レコードタイプ]
NOERROR[DNS クエリに応答して Route 53 が返した DNS レスポンスコード(NOERROR(成功)、NXDOMAIN(ドメインが存在しない))]
UDP[クエリの送信に使用されたプロトコル (TCP または UDP)]
HKG62-C2[]
1xx.xxx.xxx.1[Route 53 にリクエストを送信したクライアントIP。ただし、ISP(インターネットサービスプロバイダー)のDNS機能がもつIPアドレスに変換されるため、クライアントが所属しているサブネット帯の特定まで]
-[リクエストを発信したクライアントの IP アドレスの一部 (DNS リゾルバーから取得できる場合)。]
(2)Amazon CloudFront
取得できるログの種類
-
標準ログ(アクセスログ):
- 概要:リクエストに関する詳細な情報であり、アクセスログとも呼ばれている
- 記録情報:リクエストの日時、リクエストされたオブジェクト、リクエストの種類(GET、HEAD、POSTなど)、リクエストの送信元IPアドレス、レスポンスのステータスコード、転送されたデータ量などが含まれます。
- 用途:トラフィック分析、パフォーマンスの最適化、セキュリティ監査など
-
リアルタイムログ:
- 概要:リクエストに関する情報をリアルタイムで取得可能
- 記録情報:標準ログと取得できるログは似ており、差分は後述
- 用途:リアルタイムのモニタリング、異常検知、セキュリティ監査など
標準ログとリアルタイムログで取得できる内容の違い
基本的に標準ログで確認できるログはリアルタイムログでも確認が可能。
リアルタイムログでのみ確認ができる情報は以下の通りとなり、私見だが取得必須なログはない。
項目名 | 内容 |
---|---|
c-ip-version | リクエストの IP バージョン(ipv4 |
c-country | ビューワーの IP アドレスによって決定される |
cs-accept-encoding | ビューワーリクエスト内の accept-encoding ヘッダーの値 |
cs-accept | ビューワーリクエスト内の accept ヘッダーの値 |
cache-behavior-path-pattern | ビューワーリクエストに一致したキャッシュ動作を識別するパスパターン |
cs-headers | ビューワーリクエスト内の HTTP ヘッダー (名前と値) |
cs-header-names | ビューワーリクエスト内の HTTP ヘッダーの名前 |
cs-headers-count | ビューワーリクエスト内の HTTP ヘッダーの数 |
primary-distribution-id | 継続的デプロイが有効になっている場合 |
primary-distribution-dns-name | 継続的デプロイが有効になっている場合 |
origin-fbl | CloudFront とオリジンの間の最初のバイトレイテンシーの秒数 |
origin-lbl | CloudFront とオリジン間の最後のバイトレイテンシーの秒数 |
asn | ビューワーの AS 番号 (asn) |
ログの出力先
- 標準ログ(アクセスログ)
- S3
- リアルタイムログ:
- KinesisDataStream→KinesisDatafirehose→S3
ログ出力設定方法
標準ログ(アクセスログ):
CloudFront のディストリビューションから設定「編集」を押下
標準ログ記録「オン」を選択し、出力先S3バケットを選択。
※バケット指定時にACLの変更が必要になる。
※ACLとは、バケットに追加された新しいオブジェクトの所有権ルールになる。
現在はバケットの所有者が全てのオブジェクト所有権を持つが、
ACLを有効にすることでCloudFrontがログファイルの所有権を保持することになる
リアルタイムログ
ログ出力方法:「KinesisDataStream」→「Datafirehose」→「S3」
標準ログと異なり複数サービスの組み合わせとなる。
KinesisDataStream
KinesiDataStreamに設定を入力して、「データストリームの作成」を押下
※設定はデフォルトでOK
KinesisDataFirehose
「ソース」にKinesisDataStreamを設定し、作成したDataStream情報を入力。
「送信先に」S3を設定
「S3バケット」に出力先S3を設定
「S3 バケットプレフィックス」を必要に応じて設定
CloudFront
「エンドポイント名」に先ほど作成したDataStream情報を入力
「フィールド」に取得したい項目を設定
リアルタイム設定から「設定を作成」を押下
ログ内容
標準ログ(アクセスログ)
以下がログファイルの1行分です。
※一部情報をマスク
#Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host) cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query cs(Cookie) x-edge-result-type x-edge-request-id x-host-header cs-protocol cs-bytes time-taken x-forwarded-for ssl-protocol ssl-cipher x-edge-response-result-type cs-protocol-version fle-status fle-encrypted-fields c-port time-to-first-byte x-edge-detailed-result-type sc-content-type sc-content-len sc-range-start sc-range-end
2024-04-06 23:47:45 NRT12-P2 3132 103.5.xxx.xxx GET xxxxx.cloudfront.net / 200 - Mozilla/5.0%20(Windows※略 - - RefreshHit hD0jK6c6IFAg_tClcYGooHVXsQjgbRff4bQpldlEsjqdsx-cnx3zxQ== xxxxx.cloudfront.net https 500 0.056 - TLSv1.3 TLS_AES_128_GCM_SHA256 RefreshHit HTTP/2.0 - - 65472 0.056 RefreshHit text/html - - -
半角スペース区切りで項目が列挙されているので、どのような項目があるのか確認してみました。
2024-04-06[イベントが発生した日付]
23:47:45[CloudFront サーバーがリクエストへの応答を完了した時刻 (UTC)]
NRT12-P2[リクエストを処理したエッジロケーション]
3132[サーバーがリクエストに応じてビューワーに送信したデータ容量]
103.5.xxx.xxx[リクエスト元のビューワーの IP アドレス※HTTPプロキシやLBを使用している場合そのIPが入力される]
GET[ビューワーから受信した HTTP リクエストメソッド]
xxxxx.cloudfront.net[CloudFront ディストリビューションドメイン名]
/[ビューワーがリクエストしたリクエストパス]
200[HTTP ステータスコード]
-[リクエスト内の Referer ヘッダーの値※(今回はCloudfrontのDNS名でリクエストしたため無し。いずれかのサイト等を経由している場合はそのサイト情報)]
Mozilla/5.0%20(Windows※略[リクエスト内の User-Agent ヘッダーの値。どのブラウザからのアクセスか記載]
-[リクエスト URL のクエリ文字列(今回はCloudfrontのDNS名でリクエストしたため無し)]
-[名前と値のペアおよび関連属性を含む、リクエスト内の Cookie ヘッダー(今回はCookieヘッダ取得設定を有効にしていないため無し)]
RefreshHit[ユーザに対するCloudFrontが行ったレスポンスの分類。RefreshHitの場合、キャッシュ内でオブジェクトを検出したが、オブジェクト有効期限が切れていたため、再度オリジンへリクエストを送付した]
hD0jK6c6IFAg_tClcYGooHVXsQjgbRff4bQpldlEsjqdsx-cnx3zxQ==[リクエストを一意に識別する文字列]
xxxxx.cloudfront.net[ビューワーが、このリクエストの Host ヘッダーに追加した値。CloudFront ドメイン名を利用していればドメイン名、代替ドメイン名(DNS名)を使用していればDNS名が入る]
https[リクエストのプロトコル]
500[ビューワーがリクエストに含めたデータ容量]
0.056[ビューワーのリクエストを受信してから最後のレスポンスまでの時間]
-[HTTP プロキシまたはロードバランサーを使用してリクエストを送信した場合にリクエスト元のビューワーの IP アドレスが記載される(今回はドメイン名でリクエストしたため無し)]
TLSv1.3[リクエストが HTTPS を使用した場合のプロトコル情報]
TLS_AES_128_GCM_SHA256[リクエストが HTTPS を使用した場合のビューワーとサーバー間におけるSSL/TLS 暗号]
RefreshHit[ユーザにレスポンスを返す直前のレスポンス分類]
HTTP/2.0[リクエストで指定した HTTP バージョン]
-[フィールドレベル暗号化がディストリビューション用に設定されている場合、リクエストの処理状態を示すコードが記載(今回はフィールドレベルの暗号化をしていないため無し)]
-[サーバーが暗号化してオリジンに転送したフィールドレベル暗号化フィールドの数(今回はフィールドレベルの暗号化をしていないため無し)]
65472[ユーザーからのリクエストのポート番号。]
0.056[要求を受信してから応答の最初のバイトを書き込むまでの秒数]
RefreshHit[特定の場合を除き。x-edge-result-type フィールドと同じ値]
text/html[レスポンスの HTTP Content-Type ヘッダーの値]
-[レスポンスの HTTP Content-Length ヘッダーの値]
-[レスポンスに HTTP Content-Range ヘッダーが含まれている場合、このフィールドには範囲の開始値]
-[レスポンスに HTTP Content-Range ヘッダーが含まれている場合、このフィールドには範囲の終了値]
ログの内容については、以下を参考
リアルタイムログ:
以下がログファイルの1行分です。
※標準ログで取得できないログ情報のみ対象とする
IPv4 JP gzip,%20deflate,%20br,%20zstd image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 * host:{ドメイン名}※略 host※略 12 E3425xxxxxx xxxxx.cloudfront.net - - 131160
半角スペース区切りで項目が列挙されているので、どのような項目があるのか確認してみました。
IPv4[c-ip-version:リクエストの IP バージョン]
JP[c-country:ビューワーの IP アドレスの国コード]
gzip,%20deflate,%20br,%20zstd[cs-accept-encoding:ビューワーリクエスト内の Accept-Encoding ヘッダーの値]
image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8[cs-accept:ビューワーリクエスト内の Accept ヘッダー値]
*[cache-behavior-path-pattern:ビューワーリクエストに一致したキャッシュ動作を識別するパスパターン]
host:※略[cs-headers:ビューワーリクエスト内の HTTP ヘッダー]
host%※略[cs-header-names:ビューワーリクエスト内の HTTP ヘッダーの名前]
12[cs-headers-count:ビューワーリクエスト内の HTTP ヘッダーの数]
E3425xxxxxx[primary-distribution-id:継続的デプロイが有効になっているのであればディストリビューションID]
xxxxx.cloudfront.net[primary-distribution-dns-name:継続的デプロイが有効になっている場合ディストリビューションドメイン名]
-[origin-fbl:CloudFront とオリジンの間の最初のバイトレイテンシーの秒数]
-[origin-lbl:CloudFront とオリジン間の最後のバイトレイテンシーの秒数]
131160[ビューワーの AS 番号 (ASN)]
ログの内容については以下を参考
(3)Amazon S3
取得できるログの種類
- S3アクセスログ
- 概要:Amazon S3 バケットに対するリクエストの詳細
- ログ情報:送信先/元、リクエスト情報
- 用途:アクセス監査
- CloudTrailオブジェクトログ
- 概要:S3の操作APIログを、オブジェクト単位で記録する。
- ログ情報:オブジェクトに対するAPI情報
- 用途:内部の運用にてどのIAMユーザーがどのオブジェクトをどう操作したのかを記録
ログの出力先
- S3アクセスログ
- 出力先:静的サイト格納S3とは別のS3
- CloudTrailオブジェクトログ
- 出力先:CloudTrailと同様のS3
ログ出力設定方法
S3アクセスログ
アクセスログの送信先S3を作成し、バケットポリシーを設定。
※暗号化キーはSSE-S3を指定すること
アクセスログの送信先として各暗号化キーの利用可否はそのS3暗号化ちょっと待って(SSE-S3とSSE-KMSの違いと注意点)参照
■設定するバケットポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "logging.s3.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::{アクセスログ格納先バケット名}/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "{自身のアカウントID}"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:::{アクセスログ出力元バケット名}"
}
}
}
]
}
S3のプロパティからサーバーアクセスのログ記録の「編集」を押下
アクセスログの送信先S3を記入し、「変更の保存」を押下
CloudTrailオブジェクトログ
S3コンソールからAWS CloudTrail データイベントの「Cloudtrailで設定する」を押下
取得対象とする任意のイベントとログ取得対象バケットを選択し、
「次へ」を押下
ログ内容
S3アクセスログ
ログ格納先S3のファイルを確認したところ、
以下形式のログが格納されている。
461e15b3a022a8af3e9f0f63f315746c3f7b80c84bf0f2b89c370af47b96db7b stgxxxxxxx [09/Apr/2024:05:22:11 +0000] 10.0.xxx.xxx arn:aws:sts::xxxxx:assumed-role/codebuild-rab-stg-Build-service-role/AWSCodeBuild-378c9bed-fd31-4f42-9b0b-fdb79c69303c Z4FVD07S6BJ3Q9KX REST.PUT.OBJECT 00_img/recip.png "PUT /00_img/recip.png HTTP/1.1" 200 - - 1725086 178 81 "-" "aws-cli/2.15.30 Python/3.11.8 Linux/4.14.291-218.527.amzn2.x86_64 exec-env/AWS_ECS_EC2 exe/x86_64.amzn.2023 prompt/off command/s3.sync" - xxxxxxxxxxxx/xxxxxxxxxxxx= SigV4 ECDHE-RSA-AES128-GCM-SHA256 AuthHeader rab-stg-s3-xxxxx.xxxxxx.amazonaws.com TLSv1.2 - -
各項目の説明については以下リンクを参照
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/LogFormat.html
(4)API Gateway
取得できるログの種類
- 実行ログ
- 概要:APIGatewayに対するAPI コールのログ
- ログ情報:エラーや実行のトレース (リクエストやレスポンスのパラメータ値やペイロードなど)情報
- 用途:リクエスト監査/API へのクライアントのアクセスに関連する問題のデバッグ
- アクセスログ:
- 概要:APIGatewayに対するアクセスログ
- ログ情報:APIGatewayにアクセスしたユーザーとそのアクセス/リクエスト情報が記録
- 用途:リクエスト監査
ログの出力先
- 実行ログ
- CloudWatchLogs
- アクセスログ:
- CloudWatchLogs
ログ出力設定方法
実行ログ
APIGateway用IAMロールの作成
「マネージドポリシー:AmazonAPIGatewayPushToCloudWatchLogs」と以下信頼関係を持つIAMポリシーを作成
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
APIGatewayの設定
APIGatewayコンソールから、
左ペインの「設定」より「ログ記録-編集」を押下し先ほど作成したロールを選択
※注意としてAPIGatewayアカウント単位でのロール設定になるため、
必要に応じてポリシーの作成を検討すること
APIGatewayコンソールから、ログ出力したいAPIを選択
その後、左ペインよりステージを選択する
ログとトレースを編集からCloudwatchログよりログレベルを選択する
「変更を保存」を押下することで、
CloudwatchLogsへ自動的に出力される。
アクセスログ
APIGateway用IAMロールの作成
実行ログと同様につき割愛
APIGatewayの設定
IAMロールの付与については、実行ログと同様につき割愛
APIGatewayコンソールより、ログを出力したいAPIを選択
その後、左ペインよりステージを選択する
ログとトレースを編集からカスタムのアクセスログを有効化
「アクセスログの送信先 ARN」と「ログの形式」を記載し、「変更を保存」を押下する
■設定したアクセスログ
{ "requestId":"$context.requestId", "ip": "$context.identity.sourceIp", "caller":"$context.identity.caller", "user":"$context.identity.user","requestTime":"$context.requestTime", "httpMethod":"$context.httpMethod","resourcePath":"$context.resourcePath", "status":"$context.status","responseLatency":"$context.responseLatency","errorMessage": "$context.error.message","errorMessageDetail": "$context.error.validationErrorString","stage":"$context.stage", "protocol":"$context.protocol", "responseLength":"$context.responseLength" }
■アクセスログ参考先
ログ内容
実行ログ
CloudWatchLogsのロググループ名「API-Gateway-Execution-Logs_{API ID}/{ステージ名}」を確認
本ログではリクエストとレスポンス情報を確認できる。
ログの内容については以下記事が詳細を解説してくれているので参照
アクセスログ
出力設定時に指定したCloudwatchLogグループに以下にようなログが出力
{
"requestId": "70de46bf-2ff4-432a-af54-89c4b5cdcb44",
"ip": "223.135.xxx.xxx",
"caller": "-",
"user": "-",
"requestTime": "09/Apr/2024:06:04:43 +0000",
"httpMethod": "GET",
"resourcePath": "/stg-xxx",
"status": "200",
"protocol": "HTTP/1.1",
"responseLength": "6834",
"responseLatency": "872",
"errorMessageDetail": "-",
"stage": "test"
}
上記ログは出力設定時に項目を指定しており、
実ログを元に照らし合わせてみると以下の通りです。
requestId: "70de46bf-2ff4-432a-af54-89c4b5cdcb44"[API Gateway が生成する一意のリクエスト ID]
ip: "223.135.xxx.xxx"[接続元IP アドレス]
caller: "-"[リクエストに署名した発信者のプリンシパル ID。IAM 認証を使用するリソースでサポート(今回はIAM認証無し)]
user: "-"[リソースアクセスに対して許可されるユーザーのプリンシパル識別子。IAM 認証を使用するリソースでサポート(今回はIAM認証無し)]
requestTime: "09/Apr/2024:06:04:43 +0000"[APIGatewayがリクエストを受けた時間]
httpMethod: "GET"[使用される HTTP メソッド]
resourcePath: "/stg-xxx"[APIGatewayに設定しているリソースへのパス]
status: "200"[HTTPステータスコード]
protocol: "HTTP/1.1"[リクエストプロトコル]
responseLength: "6834"[レスポンスペイロードの長さ (バイト単位)]
responseLatency: "872"[ レスポンスレイテンシー (ミリ秒)]
stage: "test"[API リクエストのデプロイステージ]
}
(5)AWS Lambda
取得できるログの種類
-
関数ログ(Function Logs):
- 概要:Lambda関数の組み込みロガーにより生成されるログ
printやconsole.logなどの標準出力ステートメントや、言語固有のロギングライブラリを使用して生成 - ログ情報:関数の実行中に生成されたメッセージ、デバッグ情報、エラーメッセージ等
- 用途:関数の処理状況モニタリング(ユーザ主体で取得ログ情報をコードに設定)
- 備考:関数ログは、Lambda関数のコードによって制御され、開発者が決定したログ出力が表示
- 概要:Lambda関数の組み込みロガーにより生成されるログ
-
Lambdaログ
- 概要:Lambdaサービス自体によって生成される実行ログ
- ログ情報:関数の開始、終了、エラー、タイムアウト、リクエストID、実行時間、
メモリ使用量、課金時間など、関数の実行に関するメタデータ - 用途:関数の処理結果をモニタリング
- 備考:Lambda関数のコードとは独立して生成され、開発者が直接制御することはできない
ログの出力先
- 関数ログ(Function Logs)
- CloudWatchLogs
- Lambdaログ
- CloudWatchLogs
ログ出力設定方法
関数ログ(Function Logs)
Lambdaコンソールから、ログ出力対象となるLambdaを選択
「設定」より、「モニタリングおよび運用ツール」からロギング編集の「編集」を押下
Lambdaログ
Lambdaログは関数内にログ調査パッケージのインポートをすることで、
出力設定を記述することができます。
サンプルコードとしては以下の通りです。
import json
import logging
import traceback
# モジュールごと(pythonファイルごと)にログ出力するloggerインスタンス作成
logger = logging.getLogger(__name__)
# ログレベル[INFO]を設定
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
try:
logger.info("process start")
logger.debug("debug log")
logger.info("info log")
logger.warn("warn log")
except Exception as e:
logger.error(e)
traceback.print_exc()
raise e
logging
正常動作時でも処理の箇所がわかるように設定。
また、正常時にはログレベルを低く(logger.info)とすることで、
ログ確認時や監視ツールに検出されないように設定する。
異常時にはログレベルを低く(logger.error)設定することで、
ログ確認時の強調や監視ツールに検出するように設定する。
traceback
traceback モジュールの print_exc()関数を使用して、例外に関する詳細な情報をスタックトレースとして標準エラー出力に表示します。これにより、例外が発生した場所や例外の原因がわかりやすくなります。
なお、以下のように設定することで、
traceback 以下の内容が全てターミナルに出力することができます。
except Exception as e:
traceback.print_exc()
つまり、関数の場合は「logger.error(e)」として簡潔なログメッセージを出力させた後、
「traceback.print_exc()」で例外オブジェクトの内容全文を出力させています。
ログ内容
以下のようにデフォルト設定では同一ロググループに出力される
また、処理の最後には以下のようなリクエストID、実行時間、メモリ使用量、
課金時間などのメタデータログが出力される
REPORT RequestId: a0b0cfe4-faa1-44ab-be91-197aac1de112 Duration: 5307.92 ms Billed Duration: 5308 ms Memory Size: 256 MB Max Memory Used: 98 MB Init Duration: 683.16 ms
(6)Amazon Dynamodb
取得できるログの種類
- CloudTrailログ
- 概要:DynamoDBに対するAPIコールを記録。テーブルに対するAmazon DynamoDB のアイテムレベルの API アクティビティを記録(PutItem、DeleteItem、UpdateItem API オペレーションなど)
- ログ情報:APIコールのレベルでデータを記録。Item単位のコールも記録可能
- 用途:監査
ログ出力設定方法
CloudTrailコンソール左ペイン証跡を押下し、「証跡の作成」を押下
イベントタイプ「データイベント」を選択
データイベントソース「DyanmoDB」を選択
個々のテーブルの選択にて任意のテーブルを設定「読み取り」「書き込み」を有効化する
設定内容を確認し、「証跡の作成」を押下
ログ内容
ログ出力設定にて指定したCloudwatchLogsを確認すると、
テーブル単位のアクションログを確認できる。
以下のような形式であり、
DynamoDBに格納されているデータに対するアクションを確認することが可能になる。
以下がログファイルです。
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "xxxx:xxxxx",
"arn": "xxxx",
"accountId": "xxxx",
"accessKeyId": "xxx",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAYPRLU2ZCF5SCKA5SV",
"arn": "arn:aws:iam::xxxxxx",
"accountId": "xxx",
"userName": "rab-xxxx"
},
"attributes": {
"creationDate": "2024-04-09T13:45:40Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-04-09T13:45:44Z",
"eventSource": "dynamodb.amazonaws.com",
"eventName": "DeleteItem",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "43.206.xxx.xxx",
"userAgent": "Boto3/1.34.42 md/Botocore#1.34.42 ua/2.0 os/linux#5.10.210-220.852.amzn2.x86_64 md/arch#x86_64 lang/python#3.12.1 md/pyimpl#CPython exec-env/AWS_Lambda_python3.12 cfg/retry-mode#legacy Botocore/1.34.42 Resource",
"requestParameters": {
"tableName": "xxx-xxx-xxx",
"key": {
"RecipeID": "ingredientbda5f971-0b65-4f3d-b9f8-aac5ff8288e8_2"
}
},
"responseElements": null,
"requestID": "B7O4O1N6NC24D384QPMQTJSO1VVV4KQNSO5AEMVJF66Q9ASUAAJG",
"eventID": "c075c7fa-09e4-44ca-9941-5756883f24bc",
"readOnly": false,
"resources": [
{
"accountId": "xxxxx",
"type": "AWS::DynamoDB::Table",
"ARN": "arn:aws:dynamodb:ap-northeast-1:xxxxx"
}
],
"eventType": "AwsApiCall",
"apiVersion": "2012-08-10",
"managementEvent": false,
"recipientAccountId": "xxxxx",
"eventCategory": "Data",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_256_GCM_SHA384",
"clientProvidedHostHeader": "dynamodb.ap-northeast-1.amazonaws.com"
}
}
どのような項目があるのか確認してみました。
eventVersion: "1.08"[CloudTrailイベントのバージョン]
userIdentity: {}[リクエストを行ったユーザーまたはロールの詳細]
eventTime: "2024-04-09T13:45:44Z"[イベントの発生日時(UTC)]
eventSource: "dynamodb.amazonaws.com"[イベントのソース]
eventName: "DeleteItem"[実行されたDynamoDB APIオペレーション]
awsRegion: "ap-northeast-1"[DyanamoDBが所属しているリージョン]
sourceIPAddress: "43.206.xxx.xxx"[送信元IP]
userAgent: "Boto3/1.34.42 md/Botocore~[リクエストに使用されたユーザーエージェント]
requestParameters:{}[ynamoDB APIリクエストのパラメータ(例:テーブル名、項目の詳細など)]
responseElements: null[DynamoDB APIレスポンスの詳細(通常はnull)]
requestID: "B7O4O1N6NC24D384QPMQTJSO1VVV4KQNSO5AEMVJF66Q9ASUAAJG"[リクエストの一意の識別子]
eventID: "c075c7fa-09e4-44ca-9941-5756883f24bc"[イベントの一意の識別子]
readOnly: false[操作が読み取り専用かどうかを示すブール値]
resources:{}[操作の対象となったDynamoDBテーブルの詳細]
eventType: "AwsApiCall"[イベントのタイプ(常にAwsApiCall)]
apiVersion: "2012-08-10"[使用されたDynamoDB APIのバージョン]
managementEvent: false[管理イベントかどうかを示すブール値]
recipientAccountId: "xxxxx"[イベントが発生したAWSアカウントのID]
eventCategory: "Data"[イベントのカテゴリ(DataまたはManagement)]
tlsDetails: {}[TLS (Transport Layer Security) の詳細情報]
最後に
よくあるサーバ構成におけるログ出力方法とログ内容を列挙してみました。
同様構成のログ出力に悩まれている方の助けになれば幸いです。
その他参考元