Commit 9acf8cbe authored by Marcin Sedlak-Jakubowski's avatar Marcin Sedlak-Jakubowski

Merge branch 'kpaizee-fix-lists-usage-ping-docs' into 'master'

Fix list rendering in Usage Ping docs

See merge request gitlab-org/gitlab!64512
parents 8e948357 26abadc0
...@@ -712,18 +712,22 @@ Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd) and [PF ...@@ -712,18 +712,22 @@ Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd) and [PF
Aggregation on a `daily` basis does not pull more fine grained data. Aggregation on a `daily` basis does not pull more fine grained data.
- `feature_flag`: optional `default_enabled: :yaml`. If no feature flag is set then the tracking is enabled. One feature flag can be used for multiple events. For details, see our [GitLab internal Feature flags](../feature_flags/index.md) documentation. The feature flags are owned by the group adding the event tracking. - `feature_flag`: optional `default_enabled: :yaml`. If no feature flag is set then the tracking is enabled. One feature flag can be used for multiple events. For details, see our [GitLab internal Feature flags](../feature_flags/index.md) documentation. The feature flags are owned by the group adding the event tracking.
Use one of the following methods to track events: 1. Use one of the following methods to track the event:
1. Track event in controller using `RedisTracking` module with `track_redis_hll_event(*controller_actions, name:, if: nil, &block)`. - In the controller using the `RedisTracking` module and the following format:
```ruby
track_redis_hll_event(*controller_actions, name:, if: nil, &block)
```
Arguments: Arguments:
- `controller_actions`: controller actions we want to track. - `controller_actions`: the controller actions to track.
- `name`: event name. - `name`: the event name.
- `if`: optional custom conditions, using the same format as with Rails callbacks. - `if`: optional custom conditions. Uses the same format as Rails callbacks.
- `&block`: optional block that computes and returns the `custom_id` that we want to track. This will override the `visitor_id`. - `&block`: optional block that computes and returns the `custom_id` that we want to track. This overrides the `visitor_id`.
Example usage: Example:
```ruby ```ruby
# controller # controller
...@@ -747,14 +751,14 @@ Use one of the following methods to track events: ...@@ -747,14 +751,14 @@ Use one of the following methods to track events:
end end
``` ```
1. Track event in API using `increment_unique_values(event_name, values)` helper method. - In the API using the `increment_unique_values(event_name, values)` helper method.
Arguments: Arguments:
- `event_name`: event name. - `event_name`: the event name.
- `values`: values counted, one value or array of values. - `values`: the values counted. Can be one value or an array of values.
Example usage: Example:
```ruby ```ruby
get ':id/registry/repositories' do get ':id/registry/repositories' do
...@@ -768,27 +772,26 @@ Use one of the following methods to track events: ...@@ -768,27 +772,26 @@ Use one of the following methods to track events:
end end
``` ```
1. Track event using `track_usage_event(event_name, values)` in services and GraphQL - Using `track_usage_event(event_name, values)` in services and GraphQL.
Increment unique values count using Redis HLL, for given event name. Increment unique values count using Redis HLL, for a given event name.
Example: Examples:
[Track usage event for incident created in service](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/app/services/issues/update_service.rb#L66)
[Track usage event for incident created in GraphQL](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/app/graphql/mutations/alert_management/update_alert_status.rb#L16) - [Track usage event for an incident in a service](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/app/services/issues/update_service.rb#L66)
- [Track usage event for an incident in GraphQL](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/app/graphql/mutations/alert_management/update_alert_status.rb#L16)
```ruby ```ruby
track_usage_event(:incident_management_incident_created, current_user.id) track_usage_event(:incident_management_incident_created, current_user.id)
``` ```
<!-- There's nearly identical content in `##### UsageData API Tracking`. If you find / fix errors here, you may need to fix errors in that section too. --> - Using the `UsageData` API.
<!-- There's nearly identical content in `##### UsageData API Tracking`. If you find / fix errors here, you may need to fix errors in that section too. -->
1. Track event using `UsageData` API Increment unique users count using Redis HLL, for a given event name.
Increment unique users count using Redis HLL, for given event name. To track events using the `UsageData` API, ensure the `usage_data_api` feature flag
is set to `default_enabled: true`. Enabled by default in GitLab 13.7 and later.
Tracking events using the `UsageData` API requires the `usage_data_api` feature flag to be enabled, which is enabled by default.
API requests are protected by checking for a valid CSRF token. API requests are protected by checking for a valid CSRF token.
...@@ -798,23 +801,21 @@ Use one of the following methods to track events: ...@@ -798,23 +801,21 @@ Use one of the following methods to track events:
| Attribute | Type | Required | Description | | Attribute | Type | Required | Description |
| :-------- | :--- | :------- | :---------- | | :-------- | :--- | :------- | :---------- |
| `event` | string | yes | The event name it should be tracked | | `event` | string | yes | The event name to track |
Response
Return 200 if tracking failed for any reason. Response:
- `200` if event was tracked or any errors - `200` if the event was tracked, or if tracking failed for any reason.
- `400 Bad request` if event parameter is missing - `400 Bad request` if an event parameter is missing.
- `401 Unauthorized` if user is not authenticated - `401 Unauthorized` if the user is not authenticated.
- `403 Forbidden` for invalid CSRF token provided - `403 Forbidden` if an invalid CSRF token is provided.
1. Track events using JavaScript/Vue API helper which calls the API above - Using the JavaScript/Vue API helper, which calls the `UsageData` API.
Example usage for an existing event already defined in [known events](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/): To track events using the `UsageData` API, ensure the `usage_data_api` feature flag
is set to `default_enabled: true`. Enabled by default in GitLab 13.7 and later.
Usage Data API is behind `usage_data_api` feature flag which, as of GitLab 13.7, is Example for an existing event already defined in [known events](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/):
now set to `default_enabled: true`.
```javascript ```javascript
import api from '~/api'; import api from '~/api';
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment