Alejandro,

Thanks for the explanation as to how thresholding will work after this change. I did some additional debugging and found that having resource filtering does not cause and issue with it applied to thresholds but the snmp-interface-poller does so I opened a ticket on that. This ticket can be re-closed.

Thanks again,
-Eric

Hello,

First of all, sorry for confuse you.

For your last question:
"Since I have the data collection config set to "select", only interfaces which I choose for data collection will use thresholds. Is my understanding correct?"

the answer is yes.

I'll try to explain myself better this time.

When you specify thresholding-enabled=true for a specific collection package, OpenNMS will be using the feature "in-line threshold processing"; which means that the rules that apply for data collection also apply for threshold processing.

So, if the data will be stored on disk, this data are the only one that will be used for threshold processing. If the data don't be stored, the data won't be used for threshold processing. BTW, that was the way used by the deprecated Threshd service (because that service reads the data from the RRD/JRB files)

Based on that premise, and taking in consideration that SNMP Interface resources are handled different from other kind of resources, it is important that the snmpCollect flag for the SNMP interfaces is set with 'C' or 'UC', in order to let Collectd knows that the data should be stored for those interfaces. That is true only if snmpStorageFlag is set to "select" inside datacollection-config.xml for the SNMP collection used. The goal of the fix introduced for this bug, was make the threshold processing respects this rule.

If snmpStorageFlag is set to "all", the data storing will be performed no matter which is value of the snmpCollect flag. BTW, I just discover that the threshold processor doesn't respect snmpStorageFlag which is wrong. I'll validate that and I'll open a new bug if that is not working that way.

In some ocations, it could be useful to only apply threshold processing without storing any data. In that case there is a special parameter that should be explicity used for the collection package for this purpose: storing-enabled = false (inside collectd-configuration.xml); which I think is the feature you are interested on.

Now, the resource filters, will be used to avoid applying the thresholds across all resources of the same type, but this is different (or additional to) to everything that I explained so far.

Alejandro

Hi Alejandro,

So I'm a little confused on this request to remove thresholds being removed on all interfaces. I though that is why the resource filtering was available for thresholds, so that one could filter what is wanted to have or not have threshold against. I think a simpler solution for my situation is to just remove all the resource filters all together. Since I have the data collection config set to "select", only interfaces which I choose for data collection will use thresholds. Is my understanding correct?

-Eric

Hello Eric,

I understood your concern (don't worry about that). The good news is you still can do what you want, just need the proper changes in your configuration files.

You need to create a new package on collecd-configuration.xml with the nodes that only need threshold processing (no storing data) with storing-enabled=false; something like this:

<package name="my-special-package">
<filter>PUT THE PROPER FILTER HERE</filter>
<include-range begin="1.1.1.1" end="254.254.254.254"/>
<service name="SNMP" interval="300000" user-defined="false" status="on">
<parameter key="collection" value="default"/>
<parameter key="thresholding-enabled" value="true"/>
<parameter key="storing-enabled" value="false"/>
</service>
</package>

The above example assumes that you don't want to store data for the nodes that match the filter. If you want to partially collect some data (and ignore other), you should create a special snmp-collection package on datacollection-config.xml and enable storing for just that collection. (BTW, storing-enabled=true, is the default behavior when the parameter doesn't exist).

With this in mind, you will be able to enable the collection of SNMP interfaces. Collectd will be responsible for threshold processing, without storing data in JRBs/RRDs.

For your question about the snmp-interface-poller, the answer is yes. Please open an additional bug just for that, because the snmp pollar service works independently of collectd (which is the daemon related to storing and threshold procesing).

Regards,
Alejandro.

Hi Alejandro,

This is just my opinion but that could be in the wrong direction. The example we have is that we have 4500 ports in the data center and we want to know about excessive errors or discards on interfaces but do not want to collect data on all of them. So the changes that were implemented in 1.8.12 would no longer threshold against uncollected interfaces which seems to be a loss of a feature. Don't take this the wrong way I'm just providing my opinion as a user of the product.

Anyhow, I found possible another scenario where filtering causes this issue as well with the snmp interface poller. I use the interface poller the same way I have the threshold filter setup to filter via snmpifalias and if I filter "n7kA" then interface gets deleted from the database or at least the IP address is removed when doing a provision group sync. Should I open a new ticket for that to separate the two issues?

Here is the example configuration for the snmp-interface-poller:

<package name="Interface_Poller">

<filter>IPADDR != '0.0.0.0'</filter>
<include-range begin="1.1.1.1" end="254.254.254.254" />
<interface name="n7kA_Ports" criteria="snmpifalias like 'n7kA%'" interval="20000" retry="3" max-vars-per-pdu="10" user-defined="false" s
tatus="on"/>
</package>

A work around that I have found is to remove the thresholds and snmp interface poller configs back to default. Then sync provisioning group for any needed updates. After all scans are complete reapply the thresholds and snmp interface poller configs. If I don't do this I will have to go back and re-select all interfaces which I want to collect data on, not fun =-).

Thanks,
-Eric