Network Monitoring Intent

activeintentverified 2026-07-20

Status: active Last verified: 2026-07-20 (against the current network-observability service record and deployed monitoring architecture) Scope: network-specific questions and authority boundaries; deployed tooling lives in the software monitoring reference

Network observability exists to reduce uncertainty about forwarding, policy, congestion, and failure domains. It is a consumer of network intent, not a source of configuration truth.

The deployed collection systems, watchdogs, signal transport, and incident cockpit are documented in Monitoring & Observability Architecture. This page defines the network questions those systems should answer without duplicating their changing implementation details.

Questions the evidence should answer

Network visibility is useful when it can answer a bounded set of operational questions:

Metrics collected without a decision question are inventory overhead, not observability.

Evidence areas

Edge and WAN

The edge view should correlate:

Adaptive controllers own their own bounded control inputs. Monitoring observes their decisions and outcomes but does not issue route or shaping mutations on their behalf.

Switching fabric

Switching evidence should show:

The switching layer remains transport. Monitoring does not move the Layer 3 or policy boundary into the fabric.

Wireless

Wireless evidence should support diagnosis of:

Wireless telemetry describes the radio edge. The routed firewall remains authoritative for inter-VLAN capability.

Policy and enforcement

Policy evidence should make static intent inspectable through:

A counter proves that a rule matched traffic. It does not prove the whole policy is correct or that unmatched traffic followed the intended path.

Logs and chronology

Central logs provide event order and device-specific detail that counters cannot. They are especially important for network devices with little or no durable local history.

Log presence is not liveness by itself. Freshness checks need source-specific cadence expectations, and redundant collectors count as redundancy only for clients verified to send to both.

Authority model

Question First authority
Intended topology, addressing, VLANs, and links NetBox and reviewed network documentation
Enforced firewall, NAT, routing, and classification Current device configuration
Current interface and device state Live read-only device inspection
Historical metrics and trends Prometheus-compatible metrics and dashboards
Event chronology and device messages Centralized syslog
Operational event and incident history Ops Console
Notification transport acceptance Hermes

No dashboard replaces live inspection before a risky change. A discrepancy between intent, configuration, and observation is a finding to investigate, not a reason to let monitoring choose a new policy.

Freshness and blind spots

Every evidence path has a clock:

A green value without a fresh timestamp can be more dangerous than an explicit unknown. Network dashboards should expose missing or stale evidence instead of carrying the last good state indefinitely.

Second-order coverage also matters. A watcher can detect failure of the primary monitor, but the watcher itself creates another timer, host, credential, and delivery path. Where no independent check exists, that limitation should be named.

Failure boundaries

Failure Expected evidence behavior
One exporter or poll target fails Its metrics become stale while independent logs or active checks may remain
One central log collector fails Verified dual-destination clients continue to the peer; other clients may lose centralized history
Primary infrastructure monitor fails An independent application-surface watcher should report the outage
Metrics store or dashboard fails Live device state and logs remain available through their own paths
Incident cockpit fails Polling, metrics, logs, and independent notification routes continue according to their own health
Notification transport fails Local evidence should remain; delivery failure needs a separate visible path
Adaptive controller fails Static network policy remains authoritative; monitoring records the controller and network state but does not take control

The goal is not universal high availability. It is to know which evidence remains trustworthy when one layer disappears.

Explicit non-goals

Network monitoring does not:

Future passive flow, IDS, or DNS-query visibility must document retention and household-telemetry access before long-term collection. Any inline enforcement proposal requires a separate architecture decision and rollback plan.