Je komplexer das System ist, desto mehr gibt es verschiedene Alarme. Es entsteht die Notwendigkeit, auf diese Alarme zu reagieren, sie zu aggregieren und zu visualisieren. Ich denke, die Situation ist vielen bis zum Nervenzucken bekannt.
Die Lösung, über die wir sprechen werden, ist nicht die unerwartetste, jedoch gibt es keinen umfassenden Artikel zu diesem Thema.
Deshalb habe ich beschlossen, die Erfahrungen von FunCorp zu teilen und darüber zu berichten, wie der Bereitschaftsprozess strukturiert ist, wer anruft, warum und wie man all dies betrachten kann.
Was ist PagerDuty?
Um all diese Aufgaben zu lösen, begannen wir, nach einem geeigneten Werkzeug zu suchen. Nach kurzer Suche entschieden wir uns für PagerDuty. PD erschien uns als eine recht vollständige und prägnante Lösung mit vielen Integrationen und Einstellungen. Was ist es genau?
Kurz gesagt, PagerDuty ist eine Plattform zur Bearbeitung von Vorfällen, die eingehende Vorfälle über verschiedene Integrationen verarbeiten, die Bereitschaftspläne einrichten und dann den Bereitschaftsingenieur je nach Schweregrad des Vorfalls alarmieren kann (bei hohem Schweregrad — Anruf, bei niedrigem — Push-Benachrichtigung aus der App/SMS).
Wer ist der Bereitschaftsingenieur?
Das ist wahrscheinlich das Erste, womit man die Einstellung von PD beginnen sollte.
In FunCorp, wie in anderen Unternehmen, gibt es die ehrenvolle Position des Bereitschaftsingenieurs. Sie wird täglich von Ingenieur zu Ingenieur übertragen. Es gibt eine sogenannte erste und zweite Reaktionslinie auf Alarme von PagerDuty. Nehmen wir an, ein Alarm mit hoher Priorität kommt, und wenn nach 10 Minuten nach dem Anruf an den Bereitschaftsingenieur der ersten Linie keine Reaktion erfolgt (d.h. der Alarm wurde nicht in den Status
Wenn auch der zweite Bereitschaftsingenieur nicht antwortet, wird die Benachrichtigung zurückgegeben an den Haupt- Bereitschaftsingenieur.
So kann kein eingehender Alarm mit hoher Priorität unbeantwortet bleiben.
Jetzt schauen wir uns an, woher die Vorfälle kommen können.
Welche Integrationen nutzen wir?
In PD häuft sich eine Vielzahl von Vorfällen aus verschiedenen Diensten an. Wir haben derzeit etwa 25 solcher Dienste, und für deren Verarbeitung nutzen wir einige vorgefertigte Integrationen.
- Prometheus
Das Hauptsystem zur Erfassung von Metriken ist Prometheus. Darüber wurde bereits viel auf Habré geschrieben; ich möchte nur erwähnen, dass wir mehrere für verschiedene Umgebungen haben: Eine sammelt Metriken von virtuellen Maschinen und Docker, eine andere – aus Amazon-Diensten, und die dritte – von „physikalischen Maschinen“. Hauptsächlich wird Telegraf als Metrik-Exporter verwendet.
Hier ist auch, denke ich, alles klar aus dem Namen. Diese Integration wird verwendet, um Benachrichtigungen von bestimmten Skripten zu versenden, die über Cron ausgeführt werden. PD gibt Ihnen eine Adresse, an die Sie E-Mails senden. Bei der Erstellung eines Dienstes mit dieser Integration können Sie die Prioritäten festlegen, in welcher Reihenfolge eingehende Vorfälle verarbeitet werden, und wie genau ein Alert erstellt werden soll (für jede eingehende E-Mail, für eine eingehende E-Mail + eine bestimmte Regel usw.).
- Slack
Meiner Meinung nach ist dies eine sehr interessante Integration. Es gibt Fälle, in denen etwas passiert, aber nicht durch Vorfälle abgedeckt ist. Daher haben wir eine Integration von Slack hinzugefügt, um einen Vorfall zu erstellen. Das bedeutet, dass man im Unternehmens-Slack schreiben kann /callofduty все тормозит и скоро сломается und PD wird dies verarbeiten und den Vorfall an den diensthabenden Ingenieur senden.
Wir machen:
Wir sehen:
- API
HTTP-Integration. Hier gibt es tatsächlich nicht viel Interessantes, einfach ein POST-Request mit einem Body im JSON-Format. Zum Beispiel verwenden wir es zur externen Überwachung mit . Dieser Dienst überprüft die Verfügbarkeit unserer Websites aus verschiedenen Teilen der Welt. Falls wir einen inakzeptablen Antwortcode erhalten (zum Beispiel 502), wird ein Vorfall erstellt, und alles geht dann wie oben beschrieben weiter. Im StatusCake gibt es die Möglichkeit, interne URLs sowie das Ablaufdatum von SSL-Zertifikaten oder Domains zu überwachen.
- LibreNMS
Das ist ein weiteres Überwachungssystem, über das man auf ihrer Website mehr lesen kann . Damit überwachen wir die Netzwerkinterfaces und iDRAC von unseren Servern.
Es gab auch solche Integrationen wie Datadog, CloudWatch. Mehr darüber, was mit ihnen passiert ist, kann man .
Visualisierung
Das Hauptsystem zur Benachrichtigung über Vorfälle ist Slack. In einen speziellen Chat werden alle eingehenden Vorfälle in PD geschrieben, und wenn sich deren Status ändert, wird dies ebenfalls im Chat angezeigt.
Als die Möglichkeit entstand, nützliche Daten auf die Bildschirme zu projizieren, die von der Decke hängen, wurde uns plötzlich bewusst, dass wir (im DevOps-Team) nichts zu zeigen hatten. Es gibt großartige Grafana, aber sie kann nicht alles abdecken, und die Mitarbeiter reagieren auf Alarme, nicht auf Grafiken.
Nach einer gründlichen, aber erfolglosen Suche auf GitHub nach einem prägnanten und informativen Dashboard für PD entschieden wir uns, unser eigenes zu schreiben – nur mit dem, was wir brauchen. Zunächst hatten wir die Idee, die PD-Oberfläche anzuzeigen, aber das schien noch unpraktischer.
Um es zu schreiben, genügt es, einen Schlüssel für PD mit Nur-Lese-Rechten zu erhalten.
Und das ist das Ergebnis:
Auf dem Bildschirm werden aktuelle offene Vorfälle, der Name des aktuellen Bereitschaftsingenieurs aus dem gewählten Zeitplan und die Zeit ohne einen hochpriorisierten Vorfall angezeigt (das Panel für den hochpriorisierten Vorfall wird rot hervorgehoben).
.
Letztendlich haben wir ein praktisches Dashboard zur Ansicht aller unserer Vorfälle geschaffen. Ich würde mich freuen, wenn unser Erlebnis für den einen oder anderen von Ihnen nützlich ist.
Quelle: habr.com
