Commit 71880bf5 authored by Suzanne Selhorn's avatar Suzanne Selhorn

Merge branch 'eread/remove-more-inline-icons' into 'master'

Remove more inline icons

See merge request gitlab-org/gitlab!38455
parents 5508b605 bd427383
......@@ -141,7 +141,7 @@ sudo gitlab-rake geo:verification:wiki:reset
If the **primary** and **secondary** nodes have a checksum verification mismatch, the cause may not be apparent. To find the cause of a checksum mismatch:
1. Navigate to the **Admin Area >** **{overview}** **Overview > Projects** dashboard on the **primary** node, find the
1. Navigate to the **Admin Area > Overview > Projects** dashboard on the **primary** node, find the
project that you want to check the checksum differences and click on the
**Edit** button:
![Projects dashboard](img/checksum-differences-admin-projects.png)
......
......@@ -135,7 +135,7 @@ This [content was moved to another location](background_verification.md).
### Notify users of scheduled maintenance
On the **primary** node, navigate to **Admin Area >** **{bullhorn}** **Messages**, add a broadcast
On the **primary** node, navigate to **Admin Area > Messages**, add a broadcast
message. You can check under **Admin Area > Geo** to estimate how long it
will take to finish syncing. An example message would be:
......@@ -181,7 +181,7 @@ access to the **primary** node during the maintenance window.
connection.
1. Disable non-Geo periodic background jobs on the **primary** node by navigating
to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Cron**, pressing `Disable All`,
to **Admin Area > Monitoring > Background Jobs > Cron**, pressing `Disable All`,
and then pressing `Enable` for the `geo_sidekiq_cron_config_worker` cron job.
This job will re-enable several other cron jobs that are essential for planned
failover to complete successfully.
......@@ -190,7 +190,7 @@ access to the **primary** node during the maintenance window.
1. If you are manually replicating any data not managed by Geo, trigger the
final replication process now.
1. On the **primary** node, navigate to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
1. On the **primary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
and wait for all queues except those with `geo` in the name to drop to 0.
These queues contain work that has been submitted by your users; failing over
before it is completed will cause the work to be lost.
......@@ -202,7 +202,7 @@ access to the **primary** node during the maintenance window.
- Database replication lag is 0ms.
- The Geo log cursor is up to date (0 events behind).
1. On the **secondary** node, navigate to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
1. On the **secondary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
and wait for all the `geo` queues to drop to 0 queued and 0 running jobs.
1. On the **secondary** node, use [these instructions](../../raketasks/check.md)
to verify the integrity of CI artifacts, LFS objects, and uploads in file
......
......@@ -10,7 +10,7 @@ To profile a request:
1. Sign in to GitLab as a user with Administrator or Maintainer [permissions](../../../user/permissions.md).
1. In the navigation bar, click **Admin area**.
1. Navigate to **{monitor}** **Monitoring > Requests Profiles**.
1. Navigate to **Monitoring > Requests Profiles**.
1. In the **Requests Profiles** section, copy the token.
1. Pass the headers `X-Profile-Token: <token>` and `X-Profile-Mode: <mode>`(where
`<mode>` can be `execution` or `memory`) to the request you want to profile. When
......@@ -29,7 +29,7 @@ To profile a request:
Profiled requests can take longer than usual.
After the request completes, you can view the profiling output from the
**{monitor}** **Monitoring > Requests Profiles** administration page:
**Monitoring > Requests Profiles** administration page:
![Profiling output](img/request_profile_result.png)
......
......@@ -15,7 +15,7 @@ of incident management are only available in
[GitLab Ultimate and GitLab.com Gold](https://about.gitlab.com/pricing/).
For users with at least Developer [permissions](../../user/permissions.md), the
Incident Management list is available at **{cloud-gear}** **Operations > Incidents**
Incident Management list is available at **Operations > Incidents**
in your project's sidebar. The list contains the following metrics:
![Incident Management List](img/incident_list_13_3.png)
......@@ -36,7 +36,7 @@ Incidents share the [Issues API](../../user/project/issues/index.md).
To create a Incident you can take any of the following actions:
- Navigate to **{cloud-gear}** **Operations > Incidents** and click **Create Incident**.
- Navigate to **Operations > Incidents** and click **Create Incident**.
- Create a new issue using the `incident` template available when creating it.
- Create a new issue and assign the `incident` label to it.
......
......@@ -19,7 +19,7 @@ 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. In your project, navigate to **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**.
......
......@@ -23,15 +23,14 @@ The metrics as defined below do not support alerts, unlike
> 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. For the dashboard to display on your project's
**{cloud-gear}** **Operations > Metrics** page, the files must have a `.yml`
`.gitlab/dashboards/` directory. For the dashboard to display on your project's **Operations > Metrics** page, the files must have a `.yml`
extension and be present in your 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. Navigate to your dashboard at **Operations > Metrics**.
1. In the top-right corner of your dashboard, click the **{file-addition-solid}** **Actions** menu,
and select **Create new**:
![Monitoring Dashboard actions menu with create new item](img/actions_menu_create_new_dashboard_v13_2.png)
......@@ -103,7 +102,7 @@ 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. Navigate to your dashboard at **Operations > Metrics**.
1. In the top-right corner of your dashboard, click **Metrics Settings**:
![Monitoring Dashboard actions menu with create new item](img/metrics_settings_button_v13_2.png)
......
......@@ -20,7 +20,7 @@ To view the metrics dashboard for an environment that has
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**.
1. In your project, navigate to **Operations > Metrics**.
GitLab displays the default metrics dashboard for the environment, like the
following example:
......@@ -52,11 +52,11 @@ navigation bar contains:
## 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
you must also deploy code for the **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. Navigate to your project's **Operations > Kubernetes** page.
1. Ensure that, in addition to Prometheus, you also have Runner and Ingress
installed.
1. After installing Ingress, copy its endpoint.
......@@ -68,7 +68,7 @@ helps quickly create a deployment:
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.
**Operations > Metrics** page.
![Monitoring Dashboard](img/prometheus_monitoring_dashboard_v13_1.png)
......
......@@ -52,7 +52,7 @@ user interface:
1. Sign in to GitLab as a user with Reporter or greater
[permissions](../user/permissions.md).
1. Navigate to **{cloud-gear}** **Operations > Product Analytics**
1. Navigate to **Operations > Product Analytics**
The user interface contains:
......
......@@ -276,14 +276,14 @@ The following table is an example of how to configure the three different cluste
To add a different cluster for each environment:
1. Navigate to your project's **{cloud-gear}** **Operations > Kubernetes**.
1. Navigate to your project's **Operations > Kubernetes**.
1. Create the Kubernetes clusters with their respective environment scope, as
described from the table above.
1. After creating the clusters, navigate to each cluster and install
Ingress. Wait for the Ingress IP address to be assigned.
1. Make sure you've [configured your DNS](#auto-devops-base-domain) with the
specified Auto DevOps domains.
1. Navigate to each cluster's page, through **{cloud-gear}** **Operations > Kubernetes**,
1. Navigate to each cluster's page, through **Operations > Kubernetes**,
and add the domain based on its Ingress IP address.
After completing configuration, you can test your setup by creating a merge request
......
......@@ -57,7 +57,7 @@ to deploy this project to.
## Create a Kubernetes cluster from within GitLab
1. On your project's landing page, click **Add Kubernetes cluster**
(note that this option is also available when you navigate to **{cloud-gear}** **Operations > Kubernetes**).
(note that this option is also available when you navigate to **Operations > Kubernetes**).
![Project landing page](img/guide_project_landing_page_v12_10.png)
......@@ -194,7 +194,7 @@ to monitor it.
After successfully deploying your application, you can view its website and check
on its health on the **Environments** page by navigating to
**{cloud-gear}** **Operations > Environments**. This page displays details about
**Operations > Environments**. This page displays details about
the deployed applications, and the right-hand column displays icons that link
you to common environment tasks:
......
......@@ -650,6 +650,6 @@ To use Auto Monitoring:
1. After the pipeline finishes successfully, open the
[monitoring dashboard for a deployed environment](../../ci/environments/index.md#monitoring-environments)
to view the metrics of your deployed application. To view the metrics of the
whole Kubernetes cluster, navigate to **{cloud-gear}** **Operations > Metrics**.
whole Kubernetes cluster, navigate to **Operations > Metrics**.
![Auto Metrics](img/auto_monitoring.png)
......@@ -59,13 +59,13 @@ The Dashboard is the default view of the Admin Area, and is made up of the follo
## Overview section
The following topics document the **{overview}** **Overview** section of the Admin Area.
The following topics document the **Overview** section of the Admin Area.
### Administering Projects
You can administer all projects in the GitLab instance from the Admin Area's Projects page.
To access the Projects page, go to **Admin Area >** **{overview}** **Overview > Projects**.
To access the Projects page, go to **Admin Area > Overview > Projects**.
Click the **All**, **Private**, **Internal**, or **Public** tab to list only projects of that
criteria.
......@@ -105,7 +105,7 @@ You can combine the filter options. For example, to list only public projects wi
You can administer all users in the GitLab instance from the Admin Area's Users page.
To access the Users page, go to **Admin Area >** **{overview}** **Overview > Users**.
To access the Users page, go to **Admin Area > Overview > Users**.
To list users matching a specific criteria, click on one of the following tabs on the **Users** page:
......@@ -157,7 +157,7 @@ reflected in the statistics.
You can administer all groups in the GitLab instance from the Admin Area's Groups page.
To access the Groups page, go to **Admin Area >** **{overview}** **Overview > Groups**.
To access the Groups page, go to **Admin Area > Overview > Groups**.
For each group, the page displays their name, description, size, number of projects in the group,
number of members, and whether the group is private, internal, or public. To edit a group, click
......@@ -176,7 +176,7 @@ To [Create a new group](../group/index.md#create-a-new-group) click **New group*
You can administer all jobs in the GitLab instance from the Admin Area's Jobs page.
To access the Jobs page, go to **Admin Area >** **{overview}** **Overview > Jobs**.
To access the Jobs page, go to **Admin Area > Overview > Jobs**.
All jobs are listed, in descending order of job ID.
......@@ -201,7 +201,7 @@ For each job, the following details are listed:
You can administer all Runners in the GitLab instance from the Admin Area's **Runners** page. See
[GitLab Runner](https://docs.gitlab.com/runner/) for more information on Runner itself.
To access the **Runners** page, go to **Admin Area >** **{overview}** **Overview > Runners**.
To access the **Runners** page, go to **Admin Area > Overview > Runners**.
The **Runners** page features:
......@@ -247,7 +247,7 @@ You can also edit, pause, or remove each Runner.
You can list all Gitaly servers in the GitLab instance from the Admin Area's **Gitaly Servers**
page. For more details, see [Gitaly](../../administration/gitaly/index.md).
To access the **Gitaly Servers** page, go to **Admin Area >** **{overview}** **Overview > Gitaly Servers**.
To access the **Gitaly Servers** page, go to **Admin Area > Overview > Gitaly Servers**.
For each Gitaly server, the following details are listed:
......@@ -261,7 +261,7 @@ For each Gitaly server, the following details are listed:
## Monitoring section
The following topics document the **{monitor}** **Monitoring** section of the Admin Area.
The following topics document the **Monitoring** section of the Admin Area.
### System Info
......
......@@ -28,9 +28,9 @@ This namespace:
To see a list of available applications to install. For a:
- [Project-level cluster](../project/clusters/index.md), navigate to your project's
**{cloud-gear}** **Operations > Kubernetes**.
**Operations > Kubernetes**.
- [Group-level cluster](../group/clusters/index.md), navigate to your group's
**{cloud-gear}** **Kubernetes** page.
**Kubernetes** page.
NOTE: **Note:**
As of GitLab 11.6, Helm will be upgraded to the latest version supported
......@@ -343,7 +343,7 @@ To help you tune your WAF rules, you can globally set your WAF to either
To change your WAF's mode:
1. [Install ModSecurity](../../topics/web_application_firewall/quick_start_guide.md) if you have not already done so.
1. Navigate to **{cloud-gear}** **Operations > Kubernetes**.
1. Navigate to **Operations > Kubernetes**.
1. In **Applications**, scroll to **Ingress**.
1. Under **Global default**, select your desired mode.
1. Click **Save changes**.
......@@ -535,7 +535,7 @@ To enable log shipping:
1. Ensure your cluster contains at least 3 nodes of instance types larger than
`f1-micro`, `g1-small`, or `n1-standard-1`.
1. Navigate to **{cloud-gear}** **Operations > Kubernetes**.
1. Navigate to **Operations > Kubernetes**.
1. In **Kubernetes Cluster**, select a cluster.
1. In the **Applications** section, find **Elastic Stack** and click **Install**.
......@@ -601,7 +601,7 @@ your data. Fluentd sends logs in syslog format.
To enable Fluentd:
1. Navigate to **{cloud-gear}** **Operations > Kubernetes** and click
1. Navigate to **Operations > Kubernetes** and click
**Applications**. You will be prompted to enter a host, port and protocol
where the WAF logs will be sent to via syslog.
1. Provide the host domain name or URL in **SIEM Hostname**.
......
......@@ -84,7 +84,7 @@ your cluster, which can cause deployment jobs to fail.
To clear the cache:
1. Navigate to your group’s **{cloud-gear}** **Kubernetes** page,
1. Navigate to your group’s **Kubernetes** page,
and select your cluster.
1. Expand the **Advanced settings** section.
1. Click **Clear cluster cache**.
......
......@@ -56,9 +56,9 @@ Generate an access key for the IAM user, and configure GitLab with the credentia
To create and add a new Kubernetes cluster to your project, group, or instance:
1. Navigate to your:
- Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
- Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
- **Admin Area >** **{cloud-gear}** **Kubernetes**, for an instance-level cluster.
- Project's **Operations > Kubernetes** page, for a project-level cluster.
- Group's **Kubernetes** page, for a group-level cluster.
- **Admin Area > Kubernetes**, for an instance-level cluster.
1. Click **Add Kubernetes cluster**.
1. Under the **Create new cluster** tab, click **Amazon EKS**. You will be provided with an
`Account ID` and `External ID` to use in the next step.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment