journald のログを永続化したい

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

こんにちは。サイオステクノロジー OSS サポート担当山本です。

今回は以前お話しした journald のログを永続化するお話しをしてみようと思います。

1 ■おさらい：journald って何だっけ？
2 ■journald のログは永続化できない？
3 ■journald のログを永続化させる設定
- 3.1 ■①：設定ファイルによる永続化
- 3.2 ■②：永続化用のディレクトリ作成
4 ■journald ログの永続化の確認
- 4.1 ■デフォルト設定時に journald のログが消失するか
- 4.2 ■ディレクトリ /var/log/journal/ を作成した場合
5 ■journald ログ永続化と rsyslog
6 ■最後に

■おさらい：journald って何だっけ？

journald は、システム管理ソフトウェア systemd のコンポーネントの一つで、システム全体のロギングを担うものです。

この journald のログは、systemd + rsyslog でロギング環境を構成するシステムでの主要なログファイル /var/log/messages の元となっている一方で、
journald のログ自体は通常はデフォルトで一時ディレクトリ /run/ 配下の /run/log/journal/ 配下に保存されており、システムの再起動ごとに中身が全て消えてしまいます。

…というのが、前回と前々回お話しした概要でした。

■journald のログは永続化できない？

先にもお話ししたとおり、systemd + rsyslog の環境では通常、デフォルトでは journald のログはシステムの再起動で消失してしまいます。

勿論、前回お話ししたとおりその内容は rsyslog によって /vat/log/messages などに記録されるので大概の場合は気にすることはないかと思いますが、
journald のログには、rsyslog のログでは記録されない、本文や時刻・サーバ情報などの基本情報以外の埋め込み情報がある場合があったり、journalctl コマンドを使いこなせれば目的のメッセージのみを表示するフィルタリングができたりなど、
もしかすると、環境や journald のログの埋め込み情報の内容によっては journald のログも永続化させたい…ということもなくはないかもしれません。

そういった場合に、journald のログを簡単に永続化させることはできるのでしょうか？

…というのが、今回のお題目です。
そしてその答えは Yes です。ここからはその方法を確認してみます。

■journald のログを永続化させる設定

今回は 2種類の方法を確認していきます。

■①：設定ファイルによる永続化

まずはシンプルに、設定ファイルによって journald のログを永続化する方法です。

journald の設定ファイルは /etc/systemd/journald.conf にあります。
設定ファイル内の永続化に関する部分の付近を抜粋すると、このあたりです。

# Use 'systemd-analyze cat-config systemd/journald.conf' to display the full config.
#
# See journald.conf(5) for details.

[Journal]
#Storage=auto
#Compress=yes

この中の “Storage” が、journald のログの保存方法の設定項目です。

この “Storage” を “persistent” に変更すると、journald のログを永続化する設定になります。
設定ファイル内で行頭に “#” にある行はコメント行 (設定として扱われない行) となるので、”Storage” の行の行頭の “#” を外すのも忘れないようにしましょう。

[Journal]
Storage=persistent
#Compress=yes

設定を変更したら、システムを再起動すれば OK です。
(systemd-journald.service の再起動と “sudo journalctl –flush” コマンドの実行でも OK です。※ 古いバージョンでは “sudo journalctl –flush” は不要な場合があります。)

再起動後には journald のログは /var/log/journald/ 配下に記録されるようになり、システムの再起動では自動的に消失しないようになります。

■②：永続化用のディレクトリ作成

先ほど見た設定ファイル /etc/systemd/journald.conf の “Storage” のデフォルト値を改めて見てください。

[Journal]
#Storage=auto
#Compress=yes

“auto” と、ぱっと見てどんな保存方法を取るのかよくわからない設定値になっています。
(実際はこの行はコメントになっているため “Storage” は “設定なし” になりますが、”Storage” が設定されていない場合のデフォルト値も “auto” となります。)

この “Storage=auto” の挙動は…

　・/var/log/journal/ ディレクトリが存在するなら、/var/log/journal/ 配下に保存 (“Storage=persistent” の場合と同様の動作)
　・/var/log/journal/ ディレクトリが存在しないなら、/run/log/journal/ 配下に保存 (システム再起動などで消失)

というものです。

つまり、設定ファイルを変更せずとも適切な権限で /var/log/journal/ ディレクトリを作成すれば、journald のログは永続化することができます。

