Downtime Management

Administration > Service Health > Downtime Management

Alternatively, click Downtime Management.

Downtime or other scheduled events can skew CI data. You may want to exclude these periods of time from being calculated for events, alerts, or views.

Downtimes are configured based on associated CIs. For example, you may want to exclude a recurring maintenance event or a holiday for a specific host CI whose physical host will be down for that period of time.

When defining downtimes, you configure how often the downtime will occur and select the specific CIs that will be affected by the downtime.

You can select the action that will be taken during the downtime on the CIs specified in the downtime configuration. Downtime can impact the following:

• Alerts and Events. Events are suppressed and no CI status alerts or notifications are sent for the CIs associated with the downtime.

• KPIs. KPIs attached to the CI and impacted CIs are not updated and display the downtime for the CI.

• Monitoring. SiteScope monitoring stops for any of the CIs associated with the downtime.

The options you select in the Downtime Management page are combinations of the above actions, grouped in this order. This means that each option includes the previous options listed. The actions that are taken in OMi during the downtime depend on the option selected during downtime configuration.

Before creating downtimes, consider the following:

• The downtime will affect the CIs in your system. In some cases, the CIs that impact the CIs you have selected for downtimes can be affected as well.

  To understand the downtime impact model, see the BSMDowntime_topology TQL query in the RTSM Modeling Studio.

  You can select CIs of the following CI types: Node, Running software, Business application, CI Collection, Infrastructure service, and Business service.

  Note Even though SiteScope URL monitors are not included in the list of CI types, you can define a downtime on a SiteScope URL monitor by using a CI type Computer:

  1. In SiteScope, define a SiteScope URL monitor as a Computer named HPSERVER.

  2. In Downtime Management, create a downtime on a server name called HPSERVER.

• You must have the relevant permissions on the downtime resource to add, edit, or delete downtimes. In addition, you must have the View permission on the views to which CIs in the downtime belong. For details on roles and permissions, see Users, Groups, and Roles.

• If you plan to select an action option that includes suppressing events in a downtime on a selected CI, the result depends on how the downtime behavior is configured for the events related to the CI. For details, see Downtime Behavior.

By default, there is a maximum number of CIs and downtimes. These values are configured in the infrastructure settings for downtimes. The limits are enforced in both the OMi UI and the REST web service.

When adding a new downtime, OMi checks that the number of downtimes configured in the system is less than the downtime threshold. You can only add a new downtime if the number of downtimes in the system is below the threshold.

When adding CIs to a new or existing downtime, OMi checks that the number of CIs configured in the system is less than the CI threshold. You will only be able to continue the process if the number of CIs is below the threshold.

Although you can edit the downtime and CI thresholds, HPE recommends that you first delete unnecessary CIs or downtimes. Increasing the downtime and CI thresholds can adversely affect your system efficiency.

For details, see How to configure maximum number of CIs in downtimes and How to configure maximum number of downtimes.

You can purge downtimes based on the downtime completion date. By default, periodic purging is active and the time period from which completed downtimes are purged is 1095 days. This means that by default, all downtimes that were completed more than 3 years ago are purged.

From the JMX console, you can also set how often periodic purging should be run. The default value is 7 days.

When starting the downtime service, the frequency for which the periodic purging is run is offset by 10 minutes. Therefore, if the periodic purging downtime runs every 7 days and you start the downtime service at 9 am on Monday, the periodic purging downtime is performed every Monday at 9:10 am.

For details, see How to configure periodic purging frequency.

You can retrieve, update, create, and delete downtimes through a RESTful web service running on the gateway server. For details, see Downtime Web Service Interface.

In time zones that observe Daylight Saving Time (DST), downtime calculations take into account the transitions between Standard and Daylight Time using the rules described below.

Spring (Standard to Daylight Time)

• When downtime starts before the DST change and ends the day after the change, its end time is as expected, but the duration is 1 hour less than defined.

  Example 1:

  Monthly downtime starting 14th day of month at 1:30 am and ending on 15th day of month at 2:40 am. Duration is 1 day, 1 hour, and 10 minutes.

  No DST change: Downtime starts on 14th at 1:30 am and ends on 15th at 2:40 am. Duration is 1 day, 1 hour, 10 minutes.

  DST change on March 14 2010: Downtime starts on 14th at 1:30 am and ends on 15th at 2:40 am, but the duration is 1 day, 0 hours, 10 minutes (1 hour less than defined).

