Loading
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 withLabkit::RateLimit::BlockSummary. It logs onerate_limit_block_summaryline per pair every 5 minutes, withrate_limit_ruleandblock_count. - A graceful worker stop flushes what is left.
- Each worker keeps at most 10 pairs per flush. Further pairs go on one
otherline. 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_counterflag. 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.rb58 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_urlandrollout_issue_url -
introduced_by_urlset to this MR - Team review
- !268007 (merged) merged
Edited by Nidhey Indurkar