diff options
Diffstat (limited to 'doc/operations')
| -rw-r--r-- | doc/operations/README.md | 5 | ||||
| -rw-r--r-- | doc/operations/feature_flags.md | 328 | ||||
| -rw-r--r-- | doc/operations/index.md | 20 | ||||
| -rw-r--r-- | doc/operations/metrics/alerts.md | 110 | ||||
| -rw-r--r-- | doc/operations/metrics/dashboards/index.md | 249 | ||||
| -rw-r--r-- | doc/operations/metrics/dashboards/panel_types.md | 262 | ||||
| -rw-r--r-- | doc/operations/metrics/dashboards/templating_variables.md | 128 | ||||
| -rw-r--r-- | doc/operations/metrics/dashboards/variables.md | 59 | ||||
| -rw-r--r-- | doc/operations/metrics/dashboards/yaml.md | 166 | ||||
| -rw-r--r-- | doc/operations/metrics/dashboards/yaml_number_format.md | 177 | ||||
| -rw-r--r-- | doc/operations/metrics/embed.md | 93 | ||||
| -rw-r--r-- | doc/operations/metrics/embed_grafana.md | 65 | ||||
| -rw-r--r-- | doc/operations/metrics/img/example-dashboard_v13_1.png | bin | 0 -> 31439 bytes | |||
| -rw-r--r-- | doc/operations/metrics/index.md | 142 | ||||
| -rw-r--r-- | doc/operations/tracing.md | 40 |
15 files changed, 1839 insertions, 5 deletions
diff --git a/doc/operations/README.md b/doc/operations/README.md deleted file mode 100644 index 319e5f48d38..00000000000 --- a/doc/operations/README.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -redirect_to: '../administration/operations/index.md' ---- - -This document was moved to [another location](../administration/operations/index.md). diff --git a/doc/operations/feature_flags.md b/doc/operations/feature_flags.md new file mode 100644 index 00000000000..7614d70e132 --- /dev/null +++ b/doc/operations/feature_flags.md @@ -0,0 +1,328 @@ +--- +stage: Release +group: Progressive Delivery +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/#designated-technical-writers +--- + +# Feature Flags **(PREMIUM)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7433) in GitLab 11.4. + +With Feature Flags, you can deploy your application's new features to production in smaller batches. +You can toggle a feature on and off to subsets of users, helping you achieve Continuous Delivery. +Feature flags help reduce risk, allowing you to do controlled testing, and separate feature +delivery from customer launch. + +<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> +For an example of feature flags in action, see [GitLab for Deploys, Feature Flags, and Error Tracking](https://www.youtube.com/embed/5tw2p6lwXxo). + +## How it works + +GitLab uses [Unleash](https://github.com/Unleash/unleash), a feature +toggle service. + +By enabling or disabling a flag in GitLab, your application +can determine which features to enable or disable. + +You can create feature flags in GitLab and use the API from your application +to get the list of feature flags and their statuses. The application must be configured to communicate +with GitLab, so it's up to developers to use a compatible client library and +[integrate the feature flags in your app](#integrate-feature-flags-with-your-application). + +## Create a feature flag + +To create and enable a feature flag: + +1. Navigate to your project's **Operations > Feature Flags**. +1. Click the **New feature flag** button. +1. Enter a name that starts with a letter and contains only lowercase letters, digits, underscores (`_`), + or dashes (`-`), and does not end with a dash (`-`) or underscore (`_`). +1. Enter a description (optional, 255 characters max). +1. Enter details about how the flag should be applied: + - In GitLab 13.0 and earlier, add **Environment specs**. For each environment, + include the **Status** (default enabled) and [**Rollout strategy**](#rollout-strategy-legacy) + (defaults to **All users**). + - In GitLab 13.1 and later, add Feature Flag [**Strategies**](#feature-flag-strategies). + For each strategy, include the **Type** (defaults to [**All users**](#all-users)) + and **Environments** (defaults to all environments). +1. Click **Create feature flag**. + +You can change these settings by clicking the **{pencil}** (edit) button +next to any feature flag in the list. + +## Rollout strategy (legacy) + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8240) in GitLab 12.2. + +In GitLab 13.0 and earlier, the **Rollout strategy** setting affects which users will experience +the feature as enabled. Choose the percentage of users that the feature will be enabled +for. The rollout strategy will have no effect if the environment spec is disabled. + +It can be set to: + +- All users +- [Percent of users](#percent-of-users) + - Optionally, you can click the **Include additional user IDs** checkbox and add a list + of specific users IDs to enable the feature for. +- [User IDs](#user-ids) + +## Feature flag strategies + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35555) in GitLab 13.0. +> - It's deployed behind a feature flag, disabled by default. +> - It's enabled on GitLab.com. +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-feature-flag-strategies). **(CORE ONLY)** + +You can apply a feature flag strategy across multiple environments, without defining +the strategy multiple times. + +GitLab Feature Flags use [Unleash](https://unleash.github.io) as the feature flag +engine. In Unleash, there are [strategies](https://unleash.github.io/docs/activation_strategy) +for granular feature flag controls. GitLab Feature Flags can have multiple strategies, +and the supported strategies are: + +- [All users](#all-users) +- [Percent of Users](#percent-of-users) +- [User IDs](#user-ids) +- [User List](#user-list) + +Strategies can be added to feature flags when [creating a feature flag](#create-a-feature-flag), +or by editing an existing feature flag after creation by navigating to **Operations > Feature Flags** +and clicking **{pencil}** (edit). + +### All users + +Enables the feature for all users. It uses the [`default`](https://unleash.github.io/docs/activation_strategy#default) +Unleash activation strategy. + +### Percent of Users + +Enables the feature for a percentage of authenticated users. It uses the +[`gradualRolloutUserId`](https://unleash.github.io/docs/activation_strategy#gradualrolloutuserid) +Unleash activation strategy. + +For example, set a value of 15% to enable the feature for 15% of authenticated users. + +The rollout percentage can be from 0% to 100%. + +NOTE: **Note:** +Stickiness (consistent application behavior for the same user) is guaranteed for logged-in users, but not anonymous users. + +CAUTION: **Caution:** +If this strategy is selected, then the Unleash client **must** be given a user +ID for the feature to be enabled. See the [Ruby example](#ruby-application-example) below. + +### User IDs + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8240) in GitLab 12.2. [Updated](https://gitlab.com/gitlab-org/gitlab/-/issues/34363) to be defined per environment in GitLab 12.6. + +Enables the feature for a list of target users. It is implemented +using the Unleash [`userWithId`](https://unleash.github.io/docs/activation_strategy#userwithid) +activation strategy. + +Enter user IDs as a comma-separated list of values. For example, +`user@example.com, user2@example.com`, or `username1,username2,username3`, and so on. + +NOTE: **Note:** +User IDs are identifiers for your application users. They do not need to be GitLab users. + +CAUTION: **Caution:** +The Unleash client **must** be given a user ID for the feature to be enabled for +target users. See the [Ruby example](#ruby-application-example) below. + +### User List + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35930) in GitLab 13.1. + +Enables the feature for lists of users created with the [Feature Flag User List API](../api/feature_flag_user_lists.md). +Similar to [User IDs](#user-ids), it uses the Unleash [`userWithId`](https://unleash.github.io/docs/activation_strategy#userwithid) +activation strategy. + +### Enable or disable feature flag strategies + +This feature is under development, but is ready for testing. It's +deployed behind a feature flag that is **disabled by default**. +[GitLab administrators with access to the GitLab Rails console](../administration/feature_flags.md) +can enable it for your instance. + +To enable it: + +```ruby +Feature.enable(:feature_flags_new_version) +``` + +To disable it: + +```ruby +Feature.disable(:feature_flags_new_version) +``` + +## Disable a feature flag for a specific environment + +In [GitLab 13.0 and earlier](https://gitlab.com/gitlab-org/gitlab/-/issues/8621), +to disable a feature flag for a specific environment: + +1. Navigate to your project's **Operations > Feature Flags**. +1. For the feature flag you want to disable, click the Pencil icon. +1. To disable the flag: + + - In GitLab 13.0 and earlier: Slide the Status toggle for the environment. Or, to delete the + environment spec, on the right, click the **Remove (X)** icon. + - In GitLab 13.1 and later: For each strategy it applies to, under **Environments**, delete the environment. + +1. Click **Save changes**. + +## Disable a feature flag for all environments + +To disable a feature flag for all environments: + +1. Navigate to your project's **Operations > Feature Flags**. +1. For the feature flag you want to disable, slide the Status toggle to **Disabled**. + +The feature flag is displayed on the **Disabled** tab. + +## Integrate feature flags with your application + +To use feature flags with your application, get access credentials from GitLab. +Then prepare your application with a client library. + +### Get access credentials + +To get the access credentials that your application needs to communicate with GitLab: + +1. Navigate to your project's **Operations > Feature Flags**. +1. Click the **Configure** button to view the following: + - **API URL**: URL where the client (application) connects to get a list of feature flags. + - **Instance ID**: Unique token that authorizes the retrieval of the feature flags. + - **Application name**: The name of the running environment. For instance, + if the application runs for a production server, the application name would be + `production` or similar. This value is used for the environment spec evaluation. + +NOTE: **Note:** +The meaning of these fields might change over time. For example, we are not sure +if **Instance ID** will be single token or multiple tokens, assigned to the +**Environment**. Also, **Application name** could describe the version of +application instead of the running environment. + +### Choose a client library + +GitLab implements a single backend that is compatible with Unleash clients. + +With the Unleash client, developers can define, in the application code, the default values for flags. +Each feature flag evaluation can express the desired outcome if the flag isn't present in the +provided configuration file. + +Unleash currently [offers many SDKs for various languages and frameworks](https://github.com/Unleash/unleash#client-implementations). + +### Feature flags API information + +For API content, see: + +- [Feature Flags API](../api/feature_flags.md) +- [Feature Flag Specs API](../api/feature_flag_specs.md) (Deprecated and [scheduled for removal in GitLab 14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213369).) +- [Feature Flag User Lists API](../api/feature_flag_user_lists.md) +- [Legacy Feature Flags API](../api/feature_flags_legacy.md) + +### Golang application example + +Here's an example of how to integrate feature flags in a Golang application: + +```golang +package main + +import ( + "io" + "log" + "net/http" + + "github.com/Unleash/unleash-client-go" +) + +type metricsInterface struct { +} + +func init() { + unleash.Initialize( + unleash.WithUrl("https://gitlab.com/api/v4/feature_flags/unleash/42"), + unleash.WithInstanceId("29QmjsW6KngPR5JNPMWx"), + unleash.WithAppName("production"), + unleash.WithListener(&metricsInterface{}), + ) +} + +func helloServer(w http.ResponseWriter, req *http.Request) { + if unleash.IsEnabled("my_feature_name") { + io.WriteString(w, "Feature enabled\n") + } else { + io.WriteString(w, "hello, world!\n") + } +} + +func main() { + http.HandleFunc("/", helloServer) + log.Fatal(http.ListenAndServe(":8080", nil)) +} +``` + +### Ruby application example + +Here's an example of how to integrate feature flags in a Ruby application. + +The Unleash client is given a user ID for use with a **Percent rollout (logged in users)** rollout strategy or a list of **Target Users**. + +```ruby +#!/usr/bin/env ruby + +require 'unleash' +require 'unleash/context' + +unleash = Unleash::Client.new({ + url: 'http://gitlab.com/api/v4/feature_flags/unleash/42', + app_name: 'production', + instance_id: '29QmjsW6KngPR5JNPMWx' +}) + +unleash_context = Unleash::Context.new +# Replace "123" with the id of an authenticated user. +# Note that the context's user id must be a string: +# https://unleash.github.io/docs/unleash_context +unleash_context.user_id = "123" + +if unleash.is_enabled?("my_feature_name", unleash_context) + puts "Feature enabled" +else + puts "hello, world!" +end +``` + +## Feature Flag Related Issues + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36617) in GitLab 13.2. +> - It's deployed behind a feature flag, enabled by default. +> - It's enabled on GitLab.com. +> - It can't be enabled or disabled per-project +> - It's recommended for production use. +> - For GitLab self-managed instances, GitLab administrators can opt to disable it. + +You can link related issues to a feature flag. In the **Linked issues** section, click the `+` button and input the issue reference number or the full URL of the issue. + +This feature is similar to the [related issues](../user/project/issues/related_issues.md) feature. + +### Enable or disable Feature Flag Related Issues **(CORE ONLY)** + +Feature Flag Related Issues is under development but ready for production use. +It is deployed behind a feature flag that is **enabled by default**. +[GitLab administrators with access to the GitLab Rails console](../administration/feature_flags.md) +can opt to disable it for your instance. + +To disable it: + +```ruby +Feature.disable(:feature_flags_issue_links) +``` + +To enable it: + +```ruby +Feature.enable(:feature_flags_issue_links) +``` diff --git a/doc/operations/index.md b/doc/operations/index.md new file mode 100644 index 00000000000..314a1b231ba --- /dev/null +++ b/doc/operations/index.md @@ -0,0 +1,20 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Project operations + +GitLab provides a variety of tools to help operate and maintain +your applications: + +- Collect [Prometheus metrics](../user/project/integrations/prometheus_library/index.md). +- Deploy to different [environments](../ci/environments/index.md). +- Manage your [Alerts](../user/project/operations/alert_management.md) and [Incidents](../user/incident_management/index.md). +- Connect your project to a [Kubernetes cluster](../user/project/clusters/index.md). +- Manage your infrastructure with [Infrastructure as Code](../user/infrastructure/index.md) approaches. +- Discover and view errors generated by your applications with [Error Tracking](../user/project/operations/error_tracking.md). +- Create, toggle, and remove [Feature Flags](feature_flags.md). **(PREMIUM)** +- [Trace](tracing.md) the performance and health of a deployed application. **(ULTIMATE)** +- Change the [settings of the Monitoring Dashboard](../user/project/operations/dashboard_settings.md). diff --git a/doc/operations/metrics/alerts.md b/doc/operations/metrics/alerts.md new file mode 100644 index 00000000000..43debbd1b78 --- /dev/null +++ b/doc/operations/metrics/alerts.md @@ -0,0 +1,110 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Set up alerts for Prometheus metrics + +After [configuring metrics for your CI/CD environment](index.md), you can set up +alerting for Prometheus metrics depending on the location of your instances, and +[trigger actions from alerts](#trigger-actions-from-alerts-ultimate) to notify +your team when environment performance falls outside of the boundaries you set. + +## Managed Prometheus instances + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6590) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.2 for [custom metrics](index.md#adding-custom-metrics), and 11.3 for [library metrics](../../user/project/integrations/prometheus_library/metrics.md). + +For managed Prometheus instances using auto configuration, you can +[configure alerts for metrics](index.md#adding-custom-metrics) directly in the +[metrics dashboard](index.md). To set an alert: + +1. In your project, navigate to **{cloud-gear}** **Operations > Metrics**, +1. Identify the metric you want to create the alert for, and click the + **ellipsis** **{ellipsis_v}** icon in the top right corner of the metric. +1. Choose **Alerts**. +1. Set threshold and operator. +1. Click **Add** to save and activate the alert. + + + +To remove the alert, click back on the alert icon for the desired metric, and click **Delete**. + +## External Prometheus instances + +>- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9258) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.8. +>- [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/42640) to [GitLab Core](https://about.gitlab.com/pricing/) in 12.10. + +For manually configured Prometheus servers, GitLab provides a notify endpoint for +use with Prometheus webhooks. If you have manual configuration enabled, an +**Alerts** section is added to **{settings}** **Settings > Integrations > Prometheus**. +This section contains the **URL** and **Authorization Key** you will need. The +**Reset Key** button will invalidate the key and generate a new one. + + + +To send GitLab alert notifications, copy the **URL** and **Authorization Key** into the +[`webhook_configs`](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config) +section of your Prometheus Alertmanager configuration: + +```yaml +receivers: + name: gitlab + webhook_configs: + - http_config: + bearer_token: 9e1cbfcd546896a9ea8be557caf13a76 + send_resolved: true + url: http://192.168.178.31:3001/root/manual_prometheus/prometheus/alerts/notify.json + ... +``` + +For GitLab to associate your alerts with an [environment](../../ci/environments/index.md), +you must configure a `gitlab_environment_name` label on the alerts you set up in +Prometheus. The value of this should match the name of your environment in GitLab. + +NOTE: **Note:** +In GitLab versions 13.1 and greater, you can configure your manually configured +Prometheus server to use the +[Generic alerts integration](../../user/project/integrations/generic_alerts.md). + +## Trigger actions from alerts **(ULTIMATE)** + +>- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4925) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.11. +>- [From GitLab Ultimate 12.5](https://gitlab.com/gitlab-org/gitlab/-/issues/13401), when GitLab receives a recovery alert, it will automatically close the associated issue. + +Alerts can be used to trigger actions, like opening an issue automatically +(disabled by default since `13.1`). To configure the actions: + +1. Navigate to your project's **{settings}** **Settings > Operations > Incidents**. +1. Enable the option to create issues. +1. Choose the [issue template](../../user/project/description_templates.md) to create the issue from. +1. Optionally, select whether to send an email notification to the developers of the project. +1. Click **Save changes**. + +After enabling, GitLab automatically opens an issue when an alert is triggered containing +values extracted from [alert's payload](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config): + +- Issue author: `GitLab Alert Bot` +- Issue title: Extract from `annotations/title`, `annotations/summary` or `labels/alertname` +- Alert `Summary`: A list of properties + - `starts_at`: Alert start time via `startsAt` + - `full_query`: Alert query extracted from `generatorURL` + - Optional list of attached annotations extracted from `annotations/*` +- Alert [GFM](../../user/markdown.md): GitLab Flavored Markdown from `annotations/gitlab_incident_markdown` + +When GitLab receives a **Recovery Alert**, it closes the associated issue. +This action is recorded as a system message on the issue indicating that it +was closed automatically by the GitLab Alert bot. + +To further customize the issue, you can add labels, mentions, or any other supported +[quick action](../../user/project/quick_actions.md) in the selected issue template, +which applies to all incidents. To limit quick actions or other information to +only specific types of alerts, use the `annotations/gitlab_incident_markdown` field. + +Since [version 12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63373), +GitLab tags each incident issue with the `incident` label automatically. If the label +does not yet exist, it is also created automatically. + +If the metric exceeds the threshold of the alert for over 5 minutes, GitLab sends +an email to all [Maintainers and Owners](../../user/permissions.md#project-members-permissions) +of the project. diff --git a/doc/operations/metrics/dashboards/index.md b/doc/operations/metrics/dashboards/index.md new file mode 100644 index 00000000000..a46abdee2dc --- /dev/null +++ b/doc/operations/metrics/dashboards/index.md @@ -0,0 +1,249 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Using the Metrics Dashboard + +## Manage the metrics dashboard settings + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223204) in GitLab 13.2. + +To manage the settings for your metrics dashboard: + +1. Sign in as a user with project Maintainer or Admin + [permissions](../../../user/permissions.md#project-members-permissions). +1. Navigate to your dashboard at **{cloud-gear}** **Operations > Metrics**. +1. In the top-right corner of your dashboard, click **{settings}** **Metrics Settings**: + +  + +## Chart Context Menu + +From each of the panels in the dashboard, you can access the context menu by clicking the **{ellipsis_v}** **More actions** dropdown box above the upper right corner of the panel to take actions related to the chart's data. + + + +The options are: + +- [Expand panel](#expand-panel) +- [View logs](#view-logs-ultimate) +- [Download CSV](#downloading-data-as-csv) +- [Copy link to chart](../embed.md#embedding-gitlab-managed-kubernetes-metrics) +- [Alerts](../alerts.md) + +### View and edit the source file of a custom dashboard + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34779) in GitLab 12.5. + +When viewing a custom dashboard of a project, you can view the original +`.yml` file by clicking on the **Edit dashboard** button. + +### Expand panel + +> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3100) in GitLab 13.0. + +To view a larger version of a visualization, expand the panel by clicking the +**{ellipsis_v}** **More actions** icon and selecting **Expand panel**. + +To return to the metrics dashboard, click the **Back** button in your +browser, or pressing the <kbd>Esc</kbd> key. + +### View Logs **(ULTIMATE)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/122013) in GitLab 12.8. + +If you have [Logs](../../../user/project/clusters/kubernetes_pod_logs.md) enabled, +you can navigate from the charts in the dashboard to view Logs by +clicking on the context menu in the upper-right corner. + +If you use the **Timeline zoom** function at the bottom of the chart, logs will narrow down to the time range you selected. + +### Timeline zoom and URL sharing + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198910) in GitLab 12.8. + +You can use the **Timeline zoom** function at the bottom of a chart to zoom in +on a date and time of your choice. When you click and drag the sliders to select +a different beginning or end date of data to display, GitLab adds your selected start +and end times to the URL, enabling you to share specific timeframes more easily. + +### Downloading data as CSV + +Data from Prometheus charts on the metrics dashboard can be downloaded as CSV. + +## Dashboard Annotations + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211330) in GitLab 12.10 (enabled by feature flag `metrics_dashboard_annotations`). +> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/215224) in GitLab 13.0. + +You can use **Metrics Dashboard Annotations** to mark any important events on +every metrics dashboard by adding annotations to it. While viewing a dashboard, +annotation entries assigned to the selected time range will be automatically +fetched and displayed on every chart within that dashboard. On mouse hover, each +annotation presents additional details, including the exact time of an event and +its description. + +You can create annotations by making requests to the +[Metrics dashboard annotations API](../../../api/metrics_dashboard_annotations.md) + + + +### Retention policy + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211433) in GitLab 13.01. + +To avoid excessive storage space consumption by stale annotations, records attached +to time periods older than two weeks are removed daily. This recurring background +job runs at 1:00 a.m. local server time. + +## Add related links to custom dashboards + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216385) in GitLab 13.1. + +You can embed links to other dashboards or external services in your custom +dashboard by adding **Related links** to your dashboard's YAML file. Related links +open in the same tab as the dashboard. Related links can be displayed in the +following locations on your dashboard: + +- At the top of your dashboard as the top level [`links` dashboard property](../../../operations/metrics/dashboards/yaml.md#dashboard-top-level-properties). +- In charts context menus as the [`links` property of a panel](../../../operations/metrics/dashboards/yaml.md#panel-panels-properties). + +Related links can contain the following attributes: + +- `url`: The full URL to the link. Required. +- `title`: A phrase describing the link. Optional. If this attribute is not set, + the full URL is used for the link title. +- `type`: A string declaring the type of link. Optional. If set to `grafana`, the + dashboard's time range values are converted to Grafana's time range format and + appended to the `url`. + +The dashboard's time range is appended to the `url` as URL parameters. + +The following example shows two related links (`GitLab.com` and `GitLab Documentation`) +added to a dashboard: + + + +### Links Syntax + +```yaml +links: + - title: GitLab.com + url: https://gitlab.com + - title: GitLab Documentation + url: https://docs.gitlab.com + - title: Public Grafana playground dashboard + url: https://play.grafana.org/d/000000012/grafana-play-home?orgId=1 + type: grafana +``` + +## Defining custom dashboards per project + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/59974) in GitLab 12.1. + +By default, all projects include a GitLab-defined Prometheus dashboard, which +includes a few key metrics, but you can also define your own custom dashboards. + +You may create a new file from scratch or duplicate a GitLab-defined Prometheus +dashboard. + +NOTE: **Note:** +The metrics as defined below do not support alerts, unlike +[custom metrics](../index.md#adding-custom-metrics). + +### Adding a new dashboard to your project + +> UI option [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223204) in GitLab 13.2. + +You can configure a custom dashboard by adding a new YAML file into your project's +`.gitlab/dashboards/` directory. In order for the dashboards to be displayed on +the project's **{cloud-gear}** **Operations > Metrics** page, the files must have a `.yml` +extension and should be present in the project's **default** branch. + +To create a new dashboard from the GitLab user interface: + +1. Sign in to GitLab as a user with Maintainer or Owner + [permissions](../../../user/permissions.md#project-members-permissions). +1. Navigate to your dashboard at **{cloud-gear}** **Operations > Metrics**. +1. In the top-right corner of your dashboard, click the **{file-addition-solid}** **Actions** menu, + and select **Create new**: +  +1. In the modal window, click **Open Repository**, then follow the instructions + for creating a new dashboard from the command line. + +To create a new dashboard from the command line: + +1. Create `.gitlab/dashboards/prom_alerts.yml` under your repository's root + directory. Each YAML file should define the layout of the dashboard and the + Prometheus queries used to populate data. This example dashboard displays a + single area chart: + + ```yaml + dashboard: 'Dashboard Title' + panel_groups: + - group: 'Group Title' + panels: + - type: area-chart + title: "Chart Title" + y_label: "Y-Axis" + y_axis: + format: number + precision: 0 + metrics: + - id: my_metric_id + query_range: 'http_requests_total' + label: "Instance: {{instance}}, method: {{method}}" + unit: "count" + ``` + +1. Save the file, commit, and push to your repository. The file must be present in your **default** branch. +1. Navigate to your project's **Operations > Metrics** and choose the custom + dashboard from the dropdown. + +NOTE: **Note:** +Configuration files nested under subdirectories of `.gitlab/dashboards` are not +supported and will not be available in the UI. + +### Navigating to a custom dashboard + +Custom dashboards are uniquely identified by their filenames. In order to quickly view the custom dashboard, +just use the dashboard filename in the URL this way: +`https://gitlab-instance.example.com/project/-/metrics/custom_dashboard_name.yml`. + +### Duplicating a GitLab-defined dashboard + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/37238) in GitLab 12.7. +> - From [GitLab 12.8 onwards](https://gitlab.com/gitlab-org/gitlab/-/issues/39505), custom metrics are also duplicated when you duplicate a dashboard. + +You can save a complete copy of a GitLab defined dashboard along with all custom metrics added to it. +Resulting `.yml` file can be customized and adapted to your project. +You can decide to save the dashboard `.yml` file in the project's **default** branch or in a +new branch. + +1. Click **Duplicate dashboard** in the dashboard dropdown or in the actions menu. + + NOTE: **Note:** + You can duplicate only GitLab-defined dashboards. + +1. Enter the file name and other information, such as the new commit's message, and click **Duplicate**. + +If you select your **default** branch, the new dashboard becomes immediately available. +If you select another branch, this branch should be merged to your **default** branch first. + +## Troubleshooting + +When troubleshooting issues with a managed Prometheus app, it is often useful to +[view the Prometheus UI](../../../development/prometheus.md#access-the-ui-of-a-prometheus-managed-application-in-kubernetes). + +### "No data found" error on Metrics dashboard page + +If the "No data found" screen continues to appear, it could be due to: + +- No successful deployments have occurred to this environment. +- Prometheus does not have performance data for this environment, or the metrics + are not labeled correctly. To test this, connect to the Prometheus server and + [run a query](../../../user/project/integrations/prometheus_library/kubernetes.md#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG` + with the name of your environment. +- You may need to re-add the GitLab predefined common metrics. This can be done by running the [import common metrics Rake task](../../../administration/raketasks/maintenance.md#import-common-metrics). diff --git a/doc/operations/metrics/dashboards/panel_types.md b/doc/operations/metrics/dashboards/panel_types.md new file mode 100644 index 00000000000..0397218fe0e --- /dev/null +++ b/doc/operations/metrics/dashboards/panel_types.md @@ -0,0 +1,262 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Panel types for dashboards + +The below panel types are supported in monitoring dashboards. + +## Area or Line Chart + +To add an area chart panel type to a dashboard, look at the following sample dashboard file: + +```yaml +dashboard: 'Dashboard Title' +panel_groups: + - group: 'Group Title' + panels: + - type: area-chart # or line-chart + title: 'Area Chart Title' + y_label: "Y-Axis" + y_axis: + format: number + precision: 0 + metrics: + - id: area_http_requests_total + query_range: 'http_requests_total' + label: "Instance: {{instance}}, Method: {{method}}" + unit: "count" +``` + +Note the following properties: + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| type | string | no | Type of panel to be rendered. Optional for area panel types | +| query_range | string | required | For area panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) | + + + +Starting in [version 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/202696), the y-axis values will automatically scale according to the data. Previously, it always started from 0. + +## Anomaly chart + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16530) in GitLab 12.5. + +To add an anomaly chart panel type to a dashboard, add a panel with *exactly* 3 metrics. + +The first metric represents the current state, and the second and third metrics represent the upper and lower limit respectively: + +```yaml +dashboard: 'Dashboard Title' +panel_groups: + - group: 'Group Title' + panels: + - type: anomaly-chart + title: "Chart Title" + y_label: "Y-Axis" + metrics: + - id: anomaly_requests_normal + query_range: 'http_requests_total' + label: "# of Requests" + unit: "count" + metrics: + - id: anomaly_requests_upper_limit + query_range: 10000 + label: "Max # of requests" + unit: "count" + metrics: + - id: anomaly_requests_lower_limit + query_range: 2000 + label: "Min # of requests" + unit: "count" +``` + +Note the following properties: + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| type | string | required | Must be `anomaly-chart` for anomaly panel types | +| query_range | yes | required | For anomaly panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) in every metric. | + + + +## Bar chart + +To add a bar chart to a dashboard, look at the following sample dashboard file: + +```yaml +dashboard: 'Dashboard Title' +panel_groups: + - group: 'Group title' + panels: + - type: bar + title: "Http Handlers" + x_label: 'Response Size' + y_axis: + name: "Handlers" + metrics: + - id: prometheus_http_response_size_bytes_bucket + query_range: "sum(increase(prometheus_http_response_size_bytes_bucket[1d])) by (handler)" + unit: 'Bytes' +``` + +Note the following properties: + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| `type` | string | yes | Type of panel to be rendered. For bar chart types, set to `bar` | +| `query_range` | yes | yes | For bar chart, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) + + + +## Column chart + +To add a column panel type to a dashboard, look at the following sample dashboard file: + +```yaml +dashboard: 'Dashboard Title' +panel_groups: + - group: 'Group title' + panels: + - title: "Column" + type: "column" + metrics: + - id: 1024_memory + query: 'avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024' + unit: MB + label: "Memory Usage" +``` + +Note the following properties: + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| type | string | yes | Type of panel to be rendered. For column panel types, set to `column` | +| query_range | yes | yes | For column panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) | + + + +## Stacked column + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30583) in GitLab 12.8. + +To add a stacked column panel type to a dashboard, look at the following sample dashboard file: + +```yaml +dashboard: 'Dashboard title' +priority: 1 +panel_groups: + - group: 'Group Title' + priority: 5 + panels: + - type: 'stacked-column' + title: "Stacked column" + y_label: "y label" + x_label: 'x label' + metrics: + - id: memory_1 + query_range: 'memory_query' + label: "memory query 1" + unit: "count" + series_name: 'group 1' + - id: memory_2 + query_range: 'memory_query_2' + label: "memory query 2" + unit: "count" + series_name: 'group 2' +``` + + + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| `type` | string | yes | Type of panel to be rendered. For stacked column panel types, set to `stacked-column` | +| `query_range` | yes | yes | For stacked column panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) | + +## Single Stat + +To add a single stat panel type to a dashboard, look at the following sample dashboard file: + +```yaml +dashboard: 'Dashboard Title' +panel_groups: + - group: 'Group Title' + panels: + - title: "Single Stat" + type: "single-stat" + metrics: + - id: 10 + query: 'max(go_memstats_alloc_bytes{job="prometheus"})' + unit: MB + label: "Total" +``` + +Note the following properties: + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| type | string | yes | Type of panel to be rendered. For single stat panel types, set to `single-stat` | +| field | string | no | Panels display the value of a metric. For a panel to display the value of a label instead, put the name of the label in this key. | +| query | string | yes | For single stat panel types, you must use an [instant query](https://prometheus.io/docs/prometheus/latest/querying/api/#instant-queries) | + + + +## Percentile based results + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/201946) in GitLab 12.8. + +Query results sometimes need to be represented as a percentage value out of 100. You can use the `max_value` property at the root of the panel definition: + +```yaml +dashboard: 'Dashboard Title' +panel_groups: + - group: 'Group Title' + panels: + - title: "Single Stat" + type: "single-stat" + max_value: 100 + metrics: + - id: 10 + query: 'max(go_memstats_alloc_bytes{job="prometheus"})' + unit: '%' + label: "Total" +``` + +For example, if you have a query value of `53.6`, adding `%` as the unit results in a single stat value of `53.6%`, but if the maximum expected value of the query is `120`, the value would be `44.6%`. Adding the `max_value` causes the correct percentage value to display. + +## Heatmaps + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30581) in GitLab 12.5. + +To add a heatmap panel type to a dashboard, look at the following sample dashboard file: + +```yaml +dashboard: 'Dashboard Title' +panel_groups: + - group: 'Group Title' + panels: + - title: "Heatmap" + type: "heatmap" + metrics: + - id: 10 + query: 'sum(rate(nginx_upstream_responses_total{upstream=~"%{kube_namespace}-%{ci_environment_slug}-.*"}[60m])) by (status_code)' + unit: req/sec + label: "Status code" +``` + +Note the following properties: + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| type | string | yes | Type of panel to be rendered. For heatmap panel types, set to `heatmap` | +| query_range | yes | yes | For area panel types, you must use a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries) | + + + +CAUTION: **Warning:** +When a query returns too many data points, the heatmap data bucket dimensions tend downwards to 0, making the chart's data invisible, as shown in the image below. To fix this problem, limit the amount of data returned by changing the time range filter on the metrics dashboard UI, or adding the **step** property to your dashboard's YAML file. + + diff --git a/doc/operations/metrics/dashboards/templating_variables.md b/doc/operations/metrics/dashboards/templating_variables.md new file mode 100644 index 00000000000..a515742ea92 --- /dev/null +++ b/doc/operations/metrics/dashboards/templating_variables.md @@ -0,0 +1,128 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Templating variables for metrics dashboards + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214539) in GitLab 13.0. + +Templating variables can be used to make your metrics dashboard more versatile. + +`templating` is a top-level key in the +[dashboard YAML](yaml.md#dashboard-top-level-properties). +Define your variables in the `variables` key, under `templating`. The value of +the `variables` key should be a hash, and each key under `variables` +defines a templating variable on the dashboard, and may contain alphanumeric and underscore characters. + +A variable can be used in a Prometheus query in the same dashboard using the syntax +described [in Using Variables](variables.md). + +## `text` variable type + +CAUTION: **Warning:** +This variable type is an _alpha_ feature, and is subject to change at any time +without prior notice! + +For each `text` variable defined in the dashboard YAML, there will be a free text +box on the dashboard UI, allowing you to enter a value for each variable. + +The `text` variable type supports a simple and a full syntax. + +### Simple syntax + +This example creates a variable called `variable1`, with a default value +of `default value`: + +```yaml +templating: + variables: + variable1: 'default value' # `text` type variable with `default value` as its default. +``` + +### Full syntax + +This example creates a variable called `variable1`, with a default value of `default`. +The label for the text box on the UI will be the value of the `label` key: + +```yaml +templating: + variables: + variable1: # The variable name that can be used in queries. + label: 'Variable 1' # (Optional) label that will appear in the UI for this text box. + type: text + options: + default_value: 'default' # (Optional) default value. +``` + +## `custom` variable type + +CAUTION: **Warning:** +This variable type is an _alpha_ feature, and is subject to change at any time +without prior notice! + +Each `custom` variable defined in the dashboard YAML creates a dropdown +selector on the dashboard UI, allowing you to select a value for each variable. + +The `custom` variable type supports a simple and a full syntax. + +### Simple syntax + +This example creates a variable called `variable1`, with a default value of `value1`. +The dashboard UI will display a dropdown with `value1`, `value2` and `value3` +as the choices. + +```yaml +templating: + variables: + variable1: ['value1', 'value2', 'value3'] +``` + +### Full syntax + +This example creates a variable called `variable1`, with a default value of `value_option_2`. +The label for the text box on the UI will be the value of the `label` key. +The dashboard UI will display a dropdown with `Option 1` and `Option 2` +as the choices. + +If you select `Option 1` from the dropdown, the variable will be replaced with `value option 1`. +Similarly, if you select `Option 2`, the variable will be replaced with `value_option_2`: + +```yaml +templating: + variables: + variable1: # The variable name that can be used in queries. + label: 'Variable 1' # (Optional) label that will appear in the UI for this dropdown. + type: custom + options: + values: + - value: 'value option 1' # The value that will replace the variable in queries. + text: 'Option 1' # (Optional) Text that will appear in the UI dropdown. + - value: 'value_option_2' + text: 'Option 2' + default: true # (Optional) This option should be the default value of this variable. +``` + +## `metric_label_values` variable type + +CAUTION: **Warning:** +This variable type is an _alpha_ feature, and is subject to change at any time +without prior notice! + +### Full syntax + +This example creates a variable called `variable2`. The values of the dropdown will +be all the different values of the `backend` label in the Prometheus series described by +`up{env="production"}`. + +```yaml +templating: + variables: + variable2: # The variable name that can be interpolated in queries. + label: 'Variable 2' # (Optional) label that will appear in the UI for this dropdown. + type: metric_label_values + options: + series_selector: 'up{env="production"}' + label: 'backend' +``` diff --git a/doc/operations/metrics/dashboards/variables.md b/doc/operations/metrics/dashboards/variables.md new file mode 100644 index 00000000000..19b77a1ed87 --- /dev/null +++ b/doc/operations/metrics/dashboards/variables.md @@ -0,0 +1,59 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Using Variables + +## Query Variables + +Variables can be specified using double curly braces, such as `"{{ci_environment_slug}}"` ([added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20793) in GitLab 12.7). + +Support for the `"%{ci_environment_slug}"` format was +[removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31581) in GitLab 13.0. +Queries that continue to use the old format will show no data. + +## Predefined variables + +GitLab supports a limited set of [CI variables](../../../ci/variables/README.md) in the Prometheus query. This is particularly useful for identifying a specific environment, for example with `ci_environment_slug`. The supported variables are: + +- `ci_environment_slug` +- `kube_namespace` +- `ci_project_name` +- `ci_project_namespace` +- `ci_project_path` +- `ci_environment_name` +- `__range` + +NOTE: **Note:** +Variables for Prometheus queries must be lowercase. + +### __range + +The `__range` variable is useful in Prometheus +[range vector selectors](https://prometheus.io/docs/prometheus/latest/querying/basics/#range-vector-selectors). +Its value is the total number of seconds in the dashboard's time range. +For example, if the dashboard time range is set to 8 hours, the value of +`__range` is `28800s`. + +## User-defined variables + +[Variables can be defined](../../../operations/metrics/dashboards/yaml.md#templating-templating-properties) in a custom dashboard YAML file. + +## Query Variables from URL + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214500) in GitLab 13.0. + +GitLab supports setting custom variables through URL parameters. Surround the variable +name with double curly braces (`{{example}}`) to interpolate the variable in a query: + +```plaintext +avg(sum(container_memory_usage_bytes{container_name!="{{pod}}"}) by (job)) without (job) /1024/1024/1024' +``` + +The URL for this query would be: + +```plaintext +http://gitlab.com/<user>/<project>/-/environments/<environment_id>/metrics?dashboard=.gitlab%2Fdashboards%2Fcustom.yml&pod=POD +``` diff --git a/doc/operations/metrics/dashboards/yaml.md b/doc/operations/metrics/dashboards/yaml.md new file mode 100644 index 00000000000..6a4158798bc --- /dev/null +++ b/doc/operations/metrics/dashboards/yaml.md @@ -0,0 +1,166 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Dashboard YAML properties + +Dashboards have several components: + +- Templating variables. +- Panel groups, which consist of panels. +- Panels, which support one or more metrics. + +The following tables outline the details of expected properties. + +## **Dashboard (top-level) properties** + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| `dashboard` | string | yes | Heading for the dashboard. Only one dashboard should be defined per file. | +| `panel_groups` | array | yes | The panel groups which should be on the dashboard. | +| `templating` | hash | no | Top level key under which templating related options can be added. | +| `links` | array | no | Add links to display on the dashboard. | + +## **Templating (`templating`) properties** + +| Property | Type | Required | Description | +| -------- | ---- | -------- | ----------- | +| `variables` | hash | yes | Variables can be defined here. | + +Read the documentation on [templating](templating_variables.md). + +## **Links (`links`) properties** + +| Property | Type | Required | Description | +| -------- | ---- | -------- | ----------- | +| `url` | string | yes | The address of the link. | +| `title` | string | no | Display title for the link. | +| `type` | string | no | Type of the link. Specifies the link type, can be: `grafana` | + +Read the documentation on [links](index.md#add-related-links-to-custom-dashboards). + +## **Panel group (`panel_groups`) properties** + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| `group` | string | required | Heading for the panel group. | +| `priority` | number | optional, defaults to order in file | Order to appear on the dashboard. Higher number means higher priority, which will be higher on the page. Numbers do not need to be consecutive. | +| `panels` | array | required | The panels which should be in the panel group. | + +Panels in a panel group are laid out in rows consisting of two panels per row. An exception to this rule are single panels on a row: these panels will take the full width of their containing row. + +## **Panel (`panels`) properties** + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------- | +| `type` | enum | no, defaults to `area-chart` | Specifies the panel type to use, for example `area-chart`, `line-chart` or `anomaly-chart`. [View documentation on all panel types.](panel_types.md) | +| `title` | string | yes | Heading for the panel. | +| `y_label` | string | no, but highly encouraged | Y-Axis label for the panel. | +| `y_axis` | string | no | Y-Axis configuration for the panel. | +| `max_value` | number | no | Denominator value used for calculating [percentile based results](panel_types.md#percentile-based-results) | +| `weight` | number | no, defaults to order in file | Order to appear within the grouping. Lower number means higher priority, which will be higher on the page. Numbers do not need to be consecutive. | +| `metrics` | array | yes | The metrics which should be displayed in the panel. Any number of metrics can be displayed when `type` is `area-chart` or `line-chart`, whereas only 3 can be displayed when `type` is `anomaly-chart`. | +| `links` | array | no | Add links to display on the chart's [context menu](index.md#chart-context-menu). | + +## **Axis (`panels[].y_axis`) properties** + +| Property | Type | Required | Description | +| ----------- | ------ | ----------------------------- | -------------------------------------------------------------------- | +| `name` | string | no, but highly encouraged | Y-Axis label for the panel. Replaces `y_label` if set. | +| `format` | string | no, defaults to `engineering` | Unit format used. See the [full list of units](yaml_number_format.md). | +| `precision` | number | no, defaults to `2` | Number of decimal places to display in the number. | | + +## **Metrics (`metrics`) properties** + +| Property | Type | Required | Description | +| ------ | ------ | ------ | ------ | +| `id` | string | no | Used for associating dashboard metrics with database records. Must be unique across dashboard configuration files. Required for [alerting](../alerts.md) (support not yet enabled, see [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/27980)). | +| `unit` | string | yes | Defines the unit of the query's return data. | +| `label` | string | no, but highly encouraged | Defines the legend-label for the query. Should be unique within the panel's metrics. Can contain time series labels as interpolated variables. | +| `query` | string | yes if `query_range` is not defined | Defines the Prometheus query to be used to populate the chart/panel. If defined, the `query` endpoint of the [Prometheus API](https://prometheus.io/docs/prometheus/latest/querying/api/) will be utilized. | +| `query_range` | string | yes if `query` is not defined | Defines the Prometheus query to be used to populate the chart/panel. If defined, the `query_range` endpoint of the [Prometheus API](https://prometheus.io/docs/prometheus/latest/querying/api/) will be utilized. | +| `step` | number | no, value is calculated if not defined | Defines query resolution step width in float number of seconds. Metrics on the same panel should use the same `step` value. | + +## Dynamic labels + +Dynamic labels are useful when multiple time series are returned from a Prometheus query. + +When a static label is used and a query returns multiple time series, then all the legend items will be labeled the same, which makes identifying each time series difficult: + +```yaml +metrics: + - id: my_metric_id + query_range: 'http_requests_total' + label: "Time Series" + unit: "count" +``` + +This may render a legend like this: + + + +For labels to be more explicit, using variables that reflect time series labels is a good practice. The variables will be replaced by the values of the time series labels when the legend is rendered: + +```yaml +metrics: + - id: my_metric_id + query_range: 'http_requests_total' + label: "Instance: {{instance}}, method: {{method}}" + unit: "count" +``` + +The resulting rendered legend will look like this: + + + +There is also a shorthand value for dynamic dashboard labels that make use of only one time series label: + +```yaml +metrics: + - id: my_metric_id + query_range: 'http_requests_total' + label: "Method" + unit: "count" +``` + +This works by lowercasing the value of `label` and, if there are more words separated by spaces, replacing those spaces with an underscore (`_`). The transformed value is then checked against the labels of the time series returned by the Prometheus query. If a time series label is found that is equal to the transformed value, then the label value will be used and rendered in the legend like this: + + + +## Dashboard YAML syntax validation + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33202) in GitLab 13.1. + +To confirm your dashboard definition contains valid YAML syntax: + +1. Navigate to **{doc-text}** **Repository > Files**. +1. Navigate to your dashboard file in your repository. +1. Review the information pane about the file, displayed above the file contents. + +Files with valid syntax display **Metrics Dashboard YAML definition is valid**, +and files with invalid syntax display **Metrics Dashboard YAML definition is invalid**. + + + +When **Metrics Dashboard YAML definition is invalid** at least one of the following messages is displayed: + +1. `dashboard: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.md#dashboard-top-level-properties) +1. `panel_groups: should be an array of panel_groups objects` [learn more](../../../operations/metrics/dashboards/yaml.md#dashboard-top-level-properties) +1. `group: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.md#panel-group-panel_groups-properties) +1. `panels: should be an array of panels objects` [learn more](../../../operations/metrics/dashboards/yaml.md#panel-group-panel_groups-properties) +1. `title: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.md#panel-panels-properties) +1. `metrics: should be an array of metrics objects` [learn more](../../../operations/metrics/dashboards/yaml.md#panel-panels-properties) +1. `query: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.md#metrics-metrics-properties) +1. `query_range: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.md#metrics-metrics-properties) +1. `unit: can't be blank` [learn more](../../../operations/metrics/dashboards/yaml.md#metrics-metrics-properties) +1. `YAML syntax: The parsed YAML is too big` + + This is displayed when the YAML file is larger than 1 MB. + +1. `YAML syntax: Invalid configuration format` + + This is displayed when the YAML file is empty or does not contain valid YAML. + +Metrics Dashboard YAML definition validation information is also available as a [GraphQL API field](../../../api/graphql/reference/index.md#metricsdashboard) diff --git a/doc/operations/metrics/dashboards/yaml_number_format.md b/doc/operations/metrics/dashboards/yaml_number_format.md new file mode 100644 index 00000000000..ae0cd9fff64 --- /dev/null +++ b/doc/operations/metrics/dashboards/yaml_number_format.md @@ -0,0 +1,177 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Unit formats reference + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/201999) in GitLab 12.9. + +Format the data in your dashboard panels. + +You can select units to format your charts by adding `format` to your +[axis configuration](yaml.md). + +## Internationalization and localization + +Currently, your [internationalization and localization options](https://en.wikipedia.org/wiki/Internationalization_and_localization) for number formatting are dependent on the system you are using i.e. your OS or browser. + +## Engineering Notation + +For generic or default data, numbers are formatted according to the current locale in [engineering notation](https://en.wikipedia.org/wiki/Engineering_notation). + +While an [engineering notation exists for the web](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat), GitLab uses a version based off the [scientific notation](https://en.wikipedia.org/wiki/Scientific_notation). GitLab formatting acts in accordance with SI prefixes. For example, using GitLab notation, `1500.00` becomes `1.5k` instead of `1.5E3`. Keep this distinction in mind when using the engineering notation for your metrics. + +Formats: `engineering` + +SI prefixes: + +| Name | Symbol | Value | +| ---------- | ------- | -------------------------- | +| `yotta` | Y | 1000000000000000000000000 | +| `zetta` | Z | 1000000000000000000000 | +| `exa` | E | 1000000000000000000 | +| `peta` | P | 1000000000000000 | +| `tera` | T | 1000000000000 | +| `giga` | G | 1000000000 | +| `mega` | M | 1000000 | +| `kilo` | k | 1000 | +| `milli` | m | 0.001 | +| `micro` | μ | 0.000001 | +| `nano` | n | 0.000000001 | +| `pico` | p | 0.000000000001 | +| `femto` | f | 0.000000000000001 | +| `atto` | a | 0.000000000000000001 | +| `zepto` | z | 0.000000000000000000001 | +| `yocto` | y | 0.000000000000000000000001 | + +**Examples:** + +| Data | Displayed | +| --------------------------------- | --------- | +| `0.000000000000000000000008` | 8y | +| `0.000000000000000000008` | 8z | +| `0.000000000000000008` | 8a | +| `0.000000000000008` | 8f | +| `0.000000000008` | 8p | +| `0.000000008` | 8n | +| `0.000008` | 8μ | +| `0.008` | 8m | +| `10` | 10 | +| `1080` | 1.08k | +| `18000` | 18k | +| `18888` | 18.9k | +| `188888` | 189k | +| `18888888` | 18.9M | +| `1888888888` | 1.89G | +| `1888888888888` | 1.89T | +| `1888888888888888` | 1.89P | +| `1888888888888888888` | 1.89E | +| `1888888888888888888888` | 1.89Z | +| `1888888888888888888888888` | 1.89Y | +| `1888888888888888888888888888` | 1.89e+27 | + +## Numbers + +For number data, numbers are formatted according to the current locale. + +Formats: `number` + +**Examples:** + +| Data | Displayed | +| ---------- | --------- | +| `10` | 1 | +| `1000` | 1,000 | +| `1000000` | 1,000,000 | + +## Percentage + +For percentage data, format numbers in the chart with a `%` symbol. + +Formats supported: `percent`, `percentHundred` + +**Examples:** + +| Format | Data | Displayed | +| ---------------- | ----- | --------- | +| `percent` | `0.5` | 50% | +| `percent` | `1` | 100% | +| `percent` | `2` | 200% | +| `percentHundred` | `50` | 50% | +| `percentHundred` | `100` | 100% | +| `percentHundred` | `200` | 200% | + +## Duration + +For time durations, format numbers in the chart with a time unit symbol. + +Formats supported: `milliseconds`, `seconds` + +**Examples:** + +| Format | Data | Displayed | +| -------------- | ------ | --------- | +| `milliseconds` | `10` | 10ms | +| `milliseconds` | `500` | 100ms | +| `milliseconds` | `1000` | 1000ms | +| `seconds` | `10` | 10s | +| `seconds` | `500` | 500s | +| `seconds` | `1000` | 1000s | + +## Digital (Metric) + +Converts a number of bytes using metric prefixes. It scales to +use the unit that's the best fit. + +Formats supported: + +- `decimalBytes` +- `kilobytes` +- `megabytes` +- `gigabytes` +- `terabytes` +- `petabytes` + +**Examples:** + +| Format | Data | Displayed | +| -------------- | --------- | --------- | +| `decimalBytes` | `1` | 1B | +| `decimalBytes` | `1000` | 1kB | +| `decimalBytes` | `1000000` | 1MB | +| `kilobytes` | `1` | 1kB | +| `kilobytes` | `1000` | 1MB | +| `kilobytes` | `1000000` | 1GB | +| `megabytes` | `1` | 1MB | +| `megabytes` | `1000` | 1GB | +| `megabytes` | `1000000` | 1TB | + +## Digital (IEC) + +Converts a number of bytes using binary prefixes. It scales to +use the unit that's the best fit. + +Formats supported: + +- `bytes` +- `kibibytes` +- `mebibytes` +- `gibibytes` +- `tebibytes` +- `pebibytes` + +**Examples:** + +| Format | Data | Displayed | +| ----------- | ------------- | --------- | +| `bytes` | `1` | 1B | +| `bytes` | `1024` | 1KiB | +| `bytes` | `1024 * 1024` | 1MiB | +| `kibibytes` | `1` | 1KiB | +| `kibibytes` | `1024` | 1MiB | +| `kibibytes` | `1024 * 1024` | 1GiB | +| `mebibytes` | `1` | 1MiB | +| `mebibytes` | `1024` | 1GiB | +| `mebibytes` | `1024 * 1024` | 1TiB | diff --git a/doc/operations/metrics/embed.md b/doc/operations/metrics/embed.md new file mode 100644 index 00000000000..5ee9b0859b9 --- /dev/null +++ b/doc/operations/metrics/embed.md @@ -0,0 +1,93 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Embedding metric charts within GitLab Flavored Markdown + +## Embedding GitLab-managed Kubernetes metrics + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29691) in GitLab 12.2. + +It is possible to display metrics charts within [GitLab Flavored Markdown](../../user/markdown.md#gitlab-flavored-markdown-gfm) fields such as issue or merge request descriptions. The maximum number of embedded charts allowed in a GitLab Flavored Markdown field is 100. + +This can be useful if you are sharing an application incident or performance +metrics to others and want to have relevant information directly available. + +NOTE: **Note:** +Requires [Kubernetes](../../user/project/integrations/prometheus_library/kubernetes.md) metrics. + +To display metric charts, include a link of the form `https://<root_url>/<project>/-/environments/<environment_id>/metrics`: + + + +GitLab unfurls the link as an embedded metrics panel: + + + +You can also embed a single chart. To get a link to a chart, click the +**{ellipsis_v}** **More actions** menu in the upper right corner of the chart, +and select **Copy link to chart**, as shown in this example: + + + +The following requirements must be met for the metric to unfurl: + +- The `<environment_id>` must correspond to a real environment. +- Prometheus must be monitoring the environment. +- The GitLab instance must be configured to receive data from the environment. +- The user must be allowed access to the monitoring dashboard for the environment ([Reporter or higher](../../user/permissions.md)). +- The dashboard must have data within the last 8 hours. + + If all of the above are true, then the metric will unfurl as seen below: + + + +Metric charts may also be hidden: + + + +You can open the link directly into your browser for a [detailed view of the data](dashboards/index.md#expand-panel). + +## Embedding metrics in issue templates + +It is also possible to embed either the default dashboard metrics or individual metrics in issue templates. For charts to render side-by-side, links to the entire metrics dashboard or individual metrics should be separated by either a comma or a space. + + + +## Embedding metrics based on alerts in incident issues + +For [GitLab-managed alerting rules](alerts.md), the issue will include an embedded chart for the query corresponding to the alert. The chart displays an hour of data surrounding the starting point of the incident, 30 minutes before and after. + +For [manually configured Prometheus instances](../../user/project/integrations/prometheus.md#manual-configuration-of-prometheus), a chart corresponding to the query can be included if these requirements are met: + +- The alert corresponds to an environment managed through GitLab. +- The alert corresponds to a [range query](https://prometheus.io/docs/prometheus/latest/querying/api/#range-queries). +- The alert contains the required attributes listed in the chart below. + +| Attributes | Required | Description | +| ---------- | -------- | ----------- | +| `annotations/gitlab_environment_name` | Yes | Name of the GitLab-managed environment corresponding to the alert | +| One of `annotations/title`, `annotations/summary`, `labels/alertname` | Yes | Will be used as the chart title | +| `annotations/gitlab_y_label` | No | Will be used as the chart's y-axis label | + +## Embedding cluster health charts + +> - [Introduced](<https://gitlab.com/gitlab-org/gitlab/-/issues/40997>) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9. +> - [Moved](<https://gitlab.com/gitlab-org/gitlab/-/issues/208224>) to GitLab core in 13.2. + +[Cluster Health Metrics](../../user/project/clusters/index.md#visualizing-cluster-health) can also be embedded in [GitLab-flavored Markdown](../../user/markdown.md). + +To embed a metric chart, include a link to that chart in the form `https://<root_url>/<project>/-/cluster/<cluster_id>?<query_params>` anywhere that GitLab-flavored Markdown is supported. To generate and copy a link to the chart, follow the instructions in the [Cluster Health Metric documentation](../../user/project/clusters/index.md#visualizing-cluster-health). + +The following requirements must be met for the metric to unfurl: + +- The `<cluster_id>` must correspond to a real cluster. +- Prometheus must be monitoring the cluster. +- The user must be allowed access to the project cluster metrics. +- The dashboards must be reporting data on the [Cluster Health Page](../../user/project/clusters/index.md#visualizing-cluster-health) + + If the above requirements are met, then the metric will unfurl as seen below. + + diff --git a/doc/operations/metrics/embed_grafana.md b/doc/operations/metrics/embed_grafana.md new file mode 100644 index 00000000000..427ad866442 --- /dev/null +++ b/doc/operations/metrics/embed_grafana.md @@ -0,0 +1,65 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Embedding Grafana charts + +Grafana metrics can be embedded in [GitLab Flavored Markdown](../../user/markdown.md). + +## Embedding charts via Grafana Rendered Images + +It is possible to embed live [Grafana](https://docs.gitlab.com/omnibus/settings/grafana.html) charts in issues, as a [direct linked rendered image](https://grafana.com/docs/grafana/latest/reference/share_panel/#direct-link-rendered-image). + +The sharing dialog within Grafana provides the link, as highlighted below. + + + +NOTE: **Note:** +For this embed to display correctly, the Grafana instance must be available to the target user, either as a public dashboard, or on the same network. + +Copy the link and add an image tag as [inline HTML](../../user/markdown.md#inline-html) in your Markdown. You may tweak the query parameters as required. For instance, removing the `&from=` and `&to=` parameters will give you a live chart. Here is example markup for a live chart from GitLab's public dashboard: + +```html +<img src="https://dashboards.gitlab.com/d/RZmbBr7mk/gitlab-triage?orgId=1&refresh=30s&var-env=gprd&var-environment=gprd&var-prometheus=prometheus-01-inf-gprd&var-prometheus_app=prometheus-app-01-inf-gprd&var-backend=All&var-type=All&var-stage=main&from=1580444107655&to=1580465707655"/> +``` + +This will render like so: + + + +## Embedding charts via integration with Grafana HTTP API + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31376) in GitLab 12.5. + +Each project can support integration with one Grafana instance. This configuration allows a user to copy a link to a panel in Grafana, then paste it into a GitLab Markdown field. The chart will be rendered in the GitLab chart format. + +Prerequisites for embedding from a Grafana instance: + +1. The datasource must be a Prometheus instance. +1. The datasource must be proxyable, so the HTTP Access setting should be set to `Server`. + + + +## Setting up the Grafana integration + +1. [Generate an Admin-level API Token in Grafana.](https://grafana.com/docs/grafana/latest/http_api/auth/#create-api-token) +1. In your GitLab project, navigate to **Settings > Operations > Grafana Authentication**. +1. To enable the integration, check the "Active" checkbox. +1. For "Grafana URL", enter the base URL of the Grafana instance. +1. For "API Token", enter the Admin API Token you just generated. +1. Click **Save Changes**. + +## Generating a link to a chart + +1. In Grafana, navigate to the dashboard you wish to embed a panel from. +  +1. In the upper-left corner of the page, select a specific value for each variable required for the queries in the chart. +  +1. In Grafana, click on a panel's title, then click **Share** to open the panel's sharing dialog to the **Link** tab. If you click the _dashboard's_ share panel instead, GitLab will attempt to embed the first supported panel on the dashboard (if available). +1. If your Prometheus queries use Grafana's custom template variables, ensure that the "Template variables" option is toggled to **On**. Of Grafana global template variables, only `$__interval`, `$__from`, and `$__to` are currently supported. Toggle **On** the "Current time range" option to specify the time range of the chart. Otherwise, the default range will be the last 8 hours. +  +1. Click **Copy** to copy the URL to the clipboard. +1. In GitLab, paste the URL into a Markdown field and save. The chart will take a few moments to render. +  diff --git a/doc/operations/metrics/img/example-dashboard_v13_1.png b/doc/operations/metrics/img/example-dashboard_v13_1.png Binary files differnew file mode 100644 index 00000000000..0cda4ece689 --- /dev/null +++ b/doc/operations/metrics/img/example-dashboard_v13_1.png diff --git a/doc/operations/metrics/index.md b/doc/operations/metrics/index.md new file mode 100644 index 00000000000..12088884f44 --- /dev/null +++ b/doc/operations/metrics/index.md @@ -0,0 +1,142 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Monitor metrics for your CI/CD environment + +After [configuring Prometheus for a cluster](../../user/project/integrations/prometheus.md), +GitLab attempts to retrieve performance metrics for any [environment](../../ci/environments/index.md) with +a successful deployment. + +GitLab scans the Prometheus server for metrics from known servers like Kubernetes +and NGINX, and attempts to identify individual environments. To learn more about +the supported metrics and scan processes, see the +[Prometheus Metrics Library documentation](../../user/project/integrations/prometheus_library/index.md). + +To view the metrics dashboard for an environment that has +[completed at least one deployment](#populate-your-metrics-dashboard): + +1. *If the metrics dashboard is only visible to project members,* sign in to + GitLab as a member of a project. Learn more about [metrics dashboard visibility](#metrics-dashboard-visibility). +1. In your project, navigate to **{cloud-gear}** **Operations > Metrics**. + +GitLab displays the default metrics dashboard for the environment, like the +following example: + + + +The top of the dashboard contains a navigation bar. From left to right, the +navigation bar contains: + +- **Dashboard** - A dropdown list of all dashboards available for the project, + with starred dashboards listed first. +- **Environment** - A dropdown list of all [environments](../index.md) that searches + through all environments as you type. +- **Range** - The time period of data to display. +- **Refresh dashboard** **{retry}** - Reload the dashboard with current data. +- **Set refresh rate** - Set a time frame for refreshing the data displayed. +- **Star dashboard** **{star-o}** - Click to mark a dashboard as a favorite. + Starred dashboards display a solid star **{star}** button, and display first + in the **Dashboard** dropdown list. + ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214582) in GitLab 13.0.) +- **Create dashboard** **{file-addition-solid}** - Create a + [new custom dashboard for your project](dashboards/index.md#adding-a-new-dashboard-to-your-project). +- **Metrics settings** **{settings}** - Configure the + [settings for this dashboard](dashboards/index.md#manage-the-metrics-dashboard-settings). + +## Populate your metrics dashboard + +After [configuring Prometheus for a cluster](../../user/project/integrations/prometheus.md), +you must also deploy code for the **{cloud-gear}** **Operations > Metrics** page +to contain data. Setting up [Auto DevOps](../../topics/autodevops/index.md) +helps quickly create a deployment: + +1. Navigate to your project's **{cloud-gear}** **Operations > Kubernetes** page. +1. Ensure that, in addition to Prometheus, you also have Runner and Ingress + installed. +1. After installing Ingress, copy its endpoint. +1. Navigate to your project's **{settings}** **Settings > CI/CD** page. In the + **Auto DevOps** section, select a deployment strategy and save your changes. +1. On the same page, in the **Variables** section, add a variable named + `KUBE_INGRESS_BASE_DOMAIN` with the value of the Ingress endpoint you + copied previously. Leave the type as **Variable**. +1. Navigate to your project's **{rocket}** **CI/CD > Pipelines** page, and run a + pipeline on any branch. +1. When the pipeline has run successfully, graphs are available on the + **{cloud-gear}** **Operations > Metrics** page. + + + +## Customize your metrics dashboard + +After creating your dashboard, you can customize it to meet your needs: + +- **Add custom metrics**: In addition to the GitLab default metrics, you can + [create custom metrics](#adding-custom-metrics) and display them on your metrics dashboard. +- **Configure alerts for metrics**: [Configure custom alerts](alerts.md) for your team when + environment performance falls outside of the boundaries you set. +- **Trigger actions from alerts**: [Open new issues for your team](alerts.md#trigger-actions-from-alerts-ultimate) **(ULTIMATE)** + when environment performance falls outside of the boundaries you set. + +## Metrics dashboard visibility + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/201924) in GitLab 13.0. + +You can set the visibility of the metrics dashboard to **Only Project Members** +or **Everyone With Access**. When set to **Everyone with Access**, the metrics +dashboard is visible to authenticated and non-authenticated users. + +## Adding custom metrics + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3799) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.6. +> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28527) to [GitLab Core](https://about.gitlab.com/pricing/) 12.10. + +Custom metrics can be monitored by adding them on the monitoring dashboard page. +After saving them, they display on the environment metrics dashboard provided that either: + +- A [connected Kubernetes cluster](../../user/project/clusters/add_remove_clusters.md) + with the matching [environment scope](../../ci/environments/index.md#scoping-environments-with-specs) is used and + [Prometheus installed on the cluster](../../user/project/integrations/prometheus.md#enabling-prometheus-integration). +- Prometheus is [manually configured](../../user/project/integrations/prometheus.md#manual-configuration-of-prometheus). + + + +A few fields are required: + +- **Name**: Chart title +- **Type**: Type of metric. Metrics of the same type will be shown together. +- **Query**: Valid [PromQL query](https://prometheus.io/docs/prometheus/latest/querying/basics/). +- **Y-axis label**: Y axis title to display on the dashboard. +- **Unit label**: Query units, for example `req / sec`. Shown next to the value. + +Multiple metrics can be displayed on the same chart if the fields **Name**, **Type**, +and **Y-axis label** match between metrics. For example, a metric with **Name** +`Requests Rate`, **Type** `Business`, and **Y-axis label** `rec / sec` would display +on the same chart as a second metric with the same values. A **Legend label** is +suggested if this feature is used. + +## Editing additional metrics from the dashboard + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208976) in GitLab 12.9. + +You can edit existing additional custom metrics for your dashboard by clicking the +**{ellipsis_v}** **More actions** dropdown and selecting **Edit metric**. + + + +## Keyboard shortcuts for charts + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202146) in GitLab 13.2. + +You can use keyboard shortcuts to interact more quickly with your currently-focused +chart panel. To activate keyboard shortcuts, use keyboard tabs to highlight the +**{ellipsis_v}** **More actions** dropdown menu, or hover over the dropdown menu +with your mouse, then press the key corresponding to your desired action: + +- **Expand panel** - <kbd>e</kbd> +- **View logs** - <kbd>l</kbd> (lowercase 'L') +- **Download CSV** - <kbd>d</kbd> +- **Copy link to chart** - <kbd>c</kbd> +- **Alerts** - <kbd>a</kbd> diff --git a/doc/operations/tracing.md b/doc/operations/tracing.md new file mode 100644 index 00000000000..07f60c37f1b --- /dev/null +++ b/doc/operations/tracing.md @@ -0,0 +1,40 @@ +--- +stage: Monitor +group: APM +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/#designated-technical-writers +--- + +# Tracing **(ULTIMATE)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7903) in GitLab Ultimate 11.5. + +Tracing provides insight into the performance and health of a deployed application, +tracking each function or microservice which handles a given request. + +This makes it easy to +understand the end-to-end flow of a request, regardless of whether you are using a monolithic or distributed system. + +## Jaeger tracing + +[Jaeger](https://www.jaegertracing.io/) is an open source, end-to-end distributed +tracing system used for monitoring and troubleshooting microservices-based distributed +systems. + +### Deploying Jaeger + +To learn more about deploying Jaeger, read the official +[Getting Started documentation](https://www.jaegertracing.io/docs/latest/getting-started/). +There is an easy to use [all-in-one Docker image](https://www.jaegertracing.io/docs/latest/getting-started/#AllinoneDockerimage), +as well as deployment options for [Kubernetes](https://github.com/jaegertracing/jaeger-kubernetes) +and [OpenShift](https://github.com/jaegertracing/jaeger-openshift). + +### Enabling Jaeger + +GitLab provides an easy way to open the Jaeger UI from within your project: + +1. [Set up Jaeger](https://www.jaegertracing.io) and configure your application using one of the + [client libraries](https://www.jaegertracing.io/docs/latest/client-libraries/). +1. Navigate to your project's **Settings > Operations** and provide the Jaeger URL. +1. Click **Save changes** for the changes to take effect. +1. You can now visit **Operations > Tracing** in your project's sidebar and + GitLab will redirect you to the configured Jaeger URL. |
