☰

ケース1：

tag-icon • tag-icon syslog rsyslog syslog-ng rsyslogd
ケース1：

ケース1：

次のsyslog受信メッセージの場合、

<14>Mar 22 11:12:06 RT_FLOW: RT_FLOW_SESSION_CREATE: session created 1.2.3.4/62963->23.58.169.35/443 0x0 junos-https 6.7.8.9/32359->23.58.169.35/443 0x0 source rule 1 N/A N/A 6 1 Trust Untrust 60471 N/A(N/A) ge-0/0/1.0 UNKNOWN UNKNOWN UNKNOWN

syslog-ng正常に追加されましたCPU名タイムスタンプ（Mar 22 11:12:06）とメッセージタイプ（）のRT_FLOW間

ケース2：

しかし、、次の syslog 受信メッセージの場合、

<14> Mar 22 11:04:17 206.133.74.126 03362 auth:  User 'sup_ogr' logged in from 206.133.74.127 to SSH session

具体的には、タイムスタンプ（Mar 22 11:04:17）とメッセージタイプ（auth）の間にすでにIPアドレスがあります。

syslog-ngはいできない...を加えたCPU名タイムスタンプとメッセージタイプの間

使用される構成は次のとおりです。use_dns (yes);&keep_hostname (yes);

  1. 2番目のケースでは、syslogメッセージに次のものと一致するIPがありますか？RFC 5424基準？

  2. それでは、タイムスタンプとメッセージタイプの間にホスト名を設定するにはどのような設定が必要ですか？

答え1

私はsyslog-ngについてはよくわかりませんが、rsyslogと同様に、従来のsyslogメッセージを解析するために経験的な方法を使用すると仮定します（他の経験的な方法があるようです）。

表示されるメッセージは奇妙な形式であることに注意してください。 RFC3164は、Web上で一般的に見られるものを説明します。ここで、2番目の形式はそこで説明されているものとは異なります。可能であれば、最善の解決策は、送信者がフォーマットを変更して仕様をさらに遵守することです。

答え2

はい、2つのメッセージは似ていますが、RFC3164で説明されているsyslogメッセージの形式に正確に従うわけではありません。詳細については、このページと次のページを参照してください。syslog-ng ドキュメント。 syslog-ngもこれらの誤ったメッセージを解析しようとしますが、完全には実行されない可能性があります。次のことを試すことができます。

  • 送信するホストまたはアプリケーションを確認して、正しい形式のメッセージを送信するように調整できることを確認してください。
  • syslog-ngはメッセージ内のすべてのフィールドを解析できますが、正しいフィールドは解析できません。このメッセージのマクロ値を確認してみてください。メッセージ形式を正しく指定するためのテンプレートの作成
  • 他のすべての方法が失敗した場合は、以下を作成できます。Pythonのカスタムsyslog-ngパーサーこのログメッセージを解析してください。

HTH、ロバート

関連情報