解決策 1:
基本的に、それらはすべて同じであり、中央リポジトリ内のさまざまなタイプのシステムからのデータのログをすべて許可します。
しかし、これらは 3 つの異なるプロジェクトであり、各プロジェクトは前のプロジェクトの信頼性と機能を改善しようとしています。
Syslog プロジェクトは最初のプロジェクトでした。 1980年にスタートしました。 Syslog のルートプロジェクトです プロトコル。現時点では、Syslog は非常に単純なプロトコルです。最初はトランスポート用の UDP のみをサポートするため、メッセージの配信は保証されません。
次は syslog-ng でした 基本的な syslog を拡張します。 次のような新機能を備えたプロトコル:
- コンテンツ ベースのフィルタリング
- データベースへの直接ログイン
- トランスポート用の TCP
- TLS 暗号化
次は Rsyslog でした 2004 年。syslog を拡張 次のような新機能を備えたプロトコル:
- RELP プロトコルのサポート
- バッファ操作のサポート
今日、それらは 3 つの並行プロジェクトであり、バージョンごとに別々に成長しましたが、隣人が行っていたことに関しては並行して成長したとしましょう。
個人的には今日は syslog-ng だと思います 簡単で包括的なセットアップと構成に加えて、必要な主な機能を提供する最も成熟したプロジェクトであるため、ほとんどの場合に参考になります。
解決策 2:
これらは 3 種類のログ マネージャーです。システムがフィルターを収集し、ログを送信/保存できるようにします。
Syslog(デーモンはsysklogdとも呼ばれます ) は、一般的な Linux ディストリビューションのデフォルトの LM です。軽量ですが、あまり柔軟ではありません。ファシリティと重大度でソートされたログ フラックスをファイルやネットワーク (TCP、UDP) 経由でリダイレクトできます。-
rsyslogsysklogdの「高度な」バージョンです 構成ファイルは同じままです（syslog.confをコピーできますrsyslog.confに直接ファイルする そしてそれは動作します）;しかし、新しいクールなものがたくさんあります:- 制限付き (ポート、ソース IP) で TCP/UDP/... 接続をリッスンできます
- たくさんのモジュールをロードできます
- ログのフィルタリングは、プログラム、ソース、メッセージ、pid などで区別できます (たとえば、"connexion closed" というメッセージでタグ付けされた各メッセージをファイル closed.log に格納します)
- 1 つまたは複数のルールの後にメッセージを破棄できます http://www.rsyslog.com にアクセスしてください。これは非常に優れています
-
Syslog-ng は「次世代」です。ログを管理する最良の方法だと思います。すべてがオブジェクト (送信元、送信先、フィルター、および転送ルールそのもの) であり、構文が明確です。
rsyslogの機能に関しては疑問です とsyslog-ng
解決策 3:
<ブロック引用>syslog() のソース コードはどこから入手できますか
これは、glibc または他の Unix フレーバーの libc 実装によって提供されます。この呼び出しは基本的に、メッセージを syslog unix ドメイン ソケット /dev/log に送信します。このソケットは通常、システム ロガー (例:rsyslog、syslog-ng、nxlog など) によって作成されます。
解決策 4:
これらはすべて syslog デーモンであり、rsyslog と syslog-ng は、(ほとんどメンテナンスされていない) 従来の syslogd に代わる、より高速で機能豊富な代替品です。 syslog-ng はゼロから (別の構成形式で) 開始されましたが、rsyslog はもともと syslogd のフォークであり、その構文をサポートおよび拡張していました。近年、rsyslog は新しい構成形式のサポートも開始しました。ここまで来て、2 つを比較するのは、非常に詳細に踏み込んで炎上戦争を開始せずに行うのは非常に困難です.
一般に、Syslog は複数の可能性があるため、非常に混乱します。ここで曖昧さをなくすことに挑戦しました:https://sematext.com/blog/2017/01/30/what-is-syslog-daemons-message-formats-and-protocols/