私はLinuxサーバーのログを保存するより現代的な方法を探しています。 Rsyslog は、ログを保守可能に保ち、ログが占めるスペースを最小限に抑えるために、まだログロテートに大きく依存しており、これは推奨されるアプローチではありません。代わりに、以下に説明するように、データの損失やその他の問題を防ぐために、ログライターはログローターと同じでなければなりません。FGA：今世紀にはlogrotateやnewsyslogを使用しないでください。
私の目標は次のとおりです
- ログのメンテナンスを簡素化し、ログ出力を確認および操作するためのさまざまなツールを提供します。
- スペース不足の問題を回避し、構成のオーバーヘッドを回避して、このようなことが発生しないようにしてください。また、ログの重複を避ける
- このオプションは、ログが永久に開いているため、
copytruncate切り捨て中にロギングデータが失われる問題を回避するために使用する必要があります。または、サービスを強制的に再起動する必要がある代替方法を使用してください。 - それでも、中央ログサーバー/データベース（Elasticsearchなど）への配信の実装を単純にしてください。
私の経験では、rsyslog + logrotateを使用すると大きな努力がなければこれを行うことはできませんが、Journaldは少なくともこれらの基準をすべて満たしているようです。既存のジャーナル重複を削除します（ジャーナル処理中storage=persistent）。
ジャーナルドがこの目標に完全に準拠していると考える理由の詳細は次のとおりです。
- ログとスペース使用量を自動的に維持するのに十分スマートです（フォーマットは一貫しており、スペース使用量はパーティションの使用可能なスペースに基づいています）。
- 多くのソフトウェアはすでに互換性があります（dockerにはジャーナル処理されたロギングバックエンドがあり、ログ処理とLogstashに転送するためのジャーナルビットがあります）。
- 循環予約を処理するために「ダンプ」cronジョブに依存しません。
- ログを確認するための多くのツールがあります
- ログファイルは問題なく開いています。
- 広く使用されているすべてのサーバーディストリビューションにすでに組み込まれており、最小限の構成が必要です。
- 権限を正しく処理してその権限にアクセスするには、特定
admまたはグループsystemd-journalのメンバーシップが必要です。
日記で見た質問は次のとおりです。
- ログはバイナリ形式であり、外部ツールを使用したテキストベースの解析を許可しません（たとえば、Zabbixエージェントはこれらのログを解析し、特定のトリガに従って警告を発生させることはできません）。ただし、中央ログデータベースのログを介してこの操作を続行できます。
私が気になったのは、このアプローチを危険にさらすいくつかの重要な情報を見落としたり見逃しているのではありません。Red Hat LinuxやSUSE Enterprise Linuxなどの商用ディストリビューションにはまだrsyslogが含まれています。これは互換性の理由だけであり、使用する必要はないかもしれません。このソリューションは、すべてのディストリビューションと互換性のある一般的なソリューションと見なす必要があります。