Question

我们正在评估在多服务器Weblogic环境中使用Logback。在一台机器上，我们在同一个Weblogic域上运行两个Weblogic服务器实例（基本上是两个独立的JVM进程）。服务器记录到相同的日志文件（application.log）。两个服务器的Logback配置（logback.xml）相同（如下所示）：

<configuration scan="true" debug="true">

    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>log/application.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <FileNamePattern>log/application.%d{yyyy-MM-dd}.log</FileNamePattern>
    </rollingPolicy>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
        <pattern>%d{HH:mm:ss.SSS} [%31.31logger] [%-5level] [%28.-28thread] %msg %xEx %n</pattern>
        </encoder>
    </appender>

    <logger name="org" level="ERROR"/>

    <root level="DEBUG">
        <appender-ref ref="FILE" />
    </root>
</configuration>

一切正常，直到编辑配置（例如更改了根日志记录级别或添加了新的记录器），之后日志记录完全停止。日志中没有打印任何内容，并且控制台中也没有可见的Logback错误消息。 Logback已经处于调试模式，通过在服务器启动时写入每个服务器控制台的以下内容来验证：

18:06:37,949 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
18:06:37,951 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
18:06:37,957 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/opt/bea10/user_projects/KG/resources/config/logback.xml]
18:06:39,457 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@158ef4f  - Will scan for changes in file [/opt/bea10/user_projects/KG/resources/config/logback.xml] every 60 seconds.
18:06:39,457 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter
18:06:39,471 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
18:06:39,556 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE]
18:06:40,061 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [rollingPolicy] on top of the object stack.
18:06:40,533 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - No compression will be used
18:06:40,563 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use the pattern log/application.%d{yyyy-MM-dd}.log for the active file
18:06:40,652 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'log/application.%d{yyyy-MM-dd}.log'.
18:06:40,652 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight.
18:06:40,654 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Wed Oct 20 17:43:20 EEST 2010
18:06:40,685 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [encoder] on top of the object stack.
18:06:41,256 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Active log file name: log/application.log
18:06:41,257 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - File property is set to [log/application.log]
18:06:41,307 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [org] to ERROR
18:06:41,307 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [org] to true
18:06:41,307 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
18:06:41,308 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to Logger[ROOT]
18:06:41,351 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.

Logback的版本是0.9.24，slf4j是1.6.0，Weblogic是10.3（怀疑是否重要），Java是1.6.0_12。操作系统是Solaris。我甚至尝试过使用Java选项

-XX:-UseVMInterruptibleIO

因为这被建议用于Solaris here上的Logback问题，但这没有帮助。

有没有办法让这项工作？完全让两个服务器写入同一个日志文件是一个坏主意吗？

Answer 1

正如Alex Poole先前提到的，prudent mode应该有所帮助。强烈建议注册状态监听器，例如OnConsoleStatusListener，因此可以报告在应用程序的生命周期内以及初始化回写之后出现的问题。

如果修改后的配置文件不是well formed，则logback版本0.0.29及更高版本将恢复为先前格式正确的配置文件。你没有提到新的配置文件有一个良好的形成问题，这就是为什么谨慎模式可能是最相关的反应。

Answer 2

prudent property有帮助吗？它增加了开销，但可以解决多个JVM的问题。我不确定你的症状是否相符，但值得一试。

Answer 3

我们遇到类似的问题，有时会在重新部署应用程序时停止日志记录。因此，我们将在每次部署后重新启动应用程序服务器。这解决了这个问题。

由于重新启动Prod服务器总是很困难，因此在进一步调查和搜索时，我们发现旧版本的logback存在问题。我们已将版本从1.1.7更改为1.1.10并解决了问题

配置重新加载后，Logback会停止记录

3 个答案: