On Mon, Jan 23, 2006 at 12:28:36PM -0500, Ben Lentz wrote: > Interface Types: > Dell OpenManage Chassis Interface simple > .1.3.6.1.4.1.674.10892.1.200.1 Dell OpenManage Chassis Group > The 'simple' discovery function does exactly what I want: Who knew? Are > there different OIDs for discovery and for defining the Interface? The simple discovery plug-in requires two parameters. The first is the OID to test and the second is the interface name. Change your parameter to .1.3.6.1.4.1.674.10892.1.200.1,manage
> > Interface Types Fields: > Dell OpenManage Chassis Field dell_om_chassis_field 10 > Dell OpenManage Chassis Interface Other Never > I don't understand the purpose of these fields, especially when I only > want to query a single OID... but if this is empty than the Interface > never gets added. I think you may need a description field. > Poller Grouping View: > 10 Dell OpenManage Chassis Poller Temporal Buffer > 20 Dell OpenManage Chassis Poller Dell OpenManage Chassis Backend > 30 Dell OpenManage Chassis Poller Alarm Verify Operational > Following the example in the Expanding doc... these seem required to get > the status into an event and later a trigger, but the Alarm Verify > Operational and Admin Status View Change items seem to complain about an > "Unknown Object Identifier", so I created the Backend object as well... This looks wrong. What we want to do here is to poll this OID and pump its output into an alarm backend. I would recommend that you have your own specific event type, so Create an event, note the ID for it. Create a new backend. Poller Command is alarm and the Parameter is the ID you got for your new event. In Poller grouping you need one line. The poller item is your Chassis Poller and your backend is your newly created Backend. So what happens: The Poller polls the OID, it compares the return result with your bunch of parameters, if there is a match it returns whatever is to the right of the =, otherwise it returns "down". This result from the poller is sent to the backend. The string should match one of the ones found in the Alarm States table (Admin -> Event Analyyzer -> Alarm States & Sounds , first column) The backend will create events, when the state changes. > 1.3.6.1.4.1.674.10892.1.200.10.1.2.1,1=other|2=unknown|3=ok|4=noncritical|5=critical|6=nonrecoverable Each thing after the = should be in the State table, otherwise JFFNMS won't know the significance of the message. > snmp_status:dell_om_chassis(1.3...abl): ok -> buffer(): 1 (time P:34.03 You never look in the buffer so there is no point putting it here. > 12:17:34 : H 127 : I 388 : P 20 : dell_om_chassis(1.3...abl): ok -> > db(show_rootmap,down=2|up=3,0): -1 (time P:32.87 | 0.3) The backend returns -1. This is an operational poller sending output to an administrative backend. The first returns a string "ok", the second expects a number; either 0,3 or 2. > 12:17:34 : H 127 : I 388 : P 30 : dell_om_chassis(1.3...abl): ok -> > alarm(3,,180): Nothing was done (time P:35.42 | 0.96) Your poller returns "ok", The alarm backend does not alarm because we don't create events for working devices. > 12:19:25 : H 127 : I 388 : P 30 : dell_om_chassis(1.3...abl): > noncritical -> alarm(3,,180): Invalid Result (time P:32.79 | 0.67) It backend got "critical". It looks up that Alarm state table and goes "huh"? > "Invalid Result"? No events are recorded this way... so I must still be > doing something wrong. I've read the docs about a hundred times now and > I have to conclude that I'm too dumb to understand how this is supposed > to work. http://www.jffnms.org/docs/expanding.html#id19 "The backend expects from the poller an alarm level or the alarm level and optional description. A pipe character separates the level from the description. The level must match one of the Descriptions in the Alarm States table." It doesn't say not doing that will result in "Invalid Result", but I'll add that in. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ jffnms-users mailing list jffnms-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jffnms-users
