【syslog入門 第3回】Linuxのログの仕組み ― journaldとrsyslogの関係、RHELとUbuntuの違い、journalctl、/var/log、logger、logrotate、auditd

「RHELのサーバーを再起動したら、journalctlで再起動前のログが見えなくなりました」
「同じログが、/var/log/messagesに2回ずつ記録されています」

どちらも、Linuxの中でjournaldとrsyslogがどうログを受け渡しているかを知っていれば、すぐに説明がつきます。

第2回（syslogの基本）では、syslogの形式と転送方式を見ました。第3回では、Linuxの中でログがどのように集められ、ファイルや転送に渡るのかを扱います。第4回・第5回のrsyslogの設定の土台になる回です。

---

journaldとrsyslogの関係

現在のLinuxでは、ログはまずsystemd-journald（以下journald）に集まります。

• journaldは、カーネル、サービスの標準出力・標準エラー、/dev/logに書かれたsyslogのメッセージを受け取り、サービス名やPIDを付けてバイナリ形式で保存する
• テキストファイルへの書き出しと転送は、rsyslogの担当
• 受け渡しの方法は2つある。1つは、rsyslogのimjournalがジャーナルを直接読む方法で、RHELの既定。もう1つは、journaldのForwardToSyslog=yesで、syslog用のソケットへ流したメッセージをrsyslogのimuxsockが受け取る方法で、Ubuntuの既定

両方を有効にすると、同じログが2回記録されます。冒頭の「2回ずつ記録される」は、このパターンです。

---

RHELとUbuntuの違い

