By the SNMP Monitoring team · Reviewed July 2026
The SNMP manager—often called the NMS (network management station)—is the system that polls agents, stores OID values, evaluates thresholds, and usually receives traps on UDP 162. It sits in the architecture opposite the agent: off the monitored device, asking questions on a schedule.
If the agent is the instrument panel sensor, the manager is the person (or software) reading gauges and writing the logbook. Map: architecture. Agent twin: agent.
Definition: the SNMP manager / NMS
Manager / NMS = the polling and collecting side of SNMP.
It initiates:
- GetRequest / GetNextRequest / GetBulkRequest (reads)
- SetRequest (writes—when you allow that bad idea)
It consumes:
- Response PDUs with values
- Traps / informs on UDP 162 (if configured as a receiver)
It runs off the monitored device. Installing Zabbix on the same host you monitor doesn't make Zabbix an "agent"; the agent is still snmpd (or equivalent) answering on 161.
"NMS" in vendor-speak sometimes means a big licensed suite. Architecturally, a cron job with snmpget is still a manager—just a tiny one.
What a manager does
Responsibilities in practice:
- Discover or inventory targets (static list, autodiscovery—product-dependent).
- Schedule polls — which OIDs, which interval, which version/credentials.
- Send Gets/GetBulks to agents on UDP 161.
- Store time series — RRD, TSDB, proprietary DB.
- Evaluate thresholds — sustained CPU, disk, errors, etc.
- Receive traps/informs on UDP 162 and correlate them.
- Alert — page, ticket, webhook.
- Present UI — graphs, inventories, maps (full platforms).
Not every manager does all eight. CLI tools stop around step 3. Platforms sell steps 4–8. External services may only do 2–5 from outside your network.
PDU vocabulary: PDU types. Poll vs trap: traps vs polling.
Manager vs agent
One-line contrast: manager asks; agent answers (and sometimes yells first).
| Manager (NMS) | Agent | |
|---|---|---|
| Location | Off monitored device | On managed device |
| Initiates Get/Set? | Yes | No |
| Listens for traps? | Yes (162) | Sends traps |
| Listens for queries? | No (usually) | Yes (161) |
Deep agent page: agent. AgentX subagents still sit on the device side under a master agent—not "mini NMS processes."
Types of SNMP managers
Bulleted field taxonomy:
- CLI tools — net-snmp
snmpget,snmpwalk,snmpbulkwalk. Perfect for tests and scripts. Terrible as your only "platform." - Full NMS platforms — LibreNMS, Zabbix, commercial suites: polling + storage + UI + alerts.
- Hybrid observability stacks — something scrapes SNMP into a TSDB you already run.
- External / agentless services — poll from outside your network over SNMPv2c (or whatever they support).
Comparisons: tools comparison, top tools. Pick by who operates it, where it sits, and whether you need traps, discovery, and multi-tenant noise.
A laptop with net-snmp is a manager when you run the command. An always-on poller is a manager when the scheduler runs. Same role, different durability.
External / agentless managers
"Agentless" in marketing usually means you didn't install their proprietary agent—you still need an SNMP agent on the device. The manager is external.
Off-box polling helps when:
- On-prem NMS shares fate with the site
- You want an independent "is SNMP answering?" signal
- You only expose a tight OID allowlist to the outside
Smoke test the same way you'd test any manager path:
snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (43200000) 5 days, 0:00:00.00
If that works from the external network path, an external manager can do the same class of Get. Product-shaped discussion: agentless external, external monitoring. One example in this site's funnel is ostr.io as an external SNMPv2c poller (random community + allowlist, dual cadence)—not a replacement for understanding managers in general.
Don't open UDP 161 to the world because a SaaS needs a check. Scope source IPs. Harden the agent first.
When the manager is the outage
Funny failure mode: agents healthy, paths fine, NMS disk full or scheduler wedged. Graphs flatline; traps may still hit a secondary receiver if you built one. Architecture lesson: monitor the manager too (yes, with something that doesn't share all failure domains).
Another: trap receiver bound on 162 but polls use a different host—events go to a black hole box nobody opens. Draw the diagram with real hostnames.
Manager design choices that actually matter
- Where it runs — same rack as prod vs separate site vs public cloud poller. Failure domains differ.
- How hard it polls — GetBulk size, interval, simultaneous walks. Agents have feelings (and CPU).
- What it stores — raw samples vs rollups; retention is a budget line.
- Who can change templates — one bad OID list becomes a fleet-wide outage of the monitoring plane.
- Trap vs poll ownership — one team owns 161 paths, another owns 162; tickets bounce forever unless you draw ownership on the architecture page.
CLI managers are honest: they do one request and exit. Platforms hide complexity until disk fills or the poller backlog hits an hour. External managers add path dependency on the internet and on how tightly you allowlist OIDs—good if you treat them as a second opinion, bad if they're the only opinion and 161 is wide open.
Build managers like production services: capacity, auth to the UI, backups, and a tested restore. SNMP is the southbound protocol; the NMS is still software that can rot.
Quick self-test after any NMS change: from the poller host, snmpget one scalar on a canary agent; confirm the GUI shows a fresh sample within one interval; send a test trap if you rely on traps. If any leg fails, the architecture diagram just found a crack—fix that before you roll templates fleet-wide. Three green checks beat thirty untested template edits every single time without any exception at all.
Glossary: glossary. Ports: 161/162. How the Get looks on the wire: how it works.
Frequently asked questions
What is an NMS in SNMP?
Network management station—the system that acts as the SNMP manager: polls agents, collects values, often receives traps, and raises alerts.
Does the manager run on the monitored server?
No (not in the usual design). The agent runs on the monitored server; the manager runs elsewhere and queries it.
What port does the manager receive traps on?
UDP 162 for traps and informs. The manager sends queries to the agent on UDP 161.
Examples of SNMP managers?
Net-SNMP CLI tools, on-prem platforms (e.g. LibreNMS, Zabbix and peers), and external polling services. See tools comparison.
Key takeaways
- Manager/NMS = poller + (usually) trap receiver; runs off the device.
- Initiates Get/GetBulk/Set; listens for traps on 162.
- Types: CLI, full NMS, external services—same architectural role.
- Agentless SaaS still needs an on-device SNMP agent.
- Next: agent, architecture, external monitoring.