Wednesday, 07 September 2016
In my previous blog post I introduced a problem that exists with some implementations of asynchronous programming. In Oversight we extensively use async programming, especially for retrieving values with snmp. This article is a brief introduction to snmp and pysnmp and serves together with my previous post as background for for my next post.
Let's start with snmp and put in the obligatory (not really) Wikipedia quote:
Simple Network Management Protocol (SNMP) is an Internet-standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks and more
In Oversight one of our main monitoring methods is snmp. If you do monitoring, especially with infrastructures, sooner rather than later you'll be looking into snmp. It's rather low tech and "early days". You can find a pretty good description of its history here. Go read it, I'll be waiting here.
In case you remained here I wouldn't want you to miss this part:
SNMP was initially thought as an interim solution to fill the need for network management tool while a more theoretically sound system was being developed by the ISO. Anticipating the transition to the new network management system, SNMP designers made SNMP modular. Although that transition never occurred, the modularity of SNMP help it evolving through three major versions and found widespread use and acceptance.
So the basic concepts in snmp is that you'll have to understand there are OID's and MIB's. The new pySnmp explains them nicely. You can think of an OID as a tree structure where every vendor has its own subtree. Every table and every metric has its own number. There's quite some stuff that's common across vendors. Those are managed by the IETF you can find a few examples here on wikipedia
You can find the system uptime at
220.127.116.11.18.104.22.168  iso |--  identified-organization |--  dod |--  internet |--  mgmt |--  mib-2 |--  system |--  sysUpTime
Snmp also supports traps. Traps are triggers that can be set up that should alert you when something is wrong. I'm focussing on polling right now because that's what I want to talk about in my next article.
If you have multiple items in a table each instance has its own index. With netsnmp you can do a walk over this tree:
snmpwalk -v 2c -c public 22.214.171.124 126.96.36.199.4.1.232 iso.188.8.131.52.184.108.40.206.1.0 = INTEGER: 1 iso.220.127.116.11.18.104.22.168.2.0 = INTEGER: 31 iso.22.214.171.124.126.96.36.199.3.0 = INTEGER: 2 iso.188.8.131.52.184.108.40.206.220.127.116.11 = INTEGER: 0 iso.18.104.22.168.22.214.171.124.126.96.36.199.0 = INTEGER: 0 iso.188.8.131.52.184.108.40.206.220.127.116.11.1 = INTEGER: 1 iso.18.104.22.168.22.214.171.124.126.96.36.199.0 = INTEGER: 0 iso.188.8.131.52.184.108.40.206.220.127.116.11.1 = INTEGER: 0 iso.18.104.22.168.22.214.171.124.126.96.36.199.0 = STRING: "Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz" iso.188.8.131.52.184.108.40.206.220.127.116.11.1 = STRING: "Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz" iso.18.104.22.168.22.214.171.124.126.96.36.199.0 = INTEGER: 2300 iso.188.8.131.52.184.108.40.206.220.127.116.11.1 = INTEGER: 2300 iso.18.104.22.168.22.214.171.124.126.96.36.199.0 = INTEGER: 2 iso.188.8.131.52.184.108.40.206.220.127.116.11.1 = INTEGER: 2 iso.18.104.22.168.22.214.171.124.126.96.36.199.0 = INTEGER: 2 iso.188.8.131.52.184.108.40.206.220.127.116.11.1 = INTEGER: 2 iso.18.104.22.168.22.214.171.124.126.96.36.199.0 = INTEGER: 100
As you can see everything under
iso.188.8.131.52.184.108.40.206.2.1.1 ends either with a
.0 for the first cpu socket and
.1 for the second cpu socket.
In my next blog I'll use this information to collect the data we need, so stay tuned for my next post!