summaryrefslogtreecommitdiffstats
path: root/streaming/README.md
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--streaming/README.md23
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).
+
+[![analytics](https://www.google-analytics.com/collect?v=1&aip=1&t=pageview&_s=1&ds=github&dr=https%3A%2F%2Fgithub.com%2Fnetdata%2Fnetdata&dl=https%3A%2F%2Fmy-netdata.io%2Fgithub%2Fstreaming%2FREADME&_u=MAC~&cid=5792dfd7-8dc4-476b-af31-da2fdb9f93d2&tid=UA-64295674-3)]()