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.
| 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.
| Feature | Prior API | Current API | Notes |
|---|---|---|---|
| Alert priorities | Not supported
API uses |
Supported
The |
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 |
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:
priorityis a new field added to the payload under the parentdatafield. This supports the change fromseveritytopriority. There is no change to theseverityfield in the Event Notification payload. The value of the Event Notificationseverityfield will be mapped as explained in Change from alert severity to priorityversioned_idis a new field added to the payload. This is the ID which is generated when the alert is updated.- The
idfield contains theunique_identfiervalue of the alert. This ID is generated when the alert is created and remains unchanged.
For more details, see: