Fix more future-tense issues in Monitor docs

This second merge request corrects more of the future-tense issues
in the Monitor documentation. A few instances remain, but they can
be dealt with on an individual basis. (Some discuss future
deprecations, and future tense is appropriate in that case.)

doc/administration/monitoring/gitlab_self_monitoring_project/index.md

@@ -14,13 +14,13 @@ health of their GitLab instance. To surface this experience in a native way
 (similar to how you would interact with an application deployed using GitLab),
 a base project called "GitLab self monitoring" with
 [internal visibility](../../../public_access/public_access.md#internal-projects)
-will be added under a group called "GitLab Instance Administrators"
+is added under a group called "GitLab Instance Administrators"
 specifically created for visualizing and configuring the monitoring of your
 GitLab instance.
 
-All administrators at the time of creation of the project and group will be
-added as maintainers of the group and project, and as an admin, you'll be able
-to add new members to the group to give them maintainer access to the project.
+All administrators at the time of creation of the project and group are
+added as maintainers of the group and project, and as an admin, you can
+add new members to the group to give them maintainer access to the project.
 
 This project is used to self monitor your GitLab instance. The metrics dashboard
 of the project shows some basic resource usage charts, such as CPU and memory usage
@@ -34,13 +34,13 @@ metrics exposed by the [GitLab exporter](../prometheus/gitlab_metrics.md#metrics
 
 1. Navigate to **Admin Area > Settings > Metrics and profiling**, and expand the **Self monitoring** section.
 1. Toggle the **Create Project** button on.
-1. Once your GitLab instance creates the project, you'll see a link to the project in the text above the **Create Project** toggle. You can also find it under **Projects > Your projects**.
+1. Once your GitLab instance creates the project, GitLab displays a link to the project in the text above the **Create Project** toggle. You can also find it under **Projects > Your projects**.
 
 ## Deleting the self monitoring project
 
 CAUTION: **Warning:**
 If you delete the self monitoring project, you will lose any changes made to the
-project. If you create the project again, it will be created in its default state.
+project. If you create the project again, it is created in its default state.
 
 1. Navigate to **Admin Area > Settings > Metrics and profiling**, and expand the **Self monitoring** section.
 1. Toggle the **Create Project** button off.
@@ -63,7 +63,7 @@ You can also
 
 ## Connection to Prometheus
 
-The project will be automatically configured to connect to the
+The project is automatically configured to connect to the
 [internal Prometheus](../prometheus/index.md) instance if the Prometheus
 instance is present (should be the case if GitLab was installed via Omnibus
 and you haven't disabled it).

doc/administration/monitoring/prometheus/index.md

@@ -10,10 +10,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 >
 > - Prometheus and the various exporters listed in this page are bundled in the
 >   Omnibus GitLab package. Check each exporter's documentation for the timeline
->   they got added. For installations from source you will have to install them
->   yourself. Over subsequent releases additional GitLab metrics will be captured.
+>   they got added. For installations from source you must install them
+>   yourself. Over subsequent releases additional GitLab metrics are captured.
 > - Prometheus services are on by default with GitLab 9.0.
-> - Prometheus and its exporters don't authenticate users, and will be available
+> - Prometheus and its exporters don't authenticate users, and are available
 >  to anyone who can access them.
 
 [Prometheus](https://prometheus.io) is a powerful time-series monitoring service, providing a flexible
@@ -34,9 +34,9 @@ dashboard tool like [Grafana](https://grafana.com).
 For installations from source, you must install and configure it yourself.
 
 Prometheus and its exporters are on by default, starting with GitLab 9.0.
-Prometheus will run as the `gitlab-prometheus` user and listen on
+Prometheus runs as the `gitlab-prometheus` user and listen on
 `http://localhost:9090`. By default, Prometheus is only accessible from the GitLab server itself.
-Each exporter will be automatically set up as a
+Each exporter is automatically set up as a
 monitoring target for Prometheus, unless individually disabled.
 
 To disable Prometheus and all of its exporters, as well as any added in the future:
@@ -179,8 +179,7 @@ The next step is to tell all the other nodes where the monitoring node is:
 
 After monitoring using Service Discovery is enabled with `consul['monitoring_service_discovery'] =  true`,
 ensure that `prometheus['scrape_configs']` is not set in `/etc/gitlab/gitlab.rb`. Setting both
-`consul['monitoring_service_discovery'] = true` and `prometheus['scrape_configs']` in `/etc/gitlab/gitlab.rb`
-will result in errors.
+`consul['monitoring_service_discovery'] = true` and `prometheus['scrape_configs']` in `/etc/gitlab/gitlab.rb` results in errors.
 
 ### Using an external Prometheus server
 
@@ -234,7 +233,7 @@ To use an external Prometheus server:
    gitlab_rails['prometheus_address'] = '192.168.0.1:9090'
    ```
 
-1. To scrape NGINX metrics, you'll also need to configure NGINX to allow the Prometheus server
+1. To scrape NGINX metrics, you must also configure NGINX to allow the Prometheus server
    IP. For example:
 
    ```ruby
@@ -399,7 +398,7 @@ The GitLab exporter allows you to measure various GitLab metrics, pulled from Re
 > - Introduced in GitLab 9.0.
 > - Pod monitoring introduced in GitLab 9.4.
 
-If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration](../../../user/project/integrations/prometheus.md) to monitor them.
+If your GitLab server is running within Kubernetes, Prometheus collects metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration](../../../user/project/integrations/prometheus.md) to monitor them.
 
 To disable the monitoring of Kubernetes:
 

doc/administration/monitoring/prometheus/node_exporter.md

@@ -24,5 +24,5 @@ To enable the node exporter:
 1. Save the file, and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
 
-Prometheus will now begin collecting performance data from the node exporter
+Prometheus begins collecting performance data from the node exporter
 exposed at `localhost:9100`.

doc/administration/monitoring/prometheus/pgbouncer_exporter.md

@@ -26,9 +26,9 @@ To enable the PgBouncer exporter:
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
 
-Prometheus will now begin collecting performance data from the PgBouncer exporter
+Prometheus begins collecting performance data from the PgBouncer exporter
 exposed at `localhost:9188`.
 
-The PgBouncer exporter will also be enabled by default if the
+The PgBouncer exporter is enabled by default if the
 [`pgbouncer_role`](https://docs.gitlab.com/omnibus/roles/#postgresql-roles)
 role is enabled.

doc/administration/monitoring/prometheus/postgres_exporter.md

@@ -21,12 +21,12 @@ To enable the PostgreSQL Server Exporter:
 
    If PostgreSQL Server Exporter is configured on a separate node, make sure that the local
    address is [listed in `trust_auth_cidr_addresses`](../../postgresql/replication_and_failover.md#network-information) or the
-   exporter will not be able to connect to the database.
+   exporter can't connect to the database.
 
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to
    take effect.
 
-Prometheus will now automatically begin collecting performance data from
+Prometheus begins collecting performance data from
 the PostgreSQL Server Exporter exposed under `localhost:9187`.
 
 ## Advanced configuration

doc/administration/monitoring/prometheus/redis_exporter.md

@@ -25,5 +25,5 @@ To enable the Redis exporter:
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
 
-Prometheus will now begin collecting performance data from
+Prometheus begins collecting performance data from
 the Redis exporter exposed at `localhost:9121`.

doc/administration/monitoring/prometheus/registry_exporter.md

@@ -21,7 +21,7 @@ To enable it:
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
 
-Prometheus will now automatically begin collecting performance data from
+Prometheus automatically begins collecting performance data from
 the registry exporter exposed under `localhost:5001/metrics`.
 
 [← Back to the main Prometheus page](index.md)

doc/api/metrics_dashboard_annotations.md

@@ -24,7 +24,7 @@ Parameters:
 |:---------------|:---------------|:---------|:-----------------------------------------------------------------------------|
 | `dashboard_path` | string        | yes      | ID of the dashboard which needs to be annotated. Treated as a CGI-escaped path, and automatically un-escaped.  |
 | `starting_at` | string        | yes      | Date time string, ISO 8601 formatted, such as `2016-03-11T03:45:40Z`. Timestamp marking start point of annotation.   |
-| `ending_at` | string        | no      | Date time string, ISO 8601 formatted, such as `2016-03-11T03:45:40Z`. Timestamp marking end point of annotation. When not supplied annotation will be displayed as single event at start point.  |
+| `ending_at` | string        | no      | Date time string, ISO 8601 formatted, such as `2016-03-11T03:45:40Z`. Timestamp marking end point of annotation. When not supplied, an annotation displays as a single event at the start point.  |
 | `description` | string        | yes      | Description of the annotation.  |
 
 ```shell

doc/api/metrics_user_starred_dashboards.md

@@ -54,7 +54,7 @@ Parameters:
 | Attribute      | Type           | Required | Description                                                                  |
 |:---------------|:---------------|:---------|:-----------------------------------------------------------------------------|
 | `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) |
-| `dashboard_path` | string        | no      | URL-encoded path to file defining the dashboard which should no longer be marked as favorite. When not supplied all dashboards within given projects will be removed from favorites.   |
+| `dashboard_path` | string        | no      | URL-encoded path to file defining the dashboard which should no longer be marked as favorite. When not supplied, all dashboards within given projects are removed from favorites.   |
 
 ```shell
 curl --request DELETE --header 'Private-Token: <your_access_token>' https://gitlab.example.com/api/v4/projects/20/metrics/user_starred_dashboards \

doc/operations/error_tracking.md

@@ -20,7 +20,7 @@ You can sign up to the cloud hosted [Sentry](https://sentry.io), deploy your own
 
 ### Enabling Sentry
 
-GitLab provides an easy way to connect Sentry to your project. You will need at
+GitLab provides an easy way to connect Sentry to your project. You need at
 least Maintainer [permissions](../user/permissions.md) to enable the Sentry integration.
 
 1. Sign up to Sentry.io or [deploy your own](#deploying-sentry) Sentry instance.
@@ -31,7 +31,7 @@ least Maintainer [permissions](../user/permissions.md) to enable the Sentry inte
    click **Enable Error Tracking**.
 1. Navigate to your project’s **Settings > Operations**. In the **Error Tracking** section,
    ensure the **Active** checkbox is set.
-1. In the **Sentry API URL** field, enter your Sentry hostname. For example, enter `https://sentry.example.com` if this is the address at which your Sentry instance is available. For the SaaS version of Sentry, the hostname will be `https://sentry.io`.
+1. In the **Sentry API URL** field, enter your Sentry hostname. For example, enter `https://sentry.example.com` if this is the address at which your Sentry instance is available. For the SaaS version of Sentry, the hostname is `https://sentry.io`.
 1. In the **Auth Token** field, enter the token you previously generated.
 1. Click the **Connect** button to test the connection to Sentry and populate the **Project** dropdown.
 1. From the **Project** dropdown, choose a Sentry project to link to your GitLab project.
@@ -65,7 +65,7 @@ By default, a **Create issue** button is displayed:
 
 ![Error Details without Issue Link](img/error_details_v12_7.png)
 
-If you create a GitLab issue from the error, the **Create issue** button will change to a **View issue** button and a link to the GitLab issue will surface within the error detail section:
+If you create a GitLab issue from the error, the **Create issue** button changes to a **View issue** button and a link to the GitLab issue displays within the error detail section:
 
 ![Error Details with Issue Link](img/error_details_with_issue_v12_8.png)
 
@@ -79,7 +79,7 @@ You can take action on Sentry Errors from within the GitLab UI.
 
 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.
 
-Ignoring an error will prevent it from appearing in the [Error Tracking List](#error-tracking-list), and will silence notifications that were set up within Sentry.
+Ignoring an error prevents it from appearing in the [Error Tracking List](#error-tracking-list), and silences notifications that were set up within Sentry.
 
 ### Resolving errors
 
@@ -88,6 +88,6 @@ Ignoring an error will prevent it from appearing in the [Error Tracking List](#e
 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.
 
-Marking an error as resolved indicates that the error has stopped firing events. If a GitLab issue is linked to the error, then the issue will be closed.
+Marking an error as resolved indicates that the error has stopped firing events. If a GitLab issue is linked to the error, then the issue closes.
 
 If another event occurs, the error reverts to unresolved.

doc/operations/incident_management/alert_integrations.md

@@ -60,7 +60,7 @@ and you can [customize the payload](#customize-the-alert-payload-outside-of-gitl
    1. In the **Integration** dropdown menu, select **HTTP Endpoint**.
    1. Name the integration.
    1. Toggle the **Active** alert setting to display the **URL** and **Authorization Key**
-      for the webhook configuration. You will input the URL and Authorization Key
+      for the webhook configuration. You must also input the URL and Authorization Key
       in your external service.
    1. _(Optional)_ To generate a test alert to test the new integration, enter a
       sample payload, then click **Save and test alert payload**.Valid JSON is required.

doc/operations/incident_management/alerts.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Alerts
 
-Alerts are a critical entity in your incident managment workflow. They represent a notable event that might indicate a service outage or disruption. GitLab provides a list view for triage and detail view for deeper investigation of what happened.
+Alerts are a critical entity in your incident management workflow. They represent a notable event that might indicate a service outage or disruption. GitLab provides a list view for triage and detail view for deeper investigation of what happened.
 
 ## Alert List
 
@@ -84,7 +84,7 @@ The **Alert details** tab has two sections. The top section provides a short lis
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217768) in GitLab 13.2.
 
-The **Metrics** tab will display a metrics chart for alerts coming from Prometheus. If the alert originated from any other tool, the **Metrics** tab will be empty. To set up alerts for GitLab-managed Prometheus instances, see [Managed Prometheus instances](../metrics/alerts.md#managed-prometheus-instances). For externally-managed Prometheus instances, you will need to configure your alerting
+The **Metrics** tab displays a metrics chart for alerts coming from Prometheus. If the alert originated from any other tool, the **Metrics** tab is empty. To set up alerts for GitLab-managed Prometheus instances, see [Managed Prometheus instances](../metrics/alerts.md#managed-prometheus-instances). For externally-managed Prometheus instances, you must configure your alerting
 rules to display a chart in the alert. For information about how to configure
 your alerting rules, see [Embedding metrics based on alerts in incident issues](../metrics/embed.md#embedding-metrics-based-on-alerts-in-incident-issues). See
 [External Prometheus instances](../metrics/alerts.md#external-prometheus-instances)
@@ -127,7 +127,7 @@ To view the logs for an alert:
 The **Activity feed** tab is a log of activity on the alert. When you take action on an alert, this is logged as a system note. This gives you a linear
 timeline of the alert's investigation and assignment history.
 
-The following actions will result in a system note:
+The following actions result in a system note:
 
 - [Updating the status of an alert](#update-an-alerts-status)
 - [Creating an incident based on an alert](#create-an-incident-from-an-alert)
@@ -137,7 +137,7 @@ The following actions will result in a system note:
 
 ## Alert actions
 
-There are different actions avilable in GitLab to help triage and respond to alerts.
+There are different actions available in GitLab to help triage and respond to alerts.
 
 ### Update an alert's status
 

doc/operations/incident_management/status_page.md

@@ -128,11 +128,11 @@ To publish an incident:
    issue to the GitLab Status Page. Confidential issues can't be published.
 
 A background worker publishes the issue onto the Status Page using the credentials
-you provided during setup. As part of publication, GitLab will:
+you provided during setup. As part of publication, GitLab:
 
-- Anonymize user and group mentions with `Incident Responder`.
-- Remove titles of non-public [GitLab references](../../user/markdown.md#special-gitlab-references).
-- Publish any files attached to incident issue descriptions, up to 5000 per issue.
+- Anonymizes user and group mentions with `Incident Responder`.
+- Removes titles of non-public [GitLab references](../../user/markdown.md#special-gitlab-references).
+- Publishes any files attached to incident issue descriptions, up to 5000 per issue.
   ([Introduced in GitLab 13.1](https://gitlab.com/gitlab-org/gitlab/-/issues/205166).)
 
 After publication, you can access the incident's details page by clicking the

doc/operations/metrics/alerts.md

@@ -53,8 +53,8 @@ as soon as the alert fires:
 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 > 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.
+This section contains the needed **URL** and **Authorization Key**. The
+**Reset Key** button invalidates the key and generates a new one.
 
 ![Prometheus service configuration of Alerts](img/prometheus_service_alerts.png)
 
@@ -85,7 +85,7 @@ Prometheus server to use the
 ## 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.
+> - [From GitLab Ultimate 12.5](https://gitlab.com/gitlab-org/gitlab/-/issues/13401), when GitLab receives a recovery alert, it automatically closes 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:

doc/operations/metrics/dashboards/index.md

@@ -66,8 +66,8 @@ To create a new dashboard from the command line:
 Your custom dashboard is available at `https://example.com/project/-/metrics/custom_dashboard_name.yml`.
 
 NOTE: **Note:**
-Configuration files nested under subdirectories of `.gitlab/dashboards` are not
-supported and won't be available in the UI.
+Configuration files nested under subdirectories of `.gitlab/dashboards` aren't
+supported or available in the UI.
 
 ## Add a new metrics panel to a dashboard
 
@@ -156,7 +156,7 @@ and end times to the URL, enabling you to share specific timeframes more easily.
 
 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
+annotation entries assigned to the selected time range are 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.

doc/operations/metrics/dashboards/panel_types.md

@@ -39,7 +39,7 @@ Note the following properties:
 
 ![area panel chart](img/prometheus_dashboard_area_panel_type_v12_8.png)
 
-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.
+Starting in [version 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/202696), the y-axis values scale according to the data. Previously, it always started from 0.
 
 ## Anomaly chart
 

doc/operations/metrics/dashboards/templating_variables.md

@@ -25,8 +25,8 @@ 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.
+For each `text` variable defined in the dashboard YAML, a free text field displays
+on the dashboard UI, allowing you to enter a value for each variable.
 
 The `text` variable type supports a simple and a full syntax.
 
@@ -44,7 +44,7 @@ templating:
 ### 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:
+The label for the text box on the UI is the value of the `label` key:
 
 ```yaml
 templating:
@@ -70,7 +70,7 @@ 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`
+The dashboard UI displays a dropdown with `value1`, `value2` and `value3`
 as the choices.
 
 ```yaml
@@ -82,12 +82,12 @@ templating:
 ### 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`
+The label for the text box on the UI is the value of the `label` key.
+The dashboard UI displays 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`:
+If you select `Option 1` from the dropdown, the variable is replaced with `value option 1`.
+Similarly, if you select `Option 2`, the variable is replaced with `value_option_2`:
 
 ```yaml
 templating:
@@ -112,8 +112,8 @@ 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
+This example creates a variable called `variable2`. The values of the dropdown are
+all the different values of the `backend` label in the Prometheus series described by
 `up{env="production"}`.
 
 ```yaml

doc/operations/metrics/dashboards/variables.md

@@ -12,7 +12,7 @@ Variables can be specified using double curly braces, such as `"{{ci_environment
 
 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.
+Queries that continue to use the old format display no data.
 
 ## Predefined variables
 

doc/operations/metrics/dashboards/yaml.md

@@ -53,7 +53,7 @@ is no longer used.
 | `group` | string | required | Heading for the panel group. |
 | `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.
+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 take the full width of their containing row.
 
 ## **Panel (`panels`) properties**
 
@@ -87,15 +87,15 @@ is no longer used.
 | `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/number | 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 used. |
-| `query_range` | string/number | 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 used. |
+| `query` | string/number | 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/) is used. |
+| `query_range` | string/number | 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/) is used. |
 | `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:
+When a static label is used and a query returns multiple time series, then all the legend items are labeled the same, which makes identifying each time series difficult:
 
 ```yaml
 metrics:
@@ -109,7 +109,7 @@ This may render a legend like this:
 
 ![repeated legend label chart](img/prometheus_dashboard_repeated_label.png)
 
-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:
+For labels to be more explicit, using variables that reflect time series labels is a good practice. The variables are replaced by the values of the time series labels when the legend is rendered:
 
 ```yaml
 metrics:
@@ -119,7 +119,7 @@ metrics:
     unit: 'count'
 ```
 
-The resulting rendered legend will look like this:
+The resulting rendered legend looks like this:
 
 ![legend with label variables](img/prometheus_dashboard_label_variables.png)
 
@@ -133,7 +133,7 @@ metrics:
     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:
+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 renders in the legend like this:
 
 ![legend with label shorthand variable](img/prometheus_dashboard_label_variable_shorthand.png)
 

doc/operations/metrics/index.md

@@ -147,7 +147,7 @@ After saving them, they display on the environment metrics dashboard provided th
 A few fields are required:
 
 - **Name**: Chart title
-- **Type**: Type of metric. Metrics of the same type will be shown together.
+- **Type**: Type of metric. Metrics of the same type are 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.

doc/operations/tracing.md

@@ -38,4 +38,4 @@ GitLab provides an easy way to open the Jaeger UI from within your project:
 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.
+   GitLab redirects you to the configured Jaeger URL.

doc/raketasks/generate_sample_prometheus_data.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Generate sample Prometheus data **(CORE ONLY)**
 
-This command will run Prometheus queries for each of the metrics of a specific environment
+This command runs Prometheus queries for each of the metrics of a specific environment
 for a series of time intervals to now:
 
 - 30 minutes

doc/user/project/integrations/prometheus_library/nginx_ingress_vts.md

@@ -27,7 +27,7 @@ GitLab has support for automatically detecting and monitoring the Kubernetes NGI
 
 ## Configuring NGINX Ingress monitoring
 
-If you have deployed NGINX Ingress using GitLab's [Kubernetes cluster integration](../../clusters/index.md#installing-applications), it will [automatically be monitored](#about-managed-nginx-ingress-deployments) by Prometheus.
+If you have deployed NGINX Ingress using GitLab's [Kubernetes cluster integration](../../clusters/index.md#installing-applications), Prometheus [automatically monitors](#about-managed-nginx-ingress-deployments) it.
 
 For other deployments, there is [some configuration](#manually-setting-up-nginx-ingress-for-prometheus-monitoring) required depending on your installation:
 
@@ -37,7 +37,7 @@ For other deployments, there is [some configuration](#manually-setting-up-nginx-
 
 ### About managed NGINX Ingress deployments
 
-NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress will be [externally reachable via the Load Balancer's Endpoint](../../../clusters/applications.md#ingress).
+NGINX Ingress is deployed into the `gitlab-managed-apps` namespace, using the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). NGINX Ingress is [externally reachable via the Load Balancer's Endpoint](../../../clusters/applications.md#ingress).
 
 NGINX is configured for Prometheus monitoring, by setting:
 
@@ -45,11 +45,11 @@ NGINX is configured for Prometheus monitoring, by setting:
 - `prometheus.io/scrape: "true"`, to enable automatic discovery.
 - `prometheus.io/port: "10254"`, to specify the metrics port.
 
-When used in conjunction with the GitLab deployed Prometheus service, response metrics will be automatically collected.
+When used in conjunction with the GitLab deployed Prometheus service, response metrics are automatically collected.
 
 ### Manually setting up NGINX Ingress for Prometheus monitoring
 
-Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) has built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint will start running on port 10254.
+Version 0.9.0 and above of [NGINX Ingress](https://github.com/kubernetes/ingress-nginx) has built-in support for exporting Prometheus metrics. To enable, a ConfigMap setting must be passed: `enable-vts-status: "true"`. Once enabled, a Prometheus metrics endpoint begins running on port 10254.
 
 Next, the Ingress needs to be annotated for Prometheus monitoring. Two new annotations need to be added:
 
@@ -60,6 +60,6 @@ Managing these settings depends on how NGINX Ingress has been deployed. If you h
 
 ## Specifying the Environment label
 
-In order to isolate and only display relevant metrics for a given environment, GitLab needs a method to detect which labels are associated. To do this, GitLab will search for metrics with appropriate labels. In this case, the `upstream` label must be of the form `<KUBE_NAMESPACE>-<CI_ENVIRONMENT_SLUG>-*`.
+In order to isolate and only display relevant metrics for a given environment, GitLab needs a method to detect which labels are associated. To do this, GitLab searches for metrics with appropriate labels. In this case, the `upstream` label must be of the form `<KUBE_NAMESPACE>-<CI_ENVIRONMENT_SLUG>-*`.
 
-If you have used [Auto Deploy](../../../../topics/autodevops/stages.md#auto-deploy) to deploy your app, this format will be used automatically and metrics will be detected with no action on your part.
+If you have used [Auto Deploy](../../../../topics/autodevops/stages.md#auto-deploy) to deploy your app, this format is used automatically and metrics are detected with no action on your part.