Change "netdata" to "Netdata" in all docs (#6621)
Change "netdata" to "Netdata" in all docs (#6621) * First pass of changing netdata to Netdata * Second pass of netdata -> Netdata * Starting work on netdata with no whitespace after * Pass for netdata with no whitespace at the end * Pass for netdata with no whitespace at the front
Joel Hans committed
Aug 13, 2019 at 08:07 UTC
a726c905bde122d6a03da9866efb51a2e3b526c2
105 files changed
+788
-794
.travis/README.md
+2
-2
@@ -54,7 +54,7 @@ At this stage, basically, we build :-)
54
We do a baseline check of our build artifacts to guarantee they are not broken
55
Briefly our activities include:
56
- Verify docker builds successfully
57
-- Run the standard netdata installer, to make sure we build & run properly
57
+- Run the standard Netdata installer, to make sure we build & run properly
58
- Do the same through 'make dist', as this is our stable channel for our kickstart files
59
60
## Artifacts validation
@@ -66,7 +66,7 @@ Briefly we currently evaluate the following activities:
66
- Basic software unit testing
67
- Non containerized build and install on ubuntu 14.04
68
- Non containerized build and install on ubuntu 18.04
69
-- Running the full netdata lifecycle (install, update, uninstall) on ubuntu 18.04
69
+- Running the full Netdata lifecycle (install, update, uninstall) on ubuntu 18.04
70
- Build and install on CentOS 6
71
- Build and install on CentOS 7
72
(More to come)
CONTRIBUTING.md
+9
-9
@@ -15,15 +15,15 @@ This is the minimum open-source users should contribute back to the projects the
15
16
### Spread the word
17
18
-Community growth allows the project to attract new talent willing to contribute. This talent is then developing new features and improves the project. These new features and improvements attract more users and so on. It is a loop. So, post about netdata, present it to local meetups you attend, let your online social network or twitter, facebook, reddit, etc. know you are using it. **The more people involved, the faster the project evolves**.
18
+Community growth allows the project to attract new talent willing to contribute. This talent is then developing new features and improves the project. These new features and improvements attract more users and so on. It is a loop. So, post about Netdata, present it to local meetups you attend, let your online social network or twitter, facebook, reddit, etc. know you are using it. **The more people involved, the faster the project evolves**.
19
20
### Provide feedback
21
22
-Is there anything that bothers you about netdata? Did you experience an issue while installing it or using it? Would you like to see it evolve to you need? Let us know. [Open a github issue](https://github.com/netdata/netdata/issues) to discuss it. Feedback is very important for open-source projects. We can't commit we will do everything, but your feedback influences our road-map significantly. **We rely on your feedback to make Netdata better**.
22
+Is there anything that bothers you about Netdata? Did you experience an issue while installing it or using it? Would you like to see it evolve to you need? Let us know. [Open a github issue](https://github.com/netdata/netdata/issues) to discuss it. Feedback is very important for open-source projects. We can't commit we will do everything, but your feedback influences our road-map significantly. **We rely on your feedback to make Netdata better**.
23
24
### Translate some documentation
25
26
-The [netdata localization project](https://github.com/netdata/localization) contains instructions on how to provide translations for parts of our documentation. Translating the entire documentation is a daunting task, but you can contribute as much as you like, even a single file. The Chinese translation effort has already begun and we are looking forward to more contributions.
26
+The [Netdata localization project](https://github.com/netdata/localization) contains instructions on how to provide translations for parts of our documentation. Translating the entire documentation is a daunting task, but you can contribute as much as you like, even a single file. The Chinese translation effort has already begun and we are looking forward to more contributions.
27
28
### Sponsor a part of Netdata
29
@@ -57,7 +57,7 @@ Netdata delivers alarms via various [notification methods](health/notifications)
57
58
### Help other users
59
60
-As the project grows, an increasing share of our time is spent on supporting this community of users in terms of answering questions, of helping users understand how netdata works and find their way with it. Helping other users is crucial. It allows the developers and maintainers of the project to focus on improving it.
60
+As the project grows, an increasing share of our time is spent on supporting this community of users in terms of answering questions, of helping users understand how Netdata works and find their way with it. Helping other users is crucial. It allows the developers and maintainers of the project to focus on improving it.
61
62
### Improve documentation
63
@@ -80,11 +80,11 @@ Of course we appreciate contributions for any other part of the NetData agent, i
80
81
#### Code of Conduct and CLA
82
83
-We expect all contributors to abide by the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). For a pull request to be accepted, you will also need to accept the [netdata contributors license agreement](CONTRIBUTORS.md), as part of the PR process.
83
+We expect all contributors to abide by the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). For a pull request to be accepted, you will also need to accept the [Netdata contributors license agreement](CONTRIBUTORS.md), as part of the PR process.
84
85
#### Performance and efficiency
86
87
-Everything on Netdata is about efficiency. We need netdata to always be the most lightweight monitoring solution available. We will reject to merge PRs that are not optimal in resource utilization and efficiency.
87
+Everything on Netdata is about efficiency. We need Netdata to always be the most lightweight monitoring solution available. We will reject to merge PRs that are not optimal in resource utilization and efficiency.
88
89
Of course there are cases that such technical excellence is either not reasonable or not feasible. In these cases, we may require the feature or code submitted to be by disabled by default.
90
@@ -92,9 +92,9 @@ Of course there are cases that such technical excellence is either not reasonabl
92
93
Unlike other monitoring solutions, Netdata requires all metrics collected to have some structure attached to them. So, Netdata metrics have a name, units, belong to a chart that has a title, a family, a context, belong to an application, etc.
94
95
-This structure is what makes netdata different. Most other monitoring solution collect bulk metrics in terms of name-value pairs and then expect their users to give meaning to these metrics during visualization. This does not work. It is neither practical nor reasonable to give to someone 2000 metrics and let him/her visualize them in a meaningful way.
95
+This structure is what makes Netdata different. Most other monitoring solution collect bulk metrics in terms of name-value pairs and then expect their users to give meaning to these metrics during visualization. This does not work. It is neither practical nor reasonable to give to someone 2000 metrics and let him/her visualize them in a meaningful way.
96
97
-So, netdata requires all metrics to have a meaning at the time they are collected. We will reject to merge PRs that loosely collect just a "bunch of metrics", but we are very keen to help you fix this.
97
+So, Netdata requires all metrics to have a meaning at the time they are collected. We will reject to merge PRs that loosely collect just a "bunch of metrics", but we are very keen to help you fix this.
98
99
#### Automated Testing
100
@@ -106,7 +106,7 @@ Of course, manual testing is always required.
106
107
#### Netdata is a distributed application
108
109
-Netdata is a distributed monitoring application. A few basic features can become quite complicated for such applications. We may reject features that alter or influence the nature of netdata, though we usually discuss the requirements with contributors and help them adapt their code to be better suited for Netdata.
109
+Netdata is a distributed monitoring application. A few basic features can become quite complicated for such applications. We may reject features that alter or influence the nature of Netdata, though we usually discuss the requirements with contributors and help them adapt their code to be better suited for Netdata.
110
111
#### Operating systems supported
112
CONTRIBUTORS.md
+11
-11
@@ -2,9 +2,9 @@
2
SPDX-License-Identifier: GPL-3.0-or-later
3
-->
4
5
-# netdata contributors license agreement
5
+# Netdata contributors license agreement
6
7
-**Thank you for contributing to netdata!**
7
+**Thank you for contributing to Netdata!**
8
9
This agreement is part of the legal framework of the open-source ecosystem
10
that adds some red tape, but protects both the contributor and the project.
@@ -17,22 +17,22 @@ contributions for any other purpose.
17
18
## copyright license
19
20
-The Contributor (*you*) grants netdata Inc. a perpetual, worldwide, non-exclusive,
20
+The Contributor (*you*) grants Netdata Inc. a perpetual, worldwide, non-exclusive,
21
no-charge, royalty-free, irrevocable copyright license to reproduce,
22
prepare derivative works of, publicly display, publicly perform, sublicense,
23
and distribute his contributions and such derivative works.
24
25
## copyright transfer
26
27
-The Contributor (*you*) hereby assigns netdata Inc. copyright in his
27
+The Contributor (*you*) hereby assigns Netdata Inc. copyright in his
28
contributions, to be licensed under the same terms as the rest of the code.
29
30
-> *Note: this means we may re-license netdata (your contributions included)
30
+> *Note: this means we may re-license Netdata (your contributions included)
31
> any way we see fit, without asking your permission.
32
-> We intend to keep the netdata agent forever FOSS.
32
+> We intend to keep the Netdata agent forever FOSS.
33
> But open-source licenses have significant differences and in our attempt to
34
-> help netdata grow we may have to distribute it under a different license.
35
-> For example, CNCF, the Cloud Native Computing Foundation, requires netdata
34
+> help Netdata grow we may have to distribute it under a different license.
35
+> For example, CNCF, the Cloud Native Computing Foundation, requires Netdata
36
> to be licensed under Apache-2.0 for it to be accepted as a member of the
37
> Foundation. We want to be free to do it.*
38
@@ -43,9 +43,9 @@ original creation and that he is legally entitled to grant the above license.
43
44
> *Note: if you are committing third party code, please make sure the third party
45
> license or any other restrictions are also included with your commits.
46
-> netdata includes many third party libraries and tools and this is not a
46
+> Netdata includes many third party libraries and tools and this is not a
47
> problem, provided that the license of the third party code is compatible with
48
-> the one we use for netdata.*
48
+> the one we use for Netdata.*
49
50
## signature
51
@@ -66,7 +66,7 @@ are subject to this agreement.
66
> 1. add your github username and name in this file
67
> 2. commit it to the repo with a PR, using the same github username, or include this change in your first PR.
68
69
-# netdata contributors
69
+# Netdata contributors
70
71
This is the list of contributors that have signed this agreement:
72
README.md
+4
-4
@@ -154,17 +154,17 @@ not just visualize metrics.
154
155
Release v1.16.0 contains 40 bug fixes, 31 improvements and 20 documentation updates
156
157
-**Binary distributions.** To improve the security, speed and reliability of new netdata installations, we are delivering our own, industry standard installation method, with binary package distributions. The RPM binaries for the most common OSs are already available on packagecloud and we’ll have the DEB ones available very soon. All distributions are considered in Beta and, as always, we depend on our amazing community for feedback on improvements.
157
+**Binary distributions.** To improve the security, speed and reliability of new Netdata installations, we are delivering our own, industry standard installation method, with binary package distributions. The RPM binaries for the most common OSs are already available on packagecloud and we’ll have the DEB ones available very soon. All distributions are considered in Beta and, as always, we depend on our amazing community for feedback on improvements.
158
159
- Our stable distributions are at [netdata/netdata @ packagecloud.io](https://packagecloud.io/netdata/netdata)
160
- The nightly builds are at [netdata/netdata-edge @ packagecloud.io](https://packagecloud.io/netdata/netdata-edge)
161
162
**Netdata now supports TLS encryption!** You can secure the communication to the [web server](https://docs.netdata.cloud/web/server/#enabling-tls-support), the [streaming connections from slaves to the master](https://docs.netdata.cloud/streaming/#securing-the-communication) and the connection to an [openTSDB backend](https://docs.netdata.cloud/backends/opentsdb/#https).
163
164
-**This version also brings two long-awaited features to netdata’s health monitoring:**
164
+**This version also brings two long-awaited features to Netdata’s health monitoring:**
165
166
- - The [health management API](https://docs.netdata.cloud/web/api/health/#health-management-api) introduced in v1.12 allowed you to easily disable alarms and/or notifications while netdata was running. However, those changes were not persisted across netdata restarts. Since part of routine maintenance activities may involve completely restarting a monitoring node, netdata now saves these configurations to disk, every time you issue a command to change the silencer settings. The new [LIST command](https://docs.netdata.cloud/web/api/health/#list-silencers) of the API allows you to view at any time which alarms are currently disabled or silenced.
167
- - A way for netdata to [repeatedly send alarm notifications](https://docs.netdata.cloud/health/#alarm-line-repeat) for some, or all active alarms, at a frequency of your choosing. As a result, you will no longer have to worry about missing a notification, forgetting about a raised alarm. The default is still to only send a single notification, so that existing users are not surprised by a different behavior.
166
+ - The [health management API](https://docs.netdata.cloud/web/api/health/#health-management-api) introduced in v1.12 allowed you to easily disable alarms and/or notifications while Netdata was running. However, those changes were not persisted across Netdata restarts. Since part of routine maintenance activities may involve completely restarting a monitoring node, Netdata now saves these configurations to disk, every time you issue a command to change the silencer settings. The new [LIST command](https://docs.netdata.cloud/web/api/health/#list-silencers) of the API allows you to view at any time which alarms are currently disabled or silenced.
167
+ - A way for Netdata to [repeatedly send alarm notifications](https://docs.netdata.cloud/health/#alarm-line-repeat) for some, or all active alarms, at a frequency of your choosing. As a result, you will no longer have to worry about missing a notification, forgetting about a raised alarm. The default is still to only send a single notification, so that existing users are not surprised by a different behavior.
168
169
As always, we’ve introduced new collectors, 5 of them this time:
170
REDISTRIBUTED.md
+4
-4
@@ -1,16 +1,16 @@
1
# Redistributed software
2
3
-netdata copyright info:
3
+Netdata copyright info:
4
Copyright 2016-2018, Costa Tsaousis.
5
Copyright 2018, Netdata Inc.
6
Released under [GPL v3 or later](LICENSE).
7
8
-netdata uses SPDX license tags to identify the license for its files.
8
+Netdata uses SPDX license tags to identify the license for its files.
9
Individual licenses referenced in the tags are available on the [SPDX project site](http://spdx.org/licenses/).
10
11
-netdata redistributes the following third-party software.
11
+Netdata redistributes the following third-party software.
12
We have decided to redistribute all these, instead of using them
13
-through a CDN, to allow netdata to work in cases where Internet
13
+through a CDN, to allow Netdata to work in cases where Internet
14
connectivity is not available.
15
16
- [Dygraphs](http://dygraphs.com/)
backends/README.md
+37
-37
@@ -1,15 +1,15 @@
1
# Metrics long term archiving
2
3
-netdata supports backends for archiving the metrics, or providing long term dashboards,
3
+Netdata supports backends for archiving the metrics, or providing long term dashboards,
4
using Grafana or other tools, like this:
5
6
7
8
-Since netdata collects thousands of metrics per server per second, which would easily congest any backend
9
-server when several netdata servers are sending data to it, netdata allows sending metrics at a lower
8
+Since Netdata collects thousands of metrics per server per second, which would easily congest any backend
9
+server when several Netdata servers are sending data to it, Netdata allows sending metrics at a lower
10
frequency, by resampling them.
11
12
-So, although netdata collects metrics every second, it can send to the backend servers averages or sums every
12
+So, although Netdata collects metrics every second, it can send to the backend servers averages or sums every
13
X seconds (though, it can send them per second if you need it to).
14
15
## features
@@ -30,7 +30,7 @@ X seconds (though, it can send them per second if you need it to).
30
31
metrics are sent to a document db, `JSON` formatted.
32
33
- - **prometheus** is described at [prometheus page](prometheus/) since it pulls data from netdata.
33
+ - **prometheus** is described at [prometheus page](prometheus/) since it pulls data from Netdata.
34
35
- **prometheus remote write** (a binary snappy-compressed protocol buffer encoding over HTTP used by
36
**Elasticsearch**, **Gnocchi**, **Graphite**, **InfluxDB**, **Kafka**, **OpenTSDB**,
@@ -54,26 +54,26 @@ X seconds (though, it can send them per second if you need it to).
54
So, counters are sent as counters and gauges are sent as gauges, much like all data collectors do.
55
For example, to calculate CPU utilization in this format, you need to know how to convert kernel ticks to percentage.
56
57
- - `average` sends to backends normalized metrics from the netdata database.
58
- In this mode, all metrics are sent as gauges, in the units netdata uses. This abstracts data collection
57
+ - `average` sends to backends normalized metrics from the Netdata database.
58
+ In this mode, all metrics are sent as gauges, in the units Netdata uses. This abstracts data collection
59
and simplifies visualization, but you will not be able to copy and paste queries from other sources to convert units.
60
- For example, CPU utilization percentage is calculated by netdata, so netdata will convert ticks to percentage and
60
+ For example, CPU utilization percentage is calculated by Netdata, so Netdata will convert ticks to percentage and
61
send the average percentage to the backend.
62
63
- - `sum` or `volume`: the sum of the interpolated values shown on the netdata graphs is sent to the backend.
64
- So, if netdata is configured to send data to the backend every 10 seconds, the sum of the 10 values shown on the
65
- netdata charts will be used.
63
+ - `sum` or `volume`: the sum of the interpolated values shown on the Netdata graphs is sent to the backend.
64
+ So, if Netdata is configured to send data to the backend every 10 seconds, the sum of the 10 values shown on the
65
+ Netdata charts will be used.
66
67
Time-series databases suggest to collect the raw values (`as-collected`). If you plan to invest on building your monitoring around a time-series database and you already know (or you will invest in learning) how to convert units and normalize the metrics in Grafana or other visualization tools, we suggest to use `as-collected`.
68
69
-If, on the other hand, you just need long term archiving of netdata metrics and you plan to mainly work with netdata, we suggest to use `average`. It decouples visualization from data collection, so it will generally be a lot simpler. Furthermore, if you use `average`, the charts shown in the back-end will match exactly what you see in Netdata, which is not necessarily true for the other modes of operation.
69
+If, on the other hand, you just need long term archiving of Netdata metrics and you plan to mainly work with Netdata, we suggest to use `average`. It decouples visualization from data collection, so it will generally be a lot simpler. Furthermore, if you use `average`, the charts shown in the back-end will match exactly what you see in Netdata, which is not necessarily true for the other modes of operation.
70
71
-5. This code is smart enough, not to slow down netdata, independently of the speed of the backend server.
71
+5. This code is smart enough, not to slow down Netdata, independently of the speed of the backend server.
72
73
## configuration
74
75
In `/etc/netdata/netdata.conf` you should have something like this (if not download the latest version
76
-of `netdata.conf` from your netdata):
76
+of `netdata.conf` from your Netdata):
77
78
```
79
[backend]
@@ -82,7 +82,7 @@ of `netdata.conf` from your netdata):
82
host tags = list of TAG=VALUE
83
destination = space separated list of [PROTOCOL:]HOST[:PORT] - the first working will be used, or a region for kinesis
84
data source = average | sum | as collected
85
- prefix = netdata
85
+ prefix = Netdata
86
hostname = my-name
87
update every = 10
88
buffer on failures = 10
@@ -122,13 +122,13 @@ of `netdata.conf` from your netdata):
122
destination = [ffff:...:0001]:2003 10.11.12.1:2003
123
```
124
125
- When multiple servers are defined, netdata will try the next one when the first one fails. This allows
126
- you to load-balance different servers: give your backend servers in different order on each netdata.
125
+ When multiple servers are defined, Netdata will try the next one when the first one fails. This allows
126
+ you to load-balance different servers: give your backend servers in different order on each Netdata.
127
128
- netdata also ships [`nc-backend.sh`](nc-backend.sh),
128
+ Netdata also ships [`nc-backend.sh`](nc-backend.sh),
129
a script that can be used as a fallback backend to save the metrics to disk and push them to the
130
time-series database when it becomes available again. It can also be used to monitor / trace / debug
131
- the metrics netdata generates.
131
+ the metrics Netdata generates.
132
133
For kinesis backend `destination` should be set to an AWS region (for example, `us-east-1`).
134
@@ -138,16 +138,16 @@ of `netdata.conf` from your netdata):
138
- `hostname = my-name`, is the hostname to be used for sending data to the backend server. By default
139
this is `[global].hostname`.
140
141
-- `prefix = netdata`, is the prefix to add to all metrics.
141
+- `prefix = Netdata`, is the prefix to add to all metrics.
142
143
-- `update every = 10`, is the number of seconds between sending data to the backend. netdata will add
144
- some randomness to this number, to prevent stressing the backend server when many netdata servers send
143
+- `update every = 10`, is the number of seconds between sending data to the backend. Netdata will add
144
+ some randomness to this number, to prevent stressing the backend server when many Netdata servers send
145
data to the same backend. This randomness does not affect the quality of the data, only the time they
146
are sent.
147
148
- `buffer on failures = 10`, is the number of iterations (each iteration is `[backend].update every` seconds)
149
to buffer data, when the backend is not available. If the backend fails to receive the data after that
150
- many failures, data loss on the backend is expected (netdata will also log it).
150
+ many failures, data loss on the backend is expected (Netdata will also log it).
151
152
- `timeout ms = 20000`, is the timeout in milliseconds to wait for the backend server to process the data.
153
By default this is `2 * update_every * 1000`.
@@ -155,7 +155,7 @@ of `netdata.conf` from your netdata):
155
- `send hosts matching = localhost *` includes one or more space separated patterns, using ` * ` as wildcard
156
(any number of times within each pattern). The patterns are checked against the hostname (the localhost
157
is always checked as `localhost`), allowing us to filter which hosts will be sent to the backend when
158
- this netdata is a central netdata aggregating multiple hosts. A pattern starting with ` ! ` gives a
158
+ this Netdata is a central Netdata aggregating multiple hosts. A pattern starting with ` ! ` gives a
159
negative match. So to match all hosts named `*db*` except hosts containing `*slave*`, use
160
`!*slave* *db*` (so, the order is important: the first pattern matching the hostname will be used - positive
161
or negative).
@@ -166,8 +166,8 @@ of `netdata.conf` from your netdata):
166
except charts ending in `*reads`, use `!*reads apps.*` (so, the order is important: the first pattern
167
matching the chart id or the chart name will be used - positive or negative).
168
169
-- `send names instead of ids = yes | no` controls the metric names netdata should send to backend.
170
- netdata supports names and IDs for charts and dimensions. Usually IDs are unique identifiers as read
169
+- `send names instead of ids = yes | no` controls the metric names Netdata should send to backend.
170
+ Netdata supports names and IDs for charts and dimensions. Usually IDs are unique identifiers as read
171
by the system and names are human friendly labels (also unique). Most charts and metrics have the same
172
ID and name, but in several cases they are different: disks with device-mapper, interrupts, QoS classes,
173
statsd synthetic charts, etc.
@@ -176,26 +176,26 @@ of `netdata.conf` from your netdata):
176
These are currently only sent to opentsdb and prometheus. Please use the appropriate format for each
177
time-series db. For example opentsdb likes them like `TAG1=VALUE1 TAG2=VALUE2`, but prometheus like
178
`tag1="value1",tag2="value2"`. Host tags are mirrored with database replication (streaming of metrics
179
- between netdata servers).
179
+ between Netdata servers).
180
181
## monitoring operation
182
183
-netdata provides 5 charts:
183
+Netdata provides 5 charts:
184
185
-1. **Buffered metrics**, the number of metrics netdata added to the buffer for dispatching them to the
185
+1. **Buffered metrics**, the number of metrics Netdata added to the buffer for dispatching them to the
186
backend server.
187
188
-2. **Buffered data size**, the amount of data (in KB) netdata added the buffer.
188
+2. **Buffered data size**, the amount of data (in KB) Netdata added the buffer.
189
190
-3. ~~**Backend latency**, the time the backend server needed to process the data netdata sent.
190
+3. ~~**Backend latency**, the time the backend server needed to process the data Netdata sent.
191
If there was a re-connection involved, this includes the connection time.~~
192
- (this chart has been removed, because it only measures the time netdata needs to give the data
193
- to the O/S - since the backend servers do not ack the reception, netdata does not have any means
192
+ (this chart has been removed, because it only measures the time Netdata needs to give the data
193
+ to the O/S - since the backend servers do not ack the reception, Netdata does not have any means
194
to measure this properly).
195
196
-4. **Backend operations**, the number of operations performed by netdata.
196
+4. **Backend operations**, the number of operations performed by Netdata.
197
198
-5. **Backend thread CPU usage**, the CPU resources consumed by the netdata thread, that is responsible
198
+5. **Backend thread CPU usage**, the CPU resources consumed by the Netdata thread, that is responsible
199
for sending the metrics to the backend server.
200
201
@@ -204,12 +204,12 @@ netdata provides 5 charts:
204
205
The latest version of the alarms configuration for monitoring the backend is [here](../health/health.d/backend.conf)
206
207
-netdata adds 4 alarms:
207
+Netdata adds 4 alarms:
208
209
1. `backend_last_buffering`, number of seconds since the last successful buffering of backend data
210
2. `backend_metrics_sent`, percentage of metrics sent to the backend server
211
3. `backend_metrics_lost`, number of metrics lost due to repeating failures to contact the backend server
212
-4. ~~`backend_slow`, the percentage of time between iterations needed by the backend time to process the data sent by netdata~~ (this was misleading and has been removed).
212
+4. ~~`backend_slow`, the percentage of time between iterations needed by the backend time to process the data sent by Netdata~~ (this was misleading and has been removed).
213
214
215
backends/WALKTHROUGH.md
+3
-3
@@ -41,7 +41,7 @@ visibility into your application and systems performance.
41
42
## Getting Started - Netdata
43
To begin let’s create our container which we will install Netdata on. We need
44
-to run a container, forward the necessary port that netdata listens on, and
44
+to run a container, forward the necessary port that Netdata listens on, and
45
attach a tty so we can interact with the bash shell on the container. But
46
before we do this we want name resolution between the two containers to work.
47
In order to accomplish this we will create a user-defined network and attach
@@ -68,7 +68,7 @@ be sitting inside the shell of the container.
68
69
After we have entered the shell we can install Netdata. This process could not
70
be easier. If you take a look at [this link](../packaging/installer/#installation), the Netdata devs give us
71
-several one-liners to install netdata. I have not had any issues with these one
71
+several one-liners to install Netdata. I have not had any issues with these one
72
liners and their bootstrapping scripts so far (If you guys run into anything do
73
share). Run the following command in your container.
74
@@ -97,7 +97,7 @@ Netdata dashboard.
97
98
99
This CHART is called ‘system.cpu’, The FAMILY is cpu, and the DIMENSION we are
100
-observing is “system”. You can begin to draw links between the charts in netdata
100
+observing is “system”. You can begin to draw links between the charts in Netdata
101
to the prometheus metrics format in this manner.
102
103
## Prometheus
backends/aws_kinesis/README.md
+4
-4
@@ -1,8 +1,8 @@
1
-# Using netdata with AWS Kinesis Data Streams
1
+# Using Netdata with AWS Kinesis Data Streams
2
3
## Prerequisites
4
5
-To use AWS Kinesis as a backend AWS SDK for C++ should be [installed](https://docs.aws.amazon.com/en_us/sdk-for-cpp/v1/developer-guide/setup.html) first. `libcrypto`, `libssl`, and `libcurl` are also required to compile netdata with Kinesis support enabled. Next, netdata should be re-installed from the source. The installer will detect that the required libraries are now available.
5
+To use AWS Kinesis as a backend AWS SDK for C++ should be [installed](https://docs.aws.amazon.com/en_us/sdk-for-cpp/v1/developer-guide/setup.html) first. `libcrypto`, `libssl`, and `libcurl` are also required to compile Netdata with Kinesis support enabled. Next, Netdata should be re-installed from the source. The installer will detect that the required libraries are now available.
6
7
If the AWS SDK for C++ is being installed from source, it is useful to set `-DBUILD_ONLY="kinesis"`. Otherwise, the building process could take a very long time. Take a note, that the default installation path for the libraries is `/usr/local/lib64`. Many Linux distributions don't include this path as the default one for a library search, so it is advisable to use the following options to `cmake` while building the AWS SDK:
8
@@ -21,7 +21,7 @@ To enable data sending to the kinesis backend set the following options in `netd
21
```
22
set the `destination` option to an AWS region.
23
24
-In the netdata configuration directory run `./edit-config aws_kinesis.conf` and set AWS credentials and stream name:
24
+In the Netdata configuration directory run `./edit-config aws_kinesis.conf` and set AWS credentials and stream name:
25
```
26
# AWS credentials
27
aws_access_key_id = your_access_key_id
@@ -32,7 +32,7 @@ stream name = your_stream_name
32
```
33
Alternatively, AWS credentials can be set for the *netdata* user using AWS SDK for C++ [standard methods](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/credentials.html).
34
35
-A partition key for every record is computed automatically by the netdata with the purpose to distribute records across available shards evenly.
35
+A partition key for every record is computed automatically by Netdata with the purpose to distribute records across available shards evenly.
36
37
38
[]()
backends/prometheus/README.md
+40
-40
@@ -1,32 +1,32 @@
1
-# Using netdata with Prometheus
1
+# Using Netdata with Prometheus
2
3
-> IMPORTANT: the format netdata sends metrics to prometheus has changed since netdata v1.7. The new prometheus backend for netdata supports a lot more features and is aligned to the development of the rest of the netdata backends.
3
+> IMPORTANT: the format Netdata sends metrics to prometheus has changed since Netdata v1.7. The new prometheus backend for Netdata supports a lot more features and is aligned to the development of the rest of the Netdata backends.
4
5
-Prometheus is a distributed monitoring system which offers a very simple setup along with a robust data model. Recently netdata added support for Prometheus. I'm going to quickly show you how to install both netdata and prometheus on the same server. We can then use grafana pointed at Prometheus to obtain long term metrics netdata offers. I'm assuming we are starting at a fresh ubuntu shell (whether you'd like to follow along in a VM or a cloud instance is up to you).
5
+Prometheus is a distributed monitoring system which offers a very simple setup along with a robust data model. Recently Netdata added support for Prometheus. I'm going to quickly show you how to install both Netdata and prometheus on the same server. We can then use grafana pointed at Prometheus to obtain long term metrics Netdata offers. I'm assuming we are starting at a fresh ubuntu shell (whether you'd like to follow along in a VM or a cloud instance is up to you).
6
7
8
-## Installing netdata and prometheus
8
+## Installing Netdata and prometheus
9
10
-### Installing netdata
10
+### Installing Netdata
11
12
-There are number of ways to install netdata according to [Installation](../../packaging/installer/#installation)
13
-The suggested way of installing the latest netdata and keep it upgrade automatically. Using one line installation:
12
+There are number of ways to install Netdata according to [Installation](../../packaging/installer/#installation)
13
+The suggested way of installing the latest Netdata and keep it upgrade automatically. Using one line installation:
14
15
```
16
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
17
```
18
19
-At this point we should have netdata listening on port 19999. Attempt to take your browser here:
19
+At this point we should have Netdata listening on port 19999. Attempt to take your browser here:
20
21
```
22
http://your.netdata.ip:19999
23
```
24
25
-*(replace `your.netdata.ip` with the IP or hostname of the server running netdata)*
25
+*(replace `your.netdata.ip` with the IP or hostname of the server running Netdata)*
26
27
### Installing Prometheus
28
29
-In order to install prometheus we are going to introduce our own systemd startup script along with an example of prometheus.yaml configuration. Prometheus needs to be pointed to your server at a specific target url for it to scrape netdata's api. Prometheus is always a pull model meaning netdata is the passive client within this architecture. Prometheus always initiates the connection with netdata.
29
+In order to install prometheus we are going to introduce our own systemd startup script along with an example of prometheus.yaml configuration. Prometheus needs to be pointed to your server at a specific target url for it to scrape Netdata's api. Prometheus is always a pull model meaning Netdata is the passive client within this architecture. Prometheus always initiates the connection with Netdata.
30
31
#### Download Prometheus
32
@@ -57,7 +57,7 @@ sudo tar -xvf /tmp/prometheus-2.3.2.linux-amd64.tar.gz -C /opt/prometheus --stri
57
58
We will use the following `prometheus.yml` file. Save it at `/opt/prometheus/prometheus.yml`.
59
60
-Make sure to replace `your.netdata.ip` with the IP or hostname of the host running netdata.
60
+Make sure to replace `your.netdata.ip` with the IP or hostname of the host running Netdata.
61
62
```yaml
63
# my global config
@@ -101,7 +101,7 @@ scrape_configs:
101
#source: [as-collected]
102
#
103
# server name for this prometheus - the default is the client IP
104
- # for netdata to uniquely identify it
104
+ # for Netdata to uniquely identify it
105
#server: ['prometheus1']
106
honor_labels: true
107
@@ -180,21 +180,21 @@ sudo systemctl enable prometheus
180
181
Prometheus should now start and listen on port 9090. Attempt to head there with your browser.
182
183
-If everything is working correctly when you fetch `http://your.prometheus.ip:9090` you will see a 'Status' tab. Click this and click on 'targets' We should see the netdata host as a scraped target.
183
+If everything is working correctly when you fetch `http://your.prometheus.ip:9090` you will see a 'Status' tab. Click this and click on 'targets' We should see the Netdata host as a scraped target.
184
185
---
186
187
## Netdata support for prometheus
188
189
-> IMPORTANT: the format netdata sends metrics to prometheus has changed since netdata v1.6. The new format allows easier queries for metrics and supports both `as collected` and normalized metrics.
189
+> IMPORTANT: the format Netdata sends metrics to prometheus has changed since Netdata v1.6. The new format allows easier queries for metrics and supports both `as collected` and normalized metrics.
190
191
-Before explaining the changes, we have to understand the key differences between netdata and prometheus.
191
+Before explaining the changes, we have to understand the key differences between Netdata and prometheus.
192
193
-### understanding netdata metrics
193
+### understanding Netdata metrics
194
195
##### charts
196
197
-Each chart in netdata has several properties (common to all its metrics):
197
+Each chart in Netdata has several properties (common to all its metrics):
198
199
- `chart_id` - uniquely identifies a chart.
200
@@ -208,32 +208,32 @@ Each chart in netdata has several properties (common to all its metrics):
208
209
##### dimensions
210
211
-Then each netdata chart contains metrics called `dimensions`. All the dimensions of a chart have the same units of measurement, and are contextually in the same category (ie. the metrics for disk bandwidth are `read` and `write` and they are both in the same chart).
211
+Then each Netdata chart contains metrics called `dimensions`. All the dimensions of a chart have the same units of measurement, and are contextually in the same category (ie. the metrics for disk bandwidth are `read` and `write` and they are both in the same chart).
212
213
-### netdata data source
213
+### Netdata data source
214
215
Netdata can send metrics to prometheus from 3 data sources:
216
217
-- `as collected` or `raw` - this data source sends the metrics to prometheus as they are collected. No conversion is done by netdata. The latest value for each metric is just given to prometheus. This is the most preferred method by prometheus, but it is also the harder to work with. To work with this data source, you will need to understand how to get meaningful values out of them.
217
+- `as collected` or `raw` - this data source sends the metrics to prometheus as they are collected. No conversion is done by Netdata. The latest value for each metric is just given to prometheus. This is the most preferred method by prometheus, but it is also the harder to work with. To work with this data source, you will need to understand how to get meaningful values out of them.
218
219
The format of the metrics is: `CONTEXT{chart="CHART",family="FAMILY",dimension="DIMENSION"}`.
220
221
- If the metric is a counter (`incremental` in netdata lingo), `_total` is appended the context.
221
+ If the metric is a counter (`incremental` in Netdata lingo), `_total` is appended the context.
222
223
- Unlike prometheus, netdata allows each dimension of a chart to have a different algorithm and conversion constants (`multiplier` and `divisor`). In this case, that the dimensions of a charts are heterogeneous, netdata will use this format: `CONTEXT_DIMENSION{chart="CHART",family="FAMILY"}`
223
+ Unlike prometheus, Netdata allows each dimension of a chart to have a different algorithm and conversion constants (`multiplier` and `divisor`). In this case, that the dimensions of a charts are heterogeneous, Netdata will use this format: `CONTEXT_DIMENSION{chart="CHART",family="FAMILY"}`
224
225
-- `average` - this data source uses the netdata database to send the metrics to prometheus as they are presented on the netdata dashboard. So, all the metrics are sent as gauges, at the units they are presented in the netdata dashboard charts. This is the easiest to work with.
225
+- `average` - this data source uses the Netdata database to send the metrics to prometheus as they are presented on the Netdata dashboard. So, all the metrics are sent as gauges, at the units they are presented in the Netdata dashboard charts. This is the easiest to work with.
226
227
The format of the metrics is: `CONTEXT_UNITS_average{chart="CHART",family="FAMILY",dimension="DIMENSION"}`.
228
229
- When this source is used, netdata keeps track of the last access time for each prometheus server fetching the metrics. This last access time is used at the subsequent queries of the same prometheus server to identify the time-frame the `average` will be calculated. So, no matter how frequently prometheus scrapes netdata, it will get all the database data. To identify each prometheus server, netdata uses by default the IP of the client fetching the metrics. If there are multiple prometheus servers fetching data from the same netdata, using the same IP, each prometheus server can append `server=NAME` to the URL. Netdata will use this `NAME` to uniquely identify the prometheus server.
229
+ When this source is used, Netdata keeps track of the last access time for each prometheus server fetching the metrics. This last access time is used at the subsequent queries of the same prometheus server to identify the time-frame the `average` will be calculated. So, no matter how frequently prometheus scrapes Netdata, it will get all the database data. To identify each prometheus server, Netdata uses by default the IP of the client fetching the metrics. If there are multiple prometheus servers fetching data from the same Netdata, using the same IP, each prometheus server can append `server=NAME` to the URL. Netdata will use this `NAME` to uniquely identify the prometheus server.
230
231
- `sum` or `volume`, is like `average` but instead of averaging the values, it sums them.
232
233
The format of the metrics is: `CONTEXT_UNITS_sum{chart="CHART",family="FAMILY",dimension="DIMENSION"}`.
234
All the other operations are the same with `average`.
235
236
-Keep in mind that early versions of netdata were sending the metrics as: `CHART_DIMENSION{}`.
236
+Keep in mind that early versions of Netdata were sending the metrics as: `CHART_DIMENSION{}`.
237
238
### Querying Metrics
239
@@ -241,11 +241,11 @@ Fetch with your web browser this URL:
241
242
`http://your.netdata.ip:19999/api/v1/allmetrics?format=prometheus&help=yes`
243
244
-*(replace `your.netdata.ip` with the ip or hostname of your netdata server)*
244
+*(replace `your.netdata.ip` with the ip or hostname of your Netdata server)*
245
246
-netdata will respond with all the metrics it sends to prometheus.
246
+Netdata will respond with all the metrics it sends to prometheus.
247
248
-If you search that page for `"system.cpu"` you will find all the metrics netdata is exporting to prometheus for this chart. `system.cpu` is the chart name on the netdata dashboard (on the netdata dashboard all charts have a text heading such as : `Total CPU utilization (system.cpu)`. What we are interested here in the chart name: `system.cpu`).
248
+If you search that page for `"system.cpu"` you will find all the metrics Netdata is exporting to prometheus for this chart. `system.cpu` is the chart name on the Netdata dashboard (on the Netdata dashboard all charts have a text heading such as : `Total CPU utilization (system.cpu)`. What we are interested here in the chart name: `system.cpu`).
249
250
Searching for `"system.cpu"` reveals:
251
@@ -272,7 +272,7 @@ netdata_system_cpu_percentage_average{chart="system.cpu",family="cpu",dimension=
272
# COMMENT netdata_system_cpu_percentage_average: dimension "idle", value is percentage, gauge, dt 1500066653 to 1500066662 inclusive
273
netdata_system_cpu_percentage_average{chart="system.cpu",family="cpu",dimension="idle"} 92.3630770 1500066662000
274
```
275
-*(netdata response for `system.cpu` with source=`average`)*
275
+*(Netdata response for `system.cpu` with source=`average`)*
276
277
In `average` or `sum` data sources, all values are normalized and are reported to prometheus as gauges. Now, use the 'expression' text form in prometheus. Begin to type the metrics we are looking for: `netdata_system_cpu`. You should see that the text form begins to auto-fill as prometheus knows about this metric.
278
@@ -302,13 +302,13 @@ netdata_system_cpu_total{chart="system.cpu",family="cpu",dimension="iowait"} 233
302
netdata_system_cpu_total{chart="system.cpu",family="cpu",dimension="idle"} 918470 1500066716438
303
```
304
305
-*(netdata response for `system.cpu` with source=`as-collected`)*
305
+*(Netdata response for `system.cpu` with source=`as-collected`)*
306
307
For more information check prometheus documentation.
308
309
### Streaming data from upstream hosts
310
311
-The `format=prometheus` parameter only exports the host's netdata metrics. If you are using the master/slave functionality of netdata this ignores any upstream hosts - so you should consider using the below in your **prometheus.yml**:
311
+The `format=prometheus` parameter only exports the host's Netdata metrics. If you are using the master/slave functionality of Netdata this ignores any upstream hosts - so you should consider using the below in your **prometheus.yml**:
312
313
```
314
metrics_path: '/api/v1/allmetrics'
@@ -321,13 +321,13 @@ This will report all upstream host data, and `honor_labels` will make Prometheus
321
322
### Timestamps
323
324
-To pass the metrics through prometheus pushgateway, netdata supports the option `×tamps=no` to send the metrics without timestamps.
324
+To pass the metrics through prometheus pushgateway, Netdata supports the option `×tamps=no` to send the metrics without timestamps.
325
326
## Netdata host variables
327
328
-netdata collects various system configuration metrics, like the max number of TCP sockets supported, the max number of files allowed system-wide, various IPC sizes, etc. These metrics are not exposed to prometheus by default.
328
+Netdata collects various system configuration metrics, like the max number of TCP sockets supported, the max number of files allowed system-wide, various IPC sizes, etc. These metrics are not exposed to prometheus by default.
329
330
-To expose them, append `variables=yes` to the netdata URL.
330
+To expose them, append `variables=yes` to the Netdata URL.
331
332
### TYPE and HELP
333
@@ -335,7 +335,7 @@ To save bandwidth, and because prometheus does not use them anyway, `# TYPE` and
335
336
### Names and IDs
337
338
-netdata supports names and IDs for charts and dimensions. Usually IDs are unique identifiers as read by the system and names are human friendly labels (also unique).
338
+Netdata supports names and IDs for charts and dimensions. Usually IDs are unique identifiers as read by the system and names are human friendly labels (also unique).
339
340
Most charts and metrics have the same ID and name, but in several cases they are different: disks with device-mapper, interrupts, QoS classes, statsd synthetic charts, etc.
341
@@ -353,7 +353,7 @@ You can overwrite it from prometheus, by appending to the URL:
353
354
### Filtering metrics sent to prometheus
355
356
-netdata can filter the metrics it sends to prometheus with this setting:
356
+Netdata can filter the metrics it sends to prometheus with this setting:
357
358
```
359
[backend]
@@ -362,9 +362,9 @@ netdata can filter the metrics it sends to prometheus with this setting:
362
363
This settings accepts a space separated list of patterns to match the **charts** to be sent to prometheus. Each pattern can use ` * ` as wildcard, any number of times (e.g `*a*b*c*` is valid). Patterns starting with ` ! ` give a negative match (e.g `!*.bad users.* groups.*` will send all the users and groups except `bad` user and `bad` group). The order is important: the first match (positive or negative) left to right, is used.
364
365
-### Changing the prefix of netdata metrics
365
+### Changing the prefix of Netdata metrics
366
367
-netdata sends all metrics prefixed with `netdata_`. You can change this in `netdata.conf`, like this:
367
+Netdata sends all metrics prefixed with `netdata_`. You can change this in `netdata.conf`, like this:
368
369
```
370
[backend]
@@ -383,8 +383,8 @@ To get the metric names as they were before v1.12, append to the URL `&oldunits=
383
384
### Accuracy of `average` and `sum` data sources
385
386
-When the data source is set to `average` or `sum`, netdata remembers the last access of each client accessing prometheus metrics and uses this last access time to respond with the `average` or `sum` of all the entries in the database since that. This means that prometheus servers are not losing data when they access netdata with data source = `average` or `sum`.
386
+When the data source is set to `average` or `sum`, Netdata remembers the last access of each client accessing prometheus metrics and uses this last access time to respond with the `average` or `sum` of all the entries in the database since that. This means that prometheus servers are not losing data when they access Netdata with data source = `average` or `sum`.
387
388
-To uniquely identify each prometheus server, netdata uses the IP of the client accessing the metrics. If however the IP is not good enough for identifying a single prometheus server (e.g. when prometheus servers are accessing netdata through a web proxy, or when multiple prometheus servers are NATed to a single IP), each prometheus may append `&server=NAME` to the URL. This `NAME` is used by netdata to uniquely identify each prometheus server and keep track of its last access time.
388
+To uniquely identify each prometheus server, Netdata uses the IP of the client accessing the metrics. If however the IP is not good enough for identifying a single prometheus server (e.g. when prometheus servers are accessing Netdata through a web proxy, or when multiple prometheus servers are NATed to a single IP), each prometheus may append `&server=NAME` to the URL. This `NAME` is used by Netdata to uniquely identify each prometheus server and keep track of its last access time.
389
390
[]()
backends/prometheus/remote_write/README.md
+1
-1
@@ -2,7 +2,7 @@
2
3
## Prerequisites
4
5
-To use the prometheus remote write API with [storage providers](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage) [protobuf](https://developers.google.com/protocol-buffers/) and [snappy](https://github.com/google/snappy) libraries should be installed first. Next, netdata should be re-installed from the source. The installer will detect that the required libraries and utilities are now available.
5
+To use the prometheus remote write API with [storage providers](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage) [protobuf](https://developers.google.com/protocol-buffers/) and [snappy](https://github.com/google/snappy) libraries should be installed first. Next, Netdata should be re-installed from the source. The installer will detect that the required libraries and utilities are now available.
6
7
## Configuration
8
collectors/README.md
+12
-13
@@ -1,20 +1,20 @@
1
# Data collection plugins
2
3
-netdata supports **internal** and **external** data collection plugins:
3
+Netdata supports **internal** and **external** data collection plugins:
4
5
-- **internal** plugins are written in `C` and run as threads inside the netdata daemon.
5
+- **internal** plugins are written in `C` and run as threads inside the `netdat`a` daemon.
6
7
-- **external** plugins may be written in any computer language and are spawn as independent long-running processes by the netdata daemon.
8
- They communicate with the netdata daemon via `pipes` (`stdout` communication).
7
+- **external** plugins may be written in any computer language and are spawn as independent long-running processes by the `netdata` daemon.
8
+ They communicate with the `netdata` daemon via `pipes` (`stdout` communication).
9
10
-To minimize the number of processes spawn for data collection, netdata also supports **plugin orchestrators**.
10
+To minimize the number of processes spawn for data collection, Netdata also supports **plugin orchestrators**.
11
12
- **plugin orchestrators** are external plugins that do not collect any data by themeselves.
13
Instead they support data collection **modules** written in the language of the orchestrator.
14
Usually the orchestrator provides a higher level abstraction, making it ideal for writing new
15
data collection modules with the minimum of code.
16
17
- Currently netdata provides plugin orchestrators
17
+ Currently Netdata provides plugin orchestrators
18
BASH v4+ [charts.d.plugin](charts.d.plugin/),
19
node.js [node.d.plugin](node.d.plugin/) and
20
python v2+ (including v3) [python.d.plugin](python.d.plugin/).
@@ -42,7 +42,7 @@ plugin|lang|O/S|runs as|modular|description
42
[plugins.d](plugins.d/)|`C`|any|internal|-|implements the **external plugins** API and serves external plugins
43
[proc.plugin](proc.plugin/)|`C`|linux|internal|yes|collects resource usage and performance data on Linux systems
44
[python.d.plugin](python.d.plugin/)|`python` v2+|any|external|yes|a **plugin orchestrator** for data collection modules written in `python` v2 or v3 (both are supported).
45
-[statsd.plugin](statsd.plugin/)|`C`|any|internal|-|implements a high performance **statsd** server for netdata
45
+[statsd.plugin](statsd.plugin/)|`C`|any|internal|-|implements a high performance **statsd** server for Netdata
46
[tc.plugin](tc.plugin/)|`C`|linux|internal|-|collects traffic QoS metrics (`tc`) of Linux network interfaces
47
48
## Enabling and Disabling plugins
@@ -59,7 +59,7 @@ All **external plugins** are managed by [plugins.d](plugins.d/), which provides
59
60
### Internal Plugins
61
62
-Each of the internal plugins runs as a thread inside the netdata daemon.
62
+Each of the internal plugins runs as a thread inside the `netdata` daemon.
63
Once this thread has started, the plugin may spawn additional threads according to its design.
64
65
#### Internal Plugins API
@@ -72,7 +72,7 @@ collect_data() {
72
73
collected_number collected_value = collect_a_value();
74
75
- // give the metrics to netdata
75
+ // give the metrics to Netdata
76
77
static RRDSET *st = NULL; // the chart
78
static RRDDIM *rd = NULL; // a dimension attached to this chart
@@ -100,20 +100,19 @@ collect_data() {
100
}
101
else {
102
// this chart is already created
103
- // let netdata know we start a new iteration on it
103
+ // let Netdata know we start a new iteration on it
104
rrdset_next(st);
105
}
106
107
// give the collected value(s) to the chart
108
rrddim_set_by_pointer(st, rd, collected_value);
109
110
- // signal netdata we are done with this iteration
110
+ // signal Netdata we are done with this iteration
111
rrdset_done(st);
112
}
113
```
114
115
-Of course netdata has a lot of libraries to help you also in collecting the metrics.
116
-The best way to find your way through this, is to examine what other similar plugins do.
115
+Of course, Netdata has a lot of libraries to help you also in collecting the metrics. The best way to find your way through this, is to examine what other similar plugins do.
116
117
118
### External Plugins
collectors/apps.plugin/README.md
+22
-22
@@ -5,9 +5,9 @@
5
To achieve this task, it iterates through the whole process tree, collecting resource usage information
6
for every process found running.
7
8
-Since netdata needs to present this information in charts and track them through time,
8
+Since Netdata needs to present this information in charts and track them through time,
9
instead of presenting a `top` like list, `apps.plugin` uses a pre-defined list of **process groups**
10
-to which it assigns all running processes. This list is [customizable](apps_groups.conf) and netdata
10
+to which it assigns all running processes. This list is [customizable](apps_groups.conf) and Netdata
11
ships with a good default for most cases (to edit it on your system run `/etc/netdata/edit-config apps_groups.conf`).
12
13
So, `apps.plugin` builds a process tree (much like `ps fax` does in Linux), and groups
@@ -15,7 +15,7 @@ processes together (evaluating both child and parent processes) so that the resu
15
a predefined set of members (of course, only process groups found running are reported).
16
17
> If you find that `apps.plugin` categorizes standard applications as `other`, we would be
18
-> glad to accept pull requests improving the [defaults](apps_groups.conf) shipped with netdata.
18
+> glad to accept pull requests improving the [defaults](apps_groups.conf) shipped with Netdata.
19
20
Unlike traditional process monitoring tools (like `top`), `apps.plugin` is able to account the resource
21
utilization of exit processes. Their utilization is accounted at their currently running parents.
@@ -26,9 +26,9 @@ that fork/spawn other short lived processes hundreds of times per second.
26
27
`apps.plugin` provides charts for 3 sections:
28
29
-1. Per application charts as **Applications** at netdata dashboards
30
-2. Per user charts as **Users** at netdata dashboards
31
-3. Per user group charts as **User Groups** at netdata dashboards
29
+1. Per application charts as **Applications** at Netdata dashboards
30
+2. Per user charts as **Users** at Netdata dashboards
31
+3. Per user group charts as **User Groups** at Netdata dashboards
32
33
Each of these sections provides the same number of charts:
34
@@ -64,7 +64,7 @@ The above are reported:
64
`apps.plugin` is a complex piece of software and has a lot of work to do
65
We are proud that `apps.plugin` is a lot faster compared to any other similar tool,
66
while collecting a lot more information for the processes, however the fact is that
67
-this plugin requires more CPU resources than the netdata daemon itself.
67
+this plugin requires more CPU resources than the `netdata` daemon itself.
68
69
Under Linux, for each process running, `apps.plugin` reads several `/proc` files
70
per process. Doing this work per-second, especially on hosts with several thousands
@@ -135,14 +135,14 @@ The order of the entries in this list is important: the first that matches a pro
135
ones at the top. Processes not matched by any row, will inherit it from their parents or children.
136
137
The order also controls the order of the dimensions on the generated charts (although applications started
138
-after apps.plugin is started, will be appended to the existing list of dimensions the netdata daemon maintains).
138
+after apps.plugin is started, will be appended to the existing list of dimensions the `netdata` daemon maintains).
139
140
## Permissions
141
142
`apps.plugin` requires additional privileges to collect all the information it needs.
143
The problem is described in issue #157.
144
145
-When netdata is installed, `apps.plugin` is given the capabilities `cap_dac_read_search,cap_sys_ptrace+ep`.
145
+When Netdata is installed, `apps.plugin` is given the capabilities `cap_dac_read_search,cap_sys_ptrace+ep`.
146
If this fails (i.e. `setcap` fails), `apps.plugin` is setuid to `root`.
147
148
#### linux capabilities in containers
@@ -158,15 +158,15 @@ chown root:netdata /usr/libexec/netdata/plugins.d/apps.plugin
158
chmod 4750 /usr/libexec/netdata/plugins.d/apps.plugin
159
```
160
161
-You will have to run these, every time you update netdata.
161
+You will have to run these, every time you update Netdata.
162
163
## Security
164
165
`apps.plugin` performs a hard-coded function of building the process tree in memory,
166
-iterating forever, collecting metrics for each running process and sending them to netdata.
167
-This is a one-way communication, from `apps.plugin` to netdata.
166
+iterating forever, collecting metrics for each running process and sending them to Netdata.
167
+This is a one-way communication, from `apps.plugin` to Netdata.
168
169
-So, since `apps.plugin` cannot be instructed by netdata for the actions it performs,
169
+So, since `apps.plugin` cannot be instructed by Netdata for the actions it performs,
170
we think it is pretty safe to allow it have these increased privileges.
171
172
Keep in mind that `apps.plugin` will still run without escalated permissions,
@@ -210,7 +210,7 @@ For more information about badges check [Generating Badges](../../web/api/badges
210
211
## Comparison with console tools
212
213
-Ssh to a server running netdata and execute this:
213
+SSH to a server running Netdata and execute this:
214
215
```sh
216
while true; do ls -l /var/run >/dev/null; done
@@ -318,24 +318,24 @@ FILE SYS Used Total 0.3 2.1 7009 netdata 0 S /usr/sbin/netdata
318
/ (vda1) 1.56G 29.5G 0.0 0.0 17 root 0 S oom_reaper
319
```
320
321
-#### why this happens?
321
+#### why does this happen?
322
323
All the console tools report usage based on the processes found running *at the moment they
324
examine the process tree*. So, they see just one `ls` command, which is actually very quick
325
with minor CPU utilization. But the shell, is spawning hundreds of them, one after another
326
(much like shell scripts do).
327
328
-#### what netdata reports?
328
+#### What does Netdata report?
329
330
The total CPU utilization of the system:
331
332
333
-<br/>_**Figure 1**: The system overview section at netdata, just a few seconds after the command was run_
333
+<br/>_**Figure 1**: The system overview section at Netdata, just a few seconds after the command was run_
334
335
And at the applications `apps.plugin` breaks down CPU usage per application:
336
337
338
-<br/>_**Figure 2**: The Applications section at netdata, just a few seconds after the command was run_
338
+<br/>_**Figure 2**: The Applications section at Netdata, just a few seconds after the command was run_
339
340
So, the `ssh` session is using 95% CPU time.
341
@@ -344,7 +344,7 @@ Why `ssh`?
344
`apps.plugin` groups all processes based on its configuration file
345
[`/etc/netdata/apps_groups.conf`](apps_groups.conf)
346
(to edit it on your system run `/etc/netdata/edit-config apps_groups.conf`).
347
-The default configuration has nothing for `bash`, but it has for `sshd`, so netdata accumulates
347
+The default configuration has nothing for `bash`, but it has for `sshd`, so Netdata accumulates
348
all ssh sessions to a dimension on the charts, called `ssh`. This includes all the processes in
349
the process tree of `sshd`, **including the exited children**.
350
@@ -353,9 +353,9 @@ the process tree of `sshd`, **including the exited children**.
353
> `apps.plugin` does not use these mechanisms. The process grouping made by `apps.plugin` works
354
> on any Linux, `systemd` based or not.
355
356
-#### a more technical description of how netdata works
356
+#### a more technical description of how Netdata works
357
358
-netdata reads `/proc/<pid>/stat` for all processes, once per second and extracts `utime` and
358
+Netdata reads `/proc/<pid>/stat` for all processes, once per second and extracts `utime` and
359
`stime` (user and system cpu utilization), much like all the console tools do.
360
361
But it [also extracts `cutime` and `cstime`](https://github.com/netdata/netdata/blob/62596cc6b906b1564657510ca9135c08f6d4cdda/src/apps_plugin.c#L636-L642)
@@ -369,7 +369,7 @@ been reported for it prior to this iteration.
369
370
It is even trickier, because walking through the entire process tree takes some time itself. So,
371
if you sum the CPU utilization of all processes, you might have more CPU time than the reported
372
-total cpu time of the system. netdata solves this, by adapting the per process cpu utilization to
372
+total cpu time of the system. Netdata solves this, by adapting the per process cpu utilization to
373
the total of the system. [Netdata adds charts that document this normalization](https://london.my-netdata.io/default.html#menu_netdata_submenu_apps_plugin).
374
375
[]()
collectors/cgroups.plugin/README.md
+24
-24
@@ -6,11 +6,11 @@ cgroups (or control groups), are a Linux kernel feature that provides accounting
6
7
cgroups are hierarchical, meaning that cgroups can contain child cgroups, which can contain more cgroups, etc. All accounting is reported (and resource usage limits are applied) also in a hierarchical way.
8
9
-To visualize cgroup metrics netdata provides configuration for cherry picking the cgroups of interest. By default (without any configuration) netdata should pick **systemd services**, all kinds of **containers** (lxc, docker, etc) and **virtual machines** spawn by managers that register them with cgroups (qemu, libvirt, etc).
9
+To visualize cgroup metrics Netdata provides configuration for cherry picking the cgroups of interest. By default (without any configuration) Netdata should pick **systemd services**, all kinds of **containers** (lxc, docker, etc) and **virtual machines** spawn by managers that register them with cgroups (qemu, libvirt, etc).
10
11
-## configuring netdata for cgroups
11
+## configuring Netdata for cgroups
12
13
-For each cgroup available in the system, netdata provides this configuration:
13
+For each cgroup available in the system, Netdata provides this configuration:
14
15
```
16
[plugin:cgroups]
@@ -21,9 +21,9 @@ But it also provides a few patterns to provide a sane default (`yes` or `no`).
21
22
Below we see, how this works.
23
24
-### how netdata finds the available cgroups
24
+### how Netdata finds the available cgroups
25
26
-Linux exposes resource usage reporting and provides dynamic configuration for cgroups, using virtual files (usually) under `/sys/fs/cgroup`. netdata reads `/proc/self/mountinfo` to detect the exact mount point of cgroups. netdata also allows manual configuration of this mount point, using these settings:
26
+Linux exposes resource usage reporting and provides dynamic configuration for cgroups, using virtual files (usually) under `/sys/fs/cgroup`. Netdata reads `/proc/self/mountinfo` to detect the exact mount point of cgroups. Netdata also allows manual configuration of this mount point, using these settings:
27
28
```
29
[plugin:cgroups]
@@ -34,27 +34,27 @@ Linux exposes resource usage reporting and provides dynamic configuration for cg
34
path to /sys/fs/cgroup/devices = /sys/fs/cgroup/devices
35
```
36
37
-netdata rescans these directories for added or removed cgroups every `check for new cgroups every` seconds.
37
+Netdata rescans these directories for added or removed cgroups every `check for new cgroups every` seconds.
38
39
### hierarchical search for cgroups
40
41
-Since cgroups are hierarchical, for each of the directories shown above, netdata walks through the subdirectories recursively searching for cgroups (each subdirectory is another cgroup).
41
+Since cgroups are hierarchical, for each of the directories shown above, Netdata walks through the subdirectories recursively searching for cgroups (each subdirectory is another cgroup).
42
43
-For each of the directories found, netdata provides a configuration variable:
43
+For each of the directories found, Netdata provides a configuration variable:
44
45
```
46
[plugin:cgroups]
47
search for cgroups under PATH = yes | no
48
```
49
50
-To provide a sane default for this setting, netdata uses the following pattern list (patterns starting with `!` give a negative match and their order is important: the first matching a path will be used):
50
+To provide a sane default for this setting, Netdata uses the following pattern list (patterns starting with `!` give a negative match and their order is important: the first matching a path will be used):
51
52
```
53
[plugin:cgroups]
54
search for cgroups in subpaths matching = !*/init.scope !*-qemu !/init.scope !/system !/systemd !/user !/user.slice *
55
```
56
57
-So, we disable checking for **child cgroups** in systemd internal cgroups ([systemd services are monitored by netdata](#monitoring-systemd-services)), user cgroups (normally used for desktop and remote user sessions), qemu virtual machines (child cgroups of virtual machines) and `init.scope`. All others are enabled.
57
+So, we disable checking for **child cgroups** in systemd internal cgroups ([systemd services are monitored by Netdata](#monitoring-systemd-services)), user cgroups (normally used for desktop and remote user sessions), qemu virtual machines (child cgroups of virtual machines) and `init.scope`. All others are enabled.
58
59
### unified cgroups (cgroups v2) support
60
@@ -71,14 +71,14 @@ Unified cgroups use same name pattern matching as v1 cgroups. `cgroup_enable_sys
71
72
### enabled cgroups
73
74
-To check if the cgroup is enabled, netdata uses this setting:
74
+To check if the cgroup is enabled, Netdata uses this setting:
75
76
```
77
[plugin:cgroups]
78
enable cgroup NAME = yes | no
79
```
80
81
-To provide a sane default, netdata uses the following pattern list (it checks the pattern against the path of the cgroup):
81
+To provide a sane default, Netdata uses the following pattern list (it checks the pattern against the path of the cgroup):
82
83
```
84
[plugin:cgroups]
@@ -87,9 +87,9 @@ To provide a sane default, netdata uses the following pattern list (it checks th
87
88
The above provides the default `yes` or `no` setting for the cgroup. However, there is an additional step. In many cases the cgroups found in the `/sys/fs/cgroup` hierarchy are just random numbers and in many cases these numbers are ephemeral: they change across reboots or sessions.
89
90
-So, we need to somehow map the paths of the cgroups to names, to provide consistent netdata configuration (i.e. there is no point to say `enable cgroup 1234 = yes | no`, if `1234` is a random number that changes over time - we need a name for the cgroup first, so that `enable cgroup NAME = yes | no` will be consistent).
90
+So, we need to somehow map the paths of the cgroups to names, to provide consistent Netdata configuration (i.e. there is no point to say `enable cgroup 1234 = yes | no`, if `1234` is a random number that changes over time - we need a name for the cgroup first, so that `enable cgroup NAME = yes | no` will be consistent).
91
92
-For this mapping netdata provides 2 configuration options:
92
+For this mapping Netdata provides 2 configuration options:
93
94
```
95
[plugin:cgroups]
@@ -99,11 +99,11 @@ For this mapping netdata provides 2 configuration options:
99
100
The whole point for the additional pattern list, is to limit the number of times the script will be called. Without this pattern list, the script might be called thousands of times, depending on the number of cgroups available in the system.
101
102
-The above pattern list is matched against the path of the cgroup. For matched cgroups, netdata calls the script [cgroup-name.sh](cgroup-name.sh.in) to get its name. This script queries `docker`, or applies heuristics to find give a name for the cgroup.
102
+The above pattern list is matched against the path of the cgroup. For matched cgroups, Netdata calls the script [cgroup-name.sh](cgroup-name.sh.in) to get its name. This script queries `docker`, or applies heuristics to find give a name for the cgroup.
103
104
### charts with zero metrics
105
106
-By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. For example:
106
+By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. For example:
107
108
```
109
[plugin:cgroups]
@@ -118,7 +118,7 @@ CPU and memory limits are watched and used to rise alarms. Memory usage for ever
118
119
## Monitoring systemd services
120
121
-netdata monitors **systemd services**. Example:
121
+Netdata monitors **systemd services**. Example:
122
123
124
@@ -175,7 +175,7 @@ sudo systemctl daemon-reexec
175
176
(`systemctl daemon-reload` does not reload the configuration of the server - so you have to execute `systemctl daemon-reexec`).
177
178
-Now, when you run `systemd-cgtop`, services will start reporting usage (if it does not, restart a service - any service - to wake it up). Refresh your netdata dashboard, and you will have the charts too.
178
+Now, when you run `systemd-cgtop`, services will start reporting usage (if it does not, restart a service - any service - to wake it up). Refresh your Netdata dashboard, and you will have the charts too.
179
180
In case memory accounting is missing, you will need to enable it at your kernel, by appending the following kernel boot options and rebooting:
181
@@ -185,7 +185,7 @@ cgroup_enable=memory swapaccount=1
185
186
You can add the above, directly at the `linux` line in your `/boot/grub/grub.cfg` or appending them to the `GRUB_CMDLINE_LINUX` in `/etc/default/grub` (in which case you will have to run `update-grub` before rebooting). On DigitalOcean debian images you may have to set it at `/etc/default/grub.d/50-cloudimg-settings.cfg`.
187
188
-Which systemd services are monitored by netdata is determined by the following pattern list:
188
+Which systemd services are monitored by Netdata is determined by the following pattern list:
189
190
```
191
[plugin:cgroups]
@@ -196,27 +196,27 @@ Which systemd services are monitored by netdata is determined by the following p
196
197
## Monitoring ephemeral containers
198
199
-netdata monitors containers automatically when it is installed at the host, or when it is installed in a container that has access to the `/proc` and `/sys` filesystems of the host.
199
+Netdata monitors containers automatically when it is installed at the host, or when it is installed in a container that has access to the `/proc` and `/sys` filesystems of the host.
200
201
-netdata prior to v1.6 had 2 issues when such containers were monitored:
201
+Netdata prior to v1.6 had 2 issues when such containers were monitored:
202
203
1. network interface alarms where triggering when containers were stopped
204
205
2. charts were never cleaned up, so after some time dozens of containers were showing up on the dashboard, and they were occupying memory.
206
207
208
-### the current netdata
208
+### the current Netdata
209
210
network interfaces and cgroups (containers) are now self-cleaned.
211
212
-So, when a network interface or container stops, netdata might log a few errors in error.log complaining about files it cannot find, but immediately:
212
+So, when a network interface or container stops, Netdata might log a few errors in error.log complaining about files it cannot find, but immediately:
213
214
1. it will detect this is a removed container or network interface
215
2. it will freeze/pause all alarms for them
216
3. it will mark their charts as obsolete
217
4. obsolete charts are not be offered on new dashboard sessions (so hit F5 and the charts are gone)
218
5. existing dashboard sessions will continue to see them, but of course they will not refresh
219
-6. obsolete charts will be removed from memory, 1 hour after the last user viewed them (configurable with `[global].cleanup obsolete charts after seconds = 3600` (at netdata.conf).
219
+6. obsolete charts will be removed from memory, 1 hour after the last user viewed them (configurable with `[global].cleanup obsolete charts after seconds = 3600` (at `netdata.conf`).
220
7. when obsolete charts are removed from memory they are also deleted from disk (configurable with `[global].delete obsolete charts files = yes`)
221
222
collectors/charts.d.plugin/README.md
+12
-12
@@ -1,10 +1,10 @@
1
# charts.d.plugin
2
3
-`charts.d.plugin` is a netdata external plugin. It is an **orchestrator** for data collection modules written in `BASH` v4+.
3
+`charts.d.plugin` is a Netdata external plugin. It is an **orchestrator** for data collection modules written in `BASH` v4+.
4
5
1. It runs as an independent process `ps fax` shows it
6
-2. It is started and stopped automatically by netdata
7
-3. It communicates with netdata via a unidirectional pipe (sending data to the netdata daemon)
6
+2. It is started and stopped automatically by Netdata
7
+3. It communicates with Netdata via a unidirectional pipe (sending data to the `netdata` daemon)
8
4. Supports any number of data collection **modules**
9
10
`charts.d.plugin` has been designed so that the actual script that will do data collection will be permanently in
@@ -43,7 +43,7 @@ For a module called `X`, the following criteria must be met:
43
44
2. If the module needs a configuration, it should be called `X.conf` and placed in `/etc/netdata/charts.d`.
45
The configuration file `X.conf` is also a BASH script itself.
46
- To edit the default files supplied by netdata run `/etc/netdata/edit-config charts.d/X.conf`,
46
+ To edit the default files supplied by Netdata, run `/etc/netdata/edit-config charts.d/X.conf`,
47
where `X` is the name of the module.
48
49
3. All functions and global variables defined in the script and its configuration, must begin with `X_`.
@@ -54,11 +54,11 @@ For a module called `X`, the following criteria must be met:
54
(following the standard Linux command line return codes: 0 = OK, the collector can operate and 1 = FAILED,
55
the collector cannot be used).
56
57
- - `X_create()` - creates the netdata charts, following the standard netdata plugin guides as described in
57
+ - `X_create()` - creates the Netdata charts, following the standard Netdata plugin guides as described in
58
**[External Plugins](../plugins.d/)** (commands `CHART` and `DIMENSION`).
59
The return value does matter: 0 = OK, 1 = FAILED.
60
61
- - `X_update()` - collects the values for the defined charts, following the standard netdata plugin guides
61
+ - `X_update()` - collects the values for the defined charts, following the standard Netdata plugin guides
62
as described in **[External Plugins](../plugins.d/)** (commands `BEGIN`, `SET`, `END`).
63
The return value also matters: 0 = OK, 1 = FAILED.
64
@@ -67,7 +67,7 @@ For a module called `X`, the following criteria must be met:
67
68
The module script may use more functions or variables. But all of them must begin with `X_`.
69
70
-The standard netdata plugin variables are also available (check **[External Plugins](../plugins.d/)**).
70
+The standard Netdata plugin variables are also available (check **[External Plugins](../plugins.d/)**).
71
72
### X_check()
73
@@ -80,7 +80,7 @@ connect to a local mysql database to find out if it can read the values it needs
80
81
### X_create()
82
83
-The purpose of the BASH function `X_create()` is to create the charts and dimensions using the standard netdata
83
+The purpose of the BASH function `X_create()` is to create the charts and dimensions using the standard Netdata
84
plugin guides (**[External Plugins](../plugins.d/)**).
85
86
`X_create()` will be called just once and only after `X_check()` was successful.
@@ -90,8 +90,8 @@ A non-zero return value will disable the collector.
90
91
### X_update()
92
93
-`X_update()` will be called repeatedly every `X_update_every` seconds, to collect new values and send them to netdata,
94
-following the netdata plugin guides (**[External Plugins](../plugins.d/)**).
93
+`X_update()` will be called repeatedly every `X_update_every` seconds, to collect new values and send them to Netdata,
94
+following the Netdata plugin guides (**[External Plugins](../plugins.d/)**).
95
96
The function will be called with one parameter: microseconds since the last time it was run. This value should be
97
appended to the `BEGIN` statement of every chart updated by the collector script.
@@ -167,7 +167,7 @@ Keep in mind that if your configs are not in `/etc/netdata`, you should do the f
167
export NETDATA_USER_CONFIG_DIR="/path/to/etc/netdata"
168
```
169
170
-Also, remember that netdata runs `chart.d.plugin` as user `netdata` (or any other user netdata is configured to run as).
170
+Also, remember that Netdata runs `chart.d.plugin` as user `netdata` (or any other user the `netdata` process is configured to run as).
171
172
173
## Running multiple instances of charts.d.plugin
@@ -188,7 +188,7 @@ This is what you need to do:
188
3. link `/usr/libexec/netdata/plugins.d/charts.d.plugin` to `/usr/libexec/netdata/plugins.d/charts2.d.plugin`.
189
Netdata will spawn a new charts.d process.
190
191
-Execute the above in this order, since netdata will (by default) attempt to start new plugins soon after they are
191
+Execute the above in this order, since Netdata will (by default) attempt to start new plugins soon after they are
192
created in `/usr/libexec/netdata/plugins.d/`.
193
194
collectors/charts.d.plugin/ap/README.md
+1
-1
@@ -2,7 +2,7 @@
2
3
The `ap` collector visualizes data related to access points.
4
5
-## Example netdata charts
5
+## Example Netdata charts
6
7
8
collectors/charts.d.plugin/apache/README.md
+4
-4
@@ -7,7 +7,7 @@
7
8
The `apache` collector visualizes key performance data for an apache web server.
9
10
-## Example netdata charts
10
+## Example Netdata charts
11
12
For apache 2.2:
13
@@ -80,7 +80,7 @@ From the apache status output it collects:
80
81
- total accesses (incremental value, rendered as requests/s)
82
- total bandwidth (incremental value, rendered as bandwidth/s)
83
- - requests per second (this appears to be calculated by apache as an average for its lifetime, while the one calculated by netdata using the total accesses counter is real-time)
83
+ - requests per second (this appears to be calculated by apache as an average for its lifetime, while the one calculated by Netdata using the total accesses counter is real-time)
84
- bytes per second (average for the lifetime of the apache server)
85
- bytes per request (average for the lifetime of the apache server)
86
- workers by status (`busy` and `idle`)
@@ -106,7 +106,7 @@ apache_curl_opts=
106
apache_update_every=
107
```
108
109
-The default `apache_update_every` is configured in netdata.
109
+The default `apache_update_every` is configured in Netdata.
110
111
## Auto-detection
112
@@ -122,7 +122,7 @@ If you are able to run successfully, by hand this command:
122
curl "http://127.0.0.1:80/server-status?auto"
123
```
124
125
-netdata will be able to do it too.
125
+Netdata will be able to do it too.
126
127
Notice: You may need to have the default `000-default.conf ` website enabled in order for the status mod to work.
128
collectors/charts.d.plugin/sensors/README.md
+1
-1
@@ -13,7 +13,7 @@ The plugin will provide charts for all configured system sensors
13
> kernel provided values, this plugin will not perform.
14
> So, the values graphed, are the raw hardware values of the sensors.
15
16
-The plugin will create netdata charts for:
16
+The plugin will create Netdata charts for:
17
18
1. **Temperature**
19
2. **Voltage**
collectors/diskspace.plugin/README.md
+1
-1
@@ -10,7 +10,7 @@ Two charts are available for every mount:
10
11
Simple patterns can be used to exclude mounts from showed statistics based on path or filesystem. By default read-only mounts are not displayed. To display them `yes` should be set for a chart instead of `auto`.
12
13
-By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
13
+By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
14
15
16
```
collectors/fping.plugin/README.md
+4
-4
@@ -23,7 +23,7 @@ fping="/usr/local/bin/fping"
23
# I suggest to use hostnames and put their IPs in /etc/hosts
24
hosts="host1 host2 host3"
25
26
-# override the chart update frequency - the default is inherited from netdata
26
+# override the chart update frequency - the default is inherited from Netdata
27
update_every=1
28
29
# time in milliseconds (1 sec = 1000 ms) to ping the hosts
@@ -36,7 +36,7 @@ fping_opts="-R -b 56 -i 1 -r 0 -t 5000"
36
37
## alarms
38
39
-netdata will automatically attach a few alarms for each host.
39
+Netdata will automatically attach a few alarms for each host.
40
Check the [latest versions of the fping alarms](../../health/health.d/fping.conf)
41
42
## Additional Tips
@@ -60,7 +60,7 @@ ping_every=5000
60
You may need to run multiple fping plugins with different settings for different end points.
61
For example, you may need to ping a few hosts 10 times per second, and others once per second.
62
63
-netdata allows you to add as many `fping` plugins as you like.
63
+Netdata allows you to add as many `fping` plugins as you like.
64
65
Follow this procedure:
66
@@ -90,7 +90,7 @@ cd /usr/libexec/netdata/plugins.d
90
ln -s fping.plugin fping2.plugin
91
```
92
93
-That's it. netdata will detect the new plugin and start it.
93
+That's it. Netdata will detect the new plugin and start it.
94
95
You can name the new plugin any name you like.
96
Just make sure the plugin and the configuration file have the same name.
collectors/freebsd.plugin/README.md
+1
-1
@@ -2,6 +2,6 @@
2
3
Collects resource usage and performance data on FreeBSD systems
4
5
-By default, Netdata will enable monitoring metrics for disks, memory, and network only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Use `yes` instead of `auto` in plugin configuration sections to enable these charts permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
5
+By default, Netdata will enable monitoring metrics for disks, memory, and network only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Use `yes` instead of `auto` in plugin configuration sections to enable these charts permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
6
7
[]()
collectors/freeipmi.plugin/README.md
+4
-4
@@ -8,11 +8,11 @@ Netdata has a [freeipmi](https://www.gnu.org/software/freeipmi/) plugin.
8
9
1. install `libipmimonitoring-dev` or `libipmimonitoring-devel` (`freeipmi-devel` on RHEL based OS) using the package manager of your system.
10
11
-2. re-install netdata from source. The installer will detect that the required libraries are now available and will also build `freeipmi.plugin`.
11
+2. re-install Netdata from source. The installer will detect that the required libraries are now available and will also build `freeipmi.plugin`.
12
13
Keep in mind IPMI requires root access, so the plugin is setuid to root.
14
15
-If you just installed the required IPMI tools, please run at least once the command `ipmimonitoring` and verify it returns sensors information. This command initialises IPMI configuration, so that the netdata plugin will be able to work.
15
+If you just installed the required IPMI tools, please run at least once the command `ipmimonitoring` and verify it returns sensors information. This command initialises IPMI configuration, so that the Netdata plugin will be able to work.
16
17
## Netdata use
18
@@ -111,7 +111,7 @@ Append to `command options = ` the settings you need. The minimum `update every`
111
112
## Ignoring specific sensors
113
114
-Specific sensor IDs can be excluded from freeipmi tools by editing `/etc/freeipmi/freeipmi.conf` and setting the IDs to be ignored at `ipmi-sensors-exclude-record-ids`. **However this file is not used by `libipmimonitoring`** (the library used by netdata's `freeipmi.plugin`).
114
+Specific sensor IDs can be excluded from freeipmi tools by editing `/etc/freeipmi/freeipmi.conf` and setting the IDs to be ignored at `ipmi-sensors-exclude-record-ids`. **However this file is not used by `libipmimonitoring`** (the library used by Netdata's `freeipmi.plugin`).
115
116
So, `freeipmi.plugin` supports the option `ignore` that accepts a comma separated list of sensor IDs to ignore. To configure it, edit `/etc/netdata/netdata.conf` and set:
117
@@ -180,7 +180,7 @@ options ipmi_si kipmid_max_busy_us=10
180
181
This instructs the kernel IPMI module to pause for a tick between checking IPMI. Querying IPMI will be a lot slower now (e.g. several seconds for IPMI to respond), but `kipmi` will not use any noticeable CPU. You can also use a higher number (this is the number of microseconds to poll IPMI for a response, before waiting for a tick).
182
183
-If you need to disable IPMI for netdata, edit `/etc/netdata/netdata.conf` and set:
183
+If you need to disable IPMI for Netdata, edit `/etc/netdata/netdata.conf` and set:
184
185
```
186
[plugins]
collectors/ioping.plugin/README.md
+5
-5
@@ -10,7 +10,7 @@ The supplied plugin can install it, by running:
10
/usr/libexec/netdata/plugins.d/ioping.plugin install
11
```
12
13
-The `-e` option can be supplied to indicate where the netdata environment file is installed. The default path is `/etc/netdata/.environment`.
13
+The `-e` option can be supplied to indicate where the Netdata environment file is installed. The default path is `/etc/netdata/.environment`.
14
15
The above will download, build and install the right version as `/usr/libexec/netdata/plugins.d/ioping`.
16
@@ -24,7 +24,7 @@ ioping="/usr/libexec/netdata/plugins.d/ioping"
24
# set here the directory/file/device, you need to ping
25
destination="destination"
26
27
-# override the chart update frequency - the default is inherited from netdata
27
+# override the chart update frequency - the default is inherited from Netdata
28
update_every="1s"
29
30
# the request size in bytes to ping the destination
@@ -36,7 +36,7 @@ ioping_opts="-T 1000000 -R"
36
37
## alarms
38
39
-netdata will automatically attach a few alarms for each host.
39
+Netdata will automatically attach a few alarms for each host.
40
Check the [latest versions of the ioping alarms](../../health/health.d/ioping.conf)
41
42
## Multiple ioping Plugins With Different Settings
@@ -44,7 +44,7 @@ Check the [latest versions of the ioping alarms](../../health/health.d/ioping.co
44
You may need to run multiple ioping plugins with different settings or different end points.
45
For example, you may need to ping one destination once per 10 seconds, and another once per second.
46
47
-netdata allows you to add as many `ioping` plugins as you like.
47
+Netdata allows you to add as many `ioping` plugins as you like.
48
49
Follow this procedure:
50
@@ -74,7 +74,7 @@ cd /usr/libexec/netdata/plugins.d
74
ln -s ioping.plugin ioping2.plugin
75
```
76
77
-That's it. netdata will detect the new plugin and start it.
77
+That's it. Netdata will detect the new plugin and start it.
78
79
You can name the new plugin any name you like.
80
Just make sure the plugin and the configuration file have the same name.
collectors/macos.plugin/README.md
+1
-1
@@ -2,6 +2,6 @@
2
3
Collects resource usage and performance data on MacOS systems
4
5
-By default, Netdata will enable monitoring metrics for disks, memory, and network only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Use `yes` instead of `auto` in plugin configuration sections to enable these charts permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
5
+By default, Netdata will enable monitoring metrics for disks, memory, and network only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Use `yes` instead of `auto` in plugin configuration sections to enable these charts permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
6
7
[]()
collectors/nfacct.plugin/README.md
+2
-2
@@ -6,7 +6,7 @@
6
7
1. install `libmnl-dev` and `libnetfilter_acct-dev` using the package manager of your system.
8
9
-2. re-install netdata from source. The installer will detect that the required libraries are now available and will also build netdata.plugin.
9
+2. re-install Netdata from source. The installer will detect that the required libraries are now available and will also build `netdata.plugin`.
10
11
Keep in mind that NFACCT requires root access, so the plugin is setuid to root.
12
@@ -27,7 +27,7 @@ Netfilter accounting:
27
28
## Configuration
29
30
-If you need to disable NFACCT for netdata, edit /etc/netdata/netdata.conf and set:
30
+If you need to disable NFACCT for Netdata, edit /etc/netdata/netdata.conf and set:
31
32
```
33
[plugins]
collectors/node.d.plugin/README.md
+8
-8
@@ -1,10 +1,10 @@
1
# node.d.plugin
2
3
-`node.d.plugin` is a netdata external plugin. It is an **orchestrator** for data collection modules written in `node.js`.
3
+`node.d.plugin` is a Netdata external plugin. It is an **orchestrator** for data collection modules written in `node.js`.
4
5
1. It runs as an independent process `ps fax` shows it
6
-2. It is started and stopped automatically by netdata
7
-3. It communicates with netdata via a unidirectional pipe (sending data to the netdata daemon)
6
+2. It is started and stopped automatically by Netdata
7
+3. It communicates with Netdata via a unidirectional pipe (sending data to the `netdata` daemon)
8
4. Supports any number of data collection **modules**
9
5. Allows each **module** to have one or more data collection **jobs**
10
6. Each **job** is collecting one or more metrics from a single data source
@@ -28,7 +28,7 @@ At minimum, to be buildable and testable, the PR needs to include:
28
Node.js is perfect for asynchronous operations. It is very fast and quite common (actually the whole web is based on it).
29
Since data collection is not a CPU intensive task, node.js is an ideal solution for it.
30
31
-`node.d.plugin` is a netdata plugin that provides an abstraction layer to allow easy and quick development of data
31
+`node.d.plugin` is a Netdata plugin that provides an abstraction layer to allow easy and quick development of data
32
collectors in node.js. It also manages all its data collectors (placed in `/usr/libexec/netdata/node.d`) using a single
33
instance of node, thus lowering the memory footprint of data collection.
34
@@ -54,7 +54,7 @@ For more information check the **[[Installation]]** guide.
54
Unfortunately, `JSON` files do not accept comments. So, the best way to describe them is to have markdown text files
55
with instructions.
56
57
-`JSON` has a very strict formatting. If you get errors from netdata at `/var/log/netdata/error.log` that a certain
57
+`JSON` has a very strict formatting. If you get errors from Netdata at `/var/log/netdata/error.log` that a certain
58
configuration file cannot be loaded, we suggest to verify it at [http://jsonlint.com/](http://jsonlint.com/).
59
60
The files in this directory, provide usable examples for configuring each `node.d.plugin` module.
@@ -93,7 +93,7 @@ Your data collection module should be split in 3 parts:
93
so you don't need to do anything about it for http.
94
95
- a function to process the fetched/manipulate the data fetched. This function will make a number of calls
96
- to create charts and dimensions and pass the collected values to netdata.
96
+ to create charts and dimensions and pass the collected values to Netdata.
97
This is the only function you need to write for collecting http JSON data.
98
99
- a `configure` and an `update` function, which take care of your module configuration and data refresh
@@ -127,7 +127,7 @@ netdata.processors.myprocessor = {
127
var mymodule = {
128
processResponse: function(service, data) {
129
130
- /* send information to the netdata server here */
130
+ /* send information to the Netdata server here */
131
132
},
133
@@ -221,7 +221,7 @@ The configuration file `/etc/netdata/node.d/mymodule.conf` may contain whatever
221
222
`data` may be `null` or whatever the processor specified in the `service` returned.
223
224
-The `service` object defines a set of functions to allow you send information to the netdata core about:
224
+The `service` object defines a set of functions to allow you send information to the Netdata core about:
225
226
1. Charts and dimension definitions
227
2. Updated values, from the collected values
collectors/node.d.plugin/fronius/README.md
+2
-2
@@ -3,7 +3,7 @@
3
This module collects metrics from the configured solar power installation from Fronius Symo.
4
5
**Requirements**
6
- * Configuration file `fronius.conf` in the node.d netdata config dir (default: `/etc/netdata/node.d/fronius.conf`)
6
+ * Configuration file `fronius.conf` in the node.d Netdata config dir (default: `/etc/netdata/node.d/fronius.conf`)
7
* Fronius Symo with network access (http)
8
9
It produces per server:
@@ -61,7 +61,7 @@ The plugin has been tested with a single inverter, namely Fronius Symo 8.2-3-M:
61
62
Other products and versions may work, but without any guarantees.
63
64
-Example netdata configuration for node.d/fronius.conf. Copy this section to fronius.conf and change name/ip.
64
+Example Netdata configuration for node.d/fronius.conf. Copy this section to fronius.conf and change name/ip.
65
The module supports any number of servers. Sometimes there is a lag when collecting every 3 seconds, so 5 should be okay too. You can modify this per server.
66
```json
67
{
collectors/node.d.plugin/named/README.md
+4
-4
@@ -1,8 +1,8 @@
1
# ISC Bind Statistics
2
3
-Using this netdata collector, you can monitor one or more ISC Bind servers.
3
+Using this Netdata collector, you can monitor one or more ISC Bind servers.
4
5
-## Example netdata charts
5
+## Example Netdata charts
6
7
Depending on the number of views your bind has, you may get a large number of charts.
8
Here this is with just one view:
@@ -340,5 +340,5 @@ Verify it works by running the following command (the collector is written in no
340
curl "http://localhost:8888/json/v1/server"
341
```
342
343
-
344
-[]()
343
+
344
+[]()
collectors/node.d.plugin/sma_webbox/README.md
+1
-1
@@ -3,7 +3,7 @@
3
4
[SMA Sunny Webbox](http://files.sma.de/dl/4253/WEBBOX-DUS131916W.pdf)
5
6
-Example netdata configuration for node.d/sma_webbox.conf
6
+Example Netdata configuration for node.d/sma_webbox.conf
7
8
The module supports any number of name servers, like this:
9
collectors/node.d.plugin/snmp/README.md
+4
-4
@@ -1,6 +1,6 @@
1
# SNMP Data Collector
2
3
-Using this collector, netdata can collect data from any SNMP device.
3
+Using this collector, Netdata can collect data from any SNMP device.
4
5
This collector supports:
6
@@ -88,7 +88,7 @@ In this example:
88
89
`update_every` is the update frequency for each server, in seconds.
90
91
-`max_request_size` limits the maximum number of OIDs that will be requested in a single call. The default is 50. Lower this number of you get `TooBig` errors in netdata error.log.
91
+`max_request_size` limits the maximum number of OIDs that will be requested in a single call. The default is 50. Lower this number of you get `TooBig` errors in Netdata's `error.log`.
92
93
`family` sets the name of the submenu of the dashboard each chart will appear under.
94
@@ -177,9 +177,9 @@ To test it, you can run:
177
/usr/libexec/netdata/plugins.d/node.d.plugin 1 snmp
178
```
179
180
-The above will run it on your console and you will be able to see what netdata sees, but also errors. You can get a very detailed output by appending `debug` to the command line.
180
+The above will run it on your console and you will be able to see what Netdata sees, but also errors. You can get a very detailed output by appending `debug` to the command line.
181
182
-If it works, restart netdata to activate the snmp collector and refresh the dashboard (if your SNMP device responds with a delay, you may need to refresh the dashboard in a few seconds).
182
+If it works, restart Netdata to activate the snmp collector and refresh the dashboard (if your SNMP device responds with a delay, you may need to refresh the dashboard in a few seconds).
183
184
## Data collection speed
185
collectors/node.d.plugin/stiebeleltron/README.md
+1
-1
@@ -3,7 +3,7 @@
3
This module collects metrics from the configured heat pump and hot water installation from Stiebel Eltron ISG web.
4
5
**Requirements**
6
- * Configuration file `stiebeleltron.conf` in the node.d netdata config dir (default: `/etc/netdata/node.d/stiebeleltron.conf`)
6
+ * Configuration file `stiebeleltron.conf` in the node.d Netdata config dir (default: `/etc/netdata/node.d/stiebeleltron.conf`)
7
* Stiebel Eltron ISG web with network access (http), without password login
8
9
The charts are configurable, however, the provided default configuration collects the following:
collectors/plugins.d/README.md
+45
-45
@@ -1,7 +1,7 @@
1
# External plugins overview
2
3
-`plugins.d` is the netdata internal plugin that collects metrics
4
-from external processes, thus allowing netdata to use **external plugins**.
3
+`plugins.d` is the Netdata internal plugin that collects metrics
4
+from external processes, thus allowing Netdata to use **external plugins**.
5
6
## Provided External Plugins
7
@@ -19,19 +19,19 @@ plugin|language|O/S|description
19
[node.d.plugin](../node.d.plugin/)|`node.js`|all|a **plugin orchestrator** for data collection modules written in `node.js`.
20
[python.d.plugin](../python.d.plugin/)|`python`|all|a **plugin orchestrator** for data collection modules written in `python` v2 or v3 (both are supported).
21
22
-Plugin orchestrators may also be described as **modular plugins**. They are modular since they accept custom made modules to be included. Writing modules for these plugins is easier than accessing the native netdata API directly. You will find modules already available for each orchestrator under the directory of the particular modular plugin (e.g. under python.d.plugin for the python orchestrator).
22
+Plugin orchestrators may also be described as **modular plugins**. They are modular since they accept custom made modules to be included. Writing modules for these plugins is easier than accessing the native Netdata API directly. You will find modules already available for each orchestrator under the directory of the particular modular plugin (e.g. under python.d.plugin for the python orchestrator).
23
Each of these modular plugins has each own methods for defining modules. Please check the examples and their documentation.
24
25
## Motivation
26
27
-This plugin allows netdata to use **external plugins** for data collection:
27
+This plugin allows Netdata to use **external plugins** for data collection:
28
29
1. external data collection plugins may be written in any computer language.
30
31
2. external data collection plugins may use O/S capabilities or `setuid` to
32
- run with escalated privileges (compared to the netdata daemon).
33
- The communication between the external plugin and netdata is unidirectional
34
- (from the plugin to netdata), so that netdata cannot manipulate an external
32
+ run with escalated privileges (compared to the `netdata` daemon).
33
+ The communication between the external plugin and Netdata is unidirectional
34
+ (from the plugin to Netdata), so that Netdata cannot manipulate an external
35
plugin running with escalated privileges.
36
37
## Operation
@@ -39,23 +39,23 @@ This plugin allows netdata to use **external plugins** for data collection:
39
Each of the external plugins is expected to run forever.
40
Netdata will start it when it starts and stop it when it exits.
41
42
-If the external plugin exits or crashes, netdata will log an error.
43
-If the external plugin exits or crashes without pushing metrics to netdata, netdata will not start it again.
42
+If the external plugin exits or crashes, Netdata will log an error.
43
+If the external plugin exits or crashes without pushing metrics to Netdata, Netdata will not start it again.
44
- Plugins that exit with any value other than zero, will be disabled. Plugins that exit with zero, will be restarted after some time.
45
-- Plugins may also be disabled by netdata if they output things that netdata does not understand.
45
+- Plugins may also be disabled by Netdata if they output things that Netdata does not understand.
46
47
-The `stdout` of external plugins is connected to netdata to receive metrics,
47
+The `stdout` of external plugins is connected to Netdata to receive metrics,
48
with the API defined below.
49
50
-The `stderr` of external plugins is connected to netdata `error.log`.
50
+The `stderr` of external plugins is connected to Netdata's `error.log`.
51
52
Plugins can create any number of charts with any number of dimensions each. Each chart can have its own characteristics independently of the others generated by the same plugin. For example, one chart may have an update frequency of 1 second, another may have 5 seconds and a third may have 10 seconds.
53
54
## Configuration
55
56
-Netdata will supply the environment variables `NETDATA_USER_CONFIG_DIR` (for user supplied) and `NETDATA_STOCK_CONFIG_DIR` (for netdata supplied) configuration files to identify the directory where configuration files are stored. It is up to the plugin to read the configuration it needs.
56
+Netdata will supply the environment variables `NETDATA_USER_CONFIG_DIR` (for user supplied) and `NETDATA_STOCK_CONFIG_DIR` (for Netdata supplied) configuration files to identify the directory where configuration files are stored. It is up to the plugin to read the configuration it needs.
57
58
-The `netdata.conf` section [plugins] section contains a list of all the plugins found at the system where netdata runs, with a boolean setting to enable them or not.
58
+The `netdata.conf` section [plugins] section contains a list of all the plugins found at the system where Netdata runs, with a boolean setting to enable them or not.
59
60
Example:
61
@@ -100,19 +100,19 @@ Netdata will call the plugin with just one command line parameter: the number of
100
101
Other than the above, the plugin configuration is up to the plugin.
102
103
-Keep in mind, that the user may use netdata configuration to overwrite chart and dimension parameters. This is transparent to the plugin.
103
+Keep in mind, that the user may use Netdata configuration to overwrite chart and dimension parameters. This is transparent to the plugin.
104
105
### Autoconfiguration
106
107
Plugins should attempt to autoconfigure themselves when possible.
108
109
-For example, if your plugin wants to monitor `squid`, you can search for it on port `3128` or `8080`. If any succeeds, you can proceed. If it fails you can output an error (on stderr) saying that you cannot find `squid` running and giving instructions about the plugin configuration. Then you can stop (exit with non-zero value), so that netdata will not attempt to start the plugin again.
109
+For example, if your plugin wants to monitor `squid`, you can search for it on port `3128` or `8080`. If any succeeds, you can proceed. If it fails you can output an error (on stderr) saying that you cannot find `squid` running and giving instructions about the plugin configuration. Then you can stop (exit with non-zero value), so that Netdata will not attempt to start the plugin again.
110
111
## External Plugins API
112
113
-Any program that can print a few values to its standard output can become a netdata external plugin.
113
+Any program that can print a few values to its standard output can become a Netdata external plugin.
114
115
-There are 7 lines netdata parses. lines starting with:
115
+Netdata parses 7 lines starting with:
116
117
- `CHART` - create or update a chart
118
- `DIMENSION` - add or update a dimension to the chart just created
@@ -129,7 +129,7 @@ Charts can be added any time (not just the beginning).
129
### command line parameters
130
131
The plugin **MUST** accept just **one** parameter: **the number of seconds it is
132
-expected to update the values for its charts**. The value passed by netdata
132
+expected to update the values for its charts**. The value passed by Netdata
133
to the plugin is controlled via its configuration file (so there is no need
134
for the plugin to handle this configuration option).
135
@@ -144,24 +144,24 @@ available for the plugin to use.
144
145
variable|description
146
:------:|:----------
147
-`NETDATA_USER_CONFIG_DIR`|The directory where all netdata related user configuration should be stored. If the plugin requires custom user configuration, this is the place the user has saved it (normally under `/etc/netdata`).
148
-`NETDATA_STOCK_CONFIG_DIR`|The directory where all netdata related stock configuration should be stored. If the plugin is shipped with configuration files, this is the place they can be found (normally under `/usr/lib/netdata/conf.d`).
149
-`NETDATA_PLUGINS_DIR`|The directory where all netdata plugins are stored.
150
-`NETDATA_WEB_DIR`|The directory where the web files of netdata are saved.
151
-`NETDATA_CACHE_DIR`|The directory where the cache files of netdata are stored. Use this directory if the plugin requires a place to store data. A new directory should be created for the plugin for this purpose, inside this directory.
152
-`NETDATA_LOG_DIR`|The directory where the log files are stored. By default the `stderr` output of the plugin will be saved in the `error.log` file of netdata.
147
+`NETDATA_USER_CONFIG_DIR`|The directory where all Netdata-related user configuration should be stored. If the plugin requires custom user configuration, this is the place the user has saved it (normally under `/etc/netdata`).
148
+`NETDATA_STOCK_CONFIG_DIR`|The directory where all Netdata -related stock configuration should be stored. If the plugin is shipped with configuration files, this is the place they can be found (normally under `/usr/lib/netdata/conf.d`).
149
+`NETDATA_PLUGINS_DIR`|The directory where all Netdata plugins are stored.
150
+`NETDATA_WEB_DIR`|The directory where the web files of Netdata are saved.
151
+`NETDATA_CACHE_DIR`|The directory where the cache files of Netdata are stored. Use this directory if the plugin requires a place to store data. A new directory should be created for the plugin for this purpose, inside this directory.
152
+`NETDATA_LOG_DIR`|The directory where the log files are stored. By default the `stderr` output of the plugin will be saved in the `error.log` file of Netdata.
153
`NETDATA_HOST_PREFIX`|This is used in environments where system directories like `/sys` and `/proc` have to be accessed at a different path.
154
-`NETDATA_DEBUG_FLAGS`|This is a number (probably in hex starting with `0x`), that enables certain netdata debugging features. Check **[[Tracing Options]]** for more information.
155
-`NETDATA_UPDATE_EVERY`|The minimum number of seconds between chart refreshes. This is like the **internal clock** of netdata (it is user configurable, defaulting to `1`). There is no meaning for a plugin to update its values more frequently than this number of seconds.
154
+`NETDATA_DEBUG_FLAGS`|This is a number (probably in hex starting with `0x`), that enables certain Netdata debugging features. Check **[[Tracing Options]]** for more information.
155
+`NETDATA_UPDATE_EVERY`|The minimum number of seconds between chart refreshes. This is like the **internal clock** of Netdata (it is user configurable, defaulting to `1`). There is no meaning for a plugin to update its values more frequently than this number of seconds.
156
157
158
### The output of the plugin
159
160
-The plugin should output instructions for netdata to its output (`stdout`). Since this uses pipes, please make sure you flush stdout after every iteration.
160
+The plugin should output instructions for Netdata to its output (`stdout`). Since this uses pipes, please make sure you flush stdout after every iteration.
161
162
#### DISABLE
163
164
-`DISABLE` will disable this plugin. This will prevent netdata from restarting the plugin. You can also exit with the value `1` to have the same effect.
164
+`DISABLE` will disable this plugin. This will prevent Netdata from restarting the plugin. You can also exit with the value `1` to have the same effect.
165
166
#### CHART
167
@@ -225,11 +225,11 @@ the template is:
225
226
- `options`
227
228
- a space separated list of options, enclosed in quotes. 4 options are currently supported: `obsolete` to mark a chart as obsolete (netdata will hide it and delete it after some time), `detail` to mark a chart as insignificant (this may be used by dashboards to make the charts smaller, or somehow visualize properly a less important chart), `store_first` to make netdata store the first collected value, assuming there was an invisible previous value set to zero (this is used by statsd charts - if the first data collected value of incremental dimensions is not zero based, unrealistic spikes will appear with this option set) and `hidden` to perform all operations on a chart, but do not offer it on dashboards (the chart will be send to backends). `CHART` options have been added in netdata v1.7 and the `hidden` option was added in 1.10.
228
+ a space separated list of options, enclosed in quotes. 4 options are currently supported: `obsolete` to mark a chart as obsolete (Netdata will hide it and delete it after some time), `detail` to mark a chart as insignificant (this may be used by dashboards to make the charts smaller, or somehow visualize properly a less important chart), `store_first` to make Netdata store the first collected value, assuming there was an invisible previous value set to zero (this is used by statsd charts - if the first data collected value of incremental dimensions is not zero based, unrealistic spikes will appear with this option set) and `hidden` to perform all operations on a chart, but do not offer it on dashboards (the chart will be send to backends). `CHART` options have been added in Netdata v1.7 and the `hidden` option was added in 1.10.
229
230
- `plugin` and `module`
231
232
- both are just names that are used to let the user identify the plugin and the module that generated the chart. If `plugin` is unset or empty, netdata will automatically set the filename of the plugin that generated the chart. `module` has not default.
232
+ both are just names that are used to let the user identify the plugin and the module that generated the chart. If `plugin` is unset or empty, Netdata will automatically set the filename of the plugin that generated the chart. `module` has not default.
233
234
235
#### DIMENSION
@@ -290,7 +290,7 @@ the template is:
290
291
- `options`
292
293
- a space separated list of options, enclosed in quotes. Options supported: `obsolete` to mark a dimension as obsolete (netdata will delete it after some time) and `hidden` to make this dimension hidden, it will take part in the calculations but will not be presented in the chart.
293
+ a space separated list of options, enclosed in quotes. Options supported: `obsolete` to mark a dimension as obsolete (Netdata will delete it after some time) and `hidden` to make this dimension hidden, it will take part in the calculations but will not be presented in the chart.
294
295
296
#### VARIABLE
@@ -302,7 +302,7 @@ the template is:
302
Variables support 2 scopes:
303
304
- `GLOBAL` or `HOST` to define the variable at the host level.
305
-- `LOCAL` or `CHART` to define the variable at the chart level. Use chart-local variables when the same variable may exist for different charts (i.e. netdata monitors 2 mysql servers, and you need to set the `max_connections` each server accepts). Using chart-local variables is the ideal to build alarm templates.
305
+- `LOCAL` or `CHART` to define the variable at the chart level. Use chart-local variables when the same variable may exist for different charts (i.e. Netdata monitors 2 mysql servers, and you need to set the `max_connections` each server accepts). Using chart-local variables is the ideal to build alarm templates.
306
307
The position of the `VARIABLE` line, sets its default scope (in case you do not specify a scope). So, defining a `VARIABLE` before any `CHART`, or between `END` and `BEGIN` (outside any chart), sets `GLOBAL` scope, while defining a `VARIABLE` just after a `CHART` or a `DIMENSION`, or within the `BEGIN` - `END` block of a chart, sets `LOCAL` scope.
308
@@ -310,9 +310,9 @@ These variables can be set and updated at any point.
310
311
Variable names should use alphanumeric characters, the `.` and the `_`.
312
313
-The `value` is floating point (netdata used `long double`).
313
+The `value` is floating point (Netdata used `long double`).
314
315
-Variables are transferred to upstream netdata servers (streaming and database replication).
315
+Variables are transferred to upstream Netdata servers (streaming and database replication).
316
317
## Data collection
318
@@ -329,12 +329,12 @@ data collection is defined as a series of `BEGIN` -> `SET` -> `END` lines
329
is the number of microseconds since the last update of the chart. It is optional.
330
331
Under heavy system load, the system may have some latency transferring
332
- data from the plugins to netdata via the pipe. This number improves
332
+ data from the plugins to Netdata via the pipe. This number improves
333
accuracy significantly, since the plugin is able to calculate the
334
- duration between its iterations better than netdata.
334
+ duration between its iterations better than Netdata.
335
336
The first time the plugin is started, no microseconds should be given
337
- to netdata.
337
+ to Netdata.
338
339
> SET id = value
340
@@ -360,15 +360,15 @@ If more charts need to be updated, each chart should have its own
360
`BEGIN` -> `SET` -> `END` block.
361
362
If, for any reason, a plugin has issued a `BEGIN` but wants to cancel it,
363
-it can issue a `FLUSH`. The `FLUSH` command will instruct netdata to ignore
363
+it can issue a `FLUSH`. The `FLUSH` command will instruct Netdata to ignore
364
all the values collected since the last `BEGIN` command.
365
366
If a plugin does not behave properly (outputs invalid lines, or does not
367
-follow these guidelines), will be disabled by netdata.
367
+follow these guidelines), will be disabled by Netdata.
368
369
### collected values
370
371
-netdata will collect any **signed** value in the 64bit range:
371
+Netdata will collect any **signed** value in the 64bit range:
372
`-9.223.372.036.854.775.808` to `+9.223.372.036.854.775.807`
373
374
If a value is not collected, leave it empty, like this:
@@ -381,7 +381,7 @@ or do not output the line at all.
381
382
1. **python**, use `python.d.plugin`, there are many examples in the [python.d directory](../python.d.plugin/)
383
384
- python is ideal for netdata plugins. It is a simple, yet powerful way to collect data, it has a very small memory footprint, although it is not the most CPU efficient way to do it.
384
+ python is ideal for Netdata plugins. It is a simple, yet powerful way to collect data, it has a very small memory footprint, although it is not the most CPU efficient way to do it.
385
386
2. **node.js**, use `node.d.plugin`, there are a few examples in the [node.d directory](../node.d.plugin/)
387
@@ -393,7 +393,7 @@ or do not output the line at all.
393
394
4. **C**
395
396
- Of course, C is the most efficient way of collecting data. This is why netdata itself is written in C.
396
+ Of course, C is the most efficient way of collecting data. This is why Netdata itself is written in C.
397
398
## Writing Plugins Properly
399
@@ -436,7 +436,7 @@ There are a few rules for writing plugins properly:
436
/*
437
* find the time of the next loop
438
* this makes sure we are always aligned
439
- * with the netdata daemon
439
+ * with the Netdata daemon
440
*/
441
next_run = now - (now % update_every) + update_every;
442
@@ -461,7 +461,7 @@ There are a few rules for writing plugins properly:
461
/* do your magic here to collect values */
462
collectValues();
463
464
- /* send the collected data to netdata */
464
+ /* send the collected data to Netdata */
465
printValues(dt_since_last_run); /* print BEGIN, SET, END statements */
466
}
467
```
collectors/proc.plugin/README.md
+13
-13
@@ -22,7 +22,7 @@
22
- `/sys/class/power_supply` (power supply properties)
23
- `ipc` (IPC semaphores and message queues)
24
- `ksm` Kernel Same-Page Merging performance (several files under `/sys/kernel/mm/ksm`).
25
- - `netdata` (internal netdata resources utilization)
25
+ - `netdata` (internal Netdata resources utilization)
26
27
28
---
@@ -59,35 +59,35 @@ Hopefully, the Linux kernel provides many metrics that can provide deep insights
59
- **Total I/O time**
60
The sum of the duration of all completed I/O operations. This number can exceed the interval if the disk is able to execute multiple I/O operations in parallel.
61
- **Space usage**
62
- For mounted disks, netdata will provide a chart for their space, with 3 dimensions:
62
+ For mounted disks, Netdata will provide a chart for their space, with 3 dimensions:
63
1. free
64
2. used
65
3. reserved for root
66
- **inode usage**
67
- For mounted disks, netdata will provide a chart for their inodes (number of file and directories), with 3 dimensions:
67
+ For mounted disks, Netdata will provide a chart for their inodes (number of file and directories), with 3 dimensions:
68
1. free
69
2. used
70
3. reserved for root
71
72
### disk names
73
74
-netdata will automatically set the name of disks on the dashboard, from the mount point they are mounted, of course only when they are mounted. Changes in mount points are not currently detected (you will have to restart netdata to change the name of the disk). To use disk IDs provided by `/dev/disk/by-id`, the `name disks by id` option should be enabled. The `preferred disk ids` simple pattern allows choosing disk IDs to be used in the first place.
74
+Netdata will automatically set the name of disks on the dashboard, from the mount point they are mounted, of course only when they are mounted. Changes in mount points are not currently detected (you will have to restart Netdata to change the name of the disk). To use disk IDs provided by `/dev/disk/by-id`, the `name disks by id` option should be enabled. The `preferred disk ids` simple pattern allows choosing disk IDs to be used in the first place.
75
76
### performance metrics
77
78
-By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
78
+By default, Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
79
80
-netdata categorizes all block devices in 3 categories:
80
+Netdata categorizes all block devices in 3 categories:
81
82
1. physical disks (i.e. block devices that does not have slaves and are not partitions)
83
2. virtual disks (i.e. block devices that have slaves - like RAID devices)
84
3. disk partitions (i.e. block devices that are part of a physical disk)
85
86
-Performance metrics are enabled by default for all disk devices, except partitions and not-mounted virtual disks. Of course, you can enable/disable monitoring any block device by editing the netdata configuration file.
86
+Performance metrics are enabled by default for all disk devices, except partitions and not-mounted virtual disks. Of course, you can enable/disable monitoring any block device by editing the Netdata configuration file.
87
88
-### netdata configuration
88
+### Netdata configuration
89
90
-You can get the running netdata configuration using this:
90
+You can get the running Netdata configuration using this:
91
92
```sh
93
cd /etc/netdata
@@ -150,7 +150,7 @@ For all configuration options:
150
151
Of course, to set options, you will have to uncomment them. The comments show the internal defaults.
152
153
-After saving `/etc/netdata/netdata.conf`, restart your netdata to apply them.
153
+After saving `/etc/netdata/netdata.conf`, restart your Netdata to apply them.
154
155
#### Disabling performance metrics for individual device and to multiple devices by device type
156
You can pretty easy disable performance metrics for individual device, for ex.:
@@ -278,7 +278,7 @@ each state.
278
- **Network Interface Events (events/s)**
279
The number of packet framing errors, collisions detected on the interface, and carrier losses detected by the device driver.
280
281
-By default netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though).
281
+By default Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though).
282
283
#### alarms
284
@@ -340,7 +340,7 @@ Netdata does not enable SYNPROXY. It just uses the SYNPROXY metrics exposed by y
340
341
### Real-time monitoring of Linux Anti-DDoS
342
343
-netdata is able to monitor in real-time (per second updates) the operation of the Linux Anti-DDoS protection.
343
+Netdata is able to monitor in real-time (per second updates) the operation of the Linux Anti-DDoS protection.
344
345
It visualizes 4 charts:
346
@@ -353,7 +353,7 @@ Example image:
353
354
355
356
-See Linux Anti-DDoS in action at: **[netdata demo site (with SYNPROXY enabled)](https://registry.my-netdata.io/#menu_netfilter_submenu_synproxy)**
356
+See Linux Anti-DDoS in action at: **[Netdata demo site (with SYNPROXY enabled)](https://registry.my-netdata.io/#menu_netfilter_submenu_synproxy)**
357
358
## Linux power supply
359
collectors/python.d.plugin/README.md
+3
-3
@@ -1,10 +1,10 @@
1
# python.d.plugin
2
3
-`python.d.plugin` is a netdata external plugin. It is an **orchestrator** for data collection modules written in `python`.
3
+`python.d.plugin` is a Netdata external plugin. It is an **orchestrator** for data collection modules written in `python`.
4
5
1. It runs as an independent process `ps fax` shows it
6
-2. It is started and stopped automatically by netdata
7
-3. It communicates with netdata via a unidirectional pipe (sending data to the netdata daemon)
6
+2. It is started and stopped automatically by Netdata
7
+3. It communicates with Netdata via a unidirectional pipe (sending data to the `netdata` daemon)
8
4. Supports any number of data collection **modules**
9
5. Allows each **module** to have one or more data collection **jobs**
10
6. Each **job** is collecting one or more metrics from a single data source
collectors/python.d.plugin/chrony/README.md
+1
-1
@@ -14,7 +14,7 @@ It produces:
14
* system time
15
16
**Requirements:**
17
-Verify that user netdata can execute `chronyc tracking`. If necessary, update `/etc/chrony.conf`, `cmdallow`.
17
+Verify that user Netdata can execute `chronyc tracking`. If necessary, update `/etc/chrony.conf`, `cmdallow`.
18
19
### Configuration
20
collectors/python.d.plugin/dovecot/README.md
+1
-1
@@ -9,7 +9,7 @@ Module isn't compatible with new statistic api (v2.3), but you are still able to
9
by following [upgrading steps.](https://wiki2.dovecot.org/Upgrading/2.3).
10
11
**Requirement:**
12
-Dovecot UNIX socket with R/W permissions for user netdata or Dovecot with configured TCP/IP socket.
12
+Dovecot UNIX socket with R/W permissions for user `netdata` or Dovecot with configured TCP/IP socket.
13
14
Module gives information with following charts:
15
collectors/python.d.plugin/fail2ban/README.md
+1
-1
@@ -3,7 +3,7 @@
3
Module monitor fail2ban log file to show all bans for all active jails
4
5
**Requirements:**
6
- * fail2ban.log file MUST BE readable by netdata (A good idea is to add **create 0640 root netdata** to fail2ban conf at logrotate.d)
6
+ * fail2ban.log file MUST BE readable by Netdata (A good idea is to add **create 0640 root netdata** to fail2ban conf at logrotate.d)
7
8
It produces one chart with multiple lines (one line per jail)
9
collectors/python.d.plugin/go_expvar/README.md
+10
-10
@@ -104,7 +104,7 @@ number of currently running Goroutines and updates these stats every second.
104
In the next section, we will cover how to monitor and chart these exposed stats with
105
the use of `netdata`s ```go_expvar``` module.
106
107
-### Using netdata go_expvar module
107
+### Using Netdata go_expvar module
108
109
The `go_expvar` module is disabled by default. To enable it, edit [`python.d.conf`](../python.d.conf)
110
(to edit it on your system run `/etc/netdata/edit-config python.d.conf`), and change the `go_expvar`
@@ -143,7 +143,7 @@ Let's go over each of the defined options:
143
144
name: 'app1'
145
146
-This is the job name that will appear at the netdata dashboard.
146
+This is the job name that will appear at the Netdata dashboard.
147
If not defined, the job_name (top level key) will be used.
148
149
url: 'http://127.0.0.1:8080/debug/vars'
@@ -164,7 +164,7 @@ Will be explained in more detail below.
164
**Note: if `collect_memstats` is disabled and no `extra_charts` are defined, the plugin will
165
disable itself, as there will be no data to collect!**
166
167
-Apart from these options, each job supports options inherited from netdata's `python.d.plugin`
167
+Apart from these options, each job supports options inherited from Netdata's `python.d.plugin`
168
and its base `UrlService` class. These are:
169
170
update_every: 1 # the job's data collection frequency
@@ -174,21 +174,21 @@ and its base `UrlService` class. These are:
174
175
### Monitoring custom vars with go_expvar
176
177
-Now, memory stats might be useful, but what if you want netdata to monitor some custom values
177
+Now, memory stats might be useful, but what if you want Netdata to monitor some custom values
178
that your Go application exposes? The `go_expvar` module can do that as well with the use of
179
the `extra_charts` configuration variable.
180
181
-The `extra_charts` variable is a YaML list of netdata chart definitions.
181
+The `extra_charts` variable is a YaML list of Netdata chart definitions.
182
Each chart definition has the following keys:
183
184
- id: netdata chart ID
184
+ id: Netdata chart ID
185
options: a key-value mapping of chart options
186
lines: a list of line definitions
187
188
**Note: please do not use dots in the chart or line ID field.
189
See [this issue](https://github.com/netdata/netdata/pull/1902#issuecomment-284494195) for explanation.**
190
191
-Please see these two links to the official netdata documentation for more information about the values:
191
+Please see these two links to the official Netdata documentation for more information about the values:
192
193
- [External plugins - charts](../../plugins.d/#chart)
194
- [Chart variables](../#global-variables-order-and-chart)
@@ -202,9 +202,9 @@ Each line can have the following options:
202
# mandatory
203
expvar_key: the name of the expvar as present in the JSON output of /debug/vars endpoint
204
expvar_type: value type; supported are "float" or "int"
205
- id: the id of this line/dimension in netdata
205
+ id: the id of this line/dimension in Netdata
206
207
- # optional - netdata defaults are used if these options are not defined
207
+ # optional - Netdata defaults are used if these options are not defined
208
name: ''
209
algorithm: absolute
210
multiplier: 1
@@ -267,7 +267,7 @@ app1:
267
268
**Netdata charts example**
269
270
-The images below show how do the final charts in netdata look.
270
+The images below show how do the final charts in Netdata look.
271
272
273
collectors/python.d.plugin/haproxy/README.md
+1
-1
@@ -6,7 +6,7 @@ And health metrics such as backend servers status (server check should be used).
6
Plugin can obtain data from url **OR** unix socket.
7
8
**Requirement:**
9
-Socket MUST be readable AND writable by netdata user.
9
+Socket MUST be readable AND writable by the `netdata` user.
10
11
It produces:
12
collectors/python.d.plugin/httpcheck/README.md
+1
-1
@@ -33,7 +33,7 @@ server:
33
### notes
34
35
* The status chart is primarily intended for alarms, badges or for access via API.
36
- * A system/service/firewall might block netdata's access if a portscan or
36
+ * A system/service/firewall might block Netdata's access if a portscan or
37
similar is detected.
38
* This plugin is meant for simple use cases. Currently, the accuracy of the
39
response time is low and should be used as reference only.
collectors/python.d.plugin/isc_dhcpd/README.md
+1
-1
@@ -3,7 +3,7 @@
3
Module monitor leases database to show all active leases for given pools.
4
5
**Requirements:**
6
- * dhcpd leases file MUST BE readable by netdata
6
+ * dhcpd leases file MUST BE readable by Netdata
7
* pools MUST BE in CIDR format
8
9
It produces:
collectors/python.d.plugin/logind/README.md
+1
-1
@@ -19,7 +19,7 @@ It provides the following charts:
19
20
### configuration
21
22
-This module needs no configuration. Just make sure the netdata user
22
+This module needs no configuration. Just make sure the `netdata` user
23
can run the `loginctl` command and get a session list without having to
24
specify a path.
25
collectors/python.d.plugin/mongodb/README.md
+1
-1
@@ -122,7 +122,7 @@ Number of charts depends on mongodb version, storage engine and other features (
122
* member (time when last heartbeat was received from replica set member)
123
124
### prerequisite
125
-Create a read-only user for the netdata in the admin database.
125
+Create a read-only user for Netdata in the admin database.
126
127
1. Authenticate as the admin user.
128
collectors/python.d.plugin/oracledb/README.md
+1
-1
@@ -42,7 +42,7 @@ To use the Oracle module do the following:
42
43
2. Install Oracle Client libraries ([link](https://cx-oracle.readthedocs.io/en/latest/installation.html#install-oracle-client)).
44
45
-3. Create a read-only netdata user with proper access to your Oracle Database Server.
45
+3. Create a read-only `netdata` user with proper access to your Oracle Database Server.
46
47
Connect to your Oracle database with an administrative user and execute:
48
collectors/python.d.plugin/portcheck/README.md
+1
-1
@@ -28,7 +28,7 @@ server:
28
### notes
29
30
* The error chart is intended for alarms, badges or for access via API.
31
- * A system/service/firewall might block netdata's access if a portscan or
31
+ * A system/service/firewall might block Netdata's access if a portscan or
32
similar is detected.
33
* Currently, the accuracy of the latency is low and should be used as reference only.
34
collectors/python.d.plugin/web_log/README.md
+3
-3
@@ -6,7 +6,7 @@ Web server log files exist for more than 20 years. All web servers of all kinds,
6
7
Yet, after the appearance of google analytics and similar services, and the recent rise of APM (Application Performance Monitoring) with sophisticated time-series databases that collect and analyze metrics at the application level, all these web server log files are mostly just filling our disks, rotated every night without any use whatsoever.
8
9
-netdata turns this "useless" log file, into a powerful performance and health monitoring tool, capable of detecting, **in real-time**, most common web server problems, such as:
9
+Netdata turns this "useless" log file, into a powerful performance and health monitoring tool, capable of detecting, **in real-time**, most common web server problems, such as:
10
11
- too many redirects (i.e. **oops!** *this should not redirect clients to itself*)
12
- too many bad requests (i.e. **oops!** *a few files were not uploaded*)
@@ -18,7 +18,7 @@ netdata turns this "useless" log file, into a powerful performance and health mo
18
19
## Usage
20
21
-If netdata is installed on a system running a web server, it will detect it and it will automatically present a series of charts, with information obtained from the web server API, like these (*these do not come from the web server log file*):
21
+If Netdata is installed on a system running a web server, it will detect it and it will automatically present a series of charts, with information obtained from the web server API, like these (*these do not come from the web server log file*):
22
23
24
*[**netdata**](https://my-netdata.io/) charts based on metrics collected by querying the `nginx` API (i.e. `/stub_status`).*
@@ -197,7 +197,7 @@ alarm|description|minimum<br/>requests|warning|critical
197
198
The column `minimum requests` state the minimum number of requests required for the alarm to be evaluated. We found that when the site is receiving requests above this rate, these alarms are pretty accurate (i.e. no false-positives).
199
200
-[**netdata**](https://my-netdata.io/) alarms are user configurable. Sample config files can be found under directory `health/health.d` of the netdata github repository. So, even [`web_log` alarms can be adapted to your needs](../../../health/health.d/web_log.conf).
200
+[**netdata**](https://my-netdata.io/) alarms are user configurable. Sample config files can be found under directory `health/health.d` of the [Netdata GitHub repository](https://github.com/netdata/netdata/). So, even [`web_log` alarms can be adapted to your needs](../../../health/health.d/web_log.conf).
201
202
203
[]()
collectors/statsd.plugin/README.md
+26
-26
@@ -4,7 +4,7 @@ statsd is a system to collect data from any application. Applications are sendin
4
5
There is a [plethora of client libraries](https://github.com/etsy/statsd/wiki#client-implementations) for embedding statsd metrics to any application framework. This makes statsd quite popular for custom application metrics.
6
7
-netdata is a fully featured statsd server. It can collect statsd formatted metrics, visualize them on its dashboards, stream them to other netdata servers or archive them to backend time-series databases.
7
+Netdata is a fully featured statsd server. It can collect statsd formatted metrics, visualize them on its dashboards, stream them to other Netdata servers or archive them to backend time-series databases.
8
9
Netdata statsd is inside Netdata (an internal plugin, running inside the Netdata daemon), it is configured via `netdata.conf` and by-default listens on standard statsd ports (tcp and udp 8125 - yes, Netdata statsd server supports both tcp and udp at the same time).
10
@@ -62,19 +62,19 @@ The application may append `|@sampling_rate`, where `sampling_rate` is a number
62
63
#### Overlapping metrics
64
65
-netdata statsd maintains different indexes for each of the types supported. This means the same metric `name` may exist under different types concurrently.
65
+Netdata's statsd server maintains different indexes for each of the types supported. This means the same metric `name` may exist under different types concurrently.
66
67
#### Multiple metrics per packet
68
69
-netdata accepts multiple metrics per packet if each is terminated with `\n`.
69
+Netdata accepts multiple metrics per packet if each is terminated with `\n`.
70
71
#### TCP packets
72
73
-netdata listens for both TCP and UDP packets. For TCP though, is it important to always append `\n` on each metric. netdata uses this to detect if a metric is split into multiple TCP packets. On disconnect, even the remaining (non terminated with `\n`) buffer, is processed.
73
+Netdata listens for both TCP and UDP packets. For TCP though, is it important to always append `\n` on each metric. Netdata uses this to detect if a metric is split into multiple TCP packets. On disconnect, even the remaining (non terminated with `\n`) buffer, is processed.
74
75
#### UDP packets
76
77
-When sending multiple packets over UDP, it is important not to exceed the network MTU (usually 1500 bytes minus a few bytes for the headers). netdata will accept UDP packets up to 9000 bytes, but the underlying network will not exceed MTU.
77
+When sending multiple packets over UDP, it is important not to exceed the network MTU (usually 1500 bytes minus a few bytes for the headers). Netdata will accept UDP packets up to 9000 bytes, but the underlying network will not exceed MTU.
78
79
## configuration
80
@@ -107,7 +107,7 @@ This is the statsd configuration at `/etc/netdata/netdata.conf`:
107
### statsd main config options
108
- `enabled = yes|no`
109
110
- controls if statsd will be enabled for this netdata. The default is enabled.
110
+ controls if statsd will be enabled for this Netdata. The default is enabled.
111
112
- `default port = 8125`
113
@@ -117,15 +117,15 @@ This is the statsd configuration at `/etc/netdata/netdata.conf`:
117
118
is a space separated list of IPs and ports to listen to. The format is `PROTOCOL:IP:PORT` - if `PORT` is omitted, the `default port` will be used. If `IP` is IPv6, it needs to be enclosed in `[]`. `IP` can also be ` * ` (to listen on all IPs) or even a hostname.
119
120
-- `update every (flushInterval) = 1` seconds, controls the frequency statsd will push the collected metrics to netdata charts.
120
+- `update every (flushInterval) = 1` seconds, controls the frequency statsd will push the collected metrics to Netdata charts.
121
122
-- `decimal detail = 1000` controls the number of fractional digits in gauges and histograms. netdata collects metrics using signed 64 bit integers and their fractional detail is controlled using multipliers and divisors. This setting is used to multiply all collected values to convert them to integers and is also set as the divisors, so that the final data will be a floating point number with this fractional detail (1000 = X.0 - X.999, 10000 = X.0 - X.9999, etc).
122
+- `decimal detail = 1000` controls the number of fractional digits in gauges and histograms. Netdata collects metrics using signed 64 bit integers and their fractional detail is controlled using multipliers and divisors. This setting is used to multiply all collected values to convert them to integers and is also set as the divisors, so that the final data will be a floating point number with this fractional detail (1000 = X.0 - X.999, 10000 = X.0 - X.9999, etc).
123
124
The rest of the settings are discussed below.
125
126
## statsd charts
127
128
-netdata can visualize statsd collected metrics in 2 ways:
128
+Netdata can visualize statsd collected metrics in 2 ways:
129
130
1. Each metric gets its own **private chart**. This is the default and does not require any configuration (although there are a few options to tweak).
131
@@ -143,11 +143,11 @@ create private charts for metrics matching = !myapp.*.badmetric myapp.*
143
144
The default is to render private charts for all metrics.
145
146
-The `memory mode` of the round robin database and the `history` of private metric charts are controlled with `private charts memory mode` and `private charts history`. The defaults for both settings is to use the global netdata settings. So, you need to edit them only when you want statsd to use different settings compared to the global ones.
146
+The `memory mode` of the round robin database and the `history` of private metric charts are controlled with `private charts memory mode` and `private charts history`. The defaults for both settings is to use the global Netdata settings. So, you need to edit them only when you want statsd to use different settings compared to the global ones.
147
148
-If you have thousands of metrics, each with its own private chart, you may notice that your web browser becomes slow when you view the netdata dashboard (this is a web browser issue we need to address at the netdata UI). So, netdata has a protection to stop creating charts when `max private charts allowed = 200` (soft limit) is reached.
148
+If you have thousands of metrics, each with its own private chart, you may notice that your web browser becomes slow when you view the Netdata dashboard (this is a web browser issue we need to address at the Netdata UI). So, Netdata has a protection to stop creating charts when `max private charts allowed = 200` (soft limit) is reached.
149
150
-The metrics above this soft limit are still processed by netdata and will be available to be sent to backend time-series databases, up to `max private charts hard limit = 1000`. So, between 200 and 1000 charts, netdata will still generate charts, but they will automatically be created with `memory mode = none` (netdata will not maintain a database for them). These metrics will be sent to backend time series databases, if the backend configuration is set to `as collected`.
150
+The metrics above this soft limit are still processed by Netdata and will be available to be sent to backend time-series databases, up to `max private charts hard limit = 1000`. So, between 200 and 1000 charts, Netdata will still generate charts, but they will automatically be created with `memory mode = none` (Netdata will not maintain a database for them). These metrics will be sent to backend time series databases, if the backend configuration is set to `as collected`.
151
152
Metrics above the hard limit are still collected, but they can only be used in synthetic charts (once a metric is added to chart, it will be sent to backend servers too).
153
@@ -217,7 +217,7 @@ Using synthetic charts, you can create dedicated sections on the dashboard to re
217
218
Synthetic charts are organized in
219
220
-- **applications** (i.e. entries at the main menu of the netdata dashboard)
220
+- **applications** (i.e. entries at the main menu of the Netdata dashboard)
221
- **charts for each application** (grouped in families - i.e. submenus at the dashboard menu)
222
- **statsd metrics for each chart** (i.e. dimensions of the charts)
223
@@ -257,11 +257,11 @@ Using the above configuration `myapp` should get its own section on the dashboar
257
`[app]` starts a new application definition. The supported settings in this section are:
258
259
- `name` defines the name of the app.
260
-- `metrics` is a netdata simple pattern (space separated patterns, using `*` for wildcard, possibly starting with `!` for negative match). This pattern should match all the possible statsd metrics that will be participating in the application `myapp`.
260
+- `metrics` is a Netdata simple pattern (space separated patterns, using `*` for wildcard, possibly starting with `!` for negative match). This pattern should match all the possible statsd metrics that will be participating in the application `myapp`.
261
- `private charts = yes|no`, enables or disables private charts for the metrics matched.
262
- `gaps when not collected = yes|no`, enables or disables gaps on the charts of the application, when metrics are not collected.
263
-- `memory mode` sets the memory mode for all charts of the application. The default is the global default for netdata (not the global default for statsd private charts).
264
-- `history` sets the size of the round robin database for this application. The default is the global default for netdata (not the global default for statsd private charts).
263
+- `memory mode` sets the memory mode for all charts of the application. The default is the global default for Netdata (not the global default for statsd private charts).
264
+- `history` sets the size of the round robin database for this application. The default is the global default for Netdata (not the global default for statsd private charts).
265
266
`[dictionary]` defines name-value associations. These are used to renaming metrics, when added to synthetic charts. Metric names are also defined at each `dimension` line. However, using the dictionary dimension names can be declared globally, for each app and is the only way to rename dimensions when using patterns. Of course the dictionary can be empty or missing.
267
@@ -281,7 +281,7 @@ So, the format is this:
281
dimension = [pattern] METRIC NAME TYPE MULTIPLIER DIVIDER OPTIONS
282
```
283
284
-`pattern` is a keyword. When set, `METRIC` is expected to be a netdata simple pattern that will be used to match all the statsd metrics to be added to the chart. So, `pattern` automatically matches any number of statsd metrics, all of which will be added as separate chart dimensions.
284
+`pattern` is a keyword. When set, `METRIC` is expected to be a Netdata simple pattern that will be used to match all the statsd metrics to be added to the chart. So, `pattern` automatically matches any number of statsd metrics, all of which will be added as separate chart dimensions.
285
286
`TYPE`, `MUTLIPLIER`, `DIVIDER` and `OPTIONS` are optional.
287
@@ -336,13 +336,13 @@ and this synthetic chart:
336
337
The `[dictionary]` section accepts any number of `name = value` pairs.
338
339
-netdata uses this dictionary as follows:
339
+Netdata uses this dictionary as follows:
340
341
1. When a `dimension` has a non-empty `NAME`, that name is looked up at the dictionary.
342
343
2. If the above lookup gives nothing, or the `dimension` has an empty `NAME`, the original statsd metric name is looked up at the dictionary.
344
345
-3. If any of the above succeeds, netdata uses the `value` of the dictionary, to set the name of the dimension. The dimensions will have as ID the original statsd metric name, and as name, the dictionary value.
345
+3. If any of the above succeeds, Netdata uses the `value` of the dictionary, to set the name of the dimension. The dimensions will have as ID the original statsd metric name, and as name, the dictionary value.
346
347
So, you can use the dictionary in 2 ways:
348
@@ -351,11 +351,11 @@ So, you can use the dictionary in 2 ways:
351
352
In both cases, the dimension will be added with ID `myapp.metric1` and will be named `metric1 name`. So, in alarms you can use either of the 2 as `${myapp.metric1}` or `${metric1 name}`.
353
354
-> keep in mind that if you add multiple times the same statsd metric to a chart, netdata will append `TYPE` to the dimension ID, so `myapp.metric1` will be added as `myapp.metric1_last` or `myapp.metric1_events`, etc. If you add multiple times the same metric with the same `TYPE` to a chart, netdata will also append an incremental counter to the dimension ID, i.e. `myapp.metric1_last1`, `myapp.metric1_last2`, etc.
354
+> keep in mind that if you add multiple times the same statsd metric to a chart, Netdata will append `TYPE` to the dimension ID, so `myapp.metric1` will be added as `myapp.metric1_last` or `myapp.metric1_events`, etc. If you add multiple times the same metric with the same `TYPE` to a chart, Netdata will also append an incremental counter to the dimension ID, i.e. `myapp.metric1_last1`, `myapp.metric1_last2`, etc.
355
356
#### dimension patterns
357
358
-netdata allows adding multiple dimensions to a chart, by matching the statsd metrics with a netdata simple pattern.
358
+Netdata allows adding multiple dimensions to a chart, by matching the statsd metrics with a Netdata simple pattern.
359
360
Assume we have an API that provides statsd metrics for each response code per method it supports, like these:
361
@@ -382,7 +382,7 @@ To add all response codes of `myapp.api.get` to a chart use this:
382
dimension = pattern 'myapp.api.get.* '' last 1 1
383
```
384
385
-The above will add dimension named `200`, `400` and `500` (yes, netdata extracts the wildcarded part of the metric name - so the dimensions will be named with whatever the `*` matched). You can rename the dimensions with this:
385
+The above will add dimension named `200`, `400` and `500` (yes, Netdata extracts the wildcarded part of the metric name - so the dimensions will be named with whatever the `*` matched). You can rename the dimensions with this:
386
387
```
388
[dictionary]
@@ -435,17 +435,17 @@ Using the above, the dimensions will be added as `GET`, `ADD` and `DELETE`.
435
436
## interpolation
437
438
-~~If you send just one value to statsd, you will notice that the chart is created but no value is shown. The reason is that netdata interpolates all values at second boundaries. For incremental values (`counters` and `meters` in statsd terminology), if you send 10 at 00:00:00.500, 20 at 00:00:01.500 and 30 at 00:00:02.500, netdata will show 15 at 00:00:01 and 25 at 00:00:02.~~
438
+~~If you send just one value to statsd, you will notice that the chart is created but no value is shown. The reason is that Netdata interpolates all values at second boundaries. For incremental values (`counters` and `meters` in statsd terminology), if you send 10 at 00:00:00.500, 20 at 00:00:01.500 and 30 at 00:00:02.500, Netdata will show 15 at 00:00:01 and 25 at 00:00:02.~~
439
440
-~~This interpolation is automatic and global in netdata for all charts, for incremental values. This means that for the chart to start showing values you need to send 2 values across 2 flush intervals.~~
440
+~~This interpolation is automatic and global in Netdata for all charts, for incremental values. This means that for the chart to start showing values you need to send 2 values across 2 flush intervals.~~
441
442
-~~(although this is required for incremental values, netdata allows mixing incremental and absolute values on the same charts, so this little limitation [i.e. 2 values to start visualization], is applied on all netdata dimensions).~~
442
+~~(although this is required for incremental values, Netdata allows mixing incremental and absolute values on the same charts, so this little limitation [i.e. 2 values to start visualization], is applied on all Netdata dimensions).~~
443
444
(statsd metrics do not loose their first data collection due to interpolation anymore - fixed with [PR #2411](https://github.com/netdata/netdata/pull/2411))
445
446
## sending statsd metrics from shell scripts
447
448
-You can send/update statsd metrics from shell scripts. You can use this feature, to visualize in netdata automated jobs you run on your servers.
448
+You can send/update statsd metrics from shell scripts. You can use this feature, to visualize in Netdata automated jobs you run on your servers.
449
450
The command you need to run is:
451
collectors/tc.plugin/README.md
+7
-7
@@ -42,7 +42,7 @@ QoS is about 2 features:
42
43
1. **Monitoring the bandwidth used by services**
44
45
- netdata provides wonderful real-time charts, like this one (wait to see the orange `rsync` part):
45
+ Netdata provides wonderful real-time charts, like this one (wait to see the orange `rsync` part):
46
47
48
@@ -62,7 +62,7 @@ QoS is about 2 features:
62
63
When your system is under a DDoS attack, it will get a lot more bandwidth compared to the one it can handle and probably your applications will crash. Setting a limit on the inbound traffic using QoS, will protect your servers (throttle the requests) and depending on the size of the attack may allow your legitimate users to access the server, while the attack is taking place.
64
65
- Using QoS together with a [SYNPROXY](../proc.plugin/README.md#linux-anti-ddos) will provide a great degree of protection against most DDoS attacks. Actually when I wrote that article, a few folks tried to DDoS the netdata demo site to see in real-time the SYNPROXY operation. They did not do it right, but anyway a great deal of requests reached the netdata server. What saved netdata was QoS. The netdata demo server has QoS installed, so the requests were throttled and the server did not even reach the point of resource starvation. Read about it [here](../proc.plugin/README.md#linux-anti-ddos).
65
+ Using QoS together with a [SYNPROXY](../proc.plugin/README.md#linux-anti-ddos) will provide a great degree of protection against most DDoS attacks. Actually when I wrote that article, a few folks tried to DDoS the Netdata demo site to see in real-time the SYNPROXY operation. They did not do it right, but anyway a great deal of requests reached the Netdata server. What saved Netdata was QoS. The Netdata demo server has QoS installed, so the requests were throttled and the server did not even reach the point of resource starvation. Read about it [here](../proc.plugin/README.md#linux-anti-ddos).
66
67
On top of all these, QoS is extremely light. You will configure it once, and this is it. It will not bother you again and it will not use any noticeable CPU resources, especially on application and database servers.
68
@@ -72,7 +72,7 @@ On top of all these, QoS is extremely light. You will configure it once, and thi
72
73
- ensure each end-user connection will get a fair cut of the available bandwidth.
74
75
-Once **traffic classification** is applied, we can use **[netdata](https://github.com/netdata/netdata)** to visualize the bandwidth consumption per class in real-time (no configuration is needed for netdata - it will figure it out).
75
+Once **traffic classification** is applied, we can use **[netdata](https://github.com/netdata/netdata)** to visualize the bandwidth consumption per class in real-time (no configuration is needed for Netdata - it will figure it out).
76
77
QoS, is extremely light. You will configure it once, and this is it. It will not bother you again and it will not use any noticeable CPU resources, especially on application and database servers.
78
@@ -115,10 +115,10 @@ To do it the hard way, you can go through the [tc configuration steps](#qos-conf
115
116
The **[FireHOL](https://firehol.org/)** package already distributes **[FireQOS](https://firehol.org/tutorial/fireqos-new-user/)**. Check the **[FireQOS tutorial](https://firehol.org/tutorial/fireqos-new-user/)** to learn how to write your own QoS configuration.
117
118
-With **[FireQOS](https://firehol.org/tutorial/fireqos-new-user/)**, it is **really simple for everyone to use QoS in Linux**. Just install the package `firehol`. It should already be available for your distribution. If not, check the **[FireHOL Installation Guide](https://firehol.org/installing/)**. After that, you will have the `fireqos` command which uses a configuration like the following `/etc/firehol/fireqos.conf`, used at the netdata demo site:
118
+With **[FireQOS](https://firehol.org/tutorial/fireqos-new-user/)**, it is **really simple for everyone to use QoS in Linux**. Just install the package `firehol`. It should already be available for your distribution. If not, check the **[FireHOL Installation Guide](https://firehol.org/installing/)**. After that, you will have the `fireqos` command which uses a configuration like the following `/etc/firehol/fireqos.conf`, used at the Netdata demo site:
119
120
```sh
121
- # configure the netdata ports
121
+ # configure the Netdata ports
122
server_netdata_ports="tcp/19999"
123
124
interface eth0 world bidirectional ethernet balanced rate 50Mbit
@@ -155,7 +155,7 @@ With **[FireQOS](https://firehol.org/tutorial/fireqos-new-user/)**, it is **real
155
match input src 10.2.3.5
156
```
157
158
-Nothing more is needed. You just run `fireqos start` to apply this configuration, restart netdata and you have real-time visualization of the bandwidth consumption of your applications. FireQOS is not a daemon. It will just convert the configuration to `tc` commands. It will run them and it will exit.
158
+Nothing more is needed. You just run `fireqos start` to apply this configuration, restart Netdata and you have real-time visualization of the bandwidth consumption of your applications. FireQOS is not a daemon. It will just convert the configuration to `tc` commands. It will run them and it will exit.
159
160
**IMPORTANT**: If you copy this configuration to apply it to your system, please adapt the speeds - experiment in non-production environments to learn the tool, before applying it on your servers.
161
@@ -191,7 +191,7 @@ Add the following configuration option in `/etc/netdata.conf`:
191
Finally, create `/etc/netdata/tc-qos-helper.conf` with this content:
192
```tc_show="class"```
193
194
-Please note, that by default Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
194
+Please note, that by default Netdata will enable monitoring metrics only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Set `yes` for a chart instead of `auto` to enable it permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
195
196
197
[]()
collectors/xenstat.plugin/README.md
+2
-2
@@ -6,7 +6,7 @@
6
7
1. install `xen-dom0-libs-devel` and `yajl-devel` using the package manager of your system.
8
9
-2. re-install netdata from source. The installer will detect that the required libraries are now available and will also build xenstat.plugin.
9
+2. re-install Netdata from source. The installer will detect that the required libraries are now available and will also build xenstat.plugin.
10
11
Keep in mind that `libxenstat` requires root access, so the plugin is setuid to root.
12
@@ -25,7 +25,7 @@ Domain:
25
26
## Configuration
27
28
-If you need to disable xenstat for netdata, edit /etc/netdata/netdata.conf and set:
28
+If you need to disable xenstat for Netdata, edit /etc/netdata/netdata.conf and set:
29
30
```
31
[plugins]
contrib/README.md
+5
-5
@@ -1,4 +1,4 @@
1
-# netdata contrib
1
+# Netdata contrib
2
3
## Building .deb packages
4
@@ -7,8 +7,8 @@ Debian package. It has been tested on Debian Jessie and Wheezy,
7
but should work, possibly with minor changes, if you have other
8
dpkg-based systems such as Ubuntu or Mint.
9
10
-To build netdata for a Debian Jessie system, the debian directory
11
-has to be available in the root of the netdata source. The easiest
10
+To build Netdata for a Debian Jessie system, the debian directory
11
+has to be available in the root of the Netdata source. The easiest
12
way to do this is with a symlink:
13
14
~/netdata$ ln -s contrib/debian
@@ -50,9 +50,9 @@ updates first.
50
51
Then proceed as the main instructions above.
52
53
-### Reinstalling netdata
53
+### Reinstalling Netdata
54
55
-The recommended way to upgrade netdata packages built from this
55
+The recommended way to upgrade Netdata packages built from this
56
source is to remove the current package from your system, then
57
install the new package. Upgrading on wheezy is known to not
58
work cleanly; Jessie may behave as expected.
contrib/sles11/README.md
+2
-2
@@ -1,10 +1,10 @@
1
-# spec to build netdata RPM for sles 11
1
+# Spec to build Netdata RPM for sles 11
2
3
Based on [opensuse rpm spec](https://build.opensuse.org/package/show/network/netdata) with some
4
changes and additions for sles 11 backport, namely:
5
- init.d script
6
- run-time dependency on python ordereddict backport
7
-- patch for netdata python.d plugin to work with older python
7
+- patch for Netdata python.d plugin to work with older python
8
- crude hack of notification script to work with bash 3 (email and syslog only, one destination,
9
see comments at the top)
10
daemon/README.md
+61
-62
@@ -2,10 +2,10 @@
2
3
## Starting netdata
4
5
-- You can start netdata by executing it with `/usr/sbin/netdata` (the installer will also start it).
5
+- You can start Netdata by executing it with `/usr/sbin/netdata` (the installer will also start it).
6
7
-- You can stop netdata by killing it with `killall netdata`.
8
- You can stop and start netdata at any point. Netdata saves on exit its round robbin
7
+- You can stop Netdata by killing it with `killall netdata`.
8
+ You can stop and start Netdata at any point. Netdata saves on exit its round robbin
9
database to `/var/cache/netdata` so that it will continue from where it stopped the last time.
10
11
Access to the web site, for all graphs, is by default on port `19999`, so go to:
@@ -16,7 +16,7 @@ Access to the web site, for all graphs, is by default on port `19999`, so go to:
16
17
You can get the running config file at any time, by accessing `http://127.0.0.1:19999/netdata.conf`.
18
19
-### Starting netdata at boot
19
+### Starting Netdata at boot
20
21
In the `system` directory you can find scripts and configurations for the various distros.
22
@@ -27,7 +27,7 @@ The installer already installs `netdata.service` if it detects a systemd system.
27
To install `netdata.service` by hand, run:
28
29
```sh
30
-# stop netdata
30
+# stop Netdata
31
killall netdata
32
33
# copy netdata.service to systemd
@@ -36,10 +36,10 @@ cp system/netdata.service /etc/systemd/system/
36
# let systemd know there is a new service
37
systemctl daemon-reload
38
39
-# enable netdata at boot
39
+# enable Netdata at boot
40
systemctl enable netdata
41
42
-# start netdata
42
+# start Netdata
43
systemctl start netdata
44
```
45
@@ -48,7 +48,7 @@ systemctl start netdata
48
In the system directory you can find `netdata-lsb`. Copy it to the proper place according to your distribution documentation. For Ubuntu, this can be done via running the following commands as root.
49
50
```sh
51
-# copy the netdata startup file to /etc/init.d
51
+# copy the Netdata startup file to /etc/init.d
52
cp system/netdata-lsb /etc/init.d/netdata
53
54
# make sure it is executable
@@ -67,7 +67,7 @@ In the `system` directory you can find `netdata-openrc`. Copy it to the proper p
67
For older versions of RHEL/CentOS that don't have systemd, an init script is included in the system directory. This can be installed by running the following commands as root.
68
69
```sh
70
-# copy the netdata startup file to /etc/init.d
70
+# copy the Netdata startup file to /etc/init.d
71
cp system/netdata-init-d /etc/init.d/netdata
72
73
# make sure it is executable
@@ -81,7 +81,7 @@ _There have been some recent work on the init script, see PR https://github.com/
81
82
#### other systems
83
84
-You can start netdata by running it from `/etc/rc.local` or equivalent.
84
+You can start Netdata by running it from `/etc/rc.local` or equivalent.
85
86
## Command line options
87
@@ -97,7 +97,7 @@ netdata -h
97
98
The program will print the supported command line parameters.
99
100
-The command line options of the netdata 1.10.0 version are the following:
100
+The command line options of the Netdata 1.10.0 version are the following:
101
```
102
103
^
@@ -182,7 +182,7 @@ The command line options of the netdata 1.10.0 version are the following:
182
183
## Log files
184
185
-netdata uses 3 log files:
185
+Netdata uses 3 log files:
186
187
1. `error.log`
188
2. `access.log`
@@ -190,18 +190,18 @@ netdata uses 3 log files:
190
191
Any of them can be disabled by setting it to `/dev/null` or `none` in `netdata.conf`.
192
By default `error.log` and `access.log` are enabled. `debug.log` is only enabled if
193
-debugging/tracing is also enabled (netdata needs to be compiled with debugging enabled).
193
+debugging/tracing is also enabled (Netdata needs to be compiled with debugging enabled).
194
195
Log files are stored in `/var/log/netdata/` by default.
196
197
#### error.log
198
199
-The `error.log` is the `stderr` of the netdata daemon and all external plugins run by netdata.
199
+The `error.log` is the `stderr` of the `netdata` daemon and all external plugins run by netdata.
200
201
-So if any process, in the netdata process tree, writes anything to its standard error,
201
+So if any process, in the Netdata process tree, writes anything to its standard error,
202
it will appear in `error.log`.
203
204
-For most netdata programs (including standard external plugins shipped by netdata), the
204
+For most Netdata programs (including standard external plugins shipped by netdata), the
205
following lines may appear:
206
207
tag|description
@@ -213,7 +213,7 @@ tag|description
213
So, when auto-detection of data collection fail, `ERROR` lines are logged and the relevant modules
214
are disabled, but the program continues to run.
215
216
-When a netdata program cannot run at all, a `FATAL` line is logged.
216
+When a Netdata program cannot run at all, a `FATAL` line is logged.
217
218
#### access.log
219
@@ -231,7 +231,7 @@ where:
231
- `PERCENT_COMPRESSION` is the percentage of traffic saved due to compression.
232
- `PREP_TIME` is the time in milliseconds needed to prepared the response.
233
- `SENT_TIME` is the time in milliseconds needed to sent the response to the client.
234
- - `TOTAL_TIME` is the total time the request was inside netdata (from the first byte of the request to the last byte of the response).
234
+ - `TOTAL_TIME` is the total time the request was inside Netdata (from the first byte of the request to the last byte of the response).
235
- `ACTION` can be `filecopy`, `options` (used in CORS), `data` (API call).
236
237
@@ -242,17 +242,17 @@ See [debugging](#debugging).
242
243
## OOM Score
244
245
-netdata runs with `OOMScore = 1000`. This means netdata will be the first to be killed when your
245
+Netdata runs with `OOMScore = 1000`. This means Netdata will be the first to be killed when your
246
server runs out of memory.
247
248
-You can set netdata OOMScore in `netdata.conf`, like this:
248
+You can set Netdata OOMScore in `netdata.conf`, like this:
249
250
```
251
[global]
252
OOM score = 1000
253
```
254
255
-netdata logs its OOM score when it starts:
255
+Netdata logs its OOM score when it starts:
256
257
```sh
258
# grep OOM /var/log/netdata/error.log
@@ -261,16 +261,16 @@ netdata logs its OOM score when it starts:
261
262
#### OOM score and systemd
263
264
-netdata will not be able to lower its OOM Score below zero, when it is started as the `netdata`
264
+Netdata will not be able to lower its OOM Score below zero, when it is started as the `netdata`
265
user (systemd case).
266
267
-To allow netdata control its OOM Score in such cases, you will need to edit
267
+To allow Netdata control its OOM Score in such cases, you will need to edit
268
`netdata.service` and set:
269
270
```
271
[Service]
272
-# The minimum netdata Out-Of-Memory (OOM) score.
273
-# netdata (via [global].OOM score in netdata.conf) can only increase the value set here.
272
+# The minimum Netdata Out-Of-Memory (OOM) score.
273
+# Netdata (via [global].OOM score in netdata.conf) can only increase the value set here.
274
# To decrease it, set the minimum here and set the same or a higher value in netdata.conf.
275
# Valid values: -1000 (never kill netdata) to 1000 (always kill netdata).
276
OOMScoreAdjust=-1000
@@ -278,7 +278,7 @@ OOMScoreAdjust=-1000
278
279
Run `systemctl daemon-reload` to reload these changes.
280
281
-The above, sets and OOMScore for netdata to `-1000`, so that netdata can increase it via
281
+The above, sets and OOMScore for Netdata to `-1000`, so that Netdata can increase it via
282
`netdata.conf`.
283
284
If you want to control it entirely via systemd, you can set in `netdata.conf`:
@@ -293,9 +293,9 @@ Using the above, whatever OOM Score you have set at `netdata.service` will be ma
293
294
## Netdata process scheduling policy
295
296
-By default netdata runs with the `idle` process scheduling policy, so that it uses CPU resources, only when there is idle CPU to spare. On very busy servers (or weak servers), this can lead to gaps on the charts.
296
+By default Netdata runs with the `idle` process scheduling policy, so that it uses CPU resources, only when there is idle CPU to spare. On very busy servers (or weak servers), this can lead to gaps on the charts.
297
298
-You can set netdata scheduling policy in `netdata.conf`, like this:
298
+You can set Netdata scheduling policy in `netdata.conf`, like this:
299
300
```
301
[global]
@@ -306,7 +306,7 @@ You can use the following:
306
307
policy|description
308
:-----:|:--------
309
-`idle`|use CPU only when there is spare - this is lower than nice 19 - it is the default for netdata and it is so low that netdata will run in "slow motion" under extreme system load, resulting in short (1-2 seconds) gaps at the charts.
309
+`idle`|use CPU only when there is spare - this is lower than nice 19 - it is the default for Netdata and it is so low that Netdata will run in "slow motion" under extreme system load, resulting in short (1-2 seconds) gaps at the charts.
310
`other`<br/>or<br/>`nice`|this is the default policy for all processes under Linux. It provides dynamic priorities based on the `nice` level of each process. Check below for setting this `nice` level for netdata.
311
`batch`|This policy is similar to `other` in that it schedules the thread according to its dynamic priority (based on the `nice` value). The difference is that this policy will cause the scheduler to always assume that the thread is CPU-intensive. Consequently, the scheduler will apply a small scheduling penalty with respect to wake-up behavior, so that this thread is mildly disfavored in scheduling decisions.
312
`fifo`|`fifo` can be used only with static priorities higher than 0, which means that when a `fifo` threads becomes runnable, it will always immediately preempt any currently running `other`, `batch`, or `idle` thread. `fifo` is a simple scheduling algorithm without time slicing.
@@ -337,30 +337,30 @@ When the policy is set to `other`, `nice`, or `batch`, the following will appear
337
338
## scheduling settings and systemd
339
340
-netdata will not be able to set its scheduling policy and priority to more important values when it is started as the `netdata` user (systemd case).
340
+Netdata will not be able to set its scheduling policy and priority to more important values when it is started as the `netdata` user (systemd case).
341
342
You can set these settings at `/etc/systemd/system/netdata.service`:
343
344
```
345
[Service]
346
-# By default netdata switches to scheduling policy idle, which makes it use CPU, only
346
+# By default Netdata switches to scheduling policy idle, which makes it use CPU, only
347
# when there is spare available.
348
# Valid policies: other (the system default) | batch | idle | fifo | rr
349
#CPUSchedulingPolicy=other
350
351
-# This sets the maximum scheduling priority netdata can set (for policies: rr and fifo).
352
-# netdata (via [global].process scheduling priority in netdata.conf) can only lower this value.
351
+# This sets the maximum scheduling priority Netdata can set (for policies: rr and fifo).
352
+# Netdata (via [global].process scheduling priority in netdata.conf) can only lower this value.
353
# Priority gets values 1 (lowest) to 99 (highest).
354
#CPUSchedulingPriority=1
355
356
# For scheduling policy 'other' and 'batch', this sets the lowest niceness of netdata.
357
-# netdata (via [global].process nice level in netdata.conf) can only increase the value set here.
357
+# Netdata (via [global].process nice level in netdata.conf) can only increase the value set here.
358
#Nice=0
359
```
360
361
Run `systemctl daemon-reload` to reload these changes.
362
363
-Now, tell netdata to keep these settings, as set by systemd, by editing `netdata.conf` and setting:
363
+Now, tell Netdata to keep these settings, as set by systemd, by editing `netdata.conf` and setting:
364
365
```
366
[global]
@@ -370,9 +370,9 @@ Now, tell netdata to keep these settings, as set by systemd, by editing `netdata
370
Using the above, whatever scheduling settings you have set at `netdata.service` will be maintained by netdata.
371
372
373
-#### Example 1: netdata with nice -1 on non-systemd systems
373
+#### Example 1: Netdata with nice -1 on non-systemd systems
374
375
-On a system that is not based on systemd, to make netdata run with nice level -1 (a little bit higher to the default for all programs), edit netdata.conf and set:
375
+On a system that is not based on systemd, to make Netdata run with nice level -1 (a little bit higher to the default for all programs), edit `netdata.conf` and set:
376
377
```
378
[global]
@@ -387,9 +387,9 @@ sudo service netdata restart
387
```
388
389
390
-#### Example 2: netdata with nice -1 on systemd systems
390
+#### Example 2: Netdata with nice -1 on systemd systems
391
392
-On a system that is based on systemd, to make netdata run with nice level -1 (a little bit higher to the default for all programs), edit netdata.conf and set:
392
+On a system that is based on systemd, to make Netdata run with nice level -1 (a little bit higher to the default for all programs), edit `netdata.conf` and set:
393
394
```
395
[global]
@@ -415,9 +415,9 @@ sudo systemctl restart netdata
415
416
You may notice that netdata's virtual memory size, as reported by `ps` or `/proc/pid/status` (or even netdata's applications virtual memory chart) is unrealistically high.
417
418
-For example, it may be reported to be 150+MB, even if the resident memory size is just 25MB. Similar values may be reported for netdata plugins too.
418
+For example, it may be reported to be 150+MB, even if the resident memory size is just 25MB. Similar values may be reported for Netdata plugins too.
419
420
-Check this for example: A netdata installation with default settings on Ubuntu 16.04LTS. The top chart is **real memory used**, while the bottom one is **virtual memory**:
420
+Check this for example: A Netdata installation with default settings on Ubuntu 16.04LTS. The top chart is **real memory used**, while the bottom one is **virtual memory**:
421
422
423
@@ -431,19 +431,18 @@ number of threads running.
431
The system does this for speed. Having a separate memory arena for each thread, allows the
432
threads to run in parallel in multi-core systems, without any locks between them.
433
434
-This behaviour is system specific. For example, the chart above when running netdata on alpine
435
-linux (that uses **musl** instead of **glibc**) is this:
434
+This behaviour is system specific. For example, the chart above when running Netdata on Alpine Linux (that uses **musl** instead of **glibc**) is this:
435
436
437
438
**Can we do anything to lower it?**
439
441
-Since netdata already uses minimal memory allocations while it runs (i.e. it adapts its memory on start, so that while repeatedly collects data it does not do memory allocations), it already instructs the system memory allocator to minimize the memory arenas for each thread. We have also added [2 configuration options](https://github.com/netdata/netdata/blob/5645b1ee35248d94e6931b64a8688f7f0d865ec6/src/main.c#L410-L418)
440
+Since Netdata already uses minimal memory allocations while it runs (i.e. it adapts its memory on start, so that while repeatedly collects data it does not do memory allocations), it already instructs the system memory allocator to minimize the memory arenas for each thread. We have also added [2 configuration options](https://github.com/netdata/netdata/blob/5645b1ee35248d94e6931b64a8688f7f0d865ec6/src/main.c#L410-L418)
441
to allow you tweak these settings: `glibc malloc arena max for plugins` and `glibc malloc arena max for netdata`.
442
443
However, even if we instructed the memory allocator to use just one arena, it seems it allocates an arena per thread.
444
446
-netdata also supports `jemalloc` and `tcmalloc`, however both behave exactly the same to the glibc memory allocator in this aspect.
445
+Netdata also supports `jemalloc` and `tcmalloc`, however both behave exactly the same to the glibc memory allocator in this aspect.
446
447
**Is this a problem?**
448
@@ -452,53 +451,53 @@ No, it is not.
451
Linux reserves real memory (physical RAM) in pages (on x86 machines pages are 4KB each).
452
So even if the system memory allocator is allocating huge amounts of virtual memory,
453
only the 4KB pages that are actually used are reserving physical RAM. The **real memory** chart
455
-on netdata application section, shows the amount of physical memory these pages occupy(it
454
+on Netdata application section, shows the amount of physical memory these pages occupy(it
455
accounts the whole pages, even if parts of them are actually used).
456
457
458
## Debugging
459
461
-When you compile netdata with debugging:
460
+When you compile Netdata with debugging:
461
463
-1. compiler optimizations for your CPU are disabled (netdata will run somewhat slower)
462
+1. compiler optimizations for your CPU are disabled (Netdata will run somewhat slower)
463
465
-2. a lot of code is added all over netdata, to log debug messages to `/var/log/netdata/debug.log`. However, nothing is printed by default. netdata allows you to select which sections of netdata you want to trace. Tracing is activated via the config option `debug flags`. It accepts a hex number, to enable or disable specific sections. You can find the options supported at [log.h](../libnetdata/log/log.h). They are the `D_*` defines. The value `0xffffffffffffffff` will enable all possible debug flags.
464
+2. a lot of code is added all over netdata, to log debug messages to `/var/log/netdata/debug.log`. However, nothing is printed by default. Netdata allows you to select which sections of Netdata you want to trace. Tracing is activated via the config option `debug flags`. It accepts a hex number, to enable or disable specific sections. You can find the options supported at [log.h](../libnetdata/log/log.h). They are the `D_*` defines. The value `0xffffffffffffffff` will enable all possible debug flags.
465
467
-Once netdata is compiled with debugging and tracing is enabled for a few sections, the file `/var/log/netdata/debug.log` will contain the messages.
466
+Once Netdata is compiled with debugging and tracing is enabled for a few sections, the file `/var/log/netdata/debug.log` will contain the messages.
467
468
> Do not forget to disable tracing (`debug flags = 0`) when you are done tracing. The file `debug.log` can grow too fast.
469
471
-#### compiling netdata with debugging
470
+#### compiling Netdata with debugging
471
473
-To compile netdata with debugging, use this:
472
+To compile Netdata with debugging, use this:
473
474
```sh
476
-# step into the netdata source directory
475
+# step into the Netdata source directory
476
cd /usr/src/netdata.git
477
478
# run the installer with debugging enabled
479
CFLAGS="-O1 -ggdb -DNETDATA_INTERNAL_CHECKS=1" ./netdata-installer.sh
480
```
481
483
-The above will compile and install netdata with debugging info embedded. You can now use `debug flags` to set the section(s) you need to trace.
482
+The above will compile and install Netdata with debugging info embedded. You can now use `debug flags` to set the section(s) you need to trace.
483
484
#### debugging crashes
485
487
-We have made the most to make netdata crash free. If however, netdata crashes on your system, it would be very helpful to provide stack traces of the crash. Without them, is will be almost impossible to find the issue (the code base is quite large to find such an issue by just objerving it).
486
+We have made the most to make Netdata crash free. If however, Netdata crashes on your system, it would be very helpful to provide stack traces of the crash. Without them, is will be almost impossible to find the issue (the code base is quite large to find such an issue by just objerving it).
487
489
-To provide stack traces, **you need to have netdata compiled with debugging**. There is no need to enable any tracing (`debug flags`).
488
+To provide stack traces, **you need to have Netdata compiled with debugging**. There is no need to enable any tracing (`debug flags`).
489
490
Then you need to be in one of the following 2 cases:
491
493
-1. netdata crashes and you have a core dump
492
+1. Netdata crashes and you have a core dump
493
494
2. you can reproduce the crash
495
496
If you are not on these cases, you need to find a way to be (i.e. if your system does not produce core dumps, check your distro documentation to enable them).
497
499
-#### netdata crashes and you have a core dump
498
+#### Netdata crashes and you have a core dump
499
501
-> you need to have netdata compiled with debugging info for this to work (check above)
500
+> you need to have Netdata compiled with debugging info for this to work (check above)
501
502
Run the following command and post the output on a github issue.
503
@@ -506,9 +505,9 @@ Run the following command and post the output on a github issue.
505
gdb $(which netdata) /path/to/core/dump
506
```
507
509
-#### you can reproduce a netdata crash on your system
508
+#### you can reproduce a Netdata crash on your system
509
511
-> you need to have netdata compiled with debugging info for this to work (check above)
510
+> you need to have Netdata compiled with debugging info for this to work (check above)
511
512
Install the package `valgrind` and run:
513
@@ -516,7 +515,7 @@ Install the package `valgrind` and run:
515
valgrind $(which netdata) -D
516
```
517
519
-netdata will start and it will be a lot slower. Now reproduce the crash and `valgrind` will dump on your console the stack trace. Open a new github issue and post the output.
518
+Netdata will start and it will be a lot slower. Now reproduce the crash and `valgrind` will dump on your console the stack trace. Open a new github issue and post the output.
519
520
521
[]()
daemon/config/README.md
+19
-19
@@ -8,21 +8,21 @@ This config file **is not needed by default**. Netdata works fine out of the box
8
9
`netdata.conf` has sections stated with `[section]`. You will see the following sections:
10
11
-1. `[global]` to [configure](#global-section-options) the [netdata daemon](../).
11
+1. `[global]` to [configure](#global-section-options) the [Netdata daemon](../).
12
2. `[web]` to [configure the web server](../../web/server).
13
3. `[plugins]` to [configure](#plugins-section-options) which [collectors](../../collectors) to use and PATH settings.
14
4. `[health]` to [configure](#health-section-options) general settings for [health monitoring](../../health)
15
-5. `[registry]` for the [netdata registry](../../registry).
15
+5. `[registry]` for the [Netdata registry](../../registry).
16
6. `[backend]` to set up [streaming and replication](../../streaming) options.
17
7. `[statsd]` for the general settings of the [stats.d.plugin](../../collectors/statsd.plugin).
18
8. `[plugin:NAME]` sections for each collector plugin, under the comment [Per plugin configuration](#per-plugin-configuration).
19
9. `[CHART_NAME]` sections for each chart defined, under the comment [Per chart configuration](#per-chart-configuration).
20
21
-The configuration file is a `name = value` dictionary. Netdata will not complain if you set options unknown to it. When you check the running configuration by accessing the URL `/netdata.conf` on your netdata server, netdata will add a comment on settings it does not currently use.
21
+The configuration file is a `name = value` dictionary. Netdata will not complain if you set options unknown to it. When you check the running configuration by accessing the URL `/netdata.conf` on your Netdata server, Netdata will add a comment on settings it does not currently use.
22
23
## Applying changes
24
25
-After `netdata.conf` has been modified, netdata needs to be restarted for changes to apply:
25
+After `netdata.conf` has been modified, Netdata needs to be restarted for changes to apply:
26
27
```bash
28
sudo service netdata restart
@@ -42,36 +42,36 @@ Please note that your data history will be lost if you have modified `history` p
42
43
setting | default | info
44
:------:|:-------:|:----
45
-process scheduling policy | `keep` | See [netdata process scheduling policy](../#netdata-process-scheduling-policy)
45
+process scheduling policy | `keep` | See [Netdata process scheduling policy](../#netdata-process-scheduling-policy)
46
OOM score | `1000` | See [OOM score](../#oom-score)
47
glibc malloc arena max for plugins | `1` | See [Virtual memory](../#virtual-memory).
48
-glibc malloc arena max for netdata | `1` | See [Virtual memory](../#virtual-memory).
49
-hostname | auto-detected | The hostname of the computer running netdata.
50
-history | `3996` | The number of entries the netdata daemon will by default keep in memory for each chart dimension. This setting can also be configured per chart. Check [Memory Requirements](../../database/#database) for more information.
48
+glibc malloc arena max for Netdata | `1` | See [Virtual memory](../#virtual-memory).
49
+hostname | auto-detected | The hostname of the computer running Netdata.
50
+history | `3996` | The number of entries the `netdata` daemon will by default keep in memory for each chart dimension. This setting can also be configured per chart. Check [Memory Requirements](../../database/#database) for more information.
51
update every | `1` | The frequency in seconds, for data collection. For more information see [Performance](../../docs/Performance.md#performance).
52
config directory | `/etc/netdata` | The directory configuration files are kept.
53
stock config directory | `/usr/lib/netdata/conf.d` |
54
log directory | `/var/log/netdata` | The directory in which the [log files](../#log-files) are kept.
55
web files directory | `/usr/share/netdata/web` | The directory the web static files are kept.
56
-cache directory | `/var/cache/netdata` | The directory the memory database will be stored if and when netdata exits. Netdata will re-read the database when it will start again, to continue from the same point.
57
-lib directory | `/var/lib/netdata` | Contains the alarm log and the netdata instance guid.
56
+cache directory | `/var/cache/netdata` | The directory the memory database will be stored if and when Netdata exits. Netdata will re-read the database when it will start again, to continue from the same point.
57
+lib directory | `/var/lib/netdata` | Contains the alarm log and the Netdata instance guid.
58
home directory | `/var/cache/netdata` | Contains the db files for the collected metrics
59
plugins directory | `"/usr/libexec/netdata/plugins.d" "/etc/netdata/custom-plugins.d"` | The directory plugin programs are kept. This setting supports multiple directories, space separated. If any directory path contains spaces, enclose it in single or double quotes.
60
-memory mode | `save` | When set to `save` netdata will save its round robin database on exit and load it on startup. When set to `map` the cache files will be updated in real time (check `man mmap` - do not set this on systems with heavy load or slow disks - the disks will continuously sync the in-memory database of netdata). When set to `dbengine` it behaves similarly to `map` but with much better disk and memory efficiency, however, with higher overhead. When set to `ram` the round robin database will be temporary and it will be lost when netdata exits. `none` disables the database at this host. This also disables health monitoring (there cannot be health monitoring without a database). host access prefix | | This is used in docker environments where /proc, /sys, etc have to be accessed via another path. You may also have to set SYS_PTRACE capability on the docker for this work. Check [issue 43](https://github.com/netdata/netdata/issues/43).
61
-memory deduplication (ksm) | `yes` | When set to `yes`, netdata will offer its in-memory round robin database to kernel same page merging (KSM) for deduplication. For more information check [Memory Deduplication - Kernel Same Page Merging - KSM](../../database/#ksm)
60
+memory mode | `save` | When set to `save` Netdata will save its round robin database on exit and load it on startup. When set to `map` the cache files will be updated in real time (check `man mmap` - do not set this on systems with heavy load or slow disks - the disks will continuously sync the in-memory database of Netdata). When set to `dbengine` it behaves similarly to `map` but with much better disk and memory efficiency, however, with higher overhead. When set to `ram` the round robin database will be temporary and it will be lost when Netdata exits. `none` disables the database at this host. This also disables health monitoring (there cannot be health monitoring without a database). host access prefix | | This is used in docker environments where /proc, /sys, etc have to be accessed via another path. You may also have to set SYS_PTRACE capability on the docker for this work. Check [issue 43](https://github.com/netdata/netdata/issues/43).
61
+memory deduplication (ksm) | `yes` | When set to `yes`, Netdata will offer its in-memory round robin database to kernel same page merging (KSM) for deduplication. For more information check [Memory Deduplication - Kernel Same Page Merging - KSM](../../database/#ksm)
62
TZ environment variable | `:/etc/localtime` | Where to find the timezone
63
timezone | auto-detected | The timezone retrieved from the environment variable
64
debug flags | `0x0000000000000000` | Bitmap of debug options to enable. For more information check [Tracing Options](../#debugging).
65
debug log | `/var/log/netdata/debug.log` | The filename to save debug information. This file will not be created if debugging is not enabled. You can also set it to `syslog` to send the debug messages to syslog, or `none` to disable this log. For more information check [Tracing Options](../#debugging).
66
-error log | `/var/log/netdata/error.log` | The filename to save error messages for netdata daemon and all plugins (`stderr` is sent here for all netdata programs, including the plugins). You can also set it to `syslog` to send the errors to syslog, or `none` to disable this log.
67
-access log | `/var/log/netdata/access.log` | The filename to save the log of web clients accessing netdata charts. You can also set it to `syslog` to send the access log to syslog, or `none` to disable this log.
66
+error log | `/var/log/netdata/error.log` | The filename to save error messages for Netdata daemon and all plugins (`stderr` is sent here for all Netdata programs, including the plugins). You can also set it to `syslog` to send the errors to syslog, or `none` to disable this log.
67
+access log | `/var/log/netdata/access.log` | The filename to save the log of web clients accessing Netdata charts. You can also set it to `syslog` to send the access log to syslog, or `none` to disable this log.
68
errors flood protection period | `1200` | UNUSED - Length of period (in sec) during which the number of errors should not exceed the `errors to trigger flood protection`.
69
errors to trigger flood protection | `200` | UNUSED - Number of errors written to the log in `errors flood protection period` sec before flood protection is activated.
70
-run as user | `netdata` | The user netdata will run as.
70
+run as user | `netdata` | The user Netdata will run as.
71
pthread stack size | auto-detected |
72
cleanup obsolete charts after seconds | `3600` | See [monitoring ephemeral containers](../../collectors/cgroups.plugin/#monitoring-ephemeral-containers), also sets the timeout for cleaning up obsolete dimensions
73
gap when lost iterations above | `1` |
74
-cleanup orphan hosts after seconds | `3600` | How long to wait until automatically removing from the DB a remote netdata host (slave) that is no longer sending data.
74
+cleanup orphan hosts after seconds | `3600` | How long to wait until automatically removing from the DB a remote Netdata host (slave) that is no longer sending data.
75
delete obsolete charts files | `yes` | See [monitoring ephemeral containers](../../collectors/cgroups.plugin/#monitoring-ephemeral-containers), also affects the deletion of files for obsolete dimensions
76
delete orphan hosts files | `yes` | Set to `no` to disable non-responsive host removal.
77
enable zero metrics | `no` | Set to `yes` to show charts when all their metrics are zero.
@@ -90,8 +90,8 @@ setting | default | info
90
:------:|:-------:|:----
91
PATH environment variable | `auto-detected` |
92
PYTHONPATH environment variable | | Used to set a custom python path
93
-enable running new plugins | `yes` | When set to `yes`, netdata will enable detected plugins, even if they are not configured explicitly. Setting this to `no` will only enable plugins explicitly configirued in this file with a `yes`
94
-check for new plugins every | 60 | The time in seconds to check for new plugins in the plugins directory. This allows having other applications dynamically creating plugins for netdata.
93
+enable running new plugins | `yes` | When set to `yes`, Netdata will enable detected plugins, even if they are not configured explicitly. Setting this to `no` will only enable plugins explicitly configirued in this file with a `yes`
94
+check for new plugins every | 60 | The time in seconds to check for new plugins in the plugins directory. This allows having other applications dynamically creating plugins for Netdata.
95
checks | `no` | This is a debugging plugin for the internal latency
96
97
### [health] section options
@@ -129,7 +129,7 @@ The configuration options for plugins appear in sections following the pattern `
129
130
Most internal plugins will provide additional options. Check [Internal Plugins](../../collectors/) for more information.
131
132
-Please note, that by default Netdata will enable monitoring metrics for disks, memory, and network only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Use `yes` instead of `auto` in plugin configuration sections to enable these charts permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
132
+Please note, that by default Netdata will enable monitoring metrics for disks, memory, and network only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Use `yes` instead of `auto` in plugin configuration sections to enable these charts permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
133
134
#### External plugins
135
database/README.md
+23
-23
@@ -3,7 +3,7 @@
3
Although `netdata` does all its calculations using `long double`, it stores all values using
4
a [custom-made 32-bit number](../libnetdata/storage_number/).
5
6
-So, for each dimension of a chart, netdata will need: `4 bytes for the value * the entries
6
+So, for each dimension of a chart, Netdata will need: `4 bytes for the value * the entries
7
of its history`. It will not store any other data for each value in the time series database.
8
Since all its values are stored in a time series with fixed step, the time each value
9
corresponds can be calculated at run time, using the position of a value in the round robin database.
@@ -23,22 +23,22 @@ use the **[Database Engine](engine/)**.
23
24
## Memory modes
25
26
-Currently netdata supports 6 memory modes:
26
+Currently Netdata supports 6 memory modes:
27
28
1. `ram`, data are purely in memory. Data are never saved on disk. This mode uses `mmap()` and
29
supports [KSM](#ksm).
30
31
-2. `save`, (the default) data are only in RAM while netdata runs and are saved to / loaded from
32
- disk on netdata restart. It also uses `mmap()` and supports [KSM](#ksm).
31
+2. `save`, (the default) data are only in RAM while Netdata runs and are saved to / loaded from
32
+ disk on Netdata restart. It also uses `mmap()` and supports [KSM](#ksm).
33
34
3. `map`, data are in memory mapped files. This works like the swap. Keep in mind though, this
35
- will have a constant write on your disk. When netdata writes data on its memory, the Linux kernel
35
+ will have a constant write on your disk. When Netdata writes data on its memory, the Linux kernel
36
marks the related memory pages as dirty and automatically starts updating them on disk.
37
Unfortunately we cannot control how frequently this works. The Linux kernel uses exactly the
38
same algorithm it uses for its swap memory. Check below for additional information on running a
39
- dedicated central netdata server. This mode uses `mmap()` but does not support [KSM](#ksm).
39
+ dedicated central Netdata server. This mode uses `mmap()` but does not support [KSM](#ksm).
40
41
-4. `none`, without a database (collected metrics can only be streamed to another netdata).
41
+4. `none`, without a database (collected metrics can only be streamed to another Netdata).
42
43
5. `alloc`, like `ram` but it uses `calloc()` and does not support [KSM](#ksm). This mode is the
44
fallback for all others except `none`.
@@ -49,7 +49,7 @@ Currently netdata supports 6 memory modes:
49
but depends on the configured disk space and the effective compression ratio of the data stored.
50
For more details see [here](engine/).
51
52
-You can select the memory mode by editing netdata.conf and setting:
52
+You can select the memory mode by editing `netdata.conf` and setting:
53
54
```
55
[global]
@@ -60,7 +60,7 @@ You can select the memory mode by editing netdata.conf and setting:
60
cache directory = /var/cache/netdata
61
```
62
63
-## Running netdata in embedded devices
63
+## Running Netdata in embedded devices
64
65
Embedded devices usually have very limited RAM resources available.
66
@@ -74,36 +74,36 @@ second updates.
74
75
If you set `update every = 2` and `history = 1800`, you will still have an hour of data, but
76
collected once every 2 seconds. This will **cut in half** both CPU and RAM resources consumed
77
-by netdata. Of course experiment a bit. On very weak devices you might have to use
77
+by Netdata. Of course experiment a bit. On very weak devices you might have to use
78
`update every = 5` and `history = 720` (still 1 hour of data, but 1/5 of the CPU and RAM resources).
79
80
You can also disable [data collection plugins](../collectors) you don't need.
81
Disabling such plugins will also free both CPU and RAM resources.
82
83
-## Running a dedicated central netdata server
83
+## Running a dedicated central Netdata server
84
85
-Netdata allows streaming data between netdata nodes. This allows us to have a central netdata
85
+Netdata allows streaming data between Netdata nodes. This allows us to have a central Netdata
86
server that will maintain the entire database for all nodes, and will also run health checks/alarms
87
for all nodes.
88
89
-For this central netdata, memory size can be a problem. Fortunately, netdata supports several
89
+For this central Netdata, memory size can be a problem. Fortunately, Netdata supports several
90
memory modes. **One interesting option** for this setup is `memory mode = map`.
91
92
### map
93
94
-In this mode, the database of netdata is stored in memory mapped files. netdata continues to read
94
+In this mode, the database of Netdata is stored in memory mapped files. Netdata continues to read
95
and write the database in memory, but the kernel automatically loads and saves memory pages from/to
96
disk.
97
98
**We suggest _not_ to use this mode on nodes that run other applications.** There will always be
99
dirty memory to be synced and this syncing process may influence the way other applications work.
100
-This mode however is useful when we need a central netdata server that would normally need huge
100
+This mode however is useful when we need a central Netdata server that would normally need huge
101
amounts of memory. Using memory mode `map` we can overcome all memory restrictions.
102
103
There are a few kernel options that provide finer control on the way this syncing works. But before
104
-explaining them, a brief introduction of how netdata database works is needed.
104
+explaining them, a brief introduction of how Netdata database works is needed.
105
106
-For each chart, netdata maps the following files:
106
+For each chart, Netdata maps the following files:
107
108
1. `chart/main.db`, this is the file that maintains chart information. Every time data are collected
109
for a chart, this is updated.
@@ -111,7 +111,7 @@ For each chart, netdata maps the following files:
111
2. `chart/dimension_name.db`, this is the file for each dimension. At its beginning there is a
112
header, followed by the round robin database where metrics are stored.
113
114
-So, every time netdata collects data, the following pages will become dirty:
114
+So, every time Netdata collects data, the following pages will become dirty:
115
116
1. the chart file
117
2. the header part of all dimension files
@@ -147,8 +147,8 @@ There are 2 more options to tweak:
147
2. `dirty_ratio`, by default `20`.
148
149
These control the amount of memory that should be dirty for disk syncing to be triggered.
150
-On dedicated netdata servers, you can use: `80` and `90` respectively, so that all RAM is given
151
-to netdata.
150
+On dedicated Netdata servers, you can use: `80` and `90` respectively, so that all RAM is given
151
+to Netdata.
152
153
With these settings, you can expect a little `iowait` spike once every 10 minutes and in case
154
of system crash, data on disk will be up to 10 minutes old.
@@ -169,7 +169,7 @@ for this setup** is `memory mode = dbengine`.
169
170
### dbengine
171
172
-In this mode, the database of netdata is stored in database files. The [Database Engine](engine/)
172
+In this mode, the database of Netdata is stored in database files. The [Database Engine](engine/)
173
works like a traditional database. There is some amount of RAM dedicated to data caching and
174
indexing and the rest of the data reside compressed on disk. The number of history entries is not
175
fixed in this case, but depends on the configured disk space and the effective compression ratio
@@ -187,10 +187,10 @@ Netdata offers all its round robin database to kernel for deduplication
187
188
In the past KSM has been criticized for consuming a lot of CPU resources.
189
Although this is true when KSM is used for deduplicating certain applications, it is not true with
190
-netdata, since the netdata memory is written very infrequently (if you have 24 hours of metrics in
190
+netdata, since the Netdata memory is written very infrequently (if you have 24 hours of metrics in
191
netdata, each byte at the in-memory database will be updated just once per day).
192
193
-KSM is a solution that will provide 60+% memory savings to netdata.
193
+KSM is a solution that will provide 60+% memory savings to Netdata.
194
195
### Enable KSM in kernel
196
database/engine/README.md
+9
-9
@@ -23,13 +23,13 @@ journalfile-1-0000000003.njf
23
They are located under their host's cache directory in the directory `./dbengine`
24
(e.g. for localhost the default location is `/var/cache/netdata/dbengine/*`). The higher
25
numbered filenames contain more recent metric data. The user can safely delete some pairs
26
-of files when netdata is stopped to manually free up some space.
26
+of files when Netdata is stopped to manually free up some space.
27
28
*Users should* **back up** *their `./dbengine` folders if they consider this data to be important.*
29
30
## Configuration
31
32
-There is one DB engine instance per netdata host/node. That is, there is one `./dbengine` folder
32
+There is one DB engine instance per Netdata host/node. That is, there is one `./dbengine` folder
33
per node, and all charts of `dbengine` memory mode in such a host share the same storage space
34
and DB engine instance memory state. You can select the memory mode for localhost by editing
35
netdata.conf and setting:
@@ -59,10 +59,10 @@ quota. Both numbers are in **MiB**. All DB engine instances will allocate the co
59
separately.
60
61
The `page cache size` option determines the amount of RAM in **MiB** that is dedicated to caching
62
-netdata metric values themselves.
62
+Netdata metric values themselves.
63
64
The `dbengine disk space` option determines the amount of disk space in **MiB** that is dedicated
65
-to storing netdata metric values and all related metadata describing them.
65
+to storing Netdata metric values and all related metadata describing them.
66
67
## Operation
68
@@ -72,7 +72,7 @@ the **Page Cache**.
72
73
When those pages fill up they are slowly compressed and flushed to disk.
74
It can take `4096 / 4 = 1024 seconds = 17 minutes`, for a chart dimension that is being collected
75
-every 1 second, to fill a page. Pages can be cut short when we stop netdata or the DB engine
75
+every 1 second, to fill a page. Pages can be cut short when we stop Netdata or the DB engine
76
instance so as to not lose the data. When we query the DB engine for data we trigger disk read
77
I/O requests that fill the Page Cache with the requested pages and potentially evict cold
78
(not recently used) pages.
@@ -91,7 +91,7 @@ applications.
91
Using memory mode `dbengine` we can overcome most memory restrictions and store a dataset that
92
is much larger than the available memory.
93
94
-There are explicit memory requirements **per** DB engine **instance**, meaning **per** netdata
94
+There are explicit memory requirements **per** DB engine **instance**, meaning **per** Netdata
95
**node** (e.g. localhost and streaming recipient nodes):
96
97
- `page cache size` must be at least `#dimensions-being-collected x 4096 x 2` bytes.
@@ -115,11 +115,11 @@ file descriptors available per `dbengine` instance.
115
Netdata allocates 25% of the available file descriptors to its Database Engine instances. This means that only 25%
116
of the file descriptors that are available to the Netdata service are accessible by dbengine instances.
117
You should take that into account when configuring your service
118
-or system-wide file descriptor limits. You can roughly estimate that the netdata service needs 2048 file
118
+or system-wide file descriptor limits. You can roughly estimate that the Netdata service needs 2048 file
119
descriptors for every 10 streaming slave hosts when streaming is configured to use `memory mode = dbengine`.
120
121
-If for example one wants to allocate 65536 file descriptors to the netdata service on a systemd system
122
-one needs to override the netdata service by running `sudo systemctl edit netdata` and creating a
121
+If for example one wants to allocate 65536 file descriptors to the Netdata service on a systemd system
122
+one needs to override the Netdata service by running `sudo systemctl edit netdata` and creating a
123
file with contents:
124
125
```
docs/Add-more-charts-to-netdata.md
+6
-6
@@ -187,7 +187,7 @@ rethinkdb|python<br/>v2 or v3|Connects to multiple rethinkdb servers (local or r
187
188
application|language|notes|
189
:---------:|:------:|:----|
190
-retroshare|python<br/>v2 or v3|Connects to multiple retroshare servers (local or remote) to collect real-time performance metrics.<br/> <br/>netdata plugin: [python.d.plugin](../collectors/python.d.plugin)<br/>plugin module: [retroshare.chart.py](../collectors/python.d.plugin/retroshare)<br/>configuration file: [python.d/retroshare.conf](../collectors/python.d.plugin/retroshare)|
190
+retroshare|python<br/>v2 or v3|Connects to multiple retroshare servers (local or remote) to collect real-time performance metrics.<br/> <br/>Netdata plugin: [python.d.plugin](../collectors/python.d.plugin)<br/>plugin module: [retroshare.chart.py](../collectors/python.d.plugin/retroshare)<br/>configuration file: [python.d/retroshare.conf](../collectors/python.d.plugin/retroshare)|
191
192
193
---
@@ -196,7 +196,7 @@ retroshare|python<br/>v2 or v3|Connects to multiple retroshare servers (local or
196
197
application|language|notes|
198
:---------:|:------:|:----|
199
-squid|python<br/>v2 or v3|Connects to multiple squid servers (local or remote) to collect real-time performance metrics.<br/> <br/>netdata plugin: [python.d.plugin](../collectors/python.d.plugin)<br/>plugin module: [squid.chart.py](../collectors/python.d.plugin/squid)<br/>configuration file: [python.d/squid.conf](../collectors/python.d.plugin/squid)|
199
+squid|python<br/>v2 or v3|Connects to multiple squid servers (local or remote) to collect real-time performance metrics.<br/> <br/>Netdata plugin: [python.d.plugin](../collectors/python.d.plugin)<br/>plugin module: [squid.chart.py](../collectors/python.d.plugin/squid)<br/>configuration file: [python.d/squid.conf](../collectors/python.d.plugin/squid)|
200
squid|BASH<br/>Shell Script|Connects to a squid server (local or remote) to collect real-time performance metrics.<br/><br/>DEPRECATED IN FAVOR OF THE PYTHON ONE. It is still supplied only as an example module to shell scripting plugins.<br/> <br/>Netdata plugin: [charts.d.plugin](../collectors/charts.d.plugin#chartsdplugin)<br/>plugin module: [squid.chart.sh](../collectors/charts.d.plugin/squid)<br/>configuration file: [charts.d/squid.conf](../collectors/charts.d.plugin/squid)|
201
202
@@ -298,8 +298,8 @@ postfix|BASH<br/>Shell Script|Charts the postfix queue size.<br/><br/>DEPRECATED
298
application|language|notes|
299
:---------:|:------:|:----|
300
NFS Client|`C`|This is handled entirely by the Netdata daemon.<br/> <br/>Configuration: `netdata.conf`, section `[plugin:proc:/proc/net/rpc/nfs]`.
301
-NFS Server|`C`|This is handled entirely by the netdata daemon.<br/> <br/>Configuration: `netdata.conf`, section `[plugin:proc:/proc/net/rpc/nfsd]`.
302
-samba|python<br/>v2 or v3|Performance metrics of Samba SMB2 file sharing.<br/> <br/>documentation page: [python.d.plugin module samba](../collectors/python.d.plugin/samba)<br/>netdata plugin: [python.d.plugin](../collectors/python.d.plugin)<br/>plugin module: [samba.chart.py](../collectors/python.d.plugin/samba)<br/>configuration file: [python.d/samba.conf](../collectors/python.d.plugin/samba)|
301
+NFS Server|`C`|This is handled entirely by the `netdata` daemon.<br/> <br/>Configuration: `netdata.conf`, section `[plugin:proc:/proc/net/rpc/nfsd]`.
302
+samba|python<br/>v2 or v3|Performance metrics of Samba SMB2 file sharing.<br/> <br/>documentation page: [python.d.plugin module samba](../collectors/python.d.plugin/samba)<br/>Netdata plugin: [python.d.plugin](../collectors/python.d.plugin)<br/>plugin module: [samba.chart.py](../collectors/python.d.plugin/samba)<br/>configuration file: [python.d/samba.conf](../collectors/python.d.plugin/samba)|
303
304
---
305
@@ -307,7 +307,7 @@ samba|python<br/>v2 or v3|Performance metrics of Samba SMB2 file sharing.<br/>&n
307
308
application|language|notes|
309
:---------:|:------:|:----|
310
-CUPS|C|Charts metrics of printers, jobs and other cups destinations.<br/> <br/>netdata plugin: [cups.plugin](../collectors/cups.plugin)
310
+CUPS|C|Charts metrics of printers, jobs and other cups destinations.<br/> <br/>Netdata plugin: [cups.plugin](../collectors/cups.plugin)
311
312
---
313
@@ -315,7 +315,7 @@ CUPS|C|Charts metrics of printers, jobs and other cups destinations.<br/> <
315
316
application|language|notes|
317
:---------:|:------:|:----|
318
-xenstat|C|Collects host and domain statistics for XenServer or XCP-ng hypervisors.<br/> <br/>netdata plugin: [xenstat.plugin](../collectors/xenstat.plugin)
318
+xenstat|C|Collects host and domain statistics for XenServer or XCP-ng hypervisors.<br/> <br/>Netdata plugin: [xenstat.plugin](../collectors/xenstat.plugin)
319
320
---
321
docs/GettingStarted.md
+2
-2
@@ -32,9 +32,9 @@ If still Netdata does not receive the requests, something is blocking them. A fi
32
33
</details> <br/>
34
35
-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.
35
+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.
36
37
-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:
37
+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:
38
39
- the current charts panning (drag the charts left or right),
40
- the current charts zooming (`SHIFT` + mouse wheel over a chart),
docs/Running-behind-nginx.md
+1
-1
@@ -14,7 +14,7 @@ The software is known for its low impact on memory resources, high scalability,
14
15
- Password-protect access to Netdata, until distributed authentication is implemented via the Netdata cloud Sign In mechanism.
16
17
-- A proxy was necessary to encrypt the communication to netdata, until v1.16.0, which provided TLS (HTTPS) support.
17
+- A proxy was necessary to encrypt the communication to Netdata, until v1.16.0, which provided TLS (HTTPS) support.
18
19
## Nginx configuration file
20
docs/anonymous-statistics.md
+2
-2
@@ -26,7 +26,7 @@ To ensure anonymity of the stored information, we have configured GTM's GA varia
26
|page|netdata-dashboard
27
|hostname|dashboard.my-netdata.io
28
|anonymizeIp|true
29
-|title|netdata dashboard
29
+|title|Netdata dashboard
30
|campaignSource|{{machine_guid}}
31
|campaignMedium|web
32
|referrer|http://dashboard.my-netdata.io
@@ -35,7 +35,7 @@ To ensure anonymity of the stored information, we have configured GTM's GA varia
35
|Page Path|/netdata-dashboard
36
|location|http://dashboard.my-netdata.io
37
38
-In addition, the netdata-generated unique machine guid is sent to GA via a custom dimension.
38
+In addition, the Netdata-generated unique machine guid is sent to GA via a custom dimension.
39
You can verify the effect of these settings by examining the GA `collect` request parameters.
40
41
The only thing that's impossible for us to prevent from being **sent** is the URL in the "Referrer" Header of the browser request to GA. However, the settings above ensure that all **stored** URLs and host names are anonymized.
docs/configuration-guide.md
+4
-4
@@ -59,7 +59,7 @@ Entire plugins can be turned off from the [netdata.conf [plugins]](../daemon/con
59
60
##### Show charts with zero metrics
61
62
-By default, Netdata will enable monitoring metrics for disks, memory, and network only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Use `yes` instead of `auto` in plugin configuration sections to enable these charts permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
62
+By default, Netdata will enable monitoring metrics for disks, memory, and network only when they are not zero. If they are constantly zero they are ignored. Metrics that will start having values, after Netdata is started, will be detected and charts will be automatically added to the dashboard (a refresh of the dashboard is needed for them to appear though). Use `yes` instead of `auto` in plugin configuration sections to enable these charts permanently. You can also set the `enable zero metrics` option to `yes` in the `[global]` section which enables charts with zero metrics for all internal Netdata plugins.
63
64
### Modify alarms and notifications
65
@@ -92,11 +92,11 @@ You have several options under the [netdata.conf [web]](../web/server/#access-li
92
93
##### Stop sending info to registry.my-netdata.io
94
95
-You will need to configure the [registry] section in netdata.conf. First read the [registry documentation](../registry/). In it, are instructions on how to [run your own registry](../registry/#run-your-own-registry).
95
+You will need to configure the [registry] section in `netdata.conf`. First read the [registry documentation](../registry/). In it, are instructions on how to [run your own registry](../registry/#run-your-own-registry).
96
97
##### Change the IP address/port Netdata listens to
98
99
-The settings are under netdata.conf [web]. Look at the [web server documentation](../web/server/#binding-netdata-to-multiple-ports) for more info.
99
+The settings are under `netdata.conf` [web]. Look at the [web server documentation](../web/server/#binding-netdata-to-multiple-ports) for more info.
100
101
### System resource usage
102
@@ -110,7 +110,7 @@ The page on [Netdata performance](Performance.md) has an excellent guide on how
110
111
##### Prevent Netdata from getting immediately killed when my server runs out of memory
112
113
-You can change the Netdata [OOM score](../daemon/#oom-score) in netdata.conf [global].
113
+You can change the Netdata [OOM score](../daemon/#oom-score) in `netdata.conf` [global].
114
115
### Other
116
docs/netdata-security.md
+1
-1
@@ -132,7 +132,7 @@ iptables -t filter -A netdata -j DROP
132
iptables -t filter -D INPUT -p tcp --dport ${NETDATA_PORT} -m conntrack --ctstate NEW -j netdata 2>/dev/null
133
134
# add the input chain hook (again)
135
-# to send all new netdata connections to our filtering chain
135
+# to send all new Netdata connections to our filtering chain
136
iptables -t filter -I INPUT -p tcp --dport ${NETDATA_PORT} -m conntrack --ctstate NEW -j netdata
137
```
138
_script to allow access to Netdata only from a number of hosts_
docs/privacy-policy.md
+6
-6
@@ -37,22 +37,22 @@ The menu lists the Netdata servers you have visited. For example, when you jump
37
(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
38
same view. The global 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 call this **machine_guid**)
40
+1. **machines**: i.e. the Netdata installations (a random GUID generated by each Netdata the first time it starts; we call this **machine_guid**)
41
42
- For each netdata installation (each `machine_guid`) the registry keeps track of the different URLs it is accessed.
42
+ For each Netdata installation (each `machine_guid`) the registry keeps track of the different URLs it is accessed.
43
44
-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**)
44
+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**)
45
46
- For each person, the registry keeps track of the netdata installations it has accessed and their URLs.
46
+ For each person, the registry keeps track of the Netdata installations it has accessed and their URLs.
47
48
-3. **URLs** of netdata installations (as seen by the web browsers)
48
+3. **URLs** of Netdata installations (as seen by the web browsers)
49
50
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.
51
52
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.
53
54
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).
55
-*machines*, *persons*, and timestamps are stored in the netdata registry regardless of whether you sign in or not.
55
+*machines*, *persons*, and timestamps are stored in the Netdata registry regardless of whether you sign in or not.
56
57
If sending this information is against your policies, you can [run your own registry](../registry/#run-your-own-registry).
58
Note that ND versions with the 'Sign in' feature of the ND Cloud do not use the global registry.
health/README.md
+23
-25
@@ -1,9 +1,9 @@
1
# Health monitoring
2
3
-Each netdata node runs an independent thread evaluating health monitoring checks.
3
+Each Netdata node runs an independent thread evaluating health monitoring checks.
4
This thread has lock free access to the database, so that it can operate as a watchdog.
5
6
-Health checks (alarms) are attached to netdata charts, allowing netdata to automatically
6
+Health checks (alarms) are attached to Netdata charts, allowing Netdata to automatically
7
activate an alarm as soon as a chart is created. This is very important for
8
netdata, since many charts are dynamically created during runtime (for example, the
9
chart tracking network interface packet drops, is automatically created on the first
@@ -20,15 +20,15 @@ use expressions combining the latest value of any number of metrics.
20
21
## Health configuration reference
22
23
-Stock netdata health configuration is in `/usr/lib/netdata/conf.d/health.d`.
23
+Stock Netdata health configuration is in `/usr/lib/netdata/conf.d/health.d`.
24
These files can be overwritten by copying them and editing them in `/etc/netdata/health.d`
25
(run `/etc/netdata/edit-config` to edit them).
26
27
In `/etc/netdata/health.d` you can also put any number of files (in any number of sub-directories)
28
-with a suffix `.conf` to have them processed by netdata.
28
+with a suffix `.conf` to have them processed by Netdata.
29
30
-Health configuration can be reloaded at any time, without restarting netdata.
31
-Just send netdata the SIGUSR2 signal, like this:
30
+Health configuration can be reloaded at any time, without restarting Netdata.
31
+Just send Netdata the SIGUSR2 signal, like this:
32
33
```sh
34
killall -USR2 netdata
@@ -50,7 +50,7 @@ The only difference is the label `alarm` or `template`.
50
Netdata supports overriding **templates** with **alarms**.
51
For example, when a template is defined for a set of charts, an alarm with exactly the
52
same name attached to the same chart the template matches, will have higher precedence
53
-(i.e. netdata will use the alarm on this chart and prevent the template from being applied
53
+(i.e. Netdata will use the alarm on this chart and prevent the template from being applied
54
to it).
55
56
### The format
@@ -135,7 +135,7 @@ hosts: server1 server2 database* !redis3 redis*
135
The above says: use this alarm on all hosts named `server1`, `server2`, `database*`, and
136
all `redis*` except `redis3`.
137
138
-This is useful when you centralize metrics from multiple hosts, to one netdata.
138
+This is useful when you centralize metrics from multiple hosts, to one Netdata.
139
140
---
141
@@ -187,7 +187,7 @@ Everything is the same with [badges](../web/api/badges/). In short:
187
188
- `of DIMENSIONS` is optional and has to be the last parameter. Dimensions have to be separated
189
by `,` or `|`. The space characters found in dimensions will be kept as-is (a few dimensions
190
- have spaces in their names). This accepts netdata simple patterns and the `match-ids` and
190
+ have spaces in their names). This accepts Netdata simple patterns and the `match-ids` and
191
`match-names` options affect the searches for dimensions.
192
193
The result of the lookup will be available as `$this` and `$NAME` in expressions.
@@ -289,8 +289,8 @@ Format:
289
exec: SCRIPT
290
```
291
292
-The default `SCRIPT` is netdata's `alarm-notify.sh`, which supports all the notifications
293
-methods netdata supports, including custom hooks.
292
+The default `SCRIPT` is Netdata's `alarm-notify.sh`, which supports all the notifications
293
+methods Netdata supports, including custom hooks.
294
295
---
296
@@ -373,19 +373,17 @@ For some alarms we need compare two time-frames, to detect anomalies. For exampl
373
374
### Expressions
375
376
-netdata has an internal [infix expression parser](../libnetdata/eval).
376
+Netdata has an internal [infix expression parser](../libnetdata/eval).
377
This parses expressions and creates an internal structure that allows fast execution of them.
378
379
These operators are supported `+`, `-`, `*`, `/`, `<`, `<=`, `<>`, `!=`, `>`, `>=`, `&&`, `||`,
380
`!`, `AND`, `OR`, `NOT`. Boolean operators result in either `1` (true) or `0` (false).
381
382
-The conditional evaluation operator `?` is supported too. Using this operator IF-THEN-ELSE
383
-conditional statements can be specified. The format is: `(condition) ? (true expression) :
384
-(false expression)`. So, netdata will first evaluate the `condition` and based on the result
385
-will either evaluate `true expression` or `false expression`.
382
+The conditional evaluation operator `?` is supported too. Using this operator IF-THEN-ELSE conditional statements can be specified. The format is: `(condition) ? (true expression) :(false expression)`. So, Netdata will first evaluate the `condition` and based on the result will either evaluate `true expression` or `false expression`.
383
+
384
Example: `($this > 0) ? ($avail * 2) : ($used / 2)`.
387
-Nested such expressions are also supported (i.e. `true expression` and `false expression` can
388
-contain conditional evaluations).
385
+
386
+Nested such expressions are also supported (i.e. `true expression` and `false expression` can contain conditional evaluations).
387
388
Expressions also support the `abs()` function.
389
@@ -407,7 +405,7 @@ or warning thresholds. This usage helps to avoid bogus messages resulting from
405
variations in the value when it is varying regularly but staying close to the threshold
406
value, without needing to delay sending messages at all.
407
410
-An example of such usage from the default CPU usage alarms bundled with netdata is:
408
+An example of such usage from the default CPU usage alarms bundled with Netdata is:
409
410
```
411
warn: $this > (($status >= $WARNING) ? (75) : (85))
@@ -491,7 +489,7 @@ Although the `alarm_variables` link shows you variables for a particular chart,
489
490
Alarms can have the following statuses:
491
494
- - `REMOVED` - the alarm has been deleted (this happens when a SIGUSR2 is sent to netdata
492
+ - `REMOVED` - the alarm has been deleted (this happens when a SIGUSR2 is sent to Netdata
493
to reload health configuration)
494
495
- `UNINITIALIZED` - the alarm is not initialized yet
@@ -509,7 +507,7 @@ The external script will be called for all status changes.
507
508
## Examples
509
512
-Check the `health/health.d/` directory for all alarms shipped with netdata.
510
+Check the `health/health.d/` directory for all alarms shipped with Netdata.
511
512
Here are a few examples:
513
@@ -526,7 +524,7 @@ template: apache_last_collected_secs
524
crit: $this > (10 * $update_every)
525
```
526
529
-The above checks that netdata is able to collect data from apache. In detail:
527
+The above checks that Netdata is able to collect data from apache. In detail:
528
529
```
530
template: apache_last_collected_secs
@@ -653,12 +651,12 @@ The `lookup` line will calculate the sum of the all dropped packets in the last
651
The `crit` line will issue a critical alarm if even a single packet has been dropped.
652
653
Note that the drops chart does not exist if a network interface has never dropped a single packet.
656
-When netdata detects a dropped packet, it will add the chart and it will automatically attach this
654
+When Netdata detects a dropped packet, it will add the chart and it will automatically attach this
655
alarm to it.
656
657
## Troubleshooting
658
661
-You can compile netdata with [debugging](../daemon#debugging) and then set in `netdata.conf`:
659
+You can compile Netdata with [debugging](../daemon#debugging) and then set in `netdata.conf`:
660
661
```
662
[global]
@@ -671,7 +669,7 @@ Important: this will generate a lot of output in debug.log.
669
You can find the context of charts by looking up the chart in either
670
`http://your.netdata:19999/netdata.conf` or `http://your.netdata:19999/api/v1/charts`.
671
674
-You can find how netdata interpreted the expressions by examining the alarm at `http://your.netdata:19999/api/v1/alarms?all`. For each expression, netdata will return the expression as given in its config file, and the same expression with additional parentheses added to indicate the evaluation flow of the expression.
672
+You can find how Netdata interpreted the expressions by examining the alarm at `http://your.netdata:19999/api/v1/alarms?all`. For each expression, Netdata will return the expression as given in its config file, and the same expression with additional parentheses added to indicate the evaluation flow of the expression.
673
674
## Disabling health checks or silencing notifications at runtime
675
health/notifications/awssns/README.md
+3
-3
@@ -14,9 +14,9 @@ To get this working, you will need:
14
* The Amazon Web Services CLI tools. Most distributions provide these with the package name `awscli`.
15
* An actual home directory for the user you run Netdata as, instead of just using `/` as a home directory. Setup of this is distribution specific. `/var/lib/netdata` is the recommended directory (because the permissions will already be correct) if you are using a dedicated user (which is how most distributions work).
16
* An Amazon SNS topic to send notifications to with one or more subscribers. The [Getting Started](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html) section of the Amazon SNS documentation covers the basics of how to set this up. Make note of the Topic ARN when you create the topic.
17
-* While not mandatory, it is highly recommended to create a dedicated IAM user on your account for netdata to send notifications. This user needs to have programmatic access, and should only allow access to SNS. If you're really paranoid, you can create one for each system or group of systems.
17
+* While not mandatory, it is highly recommended to create a dedicated IAM user on your account for Netdata to send notifications. This user needs to have programmatic access, and should only allow access to SNS. If you're really paranoid, you can create one for each system or group of systems.
18
19
-Once you have all the above, run the following command as the user netdata runs under:
19
+Once you have all the above, run the following command as the user Netdata runs under:
20
21
aws configure
22
@@ -28,6 +28,6 @@ Notes:
28
29
* Netdata's native email notification support is far better in almost all respects than it's support through Amazon SNS. If you want email notifications, use the native support, not SNS.
30
* If you need to change the notification format for SNS notifications, you can do so by specifying the format in `AWSSNS_MESSAGE_FORMAT` in the configuration. This variable supports all the same vairiables you can use in custom notifications.
31
- * While Amazon SNS supports sending differently formatted messages for different delivery methods, netdata does not currently support this functionality.
31
+ * While Amazon SNS supports sending differently formatted messages for different delivery methods, Netdata does not currently support this functionality.
32
33
[]()
health/notifications/custom/README.md
+2
-2
@@ -46,7 +46,7 @@ Variables available to the custom_sender:
46
- `${alarm_id}` the unique id of the alarm that generated this event
47
- `${event_id}` the incremental id of the event, for this alarm id
48
- `${when}` the timestamp this event occurred
49
- - `${name}` the name of the alarm, as given in netdata health.d entries
49
+ - `${name}` the name of the alarm, as given in Netdata health.d entries
50
- `${url_name}` same as `${name}` but URL encoded
51
- `${chart}` the name of the chart (type.id)
52
- `${url_chart}` same as `${chart}` but URL encoded
@@ -67,7 +67,7 @@ Variables available to the custom_sender:
67
- `${old_value_string}` friendly old value (with units)
68
- `${image}` the URL of an image to represent the status of the alarm
69
- `${color}` a color in #AABBCC format for the alarm
70
- - `${goto_url}` the URL the user can click to see the netdata dashboard
70
+ - `${goto_url}` the URL the user can click to see the Netdata dashboard
71
- `${calc_expression}` the expression evaluated to provide the value for the alarm
72
- `${calc_param_values}` the value of the variables in the evaluated expression
73
- `${total_warnings}` the total number of alarms in WARNING state on the host
health/notifications/discord/README.md
+1
-1
@@ -6,7 +6,7 @@ This is what you will get:
6
7
You need:
8
9
-1. The **incoming webhook URL** as given by Discord. Create a webhook by following the official [Discord documentation](https://support.discordapp.com/hc/en-us/articles/228383668-Intro-to-Webhooks). You can use the same on all your netdata servers (or you can have multiple if you like - your decision).
9
+1. The **incoming webhook URL** as given by Discord. Create a webhook by following the official [Discord documentation](https://support.discordapp.com/hc/en-us/articles/228383668-Intro-to-Webhooks). You can use the same on all your Netdata servers (or you can have multiple if you like - your decision).
10
2. One or more Discord channels to post the messages to.
11
12
Set them in `/etc/netdata/health_alarm_notify.conf` (to edit it on your system run `/etc/netdata/edit-config health_alarm_notify.conf`), like this:
health/notifications/email/README.md
+2
-2
@@ -2,7 +2,7 @@
2
3
You need a working `sendmail` command for email alerts to work. Almost all MTAs provide a `sendmail` interface.
4
5
-netdata sends all emails as user `netdata`, so make sure your `sendmail` works for local users.
5
+Netdata sends all emails as user `netdata`, so make sure your `sendmail` works for local users.
6
7
email notifications look like this:
8
@@ -16,7 +16,7 @@ You can configure recipients in [`/etc/netdata/health_alarm_notify.conf`](https:
16
17
You can also configure per role recipients [in the same file, a few lines below](https://github.com/netdata/netdata/blob/99d44b7d0c4e006b11318a28ba4a7e7d3f9b3bae/conf.d/health_alarm_notify.conf#L313).
18
19
-Changes to this file do not require netdata restart.
19
+Changes to this file do not require a Netdata restart.
20
21
You can test your configuration by issuing the commands:
22
health/notifications/flock/README.md
+3
-3
@@ -7,7 +7,7 @@ This is what you will get:
7
8
You need:
9
10
-The **incoming webhook URL** as given by flock.com. You can use the same on all your netdata servers (or you can have multiple if you like - your decision).
10
+The **incoming webhook URL** as given by flock.com. You can use the same on all your Netdata servers (or you can have multiple if you like - your decision).
11
12
Get them here: https://admin.flock.com/webhooks
13
@@ -21,8 +21,8 @@ Set them in `/etc/netdata/health_alarm_notify.conf` (to edit it on your system r
21
SEND_FLOCK="YES"
22
23
# Login to flock.com and create an incoming webhook.
24
-# You need only one for all your netdata servers.
25
-# Without it, netdata cannot send flock notifications.
24
+# You need only one for all your Netdata servers.
25
+# Without it, Netdata cannot send flock notifications.
26
FLOCK_WEBHOOK_URL="https://api.flock.com/hooks/sendMessage/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
27
28
# if a role recipient is not configured, no notification will be sent
health/notifications/irc/README.md
+1
-1
@@ -10,7 +10,7 @@ Irssi terminal client:
10
11
12
You need:
13
-1. The `nc` utility. If you do not set the path, netdata will search for it in your system `$PATH`.
13
+1. The `nc` utility. If you do not set the path, Netdata will search for it in your system `$PATH`.
14
15
Set the path for `nc` in `/etc/netdata/health_alarm_notify.conf` (to edit it on your system run `/etc/netdata/edit-config health_alarm_notify.conf`), like this:
16
health/notifications/kavenegar/README.md
+1
-1
@@ -32,7 +32,7 @@ SEND_KAVENEGAR="YES"
32
# copy your api key. You can generate new API Key too.
33
# You can find and select kevenegar sender number from this place.
34
35
-# Without an API key, netdata cannot send KAVENEGAR text messages.
35
+# Without an API key, Netdata cannot send KAVENEGAR text messages.
36
KAVENEGAR_API_KEY=""
37
KAVENEGAR_SENDER=""
38
DEFAULT_RECIPIENT_KAVENEGAR=""
health/notifications/messagebird/README.md
+1
-1
@@ -31,7 +31,7 @@ SEND_MESSAGEBIRD="YES"
31
# to get the API key, click on 'API' in the sidebar, then 'API Access (REST)'
32
# click 'Add access key' and fill in data (you want a live key to send SMS)
33
34
-# Without an access key, netdata cannot send Messagebird text messages.
34
+# Without an access key, Netdata cannot send Messagebird text messages.
35
MESSAGEBIRD_ACCESS_KEY="XXXXXXXX"
36
MESSAGEBIRD_NUMBER="XXXXXXX"
37
DEFAULT_RECIPIENT_MESSAGEBIRD="XXXXXXX"
health/notifications/pagerduty/README.md
+3
-3
@@ -2,11 +2,11 @@
2
3
[PagerDuty](https://www.pagerduty.com/company/) is the enterprise incident resolution service that integrates with ITOps and DevOps monitoring stacks to improve operational reliability and agility. From enriching and aggregating events to correlating them into incidents, PagerDuty streamlines the incident management process by reducing alert noise and resolution times.
4
5
-Here is an example of a PagerDuty dashboard with netdata notifications:
5
+Here is an example of a PagerDuty dashboard with Netdata notifications:
6
7
-
7
+
8
9
-To have netdata send notifications to PagerDuty, you'll first need to set up a PagerDuty `Generic API` service and install the PagerDuty agent on the host running netdata. See the following guide for details:
9
+To have Netdata send notifications to PagerDuty, you'll first need to set up a PagerDuty `Generic API` service and install the PagerDuty agent on the host running Netdata. See the following guide for details:
10
11
https://www.pagerduty.com/docs/guides/agent-install-guide/
12
health/notifications/pushbullet/README.md
+1
-1
@@ -36,7 +36,7 @@ SEND_PUSHBULLET="YES"
36
# not have a pushbullet account, the pushbullet service will send an email
37
# to that address instead
38
39
-# Without an access token, netdata cannot send pushbullet notifications.
39
+# Without an access token, Netdata cannot send pushbullet notifications.
40
PUSHBULLET_ACCESS_TOKEN="o.Sometokenhere"
41
DEFAULT_RECIPIENT_PUSHBULLET="admin1@example.com admin3@somemail.com"
42
```
health/notifications/pushover/README.md
+2
-2
@@ -2,11 +2,11 @@
2
3
pushover.net allows you to receive push notifications on your mobile phone. The service seems free for up to 7.500 messages per month.
4
5
-netdata will send warning messages with priority `0` and critical messages with priority `1`. pushover.net allows you to select do-not-disturb hours. The way this is configured, critical notifications will ring and vibrate your phone, even during the do-not-disturb-hours. All other notifications will be delivered silently.
5
+Netdata will send warning messages with priority `0` and critical messages with priority `1`. pushover.net allows you to select do-not-disturb hours. The way this is configured, critical notifications will ring and vibrate your phone, even during the do-not-disturb-hours. All other notifications will be delivered silently.
6
7
You need:
8
9
-1. APP TOKEN. You can use the same on all your netdata servers.
9
+1. APP TOKEN. You can use the same on all your Netdata servers.
10
2. USER TOKEN for each user you are going to send notifications to. This is the actual recipient of the notification.
11
12
The configuration is like above (slack messages).
health/notifications/rocketchat/README.md
+3
-3
@@ -4,7 +4,7 @@ This is what you will get:
4
5
You need:
6
7
-1. The **incoming webhook URL** as given by RocketChat. You can use the same on all your netdata servers (or you can have multiple if you like - your decision).
7
+1. The **incoming webhook URL** as given by RocketChat. You can use the same on all your Netdata servers (or you can have multiple if you like - your decision).
8
2. One or more channels to post the messages to.
9
10
Get them here: https://rocket.chat/docs/administrator-guides/integrations/index.html#how-to-create-a-new-incoming-webhook
@@ -22,8 +22,8 @@ Set them in `/etc/netdata/health_alarm_notify.conf` (to edit it on your system r
22
SEND_ROCKETCHAT="YES"
23
24
# Login to rocket.chat and create an incoming webhook. You need only one for all
25
-# your netdata servers (or you can have one for each of your netdata).
26
-# Without it, netdata cannot send rocketchat notifications.
25
+# your Netdata servers (or you can have one for each of your Netdata).
26
+# Without it, Netdata cannot send rocketchat notifications.
27
ROCKETCHAT_WEBHOOK_URL="<your_incoming_webhook_url>"
28
29
# if a role's recipients are not configured, a notification will be send to
health/notifications/slack/README.md
+2
-2
@@ -5,7 +5,7 @@ This is what you will get:
5
6
You need:
7
8
-1. The **incoming webhook URL** as given by slack.com. You can use the same on all your netdata servers (or you can have multiple if you like - your decision).
8
+1. The **incoming webhook URL** as given by slack.com. You can use the same on all your Netdata servers (or you can have multiple if you like - your decision).
9
2. One or more channels to post the messages to.
10
11
To get a webhook that works on multiple channels, you will need to login to your slack.com workspace and create an incoming webhook using the [Incoming Webhooks App](https://slack.com/apps/A0F7XDUAZ-incoming-webhooks).
@@ -29,7 +29,7 @@ DEFAULT_RECIPIENT_SLACK="alarms"
29
30
You can define multiple recipients like this: `# #alarms systems @myuser`.
31
This example will send the alarm to:
32
-- The recipient defined in slack for the webhook (not known to netdata)
32
+- The recipient defined in slack for the webhook (not known to Netdata)
33
- The channel 'alarms'
34
- The channel 'systems'
35
- The user @myuser
health/notifications/smstools3/README.md
+1
-1
@@ -2,7 +2,7 @@
2
3
The [SMS Server Tools 3](http://smstools3.kekekasvi.com/) is a SMS Gateway software which can send and receive short messages through GSM modems and mobile phones.
4
5
-To have netdata send notifications via SMS Server Tools 3, you'll first need to [install](http://smstools3.kekekasvi.com/index.php?p=compiling) and [configure](http://smstools3.kekekasvi.com/index.php?p=configure) smsd.
5
+To have Netdata send notifications via SMS Server Tools 3, you'll first need to [install](http://smstools3.kekekasvi.com/index.php?p=compiling) and [configure](http://smstools3.kekekasvi.com/index.php?p=configure) smsd.
6
7
Ensure that the user `netdata` can execute `sendsms`. Any user executing `sendsms` needs to:
8
health/notifications/syslog/README.md
+1
-1
@@ -18,7 +18,7 @@ Targets are defined as follows:
18
19
`prefix` defines what the log messages are prefixed with. By default, all lines are prefixed with 'netdata'.
20
21
-The `facility` and `level` are the standard syslog facility and level options, for more info on them see your local `logger` and `syslog` documentation. By default, netdata will log to the `local6` facility, with a log level dependent on the type of message (`crit` for CRITICAL, `warning` for WARNING, and `info` for everything else).
21
+The `facility` and `level` are the standard syslog facility and level options, for more info on them see your local `logger` and `syslog` documentation. By default, Netdata will log to the `local6` facility, with a log level dependent on the type of message (`crit` for CRITICAL, `warning` for WARNING, and `info` for everything else).
22
23
You can configure sending directly to remote log servers by specifying a host (and optionally a port). However, this has a somewhat high overhead, so it is much preferred to use your local syslog daemon to handle the forwarding of messages to remote systems (pretty much all of them allow at least simple forwarding, and most of the really popular ones support complex queueing and routing of messages to remote log servers).
24
health/notifications/telegram/README.md
+1
-1
@@ -4,7 +4,7 @@
4
5
With Telegram, you can send messages, photos, videos and files of any type (doc, zip, mp3, etc), as well as create groups for up to 30,000 people or channels for broadcasting to unlimited audiences. You can write to your phone contacts and find people by their usernames. As a result, Telegram is like SMS and email combined — and can take care of all your personal or business messaging needs.
6
7
-netdata will send warning messages without vibration.
7
+Netdata will send warning messages without vibration.
8
9
You need:
10
health/notifications/twilio/README.md
+1
-1
@@ -32,7 +32,7 @@ SEND_TWILIO="YES"
32
# Then just set the recipients' phone numbers.
33
# The trial account is only allowed to use the number specified when set up.
34
35
-# Without an account sid and token, netdata cannot send Twilio text messages.
35
+# Without an account sid and token, Netdata cannot send Twilio text messages.
36
TWILIO_ACCOUNT_SID="xxxxxxxxx"
37
TWILIO_ACCOUNT_TOKEN="xxxxxxxxxx"
38
TWILIO_NUMBER="xxxxxxxxxxx"
health/notifications/web/README.md
+1
-1
@@ -1,6 +1,6 @@
1
# Dashboard
2
3
-The netdata dashboard shows HTML notifications, when it is open.
3
+The Netdata dashboard shows HTML notifications, when it is open.
4
5
Such web notifications look like this:
6
libnetdata/README.md
+1
-1
@@ -1,6 +1,6 @@
1
# libnetdata
2
3
-`libnetdata` is a collection of library code that is used by all netdata `C` programs.
3
+`libnetdata` is a collection of library code that is used by all Netdata `C` programs.
4
5
6
libnetdata/adaptive_resortable_list/README.md
+3
-3
@@ -1,10 +1,10 @@
1
2
# Adaptive Re-sortable List (ARL)
3
4
-This library allows netdata to read a series of `name - value` pairs
4
+This library allows Netdata to read a series of `name - value` pairs
5
in the **fastest possible way**.
6
7
-ARLs are used all over netdata, as they are the most
7
+ARLs are used all over Netdata, as they are the most
8
CPU utilization efficient way to process `/proc` files. They are used to
9
process both vertical (csv like) and horizontal (one pair per line) `name - value` pairs.
10
@@ -82,7 +82,7 @@ test|code|string comparison|number parsing|duration
82
83
Compared to unoptimized code (test No 1: 4.6sec):
84
85
- - before ARL netdata was using test No **7** with hashing and a custom `str2ull()` to achieve 602ms.
85
+ - before ARL Netdata was using test No **7** with hashing and a custom `str2ull()` to achieve 602ms.
86
- the current ARL implementation is test No **9** that needs only 157ms (29 times faster vs unoptimized code, about 4 times faster vs optimized code).
87
88
[Check the source code of this test](../../tests/profile/benchmark-value-pairs.c).
libnetdata/config/README.md
+5
-5
@@ -1,6 +1,6 @@
1
-# netdata ini config files
1
+# Netdata ini config files
2
3
-Configuration files `netdata.conf` and `stream.conf` are netdata ini files.
3
+Configuration files `netdata.conf` and `stream.conf` are Netdata ini files.
4
5
## Motivation
6
@@ -17,7 +17,7 @@ developers and the users.
17
18
So, we did this:
19
20
-1. No configuration is required to run netdata
20
+1. No configuration is required to run Netdata
21
2. There are plenty of options to tweak
22
3. There is minimal documentation (or no at all)
23
@@ -35,9 +35,9 @@ file, the default is used. The lookup is made using B-Trees and hashes
35
settings can be `my super duper setting that once set to yes, will turn the world upside down = no`
36
- so goodbye to most of the documentation involved.
37
38
-Next, netdata can generate a valid configuration for the user to edit.
38
+Next, Netdata can generate a valid configuration for the user to edit.
39
No need to remember anything or copy and paste settings. Just get the
40
-configuration from the server (`/netdata.conf` on your netdata server),
40
+configuration from the server (`/netdata.conf` on your Netdata server),
41
edit it and save it.
42
43
Last, what about options you believe you have set, but you misspelled?
libnetdata/procfile/README.md
+1
-1
@@ -58,6 +58,6 @@ When the caller exits:
58
To achieve this kind of performance, the library tries to work in batches so that the code
59
and the data are inside the processor's caches.
60
61
-This library is extensively used in netdata and its plugins.
61
+This library is extensively used in Netdata and its plugins.
62
63
[]()
libnetdata/simple_pattern/README.md
+4
-4
@@ -1,9 +1,9 @@
1
-## netdata simple patterns
1
+## Netdata simple patterns
2
3
Unix prefers regular expressions. But they are just too hard, too cryptic
4
to use, write and understand.
5
6
-So, netdata supports **simple patterns**.
6
+So, Netdata supports **simple patterns**.
7
8
Simple patterns are a space separated list of words, that can have `*`
9
as a wildcard. Each world may use any number of `*`. Simple patterns
@@ -16,7 +16,7 @@ Simple patterns are quite powerful: `pattern = *foobar* !foo* !*bar *`
16
matches everything containing `foobar`, except strings that start
17
with `foo` or end with `bar`.
18
19
-You can use the netdata command line to check simple patterns,
19
+You can use the Netdata command line to check simple patterns,
20
like this:
21
22
```sh
@@ -30,7 +30,7 @@ RESULT: NOT MATCHED - pattern '*foobar* !foo* !*bar *' does not match 'hello wor
30
RESULT: MATCHED - pattern '*foobar* !foo* !*bar *' matches 'hello world foobar'
31
```
32
33
-netdata stops processing to the first positive or negative match
33
+Netdata stops processing to the first positive or negative match
34
(left to right). If it is not matched by either positive or negative
35
patterns, it is denied at the end.
36
libnetdata/storage_number/README.md
+1
-1
@@ -1,4 +1,4 @@
1
-# netdata storage number
1
+# Netdata storage number
2
3
Although `netdata` does all its calculations using `long double`, it stores all values using
4
a **custom-made 32-bit number**.
packaging/docker/README.md
+25
-26
@@ -1,23 +1,22 @@
1
-# Install netdata with Docker
1
+# Install Netdata with Docker
2
3
-> :warning: As of Sep 9th, 2018 we ship [new docker builds](https://github.com/netdata/netdata/pull/3995), running netdata in docker with an [ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, not a COMMAND directive. Please adapt your execution scripts accordingly. You can find more information about ENTRYPOINT vs COMMAND is presented by goinbigdata [here](http://goinbigdata.com/docker-run-vs-cmd-vs-entrypoint/) and by docker docs [here](https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact).
3
+> :warning: As of Sep 9th, 2018 we ship [new docker builds](https://github.com/netdata/netdata/pull/3995), running Netdata in Docker with an [ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, not a COMMAND directive. Please adapt your execution scripts accordingly. You can find more information about ENTRYPOINT vs COMMAND is presented by goinbigdata [here](http://goinbigdata.com/docker-run-vs-cmd-vs-entrypoint/) and by docker docs [here](https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact).
4
>
5
> Also, the `latest` is now based on alpine, so **`alpine` is not updated any more** and `armv7hf` is now replaced with `armhf` (to comply with https://github.com/multiarch naming), so **`armv7hf` is not updated** either.
6
7
## Limitations
8
9
-Running netdata in a container for monitoring the whole host, can limit its capabilities. Some data is not accessible or not as detailed as when running netdata on the host.
9
+Running Netdata in a container for monitoring the whole host, can limit its capabilities. Some data is not accessible or not as detailed as when running Netdata on the host.
10
11
## Package scrambling in runtime (x86_64 only)
12
13
-By default on x86_64 architecture our docker images use Polymorphic Polyverse Linux package scrambling. For increased security you can enable rescrambling of packages during runtime. To do this set environment variable `RESCRAMBLE=true` while starting netdata docker container.
13
+By default on x86_64 architecture our docker images use Polymorphic Polyverse Linux package scrambling. For increased security you can enable rescrambling of packages during runtime. To do this set environment variable `RESCRAMBLE=true` while starting Netdata docker container.
14
15
For more information go to [Polyverse site](https://polyverse.io/how-it-works/)
16
17
-## Run netdata with docker command
17
+## Run Netdata with the docker command
18
19
-Quickly start netdata with the docker command line.
20
-Netdata is then available at http://host:19999
19
+Quickly start Netdata with the `docker` command. Netdata is then available at http://host:19999
20
21
This is good for an internal network or to quickly analyse a host.
22
@@ -58,18 +57,18 @@ If you don't want to use the apps.plugin functionality, you can remove the mount
57
58
### Docker container names resolution
59
61
-There are a few options for resolving container names within netdata. Some methods of doing so will allow root access to your machine from within the container. Please read the following carefully.
60
+There are a few options for resolving container names within Netdata. Some methods of doing so will allow root access to your machine from within the container. Please read the following carefully.
61
63
-#### Docker Socket Proxy (Safest Option)
62
+#### Docker socket proxy (safest option)
63
64
Deploy a Docker socket proxy that accepts and filter out requests using something like [HAProxy](https://docs.netdata.cloud/docs/running-behind-haproxy/) so that it restricts connections to read-only access to the CONTAINERS endpoint.
65
67
-The reason it's safer to expose the socket to the proxy is because netdata has a TCP port exposed outside the Docker network. Access to the proxy container is limited to only within the network.
66
+The reason it's safer to expose the socket to the proxy is because Netdata has a TCP port exposed outside the Docker network. Access to the proxy container is limited to only within the network.
67
69
-#### Giving group access to Docker Socket (Less safe)
68
+#### Giving group access to the Docker socket (less safe)
69
70
**Important Note**: You should seriously consider the necessity of activating this option,
72
-as it grants to the netdata user access to the privileged socket connection of docker service and therefore your whole machine.
71
+as it grants to the `netdata` user access to the privileged socket connection of docker service and therefore your whole machine.
72
73
If you want to have your container names resolved by Netdata, make the `netdata` user be part of the group that owns the socket.
74
@@ -82,10 +81,10 @@ This group number can be found by running the following (if socket group ownersh
81
grep docker /etc/group | cut -d ':' -f 3
82
```
83
85
-#### Running as root (Unsafe)
84
+#### Running as root (unsafe)
85
86
**Important Note**: You should seriously consider the necessity of activating this option,
88
-as it grants to the netdata user access to the privileged socket connection of docker service and therefore your whole machine.
87
+as it grants to the `netdata` user access to the privileged socket connection of docker service and therefore your whole machine.
88
89
```yaml
90
version: '3'
@@ -102,13 +101,13 @@ services:
101
102
### Pass command line options to Netdata
103
105
-Since we use an [ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, you can provide [netdata daemon command line options](https://docs.netdata.cloud/daemon/#command-line-options) such as the IP address netdata will be running on, using the [command instruction](https://docs.docker.com/engine/reference/builder/#cmd).
104
+Since we use an [ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint) directive, you can provide [Netdata daemon command line options](https://docs.netdata.cloud/daemon/#command-line-options) such as the IP address Netdata will be running on, using the [command instruction](https://docs.docker.com/engine/reference/builder/#cmd).
105
106
## Install Netdata using Docker Compose with SSL/TLS enabled http proxy
107
109
-For a permanent installation on a public server, you should [secure the netdata instance](../../docs/netdata-security.md). This section contains an example of how to install netdata with an SSL reverse proxy and basic authentication.
108
+For a permanent installation on a public server, you should [secure your Netdata instance](../../docs/netdata-security.md). This section contains an example of how to install Netdata with an SSL reverse proxy and basic authentication.
109
111
-You can use use the following docker-compose.yml and Caddyfile files to run netdata with docker. Replace the Domains and email address for [Letsencrypt](https://letsencrypt.org/) before starting.
110
+You can use use the following docker-compose.yml and Caddyfile files to run Netdata with docker. Replace the Domains and email address for [Letsencrypt](https://letsencrypt.org/) before starting.
111
112
### Prerequisites
113
* [Docker](https://docs.docker.com/install/#server)
@@ -128,7 +127,7 @@ netdata.example.org {
127
128
### docker-compose.yml
129
131
-After setting Caddyfile run this with `docker-compose up -d` to have fully functioning netdata setup behind HTTP reverse proxy.
130
+After setting Caddyfile run this with `docker-compose up -d` to have fully functioning Netdata setup behind HTTP reverse proxy.
131
132
```yaml
133
version: '3'
@@ -170,7 +169,7 @@ You can restrict access by following [official caddy guide](https://caddyserver.
169
170
## Publish a test image to your own repository
171
173
-At netdata we provide multiple ways of testing your docker images using your own repositories.
172
+At Netdata, we provide multiple ways of testing your Docker images using your own repositories.
173
You may either use the command line tools available or take advantage of our Travis CI infrastructure.
174
175
### Using tools manually from the command line
@@ -205,22 +204,22 @@ Then we can run `helm install [path to our helmchart clone]`.
204
205
If we make changes to the code, we execute the same `build-test.sh` command, followed by `helm upgrade [name] [path to our helmchart clone]`
206
208
-### Inside netdata organization, using Travis CI
207
+### Inside Netdata organization, using Travis CI
208
209
To enable Travis CI integration on your own repositories (Docker and Github), you need to be part of the Netdata organization.
211
-Once you have contacted the netdata owners to setup you up on Github and Travis, execute the following steps
210
+Once you have contacted the Netdata owners to setup you up on Github and Travis, execute the following steps
211
212
- Preparation
214
- - Have netdata forked on your personal GITHUB account
215
- - Get a GITHUB token: Go to Github settings -> Developer Settings -> Personal access tokens, generate a new token with full access to repo_hook, read only access to admin:org, public_repo, repo_deployment, repo:status and user:email settings enabled. This will be your GITHUB_TOKEN that is described later in the instructions, so keep it somewhere safe until is needed.
216
- - Contact netdata team and seek for permissions on https://scan.coverity.com should you require Travis to be able to push your forked code to coverity for analysis and report. Once you are setup, you should have your email you used in coverity and a token from them. These will be your COVERITY_SCAN_SUBMIT_EMAIL and COVERITY_SCAN_TOKEN that we will refer to later.
213
+ - Have Netdata forked on your personal GitHub account
214
+ - Get a GITHUB token: Go to GitHub settings -> Developer Settings -> Personal access tokens, generate a new token with full access to repo_hook, read only access to admin:org, public_repo, repo_deployment, repo:status and user:email settings enabled. This will be your GITHUB_TOKEN that is described later in the instructions, so keep it somewhere safe until is needed.
215
+ - Contact the Netdata team and seek for permissions on https://scan.coverity.com should you require Travis to be able to push your forked code to coverity for analysis and report. Once you are setup, you should have your email you used in coverity and a token from them. These will be your COVERITY_SCAN_SUBMIT_EMAIL and COVERITY_SCAN_TOKEN that we will refer to later.
216
- Have a valid Docker hub account, the credentials from this account will be your DOCKER_USERNAME and DOCKER_PWD mentioned later
217
218
- Setting up Travis CI for your own fork (Detailed instructions provided by Travis team [here](https://docs.travis-ci.com/user/tutorial/))
219
- Login to travis with your own GITHUB credentials (There is Open Auth access)
221
- - Go to your profile settings, under [repositories](https://travis-ci.com/account/repositories) section and setup your netdata fork to be built by travis
220
+ - Go to your profile settings, under [repositories](https://travis-ci.com/account/repositories) section and setup your Netdata fork to be built by travis
221
- Once the repository has been setup, go to repository settings within travis (usually under https://travis-ci.com/NETDATA_DEVELOPER/netdata/settings, where "NETDATA_DEVELOPER" is your github handle) and select your desired settings.
223
-- While in Travis settings, under netdata repository settings in the Environment Variables section, you need to add the following:
222
+- While in Travis settings, under Netdata repository settings in the Environment Variables section, you need to add the following:
223
- DOCKER_USERNAME and DOCKER_PWD variables so that Travis can login to your docker hub account and publish docker images there.
224
- REPOSITORY variable to "NETDATA_DEVELOPER/netdata" where NETDATA_DEVELOPER is your github handle again.
225
- GITHUB_TOKEN variable with the token generated on the preparation step, for travis workflows to function properly
packaging/installer/README.md
+1
-1
@@ -371,7 +371,7 @@ To enable the Netdata service:
371
service netdata config set enable=true
372
```
373
374
-To start the netdata service:
374
+To start the Netdata service:
375
```
376
service netdata start
377
```
packaging/installer/UNINSTALL.md
+5
-5
@@ -1,6 +1,6 @@
1
-# Uninstalling netdata
1
+# Uninstalling Netdata
2
3
-Our self-contained uninstaller is able to remove netdata installations created with shell installer. It doesn't need any other netdata repository files to be run. All it needs is an .environment file, which is created during installation (with shell installer) and put in ${NETDATA_USER_CONFIG_DIR}/.environment (by default /etc/netdata/.environment). That file contains some parameters which are passed to our installer and which are needed during uninstallation process. Mainly two parameters are needed:
3
+Our self-contained uninstaller is able to remove Netdata installations created with shell installer. It doesn't need any other Netdata repository files to be run. All it needs is an .environment file, which is created during installation (with shell installer) and put in ${NETDATA_USER_CONFIG_DIR}/.environment (by default /etc/netdata/.environment). That file contains some parameters which are passed to our installer and which are needed during uninstallation process. Mainly two parameters are needed:
4
```
5
NETDATA_PREFIX
6
NETDATA_ADDED_TO_GROUPS
@@ -9,10 +9,10 @@ NETDATA_ADDED_TO_GROUPS
9
A workflow for uninstallation looks like this:
10
11
1. Find your `.environment` file, which is usually `/etc/netdata/.environment` in a default installation.
12
-2. If you cannot find that file and would like to uninstall netdata, then create new file with following content:
12
+2. If you cannot find that file and would like to uninstall Netdata, then create new file with following content:
13
```
14
NETDATA_PREFIX="<installation prefix>" # put what you used as a parameter to shell installed `--install` flag. Otherwise it should be empty
15
-NETDATA_ADDED_TO_GROUPS="<additional groups>" # Additional groups for a user running netdata process
15
+NETDATA_ADDED_TO_GROUPS="<additional groups>" # Additional groups for a user running the Netdata process
16
```
17
3. Run `netdata-uninstaller.sh` as follows
18
```
@@ -29,6 +29,6 @@ chmod +x ./netdata-uninstaller.sh
29
30
The default `environment_file` is `/etc/netdata/.environment`.
31
32
-Note: This uninstallation method assumes previous installation with netdata-installer.sh or kickstart script. Currently using it when netdata was installed by a package manager can work or cause unexpected results.
32
+Note: This uninstallation method assumes previous installation with `netdata-installer.sh` or the kickstart script. Currently using it when Netdata was installed by a package manager can work or cause unexpected results.
33
34
[]()
packaging/installer/UPDATE.md
+8
-8
@@ -1,9 +1,9 @@
1
-# Updating netdata after its installation
1
+# Updating Netdata after its installation
2
3
4
5
6
-We suggest to keep your netdata updated. We are actively developing it and you should always update to the latest version.
6
+We suggest to keep your Netdata updated. We are actively developing it and you should always update to the latest version.
7
8
The update procedure depends on how you installed it:
9
@@ -11,7 +11,7 @@ The update procedure depends on how you installed it:
11
12
### Manual update to get the latest git commit
13
14
-netdata versions older than `v1.12.0-rc2-52` had a `netdata-updater.sh` script in the root directory of the source code, which has now been deprecated. The manual process that works for all versions to get the latest commit in git is to use the `netdata-installer.sh`. The installer preserves your custom configuration and updates the information of the installation in the `.environment` file under the user configuration directory.
14
+Netdata versions older than `v1.12.0-rc2-52` had a `netdata-updater.sh` script in the root directory of the source code, which has now been deprecated. The manual process that works for all versions to get the latest commit in git is to use the `netdata-installer.sh`. The installer preserves your custom configuration and updates the information of the installation in the `.environment` file under the user configuration directory.
15
16
```sh
17
# go to the git downloaded directory
@@ -20,13 +20,13 @@ cd /path/to/git/downloaded/netdata
20
# update your local copy
21
git pull
22
23
-# run the netdata installer
23
+# run the Netdata installer
24
sudo ./netdata-installer.sh
25
```
26
27
_Netdata will be restarted with the new version._
28
29
-Keep in mind, netdata may now have new features, or certain old features may now behave differently. So pay some attention to it after updating.
29
+Keep in mind, Netdata may now have new features, or certain old features may now behave differently. So pay some attention to it after updating.
30
31
### Manual update to get the latest nightly build
32
@@ -40,16 +40,16 @@ bash <(curl -Ss https://my-netdata.io/kickstart.sh) --no-updates
40
_Please, consider the risks of running an auto-update. Something can always go wrong. Keep an eye on your installation, and run a manual update if something ever fails._
41
42
Calling the `netdata-installer.sh` with the `--auto-update` or `-u` option will create the `netdata-updater` script under
43
-either `/etc/cron.daily/`, or `/etc/periodic/daily/`. Whenever the `netdata-updater` is executed, it checks if a newer nightly build is available and then handles the download, installation and netdata restart.
43
+either `/etc/cron.daily/`, or `/etc/periodic/daily/`. Whenever the `netdata-updater` is executed, it checks if a newer nightly build is available and then handles the download, installation and Netdata restart.
44
45
-Note that after Jan 2019, the `kickstart.sh` one-liner `bash <(curl -Ss https://my-netdata.io/kickstart.sh)` calls the `netdata-installer.sh` with the auto-update option. So if you just run the one-liner without options once, your netdata will be kept auto-updated.
45
+Note that after Jan 2019, the `kickstart.sh` one-liner `bash <(curl -Ss https://my-netdata.io/kickstart.sh)` calls the `netdata-installer.sh` with the auto-update option. So if you just run the one-liner without options once, your Netdata will be kept auto-updated.
46
47
48
## You downloaded a binary package
49
50
If you installed it from a binary package, the best way is to **obtain a newer copy** from the source you got it in the first place. This includes the static binary installation via `kickstart-base64.sh`, which would need to be executed again.
51
52
-If a newer version of netdata is not available from the source you got it, we suggest to uninstall the version you have and follow the [installation](README.md) instructions for installing a fresh version of netdata.
52
+If a newer version of Netdata is not available from the source you got it, we suggest to uninstall the version you have and follow the [installation](README.md) instructions for installing a fresh version of Netdata.
53
54
55
[]()
packaging/maintainers/README.md
+1
-1
@@ -1,6 +1,6 @@
1
# Package Maintainers
2
3
-This page tracks the package maintainers for netdata, for various operating systems and versions.
3
+This page tracks the package maintainers for Netdata, for various operating systems and versions.
4
5
> Feel free to update it, so that it reflects the current status.
6
packaging/makeself/README.md
+11
-11
@@ -1,4 +1,4 @@
1
-# netdata static binary build
1
+# Netdata static binary build
2
3
To build the static binary 64-bit distribution package, run:
4
@@ -11,16 +11,16 @@ The program will:
11
12
1. setup a new docker container with Alpine Linux
13
2. install the required alpine packages (the build environment, needed libraries, etc)
14
-3. download and compile third party apps that are packaged with netdata (`bash`, `curl`, etc)
15
-4. compile netdata
14
+3. download and compile third party apps that are packaged with Netdata (`bash`, `curl`, etc)
15
+4. compile Netdata
16
17
-Once finished, a file named `netdata-vX.X.X-gGITHASH-x86_64-DATE-TIME.run` will be created in the current directory. This is the netdata binary package that can be run to install netdata on any other computer.
17
+Once finished, a file named `netdata-vX.X.X-gGITHASH-x86_64-DATE-TIME.run` will be created in the current directory. This is the Netdata binary package that can be run to install Netdata on any other computer.
18
19
---
20
21
## building binaries with debug info
22
23
-To build netdata binaries with debugging / tracing information in them, use:
23
+To build Netdata binaries with debugging / tracing information in them, use:
24
25
```bash
26
$ cd /path/to/netdata.git
@@ -29,20 +29,20 @@ $ ./packaging/makeself/build-x86_64-static.sh debug
29
30
These binaries are not optimized (they are a bit slower), they have certain features disables (like log flood protection), other features enables (like `debug flags`) and are not stripped (the binary files are bigger, since they now include source code tracing information).
31
32
-#### debugging netdata binaries
32
+#### debugging Netdata binaries
33
34
-Once you have installed a binary package with debugging info, you will need to install `valgrind` and run this command to start netdata:
34
+Once you have installed a binary package with debugging info, you will need to install `valgrind` and run this command to start Netdata:
35
36
```bash
37
PATH="/opt/netdata/bin:${PATH}" valgrind --undef-value-errors=no /opt/netdata/bin/srv/netdata -D
38
```
39
40
-The above command, will run netdata under `valgrind`. While netdata runs under `valgrind` it will be 10x slower and use a lot more memory.
40
+The above command, will run Netdata under `valgrind`. While Netdata runs under `valgrind` it will be 10x slower and use a lot more memory.
41
42
-If netdata crashes, `valgrind` will print a stack trace of the issue. Open a github issue to let us know.
42
+If Netdata crashes, `valgrind` will print a stack trace of the issue. Open a github issue to let us know.
43
44
-To stop netdata while it runs under `valgrind`, press Control-C on the console.
44
+To stop Netdata while it runs under `valgrind`, press Control-C on the console.
45
46
-> If you omit the parameter `--undef-value-errors=no` to valgrind, you will get hundreds of errors about conditional jumps that depend on uninitialized values. This is normal. Valgrind has heuristics to prevent it from printing such errors for system libraries, but for the static netdata binary, all the required libraries are built into netdata. So, valgrind cannot appply its heuristics and prints them.
46
+> If you omit the parameter `--undef-value-errors=no` to valgrind, you will get hundreds of errors about conditional jumps that depend on uninitialized values. This is normal. Valgrind has heuristics to prevent it from printing such errors for system libraries, but for the static Netdata binary, all the required libraries are built into Netdata. So, valgrind cannot appply its heuristics and prints them.
47
48
[]()
registry/README.md
+29
-29
@@ -1,7 +1,7 @@
1
# Registry
2
3
-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.
4
-The node menu lists the netdata servers you have visited. The node view offers a lot of additional features on top of the menu,
3
+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.
4
+The node menu lists the Netdata servers you have visited. The node view offers a lot of additional features on top of the menu,
5
[with many more to come](https://blog.netdata.cloud/posts/netdata-cloud-announcement/).
6
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
7
the information described [here](#what-data-does-the-registry-store).
@@ -11,7 +11,7 @@ You can still get the node menu, but not the cloud features, if you [run your ow
11
12
Netdata provides distributed monitoring.
13
14
-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:
14
+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:
15
16
1. due to the resources required, the number of metrics collected is limited.
17
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.
@@ -23,14 +23,14 @@ Netdata follows a different approach:
23
1. data collection happens per second
24
1. thousands of metrics per server are collected
25
1. data do not leave the server where they are collected
26
-1. netdata servers do not talk to each other
27
-1. your browser connects all the netdata servers
26
+1. Netdata servers do not talk to each other
27
+1. your browser connects all the Netdata servers
28
29
-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.
29
+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.
30
31
-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.
31
+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.
32
33
-To solve this, netdata utilizes a **central registry**. This registry, together with certain browser features, allow netdata to provide unified cross-server dashboards.
33
+To solve this, Netdata utilizes a **central registry**. This registry, together with certain browser features, allow Netdata to provide unified cross-server dashboards.
34
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.
35
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.
36
@@ -38,28 +38,28 @@ Netdata cloud has a roadmap to [offer many more features](https://blog.netdata.c
38
39
The registry keeps track of 4 entities:
40
41
-1. **machines**: i.e. the netdata installations (a random GUID generated by each netdata the first time it starts; we call this **machine_guid**)
41
+1. **machines**: i.e. the Netdata installations (a random GUID generated by each Netdata the first time it starts; we call this **machine_guid**)
42
43
- For each netdata installation (each `machine_guid`) the registry keeps track of the different URLs it is accessed.
43
+ For each Netdata installation (each `machine_guid`) the registry keeps track of the different URLs it is accessed.
44
45
-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**)
45
+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**)
46
47
- For each person, the registry keeps track of the netdata installations it has accessed and their URLs.
47
+ For each person, the registry keeps track of the Netdata installations it has accessed and their URLs.
48
49
-3. **URLs** of netdata installations (as seen by the web browsers)
49
+3. **URLs** of Netdata installations (as seen by the web browsers)
50
51
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.
52
53
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.
54
55
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).
56
-*machines*, *persons* and timestamps are stored in the netdata registry regardless of whether you sign in or not.
56
+*machines*, *persons* and timestamps are stored in the Netdata registry regardless of whether you sign in or not.
57
58
## Who talks to the registry?
59
60
Your web browser **only**! If sending this information is against your policies, you can [run your own registry](#run-your-own-registry)
61
62
-Your netdata servers do not talk to the registry. This is a UML diagram of its operation:
62
+Your Netdata servers do not talk to the registry. This is a UML diagram of its operation:
63
64
65
@@ -69,7 +69,7 @@ Your netdata servers do not talk to the registry. This is a UML diagram of its o
69
`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.
70
`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.
71
72
-### Can this registry handle the global load of netdata installations?
72
+### Can this registry handle the global load of Netdata installations?
73
74
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).
75
@@ -77,9 +77,9 @@ We believe, it can do it...
77
78
## Run your own registry
79
80
-**Every netdata can be a registry**. Just pick one and configure it.
80
+**Every Netdata can be a registry**. Just pick one and configure it.
81
82
-**To turn any netdata into a registry**, edit `/etc/netdata/netdata.conf` and set:
82
+**To turn any Netdata into a registry**, edit `/etc/netdata/netdata.conf` and set:
83
84
```
85
[registry]
@@ -87,9 +87,9 @@ We believe, it can do it...
87
registry to announce = http://your.registry:19999
88
```
89
90
-Restart your netdata to activate it.
90
+Restart your Netdata to activate it.
91
92
-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:
92
+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:
93
94
```
95
[registry]
@@ -97,11 +97,11 @@ Then, you need to tell **all your other netdata servers to advertise your regist
97
registry to announce = http://your.registry:19999
98
```
99
100
-Note that we have not enabled the registry on the other servers. Only one netdata (the registry) needs `[registry].enabled = yes`.
100
+Note that we have not enabled the registry on the other servers. Only one Netdata (the registry) needs `[registry].enabled = yes`.
101
102
This is it. You have your registry now.
103
104
-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:
104
+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:
105
106
```
107
[registry]
@@ -112,15 +112,15 @@ So this server will appear in the node menu as `Group1 - Master DB`. The max nam
112
113
### Limiting access to the registry
114
115
-netdata v1.9+ support limiting access to the registry from given IPs, like this:
115
+Netdata v1.9+ support limiting access to the registry from given IPs, like this:
116
```
117
[registry]
118
allow from = *
119
```
120
121
-`allow from` settings are [netdata simple patterns](../libnetdata/simple_pattern/): 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.
121
+`allow from` settings are [Netdata simple patterns](../libnetdata/simple_pattern/): 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.
122
123
-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`.
123
+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`.
124
125
### Where is the registry database stored?
126
@@ -134,19 +134,19 @@ There can be up to 2 files:
134
135
- `registry.db`, the database
136
137
- 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`.
137
+ 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`.
138
139
Both files are machine readable text files.
140
141
## The future
142
143
-The registry opens a whole world of new possibilities for netdata. Check here what we think: https://github.com/netdata/netdata/issues/416
143
+The registry opens a whole world of new possibilities for Netdata. Check here what we think: https://github.com/netdata/netdata/issues/416
144
145
## Troubleshooting the registry
146
147
-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.
147
+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.
148
149
-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:
149
+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:
150
151
```
152
ERROR 409: Cannot ACCESS netdata registry: https://registry.my-netdata.io responded with: {"status":"redirect","registry":"https://registry.my-netdata.io"}
streaming/README.md
+58
-59
@@ -1,11 +1,10 @@
1
# Streaming and replication
2
3
-Each netdata is able to replicate/mirror its database to another netdata, by streaming collected
3
+Each Netdata is able to replicate/mirror its database to another Netdata, by streaming collected
4
metrics, in real-time to it. This is quite different to [data archiving to third party time-series
5
databases](../backends).
6
7
-When a netdata streams metrics to another netdata, the receiving one is able to perform everything
8
-a netdata performs:
7
+When Netdata streams metrics to another Netdata, the receiving one is able to perform everything a Netdata instance is capable of:
8
9
- visualize them with a dashboard
10
- run health checks that trigger alarms and send alarm notifications
@@ -13,25 +12,25 @@ a netdata performs:
12
13
## Supported configurations
14
16
-### netdata without a database or web API (headless collector)
15
+### Netdata without a database or web API (headless collector)
16
18
-Local netdata (`slave`), **without any database or alarms**, collects metrics and sends them to
19
-another netdata (`master`).
17
+Local Netdata (`slave`), **without any database or alarms**, collects metrics and sends them to
18
+another Netdata (`master`).
19
21
-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/.
20
+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/.
21
22
Alarms for the `slave` are served by the `master`.
23
24
In this mode the `slave` is just a plain data collector. It spawns all external plugins, but instead
25
of maintaining a local database and accepting dashboard requests, it streams all metrics to the
27
-`master`. The memory footprint is reduced significantly, to between 6 MiB and 40 MiB, depending on the enabled plugins. To reduce the memory usage as much as possible, refer to [running netdata in embedded devices](../docs/Performance.md#running-netdata-in-embedded-devices).
26
+`master`. The memory footprint is reduced significantly, to between 6 MiB and 40 MiB, depending on the enabled plugins. To reduce the memory usage as much as possible, refer to [running Netdata in embedded devices](../docs/Performance.md#running-netdata-in-embedded-devices).
27
28
The same `master` can collect data for any number of `slaves`.
29
30
### database replication
31
33
-Local netdata (`slave`), **with a local database (and possibly alarms)**, collects metrics and
34
-sends them to another netdata (`master`).
32
+Local Netdata (`slave`), **with a local database (and possibly alarms)**, collects metrics and
33
+sends them to another Netdata (`master`).
34
35
The user can use all the functions **at both** http://slave-ip:slave-port/ and
36
http://master-host:master-port/host/slave-host/.
@@ -43,15 +42,15 @@ each can have different alarms configurations or have alarms disabled).
42
43
Take a note, that custom chart names, configured on the `slave`, should be in the form `type.name` to work correctly. The `master` will truncate the `type` part and substitute the original chart `type` to store the name in the database.
44
46
-### netdata proxies
45
+### Netdata proxies
46
48
-Local netdata (`slave`), with or without a database, collects metrics and sends them to another
49
-netdata (`proxy`), which may or may not maintain a database, which forwards them to another
50
-netdata (`master`).
47
+Local Netdata (`slave`), with or without a database, collects metrics and sends them to another
48
+Netdata (`proxy`), which may or may not maintain a database, which forwards them to another
49
+Netdata (`master`).
50
51
Alarms for the slave can be triggered by any of the involved hosts that maintains a database.
52
54
-Any number of daisy chaining netdata servers are supported, each with or without a database and
53
+Any number of daisy chaining Netdata servers are supported, each with or without a database and
54
with or without alarms for the `slave` metrics.
55
56
### mix and match with backends
@@ -61,17 +60,17 @@ This allows quite complex setups.
60
61
Example:
62
64
-1. netdata `A`, `B` do not maintain a database and stream metrics to netdata `C`(live streaming functionality, i.e. this PR)
65
-2. netdata `C` maintains a database for `A`, `B`, `C` and archives all metrics to `graphite` with 10 second detail (backends functionality)
66
-3. netdata `C` also streams data for `A`, `B`, `C` to netdata `D`, which also collects data from `E`, `F` and `G` from another DMZ (live streaming functionality, i.e. this PR)
67
-4. netdata `D` is just a proxy, without a database, that streams all data to a remote site at netdata `H`
68
-5. netdata `H` maintains a database for `A`, `B`, `C`, `D`, `E`, `F`, `G`, `H` and sends all data to `opentsdb` with 5 seconds detail (backends functionality)
63
+1. Netdata `A`, `B` do not maintain a database and stream metrics to Netdata `C`(live streaming functionality, i.e. this PR)
64
+2. Netdata `C` maintains a database for `A`, `B`, `C` and archives all metrics to `graphite` with 10 second detail (backends functionality)
65
+3. Netdata `C` also streams data for `A`, `B`, `C` to Netdata `D`, which also collects data from `E`, `F` and `G` from another DMZ (live streaming functionality, i.e. this PR)
66
+4. Netdata `D` is just a proxy, without a database, that streams all data to a remote site at Netdata `H`
67
+5. Netdata `H` maintains a database for `A`, `B`, `C`, `D`, `E`, `F`, `G`, `H` and sends all data to `opentsdb` with 5 seconds detail (backends functionality)
68
6. alarms are triggered by `H` for all hosts
70
-7. users can use all the netdata that maintain a database to view metrics (i.e. at `H` all hosts can be viewed).
69
+7. users can use all the Netdata that maintain a database to view metrics (i.e. at `H` all hosts can be viewed).
70
71
## Configuration
72
74
-These are options that affect the operation of netdata in this area:
73
+These are options that affect the operation of Netdata in this area:
74
75
```
76
[global]
@@ -87,7 +86,7 @@ monitoring (there cannot be health monitoring without a database).
86
accept a streaming request every seconds = 0
87
```
88
90
-`[web].mode = none` disables the API (netdata will not listen to any ports).
89
+`[web].mode = none` disables the API (Netdata will not listen to any ports).
90
This also disables the registry (there cannot be a registry without an API).
91
92
`accept a streaming request every seconds` can be used to set a limit on how often a master Netdata server will accept streaming requests from the slaves. 0 sets no limit, 1 means maximum once every second. If this is set, you may see error log entries "... too busy to accept new streaming request. Will be allowed in X secs".
@@ -107,18 +106,18 @@ this host).
106
107
A new file is introduced: [stream.conf](stream.conf) (to edit it on your system run
108
`/etc/netdata/edit-config stream.conf`). This file holds streaming configuration for both the
110
-sending and the receiving netdata.
109
+sending and the receiving Netdata.
110
112
-API keys are used to authorize the communication of a pair of sending-receiving netdata.
113
-Once the communication is authorized, the sending netdata can push metrics for any number of hosts.
111
+API keys are used to authorize the communication of a pair of sending-receiving Netdata.
112
+Once the communication is authorized, the sending Netdata can push metrics for any number of hosts.
113
114
You can generate an API key with the command `uuidgen`. API keys are just random GUIDs.
116
-You can use the same API key on all your netdata, or use a different API key for any pair of
117
-sending-receiving netdata.
115
+You can use the same API key on all your Netdata, or use a different API key for any pair of
116
+sending-receiving Netdata.
117
118
##### options for the sending node
119
121
-This is the section for the sending netdata. On the receiving node, `[stream].enabled` can be `no`.
120
+This is the section for the sending Netdata. On the receiving node, `[stream].enabled` can be `no`.
121
If it is `yes`, the receiving node will also stream the metrics to another node (i.e. it will be
122
a `proxy`).
123
@@ -170,22 +169,22 @@ You can also add sections like this:
169
```
170
171
The above is the receiver configuration of a single host, at the receiver end. `MACHINE_GUID` is
173
-the unique id the netdata generating the metrics (i.e. the netdata that originally collects
174
-them `/var/lib/netdata/registry/netdata.unique.id`). So, metrics for netdata `A` that pass through
175
-any number of other netdata, will have the same `MACHINE_GUID`.
172
+the unique id the Netdata generating the metrics (i.e. the Netdata that originally collects
173
+them `/var/lib/netdata/registry/netdata.unique.id`). So, metrics for Netdata `A` that pass through
174
+any number of other Netdata, will have the same `MACHINE_GUID`.
175
176
You can also use `default memory mode = dbengine` for an API key or `memory mode = dbengine` for
177
a single host. The additional `page cache size` and `dbengine disk space` configuration options
179
- are inherited from the global netdata configuration.
178
+ are inherited from the global Netdata configuration.
179
180
##### allow from
181
183
-`allow from` settings are [netdata simple patterns](../libnetdata/simple_pattern): string matches
182
+`allow from` settings are [Netdata simple patterns](../libnetdata/simple_pattern): string matches
183
that use `*` as wildcard (any number of times) and a `!` prefix for a negative match.
184
So: `allow from = !10.1.2.3 10.*` will allow all IPs in `10.*` except `10.1.2.3`. The order is
185
important: left to right, the first positive or negative match is used.
186
188
-`allow from` is available in netdata v1.9+
187
+`allow from` is available in Netdata v1.9+
188
189
##### tracing
190
@@ -211,7 +210,7 @@ The receiving end (`proxy` or `master`) logs entries like these:
210
2017-02-25 01:58:14: netdata: INFO : STREAM costa-pc [receive from [10.11.12.11]:33554]: receiving metrics...
211
```
212
214
-For netdata v1.9+, streaming can also be monitored via `access.log`.
213
+For Netdata v1.9+, streaming can also be monitored via `access.log`.
214
215
### Securing streaming communications
216
@@ -302,7 +301,7 @@ Yes | -/force/optional | Yes | yes | The master-slave stream is encrypted.
301
302
## Viewing remote host dashboards, using mirrored databases
303
305
-On any receiving netdata, that maintains remote databases and has its web server enabled,
304
+On any receiving Netdata, that maintains remote databases and has its web server enabled,
305
The node menu will include a list of the mirrored databases.
306
307
@@ -326,11 +325,11 @@ In auto-scaling, all servers are ephemeral, they live for just a few hours. Ever
325
326
So, how can we monitor them? How can we be sure that everything is working as expected on all of them?
327
329
-### The netdata way
328
+### The Netdata way
329
331
-We recently made a significant improvement at the core of netdata to support monitoring such setups.
330
+We recently made a significant improvement at the core of Netdata to support monitoring such setups.
331
333
-Following the netdata way of monitoring, we wanted:
332
+Following the Netdata way of monitoring, we wanted:
333
334
1. **real-time performance monitoring**, collecting **_thousands of metrics per server per second_**, visualized in interactive, automatically created dashboards.
335
2. **real-time alarms**, for all nodes.
@@ -339,18 +338,18 @@ Following the netdata way of monitoring, we wanted:
338
339
### How it works
340
342
-All monitoring solutions, including netdata, work like this:
341
+All monitoring solutions, including Netdata, work like this:
342
343
1. `collect metrics`, from the system and the running applications
344
2. `store metrics`, in a time-series database
345
3. `examine metrics` periodically, for triggering alarms and sending alarm notifications
346
4. `visualize metrics`, so that users can see what exactly is happening
347
349
-netdata used to be self-contained, so that all these functions were handled entirely by each server. The changes we made, allow each netdata to be configured independently for each function. So, each netdata can now act as:
348
+Netdata used to be self-contained, so that all these functions were handled entirely by each server. The changes we made, allow each Netdata to be configured independently for each function. So, each Netdata can now act as:
349
350
- a `self contained system`, much like it used to be.
352
-- a `data collector`, that collects metrics from a host and pushes them to another netdata (with or without a local database and alarms).
353
-- a `proxy`, that receives metrics from other hosts and pushes them immediately to other netdata servers. netdata proxies can also be `store and forward proxies` meaning that they are able to maintain a local database for all metrics passing through them (with or without alarms).
351
+- a `data collector`, that collects metrics from a host and pushes them to another Netdata (with or without a local database and alarms).
352
+- a `proxy`, that receives metrics from other hosts and pushes them immediately to other Netdata servers. Netdata proxies can also be `store and forward proxies` meaning that they are able to maintain a local database for all metrics passing through them (with or without alarms).
353
- a `time-series database` node, where data are kept, alarms are run and queries are served to visualise the metrics.
354
355
### Configuring an auto-scaling setup
@@ -359,7 +358,7 @@ netdata used to be self-contained, so that all these functions were handled enti
358
<img src="https://cloud.githubusercontent.com/assets/2662304/23627468/96daf7ba-02b9-11e7-95ac-1f767dd8dab8.png"/>
359
</p>
360
362
-You need a netdata `master`. This node should not be ephemeral. It will be the node where all ephemeral nodes (let's call them `slaves`) will be sending their metrics.
361
+You need a Netdata `master`. This node should not be ephemeral. It will be the node where all ephemeral nodes (let's call them `slaves`) will be sending their metrics.
362
363
The master will need to authorize the slaves for accepting their metrics. This is done with an API key.
364
@@ -393,11 +392,11 @@ On the master, edit `/etc/netdata/stream.conf` (to edit it on your system run `/
392
393
If you used many API keys, you can add one such section for each API key.
394
396
-When done, restart netdata on the `master` node. It is now ready to receive metrics.
395
+When done, restart Netdata on the `master` node. It is now ready to receive metrics.
396
398
-Note that `health enabled by default = auto` will still trigger `last_collected` alarms, if a connected slave does not exit gracefully. If the netdata running on the slave is
397
+Note that `health enabled by default = auto` will still trigger `last_collected` alarms, if a connected slave does not exit gracefully. If the `netdata` process running on the slave is
398
stopped, it will close the connection to the master, ensuring that no `last_collected` alarms are triggered. For example, a proper container restart would first terminate
400
-the netdata process, but a system power issue would leave the connection open on the master side. In the second case, you will still receive alarms.
399
+the `netdata` process, but a system power issue would leave the connection open on the master side. In the second case, you will still receive alarms.
400
401
#### Configuring the `slaves`
402
@@ -405,7 +404,7 @@ On each of the slaves, edit `/etc/netdata/stream.conf` (to edit it on your syste
404
405
```bash
406
[stream]
408
- # stream metrics to another netdata
407
+ # stream metrics to another Netdata
408
enabled = yes
409
410
# the IP and PORT of the master
@@ -416,7 +415,7 @@ On each of the slaves, edit `/etc/netdata/stream.conf` (to edit it on your syste
415
```
416
*`stream.conf` on slaves, to enable pushing metrics to master at `10.11.12.13:19999`.*
417
419
-Using just the above configuration, the `slaves` will be pushing their metrics to the `master` netdata, but they will still maintain a local database of the metrics and run health checks. To disable them, edit `/etc/netdata/netdata.conf` and set:
418
+Using just the above configuration, the `slaves` will be pushing their metrics to the `master` Netdata, but they will still maintain a local database of the metrics and run health checks. To disable them, edit `/etc/netdata/netdata.conf` and set:
419
420
```bash
421
[global]
@@ -431,9 +430,9 @@ Using just the above configuration, the `slaves` will be pushing their metrics t
430
431
Keep in mind that setting `memory mode = none` will also force `[health].enabled = no` (health checks require access to a local database). But you can keep the database and disable health checks if you need to. You are however sending all the metrics to the master server, which can handle the health checking (`[health].enabled = yes`)
432
434
-#### netdata unique id
433
+#### Netdata unique id
434
436
-The file `/var/lib/netdata/registry/netdata.public.unique.id` contains a random GUID that **uniquely identifies each netdata**. This file is automatically generated, by netdata, the first time it is started and remains unaltered forever.
435
+The file `/var/lib/netdata/registry/netdata.public.unique.id` contains a random GUID that **uniquely identifies each Netdata**. This file is automatically generated, by Netdata, the first time it is started and remains unaltered forever.
436
437
> If you are building an image to be used for automated provisioning of autoscaled VMs, it important to delete that file from the image, so that each instance of your image will generate its own.
438
@@ -469,7 +468,7 @@ and something like this on the slave:
468
469
### Archiving to a time-series database
470
472
-The `master` netdata node can also archive metrics, for all `slaves`, to a time-series database. At the time of this writing, netdata supports:
471
+The `master` Netdata node can also archive metrics, for all `slaves`, to a time-series database. At the time of this writing, Netdata supports:
472
473
- graphite
474
- opentsdb
@@ -477,7 +476,7 @@ The `master` netdata node can also archive metrics, for all `slaves`, to a time-
476
- json document DBs
477
- all the compatibles to the above (e.g. kairosdb, influxdb, etc)
478
480
-Check the netdata [backends documentation](../backends) for configuring this.
479
+Check the Netdata [backends documentation](../backends) for configuring this.
480
481
This is how such a solution will work:
482
@@ -487,7 +486,7 @@ This is how such a solution will work:
486
487
### An advanced setup
488
490
-netdata also supports `proxies` with and without a local database, and data retention can be different between all nodes.
489
+Netdata also supports `proxies` with and without a local database, and data retention can be different between all nodes.
490
491
This means a setup like the following is also possible:
492
@@ -498,16 +497,16 @@ This means a setup like the following is also possible:
497
498
## proxies
499
501
-A proxy is a netdata that is receiving metrics from a netdata, and streams them to another netdata.
500
+A proxy is a Netdata instance that is receiving metrics from a Netdata, and streams them to another Netdata.
501
503
-netdata proxies may or may not maintain a database for the metrics passing through them.
502
+Netdata proxies may or may not maintain a database for the metrics passing through them.
503
When they maintain a database, they can also run health checks (alarms and notifications)
504
for the remote host that is streaming the metrics.
505
507
-To configure a proxy, configure it as a receiving and a sending netdata at the same time,
506
+To configure a proxy, configure it as a receiving and a sending Netdata at the same time,
507
using [stream.conf](stream.conf).
508
510
-The sending side of a netdata proxy, connects and disconnects to the final destination of the
509
+The sending side of a Netdata proxy, connects and disconnects to the final destination of the
510
metrics, following the same pattern of the receiving side.
511
512
For a practical example see [Monitoring ephemeral nodes](#monitoring-ephemeral-nodes).
web/README.md
+1
-1
@@ -18,7 +18,7 @@ If you change that file, your changes will be overwritten when Netdata is update
18
19
You have to copy the example file under a new name, so that it will not be overwritten with Netdata updates.
20
21
-To configure your info file set in netdata.conf:
21
+To configure your info file set in `netdata.conf`:
22
23
```
24
[web]
web/api/README.md
+2
-2
@@ -2,13 +2,13 @@
2
3
## Netdata REST API
4
5
-The complete documentation of the netdata API is available at the **[Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/netdata/netdata/master/web/api/netdata-swagger.yaml)**.
5
+The complete documentation of the Netdata API is available at the **[Swagger Editor](https://editor.swagger.io/?url=https://raw.githubusercontent.com/netdata/netdata/master/web/api/netdata-swagger.yaml)**.
6
7
If your prefer it over the Swagger Editor, you can also use **[Swagger UI](https://registry.my-netdata.io/swagger/#!/default/get_data)**. This however does not provide all the information available.
8
9
## Google charts API
10
11
-netdata is a [Google Visualization API datatable and datasource provider](https://developers.google.com/chart/interactive/docs/reference), so it can directly be used with [Google Charts](https://developers.google.com/chart/interactive/docs/).
11
+Netdata is a [Google Visualization API datatable and datasource provider](https://developers.google.com/chart/interactive/docs/reference), so it can directly be used with [Google Charts](https://developers.google.com/chart/interactive/docs/).
12
13
Check this [single chart, jsfiddle example](https://jsfiddle.net/ktsaou/ensu4uws/9/):
14
web/api/badges/README.md
+19
-19
@@ -6,11 +6,11 @@ Netdata can generate badges for any chart and any dimension at any time-frame. B
6
7
**Netdata badges are powerful**!
8
9
-Given that netdata collects from **1.000** to **5.000** metrics per server (depending on the number of network interfaces, disks, cpu cores, applications running, users logged in, containers running, etc) and that netdata already has data reduction/aggregation functions embedded, the badges can be quite powerful.
9
+Given that Netdata collects from **1.000** to **5.000** metrics per server (depending on the number of network interfaces, disks, cpu cores, applications running, users logged in, containers running, etc) and that Netdata already has data reduction/aggregation functions embedded, the badges can be quite powerful.
10
11
For each metric/dimension and for arbitrary time-frames badges can show **min**, **max** or **average** value, but also **sum** or **incremental-sum** to have their **volume**.
12
13
-For example, there is [a chart in netdata that shows the current requests/s of nginx](http://london.my-netdata.io/#nginx_local_nginx). Using this chart alone we can show the following badges (we could add more time-frames, like **today**, **yesterday**, etc):
13
+For example, there is [a chart in Netdata that shows the current requests/s of nginx](http://london.my-netdata.io/#nginx_local_nginx). Using this chart alone we can show the following badges (we could add more time-frames, like **today**, **yesterday**, etc):
14
15
<a href="https://registry.my-netdata.io/#nginx_local_nginx"><img src="https://registry.my-netdata.io/api/v1/badge.svg?chart=nginx_local.connections&dimensions=active&value_color=grey:null%7Cblue&label=nginx%20active%20connections%20now&units=null&precision=0"/></a> <a href="https://registry.my-netdata.io/#nginx_local_nginx"><img src="https://registry.my-netdata.io/api/v1/badge.svg?chart=nginx_local.connections&dimensions=active&after=-3600&value_color=orange&label=last%20hour%20average&units=null&options=unaligned&precision=0"/></a> <a href="https://registry.my-netdata.io/#nginx_local_nginx"><img src="https://registry.my-netdata.io/api/v1/badge.svg?chart=nginx_local.connections&dimensions=active&group=max&after=-3600&value_color=red&label=last%20hour%20max&units=null&options=unaligned&precision=0"/></a>
16
@@ -18,9 +18,9 @@ Similarly, there is [a chart that shows outbound bandwidth per class](http://lon
18
19
<a href="https://registry.my-netdata.io/#tc_eth0"><img src="https://registry.my-netdata.io/api/v1/badge.svg?chart=tc.world_out&dimensions=web_server&value_color=green&label=web%20server%20sends%20now&units=kbps"/></a> <a href="https://registry.my-netdata.io/#tc_eth0"><img src="https://registry.my-netdata.io/api/v1/badge.svg?chart=tc.world_out&dimensions=web_server&after=-86400&options=unaligned&group=sum÷=8388608&value_color=blue&label=web%20server%20sent%20today&units=GB"/></a>
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.
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](../../../registry/)):
23
+Let's see a few more badge examples (they come from the [Netdata registry](../../../registry/)):
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
@@ -36,7 +36,7 @@ Let's see a few more badge examples (they come from the [netdata registry](../..
36
37
---
38
39
-> So, every single line on the charts of a [netdata dashboard](http://london.my-netdata.io/), can become a badge and this badge can calculate **average**, **min**, **max**, or **volume** for any time-frame! And you can also vary the badge color using conditions on the calculated value.
39
+> So, every single line on the charts of a [Netdata dashboard](http://london.my-netdata.io/), can become a badge and this badge can calculate **average**, **min**, **max**, or **volume** for any time-frame! And you can also vary the badge color using conditions on the calculated value.
40
41
---
42
@@ -44,13 +44,13 @@ Let's see a few more badge examples (they come from the [netdata registry](../..
44
45
The basic URL is `http://your.netdata:19999/api/v1/badge.svg?option1&option2&option3&...`.
46
47
-Here is what you can put for `options` (these are standard netdata API options):
47
+Here is what you can put for `options` (these are standard Netdata API options):
48
49
- `chart=CHART.NAME`
50
51
The chart to get the values from.
52
53
- **This is the only parameter required** and with just this parameter, netdata will return the sum of the latest values of all chart dimensions.
53
+ **This is the only parameter required** and with just this parameter, Netdata will return the sum of the latest values of all chart dimensions.
54
55
Example:
56
@@ -76,7 +76,7 @@ Here is what you can put for `options` (these are standard netdata API options):
76
77
- `dimensions=DIMENSION1|DIMENSION2|...`
78
79
- The dimensions of the chart to use. If you don't set any dimension, all will be used. When multiple dimensions are used, netdata will sum their values. You can append `options=absolute` if you want this sum to convert all values to positive before adding them.
79
+ The dimensions of the chart to use. If you don't set any dimension, all will be used. When multiple dimensions are used, Netdata will sum their values. You can append `options=absolute` if you want this sum to convert all values to positive before adding them.
80
81
Pipes in HTML have to escaped with `%7C`.
82
@@ -132,7 +132,7 @@ Here is what you can put for `options` (these are standard netdata API options):
132
133
- `group=min` or `group=max` or `group=average` (the default) or `group=sum` or `group=incremental-sum`
134
135
- If netdata will have to reduce (aggregate) the data to calculate the value, which aggregation method to use.
135
+ If Netdata will have to reduce (aggregate) the data to calculate the value, which aggregation method to use.
136
137
- `max` will find the max value for the timeframe. This works on both positive and negative dimensions. It will find the most extreme value.
138
@@ -156,7 +156,7 @@ Here is what you can put for `options` (these are standard netdata API options):
156
157
- `min2max`, when multiple dimensions are given, do not sum them, but take their `max - min`.
158
159
- - `unaligned`, when data are reduced / aggregated (e.g. the request is about the average of the last minute, or hour), netdata by default aligns them so that the charts will have a constant shape (so average per minute returns always XX:XX:00 - XX:XX:59). Setting the `unaligned` option, netdata will aggregate data without any alignment, so if the request is for 60 seconds, it will aggregate the latest 60 seconds of collected data.
159
+ - `unaligned`, when data are reduced / aggregated (e.g. the request is about the average of the last minute, or hour), Netdata by default aligns them so that the charts will have a constant shape (so average per minute returns always XX:XX:00 - XX:XX:59). Setting the `unaligned` option, Netdata will aggregate data without any alignment, so if the request is for 60 seconds, it will aggregate the latest 60 seconds of collected data.
160
161
These are options dedicated to badges:
162
@@ -166,9 +166,9 @@ These are options dedicated to badges:
166
167
- `units=TEXT`
168
169
- The units of the badge. If you want to put a `/`, please put a `\`. This is because netdata allows badges parameters to be given as path in URL, instead of query string. You can also use `null` or `empty` to show it without any units.
169
+ The units of the badge. If you want to put a `/`, please put a `\`. This is because Netdata allows badges parameters to be given as path in URL, instead of query string. You can also use `null` or `empty` to show it without any units.
170
171
- The units `seconds`, `minutes` and `hours` trigger special formatting. The value has to be in this unit, and netdata will automatically change it to show a more pretty duration.
171
+ The units `seconds`, `minutes` and `hours` trigger special formatting. The value has to be in this unit, and Netdata will automatically change it to show a more pretty duration.
172
173
- `multiply=NUMBER`
174
@@ -180,7 +180,7 @@ These are options dedicated to badges:
180
181
- `label_color=COLOR`
182
183
- The color of the label (the left part). You can use any HTML color, include `#NNN` and `#NNNNNN`. The following colors are defined in netdata (and you can use them by name): `green`, `brightgreen`, `yellow`, `yellowgreen`, `orange`, `red`, `blue`, `grey`, `gray`, `lightgrey`, `lightgray`. These are taken from https://github.com/badges/shields so they are compatible with standard badges.
183
+ The color of the label (the left part). You can use any HTML color, include `#NNN` and `#NNNNNN`. The following colors are defined in Netdata (and you can use them by name): `green`, `brightgreen`, `yellow`, `yellowgreen`, `orange`, `red`, `blue`, `grey`, `gray`, `lightgrey`, `lightgray`. These are taken from https://github.com/badges/shields so they are compatible with standard badges.
184
185
- `value_color=COLOR:null|COLOR<VALUE|COLOR>VALUE|COLOR>=VALUE|COLOR<=VALUE|...`
186
@@ -188,13 +188,13 @@ These are options dedicated to badges:
188
189
Example: `value_color=grey:null|green<10|yellow<100|orange<1000|blue<10000|red`
190
191
- The above will set `grey` if no value exists (not collected within the `gap when lost iterations above` in netdata.conf for the chart), `green` if the value is less than 10, `yellow` if the value is less than 100, etc up to `red` which will be used if no other conditions match.
191
+ The above will set `grey` if no value exists (not collected within the `gap when lost iterations above` in `netdata.conf` for the chart), `green` if the value is less than 10, `yellow` if the value is less than 100, etc up to `red` which will be used if no other conditions match.
192
193
The supported operators are `<`, `>`, `<=`, `>=`, `=` (or `:`) and `!=` (or `<>`).
194
195
- `precision=NUMBER`
196
197
- The number of decimal digits of the value. By default netdata will add:
197
+ The number of decimal digits of the value. By default Netdata will add:
198
199
- no decimal digits for values > 1000
200
- 1 decimal digit for values > 100
@@ -217,7 +217,7 @@ These are options dedicated to badges:
217
218
- `refresh=auto` or `refresh=SECONDS`
219
220
- This option enables auto-refreshing of images. netdata will send the HTTP header `Refresh: SECONDS` to the web browser, thus requesting automatic refresh of the images at regular intervals.
220
+ This option enables auto-refreshing of images. Netdata will send the HTTP header `Refresh: SECONDS` to the web browser, thus requesting automatic refresh of the images at regular intervals.
221
222
`auto` will calculate the proper `SECONDS` to avoid unnecessary refreshes. If `SECONDS` is zero, this feature is disabled (it is also disabled by default).
223
@@ -227,7 +227,7 @@ These are options dedicated to badges:
227
<embed src="BADGE_URL" type="image/svg+xml" height="20" />
228
```
229
230
- Another way is to use javascript to auto-refresh them. You can auto-refresh all the netdata badges on a page using javascript. You have to add a class to all the netdata badges, like this `<img class="netdata-badge" src="..."/>`. Then add this javascript code to your page (it requires jquery):
230
+ Another way is to use javascript to auto-refresh them. You can auto-refresh all the Netdata badges on a page using javascript. You have to add a class to all the Netdata badges, like this `<img class="netdata-badge" src="..."/>`. Then add this javascript code to your page (it requires jquery):
231
232
```html
233
<script>
@@ -264,9 +264,9 @@ character|name|escape sequence
264
## FAQ
265
266
#### Is it fast?
267
-On modern hardware, netdata can generate about **2.000 badges per second per core**, before noticing any delays. It generates a badge in about half a millisecond!
267
+On modern hardware, Netdata can generate about **2.000 badges per second per core**, before noticing any delays. It generates a badge in about half a millisecond!
268
269
-Of course these timing are for badges that use recent data. If you need badges that do calculations over long durations (a day, or more), timing will differ. netdata logs its timings at its `access.log`, so take a look there before adding a heavy badge on a busy web site. Of course, you can cache such badges or have a cron job get them from netdata and save them at your web server at regular intervals.
269
+Of course these timing are for badges that use recent data. If you need badges that do calculations over long durations (a day, or more), timing will differ. Netdata logs its timings at its `access.log`, so take a look there before adding a heavy badge on a busy web site. Of course, you can cache such badges or have a cron job get them from Netdata and save them at your web server at regular intervals.
270
271
272
#### Embedding badges in github
web/api/exporters/prometheus/README.md
+1
-1
@@ -1,5 +1,5 @@
1
# prometheus exporter
2
3
-The prometheus exporter for netdata is located at the [backends section for prometheus](../../../../backends/prometheus).
3
+The prometheus exporter for Netdata is located at the [backends section for prometheus](../../../../backends/prometheus).
4
5
[]()
web/api/exporters/shell/README.md
+4
-4
@@ -1,18 +1,18 @@
1
# shell exporter
2
3
-Shell scripts can now query netdata:
3
+Shell scripts can now query Netdata:
4
5
```sh
6
eval "$(curl -s 'http://localhost:19999/api/v1/allmetrics')"
7
```
8
9
-after this command, all the netdata metrics are exposed to shell. Check:
9
+after this command, all the Netdata metrics are exposed to shell. Check:
10
11
```sh
12
# source the metrics
13
eval "$(curl -s 'http://localhost:19999/api/v1/allmetrics')"
14
15
-# let's see if there are variables exposed by netdata for system.cpu
15
+# let's see if there are variables exposed by Netdata for system.cpu
16
set | grep "^NETDATA_SYSTEM_CPU"
17
18
NETDATA_SYSTEM_CPU_GUEST=0
@@ -50,7 +50,7 @@ user 0m0,000s
50
sys 0m0,007s
51
52
# it is...
53
-# 0.07 seconds for curl to be loaded, connect to netdata and fetch the response back...
53
+# 0.07 seconds for curl to be loaded, connect to Netdata and fetch the response back...
54
```
55
56
The `_VISIBLETOTAL` variable sums up all the dimensions of each chart.
web/api/formatters/README.md
+2
-2
@@ -59,9 +59,9 @@ This is such an object:
59
## Downloading data query result files
60
61
Following the [Google Visualization Provider guidelines](https://developers.google.com/chart/interactive/docs/dev/implementing_data_source),
62
-netdata supports parsing `tqx` options.
62
+Netdata supports parsing `tqx` options.
63
64
-Using these options, any netdata data query can instruct the web browser to download
64
+Using these options, any Netdata data query can instruct the web browser to download
65
the result and save it under a given filename.
66
67
For example, to download a CSV file with CPU utilization of the last hour,
web/api/health/README.md
+8
-8
@@ -45,11 +45,11 @@ The following will return an SVG badge of the alarm named `NAME`, attached to th
45
## Health Management API
46
47
Netdata v1.12 and beyond provides a command API to control health checks and notifications at runtime. The feature is especially useful for maintenance periods, during which you receive meaningless alarms.
48
-From Netdata v1.16.0 and beyond, the configuration controlled via the API commands is [persisted across netdata restarts](#persistence).
48
+From Netdata v1.16.0 and beyond, the configuration controlled via the API commands is [persisted across Netdata restarts](#persistence).
49
50
Specifically, the API allows you to:
51
- Disable health checks completely. Alarm conditions will not be evaluated at all and no entries will be added to the alarm log.
52
- - Silence alarm notifications. Alarm conditions will be evaluated, the alarms will appear in the log and the netdata UI will show the alarms as active, but no notifications will be sent.
52
+ - Silence alarm notifications. Alarm conditions will be evaluated, the alarms will appear in the log and the Netdata UI will show the alarms as active, but no notifications will be sent.
53
- Disable or Silence specific alarms that match selectors on alarm/template name, chart, context, host and family.
54
55
The API is available by default, but it is protected by an `api authorization token` that is stored in the file you will see in the following entry of `http://localhost:19999/netdata.conf`:
@@ -65,9 +65,9 @@ You can access the API via GET requests, by adding the bearer token to an `Autho
65
curl "http://myserver/api/v1/manage/health?cmd=RESET" -H "X-Auth-Token: Mytoken"
66
```
67
68
-By default access to the health management API is only allowed from `localhost`. Accessing the API from anything else will return a 403 error with the message `You are not allowed to access this resource.`. You can change permissions by editing the `allow management from` variable in netdata.conf within the [web] section. See [web server access lists](../../server/#access-lists) for more information.
68
+By default access to the health management API is only allowed from `localhost`. Accessing the API from anything else will return a 403 error with the message `You are not allowed to access this resource.`. You can change permissions by editing the `allow management from` variable in `netdata.conf` within the [web] section. See [web server access lists](../../server/#access-lists) for more information.
69
70
-The command `RESET` just returns netdata to the default operation, with all health checks and notifications enabled.
70
+The command `RESET` just returns Netdata to the default operation, with all health checks and notifications enabled.
71
If you've configured and entered your token correclty, you should see the plain text response `All health checks and notifications are enabled`.
72
73
### Disable or silence all alarms
@@ -85,7 +85,7 @@ If you want the health checks to be running but to not receive any notifications
85
curl "http://myserver/api/v1/manage/health?cmd=SILENCE ALL" -H "X-Auth-Token: Mytoken"
86
```
87
88
-Alarms may then still be raised and logged in netdata, so you'll be able to see them via the UI.
88
+Alarms may then still be raised and logged in Netdata, so you'll be able to see them via the UI.
89
90
Regardless of the option you choose, at the end of your maintenance period you revert to the normal state via the RESET command.
91
@@ -118,7 +118,7 @@ curl "http://myserver/api/v1/manage/health?cmd=SILENCE&context=load" -H "X-Auth-
118
119
#### Selection criteria
120
121
-The `selection criteria` are key/value pairs, in the format `key : value`, where value is a netdata [simple pattern](../../../libnetdata/simple_pattern/). This means that you can create very powerful selectors (you will rarely need more than one or two).
121
+The `selection criteria` are key/value pairs, in the format `key : value`, where value is a Netdata [simple pattern](../../../libnetdata/simple_pattern/). This means that you can create very powerful selectors (you will rarely need more than one or two).
122
123
The accepted keys for the `selection criteria` are the following:
124
- `alarm` : The expression provided will match both `alarm` and `template` names.
@@ -149,7 +149,7 @@ http://localhost/api/v1/manage/health?families=cpu1 cpu2
149
150
### List silencers
151
152
-The command `LIST` was added in netdata v1.16.0 and returns a JSON with the current status of the silencers.
152
+The command `LIST` was added in Netdata v1.16.0 and returns a JSON with the current status of the silencers.
153
154
```
155
curl "http://myserver/api/v1/manage/health?cmd=LIST" -H "X-Auth-Token: Mytoken"
@@ -200,7 +200,7 @@ json
200
201
### Persistence
202
203
-From netdata v1.16.0 and beyond, the silencers configuration is persisted to disk and loaded when netdata starts.
203
+From Netdata v1.16.0 and beyond, the silencers configuration is persisted to disk and loaded when Netdata starts.
204
The JSON string returned by the [LIST command](#list-silencers) is automatically saved to the `silencers file`, every time a command alters the silencers configuration.
205
The file's location is configurable in `netdata.conf`. The default is shown below:
206
web/api/queries/README.md
+7
-7
@@ -54,7 +54,7 @@ There are 2 uses that enable this feature:
54
For example, for a time-frame of 10 minutes, the database has 600 points (1/sec),
55
while the caller requested these 10 minutes to be expressed in 200 points.
56
57
- This feature is used by netdata dashboards when you zoom-out the charts.
57
+ This feature is used by Netdata dashboards when you zoom-out the charts.
58
The dashboard is requesting the number of points the user's screen has.
59
This saves bandwidth and speeds up the browser (fewer points to evaluate for drawing the charts).
60
@@ -69,7 +69,7 @@ an integer. Keep in mind the query engine may shift `after` if required. See als
69
70
#### Time-frame Alignment
71
72
-Alignment is a very important aspect of netdata queries. Without it, the animated
72
+Alignment is a very important aspect of Netdata queries. Without it, the animated
73
charts on the dashboards would constantly [change shape](#example) during incremental updates.
74
75
To provide consistent grouping through time, the query engine (by default) aligns
@@ -111,7 +111,7 @@ and they group the values every `group points`.
111
-  applies Holt-Winters double exponential smoothing
112
-  finds the difference of the last vs the first value
113
114
-The examples shown above, are live information from the `successful` web requests of the global netdata registry.
114
+The examples shown above, are live information from the `successful` web requests of the global Netdata registry.
115
116
## Further processing
117
@@ -129,7 +129,7 @@ the result.
129
130
## Example
131
132
-When netdata is reducing metrics, it tries to return always the same boundaries. So, if we want 10s averages, it will always return points starting at a `unix timestamp % 10 = 0`.
132
+When Netdata is reducing metrics, it tries to return always the same boundaries. So, if we want 10s averages, it will always return points starting at a `unix timestamp % 10 = 0`.
133
134
Let's see why this is needed, by looking at the error case.
135
@@ -143,7 +143,7 @@ Assume we have 5 points:
143
| 00:04 | 4 |
144
| 00:05 | 5 |
145
146
-At 00:04 you ask for 2 points for 4 seconds in the past. So `group = 2`. netdata would return:
146
+At 00:04 you ask for 2 points for 4 seconds in the past. So `group = 2`. Netdata would return:
147
148
| point | time | value |
149
| :-: | :-: | :-: |
@@ -159,9 +159,9 @@ A second later the chart is to be refreshed, and makes again the same request at
159
160
**Wait a moment!** The chart was shifted just one point and it changed value! Point 2 was 3.5 and when shifted to point 1 is 2.5! If you see this in a chart, it's a mess. The charts change shape constantly.
161
162
-For this reason, netdata always aligns the data it returns to the `group`.
162
+For this reason, Netdata always aligns the data it returns to the `group`.
163
164
-When you request `points=1`, netdata understands that you need 1 point for the whole database, so `group = 3600`. Then it tries to find the starting point which would be `timestamp % 3600 = 0` Within a database of 3600 seconds, there is one such point for sure. Then it tries to find the average of 3600 points. But, most probably it will not find 3600 of them (for just 1 out of 3600 seconds this query will return something).
164
+When you request `points=1`, Netdata understands that you need 1 point for the whole database, so `group = 3600`. Then it tries to find the starting point which would be `timestamp % 3600 = 0` Within a database of 3600 seconds, there is one such point for sure. Then it tries to find the average of 3600 points. But, most probably it will not find 3600 of them (for just 1 out of 3600 seconds this query will return something).
165
166
So, the proper way to query the database is to also set at least `after`. The following call will returns 1 point for the last complete 10-second duration (it starts at `timestamp % 10 = 0`):
167
web/gui/confluence/README.md
+13
-13
@@ -1,6 +1,6 @@
1
# Atlassian Confluence dashboards
2
3
-With netdata you can build **live, interactive, monitoring dashboards** directly on Atlassian's **Confluence** pages.
3
+With Netdata you can build **live, interactive, monitoring dashboards** directly on Atlassian's **Confluence** pages.
4
5
I see you already asking "why should I do this?"
6
@@ -12,9 +12,9 @@ Well... think a bit of it.... confluence is the perfect place for something like
12
13
3. You can create monitoring pages for very specific purposes, hiding all the information that is too detailed for most users, or explaining in detail things that are difficult for them to understand.
14
15
-So, what can we expect? What can netdata do on confluence?
15
+So, what can we expect? What can Netdata do on confluence?
16
17
-You will be surprised! **Everything a netdata dashboard does!**. Example:
17
+You will be surprised! **Everything a Netdata dashboard does!**. Example:
18
19
20
@@ -24,9 +24,9 @@ Let me show you how.
24
25
### Before you begin
26
27
-Most likely your confluence is accessible via HTTPS. So, you need to proxy your netdata servers via an apache or nginx to make them HTTPS too. If your Confluence is HTTPS but your netdata are not, you will not be able to fetch the netdata content from the confluence page. The netdata wiki has many examples for proxying netdata through another web server.
27
+Most likely your confluence is accessible via HTTPS. So, you need to proxy your Netdata servers via an apache or nginx to make them HTTPS too. If your Confluence is HTTPS but your Netdata are not, you will not be able to fetch the Netdata content from the confluence page. The Netdata wiki has many examples for proxying Netdata through another web server.
28
29
-> So, make sure netdata and confluence can be accessed with the same protocol (**http**, or **https**).
29
+> So, make sure Netdata and Confluence can be accessed with the same protocol (**http**, or **https**).
30
31
For our example, I will use these 2 servers:
32
@@ -64,7 +64,7 @@ like this (type `{html` for the html box to appear - you need the confluence htm
64
65
### Add a few badges
66
67
-Then, go to your netdata and copy an alarm badge (the `<embed>` version of it):
67
+Then, go to your Netdata and copy an alarm badge (the `<embed>` version of it):
68
69
70
@@ -78,7 +78,7 @@ Hit **update** and you will get this:
78
79
This badge is now auto-refreshing. It will update itself based on the update frequency of the alarm.
80
81
-> Keep in mind you can add badges with custom netdata queries too. netdata automatically creates badges for all the alarms, but every chart, every dimension on every chart, can be used for a badge. And netdata badges are quite powerful! Check [Creating Badges](../../api/badges/) for more information on badges.
81
+> Keep in mind you can add badges with custom Netdata queries too. Netdata automatically creates badges for all the alarms, but every chart, every dimension on every chart, can be used for a badge. And Netdata badges are quite powerful! Check [Creating Badges](../../api/badges/) for more information on badges.
82
83
So, let's create a table and add this badge for both our web servers:
84
@@ -88,7 +88,7 @@ Now we get this:
88
89
90
91
-### Add a netdata chart
91
+### Add a Netdata chart
92
93
The simplest form of a chart is this (it adds the chart `web_log_nginx_netdata.response_statuses`, using 100% of the width, 150px height, and the last 10 minutes of data):
94
@@ -110,7 +110,7 @@ And you will get this:
110
111
112
113
-> This chart is **alive**, fully interactive. You can drag it, pan it, zoom it, etc like you do on netdata dashboards!
113
+> This chart is **alive**, fully interactive. You can drag it, pan it, zoom it, etc like you do on Netdata dashboards!
114
115
Of course this too big. We need something smaller to add inside the table. Let's try this:
116
@@ -128,7 +128,7 @@ Of course this too big. We need something smaller to add inside the table. Let's
128
></div>
129
```
130
131
-The chart name is shown on all netdata charts, so just copy it from a netdata dashboard.
131
+The chart name is shown on all Netdata charts, so just copy it from a Netdata dashboard.
132
133
We will fetch the same chart from both servers. To define the server we also added `data-host=` with the URL of each server, like this (we also added `<br/>` for a newline between the badge and the chart):
134
@@ -138,7 +138,7 @@ Which gives us this:
138
139
140
141
-Note the color difference. This is because netdata automatically hides dimensions that are just zero (the frankfurt server has only successful requests). To instruct netdata to disable this feature, we need to add another html fragment at the bottom of the page (make sure this is added after loading `dashboard.js`). So we edit the first block we added, and append a new `<script>` section to it:
141
+Note the color difference. This is because Netdata automatically hides dimensions that are just zero (the frankfurt server has only successful requests). To instruct Netdata to disable this feature, we need to add another html fragment at the bottom of the page (make sure this is added after loading `dashboard.js`). So we edit the first block we added, and append a new `<script>` section to it:
142
143
144
```html
@@ -165,7 +165,7 @@ Now they match:
165
166
#### more options
167
168
-If you want to change the colors append `data-colors="#001122 #334455 #667788"`. The colors will be used for the dimensions top to bottom, as shown on a netdata dashboard. Keep in mind the default netdata dashboards hide by default all dimensions that are just zero, so enable them at the dashboard settings to see them all.
168
+If you want to change the colors append `data-colors="#001122 #334455 #667788"`. The colors will be used for the dimensions top to bottom, as shown on a Netdata dashboard. Keep in mind the default Netdata dashboards hide by default all dimensions that are just zero, so enable them at the dashboard settings to see them all.
169
170
You can get a percentage chart, by adding these on these charts:
171
@@ -177,7 +177,7 @@ You can get a percentage chart, by adding these on these charts:
177
data-units="%"
178
```
179
180
-The first line instructs netdata to calculate the percentage of each dimension, the second strips any fractional digits, the third instructs the charting library to size the chart from 0 to 100, the next one instructs it to include 0 in the chart and the last changes the units of the chart to `%`. This is how it will look:
180
+The first line instructs Netdata to calculate the percentage of each dimension, the second strips any fractional digits, the third instructs the charting library to size the chart from 0 to 100, the next one instructs it to include 0 in the chart and the last changes the units of the chart to `%`. This is how it will look:
181
182
183
web/gui/custom/README.md
+20
-20
@@ -4,10 +4,10 @@ You can:
4
5
- create your own dashboards using simple HTML (no javascript is required for basic dashboards)
6
- utilizing any or all of the available chart libraries, on the same dashboard
7
-- using data from one or more netdata servers, on the same dashboard
7
+- using data from one or more Netdata servers, on the same dashboard
8
- host your dashboard HTML page on any web server, anywhere
9
10
-netdata charts can also be added to existing web pages.
10
+Netdata charts can also be added to existing web pages.
11
12
Check this **[very simple working example of a custom dashboard](http://netdata.firehol.org/demo.html)**, and its **[html source](../demo.html)**.
13
@@ -21,7 +21,7 @@ If you plan to put the dashboard on TV, check **[tv.html](../tv.html)**. This is
21
22
## Web directory
23
24
-All of the mentioned examples are available on your local netdata installation (e.g. `http://myhost:19999/dashboard.html`). The default web root directory with the HTML and JS code is `/usr/share/netdata/web`. The main dashboard is also in that directory and called `index.html`.
24
+All of the mentioned examples are available on your local Netdata installation (e.g. `http://myhost:19999/dashboard.html`). The default web root directory with the HTML and JS code is `/usr/share/netdata/web`. The main dashboard is also in that directory and called `index.html`.
25
Note: index.html has a different syntax. Don't use it as a template for simple custom dashboards.
26
27
## Example empty dashboard
@@ -55,9 +55,9 @@ If you need to create a new dashboard on an empty page, we suggest the following
55
56
## dashboard.js
57
58
-To add netdata charts to any web page (dedicated to netdata or not), you need to include the `/dashboard.js` file of a netdata server.
58
+To add Netdata charts to any web page (dedicated to Netdata or not), you need to include the `/dashboard.js` file of a Netdata server.
59
60
-For example, if your netdata server listens at `http://box:19999/`, you will need to add the following to the `head` section of your web page:
60
+For example, if your Netdata server listens at `http://box:19999/`, you will need to add the following to the `head` section of your web page:
61
62
```html
63
<script type="text/javascript" src="http://box:19999/dashboard.js"></script>
@@ -67,7 +67,7 @@ For example, if your netdata server listens at `http://box:19999/`, you will nee
67
68
`dashboard.js` will automatically load the following:
69
70
-1. `dashboard.css`, required for the netdata charts
70
+1. `dashboard.css`, required for the Netdata charts
71
72
2. `jquery.min.js`, (only if jquery is not already loaded for this web page)
73
@@ -117,11 +117,11 @@ NETDATA.pause(function() {
117
});
118
```
119
120
-### The default netdata server
120
+### The default Netdata server
121
122
-`dashboard.js` will attempt to auto-detect the URL of the netdata server it is loaded from, and set this server as the default netdata server for all charts.
122
+`dashboard.js` will attempt to auto-detect the URL of the Netdata server it is loaded from, and set this server as the default Netdata server for all charts.
123
124
-If you need to set any other URL as the default netdata server for all charts that do not specify a netdata server, add this before loading `dashboard.js`:
124
+If you need to set any other URL as the default Netdata server for all charts that do not specify a Netdata server, add this before loading `dashboard.js`:
125
126
```html
127
<script type="text/javascript">var netdataServer = "http://your.netdata.server:19999";</script>
@@ -135,7 +135,7 @@ To add charts, you need to add a `div` for each of them. Each of these `div` ele
135
136
### The chart unique ID
137
138
-The unique ID of a chart is shown at the title of the chart of the default netdata dashboard. You can also find all the charts available at your netdata server with this URL: `http://your.netdata.server:19999/api/v1/charts` ([example](http://netdata.firehol.org/api/v1/charts)).
138
+The unique ID of a chart is shown at the title of the chart of the default Netdata dashboard. You can also find all the charts available at your Netdata server with this URL: `http://your.netdata.server:19999/api/v1/charts` ([example](http://netdata.firehol.org/api/v1/charts)).
139
140
To specify the unique id, use this:
141
@@ -182,7 +182,7 @@ If you want `dashboard.js` to remember permanently (browser local storage) the d
182
183
### Netdata server
184
185
-Each chart can get data from a different netdata server. You can give per chart the netdata server using:
185
+Each chart can get data from a different Netdata server. You can give per chart the Netdata server using:
186
187
```html
188
<div data-netdata="unique.id"
@@ -221,9 +221,9 @@ Each chart library may support more chart-library specific settings. Please refe
221
222
For the time-frame requested, `dashboard.js` will use the chart dimensions and the settings of the chart library to find out how many data points it can show.
223
224
-For example, most line chart libraries are using 3 pixels per data point. If the chart shows 10 minutes of data (600 seconds), its update frequency is 1 second, and the chart width is 1800 pixels, then `dashboard.js` will request from the netdata server: 10 minutes of data, represented in 600 points, and the chart will be refreshed per second. If the user resizes the window so that the chart becomes 600 pixels wide, then `dashboard.js` will request the same 10 minutes of data, represented in 200 points and the chart will be refreshed once every 3 seconds.
224
+For example, most line chart libraries are using 3 pixels per data point. If the chart shows 10 minutes of data (600 seconds), its update frequency is 1 second, and the chart width is 1800 pixels, then `dashboard.js` will request from the Netdata server: 10 minutes of data, represented in 600 points, and the chart will be refreshed per second. If the user resizes the window so that the chart becomes 600 pixels wide, then `dashboard.js` will request the same 10 minutes of data, represented in 200 points and the chart will be refreshed once every 3 seconds.
225
226
-If you need to have a fixed number of points in the data source retrieved from the netdata server, you can set:
226
+If you need to have a fixed number of points in the data source retrieved from the Netdata server, you can set:
227
228
```html
229
<div data-netdata="unique.id"
@@ -245,7 +245,7 @@ Where `PIXELS_PER_POINT` is the number of pixels each data point should occupy.
245
246
### Data grouping method
247
248
-Netdata supports **average** (the default), **sum** and **max** grouping methods. The grouping method is used when the netdata server is requested to return fewer points for a time-frame, compared to the number of points available.
248
+Netdata supports **average** (the default), **sum** and **max** grouping methods. The grouping method is used when the Netdata server is requested to return fewer points for a time-frame, compared to the number of points available.
249
250
You can give it per chart, using:
251
@@ -272,7 +272,7 @@ Use 60 for `/minute`, 3600 for `/hour`, 86400 for `/day` (provided you have that
272
273
- The `data-gtime` setting does not change the units of the chart. You have to change them yourself with `data-units`.
274
- This works only for `data-method="average"`.
275
-- netdata may aggregate multiple points to satisfy the `data-points` setting. For example, you request `per minute` but the requested number of points to be returned are not enough to report every single minute. In this case netdata will sum the `per second` raw data of the database to find the `per minute` for every single minute and then **average** them to find the **average per minute rate of every X minutes**. So, it works as if the data collection frequency was per minute.
275
+- Netdata may aggregate multiple points to satisfy the `data-points` setting. For example, you request `per minute` but the requested number of points to be returned are not enough to report every single minute. In this case Netdata will sum the `per second` raw data of the database to find the `per minute` for every single minute and then **average** them to find the **average per minute rate of every X minutes**. So, it works as if the data collection frequency was per minute.
276
277
### Selecting dimensions
278
@@ -285,7 +285,7 @@ You can select specific dimensions using this:
285
></div>
286
```
287
288
-netdata supports coma (` , `) or pipe (` | `) separated [simple patterns](../../../libnetdata/simple_pattern/) for dimensions. By default it searches for both dimension IDs and dimension NAMEs. You can control the target of the match with: `data-append-options="match-ids"` or `data-append-options="match-names"`. Spaces in `data-dimensions=""` are matched in the dimension names and IDs.
288
+Netdata supports coma (` , `) or pipe (` | `) separated [simple patterns](../../../libnetdata/simple_pattern/) for dimensions. By default it searches for both dimension IDs and dimension NAMEs. You can control the target of the match with: `data-append-options="match-ids"` or `data-append-options="match-names"`. Spaces in `data-dimensions=""` are matched in the dimension names and IDs.
289
290
### Chart title
291
@@ -344,7 +344,7 @@ On charts that by default have a legend managed by `dashboard.js` you can remove
344
345
### API options
346
347
-You can append netdata **[REST API v1](../../api)** data options, using this:
347
+You can append Netdata **[REST API v1](../../api)** data options, using this:
348
349
```html
350
<div data-netdata="unique.id"
@@ -356,7 +356,7 @@ A few useful options are:
356
357
- `absolute` to show all values are absolute (i.e. turn negative dimensions to positive)
358
- `percentage` to express the values as a percentage of the chart total (so, the values of the dimensions are added, and the sum of them if expressed as a percentage of the sum of all dimensions)
359
-- `unaligned` to prevent netdata from aligning the charts (e.g. when requesting 60 seconds aggregation per point, netdata returns chart data aligned to XX:XX:00 to XX:XX:59 - similarly for hours, days, etc - the `unaligned` option disables this feature)
359
+- `unaligned` to prevent Netdata from aligning the charts (e.g. when requesting 60 seconds aggregation per point, Netdata returns chart data aligned to XX:XX:00 to XX:XX:59 - similarly for hours, days, etc - the `unaligned` option disables this feature)
360
- `match-ids` or `match-names` is used to control what `data-dimensions=` will match.
361
362
### Chart library performance
@@ -373,7 +373,7 @@ refreshed in <span id="measurement1"></span> milliseconds!
373
374
### Syncing charts y-range
375
376
-If you give the same `data-common-max="NAME"` to 2+ charts, then all of them will share the same max value of their y-range. If one spikes, all of them will be aligned to have the same scale. This is done for the cpu interrupts and and cpu softnet charts at the dashboard and also for the `gauge` and `easypiecharts` of the netdata home page.
376
+If you give the same `data-common-max="NAME"` to 2+ charts, then all of them will share the same max value of their y-range. If one spikes, all of them will be aligned to have the same scale. This is done for the cpu interrupts and and cpu softnet charts at the dashboard and also for the `gauge` and `easypiecharts` of the Netdata home page.
377
378
```html
379
<div data-netdata="chart1"
@@ -389,7 +389,7 @@ The same functionality exists for `data-common-min`.
389
390
### Syncing chart units
391
392
-netdata dashboards support auto-scaling of units. So, `MB` can become `KB`, `GB`, etc dynamically, based on the value to be shown.
392
+Netdata dashboards support auto-scaling of units. So, `MB` can become `KB`, `GB`, etc dynamically, based on the value to be shown.
393
394
Giving the same `NAME` with `data-common-units="NAME"`, 2+ charts can be forced to always have the same units.
395
web/server/README.md
+16
-16
@@ -22,9 +22,9 @@ With the web server enabled, you can control the number of threads and sockets w
22
23
The default number of processor threads is `min(cpu cores, 6)`.
24
25
-The `web server max sockets` setting is automatically adjusted to 50% of the max number of open files netdata is allowed to use (via `/etc/security/limits.conf` or systemd), to allow enough file descriptors to be available for data collection.
25
+The `web server max sockets` setting is automatically adjusted to 50% of the max number of open files Netdata is allowed to use (via `/etc/security/limits.conf` or systemd), to allow enough file descriptors to be available for data collection.
26
27
-### Binding netdata to multiple ports
27
+### Binding Netdata to multiple ports
28
29
Netdata can bind to multiple IPs and ports, offering access to different services on each. Up to 100 sockets can be used (you can increase it at compile time with `CFLAGS="-DMAX_LISTEN_FDS=200" ./netdata-installer.sh ...`).
30
@@ -36,12 +36,12 @@ The ports to bind are controlled via `[web].bind to`, like this:
36
bind to = 127.0.0.1=dashboard^SSL=optional 10.1.1.1:19998=management|netdata.conf hostname:19997=badges [::]:19996=streaming^SSL=force localhost:19995=registry *:http=dashboard unix:/tmp/netdata.sock
37
```
38
39
-Using the above, netdata will bind to:
39
+Using the above, Netdata will bind to:
40
41
- IPv4 127.0.0.1 at port 19999 (port was used from `default port`). Only the UI (dashboard) and the read API will be accessible on this port. Both HTTP and HTTPS requests will be accepted.
42
-- IPv4 10.1.1.1 at port 19998. The management API and netdata.conf will be accessible on this port.
42
+- IPv4 10.1.1.1 at port 19998. The management API and `netdata.conf` will be accessible on this port.
43
- All the IPs `hostname` resolves to (both IPv4 and IPv6 depending on the resolved IPs) at port 19997. Only badges will be accessible on this port.
44
-- All IPv6 IPs at port 19996. Only metric streaming requests from other netdata agents will be accepted on this port. Only encrypted streams will be allowed (i.e. slaves also need to be [configured for TLS](../../streaming).
44
+- All IPv6 IPs at port 19996. Only metric streaming requests from other Netdata agents will be accepted on this port. Only encrypted streams will be allowed (i.e. slaves also need to be [configured for TLS](../../streaming).
45
- All the IPs `localhost` resolves to (both IPv4 and IPv6 depending the resolved IPs) at port 19996. This port will only accept registry API requests.
46
- All IPv4 and IPv6 IPs at port `http` as set in `/etc/services`. Only the UI (dashboard) and the read API will be accessible on this port.
47
- Unix domain socket `/tmp/netdata.sock`. All requests are serviceable on this socket.
@@ -92,7 +92,7 @@ $ openssl req -newkey rsa:2048 -nodes -sha512 -x509 -days 365 -keyout key.pem -o
92
93
When the certificates are defined and unless any other options are provided, a Netdata server will:
94
95
-- Redirect all incoming HTTP web server requests to HTTPS. Applies to the dashboard, the API, netdata.conf and badges.
95
+- Redirect all incoming HTTP web server requests to HTTPS. Applies to the dashboard, the API, `netdata.conf` and badges.
96
- Allow incoming slave connections to use both unencrypted and encrypted communications for streaming.
97
98
To change this behavior, you need to modify the `bind to` setting in the `[web]` section of `netdata.conf`. At the end of each port definition, you can append `^SSL=force` or `^SSL=optional`. What happens with these settings differs, depending on whether the port is used for HTTP/S requests, or for streaming.
@@ -123,7 +123,7 @@ Netdata will:
123
124
- Force all HTTP requests to the default port to be redirected to HTTPS (same port).
125
- Refuse unencrypted streaming connections from slaves on the default port.
126
-- Allow both HTTP and HTTPS requests to port 20000 for netdata.conf
126
+- Allow both HTTP and HTTPS requests to port 20000 for `netdata.conf`
127
- 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.
128
129
#### TLS/SSL errors
@@ -150,7 +150,7 @@ Netdata supports access lists in `netdata.conf`:
150
151
`*` does string matches on the IPs of the clients.
152
153
-- `allow connections from` matches anyone that connects on the netdata port(s).
153
+- `allow connections from` matches anyone that connects on the Netdata port(s).
154
So, if someone is not allowed, it will be connected and disconnected immediately, without reading even
155
a single byte from its connection. This is a global settings with higher priority to any of the ones below.
156
@@ -159,12 +159,12 @@ Netdata supports access lists in `netdata.conf`:
159
160
- `allow badges from` checks if the API request is for a badge. Badges are not matched by `allow dashboard from`.
161
162
-- `allow streaming from` checks if the slave willing to stream metrics to this netdata is allowed.
162
+- `allow streaming from` checks if the slave willing to stream metrics to this Netdata is allowed.
163
This can be controlled per API KEY and MACHINE GUID in [stream.conf](../../streaming/stream.conf).
164
The setting in `netdata.conf` is checked before the ones in [stream.conf](../../streaming/stream.conf).
165
166
- `allow netdata.conf from` checks the IP to allow `http://netdata.host:19999/netdata.conf`.
167
- The IPs listed are all the private IPv4 addresses, including link local IPv6 addresses. Keep in mind that connections to netdata API ports are filtered by `allow connections from`. So, IPs allowed by `allow netdata.conf from` should also be allowed by `allow connections from`.
167
+ The IPs listed are all the private IPv4 addresses, including link local IPv6 addresses. Keep in mind that connections to Netdata API ports are filtered by `allow connections from`. So, IPs allowed by `allow netdata.conf from` should also be allowed by `allow connections from`.
168
169
- `allow management from` checks the IPs to allow API management calls. Management via the API is currently supported for [health](../api/health/#health-management-api)
170
@@ -174,27 +174,27 @@ setting | default | info
174
ses max window | `15` | See [single exponential smoothing](../api/queries/des/)
175
des max window | `15` | See [double exponential smoothing](../api/queries/des/)
176
listen backlog | `4096` | The port backlog. Check `man 2 listen`.
177
-web files owner | `netdata` | The user that owns the web static files. Netdata will refuse to serve a file that is not owned by this user, even if it has read access to that file. If the user given is not found, netdata will only serve files owned by user given in `run as user`.
177
+web files owner | `netdata` | The user that owns the web static files. Netdata will refuse to serve a file that is not owned by this user, even if it has read access to that file. If the user given is not found, Netdata will only serve files owned by user given in `run as user`.
178
web files group | `netdata` | If this is set, Netdata will check if the file is owned by this group and refuse to serve the file if it's not.
179
disconnect idle clients after seconds | `60` | The time in seconds to disconnect web clients after being totally idle.
180
timeout for first request | `60` | How long to wait for a client to send a request before closing the socket. Prevents slow request attacks.
181
accept a streaming request every seconds | `0` | Can be used to set a limit on how often a master Netdata server will accept streaming requests from the slaves in a [streaming and replication setup](../../streaming)
182
respect do not track policy | `no` | If set to `yes`, will respect the client's browser preferences on storing cookies.
183
x-frame-options response header | | [Avoid clickjacking attacks, by ensuring that the content is not embedded into other sites](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options).
184
-enable gzip compression | `yes` | When set to `yes`, netdata web responses will be GZIP compressed, if the web client accepts such responses.
184
+enable gzip compression | `yes` | When set to `yes`, Netdata web responses will be GZIP compressed, if the web client accepts such responses.
185
gzip compression strategy | `default` | Valid strategies are `default`, `filtered`, `huffman only`, `rle` and `fixed`
186
gzip compression level | `3` | Valid levels are 1 (fastest) to 9 (best ratio)
187
188
189
## DDoS protection
190
191
-If you publish your netdata to the internet, you may want to apply some protection against DDoS:
191
+If you publish your Netdata to the internet, you may want to apply some protection against DDoS:
192
193
1. Use the `static-threaded` web server (it is the default)
194
2. Use reasonable `[web].web server max sockets` (the default is)
195
-3. Don't use all your cpu cores for netdata (lower `[web].web server threads`)
196
-4. Run netdata with a low process scheduling priority (the default is the lowest)
197
-5. If possible, proxy netdata via a full featured web server (nginx, apache, etc)
195
+3. Don't use all your CPU cores for Netdata (lower `[web].web server threads`)
196
+4. Run the `netdata` process with a low process scheduling priority (the default is the lowest)
197
+5. If possible, proxy Netdata via a full featured web server (nginx, apache, etc)
198
199
200
[]()