当 logback 与 logrotate 结合使用时，推荐的配置是什么？根据调查博客等，隐式推荐配置是使用FileAppender.append=true然后 logrotate 的copytruncate选项。
它是否正确？我需要注意这里有龙吗？
问问题
4746 次
2 回答
3
多年来为多个客户这样做，最受青睐的方法是使用 TimeBasedRollingPolicy，每天滚动（可以设置为任何频率）并将 MaxHistory 设置为所需的天数（通常为 30）。
虽然我喜欢并将 logrotate 用于其他日志文件，但 Logback 的内置滚动意味着我的客户不需要 logrotate。
为了在应用程序/集中化之间进行协调，Logback 可以包含其他 Logback 配置文件，因此您可以在文件中定义标准的 appender 片段（Logback 支持属性，因此包含文件可以根据需要定义信息）。
即使有上述情况，也可能希望 logrotate 具有 Logback 没有的...但是我想分享 TimeBasedRollingPolicy 以防它被忽略。
至少，这种方法可以在 Logback 滚动文件上进行 logrotate 工作，避免 logrotate 在活动 Logback 日志文件上操作的潜在问题。
并且保持日志隔离（不要将应用程序日志混合到系统日志中）对于故障排除（应用程序和系统）非常有帮助 - 两者都不必处理其他人的噪音。
于 2013-10-05T01:51:37.240 回答
2
我不确定正确的方法是什么，因为今天早些时候我遇到这个问题只是因为我在寻找相同的答案。
我认为这种方法会起作用，但是它有两个相对较小的问题（如果您甚至可以这样称呼它们）：
- 有一个竞争条件窗口，日志数据可能会在 logrotate 复制数据的时间和发生数据截断的时间之间丢失
- Logrotate 必须复制整个文件，与关闭/重新打开日志文件的典型方法 SIGHUP 相比，这似乎有点浪费。
在我自己的搜索中，我现在正在考虑从 FileAppender（或 Rolling one）切换到 SysLogAppender 并将 logrotate 与 rsyslog 一起使用，这两者非常自然地协同工作。再说一次，我考虑这样做的原因是因为我们的系统中有其他 python 守护程序，并且这些守护程序已经使用 rsyslog。我对切换到 SysLogAppender 的唯一保留是我不知道它如何处理异常堆栈跟踪，因为 syslog 不允许超过 1024 个字符的消息。
在回答 Martin Schroder 的评论时，我想我想按照你的原因进行转换。因此，我们所有服务的日志配置都以相同的方式进行配置和处理，并且具有相同的行为。
于 2013-10-02T02:33:03.487 回答