Linuxシステムの安定稼働を支えるログ監視は、トラブル発生時の迅速な対応とセキュリティ強化に不可欠です。サーバー管理者であれば、ログ監視を毎日5分で完了させる手法を今すぐ実践すべきです。本記事では、Linux標準のログ管理ツールであるjournalctlとrsyslogを活用した効率的なログ監視手法を、具体的なコマンドと設定例で解説します。初心者から上級者まで、実務で即座に活用できる実践的な内容となっています。

目次

はじめに：Linuxログ監視の重要性

Linuxシステムにおけるログ監視は、システムの健全性を維持し、セキュリティインシデントを早期に検知するための基盤です。システム障害の60%以上はログに記録されており、適切な監視がなければ問題の根本原因特定に数時間から数日を要することも珍しくありません。

具体的には、以下のような場面でログ監視が不可欠です：

  • システム障害時の迅速な原因特定：サーバーダウンやパフォーマンス低下時に、ログから障害発生時刻や原因プロセスを特定できます。
  • セキュリティ監視：不正アクセスや権限昇格の試みをログから検知し、即座に対応できます。
  • コンプライアンス対応：金融機関や医療機関では、ログの保存と監査が法的に義務付けられています。
  • パフォーマンス最適化：システムリソースの使用状況やアプリケーションのレスポンスタイムをログから分析できます。

Linuxには、システムログを管理するための標準的なツールが2つ存在します：

  1. systemd-journald：systemdが導入された現代のLinuxで標準となったログ管理システム。journalctlコマンドで操作します。
  2. rsyslog：従来から使用されているログデーモンで、柔軟なログ転送やフィルタリング機能を提供します。

これらのツールを適切に組み合わせることで、効率的かつ包括的なログ監視環境を構築できます。本記事では、それぞれのツールの基本的な使い方から、実務で役立つ高度な設定までを網羅的に解説します。

journalctlの基礎と実践的な使い方

systemd-journaldは、Linuxシステムの起動プロセスやサービスのログを管理するためのサービスです。journalctlコマンドを使用することで、これらのログを簡単に閲覧・分析できます。

基本コマンドでログを即時確認

journalctlの基本的な使い方から始めましょう。以下のコマンドは、システム起動時から現在までのすべてのログを表示します：

journalctl

このコマンドを実行すると、以下のような出力が得られます：

フィールド説明例
— Logs begin at Mon 2024-01-01 00:00:00 JST, end at Tue 2024-01-02 12:34:56 JST —ログの開始時刻と終了時刻— Logs begin at Mon 2024-01-01 00:00:00 JST —
Jan 01 00:00:01 hostname systemd:ログの発生日時と発生元プロセスJan 01 00:00:01 server1 systemd:
Starting systemd-udevd version 249.11-0ubuntu3.6…ログメッセージStarting systemd-udevd version 249.11-0ubuntu3.6…

基本的なオプションをいくつか紹介します：

オプション説明使用例
-b現在のブートセッションのログのみ表示journalctl -b
-u特定のサービスのログを表示journalctl -u nginx
-fリアルタイムで新しいログを表示（tail -f風）journalctl -f
–since / –until特定の時間範囲のログを表示journalctl –since “2024-01-01 00:00:00” –until “2024-01-01 12:00:00”

実務で即座に活用できる具体例：

  • 直近1時間のログを確認する：journalctl --since "1 hour ago"
  • nginxサービスのエラーを監視する：journalctl -u nginx -p err -f
  • システム起動時のエラーを確認する：journalctl -b -p err

フィルタリング機能で目的のログを素早く見つける

journalctlには、ログを絞り込むための豊富なフィルタリングオプションが用意されています。以下のオプションを組み合わせることで、目的のログを素早く見つけられます：

フィルタリングオプション説明使用例
-pログレベルでフィルタリング（emerg, alert, crit, err, warning, notice, info, debug）journalctl -p err
_PID=プロセスIDでフィルタリングjournalctl _PID=1234
_UID=ユーザーIDでフィルタリングjournalctl _UID=0
_SYSTEMD_UNIT=systemdユニットでフィルタリングjournalctl _SYSTEMD_UNIT=nginx.service
SYSLOG_IDENTIFIER=プロセス名でフィルタリングjournalctl SYSLOG_IDENTIFIER=sshd

実務で役立つフィルタリングの具体例：

  • rootユーザーによるログインを監視する：journalctl _UID=0 | grep "sshd"
  • 直近5分間の警告レベル以上のログを確認する：journalctl --since "5 minutes ago" -p warning
  • 特定のプロセスがクラッシュした際のログを確認する：journalctl _PID=1234 -p crit

これらのフィルタリング機能を活用することで、数千行に及ぶログの中から、必要な情報を数秒で見つけ出せるようになります。

出力形式のカスタマイズで分析効率を向上

journalctlの出力形式は、目的に応じてカスタマイズできます。デフォルトの出力は人間が読みやすい形式ですが、機械的な処理やログ分析ツールとの連携には、機械可読な形式が適しています。

以下の出力形式オプションを活用しましょう：

出力形式オプション説明使用例
-o catメッセージのみを表示（簡潔な形式）journalctl -o cat
-o jsonJSON形式で出力（機械可読）journalctl -o json
-o json-pretty整形されたJSON形式で出力journalctl -o json-pretty
-o exportバイナリ形式で出力（バックアップに適切）journalctl -o export > logs.export
–no-pagerlessを使用せずに直接出力journalctl –no-pager | grep “error”

実務で役立つ出力形式の活用例：

  • ログをCSV形式で出力し、スプレッドシートで分析する：journalctl -o json | jq -r '[.timestamp, .message] | @csv' > logs.csv
  • 特定のサービスのログをJSON形式で取得し、ログ分析ツールに渡す：journalctl -u nginx -o json > nginx_logs.json
  • ログをファイルに保存して後で分析する：journalctl --since "1 day ago" -o json-pretty > system_logs.json

また、journalctlはjqコマンドと組み合わせることで、さらに柔軟なログ処理が可能になります。jqはJSONデータを操作するためのコマンドラインツールで、以下のように活用できます：

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

# ログレベルがerrのもののみを抽出
journalctl -o json | jq 'select(.priority == "3")'

# 特定のメッセージを含むログを抽出
journalctl -o json | jq 'select(.message | contains("failed"))'

これらの出力形式と処理方法を組み合わせることで、ログ分析の効率を大幅に向上させられます。

rsyslogの設定と高度なログ管理

rsyslogは、従来からLinuxシステムで使用されているログデーモンです。柔軟な設定ファイルと豊富なモジュール機能を備えており、ローカルログの収集からリモートログサーバーへの転送、ログのフィルタリングやフォーマット変更まで、幅広い用途に対応できます。

rsyslogの主な特徴は以下の通りです：

  • 高い処理能力：1秒あたり数万件のログ処理が可能（出典: rsyslog公式ドキュメント）
  • 柔軟な設定：設定ファイルで詳細なルールを定義可能
  • 豊富な出力先：ファイル、データベース、リモートサーバー、Syslogメッセージなど
  • セキュリティ機能：TLS暗号化による安全なログ転送に対応

基本設定：ローカルログの収集と保存

rsyslogの設定ファイルは、通常/etc/rsyslog.confと/etc/rsyslog.d/ディレクトリ以下のファイルで構成されます。基本的な設定から見ていきましょう。

まず、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:*

この設定では、以下のようなログが保存されます：

  • /var/log/messages：情報レベル以上の一般的なシステムログ
  • /var/log/secure：認証関連のログ
  • /var/log/maillog：メールサーバーのログ
  • /var/log/cron：cronジョブのログ
  • emergレベルのログ：システム全体に緊急メッセージを通知

設定を変更した後は、rsyslogサービスを再起動します：

sudo systemctl restart rsyslog

実務で役立つ基本設定の拡張：

  • 特定のサービスのログを別ファイルに保存する：
    # /etc/rsyslog.d/nginx.conf
if $programname == 'nginx' then /var/log/nginx/access.log
if $programname == 'nginx' then stop
  • ログローテーションの設定を追加する：
    # /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
}

リモートサーバーへのログ転送設定

rsyslogを使用する最大のメリットの1つは、リモートログサーバーへのログ転送です。これにより、複数のサーバーからのログを一箇所で集中管理でき、セキュリティ監視やトラブルシューティングが容易になります。

リモートログ転送の設定は、以下の2つのステップで行います：

  1. ログ送信側（クライアント）の設定
  2. ログ受信側（サーバー）の設定

1. ログ送信側の設定

クライアント側の/etc/rsyslog.confに以下の設定を追加します：

# リモートサーバーの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

2. ログ受信側の設定

サーバー側の/etc/rsyslog.confに以下の設定を追加します：

# モジュールのロード
module(load="imtcp")
module(load="gtls")

# 受信ポートの設定
input(type="imtcp" port="514")

# TLS暗号化を有効にする場合
# input(type="imtcp" port="6514"
#     streamDriver.Name="gtls"
#     streamDriver.Mode="1"
#     streamDriver.AuthMode="x509/name"
# )

# ログの保存先
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
  • ログをデータベースに保存する：
    # MySQLモジュールを有効にする
module(load="ommysql")

# データベース接続設定
action(type="ommysql" server="localhost" db="logs" user="rsyslog" password="password"
       template="dbFormat")

# ログをデータベースに保存
*.* :ommysql:localhost,logs,rsyslog,password

テンプレート機能でログ形式を統一

rsyslogのテンプレート機能を使用することで、ログの出力形式を柔軟にカスタマイズできます。これにより、ログ分析ツールやSIEM（Security Information and Event Management）システムとの連携が容易になります。

テンプレートは/etc/rsyslog.confファイル内で定義します。以下は代表的なテンプレートの例です：

# JSON形式のテンプレート
template(name="JsonFormat" type="list") {
    constant(value="{")
    constant(value="\"timestamp\":\"")
    property(name="timereported" dateFormat="rfc3339")
    constant(value="\",\"host\":\"")
    property(name="hostname")
    constant(value="\",\"program\":\"")
    property(name="programname")
    constant(value="\",\"message\":\"")
    property(name="msg" format="json")
    constant(value="\"}")
}

# CSV形式のテンプレート
template(name="CsvFormat" type="list") {
    property(name="timereported" dateFormat="rfc3339")
    constant(value=",")
    property(name="hostname")
    constant(value=",")
    property(name="programname")
    constant(value=",")
    property(name="msg")
    constant(value="\n")
}

# 使用例：JSON形式でログを出力
*.* action(type="omfile" dynaFile="JsonFormat" file="/var/log/json/system.log")

# 使用例：CSV形式でログを出力
*.* action(type="omfile" dynaFile="CsvFormat" file="/var/log/csv/system.csv")

実務で役立つテンプレートの活用例：

  • Syslog標準フォーマット（RFC 3164）に準拠したログを出力：
    template(name="SyslogRFC3164" type="string"
             string="<%PRI%>%TIMESTAMP% %HOSTNAME% %APP-NAME% %PROCID% %MSG%")
  • 特定のフィールドのみを抽出したログを出力：
    template(name="FilteredLog" type="list") {
        property(name="timestamp")
        constant(value=" - ")
        property(name="hostname")
        constant(value=" - ")
        property(name="programname")
        constant(value=" - ")
        property(name="msg")
    }

これらのテンプレート機能を活用することで、ログの形式を目的に応じて柔軟にカスタマイズし、さまざまなログ分析ツールとの互換性を確保できます。

ログ監視の自動化：トラブル検知を自動化する

