Remove legacy telemetry event names from the newer telemetry framework
What does this MR do and why?
For #395482 (closed)
Removes old telemetry names from the new widgets' telemetry framework.
Tasks for removing metrics, from the documentation:
-
Create an issue for removing the metric if none exists yet. The issue needs to outline why the metric should be deleted. You can use this issue to document the removal process. -
Verify the metric is not used to calculate the conversational index. The conversational index is a measure that reports back to self-managed instances to inform administrators of the progress of DevOps adoption for the instance. You can check CalculateConvIndexService to view the metrics that are used. The metrics are represented as the keys that are passed as a field argument into the get_value method.
-
Verify that removing the metric from the Service Ping payload does not cause errors in Version App when the updated payload is collected and processed. Version App collects and persists all Service Ping reports. To verify Service Ping processing in your local development environment, follow this guide. Alternatively, you can modify fixtures used to test the UsageDataController#create endpoint, and assure that test suite does not fail when metric that you wish to remove is not included into test payload. -
Remove data from Redis For Ordinary Redis counters remove data stored in Redis. Add a migration to remove the data from Redis for the related Redis keys. For more details, see this MR example.
-
Create an issue in the GitLab Data Team project. Ask for confirmation that the metric is not referred to in any SiSense dashboards and can be safely removed from Service Ping. Use this example issue for guidance. -
Notify the Customer Success Ops team ( @csops-team
), Analytics Engineers (@gitlab-data/analytics-engineers
), and Product Analysts (@gitlab-data/product-analysts
) by @ mentioning those groups in a comment in the issue from step 1 regarding the deletion of the metric. Many Service Ping metrics are relied upon for health score and XMAU reporting and unexpected changes to those metrics could break reporting. -
After you verify the metric can be safely removed, update the attributes of the metric’s YAML definition: - Set the
status:
to removed. - Set
removed_by_url:
to the URL of the MR removing the metric - Set
milestone_removed:
to the number of the milestone in which the metric was removed.
Do not remove the metric’s YAML definition altogether. Some self-managed instances might not immediately update to the latest version of GitLab, and therefore continue to report the removed metric. The Product Intelligence team requires a record of all removed metrics to identify and filter them.
For example please take a look at this merge request.
- Set the
-
After you verify the metric can be safely removed, remove the metric’s instrumentation from lib/gitlab/usage_data.rb or ee/lib/ee/gitlab/usage_data.rb. For example please take a look at this merge request.
-
Remove any other records related to the metric: The feature flag YAML file at config/feature_flags//.yaml. The entry in the known events YAML file at lib/gitlab/usage_data_counters/known_events/*.yaml.
Screenshots or screen recordings
All backstage.
How to set up and validate locally
See !89078 (merged) for validation steps.
Note the NB:
there. Those are the events that are being removed.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.