IT Operations Management (ITOM)
cancel

How to take advantage of event-driven ad hoc downtime manage

How to take advantage of event-driven ad hoc downtime manage

Micro Focus Expert

Consider the following scenario: a CPU event is assigned to Operations Manager i operator. The operator then follows a few steps as per company instructions to handle the event. One of the actions requires a restart of the server. In order to reduce unnecessary events, the operator defines a downtime for that server for the duration of the troubleshooting. OMi provides a Downtime Management UI, but that will take few minutes for the operator to set (or maybe he/she doesn’t have the necessary permissions). Another alternative to downtime is mentioned in this blog, but that method requires our operator to use the UI and be able to locate the necessary server in OMi views.  It also doesn’t allow for the case where a sys admin is locally logged into the server and wants to start an ad hoc downtime.

What if you could just trigger an ad hoc downtime event and OMi would do all the rest for you? There are many ways you can send such events to OMi:  

  • Use the OMi CLI sendEvent.bat/sh
  • Submit events to the OMi REST web service interface
  • Use the Operations Agent to process an opcmsg
  • Read a config file and send events accordingly, and more

These different ways to send events allow you to automate this process of creating ad hoc downtimes.

Today’s blog describes the steps needed to deploy and use the ad hoc downtime management procedure.

Components of the solution

This approach uses an EPI script, after CI resolution, which invokes the OMi downtime REST API. In addition, URL Tools provide visibility to those ad hoc downtimes to improve manageability and help you avoid exceeding downtime capacity.

You can download the content pack from ITOM Marketplace here.

The OMi Content Pack contains:

  • EPI script
  • EPI event filter
  • Tool to display all ad hoc downtimes
  • Tool to delete all ad hoc downtimes

Installation

  1. Download the ZIP file to a location on your browser’s machine
  2. Login to OMi as a super-admin user. Navigate to Administration > Setup and Maintenance > Content Packs
  3. Click the Import Content Pack button
  4. In the popup window, click the Browse button and select the ZIP file that you downloaded to your local browser’s machine
  5. Click Import

After importing the Content Pack into OMi, you will need to update the EPI script with your OMi server information as per the instructions below.  Then you are ready to generate events to trigger ad hoc downtimes to start and stop.

In order to use the provided tools, you need to place the attached JSP file on every GW under: <GW>\HPBSM\AppServer\webapps\site.war.

EPI script

In the appendix you will find the EPI script, which can be deployed manually in Event Processing Customizations > After CI/ETI resolution. You can also deploy the Content Pack which will do the same.

The script must be modified for your environment:

  1. In lines 31-39 you need to fill the correct values in order to connect to your OMi. If you have several GWs, then in the “HOST” variable you should provide the Data VIP, otherwise put the GW FQDN. USER and PASSWORD should be for user that has OMi Admin privileges.
  2. You can modify the default ad hoc downtime duration (line 52) and/or default ad hoc downtime action (line 54). The applicable action values can be found in the OMi Extensibility Guide.
  3. The EPI script is used with an event filter, in order to reduce performance impact on event processing. The event filter is:
    [Custom Attribute] DT_STATUS exists
  4. It is recommended that you adjust EPI script Timeout value based on your system load. A minimum of 3500ms worked in our test lab, and in few cases we even increased it to 5000ms.
  5. You can provide the View Name to be used when setting the downtime related CI. This is done in the method getViewNameFromCIT (lines 248-253). This is only used by the Downtime Management UI and doesn’t impact the downtime functionality even if the CI is not part of the selected view.

Ad hoc downtime event attributes

The ad hoc downtime EPI script uses several event attributes in order to create the downtime.

1) Custom Attribute “DT_STATUS”

This mandatory attribute is used by the EPI script and the event filter. The possible values are:Value description OMi.PNG

2) Related CI Hint

The event’s related CI is the CI to which ad hoc downtime applies. This can be adjusted using the Related CI Hint attribute. Every CI can be selected by OMi Downtime Management to be used by the ad hoc downtime EPI script (for example: Node, Business Application, CI Collection, Business Service, etc.)

Note: OMi Downtime Management uses the BSMDowntime_topology TQL to calculate which CIs are impacted, if any, as well as the CI(s) specified in the downtime. In many cases there will also be children CIs impacted by downtime. This may be useful if you need to put several CIs into downtime. Instead of selecting each individual CI, you can put the parent CI in downtime and have it impact its children.

Note: By default, the BSMDowntime_topology TQL is hidden. To view this query in the Modeling Studio, go to Administration > RTSM Administration > Administration > Package Manager > Tools > User Preferences > General > Show hidden queries and set the value to True.

3) Custom Attribute “DT_Action”

This optional attribute determines the ad hoc downtime action. The possible values are:

Value description OMi 2.PNG

If this attribute is not set by the event, or it is not a valid value, the ad hoc downtime action is set according to the default value in the EPI script.

4) Custom Attribute “DT_Duration”

This optional attribute determines the downtime duration, in just minutes. If it is not specified, then the default downtime duration is set according to the EPI script (the default value is 5 minutes).

5) Description

This optional attribute can be used to display the downtime’s selected CI display name in the additional Tools by setting the event’s description to: ${relatedCi.label}

You can also customize the downtime description prefix in the EPI script variable (default is: “CI Name:”)

Example ad hoc downtime event

The following shows an example event that is generated to put the mynode.example.com CI into downtime for 10 minutes, where the action is to consider events based on the downtime behavior.  This behavior by default closes the events that arrive during downtime.

Linux:

/opt/HP/BSM/opr/support/sendEvent.sh -s normal -t "Test enabling ad hoc downtime" -d "\${relatedCi.label}" -rch @@mynode.example.com -ca DT_STATUS on -ca DT_Action 2 -ca DT_Duration 10

Windows:

%TOPAZ_HOME%\opr\support\sendEvent.bat -s normal -t "Test enabling ad hoc downtime" -d "${relatedCi.label}" -rch @@ mynode.example.com -ca DT_STATUS on -ca DT_Action 2 -ca DT_Duration 10

Ad hoc downtime tools

The tools are defined on the “OMi Gateway Server” CI type. Simply go to the OMi Deployment view, click on an OMi Gateway Server CI and select Launch Tools.Omi select tool.png

 

You can also add http tools if needed.

The tool’s URL is constructed by using the management server FQDN.

 

 

 

Comments
Super Contributor.

Hi,


Firstly thanks to all those continuing to try and find ways to make ad-hoc outages easier in OMi. Its a pity HPE didn't tool this better originaly within OMi and make it as easy as they were in OM.

I note all the specifics here around GW servers and DW VIP's etc... How does this all apply to OMi within a CDF deployment? There are no GW or DW servers.. 

I can't tell from your profile if you work for HPE/MF... but my company as a long time user of ITO/OVO/OM, we're no longer even considering the traditional deplopyments models. Everything going forward we're looking to containers and the benefits from that model.

Cheers