journalctlの容量確認と削減方法｜disk-usage・vacuum・保存上限
Linuxのsystemd journalが容量を使っているときに、現在の使用量を調べ、削除可能なログと残すべきログを分けて判断するガイドです。いきなり削除せず、取得・保持要件を確認してから整理します。
このページの目的
journalctl --disk-usageで容量を確認し、--vacuum-size・--vacuum-timeの対象と制約、journald.confの保存上限を理解します。
最初にやること
まずjournalctl --disk-usageとdf -h /var/logで現状を記録します。ログが監査・障害調査に必要なら削減せず保持方針を確認します。
エラー調査・ディスク容量不足との違い
journalctlでエラーを調べる
サービス名、起動回、時刻、priorityから障害ログの内容を絞り込みます。
エラー調査へ → 容量不足の障害No space left on deviceの原因を調べる
journal以外も含め、ファイルシステム容量・inode・削除済みファイルを切り分けます。
容量不足の切り分けへ → 容量調査df・du・inodeで使用箇所を調べる
ログ以外も含め、ファイルシステムの使用量・マウント先を調べます。
ディスク調査へ →1. 最短の安全な確認順
--disk-usageはアクティブなjournalとアーカイブ済みjournalの合計を報告します。通常のdfはファイルシステム全体を対象とするため、両者の値を直接一致させる必要はありません。閲覧権限が限られる場合は管理者権限で再確認します。
df -h /run/logは該当ディレクトリが存在する場合だけ実行します。存在しないパスを指定して失敗しても、journalの容量不足を意味しません。
2. journalの保存場所を確認する
| 保存先 | 用途 | 確認時のポイント |
|---|---|---|
/var/log/journal | 永続保存に使う領域 | 再起動後も履歴が残り得る。SystemMaxUse等が関連 |
/run/log/journal | 揮発性の保存領域 | 再起動時に失われ得る。RuntimeMaxUse等が関連 |
Storage=autoなどの設定や環境により、journalの保持場所は変わります。/etc/systemd/journald.confに値がなくても、既定値やdrop-inが有効な場合があるため、主ファイルだけを見て現在の設定を断定しないでください。対応しているsystemdならsystemd-analyze cat-config systemd/journald.confで設定の重なりを確認できます。
3. vacuumで過去ログを整理する
削減コマンドは参照操作ではなく、アーカイブ済みのjournalファイルを削除する操作です。以下は保持方針と影響を確認した後の実行例です。
| コマンド | 削減対象 | 注意点 |
|---|---|---|
--vacuum-size=500M | アーカイブ済みjournalの合計が指定容量以下になるまで古いファイルを整理 | 稼働中のファイルは対象外で、全journal容量500MB以下を保証しない |
--vacuum-time=14d | 指定期間より古いアーカイブ済みjournalを削除 | 14日分のすべてのログが必ず残る設定ではない |
journalctl --list-bootsなどで保持されている履歴を確認し、必要なログの保全が完了するまではvacuumしないでください。診断中に安易にrm -rf /var/log/journalを実行しないでください。4. vacuumしても使用量が減らないとき
journalctl --disk-usageにはアクティブファイルも含まれますが、vacuumは原則アーカイブ済みだけを削減します。表示が500MBを超えたからといって、vacuumが失敗したとは限りません。
公式マニュアルには、アクティブファイルを先にローテーションした後でvacuumする組み合わせも案内されています。こちらも状態変更を伴う操作なので、必要な証跡を退避し、実行中システムへの影響を確認した場合に限ります。
--rotateは現在のjournalファイルをアーカイブし、新しいファイルを開きます。容量減少は実行環境や保存状態に依存し、指定値まで必ず減るわけではありません。5. journald.confで今後の保存容量を管理する
繰り返しjournalが肥大化する場合、毎回vacuumするより、OS・監査方針に合わせた容量制限を検討します。以下は設定内容の一例であり、サーバーへそのまま適用する指示ではありません。
| 設定項目 | 意味 |
|---|---|
SystemMaxUse | 永続保存側のjournal容量の上限方針 |
SystemKeepFree | ファイルシステムに残す空き容量の方針。すでに容量逼迫している場合の挙動に注意 |
RuntimeMaxUse | 揮発性の/run側journalの容量上限方針 |
これらはjournalが使う容量に関する設定です。他のログやアプリデータまで自動で削除する機能ではありません。設定の適用にはjournaldの再起動などが必要になる場合があり、収集中のログや運用監視への影響を確認して計画的に実施してください。
6. 確認結果から次の対応を決める
| 確認結果 | 適切な次の対応 |
|---|---|
| journalだけ大きいがディスクには余裕がある | 保持要件を優先。すぐに消す必要があるとは限らない |
| journalが肥大化し、履歴保持の方針もある | 保存上限・ログ収集・監視を設計。削減前に証跡を保全 |
vacuum後も--disk-usageが高い | アクティブファイルの割合、保存方式、権限、別保存領域を確認 |
| journal以外も大容量・inode不足 | No space left on deviceの切り分けやdf・duの確認へ移る |
| アプリ独自ログがローテーションされない | logrotateの障害調査へ移る |
7. 作業後の確認と再発防止
使用量だけでなく、必要な起動履歴・障害時刻のログが残っているか、journalの書き込みが継続できているか、監視・ログ転送に問題がないかを確認します。保存上限の変更後は、直後だけでなく運用期間を通じて容量推移を観測してください。