Linuxでログが消えた？journalctlの永続化設定とsyslog転送の罠

Linux環境で運用していると、「昨日まで見えていたログが突然消えた」「journalctlで過去の履歴が追えない」といった現象に遭遇することがあります。
特にsystemd環境では従来の/var/log配下のファイルだけを前提にしていると、ログの永続化設定や転送経路の違いに気づかず、原因の切り分けが難しくなりがちです。

本記事では、journalctlの永続化設定（Storage=persistentの有無や/var/log/journalの扱い）、そしてsyslog転送（rsyslogやsyslog-ngへの連携）に潜む典型的な罠について、実務レベルの視点で整理します。
単に「設定が間違っていた」という話ではなく、設計思想の違いが原因でログが消えたように見えるケースも解説します。

例えば、以下のような症状は典型的です。

再起動後にjournalctlの過去ログが消えている
/var/log/messagesには出ているのにjournalctlには残らない
コンテナ環境だけログが保持されない

こうした現象は単一の原因ではなく、journaldのストレージモード、ディスク容量制限、さらにはsyslogデーモンとの二重管理などが複雑に絡み合って発生します。

ログが「消えた」のではなく「どこにあるのか分からなくなっている」ケースも多いため、構造を理解することが重要です。
以降では設定ファイルの具体例とともに、再現性のある形で原因を分解していきます。

Linuxでログが消える理由：journalctlとsyslogの基本構造を理解する
journalctlのログが消えたように見える典型的な原因と誤解
journald永続化設定Storage=persistentと/var/log/journalの正しい理解
ディスク容量制限とジャーナルローテーションが引き起こすログ消失問題
rsyslog・syslog-ng転送設定に潜む二重管理とログ欠落の罠
コンテナ環境でjournalctlログが保持されない理由とDockerの注意点
ログ監視基盤の導入：Grafana LokiやDatadogでの可視化と運用改善
journalctlトラブルシュート手順と設定確認の実践ポイント
まとめ：Linuxログ管理で重要な設計思想と永続化の本質

Linuxでログが消える理由：journalctlとsyslogの基本構造を理解する

Linux環境でログが「消えたように見える」現象を正しく理解するためには、まずログ管理の全体構造を把握する必要があります。
特にsystemdが主流となった現在のディストリビューションでは、従来のsyslogベースの設計と、journaldによるバイナリジャーナル管理が並存している点が重要です。
この二重構造が、混乱の主要因になっています。

Linuxのログは大きく分けると以下の2系統で扱われます。

systemd-journaldによるバイナリログ（journalctlで参照）
rsyslogやsyslog-ngによるテキストログ（/var/log配下）

この2つは似た役割を持ちながらも、保存方式と永続化の思想が異なります。
journaldはメモリ上のリングバッファを基本とし、ディスク永続化は明示的な設定に依存します。
一方syslogはファイルとして即時書き込みされるため、従来の運用者には直感的です。

journaldの基本構造を理解するうえで重要なのは、「ログは必ずディスクに残るわけではない」という点です。
デフォルト設定では、/run/log/journal配下の一時領域に保存され、再起動時に消える構成になっている場合があります。
この挙動を知らないと、「昨日まであったログが消えた」という誤解が発生します。

さらにsyslogとの関係性も重要です。
journaldは単体でログを保持できますが、多くの環境ではrsyslogへ転送され、最終的にテキストファイルとして保存される構成が採用されています。
このとき、転送設定が不完全だと以下のような問題が発生します。

journalには存在するが/var/logに出力されない
rsyslog側でフィルタリングされて欠落する
コンテナ環境でsyslogデーモン自体が存在しない

これらの構成差異が「ログ消失」の誤認を生む主要因です。

また、journaldとsyslogの違いを整理すると理解が進みます。

項目	journald	syslog
保存形式	バイナリ	テキスト
永続化	設定依存	基本的に永続
参照方法	journalctl	cat/less
転送性	rsyslog連携可	他システムへ転送

この違いを理解していない場合、運用者は「どこにログがあるのか」を見失いやすくなります。

特に重要なのは、systemd環境ではjournaldが一次情報源であり、syslogは二次的な転送先に過ぎないという点です。
この構造を前提に設計を理解しないと、ログ欠損の原因分析は困難になります。

したがって「ログが消えた」という現象は、実際には削除ではなく、保存レイヤーや参照経路の違いによる見え方の問題であるケースが大半です。
次章では、この誤解の核心となるjournald永続化設定について具体的に掘り下げていきます。

journalctlのログが消えたように見える典型的な原因と誤解

journalctlを利用している環境で「昨日まで見えていたログが突然消えた」と感じるケースは少なくありません。
しかし実際にはログが物理的に削除されているとは限らず、多くの場合は参照しているストレージ領域や表示条件の違いによって「見えなくなっている」だけです。
この誤解を正しく解消することが、トラブルシュートの第一歩になります。

まず最も頻出する原因は、journaldの永続化設定が有効になっていないケースです。
デフォルトでは多くのディストリビューションにおいて、ログは一時領域である/run/log/journalに保存され、再起動時にクリアされます。
この状態では以下のような現象が発生します。

再起動後に過去ログが完全に消える
journalctl -b -1で前回ブートが参照できない
一時的にしかログが保持されない

この挙動は設計上の仕様であり、障害ではありません。
しかし運用者の期待との乖離が大きいため、最も誤解を生みやすいポイントです。

次に多いのが、フィルタリング条件による非表示問題です。
journalctlは非常に柔軟な検索機能を持つため、意図せず条件が絞られていることがあります。
例えば以下のようなケースです。

特定ユニット指定（-u）による表示制限
ブート番号指定（-b）による対象外ログの除外
時間範囲指定（–since, –until）の誤設定

これにより「存在するログが見えない」状態が発生します。
特にスクリプトやエイリアス経由でjournalctlを実行している場合、暗黙的なフィルタが原因となることもあります。

さらに見落とされやすいのがディスク容量制限による自動削除です。
journaldはデフォルトで以下の制約を持っています。

制約項目	内容	影響
SystemMaxUse	最大ディスク使用量	超過時に古いログ削除
RuntimeMaxUse	メモリ上限	再起動で消失リスク
MaxFileSec	保存期間	古いログの自動破棄

これらの設定により、ディスク逼迫時には古いログから順に削除されるため、ユーザーから見ると「突然消えた」ように見えます。

また、コンテナ環境ではさらに複雑になります。
DockerやKubernetes環境ではjournald自体がホスト依存であったり、ログドライバがjson-fileやfluentdに切り替わっている場合があります。
この場合、journalctlで期待通りのログが見えないのは正常動作です。

# コンテナ内ではjournalctlが空になる例
journalctl -xe

このような環境差異を無視すると、誤った原因分析に繋がります。

加えて、ユーザーが見落としがちなポイントとして「別ホストのログを見ている」というケースもあります。
SSH接続先の切り替えミスや、マルチノード環境での混同は実務でも頻出です。

重要なのは、journalctlのログ消失は多くの場合「削除」ではなく「可視性の問題」であるという点です。
保存領域、フィルタ条件、ストレージ制約、環境差異のいずれかに起因していることがほとんどです。

次のセクションでは、この問題の根本に関わるjournaldの永続化設定とディスク構成について、より具体的に掘り下げていきます。

journald永続化設定Storage=persistentと/var/log/journalの正しい理解

journaldのログが「再起動後に消える」問題を正しく解決するためには、Storage=persistentという設定の意味と、/var/log/journalディレクトリの役割を正確に理解する必要があります。
この2つは密接に関係していますが、混同されやすいポイントでもあります。

まず前提として、systemd-journaldはログの保存先を複数のモードで切り替えます。
代表的なのは以下の3つです。

volatile（メモリのみ）
auto（条件付きで永続化）
persistent（ディスクへ永続化）

このうち問題となるのはautoとvolatileの挙動です。
特にデフォルト状態では、/run/log/journal配下の一時領域のみが使用される場合があり、再起動時にログが消失します。

ここで重要になるのがStorage=persistent設定です。
この設定はjournaldに対して「ディスク上に永続的にログを保存する」ことを明示します。
ただし、この設定だけでは不十分であり、実際には保存先ディレクトリの存在が前提条件となります。

