TOC Sync: Move files under Get Started. (#9717)

**Which issue(s) this PR fixes**:
Fixes #8711 

**Special notes for your reviewer**:
Part of the Database products table of contents alignment project.
Moves Getting Started and Fundamentals files under Get Started in TOC.
Updates front matter for the topic (headings, page weights,
descriptions, aliases to redirect from old URL to new URL)
Fixes links broken by the move.

docs/sources/fundamentals/_index.md

@@ -1,11 +0,0 @@
----
-title: Fundamentals
-description: Grafana Loki Fundamentals
-weight: 150
----
-# Fundamentals
-
-This section explains fundamental concepts about Grafana Loki:
-
-{{< section >}}
-

docs/sources/get-started/_index.md

@@ -1,12 +1,14 @@
 ---
-title: Getting started
-weight: 300
-description: "This guide assists the reader to create and use a simple Loki cluster for testing and evaluation purposes."
+title: Get started
+weight: 100
+description: How to create and use a simple Loki cluster for testing and evaluation purposes.
 aliases:
     - /docs/loki/latest/getting-started/get-logs-into-loki/
+    - /docs/loki/latest/getting-started/
+    - /docs/loki/latest/get-started/
 ---
 
-# Getting started
+# Get started
 
 This guide assists the reader to create and use a simple Loki cluster.
 The cluster is intended for testing, development, and evaluation;
@@ -22,7 +24,7 @@ Grafana provides a way to pose queries against the logs stored in Loki and visua
 
 The test environment uses Docker compose to instantiate these parts, each in its own container: 
 
-- One [single scalable deployment]({{< relref "../fundamentals/architecture/deployment-modes" >}}) mode **Loki** instance has:
+- One [single scalable deployment]({{< relref "../get-started/deployment-modes" >}}) mode **Loki** instance has:
     - One Loki read component
     - One Loki write component
     - **Minio** is Loki's storage back end in the test environment.

docs/sources/get-started/architecture.md

@@ -1,11 +1,14 @@
 ---
-title: Architecture
-description: Grafana Loki's Architecture
-weight: 200
+menutitle: Architecture
+title: Loki architecture
+description: Grafana Loki's architecture.
+weight: 300
 aliases:
     - /docs/loki/latest/architecture/
+    - /docs/loki/latest/fundamentals/architecture/
+    - /docs/loki/latest/get-started/architecture/
 ---
-# Architecture
+# Loki architecture
 
 ## Multi-tenancy
 
@@ -75,7 +78,7 @@ bytes of the log entry.
 
 ### Single Store
 
-Loki stores all data in a single object storage backend. This mode of operation became generally available with Loki 2.0 and is fast, cost-effective, and simple, not to mention where all current and future development lies. This mode uses an adapter called [`boltdb_shipper`]({{< relref "../../operations/storage/boltdb-shipper" >}}) to store the `index` in object storage (the same way we store `chunks`).
+Loki stores all data in a single object storage backend. This mode of operation became generally available with Loki 2.0 and is fast, cost-effective, and simple, not to mention where all current and future development lies. This mode uses an adapter called [`boltdb_shipper`]({{< relref "../operations/storage/boltdb-shipper" >}}) to store the `index` in object storage (the same way we store `chunks`).
 
 ###  Deprecated: Multi-store
 

docs/sources/get-started/components.md

@@ -1,9 +1,13 @@
 ---
-title: Components
-description: Components
-weight: 30
+menutitle: Components
+title: Loki components
+description: The components that make up Grafana Loki.
+weight: 500
+aliases:
+    - /docs/loki/latest/fundamentals/architecture/components
+    - /docs/loki/latest/get-started/components/
 ---
-# Components
+# Loki components
 
 ![components_diagram](./loki_architecture_components.svg)
 
@@ -32,7 +36,7 @@ Currently the only way the distributor mutates incoming data is by normalizing l
 
 The distributor can also rate limit incoming logs based on the maximum per-tenant bitrate. It does this by checking a per tenant limit and dividing it by the current number of distributors. This allows the rate limit to be specified per tenant at the cluster level and enables us to scale the distributors up or down and have the per-distributor limit adjust accordingly. For instance, say we have 10 distributors and tenant A has a 10MB rate limit. Each distributor will allow up to 1MB/second before limiting. Now, say another large tenant joins the cluster and we need to spin up 10 more distributors. The now 20 distributors will adjust their rate limits for tenant A to `(10MB / 20 distributors) = 500KB/s`! This is how global limits allow much simpler and safer operation of the Loki cluster.
 
-**Note: The distributor uses the `ring` component under the hood to register itself amongst its peers and get the total number of active distributors. This is a different "key" than the ingesters use in the ring and comes from the distributor's own [ring configuration]({{< relref "../../../configuration#distributor" >}}).**
+**Note: The distributor uses the `ring` component under the hood to register itself amongst its peers and get the total number of active distributors. This is a different "key" than the ingesters use in the ring and comes from the distributor's own [ring configuration]({{< relref "../configuration#distributor" >}}).**
 
 ### Forwarding
 
@@ -139,7 +143,7 @@ deduplicated.
 
 ### Timestamp Ordering
 
-Loki is configured to [accept out-of-order writes]({{< relref "../../../configuration#accept-out-of-order-writes" >}}) by default.
+Loki is configured to [accept out-of-order writes]({{< relref "../configuration#accept-out-of-order-writes" >}}) by default.
 
 When not configured to accept out-of-order writes, the ingester validates that ingested log lines are in order. When an
 ingester receives a log line that doesn't follow the expected order, the line
@@ -154,7 +158,7 @@ Logs from each unique set of labels are built up into "chunks" in memory and
 then flushed to the backing storage backend.
 
 If an ingester process crashes or exits abruptly, all the data that has not yet
-been flushed could be lost. Loki is usually configured with a [Write Ahead Log]({{< relref "../../../operations/storage/wal" >}}) which can be _replayed_ on restart as well as with a `replication_factor` (usually 3) of each log to mitigate this risk.
+been flushed could be lost. Loki is usually configured with a [Write Ahead Log]({{< relref "../operations/storage/wal" >}}) which can be _replayed_ on restart as well as with a `replication_factor` (usually 3) of each log to mitigate this risk.
 
 When not configured to accept out-of-order writes,
 all lines pushed to Loki for a given stream (unique combination of
@@ -170,7 +174,7 @@ nanosecond timestamps:
    different content, the log line is accepted. This means it is possible to
    have two different log lines for the same timestamp.
 
-### Handoff - Deprecated in favor of the [WAL]({{< relref "../../../operations/storage/wal" >}})
+### Handoff - Deprecated in favor of the [WAL]({{< relref "../operations/storage/wal" >}})
 
 By default, when an ingester is shutting down and tries to leave the hash ring,
 it will wait to see if a new ingester tries to enter before flushing and will
@@ -224,7 +228,7 @@ Caching log (filter, regexp) queries are under active development.
 
 ## Querier
 
-The **querier** service handles queries using the [LogQL]({{< relref "../../../query" >}}) query
+The **querier** service handles queries using the [LogQL]({{< relref "../query" >}}) query
 language, fetching logs both from the ingesters and from long-term storage.
 
 Queriers query all ingesters for in-memory data before falling back to

docs/sources/get-started/deployment-modes.md

@@ -1,9 +1,13 @@
 ---
-title: Deployment modes
-description: Deployment modes
-weight: 20
+menuTitle: Deployment modes
+title: Loki deployment modes
+description: Describes the different ways to deploy Loki.
+weight: 400
+aliases:
+    - /docs/loki/latest/fundamentals/architecture/deployment-modes
+    - /docs/loki/latest/get-started/deployment-modes/
 ---
-# Deployment modes
+# Loki deployment modes
 
 As an application, 
 Loki is built out of many component microservices,
@@ -36,7 +40,7 @@ as well as for small read/write volumes of up to approximately 100GB per day.
 
 Horizontally scale up a monolithic mode deployment to more instances
 by using a shared object store, and by configuring the
-[`ring` section]({{< relref "../../../configuration#common" >}})
+[`ring` section]({{< relref "../configuration#common" >}})
 to share state between all instances.
 
 High availability can be configured by running two Loki instances
@@ -59,7 +63,7 @@ Consider the microservices mode approach for very large Loki installations.
 
 In this mode the component microservices of Loki are bundled into two targets:
 `-target=read` and `-target=write`.
-The BoltDB [compactor]({{< relref "../../../operations/storage/boltdb-shipper#compactor" >}}) 
+The BoltDB [compactor]({{< relref "../operations/storage/boltdb-shipper#compactor" >}}) 
 service will run as part of the read target.
 
 There are advantages to separating the read and write paths:

docs/sources/get-started/hash-rings.md

@@ -1,9 +1,13 @@
 ---
-title: Consistent Hash Rings
-description: Consistent Hash Rings
-weight: 40
+menuTitle: Hash rings
+title: Consistent hash rings
+description: Describes how the Loki architecture uses consistent hash rings.
+weight: 700
+aliases:
+    - /docs/loki/latest/fundamentals/architecture/rings
+    - /docs/loki/latest/get-started/hash-rings/
 ---
-# Consistent Hash Rings
+# Consistent hash rings
 
 [Consistent hash rings](https://en.wikipedia.org/wiki/Consistent_hashing)
 are incorporated into Loki cluster architectures to
@@ -50,7 +54,7 @@ For each node, the key-value store holds:
 
 ## Configuring rings
 
-Define [ring configuration]({{< relref "../../../configuration#common" >}}) within the `common.ring_config` block.
+Define [ring configuration]({{< relref "../configuration#common" >}}) within the `common.ring_config` block.
 
 Use the default `memberlist` key-value store type unless there is
 a compelling reason to use a different key-value store type.

docs/sources/get-started/labels.md

@@ -1,11 +1,14 @@
 ---
-title: Labels
-description: Labels
-weight: 300
+menuTitle: Labels
+title: Understand labels
+description: Explains how to Loki uses labels to define log streams.
+weight: 600
 aliases:
     - /docs/loki/latest/getting-started/labels/
+    - /docs/loki/latest/fundamentals/labels/
+    - /docs/loki/latest/get-started/labels/
 ---
-# Labels
+# Understand labels
 
 Labels are key value pairs and can be defined as anything! We like to refer to them as metadata to describe a log stream. If you are familiar with Prometheus, there are a few labels you are used to seeing like `job` and `instance`, and I will use those in the coming examples.
 

docs/sources/get-started/overview.md

@@ -1,11 +1,14 @@
 ---
-title: Overview
-description: Overview
-weight: 100
+menuTitle: Overview
+title: Loki overview
+description: Loki product overview and features.
+weight: 200
 aliases:
     - /docs/loki/latest/overview/
+    - /docs/loki/latest/fundamentals/overview/
+    - /docs/loki/latest/get-started/overview/
 ---
-# Overview
+# Loki overview
 
 Grafana Loki is a log aggregation tool,
 and it is the core of a fully-featured logging stack.
@@ -22,7 +25,7 @@ An agent (also called a client) acquires logs,
 turns the logs into streams,
 and pushes the streams to Loki through an HTTP API.
 The Promtail agent is designed for Loki installations,
-but many other [Agents]({{< relref "../../clients" >}}) seamlessly integrate with Loki.
+but many other [Agents]({{< relref "../clients" >}}) seamlessly integrate with Loki.
 
 ![Loki agent interaction](loki-overview-2.png)
 
@@ -31,7 +34,7 @@ Each stream identifies a set of logs associated with a unique set of labels.
 A quality set of labels is key to the creation of an index that is both compact
 and allows for efficient query execution.
 
-[LogQL]({{< relref "../../query" >}}) is the query language for Loki.
+[LogQL]({{< relref "../query" >}}) is the query language for Loki.
 
 ## Loki features
 

docs/sources/installation/helm/install-monolithic/index.md

@@ -12,7 +12,7 @@ keywords:
 
 This Helm Chart installation runs the Grafana Loki *single binary* within a Kubernetes cluster.
 
-If you set the `singleBinary.replicas` value to 1, this chart configures Loki to run the `all` target in a [monolithic mode]({{< relref "../../../fundamentals/architecture/deployment-modes#monolithic-mode" >}}), designed to work with a filesystem storage. It will also configure meta-monitoring of metrics and logs.
+If you set the `singleBinary.replicas` value to 1, this chart configures Loki to run the `all` target in a [monolithic mode]({{< relref "../../../get-started/deployment-modes#monolithic-mode" >}}), designed to work with a filesystem storage. It will also configure meta-monitoring of metrics and logs.
 If you set the `singleBinary.replicas` value to 2 or more, this chart configures Loki to run a *single binary* in a replicated, highly available mode.  When running replicas of a single binary, you must configure object storage.
 
 **Before you begin: Software Requirements**

docs/sources/installation/helm/install-scalable/index.md

@@ -14,7 +14,7 @@ keywords:
 
 This Helm Chart installation runs the Grafana Loki cluster within a Kubernetes cluster.
 
-If object storge is configured, this chart configures Loki to run `read` and `write` targets in a [scalable mode]({{< relref "../../../fundamentals/architecture/deployment-modes#simple-scalable-deployment-mode" >}}), highly available architecture (3 replicas of each) designed to work with AWS S3 object storage. It will also configure meta-monitoring of metrics and logs.
+If object storge is configured, this chart configures Loki to run `read` and `write` targets in a [scalable mode]({{< relref "../../../get-started/deployment-modes#simple-scalable-deployment-mode" >}}), highly available architecture (3 replicas of each) designed to work with AWS S3 object storage. It will also configure meta-monitoring of metrics and logs.
 
 It is not possible to run the scalable mode with the `filesystem` storage.
 

docs/sources/installation/sizing/index.md

@@ -16,7 +16,7 @@ keywords: []
 
 This tool helps to generate a Helm Charts `values.yaml` file based on specified
  expected ingestion, retention rate and node type. It will always configure a
- [scalable]({{< relref "../../fundamentals/architecture/deployment-modes#simple-scalable-deployment-mode" >}}) deployment. The storage needs to be configured after generation.
+ [scalable]({{< relref "../../get-started/deployment-modes#simple-scalable-deployment-mode" >}}) deployment. The storage needs to be configured after generation.
 
 <div id="app">
   <label>Node Type<i class="fa fa-question" v-on:mouseover="help='node'" v-on:mouseleave="help=null"></i></label>

docs/sources/operations/storage/table-manager/_index.md

@@ -200,13 +200,13 @@ The Table Manager can be executed in two ways:
 
 ### Monolithic mode
 
-When Loki runs in [monolithic mode]({{< relref "../../../fundamentals/architecture/deployment-modes" >}}),
+When Loki runs in [monolithic mode]({{< relref "../../../get-started/deployment-modes" >}}),
 the Table Manager is also started as component of the entire stack.
 
 
 ### Microservices mode
 
-When Loki runs in [microservices mode]({{< relref "../../../fundamentals/architecture/deployment-modes" >}}),
+When Loki runs in [microservices mode]({{< relref "../../../get-started/deployment-modes" >}}),
 the Table Manager should be started as separate service named `table-manager`.
 
 You can check out a production grade deployment example at

docs/sources/operations/storage/tsdb.md

@@ -77,7 +77,7 @@ We've added a user per-tenant limit called `tsdb_max_query_parallelism` in the `
 
 Previously we would statically shard queries based on the index row shards configured [here]({{< relref "../../configuration#period_config" >}}).
 TSDB does Dynamic Query Sharding based on how much data a query is going to be processing.
-We additionally store size(KB) and number of lines for each chunk in the TSDB index which is then used by the [Query Frontend]({{< relref "../../fundamentals/architecture/components#query-frontend" >}}) for planning the query.
+We additionally store size(KB) and number of lines for each chunk in the TSDB index which is then used by the [Query Frontend]({{< relref "../../get-started/components#query-frontend" >}}) for planning the query.
 Based on our experience from operating many Loki clusters, we have configured TSDB to aim for processing 300-600 MBs of data per query shard.
 This means with TSDB we will be running more, smaller queries.
 

docs/sources/release-notes/v2-4.md

@@ -14,7 +14,7 @@ Loki 2.4 focuses on two items:
 ## Features and enhancements
 
 * [**Loki no longer requires logs to be sent in perfect chronological order.**]({{< relref "../configuration#accept-out-of-order-writes" >}}) Support for out of order logs is one of the most highly requested features for Loki. The strict ordering constraint has been removed.
-* Scaling Loki is now easier with a hybrid deployment mode that falls between our single binary and our microservices. The [Simple scalable deployment]({{< relref "../fundamentals/architecture/deployment-modes" >}}) scales Loki with new `read` and `write` targets. Where previously you would have needed Kubernetes and the microservices approach to start tapping into Loki’s potential, it’s now possible to do this in a simpler way.
+* Scaling Loki is now easier with a hybrid deployment mode that falls between our single binary and our microservices. The [Simple scalable deployment]({{< relref "../get-started/deployment-modes" >}}) scales Loki with new `read` and `write` targets. Where previously you would have needed Kubernetes and the microservices approach to start tapping into Loki’s potential, it’s now possible to do this in a simpler way.
 * The new [`common` section]({{< relref "../configuration#common" >}}) results in a 70% smaller Loki configuration. Pair that with updated defaults and Loki comes out of the box with more appropriate defaults and limits. Check out the [example local configuration](https://github.com/grafana/loki/blob/main/cmd/loki/loki-local-config.yaml) as the new reference for running Loki.
 * [**Recording rules**]({{< relref "../alert#recording-rules" >}}) are no longer an experimental feature. We've given them a more resilient implementation which leverages the existing write ahead log code in Prometheus.
 * The new [**Promtail Kafka Consumer**]({{< relref "../clients/promtail/scraping#kafka" >}}) can easily get your logs out of Kafka and into Loki.