手動でログを監視する方法では、リアルタイムのトラブル検知や大量のログからの異常検知が困難です。そこで、ログ監視の自動化が重要になります。自動化により、以下のメリットが得られます：

  • リアルタイムの異常検知：エラーや警告レベルのログを即座に検知し、アラートを発報
  • 人的ミスの削減：24時間365日の監視を自動化し、見落としを防止
  • 迅速な対応：トラブル発生から数秒以内に関係者に通知し、被害拡大を防止

ログ監視の自動化には、主に以下の2つのアプローチがあります：

  1. ログ監視ツールとの連携：Prometheus、Grafana、ELK Stackなどの監視ツールを使用
  2. rsyslog/journalctlとスクリプトの組み合わせ：独自の監視スクリプトを作成

監視ツールとの連携方法

ログ監視に特化したツールや、総合的な監視システムと連携することで、効率的なログ監視を実現できます。以下に代表的なツールとその連携方法を紹介します。

1. Prometheus + Grafana + Promtail

Prometheusはオープンソースの監視システムで、Promtailはログ収集エージェントです。これらを組み合わせることで、リアルタイムのログ監視と可視化が可能になります。

導入手順：

  1. Promtailのインストールと設定：
    # Promtailのダウンロードとインストール
    wget https://github.com/grafana/loki/releases/download/v2.9.0/promtail-linux-amd64.zip
    unzip promtail-linux-amd64.zip
    sudo mv promtail-linux-amd64 /usr/local/bin/promtail

    # 設定ファイルの作成
    sudo mkdir -p /etc/promtail
    sudo nano /etc/promtail/config.yml

    設定ファイルの例：

    server:
      http_listen_port: 9080
      grpc_listen_port: 0

    positions:
      filename: /tmp/positions.yaml

    clients:
      - url: http://localhost:3100/loki/api/v1/push

    scrape_configs:
    - job_name: system
      static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          __path__: /var/log/*log
  2. Lokiのインストールと起動：
    # Lokiのダウンロードとインストール
    wget https://github.com/grafana/loki/releases/download/v2.9.0/loki-linux-amd64.zip
    unzip loki-linux-amd64.zip
    sudo mv loki-linux-amd64 /usr/local/bin/loki

    # 設定ファイルの作成
    sudo nano /etc/loki/config.yml

    # 設定ファイルの例
    auth_enabled: false

    server:
      http_listen_port: 3100

    common:
      storage:
        filesystem:
          chunks_directory: /tmp/loki/chunks
          rules_directory: /tmp/loki/rules
      replication_factor: 1
      ring:
        instance_addr: 127.0.0.1
        kvstore:
          store: inmemory

    schema_config:
      configs:
        - from: 2020-10-24
          store: boltdb-shipper
          object_store: filesystem
          schema: v11
          index:
            prefix: index_
            period: 24h

    # Lokiの起動
    sudo /usr/local/bin/loki -config.file=/etc/loki/config.yml &
  3. Grafanaのインストールと設定：
    # Grafanaのインストール
    sudo apt-get install -y apt-transport-https
    sudo apt-get install -y software-properties-common wget
    wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
    echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list
    sudo apt-get update
    sudo apt-get install grafana

    # Grafanaの起動と有効化
    sudo systemctl start grafana-server
    sudo systemctl enable grafana-server

    # GrafanaにLokiデータソースを追加
    # Webブラウザでhttp://localhost:3000にアクセスし、管理者アカウントでログイン
    # Configuration → Data Sources → Add data source → Lokiを選択
    # URLにhttp://localhost:3100を入力

活用例：

  • 特定のエラーメッセージを検知するダッシュボードを作成：
    1. Grafanaにログインし、新しいダッシュボードを作成
    2. 「Add new panel」をクリック
    3. 「Data source」でLokiを選択
    4. クエリに{job="varlogs"} |= "error"と入力
    5. 「Visualization」で「Logs」を選択
    6. 「Save」でダッシュボードを保存
  • リアルタイムのログストリームを表示：
    1. ダッシュボードに新しいパネルを追加
    2. クエリに{job="varlogs"} | logfmtと入力
      3. 【編集・制作ポリシー】
      本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
ABOUT ME
たから
フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営