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.mdx

@@ -359,6 +359,12 @@ See [Retention and querying](/docs/network-performance-monitoring/network-flows/
 
 City-level GeoIP is accurate for many public IPs but wrong for VPNs, mobile carriers, and cloud-provider egress IPs (which often resolve to the cloud region's central city, not the actual user). Use country and state for trends; use city only after validating it for the prefix you care about. ASN ownership data also drifts — companies merge, prefixes get reassigned. A database older than a quarter or two starts labelling reassigned prefixes with the previous owner.
 
+### Private and non-routable IPs
+
+CIDR-based enrichment is IP-agnostic. Both static `enrichment.networks` and dynamic `network_sources` match prefixes for any address — RFC 1918 (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`), RFC 6598 carrier-grade NAT (`100.64.0.0/10`), and link-local (`169.254.0.0/16`) are matched the same way as public ranges. GeoIP databases carry no reliable country, city, or coordinate data for these addresses, and the ASN MMDB may render them as `AS0 Private IP Address Space` (see [AS numbers vs AS names](#as-numbers-vs-as-names)).
+
+To label private-IP traffic, declare those ranges as `enrichment.networks` entries. The merge step overlays non-empty static fields (`name`, `role`, `site`, `region`, `tenant`, `country`, `city`, `latitude`, `longitude`) on top of the GeoIP base layer, so your operator-defined values replace whatever GeoIP produced — or nothing at all. The `network_sources` jq schema earlier on this page applies the same pattern with `10.0.0.0/8` tagged `name: internal, role: lan`; static `networks` accepts those fields plus `latitude` and `longitude`. See the [Static Metadata](/docs/network-performance-monitoring/network-flows/enrichment-methods/static-metadata) integration card for configuration examples and the merge-order details.
+
 ### Sampling-rate knobs
 
 Two related, easily confused knobs (set under `enrichment` in `netflow.yaml`):