From e3ec7fbf91d24575ccdc3474a7406d98533a5408 Mon Sep 17 00:00:00 2001 From: Clayton Cornell <131809008+clayton-cornell@users.noreply.github.com> Date: Thu, 28 Mar 2024 11:55:55 -0700 Subject: [PATCH] Edit and update Alloy content (#98) * Initial cleanup of Introduction topic * Replace river sytnax highlighting with alloy syntax highlighting * Remove a few instances of agent * Restore BoringCrypto as it's tracked in another PR --- docs/sources/_index.md | 2 +- docs/sources/_index.md.t | 2 +- docs/sources/about.md | 110 ++++-------------- docs/sources/concepts/clustering.md | 2 +- docs/sources/concepts/component_controller.md | 6 +- docs/sources/concepts/components.md | 6 +- .../concepts/configuration-syntax/_index.md | 11 +- .../configuration-syntax/components.md | 6 +- .../expressions/function_calls.md | 2 +- .../expressions/operators.md | 4 +- .../expressions/referencing_exports.md | 2 +- .../expressions/types_and_values.md | 20 ++-- .../concepts/configuration-syntax/syntax.md | 8 +- docs/sources/concepts/custom_components.md | 2 +- docs/sources/concepts/modules.md | 4 +- docs/sources/get-started/install/docker.md | 2 +- .../reference/components/discovery.azure.md | 4 +- .../reference/components/discovery.consul.md | 4 +- .../components/discovery.consulagent.md | 4 +- .../components/discovery.digitalocean.md | 4 +- .../reference/components/discovery.dns.md | 4 +- .../reference/components/discovery.docker.md | 6 +- .../components/discovery.dockerswarm.md | 4 +- .../reference/components/discovery.ec2.md | 4 +- .../reference/components/discovery.eureka.md | 4 +- .../reference/components/discovery.file.md | 6 +- .../reference/components/discovery.gce.md | 4 +- .../reference/components/discovery.hetzner.md | 4 +- .../reference/components/discovery.http.md | 4 +- .../reference/components/discovery.ionos.md | 4 +- .../reference/components/discovery.kubelet.md | 6 +- .../components/discovery.kubernetes.md | 10 +- .../reference/components/discovery.kuma.md | 4 +- .../components/discovery.lightsail.md | 4 +- .../reference/components/discovery.linode.md | 4 +- .../components/discovery.marathon.md | 4 +- .../reference/components/discovery.nerve.md | 4 +- .../reference/components/discovery.nomad.md | 4 +- .../components/discovery.openstack.md | 4 +- .../components/discovery.ovhcloud.md | 4 +- .../reference/components/discovery.process.md | 6 +- .../components/discovery.puppetdb.md | 4 +- .../reference/components/discovery.relabel.md | 4 +- .../components/discovery.scaleway.md | 4 +- .../components/discovery.serverset.md | 4 +- .../reference/components/discovery.triton.md | 4 +- .../reference/components/discovery.uyuni.md | 4 +- .../reference/components/faro.receiver.md | 4 +- .../reference/components/local.file.md | 4 +- .../reference/components/local.file_match.md | 6 +- .../sources/reference/components/loki.echo.md | 4 +- .../reference/components/loki.process.md | 70 +++++------ .../reference/components/loki.relabel.md | 4 +- .../components/loki.rules.kubernetes.md | 6 +- .../reference/components/loki.source.api.md | 4 +- .../components/loki.source.awsfirehose.md | 6 +- .../loki.source.azure_event_hubs.md | 4 +- .../components/loki.source.cloudflare.md | 4 +- .../components/loki.source.docker.md | 4 +- .../reference/components/loki.source.file.md | 8 +- .../components/loki.source.gcplog.md | 6 +- .../reference/components/loki.source.gelf.md | 4 +- .../components/loki.source.heroku.md | 6 +- .../components/loki.source.journal.md | 4 +- .../reference/components/loki.source.kafka.md | 4 +- .../components/loki.source.kubernetes.md | 4 +- .../loki.source.kubernetes_events.md | 4 +- .../components/loki.source.podlogs.md | 4 +- .../components/loki.source.syslog.md | 4 +- .../components/loki.source.windowsevent.md | 4 +- .../reference/components/loki.write.md | 6 +- .../components/mimir.rules.kubernetes.md | 6 +- .../components/otelcol.auth.basic.md | 4 +- .../components/otelcol.auth.bearer.md | 6 +- .../components/otelcol.auth.headers.md | 4 +- .../components/otelcol.auth.oauth2.md | 6 +- .../components/otelcol.auth.sigv4.md | 10 +- .../components/otelcol.connector.host_info.md | 4 +- .../otelcol.connector.servicegraph.md | 4 +- .../components/otelcol.connector.spanlogs.md | 4 +- .../otelcol.connector.spanmetrics.md | 8 +- .../otelcol.exporter.loadbalancing.md | 8 +- .../components/otelcol.exporter.logging.md | 4 +- .../components/otelcol.exporter.loki.md | 6 +- .../components/otelcol.exporter.otlp.md | 6 +- .../components/otelcol.exporter.otlphttp.md | 4 +- .../components/otelcol.exporter.prometheus.md | 6 +- ...telcol.extension.jaeger_remote_sampling.md | 6 +- .../otelcol.processor.attributes.md | 22 ++-- .../components/otelcol.processor.batch.md | 8 +- .../components/otelcol.processor.discovery.md | 8 +- .../components/otelcol.processor.filter.md | 8 +- .../otelcol.processor.k8sattributes.md | 10 +- .../otelcol.processor.memory_limiter.md | 2 +- ...otelcol.processor.probabilistic_sampler.md | 10 +- .../otelcol.processor.resourcedetection.md | 14 +-- .../components/otelcol.processor.span.md | 14 +-- .../otelcol.processor.tail_sampling.md | 4 +- .../components/otelcol.processor.transform.md | 20 ++-- .../components/otelcol.receiver.jaeger.md | 4 +- .../components/otelcol.receiver.kafka.md | 4 +- .../components/otelcol.receiver.loki.md | 4 +- .../components/otelcol.receiver.opencensus.md | 4 +- .../components/otelcol.receiver.otlp.md | 4 +- .../components/otelcol.receiver.prometheus.md | 4 +- .../components/otelcol.receiver.vcenter.md | 4 +- .../components/otelcol.receiver.zipkin.md | 4 +- .../components/prometheus.exporter.apache.md | 4 +- .../components/prometheus.exporter.azure.md | 4 +- .../prometheus.exporter.blackbox.md | 6 +- .../prometheus.exporter.cadvisor.md | 4 +- .../prometheus.exporter.cloudwatch.md | 8 +- .../components/prometheus.exporter.consul.md | 4 +- .../components/prometheus.exporter.dnsmasq.md | 4 +- .../prometheus.exporter.elasticsearch.md | 4 +- .../components/prometheus.exporter.gcp.md | 8 +- .../components/prometheus.exporter.github.md | 4 +- .../components/prometheus.exporter.kafka.md | 4 +- .../prometheus.exporter.memcached.md | 4 +- .../components/prometheus.exporter.mongodb.md | 4 +- .../components/prometheus.exporter.mssql.md | 4 +- .../components/prometheus.exporter.mysql.md | 4 +- .../prometheus.exporter.oracledb.md | 4 +- .../prometheus.exporter.postgres.md | 8 +- .../components/prometheus.exporter.process.md | 4 +- .../components/prometheus.exporter.redis.md | 4 +- .../components/prometheus.exporter.self.md | 4 +- .../components/prometheus.exporter.snmp.md | 6 +- .../prometheus.exporter.snowflake.md | 4 +- .../components/prometheus.exporter.squid.md | 4 +- .../components/prometheus.exporter.statsd.md | 4 +- .../components/prometheus.exporter.unix.md | 4 +- .../components/prometheus.exporter.windows.md | 4 +- .../prometheus.operator.podmonitors.md | 8 +- .../components/prometheus.operator.probes.md | 8 +- .../prometheus.operator.servicemonitors.md | 8 +- .../components/prometheus.receive_http.md | 6 +- .../components/prometheus.relabel.md | 4 +- .../components/prometheus.remote_write.md | 8 +- .../reference/components/prometheus.scrape.md | 2 +- .../reference/components/pyroscope.ebpf.md | 6 +- .../reference/components/pyroscope.java.md | 4 +- .../reference/components/pyroscope.scrape.md | 12 +- .../reference/components/pyroscope.write.md | 4 +- .../reference/components/remote.http.md | 4 +- .../components/remote.kubernetes.configmap.md | 4 +- .../components/remote.kubernetes.secret.md | 6 +- .../sources/reference/components/remote.s3.md | 4 +- .../reference/components/remote.vault.md | 6 +- .../reference/config-blocks/argument.md | 4 +- .../reference/config-blocks/declare.md | 4 +- .../sources/reference/config-blocks/export.md | 4 +- docs/sources/reference/config-blocks/http.md | 2 +- .../reference/config-blocks/import.file.md | 6 +- .../reference/config-blocks/import.git.md | 6 +- .../reference/config-blocks/import.http.md | 6 +- .../reference/config-blocks/import.string.md | 4 +- .../reference/config-blocks/logging.md | 2 +- .../reference/config-blocks/remotecfg.md | 2 +- .../reference/config-blocks/tracing.md | 2 +- docs/sources/reference/stdlib/format.md | 4 +- docs/sources/reference/stdlib/join.md | 4 +- docs/sources/reference/stdlib/replace.md | 4 +- docs/sources/reference/stdlib/split.md | 4 +- docs/sources/reference/stdlib/to_lower.md | 2 +- docs/sources/reference/stdlib/to_upper.md | 2 +- docs/sources/reference/stdlib/trim.md | 4 +- docs/sources/reference/stdlib/trim_prefix.md | 2 +- docs/sources/reference/stdlib/trim_space.md | 2 +- docs/sources/reference/stdlib/trim_suffix.md | 2 +- .../components/extract-field-block.md | 2 +- .../tasks/collect-opentelemetry-data.md | 20 ++-- .../tasks/collect-prometheus-metrics.md | 34 +++--- .../tasks/configure/configure-kubernetes.md | 2 +- .../distribute-prometheus-scrape-load.md | 2 +- docs/sources/tasks/metamonitoring.md | 14 +-- docs/sources/tasks/migrate/from-operator.md | 4 +- docs/sources/tasks/migrate/from-prometheus.md | 2 +- docs/sources/tasks/migrate/from-promtail.md | 2 +- docs/sources/tasks/migrate/from-static.md | 2 +- .../tasks/opentelemetry-to-lgtm-stack.md | 16 +-- docs/sources/tutorials/chaining.md | 2 +- .../collecting-prometheus-metrics.md | 4 +- .../first-components-and-stdlib/index.md | 10 +- .../logs-and-relabeling-basics/index.md | 10 +- .../flow-by-example/processing-logs/index.md | 18 +-- 186 files changed, 560 insertions(+), 623 deletions(-) diff --git a/docs/sources/_index.md b/docs/sources/_index.md index a49b107d68..f713f65827 100644 --- a/docs/sources/_index.md +++ b/docs/sources/_index.md @@ -10,7 +10,7 @@ cascade: PRODUCT_NAME: Alloy --- -# {{% param "PRODUCT_NAME" %}} +# {{% param "FULL_PRODUCT_NAME" %}} {{< param "FULL_PRODUCT_NAME" >}} is a vendor-neutral distribution of the [OpenTelemetry][] (OTel) Collector. {{< param "PRODUCT_NAME" >}} uniquely combines the very best OSS observability signals in the community. diff --git a/docs/sources/_index.md.t b/docs/sources/_index.md.t index 93b418161d..6a864b9ec2 100644 --- a/docs/sources/_index.md.t +++ b/docs/sources/_index.md.t @@ -10,7 +10,7 @@ cascade: PRODUCT_NAME: Alloy --- -# {{% param "PRODUCT_NAME" %}} +# {{% param "FULL_PRODUCT_NAME" %}} {{< param "FULL_PRODUCT_NAME" >}} is a vendor-neutral distribution of the [OpenTelemetry][] (OTel) Collector. {{< param "PRODUCT_NAME" >}} uniquely combines the very best OSS observability signals in the community. diff --git a/docs/sources/about.md b/docs/sources/about.md index 02a73e5d2c..80c43d208d 100644 --- a/docs/sources/about.md +++ b/docs/sources/about.md @@ -6,12 +6,11 @@ title: Introduction to Alloy weight: 10 --- -# Introduction to {{% param "PRODUCT_NAME" %}} +# Introduction to {{% param "FULL_PRODUCT_NAME" %}} {{< param "PRODUCT_NAME" >}} is a flexible, high performance, vendor-neutral telemetry collector. It's fully compatible with the most popular open source observability standards such as OpenTelemetry (OTel) and Prometheus. -{{< param "PRODUCT_NAME" >}} is a _component-based_ revision of {{< param "PRODUCT_NAME" >}} with a focus on ease-of-use, -debuggability, and ability to adapt to the needs of power users. +{{< param "PRODUCT_NAME" >}} focuses on ease-of-use, debuggability, and ability to adapt to the needs of power users. Components allow for reusability, composability, and focus on a single task. @@ -28,7 +27,7 @@ Components allow for reusability, composability, and focus on a single task. ## Example -```river +```alloy // Discover Kubernetes pods to collect metrics from discovery.kubernetes "pods" { role = "pod" @@ -76,110 +75,50 @@ This feature is experimental, and it doesn't support all {{< param "PRODUCT_NAME * Consult the [Tasks][] instructions to accomplish common objectives with {{< param "PRODUCT_NAME" >}}. * Check out the [Reference][] documentation to find specific information you might be looking for. -[configuration generator]: https://grafana.github.io/agent-configurator/ +[configuration generator]: https://grafana.github.io/alloy-configurator/ [Install]: ../get-started/install/ [Concepts]: ../concepts/ [Tasks]: ../tasks/ [Tutorials]: ../tutorials/ [Reference]: ../reference/ - ### BoringCrypto [BoringCrypto][] is an **EXPERIMENTAL** feature for building {{< param "PRODUCT_NAME" >}} diff --git a/docs/sources/concepts/clustering.md b/docs/sources/concepts/clustering.md index 231cdd2d08..a35e2eeefb 100644 --- a/docs/sources/concepts/clustering.md +++ b/docs/sources/concepts/clustering.md @@ -28,7 +28,7 @@ Target auto-distribution requires that all {{< param "PRODUCT_NAME" >}} in the s You must explicitly enable target auto-distribution on components by defining a `clustering` block. -```river +```alloy prometheus.scrape "default" { clustering { enabled = true diff --git a/docs/sources/concepts/component_controller.md b/docs/sources/concepts/component_controller.md index b1474bbe23..7483ff9c3f 100644 --- a/docs/sources/concepts/component_controller.md +++ b/docs/sources/concepts/component_controller.md @@ -25,14 +25,14 @@ which informs the component controller which references are valid and in what or For a configuration file to be valid, components must not reference themselves or contain a cyclic reference. -```river +```alloy // INVALID: local.file.some_file can not reference itself: local.file "self_reference" { filename = local.file.self_reference.content } ``` -```river +```alloy // INVALID: cyclic reference between local.file.a and local.file.b: local.file "a" { filename = local.file.b.content @@ -94,7 +94,7 @@ If your `local.file` component, which watches API keys, suddenly stops working, Components that expose HTTP endpoints, such as [prometheus.exporter.unix][], can expose an internal address that completely bypasses the network and communicate in-memory. Components within the same process can communicate with one another without needing to be aware of any network-level protections such as authentication or mutual TLS. -The internal address defaults to `agent.internal:12345`. +The internal address defaults to `alloy.internal:12345`. If this address collides with a real target on your network, change it to something unique using the `--server.http.memory-addr` flag in the [run][] command. Components must opt-in to using in-memory traffic. diff --git a/docs/sources/concepts/components.md b/docs/sources/concepts/components.md index 88b9ce223d..5874a59051 100644 --- a/docs/sources/concepts/components.md +++ b/docs/sources/concepts/components.md @@ -21,7 +21,7 @@ For example, the `local.file` component is responsible for retrieving the conten You specify components in the configuration file by first providing the component's name with a user-specified label, and then by giving arguments to configure the component. -```river +```alloy discovery.kubernetes "pods" { role = "pod" } @@ -41,7 +41,7 @@ Combining component names with a label means you can define multiple instances o Most arguments for a component in a configuration file are constant values, such as setting a `log_level` attribute to the quoted string `"debug"`. -```river +```alloy log_level = "debug" ``` @@ -66,7 +66,7 @@ An example pipeline may look like this: The following configuration file represents the pipeline. -```river +```alloy // Get our API key from disk. // // This component has an exported field called "content", holding the content diff --git a/docs/sources/concepts/configuration-syntax/_index.md b/docs/sources/concepts/configuration-syntax/_index.md index 59fb3c4610..5f11fc96a8 100644 --- a/docs/sources/concepts/configuration-syntax/_index.md +++ b/docs/sources/concepts/configuration-syntax/_index.md @@ -17,7 +17,7 @@ An {{< param "PRODUCT_NAME" >}} configuration file tells {{< param "PRODUCT_NAME The {{< param "PRODUCT_NAME" >}} syntax uses blocks, attributes, and expressions. -```river +```alloy // Create a local.file component labeled my_file. // This can be referenced by other components as local.file.my_file. local.file "my_file" { @@ -37,7 +37,7 @@ BLOCK_NAME { } ``` -[{{< param "PRODUCT_NAME" >}} is designed][RFC] with the following requirements in mind: +{{< param "PRODUCT_NAME" >}} is designed with the following requirements in mind: * _Fast_: The configuration language must be fast so the component controller can quickly evaluate changes. * _Simple_: The configuration language must be easy to read and write to minimize the learning curve. @@ -62,7 +62,7 @@ Attributes always take the form of `ATTRIBUTE_NAME = ATTRIBUTE_VALUE`. The following example shows how to set the `log_level` attribute to `"debug"`. -```river +```alloy log_level = "debug" ``` @@ -90,7 +90,7 @@ label (for example, `password_file`), and export name (for example, `content`), You use _Blocks_ to configure components and groups of attributes. Each block can contain any number of attributes or nested blocks. -```river +```alloy prometheus.remote_write "default" { endpoint { url = "http://localhost:9009/api/prom/push" @@ -113,7 +113,6 @@ You can use one or all of the following tools to help you write {{< param "PRODU * Editor support for: * [VSCode](https://github.com/grafana/vscode-alloy) * [Vim/Neovim](https://github.com/grafana/vim-alloy) -* Code formatting using the [`agent fmt` command][fmt] +* Code formatting using the [`alloy fmt` command][fmt] -[RFC]: https://github.com/grafana/agent/blob/97a55d0d908b26dbb1126cc08b6dcc18f6e30087/docs/rfcs/0005-river.md [fmt]: ../../reference/cli/fmt/ diff --git a/docs/sources/concepts/configuration-syntax/components.md b/docs/sources/concepts/configuration-syntax/components.md index e6743e8aeb..05a5797852 100644 --- a/docs/sources/concepts/configuration-syntax/components.md +++ b/docs/sources/concepts/configuration-syntax/components.md @@ -34,10 +34,10 @@ The `filename` attribute is a _required_ argument. You can also define a number of _optional_ arguments, in this case, `detector`, `poll_frequency`, and `is_secret`, that configure how and how often the file should be polled and whether its contents are sensitive. -```river +```alloy local.file "targets" { // Required argument - filename = "/etc/agent/targets" + filename = "/etc/alloy/targets" // Optional arguments: Components may have some optional arguments that // do not need to be defined. @@ -58,7 +58,7 @@ References can only appear in components. For example, here's a component that scrapes Prometheus metrics. The `targets` field is populated with two scrape targets, a constant target `localhost:9001` and an expression that ties the target to the value of `local.file.targets.content`. -```river +```alloy prometheus.scrape "default" { targets = [ { "__address__" = local.file.targets.content }, // tada! diff --git a/docs/sources/concepts/configuration-syntax/expressions/function_calls.md b/docs/sources/concepts/configuration-syntax/expressions/function_calls.md index 09d0b1a103..56a73a7d0e 100644 --- a/docs/sources/concepts/configuration-syntax/expressions/function_calls.md +++ b/docs/sources/concepts/configuration-syntax/expressions/function_calls.md @@ -20,7 +20,7 @@ The {{< param "PRODUCT_NAME" >}} configuration syntax contains a [standard libra Some functions enable interaction with the host system, for example, reading from an environment variable. Some functions allow for more complex expressions, for example, concatenating arrays or decoding JSON strings into objects. -```river +```alloy env("HOME") json_decode(local.file.cfg.content)["namespace"] ``` diff --git a/docs/sources/concepts/configuration-syntax/expressions/operators.md b/docs/sources/concepts/configuration-syntax/expressions/operators.md index 0c4ea797a3..a7d3b506cc 100644 --- a/docs/sources/concepts/configuration-syntax/expressions/operators.md +++ b/docs/sources/concepts/configuration-syntax/expressions/operators.md @@ -82,7 +82,7 @@ Brackets | Description The following example uses curly braces and square brackets to define an object and an array. -```river +```alloy obj = { app = "agent", namespace = "dev" } arr = [1, true, 7 * (1+1), 3] ``` @@ -98,7 +98,7 @@ You can access arbitrarily nested values with {{< param "PRODUCT_NAME" >}}'s acc You can use square brackets to access zero-indexed array indices and object fields by enclosing the field name in double quotes. You can use the dot operator to access object fields without double quotes and component exports. -```river +```alloy obj["app"] arr[1] diff --git a/docs/sources/concepts/configuration-syntax/expressions/referencing_exports.md b/docs/sources/concepts/configuration-syntax/expressions/referencing_exports.md index fe7e3af97f..1af0a3307e 100644 --- a/docs/sources/concepts/configuration-syntax/expressions/referencing_exports.md +++ b/docs/sources/concepts/configuration-syntax/expressions/referencing_exports.md @@ -22,7 +22,7 @@ Similarly, a `prometheus.remote_write` component instance labeled `onprem` expos The following example shows some references. -```river +```alloy local.file "target" { filename = "/etc/agent/target" } diff --git a/docs/sources/concepts/configuration-syntax/expressions/types_and_values.md b/docs/sources/concepts/configuration-syntax/expressions/types_and_values.md index 7ad987f300..445900c3c3 100644 --- a/docs/sources/concepts/configuration-syntax/expressions/types_and_values.md +++ b/docs/sources/concepts/configuration-syntax/expressions/types_and_values.md @@ -44,7 +44,7 @@ In addition to the preceding types, the [component reference][] documentation us The {{< param "PRODUCT_NAME" >}} syntax handles integers, unsigned integers, and floating-point values as a single 'number' type, simplifying writing and reading {{< param "PRODUCT_NAME" >}} configuration files. -```river +```alloy 3 == 3.00 // true 5.0 == (10 / 2) // true 1e+2 == 100 // true @@ -55,7 +55,7 @@ The {{< param "PRODUCT_NAME" >}} syntax handles integers, unsigned integers, and Strings are represented by sequences of Unicode characters surrounded by double quotes `""`. -```river +```alloy "Hello, world!" ``` @@ -84,7 +84,7 @@ The following table shows the supported escape sequences. Raw strings are represented by sequences of Unicode characters surrounded by backticks ``` `` ```. Raw strings don't support any escape sequences. -```river +```alloy `Hello, "world"!` ``` @@ -93,7 +93,7 @@ You can include a backtick by concatenating a double-quoted string that contains A multiline raw string is interpreted exactly as written. -```river +```alloy `Hello, "world"!` ``` @@ -113,14 +113,14 @@ Bools are represented by the symbols `true` and `false`. You construct arrays with a sequence of comma-separated values surrounded by square brackets `[]`. -```river +```alloy [0, 1, 2, 3] ``` You can place values in array elements on separate lines for readability. A comma after the final value must be present if the closing bracket `]` is on a different line than the final value. -```river +```alloy [ 0, 1, @@ -132,7 +132,7 @@ A comma after the final value must be present if the closing bracket `]` is on a You construct objects with a sequence of comma-separated key-value pairs surrounded by curly braces `{}`. -```river +```alloy { first_name = "John", last_name = "Doe", @@ -141,13 +141,13 @@ You construct objects with a sequence of comma-separated key-value pairs surroun You can omit the comma after the final key-value pair if the closing curly brace `}` is on the same line as the final pair. -```river +```alloy { name = "John" } ``` If the key isn't a valid identifier, you must wrap it in double quotes like a string. -```river +```alloy { "app.kubernetes.io/name" = "mysql", "app.kubernetes.io/instance" = "mysql-abcxyz", @@ -193,7 +193,7 @@ The specific type of capsule expected is explicitly documented for any component In the following example, the `prometheus.remote_write` component exports a `receiver`, which is a `capsule("prometheus.Receiver")` type. You can use this capsule in the `forward_to` attribute of `prometheus.scrape`, which expects an array of `capsule("prometheus.Receiver")`. -```river +```alloy prometheus.remote_write "default" { endpoint { url = "http://localhost:9090/api/v1/write" diff --git a/docs/sources/concepts/configuration-syntax/syntax.md b/docs/sources/concepts/configuration-syntax/syntax.md index ba8c68aa12..4bed13ad90 100644 --- a/docs/sources/concepts/configuration-syntax/syntax.md +++ b/docs/sources/concepts/configuration-syntax/syntax.md @@ -31,7 +31,7 @@ They can appear either as top-level elements or nested within blocks. The following example sets the `log_level` attribute to `"debug"`. -```river +```alloy log_level = "debug" ``` @@ -50,7 +50,7 @@ Some blocks can be defined more than once. You can use the following pattern to create an unlabeled block. -```river +```alloy BLOCK_NAME { // Block body can contain attributes and nested unlabeled blocks IDENTIFIER = EXPRESSION // Attribute @@ -63,7 +63,7 @@ BLOCK_NAME { You can use the following pattern to create a labeled block -```river +```alloy // Pattern for creating a labeled block: BLOCK_NAME "BLOCK_LABEL" { // Block body can contain attributes and nested unlabeled blocks @@ -84,7 +84,7 @@ In these cases, you use the label to disambiguate between multiple top-level blo The following snippet defines a block named `local.file` with its label set to "token". The block's body sets `filename` to the content of the `TOKEN_FILE_PATH` environment variable by using an expression, and the `is_secret` attribute is set to the boolean `true`, marking the file content as sensitive. -```river +```alloy local.file "token" { filename = env("TOKEN_FILE_PATH") // Use an expression to read from an env var. is_secret = true diff --git a/docs/sources/concepts/custom_components.md b/docs/sources/concepts/custom_components.md index 6b70b5a269..f97925fbd0 100644 --- a/docs/sources/concepts/custom_components.md +++ b/docs/sources/concepts/custom_components.md @@ -33,7 +33,7 @@ To learn how to share custom components across multiple files, refer to [Modules This example creates a new custom component called `add`, which exports the sum of two arguments: -```river +```alloy declare "add" { argument "a" { } argument "b" { } diff --git a/docs/sources/concepts/modules.md b/docs/sources/concepts/modules.md index 0db2db5ee7..85671c3e71 100644 --- a/docs/sources/concepts/modules.md +++ b/docs/sources/concepts/modules.md @@ -36,7 +36,7 @@ If an import namespace matches the name of a built-in component namespace, such This example module defines a component to filter out debug-level and info-level log lines: -```river +```alloy declare "log_filter" { // argument.write_to is a required argument that specifies where filtered // log lines are sent. @@ -71,7 +71,7 @@ declare "log_filter" { You can save this module to a file called `helpers.alloy` and import it: -```river +```alloy // Import our helpers.alloy module, exposing its custom components as // helpers.COMPONENT_NAME. import.file "helpers" { diff --git a/docs/sources/get-started/install/docker.md b/docs/sources/get-started/install/docker.md index 0c4574fed6..e59e62753c 100644 --- a/docs/sources/get-started/install/docker.md +++ b/docs/sources/get-started/install/docker.md @@ -18,7 +18,7 @@ weight: 100 * Install [Docker][] on your computer. * Create and save an {{< param "PRODUCT_NAME" >}} configuration file on your computer, for example: - ```river + ```alloy logging { level = "info" format = "logfmt" diff --git a/docs/sources/reference/components/discovery.azure.md b/docs/sources/reference/components/discovery.azure.md index 942932d59a..985c295baf 100644 --- a/docs/sources/reference/components/discovery.azure.md +++ b/docs/sources/reference/components/discovery.azure.md @@ -12,7 +12,7 @@ title: discovery.azure ## Usage -```river +```alloy discovery.azure "LABEL" { } ``` @@ -114,7 +114,7 @@ values. ## Example -```river +```alloy discovery.azure "example" { port = 80 subscription_id = AZURE_SUBSCRIPTION_ID diff --git a/docs/sources/reference/components/discovery.consul.md b/docs/sources/reference/components/discovery.consul.md index 564a789556..1cf447e8e6 100644 --- a/docs/sources/reference/components/discovery.consul.md +++ b/docs/sources/reference/components/discovery.consul.md @@ -12,7 +12,7 @@ title: discovery.consul ## Usage -```river +```alloy discovery.consul "LABEL" { server = CONSUL_SERVER } @@ -137,7 +137,7 @@ In those cases, exported fields retain their last healthy values. This example discovers targets from Consul for the specified list of services: -```river +```alloy discovery.consul "example" { server = "localhost:8500" services = [ diff --git a/docs/sources/reference/components/discovery.consulagent.md b/docs/sources/reference/components/discovery.consulagent.md index 9cc23de10b..659e8e50b3 100644 --- a/docs/sources/reference/components/discovery.consulagent.md +++ b/docs/sources/reference/components/discovery.consulagent.md @@ -14,7 +14,7 @@ This is suitable for very large Consul clusters for which using the Catalog API ## Usage -```river +```alloy discovery.consulagent "LABEL" { server = CONSUL_SERVER } @@ -95,7 +95,7 @@ values. This example discovers targets from a Consul Agent for the specified list of services: -```river +```alloy discovery.consulagent "example" { server = "localhost:8500" services = [ diff --git a/docs/sources/reference/components/discovery.digitalocean.md b/docs/sources/reference/components/discovery.digitalocean.md index c2bc5b9639..d7f83700e3 100644 --- a/docs/sources/reference/components/discovery.digitalocean.md +++ b/docs/sources/reference/components/discovery.digitalocean.md @@ -12,7 +12,7 @@ title: discovery.digitalocean ## Usage -```river +```alloy discovery.digitalocean "LABEL" { // Use one of: // bearer_token = BEARER_TOKEN @@ -92,7 +92,7 @@ values. ## Example This would result in targets with `__address__` labels like: `192.0.2.1:8080`: -```river +```alloy discovery.digitalocean "example" { port = 8080 refresh_interval = "5m" diff --git a/docs/sources/reference/components/discovery.dns.md b/docs/sources/reference/components/discovery.dns.md index 73f1d8c8a8..ea7b766c98 100644 --- a/docs/sources/reference/components/discovery.dns.md +++ b/docs/sources/reference/components/discovery.dns.md @@ -10,7 +10,7 @@ title: discovery.dns ## Usage -```river +```alloy discovery.dns "LABEL" { names = [NAME_1, NAME_2, ...] } @@ -60,7 +60,7 @@ In those cases, exported fields retain their last healthy values. This example discovers targets from an A record. -```river +```alloy discovery.dns "dns_lookup" { names = ["myservice.example.com", "myotherservice.example.com"] type = "A" diff --git a/docs/sources/reference/components/discovery.docker.md b/docs/sources/reference/components/discovery.docker.md index 0ab823d22d..cebdd79843 100644 --- a/docs/sources/reference/components/discovery.docker.md +++ b/docs/sources/reference/components/discovery.docker.md @@ -12,7 +12,7 @@ title: discovery.docker ## Usage -```river +```alloy discovery.docker "LABEL" { host = DOCKER_ENGINE_HOST } @@ -147,7 +147,7 @@ In those cases, exported fields retain their last healthy values. This example discovers Docker containers when the host machine is macOS or Linux: -```river +```alloy discovery.docker "containers" { host = "unix:///var/run/docker.sock" } @@ -177,7 +177,7 @@ Replace the following: This example discovers Docker containers when the host machine is Windows: -```river +```alloy discovery.docker "containers" { host = "tcp://localhost:2375" } diff --git a/docs/sources/reference/components/discovery.dockerswarm.md b/docs/sources/reference/components/discovery.dockerswarm.md index e2bc5d9c3e..223af0e932 100644 --- a/docs/sources/reference/components/discovery.dockerswarm.md +++ b/docs/sources/reference/components/discovery.dockerswarm.md @@ -10,7 +10,7 @@ title: discovery.dockerswarm ## Usage -```river +```alloy discovery.dockerswarm "LABEL" { host = "DOCKER_DAEMON_HOST" role = "SWARM_ROLE" @@ -215,7 +215,7 @@ In those cases, exported fields retain their last healthy values. This example discovers targets from Docker Swarm tasks: -```river +```alloy discovery.dockerswarm "example" { host = "unix:///var/run/docker.sock" role = "tasks" diff --git a/docs/sources/reference/components/discovery.ec2.md b/docs/sources/reference/components/discovery.ec2.md index 90ebb0109b..2cb454cd5d 100644 --- a/docs/sources/reference/components/discovery.ec2.md +++ b/docs/sources/reference/components/discovery.ec2.md @@ -12,7 +12,7 @@ The IAM credentials used must have the `ec2:DescribeInstances` permission to dis ## Usage -```river +```alloy discovery.ec2 "LABEL" { } ``` @@ -140,7 +140,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.ec2 "ec2" { region = "us-east-1" } diff --git a/docs/sources/reference/components/discovery.eureka.md b/docs/sources/reference/components/discovery.eureka.md index dfcc6fea56..1d7986b916 100644 --- a/docs/sources/reference/components/discovery.eureka.md +++ b/docs/sources/reference/components/discovery.eureka.md @@ -12,7 +12,7 @@ title: discovery.eureka ## Usage -```river +```alloy discovery.eureka "LABEL" { server = SERVER } @@ -127,7 +127,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.eureka "example" { server = "https://eureka.example.com/eureka/v1" } diff --git a/docs/sources/reference/components/discovery.file.md b/docs/sources/reference/components/discovery.file.md index 8a5e0441fe..2421e14183 100644 --- a/docs/sources/reference/components/discovery.file.md +++ b/docs/sources/reference/components/discovery.file.md @@ -18,7 +18,7 @@ If you are trying to discover files on the local filesystem rather than scrape t ## Usage -```river +```alloy discovery.file "LABEL" { files = [FILE_PATH_1, FILE_PATH_2, ...] } @@ -96,7 +96,7 @@ In those cases, exported fields retain their last healthy values. This example discovers targets from a single file, scrapes them, and writes metrics to a Prometheus remote write endpoint. -```river +```alloy discovery.file "example" { files = ["/tmp/example.json"] } @@ -129,7 +129,7 @@ This example discovers targets from a wildcard file path, scrapes them, and writ It also uses a relabeling rule to retain the file path as a label on each target. -```river +```alloy discovery.file "example" { files = ["/tmp/example_*.yaml"] } diff --git a/docs/sources/reference/components/discovery.gce.md b/docs/sources/reference/components/discovery.gce.md index d47300d1f9..dc593d75d4 100644 --- a/docs/sources/reference/components/discovery.gce.md +++ b/docs/sources/reference/components/discovery.gce.md @@ -22,7 +22,7 @@ If running outside of GCE make sure to create an appropriate service account and ## Usage -```river +```alloy discovery.gce "LABEL" { project = PROJECT_NAME zone = ZONE_NAME @@ -86,7 +86,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.gce "gce" { project = "agent" zone = "us-east1-a" diff --git a/docs/sources/reference/components/discovery.hetzner.md b/docs/sources/reference/components/discovery.hetzner.md index 27637a983c..91361f26e7 100644 --- a/docs/sources/reference/components/discovery.hetzner.md +++ b/docs/sources/reference/components/discovery.hetzner.md @@ -14,7 +14,7 @@ This service discovery uses the public IPv4 address by default, but that can be ## Usage -```river +```alloy discovery.hetzner "LABEL" { role = HETZNER_ROLE } @@ -150,7 +150,7 @@ values. This example discovers targets from Hetzner: -```river +```alloy discovery.hetzner "example" { role = HETZNER_ROLE } diff --git a/docs/sources/reference/components/discovery.http.md b/docs/sources/reference/components/discovery.http.md index 11e723f6e4..19a789d4da 100644 --- a/docs/sources/reference/components/discovery.http.md +++ b/docs/sources/reference/components/discovery.http.md @@ -79,7 +79,7 @@ For more information on the potential labels you can use, see the [prometheus.sc ## Usage -```river +```alloy discovery.http "LABEL" { url = URL } @@ -179,7 +179,7 @@ In those cases, exported fields retain their last healthy values. This example will query a URL every 15 seconds and expose targets that it finds: -```river +```alloy discovery.http "dynamic_targets" { url = "https://example.com/scrape_targets" refresh_interval = "15s" diff --git a/docs/sources/reference/components/discovery.ionos.md b/docs/sources/reference/components/discovery.ionos.md index 4e4ee5e555..f939aa7e63 100644 --- a/docs/sources/reference/components/discovery.ionos.md +++ b/docs/sources/reference/components/discovery.ionos.md @@ -12,7 +12,7 @@ title: discovery.ionos ## Usage -```river +```alloy discovery.ionos "LABEL" { datacenter_id = DATACENTER_ID } @@ -124,7 +124,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.ionos "example" { datacenter_id = "15f67991-0f51-4efc-a8ad-ef1fb31a480c" } diff --git a/docs/sources/reference/components/discovery.kubelet.md b/docs/sources/reference/components/discovery.kubelet.md index d642f39d0d..e2a5d76bad 100644 --- a/docs/sources/reference/components/discovery.kubelet.md +++ b/docs/sources/reference/components/discovery.kubelet.md @@ -14,7 +14,7 @@ title: discovery.kubelet ## Usage -```river +```alloy discovery.kubelet "LABEL" { } ``` @@ -155,7 +155,7 @@ In those cases, exported fields retain their last healthy values. This example uses a bearer token file to authenticate to the Kubelet API: -```river +```alloy discovery.kubelet "k8s_pods" { bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token" } @@ -185,7 +185,7 @@ Replace the following: This example limits the namespaces where pods are discovered using the `namespaces` argument: -```river +```alloy discovery.kubelet "k8s_pods" { bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token" namespaces = ["default", "kube-system"] diff --git a/docs/sources/reference/components/discovery.kubernetes.md b/docs/sources/reference/components/discovery.kubernetes.md index 6b51c7fa9a..f8c5d024b7 100644 --- a/docs/sources/reference/components/discovery.kubernetes.md +++ b/docs/sources/reference/components/discovery.kubernetes.md @@ -14,7 +14,7 @@ A kubeconfig file or manual connection settings can be used to override the defa ## Usage -```river +```alloy discovery.kubernetes "LABEL" { role = DISCOVERY_ROLE } @@ -303,7 +303,7 @@ In those cases, exported fields retain their last healthy values. This example uses in-cluster authentication to discover all pods: -```river +```alloy discovery.kubernetes "k8s_pods" { role = "pod" } @@ -333,7 +333,7 @@ Replace the following: This example uses a Kubeconfig file to authenticate to the Kubernetes API: -```river +```alloy discovery.kubernetes "k8s_pods" { role = "pod" kubeconfig_file = "/etc/k8s/kubeconfig.yaml" @@ -364,7 +364,7 @@ Replace the following: This example limits the searched namespaces and only selects pods with a specific label value attached to them: -```river +```alloy discovery.kubernetes "k8s_pods" { role = "pod" @@ -409,7 +409,7 @@ This example assumes you have used Helm chart to deploy {{< param "PRODUCT_NAME" If you have a custom Kubernetes Deployment, you must adapt this example to your configuration. {{< /admonition >}} -```river +```alloy discovery.kubernetes "k8s_pods" { role = "pod" selectors { diff --git a/docs/sources/reference/components/discovery.kuma.md b/docs/sources/reference/components/discovery.kuma.md index 720a0ed19b..9231df6797 100644 --- a/docs/sources/reference/components/discovery.kuma.md +++ b/docs/sources/reference/components/discovery.kuma.md @@ -12,7 +12,7 @@ title: discovery.kuma ## Usage -```river +```alloy discovery.kuma "LABEL" { server = SERVER } @@ -110,7 +110,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.kuma "example" { server = "http://kuma-control-plane.kuma-system.svc:5676" } diff --git a/docs/sources/reference/components/discovery.lightsail.md b/docs/sources/reference/components/discovery.lightsail.md index fabb8a3825..d7f5ded47a 100644 --- a/docs/sources/reference/components/discovery.lightsail.md +++ b/docs/sources/reference/components/discovery.lightsail.md @@ -10,7 +10,7 @@ title: discovery.lightsail ## Usage -```river +```alloy discovery.lightsail "LABEL" { } ``` @@ -123,7 +123,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.lightsail "lightsail" { region = "us-east-1" } diff --git a/docs/sources/reference/components/discovery.linode.md b/docs/sources/reference/components/discovery.linode.md index 175a241e6c..aaf33fd43d 100644 --- a/docs/sources/reference/components/discovery.linode.md +++ b/docs/sources/reference/components/discovery.linode.md @@ -13,7 +13,7 @@ This service discovery uses the public IPv4 address by default, but that can be ## Usage -```river +```alloy discovery.linode "LABEL" { bearer_token = LINODE_API_TOKEN } @@ -132,7 +132,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.linode "example" { bearer_token = env("LINODE_TOKEN") port = 8876 diff --git a/docs/sources/reference/components/discovery.marathon.md b/docs/sources/reference/components/discovery.marathon.md index b13f4d728c..e1d35e1273 100644 --- a/docs/sources/reference/components/discovery.marathon.md +++ b/docs/sources/reference/components/discovery.marathon.md @@ -10,7 +10,7 @@ title: discovery.marathon ## Usage -```river +```alloy discovery.marathon "LABEL" { servers = [MARATHON_SERVER1, MARATHON_SERVER2...] } @@ -120,7 +120,7 @@ In those cases, exported fields retain their last healthy values. This example discovers targets from a Marathon server: -```river +```alloy discovery.marathon "example" { servers = ["localhost:8500"] } diff --git a/docs/sources/reference/components/discovery.nerve.md b/docs/sources/reference/components/discovery.nerve.md index 9b7ebca64b..8c39565676 100644 --- a/docs/sources/reference/components/discovery.nerve.md +++ b/docs/sources/reference/components/discovery.nerve.md @@ -12,7 +12,7 @@ title: discovery.nerve ## Usage -```river +```alloy discovery.nerve "LABEL" { servers = [SERVER_1, SERVER_2] paths = [PATH_1, PATH_2] @@ -65,7 +65,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.nerve "example" { servers = ["localhost"] paths = ["/monitoring"] diff --git a/docs/sources/reference/components/discovery.nomad.md b/docs/sources/reference/components/discovery.nomad.md index 71eeb221ee..e6677943c0 100644 --- a/docs/sources/reference/components/discovery.nomad.md +++ b/docs/sources/reference/components/discovery.nomad.md @@ -10,7 +10,7 @@ title: discovery.nomad ## Usage -```river +```alloy discovery.nomad "LABEL" { } ``` @@ -121,7 +121,7 @@ In those cases, exported fields retain their last healthy values. This example discovers targets from a Nomad server: -```river +```alloy discovery.nomad "example" { } diff --git a/docs/sources/reference/components/discovery.openstack.md b/docs/sources/reference/components/discovery.openstack.md index 894c66101a..9fc84101b1 100644 --- a/docs/sources/reference/components/discovery.openstack.md +++ b/docs/sources/reference/components/discovery.openstack.md @@ -12,7 +12,7 @@ title: discovery.openstack ## Usage -```river +```alloy discovery.openstack "LABEL" { role = "hypervisor" region = "us-east-1" @@ -125,7 +125,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.openstack "example" { role = OPENSTACK_ROLE region = OPENSTACK_REGION diff --git a/docs/sources/reference/components/discovery.ovhcloud.md b/docs/sources/reference/components/discovery.ovhcloud.md index 6afa7bb708..7b3e96b6c1 100644 --- a/docs/sources/reference/components/discovery.ovhcloud.md +++ b/docs/sources/reference/components/discovery.ovhcloud.md @@ -19,7 +19,7 @@ For OVHcloud's [public cloud][] instances you can use `discovery.openstack`. ## Usage -```river +```alloy discovery.ovhcloud "LABEL" { application_key = APPLICATION_KEY application_secret = APPLICATION_SECRET @@ -107,7 +107,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.ovhcloud "example" { application_key = APPLICATION_KEY application_secret = APPLICATION_SECRET diff --git a/docs/sources/reference/components/discovery.process.md b/docs/sources/reference/components/discovery.process.md index 895cdada65..2a902953af 100644 --- a/docs/sources/reference/components/discovery.process.md +++ b/docs/sources/reference/components/discovery.process.md @@ -18,7 +18,7 @@ To use the `discovery.process` component you must run {{< param "PRODUCT_NAME" > ## Usage -```river +```alloy discovery.process "LABEL" { } @@ -150,7 +150,7 @@ In those cases, exported fields retain their last healthy values. ### Example discovering processes on the local host -```river +```alloy discovery.process "all" { refresh_interval = "60s" discover_config { @@ -167,7 +167,7 @@ discovery.process "all" { ### Example discovering processes on the local host and joining with `discovery.kubernetes` -```river +```alloy discovery.kubernetes "pyroscope_kubernetes" { selectors { field = "spec.nodeName=" + env("HOSTNAME") diff --git a/docs/sources/reference/components/discovery.puppetdb.md b/docs/sources/reference/components/discovery.puppetdb.md index 3ef7fc40e3..fe889d14f4 100644 --- a/docs/sources/reference/components/discovery.puppetdb.md +++ b/docs/sources/reference/components/discovery.puppetdb.md @@ -16,7 +16,7 @@ The queries for this component are expected to be valid [PQL (Puppet Query Langu ## Usage -```river +```alloy discovery.puppetdb "LABEL" { url = PUPPET_SERVER } @@ -128,7 +128,7 @@ In those cases, exported fields retain their last healthy values. This example discovers targets from puppetdb for all the servers that have a specific package defined: -```river +```alloy discovery.puppetdb "example" { url = "http://puppetdb.local:8080" query = "resources { type = \"Package\" and title = \"node_exporter\" }" diff --git a/docs/sources/reference/components/discovery.relabel.md b/docs/sources/reference/components/discovery.relabel.md index 2cb341cfdb..b98c6fa7ed 100644 --- a/docs/sources/reference/components/discovery.relabel.md +++ b/docs/sources/reference/components/discovery.relabel.md @@ -25,7 +25,7 @@ Multiple `discovery.relabel` components can be specified by giving them differen ## Usage -```river +```alloy discovery.relabel "LABEL" { targets = TARGET_LIST @@ -84,7 +84,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.relabel "keep_backend_only" { targets = [ { "__meta_foo" = "foo", "__address__" = "localhost", "instance" = "one", "app" = "backend" }, diff --git a/docs/sources/reference/components/discovery.scaleway.md b/docs/sources/reference/components/discovery.scaleway.md index 9f36c82e33..653073203e 100644 --- a/docs/sources/reference/components/discovery.scaleway.md +++ b/docs/sources/reference/components/discovery.scaleway.md @@ -13,7 +13,7 @@ title: discovery.scaleway ## Usage -```river +```alloy discovery.scaleway "LABEL" { project_id = "SCALEWAY_PROJECT_ID" role = "SCALEWAY_PROJECT_ROLE" @@ -137,7 +137,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.scaleway "example" { project_id = "SCALEWAY_PROJECT_ID" role = "SCALEWAY_PROJECT_ROLE" diff --git a/docs/sources/reference/components/discovery.serverset.md b/docs/sources/reference/components/discovery.serverset.md index e693c9f3cf..9bd2ce0ed2 100644 --- a/docs/sources/reference/components/discovery.serverset.md +++ b/docs/sources/reference/components/discovery.serverset.md @@ -15,7 +15,7 @@ Serversets are commonly used by [Finagle][] and [Aurora][]. ## Usage -```river +```alloy discovery.serverset "LABEL" { servers = SERVERS_LIST paths = ZOOKEEPER_PATHS_LIST @@ -70,7 +70,7 @@ In those cases, exported fields retain their last healthy values. The configuration below will connect to one of the Zookeeper servers (either `zk1`, `zk2`, or `zk3`) and discover JSON Serversets at paths `/path/to/znode1` and `/path/to/znode2`. The discovered targets are scraped by the `prometheus.scrape.default` component and forwarded to the `prometheus.remote_write.default` component, which will send the samples to specified remote_write URL. -```river +```alloy discovery.serverset "zookeeper" { servers = ["zk1", "zk2", "zk3"] paths = ["/path/to/znode1", "/path/to/znode2"] diff --git a/docs/sources/reference/components/discovery.triton.md b/docs/sources/reference/components/discovery.triton.md index 82578eee6f..89f09f1f7c 100644 --- a/docs/sources/reference/components/discovery.triton.md +++ b/docs/sources/reference/components/discovery.triton.md @@ -12,7 +12,7 @@ title: discovery.triton ## Usage -```river +```alloy discovery.triton "LABEL" { account = ACCOUNT dns_suffix = DNS_SUFFIX @@ -93,7 +93,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.triton "example" { account = TRITON_ACCOUNT dns_suffix = TRITON_DNS_SUFFIX diff --git a/docs/sources/reference/components/discovery.uyuni.md b/docs/sources/reference/components/discovery.uyuni.md index 8cbd7d6870..a7767f0f7d 100644 --- a/docs/sources/reference/components/discovery.uyuni.md +++ b/docs/sources/reference/components/discovery.uyuni.md @@ -12,7 +12,7 @@ title: discovery.uyuni ## Usage -```river +```alloy discovery.uyuni "LABEL" { server = SERVER username = USERNAME @@ -94,7 +94,7 @@ In those cases, exported fields retain their last healthy values. ## Example -```river +```alloy discovery.uyuni "example" { server = "https://127.0.0.1/rpc/api" username = UYUNI_USERNAME diff --git a/docs/sources/reference/components/faro.receiver.md b/docs/sources/reference/components/faro.receiver.md index a81744e1e5..88201c4687 100644 --- a/docs/sources/reference/components/faro.receiver.md +++ b/docs/sources/reference/components/faro.receiver.md @@ -12,7 +12,7 @@ title: faro.receiver ## Usage -```river +```alloy faro.receiver "LABEL" { output { logs = [LOKI_RECEIVERS] @@ -186,7 +186,7 @@ start. ## Example -```river +```alloy faro.receiver "default" { server { listen_address = "NETWORK_ADDRESS" diff --git a/docs/sources/reference/components/local.file.md b/docs/sources/reference/components/local.file.md index aa82610d44..63690e24d9 100644 --- a/docs/sources/reference/components/local.file.md +++ b/docs/sources/reference/components/local.file.md @@ -15,7 +15,7 @@ Multiple `local.file` components can be specified by giving them different label ## Usage -```river +```alloy local.file "LABEL" { filename = FILE_NAME } @@ -64,7 +64,7 @@ The read error will be exposed as a log message and in the debug information for ## Example -```river +```alloy local.file "secret_key" { filename = "/var/secrets/password.txt" is_secret = true diff --git a/docs/sources/reference/components/local.file_match.md b/docs/sources/reference/components/local.file_match.md index 5831311871..8207152868 100644 --- a/docs/sources/reference/components/local.file_match.md +++ b/docs/sources/reference/components/local.file_match.md @@ -12,7 +12,7 @@ title: local.file_match ## Usage -```river +```alloy local.file_match "LABEL" { path_targets = [{"__path__" = DOUBLESTAR_PATH}] } @@ -65,7 +65,7 @@ In those cases, exported fields retain their last healthy values. This example discovers all files and folders under `/tmp/logs`. The absolute paths are used by `loki.source.file.files` targets. -```river +```alloy local.file_match "tmp" { path_targets = [{"__path__" = "/tmp/logs/**/*.log"}] } @@ -94,7 +94,7 @@ Replace the following: This example finds all the logs on pods and monitors them. -```river +```alloy discovery.kubernetes "k8s" { role = "pod" } diff --git a/docs/sources/reference/components/loki.echo.md b/docs/sources/reference/components/loki.echo.md index 3cd8c26b86..677a4f6b7e 100644 --- a/docs/sources/reference/components/loki.echo.md +++ b/docs/sources/reference/components/loki.echo.md @@ -16,7 +16,7 @@ Multiple `loki.echo` components can be specified by giving them different labels ## Usage -```river +```alloy loki.echo "LABEL" {} ``` @@ -44,7 +44,7 @@ Name | Type | Description This example creates a pipeline that reads log files from `/var/log` and prints log lines to echo: -```river +```alloy local.file_match "varlog" { path_targets = [{ __path__ = "/var/log/*log", diff --git a/docs/sources/reference/components/loki.process.md b/docs/sources/reference/components/loki.process.md index 9f9d344d9b..c7e950249c 100644 --- a/docs/sources/reference/components/loki.process.md +++ b/docs/sources/reference/components/loki.process.md @@ -16,7 +16,7 @@ Multiple `loki.process` components can be specified by giving them different lab ## Usage -```river +```alloy loki.process "LABEL" { forward_to = RECEIVER_LIST @@ -110,7 +110,7 @@ The following arguments are supported: `max_partial_line_size` is only taken into account if `max_partial_line_size_truncate` is set to `true`. -```river +```alloy stage.cri {} ``` @@ -137,7 +137,7 @@ The `stage.decolorize` strips ANSI color codes from the log lines, thus making i The `stage.decolorize` block does not support any arguments or inner blocks, so it is always empty. -```river +```alloy stage.decolorize {} ``` @@ -159,7 +159,7 @@ The `stage.docker` inner block enables a predefined pipeline which reads log lin The `stage.docker` block does not support any arguments or inner blocks, so it is always empty. -```river +```alloy stage.docker {} ``` @@ -210,7 +210,7 @@ Whenever an entry is dropped, the metric `loki_process_dropped_lines_total` is i The following stage drops log entries that contain the word `debug` _and_ are longer than 1KB. -```river +```alloy stage.drop { expression = ".*debug.*" longer_than = "1KB" @@ -219,7 +219,7 @@ stage.drop { On the following example, we define multiple `drop` blocks so `loki.process` drops entries that are either 24h or older, are longer than 8KB, _or_ the extracted value of 'app' is equal to foo. -```river +```alloy stage.drop { older_than = "24h" drop_counter_reason = "too old" @@ -256,7 +256,7 @@ If set to `false`, the stage will automatically convert them into valid labels r #### Example combined with `stage.json` -```river +```alloy stage.json { expressions = { message = "", @@ -308,7 +308,7 @@ The map key defines the name with which the data is extracted, while the map val Here's a given log line and two JSON stages to run. -```river +```alloy {"log":"log message\n","extra":"{\"user\":\"alloy\"}"} loki.process "username" { @@ -357,7 +357,7 @@ The following arguments are supported: | -------- | -------------- | ------------------------------------------- | ------- | -------- | | `values` | `list(string)` | Configures a `label_drop` processing stage. | `{}` | no | -```river +```alloy stage.label_drop { values = [ "kubernetes_node_name", "kubernetes_namespace" ] } @@ -374,7 +374,7 @@ The following arguments are supported: | `values` | `list(string)` | Configures a `label_keep` processing stage. | `{}` | no | -```river +```alloy stage.label_keep { values = [ "kubernetes_pod_name", "kubernetes_pod_container_name" ] } @@ -393,7 +393,7 @@ The following arguments are supported: In a labels stage, the map's keys define the label to set and the values are how to look them up. If the value is empty, it is inferred to be the same as the key. -```river +```alloy stage.labels { values = { env = "", // Sets up an 'env' label, based on the 'env' extracted value. @@ -415,7 +415,7 @@ The following arguments are supported: In a structured_metadata stage, the map's keys define the label to set and the values are how to look them up. If the value is empty, it is inferred to be the same as the key. -```river +```alloy stage.structured_metadata { values = { env = "", // Sets up an 'env' property to structured metadata, based on the 'env' extracted value. @@ -441,7 +441,7 @@ The following arguments are supported: The rate limiting is implemented as a "token bucket" of size `burst`, initially full and refilled at `rate` tokens per second. Each received log entry consumes one token from the bucket. When `drop` is set to true, incoming entries that exceed the rate-limit are dropped, otherwise they are queued until more tokens are available. -```river +```alloy stage.limit { rate = 5 burst = 10 @@ -455,7 +455,7 @@ The following example rate-limits entries from each unique `namespace` value ind Any entries without the `namespace` label are not rate-limited. The stage keeps track of up to `max_distinct_labels` unique values, defaulting at 10000. -```river +```alloy stage.limit { rate = 10 burst = 10 @@ -688,7 +688,7 @@ The pipeline creates a second counter which adds the byte size of these log line These two metrics disappear after 24 hours if no new entries are received, to avoid building up metrics which no longer serve any use. These two metrics are a good starting point to track the volume of log streams in both the number of entries and their byte size, to identify sources of high-volume or high-cardinality data. -```river +```alloy stage.metrics { metric.counter { name = "log_lines_total" @@ -717,7 +717,7 @@ stage.metrics { Here, the first stage uses a regex to extract text in the format `order_status=` in the log line. The second stage, defines a counter which increments the `successful_orders_total` and `failed_orders_total` based on the previously extracted values. -```river +```alloy stage.regex { expression = "^.* order_status=(?P.*?) .*$" } @@ -744,7 +744,7 @@ stage.metrics { In this example, the first stage extracts text in the format of `retries=`, from the log line. The second stage creates a gauge whose current metric value is increased by the number extracted from the retries field. -```river +```alloy stage.regex { expression = "^.* retries=(?P\\d+) .*$" } @@ -760,7 +760,7 @@ stage.metrics { The following example shows a histogram that reads `response_time` from the extracted map and places it into a bucket, both increasing the count of the bucket and the sum for that particular bucket: -```river +```alloy stage.metrics { metric.histogram { name = "http_response_time_seconds" @@ -888,7 +888,7 @@ labels: { "level" = "error", "env" = "dev", "user_id" = "f8fas0r" } ``` and this processing stage: -```river +```alloy stage.pack { labels = ["env", "user_id"] } @@ -1103,7 +1103,7 @@ The following arguments are supported: For example, the configuration below will sample 25% of the logs and drop the remaining 75%. When logs are dropped, the `loki_process_dropped_lines_total` metric is incremented with an additional `reason=logs_sampling` label. -```river +```alloy stage.sampling { rate = 0.25 drop_counter_reason = "logs_sampling" @@ -1121,7 +1121,7 @@ The following arguments are supported: | `values` | `map(string)` | Configures a `static_labels` processing stage. | `{}` | no | -```river +```alloy stage.static_labels { values = { foo = "fooval", @@ -1162,7 +1162,7 @@ More details on each of these functions can be found in the [supported functions Assuming no data is present on the extracted map, the following stage simply adds the `new_key: "hello_world"` key-value pair to the shared map. -```river +```alloy stage.template { source = "new_key" template = "hello_world" @@ -1172,7 +1172,7 @@ stage.template { If the `source` value exists in the extract fields, its value can be referred to as `.Value` in the template. The next stage takes the current value of `app` from the extracted map, converts it to lowercase, and adds a suffix to its value: -```river +```alloy stage.template { source = "app" template = "{{ ToLower .Value }}_some_suffix" @@ -1182,7 +1182,7 @@ stage.template { Any previously extracted keys are available for `template` to expand and use. The next stage takes the current values for `level`, `app` and `module` and creates a new key named `output_message`: -```river +```alloy stage.template { source = "output_msg" template = "{{ .level }} for app {{ ToUpper .app }} in module {{.module}}" @@ -1191,7 +1191,7 @@ stage.template { A special key named `Entry` can be used to reference the current line; this can be useful when you need to append/prepend something to the log line, like this snippet: -```river +```alloy stage.template { source = "message" template = "{{.app }}: {{ .Entry }}" @@ -1210,7 +1210,7 @@ In addition to supporting all functions from the [sprig package](http://mastermi uppercase, respectively. Examples: -```river +```alloy stage.template { source = "out" template = "{{ ToLower .app }}" @@ -1232,7 +1232,7 @@ there is no limit on the number of replacement. Finally, if `` is empty, it matches before and after every UTF-8 character in the string. This example replaces the first two instances of the `loki` word by `Loki`: -```river +```alloy stage.template { source = "output" template = "{{ Replace .Value "loki" "Loki" 2 }}" @@ -1251,7 +1251,7 @@ white space removed, as defined by Unicode. Examples: -```river +```alloy stage.template { source = "output" template = "{{ Trim .Value ",. " }}" @@ -1277,7 +1277,7 @@ submatch. of the Regexp with the replacement string. The replacement string is substituted directly, without using Expand. -```river +```alloy stage.template { source = "output" template = "{{ regexReplaceAll "(a*)bc" .Value "${1}a" }}" @@ -1295,7 +1295,7 @@ It requires a (fixed) salt value, to add complexity to low input domains (e.g., `Sha2Hash` returns a `Sha2_256` of the string which is faster and less CPU-intensive than `Hash`, however it is less secure. Examples: -```river +```alloy stage.template { source = "output" template = "{{ Hash .Value "salt" }}" @@ -1324,7 +1324,7 @@ The following arguments are supported: The block expects only one of `label`, `source` or `value` to be provided. The following stage assigns the fixed value `team-a` as the tenant ID: -```river +```alloy stage.tenant { value = "team-a" } @@ -1333,7 +1333,7 @@ stage.tenant { This stage extracts the tenant ID from the `customer_id` field after parsing the log entry as JSON in the shared extracted map: -```river +```alloy stage.json { expressions = { "customer_id" = "" } } @@ -1344,7 +1344,7 @@ stage.tenant { The final example extracts the tenant ID from a label set by a previous stage: -```river +```alloy stage.labels { "namespace" = "k8s_namespace" } @@ -1452,7 +1452,7 @@ The supported actions are: The following stage fetches the `time` value from the shared values map, parses it as a RFC3339 format, and sets it as the log entry's timestamp. -```river +```alloy stage.timestamp { source = "time" format = "RFC3339" @@ -1651,7 +1651,7 @@ The following fields are exported and can be referenced by other components: This example creates a `loki.process` component that extracts the `environment` value from a JSON log line and sets it as a label named 'env'. -```river +```alloy loki.process "local" { forward_to = [loki.write.onprem.receiver] diff --git a/docs/sources/reference/components/loki.relabel.md b/docs/sources/reference/components/loki.relabel.md index 389372467e..e7c6d84503 100644 --- a/docs/sources/reference/components/loki.relabel.md +++ b/docs/sources/reference/components/loki.relabel.md @@ -28,7 +28,7 @@ Multiple `loki.relabel` components can be specified by giving them different lab ## Usage -```river +```alloy loki.relabel "LABEL" { forward_to = RECEIVER_LIST @@ -93,7 +93,7 @@ In those cases, exported fields are kept at their last healthy values. The following example creates a `loki.relabel` component that only forwards entries whose 'level' value is set to 'error'. -```river +```alloy loki.relabel "keep_error_only" { forward_to = [loki.write.onprem.receiver] diff --git a/docs/sources/reference/components/loki.rules.kubernetes.md b/docs/sources/reference/components/loki.rules.kubernetes.md index 89f74c541a..f6bcf543a8 100644 --- a/docs/sources/reference/components/loki.rules.kubernetes.md +++ b/docs/sources/reference/components/loki.rules.kubernetes.md @@ -32,7 +32,7 @@ in Kubernetes for {{< param "PRODUCT_NAME" >}} to access it via the Kubernetes R ## Usage -```river +```alloy loki.rules.kubernetes "LABEL" { address = LOKI_RULER_URL } @@ -191,7 +191,7 @@ This example creates a `loki.rules.kubernetes` component that loads discovered rules to a local Loki instance under the `team-a` tenant. Only namespaces and rules with the `alloy` label set to `yes` are included. -```river +```alloy loki.rules.kubernetes "local" { address = "loki:3100" tenant_id = "team-a" @@ -213,7 +213,7 @@ loki.rules.kubernetes "local" { This example creates a `loki.rules.kubernetes` component that loads discovered rules to Grafana Cloud. -```river +```alloy loki.rules.kubernetes "default" { address = "GRAFANA_CLOUD_URL" basic_auth { diff --git a/docs/sources/reference/components/loki.source.api.md b/docs/sources/reference/components/loki.source.api.md index 8b7ea38ee6..64f8821ddb 100644 --- a/docs/sources/reference/components/loki.source.api.md +++ b/docs/sources/reference/components/loki.source.api.md @@ -16,7 +16,7 @@ This means that other [`loki.write`][loki.write] components can be used as a cli ## Usage -```river +```alloy loki.source.api "LABEL" { http { listen_address = "LISTEN_ADDRESS" @@ -88,7 +88,7 @@ The following are some of the metrics that are exposed when this component is us This example starts an HTTP server on `0.0.0.0` address and port `9999`. The server receives log entries and forwards them to a `loki.write` component while adding a `forwarded="true"` label. The `loki.write` component will send the logs to the specified loki instance using basic auth credentials provided. -```river +```alloy loki.write "local" { endpoint { url = "http://loki:3100/api/v1/push" diff --git a/docs/sources/reference/components/loki.source.awsfirehose.md b/docs/sources/reference/components/loki.source.awsfirehose.md index 3b25e9e2c1..68f13448d6 100644 --- a/docs/sources/reference/components/loki.source.awsfirehose.md +++ b/docs/sources/reference/components/loki.source.awsfirehose.md @@ -51,7 +51,7 @@ See [Examples](#example) for a full example configuration showing how to enrich ## Usage -```river +```alloy loki.source.awsfirehose "LABEL" { http { listen_address = "LISTEN_ADDRESS" @@ -129,7 +129,7 @@ This example starts an HTTP server on `0.0.0.0` address and port `9999`. The ser them to a `loki.write` component. The `loki.write` component will send the logs to the specified loki instance using basic auth credentials provided. -```river +```alloy loki.write "local" { endpoint { url = "http://loki:3100/api/v1/push" @@ -155,7 +155,7 @@ As another example, if you are receiving records that originated from a CloudWat received entry by relabeling internal labels. The following configuration builds upon the one above but keeps the origin log stream and group as `log_stream` and `log_group`, respectively. -```river +```alloy loki.write "local" { endpoint { url = "http://loki:3100/api/v1/push" diff --git a/docs/sources/reference/components/loki.source.azure_event_hubs.md b/docs/sources/reference/components/loki.source.azure_event_hubs.md index 667ebba912..b3250cfd9b 100644 --- a/docs/sources/reference/components/loki.source.azure_event_hubs.md +++ b/docs/sources/reference/components/loki.source.azure_event_hubs.md @@ -22,7 +22,7 @@ different labels. ## Usage -```river +```alloy loki.source.azure_event_hubs "LABEL" { fully_qualified_namespace = "HOST:PORT" event_hubs = EVENT_HUB_LIST @@ -114,7 +114,7 @@ configuration. This example consumes messages from Azure Event Hub and uses OAuth to authenticate itself. -```river +```alloy loki.source.azure_event_hubs "example" { fully_qualified_namespace = "my-ns.servicebus.windows.net:9093" event_hubs = ["gw-logs"] diff --git a/docs/sources/reference/components/loki.source.cloudflare.md b/docs/sources/reference/components/loki.source.cloudflare.md index ab556885f6..6b2037aaec 100644 --- a/docs/sources/reference/components/loki.source.cloudflare.md +++ b/docs/sources/reference/components/loki.source.cloudflare.md @@ -19,7 +19,7 @@ different labels. ## Usage -```river +```alloy loki.source.cloudflare "LABEL" { zone_id = "ZONE_ID" api_token = "API_TOKEN" @@ -191,7 +191,7 @@ configuration. This example pulls logs from Cloudflare's API and forwards them to a `loki.write` component. -```river +```alloy loki.source.cloudflare "dev" { zone_id = env("CF_ZONE_ID") api_token = local.file.api.content diff --git a/docs/sources/reference/components/loki.source.docker.md b/docs/sources/reference/components/loki.source.docker.md index e944c3c814..21b7f1979d 100644 --- a/docs/sources/reference/components/loki.source.docker.md +++ b/docs/sources/reference/components/loki.source.docker.md @@ -12,7 +12,7 @@ Multiple `loki.source.docker` components can be specified by giving them differe ## Usage -```river +```alloy loki.source.docker "LABEL" { host = HOST targets = TARGET_LIST @@ -129,7 +129,7 @@ component's debug info. This example collects log entries from the files specified in the `targets` argument and forwards them to a `loki.write` component to be written to Loki. -```river +```alloy discovery.docker "linux" { host = "unix:///var/run/docker.sock" } diff --git a/docs/sources/reference/components/loki.source.file.md b/docs/sources/reference/components/loki.source.file.md index ea7b990074..0571fe943e 100644 --- a/docs/sources/reference/components/loki.source.file.md +++ b/docs/sources/reference/components/loki.source.file.md @@ -18,7 +18,7 @@ Refer to the [File Globbing](#file-globbing) example for more information. ## Usage -```river +```alloy loki.source.file "LABEL" { targets = TARGET_LIST forward_to = RECEIVER_LIST @@ -156,7 +156,7 @@ beginning. This example collects log entries from the files specified in the targets argument and forwards them to a `loki.write` component to be written to Loki. -```river +```alloy loki.source.file "tmpfiles" { targets = [ {__path__ = "/tmp/foo.txt", "color" = "pink"}, @@ -179,7 +179,7 @@ This example collects log entries from the files matching `*.log` pattern using `local.file_match` component. When files appear or disappear, the list of targets will be updated accordingly. -```river +```alloy local.file_match "logs" { path_targets = [ @@ -205,7 +205,7 @@ This example collects log entries from the compressed files matching `*.gz` pattern using `local.file_match` component and the decompression configuration on the `loki.source.file` component. -```river +```alloy local.file_match "logs" { path_targets = [ diff --git a/docs/sources/reference/components/loki.source.gcplog.md b/docs/sources/reference/components/loki.source.gcplog.md index 77c7ebb8c3..1040e239a9 100644 --- a/docs/sources/reference/components/loki.source.gcplog.md +++ b/docs/sources/reference/components/loki.source.gcplog.md @@ -17,7 +17,7 @@ Multiple `loki.source.gcplog` components can be specified by giving them differe ## Usage -```river +```alloy loki.source.gcplog "LABEL" { pull { project_id = "PROJECT_ID" @@ -151,7 +151,7 @@ metrics: This example listens for GCP Pub/Sub PushRequests on `0.0.0.0:8080` and forwards them to a `loki.write` component. -```river +```alloy loki.source.gcplog "local" { push {} @@ -168,7 +168,7 @@ loki.write "local" { On the other hand, if we need the server to listen on `0.0.0.0:4040`, and forwards them to a `loki.write` component. -```river +```alloy loki.source.gcplog "local" { push { http { diff --git a/docs/sources/reference/components/loki.source.gelf.md b/docs/sources/reference/components/loki.source.gelf.md index 0d3c508c51..16c373d869 100644 --- a/docs/sources/reference/components/loki.source.gelf.md +++ b/docs/sources/reference/components/loki.source.gelf.md @@ -14,7 +14,7 @@ different labels and ports. ## Usage -```river +```alloy loki.source.gelf "LABEL" { forward_to = RECEIVER_LIST } @@ -65,7 +65,7 @@ configuration. ## Example -```river +```alloy loki.relabel "gelf" { rule { source_labels = ["__gelf_message_host"] diff --git a/docs/sources/reference/components/loki.source.heroku.md b/docs/sources/reference/components/loki.source.heroku.md index 888f2ab99e..48cdc489ec 100644 --- a/docs/sources/reference/components/loki.source.heroku.md +++ b/docs/sources/reference/components/loki.source.heroku.md @@ -24,7 +24,7 @@ different labels. ## Usage -```river +```alloy loki.source.heroku "LABEL" { http { listen_address = "LISTEN_ADDRESS" @@ -107,7 +107,7 @@ configuration. This example listens for Heroku messages over TCP in the specified port and forwards them to a `loki.write` component using the Heroku timestamp. -```river +```alloy loki.source.heroku "local" { http { listen_address = "0.0.0.0" @@ -127,7 +127,7 @@ loki.write "local" { When using the default `http` block settings, the server listen for new connection on port `8080`. -```river +```alloy loki.source.heroku "local" { use_incoming_timestamp = true labels = {component = "loki.source.heroku"} diff --git a/docs/sources/reference/components/loki.source.journal.md b/docs/sources/reference/components/loki.source.journal.md index 8fbc4a7f7e..605d2c9356 100644 --- a/docs/sources/reference/components/loki.source.journal.md +++ b/docs/sources/reference/components/loki.source.journal.md @@ -12,7 +12,7 @@ Multiple `loki.source.journal` components can be specified by giving them differ ## Usage -```river +```alloy loki.source.journal "LABEL" { forward_to = RECEIVER_LIST } @@ -71,7 +71,7 @@ The final internal label name would be `__journal__systemd_unit`, with _two_ und ## Example -```river +```alloy loki.relabel "journal" { forward_to = [] diff --git a/docs/sources/reference/components/loki.source.kafka.md b/docs/sources/reference/components/loki.source.kafka.md index bb85c6d981..419f0bca63 100644 --- a/docs/sources/reference/components/loki.source.kafka.md +++ b/docs/sources/reference/components/loki.source.kafka.md @@ -21,7 +21,7 @@ Multiple `loki.source.kafka` components can be specified by giving them differen ## Usage -```river +```alloy loki.source.kafka "LABEL" { brokers = BROKER_LIST topics = TOPIC_LIST @@ -138,7 +138,7 @@ The `oauth_config` is required when the SASL mechanism is set to `OAUTHBEARER`. This example consumes Kafka events from the specified brokers and topics then forwards them to a `loki.write` component using the Kafka timestamp. -```river +```alloy loki.source.kafka "local" { brokers = ["localhost:9092"] topics = ["quickstart-events"] diff --git a/docs/sources/reference/components/loki.source.kubernetes.md b/docs/sources/reference/components/loki.source.kubernetes.md index b7fcc7c9bd..ad4cf2bb5d 100644 --- a/docs/sources/reference/components/loki.source.kubernetes.md +++ b/docs/sources/reference/components/loki.source.kubernetes.md @@ -27,7 +27,7 @@ Multiple `loki.source.kubernetes` components can be specified by giving them dif ## Usage -```river +```alloy loki.source.kubernetes "LABEL" { targets = TARGET_LIST forward_to = RECEIVER_LIST @@ -177,7 +177,7 @@ target: This example collects logs from all Kubernetes pods and forwards them to a `loki.write` component so they are written to Loki. -```river +```alloy discovery.kubernetes "pods" { role = "pod" } diff --git a/docs/sources/reference/components/loki.source.kubernetes_events.md b/docs/sources/reference/components/loki.source.kubernetes_events.md index adcd00d24b..9bcd18be63 100644 --- a/docs/sources/reference/components/loki.source.kubernetes_events.md +++ b/docs/sources/reference/components/loki.source.kubernetes_events.md @@ -13,7 +13,7 @@ Multiple `loki.source.kubernetes_events` components can be specified by giving t ## Usage -```river +```alloy loki.source.kubernetes_events "LABEL" { forward_to = RECEIVER_LIST } @@ -166,7 +166,7 @@ In Flow mode, this argument is no longer necessary. This example collects watches events in the `kube-system` namespace and forwards them to a `loki.write` component so they are written to Loki. -```river +```alloy loki.source.kubernetes_events "example" { // Only watch for events in the kube-system namespace. namespaces = ["kube-system"] diff --git a/docs/sources/reference/components/loki.source.podlogs.md b/docs/sources/reference/components/loki.source.podlogs.md index ed46dc0b01..9ad97b2705 100644 --- a/docs/sources/reference/components/loki.source.podlogs.md +++ b/docs/sources/reference/components/loki.source.podlogs.md @@ -31,7 +31,7 @@ different labels. ## Usage -```river +```alloy loki.source.podlogs "LABEL" { forward_to = RECEIVER_LIST } @@ -268,7 +268,7 @@ configuration. This example discovers all `PodLogs` resources and forwards collected logs to a `loki.write` component so they are written to Loki. -```river +```alloy loki.source.podlogs "default" { forward_to = [loki.write.local.receiver] } diff --git a/docs/sources/reference/components/loki.source.syslog.md b/docs/sources/reference/components/loki.source.syslog.md index 19fed5694d..ee2f126aa0 100644 --- a/docs/sources/reference/components/loki.source.syslog.md +++ b/docs/sources/reference/components/loki.source.syslog.md @@ -17,7 +17,7 @@ Multiple `loki.source.syslog` components can be specified by giving them differe ## Usage -```river +```alloy loki.source.syslog "LABEL" { listener { address = "LISTEN_ADDRESS" @@ -120,7 +120,7 @@ configuration. This example listens for Syslog messages in valid RFC5424 format over TCP and UDP in the specified ports and forwards them to a `loki.write` component. -```river +```alloy loki.source.syslog "local" { listener { address = "127.0.0.1:51893" diff --git a/docs/sources/reference/components/loki.source.windowsevent.md b/docs/sources/reference/components/loki.source.windowsevent.md index b0b7f4ee4e..f0a709cd07 100644 --- a/docs/sources/reference/components/loki.source.windowsevent.md +++ b/docs/sources/reference/components/loki.source.windowsevent.md @@ -12,7 +12,7 @@ Multiple `loki.source.windowsevent` components can be specified by giving them d ## Usage -```river +```alloy loki.source.windowsevent "LABEL" { eventlog_name = EVENTLOG_NAME forward_to = RECEIVER_LIST @@ -55,7 +55,7 @@ If using short form, you must define `eventlog_name`. This example collects log entries from the Event Log specified in `eventlog_name` and forwards them to a `loki.write` component so they are written to Loki. -```river +```alloy loki.source.windowsevent "application" { eventlog_name = "Application" forward_to = [loki.write.endpoint.receiver] diff --git a/docs/sources/reference/components/loki.write.md b/docs/sources/reference/components/loki.write.md index 3ce6e0554a..ece82eb65f 100644 --- a/docs/sources/reference/components/loki.write.md +++ b/docs/sources/reference/components/loki.write.md @@ -12,7 +12,7 @@ Multiple `loki.write` components can be specified by giving them different label ## Usage -```river +```alloy loki.write "LABEL" { endpoint { url = REMOTE_WRITE_URL @@ -203,7 +203,7 @@ The following examples show you how to create `loki.write` components that send You can create a `loki.write` component that sends your log entries to a local Loki instance: -```river +```alloy loki.write "local" { endpoint { url = "http://loki:3100/loki/api/v1/push" @@ -215,7 +215,7 @@ loki.write "local" { You can create a `loki.write` component that sends your log entries to a managed service, for example, Grafana Cloud. The Loki username and Grafana Cloud API Key are injected in this example through environment variables. -```river +```alloy loki.write "default" { endpoint { url = "https://logs-xxx.grafana.net/loki/api/v1/push" diff --git a/docs/sources/reference/components/mimir.rules.kubernetes.md b/docs/sources/reference/components/mimir.rules.kubernetes.md index 5a8c10c418..98f3b31210 100644 --- a/docs/sources/reference/components/mimir.rules.kubernetes.md +++ b/docs/sources/reference/components/mimir.rules.kubernetes.md @@ -34,7 +34,7 @@ in Kubernetes in order for {{< param "PRODUCT_NAME" >}} to access it via the Kub ## Usage -```river +```alloy mimir.rules.kubernetes "LABEL" { address = MIMIR_RULER_URL } @@ -209,7 +209,7 @@ This example creates a `mimir.rules.kubernetes` component that loads discovered rules to a local Mimir instance under the `team-a` tenant. Only namespaces and rules with the `alloy` label set to `yes` are included. -```river +```alloy mimir.rules.kubernetes "local" { address = "mimir:8080" tenant_id = "team-a" @@ -231,7 +231,7 @@ mimir.rules.kubernetes "local" { This example creates a `mimir.rules.kubernetes` component that loads discovered rules to Grafana Cloud. -```river +```alloy mimir.rules.kubernetes "default" { address = "GRAFANA_CLOUD_METRICS_URL" basic_auth { diff --git a/docs/sources/reference/components/otelcol.auth.basic.md b/docs/sources/reference/components/otelcol.auth.basic.md index 97dbaf0e08..6edddf109f 100644 --- a/docs/sources/reference/components/otelcol.auth.basic.md +++ b/docs/sources/reference/components/otelcol.auth.basic.md @@ -20,7 +20,7 @@ different labels. ## Usage -```river +```alloy otelcol.auth.basic "LABEL" { username = "USERNAME" password = "PASSWORD" @@ -57,7 +57,7 @@ configuration. This example configures [otelcol.exporter.otlp][] to use basic authentication: -```river +```alloy otelcol.exporter.otlp "example" { client { endpoint = "my-otlp-grpc-server:4317" diff --git a/docs/sources/reference/components/otelcol.auth.bearer.md b/docs/sources/reference/components/otelcol.auth.bearer.md index 1bdcea1885..febcc99ea7 100644 --- a/docs/sources/reference/components/otelcol.auth.bearer.md +++ b/docs/sources/reference/components/otelcol.auth.bearer.md @@ -20,7 +20,7 @@ Multiple `otelcol.auth.bearer` components can be specified by giving them differ ## Usage -```river +```alloy otelcol.auth.bearer "LABEL" { token = "TOKEN" } @@ -63,7 +63,7 @@ The example below configures [otelcol.exporter.otlp][] to use a bearer token aut If we assume that the value of the `API_KEY` environment variable is `SECRET_API_KEY`, then the `Authorization` RPC metadata is set to `Bearer SECRET_API_KEY`. -```river +```alloy otelcol.exporter.otlp "example" { client { endpoint = "my-otlp-grpc-server:4317" @@ -83,7 +83,7 @@ The example below configures [otelcol.exporter.otlphttp][] to use a bearer token If we assume that the value of the `API_KEY` environment variable is `SECRET_API_KEY`, then the `Authorization` HTTP header is set to `MyScheme SECRET_API_KEY`. -```river +```alloy otelcol.exporter.otlphttp "example" { client { endpoint = "my-otlp-grpc-server:4317" diff --git a/docs/sources/reference/components/otelcol.auth.headers.md b/docs/sources/reference/components/otelcol.auth.headers.md index 734b24c992..1da369da68 100644 --- a/docs/sources/reference/components/otelcol.auth.headers.md +++ b/docs/sources/reference/components/otelcol.auth.headers.md @@ -18,7 +18,7 @@ Multiple `otelcol.auth.headers` components can be specified by giving them diffe ## Usage -```river +```alloy otelcol.auth.headers "LABEL" { header { key = "HEADER_NAME" @@ -93,7 +93,7 @@ configuration. This example configures [otelcol.exporter.otlp][] to use custom headers: -```river +```alloy otelcol.receiver.otlp "default" { http { include_metadata = true diff --git a/docs/sources/reference/components/otelcol.auth.oauth2.md b/docs/sources/reference/components/otelcol.auth.oauth2.md index fd5f858f46..441065858b 100644 --- a/docs/sources/reference/components/otelcol.auth.oauth2.md +++ b/docs/sources/reference/components/otelcol.auth.oauth2.md @@ -22,7 +22,7 @@ different labels. ## Usage -```river +```alloy otelcol.auth.oauth2 "LABEL" { client_id = "CLIENT_ID" client_secret = "CLIENT_SECRET" @@ -90,7 +90,7 @@ configuration. This example configures [otelcol.exporter.otlp][] to use OAuth 2.0 for authentication: -```river +```alloy otelcol.exporter.otlp "example" { client { endpoint = "my-otlp-grpc-server:4317" @@ -106,7 +106,7 @@ otelcol.auth.oauth2 "creds" { ``` Here is another example with some optional attributes specified: -```river +```alloy otelcol.exporter.otlp "example" { client { endpoint = "my-otlp-grpc-server:4317" diff --git a/docs/sources/reference/components/otelcol.auth.sigv4.md b/docs/sources/reference/components/otelcol.auth.sigv4.md index 8ac55e2918..cbdf669b4b 100644 --- a/docs/sources/reference/components/otelcol.auth.sigv4.md +++ b/docs/sources/reference/components/otelcol.auth.sigv4.md @@ -27,7 +27,7 @@ different labels. ## Usage -```river +```alloy otelcol.auth.sigv4 "LABEL" { } ``` @@ -101,7 +101,7 @@ configuration. In this example the exporter endpoint starts with `aps-workspaces`. Hence `service` is inferred to be `aps` and `region` is inferred to be `us-east-1`. -```river +```alloy otelcol.exporter.otlp "example" { client { endpoint = "https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-XXX/api/v1/remote_write" @@ -118,7 +118,7 @@ otelcol.auth.sigv4 "creds" { In this example the exporter endpoint starts with `search-`. Hence `service` is inferred to be `es` and `region` is inferred to be `us-east-1`. -```river +```alloy otelcol.exporter.otlp "example" { client { endpoint = "https://search-my-domain.us-east-1.es.amazonaws.com/_search?q=house" @@ -135,7 +135,7 @@ otelcol.auth.sigv4 "creds" { In this example the exporter endpoint does not begin with `search-` or with `aps-workspaces`. Hence, we need to specify `region` and `service` explicitly. -```river +```alloy otelcol.exporter.otlp "example" { client { endpoint = "my-otlp-grpc-server:4317" @@ -153,7 +153,7 @@ otelcol.auth.sigv4 "creds" { In this example we have also specified configuration to assume a role. `sts_region` hasn't been provided, so it will default to the value of `region` which is `example_region`. -```river +```alloy otelcol.exporter.otlp "example" { client { endpoint = "my-otlp-grpc-server:4317" diff --git a/docs/sources/reference/components/otelcol.connector.host_info.md b/docs/sources/reference/components/otelcol.connector.host_info.md index 9b59674c20..7268a46a93 100644 --- a/docs/sources/reference/components/otelcol.connector.host_info.md +++ b/docs/sources/reference/components/otelcol.connector.host_info.md @@ -12,7 +12,7 @@ title: otelcol.connector.host_info ## Usage -```river +```alloy otelcol.connector.host_info "LABEL" { output { metrics = [...] @@ -59,7 +59,7 @@ The following fields are exported and can be referenced by other components: The example below accepts traces, adds the `host.id` resource attribute via the `otelcol.processor.resourcedetection` component, creates usage metrics from these traces, and writes the metrics to Mimir. -```river +```alloy otelcol.receiver.otlp "otlp" { http {} grpc {} diff --git a/docs/sources/reference/components/otelcol.connector.servicegraph.md b/docs/sources/reference/components/otelcol.connector.servicegraph.md index edfee4fa2e..de27065dd8 100644 --- a/docs/sources/reference/components/otelcol.connector.servicegraph.md +++ b/docs/sources/reference/components/otelcol.connector.servicegraph.md @@ -43,7 +43,7 @@ in front of Agent instances running `otelcol.connector.servicegraph`. ## Usage -```river +```alloy otelcol.connector.servicegraph "LABEL" { output { metrics = [...] @@ -160,7 +160,7 @@ The traces are written to Tempo. `otelcol.connector.servicegraph` also adds a label to each metric with the value of the "http.method" span/resource attribute. -```river +```alloy otelcol.receiver.otlp "default" { grpc { endpoint = "0.0.0.0:4320" diff --git a/docs/sources/reference/components/otelcol.connector.spanlogs.md b/docs/sources/reference/components/otelcol.connector.spanlogs.md index 266bdd778e..02c590ccef 100644 --- a/docs/sources/reference/components/otelcol.connector.spanlogs.md +++ b/docs/sources/reference/components/otelcol.connector.spanlogs.md @@ -21,7 +21,7 @@ You can specify multiple `otelcol.connector.spanlogs` components by giving them ## Usage -```river +```alloy otelcol.connector.spanlogs "LABEL" { output { logs = [...] @@ -105,7 +105,7 @@ The following configuration sends logs derived from spans to Loki. Additionally, `otelcol.processor.attributes` is configured with a "hint" so that `otelcol.exporter.loki` promotes the span's "attribute1" attribute to a Loki label. -```river +```alloy otelcol.receiver.otlp "default" { grpc {} diff --git a/docs/sources/reference/components/otelcol.connector.spanmetrics.md b/docs/sources/reference/components/otelcol.connector.spanmetrics.md index a3cd7b9a05..3c5c041a49 100644 --- a/docs/sources/reference/components/otelcol.connector.spanmetrics.md +++ b/docs/sources/reference/components/otelcol.connector.spanmetrics.md @@ -44,7 +44,7 @@ different labels. ## Usage -```river +```alloy otelcol.connector.spanmetrics "LABEL" { histogram { ... @@ -555,7 +555,7 @@ In the example below, `http.status_code` and `http.method` are additional dimens - `span.kind` - `status.code` -```river +```alloy otelcol.receiver.otlp "default" { http {} grpc {} @@ -621,7 +621,7 @@ This problem can be solved by doing **either** of the following: - **Recommended approach:** Prior to `otelcol.connector.spanmetrics`, remove all resource attributes from the incoming spans which are not needed by `otelcol.connector.spanmetrics`. {{< collapse title="Example configuration to remove unnecessary resource attributes." >}} - ```river + ```alloy otelcol.receiver.otlp "default" { http {} grpc {} @@ -689,7 +689,7 @@ However, the {{< term "cardinality" >}}cardinality{{< /term >}} of the metrics m The example below uses the [merge_maps][] OTTL function. {{< collapse title="Example configuration to add all resource attributes as metric datapoint attributes." >}} - ```river + ```alloy otelcol.receiver.otlp "default" { http {} grpc {} diff --git a/docs/sources/reference/components/otelcol.exporter.loadbalancing.md b/docs/sources/reference/components/otelcol.exporter.loadbalancing.md index f69a1e863c..f2e1927f2d 100644 --- a/docs/sources/reference/components/otelcol.exporter.loadbalancing.md +++ b/docs/sources/reference/components/otelcol.exporter.loadbalancing.md @@ -42,7 +42,7 @@ This should be stable enough for most cases, and the larger the number of backen ## Usage -```river +```alloy otelcol.exporter.loadbalancing "LABEL" { resolver { ... @@ -357,7 +357,7 @@ information. This example accepts OTLP logs and traces over gRPC. It then sends them in a load-balanced way to "localhost:55690" or "localhost:55700". -```river +```alloy otelcol.receiver.otlp "default" { grpc {} output { @@ -385,7 +385,7 @@ otelcol.exporter.loadbalancing "default" { When configured with a `dns` resolver, `otelcol.exporter.loadbalancing` will do a DNS lookup on regular intervals. Spans are exported to the addresses the DNS lookup returned. -```river +```alloy otelcol.exporter.loadbalancing "default" { resolver { dns { @@ -648,7 +648,7 @@ k3d cluster delete alloy-lb-test When you configure `otelcol.exporter.loadbalancing` with a `kubernetes` resolver, the Kubernetes API notifies {{< param "PRODUCT_NAME" >}} whenever a new pod is added or removed from the service. Spans are exported to the addresses from the Kubernetes API, combined with all the possible `ports`. -```river +```alloy otelcol.exporter.loadbalancing "default" { resolver { kubernetes { diff --git a/docs/sources/reference/components/otelcol.exporter.logging.md b/docs/sources/reference/components/otelcol.exporter.logging.md index 942f7e6bf0..8ca9d8070f 100644 --- a/docs/sources/reference/components/otelcol.exporter.logging.md +++ b/docs/sources/reference/components/otelcol.exporter.logging.md @@ -24,7 +24,7 @@ different labels. ## Usage -```river +```alloy otelcol.exporter.logging "LABEL" { } ``` @@ -83,7 +83,7 @@ information. This example scrapes prometheus unix metrics and writes them to the console: -```river +```alloy prometheus.exporter.unix "default" { } prometheus.scrape "default" { diff --git a/docs/sources/reference/components/otelcol.exporter.loki.md b/docs/sources/reference/components/otelcol.exporter.loki.md index f6e73c7b22..4354799bec 100644 --- a/docs/sources/reference/components/otelcol.exporter.loki.md +++ b/docs/sources/reference/components/otelcol.exporter.loki.md @@ -30,7 +30,7 @@ Multiple `otelcol.exporter.loki` components can be specified by giving them diff ## Usage -```river +```alloy otelcol.exporter.loki "LABEL" { forward_to = [...] } @@ -74,7 +74,7 @@ information. This example accepts OTLP logs over gRPC, transforms them and forwards the converted log entries to `loki.write`: -```river +```alloy otelcol.receiver.otlp "default" { grpc {} @@ -113,7 +113,7 @@ Labels will be translated to a [Prometheus format][]. For example: | `_name` | `key_name` | | `_name` | `_name` (if `PermissiveLabelSanitization` is enabled) | -```river +```alloy otelcol.receiver.otlp "default" { grpc {} diff --git a/docs/sources/reference/components/otelcol.exporter.otlp.md b/docs/sources/reference/components/otelcol.exporter.otlp.md index 6230d97b35..303728fef8 100644 --- a/docs/sources/reference/components/otelcol.exporter.otlp.md +++ b/docs/sources/reference/components/otelcol.exporter.otlp.md @@ -18,7 +18,7 @@ different labels. ## Usage -```river +```alloy otelcol.exporter.otlp "LABEL" { client { endpoint = "HOST:PORT" @@ -181,7 +181,7 @@ The following examples show you how to create an exporter to send data to differ You can create an exporter that sends your data to a local Grafana Tempo instance without TLS: -```river +```alloy otelcol.exporter.otlp "tempo" { client { endpoint = "tempo:4317" @@ -197,7 +197,7 @@ otelcol.exporter.otlp "tempo" { You can create an `otlp` exporter that sends your data to a managed service, for example, Grafana Cloud. The Tempo username and Grafana Cloud API Key are injected in this example through environment variables. -```river +```alloy otelcol.exporter.otlp "grafana_cloud_tempo" { client { endpoint = "tempo-xxx.grafana.net/tempo:443" diff --git a/docs/sources/reference/components/otelcol.exporter.otlphttp.md b/docs/sources/reference/components/otelcol.exporter.otlphttp.md index aa643c15d3..77a679f749 100644 --- a/docs/sources/reference/components/otelcol.exporter.otlphttp.md +++ b/docs/sources/reference/components/otelcol.exporter.otlphttp.md @@ -18,7 +18,7 @@ different labels. ## Usage -```river +```alloy otelcol.exporter.otlphttp "LABEL" { client { endpoint = "HOST:PORT" @@ -139,7 +139,7 @@ information. This example creates an exporter to send data to a locally running Grafana Tempo without TLS: -```river +```alloy otelcol.exporter.otlphttp "tempo" { client { endpoint = "http://tempo:4317" diff --git a/docs/sources/reference/components/otelcol.exporter.prometheus.md b/docs/sources/reference/components/otelcol.exporter.prometheus.md index fc21c7cf30..452e2d9c28 100644 --- a/docs/sources/reference/components/otelcol.exporter.prometheus.md +++ b/docs/sources/reference/components/otelcol.exporter.prometheus.md @@ -23,7 +23,7 @@ different labels. ## Usage -```river +```alloy otelcol.exporter.prometheus "LABEL" { forward_to = [...] } @@ -95,7 +95,7 @@ The following are dropped during the conversion process: This example accepts metrics over OTLP and forwards it using `prometheus.remote_write`: -```river +```alloy otelcol.receiver.otlp "default" { grpc {} @@ -125,7 +125,7 @@ This example uses `otelcol.processor.transform` to add extra `key1` and `key2` O This avoids the need to set `resource_to_telemetry_conversion` to `true`, which could have created too many unnecessary metric labels. -```river +```alloy otelcol.receiver.otlp "default" { grpc {} diff --git a/docs/sources/reference/components/otelcol.extension.jaeger_remote_sampling.md b/docs/sources/reference/components/otelcol.extension.jaeger_remote_sampling.md index 140c2d2c6d..59d79cc652 100644 --- a/docs/sources/reference/components/otelcol.extension.jaeger_remote_sampling.md +++ b/docs/sources/reference/components/otelcol.extension.jaeger_remote_sampling.md @@ -21,7 +21,7 @@ Multiple `otelcol.extension.jaeger_remote_sampling` components can be specified ## Usage -```river +```alloy otelcol.extension.jaeger_remote_sampling "LABEL" { source { } @@ -269,7 +269,7 @@ This example configures the Jaeger remote sampling extension to load a local jso serve it over the default http port of 5778. Currently this config style exists for consistency with upstream Opentelemetry Collector components and may be removed. -```river +```alloy otelcol.extension.jaeger_remote_sampling "example" { http { } @@ -286,7 +286,7 @@ otelcol.extension.jaeger_remote_sampling "example" { This example uses the output of a component to determine what sampling rules to serve: -```river +```alloy local.file "sampling" { filename = "/path/to/jaeger-sampling.json" } diff --git a/docs/sources/reference/components/otelcol.processor.attributes.md b/docs/sources/reference/components/otelcol.processor.attributes.md index ac78b387df..4dda4f50f6 100644 --- a/docs/sources/reference/components/otelcol.processor.attributes.md +++ b/docs/sources/reference/components/otelcol.processor.attributes.md @@ -19,7 +19,7 @@ You can specify multiple `otelcol.processor.attributes` components by giving the ## Usage -```river +```alloy otelcol.processor.attributes "LABEL" { output { metrics = [...] @@ -229,7 +229,7 @@ information. ### Various uses of the "action" block -```river +```alloy otelcol.receiver.otlp "default" { http {} grpc {} @@ -343,7 +343,7 @@ The following spans do not match the properties and the processor actions are ap Note that due to the presence of the `services` attribute, this configuration works only for trace signals. This is why only traces are configured in the `output` block. -```river +```alloy otelcol.processor.attributes "default" { exclude { match_type = "strict" @@ -377,7 +377,7 @@ A "strict" `match_type` means that we must strictly match the `resource` key/val Note that the `resource` attribute is not used for metrics, which is why metrics are not configured in the component output. -```river +```alloy otelcol.processor.attributes "default" { exclude { match_type = "strict" @@ -408,7 +408,7 @@ A "strict" `match_type` means that we must strictly match the `library` key/valu Note that the `library` attribute is not used for metrics, which is why metrics are not configured in the component output. -```river +```alloy otelcol.processor.attributes "default" { exclude { match_type = "strict" @@ -440,7 +440,7 @@ in spans where the service name matches `"auth.*"` and where the span name does Note that due to the presence of the `services` and `span_names` attributes, this configuration works only for trace signals. This is why only traces are configured in the `output` block. -```river +```alloy otelcol.processor.attributes "default" { // Specifies the span properties that must exist for the processor to be applied. include { @@ -480,7 +480,7 @@ The following demonstrates how to process spans with attributes that match a reg This processor will obfuscate the "db.statement" attribute in spans where the "db.statement" attribute matches a regex pattern. -```river +```alloy otelcol.processor.attributes "default" { include { // "match_type" of "regexp" defines that the "value" attributes @@ -517,7 +517,7 @@ attribute in spans where the log body matches "AUTH.*". Note that due to the presence of the `log_bodies` attribute, this configuration works only for log signals. This is why only logs are configured in the `output` block. -```river +```alloy otelcol.processor.attributes "default" { include { match_type = "regexp" @@ -548,7 +548,7 @@ obfuscate the "password" attribute in logs where the severity is at least "INFO" Note that due to the presence of the `log_severity` attribute, this configuration works only for log signals. This is why only logs are configured in the `output` block. -```river +```alloy otelcol.processor.attributes "default" { include { match_type = "regexp" @@ -582,7 +582,7 @@ attribute in logs where severity matches "info". Note that due to the presence of the `log_severity_texts` attribute, this configuration works only for log signals. This is why only logs are configured in the `output` block. -```river +```alloy otelcol.processor.attributes "default" { include { match_type = "regexp" @@ -613,7 +613,7 @@ If the label already exists, its value will be updated. Note that due to the presence of the `metric_names` attribute, this configuration works only for metric signals. This is why only metrics are configured in the `output` block. -```river +```alloy otelcol.processor.attributes "default" { include { match_type = "regexp" diff --git a/docs/sources/reference/components/otelcol.processor.batch.md b/docs/sources/reference/components/otelcol.processor.batch.md index 7216c18a41..e0bd069870 100644 --- a/docs/sources/reference/components/otelcol.processor.batch.md +++ b/docs/sources/reference/components/otelcol.processor.batch.md @@ -24,7 +24,7 @@ different labels. ## Usage -```river +```alloy otelcol.processor.batch "LABEL" { output { metrics = [...] @@ -140,7 +140,7 @@ information. This example batches telemetry data before sending it to [otelcol.exporter.otlp][] for further processing: -```river +```alloy otelcol.processor.batch "default" { output { metrics = [otelcol.exporter.otlp.production.input] @@ -161,7 +161,7 @@ otelcol.exporter.otlp "production" { This example will buffer up to 10,000 spans, metric data points, or log records for up to 10 seconds. Because `send_batch_max_size` is not set, the batch size may exceed 10,000. -```river +```alloy otelcol.processor.batch "default" { timeout = "10s" send_batch_size = 10000 @@ -185,7 +185,7 @@ otelcol.exporter.otlp "production" { Batching by metadata enables support for multi-tenant OpenTelemetry pipelines with batching over groups of data having the same authorization metadata. -```river +```alloy otelcol.receiver.jaeger "default" { protocols { grpc { diff --git a/docs/sources/reference/components/otelcol.processor.discovery.md b/docs/sources/reference/components/otelcol.processor.discovery.md index 16be8a5e71..3e4e1fd590 100644 --- a/docs/sources/reference/components/otelcol.processor.discovery.md +++ b/docs/sources/reference/components/otelcol.processor.discovery.md @@ -44,7 +44,7 @@ from Static mode's `prom_sd_operation_type`/`prom_sd_pod_associations` [configur ## Usage -```river +```alloy otelcol.processor.discovery "LABEL" { targets = [...] output { @@ -125,7 +125,7 @@ information. ## Examples ### Basic usage -```river +```alloy discovery.http "dynamic_targets" { url = "https://example.com/scrape_targets" refresh_interval = "15s" @@ -144,7 +144,7 @@ otelcol.processor.discovery "default" { Outputs from more than one discovery process can be combined via the `concat` function. -```river +```alloy discovery.http "dynamic_targets" { url = "https://example.com/scrape_targets" refresh_interval = "15s" @@ -171,7 +171,7 @@ a `test.label.with.dots` resource attributes will be added to a span if its IP a "1.2.2.2". The `__internal_label__` will be not be added to the span, because it begins with a double underscore (`__`). -```river +```alloy otelcol.processor.discovery "default" { targets = [{ "__address__" = "1.2.2.2", diff --git a/docs/sources/reference/components/otelcol.processor.filter.md b/docs/sources/reference/components/otelcol.processor.filter.md index ff5a35c6a6..b279a701a8 100644 --- a/docs/sources/reference/components/otelcol.processor.filter.md +++ b/docs/sources/reference/components/otelcol.processor.filter.md @@ -57,7 +57,7 @@ Exercise caution when using `otelcol.processor.filter`: ## Usage -```river +```alloy otelcol.processor.filter "LABEL" { output { metrics = [...] @@ -192,7 +192,7 @@ information. This example sets the attribute `test` to `pass` if the attribute `test` does not exist. -```river +```alloy otelcol.processor.filter "default" { error_mode = "ignore" @@ -218,7 +218,7 @@ This example drops metrics which satisfy at least one of two OTTL statements: * The metric name is `my.metric` and there is a `my_label` resource attribute with a value of `abc123 `. * The metric is a histogram. -```river +```alloy otelcol.processor.filter "default" { error_mode = "ignore" @@ -244,7 +244,7 @@ Some values in the {{< param "PRODUCT_NAME" >}} syntax string are [escaped][rive ### Drop non-HTTP spans and sensitive logs -```river +```alloy otelcol.processor.filter "default" { error_mode = "ignore" diff --git a/docs/sources/reference/components/otelcol.processor.k8sattributes.md b/docs/sources/reference/components/otelcol.processor.k8sattributes.md index f288d3d02d..dde7eacadc 100644 --- a/docs/sources/reference/components/otelcol.processor.k8sattributes.md +++ b/docs/sources/reference/components/otelcol.processor.k8sattributes.md @@ -18,7 +18,7 @@ You can specify multiple `otelcol.processor.k8sattributes` components by giving ## Usage -```river +```alloy otelcol.processor.k8sattributes "LABEL" { output { metrics = [...] @@ -180,7 +180,7 @@ fully through child blocks. The `pod_association` block can be repeated multiple times, to configure additional rules. Example: -```river +```alloy pod_association { source { from = "resource_attribute" @@ -271,7 +271,7 @@ In most cases, this is enough to get started. It'll add these resource attribute Example: -```river +```alloy otelcol.receiver.otlp "default" { http {} grpc {} @@ -300,7 +300,7 @@ otelcol.exporter.otlp "default" { ### Add additional metadata and labels -```river +```alloy otelcol.receiver.otlp "default" { http {} grpc {} @@ -355,7 +355,7 @@ To display the metadata as labels of Prometheus metrics, the OTLP attributes mus resource attributes to datapoint attributes. One way to do this is by using an `otelcol.processor.transform` component. -```river +```alloy otelcol.receiver.otlp "default" { http {} grpc {} diff --git a/docs/sources/reference/components/otelcol.processor.memory_limiter.md b/docs/sources/reference/components/otelcol.processor.memory_limiter.md index 9bf3ec2f9f..47e4e3094a 100644 --- a/docs/sources/reference/components/otelcol.processor.memory_limiter.md +++ b/docs/sources/reference/components/otelcol.processor.memory_limiter.md @@ -28,7 +28,7 @@ giving them different labels. ## Usage -```river +```alloy otelcol.processor.memory_limiter "LABEL" { check_interval = "1s" diff --git a/docs/sources/reference/components/otelcol.processor.probabilistic_sampler.md b/docs/sources/reference/components/otelcol.processor.probabilistic_sampler.md index b221d276df..6b43b852b0 100644 --- a/docs/sources/reference/components/otelcol.processor.probabilistic_sampler.md +++ b/docs/sources/reference/components/otelcol.processor.probabilistic_sampler.md @@ -21,7 +21,7 @@ You can specify multiple `otelcol.processor.probabilistic_sampler` components by ## Usage -```river +```alloy otelcol.processor.probabilistic_sampler "LABEL" { output { logs = [...] @@ -90,7 +90,7 @@ information. ### Basic usage -```river +```alloy otelcol.processor.probabilistic_sampler "default" { hash_seed = 123 sampling_percentage = 15.3 @@ -103,7 +103,7 @@ otelcol.processor.probabilistic_sampler "default" { ### Sample 15% of the logs -```river +```alloy otelcol.processor.probabilistic_sampler "default" { sampling_percentage = 15 @@ -115,7 +115,7 @@ otelcol.processor.probabilistic_sampler "default" { ### Sample logs according to their "logID" attribute -```river +```alloy otelcol.processor.probabilistic_sampler "default" { sampling_percentage = 15 attribute_source = "record" @@ -129,7 +129,7 @@ otelcol.processor.probabilistic_sampler "default" { ### Sample logs according to a "priority" attribute -```river +```alloy otelcol.processor.probabilistic_sampler "default" { sampling_percentage = 15 sampling_priority = "priority" diff --git a/docs/sources/reference/components/otelcol.processor.resourcedetection.md b/docs/sources/reference/components/otelcol.processor.resourcedetection.md index 305bf07726..ade8c4ac02 100644 --- a/docs/sources/reference/components/otelcol.processor.resourcedetection.md +++ b/docs/sources/reference/components/otelcol.processor.resourcedetection.md @@ -25,7 +25,7 @@ different labels. ## Usage -```river +```alloy otelcol.processor.resourcedetection "LABEL" { output { logs = [...] @@ -772,7 +772,7 @@ information. If you set up a `OTEL_RESOURCE_ATTRIBUTES` environment variable with value of `TestKey=TestValue`, then all logs, metrics, and traces have a resource attribute with a key `TestKey` and value of `TestValue`. -```river +```alloy otelcol.processor.resourcedetection "default" { detectors = ["env"] @@ -789,7 +789,7 @@ otelcol.processor.resourcedetection "default" { There is no need to put in an `ec2 {}` block. The `ec2` defaults are applied automatically, as specified in [ec2][]. -```river +```alloy otelcol.processor.resourcedetection "default" { detectors = ["env", "ec2"] @@ -806,7 +806,7 @@ otelcol.processor.resourcedetection "default" { There is no need to put in a `ec2 {}` block. The `ec2` defaults are applied automatically, as specified in [ec2][]. -```river +```alloy otelcol.processor.resourcedetection "default" { detectors = ["ec2"] @@ -820,7 +820,7 @@ otelcol.processor.resourcedetection "default" { ### ec2 with explicit resource attributes -```river +```alloy otelcol.processor.resourcedetection "default" { detectors = ["ec2"] ec2 { @@ -853,7 +853,7 @@ This example uses the default `node_from_env_var` option of `K8S_NODE_NAME`. There is no need to put in a `kubernetes_node {}` block. The `kubernetes_node` defaults are applied automatically, as specified in [kubernetes_node][]. -```river +```alloy otelcol.processor.resourcedetection "default" { detectors = ["kubernetes_node"] @@ -879,7 +879,7 @@ You need to add this to your workload: This example uses a custom `node_from_env_var` set to `my_custom_var`. -```river +```alloy otelcol.processor.resourcedetection "default" { detectors = ["kubernetes_node"] kubernetes_node { diff --git a/docs/sources/reference/components/otelcol.processor.span.md b/docs/sources/reference/components/otelcol.processor.span.md index 7709b5b180..1c05759103 100644 --- a/docs/sources/reference/components/otelcol.processor.span.md +++ b/docs/sources/reference/components/otelcol.processor.span.md @@ -22,7 +22,7 @@ You can specify multiple `otelcol.processor.span` components by giving them diff ## Usage -```river +```alloy otelcol.processor.span "LABEL" { output { traces = [...] @@ -231,7 +231,7 @@ This example creates a new span name from the values of attributes `db.svc`, `operation`, and `id`, in that order, separated by the value `::`. All attribute keys need to be specified in the span for the processor to rename it. -```river +```alloy otelcol.processor.span "default" { name { separator = "::" @@ -266,7 +266,7 @@ This is because the attribute key `operation` isn't set: ### Creating a new span name from attribute values (no separator) -```river +```alloy otelcol.processor.span "default" { name { from_attributes = ["db.svc", "operation", "id"] @@ -295,7 +295,7 @@ Example input and output using the Flow configuration below: 2. The span name will be changed to `/api/v1/document/{documentId}/update` 3. A new attribute `"documentId"="12345678"` will be added to the span. -```river +```alloy otelcol.processor.span "default" { name { to_attributes { @@ -318,7 +318,7 @@ if the span has the following properties: - The span name contains `/` anywhere in the string. - The span name is not `donot/change`. -```river +```alloy otelcol.processor.span "default" { include { match_type = "regexp" @@ -345,7 +345,7 @@ otelcol.processor.span "default" { This example changes the status of a span to "Error" and sets an error description. -```river +```alloy otelcol.processor.span "default" { status { code = "Error" @@ -363,7 +363,7 @@ otelcol.processor.span "default" { This example sets the status to success only when attribute `http.status_code` is equal to `400`. -```river +```alloy otelcol.processor.span "default" { include { match_type = "strict" diff --git a/docs/sources/reference/components/otelcol.processor.tail_sampling.md b/docs/sources/reference/components/otelcol.processor.tail_sampling.md index 6c300158ca..9cdba4491c 100644 --- a/docs/sources/reference/components/otelcol.processor.tail_sampling.md +++ b/docs/sources/reference/components/otelcol.processor.tail_sampling.md @@ -31,7 +31,7 @@ giving them different labels. ## Usage -```river +```alloy otelcol.processor.tail_sampling "LABEL" { policy { ... @@ -335,7 +335,7 @@ information. This example batches trace data from {{< param "PRODUCT_NAME" >}} before sending it to [otelcol.exporter.otlp][] for further processing. This example shows an impractical number of policies for the purpose of demonstrating how to set up each type. -```river +```alloy tracing { sampling_fraction = 1 write_to = [otelcol.processor.tail_sampling.default.input] diff --git a/docs/sources/reference/components/otelcol.processor.transform.md b/docs/sources/reference/components/otelcol.processor.transform.md index 3cd49e359f..61c19d69cb 100644 --- a/docs/sources/reference/components/otelcol.processor.transform.md +++ b/docs/sources/reference/components/otelcol.processor.transform.md @@ -85,7 +85,7 @@ to a new metric data type or can be used to create new metrics. ## Usage -```river +```alloy otelcol.processor.transform "LABEL" { output { metrics = [...] @@ -206,7 +206,7 @@ For practical purposes, this means that a context cannot make decisions on its t For example, __the following context statement is not possible__ because it attempts to use individual datapoint attributes in the condition of a statement associated to a `metric`: -```river +```alloy metric_statements { context = "metric" statements = [ @@ -223,7 +223,7 @@ Context __ALWAYS__ supply access to the items "higher" in the protobuf definitio For example, __the following context statement is possible__ because `datapoint` statements can access the datapoint's metric. -```river +```alloy metric_statements { context = "datapoint" statements = [ @@ -277,7 +277,7 @@ information. This example sets the attribute `test` to `pass` if the attribute `test` does not exist. -```river +```alloy otelcol.processor.transform "default" { error_mode = "ignore" @@ -306,7 +306,7 @@ each `"` with a `\"` inside a [normal][river-strings] {{< param "PRODUCT_NAME" > The are two ways to rename an attribute key. One way is to set a new attribute and delete the old one: -```river +```alloy otelcol.processor.transform "default" { error_mode = "ignore" @@ -328,7 +328,7 @@ otelcol.processor.transform "default" { Another way is to update the key using regular expressions: -```river +```alloy otelcol.processor.transform "default" { error_mode = "ignore" @@ -355,7 +355,7 @@ each `"` with a `\"`, and each `\` with a `\\` inside a [normal][river-strings] This example sets the attribute `body` to the value of the log body: -```river +```alloy otelcol.processor.transform "default" { error_mode = "ignore" @@ -382,7 +382,7 @@ each `"` with a `\"` inside a [normal][river-strings] {{< param "PRODUCT_NAME" > This example sets the attribute `test` to the value of attributes `service.name` and `service.version` combined. -```river +```alloy otelcol.processor.transform "default" { error_mode = "ignore" @@ -423,7 +423,7 @@ Given the following JSON body: You can add specific fields as attributes on the log: -```river +```alloy otelcol.processor.transform "default" { error_mode = "ignore" @@ -463,7 +463,7 @@ each `"` with a `\"`, and each `\` with a `\\` inside a [normal][river-strings] The example takes advantage of context efficiency by grouping transformations with the context which it intends to transform. -```river +```alloy otelcol.receiver.otlp "default" { http {} grpc {} diff --git a/docs/sources/reference/components/otelcol.receiver.jaeger.md b/docs/sources/reference/components/otelcol.receiver.jaeger.md index 0d34dc1ed3..54e0866f55 100644 --- a/docs/sources/reference/components/otelcol.receiver.jaeger.md +++ b/docs/sources/reference/components/otelcol.receiver.jaeger.md @@ -18,7 +18,7 @@ different labels. ## Usage -```river +```alloy otelcol.receiver.jaeger "LABEL" { protocols { grpc {} @@ -243,7 +243,7 @@ information. This example creates a pipeline which accepts Jaeger-formatted traces and writes them to an OTLP server: -```river +```alloy otelcol.receiver.jaeger "default" { protocols { grpc {} diff --git a/docs/sources/reference/components/otelcol.receiver.kafka.md b/docs/sources/reference/components/otelcol.receiver.kafka.md index 312e2fe7ee..7174c4f1c2 100644 --- a/docs/sources/reference/components/otelcol.receiver.kafka.md +++ b/docs/sources/reference/components/otelcol.receiver.kafka.md @@ -19,7 +19,7 @@ different labels. ## Usage -```river +```alloy otelcol.receiver.kafka "LABEL" { brokers = ["BROKER_ADDR"] protocol_version = "PROTOCOL_VERSION" @@ -299,7 +299,7 @@ information. This example forwards read telemetry data through a batch processor before finally sending it to an OTLP-capable endpoint: -```river +```alloy otelcol.receiver.kafka "default" { brokers = ["localhost:9092"] protocol_version = "2.0.0" diff --git a/docs/sources/reference/components/otelcol.receiver.loki.md b/docs/sources/reference/components/otelcol.receiver.loki.md index 06beab8a4b..cf5ee9cd0e 100644 --- a/docs/sources/reference/components/otelcol.receiver.loki.md +++ b/docs/sources/reference/components/otelcol.receiver.loki.md @@ -18,7 +18,7 @@ different labels. ## Usage -```river +```alloy otelcol.receiver.loki "LABEL" { output { logs = [...] @@ -73,7 +73,7 @@ to. The logs are converted to the OTLP format before they are forwarded to the `otelcol.exporter.otlp` component to be sent to an OTLP-capable endpoint: -```river +```alloy loki.source.file "default" { targets = [ {__path__ = "/tmp/foo.txt", "loki.format" = "logfmt"}, diff --git a/docs/sources/reference/components/otelcol.receiver.opencensus.md b/docs/sources/reference/components/otelcol.receiver.opencensus.md index 0884f6b1b8..a7bcc17acc 100644 --- a/docs/sources/reference/components/otelcol.receiver.opencensus.md +++ b/docs/sources/reference/components/otelcol.receiver.opencensus.md @@ -20,7 +20,7 @@ different labels. ## Usage -```river +```alloy otelcol.receiver.opencensus "LABEL" { output { metrics = [...] @@ -151,7 +151,7 @@ information. This example forwards received telemetry data through a batch processor before finally sending it to an OTLP-capable endpoint: -```river +```alloy otelcol.receiver.opencensus "default" { cors_allowed_origins = ["https://*.test.com", "https://test.com"] diff --git a/docs/sources/reference/components/otelcol.receiver.otlp.md b/docs/sources/reference/components/otelcol.receiver.otlp.md index 251ec9d6f6..8309f3d0aa 100644 --- a/docs/sources/reference/components/otelcol.receiver.otlp.md +++ b/docs/sources/reference/components/otelcol.receiver.otlp.md @@ -18,7 +18,7 @@ different labels. ## Usage -```river +```alloy otelcol.receiver.otlp "LABEL" { grpc { ... } http { ... } @@ -213,7 +213,7 @@ information. This example forwards received telemetry data through a batch processor before finally sending it to an OTLP-capable endpoint: -```river +```alloy otelcol.receiver.otlp "default" { http {} grpc {} diff --git a/docs/sources/reference/components/otelcol.receiver.prometheus.md b/docs/sources/reference/components/otelcol.receiver.prometheus.md index 5dccc0b99d..ebfeef9182 100644 --- a/docs/sources/reference/components/otelcol.receiver.prometheus.md +++ b/docs/sources/reference/components/otelcol.receiver.prometheus.md @@ -19,7 +19,7 @@ different labels. ## Usage -```river +```alloy otelcol.receiver.prometheus "LABEL" { output { metrics = [...] @@ -74,7 +74,7 @@ data to. The metrics are converted to the OTLP format before they are forwarded to the `otelcol.exporter.otlp` component to be sent to an OTLP-capable endpoint: -```river +```alloy prometheus.scrape "default" { // Collect metrics from the default HTTP listen address. targets = [{"__address__" = "127.0.0.1:12345"}] diff --git a/docs/sources/reference/components/otelcol.receiver.vcenter.md b/docs/sources/reference/components/otelcol.receiver.vcenter.md index 8694e7a85f..5b70fc7c50 100644 --- a/docs/sources/reference/components/otelcol.receiver.vcenter.md +++ b/docs/sources/reference/components/otelcol.receiver.vcenter.md @@ -38,7 +38,7 @@ A “Read Only” user assigned to a vSphere with permissions to the vCenter ser ## Usage -```river +```alloy otelcol.receiver.vcenter "LABEL" { endpoint = "VCENTER_ENDPOINT" username = "VCENTER_USERNAME" @@ -193,7 +193,7 @@ information. This example forwards received telemetry data through a batch processor before finally sending it to an OTLP-capable endpoint: -```river +```alloy otelcol.receiver.vcenter "default" { endpoint = "http://localhost:15672" username = "otelu" diff --git a/docs/sources/reference/components/otelcol.receiver.zipkin.md b/docs/sources/reference/components/otelcol.receiver.zipkin.md index 205d33ab76..d8d8c33173 100644 --- a/docs/sources/reference/components/otelcol.receiver.zipkin.md +++ b/docs/sources/reference/components/otelcol.receiver.zipkin.md @@ -18,7 +18,7 @@ different labels. ## Usage -```river +```alloy otelcol.receiver.zipkin "LABEL" { output { traces = [...] @@ -117,7 +117,7 @@ information. This example forwards received traces through a batch processor before finally sending it to an OTLP-capable endpoint: -```river +```alloy otelcol.receiver.zipkin "default" { output { traces = [otelcol.processor.batch.default.input] diff --git a/docs/sources/reference/components/prometheus.exporter.apache.md b/docs/sources/reference/components/prometheus.exporter.apache.md index 4c9b9acc6b..ed24b25f17 100644 --- a/docs/sources/reference/components/prometheus.exporter.apache.md +++ b/docs/sources/reference/components/prometheus.exporter.apache.md @@ -11,7 +11,7 @@ The `prometheus.exporter.apache` component embeds ## Usage -```river +```alloy prometheus.exporter.apache "LABEL" { } ``` @@ -52,7 +52,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.apache`: -```river +```alloy prometheus.exporter.apache "example" { scrape_uri = "http://web.example.com/server-status?auto" } diff --git a/docs/sources/reference/components/prometheus.exporter.azure.md b/docs/sources/reference/components/prometheus.exporter.azure.md index d02385f94d..9bd4367db5 100644 --- a/docs/sources/reference/components/prometheus.exporter.azure.md +++ b/docs/sources/reference/components/prometheus.exporter.azure.md @@ -34,7 +34,7 @@ The account used by {{< param "PRODUCT_NAME" >}} needs: ## Usage -```river +```alloy prometheus.exporter.azure LABEL { subscriptions = [ SUB_ID_1, @@ -115,7 +115,7 @@ debug metrics. ## Examples -```river +```alloy prometheus.exporter.azure "example" { subscriptions = SUBSCRIPTIONS resource_type = "Microsoft.Storage/storageAccounts" diff --git a/docs/sources/reference/components/prometheus.exporter.blackbox.md b/docs/sources/reference/components/prometheus.exporter.blackbox.md index 39d02ef419..b37394bd61 100644 --- a/docs/sources/reference/components/prometheus.exporter.blackbox.md +++ b/docs/sources/reference/components/prometheus.exporter.blackbox.md @@ -11,7 +11,7 @@ The `prometheus.exporter.blackbox` component embeds ## Usage -```river +```alloy prometheus.exporter.blackbox "LABEL" { target { name = "example" @@ -96,7 +96,7 @@ from `prometheus.exporter.blackbox`. It adds an extra label, `env="dev"`, to the The `config_file` argument is used to define which `blackbox_exporter` modules to use. You can use the [blackbox example config file](https://github.com/prometheus/blackbox_exporter/blob/master/example.yml). -```river +```alloy prometheus.exporter.blackbox "example" { config_file = "blackbox_modules.yml" @@ -144,7 +144,7 @@ Replace the following: This example is the same above with using an embedded configuration: -```river +```alloy prometheus.exporter.blackbox "example" { config = "{ modules: { http_2xx: { prober: http, timeout: 5s } } }" diff --git a/docs/sources/reference/components/prometheus.exporter.cadvisor.md b/docs/sources/reference/components/prometheus.exporter.cadvisor.md index 6f4ee0ba04..35af5624ff 100644 --- a/docs/sources/reference/components/prometheus.exporter.cadvisor.md +++ b/docs/sources/reference/components/prometheus.exporter.cadvisor.md @@ -10,7 +10,7 @@ The `prometheus.exporter.cadvisor` component exposes container metrics using ## Usage -```river +```alloy prometheus.exporter.cadvisor "LABEL" { } ``` @@ -89,7 +89,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.cadvisor`: -```river +```alloy prometheus.exporter.cadvisor "example" { docker_host = "unix:///var/run/docker.sock" diff --git a/docs/sources/reference/components/prometheus.exporter.cloudwatch.md b/docs/sources/reference/components/prometheus.exporter.cloudwatch.md index aa64df8aac..0d956875bf 100644 --- a/docs/sources/reference/components/prometheus.exporter.cloudwatch.md +++ b/docs/sources/reference/components/prometheus.exporter.cloudwatch.md @@ -88,7 +88,7 @@ To use all of the integration features, use the following AWS IAM Policy: ## Usage -```river +```alloy prometheus.exporter.cloudwatch "queues" { sts_region = "us-east-2" @@ -159,7 +159,7 @@ under that service/namespace. {{< param "PRODUCT_NAME" >}} will find AWS resources in the specified service for which to scrape these metrics, label them appropriately, and export them to Prometheus. For example, if we wanted to scrape CPU utilization and network traffic metrics from all AWS EC2 instances: -```river +```alloy prometheus.exporter.cloudwatch "discover_instances" { sts_region = "us-east-2" @@ -208,7 +208,7 @@ qualified with the following specifications: For example, if you want to scrape the same metrics in the discovery example, but for a specific AWS EC2 instance: -```river +```alloy prometheus.exporter.cloudwatch "static_instances" { sts_region = "us-east-2" @@ -231,7 +231,7 @@ prometheus.exporter.cloudwatch "static_instances" { As shown above, `static` blocks must be specified with a label, which will translate to the `name` label in the exported metric. -```river +```alloy static "LABEL" { regions = ["us-east-2"] namespace = "AWS/EC2" diff --git a/docs/sources/reference/components/prometheus.exporter.consul.md b/docs/sources/reference/components/prometheus.exporter.consul.md index eaafc7206a..eacbc11545 100644 --- a/docs/sources/reference/components/prometheus.exporter.consul.md +++ b/docs/sources/reference/components/prometheus.exporter.consul.md @@ -11,7 +11,7 @@ The `prometheus.exporter.consul` component embeds ## Usage -```river +```alloy prometheus.exporter.consul "LABEL" { } ``` @@ -62,7 +62,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.consul`: -```river +```alloy prometheus.exporter.consul "example" { server = "https://consul.example.com:8500" } diff --git a/docs/sources/reference/components/prometheus.exporter.dnsmasq.md b/docs/sources/reference/components/prometheus.exporter.dnsmasq.md index 243bc03a15..e29d36b6ec 100644 --- a/docs/sources/reference/components/prometheus.exporter.dnsmasq.md +++ b/docs/sources/reference/components/prometheus.exporter.dnsmasq.md @@ -11,7 +11,7 @@ The `prometheus.exporter.dnsmasq` component embeds ## Usage -```river +```alloy prometheus.exporter.dnsmasq "LABEL" { } ``` @@ -52,7 +52,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.dnsmasq`: -```river +```alloy prometheus.exporter.dnsmasq "example" { address = "localhost:53" } diff --git a/docs/sources/reference/components/prometheus.exporter.elasticsearch.md b/docs/sources/reference/components/prometheus.exporter.elasticsearch.md index 147141f227..37d9878eec 100644 --- a/docs/sources/reference/components/prometheus.exporter.elasticsearch.md +++ b/docs/sources/reference/components/prometheus.exporter.elasticsearch.md @@ -20,7 +20,7 @@ security privileges necessary for monitoring your node, as per the [official doc ## Usage -```river +```alloy prometheus.exporter.elasticsearch "LABEL" { address = "ELASTICSEARCH_ADDRESS" } @@ -91,7 +91,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.elasticsearch`: -```river +```alloy prometheus.exporter.elasticsearch "example" { address = "http://localhost:9200" basic_auth { diff --git a/docs/sources/reference/components/prometheus.exporter.gcp.md b/docs/sources/reference/components/prometheus.exporter.gcp.md index 2f0c8ea0e5..4ca55beb42 100644 --- a/docs/sources/reference/components/prometheus.exporter.gcp.md +++ b/docs/sources/reference/components/prometheus.exporter.gcp.md @@ -34,7 +34,7 @@ Since the exporter gathers all of its data from [GCP monitoring APIs](https://cl ## Usage -```river +```alloy prometheus.exporter.gcp "pubsub" { project_ids = [ "foo", @@ -96,7 +96,7 @@ debug metrics. ## Examples -```river +```alloy prometheus.exporter.gcp "pubsub_full_config" { project_ids = [ "foo", @@ -138,7 +138,7 @@ prometheus.exporter.gcp "pubsub_full_config" { } ``` -```river +```alloy prometheus.exporter.gcp "lb_with_filter" { project_ids = [ "foo", @@ -153,7 +153,7 @@ prometheus.exporter.gcp "lb_with_filter" { } ``` -```river +```alloy prometheus.exporter.gcp "lb_subset_with_filter" { project_ids = [ "foo", diff --git a/docs/sources/reference/components/prometheus.exporter.github.md b/docs/sources/reference/components/prometheus.exporter.github.md index 0167fbb347..a55038d6a0 100644 --- a/docs/sources/reference/components/prometheus.exporter.github.md +++ b/docs/sources/reference/components/prometheus.exporter.github.md @@ -11,7 +11,7 @@ The `prometheus.exporter.github` component embeds ## Usage -```river +```alloy prometheus.exporter.github "LABEL" { } ``` @@ -59,7 +59,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.github`: -```river +```alloy prometheus.exporter.github "example" { api_token_file = "/etc/github-api-token" repositories = ["grafana/alloy"] diff --git a/docs/sources/reference/components/prometheus.exporter.kafka.md b/docs/sources/reference/components/prometheus.exporter.kafka.md index 643505c804..5357c1d18b 100644 --- a/docs/sources/reference/components/prometheus.exporter.kafka.md +++ b/docs/sources/reference/components/prometheus.exporter.kafka.md @@ -11,7 +11,7 @@ The `prometheus.exporter.kafka` component embeds ## Usage -```river +```alloy prometheus.exporter.kafka "LABEL" { kafka_uris = KAFKA_URI_LIST } @@ -72,7 +72,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.kafka`: -```river +```alloy prometheus.exporter.kafka "example" { kafka_uris = ["localhost:9200"] } diff --git a/docs/sources/reference/components/prometheus.exporter.memcached.md b/docs/sources/reference/components/prometheus.exporter.memcached.md index f0c06223bb..cc4f146ebd 100644 --- a/docs/sources/reference/components/prometheus.exporter.memcached.md +++ b/docs/sources/reference/components/prometheus.exporter.memcached.md @@ -11,7 +11,7 @@ The `prometheus.exporter.memcached` component embeds ## Usage -```river +```alloy prometheus.exporter.memcached "LABEL" { } ``` @@ -64,7 +64,7 @@ debug metrics. This example uses a `prometheus.exporter.memcached` component to collect metrics from a Memcached server running locally, and scrapes the metrics using a [prometheus.scrape][scrape] component: -```river +```alloy prometheus.exporter.memcached "example" { address = "localhost:13321" timeout = "5s" diff --git a/docs/sources/reference/components/prometheus.exporter.mongodb.md b/docs/sources/reference/components/prometheus.exporter.mongodb.md index bdcfcf8e62..b0acec2b67 100644 --- a/docs/sources/reference/components/prometheus.exporter.mongodb.md +++ b/docs/sources/reference/components/prometheus.exporter.mongodb.md @@ -17,7 +17,7 @@ Refer to the [Percona documentation](https://github.com/percona/mongodb_exporter ## Usage -```river +```alloy prometheus.exporter.mongodb "LABEL" { mongodb_uri = "MONGODB_URI" } @@ -64,7 +64,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.mongodb`: -```river +```alloy prometheus.exporter.mongodb "example" { mongodb_uri = "mongodb://127.0.0.1:27017" } diff --git a/docs/sources/reference/components/prometheus.exporter.mssql.md b/docs/sources/reference/components/prometheus.exporter.mssql.md index 644686ec37..f8d0fd7d6a 100644 --- a/docs/sources/reference/components/prometheus.exporter.mssql.md +++ b/docs/sources/reference/components/prometheus.exporter.mssql.md @@ -12,7 +12,7 @@ Prometheus metrics. ## Usage -```river +```alloy prometheus.exporter.mssql "LABEL" { connection_string = CONNECTION_STRING } @@ -93,7 +93,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.mssql`: -```river +```alloy prometheus.exporter.mssql "example" { connection_string = "sqlserver://user:pass@localhost:1433" } diff --git a/docs/sources/reference/components/prometheus.exporter.mysql.md b/docs/sources/reference/components/prometheus.exporter.mysql.md index f062888739..b41a9553cd 100644 --- a/docs/sources/reference/components/prometheus.exporter.mysql.md +++ b/docs/sources/reference/components/prometheus.exporter.mysql.md @@ -11,7 +11,7 @@ The `prometheus.exporter.mysql` component embeds ## Usage -```river +```alloy prometheus.exporter.mysql "LABEL" { data_source_name = DATA_SOURCE_NAME } @@ -176,7 +176,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.mysql`: -```river +```alloy prometheus.exporter.mysql "example" { data_source_name = "root@(server-a:3306)/" enable_collectors = ["heartbeat", "mysql.user"] diff --git a/docs/sources/reference/components/prometheus.exporter.oracledb.md b/docs/sources/reference/components/prometheus.exporter.oracledb.md index ccad3484ec..f1f74d071e 100644 --- a/docs/sources/reference/components/prometheus.exporter.oracledb.md +++ b/docs/sources/reference/components/prometheus.exporter.oracledb.md @@ -11,7 +11,7 @@ The `prometheus.exporter.oracledb` component embeds ## Usage -```river +```alloy prometheus.exporter.oracledb "LABEL" { connection_string = CONNECTION_STRING } @@ -65,7 +65,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.oracledb`: -```river +```alloy prometheus.exporter.oracledb "example" { connection_string = "oracle://user:password@localhost:1521/orcl.localnet" } diff --git a/docs/sources/reference/components/prometheus.exporter.postgres.md b/docs/sources/reference/components/prometheus.exporter.postgres.md index ae124cdd03..52645f30d4 100644 --- a/docs/sources/reference/components/prometheus.exporter.postgres.md +++ b/docs/sources/reference/components/prometheus.exporter.postgres.md @@ -16,7 +16,7 @@ labels. ## Usage -```river +```alloy prometheus.exporter.postgres "LABEL" { data_source_names = DATA_SOURCE_NAMES_LIST } @@ -91,7 +91,7 @@ debug metrics. This example uses a `prometheus.exporter.postgres` component to collect metrics from a Postgres server running locally with all default settings: -```river +```alloy // Because no autodiscovery is defined, this will only scrape the 'database_name' database, as defined // in the DSN below. prometheus.exporter.postgres "example" { @@ -126,7 +126,7 @@ Replace the following: This example uses a `prometheus.exporter.postgres` component to collect custom metrics from a set of specific databases, replacing default metrics with custom metrics derived from queries in `/etc/agent/custom-postgres-metrics.yaml`: -```river +```alloy prometheus.exporter.postgres "example" { data_source_names = ["postgresql://username:password@localhost:5432/database_name?sslmode=disable"] @@ -170,7 +170,7 @@ Replace the following: This example uses a `prometheus.exporter.postgres` component to collect custom metrics from all databases except for the `secrets` database. -```river +```alloy prometheus.exporter.postgres "example" { data_source_names = ["postgresql://username:password@localhost:5432/database_name?sslmode=disable"] diff --git a/docs/sources/reference/components/prometheus.exporter.process.md b/docs/sources/reference/components/prometheus.exporter.process.md index bc38cae844..f709ed66eb 100644 --- a/docs/sources/reference/components/prometheus.exporter.process.md +++ b/docs/sources/reference/components/prometheus.exporter.process.md @@ -11,7 +11,7 @@ The `prometheus.exporter.process` component embeds ## Usage -```river +```alloy prometheus.exporter.process "LABEL" { } ``` @@ -94,7 +94,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.process`: -```river +```alloy prometheus.exporter.process "example" { track_children = false diff --git a/docs/sources/reference/components/prometheus.exporter.redis.md b/docs/sources/reference/components/prometheus.exporter.redis.md index 0f02e4f3d4..f3bb2d51f4 100644 --- a/docs/sources/reference/components/prometheus.exporter.redis.md +++ b/docs/sources/reference/components/prometheus.exporter.redis.md @@ -11,7 +11,7 @@ The `prometheus.exporter.redis` component embeds ## Usage -```river +```alloy prometheus.exporter.redis "LABEL" { redis_addr = REDIS_ADDRESS } @@ -96,7 +96,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.redis`: -```river +```alloy prometheus.exporter.redis "example" { redis_addr = "localhost:6379" } diff --git a/docs/sources/reference/components/prometheus.exporter.self.md b/docs/sources/reference/components/prometheus.exporter.self.md index 0b700825ed..8a4fbc9f27 100644 --- a/docs/sources/reference/components/prometheus.exporter.self.md +++ b/docs/sources/reference/components/prometheus.exporter.self.md @@ -10,7 +10,7 @@ The `prometheus.exporter.self` component collects and exposes metrics about {{< ## Usage -```river +```alloy prometheus.exporter.self "agent" { } ``` @@ -43,7 +43,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.self`: -```river +```alloy prometheus.exporter.self "example" {} // Configure a prometheus.scrape component to collect agent metrics. diff --git a/docs/sources/reference/components/prometheus.exporter.snmp.md b/docs/sources/reference/components/prometheus.exporter.snmp.md index d910dd3018..cac64066d5 100644 --- a/docs/sources/reference/components/prometheus.exporter.snmp.md +++ b/docs/sources/reference/components/prometheus.exporter.snmp.md @@ -15,7 +15,7 @@ The `prometheus.exporter.snmp` component embeds ## Usage -```river +```alloy prometheus.exporter.snmp "LABEL" { config_file = SNMP_CONFIG_FILE_PATH @@ -107,7 +107,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.snmp`: -```river +```alloy prometheus.exporter.snmp "example" { config_file = "snmp_modules.yml" @@ -140,7 +140,7 @@ prometheus.scrape "demo" { This example is the same above with using an embedded configuration (with secrets): -```river +```alloy local.file "snmp_config" { path = "snmp_modules.yml" is_secret = true diff --git a/docs/sources/reference/components/prometheus.exporter.snowflake.md b/docs/sources/reference/components/prometheus.exporter.snowflake.md index 30e676e9f4..1319520d59 100644 --- a/docs/sources/reference/components/prometheus.exporter.snowflake.md +++ b/docs/sources/reference/components/prometheus.exporter.snowflake.md @@ -11,7 +11,7 @@ The `prometheus.exporter.snowflake` component embeds ## Usage -```river +```alloy prometheus.exporter.snowflake "LABEL" { account_name = ACCOUNT_NAME username = USERNAME @@ -63,7 +63,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.snowflake`: -```river +```alloy prometheus.exporter.snowflake "example" { account_name = "XXXXXXX-YYYYYYY" username = "grafana" diff --git a/docs/sources/reference/components/prometheus.exporter.squid.md b/docs/sources/reference/components/prometheus.exporter.squid.md index ab85cccb78..e8031710cc 100644 --- a/docs/sources/reference/components/prometheus.exporter.squid.md +++ b/docs/sources/reference/components/prometheus.exporter.squid.md @@ -11,7 +11,7 @@ The `prometheus.exporter.squid` component embeds ## Usage -```river +```alloy prometheus.exporter.squid "LABEL" { address = SQUID_ADDRESS } @@ -58,7 +58,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.squid`: -```river +```alloy prometheus.exporter.squid "example" { address = "localhost:3128" } diff --git a/docs/sources/reference/components/prometheus.exporter.statsd.md b/docs/sources/reference/components/prometheus.exporter.statsd.md index 799ec989c6..a2460cf210 100644 --- a/docs/sources/reference/components/prometheus.exporter.statsd.md +++ b/docs/sources/reference/components/prometheus.exporter.statsd.md @@ -11,7 +11,7 @@ The `prometheus.exporter.statsd` component embeds ## Usage -```river +```alloy prometheus.exporter.statsd "LABEL" { } ``` @@ -77,7 +77,7 @@ debug metrics. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.statsd`: -```river +```alloy prometheus.exporter.statsd "example" { listen_udp = "" listen_tcp = ":9125" diff --git a/docs/sources/reference/components/prometheus.exporter.unix.md b/docs/sources/reference/components/prometheus.exporter.unix.md index 7384e2aecc..a96fff1ae3 100644 --- a/docs/sources/reference/components/prometheus.exporter.unix.md +++ b/docs/sources/reference/components/prometheus.exporter.unix.md @@ -19,7 +19,7 @@ Multiple `prometheus.exporter.unix` components can be specified by giving them d ## Usage -```river +```alloy prometheus.exporter.unix "LABEL" { } ``` @@ -378,7 +378,7 @@ properly. This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.unix`: -```river +```alloy prometheus.exporter.unix "demo" { } // Configure a prometheus.scrape component to collect unix metrics. diff --git a/docs/sources/reference/components/prometheus.exporter.windows.md b/docs/sources/reference/components/prometheus.exporter.windows.md index fa270202f1..f9743190a3 100644 --- a/docs/sources/reference/components/prometheus.exporter.windows.md +++ b/docs/sources/reference/components/prometheus.exporter.windows.md @@ -19,7 +19,7 @@ The include and exclude configuration options are preferred going forward. ## Usage -```river +```alloy prometheus.exporter.windows "LABEL" { } ``` @@ -291,7 +291,7 @@ These include but aren't limited to mscluster_*, vmware, nps, dns, msmq, teradic This example uses a [`prometheus.scrape` component][scrape] to collect metrics from `prometheus.exporter.windows`: -```river +```alloy prometheus.exporter.windows "default" { } // Configure a prometheus.scrape component to collect windows metrics. diff --git a/docs/sources/reference/components/prometheus.operator.podmonitors.md b/docs/sources/reference/components/prometheus.operator.podmonitors.md index b1fc4c413c..7bf6c9d376 100644 --- a/docs/sources/reference/components/prometheus.operator.podmonitors.md +++ b/docs/sources/reference/components/prometheus.operator.podmonitors.md @@ -22,7 +22,7 @@ PodMonitors may reference secrets for authenticating to targets to scrape them. ## Usage -```river +```alloy prometheus.operator.podmonitors "LABEL" { forward_to = RECEIVER_LIST } @@ -211,7 +211,7 @@ It also exposes some debug information for each PodMonitor it has discovered, in This example discovers all PodMonitors in your cluster, and forwards collected metrics to a `prometheus.remote_write` component. -```river +```alloy prometheus.remote_write "staging" { // Send metrics to a locally running Mimir. endpoint { @@ -231,7 +231,7 @@ prometheus.operator.podmonitors "pods" { This example will limit discovered PodMonitors to ones with the label `team=ops` in a specific namespace: `my-app`. -```river +```alloy prometheus.operator.podmonitors "pods" { forward_to = [prometheus.remote_write.staging.receiver] namespaces = ["my-app"] @@ -247,7 +247,7 @@ prometheus.operator.podmonitors "pods" { This example will apply additional relabel rules to discovered targets to filter by hostname. This may be useful if running {{< param "PRODUCT_NAME" >}} as a DaemonSet. -```river +```alloy prometheus.operator.podmonitors "pods" { forward_to = [prometheus.remote_write.staging.receiver] rule { diff --git a/docs/sources/reference/components/prometheus.operator.probes.md b/docs/sources/reference/components/prometheus.operator.probes.md index c9d1d89276..7f0dbc3ec2 100644 --- a/docs/sources/reference/components/prometheus.operator.probes.md +++ b/docs/sources/reference/components/prometheus.operator.probes.md @@ -25,7 +25,7 @@ In these cases, the secrets are loaded and refreshed only when the Probe is upda ## Usage -```river +```alloy prometheus.operator.probes "LABEL" { forward_to = RECEIVER_LIST } @@ -213,7 +213,7 @@ It also exposes some debug information for each Probe it has discovered, includi This example discovers all Probes in your cluster, and forwards collected metrics to a `prometheus.remote_write` component. -```river +```alloy prometheus.remote_write "staging" { // Send metrics to a locally running Mimir. endpoint { @@ -233,7 +233,7 @@ prometheus.operator.probes "pods" { This example will limit discovered Probes to ones with the label `team=ops` in a specific namespace: `my-app`. -```river +```alloy prometheus.operator.probes "pods" { forward_to = [prometheus.remote_write.staging.receiver] namespaces = ["my-app"] @@ -249,7 +249,7 @@ prometheus.operator.probes "pods" { This example will apply additional relabel rules to discovered targets to filter by hostname. This may be useful if running {{< param "PRODUCT_NAME" >}} as a DaemonSet. -```river +```alloy prometheus.operator.probes "probes" { forward_to = [prometheus.remote_write.staging.receiver] rule { diff --git a/docs/sources/reference/components/prometheus.operator.servicemonitors.md b/docs/sources/reference/components/prometheus.operator.servicemonitors.md index 693edb062a..9229f2c331 100644 --- a/docs/sources/reference/components/prometheus.operator.servicemonitors.md +++ b/docs/sources/reference/components/prometheus.operator.servicemonitors.md @@ -24,7 +24,7 @@ In these cases, the secrets are loaded and refreshed only when the ServiceMonito ## Usage -```river +```alloy prometheus.operator.servicemonitors "LABEL" { forward_to = RECEIVER_LIST } @@ -213,7 +213,7 @@ It also exposes some debug information for each ServiceMonitor it has discovered This example discovers all ServiceMonitors in your cluster, and forwards collected metrics to a `prometheus.remote_write` component. -```river +```alloy prometheus.remote_write "staging" { // Send metrics to a locally running Mimir. endpoint { @@ -233,7 +233,7 @@ prometheus.operator.servicemonitors "services" { This example will limit discovered ServiceMonitors to ones with the label `team=ops` in a specific namespace: `my-app`. -```river +```alloy prometheus.operator.servicemonitors "services" { forward_to = [prometheus.remote_write.staging.receiver] namespaces = ["my-app"] @@ -249,7 +249,7 @@ prometheus.operator.servicemonitors "services" { This example will apply additional relabel rules to discovered targets to filter by hostname. This may be useful if running {{< param "PRODUCT_NAME" >}} as a DaemonSet. -```river +```alloy prometheus.operator.servicemonitors "services" { forward_to = [prometheus.remote_write.staging.receiver] rule { diff --git a/docs/sources/reference/components/prometheus.receive_http.md b/docs/sources/reference/components/prometheus.receive_http.md index 2ffe9804a3..63ca72cfc0 100644 --- a/docs/sources/reference/components/prometheus.receive_http.md +++ b/docs/sources/reference/components/prometheus.receive_http.md @@ -15,7 +15,7 @@ The HTTP API exposed is compatible with [Prometheus `remote_write` API][promethe ## Usage -```river +```alloy prometheus.receive_http "LABEL" { http { listen_address = "LISTEN_ADDRESS" @@ -76,7 +76,7 @@ The following are some of the metrics that are exposed when this component is us This example creates a `prometheus.receive_http` component which starts an HTTP server listening on `0.0.0.0` and port `9999`. The server receives metrics and forwards them to a `prometheus.remote_write` component which writes these metrics to the specified HTTP endpoint. -```river +```alloy // Receives metrics over HTTP prometheus.receive_http "api" { http { @@ -103,7 +103,7 @@ prometheus.remote_write "local" { In order to send metrics to the `prometheus.receive_http` component defined in the previous example, another {{< param "PRODUCT_NAME" >}} can run with the following configuration: -```river +```alloy // Collects metrics of localhost:12345 prometheus.scrape "agent_self" { targets = [ diff --git a/docs/sources/reference/components/prometheus.relabel.md b/docs/sources/reference/components/prometheus.relabel.md index 90278bddcc..ae591ec842 100644 --- a/docs/sources/reference/components/prometheus.relabel.md +++ b/docs/sources/reference/components/prometheus.relabel.md @@ -32,7 +32,7 @@ different labels. ## Usage -```river +```alloy prometheus.relabel "LABEL" { forward_to = RECEIVER_LIST @@ -101,7 +101,7 @@ values. Let's create an instance of a see `prometheus.relabel` component and see how it acts on the following metrics. -```river +```alloy prometheus.relabel "keep_backend_only" { forward_to = [prometheus.remote_write.onprem.receiver] diff --git a/docs/sources/reference/components/prometheus.remote_write.md b/docs/sources/reference/components/prometheus.remote_write.md index 5716fe2b97..7a0807ecf6 100644 --- a/docs/sources/reference/components/prometheus.remote_write.md +++ b/docs/sources/reference/components/prometheus.remote_write.md @@ -18,7 +18,7 @@ different labels. ## Usage -```river +```alloy prometheus.remote_write "LABEL" { endpoint { url = REMOTE_WRITE_URL @@ -343,7 +343,7 @@ The following examples show you how to create `prometheus.remote_write` componen You can create a `prometheus.remote_write` component that sends your metrics to a local Mimir instance: -```river +```alloy prometheus.remote_write "staging" { // Send metrics to a locally running Mimir. endpoint { @@ -373,7 +373,7 @@ prometheus.scrape "demo" { You can create a `prometheus.remote_write` component that sends your metrics to a specific tenant within the Mimir instance. This is useful when your Mimir instance is using more than one tenant: -```river +```alloy prometheus.remote_write "staging" { // Send metrics to a Mimir instance endpoint { @@ -391,7 +391,7 @@ prometheus.remote_write "staging" { You can create a `prometheus.remote_write` component that sends your metrics to a managed service, for example, Grafana Cloud. The Prometheus username and the Grafana Cloud API Key are injected in this example through environment variables. -```river +```alloy prometheus.remote_write "default" { endpoint { url = "https://prometheus-xxx.grafana.net/api/prom/push" diff --git a/docs/sources/reference/components/prometheus.scrape.md b/docs/sources/reference/components/prometheus.scrape.md index 2bb750a214..2a6c478a49 100644 --- a/docs/sources/reference/components/prometheus.scrape.md +++ b/docs/sources/reference/components/prometheus.scrape.md @@ -265,7 +265,7 @@ of the [blackbox exporter](https://github.com/prometheus/blackbox_exporter/). The exposed metrics are sent over to the provided list of receivers, as defined by other components. -```river +```alloy prometheus.scrape "blackbox_scraper" { targets = [ {"__address__" = "blackbox-exporter:9115", "instance" = "one"}, diff --git a/docs/sources/reference/components/pyroscope.ebpf.md b/docs/sources/reference/components/pyroscope.ebpf.md index 708d9ac407..f6f232d12c 100644 --- a/docs/sources/reference/components/pyroscope.ebpf.md +++ b/docs/sources/reference/components/pyroscope.ebpf.md @@ -22,7 +22,7 @@ it can lead to additional memory and CPU usage. ## Usage -```river +```alloy pyroscope.ebpf "LABEL" { targets = TARGET_LIST forward_to = RECEIVER_LIST @@ -195,7 +195,7 @@ In the following example, performance profiles are collected from pods on the sa 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. -```river +```alloy discovery.kubernetes "all_pods" { role = "pod" selectors { @@ -262,7 +262,7 @@ The following example collects performance profiles from containers discovered b other profiles collected from outside any docker container. The `service_name` label is set to the `__meta_docker_container_name` label. -```river +```alloy discovery.docker "linux" { host = "unix:///var/run/docker.sock" } diff --git a/docs/sources/reference/components/pyroscope.java.md b/docs/sources/reference/components/pyroscope.java.md index 96f5ffc10f..f409f937de 100644 --- a/docs/sources/reference/components/pyroscope.java.md +++ b/docs/sources/reference/components/pyroscope.java.md @@ -17,7 +17,7 @@ To use the `pyroscope.java` component you must run {{< param "PRODUCT_NAME" >}} ## Usage -```river +```alloy pyroscope.java "LABEL" { targets = TARGET_LIST forward_to = RECEIVER_LIST @@ -125,7 +125,7 @@ values. ### Profile every java process on the current host -```river +```alloy pyroscope.write "staging" { endpoint { url = "http://localhost:4040" diff --git a/docs/sources/reference/components/pyroscope.scrape.md b/docs/sources/reference/components/pyroscope.scrape.md index ccdccf0785..0a9421c9bd 100644 --- a/docs/sources/reference/components/pyroscope.scrape.md +++ b/docs/sources/reference/components/pyroscope.scrape.md @@ -41,7 +41,7 @@ Multiple `pyroscope.scrape` components can be specified by giving them different ## Usage -```river +```alloy pyroscope.scrape "LABEL" { targets = TARGET_LIST forward_to = RECEIVER_LIST @@ -363,7 +363,7 @@ The following arguments are supported: The `profile.custom` block allows for collecting profiles from custom endpoints. Blocks must be specified with a label: -```river +```alloy profile.custom "PROFILE_TYPE" { enabled = true path = "PROFILE_PATH" @@ -449,7 +449,7 @@ 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. -```river +```alloy pyroscope.scrape "local" { targets = [ {"__address__" = "localhost:4100", "service_name"="pyroscope"}, @@ -493,7 +493,7 @@ the `enabled` argument of the `profile.fgprof` block is `false` by default. ### Default endpoints of dynamic targets -```river +```alloy discovery.http "dynamic_targets" { url = "https://example.com/scrape_targets" refresh_interval = "15s" @@ -516,7 +516,7 @@ pyroscope.write "local" { ### Default endpoints of static and dynamic targets -```river +```alloy discovery.http "dynamic_targets" { url = "https://example.com/scrape_targets" refresh_interval = "15s" @@ -541,7 +541,7 @@ pyroscope.write "local" { ### Enabling and disabling profiles -```river +```alloy pyroscope.scrape "local" { targets = [ {"__address__" = "localhost:12345", "service_name"="agent"}, diff --git a/docs/sources/reference/components/pyroscope.write.md b/docs/sources/reference/components/pyroscope.write.md index 98f34a1b5d..c193dc5f71 100644 --- a/docs/sources/reference/components/pyroscope.write.md +++ b/docs/sources/reference/components/pyroscope.write.md @@ -18,7 +18,7 @@ different labels. ## Usage -```river +```alloy pyroscope.write "LABEL" { endpoint { url = PYROSCOPE_URL @@ -136,7 +136,7 @@ information. ## Example -```river +```alloy pyroscope.write "staging" { // Send metrics to a locally running Pyroscope instance. endpoint { diff --git a/docs/sources/reference/components/remote.http.md b/docs/sources/reference/components/remote.http.md index a959739954..de4a1242ba 100644 --- a/docs/sources/reference/components/remote.http.md +++ b/docs/sources/reference/components/remote.http.md @@ -17,7 +17,7 @@ labels. ## Usage -```river +```alloy remote.http "LABEL" { url = "URL_TO_POLL" } @@ -135,7 +135,7 @@ request of the specified URL succeeds. This example reads a JSON array of objects from an endpoint and uses them as a set of scrape targets: -```river +```alloy remote.http "targets" { url = env("MY_TARGETS_URL") } diff --git a/docs/sources/reference/components/remote.kubernetes.configmap.md b/docs/sources/reference/components/remote.kubernetes.configmap.md index 64c0b26927..af7e90a588 100644 --- a/docs/sources/reference/components/remote.kubernetes.configmap.md +++ b/docs/sources/reference/components/remote.kubernetes.configmap.md @@ -12,7 +12,7 @@ This can be useful anytime {{< param "PRODUCT_NAME" >}} needs data from a Config ## Usage -```river +```alloy remote.kubernetes.configmap "LABEL" { namespace = "NAMESPACE_OF_CONFIGMAP" name = "NAME_OF_CONFIGMAP" @@ -135,7 +135,7 @@ Instances of `remote.kubernetes.configmap` report as healthy if the most recent This example reads a Secret and a ConfigMap from Kubernetes and uses them to supply remote-write credentials. -```river +```alloy remote.kubernetes.secret "credentials" { namespace = "monitoring" name = "metrics-secret" diff --git a/docs/sources/reference/components/remote.kubernetes.secret.md b/docs/sources/reference/components/remote.kubernetes.secret.md index 1bcdfa7464..1f09cff980 100644 --- a/docs/sources/reference/components/remote.kubernetes.secret.md +++ b/docs/sources/reference/components/remote.kubernetes.secret.md @@ -12,7 +12,7 @@ A common use case for this is loading credentials or other information from secr ## Usage -```river +```alloy remote.kubernetes.secret "LABEL" { namespace = "NAMESPACE_OF_SECRET" name = "NAME_OF_SECRET" @@ -121,7 +121,7 @@ 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]: -```river +```alloy nonsensitive(remote.kubernetes.secret.LABEL.data.KEY_NAME) ``` @@ -146,7 +146,7 @@ Instances of `remote.kubernetes.secret` report as healthy if the most recent att This example reads a Secret and a ConfigMap from Kubernetes and uses them to supply remote-write credentials. -```river +```alloy remote.kubernetes.secret "credentials" { namespace = "monitoring" name = "metrics-secret" diff --git a/docs/sources/reference/components/remote.s3.md b/docs/sources/reference/components/remote.s3.md index a0ad69a767..ba60c1b114 100644 --- a/docs/sources/reference/components/remote.s3.md +++ b/docs/sources/reference/components/remote.s3.md @@ -21,7 +21,7 @@ labels. By default, [AWS environment variables](https://docs.aws.amazon.com/cli/ ## Usage -```river +```alloy remote.s3 "LABEL" { path = S3_FILE_PATH } @@ -89,7 +89,7 @@ the watched file was successful. ## Example -```river +```alloy remote.s3 "data" { path = "s3://test-bucket/file.txt" } diff --git a/docs/sources/reference/components/remote.vault.md b/docs/sources/reference/components/remote.vault.md index d8c2516cb1..e07fc6d6fa 100644 --- a/docs/sources/reference/components/remote.vault.md +++ b/docs/sources/reference/components/remote.vault.md @@ -17,7 +17,7 @@ labels. ## Usage -```river +```alloy remote.vault "LABEL" { server = "VAULT_SERVER" path = "VAULT_PATH" @@ -271,7 +271,7 @@ values will be 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]: -```river +```alloy nonsensitive(remote.vault.LABEL.data.KEY_NAME) ``` @@ -311,7 +311,7 @@ secret around: ## Example -```river +```alloy local.file "vault_token" { filename = "/var/data/vault_token" is_secret = true diff --git a/docs/sources/reference/config-blocks/argument.md b/docs/sources/reference/config-blocks/argument.md index 21b5ef9793..fb6a4250ac 100644 --- a/docs/sources/reference/config-blocks/argument.md +++ b/docs/sources/reference/config-blocks/argument.md @@ -14,7 +14,7 @@ The `argument` block may only be specified inside the definition of [a `declare` ## Example -```river +```alloy argument "ARGUMENT_NAME" {} ``` @@ -52,7 +52,7 @@ Other expressions within a custom component may use `argument.ARGUMENT_NAME.valu This example creates a custom component that self-collects process metrics and forwards them to an argument specified by the user of the custom component: -```river +```alloy declare "self_collect" { argument "metrics_output" { optional = false diff --git a/docs/sources/reference/config-blocks/declare.md b/docs/sources/reference/config-blocks/declare.md index 7f711644fe..c7db15d2f8 100644 --- a/docs/sources/reference/config-blocks/declare.md +++ b/docs/sources/reference/config-blocks/declare.md @@ -12,7 +12,7 @@ title: declare block ## Example -```river +```alloy declare "COMPONENT_NAME" { COMPONENT_DEFINITION } @@ -41,7 +41,7 @@ The fields exported by the `declare` block are determined by the [export blocks] This example creates and uses a custom component that self-collects process metrics and forwards them to an argument specified by the user of the custom component: -```river +```alloy declare "self_collect" { argument "metrics_output" { optional = false diff --git a/docs/sources/reference/config-blocks/export.md b/docs/sources/reference/config-blocks/export.md index 109e6792c9..e60ccb6700 100644 --- a/docs/sources/reference/config-blocks/export.md +++ b/docs/sources/reference/config-blocks/export.md @@ -14,7 +14,7 @@ The `export` block may only be specified inside the definition of [a `declare` b ## Example -```river +```alloy export "ARGUMENT_NAME" { value = ARGUMENT_VALUE } @@ -39,7 +39,7 @@ The `export` block doesn't export any fields. This example creates a custom component where the output of discovering Kubernetes pods and nodes are exposed to the user: -```river +```alloy declare "pods_and_nodes" { discovery.kubernetes "pods" { role = "pod" diff --git a/docs/sources/reference/config-blocks/http.md b/docs/sources/reference/config-blocks/http.md index c994465970..bf7f4ff696 100644 --- a/docs/sources/reference/config-blocks/http.md +++ b/docs/sources/reference/config-blocks/http.md @@ -12,7 +12,7 @@ title: http block ## Example -```river +```alloy http { tls { cert_file = env("TLS_CERT_FILE_PATH") diff --git a/docs/sources/reference/config-blocks/import.file.md b/docs/sources/reference/config-blocks/import.file.md index bf6788733d..09046a0a43 100644 --- a/docs/sources/reference/config-blocks/import.file.md +++ b/docs/sources/reference/config-blocks/import.file.md @@ -19,7 +19,7 @@ in the same directory. ## Usage -```river +```alloy import.file "NAMESPACE" { filename = PATH_NAME } @@ -43,7 +43,7 @@ This example imports a module from a file and instantiates a custom component fr {{< collapse title="module.alloy" >}} -```river +```alloy declare "add" { argument "a" {} argument "b" {} @@ -58,7 +58,7 @@ declare "add" { {{< collapse title="importer.alloy" >}} -```river +```alloy import.file "math" { filename = "module.alloy" } diff --git a/docs/sources/reference/config-blocks/import.git.md b/docs/sources/reference/config-blocks/import.git.md index 5117dee0d8..81ba649469 100644 --- a/docs/sources/reference/config-blocks/import.git.md +++ b/docs/sources/reference/config-blocks/import.git.md @@ -11,7 +11,7 @@ The `import.git` block imports custom components from a Git repository and expos ## Usage -```river +```alloy import.git "NAMESPACE" { repository = "GIT_REPOSTORY" path = "PATH_TO_MODULE" @@ -73,7 +73,7 @@ Name | Type | Description | Default | Required This example imports custom components from a Git repository and uses a custom component to add two numbers: -```river +```alloy import.git "math" { repository = "https://github.com/wildum/module.git" revision = "master" @@ -88,7 +88,7 @@ math.add "default" { This example imports custom components from a directory in a Git repository and uses a custom component to add two numbers: -```river +```alloy import.git "math" { repository = "https://github.com/wildum/module.git" revision = "master" diff --git a/docs/sources/reference/config-blocks/import.http.md b/docs/sources/reference/config-blocks/import.http.md index 43c9bc0dcd..5dfc05830d 100644 --- a/docs/sources/reference/config-blocks/import.http.md +++ b/docs/sources/reference/config-blocks/import.http.md @@ -10,7 +10,7 @@ title: import.http ## Usage -```river +```alloy import.http "LABEL" { url = URL } @@ -33,7 +33,7 @@ Name | Type | Description | Def This example imports custom components from an HTTP response and instantiates a custom component for adding two numbers: {{< collapse title="HTTP response" >}} -```river +```alloy declare "add" { argument "a" {} argument "b" {} @@ -46,7 +46,7 @@ declare "add" { {{< /collapse >}} {{< collapse title="importer.alloy" >}} -```river +```alloy import.http "math" { url = SERVER_URL } diff --git a/docs/sources/reference/config-blocks/import.string.md b/docs/sources/reference/config-blocks/import.string.md index b90953e82b..a7a79da798 100644 --- a/docs/sources/reference/config-blocks/import.string.md +++ b/docs/sources/reference/config-blocks/import.string.md @@ -11,7 +11,7 @@ The `import.string` block imports custom components from a string and exposes th ## Usage -```river +```alloy import.string "NAMESPACE" { content = CONTENT } @@ -36,7 +36,7 @@ Name | Type | Description This example imports a module from the content of a file stored in an S3 bucket and instantiates a custom component from the import that adds two numbers: -```river +```alloy remote.s3 "module" { path = "s3://test-bucket/module.alloy" } diff --git a/docs/sources/reference/config-blocks/logging.md b/docs/sources/reference/config-blocks/logging.md index 4240f604eb..86dd35f06d 100644 --- a/docs/sources/reference/config-blocks/logging.md +++ b/docs/sources/reference/config-blocks/logging.md @@ -12,7 +12,7 @@ title: logging block ## Example -```river +```alloy logging { level = "info" format = "logfmt" diff --git a/docs/sources/reference/config-blocks/remotecfg.md b/docs/sources/reference/config-blocks/remotecfg.md index b5766b1563..a79a1c445d 100644 --- a/docs/sources/reference/config-blocks/remotecfg.md +++ b/docs/sources/reference/config-blocks/remotecfg.md @@ -16,7 +16,7 @@ The [API definition][] for managing and fetching configuration that the `remotec ## Example -```river +```alloy remotecfg { url = "SERVICE_URL" basic_auth { diff --git a/docs/sources/reference/config-blocks/tracing.md b/docs/sources/reference/config-blocks/tracing.md index 5365368dbb..5c1278f366 100644 --- a/docs/sources/reference/config-blocks/tracing.md +++ b/docs/sources/reference/config-blocks/tracing.md @@ -12,7 +12,7 @@ title: tracing block ## Example -```river +```alloy tracing { sampling_fraction = 0.1 diff --git a/docs/sources/reference/stdlib/format.md b/docs/sources/reference/stdlib/format.md index 27c06834d2..34f8c62244 100644 --- a/docs/sources/reference/stdlib/format.md +++ b/docs/sources/reference/stdlib/format.md @@ -9,13 +9,13 @@ title: format The `format` function produces a string by formatting a number of other values according to a specification string. It's similar to the `printf` function in C, and other similar functions in other programming languages. -```river +```alloy format(spec, values...) ``` ## Examples -```river +```alloy > format("Hello, %s!", "Ander") "Hello, Ander!" > format("There are %d lights", 4) diff --git a/docs/sources/reference/stdlib/join.md b/docs/sources/reference/stdlib/join.md index c1385c1a89..ba08bbc772 100644 --- a/docs/sources/reference/stdlib/join.md +++ b/docs/sources/reference/stdlib/join.md @@ -8,13 +8,13 @@ title: join `join` all items in an array into a string, using a character as separator. -```river +```alloy join(list, separator) ``` ## Examples -```river +```alloy > join(["foo", "bar", "baz"], "-") "foo-bar-baz" > join(["foo", "bar", "baz"], ", ") diff --git a/docs/sources/reference/stdlib/replace.md b/docs/sources/reference/stdlib/replace.md index dc400e9168..f8b8d8412d 100644 --- a/docs/sources/reference/stdlib/replace.md +++ b/docs/sources/reference/stdlib/replace.md @@ -8,13 +8,13 @@ title: replace `replace` searches a string for a substring, and replaces each occurrence of the substring with a replacement string. -```river +```alloy replace(string, substring, replacement) ``` ## Examples -```river +```alloy > replace("1 + 2 + 3", "+", "-") "1 - 2 - 3" ``` diff --git a/docs/sources/reference/stdlib/split.md b/docs/sources/reference/stdlib/split.md index e56b471235..cea5c54141 100644 --- a/docs/sources/reference/stdlib/split.md +++ b/docs/sources/reference/stdlib/split.md @@ -8,13 +8,13 @@ title: split `split` produces a list by dividing a string at all occurrences of a separator. -```river +```alloy split(list, separator) ``` ## Examples -```river +```alloy > split("foo,bar,baz", "," ) ["foo", "bar", "baz"] diff --git a/docs/sources/reference/stdlib/to_lower.md b/docs/sources/reference/stdlib/to_lower.md index 1945b1b2cd..72e47ed9c1 100644 --- a/docs/sources/reference/stdlib/to_lower.md +++ b/docs/sources/reference/stdlib/to_lower.md @@ -10,7 +10,7 @@ title: to_lower ## Examples -```river +```alloy > to_lower("HELLO") "hello" ``` diff --git a/docs/sources/reference/stdlib/to_upper.md b/docs/sources/reference/stdlib/to_upper.md index 23ec80d309..89bc7c6090 100644 --- a/docs/sources/reference/stdlib/to_upper.md +++ b/docs/sources/reference/stdlib/to_upper.md @@ -10,7 +10,7 @@ title: to_upper ## Examples -```river +```alloy > to_upper("hello") "HELLO" ``` diff --git a/docs/sources/reference/stdlib/trim.md b/docs/sources/reference/stdlib/trim.md index 15370a5e67..96a741ada4 100644 --- a/docs/sources/reference/stdlib/trim.md +++ b/docs/sources/reference/stdlib/trim.md @@ -8,13 +8,13 @@ title: trim `trim` removes the specified set of characters from the start and end of a string. -```river +```alloy trim(string, str_character_set) ``` ## Examples -```river +```alloy > trim("?!hello?!", "!?") "hello" diff --git a/docs/sources/reference/stdlib/trim_prefix.md b/docs/sources/reference/stdlib/trim_prefix.md index 28bc8235a1..ffd528fb8e 100644 --- a/docs/sources/reference/stdlib/trim_prefix.md +++ b/docs/sources/reference/stdlib/trim_prefix.md @@ -11,7 +11,7 @@ If the string doesn't start with the prefix, the string is returned unchanged. ## Examples -```river +```alloy > trim_prefix("helloworld", "hello") "world" ``` diff --git a/docs/sources/reference/stdlib/trim_space.md b/docs/sources/reference/stdlib/trim_space.md index 7c3ffece95..566cf4557b 100644 --- a/docs/sources/reference/stdlib/trim_space.md +++ b/docs/sources/reference/stdlib/trim_space.md @@ -10,7 +10,7 @@ title: trim_space ## Examples -```river +```alloy > trim_space(" hello\n\n") "hello" ``` diff --git a/docs/sources/reference/stdlib/trim_suffix.md b/docs/sources/reference/stdlib/trim_suffix.md index ba855204d9..8dc66c8a35 100644 --- a/docs/sources/reference/stdlib/trim_suffix.md +++ b/docs/sources/reference/stdlib/trim_suffix.md @@ -10,7 +10,7 @@ title: trim_suffix ## Examples -```river +```alloy > trim_suffix("helloworld", "world") "hello" ``` diff --git a/docs/sources/shared/reference/components/extract-field-block.md b/docs/sources/shared/reference/components/extract-field-block.md index 5946439435..22eeefa3e4 100644 --- a/docs/sources/shared/reference/components/extract-field-block.md +++ b/docs/sources/shared/reference/components/extract-field-block.md @@ -29,7 +29,7 @@ For example, assume your pod spec contains the following labels: If you'd like to add tags for all labels with the prefix `app.kubernetes.io/` and trim the prefix, then you can specify the following extraction rules: -```river +```alloy extract { label { from = "pod" diff --git a/docs/sources/tasks/collect-opentelemetry-data.md b/docs/sources/tasks/collect-opentelemetry-data.md index 9d9d0935bf..0d6fb97e5a 100644 --- a/docs/sources/tasks/collect-opentelemetry-data.md +++ b/docs/sources/tasks/collect-opentelemetry-data.md @@ -45,7 +45,7 @@ To configure an `otelcol.exporter.otlp` component for exporting OpenTelemetry da 1. Add the following `otelcol.exporter.otlp` component to your configuration file: - ```river + ```alloy otelcol.exporter.otlp "" { client { url = ":" @@ -64,7 +64,7 @@ To configure an `otelcol.exporter.otlp` component for exporting OpenTelemetry da 1. Add the following `otelcol.auth.basic` component to your configuration file: - ```river + ```alloy otelcol.auth.basic "" { username = "" password = "" @@ -80,7 +80,7 @@ To configure an `otelcol.exporter.otlp` component for exporting OpenTelemetry da 1. Add the following line inside of the `client` block of your `otelcol.exporter.otlp` component: - ```river + ```alloy auth = otelcol.auth.basic..handler ``` @@ -96,7 +96,7 @@ To configure an `otelcol.exporter.otlp` component for exporting OpenTelemetry da The following example demonstrates configuring `otelcol.exporter.otlp` with authentication and a component that forwards data to it: -```river +```alloy otelcol.exporter.otlp "default" { client { endpoint = "my-otlp-grpc-server:4317" @@ -150,7 +150,7 @@ To configure an `otelcol.processor.batch` component, complete the following step 1. Add the following `otelcol.processor.batch` component into your configuration file: - ```river + ```alloy otelcol.processor.batch "" { output { metrics = [otelcol.exporter.otlp..input] @@ -172,7 +172,7 @@ To configure an `otelcol.processor.batch` component, complete the following step The following example demonstrates configuring a sequence of `otelcol.processor` components before being exported. -```river +```alloy otelcol.processor.memory_limiter "default" { check_interval = "1s" limit = "1GiB" @@ -221,7 +221,7 @@ To configure an `otelcol.receiver.otlp` component for receiving OTLP data, compl 1. Add the following `otelcol.receiver.otlp` component to your configuration file. - ```river + ```alloy otelcol.receiver.otlp "