New Features

Moogsoft AIOps v7.2.0 contains the following new features. See Graze API and MoogDb V2 for details of new and changed endpoints and methods.

Ticket

Release Note

MOOG-10883

The version of Java used by Moogsoft AIOps has been upgraded to OpenJDK 11.

MOOG-11676

The version of Apache Tomcat used by Moogsoft AIOps has been upgraded to v9.0.13.

MOOG-12442

The version of Apache Tomcat Native used by Moogsoft AIOps has been upgraded to v1.2.21.

MOOG-10635

The version of Hazelcast used by Moogsoft AIOps has been upgraded to v3.11. If you use Hazelcast Management Center to monitor Hazelcast, you need to upgrade it in parallel.

MOOG-12333

Percona XtraBackup is now bundled in $MOOGSOFT_HOME/contrib.

MOOG-1117

The Workflow Engine is a new Labs feature that enables Implementers and Administrators to add custom logic for event, alert and Situation processing.

MOOG-11954

An automated ticketing workflow is provided by default in the Workflow Engine. To activate it, reinstall the relevant ticketing integration and enable the Workflow Engine feature.

MOOG-12088

A new Moobot file WorkflowEngine.js contains functions for Workflow Engine Moolets.

MOOG-11928

The following Graze API endpoints and MoogDb methods have been created for the Workflow Engine:

  • createWorkflow

  • deleteWorkflow

  • getWorkflows

  • getWorkflowEngineMoolets

  • reorderWorkflows

  • updateWorkflows

MOOG-11070, MOOG-9842, MOOG-12129

The following Graze API endpoints and MoogDb methods have been added:

  • getResolvingThreadEntries returns the resolving entries for a given Situation and optional sort parameters.

  • setResolvingThreadEntry sets or unsets a thread entry as resolving for a specified entry ID and resolving_step.

  • getTopPrcDetails retrieves the top most likely causal alerts, based on their Probable Root Cause value, for a specified Situation ID.

  • getAlertActions can be used to retrieve actions on alerts.

The following changes to existing endpoints and methods have been made:

  • addThreadEntry has a new resolving_step parameter that marks the entry as resolving.

  • getThreadEntries now returns entry_id.

MOOG-12103, MOOG-12017

The following functions have been added:

  • Bot.isActive(mooletName) returns true if there is an active Moolet with the specified name. It can be used before sending a MooletInform to a Moolet.

  • Bot.getActiveMoolets returns a list of all active Moolets.

  • Bot.getType returns the type of a Moolet.

  • Bot.getMooletName returns the name of the Moolet to which a Moobot belongs.

  • Bot.getWorkflowEngine.getMessageType returns the Workflow Engine message type.

MOOG-11888

The Moolet Informs module allows you to pass messages between Moolets.

MOOG-11701

UI: The Visualize tab now shows diagrams of the alerts in a Situation according to how the Cookbook Recipe has clustered them. Clicking a node in the diagram displays the corresponding alert details.

MOOG-11673

UI: The Resolving Steps section of the Next Steps tab in Situation Room is now collapsible.

MOOG-12570

UI: The Individual Performance Insights feature is now GA. It is enabled by default under System Settings > Labs.

MOOG-12380

UI: Operators can now use a new grid when viewing Situation and alert lists. The new grid has improved performance, better scrolling, and is easier to use. Some actions, such as drag and select rows, and copy and paste, behave slightly differently in the new grid. This is an early access feature than can be enabled in System Settings > Labs > New Grid.

MOOG-10837

Filtering on custom_info lists is now possible for alerts and Situations. This was previously possible using String comparison and has been updated to treat the list as a proper object for increased performance.

The syntax for advanced filters uses the CONTAINS keyword. The following is an example for a custom_info column named servers.kingston:

  • custom_info.servers.kingston CONTAINS "kngstn::webserver::HR"

Only full matching is allowed which means that the whole value in the filter must appear in the list. For example, the above filter requires the list to have a "kngstn::webserver::HR" element. It does not, for example, match "kngstn::webserver". Quotes are optional for both strings and number values. Note that no brackets are allowed around the filter value.

For this feature to work, the custom_info column (in this example, servers.kingston) must be added as a filterable column. This can be done in the UI, under System Settings > Alert / Situation Columns, or via the utilities: moog_add_alert_custom_info_field and moog_add_situation_custom_info_field. The column type must be a list (UI) or JSON (utility).

MOOG-12618

The historic database schema can now be queried as follows:

  • moog_mysql_client -i

  • moog_mysql_client --historic

MOOG-12477

The moog_db_validator utility can now validate the historic_moogdb database as well as moogdb, and moog_reference.

INT-4891

Signatures longer than 746 characters are now hashed at the alert level. Hashing in LAMbots is no longer required. The hashed signature length is 40 characters.

The hashing algorithm used is SHA1 rather than Java's hashcode. This vastly reduces the likelihood of signature collision.

INT-4854

Microsoft Teams is a new collaboration integration which enables you to manually send messages about alerts and Situations to one or more Teams channels.

INT-4828

The New Relic integrations and LAMs have been reorganised into the following:

The polling LAMs are separate to reflect the two separate New Relic APIs. New Relic Polling now requires a URL to support EU Datacentre.

INT-4829

The Programmatic LAM is a new custom polling LAM. It is an advanced version of the REST Client LAM. The REST Client LAM accepts a single API call and parses the responses it receives into Moogsoft AIOps events. The Programmatic LAM can accept multiple calls but you must define the processing yourself in the LAMbot using JavaScript.

INT-4633

Proxy support has been added for the following polling LAMs:

  • CA Spectrum

  • Datadog Polling

  • Email

  • New Relic Polling and New Relic Insights Polling

  • REST Client

  • SevOne

  • SolarWinds

  • VMware vCenter

  • VMware vSphere

  • Zabbix Polling

  • Zenoss

INT-4438

Two new configuration properties are available for polling LAMs: max_lookback and recovery_interval. They allow you to specify how to recover events that were missed during a connection outage. The properties can be configured for the following LAMs:

  • AWS CloudWatch

  • CA Spectrum

  • Datadog Polling

  • Email

  • New Relic Polling and New Relic Insights Polling

  • REST Client

  • SevOne

  • SolarWinds

  • VMware vRealize Log Insight

  • VMware vSphere

  • Zabbix Polling

The LAM switches to recovery mode if either of the following conditions are met:

  • The last successful poll time is more than double the request_interval.

  • The connection to the server is lost and then re-established in a later poll.

When a LAM is in recovery mode, it polls more often but uses the regular request_interval as the window in which to receive events. This allows all missed events to be recovered slowly in order of occurrence.
In this section: