Add WAGED rebalance build/solve latency split and partial movement counter

[sjainit]

Issues

• My PR addresses the following Helix issues and references them in the PR description:

No dedicated GitHub issue was filed; this is a self-contained observability enhancement for the WAGED rebalancer. Happy to open a tracking issue if maintainers prefer.

Description

• Here are some details about my PR, including screenshots of any UI changes:

What: Add two kinds of observability to the WAGED global (baseline) and partial (best possible) rebalance paths:

1. Build vs. solve latency split. The existing GlobalBaselineCalcLatencyGauge / PartialRebalanceLatencyGauge each wrap two very different phases — building the cluster model (generateClusterModelFor*) and solving it (WagedRebalanceUtil.calculateAssignment). This PR times those phases separately with four new latency gauges: GlobalBaselineCalcBuildLatencyGauge, GlobalBaselineCalcSolveLatencyGauge, PartialRebalanceBuildLatencyGauge, and PartialRebalanceSolveLatencyGauge. The original overall gauges are retained.

2. Partial replica-movement counter. There was no metric for how much the served assignment changes between rebalances. This PR adds PartialRebalanceReplicaMovementCounter, incremented by a new ResourceUsageCalculator.countReplicaMovements(old, new) helper that counts replica placements in the newly computed best possible assignment that are new or changed relative to the previous one. The best possible assignment is what actually drives state transitions, so this measures churn at the point it matters. It is deliberately scoped to the partial (best possible) path rather than the baseline, since the baseline is the steady-state target and does not itself drive transitions.

Why: Today a slow or churny WAGED rebalance is hard to diagnose. A single latency number can't tell an operator whether model construction or constraint solving is the bottleneck, and no metric quantifies the churn (state-transition blast radius) a rebalance introduces — a "fast" rebalance that moves thousands of replicas is far more impactful than its latency suggests. The movement counter captures this churn at intent-time (in the computed assignment, before throttling / IntermediateStateCalc cap it), attributed to the rebalancer phase — a leading indicator that complements the existing downstream, per-resource PendingRecovery/LoadRebalanceReplicaGauge and DifferenceWithIdealStateGauge signals rather than duplicating them.

How: Both runners already own a MetricCollector. The build and solve calls are wrapped in startMeasuringLatency() / endMeasuringLatency() spans (using try/finally so the build span is recorded even when model construction fails). After solving, the partial runner increments its movement counter with countReplicaMovements(previousBestPossibleAssignment, newAssignment), guarded by isBestPossibleChanged so the diff pass is skipped when nothing changed. The new helper walks the assignment map fields and counts each (partition, instance) placement whose state is absent or different in the previous assignment; dropped replicas are intentionally not counted, matching the "work introduced by the new assignment" framing. All additions follow the existing enum + createMetrics() + getMetric(...) pattern in WagedRebalancerMetricCollector.

Tests

• The following tests are written for this issue:

  • TestResourceUsageCalculator#testCountReplicaMovements — covers identical assignments (0), empty new (0), empty previous (all replicas counted), a mixed case (relocation + state change + unchanged + dropped-not-counted), and a resource absent from the previous assignment.
  • TestWagedRebalancerMetrics#testWagedRebalanceMetrics — extended to assert the four new build/solve latency gauges are measured and the partial replica-movement counter is positive after a from-scratch rebalance.

• Local code review completed

• The following is the result of the "mvn test" command on the appropriate module:

  Maven is not available in my local environment, so mvn test was not run locally; relying on the project CI to execute the helix-core test suite. The change is confined to helix-core and is covered by the unit tests listed above.

Changes that Break Backward Compatibility (Optional)

None. All changes are additive: new metric enum values, new gauges/counter, and a new static helper. The existing overall latency gauges and all current metrics are unchanged, and no public API or rebalancing behavior is modified.

Documentation (Optional)

Not applicable — internal observability improvement with no new user-facing functionality.

Commits

• My commit uses an imperative subject separated from the body by a blank line, wrapped at 72 columns, and explains what and why rather than how.

Code Quality

• The diff follows the existing Helix formatting conventions in the touched files.

🤖 Generated with GitHub Copilot CLI