Blog

PagerDuty 2.0

par Alex Salomon 12 avril 2010 | 6 minutes de lecture

Nous sommes heureux d'annoncer la sortie de la nouvelle version de PagerDuty, compatible avec plusieurs incidents. Pour l'essayer, connectez-vous à votre compte PagerDuty .

Cette nouvelle fonctionnalité corrige une simplification excessive de la conception de PagerDuty : jusqu'à présent, PD nécessitait la création d'une alarme pour chaque type de problème détecté par vos systèmes de surveillance. Malheureusement, cela ne fonctionne pas très bien avec un outil de surveillance comme Nagios, capable de surveiller des milliers d'hôtes et de services simultanément. La nouvelle version permet désormais de gérer plusieurs incidents ouverts depuis un seul système de surveillance ; c'est ce que nous appelons 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é « accusé de réception ».
  • 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. Nous avons certes renommé plusieurs éléments, mais nous avons veillé à conserver le même comportement que l'ancienne version pour vos services existants. Pour en savoir plus, lisez la suite.

Le grand changement : le support multi-incidents

PagerDuty est désormais capable de suivre plusieurs incidents simultanés ouverts. Autrement dit, votre système de surveillance peut signaler à PagerDuty environ 100 problèmes simultanés et indépendants sans que vous ayez à 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 de support accusera réception, transmettra et résoudra les incidents, plutôt que les alarmes. Dans PagerDuty , les incidents sont similaires aux tickets d'un système de suivi des bugs : ils sont créés lorsqu'un problème est détecté et résolus ou clôturés une fois le problème résolu.

Puisque PagerDuty peut désormais gérer des centaines d'incidents ouverts simultanément, nous avons soigneusement conçu son interface pour faciliter la gestion de grands groupes d'incidents. Les nouveaux onglets « Incidents » et « Tableau de bord » proposent des tableaux qui vous permettent de visualiser d'un coup d'œil tous les incidents ouverts qui vous sont attribués. Vous pouvez également trier facilement vos incidents directement depuis ces pages grâce aux commandes situées en haut du tableau.

Incidents tab

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

Par défaut, les services PagerDuty fonctionnent toujours comme avant : ils ne peuvent ouvrir qu'un seul incident à la fois. Ceci afin de garantir la rétrocompatibilité.

Vous pouvez activer la prise en charge multi-incidents pour tout service existant. Voici comment :

  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 si un incident ouvert n'existe pas déjà

    Email integration settings
    La première option, si elle est sélectionnée, entraînera l'ouverture par le service d'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, entraî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 à ce dernier de conserver le comportement de l'ancienne version de PagerDuty. Elle désactive la prise en charge multi-incidents : si elle est sélectionnée, le service ne peut avoir qu'un seul incident ouvert à la fois. Lorsqu'il reçoit un courriel de déclenchement, il ouvre un nouvel incident s'il n'en a pas déjà un ; sinon, il ajoute le courriel à l'incident ouvert.

  3. Pour activer la prise en charge multi-incidents, 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 servent désormais uniquement à 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 par e-mail (comme dans l'ancienne version de PD). Dans les prochaines semaines, nous ajouterons également la prise en charge d'une API HTTP pour les services PagerDuty . Cela permettra à vos systèmes de surveillance de déclencher, d'acquitter et de résoudre les 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 ce 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 » des incidents en « acquittement ». Comme auparavant, cette fonctionnalité permet d'empêcher temporairement un incident de générer des alertes. Nous avons pensé que le terme « acquittement » reflétait mieux l'objectif de la fonctionnalité : « Arrêtez de m'importuner 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. Vous pouvez ainsi définir la durée pendant laquelle un incident reste à l'état « Accusé » avant de repasser à l'état « Déclenché » et de vous alerter à nouveau. Ce délai est fixé par défaut à 30 minutes 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 ».

    Incident ack timeout

  3. Par défaut, le délai d'expiration est fixé à 30 minutes. Pour le modifier, cliquez sur ce menu déroulant et modifiez sa valeur. Vous pouvez également désactiver le délai d'expiration en décochant la case « Activer un délai d'expiration pour les incidents laissés à l'état « Acquitté » trop longtemps. Nous vous recommandons de laisser le délai d'expiration activé afin de ne pas oublier les incidents à l'état « Acquitté ».
  4. Cliquez sur « Enregistrer les modifications » en bas de la page et vous avez terminé.

Quelle est la prochaine étape ?

La prochaine étape concerne la prise en charge d'une API PagerDuty . Celle-ci facilitera l'intégration de PagerDuty avec des outils de surveillance courants tels que Nagios, Zenoss, monit, Munin et bien d'autres. L'API permettra à votre système de surveillance de déclencher, d'acquitter et de résoudre les incidents directement dans PagerDuty, via un appel synchrone à l'API.