文書の過去の版を表示しています。
Rsyslog を使用した 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 の監査ログ書き込みを有効にする ことです。デフォルトでは無効になっています ので、有効にするには以下の手順に従う必要があります。
- Go to Management → Settings → System Settings → General Setup → Security and then enable the Enable audit log option.
- Save the changes with the Update button.
- 管理(Management) → セットアップ(Settings) → システム設定(System Settings) → 一般設定(General Setup) → セキュリティ(Security) に移動し、監査ログを有効にする(Enable audit log) オプションを有効にします。
- 更新(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 環境がインストールされています。
| Host | IP Address | Role |
|---|---|---|
rsyslog-receiver | 10.0.0.1 | Rsyslog receiver |
pandora-console | 10.0.0.2 | Rsyslog sender + Pandora FMS Web Console |
| ホスト | IPアドレス | 役割 |
|---|---|---|
rsyslog-receiver | 10.0.0.1 | Rsyslog レシーバー |
pandora-console | 10.0.0.2 | Rsyslog 送信元 + Pandora FMS Webコンソール |
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:
主要な設計上の決定事項:
imfileis 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
rulesetRemoteAuditFwdon the sender is mandatory. If theomfwdaction 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, internalrsyslogdmessages, etc.) and “pollutes” the receiver. Linking theimfileinput 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=-1andqueue.saveonshutdown=oninstructions.
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 はデータをバッファリングし、再起動後に送信を継続します。
レシーバー: `rsyslog-receiver`
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
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. Useimudpif UDP is preferred; TCP is recommended for audit data.- The string type
templatePandoraAuditdefines the output file path. ruleset(“RemoteAudit”)links the single writer to that file viadynaFile=(see “Known issues” below to understand whytemplate=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 トラフィックをファイアウォール(または監査トラフィックを通過させるネットワークファイアウォール)で許可する必要があります。
送信側: `pandora-console`
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 toqueue.type=“disk”(Warning:queue.maxdisksizeis 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 theimfileinput is the critical part: It makes the file-tail output bypass the main ruleset and reach only theomfwdaction.
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):
期待される出力(timestamp とプログラム名は送信側の Rsyslog によって付加され、末尾部分は元の行です):
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.
本番環境では、監査ログの行はコンソール自身によって書き込まれるため、コンソールが 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.
これは nc や ncat を使わずに動作し、ファイアウォールやネットワークの問題を切り分けるための最も迅速な方法です。
Rsyslog ジャーナルの確認
Each of the endpoints has detailed error reports in its Systemd unit:
各エンドポイントの Systemd ユニットには、詳細なエラーレポートが含まれています。
# --- 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 byresumed— the receiver has gone down (or has been restarted), and the sender has reconnected. Messages are not lost thanks toaction.resumeRetryCount=-1andqueue.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 runrsyslogd -N1again before restarting the service.
action 'action-0-builtin:omfwd' suspended (…)に続いてresumedと表示される — 受信側が停止(または再起動)し、送信側が再接続したことを示します。action.resumeRetryCount=-1およびqueue.saveonshutdown=onの設定により、メッセージが失われることはありません。
omfwd: remote server closed connection— 受信側が接続を拒否しています。リスナー(listener)が動作していること、および ルールセット(ruleset)に パース(parsing)エラーがないことを確認してください。
error during parsing file /etc/rsyslog.d/*.conf, on or before line N— 設定を修正し、サービスを再起動する前に再度rsyslogd -N1を実行してください。
よくある問題と解決策
| Symptom | Root cause | Solution |
|---|---|---|
The receiver remains empty; the sender logs remote server closed connection. | The receiver's configuration has a parsing error; the listener runs but messages are discarded by the default ruleset. | Run rsyslogd -N1 on the receiver and correct the config. In Rsyslog 8.2510, use dynaFile= and not template= in omfile. |
The receiver's file exists but contains CROND, rsyslogd, etc., not just auditing. | The omfwd action is declared at the root level of the sender's config; it forwards all messages from the main ruleset. | Wrap the omfwd action in a dedicated ruleset and link the imfile input to it with ruleset=“…”. |
parameter 'queue.maxdisksize' not known on the sender. | That parameter is only valid for queue.type=“disk”, not for linkedList. | Remove queue.maxdisksize or change the queue to disk. |
After deleting /var/lib/rsyslog/imfile-state*, historical data is not forwarded. | Expected: without a state file, imfile anchors to the current end of the file and only sends new lines. | Leave the state file as is. To forward historical data, use readMode=“2” in the imfile input. |
| New audit lines arrive with a delay. | imfile does polling every 10 seconds by default. | Lower that value with PollingInterval=“2” in the imfile input if near-real-time is needed. |
| After a sender restart, the last seconds of auditing are lost | The memory queue is discarded upon shutdown. | queue.saveonshutdown=“on” (specified in the Rsyslog journals review) persists the queue to disk; upon startup, Rsyslog empties it. |
| 症状 | 根本原因 | 解決策 |
|---|---|---|
受信側が空のままで、送信側のログに remote server closed connection と記録される。 | 受信側の設定に 解析 (parsing) エラーがある。リスナー (listener) は動作しているが、メッセージがデフォルトの ルールセット (ruleset) によって破棄されている。 | 受信側で rsyslogd -N1 を実行し、設定を修正する。Rsyslog 8.2510 以降では、omfile 内で template= ではなく dynaFile= を使用する。 |
受信側のファイルは存在するが、監査ログだけでなく CROND や rsyslogd などのログも含まれている。 | 送信側の 設定 (config) のルートレベルで omfwd アクションが宣言されており、メインルールセット (main ruleset) からのすべてのメッセージが転送されている。 | omfwd アクションを専用の ルールセット (ruleset) で囲み、ruleset=“…” を使用して imfile 入力をそのルールセットにリンクさせる。 |
送信側で parameter 'queue.maxdisksize' not known というエラーが出る。 | そのパラメータは queue.type=“disk” の場合にのみ有効であり、linkedList では無効である。 | queue.maxdisksize を削除するか、キューを disk に変更する。 |
/var/lib/rsyslog/imfile-state* を削除した後、過去のデータが転送されない。 | 期待される動作: 状態ファイル (state file) がない場合、imfile はファイルの現在の末尾を起点とし、新しい行のみを送信する。 | 状態ファイル (state file) はそのままにしておく。過去のデータを転送するには、imfile 入力で readMode=“2” を使用する。 |
| 新しい監査ログの行が遅れて到着する。 | imfile はデフォルトで 10 秒ごとに ポーリング (polling) を行う。 | ほぼ リアルタイム (real-time) の処理が必要な場合は、imfile 入力で PollingInterval=“2” を指定してその値を小さくする。 |
| 送信側を再起動した後、最後の数秒間の監査ログが失われる。 | シャットダウン時にメモリキューが破棄されるため。 | queue.saveonshutdown=“on”(Rsyslog ジャーナルの確認 で指定)を設定すると、キューがディスクに保存される(起動時に Rsyslog がそれを処理して空にする)。 |
Re-anchoring the sender
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.
Operational review list
- □ The receiver is online from the sender via
TCP 10514. - □ Clean
rsyslogd -N1on both ends. - □
ss -ltn | grep 10514shows aLISTENon the receiver. - □ A test line added to
audit.logappears in/var/log/received/pandora-audit.login less than a polling interval. - □ The receiver's log file contains only lines with the
pandora-audittag (withoutCROND/rsyslogd). - □
systemctl enable rsyslogapplied on both hosts so that forwarding survives a restart.