Network Monitoring System Project using SNMP and Flask

A network monitoring system is the screen a network administrator opens each morning: every switch, router, server and access point on the LAN, its reachability, its link utilization, and what broke overnight. Most small offices, college labs and campus networks do not have a network monitoring system — commercial suites are priced per device and carry enterprise features a small network never uses, so outages surface only when users complain, with the evidence of what failed first already gone. This project builds that missing screen from open-source parts: a Flask application that polls SNMP agents on every managed device, stores interface counters, CPU, memory and uptime as a time series, and raises threshold alerts. SNMP fits because it is the standard every managed device already speaks — no agent software to install, just UDP queries against the MIB counters the hardware maintains. The result is a laptop-runnable monitor a student can explain end to end: discovery, polling, storage, alerting, dashboard.

The pipeline runs end to end in four stages. Discovery comes first: the poller scans the configured subnet, sends an SNMP GET for sysDescr to each address, and promotes every responder into the inventory with its hostname and IP. Then the SNMP poll: each interval (60 seconds by default) the poller requests the system MIB — sysDescr, sysName, sysUpTime under 1.3.6.1.2.1.1 — and GETBULK-walks the ifTable (1.3.6.1.2.1.2.2) for interface counters, over UDP port 161 with a 5-second timeout and 3 retries. Processing turns counters into meaning: samples are timestamped and stored, bandwidth comes from counter deltas divided by elapsed time (SNMP counters only increase, so rates are derived, never read), and the rule engine compares CPU, memory, link state, error deltas and utilization against thresholds — firing after two consecutive breaches, clearing after three clean polls. Finally the dashboard renders it all: Flask serves the overview, inventory, interfaces and alert log from the stored series.

1. Discovery scans the subnet with SNMP GET requests for sysDescr and registers responding devices with hostname and IP.
2. Every poll interval, the scheduler walks the inventory: system MIB via GET, interface table via GETBULK, over UDP/161 with timeout and 3 retries.
3. Samples are timestamped and stored; bandwidth is derived from counter deltas over elapsed time since SNMP counters are monotonically increasing.
4. The rule engine evaluates link-down, CPU, memory, error-counter and utilization thresholds against the fresh samples.
5. Alerts fire after 2 consecutive breaches (flap guard), appear in the log and dashboard badge, and can be acknowledged.
6. Three consecutive clean polls auto-recover an alert; the full history stays in the log with severity and timestamps.
7. The Flask dashboard renders inventory, charts, interface counters and alerts from the stored series on every page load and poll cycle.

Tech stack:

• Python 3, Flask (web app, routes, poll scheduler)
• pysnmp (SNMP GET / GETBULK over UDP port 161)
• SQLite (timestamped samples, device inventory, alert log)
• HTML5, CSS, JavaScript (dashboard UI)
• Canvas 2D (bandwidth and traffic charts)
• Jinja2 templates (server-side page rendering)
• Interval scheduler (configurable poll cycle)
• Git (version control)

A network monitoring system lives or dies on four capabilities, and this build implements all four: a live dashboard that answers "what is happening right now" at a glance, an SNMP poller that collects real counters on a schedule with failure handling, a threshold alert engine that fires on genuine breaches without flapping, and a device inventory tying every number to a specific box. The dashboard shows aggregate bandwidth charts, top interfaces by utilization, per-device reachability and the latest alerts on one screen. The poller walks the standard MIBs — system identity from 1.3.6.1.2.1.1 and interface counters from 1.3.6.1.2.1.2.2 — over UDP port 161 with timeout and retries, marking a device down only after every retry fails. The alert engine evaluates link-down, CPU, memory, interface-error and utilization rules after each cycle, fires after two consecutive breaches, and auto-recovers after three clean polls. The inventory keeps hostname, IP, SNMP status, CPU, memory and uptime per device, with a per-interface detail view.

• [Live dashboard] Aggregate throughput chart, top interfaces by utilization, device-status table and latest alerts on one screen, refreshed every poll cycle with a visible countdown to the next SNMP poll.
• [SNMP poller with retries] Scheduled GET/GETBULK walks over UDP port 161; per-device timeout (5 s default) with 3 retries — a device is marked down only after all retries fail, because over connectionless UDP a dead device is indistinguishable from a dropped packet.
• [Threshold alert engine] Rules for link-down, CPU, memory, interface errors and bandwidth utilization; alerts fire after 2 consecutive breaches (flap guard) and auto-recover after 3 clean polls.
• [Device inventory + detail views] 12-device demo inventory with hostname, IP, SNMP status, CPU, memory and uptime; click-through detail shows per-interface traffic charts, ifTable counters and the system MIB identity block.
• [Interface counters page] Every polled interface with live in/out Mbps, utilization against ifSpeed, and 64-bit ifInOctets totals — the raw material for capacity planning.
• [Acknowledge workflow] One-click acknowledge moves an alert out of the active count; the log keeps the full history with severity, device, message and timestamp.
• [SNMP configuration page] Version (v1/v2c/v3), community string, UDP port, timeout, retries and poll interval editable from the UI and applied at the next cycle; devices can be added to the inventory from a form.
• [Measured demo build] The shipped demo reports its own real timings in the footer — first paint in the tens-to-low-hundreds of ms, poll-cycle render for 12 devices in low single-digit ms — so performance claims are observed, not asserted.
  Optional at order time: SNMPv3 authPriv credentials, email/webhook notification wiring, trap (event-driven) reception alongside polling. Future scope: NetFlow/sFlow ingestion, ML-based anomaly detection on the time series, multi-poller federation.

• Flask application: SNMP poller, scheduler, threshold alert engine and dashboard
• Device inventory, interface-counters and alert-log pages with working acknowledge workflow
• SNMP configuration page (version, community, port, timeout, retries, interval, add-device)
• Working demo build with a 12-device simulated agent set, exercisable without hardware
• Project report PDF (background, SNMP/MIB theory, architecture, methodology, results)
• PPT presentation for final review
• Viva Q&A preparation document (SNMP, MIB/OID structure, UDP vs TCP polling, counter deltas, flap-guard logic)