Merging upstream version 1.11.1+dfsg

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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).
-