Fixing broken link and removing out of date blog post. (#8632)

**Which issue(s) this PR fixes**:
* Starts to address #8631
* Removes link to outdated blog post that says "Loki is very much alpha software and should not be used in production environments."
* Fixes broken link to Configuration file.

docs/sources/operations/scalability.md

@@ -5,9 +5,6 @@ weight: 30
 ---
 # Scalability
 
-See [Loki: Prometheus-inspired, open source logging for cloud natives](/blog/2018/12/12/loki-prometheus-inspired-open-source-logging-for-cloud-natives/)
-for a discussion about Grafana Loki's scalability.
-
 When scaling Loki, operators should consider running several Loki processes
 partitioned by role (ingester, distributor, querier) rather than a single Loki
 process. Grafana Labs' [production setup](https://github.com/grafana/loki/blob/master/production/ksonnet/loki)
@@ -19,7 +16,7 @@ and scaling for resource usage.
 The Query frontend has an in-memory queue that can be moved out into a separate process similar to the
 [Grafana Mimir query-scheduler](/docs/mimir/latest/operators-guide/architecture/components/query-scheduler/). This allows running multiple query frontends.
 
-To run with the Query Scheduler, the frontend needs to be passed the scheduler's address via `-frontend.scheduler-address` and the querier processes needs to be started with `-querier.scheduler-address` set to the same address. Both options can also be defined via the [configuration file]({{< relref "../configuration" >}}).
+To run with the Query Scheduler, the frontend needs to be passed the scheduler's address via `-frontend.scheduler-address` and the querier processes needs to be started with `-querier.scheduler-address` set to the same address. Both options can also be defined via the [configuration file]({{< relref "../configuration/_index.md" >}}).
 
 It is not valid to start the querier with both a configured frontend and a scheduler address.