Log Channels

A rented browser session writes text on a machine you do not own, and that text has to make a trip before anyone on your team reads it. The trip has two shapes, and choosing between them is a design decision with operating consequences rather than a preference. ## Pull: the artefact waits where it was made In a pull design the log is written to disk on the host that ran the browser and stays there until somebody asks for it by name. Aerokube's Selenoid, which declares itself unmaintained in its own README and is read here only as a legible open model of the mechanism, implements this directly. Started with the `-log-output-dir` flag it serves that directory, and writes a finished session's log into it whenever that session asked or the operator switched capture on for everyone: - `GET /logs/` serves a listing of the directory. - `GET /logs/?json` returns the same directory as a JSON array of file names. - `GET /logs/<name>.log` downloads one saved file. - `DELETE /logs/<name>.log` removes one, answering not-found if it has already gone. Pull is cheap to operate. There is no second system to run, no storage credential to hold, no key layout to design, and nothing to reconcile. Its weakness is structural: the only copy sits on one of the most disposable things in the estate. A host that is rebuilt, drained, scaled down or simply reclaimed takes the evidence with it, and nothing in the pull channel notices. ## Push: the artefact is sent onward as it is produced In a push design the server that made the artefact delivers it to storage you name. Selenoid models this too, in a build made with its `s3` build tag, which its own documentation says is absent by default. When a session ends and its file is finalised, a file-created event reaches an uploader, which computes an object key from the `-s3-key-pattern` flag and writes the file into the bucket named by `-s3-bucket-name` at `-s3-endpoint`. The glob flags `-s3-include-files` and `-s3-exclude-files` decide which artefacts make the trip, matched against the file's base name, so a suite can ship logs and leave heavier artefacts behind. Push costs you the things pull did not: storage to own, a credential to hold, and a key layout to design, because the key layout is what the bucket is later navigated by. ## The trap: a push is not automatically a second copy This is where confident designs go wrong. In Selenoid the uploader removes the local file after a successful upload unless it was started with `-s3-keep-files`. The push therefore *moves* the artefact by default rather than copying it, and the moment it succeeds the `/logs/` listing stops answering for that file. A team that wires push on top of pull without that flag and assumes both surfaces still work has one surface, not two, and discovers it during an incident. The same reasoning applies to any hosted service: establish whether a delivery mechanism duplicates the artefact or relocates it, because "we have it in both places" is an assumption, not an observation. ## Choosing between them | what you are weighing | argues for pull | argues for push | |---|---|---| | how often a log is actually read | rarely, on a real failure | routinely, by tooling | | how long the producing host lives | long-lived, stable hosts | short-lived, reclaimed hosts | | who must be able to read it | one engineer, on demand | a pipeline, a search index, an auditor | | what you are willing to operate | nothing extra | storage, a credential, a key layout | For most suites the answer is push, because pulling ties evidence to the lifetime of infrastructure you do not control, and that lifetime is the one variable a tenant cannot set. The honest counter-argument is that push obliges you to run and own the destination, so a suite that reads a log only when a person is already looking at a failing build can legitimately stay on pull. ## Working it through on a real suite Take a port-logistics container-tracking dashboard whose end-to-end suite runs on rented browsers each night. Its failures cluster in the shipment-status view, and triage happens the following morning. 1. Decide who reads the artefact. If the answer is "a person, the next morning", pull is survivable only while the producing host is still there the next morning, which on elastic capacity it may not be. 2. Decide what the artefact is worth once it is stale. If nobody reads a passing run's log, push everything but expire aggressively at the destination, which is a decision you can make only once the destination is yours. 3. Decide the key layout before the first upload, not after. Renaming a bucket's worth of objects later is work; getting the prefix right on the first day is a line of configuration. ## What to say in an interview Name the two shapes, say what each obliges you to run, and then name the trap: verify whether the delivery mechanism leaves a local copy behind. Candidates who stop at "we save the logs somewhere" have not made a decision; candidates who say "we push, we keep the local copy during the migration, and we verified the key resolves before we trusted it" have.