/etc/systemd/journald.conf
[Journal]
Storage=persistent

この設定を有効にしただけでは、/var/log/journalが存在しない場合、journaldは自動的に一時領域へフォールバックする挙動を取ることがあります。
そのため「設定したのにログが残らない」という誤解が発生します。

永続化の正しい構成は以下の通りです。

/var/log/journalディレクトリが存在すること
journald.confでStorage=persistentが有効であること
journaldサービスの再起動またはシステム再起動

特に/var/log/journalの存在は見落とされがちですが、これは単なるディレクトリではなく「永続ログのスイッチ」として機能します。
systemdはこのディレクトリを検出すると、自動的に永続モードを優先します。

また、ファイルシステムの権限も重要です。
journaldは専用のサブディレクトリ（machine-id単位）を作成するため、適切な所有権が必要になります。
これが壊れているとログ書き込みが失敗することがあります。

条件	状態	結果
/var/log/journalなし	Storage=persistent有効	volatile動作にフォールバック
/var/log/journalあり	Storage=auto	自動でpersistent動作
Storage=volatile	ディレクトリ有無問わず	再起動で消失

このように、設定ファイル単体ではなく「ディレクトリの存在＋設定＋システム状態」の三位一体で動作が決まります。

さらに注意すべき点として、クラウドイメージや軽量ディストリビューションでは、意図的に永続化を無効化しているケースがあります。
これはディスクI/O削減やコンテナ前提設計のためですが、運用者が気づかずに利用すると混乱の原因になります。

また、journaldの永続化は単純なファイル書き込みではなく、バイナリジャーナル形式で管理されるため、直接catなどで閲覧することはできません。
この点もsyslogとの大きな違いです。

重要なのは、Storage=persistentは「魔法のスイッチではない」という点です。
あくまでjournaldに対する動作指示であり、基盤となるディレクトリ構造と整合して初めて期待通りに機能します。

次のセクションでは、こうした永続化設計にも関わらず発生するディスク制限やローテーションの問題について、さらに踏み込んで解説していきます。

ディスク容量制限とジャーナルローテーションが引き起こすログ消失問題

journaldを運用する上で見落とされがちな重要要素が、ディスク容量制限とジャーナルローテーションの仕組みです。
Storage=persistentを正しく設定していても、「過去ログが突然消えたように見える」現象が発生する場合、その多くはこの領域の制御に起因しています。

journaldは無制限にログを保存する設計ではなく、明確なリソース制約のもとで動作します。
これはシステム全体の安定性を優先するための設計であり、ログの肥大化によるディスクフルを防ぐ目的があります。
そのため、一定条件を超えると古いログから順に削除される仕組みが組み込まれています。

代表的な制約は以下の通りです。

SystemMaxUse：ジャーナルが使用できる最大ディスク容量
SystemKeepFree：システム領域として確保する最低空き容量
SystemMaxFileSize：単一ジャーナルファイルの最大サイズ
MaxRetentionSec：保持期間ベースの削除

これらのパラメータは/etc/systemd/journald.confで制御されますが、デフォルト値のまま運用されているケースも多く、気づかないうちにログが削除される原因となります。

特にSystemMaxUseの影響は大きく、ディスク使用量が上限に達すると、journaldは自動的に古いエントリから削除を開始します。
この動作はリアルタイムで行われるため、運用者が気づいたときにはすでに過去ログが失われていることがあります。

さらに重要なのがジャーナルローテーションの仕組みです。
journaldは単一ファイルにログを書き続けるのではなく、一定サイズごとに複数のファイルへ分割します。
この際、以下のような挙動が発生します。

新しいブートや時間経過でジャーナルファイルが分割される
古いファイルから順に削除対象になる
ディスク制限と併用されると削除速度が加速する

この仕組みにより、「昨日のログがない」と感じる状況が発生しますが、実際には削除ではなく「保持優先順位に基づく整理」です。

実務上の問題として特に厄介なのは、ログ削除が静的ではなく動的に行われる点です。
つまりディスク使用状況に応じてリアルタイムに変化するため、同じ設定でも環境によって保持期間が変わる可能性があります。

