IBM Cloud Docs
IBM Cloud Logs considerations for new alert and priority configuration

IBM Cloud Logs considerations for new alert and priority configuration

IBM® Cloud Logs has made changes to the configuration and processing of alerts and how alert priorities are defined. These changes might impact any automation configured for your environment.

Change from alert severity to priority

With the latest IBM Cloud Logs release, IBM Cloud Logs has changed the alert configuration from using a series of 4 alert severities to 5 alert priorities.

Mapping of old alert severity values to new priority values
Severity Priority
Critical P1
Error P2
Warning P3
Info [*] P4
Info P5

[*] - There is no equivalent severity value for priority P4. P4 is logically mapped as Info along with P5.

Any existing automation (API or Terraform) in your environment can continue using the old severity values and they will be mapped to the new priority values. However, to take advantage of all new alert API functionality, you will want to update your automation to use the new API.

Alert configuration changes made by using the UI

With the latest IBM Cloud Logs changes, configuring alerts in the UI and API has changed and added additional functionality including:

If you configure alerts using the IBM Cloud Logs Alerts Management page, any changes you make to an existing alert will automatically be upgraded to the latest functionality. This includes changing how the alert is configured in the API.

Because alerts are automatically upgraded, if you have any APIs, Terraform, or other automation referencing the updated alerts, you will need to update the automation to meet the new alert API definition.

Changes to API support for alerting

The latest IBM® Cloud Logs version also includes changes to the IBM® Cloud Logs alerts API.

The following table outlines the key changes between the previous and the current API. This information will help you understand the capabilities and limitations of each version when creating, updating, or querying alerts.

Differences between the prior and current API
Feature Prior API Current API Notes
Alert priorities Not supported

API uses severity instead.

Supported

The priority value replaces the old severity value.

The prior API does not recognize the P1-P5 priority values. Alerts with these values can result in the prior API not being able to process alerts with priority values.
Multi-condition alerts Not supported

Only one rule is supported per alert.

Supported The prior API will ignore any extra rules defined in an alert.
Customizing the evalution window Not supported Supported The evaluationDelay field will be ignored by the prior API.
Anomaly detection alert sensitivity Not supported Supported The prior API cannot interpret or trigger alerts based on deviation percentages.
Dynamic duration Supported

Supported with evaluationWindow.

Not supported

Replaced by rolling evaluation window.

If an alert configured in the prior API is processed by the current API, the evaluationWindow will be processed as a rolling evaluation window.

Changes to the Event Notifications payload

The latest IBM® Cloud Logs version includes changes in the IBM Cloud Event Notifications payload. Your existing Event Notifications configuration and payload will continue to work unchanged. Changes are only required if you want to take advantage of the new functionality.

The following new fields are available:

  • priority is a new field added to the payload under the parent data field. This supports the change from severity to priority. There is no change to the severity field in the Event Notification payload. The value of the Event Notification severity field will be mapped as explained in Change from alert severity to priority
  • versioned_id is a new field added to the payload. This is the ID which is generated when the alert is updated.
  • The id field contains the unique_identfier value of the alert. This ID is generated when the alert is created and remains unchanged.

For more details, see: