Each node running Netdata can stream the metrics it collects, in real time, to another node. To learn more, read about how streaming works.
For a quickstart guide for enabling a simple
parent-child streaming relationship, see our stream metrics between
nodes doc. All other configuration options and scenarios are
covered in the sections below.
There are two files responsible for configuring Netdata's streaming capabilities:
From within your Netdata config directory (typically
As mentioned above, both
netdata.conf contain settings relevant to streaming.
stream.conf file contains three sections. The
[stream] section is for configuring child nodes.
[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.
/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.
|Whether this node streams metrics to any parent. Change to |
|A space-separated list of parent nodes to attempt to stream to, with the first available parent receiving metrics, using the following format: |
|If you want to accept self-signed or expired certificates, set to |
|The directory where known certificates are found. Defaults to OpenSSL's default path.|
|Add a parent node certificate to the list of known certificates in |
|The timeout to connect and send metrics to a parent.|
|The port to use if |
|A space-separated list of Netdata simple patterns to filter which charts are streamed. Read more →|
|The size of the buffer to use when sending metrics. The default |
|How long to wait until retrying to connect to the parent node.|
|Sync the clock of charts for how many seconds when starting.|
|Whether this API KEY enabled or disabled.|
|A space-separated list of Netdata simple patterns matching the IPs of nodes that will stream metrics using this API key. Read more →|
|The default amount of child metrics history to retain when using the |
|The database to use for all nodes using this |
|Whether alarms and notifications should be enabled for nodes using this |
|Postpone alarms and notifications for a period of time after the child connects.|
|Route metrics through a proxy.|
|Space-separated list of |
A space-separated list of parent nodes to attempt to stream to, with the first available parent receiving metrics, using
the following format:
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
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.
To enable TCP streaming to a parent node at
203.0.113.0 on port
20000 and with TLS/SSL encryption:
send charts matching#
A space-separated list of Netdata simple patterns to filter which charts are streamed.
The default is a single wildcard
*, which streams all charts.
To send only a few charts, list them explicitly, or list a group using a wildcard. To send only the
and charts with contexts beginning with
To send all but a few charts, use
! to create a negative match. To send all charts but
A space-separated list of Netdata simple patterns 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.
The default is
*, which accepts all requests including the
To allow from only a specific IP address:
To allow all IPs starting with
If you set specific IP addresses here, and also use the
allow connectionssetting in the
netdata.conf, be sure to add the IP address there so that it can access the API port.
default memory mode#
The database to use for all nodes using this
API_KEY. Valid settings are
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.
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 with the
cache size and
dbengine multihost disk space settings in the
[global] section in
|Determines the database type to be used on that node. Other options settings include |
|Determines the web server type. The other option is |
|Set a limit on how often a parent node accepts streaming requests from child nodes. |
[API_KEY] section applies settings for any child node using that key, you can also use per-child settings
For example, the metrics streamed from only the child node with
MACHINE_GUID are saved in memory, not using the
dbengine as specified by the
API_KEY, and alarms are disabled.
Netdata does not activate TLS encryption by default. To encrypt streaming connections, you first need to enable 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:
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
SSLin configuration files, whereas documentation will always refer to encrypted communications as
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
If you've enabled certificate verification, you might see errors from the OpenSSL library
when there's a problem with checking the certificate chain (
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
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.
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
directory for certificates. You should double-check by reading the
update-ca-certificate manual (
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.
First, you create a new directory to store your certificates for Netdata. Next, you need to change the extension on your
.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:
Now you update the list of certificates running the following, again either as
Some Linux distributions have different methods of updating the certificate list. For more details, please read this guide on adding trusted root certificates.
Once you update your certificate list, you can set the stream parameters for Netdata to trust the parent certificate.
stream.conf for editing and change the following lines:
With this configuration, the
CApath option tells Netdata to search for trusted certificates inside
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.
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
- Parent port TLS (-/force/optional): Depends on whether the
bind tocontains a
^SSL=optionaldirective on the port(s) used for streaming.
- Child TLS (Yes/No): Whether the destination in the child's
:SSLat the end.
- Child TLS Verification (yes/no): Value of the child's
ssl skip certificate verificationparameter (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.|
A proxy is a node that receives metrics from a child, then streams them onward to a parent. To configure a proxy, configure it as a receiving and a sending Netdata at the same time.
Netdata proxies may or may not maintain a database for the metrics passing through them. When they maintain a database, they can also run health checks (alarms and notifications) for the remote host that is streaming the metrics.
In the following example, the proxy receives metrics from a child node using the
66666666-7777-8888-9999-000000000000, then stores metrics using
dbengine. It then uses the
11111111-2222-3333-4444-555555555555 to proxy those same metrics on to a parent node at
Netdata can help you monitor ephemeral nodes, such as containers in an auto-scaling infrastructure, by always streaming metrics to any number of permanently-running parent nodes.
On the parent, set the following in
On the child nodes, set the following in
In addition, edit
netdata.conf on each child node to disable the database and alarms.
Both parent and child nodes log information at
If the child manages to connect to the parent you will see something like (on the parent):
and something like this on the child:
The following sections describe the most common issues you might encounter when connecting parent and child nodes.
When you have a slow connection between parent and child, Netdata raises a few different errors. Most of the
errors will appear in the child's
On the parent side, you may see various error messages, most commonly the following:
Another common problem in slow connections is the child sending a partial message to the parent. In this case, the
parent will write the following to its
In this example,
B was part of a
BEGIN message that was cut due to connection problems.
Slow connections can also cause problems when the parent misses a message and then receives a command related to the
missed message. For example, a parent might miss a message containing the child's charts, and then doesn't know
what to do with the
SET message that follows. When that happens, the parent will show a message like this:
When the child can't connect to a parent for any reason (misconfiguration, networking, firewalls, parent
down), you will see the following in the child's
This question can appear when Netdata starts the stream and receives an unexpected response. This error can appear when the parent is using SSL and the child tries to connect using plain text. You will also see this message when Netdata connects to another server that isn't Netdata. The complete error message will look like this:
Chart data needs to be consistent between child and parent nodes. If there are differences between chart data on
a parent and a child, such as gaps in metrics collection, it most often means your child's
does not match the parent's. To learn more about the different ways Netdata can store metrics, and thus keep chart
data consistent, read our memory mode documentation.
You may see errors about "forbidding access" for a number of reasons. It could be because of a slow connection between
the parent and child nodes, but it could also be due to other failures. Look in your parent's
error.log for errors
that look like this:
MESSAGE will have one of the following patterns:
request without KEY: The message received is incomplete and the KEY value can be API, hostname, machine GUID.
API key 'VALUE' is not valid GUID: The UUID received from child does not have the format defined in RFC 4122
machine GUID 'VALUE' is not GUID.: This error with machine GUID is like the previous one.
API key 'VALUE' is not allowed: This stream has a wrong API key.
API key 'VALUE' is not permitted from this IP: The IP is not allowed to use STREAM with this parent.
machine GUID 'VALUE' is not allowed.: The GUID that is trying to send stream is not allowed.
Machine GUID 'VALUE' is not permitted from this IP.: The IP does not match the pattern or IP allowed to connect to use stream.
The connection between parent and child is a stream. When the parent can't convert the initial connection into
a stream, it will write the following message inside
After logging this error, Netdata will close the stream.