Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: snmpd.conf configuration issue

103 views
Skip to first unread message

Dave Shield

unread,
Mar 18, 2010, 12:55:29 PM3/18/10
to
On 18 March 2010 16:02, Martz, Peter <Peter...@cable.comcast.com> wrote:
> monitor -r 60 -o hrSWRunName "pjm: high cpu is WAY too high" hrSWRunPerfCPU > 1

OK - That makes sense.
"Send a trap if the CPU usage of a process is too high,
and include the name of the offending process.
Repeat this check every 60 s"

> monitor -r 60 -o hrSWRunName "pjm: memorysize" hrMemorySize > 100

That doesn't.
"Send a trap if the amount of installed memory is > 100Kb
and include the name of the offending process. (???)
Repeat this check every 60s (????)"

How often are you installing new memory in your kit?!


> monitor -r 60 -o hrSWRunName "pjm: high process memory"
> 1.3.6.1.2.1.25.5.1.1.2 > 10

That makes sense again
"Send a trap if the memory usage of a process is too high,
and include the name of the offending process.
Repeat this check every 60 s"

> ## This monitor trap gives me an error:  failed to run mteTrigger query
>
> monitor -r 60 -o hrSWRunName "Martz: CheckPoint CPU"
> 1.3.6.1.4.1.2620.1.6.7.2.4 > 1
>
> monitor -r 60 -o hrSWRunName "Martz: CheckPoint Connections"
> 1.3.6.1.4.1.2620.1.1.25.3  > 1

Again, these two probably don't make sense, unless the (private) MIB
objects you are querying use the same indexing as the hrSWRunTable.
In general, the additional payload objects you specify in a monitor
line should typically belong to the same table as the object being
monitored, since the agent will append the relevant index subidentifier.


It's also worth checking whether this agent actually implements these
two MIB objects. What happens if you run "snmpgetnext" on these
two OIDs?

Dave

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-users mailing list
Net-snm...@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Martz, Peter

unread,
Mar 18, 2010, 2:33:36 PM3/18/10
to
> -----Original Message-----
> From: dave....@googlemail.com [mailto:dave....@googlemail.com] On
> Behalf Of Dave Shield
> Sent: Thursday, March 18, 2010 12:55 PM
> To: Martz, Peter
> Cc: net-snm...@lists.sourceforge.net
> Subject: Re: snmpd.conf configuration issue
>
> On 18 March 2010 16:02, Martz, Peter <Peter...@cable.comcast.com> wrote:
> > monitor -r 60 -o hrSWRunName "pjm: high cpu is WAY too high"
> hrSWRunPerfCPU > 1
>
> OK - That makes sense.
> "Send a trap if the CPU usage of a process is too high,
> and include the name of the offending process.
> Repeat this check every 60 s"
>
>
>
> > monitor -r 60 -o hrSWRunName "pjm: memorysize" hrMemorySize > 100
>
> That doesn't.
> "Send a trap if the amount of installed memory is > 100Kb
> and include the name of the offending process. (???)
> Repeat this check every 60s (????)"
>
> How often are you installing new memory in your kit?!

Fair enough, I was using the wrong token.
I meant to use this (and the other 2 working monitor lines) only as an example of what formats were working.

>
> > monitor -r 60 -o hrSWRunName "pjm: high process memory"
> > 1.3.6.1.2.1.25.5.1.1.2 > 10
>
> That makes sense again
> "Send a trap if the memory usage of a process is too high,
> and include the name of the offending process.
> Repeat this check every 60 s"
>
>
>
> > ## This monitor trap gives me an error:  failed to run mteTrigger query
> >
> > monitor -r 60 -o hrSWRunName "Martz: CheckPoint CPU"
> > 1.3.6.1.4.1.2620.1.6.7.2.4 > 1
> >
> > monitor -r 60 -o hrSWRunName "Martz: CheckPoint Connections"
> > 1.3.6.1.4.1.2620.1.1.25.3  > 1
>
> Again, these two probably don't make sense, unless the (private) MIB
> objects you are querying use the same indexing as the hrSWRunTable.
> In general, the additional payload objects you specify in a monitor
> line should typically belong to the same table as the object being
> monitored, since the agent will append the relevant index subidentifier.
>

