Hi Andreas,
Thanks for the reply.
Inventory- from watching the console it seems the if64 inventory is taking the longest, these entries being the longest to name a few
Running snmpbulkwalk -v2c -c ‘removed’ -m ‘’ -M ‘’ -Cc -OQ -OU -On -Ot 1.2.3.4 .1.3.6.1.2.1.2.2.1.19
Running snmpbulkwalk -v2c -c ‘removed’ -m ‘’ -M ‘’ -Cc -OQ -OU -On -Ot 1.2.3.4 .1.3.6.1.2.1.2.2.1.20
Running snmpbulkwalk -v2c -c ‘removed’ -m ‘’ -M ‘’ -Cc -OQ -OU -On -Ot 1.2.3.4 .1.3.6.1.2.1.2.2.1.21
Running snmpbulkwalk -v2c -c ‘removed’ -m ‘’ -M ‘’ -Cc -OQ -OU -On -Ot 1.2.3.4 .1.3.6.1.2.1.31.1.1.1.18
Total running time was 2m11s
-n ; looks like the if64 bits was taking longer again, sadly I haven’t worked out how to time stamp each line. Also interfaces are being reported as 0 traffic which is not the case, there is plenty of background noise:
Interface ae0 OK - [581] (up) MAC: 44:f4:77:ad:30:43, 2.00GBit/s, in: 0.00B/s, out: 0.00B/s
Interface ae0.0 OK - [582] (up) MAC: 44:f4:77:ad:30:43, 2.00GBit/s, in: 0.00B/s, out: 0.00B/s
Interface bme0 OK - [37] (up) MAC: 00:0b:ca:fe:00:01, speed unknown, in: 0.00B/s, out: 0.00B/s
Interface ge-0/0/0 OK - [stuff] (up) MAC: 84:b5:9c:8a:68:03, 1GBit/s, in: 0.00B/s, out: 0.00B/s
Interface ge-0/0/1 OK - [503] (up) MAC: 84:b5:9c:8a:68:04, 100MBit/s, in: 0.00B/s, out: 0.00B/s
Interface ge-0/0/10 OK - [522] (up) MAC: 84:b5:9c:8a:68:0d, 1GBit/s, in: 0.00B/s, out: 0.00B/s
Interface ge-0/0/11 OK - [524] (up) MAC: 84:b5:9c:8a:68:0e, 10MBit/s, in: 0.00B/s, out: 0.00B/s
Interface ge-0/0/12 OK - [526] (up) MAC: 84:b5:9c:8a:68:0f, 1GBit/s, in: 0.00B/s, out: 0.00B/s
Interface ge-0/0/13 OK - [528] (down) MAC: 84:b5:9c:8a:68:10, speed unknown
Interface ge-0/0/14 OK - [530] (up) MAC: 84:b5:9c:8a:68:11, 1GBit/s, in: 0.00B/s, out: 0.00B/s
Interface ge-0/0/15 OK - [532] (up) MAC: 84:b5:9c:8a:68:12, 1GBit/s, in: 0.00B/s, out: 0.00B/s
Interface ge-0/0/16 OK - [534] (up) MAC: 84:b5:9c:8a:68:13, 10MBit/s, in: 0.00B/s, out: 0.00B/s
OK - execution time 121.7 sec|execution_time=121.667 user_time=0.730 system_time=0.080 children_user_time=0.030 children_system_time=0.050
The stack I queried is 2x 48p.
Where do I go from here? it appears to be taking more than 60 seconds and returning incorrect results?
Thanks for your time.
Kind Regards,
William
···
On 8 June 2015 at 17:52, Andreas Döhler andreas.doehler@gmail.com wrote:
Hi William,
The first steps should be running the inventory from the command line and also the check to see which part takes so long.
cmk --debug -vv -II hostname
and
cmk --debug -vv -n hostname
Now you can see where the switch takes so long to answer. Beside this you have all the executed snmpwalk commands to check by yourself the single steps.
Best regards
Andreas
William willay@gmail.com schrieb am Mo., 8. Juni 2015 10:56:
Morning list,
I’m running OMD with Check_MK 1.2.4p5, currently monitoring over 100 hosts without an issue until last week when we brought up 3 pairs of stacked Juniper EX2200 switches, when monitoring these switches using check_mk I suffer from timeouts, bandwidth values being returned as 0 and very long inventory times (approx 260 seconds) when doing a Live Scan.
I have standalone Juniper EX2200s which have no issues with being monitored, along with various bits of network equipment.
I have already gone down the route of contacting Juniper and they are unable to find anything wrong with my switch configuration and nothing has come up when checking their bug lists, the stacks vary from 2 members to 4, the smallest stacks consist of 96~ ports however I have other switch stacks which do not experience the same issue (2x Juniper 4200 48p for example).
What would be the best way to troubleshoot this issue from my check_mk server? I’d appreciate any help on the matter.
Kind Regards,
William
checkmk-en mailing list
checkmk-en@lists.mathias-kettner.de
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-en
We’ll meet in Munich for the 2nd Check_MK Conference!
Book your place now and be part of it.
October 18th-20th, 2015