diff options
| author | Promise Akpan <akpanpromise@hotmail.com> | 2019-08-15 12:06:39 +0100 |
|---|---|---|
| committer | Chris Akritidis <43294513+cakrit@users.noreply.github.com> | 2019-08-15 13:06:39 +0200 |
| commit | f5006d51e8caf9148d393eb68d53dc9fcd28b7b6 (patch) | |
| tree | 03b757236d6b45e46813a4a875c77dc775e5f896 /registry | |
| parent | 69172fd57472df75d877f43de2dcc693c48ab5c0 (diff) | |
Fix Markdown Lint warnings (#6664)
* make remark access all directories
* detailed fix after autofix by remark lint
* cross check autofix for this set of files
* crosscheck more files
* crosschecking and small fixes
* crosscheck autofixed md files
Diffstat (limited to 'registry')
| -rw-r--r-- | registry/README.md | 46 |
1 files changed, 23 insertions, 23 deletions
diff --git a/registry/README.md b/registry/README.md index aaf6325de0..f852809bec 100644 --- a/registry/README.md +++ b/registry/README.md @@ -13,18 +13,18 @@ Netdata provides distributed monitoring. Traditional monitoring solutions centralize all the data to provide unified dashboards across all servers. Before Netdata, this was the standard practice. However it has a few issues: -1. due to the resources required, the number of metrics collected is limited. -1. for the same reason, the data collection frequency is not that high, at best it will be once every 10 or 15 seconds, at worst every 5 or 10 mins. -1. the central monitoring solution needs dedicated resources, thus becoming "another bottleneck" in the whole ecosystem. It also requires maintenance, administration, etc. -1. most centralized monitoring solutions are usually only good for presenting *statistics of past performance* (i.e. cannot be used for real-time performance troubleshooting). +1. due to the resources required, the number of metrics collected is limited. +2. for the same reason, the data collection frequency is not that high, at best it will be once every 10 or 15 seconds, at worst every 5 or 10 mins. +3. the central monitoring solution needs dedicated resources, thus becoming "another bottleneck" in the whole ecosystem. It also requires maintenance, administration, etc. +4. most centralized monitoring solutions are usually only good for presenting _statistics of past performance_ (i.e. cannot be used for real-time performance troubleshooting). Netdata follows a different approach: -1. data collection happens per second -1. thousands of metrics per server are collected -1. data do not leave the server where they are collected -1. Netdata servers do not talk to each other -1. your browser connects all the Netdata servers +1. data collection happens per second +2. thousands of metrics per server are collected +3. data do not leave the server where they are collected +4. Netdata servers do not talk to each other +5. your browser connects all the Netdata servers Using Netdata, your monitoring infrastructure is embedded on each server, limiting significantly the need of additional resources. Netdata is blazingly fast, very resource efficient and utilizes server resources that already exist and are spare (on each server). This allows **scaling out** the monitoring infrastructure. @@ -38,22 +38,22 @@ Netdata cloud has a roadmap to [offer many more features](https://blog.netdata.c The registry keeps track of 4 entities: -1. **machines**: i.e. the Netdata installations (a random GUID generated by each Netdata the first time it starts; we call this **machine_guid**) +1. **machines**: i.e. the Netdata installations (a random GUID generated by each Netdata the first time it starts; we call this **machine_guid**) For each Netdata installation (each `machine_guid`) the registry keeps track of the different URLs it is accessed. -2. **persons**: i.e. the web browsers accessing the Netdata installations (a random GUID generated by the registry the first time it sees a new web browser; we call this **person_guid**) +2. **persons**: i.e. the web browsers accessing the Netdata installations (a random GUID generated by the registry the first time it sees a new web browser; we call this **person_guid**) For each person, the registry keeps track of the Netdata installations it has accessed and their URLs. -3. **URLs** of Netdata installations (as seen by the web browsers) +3. **URLs** of Netdata installations (as seen by the web browsers) - For each URL, the registry keeps the URL and nothing more. Each URL is linked to *persons* and *machines*. The only way to find a URL is to know its **machine_guid** or have a **person_guid** it is linked to it. + For each URL, the registry keeps the URL and nothing more. Each URL is linked to _persons_ and _machines_. The only way to find a URL is to know its **machine_guid** or have a **person_guid** it is linked to it. -4. **accounts**: i.e. the information used to sign-in via one of the available sign-in methods. Depending on the method, this may include an email, an email and a profile picture. +4. **accounts**: i.e. the information used to sign-in via one of the available sign-in methods. Depending on the method, this may include an email, an email and a profile picture. -For *persons*/*accounts* and *machines*, the registry keeps links to *URLs*, each link with 2 timestamps (first time seen, last time seen) and a counter (number of times it has been seen). -*machines*, *persons* and timestamps are stored in the Netdata registry regardless of whether you sign in or not. +For _persons_/_accounts_ and _machines_, the registry keeps links to _URLs_, each link with 2 timestamps (first time seen, last time seen) and a counter (number of times it has been seen). +*machines_, _persons_ and timestamps are stored in the Netdata registry regardless of whether you sign in or not. ## Who talks to the registry? @@ -63,7 +63,6 @@ Your Netdata servers do not talk to the registry. This is a UML diagram of its o  - ## Which is the default registry? `https://registry.my-netdata.io`, which is currently served by `https://london.my-netdata.io`. This registry listens to both HTTP and HTTPS requests but the default is HTTPS. @@ -113,6 +112,7 @@ So this server will appear in the node menu as `Group1 - Master DB`. The max nam ### Limiting access to the registry Netdata v1.9+ support limiting access to the registry from given IPs, like this: + ``` [registry] allow from = * @@ -128,19 +128,19 @@ Keep in mind that connections to Netdata API ports are filtered by `[web].allow There can be up to 2 files: -- `registry-log.db`, the transaction log +- `registry-log.db`, the transaction log - all incoming requests that affect the registry are saved in this file in real-time. + all incoming requests that affect the registry are saved in this file in real-time. -- `registry.db`, the database +- `registry.db`, the database - every `[registry].registry save db every new entries` entries in `registry-log.db`, Netdata will save its database to `registry.db` and empty `registry-log.db`. + every `[registry].registry save db every new entries` entries in `registry-log.db`, Netdata will save its database to `registry.db` and empty `registry-log.db`. Both files are machine readable text files. ## The future -The registry opens a whole world of new possibilities for Netdata. Check here what we think: https://github.com/netdata/netdata/issues/416 +The registry opens a whole world of new possibilities for Netdata. Check here what we think: <https://github.com/netdata/netdata/issues/416> ## Troubleshooting the registry @@ -154,4 +154,4 @@ ERROR 409: Cannot ACCESS netdata registry: https://registry.my-netdata.io respon This error is printed on your web browser console (press F12 on your browser to see it). -[]() +[](<>) |