diff options
Diffstat (limited to '')
| -rw-r--r-- | streaming/README.md | 23 |
1 files changed, 14 insertions, 9 deletions
diff --git a/streaming/README.md b/streaming/README.md index e455d1070..e1ebad536 100644 --- a/streaming/README.md +++ b/streaming/README.md @@ -1,4 +1,4 @@ -# Metrics streaming +# Streaming and replication Each netdata is able to replicate/mirror its database to another netdata, by streaming collected metrics, in real-time to it. This is quite different to [data archiving to third party time-series @@ -18,13 +18,13 @@ a netdata performs: Local netdata (`slave`), **without any database or alarms**, collects metrics and sends them to another netdata (`master`). -The user can take the full functionality of the `slave` netdata at -http://master.ip:19999/host/slave.hostname/. Alarms for the `slave` are served by the `master`. +The `my-netdata` menu shows a list of all "databases streamed to" the master. Clicking one of those links allows the user to view the full dashboard of the `slave` netdata. The URL has the form http://master-host:master-port/host/slave-host/. -In this mode the `slave` is just a plain data collector. -It runs with... **5MB** of RAM (yes, you read correct), spawns all external plugins, but instead +Alarms for the `slave` are served by the `master`. + +In this mode the `slave` is just a plain data collector. It spawns all external plugins, but instead of maintaining a local database and accepting dashboard requests, it streams all metrics to the -`master`. +`master`. The memory footprint is reduced significantly, to between 6 MiB and 40 MiB, depending on the enabled plugins. To reduce the memory usage as much as possible, refer to [running netdata in embedded devices](../docs/Performance.md#running-netdata-in-embedded-devices). The same `master` can collect data for any number of `slaves`. @@ -33,8 +33,8 @@ The same `master` can collect data for any number of `slaves`. Local netdata (`slave`), **with a local database (and possibly alarms)**, collects metrics and sends them to another netdata (`master`). -The user can use all the functions **at both** http://slave.ip:19999/ and -http://master.ip:19999/host/slave.hostname/. +The user can use all the functions **at both** http://slave-ip:slave-port/ and +http://master-host:master-port/host/slave-host/. The `slave` and the `master` may have different data retention policies for the same metrics. @@ -81,12 +81,15 @@ monitoring (there cannot be health monitoring without a database). ``` [web] - mode = none | static-threaded | single-threaded | multi-threaded + mode = none | static-threaded + accept a streaming request every seconds = 0 ``` `[web].mode = none` disables the API (netdata will not listen to any ports). This also disables the registry (there cannot be a registry without an API). +`accept a streaming request every seconds` can be used to set a limit on how often a master Netdata server will accept streaming requests from the slaves. 0 sets no limit, 1 means maximum once every second. If this is set, you may see error log entries "... too busy to accept new streaming request. Will be allowed in X secs". + ``` [backend] enabled = yes | no @@ -410,3 +413,5 @@ The sending side of a netdata proxy, connects and disconnects to the final desti metrics, following the same pattern of the receiving side. For a practical example see [Monitoring ephemeral nodes](#monitoring-ephemeral-nodes). + +[]() |