要因	動作	影響
ディスク逼迫	古いログ削除	過去ログ消失
ファイルサイズ超過	ジャーナル分割	追跡困難化
保持期間制限	時間ベース削除	古いログ消失

また、クラウド環境やコンテナ環境ではこの問題がさらに顕著になります。
例えば小さなルートディスクしか持たないイメージでは、わずかなログ増加でもSystemMaxUseに到達しやすく、短期間でログがローテーションされてしまいます。

加えて、ログ監視が不十分な場合、ディスク逼迫が発生していること自体に気づけないことも多いです。
その結果、「特定の時間帯だけログがない」という現象が発生し、障害解析を困難にします。

重要なのは、journaldのローテーションは障害ではなく設計通りの挙動であるという点です。
しかし運用設計の観点からは、適切な閾値設定を行わないと事実上のログ欠損につながります。

したがって実務では、単に永続化を有効にするだけでなく、ディスク容量監視とローテーション戦略をセットで設計する必要があります。
次のセクションでは、syslog転送やrsyslogとの連携におけるさらなる落とし穴について解説します。

rsyslog・syslog-ng転送設定に潜む二重管理とログ欠落の罠

Linux環境におけるログ管理では、journaldとrsyslog（あるいはsyslog-ng）を併用する構成が一般的です。
しかしこの構成は一見すると堅牢に見える一方で、実務では「ログが欠落する」「一部のイベントだけ記録されない」といった問題を引き起こす典型的な原因にもなります。
その根本には、二重管理構造による非同期性と責務分離の曖昧さがあります。

まず理解すべきは、journaldとsyslogデーモンは同じログソースを扱いながらも、処理経路が異なるという点です。
journaldはカーネルやサービスから直接ログを受け取り、バイナリ形式で保持します。
一方rsyslogやsyslog-ngは、主にテキストベースのログストリームを受け取り、/var/log配下へ書き込みます。
この時点で、ログの流れは以下のように分岐します。

アプリケーション → journald → journalctlで参照
アプリケーション → syslog → /var/log/messagesなど

問題は、この2系統が常に一致する保証がない点にあります。

特にrsyslogとの連携では、journaldからsyslogへの転送機構（imjournalモジュールなど）が使われますが、ここに非同期バッファが存在します。
このバッファが詰まると、ログの一部がドロップされる可能性があります。

# rsyslog側でjournaldを取り込む例
module(load="imjournal")
input(type="imjournal" StateFile="imjournal.state")

この構成自体は一般的ですが、以下のような条件が重なるとログ欠落が発生します。

高負荷時にバッファがオーバーフローする
journald側とrsyslog側の処理速度差が発生する
フィルタ設定により特定facilityが除外される

つまり、ログは「存在しているが転送されていない」という状態が起こり得ます。

さらにsyslog-ngを使用している場合は、設定の柔軟性が高い反面、フィルタリングロジックが複雑化しやすいという問題があります。
特定のプログラム名やpriorityで条件分岐を行うことが一般的ですが、この条件が意図せず一致しない場合、ログが完全に破棄されることがあります。

要因	発生箇所	結果
imjournal遅延	rsyslog	ログ遅延・欠落
フィルタミス	rsyslog/syslog-ng	特定ログ消失
バッファ溢れ	転送経路	断続的欠落

また、二重管理構成そのものが運用上の複雑性を増加させます。
journaldを一次保存としながらrsyslogでも保存する場合、ログの正本がどちらなのか曖昧になり、障害解析時に混乱を招きます。
特に以下のような状況では問題が顕在化します。

journaldには存在するが/var/logには存在しない
rsyslogにはあるがjournalctlにはない（転送遅延）
タイムスタンプが微妙にずれて相関解析が困難

このような不整合は、システムのバグというよりも設計上のトレードオフです。
リアルタイム性、冗長性、互換性を同時に満たそうとした結果として発生しています。

重要なのは、二重管理構成は「安全性を高めるための冗長化」である一方で、「観測の一貫性を犠牲にする可能性がある」という点です。
この性質を理解せずに運用すると、ログが断片的に見える原因になります。

