Add purge of old logs file #576
Conversation
|
Thanks for the PR! For log rotation, I'd much prefer have this managed by the logging framework (log4j / logback, yes, there is a mess there). That's one less system dependency... |
|
I'm not a Java developer, so I've a very little knowledge of log4j 1.x/log4j 2.x/logback and co. So for me, if we want to support this in logging framework, we need to add logback and/or upgrade to log4j 2.x. Should I try to look at upgrading log4j or add logback ? |
|
Since you seem to be managing Java application, some knowledge of the standard logging framework will probably help you in the long run :) (sorry I could not resist). The situation is a bit complex... We have a mess of both logback and log4j. The way to go is definitely logback, but there are some OutputWriters that depend directly on log4j, which makes removing it (or upgrading it) a giant pain. Not that there is a time based rolling policy in log4j-extra, which is already bundled with jmxtrans. This could be a short term approach. |
|
From my search the logger that support deletion of history are:
For the last solution, I don't see how to do it. jmxtrans-output-log4j use SLF4F and its log4j12 binding. From SLF4J documentation we should "drop one and only one binding [...] onto the [...] class path". Therefor I can't add logback binding without providing two binding. The second solution means dropping usage of SLF4J (or we have the same problem as described above). It should be much more than just changing all logger creation. It also means that SLF4J + log4j 1.2 will still be used but jmxtrans-output-log4j. But since log4j 2 use another package namespace (org.apache.logging.log4j vs org.apache.log4j it should be conflict). The first solution is just configuration change. But it means that rotation will be size based and no longer time based. |
|
Another solution would be to use https://logging.apache.org/log4j/extras/apidocs/org/apache/log4j/rolling/TimeBasedRollingPolicy.html with log4j. The class is already on the classpath. |
|
I don't see how it help. It should already be used by log4j.xml and don't seem to have any option to limit history size. |
|
(closed my mistake, sry) |
|
In any case, the "right" solution would be to deprecate the log4j based output writers (keep them as an optional module) and move all logging to logback... |
|
I also tried to replace the Log4J1 dependency by a Log4J2 dependency for similar need. |
|
Yeah, those log4j appenders are a mess. We should deprecate them and replace them by slf4j output writer, which can do the same things, but driven by logging configuration. This would require writing some docs on how to use it, remove the log4j appender from the final build (we could keep them around, just in case someone really likes them). My preference would be to migrate to logback more than log4j2, but I'm open to alternatives. |
|
Since v270 (maybe v269), JMXTrans uses Logback library. Its RollingFileAppender supports a TimeBasedRollingPolicy which supports both time and size rotation. |
It seems that currently nothing purge old logs file. Which means that after a while a lots of files may be present in /var/log/jmxtrans and consume disk space.
I'm not sure logs older that few weeks are still useful.
The PR add a daily cron script that remove all archived logs older than 32 days.