Merge branch 'rename-usageping-serviceping-docs' into 'master'

Rename usage ping to service ping

See merge request gitlab-org/gitlab!65426

app/views/admin/application_settings/_usage.html.haml

@@ -22,7 +22,7 @@
           - if can_be_configured
             %p.mb-2= _('To help improve GitLab and its user experience, GitLab will periodically collect usage information.')
 
-            - service_ping_path = help_page_path('user/admin_area/settings/usage_statistics', anchor: 'usage-ping')
+            - service_ping_path = help_page_path('user/admin_area/settings/usage_statistics', anchor: 'service-ping')
             - service_ping_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: service_ping_path }
             %p.mb-2= s_('%{service_ping_link_start}Learn more%{service_ping_link_end} about what information is shared with GitLab Inc.').html_safe % { service_ping_link_start: service_ping_link_start, service_ping_link_end: '</a>'.html_safe }
 
@@ -32,7 +32,7 @@
             %pre.service-data-payload-container.js-syntax-highlight.code.highlight.mt-2.d-none{ class: payload_class, data: { endpoint: usage_data_admin_application_settings_path(format: :html) } }
           - else
             = _('Service ping is disabled, and cannot be configured through this form.')
-            - deactivating_service_ping_path = help_page_path('development/usage_ping/index.md', anchor: 'disable-usage-ping')
+            - deactivating_service_ping_path = help_page_path('development/usage_ping/index.md', anchor: 'disable-service-ping')
             - deactivating_service_ping_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: deactivating_service_ping_path }
             = s_('For more information, see the documentation on %{deactivating_service_ping_link_start}deactivating service ping%{deactivating_service_ping_link_end}.').html_safe % { deactivating_service_ping_link_start: deactivating_service_ping_link_start, deactivating_service_ping_link_end: '</a>'.html_safe }
     .form-group

doc/administration/index.md

@@ -44,7 +44,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Adjust your instance's timezone](timezone.md): Customize the default time zone of GitLab.
 - [System hooks](../system_hooks/system_hooks.md): Notifications when users, projects and keys are changed.
 - [Security](../security/index.md): Learn what you can do to further secure your GitLab instance.
-- [Usage statistics, version check, and usage ping](../user/admin_area/settings/usage_statistics.md): Enable or disable information about your instance to be sent to GitLab, Inc.
+- [Usage statistics, version check, and Service Ping](../user/admin_area/settings/usage_statistics.md): Enable or disable information about your instance to be sent to GitLab, Inc.
 - [Global user settings](user_settings.md): Configure instance-wide user permissions.
 - [Polling](polling.md): Configure how often the GitLab UI polls for updates.
 - [GitLab Pages configuration](pages/index.md): Enable and configure GitLab Pages.

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -1172,17 +1172,17 @@ registry = Geo::SnippetRepositoryRegistry.find(registry_id)
 registry.replicator.send(:sync_repository)
 ```
 
-### Generate usage ping
+### Generate Service Ping
 
-#### Generate or get the cached usage ping
+#### Generate or get the cached Service Ping
 
 ```ruby
 Gitlab::UsageData.to_json
 ```
 
-#### Generate a fresh new usage ping
+#### Generate a fresh new Service Ping
 
-This will also refresh the cached usage ping displayed in the admin area
+This will also refresh the cached Service Ping displayed in the admin area
 
 ```ruby
 Gitlab::UsageData.to_json(force_refresh: true)
@@ -1190,13 +1190,13 @@ Gitlab::UsageData.to_json(force_refresh: true)
 
 #### Generate and print
 
-Generates usage ping data in JSON format.
+Generates Service Ping data in JSON format.
 
 ```shell
 rake gitlab:usage_data:generate
 ```
 
-#### Generate and send usage ping
+#### Generate and send Service Ping
 
 Prints the metrics saved in `conversational_development_index_metrics`.
 

doc/api/usage_data.md

@@ -7,7 +7,7 @@ type: reference, api
 
 # Usage Data API **(FREE SELF)**
 
-The Usage Data API is associated with [Usage Ping](../development/usage_ping/index.md).
+The Usage Data API is associated with [Service Ping](../development/usage_ping/index.md).
 
 ## Export metric definitions as a single YAML file
 
@@ -48,14 +48,14 @@ Example response:
 ...
 ```
 
-## Export Usage Ping SQL queries
+## Export Service Ping SQL queries
 
 This action is available only for the GitLab instance [Administrator](../user/permissions.md) users.
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57016) in GitLab 13.11.
 > - [Deployed behind a feature flag](../user/feature_flags.md), disabled by default.
 
-Return all of the raw SQL queries used to compute Usage Ping.
+Return all of the raw SQL queries used to compute Service Ping.
 
 ```plaintext
 GET /usage_data/queries
@@ -116,7 +116,7 @@ Example response:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57050) in GitLab 13.11.
 > - [Deployed behind a feature flag](../user/feature_flags.md), disabled by default.
 
-Return all non-SQL metrics data used in the usage ping.
+Return all non-SQL metrics data used in the Service ping.
 
 Example request:
 

doc/architecture/blueprints/graphql_api/index.md

@@ -95,7 +95,7 @@ notify users that we plan to remove them.
 
 - Define a data-informed deprecation policy that will serve our users better
 - Build a dashboard showing usage frequency of deprecated GraphQL fields
-- Build mechanisms required to send deprecated fields usage in usage ping
+- Build mechanisms required to send deprecated fields usage in Service Ping
 
 ### Ensure consistency with the rest of the codebase
 

doc/development/index.md

@@ -271,7 +271,7 @@ See [database guidelines](database/index.md).
 ## Product Intelligence guides
 
 - [Product Intelligence guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Usage Ping guide](usage_ping/index.md)
+- [Service Ping guide](usage_ping/index.md)
 - [Snowplow guide](snowplow/index.md)
 
 ## Experiment guide

doc/development/iterating_tables_in_batches.md

@@ -394,4 +394,4 @@ end
 
 ### `EachBatch` vs `BatchCount`
 
-When adding new counters for usage ping, the preferred way to count records is using the `Gitlab::Database::BatchCount` class. The iteration logic implemented in `BatchCount` has similar performance characteristics like `EachBatch`. Most of the tips and suggestions for improving `BatchCount` mentioned above applies to `BatchCount` as well.
+When adding new counters for Service Ping, the preferred way to count records is using the `Gitlab::Database::BatchCount` class. The iteration logic implemented in `BatchCount` has similar performance characteristics like `EachBatch`. Most of the tips and suggestions for improving `BatchCount` mentioned above applies to `BatchCount` as well.

doc/development/query_performance.md

