← AWSサービスの内部原理 コース
70. ログは追記専用のストリームの束である — Lambdaの標準出力がロググループに届くまで
関数のコードが print するだけで、なぜCloudWatchのコンソールにログが並ぶのか。その1行が「ログイベント → ログストリーム → ロググループ」という3階層をどう昇っていくのか、そして途中で失敗する最頻トラブルまでを図で追っていきます。
① ログイベントは「時刻+メッセージ」だけの1レコード
ログイベント1件のアクティビティの記録
これ以外の構造は持たない
timestampイベントが起きた時刻
message生の本文(UTF-8エンコード必須)
UTF-8バイト列「level=ERROR」等の意味づけも messageの中の文字列にすぎない
- 公式定義 ―「The log event record that CloudWatch Logs understands contains two properties: the timestamp of when the event occurred, and the raw event message. Event messages must be UTF-8 encoded.」
ログイベントは「いつ・何が」の2要素だけの薄いレコード。JSON構造化ログも、CloudWatchにとっては1本のUTF-8文字列であり、意味の解釈は後段(メトリクスフィルタ等)の仕事です。
② ログストリームは「同じ発生源」からのイベントの時系列
発生源Aホスト1のApache
発生源Bホスト2のApache
発生源CLambda実行環境#3
末尾に足すだけ
ストリーム1eventが時刻順に伸びる
ストリーム2eventが時刻順に伸びる
ストリーム3eventが時刻順に伸びる
append-only追記専用の時系列構造
順序が意味を持つのは同一ストリーム内だけ- 公式定義 ―「A log stream is a sequence of log events that share the same source. (…) For example, a log stream may be associated with an Apache access log on a specific host.」
ストリームは末尾に足すだけの追記専用構造。DynamoDB Streams・Kinesisで学んだ「追記しかしないから速く、順序が保てる」という原理が、人間が読むためのログにもそのまま使われています。ストリームを分けるのは発生源を分けるためです。
③ ロググループは保持・監視・アクセス制御を共有する管理単位
ロググループ例: MyWebsite.com/Apache/access_log
配下の全ストリームに一律で適用
保持期間retention
監視metric filter 等
アクセス制御グループ単位で制御
ストリームホスト1
ストリームホスト2
ストリームホスト3
所属できる本数は無制限- 公式定義 ―「Log groups define groups of log streams that share the same retention, monitoring, and access control settings.」「There is no limit on the number of log streams that can belong to one log group.」
- アクセス制御もグループ単位 ―「Access to log streams is controlled at the log group level, because of the hierarchical relation between log groups and log streams.」(ロググループ操作ガイドおよびIAMアクセス制御概要ページに記載)
メトリクスフィルタも保持設定もグループに割り当てられ、配下の全ストリームに適用されます。ストリーム数に上限はないので、「発生源ごとにストリーム、運用ポリシーごとにグループ」という分け方が自然に決まります。
④ 保持期間はグループ単位。期限切れは自動で消える
新規ロググループ
保持期間を設定すると
Never Expireデフォルト=無期限に貯まる
期限切れイベントは
1日〜3653日PutRetentionPolicy APIで指定
無期限に戻すには DeleteRetentionPolicy自動削除まず削除マーク → 実削除まで通常は最大72時間(まれにそれ以上)
- 公式 ―「By default, log data is stored in CloudWatch Logs indefinitely.」コンソールの初期表示は「Never Expire」。「Expired log events get deleted automatically.」ただし即時ではなく「It typically takes up to 72 hours after that before log events are deleted, but in rare situations might take longer.」
- 削除マークが付いた時点でアーカイブストレージ課金の対象外になる。
- retentionInDays の許容値は 1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1096, 1827, 2192, 2557, 2922, 3288, 3653(最小1日・最大10年)。メトリクスの固定15ヶ月保持と違い、ログは1日〜無期限の範囲で選択できる。
保持設定はグループに割り当てられ、期限切れイベントは自動削除されます。デフォルトが「無期限」なので、コスト管理の観点では明示的に保持期間を切ることが実務上の第一歩になります。
⑤ Lambdaの経路:標準出力に書くだけで /aws/lambda/{関数名} に届く
関数コードprint(...) / console.log(...)
CloudWatch Logs へ送信
Lambda(胴元)実行環境というプロセスの出力を自動でキャプチャ
配下に生成
ロググループ/aws/lambda/{関数名}(デフォルトの宛先)
反映まで5〜10分かかることがあるログストリーム実行環境ごとに1本ずつ
- 公式 ―「By default, Lambda automatically captures logs for all function invocations and sends them to CloudWatch Logs, provided your function's execution role has the necessary permissions. These logs are, by default, stored in a log group named /aws/lambda/{function-name}.」「It may take 5 to 10 minutes for logs to show up after a function invocation.」
- ストリームが実行環境単位である点も公式明記 ―「Each instance of a Lambda function has a dedicated log stream. (…) Each time a new execution environment is created in response to an invocation, this generates a new log stream.」ストリーム名は YYYY/MM/DD[Function version][Execution environment GUID] 形式。②の「発生源=Lambdaの特定の実行環境」がここに対応。
Lambda編で見た「実行環境=分離されたプロセス」の標準出力を、胴元がそのまま回収してロググループに流している。だから開発者はログ送信コードを書かずに済み、宛先も既定で /aws/lambda/{関数名} に決まります。
⑥ 「ログが出ない」の最頻原因:実行ロールの3権限
CreateLogGroupロググループを作る
CreateLogStreamストリームを作る
PutLogEventsイベントを書き込む
権限が欠けると
マネージドポリシーAWSLambdaBasicExecutionRole
関数は正常に動く戻り値も返る
ログだけ出ないPutLogEvents 等が拒否される
コード疑いに時間を溶かす典型トラブル- 公式 ―実行ロールに必要な権限は logs:CreateLogGroup / logs:CreateLogStream / logs:PutLogEvents の3つ。「You can add these CloudWatch Logs permissions using the AWSLambdaBasicExecutionRole AWS managed policy provided by Lambda.」
- 認証暗号編のポリシー評価(明示的Denyがなくても、Allowが無ければ暗黙Deny)がそのまま効く場面。
関数の実行成功とログ出力は別々の権限で守られています。ログが出ないときにまずコードを疑うと沼にはまる ― 実務では実行ロールに AWSLambdaBasicExecutionRole が付いているかを先に確認するのが定石です。
⑦ ロググループには2つのログクラス
グループ作成時ログクラスを選ぶ
作成後にクラスは変更できない用途で選び分け
Standardフル機能・頻繁アクセス向け
Infrequent Access取り込み価格/GBが安い・機能制限つき
リアルタイム監視Live Tail・メトリクスフィルタ・サブスクリプション・Embedded metrics すべて ✓
事後の掘り返し上記はすべて ✗ ― ad-hocクエリ/事後分析向け
- 公式 ―「The Infrequent Access log class is a lower-cost option (…) It supports a subset of the Standard log class capabilities.」IAが非対応の主な機能:メトリクスフィルタ、サブスクリプションフィルタ、Live Tail、Embedded metrics format、異常検知など(いずれも公式のSupported features表で「No」)。
- IAでは GetLogEvents / FilterLogEvents APIも非対応で、閲覧はLogs Insights経由になる。
- 料金差は取り込みのみ ―「For charges, the Standard and Infrequent Access log classes differ in ingestion costs only. Storage charges and CloudWatch Logs Insights charges are the same in each log class.」「After a log group is created, its log class can't be changed.」
IAは「安い代わりにリアルタイム監視系の機能を削った」クラス。監視やアラームを回したいログはStandard、事後の掘り返し用途はIA、と用途で選び分けます。作成後は変更できない点が実務上の要注意ポイントです。