Fix links pointing to old go.d repo and update the integrations (#17040)

* staging test

* replace links and re-run integrations scripts

13 files changed, 48 insertions, 48 deletions

diff --git a/docs/cloud/manage/organize-your-infrastrucutre-invite-your-team.md b/docs/cloud/manage/organize-your-infrastrucutre-invite-your-team.md
index 58877b7555..1f3828556e 100644
--- a/docs/cloud/manage/organize-your-infrastrucutre-invite-your-team.md
+++ b/docs/cloud/manage/organize-your-infrastrucutre-invite-your-team.md
@@ -106,7 +106,7 @@ We recommend a few strategies for organizing your War Rooms.
 
 - **Incident response**  
   You can also create new War Rooms as one of the first steps in your incident response process.
-   For example, you have a user-facing web app that relies on Apache Pulsar for a message queue, and one of your nodes using the [Pulsar collector](https://github.com/netdata/go.d.plugin/blob/master/modules/pulsar/README.md) begins reporting a suspiciously low messages rate.
+   For example, you have a user-facing web app that relies on Apache Pulsar for a message queue, and one of your nodes using the [Pulsar collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/pulsar/README.md) begins reporting a suspiciously low messages rate.
    You can create a War Room called `$year-$month-$day-pulsar-rate`, add all your Pulsar nodes in addition to nodes they connect to, and begin diagnosing the root cause in a War Room optimized for getting to resolution as fast as possible.
 
 ### Add War Rooms
diff --git a/docs/cloud/visualize/overview.md b/docs/cloud/visualize/overview.md
index 84638f0589..a2935d6248 100644
--- a/docs/cloud/visualize/overview.md
+++ b/docs/cloud/visualize/overview.md
@@ -31,7 +31,7 @@ monitor an Apache web server, the **Apache** section still appears and displays
 One difference between the Netdata Cloud menu and those found in local Agent dashboards is that
 the Overview condenses multiple services, families, or instances into single sections, sub-menus, and associated charts.
 
-For services, let's say you have two concurrent jobs with the [web_log collector](https://github.com/netdata/go.d.plugin/blob/master/modules/weblog/README.md), one for Apache and another for Nginx.
+For services, let's say you have two concurrent jobs with the [web_log collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/weblog/README.md), one for Apache and another for Nginx.
 A single-node or local dashboard shows two section, **web_log apache** and **web_log nginx**, whereas the Overview condenses these into a
 single **web_log** section containing composite charts from both jobs.
 
diff --git a/docs/collect/application-metrics.md b/docs/collect/application-metrics.md
index 3ffa540be4..f3c97ee1a0 100644
--- a/docs/collect/application-metrics.md
+++ b/docs/collect/application-metrics.md
@@ -24,25 +24,25 @@ charts under **Users**, and per-user group charts under **User Groups**.
 
 Our most popular application collectors:
 
-- [Prometheus endpoints](https://github.com/netdata/go.d.plugin/blob/master/modules/prometheus/README.md): Gathers
+- [Prometheus endpoints](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/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://github.com/netdata/go.d.plugin/blob/master/modules/weblog/README.md):
+- [Web server logs (Apache, NGINX)](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/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://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md): Collect database global,
+- [MySQL](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/mysql/README.md): Collect database global,
   replication, and per-user statistics.
-- [Redis](https://github.com/netdata/go.d.plugin/blob/master/modules/redis/README.md): Monitor database status by
+- [Redis](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/redis/README.md): Monitor database status by
   reading the server's response to the `INFO` command.
-- [Apache](https://github.com/netdata/go.d.plugin/blob/master/modules/apache/README.md): Collect Apache web server
+- [Apache](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/apache/README.md): Collect Apache web server
   performance metrics via the `server-status?auto` endpoint.
-- [Nginx](https://github.com/netdata/go.d.plugin/blob/master/modules/nginx/README.md): Monitor web server status
+- [Nginx](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/nginx/README.md): Monitor web server status
   information by gathering metrics via `ngx_http_stub_status_module`.
-- [Postgres](https://github.com/netdata/go.d.plugin/blob/master/modules/postgres/README.md): Collect database health
+- [Postgres](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/postgres/README.md): Collect database health
   and performance metrics.
-- [ElasticSearch](https://github.com/netdata/go.d.plugin/blob/master/modules/elasticsearch/README.md): Collect search
+- [ElasticSearch](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/elasticsearch/README.md): Collect search
   engine performance and health statistics. Optionally collects per-index metrics.
-- [PHP-FPM](https://github.com/netdata/go.d.plugin/blob/master/modules/phpfpm/README.md): Collect application summary
+- [PHP-FPM](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/phpfpm/README.md): Collect application summary
   and processes health metrics by scraping the status page (`/status?full`).
 
 Our [supported collectors list](https://github.com/netdata/netdata/blob/master/src/collectors/COLLECTORS.md#service-and-application-collectors) shows all Netdata's
@@ -59,7 +59,7 @@ 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://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md) to look at `203.0.113.0:3306`:
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/mysql/README.md) to look at `203.0.113.0:3306`:
 
 ```yml
 jobs:
@@ -74,7 +74,7 @@ list](https://github.com/netdata/netdata/blob/master/src/collectors/COLLECTORS.m
 
 If you haven't yet seen the [supported collectors list](https://github.com/netdata/netdata/blob/master/src/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://github.com/netdata/go.d.plugin/blob/master/modules/prometheus/README.md).
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/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
diff --git a/docs/collect/container-metrics.md b/docs/collect/container-metrics.md
index 44fa1104d5..aecf7eee28 100644
--- a/docs/collect/container-metrics.md
+++ b/docs/collect/container-metrics.md
@@ -25,8 +25,8 @@ 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](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
+[dockerd](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/docker/README.md) or [Docker
+Engine](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/docker_engine/README.md). You can find all
 container collectors in our supported collectors list under the
 [containers/VMs](https://github.com/netdata/netdata/blob/master/src/collectors/COLLECTORS.md#containers-and-vms) and
 [Kubernetes](https://github.com/netdata/netdata/blob/master/src/collectors/COLLECTORS.md#containers-and-vms) headings.
@@ -41,7 +41,7 @@ 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://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md) to look at `127.0.0.0:3306` for
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/mysql/README.md) to look at `127.0.0.0:3306` for
 MySQL metrics:
 
 ```yml
@@ -51,7 +51,7 @@ jobs:
 ```
 
 Netdata then collects metrics from the container itself, but also dozens [MySQL-specific
-metrics](https://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md#charts) as well.
+metrics](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/mysql/README.md#charts) as well.
 
 ### Collect metrics from applications running in Docker containers
 
@@ -76,13 +76,13 @@ 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://github.com/netdata/go.d.plugin/blob/master/modules/prometheus/README.md). With these
+    collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/prometheus/README.md). With these
     configuration files, Netdata collects metrics from any compatible applications as they run _inside_ a pod.
     Service discovery happens without manual intervention as pods are created, destroyed, or moved between nodes. 
--   A [Kubelet collector](https://github.com/netdata/go.d.plugin/blob/master/modules/k8s_kubelet/README.md), which runs
+-   A [Kubelet collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/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://github.com/netdata/go.d.plugin/blob/master/modules/k8s_kubeproxy/README.md), which
+-   A [kube-proxy collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/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](https://github.com/netdata/netdata/blob/master/src/collectors/cgroups.plugin/README.md), which collects CPU, memory, and bandwidth metrics for
     each container running on your k8s cluster.
diff --git a/docs/collect/system-metrics.md b/docs/collect/system-metrics.md
index 68c6895584..e4051b0faf 100644
--- a/docs/collect/system-metrics.md
+++ b/docs/collect/system-metrics.md
@@ -38,12 +38,12 @@ can find all system collectors in our [supported collectors list](https://github
 ## Collect Windows system metrics
 
 Netdata is also capable of monitoring Windows systems. The [Windows
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/windows/README.md) integrates with
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/windows/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 Windows collector then gathers metrics from an endpoint created by windows_exporter, for more
-details see [the requirements](https://github.com/netdata/go.d.plugin/blob/master/modules/windows/README.md#requirements).
+details see [the requirements](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/windows/README.md#requirements).
 
-Next, [configure](https://github.com/netdata/go.d.plugin/blob/master/modules/windows/README.md#configuration) the Windows
+Next, [configure](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/windows/README.md#configuration) the Windows
 collector to point to the URL and port of your exposed endpoint. 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'll start seeing Windows system metrics, such as CPU
 utilization, memory, bandwidth per NIC, number of processes, and much more.
diff --git a/docs/getting-started/introduction.md b/docs/getting-started/introduction.md
index 2195cb869a..65fd059d0e 100644
--- a/docs/getting-started/introduction.md
+++ b/docs/getting-started/introduction.md
@@ -120,7 +120,7 @@ Here are a few ways to enrich your existing monitoring and troubleshooting stack
 ### Collect metrics from Prometheus endpoints
 
 Netdata automatically detects 600 popular endpoints and collects per-second metrics from them via the [generic
-Prometheus collector](https://github.com/netdata/go.d.plugin/blob/master/modules/prometheus/README.md). This even
+Prometheus collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/prometheus/README.md). This even
 includes support for Windows 10 via [`windows_exporter`](https://github.com/prometheus-community/windows_exporter).
 
 This collector is installed and enabled on all Agent installations by default, so you don't need to waste time
diff --git a/docs/guides/collect-apache-nginx-web-logs.md b/docs/guides/collect-apache-nginx-web-logs.md
index d24557b164..055219935b 100644
--- a/docs/guides/collect-apache-nginx-web-logs.md
+++ b/docs/guides/collect-apache-nginx-web-logs.md
@@ -8,7 +8,7 @@ You can use the [LTSV log format](http://ltsv.org/), track TLS and cipher usage,
 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/go.d.plugin/blob/master/modules/weblog/README.md) collector is currently compatible
+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
@@ -91,7 +91,7 @@ The web log collector is capable of parsing custom Nginx and Apache log formats
 leave that topic for a separate guide.
 
 We do have [extensive
-documentation](https://github.com/netdata/go.d.plugin/blob/master/modules/weblog/README.md#custom-log-format) on how
+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
diff --git a/docs/guides/collect-unbound-metrics.md b/docs/guides/collect-unbound-metrics.md
index 65655d484c..5467592a07 100644
--- a/docs/guides/collect-unbound-metrics.md
+++ b/docs/guides/collect-unbound-metrics.md
@@ -110,7 +110,7 @@ method](https://github.com/netdata/netdata/blob/master/packaging/installer/READM
 
 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/go.d.plugin/blob/master/config/go.d/unbound.conf) contains a few useful examples:
+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:
@@ -132,7 +132,7 @@ jobs:
 ```
 
 To see all the available options, see the default [unbound.conf
-file](https://github.com/netdata/go.d.plugin/blob/master/config/go.d/unbound.conf).
+file](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/config/go.d/unbound.conf).
 
 ## What's next?
 
diff --git a/docs/guides/monitor-cockroachdb.md b/docs/guides/monitor-cockroachdb.md
index f36af4d23c..9d4d3ea03c 100644
--- a/docs/guides/monitor-cockroachdb.md
+++ b/docs/guides/monitor-cockroachdb.md
@@ -11,7 +11,7 @@ learn_rel_path: "Miscellaneous"
 
 [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/go.d.plugin/blob/master/modules/cockroachdb/README.md)
+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
diff --git a/docs/guides/monitor-hadoop-cluster.md b/docs/guides/monitor-hadoop-cluster.md
index 963daaf3eb..b536e0fa03 100644
--- a/docs/guides/monitor-hadoop-cluster.md
+++ b/docs/guides/monitor-hadoop-cluster.md
@@ -27,8 +27,8 @@ alternative, like the guide available from
 
 For more specifics on the collection modules used in this guide, read the respective pages in our documentation:
 
--   [HDFS](https://github.com/netdata/go.d.plugin/blob/master/modules/hdfs/README.md)
--   [Zookeeper](https://github.com/netdata/go.d.plugin/blob/master/modules/zookeeper/README.md)
+-   [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
 
diff --git a/docs/guides/monitor/kubernetes-k8s-netdata.md b/docs/guides/monitor/kubernetes-k8s-netdata.md
index f70e9827e1..982c35e793 100644
--- a/docs/guides/monitor/kubernetes-k8s-netdata.md
+++ b/docs/guides/monitor/kubernetes-k8s-netdata.md
@@ -146,7 +146,7 @@ Let's explore the most colorful box by hovering over it.
 container](https://user-images.githubusercontent.com/1153921/109049544-a8417980-7695-11eb-80a7-109b4a645a27.png)
 
 The **Context** tab shows `rabbitmq-5bb66bb6c9-6xr5b` as the container's image name, which means this container is
-running a [RabbitMQ](https://github.com/netdata/go.d.plugin/blob/master/modules/rabbitmq/README.md) workload.
+running a [RabbitMQ](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/rabbitmq/README.md) workload.
 
 Click the **Metrics** tab to see real-time metrics from that container. Unsurprisingly, it shows a spike in CPU
 utilization at regular intervals.
@@ -175,13 +175,13 @@ for complete customization. For example, grouping the top chart by `k8s_containe
 Netdata has a [service discovery plugin](https://github.com/netdata/agent-service-discovery), which discovers and
 creates configuration files for [compatible
 services](https://github.com/netdata/helmchart#service-discovery-and-supported-services) and any endpoints covered by
-our [generic Prometheus collector](https://github.com/netdata/go.d.plugin/blob/master/modules/prometheus/README.md).
+our [generic Prometheus collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/prometheus/README.md).
 Netdata uses these files to collect metrics from any compatible application as they run _inside_ of a pod. Service
 discovery happens without manual intervention as pods are created, destroyed, or moved between nodes.
 
 Service metrics show up on the Overview as well, beneath the **Kubernetes** section, and are labeled according to the
 service in question. For example, the **RabbitMQ** section has numerous charts from the [`rabbitmq`
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/rabbitmq/README.md):
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/rabbitmq/README.md):
 
 ![Finding service discovery
 metrics](https://user-images.githubusercontent.com/1153921/109054511-2eac8a00-769b-11eb-97f1-da93acb4b5fe.png)
@@ -202,7 +202,7 @@ Netdata also automatically collects metrics from two essential Kubernetes proces
 
 The **k8s kubelet** section visualizes metrics from the Kubernetes agent responsible for managing every pod on a given
 node. This also happens without any configuration thanks to the [kubelet
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/k8s_kubelet/README.md).
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/k8s_kubelet/README.md).
 
 Monitoring each node's kubelet can be invaluable when diagnosing issues with your Kubernetes cluster. For example, you
 can see if the number of running containers/pods has dropped, which could signal a fault or crash in a particular
@@ -218,7 +218,7 @@ configuration-related errors, and the actual vs. desired numbers of volumes, plu
 The **k8s kube-proxy** section displays metrics about the network proxy that runs on each node in your Kubernetes
 cluster. kube-proxy lets pods communicate with each other and accept sessions from outside your cluster. Its metrics are
 collected by the [kube-proxy
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/k8s_kubeproxy/README.md).
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/k8s_kubeproxy/README.md).
 
 With Netdata, you can monitor how often your k8s proxies are syncing proxy rules between nodes. Dramatic changes in
 these figures could indicate an anomaly in your cluster that's worthy of further investigation.
@@ -238,9 +238,9 @@ clusters of all sizes.
 - [Netdata Helm chart](https://github.com/netdata/helmchart)
 - [Netdata service discovery](https://github.com/netdata/agent-service-discovery)
 - [Netdata Agent · `kubelet`
-  collector](https://github.com/netdata/go.d.plugin/blob/master/modules/k8s_kubelet/README.md)
+  collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/k8s_kubelet/README.md)
 - [Netdata Agent · `kube-proxy`
-  collector](https://github.com/netdata/go.d.plugin/blob/master/modules/k8s_kubeproxy/README.md)
+  collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/k8s_kubeproxy/README.md)
 - [Netdata Agent · `cgroups.plugin`](https://github.com/netdata/netdata/blob/master/src/collectors/cgroups.plugin/README.md)
 
 
diff --git a/docs/guides/monitor/lamp-stack.md b/docs/guides/monitor/lamp-stack.md
index 340732c018..cc649dba9e 100644
--- a/docs/guides/monitor/lamp-stack.md
+++ b/docs/guides/monitor/lamp-stack.md
@@ -69,7 +69,7 @@ metrics from each using the [cgroups data collector](https://github.com/netdata/
 ## Enable Apache monitoring
 
 Let's begin by configuring Apache to work with Netdata's [Apache data
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/apache/README.md).
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/apache/README.md).
 
 Actually, there's nothing for you to do to enable Apache monitoring with Netdata.
 
@@ -80,7 +80,7 @@ metrics](https://httpd.apache.org/docs/2.4/mod/mod_status.html), which is just _
 ## Enable web log monitoring
 
 The Netdata Agent also comes with a [web log
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/weblog/README.md), which reads Apache's access
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/weblog/README.md), which reads Apache's access
 log file, processes each line, and converts them into per-second metrics. On Debian systems, it reads the file at
 `/var/log/apache2/access.log`.
 
@@ -93,7 +93,7 @@ monitoring.
 
 Because your MySQL database is password-protected, you do need to tell MySQL to allow the `netdata` user to connect to
 without a password. Netdata's [MySQL data
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md) collects metrics in _read-only_
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/mysql/README.md) collects metrics in _read-only_
 mode, without being able to alter or affect operations in any way.
 
 First, log into the MySQL shell. Then, run the following three commands, one at a time:
@@ -113,7 +113,7 @@ Unlike Apache or MySQL, PHP isn't a service that you can monitor directly, unles
 with [StatsD](https://github.com/netdata/netdata/blob/master/src/collectors/statsd.plugin/README.md).
 
 However, if you use [PHP-FPM](https://php-fpm.org/) in your LAMP stack, you can monitor that process with our [PHP-FPM
-data collector](https://github.com/netdata/go.d.plugin/blob/master/modules/phpfpm/README.md).
+data collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/phpfpm/README.md).
 
 Open your PHP-FPM configuration for editing, replacing `7.4` with your version of PHP:
 
@@ -215,7 +215,7 @@ services. The per-second metrics granularity means you have the most accurate in
 any LAMP-related issues.
 
 Another powerful way to monitor the availability of a LAMP stack is the [`httpcheck`
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/httpcheck/README.md), which pings a web server at
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/httpcheck/README.md), which pings a web server at
 a regular interval and tells you whether if and how quickly it's responding. The `response_match` option also lets you
 monitor when the web server's response isn't what you expect it to be, which might happen if PHP-FPM crashes, for
 example.
@@ -231,8 +231,8 @@ source of issues faster with [Metric Correlations](https://github.com/netdata/ne
 ### Related reference documentation
 
 - [Netdata Agent · Get started](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md)
-- [Netdata Agent · Apache data collector](https://github.com/netdata/go.d.plugin/blob/master/modules/apache/README.md)
-- [Netdata Agent · Web log collector](https://github.com/netdata/go.d.plugin/blob/master/modules/weblog/README.md)
-- [Netdata Agent · MySQL data collector](https://github.com/netdata/go.d.plugin/blob/master/modules/mysql/README.md)
-- [Netdata Agent · PHP-FPM data collector](https://github.com/netdata/go.d.plugin/blob/master/modules/phpfpm/README.md)
+- [Netdata Agent · Apache data collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/apache/README.md)
+- [Netdata Agent · Web log collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/weblog/README.md)
+- [Netdata Agent · MySQL data collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/mysql/README.md)
+- [Netdata Agent · PHP-FPM data collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/phpfpm/README.md)
 
diff --git a/docs/guides/monitor/pi-hole-raspberry-pi.md b/docs/guides/monitor/pi-hole-raspberry-pi.md
index d4f71a2935..1e76cc096d 100644
--- a/docs/guides/monitor/pi-hole-raspberry-pi.md
+++ b/docs/guides/monitor/pi-hole-raspberry-pi.md
@@ -81,7 +81,7 @@ service](https://discourse.pi-hole.net/t/how-do-i-configure-my-devices-to-use-pi
 finished setting up Pi-hole at this point.
 
 As far as configuring Netdata to monitor Pi-hole metrics, there's nothing you actually need to do. Netdata's [Pi-hole
-collector](https://github.com/netdata/go.d.plugin/blob/master/modules/pihole/README.md) will autodetect the new service
+collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/pihole/README.md) will autodetect the new service
 running on your Raspberry Pi and immediately start collecting metrics every second.
 
 Restart Netdata with `sudo systemctl restart netdata`, which will then recognize that Pi-hole is running and start a