JunOS SNMP LogicMonitor Performance
On one of our Juniper Virtual Chassis, we noticed we that we were getting constant and correct responses via SNMP for all our Juniper DataSources (CPU/DOM/State) except for the Network Interfaces DataSource. (“SNMP_Network_Interfaces”) Upon running the collection script, we normally ran into a timeout error. We were expecting around 200 Interfaces to be monitored after filtering. We were thinking of spinning up another collector and setting the timeout to a higher value, but that seemed like wasted resources for just 1 Juniper device. After some research we stumbled across this article (https://forum.checkmk.com/t/junos-snmp-performance-hints/41429) Using the following 2 commands on our JunOS device allowed us to filter out a large number of sub-interfaces along with any internal interfaces. set snmp filter-interfaces interfaces \.0$ set snmp filter-interfaces all-internal-interfaces We tested this on another Juniper device that we wanted to cut down on monitoring sub interfaces and saw that it went from pulling 250 interfaces when running the script down to around 150 before the active discovery filtering. Once these changes were made to our problematic JunOS device, we almost instantly started getting interface traffic in LogicMonitor. I thought I’d shared this in case anyone was having any issues monitoring their Juniper devices via SNMP. The article I referenced goes into more detail on the specifics of the commands.29Views3likes0CommentsDatasource development challenge
Anyone have any ideas about how to solve this challenge? We'd like to collect dhcp relay stats from our Juniper routers, not necessarily for minute-by-minute graphs and alerts but to be able to show patterns of longer term trends (hourly, daily, monthly) I've got the list of OIDs for the counts of DORA plus Naks, Informs, total lease count and total drops. The kicker is that they are stored on a per routing instance (ie VRF) basis and the OIDs aren't structured like #WILDVALUE (routing instance name or ID)#.n.n.n Instead, all routing instances use the same OIDs, and to query them you issue a get at each OID with [routing instance name@(snmp community)] as the snmp community; the output returned corresponds to the name of the routing instance. Somehow this has to possible, but it may be a situation where the effort to achieve and/or sustain it is going to exceed the value of the data it would provide.Solved46Views0likes4Comments