How to Set Up SNMP Monitoring

Most guides on how to set up SNMP monitoring drown you in options before you've done a single useful thing. This one won't. The job breaks into a handful of ordered moves: install the daemon, tell it who may read which values, lock the community string down, move it off the obvious port, prove it answers, then point something at it that keeps watching when the box itself goes dark. Do them in that order and you'll have a monitored server in under half an hour. This page is the map. Each step links to the child guide that owns the detail, so you can go as deep as you need without losing the thread of the whole SNMP setup.

Prerequisites

Before you configure an SNMP server, make sure the ground is level. A few things need to be true, or the later steps just fail quietly.

• Root or sudo on the target host — you'll edit files under /etc/snmp/ and restart a system service.
• A Linux server you can reach. The examples assume Debian or Ubuntu; RHEL and Windows differ and have their own guides.
• SNMPv2c is fine to start. It's community-based, defined across RFC 1901 and RFC 3416, and it's what most polling and external checkers speak. Reach for SNMPv3 later when you need on-the-wire authentication and encryption.
• UDP 161 open between the poller and the host — the default agent port. You'll likely change it, but know where you're starting.
• The Net-SNMP client tools (snmpwalk, snmpget) on whatever machine you'll test from. They don't have to live on the server itself.

If any of those are missing, sort them first. Nothing downstream works without them.

Step-by-step

Here's the whole sequence, start to finish. Each numbered move is a self-contained guide; follow the links when you want the full walkthrough rather than the summary.

1. Install the agent. On Debian and Ubuntu that's a single apt-get line plus the daemon toggle in /etc/default/snmpd. The full package list and gotchas live in Install snmpd on Ubuntu/Debian.
2. Write the access rules. This is the heart of the config — the com2sec, group, view, and access directives in /etc/snmp/snmpd.conf that decide who reads what. See Configuring snmpd.conf.
3. Allowlist only the OIDs you monitor. Rather than exposing the whole tree, publish a short list of view lines — one per metric. The pattern and the exact OIDs are in the OID allowlist guide.
4. Replace the community string. public is a password everyone already knows. Swap it for a long random string, as covered in Secure the community string.
5. Move off port 161. A non-default port cuts drive-by scanning noise. Change the SNMP port shows the one-line change and the firewall follow-up.
6. Enable and restart the daemon. Flip SNMPDRUN=yes in /etc/default/snmpd (details in the snmpd daemon guide) and run service snmpd restart.
7. Verify from another machine. Walk a known OID and confirm you get a value back.
8. Connect external monitoring so alerts still fire when the server can't speak for itself.

That's the arc. Steps 2 through 5 all touch the same snmpd.conf file, so in practice you edit once, save once, restart once. If something breaks along the way, the troubleshooting guide covers the usual suspects — silent walks, timeouts, permission errors.

Configuration example

The full setup is a short, ordered sequence — each step has its own guide:

Every step above collapses into two small files. Here's the shape of a finished read-only snmpd.conf, so you can see where each move lands:

# /etc/snmp/snmpd.conf  — v2c read-only, allowlisted OIDs
agentAddress udp:161,udp6:[::1]:161        # change 161 to a random port for security

#       sec.name    source    community
com2sec ReadUser    default   <password>

#       group        sec.model  sec.name
group   ReadGroup    v2c        ReadUser

#       view         incl/excl  subtree
view    ReadData     included   .1.3.6.1.2.1.25.1.1.0
# ...one 'view ... included' line per allowed OID...

#       group        context  model  level   prefix  read      write  notify
access  ReadGroup    ""       any    noauth  exact   ReadData  none   none

The daemon itself is switched on in a separate file:

# /etc/default/snmpd
SNMPDRUN=yes
TRAPDRUN=no

Read it top to bottom and the sequence maps cleanly: agentAddress is the port step, com2sec carries the community string, each view line is one allowlisted OID, and access ties the group to read-only, no-write, no-notify. Don't try to memorise the directive grammar here — the snmpd.conf guide unpacks every field. This is just the destination.

Verify it works

Configuration you haven't tested isn't configuration; it's a guess. Two quick checks settle it.

First, confirm the daemon is actually up:

service snmpd status

Then, from a different machine, walk a value you know you allowlisted — host uptime is a good one:

snmpwalk -v2c -c <community> <host>:<port> 1.3.6.1.2.1.25.1.1.0

A line like HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: ... means the whole chain works: daemon running, community accepted, OID in view, port reachable. That uptime value is hrSystemUptime from the Host Resources MIB (RFC 2790), and it's usually the first metric people wire up — the uptime sensor page covers what to do with it. A hang instead of a value points at the port or the firewall; an empty result points at the view. Query from off-box, never from localhost, or you'll miss exactly the network problems monitoring exists to catch.

Security note

SNMP predates a lot of modern security thinking, so a fresh install trusts more than it should. Tighten these before you consider the server done:

• Never leave the community set to public or private. Those are guessable by definition — see Secure the community string.
• Read-only, always. The access line's none for write and notify keeps a leaked string from becoming a write primitive.
• Allowlist, don't blanket-expose. Publish the specific OIDs you chart, nothing more.
• Firewall the agent port to your poller's address, and move it off 161.
• Consider SNMPv3 where the traffic crosses untrusted links, since v2c sends the community in clear text.

The broader threat model — sniffing, spoofing, amplification — lives on the security overview. Treat this list as the minimum, not the ceiling.

Next: connect external monitoring

A monitored server that can only alert itself has a hole in the middle. When the CPU pins or the kernel panics, the local agent is the first thing to stop talking — right when you most need it to shout. That's the gap external polling fills. An independent checker sitting outside your network keeps querying the agent on its own schedule and tests your thresholds on its own hardware, so a crashed or saturated box still trips an alert. This is the principle of double durability: notifications from more than one source beat notifications from none.

ostr.io Monitoring is the zero-setup way to do it. It polls your SNMP endpoint from the outside and fires real-time email and SMS alerts the moment a reading crosses your limit. Wiring it up takes a couple of minutes — the add-endpoint walkthrough has the click-by-click.