Review configuration topics (#1485)

* Review configuration topics not previously copy edited

* make doc

* Apply suggestions from code review

Co-authored-by: Marco Pracucci <marco@pracucci.com>

Co-authored-by: Marco Pracucci <marco@pracucci.com>

docs/sources/operators-guide/configuring/about-dns-service-discovery.md

@@ -7,15 +7,16 @@ weight: 20
 
 # About Grafana Mimir DNS service discovery
 
-Some clients in Grafana Mimir support service discovery via DNS to find the addresses of backend servers to connect to. These clients support service discovery via DNS:
+Some clients in Grafana Mimir support service discovery via DNS to locate the addresses of backend servers to connect to. The following clients support service discovery via DNS:
 
 - [Block storage's memcached cache]({{< relref "reference-configuration-parameters/#blocks_storage" >}})
 - [All caching memcached servers]({{< relref "reference-configuration-parameters/#memcached" >}})
 - [Memberlist KV store]({{< relref "reference-configuration-parameters#memberlist" >}})
 
 ## Supported discovery modes
 
-The DNS service discovery supports different discovery modes. A discovery mode is selected adding a specific prefix to the address. Supported prefixes are:
+DNS service discovery supports different discovery modes.
+You select a discovery mode by adding one of the following supported prefixes to the address:
 
 - **`dns+`**<br />
   The domain name after the prefix is looked up as an A/AAAA query. For example: `dns+memcached.local:11211`.
@@ -24,4 +25,4 @@ The DNS service discovery supports different discovery modes. A discovery mode i
 - **`dnssrvnoa+`**<br />
   The domain name after the prefix is looked up as a SRV query, with no A/AAAA lookup made after that. For example: `dnssrvnoa+_memcached._tcp.memcached.namespace.svc.cluster.local`.
 
-If no prefix is provided, the provided IP or hostname will be used without pre-resolving it.
+If no prefix is provided, the provided IP or hostname is used without pre-resolving it.

docs/sources/operators-guide/configuring/about-ip-address-logging.md

@@ -7,16 +7,17 @@ weight: 30
 
 # About Grafana Mimir IP address logging of a reverse proxy
 
-If a reverse proxy is used in front of Mimir, it may be difficult to troubleshoot errors. The following settings can be used to log the IP address passed along by the reverse proxy in headers such as `X-Forwarded-For`.
+If a reverse proxy is used in front of Mimir, it might be difficult to troubleshoot errors.
+You can use the following settings to log the IP address passed along by the reverse proxy in headers such as `X-Forwarded-For`.
 
 - `-server.log-source-ips-enabled`
 
-  Set this to true to add IP address logging when a `Forwarded`, `X-Real-IP` or `X-Forwarded-For` header is used. A field called `sourceIPs` will be added to error logs when data is pushed into Grafana Mimir.
+  Set this to `true` to add IP address logging when a `Forwarded`, `X-Real-IP`, or `X-Forwarded-For` header is used. A field called `sourceIPs` is added to error logs when data is pushed into Grafana Mimir.
 
 - `-server.log-source-ips-header`
 
-  Header field storing the source IP addresses. It is only used if `-server.log-source-ips-enabled` is true, and if `-server.log-source-ips-regex` is set. If not set, the default `Forwarded`, `X-Real-IP` or `X-Forwarded-For` headers are searched.
+  The header field stores the source IP addresses and is used only if `-server.log-source-ips-enabled` is `true`, and if `-server.log-source-ips-regex` is set. If you do not set these flags, the default `Forwarded`, `X-Real-IP`, or `X-Forwarded-For` headers are searched.
 
 - `-server.log-source-ips-regex`
 
-  Regular expression for matching the source IPs. It should contain at least one capturing group the first of which will be returned. Only used if `-server.log-source-ips-enabled` is true and if `-server.log-source-ips-header` is set.
+  A regular expression that is used to match the source IPs. The regular expression must contain at least one capturing group, the first of which is returned. This flag is used only if `-server.log-source-ips-enabled` is `true` and if `-server.log-source-ips-header` is set.

docs/sources/operators-guide/configuring/about-runtime-configuration.md

@@ -7,9 +7,11 @@ weight: 40
 
 # About Grafana Mimir runtime configuration
 
-A runtime configuration file is a file containing configuration, which is periodically reloaded while Mimir is running. It allows you to change a subset of Grafana Mimir’s configuration without having to restart the Grafana Mimir component or instance.
+A runtime configuration file is a file that contains configuration parameters, which is periodically reloaded while Mimir is running.
+It allows you to change a subset of Grafana Mimir’s configuration without having to restart the Grafana Mimir component or instance.
 
-Runtime configuration is available for a subset of the configuration that was set at startup. A Grafana Mimir operator can observe the configuration and use runtime configuration to make immediate adjustments to Grafana Mimir.
+Runtime configuration is available for a subset of the configuration that was set at startup.
+A Grafana Mimir operator can observe the configuration and use runtime configuration to make immediate adjustments to Grafana Mimir.
 
 Runtime configuration values take precedence over command-line options.
 
@@ -27,11 +29,11 @@ Use Grafana Mimir’s `/runtime_config` endpoint to see the current value of the
 
 ## Runtime configuration of per-tenant limits
 
-The primary use case for the runtime configuration file is that it allows you to set and adjust limits for each tenant in Grafana Mimir. Doing so lets you set limits that are appropriate for each tenant based on their ingest and query needs.
+The runtime configuration file is primarily used to set and adjust limits that are appropriate for each tenant based on their ingest and query needs.
 
-The values that are defined in the limits section of your YAML configuration define the default set of limits that are applied to tenants. For example, if you set the `ingestion_rate` to 25,000 in your YAML configuration file, any tenant in your cluster that is sending more than 25,000 samples per second (SPS) will be rate limited.
+The values that are defined in the limits section of your YAML configuration define the default set of limits that are applied to tenants. For example, if you set the `ingestion_rate` to `25,000` in your YAML configuration file, any tenant in your cluster that sends more than 25,000 samples per second (SPS) is rate limited.
 
-You can use the runtime configuration file to override this behavior. For example, if you have a tenant (`tenant1`) that needs to send twice as many data points as the current limit, and you have another tenant (`tenant2`) that needs to send three times as many data points, you can modify the contents of your runtime configuration file:
+You can use the runtime configuration file to override this behavior. For example, if you have a tenant (`tenant1`) that needs to send twice as many data points as the current limit, and you have another tenant (`tenant2`) that needs to send three times as many data points, you can modify the contents of your runtime configuration file as follows:
 
 ```yaml
 overrides:
@@ -49,13 +51,13 @@ As a result, Grafana Mimir allows `tenant1` to send 50,000 SPS, and `tenant2` to
 
 ## Ingester instance limits
 
-Grafana Mimir ingesters support limits that are applied per instance, meaning that they apply to each ingester process. These limits can be used to ensure individual ingesters are not overwhelmed regardless of any per-tenant limits. These limits can be set under the `ingester.instance_limits` block in the global configuration file, with CLI flags, or under the `ingester_limits` field in the runtime configuration file.
-
-The runtime configuration file can be used to dynamically adjust ingester instance limits. While per-tenant limits are limits applied to each tenant, per-ingester-instance limits are limits applied to each ingester process.
+The runtime configuration file can be used to dynamically adjust Grafana Mimir ingester instance limits. While per-tenant limits are limits applied to each tenant, per-ingester-instance limits are limits applied to each ingester process.
+Ingester limits ensure individual ingesters are not overwhelmed, regardless of any per-tenant limits. These limits can be set under the `ingester.instance_limits` block in the global configuration file, with CLI flags, or under the `ingester_limits` field in the runtime configuration file.
 
 The runtime configuration allows you to override initial values, which is useful for advanced operators who need to dynamically change them in response to changes in ingest or query load.
 
-Everything under the `instance_limits` section within the [`ingester`]({{< relref "reference-configuration-parameters/#ingester" >}}) block can be overridden via runtime configuration. Here is an example portion of runtime configuration that changes the ingester limits:
+Everything under the `instance_limits` section within the [`ingester`]({{< relref "reference-configuration-parameters/#ingester" >}}) block can be overridden via runtime configuration.
+The following example shows a portion of the runtime configuration that changes the ingester limits:
 
 ```yaml
 ingester_limits:
@@ -67,11 +69,9 @@ ingester_limits:
 
 ## Runtime configuration of ingester streaming
 
-An advanced runtime configuration
-controls whether ingesters transfer encoded chunks (the default) or transfer decoded series to queriers at query time.
+An advanced runtime configuration option controls if ingesters transfer encoded chunks (the default) or transfer decoded series to queriers at query time.
 
-The parameter `ingester_stream_chunks_when_using_blocks` may only be used in runtime configuration.
-A value of true transfers encoded chunks,
-and a value of false transfers decoded series.
+The parameter `ingester_stream_chunks_when_using_blocks` might only be used in runtime configuration.
+A value of `true` transfers encoded chunks, and a value of `false` transfers decoded series.
 
-We strongly recommend against changing the default setting. It already defaults to true, and should remain true except for rare corner cases where users have observed slowdowns in Grafana Mimir rules evaluation.
+> **Note:** We strongly recommend that you use the default setting, which is `true`, except in rare cases where users observe Grafana Mimir rules evaluation slowing down.

docs/sources/operators-guide/configuring/about-tenant-ids.md

@@ -12,7 +12,7 @@ For information about how Grafana Mimir components use tenant IDs, refer to [Aut
 
 ## Restrictions
 
-Tenant IDs must be less-than or equal-to 150 bytes or characters in length and must comprise only supported characters:
+Tenant IDs must be less-than or equal-to 150 bytes or characters in length and can only include the following supported characters:
 
 - Alphanumeric characters
   - `0-9`