Log rack rate limit blocks per endpoint and rule

What does this MR do and why?

Replaces the rolled-back gitlab_rate_limit_rack_blocks_total counter with a LabKit block summary (#638007). The counter was rolled back at 5% on gprd because its pod label made too many series (#636996 (closed)).

  • Each Puma worker counts rack rate limiter blocks per (endpoint_id, rule) in memory with Labkit::RateLimit::BlockSummary. It logs one rate_limit_block_summary line per pair every 5 minutes, with rate_limit_rule and block_count.
  • A graceful worker stop flushes what is left.
  • Each worker keeps at most 10 pairs per flush. Further pairs go on one other line. The trade-off is in #638075.
  • Why a log line and not the counter without pod: #638007.
  • Behind rate_limiter_endpoint_block_summary (gitlab_com_derisk, default off). Rollout: #638075.
  • Removes the old counter, its row in the metrics doc, and the rate_limiter_endpoint_block_counter flag. That flag was turned off on every environment on 2026-11-03.

Stacked on !268007 (merged)

This needs gitlab-labkit 5.8.0. Until !268007 (merged) merges, the diff here includes its 3 lockfile changes. The other 6 files are this change.

How to validate locally

FOSS_ONLY=1 bundle exec rspec \
  spec/initializers/rate_limit_block_summary_spec.rb \
  spec/lib/gitlab/middleware/labkit_rack_rate_limit_spec.rb

58 examples, 0 failures, against gitlab-labkit 5.8.0.

Checklist

  • Specs above pass locally
  • RuboCop clean on the changed Ruby files
  • Feature flag YAML has feature_issue_url and rollout_issue_url
  • introduced_by_url set to this MR
  • Team review
  • !268007 (merged) merged
Edited by Nidhey Indurkar

Merge request reports

Loading
Loading