システムロギング（rsyslog・systemdジャーナル・logrotate）

rsyslogによるシステムロギング

rsyslogは、多くのディストリビューションで標準的に使われているシステムログの記録デーモン（rsyslogd）です。カーネルやアプリケーションが出力したログメッセージを、その種類や重要度に応じて振り分け、ファイルへの保存や他ホストへの転送などの処理（アクション）を行います。

/etc/rsyslog.confの基本構文

rsyslogの設定は、主に/etc/rsyslog.conf（および、そこから読み込まれる/etc/rsyslog.d/配下の設定ファイル）で行います。伝統的な構文（sysklogd形式）では、1行につき「セレクタ（どのログを対象にするか）」と「アクション（そのログをどう扱うか）」を空白で区切って記述します。セレクタはファシリティ.優先度という形式です。

kern.crit    /var/log/kern-crit.log
mail.*       /var/log/maillog
*.emerg      :omusrmsg:*

ファシリティ（メッセージの発生元の種類）

優先度（重要度、深刻な順）

優先度はemergが最も深刻で、debugに向かって順に重要度が下がります。セレクタにkern.critと書いた場合、通常は「crit以上（crit・alert・emerg）の優先度を持つkernファシリティのメッセージ」が対象になります^{優先度の前に何も付けない場合の挙動です。=critのように=を付けると「critちょうどの優先度のみ」に絞り込めますが、この=修飾子はLPIC/LinuCの出題範囲としては細かすぎるため、本記事では基本形のみを扱います。[1]}。ファシリティ・優先度のどちらの位置にも、すべてを意味するワイルドカード*が使え、優先度の位置にnoneと書くと「そのファシリティを除外する」という意味になります。複数のセレクタをまとめて指定する際は、同じアクションに対してファシリティをカンマ,で並べ、優先度の異なる条件を追加する際はセミコロン;で区切ります。

リモートホストへのログ転送

rsyslogは、自ホストのログをファイルに保存するだけでなく、中央のログサーバーへ転送したり、逆に他ホストからのログを受け取って中央のログサーバーとして動作させたりすることもできます。アクションの先頭に@を1つ付けるとUDPで、@@と2つ付けるとTCPで、指定したホストへログを転送します。

*.*    @192.0.2.10
*.*    @@192.0.2.10:10514

一般的に、rsyslog間のログ転送にはポート514番が使われます^{ポート514番自体の詳細（TCPとUDPで全く別のサービスを指す点等）は「ネットワークの基礎」の技術解説記事を参照してください。[2]}。中央のログサーバー側でログを受け取れるようにするには、UDPで受信するためのimudp、TCPで受信するためのimtcpといった入力モジュールを、あらかじめ設定ファイル上で読み込んでおく必要があります。

logger・systemd-catによるログの生成

シェルスクリプトや手動の操作から、任意のメッセージをシステムログに書き込みたい場合に使うコマンドです。

logger

loggerは、指定した文字列をsyslog（またはsystemdジャーナル）に書き込むコマンドです。

logger -p local0.info -t mybackup "バックアップ処理を開始しました"

systemd-cat

systemd-catは、指定したコマンドの標準出力・標準エラー出力をsystemdジャーナルに送り込むコマンドです。パイプラインのフィルタとしても使えます。

systemd-cat -t mybatch -p info /usr/local/bin/mybatch.sh

systemdジャーナル（journald）

systemd-journaldは、systemdに組み込まれたログ管理の仕組みです。カーネルメッセージ、各サービス（systemdユニット）の標準出力・標準エラー出力、syslog()関数経由のメッセージなどを一括して受け取り、構造化された独自のバイナリ形式で記録します。テキスト形式のログファイルと異なり、日時・優先度・発生元のユニットといった情報ごとに柔軟な検索・絞り込みができる点が特徴です。ジャーナルの内容はjournalctlコマンドで参照します。

journalctlによる問い合わせ・フィルタ

引数を付けずにjournalctlを実行すると、記録されている全てのログをページャ（less相当）で表示します。

journalctl -u sshd.service -p err --since "2026-09-01 00:00:00"

上の例は、「sshd.serviceについて、2026年9月1日0時以降の、エラー以上の優先度のログ」に絞り込んで表示します。複数のオプションを組み合わせることで、絞り込み条件を重ねて指定できます。

永続systemdジャーナルストレージとジャーナルサイズの設定

ジャーナルの保存先や上限サイズは、/etc/systemd/journald.confで設定します。

Storage=の既定値はautoであるため、多くのディストリビューションでは/var/log/journal/ディレクトリが最初から存在しない場合、再起動するとジャーナルの内容が失われます。ログを再起動後も残る永続的なものにしたい場合は、/var/log/journal/ディレクトリを作成した上で、journalctl --flushを実行するか、そのまま次回以降の起動を待つことで、ディスクへの永続保存が有効になります^{Storage=persistentを明示的に指定した場合も、必要なディレクトリが自動的に作成されます。[3]}。

古いジャーナルデータの削除

ジャーナルは放置するとSystemMaxUse=等の上限まで肥大化するため、journalctlのオプションで手動削除することもできます。

