Choisir comment PagerDuty est alerté

Contrôlez précisément quel service PagerDuty est alerté pour chaque alerte, si les incidents se résolvent automatiquement, ce qui apparaît dans l’historique de PagerDuty, et ce qui se passe pendant une maintenance planifiée. Ceci s’adresse à toute personne qui gère le fonctionnement conjoint d’InfraNest et PagerDuty, service par service.

Aperçu

• Chaque réglage présenté ici est propre à un service PagerDuty, sous Integrations → PagerDuty.
• InfraNest envoie des détails avec chaque alerte afin que l’Event Orchestration de PagerDuty puisse l’acheminer automatiquement, sans dépendre du titre.
• Vous contrôlez si les incidents se résolvent automatiquement, si des changements comme les déploiements apparaissent dans PagerDuty, et si les fenêtres de maintenance mettent aussi PagerDuty en pause.

Envoyer les alertes à la bonne équipe

Chaque alerte envoyée par InfraNest inclut des détails sur lesquels PagerDuty peut effectuer une correspondance :

• Component — pour un moniteur, son nom ; pour les autres alertes, le domaine, le serveur, le certificat ou la zone DNS.
• Group — pour un moniteur, son premier tag (ou « monitoring » s’il n’en a aucun) ; pour les autres alertes, le domaine concerné, comme domains, certificates, servers, dns ou drop-catch.
• Class — pour un moniteur, le type de vérification, comme http, ssl ou ping ; pour les autres alertes, le type d’alerte, comme domain_expiry_critical.

Par exemple, pour envoyer tout ce qui concerne vos bases de données à l’équipe base de données :

1. Dans InfraNest, taguez vos moniteurs de base de données avec « database ».
2. Dans PagerDuty, ouvrez l’Event Orchestration du service (ou l’orchestration globale, pour router entre plusieurs services).
3. Ajoutez une règle où group correspond à « database », et acheminez-la vers le service de l’équipe base de données.
4. Mettez un moniteur de base de données hors service pour tester — l’incident devrait s’ouvrir sur le service de l’équipe base de données.

Vous pouvez aussi définir vous-même le component, le group et la class dans l’action d’automatisation Trigger PagerDuty incident.

Router sur vos propres champs et définir le type d’incident

Les alertes transportent aussi des détails supplémentaires sur lesquels vous pouvez router :

• impact et source — la gravité attribuée par InfraNest à l’alerte, et ce qui l’a déclenchée.
• fields — vos propres champs personnalisés sur l’objet concerné par l’alerte : pour un moniteur, le serveur qu’il surveille ; pour une alerte de domaine, de certificat ou de serveur, les champs propres à cet enregistrement.

Ainsi, un champ Customer que vous conservez sur vos serveurs peut router les alertes : dans Event Orchestration, ajoutez une règle sur les détails personnalisés de l’alerte, comme fields.Customer correspond à « Acme », acheminant vers le service d’Acme. Le même type de règle peut définir le type d’incident — par exemple, impact correspond à « critical » achemine vers un incident Major. Rien n’a besoin d’être configuré dans InfraNest pour cela.

Résoudre les incidents manuellement

Par défaut, InfraNest résout l’incident PagerDuty dès que le problème se termine. Si votre équipe préfère clôturer les incidents elle-même, par exemple après une revue :

1. Allez dans Integrations → PagerDuty et trouvez le service.
2. Désactivez Resolve in PagerDuty when the problem ends.

L’incident InfraNest se ferme toujours quand le problème se termine. L’incident PagerDuty reste ouvert jusqu’à ce que quelqu’un le résolve, soit dans PagerDuty, soit en résolvant l’incident dans InfraNest. Les accusés de réception continuent de se synchroniser dans les deux cas.

NoteLes domaines et certificats se résolvent lorsqu’InfraNest constate réellement la correction — un domaine renouvelé lors de sa prochaine synchronisation avec le registrar (ou immédiatement s’il est renouvelé dans InfraNest), un certificat remplacé lorsqu’InfraNest détecte le nouveau. Une bonne nouvelle, comme un renouvellement, n’ouvre jamais d’incident en premier lieu.

Voir les changements InfraNest dans PagerDuty

PagerDuty affiche les changements récents sur chaque service et incident. Avec Send changes activé, InfraNest remplit cette section, afin qu’un intervenant puisse voir qu’un déploiement a eu lieu quatre minutes avant qu’un moniteur ne tombe en panne. Les changements n’ouvrent jamais d’incident ni n’alertent personne.

Ce qui apparaît :

• Les déploiements d’un dépôt que vous avez associé à un moniteur ou un serveur, sur les services qui reçoivent des alertes de supervision.
• Les changements DNS, les actions d’alimentation des serveurs, les changements de pare-feu effectués via InfraNest, et les certificats remplacés — affichés sur chaque service du compte, car ils ne sont pas liés à un moniteur en particulier.

Plusieurs changements sur la même zone, le même serveur ou le même pare-feu en l’espace d’environ une minute arrivent comme une seule entrée, par exemple « 3 DNS changes to example.com by Dana ». Send changes est activé par défaut pour chaque nouveau service ; vous pouvez le désactiver service par service. PagerDuty conserve les changements pendant 90 jours.

Mettre PagerDuty en pause pendant une maintenance

Une fenêtre de maintenance InfraNest met en silence les propres alertes d’InfraNest, mais les autres outils qui alertent le même service PagerDuty continuent de passer. Pour les faire taire aussi :

1. Allez dans Integrations → PagerDuty. Cela nécessite un compte connecté en un clic.
2. Sous le service, activez Also pause this service in PagerDuty during maintenance.
3. Planifiez la maintenance comme d’habitude sous Monitoring → Maintenance, en couvrant au moins un moniteur ou un serveur, avec les alertes retenues.

InfraNest crée alors une fenêtre de maintenance PagerDuty correspondante, la déplace si vous changez les horaires, et la supprime si vous l’annulez ou la terminez en avance. Une maintenance récurrente obtient une fenêtre à la fois, pour la prochaine occurrence.

WarningPendant que la fenêtre est ouverte, PagerDuty retient toutes les alertes sur ce service, provenant de n’importe quel outil, pas seulement d’InfraNest. N’activez ceci que si c’est bien ce que vous souhaitez. InfraNest ne touche jamais aux fenêtres de maintenance que vous avez créées vous-même dans PagerDuty.

Escalade dans InfraNest et dans PagerDuty

InfraNest peut pousser vers votre navigateur une panne que personne n’a accusé réception après 15, 30 ou 60 minutes, sous My account → Notifications. Les politiques d’escalade de PagerDuty font déjà cela, donc vous n’avez peut-être pas besoin des deux. Accuser réception dans PagerDuty arrête aussi l’escalade d’InfraNest.

Dépannage

Les déploiements ou changements n’apparaissent pas dans les changements récents. Vérifiez que Send changes est activé et que le compte n’est pas en pause. Un déploiement n’apparaît que si son dépôt est associé à un moniteur ou un serveur, que le service reçoit des alertes de supervision, et qu’InfraNest a été informé du déploiement dans l’heure.

PagerDuty n’a pas mis un service en pause pendant une maintenance. Vérifiez l’interrupteur, que le compte n’est pas en pause, et que la maintenance couvre un moniteur ou un serveur et retient les alertes. Si PagerDuty a refusé, InfraNest vous le signale dans la cloche de notifications.

Un incident de domaine ou de certificat est resté ouvert après son renouvellement. InfraNest le résout dès qu’il constate la nouvelle date d’expiration. Si vous l’avez remplacé d’une autre manière, résolvez-le dans PagerDuty.

Un service possède une intégration nommée « InfraNest (setting up …) ». Il s’agit de l’intégration propre à InfraNest, avant son renommage. Si PagerDuty n’a pas accepté le renommage, elle fonctionne quand même — renommez-la vous-même ou laissez-la telle quelle.