Replace all blockquote admonitions with the shortcode (#7420)

The [`admonition` shortcode](https://grafana.com/docs/writers-toolkit/write/shortcodes/#admonition) renders its content in a blockquote with consistent styling across the website.

Signed-off-by: Jack Baldry <jack.baldry@grafana.com>

docs/sources/mimir/configure/about-anonymous-usage-statistics-reporting.md

@@ -57,7 +57,9 @@ When the usage statistics reporting is enabled, Grafana Mimir collects the follo
       - Metadata query.
       - Cardinality analysis query.
 
-> **Note**: Mimir maintainers commit to keeping the list of tracked information updated over time, and reporting any change both via the CHANGELOG and the release notes.
+{{< admonition type="note" >}}
+Mimir maintainers commit to keeping the list of tracked information updated over time, and reporting any change both via the CHANGELOG and the release notes.
+{{< /admonition >}}
 
 ## Disable the anonymous usage statistics reporting
 

docs/sources/mimir/configure/about-runtime-configuration.md

@@ -99,4 +99,10 @@ An advanced runtime configuration option controls if ingesters transfer encoded
 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.
 
-> **Note:** The parameter `ingester_stream_chunks_when_using_blocks` in the runtime configuration can override the CLI flag `-ingester.stream-chunks-when-using-blocks`, which is enabled by default. We strongly recommend to keep it enabled, except in rare cases where you observe rules evaluation slowing down.
+{{< admonition type="note" >}}
+By default, `-ingester.stream-chunks-when-using-blocks` is `true` which enables transfer of encoded chunks.
+
+In runtime configuration, the parameter `ingester_stream_chunks_when_using_blocks` overrides the CLI flag `-ingester.stream-chunks-when-using-blocks`.
+
+It's strongly recommended that you keep the transfer of encoded chunks enabled, except in rare cases where you observe rules evaluation slowing down.
+{{< /admonition >}}

docs/sources/mimir/configure/about-tenant-ids.md

@@ -30,7 +30,12 @@ Tenant IDs must be less-than or equal-to 150 bytes or characters in length and c
   - Open parenthesis (`(`)
   - Close parenthesis (`)`)
 
-> **Note:** For security reasons, `.` and `..` are not valid tenant IDs.
-> **Note:** The tenant ID `__mimir_cluster` is unsupported because its name is used internally by Mimir.
+{{< admonition type="note" >}}
+For security reasons, `.` and `..` aren't valid tenant IDs.
+{{< /admonition >}}
 
-All other characters, including slashes and whitespace, are not supported.
+{{< admonition type="note" >}}
+`__mimir_cluster` isn't a valid tenant ID because Mimir uses the name internally.
+{{< /admonition >}}
+
+All other characters, including slashes and whitespace, aren't supported.

docs/sources/mimir/configure/configure-custom-trackers.md

@@ -62,4 +62,10 @@ cortex_ingester_active_series_custom_tracker{name="service2", user="tenant_with_
 
 To set up runtime overrides, refer to [runtime configuration]({{< relref "./about-runtime-configuration" >}}).
 
-> **Note:** The custom active series trackers are exposed on each ingester. To understand the count of active series matching a particular label pattern in your Grafana Mimir cluster at a global level, you must collect and sum this metric across all ingesters. If you're running Grafana Mimir with a `replication_factor` > 1, you must also adjust for the fact that the same series will be replicated `RF` times across your ingesters.
+{{< admonition type="note" >}}
+Each ingester exposese the custom active series trackers.
+
+To understand the count of active series matching a particular label pattern in your Grafana Mimir cluster at a global level, you must collect and sum this metric across all ingesters.
+
+If you're running Grafana Mimir with a `replication_factor` > 1, you must also adjust for the fact that Mimir replicates the same series across your ingesters replication factor times.
+{{< /admonition >}}

docs/sources/mimir/configure/configure-hash-rings.md

@@ -59,11 +59,19 @@ The `-memberlist.join` can be set to:
 
 The default port is `7946`.
 
-> **Note**: At a minimum, configure one or more addresses that resolve to a consistent subset of replicas (for example, all the ingesters).
+{{< admonition type="note" >}}
+At a minimum, configure one or more addresses that resolve to a consistent subset of replicas (for example, all the ingesters).
+{{< /admonition >}}
 
-> **Note**: If you're running Grafana Mimir in Kubernetes, define a [headless Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) which resolves to the IP addresses of all Grafana Mimir pods. Then you set `-memberlist.join` to `dnssrv+<service name>.<namespace>.svc.cluster.local:<port>`.
+{{< admonition type="note" >}}
+If you're running Grafana Mimir in Kubernetes, define a [headless Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) which resolves to the IP addresses of all Grafana Mimir Pods.
 
-> **Note**: The `memberlist` backend is configured globally and can't be customized on a per-component basis. Because `memberlist` is configured globally, the `memberlist` backend differs from other supported backends, such as Consul or etcd.
+Then set `-memberlist.join` to `dnssrv+<service name>.<namespace>.svc.cluster.local:<port>`.
+{{< /admonition >}}
+
+{{< admonition type="note" >}}
+The `memberlist` backend is configured globally, unlike other supported backends, and can't be customized on a per-component basis.
+{{< /admonition >}}
 
 Grafana Mimir supports TLS for memberlist connections between its components.
 For more information about TLS configuration, refer to [secure communications with TLS]({{< relref "../manage/secure/securing-communications-with-tls" >}}).
@@ -159,7 +167,10 @@ You can use the following parameters to configure the multi KV store settings:
 - `<prefix>.multi.mirror-enabled`: Whether mirroring of writes to the secondary backend store is enabled.
 - `<prefix>.multi.mirror-timeout`: The maximum time allowed to mirror a change to the secondary backend store.
 
-> **Note**: Grafana Mimir does not log an error if it is unable to mirror writes to the secondary backend store. The total number of errors is only tracked through the metric `cortex_multikv_mirror_write_errors_total`.
+{{< admonition type="note" >}}
+Grafana Mimir doesn't log an error if it's unable to mirror writes to the secondary backend store.
+However, the total number of errors is tracked through the metric `cortex_multikv_mirror_write_errors_total`.
+{{< /admonition >}}
 
 The multi KV primary backend and mirroring can also be configured in the [runtime configuration file]({{< relref "./about-runtime-configuration" >}}).
 Changes to a multi KV Store in the runtime configuration apply to _all_ components using a multi KV store.
@@ -173,7 +184,9 @@ multi_kv_config:
   mirror_enabled: true
 ```
 
-> **Note**: The runtime configuration settings take precedence over CLI flags.
+{{< admonition type="note" >}}
+The runtime configuration settings take precedence over CLI flags.
+{{< /admonition >}}
 
 #### Ingester migration example
 

docs/sources/mimir/configure/configure-high-availability-deduplication.md

@@ -24,10 +24,15 @@ that `team-1.b` sends are dropped. And if Grafana Mimir does not see any new sam
 If `team-1.a` goes down for more than 30 seconds, Grafana Mimir’s HA sample handling will have switched and elected `team-1.b` as the leader. The failure
 timeout ensures that too much data is not dropped before failover to the other replica.
 
-> **Note:** In a scenario where the default scrape period is 15 seconds, and the timeouts in Grafana Mimir are set to the default values,
-> when a leader-election failover occurs, you'll likely only lose a single scrape of data. For any query using the `rate()` function, make the rate time interval
-> at least four times that of the scrape period to account for any of these failover scenarios.
-> For example, with the default scrape period of 15 seconds, use a rate time-interval at least 1-minute.
+{{< admonition type="note" >}}
+In a scenario where the default scrape period is 15 seconds, and the timeouts in Grafana Mimir are set to the default values,
+when a leader-election failover occurs, you'll likely only lose a single scrape of data.
+
+For any query using the `rate()` function, make the rate time interval
+at least four times that of the scrape period to account for any of these failover scenarios.
+
+For example, with the default scrape period of 15 seconds, use a rate time-interval at least 1-minute.
+{{< /admonition >}}
 
 ## Distributor high-availability (HA) tracker
 
@@ -69,14 +74,18 @@ global:
     __replica__: replica2
 ```
 
-> **Note:** The preceding labels are external labels and have nothing to do with `remote_write` configuration.
+{{< admonition type="note" >}}
+The preceding labels are external labels and have nothing to do with `remote_write` configuration.
+{{< /admonition >}}
 
 These two label names are configurable on a per-tenant basis within Grafana Mimir. For example, if the label name of one cluster is used by
 some workloads, set the label name of another cluster to something else that uniquely identifies the second cluster.
 
 Set the replica label so that the value for each Prometheus cluster is unique in that cluster.
 
-> **Note:** Grafana Mimir drops this label when ingesting data, but preserves the cluster label. This way, your timeseries won't change when replicas change.
+{{< admonition type="note" >}}
+Grafana Mimir drops this label when ingesting data, but preserves the cluster label. This way, your time series won't change when replicas change.
+{{< /admonition >}}
 
 ### How to configure Grafana Mimir
 
@@ -99,8 +108,13 @@ Alternatively, you can enable the HA tracker only on a per-tenant basis, keeping
 The HA tracker requires a key-value (KV) store to coordinate which replica is currently elected.
 The supported KV stores for the HA tracker are `consul` and `etcd`.
 
-> **Note:** `memberlist` is not supported. Memberlist-based KV stores propagate updates using the Gossip protocol, which is too slow for the
-> HA tracker. The result would be that different distributors might see a different Prometheus server elected as leaders at the same time.
+{{< admonition type="note" >}}
+`memberlist` isn't supported.
+
+Memberlist-based KV stores propagate updates using the Gossip protocol, which is too slow for the HA tracker.
+
+The result would be that different distributors might see a different Prometheus server elected as leaders at the same time.
+{{< /admonition >}}
 
 The following CLI flags (and their respective YAML configuration options) are available for configuring the HA tracker KV store:
 
@@ -118,7 +132,9 @@ Configure the default cluster and replica label names using the following CLI fl
 - `-distributor.ha-tracker.cluster`: Name of the label whose value uniquely identifies a Prometheus HA cluster (defaults to `cluster`).
 - `-distributor.ha-tracker.replica`: Name of the label whose value uniquely identifies a Prometheus replica within the HA cluster (defaults to `__replica__`).
 
-> **Note:** The HA label names can be overridden on a per-tenant basis by setting `ha_cluster_label` and `ha_replica_label` in the overrides section of the runtime configuration.
+{{< admonition type="note" >}}
+The HA label names can be overridden on a per-tenant basis by setting `ha_cluster_label` and `ha_replica_label` in the overrides section of the runtime configuration.
+{{< /admonition >}}
 
 #### Example configuration
 

docs/sources/mimir/configure/configure-object-storage-backend.md

@@ -36,16 +36,23 @@ but it is a read-only data source and can be used to provision state into those
 
 To avoid repetition, you can use the [common configuration]({{< relref "./about-configurations#common-configurations" >}}) and fill the [`common`]({{< relref "./configuration-parameters#common" >}}) configuration block or by providing the `-common.storage.*` CLI flags.
 
-> **Note:** Blocks storage cannot be located in the same path of the same bucket as the ruler and alertmanager stores. When using the common configuration, make [`blocks_storage`]({{< relref "./configuration-parameters#blocks_storage" >}}) use either a:
+{{< admonition type="note" >}}
+Blocks storage can't be located in the same path of the same bucket as the ruler and Alertmanager stores.
+
+When using the common configuration, make [`blocks_storage`]({{< relref "./configuration-parameters#blocks_storage" >}}) use either a:
 
 - different bucket, overriding the common bucket name
 - storage prefix
 
-Grafana Mimir will fail to start if you configure blocks storage to use the same bucket and storage prefix that the alertmanager or ruler store uses.
+{{< /admonition >}}
+
+Grafana Mimir will fail to start if you configure blocks storage to use the same bucket and storage prefix that the Alertmanager or ruler store uses.
 
 Find examples of setting up the different object stores below:
 
-> **Note**: If you're using a mixture of YAML files and CLI flags, pay attention to their [precedence logic]({{< relref "./about-configurations#common-configurations" >}}).
+{{< admonition type="note" >}}
+If you're using a mixture of YAML files and CLI flags, pay attention to their [precedence logic]({{< relref "./about-configurations#common-configurations" >}}).
+{{< /admonition >}}
 
 ### S3
 

docs/sources/mimir/configure/configure-out-of-order-samples-ingestion.md

@@ -69,5 +69,8 @@ The moment that a new series sample arrives, Mimir needs to determine if the ser
 
 The experimental out-of-order ingestion helps fix both the issues.
 
-> **Note:** If you're writing metrics using Prometheus remote write or the Grafana Agent, then out-of-order samples are unexpected.
-> Prometheus and Grafana Agent guarantee that samples are written in-order for the same series.
+{{< admonition type="note" >}}
+If you're writing metrics using Prometheus remote write or Grafana Agent, then you shouldn't expect out-of-order samples.
+
+Prometheus and Grafana Agent guarantee that samples are written in-order for the same series.
+{{< /admonition >}}

docs/sources/mimir/configure/configure-shuffle-sharding/index.md

@@ -71,7 +71,9 @@ Grafana Mimir supports shuffle sharding in the following components:
 
 When you run Grafana Mimir with the default configuration, shuffle sharding is disabled and you need to explicitly enable it by increasing the shard size either globally or for a given tenant.
 
-> **Note:** If the shard size value is equal to or higher than the number of available instances, for example where `-distributor.ingestion-tenant-shard-size` is higher than the number of ingesters, then shuffle sharding is disabled and all instances are used again.
+{{< admonition type="note" >}}
+If the shard size value is equal to or higher than the number of available instances, for example where `-distributor.ingestion-tenant-shard-size` is higher than the number of ingesters, then shuffle sharding is disabled and all instances are used again.
+{{< /admonition >}}
 
 ### Guaranteed properties
 

docs/sources/mimir/configure/configure-zone-aware-replication.md

@@ -26,11 +26,13 @@ If an outage affects a zone containing multiple replicas, data loss might occur.
 
 With zone-aware replication enabled, Grafana Mimir ensures data replication to replicas across different zones.
 
-> **Warning:**
-> Ensure that you configure deployment tooling so that it is also zone-aware.
-> The deployment tooling is responsible for executing rolling updates.
-> Rolling updates should only update replicas in a single zone at any given time.
-> You can utilize the [Kubernetes rollout Operator](#kubernetes-operator-for-simplifying-rollouts-of-zone-aware-components) to assist with this.
+{{< admonition type="warning" >}}
+Ensure that you configure deployment tooling so that it's also zone-aware.
+The deployment tooling is responsible for executing rolling updates.
+
+Rolling updates should only update replicas in a single zone at any given time.
+You can utilize the [Kubernetes rollout Operator](#kubernetes-operator-for-simplifying-rollouts-of-zone-aware-components) to assist with this.
+{{< /admonition >}}
 
 Grafana Mimir supports zone-aware replication for the following:
 
@@ -81,9 +83,12 @@ When replica counts are unbalanced, zones with fewer replicas have higher resour
 Most cloud providers charge for inter-availability zone networking.
 Deploying Grafana Mimir with zone-aware replication across multiple cloud provider availability zones likely results in additional networking costs.
 
-> **Note:** The requests that the distributors receive are usually compressed, and the requests that the distributors send to the ingesters are uncompressed by default.
-> This can result in increased cross-zone bandwidth costs (because at least two ingesters will be in different availability zones).
-> If this cost is a concern, you can compress those requests by setting the `-ingester.client.grpc-compression` CLI flag, or its respective YAML configuration parameter, to `snappy` or `gzip` in the distributors.
+{{< admonition type="note" >}}
+The requests that the distributors receive are usually compressed, and the requests that the distributors send to the ingesters are uncompressed by default.
+This can result in increased cross-zone bandwidth costs because at least two ingesters will be in different availability zones.
+
+If this cost is a concern, you can compress those requests by setting the `-ingester.client.grpc-compression` CLI flag, or its respective YAML configuration parameter, to `snappy` or `gzip` in the distributors.
+{{< /admonition >}}
 
 ## Kubernetes operator for simplifying rollouts of zone-aware components
 

docs/sources/mimir/get-started/_index.md

@@ -21,8 +21,11 @@ You can get started with Grafana Mimir _imperatively_ or _declaratively_:
 - Verify that you have installed either a [Prometheus server](https://prometheus.io/docs/prometheus/latest/installation/) or [Grafana Agent](/docs/grafana-cloud/monitor-infrastructure/integrations/agent/flow/setup/install/).
 - Verify that you have installed [Docker](https://docs.docker.com/engine/install/).
 
-> **Note:** The instructions that follow help you to deploy Grafana Mimir in [Monolithic mode]({{< relref "../references/architecture/deployment-modes#monolithic-mode" >}}).
-> For information about the different ways to deploy Grafana Mimir, refer to [Grafana Mimir deployment modes]({{< relref "../references/architecture/deployment-modes" >}}).
+{{< admonition type="note" >}}
+The instructions that follow help you to deploy Grafana Mimir in [Monolithic mode]({{< relref "../references/architecture/deployment-modes#monolithic-mode" >}}).
+
+For information about the different ways to deploy Grafana Mimir, refer to [Grafana Mimir deployment modes]({{< relref "../references/architecture/deployment-modes" >}}).
+{{< /admonition >}}
 
 ## Download Grafana Mimir
 
@@ -99,9 +102,11 @@ store_gateway:
 ```
 <!-- prettier-ignore-end -->
 
-> **Note**: Grafana Mimir includes a system that optionally and anonymously reports non-sensitive, non-personally identifiable information about the running Mimir cluster to a remote statistics server.
-> If possible and to help us understand more about how the open source community runs Mimir, we kindly ask you to keep the usage reporting feature enabled.
-> To opt out, refer to [Disable the anonymous usage statistics reporting]({{< relref "../configure/about-anonymous-usage-statistics-reporting#disable-the-anonymous-usage-statistics-reporting" >}}).
+{{< admonition type="note" >}}
+Grafana Mimir includes a system that optionally and anonymously reports non-sensitive, non-personally identifiable information about the running Mimir cluster to a remote statistics server to help Mimir maintainers understand how the open source community runs Mimir.
+
+To opt out, refer to [Disable the anonymous usage statistics reporting]({{< relref "../configure/about-anonymous-usage-statistics-reporting#disable-the-anonymous-usage-statistics-reporting" >}}).
+{{< /admonition >}}
 
 ## Run Grafana Mimir
 

docs/sources/mimir/get-started/about-grafana-mimir-architecture/index.md

@@ -65,7 +65,9 @@ Queries coming into Grafana Mimir arrive at the [query-frontend]({{< relref "../
 
 The query-frontend next checks the results cache. If the result of a query has been cached, the query-frontend returns the cached results. Queries that cannot be answered from the results cache are put into an in-memory queue within the query-frontend.
 
-> **Note:** If you run the optional [query-scheduler]({{< relref "../../references/architecture/components/query-scheduler" >}}) component, this queue is maintained in the query-scheduler instead of the query-frontend.
+{{< admonition type="note" >}}
+If you run the optional [query-scheduler]({{< relref "../../references/architecture/components/query-scheduler" >}}) component, the query-schedule maintains the queue instead of the query-frontend.
+{{< /admonition >}}
 
 The queriers act as workers, pulling queries from the queue.