Skip to content

feat(metrics): chart host application Telemetry.Metrics definitions - #65

Open
thiagoesteves wants to merge 1 commit into
mainfrom
thiagoesteves/host-telemetry-metrics
Open

feat(metrics): chart host application Telemetry.Metrics definitions#65
thiagoesteves wants to merge 1 commit into
mainfrom
thiagoesteves/host-telemetry-metrics

Conversation

@thiagoesteves

Copy link
Copy Markdown
Owner

What

Closes the main capability gap with Phoenix LiveDashboard: the Metrics page can now chart the host application's own Telemetry.Metrics definitions, not just the built-in VM/Phoenix series.

  • config :observer_web, telemetry_metrics: [...] accepts a list of Telemetry.Metrics structs, or {module, function, args} for runtime-resolved definitions (e.g. reusing the list your other reporters consume).
  • Definitions are appended to the built-in list consumed by ObserverWeb.Telemetry.Consumer, so custom series flow through the existing storage, retention, and Metric Hub (:local/:observer/:broadcast) modes unchanged - including history that survives app restarts in hub mode, which LiveDashboard cannot do.
  • A new generic Custom chart component renders any metric key no dedicated component claims, labeling the series with its unit when available.
  • Invalid entries or config shapes are dropped with a warning instead of breaking telemetry startup.
  • Documented in the installation guide (Host application metrics (opt-in)) and the Observer.Web.Telemetry moduledoc.

Why

Part of the roadmap derived from comparing ObserverWeb against OTP observer, observer_cli and Phoenix LiveDashboard: rendering host-app telemetry was the main reason teams still run LiveDashboard alongside ObserverWeb.

Risk assessment

  • Impact: opt-in; without the config, the metrics list and page rendering are unchanged (the generic chart only claims keys that previously rendered nothing).
  • Blast radius: Observer.Web.Telemetry metrics list, Metrics page render loop, one new component; storage/consumer untouched.
  • Regression risk: low - defensive config validation; suite green (403 tests, 96.0% coverage), credo/sobelow/dialyzer/format clean.
  • Rollback plan: revert the commit; adopters just lose the extra charts.

Checklist

  • mix test green (403 tests)
  • mix coveralls 96.0% (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

Allow host applications to chart their own Telemetry.Metrics on the
Metrics page via config :observer_web, telemetry_metrics: [...] (or a
{module, function, args} tuple resolved at startup). The definitions
are appended to the built-in VM/Phoenix list consumed by
ObserverWeb.Telemetry.Consumer, so custom series flow through the
existing storage, retention and Metric Hub modes unchanged.

A new generic Custom chart component renders any metric key that no
dedicated component claims, showing the series unit when available.
Invalid config entries are dropped with a warning instead of breaking
telemetry startup.

Risk assessment:
- Impact: opt-in feature; without the new config the metrics list and
  page rendering are unchanged (the Custom component only claims keys
  no built-in chart renders, which previously rendered nothing).
- Blast radius: Observer.Web.Telemetry metrics list, Metrics page
  render loop, new component; storage/consumer untouched.
- Regression risk: low - config is validated defensively and the suite
  is green (403 tests, 96.0% coverage).
- Rollback plan: revert the commit; hosts that adopted the config just
  lose the extra charts.
@thiagoesteves
thiagoesteves force-pushed the thiagoesteves/host-telemetry-metrics branch from 59479a2 to fcd7f83 Compare July 17, 2026 18:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant