Aller au contenu
Docs

Incidents

Sur cette page
  1. Quand un incident s'ouvre et se ferme
  2. Sévérité
  3. Prendre en charge un incident
  4. La page d'un incident
  5. La page des incidents
  6. Voir aussi

Un incident est la trace d'un problème détecté par une sonde : il indique ce qui a échoué, depuis quand, qui a été notifié et ce que l'équipe a fait. C'est par les incidents que vous commencez quand quelque chose ne va pas — ouvrez-les depuis Monitoring → Incidents, depuis une notification ou depuis l'application mobile.

Quand un incident s'ouvre et se ferme#

Cycle de vie d'un incident Un incident s'ouvre au premier contrôle en échec et se résout au premier contrôle réussi. La prise en charge est facultative : elle indique qui s'en occupe, avec un commentaire, et n'envoie aucune notification. OuvertPremier contrôle en échecNotification envoyéePris en chargeFacultatif, avec commentaireAucune notificationRésoluPremier contrôle réussiNotification de rétablissementLe contrôle se rétablit avant toute prise en charge
Un incident s'ouvre au premier contrôle en échec et se résout au premier contrôle réussi. La prise en charge est facultative : elle indique qui s'en occupe, avec un commentaire, et n'envoie aucune notification.
  • Il s'ouvre au premier contrôle en échec. Il n'y a ni nouvelle tentative ni délai d'attente : dès qu'un contrôle échoue, l'incident s'ouvre avec l'heure de ce contrôle, et les intégrations liées à la sonde sont notifiées. Les sondes Serveur font exception : elles n'ouvrent un incident que lorsqu'une ressource reste au-dessus de son seuil pendant la durée configurée.
  • Il reste ouvert tant que le problème dure. Onagre n'envoie pas de rappels : une notification à l'ouverture, une à la fermeture.
  • Il se ferme au premier contrôle réussi. L'incident est résolu automatiquement, sa durée est enregistrée, et une notification de rétablissement part vers les mêmes intégrations. Il n'y a rien à fermer à la main.

Une sonde a au plus un incident ouvert à la fois. Supprimer une sonde ferme son incident ouvert (« Closed — resource deleted ») ; la mettre en pause, ou une fenêtre de maintenance, arrête les contrôles et laisse donc un incident ouvert jusqu'à la reprise des contrôles.

Sévérité#

Chaque incident porte la sévérité de sa sonde : Critical, Major, Minor ou Info. Elle se règle sur la sonde (Schedule and severity) et permet de trier et filtrer les incidents par importance. Elle ne change pas qui est notifié : c'est le rôle de l'alerting de la sonde.

Prendre en charge un incident#

Prendre en charge un incident, c'est dire à l'équipe « Je m'en occupe ». Cliquez sur Acknowledge sur un incident ouvert et indiquez ce que vous faites dans What are you doing about it? (au moins 5 caractères).

Prendre en charge demande un commentaire : l'équipe sait qui s'en occupe et ce qui est fait.

L'incident passe à Acknowledged et votre commentaire rejoint son activité. La prise en charge n'arrête pas les contrôles, ne résout pas l'incident et n'envoie aucune notification : l'incident se ferme toujours de lui-même lorsque le contrôle réussit. Elle évite simplement que deux personnes enquêtent sur le même problème sans le savoir.

Prendre en charge et commenter nécessitent le rôle User. Depuis l'application mobile, la prise en charge ajoute le commentaire « Acknowledged from mobile ».

La page d'un incident#

Détail d'un incident critique résolu sur PostgreSQL primary : l'erreur de la base, le début de la chronologie, et les panneaux de détails et de notifications.
La page d'un incident réunit ce qui a échoué, quand, sur quel agent, et qui a été prévenu.
  • En-tête — la sonde, le statut (Open, Acknowledged ou Resolved), la sévérité, l'heure d'ouverture et la durée écoulée. View resource ouvre la sonde.
  • What happened — l'erreur remontée par le contrôle : un statut HTTP, un délai dépassé, une erreur de base de données, une valeur inattendue…
  • Details — statut, sévérité, durée, heures d'ouverture et de résolution, sonde, agent et tags.
  • Activity — tout ce qui s'est passé, dans l'ordre : l'échec, chaque notification envoyée (ou en échec), la prise en charge, les commentaires de l'équipe, la résolution.
  • Notifications — chaque intégration notifiée, marquée Sent ou Failed.
  • Dependencies — les autres sondes qui dépendent de celle en échec, avec leur état actuel, pour évaluer l'impact.
Activité d'un incident : la prise en charge par Hugo Moreau avec son commentaire, les commentaires de l'équipe, puis la résolution et les notifications envoyées.
L'activité garde toute l'histoire : prise en charge, commentaires de l'équipe, résolution et chaque alerte envoyée.

Toute personne ayant le rôle User peut ajouter un commentaire — avancement, constats, lien vers le post-mortem — à tout moment, y compris après la résolution.

La page des incidents#

Monitoring → Incidents couvre les 30 derniers jours.

Page Incidents : un incident ouvert, un pris en charge et 45 résolus avec 99,98 % de disponibilité, un graphique des incidents par gravité sur 30 jours, et les MTTA, MTTR et MTBF.
Le haut de la page Incidents : la situation du moment, l'évolution sur 30 jours et la réactivité de l'équipe.
  • Open, Acknowledged, Resolved et Uptime sur l'ensemble des sondes.
  • Incidents over time — incidents par jour, par sévérité.
  • Response times — les moyennes de l'équipe sur 30 jours :
    • MTTA, délai de prise en charge : de l'ouverture à la prise en charge ;
    • MTTR, délai de résolution : de l'ouverture à la résolution ;
    • MTBF, temps entre pannes : la fréquence à laquelle les sondes échouent.
  • Longest downtime et Most incidents — les cinq sondes qui ont le plus souffert.

La liste en dessous peut être filtrée par statut (All, Open, Acknowledged, Resolved), par sévérité et par nom de sonde, 10, 25 ou 50 par page.

Liste des incidents avec les onglets de statut (All, Open, Acknowledged, Resolved), la recherche par ressource, le filtre de gravité et, par ligne, la raison, la gravité, le statut et la durée.
Les onglets de statut, la recherche et le filtre de gravité réduisent la liste à ce que vous cherchez.

Voir aussi#