Docs: Move architecture components doc to Hugo bundles

docs/sources/operators-guide/architecture/about-grafana-mimir-architecture.md

@@ -48,9 +48,9 @@ For more information, refer to [timeline of block uploads]({{< relref "../runnin
 #### Series sharding and replication
 
 By default, each time series is replicated to three ingesters, and each ingester writes its own block to the long-term storage.
-The [Compactor]({{< relref "components/compactor.md" >}}) merges blocks from multiple ingesters into a single block, and removes duplicate samples.
+The [Compactor]({{< relref "components/compactor/index.md" >}}) merges blocks from multiple ingesters into a single block, and removes duplicate samples.
 Blocks compaction significantly reduces storage utilization.
-For more information, refer to [Compactor]({{< relref "components/compactor.md" >}}) and [Production tips]({{< relref "../running-production-environment/production-tips.md" >}}).
+For more information, refer to [Compactor]({{< relref "components/compactor/index.md" >}}) and [Production tips]({{< relref "../running-production-environment/production-tips.md" >}}).
 
 ### The read path
 

docs/sources/operators-guide/architecture/bucket-index.md

@@ -38,7 +38,7 @@ The `bucket-index.json.gz` contains:
 
 ## How it gets updated
 
-The [compactor](./compactor.md) periodically scans the bucket and uploads an updated bucket index to the storage.
+The [compactor](./compactor/index.md) periodically scans the bucket and uploads an updated bucket index to the storage.
 You can configure the frequency with which the bucket index is updated via `-compactor.cleanup-interval`.
 
 The use of the bucket index is optional, but the index is built and updated by the compactor even if `-blocks-storage.bucket-store.bucket-index.enabled=false`.

docs/sources/operators-guide/architecture/components/compactor.md → docs/sources/operators-guide/architecture/components/compactor/index.md

@@ -12,7 +12,7 @@ The compactor increases query performance and reduces long-term storage usage by
 The compactor is the component responsible for:
 
 - Compacting multiple blocks of a given tenant into a single, optimized larger block. This deduplicates chunks and reduces the size of the index, resulting in reduced storage costs. Querying fewer blocks is faster, so it also increases query speed.
-- Keeping the per-tenant bucket index updated. The [bucket index]({{< relref "../bucket-index.md" >}}) is used by [queriers]({{< relref "querier.md" >}}), [store-gateways]({{< relref "store-gateway.md" >}}), and [rulers]({{< relref "ruler.md" >}}) to discover both new blocks and deleted blocks in the storage.
+- Keeping the per-tenant bucket index updated. The [bucket index]({{< relref "../../bucket-index.md" >}}) is used by [queriers]({{< relref "../querier.md" >}}), [store-gateways]({{< relref "../store-gateway.md" >}}), and [rulers]({{< relref "../ruler.md" >}}) to discover both new blocks and deleted blocks in the storage.
 - Deleting blocks that are no longer within a configurable retention period.
 
 The compactor is stateless.
@@ -27,7 +27,7 @@ The compactor runs at regular, configurable intervals.
 
 **Horizontal compaction** triggers after a vertical compaction. It compacts several blocks with adjacent range periods into a single larger block. The total size of the associated block chunks does not change after horizontal compaction. The horizontal compaction may significantly reduce the size of the index and the index-header kept in memory by store-gateways.
 
-![Compactor - horizontal and vertical compaction](../../../images/compactor-horizontal-and-vertical-compaction.png)
+![Compactor - horizontal and vertical compaction](compactor-horizontal-and-vertical-compaction.png)
 
 <!-- Diagram source at https://docs.google.com/presentation/d/1bHp8_zcoWCYoNU2AhO2lSagQyuIrghkCncViSqn14cU/edit -->
 
@@ -38,7 +38,7 @@ Compaction can be tuned for clusters with large tenants. Configuration specifies
 - **Vertical scaling**<br />
   The setting `-compactor.compaction-concurrency` configures the max number of concurrent compactions running in a single compactor instance. Each compaction uses one CPU core.
 - **Horizontal scaling**<br />
-  By default, tenant blocks can be compacted by any Grafana Mimir compactor. When you enable compactor [shuffle sharding]({{< relref "../../configuring/configuring-shuffle-sharding.md" >}}) by setting `-compactor.compactor-tenant-shard-size` (or its respective YAML configuration option) to a value higher than `0` and lower than the number of available compactors, only the specified number of compactors are eligible to compact blocks for a given tenant.
+  By default, tenant blocks can be compacted by any Grafana Mimir compactor. When you enable compactor [shuffle sharding]({{< relref "../../../configuring/configuring-shuffle-sharding.md" >}}) by setting `-compactor.compactor-tenant-shard-size` (or its respective YAML configuration option) to a value higher than `0` and lower than the number of available compactors, only the specified number of compactors are eligible to compact blocks for a given tenant.
 
 ## Compaction algorithm
 
@@ -53,7 +53,7 @@ To split, the first level of compaction, for example `2h`, the compactor divides
 
 The compactor merges the split blocks for each shard. This compacts all _N_ split blocks of a given shard. The merge reduces the number of blocks from _N \* M_ to _M_. For a given compaction time range, there will be a compacted block for each of the _M_ shards.
 
-![Compactor - split-and-merge compaction strategy](../../../images/compactor-split-and-merge.png)
+![Compactor - split-and-merge compaction strategy](compactor-split-and-merge.png)
 
 <!-- Diagram source at https://docs.google.com/presentation/d/1bHp8_zcoWCYoNU2AhO2lSagQyuIrghkCncViSqn14cU/edit -->
 
@@ -73,9 +73,9 @@ The compactor shards compaction jobs, either from a single tenant or multiple te
 
 Whenever the pool of compactors grows or shrinks, tenants and jobs are resharded across the available compactor instances without any manual intervention.
 
-Compactor sharding uses a [hash ring]({{< relref "../hash-ring.md" >}}). At startup, a compactor generates random tokens and registers itself to the compactor hash ring. While running, it periodically scans the storage bucket at every interval defined by `-compactor.compaction-interval`, to discover the list of tenants in storage and compact blocks for each tenant which hash matches the token ranges assigned to the instance itself within the hash ring.
+Compactor sharding uses a [hash ring]({{< relref "../../hash-ring.md" >}}). At startup, a compactor generates random tokens and registers itself to the compactor hash ring. While running, it periodically scans the storage bucket at every interval defined by `-compactor.compaction-interval`, to discover the list of tenants in storage and compact blocks for each tenant which hash matches the token ranges assigned to the instance itself within the hash ring.
 
-To configure the compactors' hash ring, refer to [configuring hash rings]({{< relref "../../configuring/configuring-hash-rings.md" >}}).
+To configure the compactors' hash ring, refer to [configuring hash rings]({{< relref "../../../configuring/configuring-hash-rings.md" >}}).
 
 ### Waiting for a stable hash ring at startup
 
@@ -132,4 +132,4 @@ Alternatively, assuming the largest `-compactor.block-ranges` is `24h` (the defa
 Refer to the [compactor](../../../configuring/reference-configuration-parameters/#compactor)
 block section and the [limits](../../../configuring/reference-configuration-parameters/#limits) block section for details of compaction-related configuration.
 
-The [alertmanager]({{< relref "alertmanager.md" >}}) and [ruler]({{< relref "ruler.md" >}}) components can also use object storage to store their configurations and rules uploaded by users. In that case a separate bucket should be created to store alertmanager configurations and rules: using the same bucket between ruler/alertmanager and blocks will cause issues with the compactor.
+The [alertmanager]({{< relref "../alertmanager.md" >}}) and [ruler]({{< relref "../ruler.md" >}}) components can also use object storage to store their configurations and rules uploaded by users. In that case a separate bucket should be created to store alertmanager configurations and rules: using the same bucket between ruler/alertmanager and blocks will cause issues with the compactor.

docs/sources/operators-guide/architecture/components/query-frontend.md → docs/sources/operators-guide/architecture/components/query-frontend/index.md

@@ -7,7 +7,7 @@ weight: 60
 
 # Grafana Mimir query-frontend
 
-The query-frontend is a stateless component that provides the same API as the [querier]({{< relref "./querier.md" >}}) and can be used to accelerate the read path.
+The query-frontend is a stateless component that provides the same API as the [querier]({{< relref "../querier.md" >}}) and can be used to accelerate the read path.
 Although the query-frontend is not required, we recommend that you deploy it.
 When you deploy the query-frontend, you should make query requests to the query-frontend instead of the queriers.
 The queriers are required within the cluster to execute the queries.
@@ -18,7 +18,7 @@ To connect the queriers with the query-frontends, configure queriers with the qu
 
 We recommend that you run at least two query-frontend replicas for high-availability reasons.
 
-![Query-frontend architecture](../../../images/query-frontend-architecture.png)
+![Query-frontend architecture](query-frontend-architecture.png)
 
 [//]: # "Diagram source at https://docs.google.com/presentation/d/1bHp8_zcoWCYoNU2AhO2lSagQyuIrghkCncViSqn14cU/edit"
 
@@ -65,13 +65,13 @@ Although aligning the step parameter to the query time range increases the perfo
 
 ### About query sharding
 
-The query-frontend also provides [query sharding]({{< relref "query-sharding.md" >}}).
+The query-frontend also provides [query sharding]({{< relref "../../query-sharding.md" >}}).
 
 ## Why query-frontend scalability is limited
 
 The query-frontend scalability is limited by the configured number of workers per querier.
 
-When you don't use the [query-scheduler]({{< relref "./query-scheduler.md">}}), the query-frontend stores a queue of queries to execute.
+When you don't use the [query-scheduler]({{< relref "../query-scheduler/index.md">}}), the query-frontend stores a queue of queries to execute.
 A querier runs `-querier.max-concurrent` workers and each worker connects to one of the query-frontend replicas to pull queries to execute.
 A querier worker executes one query at a time.
 
@@ -88,12 +88,12 @@ The queries exceeding the configured maximum concurrency create a backlog in the
 
 The backlog might cause a suboptimal utilization of querier resources, which can result in poor query performance when you run Grafana Mimir at scale.
 
-The [query-scheduler]({{< relref "./query-scheduler.md" >}}) is an optional component that you can deploy to overcome the query-frontend scalability limitations.
+The [query-scheduler]({{< relref "../query-scheduler/index.md" >}}) is an optional component that you can deploy to overcome the query-frontend scalability limitations.
 
 ## DNS configuration and readiness
 
 When a query-frontend starts up, it does not immediately have queriers attached to it.
-The [`/ready` endpoint]({{< relref "../../reference-http-api/#readiness-probe" >}}) returns an HTTP 200 status code only when the query-frontend has at least one querier attached to it, and is then ready to serve queries.
+The [`/ready` endpoint]({{< relref "../../../reference-http-api/#readiness-probe" >}}) returns an HTTP 200 status code only when the query-frontend has at least one querier attached to it, and is then ready to serve queries.
 Configure the `/ready` endpoint as a healthcheck in your load balancer; otherwise, a query-frontend scale-out event might result in failed queries or high latency until queriers connect to the query-frontend.
 
 If you use query-frontend with query-scheduler, the `/ready` endpoint reports an HTTP 200 status code only after the query-frontend connects to at least one query-scheduler.

docs/sources/operators-guide/architecture/components/query-scheduler.md → docs/sources/operators-guide/architecture/components/query-scheduler/index.md

@@ -7,23 +7,23 @@ weight: 120
 
 # (Optional) Grafana Mimir query-scheduler
 
-The query-scheduler is an optional, stateless component that retains a queue of queries to execute, and distributes the workload to available [queriers]({{< relref "querier.md" >}}).
+The query-scheduler is an optional, stateless component that retains a queue of queries to execute, and distributes the workload to available [queriers]({{< relref "../querier.md" >}}).
 
-![Query-scheduler architecture](../../../images/query-scheduler-architecture.png)
+![Query-scheduler architecture](query-scheduler-architecture.png)
 
 [//]: # "Diagram source at https://docs.google.com/presentation/d/1bHp8_zcoWCYoNU2AhO2lSagQyuIrghkCncViSqn14cU/edit"
 
 The following flow describes how a queries moves through a Grafana Mimir cluster:
 
-1. The [query-frontend]({{< relref "./query-frontend/_index.md" >}}) receives queries, and then either splits and shards them, or serves them from the cache.
+1. The [query-frontend]({{< relref "../query-frontend/index.md" >}}) receives queries, and then either splits and shards them, or serves them from the cache.
 1. The query-frontend enqueues the queries into a query-scheduler.
 1. The query-scheduler stores the queries in an in-memory queue where they wait for a querier to pick them up.
 1. Queriers pick up the queries, and executes them.
 1. The querier sends results back to query-frontend, which then forwards the results to the client.
 
 ## Benefits of using the query-scheduler
 
-Query-scheduler enables the scaling of query-frontends. You might experience challenges when you scale query-frontend. To learn more about query-frontend scalability limits, refer to [Why query-frontend scalability is limited]({{< relref "query-frontend/_index.md#why-query-frontend-scalability-is-limited" >}}).
+Query-scheduler enables the scaling of query-frontends. You might experience challenges when you scale query-frontend. To learn more about query-frontend scalability limits, refer to [Why query-frontend scalability is limited]({{< relref "../query-frontend/index.md#why-query-frontend-scalability-is-limited" >}}).
 
 ### How query-scheduler solves query-frontend scalability limits
 

docs/sources/operators-guide/architecture/hash-ring.md

@@ -74,7 +74,7 @@ Each of the following components builds an independent hash ring:
 
 - [Ingesters]({{< relref "components/ingester.md" >}}) shard and replicate series.
 - [Distributors]({{< relref "components/distributor.md" >}}) enforce rate limits.
-- [Compactors]({{< relref "components/compactor.md" >}}) shard compaction workload.
+- [Compactors]({{< relref "components/compactor/index.md" >}}) shard compaction workload.
 - [Store-gateways]({{< relref "components/store-gateway.md" >}}) shard blocks to query from long-term storage.
 - [(Optional) Rulers]({{< relref "components/ruler.md" >}}) shard rule groups to evaluate.
 - [(Optional) Alertmanagers]({{< relref "components/alertmanager.md" >}}) shard tenants.

docs/sources/operators-guide/reference-glossary.md

@@ -30,11 +30,11 @@ Grafana Mimir comprises several components.
 Each component provides a specific function to the system.
 For component specific documentation, refer to one of the following topics:
 
-- [Compactor]({{< relref "architecture/components/compactor.md" >}})
+- [Compactor]({{< relref "architecture/components/compactor/index.md" >}})
 - [Distributor]({{< relref "architecture/components/distributor.md" >}})
 - [Ingester]({{< relref "architecture/components/ingester.md" >}})
-- [Query-frontend]({{< relref "architecture/components/query-frontend/_index.md" >}})
-- [Query-scheduler]({{< relref "architecture/components/query-scheduler.md" >}})
+- [Query-frontend]({{< relref "architecture/components/query-frontend/index.md" >}})
+- [Query-scheduler]({{< relref "architecture/components/query-scheduler/index.md" >}})
 - [Store-gateway]({{< relref "architecture/components/store-gateway.md" >}})
 - [Optional: Alertmanager]({{< relref "architecture/components/alertmanager.md" >}})
 - [Optional: Ruler]({{< relref "architecture/components/ruler.md" >}})

docs/sources/operators-guide/reference-http-api/_index.md

@@ -305,7 +305,7 @@ This endpoint displays a web page with the ingesters hash ring status, including
 
 ## Querier / Query-frontend
 
-The following endpoints are exposed both by the [querier]({{< relref "../architecture/components/querier.md" >}}) and [query-frontend]({{< relref "../architecture/components/query-frontend/_index.md" >}}).
+The following endpoints are exposed both by the [querier]({{< relref "../architecture/components/querier.md" >}}) and [query-frontend]({{< relref "../architecture/components/query-frontend/index.md" >}}).
 
 ### Instant query
 

docs/sources/operators-guide/running-production-environment/planning-capacity.md

@@ -75,7 +75,7 @@ Estimated required CPU, memory, and disk space:
 
 ### Query-frontend
 
-The [query-frontend]({{< relref "../architecture/components/query-frontend/_index.md" >}}) component resources utilization is determined by the number of queries per second.
+The [query-frontend]({{< relref "../architecture/components/query-frontend/index.md" >}}) component resources utilization is determined by the number of queries per second.
 
 Estimated required CPU and memory:
 
@@ -84,7 +84,7 @@ Estimated required CPU and memory:
 
 ### (Optional) Query-scheduler
 
-The [query-scheduler]({{< relref "../architecture/components/query-scheduler.md" >}}) component resources’ utilization is determined by the number of queries per second.
+The [query-scheduler]({{< relref "../architecture/components/query-scheduler/index.md" >}}) component resources’ utilization is determined by the number of queries per second.
 
 Estimated required CPU and memory:
 
@@ -130,7 +130,7 @@ The rules evaluation is computationally equal to queries execution, so the queri
 
 ### Compactor
 
-The [compactor]({{< relref "../architecture/components/compactor.md" >}}) component resources utilization is determined by the number of active series.
+The [compactor]({{< relref "../architecture/components/compactor/index.md" >}}) component resources utilization is determined by the number of active series.
 
 The compactor can scale horizontally both in Grafana Mimir clusters with one tenant and multiple tenants.
 We recommend to run at least one compactor instance every 20 million active series ingested in total in the Grafana Mimir cluster, calculated before ingesters replication.
@@ -141,7 +141,7 @@ Assuming you run one compactor instance every 20 million active series, the esti
 - Memory: 4GB
 - Disk: 300GB
 
-For more information about disk requirements, refer to [Compactor disk utilization]({{< relref "../architecture/components/compactor.md#compactor-disk-utilization" >}}).
+For more information about disk requirements, refer to [Compactor disk utilization]({{< relref "../architecture/components/compactor/index.md#compactor-disk-utilization" >}}).
 
 **To estimate the number of active series before ingesters replication, query the number of active series across all Prometheus servers:**