Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

concepts: router: updating for style #1489

Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 26 additions & 18 deletions concepts/data-pipeline/router.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,9 @@ description: Create flexible routing rules

# Router

Routing is a core feature that allows to **route** your data through Filters and finally to one or multiple destinations. The router relies on the concept of [Tags](../key-concepts.md) and [Matching](../key-concepts.md) rules
Routing is a core feature that lets you route your data through filters and then to
one or multiple destinations. The router relies on the concept of
[Tags](../key-concepts.md) and [Matching](../key-concepts.md) rules.

```mermaid
graph LR
Expand All @@ -22,16 +24,19 @@ graph LR

There are two important concepts in Routing:

* Tag
* Match
- Tag
- Match
esmerel marked this conversation as resolved.
Show resolved Hide resolved

When the data is generated by the input plugins, it comes with a **Tag** (most of the time the Tag is configured manually), the Tag is a human-readable indicator that helps to identify the data source.
When data is generated by an input plugins, it comes with a `Tag`. A Tag is a
esmerel marked this conversation as resolved.
Show resolved Hide resolved
human-readable indicator that helps to identify the data source. Tags are usually
configured manually.

In order to define **where** the data should be routed, a **Match** rule must be specified in the output configuration.
To define where to route data, specify a `Match` rule in the output configuration.

Consider the following configuration example that aims to deliver CPU metrics to an Elasticsearch database and Memory metrics to the standard output interface:
Consider the following configuration example that delivers `CPU` metrics to an
Elasticsearch database and Memory (`mem`) metrics to the standard output interface:

```
```text
[INPUT]
Name cpu
Tag my_cpu
Expand All @@ -49,15 +54,15 @@ Consider the following configuration example that aims to deliver CPU metrics to
Match my_mem
```

> Note: the above is a simple example demonstrating how Routing is configured.

Routing works automatically reading the Input Tags and the Output Match rules. If some data has a Tag that doesn't match upon routing time, the data is deleted.
Routing reads the `Input` `Tag` and the `Output` `Match` rules. If data has a `Tag`
that doesn't match at routing time, the data is deleted.

## Routing with Wildcard

Routing is flexible enough to support _wildcard_ in the **Match** pattern. The below example defines a common destination for both sources of data:
Routing is flexible enough to support wildcards in the `Match` pattern. The following
example defines a common destination for both sources of data:

```
```text
[INPUT]
Name cpu
Tag my_cpu
Expand All @@ -71,14 +76,15 @@ Routing is flexible enough to support _wildcard_ in the **Match** pattern. The b
Match my_*
```

The match rule is set to **my\_\*** which means it will match any Tag that starts with **my\_**.
The match rule is set to `my_*` which matches any Tag starting with `my_*`.
esmerel marked this conversation as resolved.
Show resolved Hide resolved

## Routing with Regex

Routing also provides support for _regex_ with the **Match_Regex** pattern, allowing for more complex and precise matching criteria.
The following example demonstrates how to route data from sources based on a regular expression:
Routing also provides support for regular expressions with the `Match_Regex` pattern,
allowing for more complex and precise matching criteria. The following example
demonstrates how to route data from sources based on a regular expression:

```
```text
[INPUT]
Name temperature_sensor
Tag temp_sensor_A
Expand All @@ -92,5 +98,7 @@ The following example demonstrates how to route data from sources based on a reg
Match_regex .*_sensor_[AB]
```

In this configuration, the **Match_regex** rule is set to `.*_sensor_[AB]`. This regular expression will match any Tag that ends with "_sensor_A" or "_sensor_B", regardless of what precedes it.
This approach provides a more flexible and powerful way to handle different source tags with a single routing rule.
In this configuration, the `Match_regex` rule is set to `.*_sensor_[AB]`. This
regular expression matches any `Tag` that ends with `_sensor_A` or `_sensor_B`,
regardless of what precedes it. This approach provides a more flexible and powerful
way to handle different source tags with a single routing rule.