Merge pull request #2011 from fluent/lynettemiles/sc-143158/final-vale-cleanup-for-administration

Author: esmerel

administration/aws-credentials.md

@@ -23,11 +23,11 @@ The shared settings evaluate in the following order:
 | Setting | File | Description |
 |---|---|---|
 | `credential_process` | `config` | Linux only. See [Sourcing credentials with an external process in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html). |
-| `aws_access_key_id`<br />`aws_secret_access_key`<br />`aws_session_token` | `credentials` | Access key ID and secret key to use to authenticate. The session token must be set for temporary credentials. |
+| `aws_access_key_id`, `aws_secret_access_key`, `aws_session_token` | `credentials` | Access key ID and secret key to use to authenticate. The session token must be set for temporary credentials. |
 
 No other settings are supported.
 
-## EKS Web Identity Token (OIDC)
+## EKS web identity token (OIDC)
 
 Credentials are fetched using a signed web identity token for a Kubernetes service account. See [IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html).
 

administration/backpressure.md

@@ -68,4 +68,4 @@ With `storage.type filesystem` and `storage.max_chunks_up`, the following log me
 ```text
 [input] {input name or alias} paused (storage buf overlimit)
 [input] {input name or alias} resume (storage buf overlimit)
-```
+```

administration/buffering-and-storage.md

@@ -105,7 +105,7 @@ Fluent Bit controls the number of chunks that are `up` in memory by using the fi
 
 By default, the engine allows a total of 128 chunks `up` in memory in total, considering all chunks. This value is controlled by the service property `storage.max_chunks_up`. The active chunks that are `up` are ready for delivery and are still receiving records. Any other remaining chunk is in a `down` state, which means that it's only in the filesystem and won't be `up` in memory unless it's ready to be delivered. Chunks are never much larger than 2 MB, so with the default `storage.max_chunks_up` value of 128, each input is limited to roughly 256 MB of memory.
 
-If the input plugin has enabled `storage.type` as `filesystem`, when reaching the `storage.max_chunks_up` threshold, instead of the plugin being paused, all new data will go to chunks that are `down` in the filesystem. This lets you control memory usage by the service and also provides a guarantee that the service won't lose any data. By default, the enforcement of the `storage.max_chunks_up` limit is best-effort. Fluent Bit can only append new data to chunks that are `up`. When the limit is reached chunks will be temporarily brought `up` in memory to ingest new data, and then put to a `down` state afterwards. In general, Fluent Bit works to keep the total number of `up` chunks at or below `storage.max_chunks_up`.
+If the input plugin has enabled `storage.type` as `filesystem`, when reaching the `storage.max_chunks_up` threshold, instead of the plugin being paused, all new data will go to chunks that are `down` in the filesystem. This lets you control memory usage by the service and also provides a guarantee that the service won't lose any data. By default, the enforcement of the `storage.max_chunks_up` limit is best-effort. Fluent Bit can only append new data to chunks that are `up`. When the limit is reached chunks will be temporarily brought `up` in memory to ingest new data, and then put to a `down` state afterwards. In general, Fluent Bit works to keep the total number of `up` chunks at or under `storage.max_chunks_up`.
 
 If `storage.pause_on_chunks_overlimit` is enabled (default is off), the input plugin pauses upon exceeding `storage.max_chunks_up`. With this option, `storage.max_chunks_up` becomes a hard limit for the input. When the input is paused, records won't be ingested until the plugin resumes. For some inputs, such as TCP and tail, pausing the input will almost certainly lead to log loss. For the tail input, Fluent Bit can save its current offset in the current file it's reading, and pick back up when the input is resumed.
 
@@ -122,7 +122,7 @@ Fluent Bit implements the concept of logical queues. Based on its tag, a chunk c
 
 It's common to find cases where multiple destinations with different response times exist for a chunk, or one of the destinations is generating backpressure.
 
-To limit the amount of filesystem chunks logically queueing, Fluent Bit v1.6 and later includes the `storage.total_limit_size` configuration property for output This property limits the total size in bytes of chunks that can exist in the filesystem for a certain logical output destination. If one of the destinations reaches the configured `storage.total_limit_size`, the oldest chunk from its queue for that logical output destination will be discarded to make room for new data.
+To limit the amount of filesystem chunks logically queueing, Fluent Bit v1.6 and later includes the `storage.total_limit_size` configuration property for output. This property limits the total size in bytes of chunks that can exist in the filesystem for a certain logical output destination. If one of the destinations reaches the configured `storage.total_limit_size`, the oldest chunk from its queue for that logical output destination will be discarded to make room for new data.
 
 ## Configuration
 
@@ -145,9 +145,9 @@ The Service section refers to the section defined in the main [configuration fil
 | `storage.checksum` | Enable the data integrity check when writing and reading data from the filesystem. The storage layer uses the CRC32 algorithm. Accepted values: `Off`, `On`. | `Off` |
 | `storage.max_chunks_up` | If the input plugin has enabled `filesystem` storage type, this property sets the maximum number of chunks that can be `up` in memory. Use this setting to control memory usage when you enable `storage.type filesystem`. | `128` |
 | `storage.backlog.mem_limit` | If `storage.path` is set, Fluent Bit looks for data chunks that weren't delivered and are still in the storage layer. These are called _backlog_ data. _Backlog chunks_ are filesystem chunks that were left over from a previous Fluent Bit run; chunks that couldn't be sent before exit that Fluent Bit will pick up when restarted. Fluent Bit will check the `storage.backlog.mem_limit` value against the current memory usage from all `up` chunks for the input. If the `up` chunks currently consume less memory than the limit, it will bring the _backlog_ chunks up into memory so they can be sent by outputs. | `5M` |
-| `storage.backlog.flush_on_shutdown` | When enabled, Fluent Bit will attempt to flush all backlog filesystem chunks to their destination(s) during the shutdown process. This can help ensure data delivery before Fluent Bit stops, but may increase shutdown time. Accepted values: `Off`, `On`. | `Off` |
+| `storage.backlog.flush_on_shutdown` | When enabled, Fluent Bit will attempt to flush all backlog filesystem chunks to their destination during the shutdown process. This can help ensure data delivery before Fluent Bit stops, but can increase shutdown time. Accepted values: `Off`, `On`. | `Off` |
 | `storage.metrics` | If `http_server` option is enabled in the main `[SERVICE]` section, this option registers a new endpoint where internal metrics of the storage layer can be consumed. For more details refer to the [Monitoring](monitoring.md) section. | `off` |
-| `storage.delete_irrecoverable_chunks` | When enabled, [irrecoverable chunks](./buffering-and-storage.md#irrecoverable-chunks) will be deleted during runtime, and any other irrecoverable chunk located in the configured storage path directory will be deleted when Fluent-Bit starts. Accepted values: 'Off`, 'On`. | `Off` |
+| `storage.delete_irrecoverable_chunks` | When enabled, [irrecoverable chunks](./buffering-and-storage.md#irrecoverable-chunks) will be deleted during runtime, and any other irrecoverable chunk located in the configured storage path directory will be deleted when Fluent Bit starts. Accepted values: `Off`, 'On`. | `Off` |
 
 A Service section will look like this:
 
@@ -184,7 +184,7 @@ service:
 
 This configuration sets an optional buffering mechanism where the route to the data is `/var/log/flb-storage/`. It uses `normal` synchronization mode, without running a checksum and up to a maximum of 5 MB of memory when processing backlog data.
 
-### Input Section Configuration
+### Input section configuration
 
 Optionally, any Input plugin can configure their storage preference. The following table describes the options available:
 
@@ -242,7 +242,7 @@ pipeline:
 {% endtab %}
 {% endtabs %}
 
-### Output Section Configuration
+### Output section configuration
 
 If certain chunks are filesystem `storage.type` based, it's possible to control the size of the logical queue for an output plugin. The following table describes the options available:
 
@@ -302,4 +302,5 @@ pipeline:
 {% endtab %}
 {% endtabs %}
 
-If Fluent Bit is offline because of a network issue, it will continue buffering CPU samples, keeping a maximum of 5 MB of the newest data.
+If Fluent Bit is offline because of a network issue, it will continue buffering CPU
+samples, keeping a maximum of 5 MB of the newest data.

administration/configuring-fluent-bit/README.md

@@ -133,4 +133,4 @@ Outputs
   prometheus_exporter     Prometheus Exporter
   prometheus_remote_write Prometheus remote write
   s3                      Send to S3
-```
+```

administration/configuring-fluent-bit/classic-mode/commands.md

@@ -6,10 +6,10 @@ Fluent Bit `Commands` extends a configuration file with specific built-in featur
 
 | Command | Prototype | Description |
 | :--- | :--- | :--- |
-| [`@INCLUDE`](commands.md#cmd_include) | `@INCLUDE FILE` | Include a configuration file. |
-| [`@SET`](commands.md#cmd_set) | `@SET KEY=VAL` | Set a configuration variable. |
+| [`@INCLUDE`](#include) | `@INCLUDE FILE` | Include a configuration file. |
+| [`@SET`](#set) | `@SET KEY=VAL` | Set a configuration variable. |
 
-## `@INCLUDE` <a id="cmd_include"></a>
+## `@INCLUDE`
 
 Configuring a logging pipeline might lead to an extensive configuration file. In order to maintain a human-readable configuration, split the configuration in multiple files.
 
@@ -47,7 +47,7 @@ The following is an example of an `inputs.conf` file, like the one called in the
     Tag  varlog.*
 ```
 
-### outputs.conf
+### `outputs.conf`
 
 The following is an example of an `outputs.conf` file, like the one called in the previous example.
 
@@ -64,7 +64,7 @@ The following is an example of an `outputs.conf` file, like the one called in th
     Logstash_Format On
 ```
 
-## `@SET` <a id="cmd_set"></a>
+## `@SET`
 
 Fluent Bit supports [configuration variables](variables.md). One way to expose this variables to Fluent Bit is through setting a shell environment variable, the other is through the `@SET` command.
 

administration/configuring-fluent-bit/classic-mode/configuration-file.md

@@ -1,7 +1,3 @@
----
-description: This page describes the main configuration file used by Fluent Bit.
----
-
 # Configuration file
 
 <img referrerpolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=5e67142e-3887-4b56-b940-18494bcc23a7" />
@@ -119,7 +115,7 @@ The following is an example of an `OUTPUT` section:
     Match my*cpu
 ```
 
-### Example: collecting CPU metrics
+### Collecting `cpu` metrics example
 
 The following configuration file example demonstrates how to collect CPU metrics and flush the results every five seconds to the standard output:
 
@@ -138,7 +134,7 @@ The following configuration file example demonstrates how to collect CPU metrics
     Match my*cpu
 ```
 
-## Config Include File
+## Config include file
 
 To avoid complicated long configuration files is better to split specific parts in different files and call them (include) from one main file. The `@INCLUDE` can be used in the following way:
 

administration/configuring-fluent-bit/classic-mode/format-schema.md

@@ -27,13 +27,13 @@ A section is defined by a name or title inside brackets. Using the previous exam
 - Any commented line under a section must be indented too.
 - End-of-line comments aren't supported, only full-line comments.
 
-## Entries: key/value
+## Entries: `key`/`value`
 
 A section can contain entries. An entry is defined by a line of text that contains a `Key` and a `Value`. Using the previous example, the `[SERVICE]` section contains two entries: one is the key `Daemon` with value `off` and the other is the key `Log_Level` with the value `debug`. The following rules apply:
 
 - An entry is defined by a key and a value.
 - A key must be indented.
-- A key must contain a value which ends in the breakline.
+- A key must contain a value which ends in a line break.
 - Multiple keys with the same name can exist.
 
 Commented lines are set prefixing the `#` character. Commented lines aren't processed but they must be indented.

administration/configuring-fluent-bit/multiline-parsing.md

@@ -59,7 +59,7 @@ A rule specifies how to match a multiline pattern and perform the concatenation.
 - regular expression pattern
 - next state
 
-A rule might be defined as follows (comments added to simplify the definition) in corresponding YAML and classic configuration examples below:
+A rule might be defined as follows (comments added to simplify the definition) in the corresponding YAML and classic configuration examples:
 
 {% tabs %}
 {% tab title="parsers_multiline.yaml" %}
@@ -99,7 +99,7 @@ To simplify the configuration of regular expressions, you can use the [Rubular](
 
 #### Configuration example
 
-The following example provides a full Fluent Bit configuration file for multiline parsing by using the definition  explained previously. It is provided in corresponding YAML and classic configuration examples below:
+The following example provides a full Fluent Bit configuration file for multiline parsing by using the definition explained previously. It's provided in following YAML and classic configuration examples:
 
 {% tabs %}
 
@@ -344,7 +344,7 @@ multiline_parsers:
       - state: start_state
         regex: '/([a-zA-Z]+ \d+ \d+\:\d+\:\d+)(.*)/'
         next_state:  cont
-    
+
       - state: cont
         regex: '/^\s+at.*/'
         next_state: cont
@@ -367,9 +367,9 @@ This file defines a multiline parser for the classic example.
   flush_timeout 1000
   #
   # Regex rules for multiline parsing
-  # --------------------------------- 
+  # ---------------------------------
   #
-  # configuration hints:  
+  # configuration hints:
   #
   #  - first state always has the name: start_state
   #  - every field in the rule must be inside double quotes
@@ -425,4 +425,4 @@ $ ./fluent-bit --config fluent-bit.conf
 "}]
 [2] tail.0: [[1750333602.460998000, {}], {"log"=>"another line...
 "}]
-```
+```

administration/configuring-fluent-bit/yaml/README.md

@@ -1,28 +1,28 @@
 # YAML configuration
 
-## Before You Get Started
+## Before you get started
 
-Fluent Bit traditionally offered a `classic` configuration mode, a custom configuration format that we are gradually phasing out. While `classic` mode has served well for many years, it has several limitations. Its basic design only supports grouping sections with key-value pairs and lacks the ability to handle sub-sections or complex data structures like lists.
+Fluent Bit traditionally offered a `classic` configuration mode, a custom configuration format that's phasing out. While `classic` mode has served well for many years, it has several limitations. Its basic design only supports grouping sections with key-value pairs and lacks the ability to handle sub-sections or complex data structures like lists.
 
-YAML, now a mainstream configuration format, has become essential in a cloud ecosystem where everything is configured this way. To minimize friction and provide a more intuitive experience for creating data pipelines, we strongly encourage users to transition to YAML. The YAML format enables features, such as processors, that are not possible to configure in `classic` mode.
+YAML has become essential in a cloud ecosystem. To minimize friction and provide a more intuitive experience for creating data pipelines, users are encouraged to transition to YAML. The YAML format enables features, such as processors, that aren't possible to configure in `classic` mode.
 
 As of Fluent Bit v3.2, you can configure everything in YAML.
 
-## List of Available Sections
+## List of available sections
 
 Configuring Fluent Bit with YAML introduces the following root-level sections:
 
-| Section Name         |Description                                                                                                                                           |
-|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `service`            | Describes the global configuration for the Fluent Bit service. This section is optional; if not set, default values will apply. Only one `service` section can be defined. |
-| `parsers`            | Lists parsers to be used by components like inputs, processors, filters, or output plugins. You can define multiple `parsers` sections, which can also be loaded from external files included in the main YAML configuration. |
-| `multiline_parsers`  | Lists multiline parsers, functioning similarly to `parsers`. Multiple definitions can exist either in the root or in included files.                    |
-| `pipeline`           | Defines a pipeline composed of inputs, processors, filters, and output plugins. You can define multiple `pipeline` sections, but they will not operate independently. Instead, all components will be merged into a single pipeline internally. |
-| `plugins`            | Specifies the path to external plugins (.so files) to be loaded by Fluent Bit at runtime.                                                              |
-| `upstream_servers`          | Refers to a group of node endpoints that can be referenced by output plugins that support this feature.                                                |
-| `env`                | Sets a list of environment variables for Fluent Bit. Note that system environment variables are available, while the ones defined in the configuration apply only to Fluent Bit. |
-
-## Section Documentation
+| Section Name | Description |
+|--------------|-------------|
+| `service` | Describes the global configuration for the Fluent Bit service. Optional. If not set, default values will apply. Only one `service` section can be defined. |
+| `parsers` | Lists parsers to be used by components like inputs, processors, filters, or output plugins. You can define multiple `parsers` sections, which can also be loaded from external files included in the main YAML configuration. |
+| `multiline_parsers`  | Lists multiline parsers, functioning similarly to `parsers`. Multiple definitions can exist either in the root or in included files. |
+| `pipeline` | Defines a pipeline composed of inputs, processors, filters, and output plugins. You can define multiple `pipeline` sections, but they won't operate independently. Instead, all components will be merged into a single pipeline internally. |
+| `plugins` | Specifies the path to external plugins (`.so` files) to be loaded by Fluent Bit at runtime. |
+| `upstream_servers` | Refers to a group of node endpoints that can be referenced by output plugins that support this feature. |
+| `env` | Sets a list of environment variables for Fluent Bit. System environment variables are available, while the ones defined in the configuration apply only to Fluent Bit. |
+
+## Section documentation
 
 To access detailed configuration guides for each section, use the following links: