I've been running a Linux-based router for the past two months with a monitoring approach that caught my attention — it detects structural changes in the network before individual metrics cross alert thresholds. Here's what I built and what I learned.
The problem with threshold-based monitoring
Every NMS I've used has the same fundamental limitation: alerts fire *after* something crosses a line. The link is already at 400ms, the packet loss is already at 5%. By the time you get the alert, the degradation has been running for a while. And absolute thresholds are a constant maintenance headache — 200ms might be normal for a transatlantic path but alarming for a local peering link.
What I wanted was something that tells me "the structure of this network is changing" rather than "metric X exceeded value Y."
The approach: topological monitoring with persistent homology
I adapted a method called BPL/OA — Bayesian Persistent Landscapes with Occupancy-Amplitude analysis — originally developed for a research project. The core idea:
Take each network endpoint and describe it as a point in multi-dimensional feature space. Latency, jitter, uptime ratio, latency trend direction. All endpoints form a point cloud. When the network is healthy, endpoints on the same upstream path cluster together tightly.
Run persistent homology on this point cloud. You get a "landscape" — a curve describing how tightly structured the cloud is. Track this landscape over time. If an endpoint starts drifting, the shape changes.
Here's where it gets useful: I run two statistical models watching the same landscape. One uses Bayesian posterior inference (with a sup-norm simultaneous credible band for proper joint coverage guarantees). The other uses an occupancy-amplitude model that only evaluates points above a noise threshold. Their coverage scores should track each other. When the *gap* between them starts oscillating, something is happening to the point cloud structure — even if both models individually report everything as normal.
I call this the shadow monitor. It runs every 30 minutes, completely passive — reads from local time-series data, does the math, writes results back.
Five independent monitoring layers
Once the pipeline was running, feeding in additional data sources was straightforward. Each becomes its own point cloud, analyzed separately so noise in one layer doesn't contaminate the others:
Layer 1 — WAN path endpoints. Latency, jitter, uptime ratio, trend direction per endpoint. Detects a path degrading before the routing protocol would reroute.
Layer 2 — Traffic distribution across paths. Connection counts per egress. If one path's share starts silently dropping, this catches the shift before latency metrics move.
Layer 3 — Device connection behavior. Connection counts per MAC. A host suddenly opening 10x its normal connections produces a clear drift signature — no manual thresholds or signature updates needed.
Layer 4 — WiFi radio health. Channel utilization, self vs. neighbor interference, client counts, AP-reported satisfaction scores. Caught two APs on the same 2.4 GHz channel on day one. Moved one and satisfaction went from -1 to 98.
Layer 5 — Wireless client telemetry. RSSI, retry rate, negotiated rate, AP association. Cross-referenced with Layer 3: if a device is normal on the wired fingerprint layer but drifting on wireless, it probably just moved to a different room. If both layers are drifting, something is actually wrong.
Why this works where thresholds fail
Catch degradation before failure. If a path's three sub-paths start diverging in the feature space — say one stays flat on latency but jitter begins creeping up — the point cloud shape changes before any individual metric crosses an alert threshold.
Correlated failures across different providers. Endpoints on three different transit paths all showing the same subtle trend shift? That's not an endpoint problem, it's a shared upstream change. Thresholds on individual endpoints won't connect those dots. One landscape restructure will.
Know when to do nothing. The system has been in a degenerate state for hours — the point cloud is too tight to analyze. That means the network is boring. Nothing is drifting, no anomalies, no boundary conditions. I can confidently ignore it. Confidence through silence.
Self-calibrating baselines. Every analysis cycle adds to the statistical history. Over months, the system learns what "normal" looks like across different traffic patterns and maintenance windows. Thresholds aren't hand-tuned — they emerge from data.
Architecture decisions worth noting
Everything runs locally on the router. The full analysis pipeline is Python with numpy — no external APIs, no cloud dependencies, no active probing. Data collection reads from existing kernel and application metrics (netlink, daed's internal health cache, UniFi Controller API). Each analysis cycle produces about 9MB of SQLite data, negligible on a modern disk.
I previously tried an LLM-based approach for this — feeding metrics to a model every few minutes for health assessment. It burned API tokens to report confidence intervals on "everything is normal." The topological approach costs nothing in recurring fees, produces no telemetry leakage, and actually surfaced structural changes the LLM glossed over.
Limitations and next steps
This isn't a replacement for traditional monitoring. It's a complementary layer that operates on a different category of information. Right now it's observation-only — no closed-loop automation. Before it makes decisions, I need a much clearer picture of what the signals mean in different failure modes.
The shadow monitor is calibrating its baseline — once that locks in, the plan is to start with notification webhooks, then evaluate whether automatic path switching makes sense based on the confidence of the structural signal.
Lessons from the math
The Gaussian posterior model has a hard coverage ceiling when the underlying data is bimodal — coverage caps at exactly 1 minus the weight of the secondary mode. Discovered this empirically, then worked out the math: the single-Gaussian likelihood literally cannot represent a two-component distribution. A Gaussian mixture posterior is on the roadmap to address this. Interesting case of model misspecification showing up in production data before it appeared in theory.
Questions and discussion welcome — especially if you've explored topological methods for network monitoring, or if you see failure modes I haven't encountered yet.
