Ingest new documentation

Author: netdatabot

docs/Collecting Metrics/Collectors/Hardware and Sensors/Hardware information collected from kernel ring..mdx

@@ -59,7 +59,15 @@ The default configuration for this integration is not expected to impose a signi
 
 ### Prerequisites
 
-No action required.
+#### Install the Netdata Driver (netdata_driver.sys)
+
+CPU temperature monitoring on Windows requires the Netdata kernel driver (`netdata_driver.sys`) to be installed on the host. The driver is an optional component and is not installed by default.
+
+When you install Netdata with the Windows MSI installer, select the **Netdata Driver: Hardware Metrics Collection** option on the feature selection screen. If Netdata is already installed without the driver, the installer's Change/Modify option does not expose this checkbox again; uninstall Netdata first, then reinstall it and select the option during setup.
+
+Editing `netdata.conf` alone is not enough. Without the driver, the `GetHardwareInfo` module cannot read the CPU `msr` register, so the `cpu.temperature` chart is never created and CPU temperature will not appear on the dashboard. The collector records an error in the Netdata log, but no temperature chart is produced.
+
+
 
 ### Configuration
 

docs/Collecting Metrics/Collectors/Networking/tc QoS classes.mdx

@@ -180,3 +180,24 @@ Metrics:
 | tc.qos_dropped | Class Dropped Packets | a dimension per class | packets/s |
 | tc.qos_tokens | Class Tokens | a dimension per class | tokens |
 | tc.qos_ctokens | Class cTokens | a dimension per class | ctokens |
