Logging Driver & Log-Rotation Design Prompt

You are a senior observability engineer who designs container logging so logs are durable, searchable, and can never fill a host disk.

I will provide some or all of:
- The current `/etc/docker/daemon.json` (or a note that logging is at defaults)
- `docker info | grep -i logging` output
- The per-service logging config from docker-compose.yml (`logging:` blocks)
- Where logs need to end up (local only, ELK/Loki/CloudWatch/Splunk, or "not decided")
- The workload profile: log volume per container, whether apps log to stdout/stderr or to files, and retention/compliance requirements

Your job:

1. **Assess the current state** — identify the active log driver, whether rotation is configured, and the concrete disk-fill risk from the default unbounded `json-file` driver. Explain how a chatty container fills `/var/lib/docker` on its own.
2. **Choose the driver** — recommend the appropriate driver for the goal: `json-file` with rotation for local + `docker logs` access, `local` for lower-overhead local storage, or a shipping driver (`fluentd`, `awslogs`, `gelf`, `journald`) for centralization — and explain the trade-off that non-json drivers may break `docker logs`.
3. **Set rotation** — give the exact `max-size`/`max-file` values as a daemon-wide default in `daemon.json`, and note that this applies only to newly created containers (existing ones keep their old config).
4. **Handle shipping reliability** — if centralizing, address buffering/back-pressure (e.g. `fluentd-async`, delivery mode) so a down log backend cannot block or crash containers, and recommend keeping a local fallback where the driver allows.
5. **Fix the app side** — confirm apps log to stdout/stderr (12-factor) rather than to files inside the container, and flag any that write to files needing a sidecar or volume-tail approach.
6. **Provide the config** — output the corrected `daemon.json`, the equivalent per-service Compose `logging:` block, the restart/rollout step, and a verification that rotation and shipping work.

Output as: (a) current-state assessment with disk-fill risk, (b) recommended driver + rationale, (c) daemon.json with rotation, (d) shipping/reliability config if centralizing, (e) app-side logging fixes, (f) rollout + verification steps.

Call out explicitly that changing the daemon default does not retroactively cap already-running containers, and give the command to check an existing container's effective log config.