From d428aa57609bd8734e6e8210254dce15c6677658 Mon Sep 17 00:00:00 2001
From: Clayton Cornell <clayton.cornell@grafana.com>
Date: Thu, 4 Apr 2024 17:10:28 -0700
Subject: [PATCH 1/4] Clean up beyla topic

---
 .../reference/components/beyla.ebpf.md        | 110 ++++++++----------
 1 file changed, 50 insertions(+), 60 deletions(-)

diff --git a/docs/sources/reference/components/beyla.ebpf.md b/docs/sources/reference/components/beyla.ebpf.md
index 1ed7c87e19..958d66f7d2 100644
--- a/docs/sources/reference/components/beyla.ebpf.md
+++ b/docs/sources/reference/components/beyla.ebpf.md
@@ -15,12 +15,10 @@ You can configure the component to collect telemetry data from a specific port o
 The component exposes metrics that can be collected by a Prometheus scrape component, and traces that can be forwarded to an OTEL exporter component.
 
 {{< admonition type="note" >}}
-To run this component, {{< param "PRODUCT_NAME" >}} requires administrative (`sudo`) privileges, or at least it needs to be granted the `CAP_SYS_ADMIN` and `CAP_SYS_PTRACE` capability. In Kubernetes environments, app armour must be disabled for the Deployment or DaemonSet running {{< param "PRODUCT_NAME" >}}.
+To run this component, {{< param "PRODUCT_NAME" >}} requires administrative (`sudo`) privileges, or at least it needs to be granted the `CAP_SYS_ADMIN` and `CAP_SYS_PTRACE` capability.
+In Kubernetes environments, app armour must be disabled for the Deployment or DaemonSet running {{< param "PRODUCT_NAME" >}}.
 {{< /admonition >}}
 
