Expert
Professor39 minutes ago, Lewis Beard said:I've been having lots of problems over the last few months with collectors having no data or spotty data, and huge amounts of batchscript threads stuck in queue and warnings on my status page (on the collector) about the batchscript being jammed and too many dead tasks. And I've had lots of collector restarts due to dead tasks.
It seems the culprit is the Network Interfaces datasource. I guess Interfaces (64 bit)- is older, but I actually prefer it.
I had a deployment of 12 collectors that were using NI and the batchscripts, which apparently Network Interfaces uses for its operation, and I was getting all kinds of batchscript collector alerts and what-not. So I asked an LM engineer and they told me that it wasnt really fully optimized, and the threads stuck in queue were insane, even though I was using double extra large collectors.
So since it was a new deployment, I switched to the older Interfaces (64 bit)-, and disabled polling on NI completely, and PROBLEM SOLVED. Now my 12 collectors and my 8000+ devices are collecting smooth as silk.
Is this a known issue? Or has anyone had a similar problem? Whats the deal with Network Interfaces? Is it still viable to use the older one that has no dependencies or bottlenecks? Seems to be.
Thanks!
I was just dealing this over the weekend. Been running NI side-by-side still with the original for a while and I was starting to adjust dashboards so I could finally stick with NI and retire snmp64-If-. Sadly, I saw similar weirdness, including a gigbabit interface reporting over a terabit per second. I updated to the latest version, but does not look like it has helped at all. It does work in some cases, but it needs to be flawless in all cases. Sadly, this is something the dev team at LM is often incapable of delivering, including in this module. From discussions with support, they consider NI to be the current/best solution and snmp64* deprecated, but as you have found, they are pushing a bad solution.
