summaryrefslogtreecommitdiffstats
path: root/streaming/README.md
diff options
context:
space:
mode:
authorChris Akritidis <43294513+cakrit@users.noreply.github.com>2023-02-27 14:46:08 -0800
committerGitHub <noreply@github.com>2023-02-27 14:46:08 -0800
commit8c73c47645165d8eb65e06e1b50b27e82fe13bab (patch)
treed72c17664378bcd5a1e37c31c806d347848be571 /streaming/README.md
parent9fabe2340f6af2d0f51c2344e6b91cac7bb03f44 (diff)
Reorg learn 0227 (#14621)
* reorg batch 1 * remove duplicate cloud custom dashboard and agent dashboard * Simplify the root web/README * Merge streaming references * Make enable streaming the overall intro and the README the reference * Remove reference-streaming document * Update overview pages
Diffstat (limited to 'streaming/README.md')
-rw-r--r--streaming/README.md640
1 files changed, 246 insertions, 394 deletions
diff --git a/streaming/README.md b/streaming/README.md
index 965c95dd33..bf11f32e47 100644
--- a/streaming/README.md
+++ b/streaming/README.md
@@ -1,145 +1,160 @@
# Streaming and replication reference
-Each Netdata node is able to replicate/mirror its database to another Netdata node, by streaming the collected
-metrics in real-time. This is quite different to
-[data archiving to third party time-series databases](https://github.com/netdata/netdata/blob/master/exporting/README.md).
-The nodes that send metrics are called **child** nodes, and the nodes that receive metrics are called **parent** nodes.
-
-There are also **proxy** nodes, which collect metrics from a child and sends it to a parent.
-
-When one Netdata node streams metrics another, the receiving instance can use the data for all features of a typical Netdata node, for example:
-
-- Visualize metrics with a dashboard
-- Run health checks that trigger alarms and send alarm notifications
-- Export metrics to an external time-series database
-
This document contains advanced streaming options and suggested deployment options for production.
If you haven't already done so, we suggest you first go through the
[quick introduction to streaming](https://github.com/netdata/netdata/blob/master/docs/metrics-storage-management/enable-streaming.md)
, for your first, basic parent child setup.
-## Supported configurations
-
-### Netdata without a database or web API (headless collector)
+## Configuration
-A local Netdata Agent (child), **without any database or alarms**, collects metrics and sends them to another Netdata node
-(parent).
-The same parent can collect data for any number of child nodes and serves alerts for each child.
+There are two files responsible for configuring Netdata's streaming capabilities: `stream.conf` and `netdata.conf`.
-The node menu shows a list of all "databases streamed to" the parent. Clicking one of those links allows the user to
-view the full dashboard of the child node. The URL has the form
-`http://parent-host:parent-port/host/child-host/`.
+From within your Netdata config directory (typically `/etc/netdata`), [use `edit-config`](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md) to
+open either `stream.conf` or `netdata.conf`.
+```
+sudo ./edit-config stream.conf
+sudo ./edit-config netdata.conf
+```
-In a headless setup, the child acts as a plain data collector. It spawns all external plugins, but instead of maintaining a
-local database and accepting dashboard requests, it streams all metrics to the parent.
+### `stream.conf`
-This setup works great to reduce the memory footprint. Depending on the enabled plugins, memory usage is between 6 MiB and 40 MiB. To reduce the memory usage as much as
-possible, refer to the [performance optimization guide](https://github.com/netdata/netdata/blob/master/docs/guides/configure/performance.md).
+The `stream.conf` file contains three sections. The `[stream]` section is for configuring child nodes.
+The `[API_KEY]` and `[MACHINE_GUID]` sections are both for configuring parent nodes, and share the same settings.
+`[API_KEY]` settings affect every child node using that key, whereas `[MACHINE_GUID]` settings affect only the child
+node with a matching GUID.
-### Database Replication
+The file `/var/lib/netdata/registry/netdata.public.unique.id` contains a random GUID that **uniquely identifies each
+node**. This file is automatically generated by Netdata the first time it is started and remains unaltered forever.
-The local Netdata Agent (child), **with a local database (and possibly alarms)**, collects metrics and
-sends them to another Netdata node (parent).
+#### `[stream]` section
-The user can use all the functions **at both** `http://child-ip:child-port/` and
-`http://parent-host:parent-port/host/child-host/`.
+| Setting | Default | Description |
+| :---------------------------------------------- | :------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `enabled` | `no` | Whether this node streams metrics to any parent. Change to `yes` to enable streaming. |
+| [`destination`](#destination) | ` ` | A space-separated list of parent nodes to attempt to stream to, with the first available parent receiving metrics, using the following format: `[PROTOCOL:]HOST[%INTERFACE][:PORT][:SSL]`. [Read more &rarr;](#destination) |
+| `ssl skip certificate verification` | `yes` | If you want to accept self-signed or expired certificates, set to `yes` and uncomment. |
+| `CApath` | `/etc/ssl/certs/` | The directory where known certificates are found. Defaults to OpenSSL's default path. |
+| `CAfile` | `/etc/ssl/certs/cert.pem` | Add a parent node certificate to the list of known certificates in `CAPath`. |
+| `api key` | ` ` | The `API_KEY` to use as the child node. |
+| `timeout seconds` | `60` | The timeout to connect and send metrics to a parent. |
+| `default port` | `19999` | The port to use if `destination` does not specify one. |
+| [`send charts matching`](#send-charts-matching) | `*` | A space-separated list of [Netdata simple patterns](https://github.com/netdata/netdata/blob/master/libnetdata/simple_pattern/README.md) to filter which charts are streamed. [Read more &rarr;](#send-charts-matching) |
+| `buffer size bytes` | `10485760` | The size of the buffer to use when sending metrics. The default `10485760` equals a buffer of 10MB, which is good for 60 seconds of data. Increase this if you expect latencies higher than that. The buffer is flushed on reconnect. |
+| `reconnect delay seconds` | `5` | How long to wait until retrying to connect to the parent node. |
+| `initial clock resync iterations` | `60` | Sync the clock of charts for how many seconds when starting. |
-The child and the parent may have different data retention policies for the same metrics.
+### `[API_KEY]` and `[MACHINE_GUID]` sections
-Alerts for the child are triggered by **both** the child and the parent.
-It is possible to enable different alert configurations on the parent and the child.
+| Setting | Default | Description |
+| :---------------------------------------------- | :------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `enabled` | `no` | Whether this API KEY enabled or disabled. |
+| [`allow from`](#allow-from) | `*` | A space-separated list of [Netdata simple patterns](https://github.com/netdata/netdata/blob/master/libnetdata/simple_pattern/README.md) matching the IPs of nodes that will stream metrics using this API key. [Read more &rarr;](#allow-from) |
+| `default history` | `3600` | The default amount of child metrics history to retain when using the `save`, `map`, or `ram` memory modes. |
+| [`default memory mode`](#default-memory-mode) | `ram` | The [database](https://github.com/netdata/netdata/blob/master/database/README.md) to use for all nodes using this `API_KEY`. Valid settings are `dbengine`, `map`, `save`, `ram`, or `none`. [Read more &rarr;](#default-memory-mode) |
+| `health enabled by default` | `auto` | Whether alarms and notifications should be enabled for nodes using this `API_KEY`. `auto` enables alarms when the child is connected. `yes` enables alarms always, and `no` disables alarms. |
+| `default postpone alarms on connect seconds` | `60` | Postpone alarms and notifications for a period of time after the child connects. |
+| `default proxy enabled` | ` ` | Route metrics through a proxy. |
+| `default proxy destination` | ` ` | Space-separated list of `IP:PORT` for proxies. |
+| `default proxy api key` | ` ` | The `API_KEY` of the proxy. |
+| `default send charts matching` | `*` | See [`send charts matching`](#send-charts-matching). |
-In order for custom chart names on the child to work correctly, follow the form `type.name`. The parent will truncate the `type` part and substitute the original chart `type` to store the name in the database.
+#### `destination`
-### Netdata proxies
+A space-separated list of parent nodes to attempt to stream to, with the first available parent receiving metrics, using
+the following format: `[PROTOCOL:]HOST[%INTERFACE][:PORT][:SSL]`.
-The local Netdata Agent(child), with or without a database, collects metrics and sends them to another
-Netdata node(**proxy**), which may or may not maintain a database, which forwards them to another
-Netdata (parent).
+- `PROTOCOL`: `tcp`, `udp`, or `unix`. (only tcp and unix are supported by parent nodes)
+- `HOST`: A IPv4, IPv6 IP, or a hostname, or a unix domain socket path. IPv6 IPs should be given with brackets
+ `[ip:address]`.
+- `INTERFACE` (IPv6 only): The network interface to use.
+- `PORT`: The port number or service name (`/etc/services`) to use.
+- `SSL`: To enable TLS/SSL encryption of the streaming connection.
-Alerts for the child can be triggered by any of the involved hosts that maintains a database.
+To enable TCP streaming to a parent node at `203.0.113.0` on port `20000` and with TLS/SSL encryption:
-You can daisy-chain any number of Netdata, each with or without a database and
-with or without alerts for the child metrics.
+```conf
+[stream]
+ destination = tcp:203.0.113.0:20000:SSL
+```
-### Mix and match with exporting engine
+#### `send charts matching`
-All nodes that maintain a database can also send their data to an external database.
-This allows quite complex setups.
+A space-separated list of [Netdata simple patterns](https://github.com/netdata/netdata/blob/master/libnetdata/simple_pattern/README.md) to filter which charts are streamed.
-Example:
+The default is a single wildcard `*`, which streams all charts.
-1. Netdata nodes `A` and `B` do not maintain a database and stream metrics to Netdata node `C`(live streaming functionality).
-2. Netdata node `C` maintains a database for `A`, `B`, `C` and archives all metrics to `graphite` with 10 second detail (exporting functionality).
-3. Netdata node `C` also streams data for `A`, `B`, `C` to Netdata `D`, which also collects data from `E`, `F` and `G` from another DMZ (live streaming functionality).
-4. Netdata node `D` is just a proxy, without a database, that streams all data to a remote site at Netdata `H`.
-5. Netdata node `H` maintains a database for `A`, `B`, `C`, `D`, `E`, `F`, `G`, `H` and sends all data to `opentsdb` with 5 seconds detail (exporting functionality)
-6. Alerts are triggered by `H` for all hosts.
-7. Users can use all Netdata nodes that maintain a database to view metrics (i.e. at `H` all hosts can be viewed).
+To send only a few charts, list them explicitly, or list a group using a wildcard. To send _only_ the `apps.cpu` chart
+and charts with contexts beginning with `system.`:
-## Configuration
+```conf
+[stream]
+ send charts matching = apps.cpu system.*
+```
-The following options affect how Netdata streams:
+To send all but a few charts, use `!` to create a negative match. To send _all_ charts _but_ `apps.cpu`:
-```
-[global]
- memory mode = none | ram | save | map | dbengine
+```conf
+[stream]
+ send charts matching = !apps.cpu *
```
-`[global].memory mode = none` disables the database at this host. This also disables health
-monitoring because a node can't have health monitoring without a database.
+#### `allow from`
-```
-[web]
- mode = none | static-threaded
- accept a streaming request every seconds = 0
-```
+A space-separated list of [Netdata simple patterns](https://github.com/netdata/netdata/blob/master/libnetdata/simple_pattern/README.md) matching the IPs of nodes that
+will stream metrics using this API key. The order is important, left to right, as the first positive or negative match is used.
-`[web].mode = none` disables the API (Netdata will not listen to any ports).
-This also disables the registry (there cannot be a registry without an API).
+The default is `*`, which accepts all requests including the `API_KEY`.
-`accept a streaming request every seconds` can be used to set a limit on how often a parent node will accept streaming
-requests from its child nodes. 0 sets no limit, 1 means maximum once every second. If this is set, you may see error log
-entries "... too busy to accept new streaming request. Will be allowed in X secs".
+To allow from only a specific IP address:
-You can [use](https://github.com/netdata/netdata/blob/master/exporting/README.md#configuration) the exporting engine to configure data archiving to an external database (it archives all databases maintained on
-this host).
+```conf
+[API_KEY]
+ allow from = 203.0.113.10
+```
-### Streaming configuration
+To allow all IPs starting with `10.*`, except `10.1.2.3`:
-The new file `stream.conf` contains streaming configuration for a sending and a receiving Netdata node.
+```conf
+[API_KEY]
+ allow from = !10.1.2.3 10.*
+```
-To configure streaming on your system:
-1. Generate an API key using `uuidgen`. Note: API keys are just random GUIDs. You can use the same API key on all your Netdata, or use a different API key for any pair of sending-receiving Netdata nodes.
+> If you set specific IP addresses here, and also use the `allow connections` setting in the `[web]` section of
+> `netdata.conf`, be sure to add the IP address there so that it can access the API port.
-2. Authorize the communication between a pair of sending-receiving Netdata nodes using the generated API key.
-Once the communication is authorized, the sending Netdata node can push metrics for any number of hosts.
+#### `default memory mode`
-3. To edit `stream.conf`, run `/etc/netdata/edit-config stream.conf`
+The [database](https://github.com/netdata/netdata/blob/master/database/README.md) to use for all nodes using this `API_KEY`. Valid settings are `dbengine`, `ram`,
+`save`, `map`, or `none`.
-The following sections describe how you can configure sending and receiving Netdata nodes.
+- `dbengine`: The default, recommended time-series database (TSDB) for Netdata. Stores recent metrics in memory, then
+ efficiently spills them to disk for long-term storage.
+- `ram`: Stores metrics _only_ in memory, which means metrics are lost when Netdata stops or restarts. Ideal for
+ streaming configurations that use ephemeral nodes.
+- `save`: Stores metrics in memory, but saves metrics to disk when Netdata stops or restarts, and loads historical
+ metrics on start.
+- `map`: Stores metrics in memory-mapped files, like swap, with constant disk write.
+- `none`: No database.
-##### Options for the sending node
+When using `default memory mode = dbengine`, the parent node creates a separate instance of the TSDB to store metrics
+from child nodes. The [size of _each_ instance is configurable](https://github.com/netdata/netdata/blob/master/docs/store/change-metrics-storage.md) with the `page
+cache size` and `dbengine multihost disk space` settings in the `[global]` section in `netdata.conf`.
-This is the section for the sending Netdata node. On the receiving node, `[stream].enabled` can be `no`.
-If it is `yes`, the receiving node will also stream the metrics to another node (i.e. it will be
-a proxy).
+### `netdata.conf`
-```
-[stream]
- enabled = yes | no
- destination = IP:PORT[:SSL] ...
- api key = XXXXXXXXXXX
+| Setting | Default | Description |
+| :----------------------------------------- | :---------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **`[global]` section** | | |
+| `memory mode` | `dbengine` | Determines the [database type](https://github.com/netdata/netdata/blob/master/database/README.md) to be used on that node. Other options settings include `none`, `ram`, `save`, and `map`. `none` disables the database at this host. This also disables alarms and notifications, as those can't run without a database. |
+| **`[web]` section** | | |
+| `mode` | `static-threaded` | Determines the [web server](https://github.com/netdata/netdata/blob/master/web/server/README.md) type. The other option is `none`, which disables the dashboard, API, and registry. |
+| `accept a streaming request every seconds` | `0` | Set a limit on how often a parent node accepts streaming requests from child nodes. `0` equals no limit. If this is set, you may see `... too busy to accept new streaming request. Will be allowed in X secs` in Netdata's `error.log`. |
-[API_KEY]
- enabled = yes | no
+### Basic use cases
-[MACHINE_GUID]
- enabled = yes | no
-```
-This is an overview of how these options can be combined:
+This is an overview of how the main options can be combined:
| target|memory<br/>mode|web<br/>mode|stream<br/>enabled|exporting|alarms|dashboard|
|------|:-------------:|:----------:|:----------------:|:-----:|:----:|:-------:|
@@ -148,170 +163,26 @@ This is an overview of how these options can be combined:
| proxy with db|not `none`|not `none`|`yes`|possible|possible|yes|
| central netdata|not `none`|not `none`|`no`|possible|possible|yes|
-For the options to encrypt the data stream between the child and the parent, refer to [securing the communication](#securing-streaming-communications)
+### Per-child settings
+While the `[API_KEY]` section applies settings for any child node using that key, you can also use per-child settings
+with the `[MACHINE_GUID]` section.
-##### Options for the receiving node
+For example, the metrics streamed from only the child node with `MACHINE_GUID` are saved in memory, not using the
+default `dbengine` as specified by the `API_KEY`, and alarms are disabled.
-For a receiving Netdata node, the `stream.conf` looks like this:
-
-```sh
-# replace API_KEY with your uuidgen generated GUID
+```conf
[API_KEY]
enabled = yes
- default history = 3600
- default memory mode = save
+ default memory mode = dbengine
health enabled by default = auto
allow from = *
-```
-
-You can add many such sections, one for each API key. The above are used as default values for
-all hosts pushed with this API key.
-
-You can also add sections like this:
-```sh
-# replace MACHINE_GUID with the child /var/lib/netdata/registry/netdata.public.unique.id
[MACHINE_GUID]
enabled = yes
- history = 3600
memory mode = save
- health enabled = yes
- allow from = *
-```
-
-The above is the parent configuration of a single host, at the parent end. `MACHINE_GUID` is
-the unique id the Netdata generating the metrics (i.e. the Netdata that originally collects
-them `/var/lib/netdata/registry/netdata.unique.id`). So, metrics for Netdata `A` that pass through
-any number of other Netdata, will have the same `MACHINE_GUID`.
-
-You can also use `default memory mode = dbengine` for an API key or `memory mode = dbengine` for
- a single host. The additional `page cache size` and `dbengine multihost disk space` configuration options
- are inherited from the global Netdata configuration.
-
-##### Allow from
-
-`allow from` settings are [Netdata simple patterns](https://github.com/netdata/netdata/blob/master/libnetdata/simple_pattern/README.md): string matches
-that use `*` as wildcard (any number of times) and a `!` prefix for a negative match.
-So: `allow from = !10.1.2.3 10.*` will allow all IPs in `10.*` except `10.1.2.3`. The order is
-important: left to right, the first positive or negative match is used.
-
-##### Tracing
-
-When a child is trying to push metrics to a parent or proxy, it logs entries like these:
-
-```
-2017-02-25 01:57:44: netdata: ERROR: Failed to connect to '10.11.12.1', port '19999' (errno 111, Connection refused)
-2017-02-25 01:57:44: netdata: ERROR: STREAM costa-pc [send to 10.11.12.1:19999]: failed to connect
-2017-02-25 01:58:04: netdata: INFO : STREAM costa-pc [send to 10.11.12.1:19999]: initializing communication...
-2017-02-25 01:58:04: netdata: INFO : STREAM costa-pc [send to 10.11.12.1:19999]: waiting response from remote netdata...
-2017-02-25 01:58:14: netdata: INFO : STREAM costa-pc [send to 10.11.12.1:19999]: established communication - sending metrics...
-2017-02-25 01:58:14: netdata: ERROR: STREAM costa-pc [send]: discarding 1900 bytes of metrics already in the buffer.
-2017-02-25 01:58:14: netdata: INFO : STREAM costa-pc [send]: ready - sending metrics...
-```
-
-The receiving end (proxy or parent) logs entries like these:
-
-```
-2017-02-25 01:58:04: netdata: INFO : STREAM [receive from [10.11.12.11]:33554]: new client connection.
-2017-02-25 01:58:04: netdata: INFO : STREAM costa-pc [10.11.12.11]:33554: receive thread created (task id 7698)
-2017-02-25 01:58:14: netdata: INFO : Host 'costa-pc' with guid '12345678-b5a6-11e6-8a50-00508db7e9c9' initialized, os: linux, update every: 1, memory mode: ram, history entries: 3600, streaming: disabled, health: enabled, cache_dir: '/var/cache/netdata/12345678-b5a6-11e6-8a50-00508db7e9c9', varlib_dir: '/var/lib/netdata/12345678-b5a6-11e6-8a50-00508db7e9c9', health_log: '/var/lib/netdata/12345678-b5a6-11e6-8a50-00508db7e9c9/health/health-log.db', alarms default handler: '/usr/libexec/netdata/plugins.d/alarm-notify.sh', alarms default recipient: 'root'
-2017-02-25 01:58:14: netdata: INFO : STREAM costa-pc [receive from [10.11.12.11]:33554]: initializing communication...
-2017-02-25 01:58:14: netdata: INFO : STREAM costa-pc [receive from [10.11.12.11]:33554]: receiving metrics...
-```
-
-For Netdata v1.9+, streaming can also be monitored via `access.log`.
-
-### Securing streaming communications
-
-Netdata does not activate TLS encryption by default. To encrypt streaming connections:
-1. On the parent node (receiving node), [enable TLS support](https://github.com/netdata/netdata/blob/master/web/server/README.md#enabling-tls-support).
-2. On the child's `stream.conf`, configure the destination as follows:
-
-```
-[stream]
- destination = host:port:SSL
-```
-
-The word `SSL` appended to the end of the destination tells the child that connections must be encrypted.
-
-> While Netdata uses Transport Layer Security (TLS) 1.2 to encrypt communications rather than the obsolete SSL protocol,
-> it's still common practice to refer to encrypted web connections as `SSL`. Many vendors, like Nginx and even Netdata
-> itself, use `SSL` in configuration files, whereas documentation will always refer to encrypted communications as `TLS`
-> or `TLS/SSL`.
-
-#### Certificate verification
-
-When TLS/SSL is enabled on the child, the default behavior will be to not connect with the parent unless the server's certificate can be verified via the default chain. In case you want to avoid this check, add the following to the child's `stream.conf` file:
-
-```
-[stream]
- ssl skip certificate verification = yes
-```
-
-#### Trusted certificate
-
-If you've enabled [certificate verification](#certificate-verification), you might see errors from the OpenSSL library when there's a problem with checking the certificate chain (`X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY`). More importantly, OpenSSL will reject self-signed certificates.
-
-Given these known issues, you have two options. If you trust your certificate, you can set the options `CApath` and `CAfile` to inform Netdata where your certificates, and the certificate trusted file, are stored.
-
-For more details about these options, you can read about [verify locations](https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_load_verify_locations.html).
-
-Before you changed your streaming configuration, you need to copy your trusted certificate to your child system and add the certificate to OpenSSL's list.
-
-On most Linux distributions, the `update-ca-certificates` command searches inside the `/usr/share/ca-certificates` directory for certificates. You should double-check by reading the `update-ca-certificate` manual (`man update-ca-certificate`), and then change the directory in the below commands if needed.
-
-If you have `sudo` configured on your child system, you can use that to run the following commands. If not, you'll have to log in as `root` to complete them.
-
-```
-# mkdir /usr/share/ca-certificates/netdata
-# cp parent_cert.pem /usr/share/ca-certificates/netdata/parent_cert.crt
-# chown -R netdata.netdata /usr/share/ca-certificates/netdata/
-```
-
-First, you create a new directory to store your certificates for Netdata. Next, you need to change the extension on your certificate from `.pem` to `.crt` so it's compatible with `update-ca-certificate`. Finally, you need to change permissions so the user that runs Netdata can access the directory where you copied in your certificate.
-
-Next, edit the file `/etc/ca-certificates.conf` and add the following line:
-
-```
-netdata/parent_cert.crt
-```
-
-Now you update the list of certificates running the following, again either as `sudo` or `root`:
-
-```
-# update-ca-certificates
-```
-
-> Some Linux distributions have different methods of updating the certificate list. For more details, please read this
-> guide on [adding trusted root certificates](https://github.com/Busindre/How-to-Add-trusted-root-certificates).
-
-Once you update your certificate list, you can set the stream parameters for Netdata to trust the parent certificate. Open `stream.conf` for editing and change the following lines:
-
+ health enabled = no
```
-[stream]
- CApath = /etc/ssl/certs/
- CAfile = /etc/ssl/certs/parent_cert.pem
-```
-
-With this configuration, the `CApath` option tells Netdata to search for trusted certificates inside `/etc/ssl/certs`. The `CAfile` option specifies the Netdata parent certificate is located at `/etc/ssl/certs/parent_cert.pem`. With this configuration, you can skip using the system's entire list of certificates and use Netdata's parent certificate instead.
-
-#### Expected behaviors
-
-With the introduction of TLS/SSL, the parent-child communication behaves as shown in the table below, depending on the following configurations:
-
-- **Parent TLS (Yes/No)**: Whether the `[web]` section in `netdata.conf` has `ssl key` and `ssl certificate`.
-- **Parent port TLS (-/force/optional)**: Depends on whether the `[web]` section `bind to` contains a `^SSL=force` or `^SSL=optional` directive on the port(s) used for streaming.
-- **Child TLS (Yes/No)**: Whether the destination in the child's `stream.conf` has `:SSL` at the end.
-- **Child TLS Verification (yes/no)**: Value of the child's `stream.conf` `ssl skip certificate verification` parameter (default is no).
-
-| Parent TLS enabled|Parent port SSL|Child TLS|Child SSL Ver.|Behavior|
-|:----------------:|:-------------:|:-------:|:------------:|:-------|
-| No|-|No|no|Legacy behavior. The parent-child stream is unencrypted.|
-| Yes|force|No|no|The parent rejects the child connection.|
-| Yes|-/optional|No|no|The parent-child stream is unencrypted (expected situation for legacy child nodes and newer parent nodes)|
-| Yes|-/force/optional|Yes|no|The parent-child stream is encrypted, provided that the parent has a valid TLS/SSL certificate. Otherwise, the child refuses to connect.|
-| Yes|-/force/optional|Yes|yes|The parent-child stream is encrypted.|
### Streaming compression
@@ -408,83 +279,147 @@ Same thing applies with the `[MACHINE_GUID]` configuration.
[MACHINE_GUID]
enable compression = yes | no
```
-## Viewing remote host dashboards, using mirrored databases
-On any receiving Netdata, that maintains remote databases and has its web server enabled,
-The node menu will include a list of the mirrored databases.
+### Securing streaming with TLS/SSL
+
+Netdata does not activate TLS encryption by default. To encrypt streaming connections, you first need to [enable TLS
+support](https://github.com/netdata/netdata/blob/master/web/server/README.md#enabling-tls-support) on the parent. With encryption enabled on the receiving side, you
+need to instruct the child to use TLS/SSL as well. On the child's `stream.conf`, configure the destination as follows:
+
+```
+[stream]
+ destination = host:port:SSL
+```
+
+The word `SSL` appended to the end of the destination tells the child that connections must be encrypted.
+
+> While Netdata uses Transport Layer Security (TLS) 1.2 to encrypt communications rather than the obsolete SSL protocol,
+> it's still common practice to refer to encrypted web connections as `SSL`. Many vendors, like Nginx and even Netdata
+> itself, use `SSL` in configuration files, whereas documentation will always refer to encrypted communications as `TLS`
+> or `TLS/SSL`.
+
+#### Certificate verification
-![image](https://cloud.githubusercontent.com/assets/2662304/24080824/24cd2d3c-0caf-11e7-909d-a8dd1dbb95d7.png)
+When TLS/SSL is enabled on the child, the default behavior will be to not connect with the parent unless the server's
+certificate can be verified via the default chain. In case you want to avoid this check, add the following to the
+child's `stream.conf` file:
-Selecting any of these, the server will offer a dashboard using the mirrored metrics.
+```
+[stream]
+ ssl skip certificate verification = yes
+```
-## Monitoring ephemeral nodes
+#### Trusted certificate
-Auto-scaling is probably the most trendy service deployment strategy these days.
+If you've enabled [certificate verification](#certificate-verification), you might see errors from the OpenSSL library
+when there's a problem with checking the certificate chain (`X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY`). More
+importantly, OpenSSL will reject self-signed certificates.
-Auto-scaling detects the need for additional resources and boots VMs on demand, based on a template. Soon after they start running the applications, a load balancer starts distributing traffic to them, allowing the service to grow horizontally to the scale needed to handle the load. When demands falls, auto-scaling starts shutting down VMs that are no longer needed.
+Given these known issues, you have two options. If you trust your certificate, you can set the options `CApath` and
+`CAfile` to inform Netdata where your certificates, and the certificate trusted file, are stored.
-![Monitoring ephemeral nodes with Netdata](https://cloud.githubusercontent.com/assets/2662304/23627426/65a9074a-02b9-11e7-9664-cd8f258a00af.png)
+For more details about these options, you can read about [verify
+locations](https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_load_verify_locations.html).
-What a fantastic feature for controlling infrastructure costs! Pay only for what you need for the time you need it!
+Before you changed your streaming configuration, you need to copy your trusted certificate to your child system and add
+the certificate to OpenSSL's list.
-In auto-scaling, all servers are ephemeral, they live for just a few hours. Every VM is a brand new instance of the application, that was automatically created based on a template.
+On most Linux distributions, the `update-ca-certificates` command searches inside the `/usr/share/ca-certificates`
+directory for certificates. You should double-check by reading the `update-ca-certificate` manual (`man
+update-ca-certificate`), and then change the directory in the below commands if needed.
-So, how can we monitor them? How can we be sure that everything is working as expected on all of them?
+If you have `sudo` configured on your child system, you can use that to run the following commands. If not, you'll have
+to log in as `root` to complete them.
-### The Netdata way
+```
+# mkdir /usr/share/ca-certificates/netdata
+# cp parent_cert.pem /usr/share/ca-certificates/netdata/parent_cert.crt
+# chown -R netdata.netdata /usr/share/ca-certificates/netdata/
+```
+
+First, you create a new directory to store your certificates for Netdata. Next, you need to change the extension on your
+certificate from `.pem` to `.crt` so it's compatible with `update-ca-certificate`. Finally, you need to change
+permissions so the user that runs Netdata can access the directory where you copied in your certificate.
+
+Next, edit the file `/etc/ca-certificates.conf` and add the following line:
-We recently made a significant improvement at the core of Netdata to support monitoring such setups.
+```
+netdata/parent_cert.crt
+```
-Following the Netdata way of monitoring, we wanted:
+Now you update the list of certificates running the following, again either as `sudo` or `root`:
-1. **real-time performance monitoring**, collecting ***thousands of metrics per server per second***, visualized in interactive, automatically created dashboards.
-2. **real-time alarms**, for all nodes.
-3. **zero configuration**, all ephemeral servers should have exactly the same configuration, and nothing should be configured at any system for each of the ephemeral nodes. We shouldn't care if 10 or 100 servers are spawned to handle the load.
-4. **self-cleanup**, so that nothing needs to be done for cleaning up the monitoring infrastructure from the hundreds of nodes that may have been monitored through time.
+```
+# update-ca-certificates
+```
-### How it works
+> Some Linux distributions have different methods of updating the certificate list. For more details, please read this
+> guide on [adding trusted root certificates](https://github.com/Busindre/How-to-Add-trusted-root-certificates).
-All monitoring solutions, including Netdata, work like this:
+Once you update your certificate list, you can set the stream parameters for Netdata to trust the parent certificate.
+Open `stream.conf` for editing and change the following lines:
-1. Collect metrics from the system and the running applications
-2. Store metrics in a time-series database
-3. Examine metrics periodically, for triggering alarms and sending alarm notifications
-4. Visualize metrics so that users can see what exactly is happening
+```
+[stream]
+ CApath = /etc/ssl/certs/
+ CAfile = /etc/ssl/certs/parent_cert.pem
+```
-Netdata used to be self-contained, so that all these functions were handled entirely by each server. The changes we made, allow each Netdata to be configured independently for each function. So, each Netdata can now act as:
+With this configuration, the `CApath` option tells Netdata to search for trusted certificates