Apply suggestions from code review

Co-authored-by: Craig Norris <[email protected]>
Signed-off-by: Lynette  Miles <[email protected]>

Author: esmerel

concepts/buffering.md

@@ -32,6 +32,6 @@ The `buffer` phase contains the data in an immutable state, meaning that no othe
 
 Buffered data uses the Fluent Bit internal binary representation, which isn't raw text.
 
-Fluent Bit offers a buffering mechanism in the file system that acts as a backup system to avoid data loss in case of system failures.
+To avoid data loss in case of system failures, Fluent Bit offers a buffering mechanism in the file system that acts as a backup system.
 
 To learn more about the buffering configuration in Fluent Bit, see [Buffering and Storage](../administration/buffering-and-storage.md).

concepts/data-pipeline.md

@@ -26,4 +26,4 @@ Fluent Bit provides [input plugins](../pipeline/inputs.md) to gather information
 
 ## Route
 
-[Routing](../pipeline/router.md) 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](../concepts/key-concepts#tag.md) and [Matching](../concepts/key-concepts#match.md) rules.
+[Routing](../pipeline/router.md) 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](../concepts/key-concepts#tag.md) and [matching](../concepts/key-concepts#match.md) rules.

concepts/key-concepts.md

@@ -58,7 +58,7 @@ to represent events. This format is still supported for reading input event stre
 
 ## Filtering
 
-You might need to perform modifications on an Event's content. The process to alter, append to, or drop Events is called [_filtering_](../pipeline/filters.md).
+You might need to perform modifications on an event's content. The process to alter, append to, or drop Events is called [_filtering_](../pipeline/filters.md).
 
 Use filtering to:
 

installation/sources/build-with-static-configuration.md

@@ -12,7 +12,7 @@ The following steps assume you are familiar with configuring Fluent Bit using te
 
 #### Configuration directory
 
-In your file system, prepare a specific directory that will be used as an entry point for the build system to lookup and parse the configuration files. This directory must contain a minimum of one configuration file called `fluent-bit.conf` containing the required [`SERVICE`](/administration/configuring-fluent-bit/yaml/service-section.md), [`INPUT`](../../pipeline/input.md), and [`OUTPUT`](../../pipeline/output.md) sections.
+In your file system, prepare a specific directory that will be used as an entry point for the build system to lookup and parse the configuration files. This directory must contain a minimum of one configuration file, called `fluent-bit.conf`, that contains the required [`SERVICE`](/administration/configuring-fluent-bit/yaml/service-section.md), [`INPUT`](../../pipeline/input.md), and [`OUTPUT`](../../pipeline/output.md) sections.
 
 As an example, create a new `fluent-bit.yaml` file or `fluent-bit.conf` file:
 

pipeline/filters/rewrite-tag.md

@@ -4,9 +4,9 @@ description: Powerful and flexible routing
 
 # Rewrite tag
 
-Tags make [routing](../../pipeline/router.md) possible. Tags are set in the configuration of the `INPUT` definitions where the records are generated. There are scenarios where you might want to modify the tag in the pipeline to perform more advanced and flexible routing.
+Tags make [routing](../../pipeline/router.md) possible. Tags are set in the configuration of the `INPUT` definitions where the records are generated. There are scenarios when you might want to modify the tag in the pipeline to perform more advanced and flexible routing.
 
-The _Rewrite Tag_ filter lets you re-emit a record under a new tag. Once a record has been re-emitted, the original record can be preserved or discarded.
+The _Rewrite Tag_ filter lets you re-emit a record under a new tag. After a record is re-emitted, the original record can be preserved or discarded.
 
 The Rewrite Tag filter defines rules that match specific record key content against a regular expression. If a match exists, a new record with the defined tag will be emitted, entering from the beginning of the pipeline. Multiple rules can be specified and are processed in order until one of them matches.
 

pipeline/inputs.md

@@ -1,6 +1,6 @@
 # Inputs
 
-Input plugins gather information from different sources. Some plugins collect data from log files, while others can gather metrics information from the operating system. There are many plugins to suit different needs.
+Input plugins gather information from different sources. Some plugins collect data from log files, and others gather metrics information from the operating system. There are many different plugins, and they let you handle many different needs.
 
 ```mermaid
 graph LR

pipeline/parsers.md

@@ -1,6 +1,6 @@
 # Parsers
 
-Dealing with raw strings or unstructured messages is difficult. Having a structure makes data more usable. Set a structure to the incoming data by using input plugins as data is collected.
+Dealing with raw strings or unstructured messages is difficult. Having a structure makes data more usable. Set a structure for the incoming data by using input plugins as data is collected.
 
 Parsers are fully configurable and are independently and optionally handled by each input plugin.
 

pipeline/router.md

@@ -161,7 +161,4 @@ pipeline:
 {% endtab %}
 {% endtabs %}
 
-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.
+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.