Update some River references

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/concepts/config-language/_index.md

@@ -74,7 +74,7 @@ The {{< param "PRODUCT_NAME" >}} syntax supports complex expressions, for exampl
 * 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.
 

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

@@ -25,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.
@@ -75,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/files.md

@@ -1,13 +1,13 @@
 ---
 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.
+{{< 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."
 
 {{< param "PRODUCT_NAME" >}} configuration files must be UTF-8 encoded and can contain Unicode characters.

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

@@ -1,6 +1,6 @@
 ---
 canonical: https://grafana.com/docs/alloy/latest/concepts/config-language/syntax/
-description: Learn about the River syntax
+description: Learn about the {{< param "PRODUCT_NAME" >}} syntax
 title: Syntax
 weight: 200
 ---
@@ -10,7 +10,7 @@ weight: 200
 The {{< param "PRODUCT_NAME" >}} syntax is easy to read and write. It has only two high-level elements, _Attributes_ and _Blocks_.
 
 The {{< param "PRODUCT_NAME" >}} configuration syntax is a _declarative_ language used to build programmable pipelines.
-The order of blocks and attributes within the River configuration file isn't important.
+The order of blocks and attributes within the {{< param "PRODUCT_NAME" >}} configuration file isn't important.
 The language considers all direct and indirect dependencies between elements to determine their relationships.
 
 ## Comments

docs/sources/get-started/install/ansible.md

@@ -39,7 +39,7 @@ To add {{% param "PRODUCT_NAME" %}} to a host:
     ```
 
    Replace the following:
-   - _`<path-to-config-file-on-localhost>`_: The path to the River configuration file on the Ansible Controller (Localhost).
+   - _`<path-to-config-file-on-localhost>`_: The path to the {{< param "PRODUCT_NAME" >}} configuration file on the Ansible Controller (Localhost).
 
 1. Run the Ansible playbook. Open a terminal window and run the following command from the Ansible playbook directory.
 

docs/sources/reference/cli/convert.md

@@ -34,7 +34,7 @@ There are several different flags available for the `convert` command. You can u
 You can use the `--report` flag to generate a diagnostic report.
 The `--bypass-errors` flag allows you to bypass any [errors][] generated during the file conversion.
 
-The command fails if the source configuration has syntactically incorrect configuration or can't be converted to {{< param "PRODUCT_NAME" >}} River format.
+The command fails if the source configuration has syntactically incorrect configuration or can't be converted to an {{< param "PRODUCT_NAME" >}} configuration.
 
 The following flags are supported:
 

docs/sources/reference/cli/fmt.md

@@ -31,7 +31,7 @@ Otherwise, `fmt` reads and formats the file from disk specified by the argument.
 The `--write` flag can be specified to replace the contents of the original file on disk with the formatted results.
 `--write` can only be provided when `fmt` isn't reading from standard input.
 
-The command fails if the file being formatted has syntactically incorrect River configuration, but doesn't validate whether {{< param "PRODUCT_NAME" >}} components are configured properly.
+The command fails if the file being formatted has syntactically incorrect {{< param "PRODUCT_NAME" >}} configuration, but doesn't validate whether {{< param "PRODUCT_NAME" >}} components are configured properly.
 
 The following flags are supported:
 

docs/sources/reference/cli/run.md

@@ -28,7 +28,7 @@ alloy run [FLAG ...] PATH_NAME
 If the `PATH_NAME` argument is not provided, or if the configuration path can't be loaded or contains errors during the initial load, the `run` command will immediately exit and show an error message.
 
 If you give the `PATH_NAME` argument a directory path, {{< param "PRODUCT_NAME" >}} will find `*.alloy` files (ignoring nested directories) and load them as a single configuration source.
-However, component names must be **unique** across all River files, and configuration blocks must not be repeated.
+However, component names must be **unique** across all {{< param "PRODUCT_NAME" >}} configuration files, and configuration blocks must not be repeated.
 
 {{< param "PRODUCT_NAME" >}} will continue to run if subsequent reloads of the configuration file fail, potentially marking components as unhealthy depending on the nature of the failure.
 When this happens, {{< param "PRODUCT_NAME" >}} will continue functioning in the last valid state.

docs/sources/tutorials/flow-by-example/_index.md

@@ -1,11 +1,11 @@
 ---
 canonical: https://grafana.com/docs/alloy/latest/tutorials/flow-by-example/
 description: Learn how to use Grafana Alloy
-title: Flow by example
+title: Alloy by example
 weight: 100
 ---
 
-# Flow by example
+# {{% param "PRODUCT_NAME" %}} by example
 
 This section provides a set of step-by-step tutorials that show how to use {{< param "PRODUCT_NAME" >}}.
 

docs/sources/tutorials/flow-by-example/first-components-and-stdlib/index.md

@@ -7,7 +7,7 @@ weight: 20
 
 # First components and the standard library
 
-This tutorial covers the basics of the River language and the standard library.
+This tutorial covers the basics of the {{< param "PRODUCT_NAME" >}} configuration syntax and the standard library.
 It introduces a basic pipeline that collects metrics from the host and sends them to Prometheus.
 
 ## River basics