Merging upstream version 1.38.0.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

5 files changed, 96 insertions, 79 deletions

diff --git a/docs/collect/application-metrics.md b/docs/collect/application-metrics.md
index c9bc4e2c8..454ed95ad 100644
--- a/docs/collect/application-metrics.md
+++ b/docs/collect/application-metrics.md
@@ -2,7 +2,10 @@
 title: "Collect application metrics with Netdata"
 sidebar_label: "Application metrics"
 description: "Monitor and troubleshoot every application on your infrastructure with per-second metrics, zero configuration, and meaningful charts."
-custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/collect/application-metrics.md
+custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/collect/application-metrics.md"
+learn_status: "Published"
+learn_topic_type: "Concepts"
+learn_rel_path: "Concepts"
 -->
 
 # Collect application metrics with Netdata
@@ -12,7 +15,7 @@ web servers, databases, message brokers, email servers, search platforms, and mu
 pre-installed with every Netdata Agent and usually require zero configuration. Netdata also collects and visualizes
 resource utilization per application on Linux systems using `apps.plugin`.
 
-[**apps.plugin**](/collectors/apps.plugin/README.md) looks at the Linux process tree every second, much like `top` or
+[**apps.plugin**](https://github.com/netdata/netdata/blob/master/collectors/apps.plugin/README.md) looks at the Linux process tree every second, much like `top` or
 `ps fax`, and collects resource utilization information on every running process. By reading the process tree, Netdata
 shows CPU, disk, networking, processes, and eBPF for every application or Linux user. Unlike `top` or `ps fax`, Netdata
 adds a layer of meaningful visualization on top of the process tree metrics, such as grouping applications into useful
@@ -21,43 +24,43 @@ charts under **Users**, and per-user group charts under **User Groups**.
 
 Our most popular application collectors:
 
-- [Prometheus endpoints](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus): Gathers
+- [Prometheus endpoints](https://github.com/netdata/go.d.plugin/blob/master/modules/prometheus/README.md): Gathers
   metrics from one or more Prometheus endpoints that use the OpenMetrics exposition format. Auto-detects more than 600
   endpoints.
-- [Web server logs (Apache, NGINX)](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/weblog/):
+- [Web server logs (Apache, NGINX)](https://github.com/netdata/go.d.plugin/blob/master/modules/weblog/README.md):
   Tail access logs and provide very detailed web server performance statistics. This module is able to parse 200k+
   rows in less than half a second.
-- [MySQL](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/mysql/): Collect database global,
+- [MySQL](https://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md): Collect database global,
   replication, and per-user statistics.
-- [Redis](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/redis): Monitor database status by
+- [Redis](https://github.com/netdata/go.d.plugin/blob/master/modules/redis/README.md): Monitor database status by
   reading the server's response to the `INFO` command.
-- [Apache](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/apache/): Collect Apache web server
+- [Apache](https://github.com/netdata/go.d.plugin/blob/master/modules/apache/README.md): Collect Apache web server
   performance metrics via the `server-status?auto` endpoint.
-- [Nginx](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/nginx/): Monitor web server status
+- [Nginx](https://github.com/netdata/go.d.plugin/blob/master/modules/nginx/README.md): Monitor web server status
   information by gathering metrics via `ngx_http_stub_status_module`.
-- [Postgres](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/postgres): Collect database health
+- [Postgres](https://github.com/netdata/go.d.plugin/blob/master/modules/postgres/README.md): Collect database health
   and performance metrics.
-- [ElasticSearch](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/elasticsearch): Collect search
+- [ElasticSearch](https://github.com/netdata/go.d.plugin/blob/master/modules/elasticsearch/README.md): Collect search
   engine performance and health statistics. Optionally collects per-index metrics.
-- [PHP-FPM](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/phpfpm/): Collect application summary
+- [PHP-FPM](https://github.com/netdata/go.d.plugin/blob/master/modules/phpfpm/README.md): Collect application summary
   and processes health metrics by scraping the status page (`/status?full`).
 
-Our [supported collectors list](/collectors/COLLECTORS.md#service-and-application-collectors) shows all Netdata's
+Our [supported collectors list](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md#service-and-application-collectors) shows all Netdata's
 application metrics collectors, including those for containers/k8s clusters.
 
 ## Collect metrics from applications running on Windows
 
 Netdata is fully capable of collecting and visualizing metrics from applications running on Windows systems. The only
-caveat is that you must [install Netdata](/docs/get-started.mdx) on a separate system or a compatible VM because there
+caveat is that you must [install Netdata](https://github.com/netdata/netdata/blob/master/docs/get-started.mdx) on a separate system or a compatible VM because there
 is no native Windows version of the Netdata Agent.
 
 Once you have Netdata running on that separate system, you can follow the [enable and configure
-doc](/docs/collect/enable-configure.md) to tell the collector to look for exposed metrics on the Windows system's IP
+doc](https://github.com/netdata/netdata/blob/master/docs/collect/enable-configure.md) to tell the collector to look for exposed metrics on the Windows system's IP
 address or hostname, plus the applicable port.
 
 For example, you have a MySQL database with a root password of `my-secret-pw` running on a Windows system with the IP
 address 203.0.113.0. you can configure the [MySQL
-collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/mysql) to look at `203.0.113.0:3306`:
+collector](https://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md) to look at `203.0.113.0:3306`:
 
 ```yml
 jobs:
@@ -66,16 +69,16 @@ jobs:
 ```
 
 This same logic applies to any application in our [supported collectors
-list](/collectors/COLLECTORS.md#service-and-application-collectors) that can run on Windows.
+list](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md#service-and-application-collectors) that can run on Windows.
 
 ## What's next?
 
-If you haven't yet seen the [supported collectors list](/collectors/COLLECTORS.md) give it a once-over for any
+If you haven't yet seen the [supported collectors list](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md) give it a once-over for any
 additional applications you may want to monitor using Netdata's native collectors, or the [generic Prometheus
-collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus).
+collector](https://github.com/netdata/go.d.plugin/blob/master/modules/prometheus/README.md).
 
 Collecting all the available metrics on your nodes, and across your entire infrastructure, is just one piece of the
 puzzle. Next, learn more about Netdata's famous real-time visualizations by [seeing an overview of your
-infrastructure](/docs/visualize/overview-infrastructure.md) using Netdata Cloud.
+infrastructure](https://github.com/netdata/netdata/blob/master/docs/visualize/overview-infrastructure.md) using Netdata Cloud.
 
 
diff --git a/docs/collect/container-metrics.md b/docs/collect/container-metrics.md
index 5d145362e..b6b6a432c 100644
--- a/docs/collect/container-metrics.md
+++ b/docs/collect/container-metrics.md
@@ -2,7 +2,10 @@
 title: "Collect container metrics with Netdata"
 sidebar_label: "Container metrics"
 description: "Use Netdata to collect per-second utilization and application-level metrics from Linux/Docker containers and Kubernetes clusters."
-custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/collect/container-metrics.md
+custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/collect/container-metrics.md"
+learn_status: "Published"
+learn_topic_type: "Concepts"
+learn_rel_path: "Concepts"
 -->
 
 # Collect container metrics with Netdata
@@ -10,35 +13,35 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/collect/con
 Thanks to close integration with Linux cgroups and the virtual files it maintains under `/sys/fs/cgroup`, Netdata can
 monitor the health, status, and resource utilization of many different types of Linux containers.
 
-Netdata uses [cgroups.plugin](/collectors/cgroups.plugin/README.md) to poll `/sys/fs/cgroup` and convert the raw data
+Netdata uses [cgroups.plugin](https://github.com/netdata/netdata/blob/master/collectors/cgroups.plugin/README.md) to poll `/sys/fs/cgroup` and convert the raw data
 into human-readable metrics and meaningful visualizations. Through cgroups, Netdata is compatible with **all Linux
 containers**, such as Docker, LXC, LXD, Libvirt, systemd-nspawn, and more. Read more about [Docker-specific
 monitoring](#collect-docker-metrics) below.
 
 Netdata also has robust **Kubernetes monitoring** support thanks to a
-[Helmchart](/packaging/installer/methods/kubernetes.md) to automate deployment, collectors for k8s agent services, and
+[Helmchart](https://github.com/netdata/netdata/blob/master/packaging/installer/methods/kubernetes.md) to automate deployment, collectors for k8s agent services, and
 robust [service discovery](https://github.com/netdata/agent-service-discovery/#service-discovery) to monitor the
 services running inside of pods in your k8s cluster. Read more about [Kubernetes
 monitoring](#collect-kubernetes-metrics) below.
 
 A handful of additional collectors gather metrics from container-related services, such as
-[dockerd](/collectors/python.d.plugin/dockerd/README.md) or [Docker
-Engine](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/docker_engine/). You can find all
+[dockerd](https://github.com/netdata/go.d.plugin/blob/master/modules/docker/README.md) or [Docker
+Engine](https://github.com/netdata/go.d.plugin/blob/master/modules/docker_engine/README.md). You can find all
 container collectors in our supported collectors list under the
-[containers/VMs](/collectors/COLLECTORS.md#containers-and-vms) and
-[Kubernetes](/collectors/COLLECTORS.md#containers-and-vms) headings.
+[containers/VMs](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md#containers-and-vms) and
+[Kubernetes](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md#containers-and-vms) headings.
 
 ## Collect Docker metrics
 
 Netdata has robust Docker monitoring thanks to the aforementioned
-[cgroups.plugin](/collectors/cgroups.plugin/README.md). By polling cgroups every second, Netdata can produce meaningful
+[cgroups.plugin](https://github.com/netdata/netdata/blob/master/collectors/cgroups.plugin/README.md). By polling cgroups every second, Netdata can produce meaningful
 visualizations about the CPU, memory, disk, and network utilization of all running containers on the host system with
 zero configuration.
 
 Netdata also collects metrics from applications running inside of Docker containers. For example, if you create a MySQL
 database container using `docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag`, it exposes
 metrics on port 3306. You can configure the [MySQL
-collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/mysql) to look at `127.0.0.0:3306` for
+collector](https://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md) to look at `127.0.0.0:3306` for
 MySQL metrics:
 
 ```yml
@@ -48,18 +51,18 @@ jobs:
 ```
 
 Netdata then collects metrics from the container itself, but also dozens [MySQL-specific
-metrics](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/mysql#charts) as well.
+metrics](https://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md#charts) as well.
 
 ### Collect metrics from applications running in Docker containers
 
 You could use this technique to monitor an entire infrastructure of Docker containers. The same [enable and
-configure](/docs/collect/enable-configure.md) procedures apply whether an application runs on the host system or inside
+configure](https://github.com/netdata/netdata/blob/master/docs/collect/enable-configure.md) procedures apply whether an application runs on the host system or inside
 a container. You may need to configure the target endpoint if it's not the application's default.
 
-Netdata can even [run in a Docker container](/packaging/docker/README.md) itself, and then collect metrics about the
+Netdata can even [run in a Docker container](https://github.com/netdata/netdata/blob/master/packaging/docker/README.md) itself, and then collect metrics about the
 host system, its own container with cgroups, and any applications you want to monitor.
 
-See our [application metrics doc](/docs/collect/application-metrics.md) for details about Netdata's application metrics
+See our [application metrics doc](https://github.com/netdata/netdata/blob/master/docs/collect/application-metrics.md) for details about Netdata's application metrics
 collection capabilities.
 
 ## Collect Kubernetes metrics
@@ -74,26 +77,26 @@ your k8s infrastructure.
     configuration files for [compatible
     applications](https://github.com/netdata/helmchart#service-discovery-and-supported-services) and any endpoints
     covered by our [generic Prometheus
-    collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus). With these
+    collector](https://github.com/netdata/go.d.plugin/blob/master/modules/prometheus/README.md). With these
     configuration files, Netdata collects metrics from any compatible applications as they run _inside_ of a pod.
     Service discovery happens without manual intervention as pods are created, destroyed, or moved between nodes. 
--   A [Kubelet collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/k8s_kubelet), which runs
+-   A [Kubelet collector](https://github.com/netdata/go.d.plugin/blob/master/modules/k8s_kubelet/README.md), which runs
     on each node in a k8s cluster to monitor the number of pods/containers, the volume of operations on each container,
     and more.
--   A [kube-proxy collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/k8s_kubeproxy), which
+-   A [kube-proxy collector](https://github.com/netdata/go.d.plugin/blob/master/modules/k8s_kubeproxy/README.md), which
     also runs on each node and monitors latency and the volume of HTTP requests to the proxy.
--   A [cgroups collector](/collectors/cgroups.plugin/README.md), which collects CPU, memory, and bandwidth metrics for
+-   A [cgroups collector](https://github.com/netdata/netdata/blob/master/collectors/cgroups.plugin/README.md), which collects CPU, memory, and bandwidth metrics for
     each container running on your k8s cluster.
 
 For a holistic view of Netdata's Kubernetes monitoring capabilities, see our guide: [_Monitor a Kubernetes (k8s) cluster
-with Netdata_](https://learn.netdata.cloud/guides/monitor/kubernetes-k8s-netdata).
+with Netdata_](https://github.com/netdata/netdata/blob/master/docs/guides/monitor/kubernetes-k8s-netdata.md).
 
 ## What's next?
 
 Netdata is capable of collecting metrics from hundreds of applications, such as web servers, databases, messaging
-brokers, and more. See more in the [application metrics doc](/docs/collect/application-metrics.md).
+brokers, and more. See more in the [application metrics doc](https://github.com/netdata/netdata/blob/master/docs/collect/application-metrics.md).
 
 If you already have all the information you need about collecting metrics, move into Netdata's meaningful visualizations
-with [seeing an overview of your infrastructure](/docs/visualize/overview-infrastructure.md) using Netdata Cloud.
+with [seeing an overview of your infrastructure](https://github.com/netdata/netdata/blob/master/docs/visualize/overview-infrastructure.md) using Netdata Cloud.
 
 
diff --git a/docs/collect/enable-configure.md b/docs/collect/enable-configure.md
index 19e680c21..cd8960ac1 100644
--- a/docs/collect/enable-configure.md
+++ b/docs/collect/enable-configure.md
@@ -1,14 +1,18 @@
 <!--
 title: "Enable or configure a collector"
 description: "Every collector is highly configurable, allowing them to collect metrics from any node and any infrastructure."
-custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/collect/enable-configure.md
+custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/collect/enable-configure.md"
+sidebar_label: "Enable or configure a collector"
+learn_status: "Published"
+learn_topic_type: "Tasks"
+learn_rel_path: "Setup"
 -->
 
 # Enable or configure a collector
 
 When Netdata starts up, each collector searches for exposed metrics on the default endpoint established by that service
 or application's standard installation procedure. For example, the [Nginx
-collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/nginx) searches at
+collector](https://github.com/netdata/go.d.plugin/blob/master/modules/nginx/README.md) searches at
 `http://127.0.0.1/stub_status` for exposed metrics in the correct format. If an Nginx web server is running and exposes
 metrics on that endpoint, the collector begins gathering them.
 
@@ -20,7 +24,7 @@ enable or configure a collector to gather all available metrics from your system
 You can enable/disable collectors individually, or enable/disable entire orchestrators, using their configuration files.
 For example, you can change the behavior of the Go orchestrator, or any of its collectors, by editing `go.d.conf`.
 
-Use `edit-config` from your [Netdata config directory](/docs/configure/nodes.md#the-netdata-config-directory) to open
+Use `edit-config` from your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) to open
 the orchestrator primary configuration file:
 
 ```bash
@@ -33,14 +37,14 @@ enable/disable it with `yes` and `no` settings. Uncomment any line you change to
 start.
 
 After you make your changes, restart the Agent with `sudo systemctl restart netdata`, or the [appropriate
-method](/docs/configure/start-stop-restart.md) for your system.
+method](https://github.com/netdata/netdata/blob/master/docs/configure/start-stop-restart.md) for your system.
 
 ## Configure a collector
 
-First, [find the collector](/collectors/COLLECTORS.md) you want to edit and open its documentation. Some software has
+First, [find the collector](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md) you want to edit and open its documentation. Some software has
 collectors written in multiple languages. In these cases, you should always pick the collector written in Go.
 
-Use `edit-config` from your [Netdata config directory](/docs/configure/nodes.md#the-netdata-config-directory) to open a
+Use `edit-config` from your [Netdata config directory](https://github.com/netdata/netdata/blob/master/docs/configure/nodes.md#the-netdata-config-directory) to open a
 collector's configuration file. For example, edit the Nginx collector with the following:
 
 ```bash
@@ -53,16 +57,16 @@ configure that collector. Uncomment any line you change to ensure the collector'
 read it on start.
 
 After you make your changes, restart the Agent with `sudo systemctl restart netdata`, or the [appropriate
-method](/docs/configure/start-stop-restart.md) for your system.
+method](https://github.com/netdata/netdata/blob/master/docs/configure/start-stop-restart.md) for your system.
 
 ## What's next?
 
-Read high-level overviews on how Netdata collects [system metrics](/docs/collect/system-metrics.md), [container
-metrics](/docs/collect/container-metrics.md), and [application metrics](/docs/collect/application-metrics.md).
+Read high-level overviews on how Netdata collects [system metrics](https://github.com/netdata/netdata/blob/master/docs/collect/system-metrics.md), [container
+metrics](https://github.com/netdata/netdata/blob/master/docs/collect/container-metrics.md), and [application metrics](https://github.com/netdata/netdata/blob/master/docs/collect/application-metrics.md).
 
 If you're already collecting all metrics from your systems, containers, and applications, it's time to move into
-Netdata's visualization features. [See an overview of your infrastructure](/docs/visualize/overview-infrastructure.md)
+Netdata's visualization features. [See an overview of your infrastructure](https://github.com/netdata/netdata/blob/master/docs/visualize/overview-infrastructure.md)
 using Netdata Cloud, or learn how to [interact with dashboards and
-charts](/docs/visualize/interact-dashboards-charts.md).
+charts](https://github.com/netdata/netdata/blob/master/docs/visualize/interact-dashboards-charts.md).
 
 
diff --git a/docs/collect/how-collectors-work.md b/docs/collect/how-collectors-work.md
index 07e34858f..382d4ccc6 100644
--- a/docs/collect/how-collectors-work.md
+++ b/docs/collect/how-collectors-work.md
@@ -1,7 +1,11 @@
 <!--
 title: "How Netdata's metrics collectors work"
 description: "When Netdata starts, and with zero configuration, it auto-detects thousands of data sources and immediately collects per-second metrics."
-custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/collect/how-collectors-work.md
+custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/collect/how-collectors-work.md"
+sidebar_label: "How Netdata's metrics collectors work"
+learn_status: "Published"
+learn_topic_type: "Concepts"
+learn_rel_path: "Concepts"
 -->
 
 # How Netdata's metrics collectors work
@@ -10,7 +14,7 @@ When Netdata starts, and with zero configuration, it auto-detects thousands of d
 per-second metrics.
 
 Netdata can immediately collect metrics from these endpoints thanks to 300+ **collectors**, which all come pre-installed
-when you [install Netdata](/docs/get-started.mdx).
+when you [install Netdata](https://github.com/netdata/netdata/blob/master/docs/get-started.mdx).
 
 Every collector has two primary jobs:
 
@@ -19,15 +23,15 @@ Every collector has two primary jobs:
 
 If the collector finds compatible metrics exposed on the configured endpoint, it begins a per-second collection job. The
 Netdata Agent gathers these metrics, sends them to the [database engine for
-storage](/docs/store/change-metrics-storage.md), and immediately [visualizes them
-meaningfully](/docs/visualize/interact-dashboards-charts.md) on dashboards.
+storage](https://github.com/netdata/netdata/blob/master/docs/store/change-metrics-storage.md), and immediately [visualizes them
+meaningfully](https://github.com/netdata/netdata/blob/master/docs/visualize/interact-dashboards-charts.md) on dashboards.
 
 Each collector comes with a pre-defined configuration that matches the default setup for that application. This endpoint
 can be a URL and port, a socket, a file, a web page, and more.
 
-For example, the [Nginx collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/nginx) searches
+For example, the [Nginx collector](https://github.com/netdata/go.d.plugin/blob/master/modules/nginx/README.md) searches
 at `http://127.0.0.1/stub_status`, which is the default endpoint for exposing Nginx metrics. The [web log collector for
-Nginx or Apache](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/weblog) searches at
+Nginx or Apache](https://github.com/netdata/go.d.plugin/blob/master/README.mdmodules/weblog) searches at
 `/var/log/nginx/access.log` and `/var/log/apache2/access.log`, respectively, both of which are standard locations for
 access log files on Linux systems.
 
@@ -35,15 +39,15 @@ The endpoint is user-configurable, as are many other specifics of what a given c
 
 ## What can Netdata collect?
 
-To quickly find your answer, see our [list of supported collectors](/collectors/COLLECTORS.md).
+To quickly find your answer, see our [list of supported collectors](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md).
 
 Generally, Netdata's collectors can be grouped into three types:
 
--   [Systems](/docs/collect/system-metrics.md): Monitor CPU, memory, disk, networking, systemd, eBPF, and much more.
+-   [Systems](https://github.com/netdata/netdata/blob/master/docs/collect/system-metrics.md): Monitor CPU, memory, disk, networking, systemd, eBPF, and much more.
     Every metric exposed by `/proc`, `/sys`, and other Linux kernel sources.
--   [Containers](/docs/collect/container-metrics.md): Gather metrics from container agents, like `dockerd` or `kubectl`,
+-   [Containers](https://github.com/netdata/netdata/blob/master/docs/collect/container-metrics.md): Gather metrics from container agents, like `dockerd` or `kubectl`,
     along with the resource usage of containers and the applications they run.
--   [Applications](/docs/collect/application-metrics.md): Collect per-second metrics from web servers, databases, logs,
+-   [Applications](https://github.com/netdata/netdata/blob/master/docs/collect/application-metrics.md): Collect per-second metrics from web servers, databases, logs,
     message brokers, APM tools, email servers, and much more.
 
 ## Collector architecture and terminology
@@ -56,11 +60,11 @@ terms related to collecting metrics.
 -   **Modules** are a type of collector.
 -   **Orchestrators** are external plugins that run and manage one or more modules. They run as independent processes.
     The Go orchestrator is in active development.
-    -   [go.d.plugin](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/): An orchestrator for data
+    -   [go.d.plugin](https://github.com/netdata/go.d.plugin/blob/master/README.md): An orchestrator for data
         collection modules written in `go`.
-    -   [python.d.plugin](/collectors/python.d.plugin/README.md): An orchestrator for data collection modules written in
+    -   [python.d.plugin](https://github.com/netdata/netdata/blob/master/collectors/python.d.plugin/README.md): An orchestrator for data collection modules written in
         `python` v2/v3.
-    -   [charts.d.plugin](/collectors/charts.d.plugin/README.md): An orchestrator for data collection modules written in
+    -   [charts.d.plugin](https://github.com/netdata/netdata/blob/master/collectors/charts.d.plugin/README.md): An orchestrator for data collection modules written in
         `bash` v4+.
 -   **External plugins** gather metrics from external processes, such as a webserver or database, and run as independent
     processes that communicate with the Netdata daemon via pipes.
@@ -69,10 +73,10 @@ terms related to collecting metrics.
 
 ## What's next?
 
-[Enable or configure a collector](/docs/collect/enable-configure.md) if the default settings are not compatible with
+[Enable or configure a collector](https://github.com/netdata/netdata/blob/master/docs/collect/enable-configure.md) if the default settings are not compatible with
 your infrastructure.
 
-See our [collectors reference](/collectors/REFERENCE.md) for detailed information on Netdata's collector architecture,
+See our [collectors reference](https://github.com/netdata/netdata/blob/master/collectors/REFERENCE.md) for detailed information on Netdata's collector architecture,
 troubleshooting a collector, developing a custom collector, and more.
 
 
diff --git a/docs/collect/system-metrics.md b/docs/collect/system-metrics.md
index ecd8dad70..442b13823 100644
--- a/docs/collect/system-metrics.md
+++ b/docs/collect/system-metrics.md
@@ -2,59 +2,62 @@
 title: "Collect system metrics with Netdata"
 sidebar_label: "System metrics"
 description: "Netdata collects thousands of metrics from physical and virtual systems, IoT/edge devices, and containers with zero configuration."
-custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/collect/system-metrics.md
+custom_edit_url: "https://github.com/netdata/netdata/edit/master/docs/collect/system-metrics.md"
+learn_status: "Published"
+learn_topic_type: "Concepts"
+learn_rel_path: "Concepts"
 -->
 
 # Collect system metrics with Netdata
 
 Netdata collects thousands of metrics directly from the operating systems of physical and virtual systems, IoT/edge
-devices, and [containers](/docs/collect/container-metrics.md) with zero configuration.
+devices, and [containers](https://github.com/netdata/netdata/blob/master/docs/collect/container-metrics.md) with zero configuration.
 
 To gather system metrics, Netdata uses roughly a dozen plugins, each of which has one or more collectors for very
 specific metrics exposed by the host. The system metrics Netdata users interact with most for health monitoring and
 performance troubleshooting are collected and visualized by `proc.plugin`, `cgroups.plugin`, and `ebpf.plugin`.
 
-[**proc.plugin**](/collectors/proc.plugin/README.md) gathers metrics from the `/proc` and `/sys` folders in Linux
+[**proc.plugin**](https://github.com/netdata/netdata/blob/master/collectors/proc.plugin/README.md) gathers metrics from the `/proc` and `/sys` folders in Linux
 systems, along with a few other endpoints, and is responsible for the bulk of the system metrics collected and
 visualized by Netdata. It collects CPU, memory, disks, load, networking, mount points, and more with zero configuration.
 It even allows Netdata to monitor its own resource utilization!
 
-[**cgroups.plugin**](/collectors/cgroups.plugin/README.md) collects rich metrics about containers and virtual machines
+[**cgroups.plugin**](https://github.com/netdata/netdata/blob/master/collectors/cgroups.plugin/README.md) collects rich metrics about containers and virtual machines
 using the virtual files under `/sys/fs/cgroup`. By reading cgroups, Netdata can instantly collect resource utilization
 metrics for systemd services, all containers (Docker, LXC, LXD, Libvirt, systemd-nspawn), and more. Learn more in the
-[collecting container metrics](/docs/collect/container-metrics.md) doc.
+[collecting container metrics](https://github.com/netdata/netdata/blob/master/docs/collect/container-metrics.md) doc.
 
-[**ebpf.plugin**](/collectors/ebpf.plugin/README.md): Netdata's extended Berkeley Packet Filter (eBPF) collector
+[**ebpf.plugin**](https://github.com/netdata/netdata/blob/master/collectors/ebpf.plugin/README.md): Netdata's extended Berkeley Packet Filter (eBPF) collector
 monitors Linux kernel-level metrics for file descriptors, virtual filesystem IO, and process management. You can use our
 eBPF collector to analyze how and when a process accesses files, when it makes system calls, whether it leaks memory or
 creating zombie processes, and more.
 
 While the above plugins and associated collectors are the most important for system metrics, there are many others. You
-can find all system collectors in our [supported collectors list](/collectors/COLLECTORS.md#system-collectors).
+can find all system collectors in our [supported collectors list](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md#system-collectors).
 
 ## Collect Windows system metrics
 
 Netdata is also capable of monitoring Windows systems. The [WMI
-collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/wmi) integrates with
+collector](https://github.com/netdata/go.d.plugin/blob/master/modules/wmi/README.md) integrates with
 [windows_exporter](https://github.com/prometheus-community/windows_exporter), a small Go-based binary that you can run
 on Windows systems. The WMI collector then gathers metrics from an endpoint created by windows_exporter, for more
-details see [the requirements](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/wmi#requirements).
+details see [the requirements](https://github.com/netdata/go.d.plugin/blob/master/modules/wmi/README.md#requirements).
 
 Next, [configure the WMI
-collector](https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/wmi#configuration) to point to the URL
+collector](https://github.com/netdata/go.d.plugin/blob/master/modules/wmi/README.md#configuration) to point to the URL
 and port of your exposed endpoint. Restart Netdata with `sudo systemctl restart netdata`, or the [appropriate
-method](/docs/configure/start-stop-restart.md) for your system. You'll start seeing Windows system metrics, such as CPU
+method](https://github.com/netdata/netdata/blob/master/docs/configure/start-stop-restart.md) for your system. You'll start seeing Windows system metrics, such as CPU
 utilization, memory, bandwidth per NIC, number of processes, and much more.
 
 For information about collecting metrics from applications _running on Windows systems_, see the [application metrics
-doc](/docs/collect/application-metrics.md#collect-metrics-from-applications-running-on-windows).
+doc](https://github.com/netdata/netdata/blob/master/docs/collect/application-metrics.md#collect-metrics-from-applications-running-on-windows).
 
 ## What's next?
 
-Because there's some overlap between system metrics and [container metrics](/docs/collect/container-metrics.md), you
+Because there's some overlap between system metrics and [container metrics](https://github.com/netdata/netdata/blob/master/docs/collect/container-metrics.md), you
 should investigate Netdata's container compatibility if you use them heavily in your infrastructure.
 
-If you don't use containers, skip ahead to collecting [application metrics](/docs/collect/application-metrics.md) with
+If you don't use containers, skip ahead to collecting [application metrics](https://github.com/netdata/netdata/blob/master/docs/collect/application-metrics.md) with
 Netdata.