journalctl rsyslog LinuC102 第7回

LinuC レベル1 102試験対策シリーズの第7回です。前回は定期実行と時刻同期を扱い、「いつ動かすか」と「正しい時刻か」を整えました。今回は 「動いた結果をどう残し、どう調べるか」 ── つまり ログ管理 です。Linux のログには systemd-journald と rsyslog の2系統があり、現代の RHEL系は 両者を併用 しています。

本記事では journalctl の絞り込み技、/etc/rsyslog.conf の facility / severity 構文、logger でシェルから書く方法、リモート syslog 転送、そして logrotate までを実機で読み解きます。

今ここマップ

LinuC 102 試験対策シリーズ（全12回）

  第1回 シェル環境のカスタマイズ
  第2回 Bashスクリプト入門
  第3回 ネットワーク基礎
  第4回 ネットワークトラブルシューティングとDNS
  第5回 ユーザ・グループ管理と sudo 設定
  第6回 ジョブスケジューリングと時刻管理
▶ 第7回 ログ管理実践    ← いまここ
  第8回 メール配送エージェント(MTA)の基本
  第9回 ファイアウォールと SELinux 入門
  第10回 暗号化によるデータ保護
  第11回 クラウドセキュリティの基礎
  第12回 オープンソースの文化

この記事で身につくこと

1. systemd-journald と rsyslog の役割を区別して説明できる
2. journalctl -u/-p/-S/-U/-b/-f でログを絞り込める
3. /etc/rsyslog.conf の facility / severity / action を読める
4. logger でシェルから syslog にログを書ける
5. リモート syslog 転送の書式（@@host/@host）の意味を説明できる

第1章：なぜログが運用の生命線なのか

1.1 ログが無いと困る4つの場面

「動いている／動いていない」しか分からない状態を想像してみてください。「なぜ動かなくなったのか」「いつから」「誰が／何が起因したのか」 が一切分からない世界です。実際の現場では次のような場面でログが調査の起点になります。

• 運用担当のため：障害復旧。サービス停止直前のエラーメッセージ・カーネルログ・OOM Killer の動作を追う
• セキュリティ担当のため：不正アクセス調査。/var/log/secure の認証失敗、sudo 履歴、auditd の監視対象アクセス
• 開発担当のため：性能問題の調査。アプリログのレスポンスタイム、エラー率、外部 API 失敗の頻度
• 監査担当のため：法的・コンプライアンス要求。「いつ・誰が・何にアクセスしたか」を一定期間保存する義務

第6回で扱った 時刻同期 が前提として効きます。複数台のサーバのログを時系列で並べるには、全サーバの時刻が NTP で揃っている必要があるからです。

第2章：systemd-journald と rsyslog の2層構造

2.1 役割分担

現代の RHEL系では、ログを扱う2つのソフトウェアが 連携して 動作しています。

両者が稼働中であることを実機で確認します。

実行コマンド（linuc-alma）：

$ systemctl is-active systemd-journald
$ systemctl is-active rsyslog
$ systemctl is-enabled rsyslog

実行結果：

active
active
enabled

systemd-journald は static（systemd の一部として常駐、enable/disable の対象外）、rsyslog は enabled（独立サービス、再起動後も自動起動）になります。

2.2 「logger」 → journald → rsyslog のパス

AlmaLinux 9 の rsyslog は、imjournal モジュール 経由で journald からログを取り込み、/var/log/messages 等に書き出す構成です。logger コマンドの出力は次のパスをたどります。

logger / アプリ → systemd-journald → rsyslog (imjournal) → /var/log/messages 等

つまり同じイベントが journal にもファイルにも残る。journalctl で構造化検索、grep でファイル検索、どちらも可能というわけです。

2.3 journald の永続化 ── 既定は揮発

AlmaLinux 9 既定では /var/log/journal/ が 存在しません。この場合、journald は Storage=auto の動作として /run/log/journal/ に書きます。/run は tmpfs なので再起動でジャーナルが消えます。