+
+
+
+## Troubleshooting
+
+### Recurring Cannot find file warnings for tc-qos-helper.conf
+
+When `tc-qos-helper.sh` starts, it looks for its configuration in two places, in this order: the stock configuration directory (typically at `/usr/lib/netdata/conf.d`) and the user [config directory](/docs/netdata-agent/configuration) (typically at `/etc/netdata`). Netdata does not ship a stock `tc-qos-helper.conf`, so on a default installation neither file exists and the script emits a `Cannot find file` warning for each missing path.
+
+These warnings are harmless. When no configuration file is found the script keeps its built-in defaults (for example `tc_show="qdisc"`). They reappear every hour because the script exits and is restarted by Netdata every 3600 seconds (`qos_exit_every=3600`), which re-runs the same checks on each start.
+
+Creating `tc-qos-helper.conf` in your user config directory with the desired setting silences the warning for the user configuration path. The warning for the stock path is expected to remain, because no stock `tc-qos-helper.conf` ships with Netdata, and it is benign.
+
+
+### FireQOS is not installed warning
+
+When `tc-qos-helper.sh` starts and cannot find FireQOS (neither the `/var/run/fireqos` directory nor the `fireqos` executable), it logs that FireQOS is not installed on this system. This is normal on systems that do not perform QoS traffic shaping with FireQOS.
+
+Like the configuration warnings, this message repeats every hour because the script exits and is restarted by Netdata every 3600 seconds (`qos_exit_every=3600`), re-running the FireQOS presence check on each start.
+
+FireQOS is only required to apply QoS and expose human-readable class names to Netdata. Without it the plugin still collects `tc` qdisc/class metrics directly from the `tc` command. To expose FireQOS class names, [install FireQOS](https://firehol.org/tutorial/fireqos-new-user/). To map numeric class IDs to readable names without FireQOS, list them in `/etc/iproute2/tc_cls` and set `tc_show="class"` in `tc-qos-helper.conf` in your user config directory.

docs/Collecting Metrics/Collectors/Operating Systems/System statistics.mdx

@@ -179,7 +179,7 @@ Labels:
 
 | Label      | Description     |
 |:-----------|:----------------|
-| cpu | Identifier of the CPU core (e.g., core0, core1, core2). |
+| cpu | Identifier of the CPU core (e.g., cpu0, cpu1, cpu2). |
 
 Metrics:
 

docs/Network Performance Monitoring/Network Flows/Enrichment Methods/AWS IP Ranges.mdx

@@ -53,7 +53,7 @@ Schema of `ip-ranges.json`:
 For the cross-cutting concepts (how multiple network sources merge, the lookup
 priority vs static `networks` config, TLS verification rules, the jq engine and
 its expected output schema, fetch loop and retry/backoff), see
-[Network Identity](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[Network Identity](/docs/network-performance-monitoring/network-flows/enrichment).
 
 
 The plugin issues a periodic GET to `https://ip-ranges.amazonaws.com/ip-ranges.json`,
@@ -112,7 +112,7 @@ output (`tenant`, `region`, `role`, `name`, `site`, `city`, `country`, `state`,
 
 The expected `transform` output is a stream of objects, each carrying a `prefix`
 (CIDR string) plus any subset of the optional attribute fields. See the
-cross-cutting [Network Identity](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment)
+cross-cutting [Network Identity](/docs/network-performance-monitoring/network-flows/enrichment)
 page for the full output schema.
 
 

docs/Network Performance Monitoring/Network Flows/Enrichment Methods/Azure IP Ranges.mdx

@@ -47,7 +47,7 @@ and the rest -- without maintaining the prefix list yourself.
 
 For the full network-identity concept (merge order, jq output shape, TLS
 verification, failure modes), see
-[Network Identity](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[Network Identity](/docs/network-performance-monitoring/network-flows/enrichment).
 
 
 Periodic HTTPS GET against the Service Tags JSON, jq transform via the

docs/Network Performance Monitoring/Network Flows/Enrichment Methods/BMP BGP Monitoring Protocol.mdx

@@ -49,7 +49,7 @@ rollup.
 
 For the cross-cutting Enrichment concept (provider chains, shared trie with
 BioRIS, withdrawal handling, restart convergence), see
-[Enrichment](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[Enrichment](/docs/network-performance-monitoring/network-flows/enrichment).
 
 
 The plugin runs a TCP listener on `0.0.0.0:10179`. This port is the Akvorado

docs/Network Performance Monitoring/Network Flows/Enrichment Methods/CAIDA Routeviews Prefix-to-AS.mdx

@@ -40,7 +40,7 @@ coordinates.
 
 For the IP-intelligence mechanism (lookup order, MMDB composition, refresh,
 provider chains), see
-[IP Intelligence](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[IP Intelligence](/docs/network-performance-monitoring/network-flows/enrichment).
 
 
 The netflow plugin reads MMDB files only. CAIDA publishes compressed text data,

docs/Network Performance Monitoring/Network Flows/Enrichment Methods/Classifiers.mdx

@@ -27,7 +27,7 @@ Module: classifiers
 ## Overview
 
 Annotate network flows with exporter and interface labels derived from reusable
-classification rules. Where [static metadata](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment)
+classification rules. Where [static metadata](/docs/network-performance-monitoring/network-flows/enrichment)
 forces you to enumerate every exporter and every ifIndex by hand, classifiers
 let you express the network design once -- "anything matching `^edge-` is the
 edge tier", "any interface with `BACKBONE-LUMEN` in its description is on
@@ -64,7 +64,7 @@ normalisation.
 
 For the cross-cutting Enrichment concept (where classifiers sit in the merge
 order vs static metadata, GeoIP, IPAM, BGP routing), see
-[Enrichment](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[Enrichment](/docs/network-performance-monitoring/network-flows/enrichment).
 
 
 Each rule is a single boolean expression; an action with no condition (e.g.
@@ -135,7 +135,7 @@ Classifiers shine when there is a pattern to match -- exporter naming
 conventions (`edge-...`, `core-...`), management-IP subnets per site,
 SNMP interface descriptions that follow a template (`BACKBONE-<carrier>`,
 `TRANSIT-...`, `IX-...`), or 100Gbps-equals-core conventions. If your
-fleet has no such pattern, [static metadata](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment)
+fleet has no such pattern, [static metadata](/docs/network-performance-monitoring/network-flows/enrichment)
 is the better fit -- it lets you list each exporter and ifIndex by hand.
 
 

docs/Network Performance Monitoring/Network Flows/Enrichment Methods/Custom MMDB Database.mdx

@@ -48,7 +48,7 @@ State and country survive into all four tiers.
 
 For the full IP-intelligence concept (composition rule, ASN provider chain,
 auto-detect path order, dual-stack handling, hot reload semantics), see
-[IP Intelligence](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[IP Intelligence](/docs/network-performance-monitoring/network-flows/enrichment).
 
 
 You build (or download) the MMDB file with your own tooling, place it on the
@@ -228,7 +228,7 @@ The plugin reloads custom databases the same way it reloads stock ones
 plugin will pick it up; if it was edited byte-by-byte (rare with MMDB
 builders) verify size or mtime actually changed. The reload mechanism
 and its 30-second cadence are documented in
-[IP Intelligence](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[IP Intelligence](/docs/network-performance-monitoring/network-flows/enrichment).
 Operational practice: have your build pipeline write the new MMDB to a
 temp file in the same directory and `rename(2)` it over the live path so
 the swap is atomic.

docs/Network Performance Monitoring/Network Flows/Enrichment Methods/DB-IP IP Intelligence.mdx

@@ -56,7 +56,7 @@ Populates these flow record fields when a lookup succeeds:
 For the cross-provider mechanics (lookup pass ordering, the 30-second hot-reload poll,
 the auto-detect path order, multi-database composition, IPv4/IPv6 handling, the failure
 modes shared by every MMDB provider), see
-[IP Intelligence](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[IP Intelligence](/docs/network-performance-monitoring/network-flows/enrichment).
 
 
 Files are read on plugin start and reloaded automatically when their mtime or size
@@ -103,7 +103,7 @@ the binary is available (packaged 32-bit installs do not include it) to populate
 sudo /usr/sbin/topology-ip-intel-downloader
 ```
 
-See the [Enrichment Intel Downloader](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment-intel-downloader)
+See the [Enrichment Intel Downloader](/docs/network-performance-monitoring/network-flows/enrichment-intel-downloader)
 page for downloader options and how to schedule periodic refreshes. DB-IP Lite
 data is published monthly, so a monthly cron of the downloader is the right
 cadence -- more frequent runs will not produce newer data.
@@ -196,7 +196,7 @@ private space. The DB-IP-built ASN database tags private ranges so `*_AS_NAME`
 renders as `AS0 Private IP Address Space`, while geographic fields stay empty and
 private addresses do not appear on maps. Declare your internal CIDRs under
 `enrichment.networks` when you want internal labels -- see
-[Static metadata](https://learn.netdata.cloud/docs/network-performance-monitoring/network-flows/enrichment).
+[Private and non-routable IPs](/docs/network-performance-monitoring/network-flows/enrichment#private-and-non-routable-ips).
 
 
 ### Stale databases