実務上の対策としては、以下のような方針が有効です。

journaldを正としrsyslogを補助に限定する
転送経路を減らし単一パイプラインに寄せる
フィルタ設定を最小限にする

特に最近のシステムでは、journald単体での運用（あるいはLokiやFluentdへの直接転送）が増えており、rsyslogとの併用はレガシー構成として扱われるケースもあります。

したがって「ログが欠落する」という問題の多くは、データ消失ではなく転送経路の不整合です。
この構造を理解することで、原因切り分けの精度は大きく向上します。
次のセクションでは、コンテナ環境におけるさらに特殊なログ構造について解説します。

コンテナ環境でjournalctlログが保持されない理由とDockerの注意点

コンテナ環境において「journalctlでログが見えない」「再起動するとログが消える」という現象は非常に頻繁に発生しますが、これは多くの場合バグではなく設計上の制約によるものです。
特にDockerやKubernetesのようなコンテナ基盤では、ホストOSとは異なるログアーキテクチャが採用されるため、journaldの前提条件が成立しないケースが多く存在します。

まず重要なのは、コンテナ内のsystemdは通常フル機能で動作していないという点です。
多くのコンテナイメージでは軽量化のためsystemd自体が省略されているか、PID1として動作していない構成になっています。
その結果、journaldも完全には機能せず、ログは標準出力（stdout/stderr）に依存する形になります。

この構造の違いにより、以下のような現象が発生します。

journalctlコマンド自体が存在しない、または空の結果になる
/var/log/journalが作成されない
再起動時にログが完全に消える

つまりコンテナ内部では「ログの永続化」という概念自体がホストとは異なるレイヤーで扱われています。

Dockerの標準的なログ設計では、アプリケーションは標準出力にログを書き、Dockerデーモンがそれを収集する構造になっています。

# Dockerの標準ログ確認
docker logs <container_id>

この仕組みではjournaldは必須ではなく、むしろ利用されないことが一般的です。
Dockerのログドライバには以下のような種類があり、それぞれで保存先が異なります。

ログドライバ	保存先	特徴
json-file	ホストファイル	デフォルト・シンプル
journald	systemd journal	ホスト依存
fluentd	外部ログ基盤	集約向け

特にjournaldドライバを使用している場合でも、コンテナごとのログはホスト側journaldに統合されるため、コンテナ内から直接journalctlを実行しても期待通りの結果は得られません。

さらにKubernetes環境ではログ管理は完全に別設計となり、コンテナランタイム（containerdやCRI-O）がstdoutを収集し、ノードレベルで集約する構成が一般的です。
この場合もjournaldは補助的な役割に留まります。

また注意すべきポイントとして、コンテナのライフサイクルとログのライフサイクルが一致しないという問題があります。
コンテナは短命であることが前提のため、内部ストレージに依存したログ保存は破綻しやすくなります。

特に以下のような設計ミスが頻出します。

コンテナ内で/var/log/journalを永続化しようとする
systemdを無理に有効化して複雑化する
ホストとコンテナでログ経路が二重化する

このような構成は一見すると「フルOSのようなログ環境」を再現できますが、実際にはコンテナの軽量性と矛盾し、運用負荷を増大させます。

重要なのは、コンテナではログ永続化の責務はアプリケーションではなくプラットフォーム側にあるという設計思想です。
したがって、journaldをコンテナ内で完全に機能させること自体が目的として適切でない場合が多いです。

実務的には以下のような方針が推奨されます。

ログは標準出力に統一する
ホストまたは外部基盤で収集する
コンテナ内部のログ永続化は避ける

この設計により、ログの一貫性とスケーラビリティが確保されます。

したがって「コンテナでjournalctlが使えない」「ログが消える」という現象は、欠陥ではなくアーキテクチャの違いによる必然です。
この前提を理解することで、ログ設計の判断基準は大きく明確になります。
次のセクションでは、こうした環境差異を踏まえたログ監視基盤の設計について解説します。

ログ監視基盤の導入：Grafana LokiやDatadogでの可視化と運用改善

