<fix>[zwatch]: clean alarm resource state label and prune stale ones#4341
<fix>[zwatch]: clean alarm resource state label and prune stale ones#4341MatheMatrix wants to merge 1 commit into
Conversation
|
Warning Review limit reached
More reviews will be available in 8 minutes and 28 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Warning
|
The per-resource alarm state now stores a clean identify label and drops residual states when a metric series disappears. 1. Why is this change necessary? AlarmResourceState.identifyLabel stored the whole metric series key (e.g. ::CPUNum:19::::VMUuid:x::), so the alarm detail page showed the VMUuid that resourceUuid already carries. And when a series vanished while its resource stayed (e.g. a vCPU dropped after a cpu downsize), the state was only marked InsufficientData and lingered forever. 2. How does it address the problem? identifyLabel now persists the clean per-resource label (CPUNum:19); the resource identity stays in resourceUuid, so the row key becomes (alarmUuid, identifyLabel, resourceUuid) and its unique index follows (identifyLabel shrinks to 191 to keep the composite key within the CI MySQL limit). Rule rebuild reconstructs the full series key from the stored row, so the recovery pairing keeps matching the rule engine. A series missing this round whose resource still reports other series is deleted; a fully silent resource stays InsufficientData. 3. Are there any side effects? identifyLabel of existing rows changes shape; acceptable on this unreleased feature branch. No behavior change for silent resources. # Summary of changes (by module): - zwatch: store clean identifyLabel, (alarm,label,resourceUuid) row key, series-key reconstruction on rebuild, prune departed series - conf: AlarmResourceStateVO unique key + identifyLabel length Related: ZSTAC-85397 Related: SUG-2677 Change-Id: Ie8fa813292de89766f0733089a3610e09f88cfae
c2bd291 to
6058905
Compare
ZSTAC-85397
Root Cause
The alarm resource state row was keyed only by (alarmUuid, identifyLabel). Now that identifyLabel stores the clean per-resource label (e.g. CPUNum:19), two resources under one multi-resource alarm can share the same label, so the unique key must also include resourceUuid.
Changes
Test
Related MRs
Related: ZSTAC-85397
Related: SUG-2677
sync from gitlab !10302