Open the print queue on almost any office network and you'll see something quietly remarkable: the print server knows the printer down the hall is at 12% toner, even though nobody walked over to check. The printer didn't email anyone. A protocol asked it, the printer answered, and the answer landed on a dashboard. That protocol is the Simple Network Management Protocol (SNMP), and it's how networks report their own health — from toner levels to failing switch ports — before users ever open a ticket.
CompTIA A+ Core 1 (220-1201) puts network monitoring in the Networking domain, under the objective covering server roles and networked host services. The exam expects you to recognize what a network monitoring system does, know the pieces of SNMP by name, understand why SNMPv3 matters, and recall that SNMP uses UDP ports 161 and 162 — a pair that shows up constantly on port-matching questions. This article walks through why monitoring exists, how SNMP is built, how it differs from and pairs with syslog, and the specific facts to have cold on exam day.
Networks need monitoring because failures start quietly
Almost no network failure begins as an outage. A switch uplink drops frames for days before it dies. A server's memory usage creeps upward for a week before the application crashes. A printer runs low on toner long before it prints a blank page. The information that predicts the failure exists inside the device the whole time — the question is whether anyone is collecting it.
Without monitoring, the collection method is users. Someone calls the help desk because the internet "feels slow," and a technician troubleshoots from zero, with no history and no baseline. With monitoring, the network reports on itself continuously: the uplink's error counter started climbing on Tuesday, the WAN link pins at 95% every afternoon, the file server's CPU spiked at 2 a.m. when the backup ran.
That's the real value: monitoring turns reactive firefighting into proactive maintenance, and it builds a baseline of what "normal" looks like so changes stand out. Remote management tools like Secure Shell (SSH) and Remote Desktop Protocol (RDP) let an administrator log in and fix a device; monitoring is the layer that says which device needs attention in the first place. On the exam, a network monitoring system is one of the standard networked host services, sitting alongside file, print, DHCP, and DNS servers as infrastructure a business runs internally.
SNMP has three parts: managed devices, agents, and the NMS
SNMP is a framework, and it always involves the same three components. Learn them as a set, because exam questions test whether you can name which part does what.
A managed device is any piece of hardware being monitored: a switch, router, firewall, server, wireless access point, printer, or UPS. If it speaks SNMP, it can be managed. This is one of SNMP's quiet strengths — the same protocol that reads interface counters from a core switch reads toner levels from a laser printer.
An agent is the small software process running on each managed device. The agent's job is bookkeeping: it maintains a local database of statistics about the device — packets forwarded, errors seen, uptime, temperature, supply levels — and answers questions about that data when asked. The agent can also speak up on its own when something notable happens, which we'll cover shortly.
The network management system (NMS) is the central software that does the asking. Sometimes called the SNMP manager, the NMS runs on a server, keeps a list of every enrolled device, polls each agent on a schedule, stores the answers as historical data, and presents everything as graphs, maps, and alerts. Examples include PRTG, SolarWinds, Zabbix, and LibreNMS, though the exam cares about the role, not the brand names.
Stated plainly: agents live on the devices and hold the data; the NMS lives centrally and collects it. An exam question about "a central server that gathers statistics from network devices" is describing the NMS; one about "software on a router that responds to management queries" is describing the agent.
The MIB is the device's catalog, and OIDs are the item numbers
The database each agent maintains has a formal name: the management information base (MIB). Think of the MIB as a structured catalog of everything the device knows about itself. For a switch, that includes the status and traffic counters of every port. For a server, it includes CPU load, memory usage, and disk space. For a printer, it includes page counts and consumable levels.
Every individual value in the MIB has an address called an object identifier (OID). An OID is a long dotted string of numbers — something like 1.3.6.1.2.1.2.2.1.8, which identifies interface operational status — that walks down a standardized tree from general to specific. You do not need to memorize any OID for the A+ exam; what you need is the concept. The MIB is the organized collection of manageable data on a device, an OID is the unique address of one value inside it, and when the NMS asks a question, it asks by OID.
Part of the MIB tree is standardized, so any SNMP device reports universal basics like uptime and interface counters the same way. Vendors then extend the tree with branches for device-specific data — that's how a printer exposes toner percentage or a UPS exposes battery runtime — and the NMS loads the vendor's MIB definitions so it knows what those extra OIDs mean.
If a question pairs the terms: the MIB is the database, and OIDs are the entries in it.
Polling asks questions on a schedule; traps interrupt with news
SNMP moves information in two directions, and the difference is a favorite exam distinction.
Polling is NMS-initiated. On a schedule — commonly every one to five minutes — the NMS sends GET requests to each agent, asking for the current values of the OIDs it tracks. The agent answers, the NMS records the numbers, and over time those samples become the graphs and baselines that make monitoring useful. Polling's weakness is the gap between polls: if a port fails ten seconds after a poll, the NMS won't notice through polling alone until the next cycle.
Traps close that gap. A trap is agent-initiated: when something notable happens — a port goes down, a device reboots, a temperature threshold is crossed — the agent immediately sends an unsolicited message to the NMS without waiting to be asked. Agents can be configured with thresholds per value, so a device might trap when CPU passes 90% or when toner drops below 10%.