Skip to content

feat(metrics): add pod CPU/memory usage history with charts drawer - #77

Merged
wellCh4n merged 1 commit into
mainfrom
feat/pod-metrics-history
Jul 28, 2026
Merged

feat(metrics): add pod CPU/memory usage history with charts drawer#77
wellCh4n merged 1 commit into
mainfrom
feat/pod-metrics-history

Conversation

@wellCh4n

Copy link
Copy Markdown
Owner

metrics-server keeps no history, so the status page could only show a point-in-time reading. This adds an in-process sampler that turns those readings into 24 hours of per-pod usage curves.

Backend:

  • PodMetricSampleJob sweeps every environment on a 30s tick, fanning out across virtual threads so one unreachable cluster cannot delay the others. Each environment costs two cluster-wide API calls (pod list + top) regardless of application count; pods are attributed to applications via the oops.app.name label, so the sweep never touches the database.
  • InMemoryPodMetricHistoryStore keeps each pod series in a fixed-size ring of primitive arrays (20 bytes/sample, ~57KB per pod for 24h) behind the PodMetricHistoryStore port. Series survive pod deletion until their samples age out, so charts drawn right after a rollout still show the replaced pods. A max-series cap guards the heap.
  • GET .../applications/{name}/metrics/history?env=&range=&agg= serves chart-ready series. Buckets are epoch-aligned and floored at two sampling intervals so the avg/max choice is meaningful on every range; long ranges downsample to at most 240 points per pod.
  • spring.task.scheduling.pool.size is raised to 3 in the config templates: the Spring Boot default of 1 would serialise this sampler with PipelineInstanceScanJob and ScheduledRestartJob.

Frontend:

  • A "Metrics" button on the status page's environment tab row opens a right-side drawer with two area charts (CPU cores, memory MiB), one line per pod, with 30m/1h/6h/24h ranges, an avg/max toggle, and a 30s silent refresh. Localised in all four languages.
  • Adds the base-vega chart (recharts) and drawer components; tabs get cursor-pointer per project convention and a primary-colored active indicator for the line variant.

History lives in memory by design (restart starts over) and shares the single-instance assumption of the existing scheduler jobs; the store port isolates a future shared-storage implementation if that changes.

metrics-server keeps no history, so the status page could only show a
point-in-time reading. This adds an in-process sampler that turns those
readings into 24 hours of per-pod usage curves.

Backend:
- PodMetricSampleJob sweeps every environment on a 30s tick, fanning out
  across virtual threads so one unreachable cluster cannot delay the
  others. Each environment costs two cluster-wide API calls (pod list +
  top) regardless of application count; pods are attributed to
  applications via the oops.app.name label, so the sweep never touches
  the database.
- InMemoryPodMetricHistoryStore keeps each pod series in a fixed-size
  ring of primitive arrays (20 bytes/sample, ~57KB per pod for 24h)
  behind the PodMetricHistoryStore port. Series survive pod deletion
  until their samples age out, so charts drawn right after a rollout
  still show the replaced pods. A max-series cap guards the heap.
- GET .../applications/{name}/metrics/history?env=&range=&agg= serves
  chart-ready series. Buckets are epoch-aligned and floored at two
  sampling intervals so the avg/max choice is meaningful on every
  range; long ranges downsample to at most 240 points per pod.
- spring.task.scheduling.pool.size is raised to 3 in the config
  templates: the Spring Boot default of 1 would serialise this sampler
  with PipelineInstanceScanJob and ScheduledRestartJob.

Frontend:
- A "Metrics" button on the status page's environment tab row opens a
  right-side drawer with two area charts (CPU cores, memory MiB), one
  line per pod, with 30m/1h/6h/24h ranges, an avg/max toggle, and a
  30s silent refresh. Localised in all four languages.
- Adds the base-vega chart (recharts) and drawer components; tabs get
  cursor-pointer per project convention and a primary-colored active
  indicator for the line variant.

History lives in memory by design (restart starts over) and shares the
single-instance assumption of the existing scheduler jobs; the store
port isolates a future shared-storage implementation if that changes.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
@wellCh4n
wellCh4n merged commit 380b4f4 into main Jul 28, 2026
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