Apply suggestions from code review

alexakreizinger · cnorris-cs · web-flow · commit 9f62939e00ec · 2024-08-27T10:20:41.000-07:00
Co-authored-by: Craig Norris &lt;112565517+cnorris-cs@users.noreply.github.com&gt;
Signed-off-by: Alexa Kreizinger &lt;alexakreizinger@gmail.com&gt;
diff --git a/pipeline/inputs/collectd.md b/pipeline/inputs/collectd.md
@@ -11,7 +11,7 @@ The plugin supports the following configuration parameters:
 | Listen | Set the address to listen to | 0.0.0.0 |
 | Port | Set the port to listen to | 25826 |
 | TypesDB | Set the data specification file | /usr/share/collectd/types.db |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Configuration Examples <a id="config_example"></a>
 
diff --git a/pipeline/inputs/cpu-metrics.md b/pipeline/inputs/cpu-metrics.md
@@ -4,7 +4,8 @@ The **cpu** input plugin, measures the CPU usage of a process or the whole syste
 
 The following tables describes the information generated by the plugin. The keys below represent the data used by the overall system, all values associated to the keys are in a percentage unit \(0 to 100%\):
 
-The CPU metrics plugin creates metrics that are log-based \(I.e. JSON payload\). If you are looking for Prometheus-based metrics please see the Node Exporter Metrics input plugin.
+The CPU metrics plugin creates metrics that are log-based, such as JSON payload. For
+Prometheus-based metrics, see the Node Exporter Metrics input plugin.
 
 | key | description |
 | :--- | :--- |
diff --git a/pipeline/inputs/disk-io-metrics.md b/pipeline/inputs/disk-io-metrics.md
@@ -2,7 +2,8 @@
 
 The **disk** input plugin, gathers the information about the disk throughput of the running system every certain interval of time and reports them.
 
-The Disk I/O metrics plugin creates metrics that are log-based \(I.e. JSON payload\). If you are looking for Prometheus-based metrics please see the Node Exporter Metrics input plugin.
+The Disk I/O metrics plugin creates metrics that are log-based, such as JSON payload.
+For Prometheus-based metrics, see the Node Exporter Metrics input plugin.
 
 ## Configuration Parameters
 
@@ -13,7 +14,7 @@ The plugin supports the following configuration parameters:
 | Interval\_Sec | Polling interval \(seconds\).  | 1 |
 | Interval\_NSec | Polling interval \(nanosecond\). | 0 |
 | Dev\_Name | Device name to limit the target. \(e.g. sda\). If not set, _in\_disk_ gathers information from all of disks and partitions. | all disks |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
diff --git a/pipeline/inputs/docker-events.md b/pipeline/inputs/docker-events.md
@@ -14,7 +14,7 @@ This plugin supports the following configuration parameters:
 | Key | When a message is unstructured \(no parser applied\), it's appended as a string under the key name _message_. | message |
 | Reconnect.Retry_limits| The maximum number of retries allowed. The plugin tries to reconnect with docker socket when EOF is detected. | 5 |
 | Reconnect.Retry_interval| The retrying interval. Unit is second. | 1 |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ### Command Line
 
diff --git a/pipeline/inputs/docker-metrics.md b/pipeline/inputs/docker-metrics.md
@@ -15,7 +15,7 @@ The plugin supports the following configuration parameters:
 | Interval_Sec | Polling interval in seconds                     | 1       |
 | Include      | A space-separated list of containers to include |         |
 | Exclude      | A space-separated list of containers to exclude |         |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 If you set neither `Include` nor `Exclude`, the plugin will try to get metrics from _all_ the running containers.
 
diff --git a/pipeline/inputs/dummy.md b/pipeline/inputs/dummy.md
@@ -18,7 +18,7 @@ The plugin supports the following configuration parameters:
 | Samples            | If set, the events number will be limited. For example, if Samples=3, the plugin generates only three events and stops. | _none_ |
 | Copies             | Number of messages to generate each time they are generated. | `1` |
 | Flush\_on\_startup | If set to `true`, the first dummy event is generated at startup. | `false` |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
diff --git a/pipeline/inputs/elasticsearch.md b/pipeline/inputs/elasticsearch.md
@@ -14,7 +14,7 @@ The plugin supports the following configuration parameters:
 | meta\_key | Specify a key name for meta information. | "@meta" |
 | hostname | Specify hostname or FQDN. This parameter can be used for "sniffing" (auto-discovery of) cluster node information. | "localhost" |
 | version  | Specify Elasticsearch server version. This parameter is effective for checking a version of Elasticsearch/OpenSearch server version. | "8.0.0" |
-| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 **Note:** The Elasticsearch cluster uses "sniffing" to optimize the connections between its cluster and clients.
 Elasticsearch can build its cluster and dynamically generate a connection list which is called "sniffing".
diff --git a/pipeline/inputs/fluentbit-metrics.md b/pipeline/inputs/fluentbit-metrics.md
@@ -18,7 +18,7 @@ They can be sent to output plugins including [Prometheus Exporter](../outputs/pr
 | --------------- | --------------------------------------------------------------------------------------------------------- | --------- |
 | scrape_interval | The rate at which metrics are collected from the host operating system                                    | 2 seconds |
 | scrape_on_start | Scrape metrics upon start, useful to avoid waiting for 'scrape_interval' for the first round of metrics.  | false     |
-| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 
 ## Getting Started
diff --git a/pipeline/inputs/forward.md b/pipeline/inputs/forward.md
@@ -20,7 +20,7 @@ The plugin supports the following configuration parameters:
 | Shared\_Key         | Shared key for secure forward authentication. |  |
 | Self\_Hostname      | Hostname for secure forward authentication.   |  |
 | Security.Users      | Specify the username and password pairs for secure forward authentication. | |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
diff --git a/pipeline/inputs/http.md b/pipeline/inputs/http.md
@@ -15,7 +15,7 @@ description: The HTTP input plugin allows you to send custom records to an HTTP
 | buffer_chunk_size        | This sets the chunk size for incoming incoming JSON messages. These chunks are then stored/managed in the space available by buffer_max_size. | 512K    |
 | successful_response_code | It allows to set successful response code. `200`, `201` and `204` are supported.                                                              | 201     |
 | success_header           | Add an HTTP header key/value pair on success. Multiple headers can be set. Example: `X-Custom custom-answer`                                  |         |
-| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ### TLS / SSL
 
diff --git a/pipeline/inputs/kafka.md b/pipeline/inputs/kafka.md
@@ -15,7 +15,7 @@ This plugin uses the official [librdkafka C library](https://github.com/edenhill
 | poll\_ms | Kafka brokers polling interval in milliseconds. | 500 |
 | Buffer\_Max\_Size | Specify the maximum size of buffer per cycle to poll kafka messages from subscribed topics. To increase throughput, specify larger size. | 4M |
 | rdkafka.{property} | `{property}` can be any [librdkafka properties](https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md) |  |
-| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
@@ -46,7 +46,8 @@ In your main configuration file append the following _Input_ & _Output_ sections
 
 #### Example of using kafka input/output plugins
 
-The fluent-bit source repository contains a full example of using fluent-bit to process kafka records:
+The Fluent Bit source repository contains a full example of using Fluent Bit to
+process Kafka records:
 
 ```text
 [INPUT]
diff --git a/pipeline/inputs/kernel-logs.md b/pipeline/inputs/kernel-logs.md
@@ -7,7 +7,7 @@ The **kmsg** input plugin reads the Linux Kernel log buffer since the beginning,
 | Key | Description | Default |
 | :--- | :--- | :--- |
 | Prio_Level | The log level to filter. The kernel log is dropped if its priority is more than prio_level. Allowed values are 0-8. Default is 8. 8 means all logs are saved. | 8 |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
diff --git a/pipeline/inputs/network-io-metrics.md b/pipeline/inputs/network-io-metrics.md
@@ -2,7 +2,8 @@
 
 The **netif** input plugin gathers network traffic information of the running system every certain interval of time, and reports them.
 
-The Network I/O Metrics plugin creates metrics that are log-based \(I.e. JSON payload\). If you are looking for Prometheus-based metrics please see the Node Exporter Metrics input plugin.
+The Network I/O Metrics plugin creates metrics that are log-based, such as JSON
+payload. For Prometheus-based metrics, see the Node Exporter Metrics input plugin.
 
 ## Configuration Parameters
 
@@ -15,7 +16,7 @@ The plugin supports the following configuration parameters:
 | Interval\_NSec | Polling interval \(nanosecond\). | 0 |
 | Verbose | If true, gather metrics precisely. | false |
 | Test\_At\_Init | If true, testing if the network interface is valid at initialization. | false |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
diff --git a/pipeline/inputs/nginx.md b/pipeline/inputs/nginx.md
@@ -12,7 +12,7 @@ The plugin supports the following configuration parameters:
 | Port | Port of the target nginx service to connect to. | 80 |
 | Status_URL | The URL of the Stub Status Handler. | /status |
 | Nginx_Plus | Turn on NGINX plus mode. | true |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
@@ -36,8 +36,8 @@ server {
 
 ### Configuration with NGINX Plus REST API
 
-A much more powerful and flexible metrics API is available with NGINX Plus. A path needs to be configured
-in NGINX Plus first.
+Another metrics API is available with NGINX Plus. You must first configure a path in
+NGINX Plus.
 
 ```
 server {
diff --git a/pipeline/inputs/opentelemetry.md b/pipeline/inputs/opentelemetry.md
@@ -20,7 +20,7 @@ Our compliant implementation fully supports OTLP/HTTP and OTLP/GRPC. Note that t
 | buffer_chunk_size | Initial size and allocation strategy to store the payload (advanced users only)    | 512K    |
 |successful_response_code | It allows to set successful response code. `200`, `201` and `204` are supported.| 201 |
 | tag_from_uri      | If true, tag will be created from uri. e.g. v1_metrics from /v1/metrics .                                                                      | true    |
-| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 Important note: Raw traces means that any data forwarded to the traces endpoint (`/v1/traces`) will be packed and forwarded as a log message, and will NOT be processed by Fluent Bit. The traces endpoint by default expects a valid protobuf encoded payload, but you can set the `raw_traces` option in case you want to get trace telemetry data to any of Fluent Bit's supported outputs.
 
diff --git a/pipeline/inputs/podman-metrics.md b/pipeline/inputs/podman-metrics.md
@@ -13,7 +13,7 @@ description: The Podman Metrics input plugin allows you to collect metrics from
 | path.config       | Custom path to podman containers configuration file        | /var/lib/containers/storage/overlay-containers/containers.json |
 | path.sysfs        | Custom path to sysfs subsystem directory                   | /sys/fs/cgroup                                                 |
 | path.procfs       | Custom path to proc subsystem directory                    | /proc                                                          |
-| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
diff --git a/pipeline/inputs/process-exporter-metrics.md b/pipeline/inputs/process-exporter-metrics.md
@@ -87,7 +87,8 @@ curl http://127.0.0.1:2021/metrics
 ### Container to Collect Host Metrics
 
 When deploying Fluent Bit in a container you will need to specify additional settings to ensure that Fluent Bit has access to the process details.
-The following `docker` command deploys Fluent Bit with a specific mount path for `procfs` and settings enabled to ensure that Fluent Bit can collect from the host.
+The following `docker` command deploys Fluent Bit with a specific mount path for
+`procfs` and settings enabled to ensure that Fluent Bit can collect from the host.
 These are then exposed over port 2021.
 
 ```
diff --git a/pipeline/inputs/process.md b/pipeline/inputs/process.md
@@ -3,7 +3,8 @@
 
 _Process_ input plugin allows you to check how healthy a process is. It does so by performing a service check at every certain interval of time specified by the user.
 
-The Process metrics plugin creates metrics that are log-based \(I.e. JSON payload\). If you are looking for Prometheus-based metrics please see the Node Exporter Metrics input plugin.
+The Process metrics plugin creates metrics that are log-based, such as JSON payload.
+For Prometheus-based metrics, see the Node Exporter Metrics input plugin.
 
 ## Configuration Parameters
 
diff --git a/pipeline/inputs/prometheus-remote-write.md b/pipeline/inputs/prometheus-remote-write.md
@@ -17,7 +17,7 @@ This input plugin allows you to ingest a payload in the Prometheus remote-write
 |successful\_response\_code | It allows to set successful response code. `200`, `201` and `204` are supported.| 201 |
 | tag\_from\_uri      | If true, tag will be created from uri, e.g. api\_prom\_push from /api/prom/push, and any tag specified in the config will be ignored. If false then a tag must be provided in the config for this input. | true    |
 | uri               | Specify an optional HTTP URI for the target web server listening for prometheus remote write payloads, e.g: /api/prom/push                       | |
-| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 
 A sample config file to get started will look something like the following:
diff --git a/pipeline/inputs/prometheus-scrape-metrics.md b/pipeline/inputs/prometheus-scrape-metrics.md
@@ -12,7 +12,7 @@ The initial release of the Prometheus Scrape metric allows you to collect metric
 | port            | The port of the prometheus metric endpoint that you want to scrape                                                                                    |          |
 | scrape\_interval | The interval to scrape metrics                                                                                                                       | 10s      |
 | metrics\_path   | <p>The metrics URI endpoint, that must start with a forward slash.<br><br>Note: Parameters can also be added to the path by using <code>?</code></p> | /metrics |
-| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Example
 
diff --git a/pipeline/inputs/splunk.md b/pipeline/inputs/splunk.md
@@ -13,7 +13,7 @@ The **splunk** input plugin handles [Splunk HTTP HEC](https://docs.splunk.com/Do
 | buffer_chunk_size        | This sets the chunk size for incoming incoming JSON messages. These chunks are then stored/managed in the space available by buffer_max_size. | 512K    |
 | successful_response_code | It allows to set successful response code. `200`, `201` and `204` are supported.                                                              | 201     |
 | splunk\_token           | Add an Splunk token for HTTP HEC.`                                  |         |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
diff --git a/pipeline/inputs/standard-input.md b/pipeline/inputs/standard-input.md
@@ -204,4 +204,4 @@ The plugin supports the following configuration parameters:
 | :--- | :--- | :--- |
 | Buffer\_Size | Set the buffer size to read data. This value is used to increase buffer size. The value must be according to the [Unit Size](../../administration/configuring-fluent-bit/unit-sizes.md) specification. | 16k |
 | Parser | The name of the parser to invoke instead of the default JSON input parser | |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
diff --git a/pipeline/inputs/statsd.md b/pipeline/inputs/statsd.md
@@ -15,7 +15,7 @@ The plugin supports the following configuration parameters:
 | :--- | :--- | :--- |
 | Listen | Listener network interface. | 0.0.0.0 |
 | Port | UDP port where listening for connections | 8125 |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Configuration Examples <a id="config_example"></a>
 
diff --git a/pipeline/inputs/syslog.md b/pipeline/inputs/syslog.md
@@ -18,7 +18,7 @@ The plugin supports the following configuration parameters:
 | Buffer\_Max\_Size | Specify the maximum buffer size to receive a Syslog message. If not set, the default size will be the value of _Buffer\_Chunk\_Size_. |  |
 | Receive\_Buffer\_Size | Specify the maximum socket receive buffer size. If not set, the default value is OS-dependant, but generally too low to accept thousands of syslog messages per second without loss on _udp_ or _unix\_udp_ sockets. Note that on Linux the value is capped by `sysctl net.core.rmem_max`.| |
 | Source\_Address\_Key| Specify the key where the source address will be injected. | |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ### Considerations
 
diff --git a/pipeline/inputs/systemd.md b/pipeline/inputs/systemd.md
@@ -19,7 +19,7 @@ The plugin supports the following configuration parameters:
 | Read\_From\_Tail | Start reading new entries. Skip entries already stored in Journald. | Off |
 | Lowercase | Lowercase the Journald field \(key\). | Off |
 | Strip\_Underscores | Remove the leading underscore of the Journald field \(key\). For example the Journald field _\_PID_ becomes the key _PID_. | Off |
-| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | false |
+| Threaded | Indicates whether to run this input in its own [thread](../../administration/multithreading.md#inputs). | `false` |
 
 ## Getting Started
 
diff --git a/pipeline/inputs/tail.md b/pipeline/inputs/tail.md
diff --git a/pipeline/inputs/tcp.md b/pipeline/inputs/tcp.md
diff --git a/pipeline/inputs/udp.md b/pipeline/inputs/udp.md
diff --git a/pipeline/inputs/windows-event-log-winevtlog.md b/pipeline/inputs/windows-event-log-winevtlog.md
diff --git a/pipeline/inputs/windows-event-log.md b/pipeline/inputs/windows-event-log.md