Linuxにおけるログ管理の課題は、単に「保存できているかどうか」ではなく、「必要なときに、必要な粒度で、素早く分析できるか」という観点に移行しています。
journalctlやsyslog単体での運用はシンプルである一方、システム規模が拡大すると検索性や可観測性に限界が生じます。
そのため近年では、Grafana LokiやDatadogのようなログ監視基盤を導入し、ログの集約・可視化・分析を一体化する構成が主流になりつつあります。

まずGrafana Lokiは、Prometheusの思想を踏襲したログ集約システムであり、メトリクスとログを同一スタックで扱える点が特徴です。
従来のELKスタックのように全文インデックスを構築しないため、ストレージ効率が高く、クラウドネイティブ環境との相性が良い設計になっています。

Lokiの基本構造は以下のように整理できます。

Promtailがログを収集
Lokiがラベルベースで保存
Grafanaがクエリと可視化を担当

この設計により、ログは全文検索ではなくラベル検索中心となり、運用上のコストを大きく削減できます。
一方で、ラベル設計を誤ると検索性が著しく低下するため、設計段階での慎重な分類が重要になります。

# Promtail設定例（概念）
scrape_configs:
  - job_name: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          __path__: /var/log/*.log

一方、DatadogはSaaS型の統合オブザーバビリティプラットフォームとして、ログ・メトリクス・トレースを統合的に扱うことができます。
特に大規模環境では、インフラの状態とアプリケーションログを横断的に分析できる点が強みです。

Datadog導入のメリットは以下の通りです。

インフラとアプリケーションの統合監視
AIベースの異常検知
ダッシュボードによる即時可視化

ただし注意点として、コスト構造がログ量に比例するため、無制限にログを送信すると運用コストが急増する可能性があります。
そのためフィルタリング戦略やサンプリング設計が不可欠です。

項目	Grafana Loki	Datadog
形態	OSS + 自前運用	SaaS
スケーラビリティ	高い（設計依存）	自動スケール
コスト	低〜中	中〜高
学習コスト	中	低

ログ監視基盤を導入する際に重要なのは、「ログを保存すること」ではなく「ログから意思決定できる状態を作ること」です。
journalctlやsyslogはあくまでローカルデバッグ用途に適しており、運用環境では情報の集約と構造化が不可欠になります。

特に分散システムでは、単一ノードのログだけを見ても障害全体像は把握できません。
そのため、トレースIDやリクエストIDを用いた相関分析が重要になります。
LokiやDatadogはこの点で優れており、ログを時系列やサービス単位で横断的に追跡することが可能です。

また、運用改善の観点では「アラート設計」が極めて重要です。
単なるエラー検知ではなく、エラーの頻度増加やレスポンスタイムの変化など、システムの兆候を捉える設計が求められます。

重要なのは、ログ監視基盤は単なるツールではなく「観測可能性（Observability）の中核」であるという点です。
これにより、従来の受動的なログ確認から、能動的なシステム改善へと運用スタイルが変化します。

したがって、journalctlやsyslogの理解に加えて、LokiやDatadogのような基盤を組み合わせることで、ログは単なる記録から戦略的資産へと変化します。
次のセクションでは、これまでの内容を踏まえた実践的なトラブルシュート手順について整理します。

journalctlトラブルシュート手順と設定確認の実践ポイント

journalctlで「ログが消えた」「見たいログが出てこない」といった問題に直面した場合、感覚的に原因を推測するのではなく、構造に基づいた段階的な切り分けが重要になります。
systemd環境のログは複数のレイヤーに分散しているため、確認順序を誤ると誤診に繋がりやすい構造になっています。

まず最初に確認すべきは、そもそもログが存在するかどうかです。
これは表示条件の問題なのか、物理的な消失なのかを切り分けるための基本ステップです。

# 全ログの確認
journalctl --no-pager
# ブート単位の確認
journalctl -b
journalctl -b -1

ここでログが見える場合、消失ではなくフィルタや表示条件の問題である可能性が高くなります。
一方で何も表示されない場合は、永続化設定やストレージの問題を疑う必要があります。

次に確認すべきはストレージ状態です。
journaldはメモリとディスクの両方を使用するため、現在どのモードで動作しているかを把握することが重要です。

# journaldの状態確認
journalctl --disk-usage

このコマンドにより、現在のジャーナル使用量とディスク上の保持状況を確認できます。
ここで極端に小さい値が表示される場合、永続化されていない可能性があります。

続いて確認すべきは設定ファイルです。
/etc/systemd/journald.confの内容は運用の基礎となるため、ここに誤設定があると全体に影響します。

特に重要なのは以下の項目です。

Storage=persistent の有無
SystemMaxUse の設定値
SystemKeepFree の確保量

これらの設定はログ保持ポリシーそのものを決定するため、単純なミスでもログ消失に直結します。

次に行うべきはディレクトリ構造の確認です。

ls -ld /var/log/journal
ls -ld /run/log/journal

この2つのディレクトリの存在は、永続化と一時ログのどちらが使用されているかを判断する重要な指標になります。
/run配下のみの場合は再起動でログが消える設計であるため、これは正常動作です。

また、フィルタリングの影響も必ず確認する必要があります。
journalctlは非常に柔軟なため、意図しない条件が付与されていることがあります。

# 特定ユニット確認
journalctl -u nginx
# 時間指定確認
journalctl --since "1 hour ago"

この段階でログが見つかる場合、問題は保存ではなく検索条件にあります。

さらにコンテナ環境やリモート環境では、対象ホストの誤認も頻出です。
SSH接続先やkubectlコンテキストが異なるだけで、全く別のログを見ているケースがあります。

実務的なトラブルシュート手順は以下のように整理できます。

ログ存在確認（journalctl全体）
ブート単位確認（-b）
ストレージ使用量確認（–disk-usage）
設定ファイル確認（journald.conf）
ディレクトリ構造確認（/var/log/journal）
フィルタ条件の排除
実行環境の確認（ホスト・コンテナ）

この順序で確認することで、誤診の多くは回避できます。

重要なのは、journalctlの問題の大半は「消失」ではなく「見え方の問題」であるという点です。
ログ管理は単なるコマンド操作ではなく、ストレージ設計・転送設計・検索設計が統合されたシステム問題として扱う必要があります。

したがってトラブルシュートの本質は「ログを探すこと」ではなく、「ログがどのレイヤーに存在しているかを特定すること」にあります。
これを理解できれば、systemd環境におけるログ運用の難易度は大きく下がります。

まとめ：Linuxログ管理で重要な設計思想と永続化の本質

Linuxにおけるログ管理を俯瞰すると、「ログが消えた」という現象の多くは実装上の不具合ではなく、設計思想の違いに起因していることが分かります。
特にsystemdの導入以降、従来のテキストファイル中心のsyslogモデルから、構造化されたバイナリログであるjournaldへと重心が移動したことで、ログの可視性や保持条件が大きく変化しました。

重要な前提として、ログは単一の保存先に存在するものではなく、複数レイヤーに分散した情報であるという理解が必要です。
journald、rsyslog、syslog-ng、コンテナランタイム、さらには外部監視基盤まで含めると、ログの経路は複雑なネットワーク構造になります。
この構造を意識せずに「ファイルにない＝消えた」と判断すると、誤った結論に至ります。

特に重要な設計思想は以下の3点に集約されます。

ログは「永続保存」ではなく「観測データ」である
保存場所は単一ではなく、用途別に分離される
可用性とコストのトレードオフで保持期間が決まる

この前提を理解すると、journaldのStorage=persistent設定やrsyslogの転送設定も単なるスイッチではなく、システム全体の観測設計の一部であることが見えてきます。

また永続化の本質は「消えないこと」ではなく、「必要な期間だけ再現可能であること」です。
ディスク容量制限やローテーション、さらにはクラウド環境におけるエフェメラルディスクの採用は、この思想に基づいています。
つまりログは無限に保持するものではなく、分析可能性を担保する範囲で保持されるべきデータです。

観点	従来型syslog	systemd/journald
保存形式	テキスト	バイナリ
永続化	ファイル依存	設定＋ディレクトリ依存
可観測性	分散的	構造化・統合的
スケーラビリティ	低〜中	中〜高