snmp data via http
December 2, 2005
I was talking today at lunch with Tom and we were discussing what we do and don’t like about snmp and other options to it. Roughly, We like all the data it gives us access to on our servers. We don’t like how convoluted it can be to access it and how specialized the protocol seems to be.
So then I mentioned reading up on WBEM and we were talking about why couldn’t the data from an snmp daemon be made available via http in a REST-ful way, right now. It occurred to us that oids could be converted nicely into directory-displayable indexes without much trouble. Just convert the dotted separation of oids into ‘/’s and you have any given oid on the system as a path.
We talked out a bunch of the pros and cons:
– no more arbitrary protocol design to have to program for and sort out. You simply use normal http get/posts or other verbs and interact with the data you get back.
– searching for these items would be just like traversing a directory tree. We know how to recursively traverse an http structure, this isn’t new.
– all the authentication mechanisms of normal http none of the pain of snmp authentication
– removes yet another different daemon/protocol type to design and check out. As more and more things converge on using http as the protocol one would hope our ability to write and debug an http server would improve. Not to mention that http gets vastly more auditing and programmer time b/c of how much more widely it is used than snmp.
– data for any given server/system would be available using a normal interface that more users are comfortable with. Instead of having to learn an arcane and difficult litany of commands and structures to walk over an snmp mib you could simple browse to a place in the hierarchy and view the data.
– ability to reassign and alias data locations for simple look ups. (think of taking all the entries you most commonly access and aliasing them into one url for quick access. Then when you could check on any given system by just connecting to that path in a web browser and you get a quick summary)
– vastly simplified access to the daemon over proxies
– significantly smaller amounts of code to access the same data. As someone who has done both http-based retrieval and snmp-based retrieval of data the programming interfaces for http-based access are significantly simpler, better designed and more advanced. It’s just plain easier.
– authN/authZ for dealing with setting values is fairly trivial too, given that http already deals with this nicely and pushing data via http is well established.
– gets rid of a single-use protocol. (yay!)
– How to deal with tables and some of the other more advanced snmp types. I think having them be exposed an xml structure wouldn’t be terribly unreasonable. Simple to parse and accurate to handle. Heck all of the structure could be returned as xml to deal with any irregularities in the response type.
How to do it:
So the problem is we don’t want to re-invent the wheel immediately. There’s no point in getting all new mibs and a new data structure. So an easy way might be to setup a simple http server to talk to net-snmp on any given system and convert the oid/mib structure to an http tree structure. That would buy us all of the abilities of current snmp-stacks w/o having to have an externally-exposed snmp daemon.
If we can make all our snmp data exposed via an http server in a directory structure then it simplifies access and handling of that data and it lets us expand the structures we already have in place. It’s also an easy upgrade path away from snmp as we can continue to use our current snmp daemons to organize the data on the system and http to access the data from outside of the system.
I’d love to hear anyone’s thoughts on the idea and if:
1. anyone has already implemented something like this
2. anyone is interested in working on something like this
3. anyone thinks I’m missing some crucial bit of information