CJE study materials
CJE study resources

CJE: Troubleshooting, Monitoring, and Maintenance

CJE ยท Work through your exam, one topic at a time.

All guide sections

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 or jenkins.log for the WAR). Manage Jenkins โ†’ System Log lets you add log recorders at runtime, e.g. logger hudson.plugins.git at FINE, without a restart - turn them back off afterwards.
  • Thread dumps answer "builds are hanging": /threadDump on the controller or jstack <pid>. Look for hudson.remoting channels, a blocked Executor, or an HTTP thread stuck in an SCM call. /heapDump and jmap capture memory for OutOfMemoryError analysis.
  • 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/json reports 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/json tree, 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 /login and accept 200, but a full disk still returns 200, so watch $JENKINS_HOME size separately.
  • Maintenance. /safeRestart waits for running builds then restarts; /restart and /safeExit are blunter. Quiet down stops new builds while running ones finish. Back up by copying JENKINS_HOME with the controller stopped, or use ThinBackup/Periodic Backup; treat secrets/ 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.