Fix broken links and correct syntax

docs/sources/collect/ecs-opentelemetry-data.md

@@ -84,13 +84,13 @@ To create an ECS Task Definition for AWS Fargate with an ADOT collector, complet
      * Use `--config=/etc/ecs/container-insights/otel-task-metrics-config.yaml` to use StatsD, OTLP, AWS X-Ray, and Container Resource utilization metrics.
 1. Follow the ECS Fargate setup instructions to [create a task definition][task] using the template.
 
-## Run Alloy directly in your instance, or as a Kubernetes sidecar
+## Run {{% param "PRODUCT_NAME" %}} directly in your instance, or as a Kubernetes sidecar
 
 SSH or connect to the Amazon ECS or AWS Fargate-managed container. Refer to [9 steps to SSH into an AWS Fargate managed container][steps] for more information about using SSH with Amazon ECS or AWS Fargate.
 
 You can also use your own method to connect to the Amazon ECS or AWS Fargate-managed container as long as you can pass the parameters needed to install and configure {{< param "PRODUCT_NAME" >}}.
 
-### Install Grafana Alloy
+### Install {{% param "PRODUCT_NAME" %}}
 
 After connecting to your instance, follow the {{< param "PRODUCT_NAME" >}} [installation][install], [configuration][configure] and [deployment][deploy] instructions.
 

docs/sources/collect/opentelemetry-data.md

@@ -38,7 +38,7 @@ This topic describes how to:
 Before components can receive OpenTelemetry data, you must have a component responsible for exporting the OpenTelemetry data.
 An OpenTelemetry _exporter component_ is responsible for writing (exporting) OpenTelemetry data to an external system.
 
-In this task, you use the [otelcol.exporter.otlp][] component to send OpenTelemetry data to a server using the OpenTelemetry Protocol (OTLP).
+In this task, you use the [`otelcol.exporter.otlp`][otelcol.exporter.otlp] component to send OpenTelemetry data to a server using the OpenTelemetry Protocol (OTLP).
 After an exporter component is defined, you can use other {{< param "PRODUCT_NAME" >}} components to forward data to it.
 
 {{< admonition type="tip" >}}
@@ -137,7 +137,7 @@ otelcol.receiver.otlp "example" {
 }
 ```
 
-For more information on writing OpenTelemetry data using the OpenTelemetry Protocol, refer to [otelcol.exporter.otlp][].
+For more information on writing OpenTelemetry data using the OpenTelemetry Protocol, refer to [`otelcol.exporter.otlp`][otelcol.exporter.otlp].
 
 ## Configure batching
 
@@ -146,7 +146,7 @@ Instead, data is usually sent to one or more _processor components_ that perform
 
 Ensuring data is batched is a production-readiness step to improve data compression and reduce the number of outgoing network requests to external systems.
 
-In this task, you configure an [otelcol.processor.batch][] component to batch data before sending it to the exporter.
+In this task, you configure an [`otelcol.processor.batch`][otelcol.processor.batch] component to batch data before sending it to the exporter.
 
 {{< admonition type="note" >}}
 Refer to the list of available [Components][] for the full list of `otelcol.processor` components that you can use to process OpenTelemetry data.
@@ -210,14 +210,14 @@ otelcol.exporter.otlp "default" {
 }
 ```
 
-For more information on configuring OpenTelemetry data batching, refer to [otelcol.processor.batch][].
+For more information on configuring OpenTelemetry data batching, refer to [`otelcol.processor.batch`][otelcol.processor.batch].
 
 ## Configure an OpenTelemetry Protocol receiver
 
 You can configure {{< param "PRODUCT_NAME" >}} to receive OpenTelemetry metrics, logs, and traces.
 An OpenTelemetry _receiver_ component is responsible for receiving OpenTelemetry data from an external system.
 
-In this task, you use the [otelcol.receiver.otlp][] component to receive OpenTelemetry data over the network using the OpenTelemetry Protocol (OTLP).
+In this task, you use the [`otelcol.receiver.otlp`][otelcol.receiver.otlp] component to receive OpenTelemetry data over the network using the OpenTelemetry Protocol (OTLP).
 You can configure a receiver component to forward received data to other {{< param "PRODUCT_NAME" >}} components.
 
 > Refer to the list of available [Components][] for the full list of
