xymon-snmpcollect - state ? xymond_channel worker needed for trending ? 🔗 link

Sorry for the replying to an old message, but seems there hasn't been any recent discussion of snmp polling. 

I believe I have everything working perfectly with 4.3.18, I see clientdata coming in on my test switch and I am collecting data on the [ifmib] definition in "server/etc/snmpmibs.cfg". What I don't have is trending on that data. I am assuming that is because the data is coming in under to xymon via "client" message versus a "data" message.

To get trends, I assume I could write a xymond_channel worker listening on the client channel and using a filter option to target only "snmpcollect" messages. This would process the raw data, and submit the data I want to trend on via "data" messages ?

Or am I just to bogged in the details and missing something obvious ? Thanks,
 -Steve

-----Original Message-----
To: user-ae9b8668bcde@xymon.invalid
*Subject: Re: [hobbit] snmp
*From: Henrik Stoerner <user-ce4a2c883f75@xymon.invalid>
*Date: Fri, 7 Mar 2008 07:34:31 +0100
*References: <001001c88014$695664f0$user-a73ca09b698f@xymon.invalid>
*User-agent: Mutt/1.5.15+20070412 (2007-04-11)
  
  On Fri, Mar 07, 2008 at 06:30:53AM +0100, Lars Ebeling wrote:

I would like to have an examle of the snmp configuration file: 
hobbit-snmphosts.cfg-- 

Here's one:

[osiris.hswn.dk]
	version=2c
	community=public
	ip=172.16.10.100
	ifmib={172.16.10.100}
#	ifmib={*}
	hrsystem
	hrstorage=(Real Memory)
	hrstorage=(Swap Space)
	hrstorage=(/)
	hrstorage=(/work)
	hrtask=<*>

To understand how it works, you need to look at the hobbit-snmpmibs.cfg
file also. In this file you'll find an [ifmib] section that begins with

[ifmib]
	keyidx (IF-MIB::ifDescr)
	keyidx [IF-MIB::ifPhysAddress]
	keyidx <IF-MIB::ifName>
	validx {IP-MIB::ipAdEntIfIndex}
	ifDescr = IF-MIB::ifDescr

Note the different kind of parentheses / brackets ? What these do is
they act like an index into the list of network interfaces. So the line
"ifmib={172.16.10.100}" means "grab the ifmib data for the network
interface whose {IP-MIB::ipAdEntIfIndex} (IP-address) is 172.16.10.100.

If you wanted the statistics from the "eth0" net-interface, you would
use "ifmib=(eth0)".

The line that just read "hrsystem" has no index, because this data
- part of the Host Ressources MIB - only has one entry globally (e.g.
there is only one count of how many users are logged on).

The "hrtask=<*>" of course means to fetch information about all of the
tasks running on the system.


Regards,
Henrik

On 16 April 2015 at 06:16, Steve <user-5f4af886b3dc@xymon.invalid> wrote:

I'm glad to see there's interest in trying this out.  I've been
disheartened after previous comments by Henrik, but totally understand that
there are higher priorities like IPv6.

I believe I have everything working perfectly with 4.3.18, I see clientdata

Good news.  This is encouraging.

Would you mind showing a sample of the relevant client data you're
receiving?

Yep, it's the same collection/processing mechanism as per host client
messages.  In such cases, xymond_client will parse the client data and
generate both status and data messages based on what it finds.

This shouldn't be necessary.  There's a client definition for "snmpcollect"
messages, so the existing xymond_client process should create data and
status messages.

Or am I just to bogged in the details and missing something obvious ?

The code in xymond/client/snmpcollect.c doesn't generate any "data"
messages, only "status" messages.  So don't expect anything on the trends
page.

Instead, status messages should appear, which should create their own
columns.  The column name will be the "mibname" which I'm guessing is the
[sectionname] in snmpmibs.cfg.

There's code in the RRD processing (xymond/do_rrd.c) that looks for MIB
data being passed from calling functions, but there doesn't seem to be any
glue between snmpcollect.c and this code.  Or could be that I just haven't
found it yet.