項目	RHEL 9／10	Ubuntu（26.04 で確認）
rsyslog の導入	通常のインストールで導入される	導入済み（Debian 12 以降は既定で未導入）
journald からの受け取り	imjournal がジャーナルを読む（imuxsock は SysSock.Use=”off”）	ForwardToSyslog=yes（systemd パッケージの /usr/lib/systemd/journald.conf.d/syslog.conf）を imuxsock で受ける
journald の保存の既定	メモリ上（/run/log/journal）。再起動で消える	永続（/var/log/journal）
ファイルの時刻の形式	Sep 26 17:42:28（RSYSLOG_TraditionalFileFormat）	2026-09-26T17:42:28.477025+09:00（高精度）
rsyslog の設定ファイル	/etc/rsyslog.conf、/etc/rsyslog.d/*.conf	/etc/rsyslog.conf、/etc/rsyslog.d/50-default.conf
主なログファイル	messages・secure・maillog・cron	syslog・auth.log・mail.log・kern.log

• Amazon Linux 2023とDebian 12以降は、rsyslogが既定で入っておらず、ログはjournaldにしかない。導入の有無はsystemctl status rsyslogで確かめる
• RHELはjournaldが再起動で消える既定のため、再起動前の調査には、rsyslogが書く/var/log/messagesを使う

冒頭の「再起動前のログが見えない」は、RHELの既定どおりの動きです。

---

journaldの保存と転送の設定

# RHEL で journald を永続化する（どちらか一方）
$ sudo mkdir -p /var/log/journal && sudo journalctl --flush
$ sudo mkdir -p /etc/systemd/journald.conf.d
$ printf '[Journal]\nStorage=persistent\n' | sudo tee /etc/systemd/journald.conf.d/persistent.conf
$ sudo systemctl restart systemd-journald
# 確かめる
$ journalctl --list-boots        # 過去の起動分が並べば永続化されている
$ systemd-analyze cat-config systemd/journald.conf | grep -E 'Storage|ForwardToSyslog'

• Storage=：auto（/var/log/journalがあれば永続）、persistent、volatile（メモリのみ）。既定値はビルド時に決まり、RHELはメモリ上、Ubuntuは永続
• ForwardToSyslog=：syslog用のソケットへ流すか。RHELはno（imjournalで読むため）。imjournalと両方を使うと、二重に記録される
• ログサーバーへ送るのはrsyslogの役目。journaldにもsystemd-journal-uploadなどの転送の仕組みはあるが、機器やWindowsを含めて集めるなら、syslogが共通語になる（第7回）
• 容量の上限はSystemMaxUse=、古いログの削除はjournalctl --vacuum-time=で行う

---

journalctlの要点（ログ集約の観点）

$ journalctl -u sshd --since "2026-09-26 09:00" --until "10:00"
$ journalctl -p warning -b                     # 今回の起動以降の warning 以上
$ journalctl -t myapp -n 1 -o short-iso-precise --utc
2026-09-26T08:42:28.476857+00:00 web01 myapp[1276115]: disk usage 91% on /var
$ journalctl -t myapp -n 1 -o json             # 抜粋。実際は1件が1行
{"MESSAGE":"disk usage 91% on /var","PRIORITY":"4","SYSLOG_FACILITY":"16",
 "SYSLOG_IDENTIFIER":"myapp","_PID":"1276115","_HOSTNAME":"web01",
 "_TRANSPORT":"syslog","__REALTIME_TIMESTAMP":"1790412148476874"}

• -u（サービス）、-p（Severity。-p warning..errのように範囲も可）、--since／--until（時刻）を組み合わせて絞る。サービス名は、RHELがsshd、Ubuntuがssh
• -o jsonでは、PRIORITY（Severity）とSYSLOG_FACILITYが数値のまま入り、収集ツールが読みやすい。先頭が_の項目（_PID・_HOSTNAMEなど）はjournaldが付けるもので、送信元のプログラムは偽れない
• --utcでUTCで表示する。複数の機器と突き合わせるときは、時刻の基準をそろえる（連載「NTP入門」第2回）

Windowsで同じことを調べる

PS> Get-WinEvent -LogName System -MaxEvents 1
   ProviderName: Microsoft-Windows-Kernel-General
TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
2026/09/26 17:40:10             16 情報             …（抜粋）
PS> Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2,3; StartTime=(Get-Date).AddHours(-24)}
PS> Get-WinEvent -LogName Application -MaxEvents 1 |
      Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message | ConvertTo-Json
PS> wevtutil qe System /c:3 /rd:true /f:text

• Windowsには、journaldもsyslogも無く、イベントログ（System・Application・Securityなどのチャネル）に記録される。詳しくは第6回
• -LogNameがjournalctlの対象の指定、-FilterHashtableのLevel（1＝重大〜4＝情報）が-p、StartTime／EndTimeが--since／--untilに当たる
• ConvertTo-Jsonで、-o jsonのように項目付きで出せる。wevtutilは標準のコマンド（/rd:trueで新しい順）。Securityログの読み取りには管理者権限が必要

---

/var/logの主なファイル

内容	RHEL 9／10	Ubuntu・Debian 系	振り分けの設定（セレクター）
一般のメッセージ	/var/log/messages	/var/log/syslog	RHEL：.info;mail.none;authpriv.none;cron.none、Ubuntu：.*;auth,authpriv.none
認証（SSH・sudo）	/var/log/secure	/var/log/auth.log	RHEL：authpriv.、Ubuntu：auth,authpriv.
メール	/var/log/maillog	/var/log/mail.log	mail.*
cron	/var/log/cron	（syslog に含まれる）	cron.*
カーネル	（messages に含まれる）	/var/log/kern.log	kern.*
監査（auditd）	/var/log/audit/audit.log	同左（auditd を入れた場合）	syslog を経由しない

• FacilityとSeverityの組み合わせ（セレクター）でファイルを分けている（第2回）
• RHELのmessagesはauthprivを除くため、SSHのログインはsecureにしかない
• ログサーバーへ転送するときも、同じセレクターで選べる（第5回）
• これらのファイルはrsyslogが書くため、rsyslogの無い環境には存在しない

---

loggerで試す

ローカルに書く

$ logger -p local0.warning -t myapp "disk usage 91% on /var"
$ tail -n 1 /var/log/syslog                   # Ubuntu（RHEL は /var/log/messages）
2026-09-26T17:42:28.477025+09:00 web01 myapp: disk usage 91% on /var
$ journalctl -t myapp -n 1
Sep 26 17:42:28 web01 myapp[1276115]: disk usage 91% on /var

オプション	意味	例
-p	Facility.Severity（既定は user.notice）	-p local0.warning、-p auth.info
-t	TAG（既定はユーザー名）	-t myapp
-i、–id=	PID を付ける	–id=$$
-n、-P	送り先のサーバーとポート	-n 192.0.2.50 -P 514
-d、-T	UDP だけ、TCP だけで送る	-T -P 514
–rfc3164、–rfc5424	送る形式。リモートへの既定は 5424	–rfc3164
-s	標準エラーにも表示する	動作の確認に

journaldがPIDを補うため、journalctlには[1276115]が付きますが、rsyslogが書くファイルには付きません（-iを付ければ両方に付きます）。オプションは、すべて半角のハイフンです。資料などからコピーすると、ハイフンがenダッシュ（–）になっていて動かないことがあります。

ログサーバーへ送り、中身を見る

$ logger -n 192.0.2.50 -P 514 -p local0.warning -t myapp "disk usage 91%"
（受信側で見たペイロード）<132>1 2026-09-26T17:41:43.895957+09:00 web01 myapp - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="124747"] disk usage 91%
$ logger -n 192.0.2.50 -P 514 --rfc3164 -p local0.warning -t myapp "disk usage 91%"
（受信側で見たペイロード）<132>Sep 26 17:41:43 web01 myapp: disk usage 91%
$ logger -T -n 192.0.2.50 -P 514 -p local0.err -t myapp "tcp test"   # TCP（-P を省くと 601 番）
PS> $udp = New-Object System.Net.Sockets.UdpClient
PS> $b = [Text.Encoding]::UTF8.GetBytes("<134>1 2026-09-26T17:41:43+09:00 pc01 test - - - hello from Windows")
PS> $udp.Send($b, $b.Length, "192.0.2.50", 514)
67
PS> $udp.Close()
PS> Test-NetConnection 192.0.2.50 -Port 6514      # TCP だけ確かめられる

• -nを付けると、既定でRFC 5424形式・UDPで送る。UDPで送れないときだけTCPを試す
• 受信側では、sudo tcpdump -i ens192 -n -A udp port 514でペイロードを見て、PRIと形式を確かめる（第10回）
• Windowsにはloggerが無いが、PowerShellから.NETのUdpClientで1行送れる（67は送ったバイト数）。Test-NetConnectionはTCPしか確かめられない。UDPは、受信側で届いたかを見る

---

logrotate：ログサーバーでの注意

# /etc/logrotate.d/remote（送信元ごとのディレクトリに書く場合の例）
/var/log/remote/*/*.log {
    daily
    rotate 400
    dateext
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
    endscript
}

