Radar docs - #3803
Conversation
🧠 Redis MemoryFound 8 related items from repository history:
Memory updated at f366377 |
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>
|
|
||
| Adding a cluster to Radar does not change it. Radar reads through the same management interfaces you already use. | ||
|
|
||
| ## What you can connect |
There was a problem hiding this comment.
AWS elasticache and gcp memorystore are also avilable
There was a problem hiding this comment.
Added both, with connection procedures and the IAM/role requirements. Two things to check: I documented them as needing the connector switched on (ELASTICACHE_ENABLED/MEMORYSTORE_ENABLED default to false in the Helm chart) — remove that if they ship enabled. I also only documented the self-managed credential path (access keys / SA key JSON), not AssumeRole or impersonation.
andy-stark-redis
left a comment
andy-stark-redis
left a comment
There was a problem hiding this comment.
I know it's still an early-stage draft but some of this is pretty dense and hard to read (for a human, at any rate). Claude seems to have often done a much better job than this in the past, but with this being a new section, maybe Claude doesn't have much similar material to use as a guide? Anyway, I'd say that it's getting there but probably needs a bit more work before release.
| Two 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" >}}). | ||
| - **For self-managed clusters, Radar shows the last successful collection rather than live state.** Redis Software and Redis Open Source clusters are collected on an interval, so a value is only as fresh as the last time Radar reached that cluster. Radar displays that age alongside the data. |
There was a problem hiding this comment.
This treats "collection" as though it's an established term, but AFAICS it's only mentioned casually on line 16 here. Might be better to explicitly describe it as "state collection" for this page? Also generally quite a dense bit of text.
| - **For self-managed clusters, Radar shows the last successful collection rather than live state.** Redis Software and Redis Open Source clusters are collected on an interval, so a value is only as fresh as the last time Radar reached that cluster. Radar displays that age alongside the data. | |
| - **For self-managed clusters, Radar shows the last successful state collection rather than live state.** The state of Redis Software and Redis Open Source clusters is collected on a regular interval, so a value is only as fresh as the last time Radar checked that cluster. Radar displays the age of the data alongside its values. |
|
|
||
| Radar reads each cluster's own management interface 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. | ||
|
|
||
| Two consequences: |
There was a problem hiding this comment.
I might be getting too pedantic here :-) TBH, I think we probably need a team discussion about how much we want to preserve our previous style and how much we just let it go and accept what AI produces.
| Two consequences: | |
| This approach has two significant consequences: |
| weight: 20 | ||
| --- | ||
|
|
||
| Radar does not find clusters on its own. You add each one, Radar tests the connection, and from then on Radar keeps collecting that source's state. |
There was a problem hiding this comment.
Early comment about style applies here too. Maybe we just don't want to worry about stuff like this.
| Radar does not find clusters on its own. You add each one, Radar tests the connection, and from then on Radar keeps collecting that source's state. | |
| Radar does not find clusters by itself, so you must add each one manually. When you do this, Radar tests the connection, and from then on Radar keeps collecting that source's state automatically. |
|
|
||
| Radar does not find clusters on its own. You add each one, Radar tests the connection, and from then on Radar keeps collecting that source's state. | ||
|
|
||
| Adding a cluster to Radar does not change it. Radar reads through the same management interfaces you already use. |
There was a problem hiding this comment.
| Adding a cluster to Radar does not change it. Radar reads through the same management interfaces you already use. | |
| Adding a cluster to Radar does not change the behavior of that cluster. Radar collects the state data through the same management interfaces you already use. |
| | [Databases](#databases) | Which database, across every cluster? | | ||
| | [Usage](#usage) | How much are you consuming against your limits? | | ||
| | [Alerts](#alerts) | What is your fleet complaining about? | | ||
|
|
There was a problem hiding this comment.
| All the views are read-only. You cannot start, stop, resize, or reconfigure anything from them: you read what your clusters report via Radar, but you must access the cluster itself to take action. | |
| | [Clusters](#clusters) | Which cluster, and what does it look like? | | ||
| | [Databases](#databases) | Which database, across every cluster? | |
There was a problem hiding this comment.
These two questions are a bit odd.
|
|
||
| Shard counts are the exception: they always show a number, because zero shards is a real answer rather than a missing one. | ||
|
|
||
| ## Overview |
There was a problem hiding this comment.
These sections all look very terse - might be worth expanding them unless you're expecting the info to change soon.
|
|
||
| Radar shows the result of the last successful collection, not live state. This applies to every number on every screen. | ||
|
|
||
| Each list carries a **Last Seen** column, and the Overview has a data freshness card, so the age of what you are reading is always on screen next to the value. |
There was a problem hiding this comment.
Usage does not show a table with last seen + the intervals below are not necessarily correct (there are various things that can affect this)
I would say that we aim to read the Usage report once an hour and the rest of the data every 5-15 minutes.
Polling is done using a queue so we can't gurantee the timing, and different cluster versions can decrease collection time below the 5 minutes (which is why I gave a range)
I don't think we need to be very specific about it
| | Running actions | 5 minutes | | ||
| | Usage | 1 hour | | ||
|
|
||
| Your administrator can change these intervals. Collecting more often costs more requests against every cluster in the fleet, so the defaults are deliberately conservative. |
There was a problem hiding this comment.
this is limited to on-prem deployment there's no admin ui to change this, it's part of the k8 deployment script. I would not go into that for now
|
|
||
| Your administrator can change these intervals. Collecting more often costs more requests against every cluster in the fleet, so the defaults are deliberately conservative. | ||
|
|
||
| If a cluster's Last Seen value stops advancing, treat that as a Radar connectivity problem rather than a healthy cluster. Radar keeps showing the last good data it has. |
There was a problem hiding this comment.
That's not correct, there might be any number of cluster problems that can cause it (the cluster is down)
|
|
||
| ## Usage | ||
|
|
||
| The **Usage** view is about consumption against what you are entitled to, rather than health: |
There was a problem hiding this comment.
usage is only used for redis enterprise - other deployments do not appear here
| weight: 40 | ||
| --- | ||
|
|
||
| Radar has two roles, and every user has exactly one of them. People sign in with a local Radar account, through your directory over LDAP, or through your identity provider with SAML SSO. |
There was a problem hiding this comment.
manage access is only relevant for on-prem deployments
|
|
||
| ## Roles | ||
|
|
||
| | Role | Can do | |
There was a problem hiding this comment.
same with roles, etc. when you use cloud it's managed by the sm
| weight: 50 | ||
| --- | ||
|
|
||
| Licenses and certificates expire per cluster, so the more clusters you run, the more likely one of them is close to expiring without anyone noticing. Radar collects both across the whole fleet and lists them by expiry date, so you find out before a customer does. |
There was a problem hiding this comment.
also licenses would generally all expire on the same date
3 participants
No description provided.