How to Monitor System Processes via SNMP

By the SNMP Monitoring team · Reviewed July 2026

Process monitoring over SNMP comes in two useful flavors: a cheap total count, and a per-process table (names, status, optional CPU/mem). The count tells you “the OS is spawning chaos.” The table tells you “is sshd / postgres still there?” Neither replaces a proper service mesh check—but both earn their keep on bare metal and VMs.

Twin (leaves): process sensors. Parent: server monitoring. Walks: snmpwalk.

Total process count

hrSystemProcesses = 1.3.6.1.2.1.25.1.6.0 — current number of processes on the host.

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.1.6.0

HOST-RESOURCES-MIB::hrSystemProcesses.0 = INTEGER: 248

Use cases:

• Spike detection (fork bomb / runaway workers)
• Baseline drift after deploys
• Cheap heartbeat beside CPU/RAM

Alert on sustained deviation from normal band, not a single blip during boot.

The hrSWRunTable

Base 1.3.6.1.2.1.25.4.2.1 — running software table. Useful columns (HOST-RESOURCES style):

Index is typically the process table index the agent uses—not always the OS PID in a friendly way. Always walk and map on your platform.

Per-process CPU & memory

hrSWRunPerfTable base 1.3.6.1.2.1.25.5.1.1:

• CPU .1
• memory .2

Same indexes as the run table when the agent implements both. Great for “which process is fat?” without SSH. Heavy to walk every minute on busy hosts—sample wisely.

Reading them with snmpwalk

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.4.2.1.2

HOST-RESOURCES-MIB::hrSWRunName.1 = STRING: "systemd"
HOST-RESOURCES-MIB::hrSWRunName.400 = STRING: "sshd"
HOST-RESOURCES-MIB::hrSWRunName.512 = STRING: "python3"

Status column:

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.4.2.1.7

HOST-RESOURCES-MIB::hrSWRunStatus.400 = INTEGER: running(1)

(Exact integer labels depend on MIB load; compare to HOST-RESOURCES-MIB on your box.)

Watching for a specific service

Numbered approach:

1. Walk hrSWRunName once; find the string for your daemon.
2. Note the index(es)—some services have multiple workers.
3. Poll name + status for those indexes, or search-by-name each cycle if the NMS supports it.
4. Alert if zero matches for a required process.
5. Optionally require status = running.
6. Pair with availability checks on the service port—process present ≠ port healthy.

Process names truncate; parameters help disambiguate. Don’t match too loosely (python matches everything).

Reference & alerts

Full columns: sensors/processes. Threshold design: alerts.

Starters:

• Count: warn if > baseline × 1.5 for N polls
• Required process missing for N polls → crit
• Perf: top offender CPU sustained high (careful of cost)

External note

Some external pollers reference the process table path 1.3.6.1.2.1.25.4.2.1.x. If you use ostr.io for off-box process-related visibility, allowlist only what you need—full process tables can be chatty. Pattern: external.

One CTA; local NMS can do the same walks.

Limits (be honest)

• Not a full ps aux replacement on every OS/agent
• Indexes churn as processes die/spawn
• Container hosts may show host-level noise
• Security: process lists leak software inventory—views matter

Ops checklist

1. Poll hrSystemProcesses for trend
2. Inventory required daemons by name
3. Build “present” checks
4. Optional perf for troublemakers
5. Re-map after major OS upgrades

Glossary: glossary.

Cost control on process walks

Walking full hrSWRunTable every 30 seconds on a host with thousands of threads/processes will hurt. Patterns that scale:

• Poll count often (cheap scalar)
• Walk names every few minutes or on demand
• Pin indexes for required daemons after each map cycle
• Reserve perf table for suspects, not the whole fleet every minute

If the NMS “process discovery” feature re-walks constantly, rate-limit it. Monitoring should not become the load average incident.

Matching tips that reduce false missing-process alerts

• Prefer stable process names over versioned paths
• Account for worker processes (one master + N workers = multiple rows)
• During deploys, allow brief gaps or use maintenance windows
• On systemd hosts, the visible name might be the unit’s Exec name—verify with a walk after each major distro upgrade

False “postgres down” pages train people to ignore process alerts. Spend an hour making matchers tight; save a year of mute buttons.

Security note

Process lists are inventory. RO communities that can walk hrSWRun* should not be world-readable. Prefer views that allow the scalar count broadly and the full table only to the NMS. Same rule for external pollers: don’t allowlist the entire run table if you only needed a count.

Minimal viable process monitoring

If you only do three things:

1. Graph hrSystemProcesses.
2. Alert when count leaves a sane band for 15+ minutes.
3. Alert when critical process name missing for 5+ minutes.

Everything else (perf table, full inventory walks) is optional depth. Teams that start with “discover all processes and alert on anything weird” drown in noise.

hrSWRunStatus values (operational reading)

Treat status as “is this entry considered running-ish by the agent?” When in doubt, walk a known-good daemon and record the integer your agent returns for healthy state—don’t hard-code enum names from memory across vendors. If status is flaky but the TCP port is fine, trust the port for availability and use SNMP as supporting evidence.

Column suffixes again for copy-paste into templates: name .2, parameters .5, type .6, status .7 under 1.3.6.1.2.1.25.4.2.1; perf CPU .1, mem .2 under 1.3.6.1.2.1.25.5.1.1.

After a kernel or agent upgrade, re-walk one golden host and diff process names you depend on—systemd renames and package renames break string matchers more often than OIDs move. Budget that check in the change plan, not in the incident.

If process monitoring is “too heavy,” fall back to count + one critical process + a TCP check. Perfect is the enemy of paged correctly.

Frequently asked questions

What OID is process count in SNMP?

hrSystemProcesses 1.3.6.1.2.1.25.1.6.0.

Can SNMP list running processes?

Yes, via hrSWRunTable 1.3.6.1.2.1.25.4.2.1 when implemented—names, status, etc.

How do I check if a service is running via SNMP?

Match hrSWRunName (and status) for that service’s process string; confirm with a service port check when it matters.

What is hrSWRunStatus?

Status column on the run table (suffix .7): running/runnable/notRunnable/invalid style values per HOST-RESOURCES—verify enums on your agent.

Key takeaways

• Count: …25.1.6.0. Table: …25.4.2.1. Perf: …25.5.1.1.
• Use count for chaos; table for “is daemon there?”
• Name match + status; indexes churn.
• Twin: sensors/processes.
• External allowlists: keep process walks tight (ostr.io).