journald.conf側にも、MaxRetentionSec=（保存期間の上限）・MaxFileSec=（個々のジャーナルファイルをローテーションするまでの期間）のように、あらかじめ自動的な削除・世代管理の方針を設定できるディレクティブが用意されています。

レスキューシステムやファイルシステムのコピーからのジャーナルデータの探索

システム障害時にレスキューシステムから起動した場合や、別の場所にコピーしたディスクイメージ・ファイルシステムの中身を調査したい場合、journalctlに-D（--directory=）オプションでジャーナルのディレクトリを直接指定することで、通常の実行中システムとは別の場所にあるジャーナルデータを参照できます。

journalctl -D /mnt/recovery/var/log/journal/<マシンID>

個々のジャーナルファイルを指定したい場合は、--file=オプション（glob形式で複数指定可）も使えます。

systemd-journaldとrsyslogのやり取り

systemdが採用されている現在の多くのディストリビューションでは、journaldとrsyslogは役割を分担しつつ連携して動作しています。カーネルメッセージや各サービスの出力は、まずsystemd-journaldに集約され、構造化された形でジャーナルに記録されます。rsyslog側は、imjournalという入力モジュールを使ってこのジャーナルの内容を読み取り、従来どおりの/etc/rsyslog.confの設定に基づいて/var/log/配下のテキスト形式のログファイルへの書き出しや、他ホストへの転送を行います^{ディストリビューションやバージョンによっては、rsyslogがジャーナル経由ではなく、従来の/dev/logソケットを直接受け取るimuxsockモジュールで動作している構成もあります。「journaldが一元的にログを集約し、rsyslogはそこから必要な形で書き出し・転送を担当する」という役割分担の考え方自体は共通ですが、具体的な受け渡し方法（imjournalかimuxsockか）はディストリビューションの既定設定によって異なる点に注意してください。[4]}。このように、journalctlで構造化された形で検索したい場合はジャーナルを、他ホストへの転送や昔ながらのテキスト形式のログファイルとして扱いたい場合はrsyslogを、という形で使い分けられるのが現在の一般的な構成です。

logrotateによるログのローテーション

/var/log/配下のログファイルは、放置すると肥大化してディスクを圧迫します。logrotateは、ログファイルを定期的に切り替え（ローテーション）、古いログの圧縮・世代管理・削除までを自動化するツールです。

設定ファイルの構成

logrotateの設定は/etc/logrotate.confが起点となり、そこから/etc/logrotate.d/配下の個々の設定ファイル（多くの場合、パッケージのインストール時にサービスごとに追加される）を読み込みます。設定ファイルの先頭部分（波かっこで囲まれていない部分）に書いた内容はグローバルオプションとしてすべてのログに適用され、対象ファイルのパス { ... }のように波かっこで特定のログファイルに対して書いた内容はローカルオプションとして、そのログに対してだけグローバルオプションを上書きします。

/var/log/myapp/*.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    postrotate
        systemctl reload myapp >/dev/null 2>&1 || true
    endscript
}

主要ディレクティブ

実行のしくみ

logrotate自体は常駐するデーモンではなく、多くのディストリビューションでは、cron（/etc/cron.daily/logrotate）またはlogrotate.timerのようなsystemdタイマーによって1日1回程度の頻度で定期的に呼び出されるコマンドです^{「ログファイルのサイズを常に監視し続けている」わけではなく、あくまで定期的に実行された時点でのファイルサイズ・経過日数を基準に判断する点に注意してください。[5]}。そのため、size・maxsizeを指定していても、実際にファイルが縮小されるタイミングは次にlogrotateが実行されるタイミング次第になります。

syslogとsyslog-ngの知識

syslogは、ログメッセージの形式・転送方法を定めた古くからのプロトコル・しくみの総称で、その実装（デーモン）として伝統的に使われてきたのがsyslogdです。syslog-ngは、この伝統的なsyslogdを置き換える形で登場した、より柔軟なフィルタリング・振り分けが可能な実装の1つです。rsyslogも同様に、伝統的なsyslogdを置き換える目的で開発された実装であり、syslog-ngとrsyslogは、いずれも「syslogという枠組みの、より高機能な実装」という位置づけを共有していますが、互いに設定ファイルの書式（syslog-ng.confとrsyslog.conf）や実装は別物です。現在の主要なディストリビューションでは、既定のログデーモンとしてrsyslogが採用されていることが多いですが、syslog-ngが採用されている、あるいは選択できる環境もあります。

試験対策上の注意点

• セレクタの優先度は「指定した優先度以上」が対象になる（=を付けない限り）ことを、思い込みで逆に覚えないようにしてください。
• journalctl -pも同様に「指定した優先度以上」が対象になります。rsyslog・journalctlのどちらも同じ考え方です。
• ジャーナルは既定では永続化されないディストリビューションが多い点（Storage=autoかつ/var/log/journal/が存在しない場合）に注意してください。「journalctlで過去の起動分のログが見えない」というトラブルの典型的な原因です。
• logrotateはデーモンではなく、cronやsystemdタイマー経由で定期的に呼び出されるコマンドです。「ログファイルを常時監視している」という誤解をしないようにしてください。
• rsyslogとsyslog-ngは別の実装です。「syslog-ngはrsyslogの別名」のような誤った理解をしないよう注意してください。