xymon-snmpcollect - state ? xymond_channel worker needed for trending ?
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: hobbit (at) hswn.dk *Subject: Re: [hobbit] snmp *From: Henrik Stoerner <henrik (at) hswn.dk> *Date: Fri, 7 Mar 2008 07:34:31 +0100 *References: <001001c88014$695664f0$0500a8c0 (at) noip.org> *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 <steve at nerdynomads.net> wrote:
Sorry for the replying to an old message, but seems there hasn't been any recent discussion of snmp polling.
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
coming in on my test switch and I am collecting data on the [ifmib] definition in "server/etc/snmpmibs.cfg".
Good news. This is encouraging.
Would you mind showing a sample of the relevant client data you're receiving?
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.
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.
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 ?
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 ?
Thanks,
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.
On Apr 16th 2016, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote: -----Original Message----- Good news. This is encouraging. Would you mind showing a sample of the relevant client data you're receiving?
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
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.
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.
Hmm I will have to look at the code more to try to figure things out a bit better too
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.
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
participants (2)
-
jlaidman＠rebel-it.com.au
-
steve＠nerdynomads.net