@@ -21,7 +21,7 @@ When you are optimizing your SQL queries, there are two dimensions to pay attent
 | Queries in a migration | `100ms` | This is different than the total [migration time](database_review.md#timing-guidelines-for-migrations). |
 | Concurrent operations in a migration | `5min` | Concurrent operations do not block the database, but they block the GitLab update. This includes operations such as `add_concurrent_index` and `add_concurrent_foreign_key`. |
 | Background migrations | `1s` |  |
-| Usage Ping | `1s` | See the [usage ping docs](usage_ping/index.md#developing-and-testing-usage-ping) for more details. |
+| Service Ping | `1s` | See the [Service Ping docs](usage_ping/index.md#developing-and-testing-service-ping) for more details. |
 
 - When analyzing your query's performance, pay attention to if the time you are seeing is on a [cold or warm cache](#cold-and-warm-cache). These guidelines apply for both cache types.
 - When working with batched queries, change the range and batch size to see how it effects the query timing and caching.

doc/development/snowplow/index.md

@@ -11,7 +11,7 @@ This guide provides an overview of how Snowplow works, and implementation detail
 For more information about Product Intelligence, see:
 
 - [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Usage Ping Guide](../usage_ping/index.md)
+- [Service Ping Guide](../usage_ping/index.md)
 
 More useful links:
 

doc/development/usage_ping/metrics_dictionary.md

@@ -12,7 +12,7 @@ This guide describes Metrics Dictionary and how it's implemented
 
 We are using [JSON Schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json) to validate the metrics definition.
 
-This process is meant to ensure consistent and valid metrics defined for Usage Ping. All metrics *must*:
+This process is meant to ensure consistent and valid metrics defined for Service Ping. All metrics *must*:
 
 - Comply with the defined [JSON schema](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
 - Have a unique `key_path` .
@@ -26,7 +26,7 @@ Each metric is defined in a separate YAML file consisting of a number of fields:
 
 | Field               | Required | Additional information                                         |
 |---------------------|----------|----------------------------------------------------------------|
-| `key_path`          | yes      | JSON key path for the metric, location in Usage Ping payload.  |
+| `key_path`          | yes      | JSON key path for the metric, location in Service Ping payload.  |
 | `name`              | no       | Metric name suggestion. Can replace the last part of `key_path`. |
 | `description`       | yes      |                                                                |
 | `product_section`   | yes      | The [section](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/sections.yml). |
@@ -58,7 +58,7 @@ Metric definitions can have one of the following statuses:
 - `broken`: Metric reports broken data (for example, -1 fallback), or does not report data at all. A metric marked as `broken` must also have the `repair_issue_url` attribute.
 - `not_used`: Metric is not used in any dashboard.
 - `deprecated`: Metric is deprecated and possibly planned to be removed.
-- `removed`: Metric was removed, but it may appear in Usage Ping payloads sent from instances running on older versions of GitLab.
+- `removed`: Metric was removed, but it may appear in Service Ping payloads sent from instances running on older versions of GitLab.
 
 ### Metric value_type
 
@@ -99,7 +99,7 @@ should be changed.
 We use the following categories to classify a metric:
 
 - `Operational`: Required data for operational purposes.
-- `Optional`: Data that is optional to collect. This can be [enabled or disabled](../usage_ping/index.md#disable-usage-ping) in the Admin Area.
+- `Optional`: Data that is optional to collect. This can be [enabled or disabled](../usage_ping/index.md#disable-service-ping) in the Admin Area.
 - `Subscription`: Data related to licensing.
 - `Standard`: Standard set of identifiers that are included when collecting data.
 
@@ -214,9 +214,9 @@ bundle exec rails generate gitlab:usage_metric_definition counts.issues --ee --d
 create  ee/config/metrics/counts_7d/issues.yml
 ```
 
-## Metrics added dynamic to Usage Ping payload
+## Metrics added dynamic to Service Ping payload
 
-The [Redis HLL metrics](index.md#known-events-are-added-automatically-in-usage-data-payload) are added automatically to Usage Ping payload.
+The [Redis HLL metrics](index.md#known-events-are-added-automatically-in-usage-data-payload) are added automatically to Service Ping payload.
 
 A YAML metric definition is required for each metric. A dedicated generator is provided to create metric definitions for Redis HLL events.
 

doc/development/usage_ping/metrics_instrumentation.md

@@ -6,13 +6,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Metrics instrumentation guide
 
-This guide describes how to develop Usage Ping metrics using metrics instrumentation.
+This guide describes how to develop Service Ping metrics using metrics instrumentation.
 
 ## Nomenclature
 
 - **Instrumentation class**:
   - Inherits one of the metric classes: `DatabaseMetric`, `RedisHLLMetric` or `GenericMetric`.
-  - Implements the logic that calculates the value for a Usage Ping metric.
+  - Implements the logic that calculates the value for a Service Ping metric.
 
 - **Metric definition**
   The Usage Data metric YAML definition.
@@ -27,7 +27,7 @@ A metric definition has the [`instrumentation_class`](metrics_dictionary.md) fie
 The defined instrumentation class should have one of the existing metric classes: `DatabaseMetric`, `RedisHLLMetric`, or `GenericMetric`.
 
 Using the instrumentation classes ensures that metrics can fail safe individually, without breaking the entire
- process of Usage Ping generation.
+ process of Service Ping generation.
 
 We have built a domain-specific language (DSL) to define the metrics instrumentation.
 
@@ -88,7 +88,7 @@ end
 
 ## Creating a new metric instrumentation class
 
-To create a stub instrumentation for a Usage Ping metric, you can use a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_generator.rb):
+To create a stub instrumentation for a Service Ping metric, you can use a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_generator.rb):
 
 The generator takes the class name as an argument and the following options:
 

doc/development/usage_ping/review_guidelines.md

@@ -4,22 +4,22 @@ group: Product Intelligence
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Usage Ping review guidelines
+# Service Ping review guidelines
 
 This page includes introductory material for a
 [Product Intelligence](https://about.gitlab.com/handbook/engineering/development/growth/product-intelligence/)
-review, and is specific to Usage Ping related reviews. For broader advice and
+review, and is specific to Service Ping related reviews. For broader advice and
 general best practices for code reviews, refer to our [code review guide](../code_review.md).
 
 ## Resources for reviewers
 
-- [Usage Ping Guide](index.md)
+- [Service Ping Guide](index.md)
 - [Metrics Dictionary](metrics_dictionary.md)
 
 ## Review process
 
 We recommend a Product Intelligence review when a merge request (MR) touches
-any of the following Usage Ping files:
+any of the following Service Ping files:
 
 - `usage_data*` files.
 - The Metrics Dictionary, including files in:
@@ -50,7 +50,7 @@ any of the following Usage Ping files:
 
 - Perform a first-pass review on the merge request and suggest improvements to the author.
 - Check the [metrics location](index.md#1-naming-and-placing-the-metrics) in
-  the Usage Ping JSON payload.
+  the Service Ping JSON payload.
 - Add the `~database` label and ask for a [database review](../database_review.md) for
   metrics that are based on Database.
 - For tracking using Redis HLL (HyperLogLog):

doc/raketasks/index.md

@@ -46,7 +46,7 @@ The following Rake tasks are available for use with GitLab:
 | [Repository storage](../administration/raketasks/storage.md) | List and migrate existing projects and attachments from legacy storage to hashed storage. |
 | [Uploads migrate](../administration/raketasks/uploads/migrate.md) | Migrate uploads between local storage and object storage. |
 | [Uploads sanitize](../administration/raketasks/uploads/sanitize.md) | Remove EXIF data from images uploaded to earlier versions of GitLab. |
-| [Usage data](../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-usage-ping) | Generate and troubleshoot [Usage Ping](../development/usage_ping/index.md). |
+| [Usage data](../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-service-ping) | Generate and troubleshoot [Service Ping](../development/usage_ping/index.md). |
 | [User management](user_management.md)                 | Perform user management tasks. |
 | [Webhooks administration](web_hooks.md)               | Maintain project webhooks. |
 | [X.509 signatures](x509_signatures.md)                | Update X.509 commit signatures, which can be useful if the certificate store changed. |

doc/user/admin_area/analytics/dev_ops_report.md

@@ -20,19 +20,19 @@ To see DevOps Report:
 ## DevOps Score
 
 NOTE:
-Your GitLab instance's [usage ping](../settings/usage_statistics.md#usage-ping) must be activated in order to use this feature.
+Your GitLab instance's [Service Ping](../settings/usage_statistics.md#service-ping) must be activated in order to use this feature.
 
 The DevOps Score tab displays the usage of major GitLab features on your instance over
 the last 30 days, averaged over the number of billable users in that time period. It also
 provides a Lead score per feature, which is calculated based on GitLab analysis
-of top-performing instances based on [usage ping data](../settings/usage_statistics.md#usage-ping) that GitLab has
+of top-performing instances based on [Service Ping data](../settings/usage_statistics.md#service-ping) that GitLab has
 collected. Your score is compared to the lead score of each feature and then expressed as a percentage at the bottom of said feature.
 Your overall **DevOps Score** is an average of your feature scores. You can use this score to compare your DevOps status to other organizations.
 
 The page also provides helpful links to articles and GitLab docs, to help you
 improve your scores.
 
-Usage ping data is aggregated on GitLab servers for analysis. Your usage
+Service Ping data is aggregated on GitLab servers for analysis. Your usage
 information is **not sent** to any other GitLab instances. If you have just started using GitLab, it may take a few weeks for data to be
 collected before this feature is available.
 

doc/user/admin_area/settings/usage_statistics.md

@@ -14,7 +14,7 @@ All statistics are opt-out. To enable or disable them:
 
 1. On the top bar, select **Menu >** **{admin}** **Admin**.
 1. In the left sidebar, select **Settings > Metrics and profiling**, and expand **Usage statistics**.
-1. Enable or disable **Version check** and **Usage ping**.
+1. Enable or disable **Version check** and **Service ping**.
 1. Select **Save changes**.
 
 ## Network configuration
@@ -67,14 +67,14 @@ sequenceDiagram
     Version Application->>GitLab instance: Response (PNG/SVG)
 ```
 
-## Usage Ping **(FREE SELF)**
+## Service Ping **(FREE SELF)**
 
-See [Usage Ping guide](../../../development/usage_ping/index.md).
+See [Service Ping guide](../../../development/usage_ping/index.md).
 
 ## Instance-level analytics availability
 
-After usage ping is enabled, GitLab gathers data from other instances and
-enables certain [instance-level analytics features](../analytics/index.md) that are dependent on usage ping.
+After Service Ping is enabled, GitLab gathers data from other instances and
+enables certain [instance-level analytics features](../analytics/index.md) that are dependent on Service Ping.
 
 <!-- ## Troubleshooting