You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[NEW] Introduce slot level metrics to Valkey clusterΒ #20
Iβm revisiting the feature proposal we discussed in redis/redis#10472, which aims at providing metrics at the slot level. Despite the substantial effort and detailed discussions back then, we didnβt land this feature. I believe itβs worth reconsidering, given the potential benefits and previous interest.
Sure, metrics seem fine. I don't have strong opinions about it, only that I think fixing the cluster consistency problems is more important than metrics.
I think our big initial play should be cluster overhaul. I think a lot of us want it, and it makes the most compelling sense as the big "next major features".
Reacted by Viktor SΓΆderqvist, Harkrishn Patro and woodgaines
Good to hear back on this thread, hope you all have been doing well.
Where we left-off
In total, there were 3 proposed metrics under CLUSTER SLOT-STATS command group;
key_count
cpu_usec
memory_bytes
Next steps
memory_bytes is the most complex of all, but this shouldn't stop us from implementing the first two metrics to gain some momentum.
I will open two PRs for key_count and cpu_usec in the coming days. These PRs will be based off of the already existing PRs for key_count and cpu_usec under Redis repository.
As for CLUSTER SLOT-STATS command format, below was the latest development we agreed upon. Lengthy discussion and rationale can be found here and here.
Thanks for chiming in. Personally, I'm opposed to CLUSTER INFO. We could perhaps add aggregated information under CLUSTER INFO, but not for the slot level metrics themselves.
Imagine dumping ~16384 slot level metrics under CLUSTER INFO. This would unnecessarily bloat the info string, when the user may have only wanted to check cluster_state:ok.
A new command dedicated for slot level metrics querying, in this case, CLUSTER SLOT-STATS, is more suitable. For reference, below was the latest command format we agreed on.
@kyle-yh-kim Yeah CLUSTER SLOT-STATS. We're a bit overloaded with the forking stuff, new core team, new project, etc. but I think we want this for our next release. There was already a lot of review done and I think it was almost ready to merge. Do you want to bring over your PR?
Activity
madolson commentedon Mar 25, 2024
I fully agree!
madolson commentedon Mar 25, 2024
I've also re-added my favorite creature comfort. @placeholderkv/core-team thoughts?
zuiderkwast commentedon Mar 25, 2024
Sure, metrics seem fine. I don't have strong opinions about it, only that I think fixing the cluster consistency problems is more important than metrics.
zuiderkwast commentedon Mar 25, 2024
redis/redis#11432
madolson commentedon Mar 25, 2024
I think our big initial play should be cluster overhaul. I think a lot of us want it, and it makes the most compelling sense as the big "next major features".
kyle-yh-kim commentedon Mar 26, 2024
Good to hear back on this thread, hope you all have been doing well.
Where we left-off
In total, there were 3 proposed metrics under
CLUSTER SLOT-STATScommand group;key_countcpu_usecmemory_bytesNext steps
memory_bytesis the most complex of all, but this shouldn't stop us from implementing the first two metrics to gain some momentum.I will open two PRs for
key_countandcpu_usecin the coming days. These PRs will be based off of the already existing PRs for key_count and cpu_usec under Redis repository.As for
CLUSTER SLOT-STATScommand format, below was the latest development we agreed upon. Lengthy discussion and rationale can be found here and here.hwware commentedon Mar 27, 2024
It is great, and I prefer to add this feature in CLUSTER INFO.
madolson commentedon Mar 27, 2024
Why cluster info? It's a free form field I guess, it could be a new sub info field I suppose
kyle-yh-kim commentedon Mar 28, 2024
Thanks for chiming in. Personally, I'm opposed to
CLUSTER INFO. We could perhaps add aggregated information underCLUSTER INFO, but not for the slot level metrics themselves.Imagine dumping ~16384 slot level metrics under
CLUSTER INFO. This would unnecessarily bloat the info string, when the user may have only wanted to checkcluster_state:ok.A new command dedicated for slot level metrics querying, in this case,
CLUSTER SLOT-STATS, is more suitable. For reference, below was the latest command format we agreed on.I'll wait for the core team to finalize this decision, before opening the PRs.
zuiderkwast commentedon Apr 15, 2024
@kyle-yh-kim Yeah CLUSTER SLOT-STATS. We're a bit overloaded with the forking stuff, new core team, new project, etc. but I think we want this for our next release. There was already a lot of review done and I think it was almost ready to merge. Do you want to bring over your PR?
[-]Introduce slot level metrics to Redis cluster[/-][+][NEW] Introduce slot level metrics to Redis cluster[/+]65 remaining items
madolson commentedon Jul 26, 2024
The four components for Valkey 8.0 are now merged. We will follow up with memory in Valkey 8.2.
Fix hashtablePauseAutoShrink and use it in hashtableScanDefrag (#2257)
Fix hashtablePauseAutoShrink and use it in hashtableScanDefrag (valkeβ¦
Fix hashtablePauseAutoShrink and use it in hashtableScanDefrag (#2257)
update artifactory repo (valkey-io#20)
update artifactory repo (valkey-io#20)
Inline compression: drop dict-scoped retry guard (S2.3 superseded)
Inline compression: drop dict-scoped retry guard (S2.3 superseded)
Inline compression: drop dict-scoped retry guard (S2.3 superseded)
Inline compression: drop dict-scoped retry guard (S2.3 superseded)
Inline compression: drop dict-scoped retry guard (S2.3 superseded) (#10)
feat(S1.2): training sampler + BIO_COMPRESSION_TRAIN job (valkey-io#20)
fix(S1.2): NULL-guard server.db[j] iteration in compressionTrainCron (vβ¦
docs(plan): mark S1.2/S1.3/S1.4 complete (PR valkey-io#20, valkey-io#25β¦