[pull] master from netdata:master

.agents/skills/project-create-topology/SKILL.md

@@ -100,7 +100,8 @@ developer-facing and must stay in this project skill, not under
 4. Pick evidence rows.
    - Evidence is the lossless relationship proof.
    - For sockets, preserve the exact matching tuple.
-   - For SNMP/L2, preserve LLDP/CDP/FDB/ARP/STP facts according to role.
+   - For SNMP, preserve LLDP/CDP/FDB/ARP/STP facts according to role and keep
+     logical L3 adjacency in distinct L3 link/evidence types.
    - For streaming, keep relationship facts separate from actor-owned path data.
    - For vSphere, preserve inventory/relationship facts using stable object IDs.
 
@@ -395,9 +396,9 @@ For `topology:streaming` actor modals:
   so Cloud aggregation can preserve multiple retaining parents and a future
   explicitly named `Retained by` section can be added without changing facts.
 
-## SNMP/L2 Modal Rules
+## SNMP Topology Modal Rules
 
-For SNMP/L2 managed device actor modals:
+For SNMP managed device actor modals:
 
 - Treat the device as a collection of ports. The primary section is `Ports`
   over `actor_ports`.
@@ -418,6 +419,13 @@ For SNMP/L2 managed device actor modals:
   confidence, inference, attachment mode, or timestamps.
 - `actor_port_links` may carry compact side-specific refs and scalar facts, but
   must not duplicate raw LLDP/CDP/FDB/ARP/STP evidence JSON.
+- Keep logical L3 adjacency out of `actor_port_links`. `l3_subnet` is not a
+  physical or L2 port-neighbor relationship.
+- Expose logical L3 adjacency through typed `l3_subnet` relationship evidence
+  and an evidence-backed device modal section such as `L3 Adjacencies`.
+- `l3_subnet` links represent shared-subnet logical L3 adjacency between
+  resolved managed SNMP device actors. They must use explicit L3 link/evidence
+  types and must not be presented as discovery, physical, or L2 links.
 - Keep generic graph-link `Links` sections only for endpoint, segment, or
   custom actors that do not own port inventory.
 - Build link endpoint port labels only from real port fields: `port_name`,

.agents/sow/specs/topology-function-schema.md

@@ -16,7 +16,7 @@ The production schema is defined by:
 - `src/plugins.d/FUNCTION_TOPOLOGY_DEVELOPER_GUIDE.md`
 
 The schema is generic across topology domains. It applies to network
-connections, streaming, SNMP/L2, vSphere, and future topology producers.
+connections, streaming, SNMP, vSphere, and future topology producers.
 
 ## Planes
 
@@ -587,15 +587,29 @@ deduplicated actor-label values when available.
 
 `topology:snmp` now emits `netdata.topology.v1` from the Function handler
 through an adapter over the existing SNMP topology engine output. The adapter
-preserves actors, links, L2 observation evidence, actor metadata, and actor
-custom detail tables. Remaining SNMP refinement is to promote interface metric
-lookup fragments into first-class overlay templates/refs.
+preserves actors, links, L2 observation evidence, bounded L3 adjacency
+evidence, actor metadata, and actor custom detail tables. Remaining SNMP
+refinement is to promote interface metric lookup fragments into first-class
+overlay templates/refs.
+
+SNMP `l3_subnet` links are logical L3 adjacency, not physical or L2 adjacency.
+They use `orientation: observed_bidirectional`, `direction_role: observation`,
+and `semantic_role: normal`. The producer emits them only between resolved
+managed SNMP device actors; unresolved or ambiguous L3 endpoints remain
+diagnostic/suppression state and must not create IP-only graph actors.
+
+SNMP `l3_subnet` evidence must preserve the relationship facts needed for
+drilldown and aggregation, including a `link_ref`, source/destination actors,
+source/destination interface IPs, subnet, network, netmask, prefix, source, and
+logical inference/attachment metadata. The evidence is an actor-modal source
+for L3 adjacency drilldowns.
 
 SNMP modal composition must be port-centric for managed device actors. A managed
 device modal uses actor-label identification for important device facts, a
 primary `Ports` section over `actor_ports`, and a `Port Neighbors` section over
-`actor_port_links`. Generic graph-link `Links` sections are reserved for
-endpoint, segment, or custom actors that do not own port inventory.
+`actor_port_links`. It may also expose an `L3 Adjacencies` section sourced from
+`l3_subnet` relationship evidence. Generic graph-link `Links` sections are
+reserved for endpoint, segment, or custom actors that do not own port inventory.
 
 SNMP `actor_ports` exposes real port identity and status as typed columns:
 SNMP `if_index` as the visible numeric port ID when known, source `port_id`,
@@ -616,6 +630,10 @@ state, evidence count, confidence, inference, attachment mode, and timestamps.
 It exists so device modals can align neighbor rows with the same port identity
 shown in `actor_ports`; it is not a second copy of raw evidence.
 
+SNMP `actor_port_links` must remain port-neighbor oriented. It must not include
+`l3_subnet` links, because shared-subnet L3 adjacency does not prove a physical
+or L2 port neighbor.
+
 SNMP polished UI must not depend on raw `actor_metadata` and endpoint JSON.
 Important scalar/count summary values live in typed actor or actor-detail
 columns and are also available through `actor_labels`. Nested neighbors, VLANs,

.agents/sow/specs/topology-modes-correlation-aggregation.md

@@ -29,7 +29,7 @@ rules, table merge policies, and presentation recipes in the payload.
 ## Terms
 
 - **Producer**: the Agent Function that emits one `netdata.topology.v1`
-  payload, for example network-connections, SNMP/L2, streaming, or vSphere.
+  payload, for example network-connections, SNMP, streaming, or vSphere.
 - **Aggregator**: Cloud service that fans out to many producers, decodes their
   payloads, correlates them, optionally aggregates detail, and returns a normal
   `netdata.topology.v1` payload.
@@ -88,7 +88,7 @@ aggregator returns either detailed or aggregated output according to the
 original user request.
 
 If a producer does not expose `__topology_mode`, the aggregator must not invent
-that parameter for it. SNMP/L2 and streaming are expected to be mode-invariant
+that parameter for it. SNMP and streaming are expected to be mode-invariant
 unless a future producer change defines a real mode difference.
 
 ### Final Output
@@ -497,20 +497,32 @@ Aggregator detailed:
 - Show exact socket evidence with resolved actors where possible.
 - Unresolved rows retain their loose-side facts.
 
-## SNMP/L2
+## SNMP
 
 ### Domain Model
 
-SNMP/L2 topology observations are device, interface, neighbor, forwarding,
-ARP, bridge, VLAN, and protocol facts. A graph link represents an observed or
-inferred L2 relationship between two actors.
+SNMP topology observations are device, interface, neighbor, forwarding, ARP,
+bridge, VLAN, protocol, and bounded L3 adjacency facts.
 
-SNMP is not a loose-side topology. Every link should have two actors in both
-Agent and aggregator views.
+Most graph links represent observed or inferred L2 relationships between two
+actors. SNMP may also emit logical L3 relationships with their own link and
+evidence types. These links MUST NOT be presented as physical or L2 adjacency.
+
+`l3_subnet` represents an observed shared-subnet relationship between two
+managed SNMP device actors. It is currently derived from interface IP/netmask
+state collected from IP-MIB `ipAddrTable`, limited to IPv4 point-to-point
+`/30` and `/31` subnets. It means both devices have managed interfaces in the
+same point-to-point subnet; it does not prove that the devices are physically
+connected.
+
+SNMP is not a loose-side topology. Every graph link should have two actors in
+both Agent and aggregator views. `l3_subnet` follows the same rule: unmatched
+or ambiguous L3 endpoints are diagnostic/suppression state, not materialized
+IP-only graph actors.
 
 ### Mode Behavior
 
-SNMP/L2 detailed and aggregated modes are currently a no-op. The producer should
+SNMP detailed and aggregated modes are currently a no-op. The producer should
 not expose `__topology_mode` until it has a real lower/higher-grain distinction.
 
 If a global Cloud topology request asks for aggregated output, the aggregator
