| 1 | # Bandwidth Requirements |
| 2 | |
| 3 | ## Production Systems: Standalone Netdata |
| 4 | |
| 5 | Standalone Netdata may use network bandwidth under the following conditions: |
| 6 | |
| 7 | 1. You configured data collection jobs that are fetching data from remote systems. There are no such jobs enabled by default. |
| 8 | 2. You use the dashboard of the Netdata. |
| 9 | 3. [Netdata Cloud communication](#netdata-cloud-communication) (see below). |
| 10 | |
| 11 | ## Metrics Centralization Points: Between Netdata Children & Parents |
| 12 | |
| 13 | Netdata supports multiple compression algorithms for streaming communication. Netdata Children offer all their compression algorithms when connecting to a Netdata Parent, and the Netdata Parent decides which one to use based on algorithm availability and user configuration. |
| 14 | |
| 15 | | Algorithm | Best for | |
| 16 | |:---------:|:-----------------------------------------------------------------------------------------------------------------------------------:| |
| 17 | | `zstd` | The best balance between CPU utilization and compression efficiency. This is the default. | |
| 18 | | `lz4` | The fastest of the algorithms. Use this when CPU utilization is more important than bandwidth. | |
| 19 | | `gzip` | The best compression efficiency, at the expense of CPU utilization. Use this when bandwidth is more important than CPU utilization. | |
| 20 | | `brotli` | The most CPU intensive algorithm, providing the best compression. | |
| 21 | |
| 22 | The expected bandwidth consumption using `zstd` for 1 million samples per second is 84 Mbps, or 10.5 MiB/s. |
| 23 | |
| 24 | The order compression algorithms is selected is configured in `stream.conf`, per `[API KEY]`, like this: |
| 25 | |
| 26 | ```text |
| 27 | compression algorithms order = zstd lz4 brotli gzip |
| 28 | ``` |
| 29 | |
| 30 | The first available algorithm on both the Netdata Child and the Netdata Parent, from left to right, is chosen. |
| 31 | |
| 32 | Compression can also be disabled in `stream.conf` at either Netdata Children or Netdata Parents. |
| 33 | |
| 34 | ## Netdata Cloud Communication |
| 35 | |
| 36 | When Netdata Agents connect to Netdata Cloud, they communicate metadata of the metrics being collected, but they do not stream the samples collected for each metric. |
| 37 | |
| 38 | The information transferred to Netdata Cloud is: |
| 39 | |
| 40 | 1. Information and **metadata about the system itself**, like its hostname, architecture, virtualization technologies used and generally labels associated with the system. |
| 41 | 2. Information about the **running data collection plugins, modules and jobs**. |
| 42 | 3. Information about the **metrics available and their retention**. |
| 43 | 4. Information about the **configured alerts and their transitions**. |
| 44 | |
| 45 | This is not a constant stream of information. Netdata Agents update Netdata Cloud only about status changes on all the above (e.g., an alert being triggered, or a metric stopped being collected). So, there is an initial handshake and exchange of information when Netdata starts, and then there only updates when required. |
| 46 | |
| 47 | Of course, when you view Netdata Cloud dashboards that need to query the database a Netdata Agent maintains, this query is forwarded to an Agent that can satisfy it. This means that Netdata Cloud receives metric samples only when a user is accessing a dashboard and the samples transferred are usually aggregations to allow rendering the dashboards. |