AIOps 2.3-Release Description
Click here to see this page in full context

AIOps 2.3-Release Description

AIOps 2.3 is a minor release aimed at implementing priority feature requests from customers. This release focuses on ‘Faster Customer On-boarding’ by introducing new features in L0 automation and customization, alert enrichment and advanced filters.

"Group By" Option in Auto Closure  

In AIOps whenever a recovery alert is received, the system checks and compares if the auto-close attributes on the recovery alert matches with all the alerts in the cluster. If it matches, the cluster is automatically closed. Although this method provides assurance that a cluster will never be auto closed incorrectly. It does not provide the flexibility required when alerts from multiple sources are correlated into clusters. It is highly unlikely that alerts from different sources will share the same auto-close alert attributes. To bring in this flexibility required, AIOps introduces an API-first solution ‘Group-by option in auto closure’ in this release.
Admins can set up ‘group-by’ attribute(s) to use for auto-closure. Alerts will be grouped into internal sub-groups within clusters, based on the selected attribute(s). An alert cluster will be auto-closed, only when all sub-groups in the cluster has received a recovery alert.
Here is an example to illustrate the feature.


 
Going forward, all projects will have ‘group by’ attribute as mandatory. The default setting will be ‘Node name’. Admins can change this using the APIs.
This feature will also change the way alert cluster severity is determined in AIOps. Alert cluster severity is calculated based on the highest severity among the sub-groups. The severity of the subgroup is calculated as the highest alert severity in the subgroup. However, if the latest alert in the subgroup is a recovery alert, the subgroup severity is changed to the same severity as that of the recovery alert.
Here is an example to illustrate the severity calculation.

Custom Elastic Query in Advanced Filter  

This release introduces a ‘custom query’ feature, which can be used if the user’s filter requirement is complex and cannot be fulfilled using the available fields in the Alerts Advanced Filter.
Users can create a custom filter by providing an Elastic query using fields from the alert data store. These custom query filters can be used like regular filters - they can be saved/deleted, set as default filter etc.
In future, this feature will eventually be replaced with an ‘AIOps Query Language’ feature.

To use the Custom Elastic Query, follow the steps mentioned below:

  1. Navigate to Alerts listing page of AIOps.

  2. Select Advanced Filter option to view the Advanced Filter window as shown in Figure:

  3. Select Custom Query to view the custom Query window as shown in Figure.
    You may view the list of fields available from the Available fields tab.
    Also, you may save the filter for future use.

Check ITSM ticket status before auto-closure 

As part of this release, a new configuration setting ‘Do not auto close when ticket is in’ option is being introduced. An admin can use this setting to disable auto-closure for tickets in selected states.
Let’s say: - A ticket cluster that receives ‘REC’ alert and is eligible for auto-closure will also check for the ‘Do not auto close when the ticket is’ state and keeps the cluster active rather than changing into ‘Resolved’ state and waits for user intervention.

To enable checking ITSM Ticket status before auto closure, follow the steps below:

  1. Login to AIOps. 

  2. Click on Configuration tab. This displays the Alert Configuration Policy screen as shown in FigureFigure.

  3. Click on Autoclosure and Flapping available in the left pane. This displays the Alert Closure and Flapping Conditions screen as shown in FigureFigure.

  4. You may configure the auto close facility based on the status.

API for Bulk Update of Device Maintenance Status  

AIOps application has device inventory details which is used to enrich alerts before correlation. Currently, update of device details can be done on the device details screen for a specific device, or through a bulk update using device inventory Excel file.
This release includes an API which will make it easier for admins to do bulk update for maintenance status of devices. The API will allow only ‘ON’ & ‘OFF’ values while updating the maintenance status. Response will return the number of devices updated successfully and if there are no devices matching the criteria, an appropriate message will be displayed.


Format Sample Request API

{
          “queryCriteria”: [
            {
              “field”: ”resourceName”,
              “operator”: ”IN”,
              “value”: “R1,
              R2”
            },
            {
              “field”: ”site”,
              “operator”: ”EQUALS”,
              “values”: “Site1”
            }
          ],
          “maintenanceStatus”: ”ON”
        } 

 

Permitted fields and references in templates according to scenarios  

From this release onwards only permitted fields and attributes will be allowed while using ticket templates for ticket creation and the following table illustrates the field limitations for each of the ticket scenarios.