concepts: router: updating for style

Signed-off-by: Lynette Miles <[email protected]>

Author: esmerel

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.