Howto: BMC RBA Adapter for BEM

Size: px

Start display at page:

Download "Howto: BMC RBA Adapter for BEM"

Elwin Logan
6 years ago
Views:

1 Howto: BMC RBA Adapter for BEM Author: Markus Dillmann Version: 1.2, Monitor Adapter (getting Events from BEM) This section describes how to setup BEM and RBA to receive and handle events from BEM. Please refer to the RBA BEM Application Adapter Users guide for more detail regarding the BEM adapter. Initial setup This is the sample configuration from the adapter documentation: <config> <port>1859</port> <gateway-name>rbagw</gateway-name> <encryption-key>mc</encryption-key> </config> Basically you are free on what port the monitor adapter listens (as long as it is not used by another application). Gateway-name can also be chosen at will as long as you follow the BEM naming rules. 1 The encryption-key is default mc across the BEM product. It is strongly recommended that this value be change to something else, which can be up to 63 characters in length. After you setup up the monitor, you need to inform the BEM environment about it. To do so, add the following info to the mcell.dir located in $MCELL_HOME/etc. Note: If you have multiple BEM/SIM cells on different machines which will send events to RBA you have to add the information to all mcell.dir-files. If all cells are on the same box, you only need to add that once. From the docs: # Line to add in mcell.dir gateway.rba RBAGW mc localhost:1859 RBAGW is the name you chose in the adapter config is the value you provided in the port element of the adapter config. If the RBA-adapter doesn t run on the local box specify the ip-adress or the FQDN instead of localhost. The encryption key ( mc in this example) must match the one in the adapter config. gateway.rba : gateway is a fixed text but rba is the name that is used to identify the RBA to use. It is perfectly legal to have multiple RBA-entries here like: 1 sequence of characters excluding blanks and " ' ; :, = ( ) [ ] { } Page 1 of 12

2 gateway.rba-customer1 RBAGW mc localhost:1860 gateway.rba-dev RBAGW devkey localhost:1861 After making changes to mcell.dir restart BEM. If restart is not possible, use the BEM CLI mcontrol n <cellname> reload dir to force the reload of the directory file. Each of the gateway instances you configured (normally just one named gateway.rba) needs a configuration file which controls the format how the information is sent to the recipient. Create a new file named gateway.rba with the following content in the etc directory of the Impact Manager: cond.new=propagate cond.mod=always slots.new=[$all] slots.mod=[mc_ueid, $MODS] init.new=$class;\n init.mod=modify $GHANDLE;\n body=\t$name=$value;\n term=end\n If you named your gateway differently in mcell.dir (e.g. gateway.rba-customer1) create the file with that name but the content shown above. Setting up a BEM policy to automate handling of events by RBA The fastest/easiest way to automate the handling of events with RBA is to create a Notification Policy. A Policy is divided in two parts: the selector, which defines the conditions an event must satisfy, and the policy itself. First create a selector: Page 2 of 12

3 Switch to the Administration tab (arrow) and select/expand the cell you want to create the selector. In the toolbar click the leftmost-icon :. Then enter a name for the selector (required) and specify the event-class for the field Base Event Class. Via the add button you can add additional conditions that events must match (e.g. severity, specific hosts the event came from). In the example above the selector triggers on all events of class PROCESS_HANG (this is not a standard BEM-class but a custom one). You can choose any class (e.g. the root-class EVENT or PATROL_EV) and further qualify which events you want to process with additional conditions. This limits the number of events sent over to RBA. On the RBA monitor-adapter you also specify rules (conditions) which will then trigger the RBA-workflow. You have to judge how much you filter on BEM and RBA. Now create the policy which propagates the events to our RBA monitor adapter: Page 3 of 12

4 First select the Propagation Policy on the left and then hit Add Event Policy at the top. (Note: if you do not first select the policy type but hit add first, a dialog shows up asking to choose the type of policy to create. Simply choose Propagation Policy here. After hitting add, BEM asks for the selector which should be used with that new policy: Page 4 of 12

5 Choose the Selector you created in the first place. In the now following policy-details choose the rba for Propagate to One Of and enter a name for the policy. rba will be the name you chose in mcell.dir for gateway.xxx see page 1. Page 5 of 12

6 Now you re done. Once saved, all new events satisfying the selector will be sent to RBA. Send an event over to RBA manually You way want to send events over to RBA at a later time instead of when they are initially received and processed (with the policy). This allows BEM-rules to control the forward to RBA at a later time based on other events or conditions that occur after the original event. E.g. you can have a timer-rule which sends the event to RBA for handling if not acknowledged by an operator within 10 minutes. Also, you can use this to have a context action in IX (Impact Explorer) to allow the operator to handle an event by RBA on demand. This setup requires several steps: 1. Create an additional slot (aka attribute) which will control the forward 2. Create a rule which reacts on this slot 3. Create an IX menu action To create a slot, you must first create a BEM-class (e.g. named rba.baroc ) file with the following content, put it in.load, compile and restart the cell. (See KB-Reference guide for more info on that process): Page 6 of 12

7 MC_EV_CLASS : EVENT DEFINES { handle_rba : STRING; }; END Create the following rule (e.g. named rba.mrl) in the BEM-rules directory, activate it by putting it in.load for the rules, compile and restart: execute handle_rba_interactive: EVENT ($EV) when $EV.handle_rba=='true' { send_to ('rba',$ev); } END Now add the following to the file mc_actions.mrl in the BEM-bin dir. Also needs compilation: action 'Handle Event with RBA': { ['Service Administrators'] } : EVENT($E) { set_list_slotvalues([$e],[handle_rba],[true]); } END You can name the action anything you like. Also Role-based access can be given (see KB-ref for details). Note: you can combine all compiles, by doing all changes first and then one single compile run. After successful compilation and restart the context-sensitive action is available: Page 7 of 12

The propagation (which is used with the policy) maintains a link between the event in BEM and the event as sent to RBA.

8 Any change to the value true of slot handle_rba e.g. by a timer-rule will trigger the send to RBA. Notes on updated BEM events The above methods use intentionally two different ways of transporting the info to RBA. The propagation (which is used with the policy) maintains a link between the event in BEM and the event as sent to RBA. This means that modifications to the event that occur later in the event s lifecycle are automatically sent over to RBA as event updates. For example if the event is closed (by an operator) after it s a few days old, this closeinformation is sent to RBA and depending on how you set up the rules in RBA may trigger workflow again. The interactive solution used the send_to mechanism using this the events are not coupled so later updates to the event are not forwarded to RBA. You could change the interactive solution to use the propagation-mechanism too (by using an propagation-rule instead of an execute-rule), but not the other way round: the propagation policy can t be changed to send_to without causing severe side-effects. A new event looks like this: Page 8 of 12

9 <event> <cell-name>bem</cell-name> <class-name>process_hang</class-name> <mc-arrival-time><![cdata[ ]]></mc-arrival-time> <msg><![cdata[hung process detected!]]></msg> <severity><![cdata[critical]]></severity> <mc-date-modification><![cdata[ ]]></mc-datemodification> <date><![cdata[ ]]></date> <mc-object><![cdata[cpuhog.sh]]></mc-object> <date-reception><![cdata[ ]]></date-reception> <mc-host><![cdata[fra-mdil-sun-01.bmc.com]]></mc-host> <mc-local-reception-time><![cdata[ ]]></mc-localreception-time> <mc-host-address><![cdata[ ]]></mc-host-address> <mc-ueid><![cdata[mc.bem.88dc7f3.0]]></mc-ueid> <mc-location><![cdata[bmc.com]]></mc-location> <mc-history><![cdata[[bem:2648]]]></mc-history> </event> whereas an update looks like this: <event> <status><![cdata[closed]]></status> <mc-ueid><![cdata[mc.bem.88dc7f3.0]]></mc-ueid> </event> An update-event only contains the updated slots (may be more than one) and the uniqueid (mc-ueid) which uniquely identifies the event inside BEM. If you want to trigger only on new events, you can set up the rule in RBA to check for the existence (and perhaps the value) of the slot/attribute class-name. As class-names can t change in BEM, you will never receive an update-event containing this. An example rule: Page 9 of 12

$new=$class;\nbemeventtype=new;\n init.$

10 An alternative approach to distinguish new and update-events is to add a tag in the gateway-configuration like this: slots.new=[$all] slots.mod=[mc_ueid, $MODS] init.new=$class;\nbemeventtype=new;\n init.mod=modify $GHANDLE;\nBEMEventType=MOD;\n body=\t$name=$value;\n term=end\n This instructs BEM to send a new pseudo-slot with each event to RBA which contains the value NEW for new events and MOD for modified ones. Events in RBA will look like this: <event> <cell-name>bem</cell-name> <class-name>process_hang</class-name> <mc-arrival-time><![cdata[ ]]></mc-arrival-time> <BEMEventType><![CDATA[NEW]]></BEMEventType> <msg><![cdata[hung process detected!]]></msg> <severity><![cdata[critical]]></severity> <mc-date-modification><![cdata[ ]]></mc-datemodification> <date><![cdata[ ]]></date> <mc-object><![cdata[cpuhog.sh]]></mc-object> <date-reception><![cdata[ ]]></date-reception> <mc-host><![cdata[fra-mdil-sun-01.bmc.com]]></mc-host> Page 10 of 12

11 <mc-local-reception-time><![cdata[ ]]></mc-localreception-time> <mc-host-address><![cdata[ ]]></mc-host-address> <mc-ueid><![cdata[mc.bem.88dc7f3.0]]></mc-ueid> <mc-location><![cdata[bmc.com]]></mc-location> <mc-history><![cdata[[bem:2648]]]></mc-history> </event> <event> <BEMEventType><![CDATA[MOD]]></BEMEventType> <status><![cdata[closed]]></status> <mc-ueid><![cdata[mc.bem.88dc7f3.0]]></mc-ueid> </event> So you can easily set up the RBA-rules to trigger the workflow you want. If you want to react properly on modifications (e.g. when a close of an event is received and you need to access other values from the event besides the status -slot) you may need an additional workflow-step which reads the complete event from the BEM based on the mc-ueid and pass this on. Troubleshooting If your workflow doesn t get started on RBA, you first should check if BEM correctly sent over the event. If you used the propagation-method, BEM keeps track of that and helps you diagnose problems. Select the event in question and click on the Internals tab. Look at the field Propagations : Page 11 of 12

If you see something like PEND: followed by a number in the Propagations-slot, this means that the RBA-adapter could not be connected.

12 If this contains the name of your gateway followed by a number, then the event was received by the RBA adapter and acknowledged. In this case check RBA s process log perhaps the filters there are not correct. If you see something like PEND: followed by a number in the Propagations-slot, this means that the RBA-adapter could not be connected. Perhaps the adapter/peer isn t started or you have networking issues (e.g. no connectivity or wrong encryption-key ). Fix that and BEM will retry the propagations automatically each 10min by default. If you are in a hurry, you can tell BEM to force-retry propagations immediately via BEM-CLI mcontrol n <cellname> prop If you see nothing in Propagations at all or at least you don t see your rba, this means that your propagation-policy did not trigger. This is mostly likely caused by the event not having the exact conditions you specified in the selector. You could test your selector with e.g. an notification-policy (to send you an ) to verify that the selector works. Page 12 of 12

12/05/2017. Geneva Service Management

12/05/2017. Geneva Service Management 12/05/2017 Contents Contents...4 Activate...4 Activate other applications... 4 Service management states...6 State flow customization...6 State flow example... 11 Implications of disabling SM state flows...