AIOps Release 2.3

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.

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.

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.

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”
        } 
                                                    

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.