With this commit we make it possible to adjust the request headers sent
to Prometheus by the codemirror-promql extension. This enables
customizing the headers sent, without re-implementing the Prometheus
client completely.
Signed-off-by: Jacob Baungard Hansen <jacobbaungard@redhat.com>
* Show group interval in Rules display
Signed-off-by: Danny Kopping <danny.kopping@grafana.com>
* Humanise interval
Signed-off-by: Danny Kopping <danny.kopping@grafana.com>
---------
Signed-off-by: Danny Kopping <danny.kopping@grafana.com>
* Move /targets page discovered labels to expandable section
The current tooltip for showing the pre-relabeling discovered labels for a
target is notoriously unreliable and can get cut off when there are many
labels. This PR introduces a (hopefully unobtuse enough) expander/collapser
button for the discovered labels of each target, and then the discovered labels
are shown in a more persistent way underneath the final target labels, instead
of using a tooltip.
Fixes https://github.com/prometheus/prometheus/issues/9175#issuecomment-1713074341
Signed-off-by: Julius Volz <julius.volz@gmail.com>
* Remove obsolete test snapshot
Signed-off-by: Julius Volz <julius.volz@gmail.com>
---------
Signed-off-by: Julius Volz <julius.volz@gmail.com>
This commit adds the option --include-workspace-root in ui_release.sh
npm scripts in order to also include the version in web/ui/pagkage jsons
files when bumping the version. This also avoids issues when building
directly with npm install on some systems.
Signed-off-by: Daniel Mellado <dmellado@redhat.com>
It's possible (quite common on Kubernetes) to have a service discovery
return thousands of targets then drop most of them in relabel rules.
The main place this data is used is to display in the web UI, where
you don't want thousands of lines of display.
The new limit is `keep_dropped_targets`, which defaults to 0
for backwards-compatibility.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
This commit adds a new 'keep_firing_for' field to Prometheus alerting
rules. The 'resolve_delay' field specifies the minimum amount of time
that an alert should remain firing, even if the expression does not
return any results.
This feature was discussed at a previous dev summit, and it was
determined that a feature like this would be useful in order to allow
the expression time to stabilize and prevent confusing resolved messages
from being propagated through Alertmanager.
This approach is simpler than having two PromQL queries, as was
sometimes discussed, and it should be easy to implement.
This commit does not include tests for the 'resolve_delay' field. This
is intentional, as the purpose of this commit is to gather comments on
the proposed design of the 'resolve_delay' field before implementing
tests. Once the design of the 'resolve_delay' field has been finalized,
a follow-up commit will be submitted with tests."
See https://github.com/prometheus/prometheus/issues/11570
Signed-off-by: Julien Pivotto <roidelapluie@o11y.eu>
