はじめに
この実験（Lab）では、journalctl と rsyslog を使用して、Red Hat Enterprise Linux 9 上でシステムログを分析し、保存する実践的な経験を積みます。まず、systemd-journald と rsyslog の役割を含むシステムロギングのコアアーキテクチャを理解し、主要なログファイルを特定することから始めます。次に、一般的なコマンドを使用して syslog ファイルをレビューおよびフィルタリングする方法、カスタム syslog メッセージを手動で送信する方法を学びます。また、journalctl を使用してシステムジャーナルエントリを探索し、フィルタリングする方法も学びます。この実験（Lab）では、永続的なシステムジャーナルストレージの設定と、timedatectl および chronyd を使用した正確なシステム時間の維持についても取り上げます。これにより、システム分析とトラブルシューティングに不可欠なスキルを習得できます。
システムログアーキテクチャと主要ファイルの理解
このステップでは、Red Hat Enterprise Linux 9 におけるシステムロギングの基本的なコンポーネントについて学びます。具体的には、systemd-journald および rsyslog サービス、そしてそれらが管理する主要なログファイルに焦点を当てます。このアーキテクチャを理解することは、効果的なシステム分析とトラブルシューティングに不可欠です。
まず、systemd-journald サービスを見てみましょう。このサービスは、オペレーティングシステムのイベントロギングの中核を担っています。システムカーネル、初期ブートプロセス、デーモンの標準出力/エラー、および syslog イベントなど、さまざまなソースからのイベントメッセージを収集します。systemd-journald サービスは、これらのログを「ジャーナル」（journal）と呼ばれる構造化されたインデックス付きバイナリファイルに保存します。
次に、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 メッセージは、facility（メッセージを生成するサブシステム）と priority（メッセージの重大度）によって分類されます。効率的なログ分析には、これらのカテゴリを理解することが不可欠です。
まず、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
次に、メッセージをフィルタリングしてみましょう。authentication に関連するメッセージに関心があるとします。これらのメッセージは通常、/var/log/secure にあります。grep を使用して、/var/log/secure で「authentication」という単語を含む行を検索します。ログファイルにアクセスするには、sudo を使用することを忘れないでください。
sudo grep "authentication" /var/log/secure
最近の認証メッセージがない場合、出力が表示されない可能性があります。より一般的な検索語である「sshd」を試してみましょう。これは、SSH デーモンに関連しています。
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 を実行すると、最も古いものから始めて、利用可能なすべてのログエントリが表示されます。sudo 権限を持つ labex としてログインしているため、ジャーナルへのフルアクセス権があります。
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 プロセスからのエントリを見つけるには（以前の journalctl -u sshd.service の出力から PID を取得できます）。
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 ディレクトリが作成され、適切な権限を持っていることを確認することにより、サービスの再起動の効果をシミュレートします。これは、非コンテナ化された環境で systemd-journald が再起動時に行うことです。
まず、ディレクトリが存在しない場合は作成し、適切な権限を設定しましょう。
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）からのエントリを表示するには、次のようにします。
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
q を押して less を終了します。タイムゾーンは、Internet Assigned Numbers Authority（IANA）タイムゾーンデータベースに基づいて、通常は大陸/海洋、次に最大の都市で名前が付けられます。
システムのタイムゾーンを変更するには、set-timezone オプションを使用します。たとえば、タイムゾーンを America/Phoenix に変更してみましょう。これには sudo 権限が必要です。
sudo timedatectl set-timezone America/Phoenix
次に、変更を確認します。
timedatectl
タイムゾーンが America/Phoenix に更新されているはずです。
set-time オプションを使用して、システムの現在の時間を手動で設定することもできます。形式は「YYYY-MM-DD hh:mm:ss」ですが、日付または時間を省略できます。時間を 09:00:00（現在の日付の場合）に設定してみましょう。
sudo timedatectl set-time 09:00:00
時間の変更を確認します。
timedatectl
最後に、set-ntp オプションは、自動時間調整のために NTP 同期を有効または無効にします。引数として true または false を受け取ります。しばらくの間、NTP 同期を無効にしましょう（後で再度有効にします）。
sudo timedatectl set-ntp false
NTP サービスのステータスを確認します。
timedatectl
NTP service: inactive と表示されるはずです。
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
NTP ソースを定義する server または pool で始まる行が表示されます。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（Source state）フィールドの星印 * は、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 サーバーと積極的に時間を同期していることを確認します。
まとめ
この実験では、Red Hat Enterprise Linux 9 のシステムログアーキテクチャについて包括的に理解を深め、systemd-journald と rsyslog の相互作用に焦点を当てました。systemd-journald が構造化されたインデックス付きバイナリログをジャーナルに収集して保存し、rsyslog がこれらのメッセージを処理して /var/log の従来のログファイルに書き込むことを学びました。/var/log/messages、/var/log/secure などの主要なログファイルを調べ、一般的なコマンドを使用して syslog ファイルのレビューとフィルタリングを実践しました。また、カスタム syslog メッセージを手動で送信する方法も学びました。
さらに、journalctl を使用してシステムジャーナルエントリを探索およびフィルタリングし、詳細なシステムイベントにアクセスするためのその機能を理解しました。その後、再起動後もログデータを保持するために、永続的なシステムジャーナルストレージを設定しました。最後に、timedatectl と chronyd を使用して正確なシステム時間を維持することを取り上げ、正確なログタイムスタンプとシステム全体の整合性にとってのその重要性を認識しました。この実験は、堅牢なログ管理を通じて、効果的なシステム分析とトラブルシューティングのための不可欠なスキルを提供しました。
