Je komplizierter ein System ist, desto mehr Alerts kommen auf. Es entsteht die Notwendigkeit, auf diese Alerts zu reagieren, sie zu aggregieren und zu visualisieren. Ich denke, dass dies für viele ein vertrautes, nervenaufreibendes Szenario ist.
Die Lösung, über die wir sprechen werden, ist zwar nicht die überraschendste, aber eine umfassende Recherche zu diesem Thema ergibt nichts Vollständiges.
Daher habe ich mich entschieden, die Erfahrungen von FunCorp zu teilen und zu schildern, wie der Bereitschaftsdienst organisiert ist, wer anruft und warum, sowie wie man all das einsehen kann.
Was ist PagerDuty?
Um all diese Aufgaben zu bewältigen, begannen wir, nach einem geeigneten Werkzeug zu suchen. Nach kurzer Zeit entschieden wir uns für PagerDuty. Es erschien uns als eine umfassende und prägnante Lösung mit vielen Integrationen und Anpassungsmöglichkeiten. Was hat es damit auf sich?
Kurz gesagt, PagerDuty ist eine Plattform zur Bearbeitung von Incidents, die eingehende Incidents über verschiedene Integrationen verarbeiten kann, die Reihenfolge der Diensteinstellungen anpasst und anschließend den Bereitschaftstechniker je nach Schwere des Incidents alarmiert (bei hohem Schweregrad – Anruf, bei niedrigem – Push-Benachrichtigung aus der App/SMS).
Wer ist der Bereitschaftstechniker?
Das ist wahrscheinlich der erste Schritt, um die PD-Konfiguration zu starten.
Bei FunCorp, wie in anderen Unternehmen, gibt es die ehrenvolle Position des Bereitschaftsdienstes. Diese wird jeden Tag von Ingenieur zu Ingenieur weitergegeben. Es gibt eine sogenannte erste und zweite Alarmreaktionslinie für Alerts von PagerDuty. Angenommen, ein hochpriorisierter Alert kommt herein, und wenn nach 10 Minuten nach dem Anruf an den Bereitschaftsdienst der ersten Linie keine Reaktion erfolgt (d.h. der Status wurde nicht auf acknowledge oder resolved gesetzt), wird der Anruf an den zweiten Bereitschaftsingenieur weitergeleitet. Dies wird in PagerDuty über die Eskalationsrichtlinien eingestellt.
Wenn auch der zweite Bereitschaftsdienst nicht antwortet, wird die Benachrichtigung zurückgegeben an den Haupt- Bereitschaftsdienst.
Somit kann kein hochpriorisierter eingehender Alert unbehandelt bleiben.
Jetzt schauen wir uns an, woher die Vorfälle kommen können.
Welche Integrationen nutzen wir?
In PD kommen zahlreiche verschiedene Vorfälle von verschiedenen Diensten herein. Derzeit haben wir etwa 25 solcher Dienste, und für deren Bearbeitung verwenden wir einige fertige Integrationen.
- Prometheus
Das Hauptsystem zur Sammlung von Metriken ist Prometheus. Darüber wurde bereits viel auf Habré geschrieben, ich möchte nur sagen, dass wir mehrere Instanzen für verschiedene Umgebungen haben: eine für die Sammlung von Metriken von virtuellen Maschinen und Containern, eine andere für die Dienste von Amazon und eine dritte für 'physische Maschinen'. In der Regel wird Telegraf als Metriken-Exporter verwendet.
Hier ist, denke ich, alles klar aus dem Namen. Diese Integration wird verwendet, um Benachrichtigungen von bestimmten Skripten, die im Cronjob ausgeführt werden, zu senden. PD gibt Ihnen eine Adresse, an die Sie E-Mails senden. Bei der Erstellung eines Dienstes mit dieser Integration können Sie Prioritäten festlegen, in welcher Reihenfolge eingehende Vorfälle bearbeitet werden sollen, sowie festlegen, wie Alarme erstellt werden (für jede eingehende E-Mail, für eine eingehende E-Mail plus eine bestimmte Regel usw.).
- Slack
Meiner Meinung nach ist dies eine äußerst interessante Integration. Es gibt Fälle, in denen etwas passiert, aber es nicht zu Vorfällen führt. Daher haben wir eine Integration mit Slack hinzugefügt, um einen Vorfall zu erstellen. Das heißt, man kann im Unternehmens-Slack schreiben. /callofduty все тормозит и скоро сломается und PD wird dies verarbeiten und den Vorfall an den diensthabenden Ingenieur senden.
Wir machen:
Wir sehen:
- API
HTTP-Integration. Hier gibt es eigentlich nichts besonderes, nur eine POST-Anfrage mit einem JSON-Format im Body. Interessant ist, dass wir sie für die externe Überwachung mit Hilfe von . Dieser Dienst prüft die Verfügbarkeit unserer Websites aus verschiedenen Teilen der Welt. Falls wir einen unzulässigen Antwortcode erhalten (z.B. 502), wird ein Vorfall erstellt und alles folgt der oben beschriebenen Kette. In StatusCake gibt es die Möglichkeit, interne URLs, das Ablaufen von SSL-Zertifikaten oder Domains zu überwachen.
- LibreNMS
Das ist ein weiteres Überwachungssystem, über das man mehr auf ihrer Website lesen kann . Damit überwachen wir die Netzwerkschnittstellen und iDRAC von den Servern.
Es gab auch Integrationen wie Datadog und CloudWatch. Mehr dazu, was mit ihnen passiert ist, kann man sehen .
Visualisierung
Das Hauptinformationssystem für Vorfälle ist Slack. Alle eingehenden Vorfälle im PD werden in einen speziellen Chat geschrieben, und wenn sich ihr Status ändert, wird dies ebenfalls im Chat angezeigt.
Als wir die Möglichkeit hatten, nützliche Daten auf die an der Decke hängenden Monitore zu projizieren, wurde uns plötzlich klar, dass wir (im DevOps-Team) nichts hatten, was wir darauf anzeigen könnten. Es gibt großartige Grafana, aber sie kann nicht alles abdecken, und die Mitarbeiter reagieren eher auf Alarme als auf Grafiken.
Nach einer gründlichen, aber erfolglosen Suche auf GitHub nach einem prägnanten und informativen Dashboard für PD, beschlossen wir, unser eigenes zu erstellen – nur mit dem, was wir wirklich benötigen. Zunächst hatten wir die Idee, die PD-Oberfläche anzuzeigen, was jedoch noch unpraktischer schien.
Um dies zu erstellen, reicht es aus, einen Schlüssel für PD mit Lesezugriff zu erhalten.
Und das ist das Ergebnis:
Auf dem Bildschirm werden aktuelle offene Vorfälle, der Name des aktuellen on-call Ingenieurs aus dem gewählten Zeitplan und die Zeit ohne einen hochprioritären Vorfall angezeigt (das Panel mit dem hochprioritären Vorfall wird rot hervorgehoben).
.
Am Ende haben wir ein benutzerfreundliches Dashboard für die Ansicht aller unserer Vorfälle erstellt. Ich würde mich freuen, wenn jemand von euch von unserer Erfahrung profitieren kann.
Quelle: habr.com
