Der Blog

Wer überwacht die Wächter?

von Julie Arsenault 30. Oktober 2014 | 4 Minuten Lesezeit

Wie wir unseren eigenen Champagner trinken (und bei PagerDuty überwachen)

Wir versenden jeden Monat über 4 Millionen Warnmeldungen und Unternehmen verlassen sich darauf, dass wir sie über Ausfälle informieren. Wer überwacht also die Wächter? Arup Chakrabarti, technischer Leiter von PagerDuty, sprach darüber, wie wir unsere eigenen Systeme überwachen bei den DevOps Days Chicago Anfang des Monats. Hier sind einige Highlights aus seinem Vortrag über die Überwachungstools und -philosophien, die wir hier bei PagerDuty verwenden.

Verwenden Sie das richtige Werkzeug

Was Tools angeht, verwenden wir New Relic, weil es viele Diagramme und Berichte bereitstellen kann. Tools zur Anwendungsleistungsverwaltung liefern Ihnen viele Informationen, was hilfreich ist, wenn Sie Ihre kritischen Kennzahlen nicht wirklich kennen. Sie lassen sich jedoch nur schwer anpassen und all diese Informationen können zu einer „Analyselähmung“ führen.

PagerDuty verwendet auch StatsD und DataDog zur Überwachung wichtiger Kennzahlen, da diese einfach zu verwenden und sehr anpassbar sind. Allerdings kann es etwas dauern (wir haben eine halbtägige Sitzung mit unseren Ingenieuren abgehalten), bis die Teams mit den Kennzahlen vertraut sind. SumoLogic analysiert kritische App-Protokolle und die PagerDuty -Ingenieure richten Warnmeldungen für Muster in den Protokollen ein. Wormly und Monitis bieten externe Überwachung, allerdings musste das Team eine intelligentere Seite zur Integritätsprüfung erstellen, die bei unerwarteten Werten warnt. Und schließlich verwendet PagerDuty PagerDuty , um Warnmeldungen aus all diesen Überwachungssystemen zu konsolidieren und uns zu benachrichtigen, wenn etwas schief geht.

Vermeiden Sie die Einzelhostüberwachung für verteilte Systeme

„Gehen Sie davon aus, dass alles, was auf einer einzelnen Box läuft, anfällig ist und im ungünstigsten Moment kaputtgeht“, sagt Chakrabarti. Stattdessen richtet PagerDuty Warnmeldungen auf Cluster-Ebene ein, wie etwa die Gesamtzahl von 500 Fehlern, nicht die Anzahl in einer einzelnen Protokolldatei, und die Gesamtlatenz, nicht die Latenz einer einzelnen Box. Aus diesem Grund versucht PagerDuty , alle Systeme durch das Überwachungssystem zu leiten, anstatt Daten direkt von den Servern oder Diensten in PagerDuty einzuspeisen.

We funnel server and service alerts through a highly-available monitoring system so that we alert on the overall impact rather than individual box issues.

Wir leiten Server- und Servicewarnungen durch ein hochverfügbares Überwachungssystem, sodass wir über die Gesamtauswirkungen und nicht über Probleme einzelner Boxen informieren.

Chakrabarti erörtert auch die Überwachung von Abhängigkeiten oder die Überwachung der Leistung von SaaS-Systemen, die Sie nicht kontrollieren. Für dieses Problem gibt es noch keine gute Antwort. Wir führen eine Kombination aus manuellen Prüfungen und automatisierten Pings durch. Als Beispiel erzählt er die Geschichte eines Anrufs von einem Kunden, der seine SMS nicht erhielt. Bei der Untersuchung stellte sich heraus, dass unser SMS-Anbieter die Nachrichten sendete, der Mobilfunkanbieter sie jedoch aus irgendeinem Grund blockierte. Daraufhin bauten wir ein Testframework auf, „auch bekannt als: Wie man unbegrenzte Messaging-Pläne missbraucht“. Jede Minute senden wir eine SMS-Benachrichtigung an jeden großen Anbieter und messen die Antwortzeiten.

We send SMS messages to the major mobile carriers every minute and measure the response times to make sure we know if the carriers are experiencing issues that may be affecting the deliverability of our SMS alerts

Wir senden jede Minute SMS-Nachrichten an die wichtigsten Mobilfunkanbieter und messen die Antwortzeiten, um sicherzustellen, dass wir wissen, ob bei den Anbietern Probleme auftreten, die die Zustellbarkeit unserer SMS-Benachrichtigungen beeinträchtigen könnten.

Benachrichtigungen zu wichtigen Themen für Kunden

Viele Leute machen den Fehler, bei jedem einzelnen Fehler im Protokoll eine Warnung auszugeben, sagt Chakrabarti. „Wenn der Kunde es nicht bemerkt, muss er vielleicht nicht darauf hingewiesen werden.“ Er warnt jedoch, dass das Wort „Kunde“ innerhalb derselben Organisation verschiedene Bedeutungen haben kann. „Wenn Sie an Endbenutzer-Dingen arbeiten, sollten Sie die Latenz überwachen. Wenn Sie sich mehr um interne Vorgänge sorgen, sollten Sie sich vielleicht um die CPU in Ihrem Cassandra-Cluster kümmern, weil Sie wissen, dass dies Ihre anderen Entwicklungsteams beeinflusst.“ Wir haben eine großartige Blogeintrag darüber, worauf Sie aufmerksam gemacht werden sollen, wenn Sie mehr erfahren möchten.

Überprüfen Sie, ob die Warnungen funktionieren

Das vielleicht beste Beispiel für die Beobachtung der Beobachter ist die Tatsache, dass „man hin und wieder manuell nachsehen muss, ob die Alarme noch funktionieren“, sagt Chakrabarti. „Bei PagerDuty haben wir etwas, das wir Misserfolg am Freitag , während wir im Grunde eingreifen und unsere eigenen Dienste angreifen.“ Das Team lässt alle Alarme aktiv und fährt fort, Prozesse, das Netzwerk und die Rechenzentren zu zerstören, um die Alarme zu bestätigen.

Was hat das Team aus Failure Friday gelernt? „Die Prozessüberwachung war mit der Prozessausführung vermischt“, erklärt Chakrabarti. „Wenn der Dienst ausfällt, fällt auch die Überwachung des Dienstes aus, und man erfährt davon erst, wenn es auf jeder einzelnen Box ausfällt.“ Und das ist, kurz gesagt, der Grund für die externe Überwachung.