実行コマンド（linuc-alma）：

$ ls -la /var/log/journal/ 2>&1
$ ls /run/log/journal/

実行結果：

ls: '/var/log/journal/' にアクセスできません: そのようなファイルやディレクトリはありません
9675dfbf54f14d9ebfa704b59841fc8f

永続化したい場合は次の手順を踏みます（本記事では実行しない）。

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

運用上は、テキストでの長期保管は rsyslog 側に任せ、journald は直近の構造化ログ用 という分担が多いです。

第3章：journalctl 使いこなし

3.1 最新数件と新しい順

引数なしの journalctl は全ログをページングして表示しますが、運用では「直近の数件だけ」「特定ユニットだけ」を見るケースがほとんどです。

実行コマンド（linuc-alma）：

$ journalctl -n 5 --no-pager

実行結果（採取時点の例）：

 5月 14 08:03:59 linuc-alma systemd-logind[730]: Removed session 58.
 5月 14 08:03:59 linuc-alma sshd[13146]: Accepted publickey for developer from 192.168.1.100 port 57494 ssh2: ED25519 SHA256:...
 5月 14 08:03:59 linuc-alma systemd-logind[730]: New session 60 of user developer.
 5月 14 08:03:59 linuc-alma systemd[1]: Started Session 60 of User developer.
 5月 14 08:03:59 linuc-alma sshd[13146]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)

--no-pager はページングを止める（端末をクリアしない）。スクリプト・SSH 経由では必須です。-r を付けると新しい順になります。

3.2 ユニット指定 ── サービス単位で見る

実行コマンド（linuc-alma）：

$ journalctl -u crond -n 5 --no-pager

実行結果（例）：

 5月 14 07:01:01 linuc-alma run-parts[13089]: (/etc/cron.hourly) finished 0anacron
 5月 14 07:01:01 linuc-alma CROND[13079]: (root) CMDEND (run-parts /etc/cron.hourly)
 5月 14 08:01:01 linuc-alma CROND[13102]: (root) CMD (run-parts /etc/cron.hourly)
 5月 14 08:01:01 linuc-alma run-parts[13105]: (/etc/cron.hourly) starting 0anacron
 5月 14 08:01:01 linuc-alma CROND[13101]: (root) CMDEND (run-parts /etc/cron.hourly)

-u "nginx*" のようにワイルドカードも使えます。sshd、NetworkManager、rsyslog、chronyd 等、調査対象のサービスを直接指定するのが定石です。

3.3 優先度フィルタ ── エラー以上を抽出

syslog の severity（重要度）8段階で絞れます。

-p err は「err（3）以上」、つまり err / crit / alert / emerg を意味します。

実行コマンド（linuc-alma）：

$ journalctl -p err -b --no-pager | head

実行結果（例。表示される行は環境やブート以降の操作履歴によって異なる）：

 5月 09 19:04:16 linuc-alma kernel: Warning: Unmaintained driver is detected: ip_set
 5月 09 19:17:32 linuc-alma sudo[950]: developer : a password is required ; PWD=/home/developer ; USER=root ; COMMAND=/bin/true
 5月 09 19:24:23 linuc-alma systemd[1]: Failed to start dnf makecache.

journalctl -p err -b は障害調査の最初の一手です。今回のブート（-b）で発生した err 以上を一覧でき、原因の見当がつきやすくなります。表示される具体的な行は、そのブート以降に何が起きたかによって変わります（上記はインストール直後のブートの例で、SSH 接続失敗などがあればその行も並びます）。

3.4 時刻範囲とブート単位

journalctl --since "1 hour ago" -u sshd のように複数フィルタを AND結合 できるのが journalctl の強みです。

3.5 ディスク使用量

実行コマンド（linuc-alma）：

$ journalctl --disk-usage

実行結果（例）：

Archived and active journals take up 9.9M in the file system.

容量が大きくなりすぎると SystemMaxUse=（既定はディスクの10%）で自動削除されます。手動削除は journalctl --vacuum-size=100M や --vacuum-time=2weeks で可能です。

第4章：rsyslog ── facility / severity / action

4.1 syslog の3要素

syslog プロトコル（RFC 5424 / RFC 3164）はメッセージを次の3要素で分類します。

• facility（出力元の分類）：誰が出したか
• severity（重要度）：どのくらい深刻か
• action（出力先）：どこに書くか

4.2 facility 一覧

自社アプリは local0〜local7 を使うのが慣例です。auth と authpriv の違いは「authpriv は root しか読めない（パスワード関連の機密を扱う）」点で、現代ではほぼ全て authpriv に集約されています。

4.3 /etc/rsyslog.conf を読む

コメント・空行を除いた主要行を見ます。

実行コマンド（linuc-alma）：

$ cat /etc/rsyslog.conf | grep -v '^#' | grep -v '^$'

実行結果：

global(workDirectory="/var/lib/rsyslog")
module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat")
module(load="imuxsock" 	  # provides support for local system logging (e.g. via logger command)
       SysSock.Use="off") # Turn off message reception via local log socket;
			  # local messages are retrieved through imjournal now.
module(load="imjournal" 	    # provides access to the systemd journal
       UsePid="system" # PID nummber is retrieved as the ID of the process the journal entry originates from
       FileCreateMode="0644" # Set the access permissions for the state file
       StateFile="imjournal.state") # File to store the position in the journal
include(file="/etc/rsyslog.d/*.conf" mode="optional")
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 :omusrmsg:*
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log

下半分の7行が facility.severity action ルールです。重要な書式を解説します。

• *.info;mail.none;authpriv.none;cron.none /var/log/messages：「info以上を /var/log/messages へ。ただし mail / authpriv / cron は .none で除外」。; で複数条件を結合
• authpriv.* /var/log/secure：authpriv の全 severity を /var/log/secure へ
• mail.* -/var/log/maillog：先頭の - は「同期書き込みしない」（性能優先、クラッシュ時の損失許容）
• *.emerg :omusrmsg:*：emerg は全ユーザ端末に wall 通知
• local7.* /var/log/boot.log：local7 の全 severity を /var/log/boot.log へ（init/systemd の起動メッセージ用）

4.4 facility.severity の特殊指定

4.5 /etc/rsyslog.d/ ── パッケージごとの分割

rsyslog.conf 末尾近くの include(file="/etc/rsyslog.d/*.conf" mode="optional") によって、/etc/rsyslog.d/ 配下の *.conf ファイルが自動的に読み込まれます。新規ルールは本体を編集せず、ここに新規ファイルを置くのが推奨です（第5回 sudoers の /etc/sudoers.d/ と同じ思想）。

第5章：/var/log/ の主要ファイル

実行コマンド（linuc-alma）：

$ sudo ls -la /var/log/{messages,secure,cron,maillog,boot.log} 2>&1

実行結果（例）：

ls: '/var/log/boot.log' にアクセスできません: そのようなファイルやディレクトリはありません
-rw-------. 1 root root   6801  5月 14 08:01 /var/log/cron
-rw-------. 1 root root      0  5月  9 18:45 /var/log/maillog
-rw-------. 1 root root 287416  5月 14 08:03 /var/log/messages
-rw-------. 1 root root  45383  5月 14 08:03 /var/log/secure

パーミッションは 0600（root のみ）。boot.log は Minimal Install のサーバ用途では空のため作られていません。maillog は MTA 未稼働で0バイト（次回第8回で postfix を導入すると育ちます）。

ローテーション後の圧縮ファイル（messages-20260513.gz 等）は zcat zless zgrep で直接読めます。

第6章：logger と systemd-cat ── シェルから書く

6.1 logger コマンド

logger はシェルから syslog にメッセージを送るコマンドです。バックアップスクリプトや監視スクリプトから「実行した」「失敗した」を残すのに便利です。

