Create framework to be able to categorize controller actions with 'feature category'
Intro
At #315 (closed) we're introducing new Redis metrics, these are:
-
sidekiq_redis_requests_total
- Counts the amount of calls to Redis servers during worker execution -
sidekiq_redis_requests_duration_seconds_bucket
- Adds query time spent on Redis servers during worker execution -
http_redis_requests_total
- Counts the amount of calls to Redis servers during web requests -
http_redis_requests_duration_seconds
- Measures query time for Redis servers during web requests
The two former metrics, as the name states, measures Redis calls coming from Sidekiq workers, the latter ones, Redis calls coming from web requests.
Since we already categorize Sidekiq workers, the two former metrics carry a feature_category
label. It's a valuable attribute to know how much the teams are relying on Redis for their workers, and is another step towards #304 (closed).
Still, web requests (Rails controllers and Grape API) are not categorized, meaning it's not easy to budget (per team) how much is being spent on Redis (or any other internal service).
Proposal
Rails
The controller and all underlying action requests are responsibility of a single feature category:
class FooController < ActionController::Base
feature_category :foo_management
end
The controller and a few actions are responbility of a feature category:
class FooController < ActionController::Base
feature_category :foo_management, only: [:foo]
feature_category :bar_management, only: [:bar]
end
Grape API
All routes under Foo
API are responsibility of a single feature category:
module API
class Foo < Grape::API
feature_category :foo_management
...
end
end
When a few routes under Foo
API are responsibility of a single feature category we could probably make use of the pattern returned by bundle exec rake grape:path_helpers
(or something similar):
module API
class Foo < Grape::API
feature_category :foo_management, only: ['/api/:version/audit_events', '/api/:version/issues']
...
end
end
In order to enforce that all actions and routes should have a feature_category
definition, we should validate that each action and API endpoint has a feature category in specs.
Outcome
As an outcome, we'd be able to categorize underlying service calls (e.g. Gitaly, Redis) metrics per 'feature category' in web requests, allowing to budget properly. Additionally that's also required for any other step towards automating notifications to Slack channels (in the context of web requests).