Journalログの運用管理
ログインユーザが100人を越えるときにはjournalの容量に注意
Journalログについて
systemd-journaldは、systemdと統合されたログ収集・保存サービスです。 従来から syslogで使われてきた /dev/log や systemd unitの標準出力・標準エラー出力など様々な入力をうけつけ、 専用の journal とよばれるバイナリログへ保存します。
RHEL 7,8,9のデフォルトでは、journalはtmpfs上に作成され、再起動により消えます。 rsyslogのimjournal pluginがjournalを読み、/var/log/messagesなどに保存します。 つまりjournalは主にrsyslogへの中継役として利用されています。
Journalログの永続化
上記にある通り Journal 自体ロガーという役割ではないためデフォルトではログは再起動等あると消えてしまいます。
それでも監査等の目的で一定のログを保持したい場合、出力先を作成することでログ出力されるようになる。
# mkdir /var/log/journal
# systemctl restart systemd-journald
デフォルトでは journal の設定は下記のようになっており、auto の場合に出力先がない場合は保存しない、出力先ディレクトリがある場合はログ出力という挙動になります
Storage のパラメータを persistent にすることでも同様に永続化させることが出来る
# vi /etc/systemd/journald.conf
[Journal]
#Storage=auto
ログのローテート
systemd-journaldはログをjournalに保存するタイミングで、時間・サイズなどの条件を判定してjournalを自動的にローテートします。デフォルトでは記録をはじめて30日経過する、全体で利用できる容量(デフォルトは 4GiBまたはパーティションの10%のどちらか小さなサイズ )の1/8のサイズになる等の契機でローテートします。
また rsyslog で管理している messages や secure などのログは journald の内容を参照しているためjournalログの多くの内容は重複していることになる
rsyslog で管理されているログをきちんと管理するようにしている場合はは最低限消えないよう出力するようにしておく程度で、重複してバックアップや長期保存するような運用は行わないほうが良さそう
ユーザーログの一括管理化
ファイルをユーザ毎に分割しないことで、ローテーション時に参照できる過去のログが極端に少なくなる現象を避けられます。 1つのファイルにまとめた結果として、各ユーザがデフォルトでは自分のセッションのログを読めません。システム全体のログを読むのと同じ権限が必要になります。
上記にある通り、ユーザー毎に分かれていたほうが可読性や検索性は上がるが、このようなシステムログは管理者のみ見れるようになることは良い場合が多いため、
頻繁にログを見る必要がない場合はログの分割を無効化する
# vi /etc/systemd/journald.conf
[Journal]
SplitMode=none