Lesson 28 of 30

Container Logging & Log Drivers

Q: A container writes its logs to a file inside itself, and those logs disappear every time the container restarts. Walk me through what's wrong and how you'd fix it, including where the fixed logs would actually end up.

A strong answer covers: Identifies the root cause: the container's filesystem is ephemeral, so a log file written inside it doesn't survive a restart or removal; States the fix: log to stdout/stderr instead, which the container runtime captures independently of the container's own filesystem; Names the log driver as the piece that determines where captured stdout/stderr output actually goes (json-file, journald, syslog, or a centralized aggregator); Recognizes that docker logs reads the driver's stored output, not a live file, and that this has implications for what's retrievable after a container stops or is rescheduled.

'Log to stdout, not a file' is standard container advice — but stdout alone doesn't explain where those logs actually go, or why `docker logs` keeps working after a container restarts. That's a separate piece: the log driver.

10 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

Why does the container convention say to log to stdout/stderr instead of writing to a log file inside the container?

A container's filesystem is ephemeral, so a log file written inside it disappears when the container is removed; stdout/stderr are captured independently of that filesystemstdout/stderr are faster to write to than a file, which is the primary reason for the conventionWriting to a file inside a container is technically impossible — containers don't support file writes at runtime

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Container Logging & Log Drivers

What interviewers actually ask about this, and what a strong answer has to cover.

A container writes its logs to a file inside itself, and those logs disappear every time the container restarts. Walk me through what's wrong and how you'd fix it, including where the fixed logs would actually end up.

A strong answer covers

Identifies the root cause: the container's filesystem is ephemeral, so a log file written inside it doesn't survive a restart or removal
States the fix: log to stdout/stderr instead, which the container runtime captures independently of the container's own filesystem
Names the log driver as the piece that determines where captured stdout/stderr output actually goes (json-file, journald, syslog, or a centralized aggregator)
Recognizes that docker logs reads the driver's stored output, not a live file, and that this has implications for what's retrievable after a container stops or is rescheduled

Likely follow-ups

This container runs under an orchestrator that reschedules it to different hosts. What happens to json-file's default logging behavior in that scenario, and would you change anything?
What's the actual risk of running json-file with no max-size or max-file configured on a host with several long-lived containers?

Practice these with the AI interviewer →

The plain-language idea

The logging pillar of the observability lesson in the Frontend Practices track establishes the principle generically: structured, contextual log lines are what let you answer "what actually happened" after the fact. This lesson is the concrete mechanism underneath that principle at the container-runtime level — where a container's logs actually go, and what makes them retrievable at all.

The container convention is: write logs to stdout/stderr, never to a file inside the container. A container's filesystem is ephemeral — anything written inside it, including a log file, disappears the moment the container is removed. stdout/stderr aren't subject to that, because they're not really "inside" the container's filesystem at all; the container runtime captures that output stream directly.

What actually happens to that captured stream is the log driver's job, and it's a separate, configurable piece most people never think about until they need to change it:

json-file — the default. Each container's stdout/stderr gets written to a JSON-formatted file on the host, one entry per line. Simple, works out of the box, but lives on that one host's disk.
journald — routes container logs into the host's systemd journal, integrating with whatever log tooling already reads journald on that machine.
syslog — sends logs to a syslog daemon, local or remote, following that long-established logging protocol.
A centralized aggregator (Fluentd, a cloud provider's logging service, and similar) — ships logs off the individual container host entirely, to a system built for searching and retaining logs across a whole fleet, not just one machine.

See it in a real thing: `docker logs` doesn't read a live file

# check which driver a running container is actually using
docker inspect --format '{{.HostConfig.LogConfig.Type}}' my-container

# set a driver at container-run time
docker run --log-driver=json-file --log-opt max-size=10m myapp

# or globally, in the daemon config (dockerd)
# /etc/docker/daemon.json
# { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

The max-size/max-file options above matter in practice more than people expect: json-file with no size cap will grow that log file indefinitely for a long-running, chatty container, quietly consuming host disk until something else fails because of it — capping and rotating logs is not automatic by default.

What people usually miss

Watch out

json-file (the default) keeps logs on the single host the container ran on. If that container gets rescheduled onto a different machine, or the host disk fills up and gets cleaned, those logs are effectively gone — this is exactly why a fleet running under an orchestrator typically pairs container logging with a centralized aggregator, not the default driver alone.
Uncapped json-file logs are an unbounded disk-usage risk, not just a cosmetic one. Without max-size/max-file configured, a single verbose container can fill host disk over time, which can then take down unrelated containers on the same machine that have nothing to do with the original noisy one.
Switching log drivers is a real operational decision, not a config toggle with no consequences. Some drivers don't support docker logs reading historical output locally at all once logs are shipped elsewhere — losing the ability to docker logs a container directly is a real tradeoff for centralizing logs, not a bug.
"Log to stdout" doesn't mean "logging is now someone else's problem." The application still needs to emit structured, contextual log lines (the observability lesson's point) — the driver only controls where captured output goes, not whether what's being emitted is actually useful once it gets there.

Why this matters in interviews

"A container writes logs to a file inside itself and they disappear every restart — what's wrong?" is a real, specific diagnostic question, and the strong answer names the actual fix (stdout/stderr, captured by a log driver) and can go one level deeper into which driver is appropriate for a single host versus a fleet — not just "use a logging library," which doesn't address where the output actually needs to go.