Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2023-08-04 09:11:29 +0300
committerGitLab Bot <gitlab-bot@gitlab.com>2023-08-04 09:11:29 +0300
commitdebd8f45f8613aa1ac63362c86a7d8137df173a4 (patch)
tree4074b6c6ce1a6e09a486e553d9d985fa097004ae /doc
parentf830a15de6991a6768990aab9a4457b06718d29e (diff)
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r--doc/development/fe_guide/merge_request_widget_extensions.md5
-rw-r--r--doc/development/integrations/index.md12
-rw-r--r--doc/development/internal_analytics/service_ping/implement.md35
-rw-r--r--doc/development/internal_analytics/service_ping/metrics_dictionary.md24
-rw-r--r--doc/development/internal_analytics/service_ping/metrics_lifecycle.md1
5 files changed, 21 insertions, 56 deletions
diff --git a/doc/development/fe_guide/merge_request_widget_extensions.md b/doc/development/fe_guide/merge_request_widget_extensions.md
index f5bf9049db1..99206d99590 100644
--- a/doc/development/fe_guide/merge_request_widget_extensions.md
+++ b/doc/development/fe_guide/merge_request_widget_extensions.md
@@ -351,10 +351,7 @@ To generate these known events for a single widget:
```
1. Repeat step 6, but change the `data_source` to `redis_hll`.
-1. Add each of the HLL metrics to `lib/gitlab/usage_data_counters/known_events/code_review_events.yml`:
- 1. `name` = (the event)
- 1. `category` = `code_review`
- 1. `aggregation` = `weekly`
+
1. Add each event (those listed in the command in step 7, replacing `test_reports`
with the appropriate name slug) to the aggregate files:
1. `config/metrics/counts_7d/{timestamp}_code_review_category_monthly_active_users.yml`
diff --git a/doc/development/integrations/index.md b/doc/development/integrations/index.md
index bd672c86b28..a01e35349cb 100644
--- a/doc/development/integrations/index.md
+++ b/doc/development/integrations/index.md
@@ -156,7 +156,7 @@ module Integrations
end
```
-### Customize the frontend form
+## Customize the frontend form
The frontend form is generated dynamically based on metadata defined in the model.
@@ -182,26 +182,26 @@ This method should return an array of hashes for each field, where the keys can
| `help:` | string | false | | A help text that displays below the form field.
| `api_only:` | boolean | false | `false` | Specify if the field should only be available through the API, and excluded from the frontend form.
-#### Additional keys for `type: 'checkbox'`
+### Additional keys for `type: 'checkbox'`
| Key | Type | Required | Default | Description
|:------------------|:-------|:---------|:------------------|:--
| `checkbox_label:` | string | false | Value of `title:` | A custom label that displays next to the checkbox.
-#### Additional keys for `type: 'select'`
+### Additional keys for `type: 'select'`
| Key | Type | Required | Default | Description
|:-----------|:------|:---------|:--------|:--
| `choices:` | array | true | | A nested array of `[label, value]` tuples.
-#### Additional keys for `type: 'password'`
+### Additional keys for `type: 'password'`
| Key | Type | Required | Default | Description
|:----------------------------|:-------|:---------|:------------------|:--
| `non_empty_password_title:` | string | false | Value of `title:` | An alternative label that displays when a value is already stored.
| `non_empty_password_help:` | string | false | Value of `help:` | An alternative help text that displays when a value is already stored.
-#### Frontend form examples
+### Frontend form examples
This example defines a required `url` field, and optional `username` and `password` fields:
@@ -236,7 +236,7 @@ module Integrations
end
```
-### Expose the integration in the REST API
+## Expose the integration in the REST API
To expose the integration in the [REST API](../../api/integrations.md):
diff --git a/doc/development/internal_analytics/service_ping/implement.md b/doc/development/internal_analytics/service_ping/implement.md
index 5c5be64ccb9..9dbfa02854d 100644
--- a/doc/development/internal_analytics/service_ping/implement.md
+++ b/doc/development/internal_analytics/service_ping/implement.md
@@ -323,25 +323,7 @@ Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd/) and [P
##### Add new events
-1. Define events in [`known_events`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/).
-
- Example event:
-
- ```yaml
- - name: users_creating_epics
- aggregation: weekly
- ```
-
- Keys:
-
- - `name`: unique event name.
-
- Name format for Redis HLL events `{hll_counters}_<name>`
-
- Example names: `users_creating_epics`, `users_triggering_security_scans`.
-
- - `aggregation`: may be set to a `:daily` or `:weekly` key. Defines how counting data is stored in Redis.
- Aggregation on a `daily` basis does not pull more fine grained data.
+1. Add an event to the required metric ([see example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_7d/20230210200054_i_ee_code_review_merge_request_widget_license_compliance_expand_weekly.yml#L17-17)) or create a metric.
1. Use one of the following methods to track the event:
@@ -446,7 +428,7 @@ Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd/) and [P
- Using the JavaScript/Vue API helper, which calls the [`UsageData` API](#usagedata-api).
- 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/):
+ Example for an existing event already defined in [metric fields](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/counts_28d/20220407125907_p_ci_templates_themekit_monthly.yml#L17-17):
```javascript
import api from '~/api';
@@ -484,7 +466,6 @@ Next, get the unique events for the current week.
We have the following recommendations for [adding new events](#add-new-events):
-- Event aggregation: weekly.
- When adding new metrics, use a [feature flag](../../../operations/feature_flags.md) to control the impact.
It's recommended to disable the new feature flag by default (set `default_enabled: false`).
- Events can be triggered using the `UsageData` API, which helps when there are > 10 events per change
@@ -500,7 +481,7 @@ We can disable tracking completely by using the global flag:
##### Known events are added automatically in Service Data payload
-Service Ping adds all events [`known_events/*.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events) to Service Data generation under the `redis_hll_counters` key. This column is stored in [version-app as a JSON](https://gitlab.com/gitlab-org/gitlab-services/version.gitlab.com/-/blob/main/db/schema.rb#L213).
+Service Ping adds all events to Service Data generation under the `redis_hll_counters` key. This column is stored in [version-app as a JSON](https://gitlab.com/gitlab-org/gitlab-services/version.gitlab.com/-/blob/main/db/schema.rb#L213).
For each event we add metrics for the weekly and monthly time frames, and totals for each where applicable:
- `#{event_name}_weekly`: Data for 7 days for daily [aggregation](#add-new-events) events and data for the last complete week for weekly [aggregation](#add-new-events) events.
@@ -539,8 +520,6 @@ Example:
# Redis Counters
redis_usage_data(Gitlab::UsageDataCounters::WikiPageCounter)
-# Define events in common.yml https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/common.yml
-
# Tracking events
Gitlab::UsageDataCounters::HLLRedisCounter.track_event('users_expanding_vulnerabilities', values: visitor_id)
@@ -804,13 +783,7 @@ create metric YAML definition file following [Aggregated metric instrumentation
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45979) in GitLab 13.6.
-To declare the aggregate of events collected with [Redis HLL Counters](#redis-hll-counters),
-you must fulfill the following requirements:
-
-1. All events listed at `events` attribute must come from
- [`known_events/*.yml`](#known-events-are-added-automatically-in-service-data-payload) files.
-1. All events listed at `events` attribute must have the same `aggregation` attribute.
-1. `time_frame` does not include `all` value, which is unavailable for Redis sourced aggregated metrics.
+To declare the aggregate of events collected with [Redis HLL Counters](#redis-hll-counters), make sure `time_frame` does not include the `all` value, which is unavailable for Redis-sourced aggregated metrics.
While it is possible to aggregate EE-only events together with events that occur in all GitLab editions, it's important to remember that doing so may produce high variance between data collected from EE and CE GitLab instances.
diff --git a/doc/development/internal_analytics/service_ping/metrics_dictionary.md b/doc/development/internal_analytics/service_ping/metrics_dictionary.md
index f56955ed422..1fcd41fa816 100644
--- a/doc/development/internal_analytics/service_ping/metrics_dictionary.md
+++ b/doc/development/internal_analytics/service_ping/metrics_dictionary.md
@@ -130,20 +130,16 @@ which has a related schema in `/config/metrics/objects_schemas/topology_schema.j
### Metric `time_frame`
A metric's time frame is calculated based on the `time_frame` field and the `data_source` of the metric.
-For `redis_hll` metrics, the type of aggregation is also taken into consideration. In this context, the term "aggregation" refers to [chosen events data storage interval](implement.md#add-new-events), and is **NOT** related to the Aggregated Metrics feature.
-For more information about the aggregation type of each feature, see the [`common.yml` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/known_events/common.yml). Weeks run from Monday to Sunday.
-
-| data_source | time_frame | aggregation | Description |
-|------------------------|------------|----------------|-------------------------------------------------|
-| any | `none` | not applicable | A type of data that's not tracked over time, such as settings and configuration information |
-| `database` | `all` | not applicable | The whole time the metric has been active (all-time interval) |
-| `database` | `7d` | not applicable | 9 days ago to 2 days ago |
-| `database` | `28d` | not applicable | 30 days ago to 2 days ago |
-| `redis` | `all` | not applicable | The whole time the metric has been active (all-time interval) |
-| `redis_hll` | `7d` | `daily` | Most recent 7 complete days |
-| `redis_hll` | `7d` | `weekly` | Most recent complete week |
-| `redis_hll` | `28d` | `daily` | Most recent 28 complete days |
-| `redis_hll` | `28d` | `weekly` | Most recent 4 complete weeks |
+
+| data_source | time_frame | Description |
+|------------------------|------------|-------------------------------------------------|
+| any | `none` | A type of data that's not tracked over time, such as settings and configuration information |
+| `database` | `all` | The whole time the metric has been active (all-time interval) |
+| `database` | `7d` | 9 days ago to 2 days ago |
+| `database` | `28d` | 30 days ago to 2 days ago |
+| `redis` | `all` | The whole time the metric has been active (all-time interval) |
+| `redis_hll` | `7d` | Most recent complete week |
+| `redis_hll` | `28d` | Most recent 4 complete weeks |
### Data category
diff --git a/doc/development/internal_analytics/service_ping/metrics_lifecycle.md b/doc/development/internal_analytics/service_ping/metrics_lifecycle.md
index 7aa0eaa1554..bb3d6797011 100644
--- a/doc/development/internal_analytics/service_ping/metrics_lifecycle.md
+++ b/doc/development/internal_analytics/service_ping/metrics_lifecycle.md
@@ -103,4 +103,3 @@ To remove a metric:
1. Remove any other records related to the metric:
- The feature flag YAML file at [`config/feature_flags/*/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/feature_flags).
- - The entry in the known events YAML file at [`lib/gitlab/usage_data_counters/known_events/*.yaml`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/usage_data_counters/known_events).