diff options
| author | Joel Hans <joel@netdata.cloud> | 2019-08-13 08:07:17 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-08-13 08:07:17 -0700 |
| commit | a726c905bde122d6a03da9866efb51a2e3b526c2 (patch) | |
| tree | 7715d332b0eeedbf4e45ea60c698a25c2c30929d /backends | |
| parent | dc38b1d15df2d07f65c0f3c8f8f944fbcc89a574 (diff) | |
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
Diffstat (limited to 'backends')
| -rw-r--r-- | backends/README.md | 74 | ||||
| -rw-r--r-- | backends/WALKTHROUGH.md | 6 | ||||
| -rw-r--r-- | backends/aws_kinesis/README.md | 8 | ||||
| -rw-r--r-- | backends/prometheus/README.md | 80 | ||||
| -rw-r--r-- | backends/prometheus/remote_write/README.md | 2 |
5 files changed, 85 insertions, 85 deletions
diff --git a/backends/README.md b/backends/README.md index ef5baa1b6b..86f08325ff 100644 --- a/backends/README.md +++ b/backends/README.md @@ -1,15 +1,15 @@ # Metrics long term archiving -netdata supports backends for archiving the metrics, or providing long term dashboards, +Netdata supports backends for archiving the metrics, or providing long term dashboards, using Grafana or other tools, like this:  -Since netdata collects thousands of metrics per server per second, which would easily congest any backend -server when several netdata servers are sending data to it, netdata allows sending metrics at a lower +Since Netdata collects thousands of metrics per server per second, which would easily congest any backend +server when several Netdata servers are sending data to it, Netdata allows sending metrics at a lower frequency, by resampling them. -So, although netdata collects metrics every second, it can send to the backend servers averages or sums every +So, although Netdata collects metrics every second, it can send to the backend servers averages or sums every X seconds (though, it can send them per second if you need it to). ## features @@ -30,7 +30,7 @@ X seconds (though, it can send them per second if you need it to). metrics are sent to a document db, `JSON` formatted. - - **prometheus** is described at [prometheus page](prometheus/) since it pulls data from netdata. + - **prometheus** is described at [prometheus page](prometheus/) since it pulls data from Netdata. - **prometheus remote write** (a binary snappy-compressed protocol buffer encoding over HTTP used by **Elasticsearch**, **Gnocchi**, **Graphite**, **InfluxDB**, **Kafka**, **OpenTSDB**, @@ -54,26 +54,26 @@ X seconds (though, it can send them per second if you need it to). So, counters are sent as counters and gauges are sent as gauges, much like all data collectors do. For example, to calculate CPU utilization in this format, you need to know how to convert kernel ticks to percentage. - - `average` sends to backends normalized metrics from the netdata database. - In this mode, all metrics are sent as gauges, in the units netdata uses. This abstracts data collection + - `average` sends to backends normalized metrics from the Netdata database. + In this mode, all metrics are sent as gauges, in the units Netdata uses. This abstracts data collection and simplifies visualization, but you will not be able to copy and paste queries from other sources to convert units. - For example, CPU utilization percentage is calculated by netdata, so netdata will convert ticks to percentage and + For example, CPU utilization percentage is calculated by Netdata, so Netdata will convert ticks to percentage and send the average percentage to the backend. - - `sum` or `volume`: the sum of the interpolated values shown on the netdata graphs is sent to the backend. - So, if netdata is configured to send data to the backend every 10 seconds, the sum of the 10 values shown on the - netdata charts will be used. + - `sum` or `volume`: the sum of the interpolated values shown on the Netdata graphs is sent to the backend. + So, if Netdata is configured to send data to the backend every 10 seconds, the sum of the 10 values shown on the + Netdata charts will be used. 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`. -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. +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. -5. This code is smart enough, not to slow down netdata, independently of the speed of the backend server. +5. This code is smart enough, not to slow down Netdata, independently of the speed of the backend server. ## configuration In `/etc/netdata/netdata.conf` you should have something like this (if not download the latest version -of `netdata.conf` from your netdata): +of `netdata.conf` from your Netdata): ``` [backend] @@ -82,7 +82,7 @@ of `netdata.conf` from your netdata): host tags = list of TAG=VALUE destination = space separated list of [PROTOCOL:]HOST[:PORT] - the first working will be used, or a region for kinesis data source = average | sum | as collected - prefix = netdata + prefix = Netdata hostname = my-name update every = 10 buffer on failures = 10 @@ -122,13 +122,13 @@ of `netdata.conf` from your netdata): destination = [ffff:...:0001]:2003 10.11.12.1:2003 ``` - When multiple servers are defined, netdata will try the next one when the first one fails. This allows - you to load-balance different servers: give your backend servers in different order on each netdata. + When multiple servers are defined, Netdata will try the next one when the first one fails. This allows + you to load-balance different servers: give your backend servers in different order on each Netdata. - netdata also ships [`nc-backend.sh`](nc-backend.sh), + Netdata also ships [`nc-backend.sh`](nc-backend.sh), a script that can be used as a fallback backend to save the metrics to disk and push them to the time-series database when it becomes available again. It can also be used to monitor / trace / debug - the metrics netdata generates. + the metrics Netdata generates. For kinesis backend `destination` should be set to an AWS region (for example, `us-east-1`). @@ -138,16 +138,16 @@ of `netdata.conf` from your netdata): - `hostname = my-name`, is the hostname to be used for sending data to the backend server. By default this is `[global].hostname`. -- `prefix = netdata`, is the prefix to add to all metrics. +- `prefix = Netdata`, is the prefix to add to all metrics. -- `update every = 10`, is the number of seconds between sending data to the backend. netdata will add - some randomness to this number, to prevent stressing the backend server when many netdata servers send +- `update every = 10`, is the number of seconds between sending data to the backend. Netdata will add + some randomness to this number, to prevent stressing the backend server when many Netdata servers send data to the same backend. This randomness does not affect the quality of the data, only the time they are sent. - `buffer on failures = 10`, is the number of iterations (each iteration is `[backend].update every` seconds) to buffer data, when the backend is not available. If the backend fails to receive the data after that - many failures, data loss on the backend is expected (netdata will also log it). + many failures, data loss on the backend is expected (Netdata will also log it). - `timeout ms = 20000`, is the timeout in milliseconds to wait for the backend server to process the data. By default this is `2 * update_every * 1000`. @@ -155,7 +155,7 @@ of `netdata.conf` from your netdata): - `send hosts matching = localhost *` includes one or more space separated patterns, using ` * ` as wildcard (any number of times within each pattern). The patterns are checked against the hostname (the localhost is always checked as `localhost`), allowing us to filter which hosts will be sent to the backend when - this netdata is a central netdata aggregating multiple hosts. A pattern starting with ` ! ` gives a + this Netdata is a central Netdata aggregating multiple hosts. A pattern starting with ` ! ` gives a negative match. So to match all hosts named `*db*` except hosts containing `*slave*`, use `!*slave* *db*` (so, the order is important: the first pattern matching the hostname will be used - positive or negative). @@ -166,8 +166,8 @@ of `netdata.conf` from your netdata): except charts ending in `*reads`, use `!*reads apps.*` (so, the order is important: the first pattern matching the chart id or the chart name will be used - positive or negative). -- `send names instead of ids = yes | no` controls the metric names netdata should send to backend. - netdata supports names and IDs for charts and dimensions. Usually IDs are unique identifiers as read +- `send names instead of ids = yes | no` controls the metric names Netdata should send to backend. + 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). 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. @@ -176,26 +176,26 @@ of `netdata.conf` from your netdata): These are currently only sent to opentsdb and prometheus. Please use the appropriate format for each time-series db. For example opentsdb likes them like `TAG1=VALUE1 TAG2=VALUE2`, but prometheus like `tag1="value1",tag2="value2"`. Host tags are mirrored with database replication (streaming of metrics - between netdata servers). + between Netdata servers). ## monitoring operation -netdata provides 5 charts: +Netdata provides 5 charts: -1. **Buffered metrics**, the number of metrics netdata added to the buffer for dispatching them to the +1. **Buffered metrics**, the number of metrics Netdata added to the buffer for dispatching them to the backend server. -2. **Buffered data size**, the amount of data (in KB) netdata added the buffer. +2. **Buffered data size**, the amount of data (in KB) Netdata added the buffer. -3. ~~**Backend latency**, the time the backend server needed to process the data netdata sent. +3. ~~**Backend latency**, the time the backend server needed to process the data Netdata sent. If there was a re-connection involved, this includes the connection time.~~ - (this chart has been removed, because it only measures the time netdata needs to give the data - to the O/S - since the backend servers do not ack the reception, netdata does not have any means + (this chart has been removed, because it only measures the time Netdata needs to give the data + to the O/S - since the backend servers do not ack the reception, Netdata does not have any means to measure this properly). -4. **Backend operations**, the number of operations performed by netdata. +4. **Backend operations**, the number of operations performed by Netdata. -5. **Backend thread CPU usage**, the CPU resources consumed by the netdata thread, that is responsible +5. **Backend thread CPU usage**, the CPU resources consumed by the Netdata thread, that is responsible for sending the metrics to the backend server.  @@ -204,12 +204,12 @@ netdata provides 5 charts: The latest version of the alarms configuration for monitoring the backend is [here](../health/health.d/backend.conf) -netdata adds 4 alarms: +Netdata adds 4 alarms: 1. `backend_last_buffering`, number of seconds since the last successful buffering of backend data 2. `backend_metrics_sent`, percentage of metrics sent to the backend server 3. `backend_metrics_lost`, number of metrics lost due to repeating failures to contact the backend server -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). +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).  diff --git a/backends/WALKTHROUGH.md b/backends/WALKTHROUGH.md index d3666ef5db..7f1dda66f4 100644 --- a/backends/WALKTHROUGH.md +++ b/backends/WALKTHROUGH.md @@ -41,7 +41,7 @@ visibility into your application and systems performance. ## Getting Started - Netdata To begin let’s create our container which we will install Netdata on. We need -to run a container, forward the necessary port that netdata listens on, and +to run a container, forward the necessary port that Netdata listens on, and attach a tty so we can interact with the bash shell on the container. But before we do this we want name resolution between the two containers to work. 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. After we have entered the shell we can install Netdata. This process could not be easier. If you take a look at [this link](../packaging/installer/#installation), the Netdata devs give us -several one-liners to install netdata. I have not had any issues with these one +several one-liners to install Netdata. I have not had any issues with these one liners and their bootstrapping scripts so far (If you guys run into anything do share). Run the following command in your container. @@ -97,7 +97,7 @@ Netdata dashboard.  This CHART is called ‘system.cpu’, The FAMILY is cpu, and the DIMENSION we are -observing is “system”. You can begin to draw links between the charts in netdata +observing is “system”. You can begin to draw links between the charts in Netdata to the prometheus metrics format in this manner. ## Prometheus diff --git a/backends/aws_kinesis/README.md b/backends/aws_kinesis/README.md index 4249790975..b5726d2dbd 100644 --- a/backends/aws_kinesis/README.md +++ b/backends/aws_kinesis/README.md @@ -1,8 +1,8 @@ -# Using netdata with AWS Kinesis Data Streams +# Using Netdata with AWS Kinesis Data Streams ## Prerequisites -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. +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. 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: @@ -21,7 +21,7 @@ To enable data sending to the kinesis backend set the following options in `netd ``` set the `destination` option to an AWS region. -In the netdata configuration directory run `./edit-config aws_kinesis.conf` and set AWS credentials and stream name: +In the Netdata configuration directory run `./edit-config aws_kinesis.conf` and set AWS credentials and stream name: ``` # AWS credentials aws_access_key_id = your_access_key_id @@ -32,7 +32,7 @@ stream name = your_stream_name ``` 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). -A partition key for every record is computed automatically by the netdata with the purpose to distribute records across available shards evenly. +A partition key for every record is computed automatically by Netdata with the purpose to distribute records across available shards evenly. []() diff --git a/backends/prometheus/README.md b/backends/prometheus/README.md index 6b070dea8d..f879ba35a3 100644 --- a/backends/prometheus/README.md +++ b/backends/prometheus/README.md @@ -1,32 +1,32 @@ -# Using netdata with Prometheus +# Using Netdata with Prometheus -> 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. +> 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. -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). +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). -## Installing netdata and prometheus +## Installing Netdata and prometheus -### Installing netdata +### Installing Netdata -There are number of ways to install netdata according to [Installation](../../packaging/installer/#installation) -The suggested way of installing the latest netdata and keep it upgrade automatically. Using one line installation: +There are number of ways to install Netdata according to [Installation](../../packaging/installer/#installation) +The suggested way of installing the latest Netdata and keep it upgrade automatically. Using one line installation: ``` bash <(curl -Ss https://my-netdata.io/kickstart.sh) ``` -At this point we should have netdata listening on port 19999. Attempt to take your browser here: +At this point we should have Netdata listening on port 19999. Attempt to take your browser here: ``` http://your.netdata.ip:19999 ``` -*(replace `your.netdata.ip` with the IP or hostname of the server running netdata)* +*(replace `your.netdata.ip` with the IP or hostname of the server running Netdata)* ### Installing Prometheus -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. +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. #### Download Prometheus @@ -57,7 +57,7 @@ sudo tar -xvf /tmp/prometheus-2.3.2.linux-amd64.tar.gz -C /opt/prometheus --stri We will use the following `prometheus.yml` file. Save it at `/opt/prometheus/prometheus.yml`. -Make sure to replace `your.netdata.ip` with the IP or hostname of the host running netdata. +Make sure to replace `your.netdata.ip` with the IP or hostname of the host running Netdata. ```yaml # my global config @@ -101,7 +101,7 @@ scrape_configs: #source: [as-collected] # # server name for this prometheus - the default is the client IP - # for netdata to uniquely identify it + # for Netdata to uniquely identify it #server: ['prometheus1'] honor_labels: true @@ -180,21 +180,21 @@ sudo systemctl enable prometheus Prometheus should now start and listen on port 9090. Attempt to head there with your browser. -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. +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. --- ## Netdata support for prometheus -> 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. +> 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. -Before explaining the changes, we have to understand the key differences between netdata and prometheus. +Before explaining the changes, we have to understand the key differences between Netdata and prometheus. -### understanding netdata metrics +### understanding Netdata metrics ##### charts -Each chart in netdata has several properties (common to all its metrics): +Each chart in Netdata has several properties (common to all its metrics): - `chart_id` - uniquely identifies a chart. @@ -208,32 +208,32 @@ Each chart in netdata has several properties (common to all its metrics): ##### dimensions -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). +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). -### netdata data source +### Netdata data source Netdata can send metrics to prometheus from 3 data sources: -- `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. +- `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. The format of the metrics is: `CONTEXT{chart="CHART",family="FAMILY",dimension="DIMENSION"}`. - If the metric is a counter (`incremental` in netdata lingo), `_total` is appended the context. + If the metric is a counter (`incremental` in Netdata lingo), `_total` is appended the context. - 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"}` + 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"}` -- `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. +- `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. The format of the metrics is: `CONTEXT_UNITS_average{chart="CHART",family="FAMILY",dimension="DIMENSION"}`. - 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. + 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. - `sum` or `volume`, is like `average` but instead of averaging the values, it sums them. The format of the metrics is: `CONTEXT_UNITS_sum{chart="CHART",family="FAMILY",dimension="DIMENSION"}`. All the other operations are the same with `average`. -Keep in mind that early versions of netdata were sending the metrics as: `CHART_DIMENSION{}`. +Keep in mind that early versions of Netdata were sending the metrics as: `CHART_DIMENSION{}`. ### Querying Metrics @@ -241,11 +241,11 @@ Fetch with your web browser this URL: `http://your.netdata.ip:19999/api/v1/allmetrics?format=prometheus&help=yes` -*(replace `your.netdata.ip` with the ip or hostname of your netdata server)* +*(replace `your.netdata.ip` with the ip or hostname of your Netdata server)* -netdata will respond with all the metrics it sends to prometheus. +Netdata will respond with all the metrics it sends to prometheus. -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`). +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`). Searching for `"system.cpu"` reveals: @@ -272,7 +272,7 @@ netdata_system_cpu_percentage_average{chart="system.cpu",family="cpu",dimension= # COMMENT netdata_system_cpu_percentage_average: dimension "idle", value is percentage, gauge, dt 1500066653 to 1500066662 inclusive netdata_system_cpu_percentage_average{chart="system.cpu",family="cpu",dimension="idle"} 92.3630770 1500066662000 ``` -*(netdata response for `system.cpu` with source=`average`)* +*(Netdata response for `system.cpu` with source=`average`)* 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. @@ -302,13 +302,13 @@ netdata_system_cpu_total{chart="system.cpu",family="cpu",dimension="iowait"} 233 netdata_system_cpu_total{chart="system.cpu",family="cpu",dimension="idle"} 918470 1500066716438 ``` -*(netdata response for `system.cpu` with source=`as-collected`)* +*(Netdata response for `system.cpu` with source=`as-collected`)* For more information check prometheus documentation. ### Streaming data from upstream hosts -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**: +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**: ``` metrics_path: '/api/v1/allmetrics' @@ -321,13 +321,13 @@ This will report all upstream host data, and `honor_labels` will make Prometheus ### Timestamps -To pass the metrics through prometheus pushgateway, netdata supports the option `×tamps=no` to send the metrics without timestamps. +To pass the metrics through prometheus pushgateway, Netdata supports the option `×tamps=no` to send the metrics without timestamps. ## Netdata host variables -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. +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. -To expose them, append `variables=yes` to the netdata URL. +To expose them, append `variables=yes` to the Netdata URL. ### TYPE and HELP @@ -335,7 +335,7 @@ To save bandwidth, and because prometheus does not use them anyway, `# TYPE` and ### Names and IDs -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). +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). 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. @@ -353,7 +353,7 @@ You can overwrite it from prometheus, by appending to the URL: ### Filtering metrics sent to prometheus -netdata can filter the metrics it sends to prometheus with this setting: +Netdata can filter the metrics it sends to prometheus with this setting: ``` [backend] @@ -362,9 +362,9 @@ netdata can filter the metrics it sends to prometheus with this setting: 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. -### Changing the prefix of netdata metrics +### Changing the prefix of Netdata metrics -netdata sends all metrics prefixed with `netdata_`. You can change this in `netdata.conf`, like this: +Netdata sends all metrics prefixed with `netdata_`. You can change this in `netdata.conf`, like this: ``` [backend] @@ -383,8 +383,8 @@ To get the metric names as they were before v1.12, append to the URL `&oldunits= ### Accuracy of `average` and `sum` data sources -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`. +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`. -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. +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. []() diff --git a/backends/prometheus/remote_write/README.md b/backends/prometheus/remote_write/README.md index 73cb1daf5a..2baa00fa09 100644 --- a/backends/prometheus/remote_write/README.md +++ b/backends/prometheus/remote_write/README.md @@ -2,7 +2,7 @@ ## Prerequisites -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. +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. ## Configuration |