Merge pull request #1729 from grafana/grafana-beyla-next-robbymilo/relref-replace-beyla

Remove relref shortcodes

Author: robbymilo

docs/sources/_index.md

@@ -73,13 +73,13 @@ While most eBPF programs require elevated privileges, Beyla allow you to specify
 
 Some Beyla functionality requires further permissions, for example using the network observability probes with Linux Traffic Control requires `CAP_NET_ADMIN`, but it's a feature you have to optionally enable.
 
-For a comprehensive list of capabilities required by Beyla, refer to [Security, permissions and capabilities]({{< relref "./security" >}}).
+For a comprehensive list of capabilities required by Beyla, refer to [Security, permissions and capabilities](security/).
 
 ## Get started
 
-- Follow the [setup]({{< relref "./setup/_index.md" >}}) documentation to get started with Beyla either with Docker or Kubernetes.
+- Follow the [setup](setup/) documentation to get started with Beyla either with Docker or Kubernetes.
 
-- Follow the [language quickstart guides]({{< relref "./quickstart" >}}) for quick instructions
+- Follow the [language quickstart guides](quickstart/) for quick instructions
   about how to set up Beyla to instrument applications written in a particular language.
 
 ## Learn more about Grafana Beyla

docs/sources/beyla-dashboard.md

@@ -37,7 +37,7 @@ The dashboard contains the following components:
 
 - A list with the slowest HTTP routes for all instrumented services. Since you only
   have a single service, only one entry appears. If you configure Beyla to
-  [report the HTTP routes]({{< relref "./configure/routes-decorator.md" >}}),
+  [report the HTTP routes](../configure/routes-decorator/),
   many entries could appear there, one for each HTTP path seen by the server.
 - A list with the slowest GRPC methods. Since the test service in this tutorial only
   serves HTTP, this table is empty.

docs/sources/cardinality.md

@@ -13,7 +13,7 @@ keywords:
 
 # Beyla metrics cardinality
 
-The cardinality of [Beyla metrics]({{< relref "./metrics.md" >}}) highly depends on the size and complexity
+The cardinality of [Beyla metrics](../metrics/) highly depends on the size and complexity
 of the instrumented environment, so there is no way to provide a simple and accurate formula.
 
 This document tries to provide an approximation of the metrics cardinality that might

docs/sources/configure/_index.md

@@ -12,10 +12,10 @@ aliases:
 
 # Configure Beyla
 
-You can configure Beyla by setting [export modes]({{< relref "./export-modes.md" >}}), global properties, and component options.
+You can configure Beyla by setting [export modes](export-modes/), global properties, and component options.
 
 {{< section menuTitle="true" withDescriptions="true">}}
 
-For information on the metrics Beyla exports, refer to the [exported metrics]({{< relref "../metrics.md" >}}) documentation.
+For information on the metrics Beyla exports, refer to the [exported metrics](../metrics/) documentation.
 
-Refer to the [routes decorator]({{< relref "./routes-decorator.md" >}}) documentation to configure the low cardinality routes decorator is very important for optimal results.
+Refer to the [routes decorator](routes-decorator/) documentation to configure the low cardinality routes decorator is very important for optimal results.

docs/sources/configure/export-data.md

@@ -37,7 +37,7 @@ Beyla uses lowercase fields for YAML configuration and uppercase names for envir
 | `features`<br>`BEYLA_OTEL_METRICS_FEATURES`                                               | The list of metric groups Beyla exports data for, refer to [metrics export features](#metrics-export-features). Accepted values `application`, `application_span`, `application_service_graph`, `application_process`, `network` and `network_inter_zone`.                                                                                                     | list of strings | `["application"]`           |
 | `allow_service_graph_self_references`<br>`BEYLA_OTEL_ALLOW_SERVICE_GRAPH_SELF_REFERENCES` | Does Beyla include self-referencing service in service graph generation, for example a service that calls itself. Self referencing isn't useful service graphs and increases data cardinality.                                                                                                                                                                 | boolean         | `false`                     |
 | `instrumentations`<br>`BEYLA_OTEL_METRICS_INSTRUMENTATIONS`                               | The list of metrics instrumentation Beyla collects data for, refer to [metrics instrumentation](#metrics-instrumentation)  section.                                                                                                                                                                                                                            | list of strings | `["*"]`                     |
-| `buckets`                                                                                 | Sets how you can override bucket boundaries of diverse histograms, refer to [override histogram buckets]({{< relref "./metrics-histograms.md" >}}).                                                                                                                                                                                                                         | (n/a)           | Object                      |
+| `buckets`                                                                                 | Sets how you can override bucket boundaries of diverse histograms, refer to [override histogram buckets](../metrics-histograms/).                                                                                                                                                                                                                         | (n/a)           | Object                      |
 | `histogram_aggregation`<br>`OTEL_EXPORTER_OTLP_METRICS_DEFAULT_HISTOGRAM_AGGREGATION`     | Sets the default aggregation Beyla uses for histogram instruments. Accepted values [`explicit_bucket_histogram`](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#explicit-bucket-histogram-aggregation) or [`base2_exponential_bucket_histogram`](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#base2-exponential-bucket-histogram-aggregation). | `string`        | `explicit_bucket_histogram` |
 
 ### Metrics export protocol
@@ -49,7 +49,7 @@ If you don't set a protocol Beyla sets the protocol as follows:
 
 ### Metrics export features
 
-The Beyla metrics exporter can export the following metrics data groups for processes matching entries in the [metrics discovery]({{< relref "./export-data.md" >}}) configuration.
+The Beyla metrics exporter can export the following metrics data groups for processes matching entries in the [metrics discovery](./) configuration.
 
 - `application`: Application-level metrics
 - `application_span` Application-level trace span metrics
@@ -194,7 +194,7 @@ The purpose of this value is to avoid reporting indefinitely finished applicatio
 | `buckets` | (n/a)                | Object |
 
 The `buckets` object allows overriding the bucket boundaries of diverse histograms. See
-[Overriding histogram buckets]({{< relref "./metrics-histograms.md" >}}) section for more details.
+[Overriding histogram buckets](../metrics-histograms/) section for more details.
 
 | YAML       | Environment variable        | Type            | Default           |
 | ---------- | --------------------------- | --------------- | ----------------- |
@@ -219,7 +219,7 @@ of Beyla: application-level metrics or network metrics.
   run the instrumented application.
 - If the list contains `network` or `network_inter_zone`, the Beyla Prometheus exporter exports network-level
   metrics; but only if the Prometheus `port` property is defined. For network-level metrics options visit the
-  [network metrics]({{< relref "../network" >}}) configuration documentation.
+  [network metrics](../../network/) configuration documentation.
 
 | YAML                                  | Environment variable                                   | Type    | Default |
 | ------------------------------------- | ------------------------------------------------------ | ------- | ------- |

docs/sources/configure/export-modes.md

@@ -36,15 +36,15 @@ The OTLP endpoint authentication credentials are provided by using the following
 - `OTEL_EXPORTER_OTLP_HEADERS`
 
 To run in Direct mode by using the Prometheus scrape endpoint, please refer to the
-[configuration documentation]({{< relref "./options.md" >}}).
+[configuration documentation](../options/).
 
 ## Alloy mode
 
 > ℹ️ This tutorial assumes that both Alloy and the auto-instrumentation tool are installed
 > as local Linux OS executables. For further examples on downloading and running the
 > auto-instrumentation tool as an OCI container, you can check the documentation sections on
-> [running the Beyla as a Docker container]({{< relref "../setup/docker.md" >}})
-> or [running Beyla in Kubernetes]({{< relref "../setup/kubernetes.md" >}}).
+> [running the Beyla as a Docker container](../../setup/docker/)
+> or [running Beyla in Kubernetes](../../setup/kubernetes/).
 
 First, locally install and configure [Grafana Alloy, according to the latest documentation](/docs/alloy/).
 Alloy facilitates the ingestion of OpenTelemetry metrics and traces from the auto-instrumentation tool,
@@ -153,7 +153,7 @@ This tutorial assumes Beyla and Alloy are running on the same host, so there is
 
 You can configure the auto-instrumentation tool both via environment variables or via
 a configuration YAML file, which is what we will use in this example.
-Please refer to the complete [Configuration documentation]({{< relref "./options.md" >}}) for
+Please refer to the complete [Configuration documentation](../options/) for
 more detailed description of each configuration option.
 
 You can download the whole [example configuration file](https://github.com/grafana/beyla/blob/main/docs/sources/configure/resources/instrumenter-config.yml),

docs/sources/configure/filter-metrics-traces.md

@@ -26,7 +26,7 @@ filter:
 ```
 
 For a list of metrics under the application and network family, as well as their
-attributes, check the [Beyla exported metrics]({{< relref "../metrics.md" >}}) document.
+attributes, check the [Beyla exported metrics](../../metrics/) document.
 
 Each `application` and `network` filter section is a map where each key is an attribute
 name (either in Prometheus or OpenTelemetry format), with either the `match` or the `not_match` property. Both properties accept a

docs/sources/configure/internal-metrics-reporter.md

@@ -42,7 +42,7 @@ Specifies the internal metrics exporter. Accepted values are `disabled`, `promet
 Specifies the HTTP port for the Prometheus scrape endpoint. If unset or 0,
 no Prometheus endpoint is open and no metrics are accounted.
 
-Its value can be the same as [`prometheus_export.port`]({{< relref "./export-data.md#prometheus-http-endpoint" >}}) (both metric families
+Its value can be the same as [`prometheus_export.port`](../export-data/#prometheus-http-endpoint) (both metric families
 share the same HTTP server, though they can be accessed in different paths),
 or a different value (two different HTTP servers for the different metric families).
 
@@ -51,7 +51,7 @@ or a different value (two different HTTP servers for the different metric famili
 | `path` | `BEYLA_INTERNAL_METRICS_PROMETHEUS_PATH` | string | `/internal/metrics` |
 
 Specifies the HTTP query path to fetch the list of Prometheus metrics.
-If [`prometheus_export.port`]({{< relref "./export-data.md#prometheus-http-endpoint" >}}) and `internal_metrics.prometheus.port` have the
+If [`prometheus_export.port`](../export-data/#prometheus-http-endpoint) and `internal_metrics.prometheus.port` have the
 same values, this `internal_metrics.prometheus.path` value can be
 different from `prometheus_export.path`, to keep both metric families separated,
 or the same (both metric families are listed in the same scrape endpoint).

docs/sources/configure/metrics-histograms.md

@@ -60,5 +60,5 @@ For Prometheus, [native histograms](https://prometheus.io/docs/concepts/metric_t
 For OpenTelemetry you can use [exponential histograms](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#exponentialhistogram)
 for the predefined histograms instead of defining the buckets manually. You need to set up the standard
 [OTEL_EXPORTER_OTLP_METRICS_DEFAULT_HISTOGRAM_AGGREGATION](https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/otlp/#additional-configuration)
-environment variable. See the `histogram_aggregation` section in the [OTEL metrics exporter]({{< relref "./export-data.md" >}}) section
+environment variable. See the `histogram_aggregation` section in the [OTEL metrics exporter](../export-data/) section
 for more information.

docs/sources/configure/metrics-traces-attributes.md

@@ -14,7 +14,7 @@ Grafana Beyla allows configuring how some attributes for metrics and traces
 are decorated. Under the `attributes` top YAML sections, you can enable
 other subsections configure how some attributes are set.
 
-The [Beyla exported metrics]({{< relref "../metrics.md" >}}) document lists the attributes
+The [Beyla exported metrics](../../metrics/) document lists the attributes
 that can be reported with each metric. Some of the attributes are reported by default while
 others are hidden to control the cardinality.
 
@@ -24,7 +24,7 @@ and each metric has two more sub-properties: `include` and `exclude`.
 
 * `include` is a list of attributes that need to be reported. Each attribute can be an attribute
   name or a wildcard (for example, `k8s.dst.*` to include all the attributes starting with `k8s.dst`).
-  If no `include` list is provided, the default attribute set is reported (check [Beyla exported metrics]({{< relref "../metrics.md" >}})
+  If no `include` list is provided, the default attribute set is reported (check [Beyla exported metrics](../../metrics/)
   for more information about the default attributes for a given metric).
 * `exclude` is a list to of attribute names/wildcards containing the attributes to remove from the
   `include` list (or the default attribute set).
@@ -83,7 +83,7 @@ Beyla to propagate any incoming context to downstream services. This context pro
 support works for any programming language and it's implemented by using Linux Traffic Control
 (TC). Because Linux Traffic Control is sometimes used by other eBPF programs, this option 
 requires that the other eBPF programs chain correctly with Beyla. For more information on 
-this topic, see our documentation related to [Cilium CNI]({{< relref "../cilium-compatibility.md" >}}).
+this topic, see our documentation related to [Cilium CNI](../../cilium-compatibility/).
 This context propagation support is fully compatible with any OpenTelemetry
 distributed tracing library.
 
@@ -99,7 +99,7 @@ following configuration must be specified:
 gRPC and HTTP2 are not supported at the moment.
 
 For an example of how to configure distributed traces in Kubernetes, see our 
-[Distributed traces with Beyla]({{< relref "../distributed-traces.md" >}}) guide.
+[Distributed traces with Beyla](../../distributed-traces/) guide.
 
 | YAML                    | Environment variable              | Type    | Default |
 | ----------------------- | --------------------------------- | ------- | ------- |
@@ -191,7 +191,7 @@ attributes:
 
 It is IMPORTANT to consider that enabling this feature requires a previous step of
 providing some extra permissions to the Beyla Pod. Consult the
-["Configuring Kubernetes metadata decoration section" in the "Running Beyla in Kubernetes"]({{< relref "../setup/kubernetes.md" >}}) page.
+["Configuring Kubernetes metadata decoration section" in the "Running Beyla in Kubernetes"](../../setup/kubernetes/) page.
 
 | YAML     | Environment variable         | Type    | Default |
 | -------- | ---------------------------- | ------- | ------- |