[yeya24]

What this PR does:

cortex_ring_member_ownership_percent is computed by countTokens(), which merges the tokens of all zones into a single sorted list, so each token owns the distance back to the previous token from any zone.

With zone-aware replication a write is routed within a single zone: in zone A, member X serves the hash range from the previous zone-A token to X's own token. The existing metric therefore depends on where the other zones' tokens happen to fall and does not report the range a member actually serves. An uneven per-zone token distribution, for example after a scale-down, is invisible: a member can sit at the zone average by this metric while serving a noticeably larger share of its own zone, which is what pushes the hottest members of a zone into per-member limits first.

This PR adds:

cortex_ring_member_zonal_ownership_percent{name, member, zone}

The value is the fraction of its own zone's token space owned by the member, so the values within a zone sum to 1. Skew per zone can be computed as:

  max by (name, zone) (max by (name, member, zone) (cortex_ring_member_zonal_ownership_percent{name="ingester"}))
/
  avg by (name, zone) (max by (name, member, zone) (cortex_ring_member_zonal_ownership_percent{name="ingester"}))

(The inner max by (name, member, zone) collapses the identical series reported by every component holding a ring client.)

Details:

• Reuses the existing countTokensByAz(), which was previously only used by the /ring page.
• Reported only when ring detailed metrics (detailed_metrics_enabled) and zone awareness are both enabled. Without zone awareness writes are not routed per zone, so a per-zone ownership value would be misleading.
• Stale series are deleted when a member leaves the ring or moves to another zone, mirroring the existing handling for cortex_ring_member_ownership_percent.
• The _percent suffix matches the sibling cortex_ring_member_ownership_percent, which also reports a 0–1 value.
• countTokensByAz() now reads the ringTokensByZone already computed by updateRingState instead of recomputing the per-zone token lists on every call, matching countTokens(), which already reads the cached ringTokens. RingCompare returns Different for any change to the instance set, zones or tokens, so on every path that reaches updateRingMetrics the cached value is token-identical to a fresh computation. On a 300 instance x 512 token x 3 zone ring this takes countTokensByAz() from ~41ms / 708KB to ~23ms / 48KB per call, which also makes the /ring page cheaper.

The detailed metrics block only runs on topology changes (heartbeat-only updates return EqualButStatesAndTimestamps and skip it), so the added cost is one countTokensByAz() pass per topology change per ring client.

Which issue(s) this PR fixes:

N/A

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]
• docs/configuration/v1-guarantees.md updated if this PR introduces experimental flags (N/A: no new flags)