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

{{indexmenu_n>64}}
 
[[ja:documentation:pandorafms:start|Pandora FMS ドキュメント一覧に戻る]]

<wrap #ks1 />

===== 概要 =====

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 ウェブコンソールの監査ログが対象となります：

<file>
/var/www/html/pandora_console/log/audit.log
</file>

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 [[:en:documentation:pandorafms:management_and_operation:12_console_setup#ks1_1_2|Web Console]]. //It is disabled by default//, and to enable it, you must follow these steps:

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

  - Go to <wrap :en>**Management → Settings → System Settings → General Setup → Security**</wrap> and then enable the <wrap :en>**Enable audit log**</wrap> option.
  - Save the changes with the <wrap :en>**Update**</wrap> button.

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

<wrap #ks2 />

===== トポロジ =====

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.

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

<wrap #ks2_1 />

==== サーバと設定 ====

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 [[:en:documentation:pandorafms:installation:01_installing#ks1_7|installation script]].

Webコンソールサーバには、[[:ja:documentation:pandorafms:installation:01_installing#ks1_7|インストールスクリプト]]を使用して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行書き換えるだけで済みます。

<wrap #ks3 />

===== 処理説明 =====

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つのステージで構成されています。

<file>
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
</file>

**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 はデータをバッファリングし、再起動後に送信を継続します。

<wrap #ks4 />

===== レシーバー: `rsyslog-receiver` =====

<wrap #ks4_1 />
==== 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）の場合、インストールするためのコマンドは以下の通りです。

<code bash>
# --- On rsyslog-receiver (10.0.0.1) ---
dnf install -y rsyslog
</code>

<wrap #ks4_2 />

==== Rsyslog 設定 ====

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

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

<file | 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")
</file>

**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// へとルーティングします。

<wrap #ks4_3 />

==== 有効化および検証 ====

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

**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'' トラフィックをファイアウォール（または監査トラフィックを通過させるネットワークファイアウォール）で許可する必要があります。

<wrap #ks5 />

===== 送信側: `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 が含まれています（標準のコンソールイメージではデフォルトでインストールされ、有効になっています）。必要な作業は、監査ログ転送の設定を追加することだけです。

<wrap #ks5_1 />

==== 転送設定の作成 ====

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

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

<file | 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"
)
</file>

**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'' アクションにのみ渡されるようになります。

<wrap #ks5_2 />

==== 設定の検証とサービスの開始 ====

<code bash>
# --- On pandora-console (10.0.0.2) ---
rsyslogd -N1
systemctl enable --now rsyslog
</code>

''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.'' です。//それ以外の出力は、設定が読み込まれなかったことを示しており、その場合、サービスは転送ルールを適用せずに動作します//。

<wrap #ks6 />

===== テストとデバッグ =====

<wrap #ks6_1 />

==== スモークテスト ====

<code bash>
# --- 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
</code>

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

期待される出力（//timestamp// とプログラム名は送信側の Rsyslog によって付加され、末尾部分は元の行です）：

<file>
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
</file>

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

本番環境では、監査ログの行はコンソール自身によって書き込まれるため、コンソールが Rsyslog について何かを「知る」必要はありません。

<wrap #ks6_2 />

==== 接続チェック ====

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

受信側に何も届かない場合は、まずネットワーク経路を検証してください。

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

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

これは ''nc'' や ''ncat'' を使わずに動作し、ファイアウォールやネットワークの問題を切り分けるための最も迅速な方法です。

<wrap #ks6_3 />

==== Rsyslog ジャーナルの確認 ====

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

各エンドポイントの Systemd ユニットには、詳細なエラーレポートが含まれています。

<code bash>
# --- On pandora-console (10.0.0.2) ---
journalctl -u rsyslog --no-pager -n 50
</code>

<code bash>
# --- On rsyslog-receiver (10.0.0.1) ---
journalctl -u rsyslog --no-pager -n 50
</code>

**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.  \\ 

  * ''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'' を実行してください。 \\

<wrap #ks6_4 />

==== よくある問題と解決策 ====

^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 [[#ks6_3|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"''（[[#ks6_3|Rsyslog ジャーナルの確認]] で指定）を設定すると、キューがディスクに保存される（起動時に Rsyslog がそれを処理して空にする）。|

<wrap #ks6_5 />

==== 送信側のアンカー再設定 ====

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:

監査ストリームをゼロから再構築する場合（例えば、受信側が長期間オフラインになり、ローカルの監査ログの処理が遅延してしまった後など）、''imfile'' の状態（state）をリセットし、対象のファイルが想定されるパスに存在することを確認してください。

<code bash>
# --- 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
</code>

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.

再起動後、送信側は再起動**以降**に書き込まれた行のみを送信します。現在の ''audit.log'' の冒頭からすべてを転送するには、''imfile'' 入力に ''readMode="2"'' を追加し、Rsyslog を再度再起動します。

<wrap #ks7 />

===== 作業確認リスト =====

  * □ 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.

  * □ 送信元から受信側へ ''TCP 10514'' で接続可能である。
  * □ 両端で ''rsyslogd -N1'' を実行し、設定に問題がないことを確認済みである。
  * □ 受信側で ''ss -ltn | grep 10514'' を実行すると、''LISTEN'' 状態であることが確認できる。
  * □ ''audit.log'' に追加したテスト行が、ポーリング間隔以内に ''/var/log/received/pandora-audit.log'' へ反映される。
  * □ 受信側のログファイルには、''pandora-audit'' タグが付いた行**のみ**が含まれている（''CROND'' や ''rsyslogd'' などの行は含まれない）。
  * □ 再起動後も転送が継続されるよう、両ホストで ''systemctl enable rsyslog'' が実行されている。

[[ja:documentation:pandorafms:start|Pandora FMS ドキュメント一覧に戻る]]