Je komplexer das System ist, desto mehr wächst es mit allen Arten von Warnungen. Und es besteht die Notwendigkeit, genau auf diese Warnungen zu reagieren, sie zu aggregieren und zu visualisieren. Ich denke eine Situation, die vielen vor einer nervösen Zecke bekannt ist.
Die Entscheidung, die diskutiert wird, ist nicht die unerwartetste, aber die Suche liefert keinen vollständigen Artikel zu diesem Thema.
Aus diesem Grund habe ich beschlossen, die Erfahrungen von FunCorp zu teilen und darüber zu sprechen, wie der Pflichtprozess aufgebaut ist, wer anruft, warum und wie Sie dies alles betrachten können.
Was ist PagerDuty?
Um all diese Probleme zu lösen, suchten wir nach einem geeigneten Werkzeug. Nach einer kurzen Suche haben wir uns für PagerDuty entschieden. PD schien uns eine ziemlich vollständige und prägnante Lösung mit vielen Integrationen und Einstellungen zu sein. Wie ist sie?
Kurz gesagt, PagerDuty ist eine Vorfallbearbeitungsplattform, die eingehende Vorfälle durch verschiedene Integrationen verarbeiten, die Reihenfolge der Vorfälle anpassen und dann den zuständigen Techniker je nach Ebene des Vorfalls benachrichtigen kann (bei Anruf auf hoher Ebene, bei Anruf aus Anwendung auf niedriger Ebene / SMS). .
Wer ist die diensthabende Person?
Dies ist wahrscheinlich das erste Mal, dass Sie mit dem Einrichten einer PD beginnen.
FunCorp hat wie andere Unternehmen eine ehrenamtliche Funktion inne. Es wird einmal täglich von Ingenieur zu Ingenieur übertragen. Es gibt die sogenannte erste und zweite Antwortzeile auf Warnungen von PagerDuty. Angenommen, ein Alarm mit hoher Priorität kommt an, und wenn 10 Minuten nach dem Anruf an den Vermittler aus der ersten Leitung keine Reaktion auf ihn erfolgt (d. H. Er wird nicht in den Bestätigungs- oder Abwicklungsstatus versetzt), geht der Anruf an den zweiten diensthabenden Techniker. Dies wird in PagerDuty selbst über Eskalationsrichtlinien konfiguriert.
Wenn die zweite Telefonzentrale nicht antwortet, wird die Benachrichtigung an die
Haupttelefonzentrale zurückgesendet .
Daher kann eine eingehende Warnung mit hoher Priorität nicht unbearbeitet bleiben.
Nun wollen wir sehen, wo die Vorfälle herkommen können.
Welche Integrationen verwenden wir?
Viele verschiedene Vorfälle aus verschiedenen Diensten werden in PD eingespeist. Wir haben jetzt ungefähr 25 solcher Dienste und verwenden für ihre Verarbeitung einige vorgefertigte Integrationen.
Das primäre Messwerterfassungssystem ist Prometheus. In Habré ist schon viel darüber geschrieben worden, ich möchte nur sagen, dass wir mehrere für verschiedene Umgebungen haben: eine sammelt Metriken von virtuellen Maschinen und Dockern, die andere von Amazon-Diensten, die dritte von „Eisenmaschinen“. Als Exporteur von Metriken wird hauptsächlich Telegraf verwendet.
Auch hier denke ich, dass der Name alles verdeutlicht. Diese Integration wird verwendet, um Benachrichtigungen von einigen Skripten zu senden, die auf der Krone ausgeführt werden. PD gibt Ihnen eine bestimmte Adresse, an die Sie Briefe senden. Beim Erstellen eines Dienstes mit dieser Integration können Sie Prioritäten festlegen, in welcher Reihenfolge eingehende Vorfälle verarbeitet werden, wie eine Warnung erstellt wird (für jeden eingehenden Brief, für einen eingehenden Brief + eine bestimmte Regel usw.).
Meiner Meinung nach eine sehr interessante Integration. Es gibt Zeiten, in denen etwas passiert, das jedoch nicht von Vorfällen abgedeckt wird. Aus diesem Grund haben wir die Integration von Slack hinzugefügt, um den Vorfall zu erstellen. Das heißt, in Corporate Slack können Sie schreiben
/ callofduty alles verlangsamt und bald bricht es und PD verarbeitet dies und sendet den Vorfall an den Duty Engineer.
Wir machen:
Wir sehen:
HTTP-Integration. Hier gibt es eigentlich nichts besonders Interessantes, nur eine POST-Anfrage mit einem Body im JSON-Format. Ein interessantes Beispiel: Wir verwenden es für die externe Überwachung über
https://www.statuscake.com/ . Dieser Service prüft die Verfügbarkeit unserer Websites auf der ganzen Welt. In dem Fall, dass wir einen inakzeptablen Antwortcode erhalten (z. B. 502), wird ein Vorfall erstellt, und dann verläuft alles entlang der oben beschriebenen Kette. StatusCake selbst kann interne URLs, den Ablauf eines SSL-Zertifikats oder einer Domäne überwachen.
Dies ist ein weiteres Überwachungssystem. Weitere Informationen finden Sie auf der Website
https://www.librenms.org/ . Mit seiner Hilfe überwachen wir Netzwerkschnittstellen und iDRAC von Servern.
Es gab auch Integrationen wie Datadog, CloudWatch. Mehr darüber, was daraus geworden ist, finden Sie
hier .
Visualisierung
Das primäre Ereignismeldesystem ist Slack. Alle Vorfälle, die zu PD kommen, werden in einen speziellen Chat geschrieben. Wenn sich ihr Status ändert, wird dies auch im Chat angezeigt.
Als es möglich wurde, nützliche Daten auf den Bildschirmen von Monitoren anzuzeigen, die unter der Decke hingen, wurde uns plötzlich klar, dass wir (in der Entwicklungsabteilung) nichts auf ihnen anzuzeigen haben. Es gibt eine wundervolle Grafana, die jedoch nicht abgedeckt werden kann, und Mitarbeiter reagieren auf Warnungen, nicht auf Diagramme.
Nach einer gründlichen, aber erfolglosen Suche auf GitHub nach einem übersichtlichen und informativen „Board“ für PD haben wir beschlossen, unser eigenes zu schreiben - nur mit dem, was wir brauchten. Obwohl zunächst die Idee bestand, das PD-Interface selbst anzuzeigen, sah es noch unpraktischer aus.
Zum Schreiben benötigen Sie lediglich den Schlüssel für PD mit Leserechten.
Und hier ist was wir haben:
Auf dem Bildschirm werden die aktuellen offenen Vorfälle, der Name des aktuellen Einsatzleiters aus dem ausgewählten Zeitplan und die Zeit ohne Vorfall mit hoher Priorität angezeigt (ein Bereich mit einem Vorfall mit hoher Priorität wird rot hervorgehoben).
Den Quellcode für diese Implementierung finden Sie hier .
Als Ergebnis haben wir ein praktisches Dashboard, über das wir alle unsere Vorfälle anzeigen können. Ich würde mich freuen, wenn einer von Ihnen von unserer Erfahrung profitieren würde.