我有一个Jenkins仪表板，连接着若干Freestyle项目和多台节点。每个节点在Windows服务器上执行一个脚本后，自动通过管理员身份的CMD启动对应的代理。超过一年多以来，一切都正常，直到突然所有节点离线，而代理仍然连接到服务器。即使重启服务器上的Jenkins服务，终止运行代理的自动脚本，甚至尝试手动启动代理，Jenkins中的节点仍然离线。可能出了什么问题？基础设施与服务器团队修复了服务器慢的问题，但他们说不知道原因，问题似乎取决于我们在Jenkins应用中的改动，但我们没有改动任何东西。最近唯一的变化是并行自动化模式，涉及大量Chrome实例，可能让服务器有点儿吃不消，我也不知道它是否已经连接。

下面给出一个在服务器上用于启动代理的片段示例：

java -jar agent.jar -jnlpUrl <jenkins_url>/jenkins-agent.jnlp -secret <secret_key> -workDir "<work_directory>"

在CMD中输出的关键内容：

INFO: Agent discovery successful
  Agent address: <address>
  Agent port:    <redacted>
INFO: Connected

在Jenkins的输出中显示的节点日志：

Inbound agent connected from <redacted>
Remoting version: 3107.v665000b_51092
Launcher: JNLPLauncher
Communication Protocol: JNLP4-connect

添加附加的远程日志记录器：

    Send Unexport
    FINEST hudson.slaves.SlaveComputer
    JNLP4-connect connection from <server ip info>:54036 wrote 1443:              Unexport
    FINEST org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer
    [JNLP4-connect connection from <server ip info>:54036] APP      ENCODE: 1,445 bytes
FINEST org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer
[JNLP4-connect connection from <server ip info>:54036] Handshake status: NOT_HANDSHAKING engine result: Status = OK HandshakeStatus = NOT_HANDSHAKING
bytesConsumed = 1445 bytesProduced = 1483 sequenceNumber = 19
FINEST org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer
[JNLP4-connect connection from <server ip info>:54036] APP SEND: 1,483 bytes
FINEST org.jenkinsci.remoting.protocol.impl.NIONetworkLayer
[JNLP4-connect connection from <server ip info>:54036] SEND: 1,483 bytes
FINEST org.jenkinsci.remoting.protocol.IOHub
Scheduling adding OP_WRITE to channel=java.nio.channels.SocketChannel[connected local=/<ip>:49854 remote=<server ip info>:54036], selector=sun.nio.ch.WEPollSelectorImpl@4bbcc33e, interestOps=1, readyOps=4
FINE hudson.remoting.Channel
Send Unexport

解决方案

日志中的直接证据是在建立连接后立刻出现的 Send Unexport 信息。这意味着Jenkins在代理连接后，正在主动从控制器端拆除远程通道。代理执行正常，连接和SSL握手也都正常，但Jenkins在节点初始化之前就把它终止了。

由于所有节点同时离线，而你的基础设施团队正在处理“服务器慢”的问题，这几乎可以确定是控制器端的资源问题。你提到的重度Chrome自动化可能让Jenkins的 JVM处于一个不良状态（堆内存耗尽、线程饥饿），即使基础设施修复后，Jenkins也可能尚未完全恢复。

有几件事需要检查：

1.彻底重启Jenkins（不仅仅是重启服务）

如果你只是重启了Windows服务，JVM可能已经处于错误的状态。请前往 <jenkins_url>/safeRestart，从UI执行一次干净的重启。这会清空所有内存中的状态。

2.检查控制器的堆内存

转到 <jenkins_url>/monitoring（如果安装了Monitoring插件），或者检查JVM启动参数。如果Jenkins的堆大小很小，而Chrome自动化的高峰把它推入持续的GC，控制器就没有足够的资源来初始化传入的代理连接。它会建立连接，发现无法分配所需资源，然后立即发送Unexport。

查看你的Jenkins启动脚本中关于 -Xmx 的设置。如果堆大小小于2G，且你在运行多个并行的Chrome密集型作业，请提升它。

3.从控制器角度检查工作目录

在连接后，Jenkins会验证代理的 workDir。如果基础设施团队在修复过程中改变了网络共享、挂载点或权限等设置，Jenkins可能无法初始化远程文件系统并因此断开连接。在代理机上，确保工作目录存在，并且运行 agent.jar 的用户具备写权限。

4.检查 <jenkins_url>/log/all

默认的Jenkins日志通常会显示为什么节点被标记为离线。在 Send Unexport 的时间戳附近查找相关条目。你很可能会看到类似 IOException 或 ChannelClosedException 之类的条目，给出实际原因。

5. Remoting版本

你的代理正在运行Remoting 3107.v665000b_51092。如果Jenkins最近有更新（甚至插件更新也可能引入新的Remoting版本），可能会存在不匹配。请查看 <jenkins_url>/about，了解控制器端的Remoting版本。如果两者不匹配，请在每台代理机器上从 <jenkins_url>/jnlpJars/agent.jar 下载 agent.jar。

我的猜测更可能是#1或 #2。Chrome的高负载把堆内存耗尽了，基础设施修复了底层的服务器慢问题，但Jenkins自身并没有得到正确的重启。