Refactor Gitlab::UsageDataCounters counter classes
As noted in #332487 (comment 633607814):
There is a lot of technical debt in the ordinary Redis counter classes in the form of various inconsistencies. There are several classes listed in lib/gitlab/usage_data_counters.rb that handle incrementing events for different features. Some of the classes differ only in namespace and events they support, while others have helper classes to increment particular events with a convenient method call. Some have different Redis key names that differ in structure from the others.
This could be generalized like Redis HLL events are in
known_events
files and similar - some ordinary Redis counters actually already do, likePackageEventCounter
. Also, their API could be more unified, because now it's a free-for-all of different styles.
The main motivation is improving instrumenting Redis counters so that's easier for developers, because currently adding regular Redis counters is a fairly complicated and opaque process.
Some ideas on how to achieve that:
-
Cleanly separate existing Redis and Redis HLL classes, since HLL classes generally contain only helper methods that pass a proper event name to a
HLLRedisCounter
call.A major problem is that
Gitlab::UsageDataCounters
looks like a common interface to pass an event name to, but this only works for regular Redis classes. Redis HLL helper classes occupy the same folder (lib/gitlab/usage_data_counters/*
) as regular Redis counter classes which inherit fromBaseCounter
, but really are unrelated to HLL counter logic. -
Support instrumenting Redis counters with instrumentation classes.
There exists a
RedisMetric
instrumentation class as a proof-of-concept that can be used similarly toRedisHLLMetric
, but it relies on calls toGitlab::UsageDataCounters::*
classes. This should be rewritten to be independent of the legacy implementation and let developers instrument Redis counters right in metric definitions, just like with Redis HLL.
Testing
Ensure related tests are updated and passing