devmon-support — General Devmon support

Re: [Devmon] devmon 0.3.1-beta1 goes purple, error message

[Buchan M. <bg...@st...>]

On Tuesday, 30 November 2010 15:32:46 Taylor Lewick wrote:
> I started devmon with...
> 
> ./devmon --debug -vvvvv -d /home/xymon/server/etc/bbhosts.cfg -c
> /usr/local/devmon/devmon.cfg

The -d should point to a file maintained by devmon (created or updated with 
the --readbbhosts option), typically called hosts.db. By default, unpatched 
devmon looks for hosts.db in the same directory as the 'devmon' script (but, 
distribution packages patch it to be in a filesystem intended for "volatile" 
files)

Probably this is sufficient (with working directory /usr/local/devmon):

./devmon --debug -vvvvv

If not, try:

./devmon --debug -vvvvv -d /usr/local/devmon/hosts.db -c 
/usr/local/devmon/devmon.cfg

> And in the /var/log/devmon.log file, I do see:
> 
> [10-11-29@10:53:20] DEBUG TEMPLATES: running post_template_load()
> [10-11-29@10:53:20] DEBUG CFG: running read_hosts
> [10-11-29@10:53:20] DEBUG SNMP: running poll_devices()

With one or more -v's, you should also see a line such as this for each 
device:

[10-12-01@21:51:28] Querying localdevmon for tests 
disk,processes,if_stat,memory,temp,diskio,ip_route,if_ipv4,if_load

Regards,
Buchan

Re: [Devmon] devmon 0.3.1-beta1 goes purple, error message

[Taylor L. <tl...@tr...>]

Buchan, did you see my last post?  It seems from other related posts, you were interested in someone running debug from latest SVN version, which I did, and everything is purple.  

Whats interesting about this version, is nothing ever started out green, as soon as I started devmon the items just stayed purple.  Like its never actually queried any of the devices, which matches not seeing OIDs in the devmon.log file, yet I see the read_templates and poll_devices, and other messages indicating these processes were run or started successfully.

How else can I assist in tracking down whats wrong?

Thanks,
Taylor

Re: [Devmon] devmon 0.3.1-beta1 goes purple, error message

[Taylor L. <tl...@tr...>]

I started devmon with...

./devmon --debug -vvvvv -d /home/xymon/server/etc/bbhosts.cfg -c /usr/local/devmon/devmon.cfg

And in the /var/log/devmon.log file, I do see:

[10-11-29@10:53:20] DEBUG TEMPLATES: running post_template_load()
[10-11-29@10:53:20] DEBUG CFG: running read_hosts
[10-11-29@10:53:20] DEBUG SNMP: running poll_devices()

Re: [Devmon] devmon 0.3.1-beta1 goes purple, error message

[Buchan M. <bg...@st...>]

On Monday, 29 November 2010 18:06:06 Taylor Lewick wrote:
> I just ran the SVN version, and everything I was testing with devmon now
> just remains purple.

Depending on how you start devmon, where your devmon.cfg file is etc., you may 
need to specify the path to your devmon configuration file (-c option) and the 
'hosts.db' file (-d option)

> Looks like the SNMP tests aren't actually being run,
> I never see any SNMP oids in the devmon.log file now.
> 
> I see this...
> [10-11-29@10:52:19] Fork 1 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 2 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 3 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 4 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 5 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 6 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 7 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 8 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 9 timed out waiting for data from parent: Timeout
> at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
> [10-11-29@10:52:19] Fork 10 timed out waiting for data from parent:
> Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.

There shouldn't be time-outs, even if you aren't polling any devices, as the 
master should "ping" each poller if it hasn't heard from it. Can you provide 
the options you used to start devmon? You may want to try with -f and -v or -
vv or -vvv or -vvvv.

Hmm, you should at least see something like this for every poll period:

[10-11-29@22:05:02] DEBUG TEMPLATES: running read_templates()
[10-11-29@22:05:02] DEBUG TEMPLATES: running post_template_load()
[10-11-29@22:05:02] DEBUG SNMP: running poll_devices()

> And I see one of each of the messages below for all 10 PIDs regarding
> cycletime on the dm page for the xymon host...

I'm running mine from a clean checkout, on a system that can normally run from 
Xymon and devmon RPMs for Mandriva, as follows:

# su - devmon -s /bin/bash -c '/usr/lib64/xymon/client/bin/bbcmd 
/home/bgmilne/Download/source/svn/sf/devmon-clean-trunk/devmon -vvvv -f --
debug'