@@ -546,9 +558,14 @@ switch-a port 10 -> managed-switch-b
 The weaker LLDP remote actor is removed from the aggregated output and its
 incident links/tables are rewired to the managed device actor.
 
-### UI SNMP/L2
+For `l3_subnet`, aggregation MUST preserve the explicit `l3_subnet` link and
+evidence type. Replacement may rewire endpoint actors to stronger managed
+device actors, but it MUST NOT reinterpret `l3_subnet` as discovery protocol
+evidence or port-neighbor evidence.
+
+### UI SNMP
 
-The UI should not expose a detailed/aggregated toggle for SNMP/L2 unless the
+The UI should not expose a detailed/aggregated toggle for SNMP unless the
 payload declares supported modes.
 
 Device modals should remain port-centric:
@@ -562,6 +579,8 @@ Device modals should remain port-centric:
   when graph-link facts can align the port to a remote actor;
 - links/neighbor information: derived from the same port rows or aligned
   relationship rows so local port identity never contradicts the port table.
+- L3 adjacency information: derived from typed `l3_subnet` relationship
+  evidence, not from `actor_port_links`.
 
 ## Streaming
 

src/collectors/statsd.plugin/README.md

@@ -692,6 +692,14 @@ To rename methods automatically:
 This adds dimensions named `GET`, `ADD`, and `DELETE`.
 </details>
 
+### Scope of StatsD Chart Configuration
+
+All chart and dimension configuration directives in `/etc/netdata/statsd.d/*.conf` control **local agent behavior only** — they define how the local Netdata agent processes, names, and visualizes statsd metrics it receives.
+
+The dimension `TYPE` field (see [Dimension Format](#dimension-format) above) selects which computed value of a metric a single agent displays. It does **not** control how that metric is combined across multiple Netdata instances.
+
+Cross-node aggregation — how metrics from multiple agents are combined in Netdata Cloud dashboards — is governed by the Cloud query engine, not by statsd configuration files. To choose Sum, Average, or another aggregation for a chart in Netdata Cloud, use the [aggregate function](../../../docs/dashboards-and-charts/netdata-charts.md#aggregate-functions-dropdown) on that chart. There is no `aggregation = SUM` or `aggregation = AVG` directive in statsd.d configuration.
+
 ## Using StatsD with Different Languages
 
 <details>

src/database/README.md

@@ -36,7 +36,14 @@ These limits are fully configurable. See [Changing how long Netdata stores metri
 
 ### Monitoring Retention Utilization
 
-Netdata provides a visual representation of storage utilization for both the time and space limits across all Tiers under "Netdata" -> "dbengine retention" on the dashboard. This chart shows exactly how your storage space (disk space limits) and time (time limits) are used for metric retention.
+Netdata provides a visual representation of storage utilization for both the time and space limits across all Tiers. In the dashboard, these are the **dbengine space and time retention** charts, found under the **Netdata** section → **dbengine retention** family — there is one chart per database tier. Each chart shows exactly how your storage space (disk space limits) and time (time limits) are used for metric retention.
+
+Each tier has its own independent **space** and **time** lines on the chart:
+
+- **Space (disk utilization %)**: the percentage of the tier's allocated disk space that is currently occupied, calculated as `disk_used / disk_max × 100`. When a size limit is configured for the tier, `disk_max` is that limit. When no size limit is configured (set to 0), `disk_max` is the total available disk space at the tier's data directory (free space plus already-used space). For example, a space value of 89% means 89% of the tier's allocated or available disk space is occupied by datafiles.
+- **Time (retention time utilization %)**: the percentage of the configured retention time period that has been filled with data, calculated as `current_retention_duration / configured_time_limit × 100`. When no time limit is configured (set to 0), this dimension shows 0% and no time-based retention is enforced. For example, a time value of 61% means 61% of the configured time retention period has elapsed since the oldest sample. This value is capped at 100%.
+
+Different tiers naturally show different percentages because they have different write volumes, compression ratios, and configured limits. When either the space or time dimension reaches 100%, the oldest datafiles are rotated out as described in the [Retention Size Enforcement](#retention-size-enforcement) section below.
 
 ### Retention Size Enforcement