@@ -312,7 +312,7 @@ otelcol.exporter.otlp "default" {
 }
 ```
 
-For more information on receiving OpenTelemetry data using the OpenTelemetry Protocol, refer to [otelcol.receiver.otlp][].
+For more information on receiving OpenTelemetry data using the OpenTelemetry Protocol, refer to [`otelcol.receiver.otlp`][otelcol.receiver.otlp].
 
 [OpenTelemetry]: https://opentelemetry.io
 [Configure an OpenTelemetry Protocol exporter]: #configure-an-opentelemetry-protocol-exporter

docs/sources/configure/kubernetes.md

@@ -28,12 +28,12 @@ To modify {{< param "PRODUCT_NAME" >}}'s Helm chart configuration, perform the f
 1. Create a local `values.yaml` file with a Helm chart configuration.
 
    1. You can use your own copy of the values file or download a copy of the
-      default [values.yaml][].
+      default [`values.yaml`][values.yaml].
 
    1. Make changes to your `values.yaml` to customize settings for the
       Helm chart.
 
-      Refer to the inline documentation in the default [values.yaml][] for more
+      Refer to the inline documentation in the default [`values.yaml`][values.yaml] for more
       information about each option.
 
 1. Run the following command in a terminal to upgrade your {{< param "PRODUCT_NAME" >}} installation:

docs/sources/configure/nonroot.md

@@ -24,7 +24,7 @@ You can configure a non-root user when you deploy {{< param "PRODUCT_NAME" >}} i
 {{< admonition type="note" >}}
 Running {{< param "PRODUCT_NAME" >}} as a non-root user won't work if you are using components like [beyla.ebpf][] that require root rights.
 
-[beyla.ebpf]: ../../reference/components/beyla/beyla.ebpf
+[beyla.ebpf]: ../../reference/components/beyla/beyla.ebpf/
 {{< /admonition >}}
 
 To run {{< param "PRODUCT_NAME" >}} as a non-root user, configure a [security context][] for the {{< param "PRODUCT_NAME" >}} container. If you are using the [Grafana Helm chart][] you can add the following snippet to `values.yaml`:
@@ -45,6 +45,6 @@ Not really. The Linux kernel prevents Docker containers from accessing host reso
 However, if there was a bug in the Linux kernel that allowed Docker containers to break out of the virtual environment, it would likely be easier to exploit this bug with a root user than with a non-root user. It's worth noting that the attacker would not only need to find such a Linux kernel bug, but would also need to find a way to make {{< param "PRODUCT_NAME" >}} exploit that bug.
 
 [image]: https://hub.docker.com/r/grafana/alloy
-[beyla.ebpf]: ../../reference/components/beyla/beyla.ebpf
+[beyla.ebpf]: ../../reference/components/beyla/beyla.ebpf/
 [security context]: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
 [Grafana Helm chart]: ../../configure/kubernetes/#configure-the-helm-chart

docs/sources/configure/windows.md

@@ -116,4 +116,4 @@ To expose the UI to other machines, complete the following steps:
      To listen on all interfaces, replace _`<LISTEN_ADDR>`_ with `0.0.0.0`.
 
 [UI]: ../../troubleshoot/debug/#alloy-ui
-[environment]: ../../reference/cli/environment-variables
+[environment]: ../../reference/cli/environment-variables/

docs/sources/data-collection.md

@@ -31,5 +31,5 @@ All newly reported data is documented in the CHANGELOG.
 
 You can use the `--disable-reporting` [command line flag][] to disable the reporting and opt-out of the data collection.
 
-[components]: ../get-started/components
-[command line flag]: ../reference/cli/run
+[components]: ../get-started/components/
+[command line flag]: ../reference/cli/run/

docs/sources/get-started/clustering.md

@@ -58,12 +58,12 @@ Refer to component reference documentation to discover whether it supports clust
 ## Cluster monitoring and troubleshooting
 
 You can use the {{< param "PRODUCT_NAME" >}} UI [clustering page][] to monitor your cluster status.
-Refer to [Debugging clustering issues][debugging] for additional troubleshooting information.
+Refer to [Debug clustering issues][debugging] for additional troubleshooting information.
 
 [run]: ../../reference/cli/run/#clustering
 [prometheus.scrape]: ../../reference/components/prometheus/prometheus.scrape/#clustering-block
 [pyroscope.scrape]: ../../reference/components/pyroscope/pyroscope.scrape/#clustering-block
 [prometheus.operator.podmonitors]: ../../reference/components/prometheus/prometheus.operator.podmonitors/#clustering-block
 [prometheus.operator.servicemonitors]: ../../reference/components/prometheus/prometheus.operator.servicemonitors/#clustering-block
 [clustering page]: ../../troubleshoot/debug/#clustering-page
-[debugging]: ../../troubleshoot/debug/#debugging-clustering-issues
+[debugging]: ../../troubleshoot/debug/#debug-clustering-issues

docs/sources/get-started/modules.md

@@ -19,10 +19,10 @@ Modules can be [imported](#import-modules) to enable the reuse of [custom compon
 A module can be _imported_, allowing the custom components defined by that module to be used by other modules, called the _importing module_.
 Modules can be imported from multiple locations using one of the `import` configuration blocks:
 
-* [import.file][]: Imports a module from a file on disk.
-* [import.git][]: Imports a module from a file located in a Git repository.
-* [import.http][]: Imports a module from the response of an HTTP request.
-* [import.string][]: Imports a module from a string.
+* [`import.file`][import.file]: Imports a module from a file on disk.
+* [`import.git`][import.git]: Imports a module from a file located in a Git repository.
+* [`import.http`][import.http]: Imports a module from the response of an HTTP request.
+* [`import.string`][import.string]: Imports a module from a string.
 
 {{< admonition type="warning" >}}
 You can't import a module that contains top-level blocks other than `declare` or `import`.

docs/sources/reference/cli/convert.md

@@ -16,8 +16,6 @@ The `convert` command converts a supported configuration format to the {{< param
 
 ## Usage
 
-Usage:
-
 ```shell
 alloy convert [<FLAG> ...] <FILE_NAME>
 ```
@@ -111,7 +109,7 @@ Refer to [Migrate from Grafana Agent Static to {{< param "PRODUCT_NAME" >}}][mig
 [relabel_config]: https://prometheus.io/docs/prometheus/2.45/configuration/configuration/#relabel_config
 [metric_relabel_configs]: https://prometheus.io/docs/prometheus/2.45/configuration/configuration/#metric_relabel_configs
 [remote_write]: https://prometheus.io/docs/prometheus/2.45/configuration/configuration/#remote_write
-[Component Reference]: ../components/otelcol/
+[Component Reference]: ../../components/otelcol/
 [migrate otelcol]: ../../../set-up/migrate/from-otelcol/
 [migrate prometheus]: ../../../set-up/migrate/from-prometheus/
 [Promtail v2.8.x]: https://grafana.com/docs/loki/v2.8.x/clients/promtail/

docs/sources/reference/cli/fmt.md

@@ -12,8 +12,6 @@ The `fmt` command formats a given {{< param "PRODUCT_NAME" >}} configuration fil
 
 ## Usage
 
-Usage:
-
 ```shell
 alloy fmt [<FLAG> ...] <FILE_NAME>
 ```

docs/sources/reference/cli/run.md

@@ -12,8 +12,6 @@ The `run` command runs {{< param "PRODUCT_NAME" >}} in the foreground until an i
 
 ## Usage
 
-Usage:
-
 ```shell
 alloy run [<FLAG> ...] <PATH_NAME>
 ```
@@ -177,6 +175,6 @@ Refer to [alloy convert][] for more details on how `extra-args` work.
 [go-discover]: https://github.com/hashicorp/go-discover
 [in-memory HTTP traffic]: ../../../get-started/component_controller/#in-memory-traffic
 [data collection]: ../../../data-collection/
-[support bundle]: ../../../troubleshoot/support_bundle
+[support bundle]: ../../../troubleshoot/support_bundle/
 [component controller]: ../../../get-started/component_controller/
 [UI]: ../../../troubleshoot/debug/#clustering-page

docs/sources/reference/cli/tools.md

@@ -18,8 +18,6 @@ Utilities in this command have no backward compatibility guarantees and may chan
 
 ### prometheus.remote_write sample-stats
 
-Usage:
-
 ```shell
 alloy tools prometheus.remote_write sample-stats [<FLAG> ...] <WAL_DIRECTORY>
 ```
@@ -46,8 +44,6 @@ The following flag is supported:
 
 ### prometheus.remote_write target-stats
 
-Usage:
-
 ```shell
 alloy tools prometheus.remote_write target-stats --job JOB --instance INSTANCE WAL_DIRECTORY
 ```
@@ -65,8 +61,6 @@ The `--job` and `--instance` labels are required.
 
 ### prometheus.remote_write wal-stats
 
-Usage:
-
 ```shell
 alloy tools prometheus.remote_write wal-stats <WAL_DIRECTORY>
 ```

docs/sources/reference/config-blocks/declare.md

@@ -71,5 +71,5 @@ prometheus.remote_write "example" {
 [argument]: ../argument/
 [export]: ../export/
 [declare]: ../declare/
-[import]: ../../../get-started/modules/#importing-modules
+[import]: ../../../get-started/modules/#import-modules
 [custom component]: ../../../get-started/custom_components/

docs/sources/set-up/migrate/from-otelcol.md

@@ -19,9 +19,9 @@ This topic describes how to:
 
 ## Components used in this topic
 
-* [otelcol.receiver.otlp][]
-* [otelcol.processor.memory_limiter][]
-* [otelcol.exporter.otlp][]
+* [`otelcol.receiver.otlp`][otelcol.receiver.otlp]
+* [`otelcol.processor.memory_limiter`][otelcol.processor.memory_limiter]
+* [`otelcol.exporter.otlp`][otelcol.exporter.otlp]
 
 ## Before you begin
 
@@ -47,7 +47,7 @@ In this task, you use the [convert][] CLI command to output a {{< param "PRODUCT
    * _`<INPUT_CONFIG_PATH>`_: The full path to the OpenTelemetry Collector configuration.
    * _`<OUTPUT_CONFIG_PATH>`_: The full path to output the {{< param "PRODUCT_NAME" >}} configuration.
 
-1. [Run][] {{< param "PRODUCT_NAME" >}} using the new {{< param "PRODUCT_NAME" >}} configuration from _`<OUTPUT_CONFIG_PATH>`_:
+1. [Run][run_cli] {{< param "PRODUCT_NAME" >}} using the new {{< param "PRODUCT_NAME" >}} configuration from _`<OUTPUT_CONFIG_PATH>`_:
 
 ### Debugging
 
@@ -98,7 +98,7 @@ This allows you to try {{< param "PRODUCT_NAME" >}} without modifying your OpenT
 
 In this task, you use the [run][run_cli] CLI command to run {{< param "PRODUCT_NAME" >}} using an OpenTelemetry Collector configuration.
 
-[Run][] {{< param "PRODUCT_NAME" >}} and include the command line flag `--config.format=otelcol`.
+[Run][run_cli] {{< param "PRODUCT_NAME" >}} and include the command line flag `--config.format=otelcol`.
 Your configuration file must be a valid OpenTelemetry Collector configuration file rather than a {{< param "PRODUCT_NAME" >}} configuration file.
 
 ### Debug
@@ -225,6 +225,5 @@ The following list is specific to the convert command and not {{< param "PRODUCT
 [Component Reference]: ../../../reference/components/
 [convert]: ../../../reference/cli/convert/
 [run_cli]: ../../../reference/cli/run/
-[Run]: ../../../get-started/run/
 [DebuggingUI]: ../../../troubleshoot/debug/
 [UI]: ../../../troubleshoot/debug/#alloy-ui

docs/sources/set-up/migrate/from-prometheus.md

@@ -96,7 +96,7 @@ This allows you to try {{< param "PRODUCT_NAME" >}} without modifying your Prome
 
 In this task, you use the [run][] CLI command to run {{< param "PRODUCT_NAME" >}} using a Prometheus configuration.
 
-[Run][run alloy] {{< param "PRODUCT_NAME" >}} and include the command line flag `--config.format=prometheus`.
+[Run][run] {{< param "PRODUCT_NAME" >}} and include the command line flag `--config.format=prometheus`.
 Your configuration file must be a valid Prometheus configuration file rather than an {{< param "PRODUCT_NAME" >}} configuration file.
 
 ### Debug
@@ -206,7 +206,6 @@ The following list is specific to the convert command and not {{< param "PRODUCT
 [Components]: ../../../get-started/components/
 [convert]: ../../../reference/cli/convert/
 [run]: ../../../reference/cli/run/
-[run alloy]: ../../../set-up/run/
 [DebuggingUI]: ../../../troubleshoot/debug/
 [configuration]: ../../../get-started/configuration-syntax/
 [UI]: ../../../troubleshoot/debug/#alloy-ui

docs/sources/set-up/migrate/from-promtail.md

@@ -46,7 +46,7 @@ This conversion allows you to take full advantage of the many additional feature
     * _`<INPUT_CONFIG_PATH>`_: The full path to the Promtail configuration.
     * _`<OUTPUT_CONFIG_PATH>`_: The full path to output the {{< param "PRODUCT_NAME" >}} configuration.
 
-1. [Run][run alloy] {{< param "PRODUCT_NAME" >}} using the new configuration from _`<OUTPUT_CONFIG_PATH>`_:
+1. [Run][run] {{< param "PRODUCT_NAME" >}} using the new configuration from _`<OUTPUT_CONFIG_PATH>`_:
 
 ### Debugging
 
@@ -93,7 +93,7 @@ This allows you to try {{< param "PRODUCT_NAME" >}} without modifying your Promt
 
 > In this task, you use the [run][] CLI command to run {{< param "PRODUCT_NAME" >}} using a Promtail configuration.
 
-[Run][run alloy] {{< param "PRODUCT_NAME" >}} and include the command line flag `--config.format=promtail`.
+[Run][run] {{< param "PRODUCT_NAME" >}} and include the command line flag `--config.format=promtail`.
 Your configuration file must be a valid Promtail configuration file rather than an {{< param "PRODUCT_NAME" >}} configuration file.
 
 ### Debug
@@ -189,7 +189,6 @@ The following list is specific to the convert command and not {{< param "PRODUCT
 [Components]: ../../../get-started/components/
 [convert]: ../../../reference/cli/convert/
 [run]: ../../../reference/cli/run/
-[run alloy]: ../../../set-up/run/
 [DebuggingUI]: ../../../troubleshoot/debug/
 [configuration]: ../../../get-started/configuration-syntax/
 [UI]: ../../../troubleshoot/debug/#alloy-ui