我正在寻找一种更现代的方式来保存 Linux 服务器的日志。 Rsyslog 仍然强烈依赖 logrotate 来保持日志的可维护性并将日志占用的空间降至最低，这不再是推荐的方法。相反，日志编写器应该与日志旋转器相同，以避免任何数据丢失和其他问题，如下详细描述：FGA：本世纪不要使用 logrotate 或 newsyslog
我的目标是：
- 保持日志维护简单并提供很多工具来检查和操作日志的输出
- 避免空间超出的问题并避免配置开销以防止这种情况发生。还避免日志重复
- 避免日志永远保持打开状态的问题，并且
copytruncate应该使用该选项，从而导致截断过程中发生的日志记录数据丢失。或者使用需要强制重启服务的替代方法 - 仍然保持简单地实现转发到中央日志服务器/数据库（如 Elasticsearch）
根据我的经验，如果不付出太多努力，rsyslog + logrotate 是不可能做到这一点的，但journald似乎至少满足所有这些标准，所以我想专门使用它并删除rsyslog以达到已经描述的目的，以及删除现有的日志重复（当journald时storage=persistent）。
关于为什么我认为journald完全符合这个目标的详细信息：
- 它足够智能，可以自动维护日志和空间使用情况（格式一致，空间使用情况基于分区上的可用空间）
- 很多软件已经与其兼容（docker有一个journald日志记录后端，有journalbeat用于日志处理并将它们发送到Logstash）
- 它不依赖于“转储”cron 作业来处理轮换调度
- 有很多工具可以检查日志
- 日志文件保持打开状态没有问题
- 它已经内置在所有流行的服务器发行版中，并且需要最少的配置
- 正确处理权限并要求具有
adm或systemd-journal组的成员身份才能访问它们
我在日记中看到的问题是：
- 日志采用二进制格式，不允许使用外部工具进行基于文本的解析（例如，Zabbix 代理无法解析这些日志并根据某些触发器发出警报）。尽管这仍然可以通过中央日志数据库中的日志来完成。
我想知道的是，我是否忽略了或者遗漏了一些关键信息，从而使得这种方法变得有风险。我发现 Red Hat Linux 和 SUSE Enterprise Linux 等商业发行版仍然包含 rsyslog，尽管这可能只是出于兼容性原因，并不要求使用它。请注意，此解决方案应被视为与任何发行版兼容的通用解决方案。