So wird PagerDuty alarmiert

Steuere genau, welcher PagerDuty-Service für welche Benachrichtigung alarmiert wird, ob sich Vorfälle automatisch schließen, was im Verlauf von PagerDuty erscheint und was während geplanter Wartung passiert. Das richtet sich an alle, die festlegen, wie InfraNest und PagerDuty pro Service zusammenarbeiten.

Überblick

• Jede Einstellung hier gilt pro PagerDuty-Service und findet sich unter Integrations → PagerDuty.
• InfraNest sendet mit jeder Alarmierung Details, damit PagerDutys Event Orchestration sie automatisch weiterleiten kann, ohne sich auf den Titel zu verlassen.
• Du bestimmst, ob Vorfälle automatisch aufgelöst werden, ob Änderungen wie Deploys in PagerDuty erscheinen und ob Wartungsfenster auch PagerDuty pausieren.

Benachrichtigungen an das richtige Team senden

Jede Alarmierung, die InfraNest sendet, enthält Details, auf die PagerDuty reagieren kann:

• Component — bei einem Monitor dessen Name; bei anderen Benachrichtigungen die Domain, der Server, das Zertifikat oder die DNS-Zone.
• Group — bei einem Monitor dessen erster Tag (oder „monitoring“, falls keiner vorhanden ist); bei anderen Benachrichtigungen der Bereich, etwa Domains, Zertifikate, Server, DNS oder Drop Catch.
• Class — bei einem Monitor die Art der Prüfung, etwa http, ssl oder ping; bei anderen Benachrichtigungen die Art der Benachrichtigung, etwa domain_expiry_critical.

Um zum Beispiel alles rund um deine Datenbanken an das Datenbankteam zu senden:

1. Versieh deine Datenbank-Monitore in InfraNest mit dem Tag „database“.
2. Öffne in PagerDuty die Event Orchestration des Service (oder die globale, um serviceübergreifend weiterzuleiten).
3. Füge eine Regel hinzu, bei der group mit „database“ übereinstimmt, und leite sie an den Service des Datenbankteams weiter.
4. Nimm einen Datenbank-Monitor offline, um es zu testen — der Vorfall sollte beim Service des Datenbankteams eröffnet werden.

Du kannst Component, Group und Class auch selbst in der Automatisierungsaktion Trigger PagerDuty incident festlegen.

Nach eigenen Feldern weiterleiten und den Vorfalltyp festlegen

Alarmierungen enthalten zudem weitere Details, nach denen du weiterleiten kannst:

• impact und source — wie schwerwiegend InfraNest die Benachrichtigung einstuft und wodurch sie ausgelöst wurde.
• fields — deine eigenen benutzerdefinierten Felder auf dem Objekt, um das es bei der Alarmierung geht: bei einem Monitor der Server, den er überwacht; bei einer Domain-, Zertifikats- oder Server-Benachrichtigung die eigenen Felder dieses Eintrags.

So kann ein Customer-Feld, das du bei deinen Servern pflegst, Alarmierungen weiterleiten: Füge in Event Orchestration eine Regel hinzu, bei der etwa fields.Customer mit „Acme“ übereinstimmt und an den Service von Acme weiterleitet. Eine ähnliche Regel kann den Vorfalltyp festlegen — zum Beispiel leitet impact mit Übereinstimmung „critical“ an einen Major-Vorfall weiter. Dafür ist in InfraNest nichts einzurichten.

Vorfälle manuell auflösen

Standardmäßig löst InfraNest den PagerDuty-Vorfall auf, sobald das Problem endet. Falls dein Team Vorfälle lieber selbst schließt, etwa nach einer Überprüfung:

1. Gehe zu Integrations → PagerDuty und suche den Service.
2. Schalte Resolve in PagerDuty when the problem ends aus.

Der InfraNest-Vorfall schließt sich weiterhin, sobald das Problem endet. Der PagerDuty-Vorfall bleibt offen, bis ihn jemand auflöst — entweder in PagerDuty oder indem der Vorfall in InfraNest aufgelöst wird. Bestätigungen (Acknowledgements) werden in beiden Fällen weiterhin synchronisiert.

NoteDomains und Zertifikate werden aufgelöst, sobald InfraNest die Behebung tatsächlich feststellt — eine verlängerte Domain bei der nächsten Registrar-Synchronisierung (oder sofort, falls in InfraNest verlängert), ein ersetztes Zertifikat, sobald InfraNest das neue sieht. Gute Nachrichten wie eine Verlängerung eröffnen von vornherein nie einen Vorfall.

InfraNest-Änderungen in PagerDuty sehen

PagerDuty zeigt aktuelle Änderungen bei jedem Service und Vorfall an. Mit aktiviertem Send changes trägt InfraNest diese ein, sodass ein Verantwortlicher sehen kann, dass vier Minuten vor dem Ausfall eines Monitors ein Deploy stattfand. Änderungen eröffnen nie einen Vorfall und alarmieren niemanden.

Was angezeigt wird:

• Deploys eines Repositorys, das du mit einem Monitor oder Server verknüpft hast, bei Services, die Monitor-Benachrichtigungen erhalten.
• DNS-Änderungen, Server-Energieaktionen, über InfraNest vorgenommene Firewall-Änderungen und ersetzte Zertifikate — angezeigt bei jedem Service im Konto, da sie nicht an einen bestimmten Monitor gebunden sind.

Mehrere Änderungen an derselben Zone, demselben Server oder derselben Firewall innerhalb von etwa einer Minute erscheinen als ein einzelner Eintrag, etwa „3 DNS changes to example.com by Dana“. Send changes ist standardmäßig für jeden neuen Service aktiviert; du kannst es pro Service ausschalten. PagerDuty bewahrt Änderungen 90 Tage lang auf.

PagerDuty während der Wartung pausieren

Ein InfraNest-Wartungsfenster stummschaltet InfraNests eigene Benachrichtigungen, aber andere Tools, die denselben PagerDuty-Service alarmieren, kommen weiterhin durch. Um auch diese stummzuschalten:

1. Gehe zu Integrations → PagerDuty. Dafür ist ein mit einem Klick verbundenes Konto nötig.
2. Schalte beim Service Also pause this service in PagerDuty during maintenance ein.
3. Plane die Wartung wie gewohnt unter Monitoring → Maintenance, wobei mindestens ein Monitor oder Server erfasst und Benachrichtigungen zurückgehalten werden.

InfraNest erstellt dann ein passendes Wartungsfenster in PagerDuty, verschiebt es, wenn du die Zeiten änderst, und entfernt es, wenn du die Wartung abbrichst oder vorzeitig beendest. Bei wiederkehrender Wartung wird jeweils ein Fenster für das nächste Vorkommen erstellt.

WarningSolange das Fenster offen ist, hält PagerDuty jede Benachrichtigung an diesem Service zurück — von jedem Tool, nicht nur von InfraNest. Schalte dies nur ein, wenn genau das gewünscht ist. InfraNest rührt niemals Wartungsfenster an, die du selbst in PagerDuty angelegt hast.

Eskalation in InfraNest und in PagerDuty

InfraNest kann einen nicht bestätigten Ausfall nach 15, 30 oder 60 Minuten an deinen Browser weitergeben, einstellbar unter My account → Notifications. PagerDutys Eskalationsrichtlinien tun dies bereits, daher brauchst du eventuell nicht beides. Eine Bestätigung in PagerDuty stoppt auch InfraNests Eskalation.

Fehlerbehebung

Deploys oder Änderungen erscheinen nicht unter den aktuellen Änderungen. Prüfe, ob Send changes aktiviert ist und das Konto nicht pausiert ist. Ein Deploy erscheint nur, wenn sein Repository mit einem Monitor oder Server verknüpft ist, der Service Monitor-Benachrichtigungen erhält und InfraNest innerhalb einer Stunde vom Deploy erfahren hat.

PagerDuty hat einen Service während der Wartung nicht pausiert. Prüfe den Schalter, ob das Konto nicht pausiert ist und ob die Wartung einen Monitor oder Server erfasst und Benachrichtigungen zurückhält. Falls PagerDuty dies abgelehnt hat, informiert InfraNest dich über die Benachrichtigungsglocke.

Ein Domain- oder Zertifikats-Vorfall blieb nach der Verlängerung offen. InfraNest löst ihn auf, sobald das neue Ablaufdatum erkannt wird. Falls du auf andere Weise verlängert hast, löse ihn in PagerDuty auf.

Ein Service hat eine Integration namens „InfraNest (setting up …)“. Das ist InfraNests eigene Integration, vor ihrer Umbenennung. Falls PagerDuty die Umbenennung nicht übernommen hat, funktioniert sie dennoch — benenne sie selbst um oder lasse sie so, wie sie ist.