Rsyslog を使用した Pandora FMS 監査ログの集約

Pandora FMS ドキュメント一覧に戻る

This topic describes how to forward a Pandora FMS log through Rsyslog. In reality, it would work for any server log, but here it focuses on Pandora FMS logs.

本トピックでは、Rsyslog を使用して Pandora FMS のログを転送する方法について説明します。実際にはあらゆるサーバのログに適用可能ですが、ここでは Pandora FMS のログに焦点を当てています。

Specifically, for this example, the Pandora FMS Web Console audit log located at:

具体的には、この例では、以下の場所にある Pandora FMS ウェブコンソールの監査ログが対象となります：

/var/www/html/pandora_console/log/audit.log

From a production server to a dedicated Rsyslog receiver, using imfile (file queue) on the sender's side and imtcp with an omfile template on the receiver's side. This is exactly the result of a real end-to-end execution on Rocky Linux 9 (Rsyslog 8.2506.0 on the sender and 8.2510.0 on the receiver).

本番サーバから専用の Rsyslog 受信サーバへの転送において、送信側では imfile （ファイルキュー）を使用し、受信側では imtcp と omfile テンプレートを使用しています。これは、Rocky Linux 9（Rsyslog のバージョンは送信側が 8.2506.0、受信側が 8.2510.0）上で実際にエンドツーエンドの処理を実行した際の結果そのものです。

For this log, the first thing to do is enable Pandora FMS audit log writing in the Web Console. It is disabled by default, and to enable it, you must follow these steps:

この ログ に関して、まず最初に行うべきことは、Webコンソール で Pandora FMS の監査ログ書き込みを有効にする ことです。デフォルトでは無効になっています ので、有効にするには以下の手順に従う必要があります。

1. Go to Management → Settings → System Settings → General Setup → Security and then enable the Enable audit log option.
2. Save the changes with the Update button.

1. 管理(Management) → セットアップ(Settings) → システム設定(System Settings) → 一般設定(General Setup) → セキュリティ(Security) に移動し、監査ログを有効にする(Enable audit log) オプションを有効にします。
2. 更新(Update) ボタンをクリックして変更を保存します。

In some log collection tools, there is already a dedicated collector “listening” via Syslog, making it unnecessary to configure an additional receiver on the opposite side.

一部のログ収集ツールには、Syslog 経由で待ち受ける専用のコレクターが既に備わっているため、送信側で追加のレシーバーを設定する必要はありません。

For this example, the configuration is done from scratch without assuming any pre-configured log collection tool.

この例では、事前に設定されたログ収集ツールを前提とせず、ゼロから設定を行います。

Both servers are configured with Rocky Linux version 9.7 and a minimal installation.

両サーバとも、Rocky Linux バージョン 9.7 の最小構成（Minimal Install）で設定されています。

The Web Console server has the Pandora FMS environment installed using the installation script.

Webコンソールサーバには、インストールスクリプトを使用してPandora FMS 環境がインストールされています。

Transport: TCP 10514. 514 is the canonical Syslog port; in this example, 10514 is used to show how to change the destination when the default port is not viable. This choice keeps the procedure reproducible in a clean installation; changing it to 514 for production takes only a single configuration line.

トランスポート: TCP 10514。Syslog の標準ポートは 514 ですが、この例では、デフォルトのポートが使用できない場合に送信先ポートを変更する方法を示すために 10514 を使用しています。この設定により、クリーンインストール環境でも手順を再現可能になります。本番環境向けに 514 へ変更する場合も、設定を 1行書き換えるだけで済みます。

The audit log is a plain text file to which the PHP Console adds lines on every administrative action. The goal is to send each new line to a separate host without modifying the Console code. The pipeline has three stages:

監査ログは、管理操作が行われるたびに PHP コンソールが新しい行を追記していくプレーンテキストファイルです。ここでの目的は、コンソールのコードを改変することなく、新たに追加された各行を別のホストへ送信することです。このパイプラインは、以下の3つのステージで構成されています。

