IBM Cloud Logs considérations relatives à la nouvelle configuration des alertes et des priorités

IBM® Cloud Logs a apporté des modifications à la configuration et au traitement des alertes, ainsi qu'à la définition des priorités des alertes. Ces changements peuvent avoir un impact sur l'automatisation configurée pour votre environnement.

Passer de la gravité de l'alerte à la priorité

Avec la dernière version de IBM Cloud Logs, IBM Cloud Logs a modifié la configuration des alertes en passant d'une série de 4 niveaux de gravité à 5 priorités d'alerte.

Correspondance entre les anciennes valeurs de gravité des alertes et les nouvelles valeurs de priorité
Gravité	Priorité
`Critical`	`P1`
`Error`	`P2`
`Warning`	`P3`
`Info` `[*]`	`P4`
`Info`	`P5`

[*]- Il n'y a pas de valeur de gravité équivalente pour la priorité P4. P4 est logiquement mappé comme Info avec P5.

Toute automatisation existante (API ou Terraform) dans votre environnement peut continuer à utiliser les anciennes valeurs de gravité et elles seront mappées aux nouvelles valeurs de priorité. Toutefois, pour tirer parti de toutes les nouvelles fonctionnalités de l'API d'alerte, vous devrez mettre à jour votre automatisation afin d'utiliser la nouvelle API.

Alerte sur les changements de configuration effectués à l'aide de l'interface utilisateur

Avec les dernières modifications apportées à IBM Cloud Logs, la configuration des alertes dans l'interface utilisateur et l'interface de programmation a changé et a ajouté des fonctionnalités supplémentaires :

Si vous configurez des alertes à l'aide de la page Gestion des alertes IBM Cloud Logs, toutes les modifications que vous apportez à une alerte existante seront automatiquement mises à niveau vers la dernière fonctionnalité. Il s'agit notamment de modifier la configuration de l'alerte dans l'API.

Étant donné que les alertes sont automatiquement mises à niveau, si vous disposez d’API, de Terraform ou d’autres automatisations référençant les alertes mises à jour, vous devrez mettre à jour l’automatisation pour répondre à la nouvelle définition d’API d’alerte.

Modifications de la prise en charge des alertes par l'API

La dernière version de IBM® Cloud Logs comprend également des modifications de l'API d'alertes de IBM® Cloud Logs.

Le tableau suivant présente les principaux changements entre l'API précédente et l'API actuelle. Ces informations vous aideront à comprendre les capacités et les limites de chaque version lors de la création, de la mise à jour ou de l'interrogation des alertes.

Différences entre l'API précédente et l'API actuelle
Fonction	API antérieure	API actuelle	Remarques
Priorités d'alerte	Non pris en charge L'API utilise `severity` à la place.	Prise en charge La valeur `priority` remplace l'ancienne valeur `severity`.	L'API précédente ne reconnaît pas les valeurs de priorité de `P1-P5`. Les alertes ayant ces valeurs peuvent entraîner l'impossibilité pour l'API précédente de traiter les alertes ayant des valeurs de priorité.
Alertes multi-conditionnelles	Non pris en charge Une seule règle est prise en charge par alerte.	Pris en charge	L'API précédente ignorera toute règle supplémentaire définie dans une alerte.
Personnalisation de la fenêtre d'évaluation	Non pris en charge	Pris en charge	Le champ `evaluationDelay` sera ignoré par l'API précédente.
Sensibilité des alertes en cas de détection d'anomalies	Non pris en charge	Pris en charge	L'API précédente ne peut pas interpréter ou déclencher des alertes basées sur des pourcentages d'écart.
Durée dynamique	Pris en charge Pris en charge avec `evaluationWindow`.	Non pris en charge Remplacé par une fenêtre d'évaluation roulante.	Si une alerte configurée dans l'API précédente est traitée par l'API actuelle, le site `evaluationWindow` sera traité comme une fenêtre d'évaluation continue.

Changements apportés à la charge utile Event Notifications

La dernière version de IBM® Cloud Logs comprend des changements dans la charge utile de IBM Cloud Event Notifications. La configuration et la charge utile de votre site Event Notifications continueront à fonctionner sans changement. Les modifications ne sont nécessaires que si vous souhaitez bénéficier de la nouvelle fonctionnalité.

Les nouveaux champs suivants sont disponibles :

priority est un nouveau champ ajouté à la charge utile sous le champ parent data. Cela confirme le passage de severity à priority. Le champ severity de la charge utile de la notification d'événement n'est pas modifié. La valeur du champ Event Notification severity sera mise en correspondance comme expliqué dans Change from alert severity to priority
versioned_id est un nouveau champ ajouté à la charge utile. Il s'agit de l'identifiant généré lors de la mise à jour de l'alerte.
Le champ id contient la valeur unique_identfier du signalement. Cet identifiant est généré lors de la création du signalement et reste inchangé.

Pour plus de détails, voir :