Linuxログ監視の方法｜journalctl・rsyslog

※本記事にはプロモーションを含む場合があります。

ログ監視が重要な理由

Linuxサーバーを運用していると、障害の予兆や不正アクセスの痕跡はほぼ例外なくログの中に残っています。しかし、ログを見る習慣がなければ、障害発生から原因特定までに数時間、場合によっては数日かかることも珍しくありません。実際、システム障害の多くはログの中に何らかの手がかりが残っているとされており、監視体制を整えていない現場ほど復旧までの時間が長引く傾向にあります。

ログ監視が求められる代表的な場面は次の4つです。

• システム障害時の原因特定：サーバーダウンやレスポンス低下が起きた際、発生時刻と関連プロセスをログから素早く割り出せる
• セキュリティインシデントの検知：不正ログインや権限昇格の試みを、発生から数分以内に検知できる体制が理想とされる
• コンプライアンス対応：金融機関や医療機関では、ログの保存と定期監査が内部規程・法令で義務付けられていることが多い
• パフォーマンス分析：CPUやメモリ使用率、レスポンスタイムの推移をログから継続的に把握できる

Linuxには標準で2つのログ管理の仕組みが用意されています。1つはsystemdに組み込まれたsystemd-journald（journalctlコマンドで操作）、もう1つは従来から使われてきたrsyslogです。両者は役割が異なり、journalctlは「今すぐログを見る」用途に強く、rsyslogは「ログを長期保存・転送・整形する」用途に強みがあります。この2つを組み合わせることで、日々の運用から緊急時のトラブルシューティングまでを一貫してカバーできる監視環境が構築できます。次のセクションから、それぞれの実践的な使い方を順番に見ていきます。

journalctl基本操作

systemd-journaldは、Linuxの起動プロセスやサービスのログを一元管理する仕組みです。journalctlコマンドを使えば、複雑な設定なしにすぐログを閲覧できます。まずは何も引数を付けずに実行してみましょう。

journalctl

これだけで、システム起動時から現在までの全ログが時系列で表示されます。行数が多い場合は自動的にページャ（less相当）が起動するため、矢印キーやスペースキーでスクロールしながら確認できます。

実務で頻出するパターンを3つ紹介します。

• 直近1時間のログを確認する：journalctl --since "1 hour ago"
• nginxのエラーだけをリアルタイム監視する：journalctl -u nginx -p err -f
• 今回のブートで発生したエラーを洗い出す：journalctl -b -p err

これらのコマンドは、サーバーにSSH接続してから10秒以内に実行できる手軽さが利点です。特に-fオプションはデプロイ直後の動作確認や、障害発生中のリアルタイム監視で重宝します。慣れてくると、朝の巡回作業を1日あたり5分程度で終えられるという声も現場からよく聞かれます。まずはこの基本コマンド群を体に染み込ませることが、効率的なログ監視の第一歩です。

フィルタで絞り込む

journalctlの真価は、豊富なフィルタリング機能にあります。ログレベルやプロセスID、ユーザーIDなど、複数の条件を組み合わせることで、数万行に及ぶログの中から目的の1行を瞬時に見つけ出せます。

現場でよく使われる組み合わせ例を挙げます。

1. rootユーザーによるログイン履歴を洗い出す：journalctl _UID=0 | grep "sshd"
2. 直近5分間の警告レベル以上のログを確認する：journalctl --since "5 minutes ago" -p warning
3. 特定プロセスのクラッシュ原因を追う：journalctl _PID=1234 -p crit
4. 複数条件を組み合わせて絞り込む：journalctl -u nginx -p err --since today

ログレベルはemerg（緊急）からdebug（デバッグ情報）まで8段階に分かれており、通常の運用ではwarning以上、障害調査時はinfo以上まで範囲を広げて確認するのが一般的とされています。フィルタを組み合わせずに全ログを目視で追うと、1万行あたり数十分かかることもありますが、適切なフィルタを使えば同じ作業を1分以内に短縮できるケースも多く報告されています。日々のログ確認では、まず-pオプションでレベルを絞り、次に_SYSTEMD_UNIT=やSYSLOG_IDENTIFIER=でサービス単位に絞り込む、という2段階の流れを覚えておくと迷いません。

