はじめに
この実験では、journalctl と rsyslog を使用して、Red Hat Enterprise Linux 9 でシステムログを分析および保存する実践的な経験を積みます。まず、systemd-journald と rsyslog の役割を含むシステムロギングのコアアーキテクチャを理解し、主要なログファイルを特定します。続いて、一般的なコマンドを使用して syslog ファイルを確認・フィルタリングする方法、カスタム syslog メッセージを手動で送信する方法、および journalctl を使用してシステムジャーナルエントリを調査・フィルタリングする方法を学びます。また、永続的なシステムジャーナルストレージの設定や、timedatectl および chronyd を使用した正確なシステム時刻の維持についても扱い、システム分析とトラブルシューティングに不可欠なスキルを習得します。
システムログのアーキテクチャと主要ファイルの理解
このステップでは、Red Hat Enterprise Linux 9 におけるシステムロギングの基本コンポーネント、特に systemd-journald サービスと rsyslog サービス、およびそれらが管理する主要なログファイルについて学びます。このアーキテクチャを理解することは、効果的なシステム分析とトラブルシューティングを行う上で非常に重要です。
まず、systemd-journald サービスについて見ていきましょう。このサービスは、オペレーティングシステムのイベントロギングの中核を担っています。カーネル、ブート初期のプロセス、デーモンからの標準出力/エラー、syslog イベントなど、さまざまなソースからイベントメッセージを収集します。systemd-journald サービスは、これらのログを「ジャーナル」と呼ばれる構造化されたインデックス付きのバイナリファイルに保存します。
次に、rsyslog サービスについて説明します。systemd-journald がログを収集する一方で、rsyslog はジャーナルに syslog メッセージが到着するとそれを読み取ります。その後、メッセージを処理し、/var/log ディレクトリ内の従来のログファイルに記録するか、設定に基づいて他のサービスに転送します。これらの rsyslog ファイルは、再起動後も保持されます。
/var/log ディレクトリ内で rsyslog が管理する重要なログファイルをいくつか確認してみましょう。ls コマンドを使用して、このディレクトリの内容をリスト表示できます。
ls /var/log
さまざまなログファイルが表示されます。システム環境によりますが、anaconda、audit、boot.log、chrony、cron、dnf.log、messages、secure などのファイルが見えるはずです。最も一般的なものは以下の通りです。
/var/log/messages: 認証、メール処理、スケジュールされたジョブの実行、デバッグに関連するものを除く、ほとんどの一般的な syslog メッセージが含まれています。/var/log/secure: セキュリティおよび認証イベントに関連する syslog メッセージが保存されます。/var/log/maillog: メールサーバーに関する syslog メッセージが含まれています。/var/log/cron: スケジュールされたジョブの実行に関する syslog メッセージが記録されます。/var/log/boot.log: システム起動に関する syslog 以外のコンソールメッセージが含まれています。
これらのファイルの内容を表示するには、cat、less、tail などのコマンドを使用できます。/var/log 内のほとんどのログファイルは読み取りに root 権限が必要なため、sudo を使用する必要があることに注意してください。例えば、tail を使用して /var/log/messages ファイルの最後の数行を表示してみましょう。
sudo tail /var/log/messages
また、セキュリティ監査に重要な /var/log/secure ファイルの内容も表示できます。
sudo tail /var/log/secure
これらのファイルの目的を理解しておくことで、システムの問題をトラブルシューティングする際に、関連情報を迅速に見つけることができます。
一般的なコマンドを使用した syslog ファイルの確認とフィルタリング
このステップでは、一般的な Linux コマンドを使用して syslog ファイルを効果的に確認およびフィルタリングする方法を学びます。Syslog メッセージは、「ファシリティ（どのサブシステムがメッセージを生成したか）」と「優先度（メッセージの重大度）」によって分類されます。これらのカテゴリを理解することは、効率的なログ分析に不可欠です。
まず、Syslog のファシリティと優先度の概念を確認しましょう。
Syslog ファシリティ: ログメッセージのソースを示します。例として、kern（カーネルメッセージ）、user（ユーザーレベルのメッセージ）、mail（メールシステムメッセージ）、daemon（システムデーモンメッセージ）、auth（認証およびセキュリティメッセージ）、cron（クロックデーモンメッセージ）などがあります。
Syslog 優先度: メッセージの重大度を定義します。emerg（システム使用不可）から debug（デバッグレベルのメッセージ）まであります。重大度の高い順に、emerg、alert、crit、err、warning、notice、info、debug となります。
ログファイルは非常に大きくなる可能性があるため、特定の情報を見つけるのが困難になることがあります。そのため、フィルタリングが不可欠です。grep、awk、sed などのコマンドを使用して、ログファイルの内容をフィルタリングできます。
まず、less を使用して /var/log/messages の全内容を表示してみましょう。このコマンドを使用すると、ファイルをスクロールできます。less を終了するには q を押します。ログファイルの読み取りには root 権限が必要なため、sudo を使用することを忘れないでください。
sudo less /var/log/messages
次に、メッセージをフィルタリングしてみましょう。「認証」に関連するメッセージに興味があるとします。これらのメッセージは通常 /var/log/secure にあります。grep を使用して、/var/log/secure 内で「authentication」という単語を含む行を検索します。ログファイルにアクセスするために sudo を使用してください。
sudo grep "authentication" /var/log/secure
最近の認証メッセージがない場合、出力は表示されないかもしれません。SSH デーモンに関連する「sshd」のような、より一般的な検索語を試してみましょう。
sudo grep "sshd" /var/log/secure
SSH デーモンのアクティビティ、認証試行、またはその他のセキュリティ関連イベントを示す出力が表示されるはずです。正確な出力は現在のシステムアクティビティによって異なりますが、以下のようなエントリが含まれる可能性があります。
Dec 16 10:15:30 host sshd[1234]: Accepted publickey for labex from 172.25.0.10 port 12345 ssh2
Dec 16 10:15:30 host sshd[1234]: pam_unix(sshd:session): session opened for user labex(uid=1000) by (uid=0)
...output omitted...
ログメッセージにはタイムスタンプも含まれています。日付と時刻でメッセージをフィルタリングできます。例えば、特定の日付のメッセージを表示するには、grep と日付を組み合わせます。/var/log/messages で今日の日付のメッセージを見つけてみましょう。システムログに表示される現在の日付形式を使用してください。
sudo grep "$(date '+%b %d')" /var/log/messages
ログファイルのローテーション:
ログファイルがディスク容量を消費しすぎないように、システムは logrotate を使用します。このユーティリティはログファイルをローテーションし、古いファイルをリネーム（例: /var/log/messages が /var/log/messages-20220320 になる）して、新しい空のファイルを作成します。一定期間（通常は4週間）経過すると、最も古いローテーション済みログファイルは破棄されます。このプロセスを管理するために、スケジュールされたジョブが毎日 logrotate を実行します。
/var/log の内容を再度リスト表示することで、ローテーションされたログファイルを確認できます。日付拡張子や .gz 拡張子（圧縮されている場合）が付いたファイルが見えるかもしれません。
ls -l /var/log/messages*
出力例:
-rw-------. 1 root root 123456 Mar 20 23:59 /var/log/messages
-rw-------. 1 root root 78901 Mar 13 23:59 /var/log/messages-20220320
-rw-------. 1 root root 54321 Mar 06 23:59 /var/log/messages-20220313.gz
...output omitted...
これは logrotate が古いログファイルをどのように管理しているかを示しています。
最後に、syslog エントリの構造を分析しましょう。/var/log/secure 内の典型的なログメッセージは以下のようになっています。
Dec 16 10:11:48 host sshd[1433]: Failed password for student from 172.25.0.10 port 59344 ssh2
Dec 16 10:11:48: ログエントリのタイムスタンプ。host: ログメッセージを送信したホスト。sshd[1433]: ログメッセージを送信したプログラムまたはプロセス名 (sshd) とその PID (1433)。Failed password for …: 実際のメッセージ内容。
この形式を理解することで、ログエントリをより効果的に解析および解釈できるようになります。
カスタム syslog メッセージの手動送信
このステップでは、logger コマンドを使用してカスタム syslog メッセージを手動で送信する方法を学びます。これは、rsyslog サービスの設定をテストしたり、デバッグや監視の目的でシステムログにカスタムメッセージを挿入したりする際に便利なテクニックです。
logger コマンドは、rsyslog サービスにメッセージを送信します。デフォルトでは、-p オプションで指定しない限り、user ファシリティと notice 優先度 (user.notice) でメッセージを送信します。
まず、デフォルトのログ場所（通常は /var/log/messages）に簡単なテストメッセージを送信してみましょう。
logger "This is a test message from labex."
コマンドを実行した後、/var/log/messages ファイルを確認して、メッセージが記録されたことを確認できます。tail を使用してファイルの最後の数行を表示します。ログファイルにアクセスするために sudo を使用してください。
sudo tail /var/log/messages
出力の最後に、以下のようなカスタムメッセージが表示されるはずです。
...
Dec 16 10:30:00 host labex: This is a test message from labex.
次に、特定のファシリティと優先度を指定してメッセージを送信してみましょう。前のステップで学んだように、syslog メッセージはファシリティと優先度で分類されます。例えば、local7.notice は、メッセージが local7 ファシリティと notice 優先度で記録されることを意味します。local7 ファシリティはカスタムアプリケーションやブートメッセージによく使用され、通常は rsyslog 設定によって /var/log/boot.log に向けられます。
/var/log/boot.log ログファイルに記録されるように rsyslog サービスへメッセージを送信するには、以下の logger コマンドを実行します。
logger -p local7.notice "Log entry created by labex for boot.log"
次に、このメッセージが /var/log/boot.log に書き込まれたことを確認します。ログファイルにアクセスするために sudo を使用してください。
sudo tail /var/log/boot.log
出力にカスタムメッセージが表示されるはずです。
...
Dec 16 10:31:00 host labex: Log entry created by labex for boot.log
これは、ファシリティと優先度を指定することで、カスタムメッセージがどこに記録されるかを制御できることを示しています。この機能は、rsyslog 設定のテストや、システムログに特定のイベントを挿入する際に非常に役立ちます。
journalctl を使用したシステムジャーナルエントリの調査とフィルタリング
このステップでは、journalctl コマンドを使用してシステムジャーナルエントリを調査およびフィルタリングする方法を学びます。学んだように、systemd-journald サービスはログデータを「ジャーナル」と呼ばれる構造化されたインデックス付きのバイナリファイルに保存します。journalctl コマンドは、このジャーナルを操作するための主要なツールです。
まず、ジャーナル内のすべてのメッセージを表示してみましょう。オプションなしで journalctl を実行すると、最も古いエントリから順に、利用可能なすべてのログエントリが表示されます。labex として sudo 権限でログインしているため、ジャーナルへのフルアクセス権があります。
journalctl
大量の出力が表示されます。journalctl ビューアを終了するには q を押します。journalctl が重要なログメッセージを強調表示していることに注目してください。notice または warning 優先度のメッセージは太字で、error 優先度以上のメッセージは赤色で表示されます。
次に、エントリをフィルタリングして表示するための一般的な journalctl オプションをいくつか見ていきましょう。
1. 最後の N 件のログエントリを表示 (-n オプション):
デフォルトでは、journalctl -n は最後の 10 件のログエントリを表示します。数値を指定することもできます。例えば、最後の 5 件を表示する場合：
journalctl -n 5
最新の 5 件のログエントリが表示されるはずです。
2. 新しいジャーナルエントリを追跡 (-f オプション):
tail -f コマンドと同様に、journalctl -f オプションはシステムジャーナルの最後の 10 行を出力し、新しいジャーナルエントリが追加されるたびに出力を継続します。これはリアルタイム監視に非常に便利です。
journalctl -f
この継続的な出力を終了するには、Ctrl+C を押します。
3. 優先度でフィルタリング (-p オプション):
ジャーナルエントリの優先度レベルで出力をフィルタリングできます。journalctl -p オプションは、指定された優先度レベル（名前または番号）以上のエントリを表示します。優先度レベルは、昇順で debug、info、notice、warning、err、crit、alert、emerg です。
err 優先度以上のジャーナルエントリをリスト表示してみましょう。
journalctl -p err
さまざまなシステムコンポーネントに関連するエラーメッセージが表示されるかもしれません。
4. systemd ユニットでフィルタリング (-u オプション):
journalctl -u オプションとユニット名を使用することで、指定した systemd ユニットのメッセージを表示できます。例えば、sshd サービスのログを具体的に表示するには：
journalctl -u sshd.service
これにより、SSH デーモンに関連するすべてのログエントリが表示されます。
5. 時間範囲でフィルタリング (--since および --until オプション):
特定のイベントを探す際、出力を特定の時間枠に制限できます。--since および --until オプションは、"YYYY-MM-DD hh:mm:ss" 形式の時間引数を取ります。引数にスペースが含まれる場合は二重引用符が必要です。yesterday、today、tomorrow のような相対的な用語や、"-1 hour" のような時間間隔も使用できます。
今日の初めからのすべてのジャーナルエントリを表示してみましょう。
journalctl --since today
次に、過去 1 時間のエントリを表示してみましょう。
journalctl --since "-1 hour"
6. 詳細な出力を表示 (-o verbose オプション):
内部ジャーナルフィールドを含む各ログエントリの詳細を確認するには、-o verbose オプションを使用できます。これは高度なトラブルシューティングに役立ちます。
journalctl -n 1 -o verbose
これにより、最後のログエントリが詳細情報とともに表示されます。_COMM（コマンド名）、_EXE（実行可能ファイルへのパス）、_PID（プロセス ID）、_UID（ユーザー ID）、_SYSTEMD_UNIT（systemd ユニット）などのフィールドに注目してください。これらのフィールドは、より正確なフィルタリングに使用できます。
例えば、特定の PID を持つ sshd プロセスからのエントリを見つけるには（PID は以前の journalctl -u sshd.service の出力から取得できます）：
journalctl _SYSTEMD_UNIT=sshd.service _PID=<PID_NUMBER>
<PID_NUMBER> を sshd エントリから確認した実際の PID に置き換えてください。例えば、sshd[1433] を確認した場合は、_PID=1433 を使用します。
journalctl _SYSTEMD_UNIT=sshd.service _PID=1433
このコマンドは、複数のフィルタを組み合わせてジャーナル内の検索を絞り込む方法を示しています。
永続的なシステムジャーナルストレージの設定
このステップでは、再起動後もシステムジャーナルが保持されるように設定する方法を学びます。デフォルトでは、Red Hat Enterprise Linux 9 はシステムジャーナルを一時ファイルシステムである /run/log ディレクトリに保存します。つまり、システムを再起動するとすべてのジャーナルエントリが消去されます。過去のログデータを保持するには、永続ストレージ用に systemd-journald サービスを設定する必要があります。
systemd-journald の設定は /etc/systemd/journald.conf ファイルにあります。このファイル内の Storage パラメータは、ジャーナルを揮発的に保存するか、永続的に保存するかを決定します。
Storage パラメータには以下のいずれかの値を設定できます。
persistent: ジャーナルを/var/log/journalディレクトリに保存します。これは再起動後も保持されます。このディレクトリが存在しない場合、systemd-journaldが作成します。volatile: ジャーナルを一時的な/run/log/journalディレクトリに保存します。/run内のデータは再起動後に保持されません。Storageが明示的に設定されておらず、/var/log/journalが存在しない場合のデフォルトの動作です。auto:/var/log/journalディレクトリが存在する場合、systemd-journaldは永続ストレージを使用します。存在しない場合は揮発性ストレージを使用します。Storageパラメータを設定しない場合のデフォルトです。none: ストレージは使用されません。すべてのログは破棄されますが、転送することは可能です。
/etc/systemd/journald.conf ファイルを修正して、永続的なジャーナルストレージを有効にしましょう。sudo nano を使用してこのファイルを編集します。
sudo nano /etc/systemd/journald.conf
nano エディタ内で [Journal] セクションを探します。Storage 行のコメントアウトを解除し（先頭の # を削除）、値を persistent に設定します。
ファイルは以下のようになっているはずです（関連する行のみ表示）。
[Journal]
Storage=persistent
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=1000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#Audit=no
#FlushIntervalSec=
#SyncIntervalSec=
#ReadKMsg=yes
#Audit=yes
変更後、Ctrl+X を押し、Y で保存を確認し、Enter でファイル名を確定して保存します。
変更を反映させるには systemd-journald サービスを再起動する必要があります。この環境は Docker コンテナであるため systemctl は使用できません。代わりに、非コンテナ環境でサービス再起動時に行われる処理と同様に、/var/log/journal ディレクトリが作成され、正しい権限が設定されていることを確認することで、サービス再起動の効果をシミュレートします。
まず、ディレクトリが存在しない場合は作成し、適切な権限を設定します。
sudo mkdir -p /var/log/journal
sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal
次に、永続ストレージが設定されアクティブであることを確認するために、/var/log/journal ディレクトリに 16 進数の名前を持つサブディレクトリと .journal ファイルが含まれているかを確認します。これらのファイルには、構造化されインデックス化されたジャーナルエントリが保存されます。
ls -l /var/log/journal
長い 16 進数の名前（例: 4ec03abd2f7b40118b1b357f479b3112）を持つサブディレクトリが表示されるはずです。このディレクトリ内に .journal ファイルがあります。
ls -l /var/log/journal/ <YOUR_HEX_ID> /
<YOUR_HEX_ID> を前の ls コマンドの出力で見つけた実際の 16 進数 ID に置き換えてください。例えば：
ls -l /var/log/journal/4ec03abd2f7b40118b1b357f479b3112/
system.journal や、場合によっては user-1000.journal のようなファイルが表示されるはずです。
永続ジャーナルであっても、システムはすべてのデータを永久に保持するわけではありません。ジャーナルには組み込みのログローテーションメカニズムがあります。/etc/systemd/journald.conf ファイルで SystemMaxUse、SystemKeepFree、SystemMaxFileSize、MaxRetentionSec などのパラメータを使用して、サイズ制限や保持期間を設定できます。
最後に、永続ジャーナルが有効な場合、journalctl の出力には現在のシステムブートだけでなく、以前のシステムブートのエントリも含まれます。特定のシステムブートに限定するには、journalctl -b オプションを使用します。
認識されているすべてのシステムブートイベントをリスト表示するには：
journalctl --list-boots
ブート ID とそれに対応する時間範囲のリストが表示されます。現在のブートは通常 0 です。以前のブートは負の数（-1、-2 など）になります。
現在のシステムブートのエントリのみを表示するには：
journalctl -b
以前のブート（現在のブートの 1 つ前、通常は -1）のエントリを表示するには：
journalctl -b -1
これで、永続ジャーナルストレージの設定は完了です。
timedatectl と chronyd を使用した正確なシステム時刻の維持
このステップでは、timedatectl コマンドを使用して正確なシステム時刻を維持する方法と、chronyd サービスの役割について学びます。正確な時刻管理は、ロギング、セキュリティ、および多くのネットワークサービスにとって非常に重要です。
1. timedatectl を使用したシステム時刻とタイムゾーンの管理:
timedatectl コマンドは、ローカル時刻、協定世界時 (UTC)、RTC 時刻、タイムゾーン、NTP 同期ステータスなど、現在の時刻関連のシステム設定の概要を提供します。
システムの現在の時刻設定を確認してみましょう。
timedatectl
以下のような出力が表示されるはずです（正確な時刻と日付は現在のシステム時刻を反映します）。
Local time: Sun 2025-06-15 21:46:11 EDT
Universal time: Mon 2025-06-16 01:46:11 UTC
RTC time: Mon 2025-06-16 01:46:10
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
list-timezones オプションを使用して、利用可能なすべてのタイムゾーンをリスト表示できます。
timedatectl list-timezones | less
less を終了するには q を押します。タイムゾーンは、Internet Assigned Numbers Authority (IANA) タイムゾーンデータベースに基づいて、通常は大陸/海洋、その後に主要都市という形式で命名されています。
システムのタイムゾーンを変更するには、set-timezone オプションを使用します。例えば、タイムゾーンを America/Phoenix に変更してみましょう。これには sudo 権限が必要です。
sudo timedatectl set-timezone America/Phoenix
変更を確認します。
timedatectl
タイムゾーンが America/Phoenix に更新されているはずです。
手動でシステム時刻を変更する前に、一時的に NTP 同期を無効にする必要があります。set-ntp オプションは、自動時刻調整のための NTP 同期を有効または無効にします。引数として true または false を取ります。一時的に NTP 同期を無効にしてみましょう（後で再度有効にします）。
sudo timedatectl set-ntp false
NTP サービスのステータスを確認します。
timedatectl
NTP service: inactive と表示されるはずです。
これで、set-time オプションを使用してシステムの手動時刻を設定できます。形式は "YYYY-MM-DD hh:mm:ss" ですが、日付や時刻を省略することも可能です。時刻を 09:00:00 に設定してみましょう（現在の日付に対して）。
sudo timedatectl set-time 09:00:00
時刻の変更を確認します。
timedatectl
2. chronyd サービスの理解と設定:
chronyd サービスは、Network Time Protocol (NTP) サーバーと同期することで、システムのリアルタイムクロック (RTC) を正確に保つデーモンです。Red Hat Enterprise Linux のデフォルトの NTP クライアントです。
chronyd の設定ファイルは /etc/chrony.conf です。デフォルトではパブリック NTP サーバーを使用します。実際の環境では、内部 NTP サーバーを使用するように設定する場合があります。
デフォルトの chrony.conf ファイルを表示してみましょう。
cat /etc/chrony.conf
server または pool で始まる行が表示され、NTP ソースが定義されています。iburst オプションは、より正確な初期同期のために 4 回の測定を迅速に行うため、推奨されます。
NTP タイムソースの stratum はその品質を示します。stratum 0 は基準クロック、stratum 1 は基準クロックに直接接続されており、stratum 2 は stratum 1 サーバーから同期します。
このコンテナ環境では systemctl が使用できないため、設定変更を適用するために chronyd を直接再起動することはできません。しかし、ファイルを修正することで設定変更をシミュレートできます。
timedatectl を使用して NTP 同期を再度有効にしましょう。
sudo timedatectl set-ntp true
NTP サービスのステータスを再度確認します。
timedatectl
NTP service: active と表示されるはずです。
chronyc コマンドは chronyd サービスへのクライアントとして機能します。これを使用して同期ステータスを監視できます。chronyc sources コマンドは、現在のタイムソースとその同期ステータスを表示します。
chronyc sources -v
出力には NTP ソースに関する詳細が表示されます。S (ソース状態) フィールドのアスタリスク * は、chronyd が現在同期しているソースを示します。
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current best, '+' = combined, '-' = not combined,
| / 'x' = may be in error, '~' = too variable, '?' = unusable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 100.100.61.88 1 5 377 16 +1824us[+2180us] +/- 85ms
...output omitted...
この出力は、システムが NTP サーバーとアクティブに時刻同期していることを確認しています。
まとめ
この実験では、systemd-journald と rsyslog の相互作用に焦点を当て、Red Hat Enterprise Linux 9 におけるシステムログのアーキテクチャを包括的に理解しました。systemd-journald が構造化されたインデックス付きのバイナリログをジャーナルに収集・保存し、rsyslog がこれらのメッセージを処理して /var/log 内の従来のログファイルに書き込むことを学びました。/var/log/messages、/var/log/secure などの主要なログファイルを調査し、一般的なコマンドを使用して syslog ファイルを確認・フィルタリングする練習を行いました。また、カスタム syslog メッセージを手動で送信する方法も学びました。
さらに、journalctl を使用してシステムジャーナルエントリを調査・フィルタリングし、詳細なシステムイベントにアクセスする機能を理解しました。その後、再起動後もログデータを保持できるように、永続的なシステムジャーナルストレージを設定しました。最後に、timedatectl と chronyd を使用して正確なシステム時刻を維持する方法を扱い、正確なログタイムスタンプとシステム全体の整合性にとっての重要性を認識しました。この実験を通じて、堅牢なログ管理による効果的なシステム分析とトラブルシューティングに必要なスキルを習得しました。
