Radar: connect with agents

[kaitlynmichael]

Note

Low Risk
Documentation-only changes with no application code, credentials handling, or deployment logic modified in this PR.

Overview
Documents Radar agents for Redis Software and Redis Open Source when Radar cannot reach clusters directly (firewalls, private subnets, air-gapped paths).

Adds agent.md, a new operate guide that explains managed vs static credential modes, tarball install and systemd setup, managed activation and static YAML provisioning, private CA trust, isolated-network export/submit-export, monitoring (/healthz, /metrics), security notes, and upgrade/removal. It references new UI screenshots under images/radar/.

Updates _index.md and connect.md so network reachability is called out as a setup requirement, with links to the agent page when direct outbound access from Radar is not possible.

^{Reviewed by Cursor Bugbot for commit 2bf5eaa. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

DOC-7023

[github-actions]

Staging links:
https://redis.io/docs/staging/DOC-7023/operate/radar/
https://redis.io/docs/staging/DOC-7023/operate/radar/agent
https://redis.io/docs/staging/DOC-7023/operate/radar/agent/
https://redis.io/docs/staging/DOC-7023/operate/radar/connect/

[github-actions]

🧠 Redis Memory

Found 9 related items from repository history (1 new this commit):

• Commit — remove connection

  remove connection

• Commit — review feedback

  review feedback

• Commit — Update content/operate/radar/connect.md

  Update content/operate/radar/connect.md

• Commit — add screenshots

  add screenshots

• Commit — first use edit

  first use edit

• PR — Radar docs

• Commit — Revalidate Radar pages against v0.3.21

  Revalidate Radar pages against v0.3.21

• Commit — edits and questions

  edits and questions

• Commit — add in missing info 🆕

  add in missing info

Memory updated at 2bf5eaa

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 9251adf. Configure here.}

[dwdougherty]

Apart from the Bugbot issue and the TODO you have in a comment, the language looks good to me. One nitpick: the first image, activate-managed-agent.png could do with a bit of trimming.

[gnesher]

For Cloud deployments, this example drops the required --tenant-activation-id argument. Radar already generates a short-lived, tenant-bound handle when the administrator opens Activate managed agent, and the UI includes it in the copied activation command. The Cloud gRPC service rejects activation without that handle, so following this example will fail before a pending request appears.

Please instruct readers to copy the entire activation command from the dialog, preserve all generated arguments (including --tenant-activation-id when present), replace the endpoint and agent-name placeholders, and run it as the mcm service user before the displayed deadline.

Also, the dialog currently displays an endpoint placeholder, not the actual deployment endpoint. Readers need the public Agent gRPC hostname and port; 9443 is not necessarily the public port. Automatically populating that endpoint would be a separate Radar UI/API/configuration improvement. The tenant-handle generation and enforcement already exist; the fix for the missing flag here is in the documentation.

[gnesher]

Five documentation-only follow-ups from checking the agent setup instructions against Radar’s current implementation.

[gnesher]

[P1] Create the static agent's redaction salt before the first collection

The bundled examples/static-agent.yaml enables redaction and sets redaction.salt_file to /var/lib/radar-agent/redaction-salt, but these instructions only create the directory. The runtime reads an existing salt file; it does not generate one. Following the guide therefore passes validate and then fails here with read redaction salt file: ... no such file or directory (reproduced against the current Radar code).

Please add a one-time step before dry-run to generate a nonempty random salt at the configured path, owned by mcm with mode 0600. Tell readers to retain the same salt across restarts and upgrades rather than overwrite it when repeating installation steps. This can be fixed in the guide without changing the agent.

[gnesher]

[P2] Complete approval and wait for credential storage before starting the service

The initial Approve action opens the connection-details form; entering those details does not submit the approval. The UI has a separate Confirm approval button. The agent then polls for approval and writes its credential before printing Activation approved; managed credential stored.

Please end this step with: select Confirm approval, then wait for that terminal success message before proceeding to start the service. This makes the UI-to-terminal handoff explicit and ensures the managed daemon has the credential file it needs.

[gnesher]

[P2] Configure the health file on both the daemon and the health command

The documented bare radar-agent health command exits with --health-file is required (reproduced). The daemon also only writes a local health snapshot when started with --health-file; neither daemon example currently includes it. --metrics-addr alone exposes HTTP health/metrics but does not create the local JSON file.

Please either direct readers to the configured /healthz endpoint, or show both sides: add --health-file /var/lib/radar-agent/health.json to RADAR_AGENT_DAEMON_ARGS, restart the service, and read it with sudo -u mcm /usr/libexec/mcm/radar-agent health --health-file /var/lib/radar-agent/health.json.

[gnesher]

[P2] Document separate collection and submission configurations for offline use

Both commands accept --config, but they do not require the same credentials. The current CLI deliberately uses collection-only validation for export (source configuration required, no Radar token required) and submission-only validation for submit-export (Radar endpoint/token required, no source configuration required).

Please show two minimal configurations with matching agent.id: source credentials and the redaction salt on the collector, and Radar endpoint/token on the submission host. Update the preceding instruction to copy the configuration to both hosts accordingly. Saying that both hosts' configurations contain both sets of credentials unnecessarily moves source secrets off the collector and conflicts with the static-mode custody benefit described above. The code already supports this separation.

[gnesher]

[P2] Link reactivation to the complete managed setup procedure

The bare radar-agent activate command fails immediately with --endpoint is required; --state-dir and --display-name are also required, and Cloud needs a fresh tenant activation handle from the UI. Removing /var/lib/radar-agent introduces another missing step: the mcm user cannot recreate that directory under the root-owned /var/lib parent during activation.

Please tell readers to stop the service before clearing managed registration state, recreate the state directory with mcm:mcm ownership and mode 0700 if it was removed, and repeat the complete managed activation/approval procedure before restarting. Linking back to that procedure will avoid maintaining an incomplete second activation command here.