Utilisation des alertes et des événements

Dans le service IBM Cloud Monitoring, vous pouvez configurer des alertes à conditions multiples ou uniques pour signaler les problèmes qui peuvent requérir votre attention. Lorsqu'une alerte est déclenchée, vous pouvez en être averti par le biais d'un ou plusieurs canaux de notification. Une définition d'alerte peut générer des notifications multicanaux.

Une alerte est un événement de notification que vous pouvez utiliser pour avertir de situations qui requièrent votre attention. Chaque alerte possède un statut de gravité. Ce statut vous informe de l'importance des informations qu'elle signale.

Lorsque vous définissez une alerte, vous devez définir la condition qui déclenche la notification, et un ou plusieurs canaux de notification par le biais desquels vous voulez être averti. Vous devez également définir la gravité de l'alerte et le type d'alerte. Pour plus d'informations sur la configuration d'une alerte, voir Configuration d'une alerte.

Par défaut, le niveau de gravité est défini sur warning (avertissement). Vous pouvez définir la gravité d'une alerte sur l'une des valeurs suivantes : emergency (urgence), alert (alerte), critical (critique), error (erreur), warning (avertissement), notice (avis), informational (information), debug* (débogage)

Vous pouvez définir une alerte sur une ou plusieurs métriques afin de signaler les événements ou les problèmes que vous souhaitez surveiller.

  • Vous pouvez définir une alerte à condition unique.
  • Vous pouvez définir une alerte à conditions multiples. Le seuil d'alerte est configuré par le biais de conditions complexes.
  • Vous pouvez définir la façon dont les données sont agrégées.
  • Vous pouvez utiliser la logique booléenne pour définir des alertes qui concernent plusieurs métriques.
  • Vous recevez une notification lorsque la condition d'alerte est remplie.
  • Vous pouvez configurer plusieurs canaux de notification par alerte.
  • Les alertes s'exécutent une minute ou moins après la réception. Il est aussi possible de configurer le délai d'attente du déclenchement en heures ou en jours.
  • Pour les alertes PromQL uniquement, vous pouvez configurer un délai d'attente de 0 minute.

Vous pouvez activer des alertes prédéfinies, modifier des alertes et créer des alertes personnalisées dans l'interface utilisateur Web et à l'aide de l'API IBM Cloud Monitoring.

Vous pouvez gérer des alertes dans la vue Alerts de l'interface utilisateur Web. Vous pouvez configurer les colonnes du tableau qui sont affichées dans la vue Alerts. Les options de colonne valides sont Nom, Portée, Alerte quand, Segmenter par, Notifications, Activé, Modifié, Captures, Canaux, Créé, Description, Destinataires du courrier électronique, Pour au moins, OpsGenie, PagerDuty, Sévérité, Slack, WebHook, Type, et VictorOps.

Types d'alerte

Le service IBM Cloud Monitoring inclut des alertes prédéfinies que vous pouvez activer. De plus, vous pouvez configurer des alertes personnalisées à partir des panneaux d'un tableau de bord, à l'aide de l'API REST ou dans la section Alertes de l'interface utilisateur Web.

Dans le service IBM Cloud Monitoring, vous pouvez définir l'un des types d'alerte suivants :

  • Indisponibilité : Ce type d'alerte permet de surveiller des sources, telles qu'un serveur bare metal, et de signaler quand elles sont arrêtées.

  • Métrique : Ce type d'alerte permet de surveiller les métriques de série temporelle et de lancer une alerte lorsqu'elles atteignent les seuils définis.

  • PromQL : Ce type de métrique permet de surveiller les métriques à l'aide d'une requête PromQL.

  • Evénement : Ce type d'alerte permet de surveiller les occurrences d'événements spécifiques et de lancer une alerte lorsqu'elles atteignent les seuils définis. Il peut être utilisé par exemple pour surveiller quand un certain nombre de demandes d'accès non autorisées sont signalées.

  • Détection d'anomalie : Ce type d'alerte permet de surveiller les hôtes en fonction de comportements historiques et de lancer une alerte lorsqu'ils ne sont pas conformes au schéma attendu.

    Ce type d'alerte est obsolète. Vous ne pouvez gérer que les alertes existantes de ce type.

  • Valeur extrême de groupe : Ce type d'alerte permet de surveiller les hôtes et de recevoir une notification lorsque l'un d'eux se comporte différemment des autres.

    Ce type d'alerte est obsolète. Vous ne pouvez gérer que les alertes existantes de ce type.

Canaux de notification

Un canal de notification définit l'emplacement où vous souhaitez recevoir les informations lorsqu'une alerte est déclenchée.

Lorsque vous configurez une alerte, vous pouvez spécifier un ou plusieurs canaux de notification.

Par défaut, lorsqu'une alerte est déclenchée, vous recevez une notification dans la section Evénements.

Vous pouvez configurer les canaux de notification suivants :

  • Adresse électronique
  • IBM Event Notifications
  • Microsoft Teams
  • OpsGenie
  • PagerDuty
  • Slack
  • Teams Email
  • VictorOps
  • WebHook

Evénements

Un événement est une notification qui vous informe sur un fait qui se produit dans l'un des noeuds qui transmettent les données à votre instance Monitoring. Utilisez des événements pour passer en revue, suivre et résoudre les problèmes.

La liste suivante décrit les différents types d'événement :

  • Les événements d'alerte sont des événements qui sont déclenchés par des alertes configurées par l'utilisateur.
  • Les événements d'infrastructure sont des événements qui sont collectés à partir de noeuds Kubernetes et Docker. Par défaut, l'agent de surveillance reconnaît et collecte automatiquement les données provenant d'un groupe d'événements spécifique. Vous pouvez éditer le fichier de configuration de l'agent pour activer davantage d'événements.
  • Les événements personnalisés que vous configurez via les intégrations suivantes : Slackbot, scripts Python préconfigurés, scripts Python personnalisés créés par l'utilisateur, ou demandes cURL.

Par défaut, un événement a un état :

  • Actif : cet état indique que les circonstances qui ont déclenché l'événement demeurent, par exemple, un noeud continue à être en panne.
  • OK : cet état indique que la situation est revenue à la normale, par exemple, un noeud est opérationnel.

Vous pouvez gérer des événements dans la section Events de l'interface utilisateur Web.

  • Vous pouvez afficher des événements d'alerte via l'onglet Alert Events.
  • Vous pouvez afficher des événements basés sur l'infrastructure via l'onglet Custom events.
  • Vous pouvez afficher des événements personnalisés via l'onglet Custom events.
  • Vous pouvez envoyer des événements personnalisés à l'une de vos équipes à l'aide du jeton d'API pour cette équipe. Pour plus d'informations, voir événements personnalisés).
  • Vous pouvez définir l'événement comme Resolved afin d'indiquer aux autres utilisateurs que le problème a été traité, plutôt que d'attendre que le statut soit défini sur OK.