Repository navigation
feat(minvmd): export the VM host daemon's spans and carry telemetry into the guest (4/7, spec 25) - #1996
Conversation
|
Warning Review limit reached
This review includes 77 billable files and costs up to $19.25.
Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing. Or wait 59 minutes for your next included review. View limit details
Comment |
0b473cb to
d405d53
Compare
544de75 to
19e55bd
Compare
|
Reviewed: 1 finding, none blocking at Address the comments on the diff. Clobber: none: |
19e55bd to
a61e33d
Compare
d405d53 to
e576df1
Compare
|
@coderabbitai review |
|
a61e33d to
8e27af5
Compare
e576df1 to
574fbb2
Compare
There was a problem hiding this comment.
Review of 4/7 at 574fbb2, against its stack parent #1995 and spec 25 at eed80b0.
Summary:
- The minvmd span structure is good. The start phase ends at READY, supervision runs under its own linked root, and long-lived tasks use
vm_task, so they do not hold the start phase open. TEL-032 and TEL-035 have tests here. - The egress gate,
net.rsandrun.rschanges add only spans. They do not change gate decisions. - Must fix: this PR puts the OTLP endpoint on the guest boot line, and its tests assert that. TEL-033 forbids it, and #2039 removes it. Remove the endpoint arm here, or merge 4/7 to 7/7 as one unit.
- Should fix: the full boot line is logged at info level and exported. Update the module doc.
- Minor:
minvmd bootdoes not record the error status onvm.boot. The spawn scan test has gaps.
|
Review pass (read-only, head Must fix — +1 to @norrietaylor at Also open, all valid:
|
8e27af5 to
58e33fd
Compare
574fbb2 to
92e4b98
Compare
|
Verified at 92e4b98: the endpoint arm,
|
92e4b98 to
e6757af
Compare
58e33fd to
8589c71
Compare
|
@mitodrummer both of your re-approve items are in round 4 (e6757af):
|
e6757af to
34b99e7
Compare
8589c71 to
2db9bfa
Compare
5618f2d to
c09ef70
Compare
244d63d to
b76a52b
Compare
b76a52b to
f380e8f
Compare
c09ef70 to
eca58d5
Compare
eca58d5 to
8c61be2
Compare
02261d3 to
6ed880a
Compare
8c61be2 to
0b57a99
Compare
6ed880a to
dce2819
Compare
0b57a99 to
fe44427
Compare
Three small test-only changes that the telemetry series relies on, kept separate so they can land on their own: - the walked-publication probe waits for the publication to settle - bep_stub tolerates EPIPE when the client hangs up first - the fresh-streak test waits for the streak counter to advance No product code changes.
The telemetry core for every minimal process (spec 25 TEL-001 to TEL-020, principles 1, 2, 7 and 8). Off unless MINIMAL_TELEMETRY=1; when off nothing starts: no thread, no exporter, no file. When on: - spans and logs leave over OTLP/HTTP (opentelemetry 0.33) to the endpoint the MINIMAL_OTEL_EXPORTER_OTLP_* variables name, base or per signal, and the plain OTEL_* ones only when no MINIMAL_ endpoint is set; per-signal endpoints and `*_EXPORTER=none` are honoured; - DO_NOT_TRACK (any non-empty value) and OTEL_SDK_DISABLED=true always win; - the exporter's own HTTP stack and the SDK never produce telemetry, errors never reach a console, and the exit flush is bounded (200 ms in the CLI); - every finished span and log record is appended synchronously to an OTLP/JSON spool under <state>/telemetry/spool (0700/0600, 4 MiB segments, pruned to 50 MiB / 7 days, torn lines contained), so a crash or SIGKILL keeps what was already written; - the endpoint and the switches have one recognizer each (url::Url, a byte-exact flag grammar), ambient OTEL_EXPORTER_OTLP_HEADERS are refused when the endpoint came from a MINIMAL_ variable, and secrets never appear in the init summary or the logs. The switch decision and the spool prune plan are pure functions with Kani harnesses beside their unit tests.
Wire mlog's telemetry into the CLI and the daemon (spec 25 TEL-021 to TEL-029). - The CLI mints or adopts a TRACEPARENT, exports its `cmd` span, and ends and flushes it before any hand-off; the daemon adopts the context from the channel environment and records `rpc` and `exec` spans under it. - `min session exec` / `run` relays ssh rather than exec()ing it (#1881), so every way out of a command is an exit or signal hand-off and the `cmd` span covers the command; `run` finishes the hand-off once the span has ended and been flushed. - Work the daemon does for a request stays in that request's trace: actor mailboxes carry the sender's span, the blocking pool, spawned tasks (`traced::spawn`, with a guard test against bare spawns), package fetches, orchestrator and check tasks, checkouts (remotes scrubbed), git upload and receive, and the periodic cache clean in its own root. - Boxes receive only the exec span's TRACEPARENT (never headers, baggage or OTEL_* variables), and only when that span is recorded; a nested `min` inside a box, a task run and the in-box helper socket forward it, so daemon-side work for them joins the outer trace. - `min net forward` carries the context on the direct-tcpip open; attach adopts it; SIGHUP and exit paths flush within the shutdown bound.
…nto the guest minvmd exports a bounded root per command with `net.switch.start`, `vm.boot`, `vm.stop` and `guest.shutdown` as children, in the CLI's trace (spec 25 TEL-032 to TEL-036). The host decides the telemetry switches and writes them onto the guest's boot line with one byte-exact writer under a fixed budget: the opt-in, the spool and filter settings, the exporter switches and TRACEPARENT, never an endpoint, headers, resource attributes or baggage (TEL-033), because everything in the guest can read the boot line as /proc/cmdline. With no endpoint the guest exports nothing here: both signals are `none` and its records stay in its own spool until the VM channel carries them to the host. The whole set is forwarded or dropped, so a guest never boots with a partial configuration, and the logged boot line names the telemetry tokens by key only. The guest daemon builds its OTLP client without platform CA roots (an http:// collector needs none) and flushes before it powers off. RUST_LOG filters the console per layer, so it never gates export. A failed `minvmd boot` marks `vm.boot` with an error status, as `run` does. The boot line's alphabet, budget and all-or-none rules are proven with Kani.
fe44427 to
440cecf
Compare
dce2819 to
4ff7dbe
Compare
feat(minvmd): export the VM host daemon's spans and carry telemetry into the guest (4/7, spec 25)
Stack: spec #1988 → test hardening → mlog export → CLI+daemon → this → diag → requirement tests → guest telemetry over vsock (7/7). Base:
otel/3-cli-daemon.12 files, +2445/−157:
crates/minvmd/src/telemetry.rs— minvmd joins the request trace from the CLI/daemon and exports its own spans (boot, stop, remount, egress gate) under the same opt-in; the Rust-log bridge warns once, never panics (TEL-040..044).crates/minvmd/src/vm.rs— the guest boot line: telemetry settings reach the guest daemon only through an allowlist ofMINIMAL_*keys with a byte budget; a long or non-ASCII filter cannot kill the boot; no endpoint ever crosses: the guest's exporters are forced tonone, and its records reach the host only over vsock (feat(otel): guest telemetry rides the VM channel (7/7, spec 25) #2039). With telemetry off the boot line is byte-identical to a build without this stack.egress_gate.rs,cmd/run.rs,main.rs: spans around the paths that already existed; the newStatus { json, row }arm returns throughdispatch'sResult<i32>like the rest.LangSec before/after in the lab: the secret-on-the-boot-line, re-emitted trace flags and long/non-ASCII filter cases each REPRODUCED on the unpatched tree and PASS here. Lab evidence (job 00244, four distros): 715/715b/715c/715e/715f (boot/stop and the guest daemon in one trace), 715g/715h (allowlist, bytes, budget), 749b (clean stop and remount); minvmd traces 100 % joined.
Not covered: macOS (minvmd on arm64) is untested in the lab, which runs Linux hosts only; the stack's CI macOS job is the first run there.
Plan: #1992 (the spec's plan comment). Plan tasks in this PR: T12 minvmd root, boot and stop spans · T13 guest boot line allowlist (and the guest side of T6's clean stop).
🤖 Generated with Claude Code