Re: [jffnms-users] Dell OpenManage

[Ben Lentz]

----- Original Message ----- From: [EMAIL PROTECTED] (Craig Small) Sent: Monday, January 23, 2006 4:59:28 PM To: jffnms-users@lists.sourceforge.net Subject: [jffnms-users] Dell OpenManage 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 That's all set, discovery for my Dell OpenManage poller is working. 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. Heh, I guess not... maybe I'll go back and add one based on your recommendation. 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. I'm not sure I get this. Before when I was following the documentation, it looks like the instructions were to modify the poller/backend relationship to include the new poller to "Alarm Verify Operational" and "Admin Status Change View" (although I'm not sure why). When I first tried to do this, I had problems because the Dell OpenManage "DellStatus" output for the chassis OID returns one of 1=other|2=unknown|3=ok|4=noncritical|5=critical|6=nonrecoverabl. When I did my test, my poller (well, snmp_status) would've returned "noncritical", an output not understood by the default list of "Alarm States and Sounds". Per your recommendation, I added these other types to the "Alarm States and Sounds" table. Miraculously, I think it's working. 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. Yeah, this was extremely helpful. 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. Just playing around, didn't really understand what I was doing. 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"? Thanks for your help. The modifications, for anyone who is crazy enough to try and recreate my aimless JFFNMS support for Dell OpenManage chassis status is the following (Craig, please correct me if any of this looks wrong - I'd really like to get this as you guys intend for it to work - although, it's hard to argue with results): 1. A new Administration, Internal Configuration, Polling & Discovery, Poller Items:     Description: Dell OpenManage Chassis Poller     Name: dell_om_chassis     Poller Command: snmp_status     Parameters: 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=nonrecoverabl 2. A new Administration, Internal Configuration, Polling & Discovery, Interface Type:     Description: Dell OpenManage Chassis Interface     AD enabled: Checked     Validate in AD: Checked     Discovery Function: Simple     Discovery Parameters: .1.3.6.1.4.1.674.10892.1.200.10.1.2.1,Chassis Status     Discovery Default Poller: Dell OpenManage Chassis Group (this will need to be set after it's created, happens next) 3. Under the Interface Type, click Fields, and Add a new field:     Description: Dell OpenManage Chassis Field     Internal Name: dell_om_chassis_field 4. A new Administration, Internal Configuration, Polling & Discovery, Poller Grouping item:     Description: Dell OpenManage Chassis Group     Interface Type: Dell OpenManage Chassis Interface 5. Under the Poller Grouping item, click View and add new Pollers/Backend Relation items:     Position: 10     Poller: Dell OpenManage Chassis Poller     Backend: Alarm Verify Operational and     Position: 20     Poller: Dell OpenManage Chassis Poller     Backend: Admin Status Change View 6. New items beneath Administration, Internal Configuration, Event Analyzer, Alarm States & Sounds:     Description: other     Alarm Level: 10     Internal State: Down and     Description: unknown     Alarm Level: 10     Internal State: Down and     Description: noncritical     Alarm Level: 90     Internal State: Down and     Description: critical     Alarm Level: 10     Internal State: Down and finally     Description: non-recoverabl(e?)     Alarm Level: 10     Internal State: Down 7. Add a Host that's running snmp with Dell OpenManage, and assign the RO community string. Do a discovery, and the Dell OpenManage Chassis Interface will appear. Check the box to add this interface, and if anything goes wrong with the ESM/BMC hardware monitoring, the Chassis Status flag will be set accordingly, will be picked up by JFFNMS using the chassis status OID, and you will be notified. "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