• When downtime starts before the DST change and ends the same day as the change, but after the change, its end time is 1 hour more than defined, but its duration is as defined.

  Example 2:

  Monthly downtime on 13th day of month, starting at 11 pm (23:00), for a duration of 5 hours.

  No DST change: Downtime starts on 13th at 11:00 pm and ends on 14th at 4:00 am.

  DST change on March 14 2010: Downtime starts on 13th at 11:00 pm and ends on 14th at 5:00 am, and the duration remains 5 hours.

• When downtime is defined to start during the skipped hour, the start time shifts 1 hour forward and keeps the defined duration.

  Example 3:

  Monthly downtime on 14th day of month, starting at 2:30 am, for a duration of 2 hours.

  No DST change: Downtime starts on 14th at 2:30 am and ends on 14th at 4:30 am.

  DST change on March 14 2010: Downtime starts on 14th at 3:30 am and ends on 14th at 5:30 am, and the duration remains 2 hours.

• When downtime is defined to start before the DST change and end during the skipped hour, the end time shifts 1 hour forward and keeps the defined duration.

  Example 4:

  Monthly downtime on 13th day of month, starting at 1:30 am, for a duration of 1 day, 1 hour, and 10 minutes.

  No DST change: Downtime starts on 13th at 1:30 am and ends on 14th at 2:40 am. The duration is 1 day, 1 hour, and 10 minutes.

  DST change on March 14 2010: Downtime starts on 13th at 1:30 am and ends on 14th at 3:40 am, and the duration remains as defined -- 1 day, 1 hour, and 10 minutes.

• When downtime is defined to start and end during the skipped hour, downtime takes place one hour later than defined.

  Example 5:

  Monthly downtime on 14th day of month, starting at 2:00 am, for a duration of 1 hour.

  No DST change: Downtime starts on 14th at 2:00 am and ends on 14th at 3:00 am.

  DST change on March 14 2010: Downtime starts on 14th at 3:00 am and ends on 14th at 4:00 am, and the duration remains as defined – 1 hour.

Fall (Daylight Time to Standard Time)

• When downtime starts and ends after the DST change, its end time and duration are as defined.

• When downtime starts before the DST change (same day as change or day before) and ends after the change during the day of the change, the end time is 1 hour less than expected, and duration is as defined.

  Example 6:

  Two monthly downtimes, both starting on the 7th day of month at midnight. The first downtime duration is 1 hour, and the second is 2 hours.

  No DST change: The first downtime is on 7th from 0:00 to 1:00 am (1 hour duration), and the second on 7th from 0:00 to 2:00 am (2 hours duration).

  DST change on November 7 2010: The first downtime starts on 7th at 0:00 Daylight Time and ends on 7th at 1:00 am Daylight Time, with a duration of 1 hour. The second downtime starts on 7th at 0:00 Daylight Time and ends on 7th at 1:00 am Standard Time, and the duration remains 2 hours.

  Example 7:

  Monthly downtime on 7th day of month, starting at midnight, for a duration of 4 hours.

  No DST change: Downtime starts on 7th at 0:00 and ends on 7th at 4:00 am.

  DST change on November 7 2010: Downtime starts on 7th at 0:00 and ends on 7th at 3:00 am, and the duration remains as defined – 4 hours.

  Example 8:

  Monthly downtime on 6th day of month, starting at 8:00 pm (20:00), for a duration of 7 hours.

  No DST change: Downtime starts on 6th at 8:00 pm and ends on 7th at 3:00 am.

  DST change on November 7 2010: Downtime starts on 6th at 8:00 pm and ends on 7th at 2:00 am, and the duration remains as defined – 7 hours.

• When downtime starts before the DST change and ends the day after the change, the end time is as expected, and duration is 1 hour more than defined.

  Example 9:

  Monthly downtime on 7th day of month, starting at midnight (0:00), for a duration of 1 day, 1 hour (25 hours).

  No DST change: Downtime starts on 7th at 0:00 and ends on 8th at 1:00 am.

  DST change on November 7 2010: Downtime starts on 7th at 0:00 and ends on 8th at 1:00 am, but the duration is 26 hours.

DST changes affecting downtime: example summary

1. Click New to create a new downtime or Edit to edit an existing downtime. The Create Downtime or Edit Downtime panel opens.

   Important Before creating downtimes, make sure you reviewed important considerations as described in Important considerations, and configured downtime behaviors for events as described in Downtime Behavior.

   Note If the status of a downtime changes from Idle to Active while editing it, changes to the downtime cannot be saved.

2. In the General section, provide the following information:

   1. Enter or edit a display name and, optionally, a description.

   2. In the Approved by field, enter a person or a department that approved this downtime.

   3. Select a category that describes the reason for the downtime.

      Tip You can also create your own customized categories as follows:

      1. Open the Infrastructure Settings page:

         Administration > Setup and Maintenance > Infrastructure Settings

         Alternatively, click Infrastructure Settings.

      2. From the Foundations drop-down list, select Downtime

      3. In the Downtime - General settings section, edit the Downtime categories value to the name you want to use as a customized category for the downtime. The name you enter appears as an option in the list of available downtime categories after you restart OMi.

   4. Select the Planned check box if you want this downtime to be marked as planned.

      Note This is for information purposes only. You can also create unplanned downtimes.

3. In the Configuration Items section, click Select CIs, and, in the Select CIs side panel, select the view that contains the CIs to be affected by this downtime. You can select any view that you have permission to see. Select a CI from the view to move it to the list of selected CIs.

   You can select CIs of the following CI types: Node, Running software, Business application, CI Collection, Infrastructure service, and Business service.

   When the CIs are selected, they appear in the list of selected CIs. To remove a CI from the downtime, hover over it and click Delete.

   Note You cannot edit CIs for the downtimes that already occurred.

4. In the Scheduling section, configure the downtime schedule:

   Note For downtimes that have already occurred, you can edit only the End by date. To cancel a recurring downtime that already occurred at least once, edit the downtime End by date .

   1. Select the recurrence pattern:

      • Once. The downtime happens only once as scheduled and does not recur. Select the calendar date for the occurrence.

      • Weekly. Select a day or days of the week for the scheduled weekly recurrence.

      • Monthly. Select a day in the month or a monthly repeated downtime pattern.

      For example, you can schedule a downtime event on the first Sunday of every third month.

      Note If you selected Weekly or Monthly, define the start date, and select either End by or No end date.

   2. Select the required time zone. All time zones are displayed in relation to GMT.

   3. Select the time. The drop-down lists includes the times set for every half hour on the hour and half hour. To select a different time, select the closest half hour and edit the field to enter the actual time you want the downtime to start. For example, for 2:10 am, select 2:00 am and edit the minutes to indicate 2:10 am.

   Note The time displayed in the Duration field will differ from the actual duration of the downtime if the start time and end time have different daylight savings time states. The configured start and end times will be used, even if an hour is skipped or gained during the downtime duration.

5. In the Action section, define a set of actions to be taken during the downtime. You can select one of the following:

   • No action. No action is taken on the associated CIs or the CI monitoring, alerts, or reports.

     Note During this downtime, the affected CI does not change its status to Downtime. CI status alerts are configured to be triggered if the CI changes its status.

   • Consider events. No alerts or their associated notifications or actions are sent for any of the CIs associated with the downtime. By default, events are submitted as closed. The OMi event handling in downtime configured in the Downtime Behavior manager overrides this setting. Monitoring continues and the status is updated.

     Note During the downtime period, the affected CI may change its status, and the status change may trigger the relevant CI status alert.

   • Consider events, enforce downtime on KPI calculations. KPI calculations are not run and the status is not updated. The downtime for the CI is displayed. No alerts or their associated notifications or actions are sent for any of the CIs associated with the downtime. By default, events are submitted as closed. The OMi event handling in downtime configured in the Downtime Behavior manager overrides this setting. Monitoring continues.

   • BSM/APM integration only. Additionally enforce downtime in BSM/APM reports. If this option is selected, the report data is not updated and the downtime is displayed for the associated CIs.

     Note APM integration only. Selected SLAs are not updated for the SLAs affected by the CIs associated with the downtime.

     KPI calculations are not run and the status is not updated. The downtime for the CI is displayed. No alerts or their associated notifications or actions are sent for any CIs associated with the downtime. By default, events are submitted as closed. The OMi event handling in downtime configured in the Downtime Behavior manager overrides this setting. Monitoring continues.

   • BSM/APM integration only. Additionally enforce downtime in BSM/APM reports and stop active BPM & SiteScope monitoring. If this option is selected, Business Process Monitor and SiteScope monitoring stops. Report data is not updated and the downtime is displayed for the associated CIs.

     Note APM integration only. SLAs are not updated for the SLAs affected by the CIs associated with the downtime.

     KPI calculations are not run and status in Service Health is not updated. The downtime for the CI is displayed. No alerts or their associated notifications or actions are sent for any CIs associated with the downtime. By default, events are submitted as closed. The OMi event handling in downtime configured in the Downtime Behavior manager overrides this setting.

     Note Downtime Sync with APM only. If you configure a downtime period for an Application CI (which data is updated by BPM monitoring), the Downtime Manager automatically sends an event to the BPM Agent when the downtime period starts. The agent stops sending samples to OMi. The samples that are suppressed are the BPM samples corresponding to the Transaction CIs, which are child CIs of the Application CIs on which the downtime is configured. There is one sample per transaction.

6. In the Notification section, select the recipients to receive downtime notifications. Notifications are sent by email at the time of the downtime occurrence and immediately after its completion. You can select only the recipients with an email address defined.

   Note You can edit selected recipients for downtimes that already occurred.

   To create a recipient that is not yet in the list of available recipients, click the Users > Recipients link. For details on creating recipients, see Recipient Management.

7. Click Create or Save.

By default, downtimes with the Completed status are hidden.

To view completed downtimes, click Filter and select the Show completed downtimes check box.

1. Open the Infrastructure Settings page:

   Administration > Setup and Maintenance > Infrastructure Settings

   Alternatively, click Infrastructure Settings.

2. Select Foundations.

3. From the Foundations drop-down list, select Downtime.

4. For the Max. number of downtimes parameter, click Edit Setting.

5. In the Value field, enter a new value.

6. Click Save.

7. Restart the server for the new value to take effect.

1. Open the Infrastructure Settings page:

   Administration > Setup and Maintenance > Infrastructure Settings

   Alternatively, click Infrastructure Settings.

2. Select Foundations.
3. From the Foundations drop-down list, select Downtime.
4. For the Max. total number of CIs in downtimes parameter, click Edit Setting.
5. In the Value field, enter a new value.
6. Click Save.

7. Restart the server for the new value to take effect.

By default, periodic purging is active and the time period from which completed downtimes are purged is 1095 days. To disable periodic purging, change the value of the Run periodic purging parameter to false.

1. Open the Infrastructure Settings page:

   Administration > Setup and Maintenance > Infrastructure Settings

   Alternatively, click Infrastructure Settings.

2. Select Foundations.

3. From the Foundations drop-down list, select Downtime.

4. For the Run periodic purging parameter, click Edit Setting.
5. In the Value field, select false.

6. Click Save.

7. Restart the server for the new value to take effect.

You can also set how often periodic purging should be run. The default is 7 days.

1. In a browser, enter the URL of the JMX console:

   https://localhost:29000

2. Enter your JMX console authentication credentials.

3. Go to Foundations:service=Infrastructure Settings Manager.

4. Invoke the setSettingValuePerCustomerId function after entering the values for contextName, SettingName, and newValue.

5. Restart the server.

By default, events that are received during a downtime are kept as closed events. To discard these events instead, create a corresponding Event Suppression rule.

1. Open the Event Suppression page:

   Administration > Event Processing > Correlation > Event Suppression

   Alternatively, click Event Suppression.

2. Click New Item.

3. Enter a display name.

4. Create and select a new event filter for events that were received during a CI downtime.

   1. To open the Manage Event Filters side panel, click (...) Manage Event Filters.
   2. Click New.
   3. Enter a name (for example "Events received during downtime").
   4. To specify the filter, click Add condition.
   5. Type Received On CI Downtime and press Enter. Alternatively, click Show complete list and select Received On CI Downtime.
   6. Set the value of the filter condition to True.
   7. Click Save to save the filter and close the Create Filter side panel.
   8. In the Manage Event Filters side panel, click Select.

5. In the Create Event Suppression Rule dialog box, select Activate Rule after creation.

6. Click OK to save the rule. All events that are received for CIs in a downtime will now be discarded.