Debugging Spring Boot in Docker: Logs, Exec, and Remote Debug

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

Primary debugging approaches: (1) check logs with docker logs -f, (2) exec into the container with docker exec -it for live inspection, (3) enable JVM remote debug port (5005) with -agentlib:jdwp and port-forward it to attach your IDE debugger. In Kubernetes use kubectl logs and kubectl exec equivalents.

Interview Answer3 min

Debugging a Spring Boot container means choosing between three tools depending on what kind of problem you have: interactive log inspection for startup failures, remote JDWP debugging for code-level bugs, and ephemeral debug containers for filesystem and process issues.

Log inspection — first tool for startup failures

docker logs --follow streams logs in real time; add --since 5m to limit to recent logs — the first tool you reach for on any startup failure or exception
If the container exits immediately, use docker logs without --follow after the fact — the logs are still available until the container is removed even though the process died
Spring Boot startup errors are almost always in the logs: APPLICATION FAILED TO START with a clear reason (missing property, bean conflict, database unreachable) — the error is one scroll up from the stack trace, not buried in it

JDWP remote debugging

Add -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 to the JVM startup command and expose port 5005 with -p 5005:5005 in Docker Compose — the suspend=n starts the application immediately without waiting for a debugger to attach
Never expose the JDWP port in production — the debug port has no authentication; anyone who can reach port 5005 can pause threads, read memory, and execute arbitrary code in the JVM
Connect IntelliJ's remote debugger to localhost:5005; set breakpoints normally — the debugger communicates with the JVM through the exposed port exactly as if debugging locally

Exec and ephemeral containers

docker exec -it /bin/sh opens a shell inside the running container for filesystem inspection, testing connectivity with wget, or checking environment variables — not available on distroless images
For distroless containers in Kubernetes, use kubectl debug -it --image=busybox --target=app to attach an ephemeral sidecar with a shell without modifying the running pod
docker stats shows CPU, memory, and network I/O in real time — the first tool for performance issues where the application is running but responding slowly

Interview-ready guide

Interview answer

Log inspection — first tool for startup failures

docker logs --follow streams logs in real time; add --since 5m to limit to recent logs — the first tool you reach for on any startup failure or exception
If the container exits immediately, use docker logs without --follow after the fact — the logs are still available until the container is removed even though the process died
Spring Boot startup errors are almost always in the logs: APPLICATION FAILED TO START with a clear reason (missing property, bean conflict, database unreachable) — the error is one scroll up from the stack trace, not buried in it

JDWP remote debugging

Add -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 to the JVM startup command and expose port 5005 with -p 5005:5005 in Docker Compose — the suspend=n starts the application immediately without waiting for a debugger to attach
Never expose the JDWP port in production — the debug port has no authentication; anyone who can reach port 5005 can pause threads, read memory, and execute arbitrary code in the JVM
Connect IntelliJ's remote debugger to localhost:5005; set breakpoints normally — the debugger communicates with the JVM through the exposed port exactly as if debugging locally

Exec and ephemeral containers

docker exec -it /bin/sh opens a shell inside the running container for filesystem inspection, testing connectivity with wget, or checking environment variables — not available on distroless images
For distroless containers in Kubernetes, use kubectl debug -it --image=busybox --target=app to attach an ephemeral sidecar with a shell without modifying the running pod
docker stats shows CPU, memory, and network I/O in real time — the first tool for performance issues where the application is running but responding slowly

03 · Deep dive