From 2382d3b32c396c39c3bd7ef7bde4e08eca8d8fd6 Mon Sep 17 00:00:00 2001 From: Clayton Cornell Date: Tue, 26 Mar 2024 13:29:31 -0700 Subject: [PATCH] Update some River references --- .../writing-flow-component-documentation.md | 14 +++++++------- docs/sources/concepts/config-language/_index.md | 2 +- .../sources/concepts/config-language/components.md | 4 ++-- .../concepts/config-language/expressions/_index.md | 2 +- .../config-language/expressions/function_calls.md | 6 +++--- .../config-language/expressions/operators.md | 6 +++--- .../expressions/referencing_exports.md | 8 ++++---- docs/sources/concepts/config-language/files.md | 4 ++-- docs/sources/concepts/config-language/syntax.md | 4 ++-- docs/sources/get-started/install/ansible.md | 2 +- docs/sources/reference/cli/convert.md | 2 +- docs/sources/reference/cli/fmt.md | 2 +- docs/sources/reference/cli/run.md | 2 +- docs/sources/tutorials/flow-by-example/_index.md | 4 ++-- .../first-components-and-stdlib/index.md | 2 +- 15 files changed, 32 insertions(+), 32 deletions(-) diff --git a/docs/developer/writing-flow-component-documentation.md b/docs/developer/writing-flow-component-documentation.md index ab1d304990..5753b96b08 100644 --- a/docs/developer/writing-flow-component-documentation.md +++ b/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 diff --git a/docs/sources/concepts/config-language/_index.md b/docs/sources/concepts/config-language/_index.md index 67dbc3c2d8..4ea24b8a2c 100644 --- a/docs/sources/concepts/config-language/_index.md +++ b/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. diff --git a/docs/sources/concepts/config-language/components.md b/docs/sources/concepts/config-language/components.md index e0ca6d027c..e6743e8aeb 100644 --- a/docs/sources/concepts/config-language/components.md +++ b/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. diff --git a/docs/sources/concepts/config-language/expressions/_index.md b/docs/sources/concepts/config-language/expressions/_index.md index f91c8aaa2f..c95bfc2d17 100644 --- a/docs/sources/concepts/config-language/expressions/_index.md +++ b/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/ diff --git a/docs/sources/concepts/config-language/expressions/function_calls.md b/docs/sources/concepts/config-language/expressions/function_calls.md index da05a2c8f4..09d0b1a103 100644 --- a/docs/sources/concepts/config-language/expressions/function_calls.md +++ b/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. diff --git a/docs/sources/concepts/config-language/expressions/operators.md b/docs/sources/concepts/config-language/expressions/operators.md index a554345f04..0c4ea797a3 100644 --- a/docs/sources/concepts/config-language/expressions/operators.md +++ b/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. diff --git a/docs/sources/concepts/config-language/expressions/referencing_exports.md b/docs/sources/concepts/config-language/expressions/referencing_exports.md index 00f7030f80..fe7e3af97f 100644 --- a/docs/sources/concepts/config-language/expressions/referencing_exports.md +++ b/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/ diff --git a/docs/sources/concepts/config-language/files.md b/docs/sources/concepts/config-language/files.md index 14120ba04c..22ca0e40a3 100644 --- a/docs/sources/concepts/config-language/files.md +++ b/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. diff --git a/docs/sources/concepts/config-language/syntax.md b/docs/sources/concepts/config-language/syntax.md index 66305fe96f..ba8c68aa12 100644 --- a/docs/sources/concepts/config-language/syntax.md +++ b/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 diff --git a/docs/sources/get-started/install/ansible.md b/docs/sources/get-started/install/ansible.md index 5d1123bfa7..a22105b6c9 100644 --- a/docs/sources/get-started/install/ansible.md +++ b/docs/sources/get-started/install/ansible.md @@ -39,7 +39,7 @@ To add {{% param "PRODUCT_NAME" %}} to a host: ``` Replace the following: - - _``_: The path to the River configuration file on the Ansible Controller (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. diff --git a/docs/sources/reference/cli/convert.md b/docs/sources/reference/cli/convert.md index 50aad87ac6..893df15820 100644 --- a/docs/sources/reference/cli/convert.md +++ b/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: diff --git a/docs/sources/reference/cli/fmt.md b/docs/sources/reference/cli/fmt.md index 4b40efb59a..20981499d1 100644 --- a/docs/sources/reference/cli/fmt.md +++ b/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: diff --git a/docs/sources/reference/cli/run.md b/docs/sources/reference/cli/run.md index 3a343b4952..48fee0b1a9 100644 --- a/docs/sources/reference/cli/run.md +++ b/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. diff --git a/docs/sources/tutorials/flow-by-example/_index.md b/docs/sources/tutorials/flow-by-example/_index.md index 33f34193dd..0e204774bd 100644 --- a/docs/sources/tutorials/flow-by-example/_index.md +++ b/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" >}}. diff --git a/docs/sources/tutorials/flow-by-example/first-components-and-stdlib/index.md b/docs/sources/tutorials/flow-by-example/first-components-and-stdlib/index.md index feb7cfcc6d..1e81d65ced 100644 --- a/docs/sources/tutorials/flow-by-example/first-components-and-stdlib/index.md +++ b/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