Pat, You can use the Device List view to sort by probe type, e.g. SNMP Traffic, then select the devices using this probe in the list view, right/ctl-click and use the Set Info > Set Thresholds command to change the round-trip time thresholds for just the selected devices.
Regards, Janice Losgar Dartware, LLC -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Pat Storr Sent: Wednesday, January 09, 2008 4:01 PM To: InterMapper Discussion Subject: Re: [IM-Talk] Round trip weirdness I understand the ability to change thresholds on server-wide or on a per-map basis. However, I would like to be alerted if the RTT becomes abnormal. If I change the threshold to clean up my slow-to-reply SNMP devices, I won't know if "normal" devices have abnormal RTT reply. It seems to me that you'd have to be able to set threshold on a per-device basis to accomplish this goal. Maybe the ability to differentiate between ICMP RTT and SNMP RTT would be an option? On 1/9/08 2:46 PM, "Janice Losgar" <[EMAIL PROTECTED]> wrote: > Pat, > > If you are using InterMapper version 4.5 or higher, you can configure the > round-trip time thresholds for warning, alarm and critical alerts. You can > do this server wide using the Server Settings > Device Thresholds settings; > per-map using the Edit > Map Settings > Thresholds > Device settings; or > per-device, using the Set Info > Set Thresholds command. > > Regards, > > Janice Losgar > Dartware, LLC > > -----Original Message----- > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Pat Storr > Sent: Wednesday, January 09, 2008 3:38 PM > To: InterMapper Discussion > Subject: Re: [IM-Talk] Round trip weirdness > > I will add my 2 cents here too. We monitor as much as we can via SNMP. > Some devices are slow to reply with the SNMP request, so the device displays > as yellow, orange or red on the map even though they are operating normally. > If we could change the threshold so they don't change colors based on SNMP > RTT it would keep our maps much cleaner. > > Pat > > > On 1/9/08 2:27 PM, "Steve Himebaugh" <[EMAIL PROTECTED]> wrote: > >> I vote for the name being misleading. RTT is firmly associated with ping > in >> my mind. >> >> FYI ... a ping RTT monitor in the Status Window would be nice. More > useful >> to me than the 'Round-trip time'/SNMP Response Time parameter. I would >> disable the 'Round-trip time' monitor if I had the option. >> >> Steve Himebaugh >> >> ----- Original Message ----- >> From: "Jakob Peterhänsel" <[EMAIL PROTECTED]> >> To: "InterMapper Discussion" <[email protected]> >> Sent: Wednesday, January 09, 2008 10:49 AM >> Subject: Re: [IM-Talk] Round trip weirdness >> >> >> >> I really can't see what's wrong with the name. It very directly tells >> you that this is the time it takes the Probe Used to enquire and get >> back a result. >> >> It does not say 'Ping RTT' does it? >> >> >> It's the same issue if you probe an Xserver for a lot of info - it can >> easily take 500-2500ms, but then you know that the server is slow in >> responding, or collecting the data. >> >> If you wanna know the Ping RTT.. set up a probe for it.. ;-) >> >> >> >> Jakob Peterhänsel >> >> "Be a part of the Love Generation - carry a smile, not a gun." >> - JP, May 2006 >> >> Email: [EMAIL PROTECTED] >> AIM: Marook >> Phone: +45 29687104 >> >> >> On 09/01/2008, at 17.31, Andrey Gordon wrote: >> >>> Hrm... >>> >>> Perhaps then the name of that value is misleading. I can't come up with > a >>> better one at this time, but something like 'Last request took: N sec' >>> would make more sense at a glance. >>> >>> Andrey >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected] ] On Behalf Of Janice Losgar >>> Sent: Wednesday, January 09, 2008 8:49 AM >>> To: 'InterMapper Discussion' >>> Subject: RE: [IM-Talk] Round trip weirdness >>> >>> Andrey, >>> >>> You can't compare the round-trip time of ping packets with an SNMP > probe. >>> For SNMP probes, round-trip time is calculated by the time it takes for >>> the >>> last packet sent to come back. In an SNMP probe with several variables, >>> we >>> send one request for all the variables. The round-trip time is the sum > of >>> the time it takes to retrieve all the information, which would be much >>> different than a simple ping request. >>> >>> Regards, >>> >>> Janice Losgar >>> Dartware, LLC >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Andrey Gordon >>> Sent: Tuesday, January 08, 2008 6:32 PM >>> To: InterMapper Discussion >>> Subject: [IM-Talk] Round trip weirdness >>> >>> I have map with a round trip time issue. I believe this is the only one, >>> but >>> I haven't looked that close for this before. >>> >>> You may notice from the paste of the status window that round trip time >>> to >>> the device is over 150ms according to intermapper >>> >>> Device Status >>> Name: v08-g1-axs-2 >>> DNS Name: v08-g1-axs-2.epicsys.com >>> Address: <snip> >>> Status: UP >>> Probe: SNMP - Cisco - Process and Memory Pool (port 161 SNMPv2c) >>> Up Time: 172 days, 19 hours, 54 minutes >>> SysName: v08-g1-axs-2.epicsys.com >>> Availability: 100 % (of 4 days, 1 hour, 45 minutes) >>> Packet Loss: 0.02 % (of 209673 total attempts) >>> Short-term Packet Loss: 0.0 % (of 100 last attempts) [Reset] >>> Recent Loss: 2 pkts at Jan 08, 15:06:31 >>> Round-trip time: 170 msec >>> Cisco Device Information >>> CPU Percent Busy: 16 % (of last 5 seconds) >>> Avg. CPU % Busy: 18 % (1 min.), 21 % (5 min.) >>> Available Processor Memory: 830841508 bytes >>> Available I/O Memory: 63583940 bytes >>> Last updated Jan 08, 17:29:23; interval: 5 seconds >>> >>> >>> >>> however: >>> >>> [EMAIL PROTECTED]:/~$ ping v08-g1-axs-2 >>> PING v08-g1-axs-2.epicsys.com (<snip>) 56(84) bytes of data. >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=0 ttl=254 >>> time=1.20 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=1 ttl=254 >>> time=1.57 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=2 ttl=254 >>> time=1.17 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=3 ttl=254 >>> time=0.834 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=4 ttl=254 >>> time=0.751 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=5 ttl=254 >>> time=1.03 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=6 ttl=254 >>> time=0.939 ms >>> >>> --- v08-g1-axs-2.epicsys.com ping statistics --- >>> 7 packets transmitted, 7 received, 0% packet loss, time 6005ms >>> rtt min/avg/max/mdev = 0.751/1.072/1.575/0.259 ms, pipe 2 >>> [EMAIL PROTECTED]:/~$ >>> >>> >>> Why is this happening? >>> >>> I'd like to mention that this device is not the only one that does it. >>> I'd >>> like to mention that netmon2 is the server running the intermapper. So, >>> intermapper thins the round trip time is 160ms, but CLI ping from the >>> same >>> box is 1ms. My routers in europe show up with 130ms on the intermapper. >>> >>> The devices that do produce this weird round trip time are all my 3005 >>> cisco >>> VPNc, two fwsm blades and the core internet access router. I understand >>> they >>> use tons more CPU cycles then the rest, but then why does my CLI ping >>> comes >>> back fine? >>> >>> ____________________________________________________________________ >>> List archives: >>> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >>> To unsubscribe: send email to: [EMAIL PROTECTED] >>> >>> ____________________________________________________________________ >>> List archives: >>> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >>> To unsubscribe: send email to: [EMAIL PROTECTED] >>> >>> ____________________________________________________________________ >>> List archives: >>> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >>> To unsubscribe: send email to: [EMAIL PROTECTED] >>> >> >> ____________________________________________________________________ >> List archives: >> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >> To unsubscribe: send email to: [EMAIL PROTECTED] >> >> >> ____________________________________________________________________ >> List archives: >> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >> To unsubscribe: send email to: [EMAIL PROTECTED] >> > > > ____________________________________________________________________ > List archives: > http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ > To unsubscribe: send email to: [EMAIL PROTECTED] > > ____________________________________________________________________ > List archives: > http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ > To unsubscribe: send email to: [EMAIL PROTECTED] > ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [EMAIL PROTECTED] ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [EMAIL PROTECTED]
