Adding upstream version 1.37.0.upstream/1.37.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

8 files changed, 66 insertions, 26 deletions

diff --git a/docs/guides/configure/performance.md b/docs/guides/configure/performance.md
index f83634168..cb52a1141 100644
--- a/docs/guides/configure/performance.md
+++ b/docs/guides/configure/performance.md
@@ -8,8 +8,9 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/conf
 # How to optimize the Netdata Agent's performance
 
 We designed the Netdata Agent to be incredibly lightweight, even when it's collecting a few thousand dimensions every
-second and visualizing that data into hundreds of charts. The Agent itself should never use more than 1% of a single CPU
-core, roughly 100 MiB of RAM, and minimal disk I/O to collect, store, and visualize all this data.
+second and visualizing that data into hundreds of charts. When properly configured for a production node, the Agent 
+itself should never use more than 1% of a single CPU core, roughly 50-100 MiB of RAM, and minimal disk I/O to collect, 
+store, and visualize all this data.
   
 We take this scalability seriously. We have one user [running
 Netdata](https://github.com/netdata/netdata/issues/1323#issuecomment-266427841) on a system with 144 cores and 288
@@ -21,6 +22,11 @@ only 512 MiB of RAM, or an IoT device like a [Raspberry Pi](/docs/guides/monitor
 cases, reducing Netdata's footprint beyond its already diminutive size can pay big dividends, giving your services more
 horsepower while still monitoring the health and the performance of the node, OS, hardware, and applications.
 
+The default settings of the Netdata Agent are not optimized for performance, but for a simple standalone setup. We want 
+the first install to give you something you can run without any configuration. Most of the settings and options are 
+enabled, since we want you to experience the full thing.
+
+
 ## Prerequisites
 
 -   A node running the Netdata Agent.
@@ -146,18 +152,39 @@ calculator](/docs/store/change-metrics-storage.md#calculate-the-system-resources
 All the settings are found in the `[global]` section of `netdata.conf`:
 
 ```conf
-[global]
+[db]
     memory mode = dbengine
     page cache size = 32
     dbengine multihost disk space = 256
 ```
 
+To save even more memory, you can disable the dbengine and reduce retention to just 30 minutes, as shown below:
+
+```conf
+[db]
+   storage tiers = 1
+   mode = alloc
+   retention = 1800
+```
+
 Metric retention is not important in certain use cases, such as:
  - Data collection nodes stream collected metrics collected to a centralization point.
  - Data collection nodes export their metrics to another time series DB, or are scraped by Prometheus
  - Netdata installed only during incidents, to get richer information.
-In such cases, you may not want to use the dbengine at all and instead opt for memory mode `memory mode = ram` or `memory mode = none`.
+In such cases, you may not want to use the dbengine at all and instead opt for memory mode 
+`memory mode = alloc` or `memory mode = none`.
+
+## Disable machine learning
+
+Automated anomaly detection may be a powerful tool, but we recommend it to only be enabled on Netdata parents 
+that sit outside your production infrastructure, or if you have cpu and memory to spare. You can disable ML 
+with the following:
 
+```conf
+[ml]
+   enabled = no
+```
+   
 ## Run Netdata behind Nginx
 
 A dedicated web server like Nginx provides far more robustness than the Agent's internal [web server](/web/README.md).
@@ -220,6 +247,19 @@ If you installation is working correctly, and you're not actively auditing Netda
     access log = none
 ```
 
+## Disable health checks
+
+If you are streaming metrics to parent nodes, we recommend you run your health checks on the parent, for all the metrics collected 
+by the children nodes. This saves resources on the children and makes it easier to configure or disable alerts and agent notifications.
+
+The parents by default run health checks for each child, as long as it is connected (the details are in `stream.conf`). 
+On the child nodes you should add to `netdata.conf` the following:
+
+```conf
+[health]
+   enabled = no
+```
+
 ## What's next?
 
 We hope this guide helped you better understand how to optimize the performance of the Netdata Agent.
diff --git a/docs/guides/export/export-netdata-metrics-graphite.md b/docs/guides/export/export-netdata-metrics-graphite.md
index 007c30f8b..dd742e454 100644
--- a/docs/guides/export/export-netdata-metrics-graphite.md
+++ b/docs/guides/export/export-netdata-metrics-graphite.md
@@ -3,7 +3,7 @@ title: Export and visualize Netdata metrics in Graphite
 description: "Use Netdata to collect and export thousands of metrics to Graphite for long-term storage or further analysis."
 image: /img/seo/guides/export/export-netdata-metrics-graphite.png
 -->
-import { OneLineInstallWget } from '../../src/components/OneLineInstall/'
+import { OneLineInstallWget } from '@site/src/components/OneLineInstall/'
 
 # Export and visualize Netdata metrics in Graphite
 
diff --git a/docs/guides/monitor/lamp-stack.md b/docs/guides/monitor/lamp-stack.md
index 595d64400..29b35e142 100644
--- a/docs/guides/monitor/lamp-stack.md
+++ b/docs/guides/monitor/lamp-stack.md
@@ -7,7 +7,7 @@ author_title: "Editorial Director, Technical & Educational Resources"
 author_img: "/img/authors/joel-hans.jpg"
 custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/monitor/lamp-stack.md
 -->
-import { OneLineInstallWget } from '../../src/components/OneLineInstall/'
+import { OneLineInstallWget } from '@site/src/components/OneLineInstall/'
 
 # LAMP stack monitoring (Linux, Apache, MySQL, PHP) with Netdata
 
diff --git a/docs/guides/monitor/pi-hole-raspberry-pi.md b/docs/guides/monitor/pi-hole-raspberry-pi.md
index 721ba2a8f..1246d8ba1 100644
--- a/docs/guides/monitor/pi-hole-raspberry-pi.md
+++ b/docs/guides/monitor/pi-hole-raspberry-pi.md
@@ -4,7 +4,7 @@ description: "Monitor Pi-hole metrics, plus Raspberry Pi system metrics, in minu
 image: /img/seo/guides/monitor/netdata-pi-hole-raspberry-pi.png
 custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/monitor/pi-hole-raspberry-pi.md
 -->
-import { OneLineInstallWget } from '../../src/components/OneLineInstall/'
+import { OneLineInstallWget } from '@site/src/components/OneLineInstall/'
 
 # Monitor Pi-hole (and a Raspberry Pi) with Netdata
 
diff --git a/docs/guides/python-collector.md b/docs/guides/python-collector.md
index f93c724bf..920b9b9ef 100644
--- a/docs/guides/python-collector.md
+++ b/docs/guides/python-collector.md
@@ -424,8 +424,8 @@ configuration in [YAML](https://www.tutorialspoint.com/yaml/yaml_basics.htm) for
   run. This enables you to define different "ways" to fetch data from a particular data source so that the collector has
   more chances to work out-of-the-box. For example, if the data source supports both `HTTP` and `linux socket`, you can
   define 2 jobs named `local`, with each using a different method. 
-- Check the `postgresql` collector configuration file on
-  [GitHub](https://github.com/netdata/netdata/blob/master/collectors/python.d.plugin/postgres/postgres.conf) to get a
+- Check the `example` collector configuration file on
+  [GitHub](https://github.com/netdata/netdata/blob/master/collectors/python.d.plugin/example/example.conf) to get a
   sense of the structure.
 
 ```yaml
@@ -455,8 +455,8 @@ function takes 2 arguments, one with the name of the configuration field and one
 find the configuration field. This allows you to define sane defaults for your collector.
 
 Moreover, when creating the configuration file, create a large comment section that describes the configuration
-variables and inform the user about the defaults. For example, take a look at the `postgresql` collector on
-[GitHub](https://github.com/netdata/netdata/blob/master/collectors/python.d.plugin/postgres/postgres.conf).
+variables and inform the user about the defaults. For example, take a look at the `example` collector on
+[GitHub](https://github.com/netdata/netdata/blob/master/collectors/python.d.plugin/example/example.conf).
 
 You can read more about the configuration file on the [`python.d.plugin`
 documentation](https://learn.netdata.cloud/docs/agent/collectors/python.d.plugin). 
@@ -465,7 +465,7 @@ documentation](https://learn.netdata.cloud/docs/agent/collectors/python.d.plugin
 
 Find the source code for the above examples on [GitHub](https://github.com/papajohn-uop/netdata). 
 
-Now we you ready to start developing our Netdata python Collector and share it with the rest of the Netdata community.
+Now you are ready to start developing our Netdata python Collector and share it with the rest of the Netdata community.
 
 - If you need help while developing your collector, join our [Netdata
   Community](https://community.netdata.cloud/c/agent-development/9) to chat about it.
diff --git a/docs/guides/step-by-step/step-00.md b/docs/guides/step-by-step/step-00.md
index ab68fe741..9f0fecac8 100644
--- a/docs/guides/step-by-step/step-00.md
+++ b/docs/guides/step-by-step/step-00.md
@@ -3,7 +3,7 @@ title: "The step-by-step Netdata guide"
 date: 2020-03-31
 custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/step-by-step/step-00.md
 -->
-import { OneLineInstallWget, OneLineInstallCurl } from '../../src/components/OneLineInstall/'
+import { OneLineInstallWget, OneLineInstallCurl } from '@site/src/components/OneLineInstall/'
 
 # The step-by-step Netdata guide
 
diff --git a/docs/guides/step-by-step/step-09.md b/docs/guides/step-by-step/step-09.md
index 6333dfe69..8aacd7514 100644
--- a/docs/guides/step-by-step/step-09.md
+++ b/docs/guides/step-by-step/step-09.md
@@ -36,10 +36,10 @@ guide, your Netdata agent is already using the database engine.
 Let's look at your `netdata.conf` file again. Under the `[global]` section, you'll find three connected options.
 
 ```conf
-[global]
-    # memory mode = dbengine
-    # page cache size = 32
-    # dbengine disk space = 256
+[db]
+    # mode = dbengine
+    # dbengine page cache size MB = 32
+    # dbengine disk space MB = 256
 ```
 
 The `memory mode` option is set, by default, to `dbengine`. `page cache size` determines the amount of RAM, in MiB, that
@@ -56,10 +56,10 @@ space` based on your needs. The calculator gives an accurate estimate based on h
 metrics your Agent collects, and more.
 
 ```conf
-[global]
-    memory mode = dbengine
-    page cache size = 64
-    dbengine disk space = 512
+[db]
+    mode = dbengine
+    dbengine page cache size MB = 64
+    dbengine disk space MB = 512
 ```
 
 After you've made your changes, restart Netdata using `sudo systemctl restart netdata`, or the [appropriate
diff --git a/docs/guides/troubleshoot/troubleshooting-agent-with-cloud-connection.md b/docs/guides/troubleshoot/troubleshooting-agent-with-cloud-connection.md
index ee214c814..3bb5ace66 100644
--- a/docs/guides/troubleshoot/troubleshooting-agent-with-cloud-connection.md
+++ b/docs/guides/troubleshoot/troubleshooting-agent-with-cloud-connection.md
@@ -65,7 +65,7 @@ With the introduction of our new architecture, Agents running versions lower tha
 
 ### Verify that your IP is whitelisted from Netdata Cloud
 
-Most of the nodes change IPs dynamically. It is possible that your current IP has been restricted from accessing `app.netdata.cloud` due to security concerns.
+Most of the nodes change IPs dynamically. It is possible that your current IP has been restricted from accessing `api.netdata.cloud` due to security concerns.
 
 To verify this:
 
@@ -75,7 +75,7 @@ To verify this:
     sudo netdatacli aclk-state | grep "Banned By Cloud"
     ```
 
-    The output will contain a line indicating if the IP is banned from `app.netdata.cloud`:
+    The output will contain a line indicating if the IP is banned from `api.netdata.cloud`:
 
     ```bash
     Banned By Cloud: yes
@@ -97,13 +97,13 @@ To verify this:
 2. If you can reach external IPs, then check your domain resolution.
 
     ```bash
-    host app.netdata.cloud
+    host api.netdata.cloud
     ```
 
     The expected output should be something like this:
 
     ```bash
-    app.netdata.cloud is an alias for main-ingress-545609a41fcaf5d6.elb.us-east-1.amazonaws.com.
+    api.netdata.cloud is an alias for main-ingress-545609a41fcaf5d6.elb.us-east-1.amazonaws.com.
     main-ingress-545609a41fcaf5d6.elb.us-east-1.amazonaws.com has address 54.198.178.11
     main-ingress-545609a41fcaf5d6.elb.us-east-1.amazonaws.com has address 44.207.131.212
     main-ingress-545609a41fcaf5d6.elb.us-east-1.amazonaws.com has address 44.196.50.41
@@ -111,7 +111,7 @@ To verify this:
 
     :::info
 
-    There will be cases in which the firewall restricts network access. In those cases, you need to whitelist the `app.netdata.cloud` domain to be able to see your nodes in Netdata Cloud.  
+    There will be cases in which the firewall restricts network access. In those cases, you need to whitelist `api.netdata.cloud` and `mqtt.netdata.cloud` domains to be able to see your nodes in Netdata Cloud.  
     If you can't whitelist domains in your firewall, you can whitelist the IPs that the above command will produce, but keep in mind that they can change without any notice.
 
     :::