Change backends to exporting engine in general documentation pages (#9045)
Vladimir Kobal committed
May 26, 2020 at 20:08 UTC
b4e9fd0c591a66c11f4bdd0d2c667556e9d866c3
6 files changed
+35
-54
docs/getting-started.md
+1
-1
@@ -243,7 +243,7 @@ Netdata.
243
Take a look at some more advanced features and configurations:
244
245
- Centralize Netdata metrics from many systems with [streaming](/streaming/README.md)
246
-- Enable long-term archiving of Netdata metrics via [backends](/backends/README.md) to time-series databases.
246
+- Enable long-term archiving of Netdata metrics via [exporting engine](/exporting/README.md) to time-series databases.
247
- Improve security by putting Netdata behind an [Nginx proxy with SSL](/docs/Running-behind-nginx.md).
248
249
Or, learn more about how you can contribute to [Netdata core](/CONTRIBUTING.md) or our
docs/netdata-security.md
+1
-1
@@ -26,7 +26,7 @@ We have given special attention to all aspects of Netdata, ensuring that everyth
26
27
Netdata collects raw data from many sources. For each source, Netdata uses a plugin that connects to the source (or reads the relative files produced by the source), receives raw data and processes them to calculate the metrics shown on Netdata dashboards.
28
29
-Even if Netdata plugins connect to your database server, or read your application log file to collect raw data, the product of this data collection process is always a number of **chart metadata and metric values** (summarized data for dashboard visualization). All Netdata plugins (internal to the Netdata daemon, and external ones written in any computer language), convert raw data collected into metrics, and only these metrics are stored in Netdata databases, sent to upstream Netdata servers, or archived to backend time-series databases.
29
+Even if Netdata plugins connect to your database server, or read your application log file to collect raw data, the product of this data collection process is always a number of **chart metadata and metric values** (summarized data for dashboard visualization). All Netdata plugins (internal to the Netdata daemon, and external ones written in any computer language), convert raw data collected into metrics, and only these metrics are stored in Netdata databases, sent to upstream Netdata servers, or archived to external time-series databases.
30
31
> The **raw data** collected by Netdata, do not leave the host they are collected. **The only data Netdata exposes are chart metadata and metric values.**
32
docs/step-by-step/step-01.md
+1
-1
@@ -141,7 +141,7 @@ easy!
141
We'll cover this quickly, as you're probably eager to get on with using Netdata itself.
142
143
We don't want to lock you in to using Netdata by itself, and forever. By supporting [archiving to
144
-backends](/backends/README.md) like Graphite, Prometheus, OpenTSDB, MongoDB, and others, you can use Netdata _in
144
+external databases](/exporting/README.md) like Graphite, Prometheus, OpenTSDB, MongoDB, and others, you can use Netdata _in
145
conjunction_ with software that might seem like our competitors.
146
147
We don't want to "wage war" with another monitoring solution, whether it's commercial, open-source, or anything in
docs/step-by-step/step-09.md
+25
-43
@@ -18,16 +18,15 @@ That's a lot of metrics. We're talking 345,600,000 individual data points. And t
18
a portion of the RAM available on most systems.
19
20
To store _even more_ metrics, you have two options. First, you can tweak the database engine's options to expand the RAM
21
-or disk it uses. Second, you can archive metrics to a different backend. For that, we'll use MongoDB and Prometheus as
22
-examples.
21
+or disk it uses. Second, you can archive metrics to an external database. For that, we'll use MongoDB as examples.
22
23
## What you'll learn in this step
24
25
In this step of the Netdata guide, you'll learn how to:
26
27
- [Tweak the database engine's settings](#tweak-the-database-engines-settings)
29
-- [Archive metrics to a backend](#archive-metrics-to-a-backend)
30
- - [Use the MongoDB backend](#archive-metrics-via-the-mongodb-backend)
28
+- [Archive metrics to an external database](#archive-metrics-to-an-external-database)
29
+ - [Use the MongoDB database](#archive-metrics-via-the-mongodb-exporting-connector)
30
31
Let's get started!
32
@@ -73,15 +72,16 @@ the right-hand side. You can find `dbengine` metrics after `queries`.
72
74
76
-## Archive metrics to a backend
75
+## Archive metrics to an external database
76
78
-You can archive all the metrics collected by Netdata to what we call **backends**. The supported backends include
79
-Graphite, OpenTSDB, Prometheus, AWS Kinesis Data Streams, MongoDB, and the list is always growing.
77
+You can archive all the metrics collected by Netdata to **external databases**. The supported databases and services
78
+include Graphite, OpenTSDB, Prometheus, AWS Kinesis Data Streams, Google Cloud Pub/Sub, MongoDB, and the list is always
79
+growing.
80
81
As we said in [step 1](/docs/step-by-step/step-01.md), we have only complimentary systems, not competitors! We're happy
82
to support these archiving methods and are always working to improve them.
83
84
-A lot of Netdata users archive their metrics to one of these backends for long-term storage or further analysis. Since
84
+A lot of Netdata users archive their metrics to one of these databases for long-term storage or further analysis. Since
85
Netdata collects so many metrics every second, they can quickly overload small devices or even big servers that are
86
aggregating metrics streaming in from other Netdata agents.
87
@@ -91,11 +91,7 @@ sum of every X seconds of metrics. This reduces the sheer amount of data, albeit
91
How you archive metrics, or if you archive metrics at all, is entirely up to you! But let's cover two easy archiving
92
methods, MongoDB and Prometheus remote write, to get you started.
93
94
-> Currently, Netdata can only use a single backend at a time. We are currently working on a new archiving solution,
95
-> which we call "exporters," that simplifies the configuration process and allows you to archive to multiple backends.
96
-> We'll update this tutorial as soon as exporters are enabled.
97
-
98
-### Archive metrics via the MongoDB backend
94
+### Archive metrics via the MongoDB exporting connector
95
96
Begin by installing MongoDB its dependencies via the correct package manager for your system.
97
@@ -122,7 +118,7 @@ use netdata
118
db.createCollection("netdata_metrics")
119
```
120
125
-Next, Netdata needs to be reinstalled in order to detect that the required libraries to make this backend connection
121
+Next, Netdata needs to be reinstalled in order to detect that the required libraries to make this exporting connection
122
exist. Since you most likely installed Netdata using the one-line installer script, all you have to do is run that
123
script again. Don't worry—any configuration changes you made along the way will be retained!
124
@@ -130,45 +126,31 @@ script again. Don't worry—any configuration changes you made along the way wil
126
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
127
```
128
133
-Now, from your Netdata config directory, edit your `netdata.conf` file and set these options in the `[backend]` section:
134
-
135
-```conf
136
-[backend]
137
- enabled = yes
138
- type = mongodb
139
-```
140
-
141
-You now need to initialize and edit a `mongodb.conf` file to tell Netdata where to find the database you just created.
129
+Now, from your Netdata config directory, initialize and edit a `exporting.conf` file to tell Netdata where to find the
130
+database you just created.
131
132
```sh
144
-./edit-config mongodb.conf
133
+./edit-config exporting.conf
134
```
135
147
-Add the following values to the file:
136
+Add the following section to the file:
137
149
-```yaml
150
-# MongoDB backend configuration
151
-#
152
-# All options in this file are mandatory
153
-
154
-# URI
155
-uri = mongodb://localhost
156
-
157
-# database name
158
-database = netdata
159
-
160
-# collection name
161
-collection = netdata_metrics
138
+```conf
139
+[mongodb:my_mongo_instance]
140
+ enabled = yes
141
+ destination = mongodb://localhost
142
+ database = netdata
143
+ collection = netdata_metrics
144
```
145
164
-[Restart](/docs/getting-started.md#start-stop-and-restart-netdata) Netdata to enable the MongoDB backend. Click on the
165
-**Netdata Montioring** menu and check out the **backend** sub-menu. You should start seeing these charts fill up with
166
-data about your MongoDB backend!
146
+[Restart](/docs/getting-started.md#start-stop-and-restart-netdata) Netdata to enable the MongoDB exporting connector.
147
+Click on the **Netdata Montioring** menu and check out the **exporting my mongo instance** sub-menu. You should start
148
+seeing these charts fill up with data about the exporting process!
149
150
151
170
-If you'd like to try connecting Netdata to another backend, such as Prometheus or OpenTSDB, read our [backends
171
-documentation](/backends/README.md).
152
+If you'd like to try connecting Netdata to another database, such as Prometheus or OpenTSDB, read our [exporting
153
+documentation](/exporting/README.md).
154
155
## What's next?
156
docs/tutorials/longer-metrics-storage.md
+1
-2
@@ -11,8 +11,7 @@ long term?
11
12
Many people think Netdata can only store about an hour's worth of real-time metrics, but that's simply not true any
13
more. With the right settings, Netdata is quite capable of efficiently storing hours or days worth of historical,
14
-per-second metrics without having to rely on a [backend](/backends/README.md) or [exporting
15
-connector](/exporting/README.md).
14
+per-second metrics without having to rely on an [exporting engine](/exporting/README.md).
15
16
This tutorial gives two options for configuring Netdata to store more metrics. **We recommend the default [database
17
engine](#using-the-database-engine)**, but you can stick with or switch to the round-robin database if you prefer.
docs/what-is-netdata.md
+6
-6
@@ -223,7 +223,7 @@ This is how it works:
223
| **Store** | Metrics are first stored in RAM in a custom database engine that then "spills" historical metrics to disk for efficient long-term metrics storage. | [`database`](/database/README.md) |
224
| **Check** | A lockless independent watchdog is evaluating **health checks** on the collected metrics, triggers alarms, maintains a health transaction log and dispatches alarm notifications. | [`health`](/health/README.md) |
225
| **Stream** | A lockless independent worker is streaming metrics, in full detail and in real-time, to remote Netdata servers, as soon as they are collected. | [`streaming`](/streaming/README.md) |
226
-| **Archive** | A lockless independent worker is down-sampling the metrics and pushes them to **backend** time-series databases. | [`backends`](/backends/README.md) |
226
+| **Archive** | A lockless independent worker is down-sampling the metrics and pushes them to external time-series databases. | [`exporting`](/exporting/README.md) |
227
| **Query** | Multiple independent workers are attached to the [internal web server](/web/server/README.md), servicing API requests, including [data queries](/web/api/queries/README.md). | [`web/api`](/web/api/README.md) |
228
229
The result is a highly efficient, low-latency system, supporting multiple readers and one writer on each metric.
@@ -279,10 +279,10 @@ This is what you should expect from Netdata:
279
### Integrations
280
281
- **Time-series databases** - Netdata can archive its metrics to **Graphite**, **OpenTSDB**, **Prometheus**, **AWS
282
- Kinesis**, **MongoDB**, **JSON document DBs**, in the same or lower resolution (lower: to prevent it from congesting
283
- these servers due to the amount of data collected). Netdata also supports **Prometheus remote write API**, which
284
- allows storing metrics to **Elasticsearch**, **Gnocchi**, **InfluxDB**, **Kafka**, **PostgreSQL/TimescaleDB**,
285
- **Splunk**, **VictoriaMetrics** and a lot of other [storage
282
+ Kinesis**, **Google Cloud Pub/Sub**, **MongoDB**, **JSON document DBs**, in the same or lower resolution (lower: to
283
+ prevent it from congesting these servers due to the amount of data collected). Netdata also supports **Prometheus
284
+ remote write API**, which allows storing metrics to **Elasticsearch**, **Gnocchi**, **InfluxDB**, **Kafka**,
285
+ **PostgreSQL/TimescaleDB**, **Splunk**, **VictoriaMetrics** and a lot of other [storage
286
providers](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage).
287
288
## Visualization
@@ -370,7 +370,7 @@ Here is a quick list of notable documents:
370
| [`collectors`](/collectors/README.md) | Information about data collection plugins. |
371
| [`health`](/health/README.md) | How Netdata's health monitoring works, how to create your own alarms and how to configure alarm notification methods. |
372
| [`streaming`](/streaming/README.md) | How to build hierarchies of Netdata servers, by streaming metrics between them. |
373
-| [`backends`](/backends/README.md) | Long term archiving of metrics to industry-standard time-series databases, like `prometheus`, `graphite`, `opentsdb`. |
373
+| [`exporting`](/exporting/README.md) | Long term archiving of metrics to industry-standard time-series databases, like `prometheus`, `graphite`, `opentsdb`. |
374
| [`web/api`](/web/api/README.md) | Learn how to query the Netdata API and the queries it supports. |
375
| [`web/api/badges`](/web/api/badges/README.md) | Learn how to generate badges (SVG images) from live data. |
376
| [`web/gui/custom`](/web/gui/custom/README.md) | Learn how to create custom Netdata dashboards. |