From fee6a0f1684dc4e160fedf1156d0fc8d3e6b2689 Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Wed, 29 Jul 2026 15:20:49 -0500 Subject: [PATCH 1/2] Document the single scrape target requirement for v2 metrics --- content/embeds/rs-observability.md | 2 +- content/embeds/rs-prometheus-grafana-quickstart.md | 8 ++++++++ .../prometheus-metrics-v1-to-v2.md | 8 ++++++++ content/operate/rs/monitoring/_index.md | 2 +- content/operate/rs/monitoring/get-started.md | 6 ++++++ .../rs/monitoring/metrics_stream_engine/_index.md | 10 +++++++++- .../prometheus-metrics-v1-to-v2.md | 8 ++++++++ content/operate/rs/references/metrics/_index.md | 2 +- 8 files changed, 42 insertions(+), 4 deletions(-) diff --git a/content/embeds/rs-observability.md b/content/embeds/rs-observability.md index 1b20c805f1..caa1b26859 100644 --- a/content/embeds/rs-observability.md +++ b/content/embeds/rs-observability.md @@ -33,7 +33,7 @@ In addition to manually monitoring these resources and indicators, it is best pr ## Core cluster resource monitoring -Redis Software version 7.8.2 introduces a preview of the new metrics stream engine that exposes the v2 Prometheus scraping endpoint at `https://:8070/v2`. This new engine exports all time-series metrics to external monitoring tools such as Grafana, DataDog, NewRelic, and Dynatrace using Prometheus. +Redis Software version 7.8.2 introduces a preview of the new metrics stream engine that exposes the v2 Prometheus scraping endpoint at `https://:8070/v2`. This new engine exports all time-series metrics to external monitoring tools such as Grafana, DataDog, NewRelic, and Dynatrace using Prometheus. The new engine enables real-time monitoring, including full monitoring during maintenance operations, providing full visibility into performance during events such as shards' failovers and scaling operations. See [Monitoring with metrics and alerts]({{}}) for more details. diff --git a/content/embeds/rs-prometheus-grafana-quickstart.md b/content/embeds/rs-prometheus-grafana-quickstart.md index dc0fed8e8c..1e7483719a 100644 --- a/content/embeds/rs-prometheus-grafana-quickstart.md +++ b/content/embeds/rs-prometheus-grafana-quickstart.md @@ -132,6 +132,12 @@ scrape_configs: ``` {{< /multitabs >}} + {{< note >}} + +**Use a single scrape target.** The v2 endpoint is cluster-wide. Every node aggregates metrics from all nodes and returns the same complete result, so one target is enough. If you list one target per node, Prometheus stores every series once per target and multiplies each `sum()`-based dashboard panel by the number of targets. This produces no error. Prometheus reports every target as up and Grafana renders normally. Use your cluster FQDN as the single target so metrics remain available if a node goes down. + + {{< /note >}} + 1. Set up your Prometheus and Grafana servers. See the official [Prometheus installation](https://prometheus.io/docs/prometheus/latest/installation/) and [Grafana installation](https://grafana.com/docs/grafana/latest/setup-grafana/installation/) documentation for help. {{< note >}} @@ -195,6 +201,8 @@ We recommend running Prometheus in Docker only for development and testing. If Prometheus is connected to the cluster, you can type **node_up** in the Expression field on the Prometheus home page to see the cluster metrics. + To confirm you are not scraping duplicate targets, query `count(up{job="redis-enterprise"})`. A correct configuration returns `1`. To confirm the cluster can reach every node, query `node_metrics_up`, which reports `0` for any node the aggregator failed to scrape. + 1. Configure the Grafana datasource: 1. Sign in to Grafana. If you installed Grafana locally, go to `http://localhost:3000` and sign in with: diff --git a/content/integrate/prometheus-with-redis-enterprise/prometheus-metrics-v1-to-v2.md b/content/integrate/prometheus-with-redis-enterprise/prometheus-metrics-v1-to-v2.md index 7213e9500c..a2f2c7cf2e 100644 --- a/content/integrate/prometheus-with-redis-enterprise/prometheus-metrics-v1-to-v2.md +++ b/content/integrate/prometheus-with-redis-enterprise/prometheus-metrics-v1-to-v2.md @@ -36,6 +36,14 @@ scrape_configs: - targets: [":8070"] ``` +{{< note >}} +**Use a single scrape target.** The v2 endpoint is cluster-wide. Every node aggregates metrics from all nodes and returns the same complete result, so one target is enough. If you list one target per node, Prometheus stores every series once per target and multiplies each `sum()`-based dashboard panel by the number of targets. This produces no error. Prometheus reports every target as up and Grafana renders normally. Use your cluster FQDN as the single target so metrics remain available if a node goes down. +{{< /note >}} + +The reason for a single target changed in v2. On v1, only the cluster master served the metrics endpoint and other nodes returned a redirect, so the protocol effectively forced one target. On v2, every node returns the full cluster view and no redirects are involved. If your v1 configuration listed multiple node targets, reduce it to one. + +If you prefer a per-node scrape topology, scrape `/v2/node`, which returns only that node's own metrics. Aggregation adds the `cluster` and `node` labels, so `/v2/node` responses omit them. Add `relabel_configs` to supply those labels before using `/v2/node` with the Redis Software Grafana dashboards. + It is possible to scrape both v1 and v2 endpoints simultaneously during the transition period to prepare dashboards and ensure a smooth transition. You can use the following tables to transition from v1 metrics to equivalent v2 PromQL. For a list of all available v2 PromQL metrics, see [Prometheus metrics v2]({{}}). diff --git a/content/operate/rs/monitoring/_index.md b/content/operate/rs/monitoring/_index.md index c990967bf7..02a111a924 100644 --- a/content/operate/rs/monitoring/_index.md +++ b/content/operate/rs/monitoring/_index.md @@ -24,7 +24,7 @@ See [Metrics and alerts for monitoring v1]({{}}) This new engine exposes the v2 Prometheus scraping endpoint at `https://:8070/v2`, exports all time-series metrics to external monitoring tools, and enables real-time monitoring. +The new metrics stream engine is generally available as of [Redis Software version 8.0]({{}}) This new engine exposes the v2 Prometheus scraping endpoint at `https://:8070/v2`, exports all time-series metrics to external monitoring tools, and enables real-time monitoring. See [Metrics stream engine for monitoring v2]({{}}) for more information. diff --git a/content/operate/rs/monitoring/get-started.md b/content/operate/rs/monitoring/get-started.md index 29ea92b290..37465f5df2 100644 --- a/content/operate/rs/monitoring/get-started.md +++ b/content/operate/rs/monitoring/get-started.md @@ -129,6 +129,10 @@ scrape_configs: ``` {{< /multitabs >}} + {{< note >}} +**Use a single scrape target.** The v2 endpoint is cluster-wide. Every node aggregates metrics from all nodes and returns the same complete result, so one target is enough. If you list one target per node, Prometheus stores every series once per target and multiplies each `sum()`-based dashboard panel by the number of targets. This produces no error. Prometheus reports every target as up and Grafana renders normally. Use your cluster FQDN as the single target so metrics remain available if a node goes down. + {{< /note >}} + 1. Set up your Prometheus server. {{< note >}} @@ -170,6 +174,8 @@ We recommend running Prometheus in Docker only for development and testing. If Prometheus is connected to the cluster, you can type **node_up** in the Expression field on the Prometheus home page to see the cluster metrics. + To confirm you are not scraping duplicate targets, query `count(up{job="redis-enterprise"})`. A correct configuration returns `1`. To confirm the cluster can reach every node, query `node_metrics_up`, which reports `0` for any node the aggregator failed to scrape. + 1. Integrate Redis Software and your Prometheus server with one of the [compatible tools](#prometheus-integrations). For help, see the integration guide and official documentation for your chosen tool. 1. Add dashboards for cluster, database, node, and shard metrics. diff --git a/content/operate/rs/monitoring/metrics_stream_engine/_index.md b/content/operate/rs/monitoring/metrics_stream_engine/_index.md index afe88879be..34bb3f1887 100644 --- a/content/operate/rs/monitoring/metrics_stream_engine/_index.md +++ b/content/operate/rs/monitoring/metrics_stream_engine/_index.md @@ -17,7 +17,7 @@ The new metrics stream engine is generally available as of [Redis Software versi The new metrics stream engine: -- Exposes the v2 Prometheus scraping endpoint at `https://:8070/v2`. +- Exposes the v2 Prometheus scraping endpoint at `https://:8070/v2`. - Exports all time-series metrics to external monitoring tools such as Grafana, DataDog, NewRelic, and Dynatrace using Prometheus. @@ -67,8 +67,16 @@ If you are already using the existing scraping endpoint for integration, do the - targets: [":8070"] ``` + {{< note >}} +**Use a single scrape target.** The v2 endpoint is cluster-wide. Every node aggregates metrics from all nodes and returns the same complete result, so one target is enough. If you list one target per node, Prometheus stores every series once per target and multiplies each `sum()`-based dashboard panel by the number of targets. This produces no error. Prometheus reports every target as up and Grafana renders normally. Use your cluster FQDN as the single target so metrics remain available if a node goes down. + {{< /note >}} + 1. Use the metrics tables in [this guide]({{}}) to transition from v1 metrics to equivalent v2 PromQL. +The reason for a single target changed in v2. On v1, only the cluster master served the metrics endpoint and other nodes returned a redirect, so the protocol effectively forced one target. On v2, every node returns the full cluster view and no redirects are involved. If your v1 configuration listed multiple node targets, reduce it to one. + +If you prefer a per-node scrape topology, scrape `/v2/node`, which returns only that node's own metrics. Aggregation adds the `cluster` and `node` labels, so `/v2/node` responses omit them. Add `relabel_configs` to supply those labels before using `/v2/node` with the Redis Software Grafana dashboards. + It is possible to scrape both existing and new endpoints simultaneously, allowing advanced dashboard preparation and a smooth transition. {{}} \ No newline at end of file diff --git a/content/operate/rs/monitoring/metrics_stream_engine/prometheus-metrics-v1-to-v2.md b/content/operate/rs/monitoring/metrics_stream_engine/prometheus-metrics-v1-to-v2.md index 1822e589d7..2df9d15d04 100644 --- a/content/operate/rs/monitoring/metrics_stream_engine/prometheus-metrics-v1-to-v2.md +++ b/content/operate/rs/monitoring/metrics_stream_engine/prometheus-metrics-v1-to-v2.md @@ -36,6 +36,14 @@ scrape_configs: - targets: [":8070"] ``` +{{< note >}} +**Use a single scrape target.** The v2 endpoint is cluster-wide. Every node aggregates metrics from all nodes and returns the same complete result, so one target is enough. If you list one target per node, Prometheus stores every series once per target and multiplies each `sum()`-based dashboard panel by the number of targets. This produces no error. Prometheus reports every target as up and Grafana renders normally. Use your cluster FQDN as the single target so metrics remain available if a node goes down. +{{< /note >}} + +The reason for a single target changed in v2. On v1, only the cluster master served the metrics endpoint and other nodes returned a redirect, so the protocol effectively forced one target. On v2, every node returns the full cluster view and no redirects are involved. If your v1 configuration listed multiple node targets, reduce it to one. + +If you prefer a per-node scrape topology, scrape `/v2/node`, which returns only that node's own metrics. Aggregation adds the `cluster` and `node` labels, so `/v2/node` responses omit them. Add `relabel_configs` to supply those labels before using `/v2/node` with the Redis Software Grafana dashboards. + You can scrape both v1 and v2 endpoints simultaneously during the transition period to prepare dashboards and ensure a smooth transition. You can use the following tables to transition from v1 metrics to equivalent v2 PromQL. For a list of all available v2 metrics, see [Prometheus metrics v2]({{}}). diff --git a/content/operate/rs/references/metrics/_index.md b/content/operate/rs/references/metrics/_index.md index dae0ea6a32..0dd31ee763 100644 --- a/content/operate/rs/references/metrics/_index.md +++ b/content/operate/rs/references/metrics/_index.md @@ -30,7 +30,7 @@ you can connect your [Prometheus](https://prometheus.io/) and [Grafana](https:// See [Prometheus integration]({{< relref "/operate/rs/monitoring/get-started" >}}) to learn how to connect Prometheus and Grafana to your Redis Software database. -The new metrics stream engine that exposes the v2 Prometheus scraping endpoint at `https://:8070/v2` is generally available as of Redis Software version 8.0. +The new metrics stream engine that exposes the v2 Prometheus scraping endpoint at `https://:8070/v2` is generally available as of Redis Software version 8.0. This new engine exports all time-series metrics to external monitoring tools such as Grafana, DataDog, NewRelic, and Dynatrace using Prometheus. The new engine enables real-time monitoring, including full monitoring during maintenance operations, providing full visibility into performance during events such as shards' failovers and scaling operations. From 0a846acc3820deebbd1253e2c5f0e368be803981 Mon Sep 17 00:00:00 2001 From: Kaitlyn Michael Date: Wed, 29 Jul 2026 16:55:56 -0500 Subject: [PATCH 2/2] additional file to correct --- .../rs/references/metrics/prometheus-metrics-v1-to-v2.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/operate/rs/references/metrics/prometheus-metrics-v1-to-v2.md b/content/operate/rs/references/metrics/prometheus-metrics-v1-to-v2.md index d97129b918..3b33741bf1 100644 --- a/content/operate/rs/references/metrics/prometheus-metrics-v1-to-v2.md +++ b/content/operate/rs/references/metrics/prometheus-metrics-v1-to-v2.md @@ -36,6 +36,14 @@ scrape_configs: - targets: [":8070"] ``` +{{< note >}} +**Use a single scrape target.** The v2 endpoint is cluster-wide. Every node aggregates metrics from all nodes and returns the same complete result, so one target is enough. If you list one target per node, Prometheus stores every series once per target and multiplies each `sum()`-based dashboard panel by the number of targets. This produces no error. Prometheus reports every target as up and Grafana renders normally. Use your cluster FQDN as the single target so metrics remain available if a node goes down. +{{< /note >}} + +The reason for a single target changed in v2. On v1, only the cluster master served the metrics endpoint and other nodes returned a redirect, so the protocol effectively forced one target. On v2, every node returns the full cluster view and no redirects are involved. If your v1 configuration listed multiple node targets, reduce it to one. + +If you prefer a per-node scrape topology, scrape `/v2/node`, which returns only that node's own metrics. Aggregation adds the `cluster` and `node` labels, so `/v2/node` responses omit them. Add `relabel_configs` to supply those labels before using `/v2/node` with the Redis Software Grafana dashboards. + It is possible to scrape both v1 and v2 endpoints simultaneously during the transition period to prepare dashboards and ensure a smooth transition. You can use the following tables to transition from v1 metrics to equivalent v2 PromQL. For a list of all available v2 metrics, see [Prometheus metrics v2]({{}}).