Nous sommes heureux d'annoncer que nous avons publié la nouvelle version de PagerDuty, qui prend en charge plusieurs incidents. Pour l'essayer, connectez-vous simplement à votre compte PagerDuty .

Cette nouvelle fonctionnalité corrige une simplification excessive dans la conception de PagerDuty : jusqu'à présent, PD nécessitait de créer une nouvelle alarme pour chaque type de problème que vos systèmes de surveillance sont capables de détecter. Malheureusement, cela ne fonctionne pas très bien si vous utilisez un outil de surveillance comme Nagios, qui peut surveiller des milliers d'hôtes et de services à la fois. La nouvelle version peut désormais gérer plusieurs incidents ouverts à partir d'un seul système de surveillance ; nous appelons cela la « prise en charge multi-incidents ».

Voici un bref résumé des changements apportés à la nouvelle version :

• Les alarmes ont été renommées en Services.
• Les groupes d’alarmes ont été renommés en stratégies d’escalade.
• Les services peuvent désormais suivre plusieurs incidents ouverts à la fois.
• L’incident « suppression » a été renommé « reconnaissance ».
• La durée pendant laquelle un incident reste reconnu est désormais configurable service par service

La nouvelle version de PD est 100 % rétrocompatible avec la version précédente. Oui, nous avons renommé un certain nombre de choses, mais nous avons pris grand soin de conserver le même comportement que l'ancienne version pour vos services existants. Lisez la suite pour plus de détails.

Le grand changement : le support multi-incidents

PagerDuty est désormais capable de suivre plusieurs incidents ouverts simultanément. En d'autres termes, votre système de surveillance peut signaler à PagerDuty environ 100 problèmes simultanés et indépendants sans que vous ayez besoin de créer 100 alarmes PagerDuty (comme c'était le cas dans l'ancienne version de PD).

PagerDuty utilise désormais les « incidents » plutôt que les « alarmes » comme objet principal. Votre équipe d'assistance reconnaîtra, signalera et résoudra les incidents, au lieu des alarmes. Les incidents dans PagerDuty sont similaires aux tickets dans un système de suivi de bogues : ils sont créés lorsqu'un problème est détecté et sont résolus ou fermés lorsque le problème est résolu.

Étant donné que PagerDuty peut désormais gérer des centaines d'incidents ouverts à la fois, nous avons essayé de concevoir soigneusement l'interface de PagerDuty pour faciliter le travail avec de grandes collections d'incidents. Les nouveaux onglets Incidents et Tableau de bord comportent des tableaux qui vous permettent de voir en un coup d'œil tous les incidents ouverts qui vous sont attribués. Vous pouvez également trier facilement vos incidents directement à partir de ces pages à l'aide des commandes situées en haut du tableau.

Activation de la prise en charge multi-incidents pour vos services PagerDuty

Par défaut, les services PagerDuty fonctionnent toujours de la même manière qu'ils ont toujours fonctionné : ils ne peuvent ouvrir qu'un seul incident à la fois. La raison en est de maintenir la compatibilité ascendante.

Vous pouvez activer la prise en charge multi-incidents pour n'importe quel service existant. Voici comment procéder :

1. Cliquez sur l’onglet « Services », puis sur le lien « Modifier » (sous Actions) pour le service que vous souhaitez modifier.
2. Dans la section « Paramètres d'intégration de messagerie », vous verrez 3 options :
   • Ouvrir un nouvel incident pour chaque e-mail déclencheur
   • Ouvrir un nouvel incident pour chaque nouvel objet d'e-mail déclencheur
   • Ouvrir un nouvel incident uniquement s'il n'existe pas déjà d'incident ouvert

   
   La première option, si elle est sélectionnée, amènera le service à ouvrir un nouvel incident pour chaque e-mail de déclenchement envoyé à l'adresse e-mail du service.

   La deuxième option, si elle est sélectionnée, amènera le service à ouvrir un nouvel incident en fonction de l'objet de l'e-mail : si un incident ouvert avec le même objet existe déjà, l'e-mail est ajouté à cet incident ; sinon, un nouvel incident est créé.

   La troisième option, qui doit être sélectionnée par défaut pour un service existant, permet à un service de conserver le comportement de l'ancienne version de PagerDuty. Cela désactive essentiellement la prise en charge de plusieurs incidents : si cette option est sélectionnée, le service ne peut avoir qu'un seul incident ouvert à la fois. Lorsque le service reçoit un e-mail de déclenchement, il ouvre un nouvel incident si le service n'a pas déjà d'incident ouvert ; sinon, il ajoute l'e-mail à l'incident ouvert.

3. Pour activer la prise en charge multi-incident, sélectionnez la première ou la deuxième option.
4. Cliquez sur « Enregistrer les modifications » en bas de la page et vous avez terminé.

Les alarmes sont désormais des services

Nous avons renommé « alarmes » en « services ». Les services sont désormais utilisés uniquement pour représenter un point d'intégration entre PagerDuty et vos services de surveillance. Actuellement, les services PagerDuty s'intègrent à vos systèmes de surveillance via l'intégration de la messagerie électronique (tout comme dans l'ancienne version de PD). Dans les semaines à venir, nous ajouterons également la prise en charge d'une API basée sur HTTP pour les services PagerDuty . Cela permettra à vos systèmes de surveillance de déclencher/reconnaître/résoudre des incidents dans PagerDuty via un appel API synchrone.

Pour des raisons similaires, nous avons renommé « groupes d'alarmes » en « stratégies d'escalade ». Nous pensons que le nouveau nom reflète mieux l'utilisation de ces objets.

La « suppression » d’un incident est désormais une « reconnaissance » d’un incident

Nous avons également renommé la « suppression » de l'incident en « acquittement ». Comme auparavant, cette fonctionnalité est utilisée pour empêcher temporairement un incident de générer des alertes. Nous avons pensé que le mot « acquittement » reflétait mieux l'objectif de la fonctionnalité : « Arrêtez de m'embêter avec ce problème pour l'instant… J'y travaille ! ».

Nous avons également rendu le délai d'expiration de l'accusé de réception configurable service par service. Cela signifie que vous pouvez définir la durée pendant laquelle un incident reste à l'état Acquitté, avant de revenir à l'état Déclenché et de vous alerter à nouveau. Le délai d'expiration est fixé à 30 minutes par défaut pour chaque service, mais vous pouvez le modifier ou même le désactiver facilement :

1. Cliquez sur l’onglet « Services », puis sur le lien « Modifier » (sous Actions) pour le service que vous souhaitez modifier.
2. Dans la section « Paramètres d'incident », vous verrez une entrée pour le « Délai d'expiration de l'accusé de réception de l'incident ».

   

3. Par défaut, le délai d'expiration est défini sur « 30 minutes ». Pour modifier le délai d'expiration, cliquez sur et modifiez la valeur de cette liste déroulante. Vous pouvez également désactiver complètement le délai d'expiration en décochant la case à cocher intitulée « Activer un délai d'expiration pour les incidents laissés dans l'état Reconnu pendant trop longtemps ». Nous vous recommandons de laisser le délai d'expiration activé, pour vous assurer de ne pas oublier les incidents dans l'état Reconnu.
4. Cliquez sur « Enregistrer les modifications » en bas de la page et vous avez terminé.

Et après?

La prochaine étape est la prise en charge d'une API PagerDuty . Cela facilitera l'intégration de PagerDuty aux outils de surveillance populaires tels que Nagios, Zenoss, monit, Munin et bien d'autres. L'API permettra à votre système de surveillance de déclencher, reconnaître et résoudre des incidents directement dans PagerDuty, via un appel synchrone à l'API.