Observability cent points improved (#20052)
* Observability cent points improved * Observability cent points 2 * fix formatting * fixes --------- Co-authored-by: ilyam8 <ilya@netdata.cloud>
kanelatechnical committed
Apr 5, 2025 at 16:40 UTC
86eb74af33f450c93ea1bcca1ed56aa09b6562e5
5 files changed
+314
-629
docs/nodes-ephemerality.md
+40
-47
@@ -1,90 +1,83 @@
1
# Nodes Ephemerality in Netdata
2
3
-## Overview
4
-
5
-Netdata v2.3.0 changes how ephemeral nodes are defined and managed in distributed monitoring environments. This update enhances monitoring reliability while providing flexibility for dynamic infrastructure management.
6
-
7
-**Key Changes**:
8
-
9
-Netdata now defines ephemeral nodes as "nodes that are expected to disconnect without raising alerts," replacing the previous definition of forgotten nodes after one day of disconnection. This change provides three major benefits:
3
+## Node Types
4
11
-1. **Improved Permanent Node Monitoring**: Disconnection alerts are triggered only for permanent nodes, reducing alert noise and helping teams focus on genuine operational issues.
12
-2. **Better Support for Dynamic Infrastructure**: Organizations using auto-scaling cloud instances, containers, and other dynamic resources can now designate nodes as ephemeral, preventing unnecessary alerts.
13
-3. **Automated Node Management**: The system automatically removes ephemeral nodes based on configurable retention periods, maintaining clean and relevant monitoring dashboards.
5
+Netdata categorizes nodes into two types:
6
15
-## Node Types
7
+| Type | Description | Common Use Cases |
8
+|---------------|------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
9
+| **Ephemeral** | Expected to disconnect or reconnect frequently | - Auto-scaling cloud instances<br>- Dynamic containers and VMs<br>- IoT devices with intermittent connectivity<br>- Development/test environments with frequent restarts |
10
+| **Permanent** | Expected to maintain continuous connectivity | - Production servers<br>- Core infrastructure nodes<br>- Critical monitoring systems<br>- Stable database servers |
11
17
-Netdata supports two types of nodes:
12
+> **Note:** Disconnections in permanent nodes indicate potential system failures and require immediate attention.
13
19
-| Type | Description | Common Examples |
20
-|-----------|------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
21
-| Ephemeral | Nodes expected to disconnect or reconnect frequently | • Auto-scaling cloud instances<br/>• Dynamic containers and VMs<br/>• IoT devices with intermittent connectivity<br/>• Development/test environments with frequent restarts |
22
-| Permanent | Nodes expected to maintain continuous connectivity | • Production servers<br/>• Core infrastructure nodes<br/>• Critical monitoring systems<br/>• Stable database servers |
14
+### Key Benefits
15
24
-> **Note**: Disconnections in permanent nodes indicate potential system failures requiring immediate attention.
16
+1. **Reduced Alert Noise**: Disconnection alerts now apply only to permanent nodes, helping teams focus on actual issues.
17
+2. **Improved Dynamic Infrastructure Support**: Auto-scaling cloud instances, containers, and other temporary resources can be designated as ephemeral to prevent unnecessary alerts.
18
+3. **Automated Node Cleanup**: Ephemeral nodes are removed based on configurable retention periods, keeping dashboards relevant and uncluttered.
19
26
-## Setting Up Ephemeral Nodes
20
+## Configuring Ephemeral Nodes
21
22
By default, Netdata treats all nodes as permanent. To mark a node as ephemeral:
23
30
-1. Open `netdata.conf` on the target node
24
+1. Open the `netdata.conf` file on the target node.
25
2. Add the following configuration:
26
```ini
27
[global]
28
is ephemeral node = yes
29
```
36
-3. Restart the node
30
+3. Restart the node.
31
38
-This configuration sets the `_is_ephemeral` host label which propagates to Netdata Parents and Netdata Cloud.
32
+This setting applies the `_is_ephemeral` host label, which propagates to Netdata Parents and Netdata Cloud.
33
40
-## Alerts: Parent Node Alerts
34
+## Alerts for Parent Nodes
35
42
-Netdata v2.3.0 adds [two alerts](https://github.com/netdata/netdata/blob/master/src/health/health.d/streaming.conf) specifically for permanent nodes:
36
+Netdata v2.3.0 introduces two new alerts specifically for permanent nodes:
37
44
-| Alert | Triggers |
45
-|---------------------------|---------------------------------------------------------------|
46
-| streaming_never_connected | When permanent nodes have never connected to a Netdata Parent |
47
-| streaming_disconnected | When previously connected permanent nodes disconnect |
38
+| Alert | Trigger Condition |
39
+|-----------------------------|-----------------------------------------------------------|
40
+| `streaming_never_connected` | A permanent node has never connected to a Netdata Parent. |
41
+| `streaming_disconnected` | A previously connected permanent node has disconnected. |
42
43
## Monitoring Child Node Status
44
51
-To investigate alert:
45
+To investigate an alert:
46
53
-1. Navigate to the `Top` tab in your dashboard
54
-2. Select the `Netdata-streaming` function
55
-3. Review the detailed node status table:
56
- - Red lines: Node connection problems (when nodes attempt to connect to this Parent)
57
- - Yellow lines: Restreaming issues (when this Parent attempts to stream data to other Parent nodes)
58
- - Color highlighting applies only to permanent nodes
59
- - Filter by `Ephemerality` to focus on permanent nodes
60
- - Use `InStatus`, `InReason`, and `InAge` columns to analyze node connections to the parent node
61
- - Use `OutStatus`, `OutReason`, and `OutAge` columns to analyze this Parent's restreaming to other Parent nodes
47
+1. Open the `Top` tab in your Netdata dashboard.
48
+2. Select the `Netdata-streaming` function.
49
+3. Review the node status table:
50
+ - **Red lines**: Connection issues when nodes attempt to connect to a Parent.
51
+ - **Yellow lines**: Restreaming issues when a Parent streams data to another Parent.
52
+ - **Color highlighting applies only to permanent nodes**.
53
+ - Use the `Ephemerality` filter to view only permanent nodes.
54
+ - Check `InStatus`, `InReason`, and `InAge` for incoming connection status.
55
+ - Check `OutStatus`, `OutReason`, and `OutAge` for outgoing streaming status.
56
63
-## Managing Archived Nodes
57
+## Managing Offline Nodes
58
65
-To clear alerts for permanently offline nodes:
59
+To clear alerts for permanently offline nodes, run:
60
61
```bash
62
netdatacli mark-stale-nodes-ephemeral <node_id | machine_guid | hostname | ALL_NODES>
63
```
64
71
-> **Note**: Nodes will revert to permanent status if they reconnect unless configured as ephemeral in their `netdata.conf`.
65
+> **Note:** Nodes will revert to permanent status if they reconnect unless explicitly configured as ephemeral in `netdata.conf`.
66
67
## Cloud Integration
68
75
-Starting with v2.3.0, Netdata Cloud sends node-unreachable notifications **exclusively for permanent nodes**, improving alert relevance.
69
+From v2.3.0 onward, Netdata Cloud sends unreachable-node notifications **only for permanent nodes**, reducing unnecessary alerts.
70
77
-## Automatic Ephemeral Nodes Cleanup
71
+## Automatically Removing Ephemeral Nodes
72
79
-The automatic removal of disconnected ephemeral nodes is disabled by default in v2.3.0+. To enable this feature:
73
+By default, Netdata does not automatically remove disconnected ephemeral nodes. To enable automatic cleanup:
74
81
-1. Edit the `netdata.conf` file on Netdata Parent nodes
75
+1. Open the `netdata.conf` file on Netdata Parent nodes.
76
2. Add the following configuration:
83
-
77
```ini
78
[db]
79
cleanup ephemeral hosts after = 1d
80
```
88
-3. Restart the node
81
+3. Restart the node.
82
90
-This setting removes ephemeral nodes from queries 24 hours after disconnection. When all parent nodes remove a node, Netdata Cloud automatically deletes it too.
83
+This setting removes ephemeral nodes from queries after 24 hours of disconnection. Once all parent nodes remove a node, Netdata Cloud automatically deletes it as well.
docs/observability-centralization-points/README.md
+18
-10
@@ -1,18 +1,26 @@
1
-# Observability Centralization Points
1
+# **Observability Centralization Points**
2
3
-Netdata supports the creation of multiple independent **Observability Centralization Points**, aggregating metric samples, logs and metadata within an infrastructure.
3
+Netdata allows you to set up multiple **Observability Centralization Points** to aggregate metrics, logs, and metadata across your infrastructure.
4
5
-Observability Centralization Points are crucial for ensuring comprehensive monitoring and observability across an infrastructure, particularly under the following conditions:
5
+## **Why Use Centralization Points?**
6
7
-1. **Ephemeral Systems**: For systems like Kubernetes nodes or ephemeral VMs that may not be persistently available, centralization points ensure that metrics and logs are not lost when these systems go offline. This is essential for maintaining historical data for analysis and troubleshooting.
7
+- **Ephemeral Systems**:
8
+ - Ideal for **Kubernetes nodes or temporary VMs** that frequently go offline.
9
+ - Ensures metrics and logs remain available for analysis and troubleshooting.
10
9
-2. **Resource Constraints**: In scenarios where the monitored systems lack sufficient resources (disk space or I/O bandwidth, CPU, RAM) to handle observability tasks effectively, centralization points offload these responsibilities, ensuring that production systems can operate efficiently without compromise.
11
+- **Limited Resources**:
12
+ - Offloads observability tasks from systems with **low disk space, CPU, RAM, or I/O bandwidth**.
13
+ - Keeps production systems running efficiently without performance trade-offs.
14
11
-3. **Multi-node Dashboards without Netdata Cloud**: For environments requiring aggregated views across multiple nodes but without the use of Netdata Cloud, Netdata Parents can aggregate this data to provide comprehensive dashboards, similar to what Netdata Cloud offers.
15
+- **Multi-Node Dashboards Without Netdata Cloud**:
16
+ - Aggregates data from multiple nodes for **centralized dashboards**, similar to Netdata Cloud.
17
13
-4. **Netdata Cloud Access Restrictions**: In cases where monitored systems cannot connect to Netdata Cloud (due to a firewall policy), a Netdata Parent can serve as a bridge, aggregating data and interfacing with Netdata Cloud on behalf of these restricted systems.
18
+- **Restricted Netdata Cloud Access**:
19
+ - Acts as a **bridge** when monitored systems can’t connect to Netdata Cloud due to **firewall restrictions**.
20
15
-When multiple independent centralization points are available:
21
+## **How Multiple Centralization Points Work**
22
17
-- Netdata Cloud provides a unified infrastructure view by querying all points in parallel.
18
-- Parent nodes without Cloud access provide consolidated views of their connected infrastructure's metrics and logs.
23
+- **With Netdata Cloud**:
24
+ - Queries all centralization points in parallel for a unified view of the infrastructure.
25
+- **Without Netdata Cloud**:
26
+ - Parent nodes consolidate data from connected systems, providing a local view of metrics and logs.
docs/observability-centralization-points/best-practices.md
+24
-33
@@ -1,44 +1,35 @@
1
# Best Practices for Observability Centralization Points
2
3
-When planning the deployment of Observability Centralization Points, the following factors need consideration:
3
+## Critical factors to consider
4
5
-1. **Volume of Monitored Systems**: The number of systems being monitored dictates the scaling and number of centralization points required. Larger infrastructures may require multiple centralization points to manage the volume of data effectively and maintain performance.
5
+When setting up Observability Centralization Points, consider the following:
6
7
-2. **Cost of Data Transfer**: Particularly in multi-cloud or hybrid environments, the location of centralization points can significantly impact egress bandwidth costs. Strategically placing centralization points in each data center or cloud region can minimize these costs by reducing the need for cross-network data transfer.
7
+1. **System Volume**: The number of monitored systems impacts scaling. Larger infrastructures may need multiple centralization points to maintain performance.
8
+2. **Data Transfer Costs**: In multi-cloud or hybrid environments, placing centralization points strategically reduces egress bandwidth costs.
9
+3. **Usability Without Netdata Cloud**: Using fewer centralization points simplifies access and management when Netdata Cloud is not in use.
10
+4. **Optimized Deployment with Netdata Cloud**: Netdata Cloud provides a complete infrastructure view, allowing you to optimize based on:
11
+ - **Security** (internet access controls)
12
+ - **Cost** (bandwidth and resource allocation)
13
+ - **Operational needs** (regional, service, or team-based isolation)
14
9
-3. **Usability without Netdata Cloud**: When not using Netdata Cloud, observability with Netdata is simpler when there are fewer centralization points, making it easier to remember where observability is and how to access it.
15
+## Cost Optimization Strategies
16
11
-4. Netdata Cloud provides infrastructure-wide views regardless of centralization points, allowing you to optimize your setup based on:
12
- - Security requirements (such as internet access controls)
13
- - Cost management (including bandwidth and resource allocation)
14
- - Operational needs (like regional, service, or team isolation)
17
+Netdata is designed to keep observability efficient and cost-effective. To manage costs:
18
16
-## Cost Optimization
19
+- **Scale Out**: Use multiple smaller centralization points to improve efficiency and performance.
20
+- **Use Existing Resources**: Leverage spare capacity before dedicating new resources to observability.
21
+- **Centralized or Separate Logs & Metrics**: Choose whether to store logs and metrics together or separately based on access needs, retention policies, and compliance.
22
+- **Flexible Configuration Management**: Each centralization point can have unique retention and alert settings, helping to control costs and tailor observability for different teams or services.
23
18
-Netdata has been designed for observability cost optimization. For optimal cost, we recommend using Netdata Cloud and multiple independent observability centralization points:
24
+## Advantages of Netdata's Approach
25
20
-- **Scale out**: add more, smaller centralization points to distribute the load. This strategy provides the least resource consumption per unit of workload, maintaining optimal performance and resource efficiency across your observability infrastructure.
26
+Netdata provides several benefits over other observability solutions:
27
22
-- **Use existing infrastructure resources**: use spare capacities before allocating dedicated resources for observability. This approach minimizes additional costs and promotes an economically sustainable observability framework.
28
+- **Scalability & Flexibility**: Multiple independent centralization points allow for customized observability by region, service, or team.
29
+- **Resilience & Reliability**: Built-in replication ensures that observability continues even if a centralization point fails.
30
+- **Optimized Cost & Performance**: Distributing workloads prevents bottlenecks and improves resource efficiency.
31
+- **Ease of Use**: Netdata Agents require minimal setup and maintenance, reducing complexity.
32
+- **On-Prem Control**: Centralization points remain on-prem even when using Netdata Cloud, keeping data within your infrastructure.
33
+- **Comprehensive Observability**: Netdata enables deep visibility by segmenting infrastructure into independent observability points with tailored retention, alerts, and machine learning, while Netdata Cloud provides a unified view.
34
24
-- **Unified or separate centralization for logs and metrics**: Netdata allows centralizing metrics and logs together or separately. Consider factors such as access frequency, data retention policies, and compliance requirements to enhance performance and reduce costs.
25
-
26
-- **Decentralized configuration management**: each Netdata centralization point can have its own unique configuration for retention and alerts. This enables:
27
- - Finer control on infrastructure costs
28
- - Localized control for separate services or teams
29
-
30
-## Pros and Cons
31
-
32
-Compared to other observability solutions, the design of Netdata offers:
33
-
34
-- **Enhanced Scalability and Flexibility**: Netdata's support for multiple independent observability centralization points allows for a more scalable and flexible architecture. This feature is particularly helpful in distributed and complex environments, enabling tailored observability strategies that can vary by region, service, or team requirements.
35
-
36
-- **Resilience and Fault Tolerance**: The ability to deploy multiple centralization points also contributes to greater system resilience and fault tolerance. Replication is a native feature of Netdata centralization points, so in the event of a failure at one centralization point, others can continue to function, ensuring continuous observability.
37
-
38
-- **Optimized Cost and Performance**: By distributing the load across multiple centralization points, Netdata can optimize both performance and cost. This distribution allows for the efficient use of resources and help mitigate the bottlenecks associated with a single centralization point.
39
-
40
-- **Simplicity**: Netdata Agents (Children and Parents) require minimal configuration and maintenance, usually less than the configuration and maintenance required for the Agents and exporters of other monitoring solutions. This provides an observability pipeline that has less moving parts and is easier to manage and maintain.
41
-
42
-- **Always On-Prem**: Netdata centralization points are always on-prem. Even when Netdata Cloud is used, Netdata Agents and parents are queried to provide the data required for the dashboards.
43
-
44
-- **Bottom-Up Observability**: Netdata is designed to monitor systems, containers and applications bottom-up, aiming to provide the maximum resolution, visibility, depth and insights possible. Its ability to segment the infrastructure into multiple independent observability centralization points with customized retention, machine learning and alerts on each of them, while providing unified infrastructure level dashboards at Netdata Cloud, provides a flexible environment that can be tailored per service or team, while still being one unified infrastructure.
35
+Following these best practices helps maintain a **cost-effective**, **high-performance** observability setup with Netdata.
docs/observability-centralization-points/metrics-centralization-points/README.md
+40
-23
@@ -11,37 +11,54 @@ flowchart BT
11
C3 -->|stream| P1
12
```
13
14
-Netdata **Streaming and Replication** copies the recent past samples (replication) and in real-time all new samples collected (streaming) from production systems (Netdata Children) to metrics centralization points (Netdata Parents). The Netdata Parents then maintain the database for these metrics, according to their retention settings.
14
+- **Netdata Streaming and Replication**:
15
+ - Copies **recent past samples** (replication) and **real-time new samples** (streaming) from production systems (**Netdata Children**) to **metrics centralization points** (**Netdata Parents**).
16
+ - **Netdata Parents** store the database for these metrics based on **retention settings**.
17
16
-Each production system (Netdata Child) can stream to **only one** Netdata Parent at a time. The configuration allows configuring multiple Netdata Parents for high availability, but only the first found working will be used.
18
+- **Netdata Child Behavior**:
19
+ - Each **Netdata Child** can stream to **only one** Netdata Parent at a time.
20
+ - Multiple **Netdata Parents** can be configured for **high availability**, but only the **first working one** will be used.
21
18
-Netdata Parents receive metric samples **from multiple** production systems (Netdata Children) and can re-stream them to another Netdata Parent. This allows building an infinite hierarchy of Netdata Parents. It also enables the configuration of Netdata Parents Clusters, for high availability.
22
+- **Netdata Parent Capabilities**:
23
+ - Receives metric samples **from multiple Netdata Children**.
24
+ - Can **re-stream** received metrics to another **Netdata Parent**, forming an **infinite hierarchy** of Parents.
25
+ - Supports **Netdata Parents Clusters** for **high availability**.
26
20
-| Feature | Netdata Child (production system) | Netdata Parent (centralization point) |
21
-|:---------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------------------:|
22
-| Metrics Retention | Can be minimized, or switched to mode `ram` or `alloc` to save resources. Some retention is required in case network errors introduce disconnects. | Common retention settings for all systems aggregated to it. |
23
-| Machine Learning | Can be disabled (enabled by default). | Runs Anomaly Detection for all systems aggregated to it. |
24
-| Alerts & Notifications | Can be disabled (enabled by default). | Runs health checks and sends notifications for all systems aggregated to it. |
25
-| API and Dashboard | Can be disabled (enabled by default). | Serves the dashboard for all systems aggregated to it, using its own retention. |
26
-| Exporting Metrics | Not required (enabled by default). | Exports the samples of all metrics collected by the systems aggregated to it. |
27
-| Netdata Functions | Netdata Child must be online. | Forwards Functions requests to the Children connected to it. |
28
-| Connection to Netdata Cloud | Not required. | Each Netdata Parent registers to Netdata Cloud all systems aggregated to it. |
27
+| Feature | Netdata Child (Production System) | Netdata Parent (Centralization Point) |
28
+|----------------------------|---------------------------------------------------|-------------------------------------------------------|
29
+| **Metrics Retention** | Minimal retention; can use `ram` or `alloc` mode. | Stores metrics for all connected systems. |
30
+| **Machine Learning** | Can be disabled (default: enabled). | Runs anomaly detection for all connected systems. |
31
+| **Alerts & Notifications** | Can be disabled (default: enabled). | Monitors health and sends alerts for all systems. |
32
+| **API & Dashboard** | Can be disabled (default: enabled). | Hosts the dashboard using its own retention settings. |
33
+| **Exporting Metrics** | Optional (default: enabled). | Exports all collected metrics. |
34
+| **Netdata Functions** | Child must be online to function. | Forwards function requests to connected Children. |
35
+| **Netdata Cloud** | Not required. | Registers all connected systems to Netdata Cloud. |
36
30
-## Supported Configurations
37
+## **Supported Configurations**
38
32
-For Netdata Children:
39
+### **For Netdata Children**
40
34
-1. **Full**: Full Netdata functionality is available at the Children. This means running machine learning, alerts, notifications, having the local dashboard available, and generally all Netdata features enabled. This is the default.
35
-2. **Thin**: The Children are only collecting and forwarding metrics to a Parent. Some local retention may exist to avoid missing samples in case of network issues or Parent maintenance, but everything else is disabled.
41
+- **Full Mode (Default)**:
42
+ - All Netdata features are enabled (machine learning, alerts, notifications, dashboard, etc.).
43
+- **Thin Mode**:
44
+ - Only collects and forwards metrics to a Parent.
45
+ - Some local retention is kept to handle network issues, but all other features are disabled.
46
37
-For Netdata Parents:
47
+### **For Netdata Parents**
48
39
-1. **Standalone**: The Parent is standalone, either the only Parent available in the infrastructure, or the top-most of a hierarchy of Parents.
40
-2. **Cluster**: The Parent is part of a cluster of Parents, all having the same data from the same Children. A Cluster of Parents offers high-availability.
41
-3. **Proxy**: The Parent receives metrics and stores them locally, but it also forwards them to a Grand Parent.
49
+- **Standalone**:
50
+ - A single Parent in the infrastructure or the top-most Parent in a hierarchy.
51
+- **Cluster**:
52
+ - A group of Parents that share the same data from the same Children.
53
+ - Provides **high availability**.
54
+- **Proxy**:
55
+ - Stores received metrics locally and **forwards them** to a higher-level Parent (Grand Parent).
56
43
-A Cluster consists of nodes configured as circular **Proxies**, where each node acts as a Parent to all others. When using multiple levels of centralization, only the top level can be configured as a cluster.
57
+### **Cluster Configuration**
58
45
-## Best Practices
59
+- A Cluster consists of **circular Proxy nodes**, where each Parent acts as a Parent to the others.
60
+- Only the **top level** of a multi-level hierarchy can be configured as a cluster.
61
47
-Refer to [Best Practices for Observability Centralization Points](/docs/observability-centralization-points/best-practices.md).
62
+## **Best Practices**
63
+
64
+For detailed guidelines, check [Best Practices for Observability Centralization Points](/docs/observability-centralization-points/best-practices.md).
src/streaming/README.md
+192
-516
@@ -1,553 +1,247 @@
1
-# Streaming and replication reference
1
+# Streaming and Replication Reference
2
3
-This document contains advanced streaming options and suggested deployment options for production.
4
-If you haven't already done so, we suggest you first go through the
5
-[quick introduction to streaming](/docs/observability-centralization-points/README.md)
6
-, for your first, basic parent child setup.
3
+This guide covers advanced streaming options and recommended deployment strategies for production environments. If you're new to Netdata streaming, start with the [quick introduction to streaming](/docs/observability-centralization-points/README.md) to set up a basic parent-child configuration.
4
8
-## Configuration
5
+## Configuration Overview
6
10
-There are two files responsible for configuring Netdata's streaming capabilities: `stream.conf` and `netdata.conf`.
7
+Netdata's streaming capabilities are configured through two key files:
8
12
-From within your Netdata config directory (typically `/etc/netdata`), [use `edit-config`](/docs/netdata-agent/configuration/README.md) to
13
-open either `stream.conf` or `netdata.conf`.
9
+- **`stream.conf`** – Controls streaming behavior, including parent and child configurations.
10
+- **`netdata.conf`** – Contains global settings that can impact streaming.
11
15
-```
12
+To edit these files, navigate to your Netdata configuration directory (typically `/etc/netdata`) and run:
13
+
14
+```sh
15
sudo ./edit-config stream.conf
16
sudo ./edit-config netdata.conf
17
```
18
20
-### `stream.conf`
21
-
22
-The `stream.conf` file contains three sections. The `[stream]` section is for configuring child nodes.
23
-
24
-The `[API_KEY]` and `[MACHINE_GUID]` sections are both for configuring parent nodes, and share the same settings.
25
-`[API_KEY]` settings affect every child node using that key, whereas `[MACHINE_GUID]` settings affect only the child
26
-node with a matching GUID.
27
-
28
-The file `/var/lib/netdata/registry/netdata.public.unique.id` contains a random GUID that **uniquely identifies each
29
-node**. This file is automatically generated by Netdata the first time it is started and remains unaltered forever.
30
-
31
-#### `[stream]` section
32
-
33
-This section is used by the sending Netdata.
34
-
35
-| Setting | Default | Description |
36
-|-------------------------------------------------|---------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
37
-| `enabled` | `no` | Whether this node streams metrics to any parent. Change to `yes` to enable streaming. |
38
-| [`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 →](#destination) |
39
-| `ssl skip certificate verification` | `yes` | If you want to accept self-signed or expired certificates, set to `yes` and uncomment. |
40
-| `CApath` | `/etc/ssl/certs/` | The directory where known certificates are found. Defaults to OpenSSL's default path. |
41
-| `CAfile` | `/etc/ssl/certs/cert.pem` | Add a parent node certificate to the list of known certificates in `CAPath`. |
42
-| `api key` | | The `API_KEY` to use as the child node. |
43
-| `timeout` | `1m` | The timeout to connect and send metrics to a parent. |
44
-| `default port` | `19999` | The port to use if `destination` does not specify one. |
45
-| [`send charts matching`](#send-charts-matching) | `*` | A space-separated list of [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md) to filter which charts are streamed. [Read more →](#send-charts-matching) |
46
-| `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. |
47
-| `reconnect delay` | `5s` | How long to wait until retrying to connect to the parent node. |
48
-| `initial clock resync iterations` | `60` | Sync the clock of charts for how many seconds when starting. |
49
-| `parent using h2o` | `no` | Set to yes if you are connecting to parent trough it's h2o webserver/port. Currently there is no reason to set this to `yes` unless you are testing the new h2o based netdata webserver. When production ready this will be set to `yes` as default. |
50
-
51
-### `[API_KEY]` sections
52
-
53
-This section defines an API key for other Agents to connect to this Netdata.
54
-
55
-| Setting | Default | Description |
56
-|------------------------------|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
57
-| `enabled` | `no` | Whether this API KEY enabled or disabled. |
58
-| `type` | `api` | This section defines an API key. |
59
-| [`allow from`](#allow-from) | `*` | A space-separated list of [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md) matching the IPs of nodes that will stream metrics using this API key. [Read more →](#allow-from) |
60
-| `retention` | `1h` | The default amount of child metrics history to retain when using the `ram` db. |
61
-| [`db`](#default-memory-mode) | `dbengine` | The [database](/src/database/README.md) to use for all nodes using this `API_KEY`. Valid settings are `dbengine`, `ram`, or `none`. [Read more →](#default-memory-mode) |
62
-| `health enabled` | `auto` | Whether alerts and notifications should be enabled for nodes using this `API_KEY`. `auto` enables alerts when the child is connected. `yes` enables alerts always, and `no` disables alerts. |
63
-| `postpone alerts on connect` | `1m` | Postpone alerts and notifications for a period of time after the child connects. |
64
-| `health log retention` | `5d` | History of health log events (in seconds) kept in the database. |
65
-| `proxy enabled` | | Route metrics through a proxy. |
66
-| `proxy destination` | | Space-separated list of `IP:PORT` for proxies. |
67
-| `proxy api key` | | The `API_KEY` of the proxy. |
68
-| `send charts matching` | `*` | See [`send charts matching`](#send-charts-matching). |
69
-| `enable compression` | `yes` | Enable/disable stream compression. |
70
-| `enable replication` | `yes` | Enable/disable replication. |
71
-| `replication period` | `1d` | Limits the maximum window that will be replicated from each child. |
72
-| `replication step` | `10m` | The duration we want to replicate per each replication step. |
73
-| `is ephemeral node` | `no` | Indicate whether this child is an ephemeral node. An ephemeral node will become unavailable after the specified duration of "cleanup ephemeral hosts after" from the time of the node's last connection. |
74
-
75
-
76
-### `[MACHINE_GUID]` sections
77
-
78
-This section is about customizing configuration for specific Agents. It allows many Agents to share the same API key, while providing customizability per remote Agent.
79
-
80
-| Setting | Default | Description |
81
-|------------------------------|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
82
-| `enabled` | `no` | Whether this MACHINE_GUID enabled or disabled. |
83
-| `type` | `machine` | This section defines the configuration for a specific Agent. |
84
-| [`allow from`](#allow-from) | `*` | A space-separated list of [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md) matching the IPs of nodes that will stream metrics using this API key. [Read more →](#allow-from) |
85
-| `retention` | `3600` | The default amount of child metrics history to retain when using the `ram` db. |
86
-| [`db`](#default-memory-mode) | `dbengine` | The [database](/src/database/README.md) to use for all nodes using this `API_KEY`. Valid settings are `dbengine`, `ram`, or `none`. [Read more →](#default-memory-mode) |
87
-| `health enabled` | `auto` | Whether alerts and notifications should be enabled for nodes using this `API_KEY`. `auto` enables alerts when the child is connected. `yes` enables alerts always, and `no` disables alerts. |
88
-| `postpone alerts on connect` | `1m` | Postpone alerts and notifications for a period of time after the child connects. |
89
-| `health log retention` | `5d` | History of health log events (in seconds) kept in the database. |
90
-| `proxy enabled` | | Route metrics through a proxy. |
91
-| `proxy destination` | | Space-separated list of `IP:PORT` for proxies. |
92
-| `proxy api key` | | The `API_KEY` of the proxy. |
93
-| `send charts matching` | `*` | See [`send charts matching`](#send-charts-matching). |
94
-| `enable compression` | `yes` | Enable/disable stream compression. |
95
-| `enable replication` | `yes` | Enable/disable replication. |
96
-| `replication period` | `1d` | Limits the maximum window that will be replicated from each child. |
97
-| `replication step` | `10m` | The duration we want to replicate per each replication step. |
98
-| `is ephemeral node` | `no` | Indicate whether this child is an ephemeral node. An ephemeral node will become unavailable after the specified duration of "cleanup ephemeral hosts after" from the time of the node's last connection. |
99
-
100
-#### `destination`
101
-
102
-A space-separated list of parent nodes to attempt to stream to, with the first available parent receiving metrics, using
103
-the following format: `[PROTOCOL:]HOST[%INTERFACE][:PORT][:SSL]`.
104
-
105
-- `PROTOCOL`: `tcp`, `udp`, or `unix`. (only tcp and unix are supported by parent nodes)
106
-- `HOST`: A IPv4, IPv6 IP, or a hostname, or a unix domain socket path. IPv6 IPs should be given with brackets
107
- `[ip:address]`.
108
-- `INTERFACE` (IPv6 only): The network interface to use.
109
-- `PORT`: The port number or service name (`/etc/services`) to use.
110
-- `SSL`: To enable TLS/SSL encryption of the streaming connection.
111
-
112
-To enable TCP streaming to a parent node at `203.0.113.0` on port `20000` and with TLS/SSL encryption:
113
-
114
-```text
115
-[stream]
116
- destination = tcp:203.0.113.0:20000:SSL
117
-```
118
-
119
-#### `send charts matching`
120
-
121
-A space-separated list of [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md) to filter which charts are streamed.
19
+## Configuring `stream.conf`
20
+
21
+The `stream.conf` file has three main sections:
22
+
23
+- **`[stream]`** – Configures child nodes.
24
+- **`[API_KEY]`** – Defines settings for all child nodes using the same API key.
25
+- **`[MACHINE_GUID]`** – Sets configurations for a specific child node matching the given GUID.
26
123
-The default is a single wildcard `*`, which streams all charts.
27
+### Identifying a Node's GUID
28
125
-To send only a few charts, list them explicitly, or list a group using a wildcard. To send _only_ the `apps.cpu` chart
126
-and charts with contexts beginning with `system.`:
29
+Each Netdata node has a unique identifier stored in:
30
128
-```text
129
-[stream]
130
- send charts matching = apps.cpu system.*
131
-```
132
-
133
-To send all but a few charts, use `!` to create a negative match. To send _all_ charts _but_ `apps.cpu`:
134
-
135
-```text
136
-[stream]
137
- send charts matching = !apps.cpu *
138
-```
139
-
140
-#### `allow from`
141
-
142
-A space-separated list of [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md) matching the IPs of nodes that
143
-will stream metrics using this API key. The order is important, left to right, as the first positive or negative match is used.
144
-
145
-The default is `*`, which accepts all requests including the `API_KEY`.
146
-
147
-To allow from only a specific IP address:
148
-
149
-```text
150
-[API_KEY]
151
- allow from = 203.0.113.10
152
-```
153
-
154
-To allow all IPs starting with `10.*`, except `10.1.2.3`:
155
-
156
-```text
157
-[API_KEY]
158
- allow from = !10.1.2.3 10.*
31
+```sh
32
+/var/lib/netdata/registry/netdata.public.unique.id
33
```
34
161
-> If you set specific IP addresses here, and also use the `allow connections` setting in the `[web]` section of
162
-> `netdata.conf`, be sure to add the IP address there so that it can access the API port.
163
-
164
-#### `db`
165
-
166
-The [database](/src/database/README.md) to use for all nodes using this `API_KEY`.
167
-Valid settings are `dbengine`, `ram`, , or `none`.
168
-
169
-- `dbengine`: The default, recommended time-series database (TSDB) for Netdata. Stores recent metrics in memory, then
170
- efficiently spills them to disk for long-term storage.
171
-- `ram`: Stores metrics _only_ in memory, which means metrics are lost when Netdata stops or restarts. Ideal for
172
- streaming configurations that use ephemeral nodes.
173
-- `none`: No database.
174
-
175
-### `netdata.conf`
176
-
177
-| Setting | Default | Description |
178
-|------------------------------------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
179
-| `[db]` section | | |
180
-| `mode` | `dbengine` | Determines the [database type](/src/database/README.md) to be used on that node. Other options settings include `none`, and `ram`. `none` disables the database at this host. This also disables alerts and notifications, as those can't run without a database. |
181
-| `[web]` section | | |
182
-| `mode` | `static-threaded` | Determines the [web server](/src/web/server/README.md) type. The other option is `none`, which disables the dashboard, API, and Registry. |
183
-| `accept a streaming request every` | `off` | 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`. |
184
-
185
-### Basic use cases
186
-
187
-This is an overview of how the main options can be combined:
188
-
189
-| target | memory<br/>mode | web<br/>mode | stream<br/>enabled | exporting | alerts | dashboard |
190
-|--------------------|:---------------:|:------------:|:------------------:|:-------------------------------------:|:------------:|:---------:|
191
-| headless collector | `none` | `none` | `yes` | only for `data source = as collected` | not possible | no |
192
-| headless proxy | `none` | not `none` | `yes` | only for `data source = as collected` | not possible | no |
193
-| proxy with db | not `none` | not `none` | `yes` | possible | possible | yes |
194
-| central netdata | not `none` | not `none` | `no` | possible | possible | yes |
195
-
196
-### Per-child settings
197
-
198
-While the `[API_KEY]` section applies settings for any child node using that key, you can also use per-child settings
199
-with the `[MACHINE_GUID]` section.
200
-
201
-For example, the metrics streamed from only the child node with `MACHINE_GUID` are saved in memory, not using the
202
-default `dbengine` as specified by the `API_KEY`, and alerts are disabled.
203
-
204
-```text
205
-[API_KEY]
206
- enabled = yes
207
- db = dbengine
208
- health enabled = auto
209
- allow from = *
210
-
211
-[MACHINE_GUID]
212
- enabled = yes
213
- db = ram
214
- health enabled = no
215
-```
216
-
217
-### Streaming compression
218
-
219
-[](https://github.com/netdata/netdata/releases/latest)
220
-
221
-[](https://github.com/netdata/netdata/releases/latest)
222
-
223
-#### OS dependencies
224
-* Streaming compression is based on [lz4 v1.9.0+](https://github.com/lz4/lz4). The [lz4 v1.9.0+](https://github.com/lz4/lz4) library must be installed in your OS in order to enable streaming compression. Any lower version will disable Netdata streaming compression for compatibility purposes between the older versions of Netdata Agents.
225
-
226
-To check if your Netdata Agent supports stream compression run the following GET request in your browser or terminal:
227
-
228
-```
229
-curl -X GET http://localhost:19999/api/v1/info | grep 'Stream Compression'
230
-```
231
-
232
-**Output**
233
-```
234
-"buildinfo": "dbengine|Native HTTPS|Netdata Cloud|ACLK Next Generation|New Cloud Protocol Support|ACLK Legacy|TLS Host Verification|Machine Learning|Stream Compression|protobuf|JSON-C|libcrypto|libm|LWS v3.2.2|mosquitto|zlib|apps|cgroup Network Tracking|EBPF|perf|slabinfo",
235
-```
236
-> Note: If your OS doesn't support Netdata compression the `buildinfo` will not contain the `Stream Compression` statement.
237
-
238
-To check if your Netdata Agent has stream compression enabled, run the following GET request in your browser or terminal:
239
-
240
-```
241
- curl -X GET http://localhost:19999/api/v1/info | grep 'stream-compression'
242
-```
243
-**Output**
244
-```
245
-"stream-compression": "enabled"
246
-```
247
-Note: The `stream-compression` status can be `"enabled" | "disabled" | "N/A"`.
35
+This file is generated automatically the first time Netdata starts and remains unchanged.
36
249
-A compressed data packet is determined and decompressed on the fly.
37
+## Recommended Deployment Strategies
38
251
-#### Limitations
252
-This limitation will be withdrawn asap and is work-in-progress.
39
+For a production-ready streaming setup, consider the following best practices:
40
254
-The current implementation of streaming data compression can support only a few number of dimensions in a chart with names that cannot exceed the size of 16384 bytes. In case your instance hit this limitation, the Agent will deactivate compression during runtime to avoid stream corruption. This limitation can be seen in the error.log file with the sequence of the following messages:
255
-```
256
-netdata INFO : STREAM_SENDER[child01] : STREAM child01 [send to my.parent.IP]: connecting...
257
-netdata INFO : STREAM_SENDER[child01] : STREAM child01 [send to my.parent.IP]: initializing communication...
258
-netdata INFO : STREAM_SENDER[child01] : STREAM child01 [send to my.parent.IP]: waiting response from remote netdata...
259
-netdata INFO : STREAM_SENDER[child01] : STREAM_COMPRESSION: Compressor Reset
260
-netdata INFO : STREAM_SENDER[child01] : STREAM child01 [send to my.parent.IP]: established communication with a parent using protocol version 5 - ready to send metrics...
261
-...
262
-netdata ERROR : PLUGINSD[go.d] : STREAM_COMPRESSION: Compression Failed - Message size 27847 above compression buffer limit: 16384 (errno 9, Bad file descriptor)
263
-netdata ERROR : PLUGINSD[go.d] : STREAM_COMPRESSION: Deactivating compression to avoid stream corruption
264
-netdata ERROR : PLUGINSD[go.d] : STREAM_COMPRESSION child01 [send to my.parent.IP]: Restarting connection without compression
265
-...
266
-netdata INFO : STREAM_SENDER[child01] : STREAM child01 [send to my.parent.IP]: connecting...
267
-netdata INFO : STREAM_SENDER[child01] : STREAM child01 [send to my.parent.IP]: initializing communication...
268
-netdata INFO : STREAM_SENDER[child01] : STREAM child01 [send to my.parent.IP]: waiting response from remote netdata...
269
-netdata INFO : STREAM_SENDER[child01] : Stream is uncompressed! One of the Agents (my.parent.IP <-> child01) does not support compression OR compression is disabled.
270
-netdata INFO : STREAM_SENDER[child01] : STREAM child01 [send to my.parent.IP]: established communication with a parent using protocol version 4 - ready to send metrics...
271
-netdata INFO : WEB_SERVER[static4] : STREAM child01 [send]: sending metrics...
272
-```
41
+- **Use Multiple Parent Nodes** – Ensures redundancy and improves resilience.
42
+- **Optimize Data Retention** – Configure retention periods to balance storage costs and data availability.
43
+- **Secure Communications** – Enable encryption and authentication to protect data streams.
44
+- **Monitor Performance** – Regularly review logs and metrics to ensure efficient streaming operations.
45
274
-#### How to enable stream compression
275
-Netdata Agents are shipped with data compression enabled by default. You can also configure which streams will use compression.
46
+By following these guidelines, you can set up a scalable and reliable Netdata streaming environment.
47
277
-With enabled stream compression, a Netdata Agent can negotiate streaming compression with other Netdata Agents. During the negotiation of streaming compression both Netdata Agents should support and enable compression in order to communicate over a compressed stream. The negotiation will result into an uncompressed stream, if one of the Netdata Agents doesn't support **or** has compression disabled.
48
+## `stream.conf`
49
279
-To enable stream compression:
50
+The `stream.conf` file consists of three main sections:
51
281
-1. Edit `stream.conf` by using the `edit-config` script:
282
-`/etc/netdata/edit-config stream.conf`.
52
+1. **`[stream]`** – Configures child nodes (data senders).
53
+2. **`[API_KEY]`** – Defines API keys for parent nodes (data receivers).
54
+3. **`[MACHINE_GUID]`** – Customizes settings for specific child nodes.
55
284
-2. In the `[stream]` section, set `enable compression` to `yes`.
285
-```
286
-# This is the default stream compression flag for an Agent.
56
+### `[stream]` Section (Child Node Settings)
57
288
-[stream]
289
- enable compression = yes | no
290
-```
58
+This section configures a child node to send metrics to a parent.
59
60
+| Setting | Default | Description |
61
+|-------------------------------------------------|---------------------------|---------------------------------------------------------------------|
62
+| `enabled` | `no` | Enables streaming. Set to `yes` to allow this node to send metrics. |
63
+| [`destination`](#destination) | (empty) | Defines one or more parent nodes to send data to. |
64
+| `ssl skip certificate verification` | `yes` | Accepts self-signed or expired SSL certificates. |
65
+| `CApath` | `/etc/ssl/certs/` | Directory for trusted SSL certificates. |
66
+| `CAfile` | `/etc/ssl/certs/cert.pem` | File containing trusted certificates. |
67
+| `api key` | (empty) | API key used by the child to authenticate with the parent. |
68
+| `timeout` | `1m` | Connection timeout duration. |
69
+| `default port` | `19999` | Default port for streaming if not specified in `destination`. |
70
+| [`send charts matching`](#send-charts-matching) | `*` | Filters which charts are streamed. |
71
+| `buffer size bytes` | `10485760` | Buffer size (10MB by default). Increase for higher latencies. |
72
+| `reconnect delay` | `5s` | Time before retrying connection to the parent. |
73
+| `initial clock resync iterations` | `60` | Syncs chart clocks during startup. |
74
+| `parent using h2o` | `no` | Set to `yes` if connecting to a parent using the H2O web server. |
75
293
-| Parent | Stream compression | Child |
294
-|--------------------------------------|--------------------|--------------------------------------|
295
-| Supported & Enabled | compressed | Supported & Enabled |
296
-| (Supported & Disabled)/Not supported | uncompressed | Supported & Enabled |
297
-| Supported & Enabled | uncompressed | (Supported & Disabled)/Not supported |
298
-| (Supported & Disabled)/Not supported | uncompressed | (Supported & Disabled)/Not supported |
76
+### `[API_KEY]` Section (Parent Node Authentication)
77
300
-In case of parents with multiple children you can select which streams will be compressed by using the same configuration under the `[API_KEY]`, `[MACHINE_GUID]` section.
78
+This section allows parent nodes to accept streaming data from child nodes using an API key.
79
302
-This configuration uses AND logic with the default stream compression configuration under the `[stream]` section. This means the stream compression from child to parent will be enabled only if the outcome of the AND logic operation is true (`default compression enabled` && `api key compression enabled`). So both should be enabled to get stream compression otherwise stream compression is disabled.
303
-```
304
-[API_KEY]
305
- enable compression = yes | no
306
-```
307
-Same thing applies with the `[MACHINE_GUID]` configuration.
308
-```
309
-[MACHINE_GUID]
310
- enable compression = yes | no
311
-```
80
+| Setting | Default | Description |
81
+|------------------------------|------------|-------------------------------------------------------------|
82
+| `enabled` | `no` | Enables or disables this API key. |
83
+| `type` | `api` | Defines the section as an API key configuration. |
84
+| [`allow from`](#allow-from) | `*` | Specifies which child nodes (IP addresses) can connect. |
85
+| `retention` | `1h` | How long to keep child node metrics in RAM-based storage. |
86
+| [`db`](#db) | `dbengine` | Specifies the database type for this API key. |
87
+| `health enabled` | `auto` | Controls alerts and notifications (`auto`, `yes`, or `no`). |
88
+| `postpone alerts on connect` | `1m` | Delay alerts for a period after the child connects. |
89
+| `health log retention` | `5d` | Duration (in seconds) to keep health log events. |
90
+| `proxy enabled` | (empty) | Enables routing metrics through a proxy. |
91
+| `proxy destination` | (empty) | IP and port of the proxy server. |
92
+| `proxy api key` | (empty) | API key for the proxy server. |
93
+| `send charts matching` | `*` | Defines which charts to stream. |
94
+| `enable compression` | `yes` | Enables or disables data compression. |
95
+| `enable replication` | `yes` | Enables or disables data replication. |
96
+| `replication period` | `1d` | Maximum time window replicated from each child. |
97
+| `replication step` | `10m` | Time interval for each replication step. |
98
+| `is ephemeral node` | `no` | Marks the child as ephemeral (removes it after inactivity). |
99
313
-### Securing streaming with TLS/SSL
100
+### `[MACHINE_GUID]` Section (Per-Node Customization)
101
315
-Netdata does not activate TLS encryption by default. To encrypt streaming connections, you first need to [enable TLS
316
-support](/src/web/server/README.md#enabling-tls-support) on the parent. With encryption enabled on the receiving side, you
317
-need to instruct the child to use TLS/SSL as well. On the child's `stream.conf`, configure the destination as follows:
102
+This section customizes settings for specific child nodes using their unique Machine GUID.
103
319
-```
320
-[stream]
321
- destination = host:port:SSL
322
-```
104
+| Setting | Default | Description |
105
+|------------------------------|------------|----------------------------------------------------------|
106
+| `enabled` | `no` | Enables or disables this specific node’s configuration. |
107
+| `type` | `machine` | Defines the section as a machine-specific configuration. |
108
+| [`allow from`](#allow-from) | `*` | Lists IP addresses allowed to stream metrics. |
109
+| `retention` | `3600` | Retention period for child metrics in RAM-based storage. |
110
+| [`db`](#db) | `dbengine` | Database type for this node. |
111
+| `health enabled` | `auto` | Controls alerts (`auto`, `yes`, `no`). |
112
+| `postpone alerts on connect` | `1m` | Delay alerts for a period after connection. |
113
+| `health log retention` | `5d` | Duration to keep health log events. |
114
+| `proxy enabled` | (empty) | Routes metrics through a proxy if enabled. |
115
+| `proxy destination` | (empty) | Proxy server IP and port. |
116
+| `proxy api key` | (empty) | API key for the proxy. |
117
+| `send charts matching` | `*` | Filters streamed charts. |
118
+| `enable compression` | `yes` | Enables or disables compression. |
119
+| `enable replication` | `yes` | Enables or disables replication. |
120
+| `replication period` | `1d` | Maximum replication window. |
121
+| `replication step` | `10m` | Time interval for each replication step. |
122
+| `is ephemeral node` | `no` | Marks the node as ephemeral (removes after inactivity). |
123
+
124
+### Additional Settings
125
324
-The word `SSL` appended to the end of the destination tells the child that connections must be encrypted.
126
+#### `destination`
127
326
-> While Netdata uses Transport Layer Security (TLS) 1.2 to encrypt communications rather than the obsolete SSL protocol,
327
-> it's still common practice to refer to encrypted web connections as `SSL`. Many vendors, like Nginx and even Netdata
328
-> itself, use `SSL` in configuration files, whereas documentation will always refer to encrypted communications as `TLS`
329
-> or `TLS/SSL`.
128
+Defines parent nodes for streaming using the format:
129
+`[PROTOCOL:]HOST[%INTERFACE][:PORT][:SSL]`
130
331
-#### Certificate verification
131
+- **PROTOCOL**: `tcp`, `udp`, or `unix` (only `tcp` and `unix` are supported for parents).
132
+- **HOST**: IPv4, IPv6 (in brackets `[ ]`), hostname, or Unix domain socket path.
133
+- **INTERFACE** (IPv6 only): Network interface to use.
134
+- **PORT**: Port number or service name.
135
+- **SSL**: Enables TLS/SSL encryption.
136
333
-When TLS/SSL is enabled on the child, the default behavior will be to not connect with the parent unless the server's
334
-certificate can be verified via the default chain. In case you want to avoid this check, add the following to the
335
-child's `stream.conf` file:
137
+Example (TCP connection with SSL to `203.0.113.0` on port `20000`):
138
337
-```
139
+```ini
140
[stream]
339
- ssl skip certificate verification = yes
340
-```
341
-
342
-#### Trusted certificate
343
-
344
-If you've enabled [certificate verification](#certificate-verification), you might see errors from the OpenSSL library
345
-when there's a problem with checking the certificate chain (`X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY`). More
346
-importantly, OpenSSL will reject self-signed certificates.
347
-
348
-Given these known issues, you have two options. If you trust your certificate, you can set the options `CApath` and
349
-`CAfile` to inform Netdata where your certificates, and the certificate trusted file, are stored.
350
-
351
-For more details about these options, you can read about [verify
352
-locations](https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_load_verify_locations.html).
353
-
354
-Before you changed your streaming configuration, you need to copy your trusted certificate to your child system and add
355
-the certificate to OpenSSL's list.
356
-
357
-On most Linux distributions, the `update-ca-certificates` command searches inside the `/usr/share/ca-certificates`
358
-directory for certificates. You should double-check by reading the `update-ca-certificate` manual (`man
359
-update-ca-certificate`), and then change the directory in the below commands if needed.
360
-
361
-If you have `sudo` configured on your child system, you can use that to run the following commands. If not, you'll have
362
-to log in as `root` to complete them.
363
-
364
-```
365
-# mkdir /usr/share/ca-certificates/netdata
366
-# cp parent_cert.pem /usr/share/ca-certificates/netdata/parent_cert.crt
367
-# chown -R netdata.netdata /usr/share/ca-certificates/netdata/
368
-```
369
-
370
-First, you create a new directory to store your certificates for Netdata. Next, you need to change the extension on your
371
-certificate from `.pem` to `.crt` so it's compatible with `update-ca-certificate`. Finally, you need to change
372
-permissions so the user that runs Netdata can access the directory where you copied in your certificate.
373
-
374
-Next, edit the file `/etc/ca-certificates.conf` and add the following line:
375
-
376
-```
377
-netdata/parent_cert.crt
141
+ destination = tcp:203.0.113.0:20000:SSL
142
```
143
380
-Now you update the list of certificates running the following, again either as `sudo` or `root`:
144
+#### `send charts matching`
145
382
-```
383
-# update-ca-certificates
384
-```
146
+Controls which charts are streamed.
147
386
-> Some Linux distributions have different methods of updating the certificate list. For more details, please read this
387
-> guide on [adding trusted root certificates](https://github.com/Busindre/How-to-Add-trusted-root-certificates).
148
+- `*` (default) – Streams all charts.
149
+- Specific charts:
150
389
-Once you update your certificate list, you can set the stream parameters for Netdata to trust the parent certificate.
390
-Open `stream.conf` for editing and change the following lines:
151
+ ```ini
152
+ [stream]
153
+ send charts matching = apps.cpu system.*
154
+ ```
155
392
-```
393
-[stream]
394
- CApath = /etc/ssl/certs/
395
- CAfile = /etc/ssl/certs/parent_cert.pem
396
-```
156
+- Exclude charts using `!`:
157
398
-With this configuration, the `CApath` option tells Netdata to search for trusted certificates inside `/etc/ssl/certs`.
399
-The `CAfile` option specifies the Netdata parent certificate is located at `/etc/ssl/certs/parent_cert.pem`. With this
400
-configuration, you can skip using the system's entire list of certificates and use Netdata's parent certificate instead.
158
+ ```ini
159
+ [stream]
160
+ send charts matching = !apps.cpu *
161
+ ```
162
402
-#### Expected behaviors
163
+#### `allow from`
164
404
-With the introduction of TLS/SSL, the parent-child communication behaves as shown in the table below, depending on the
405
-following configurations:
165
+Defines which child nodes (by IP) can connect.
166
407
-- **Parent TLS (Yes/No)**: Whether the `[web]` section in `netdata.conf` has `ssl key` and `ssl certificate`.
408
-- **Parent port TLS (-/force/optional)**: Depends on whether the `[web]` section `bind to` contains a `^SSL=force` or
409
- `^SSL=optional` directive on the port(s) used for streaming.
410
-- **Child TLS (Yes/No)**: Whether the destination in the child's `stream.conf` has `:SSL` at the end.
411
-- **Child TLS Verification (yes/no)**: Value of the child's `stream.conf` `ssl skip certificate verification`
412
- parameter (default is no).
167
+- Allow a single IP:
168
414
-| Parent TLS enabled | Parent port SSL | Child TLS | Child SSL Ver. | Behavior |
415
-|:-------------------|:-----------------|:----------|:---------------|:-----------------------------------------------------------------------------------------------------------------------------------------|
416
-| No | - | No | no | Legacy behavior. The parent-child stream is unencrypted. |
417
-| Yes | force | No | no | The parent rejects the child connection. |
418
-| Yes | -/optional | No | no | The parent-child stream is unencrypted (expected situation for legacy child nodes and newer parent nodes) |
419
-| 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. |
420
-| Yes | -/force/optional | Yes | yes | The parent-child stream is encrypted. |
169
+ ```ini
170
+ [API_KEY]
171
+ allow from = 203.0.113.10
172
+ ```
173
422
-### Proxy
174
+- Allow a range but exclude one:
175
424
-A proxy is a node that receives metrics from a child, then streams them onward to a parent. To configure a proxy,
425
-configure it as a receiving and a sending Netdata at the same time.
176
+ ```ini
177
+ [API_KEY]
178
+ allow from = !10.1.2.3 10.*
179
+ ```
180
427
-Netdata proxies may or may not maintain a database for the metrics passing through them. When they maintain a database,
428
-they can also run health checks (alerts and notifications) for the remote host that is streaming the metrics.
181
+#### `db`
182
430
-In the following example, the proxy receives metrics from a child node using the `API_KEY` of
431
-`66666666-7777-8888-9999-000000000000`, then stores metrics using `dbengine`. It then uses the `API_KEY` of
432
-`11111111-2222-3333-4444-555555555555` to proxy those same metrics on to a parent node at `203.0.113.0`.
183
+Defines the database mode:
184
434
-```text
435
-[stream]
436
- enabled = yes
437
- destination = 203.0.113.0
438
- api key = 11111111-2222-3333-4444-555555555555
185
+- `dbengine` – Stores recent metrics in RAM and writes older data to disk.
186
+- `ram` – Stores metrics only in RAM (lost on restart).
187
+- `none` – No database.
188
440
-[66666666-7777-8888-9999-000000000000]
441
- enabled = yes
189
+```ini
190
+[API_KEY]
191
db = dbengine
192
```
193
445
-### Ephemeral nodes
446
-
447
-Netdata can help you monitor ephemeral nodes, such as containers in an auto-scaling infrastructure, by always streaming
448
-metrics to any number of permanently-running parent nodes.
449
-
450
-On the parent, set the following in `stream.conf`:
451
-
452
-```text
453
-[11111111-2222-3333-4444-555555555555]
454
- # enable/disable this API key
455
- enabled = yes
456
-
457
- # one hour of data for each of the child nodes
458
- history = 1h
459
-
460
- # do not save child metrics on disk
461
- default memory = ram
462
-
463
- # alerts checks, only while the child is connected
464
- health enabled = auto
465
-```
466
-
467
-On the child nodes, set the following in `stream.conf`:
194
+Here’s an optimized version of the `netdata.conf` structure with clearer, more direct language. I've broken down the key sections for readability and made the content less dense:
195
469
-```bash
470
-[stream]
471
- # stream metrics to another Netdata
472
- enabled = yes
196
+## `netdata.conf`
197
474
- # the IP and PORT of the parent
475
- destination = 10.11.12.13:19999
198
+The `netdata.conf` file is the primary configuration file for the Netdata agent. It controls the agent’s settings, including networking, data collection, logging, and resource usage.
199
477
- # the API key to use
478
- api key = 11111111-2222-3333-4444-555555555555
479
-```
200
+### Sections
201
481
-In addition, edit `netdata.conf` on each child node to disable the database and alerts.
202
+#### [global]
203
483
-```bash
484
-[db]
485
- # disable the local database
486
- db = none
204
+This section defines global settings for the Netdata agent.
205
488
-[health]
489
- # disable health checks
490
- enabled = no
491
-```
206
+- **hostname**: The hostname used by the agent.
207
+- **memory mode**: Choose the memory mode for data collection (e.g., `ram` or `swap`).
208
+- **error log file**: Path to the file where error logs are saved.
209
493
-## Replication
210
+#### [web]
211
495
-Netdata streaming automatically replicates data from child nodes to parent nodes, ensuring that the parent node has a complete and up-to-date view of all metrics.
496
-This replication process ensures data continuity even if child nodes temporarily disconnect.
212
+Configure the web interface settings here.
213
498
-Replication is enabled by default in Netdata, but you can customize the replication behavior by modifying the `[API_KEY]` section of the `stream.conf` file. Here's an example configuration:
214
+- **bind to**: Define the network address to which Netdata binds.
215
+- **port**: Set the port for the web interface (default: 19999).
216
+- **disable SSL**: Set to `yes` to disable SSL support.
217
500
-```text
501
-[11111111-2222-3333-4444-555555555555]
502
- # Enable replication for all hosts using this api key. Default: yes.
503
- enable replication = yes
218
+#### [plugin]
219
505
- # How many seconds of data to replicate from each child at a time. Default: a day.
506
- replication period = 1d
220
+This section configures individual plugins for data collection.
221
508
- # The duration we want to replicate per each replication step. Default: 10 minutes.
509
- replication step = 10m
510
-```
222
+- **enabled**: Enable or disable the plugin.
223
+- **update every**: Define the update frequency (in seconds).
224
512
-You can monitor the replication process in two ways:
225
+#### [database]
226
514
-1. **Netdata Monitoring**: access the Netdata Monitoring section and look for the Replication charts.
515
-2. **Streaming Function**: use the Streaming function (Top) to see the replication status of children nodes. This function provides real-time insights into the replication status of each child node.
227
+Manage database settings for data storage and retention.
228
517
-### Replication history
229
+- **memory mode**: Choose between in-memory or disk-based storage.
230
+- **data retention**: Set how long to keep historical data.
231
+- **compression**: Enable or disable data compression.
232
519
-Replication history in [dbengine](/src/database/README.md#modes) mode is limited
520
-by [Tier 0 retention](/src/database/README.md#tiers):
233
+#### [logging]
234
522
-- Child instances replicate only Tier 0 data.
523
-- Parent instance calculates higher-level tiers using Tier 0 as the basis.
235
+Configure logging behavior for Netdata.
236
525
-Extend replication history by increasing Tier 0 retention.
526
-
527
-Checking Tier 0 retention:
528
-
529
-- Using a web browser:
530
- - Navigate to `http://{CHILD_IP}:19999/api/v2/node_instances`.
531
- - Locate the `expected_retention` value for Tier 0 of your Agent.
532
- - Convert the value from seconds to days for a more meaningful representation.
533
-- Using `curl` and `jq`:
534
- - Execute the following command:
535
- ```bash
536
- $ curl -s "http://{CHILD_IP}:19999/api/v2/node_instances" | jq '.agents[] | {nm, retention: (.db_size[0].retention / 86400 | .*100 | round/100) }'
537
- ```
538
- - Example output:
539
- ```json
540
- {
541
- "nm": "myhost",
542
- "retention": 12.73
543
- }
544
- ```
237
+- **log file**: Define the log file location.
238
+- **log level**: Set the verbosity of logs (e.g., `info`, `debug`).
239
240
## Troubleshooting
241
548
-Both parent and child nodes log information at `/var/log/netdata/error.log`.
242
+Both parent and child nodes log information in `/var/log/netdata/error.log`.
243
550
-If the child manages to connect to the parent you will see something like (on the parent):
244
+If the child successfully connects to the parent, you’ll see logs similar to the following on the parent:
245
246
```
247
2017-03-09 09:38:52: netdata: INFO : STREAM [receive from [10.11.12.86]:38564]: new client connection.
@@ -557,7 +251,7 @@ If the child manages to connect to the parent you will see something like (on th
251
2017-03-09 09:38:52: netdata: INFO : STREAM xxx [receive from [10.11.12.86]:38564]: receiving metrics...
252
```
253
560
-and something like this on the child:
254
+On the child side, you might see:
255
256
```
257
2017-03-09 09:38:28: netdata: INFO : STREAM xxx [send to box:19999]: connecting...
@@ -566,93 +260,75 @@ and something like this on the child:
260
2017-03-09 09:38:28: netdata: INFO : STREAM xxx [send to box:19999]: established communication - sending metrics...
261
```
262
569
-The following sections describe the most common issues you might encounter when connecting parent and child nodes.
263
+The following sections cover common issues when connecting parent and child nodes.
264
571
-### Slow connections between parent and child
265
+### Slow Connections Between Parent and Child
266
573
-When you have a slow connection between parent and child, Netdata raises a few different errors. Most of the
574
-errors will appear in the child's `error.log`.
267
+Slow connections may lead to several errors, mainly logged in the child’s `error.log`:
268
269
```bash
577
-netdata ERROR : STREAM_SENDER[CHILD HOSTNAME] : STREAM CHILD HOSTNAME [send to PARENT IP:PARENT PORT]: too many data pending - buffer is X bytes long,
578
-Y unsent - we have sent Z bytes in total, W on this connection. Closing connection to flush the data.
270
+netdata ERROR : STREAM_SENDER[CHILD HOSTNAME] : STREAM CHILD HOSTNAME [send to PARENT IP:PARENT PORT]: too many data pending - buffer is X bytes long, Y unsent - we have sent Z bytes in total, W on this connection. Closing connection to flush the data.
271
```
272
581
-On the parent side, you may see various error messages, most commonly the following:
273
+On the parent side, you might see:
274
275
```
276
netdata ERROR : STREAM_PARENT[CHILD HOSTNAME,[CHILD IP]:CHILD PORT] : read failed: end of file
277
```
278
587
-Another common problem in slow connections is the child sending a partial message to the parent. In this case, the
588
-parent will write the following to its `error.log`:
279
+Another issue in slow connections is the child sending partial messages to the parent. In this case, the parent will log:
280
281
```
282
ERROR : STREAM_RECEIVER[CHILD HOSTNAME,[CHILD IP]:CHILD PORT] : sent command 'B' which is not known by netdata, for host 'HOSTNAME'. Disabling it.
283
```
284
594
-In this example, `B` was part of a `BEGIN` message that was cut due to connection problems.
595
-
596
-Slow connections can also cause problems when the parent misses a message and then receives a command related to the
597
-missed message. For example, a parent might miss a message containing the child's charts, and then doesn't know
598
-what to do with the `SET` message that follows. When that happens, the parent will show a message like this:
285
+Slow connections can also cause the parent to miss a message. For example, if the parent misses a message about the child’s charts and then receives a `SET` command for a chart, the parent might log:
286
287
```
288
ERROR : STREAM_RECEIVER[CHILD HOSTNAME,[CHILD IP]:CHILD PORT] : requested a SET on chart 'CHART NAME' of host 'HOSTNAME', without a dimension. Disabling it.
289
```
290
604
-### Child cannot connect to parent
291
+### Child Can’t Connect to Parent
292
606
-When the child can't connect to a parent for any reason (misconfiguration, networking, firewalls, parent
607
-down), you will see the following in the child's `error.log`.
293
+If the child can't connect to the parent (due to misconfiguration, networking issues, firewalls, or the parent being down), the child will log:
294
295
```
296
ERROR : STREAM_SENDER[HOSTNAME] : Failed to connect to 'PARENT IP', port 'PARENT PORT' (errno 113, No route to host)
297
```
298
613
-### 'Is this a Netdata?'
299
+### 'Is This a Netdata?'
300
615
-This question can appear when Netdata starts the stream and receives an unexpected response. This error can appear when
616
-the parent is using SSL and the child tries to connect using plain text. You will also see this message when
617
-Netdata connects to another server that isn't Netdata. The complete error message will look like this:
301
+This error typically occurs when the parent is using SSL and the child attempts a plain-text connection, or if the child tries to connect to a non-Netdata server. The error message looks like this:
302
303
```
304
ERROR : STREAM_SENDER[CHILD HOSTNAME] : STREAM child HOSTNAME [send to PARENT HOSTNAME:PARENT PORT]: server is not replying properly (is it a netdata?).
305
```
306
623
-### Stream charts wrong
307
+### Stream Charts Wrong
308
625
-Chart data needs to be consistent between child and parent nodes. If there are differences between chart data on
626
-a parent and a child, such as gaps in metrics collection, it most often means your child's `[db].db` setting
627
-does not match the parent's. To learn more about the different ways Netdata can store metrics, and thus keep chart
628
-data consistent, read our [db documentation](/src/database/README.md).
309
+If chart data is inconsistent between the parent and child (e.g., gaps in metrics collection), it likely indicates a mismatch in the `[db].db` settings between the parent and child. Refer to our [db documentation](/src/database/README.md) for more information on how Netdata stores metrics to ensure data consistency.
310
630
-### Forbidding access
311
+### Forbidding Access
312
632
-You may see errors about "forbidding access" for a number of reasons. It could be because of a slow connection between
633
-the parent and child nodes, but it could also be due to other failures. Look in your parent's `error.log` for errors
634
-that look like this:
313
+Access might be forbidden for several reasons, such as slow connections or other failures. Look for the following errors in the parent’s `error.log`:
314
315
```
316
STREAM [receive from [child HOSTNAME]:child IP]: `MESSAGE`. Forbidding access."
317
```
318
640
-`MESSAGE` will have one of the following patterns:
319
+Possible causes for this error include:
320
642
-- `request without KEY` : The message received is incomplete and the KEY value can be API, hostname, machine GUID.
643
-- `API key 'VALUE' is not valid GUID`: The UUID received from child does not have the format defined in [RFC
644
- 4122](https://tools.ietf.org/html/rfc4122)
645
-- `machine GUID 'VALUE' is not GUID.`: This error with machine GUID is like the previous one.
646
-- `API key 'VALUE' is not allowed`: This stream has a wrong API key.
647
-- `API key 'VALUE' is not permitted from this IP`: The IP is not allowed to use STREAM with this parent.
648
-- `machine GUID 'VALUE' is not allowed.`: The GUID that is trying to send stream is not allowed.
649
-- `Machine GUID 'VALUE' is not permitted from this IP. `: The IP does not match the pattern or IP allowed to connect to
650
- use stream.
321
+- `request without KEY`: Incomplete message, missing API key, hostname, or machine GUID.
322
+- `API key 'VALUE' is not valid GUID`: Invalid UUID format.
323
+- `machine GUID 'VALUE' is not GUID.`: Invalid machine GUID.
324
+- `API key 'VALUE' is not allowed`: Invalid API key.
325
+- `API key 'VALUE' is not permitted from this IP`: IP not allowed to use STREAM with this parent.
326
+- `machine GUID 'VALUE' is not allowed.`: GUID not permitted.
327
+- `Machine GUID 'VALUE' is not permitted from this IP.`: IP not matching the allowed pattern.
328
652
-### Netdata could not create a stream
329
+### Netdata Could Not Create a Stream
330
654
-The connection between parent and child is a stream. When the parent can't convert the initial connection into
655
-a stream, it will write the following message inside `error.log`:
331
+If the parent can’t convert the initial connection into a stream, it will log the following error:
332
333
```
334
file descriptor given is not a valid stream