Update Registry docs (#19095)
Co-authored-by: ilyam8 <ilya@netdata.cloud>
Fotis Voutsas committed
Nov 27, 2024 at 16:27 UTC
fa7a7c71bc20d3fe1ce9fe0e24cf9d17c7561e4a
10 files changed
+157
-200
README.md
+1
-1
@@ -635,7 +635,7 @@ These steps will disable the anonymous telemetry for your Netdata installation.
635
636
Please note, even with telemetry disabled, Netdata still requires a [Netdata Registry](https://learn.netdata.cloud/docs/configuring/securing-netdata-agents/registry) for alert notifications' Call To Action (CTA) functionality. When you click an alert notification, it redirects you to the Netdata Registry, which then directs your web browser to the specific Netdata Agent that issued the alert for further troubleshooting. The Netdata Registry learns the URLs of your Agents when you visit their dashboards.
637
638
-Any Netdata Agent can act as a Netdata Registry. Designate one Netdata Agent as your registry, and our global Netdata Registry will no longer be in use. For further information on this, please refer to [this guide](https://learn.netdata.cloud/docs/configuring/securing-netdata-agents/registry).
638
+Any Netdata Agent can act as a Netdata Registry. Designate one Netdata Agent as your Registry, read more [here](https://learn.netdata.cloud/docs/netdata-agent/configuration/registry).
639
640
<br/> <br/>
641
</details>
docs/DICTIONARY.md
+1
@@ -10,6 +10,7 @@ When the context is clear, we can omit the "Netdata" prefix for brevity.
10
|------------------------|--------------------------------------------------------------------------|
11
| **Agent** (**Agents**) | The core monitoring software that collects, processes and stores metrics |
12
| **Cloud** | The centralized platform for managing and visualizing Netdata metrics |
13
+| **Registry** | The default Netdata Registry, or any Agent acting as one |
14
15
## Database
16
src/daemon/config/README.md
+2
-2
@@ -29,8 +29,8 @@ the [web server access lists](/src/web/server/README.md#access-lists).
29
7. `[ml]` to configure settings for [machine learning](/src/ml/README.md).
30
8. `[health]` to [configure](#health-section-options) general settings for [health monitoring](/src/health/README.md).
31
9. `[web]` to [configure the web server](/src/web/server/README.md).
32
-10. `[registry]` for the [Netdata registry](/src/registry/README.md).
33
-11. `[global statistics]` for the [Netdata registry](/src/registry/README.md).
32
+10. `[registry]` for the [Netdata Registry](/src/registry/README.md).
33
+11. `[global statistics]` for the [Netdata Registry](/src/registry/README.md).
34
12. `[statsd]` for the general settings of the [stats.d.plugin](/src/collectors/statsd.plugin/README.md).
35
13. `[plugins]` to [configure](#plugins-section-options) which [collectors](/src/collectors/README.md) to use and PATH
36
settings.
src/health/notifications/README.md
+11
-11
@@ -1,6 +1,6 @@
1
# Agent alert notifications
2
3
-This is a reference documentation for Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
3
+This is reference documentation for Netdata's Agent alert notification feature, which supports dozens of endpoints, user roles, and more.
4
5
The `script to execute on alarm` line in `netdata.conf` defines the external script that will be called once the alert is triggered.
6
@@ -10,10 +10,10 @@ The default script is `alarm-notify.sh`.
10
>
11
> This file mentions editing configuration files.
12
>
13
-> - To edit configuration files in a safe way, we provide the [`edit config` script](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config)located in your [Netdata config directory](/docs/netdata-agent/configuration/README.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.
13
+> - To edit configuration files safely, we provide the [`edit config` script](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config)located in your [Netdata config directory](/docs/netdata-agent/configuration/README.md#the-netdata-config-directory) (typically is `/etc/netdata`) that creates the proper file and opens it in an editor automatically.
14
> Note that to run the script you need to be inside your Netdata config directory.
15
>
16
-> - Please also note that after most configuration changes you will need to [restart the Agent](/docs/netdata-agent/start-stop-restart.md) for the changes to take effect.
16
+> - Please also note that after most configuration changes, you will need to [restart the Agent](/docs/netdata-agent/start-stop-restart.md) for the changes to take effect.
17
>
18
> It is recommended to use this way for configuring Netdata.
19
@@ -27,7 +27,7 @@ You can change the default script globally by editing `netdata.conf` and changin
27
28
It uses **roles**. For example `sysadmin`, `webmaster`, `dba`, etc.
29
30
-Each alert is assigned to one or more roles, using the `to` line of the alert configuration. For example, here is the alert configuration for `ram.conf` that defaults to the role `sysadmin`:
30
+Each alert is assigned to one or more roles, using the `to` line of the alert configuration. For example, here is the alert configuration for `ram.conf` that defaults to the role `sysadmin`:
31
32
```text
33
alarm: ram_in_use
@@ -66,7 +66,7 @@ role_recipients_email[sysadmin]="someone@exaple.com someoneelse@example.com"
66
67
Each role may have one or more destinations and one or more notification methods.
68
69
-So, for example the `sysadmin` role may send:
69
+So, for example, the `sysadmin` role may send:
70
71
1. emails to admin1@example.com and admin2@example.com
72
2. pushover.net notifications to USERTOKENS `A`, `B` and `C`.
@@ -80,7 +80,7 @@ You can edit `health_alarm_notify.conf` using the `edit-config` script to config
80
81
- **Settings** per notification method:
82
83
- All notification methods except email, require some configuration (i.e. API keys, tokens, destination rooms, channels, etc). Please check this section's content to find the configuration guides for your notification option of choice
83
+ All notification methods, except email, require some configuration (i.e., API keys, tokens, destination rooms, channels, etc.). Please check this section's content to find the configuration guides for your notification option of choice
84
85
- **Recipients** per role per notification method
86
@@ -113,7 +113,7 @@ export NETDATA_ALARM_NOTIFY_DEBUG=1
113
/usr/libexec/netdata/plugins.d/alarm-notify.sh test "ROLE"
114
```
115
116
-If you are [running your own registry](/src/registry/README.md#run-your-own-registry), add `export NETDATA_REGISTRY_URL=[YOUR_URL]` before calling `alarm-notify.sh`.
116
+If you are [running your own Registry](/src/registry/CONFIGURATION.md#configure-a-custom-registry), add `export NETDATA_REGISTRY_URL=[YOUR_URL]` before calling `alarm-notify.sh`.
117
118
> If you need to dig even deeper, you can trace the execution with `bash -x`. Note that in test mode, `alarm-notify.sh` calls itself with many more arguments. So first do:
119
>
@@ -155,7 +155,7 @@ This works for all notification methods (including the default recipients).
155
156
### Proxy configuration
157
158
-If you need to send curl based notifications (pushover, pushbullet, slack, alerta,
158
+If you need to send curl-based notifications (pushover, pushbullet, slack, alerta,
159
flock, discord, telegram) via a proxy, you should set these variables to your proxy address:
160
161
```text
@@ -167,10 +167,10 @@ export https_proxy="http://10.0.0.1:3128/"
167
168
Images in notifications need to be downloaded from an Internet facing site.
169
170
-To allow notification providers to fetch the icons/images, by default we set the URL of the global public netdata registry.
170
+To allow notification providers to fetch the icons/images, by default we set the URL of the global public Netdata Registry.
171
172
If you have an Internet facing netdata (or you have copied the images/ folder
173
-of netdata to your web server), set its URL here, to fetch the notification
173
+of Netdata to your web server), set its URL here, to fetch the notification
174
images from it.
175
176
```text
@@ -184,7 +184,7 @@ You can configure netdata alerts to send dates in any format you want via editin
184
This uses standard `date` command format strings. See `man date` for
185
more info on what formats are supported.
186
187
-Note that this has to start with a '+', otherwise it won't work.
187
+Note that this has to start with a '+'; otherwise it won't work.
188
189
- For ISO 8601 dates, use `+%FT%T%z`
190
- For RFC 5322 dates, use `+%a, %d %b %Y %H:%M:%S %z`
src/registry/CONFIGURATION.md
new
+108
@@ -0,0 +1,108 @@
1
+# Registry Configuration Reference
2
+
3
+Netdata uses a **central Registry**. Together with certain browser features, it allows Netdata to provide unified cross-server dashboards. Read more about it in the [overview page](/src/registry/README.md).
4
+
5
+The Registry operates with [minimal data transfer](/src/registry/README.md#communication-with-the-registry), with all communication occurring directly between your web browser and the Registry.
6
+
7
+## Configure a Custom Registry
8
+
9
+Any Netdata Agent can function as a Registry.
10
+
11
+1. To set up your own Registry node, modify `netdata.conf` using [`edit-config`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config):
12
+
13
+ ```text
14
+ [registry]
15
+ enabled = yes
16
+ registry to announce = http://your.registry:19999
17
+ ```
18
+
19
+2. [Restart the Agent](/docs/netdata-agent/start-stop-restart.md) for the changes to take effect.
20
+3. Next, configure all other Agents to use your custom Registry instead of the default one. For each Agent, modify `netdata.conf`:
21
+
22
+ ```text
23
+ [registry]
24
+ enabled = no
25
+ registry to announce = http://your.registry:19999
26
+ ```
27
+
28
+4. To improve node identification in your dashboard, you can assign custom names to each Agent (optional):
29
+
30
+ ```text
31
+ [registry]
32
+ registry hostname = Group1 - Master DB
33
+ ```
34
+
35
+## Configure Registry Access Control
36
+
37
+You can restrict Registry access to specific IP addresses or hostnames using [simple pattern](/src/libnetdata/simple_pattern/README.md) matching:
38
+
39
+```text
40
+[registry]
41
+ allow from = *
42
+```
43
+
44
+> **Info**
45
+>
46
+> For example, `allow from = !10.1.2.3 10.*` allows all IPs in the `10.*` range except `10.1.2.3`.
47
+
48
+**Access Control Considerations**
49
+
50
+- Registry access rules work in conjunction with the main API access control (`[web].allow connections from`). IPs must be allowed by both settings to access the Registry.
51
+- Patterns can match against IP addresses or host FQDNs. For hostname matching, the system performs both reverse and forward DNS lookups to prevent DNS spoofing.
52
+
53
+**DNS Resolution Settings**
54
+
55
+DNS resolution for pattern matching can impact performance on systems handling many connections. Control this behavior using:
56
+
57
+```text
58
+[registry]
59
+ allow by dns = heuristic
60
+```
61
+
62
+Available options:
63
+
64
+| Option | Description |
65
+|:-----------:|--------------------------------------------------------------------------------------------------|
66
+| `yes` | Enables hostname pattern matching using DNS |
67
+| `no` | Restricts patterns to match IP addresses only |
68
+| `heuristic` | Automatically determines whether to use DNS based on pattern syntax (presence of `:` or letters) |
69
+
70
+## Registry database location
71
+
72
+The Registry maintains its data in two text-based database files located at `/var/lib/netdata/registry/`.
73
+
74
+| File | Purpose | Behavior |
75
+|-------------------|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
76
+| `registry-log.db` | Records all real-time Registry operations | Captures every modification to the Registry as it occurs |
77
+| `registry.db` | Stores the consolidated Registry data | Updates after every `[registry].registry save db every new entries` entries in the transaction log, at which point the main database is refreshed and the transaction log is cleared |
78
+
79
+## Configure Cookie Security Settings
80
+
81
+By default, the Netdata Agent's web server sets `SameSite=none` and `Secure` attributes for its cookies. If these security settings interfere with accessing your Agent dashboard or Netdata Cloud, you can disable them.
82
+
83
+To modify cookie settings, edit `netdata.conf` using [`edit-config`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config):
84
+
85
+```text
86
+[registry]
87
+ enable cookies SameSite and Secure = no
88
+```
89
+
90
+Disabling these security attributes may affect browser compatibility and security. Only disable them if you're experiencing specific access issues.
91
+
92
+## Troubleshooting the Registry
93
+
94
+The Registry URL must point to a valid Netdata dashboard where the Registry is enabled (`[registry].enabled = yes`). You can verify your Registry configuration by accessing its URL directly in your web browser—it should display the dashboard of the Netdata Agent running the Registry.
95
+The Registry relies on third-party cookies to function properly. The Registry sets these cookies while you're viewing dashboards from other Netdata Agents.
96
+
97
+When a new browser first connects, the Registry performs a cookie compatibility check through the following process:
98
+
99
+- Set a test cookie.
100
+- Redirect the browser back to verify the cookie.
101
+
102
+If cookies are disabled or blocked, this process fails after several redirects with an error similar to:
103
+
104
+```text
105
+ERROR 409: Cannot ACCESS netdata registry: https://registry.my-netdata.io responded with: {"status":"redirect","registry":"https://registry.my-netdata.io"}
106
+```
107
+
108
+To view these error messages, open your browser's developer console (typically F12).
src/registry/README.md
+29
-180
@@ -1,205 +1,54 @@
1
# Registry
2
3
-Netdata provides distributed monitoring.
3
+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.
4
5
-Traditional monitoring solutions centralize all the data to provide unified dashboards across all servers. Before
6
-Netdata, this was the standard practice. However it has a few issues:
5
+## Default Registry
6
8
-1. due to the resources required, the number of metrics collected is limited.
9
-2. for the same reason, the data collection frequency is not that high, at best it will be once every 10 or 15 seconds,
10
- at worst every 5 or 10 mins.
11
-3. the central monitoring solution needs dedicated resources, thus becoming "another bottleneck" in the whole
12
- ecosystem. It also requires maintenance, administration, etc.
13
-4. most centralized monitoring solutions are usually only good for presenting _statistics of past performance_ (i.e.
14
- cannot be used for real-time performance troubleshooting).
7
+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.
8
16
-Netdata follows a different approach:
9
+## What data is stored
10
18
-1. data collection happens per second
19
-2. thousands of metrics per server are collected
20
-3. data do not leave the server where they are collected
21
-4. Netdata servers do not talk to each other
22
-5. your browser connects all the Netdata servers
11
+The Registry keeps track of four entities:
12
24
-Using Netdata, your monitoring infrastructure is embedded on each server, limiting significantly the need of additional
25
-resources. Netdata is blazingly fast, very resource efficient and utilizes server resources that already exist and are
26
-spare (on each server). This allows **scaling out** the monitoring infrastructure.
13
+1. **machines**: The Netdata installations (a random GUID generated by each Netdata the first time it starts, we call this **machine_guid**)
14
28
-However, the Netdata approach introduces a few new issues that need to be addressed, one being **the list of Netdata we
29
-have installed**, i.e. the URLs our Netdata servers are listening.
15
+ For each Netdata installation, the Registry keeps track of the various different URLs it has accessed.
16
31
-To solve this, Netdata utilizes a **central registry**. This registry, together with certain browser features, allow
32
-Netdata to provide unified cross-server dashboards. For example, when you jump from server to server using the node
33
-menu, several session settings (like the currently viewed charts, the current zoom and pan operations on the charts,
34
-etc.) are propagated to the new server, so that the new dashboard will come with exactly the same view.
17
+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**)
18
36
-## What data does the registry store?
37
-
38
-The registry keeps track of 4 entities:
39
-
40
-1. **machines**: i.e. the Netdata installations (a random GUID generated by each Netdata the first time it starts; we
41
- call this **machine_guid**)
42
-
43
- For each Netdata installation (each `machine_guid`) the registry keeps track of the different URLs it has accessed.
44
-
45
-2. **persons**: i.e. the web browsers accessing the Netdata installations (a random GUID generated by the registry the
46
- first time it sees a new web browser; we call this **person_guid**)
47
-
48
- For each person, the registry keeps track of the Netdata installations it has accessed and their URLs.
19
+ For each person, the Registry keeps track of the Netdata installations it has accessed and their URLs.
20
21
3. **URLs** of Netdata installations (as seen by the web browsers)
22
52
- For each URL, the registry keeps the URL and nothing more. Each URL is linked to _persons_ and _machines_. The only
53
- way to find a URL is to know its **machine_guid** or have a **person_guid** it is linked to it.
54
-
55
-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.
56
-
57
-For _persons_/_accounts_ and _machines_, the registry keeps links to _URLs_, each link with 2 timestamps (first time
58
-seen, last time seen) and a counter (number of times it has been seen). *machines_, _persons_ and timestamps are stored
59
-in the Netdata registry regardless of whether you sign in or not.
60
-
61
-## Who talks to the registry?
62
-
63
-Your web browser **only**! If sending this information is against your policies, you
64
-can [run your own registry](#run-your-own-registry)
65
-
66
-Your Netdata servers do not talk to the registry. This is a UML diagram of its operation:
67
-
68
-
69
-
70
-## Which is the default registry?
71
-
72
-`https://registry.my-netdata.io`, which is currently served by `https://london.my-netdata.io`. This registry listens to
73
-both HTTP and HTTPS requests but the default is HTTPS.
74
-
75
-### Can this registry handle the global load of Netdata installations?
76
-
77
-Yeap! The registry can handle 50.000 - 100.000 requests **per second per core** (depending on the type of CPU, the
78
-computer's memory bandwidth, etc). 50.000 is on J1900 (celeron 2Ghz).
79
-
80
-We believe, it can do it...
81
-
82
-## Run your own registry
83
-
84
-**Every Netdata can be a registry**. Just pick one and configure it.
85
-
86
-**To turn any Netdata into a registry**, edit `/etc/netdata/netdata.conf` and set:
87
-
88
-```text
89
-[registry]
90
- enabled = yes
91
- registry to announce = http://your.registry:19999
92
-```
93
-
94
-Restart your Netdata to activate it.
95
-
96
-Then, you need to tell **all your other Netdata servers to advertise your registry**, instead of the default. To do
97
-this, on each of your Netdata servers, edit `/etc/netdata/netdata.conf` and set:
98
-
99
-```text
100
-[registry]
101
- enabled = no
102
- registry to announce = http://your.registry:19999
103
-```
104
-
105
-Note that we have not enabled the registry on the other servers. Only one Netdata (the registry) needs
106
-`[registry].enabled = yes`.
107
-
108
-This is it. You have your registry now.
23
+ 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.
24
110
-You may also want to give your server different names under the node menu (i.e. to have them sorted / grouped). You can
111
-change its registry name, by setting on each Netdata server:
25
+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.
26
113
-```text
114
-[registry]
115
- registry hostname = Group1 - Master DB
116
-```
27
+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).
28
118
-So this server will appear in the node menu as `Group1 - Master DB`. The max name length is 50 characters.
29
+**machines**, **people** and timestamps are stored in the Netdata Registry regardless of whether you sign in or not.
30
120
-### Limiting access to the registry
31
+## Communication with the Registry
32
122
-Netdata v1.9+ support limiting access to the registry from given IPs, like this:
33
+**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)
34
124
-```text
125
-[registry]
126
- allow from = *
127
-```
35
+Your Agents do not talk to the Registry. This is a diagram explaining the process:
36
129
-`allow from` settings are [Netdata simple patterns](/src/libnetdata/simple_pattern/README.md): string matches that use `*`
130
-as wildcard (any number of times) and a `!` prefix for a negative match. So: `allow from = !10.1.2.3 10.*` will allow
131
-all IPs in `10.*` except `10.1.2.3`. The order is important: left to right, the first positive or negative match is
132
-used.
37
+```mermaid
38
+sequenceDiagram
39
+ participant WebBrowser as Web Browser
40
+ participant Netdata1 as Netdata 1
41
+ participant Registry1 as Registry 1
42
134
-Keep in mind that connections to Netdata API ports are filtered by `[web].allow connections from`. So, IPs allowed by
135
-`[registry].allow from` should also be allowed by `[web].allow connection from`.
43
+ WebBrowser->>Netdata1: 1. Hi, give me the dashboard
44
+ Netdata1-->>WebBrowser: 2. Welcome, here it is...
45
+ Note over WebBrowser,Netdata1: a few seconds later
46
137
-The patterns can be matches over IP addresses or FQDN of the host. In order to check the FQDN of the connection without
138
-opening the Netdata Agent to DNS-spoofing, a reverse-dns record must be setup for the connecting host. At connection
139
-time the reverse-dns of the peer IP address is resolved, and a forward DNS resolution is made to validate the IP address
140
-against the name-pattern.
47
+ WebBrowser->>Netdata1: 3. Now give me the Registry information
48
+ Netdata1-->>WebBrowser: 4. Here it is, talk to Registry 1
49
142
-Please note that this process can be expensive on a machine that is serving many connections. The behaviour of the
143
-pattern matching can be controlled with the following setting:
50
+ WebBrowser->>Registry1: 5. Hey Registry 1, I am accessing Netdata 1...
51
+ Registry1-->>WebBrowser: 6. Nice! Here are other Netdata Agents you have accessed in the past
52
145
-```text
146
-[registry]
147
- allow by dns = heuristic
53
+ Note over WebBrowser: Only your web browser talks to the Registry
54
```
149
-
150
-The settings are:
151
-
152
-- `yes` allows the pattern to match DNS names.
153
-- `no` disables DNS matching for the patterns (they only match IP addresses).
154
-- `heuristic` will estimate if the patterns should match FQDNs by the presence or absence of `:`s or alpha-characters.
155
-
156
-### Where is the registry database stored?
157
-
158
-`/var/lib/netdata/registry/*.db`
159
-
160
-There can be up to 2 files:
161
-
162
-- `registry-log.db`, the transaction log
163
-
164
- all incoming requests that affect the registry are saved in this file in real-time.
165
-
166
-- `registry.db`, the database
167
-
168
- 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`.
169
-
170
-Both files are machine readable text files.
171
-
172
-### How can I disable the SameSite and Secure cookies?
173
-
174
-Beginning with `v1.30.0`, when the Netdata Agent's web server processes a request, it delivers the `SameSite=none`
175
-and `Secure` cookies. If you have problems accessing the local Agent dashboard or Netdata Cloud, disable these
176
-cookies by [editing `netdata.conf`](/docs/netdata-agent/configuration/README.md#edit-a-configuration-file-using-edit-config):
177
-
178
-```text
179
-[registry]
180
- enable cookies SameSite and Secure = no
181
-```
182
-
183
-## The future
184
-
185
-The registry opens a whole world of new possibilities for Netdata. Check here what we think:
186
-<https://github.com/netdata/netdata/issues/416>
187
-
188
-## Troubleshooting the registry
189
-
190
-The registry URL should be set to the URL of a Netdata dashboard. This server has to have `[registry].enabled = yes`.
191
-So, accessing the registry URL directly with your web browser, should present the dashboard of the Netdata operating the
192
-registry.
193
-
194
-To use the registry, your web browser needs to support **third party cookies**, since the cookies are set by the
195
-registry while you are browsing the dashboard of another Netdata server. The registry, the first time it sees a new web
196
-browser it tries to figure if the web browser has cookies enabled or not. It does this by setting a cookie and
197
-redirecting the browser back to itself hoping that it will receive the cookie. If it does not receive the cookie, the
198
-registry will keep redirecting your web browser back to itself, which after a few redirects will fail with an error like
199
-this:
200
-
201
-```text
202
-ERROR 409: Cannot ACCESS netdata registry: https://registry.my-netdata.io responded with: {"status":"redirect","registry":"https://registry.my-netdata.io"}
203
-```
204
-
205
-This error is printed on your web browser console (press F12 on your browser to see it).
src/streaming/README.md
+1
-1
@@ -179,7 +179,7 @@ Valid settings are `dbengine`, `ram`, , or `none`.
179
| `[db]` section | | |
180
| `mode` | `dbengine` | Determines the [database type](/src/database/README.md) to be used on that node. Other options settings include `none`, and `ram`. `none` disables the database at this host. This also disables alerts and notifications, as those can't run without a database. |
181
| `[web]` section | | |
182
-| `mode` | `static-threaded` | Determines the [web server](/src/web/server/README.md) type. The other option is `none`, which disables the dashboard, API, and registry. |
182
+| `mode` | `static-threaded` | Determines the [web server](/src/web/server/README.md) type. The other option is `none`, which disables the dashboard, API, and Registry. |
183
| `accept a streaming request every` | `off` | Set a limit on how often a parent node accepts streaming requests from child nodes. `0` equals no limit. If this is set, you may see `... too busy to accept new streaming request. Will be allowed in X secs` in Netdata's `error.log`. |
184
185
### Basic use cases
src/web/api/queries/README.md
+2
-3
@@ -114,9 +114,8 @@ and they group the values every `group points`.
114
-  applies Holt-Winters double exponential smoothing
115
-  finds the difference of the last vs the first value
116
117
-The examples shown above show live information from the `received` traffic on the `eth0` interface of the global Netdata registry.
118
-Inspect any of the badges to see the parameters provided. You can directly issue the request to the registry server's API yourself, e.g. by
119
-passing the following to get the value shown on the badge for the sum of the values within the period:
117
+The examples shown above show live information from the `received` traffic on the `eth0` interface of the global Netdata Registry.
118
+Inspect any of the badges to see the parameters provided. You can directly issue the request to the Registry server's API yourself, e.g. by passing the following to get the value shown on the badge for the sum of the values within the period:
119
120
```
121
https://registry.my-netdata.io/api/v1/data?chart=net.eth0&options=unaligned&dimensions=received&group=sum&units=kilobits&after=-60&label=sum&points=1
src/web/api/v1/api_v1_badge/README.md
+1
-1
@@ -20,7 +20,7 @@ Similarly, there is [a chart that shows outbound bandwidth per class](http://lon
20
21
The right one is a **volume** calculation. Netdata calculated the total of the last 86.400 seconds (a day) which gives `kilobits`, then divided it by 8 to make it KB, then by 1024 to make it MB and then by 1024 to make it GB. Calculations like this are quite accurate, since for every value collected, every second, Netdata interpolates it to second boundary using microsecond calculations.
22
23
-Let's see a few more badge examples (they come from the [Netdata registry](/src/registry/README.md)):
23
+Let's see a few more badge examples (they come from the [Netdata Registry](/src/registry/README.md)):
24
25
- **cpu usage of user `root`** (you can pick any user; 100% = 1 core). This will be `green <10%`, `yellow <20%`, `orange <50%`, `blue <100%` (1 core), `red` otherwise (you define thresholds and colors on the URL).
26
src/web/server/README.md
+1
-1
@@ -268,7 +268,7 @@ Netdata will:
268
- Force all HTTP requests to the default port to be redirected to HTTPS (same port).
269
- Refuse unencrypted streaming connections from child nodes on the default port.
270
- Allow both HTTP and HTTPS requests to port 20000 for `netdata.conf`
271
-- Force HTTP requests to port 20001 to be redirected to HTTPS (same port). Only allow requests for the dashboard, the read API and the registry on port 20001.
271
+- Force HTTP requests to port 20001 to be redirected to HTTPS (same port). Only allow requests for the dashboard, the read API and the Registry on port 20001.
272
273
#### TLS/SSL errors
274