CiscoAnyConnect Active Sessions

There is already a global stats datasource from LogicMonitor repo called 'CiscoASA' displayed as 'Global PIX/ASA Stats' (Published with lmLocator: 3XDXDM).  It has numSessions (aggregate over all types) but does not including webvpn and SVC directly.  I submitted feedback request, but you can add those datapoints to the existing datasource using the OIDs that you identified.

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). 

Just as a follow up.  I opened a TAC case and the OIDs I am using are correct for both the ASA and FPR devices.  So....not sure why this isn't working in my environment.

I'm going to check out the version we are  on.  In our sandbox we have 1 FPPR, but in our prod system we have 15-20.....I'm assuming that the versions are spread out but going to do some investigating.  Thanks again Matt and Stuart!

I had that issue when I was testing different OIDs to find the right one.  Usually it was when I was polling a OID incorrectly or the OID didn't exist on the device.  You can try to manually poll that OID and see if you get any value returned.  If you get the anyconnect user count you are expecting you know the issue is on your logicmonitor datasource config side.  If not -- then you know the issue is on your SNMP/OID side.  These 2110 FTDs are running the latest version as they are fairly new so I am not sure if that has anything to do with it.

If you do not get the expected variable returned I would try some other OIDs for your specific firmware, or open a TAC case and ask them what OID to use or why the OID given here isnt working as intended.

Attached some screenshots.  I have pulled this into my prod and sandbox environment and same result.

That's just it....I see that the appliesto is working, SNMP is now polling correctly, but on the FP devices I'm not seeing the new "Cisco" datasource under the devices....but I do on the ASAs.

You can check that your appliesto is working properly (click test applies to and click the link to view the results and ensure your new device is in there). If that's successful, that part is done.

Then you can test the active discovery to see if it's discovering anything. If that part's not working, there's a problem with SNMP or the OIDs specified in discovery aren't there on the version of the device you have (doesn't sounds like the latter should be the case).

If all that works, you can test the polling by going to the device, browsing to the datasource, then the raw data tab. Click poll now to see if you're getting data back.  If that doesn't work, then there's a problem with SNMP (permissions maybe, v3?) or the OIDs specified in the "Datapoints" section of the DS aren't correct.

Thank you Matt and Stuart.  Unfortunately even after setting the displayName in the appliesto isn't working.  I'm having one of the guys take a look as i just noticed that NetFlow is working but we aren't getting any SNMP info...

What you'll need to do is make sure that the datasource is getting "applied" to the additional devices. It sounds like the OIDs and stuff are probably the same between the two, so you would only need to change the "AppliesTo". You can do that manually by adding " || displayName == '[the display name of an additional device]'" to the current applies to. If that gets you data on the 2110, you'll need to further adjust the AppliesTo so that the datasource is trying to collect data for the additional devices. You can do this with a system.category, or a sysOID mapping, or a property source.