Documentation fixes (#6144)
* Correct my-netdata menu to node menu and mention Netdata cloud in the registry * rebase and fix replace of main readme link * remove comma
This commit is contained in:
Chris Akritidis
GitHub
parent
ee87e2ae84
commit
cfa8b9e2de
|
|
@ -331,8 +331,7 @@ Charts on Netdata dashboards are synchronized to each other. There is no master
|
|||
|
||||
*Charts are panned by dragging them with the mouse. Charts can be zoomed in/out with`SHIFT` + `mouse wheel` while the mouse pointer is over a chart.*
|
||||
|
||||
> The visible time-frame (pan and zoom) is propagated from Netdata server to Netdata server, when navigating via the [`my-netdata` menu](registry#registry).
|
||||
|
||||
> The visible time-frame (pan and zoom) is propagated from Netdata server to Netdata server, when navigating via the [node menu](registry#registry).
|
||||
|
||||
### Highlighted time-frame
|
||||
|
||||
|
|
@ -342,7 +341,7 @@ To improve visual anomaly detection across charts, the user can highlight a time
|
|||
|
||||
*A highlighted time-frame can be given by pressing `ALT` + `mouse selection` on any chart. Netdata will highlight the same range on all charts.*
|
||||
|
||||
> Highlighted ranges are propagated from Netdata server to Netdata server, when navigating via the [`my-netdata` menu](registry#registry).
|
||||
> Highlighted ranges are propagated from Netdata server to Netdata server, when navigating via the [node menu](registry#registry).
|
||||
|
||||
|
||||
## What does it monitor
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ If still Netdata does not receive the requests, something is blocking them. A fi
|
|||
|
||||
</details> <br/>
|
||||
|
||||
When you install multiple Netdata servers, all your servers will appear at the `my-netdata` menu at the top left of the dashboard. For this to work, you have to manually access just once, the dashboard of each of your Netdata servers.
|
||||
When you install multiple Netdata servers, all your servers will appear at the node menu at the top left of the dashboard. For this to work, you have to manually access just once, the dashboard of each of your netdata servers.
|
||||
|
||||
The `my-netdata` menu is more than just browser bookmarks. When switching Netdata servers from that menu, any settings of the current view are propagated to the other Netdata server:
|
||||
The node menu is more than just browser bookmarks. When switching Netdata servers from that menu, any settings of the current view are propagated to the other netdata server:
|
||||
|
||||
- the current charts panning (drag the charts left or right),
|
||||
- the current charts zooming (`SHIFT` + mouse wheel over a chart),
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ cp -a ./${GENERATOR_DIR}/custom ./${SRC_DIR}/
|
|||
|
||||
# Modify the first line of the main README.md, to enable proper static html generation
|
||||
echo "Modifying README header"
|
||||
sed -i -e '0,/# netdata /s//# Introduction\n\n/' ${SRC_DIR}/README.md
|
||||
sed -i -e '0,/# Netdata /s//# Introduction\n\n/' ${SRC_DIR}/README.md
|
||||
|
||||
# Remove all GA tracking code
|
||||
find ${SRC_DIR} -name "*.md" -print0 | xargs -0 sed -i -e 's/\[!\[analytics.*UA-64295674-3)\]()//g'
|
||||
|
|
|
|||
|
|
@ -32,14 +32,27 @@ Note that you can learn about Google’s practices in connection with its analyt
|
|||
|
||||
Information from Cookies: We and our service providers (for example, Google Analytics as described above) may collect information using cookies or similar technologies for the purposes described above and below. Cookies are pieces of information that are stored by your browser on the hard drive or memory of your computer or other Internet access device. Cookies may enable us to personalize your experience on the Services, maintain a persistent session, passively collect demographic information about your computer, and monitor advertisements and other activities. The Websites may use different kinds of cookies and other types of local storage (such as browser-based or plugin-based local storage).
|
||||
|
||||
ND Registry: The global registry, together with certain browser features, allow Netdata to provide unified cross-server dashboards, via the node menu.
|
||||
The menu lists the Netdata servers you have visited. 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. The global registry keeps track of 4 entities:
|
||||
|
||||
ND Registry: The global registry, together with certain browser features, allow Netdata to provide unified cross-server dashboards, via the `my-netdata` menu. The menu lists the Netdata servers you have visited. 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. The global registry keeps track of 3 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.
|
||||
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**). For each person, the registry keeps track of the Netdata installations it has accessed and their URLs.
|
||||
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**)
|
||||
|
||||
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 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, 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.
|
||||
|
||||
If sending this information is against your policies, you can [run your own registry](../registry/#run-your-own-registry).
|
||||
Note that ND versions with the 'Sign in' feature of the ND Cloud do not use the global registry.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
# Registry
|
||||
|
||||
Netdata registry implements the `my-netdata` menu on netdata dashboards.
|
||||
The `my-netdata` menu lists the netdata servers you have visited.
|
||||
The Netdata registry implements the node menu on the top left corner of the netdata dashboards and enables the Netdata cloud features, such as the node view.
|
||||
The node menu lists the netdata servers you have visited. The node view offers a lot of additional features on top of the menu,
|
||||
[with many more to come](https://blog.netdata.cloud/posts/netdata-cloud-announcement/).
|
||||
To enable the global Netdata registry and the cloud features, you need to Sign In to Netdata cloud. By signing in, you opt in to let the registry receive and store
|
||||
the information described [here](#what-data-does-the-registry-store).
|
||||
You can still get the node menu, but not the cloud features, if you [run your own registry](#run-your-own-registry).
|
||||
|
||||
## Why?
|
||||
|
||||
|
|
@ -26,11 +30,13 @@ Using netdata, your monitoring infrastructure is embedded on each server, limiti
|
|||
|
||||
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.
|
||||
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.
|
||||
Netdata cloud has a roadmap to [offer many more features](https://blog.netdata.cloud/posts/netdata-cloud-announcement/) over and above the simple node menu.
|
||||
|
||||
## What is the registry?
|
||||
## What data does the registry store?
|
||||
|
||||
The registry keeps track of 3 entities:
|
||||
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**)
|
||||
|
||||
|
|
@ -38,12 +44,17 @@ The registry keeps track of 3 entities:
|
|||
|
||||
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, 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.
|
||||
|
||||
## 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)
|
||||
|
|
@ -52,19 +63,11 @@ Your netdata servers do not talk to the registry. This is a UML diagram of its o
|
|||
|
||||
|
||||
|
||||
## What data does the registry store?
|
||||
|
||||
Its database contains:
|
||||
|
||||
- **random person GUIDs** (generated by the registry as a browser cookie)
|
||||
- **random machine GUIDs** (generated by each netdata server on its first run), including the hostname of the server netdata is running (without the domain)
|
||||
- **URLs** (the base URL for accessing a netdata server, as seen by the web browser)
|
||||
|
||||
For *persons* 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).
|
||||
|
||||
## 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.
|
||||
`https://netdata.cloud` is the additional registry endpoint, that enables [the cloud features](https://blog.netdata.cloud/posts/netdata-cloud-announcement/). It only accepts HTTPS.
|
||||
|
||||
### Can this registry handle the global load of netdata installations?
|
||||
|
||||
|
|
@ -98,14 +101,14 @@ Note that we have not enabled the registry on the other servers. Only one netdat
|
|||
|
||||
This is it. You have your registry now.
|
||||
|
||||
You may also want to give your server different names under the **my-netdata** menu (i.e. to have them sorted / grouped). You can change its registry name, by setting on each netdata server:
|
||||
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:
|
||||
|
||||
```
|
||||
[registry]
|
||||
registry hostname = Group1 - Master DB
|
||||
```
|
||||
|
||||
So this server will appear in **my-netdata** as `Group1 - Master DB`. The max name length is 50 characters.
|
||||
So this server will appear in the node menu as `Group1 - Master DB`. The max name length is 50 characters.
|
||||
|
||||
### Limiting access to the registry
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ a netdata performs:
|
|||
Local netdata (`slave`), **without any database or alarms**, collects metrics and sends them to
|
||||
another netdata (`master`).
|
||||
|
||||
The `my-netdata` menu shows a list of all "databases streamed to" the master. Clicking one of those links allows the user to view the full dashboard of the `slave` netdata. The URL has the form http://master-host:master-port/host/slave-host/.
|
||||
The node menu shows a list of all "databases streamed to" the master. Clicking one of those links allows the user to view the full dashboard of the `slave` netdata. The URL has the form http://master-host:master-port/host/slave-host/.
|
||||
|
||||
Alarms for the `slave` are served by the `master`.
|
||||
|
||||
|
|
@ -213,7 +213,7 @@ For netdata v1.9+, streaming can also be monitored via `access.log`.
|
|||
## 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.
|
||||
The node menu will include a list of the mirrored databases.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue