Without `staleTime: Infinity`, the query data would be immediately marked
stale, and in combination with the `gcTime: 0` setting and a brief unmount
during data loading (via Suspense), the data would have to be reloaded a second
time during/after the first real render.
`gcTime: 0` + `staleTime: Infinity` should give us the desired behavior where
data loaded for a page should be valid forever as long as that page is being
displayed, but always thrown away (and later reloaded) whenever we navigate
away and again to that page.
Signed-off-by: Julius Volz <julius.volz@gmail.com>
This adds:
* A `ScrapePoolConfig()` method to the scrape manager that allows getting
the scrape config for a given pool.
* An API endpoint at `/api/v1/targets/relabel_steps` that takes a pool name
and a label set of a target and returns a detailed list of applied
relabeling rules and their output for each step.
* A "show relabeling" link/button for each target on the discovery page
that shows the detailed flow of all relabeling rules (based on the API
response) for that target.
Note that this changes the JSON encoding of the relabeling rule config
struct to output the original snake_case (instead of camelCase) field names,
and before merging, we need to be sure that's ok :) See my comment about
that at https://github.com/prometheus/prometheus/pull/15383#issuecomment-3405591487
Fixes https://github.com/prometheus/prometheus/issues/17283
Signed-off-by: Julius Volz <julius.volz@gmail.com>
Bump versions and changelog.
Co-authored-by: Arthur Silva Sens <arthursens2005@gmail.com>
Co-authored-by: Ayoub Mrini <ayoubmrini424@gmail.com>
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
Implements expand/collapse functionality for displaying final scrape
configuration (interval + timeout) in the targets page timing column.
- Add ScrapeDetails component with expand/collapse chevron
- Keep existing "Last Scrape" and "Scrape Duration" badges always visible
- Display "Scrape interval: every \<interval\>" and "Scrape timeout: after \<timeout\>" when expanded
- Use IconRepeat for interval and IconPlugConnectedX for timeout
- Follow TargetLabels.tsx pattern for consistency
- Implement performance optimization with conditional DOM rendering
- Maintain existing hover tooltip functionality
Signed-off-by: ADITYATIWARI342005 <142050150+ADITYATIWARI342005@users.noreply.github.com>
Although these suffixes always need to be removed before querying metadata for
metrics that follow the Prometheus naming best practices, there can also be
metrics that don't follow these naming practices and have these suffixes
without being part of either a histogram or a summary metric.
Fixes https://github.com/prometheus/prometheus/issues/16907
Signed-off-by: Julius Volz <julius.volz@gmail.com>
This RC reverts the feature "OTLP: Support promoting OTel scope attributes".
Add the line back into the CHANGELOG for 3.5.0-rc.0, since we are not changing that version.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
Addresses part of https://github.com/prometheus/prometheus/issues/16515
For now, I'm adding very similar filtering to the /rules page as we have on
the /alerts page, with the difference being:
* The state filter filters by rule health (ok/warn/unknown) instead of
alert state (firing/pending/inactive)
* We don't collect & show detailed stats on the different state counts as
we do on the /alerts page
There is a lot of copied / very similar code between those two pages (and
also some others) around filtering and pagination, so maybe there is an
opportunity for more code sharing in the future here.
Signed-off-by: Julius Volz <julius.volz@gmail.com>
When opening the status pages menu while already viewing one of the
status pages, the whole page would be re-rendered because the menu target's
default action of following the current page's URL was not prevented. Also,
we don't need to use a NavLink component for the menu target when we are
not viewing a status page, because then the component won't need to be
highlighted anyways.
Discovered + fixed with the help of react-scan.
Signed-off-by: Julius Volz <julius.volz@gmail.com>
Moving the debouncing of the search field to the parent component and then
memoizing the ScrapePoolsList component prevents a lot of superfluous
re-renders of the entire scrape pools list that previously got triggered
immediately when you typed in the search box or even just collapsed a pool.
(While the computation of what data to show was already memoized in the
ScrapePoolList component, the component itself still had to re-render a lot
with the same data.)
Discovered this problem + verified fix using react-scan.
Signed-off-by: Julius Volz <julius.volz@gmail.com>