(or without -f if I want it to log to the log file, fewer v's etc.)

Regards,
Buchan

Re: [Devmon] devmon 0.3.1-beta1 goes purple, error message

[Taylor L. <tl...@tr...>]

I just ran the SVN version, and everything I was testing with devmon now just remains purple.  Looks like the SNMP tests aren't actually being run, I never see any SNMP oids in the devmon.log file now.

I see this...
[10-11-29@10:52:19] Fork 1 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 2 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 3 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 4 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 5 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 6 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 7 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 8 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 9 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.
[10-11-29@10:52:19] Fork 10 timed out waiting for data from parent: Timeout at /usr/local/devmon-svn-20101129/modules/dm_snmp.pm line 516.

And I see one of each of the messages below for all 10 PIDs regarding cycletime on the dm page for the xymon host...

1   12515           843s ago        idle for more than cycletime yellow




-----Original Message-----
From: Buchan Milne [mailto:bg...@st...] 
Sent: Monday, November 29, 2010 3:55 AM
To: dev...@li...
Cc: Taylor Lewick
Subject: Re: [Devmon] devmon 0.3.1-beta1 goes purple, error message

On Friday, 26 November 2010 15:14:50 Taylor Lewick wrote:
> We upgraded xymon to run 4.3.0-0.beta2 from hobbit 4.2.3
> In so doing, we also upgraded devmon to devmon 0.3.1-beta1.  So far
> everything with xymon works great, and devmon works as expected, except it
> goes purple quite often.

I can't reproduce this reliably myself. There have been some issues I could 
reproduce, which have been fixed in changes since 0.3.0-rc1 and 0.3.1-beta1, 
and between 0.3.1-beta1 and current svn.

> This last time it happened, we received the following error message:
> Can't use an undefined value as a HASH reference at
> /usr/local/devmon/modules/dm_snmp.pm line 405, <$__ANONIO__> line 40712.
> 
> Looked at dm_snmp.pm and we can't really make too much sense of whats going
> on here.  Is this helpful at all to tracking down the devmon goes purple
> problem?

There are some changes in svn to address some possible issues, and to add a 
bit more information to the 'dm' test for the devmon host (statistics for each 
polling process, ensuring the polling process are still communicating with the 
master etc., additional logging).

If you are experiencing problems, it would be best if you could run the 
version from svn with --debug, and:
-report if it works better (goes purple less often)
-report on what occurs when it does go purple, there should be additional 
logging indicating what occurred just prior to it going purple

It's probably best to do an svn checkout, see:

http://sourceforge.net/projects/devmon/develop

> FYI, in our older version of devemon 0.3.0-rc1, it never goes purple, so
> was hoping to avoid rolling back to that version if possible.

Well, you could have a look at the differences between 0.3.0-rc1 and 0.3.1-
beta1, by using e.g.:

svn diff -r 80:124 
https://devmon.svn.sourceforge.net/svnroot/devmon/trunk/modules

The only change that should have made any difference is this one:

http://devmon.svn.sf.net/viewvc/devmon?view=revision&revision=82

which fixes a problem I could reproduce, and was included in the 0.3.0 (final) 
release.

Regards,
Buchan

Re: [Devmon] devmon 0.3.1-beta1 goes purple, error message

[Buchan M. <bg...@st...>]

On Friday, 26 November 2010 15:14:50 Taylor Lewick wrote:
> We upgraded xymon to run 4.3.0-0.beta2 from hobbit 4.2.3
> In so doing, we also upgraded devmon to devmon 0.3.1-beta1.  So far
> everything with xymon works great, and devmon works as expected, except it
> goes purple quite often.

I can't reproduce this reliably myself. There have been some issues I could 
reproduce, which have been fixed in changes since 0.3.0-rc1 and 0.3.1-beta1, 
and between 0.3.1-beta1 and current svn.

> This last time it happened, we received the following error message:
> Can't use an undefined value as a HASH reference at
> /usr/local/devmon/modules/dm_snmp.pm line 405, <$__ANONIO__> line 40712.
> 
> Looked at dm_snmp.pm and we can't really make too much sense of whats going
> on here.  Is this helpful at all to tracking down the devmon goes purple
> problem?

There are some changes in svn to address some possible issues, and to add a 
bit more information to the 'dm' test for the devmon host (statistics for each 
polling process, ensuring the polling process are still communicating with the 
master etc., additional logging).

If you are experiencing problems, it would be best if you could run the 
version from svn with --debug, and:
-report if it works better (goes purple less often)
-report on what occurs when it does go purple, there should be additional 
logging indicating what occurred just prior to it going purple

It's probably best to do an svn checkout, see:

http://sourceforge.net/projects/devmon/develop

> FYI, in our older version of devemon 0.3.0-rc1, it never goes purple, so
> was hoping to avoid rolling back to that version if possible.

Well, you could have a look at the differences between 0.3.0-rc1 and 0.3.1-
beta1, by using e.g.:

svn diff -r 80:124 
https://devmon.svn.sourceforge.net/svnroot/devmon/trunk/modules

The only change that should have made any difference is this one:

http://devmon.svn.sf.net/viewvc/devmon?view=revision&revision=82

which fixes a problem I could reproduce, and was included in the 0.3.0 (final) 
release.

Regards,
Buchan

[Devmon] devmon 0.3.1-beta1 goes purple, error message

[Taylor L. <tl...@tr...>]

We upgraded xymon to run 4.3.0-0.beta2 from hobbit 4.2.3
In so doing, we also upgraded devmon to devmon 0.3.1-beta1.  So far everything with xymon works great, and devmon works as expected, except it goes purple quite often.

This last time it happened, we received the following error message:
Can't use an undefined value as a HASH reference at /usr/local/devmon/modules/dm_snmp.pm line 405, <$__ANONIO__> line 40712.

Looked at dm_snmp.pm and we can't really make too much sense of whats going on here.  Is this helpful at all to tracking down the devmon goes purple problem?

FYI, in our older version of devemon 0.3.0-rc1, it never goes purple, so was hoping to avoid rolling back to that version if possible.

Thanks in advance for any help.,
Taylor

Re: [Devmon] devmon 0.3.1-beta1 goes purple, error message

[Taylor L. <tl...@tr...>]

Also, as a second unrelated issue, believe we (another guy I work with) found an error in the Math Transform that was causing devmon to crash...

/usr/local/devmon/modules # diff dm_templates.pm.bak dm_templates.pm
537c537
<           $temp =~ s/\{\s*\S+?\s*\}|\s|x|\+|\/|-|^|\d+(\.\d*)?|\(|\)\s*//g;
---
>           $temp =~ s/\{\s*\S+?\s*\}|\s|x|\+|\/|-|\^|\d+(\.\d*)?|\(|\)\s*//g;

FYI, here is the diff that fixes exponentiation in the MATH transform: (had to escape the ^, so it would be seen as a literal '^' instead of a start of line delimiter)  This is in the logic that checks the format of the transform, not the logic that does the transform (which apparently works fine)



From: Taylor Lewick
Sent: Friday, November 26, 2010 8:15 AM
To: 'dev...@li...'
Subject: devmon 0.3.1-beta1 goes purple, error message

We upgraded xymon to run 4.3.0-0.beta2 from hobbit 4.2.3
In so doing, we also upgraded devmon to devmon 0.3.1-beta1.  So far everything with xymon works great, and devmon works as expected, except it goes purple quite often.

This last time it happened, we received the following error message:
Can't use an undefined value as a HASH reference at /usr/local/devmon/modules/dm_snmp.pm line 405, <$__ANONIO__> line 40712.

Looked at dm_snmp.pm and we can't really make too much sense of whats going on here.  Is this helpful at all to tracking down the devmon goes purple problem?

FYI, in our older version of devemon 0.3.0-rc1, it never goes purple, so was hoping to avoid rolling back to that version if possible.

Thanks in advance for any help.,
Taylor

Re: [Devmon] error: Undefined subroutine &dm_templates

[Buchan M. <bg...@st...>]

On Monday, 22 November 2010 14:44:15 Alessandro Tinivelli wrote:
> hi all,
> 
> i'm new to devmon trying to use it with xymon 4.2.3.
> 

How did you install devmon?

> 
> 
> Running  ./devmon --readbbhosts -vv
> 
> i am getting this
> 
> 
> 
> [HOBBITUSER@bsmon03 devmon-0.3.1-beta1]$  ./devmon --readbbhosts -vvv
> 
> [10-11-22@12:49:45] Option 'bblocation' defaulting to:
> 
> Undefined subroutine &dm_templates::log_fatal called at
> /home/HOBBITUSER/devmon-0.3.1-beta1/modules/dm_templates.pm line 175.

Well, line 175 of dm_templates.pm says:

log_fatal("Unable to open template directory ($!)",0);

So, most likely you did not follow the installation instructions which 
indicated you should download and unpack the templates tarball as well.

(BTW, this should have reported the error correctly, in my test it shows:

$ ./devmon --readbbhosts
[10-11-24@14:56:51] Unable to open template directory (No such file or 
directory)

)

Regards,
Buchan

[Devmon] error: Undefined subroutine &dm_templates

[Alessandro T. <ale...@mo...>]

hi all,

i'm new to devmon trying to use it with xymon 4.2.3.

 

Running  ./devmon --readbbhosts -vv

i am getting this

 

[HOBBITUSER@bsmon03 devmon-0.3.1-beta1]$  ./devmon --readbbhosts -vvv

[10-11-22@12:49:45] Option 'bblocation' defaulting to:

Undefined subroutine &dm_templates::log_fatal called at
/home/HOBBITUSER/devmon-0.3.1-beta1/modules/dm_templates.pm line 175.

 

i have tried same command as root with same result. i created the log
file defined in devmon.cfg and gave permissions to be written but it
remains empty.

 

I've googled this error but was not able to find someother with same
problem...

 

thanks in advance

 

--

Alessandro 

 

Re: [Devmon] Problem while installing devmon

[Marco A. <mar...@re...>]

Hi,

i have the same problem .. i always xymon 4.2.0 .... updating 4.3.0
thanks for help
Marco

Il 18/03/2009 18.20, Gé Janssen ha scritto:
> Hi,
>
> Recently I updated my xymon server to 4.23 and I started testing devmon.
>
> Unfortunately I can't get it working. Can someone point me to the right
> direction?
>
> Steps I took:
>
> Install xymon (/opt/monitor/xymon
> install devmon (/opt/monitor/devmon-0.3.1-beta1/) and link -s
> devmon-0.3.1-beta1 devmon
> install templates (devmon-templates-20080206) and link -s
> devmon-templates-20080206 templates
>
> cp /usr/lib/mrtg2/*pm modules
>
> configuring bb-hosts:
> 10.128.168.20   sw2950 # dialup http://sw2950/ ssh telnet
> DEVMON:tests(cpu,fans,power)
>
>
> configuring devmon.cfg
>
> BBHOSTS=/opt/monitor/xymon/server/etc/bb-hosts
> DISPSERV=10.128.168.215 (and tried localhost)
> DISPPORT=1984
>
> crontab:
> */5 * * * *     root /root/devmon.sh
>
> script:
> callisto:/opt/monitor/devmon # cat /root/devmon.sh
> cd /opt/monitor/devmon
> /opt/monitor/devmon/devmon --readbbhosts
>
>
> Tested so far:
> callisto:/opt/monitor/devmon # snmpget -v2c -c public sw2950
> 1.3.6.1.2.1.1.1.0  SNMPv2-MIB::sysDescr.0 = STRING: Cisco Internetwork
> Operating System Software
> IOS (tm) C2950 Software (C2950-I6K2L2Q4-M), Version 12.1(22)EA13,
> RELEASE SOFTWARE (fc2)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2009 by cisco Systems, Inc.
> Compiled Fri 27-F
>
> works.....
>
> callisto:/opt/monitor/devmon # ./devmon --readbbhosts -vvv
> [09-03-18@17:53:58] Option 'bblocation' defaulting to:
> [09-03-18@17:53:58] SNMP querying all hosts in bb-hosts file, please wait...
> [09-03-18@17:53:58] Checking if         # bbd http://callisto/ matches NET:.
> [09-03-18@17:53:58] Checking if                 # dialup http://sw2950/
> ssh telnet DEVMON  matches NET:.
> [09-03-18@17:53:58] Option 'bbdateformat' defaulting to: .
> [09-03-18@17:53:58] Querying pre-existing hosts
> [09-03-18@17:53:58] Discovered sw2950 as a cisco 2950
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
> [09-03-18@17:53:58] Received signal TERM, shutting down with return code 0
>
> is this OK??
>
>
> If I do a:
> ./devmon -f -p -vvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>
> Everything checks out ok.
>
> for instance:
> status sw2950.memory green Wed Mar 18 18:04:08 2009
>
> Free memory:       1282980 bytes (33%)
> Used memory:       2602216 bytes (67%)
> -------------     ----------------
> Total memory:      3885196.00 bytes (100%)
>
> <!-- DEVMON to RRD Physical 67%
> -->
>
>
> Devmon version 0.3.1-beta1 running on callisto
>
>
> If I do a telnet to the xymon server at port 1984 and copy this data,
> everything displays ok:
>
> output from logging: (/var/log/devmon.log)
>
> [09-03-18@18:04:06] ---Initilizing devmon...
> [09-03-18@18:04:06] Verbosity level: 18
> [09-03-18@18:04:06] Logging to /var/log/devmon.log
> [09-03-18@18:04:06] Node 0 reporting to 44.128.168.215
> [09-03-18@18:04:06] Running under process id: 11811
> [09-03-18@18:04:06] Entering poll loop
> [09-03-18@18:04:06] Starting snmp queries
> [09-03-18@18:04:06] Getting device status from hobbit at 44.128.168.215:1984
> [09-03-18@18:04:06] Querying sw2950 for tests
> if_dsc,cpu,serial,if_stat,fans,if_col,memory,power,if_err,if_load
> [09-03-18@18:04:08] Performing test logic
> [09-03-18@18:04:08] Done with test logic
> [09-03-18@18:04:08] Sending messages to display server
> [09-03-18@18:04:08] Sleeping for 58 seconds.
> [09-03-18@18:04:10] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:10] Shutting down
> [09-03-18@18:04:10] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:10] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:11] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:11] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:11] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:11] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:11] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:11] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:11] Received signal INT, shutting down with return code 0
> [09-03-18@18:04:11] Received signal INT, shutting down with return code 0
>
>
> My interpretation is that devmon doesn't try to reach, or can't reach
> the xymon server. But what is wrong?
>
> port, firewall, etc. is open and checks ok.
>
> Thanks for your assistance.
>
> Ge
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Devmon-support mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devmon-support
>    

[Devmon] Multiple bbdisplay configuration

[Mario A. P. <row...@gm...>]

Hi All,

It´s possible to send the devmon results for multiple bbdisplays servers?


Thanks in advance,

Mario.

Re: [Devmon] [xymon] Devmon if_stat alarm consistency

[Chris W. <ch...@su...>]

Buchan Milne wrote:
> I prefer not to "fix" templates that relate to devices I don't have access to, 
> especially since I am not familiar with all the naming conventions for 
> interfaces on Cisco equipment.
> 
> Please log a tracker item on the SF page. Feel free to attach a patch against 
> current svn.

I submitted a patch. I also included a few other templates I've been 
using but forgot to add (vmware-esx4, mikrotik-rb400, cisco-1600) as 
well as fixes to cisco-2811 where CPU graphing is screwed up as well as 
the previously mentioned alert issue.

Thanks
--Chris

Re: [Devmon] [xymon] Devmon if_stat alarm consistency

[Buchan M. <bg...@st...>]

On Monday, 25 October 2010 18:10:17 Chris Wopat wrote:
> Posting some inconsistencies I discovered today with Devmon templates,
> specificly the if_stat check with only appears in Cisco templates. I was
> troubleshooting why various routers I have showed if_stat down for
> various serial interfaces but nothing was alerted in xymon.
> 
> Eventually I noticed that it only is happening on 2811 and 3640 routers.
> I checked the templates and the file 'if_stat/exceptions' lists:
> 
> 	ifName : alarm  : Gi.+
> 
> Almost all other templates list this, or no alarm line:
> 
> 	ifName : alarm  : .+
> 
> This is a request to get consistency across the board and to set them
> all to alarm on everything per above. It's pretty funny that it's in the
> 3640 since it doesn't even support Gig interfaces that I'm aware of.
> Here's the templates with the issue:

I prefer not to "fix" templates that relate to devices I don't have access to, 
especially since I am not familiar with all the naming conventions for 
interfaces on Cisco equipment.

Please log a tracker item on the SF page. Feel free to attach a patch against 
current svn.

Please note the exceptions file in other if_* tests as well (e.g. if_load).

(Of course, this is largely off-topic for Xymon itself, it would be best not 
to cross-post, so I have removed the Xymon list).

Regards,
Buchan

[Devmon] Devmon if_stat alarm consistency

[Chris W. <ch...@su...>]

Posting some inconsistencies I discovered today with Devmon templates, 
specificly the if_stat check with only appears in Cisco templates. I was 
troubleshooting why various routers I have showed if_stat down for 
various serial interfaces but nothing was alerted in xymon.

Eventually I noticed that it only is happening on 2811 and 3640 routers. 
I checked the templates and the file 'if_stat/exceptions' lists:

	ifName : alarm  : Gi.+

Almost all other templates list this, or no alarm line:

	ifName : alarm  : .+

This is a request to get consistency across the board and to set them 
all to alarm on everything per above. It's pretty funny that it's in the 
3640 since it doesn't even support Gig interfaces that I'm aware of. 
Here's the templates with the issue:

	cisco-2811
	cisco-3640
	cisco-4500
	cisco-5500
	cisco-6506 (commented out, 6509 template not affected)
	cisco-msfc2

And a link to browse the file on the 3640 as an example:

http://devmon.svn.sourceforge.net/viewvc/devmon/trunk/templates/cisco-3640/if_stat/exceptions?revision=54&view=markup

Thanks!
Chris

Re: [Devmon] Checkpoint SPLAT template

[pkc_mls <pk...@ya...>]

  Le 10/12/2010 11:54 PM, Patrick Nixon a écrit :
> Hey all,
Hi Patrick,
>   I saw a reference back in 2008 for a template for CheckPoint SPLAT R65, but
> I don't see it in the templates directory.
There was a thread on the hobbit mailing list about checkpoint 
monitoring, but this was done
via a statically compiled linux RHEL3 client.
As the client works fine, I never tried to get the values via snmp;

There is a cacti template in which you should find the relevant OIDs for 
checkpoint metrics. (sessions,
packets accepted, dropped, etc).
>   Is there some place else I should be looking for it?
>
> Thanks!
> --patrick

[Devmon] Checkpoint SPLAT template

[Patrick N. <pn...@gm...>]

Hey all,
 I saw a reference back in 2008 for a template for CheckPoint SPLAT R65, but
I don't see it in the templates directory.

 Is there some place else I should be looking for it?

Thanks!
--patrick

Re: [Devmon] Unknown model in model

[Johan S. <joh...@de...>]

Check that you don't have any space " " at the end of the lines in the specs file. I had the same problem when I had a space at the end of the model line.

/Johan

> -----Original Message-----
> From: Tom Shimada [mailto:tom...@ga...]
> Sent: den 30 september 2010 11:29
> To: dev...@li...
> Subject: [Devmon] Unknown model in model
> 
> Hello,
> 
> I am trying to use xymon and devmon 0.3.1-beta1 to monitor my
> netscreen device.  it is a ssg520.
> 
> I didn't see any templates so i first wanted to test if the query would work
> so i created a new directory under the templates directory DIR: ssg-520
> in there i created the specs file.
> 
> vendor	: juniper
> model	: ssg520
> snmpver	: 2
> sysdesc : SSG-520 version 6.1.0r2.0 (SN: JN111463BADA, Firewall+VPN)
> 
> in my bb-hosts file i added:
> 
> <ssg ip address>   ssg520  # DEVMON:model(juniper;ssg520),cid(public)
> 
> however, when i run,
> 
> ./devmon --readbbhosts -vvv
> 
> i get the following error.
> 
> 	Unknown model in model() option for ssg520
> 
> Also, the sysdesc information is what i got from running the
> 
> [root@xymon01 devmon-0.3.1-beta1]# snmpwalk -v2c -c public <ssg ip>
> SNMPv2-MIB::sysDescr.0 = STRING: SSG-520 version 6.1.0r2.0 (SN:
> JN111463BADA, Firewall+VPN)
> 
> Could you tell me what might be wrong?
> 
> Thanks
> Tom
> 
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Devmon-support mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devmon-support

[Devmon] Unknown model in model

[Tom S. <tom...@ga...>]

Hello,

I am trying to use xymon and devmon 0.3.1-beta1 to monitor my 
netscreen device.  it is a ssg520.

I didn't see any templates so i first wanted to test if the query would work
so i created a new directory under the templates directory DIR: ssg-520
in there i created the specs file.

vendor	: juniper
model	: ssg520
snmpver	: 2
sysdesc : SSG-520 version 6.1.0r2.0 (SN: JN111463BADA, Firewall+VPN) 

in my bb-hosts file i added:

<ssg ip address>   ssg520  # DEVMON:model(juniper;ssg520),cid(public)

however, when i run,

./devmon --readbbhosts -vvv

i get the following error.

	Unknown model in model() option for ssg520

Also, the sysdesc information is what i got from running the 

[root@xymon01 devmon-0.3.1-beta1]# snmpwalk -v2c -c public <ssg ip>
SNMPv2-MIB::sysDescr.0 = STRING: SSG-520 version 6.1.0r2.0 (SN: JN111463BADA, Firewall+VPN)

Could you tell me what might be wrong?

Thanks
Tom

[Devmon] Loris Serena is out of the office.

[<lor...@bn...>]

I will be out of the office starting  24/09/2010 and will not return until
04/10/2010.

Please contact its...@pn... with any queries.

The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not an intended party to this communication, please notify the sender and delete/destroy any and all copies of this communication.  

Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.  There are some inherent risks with exchanging e-mails. You understand and agree that we are not, and will not be, responsible for the unauthorized access, interception, or redirection of e-mails including any attachments, nor will we be responsible for the effect on any computer system of any e-mails or attachments.  You also agree that we will not be responsible for the incorrect or incomplete transmission of information by e-mail

The information contained in this communication is not intended or construed as an offer, solicitation, or a recommendation to purchase any security.

Opinions, suggestions or views presented in this communication are not necessarily those of The Bank of New York Mellon Corporation or any of its affiliates. 

Please refer to http://disclaimer.bnymellon.com/eu.htm for disclosures relating to European legal entities

Re: [Devmon] Devmon V3

[Mario A. P. <row...@gm...>]

Hi Buchan, thanks for your answers!

I will wait your comments...

I've answered to a post that you replied at the xymon list and I think you
don't  saw it.

The post was about a possible fix to a problem that I'm facing here.

Can you help me with this?

Hi Buchan,

I'm running 4.3.0 but I think my revision is different because I could not
patch do_devmon.c , I've searched the trunk and branch files but I haven't
found the revision 6330 described into the patch file
--- hobbitd/rrd/do_devmon.c     (revision 6330).
Can you help?


Thanks in advance,

Mario.

On Tuesday, 17 August 2010 14:24:15 Geoff Hallford wrote:
> Hi All,
>
> Hopefully someone can help with this issue. hobbitd_rrd keeps crashing and
> popping up as red on my xymon installation. I am running 4.3.0-0 beta 2.
> Here is the dump of the core file:


It looks like the attached patch fixes this. Can you test it and confirm?
- Show quoted text -


> xymon@xymon:~/server> gdb bin/hobbitd_rrd tmp/core
> GNU gdb (GDB) SUSE (7.1-3.12)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html


>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i586-suse-linux".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/

>...
> Reading symbols from /home/xymon/server/bin/hobbitd_rrd...done.
> [New Thread 8252]
> Core was generated by `hobbitd_rrd --rrddir=/home/xymon/data/rrd'.
> Program terminated with signal 6, Aborted.
> #0  0xffffe424 in __kernel_vsyscall ()
>
> (gdb) bt
> #0  0xffffe424 in __kernel_vsyscall ()
> #1  0xb75937ff in raise () from /lib/libc.so.6
> #2  0xb7595140 in abort () from /lib/libc.so.6
> #3  0x080666d3 in sigsegv_handler (signum=11) at sig.c:57
> #4  <signal handler called>
> #5  0xb75de4a3 in strlen () from /lib/libc.so.6
> #6  0xb75de1a6 in strdup () from /lib/libc.so.6
> #7  0xb777ed16 in rrd_update () from /usr/lib/librrd.so.4
> #8  0x0804c217 in flush_cached_updates (cacheitem=0x80d4030,
newdata=<value
> optimized out>) at do_rrd.c:225
> #9  0x0804d2dc in create_and_update_rrd (hostname=<value optimized out>,
> testname=0xb6e17a8a "if_load", classname=<value optimized out>,
> pagepaths=0x806d031 "", creparams=0xbfc280a4,
>     template=0x80d4970) at do_rrd.c:404
> #10 0x08057a26 in do_devmon_rrd (hostname=0xb6e17a7d "VPN04.uhn.ca<http://vpn04.uhn.ca/>

",
> testname=0xb6e17a8a "if_load", classname=0xb6e17abe "uhn/uhnnetwork",
> pagepaths=0x806d031 "", msg=
>     0xb6e17acd "status VPN04,uhn,ca.if_load green Tue Aug 17 08:55:18
> 2010", tstamp=1282049718) at rrd/do_devmon.c:111
> #11 0x08058bf6 in update_rrd (hostname=0xb6e17a7d "VPN04.uhn.ca<http://vpn04.uhn.ca/>

",
> testname=0xb6e17a8a "if_load", msg=0xb6e17acd "status VPN04,uhn,ca.if_load
> green Tue Aug 17 08:55:18 2010", tstamp=
>     1282049718, sender=0xb6e17a72 "127.0.0.1", ldef=0x809e490,
> classname=0xb6e17abe "uhn/uhnnetwork", pagepaths=0x806d031 "") at
> do_rrd.c:660
> #12 0x0804a906 in main (argc=2, argv=0xbfc2b444) at hobbitd_rrd.c:366

Regards,
Buchan

Re: [Devmon] Devmon V3

[Buchan M. <bg...@st...>]

On Tuesday, 21 September 2010 16:42:32 Mario Andre Panza wrote:
> Hi Buchan,
> 
> How are you?

Unfortunately, quite busy at present.

> The V3 support is running good on my systems , I would like to share the
> code with the community, Did you have time to test?

I have had a look at the changes, and there are some things which should be 
improved, I will send some comments by (hopefully) the end of the week.

Regards,
Buchan

Re: [Devmon] Devmon V3

[Mario A. P. <row...@gm...>]

Hi Buchan,

How are you?

The V3 support is running good on my systems , I would like to share the
code with the community, Did you have time to test?


Regards,

Mario.

On Thu, Sep 9, 2010 at 2:57 PM, Mario Andre Panza <row...@gm...>wrote:

>
> Hi Buchan,
>
> Did you have time to test or to see the code?
>
>
> Regards,
>
> Mario.
>
>
>
>
>
>
> On Fri, Aug 27, 2010 at 11:09 AM, Mario Andre Panza <
> row...@gm...> wrote:
>
>> Hi Buchan,
>>
>> How are you?
>>
>> The passed weeks I have too much work and could not send to you my first
>> version. It's running good on my VM machine.
>>
>> This 1st version uses only the v3 authentication and I'm working now for
>> the encryption parameters on the next version.
>>
>>
>> I'm sending to you the trunk version I've used and the modified version.
>> Please take a look.
>>
>> I've modified dm_config.pm , dm_snmp.pm and dm_templates.pm.
>>
>> devmon, version 0.3.1-beta1
>>
>> Node name:        kunis
>> Node number:      0
>> Process ID:       2786
>>
>> Cycle time:       300
>> Dead time:        180
>>
>> Polled devices:   3
>> Polled tests:     3
>>
>>
>>
>> Avg tests/node:   n/a
>> # clear msgs:     0
>>
>> SNMP test time:   2
>> Test logic time:  0
>> BB msg xfer time: 0
>> This poll period: 2
>>
>> Avg poll time:    3.2 seconds
>>
>> Poll time averaged over 5 poll cycles.
>>
>>
>>
>> Fork summary
>>   Number PID        Last checked in Polled          Current Activity
>>        1   11818             2s ago      1                      idle
>>        2   11819             2s ago      1                      idle
>>
>>
>>
>>        3   11820             2s ago      1                      idle
>>        4   21200             1s ago                             idle
>>        5   21201             1s ago                             idle
>>        6   21202             1s ago                             idle
>>
>>
>>
>>        7   21203             1s ago                             idle
>>        8   21204             1s ago                             idle
>>        9   21205             1s ago                             idle
>>       10   21206             1s ago                             idle
>>
>>
>>
>> bb-hosts configuration:
>>
>> 1 #
>>   2 # Master configuration file for Xymon
>>   3 #
>>   4 # This file defines several things:
>>   5 #
>>   6 # 1) By adding hosts to this file, you define hosts that are monitored
>> by Xymon
>>   7 # 2) By adding "page", "subpage", "group" definitions, you define the
>> layout
>>   8 #    of the Xymon webpages, and how hosts are divided among the
>> various webpages
>>   9 #    that Xymon generates.
>>  10 # 3) Several other definitions can be done for each host, see the
>> bb-hosts(5)
>>  11 #    man-page.
>>  12 #
>>  13 # You need to define at least the Xymon server itself here.
>>  14 title Monitor Template
>>  15 group <h3>Argus Server</h3>
>>  16 10.20.1.30   kunis      # DESCR:Server:SYS BBPAGER BBNET BBDISPLAY bbd
>> ssh ~http://10.20.1.30/ testip dig
>>  22 10.20.6.102 router-teste # testip DEVMON:snmpv3(Mario;MD5;Panza123)
>>
>>
>> Regards,
>>
>> Mario Panza.
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Buchan Milne <bg...@st...>
>> Date: Mon, Jul 26, 2010 at 6:50 AM
>> Subject: Re: Help with devmon develop
>> To: Mario Andre Panza <row...@gm...>
>> Cc: dev...@li...
>>
>>
>> On Thursday, 22 July 2010 19:20:04 Mario Andre Panza wrote:
>> > Hi Buchan,
>> >
>> > How are you?
>> >
>> > I Hope that everything is doing good for you right now.
>> > I have good news of the v3 devmon support version.
>> > I've decided to use Net_SNMP_util.pm utility and after some hard work,
>> >  first to discover how the things works and then how  SNMP_session works
>> >  and how they are parsed.
>>
>> Great! It would be nice to see a patch/svn diff if you have one available.
>>
>> > In my first release, I'm using only 3 parameters from v3 (
>> >  username,password and protocol) and the others can be added with easy
>> >  changes.
>>
>> I think for now that should be sufficient for the users with urgent SNMPv3
>> requirements, but other methods (e.g. SSL certificates) would be useful
>> later.
>>
>> > I will clean some code and send to you so you can make tests too.
>>
>> Cool.
>>
>> > In Net_SNMP_util.pm the sysUptime is not parsed in seconds, the result
>> is
>> > already parsed in days HH:MM:SS format. So for example the cpu
>> monitoring
>> > 'sysuptime' don't work as the previous version.
>> >
>> > Do you think that already exist a way in devmon to transform it or we
>> have
>> > to develop?
>>
>> I'll have a look as soon as you send me a patch, but ideally we would want
>> to
>> be able to access both transformed and non-transformed values. Otherwise,
>> we
>> will have to consider adding template versioning and have devmon check
>> that
>> the templates are up-to-date ...
>>
>> > I'm asking this because I would like to maintain my cpu uptime
>> > monitoring and the new version needs to be compatible with the old one
>> > templates, right?
>>
>> We will definitely want to ensure that all values used in thresholds or
>> RRDs
>> are maintained or migrated.
>>
>> Regards,
>> Buchan
>>
>>
>
>

Re: [Devmon] Fortigate templates

[Stephan B. <Ste...@MX...>]

Thanks for the reply, but have tried that. And tried it again now, makes
no difference.


-----Original Message-----
From: Glenn Attwood <at...@ut...>
To: dev...@li...
<dev...@li...>
Cc: Stephan Buys <Ste...@mx...>
Subject: Re: [Devmon] Fortigate templates
Date: Fri, 10 Sep 2010 17:34:45 +0200


Probably a dumb question, but what if you use

/oids
fgFwPolID :	 .1.3.6.1.4.1.12356.101.5.1.2.1.1.1.1 : branch
fgPolPktCount :  .1.3.6.1.4.1.12356.101.5.1.2.1.1.2.1 : branch
fgPolByteCount : .1.3.6.1.4.1.12356.101.5.1.2.1.1.3.1 : branch

i.e., specify the OID up to the bit that is actually changing

Glenn Attwood
Senior Network Administrator, IITS
University of Toronto Scarborough
416-287-7364

On 09/10/2010 04:51 AM, Stephan Buys wrote:
> Hi all,
>
> Busy developing Fortigate Firewall templates, going strong just have the
> following problem:
>
> /oids
> fgFwPolID :	 .1.3.6.1.4.1.12356.101.5.1.2.1.1.1 : branch
> fgPolPktCount :  .1.3.6.1.4.1.12356.101.5.1.2.1.1.2 : branch
> fgPolByteCount : .1.3.6.1.4.1.12356.101.5.1.2.1.1.3 : branch
>
> /message
> TABLE:
> Policy ID|Packet Count|Byte Count
> {fgFwPolID}|{fgPolPktCount}|{fgPolByteCount}
>
> Result
>
> "2010-09-10 10:46:03 +0200"
>
>
> Alarming on (2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2)
>         Policy ID
>        Packet Count
>         Byte Count
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
>
>
> Supposed to be: (snmpwalk from same machine)
>
> /Policy ID
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.2 = INTEGER: 2
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.5 = INTEGER: 5
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.6 = INTEGER: 6
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.7 = INTEGER: 7
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.9 = INTEGER: 9
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.12 = INTEGER: 12
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.13 = INTEGER: 13
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.14 = INTEGER: 14
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.16 = INTEGER: 16
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.17 = INTEGER: 17
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.18 = INTEGER: 18
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.19 = INTEGER: 19
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.20 = INTEGER: 20
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.22 = INTEGER: 22
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.24 = INTEGER: 24
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.25 = INTEGER: 25
>
> /Packet Count
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.2 = Counter32: 124122669
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.5 = Counter32: 54549534
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.6 = Counter32: 24132724
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.7 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.9 = Counter32: 1846132
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.12 = Counter32: 4567489
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.13 = Counter32: 11629696
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.14 = Counter32: 676
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.16 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.17 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.18 = Counter32: 1925703
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.19 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.20 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.22 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.24 = Counter32: 28345
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.25 = Counter32: 2089661
>
> /Byte Count
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.2 = Counter32: 579080034
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.5 = Counter32: 288458478
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.6 = Counter32: 2808814712
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.7 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.9 = Counter32: 1358060886
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.12 = Counter32: 1560932375
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.13 = Counter32: 3957765703
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.14 = Counter32: 90521
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.16 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.17 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.18 = Counter32: 256112795
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.19 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.20 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.22 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.24 = Counter32: 7926273
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.25 = Counter32: 767754201
>
>
> Any help would be appreciated!!
>
>
> Thanks
>
>
> Stephan Buys
>
>
> This email is subject to the MXit email disclaimer, which is available at http://www.mxit.com/email.pdf
> If you cannot access the disclaimer, please get a copy from us by sending an email to: su...@mx...
> ------------------------------------------------------------------------------
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
> _______________________________________________
> Devmon-support mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devmon-support


Stephan Buys


This email is subject to the MXit email disclaimer, which is available at http://www.mxit.com/email.pdf   
If you cannot access the disclaimer, please get a copy from us by sending an email to: su...@mx...

Re: [Devmon] Fortigate templates

[Glenn A. <at...@ut...>]

Probably a dumb question, but what if you use

/oids
fgFwPolID :	 .1.3.6.1.4.1.12356.101.5.1.2.1.1.1.1 : branch
fgPolPktCount :  .1.3.6.1.4.1.12356.101.5.1.2.1.1.2.1 : branch
fgPolByteCount : .1.3.6.1.4.1.12356.101.5.1.2.1.1.3.1 : branch

i.e., specify the OID up to the bit that is actually changing

Glenn Attwood
Senior Network Administrator, IITS
University of Toronto Scarborough
416-287-7364

On 09/10/2010 04:51 AM, Stephan Buys wrote:
> Hi all,
>
> Busy developing Fortigate Firewall templates, going strong just have the
> following problem:
>
> /oids
> fgFwPolID :	 .1.3.6.1.4.1.12356.101.5.1.2.1.1.1 : branch
> fgPolPktCount :  .1.3.6.1.4.1.12356.101.5.1.2.1.1.2 : branch
> fgPolByteCount : .1.3.6.1.4.1.12356.101.5.1.2.1.1.3 : branch
>
> /message
> TABLE:
> Policy ID|Packet Count|Byte Count
> {fgFwPolID}|{fgPolPktCount}|{fgPolByteCount}
>
> Result
>
> "2010-09-10 10:46:03 +0200"
>
>
> Alarming on (2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2)
>         Policy ID
>        Packet Count
>         Byte Count
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
> 2
> 124118298
> 577806539
>
>
> Supposed to be: (snmpwalk from same machine)
>
> /Policy ID
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.2 = INTEGER: 2
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.5 = INTEGER: 5
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.6 = INTEGER: 6
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.7 = INTEGER: 7
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.9 = INTEGER: 9
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.12 = INTEGER: 12
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.13 = INTEGER: 13
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.14 = INTEGER: 14
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.16 = INTEGER: 16
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.17 = INTEGER: 17
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.18 = INTEGER: 18
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.19 = INTEGER: 19
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.20 = INTEGER: 20
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.22 = INTEGER: 22
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.24 = INTEGER: 24
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.1.1.25 = INTEGER: 25
>
> /Packet Count
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.2 = Counter32: 124122669
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.5 = Counter32: 54549534
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.6 = Counter32: 24132724
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.7 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.9 = Counter32: 1846132
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.12 = Counter32: 4567489
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.13 = Counter32: 11629696
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.14 = Counter32: 676
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.16 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.17 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.18 = Counter32: 1925703
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.19 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.20 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.22 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.24 = Counter32: 28345
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.2.1.25 = Counter32: 2089661
>
> /Byte Count
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.2 = Counter32: 579080034
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.5 = Counter32: 288458478
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.6 = Counter32: 2808814712
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.7 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.9 = Counter32: 1358060886
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.12 = Counter32: 1560932375
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.13 = Counter32: 3957765703
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.14 = Counter32: 90521
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.16 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.17 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.18 = Counter32: 256112795
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.19 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.20 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.22 = Counter32: 0
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.24 = Counter32: 7926273
> SNMPv2-SMI::enterprises.12356.101.5.1.2.1.1.3.1.25 = Counter32: 767754201
>
>
> Any help would be appreciated!!
>
>
> Thanks
>
>
> Stephan Buys
>
>
> This email is subject to the MXit email disclaimer, which is available at http://www.mxit.com/email.pdf
> If you cannot access the disclaimer, please get a copy from us by sending an email to: su...@mx...
> ------------------------------------------------------------------------------
> Automate Storage Tiering Simply
> Optimize IT performance and efficiency through flexible, powerful,
> automated storage tiering capabilities. View this brief to learn how
> you can reduce costs and improve performance.
> http://p.sf.net/sfu/dell-sfdev2dev
> _______________________________________________
> Devmon-support mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devmon-support