Change "netdata" to "Netdata" in all docs (#6621)

* First pass of changing netdata to Netdata

* Second pass of netdata -> Netdata

* Starting work on netdata with no whitespace after

* Pass for netdata with no whitespace at the end

* Pass for netdata with no whitespace at the front

1 files changed, 24 insertions, 24 deletions

diff --git a/collectors/cgroups.plugin/README.md b/collectors/cgroups.plugin/README.md
index 6ec9024da3..45d2da3be9 100644
--- a/collectors/cgroups.plugin/README.md
+++ b/collectors/cgroups.plugin/README.md
@@ -6,11 +6,11 @@ cgroups (or control groups), are a Linux kernel feature that provides accounting
 
 cgroups are hierarchical, meaning that cgroups can contain child cgroups, which can contain more cgroups, etc. All accounting is reported (and resource usage limits are applied) also in a hierarchical way.
 
-To visualize cgroup metrics netdata provides configuration for cherry picking the cgroups of interest. By default (without any configuration) netdata should pick **systemd services**, all kinds of **containers** (lxc, docker, etc) and **virtual machines** spawn by managers that register them with cgroups (qemu, libvirt, etc).
+To visualize cgroup metrics Netdata provides configuration for cherry picking the cgroups of interest. By default (without any configuration) Netdata should pick **systemd services**, all kinds of **containers** (lxc, docker, etc) and **virtual machines** spawn by managers that register them with cgroups (qemu, libvirt, etc).
 
-## configuring netdata for cgroups
+## configuring Netdata for cgroups
 
-For each cgroup available in the system, netdata provides this configuration:
+For each cgroup available in the system, Netdata provides this configuration:
 
 ```
 [plugin:cgroups]
@@ -21,9 +21,9 @@ But it also provides a few patterns to provide a sane default (`yes` or `no`).
 
 Below we see, how this works.
 
-### how netdata finds the available cgroups
+### how Netdata finds the available cgroups
 
-Linux exposes resource usage reporting and provides dynamic configuration for cgroups, using virtual files (usually) under `/sys/fs/cgroup`. netdata reads `/proc/self/mountinfo` to detect the exact mount point of cgroups. netdata also allows manual configuration of this mount point, using these settings:
+Linux exposes resource usage reporting and provides dynamic configuration for cgroups, using virtual files (usually) under `/sys/fs/cgroup`. Netdata reads `/proc/self/mountinfo` to detect the exact mount point of cgroups. Netdata also allows manual configuration of this mount point, using these settings:
 
 ```
 [plugin:cgroups]
@@ -34,27 +34,27 @@ Linux exposes resource usage reporting and provides dynamic configuration for cg
 	path to /sys/fs/cgroup/devices = /sys/fs/cgroup/devices
 ```
 
-netdata rescans these directories for added or removed cgroups every `check for new cgroups every` seconds.
+Netdata rescans these directories for added or removed cgroups every `check for new cgroups every` seconds.
 
 ### hierarchical search for cgroups
 
-Since cgroups are hierarchical, for each of the directories shown above, netdata walks through the subdirectories recursively searching for cgroups (each subdirectory is another cgroup).
+Since cgroups are hierarchical, for each of the directories shown above, Netdata walks through the subdirectories recursively searching for cgroups (each subdirectory is another cgroup).
 
-For each of the directories found, netdata provides a configuration variable:
+For each of the directories found, Netdata provides a configuration variable:
 
 ```
 [plugin:cgroups]
 	search for cgroups under PATH = yes | no
 ```
 
-To provide a sane default for this setting, netdata uses the following pattern list (patterns starting with `!` give a negative match and their order is important: the first matching a path will be used):
+To provide a sane default for this setting, Netdata uses the following pattern list (patterns starting with `!` give a negative match and their order is important: the first matching a path will be used):
 
 ```
 [plugin:cgroups]
 	search for cgroups in subpaths matching =  !*/init.scope  !*-qemu  !/init.scope  !/system  !/systemd  !/user  !/user.slice  *
 ```
 
-So, we disable checking for **child cgroups** in systemd internal cgroups ([systemd services are monitored by netdata](#monitoring-systemd-services)), user cgroups (normally used for desktop and remote user sessions), qemu virtual machines (child cgroups of virtual machines) and `init.scope`. All others are enabled.
+So, we disable checking for **child cgroups** in systemd internal cgroups ([systemd services are monitored by Netdata](#monitoring-systemd-services)), user cgroups (normally used for desktop and remote user sessions), qemu virtual machines (child cgroups of virtual machines) and `init.scope`. All others are enabled.
 
 ### unified cgroups (cgroups v2) support
 
@@ -71,14 +71,14 @@ Unified cgroups use same name pattern matching as v1 cgroups. `cgroup_enable_sys
 
 ### enabled cgroups
 
-To check if the cgroup is enabled, netdata uses this setting:
+To check if the cgroup is enabled, Netdata uses this setting:
 
 ```
 [plugin:cgroups]
 	enable cgroup NAME = yes | no
 ```
 
-To provide a sane default, netdata uses the following pattern list (it checks the pattern against the path of the cgroup):
+To provide a sane default, Netdata uses the following pattern list (it checks the pattern against the path of the cgroup):
 
 ```
 [plugin:cgroups]
@@ -87,9 +87,9 @@ To provide a sane default, netdata uses the following pattern list (it checks th
 
 The above provides the default `yes` or `no` setting for the cgroup. However, there is an additional step. In many cases the cgroups found in the `/sys/fs/cgroup` hierarchy are just random numbers and in many cases these numbers are ephemeral: they change across reboots or sessions.
 
-So, we need to somehow map the paths of the cgroups to names, to provide consistent netdata configuration (i.e. there is no point to say `enable cgroup 1234 = yes | no`, if `1234` is a random number that changes over time - we need a name for the cgroup first, so that `enable cgroup NAME = yes | no` will be consistent).
+So, we need to somehow map the paths of the cgroups to names, to provide consistent Netdata configuration (i.e. there is no point to say `enable cgroup 1234 = yes | no`, if `1234` is a random number that changes over time - we need a name for the cgroup first, so that `enable cgroup NAME = yes | no` will be consistent).
 
-For this mapping netdata provides 2 configuration options:
+For this mapping Netdata provides 2 configuration options:
 
 ```
 [plugin:cgroups]
@@ -99,11 +99,11 @@ For this mapping netdata provides 2 configuration options:
 
 The whole point for the additional pattern list, is to limit the number of times the script will be called. Without this pattern list, the script might be called thousands of times, depending on the number of cgroups available in the system.
 
-The above pattern list is matched against the path of the cgroup. For matched cgroups, netdata calls the script [cgroup-name.sh](cgroup-name.sh.in) to get its name. This script queries `docker`, or applies heuristics to find give a name for the cgroup.
+The above pattern list is matched against the path of the cgroup. For matched cgroups, Netdata calls the script [cgroup-name.sh](cgroup-name.sh.in) to get its name. This script queries `docker`, or applies heuristics to find give a name for the cgroup.
 
 ### charts with zero metrics
 
-By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. For example:
+By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. For example:
 
 ```
 [plugin:cgroups]
@@ -118,7 +118,7 @@ CPU and memory limits are watched and used to rise alarms. Memory usage for ever
 
 ## Monitoring systemd services
 
-netdata monitors **systemd services**. Example:
+Netdata monitors **systemd services**. Example:
 
 ![image](https://cloud.githubusercontent.com/assets/2662304/21964372/20cd7b84-db53-11e6-98a2-b9c986b082c0.png)
 
@@ -175,7 +175,7 @@ sudo systemctl daemon-reexec
 
 (`systemctl daemon-reload` does not reload the configuration of the server - so you have to execute `systemctl daemon-reexec`).
 
-Now, when you run `systemd-cgtop`, services will start reporting usage (if it does not, restart a service - any service - to wake it up). Refresh your netdata dashboard, and you will have the charts too.
+Now, when you run `systemd-cgtop`, services will start reporting usage (if it does not, restart a service - any service - to wake it up). Refresh your Netdata dashboard, and you will have the charts too.
 
 In case memory accounting is missing, you will need to enable it at your kernel, by appending the following kernel boot options and rebooting:
 
@@ -185,7 +185,7 @@ cgroup_enable=memory swapaccount=1
 
 You can add the above, directly at the `linux` line in your `/boot/grub/grub.cfg` or appending them to the `GRUB_CMDLINE_LINUX` in `/etc/default/grub` (in which case you will have to run `update-grub` before rebooting). On DigitalOcean debian images you may have to set it at `/etc/default/grub.d/50-cloudimg-settings.cfg`.
 
-Which systemd services are monitored by netdata is determined by the following pattern list:
+Which systemd services are monitored by Netdata is determined by the following pattern list:
 
 ```
 [plugin:cgroups]
@@ -196,27 +196,27 @@ Which systemd services are monitored by netdata is determined by the following p
 
 ## Monitoring ephemeral containers
 
-netdata monitors containers automatically when it is installed at the host, or when it is installed in a container that has access to the `/proc` and `/sys` filesystems of the host.
+Netdata monitors containers automatically when it is installed at the host, or when it is installed in a container that has access to the `/proc` and `/sys` filesystems of the host.
 
-netdata prior to v1.6 had 2 issues when such containers were monitored:
+Netdata prior to v1.6 had 2 issues when such containers were monitored:
 
 1. network interface alarms where triggering when containers were stopped
 
 2. charts were never cleaned up, so after some time dozens of containers were showing up on the dashboard, and they were occupying memory.
 
 
-### the current netdata
+### the current Netdata
 
 network interfaces and cgroups (containers) are now self-cleaned.
 
-So, when a network interface or container stops, netdata might log a few errors in error.log complaining about files it cannot find, but immediately:
+So, when a network interface or container stops, Netdata might log a few errors in error.log complaining about files it cannot find, but immediately:
 
 1. it will detect this is a removed container or network interface
 2. it will freeze/pause all alarms for them
 3. it will mark their charts as obsolete
 4. obsolete charts are not be offered on new dashboard sessions (so hit F5 and the charts are gone)
 5. existing dashboard sessions will continue to see them, but of course they will not refresh
-6. obsolete charts will be removed from memory, 1 hour after the last user viewed them (configurable with `[global].cleanup obsolete charts after seconds = 3600` (at netdata.conf).
+6. obsolete charts will be removed from memory, 1 hour after the last user viewed them (configurable with `[global].cleanup obsolete charts after seconds = 3600` (at `netdata.conf`).
 7. when obsolete charts are removed from memory they are also deleted from disk (configurable with `[global].delete obsolete charts files = yes`)