出力形式のコツ

journalctlの出力は、目的に応じて形式を切り替えられます。人間が読みやすいデフォルト形式に加え、機械的な処理に適したJSON形式なども選択可能です。

実務での活用例を3つ紹介します。

• ログをCSVに変換してスプレッドシート分析に使う：journalctl -o json | jq -r '[.timestamp, .message] | @csv' > logs.csv
• 特定サービスのログをJSON形式で外部ツールへ渡す：journalctl -u nginx -o json > nginx_logs.json
• 1日分のログを整形して保存する：journalctl --since "1 day ago" -o json-pretty > system_logs.json

jqコマンドと組み合わせると、さらに柔軟な処理が可能になります。

# 特定フィールドのみ抽出
journalctl -o json | jq -r '.timestamp, .message'

# エラーレベル（priority=3）のみ抽出
journalctl -o json | jq 'select(.priority == "3")'

# 特定文字列を含むログのみ抽出
journalctl -o json | jq 'select(.message | contains("failed"))'

JSON形式での出力は、GrafanaやELK StackといったログBIツールへの連携を前提とする場合に特に効果を発揮します。手元での簡易確認は-o catやgrepで十分ですが、チームで共有するダッシュボードを作る段階になったら、JSON形式への切り替えを検討する価値があります。

rsyslogの設定方法

rsyslogは、Linuxで長らく使われてきたログデーモンです。柔軟な設定ファイルと豊富なモジュール群により、ローカル保存からリモート転送、フォーマット変更まで幅広く対応できます。公式ドキュメントによれば、1秒あたり数万件規模のログ処理性能を持つとされ、大規模環境でも実績があります。

まずrsyslogサービスを起動・有効化します。

sudo systemctl start rsyslog
sudo systemctl enable rsyslog

次に/etc/rsyslog.confを編集します。基本設定の例は以下の通りです。

module(load="imuxsock")   # local messages
module(load="imklog")     # kernel logs
module(load="builtin:omfile") # file output

*.info;mail.none;authpriv.none;cron.none  /var/log/messages
authpriv.*                                /var/log/secure
mail.*                                    /var/log/maillog
cron.*                                    /var/log/cron
*.emerg                                   :omusrmsg:*

設定変更後は必ずサービスを再起動します。

sudo systemctl restart rsyslog

特定サービスのログを別ファイルに分離したい場合は、/etc/rsyslog.d/以下に個別設定ファイルを追加します。

# /etc/rsyslog.d/nginx.conf
if $programname == 'nginx' then /var/log/nginx/access.log
if $programname == 'nginx' then stop

加えて、ログの肥大化を防ぐためにlogrotateとの併用が推奨されます。多くのディストリビューションでは週次でローテーション・4世代保持・圧縮といった設定が標準ですが、アクセス数の多いサーバーでは日次ローテーションに切り替えるケースもあります。

