diff --git a/assets/css/index.css b/assets/css/index.css index c85a372c49..d677cabeb2 100644 --- a/assets/css/index.css +++ b/assets/css/index.css @@ -1863,3 +1863,49 @@ a[href*="#no-click"], img[src*="#no-click"] { white-space: nowrap; border: 0; } + +/* Qualified chat widget accommodations. The widget (production only, + injected via GTM, owned by web/marketing) replaces root scrolling with a + scroller: it measures the root scrollbar width N, then applies + html { width: calc(100dvw - N); margin-right: N; overflow: hidden } and + body { width: calc(100% + N) }, expecting body's scrollbar to land where + the root scrollbar was. When N > 0 (classic, always-visible scrollbars: + Windows, or macOS with a mouse), body overshoots html's box by N and + html's own overflow: hidden clips body's scrollbar out of view — the page + scrollbar disappears the moment the widget loads. The widget marks + with q-docked-target while it is active and q-docked while the chat panel + is open. */ + +/* While the chat is closed, neutralize the width/margin compensation on + both elements so body fills the window exactly and its scrollbar sits at + the window edge, unclipped. While the panel is docked open (q-docked) the + widget's own geometry must win, so none of this applies then. */ +html[q-docked-target]:not([q-docked]) { + width: 100dvw !important; + min-width: 100dvw !important; + max-width: 100dvw !important; + margin-right: 0 !important; +} + +html[q-docked-target]:not([q-docked]) body { + width: 100% !important; + max-width: 100% !important; +} + +/* The html { scrollbar-gutter: stable } rule set earlier in this file would + re-reserve a gutter inside the widget's overflow-hidden html box and push + body's scrollbar inboard by another scrollbar-width. Scoped to the widget + being active so normal pages keep the stable gutter. */ +html[q-docked-target] { + scrollbar-gutter: auto !important; +} + +/* While the chat is closed, the widget's invisible #q-messenger-frame + iframe overlays page content near the right edge with pointer events + enabled, stealing clicks and hovers from whatever is underneath — + including the page scrollbar, since Firefox hit-tests page content before + non-root scrollbars. Let events pass through; q-docked restores normal + pointer events for the open panel. */ +html:not([q-docked]) #q-messenger-frame { + pointer-events: none !important; +} diff --git a/content/develop/ai/ecosystem-integrations.md b/content/develop/ai/ecosystem-integrations.md index 4286b02f17..10aa37a438 100644 --- a/content/develop/ai/ecosystem-integrations.md +++ b/content/develop/ai/ecosystem-integrations.md @@ -23,6 +23,7 @@ Redis integrates with a wide range of AI frameworks, platforms, and tools to enh ## Additional integrations +- [**AISIX AI Gateway & Redis**](https://docs.api7.ai/ai-gateway/traffic-controls/caching): Use Redis to share response cache entries and coordinate [rate-limit counters](https://docs.api7.ai/ai-gateway/traffic-controls/rate-limits) across AISIX gateway instances. - [**Microsoft Semantic Kernel**](https://learn.microsoft.com/en-us/semantic-kernel/concepts/vector-store-connectors/out-of-the-box-connectors/redis-connector?pivots=programming-language-csharp): Use Redis as a vector store connector with Microsoft's Semantic Kernel framework. - [**DocArray**](https://docs.docarray.org/user_guide/storing/index_redis/): Leverage Redis as a document store and vector database with Jina AI's DocArray. - [**Redis Cloud on Vercel**](https://redis.io/blog/redis-cloud-now-available-on-vercel-marketplace/): Deploy and manage Redis databases directly from your Vercel dashboard with the Redis Cloud integration. Refer to the [setup guide]({{< relref "/operate/rc/cloud-integrations/vercel" >}}) for more details. diff --git a/content/integrate/redis-data-integration/installation/migration-classic-to-flink.md b/content/integrate/redis-data-integration/installation/migration-classic-to-flink.md index 36ac9d9ba4..419c048101 100644 --- a/content/integrate/redis-data-integration/installation/migration-classic-to-flink.md +++ b/content/integrate/redis-data-integration/installation/migration-classic-to-flink.md @@ -16,7 +16,7 @@ type: integration weight: 35 --- -RDI ships with two stream processor implementations. The default *classic* +RDI ships with two stream processor implementations. The *classic* processor is implemented in Python. The *Flink* processor is built on top of [Apache Flink](https://flink.apache.org/). Both run on VM and Kubernetes installations. The Flink processor can achieve much higher throughput @@ -24,6 +24,9 @@ during snapshots, scales horizontally by changing the number of TaskManager repl and uses Flink checkpointing for fault tolerance. See [Stream processor implementations]({{< relref "/integrate/redis-data-integration/architecture#stream-processor-implementations" >}}) for an overview. +The classic processor is the default in RDI 1.19.0. The Flink processor is the +default starting with RDI 2.0.0. + This page describes how to migrate an existing pipeline from the classic processor to the Flink processor. The steps are the same on VMs and Kubernetes, except for the optional Helm-level tuning in [Step 1](#step-1-configure-the-flink-processor-at-the-helm-chart-level-kubernetes), @@ -31,11 +34,24 @@ which applies to Kubernetes only. ## Before you migrate +This procedure migrates the pipeline processor on RDI 1.19.0. It does not +upgrade RDI. + +Before you start, save your existing configuration and jobs. Wait for the +initial snapshot to finish. Interrupting it causes the snapshot to restart +from the beginning. + +{{< warning >}} +Switching processors with records still in the RDI input streams can leave +records unprocessed. Stop the collector and let the classic processor empty +the streams before switching. +{{< /warning >}} + Confirm that your pipeline is compatible with the Flink processor: - `JSON.MERGE` semantics differ from the classic processor's Lua-based merge when null values are involved (see - [`use_native_json_merge`]({{< relref "/integrate/redis-data-integration/reference/config-yaml-reference#processors" >}})). + [`use_native_json_merge`]({{< relref "/integrate/redis-data-integration/reference/config-yaml-reference#processors-data-processing-configuration" >}})). The Flink processor always uses the native `JSON.MERGE` command when the target database supports it. - Ensure your Kubernetes cluster or VM has enough capacity for the Flink JobManager @@ -46,7 +62,7 @@ Confirm that your pipeline is compatible with the Flink processor: ## Step 1: Configure the Flink processor at the Helm chart level (Kubernetes) This step applies to **Kubernetes** installations only. On VM installations, -skip it and enable the Flink processor per pipeline in step 2. +continue with [Step 2](#step-2-disable-source-collection). The Flink processor is always available — no opt-in is required at the Helm chart level. The defaults are sized for typical workloads, so you can skip @@ -55,27 +71,137 @@ TaskManager defaults, add an `operator.dataPlane.flinkProcessor` block to your `rdi-values.yaml` file and run `helm upgrade` as described in [Configure the Flink processor]({{< relref "/integrate/redis-data-integration/installation/install-k8s#configure-the-flink-processor" >}}). Existing pipelines continue to run on the classic processor until you switch -them in step 2. +them in [Step 4](#step-4-switch-processors-and-resume-collection). For VM installations, skip this step. You can configure per-pipeline Flink -resources in step 4. +resources in [Step 6](#step-6-tune-the-flink-processor-optional). + +## Step 2: Disable source collection + +In your existing `config.yaml`, add `active: false` under the source and set +`processors.type` to `classic`. Use your existing source name and preserve +all other source, target, processor, and job settings. This example shows +only the fields to change: + +```yaml +sources: + : + active: false +processors: + type: classic +``` + +Deploy the complete configuration directory, including the existing jobs: + +```bash +redis-di deploy --dir +``` + +Wait for the deployment to finish and the source collector to stop. Keep +the pipeline active so the classic processor can process the remaining input records. +Do not use `redis-di stop` for this step, because it also stops the processor. + +Applications can continue writing to the source database while collection +is disabled. Make sure the database change log retains the whole paused +interval. When the collector restarts, it resumes from the saved source +position and processes those changes. + +## Step 3: Wait for the input streams to empty + +After the collector has stopped, wait for every input stream to have a length +of `0` in three complete checks, five seconds apart. An error, missing +statistics, or an unexpectedly empty stream list does not count as `0`. +Do not include DLQ streams. Use any of the following methods. + +### Check with `redis-di` + +Run: + +```bash +redis-di describe default +``` -## Step 2: Switch the pipeline to the Flink processor +In the **Statistics** table, the **Pending** value for each classic processor +stream is its current length. Confirm that every input stream is listed and +that the values agree with the Redis command checks below. This **Pending** +value is different from consumer-group pending entries. `XPENDING` or group +lag of `0` alone does not prove that a stream is empty. -In the pipeline's `config.yaml`, set +### Check with Redis commands + +Connect an authenticated Redis client to the **RDI database** that stores +the pipeline's input streams, not the target database. Find the input stream +keys with +[`SCAN`]({{< relref "/commands/scan" >}}): + +```text +SCAN 0 MATCH data:{rdi}:* COUNT 1000 TYPE stream +``` + +If the returned cursor is not `0`, pass it to the next command: + +```text +SCAN MATCH data:{rdi}:* COUNT 1000 TYPE stream +``` + +Repeat with each new cursor until the returned cursor is `0`, even if an +intermediate result contains no keys. + +For every input stream returned, run +[`XLEN`]({{< relref "/commands/xlen" >}}): + +```text +XLEN +``` + +Run a complete `SCAN` and all `XLEN` commands in each of the three checks. + +### Check with Redis Insight + +1. Connect Redis Insight to the RDI database and open **Browse**. +1. Filter by the pipeline's input stream pattern. For the default pipeline, + use `data:{rdi}:*`. Confirm that all input streams are listed. +1. Open each stream, select **Stream Data**, and use the refresh button. + Confirm that **Entries** is `0`. +1. Repeat the complete inventory and entry check three times, five seconds + apart. + +You can also open the built-in **CLI** and run the `SCAN` and `XLEN` commands +shown above. The Browser and CLI results must contain the same streams and +lengths. + +If records remain, keep the classic processor running and resolve its +processing errors before continuing. Do not delete stream entries, reset the +pipeline, or move consumer-group positions to make the count reach `0`. + +## Step 4: Switch processors and resume collection + +After the drain check passes, remove the source's `active: false` setting +from the existing `config.yaml` and set [`processors.type`]({{< relref "/integrate/redis-data-integration/data-pipelines/pipeline-config#processors" >}}) to `flink`: ```yaml processors: type: flink - ... ``` -Then redeploy the pipeline. The operator stops the classic processor pods -and starts the Flink JobManager and TaskManager workloads for the pipeline. +RDI 1.19.0 requires this setting because its default processor is `classic`. + +Keep the remaining configuration and jobs, then redeploy the complete +configuration directory: + +```bash +redis-di deploy --dir +``` + +Wait for the classic processor to terminate and the Flink JobManager and +TaskManager workloads to become healthy. Confirm that collection resumes +from the saved source position and changes committed during the pause reach +the target. Verify new inserts, updates, and deletes. The processor migration +is complete after these checks pass. -## Step 3: Adapt deprecated and classic-only properties +## Step 5: Adapt deprecated and classic-only properties Some `processors` properties are no-ops, classic-only, or have moved to `processors.advanced` for the Flink processor. The following table lists the @@ -97,7 +223,7 @@ and the Flink processor silently ignores classic-only top-level properties, so k both top-level properties and their `processors.advanced` equivalents lets you switch back without further edits. -## Step 4: Tune the Flink processor (optional) +## Step 6: Tune the Flink processor (optional) Fine-tune the Flink processor through the `processors.advanced` section. For example: @@ -121,10 +247,10 @@ processors: ``` See the -[`processors.advanced` reference]({{< relref "/integrate/redis-data-integration/reference/config-yaml-reference#processors" >}}) +[`processors.advanced` reference]({{< relref "/integrate/redis-data-integration/reference/config-yaml-reference#processorsadvanced-advanced-configuration" >}}) for the full set of available properties. -## Step 5: Update observability +## Step 7: Update observability The Flink processor exposes Prometheus metrics directly from the Flink JobManager and TaskManager pods. @@ -135,6 +261,6 @@ for the `ServiceMonitor` configuration and the available metrics. ## Rolling back To revert a pipeline to the classic processor, set `processors.type` back to -`classic` (or remove the property) and redeploy the pipeline. The -`processors.advanced` section is silently ignored by the classic processor, -so you don't need to remove it before switching back. +`classic` and redeploy the pipeline. This setting is required on RDI 2.0.0, +where the default is `flink`. The classic processor silently ignores +`processors.advanced`, so you don't need to remove it before switching back. diff --git a/content/integrate/redis-data-integration/installation/upgrade.md b/content/integrate/redis-data-integration/installation/upgrade.md index da873958c0..964881e79d 100644 --- a/content/integrate/redis-data-integration/installation/upgrade.md +++ b/content/integrate/redis-data-integration/installation/upgrade.md @@ -16,6 +16,28 @@ type: integration weight: 30 --- +{{< note >}} +Before upgrading to RDI 2.0.0, review the +[processor default change](#upgrading-to-rdi-200). +{{< /note >}} + +## Upgrading to RDI 2.0.0 + +RDI 2.0.0 changes the default processor from `classic` to `flink`. This default +applies when the pipeline's `config.yaml` omits `processors.type`. + +For an existing classic pipeline, choose one of these options before upgrading: + +- To migrate to Flink, first follow + [Migrate from the classic processor to the Flink processor]({{< relref "/integrate/redis-data-integration/installation/migration-classic-to-flink" >}}) + on RDI 1.19.0. This stops the collector and drains the input streams before + switching processors. Then upgrade RDI. +- To keep the classic processor, set `processors.type: classic` in the + pipeline's `config.yaml` and deploy it before upgrading. + +If your pipeline already uses `processors.type: flink`, no processor change +is needed. Continue with the upgrade instructions for your installation. + ## Upgrading a VM installation Follow the steps below to upgrade an existing @@ -181,11 +203,11 @@ The fully supported on both VM and Kubernetes installations after upgrading to RDI 1.19.0. Once the upgrade completes, it is always available — no opt-in is required, and the defaults are sized for typical workloads. -Upgrading does not change the processor used by existing pipelines, which keep -running on the classic processor until you explicitly switch them by -setting +On RDI 1.19.0, existing classic pipelines keep using that processor until +you switch them by setting [`processors.type`]({{< relref "/integrate/redis-data-integration/data-pipelines/pipeline-config#processors" >}}) to `flink` in their `config.yaml`. +RDI 2.0.0 changes this default; see [Upgrading to RDI 2.0.0](#upgrading-to-rdi-200). On Kubernetes, to override the Flink processor defaults, add an `operator.dataPlane.flinkProcessor` block to your `rdi-values.yaml` file as diff --git a/content/operate/kubernetes/release-notes/7-22-2-releases/7-22-2-43-august2026.md b/content/operate/kubernetes/release-notes/7-22-2-releases/7-22-2-43-august2026.md index 6bc095b490..b9dd71ce53 100644 --- a/content/operate/kubernetes/release-notes/7-22-2-releases/7-22-2-43-august2026.md +++ b/content/operate/kubernetes/release-notes/7-22-2-releases/7-22-2-43-august2026.md @@ -34,6 +34,6 @@ This is a maintenance release of Redis for Kubernetes to support Redis Software ### New limitations -- **Upgrading directly from Redis for Kubernetes 7.22.2-43 to 8.0.20-26 is not supported** due to an upgrade path limitation between these builds. Remain on 7.22.2-43 until a later 8.0.20 maintenance release is available. +- **Upgrading directly from Redis for Kubernetes 7.22.2-43 to 8.0.20-26 is not supported in OLM-based deployments** due to an upgrade path limitation between these builds. Upgrade to 8.0.20-27 or later instead. See [7.22.2 releases]({{}}) for information on other known limitations. diff --git a/content/operate/kubernetes/release-notes/8-0-20-releases/8-0-20-26-august2026.md b/content/operate/kubernetes/release-notes/8-0-20-releases/8-0-20-26-august2026.md index 5c3daa6fed..46cdc5d409 100644 --- a/content/operate/kubernetes/release-notes/8-0-20-releases/8-0-20-26-august2026.md +++ b/content/operate/kubernetes/release-notes/8-0-20-releases/8-0-20-26-august2026.md @@ -42,6 +42,6 @@ This is a maintenance release to support [Redis Software 8.0.20]({{}}) for information on other known limitations. diff --git a/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.10-release-notes.md b/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.10-release-notes.md index e9e8c26789..7e8cb41c6f 100644 --- a/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.10-release-notes.md +++ b/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.10-release-notes.md @@ -14,11 +14,25 @@ weight: 95 --- ## Requirements -RedisTimeSeries v1.10.24 requires: +RedisTimeSeries v1.10.27 requires: - Minimum Redis compatibility version (database): 7.2 - Minimum Redis Enterprise Software version (cluster): 7.2.4 +## v1.10.27 (Sep 2026) + +This is a maintenance release for RedisTimeSeries 1.10. + +Update urgency: `SECURITY`: There are security fixes in the release. + +Details: + +- **Security** + - Prevent heap buffer overflows and invalid memory access when restoring malformed time-series data. + +- Bug fixes: + - Fix `TS.INCRBY` replication to preserve the primary’s timestamp when using server-generated timestamps. + ## v1.10.24 (May 2026) This is a maintenance release for RedisTimeSeries 1.10. diff --git a/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.12-release-notes.md b/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.12-release-notes.md index f8f40fda8c..935ea5a95a 100644 --- a/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.12-release-notes.md +++ b/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.12-release-notes.md @@ -14,11 +14,27 @@ weight: 94 --- ## Requirements -RedisTimeSeries v1.12.14 requires: +RedisTimeSeries v1.12.17 requires: - Minimum Redis compatibility version (database): 7.4 - Minimum Redis Enterprise Software version (cluster): 7.8 +## v1.12.17 (Sep 2026) + +This is a maintenance release for RedisTimeSeries 1.12. + +Update urgency: `SECURITY`: There are security fixes in the release. + +Details: + +- **Security** + + - Prevent heap buffer overflows and invalid memory access when restoring malformed time-series data. + +- Bug fixes: + + - Fix `TS.INCRBY` replication to preserve the primary’s timestamp when using server-generated timestamps. + ## v1.12.14 (May 2026) {{< note >}} diff --git a/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.8-release-notes.md b/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.8-release-notes.md index 527f5659ea..1440f3ae22 100644 --- a/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.8-release-notes.md +++ b/content/operate/oss_and_stack/stack-with-enterprise/release-notes/redistimeseries/redistimeseries-1.8-release-notes.md @@ -16,11 +16,25 @@ weight: 96 --- ## Requirements -RedisTimeSeries v1.8.23 requires: +RedisTimeSeries v1.8.26 requires: - Minimum Redis compatibility version (database): 6.0.16 - Minimum Redis Enterprise Software version (cluster): 6.2.8 +## v1.8.26 (Sep 2026) + +This is a maintenance release for RedisTimeSeries 1.8. + +Update urgency: `SECURITY`: There are security fixes in the release. + +Details: + +- **Security:** + - Prevent heap buffer overflows and invalid memory access when restoring malformed time-series data. + +- Bug fixes: + - Fix `TS.INCRBY` replication to preserve the primary’s timestamp when using server-generated timestamps. + ## v1.8.23 (May 2026) This is a maintenance release for RedisTimeSeries 1.8. diff --git a/content/operate/oss_and_stack/stack-with-enterprise/search/search-active-active.md b/content/operate/oss_and_stack/stack-with-enterprise/search/search-active-active.md index 036bea7cf1..d469fce9bf 100644 --- a/content/operate/oss_and_stack/stack-with-enterprise/search/search-active-active.md +++ b/content/operate/oss_and_stack/stack-with-enterprise/search/search-active-active.md @@ -24,7 +24,6 @@ You can run search operations on any instance of an Active-Active database. Active-Active databases do not support the following Redis Search commands: -- [`FT.DROPINDEX` ]({{< relref "commands/ft.dropindex" >}}) - [`FT.SUGADD`]({{< relref "commands/ft.sugadd" >}}) - [`FT.SUGGET`]({{< relref "commands/ft.sugget" >}}) - [`FT.SUGDEL`]({{< relref "commands/ft.sugdel" >}}) diff --git a/content/operate/radar/_index.md b/content/operate/radar/_index.md index 04bd223f5d..085de022a4 100644 --- a/content/operate/radar/_index.md +++ b/content/operate/radar/_index.md @@ -36,6 +36,7 @@ Radar reads each cluster's management interface using credentials you supply, th This approach has two significant consequences: - **Radar needs credentials for every cluster you want to see.** Getting that access in place is most of the setup work. See [Connect clusters]({{< relref "/operate/radar/connect" >}}). +- **Radar must be able to reach each cluster.** Where it can't, such as a cluster behind a firewall or on an isolated network, an agent you install inside that network collects and submits on Radar's behalf. See [Connect clusters with an agent]({{< relref "/operate/radar/agent" >}}). - **Radar shows the last successful state collection rather than live state.** Radar collects the state of every connected cluster — Redis Software, Redis Open Source, Redis Cloud, Amazon ElastiCache, and Google Memorystore — on a fixed interval, so a value is only as fresh as the last time Radar reached that cluster. Radar shows that age alongside the data. ## Next steps diff --git a/content/operate/radar/agent.md b/content/operate/radar/agent.md new file mode 100644 index 0000000000..0225048492 --- /dev/null +++ b/content/operate/radar/agent.md @@ -0,0 +1,377 @@ +--- +title: Connect clusters with an agent +alwaysopen: false +categories: +- docs +- operate +- radar +description: Install an agent to connect Redis Software and Redis Open Source clusters that Radar cannot reach directly. +linkTitle: Agent +weight: 25 +--- + +The Radar agent collects data from Redis deployments that Radar can't reach directly. You install it on a host inside your network, and it opens an outbound connection to Radar. Radar never needs inbound access to your network. + +## When to connect clusters with an agent + +Use an agent for Redis Software and Redis Open Source deployments behind a firewall, in a private subnet, or on a segmented network. + +The agent always connects to Radar over Transport Layer Security (TLS), using gRPC, and makes separate local connections to each Redis endpoint you configure. + +Radar accepts those connections on its agent gRPC endpoint, which isn't enabled on every Radar deployment. Confirm the endpoint is available before you install an agent, and get its host and port from whoever administers your Radar deployment. + +The agent runs in one of two modes. They differ in where your source credentials live. + +| Mode | Radar holds source credentials | You maintain | Choose it when | +|---|---|---|---| +| Managed | Yes | Nothing on the host | You want to add and change sources from the Radar UI. | +| Static | No | A YAML file on the agent host | Source credentials must never leave the agent host. | + +## Trust a private certificate authority + +If Radar presents a certificate from a public certificate authority (CA), certificate verification doesn't require any configuration. The agent verifies it against the host's system roots. + +If Radar uses a private CA, point the agent at its certificate bundle instead: `tls.ca_file` in a static agent's configuration file, or `--ca-file` on `radar-agent activate` for a managed agent. The bundle you supply replaces the host's system roots rather than adding to them, so it must contain every certificate the agent needs to verify Radar. + +## Install the agent + +Each Radar release publishes standalone agent tarballs, so a collector host runs the agent without running Radar itself. + +Install the agent on a host that can reach both Radar and the Redis endpoints you want to collect from. + +1. Get the tarball for your platform from the [Redis Download Center](https://cloud.redis.io/#/rlec-downloads), under **Modules, tools and integrations**. + + Take the `radar-agent-fips-` build only if you require Federal Information Processing Standards (FIPS) 140-3. It refuses to start unless FIPS 140-3 mode is active in its runtime. + +
+ +2. Extract the archive and confirm the version. + + ```bash + tar -xzf radar-agent--linux-amd64.tar.gz + cd radar-agent--linux-amd64 + ./radar-agent version + ``` + + The agent must report version `1.0.0` or newer. Radar rejects anything older. + +
+ +3. Create the `mcm` service identity the unit runs as. + + Skip this step if the host already runs Radar from the RPM, which creates `mcm` for you. + + ```bash + sudo groupadd --system mcm + sudo useradd --system --gid mcm --home-dir / --no-create-home \ + --shell /sbin/nologin --comment "Radar service identity" mcm + ``` + +
+ +4. Install the binary, the unit, and the environment file, then create the state directory. + + ```bash + sudo install -d -m 0755 /usr/libexec/mcm + sudo install -o root -g root -m 0755 radar-agent /usr/libexec/mcm/radar-agent + sudo install -d -o root -g mcm -m 0750 /etc/radar-agent + sudo install -o root -g mcm -m 0640 systemd/radar-agent.env /etc/radar-agent/radar-agent.env + sudo install -o root -g root -m 0644 systemd/radar-agent.service /usr/lib/systemd/system/ + sudo install -d -o mcm -g mcm -m 0700 /var/lib/radar-agent + sudo systemctl daemon-reload + ``` + + `/var/lib/radar-agent` holds runtime state. Create it now, because a managed agent writes to it during activation, before the service first starts. If you install the binary elsewhere, update the paths in the unit. + +Run every agent command as the service identity, as `sudo -u mcm /usr/libexec/mcm/radar-agent `. + +## Set up a managed agent + +1. In Radar, go to **Settings > Agents** and select **Activate managed agent**. + + Radar shows an activation command and a daemon command. + + {{The Activate managed agent dialog, showing the activation command and the daemon command}} + +
+ +2. Copy the whole activation command from the dialog, then run it on the agent host as the service identity. + + Keep every argument the dialog generated. On Redis Cloud, the dialog adds `--tenant-activation-id`, a short-lived handle bound to your tenant, and the agent gRPC service rejects an activation that omits it. A self-managed install doesn't generate one. + + Replace the endpoint and the agent name. The endpoint is your deployment's public agent gRPC host and port. The dialog shows a placeholder, and the public port isn't necessarily `9443`. + + ```bash + sudo -u mcm /usr/libexec/mcm/radar-agent activate \ + --endpoint : \ + --state-dir /var/lib/radar-agent \ + --display-name \ + --tenant-activation-id + ``` + + When the dialog shows a **Start before** time, run the command before it. The command prints an activation code and waits for approval. You use that code to identify this host in Radar. + +
+ +3. In Radar, find the request under **Pending activations**, confirm the activation code matches, and select **Approve**. + + {{The Agents tab, showing pending activations with Approve and Deny actions above the registered agents list}} + + The activation expires 15 minutes after the command prints the code, so approve it while the command is still waiting. + +
+ +4. Enter the Redis Software or Redis Open Source connection details in the approval form, then select **Confirm approval**. + + Radar stores these credentials and sends them to the agent. Entering the details doesn't submit the approval; **Confirm approval** does. + + Wait for the agent to print `Activation approved; managed credential stored.` before you continue. The daemon needs that credential to start. + +
+ +5. Set the daemon arguments and start the service. + + Edit `/etc/radar-agent/radar-agent.env` and replace the default `RADAR_AGENT_DAEMON_ARGS` line with: + + ```bash + RADAR_AGENT_DAEMON_ARGS=--managed --state-dir /var/lib/radar-agent --metrics-addr 127.0.0.1:9090 + ``` + + `--metrics-addr` is optional. It exposes the agent's health and metrics endpoints on the address you give it. + + ```bash + sudo systemctl enable --now radar-agent.service + ``` + +To change an agent's sources later, go to **Settings > Agents**, find the agent under **Registered agents**, and select **Edit connections**. + +{{< note >}} +Managed mode stores the credential it was issued in `/var/lib/radar-agent/agent-key.json`. Keep that file readable only by its owner. The configuration cache Radar writes alongside it holds no secrets. +{{< /note >}} + +## Set up a static agent + +1. In Radar, go to **Settings > Agents** and select **Provision static agent**. + + Radar returns an agent ID and a one-time access token in the form `.`. Copy both now, because Radar shows the token only once. + + Manage these tokens later under **Settings > Access keys**. + + {{The Access keys tab, listing credential keys with their creation date, last use, and Revoke action}} + +
+ +2. Generate one universally unique identifier (UUID) for each Redis source you plan to collect from. + + ```bash + uuidgen + ``` + +
+ +3. Copy the example configuration from the archive, fill it in, and install it. + + ```bash + cp examples/static-agent.yaml config.yaml + ``` + + Set the agent ID, the token, and one UUID per source. See [Configuration reference](#configuration-reference) for every setting. Then install it with the ownership the service expects. + + ```bash + sudo install -o root -g mcm -m 0640 config.yaml /etc/radar-agent/config.yaml + ``` + +
+ +4. Validate the configuration. + + ```bash + sudo -u mcm /usr/libexec/mcm/radar-agent validate --config /etc/radar-agent/config.yaml + ``` + +
+ +5. Create the redaction salt. + + The example configuration turns redaction on and reads the salt from `/var/lib/radar-agent/redaction-salt`. The agent reads that file and doesn't create it, so generate it once before the first collection. + + ```bash + sudo -u mcm sh -c 'umask 077 && openssl rand -hex 32 > /var/lib/radar-agent/redaction-salt' + ``` + + Keep the same salt across restarts and upgrades. A new salt changes what existing values redact to, so don't overwrite it if you repeat these steps. + +
+ +6. Collect from every source and print a redacted summary without submitting to Radar. + + ```bash + sudo -u mcm /usr/libexec/mcm/radar-agent dry-run --config /etc/radar-agent/config.yaml + ``` + +
+ +7. Submit one collection to confirm the connection to Radar works. + + ```bash + sudo -u mcm /usr/libexec/mcm/radar-agent once --config /etc/radar-agent/config.yaml + ``` + + Radar creates each source the first time it receives data from that source, and uses your `name` value as the display label when that value is valid. + +
+ +8. Start the service. + + The default `RADAR_AGENT_DAEMON_ARGS` in `/etc/radar-agent/radar-agent.env` already points at `/etc/radar-agent/config.yaml`. To expose health and metrics, add `--metrics-addr 127.0.0.1:9090` to that line. + + ```bash + sudo systemctl enable --now radar-agent.service + ``` + +{{< note >}} +Don't also add a static agent's sources as regular Radar connections. In static mode the endpoint and credential values belong only in the agent's YAML file. +{{< /note >}} + +### Configuration reference + +Static mode uses a single YAML file. Managed mode doesn't. + +| Setting | Description | +|---|---| +| `agent.id` | The agent ID Radar returned when you provisioned the agent. It must match the identity bound to the token, or Radar denies every submission. | +| `agent.version` | Optional. Defaults to the version of the installed binary. | +| `radar.endpoint` | The Radar agent endpoint, as `host:port`. | +| `radar.agent_key` | The one-time token, as `.`. | +| `radar.tls.ca_file` | Optional. A PEM bundle used to verify Radar's certificate, replacing the host's system roots. | +| `radar.tls.server_name` | Optional. Overrides the certificate name the agent verifies. | +| `redaction.enabled` | Whether the agent redacts values in the payloads it submits. Enabled by default. | +| `redaction.salt_file` | The salt file the agent uses so a given value redacts to the same result on every collection. | +| `collection.interval` | How often the agent collects when running as a daemon. | +| `collection.timeout` | How long a single collection can run. | +| `sources[].id` | The UUID you generated for this source. | +| `sources[].name` | A name for the source. Radar uses it as the display label. | +| `sources[].type` | Either `redis_enterprise` for Redis Software or `redis_oss` for Redis Open Source. | + +A `redis_enterprise` source takes `base_url`, `username`, and `password`. To collect from a cluster running an older Redis Software version, set `old_version_compatibility.enabled` to `true`. + +A `redis_oss` source takes `host`, `port`, and `password`. Set `username` only if you connect as an access control list (ACL) user. + +Each source type takes a different TLS setting: `tls.skip_verify` for a `redis_enterprise` source, and `tls.enabled` for a `redis_oss` source. Neither one affects the agent's connection to Radar, which `radar.tls` controls. + +To keep secrets out of the file, reference environment variables instead of literal values. + +### Collect from an isolated network + +When the agent host can't reach Radar at all, collect and submit in two steps from different hosts. Install the agent on both hosts, and give each one only the configuration it needs. `export` requires your source credentials and no Radar token, and `submit-export` requires the Radar endpoint and token and no sources. Use the same `agent.id` in both files. + +This keeps your source credentials on the collector, which is the custody benefit static mode exists for. + +On the collector, the sources and the redaction salt: + +```yaml +agent: + id: "" + +redaction: + enabled: true + salt_file: "/var/lib/radar-agent/redaction-salt" + +sources: + - id: "" + name: "" + type: redis_enterprise + base_url: "https://:9443" + username: "" + password: "" +``` + +On the submission host, the Radar endpoint and token: + +```yaml +agent: + id: "" + +radar: + endpoint: ":" + agent_key: "." +``` + +1. On the host that can reach your Redis sources, collect to a file. + + ```bash + sudo -u mcm /usr/libexec/mcm/radar-agent export --config /etc/radar-agent/config.yaml --output telemetry.json + ``` + +
+ +2. Move the file to a host that can reach Radar, then submit it. + + ```bash + sudo -u mcm /usr/libexec/mcm/radar-agent submit-export --config /etc/radar-agent/config.yaml --input telemetry.json + ``` + +The exported file holds sanitized telemetry only. It never contains your Radar token or your source credentials. Each configuration file does hold secrets for its own half, so protect both hosts. + +## Monitor and secure the agent + +Every agent appears in Radar under **Settings > Agents** and in the **Connected agents** list on the Connections page. Radar shows each agent's mode, platform, version, and last heartbeat, along with the combined health of the sources it collects from. + +{{The Connections page, with the Connected agents list showing each agent's mode, platform, version, and status}} + +To expose health and metrics endpoints on the agent host, pass `--metrics-addr` when you start the daemon: + +- `GET /healthz` returns a health snapshot: `200` when the agent is healthy, `503` when a source is failing. +- `GET /metrics` returns per-source collection, submission, and failure counters in Prometheus format. + +{{< warning >}} +These endpoints are unauthenticated. Bind them to loopback, as in `--metrics-addr 127.0.0.1:9090`, or put a firewall in front of them. +{{< /warning >}} + +The daemon writes a local health snapshot only when you start it with `--health-file`, and the `health` command needs that same path. Add `--health-file /var/lib/radar-agent/health.json` to `RADAR_AGENT_DAEMON_ARGS` in `/etc/radar-agent/radar-agent.env`, restart the service, then read it: + +```bash +sudo -u mcm /usr/libexec/mcm/radar-agent health --health-file /var/lib/radar-agent/health.json +``` + +`--metrics-addr` serves health over HTTP but doesn't write this file. Use `journalctl` for the agent's logs and `systemctl` to restart the service. + +Both `/etc/radar-agent/config.yaml` and `/var/lib/radar-agent/agent-key.json` hold secrets, so restrict them to their owner. Never set `tls.insecure_skip_verify` outside local development, because it turns off certificate verification. To block an agent, revoke its key under **Settings > Access keys**. Revoking takes effect centrally, and the agent can no longer connect. + +Source passwords and the agent's token are redacted from logs, diagnostics, health output, error messages, and export bundles. + +## Upgrade or remove the agent + +To upgrade, get the new tarball, verify it, and replace the binary in place. Your configuration and environment file are untouched. If you run a static agent whose configuration file holds both source and Radar credentials, revalidate it before restarting: + +```bash +sudo -u mcm /usr/libexec/mcm/radar-agent validate --config /etc/radar-agent/config.yaml +sudo systemctl restart radar-agent.service +``` + +Keep `/etc/radar-agent` and `/var/lib/radar-agent` in place, because the agent needs its state to stay registered. + +Radar enforces a version policy on every request. An agent older than the minimum supported version is rejected until you upgrade it. An agent newer than the Radar deployment supports is also rejected, and Radar asks for a server upgrade instead. + +If Radar's database is reset, activate the managed agent again. Stop the service before you clear the managed registration state. Recreate the state directory if you removed it, because `/var/lib` is owned by root and `mcm` can't create the directory during activation. + +```bash +sudo systemctl stop radar-agent.service +sudo rm -rf /var/lib/radar-agent +sudo install -d -o mcm -g mcm -m 0700 /var/lib/radar-agent +``` + +Then repeat [Set up a managed agent](#set-up-a-managed-agent) and start the service again. On Redis Cloud, get a fresh tenant activation handle from the dialog first. + +To stop collecting from this host, turn off the service and delete its configuration and state. + +```bash +sudo systemctl disable --now radar-agent.service +sudo rm -rf /etc/radar-agent /var/lib/radar-agent +``` + +Then delete `/usr/libexec/mcm/radar-agent` and `/usr/lib/systemd/system/radar-agent.service`, and revoke the agent's key in Radar under **Settings > Access keys**. + +## Next steps + +After the agent reports its first collection, its sources appear alongside your other clusters. See [Monitor your fleet]({{< relref "/operate/radar/monitor" >}}). diff --git a/content/operate/radar/connect.md b/content/operate/radar/connect.md index 14c914b074..a6471bc99d 100644 --- a/content/operate/radar/connect.md +++ b/content/operate/radar/connect.md @@ -35,7 +35,7 @@ Connect Redis Software clusters and Redis Open Source instances that you run you For every connection you need: - **Credentials for the cluster or instance.** Radar uses the same management interface you do, so it needs an account there. Read access is enough. -- **Network access from Radar to the source.** Radar connects outbound. Nothing needs to connect back to Radar, so no inbound rule is required on the Radar host. +- **Network access from Radar to the source.** Radar connects outbound. Nothing needs to connect back to Radar, so no inbound rule is required on the Radar host. If Radar can't reach a cluster directly, install an agent inside that network instead. See [Connect clusters with an agent]({{< relref "/operate/radar/agent" >}}). ### Connect a Redis Software cluster diff --git a/content/operate/radar/install.md b/content/operate/radar/install.md index 451b0f24bc..8af57907f4 100644 --- a/content/operate/radar/install.md +++ b/content/operate/radar/install.md @@ -39,7 +39,7 @@ What you have to do differs by method, so each install method below ends with it All three are supported and built from the same release. You can install any of them on a host with no internet access. See [Install on an air-gapped host](#install-on-an-air-gapped-host). -Get the RPM from the [Redis Download Center](https://cloud.redis.io/#/rlec-downloads), under **Modules, tools and integrations**. Get the container images from Docker Hub, and the Helm chart. +Get the RPM from the [Redis Download Center](https://cloud.redis.io/#/rlec-downloads), under **Modules, tools and integrations**. Get the container images from Docker Hub, and the Helm chart from the Redis Helm repository at `https://helm.redis.io/radar`. ## Before you start @@ -51,7 +51,7 @@ Before you install: ### PostgreSQL -For production, set up your own external, managed [PostgreSQL](https://www.postgresql.org/docs/) database before you install Radar. You need to provision, back up, and tune it yourself, since Radar only connects to it and creates the roles and schema it needs on startup. +Radar requires PostgreSQL 16 or later. Redis tests Radar against PostgreSQL 16 and 18. For production, set up your own external, managed [PostgreSQL](https://www.postgresql.org/docs/) database before you install Radar. You need to provision, back up, and tune it yourself, since Radar only connects to it and creates the roles and schema it needs on startup. For evaluation or testing, you can skip that step: the Helm chart and the Compose bundle can each start a PostgreSQL container for you, though neither is hardened for production use. @@ -83,11 +83,11 @@ In that line, both `enabled` and `required` should read `true`. Search your logs ### Package and service names -Radar's packages, services, and paths use an `mcm` prefix. The RPM is named `mcm`, its services are `mcm-api` and `mcm-worker`, and its configuration lives in `/etc/mcm/`. The Docker Compose bundle's container images are `mcm-app`, `mcm-worker`, and `mcm-migrate`; the Helm chart's default image repositories use a `radar-` prefix instead. +Radar's services and paths use an `mcm` prefix. The RPM is named `radar`, its services are `mcm-api` and `mcm-worker`, and its configuration lives in `/etc/mcm/`. Container images use a `radar-` prefix in both the Docker Compose bundle and the Helm chart: `radar-app`, `radar-worker`, and `radar-migrate`. ## Install on RHEL with the RPM -The RPM installs native binaries and needs no container runtime. It also installs the `mcmctl` diagnostics command. +The RPM installs native binaries and needs no container runtime. It also installs the `radar` diagnostics command. {{< note >}} The RPM listens only on loopback by default. A successful RPM install is not yet reachable from any other machine until you put a proxy in front of it. @@ -96,11 +96,10 @@ The RPM listens only on loopback by default. A successful RPM install is not yet 1. Install the package. ```bash - sha256sum -c SHA256SUMS - sudo dnf install -y ./mcm--.x86_64.rpm + sudo dnf install -y ./radar--.x86_64.rpm ``` - The package depends on RHEL's `postgresql-server`, so `dnf` installs PostgreSQL software if it is absent. It does not create or start a database. + The package requires `postgresql-server` and `postgresql-contrib` version 16 or later, from the `postgresql:16` module stream. Enable that stream before you install, since `dnf` resolves the dependency only from a stream you have already enabled. Installing the package never creates, starts, or tunes a database.
@@ -143,10 +142,10 @@ The RPM listens only on loopback by default. A successful RPM install is not yet 4. Check the configuration. ```bash - sudo mcmctl doctor + sudo radar doctor ``` - Before the first start, `mcmctl doctor` reports that schema migration has not run yet. That is expected; the configuration and database connectivity checks should still pass. + Before the first start, `radar doctor` reports that schema migration has not run yet. That is expected; the configuration and database connectivity checks should still pass.
@@ -165,7 +164,7 @@ The RPM listens only on loopback by default. A successful RPM install is not yet ```bash curl -fsS http://127.0.0.1:8080/healthz/ready - sudo mcmctl doctor + sudo radar doctor ```
@@ -195,10 +194,10 @@ The RPM listens only on loopback by default. A successful RPM install is not yet ```bash sudo systemctl restart mcm-api.service - sudo mcmctl doctor + sudo radar doctor ``` - `mcmctl doctor` checks runtime health through the configured address. If it reports a runtime-health failure after you change the listen address, confirm the service bound to the interface you expected and that the proxy forwards to the same address. + `radar doctor` checks runtime health through the configured address. If it reports a runtime-health failure after you change the listen address, confirm the service bound to the interface you expected and that the proxy forwards to the same address. {{< warning >}} Do not expose Radar directly on a public interface. Terminate TLS and apply access controls at the edge. @@ -210,6 +209,15 @@ The RPM listens only on loopback by default. A successful RPM install is not yet A production install has four parts you supply: the PostgreSQL connection, the credential encryption key, image pull access, and an external access path. +Add the Redis Helm repository first. The commands below install from it. + +```bash +helm repo add radar https://helm.redis.io/radar +helm repo update radar +``` + +If you install from a source checkout or from an air-gapped bundle instead, substitute `./helm/radar` or the bundle's `radar-*.tgz` file for `radar/radar` in the `helm install` commands below. + 1. Create the database secret. Store the database connection string in a secret. ```bash @@ -243,7 +251,7 @@ A production install has four parts you supply: the PostgreSQL connection, the c 3. Install the chart. ```bash - helm install radar ./helm/radar \ + helm install radar radar/radar \ --namespace radar \ --create-namespace \ --set database.existingSecret=radar-db \ @@ -266,13 +274,15 @@ A production install has four parts you supply: the PostgreSQL connection, the c - name: registry-creds ``` - **For OpenShift**, use the OpenShift values file instead, which lets OpenShift assign namespace-scoped user IDs and switches the external access path from an ingress to a route. + **For OpenShift**, use the OpenShift values file instead, which lets OpenShift assign namespace-scoped user IDs and switches the external access path from an ingress to a route. The file ships inside the chart, so extract it first. ```bash - helm install radar ./helm/radar \ + helm pull radar/radar --untar --untardir . + + helm install radar radar/radar \ --namespace radar \ --create-namespace \ - -f ./helm/radar/values-openshift.yaml \ + -f ./radar/values-openshift.yaml \ --set database.existingSecret=radar-db \ --set credentials.existingSecret=radar-credentials \ --set route.host=radar.apps.example.com @@ -331,7 +341,7 @@ The Compose bundle runs Radar on a single host. It ships the container images, t 1. Load the images. ```bash - sha256sum -c SHA256SUMS + sha256sum -c radar-v.SHA256SUMS docker load -i images.tar.gz ``` @@ -364,12 +374,12 @@ Air-gapped installation uses the same three methods. Transfer the release artifacts to the target host or to an offline repository it can reach, then verify them: ```bash -sha256sum -c SHA256SUMS +sha256sum -c radar-v.SHA256SUMS ``` | Method | What to transfer | How it installs | |---|---|---| -| RPM | The `.rpm`, `SHA256SUMS`, and the dependency closure, including `postgresql-server` if the host has no offline PostgreSQL | `dnf install` from the local file | +| RPM | The `.rpm` and the dependency closure, including `postgresql-server` if the host has no offline PostgreSQL | `dnf install` from the local file | | Helm | `images.tar.gz`, the packaged chart, and the bundled values file | `docker load` the images onto the nodes, then install the chart | | Docker Compose | `images.tar.gz` and the Compose files | `docker load`, then `docker compose up` | diff --git a/content/operate/radar/release-notes/2026-9-5.md b/content/operate/radar/release-notes/2026-9-5.md new file mode 100644 index 0000000000..6ad9beae29 --- /dev/null +++ b/content/operate/radar/release-notes/2026-9-5.md @@ -0,0 +1,29 @@ +--- +title: Redis Radar release notes 2026.9.5 +alwaysopen: false +categories: +- docs +- operate +- radar +description: Connect clusters that Radar can't reach directly by installing an agent. +linkTitle: 2026.9.5 +weight: 9 +tags: +- self-managed +--- + +Radar can now collect from clusters it can't reach directly. You install an agent on a host inside the network that holds them, and the agent opens an outbound connection to Radar. + +This is a Short-Term Support (STS) release. See [Self-managed releases]({{< relref "/operate/radar/release-notes" >}}#self-managed-releases) for more details. + +## Highlights + +### Connect clusters with an agent + +- Collect from **Redis Software** and **Redis Open Source** clusters behind a firewall, in a private subnet, or on a segmented network. Radar needs no inbound access to your network. +- Choose between two modes. **Managed** agents receive source credentials from Radar, so you add and change sources from the Radar UI. **Static** agents read their sources from a file on the agent host, so those credentials never leave it. +- Collect from a fully isolated network by exporting to a file on one host and submitting it from another. +- Install from standalone agent packages for Linux on amd64 and arm64, including Federal Information Processing Standards (FIPS) 140-3 builds. +- Track every agent under **Settings > Agents** and in the **Connected agents** list on the Connections page, with its mode, platform, version, and last heartbeat. + +Radar accepts agent connections on its agent gRPC endpoint, which isn't enabled on every Radar deployment. See [Connect clusters with an agent]({{< relref "/operate/radar/agent" >}}). diff --git a/content/operate/radar/release-notes/_index.md b/content/operate/radar/release-notes/_index.md index cdc719a697..1b79f1cd66 100644 --- a/content/operate/radar/release-notes/_index.md +++ b/content/operate/radar/release-notes/_index.md @@ -34,6 +34,7 @@ STS releases receive security and bug fixes for 6 months after release. LTS rele Install a new release when you're ready to upgrade. See [Install Radar]({{< relref "/operate/radar/install" >}}). -| Release | Support track | What changed | -|--------------------------------------------------------------------|---------------|------------------| -| [2026.9.2]({{< relref "/operate/radar/release-notes/2026-9-2" >}}) | STS | Initial release. | +| Release | Support track | What changed | +|--------------------------------------------------------------------|---------------|--------------------------------------| +| [2026.9.5]({{< relref "/operate/radar/release-notes/2026-9-5" >}}) | STS | Connect clusters with an agent. | +| [2026.9.2]({{< relref "/operate/radar/release-notes/2026-9-2" >}}) | STS | Initial release. | diff --git a/content/operate/rc/api/api-reference/openapi.json b/content/operate/rc/api/api-reference/openapi.json index 92959c0e46..61f176f214 100644 --- a/content/operate/rc/api/api-reference/openapi.json +++ b/content/operate/rc/api/api-reference/openapi.json @@ -91,7 +91,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_1", + "operationId": "proxyDataIntegrationWorkspace_3", "parameters": [ { "name": "subscriptionId", @@ -161,7 +161,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_4", + "operationId": "proxyDataIntegrationWorkspace_2", "parameters": [ { "name": "subscriptionId", @@ -232,7 +232,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace", + "operationId": "proxyDataIntegrationWorkspace_1", "parameters": [ { "name": "subscriptionId", @@ -303,7 +303,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_2", + "operationId": "proxyDataIntegrationWorkspace_4", "parameters": [ { "name": "subscriptionId", @@ -374,7 +374,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_3", + "operationId": "proxyDataIntegrationWorkspace", "parameters": [ { "name": "subscriptionId", @@ -447,7 +447,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_6", + "operationId": "proxyDataIntegrationWorkspace_8", "parameters": [ { "name": "subscriptionId", @@ -517,7 +517,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_9", + "operationId": "proxyDataIntegrationWorkspace_7", "parameters": [ { "name": "subscriptionId", @@ -588,7 +588,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_5", + "operationId": "proxyDataIntegrationWorkspace_6", "parameters": [ { "name": "subscriptionId", @@ -659,7 +659,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_7", + "operationId": "proxyDataIntegrationWorkspace_9", "parameters": [ { "name": "subscriptionId", @@ -730,7 +730,7 @@ ], "summary": "Proxy a Data Integration workspace request", "description": "Forwards the request to the Data Integration workspace owned by the specified subscription. Path under `data-integration-workspace/**` is forwarded as-is to the Cloud RDI service.", - "operationId": "proxyDataIntegrationWorkspace_8", + "operationId": "proxyDataIntegrationWorkspace_5", "parameters": [ { "name": "subscriptionId", diff --git a/content/operate/rs/8.0/monitoring/v1_monitoring.md b/content/operate/rs/8.0/monitoring/v1_monitoring.md index 3abb6bf47f..2ad073821e 100644 --- a/content/operate/rs/8.0/monitoring/v1_monitoring.md +++ b/content/operate/rs/8.0/monitoring/v1_monitoring.md @@ -142,4 +142,4 @@ To send cluster and database alerts by email: 1. In **Configuration** for the database, click **Edit**. 1. Select the **Alerts** section to open it. 1. Select **Receive email alerts** and click **Save**. -1. In **Access Control**, select the [database and cluster alerts]({{< relref "/operate/rs/8.0/security/access-control/manage-users" >}}) that you want each user to receive. +1. In **Access Control**, select the [database and cluster alerts]({{< relref "/operate/rs/8.0/security/access-control/create-users#add-users" >}}) that you want each user to receive. diff --git a/content/operate/rs/8.0/references/alerts/_index.md b/content/operate/rs/8.0/references/alerts/_index.md index 89a89ad5fd..7eb283c1f3 100644 --- a/content/operate/rs/8.0/references/alerts/_index.md +++ b/content/operate/rs/8.0/references/alerts/_index.md @@ -60,4 +60,4 @@ To send cluster and database alerts by email: 1. In **Configuration** for the database, click **Edit**. 1. Select the **Alerts** section to open it. 1. Select **Receive email alerts** and click **Save**. -1. In **Access Control**, select the [database and cluster alerts]({{< relref "/operate/rs/8.0/security/access-control/manage-users" >}}) that you want each user to receive. +1. In **Access Control**, select the [database and cluster alerts]({{< relref "/operate/rs/8.0/security/access-control/create-users#add-users" >}}) that you want each user to receive. diff --git a/content/operate/rs/monitoring/v1_monitoring.md b/content/operate/rs/monitoring/v1_monitoring.md index 7001b7254a..cb6fe7ab9b 100644 --- a/content/operate/rs/monitoring/v1_monitoring.md +++ b/content/operate/rs/monitoring/v1_monitoring.md @@ -141,4 +141,4 @@ To send cluster and database alerts by email: 1. In **Configuration** for the database, click **Edit**. 1. Select the **Alerts** section to open it. 1. Select **Receive email alerts** and click **Save**. -1. In **Access Control**, select the [database and cluster alerts]({{< relref "/operate/rs/security/access-control/manage-users" >}}) that you want each user to receive. +1. In **Access Control**, select the [database and cluster alerts]({{< relref "/operate/rs/security/access-control/create-users#add-users" >}}) that you want each user to receive. diff --git a/content/operate/rs/references/alerts/_index.md b/content/operate/rs/references/alerts/_index.md index 1cb92ab0f4..4f61c31155 100644 --- a/content/operate/rs/references/alerts/_index.md +++ b/content/operate/rs/references/alerts/_index.md @@ -59,4 +59,4 @@ To send cluster and database alerts by email: 1. In **Configuration** for the database, click **Edit**. 1. Select the **Alerts** section to open it. 1. Select **Receive email alerts** and click **Save**. -1. In **Access Control**, select the [database and cluster alerts]({{< relref "/operate/rs/security/access-control/manage-users" >}}) that you want each user to receive. +1. In **Access Control**, select the [database and cluster alerts]({{< relref "/operate/rs/security/access-control/create-users#add-users" >}}) that you want each user to receive. diff --git a/content/operate/rs/release-notes/rs-8-2-releases/rs-8-2-0-78.md b/content/operate/rs/release-notes/rs-8-2-releases/rs-8-2-0-78.md index 7d7d554cb5..5f27180300 100644 --- a/content/operate/rs/release-notes/rs-8-2-releases/rs-8-2-0-78.md +++ b/content/operate/rs/release-notes/rs-8-2-releases/rs-8-2-0-78.md @@ -6,7 +6,7 @@ categories: - operate - rs compatibleOSSVersion: Redis 8.6.2, 8.4.0, 8.2.1, 8.0.2, 7.4.3, 7.2.7, 6.2.13 -description: Bug fixes for minor version upgrades, shard placement, LDAP client authentication, database connectivity, DMC proxy connection cleanup, module configuration, and support package collection. Internal fixes and improvements. +description: Bug fixes for minor version upgrades, shard placement, LDAP client authentication, database connectivity, DMC proxy connection cleanup, internode encryption certificates, Auto Tiering database resizing, Google Cloud Storage backups, crdb-cli certificate-based authentication, metrics export, module configuration, and support package collection. Internal fixes and improvements. linkTitle: 8.2.0-78 (September 2026) weight: 78 --- @@ -25,6 +25,16 @@ This version offers: - Bug fixes for database connectivity and DMC proxy connection cleanup +- Bug fix for applying custom internode encryption certificates + +- Bug fix for resizing a database with Auto Tiering enabled + +- Bug fix for Google Cloud Storage backup configuration + +- Bug fix for `crdb-cli` certificate-based authentication + +- Bug fixes for metrics export and Prometheus ingestion + - Bug fixes for module configuration and support package collection - Internal fixes and improvements @@ -61,16 +71,28 @@ The following table shows which Redis modules are compatible with each Redis dat ### Resolved issues +- RS149489: Fixed an issue where Redis Software exported metrics samples that shared a timestamp but carried different values, which caused Prometheus to reject them with an ingestion error. + - RS192976: Fixed an issue where a master shard could not be reached while the shard placement blueprint was applied through migrations and failovers. +- RS196137: Fixed an issue where the Cluster Manager did not send the required `private_key` field when configuring Google Cloud Storage backups, which caused the backup configuration to fail. + - RS197092: Fixed an issue where databases became unreachable after a quorum node went down. - RS197402: Fixed an issue where LDAP client authentication failed after a period of time. +- RS205561: Fixed an issue where v2 metrics were exported with a duplicate cluster label, which caused Grafana dashboards based on v2 metrics to show no data. + - RS206926: Fixed an issue where the DMC proxy could fail an assertion while cleaning up an SSL client disconnection over IPv6. +- RS208996: Fixed an issue where applying a custom internode encryption certificate restarted the heartbeat daemon and made the cluster configuration store and the management API on port 9443 unavailable cluster-wide. + - RS210365: Fixed an issue where removing module arguments from a database configuration did not update the `redis.conf` file on the shards. +- RS212043: Fixed an issue where `crdb-cli` did not use the configured client key when certificate-based authentication was enabled. + +- RS212448: Fixed an issue where resizing a database with Auto Tiering enabled did not complete after a cluster upgrade, which left the database in a pending state and caused subsequent requests to return a busy error. + - RS213492: Fixed an issue where shards loaded slowly from persistence during a minor version upgrade of a non-replicated database, which extended the time the database spent in a loading state. - RS215377: Fixed an issue where `rladmin cluster debug_info` silently omitted nodes whose collection failed, which produced a support package that appeared complete. diff --git a/static/images/radar/activate-managed-agent.png b/static/images/radar/activate-managed-agent.png new file mode 100644 index 0000000000..9f91c68327 Binary files /dev/null and b/static/images/radar/activate-managed-agent.png differ diff --git a/static/images/radar/connections-with-agents.png b/static/images/radar/connections-with-agents.png new file mode 100644 index 0000000000..ab6e1f3ea4 Binary files /dev/null and b/static/images/radar/connections-with-agents.png differ diff --git a/static/images/radar/settings-access-keys.png b/static/images/radar/settings-access-keys.png new file mode 100644 index 0000000000..1f0f904421 Binary files /dev/null and b/static/images/radar/settings-access-keys.png differ diff --git a/static/images/radar/settings-agents.png b/static/images/radar/settings-agents.png new file mode 100644 index 0000000000..66a0cfa51d Binary files /dev/null and b/static/images/radar/settings-agents.png differ