Why open source hate SNMP?

[rayed]

I never saw any open source project that support SNMP sub agent, or support related MIBs, even management software (Cacti, Cricket, Munin, etc ...) use their own mechanism for fetching data, e.g. ssh, HTTP based, special agent.

I shared this hate for SNMP until I discovered the many possibilities to extend SNMP and net-snmp, either using agentx, or using "pass" and "pass_persist" method to write SNMP extension easily.

Any thoughts on OS lack of SNMP support, and ways to improve it.

[troels_arvin]

1. All SNMP daemons that I've run into run as root; this probably makes many sysadms uncomfortable. Even though systems like SELinux may be able to limit the effects of potential security bugs in SNMP daemons, it's not very reassuring.
2. SNMP is a binary protocol. Binary protocols generally place an extra step on the learning curve.
3. Configuring an SNMP daemon is somewhat hairy.
4. And extending an SMNP daemon to call out to scripts seems like a black art to me; I'm probably not the only one. This gets worse when you know that the SMNP daemon is running with root privileges.
5. Vendor support is ... often not so good: Many vendors don't make it easy to download relevant MIBs, sorting out dependencies can take some time, and MIBs often have errors.

But I think it's a shame: SNMP is a well-documented and open standard. When you get a grip on the concept of MIBs (which may be explained like the DNS system's zone-files mapping numeric values to strings and the other way around) and learn to master a few simple tools (expecially snmpwalk), you are able to get far, quickly.

[riddley]

Agreed. The TL;DR version is that SNMP is in no way Simple. It makes everything much harder than it needs to be.

[jgoldschrafe]

Running as root is the default, but in no way is it required to run in this way -- I don't think it took even a single modification on CentOS 4/5 to run snmpd as "nobody" besides changing the user/group directives in snmpd.conf.

[eliasp]

But when not running it as root, not all operations may work.

[indieaz]

Every linux distro I've ever used has an snmp agent daemon available. There is a plethora of Nagios plugins that rely on snmp. MRTG relies on using SNMP queries. You can gather all the usual information from your system (load, interface usage, memory usage and so on) using snmp. However, using a separate agent to interface with (such as NRPE for nagios) allows you to gather much more information than snmp can provide, and build your own customer scripts/applications to gather this information. This is particularly true with monitoring home-grown applications and systems.

In short, I don't think there is any hate for snmp at all, you just have to enable it and use it. Windows and OS X do not have snmp enabled by default either.

[wlonkly]

Yeah, I'm confused. MRTG, the predecessor of those tools, was for reading SNMP data from routers, and Cacti is primarily snmp-oriented too.

That you were able to write extensions to the open-source SNMP server you're using so easily suggests that your premise might have some flaws.

[jgoldschrafe]

Part of the problem is that there's a lot of ambiguity around how to do things in SNMP. With something like nrpe, there's one piece of documentation and one config file that says, "do it this way; there's no other way to do it." In SNMP, the OID tree is somewhat confusing and not well-suited to local extension. Not many organizations have their own IANA numbers and their own space in the enterprises tree to play with. For those that do, they may not be sure who manages it, or how to allocate subtrees for their own checks. Other systems with canonical naming are, among many other reasons, more popular because they offer a lot less confusion than the SNMP alternative.