Menu
▾
▴
devmon-support — General Devmon support
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(38) |
Mar
(131) |
Apr
(5) |
May
(23) |
Jun
(9) |
Jul
(9) |
Aug
(9) |
Sep
(24) |
Oct
(28) |
Nov
(33) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(45) |
Feb
(22) |
Mar
(52) |
Apr
(17) |
May
(4) |
Jun
(68) |
Jul
(12) |
Aug
(25) |
Sep
(63) |
Oct
(45) |
Nov
(25) |
Dec
(76) |
| 2008 |
Jan
(34) |
Feb
(53) |
Mar
(30) |
Apr
(42) |
May
(50) |
Jun
(45) |
Jul
(21) |
Aug
(36) |
Sep
(33) |
Oct
(28) |
Nov
(32) |
Dec
(16) |
| 2009 |
Jan
(35) |
Feb
(36) |
Mar
(32) |
Apr
(24) |
May
(26) |
Jun
(15) |
Jul
(17) |
Aug
(30) |
Sep
(14) |
Oct
(18) |
Nov
(26) |
Dec
(22) |
| 2010 |
Jan
(11) |
Feb
(33) |
Mar
(35) |
Apr
(16) |
May
(11) |
Jun
(4) |
Jul
(36) |
Aug
(3) |
Sep
(14) |
Oct
(5) |
Nov
(10) |
Dec
(12) |
| 2011 |
Jan
(7) |
Feb
(31) |
Mar
(13) |
Apr
(14) |
May
(18) |
Jun
(25) |
Jul
(6) |
Aug
(23) |
Sep
(20) |
Oct
(18) |
Nov
(4) |
Dec
(9) |
| 2012 |
Jan
(32) |
Feb
(4) |
Mar
(15) |
Apr
(3) |
May
(8) |
Jun
(9) |
Jul
(6) |
Aug
(6) |
Sep
|
Oct
(14) |
Nov
(22) |
Dec
(4) |
| 2013 |
Jan
(16) |
Feb
(11) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(6) |
Jul
|
Aug
(5) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(3) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(5) |
Nov
(5) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
(4) |
May
|
Jun
(1) |
Jul
(19) |
Aug
(4) |
Sep
(13) |
Oct
(3) |
Nov
(8) |
Dec
(4) |
| 2016 |
Jan
(18) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(7) |
| 2017 |
Jan
(5) |
Feb
|
Mar
(3) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ken C. <kco...@ry...> - 2016-01-22 17:25:13
|
So the probes are there sometimes ? like how often ? I think you have to have two templates. one with the probe checks, one without, then specify in the hosts lists which template to use. Other option is external script which first checks if the probe is present and decides which set of OIDs to poll and reports back to the xymon display. On Fri, Jan 22, 2016 at 11:34 AM, Steve B <rec...@gm...> wrote: > Hi all, > > any ideas on this one? I am monitoring 2 IBM UPS devices (per site) and > testing temperature/humidity snmp monitoring which gives results if a probe > is installed. So I have a temp check, battery capacity and power. When the > probe is installed, I have results for all these checks but if I remove the > probe, the temp check gives unknown as entries and this spreads to the > other checks for that host with the dreaded "No SNMP data found for...." in > the logs so I get white faces and greens with barely any results (there are > a few). > > How can I say to devmon, please only monitor the temp if the probe is > present (and leave the other checks alone)? Or is there another way to look > at this? > > thanks > > Steve > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > -- Ken Connell Network Engineer Computer & Communication Services Ryerson University 350 Victoria St RM AB50 Toronto, Ont M5B 2K3 416-979-5000 x6709 |
|
From: Steve B <rec...@gm...> - 2016-01-22 16:34:42
|
Hi all, any ideas on this one? I am monitoring 2 IBM UPS devices (per site) and testing temperature/humidity snmp monitoring which gives results if a probe is installed. So I have a temp check, battery capacity and power. When the probe is installed, I have results for all these checks but if I remove the probe, the temp check gives unknown as entries and this spreads to the other checks for that host with the dreaded "No SNMP data found for...." in the logs so I get white faces and greens with barely any results (there are a few). How can I say to devmon, please only monitor the temp if the probe is present (and leave the other checks alone)? Or is there another way to look at this? thanks Steve |
|
From: Root, P. T <Pau...@Ce...> - 2016-01-19 18:21:56
|
Thanks! From: Ken Connell [mailto:kco...@ry...] Sent: Tuesday, January 19, 2016 12:15 PM To: Devmon - Email List Cc: Root, Paul T Subject: Re: [Devmon] Templates for Cisco NX and Palo Alto firewalls Here's what I got for PaloAlto: There are 2 attached templates which poll an HA cluster of 2 5060's in active-standby config. I poll the out-of-band interface of each firewall separately (not the VIP) because I want HA status on each. (you'll notice the HA thresholds on the standby template trigger when it's active. That way the change is noted and flagged). Also, depending on code level, the snmp port index numbers sometimes change (seem to always be off by 2, and the poll on fan RPM changes sometimes with code. On Tue, Jan 19, 2016 at 10:48 AM, Root, Paul T <Pau...@ce...<mailto:Pau...@ce...>> wrote: Anybody have templates for Cisco NX switches or Palo Alto firewalls? Thanks, Paul. Paul Root Lead Engineer CenturyLink Network Reliability Operations Center 390 Commerce Dr Woodbury, MN 55125 Direct: (651)312-5207<tel:%28651%29312-5207> Pau...@ce...<mailto:Pau...@ce...> This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Devmon-support mailing list Dev...@li...<mailto:Dev...@li...> https://lists.sourceforge.net/lists/listinfo/devmon-support -- Ken Connell Network Engineer Computer & Communication Services Ryerson University 350 Victoria St RM AB50 Toronto, Ont M5B 2K3 416-979-5000 x6709 The .zip file (paloalto-5060-devmon.zip) attached to this message may pose a virus risk to the network. Please exercise caution. Thank you, Information Security This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. |
|
From: Root, P. T <Pau...@Ce...> - 2016-01-19 16:03:27
|
Anybody have templates for Cisco NX switches or Palo Alto firewalls? Thanks, Paul. Paul Root Lead Engineer CenturyLink Network Reliability Operations Center 390 Commerce Dr Woodbury, MN 55125 Direct: (651)312-5207 Pau...@ce... This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. |
|
From: Stef C. <ste...@do...> - 2015-12-09 11:24:12
|
On Wednesday 02 December 2015 11:50:46 Stef Coene wrote: > Hi, > > I have some NetApps that I monitor, but devmon is refusing Counter64 oids. I found the error. The template was configured for using v1 SNMP and I had to use v2c to get Counter64 support! Stef |
|
From: Stef C. <ste...@do...> - 2015-12-03 12:42:13
|
On Thursday 03 December 2015 11:36:49 W.J.M. Nelis wrote: > On 02-12-15 11:50, Stef Coene wrote: > > Hi, > > > > I have some NetApps that I monitor, but devmon is refusing Counter64 oids. > > > > I did some research and I'm not the first one with this issue, but I > > couldn't find a solution. > > Hmm, I do not experience this problem. For instance, the OIDs used in > template cisco-3750/if_load is: > > ifBps : .1.3.6.1.2.1.2.2.1.5 : branch > ifName : .1.3.6.1.2.1.31.1.1.1.1 : branch > ifInOctets : .1.3.6.1.2.1.31.1.1.1.6 : branch > ifOutOctets : .1.3.6.1.2.1.31.1.1.1.10 : branch > ifAlias : .1.3.6.1.2.1.31.1.1.1.18 : branch > > Both ifInOctets and ifOutOctets are 64-bit counters. When I enable this check on a SAN switch, devmon is also skipping these counter64 oids! So the problem is not devmon related, but in the perl module. I'm using ubuntu 14.04: libnet-snmp-perl: 6.0.1-2 libsnmp-base: 5.7.2~dfsg-8.1ubuntu3 libsnmp-perl: 5.7.2~dfsg-8.1ubuntu3.1 libsnmp-session-perl: 1.13-1.1 libsnmp30:amd64: 5.7.2~dfsg-8.1ubuntu3 snmp: 5.7.2~dfsg-8.1ubuntu3.1 Stef |
|
From: W.J.M. N. <Wim...@nl...> - 2015-12-03 10:57:27
|
On 02-12-15 11:50, Stef Coene wrote: > Hi, > > I have some NetApps that I monitor, but devmon is refusing Counter64 oids. > > I did some research and I'm not the first one with this issue, but I couldn't > find a solution. Hmm, I do not experience this problem. For instance, the OIDs used in template cisco-3750/if_load is: ifBps : .1.3.6.1.2.1.2.2.1.5 : branch ifName : .1.3.6.1.2.1.31.1.1.1.1 : branch ifInOctets : .1.3.6.1.2.1.31.1.1.1.6 : branch ifOutOctets : .1.3.6.1.2.1.31.1.1.1.10 : branch ifAlias : .1.3.6.1.2.1.31.1.1.1.18 : branch Both ifInOctets and ifOutOctets are 64-bit counters. Regards, Wim Nelis. |
|
From: Stef C. <ste...@do...> - 2015-12-02 11:10:41
|
Hi, I have some NetApps that I monitor, but devmon is refusing Counter64 oids. I did some research and I'm not the first one with this issue, but I couldn't find a solution. Stef |
|
From: Ken C. <kco...@ry...> - 2015-11-12 13:36:30
|
Odd...last thing....had something similar as well and was pulling my hair out....build each file for your template manually. I had something off once which I kept missing...but I kept copying the template dir to another and tweaking thus copying over the error. On Nov 12, 2015 4:18 AM, "Steve B" <rec...@gm...> wrote: > Yea I know what you mean, seen a lot of that too. I had already played the > baby steps game and not even one works and appears as 'unknown' even if I > can snmpwalk it with reply. I have checked for spaces throughout or > something else that might cause this to do this. I even used another part > of the MIB tree and made a new check and same results, the only oids I can > use are the ones I use for sensors. > > Can't say this is the first time I have encountered this but usually it > works after a while, by using baby steps etc.. > > Thanks for your input. Not sure what I will do now. > > On Wed, Nov 11, 2015 at 9:28 PM, Ken Connell <kco...@ry...> wrote: > > > If you can get a value back via snmpwalk, then I'd say go the "baby > steps" > > route and start with just one. > > > > I've seen where some oids which are not valid mess up everything else in > > the mix....kinda like a domino effect. > > On Nov 11, 2015 3:24 PM, "Steve B" <rec...@gm...> wrote: > > > > > I have also seen quite a few that don't work or wrongly programmed as > > > branch when should be leaf. > > > > > > Snmpwalk does work and gives a value, just not with a zero on the end. > > > > > > On Wed, Nov 11, 2015 at 7:06 PM, Ken Connell <kco...@ry...> > > wrote: > > > > > > > If you can't get a value back manually via snmpwalk, then your SOL. > > > > > > > > I find many times there are branches & leaf oid objects listed which > > > never > > > > work for that host or code level. > > > > On Nov 11, 2015 1:00 PM, "Steve B" <rec...@gm...> wrote: > > > > > > > > > Had tried it with a zero at the end already: By the way, if I > > snmpwalk > > > > with > > > > > a zero I get: > > > > > SNMPv2-SMI::experimental.94.1.6.1.3.0 = No Such Instance currently > > > exists > > > > > at this OID > > > > > so no dice on that alas. > > > > > > > > > > On Wed, Nov 11, 2015 at 6:06 PM, Ken Connell <kco...@ry...> > > > > wrote: > > > > > > > > > > > Are you sure the leaf objects don't end with a .0 ? > > > > > > > > > > > > >From the top of my head I'm pretty sure they do.....so tac it on > > and > > > > > try. > > > > > > On Nov 11, 2015 11:40 AM, "Steve B" <rec...@gm...> wrote: > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > I am making a template for an HP P2000 G3 and I have a nice > table > > > > > showing > > > > > > > all the status for the sensors. They look like this: > > > > > > > > > > > > > > SensorHex : .1.3.6.1.3.94.1.8.1.1 : branch > > > > > > > SensorIdx : .1.3.6.1.3.94.1.8.1.2 : branch > > > > > > > SensorName : .1.3.6.1.3.94.1.8.1.3 : branch > > > > > > > SensorStatus : .1.3.6.1.3.94.1.8.1.4 : branch > > > > > > > SensorValue : .1.3.6.1.3.94.1.8.1.6 : branch > > > > > > > SensorType : .1.3.6.1.3.94.1.8.1.7 : branch > > > > > > > SensorMetric : .1.3.6.1.3.94.1.8.1.8 : branch > > > > > > > > > > > > > > I am using the FCMGMT-MIB for this. > > > > > > > > > > > > > > Now say I want to make a new check, connectivity and start > > looking > > > > at: > > > > > > > > > > > > > > connUnitType : .1.3.6.1.3.94.1.6.1.3 : > > > leaf > > > > > > > connUnitNumports : .1.3.6.1.3.94.1.6.1.4 : > > > leaf > > > > > > > connUnitState : .1.3.6.1.3.94.1.6.1.5 : > > > leaf > > > > > > > connUnitStatus : .1.3.6.1.3.94.1.6.1.6 : > > > leaf > > > > > > > connUnitProduct : .1.3.6.1.3.94.1.6.1.7 : > > > leaf > > > > > > > > > > > > > > after putting these into the message file, I have 'unknown' for > > all > > > > the > > > > > > > oids on my html page and in the devmon log file I have No SNMP > > data > > > > > found > > > > > > > for connUnitType etc When I look at the mib info here: > > > > > > > > > > > > > > http://www.circitor.fr/Mibs/Html/FCMGMT-MIB.php > > > > > > > or > > > > > > > http://www.oidview.com/mibs/0/FCMGMT-MIB.html > > > > > > > > > > > > > > it looks as if this is branch info even if it's only on one > line. > > > So > > > > I > > > > > > > tried using branch instead of leaf and made a table entry in > > > message > > > > > and > > > > > > > then I had worldwide purple for devmon and had to restart it. > Too > > > > many > > > > > > > forks or similar..iirc > > > > > > > > > > > > > > Now I know this is a tough question but does anyone know why > this > > > is > > > > > > > happening? I should still be able to use this as a leaf (the > > > snmpwalk > > > > > > gives > > > > > > > the value I am expecting to see) but it just won't digest my > > > > > > information. I > > > > > > > am spefically interested in the 'No SNMP data found' and the > > > unknown > > > > > > when a > > > > > > > manual snmpwalk -v2c -c blabla is fine > > > > > > > > > > > > > > cheers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > _______________________________________________ > > > > > > > Devmon-support mailing list > > > > > > > Dev...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > > > > Devmon-support mailing list > > > > > > Dev...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > > > > > Devmon-support mailing list > > > > > Dev...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Devmon-support mailing list > > > > Dev...@li... > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Devmon-support mailing list > > > Dev...@li... > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Devmon-support mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Steve B <rec...@gm...> - 2015-11-12 09:18:42
|
Yea I know what you mean, seen a lot of that too. I had already played the baby steps game and not even one works and appears as 'unknown' even if I can snmpwalk it with reply. I have checked for spaces throughout or something else that might cause this to do this. I even used another part of the MIB tree and made a new check and same results, the only oids I can use are the ones I use for sensors. Can't say this is the first time I have encountered this but usually it works after a while, by using baby steps etc.. Thanks for your input. Not sure what I will do now. On Wed, Nov 11, 2015 at 9:28 PM, Ken Connell <kco...@ry...> wrote: > If you can get a value back via snmpwalk, then I'd say go the "baby steps" > route and start with just one. > > I've seen where some oids which are not valid mess up everything else in > the mix....kinda like a domino effect. > On Nov 11, 2015 3:24 PM, "Steve B" <rec...@gm...> wrote: > > > I have also seen quite a few that don't work or wrongly programmed as > > branch when should be leaf. > > > > Snmpwalk does work and gives a value, just not with a zero on the end. > > > > On Wed, Nov 11, 2015 at 7:06 PM, Ken Connell <kco...@ry...> > wrote: > > > > > If you can't get a value back manually via snmpwalk, then your SOL. > > > > > > I find many times there are branches & leaf oid objects listed which > > never > > > work for that host or code level. > > > On Nov 11, 2015 1:00 PM, "Steve B" <rec...@gm...> wrote: > > > > > > > Had tried it with a zero at the end already: By the way, if I > snmpwalk > > > with > > > > a zero I get: > > > > SNMPv2-SMI::experimental.94.1.6.1.3.0 = No Such Instance currently > > exists > > > > at this OID > > > > so no dice on that alas. > > > > > > > > On Wed, Nov 11, 2015 at 6:06 PM, Ken Connell <kco...@ry...> > > > wrote: > > > > > > > > > Are you sure the leaf objects don't end with a .0 ? > > > > > > > > > > >From the top of my head I'm pretty sure they do.....so tac it on > and > > > > try. > > > > > On Nov 11, 2015 11:40 AM, "Steve B" <rec...@gm...> wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > I am making a template for an HP P2000 G3 and I have a nice table > > > > showing > > > > > > all the status for the sensors. They look like this: > > > > > > > > > > > > SensorHex : .1.3.6.1.3.94.1.8.1.1 : branch > > > > > > SensorIdx : .1.3.6.1.3.94.1.8.1.2 : branch > > > > > > SensorName : .1.3.6.1.3.94.1.8.1.3 : branch > > > > > > SensorStatus : .1.3.6.1.3.94.1.8.1.4 : branch > > > > > > SensorValue : .1.3.6.1.3.94.1.8.1.6 : branch > > > > > > SensorType : .1.3.6.1.3.94.1.8.1.7 : branch > > > > > > SensorMetric : .1.3.6.1.3.94.1.8.1.8 : branch > > > > > > > > > > > > I am using the FCMGMT-MIB for this. > > > > > > > > > > > > Now say I want to make a new check, connectivity and start > looking > > > at: > > > > > > > > > > > > connUnitType : .1.3.6.1.3.94.1.6.1.3 : > > leaf > > > > > > connUnitNumports : .1.3.6.1.3.94.1.6.1.4 : > > leaf > > > > > > connUnitState : .1.3.6.1.3.94.1.6.1.5 : > > leaf > > > > > > connUnitStatus : .1.3.6.1.3.94.1.6.1.6 : > > leaf > > > > > > connUnitProduct : .1.3.6.1.3.94.1.6.1.7 : > > leaf > > > > > > > > > > > > after putting these into the message file, I have 'unknown' for > all > > > the > > > > > > oids on my html page and in the devmon log file I have No SNMP > data > > > > found > > > > > > for connUnitType etc When I look at the mib info here: > > > > > > > > > > > > http://www.circitor.fr/Mibs/Html/FCMGMT-MIB.php > > > > > > or > > > > > > http://www.oidview.com/mibs/0/FCMGMT-MIB.html > > > > > > > > > > > > it looks as if this is branch info even if it's only on one line. > > So > > > I > > > > > > tried using branch instead of leaf and made a table entry in > > message > > > > and > > > > > > then I had worldwide purple for devmon and had to restart it. Too > > > many > > > > > > forks or similar..iirc > > > > > > > > > > > > Now I know this is a tough question but does anyone know why this > > is > > > > > > happening? I should still be able to use this as a leaf (the > > snmpwalk > > > > > gives > > > > > > the value I am expecting to see) but it just won't digest my > > > > > information. I > > > > > > am spefically interested in the 'No SNMP data found' and the > > unknown > > > > > when a > > > > > > manual snmpwalk -v2c -c blabla is fine > > > > > > > > > > > > cheers > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > > > > Devmon-support mailing list > > > > > > Dev...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > > > > > Devmon-support mailing list > > > > > Dev...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Devmon-support mailing list > > > > Dev...@li... > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Devmon-support mailing list > > > Dev...@li... > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Devmon-support mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Ken C. <kco...@ry...> - 2015-11-11 20:28:52
|
If you can get a value back via snmpwalk, then I'd say go the "baby steps" route and start with just one. I've seen where some oids which are not valid mess up everything else in the mix....kinda like a domino effect. On Nov 11, 2015 3:24 PM, "Steve B" <rec...@gm...> wrote: > I have also seen quite a few that don't work or wrongly programmed as > branch when should be leaf. > > Snmpwalk does work and gives a value, just not with a zero on the end. > > On Wed, Nov 11, 2015 at 7:06 PM, Ken Connell <kco...@ry...> wrote: > > > If you can't get a value back manually via snmpwalk, then your SOL. > > > > I find many times there are branches & leaf oid objects listed which > never > > work for that host or code level. > > On Nov 11, 2015 1:00 PM, "Steve B" <rec...@gm...> wrote: > > > > > Had tried it with a zero at the end already: By the way, if I snmpwalk > > with > > > a zero I get: > > > SNMPv2-SMI::experimental.94.1.6.1.3.0 = No Such Instance currently > exists > > > at this OID > > > so no dice on that alas. > > > > > > On Wed, Nov 11, 2015 at 6:06 PM, Ken Connell <kco...@ry...> > > wrote: > > > > > > > Are you sure the leaf objects don't end with a .0 ? > > > > > > > > >From the top of my head I'm pretty sure they do.....so tac it on and > > > try. > > > > On Nov 11, 2015 11:40 AM, "Steve B" <rec...@gm...> wrote: > > > > > > > > > Hi All, > > > > > > > > > > I am making a template for an HP P2000 G3 and I have a nice table > > > showing > > > > > all the status for the sensors. They look like this: > > > > > > > > > > SensorHex : .1.3.6.1.3.94.1.8.1.1 : branch > > > > > SensorIdx : .1.3.6.1.3.94.1.8.1.2 : branch > > > > > SensorName : .1.3.6.1.3.94.1.8.1.3 : branch > > > > > SensorStatus : .1.3.6.1.3.94.1.8.1.4 : branch > > > > > SensorValue : .1.3.6.1.3.94.1.8.1.6 : branch > > > > > SensorType : .1.3.6.1.3.94.1.8.1.7 : branch > > > > > SensorMetric : .1.3.6.1.3.94.1.8.1.8 : branch > > > > > > > > > > I am using the FCMGMT-MIB for this. > > > > > > > > > > Now say I want to make a new check, connectivity and start looking > > at: > > > > > > > > > > connUnitType : .1.3.6.1.3.94.1.6.1.3 : > leaf > > > > > connUnitNumports : .1.3.6.1.3.94.1.6.1.4 : > leaf > > > > > connUnitState : .1.3.6.1.3.94.1.6.1.5 : > leaf > > > > > connUnitStatus : .1.3.6.1.3.94.1.6.1.6 : > leaf > > > > > connUnitProduct : .1.3.6.1.3.94.1.6.1.7 : > leaf > > > > > > > > > > after putting these into the message file, I have 'unknown' for all > > the > > > > > oids on my html page and in the devmon log file I have No SNMP data > > > found > > > > > for connUnitType etc When I look at the mib info here: > > > > > > > > > > http://www.circitor.fr/Mibs/Html/FCMGMT-MIB.php > > > > > or > > > > > http://www.oidview.com/mibs/0/FCMGMT-MIB.html > > > > > > > > > > it looks as if this is branch info even if it's only on one line. > So > > I > > > > > tried using branch instead of leaf and made a table entry in > message > > > and > > > > > then I had worldwide purple for devmon and had to restart it. Too > > many > > > > > forks or similar..iirc > > > > > > > > > > Now I know this is a tough question but does anyone know why this > is > > > > > happening? I should still be able to use this as a leaf (the > snmpwalk > > > > gives > > > > > the value I am expecting to see) but it just won't digest my > > > > information. I > > > > > am spefically interested in the 'No SNMP data found' and the > unknown > > > > when a > > > > > manual snmpwalk -v2c -c blabla is fine > > > > > > > > > > cheers > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > > > > > Devmon-support mailing list > > > > > Dev...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Devmon-support mailing list > > > > Dev...@li... > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Devmon-support mailing list > > > Dev...@li... > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Devmon-support mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Steve B <rec...@gm...> - 2015-11-11 20:23:58
|
I have also seen quite a few that don't work or wrongly programmed as branch when should be leaf. Snmpwalk does work and gives a value, just not with a zero on the end. On Wed, Nov 11, 2015 at 7:06 PM, Ken Connell <kco...@ry...> wrote: > If you can't get a value back manually via snmpwalk, then your SOL. > > I find many times there are branches & leaf oid objects listed which never > work for that host or code level. > On Nov 11, 2015 1:00 PM, "Steve B" <rec...@gm...> wrote: > > > Had tried it with a zero at the end already: By the way, if I snmpwalk > with > > a zero I get: > > SNMPv2-SMI::experimental.94.1.6.1.3.0 = No Such Instance currently exists > > at this OID > > so no dice on that alas. > > > > On Wed, Nov 11, 2015 at 6:06 PM, Ken Connell <kco...@ry...> > wrote: > > > > > Are you sure the leaf objects don't end with a .0 ? > > > > > > >From the top of my head I'm pretty sure they do.....so tac it on and > > try. > > > On Nov 11, 2015 11:40 AM, "Steve B" <rec...@gm...> wrote: > > > > > > > Hi All, > > > > > > > > I am making a template for an HP P2000 G3 and I have a nice table > > showing > > > > all the status for the sensors. They look like this: > > > > > > > > SensorHex : .1.3.6.1.3.94.1.8.1.1 : branch > > > > SensorIdx : .1.3.6.1.3.94.1.8.1.2 : branch > > > > SensorName : .1.3.6.1.3.94.1.8.1.3 : branch > > > > SensorStatus : .1.3.6.1.3.94.1.8.1.4 : branch > > > > SensorValue : .1.3.6.1.3.94.1.8.1.6 : branch > > > > SensorType : .1.3.6.1.3.94.1.8.1.7 : branch > > > > SensorMetric : .1.3.6.1.3.94.1.8.1.8 : branch > > > > > > > > I am using the FCMGMT-MIB for this. > > > > > > > > Now say I want to make a new check, connectivity and start looking > at: > > > > > > > > connUnitType : .1.3.6.1.3.94.1.6.1.3 : leaf > > > > connUnitNumports : .1.3.6.1.3.94.1.6.1.4 : leaf > > > > connUnitState : .1.3.6.1.3.94.1.6.1.5 : leaf > > > > connUnitStatus : .1.3.6.1.3.94.1.6.1.6 : leaf > > > > connUnitProduct : .1.3.6.1.3.94.1.6.1.7 : leaf > > > > > > > > after putting these into the message file, I have 'unknown' for all > the > > > > oids on my html page and in the devmon log file I have No SNMP data > > found > > > > for connUnitType etc When I look at the mib info here: > > > > > > > > http://www.circitor.fr/Mibs/Html/FCMGMT-MIB.php > > > > or > > > > http://www.oidview.com/mibs/0/FCMGMT-MIB.html > > > > > > > > it looks as if this is branch info even if it's only on one line. So > I > > > > tried using branch instead of leaf and made a table entry in message > > and > > > > then I had worldwide purple for devmon and had to restart it. Too > many > > > > forks or similar..iirc > > > > > > > > Now I know this is a tough question but does anyone know why this is > > > > happening? I should still be able to use this as a leaf (the snmpwalk > > > gives > > > > the value I am expecting to see) but it just won't digest my > > > information. I > > > > am spefically interested in the 'No SNMP data found' and the unknown > > > when a > > > > manual snmpwalk -v2c -c blabla is fine > > > > > > > > cheers > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > > > Devmon-support mailing list > > > > Dev...@li... > > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Devmon-support mailing list > > > Dev...@li... > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Devmon-support mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Ken C. <kco...@ry...> - 2015-11-11 18:21:43
|
If you can't get a value back manually via snmpwalk, then your SOL. I find many times there are branches & leaf oid objects listed which never work for that host or code level. On Nov 11, 2015 1:00 PM, "Steve B" <rec...@gm...> wrote: > Had tried it with a zero at the end already: By the way, if I snmpwalk with > a zero I get: > SNMPv2-SMI::experimental.94.1.6.1.3.0 = No Such Instance currently exists > at this OID > so no dice on that alas. > > On Wed, Nov 11, 2015 at 6:06 PM, Ken Connell <kco...@ry...> wrote: > > > Are you sure the leaf objects don't end with a .0 ? > > > > >From the top of my head I'm pretty sure they do.....so tac it on and > try. > > On Nov 11, 2015 11:40 AM, "Steve B" <rec...@gm...> wrote: > > > > > Hi All, > > > > > > I am making a template for an HP P2000 G3 and I have a nice table > showing > > > all the status for the sensors. They look like this: > > > > > > SensorHex : .1.3.6.1.3.94.1.8.1.1 : branch > > > SensorIdx : .1.3.6.1.3.94.1.8.1.2 : branch > > > SensorName : .1.3.6.1.3.94.1.8.1.3 : branch > > > SensorStatus : .1.3.6.1.3.94.1.8.1.4 : branch > > > SensorValue : .1.3.6.1.3.94.1.8.1.6 : branch > > > SensorType : .1.3.6.1.3.94.1.8.1.7 : branch > > > SensorMetric : .1.3.6.1.3.94.1.8.1.8 : branch > > > > > > I am using the FCMGMT-MIB for this. > > > > > > Now say I want to make a new check, connectivity and start looking at: > > > > > > connUnitType : .1.3.6.1.3.94.1.6.1.3 : leaf > > > connUnitNumports : .1.3.6.1.3.94.1.6.1.4 : leaf > > > connUnitState : .1.3.6.1.3.94.1.6.1.5 : leaf > > > connUnitStatus : .1.3.6.1.3.94.1.6.1.6 : leaf > > > connUnitProduct : .1.3.6.1.3.94.1.6.1.7 : leaf > > > > > > after putting these into the message file, I have 'unknown' for all the > > > oids on my html page and in the devmon log file I have No SNMP data > found > > > for connUnitType etc When I look at the mib info here: > > > > > > http://www.circitor.fr/Mibs/Html/FCMGMT-MIB.php > > > or > > > http://www.oidview.com/mibs/0/FCMGMT-MIB.html > > > > > > it looks as if this is branch info even if it's only on one line. So I > > > tried using branch instead of leaf and made a table entry in message > and > > > then I had worldwide purple for devmon and had to restart it. Too many > > > forks or similar..iirc > > > > > > Now I know this is a tough question but does anyone know why this is > > > happening? I should still be able to use this as a leaf (the snmpwalk > > gives > > > the value I am expecting to see) but it just won't digest my > > information. I > > > am spefically interested in the 'No SNMP data found' and the unknown > > when a > > > manual snmpwalk -v2c -c blabla is fine > > > > > > cheers > > > > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Devmon-support mailing list > > > Dev...@li... > > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Devmon-support mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Steve B <rec...@gm...> - 2015-11-11 18:00:35
|
Had tried it with a zero at the end already: By the way, if I snmpwalk with a zero I get: SNMPv2-SMI::experimental.94.1.6.1.3.0 = No Such Instance currently exists at this OID so no dice on that alas. On Wed, Nov 11, 2015 at 6:06 PM, Ken Connell <kco...@ry...> wrote: > Are you sure the leaf objects don't end with a .0 ? > > >From the top of my head I'm pretty sure they do.....so tac it on and try. > On Nov 11, 2015 11:40 AM, "Steve B" <rec...@gm...> wrote: > > > Hi All, > > > > I am making a template for an HP P2000 G3 and I have a nice table showing > > all the status for the sensors. They look like this: > > > > SensorHex : .1.3.6.1.3.94.1.8.1.1 : branch > > SensorIdx : .1.3.6.1.3.94.1.8.1.2 : branch > > SensorName : .1.3.6.1.3.94.1.8.1.3 : branch > > SensorStatus : .1.3.6.1.3.94.1.8.1.4 : branch > > SensorValue : .1.3.6.1.3.94.1.8.1.6 : branch > > SensorType : .1.3.6.1.3.94.1.8.1.7 : branch > > SensorMetric : .1.3.6.1.3.94.1.8.1.8 : branch > > > > I am using the FCMGMT-MIB for this. > > > > Now say I want to make a new check, connectivity and start looking at: > > > > connUnitType : .1.3.6.1.3.94.1.6.1.3 : leaf > > connUnitNumports : .1.3.6.1.3.94.1.6.1.4 : leaf > > connUnitState : .1.3.6.1.3.94.1.6.1.5 : leaf > > connUnitStatus : .1.3.6.1.3.94.1.6.1.6 : leaf > > connUnitProduct : .1.3.6.1.3.94.1.6.1.7 : leaf > > > > after putting these into the message file, I have 'unknown' for all the > > oids on my html page and in the devmon log file I have No SNMP data found > > for connUnitType etc When I look at the mib info here: > > > > http://www.circitor.fr/Mibs/Html/FCMGMT-MIB.php > > or > > http://www.oidview.com/mibs/0/FCMGMT-MIB.html > > > > it looks as if this is branch info even if it's only on one line. So I > > tried using branch instead of leaf and made a table entry in message and > > then I had worldwide purple for devmon and had to restart it. Too many > > forks or similar..iirc > > > > Now I know this is a tough question but does anyone know why this is > > happening? I should still be able to use this as a leaf (the snmpwalk > gives > > the value I am expecting to see) but it just won't digest my > information. I > > am spefically interested in the 'No SNMP data found' and the unknown > when a > > manual snmpwalk -v2c -c blabla is fine > > > > cheers > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Devmon-support mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Ken C. <kco...@ry...> - 2015-11-11 17:36:23
|
Are you sure the leaf objects don't end with a .0 ? >From the top of my head I'm pretty sure they do.....so tac it on and try. On Nov 11, 2015 11:40 AM, "Steve B" <rec...@gm...> wrote: > Hi All, > > I am making a template for an HP P2000 G3 and I have a nice table showing > all the status for the sensors. They look like this: > > SensorHex : .1.3.6.1.3.94.1.8.1.1 : branch > SensorIdx : .1.3.6.1.3.94.1.8.1.2 : branch > SensorName : .1.3.6.1.3.94.1.8.1.3 : branch > SensorStatus : .1.3.6.1.3.94.1.8.1.4 : branch > SensorValue : .1.3.6.1.3.94.1.8.1.6 : branch > SensorType : .1.3.6.1.3.94.1.8.1.7 : branch > SensorMetric : .1.3.6.1.3.94.1.8.1.8 : branch > > I am using the FCMGMT-MIB for this. > > Now say I want to make a new check, connectivity and start looking at: > > connUnitType : .1.3.6.1.3.94.1.6.1.3 : leaf > connUnitNumports : .1.3.6.1.3.94.1.6.1.4 : leaf > connUnitState : .1.3.6.1.3.94.1.6.1.5 : leaf > connUnitStatus : .1.3.6.1.3.94.1.6.1.6 : leaf > connUnitProduct : .1.3.6.1.3.94.1.6.1.7 : leaf > > after putting these into the message file, I have 'unknown' for all the > oids on my html page and in the devmon log file I have No SNMP data found > for connUnitType etc When I look at the mib info here: > > http://www.circitor.fr/Mibs/Html/FCMGMT-MIB.php > or > http://www.oidview.com/mibs/0/FCMGMT-MIB.html > > it looks as if this is branch info even if it's only on one line. So I > tried using branch instead of leaf and made a table entry in message and > then I had worldwide purple for devmon and had to restart it. Too many > forks or similar..iirc > > Now I know this is a tough question but does anyone know why this is > happening? I should still be able to use this as a leaf (the snmpwalk gives > the value I am expecting to see) but it just won't digest my information. I > am spefically interested in the 'No SNMP data found' and the unknown when a > manual snmpwalk -v2c -c blabla is fine > > cheers > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Steve B <rec...@gm...> - 2015-11-11 16:40:17
|
Hi All, I am making a template for an HP P2000 G3 and I have a nice table showing all the status for the sensors. They look like this: SensorHex : .1.3.6.1.3.94.1.8.1.1 : branch SensorIdx : .1.3.6.1.3.94.1.8.1.2 : branch SensorName : .1.3.6.1.3.94.1.8.1.3 : branch SensorStatus : .1.3.6.1.3.94.1.8.1.4 : branch SensorValue : .1.3.6.1.3.94.1.8.1.6 : branch SensorType : .1.3.6.1.3.94.1.8.1.7 : branch SensorMetric : .1.3.6.1.3.94.1.8.1.8 : branch I am using the FCMGMT-MIB for this. Now say I want to make a new check, connectivity and start looking at: connUnitType : .1.3.6.1.3.94.1.6.1.3 : leaf connUnitNumports : .1.3.6.1.3.94.1.6.1.4 : leaf connUnitState : .1.3.6.1.3.94.1.6.1.5 : leaf connUnitStatus : .1.3.6.1.3.94.1.6.1.6 : leaf connUnitProduct : .1.3.6.1.3.94.1.6.1.7 : leaf after putting these into the message file, I have 'unknown' for all the oids on my html page and in the devmon log file I have No SNMP data found for connUnitType etc When I look at the mib info here: http://www.circitor.fr/Mibs/Html/FCMGMT-MIB.php or http://www.oidview.com/mibs/0/FCMGMT-MIB.html it looks as if this is branch info even if it's only on one line. So I tried using branch instead of leaf and made a table entry in message and then I had worldwide purple for devmon and had to restart it. Too many forks or similar..iirc Now I know this is a tough question but does anyone know why this is happening? I should still be able to use this as a leaf (the snmpwalk gives the value I am expecting to see) but it just won't digest my information. I am spefically interested in the 'No SNMP data found' and the unknown when a manual snmpwalk -v2c -c blabla is fine cheers |
|
From: Steve B <rec...@gm...> - 2015-10-23 12:33:43
|
Thanks Mario, will have a look into that, could be just what we need. Regards Steve On Tue, Oct 20, 2015 at 9:47 PM, Mario <row...@gm...> wrote: > Hi, > > I use multiple instances of devmon on my xymon servers. > To do this you need to duplicate the devmon folder and hack some files and > lines to have a new and different devmon process. > > On b-hosts you can use for example: > > 10.10.10.2 host # testip devmon:cid(Abc) DEVMONSVR:cid(abc),ip(10.10.10.1) > > > Regards, > Mario > > On Tue, Oct 20, 2015 at 10:45 AM, Steve B <rec...@gm...> wrote: > > > Hi all, > > > > monitoring IBM X series server and I would like to use only one host line > > in hosts.cfg and therefore one line ine the display with all the checks > in > > their respective columns. I see there is a: > > > > DEVMON:ip(10.0.0.11) > > > > option which seems nice but in this case, on my server I have the > > server's ip giving me RAID snmp info > > but if I want to measure temperatures and other checks, I have to > > query the imm's ip. > > > > Can I do this: > > > > DEVMON:ip(10.0.0.11, 10.0.0.12)? And if not, is there any other way > > to do this, I have a lot of hosts > > so keeping everything on one line would be great. > > > > Thanks > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Devmon-support mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Mario <row...@gm...> - 2015-10-20 19:47:58
|
Hi, I use multiple instances of devmon on my xymon servers. To do this you need to duplicate the devmon folder and hack some files and lines to have a new and different devmon process. On b-hosts you can use for example: 10.10.10.2 host # testip devmon:cid(Abc) DEVMONSVR:cid(abc),ip(10.10.10.1) Regards, Mario On Tue, Oct 20, 2015 at 10:45 AM, Steve B <rec...@gm...> wrote: > Hi all, > > monitoring IBM X series server and I would like to use only one host line > in hosts.cfg and therefore one line ine the display with all the checks in > their respective columns. I see there is a: > > DEVMON:ip(10.0.0.11) > > option which seems nice but in this case, on my server I have the > server's ip giving me RAID snmp info > but if I want to measure temperatures and other checks, I have to > query the imm's ip. > > Can I do this: > > DEVMON:ip(10.0.0.11, 10.0.0.12)? And if not, is there any other way > to do this, I have a lot of hosts > so keeping everything on one line would be great. > > Thanks > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > |
|
From: Steve B <rec...@gm...> - 2015-10-20 12:45:39
|
Hi all, monitoring IBM X series server and I would like to use only one host line in hosts.cfg and therefore one line ine the display with all the checks in their respective columns. I see there is a: DEVMON:ip(10.0.0.11) option which seems nice but in this case, on my server I have the server's ip giving me RAID snmp info but if I want to measure temperatures and other checks, I have to query the imm's ip. Can I do this: DEVMON:ip(10.0.0.11, 10.0.0.12)? And if not, is there any other way to do this, I have a lot of hosts so keeping everything on one line would be great. Thanks |
|
From: Marco A. <mar...@re...> - 2015-09-28 10:02:13
|
Thanks for your suggestion Wim, i'll try to use match operator MA Il 14/09/2015 12.35, W.J.M. Nelis ha scritto: > Hello Marco, > >> i'm tryng to make a template for our cisco 1100 . >> The only way I've found is to run an snmpwalk on the table >> entPhysicalTable, >> but this brings me back to all the sensors on this switch >> >> This is a part of the output, for the descr table: >> .. >> MPv2-SMI::mib-2.47.1.1.1.1.7.7022 = STRING: "VVM 2: VX4 R0/21" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7023 = STRING: "VVM 2: VX5 R0/22" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7024 = STRING: "VVM 2: VP2 R0/23" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7025 = STRING: "VVM 2: VP3 R0/24" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7026 = STRING: "VVM 2: VP4 R0/25" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7027 = STRING: "VVM 2: VH R0/26" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7028 = STRING: "VVM 2: AUX1 R0/27" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7029 = STRING: "VVM 2: AUX2 R0/28" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7030 = STRING: "Temp: sTCAM R0/29" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7031 = STRING: "Temp: Inlet R0/30" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7032 = STRING: "Temp: Outlet R0/31" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7033 = STRING: "Temp: QFP Die R0/32" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7034 = STRING: "Temp: Center R0/33" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7035 = STRING: "Temp: Oct Die R0/34" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7036 = STRING: "Temp: CPU Inlt R0/35" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7037 = STRING: "Temp: CPU VRM R0/36" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7038 = STRING: "Temp: CPU Die R0/37" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7039 = STRING: "Temp: FC FANS R0/38" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7051 = STRING: "cpu R0/0" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7052 = STRING: "usb R0/0" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7054 = STRING: "usb R0/1" >> SNMPv2-SMI::mib-2.47.1.1.1.1.7.7056 = STRING: "NME R0" >> .... >> >> This is a part of the output for the values table: >> ... >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7010 = INTEGER: 1190 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7011 = INTEGER: 843 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7012 = INTEGER: 856 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7013 = INTEGER: 998 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7014 = INTEGER: 874 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7015 = INTEGER: 3320 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7016 = INTEGER: 1811 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7017 = INTEGER: 995 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7018 = INTEGER: 11924 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7019 = INTEGER: 1112 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7020 = INTEGER: 1102 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7021 = INTEGER: 1208 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7022 = INTEGER: 2488 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7023 = INTEGER: 960 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7024 = INTEGER: 1529 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7025 = INTEGER: 1512 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7026 = INTEGER: 2483 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7027 = INTEGER: 11940 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7028 = INTEGER: 751 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7029 = INTEGER: 754 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7030 = INTEGER: 23 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7031 = INTEGER: 17 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7032 = INTEGER: 31 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7033 = INTEGER: 32 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7034 = INTEGER: 31 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7035 = INTEGER: 36 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7036 = INTEGER: 23 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7037 = INTEGER: 22 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7038 = INTEGER: 29 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7039 = INTEGER: 17 >> ... >> For treshold : >> ... >> >> MPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1122.3 = INTEGER: -95 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1122.4 = INTEGER: -135 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.1 = INTEGER: 30 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.2 = INTEGER: 0 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.3 = INTEGER: -170 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.4 = INTEGER: -210 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.1 = INTEGER: 65 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.2 = INTEGER: 72 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.3 = INTEGER: 80 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.4 = INTEGER: 100 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.1 = INTEGER: 55 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.2 = INTEGER: 65 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.3 = INTEGER: 75 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.4 = INTEGER: 80 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.1 = INTEGER: 75 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.2 = INTEGER: 80 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.3 = INTEGER: 85 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.4 = INTEGER: 100 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.1 = INTEGER: 100 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.2 = INTEGER: 110 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.3 = INTEGER: 120 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.4 = INTEGER: 125 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.1 = INTEGER: 75 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.2 = INTEGER: 80 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.3 = INTEGER: 85 >> SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.4 = INTEGER: 100 >> ... >> For state: >> >> ... >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7003 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7004 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7005 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7006 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7007 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7008 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7009 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7010 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7011 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7012 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7013 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7014 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7015 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7016 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7017 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7018 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7019 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7020 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7021 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7022 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7023 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7024 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7025 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7026 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7027 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7028 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7029 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7030 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7031 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7032 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7033 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7034 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7035 = INTEGER: 1 >> SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7036 = INTEGER: 1 >> ... >> >> >> how could I get only values with index from 7030 to 7039 from each >> table ? >> maybe there's another way to get from these switches, the values on >> temperature (but also on fans and power)? thanks for help, Marco > Given the tables above, you could use the MATCH operator to select the > temperatures. I don't know if it will extract the thresholds as well, > because those have an additional index (.1 through .4). > > Regards, > Wim Nelis. > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support |
|
From: Root, P. T <Pau...@Ce...> - 2015-09-24 15:07:45
|
Devmon has been stuck at 0.3 for years. There is no development, just tinkering with templates. -----Original Message----- From: White, Bruce [mailto:BW...@fe...] Sent: Thursday, September 24, 2015 8:41 AM To: Devmon - Email List Subject: Re: [Devmon] Due to PCI 3.0 requirements starting in 2015 we will not be able to use SNMP v1 or SNMP v2 Ken, I understand it could all be replaced with custom scripting, but it would be better if the current tool could be upgraded to work with SNMP v3. Is anyone doing devmon development work? .......Bruce -----Original Message----- From: Ken Connell [mailto:kco...@ry...] Sent: Friday, September 04, 2015 11:12 AM To: Devmon - Email List Subject: Re: [Devmon] Due to PCI 3.0 requirements starting in 2015 we will not be able to use SNMP v1 or SNMP v2 I've asked the same question as well..... Since devmon does not support snmpv3, a band-aid solution (if you plan to keep xymon) is to write your own scripts using snmpv3 and the just report the outputs to the xymon display. On Sep 4, 2015 11:45 AM, "White, Bruce" <BW...@fe...> wrote: > I did not see an answer to this question. > We are being told to get off SNMP v2c because of security issues. > Is there anyone out there that can make the adjustments to how DEVMON > interacts with SNMP to allow SNMP v3 to work? > Unfortunately, I'm just an 30-year sysadmin, who is very grateful for what > this tool has provided in the past. I would be happy to help, but do not > have the expertise to do this kind of change myself. > > .....Bruce > > > > > -----Original Message----- > From: Mark Mulligan [mailto:MMu...@ll...] > Sent: Friday, August 01, 2014 12:37 PM > To: dev...@li... > Subject: [Devmon] Due to PCI 3.0 requirements starting in 2015 we will not > be able to use SNMP v1 or SNMP v2 > > Are there any plans to upgrade devmon to snmp v3? > > Thanks, > > Mark Mulligan > Associate Operations Engineer - Splunk and Xymon Admin > P Please do not print this e-mail unless necessary > > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > Bruce White > Senior Enterprise Systems Engineer | Phone: 1-630-671-5169 | > BW...@fe... | www.fellowes.com > > > Disclaimer: The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader of this > message is not the intended recipient or an employee or agent responsible > for delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to the > message and deleting it from your computer. Thank you. Fellowes, Inc > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > ------------------------------------------------------------------------------ _______________________________________________ Devmon-support mailing list Dev...@li... https://lists.sourceforge.net/lists/listinfo/devmon-support Bruce White Senior Enterprise Systems Engineer | Phone: 1-630-671-5169 | BW...@fe... | www.fellowes.com Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ Devmon-support mailing list Dev...@li... https://lists.sourceforge.net/lists/listinfo/devmon-support This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. |
|
From: White, B. <BW...@fe...> - 2015-09-24 13:41:20
|
Ken, I understand it could all be replaced with custom scripting, but it would be better if the current tool could be upgraded to work with SNMP v3. Is anyone doing devmon development work? .......Bruce -----Original Message----- From: Ken Connell [mailto:kco...@ry...] Sent: Friday, September 04, 2015 11:12 AM To: Devmon - Email List Subject: Re: [Devmon] Due to PCI 3.0 requirements starting in 2015 we will not be able to use SNMP v1 or SNMP v2 I've asked the same question as well..... Since devmon does not support snmpv3, a band-aid solution (if you plan to keep xymon) is to write your own scripts using snmpv3 and the just report the outputs to the xymon display. On Sep 4, 2015 11:45 AM, "White, Bruce" <BW...@fe...> wrote: > I did not see an answer to this question. > We are being told to get off SNMP v2c because of security issues. > Is there anyone out there that can make the adjustments to how DEVMON > interacts with SNMP to allow SNMP v3 to work? > Unfortunately, I'm just an 30-year sysadmin, who is very grateful for what > this tool has provided in the past. I would be happy to help, but do not > have the expertise to do this kind of change myself. > > .....Bruce > > > > > -----Original Message----- > From: Mark Mulligan [mailto:MMu...@ll...] > Sent: Friday, August 01, 2014 12:37 PM > To: dev...@li... > Subject: [Devmon] Due to PCI 3.0 requirements starting in 2015 we will not > be able to use SNMP v1 or SNMP v2 > > Are there any plans to upgrade devmon to snmp v3? > > Thanks, > > Mark Mulligan > Associate Operations Engineer - Splunk and Xymon Admin > P Please do not print this e-mail unless necessary > > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > > > Bruce White > Senior Enterprise Systems Engineer | Phone: 1-630-671-5169 | > BW...@fe... | www.fellowes.com > > > Disclaimer: The information contained in this message may be privileged > and confidential and protected from disclosure. If the reader of this > message is not the intended recipient or an employee or agent responsible > for delivering this message to the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to the > message and deleting it from your computer. Thank you. Fellowes, Inc > > > ------------------------------------------------------------------------------ > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support > ------------------------------------------------------------------------------ _______________________________________________ Devmon-support mailing list Dev...@li... https://lists.sourceforge.net/lists/listinfo/devmon-support Bruce White Senior Enterprise Systems Engineer | Phone: 1-630-671-5169 | BW...@fe... | www.fellowes.com Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Fellowes, Inc |
|
From: W.J.M. N. <Wim...@nl...> - 2015-09-14 10:35:26
|
Hello Marco, > i'm tryng to make a template for our cisco 1100 . > The only way I've found is to run an snmpwalk on the table > entPhysicalTable, > but this brings me back to all the sensors on this switch > > This is a part of the output, for the descr table: > .. > MPv2-SMI::mib-2.47.1.1.1.1.7.7022 = STRING: "VVM 2: VX4 R0/21" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7023 = STRING: "VVM 2: VX5 R0/22" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7024 = STRING: "VVM 2: VP2 R0/23" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7025 = STRING: "VVM 2: VP3 R0/24" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7026 = STRING: "VVM 2: VP4 R0/25" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7027 = STRING: "VVM 2: VH R0/26" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7028 = STRING: "VVM 2: AUX1 R0/27" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7029 = STRING: "VVM 2: AUX2 R0/28" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7030 = STRING: "Temp: sTCAM R0/29" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7031 = STRING: "Temp: Inlet R0/30" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7032 = STRING: "Temp: Outlet R0/31" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7033 = STRING: "Temp: QFP Die R0/32" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7034 = STRING: "Temp: Center R0/33" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7035 = STRING: "Temp: Oct Die R0/34" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7036 = STRING: "Temp: CPU Inlt R0/35" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7037 = STRING: "Temp: CPU VRM R0/36" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7038 = STRING: "Temp: CPU Die R0/37" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7039 = STRING: "Temp: FC FANS R0/38" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7051 = STRING: "cpu R0/0" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7052 = STRING: "usb R0/0" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7054 = STRING: "usb R0/1" > SNMPv2-SMI::mib-2.47.1.1.1.1.7.7056 = STRING: "NME R0" > .... > > This is a part of the output for the values table: > ... > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7010 = INTEGER: 1190 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7011 = INTEGER: 843 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7012 = INTEGER: 856 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7013 = INTEGER: 998 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7014 = INTEGER: 874 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7015 = INTEGER: 3320 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7016 = INTEGER: 1811 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7017 = INTEGER: 995 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7018 = INTEGER: 11924 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7019 = INTEGER: 1112 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7020 = INTEGER: 1102 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7021 = INTEGER: 1208 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7022 = INTEGER: 2488 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7023 = INTEGER: 960 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7024 = INTEGER: 1529 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7025 = INTEGER: 1512 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7026 = INTEGER: 2483 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7027 = INTEGER: 11940 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7028 = INTEGER: 751 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7029 = INTEGER: 754 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7030 = INTEGER: 23 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7031 = INTEGER: 17 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7032 = INTEGER: 31 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7033 = INTEGER: 32 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7034 = INTEGER: 31 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7035 = INTEGER: 36 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7036 = INTEGER: 23 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7037 = INTEGER: 22 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7038 = INTEGER: 29 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7039 = INTEGER: 17 > ... > For treshold : > ... > > MPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1122.3 = INTEGER: -95 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1122.4 = INTEGER: -135 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.1 = INTEGER: 30 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.2 = INTEGER: 0 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.3 = INTEGER: -170 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.4 = INTEGER: -210 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.1 = INTEGER: 65 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.2 = INTEGER: 72 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.3 = INTEGER: 80 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.4 = INTEGER: 100 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.1 = INTEGER: 55 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.2 = INTEGER: 65 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.3 = INTEGER: 75 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.4 = INTEGER: 80 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.1 = INTEGER: 75 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.2 = INTEGER: 80 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.3 = INTEGER: 85 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.4 = INTEGER: 100 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.1 = INTEGER: 100 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.2 = INTEGER: 110 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.3 = INTEGER: 120 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.4 = INTEGER: 125 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.1 = INTEGER: 75 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.2 = INTEGER: 80 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.3 = INTEGER: 85 > SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.4 = INTEGER: 100 > ... > For state: > > ... > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7003 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7004 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7005 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7006 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7007 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7008 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7009 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7010 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7011 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7012 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7013 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7014 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7015 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7016 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7017 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7018 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7019 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7020 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7021 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7022 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7023 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7024 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7025 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7026 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7027 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7028 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7029 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7030 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7031 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7032 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7033 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7034 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7035 = INTEGER: 1 > SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7036 = INTEGER: 1 > ... > > > how could I get only values with index from 7030 to 7039 from each > table ? > maybe there's another way to get from these switches, the values on > temperature (but also on fans and power)? thanks for help, Marco Given the tables above, you could use the MATCH operator to select the temperatures. I don't know if it will extract the thresholds as well, because those have an additional index (.1 through .4). Regards, Wim Nelis. |
|
From: Marco A. <mar...@re...> - 2015-09-14 09:54:20
|
Hi, i'm tryng to make a template for our cisco 1100 . The only way I've found is to run an snmpwalk on the table entPhysicalTable, but this brings me back to all the sensors on this switch This is a part of the output, for the descr table: .. MPv2-SMI::mib-2.47.1.1.1.1.7.7022 = STRING: "VVM 2: VX4 R0/21" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7023 = STRING: "VVM 2: VX5 R0/22" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7024 = STRING: "VVM 2: VP2 R0/23" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7025 = STRING: "VVM 2: VP3 R0/24" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7026 = STRING: "VVM 2: VP4 R0/25" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7027 = STRING: "VVM 2: VH R0/26" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7028 = STRING: "VVM 2: AUX1 R0/27" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7029 = STRING: "VVM 2: AUX2 R0/28" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7030 = STRING: "Temp: sTCAM R0/29" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7031 = STRING: "Temp: Inlet R0/30" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7032 = STRING: "Temp: Outlet R0/31" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7033 = STRING: "Temp: QFP Die R0/32" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7034 = STRING: "Temp: Center R0/33" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7035 = STRING: "Temp: Oct Die R0/34" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7036 = STRING: "Temp: CPU Inlt R0/35" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7037 = STRING: "Temp: CPU VRM R0/36" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7038 = STRING: "Temp: CPU Die R0/37" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7039 = STRING: "Temp: FC FANS R0/38" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7051 = STRING: "cpu R0/0" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7052 = STRING: "usb R0/0" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7054 = STRING: "usb R0/1" SNMPv2-SMI::mib-2.47.1.1.1.1.7.7056 = STRING: "NME R0" .... This is a part of the output for the values table: ... SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7010 = INTEGER: 1190 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7011 = INTEGER: 843 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7012 = INTEGER: 856 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7013 = INTEGER: 998 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7014 = INTEGER: 874 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7015 = INTEGER: 3320 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7016 = INTEGER: 1811 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7017 = INTEGER: 995 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7018 = INTEGER: 11924 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7019 = INTEGER: 1112 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7020 = INTEGER: 1102 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7021 = INTEGER: 1208 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7022 = INTEGER: 2488 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7023 = INTEGER: 960 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7024 = INTEGER: 1529 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7025 = INTEGER: 1512 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7026 = INTEGER: 2483 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7027 = INTEGER: 11940 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7028 = INTEGER: 751 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7029 = INTEGER: 754 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7030 = INTEGER: 23 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7031 = INTEGER: 17 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7032 = INTEGER: 31 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7033 = INTEGER: 32 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7034 = INTEGER: 31 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7035 = INTEGER: 36 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7036 = INTEGER: 23 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7037 = INTEGER: 22 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7038 = INTEGER: 29 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.4.7039 = INTEGER: 17 ... For treshold : ... MPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1122.3 = INTEGER: -95 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1122.4 = INTEGER: -135 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.1 = INTEGER: 30 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.2 = INTEGER: 0 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.3 = INTEGER: -170 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.1123.4 = INTEGER: -210 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.1 = INTEGER: 65 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.2 = INTEGER: 72 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.3 = INTEGER: 80 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7030.4 = INTEGER: 100 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.1 = INTEGER: 55 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.2 = INTEGER: 65 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.3 = INTEGER: 75 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7031.4 = INTEGER: 80 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.1 = INTEGER: 75 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.2 = INTEGER: 80 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.3 = INTEGER: 85 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7032.4 = INTEGER: 100 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.1 = INTEGER: 100 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.2 = INTEGER: 110 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.3 = INTEGER: 120 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7033.4 = INTEGER: 125 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.1 = INTEGER: 75 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.2 = INTEGER: 80 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.3 = INTEGER: 85 SNMPv2-SMI::enterprises.9.9.91.1.2.1.1.4.7034.4 = INTEGER: 100 ... For state: ... SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7003 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7004 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7005 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7006 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7007 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7008 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7009 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7010 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7011 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7012 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7013 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7014 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7015 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7016 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7017 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7018 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7019 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7020 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7021 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7022 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7023 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7024 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7025 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7026 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7027 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7028 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7029 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7030 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7031 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7032 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7033 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7034 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7035 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.91.1.1.1.1.5.7036 = INTEGER: 1 ... how could I get only values with index from 7030 to 7039 from each table ? maybe there's another way to get from these switches, the values on temperature (but also on fans and power)? thanks for help, Marco |
|
From: Steve B <rec...@gm...> - 2015-09-10 09:11:29
|
Hi All, A question, in the last couple of days I have witnessed some devmon shutdowns. I have been making some new templates and in some cases, I have been using some full MIB names, example: cpqRackPowerSupplyEnclosureSerialNum <http://www.circitor.fr/Mibs/Html/CPQRACK-MIB.php#cpqRackPowerSupplyEnclosureSerialNum> Is this too long? Normally I do not use such long names and abbreviate them so I was wondering if this could be the culprit of Devmon stopping working. Here you can see in the devmon.log, a shut down at 10:27 (it shut down by itself) which brings purples to all devmon checks: [15-09-10@10:27:53] No SNMP data found for ifDescr [15-09-10@10:27:53] No SNMP data found for ifDescr [15-09-10@10:27:53] No SNMP data found for ifDescr [15-09-10@10:27:53] No SNMP data found for ifDescr [15-09-10@10:27:53] Shutting down [15-09-10@10:57:54] ---Initilizing devmon... [15-09-10@10:57:54] Node 0 reporting to <servername> [15-09-10@10:57:54] Running under process id: 2363 [15-09-10@10:57:54] Entering poll loop [15-09-10@10:57:54] Undefined oid 'cpqRackEncTmpGcond' referenced in [15-09-10@10:57:54] Attempting to redefine HPG2 /RT3000/batt-capacity template when reading data from [15-09-10@10:57:54] Attempting to redefine HPG2 /RT3000/pwr template when reading data from [15-09-10@10:57:54] Attempting to redefine HPG2 /RT3000/temp template when reading data from [15-09-10@10:57:54] Undefined oid 'upsSecsOnBatt' referenced in [15-09-10@10:59:25] Fork 20 (2514) exceeded poll time polling [15-09-10@10:59:25] Fork 20 (2514) exceeded poll time polling [15-09-10@10:59:52] Fork 15 (2506) exceeded poll time polling [15-09-10@10:59:52] Fork 15 (2506) exceeded poll time polling [15-09-10@11:00:07] Fork 11 (2500) exceeded poll time polling [15-09-10@11:00:07] Fork 11 (2500) exceeded poll time polling [15-09-10@11:00:47] Fork 18 (2510) exceeded poll time polling [15-09-10@11:00:47] Fork 18 (2510) exceeded poll time polling [15-09-10@11:01:02] Fork 12 (2502) exceeded poll time polling [15-09-10@11:01:02] Fork 12 (2502) exceeded poll time polling [15-09-10@11:01:03] Fork 19 (2511) exceeded poll time polling [15-09-10@11:01:03] Fork 19 (2511) exceeded poll time polling At 10:00ish I had introduced the new oids (with long Mib names). I had this same issue yesterday and last week. I started Devmon up again at 10:57. I do have poll time issues from time to time as I am polling devices all over the world and some places are less responsive due to setup but typically my thresholds are ok and my checks are responsive. I have Devmon updating in a 5 minute cycle in Xymon. Any ideas about the length of the oids + subsequent shutdown? Thanks S |
122 messages has been excluded from this view by a project administrator.
