From 850b725085c5a8faaea2c2280978d6f8fb1835f2 Mon Sep 17 00:00:00 2001 From: Lynette Miles Date: Thu, 24 Oct 2024 14:02:22 -0700 Subject: [PATCH 1/2] concepts: router: updating for style Signed-off-by: Lynette Miles --- concepts/data-pipeline/router.md | 44 +++++++++++++++++++------------- 1 file changed, 26 insertions(+), 18 deletions(-) diff --git a/concepts/data-pipeline/router.md b/concepts/data-pipeline/router.md index d267f3607..5d4207dc0 100644 --- a/concepts/data-pipeline/router.md +++ b/concepts/data-pipeline/router.md @@ -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 @@ -22,16 +24,19 @@ graph LR There are two important concepts in Routing: -* Tag -* Match +- Tag +- Match -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 +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 @@ -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 @@ -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_*`. ## 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 @@ -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. From edaac73327441f29e8755b6fddf8272cb5063709 Mon Sep 17 00:00:00 2001 From: esmerel <6818907+esmerel@users.noreply.github.com> Date: Fri, 25 Oct 2024 08:54:42 -0700 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Alexa Kreizinger Signed-off-by: esmerel <6818907+esmerel@users.noreply.github.com> --- concepts/data-pipeline/router.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/concepts/data-pipeline/router.md b/concepts/data-pipeline/router.md index 5d4207dc0..4a6241630 100644 --- a/concepts/data-pipeline/router.md +++ b/concepts/data-pipeline/router.md @@ -27,7 +27,7 @@ There are two important concepts in Routing: - Tag - Match -When data is generated by an input plugins, it comes with a `Tag`. A Tag is a +When data is generated by an input plugin, it comes with a `Tag`. A Tag is a human-readable indicator that helps to identify the data source. Tags are usually configured manually. @@ -76,7 +76,7 @@ example defines a common destination for both sources of data: Match my_* ``` -The match rule is set to `my_*` which matches any Tag starting with `my_*`. +The match rule is set to `my_*`, which matches any Tag starting with `my_*`. ## Routing with Regex