Network Monitoring & Alerts

Monitor the network you actually run

A small or mid-sized ISP runs a mix of subscriber CPE, managed edge routers, APs, switches, and backhaul — usually across two or three protocols at once. The problem is rarely a lack of graphs. It is that device status lives in one tool, SNMP counters in another, RouterOS reads in a third, and the controller in a fourth, so nobody can answer the only question that matters when the phone rings: who is affected, and what changed.

ISPAgents monitors all of it in one place. Metrics from TR-069 / CWMP diagnostics, SNMP polling, RouterOS REST probes, and controller APIs are normalized into the same model and converged into a single tenant and device timeline — so monitoring, alerts, syslog, and audit sit on one surface rather than four disconnected dashboards.

One device timeline, many sources

ISPAgents is ISP-aware infrastructure observation, not an attempt to beat a generic NMS at its own game. Multi-source metrics are normalized with source overlays, so a chart can show the same metric from more than one path and label exactly where each reading came from — and how fresh it is.

Source freshness is shown honestly: a stale reading is labeled stale rather than presented as live, so an operator never mistakes an old value for current state.

The event engine

A real-time event engine watches device and metric state and raises events when something crosses a line. It ships ten device event types today, with deduplication and throttling so a flapping router does not bury a real outage, and multi-channel delivery so the right people see it.

Delivery is multi-channel — email and webhooks — so events can reach an inbox, a chat channel, or an existing ticketing or on-call system without bolting on a separate alerting product.

Threshold rules that inherit

Thresholds are not set device by device. Metric threshold rules inherit down a hierarchy — catalog to group to device — so a policy defined once applies across a fleet, and an override is only needed where a specific device genuinely differs. Breach state persists, so a rule that is currently violated stays visible as an active condition rather than flickering on and off with each poll.

• Define a rule once at the catalog level and let it inherit to every group and device beneath it.
• Override at the group or device level only where the equipment warrants it.
• Persisted breach state means an ongoing problem reads as ongoing, not as a stream of disconnected blips.

Charts built for operators

Metrics land in chart workspaces an operator can arrange and keep — private to one user or shared across a team — so the views a NOC relies on during an incident are saved, not rebuilt each time. Because every source feeds the same device timeline, a chart sits next to the syslog and audit context for the same device, and an operator can move from "this metric looks wrong" to "here is what changed" without leaving the page.

Coexist, then converge

Start by connecting the sources you already have in read-only mode — SNMP, RouterOS, TR-069, or a controller — and watch the same devices appear in one timeline with nothing switched off. Turn on the event types your team cares about, set threshold rules at the catalog level, and route alerts to email and webhooks. Keep your existing tooling in place and let ISPAgents become the single pane as the evidence proves clean.

Pair monitoring with the SNMP integration for infrastructure and managed-edge polling, add syslog monitoring for event context on the same timeline, and connect MikroTik management so the routers you watch are also the routers you can back up and act on — all mapped to one canonical subscriber and device identity.