Update paths, references to River, and config/binary paths and names (#…

…84)

* Relocate assets to main image repo

* Update format and markdown

* Update article reference to Alloy

* Update some River references

* Update more instances of River

* Fix a shortcode typo

* Fix markdown syntax errors

docs/developer/writing-flow-component-documentation.md

@@ -129,7 +129,7 @@ and blocks to configure a component.
 
 It starts with an `h2` header called Usage.
 
-The Usage section should be composed of a single River code block, with no
+The Usage section should be composed of a single {{< param "PRODUCT_NAME" >}} code block, with no
 description. Use `YELLING_SNAKE_CASE` to refer to values the user must replace.
 For example:
 
@@ -188,7 +188,7 @@ Name             | Type       | Description                            | Default
 Values for the Name column should be the backticked argument name, such as ``
 `targets` ``.
 
-Values for the Type column should be the backticked River type (for example,
+Values for the Type column should be the backticked {{< param "PRODUCT_NAME" >}} type (for example,
 `string`, `bool`, `number`). Arrays should be represented as
 `list(INNER_TYPE)`, and dictionaries should be represented as
 `map(VALUE_TYPE)`.
@@ -205,7 +205,7 @@ the table. Use full sentences for argument descriptions, ending them in
 periods.
 
 Values for the Default column may be omitted if the default is the zero value
-for the given River type. The Default column must be empty for required
+for the given {{< param "PRODUCT_NAME" >}} type. The Default column must be empty for required
 attributes.
 
 Values for the Required column must be either "yes" (for required attributes)
@@ -378,13 +378,13 @@ with the following columns:
 | Column      | Description                       |
 | ----------- | --------------------------------- |
 | Name        | Name of exported value.           |
-| Type        | River type of exported value.     |
+| Type        | {{< param "PRODUCT_NAME" >}} type of exported value.     |
 | Description | Description of exported value.    |
 
 Values for the Name column should be the backticked exported field name, such
 as `` `targets` ``.
 
-Values for the Type column should be the backticked River type. These types
+Values for the Type column should be the backticked {{< param "PRODUCT_NAME" >}} type. These types
 should follow the same guidelines detailed in the Type column in the [Arguments
 block](#arguments).
 
@@ -462,7 +462,7 @@ should always prefix the metrics table.
 
 ### Examples
 
-The Examples section provides copy-and-paste River pipelines which use the
+The Examples section provides copy-and-paste {{< param "PRODUCT_NAME" >}} pipelines which use the
 Flow component. The section starts with an `h2` header called Examples. If
 there is only one example, call the section Example instead.
 
@@ -566,7 +566,7 @@ The [otelcol.processor.transform][] component documentation needed to add
 an extra section about OTTL Contexts because there is no appropriate OTEL docs page 
 that we could link to. Currently this information is housed on the [transformprocessor][] 
 doc page, but because it contains yaml config for the Collector, users might get confused 
-how this maps to River and it is better not to link to it. In the future we could try to
+how this maps to {{< param "PRODUCT_NAME" >}} and it is better not to link to it. In the future we could try to
 move this information from [transformprocessor][] to the [OTTL Context][ottl context] doc.
 
 [loki.source.podlogs]: ../sources/flow/reference/components/loki.source.podlogs.md

docs/sources/about.md

@@ -68,7 +68,7 @@ prometheus.remote_write "default" {
 The {{< param "PRODUCT_NAME" >}} [configuration generator][] helps you get a head start on creating {{< param "PRODUCT_NAME" >}} configurations.
 
 {{< admonition type="note" >}}
-This feature is experimental, and it doesn't support all River components.
+This feature is experimental, and it doesn't support all {{< param "PRODUCT_NAME" >}} components.
 {{< /admonition >}}
 
 ## Next steps

docs/sources/concepts/_index.md

@@ -7,6 +7,6 @@ weight: 100
 
 # Concepts
 
-This section explains the primary concepts of {{< param "PRODUCT_NAME" >}}.
+This section explains the primary concepts of {{< param "FULL_PRODUCT_NAME" >}}.
 
 {{< section >}}

docs/sources/concepts/clustering.md

@@ -58,7 +58,6 @@ Refer to component reference documentation to discover whether it supports clust
 You can use the {{< param "PRODUCT_NAME" >}} UI [clustering page][] to monitor your cluster status.
 Refer to [Debugging clustering issues][debugging] for additional troubleshooting information.
 
-
 [run]: ../../reference/cli/run/#clustering-beta
 [prometheus.scrape]: ../../reference/components/prometheus.scrape/#clustering-beta
 [pyroscope.scrape]: ../../reference/components/pyroscope.scrape/#clustering-beta

docs/sources/concepts/config-language/_index.md

@@ -7,14 +7,14 @@ weight: 10
 
 # Configuration language
 
-{{< param "PRODUCT_NAME" >}} dynamically configures and connects components with a custom configuration language called River.
+{{< param "PRODUCT_NAME" >}} dynamically configures and connects components with the {{< param "PRODUCT_NAME" >}} configuration syntax.
 
-River aims to reduce errors in configuration files by making configurations easier to read and write.
-River configurations use blocks that can be easily copied and pasted from the documentation to help you get started as quickly as possible.
+The {{< param "PRODUCT_NAME" >}} syntax aims to reduce errors in configuration files by making configurations easier to read and write.
+{{< param "PRODUCT_NAME" >}} configurations use blocks that can be easily copied and pasted from the documentation to help you get started as quickly as possible.
 
-A River configuration file tells {{< param "PRODUCT_NAME" >}} which components to launch and how to bind them together into a pipeline.
+An {{< param "PRODUCT_NAME" >}} configuration file tells {{< param "PRODUCT_NAME" >}} which components to launch and how to bind them together into a pipeline.
 
-The River syntax uses blocks, attributes, and expressions.
+The {{< param "PRODUCT_NAME" >}} syntax uses blocks, attributes, and expressions.
 
 ```river
 // Create a local.file component labeled my_file.
@@ -36,13 +36,13 @@ BLOCK_NAME {
 }
 ```
 
-[River is designed][RFC] with the following requirements in mind:
+[{{< param "PRODUCT_NAME" >}} is designed][RFC] 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.
 * _Debuggable_: The configuration language must give detailed information when there's a mistake in the configuration file.
 
-River is similar to HCL, the language Terraform and other Hashicorp projects use.
+The {{< param "PRODUCT_NAME" >}} configuration syntax is similar to HCL, the language Terraform and other Hashicorp projects use.
 It's a distinct language with custom syntax and features, such as first-class functions.
 
 * Blocks are a group of related settings and usually represent creating a component.
@@ -51,7 +51,7 @@ It's a distinct language with custom syntax and features, such as first-class fu
 * Expressions represent a value, either literally or by referencing and combining other values.
   You use expressions to compute a value for an attribute.
 
-River is declarative, so ordering components, blocks, and attributes within a block isn't significant.
+The {{< param "PRODUCT_NAME" >}} syntax is declarative, so ordering components, blocks, and attributes within a block isn't significant.
 The relationship between components determines the order of operations.
 
 ## Attributes
@@ -69,12 +69,12 @@ log_level = "debug"
 
 You use expressions to compute the value of an attribute.
 The simplest expressions are constant values like `"debug"`, `32`, or `[1, 2, 3, 4]`.
-River supports complex expressions, for example:
+The {{< param "PRODUCT_NAME" >}} syntax supports complex expressions, for example:
 
 * Referencing the exports of components: `local.file.password_file.content`
 * Mathematical operations: `1 + 2`, `3 * 4`, `(5 * 6) + (7 + 8)`
 * Equality checks: `local.file.file_a.content == local.file.file_b.content`
-* Calling functions from River's standard library: `env("HOME")` retrieves the value of the `HOME` environment variable.
+* Calling functions from {{< param "PRODUCT_NAME" >}}'s standard library: `env("HOME")` retrieves the value of the `HOME` environment variable.
 
 You can use expressions for any attribute inside a component definition.
 
@@ -107,7 +107,7 @@ The preceding example has two blocks:
 
 ## Tooling
 
-You can use one or all of the following tools to help you write configuration files in River.
+You can use one or all of the following tools to help you write {{< param "PRODUCT_NAME" >}} configuration files.
 
 * Editor support for:
   * [VSCode](https://github.com/grafana/vscode-alloy)

docs/sources/concepts/config-language/components.md

@@ -8,14 +8,13 @@ weight: 300
 # Components configuration language
 
 Components are the defining feature of {{< param "PRODUCT_NAME" >}}.
-Components are small, reusable pieces of business logic that perform a single task like retrieving secrets or collecting Prometheus metrics,
-and you can wire them together to form programmable pipelines of telemetry data.
+Components are small, reusable pieces of business logic that perform a single task like retrieving secrets or collecting Prometheus metrics, and you can wire them together to form programmable pipelines of telemetry data.
 
 The [_component controller_][controller] is responsible for scheduling components, reporting their health and debug status, re-evaluating their arguments, and providing their exports.
 
 ## Configuring components
 
-You create [components][] by defining a top-level River block.
+You create [components][] by defining a top-level block.
 All components are identified by their name, describing what the component is responsible for, and a user-specified _label_.
 
 ## Arguments and exports
@@ -26,7 +25,7 @@ Most user interactions with components center around two basic concepts, _argume
   They can be any number of attributes or nested unlabeled blocks, some required and some optional.
   Any optional arguments that aren't set take on their default values.
 
-* _Exports_ are zero or more output values that other components can refer to and can be of any River type.
+* _Exports_ are zero or more output values that other components can refer to and can be of any {{< param "PRODUCT_NAME" >}} type.
 
 The following block defines a `local.file` component labeled "targets".
 The `local.file.targets` component exposes the file `content` as a string in its exports.
@@ -76,7 +75,7 @@ prometheus.scrape "default" {
 Each time the file contents change, the `local.file` updates its exports. The new value is sent to the `prometheus.scrape` targets field.
 
 Each argument and exported field has an underlying [type][].
-River checks the expression type before assigning a value to an attribute.
+{{< param "PRODUCT_NAME" >}} checks the expression type before assigning a value to an attribute.
 The documentation of each [component][components] provides more information about how to wire components together.
 
 In the previous example, the contents of the `local.file.targets.content` expression is evaluated to a concrete value.

docs/sources/concepts/config-language/expressions/_index.md

@@ -14,7 +14,7 @@ Expressions may also do things like [refer to values][] exported by components,
 
 You use expressions when you configure any component.
 All component arguments have an underlying [type][].
-River checks the expression type before assigning the result to an attribute.
+{{< param "PRODUCT_NAME" >}} checks the expression type before assigning the result to an attribute.
 
 [refer to values]: ./referencing_exports/
 [call functions]: ./function_calls/

docs/sources/concepts/config-language/expressions/function_calls.md

@@ -7,16 +7,16 @@ weight: 400
 
 # Function calls
 
-You can use River function calls to build richer expressions.
+You can use {{< param "PRODUCT_NAME" >}} function calls to build richer expressions.
 
 Functions take zero or more arguments as their input and always return a single value as their output.
-You can't construct functions. You can call functions from River's standard library or export them from a component.
+You can't construct functions. You can call functions from {{< param "PRODUCT_NAME" >}}'s standard library or export them from a component.
 
 If a function fails, the expression isn't evaluated, and an error is reported.
 
 ## Standard library functions
 
-River contains a [standard library][] of functions.
+The {{< param "PRODUCT_NAME" >}} configuration syntax contains a [standard library][] of functions.
 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.
 

docs/sources/concepts/config-language/expressions/operators.md

@@ -7,7 +7,7 @@ weight: 300
 
 # Operators
 
-River uses a common set of operators.
+The {{< param "PRODUCT_NAME" >}} configuration syntax uses a common set of operators.
 All operations follow the standard [PEMDAS][] order of mathematical operations.
 
 ## Arithmetic operators
@@ -61,7 +61,7 @@ Logical operators apply to boolean values and yield a boolean result.
 
 ## Assignment operator
 
-River uses `=` as its assignment operator.
+The {{< param "PRODUCT_NAME" >}} configuration syntax uses `=` as its assignment operator.
 
 An assignment statement may only assign a single value.
 Each value must be _assignable_ to the attribute or object key.
@@ -94,7 +94,7 @@ Operator | Description
 `[ ]`    | Access a member of an array or object.
 `.`      | Access a named member of an object or an exported field of a component.
 
-You can access arbitrarily nested values with River's access operators.
+You can access arbitrarily nested values with {{< param "PRODUCT_NAME" >}}'s access operators.
 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.
 

docs/sources/concepts/config-language/expressions/referencing_exports.md

@@ -7,7 +7,7 @@ weight: 200
 
 # Referencing component exports
 
-Referencing exports enables River to configure and connect components dynamically using expressions.
+Referencing exports enables {{< param "PRODUCT_NAME" >}} to configure and connect components dynamically using expressions.
 While components can work in isolation, they're more useful when one component's behavior and data flow are bound to the exports of another, building a dependency relationship between the two.
 
 Such references can only appear as part of another component's arguments or a configuration block's fields.
@@ -39,12 +39,12 @@ prometheus.remote_write "onprem" {
 }
 ```
 
-In the preceding example, you wired together a very simple pipeline by writing a few River expressions.
+In the preceding example, you wired together a very simple pipeline by writing a few {{< param "PRODUCT_NAME" >}} expressions.
 
 ![Flow of example pipeline](/media/docs/agent/flow_referencing_exports_diagram.svg)
 
 After the value is resolved, it must match the [type][] of the attribute it is assigned to.
-While you can only configure attributes using the basic River types,
-the exports of components can take on special internal River types, such as Secrets or Capsules, which expose different functionality.
+While you can only configure attributes using the basic {{< param "PRODUCT_NAME" >}} types,
+the exports of components can take on special internal {{< param "PRODUCT_NAME" >}} types, such as Secrets or Capsules, which expose different functionality.
 
 [type]: ../types_and_values/

docs/sources/concepts/config-language/expressions/types_and_values.md

@@ -1,13 +1,13 @@
 ---
 canonical: https://grafana.com/docs/alloy/latest/concepts/config-language/expressions/types_and_values/
-description: Learn about the River types and values
+description: Learn about the {{< param "PRODUCT_NAME" >}} syntax types and values
 title: Types and values
 weight: 100
 ---
 
 # Types and values
 
-River uses the following types for its values:
+The {{< param "PRODUCT_NAME" >}} syntax uses the following types for its values:
 
 * `number`: Any numeric value, like `3` or `3.14`.
 * `string`: A sequence of Unicode characters representing text, like `"Hello, world!"`.
@@ -42,7 +42,7 @@ In addition to the preceding types, the [component reference][] documentation us
 
 ## Numbers
 
-River handles integers, unsigned integers, and floating-point values as a single 'number' type, simplifying writing and reading River configuration files.
+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
 3    == 3.00     // true

docs/sources/concepts/config-language/files.md

@@ -1,14 +1,14 @@
 ---
 canonical: https://grafana.com/docs/alloy/latest/concepts/config-language/files/
-description: Learn about River files
+description: Learn about {{< param "PRODUCT_NAME" >}} configuration files
 title: Files
 weight: 100
 ---
 
 # Files
 
-River files are plain text files with the `.alloy` file extension.
-You can refer to each River file as a "configuration file" or a "River configuration."
+{{< param "PRODUCT_NAME" >}} configuration files are plain text files with the `.alloy` file extension.
+You can refer to each {{< param "PRODUCT_NAME" >}} file as a "configuration file" or an "{{< param "PRODUCT_NAME" >}} configuration."
 
-River files must be UTF-8 encoded and can contain Unicode characters.
-River files can use Unix-style line endings (LF) and Windows-style line endings (CRLF), but formatters may replace all line endings with Unix-style ones.
+{{< param "PRODUCT_NAME" >}} configuration files must be UTF-8 encoded and can contain Unicode characters.
+{{< param "PRODUCT_NAME" >}} configuration files can use Unix-style line endings (LF) and Windows-style line endings (CRLF), but formatters may replace all line endings with Unix-style ones.