Skip to content

feat(system): add OS data via os_mon to the System page - #63

Merged
thiagoesteves merged 4 commits into
mainfrom
thiagoesteves/system-os-mon-data
Jul 17, 2026
Merged

feat(system): add OS data via os_mon to the System page#63
thiagoesteves merged 4 commits into
mainfrom
thiagoesteves/system-os-mon-data

Conversation

@thiagoesteves

Copy link
Copy Markdown
Owner

What

Adds an "Operating System" section to the System pillar, closing the OS-data gap with the observer GUI's load charts and LiveDashboard's OS Data page:

  • ObserverWeb.SystemInfo.os_data/1 collects load averages (1m/5m/15m), per-CPU utilization, OS memory and per-disk usage through the os_mon probes (:cpu_sup, :memsup, :disksup) over the existing Rpc adapter, so it works against any node in the cluster.
  • The System page renders the new section with the same usage-bar treatment as Limits; when os_mon is not running on the selected service it shows a hint to add :os_mon to extra_applications instead of failing.
  • Each probe degrades individually (nil/empty) since support varies per platform (e.g. per-CPU utilization availability differs across OSes).

Why

Part of the roadmap derived from comparing ObserverWeb against OTP observer, observer_cli and Phoenix LiveDashboard: OS-level data was one of the few remaining inspection gaps.

Notes

  • mix.exs adds :os_mon to extra_applications for dev/test only (Elixir prunes undeclared OTP apps from the code path); host applications opt in via their own extra_applications, which is what the page hint documents.

Risk assessment

  • Impact: new read-only section on the System page; no behavior change when os_mon is absent beyond the hint text.
  • Blast radius: SystemInfo and the System page only; host applications unaffected by the dev/test-only extra_applications change.
  • Regression risk: low - defensive matching on every probe, all RPCs behind the existing adapter; suite green (403 tests, 96.1% coverage), credo/sobelow/dialyzer/format clean.
  • Rollback plan: revert the commit; no config or data migration involved.

Checklist

  • mix test green (403 tests)
  • mix coveralls 96.1% (threshold 95%)
  • mix credo --strict, mix sobelow, mix dialyzer, mix format --check-formatted clean
  • Small focused diff, no leftover debug output

🤖 Generated with Claude Code

@thiagoesteves

Copy link
Copy Markdown
Owner Author

The failed Test job is the pre-existing tracing flakiness (Run Trace for mix Elixir.Enum... - trace session self-aborts before the STOP click). Root cause is a display-session feedback loop fixed in #68; rerunning the job in the meantime.

Add ObserverWeb.SystemInfo.os_data/1, collecting load averages, per-CPU
utilization, OS memory and disk usage through the os_mon probes
(:cpu_sup, :memsup, :disksup) over RPC, and render it as a new
"Operating System" section on the System page. When os_mon is not
running on the selected service the page hints at adding :os_mon to
extra_applications instead of failing.

Each probe degrades individually (nil or empty list) since availability
varies per platform, mirroring how the rest of SystemInfo tolerates
unsupported system_info items.

Risk assessment:
- Impact: new read-only section on the System page; no behavior change
  when os_mon is absent beyond the hint text.
- Blast radius: SystemInfo and the System page only; mix.exs adds
  :os_mon to extra_applications for dev/test envs exclusively, so host
  applications are unaffected.
- Regression risk: low - all probes go through the existing Rpc
  adapter with defensive matching; full suite plus new unit/page tests
  are green (403 tests, 96.1% coverage).
- Rollback plan: revert this commit; no config or data migration
  involved.
@thiagoesteves
thiagoesteves force-pushed the thiagoesteves/system-os-mon-data branch from df4844a to d1f3ac0 Compare July 17, 2026 17:47
Add a Refresh interval selector (Paused/2s/5s/10s, default 5s) to the
System page using the same generation-counted tick chain as the
Network and Logs pillars: changing any control or pressing REFRESH
restarts the chain, stale in-flight ticks are ignored, and Paused
keeps the page on-demand only. The nodedown fallback now restarts the
chain as well, so the page recovers onto the local node and keeps
refreshing.

Periodic sampling also makes the os_mon per-CPU utilization more
meaningful, since cpu_sup reports utilization since the previous call.

Risk assessment:
- Impact: System page gains periodic refresh; manual REFRESH behavior
  unchanged apart from also resetting the timer cadence.
- Blast radius: System page only; the tick pattern is reused as-is.
- Regression risk: low - message-based tests cover the interval firing
  and the stale-generation guard; suite green (430 tests, 96.0%
  coverage), credo/dialyzer/format clean.
- Rollback plan: revert the commit.
@thiagoesteves

Copy link
Copy Markdown
Owner Author

Added auto refresh to the System page after the rebase: a Refresh interval selector (Paused/2s/5s/10s, default 5s) driven by the same generation-counted tick chain the Network and Logs pillars use - changing any control or pressing REFRESH restarts the chain, stale ticks are dropped, Paused keeps it on-demand. Periodic sampling also makes the per-CPU utilization numbers more meaningful since cpu_sup reports utilization since the previous call.

@thiagoesteves thiagoesteves moved this to In Progress in Observer Web Jul 17, 2026
The :os_mon requirement was only discoverable through the in-page hint
and the SystemInfo moduledoc. Add an "OS data on the System page
(opt-in)" section to the installation guide - alongside the other
opt-ins - explaining what the section shows, why Observer Web does not
start os_mon itself (OS polling processes, system alarms) and the
extra_applications snippet to enable it. Mention OS data in the README
feature line as well.

Risk assessment:
- Impact: documentation only.
- Blast radius: installation guide and README.
- Regression risk: none - mix docs builds cleanly.
- Rollback plan: revert the commit.
@thiagoesteves

Copy link
Copy Markdown
Owner Author

Documented the opt-in: new "OS data on the System page (opt-in)" section in the installation guide (what the section shows, why Observer Web does not start os_mon itself, and the extra_applications snippet), plus a mention in the README feature line. Previously the requirement was only discoverable through the in-page hint.

The Observer.Web.Page moduledoc referenced
Phoenix.LiveView.handle_params/3 as a function; it is a callback, so
ExDoc warned about an undefined reference. Use the c: prefix. mix docs
now builds warning-free.

Risk assessment:
- Impact: documentation only.
- Blast radius: one moduledoc line.
- Regression risk: none.
- Rollback plan: revert the commit.
@thiagoesteves
thiagoesteves merged commit 1770869 into main Jul 17, 2026
5 of 6 checks passed
@github-project-automation github-project-automation Bot moved this from In Progress to Done in Observer Web Jul 17, 2026
@thiagoesteves
thiagoesteves deleted the thiagoesteves/system-os-mon-data branch July 17, 2026 18:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant