Troubleshooting, Monitoring, and Maintenance
What this domain covers
Diagnosis under pressure: reading logs and thread dumps, exposing metrics, and keeping a controller alive across upgrades. Questions often ask for the first thing you check.
Core rules
- Logs. Jenkins uses java.util.logging; server logs land in
$JENKINS_HOME/logs/(plus the console orjenkins.logfor the WAR). Manage Jenkins โ System Log lets you add log recorders at runtime, e.g. loggerhudson.plugins.gitatFINE, without a restart - turn them back off afterwards. - Thread dumps answer "builds are hanging":
/threadDumpon the controller orjstack <pid>. Look forhudson.remotingchannels, a blockedExecutor, or an HTTP thread stuck in an SCM call./heapDumpandjmapcapture memory forOutOfMemoryErroranalysis. - Script Console (Manage Jenkins โ Script Console) runs Groovy inside the controller JVM - useful for inspecting
Jenkins.instance, but a real security liability on a shared instance. - Agent diagnosis.
/computer/<name>/api/jsonreports the offline cause; the agent's own log shows connection and protocol errors. Frequent causes: wrong secret, clock skew, firewall on 50000, full disk. - Monitoring. The
/api/jsontree, the Prometheus plugin (/prometheus/), the Metrics plugin, and the Monitoring plugin (JavaMelody at/monitoring) expose queue length, executor utilisation, response times, and heap. Health probes should hit/loginand accept 200, but a full disk still returns 200, so watch$JENKINS_HOMEsize separately. - Maintenance.
/safeRestartwaits for running builds then restarts;/restartand/safeExitare blunter. Quiet down stops new builds while running ones finish. Back up by copyingJENKINS_HOMEwith the controller stopped, or use ThinBackup/Periodic Backup; treatsecrets/as sensitive. - Hygiene: discarders everywhere,
cleanWs(), artifact retention limits, plugin updates rehearsed in a staging copy, and heap kept below the container limit.
Worked example
Every build on one agent hangs at "Fetching upstream changes". Reasoning: the executor is alive but blocked inside the Git client, so the controller is healthy and the agent's network or credentials are suspect. Take a controller thread dump to confirm the thread sits in the Git plugin, check the agent's disk and DNS, then run git ls-remote on the agent with the same credential. Raising timeouts without finding the block is the wrong fix.
Traps
Killing the JVM instead of /safeRestart, which can leave build records inconsistent; enabling FINE logging globally and filling the disk; assuming a green /login means the instance is healthy; restoring a backup taken while Jenkins was still writing.