Merging upstream version 1.46.3.

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

4 files changed, 495 insertions, 0 deletions

diff --git a/docs/deployment-guides/README.md b/docs/deployment-guides/README.md
new file mode 100644
index 000000000..1b6571b99
--- /dev/null
+++ b/docs/deployment-guides/README.md
@@ -0,0 +1,25 @@
+# Deployment Guides
+
+Netdata can be used to monitor all kinds of infrastructure, from tiny stand-alone IoT devices to complex hybrid setups combining on-premise and cloud infrastructure, mixing bare-metal servers, virtual machines and containers.
+
+There are 3 components to structure your Netdata ecosystem:
+
+1. **Netdata Agents**
+
+   To monitor the physical or virtual nodes of your infrastructure, including all applications and containers running on them.
+
+   Netdata Agents are Open-Source, licensed under GPL v3+.
+
+2. **Netdata Parents**
+
+   To create [observability centralization points](/docs/observability-centralization-points/README.md) within your infrastructure, to offload Netdata Agents functions from your production systems, to provide high-availability of your data, increased data retention and isolation of your nodes.
+
+   Netdata Parents are implemented using the Netdata Agent software. Any Netdata Agent can be an Agent for a node and a Parent  for other Agents, at the same time.
+
+   It is recommended to set up multiple Netdata Parents. They will all seamlessly be integrated by Netdata Cloud into one monitoring solution.
+
+3. **Netdata Cloud**
+
+   Our SaaS, combining all your infrastructure, all your Netdata Agents and Parents, into one uniform, distributed, scalable, monitoring database, offering advanced data slicing and dicing capabilities, custom dashboards, advanced troubleshooting tools, user management, centralized management of alerts, and more.
+
+The Netdata Agent is a highly modular software piece, providing data collection via numerous plugins, an in-house crafted time-series database, a query engine, health monitoring and alerts, machine learning and anomaly detection, metrics exporting to third party systems.
diff --git a/docs/deployment-guides/deployment-strategies.md b/docs/deployment-guides/deployment-strategies.md
new file mode 100644
index 000000000..abdb36cdf
--- /dev/null
+++ b/docs/deployment-guides/deployment-strategies.md
@@ -0,0 +1,207 @@
+# Deployment Examples
+
+## Deployment Options Overview
+
+This section provides a quick overview for a few common deployment options for Netdata.
+
+You can read about [Standalone Deployment](/docs/deployment-guides/standalone-deployment.md) and [Deployment with Centralization Points](/docs/deployment-guides/deployment-with-centralization-points.md) in the documentation inside this section.
+
+The sections below go into configuration examples about these deployment concepts.
+
+## Deployment Configuration Details
+
+### Stand-alone
+
+The stand-alone setup is configured out of the box with reasonable defaults, but please consult our [configuration documentation](/docs/netdata-agent/configuration/README.md) for details, including the overview of [common configuration changes](/docs/netdata-agent/configuration/common-configuration-changes.md).
+
+### Parent – Child
+
+For setups involving Parent and Child Agents, they need to be configured for [streaming](docs/observability-centralization-points/metrics-centralization-points/configuration.md), through the configuration file `stream.conf`.
+
+This will instruct the Child to stream data to the Parent and the Parent to accept streaming connections for one or more Child Agents. To secure this connection, both need a shared API key (to replace the string `API_KEY` in the examples below). Additionally, the Child can be configured with one or more addresses of Parent Agents (`PARENT_IP_ADDRESS`).
+
+An API key is a key created with `uuidgen` and is used for authentication and/or customization on the Parent side. For example, a Child can stream using the API key, and a Parent can be configured to accept connections from the Child, but it can also apply different options for Children by using multiple different API keys. The easiest setup uses just one API key for all Child Agents.
+
+#### Child config
+
+As mentioned above, we do not recommend to claim the Child to Cloud directly during your setup.
+
+This is done in order to reduce the footprint of the Netdata Agent on your production system, as some capabilities can be switched OFF for the Child and kept ON for the Parent.
+
+In this example, Machine Learning and Alerting are disabled for the Child, so that the Parent can take the load. We also use RAM instead of disk to store metrics with limited retention, covering temporary network issues.
+
+##### netdata.conf
+
+On the child node, edit `netdata.conf` by using the [edit-config](docs/netdata-agent/configuration/README.md#edit-netdataconf) script and set the following parameters:
+
+```yaml
+[db]
+    # https://github.com/netdata/netdata/blob/master/src/database/README.md
+    # none = no retention, ram = some retention in ram
+    mode = ram
+    # The retention in seconds.
+    # This provides some tolerance to the time the child has to find a parent in
+    # order to transfer the data. For IoT this can be lowered to 120.
+    retention = 1200
+    # The granularity of metrics, in seconds.
+    # You may increase this to lower CPU resources.
+    update every = 1
+[ml]
+    # Disable Machine Learning
+    enabled = no
+[health]
+    # Disable Health Checks (Alerting)
+    enabled = no
+[web]
+    # Disable remote access to the local dashboard
+    bind to = lo
+[plugins]
+    # Uncomment the following line to disable all external plugins on extreme
+    # IoT cases by default.
+    # enable running new plugins = no
+```
+
+##### stream.conf
+
+To edit `stream.conf`, use again the [edit-config](docs/netdata-agent/configuration/README.md#edit-netdataconf) script and set the following parameters:
+
+```yaml
+[stream]
+    # Stream metrics to another Netdata
+    enabled = yes
+    # The IP and PORT of the parent
+    destination = PARENT_IP_ADDRESS:19999
+    # The shared API key, generated by uuidgen
+    api key = API_KEY
+```
+
+#### Parent config
+
+For the Parent, besides setting up streaming, this example also provides configuration for multiple [tiers of metrics storage](/docs/netdata-agent/configuration/optimizing-metrics-database/change-metrics-storage.md#calculate-the-system-resources-ram-disk-space-needed-to-store-metrics), for 10 Children, with about 2k metrics each. This allows for:
+
+- 1s granularity at tier 0 for 1 week
+- 1m granularity at tier 1 for 1 month
+- 1h granularity at tier 2 for 1 year
+
+Requiring:
+
+- 25GB of disk
+- 3.5GB of RAM (2.5GB under pressure)
+
+##### netdata.conf
+
+On the Parent, edit `netdata.conf` by using the [edit-config](docs/netdata-agent/configuration/README.md#edit-netdataconf) script and set the following parameters:
+
+```yaml
+[db]
+    mode = dbengine
+    storage tiers = 3
+    # To allow memory pressure to offload index from ram
+    dbengine page descriptors in file mapped memory = yes
+    # storage tier 0
+    update every = 1
+    dbengine multihost disk space MB = 12000
+    dbengine page cache size MB = 1400
+    # storage tier 1
+    dbengine tier 1 page cache size MB = 512
+    dbengine tier 1 multihost disk space MB = 4096
+    dbengine tier 1 update every iterations = 60
+    dbengine tier 1 backfill = new
+    # storage tier 2
+    dbengine tier 2 page cache size MB = 128
+    dbengine tier 2 multihost disk space MB = 2048
+    dbengine tier 2 update every iterations = 60
+    dbengine tier 2 backfill = new
+[ml]
+    # Enabled by default
+    # enabled = yes
+[health]
+    # Enabled by default
+    # enabled = yes
+[web]
+    # Enabled by default
+    # bind to = *
+```
+
+##### stream.conf
+
+On the Parent node, edit `stream.conf` by using the [edit-config](docs/netdata-agent/configuration/README.md#edit-netdataconf) script and set the following parameters:
+
+```yaml
+[API_KEY]
+    # Accept metrics streaming from other Agents with the specified API key
+    enabled = yes
+```
+
+### Active–Active Parents
+
+In order to setup active–active streaming between Parent 1 and Parent 2, Parent 1 needs to be instructed to stream data to Parent 2 and Parent 2 to stream data to Parent 1. The Child Agents need to be configured with the addresses of both Parent Agents. An Agent will only connect to one Parent at a time, falling back to the next upon failure. These examples use the same API key between Parent Agents and for connections for Child Agents.
+
+On both Netdata Parent and all Child Agents, edit `stream.conf` by using the [edit-config](docs/netdata-agent/configuration/README.md#edit-netdataconf) script:
+
+#### stream.conf on Parent 1
+
+```yaml
+[stream]
+    # Stream metrics to another Netdata
+    enabled = yes
+    # The IP and PORT of Parent 2
+    destination = PARENT_2_IP_ADDRESS:19999
+    # This is the API key for the outgoing connection to Parent 2
+    api key = API_KEY
+[API_KEY]
+    # Accept metrics streams from Parent 2 and Child Agents
+    enabled = yes
+```
+
+#### stream.conf on Parent 2
+
+```yaml
+[stream]
+    # Stream metrics to another Netdata
+    enabled = yes
+    # The IP and PORT of Parent 1
+    destination = PARENT_1_IP_ADDRESS:19999
+    api key = API_KEY
+[API_KEY]
+    # Accept metrics streams from Parent 1 and Child Agents
+    enabled = yes
+```
+
+#### stream.conf on Child Agents
+
+```yaml
+[stream]
+    # Stream metrics to another Netdata
+    enabled = yes
+    # The IP and PORT of the parent
+    destination = PARENT_1_IP_ADDRESS:19999 PARENT_2_IP_ADDRESS:19999
+    # The shared API key, generated by uuidgen
+    api key = API_KEY
+```
+
+## Further Reading
+
+We strongly recommend the following configuration changes for production deployments:
+
+1. Understand Netdata's [security and privacy design](/docs/security-and-privacy-design/README.md) and [secure your nodes](/docs/netdata-agent/securing-netdata-agents.md)
+
+   To safeguard your infrastructure and comply with your organization's security policies.
+
+2. [Optimize the Netdata Agents system utilization and performance](/docs/netdata-agent/configuration/optimize-the-netdata-agents-performance.md)
+
+   To save valuable system resources, especially when running on weak IoT devices.
+
+We also suggest that you:
+
+1. [Use Netdata Cloud to access the dashboards](/docs/netdata-cloud/README.md)
+
+   For increased security, user management and access to our latest features, tools and troubleshooting solutions.
+
+2. [Change how long Netdata stores metrics](/docs/netdata-agent/configuration/optimizing-metrics-database/change-metrics-storage.md)
+
+   To control Netdata's memory use, when you have a lot of ephemeral metrics.
+
+3. [Use host labels](/docs/netdata-agent/configuration/organize-systems-metrics-and-alerts.md)
+
+   To organize systems, metrics, and alerts.
diff --git a/docs/deployment-guides/deployment-with-centralization-points.md b/docs/deployment-guides/deployment-with-centralization-points.md
new file mode 100644
index 000000000..87fd4a61a
--- /dev/null
+++ b/docs/deployment-guides/deployment-with-centralization-points.md
@@ -0,0 +1,122 @@
+# Deployment with Centralization Points
+
+An observability centralization point can centralize both metrics and logs. The sending systems are called Children, while the receiving systems are called a Parents.
+
+When metrics and logs are centralized, the Children are never queried for metrics and logs. The Netdata Parents have all the data needed to satisfy queries.
+
+- **Metrics** are centralized by Netdata, with a feature we call **Streaming**. The Parents listen for incoming connections and permit access only to Children that connect to it with the right API key. Children are configured to push their metrics to the Parents and they initiate the connections to do so.
+
+- **Logs** are centralized with methodologies provided by `systemd-journald`. This involves installing `systemd-journal-remote` on both the Parent and the Children, and configuring the keys required for this communication.
+
+|                    Feature                    |                                                 How it works                                                  |
+|:---------------------------------------------:|:-------------------------------------------------------------------------------------------------------------:|
+| Unified infrastructure dashboards for metrics |                                             Yes, at Netdata Cloud                                             |
+|  Unified infrastructure dashboards for logs   | All logs are accessible via the same dashboard at Netdata Cloud, although they are unified per Netdata Parent |
+|          Centrally configured alerts          |                                            Yes, at Netdata Parents                                            |
+|   Centrally dispatched alert notifications    |                                             Yes, at Netdata Cloud                                             |
+|         Data are exclusively on-prem          |                    Yes, Netdata Cloud queries Netdata Agents to satisfy dashboard queries.                    |
+
+A configuration with 2 observability centralization points, looks like this:
+
+```mermaid
+flowchart LR
+    WEB[["One unified
+        dashboard
+        for all nodes"]]
+    NC(["<b>Netdata Cloud</b>
+        decides which Agents
+        need to be queried"])
+    SA1["Netdata at AWS
+         A1"]
+    SA2["Netdata at AWS
+         A2"]
+    SAN["Netdata at AWS
+         AN"]
+    PA["<b>Netdata Parent A</b>
+        at AWS
+        having all metrics & logs
+        for all Ax nodes"]
+    SB1["Netdata On-Prem
+         B1"]
+    SB2["Netdata On-Prem
+         B2"]
+    SBN["Netdata On-Prem
+         BN"]
+    PB["<b>Netdata Parent B</b>
+        On-Prem
+        having all metrics & logs
+        for all Bx nodes"]
+    WEB -->|query| NC -->|query| PA & PB
+    PA ---|stream| SA1 & SA2 & SAN
+    PB ---|stream| SB1 & SB2 & SBN 
+```
+
+Netdata Cloud queries the Netdata Parents to provide aggregated dashboard views.
+
+For alerts, the dispatch of notifications looks like in the following chart:
+
+```mermaid
+flowchart LR
+    NC(["<b>Netdata Cloud</b>
+        applies silencing
+        & user settings"])
+    SA1["Netdata at AWS
+         A1"]
+    SA2["Netdata at AWS
+         A2"]
+    SAN["Netdata at AWS
+         AN"]
+    PA["<b>Netdata Parent A</b>
+        at AWS
+        having all metrics & logs
+        for all Ax nodes"]
+    SB1["Netdata On-Prem
+         B1"]
+    SB2["Netdata On-Prem
+         B2"]
+    SBN["Netdata On-Prem
+         BN"]
+    PB["<b>Netdata Parent B</b>
+        On-Prem
+        having all metrics & logs
+        for all Bx nodes"]
+    EMAIL{{"<b>e-mail</b>
+        notifications"}}
+    MOBILEAPP{{"<b>Netdata Mobile App</b>
+        notifications"}}
+    SLACK{{"<b>Slack</b>
+        notifications"}}
+    OTHER{{"Other
+        notifications"}}
+    PA & PB -->|alert transitions| NC -->|notification| EMAIL & MOBILEAPP & SLACK & OTHER 
+    SA1 & SA2 & SAN ---|stream| PA
+    SB1 & SB2 & SBN ---|stream| PB 
+```
+
+## Active–Active Parent Deployment
+
+For high availability, Parents can be configured to stream data for their Children between them, and keep their data sets in sync. Children are configured with the addresses of both Parents, but will only stream to one of them at a time. When one Parent becomes unavailable, the Child reconnects to the other. When the first Parent becomes available again, that Parent will catch up by receiving the backlog from the second.
+
+With both Parent Agents connected to Netdata Cloud, it will route queries to either of them transparently, depending on their availability. Alerts trigger on either Parent will stream to Cloud, and Cloud will deduplicate and debounce state changes to prevent spurious notifications.
+
+## Configuration steps for deploying Netdata with Observability Centralization Points
+
+For Metrics:
+
+- Install Netdata Agents on all systems and the Netdata Parents.
+
+- Configure `stream.conf` at the Netdata Parents to enable streaming access with an API key.
+
+- Configure `stream.conf` at the Netdata Children to enable streaming to the configured Netdata Parents.
+
+Check the [related section in our documentation](/docs/observability-centralization-points/metrics-centralization-points/README.md) for more info
+
+For Logs:
+
+- Install `systemd-journal-remote` on all systems and the Netdata Parents.
+
+- Configure `systemd-journal-remote` at the Netdata Parents to enable logs reception.
+
+- Configure `systemd-journal-upload` at the Netdata Children to enable transmission of their logs to the Netdata Parents.
+
+Check the [related section in our documentation](/docs/observability-centralization-points/logs-centralization-points-with-systemd-journald/README.md) for more info
diff --git a/docs/deployment-guides/standalone-deployment.md b/docs/deployment-guides/standalone-deployment.md
new file mode 100644
index 000000000..3138141f7
--- /dev/null
+++ b/docs/deployment-guides/standalone-deployment.md
@@ -0,0 +1,141 @@
+# Standalone Deployment
+
+To help our users have a complete experience of Netdata when they install it for the first time, the Netdata Agent with default configuration is a complete monitoring solution out of the box, with features enabled and available.
+
+So, each Netdata Agent acts as a standalone monitoring system by default.
+
+## Standalone Agents, without Netdata Cloud
+
+|                    Feature                    |                     How it works                     |
+|:---------------------------------------------:|:----------------------------------------------------:|
+| Unified infrastructure dashboards for metrics |  No, each Netdata Agent provides its own dashboard   |
+|  Unified infrastructure dashboards for logs   |     No, each Netdata Agent exposes its own logs      |
+|          Centrally configured alerts          |  No, each Netdata has its own alerts configuration   |
+|   Centrally dispatched alert notifications    | No, each Netdata Agent sends notifications by itself |
+|         Data are exclusively on-prem          |                         Yes                          |
+
+When using Standalone Netdata Agents, each of them offers an API and a dashboard, at its own unique URL, that looks like `http://agent-ip:19999`.
+
+So, each of the Netdata Agents has to be accessed individually and independently of the others:
+
+```mermaid
+flowchart LR
+    WEB[["Multiple
+        Independent
+        Dashboards"]]
+    S1["Standalone
+        Netdata
+         1"]
+    S2["Standalone
+        Netdata
+         2"]
+    SN["Standalone
+        Netdata
+         N"]
+    WEB -->|URL 1| S1
+    WEB -->|URL 2| S2
+    WEB -->|URL N| SN
+```
+
+The same is true for alert notifications. Each of the Netdata Agents runs its own alerts and sends notifications by itself, according to its configuration:
+
+```mermaid
+flowchart LR
+    S1["Standalone
+        Netdata
+         1"]
+    S2["Standalone
+        Netdata
+         2"]
+    SN["Standalone
+        Netdata
+         N"]
+    EMAIL{{"<b>e-mail</b>
+        notifications"}}
+    SLACK{{"<b>Slack</b>
+        notifications"}}
+    OTHER{{"Other
+        notifications"}}
+    S1 & S2 & SN .-> SLACK
+    S1 & S2 & SN ---> EMAIL
+    S1 & S2 & SN ==> OTHER
+```
+
+### Configuration steps for standalone Netdata Agents without Netdata Cloud
+
+No special configuration needed.
+
+- Install Netdata Agents on all your systems, then access each of them via its own unique URL, that looks like `http://agent-ip:19999/`.
+
+## Standalone Agents, with Netdata Cloud
+
+|                    Feature                    |                                                                              How it works                                                                               |
+|:---------------------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
+| Unified infrastructure dashboards for metrics |                                                 Yes, via Netdata Cloud, all charts aggregate metrics from all servers.                                                  |
+|  Unified infrastructure dashboards for logs   | All logs are accessible via the same dashboard at Netdata Cloud, although they are not unified (ie. logs from different servers are not multiplexed into a single view) |
+|          Centrally configured alerts          |                                                            No, each Netdata has its own alerts configuration                                                            |
+|   Centrally dispatched alert notifications    |                                                                         Yes, via Netdata Cloud                                                                          |
+|         Data are exclusively on-prem          |                                                 Yes, Netdata Cloud queries Netdata Agents to satisfy dashboard queries.                                                 |
+
+By [connecting all Netdata Agents to Netdata Cloud](/src/claim/README.md), you can have a unified infrastructure view of all your nodes, with aggregated charts, without configuring [observability centralization points](/docs/observability-centralization-points/README.md).
+
+```mermaid
+flowchart LR
+    WEB[["One unified
+        dashboard
+        for all nodes"]]
+    NC(["<b>Netdata Cloud</b>
+        decides which Agents
+        need to be queried"])
+    S1["Standalone
+        Netdata
+         1"]
+    S2["Standalone
+        Netdata
+         2"]
+    SN["Standalone
+        Netdata
+         N"]
+    WEB -->|queries| NC
+    NC -->|queries| S1 & S2 & SN
+```
+
+Similarly for alerts, Netdata Cloud receives all alert transitions from all Agents, decides which notifications should be sent and how, applies silencing rules, maintenance windows and based on each Netdata Cloud space and user settings, dispatches notifications:
+
+```mermaid
+flowchart LR
+    EMAIL{{"<b>e-mail</b>
+        notifications"}}
+    MOBILEAPP{{"<b>Netdata Mobile App</b>
+        notifications"}}
+    SLACK{{"<b>Slack</b>
+        notifications"}}
+    OTHER{{"Other
+        notifications"}}
+    NC(["<b>Netdata Cloud</b>
+        applies silencing
+        & user settings"])
+    S1["Standalone
+        Netdata
+         1"]
+    S2["Standalone
+        Netdata
+         2"]
+    SN["Standalone
+        Netdata
+         N"]
+    NC -->|notification| EMAIL & MOBILEAPP & SLACK & OTHER
+    S1 & S2 & SN -->|alert transition| NC
+```
+
+> **Note**
+>
+> Alerts are still triggered by Netdata Agents. Netdata Cloud only takes care of the notifications.
+
+### Configuration steps for standalone Netdata Agents with Netdata Cloud
+
+- Install Netdata Agents using the commands given by Netdata Cloud, so that they will be automatically connected to your Netdata Cloud space. Otherwise, install Netdata Agents and then claim them via the command line or their dashboard.
+
+- Optionally: disable their direct dashboard access to secure them.
+
+- Optionally: disable their alert notifications to avoid receiving email notifications directly from them (email notifications are automatically enabled when a working MTA is found on the systems Netdata Agents are installed).