# /etc/logrotate.d/rsyslog
/var/log/messages {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

ログ転送で一元管理

複数台のサーバーを運用している場合、各サーバーのログを1か所に集約できると、障害調査や監査対応の手間が大幅に減ります。rsyslogのリモート転送機能を使えば、この一元管理を比較的シンプルな設定で実現できます。設定は送信側（クライアント）と受信側（サーバー）に分けて進めます。

1. 送信側サーバーで/etc/rsyslog.confを開き、転送先IPとポートを指定する：*.* @@192.168.1.100:514
2. 必要に応じてTLS暗号化用の証明書パスを設定する（下記コメントアウト部分を参照）
3. 受信側サーバーでimtcpモジュールを読み込み、受信ポート514番を開放する
4. 受信ログの保存先テンプレートをホスト名・プログラム名ごとに定義する
5. ファイアウォールで514番（TLS利用時は6514番）を許可する
6. 両サーバーでrsyslogサービスを再起動し、転送状況を確認する

送信側の設定例です。

# リモートサーバーのIPアドレスとポートを指定
*.* @@192.168.1.100:514

# TLS暗号化を有効にする場合（例）
# $DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.pem
# $DefaultNetstreamDriverCertFile /etc/rsyslog.d/keys/client-cert.pem
# $DefaultNetstreamDriverKeyFile /etc/rsyslog.d/keys/client-key.pem
# $ActionSendStreamDriverMode 1
# $ActionSendStreamDriverAuthMode x509/name
# *.* @@(o)192.168.1.100:6514

受信側の設定例です。

module(load="imtcp")
module(load="gtls")

input(type="imtcp" port="514")

template(name="RemoteLogs" type="string" string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
*.* ?RemoteLogs

設定完了後は両サーバーでrsyslogを再起動します：sudo systemctl restart rsyslog

特定ホストからのログだけを別ファイルに保存したい場合は、以下のように条件を追加できます。

if $fromhost-ip == '192.168.1.200' then /var/log/specific_host.log
if $fromhost-ip == '192.168.1.200' then stop

また、テンプレート機能を使えばJSON形式やCSV形式にログを整形して出力することもでき、SIEM製品やログ分析ツールとの連携がスムーズになります。暗号化なしの転送はネットワーク上でログ内容が平文のまま流れるため、社外拠点間や公衆回線をまたぐ構成ではTLSの利用がほぼ前提になると考えておくと安全です。

監視自動化の実践

手動でのログ確認には限界があります。人がターミナルを見ている間しか異常に気付けず、深夜や休日のトラブルは発見が遅れがちです。そこで重要になるのが監視の自動化です。自動化によって得られる効果は主に3つあります。

• リアルタイム異常検知：エラーや警告レベルのログを検知した瞬間にアラートを発報できる
• 人的ミスの削減：24時間365日体制の監視を仕組み化し、見落としのリスクを減らせる
• 初動対応の高速化：異常検知から通知までを数十秒以内に収められれば、被害拡大を防ぎやすくなる

自動化のアプローチは大きく2種類に分けられます。1つはPrometheus・Grafana・Loki（Promtail）やELK Stackといった専用の監視ツールと連携する方法、もう1つはrsyslog・journalctlと自作スクリプトを組み合わせる方法です。

Promtail + Loki + Grafanaを使う場合の大まかな流れは以下の通りです。

1. Promtailをダウンロードしてインストールする（wgetでバイナリを取得し/usr/local/bin配下に配置）
2. /etc/promtail/config.ymlを作成し、監視対象パス（例：/var/log/*log）を指定する
3. Lokiをインストールし、ストレージ設定を含む/etc/loki/config.ymlを用意して起動する
4. Grafanaをインストールし、grafana-serverサービスを起動・自動起動を有効化する
5. Grafanaの管理画面からLokiをデータソースとして追加する（URL：http://localhost:3100）
6. ダッシュボードを作成し、{job="varlogs"} |= "error"のようなクエリでエラーログを可視化する

Grafana上でLogsパネルを作成すれば、特定のエラーメッセージが発生した瞬間をダッシュボード上でリアルタイムに確認できます。導入初期は設定が複雑に感じられるかもしれませんが、一度構築してしまえば、複数サーバーの状況を1画面で把握できるようになり、日々の巡回時間を大幅に圧縮できます。小規模な環境であれば、journalctl -fとslack通知用のシェルスクリプトを組み合わせる簡易的な自動化から始めるのも現実的な選択肢です。

不正アクセス検知術

ログ監視のもう1つの大きな目的が、セキュリティインシデントの早期発見です。不正アクセスの多くは、成功する前に何度も失敗した痕跡をログに残します。この痕跡をいかに早く見つけるかが、被害を最小限に抑える鍵になります。

実務で使える具体的な確認コマンドを紹介します。

• 直近24時間のSSH認証失敗を集計する：journalctl -u sshd --since "24 hours ago" | grep "Failed password"
• 特定IPからのアクセスを追跡する：journalctl _SYSTEMD_UNIT=sshd.service | grep "192.168.1.50"
• 権限昇格の試みを確認する：journalctl _UID=0 -p warning --since today

これらのログを定期的にチェックする体制がない場合、fail2banのようなツールを併用し、一定回数以上の認証失敗を検知したら自動でIPアドレスをブロックする仕組みを組み込む方法もあります。加えて、rsyslogでリモートサーバーにログを転送しておけば、万が一攻撃者に侵入されてローカルログが改ざん・削除されても、転送済みのログは別サーバー上に残るため、証跡の保全という観点でも有効です。セキュリティ監査の場面では、ログの改ざん耐性が問われることも多く、リモート転送とアクセス権限の分離は基本的な対策として位置づけられています。

よくあるトラブル対処

ログ監視環境を運用していると、いくつかの典型的なトラブルに遭遇します。ここでは代表的な4つのケースと、その対処法を紹介します。

ログが永続化されず再起動のたびに消えてしまう場合は、/etc/systemd/journald.confでStorage=persistentを設定し、/var/log/journalディレクトリを作成した上でサービスを再起動すると解決することが多いです。デフォルトでは揮発性ストレージ（メモリ上）に保存される設定になっているディストリビューションもあり、意図せずログが消えてしまうケースが一因になっています。

rsyslogでの転送トラブルは、ネットワーク周りの設定漏れが原因であることが大半です。telnet 192.168.1.100 514のようなコマンドで疎通確認を行い、ポートが到達しているかをまず切り分けると、原因特定までの時間を短縮できます。ログ容量の肥大化は、アクセス数の多いWebサーバーなどで特に起きやすく、放置すると数GB〜数十GB単位でディスクを圧迫することもあるため、logrotateの設定は導入初期段階で必ず確認しておきたいポイントです。

よくある質問

Q1. journalctlのログはどれくらい保存される？
デフォルトでは/etc/systemd/journald.confのSystemMaxUse等の設定値に依存し、ディスク容量の一定割合（多くのディストリビューションで10%前後）に達すると古いログから自動的に削除される仕組みになっているとされています。長期保存が必要な場合は、SystemMaxUseやMaxRetentionSecの値を明示的に設定する必要があります。

Q2. rsyslogとjournalctlはどちらを使えばいい？
両者は競合するものではなく、役割分担で考えるのが一般的です。journalctlはリアルタイムの確認や直近ログの調査に向いており、rsyslogは長期保存・リモート転送・フォーマット変換など、恒久的なログ管理基盤としての役割に強みがあります。多くの現場では両方を併用しています。

Q3. journalctlで過去のログを削除できる？
journalctl --vacuum-time=7dのようなコマンドで、指定期間より古いログを削除できます。またvacuum-sizeオプションを使えば、容量ベースでの削除も可能です。誤って必要なログまで削除しないよう、実行前に対象範囲を確認することが推奨されます。

Q4. リモート転送にTLS暗号化は必須？
必須ではありませんが、社外拠点や公衆回線をまたぐ構成では強く推奨されています。TLSなしの転送では、ログの内容がネットワーク上を平文で流れるため、認証情報や個人情報が含まれるログを扱う場合は特にリスクが高まるとされています。

Q5. 監視ツールはどれを選べばいい？
小規模〜中規模環境ではPrometheus + Grafana + Loki（Promtail）の組み合わせが比較的導入しやすいとされ、大規模かつ多機能な分析が必要な場合はELK Stack（Elasticsearch, Logstash, Kibana）が選ばれる傾向にあります。自社の運用体制やログ量、予算に合わせて選定することが望ましいです。

Infra Academy編集部は、各ベンダー公式ドキュメントとエンジニア監修をもとに本記事を作成しています。インフラ・クラウド構築は環境ごとに差異があるため、本番環境への適用前には必ずテスト環境での検証を行ってください。

ABOUT ME

たから

フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営