Radar docs **DRAFT** - #3803
Conversation
🧠 Redis MemoryFound 3 related items from repository history (1 new this commit):
Memory updated at 66fe9d3 |
Verified the six written pages against release tag v0.3.21 rather than the dev mainline. install.md, manage-access.md, licenses-and-certificates.md, and _index.md needed no changes: the only in-range change to install.md's sources was the LaunchDarkly removal (RED-209582), which the page never documented. connect.md: the three connection procedures described a "Test connection" button that does not exist. The add-connection modal has a single primary action, and the connection test runs inside it, returning before create when the test fails. Corrected the steps, documented the real failure path, and used the actual TLS checkbox label. Also noted that Add connection is now reachable from the top bar as well as the Connections page (RED-212669). monitor.md: documented two shipped behaviors the page did not cover. Fleet memory and ops/sec are now nullable and render as N/A rather than a fabricated zero, with shard counts staying non-nullable because zero shards is a real answer (RED-212614). Redis Cloud database detail has a Force refresh action for on-demand collection (RED-210548). Hugo builds clean, the new anchor resolves, Vale reports 0 errors. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
||
| Teams that run dozens or hundreds of clusters usually track them in a spreadsheet that goes out of date the moment someone adds a cluster. Radar replaces that spreadsheet: it connects to each cluster, collects its state on a schedule, and presents one fleet-wide view across Redis Software, Redis Cloud, and Redis Open Source. | ||
|
|
||
| Radar is a visibility tool first. It reports what your clusters are doing, and adding a cluster to Radar does not change how that cluster runs. You can also do a few fleet-wide tasks from Radar, such as [updating a cluster license]({{< relref "/operate/radar/licenses-and-certificates#update-a-cluster-license" >}}). |
There was a problem hiding this comment.
You can also do a few fleet-wide tasks from Radar - this is incorrect the capability is not enabled
|
|
||
| ## How Radar collects data | ||
|
|
||
| Radar pulls; your clusters do not push. On a schedule, Radar reads each cluster's own management API using credentials you supply, normalizes what it finds, and stores it. A **connector** handles each source type, which is how one fleet view spans products with very different APIs. |
There was a problem hiding this comment.
This isn't entirely correct; we are introducing an Agent deployment soon that will push data to radar (code complete) - and in some cases like Redis Cloud / AWS / GCP we pull data on demand not on sechdule
I'd just skip this for now?
|
|
||
| Two consequences: | ||
|
|
||
| - **Radar shows the last successful collection, not live state.** A value is as fresh as the last time Radar reached that cluster, which Radar displays alongside the data. |
There was a problem hiding this comment.
We can say that for on-prem deployments (Redis Software/Redis OSS) this is a limitation
| - **Radar shows the last successful collection, not live state.** A value is as fresh as the last time Radar reached that cluster, which Radar displays alongside the data. | ||
| - **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" >}}). | ||
|
|
||
| ## Redis Radar and MCM |
There was a problem hiding this comment.
MCM was never a public facing name I wouldn't mention it
No description provided.