-[Grafana Beyla]: https://github.com/grafana/beyla
-[eBPF]: https://ebpf.io/
-
 ## Usage
 
 ```alloy
@@ -33,11 +31,10 @@ beyla.ebpf "<LABEL>" {
 
 `beyla.ebpf` supports the following arguments:
 
-Name | Type | Description                                               | Default | Required
----- | ---- |-----------------------------------------------------------| ------- | --------
-`open_port` | `string` | The port of the running service for Beyla automatically instrumented with eBPF. | | no
-`excutable_name` | `string` | The name of the executable to match for Beyla automatically instrumented with eBPF. | | no
-
+Name             | Type     | Description                                                                         | Default | Required
+-----------------|----------|-------------------------------------------------------------------------------------|---------|---------
+`open_port`      | `string` | The port of the running service for Beyla automatically instrumented with eBPF.     |         | no
+`excutable_name` | `string` | The name of the executable to match for Beyla automatically instrumented with eBPF. |         | no
 
 `open_port` accepts a comma-separated list of ports (for example, `80,443`), and port ranges (for example, `8000-8999`).
 If the executable matches only one of the ports in the list, it is considered to match the selection criteria.
@@ -48,37 +45,28 @@ If the executable matches only one of the ports in the list, it is considered to
 
 The following blocks are supported inside the definition of `beyla.ebpf`:
 
-Hierarchy | Block | Description | Required
---------- | ----- | ----------- | --------
-routes | [routes][] | Configures the routes to match HTTP paths into user-provided HTTP routes. | no
-attributes | [attributes][] | Configures the Beyla attributes for the component. | no
+Hierarchy               | Block          | Description                                                                                        | Required
+------------------------|----------------|----------------------------------------------------------------------------------------------------|---------
+routes                  | [routes][]     | Configures the routes to match HTTP paths into user-provided HTTP routes.                          | no
+attributes              | [attributes][] | Configures the Beyla attributes for the component.                                                 | no
 attributes > kubernetes | [kubernetes][] | Configures decorating of the metrics and traces with Kubernetes metadata of the instrumented Pods. | no
-discovery | [discovery][] | Configures the discovery for instrumentable processes matching a given criteria. | no
-discovery > services | [services][] | Configures the discovery for the component. | no
-output | [output][] | Configures where to send received telemetry data. | yes
-
-The `>` symbol indicates deeper levels of nesting. For example,
-`attributes > kubernetes` refers to a `kubernetes` block defined inside an
-`attributes` block.
+discovery               | [discovery][]  | Configures the discovery for instrumentable processes matching a given criteria.                   | no
+discovery > services    | [services][]   | Configures the discovery for the component.                                                        | no
+output                  | [output][]     | Configures where to send received telemetry data.                                                  | yes
 
-[routes]: #routes-block
-[attributes]: #attributes-block
-[kubernetes]: #kubernetes-block
-[discovery]: #discovery-block
-[services]: #services-block
-[output]: #output-block
+The `>` symbol indicates deeper levels of nesting.
+For example,`attributes > kubernetes` refers to a `kubernetes` block defined inside an `attributes` block.
 
 ### attributes block
 
 This block allows you to configure how some attributes for metrics and traces are decorated.
 
 It contains the following blocks:
-[kubernetes]: #kubernetes-block
 
 #### kubernetes block
 
-Name | Type | Description                                               | Default | Required
----- | ---- |-----------------------------------------------------------| ------- | --------
+Name     | Type     | Description                                | Default | Required
+---------|----------|--------------------------------------------|---------|---------
 `enable` | `string` | Enable the Kubernetes metadata decoration. | `false` | no
 
 If set to `true`, Beyla will decorate the metrics and traces with Kubernetes metadata. The following labels will be added:
@@ -95,19 +83,18 @@ If set to `true`, Beyla will decorate the metrics and traces with Kubernetes met
 
 If set to `false`, the Kubernetes metadata decorator will be disabled.
 
-If set to `autodetect`, Beyla will try to automatically detect if it is running inside Kubernetes, and enable the metadata decoration if that is the case.
-
+If set to `autodetect`, Beyla will try to automatically detect if it is running inside Kubernetes, and enable the metadata decoration if that's the case.
 
 ### routes block
 
 This block is used to configure the routes to match HTTP paths into user-provided HTTP routes.
 
-Name | Type | Description                                               | Default | Required
----- | ---- |-----------------------------------------------------------| ------- | --------
-`patterns` | `list(string)` | List of provided URL path patterns to set the `http.route` trace/metric property | | no
-`ignore_patterns` | `list(string)` | List of provided URL path patterns to ignore from `http.route` trace/metric property. | | no
-`ignore_mode` | `string` | The mode to use when ignoring patterns. | | no
-`unmatched` | `string` | Specifies what to do when a trace HTTP path does not match any of the `patterns` entries | | no
+Name              | Type           | Description                                                                               | Default | Required
+------------------|----------------|-------------------------------------------------------------------------------------------|---------|---------
+`patterns`        | `list(string)` | List of provided URL path patterns to set the `http.route` trace/metric property          |         | no
+`ignore_patterns` | `list(string)` | List of provided URL path patterns to ignore from `http.route` trace/metric property.     |         | no
+`ignore_mode`     | `string`       | The mode to use when ignoring patterns.                                                   |         | no
+`unmatched`       | `string`       | Specifies what to do when a trace HTTP path does not match any of the `patterns` entries. |         | no
 
 `patterns` and `ignored_patterns` are a list of patterns which a URL path with specific tags which allow for grouping path segments (or ignored them).
 The matcher tags can be in the `:name` or `{name}` format.
@@ -124,31 +111,30 @@ The matcher tags can be in the `:name` or `{name}` format.
   - Any path components that have numbers or characters outside of the ASCII alphabet (or `-` and _), are replaced by an asterisk `*`.
   - Any alphabetical components that don’t look like words are replaced by an asterisk `*`.
 
-
 ### discovery block
 
 This block is used to configure the discovery for instrumentable processes matching a given criteria.
 
 It contains the following blocks:
-[services]: #services-block
 
 ### services block
 
 In some scenarios, Beyla will instrument a wide variety of services, such as a Kubernetes DaemonSet that instruments all the services in a node.
 This block allows you to filter the services to instrument based on their metadata.
 
-Name | Type | Description                                               | Default | Required
----- | ---- |-----------------------------------------------------------| ------- | --------
-`name ` | `string` | The name of the service to match. | | no
-`namespace` | `string` | The namespace of the service to match. | | no
-`open_ports` | `string` | The port of the running service for Beyla automatically instrumented with eBPF. | | no
-`path` | `string` | The path of the running service for Beyla automatically instrumented with eBPF. | | no
+Name         | Type     | Description                                                                     | Default | Required
+-------------|----------|---------------------------------------------------------------------------------|---------|---------
+`name `      | `string` | The name of the service to match.                                               |         | no
+`namespace`  | `string` | The namespace of the service to match.                                          |         | no
+`open_ports` | `string` | The port of the running service for Beyla automatically instrumented with eBPF. |         | no
+`path`       | `string` | The path of the running service for Beyla automatically instrumented with eBPF. |         | no
 
-`name` defines a name for the matching instrumented service. It is used to populate the `service.name` OTEL property and/or the `service_name` Prometheus property in the exported metrics/traces.
-`open_port` accepts a comma-separated list of ports (for example, `80,443`), and port ranges (for example, `8000-8999`). If the executable matches only one of the ports in the list, it is considered to match the selection criteria.
+`name` defines a name for the matching instrumented service.
+It is used to populate the `service.name` OTEL property and/or the `service_name` Prometheus property in the exported metrics/traces.
+`open_port` accepts a comma-separated list of ports (for example, `80,443`), and port ranges (for example, `8000-8999`).
+If the executable matches only one of the ports in the list, it is considered to match the selection criteria.
 `path` accepts a regular expression to be matched against the full executable command line, including the directory where the executable resides on the file system.
 
-
 ### output block
 
 The `output` block configures a set of components to forward the resulting telemetry data to.
@@ -168,32 +154,26 @@ Configure the `traces` argument to send traces data to other components.
 The following fields are exported and can be referenced by other components.
 
 Name      | Type                | Description
-----------|---------------------|----------------------------------------------------------
+----------|---------------------|------------------------------------------------------------------------------------
 `targets` | `list(map(string))` | The targets that can be used to collect metrics of instrumented services with eBPF.
 
 For example, the `targets` can either be passed to a `discovery.relabel` component to rewrite the targets' label sets or to a `prometheus.scrape` component that collects the exposed metrics.
 
 The exported targets use the configured [in-memory traffic][] address specified by the [run command][].
 
-[in-memory traffic]: ../../../concepts/component_controller#in-memory-traffic
-[run command]: ../../cli/run/
-
 ## Component health
 
-`beyla.ebpf` is only reported as unhealthy if given an invalid
-configuration.
+`beyla.ebpf` is only reported as unhealthy if given an invalid configuration.
 
 ## Debug information
 
-`beyla.ebpf` does not expose any component-specific debug
-information.
+`beyla.ebpf` does not expose any component-specific debug information.
 
 ## Example
 
 ### Metrics
 
-This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `beyla.ebpf` of
-the specified port:
+This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `beyla.ebpf` of the specified port:
 
 ```alloy
 beyla.ebpf "default" {
@@ -224,8 +204,6 @@ Replace the following:
 - _`<USERNAME>`_: The username to use for authentication to the remote_write API.
 - _`<PASSWORD>`_: The password to use for authentication to the remote_write API.
 
-[scrape]: ../prometheus.scrape/
-
 ### Traces
 
 This example gets traces from `beyla.ebpf` and forwards them to `otlp`:
@@ -256,6 +234,18 @@ Replace the following:
 - _`<OPEN_PORT>`_: The port of the running service for Beyla automatically instrumented with eBPF.
 - _`<OTLP_ENDPOINT>`_: The endpoint of the OpenTelemetry Collector to send traces to.
 
+[Grafana Beyla]: https://github.com/grafana/beyla
+[eBPF]: https://ebpf.io/
+[routes]: #routes-block
+[attributes]: #attributes-block
+[kubernetes]: #kubernetes-block
+[discovery]: #discovery-block
+[services]: #services-block
+[output]: #output-block
+[in-memory traffic]: ../../../concepts/component_controller#in-memory-traffic
+[run command]: ../../cli/run/
+[scrape]: ../prometheus.scrape/
+
 <!-- START GENERATED COMPATIBLE COMPONENTS -->
 
 ## Compatible components

From 89a22f0b51fb06404720bad265ed038fe964c502 Mon Sep 17 00:00:00 2001
From: Clayton Cornell <clayton.cornell@grafana.com>
Date: Thu, 4 Apr 2024 17:42:50 -0700
Subject: [PATCH 2/4] General syntax cleanup

---
 .../reference/components/pyroscope.scrape.md  | 278 ++++++++----------
 .../reference/components/pyroscope.write.md   |  56 ++--
 .../reference/components/remote.http.md       |  47 ++-
 .../components/remote.kubernetes.configmap.md |  49 ++-
 .../components/remote.kubernetes.secret.md    |  53 ++--
 .../sources/reference/components/remote.s3.md |  35 +--
 .../reference/components/remote.vault.md      | 211 ++++++-------
 docs/sources/tasks/estimate-resource-usage.md |   2 +-
 docs/sources/tasks/metamonitoring.md          |   2 +-
 9 files changed, 327 insertions(+), 406 deletions(-)

diff --git a/docs/sources/reference/components/pyroscope.scrape.md b/docs/sources/reference/components/pyroscope.scrape.md
index 0a9421c9bd..3365306139 100644
--- a/docs/sources/reference/components/pyroscope.scrape.md
+++ b/docs/sources/reference/components/pyroscope.scrape.md
@@ -10,30 +10,25 @@ title: pyroscope.scrape
 
 {{< docs/shared lookup="stability/public_preview.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-`pyroscope.scrape` collects [pprof] performance profiles for a given set of HTTP `targets`. 
+`pyroscope.scrape` collects [pprof] performance profiles for a given set of HTTP `targets`.
 
 `pyroscope.scrape` mimcks the scraping behavior of `prometheus.scrape`.
 Similarly to how Prometheus scrapes metrics via HTTP, `pyroscope.scrape` collects profiles via HTTP requests.
 
-Unlike Prometheus, which usually only scrapes one `/metrics` endpoint per target, 
-`pyroscope.scrape` may need to scrape multiple endpoints for the same target.
-This is because different types of profiles are scraped on different endpoints. 
-For example, "mutex" profiles may be scraped on a `/debug/pprof/delta_mutex` HTTP endpoint, whereas 
-memory consumption may be scraped on a `/debug/pprof/allocs` HTTP endpoint.
+Unlike Prometheus, which usually only scrapes one `/metrics` endpoint per target, `pyroscope.scrape` may need to scrape multiple endpoints for the same target.
+This is because different types of profiles are scraped on different endpoints.
+For example, "mutex" profiles may be scraped on a `/debug/pprof/delta_mutex` HTTP endpoint, whereas memory consumption may be scraped on a `/debug/pprof/allocs` HTTP endpoint.
 
-The profile paths, protocol scheme, scrape interval, scrape timeout,
-query parameters, as well as any other settings can be configured within `pyroscope.scrape`.
+The profile paths, protocol scheme, scrape interval, scrape timeout, query parameters, as well as any other settings can be configured within `pyroscope.scrape`.
 
-The `pyroscope.scrape` component regards a scrape as successful if it
-responded with an HTTP `200 OK` status code and returned the body of a valid [pprof] profile.
+The `pyroscope.scrape` component regards a scrape as successful if it responded with an HTTP `200 OK` status code and returned the body of a valid [pprof] profile.
 
 If a scrape request fails, the [debug UI][] for `pyroscope.scrape` will show:
 * Detailed information about the failure.
 * The time of the last successful scrape.
 * The labels last used for scraping.
 
-The scraped performance profiles can be forwarded to components such as 
-`pyroscope.write` via the `forward_to` argument.
+The scraped performance profiles can be forwarded to components such as `pyroscope.write` via the `forward_to` argument.
 
 Multiple `pyroscope.scrape` components can be specified by giving them different labels.
 
@@ -50,16 +45,15 @@ pyroscope.scrape "LABEL" {
 
 ## Arguments
 
-`pyroscope.scrape` starts a new scrape job to scrape all of the input targets. 
+`pyroscope.scrape` starts a new scrape job to scrape all of the input targets.
 Multiple scrape jobs can be started for a single input target
 when scraping multiple profile types.
 
 The list of arguments that can be used to configure the block is
 presented below.
 
-Any omitted arguments take on their default values. If conflicting
-arguments are being passed (for example, configuring both `bearer_token` 
-and `bearer_token_file`), then `pyroscope.scrape` will fail to start and will report an error.
+Any omitted arguments take on their default values.
+If conflicting arguments are being passed (for example, configuring both `bearer_token` and `bearer_token_file`), then `pyroscope.scrape` will fail to start and will report an error.
 
 The following arguments are supported:
 
@@ -70,7 +64,7 @@ Name                | Type                     | Description
 `job_name`          | `string`                 | The job name to override the job label with.                       | component name | no
 `params`            | `map(list(string))`      | A set of query parameters with which the target is scraped.        |                | no
 `scrape_interval`   | `duration`               | How frequently to scrape the targets of this scrape configuration. | `"15s"`        | no
-`scrape_timeout`    | `duration`               | The timeout for scraping targets of this configuration. Must be larger than `scrape_interval`. | `"18s"`        | no
+`scrape_timeout`    | `duration`               | The timeout for scraping targets of this configuration. Must be larger than `scrape_interval`. | `"18s"` | no
 `scheme`            | `string`                 | The URL scheme with which to fetch metrics from targets.           | `"http"`       | no
 `bearer_token_file` | `string`                 | File containing a bearer token to authenticate with.               |                | no
 `bearer_token`      | `secret`                 | Bearer token to authenticate with.                                 |                | no
@@ -100,17 +94,16 @@ For example, the `job_name` of `pyroscope.scrape "local" { ... }` will be `"pyro
 
 #### `targets` argument
 
-The list of `targets` can be provided [statically][example_static_targets], [dynamically][example_dynamic_targets], 
-or a [combination of both][example_static_and_dynamic_targets].
+The list of `targets` can be provided [statically][example_static_targets], [dynamically][example_dynamic_targets], or a [combination of both][example_static_and_dynamic_targets].
 
 The special `__address__` label _must always_ be present and corresponds to the
 `<host>:<port>` that is used for the scrape request.
 
 Labels starting with a double underscore (`__`) are treated as _internal_, and are removed prior to scraping.
 
-The special label `service_name` is required and must always be present. 
-If it is not specified, `pyroscope.scrape` will attempt to infer it from 
-either of the following sources, in this order: 
+The special label `service_name` is required and must always be present.
+If it's not specified, `pyroscope.scrape` will attempt to infer it from either of the following sources, in this order:
+
 1. `__meta_kubernetes_pod_annotation_pyroscope_io_service_name` which is a `pyroscope.io/service_name` pod annotation.
 2. `__meta_kubernetes_namespace` and `__meta_kubernetes_pod_container_name`
 3. `__meta_docker_container_name`
@@ -118,19 +111,18 @@ either of the following sources, in this order:
 
 If `service_name` is not specified and could not be inferred, then it is set to `unspecified`.
 
-The following labels are automatically injected to the scraped profiles 
-so that they can be linked to a scrape target:
+The following labels are automatically injected to the scraped profiles so that they can be linked to a scrape target:
 
-| Label            | Description                                                      |
-|------------------|----------------------------------------------------------------- |
-| `"job"`          | The `job_name` that the target belongs to.                       |
-| `"instance"`     | The `__address__` or `<host>:<port>` of the scrape target's URL. |
-| `"service_name"` | The inferred Pyroscope service name.                             |
+Label            | Description
+-----------------|-----------------------------------------------------------------
+`"job"`          | The `job_name` that the target belongs to.
+`"instance"`     | The `__address__` or `<host>:<port>` of the scrape target's URL.
+`"service_name"` | The inferred Pyroscope service name.
 
 #### `scrape_interval` argument
 
-The `scrape_interval` typically refers to the frequency with which {{< param "PRODUCT_NAME" >}} collects performance profiles from the monitored targets. 
-It represents the time interval between consecutive scrapes or data collection events. 
+The `scrape_interval` typically refers to the frequency with which {{< param "PRODUCT_NAME" >}} collects performance profiles from the monitored targets.
+It represents the time interval between consecutive scrapes or data collection events.
 This parameter is important for controlling the trade-off between resource usage and the freshness of the collected data.
 
 If `scrape_interval` is short:
@@ -145,49 +137,44 @@ If `scrape_interval` is long:
   * Lower resource consumption.
 * Disadvantages:
   * More profiles may be lost if the application being scraped crashes.
-  * If the [delta argument][] is set to `true`, the batch size of 
-    each remote write to Pyroscope may be bigger.
+  * If the [delta argument][] is set to `true`, the batch size of each remote write to Pyroscope may be bigger.
     The Pyroscope database may need to be tuned with higher limits.
-  * If the [delta argument][] is set to `true`, there is a larger risk of 
-    reaching the HTTP server timeouts of the application being scraped.
+  * If the [delta argument][] is set to `true`, there is a larger risk of reaching the HTTP server timeouts of the application being scraped.
 
 For example, consider this situation:
 * `pyroscope.scrape` is configured with a `scrape_interval` of `"60s"`.
 * The application being scraped is running an HTTP server with a timeout of 30 seconds.
-* Any scrape HTTP requests where the [delta argument][] is set to `true` will fail, 
-  because they will attempt to run for 59 seconds.
+* Any scrape HTTP requests where the [delta argument][] is set to `true` will fail, because they will attempt to run for 59 seconds.
 
 ## Blocks
 
 The following blocks are supported inside the definition of `pyroscope.scrape`:
 
-| Hierarchy                                     | Block                          | Description                                                              | Required |
-|-----------------------------------------------|--------------------------------|--------------------------------------------------------------------------|----------|
-| basic_auth                                    | [basic_auth][]                 | Configure basic_auth for authenticating to targets.                      | no       |
-| authorization                                 | [authorization][]              | Configure generic authorization to targets.                              | no       |
-| oauth2                                        | [oauth2][]                     | Configure OAuth2 for authenticating to targets.                          | no       |
-| oauth2 > tls_config                           | [tls_config][]                 | Configure TLS settings for connecting to targets via OAuth2.             | no       |
-| tls_config                                    | [tls_config][]                 | Configure TLS settings for connecting to targets.                        | no       |
-| profiling_config                              | [profiling_config][]           | Configure profiling settings for the scrape job.                         | no       |
-| profiling_config > profile.memory             | [profile.memory][]             | Collect memory profiles.                                                 | no       |
-| profiling_config > profile.block              | [profile.block][]              | Collect profiles on blocks.                                              | no       |
-| profiling_config > profile.goroutine          | [profile.goroutine][]          | Collect goroutine profiles.                                              | no       |
-| profiling_config > profile.mutex              | [profile.mutex][]              | Collect mutex profiles.                                                  | no       |
-| profiling_config > profile.process_cpu        | [profile.process_cpu][]        | Collect CPU profiles.                                                    | no       |
-| profiling_config > profile.fgprof             | [profile.fgprof][]             | Collect [fgprof][] profiles.                                             | no       |
-| profiling_config > profile.godeltaprof_memory | [profile.godeltaprof_memory][] | Collect [godeltaprof][] memory profiles.                                 | no       |
-| profiling_config > profile.godeltaprof_mutex  | [profile.godeltaprof_mutex][]  | Collect [godeltaprof][] mutex profiles.                                  | no       |
-| profiling_config > profile.godeltaprof_block  | [profile.godeltaprof_block][]  | Collect [godeltaprof][] block profiles.                                  | no       |
-| profiling_config > profile.custom             | [profile.custom][]             | Collect custom profiles.                                                 | no       |
-| clustering                                    | [clustering][]                 | Configure the component for when {{< param "PRODUCT_NAME" >}} is running in clustered mode. | no       |
-
-The `>` symbol indicates deeper levels of nesting. For example,
-`oauth2 > tls_config` refers to a `tls_config` block defined inside
-an `oauth2` block.
-
-Any omitted blocks take on their default values. For example, 
-if `profile.mutex` is not specified in the config, 
-the defaults documented in [profile.mutex][] will be used.
+Hierarchy                                     | Block                          | Description                                                                                 | Required
+----------------------------------------------|--------------------------------|---------------------------------------------------------------------------------------------|---------
+basic_auth                                    | [basic_auth][]                 | Configure basic_auth for authenticating to targets.                                         | no
+authorization                                 | [authorization][]              | Configure generic authorization to targets.                                                 | no
+oauth2                                        | [oauth2][]                     | Configure OAuth2 for authenticating to targets.                                             | no
+oauth2 > tls_config                           | [tls_config][]                 | Configure TLS settings for connecting to targets via OAuth2.                                | no
+tls_config                                    | [tls_config][]                 | Configure TLS settings for connecting to targets.                                           | no
+profiling_config                              | [profiling_config][]           | Configure profiling settings for the scrape job.                                            | no
+profiling_config > profile.memory             | [profile.memory][]             | Collect memory profiles.                                                                    | no
+profiling_config > profile.block              | [profile.block][]              | Collect profiles on blocks.                                                                 | no
+profiling_config > profile.goroutine          | [profile.goroutine][]          | Collect goroutine profiles.                                                                 | no
+profiling_config > profile.mutex              | [profile.mutex][]              | Collect mutex profiles.                                                                     | no
+profiling_config > profile.process_cpu        | [profile.process_cpu][]        | Collect CPU profiles.                                                                       | no
+profiling_config > profile.fgprof             | [profile.fgprof][]             | Collect [fgprof][] profiles.                                                                | no
+profiling_config > profile.godeltaprof_memory | [profile.godeltaprof_memory][] | Collect [godeltaprof][] memory profiles.                                                    | no
+profiling_config > profile.godeltaprof_mutex  | [profile.godeltaprof_mutex][]  | Collect [godeltaprof][] mutex profiles.                                                     | no
+profiling_config > profile.godeltaprof_block  | [profile.godeltaprof_block][]  | Collect [godeltaprof][] block profiles.                                                     | no
+profiling_config > profile.custom             | [profile.custom][]             | Collect custom profiles.                                                                    | no
+clustering                                    | [clustering][]                 | Configure the component for when {{< param "PRODUCT_NAME" >}} is running in clustered mode. | no
+
+The `>` symbol indicates deeper levels of nesting.
+For example, `oauth2 > tls_config` refers to a `tls_config` block defined inside an `oauth2` block.
+
+Any omitted blocks take on their default values.
+For example, if `profile.mutex` is not specified in the config, the defaults documented in [profile.mutex][] will be used.
 
 [basic_auth]: #basic_auth-block
 [authorization]: #authorization-block
@@ -230,14 +217,13 @@ the defaults documented in [profile.mutex][] will be used.
 
 ### profiling_config block
 
-The `profiling_config` block configures the profiling settings when scraping
-targets.
+The `profiling_config` block configures the profiling settings when scraping targets.
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`path_prefix` | `string` | The path prefix to use when scraping targets. | | no
+Name          | Type     | Description                                   | Default | Required
+--------------|----------|-----------------------------------------------|---------|---------
+`path_prefix` | `string` | The path prefix to use when scraping targets. |         | no
 
 ### profile.memory block
 
@@ -245,11 +231,11 @@ The `profile.memory` block collects profiles on memory consumption.
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`enabled` | `boolean` | Enable this profile type to be scraped. | `true` | no
-`path` | `string` | The path to the profile type on the target. | `"/debug/pprof/allocs"` | no
-`delta` | `boolean` | Whether to scrape the profile as a delta. | `false` | no
+Name      | Type      | Description                                 | Default                 | Required
+----------|-----------|---------------------------------------------|-------------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `true`                  | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/allocs"` | no
+`delta`   | `boolean` | Whether to scrape the profile as a delta.   | `false`                 | no
 
 For more information about the `delta` argument, see the [delta argument][] section.
 
@@ -259,11 +245,11 @@ The `profile.block` block collects profiles on process blocking.
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`enabled` | `boolean` | Enable this profile type to be scraped. | `true` | no
-`path` | `string` | The path to the profile type on the target. | `"/debug/pprof/block"` | no
-`delta` | `boolean` | Whether to scrape the profile as a delta. | `false` | no
+Name      | Type      | Description                                 | Default                | Required
+----------|-----------|---------------------------------------------|------------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `true`                 | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/block"` | no
+`delta`   | `boolean` | Whether to scrape the profile as a delta.   | `false`                | no
 
 For more information about the `delta` argument, see the [delta argument][] section.
 
@@ -273,11 +259,11 @@ The `profile.goroutine` block collects profiles on the number of goroutines.
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`enabled` | `boolean` | Enable this profile type to be scraped. | `true` | no
-`path` | `string` | The path to the profile type on the target. | `"/debug/pprof/goroutine"` | no
-`delta` | `boolean` | Whether to scrape the profile as a delta. | `false` | no
+Name      | Type      | Description                                 | Default                    | Required
+----------|-----------|---------------------------------------------|----------------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `true`                     | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/goroutine"` | no
+`delta`   | `boolean` | Whether to scrape the profile as a delta.   | `false`                    | no
 
 For more information about the `delta` argument, see the [delta argument][] section.
 
@@ -287,26 +273,25 @@ The `profile.mutex` block collects profiles on mutexes.
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`enabled` | `boolean` | Enable this profile type to be scraped. | `true` | no
-`path` | `string` | The path to the profile type on the target. | `"/debug/pprof/mutex"` | no
-`delta` | `boolean` | Whether to scrape the profile as a delta. | `false` | no
+Name      | Type      | Description                                 | Default                | Required
+----------|-----------|---------------------------------------------|------------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `true`                 | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/mutex"` | no
+`delta`   | `boolean` | Whether to scrape the profile as a delta.   | `false`                | no
 
 For more information about the `delta` argument, see the [delta argument][] section.
 
 ### profile.process_cpu block
 
-The `profile.process_cpu` block collects profiles on CPU consumption for the
-process.
+The `profile.process_cpu` block collects profiles on CPU consumption for the process.
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`enabled` | `boolean` | Enable this profile type to be scraped. | `true` | no
-`path` | `string` | The path to the profile type on the target. | `"/debug/pprof/profile"` | no
-`delta` | `boolean` | Whether to scrape the profile as a delta. | `true` | no
+Name      | Type      | Description                                 | Default                  | Required
+----------|-----------|---------------------------------------------|--------------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `true`                   | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/profile"` | no
+`delta`   | `boolean` | Whether to scrape the profile as a delta.   | `true`                   | no
 
 For more information about the `delta` argument, see the [delta argument][] section.
 
@@ -316,11 +301,11 @@ The `profile.fgprof` block collects profiles from an [fgprof][] endpoint.
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`enabled` | `boolean` | Enable this profile type to be scraped. | `false` | no
-`path` | `string` | The path to the profile type on the target. | `"/debug/fgprof"` | no
-`delta` | `boolean` | Whether to scrape the profile as a delta. | `true` | no
+Name      | Type      | Description                                 | Default           | Required
+----------|-----------|---------------------------------------------|-------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `false`           | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/fgprof"` | no
+`delta`   | `boolean` | Whether to scrape the profile as a delta.   | `true`            | no
 
 For more information about the `delta` argument, see the [delta argument][] section.
 
@@ -330,21 +315,22 @@ The `profile.godeltaprof_memory` block collects profiles from [godeltaprof][] me
 
 The following arguments are supported:
 
-| Name      | Type      | Description                                 | Default                     | Required |
-|-----------|-----------|---------------------------------------------|-----------------------------|----------|
-| `enabled` | `boolean` | Enable this profile type to be scraped.     | `false`                     | no       |
-| `path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/delta_heap"` | no       |
+Name      | Type      | Description                                 | Default                     | Required
+----------|-----------|---------------------------------------------|-----------------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `false`                     | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/delta_heap"` | no
 
 ### profile.godeltaprof_mutex block
 
-The `profile.godeltaprof_mutex` block collects profiles from [godeltaprof][] mutex endpoint. The delta is computed on the target.
+The `profile.godeltaprof_mutex` block collects profiles from [godeltaprof][] mutex endpoint.
+The delta is computed on the target.
 
 The following arguments are supported:
 
-| Name      | Type      | Description                                 | Default                      | Required |
-|-----------|-----------|---------------------------------------------|------------------------------|----------|
-| `enabled` | `boolean` | Enable this profile type to be scraped.     | `false`                      | no       |
-| `path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/delta_mutex"` | no       |
+Name      | Type      | Description                                 | Default                      | Required
+----------|-----------|---------------------------------------------|------------------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `false`                      | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/delta_mutex"` | no
 
 ### profile.godeltaprof_block block
 
@@ -352,16 +338,15 @@ The `profile.godeltaprof_block` block collects profiles from [godeltaprof][] blo
 
 The following arguments are supported:
 
-| Name      | Type      | Description                                 | Default                      | Required |
-|-----------|-----------|---------------------------------------------|------------------------------|----------|
-| `enabled` | `boolean` | Enable this profile type to be scraped.     | `false`                      | no       |
-| `path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/delta_block"` | no       |
+Name      | Type      | Description                                 | Default                      | Required
+----------|-----------|---------------------------------------------|------------------------------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     | `false`                      | no
+`path`    | `string`  | The path to the profile type on the target. | `"/debug/pprof/delta_block"` | no
 
 
 ### profile.custom block
 
-The `profile.custom` block allows for collecting profiles from custom
-endpoints. Blocks must be specified with a label:
+The `profile.custom` block allows for collecting profiles from custom endpoints. Blocks must be specified with a label:
 
 ```alloy
 profile.custom "PROFILE_TYPE" {
@@ -370,38 +355,32 @@ profile.custom "PROFILE_TYPE" {
 }
 ```
 
-Multiple `profile.custom` blocks can be specified. Labels assigned to
-`profile.custom` blocks must be unique across the component.
+Multiple `profile.custom` blocks can be specified.
+Labels assigned to `profile.custom` blocks must be unique across the component.
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`enabled` | `boolean` | Enable this profile type to be scraped. | | yes
-`path` | `string` | The path to the profile type on the target. | | yes
-`delta` | `boolean` | Whether to scrape the profile as a delta. | `false` | no
+Name      | Type      | Description                                 | Default | Required
+----------|-----------|---------------------------------------------|---------|---------
+`enabled` | `boolean` | Enable this profile type to be scraped.     |         | yes
+`path`    | `string`  | The path to the profile type on the target. |         | yes
+`delta`   | `boolean` | Whether to scrape the profile as a delta.   | `false` | no
 
-When the `delta` argument is `true`, a `seconds` query parameter is
-automatically added to requests. The `seconds` used will be equal to `scrape_interval - 1`.
+When the `delta` argument is `true`, a `seconds` query parameter is automatically added to requests.
+The `seconds` used will be equal to `scrape_interval - 1`.
 
 ### clustering block
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
+Name      | Type   | Description                                       | Default | Required
+----------|--------|---------------------------------------------------|---------|---------
 `enabled` | `bool` | Enables sharing targets with other cluster nodes. | `false` | yes
 
-When {{< param "PRODUCT_NAME" >}} is [using clustering][], and `enabled` is set to true,
-then this `pyroscope.scrape` component instance opts-in to participating in the
-cluster to distribute scrape load between all cluster nodes.
+When {{< param "PRODUCT_NAME" >}} is [using clustering][], and `enabled` is set to true, then this `pyroscope.scrape` component instance opts-in to participating in the cluster to distribute scrape load between all cluster nodes.
 
-Clustering causes the set of targets to be locally filtered down to a unique
-subset per node, where each node is roughly assigned the same number of
-targets. If the state of the cluster changes, such as a new node joins, then
-the subset of targets to scrape per node will be recalculated.
+Clustering causes the set of targets to be locally filtered down to a unique subset per node, where each node is roughly assigned the same number of targets.
+If the state of the cluster changes, such as a new node joins, then the subset of targets to scrape per node will be recalculated.
 
-When clustering mode is enabled, all {{< param "PRODUCT_NAME" >}}s participating in the cluster must
-use the same configuration file and have access to the same service discovery
-APIs.
+When clustering mode is enabled, all {{< param "PRODUCT_NAME" >}} instances participating in the cluster must use the same configuration file and have access to the same service discovery APIs.
 
 If {{< param "PRODUCT_NAME" >}} is _not_ running in clustered mode, this block is a no-op.
 
@@ -422,18 +401,15 @@ When the `delta` argument is `true`:
 
 ## Exported fields
 
-`pyroscope.scrape` does not export any fields that can be referenced by other
-components.
+`pyroscope.scrape` does not export any fields that can be referenced by other components.
 
 ## Component health
 
-`pyroscope.scrape` is only reported as unhealthy if given an invalid
-configuration.
+`pyroscope.scrape` is only reported as unhealthy if given an invalid configuration.
 
 ## Debug information
 
-`pyroscope.scrape` reports the status of the last scrape for each configured
-scrape job on the component's debug endpoint.
+`pyroscope.scrape` reports the status of the last scrape for each configured scrape job on the component's debug endpoint.
 
 ## Debug metrics
 
@@ -445,15 +421,14 @@ scrape job on the component's debug endpoint.
 
 ### Default endpoints of static targets
 
-The following example sets up a scrape job of a statically configured 
-list of targets - {{< param "PRODUCT_NAME" >}} itself and Pyroscope.
+The following example sets up a scrape job of a statically configured list of targets - {{< param "PRODUCT_NAME" >}} itself and Pyroscope.
 The scraped profiles are sent to `pyroscope.write` which remote writes them to a Pyroscope database.
 
 ```alloy
 pyroscope.scrape "local" {
   targets = [
     {"__address__" = "localhost:4100", "service_name"="pyroscope"},
-    {"__address__" = "localhost:12345", "service_name"="agent"},
+    {"__address__" = "localhost:12345", "service_name"="alloy"},
   ]
 
   forward_to = [pyroscope.write.local.receiver]
@@ -482,12 +457,11 @@ http://localhost:12345/debug/pprof/mutex
 http://localhost:12345/debug/pprof/profile?seconds=14
 ```
 
-Note that `seconds=14` is added to the `/debug/pprof/profile` endpoint, because:
+`seconds=14` is added to the `/debug/pprof/profile` endpoint, because:
 * The `delta` argument of the `profile.process_cpu` block is `true` by default.
-* `scrape_interval` is `"15s"` by default. 
+* `scrape_interval` is `"15s"` by default.
 
-Also note that the `/debug/fgprof` endpoint will not be scraped, because
-the `enabled` argument of the `profile.fgprof` block is `false` by default.
+The `/debug/fgprof` endpoint will not be scraped, because the `enabled` argument of the `profile.fgprof` block is `false` by default.
 
 [example_dynamic_targets]: #default-endpoints-of-dynamic-targets
 
@@ -525,7 +499,7 @@ discovery.http "dynamic_targets" {
 pyroscope.scrape "local" {
   targets = concat([
     {"__address__" = "localhost:4040", "service_name"="pyroscope"},
-    {"__address__" = "localhost:12345", "service_name"="agent"},
+    {"__address__" = "localhost:12345", "service_name"="alloy"},
   ], discovery.http.dynamic_targets.targets)
 
   forward_to = [pyroscope.write.local.receiver]
@@ -544,7 +518,7 @@ pyroscope.write "local" {
 ```alloy
 pyroscope.scrape "local" {
   targets = [
-    {"__address__" = "localhost:12345", "service_name"="agent"},
+    {"__address__" = "localhost:12345", "service_name"="alloy"},
   ]
 
   profiling_config {
diff --git a/docs/sources/reference/components/pyroscope.write.md b/docs/sources/reference/components/pyroscope.write.md
index c193dc5f71..137b095805 100644
--- a/docs/sources/reference/components/pyroscope.write.md
+++ b/docs/sources/reference/components/pyroscope.write.md
@@ -10,11 +10,9 @@ title: pyroscope.write
 
 {{< docs/shared lookup="stability/public_preview.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-`pyroscope.write` receives performance profiles from other components and forwards them
-to a series of user-supplied endpoints using [Pyroscope' Push API](/oss/pyroscope/).
+`pyroscope.write` receives performance profiles from other components and forwards them to a series of user-supplied endpoints using [Pyroscope' Push API](/oss/pyroscope/).
 
-Multiple `pyroscope.write` components can be specified by giving them
-different labels.
+Multiple `pyroscope.write` components can be specified by giving them different labels.
 
 ## Usage
 
@@ -34,27 +32,25 @@ pyroscope.write "LABEL" {
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`external_labels` | `map(string)` | Labels to add to profiles sent over the network. | | no
+Name              | Type          | Description                                      | Default | Required
+------------------|---------------|--------------------------------------------------|---------|---------
+`external_labels` | `map(string)` | Labels to add to profiles sent over the network. |         | no
 
 ## Blocks
 
-The following blocks are supported inside the definition of
-`pyroscope.write`:
+The following blocks are supported inside the definition of `pyroscope.write`:
 
-Hierarchy | Block | Description | Required
---------- | ----- | ----------- | --------
-endpoint | [endpoint][] | Location to send profiles to. | no
-endpoint > basic_auth | [basic_auth][] | Configure basic_auth for authenticating to the endpoint. | no
-endpoint > authorization | [authorization][] | Configure generic authorization to the endpoint. | no
-endpoint > oauth2 | [oauth2][] | Configure OAuth2 for authenticating to the endpoint. | no
-endpoint > oauth2 > tls_config | [tls_config][] | Configure TLS settings for connecting to the endpoint. | no
-endpoint > tls_config | [tls_config][] | Configure TLS settings for connecting to the endpoint. | no
+Hierarchy                      | Block             | Description                                              | Required
+-------------------------------|-------------------|----------------------------------------------------------|---------
+endpoint                       | [endpoint][]      | Location to send profiles to.                            | no
+endpoint > basic_auth          | [basic_auth][]    | Configure basic_auth for authenticating to the endpoint. | no
+endpoint > authorization       | [authorization][] | Configure generic authorization to the endpoint.         | no
+endpoint > oauth2              | [oauth2][]        | Configure OAuth2 for authenticating to the endpoint.     | no
+endpoint > oauth2 > tls_config | [tls_config][]    | Configure TLS settings for connecting to the endpoint.   | no
+endpoint > tls_config          | [tls_config][]    | Configure TLS settings for connecting to the endpoint.   | no
 
-The `>` symbol indicates deeper levels of nesting. For example, `endpoint >
-basic_auth` refers to a `basic_auth` block defined inside an
-`endpoint` block.
+The `>` symbol indicates deeper levels of nesting.
+For example, `endpoint > basic_auth` refers to a `basic_auth` block defined inside an `endpoint` block.
 
 [endpoint]: #endpoint-block
 [basic_auth]: #basic_auth-block
@@ -64,8 +60,8 @@ basic_auth` refers to a `basic_auth` block defined inside an
 
 ### endpoint block
 
-The `endpoint` block describes a single location to send profiles to. Multiple
-`endpoint` blocks can be provided to send profiles to multiple locations.
+The `endpoint` block describes a single location to send profiles to.
+Multiple `endpoint` blocks can be provided to send profiles to multiple locations.
 
 The following arguments are supported:
 
@@ -96,8 +92,7 @@ Name                     | Type                | Description
 
 {{< docs/shared lookup="reference/components/http-client-proxy-config-description.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-When multiple `endpoint` blocks are provided, profiles are concurrently forwarded to all
-configured locations.
+When multiple `endpoint` blocks are provided, profiles are concurrently forwarded to all configured locations.
 
 ### basic_auth block
 
@@ -119,20 +114,18 @@ configured locations.
 
 The following fields are exported and can be referenced by other components:
 
-Name | Type | Description
----- | ---- | -----------
+Name       | Type       | Description
+-----------|------------|-----------------------------------------------------------
 `receiver` | `receiver` | A value that other components can use to send profiles to.
 
 ## Component health
 
-`pyroscope.write` is only reported as unhealthy if given an invalid
-configuration. In those cases, exported fields are kept at their last healthy
-values.
+`pyroscope.write` is only reported as unhealthy if given an invalid configuration.
+In those cases, exported fields are kept at their last healthy values.
 
 ## Debug information
 
-`pyroscope.write` does not expose any component-specific debug
-information.
+`pyroscope.write` does not expose any component-specific debug information.
 
 ## Example
 
@@ -150,7 +143,6 @@ pyroscope.write "staging" {
   }
 }
 
-
 pyroscope.scrape "default" {
   targets = [
     {"__address__" = "pyroscope:4100", "service_name"="pyroscope"},
diff --git a/docs/sources/reference/components/remote.http.md b/docs/sources/reference/components/remote.http.md
index f8c419d6a3..24873cd8bf 100644
--- a/docs/sources/reference/components/remote.http.md
+++ b/docs/sources/reference/components/remote.http.md
@@ -6,14 +6,12 @@ title: remote.http
 
 # remote.http
 
-`remote.http` exposes the response body of a URL to other components. The URL
-is polled for changes so that the most recent content is always available.
+`remote.http` exposes the response body of a URL to other components.
+The URL is polled for changes so that the most recent content is always available.
 
-The most common use of `remote.http` is to load discovery targets from an HTTP
-server.
+The most common use of `remote.http` is to load discovery targets from an HTTP server.
 
-Multiple `remote.http` components can be specified by giving them different
-labels.
+Multiple `remote.http` components can be specified by giving them different labels.
 
 ## Usage
 
@@ -37,17 +35,16 @@ Name             | Type          | Description
 `poll_timeout`   | `duration`    | Timeout when polling the URL.                            | `"10s"` | no
 `is_secret`      | `bool`        | Whether the response body should be treated as a secret. | false   | no
 
-When `remote.http` performs a poll operation, an HTTP `GET` request is made
-against the URL specified by the `url` argument. A poll is triggered by the
-following:
+When `remote.http` performs a poll operation, an HTTP `GET` request is made against the URL specified by the `url` argument.
+A poll is triggered by the following:
 
 * When the component first loads.
 * Every time the component's arguments get re-evaluated.
 * At the frequency specified by the `poll_frequency` argument.
 
-The poll is successful if the URL returns a `200 OK` response code. All other
-response codes are treated as errors and mark the component as unhealthy. After
-a successful poll, the response body from the URL is exported.
+The poll is successful if the URL returns a `200 OK` response code.
+All other response codes are treated as errors and mark the component as unhealthy.
+After a successful poll, the response body from the URL is exported.
 
 [secret]: ../../../concepts/configuration-syntax/expressions/types_and_values/#secrets
 
@@ -64,8 +61,8 @@ client > oauth2              | [oauth2][]        | Configure OAuth2 for authenti
 client > oauth2 > tls_config | [tls_config][]    | Configure TLS settings for connecting to the endpoint.   | no
 client > tls_config          | [tls_config][]    | Configure TLS settings for connecting to the endpoint.   | no
 
-The `>` symbol indicates deeper levels of nesting. For example, `client >
-basic_auth` refers to an `basic_auth` block defined inside a `client` block.
+The `>` symbol indicates deeper levels of nesting.
+For example, `client > basic_auth` refers to an `basic_auth` block defined inside a `client` block.
 
 [client]: #client-block
 [basic_auth]: #basic_auth-block
@@ -75,29 +72,25 @@ basic_auth` refers to an `basic_auth` block defined inside a `client` block.
 
 ### client block
 
-The `client` block configures settings used to connect to the HTTP
-server.
+The `client` block configures settings used to connect to the HTTP server.
 
 {{< docs/shared lookup="reference/components/http-client-config-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ### basic_auth block
 
-The `basic_auth` block configures basic authentication to use when polling the
-configured URL.
+The `basic_auth` block configures basic authentication to use when polling the configured URL.
 
 {{< docs/shared lookup="reference/components/basic-auth-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ### authorization block
 
-The `authorization` block configures custom authorization to use when polling
-the configured URL.
+The `authorization` block configures custom authorization to use when polling the configured URL.
 
 {{< docs/shared lookup="reference/components/authorization-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
 ### oauth2 block
 
-The `oauth2` block configures OAuth2 authorization to use when polling the
-configured URL.
+The `oauth2` block configures OAuth2 authorization to use when polling the configured URL.
 
 {{< docs/shared lookup="reference/components/oauth2-block.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
@@ -119,21 +112,19 @@ If the `is_secret` argument was `true`, `content` is a secret type.
 
 ## Component health
 
-Instances of `remote.http` report as healthy if the most recent HTTP `GET`
-request of the specified URL succeeds.
+Instances of `remote.http` report as healthy if the most recent HTTP `GET` request of the specified URL succeeds.
 
 ## Debug information
 
-`remote.http` does not expose any component-specific debug information.
+`remote.http` doesn't expose any component-specific debug information.
 
 ## Debug metrics
 
-`remote.http` does not expose any component-specific debug metrics.
+`remote.http` doesn't expose any component-specific debug metrics.
 
 ## Example
 
-This example reads a JSON array of objects from an endpoint and uses them as a
-set of scrape targets:
+This example reads a JSON array of objects from an endpoint and uses them as a set of scrape targets:
 
 ```alloy
 remote.http "targets" {
diff --git a/docs/sources/reference/components/remote.kubernetes.configmap.md b/docs/sources/reference/components/remote.kubernetes.configmap.md
index af7e90a588..0fd490b88c 100644
--- a/docs/sources/reference/components/remote.kubernetes.configmap.md
+++ b/docs/sources/reference/components/remote.kubernetes.configmap.md
@@ -23,12 +23,12 @@ remote.kubernetes.configmap "LABEL" {
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`namespace` | `string` | Kubernetes namespace containing the desired ConfigMap. | | yes
-`name` | `string` | Name of the Kubernetes ConfigMap | | yes
-`poll_frequency` | `duration` | Frequency to poll the Kubernetes API. | `"1m"` | no
-`poll_timeout` | `duration` | Timeout when polling the Kubernetes API. | `"15s"` | no
+Name             | Type       | Description                                            | Default | Required
+-----------------|------------|--------------------------------------------------------|---------|---------
+`namespace`      | `string`   | Kubernetes namespace containing the desired ConfigMap. |         | yes
+`name`           | `string`   | Name of the Kubernetes ConfigMap                       |         | yes
+`poll_frequency` | `duration` | Frequency to poll the Kubernetes API.                  | `"1m"`  | no
+`poll_timeout`   | `duration` | Timeout when polling the Kubernetes API.               | `"15s"` | no
 
 When this component performs a poll operation, it requests the ConfigMap data from the Kubernetes API.
 A poll is triggered by the following:
@@ -37,24 +37,24 @@ A poll is triggered by the following:
 * Every time the component's arguments get re-evaluated.
 * At the frequency specified by the `poll_frequency` argument.
 
-Any error while polling will mark the component as unhealthy. After
-a successful poll, all data is exported with the same field names as the source ConfigMap.
+Any error while polling will mark the component as unhealthy.
+After a successful poll, all data is exported with the same field names as the source ConfigMap.
 
 ## Blocks
 
 The following blocks are supported inside the definition of `remote.kubernetes.configmap`:
 
-Hierarchy | Block | Description | Required
---------- | ----- | ----------- | --------
-client | [client][] | Configures Kubernetes client used to find Probes. | no
-client > basic_auth | [basic_auth][] | Configure basic authentication to the Kubernetes API. | no
-client > authorization | [authorization][] | Configure generic authorization to the Kubernetes API. | no
-client > oauth2 | [oauth2][] | Configure OAuth2 for authenticating to the Kubernetes API. | no
-client > oauth2 > tls_config | [tls_config][] | Configure TLS settings for connecting to the Kubernetes API. | no
-client > tls_config | [tls_config][] | Configure TLS settings for connecting to the Kubernetes API. | no
+Hierarchy                    | Block             | Description                                                  | Required
+-----------------------------|-------------------|--------------------------------------------------------------|---------
+client                       | [client][]        | Configures Kubernetes client used to find Probes.            | no
+client > basic_auth          | [basic_auth][]    | Configure basic authentication to the Kubernetes API.        | no
+client > authorization       | [authorization][] | Configure generic authorization to the Kubernetes API.       | no
+client > oauth2              | [oauth2][]        | Configure OAuth2 for authenticating to the Kubernetes API.   | no
+client > oauth2 > tls_config | [tls_config][]    | Configure TLS settings for connecting to the Kubernetes API. | no
+client > tls_config          | [tls_config][]    | Configure TLS settings for connecting to the Kubernetes API. | no
 
-The `>` symbol indicates deeper levels of nesting. For example, `client > basic_auth`
-refers to a `basic_auth` block defined inside a `client` block.
+The `>` symbol indicates deeper levels of nesting.
+For example, `client > basic_auth` refers to a `basic_auth` block defined inside a `client` block.
 
 [client]: #client-block
 [basic_auth]: #basic_auth-block
@@ -64,9 +64,8 @@ refers to a `basic_auth` block defined inside a `client` block.
 
 ### client block
 
-The `client` block configures the Kubernetes client used to discover Probes. If the `client` block isn't provided, the default in-cluster
-configuration with the service account of the running {{< param "PRODUCT_NAME" >}} pod is
-used.
+The `client` block configures the Kubernetes client used to discover Probes.
+If the `client` block isn't provided, the default in-cluster configuration with the service account of the running {{< param "PRODUCT_NAME" >}} pod is used.
 
 The following arguments are supported:
 
@@ -113,8 +112,8 @@ Name                     | Type                | Description
 
 The following fields are exported and can be referenced by other components:
 
-Name | Type | Description
----- | ---- | -----------
+Name   | Type          | Description
+-------|---------------|--------------------------------------------------
 `data` | `map(string)` | Data from the ConfigMap obtained from Kubernetes.
 
 The `data` field contains a mapping from field names to values.
@@ -157,6 +156,4 @@ prometheus.remote_write "default" {
 }
 ```
 
-This example assumes that the Secret and ConfigMap have already been created, and that the appropriate field names
-exist in their data.
-
+This example assumes that the Secret and ConfigMap have already been created, and that the appropriate field names exist in their data.
diff --git a/docs/sources/reference/components/remote.kubernetes.secret.md b/docs/sources/reference/components/remote.kubernetes.secret.md
index 1f09cff980..49fd2296bd 100644
--- a/docs/sources/reference/components/remote.kubernetes.secret.md
+++ b/docs/sources/reference/components/remote.kubernetes.secret.md
@@ -23,12 +23,12 @@ remote.kubernetes.secret "LABEL" {
 
 The following arguments are supported:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`namespace` | `string` | Kubernetes namespace containing the desired Secret. | | yes
-`name` | `string` | Name of the Kubernetes Secret | | yes
-`poll_frequency` | `duration` | Frequency to poll the Kubernetes API. | `"1m"` | no
-`poll_timeout` | `duration` | Timeout when polling the Kubernetes API. | `"15s"` | no
+Name             | Type       | Description                                         | Default | Required
+-----------------|------------|-----------------------------------------------------|---------|---------
+`namespace`      | `string`   | Kubernetes namespace containing the desired Secret. |         | yes
+`name`           | `string`   | Name of the Kubernetes Secret                       |         | yes
+`poll_frequency` | `duration` | Frequency to poll the Kubernetes API.               | `"1m"`  | no
+`poll_timeout`   | `duration` | Timeout when polling the Kubernetes API.            | `"15s"` | no
 
 When this component performs a poll operation, it requests the Secret data from the Kubernetes API.
 A poll is triggered by the following:
@@ -37,24 +37,24 @@ A poll is triggered by the following:
 * Every time the component's arguments get re-evaluated.
 * At the frequency specified by the `poll_frequency` argument.
 
-Any error while polling will mark the component as unhealthy. After
-a successful poll, all data is exported with the same field names as the source Secret.
+Any error while polling will mark the component as unhealthy.
+After a successful poll, all data is exported with the same field names as the source Secret.
 
 ## Blocks
 
 The following blocks are supported inside the definition of `remote.kubernetes.secret`:
 
-Hierarchy | Block | Description | Required
---------- | ----- | ----------- | --------
-client | [client][] | Configures Kubernetes client used to find Probes. | no
-client > basic_auth | [basic_auth][] | Configure basic authentication to the Kubernetes API. | no
-client > authorization | [authorization][] | Configure generic authorization to the Kubernetes API. | no
-client > oauth2 | [oauth2][] | Configure OAuth2 for authenticating to the Kubernetes API. | no
-client > oauth2 > tls_config | [tls_config][] | Configure TLS settings for connecting to the Kubernetes API. | no
-client > tls_config | [tls_config][] | Configure TLS settings for connecting to the Kubernetes API. | no
+Hierarchy                    | Block             | Description                                                  | Required
+-----------------------------|-------------------|--------------------------------------------------------------|---------
+client                       | [client][]        | Configures Kubernetes client used to find Probes.            | no
+client > basic_auth          | [basic_auth][]    | Configure basic authentication to the Kubernetes API.        | no
+client > authorization       | [authorization][] | Configure generic authorization to the Kubernetes API.       | no
+client > oauth2              | [oauth2][]        | Configure OAuth2 for authenticating to the Kubernetes API.   | no
+client > oauth2 > tls_config | [tls_config][]    | Configure TLS settings for connecting to the Kubernetes API. | no
+client > tls_config          | [tls_config][]    | Configure TLS settings for connecting to the Kubernetes API. | no
 
-The `>` symbol indicates deeper levels of nesting. For example, `client > basic_auth`
-refers to a `basic_auth` block defined inside a `client` block.
+The `>` symbol indicates deeper levels of nesting.
+For example, `client > basic_auth` refers to a `basic_auth` block defined inside a `client` block.
 
 [client]: #client-block
 [basic_auth]: #basic_auth-block
@@ -64,8 +64,8 @@ refers to a `basic_auth` block defined inside a `client` block.
 
 ### client block
 
-The `client` block configures the Kubernetes client used to discover Probes. If the `client` block isn't provided, the default in-cluster
-configuration with the service account of the running {{< param "PRODUCT_NAME" >}} pod is used.
+The `client` block configures the Kubernetes client used to discover Probes.
+If the `client` block isn't provided, the default in-cluster configuration with the service account of the running {{< param "PRODUCT_NAME" >}} pod is used.
 
 The following arguments are supported:
 
@@ -112,21 +112,19 @@ Name                     | Type                | Description
 
 The following fields are exported and can be referenced by other components:
 
-Name | Type | Description
----- | ---- | -----------
+Name   | Type          | Description
+-------|---------------|-----------------------------------------------
 `data` | `map(secret)` | Data from the secret obtained from Kubernetes.
 
 The `data` field contains a mapping from field names to values.
 
-If an individual key stored in `data` does not hold sensitive data, it can be
-converted into a string using [the `nonsensitive` function][nonsensitive]:
+If an individual key stored in `data` does not hold sensitive data, it can be converted into a string using [the `nonsensitive` function][nonsensitive]:
 
 ```alloy
 nonsensitive(remote.kubernetes.secret.LABEL.data.KEY_NAME)
 ```
 
-Using `nonsensitive` allows for using the exports of `remote.kubernetes.secret` for
-attributes in components that do not support secrets.
+Using `nonsensitive` allows for using the exports of `remote.kubernetes.secret` for attributes in components that do not support secrets.
 
 [nonsensitive]: ../../stdlib/nonsensitive/
 
@@ -168,5 +166,4 @@ prometheus.remote_write "default" {
 }
 ```
 
-This example assumes that the Secret and ConfigMap have already been created, and that the appropriate field names
-exist in their data.
+This example assumes that the Secret and ConfigMap have already been created, and that the appropriate field names exist in their data.
diff --git a/docs/sources/reference/components/remote.s3.md b/docs/sources/reference/components/remote.s3.md
index 260ce698b6..07bc1abfe4 100644
--- a/docs/sources/reference/components/remote.s3.md
+++ b/docs/sources/reference/components/remote.s3.md
@@ -6,18 +6,18 @@ title: remote.s3
 
 # remote.s3
 
-`remote.s3` exposes the string contents of a file located in [AWS S3](https://aws.amazon.com/s3/)
-to other components. The file will be polled for changes so that the most
-recent content is always available.
+`remote.s3` exposes the string contents of a file located in [AWS S3](https://aws.amazon.com/s3/) to other components.
+The file will be polled for changes so that the most recent content is always available.
 
 The most common use of `remote.s3` is to load secrets from files.
 
 Multiple `remote.s3` components can be specified using different name
 labels. By default, [AWS environment variables](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html) are used to authenticate against S3. The `key` and `secret` arguments inside `client` blocks can be used to provide custom authentication.
 
-> **NOTE**: Other S3-compatible systems can be read  with `remote.s3` but may require specific
-> authentication environment variables. There is no  guarantee that `remote.s3` will work with non-AWS S3
-> systems.
+{{< admonition type="note" >}}
+Other S3-compatible systems can be read  with `remote.s3` but may require specific authentication environment variables.
+There is no  guarantee that `remote.s3` will work with non-AWS S3 systems.
+{{< /admonition >}}
 
 ## Usage
 
@@ -37,15 +37,17 @@ Name             | Type       | Description
 `poll_frequency` | `duration` | How often to poll the file for changes. Must be greater than 30 seconds. | `"10m"` | no
 `is_secret`      | `bool`     | Marks the file as containing a [secret][].                               | `false` | no
 
-> **NOTE**: `path` must include a full path to a file. This does not support reading of directories.
+{{< admonition type="note" >}}
+`path` must include a full path to a file. This does not support reading of directories.
+{{< /admonition >}}
 
 [secret]: ../../../concepts/configuration-syntax/expressions/types_and_values/#secrets
 
 ## Blocks
 
-Hierarchy | Name       | Description | Required
---------- |------------| ----------- | --------
-client | [client][] | Additional options for configuring the S3 client. | no
+Hierarchy | Name       | Description                                       | Required
+----------|------------|---------------------------------------------------|---------
+client    | [client][] | Additional options for configuring the S3 client. | no
 
 [client]: #client-block
 
@@ -68,24 +70,23 @@ Name             | Type     | Description
 
 The following fields are exported and can be referenced by other components:
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`content` | `string` or `secret` | The contents of the file. | | no
+Name      | Type                 | Description               | Default | Required
+----------|----------------------|---------------------------|---------|---------
+`content` | `string` or `secret` | The contents of the file. |         | no
 
 The `content` field will be secret if `is_secret` was set to true.
 
 ## Component health
 
-Instances of `remote.s3` report as healthy if the most recent read of
-the watched file was successful.
+Instances of `remote.s3` report as healthy if the most recent read of the watched file was successful.
 
 ## Debug information
 
-`remote.s3` does not expose any component-specific debug information.
+`remote.s3` doesn't expose any component-specific debug information.
 
 ## Debug metrics
 
-`remote.s3` does not expose any component-specific debug metrics.
+`remote.s3` doesn't expose any component-specific debug metrics.
 
 ## Example
 
diff --git a/docs/sources/reference/components/remote.vault.md b/docs/sources/reference/components/remote.vault.md
index e07fc6d6fa..8caa6a0200 100644
--- a/docs/sources/reference/components/remote.vault.md
+++ b/docs/sources/reference/components/remote.vault.md
@@ -40,13 +40,11 @@ Name               | Type       | Description
 `path`             | `string`   | The path to retrieve a secret from.                        |         | yes
 `reread_frequency` | `duration` | Rate to re-read keys.                                      | `"0s"`  | no
 
-Tokens with a lease will be automatically renewed roughly two-thirds through
-their lease duration. If the leased token isn't renewable, or renewing the
-lease fails, the token will be re-read.
+Tokens with a lease will be automatically renewed roughly two-thirds through their lease duration.
+If the leased token isn't renewable, or renewing the lease fails, the token will be re-read.
 
-All tokens, regardless of whether they have a lease, are automatically reread
-at a frequency specified by the `reread_frequency` argument. Setting
-`reread_frequency` to `"0s"` (the default) disables this behavior.
+All tokens, regardless of whether they have a lease, are automatically reread at a frequency specified by the `reread_frequency` argument.
+Setting `reread_frequency` to `"0s"` (the default) disables this behavior.
 
 ## Blocks
 
@@ -65,8 +63,7 @@ auth.ldap       | [auth.ldap][]       | Authenticate to Vault using LDAP.
 auth.userpass   | [auth.userpass][]   | Authenticate to Vault using a username and password. | no
 auth.custom     | [auth.custom][]     | Authenticate to Vault with custom authentication.    | no
 
-Exactly one `auth.*` block **must** be provided, otherwise the component will
-fail to load.
+Exactly one `auth.*` block **must** be provided, otherwise the component will fail to load.
 
 [client_options]: #client_options-block
 [auth.token]: #authtoken-block
@@ -92,35 +89,31 @@ Name             | Type       | Description
 
 Requests which fail due to server errors (HTTP 5xx error codes) can be retried.
 The `max_retries` argument specifies how many times to retry failed requests.
-The `min_retry_wait` and `max_retry_wait` arguments specify how long to wait
-before retrying. The wait period starts at `min_retry_wait` and exponentially
-increases up to `max_retry_wait`.
+The `min_retry_wait` and `max_retry_wait` arguments specify how long to wait before retrying.
+The wait period starts at `min_retry_wait` and exponentially increases up to `max_retry_wait`.
 
-Other types of failed requests, including HTTP 4xx error codes, are not
-retried.
+Other types of failed requests, including HTTP 4xx error codes, aren't retried.
 
-If the `max_retries` argument is set to `0`, failed requests are not retried.
+If the `max_retries` argument is set to `0`, failed requests aren't retried.
 
 ### auth.token block
 
-The `auth.token` block authenticates each request to Vault using a
-token.
+The `auth.token` block authenticates each request to Vault using a token.
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`token` | `secret` | Authentication token to use. | | yes
+Name    | Type     | Description                  | Default | Required
+--------|----------|------------------------------|---------|---------
+`token` | `secret` | Authentication token to use. |         | yes
 
 ### auth.approle block
 
-The `auth.token` block auhenticates to Vault using the [AppRole auth
-method][AppRole].
+The `auth.token` block authenticates to Vault using the [AppRole auth method][AppRole].
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`role_id` | `string` | Role ID to authenticate as. | | yes
-`secret` | `secret` | Secret to authenticate with. | | yes
-`wrapping_token` | `bool` | Whether to [unwrap][] the token. | `false` | no
-`mount_path` | `string` | Mount path for the login. | `"approle"` | no
+Name             | Type     | Description                      | Default     | Required
+-----------------|----------|----------------------------------|-------------|---------
+`role_id`        | `string` | Role ID to authenticate as.      |             | yes
+`secret`         | `secret` | Secret to authenticate with.     |             | yes
+`wrapping_token` | `bool`   | Whether to [unwrap][] the token. | `false`     | no
+`mount_path`     | `string` | Mount path for the login.        | `"approle"` | no
 
 [AppRole]: https://www.vaultproject.io/docs/auth/approle
 [unwrap]: https://www.vaultproject.io/docs/concepts/response-wrapping
@@ -129,47 +122,41 @@ Name | Type | Description | Default | Required
 
 The `auth.aws` block authenticates to Vault using the [AWS auth method][AWS].
 
-Credentials used to connect to AWS are specified by the environment variables
-`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION`. The
-environment variable `AWS_SHARED_CREDENTIALS_FILE` may be specified to use a
-credentials file instead.
+Credentials used to connect to AWS are specified by the environment variables `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION`.
+The environment variable `AWS_SHARED_CREDENTIALS_FILE` may be specified to use a credentials file instead.
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`type` | `string` | Mechanism to authenticate against AWS with. | | yes
-`region` | `string` | AWS region to connect to. | `"us-east-1"` | no
-`role` | `string` | Overrides the inferred role name inferred. | `""` | no
-`iam_server_id_header` | `string` | Configures a `X-Vault-AWS-IAM-Server-ID` header. | `""` | no
-`ec2_signature_type` | `string` | Signature to use when authenticating against EC2. | `"pkcs7"` | no
-`mount_path` | `string` | Mount path for the login. | `"aws"` | no
+Name                   | Type     | Description                                       | Default       | Required
+-----------------------|----------|---------------------------------------------------|---------------|---------
+`type`                 | `string` | Mechanism to authenticate against AWS with.       |               | yes
+`region`               | `string` | AWS region to connect to.                         | `"us-east-1"` | no
+`role`                 | `string` | Overrides the inferred role name inferred.        | `""`          | no
+`iam_server_id_header` | `string` | Configures a `X-Vault-AWS-IAM-Server-ID` header.  | `""`          | no
+`ec2_signature_type`   | `string` | Signature to use when authenticating against EC2. | `"pkcs7"`     | no
+`mount_path`           | `string` | Mount path for the login.                         | `"aws"`       | no
 
 The `type` argument must be set to one of `"ec2"` or `"iam"`.
 
-The `iam_server_id_header` argument is required used when `type` is set to
-`"iam"`.
+The `iam_server_id_header` argument is required used when `type` is set to `"iam"`.
 
-If the `region` argument is explicitly set to an empty string `""`, the region
-to connect to will be inferred using an API call to the EC2 metadata service.
+If the `region` argument is explicitly set to an empty string `""`, the region to connect to will be inferred using an API call to the EC2 metadata service.
 
-The `ec2_signature_type` argument configures the signature to use when
-authenticating against EC2. It only applies when `type` is set to `"ec2"`.
+The `ec2_signature_type` argument configures the signature to use when authenticating against EC2.
+It only applies when `type` is set to `"ec2"`.
 `ec2_signature_type` must be set to either `"identity"` or `"pkcs7"`.
 
 [AWS]: https://www.vaultproject.io/docs/auth/aws
 
 ### auth.azure block
 
-The `auth.azure` block authenticates to Vault using the [Azure auth
-method][Azure].
+The `auth.azure` block authenticates to Vault using the [Azure auth method][Azure].
 
-Credentials are retrieved for the running Azure VM using Managed Identities for
-Azure Resources.
+Credentials are retrieved for the running Azure VM using Managed Identities for Azure Resources.
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`role` | `string` | Role name to authenticate as. | | yes
-`resource_url` | `string` | Resource URL to include with authentication request. | | no
-`mount_path` | `string` | Mount path for the login. | `"azure"` | no
+Name           | Type     | Description                                          | Default   | Required
+---------------|----------|------------------------------------------------------|-----------|---------
+`role`         | `string` | Role name to authenticate as.                        |           | yes
+`resource_url` | `string` | Resource URL to include with authentication request. |           | no
+`mount_path`   | `string` | Mount path for the login.                            | `"azure"` | no
 
 [Azure]: https://www.vaultproject.io/docs/auth/azure
 
@@ -177,49 +164,43 @@ Name | Type | Description | Default | Required
 
 The `auth.gcp` block authenticates to Vault using the [GCP auth method][GCP].
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`role` | `string` | Role name to authenticate as. | | yes
-`type` | `string` | Mechanism to authenticate against GCP with | | yes
-`iam_service_account` | `string` | IAM service account name to use. | | no
-`mount_path` | `string` | Mount path for the login. | `"gcp"` | no
+Name                  | Type     | Description                                | Default | Required
+----------------------|----------|--------------------------------------------|---------|---------
+`role`                | `string` | Role name to authenticate as.              |         | yes
+`type`                | `string` | Mechanism to authenticate against GCP with |         | yes
+`iam_service_account` | `string` | IAM service account name to use.           |         | no
+`mount_path`          | `string` | Mount path for the login.                  | `"gcp"` | no
 
-The `type` argument must be set to `"gce"` or `"iam"`. When `type` is `"gce"`,
-credentials are retrieved using the metadata service on GCE VMs. When `type` is
-`"iam"`, credentials are retrieved from the file that the
-`GOOGLE_APPLICATION_CREDENTIALS` environment variable points to.
+The `type` argument must be set to `"gce"` or `"iam"`. When `type` is `"gce"`, credentials are retrieved using the metadata service on GCE VMs.
+When `type` is `"iam"`, credentials are retrieved from the file that the `GOOGLE_APPLICATION_CREDENTIALS` environment variable points to.
 
-When `type` is `"iam"`, the `iam_service_account` argument determines what
-service account name to use.
+When `type` is `"iam"`, the `iam_service_account` argument determines what service account name to use.
 
 [GCP]: https://www.vaultproject.io/docs/auth/gcp
 
 ### auth.kubernetes block
 
-The `auth.kubernetes` block authenticates to Vault using the [Kubernetes auth
-method][Kubernetes].
+The `auth.kubernetes` block authenticates to Vault using the [Kubernetes auth method][Kubernetes].
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`role` | `string` | Role name to authenticate as. | | yes
-`service_account_file` | `string` | Override service account token file to use. | | no
-`mount_path` | `string` | Mount path for the login. | `"kubernetes"` | no
+Name                   | Type     | Description                                 | Default        | Required
+-----------------------|----------|---------------------------------------------|----------------|---------
+`role`                 | `string` | Role name to authenticate as.               |                | yes
+`service_account_file` | `string` | Override service account token file to use. |                | no
+`mount_path`           | `string` | Mount path for the login.                   | `"kubernetes"` | no
 
-When `service_account_file` is not specified, the JWT token to authenticate
-with is retrieved from `/var/run/secrets/kubernetes.io/serviceaccount/token`.
+When `service_account_file` is not specified, the JWT token to authenticate with is retrieved from `/var/run/secrets/kubernetes.io/serviceaccount/token`.
 
 [Kubernetes]: https://www.vaultproject.io/docs/auth/kubernetes
 
 ### auth.ldap block
 
-The `auth.ldap` block authenticates to Vault using the [LDAP auth
-method][LDAP].
+The `auth.ldap` block authenticates to Vault using the [LDAP auth method][LDAP].
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`username` | `string` | LDAP username to authenticate as. | | yes
-`password` | `secret` | LDAP passsword for the user. | | yes
-`mount_path` | `string` | Mount path for the login. | `"ldap"` | no
+Name         | Type     | Description                       | Default  | Required
+-------------|----------|-----------------------------------|----------|---------
+`username`   | `string` | LDAP username to authenticate as. |          | yes
+`password`   | `secret` | LDAP passsword for the user.      |          | yes
+`mount_path` | `string` | Mount path for the login.         | `"ldap"` | no
 
 [LDAP]: https://www.vaultproject.io/docs/auth/ldap
 
@@ -228,67 +209,59 @@ Name | Type | Description | Default | Required
 The `auth.userpass` block authenticates to Vault using the [UserPass auth
 method][UserPass].
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`username` | `string` | Username to authenticate as. | | yes
-`password` | `secret` | Passsword for the user. | | yes
-`mount_path` | `string` | Mount path for the login. | `"userpass"` | no
+Name         | Type     | Description                  | Default      | Required
+-------------|----------|------------------------------|--------------|---------
+`username`   | `string` | Username to authenticate as. |              | yes
+`password`   | `secret` | Passsword for the user.      |              | yes
+`mount_path` | `string` | Mount path for the login.    | `"userpass"` | no
 
 [UserPass]: https://www.vaultproject.io/docs/auth/userpass
 
 ### auth.custom block
 
-The `auth.custom` blocks allows authenticating against Vault using an arbitrary
-authentication path like `auth/customservice/login`.
+The `auth.custom` blocks allows authenticating against Vault using an arbitrary authentication path like `auth/customservice/login`.
 
-Using `auth.custom` is equivalent to calling `vault write PATH DATA` on the
-command line.
+Using `auth.custom` is equivalent to calling `vault write PATH DATA` on the command line.
 
-Name | Type | Description | Default | Required
----- | ---- | ----------- | ------- | --------
-`path` | `string` | Path to write to for creating an authentication token. | yes
-`data` | `map(secret)` | Authentication data. | yes
+Name   | Type          | Description                                            | Default | Required
+-------|---------------|--------------------------------------------------------|---------|---------
+`path` | `string`      | Path to write to for creating an authentication token. |         | yes
+`data` | `map(secret)` | Authentication data.                                   |         | yes
 
-All values in the `data` attribute are considered secret, even if they contain
-nonsensitive information like usernames.
+All values in the `data` attribute are considered secret, even if they contain nonsensitive information like usernames.
 
 ## Exported fields
 
 The following fields are exported and can be referenced by other components:
 
-Name | Type | Description
----- | ---- | -----------
+Name   | Type          | Description
+-------|---------------|------------------------------------------
 `data` | `map(secret)` | Data from the secret obtained from Vault.
 
-The `data` field contains a mapping from data field names to values. There will
-be one mapping for each string-like field stored in the Vault secret.
+The `data` field contains a mapping from data field names to values.
+There is one mapping for each string-like field stored in the Vault secret.
 
-Note that Vault permits secret engines to store arbitrary data within the
-key-value pairs for a secret. The `remote.vault` component is only able to use
-values which are strings or can be converted to strings. Keys with non-string
-values will be ignored and omitted from the `data` field.
+Vault permits secret engines to store arbitrary data within the key-value pairs for a secret.
+The `remote.vault` component is only able to use values which are strings or can be converted to strings.
+Keys with non-string values are ignored and omitted from the `data` field.
 
-If an individual key stored in `data` does not hold sensitive data, it can be
-converted into a string using [the `nonsensitive` function][nonsensitive]:
+If an individual key stored in `data` doesn't hold sensitive data, it can be converted into a string using [the `nonsensitive` function][nonsensitive]:
 
 ```alloy
 nonsensitive(remote.vault.LABEL.data.KEY_NAME)
 ```
 
-Using `nonsensitive` allows for using the exports of `remote.vault` for
-attributes in components that do not support secrets.
+Using `nonsensitive` allows for using the exports of `remote.vault` for attributes in components that don't support secrets.
 
 [nonsensitive]: ../../stdlib/nonsensitive/
 
 ## Component health
 
-`remote.vault` will be reported as unhealthy if the latest reread or renewal of
-secrets was unsuccessful.
+`remote.vault` will be reported as unhealthy if the latest reread or renewal of secrets was unsuccessful.
 
 ## Debug information
 
-`remote.vault` exposes debug information for the authentication token and
-secret around:
+`remote.vault` exposes debug information for the authentication token and secret around:
 
 * The latest request ID used for retrieving or renewing the token.
 * The most recent time when the token was retrieved or renewed.
@@ -300,14 +273,10 @@ secret around:
 
 `remote.vault` exposes the following metrics:
 
-* `remote_vault_auth_total` (counter): Total number of times the component
-  authenticated to Vault.
-* `remote_vault_secret_reads_total` (counter): Total number of times the secret
-  was read from Vault.
-* `remote_vault_auth_lease_renewal_total` (counter): Total number of times the
-  component renewed its authentication token lease.
-* `remote_vault_secret_lease_renewal_total` (counter): Total number of times
-  the component renewed its secret token lease.
+* `remote_vault_auth_total` (counter): Total number of times the component authenticated to Vault.
+* `remote_vault_secret_reads_total` (counter): Total number of times the secret was read from Vault.
+* `remote_vault_auth_lease_renewal_total` (counter): Total number of times the component renewed its authentication token lease.
+* `remote_vault_secret_lease_renewal_total` (counter): Total number of times the component renewed its secret token lease.
 
 ## Example
 
diff --git a/docs/sources/tasks/estimate-resource-usage.md b/docs/sources/tasks/estimate-resource-usage.md
index a6e89d1ef8..1a65843fbb 100644
--- a/docs/sources/tasks/estimate-resource-usage.md
+++ b/docs/sources/tasks/estimate-resource-usage.md
@@ -1,5 +1,5 @@
 ---
-canonical: https://grafana.com/docs/alloy/latest/tasks/resource-usage/
+canonical: https://grafana.com/docs/alloy/latest/tasks/estimate-resource-usage/
 description: Estimate expected Grafana Alloy resource usage
 headless: true
 title: Estimate Grafana Alloy resource usage
diff --git a/docs/sources/tasks/metamonitoring.md b/docs/sources/tasks/metamonitoring.md
index 6ffa8da3a9..fc239f0fc9 100644
--- a/docs/sources/tasks/metamonitoring.md
+++ b/docs/sources/tasks/metamonitoring.md
@@ -1,5 +1,5 @@
 ---
-canonical: https://grafana.com/docs/alloy/latest/tasks/setup-metamonitoring/
+canonical: https://grafana.com/docs/alloy/latest/tasks/metamonitoring/
 description: Learn how to set up meta-monitoring for Grafana Alloy
 title: Set up meta-monitoring
 weight: 200

From 35904471e3b6bb8c1f50f872bb7eddeac6b94230 Mon Sep 17 00:00:00 2001
From: Clayton Cornell <clayton.cornell@grafana.com>
Date: Thu, 4 Apr 2024 17:50:08 -0700
Subject: [PATCH 3/4] Update pyroscope sytnax and style

---
 .../reference/components/pyroscope.ebpf.md    | 119 ++++++++----------
 .../reference/components/pyroscope.java.md    |  68 +++++-----
 2 files changed, 84 insertions(+), 103 deletions(-)

diff --git a/docs/sources/reference/components/pyroscope.ebpf.md b/docs/sources/reference/components/pyroscope.ebpf.md
index f6f232d12c..5f728f1d09 100644
--- a/docs/sources/reference/components/pyroscope.ebpf.md
+++ b/docs/sources/reference/components/pyroscope.ebpf.md
@@ -10,15 +10,14 @@ title: pyroscope.ebpf
 
 {{< docs/shared lookup="stability/public_preview.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-`pyroscope.ebpf` configures an ebpf profiling job for the current host. The collected performance profiles are forwarded
-to the list of receivers passed in `forward_to`.
+`pyroscope.ebpf` configures an ebpf profiling job for the current host.
+The collected performance profiles are forwarded to the list of receivers passed in `forward_to`.
 
 {{< admonition type="note" >}}
-To use the  `pyroscope.ebpf` component you must run {{< param "PRODUCT_NAME" >}} as root and inside host pid namespace.
+To use the  `pyroscope.ebpf` component you must run {{< param "PRODUCT_NAME" >}} as root and inside the host PID namespace.
 {{< /admonition >}}
 
-You can specify multiple `pyroscope.ebpf` components by giving them different labels, however it is not recommended as
-it can lead to additional memory and CPU usage.
+You can specify multiple `pyroscope.ebpf` components by giving them different labels, however it's not recommended as it can lead to additional memory and CPU usage.
 
 ## Usage
 
@@ -33,34 +32,32 @@ pyroscope.ebpf "LABEL" {
 
 The component configures and starts a new ebpf profiling job to collect performance profiles from the current host.
 
-You can use the following arguments to configure a `pyroscope.ebpf`. Only the
-`forward_to` and `targets` fields are required. Omitted fields take their default
-values.
-
-| Name                      | Type                     | Description                                                                         | Default | Required |
-|---------------------------|--------------------------|-------------------------------------------------------------------------------------|---------|----------|
-| `targets`                 | `list(map(string))`      | List of targets to group profiles by container id                                   |         | yes      |
-| `forward_to`              | `list(ProfilesReceiver)` | List of receivers to send collected profiles to.                                    |         | yes      |
-| `collect_interval`        | `duration`               | How frequently to collect profiles                                                  | `15s`   | no       |
-| `sample_rate`             | `int`                    | How many times per second to collect profile samples                                | 97      | no       |
-| `pid_cache_size`          | `int`                    | The size of the pid -> proc symbols table LRU cache                                 | 32      | no       |
-| `build_id_cache_size`     | `int`                    | The size of the elf file build id -> symbols table LRU cache                        | 64      | no       |
-| `same_file_cache_size`    | `int`                    | The size of the elf file -> symbols table LRU cache                                 | 8       | no       |
-| `container_id_cache_size` | `int`                    | The size of the pid -> container ID table LRU cache                                 | 1024    | no       |
-| `collect_user_profile`    | `bool`                   | A flag to enable/disable collection of userspace profiles                           | true    | no       |
-| `collect_kernel_profile`  | `bool`                   | A flag to enable/disable collection of kernelspace profiles                         | true    | no       |
-| `demangle`                | `string`                 | C++ demangle mode. Available options are: `none`, `simplified`, `templates`, `full` | `none`  | no       |
-| `python_enabled`          | `bool`                   | A flag to enable/disable python profiling                                           | true    | no       |
+You can use the following arguments to configure a `pyroscope.ebpf`.
+Only the `forward_to` and `targets` fields are required.
+Omitted fields take their default values.
+
+Name                      | Type                     | Description                                                                         | Default | Required
+--------------------------|--------------------------|-------------------------------------------------------------------------------------|---------|---------
+`targets`                 | `list(map(string))`      | List of targets to group profiles by container id                                   |         | yes
+`forward_to`              | `list(ProfilesReceiver)` | List of receivers to send collected profiles to.                                    |         | yes
+`collect_interval`        | `duration`               | How frequently to collect profiles                                                  | `15s`   | no
+`sample_rate`             | `int`                    | How many times per second to collect profile samples                                | 97      | no
+`pid_cache_size`          | `int`                    | The size of the pid -> proc symbols table LRU cache                                 | 32      | no
+`build_id_cache_size`     | `int`                    | The size of the elf file build id -> symbols table LRU cache                        | 64      | no
+`same_file_cache_size`    | `int`                    | The size of the elf file -> symbols table LRU cache                                 | 8       | no
+`container_id_cache_size` | `int`                    | The size of the pid -> container ID table LRU cache                                 | 1024    | no
+`collect_user_profile`    | `bool`                   | A flag to enable/disable collection of userspace profiles                           | true    | no
+`collect_kernel_profile`  | `bool`                   | A flag to enable/disable collection of kernelspace profiles                         | true    | no
+`demangle`                | `string`                 | C++ demangle mode. Available options are: `none`, `simplified`, `templates`, `full` | `none`  | no
+`python_enabled`          | `bool`                   | A flag to enable/disable python profiling                                           | true    | no
 
 ## Exported fields
 
-`pyroscope.ebpf` does not export any fields that can be referenced by other
-components.
+`pyroscope.ebpf` does not export any fields that can be referenced by other components.
 
 ## Component health
 
-`pyroscope.ebpf` is only reported as unhealthy if given an invalid
-configuration.
+`pyroscope.ebpf` is only reported as unhealthy if given an invalid configuration.
 
 ## Debug information
 
@@ -81,16 +78,16 @@ configuration.
 The `pyroscope.ebpf` component collects stack traces associated with a process running on the current host.
 You can use the `sample_rate` argument to define the number of stack traces collected per second. The default is 97.
 
-The following labels are automatically injected into the collected profiles if you have not defined them. These labels
-can help you pin down a profiling target.
+The following labels are automatically injected into the collected profiles if you haven't defined them.
+These labels can help you pin down a profiling target.
 
-| Label              | Description                                                                                                                      |
-|--------------------|----------------------------------------------------------------------------------------------------------------------------------|
-| `service_name`     | Pyroscope service name. It's automatically selected from discovery meta labels if possible. Otherwise defaults to `unspecified`. |
-| `__name__`         | pyroscope metric name. Defaults to `process_cpu`.                                                                                |
-| `__container_id__` | The container ID derived from target.                                                                                            |
+Label              | Description
+-------------------|---------------------------------------------------------------------------------------------------------------------------------
+`service_name`     | Pyroscope service name. It's automatically selected from discovery meta labels if possible. Otherwise defaults to `unspecified`.
+`__name__`         | pyroscope metric name. Defaults to `process_cpu`.
+`__container_id__` | The container ID derived from target.
 
-### Targets 
+### Targets
 
 One of the following special labels _must_ be included in each target of `targets` and the label must correspond to the container or process that is profiled:
 
@@ -99,22 +96,22 @@ One of the following special labels _must_ be included in each target of `target
 * `__meta_kubernetes_pod_container_id`: The ID of the Kubernetes pod container.
 * `__process_pid__` : The process ID.
 
-Each process is then associated with a specified target from the targets list, determined by a container ID or process PID. 
+Each process is then associated with a specified target from the targets list, determined by a container ID or process PID.
 
 If a process's container ID matches a target's container ID label, the stack traces are aggregated per target based on the container ID.
 If a process's PID matches a target's process PID label, the stack traces are aggregated per target based on the process PID.
-Otherwise the process is not profiled.
+Otherwise the process isn't profiled.
 
 ### Service name
 
-The special label `service_name` is required and must always be present. If it's not specified, it is
-attempted to be inferred from multiple sources:
+The special label `service_name` is required and must always be present.
+If it's not specified, it's attempted to be inferred from multiple sources:
 
 - `__meta_kubernetes_pod_annotation_pyroscope_io_service_name` which is a `pyroscope.io/service_name` pod annotation.
 - `__meta_kubernetes_namespace` and `__meta_kubernetes_pod_container_name`
 - `__meta_docker_container_name`
 
-If `service_name` is not specified and could not be inferred, it is set to `unspecified`.
+If `service_name` isn't specified and couldn't be inferred, it's set to `unspecified`.
 
 ## Troubleshooting unknown symbols
 
@@ -125,9 +122,8 @@ Symbols are extracted from various sources, including:
 - The `.gopclntab` section in Go language ELF files.
 
 The search for debug files follows [gdb algorithm](https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html).
-For example, if the profiler wants to find the debug file
-for `/lib/x86_64-linux-gnu/libc.so.6`
-with a `.gnu_debuglink` set to `libc.so.6.debug` and a build ID `0123456789abcdef`. The following paths are examined:
+For example, if the profiler wants to find the debug file for `/lib/x86_64-linux-gnu/libc.so.6` with a `.gnu_debuglink` set to `libc.so.6.debug` and a build ID `0123456789abcdef`.
+The following paths are examined:
 
 - `/usr/lib/debug/.build-id/01/0123456789abcdef.debug`
 - `/lib/x86_64-linux-gnu/libc.so.6.debug`
@@ -136,8 +132,7 @@ with a `.gnu_debuglink` set to `libc.so.6.debug` and a build ID `0123456789abcde
 
 ### Dealing with unknown symbols
 
-Unknown symbols in the profiles you’ve collected indicate that the profiler couldn't access an ELF file associated with
-a given address in the trace.
+Unknown symbols in the profiles you’ve collected indicate that the profiler couldn't access an ELF file associated with a given address in the trace.
 
 This can occur for several reasons:
 
@@ -147,16 +142,15 @@ This can occur for several reasons:
 
 ### Addressing unresolved symbols
 
-If you only see module names (e.g., `/lib/x86_64-linux-gnu/libc.so.6`) without corresponding function names, this
-indicates that the symbols couldn't be mapped to their respective function names.
+If you only see module names (e.g., `/lib/x86_64-linux-gnu/libc.so.6`) without corresponding function names, this indicates that the symbols couldn't be mapped to their respective function names.
 
 This can occur for several reasons:
 
 - The binary has been stripped, leaving no .symtab, .dynsym, or .gopclntab sections in the ELF file.
 - The debug file is missing or could not be located.
 
-To fix this for your binaries, ensure that they are either not stripped or that you have separate
-debug files available. You can achieve this by running:
+To fix this for your binaries, ensure that they are either not stripped or that you have separate debug files available.
+You can achieve this by running:
 
 ```bash
 objcopy --only-keep-debug elf elf.debug
@@ -164,8 +158,8 @@ strip elf -o elf.stripped
 objcopy --add-gnu-debuglink=elf.debug elf.stripped elf.debuglink
 ```
 
-For system libraries, ensure that debug symbols are installed. On Ubuntu, for example, you can install debug symbols
-for `libc` by executing:
+For system libraries, ensure that debug symbols are installed.
+On Ubuntu, for example, you can install debug symbols for `libc` by executing:
 
 ```bash
 apt install libc6-dbg
@@ -173,16 +167,15 @@ apt install libc6-dbg
 
 ### Understanding flat stack traces
 
-If your profiles show many shallow stack traces, typically 1-2 frames deep, your binary might have been compiled without
-frame pointers.
+If your profiles show many shallow stack traces, typically 1-2 frames deep, your binary might have been compiled without frame pointers.
 
 To compile your code with frame pointers, include the `-fno-omit-frame-pointer` flag in your compiler options.
 
 ### Profiling interpreted languages
 
-Profiling interpreted languages like Python, Ruby, JavaScript, etc., is not ideal using this implementation.
-The JIT-compiled methods in these languages are typically not in ELF file format, demanding additional steps for
-profiling. For instance, using perf-map-agent and enabling frame pointers for Java.
+Profiling interpreted languages like Python, Ruby, JavaScript, etc., isn't ideal using this implementation.
+The JIT-compiled methods in these languages are typically not in ELF file format, demanding additional steps for profiling.
+For instance, using perf-map-agent and enabling frame pointers for Java.
 
 Interpreted methods will display the interpreter function’s name rather than the actual function.
 
@@ -190,10 +183,9 @@ Interpreted methods will display the interpreter function’s name rather than t
 
 ### Kubernetes discovery
 
-In the following example, performance profiles are collected from pods on the same node, discovered using
-`discovery.kubernetes`. Pod selection relies on the `HOSTNAME` environment variable, which is a pod name if {{< param "PRODUCT_NAME" >}} is
-used as an {{< param "PRODUCT_NAME" >}} Helm chart. The `service_name` label is set
-to `{__meta_kubernetes_namespace}/{__meta_kubernetes_pod_container_name}` from Kubernetes meta labels.
+In the following example, performance profiles are collected from pods on the same node, discovered using `discovery.kubernetes`.
+Pod selection relies on the `HOSTNAME` environment variable, which is a pod name if {{< param "PRODUCT_NAME" >}} is used as an {{< param "PRODUCT_NAME" >}} Helm chart.
+The `service_name` label is set to `{__meta_kubernetes_namespace}/{__meta_kubernetes_pod_container_name}` from Kubernetes meta labels.
 
 ```alloy
 discovery.kubernetes "all_pods" {
@@ -258,9 +250,8 @@ pyroscope.write "endpoint" {
 
 ### Docker discovery
 
-The following example collects performance profiles from containers discovered by `discovery.docker` and ignores all
-other profiles collected from outside any docker container. The `service_name` label is set to the
-`__meta_docker_container_name` label.
+The following example collects performance profiles from containers discovered by `discovery.docker` and ignores all other profiles collected from outside any docker container.
+The `service_name` label is set to the `__meta_docker_container_name` label.
 
 ```alloy
 discovery.docker "linux" {
@@ -282,7 +273,7 @@ pyroscope.write "staging" {
   }
 }
 
-pyroscope.ebpf "default" {  
+pyroscope.ebpf "default" {
   forward_to   = [ pyroscope.write.staging.receiver ]
   targets      = discovery.relabel.local_containers.output
 }
diff --git a/docs/sources/reference/components/pyroscope.java.md b/docs/sources/reference/components/pyroscope.java.md
index f409f937de..b006e3f317 100644
--- a/docs/sources/reference/components/pyroscope.java.md
+++ b/docs/sources/reference/components/pyroscope.java.md
@@ -8,8 +8,7 @@ title: pyroscope.java
 
 {{< docs/shared lookup="stability/public_preview.md" source="alloy" version="<ALLOY_VERSION>" >}}
 
-`pyroscope.java` continuously profiles Java processes running on the local Linux OS
-using [async-profiler](https://github.com/async-profiler/async-profiler).
+`pyroscope.java` continuously profiles Java processes running on the local Linux OS using [async-profiler](https://github.com/async-profiler/async-profiler).
 
 {{< admonition type="note" >}}
 To use the  `pyroscope.java` component you must run {{< param "PRODUCT_NAME" >}} as root and inside host PID namespace.
@@ -28,19 +27,17 @@ pyroscope.java "LABEL" {
 
 The following arguments are supported:
 
-| Name         | Type                     | Description                                      | Default | Required |
-|--------------|--------------------------|--------------------------------------------------|---------|----------|
-| `targets`    | `list(map(string))`      | List of java process targets to profile.         |         | yes      |
-| `forward_to` | `list(ProfilesReceiver)` | List of receivers to send collected profiles to. |         | yes      |
-| `tmp_dir`    | `string`                 | Temporary directory to store async-profiler.      | `/tmp`  | no       |
+Name         | Type                     | Description                                      | Default | Required
+-------------|--------------------------|--------------------------------------------------|---------|---------
+`targets`    | `list(map(string))`      | List of java process targets to profile.         |         | yes
+`forward_to` | `list(ProfilesReceiver)` | List of receivers to send collected profiles to. |         | yes
+`tmp_dir`    | `string`                 | Temporary directory to store async-profiler.     | `/tmp`  | no
 
 ## Profiling behavior
 
-The special label `__process_pid__` _must always_ be present in each target of `targets` and corresponds to the `PID` of
-the process to profile.
+The special label `__process_pid__` _must always_ be present in each target of `targets` and corresponds to the `PID` of the process to profile.
 
-After component startup, `pyroscope.java` creates a temporary directory under `tmp_dir` and extracts the
-async-profiler binaries for both glibc and musl into the directory with the following layout.
+After component startup, `pyroscope.java` creates a temporary directory under `tmp_dir` and extracts the async-profiler binaries for both glibc and musl into the directory with the following layout.
 
 ```
 /tmp/alloy-asprof-glibc-{SHA1}/bin/asprof
@@ -49,40 +46,35 @@ async-profiler binaries for both glibc and musl into the directory with the foll
 /tmp/alloy-asprof-musl-{SHA1}/lib/libasyncProfiler.so
 ```
 
-After process profiling startup, the component detects libc type and copies according `libAsyncProfiler.so` into the
-target process file system at the exact same path.
+After process profiling startup, the component detects libc type and copies according `libAsyncProfiler.so` into the target process file system at the exact same path.
 
 {{< admonition type="note" >}}
 The `asprof` binary runs with root permissions.
-If you change the `tmp_dir` configuration to something other than `/tmp`, then you must ensure that the
-directory is only writable by root.
+If you change the `tmp_dir` configuration to something other than `/tmp`, then you must ensure that the directory is only writable by root.
 {{< /admonition >}}
 
 #### `targets` argument
 
-The special `__process_pid__` label _must always_ be present and corresponds to the
-process PID that is used for profiling.
+The special `__process_pid__` label _must always_ be present and corresponds to the process PID that is used for profiling.
 
 Labels starting with a double underscore (`__`) are treated as _internal_, and are removed prior to scraping.
 
 The special label `service_name` is required and must always be present.
-If it is not specified, `pyroscope.scrape` will attempt to infer it from
-either of the following sources, in this order:
+If it is not specified, `pyroscope.scrape` will attempt to infer it from either of the following sources, in this order:
 1. `__meta_kubernetes_pod_annotation_pyroscope_io_service_name` which is a `pyroscope.io/service_name` pod annotation.
 2. `__meta_kubernetes_namespace` and `__meta_kubernetes_pod_container_name`
 3. `__meta_docker_container_name`
 4. `__meta_dockerswarm_container_label_service_name` or `__meta_dockerswarm_service_name`
 
-If `service_name` is not specified and could not be inferred, then it is set to `unspecified`.
+If `service_name` isn't specified and couldn't be inferred, then it's set to `unspecified`.
 
 ## Blocks
 
-The following blocks are supported inside the definition of
-`pyroscope.java`:
+The following blocks are supported inside the definition of `pyroscope.java`:
 
-| Hierarchy        | Block                | Description                            | Required |
-|------------------|----------------------|----------------------------------------|----------|
-| profiling_config | [profiling_config][] | Describes java profiling configuration. | no       |
+Hierarchy        | Block                | Description                             | Required
+-----------------|----------------------|-----------------------------------------|---------
+profiling_config | [profiling_config][] | Describes java profiling configuration. | no
 
 [profiling_config]: #profiling_config-block
 
@@ -92,34 +84,32 @@ The `profiling_config` block describes how async-profiler is invoked.
 
 The following arguments are supported:
 
-| Name          | Type       | Description                                                                                             | Default | Required |
-|---------------|------------|---------------------------------------------------------------------------------------------------------|---------|----------|
-| `interval`    | `duration` | How frequently to collect profiles from the targets.                                                    | "60s"   | no       |
-| `cpu`         | `bool`     | A flag to enable cpu profiling, using `itimer` async-profiler event.                                    | true    | no       |
-| `sample_rate` | `int`      | CPU profiling sample rate. It is converted from Hz to interval and passed as `-i` arg to async-profiler. | 100     | no       |
-| `alloc`       | `string`   | Allocation profiling sampling configuration  It is passed as `--alloc` arg to async-profiler.            | "512k"  | no       |
-| `lock`        | `string`   | Lock profiling sampling configuration. It is passed as `--lock` arg to async-profiler.                   | "10ms"  | no       |
+Name          | Type       | Description                                                                                              | Default | Required
+--------------|------------|----------------------------------------------------------------------------------------------------------|---------|---------
+`interval`    | `duration` | How frequently to collect profiles from the targets.                                                     | "60s"   | no
+`cpu`         | `bool`     | A flag to enable cpu profiling, using `itimer` async-profiler event.                                     | true    | no
+`sample_rate` | `int`      | CPU profiling sample rate. It is converted from Hz to interval and passed as `-i` arg to async-profiler. | 100     | no
+`alloc`       | `string`   | Allocation profiling sampling configuration  It is passed as `--alloc` arg to async-profiler.            | "512k"  | no
+`lock`        | `string`   | Lock profiling sampling configuration. It is passed as `--lock` arg to async-profiler.                   | "10ms"  | no
 
 For more information on async-profiler configuration, see [profiler-options](https://github.com/async-profiler/async-profiler?tab=readme-ov-file#profiler-options)
 
 ## Exported fields
 
-`pyroscope.java` does not export any fields that can be referenced by other
-components.
+`pyroscope.java` doesn't export any fields that can be referenced by other components.
 
 ## Component health
 
-`pyroscope.java` is only reported as unhealthy when given an invalid
-configuration. In those cases, exported fields retain their last healthy
-values.
+`pyroscope.java` is only reported as unhealthy when given an invalid configuration.
+In those cases, exported fields retain their last healthy values.
 
 ## Debug information
 
-`pyroscope.java` does not expose any component-specific debug information.
+`pyroscope.java` doesn't expose any component-specific debug information.
 
 ## Debug metrics
 
-`pyroscope.java` does not expose any component-specific debug metrics.
+`pyroscope.java` doesn't expose any component-specific debug metrics.
 
 ## Examples
 

From 2838e99d26ef4c0785d47f4ec4c3a6b8fe9a4600 Mon Sep 17 00:00:00 2001
From: Clayton Cornell <clayton.cornell@grafana.com>
Date: Fri, 5 Apr 2024 10:57:50 -0700
Subject: [PATCH 4/4] Fix and clarify main page

---
 docs/sources/_index.md   | 4 ++--
 docs/sources/_index.md.t | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/sources/_index.md b/docs/sources/_index.md
index 3cb95c69fc..e164515259 100644
--- a/docs/sources/_index.md
+++ b/docs/sources/_index.md
@@ -64,8 +64,8 @@ Some of these features include:
 * **Clustering support:** {{< param "PRODUCT_NAME" >}} has native clustering support.
   Clustering helps distribute the workload and ensures you have high availability.
   You can quickly create horizontally scalable deployments with minimal resource and operational overhead.
-* **Security:** {{< param "PRODUCT_NAME" >}} helps you manage authentication credentials and connect to HashiCorp Vaults or Kubernetes clusters to retrieve secrets.
-* **Debugging utilities:** {{< param "PRODUCT_NAME" >}} provides troubleshooting support and an embedded [user interface][UI] to help you identify and resolve configuration problems.
+* **Security:** {{< param "PRODUCT_NAME" >}} helps you manage authentication credentials and connect to HashiCorp Vault servers or Kubernetes clusters to retrieve Kubernetes secrets.
+* **Debugging utilities:** {{< param "PRODUCT_NAME" >}} provides debugging tools such as an embedded [user interface][UI] to help you identify and resolve configuration problems.
 
 ## Explore
 
diff --git a/docs/sources/_index.md.t b/docs/sources/_index.md.t
index bd3be5443f..1dd7bd6117 100644
--- a/docs/sources/_index.md.t
+++ b/docs/sources/_index.md.t
@@ -64,8 +64,8 @@ Some of these features include:
 * **Clustering support:** {{< param "PRODUCT_NAME" >}} has native clustering support.
   Clustering helps distribute the workload and ensures you have high availability.
   You can quickly create horizontally scalable deployments with minimal resource and operational overhead.
-* **Security:** {{< param "PRODUCT_NAME" >}} helps you manage authentication credentials and connect to HashiCorp Vaults or Kubernetes clusters to retrieve secrets.
-* **Debugging utilities:** {{< param "PRODUCT_NAME" >}} provides troubleshooting support and an embedded [user interface][UI] to help you identify and resolve configuration problems.
+* **Security:** {{< param "PRODUCT_NAME" >}} helps you manage authentication credentials and connect to HashiCorp Vault servers or Kubernetes clusters to retrieve Kubernetes secrets.
+* **Debugging utilities:** {{< param "PRODUCT_NAME" >}} provides debugging tools such as an embedded [user interface][UI] to help you identify and resolve configuration problems.
 
 ## Explore