On 2014-03-29 15:01, Remco Bressers wrote:
Dear list,
A few of our routers in the network are terribly slow in handling the
complete ifEntry from IF-MIB to Observium. This results in gaps in
graphs and there’s no way to speed things up because of relatively
broken/slow implementations in (in this case) Brocade XMR hardware. In
the past we monitored ifInOctets/ifOutOctets and a few OID’s more. The
full ifEntry is too heavy.
Is there a way to deal with this, like a possibility to prevent
polling the whole thing and skip certain unneeded OID’s. Are there any
plans to enhance the poller for this possibility of is there any
(filthy) hack known to do this? Any ideas on this would be great. We
would definitely want to throw Cacti to /dev/null but due to this
problem it’s not yet possible.
Not necessary to say this again but we are very, very happy with
Observium. Thanks Adam, Mike, Tom and others..
Assuming you have dot3stats/etherlike already disabled, perhaps you could look at our polling run and suggest things we should make optional.
I looked in the code for polling ports and it polls ifEntry and after that, it polls ifXEntry. Everything is just fine, except for polling the whole ifEntry. For some routers we would like to poll the traffic and error statistics exclusively.
The problem is that we are running XMR’s with hundreds of interfaces. A snippet from ifIndex looks like this :
IF-MIB::ifIndex.78 = INTEGER: 78
IF-MIB::ifIndex.79 = INTEGER: 79
IF-MIB::ifIndex.80 = INTEGER: 80
IF-MIB::ifIndex.641 = INTEGER: 641
IF-MIB::ifIndex.16777221 = INTEGER: 16777221
IF-MIB::ifIndex.16777223 = INTEGER: 16777223
IF-MIB::ifIndex.16777225 = INTEGER: 16777225
The regular interfaces we DO want to monitor are using OID’s < 1000 and virtual-interfaces are using OID’s > 16000000. The huge amount of interfaces result in a long polling cycle and sometimes polling just stalls and gaps show up in the graphs because of overlapping poller cycles for this host. Are there possibilities to bring down the polling time? Things like ifMtu or ifPhysAddress are not very relevant and take up a certain amount of time to process.. I know, it’s all about the slow SNMP implementation on the Brocades but i’m looking for a solution.
Thanks,
Remco