Alarmes

Une alarme surveille un objet et tout ce qu'il contient. Quand un événement du type choisi se produit sur un objet de la portée, l'alarme pose un état sur cet objet : Avertissement (jaune) ou Critique (rouge), ou vert quand elle est réinitialisée. Chaque changement d'état est enregistré comme l'événement AlarmStatusChangedEvent, et une alarme peut aussi l'envoyer aux abonnés de webhooks. Définir des alarmes demande Alarm.Create sur la portée.

Dans la console

Définir une alarme

1. Ouvrez la page d'accueil (Accueil) et sélectionnez Définitions d’alarme sous Raccourcis. Depuis la liste des alarmes déclenchées, le lien Gérer les définitions d’alarme mène à la même page.

:::screen alarm-definitions

Le tableau montre chaque alarme avec son Déclencheur, sa Périmètre, ses Actions, le nombre d'objets déclenchés et son état activé ou non.

2. Sélectionnez Nouvelle alarme. Saisissez le Nom, 80 caractères au plus, et si vous le souhaitez une Description.
3. Choisissez la Périmètre : Tout, ou un datacenter, un cluster, un hôte, un datastore ou un dossier. L'alarme surveille cet objet et tout ce qu'il contient.
4. Choisissez le Type de déclencheur.
   • Pour Un événement se produit, saisissez le Type d’événement tel que la liste des événements l'affiche, par exemple HostConnectionLostEvent, et choisissez le État à fixer.
   • Pour Une métrique franchit un seuil, choisissez la Métrique, puis si l'alarme est levée quand la valeur est au-dessus du seuil ou en dessous du seuil, et saisissez le Seuil d’avertissement et le Seuil critique. Le seuil critique ne doit pas être inférieur au seuil d'avertissement pour une alarme au-dessus, et pas supérieur pour une alarme en dessous.
5. Sous Actions au déclenchement de l’alarme, laissez Enregistrer un événement cochée pour écrire le changement dans le journal des événements, et cochez une étiquette de webhook pour envoyer le changement aux webhooks qui la portent. Choisissez au moins une action. Une étiquette est ajoutée à un webhook à sa création ; consultez les webhooks.
6. Laissez L’alarme est activée cochée.

:::screen alarm-definition-create

7. Sélectionnez Créer l’alarme.

Modifier et Supprimer dans une ligne modifient et suppriment une alarme ; la suppression retire aussi ses états déclenchés, et personne n'est plus notifié à leur sujet. La modification remplace la définition ; les états restent, sauf si le déclencheur ou la portée change.

Un déclencheur de métrique est stocké avec ses seuils, mais le contrôleur ne l'évalue pas encore sur les échantillons de performance. Prévu Utilisez un déclencheur d'événement pour une alarme qui fonctionne aujourd'hui.

Acquitter et réinitialiser les alarmes déclenchées

1. Sélectionnez Alarmes sur la page d'accueil, ou ouvrez l'onglet Alarmes dans le volet en bas de la page. La page d'accueil montre les alarmes que personne n'a encore acquittées.

:::screen alarms

Le tableau Alarmes déclenchées liste Gravité, Alarme, Objet, Déclenchée et Acquittée.

2. Cochez une ou plusieurs lignes et sélectionnez Acquitter pour indiquer que quelqu'un s'en occupe. L'alarme reste déclenchée.
3. Sélectionnez Réinitialiser au vert pour remettre au vert toutes les alarmes déclenchées. Cela efface aussi l'acquittement.

Une alarme ne revient pas au vert d'elle-même. Réinitialisez-la quand la cause a disparu.

Résultat

L'alarme figure dans la liste des définitions. Quand un événement de son type se produit sur un objet de la portée, l'objet est listé sous Alarmes avec l'état choisi, et les actions s'exécutent. Kyvernon n'évalue pas à nouveau les événements que ses propres alarmes produisent, donc les alarmes ne peuvent pas se déclencher entre elles.

Automatisation

Avec la CLI

Écrivez la définition dans un fichier JSON, alarm.json. Cette alarme passe un objet au rouge quand un hôte se déconnecte et envoie le changement aux webhooks qui portent l'étiquette ops-pager :

{
  "name": "Host disconnected",
  "scopeId": "group-d1",
  "enabled": true,
  "trigger": { "type": "event", "event_type": "HostDisconnectedEvent", "status": "red" },
  "actions": [ { "type": "event" }, { "type": "webhook", "label": "ops-pager" } ]
}

kyvernon alarms create --body-file alarm.json
kyvernon alarms update <alarm-id> --disable
kyvernon alarms list
kyvernon alarms acknowledge <alarm-id> host-3
kyvernon alarms clear-triggered --status red

scopeId est l'objet que l'alarme surveille, avec tout ce qu'il contient ; group-d1 est le dossier racine. clear-triggered remet au vert tous les états non verts, ou seulement les états ayant les statuts donnés.

Avec l'API

POST /v1/alarms définit une alarme, GET /v1/alarms et GET /v1/alarms/{id} les lisent, PUT /v1/alarms/{id} remplace une définition avec le corps de création, et DELETE /v1/alarms/{id} en supprime une avec Alarm.Delete sur la portée. POST /v1/alarms/{id}/acknowledge avec targetId demande Alarm.Acknowledge sur l'objet, et POST /v1/alarms/clear-triggered avec statuses demande Alarm.SetStatus. Le service gRPC AlarmService liste et acquitte les alarmes.

Voir aussi

• Les événements listent les types d'événements.
• Les webhooks livrent les changements d'alarme à d'autres systèmes.
• Le dépannage des identités explique les messages d'erreur pour privilèges manquants.