Introduction
This guide covers Netdata's advanced streaming and replication capabilities, which allow you to build centralized observability points across your infrastructure.
Streaming and replication work together to send metrics data from one Netdata Agent (Child) to another Netdata Agent (Parent). Streaming sends metrics in real-time, while replication ensures historical data is copied, as well, maintaining complete data integrity even after connection interruptions.
If you're new to Netdata streaming or prefer a guided approach, jump to our step-by-step guide at the end of this document. The guide will walk you through setting up a basic streaming configuration and then connecting to the comprehensive reference sections as needed.
For a quick reference on setting up the Parent-Child relationship, see the Configuration Examples or refer to our comprehensive Parents: Your Centralization Points documentation for more details.
Understanding Streaming Architecture
Before diving into configuration details, it's important to understand the key concepts behind Netdata's streaming architecture:
Parent-Child Relationship
- Child nodes (data sources) collect metrics directly from systems they monitor
- Parent nodes (data centralization points) receive, store, and visualize metrics from multiple Child nodes
- A single Parent can receive data from many Children, creating a centralized monitoring hub
- Child nodes maintain independence and continue collecting metrics even if the connection to a Parent is lost
Data Flow
- Collection: Child nodes collect metrics from their local systems
- Streaming: Child nodes send real-time metrics to Parent nodes
- Replication: When a connection is established or restored, Child nodes replicate historical data to ensure Parents have complete history
- Storage: Parent nodes store metrics based on their configured retention policies
- Visualization: Users access the Parent node's dashboard to view metrics from all connected Child nodes
Benefits of This Architecture
- Efficiency: Distribute collection workload across multiple nodes while centralizing visualization
- Resilience: Maintain data collection even during network disruptions or Parent node failures
- Scalability: Add more Child nodes or additional Parent nodes as your infrastructure grows
- Flexibility: Configure retention, alerts, and dashboards according to your specific needs
Protocol Architecture
Netdata streaming uses a custom binary protocol over TCP, not HTTP/HTTPS. This is an important distinction:
- Custom binary protocol: Streaming uses Netdata's own protocol designed for efficient metrics transfer, not HTTP
- TLS encryption: When you enable
:SSLin the destination, it adds TLS encryption as a security layer on top of the custom streaming protocol (this is not HTTPS) - Port multiplexing: The same port (19999 by default) handles both web API requests and streaming connections—the server automatically detects which protocol is being used based on the initial handshake
- Destination requirement: This is why streaming requires a Netdata server at the destination, not just any HTTP server
Quick Reference
| Task | Configuration | Example |
|---|---|---|
| Enable streaming on a Child | Set enabled = yes in [stream] section | [stream]enabled = yesdestination = 192.168.1.5 |
| Configure a Parent to accept connections | Create an [API_KEY] section | [API_KEY]type = apienabled = yesallow from = * |
| Set up high availability | Configure multiple destinations on Child | [stream]destination = parent1:19999 parent2:19999 |
| Filter which metrics to send | Use send charts matching setting | send charts matching = system.* !system.uptime |
Configuration Overview
Netdata's streaming capabilities are configured through two key files:
stream.conf– Controls streaming behavior, including Parent and Child configurations.netdata.conf– Contains global settings that can impact streaming.
To edit these files, navigate to your Netdata configuration directory (typically /etc/netdata) and run:
# Edit streaming configuration
sudo ./edit-config stream.conf
# Edit global Netdata settings
sudo ./edit-config netdata.conf
Configuring stream.conf
The stream.conf file has three main sections:
[stream]– With these settings, you can configure how Child nodes send metrics.[API_KEY]– Here you can define settings for authentication and access control between Parents and Children.[MACHINE_GUID]– This area lets you customize settings for specific Child nodes by their unique ID.
Identifying a Node's GUID
Each Netdata node has a unique identifier stored in:
/var/lib/netdata/registry/netdata.public.unique.id
This file is generated automatically the first time Netdata starts and remains unchanged.
Recommended Deployment Strategies
For a production-ready streaming setup, consider the following best practices:
Multiple Parent Nodes
Setting up multiple Parent nodes creates redundancy in your monitoring infrastructure. If one Parent fails, Child nodes can automatically switch to another available Parent. This approach:
- Prevents single points of failure in your monitoring system
- Allows for maintenance on Parent nodes without monitoring interruptions
- Can be geographically distributed to reduce latency for global deployments
Optimized Data Retention
Configure data retention settings based on your specific monitoring needs:
- Use longer retention periods for critical systems and metrics
- Implement tiered storage strategies with different retention policies
- Balance storage requirements with data availability for historical analysis
Secure Communications
Protect your metrics data during transmission:
- Enable SSL/TLS encryption for all streaming connections
- Implement proper API key management and rotation
- Use IP-based restrictions to control which nodes can connect
Performance Monitoring
Regularly evaluate the health of your streaming setup:
- Monitor network traffic between Child and Parent nodes
- Check for buffer overflows or connection issues
- Adjust settings like buffer size based on actual performance
By following these guidelines, you can set up a scalable and reliable Netdata streaming environment.
stream.conf Detailed Reference
[stream] Section (Child Node Settings)
With these settings, you can configure how your Child nodes send metrics to Parent nodes.
| Setting | Default | Description |
|---|---|---|
enabled | no | Enables streaming. Set to yes to allow this node to send metrics. |
destination | (empty) | Defines one or more Parent nodes to send data to. |
ssl skip certificate verification | yes | Accepts self-signed or expired SSL certificates. |
CApath | /etc/ssl/certs/ | Directory for trusted SSL certificates. |
CAfile | /etc/ssl/certs/cert.pem | File containing trusted certificates. |
api key | (empty) | API key used by the Child to authenticate with the Parent. |
timeout | 1m | Connection timeout duration. |
default port | 19999 | Default port for streaming if not specified in destination. |
send charts matching | * | Filters which charts are streamed. |
buffer size bytes | 10485760 | Buffer size (10MB by default). Increase for higher latencies. |
reconnect delay | 5s | Time before retrying connection to the Parent. |
initial clock resync iterations | 60 | Syncs chart clocks during startup. |
parent using h2o | no | Set to yes if connecting to a Parent using the H2O web server. |
[API_KEY] Section (Parent Node Authentication)
Here you can define settings for authentication and access control between Parents and Children.
| Setting | Default | Description |
|---|---|---|
enabled | no | Enables or disables this API key. |
type | api | Defines the section as an API key configuration. |
allow from | * | Specifies which Child nodes (IP addresses) can connect. |
retention | 1h | How long to keep Child node metrics in RAM-based storage. |
db | dbengine | Specifies the database type for this API key. |
health enabled | auto | Controls alerts and notifications (auto, yes, or no). |
postpone alerts on connect | 1m | Delay alerts for a period after the Child connects. |
health log retention | 5d | Duration (in seconds) to keep health log events. |
proxy enabled | (empty) | Enables routing metrics through a proxy. |
proxy destination | (empty) | IP and port of the proxy server. |
proxy api key | (empty) | API key for the proxy server. |
send charts matching | * | Defines which charts to stream. |
enable compression | yes | Enables or disables data compression. |
enable replication | yes | Enables or disables data replication. |
replication period | 1d | Maximum time window replicated from each Child. |
replication step | 10m | Time interval for each replication step. |
is ephemeral node | no | Marks the Child as ephemeral (removes it after inactivity). |
[MACHINE_GUID] Section (Per-Node Customization)
This area lets you customize settings for specific Child nodes by their unique ID.
| Setting | Default | Description |
|---|---|---|
enabled | no | Enables or disables this specific node's configuration. |
type | machine | Defines the section as a machine-specific configuration. |
allow from | * | Lists IP addresses allowed to stream metrics. |
retention | 3600 | Retention period for Child metrics in RAM-based storage. |
db | dbengine | Database type for this node. |
health enabled | auto | Controls alerts (auto, yes, no). |
postpone alerts on connect | 1m | Delay alerts for a period after connection. |
health log retention | 5d | Duration to keep health log events. |
proxy enabled | (empty) | Routes metrics through a proxy if enabled. |
proxy destination | (empty) | Proxy server IP and port. |
proxy api key | (empty) | API key for the proxy. |
send charts matching | * | Filters streamed charts. |
enable compression | yes | Enables or disables compression. |
enable replication | yes | Enables or disables replication. |
replication period | 1d | Maximum replication window. |
replication step | 10m | Time interval for each replication step. |
is ephemeral node | no | Marks the node as ephemeral (removes after inactivity). |
Additional Settings
destination
Defines Parent nodes for streaming using the format:
[PROTOCOL:]HOST[%INTERFACE][:PORT][:SSL]
- PROTOCOL:
tcp,udp, orunix(onlytcpandunixare supported for Parents). - HOST: IPv4, IPv6 (in brackets
[ ]), hostname, or Unix domain socket path. - INTERFACE (IPv6 only): Network interface to use.
- PORT: Port number or service name.
- SSL: Enables TLS/SSL encryption.
Example (TCP connection with SSL to 203.0.113.0 on port 20000):
[stream]
# Send metrics securely to the Parent at 203.0.113.0:20000
destination = tcp:203.0.113.0:20000:SSL
send charts matching
Controls which charts are streamed.
-
*(default) – Streams all charts. -
Specific charts:
[stream]
# Only send CPU application charts and all system charts
send charts matching = apps.cpu system.* -
Exclude charts using
!:[stream]
# Send all charts except CPU application charts
send charts matching = !apps.cpu *
allow from
Defines which Child nodes (by IP) can connect.
-
Allow a single IP:
[API_KEY]
# Only allow connections from 203.0.113.10
allow from = 203.0.113.10 -
Allow a range but exclude one:
[API_KEY]
# Allow all 10.*.*.* addresses except 10.1.2.3
allow from = !10.1.2.3 10.*
db
Defines the database mode:
dbengine– Stores recent metrics in RAM and writes older data to disk.ram– Stores metrics only in RAM (lost on restart).none– No database.
[API_KEY]
# Use disk-based database for all metrics
db = dbengine
netdata.conf Settings Affecting Streaming
The netdata.conf file is the primary configuration file for the Netdata agent. The following sections can impact streaming:
[global]
This section defines global settings for the Netdata agent.
- hostname: The hostname used by the agent.
- error log file: Path to the file where error logs are saved.
[web]
Configure the web interface settings here.
- bind to: Define the network address to which Netdata binds.
- port: Set the port for the web interface (default: 19999).
- disable SSL: Set to
yesto disable SSL support.
[db]
Manage database settings for data storage and retention.
- db (formerly
memory mode): Choose between in-memory or disk-based storage (e.g.,dbengine,ram,none). - retention: Set how long to keep historical data.
- update every: The data collection frequency in seconds.
Parent and Child update every do not need to match
The update every setting controls the collection granularity of the metrics this node collects locally. In a Parent-Child streaming setup, the Parent's [db] update every and a Child's update every are independent — they do not need to match:
- The Parent's
update everygoverns only the metrics the Parent collects from its own host. - A streaming Child automatically sends its own
update everyto the Parent, and the Parent stores that Child's metrics at the Child's collection frequency — regardless of the Parent'supdate every. - Each streaming Child is a separate host on the Parent, each keeping its own
update every.
Configuring both nodes with the same value is neither required nor beneficial — if they happen to be equal, it is coincidental and has no effect on correctness. Set each node's update every based on the collection granularity you want for that node's own data.
Complete Configuration Examples
Basic Parent-Child Setup
Parent node configuration (stream.conf):
# Generate a random UUID first: uuidgen
[11111111-2222-3333-4444-555555555555]
type = api
# Enable this API key
enabled = yes
# Allow all IPs to connect with this key
allow from = *
# Store data using dbengine for persistence
db = dbengine
Child node configuration (stream.conf):
[stream]
# Enable streaming on this node
enabled = yes
# Connect to Parent at 192.168.1.5 port 19999
destination = 192.168.1.5
# Use the same API key defined on the Parent
api key = 11111111-2222-3333-4444-555555555555
High Availability Setup with Multiple Parents
Parent nodes configuration (stream.conf on both Parents):
# Configuration for accepting metrics from Children
[11111111-2222-3333-4444-555555555555]
type = api
enabled = yes
allow from = *
db = dbengine
# Configuration for accepting metrics from other Parents
[22222222-3333-4444-5555-666666666666]
type = api
enabled = yes
# Only allow the other Parent's IP
allow from = 192.168.1.5 192.168.1.6
db = dbengine
First Parent node's configuration for streaming to the second Parent:
[stream]
enabled = yes
destination = 192.168.1.6
api key = 22222222-3333-4444-5555-666666666666
Second Parent node's configuration for streaming to the first Parent:
[stream]
enabled = yes
destination = 192.168.1.5
api key = 22222222-3333-4444-5555-666666666666
Child node configuration:
[stream]
enabled = yes
# List both Parents for failover
destination = 192.168.1.5 192.168.1.6
api key = 11111111-2222-3333-4444-555555555555
Verifying Successful Connections
If the streaming configuration is working correctly, you'll see logs similar to the following.
On the Parent side:
2017-03-09 09:38:52: netdata: INFO : STREAM [receive from [10.11.12.86]:38564]: new client connection.
2017-03-09 09:38:52: netdata: INFO : STREAM xxx [10.11.12.86]:38564: receive thread created (task id 27721)
On the Child side:
2017-03-09 09:38:28: netdata: INFO : STREAM xxx [send to box:19999]: connecting...
2017-03-09 09:38:28: netdata: INFO : STREAM xxx [send to box:19999]: established communication - sending metrics...
Both Parent and Child nodes log information in /var/log/netdata/error.log.
Troubleshooting
FAQ
Step-by-Step Setup Guide
This guide will walk you through setting up Netdata streaming between nodes. By following these sequential steps, you'll create a basic streaming configuration that you can later customize based on your needs.
Quick Troubleshooting Tips
Do you have any feedback for this page? If so, you can open a new issue on our netdata/learn repository.