この方法は、例えば以下のようなコマンドで実現することができます。

$ sudo mkdir -p /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal

上記コマンドを実行したら、システムを再起動した後は jouenald のログが /var/log/journald/ 配下に記録されるようになります。
(“sudo journalctl –flush” コマンドの実行でも OK です。)

■journald ログの永続化の確認

では上記の②のディレクトリを作成する方法を使って、実際に journald のログが永続化できるか確認してみましょう。

■デフォルト設定時に journald のログが消失するか

…とその前に。まずは journald のログがシステム再起動で消失してしまうことを確認しておきましょう。
今回は、システムログを書き込める logger コマンドと journald のログを確認する journalctl コマンドで確認していこうと思います。
logger でログの生成 → journalctl でログの確認 → システム再起動の順で実行していきます。

$ logger -p user.info test: before create directory
$ sudo journalctl --facility=user -n 5 -o short-full --no-pager --no-hostname
Wed 2023-07-12 10:02:00 UTC user1[2356]: test: before create directory
$ 
$ sudo reboot

再起動後、再度ログインして同じ journalctl コマンドで再起動前のログがあるかを確認してみると…
このとおり、ログは確かに消えてしまっています。

$ sudo journalctl --facility=user -n 5 -o short-full --no-pager --no-hostname
-- No entries --
$

■ディレクトリ /var/log/journal/ を作成した場合

さて、それでは改めて /var/log/journal/ を作成して、journald のログが永続化されているかを確認してみます。
まずはディレクトリを作成して再起動します。

$ sudo mkdir -p /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal
$ 
$ sudo reboot

再起動後に再ログインして、先ほどと同じように logger でログの生成 → journalctl でログの確認 → システム再起動の順で実行していきます。

$ logger -p user.info test: after create directory
$ sudo journalctl --facility=user -n 5 -o short-full --no-pager --no-hostname
Wed 2023-07-12 10:10:27 UTC user1[1756]: test: after create directory
$ 
$ sudo reboot

再度の再起動後に再ログインして、同様の journalctl コマンドで再起動前のログがあるかを確認してみると…
このとおり、再起動前のログがちゃんと残っていることが確認できるかと思います。

$ sudo journalctl --facility=user -n 5 -o short-full --no-pager --no-hostname
Wed 2023-07-12 10:10:27 UTC user1[1756]: test: after create directory
$

■journald ログ永続化と rsyslog

さて、journald の永続化が簡単にできるということはわかりました。

ところで、以前にお話ししたとおり systemd + rsyslog の環境で rsyslog が記録するログ /var/log/messages などの内容は、journald のログの情報を元にしています。
バイナリファイル/テキストファイルの違いや rsyslog 側が journald ログの情報の一部抜粋であるなどの違いはありますが、原則内容がかぶっているわけですね。
journald を永続化していないなら「長期保存と初期調査は rsyslog、直近のデータをフィルタリングしたり細かく見るなら journald」…のようにそれぞれに用途を見出すことができるかと思いますが、journald を永続化するなら rsyslog でわざわざ journald のログを元にした /var/log/messages などを記録させる必要はあるのか？というところは検討する必要がありそうです。

一方、journald のログは複数のフィールドから構成されています。
例えば「メッセージ本文はこれ」「ファシリティはこれ」「タイムスタンプはこれ」「ホスト名はこれ」「各種 ID はこれとこれと…」…といった具合に、複数の「このフィールドはこう」という記述によって、一つのログを表現しています。
このおかげで journald のログは journalctl コマンドによる柔軟なフィルタリングに対応できるわけですが……(単純なテキストとして書き出している /var/log/messages と比べると) これは多少なりとより多くのディスク領域を使用することになるはずです。

なお、journald のログを永続化した場合、その最大のディスク使用量は /etc/systemd/journald.conf の “SystemMaxUse (デフォルト値：ストレージ全体の 10%)” となります。
journald の各ログファイルは同設定ファイルの “SystemMaxFileSize (デフォルト値：SystemMaxUse の 1/8、ただし最大 4G)” のサイズで作成され、必要に応じてログのローテーションが行われます。
このため、「永続化」と言っても古いログに関しては削除される可能性がある点にも留意は必要です。

journald の永続化を行なう場合、これらを踏まえた上で環境に合った設定方法を考えていく必要があります。