A service writes its log to a file inside the container and the platform's captured log view is empty — why?

## What the platform actually captures When a container platform starts a workload it starts one process inside the boundary and connects that process's two output streams — **standard output** and **standard error** — to pipes the runtime itself holds open. Everything written there is read by the runtime, stamped with the time the runtime read it, and appended to files the node manages on the node's own disk. Those node-side files are what the platform's log view reads back, and what a collector running on the host ships onward. The workload configures nothing: **the contract is "write to the stream", and the platform owns everything after the write.** That is the whole of the default capture path, and it is deliberately narrow. It is the only thing a platform can offer identically to every workload, on every node, whatever the workload is written in: a process that can print has already satisfied it. Anything else — a file, a socket, a local agent of your own — is something you added, and the platform makes no promise about it. ## Why the file is invisible A write to a path inside the container is an ordinary filesystem write. The bytes land in the container's own writable layer (why that layer is throwaway is a storage subject of its own), and **nothing on the other side of the boundary is reading them**. The capture pipe is untouched, so three separate things are true at once: - the platform's log view shows an empty or near-empty stream for the workload; - the collector on the node ships nothing for it, because it ships what the runtime captured; - when the instance is replaced — a rollout, a rescheduling, a restart onto another node — the layer is discarded and the file goes with it. Teams usually meet those in that order, and meet the third one during the incident where the log was the only evidence. The file was readable the whole time, but only from inside that one running instance, and by the time anyone looks the instance is gone. ## Where a line can go, and what each choice costs | where the line is written | who can read it while the instance runs | survives replacement | |---|---|---| | the process's output streams | anyone with the platform's log view, and any collector on the node | yes, as the captured copy, until the node's rotation cap discards it | | a file inside the container | only someone who gets a view inside that specific instance | no | | a file on a path mounted from outside the container | whoever can read that path on the other side of the boundary | depends on what the path is backed by — a separate subject | The middle row is what this failure is made of. The problem is not that a file is a bad place to put bytes; it is that the file sits **outside the only channel anything is collecting**. ## What to do instead 1. Emit log lines on the output streams and let the platform own stamping, storage and shipping. This is why so many container-oriented services ship with no log-file setting at all — there is nothing useful for it to point at. 2. If a library can only write to a file, point its output at the process's own output stream; most accept a stream target rather than a path. Failing that, run a small forwarder alongside the process that reads the file and re-emits each line on the stream — and accept its cost: two copies of the data, another thing to supervise, and a window in which the forwarder is behind. 3. Do not try to fix it by choosing a conventional log directory. Nothing scans for one. There is no path the default capture is watching, and a name that looks standard buys nothing. ## The trap that survives the fix Writing to the stream is necessary, not sufficient. Two mechanisms still lose lines after the change: - **Buffering.** Many runtime libraries switch to block buffering when their output is a pipe rather than a terminal, so lines sit in the process's own memory in kilobyte-sized chunks instead of leaving immediately. A process killed mid-buffer loses everything unflushed — reliably including the last lines before a crash, which are the ones you wanted. Disable block buffering or flush per line for anything diagnostic. - **Back-pressure.** The pipe is finite. If whatever drains it stops draining, a write to the stream eventually blocks, and a process that logs on the request path stalls with it. It is rare, and worth recognising, because the symptom — a service that goes quiet and slow at the same moment — does not look like a logging problem. Neither is the file problem, but both hide behind the report "we moved to the stream and still lost the last minute".