Which Docker log drivers can serve logs back to docker logs, and what happens with the others?

## Reading back is a property of the driver The engine has no log store of its own. When you ask for a container's logs, `dockerd` asks that container's **logging driver** to replay them, and only some drivers can. That is the whole shape of the question, and it explains the war story it is usually asked as: somebody switched the fleet to a shipping driver, and the next incident began with a completely empty read against a container that was obviously producing output. **Drivers that can replay natively:** - **json-file** — reads its own `-json.log` files, including the rotated (and, if `compress` is on, gzipped) ones. - **local** — reads its own compact files, likewise across rotations. - **journald** — queries the systemd journal, which is a real store with its own index; entries are also reachable directly with `journalctl` filtered by container name or id. **Drivers that cannot:** `syslog`, `gelf`, `fluentd`, `splunk`, `awslogs`, `gcplogs` — each is a one-way pipe to something outside the engine. The engine will not go and query that backend on your behalf; retrieval there is the backend's own query language and tooling. And **`none`** discards everything, so nothing is readable by construction. ## Dual logging: why a modern engine still answers Docker Engine **20.10** introduced *dual logging* to remove exactly this cliff. When a container uses a driver that cannot serve reads, the daemon additionally writes the same messages to a bounded ring of **local**-driver files, used for nothing except answering read requests. The effect is that `docker logs` works on virtually every driver on a current engine, showing a recent window even though the authoritative copy is in a collector somewhere. It is tuned with log options that mirror the local driver's own: - `cache-disabled` — turn the cache off entirely (then reads fail as they did before 20.10) - `cache-max-size`, `cache-max-file` — bound the cache, the same size × count arithmetic as normal rotation - `cache-compress` — compress the rotated cache files Two consequences follow. First, on a host using a shipping driver you are still spending disk on logs, and that budget must be accounted for. Second, if someone has set `cache-disabled=true` to reclaim that disk, the empty-read failure mode is back — and it will be discovered during an incident, not before one. ## Diagnosing an empty read When a container's logs come back empty, work down the ownership chain rather than guessing: 1. **Which driver is this container actually using?** Not what `daemon.json` says today — log configuration is frozen at container creation, so a container started last month may be on a different driver than the current default. `docker inspect` shows the container's real `LogConfig`. 2. **Can that driver read?** If it is `none`, stop: there is nothing anywhere. If it is a shipping driver, check the engine version and whether `cache-disabled` is set. 3. **Did the driver ever get anything?** Only `stdout` and `stderr` are captured. An application logging to a file inside the container produces an empty read on *every* driver, and no driver change will fix it. 4. **Has rotation already discarded it?** With a tight `max-size × max-file` bound, a burst of output can push the interesting lines out within minutes. An empty-looking window is sometimes a rotation problem wearing a driver problem's clothes. ## Design implications The practical rule is that **the driver decides who can investigate and with what tool**. Choosing journald hands retrieval to the host's journal and everything that already reads it. Choosing a shipping driver hands the authoritative copy to a log backend and leaves you a short cached window locally. Choosing json-file or local keeps everything on the host, which is excellent for one machine and useless the moment the host is gone. Most fleets end up wanting both properties: an on-host copy short enough to be cheap and long enough for an on-call engineer to read directly, plus a durable copy elsewhere. Dual logging gives the first almost for free; deciding what the second is, and who owns it, belongs to the logging architecture rather than to the engine. One last nuance about the file-based drivers: replaying is not free. Both json-file and local read across rotated generations, and when `compress` is on the rotated files must be decompressed to be read, which costs CPU and temporary space at exactly the moment somebody is trying to work quickly. It is a small effect at 10 MB files and a noticeable one when a team has set a very large bound to keep more history locally. If reads have to be fast and wide, that is a signal the history belongs in a log backend built for querying rather than in bigger files on the host — the engine's replay is a convenience for one container, not a search tool.