Pandora FMS Console  --append-->  /var/www/html/pandora_console/log/audit.log
                                       |
                                       |  imfile (polling, 10s)
                                       v
                              rsyslog, pandora-console
                              (ruleset RemoteAuditFwd)
                                       |
                                       |  omfwd / TCP 10514
                                       v
                              rsyslog, rsyslog-receiver
                              (ruleset RemoteAudit)
                                       |
                                       v
                    /var/log/received/pandora-audit.log

Key design decisions:

主要な設計上の決定事項:

• imfile is the right tool to tail an application file without relying on the application to write to Syslog. It saves the read position in a state file, so Rsyslog restarts do not forward historical data.
• A dedicated ruleset RemoteAuditFwd on the sender is mandatory. If the omfwd action is declared at the root level of the Rsyslog configuration, it applies to all messages in the main ruleset — that is, to the entire journal (CROND, internal rsyslogd messages, etc.) and “pollutes” the receiver. Linking the imfile input to its own ruleset is the cleanest way to send only the audit lines.
• A ruleset, RemoteAudit, on the receiver with a string type template used as the output file name (dynaFile) produces a single predictable file—for this example, under /var/log/received/—and leaves the receiver's local Syslog intact.
• TCP over UDP: Audit lines are small but should not be silently discarded; a brief receiver restart will cause Rsyslog to buffer and forward them using the action.resumeRetryCount=-1 and queue.saveonshutdown=on instructions.

