Enhance Proxy UI with instance detail pages, metric units, device summary, and topology view

[zhy1658858023]

Background

The current UI/proxy_ui dashboard already provides a useful observability overview for Proxy health, Instance liveness, resource snapshots, KDN topology payloads, Scheduler registration, short resource trend charts, and raw diagnostics.

The next step is to make the Proxy UI more useful for debugging CacheRoute runtime behavior and per-Instance bottlenecks. The dashboard should let users drill down from the overview into one specific Instance, understand the units and meaning of resource trend charts, see concise hardware identity on each Instance card, and visualize the automatically discovered system topology.

Requested improvements

1. Make each Instance card clickable and add an Instance detail view

Each Instance card in the Proxy UI should be clickable. Clicking a card should navigate to, open, or switch into an Instance-level detail view.

The detail view should make it easier to inspect per-Instance information, including at least:

• Instance identity: instance_id, host, port, endpoints, tags, weight, metadata.
• Liveness state: alive / stale / unknown, registered_at, last_seen_at, TTL-derived age.
• Current load: inflight, qps, heartbeat GPU utilization if available.
• Resource snapshot: CPU, memory, GPU utilization, GPU memory, network RX/TX, admission state, report freshness.
• Hardware summary: CPU model, GPU model/count, NIC model/count when reported by the resource agent.
• Raw per-Instance JSON for debugging.

Suggested UI behavior:

• Keep the overview page as the default landing page.
• Clicking an Instance card can either open a dedicated route such as /#/instances/<instance_id> or switch to an in-page detail panel/modal.
• Provide a clear way to return to the overview.
• If an Instance is stale, keep the page readable and explicitly mark data as stale rather than hiding it.

Potential follow-up information to add later:

• Per-Instance queue/load history if the backend exposes it.
• Per-Instance request traces or recent routing decisions.
• Per-Instance KDN links and KVCache-related diagnostics.

2. Improve Resource Trend chart semantics and axis labels

The current Resource Trend section is visually useful but too coarse. It only shows curves and does not clearly communicate what each axis means or which units are used.

Please make chart semantics explicit:

• X-axis should represent time or sample index. Prefer wall-clock time if practical; otherwise label it clearly as recent polling samples.
• Y-axis labels should include units:
  • CPU average: %
  • memory used ratio: %
  • GPU average: %
  • network RX/TX: Mbps
  • alive/stale Instance counts: count
• Add compact chart legends where multiple series are shown, especially alive/stale and RX/TX.
• Consider showing a tooltip or small caption explaining that the current history is an in-browser rolling buffer and is not persisted by the backend.
• If metrics are missing, show a clear empty-state or degraded-state hint instead of only rendering gaps.

Acceptance expectation: a user looking at the trend row should immediately know the unit and meaning of every curve.

3. Add concise hardware/device summary to each Instance card

In the Instance card badge row near last seen and resource freshness, add a short device summary when available.

Desired compact fields:

• CPU model, for example CPU: EPYC 7xxx or CPU: Xeon ...
• GPU model and count, for example GPU: 8×A800 or GPU: 1×RTX 4090
• NIC model and count, for example NIC: 2×ConnectX-6

If detailed model names are too long, use a shortened display string and expose full details in the Instance detail view or raw JSON.

Fallback behavior:

• If hardware metadata is missing, show device: unknown or omit the badge depending on layout constraints.
• Do not confuse missing data with zero devices.

Backend note: this may require extending the resource snapshot payload reported by the Resource Agent and surfaced through Proxy control-plane endpoints. If the data is already present inside raw_resource, normalize it for UI consumption.

4. Split the Resource Trend row and add an automatic topology diagram

The current Resource Trend panel occupies a full row. Please split this area into two columns:

• Left column: Resource Trend charts.
• Right column: automatically discovered system topology diagram.

The topology diagram should include at least:

• Scheduler node.
• Current Proxy node.
• Connected Instance nodes.
• Instance liveness state: alive vs stale.
• Optional degraded/unavailable markers when Scheduler registration or topology data is unavailable.

Suggested visual model:

Scheduler
   |
 Proxy (current)
  /   |   \
InstA InstB InstC
alive stale alive

Design expectations:

• The topology should be generated from the same data already used by the UI: Scheduler proxy registration, Proxy status, and Instance list.
• Alive and stale Instances should be visually distinct.
• The current Proxy should be clearly labeled as the local/observed Proxy.
• If Scheduler information is unavailable, still render Proxy → Instance topology and mark Scheduler as unavailable.
• Keep the diagram lightweight and dependency-free unless a strong reason exists to introduce a graph library.

Acceptance criteria

• Instance cards are clickable.
• A user can inspect a single Instance in a dedicated detail view or equivalent in-page panel.
• Instance detail view includes identity, liveness, load, resource, hardware summary, and raw JSON sections.
• Resource Trend charts clearly label x-axis meaning and y-axis units.
• Multi-series charts include labels or legends.
• Missing metrics show an understandable degraded/empty state.
• Instance cards show concise CPU/GPU/NIC hardware summaries when data is available.
• Hardware data gracefully degrades when unavailable.
• Resource Trend section is reorganized into a two-column layout.
• The right column shows an automatically discovered Scheduler → Proxy → Instance topology diagram.
• Alive and stale Instance nodes are visually distinct.
• Scheduler unavailable state does not break the topology view.
• Existing Proxy UI functionality continues to work: refresh, pause/resume, interval selection, filters, search, sorting, raw JSON, copy buttons, and theme toggle.

Suggested implementation areas

Likely frontend files:

• UI/proxy_ui/static/index.html
• UI/proxy_ui/static/app.js
• UI/proxy_ui/static/style.css

Likely backend / API areas if additional data is needed:

• UI/proxy_ui/proxy_ui_server.py
• proxy/resource/p_control_plane.py
• Resource Agent snapshot payload generation if CPU/GPU/NIC model data is not currently normalized.

Notes

This issue is intentionally scoped as a UI/observability improvement. It should not change Proxy scheduling behavior, Instance selection, KDN behavior, KVCache injection, or request forwarding semantics.