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

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #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
• #5529 fix(rivetkit): treat empty actor input bytes as absent
• main

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

_{change xumpnzoy}

[claude]

Review

Overall this is a clean, well-documented addition (nice doc comments explaining the cgroup v2 vs /proc fallback and the sampling math). A few things worth addressing:

Correctness / design

actor.rs:88-97 - the new "resource monitor status" log in on_start calls crate::monitor::sampling_source() unconditionally, which calls detect_source() and does blocking reads of /sys/fs/cgroup/memory.current, cpu.stat, and potentially /proc/meminfo /proc/stat as a fallback - on every single actor start, regardless of whether RIVET_LOG_RESOURCE_USAGE is set.

This contradicts the module doc comment on monitor.rs ("Disabled by default so nothing is logged unless explicitly turned on"): with the monitor disabled (the default), every actor placement still does synchronous fs I/O on the async on_start hot path and adds a permanent extra log line to every actor's logs forever, just to report resource_monitor_enabled=false.

Since enabled()/sampling_source() reflect process-wide, static-for-the-life-of-the-instance state (not something that varies per actor), consider either:

• gating this whole block behind crate::monitor::enabled() so it's a true no-op when disabled, or
• logging it once at process startup next to monitor::spawn_resource_monitor() in main.rs instead of per actor placement.

Code quality

main.rs:120-131 - active_actor_ids() duplicates the identical CHILDREN.retain_async(|actor_id, _| { ids.push(...); true }) scan that's already inlined in spawn_signal_handler at main.rs:456-464 for the SIGTERM path. Now that the helper exists, spawn_signal_handler could call active_actor_ids() instead of keeping two copies of the same read-only scan.

Test coverage

monitor.rs adds several small parsing functions (read_meminfo_kb, read_proc_cpu_busy_usec, read_proc_cpu_count, read_cgroup_cpu_limit_cores, read_cgroup_memory_max) with no tests. This crate already has a convention for this: tests/inline/input.rs and tests/inline/boot_id.rs, wired via a '#[path]' shim per CLAUDE.md's guidance on keeping inline tests out of src/. As written, each parsing function directly calls std::fs::read_to_string(PATH) inline, so none of them can be unit tested without touching the real filesystem. Splitting "read the file" from "parse the string" (e.g. have read_meminfo_kb take the file contents as a &str parameter) would make the cgroup v2 / /proc parsing logic (the part most likely to have an off-by-one or wrong-field bug, e.g. /proc/stat field ordering or the cpu.max "max" sentinel) directly testable and consistent with the rest of the crate.

Minor

• USER_HZ is hardcoded to 100 with a comment asserting it holds "on Linux and gVisor." This is normally true but is technically a runtime/build constant (sysconf(_SC_CLK_TCK)); fine for the currently known deployment targets, just flagging as a hidden assumption if this ever needs to run somewhere else.

Nothing else stood out - the cgroup v2//proc fallback logic, the Skip-on-missed-tick handling, and the opt-in env var parsing all look correct, and the feature is safely disabled by default (aside from the point above).