diff options
Diffstat (limited to 'doc/user/project/operations')
18 files changed, 227 insertions, 158 deletions
diff --git a/doc/user/project/operations/alert_management.md b/doc/user/project/operations/alert_management.md index 2dcf72aaf01..411b36411af 100644 --- a/doc/user/project/operations/alert_management.md +++ b/doc/user/project/operations/alert_management.md @@ -1,3 +1,9 @@ +--- +stage: Monitor +group: Health +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 +--- + # Alert Management > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2877) in GitLab 13.0. @@ -32,12 +38,14 @@ immediately identify which alerts you should prioritize investigating: Alerts contain one of the following icons: -- **Critical**: **{severity-critical}** and hexadecimal color `#8b2615` -- **High**: **{severity-high}** and hexadecimal color `#c0341d` -- **Medium**: **{severity-medium}** and hexadecimal color `#fca429` -- **Low**: **{severity-low}** and hexadecimal color `#fdbc60` -- **Info**: **{severity-info}** and hexadecimal color `#418cd8` -- **Unknown**: **{severity-unknown}** and hexadecimal color `#bababa` +| Severity | Icon | Color (hexadecimal) | +|---|---|---| +| Critical | **{severity-critical}** | `#8b2615` | +| High | **{severity-high}** | `#c0341d` | +| Medium | **{severity-medium}** | `#fca429` | +| Low | **{severity-low}** | `#fdbc60` | +| Info | **{severity-info}** | `#418cd8` | +| Unknown | **{severity-unknown}** | `#bababa` | ## Alert Management list @@ -72,8 +80,91 @@ You will need at least Developer [permissions](../../permissions.md) to view Ale Navigate to the Alert Management detail view by visiting the [Alert Management list](#alert-management-list) and selecting an Alert from the list. - + + + ### Update an Alert's status -The Alert Management detail view allows users to update the Alert Status. See [Alert Management statuses](#alert-management-statuses) for more details. +The Alert Management detail view enables you to update the Alert Status. +See [Alert Management statuses](#alert-management-statuses) for more details. + +### Create an Issue from an Alert + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217745) in GitLab 13.1. + +The Alert Management detail view enables you to create an issue with a +description automatically populated from an alert. To create the issue, +click the **Create Issue** button. You can then view the issue from the +alert by clicking the **View Issue** button. + +Closing a GitLab issue associated with an alert changes the alert's status to Resolved. +See [Alert Management statuses](#alert-management-statuses) for more details about statuses. + +### Update an Alert's assignee + +> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in GitLab 13.1. + +The Alert Management detail view allows users to update the Alert assignee. + +In large teams, where there is shared ownership of an alert, it can be difficult +to track who is investigating and working on it. The Alert Management detail view +enables you to update the Alert assignee: + +NOTE: **Note:** +GitLab currently only supports a single assignee per alert. + +1. To display the list of current alerts, click + **{cloud-gear}** **Operations > Alerts**: + +  + +1. Select your desired alert to display its **Alert Management Details View**: + +  + +1. If the right sidebar is not expanded, click + **{angle-double-right}** **Expand sidebar** to expand it. +1. In the right sidebar, locate the **Assignee** and click **Edit**. From the + dropdown menu, select each user you want to assign to the alert. GitLab creates + a [To-Do list item](../../todos.md) for each user. + +  + +To remove an assignee, click **Edit** next to the **Assignee** dropdown menu and +deselect the user from the list of assignees, or click **Unassigned**. + +### Alert system notes + +> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in GitLab 13.1. + +NOTE: **Note:** +GitLab currently only supports creating system notes when assigning an Alert. + +Assigning a user an Alert creates a system note, visible in the Alert Details view, +giving you a linear timeline of the alert's investigation and assignment history. + + + +## Use cases for assigning alerts + +Consider a team formed by different sections of monitoring, collaborating on a +single application. After an alert surfaces, it's extremely important to +route the alert to the team members who can address and resolve the alert. + +Assigning Alerts to multiple assignees eases collaboration and delegation. All +assignees are shown in your team's work-flows, and all assignees receive +notifications, simplifying communication and ownership of the alert. + +After completing their portion of investigating or fixing the alert, users can +unassign their account from the alert when their role is complete. +The [alerts status](#alert-management-statuses) can be updated to +reflect if the alert has been resolved. + +### Slack Notifications + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216326) in GitLab 13.1. + +You can be alerted via a Slack message when a new alert has been received. + +See the [Slack Notifications Service docs](../integrations/slack.md) for information on how to set this up. diff --git a/doc/user/project/operations/dashboard_settings.md b/doc/user/project/operations/dashboard_settings.md new file mode 100644 index 00000000000..e14c478ab7a --- /dev/null +++ b/doc/user/project/operations/dashboard_settings.md @@ -0,0 +1,47 @@ +--- +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 +--- + +# Metrics dashboard settings + +You can configure your [Monitoring dashboard](../integrations/prometheus.md) to +display the time zone of your choice, and the links of your choice. + +## Change the dashboard time zone + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214370) in GitLab 13.1. + +By default, your monitoring dashboard displays dates and times in your local +time zone, but you can display dates and times in UTC format. To change the +time zone: + +1. Navigate to **{settings}** **Settings > Operations**, and scroll to + **Metrics Dashboard**. +1. In the **Dashboard timezone** select box, select *User's local timezone* + or *UTC*: + +  +1. Click **Save changes**. + +## Link to an external dashboard + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57171) in GitLab 12.0. + +You can add a button on your monitoring dashboard that links directly to your +existing external dashboards: + +1. Navigate to **{settings}** **Settings > Operations**, and scroll to + **Metrics Dashboard**. +1. In **External dashboard URL**, provide the URL to your external dashboard: + +  + +1. Click **Save changes**. + +GitLab displays a **View full dashboard** button in the top right corner of your +[monitoring dashboard](../../../ci/environments/index.md#monitoring-environments) +which opens the URL you provided: + + diff --git a/doc/user/project/operations/error_tracking.md b/doc/user/project/operations/error_tracking.md index 23a50fd7766..a7a16de90e0 100644 --- a/doc/user/project/operations/error_tracking.md +++ b/doc/user/project/operations/error_tracking.md @@ -61,7 +61,7 @@ This page has: - A link to the Sentry issue. - A link to the GitLab commit if the Sentry [release ID/version](https://docs.sentry.io/workflow/releases/?platform=javascript#configure-sdk) on the Sentry Issue's first release matches a commit SHA in your GitLab hosted project. - Other details about the issue, including a full stack trace. -- In [GitLab 12.7 and newer](https://gitlab.com/gitlab-org/gitlab/issues/36246), language and urgency are displayed. +- In [GitLab 12.7 and newer](https://gitlab.com/gitlab-org/gitlab/-/issues/36246), language and urgency are displayed. By default, a **Create issue** button is displayed: @@ -77,7 +77,7 @@ You can take action on Sentry Errors from within the GitLab UI. ### Ignoring errors -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/39665) in GitLab 12.7. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39665) in GitLab 12.7. From within the [Error Details](#error-details) page you can ignore a Sentry error by simply clicking the **Ignore** button near the top of the page. @@ -85,7 +85,7 @@ Ignoring an error will prevent it from appearing in the [Error Tracking List](#e ### Resolving errors -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/39825) in GitLab 12.7. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39825) in GitLab 12.7. From within the [Error Details](#error-details) page you can resolve a Sentry error by clicking the **Resolve** button near the top of the page. diff --git a/doc/user/project/operations/feature_flags.md b/doc/user/project/operations/feature_flags.md index 8716d5feb4a..a9729204cd7 100644 --- a/doc/user/project/operations/feature_flags.md +++ b/doc/user/project/operations/feature_flags.md @@ -8,100 +8,73 @@ info: To determine the technical writer assigned to the Stage/Group associated w > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7433) in GitLab 11.4. -Feature flags allow you to ship a project in different flavors by -dynamically toggling certain functionality. +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. -## Overview - -Feature Flags offer a feature toggle system for your application. They enable teams -to achieve Continuous Delivery by deploying new features to production at smaller -batches for controlled testing, separating feature delivery from customer launch. -This helps reducing risk and allows you to easily manage which features to enable. - -GitLab offers a Feature Flags interface that allows you to create, toggle and -remove feature flags. - -<div class="video-fallback"> - <a href="https://www.youtube.com/watch?v=5tw2p6lwXxo">Watch</a> a use case between Feature Flags and Sentry Error Tracking -</div> -<figure class="video-container"> - <iframe src="https://www.youtube.com/embed/5tw2p6lwXxo" frameborder="0" allowfullscreen="true"> </iframe> -</figure> +<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 -Underneath, GitLab uses [unleash](https://github.com/Unleash/unleash), a feature -toggle service. GitLab provides an API where your application can talk to and get the -list of feature flags you set in GitLab. +GitLab uses [Unleash](https://github.com/Unleash/unleash), a feature +toggle service. -The application must be configured to talk to GitLab, so that's up to the -developers to use a compatible [client library](#client-libraries) and -integrate it in their app. +By enabling or disabling a flag in GitLab, your application +can determine which features to enable or disable. -By setting a flag active or inactive via GitLab, your application will automatically -know which features to enable or disable respectively. +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). -## Adding a new feature flag +## Create a feature flag -To add a new feature flag: +To create and enable a feature flag: 1. Navigate to your project's **Operations > Feature Flags**. -1. Click on the **New Feature Flag** button. -1. Give it a name. - - NOTE: **Note:** - A name can contain only lowercase letters, digits, underscores (`_`) - and dashes (`-`), must start with a letter, and cannot end with a dash (`-`) - or an underscore (`_`). - -1. Give it a description (optional, 255 characters max). -1. Define environment [specs](#define-environment-specs). If you want the flag on by default, enable the catch-all [wildcard spec (`*`)](#define-environment-specs) +1. Click the **New feature flag** button. +1. Enter a name that starts with a letter and contains only lowercase letters, digits, underscores (`_`) + and 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: Enter an environment spec, + enable or disable the flag in this environment, and select a rollout strategy. + - In GitLab 13.1 and later (when [this feature flag](#feature-flag-behavior-change-in-130) is enabled): Select a strategy and then + the environments to apply the strategy to. 1. Click **Create feature flag**. -Once a feature flag is created, the list of existing feature flags will be presented -with ability to edit or remove them. - -To make a feature flag active or inactive, click the pencil icon to edit it, -and toggle the status for each [spec](#define-environment-specs). +The feature flag is displayed in the list. It is enabled by default. -The toggles next to each feature flag on the list page function as global shutoff switches. -If a toggle is off, that feature flag is disabled for every environment. +## 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: -## Define environment specs - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/8621) in GitLab 11.8. - -In general, an application is deployed to multiple environments, such as -production, staging and [review apps](../../../ci/review_apps/index.md). -For example, you may not want to enable a feature flag on production until your QA team has -first confirmed that the feature is working correctly on testing environments. +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 (when [this feature flag](#feature-flag-behavior-change-in-130) is + enabled): For each strategy it applies to, under **Environments**, delete the environment. +1. Click **Save changes**. -To handle these situations, you can enable a feature flag on a particular environment -with [Environment specs](../../../ci/environments/index.md#scoping-environments-with-specs). -You can define multiple specs per flag so that you can control your feature flag more granularly. +## Disable a feature flag for all environments -To define specs for each environment: +To disable a feature flag for all environments: 1. Navigate to your project's **Operations > Feature Flags**. -1. Click on the **New Feature Flag** button or edit an existing flag. -1. Set the status of the default [spec](../../../ci/environments/index.md#scoping-environments-with-specs) (`*`). Choose a rollout strategy. This status and rollout strategy combination will be used for _all_ environments. -1. If you want to enable/disable the feature on a specific environment, create a new [spec](../../../ci/environments/index.md#scoping-environments-with-specs) and type the environment name. -1. Set the status and rollout strategy of the additional spec. This status and rollout strategy combination takes precedence over the default spec since we always use the most specific match available. -1. Click **Create feature flag** or **Update feature flag**. +1. For the feature flag you want to disable, slide the Status toggle to **Disabled**. - - -NOTE: **NOTE** -We'd highly recommend you to use the [Environment](../../../ci/environments/index.md) -feature in order to quickly assess which flag is enabled per environment. +The feature flag is displayed on the **Disabled** tab. ## Feature flag behavior change in 13.0 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35555) in GitLab 13.0. -Starting in GitLab 13.0, you can apply a feature flag strategy across multiple environment specs, +Starting in GitLab 13.0, you can apply a feature flag strategy across multiple environments, without defining the strategy multiple times. This feature is under development and not ready for production use. It is @@ -121,29 +94,18 @@ To disable it: Feature.disable(:feature_flags_new_version) ``` -### Applying a strategy to environments - -After a strategy is defined, it applies to **All Environments** by default. To -make a strategy apply to a specific environment spec: +## Feature flag strategies -1. Click the **Add Environment** button. -1. Create a new - [spec](../../../ci/environments/index.md#scoping-environments-with-specs). - -To apply the strategy to multiple environment specs, repeat these steps. - -## Feature Flag strategies - -GitLab Feature Flag adopts [Unleash](https://unleash.github.io) -as the feature flag engine. In unleash, there is a concept of rulesets for granular feature flag controls, +GitLab Feature Flag uses [Unleash](https://unleash.github.io) +as the feature flag engine. In Unleash, there is a concept of rulesets for granular feature flag controls, called [strategies](https://unleash.github.io/docs/activation_strategy). Supported strategies for GitLab Feature Flags are described below. ### Rollout strategy -> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/8240) in GitLab 12.2. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8240) in GitLab 12.2. -The selected rollout strategy affects which users will experience the feature enabled. +The selected rollout strategy affects which users will experience the feature as enabled. The status of an environment spec ultimately determines whether or not a feature is enabled at all. For instance, a feature will always be disabled for every user if the matching environment spec has a disabled status, regardless of the chosen rollout strategy. @@ -172,36 +134,34 @@ ID for the feature to be enabled. See the [Ruby example](#ruby-application-examp #### 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. +> [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. A feature flag may be enabled for a list of target users. It is implemented using the Unleash [`userWithId`](https://unleash.github.io/docs/activation_strategy#userwithid) activation strategy. -User IDs should be a comma separated list of values. For example, `user@example.com, user2@example.com`, or `username1,username2,username3`, etc. +User IDs should be a comma-separated list of values. For example, `user@example.com, user2@example.com`, or `username1,username2,username3`, etc. 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. -## Integrating with your application +## Integrate feature flags with your application -In order to use Feature Flags, you need to first -[get the access credentials](#configuring-feature-flags) from GitLab and then -prepare your application and hook it with a [client library](#client-libraries). +To use feature flags with your application, get access credentials from GitLab. +Then prepare your application with a client library. -## Configuring Feature Flags +### Get access credentials -To get the access credentials that your application will need to talk to GitLab: +To get the access credentials that your application needs to communicate with GitLab: 1. Navigate to your project's **Operations > Feature Flags**. -1. Click on the **Configure** button to see the values: +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, application name would be - `production` or similar. This value is used for - [the environment spec evaluation](#define-environment-specs). + 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 @@ -209,34 +169,28 @@ 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. -## Client libraries +### Choose a client library -GitLab currently implements a single backend that is compatible with -[Unleash](https://github.com/Unleash/unleash#client-implementations) clients. +GitLab implements a single backend that is compatible with Unleash clients. -Unleash clients allow the developers to define in the app's code the default -values for flags. Each feature flag evaluation can express the desired -outcome in case the flag isn't present on the provided configuration file. +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 a number of official SDKs for various frameworks and -a number of community contributed libraries. +Unleash currently [offers many SDKs for various languages and frameworks](https://github.com/Unleash/unleash#client-implementations). -Official clients: +### Feature flags API information -- [Unleash client SDK for Java](https://github.com/unleash/unleash-client-java) -- [Unleash client SDK for Node.js](https://github.com/unleash/unleash-client-node) -- [Unleash client for Go](https://github.com/unleash/unleash-client-go) -- [Unleash client for Ruby](https://github.com/unleash/unleash-client-ruby) +For API content, see: -Community contributed clients: - -- [Unleash FeatureToggle Client for .Net](https://github.com/stiano/unleash-client-dotnet) -- [Unofficial .Net Core Unleash client](https://github.com/onybo/unleash-client-core) -- [Unleash client for Python 3](https://github.com/aes/unleash-client-python) +- [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 +### Golang application example -Here's an example of how to integrate the feature flags in a Golang application: +Here's an example of how to integrate feature flags in a Golang application: ```golang package main @@ -275,9 +229,9 @@ func main() { } ``` -## Ruby application example +### Ruby application example -Here's an example of how to integrate the feature flags in a Ruby application. +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**. @@ -305,12 +259,3 @@ else puts "hello, world!" end ``` - -## Feature Flags API - -You can create, update, read, and delete Feature Flags via API -to control them in an automated flow: - -- [Feature Flags API](../../../api/feature_flags.md) -- [Feature Flag Specs API](../../../api/feature_flag_specs.md) -- [Feature Flag User Lists API](../../../api/feature_flag_user_lists.md) diff --git a/doc/user/project/operations/img/alert_detail_full_v13_1.png b/doc/user/project/operations/img/alert_detail_full_v13_1.png Binary files differnew file mode 100644 index 00000000000..18a6f4fb67b --- /dev/null +++ b/doc/user/project/operations/img/alert_detail_full_v13_1.png diff --git a/doc/user/project/operations/img/alert_detail_overview_v13_1.png b/doc/user/project/operations/img/alert_detail_overview_v13_1.png Binary files differnew file mode 100644 index 00000000000..10c945d3810 --- /dev/null +++ b/doc/user/project/operations/img/alert_detail_overview_v13_1.png diff --git a/doc/user/project/operations/img/alert_detail_system_notes_v13_1.png b/doc/user/project/operations/img/alert_detail_system_notes_v13_1.png Binary files differnew file mode 100644 index 00000000000..2a6d0320a54 --- /dev/null +++ b/doc/user/project/operations/img/alert_detail_system_notes_v13_1.png diff --git a/doc/user/project/operations/img/alert_detail_v13_0.png b/doc/user/project/operations/img/alert_detail_v13_0.png Binary files differdeleted file mode 100644 index 7da09407cd5..00000000000 --- a/doc/user/project/operations/img/alert_detail_v13_0.png +++ /dev/null diff --git a/doc/user/project/operations/img/alert_details_assignees_v13_1.png b/doc/user/project/operations/img/alert_details_assignees_v13_1.png Binary files differnew file mode 100644 index 00000000000..dab4eac384a --- /dev/null +++ b/doc/user/project/operations/img/alert_details_assignees_v13_1.png diff --git a/doc/user/project/operations/img/alert_issue_v13_1.png b/doc/user/project/operations/img/alert_issue_v13_1.png Binary files differnew file mode 100644 index 00000000000..da79074aa2f --- /dev/null +++ b/doc/user/project/operations/img/alert_issue_v13_1.png diff --git a/doc/user/project/operations/img/alert_list_assignees_v13_1.png b/doc/user/project/operations/img/alert_list_assignees_v13_1.png Binary files differnew file mode 100644 index 00000000000..db1e0d8dcb7 --- /dev/null +++ b/doc/user/project/operations/img/alert_list_assignees_v13_1.png diff --git a/doc/user/project/operations/img/alert_management_1_v13_1.png b/doc/user/project/operations/img/alert_management_1_v13_1.png Binary files differindex c01b4749eda..00aa56a6050 100644 --- a/doc/user/project/operations/img/alert_management_1_v13_1.png +++ b/doc/user/project/operations/img/alert_management_1_v13_1.png diff --git a/doc/user/project/operations/img/alert_todo_assignees_v13_1.png b/doc/user/project/operations/img/alert_todo_assignees_v13_1.png Binary files differnew file mode 100644 index 00000000000..637f8be5d25 --- /dev/null +++ b/doc/user/project/operations/img/alert_todo_assignees_v13_1.png diff --git a/doc/user/project/operations/img/dashboard_external_link_v13_1.png b/doc/user/project/operations/img/dashboard_external_link_v13_1.png Binary files differnew file mode 100644 index 00000000000..3e8d792c53e --- /dev/null +++ b/doc/user/project/operations/img/dashboard_external_link_v13_1.png diff --git a/doc/user/project/operations/img/dashboard_local_timezone_v13_1.png b/doc/user/project/operations/img/dashboard_local_timezone_v13_1.png Binary files differnew file mode 100644 index 00000000000..8d45607a940 --- /dev/null +++ b/doc/user/project/operations/img/dashboard_local_timezone_v13_1.png diff --git a/doc/user/project/operations/img/external_dashboard_settings.png b/doc/user/project/operations/img/external_dashboard_settings.png Binary files differdeleted file mode 100644 index e1b7fa56a1c..00000000000 --- a/doc/user/project/operations/img/external_dashboard_settings.png +++ /dev/null diff --git a/doc/user/project/operations/index.md b/doc/user/project/operations/index.md index 954f88fe4f2..ca38eab9455 100644 --- a/doc/user/project/operations/index.md +++ b/doc/user/project/operations/index.md @@ -10,4 +10,4 @@ your applications: - Discover and view errors generated by your applications with [Error Tracking](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)** -- Add a [button to the Monitoring dashboard](linking_to_an_external_dashboard.md) linking directly to your existing external dashboards. +- Change the [settings of the Monitoring Dashboard](dashboard_settings.md). diff --git a/doc/user/project/operations/linking_to_an_external_dashboard.md b/doc/user/project/operations/linking_to_an_external_dashboard.md index 8e1117de4c7..ff609a3720e 100644 --- a/doc/user/project/operations/linking_to_an_external_dashboard.md +++ b/doc/user/project/operations/linking_to_an_external_dashboard.md @@ -1,19 +1,5 @@ -# Linking to an external dashboard +--- +redirect_to: 'dashboard_settings.md' +--- -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/57171) in GitLab 12.0. - -You can add a button to the Monitoring dashboard linking directly to your existing external dashboards. - -## Enabling the external dashboard link - -1. Go to **Settings > Operations** and scroll to the section titled **External dashboard**. - -1. Fill in the URL to your external dashboard and click **Save changes**. - -  - -1. There should now be a button on your - [Monitoring dashboard](../../../ci/environments/index.md#monitoring-environments) which - will open the URL you entered in the above step. - -  +This document was moved to [another location](dashboard_settings.md). |