実行コマンド（linuc-alma）：

$ logger -p user.notice -t LinuC-test "LinuC test message from alma (notice)"
$ logger -p user.err -t LinuC-test "LinuC error test from alma"

主なオプションは次のとおりです。

journalctl で確認します。

実行コマンド（linuc-alma）：

$ journalctl -t LinuC-test -n 5 --no-pager

実行結果：

 5月 14 08:03:59 linuc-alma LinuC-test[13204]: LinuC test message from alma (notice)
 5月 14 08:03:59 linuc-alma LinuC-test[13205]: LinuC error test from alma

同じメッセージが /var/log/messages にも届いていることを確認します。

実行コマンド（linuc-alma）：

$ sudo tail -10 /var/log/messages | grep LinuC-test

実行結果：

May 14 08:03:59 linuc-alma LinuC-test[13204]: LinuC test message from alma (notice)
May 14 08:03:59 linuc-alma LinuC-test[13205]: LinuC error test from alma

これが 「logger → journald → rsyslog → /var/log/messages」 の2層構造を実機で見た瞬間です。同じ1行が2箇所に届いています。

6.2 systemd-cat ── 標準出力を journal にリダイレクト

シェルスクリプトの標準出力／標準エラー出力をまとめて journal に書き込むには systemd-cat が便利です。

$ systemd-cat -t mybackup -p info /opt/scripts/backup.sh

これで backup.sh の出力すべてが mybackup タグで journal に流れ、journalctl -t mybackup で後から確認できます。

第7章：リモート syslog 転送

7.1 なぜログを集約するのか

サーバが数十台・数百台あると、1台ずつログを見るのは現実的ではありません。すべてのログを1箇所に集約 して、検索・相関分析する仕組みが必要です。代表例は次のとおりです。

• rsyslog の @@/@ 転送：もっとも軽量。ファイルに書く代わりにリモートホストへ syslog を送る
• SIEM 製品（Splunk、Elastic SIEM 等）：セキュリティ用途の集約＋分析
• ログ基盤（Elasticsearch + Fluentd、Grafana Loki、CloudWatch Logs 等）：開発・運用用途

7.2 rsyslog の転送書式

rsyslog で他サーバへ送る書式は次のとおりです。

覚え方は 「@ 2つで TCP」「@ 1つで UDP」。試験でも頻出です。ポート省略時の既定は 514。

7.3 設定例（送信側）

linuc-alma から linuc-ubuntu（10.0.10.133）に転送する場合の /etc/rsyslog.d/50-forward.conf の例（本記事では作成はしません、書式の例示のみ）。

# 全ログを TCP で linuc-ubuntu に転送（再接続バッファ付き）
*.* action(type="omfwd"
           target="10.0.10.133"
           port="514"
           protocol="tcp"
           action.resumeRetryCount="100"
           queue.type="LinkedList"
           queue.size="10000")

古い書式 *.* @@10.0.10.133:514 でも動きますが、現代の rsyslog では action() ベースの構文が推奨です。queue.type で「受信側ダウン時のメッセージを送信側で保持する」リトライ機構を組み込めます。

7.4 受信側の準備（参考）

受信側 linuc-ubuntu 側では、次の3点が必要です。本記事では実施しませんが、概念として把握してください。

• rsyslog の imtcp モジュールを有効化（module(load="imtcp") + input(type="imtcp" port="514")）
• firewalld / ufw でポート 514/tcp を開放
• 受信したログをホスト名ごとに分離するテンプレート設定（任意）

第8章：logrotate ── ログのサイズ管理

8.1 logrotate.conf の主要ディレクティブ

第6回で扱った logrotate.timer（systemd timer）の本体が logrotate コマンドで、/etc/logrotate.conf を読みます。

実行コマンド（linuc-alma）：

$ cat /etc/logrotate.conf | grep -v '^#' | grep -v '^$' | head

実行結果（抜粋）：

weekly
rotate 4
create
dateext
include /etc/logrotate.d

主なディレクティブの意味は次のとおりです。

8.2 /etc/logrotate.d/ の分割設定

パッケージごとの個別設定が並びます。

実行コマンド（linuc-alma）：

$ ls /etc/logrotate.d/

実行結果：

btmp  chrony  dnf  firewalld  kvm_stat  rsyslog  sssd  wtmp

新しいアプリを導入したら、必ず /etc/logrotate.d/<アプリ名> を追加するのが運用の鉄則です。

8.3 dry-run で安全に検証する

-d でデバッグ実行（実ファイル変更なし）できます。新規 logrotate 設定を追加した後に必ず走らせる定型操作です。

実行コマンド（linuc-alma）：

$ sudo logrotate -d /etc/logrotate.conf 2>&1 | head -10

実行結果（抜粋）：

WARNING: logrotate in debug mode does nothing except printing debug messages!
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file btmp
reading config file chrony
reading config file dnf
reading config file firewalld
reading config file kvm_stat
reading config file rsyslog
reading config file sssd

「設定ファイルの構文エラーが無い」「対象ログがどれか」を事前に確認できます。

第9章：現場での使いどころ

現場での使いどころ

• 障害調査の起点：journalctl -p err -b でブート以降の err 以上を一覧。次に journalctl -u 怪しいサービス --since "10 min ago" で時刻を絞る
• 認証失敗の追跡：sudo grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -rn でブルートフォース攻撃の発信元IPを集計
• 集約ログ基盤への送信：rsyslog の @@/@ 転送で Splunk / Elasticsearch / CloudWatch Logs / Grafana Loki にまとめる。1サーバあたりの保存はせず、保管・検索は集約側に任せる構成
• セキュリティインシデントの最初の20分：/var/log/secure の認証ログ → sudo 実行履歴 → 該当時刻の journalctl -u sshd → 該当IPからのアクセス全件
• アプリログを syslog に統合：自社アプリの開発時に「local0〜local7」のどれかを割り当て、logger -p local0.info で書く。集約基盤への送信ルートに乗る
• logrotate の運用：新規アプリ追加時に /etc/logrotate.d/<アプリ名> を必ず作る。logrotate -d で構文・対象を確認
• journald の永続化判断：本番サーバで再起動時のログを失いたくない場合は /var/log/journal/ を作成して永続化。クラウドの短命インスタンスや揮発させて構わない用途では既定のまま

第10章：ヒヤリハット

$ df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/...  20G   20G    0G 100% /var

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp myapp
    postrotate
        systemctl reload myapp >/dev/null 2>&1 || true
    endscript
}

第11章：やってみよう

linuc-alma にログインして次の4つの演習を順に実行してください。所要時間は20〜30分です。すべて読み取りまたは logger による軽量な書き込みのみで、システム設定は変更しません。

演習1：journalctl のフィルタを試す

実行コマンド（linuc-alma）：

$ journalctl -n 5 --no-pager
$ journalctl -u sshd -n 5 --no-pager
$ journalctl -p err -b --no-pager | head
$ journalctl --since "1 hour ago" -n 5 --no-pager
$ journalctl --disk-usage
$ journalctl --list-boots --no-pager

確認ポイント：

• 直近5件と、sshd 関連だけ、err 以上だけ、それぞれ違う結果が出る
• disk-usage で journal の容量が見える
• list-boots で最初のブート以降1つしかブートIDが無い（このVMは再起動していない／永続化していないため）

演習2：rsyslog の設定を読む

実行コマンド（linuc-alma）：

$ cat /etc/rsyslog.conf | grep -v '^#' | grep -v '^$'
$ ls /etc/rsyslog.d/
$ sudo ls -la /var/log/{messages,secure,cron,maillog} 2>&1
$ sudo tail -3 /var/log/messages
$ sudo tail -3 /var/log/secure

確認ポイント：

• 7行の facility.severity ルールがどのファイルに何を書いているか
• /etc/rsyslog.d/ は空（パッケージ追加時にここにファイルが増える）
• 主要ログの所有者は root、パーミッションは 0600

演習3：logger でシェルから書く

実行コマンド（linuc-alma）：

$ logger -p user.notice -t my-test "Hello from $(whoami)"
$ logger -p user.err -t my-test "Error simulation"
$ journalctl -t my-test -n 3 --no-pager
$ sudo tail -10 /var/log/messages | grep my-test

確認ポイント：

• journalctl と /var/log/messages の 両方 に同じメッセージが届く
• タグ my-test が表示される
• これが「logger → journald → rsyslog → /var/log/messages」の2層構造

演習4：logrotate を読む（dry-run）

実行コマンド（linuc-alma）：

$ cat /etc/logrotate.conf | grep -v '^#' | grep -v '^$' | head -10
$ ls /etc/logrotate.d/
$ cat /etc/logrotate.d/rsyslog
$ sudo logrotate -d /etc/logrotate.conf 2>&1 | head -30

確認ポイント：

• 既定は週次・4世代・dateext
• /etc/logrotate.d/rsyslog に主要ログのローテーション設定がある
• logrotate -d の出力に「reading config file …」が並び、設定が解析できている

困ったらマニュアルを引きます。man journalctl man systemd.journal-fields man rsyslog.conf man logger man systemd-cat man logrotate。journalctl --help でオプションの俯瞰、logger --help で簡易ヘルプもあります。

理解度チェック

次の5問を ○×で答えてください。解答は記事末尾にあります。

1. systemd-journald はテキスト形式でログを保存する。
2. journalctl -p err は err（数値3）以上の優先度、つまり err / crit / alert / emerg を表示する。
3. /etc/rsyslog.conf で mail.* /var/log/maillog と書くと、mail に関する全 severity が /var/log/maillog に書かれる。
4. リモート syslog 転送で TCP を使う書式は @host:514（@ 1つ）である。
5. logger -t mytag "hello" で書いたメッセージは journalctl -t mytag でも /var/log/messages でも見つかる。

解答

1. ×（バイナリ形式。テキスト形式は rsyslog 側の /var/log/messages 等）
2. ○（severity は emerg(0)〜debug(7) で、-p err は数値 3 以下、つまり emerg / alert / crit / err）
3. ○（mail.* は mail facility の全 severity）
4. ×（@ 1つは UDP。TCP は @@ 2つ）
5. ○（rsyslog が imjournal で journald から取り込み /var/log/messages に書き出すため）

次回予告

次回（第8回）は 「メール配送エージェント(MTA)の基本 — postfix の動作確認」 です。MTA / MUA / MDA の役割の違い、postfix の最小構成、mail コマンド、メールキューの確認（mailq）と再配送（postqueue -f）を扱います。今回学んだ /var/log/maillog が育つ現場を見ることができます。

LinuC 102 試験対策シリーズ（全12回）

1. シェル環境のカスタマイズ：環境変数・エイリアス・履歴・ロケール
2. Bashスクリプト入門:if/for/関数で書く現場の自動化スクリプト
3. ネットワーク基礎：TCP/IP・ip コマンド・NetworkManager
4. ネットワークトラブルシューティングとDNSクライアント設定
5. ユーザ・グループ管理と sudo 設定の実務（useradd, visudo）
6. ジョブスケジューリングと時刻管理：cron, systemd timer, chrony, NTP
7. ログ管理実践：journalctl と rsyslog の使い分け
8. メール配送エージェント(MTA)の基本：postfix の動作確認
9. ファイアウォール（firewalld / ufw）と SELinux 入門
10. 暗号化によるデータ保護：SSH鍵認証・GnuPG・OpenSSL
11. クラウドセキュリティの基礎：IAM・公開鍵管理・SSH踏み台構成
12. オープンソースの文化：主要ライセンス（GPL/MIT/Apache）とコミュニティ