Implement web-based kernel observatory

[jserv]

A browser-based dashboard that exposes LKL's internal kernel state in real time while the guest executes. This is not a CLI-to-GUI wrapper -- it reveals runtime details that are invisible in normal Linux operation because they occur inside kernel code paths that userspace cannot observe without instrumentation. The web UI makes kbox's unique architectural property (the kernel runs in the same address space as the supervisor, with all data structures directly readable) accessible to anyone with a browser, not just GDB experts.

Motivation and Positioning

kbox is not "another Linux emulator" or "another sandbox." Emulators (QEMU, Bochs) and sandboxes (gVisor, Firecracker) optimize for isolation and performance. kbox optimizes for transparency: it boots a real Linux kernel as a library specifically so that the kernel's internal machinery -- scheduler decisions, page cache behavior, interrupt routing, VFS traversals, memory allocator state -- can be observed, measured, and understood by students, developers, and anyone curious about how Linux actually works.

The GDB helpers already expose this data to expert users. The web observatory democratizes it. A student who has never used GDB can watch context switches accumulate in real time, see which syscall paths trigger page faults, observe the EEVDF scheduler picking the next task by deadline, and trace a write() from the seccomp notification through VFS down to the block layer -- all rendered as live charts and event streams in a browser tab.

Traditional approaches to kernel observation are impractical for this use case:

• ftrace/perf require root or CAP_SYS_ADMIN and produce text logs that must be post-processed.
• /proc and /sys expose counters but not event-level detail (you see the count of context switches, not when each one happened or why).
• KGDB requires a serial connection and halts the kernel at breakpoints.
• printk-based tracing requires kernel recompilation and produces unstructured text.

LKL eliminates all of these barriers. The kernel runs in-process, so its /proc and /sys filesystems are accessible to the supervisor via standard kbox_lkl_openat/kbox_lkl_read calls -- no privilege escalation, no ptrace, no external tools. The supervisor can sample kernel state at arbitrary frequency via /proc parsing, correlate it with seccomp dispatch events, and stream it to a browser via SSE (Server-Sent Events) -- all from an unprivileged process.

Design decision -- self-contained telemetry, not infrastructure integration: gVisor exposes Prometheus endpoints and could integrate with OpenTelemetry for distributed tracing. kbox deliberately rejects this approach. Prometheus/OTel add external dependencies (scraping infrastructure, collector daemons, time-series databases), contradict the zero-dependency philosophy, and solve a problem kbox does not have (multi-service distributed tracing across network boundaries). kbox is a single-process, local-only tool. The embedded HTTP server + SSE + browser dashboard is the entire observability stack. No Prometheus, no Grafana, no Jaeger, no npm. A standard browser is the only consumer. If users need to export data for offline analysis, --trace-format=json to stdout or the dashboard's CSV/JSON export covers that. The --trace-format=json schema is intentionally simple but does not preclude downstream ingestion by OTel collectors or jq pipelines -- format compatibility is free, infrastructure dependency is not. This is a conscious trade-off: less enterprise integration surface in exchange for zero operational complexity.