Die API geändert hat (zB setMaxFileSize existiert nicht mehr) und eine Menge von dem Zeug oben nicht scheinen zu arbeiten, aber ich habe etwas, das für mich gegen Logback 1.1.8 arbeitet (das neueste zu dieser Zeit).
Ich wollte beim Start und rollen auf Größe, aber nicht Zeit. Das macht es:
public class RollOnStartupAndSizeTriggeringPolicy<E> extends SizeBasedTriggeringPolicy<E> {
private final AtomicBoolean firstTime = new AtomicBoolean();
public boolean isTriggeringEvent(final File activeFile, final E event) {
if (firstTime.compareAndSet(false, true) && activeFile != null && activeFile.length() > 0) {
return true;
}
return super.isTriggeringEvent(activeFile, event);
}
}
Damit benötigen Sie auch eine rollierende Politik. FixedWindowRollingPolicy würde wahrscheinlich tun, aber ich mag es nicht, weil ich eine große Anzahl von Dateien behalten möchte und das ist sehr ineffizient dafür. Etwas, das schrittweise aufwärts zählt (anstatt wie FixedWindow zu gleiten), funktioniert, aber das existiert nicht. Solange ich meine eigene schreibe, habe ich beschlossen, Zeit zu verwenden statt zu zählen. Ich wollte den aktuellen Logback-Code erweitern, aber für die zeitbasierten Sachen werden die Rolling- und Triggering-Richtlinien oft zu einer Klasse zusammengefasst, und es gibt Protokolle von Verschachtelung und Kreisverkehr und Feldern ohne Getters, also fand ich das eher unmöglich. Also musste ich viel von vorne anfangen. Ich halte es einfach und implementiere keine Funktionen wie die Komprimierung - ich hätte sie gerne, aber ich versuche es einfach zu halten.
public class TimestampRollingPolicy<E> extends RollingPolicyBase {
private final RenameUtil renameUtil = new RenameUtil();
private String activeFileName;
private String fileNamePatternStr;
private FileNamePattern fileNamePattern;
@Override
public void start() {
super.start();
renameUtil.setContext(this.context);
activeFileName = getParentsRawFileProperty();
if (activeFileName == null || activeFileName.isEmpty()) {
addError("No file set on appender");
}
if (fileNamePatternStr == null || fileNamePatternStr.isEmpty()) {
addError("fileNamePattern not set");
fileNamePattern = null;
} else {
fileNamePattern = new FileNamePattern(fileNamePatternStr, this.context);
}
addInfo("Will use the pattern " + fileNamePattern + " to archive files");
}
@Override
public void rollover() throws RolloverFailure {
File f = new File(activeFileName);
if (!f.exists()) {
return;
}
if (f.length() <= 0) {
return;
}
try {
String archiveFileName = fileNamePattern.convert(new Date(f.lastModified()));
renameUtil.rename(activeFileName, archiveFileName);
} catch (RolloverFailure e) {
throw e;
} catch (Exception e) {
throw new RolloverFailure(e.toString(), e);
}
}
@Override
public String getActiveFileName() {
return activeFileName;
}
public void setFileNamePattern(String fnp) {
fileNamePatternStr = fnp;
}
}
Und dann Config wie
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
<file>/tmp/monitor.log</file>
<rollingPolicy class="my.log.TimestampRollingPolicy">
<fileNamePattern>/tmp/monitor.%d{yyyyMMdd-HHmmss}.log</fileNamePattern>
</rollingPolicy>
<triggeringPolicy class="my.log.RollOnStartupAndSizeTriggeringPolicy">
<maxFileSize>1gb</maxFileSize>
</triggeringPolicy>
</appender>
sieht, wenn Sie frustriert sind diese nicht nativ gelöst ist, für ihn stimmen bei
http://jira.qos.ch/browse/LOGBACK-204
http://jira.qos.ch/browse/LOGBACK-215
(es ist Jahre her, und das ist für mich absolut kritischer Spaß ctionality, obwohl ich weiß, dass viele andere Frameworks es auch scheitern)
Leider funktioniert das nicht, weil die auslösende Richtlinie Null von getElapsedPeriodsFileName() zurückgibt, die dann den Rollover() in die Luft jagt. –