Which parts of a Go service's log output should a platform owner mandate fleet-wide, and which stay a team's call?

## Draw the line where the platform cannot recover The useful test for a mandate is not "is this a good idea" but "if a team gets this wrong, can the platform fix it afterwards without touching their code?" Almost everything about logging passes that test — a noisy service can be filtered, a badly named field can be aliased in a query, a missing debug record can be added next sprint. Three things do not: 1. **Where the records go.** If a service writes to a file inside its container, the platform never sees the records at all. There is no recovery; the data was destroyed with the container. 2. **What the records look like on the wire.** If every service invents its own format, the collector needs per-service parsing and cross-service correlation becomes manual work. That cost lands entirely on the platform. 3. **Whether the sink is buffered.** Buffered records that never flushed do not exist. The platform cannot retrieve what was never written, and the records lost are always the newest — the ones describing the failure. Those three are the mandate. They are cheap to comply with, mechanically checkable, and each protects a property the platform is accountable for. ## What stays with the team Everything about *content*. Which events are worth a record; what level each one gets; whether per-request logging is sampled at 1% or off entirely; which domain attributes a record carries; whether they build one logger or several; how their handler is implemented. A platform that legislates message wording is spending authority it will need later, and it makes the platform team the bottleneck on every service's debuggability. There is a shared middle: a small set of common field names — service, version, request identifier, level, timestamp — because those are what dashboards and correlation queries join on. Standardise the join keys; leave the rest of the record alone. ## The buffering argument, concretely A team profiles a hot path, sees log writes costing a few percent of CPU, and asks to put a buffer in front of the sink. This is the case the posture exists for, and "no" without reasoning is the wrong answer. What I weigh: - **What buffering actually saves.** It removes system calls, not the formatting and serialisation of the record — and formatting is usually the larger half. The measured saving is often smaller than the profile suggested. - **What it costs.** Every record in the buffer exists only in the process. `os.Exit`, `log.Fatal`, an uncaught SIGTERM, SIGKILL and fatal runtime errors all discard it. The lost records are the newest ones, which is the tail on-call reads first. It also delays visibility, so a stuck service looks silent. - **The better trade.** If logging is genuinely expensive, the cause is volume. Sampling per-request records, or moving them below the enabled level, removes the formatting cost *and* the syscall, and takes nothing away from the crash tail. I offer that first, because it is a bigger win and has no downside at exit. If they still need buffering — a batch job whose output volume is the actual workload, whose final status is recorded elsewhere — I grant it as an exemption with conditions attached: flush on every record at error level and above, a periodic flush that bounds visibility lag, a SIGTERM handler that flushes on the way out, `log.Fatal` banned in that binary, and a subprocess test in their pipeline that runs the real failure path in a child and asserts the last record survived. The exemption is reviewable, and the test is what keeps it honest after the person who requested it moves on. ## Where I can be overruled, and by what Two constraints legitimately beat the default. **Cost**: if log volume dominates the platform bill, something has to give — but the answer is fewer records, not later ones, and I should be able to show that with data rather than asserting it. **A workload whose economics really are different**: a high-throughput pipeline stage where the log stream is the product. In both cases the argument that wins is a measurement, and I should say up front what measurement would change my mind. A posture that cannot be argued with is a posture people route around. ## Enforcement is a default, not a document The part teams get wrong is the part that requires them to remember something. So the posture ships as code: a shared constructor that returns a logger writing unbuffered to the standard stream in the fleet's format, wired into the service template so a new service is compliant before anyone thinks about it. Add one check in the shared pipeline for the obvious violations, and a platform-side alert when a service stops producing records at all — that catches the buffered sink that quietly stopped flushing. A rule in a wiki decays at the rate the team turns over. A default decays at the rate someone deliberately opts out of it, which is far slower and, when it happens, visible. ## The shape of a good answer Name the small mandate and justify it by what the platform cannot repair. Hand back everything else explicitly, so it is clear the mandate is small on purpose. Show that you would meet the buffering request with a measurement and a counter-offer rather than a refusal, and that you would attach conditions rather than trust. Finish with enforcement by default, because a posture nobody can bypass by accident is the only one that holds across dozens of services.