J

Sorry for the formatting..  trying to figure out how to set my mail client to reply/quote in a manner that makes sense.

Sure, happy to share, but it is lengthy so I will only share two ports. Also, I changed it a bit to go by port# versus portDescription.

[ifmib]
Interval=60
ActiveIP=192.168.11.121
<2>
	ifDescr = port 2: Gigabit Copper
	ifType = ethernetCsmacd
	ifMtu = 1500
	ifSpeed = 0
	ifPhysAddress = c0:4a:0:be:4d:a9
	ifAdminStatus = up
	ifOperStatus = down
	ifLastChange = 0:0:00:00.00
	ifInOctets = 0
	ifInUcastPkts = 0
	ifInNUcastPkts = 0
	ifInDiscards = 0
	ifInErrors = 0
	ifInUnknownProtos = 0
	ifOutOctets = 0
	ifOutUcastPkts = 0
	ifOutNUcastPkts = 0
	ifOutDiscards = 0
	ifOutErrors = 0
	ifOutQLen = 0
	ifName = port 2: Gigabit Copper
	ifInMulticastPkts = 0
	ifInBroadcastPkts = 0
	ifOutMulticastPkts = 0
	ifOutBroadcastPkts = 0
	ifHCInOctets = 0
	ifHCInUcastPkts = 0
	ifHCInMulticastPkts = 0
	ifHCInBroadcastPkts = 0
	ifHCOutOctets = 0
	ifHCOutUcastPkts = 0
	ifHCOutMulticastPkts = 0
	ifHCOutBroadcastPkts = 0
	ifLinkUpDownTrapEnable = enabled
	ifHighSpeed = 0
	ifPromiscuousMode = false
	ifConnectorPresent = true
	ifAlias = norm
	ifCounterDiscontinuityTime = 0:0:00:00.00
<1>
	ifDescr = port 1: Gigabit Copper
	ifType = ethernetCsmacd
	ifMtu = 1500
	ifSpeed = 0
	ifPhysAddress = c0:4a:0:be:4d:a9
	ifAdminStatus = up
	ifOperStatus = down
	ifLastChange = 0:0:00:00.00
	ifInOctets = 0
	ifInUcastPkts = 0
	ifInNUcastPkts = 0
	ifInDiscards = 0
	ifInErrors = 0
	ifInUnknownProtos = 0
	ifOutOctets = 0
	ifOutUcastPkts = 0
	ifOutNUcastPkts = 0
	ifOutDiscards = 0
	ifOutErrors = 0
	ifOutQLen = 0
	ifName = port 1: Gigabit Copper
	ifInMulticastPkts = 0
	ifInBroadcastPkts = 0
	ifOutMulticastPkts = 0
	ifOutBroadcastPkts = 0
	ifHCInOctets = 0
	ifHCInUcastPkts = 0
	ifHCInMulticastPkts = 0
	ifHCInBroadcastPkts = 0
	ifHCOutOctets = 0
	ifHCOutUcastPkts = 0
	ifHCOutMulticastPkts = 0
	ifHCOutBroadcastPkts = 0
	ifLinkUpDownTrapEnable = enabled
	ifHighSpeed = 0
	ifPromiscuousMode = false
	ifConnectorPresent = true
	ifAlias = AccessPoint
	ifCounterDiscontinuityTime = 0:0:00:00.00

Hmm I will have to look at the code more to try to figure things out a bit better too

Now that does not happen. Someone else report similar back on Mar 26th 2008; http://lists.xymon.com/archive/2008-March/018374.html

But on Sep 10th 2007, Henrik responded in the email @ http://lists.xymon.com/oldarchive/2007/09/msg00139.html
"Right now it just collects the data. I have some ideas to add monitoring
so it might trigger an alert if the error-rate of an interface goes up,
or the traffic exceeds certain limits (min/max). Nothing definite yet."

So I had just assumed that xymon's snmp capabilities were only to collect & post "client data" and that nothing was enabled/working for taking that and posting "status" or "data" messages and thusly no trends

-Steve