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:

data collection happens per second

thousands of metrics per server are collected

data do not leave the server where they are collected

netdata servers do not talk to each other

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.

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.

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 my-netdata 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.

netdata v1.9+ support limiting access to the registry from given IPs, like this:

[registry]allow from=*

allow from settings are netdata simple patterns: 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.

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.

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: