Container logging in production

The debugging lesson's docker logs command reads from one specific container, on the host you're currently connected to. Once an application runs as multiple replicas — across multiple hosts, as ECS or Kubernetes routinely does — "check the logs" means knowing which of N containers, on which of M hosts, actually handled the request in question, and SSHing around to check each one individually doesn't scale past a handful of instances.

Docker's default log driver, json-file, writes each container's stdout/stderr to a JSON file on the host's local disk — which is exactly why docker logs works at all, but also exactly why it stops working the moment a container (and its host-local log file) is gone.

max-size and max-file matter on their own even for local logging — without them, json-file's default is genuinely unbounded, and a verbose or looping application can fill a host's disk with log data alone, a real, self-inflicted outage distinct from anything the application itself is doing wrong.

A different log driver sends output directly to a centralized system instead of (or alongside) local disk:

This is exactly the awslogs configuration already shown in the ECS Fargate lesson's task definition — centralized logging isn't a separate add-on to orchestrated deployments, it's the only way "check the logs" remains a workable operation once there's more than one container to check, since the logs survive even after the specific container that wrote them is gone.

A plain text log line ("User 42 logged in at 10:32am") is readable by a human scrolling through it, but hard to filter or aggregate at scale. Structured logging (JSON-formatted log lines) trades a little human-readability for real queryability:

Once logs are structured JSON in a centralized store, "show me every failed login for user 42 in the last hour" becomes an actual query instead of a manual grep across files scattered over several hosts — this is the practical payoff that makes structured logging worth the upfront discipline of emitting it consistently from application code.

Rather than every application configuring its own log shipping, a common pattern runs a dedicated log-forwarding container (Fluentd, Fluent Bit) alongside the application, reading whatever the application already writes to stdout and forwarding it centrally — this is precisely the kind of workload the Kubernetes domain's DaemonSet lesson described (one log collector per node, automatically), letting application code stay completely unaware that centralized logging exists at all.

Centralized, structured logs from many replicas still need one more thing to be genuinely useful for tracing a single request's path: a correlation ID (or trace ID), generated once per incoming request and passed through every downstream log line and service call that request triggers. Without one, finding every log line related to one specific user's one specific slow request, across several services, means guessing at timestamps — with one, it's an exact filter on a single shared ID value.