Quartz的Log4J Appender运行时被外部修改为SocketAppender故障咨询

直接回答你的问题 #

Tomcat和SLF4J本身不存在会主动修改你应用内Log4j Appender的内置机制，你遇到的SocketAppender被动态注入的问题，几乎可以确定是服务器上安装的SolarWinds监控探针导致的。

根因分析 #

1. 监控探针的Java Agent注入逻辑 #

SolarWinds这类基础设施监控工具普遍会通过Java Agent技术注入到宿主机上所有运行的Java进程中，不需要依赖全局CLASSPATH或Java环境变量配置，就可以在类加载阶段或应用运行过程中修改目标进程的代码逻辑：

• 探针会主动识别应用使用的日志框架，动态向Log4j RootLogger添加SocketAppender，用于将应用日志上报到SolarWinds的监控服务端
• 如果监控服务端地址不可达、端口被防火墙拦截、网络不通，SocketAppender的同步写操作就会触发IO阻塞，而Log4j 1.x的Appender默认是同步执行的，会直接卡住当前打日志的业务线程（你场景中就是Quartz的调度线程）。

2. Log4j 1.x的设计支持运行时动态修改配置 #

Log4j 1.x的Logger体系没有做访问隔离，任意运行在同一个JVM进程中的代码，都可以通过以下代码动态添加Appender，完全不需要修改你的静态log4j配置文件，也不会在Log4j初始化阶段留下日志：

import org.apache.log4j.Logger;
import org.apache.log4j.net.SocketAppender;

// 任何代码都可以在运行时执行这段逻辑注入Appender
Logger rootLogger = Logger.getRootLogger();
SocketAppender monitorAppender = new SocketAppender("solarwinds-monitor-host", 4560);
rootLogger.addAppender(monitorAppender);

你看到启动时Log4j正确加载了你的RollingFileAppender配置，是因为探针的注入操作发生在Log4j初始化完成之后，所以启动日志不会有任何异常记录。

3. 排除Tomcat/SLF4J的可能性 #

• Tomcat默认使用JULI作为自身的日志实现，除非你主动配置了全局日志桥接，否则不会干预Web应用内部独立的Log4j实例配置
• SLF4J只是日志门面层，仅负责将日志调用转发到底层的日志实现（你场景中是Log4j 1.2.x），本身没有任何修改Appender的内置逻辑。

验证和修复方案 #

快速验证 #

在问题服务器的Tomcat启动参数中添加-XX:+DisableAttachMechanism禁用JVM动态attach能力，或者临时关闭SolarWinds的监控探针，重启应用后观察Quartz是否恢复正常、日志是否正常写入到本地RollingFileAppender，即可验证根因。

永久修复 #

1. 应用层面增加防护逻辑，在应用启动完成后主动清理非预期的Appender：

import org.apache.log4j.Appender;
import org.apache.log4j.Logger;
import java.util.Enumeration;

// 应用启动完成后执行这段逻辑
public void cleanUnexpectedAppenders() {
    Logger rootLogger = Logger.getRootLogger();
    Enumeration<Appender> appenders = rootLogger.getAllAppenders();
    while (appenders.hasMoreElements()) {
        Appender appender = appenders.nextElement();
        // 只保留你配置中定义的名为R的RollingFileAppender
        if (!"R".equals(appender.getName())) {
            rootLogger.removeAppender(appender);
        }
    }
}

2. 协调客户调整SolarWinds监控策略，将你的Java进程排除在日志采集范围外，或者配置探针仅读取日志、不注入SocketAppender。

内容的提问来源于stack exchange，提问作者jriffel73