hybrid script server / direct snmp polling

[meralias]

I have a large number of devices where I have to use a script to work around issues in the results being returned via SNMP (for example, an ATM interface that shows as one physical interface and 3 sub interfaces .. you have to poll one of the sub interfaces for traffic stats but the description is on the physical port) however collecting counter data is just a straight snmp get. It feels like overkill to have to start a script server just to do a straight snmp get.

[gandalf]

Of course you can do the snmpget using the generic OID template. But for the association, you will still need the script server
R.

[meralias]

My current issue is that i'm polling ~2800 devices, each with at least 10 interfaces, and they respond slowly to SNMP, so i'm having to start a large number of script servers each poll period. They're also not always closing correctly, tying up resources.

I'm going to try and tackle it from a different angle, using the run_data_query api hook (added by autom8) to create a plugin that will do the fixup for me, meaning I can use the generic oid polling method instead.

[gandalf]

Please let us know about your results
R.

[TheWitness]

Is this due to having to combine high and low registers to obtain a 64 bit counter value?

TheWitness

[meralias]

The main two issues that I'm trying to work around involve the information being returned by the device when you are gathering information such as the ifDesc/ifAlias and ifSpeed.

For example, one of the ATM devices I am working with uses multiple physical T1 lines to create a larger aggregated interface. The problem that I have is that I need to know what the maximum bandwidth is for that aggregated interface, and the device simply returns '0' as the ifSpeed. By referring to the ifStackTable table, I can work out which of the T1's are bundled together, sum up their individual ifSpeed entries, and use it as the ifSpeed for the aggregated link.

Another example would be where you may have ATM over SONET - In order to monitor the traffic, you have to monitor the virtual ATM interface, however the port description is only listed on the physical SONET interface. By using the ifStackTable table, I can find out which physical SONET interface is being used by the virtual ATM interface, and use the physical SONET ifAlias entry instead of the blank ATM one.

In both these cases, I'm only having to perform additional steps when "discovering" the interface table, accessing the counters can be done without requiring any special scripting. The problem is that I have to deal with the PHP overhead during normal polling since I'm using a script server script to manipulate the discovery results.

[TheWitness]

Id graph from dsstats. Easy enough.

TheWitness

[maguiresf]

Sorry to resurect an old thread but I've been battling with this problem for a while now and I've just got it to work. Since this thread showed up in my googling and no one else seems to have answered it elsewhere, I thought maybe it would help people in future to know how I got this to work.

In the end I found that I just had to follow the instructions and create a script query as normal, then when creating the data template, select "Get SNMP Data (Indexed)" instead of "Get Script Data (Indexed)". Additionally, and this is the bit that took me a bit of digging around in the code to work out, you have to also add the OIDs that you want to query into your XML file.

So, previously my script data query field might have looked like:

Code: Select all

<ifInOctets>
  <name>Bytes In</name>
  <direction>output</direction>
  <query_name>ifInOctets</query_name>
</ifInOctets>

I just made the addition of the OID and it now looks like:

Code: Select all

<ifInOctets>
  <name>Bytes In</name>
  <direction>output</direction>
  <query_name>ifInOctets</query_name>
  <oid>.1.3.6.1.2.1.2.2.1.10</oid>
</ifInOctets>

This seems to work perfectly, the data query is handled by the script but the poller uses spine's inbuilt SNMP querying to gather the data for the RRDs. If this is already well known, sorry! I couldn't find any reference to it anywhere though so hopefully this will help someone else.