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

QuestionFirst authority
Intended topology, addressing, VLANs, and linksNetBox and reviewed network documentation
Enforced firewall, NAT, routing, and classificationCurrent device configuration
Current interface and device stateLive read-only device inspection
Historical metrics and trendsPrometheus-compatible metrics and dashboards
Event chronology and device messagesCentralized syslog
Operational event and incident historyOps Console
Notification transport acceptanceHermes

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

FailureExpected evidence behavior
One exporter or poll target failsIts metrics become stale while independent logs or active checks may remain
One central log collector failsVerified dual-destination clients continue to the peer; other clients may lose centralized history
Primary infrastructure monitor failsAn independent application-surface watcher should report the outage
Metrics store or dashboard failsLive device state and logs remain available through their own paths
Incident cockpit failsPolling, metrics, logs, and independent notification routes continue according to their own health
Notification transport failsLocal evidence should remain; delivery failure needs a separate visible path
Adaptive controller failsStatic 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.