|
|
@@ -1,205 +1,54 @@
|
|
|
# Registry
|
|
|
|
|
|
-Netdata provides distributed monitoring.
|
|
|
+Netdata uses a **central Registry**. Together with certain browser features, it allows for unified cross-Agent dashboards. For example, when you jump from Agent to Agent using the node menu, several session settings (like the currently viewed charts, the current zoom and pan operations on the charts, etc.) are propagated to the new Agent, so that the new dashboard will come with exactly the same view.
|
|
|
|
|
|
-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:
|
|
|
+## Default Registry
|
|
|
|
|
|
-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).
|
|
|
+The default Registry is `https://registry.my-netdata.io`, which is currently served by `https://london.my-netdata.io`. This Registry listens to both HTTP and HTTPS requests with the default being HTTPS.
|
|
|
|
|
|
-Netdata follows a different approach:
|
|
|
+## What data is stored
|
|
|
|
|
|
-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
|
|
|
+The Registry keeps track of four entities:
|
|
|
|
|
|
-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.
|
|
|
+1. **machines**: The Netdata installations (a random GUID generated by each Netdata the first time it starts, we call this **machine_guid**)
|
|
|
|
|
|
-However, the Netdata approach introduces a few new issues that need to be addressed, one being **the list of Netdata we
|
|
|
-have installed**, i.e. the URLs our Netdata servers are listening.
|
|
|
+ For each Netdata installation, the Registry keeps track of the various different URLs it has accessed.
|
|
|
|
|
|
-To solve this, Netdata utilizes a **central registry**. This registry, together with certain browser features, allow
|
|
|
-Netdata to provide unified cross-server dashboards. For example, when you jump from server to server using the node
|
|
|
-menu, several session settings (like the currently viewed charts, the current zoom and pan operations on the charts,
|
|
|
-etc.) are propagated to the new server, so that the new dashboard will come with exactly the same view.
|
|
|
+2. **people**: 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**)
|
|
|
|
|
|
-## What data does the registry store?
|
|
|
-
|
|
|
-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**)
|
|
|
-
|
|
|
- For each Netdata installation (each `machine_guid`) the registry keeps track of the different URLs it has 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**)
|
|
|
-
|
|
|
- For each person, the registry keeps track of the Netdata installations it has accessed and their URLs.
|
|
|
+ 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)
|
|
|
|
|
|
- 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, or an email and a profile picture or avatar.
|
|
|
-
|
|
|
-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?
|
|
|
-
|
|
|
-Your web browser **only**! If sending this information is against your policies, you
|
|
|
-can [run your own registry](#run-your-own-registry)
|
|
|
-
|
|
|
-Your Netdata servers do not talk to the registry. This is a UML diagram of its operation:
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-## 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.
|
|
|
-
|
|
|
-### Can this registry handle the global load of Netdata installations?
|
|
|
-
|
|
|
-Yeap! The registry can handle 50.000 - 100.000 requests **per second per core** (depending on the type of CPU, the
|
|
|
-computer's memory bandwidth, etc). 50.000 is on J1900 (celeron 2Ghz).
|
|
|
-
|
|
|
-We believe, it can do it...
|
|
|
-
|
|
|
-## Run your own registry
|
|
|
-
|
|
|
-**Every Netdata can be a registry**. Just pick one and configure it.
|
|
|
-
|
|
|
-**To turn any Netdata into a registry**, edit `/etc/netdata/netdata.conf` and set:
|
|
|
-
|
|
|
-```text
|
|
|
-[registry]
|
|
|
- enabled = yes
|
|
|
- registry to announce = http://your.registry:19999
|
|
|
-```
|
|
|
-
|
|
|
-Restart your Netdata to activate it.
|
|
|
-
|
|
|
-Then, you need to tell **all your other Netdata servers to advertise your registry**, instead of the default. To do
|
|
|
-this, on each of your Netdata servers, edit `/etc/netdata/netdata.conf` and set:
|
|
|
-
|
|
|
-```text
|
|
|
-[registry]
|
|
|
- enabled = no
|
|
|
- registry to announce = http://your.registry:19999
|
|
|
-```
|
|
|
-
|
|
|
-Note that we have not enabled the registry on the other servers. Only one Netdata (the registry) needs
|
|
|
-`[registry].enabled = yes`.
|
|
|
-
|
|
|
-This is it. You have your registry now.
|
|
|
+ For each URL, the Registry keeps the URL and nothing more. Each URL is linked to **people** and **machines**. The only way to find a URL is to know its **machine_guid** or have a **person_guid** that is linked to it.
|
|
|
|
|
|
-You may also want to give your server different names under the node menu (i.e. to have them sorted / grouped). You can
|
|
|
-change its registry name, by setting on each Netdata server:
|
|
|
+4. **accounts**: The information used to sign in via one of the available sign-in methods. Depending on the method, this may include only an email or additionally a profile picture or avatar.
|
|
|
|
|
|
-```text
|
|
|
-[registry]
|
|
|
- registry hostname = Group1 - Master DB
|
|
|
-```
|
|
|
+For **people**, **accounts** and **machines**, the Registry keeps links to **URLs**, each link with two timestamps (first time seen, last time seen) and a counter (number of times it has been seen).
|
|
|
|
|
|
-So this server will appear in the node menu as `Group1 - Master DB`. The max name length is 50 characters.
|
|
|
+**machines**, **people** and timestamps are stored in the Netdata Registry regardless of whether you sign in or not.
|
|
|
|
|
|
-### Limiting access to the registry
|
|
|
+## Communication with the Registry
|
|
|
|
|
|
-Netdata v1.9+ support limiting access to the registry from given IPs, like this:
|
|
|
+**Only** your web browser communicates with the Registry. If sending this information is against your policies, you can [run your own Registry](/src/registry/CONFIGURATION.md)
|
|
|
|
|
|
-```text
|
|
|
-[registry]
|
|
|
- allow from = *
|
|
|
-```
|
|
|
+Your Agents do not talk to the Registry. This is a diagram explaining the process:
|
|
|
|
|
|
-`allow from` settings are [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md): string matches that use `*`
|
|
|
-as wildcard (any number of times) and a `!` prefix for a negative match. So: `allow from = !10.1.2.3 10.*` will allow
|
|
|
-all IPs in `10.*` except `10.1.2.3`. The order is important: left to right, the first positive or negative match is
|
|
|
-used.
|
|
|
+```mermaid
|
|
|
+sequenceDiagram
|
|
|
+ participant WebBrowser as Web Browser
|
|
|
+ participant Netdata1 as Netdata 1
|
|
|
+ participant Registry1 as Registry 1
|
|
|
|
|
|
-Keep in mind that connections to Netdata API ports are filtered by `[web].allow connections from`. So, IPs allowed by
|
|
|
-`[registry].allow from` should also be allowed by `[web].allow connection from`.
|
|
|
+ WebBrowser->>Netdata1: 1. Hi, give me the dashboard
|
|
|
+ Netdata1-->>WebBrowser: 2. Welcome, here it is...
|
|
|
+ Note over WebBrowser,Netdata1: a few seconds later
|
|
|
|
|
|
-The patterns can be matches over IP addresses or FQDN of the host. In order to check the FQDN of the connection without
|
|
|
-opening the Netdata Agent to DNS-spoofing, a reverse-dns record must be setup for the connecting host. At connection
|
|
|
-time the reverse-dns of the peer IP address is resolved, and a forward DNS resolution is made to validate the IP address
|
|
|
-against the name-pattern.
|
|
|
+ WebBrowser->>Netdata1: 3. Now give me the Registry information
|
|
|
+ Netdata1-->>WebBrowser: 4. Here it is, talk to Registry 1
|
|
|
|
|
|
-Please note that this process can be expensive on a machine that is serving many connections. The behaviour of the
|
|
|
-pattern matching can be controlled with the following setting:
|
|
|
+ WebBrowser->>Registry1: 5. Hey Registry 1, I am accessing Netdata 1...
|
|
|
+ Registry1-->>WebBrowser: 6. Nice! Here are other Netdata Agents you have accessed in the past
|
|
|
|
|
|
-```text
|
|
|
-[registry]
|
|
|
- allow by dns = heuristic
|
|
|
+ Note over WebBrowser: Only your web browser talks to the Registry
|
|
|
```
|
|
|
-
|
|
|
-The settings are:
|
|
|
-
|
|
|
-- `yes` allows the pattern to match DNS names.
|
|
|
-- `no` disables DNS matching for the patterns (they only match IP addresses).
|
|
|
-- `heuristic` will estimate if the patterns should match FQDNs by the presence or absence of `:`s or alpha-characters.
|
|
|
-
|
|
|
-### Where is the registry database stored?
|
|
|
-
|
|
|
-`/var/lib/netdata/registry/*.db`
|
|
|
-
|
|
|
-There can be up to 2 files:
|
|
|
-
|
|
|
-- `registry-log.db`, the transaction log
|
|
|
-
|
|
|
- all incoming requests that affect the registry are saved in this file in real-time.
|
|
|
-
|
|
|
-- `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`.
|
|
|
-
|
|
|
-Both files are machine readable text files.
|
|
|
-
|
|
|
-### How can I disable the SameSite and Secure cookies?
|
|
|
-
|
|
|
-Beginning with `v1.30.0`, when the Netdata Agent's web server processes a request, it delivers the `SameSite=none`
|
|
|
-and `Secure` cookies. If you have problems accessing the local Agent dashboard or Netdata Cloud, disable these
|
|
|
-cookies by [editing `netdata.conf`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config):
|
|
|
-
|
|
|
-```text
|
|
|
-[registry]
|
|
|
- enable cookies SameSite and Secure = no
|
|
|
-```
|
|
|
-
|
|
|
-## 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>
|
|
|
-
|
|
|
-## Troubleshooting the registry
|
|
|
-
|
|
|
-The registry URL should be set to the URL of a Netdata dashboard. This server has to have `[registry].enabled = yes`.
|
|
|
-So, accessing the registry URL directly with your web browser, should present the dashboard of the Netdata operating the
|
|
|
-registry.
|
|
|
-
|
|
|
-To use the registry, your web browser needs to support **third party cookies**, since the cookies are set by the
|
|
|
-registry while you are browsing the dashboard of another Netdata server. The registry, the first time it sees a new web
|
|
|
-browser it tries to figure if the web browser has cookies enabled or not. It does this by setting a cookie and
|
|
|
-redirecting the browser back to itself hoping that it will receive the cookie. If it does not receive the cookie, the
|
|
|
-registry will keep redirecting your web browser back to itself, which after a few redirects will fail with an error like
|
|
|
-this:
|
|
|
-
|
|
|
-```text
|
|
|
-ERROR 409: Cannot ACCESS netdata registry: https://registry.my-netdata.io responded with: {"status":"redirect","registry":"https://registry.my-netdata.io"}
|
|
|
-```
|
|
|
-
|
|
|
-This error is printed on your web browser console (press F12 on your browser to see it).
|
Fotis Voutsas