OK.
Based on that, could this be why I am getting the trigger error?:
disman:event:trigger:monitor: Trigger query (walk) failed: -2

I am not sure I fully understand which additional OIDs I can supply with an alert (not a smart man jenny).
How can I add "custom" information to the traps, once I get them working?

> It's also worth checking whether this agent actually implements these
> two MIB objects. What happens if you run "snmpgetnext" on these
> two OIDs?
>

Running snmpgetnext on 1.3.6.1.4.1.2620.1.1.25.3 gives the following:

/usr/local/bin/snmpgetnext -Of -On -v 2c -c <community> <ip> 1.3.6.1.4.1.2620.1.1.25.3
.1.3.6.1.4.1.2620.1.1.25.3.0 = INTEGER: 19

Dave Shield

unread,
Mar 18, 2010, 5:51:18 PM3/18/10
to
On 18 March 2010 18:33, Martz, Peter <Peter...@cable.comcast.com> wrote:
> Running snmpgetnext on 1.3.6.1.4.1.2620.1.1.25.3 gives the following:
>
> /usr/local/bin/snmpgetnext -Of -On -v 2c -c <community> <ip> 1.3.6.1.4.1.2620.1.1.25.3
> .1.3.6.1.4.1.2620.1.1.25.3.0 = INTEGER: 19

Is this a scalar object?
If so, it's probably safer to specify the full OID (including the
trailing .0 instance)
and add "-I" to the monitor line to indicate that this monitoring an instance
rather than (all instances of) an object.

Dave

Martz, Peter

unread,
Mar 19, 2010, 11:06:13 AM3/19/10
to
I have modified the configuration file to remove the -o option (as it
didn't make sense per you suggestion).

So to monitor the CheckPoint OIDs, I have the following 3 lines in my
snmpd.conf file (which should all be the same thing):

monitor -I -r 60 1.3.6.1.4.1.2620.1.1.25.3 > 1
monitor -I -r 60 1.3.6.1.4.1.2620.1.1.25.3.0 > 1
monitor -I -r 60 fwNumConn > 1

All 3 lines generate:
/etc/snmp/snmpd.conf: line <X>: Error: unknown monitor OID

I have added the CheckPoint MIB file into the /usr/share/snmp/mibs
directory (default location and where all the standard MIB files live),
so the fwNumConn token should be known at this point. Removing the "-I"
doesn't change anything.

Could I have permissions incorrect for the user?

In the snmpd.conf file:
createUser <username> MD5 <passwd> DES
User shows up with snmp user show, but show user snmp <username> gives:
<username>: User Access Information not Found

Running: NET-SNMP version 5.3.1, not sure if it is on any patch level
(how would I determine?).

> -----Original Message-----
> From: dave....@googlemail.com [mailto:dave....@googlemail.com]
On
> Behalf Of Dave Shield
> Sent: Thursday, March 18, 2010 5:51 PM
> To: Martz, Peter
> Cc: net-snm...@lists.sourceforge.net
> Subject: Re: snmpd.conf configuration issue
>

Dave Shield

unread,
Mar 19, 2010, 2:22:35 PM3/19/10
to
On 19 March 2010 15:06, Martz, Peter <Peter...@cable.comcast.com> wrote:
> So to monitor the CheckPoint OIDs, I have the following 3 lines in my
> snmpd.conf file (which should all be the same thing):
>
> monitor -I -r 60 1.3.6.1.4.1.2620.1.1.25.3    > 1
> monitor -I -r 60 1.3.6.1.4.1.2620.1.1.25.3.0  > 1
> monitor -I -r 60 fwNumConn > 1

You're missing the name for these monitor entries.
(Which is used as an index for the table)

Try
monitor -I -r 60 test1 1.3.6.1.4.1.2620.1.1.25.3 > 1
monitor -I -r 60 test2 1.3.6.1.4.1.2620.1.1.25.3.0 > 1
monitor -I -r 60 test3 fwNumConn > 1


> I have added the CheckPoint MIB file into the /usr/share/snmp/mibs
> directory (default location and where all the standard MIB files live)

Have you added this MIB to the list of modules to load?
(See the FAQ entry "How do I add a MIB to the clients?")

0 new messages