• imfile は、アプリケーションが Syslog へ書き出す機能に依存することなく、アプリケーションのログファイルを tail（追跡）するのに最適なツールです。読み取り位置は 状態ファイル に保存されるため、Rsyslog を再起動しても過去のデータが再送信されることはありません。
• 送信側では、専用の ruleset （ここでは RemoteAuditFwd とします）を定義することが必須です。もし Rsyslog 設定のルートレベルで omfwd アクションを宣言してしまうと、メインの ruleset 内のすべてのメッセージ、つまり、journal 全体 (CROND、rsyslogd 内部メッセージなど）に適用され、受信側のログを「汚染」してしまいます。imfile 入力を独自の ruleset に紐付けるのが、監査ログの行だけを送信するための最もクリーンな方法です。
• 受信側でも ruleset（ここでは RemoteAudit とします）を定義し、出力ファイル名（dynaFile）として文字列（string）型の テンプレート を使用します。これにより、単一の予測可能なファイル（この例では /var/log/received/ 配下）が生成され、受信側のローカル Syslog には影響を与えません。
• UDP ではなく TCP を使用: 監査ログの行は小規模ですが、黙って破棄されるべきではありません。受信側を短時間再起動する場合でも、action.resumeRetryCount=-1 および queue.saveonshutdown=on という設定を使用することで、Rsyslog はデータをバッファリングし、再起動後に送信を継続します。

In most Rocky Linux installations, Rsyslog is already installed by default. If it is a minimal installation that does not have it, the command to install it is:

Rocky Linux のほとんどのインストール環境では、Rsyslog はデフォルトですでにインストールされています。インストールされていない最小構成（Minimal Install）の場合、インストールするためのコマンドは以下の通りです。

# --- On rsyslog-receiver (10.0.0.1) ---
dnf install -y rsyslog

Create /etc/rsyslog.d/10-remote-audit.conf with the following content:

以下の内容で /etc/rsyslog.d/10-remote-audit.conf を作成します。

10-remote-audit.conf

# Receiver: accept audit logs forwarded on TCP port 10514 and
# store them in a single file under /var/log/received/.
module(load="imtcp")

template(name="PandoraAudit" type="string"
    string="/var/log/received/pandora-audit.log"
)

ruleset(name="RemoteAudit") {
    action(type="omfile" dynaFile="PandoraAudit")
}

input(type="imtcp" port="10514" ruleset="RemoteAudit")

What each block does:

各ブロックの機能:

• module(load=“imtcp”) enables the Syslog receiver over TCP. Use imudp if UDP is preferred; TCP is recommended for audit data.
• The string type template PandoraAudit defines the output file path.
• ruleset(“RemoteAudit”) links the single writer to that file via dynaFile= (see “Known issues” below to understand why template= does not work here in Rsyslog 8.2510).
• input(type=“imtcp” port=“10514” ruleset=“RemoteAudit”) opens the listener and routes incoming messages to the custom ruleset instead of the default ruleset.

• module(load=“imtcp”) は、TCP 経由の Syslog 受信機能を有効にします。UDP を使用したい場合は imudp を使用してください（監査データには TCP が推奨されます）。
• 文字列（string）型の template である PandoraAudit は、出力ファイルのパスを定義します。
• ruleset(“RemoteAudit”) は、dynaFile= を介して単一の書き込み処理をそのファイルに紐付けます（Rsyslog 8.2510 において、なぜここで template= が機能しないのかについては、後述の「既知の問題」を参照してください）。
• input(type=“imtcp” port=“10514” ruleset=“RemoteAudit”) はリスナーを起動し、受信したメッセージをデフォルトの ruleset ではなく、カスタム ruleset へとルーティングします。

# --- On rsyslog-receiver (10.0.0.1) ---
mkdir -p /var/log/received
systemctl enable --now rsyslog
ss -ltn | grep 10514

Expected: a LISTEN line on 0.0.0.0:10514 and [::]:10514. In production, the receiving host must allow incoming TCP 10514 traffic from the sender in its firewall (or in the network firewall carrying the audit traffic).

期待される動作: 0.0.0.0:10514 および [::]:10514 での LISTEN 行の表示。本番環境では、受信側のホストにおいて、送信元からの TCP 10514 トラフィックをファイアウォール（または監査トラフィックを通過させるネットワークファイアウォール）で許可する必要があります。

The Pandora FMS Server already includes Rsyslog (it is installed by default and active in the standard Console image). You only need to add the audit forwarding configuration.

Pandora FMS サーバには、すでに Rsyslog が含まれています（標準のコンソールイメージではデフォルトでインストールされ、有効になっています）。必要な作業は、監査ログ転送の設定を追加することだけです。

Create /etc/rsyslog.d/10-pandora-audit-fwd.conf:

/etc/rsyslog.d/10-pandora-audit-fwd.conf を作成します:

10-pandora-audit-fwd.conf

# Sender: tail the Pandora FMS Console audit log and
# forward it to the receiver via TCP port 10514. The dedicated ruleset is
# required to ensure that ONLY the audit log is sent, not the entire
# system journal.
module(load="imfile")

ruleset(name="RemoteAuditFwd") {
    action(type="omfwd"
        target="10.0.0.1"
        port="10514"
        protocol="tcp"
        action.resumeRetryCount="-1"
        queue.type="linkedList"
        queue.filename="pandora_audit_fwd"
        queue.saveonshutdown="on"
    )
}

input(type="imfile"
    File="/var/www/html/pandora_console/log/audit.log"
    Tag="pandora-audit"
    Severity="info"
    Facility="local0"
    ruleset="RemoteAuditFwd"
)

Notes on the parameters:

パラメータに関する注記:

• action.resumeRetryCount=“-1” makes the sender retry indefinitely when the receiver is down; this gives the sender the “buffer if the network goes down” behavior.
• queue.type=“linkedList” keeps the queue in memory simply. If the audit volume justifies a disk queue, change it to queue.type=“disk” (Warning: queue.maxdisksize is only valid for disk queues).
• Tag=“pandora-audit” allows the receiver and downstream filters to recognize the stream. Facility=“local0” keeps it out of the standard facilities (auth, syslog).
• ruleset=“RemoteAuditFwd” in the imfile input is the critical part: It makes the file-tail output bypass the main ruleset and reach only the omfwd action.

• action.resumeRetryCount=“-1” は、受信側がダウンしている場合に送信側が再試行を無期限に続けるように設定します。これにより、送信側は「ネットワークがダウンした際にデータをバッファリングする」という動作を行うようになります。
• queue.type=“linkedList” は、キューをメモリ上に保持するシンプルな設定です。監査データの量がディスクキューの使用に適した規模であれば、queue.type=“disk” に変更してください（注意: queue.maxdisksize は ディスク キューに対してのみ有効です）。
• Tag=“pandora-audit” を指定することで、受信側や後続のフィルタ（downstream filters）がこのストリームを識別できるようになります。Facility=“local0” を指定することで、標準のファシリティ（auth や syslog）とは区別されます。
• imfile 入力における ruleset=“RemoteAuditFwd” は重要な設定箇所です。これにより、ファイル末尾の出力（file-tail output）がメインのルールセットをバイパスし、omfwd アクションにのみ渡されるようになります。

# --- On pandora-console (10.0.0.2) ---
rsyslogd -N1
systemctl enable --now rsyslog

rsyslogd -N1 performs a validation pass in a single read.

rsyslogd -N1 は、1回の読み取りで検証パスを実行します。

The expected last line is End of config validation run. Bye. Anything else indicates the configuration does not load, and the service will run without the forwarding rules.

期待される最後の行は End of config validation run. Bye. です。それ以外の出力は、設定が読み込まれなかったことを示しており、その場合、サービスは転送ルールを適用せずに動作します。

# --- On pandora-console (10.0.0.2) ---
# 1. Generate an audit-style line in the source file.
#    192.0.2.10 is the IP address of the administrator
#    performing the action (fictitious value).
TS=$(date '+%F %T')
echo "$TS - admin - Test - 192.0.2.10 - rsyslog forwarding smoke test" \
    | sudo tee -a /var/www/html/pandora_console/log/audit.log
 
# 2. Wait for the imfile polling interval (10 seconds by default)
sleep 15
 
# 3. Check the output file on the receiver
cat /var/log/received/pandora-audit.log

Expected output (the timestamp and the program name are added by Rsyslog on the sender; the final part is the original line):

Jul  2 12:44:52 pandora-console pandora-audit 2026-07-02 12:44:52 -
 admin - Test - 192.0.2.10 - rsyslog forwarding smoke test

In production, the audit lines are written by the Console itself, which does not need to “know” anything about Rsyslog.

If nothing reaches the receiver, first validate the network path:

# --- On pandora-console (10.0.0.2) ---
bash -c 'echo > /dev/tcp/10.0.0.1/10514' && echo "TCP 10514 alcanzable"

This works without nc or ncat and is the fastest way to rule out firewall/network issues.

Each of the endpoints has detailed error reports in its Systemd unit:

# --- On pandora-console (10.0.0.2) ---
journalctl -u rsyslog --no-pager -n 50

# --- On rsyslog-receiver (10.0.0.1) ---
journalctl -u rsyslog --no-pager -n 50

Patterns worth recognizing:

• action 'action-0-builtin:omfwd' suspended (…) followed by resumed — the receiver has gone down (or has been restarted), and the sender has reconnected. Messages are not lost thanks to action.resumeRetryCount=-1 and queue.saveonshutdown=on.
  
• omfwd: remote server closed connection — the receiver is rejecting connections. Check that the listener is running and that the ruleset is free of parsing errors.
  
• error during parsing file /etc/rsyslog.d/*.conf, on or before line N — correct the configuration and run rsyslogd -N1 again before restarting the service.
  

To rebuild the audit stream from scratch (for example, after a long offline period for the receiver where the local audit log has fallen behind), reset the imfile state and confirm that the file still exists in the expected path:

# --- On pandora-console (10.0.0.2) ---
# Locate the state file (its name contains a colon; enclose it in quotation marks)
ls -la /var/lib/rsyslog/ | grep imfile-state
 
# Erase it
rm -f /var/lib/rsyslog/imfile-state:*
 
# Restar service
systemctl restart rsyslog

After the restart, the sender only sends the lines written after the restart. To forward everything from the beginning of the current audit.log, add readMode=“2” to the imfile input and restart Rsyslog again.

• □ The receiver is online from the sender via TCP 10514.
• □ Clean rsyslogd -N1 on both ends.
• □ ss -ltn | grep 10514 shows a LISTEN on the receiver.
• □ A test line added to audit.log appears in /var/log/received/pandora-audit.log in less than a polling interval.
• □ The receiver's log file contains only lines with the pandora-audit tag (without CROND / rsyslogd).
• □ systemctl enable rsyslog applied on both hosts so that forwarding survives a restart.

Pandora FMS ドキュメント一覧に戻る