Dropwizard не удаляет старые файлы журнала, как настроено в файле конфигурации обратного входа - PullRequest
Новая
       25

Dropwizard не удаляет старые файлы журнала, как настроено в файле конфигурации обратного входа

0 голосов
/ 29 марта 2019

Моя группа использует Dropwizard в качестве основы. В настоящее время мы настраиваем Logback на следующее значение для archiveFileCount: 

archivedLogFilenamePattern = ${logRoot}"/trace-"${serviceId}"-%d{yyyy-MM-dd-HH}.log.gz"

archivedFileCount = 48

Исходя из этой конфигурации, журналы должны пролонгироваться каждый час, и журналы должны быть рассчитаны на два дня.

То, что мы на самом деле видим, - это число файлов журнала, равное 92. Кроме того, оставленные позади файлы журнала кажутся случайными часами от случайных дней (см. Фрагмент в конце этого поста).

Я попытался использовать флаг отладки для входа в систему, чтобы увидеть, как при входе в систему происходит переворачивание файла и очистка старого файла, но я не вижу никаких сообщений отладки, специфичных для обратного входа в журналах в STDOUT 

-Dlogback.debug=true

Кто-нибудь знает, как включить отладку для входа в систему в среде Dropwizard? Вот информация о версии:

Dropwizard: 3.1.2 Выход из системы: 1.1.7 

trace-fakeServiceId-2019-02-26-18.log.gz
trace-fakeServiceId-2019-02-26-21.log.gz
trace-fakeServiceId-2019-02-26-23.log.gz
trace-fakeServiceId-2019-02-27-15.log.gz
trace-fakeServiceId-2019-02-27-18.log.gz
trace-fakeServiceId-2019-02-27-19.log.gz
trace-fakeServiceId-2019-02-27-21.log.gz
trace-fakeServiceId-2019-03-02-16.log.gz
trace-fakeServiceId-2019-03-02-18.log.gz
trace-fakeServiceId-2019-03-02-19.log.gz
trace-fakeServiceId-2019-03-02-21.log.gz
trace-fakeServiceId-2019-03-02-22.log.gz
trace-fakeServiceId-2019-03-03-20.log.gz
trace-fakeServiceId-2019-03-03-21.log.gz
trace-fakeServiceId-2019-03-03-22.log.gz
trace-fakeServiceId-2019-03-04-19.log.gz
trace-fakeServiceId-2019-03-04-21.log.gz
trace-fakeServiceId-2019-03-04-22.log.gz
trace-fakeServiceId-2019-03-05-17.log.gz
trace-fakeServiceId-2019-03-05-18.log.gz
trace-fakeServiceId-2019-03-09-20.log.gz
trace-fakeServiceId-2019-03-09-21.log.gz
trace-fakeServiceId-2019-03-09-22.log.gz
trace-fakeServiceId-2019-03-10-19.log.gz
trace-fakeServiceId-2019-03-11-16.log.gz
trace-fakeServiceId-2019-03-11-17.log.gz
trace-fakeServiceId-2019-03-11-19.log.gz
trace-fakeServiceId-2019-03-12-17.log.gz
trace-fakeServiceId-2019-03-12-20.log.gz
trace-fakeServiceId-2019-03-12-21.log.gz
trace-fakeServiceId-2019-03-12-22.log.gz
trace-fakeServiceId-2019-03-12-23.log.gz
trace-fakeServiceId-2019-03-13-19.log.gz
trace-fakeServiceId-2019-03-17-16.log.gz
trace-fakeServiceId-2019-03-17-17.log.gz
trace-fakeServiceId-2019-03-17-21.log.gz
trace-fakeServiceId-2019-03-17-23.log.gz
trace-fakeServiceId-2019-03-18-19.log.gz
trace-fakeServiceId-2019-03-18-20.log.gz
trace-fakeServiceId-2019-03-18-23.log.gz
trace-fakeServiceId-2019-03-20-23.log.gz
trace-fakeServiceId-2019-03-23-17.log.gz
trace-fakeServiceId-2019-03-24-00.log.gz
trace-fakeServiceId-2019-03-24-16.log.gz
trace-fakeServiceId-2019-03-27-19.log.gz
trace-fakeServiceId-2019-03-27-20.log.gz
trace-fakeServiceId-2019-03-27-21.log.gz
trace-fakeServiceId-2019-03-27-22.log.gz
trace-fakeServiceId-2019-03-27-23.log.gz
trace-fakeServiceId-2019-03-28-00.log.gz
trace-fakeServiceId-2019-03-28-01.log.gz
trace-fakeServiceId-2019-03-28-02.log.gz
trace-fakeServiceId-2019-03-28-03.log.gz
trace-fakeServiceId-2019-03-28-04.log.gz
trace-fakeServiceId-2019-03-28-08.log.gz
trace-fakeServiceId-2019-03-28-09.log.gz
trace-fakeServiceId-2019-03-28-10.log.gz
trace-fakeServiceId-2019-03-28-11.log.gz
trace-fakeServiceId-2019-03-28-12.log.gz
trace-fakeServiceId-2019-03-28-13.log.gz
trace-fakeServiceId-2019-03-28-14.log.gz
trace-fakeServiceId-2019-03-28-15.log.gz
trace-fakeServiceId-2019-03-28-16.log.gz
trace-fakeServiceId-2019-03-28-17.log.gz
trace-fakeServiceId-2019-03-28-18.log.gz
trace-fakeServiceId-2019-03-28-19.log.gz
trace-fakeServiceId-2019-03-28-20.log.gz
trace-fakeServiceId-2019-03-28-21.log.gz
trace-fakeServiceId-2019-03-28-22.log.gz
trace-fakeServiceId-2019-03-28-23.log.gz
trace-fakeServiceId-2019-03-29-00.log.gz
trace-fakeServiceId-2019-03-29-01.log.gz
trace-fakeServiceId-2019-03-29-02.log.gz
trace-fakeServiceId-2019-03-29-03.log.gz
trace-fakeServiceId-2019-03-29-04.log.gz
trace-fakeServiceId-2019-03-29-08.log.gz
trace-fakeServiceId-2019-03-29-09.log.gz
trace-fakeServiceId-2019-03-29-10.log.gz
trace-fakeServiceId-2019-03-29-11.log.gz
trace-fakeServiceId-2019-03-29-12.log.gz
trace-fakeServiceId-2019-03-29-13.log.gz
trace-fakeServiceId-2019-03-29-14.log.gz
trace-fakeServiceId-2019-03-29-15.log.gz
trace-fakeServiceId-2019-03-29-16.log.gz
trace-fakeServiceId-2019-03-29-17.log.gz
trace-fakeServiceId-2019-03-29-18.log.gz

1 Ответ

0 голосов
/ 10 апреля 2019

Из документации Logback для TimeBasedRollingPolicy шаблон имени файла для ежечасного расписания ролловеров составляет %d{yyyy-MM-dd_HH}

В вашем случае значение archivedLogFilenamePattern должно быть 

${logRoot}"/trace-"${serviceId}"-%d{yyyy-MM-dd_HH}.log.gz"

Надеюсь, что это работает для вас.

...