15 files changed, 0 insertions, 3170 deletions
diff --git a/docs/guides/collect-apache-nginx-web-logs.md b/docs/guides/collect-apache-nginx-web-logs.md
deleted file mode 100644
index 055219935b..0000000000
--- a/docs/guides/collect-apache-nginx-web-logs.md
+++ /dev/null
@@ -1,112 +0,0 @@
-# Monitor Nginx or Apache web server log files
-
-Parsing web server log files with Netdata, revealing the volume of redirects, requests and other metrics, can give you a better overview of your infrastructure.
-
-Too many bad requests? Maybe a recent deploy missed a few small SVG icons. Too many requests? Time to batten down the hatches—it's a DDoS.
-
-You can use the [LTSV log format](http://ltsv.org/), track TLS and cipher usage, and the whole parser is faster than
-ever. In one test on a system with SSD storage, the collector consistently parsed the logs for 200,000 requests in
-200ms, using ~30% of a single core.
-
-The [web_log](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/weblog/README.md) collector is currently compatible
-with [Nginx](https://nginx.org/en/) and [Apache](https://httpd.apache.org/).
-
-This guide will walk you through using the new Go-based web log collector to turn the logs these web servers
-constantly write to into real-time insights into your infrastructure.
-
-## Set up your web servers
-
-As with all data sources, Netdata can auto-detect Nginx or Apache servers if you installed them using their standard
-installation procedures.
-
-Almost all web server installations will need _no_ configuration to start collecting metrics. As long as your web server
-has readable access log file, you can configure the web log plugin to access and parse it.
-
-## Custom configuration of the web log collector
-
-The web log collector's default configuration comes with a few example jobs that should cover most Linux distributions
-and their default locations for log files:
-
-```yaml
-# [ JOBS ]
-jobs:
-# NGINX
-# debian, arch
-  - name: nginx
-    path: /var/log/nginx/access.log
-
-# gentoo
-  - name: nginx
-    path: /var/log/nginx/localhost.access_log
-
-# APACHE
-# debian
-  - name: apache
-    path: /var/log/apache2/access.log
-
-# gentoo
-  - name: apache
-    path: /var/log/apache2/access_log
-
-# arch
-  - name: apache
-    path: /var/log/httpd/access_log
-
-# debian
-  - name: apache_vhosts
-    path: /var/log/apache2/other_vhosts_access.log
-
-# GUNICORN
-  - name: gunicorn
-    path: /var/log/gunicorn/access.log
-
-  - name: gunicorn
-    path: /var/log/gunicorn/gunicorn-access.log
-```
-
-However, if your log files were not auto-detected, it might be because they are in a different location. Try the default
-`web_log.conf` file.
-
-```bash
-./edit-config go.d/web_log.conf
-```
-
-To create a new custom configuration, you need to set the `path` parameter to point to your web server's access log
-file. You can give it a `name` as well, and set the `log_type` to `auto`.
-
-```yaml
-jobs:
-  - name: example
-    path: /path/to/file.log
-    log_type: auto
-```
-
-Restart Netdata with `sudo systemctl restart netdata`, or the [appropriate
-method](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md#maintaining-a-netdata-agent-installation) for your system. Netdata should pick up your web server's access log and
-begin showing real-time charts!
-
-### Custom log formats and fields
-
-The web log collector is capable of parsing custom Nginx and Apache log formats and presenting them as charts, but we'll
-leave that topic for a separate guide.
-
-We do have [extensive
-documentation](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/weblog/README.md#custom-log-format) on how
-to build custom parsing for Nginx and Apache logs.
-
-## Tweak web log collector alerts
-
-Over time, we've created some default alerts for web log monitoring. These alerts are designed to work only when your
-web server is receiving more than 120 requests per minute. Otherwise, there's simply not enough data to make conclusions
-about what is "too few" or "too many."
-
--   [web log alerts](https://raw.githubusercontent.com/netdata/netdata/master/src/health/health.d/web_log.conf).
-
-You can also edit this file directly with `edit-config`:
-
-```bash
-./edit-config health.d/weblog.conf
-```
-
-For more information about editing the defaults or writing new alert entities, see our 
-[health monitoring documentation](https://github.com/netdata/netdata/blob/master/src/health/README.md).
diff --git a/docs/guides/collect-unbound-metrics.md b/docs/guides/collect-unbound-metrics.md
deleted file mode 100644
index 5467592a07..0000000000
--- a/docs/guides/collect-unbound-metrics.md
+++ /dev/null
@@ -1,144 +0,0 @@
-<!--
-title: "Monitor Unbound DNS servers with Netdata"
-sidebar_label: "Monitor Unbound DNS servers with Netdata"
-date: 2020-03-31
-custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/collect-unbound-metrics.md
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Miscellaneous"
--->
-
-# Monitor Unbound DNS servers with Netdata
-
-[Unbound](https://nlnetlabs.nl/projects/unbound/about/) is a "validating, recursive, caching DNS resolver" from NLNet
-Labs. In v1.19 of Netdata, we release a completely refactored collector for collecting real-time metrics from Unbound
-servers and displaying them in Netdata dashboards.
-
-Unbound runs on FreeBSD, OpenBSD, NetBSD, macOS, Linux, and Windows, and supports DNS-over-TLS, which ensures that DNS
-queries and answers are all encrypted with TLS. In theory, that should reduce the risk of eavesdropping or
-man-in-the-middle attacks when communicating to DNS servers.
-
-This guide will show you how to collect dozens of essential metrics from your Unbound servers with minimal
-configuration.
-
-## Set up your Unbound installation
-
-As with all data sources, Netdata can auto-detect Unbound servers if you installed them using the standard installation
-procedure.
-
-Regardless of whether you're connecting to a local or remote Unbound server, you need to be able to access the server's
-`remote-control` interface via an IP address, FQDN, or Unix socket.
-
-To set up the `remote-control` interface, you can use `unbound-control`. First, run `unbound-control-setup` to generate
-the TLS key files that will encrypt connections to the remote interface. Then add the following to the end of your
-`unbound.conf` configuration file. See the [Unbound
-documentation](https://nlnetlabs.nl/documentation/unbound/howto-setup/#setup-remote-control) for more details on using
-`unbound-control`, such as how to handle situations when Unbound is run under a unique user.
-
-```conf
-# enable remote-control
-remote-control:
-    control-enable: yes
-```
-
-Next, make your `unbound.conf`, `unbound_control.key`, and `unbound_control.pem` files readable by Netdata using [access
-control lists](https://wiki.archlinux.org/index.php/Access_Control_Lists) (ACL).
-
-```bash
-sudo setfacl -m user:netdata:r unbound.conf
-sudo setfacl -m user:netdata:r unbound_control.key
-sudo setfacl -m user:netdata:r unbound_control.pem
-```
-
-Finally, take note whether you're using Unbound in _cumulative_ or _non-cumulative_ mode. This will become relevant when
-configuring the collector.
-
-## Configure the Unbound collector
-
-You may not need to do any more configuration to have Netdata collect your Unbound metrics.
-
-If you followed the steps above to enable `remote-control` and make your Unbound files readable by Netdata, that should
-be enough. Restart Netdata with `sudo systemctl restart netdata`, or the [appropriate
-method](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md#maintaining-a-netdata-agent-installation) for your system. You should see Unbound metrics in your Netdata
-dashboard!
-
-![Some charts showing Unbound metrics in real-time](https://user-images.githubusercontent.com/1153921/69659974-93160f00-103c-11ea-88e6-27e9efcf8c0d.png)
-
-If that failed, you will need to manually configure `unbound.conf`. See the next section for details.
-
-### Manual setup for a local Unbound server
-
-To configure Netdata's Unbound collector module, navigate to your Netdata configuration directory (typically at
-`/etc/netdata/`) and use `edit-config` to initialize and edit your Unbound configuration file.
-
-```bash
-cd /etc/netdata/ # Replace with your Netdata configuration directory, if not /etc/netdata/
-sudo ./edit-config go.d/unbound.conf
-```
-
-The file contains all the global and job-related parameters. The `name` setting is required, and two Unbound servers
-can't have the same name.
-
-> It is important you know whether your Unbound server is running in cumulative or non-cumulative mode, as a conflict
-> between modes will create incorrect charts.
-
-Here are two examples for local Unbound servers, which may work based on your unique setup:
-
-```yaml
-jobs:
-  - name: local
-    address: 127.0.0.1:8953
-    cumulative: no
-    use_tls: yes
-    tls_skip_verify: yes
-    tls_cert: /path/to/unbound_control.pem
-    tls_key: /path/to/unbound_control.key
-  
-  - name: local
-    address: 127.0.0.1:8953
-    cumulative: yes
-    use_tls: no
-```
-
-Netdata will attempt to read `unbound.conf` to get the appropriate `address`, `cumulative`, `use_tls`, `tls_cert`, and
-`tls_key` parameters. 
-
-Restart Netdata with `sudo systemctl restart netdata`, or the [appropriate
-method](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md#maintaining-a-netdata-agent-installation) for your system.
-
-### Manual setup for a remote Unbound server
-
-Collecting metrics from remote Unbound servers requires manual configuration. There are too many possibilities to cover
-all remote connections here, but the [default `unbound.conf`
-file](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/config/go.d/unbound.conf) contains a few useful examples:
-
-```yaml
-jobs:
-  - name: remote
-    address: 203.0.113.10:8953
-    use_tls: no
-
-  - name: remote_cumulative
-    address: 203.0.113.11:8953
-    use_tls: no
-    cumulative: yes
-
-  - name: remote
-    address: 203.0.113.10:8953
-    cumulative: yes
-    use_tls: yes
-    tls_cert: /etc/unbound/unbound_control.pem
-    tls_key: /etc/unbound/unbound_control.key
-```
-
-To see all the available options, see the default [unbound.conf
-file](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/config/go.d/unbound.conf).
-
-## What's next?
-
-Now that you're collecting metrics from your Unbound servers, let us know how it's working for you! There's always room
-for improvement or refinement based on real-world use cases. Feel free to [file an
-issue](https://github.com/netdata/netdata/issues/new?assignees=&labels=bug%2Cneeds+triage&template=BUG_REPORT.yml) with your
-thoughts.
-
-
diff --git a/docs/guides/configure/performance.md b/docs/guides/configure/performance.md
deleted file mode 100644
index e1b32778e0..0000000000
--- a/docs/guides/configure/performance.md
+++ /dev/null
@@ -1,266 +0,0 @@
-# How to optimize the Netdata Agent's performance
-
-We designed the Netdata Agent to be incredibly lightweight, even when it's collecting a few thousand dimensions every
-second and visualizing that data into hundreds of charts. However, the default settings of the Netdata Agent are not
-optimized for performance, but for a simple, standalone setup. We want the first install to give you something you can
-run without any configuration. Most of the settings and options are enabled, since we want you to experience the full
-thing.
-
-By default, Netdata will automatically detect applications running on the node it is installed to start collecting
-metrics in real-time, has health monitoring enabled to evaluate alerts and trains Machine Learning (ML) models for each
-metric, to detect anomalies.
-
-This document describes the resources required for the various default capabilities and the strategies to optimize
-Netdata for production use.
-
-## Summary of performance optimizations
-
-The following table summarizes the effect of each optimization on the CPU, RAM and Disk IO utilization in production.
-
-| Optimization                                                                                                                  | CPU                | RAM                | Disk IO            |
-|-------------------------------------------------------------------------------------------------------------------------------|--------------------|--------------------|--------------------|
-| [Use streaming and replication](#use-streaming-and-replication)                                                               | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| [Disable unneeded plugins or collectors](#disable-unneeded-plugins-or-collectors)                                             | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| [Reduce data collection frequency](#reduce-collection-frequency)                                                              | :heavy_check_mark: |                    | :heavy_check_mark: |
-| [Change how long Netdata stores metrics](https://github.com/netdata/netdata/blob/master/docs/store/change-metrics-storage.md) |                    | :heavy_check_mark: | :heavy_check_mark: |
-| [Use a different metric storage database](https://github.com/netdata/netdata/blob/master/src/database/README.md)              |                    | :heavy_check_mark: | :heavy_check_mark: |
-| [Disable machine learning](#disable-machine-learning)                                                                         | :heavy_check_mark: |                    |                    |
-| [Use a reverse proxy](#run-netdata-behind-a-proxy)                                                                            | :heavy_check_mark: |                    |                    |
-| [Disable/lower gzip compression for the agent dashboard](#disablelower-gzip-compression-for-the-dashboard)                    | :heavy_check_mark: |                    |                    |
-
-## Resources required by a default Netdata installation
-
-Netdata's performance is primarily affected by **data collection/retention** and **clients accessing data**.
-
-You can configure almost all aspects of data collection/retention, and certain aspects of clients accessing data.
-
-### CPU consumption
-
-Expect about:
-
-- 1-3% of a single core for the netdata core
-- 1-3% of a single core for the various collectors (e.g. go.d.plugin, apps.plugin)
-- 5-10% of a single core, when ML training runs
-
-Your experience may vary depending on the number of metrics collected, the collectors enabled and the specific
-environment they run on, i.e. the work they have to do to collect these metrics.
-
-As a general rule, for modern hardware and VMs, the total CPU consumption of a standalone Netdata installation,
-including all its components, should be below 5 - 15% of a single core. For example, on 8 core server it will use only
-0.6% - 1.8% of a total CPU capacity, depending on the CPU characteristics.
-
-The Netdata Agent runs with the lowest
-possible [process scheduling policy](https://github.com/netdata/netdata/blob/master/src/daemon/README.md#netdata-process-scheduling-policy),
-which is `nice 19`, and uses the `idle` process scheduler. Together, these settings ensure that the Agent only gets CPU
-resources when the node has CPU resources to space. If the node reaches 100% CPU utilization, the Agent is stopped first
-to ensure your applications get any available resources.
-
-To reduce CPU usage you can (either one or a combination of the following actions):
-
-1. [Disable machine learning](#disable-machine-learning),
-2. [Use streaming and replication](#use-streaming-and-replication),
-3. [Reduce the data collection frequency](#reduce-collection-frequency)
-4. [Disable unneeded plugins or collectors](#disable-unneeded-plugins-or-collectors)
-5. [Use a reverse proxy](#run-netdata-behind-a-proxy),
-6. [Disable/lower gzip compression for the agent dashboard](#disablelower-gzip-compression-for-the-dashboard).
-
-### Memory consumption
-
-The memory footprint of Netdata is mainly influenced by the number of metrics concurrently being collected. Expect about
-150MB of RAM for a typical 64-bit server collecting about 2000 to 3000 metrics.
-
-To estimate and control memory consumption, you can (either one or a combination of the following actions):
-
-1. [Disable unneeded plugins or collectors](#disable-unneeded-plugins-or-collectors)
-2. [Change how long Netdata stores metrics](https://github.com/netdata/netdata/blob/master/docs/store/change-metrics-storage.md)
-3. [Use a different metric storage database](https://github.com/netdata/netdata/blob/master/src/database/README.md).
-
-### Disk footprint and I/O
-
-By default, Netdata should not use more than 1GB of disk space, most of which is dedicated for storing metric data and
-metadata. For typical installations collecting 2000 - 3000 metrics, this storage should provide a few days of
-high-resolution retention (per second), about a month of mid-resolution retention (per minute) and more than a year of
-low-resolution retention (per hour).
-
-Netdata spreads I/O operations across time. For typical standalone installations there should be a few write operations
-every 5-10 seconds of a few kilobytes each, occasionally up to 1MB. In addition, under heavy load, collectors that
-require disk I/O may stop and show gaps in charts.
-
-To optimize your disk footprint in any aspect described below you can:
-
-
-To configure retention, you can: 
-
-1. [Change how long Netdata stores metrics](https://github.com/netdata/netdata/blob/master/docs/store/change-metrics-storage.md).
-
-To control disk I/O:
-
-1. [Use a different metric storage database](https://github.com/netdata/netdata/blob/master/src/database/README.md),
-
-
-Minimize deployment impact on the production system by optimizing disk footprint:
-
-1. [Using streaming and replication](#use-streaming-and-replication)
-2. [Reduce the data collection frequency](#reduce-collection-frequency)
-3. [Disable unneeded plugins or collectors](#disable-unneeded-plugins-or-collectors).
-
-## Use streaming and replication
-
-For all production environments, parent Netdata nodes outside the production infrastructure should be receiving all
-collected data from children Netdata nodes running on the production infrastructure,
-using [streaming and replication](https://github.com/netdata/netdata/blob/master/docs/metrics-storage-management/enable-streaming.md).
-
-### Disable health checks on the child nodes
-
-When you set up streaming, we recommend you run your health checks on the parent. This saves resources on the children
-and makes it easier to configure or disable alerts and agent notifications.
-
-The parents by default run health checks for each child, as long as the child is connected (the details are
-in `stream.conf`). On the child nodes you should add to `netdata.conf` the following:
-
-```conf
-[health]
-   enabled = no
-```
-
-### Use memory mode ram for the child nodes
-
-See [using a different metric storage database](https://github.com/netdata/netdata/blob/master/src/database/README.md).
-
-## Disable unneeded plugins or collectors
-
-If you know that you don't need an [entire plugin or a specific
-collector](https://github.com/netdata/netdata/blob/master/src/collectors/README.md#collector-architecture-and-terminology),
-you can disable any of them. Keep in mind that if a plugin/collector has nothing to do, it simply shuts down and does
-not consume system resources. You will only improve the Agent's performance by disabling plugins/collectors that are
-actively collecting metrics.
-
-Open `netdata.conf` and scroll down to the `[plugins]` section. To disable any plugin, uncomment it and set the value to
-`no`. For example, to explicitly keep the `proc` and `go.d` plugins enabled while disabling `python.d` and `charts.d`.
-
-```conf
-[plugins]
-    proc = yes
-	python.d = no
-	charts.d = no
-	go.d = yes
-```
-
-Disable specific collectors by opening their respective plugin configuration files, uncommenting the line for the
-collector, and setting its value to `no`.
-
-```bash
-sudo ./edit-config go.d.conf
-sudo ./edit-config python.d.conf
-sudo ./edit-config charts.d.conf
-```
-
-For example, to disable a few Python collectors:
-
-```conf
-modules:
-  apache: no
-	dockerd: no
-	fail2ban: no
-```
-
-## Reduce collection frequency
-
-The fastest way to improve the Agent's resource utilization is to reduce how often it collects metrics.
-
-### Global
-
-If you don't need per-second metrics, or if the Netdata Agent uses a lot of CPU even when no one is viewing that node's
-dashboard, [configure the Agent](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md) to collect
-metrics less often.
-
-Open `netdata.conf` and edit the `update every` setting. The default is `1`, meaning that the Agent collects metrics
-every second.
-
-If you change this to `2`, Netdata enforces a minimum `update every` setting of 2 seconds, and collects metrics every
-other second, which will effectively halve CPU utilization. Set this to `5` or `10` to collect metrics every 5 or 10
-seconds, respectively.
-
-```conf
-[global]
-    update every = 5
-```
-
-### Specific plugin or collector
-
-Every collector and plugin has its own `update every` setting, which you can also change in the `go.d.conf`,
-`python.d.conf`, or `charts.d.conf` files, or in individual collector configuration files. If the `update
-every` for an individual collector is less than the global, the Netdata Agent uses the global setting. See
-the [collectors configuration reference](https://github.com/netdata/netdata/blob/master/src/collectors/REFERENCE.md) for
-details.
-
-To reduce the frequency of
-an [internal_plugin/collector](https://github.com/netdata/netdata/blob/master/src/collectors/README.md#collector-architecture-and-terminology),
-open `netdata.conf` and find the appropriate section. For example, to reduce the frequency of the `apps` plugin, which
-collects and visualizes metrics on application resource utilization:
-
-```conf
-[plugin:apps]
-    update every = 5
-```
-
-To [configure an individual collector](https://github.com/netdata/netdata/blob/master/src/collectors/REFERENCE.md#configure-a-collector),
-open its specific configuration file with `edit-config` and look for the `update_every` setting. For example, to reduce
-the frequency of the `nginx` collector, run `sudo ./edit-config go.d/nginx.conf`:
-
-```conf
-# [ GLOBAL ]
-update_every: 10
-```
-
-## Lower memory usage for metrics retention
-
-See how
-to [change how long Netdata stores metrics](https://github.com/netdata/netdata/blob/master/docs/store/change-metrics-storage.md).
-
-## Use a different metric storage database
-
-Consider [using a different metric storage database](https://github.com/netdata/netdata/blob/master/src/database/README.md)
-when running Netdata on IoT devices, and for children in a parent-child set up based
-on [streaming and replication](https://github.com/netdata/netdata/blob/master/docs/metrics-storage-management/enable-streaming.md).
-
-## Disable machine learning
-
-Automated anomaly detection may be a powerful tool, but we recommend it to only be enabled on Netdata parents that sit
-outside your production infrastructure, or if you have cpu and memory to spare. You can disable ML with the following:
-
-```conf
-[ml]
-   enabled = no
-```
-
-## Run Netdata behind a proxy
-
-A dedicated web server like nginx provides more robustness than the Agent's
-internal [web server](https://github.com/netdata/netdata/blob/master/src/web/README.md).
-Nginx can handle more concurrent connections, reuse idle connections, and use fast gzip compression to reduce payloads.
-
-For details on installing another web server as a proxy for the local Agent dashboard,
-see [reverse proxies](https://github.com/netdata/netdata/blob/master/docs/category-overview-pages/reverse-proxies.md).
-
-## Disable/lower gzip compression for the dashboard
-
-If you choose not to run the Agent behind Nginx, you can disable or lower the Agent's web server's gzip compression.
-While gzip compression does reduce the size of the HTML/CSS/JS payload, it does use additional CPU while a user is
-looking at the local Agent dashboard.
-
-To disable gzip compression, open `netdata.conf` and find the `[web]` section:
-
-```conf
-[web]
-    enable gzip compression = no
-```
-
-Or to lower the default compression level:
-
-```conf
-[web]
-    enable gzip compression = yes
-    gzip compression level = 1
-```
-
diff --git a/docs/guides/monitor-cockroachdb.md b/docs/guides/monitor-cockroachdb.md
deleted file mode 100644
index 9d4d3ea03c..0000000000
--- a/docs/guides/monitor-cockroachdb.md
+++ /dev/null
@@ -1,118 +0,0 @@
-<!--
-title: "Monitor CockroachDB metrics with Netdata"
-sidebar_label: "Monitor CockroachDB metrics with Netdata"
-custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/monitor-cockroachdb.md
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Miscellaneous"
--->
-
-# Monitor CockroachDB metrics with Netdata
-
-[CockroachDB](https://github.com/cockroachdb/cockroach) is an open-source project that brings SQL databases into
-scalable, disaster-resilient cloud deployments. Thanks to
-a [new CockroachDB collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/cockroachdb/README.md)
-released in
-[v1.20](https://blog.netdata.cloud/posts/release-1.20/), you can now monitor any number of CockroachDB databases with
-maximum granularity using Netdata. Collect more than 50 unique metrics and put them on interactive visualizations
-designed for better visual anomaly detection.
-
-Netdata itself uses CockroachDB as part of its Netdata Cloud infrastructure, so we're happy to introduce this new
-collector and help others get started with it straight away.
-
-Let's dive in and walk through the process of monitoring CockroachDB metrics with Netdata.
-
-## What's in this guide
-
-- [Monitor CockroachDB metrics with Netdata](#monitor-cockroachdb-metrics-with-netdata)
-  - [What's in this guide](#whats-in-this-guide)
-  - [Configure the CockroachDB collector](#configure-the-cockroachdb-collector)
-    - [Manual setup for a local CockroachDB database](#manual-setup-for-a-local-cockroachdb-database)
-  - [Tweak CockroachDB alerts](#tweak-cockroachdb-alerts)
-
-## Configure the CockroachDB collector
-
-Because _all_ of Netdata's collectors can auto-detect the services they monitor, you _shouldn't_ need to worry about
-configuring CockroachDB. Netdata only needs to regularly query the database's `_status/vars` page to gather metrics and
-display them on the dashboard.
-
-If your CockroachDB instance is accessible through `http://localhost:8080/` or `http://127.0.0.1:8080`, your setup is
-complete. Restart Netdata with `sudo systemctl restart netdata`, or the [appropriate
-method](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md#maintaining-a-netdata-agent-installation) for your system, and refresh your browser. You should see CockroachDB
-metrics in your Netdata dashboard!
-
-<figure>
-  <img src="https://user-images.githubusercontent.com/1153921/73564467-d7e36b00-441c-11ea-9ec9-b5d5ea7277d4.png" alt="CPU utilization charts from a CockroachDB database monitored by Netdata" />
-  <figcaption>CPU utilization charts from a CockroachDB database monitored by Netdata</figcaption>
-</figure>
-
-> Note: Netdata collects metrics from CockroachDB every 10 seconds, instead of our usual 1 second, because CockroachDB
-> only updates `_status/vars` every 10 seconds. You can't change this setting in CockroachDB.
-
-If you don't see CockroachDB charts, you may need to configure the collector manually.
-
-### Manual setup for a local CockroachDB database
-
-To configure Netdata's CockroachDB collector, navigate to your Netdata configuration directory (typically at
-`/etc/netdata/`) and use `edit-config` to initialize and edit your CockroachDB configuration file.
-
-```bash
-cd /etc/netdata/ # Replace with your Netdata configuration directory, if not /etc/netdata/
-./edit-config go.d/cockroachdb.conf
-```
-
-Scroll down to the `[JOBS]` section at the bottom of the file. You will see the two default jobs there, which you can
-edit, or create a new job with any of the parameters listed above in the file. Both the `name` and `url` values are
-required, and everything else is optional.
-
-For a production cluster, you'll use either an IP address or the system's hostname. Be sure that your remote system
-allows TCP communication on port 8080, or whichever port you have configured CockroachDB's 
-[Admin UI](https://www.cockroachlabs.com/docs/stable/monitoring-and-alerting.html#prometheus-endpoint) to listen on.
-
-```yaml
-# [ JOBS ]
-jobs:
-  - name: remote
-    url: http://203.0.113.0:8080/_status/vars
-
-  - name: remote_hostname
-    url: http://cockroachdb.example.com:8080/_status/vars
-```
-
-For a secure cluster, use `https` in the `url` field instead.
-
-```yaml
-# [ JOBS ]
-jobs:
-  - name: remote
-    url: https://203.0.113.0:8080/_status/vars
-    tls_skip_verify: yes # If your certificate is self-signed
-
-  - name: remote_hostname
-    url: https://cockroachdb.example.com:8080/_status/vars
-    tls_skip_verify: yes # If your certificate is self-signed
-```
-
-You can add as many jobs as you'd like based on how many CockroachDB databases you have—Netdata will create separate
-charts for each job. Once you've edited `cockroachdb.conf` according to the needs of your infrastructure, restart
-Netdata to see your new charts.
-
-<figure>
-  <img src="https://user-images.githubusercontent.com/1153921/73564469-d7e36b00-441c-11ea-8333-02ba0e1c294c.png" alt="Charts showing a node failure during a simulated test" />
-  <figcaption>Charts showing a node failure during a simulated test</figcaption>
-</figure>
-
-## Tweak CockroachDB alerts
-
-This release also includes eight pre-configured alerts for live nodes, such as whether the node is live, storage
-capacity, issues with replication, and the number of SQL connections/statements. See [health.d/cockroachdb.conf on
-GitHub](https://raw.githubusercontent.com/netdata/netdata/master/src/health/health.d/cockroachdb.conf) for details.
-
-You can also edit these files directly with `edit-config`:
-
-```bash
-cd /etc/netdata/ # Replace with your Netdata configuration directory, if not /etc/netdata/
-./edit-config health.d/cockroachdb.conf # You may need to use `sudo` for write privileges
-```
-
-For more information about editing the defaults or writing new alert entities, see our documentation on [configuring health alerts](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md).
diff --git a/docs/guides/monitor-hadoop-cluster.md b/docs/guides/monitor-hadoop-cluster.md
deleted file mode 100644
index b536e0fa03..0000000000
--- a/docs/guides/monitor-hadoop-cluster.md
+++ /dev/null
@@ -1,191 +0,0 @@
-<!--
-title: "Monitor a Hadoop cluster with Netdata"
-sidebar_label: "Monitor a Hadoop cluster with Netdata"
-custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/monitor-hadoop-cluster.md
-learn_status: "Published"
-learn_topic_type: "Tasks"
-learn_rel_path: "Miscellaneous"
--->
-
-# Monitor a Hadoop cluster with Netdata
-
-Hadoop is an [Apache project](https://hadoop.apache.org/) is a framework for processing large sets of data across a
-distributed cluster of systems.
-
-And while Hadoop is designed to be a highly-available and fault-tolerant service, those who operate a Hadoop cluster
-will want to monitor the health and performance of their [Hadoop Distributed File System
-(HDFS)](https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html) and [Zookeeper](https://zookeeper.apache.org/)
-implementations.
-
-Netdata comes with built-in and pre-configured support for monitoring both HDFS and Zookeeper.
-
-This guide assumes you have a Hadoop cluster, with HDFS and Zookeeper, running already. If you don't, please follow
-the [official Hadoop
-instructions](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/SingleCluster.html) or an
-alternative, like the guide available from
-[DigitalOcean](https://www.digitalocean.com/community/tutorials/how-to-install-hadoop-in-stand-alone-mode-on-ubuntu-18-04).
-
-For more specifics on the collection modules used in this guide, read the respective pages in our documentation:
-
--   [HDFS](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/hdfs/README.md)
--   [Zookeeper](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/zookeeper/README.md)
-
-## Set up your HDFS and Zookeeper installations
-
-As with all data sources, Netdata can auto-detect HDFS and Zookeeper nodes if you installed them using the standard
-installation procedure.
-
-For Netdata to collect HDFS metrics, it needs to be able to access the node's `/jmx` endpoint. You can test whether an
-JMX endpoint is accessible by using `curl HDFS-IP:PORT/jmx`. For a NameNode, you should see output similar to the
-following:
-
-```json
-{
-  "beans" : [ {
-    "name" : "Hadoop:service=NameNode,name=JvmMetrics",
-    "modelerType" : "JvmMetrics",
-    "MemNonHeapUsedM" : 65.67851,
-    "MemNonHeapCommittedM" : 67.3125,
-    "MemNonHeapMaxM" : -1.0,
-    "MemHeapUsedM" : 154.46341,
-    "MemHeapCommittedM" : 215.0,
-    "MemHeapMaxM" : 843.0,
-    "MemMaxM" : 843.0,
-    "GcCount" : 15,
-    "GcTimeMillis" : 305,
-    "GcNumWarnThresholdExceeded" : 0,
-    "GcNumInfoThresholdExceeded" : 0,
-    "GcTotalExtraSleepTime" : 92,
-    "ThreadsNew" : 0,
-    "ThreadsRunnable" : 6,
-    "ThreadsBlocked" : 0,
-    "ThreadsWaiting" : 7,
-    "ThreadsTimedWaiting" : 34,
-    "ThreadsTerminated" : 0,
-    "LogFatal" : 0,
-    "LogError" : 0,
-    "LogWarn" : 2,
-    "LogInfo" : 348
-  }, 
-  { ... }
-  ]
-}
-```
-
-The JSON result for a DataNode's `/jmx` endpoint is slightly different:
-
-```json
-{
-  "beans" : [ {
-    "name" : "Hadoop:service=DataNode,name=DataNodeActivity-dev-slave-01.dev.local-9866",
-    "modelerType" : "DataNodeActivity-dev-slave-01.dev.local-9866",
-    "tag.SessionId" : null,
-    "tag.Context" : "dfs",
-    "tag.Hostname" : "dev-slave-01.dev.local",
-    "BytesWritten" : 500960407,
-    "TotalWriteTime" : 463,
-    "BytesRead" : 80689178,
-    "TotalReadTime" : 41203,
-    "BlocksWritten" : 16,
-    "BlocksRead