feat(container-runner): setup instance memory and cpu usage logger

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5557 docs(container-runner): sync deploy docs with runner source
• #5556 fix(container-runner): read cgroup v1 memory usage under gvi …
• #5548 feat(container-runner): log version and git sha at actor sta …
• #5549 feat(container-runner): setup instance memory and cpu usage … 👈
• #5546 fix(rivetkit): keep actor event loop alive through shutdown …
• #5539 feat(container-runner): report actors as crashed on unexpect …
• #5536 feat(container-runner): log unexpected platform SIGTERM as a …
• #5530 fix(rivetkit-core): cancel driver alarm before sqlite teardo …
• #5531 feat(container-runner): keep instance warm instead of self-e …
• #5533 chore(container-runner): default stop grace to 10s
• #5528 fix(rivetkit): log and surface actor startup failures
• #5558 fix(sdks): drop rivet-util metrics dep from protocol crates …
• main

Get stack: forklift get 5549
Push local edits: forklift submit
Merge when ready: forklift merge 5549

_{change xumpnzoy}

[claude]

Review

Solid, well-scoped addition: an opt-in (RIVET_LOG_RESOURCE_USAGE), disabled-by-default resource sampler with a sensible cgroup-v2 to /proc fallback for gVisor sandboxes. I read through monitor.rs and the wiring in actor.rs/main.rs. No security or correctness bugs found in the sampling/parsing logic (cumulative-counter deltas, /proc/stat field indexing, div-by-zero guards, and the MissedTickBehavior::Skip handling all look correct). A few things worth considering before merge:

Test coverage (moderate).
monitor.rs adds several pure parsing functions (read_cgroup_cpu_limit_cores, read_proc_cpu_busy_usec, read_proc_cpu_count, bytes_to_mib, etc.) but ships with zero tests. This repo already has precedent for exactly this kind of unit test: container-runner/tests/inline/boot_id.rs tests the pure base64url_nopad helper in main.rs the same way. As written, though, the parsing functions read directly from hardcoded path constants (CPU_STAT, PROC_STAT, ...), so they are not unit-testable without a refactor to accept the file content as a parameter (e.g. fn parse_cpu_max(raw: &str) -> Option<f64>) with the constants only used at the call site. Worth doing given how easy it would be to get the /proc/stat field offsets or the cpu.max/memory.max unlimited sentinel handling wrong silently.

Minor: sampling_source() cost on every actor start (low).
actor.rs's new on_start log unconditionally calls crate::monitor::sampling_source(), which runs detect_source() (up to 4 blocking file reads) even when the monitor is disabled (resource_monitor_enabled = false, the default) and even on the idempotent duplicate-start retry path (before the existing-child check). The reads are cheap pseudo-file reads, so this is not a real perf problem, but it is unconditional work done for a status log that is mostly informative when the flag is off. Consider short-circuiting: only call sampling_source() when enabled() is true.

Log volume with multiple actors per instance (low, already acknowledged).
Per main.rs's doc comment, one instance can host multiple concurrent actors. The monitor's counters are instance-wide, so with N actors running it logs the identical "instance resource usage" line N times every 500ms. The code comment already calls this out, so it is a conscious tradeoff, just flagging it since it could meaningfully multiply log volume when the flag is enabled on a densely-packed instance.

Nit: Option<f64> fields via ? (very low).
mem_used_mib = ?mem_used_mib etc. log as Some(123.45) / None under the current plain-text formatter. If this ever moves to JSON-formatted log output for aggregation, these fields will serialize as strings like "Some(123.45)" rather than numbers/null, which is awkward to query. Not a problem today, just worth being aware of.

Nothing here blocks merging. The feature is opt-in, defaults to off, and the core sampling logic is sound.