diff options
Diffstat (limited to '')
| -rw-r--r-- | streaming/README.md | 23 |
1 files changed, 11 insertions, 12 deletions
diff --git a/streaming/README.md b/streaming/README.md index 1f3bd739..e455d107 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). - |