feat(metrics): add pod CPU/memory usage history with charts drawer - #77
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
Frontend:
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.