Correct some spelling and grammar issues

Improve documentation readability.

Signed-off-by: Brad Solomon <81818815+brsolomon-deloitte@users.noreply.github.com>

Author: brsolomon-deloitte

container-deployment/kubernetes.md

@@ -35,7 +35,7 @@ Since applications runs in Pods and multiple Pods might exists across multiple n
 
 For [Kubernetes](https://kubernetes.io), a [DaemonSet](https://kubernetes.io/docs/admin/daemons/) ensures that all \(or some\) nodes run a copy of a _pod_. To solve log collection, we are going to implement a Fluentd DaemonSet.
 
-Fluentd is flexible enough and have the proper plugins to distribute logs to different third-party applications like databases or cloud services, so the principal question is to know: _Where the logs will be stored?_. Once we got that question answered, we can move forward configuring our DaemonSet.
+Fluentd is flexible enough and has the proper plugins to distribute logs to different third-party applications like databases or cloud services, so the principal question is _Where will the logs be stored?_. Once we got that question answered, we can move forward configuring our DaemonSet.
 
 The following steps will focus on sending the logs to an Elasticsearch Pod:
 

deployment/high-availability.md

@@ -26,9 +26,9 @@ In such systems, several delivery guarantees are possible:
 
   is the most desirable.
 
-If the system "**can't lose a single event**", and must also transfer "**exactly once**", then the system must stop ingesting events when it runs out of write capacity. The proper approach would be to use synchronous logging and return errors when the event cannot be accepted.
+If the system "**can't lose a single event**" and must also transfer "**exactly once**", then the system must stop ingesting events when it runs out of write capacity. The proper approach would be to use synchronous logging and return errors when the event cannot be accepted.
 
-That's why Fluentd provides '**at most once**' and '**at least once**' transfers. To collect massive amounts of data without impacting application performance, a data logger must transfer data asynchronously. This improves performance at the cost of potential delivery failures.
+That's why Fluentd provides "**at most once**" and "**at least once**" transfers. To collect massive amounts of data without impacting application performance, a data logger must transfer data asynchronously. This improves performance at the cost of potential delivery failures.
 
 However, most failure scenarios are preventable. The following sections describe how to set up Fluentd's topology for high-availability.
 
@@ -38,9 +38,9 @@ To configure Fluentd for high-availability, we assume that your network consists
 
 ![Fluentd's High-Availability Overview](../.gitbook/assets/fluentd_ha%20%281%29%20%281%29%20%281%29.png)
 
-'**log forwarders**' are typically installed on every node to receive local events. Once an event is received, they forward it to the 'log aggregators' through the network. For log forwarders, [fluent-bit](https://fluentbit.io/) is also good candidate for light-weight processing.
+'**Log forwarders**' are typically installed on every node to receive local events. Once an event is received, they forward it to the 'log aggregators' through the network. For log forwarders, [fluent-bit](https://fluentbit.io/) is also good candidate for light-weight processing.
 
-'**log aggregators**' are daemons that continuously receive events from the log forwarders. They buffer the events and periodically upload the data into the cloud.
+'**Log aggregators**' are daemons that continuously receive events from the log forwarders. They buffer the events and periodically upload the data into the cloud.
 
 Fluentd can act as either a log forwarder or a log aggregator, depending on its configuration. The next sections describe the respective setups. We assume that the active log aggregator has an IP **192.168.0.1** and the backup has IP **192.168.0.2**.
 
@@ -112,7 +112,7 @@ The incoming logs are buffered, then periodically uploaded to the cloud. If the
 
 When a log forwarder receives events from applications, the events are first written into a disk buffer \(specified by `<buffer>`'s `path`\). After every `flush_interval`, the buffered data is forwarded to aggregators.
 
-This process is inherently robust against data loss. If a log forwarder's fluentd process dies then on its restart the buffered data is properly transferred to its aggregator. If the network between forwarders and aggregators breaks, the data transfer is automatically retried.
+This process is inherently robust against data loss. If a log forwarder's fluentd process dies, then on its restart, the buffered data is properly transferred to its aggregator. If the network between forwarders and aggregators breaks, the data transfer is automatically retried.
 
 However, possible message loss scenarios do exist:
 
@@ -126,7 +126,7 @@ However, possible message loss scenarios do exist:
 
 When log aggregators receive events from log forwarders, the events are first written into a disk buffer \(specified by `<buffer>`'s `path`\). After every `flush_interval`, the buffered data is uploaded to the cloud.
 
-This process is inherently robust against data loss. If a log aggregator's fluentd process dies then on its restart the data from the log forwarder is properly retransferred. If the network between aggregators and the cloud breaks, the data transfer is automatically retried.
+This process is inherently robust against data loss. If a log aggregator's fluentd process dies, then on its restart, the data from the log forwarder is properly retransferred. If the network between aggregators and the cloud breaks, the data transfer is automatically retried.
 
 However, possible message loss scenarios do exist:
 

deployment/multi-process-workers.md

@@ -8,7 +8,7 @@ This feature can simply replace `fluent-plugin-multiprocess`.
 
 By default, one instance of `fluentd` launches a supervisor and a worker. A worker consists of input/filter/output plugins.
 
-Multi-process workers feature launches multiple workers and use a separate process per worker. `fluentd` provides several features for multi-process workers, so you can get multi-process merits.
+The **multi-process workers** feature launches multiple workers and use a separate process per worker. `fluentd` provides several features for multi-process workers.
 
 ![Multi-process Workers](../.gitbook/assets/multi-process-workers%20%281%29%20%281%29.png)
 

deployment/performance-tuning-single-process.md

@@ -71,11 +71,8 @@ Ruby has several GC parameters to tune GC performance and you can configure thes
 
 Here's a quote from the documentation:
 
-```text
-Do full GC when the number of old objects is more than R * N
-  where R is this factor and
-  N is the number of old objects just after last full GC.
-```
+> Do full GC when the number of old objects is more than R * N
+> where R is this factor and N is the number of old objects just after last full GC.
 
 So, the default GC behavior does not call full GC until the number of old objects reaches `2.0 * before old objects`. This improves the throughput but it grows the total memory usage. This setting is not good for the low resource environment e.g. a small container. For such cases, try `RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0.9` or `RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.2`.
 

deployment/rpc.md

@@ -2,7 +2,7 @@
 
 HTTP RPC enables you to manage your Fluentd instance through HTTP endpoints. You can use this feature as a replacement of [Unix signals](signals.md).
 
-It is especially useful for environments where signals are not supported well e.g. Windows. This requires Fluentd to start not with --no-supervisor command-line option.
+It is especially useful for environments where signals are not supported well e.g. Windows. This requires Fluentd to start not with `--no-supervisor` command-line option.
 
 ## Configuration
 

deployment/system-config.md

@@ -1,6 +1,6 @@
 # System Configuration
 
-This article describes the Fluentd's system configurations for `<system>` section and command-line options.
+This article describes Fluentd's system configurations for the `<system>` section and command-line options.
 
 ## Overview
 

deployment/trouble-shooting.md

@@ -87,7 +87,7 @@ You sometimes hit unexpected shutdown with non-zero exit status like this:
 2016-01-01 00:00:02 +0800 [info]: process finished code=6
 ```
 
-If the problem happens inside Ruby e.g. segmentation fault, C extension bug, etc., you cannot get the complete log when `fluentd` process is daemonized. For example, `td-agent` launches fluentd with `--daemon` option. In `td-agent` case, you can get the complete log with following command to simulate `/etc/init.d/td-agent start` without daemonize:
+If the problem happens inside Ruby e.g. segmentation fault, C extension bug, etc., you cannot get the complete log when `fluentd` process is daemonized. For example, `td-agent` launches fluentd with `--daemon` option. In `td-agent` case, you can get the complete log with following command to simulate `/etc/init.d/td-agent start` without daemonizing (run in the foreground):
 
 ```text
 $ sudo LD_PRELOAD=/opt/td-agent/embedded/lib/libjemalloc.so /usr/sbin/td-agent -c /etc/td-agent/td-agent.conf --user td-agent --group td-agent

how-to-guides/free-alternative-to-splunk-by-fluentd.md

@@ -6,7 +6,7 @@
 
 [Elasticsearch](https://www.elastic.co/products/elasticsearch) is an open-source search engine well-known for its ease of use. [Kibana](https://www.elastic.co/products/kibana) is an open-source Web UI that makes Elasticsearch user friendly for marketers, engineers and data scientists alike.
 
-By combining these three tools \(Fluentd + Elasticsearch + Kibana\) we get a scalable, flexible, easy to use the log search engine with a great Web UI that provides an open-source Splunk alternative, all for free.
+By combining these three tools \(Fluentd + Elasticsearch + Kibana\) we get a scalable, flexible, easy to use log search engine with a great Web UI that provides an open-source Splunk alternative, all for free.
 
 ![Fluentd + Elasticsearch + Kibana](../.gitbook/assets/fluentd-elasticsearch-kibana.png)
 
@@ -45,7 +45,7 @@ Note: You can also install Elasticsearch \(and Kibana\) using RPM/DEB packages.
 
 ## Set Up Kibana
 
-To install Kibana, download it from the official website and extract it. Kibana is an HTML/CSS/JavaScript application \([download](https://www.elastic.co/downloads/kibana)\). Use the binary for 64-bit Linux systems. For this article, we download the binary for macOS.
+To install Kibana, download it from the official website and extract it. Kibana is an HTML/CSS/JavaScript application \([download](https://www.elastic.co/downloads/kibana)\). Use the binary for 64-bit Linux systems.
 
 ```text
 $ curl -O https://artifacts.elastic.co/downloads/kibana/kibana-6.1.0-linux-x86_64.tar.gz

how-to-guides/syslog-influxdb.md

@@ -55,7 +55,7 @@ Once it is installed, you can run it with:
 $ sudo systemctl start chronograf
 ```
 
-Then, go to localhost:8888 \(or wherever you are hosting Chronograf\) to access Chronograf's web console which is the successor of InfluxDB's web console.
+Then, go to localhost:8888 \(or wherever you are hosting Chronograf\) to access Chronograf's web console which is the successor to InfluxDB's web console.
 
 Create a database called `test`. This is where we will be storing `syslog` data:
 

installation/before-install.md

@@ -12,7 +12,7 @@ Follow these recommendations:
 
 It is highly recommended that you set up an NTP daemon \(e.g. [`chrony`](https://chrony.tuxfamily.org/), `ntpd`, etc.\) on the node to have an accurate current timestamp. This is crucial for all the production-grade logging services.
 
-For Amazon Web Services users, we recommend using [AWS-hosted NTP server](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html).
+For Amazon Web Services users, we recommend using the [AWS-hosted NTP server](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html).
 
 ## Increase the Maximum Number of File Descriptors
 
@@ -68,9 +68,9 @@ fs.protected_hardlinks = 1
 fs.protected_symlinks = 1
 ```
 
-This settings are almost enough for time-of-check to time-of-use \(TOCTOU, TOCTTOU or TOC/TOU\) which is a class of software bugs.
+This settings are almost enough for time-of-check to time-of-use (TOCTOU, TOCTTOU or TOC/TOU) which are class of software bugs.
 
-If you turned off these protection, please turn on them.
+If you turned off these protections, please turn on them.
 
 Use `sysctl -p` command or reboot your node for the changes to take effect.