In Event Management the term "blackout" (or "maintenance") is used to refer to a time period when notifications for events should be prevented, for example when regular system maintenance is scheduled.  Ideally, Event Management would be tightly integrated with a CMDB so that changes to the status of a CI would be reflected in an alert (i.e. event notification).  Furthermore, if Event Management is tightly integrated with Change Management, then any active change requests that change the status of a CI would also be reflected in an alert. ServiceNow Event Management takes advantage of native integration with the CMDB and Change Management to automate these blackout scenarios, and it does so using Maintenance Rules.

 

Maintenance Rules are used to determine when the Maintenance field for an alert associated with a CI in the CMDB should be set (or unset).  When an alert is in maintenance, the impact of the alert (i.e. the severity) for the CI is excluded from impact calculations.

 

ServiceNow Event Management includes two default Maintenance Rules that will automatically set the Maintenance field for an alert to true:

  • CI in Change Window - Where the CI has an active change window, the matching CIs are marked as being in maintenance status.  The following conditions in a Change Requestmust be met:
    • State is one of these options: Scheduled, Implement, Work in Progress, or Open/New
    • Approval is Approved
    • The current time is between Planned start date and Planned end date, or between Actual start and Actual end
    • The change request record is not an on-hold record
  • Maintenance status of CI - CIs whose CMDB status field is In Maintenance are flagged by this rule as being in maintenance status.

 

Maintenance Rules are executed every minute by a scheduled job.

 

In addition to these OOTB Maintenance Rules, you can define your own rules to cater for unique requirements.  You can configure a Maintenance Rule to automatically set the Maintenance field in an alert based on a condition built from any table within a ServiceNow instance.  Two examples using this method are provided in the ServiceNow Product Documentation.  Note that when a custom Maintenance Rule sets the Maintenance field to true for an alert, the associated CI's status is not set to In Maintenance - the Maintenance Rule only changes the status of the Maintenance field for the alert.

 

Some scenarios however, may require more complex business logic and fortunately, Maintenance Rules include an Advanced option enabling JavaScript to be used to configure processing logic.

 

Recently a question was posted on the ServiceNow Community asking how Event Management could suppress alerts for CIs during a specific time window.  For example, suppose a monitoring tool generates an event for a Windows Server that experiences very high CPU utilization every day between between 6am - 7am however this is actually normal.  Assuming "blackout" functionality is not available in the monitoring tool (and you're not using Operational Intelligence... wait, you're not??), you might initially consider using an Event Rule in ServiceNow to filter events.  While configuring a Filter in an Event Rule does support certain date/time operations such as comparing the time_of_event between two selected times, the times are effectively static - you wouldn't want to be manually setting the start and end date/times every day, right?

 

Rather than filter the event, we can use a Maintenance Rule to automatically set the Maintenance field to true for an alert.  Here's how in Jakarta:

  • Navigate to Event Management > Rules > Maintenance Rules and click on New.
  • Provide a Name for the rule and then check the Advanced checkbox.  When you do this you'll see default code provided for you:

(function findCisInMaint(){

   //Your code goes here

   var result = ['id1','id2','id3'];

  

   return JSON.stringify(result);

})();

  • The script returns an array of strings that are then converted into a format Event Management uses to place alerts with matching CIs into Maintenance.  Here's a sample script supporting the scenario described above:

 

(function findCisInMaint(){

 

   // Get the CI(s)

   var ci = new GlideRecord('cmdb_ci');

   ci.addQuery('name','V-W2K3-32-MQ7');

   ci.addQuery('sys_class_name', 'cmdb_ci_win_server');

   ci.query();

 

   if (ci.next()) {

      // Set the CI ID

      var cid = ci.sys_id;

      // Get current date/time so we can build the date format

      var cdt = new GlideDateTime();

      var date = cdt.getYearUTC() + '-' + cdt.getMonthUTC() + '-' + cdt.getDayOfMonthUTC();

      // Set start time

      var sgt = new GlideDateTime();

      sgt.setDisplayValueInternal(date + ' 06:00:00'); // Adjust as necessary

      //Set end time

      var egt = new GlideDateTime();

      egt.setDisplayValueInternal(date + ' 07:00:00'); // Adjust as necessary

      // Get current time

      var ngt = new GlideDateTime();

 

      // if the current time is between the start and end times add the CI to the result array

      if ((ngt.compareTo(sgt)==1) && (ngt.compareTo(egt)==-1)) {

         var result = [cid + ""];

         return JSON.stringify(result);

      }

   }

})();

 

 

In this sample script, since the sys_id field being returned is an object we append the "" to convert it to a string as the function returns an array of strings. While this is a fairly basic example, it could easily be extended into a more flexible solution by adding a table and form allowing the CI(s) and start/end times to be selected.

 

Hopefully the information in this blog helps demystify how Maintenance Rules can be used to support blackouts in ServiceNow Event Management.

 

Keep posted for more blogs on Event Management in the future.