【PR】この記事にはA8.netのアフィリエイト広告を含みます。
先に結論：現在のXServer VPSは、Dockerログ対策が何もない状態ではありません。実機では既定driverがlocal、上限が10MB×5世代でした。同じ16,487,578バイトのログを出すと、既定localは7,052,290バイト、無制限json-fileは17,632,619バイト、json-file 1MB×3は2,624,367バイトでした。容量は抑えられますが古いログも消えるため、判定は一部解決です。
Dockerログを放置するとVPSのディスクが埋まる？
設定次第では埋まります。Docker公式のlogging driver設定では、一般的なDocker既定のjson-fileは自動rotationなしで、ログ量の多いcontainerではディスク枯渇につながると説明されています。ZennのVPS初期設定記事でも、max-sizeとmax-fileを設定する例が紹介されています。
ただし、一般論をこのXServer VPSへそのまま当てはめるのは危険です。実機の設定を確認すると、既定はjson-fileではなくlocalでした。
XServer VPSのDockerログ設定は実際どうなっていた？
{
"live-restore": true,
"log-driver": "local",
"log-opts": {
"max-size": "10m",
"max-file": "5"
}
}docker infoでもLogging Driver: localを確認しました。Docker公式では、local driverはディスク使用と性能を意識した内部形式で保存し、rotationと圧縮を利用できると説明されています。
つまり、このVPSはDockerを入れただけの標準状態とは異なり、ログ肥大化への基本対策がすでに入っていました。
どのようなログ実験をした？
同じ合成ログを3つの一時containerから出しました。1条件16,384行、stdoutは正確に16,487,578バイトです。
各containerはCPU 0.5、RAM 64MiB、networkなし。3条件合計でも生成ログは約49.46MBに限定しました。実験前の空きは約130GiBあり、ディスクを危険な残量まで埋める試験はしていません。
同じ16.49MBのログは何MBで保存された？
| 条件 | host上の保存量 | 無制限json-fileとの差 |
|---|---|---|
| 既定local | 7,052,290 byte | 60.004%小さい |
| 無制限json-file | 17,632,619 byte | 基準 |
| json-file 1m×3 | 2,624,367 byte | 85.116%小さい |
生のstdoutよりjson-fileが大きいのは、各行へstreamやtimestampなどのJSON情報が加わるためです。今回のlocalはrotation済み部分をgzip圧縮し、全ログを取得できる状態のまま約7.05MBに収まりました。
local driverならログは全部読めた？
今回の生成量では全部読めました。docker logsから16,384行、16,487,578バイトを再取得し、最初のsequence 0から最後の16,383まで保持していました。
| local driverのファイル | 容量 |
|---|---|
container.log |
6,945,558 byte |
container.log.1.gz |
106,732 byte |
ただし上限は10MB×5です。ログを出し続ければ、最終的には古い世代から削除されます。「全期間を永久保存できた」という結果ではありません。
json-fileを1MB×3にすると何行残った？
2,437行だけ残りました。全16,384行の14.874%です。保持範囲はsequence 13,947〜16,383で、それ以前の13,947行はdocker logsでも取得できませんでした。
max-sizeとmax-fileはディスク上限を作れます。一方で、AI調査中に最初に起きた認証エラーや料金表示を後から調べたい場合、必要なログまで消える可能性があります。
無制限json-fileはなぜ危ない？
Docker公式のjson-file説明では、max-sizeの初期値は-1、つまりunlimitedです。今回も16,487,578バイトのstdoutが17,632,619バイトの単一JSON logになりました。
今回は1.100秒で終了し、生成量も固定したため障害にはなりませんでした。しかし、同じ速度で常時出力するアプリなら、放置時間に比例して増える設計です。
実験中に発生した問題は？
初回測定では、Docker inspectのLogPathを全driverで取得できると思い込んでいました。json-fileではpathが返りましたが、localでは空でした。scriptが空pathを現在directoryとして扱い、.bashrcなどをログと誤認して4,798バイトと記録しました。
driverがlocalの場合だけcontainer IDから保存位置を特定し、hostファイル、docker logsの行数、byte数、SHA-256を照合するよう修正。3条件を最初から再実行しました。初回値は最終比較には使っていません。
driverが違えば、確認できるpathや保存形式も同じではありません。もっともらしい小さな数字が出ても、取得元を検証する必要がありました。
既存containerにも設定変更は反映される？
自動では反映されません。Docker公式ドキュメントでは、daemonの既定driverやoptionを変更しても、新しく作成されるcontainerが対象で、既存containerは作り直しが必要とされています。
今回はdaemon設定を変更していません。一時container単位で--log-driverと--log-optを指定して比較しました。本番へ適用する場合は、Compose差分を保存し、1サービスずつ再作成してreadyを確認する手順が必要です。
公開中のVPSサービスに影響は出た？
実験前、3条件の各終了後、実験後の5回すべてで公開readyがHTTP 200でした。status=ready、database=ok、artifact_storage=okを維持しています。
3つの一時containerは削除済みです。ルートディスクの実験前後差は49,152バイトでした。これはDocker管理情報や既存service logも含むhost全体の即時値で、実験ログの残存量ではありません。
AI一次情報収集システムではどう設定する？
- Docker stdoutは
localまたは上限付きdriverでdisk使用量を制限。 - 調査job ID、操作、料金、errorはPostgreSQLへ構造化保存。
- スクリーンショットはartifact storageへ保存し、SHA-256をDBへ記録。
- 長期保存が必要なapplication logはVPS外へ転送。
- disk残量、log増加速度、rotation回数を監視。
stdout logを証拠の唯一の保存先にしない構成が重要です。rotationは容量問題を抑えますが、記事に必要な一次情報まで消す可能性があります。
初心者が迷いそうなポイントは？
- Docker一般の既定値と、自分のVPSのdaemon設定は同じとは限らない。
docker infoでdaemon既定、docker inspectでcontainer個別設定を確認する。max-fileはmax-sizeと組み合わせる。- 設定変更は既存containerへ自動適用されない。
- host上のDocker log fileを直接編集しない。
- 小さな上限はディスクを守るが、障害調査に必要な古いログも失う。
よくある質問
XServer VPSのDockerログは無制限だった？
今回確認したVPSでは違います。既定はlocal、max-size 10m、max-file 5でした。
localとjson-fileはどちらが小さかった？
同じ16.49MBの合成ログで、localは約7.05MB、無制限json-fileは約17.63MBでした。今回のデータではlocalが60.004%小さい結果です。
1MB×3ならログは全部残る？
残りませんでした。全16,384行のうち末尾2,437行、14.874%だけ取得できました。
ディスクを100%まで埋めて試した？
試していません。本番VPSを守るため、3条件合計約49.46MBの固定量に限定しました。
daemon.jsonを書き換えた？
書き換えていません。現在値を読み取り、一時containerだけ個別optionを指定しました。
Dockerログによるディスク枯渇の悩みは解決した？
一部解決です。このXServer VPSは既定でlocalと10MB×5世代が設定され、今回の合成ログを無制限json-fileより60.004%小さく保存できました。1MB×3では85.116%削減できましたが、保持行も14.874%まで減りました。容量上限、必要な保持期間、外部保存の3点を一緒に設計する必要があります。
コメント