Skip to content

Renaming a high-volume feature category causes metric gaps

First noticed in #2095 (closed). Here's what happened:

  1. code_review got renamed to code_review_workflow: #2095 (closed)
  2. We merged the runbooks MR: gitlab-com/runbooks!5272 (merged)
  3. The Rails MR took longer: gitlab-org/gitlab!108219 (merged)
  4. We had a metrics gap.

The reason for the gap is that the recording rules (from step 2) were expecting code_review_workflow, but the application (from step 3) was still emitting code_review.

Most of the time that this happens it isn't a huge deal, but this category is a very high-volume one and so it was clearly noticeable to the team. In gitlab-org/gitlab!109338 (merged) / gitlab-com/runbooks!5310 (merged) we have a similar rename from users to user_profile.

If this continues to happen, we should consider adding something to the runbooks to map both categories for a period (so, code_review and code_review_workflow would both be valid), as we can never align the recording rules exactly with the application deploy. Sketch of this idea in #2095 (comment 1232109841).