summaryrefslogtreecommitdiffstats
path: root/streaming
diff options
context:
space:
mode:
Diffstat (limited to 'streaming')
-rw-r--r--streaming/README.md23
1 files changed, 11 insertions, 12 deletions
diff --git a/streaming/README.md b/streaming/README.md
index 1f3bd7391..e455d1070 100644
--- a/streaming/README.md
+++ b/streaming/README.md
@@ -11,9 +11,9 @@ a netdata performs:
- run health checks that trigger alarms and send alarm notifications
- archive metrics to a backend time-series database
-The following configurations are supported:
+## Supported configurations
-#### netdata without a database or web API (headless collector)
+### netdata without a database or web API (headless collector)
Local netdata (`slave`), **without any database or alarms**, collects metrics and sends them to
another netdata (`master`).
@@ -28,7 +28,7 @@ of maintaining a local database and accepting dashboard requests, it streams all
The same `master` can collect data for any number of `slaves`.
-#### database replication
+### database replication
Local netdata (`slave`), **with a local database (and possibly alarms)**, collects metrics and
sends them to another netdata (`master`).
@@ -41,7 +41,7 @@ The `slave` and the `master` may have different data retention policies for the
Alarms for the `slave` are triggered by **both** the `slave` and the `master` (and actually
each can have different alarms configurations or have alarms disabled).
-#### netdata proxies
+### netdata proxies
Local netdata (`slave`), with or without a database, collects metrics and sends them to another
netdata (`proxy`), which may or may not maintain a database, which forwards them to another
@@ -52,7 +52,7 @@ Alarms for the slave can be triggered by any of the involved hosts that maintain
Any number of daisy chaining netdata servers are supported, each with or without a database and
with or without alarms for the `slave` metrics.
-#### mix and match with backends
+### mix and match with backends
All nodes that maintain a database can also send their data to a backend database.
This allows quite complex setups.
@@ -67,7 +67,7 @@ Example:
6. alarms are triggered by `H` for all hosts
7. users can use all the netdata that maintain a database to view metrics (i.e. at `H` all hosts can be viewed).
-#### netdata.conf configuration
+## Configuration
These are options that affect the operation of netdata in this area:
@@ -98,7 +98,7 @@ This also disables the registry (there cannot be a registry without an API).
`[backend]` configures data archiving to a backend (it archives all databases maintained on
this host).
-#### streaming configuration
+### streaming configuration
A new file is introduced: [stream.conf](stream.conf) (to edit it on your system run
`/etc/netdata/edit-config stream.conf`). This file holds streaming configuration for both the
@@ -167,7 +167,7 @@ the unique id the netdata generating the metrics (i.e. the netdata that original
them `/var/lib/netdata/registry/netdata.unique.id`). So, metrics for netdata `A` that pass through
any number of other netdata, will have the same `MACHINE_GUID`.
-####### allow from
+##### allow from
`allow from` settings are [netdata simple patterns](../libnetdata/simple_pattern): string matches
that use `*` as wildcard (any number of times) and a `!` prefix for a negative match.
@@ -176,7 +176,7 @@ important: left to right, the first positive or negative match is used.
`allow from` is available in netdata v1.9+
-#### tracing
+##### tracing
When a `slave` is trying to push metrics to a `master` or `proxy`, it logs entries like these:
@@ -203,7 +203,7 @@ The receiving end (`proxy` or `master`) logs entries like these:
For netdata v1.9+, streaming can also be monitored via `access.log`.
-#### Viewing remote host dashboards, using mirrored databases
+## Viewing remote host dashboards, using mirrored databases
On any receiving netdata, that maintains remote databases and has its web server enabled,
`my-netdata` menu will include a list of the mirrored databases.
@@ -240,7 +240,7 @@ Following the netdata way of monitoring, we wanted:
3. **zero configuration**, all ephemeral servers should have exactly the same configuration, and nothing should be configured at any system for each of the ephemeral nodes. We shouldn't care if 10 or 100 servers are spawned to handle the load.
4. **self-cleanup**, so that nothing needs to be done for cleaning up the monitoring infrastructure from the hundreds of nodes that may have been monitored through time.
-#### How it works
+### How it works
All monitoring solutions, including netdata, work like this:
@@ -410,4 +410,3 @@ 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).
-