Skip to content

Commit

Permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Additional edits nad updates for grammar style
Browse files Browse the repository at this point in the history
clayton-cornell committed Dec 8, 2023
1 parent 9538303 commit ffac9f1
Showing 2 changed files with 7 additions and 8 deletions.
9 changes: 4 additions & 5 deletions docs/sources/flow/concepts/clustering.md
Original file line number Diff line number Diff line change
@@ -31,8 +31,7 @@ You configure clustering by passing `cluster` command-line flags to the [run][]

Target auto-distribution is the most basic use case of clustering.
It allows scraping components running on all peers to distribute the scrape load between themselves.
For target auto-distribution to work correctly,
all {{< param "PRODUCT_ROOT_NAME" >}} in the same cluster must be able to reach the same service discovery APIs and must be able to scrape the same targets.
Target auto-distribution requires that all {{< param "PRODUCT_ROOT_NAME" >}} in the same cluster can reach the same service discovery APIs and scrape the same targets.

You must explicitly enable target auto-distribution on components by defining a `clustering` block, such as:

@@ -50,7 +49,7 @@ A cluster state change is detected when a new node joins or an existing node lea
All participating components locally recalculate target ownership and re-balance the number of targets they’re scraping without explicitly communicating ownership over the network.

Target auto-distribution allows you to dynamically scale the number of {{< param "PRODUCT_ROOT_NAME" >}}s to distribute workload during peaks.
It also provides resiliency because targets are automatically picked up by one of the node peers if a node goes away.
It also provides resiliency because targets are automatically picked up by one of the node peers if a node leaves.

{{< param "PRODUCT_NAME" >}} uses a fully local consistent hashing algorithm to distribute targets, meaning that, on average, only ~1/N of the targets are redistributed.

@@ -63,8 +62,8 @@ Refer to component reference documentation to discover whether it supports clust

## Cluster monitoring and troubleshooting

To monitor your cluster status, you can check the {{< param "PRODUCT_NAME" >}} UI [clustering page][].
The [debugging][] topic contains some clues to help pin down probable clustering issues.
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.

{{% docs/reference %}}
[run]: "/docs/agent/ -> /docs/agent/<AGENT_VERSION>/flow/reference/cli/run.md#clustering-beta"
6 changes: 3 additions & 3 deletions docs/sources/flow/concepts/components.md
Original file line number Diff line number Diff line change
@@ -16,7 +16,7 @@ weight: 100
_Components_ are the building blocks of {{< param "PRODUCT_NAME" >}}.
Each component handles a single task, such as retrieving secrets or collecting Prometheus metrics.

Components are composed of two parts:
Components are composed of the following:

* Arguments: Settings that configure a component.
* Exports: Named values that a component exposes to other components.
@@ -25,7 +25,7 @@ Each component has a name that describes what that component is responsible for.
For example, the `local.file` component is responsible for retrieving the contents of files on disk.

Components are specified in the configuration file by first providing the component's name with a user-specified label,
and then by providing arguments to configure the component:
and then by providing arguments to configure the component.

```river
discovery.kubernetes "pods" {
@@ -38,7 +38,7 @@ discovery.kubernetes "nodes" {
```

> Components are referenced by combining the component name with its label.
> For > example, a `local.file` component labeled `foo` would be referenced as `local.file.foo`.
> For example, a `local.file` component labeled `foo` would be referenced as `local.file.foo`.
>
> The combination of a component's name and its label must be unique within the configuration file.
> This means multiple instances of a component may be defined as long as each instance has a different label value.

0 comments on commit ffac9f1

Please sign in to comment.