CiscoAnyConnect Active Sessions

I'm finally taking a look at this and I think there is some confusion about multi-instance, discovery, and polling. I don't think this datasource should be multi-instance, which means there should be no active-discovery configuration at all.

To answer the question "should this be multi-instance?", ask yourself this: "Are there multiple objects on this one device for which I want to gather the same metric?" For example, "Are there multiple interfaces on this device for which I want to gather inbound discards?"  In this case, I can see that we're trying to gather the count of active sessions. That's the metric. But what would the objects be? It doesn't seem to me that there are because this is likely a single metric pertaining to the device itself.  I'm now going to go on a tangent and explain how to do active discovery for multiple instances. If you're not interested (because this DS probably isn't multi-instance), skip to the bottom.

If there were multiple objects on this device that each had their own count of active sessions, then we would select the "multi-instance" option in the datasource. After selecting this, we'd need to figure out a way to create those instances, either manually or through active discovery. If using active discovery, we need to find a MIB table containing a listing of these objects. There are two main ways that active discovery can create the instances based on data in the MIB table: 1) value and 2) wildcard.  Understand this before we proceed, in order for LM to create instances, it needs a minimum of two pieces of data: 1) a unique identifier for the object (called WILDVALUE) in LM and 2) a display name for the object (called WILDALIAS) in LM.

VALUE BASED DISCOVERY TYPE
That MIB table would have an index column and hopefully a column that provides some sort of display name for the objects. If it does have a column that you want to use for the display name of each object, you can use "Value" based discovery. For example, the ifEntry MIB table located at 1.3.6.1.2.1.2.2.1 has a column called ifDescr (1.3.6.1.2.1.2.2.1.2). If I wanted to gather statistics for each interface on a device, I would check the "multi-instance" box and enable "active discovery". I would select "value" as the discovery type and provide "1.3.6.1.2.1.2.2.1.2" (a single column/leaf in the MIB table). LM would do an snmpwalk of that OID and use the results to create the instances in LM. Let's see what the walk results look like so we can see what "value" does:

$ !snmpwalk 10.7.255.251 .1.3.6.1.2.1.2.2.1.2
Walking OID .1.3.6.1.2.1.2.2.1.2 from 10.7.255.251:161 for version v2c with community=public pdu.timeout=5s walk.timeout=5s
	1 => Slot: 0 Port: 1 Gigabit - Level
	13 =>  CPU Interface for Slot: 5 Port: 1
	14 =>  Link Aggregate
	15 =>  Link Aggregate
	16 =>  Link Aggregate
	17 =>  Link Aggregate
	2 => Slot: 0 Port: 2 Gigabit - Level
	3 => Slot: 0 Port: 3 Gigabit - Level
	4 => Slot: 0 Port: 4 Gigabit - Level
	5 => Slot: 0 Port: 5 Gigabit - Level
	6 => Slot: 0 Port: 6 Gigabit - Level
	7 => Slot: 0 Port: 7 Gigabit - Level
	8 => Slot: 0 Port: 8 Gigabit - Level

As you can see, since we did an SNMP Walk (not a get/getbulk), we got two pieces of information back for each interface on the device. The first is the index of the object, a good candidate for use as the unique identifier or WILDVALUE. The second piece of data is the ifDescr we asked for and is a good candidate for use as the display name or WILDALIAS of the instance in LM. Since we've chosen "VALUE" as the discovery type, LM will use the index (left column) as the WILDVALUE and the ifDescr (right column) as the WILDALIAS.

WILDCARD BASED DISCOVERY TYPE
If the table you're looking to gather stats from doesn't have a good column from which we can pull a display name, we still have to have a display name. For example, let's look at the hrProcessorEntry table at 1.3.6.1.2.1.25.3.3.1. There are two metrics to pull, but no OIDs that contain any valid names. Let's look at the SNMP Walk of that table:

$ !snmpwalk 10.0.86.41 1.3.6.1.2.1.25.3.3.1
Walking OID 1.3.6.1.2.1.25.3.3.1 from 10.0.86.41:161 for version v2c with community=public pdu.timeout=5s walk.timeout=5s
	1.196608 => 0.0
	1.196609 => 0.0
	1.196610 => 0.0
	1.196611 => 0.0
	2.196608 => 23
	2.196609 => 22
	2.196610 => 21
	2.196611 => 22

As you can see, there are two metrics hrProcessorFrwID (1) and hrProcessorLoad (2). You might think that since hrProcessorFrwID ends in "ID" it might be a good idea to use that as the display name. However, notice the values? They're all "0.0". That won't make for a good display name. So, what do we do? We use "WILDCARD" discovery and provide a single column for LM to do an SNMP Walk. It actually doesn't matter which column in this table we choose because the output will be the same. Since we're interested (in this example) in hrProcessorLoad, let's choose that column. Here's what the collector would see when it does the SNMP Walk of 1.3.6.1.2.1.25.3.3.1.2:

$ !snmpwalk 10.0.86.41 1.3.6.1.2.1.25.3.3.1.2
Walking OID 1.3.6.1.2.1.25.3.3.1.2 from 10.0.86.41:161 for version v2c with community=public pdu.timeout=5s walk.timeout=5s
	196608 => 22
	196609 => 20
	196610 => 19
	196611 => 22

Remember that LM needs two pieces of data to create the instances: WILDVALUE and WILDALIAS. By choosing Wildcard as our discovery type, we instruct LM to use the index (left column) as both the WILDVALUE and the WILDALIAS.

Setting the WILDVALUE properly is important because it is used later when defining datapoints. For example, to pull the hrProcessorLoad from the Wildcard example above, my datapoint OID would be "1.3.6.1.2.1.25.3.3.1.##WILDVALUE##". To pull the ifInDiscards for the "Value" example, my datapoint OID would be "1.3.6.1.2.1.2.2.1.13.##WILDVALUE##". 

TL;DR - SKIP TO HERE

So, now that you know that this DS probably doesn't need to be multi-instance, where does that leave us? What do we do now? Without active discovery, our SNMP polling becomes very simple. Since the metric is on the device level, the WILDVALUE will always be 0 (@Jeffrey.Young this is why you were seeing an instance with the display name "0" in your screenshot from March 30). So, all we need to do is find the OID(s) containing our desired metric(s) and pull them in as datapoints. It looks like the one you're interested in is crasSVCNumSessions (1.3.6.1.4.1.9.9.392.1.3.35), so the datapoint OID would be ".1.3.6.1.4.1.9.9.392.1.3.35.0". To make sure, I recommend doing an SNMPWalk from the collector's debug tool to the target device. I recommend omitting the .35 from the OID so that you can fetch the entire table and look at all the values at once. @Jeffrey.Young, I did test polls against the devices you DM'd me and didn't get any results. It would appear that those devices don't have data in those OIDs. Could be a firmware issue or Cisco decided that certain models would have the data in a different place (they've done it before).