• rsyslogはHUPを受けると、書き込み中のファイルを閉じ、次の書き込みで開き直す
• ファイルが大量になる：送信元ごと・種類ごとに分けると数千ファイルになる。ワイルドカードで1つの設定にまとめ、sharedscriptsでHUPを1回にする
• 圧縮：テキストのログは圧縮がよく効く。delaycompressで直前の世代は圧縮せず残し、書き込みの取りこぼしに備える
• 保存期間：rotate 400は日次で約13か月（PCI DSSの12か月に余裕を持たせた例。第1回（ログとは・なぜ集めるか））。世代数は規程の保存期間から逆算し、ディスクの容量を見積もる（第7回）
• ファイル名に日付を入れて書く方式（rsyslogのテンプレート。第5回）なら切り替えは不要で、古いファイルを消すだけでよい

---

auditdとの違い

観点	syslog（rsyslog）	journald	auditd
記録するもの	プログラムが自分で出すメッセージ	syslog のメッセージ、サービスの標準出力、カーネル	カーネルが見た操作（ファイルへのアクセス、コマンドの実行、ログイン、SELinux の拒否）
誰が書くか	各プログラム（自己申告）	各プログラム＋journald が付ける信頼できる項目	カーネル（プログラムは関与しない）
保存先	/var/log/messages など	/var/log/journal など	/var/log/audit/audit.log
検索	grep など	journalctl	ausearch、aureport
集約先への転送	rsyslog で送る	rsyslog を経由	syslog プラグイン（/etc/audit/plugins.d/syslog.conf で active = yes）か rsyslog の imfile で読む

syslogのログは、プログラムが「自分は何をしたか」を申告したもので、logger -p auth.infoのように誰でも任意のFacilityで書き込めます。auditdはカーネルが記録するため詐称に強く、PCI DSSの「管理者の操作」「重要なファイルへのアクセス」の証跡に向いています。監査ログも、集約先へ送って保管します。

---

考えてみよう

1. 担当のRHELサーバーでjournalctl --list-bootsを実行すると、前回の起動分は見えますか。見えない場合、再起動前の障害はどこで調べますか。
2. rsyslogのimjournalと、journaldのForwardToSyslogが両方とも有効になっていたら、何が起きますか。どうやって確かめますか。
3. 一般ユーザーでlogger -p auth.info -t sshd "Accepted password for root"と打つと、何が記録されますか。このことから、syslogのログを証跡として使うときの注意を説明してください。

ヒント：この記事のRHELとUbuntuの違いの表、journaldの設定のsystemd-analyze cat-config、「自己申告」と「カーネルが記録」の図が手がかりです。

---

まとめ

• ログはまずjournaldに集まり、ファイルへの書き出しと転送はrsyslogが担う
• 受け渡しはimjournal（RHEL）かForwardToSyslog（Ubuntu）のどちらか。両方だと二重に記録される
• RHELのjournaldは再起動で消える既定。Amazon Linux 2023・Debian 12以降はrsyslogが無い
• journalctl -o jsonの先頭が_の項目は、送信元が偽れない
• logger -n … -P …で送り、受信側のtcpdumpでPRIと形式を確かめる
• ログサーバーのlogrotateは、ワイルドカードとsharedscripts、保存期間から世代数を逆算
• syslogは自己申告。証跡にはauditdも集める

次回は、rsyslogでログを受信・転送し、キューで欠損を防ぐ設定を扱います（前編）。

---

連載「syslog入門」全11回

全回の目次と、読む順番・目的別の読み方は、syslog入門の入口のページにまとめています。

1. ログとは・なぜ集めるか
2. syslogの基本
3. Linuxのログの仕組み（この記事）
4. rsyslog 前編
5. rsyslog 後編
6. Windows・ネットワーク機器のログ
7. ログ集約基盤の設計
8. 分析と監視・SIEM
9. クラウドのログ
10. syslogのトラブルシュート
11. ログ管理の設計演習