Dropwizard 日志删除不适用于 archivedFileCount 集

Question

我有一个 dropwizard 服务，并且我有以下 dropwizard 的 appender 配置：

    appenders=[
    {
        archive=true
        archivedFileCount=700
        archivedLogFilenamePattern="/logs/my-service/application.%d{yyyy-MM-dd_HH}.log.gz"
        currentLogFilename="/logs/my-service/application.log"
        logFormat="%-5level %date{ISO8601, UTC} %mdc{opc-request-id} [%thread] %logger: %message%n"
        timeZone=UTC
        type=file
    }]

我意识到上面的配置不起作用。我的日志目录中现在有 1500 + application..log.gz 文件。我检查了 dropwizard FileAppenderFactory 的日志，发现 archivedFileCount 用于设置 logback 的 maxHistory。根据 logback 文档，它应该只保留 700 小时的档案。服务能够毫无问题地将日志翻转到 log.gz 文件，但无法删除旧文件。我使用的是 dropwizard 1.3.5 版。

Answer 1

这可能是因为 TimeBasedRollingPolicy 实际上不是基于时钟，而是由事件驱动。来自他们的官方docs：

由于各种技术原因，翻转不是时钟驱动的，而是取决于日志事件的到来。 例如，在 2002 年 3 月 8 日，假设 fileNamePattern 设置为 yyyy-MM-dd（每日翻转），午夜后第一个事件的到来将触发翻转。如果在午夜后的 23 分 47 秒内没有记录事件，则翻转实际上将发生在 3 月 9 日凌晨 00:23'47，而不是凌晨 0:00。因此，根据事件的到达率，触发翻转可能会有一些延迟。

由于您使用每小时翻转率，如果日志事件在一个小时内未触发，则第一个小时的日志文件将错过删除；如果事件在 2 小时内没有触发，前 2 个将被错过，等等。

log_hr1, log_hr2, no log events fire for hr3, log_hr4, log_hr5 (initiate rollover)

...

log_hr1, log_hr245, log_hr6

所以，log_hr1 被遗漏了。

为了解决您的问题，您可以将翻转率更改为每天一次，以便获得更高的容错率。但是，这可能会引入第二个问题，即单个日志文件变得太大。为避免这种情况，您可以添加 ma​​xFileSize 属性并将翻转策略调整为 SizeAndTimeBasedRollingPolicy（将 %i 标志添加到日志文件名）。例如，

archivedLogFilenamePattern: ./logs/example-%d-%i.log.gz
archivedFileCount: 5
maxFileSize: "10mb"

这实质上是首先按日期归档，但也限制了每个日志文件的大小。每次当前日志文件在当前时间段结束前达到 maxFileSize 时，都会以递增的索引归档，从 0 开始。如果我们的应用程序停止并重新启动，日志记录将在正确的位置继续，即在最大的索引号当前期间。注意：这一切都记录在 Logback 的官方文档中。

希望这会有所帮助。