Der Autor möchte darauf hinweisen, dass dieses Blog definitiv nicht mehrfach durch die Mitwirkenden Dave Bresci und Arup Chakrabarti verzögert wurde.

Überwachung ist eine Kunstform. Das klingt kitschig und faul, aber die richtige Art der Überwachung ist sehr kontextabhängig und selten funktioniert dieselbe Vorgehensweise bei mehreren Softwareprogrammen oder Personen.

Dies wird noch schwieriger, wenn Sie an moderne Softwarearchitekturen denken. Microservices? Container-Scheduler? Autoscaling-Gruppen? Serverlos? ${Neue-Technologie-die-alle-meine-Probleme-löst-aber-wahrscheinlich-andere-Probleme-schafft}?

Darüber hinaus hängt die Definition eines „Dienstes“ davon ab, mit wem Sie sprechen.

Für einen Softwareentwickler ist ein Service ein isolierter Funktionsblock, der von den zuvor erwähnten Technologien angetrieben wird. Für einen Kunden ist ein Service ein Produkt, für das er bezahlt. Für einen CEO ist ein Service etwas, das ausfällt, damit er seinen SVP of Engineering anschreien kann.

In diesem Beitrag erläutern wir, wie wir, PagerDuty, unsere Dienste in unserer eigenen Instanz von PagerDuty einrichten und überwachen. Sie erhalten einige Tipps, wie Sie die vollständige Übernahme der Dienste ohne (viel) Schlafverlust erreichen und Ihre Kunden und Geschäftspartner zufriedenstellen können.

Ermitteln Sie den Service und die Komponenten

Ein Service besteht normalerweise aus mehreren Komponenten. Die meisten gut aufgestellten Teams besitzen 5-10 Services in der Produktion, mit jeweils 3-5 Komponenten pro Service. Im Idealfall gehört ein Service einem einzigen Team, das die volle Kontrolle über die Komponenten hat. Ist dies nicht der Fall, sollten Sie als Erstes die Eigentumsverteilung auf die Komponenten prüfen.

Sehen wir uns einen typischen dreistufigen Webdienst an.

1. Sie haben Ihren Load Balancer für die Anforderungsweiterleitung
2. Auf Ihren Anwendungsservern wird die Geschäftslogik ausgeführt (häufig ist dies der einzige Teil, der als Teil des „Dienstes“ betrachtet wird).
3. Ihre Datenbank dient der tatsächlichen Speicherung der Daten Ihrer Kunden.

In diesem Szenario haben wir drei Komponenten als Teil eines Dienstes.

Beginnen wir nun mit der Skalierung dieses Webdienstes. Sie werden wahrscheinlich eine Caching-Ebene hinzufügen, um Ihre schlechte Datenbank zu retten, einige CDN-Knoten hinzufügen, um die Leistung zu steigern, und einen gehosteten Dienst verwenden, um selbst einige Arbeiten auszulagern.

Jetzt haben Sie einen einzigen Dienst, der aus sechs unterschiedlichen Komponenten besteht. Jede Komponente benötigt ein gewisses Maß an Telemetrie und Sichtbarkeit, aber das bedeutet nicht, dass Sie jede Komponente überwachen und Warnmeldungen ausgeben müssen. Dadurch konzentrieren Sie sich auf die Integrität der Komponenten, obwohl Sie sich stattdessen auf die allgemeine Integrität des Dienstes konzentrieren sollten.

Es gibt verschiedene Möglichkeiten, sogar einen „einzelnen“ Dienst wie diesen zu modellieren. Einige Organisationen betrachten gemeinsame Infrastrukturebenen, wie etwa Netzwerkebenen oder Datenbanken, als einen separaten, eigenständigen Dienst gegenüber den kundenorientierten Diensten.

Konzentrieren Sie sich auf Warnmeldungen mit Kundenauswirkungen

Konzentrieren Sie sich zunächst auf die grundlegendsten Warnmeldungen für die Verhaltensweisen, die für Ihre Kunden von Bedeutung sind. Denken Sie daran, dass Kunden interne Teams oder externe Personen sein können, die für Ihr Produkt bezahlen. Dies beginnt normalerweise mit einfachen Ping-Monitoren (Ist es aktiv?) und entwickelt sich zu komplexeren Fragen (Läuft es schnell genug?).

Das Schwierige dabei ist, dass es sehr schwierig ist, jede einzelne Art und Weise vorherzusehen, wie Ihre Kunden Ihren Service nutzen werden. Hier ist es tatsächlich in Ordnung, einige Probleme zu spät auftauchen zu lassen und dann später herauszufinden, wie Sie Probleme in Zukunft überwachen und verhindern können. Wenn Sie versuchen, jedes Problem vorherzusehen, werden Sie am Ende Hunderte von Warnungen erstellen, die zu Lärm werden. Denken Sie zunächst an breite Kategorien wie Verfügbarkeit und Leistung und gehen Sie im Laufe der Iteration detaillierter vor.

Bei der Verfügbarkeit können Sie beispielsweise mit dem Prozentsatz der erfolgreich bedienten HTTP-Anfragen beginnen und dann zu Fehleraufschlüsselungen, Aufschlüsselungen nach Komponenten usw. übergehen. Bei der Leistung können Sie mit der Gesamtladezeit der Seite beginnen und dann zu einzelnen Seitenkomponenten, Inhalten von Drittanbietern, Transaktionen auf mehreren Seiten usw. übergehen. Bedenken Sie die Gefahr von Durchschnittswerten und entscheiden Sie sich für Perzentilen. Mehr dazu können Sie hier lesen: https://www.dynatrace.com/news/blog/why-averages-suck-and-percentiles-are-great/ und hier: https://medium.com/@djsmith42/how-to-metric-edafaf959fc7

Das Hinzufügen von Warnungen ist einfach, das Löschen ist schwierig

Verlassen Sie sich nie auf alte Warnmeldungen. Was Sinn machte, als Ihr Service 10 Kunden und drei Komponenten hatte, macht keinen Sinn, wenn Sie Tausende von Kunden und ein Dutzend Komponenten haben.

Wenn Sie eine der folgenden Fragen mit „Ja“ beantworten, ist dies ein Zeichen dafür, dass Sie eine Warnung löschen sollten:

• Ignorieren die Leute diese Warnung?
• Schlummern Sie diese Warnung die meiste Zeit und warten Sie, bis eine andere Warnung eingeht, die relevanter oder wichtiger ist?
• Spiegelt der Wortlaut der Warnung eine alte Denkweise oder etwas wider, das nicht mehr existiert?

Wir haben über die Bedeutung von Betriebsprüfungen und ein wichtiger Teil davon ist das Verständnis, welche Warnungen Sie entfernen können. Eine allgemeine Regel lautet: Wenn eine Warnung in drei aufeinanderfolgenden Überprüfungszyklen keine Aktion ausgelöst hat, entfernen Sie sie oder wandeln Sie sie in eine unterdrücktes Ereignis die Sie später ansehen können. Es kann sich herausstellen, dass Sie Optimieren Sie Ihre Servicekonfiguration in PagerDuty .

Das Definieren von SLIs, SLOs und SLAs ist wirklich schwierig

Nachfolgend finden Sie die Definitionen, die wir intern bei PagerDuty verwenden. Wenn Sie mit der Terminologie nicht vertraut sind, empfehlen wir Ihnen dringend, Folgendes zu lesen: Googles Bücher zum Thema.

Stellen Sie sich SLAs, SLOs und SLIs kurz wie folgt vor.

SLA (Service Level Agreement) - Übersetzung für 'Service Level Agreement' im Deutsch Was Sie Ihren Kunden als Versprechen geben. Jeder Service sollte genau ein SLA haben. Beispiel: 99,9 % Verfügbarkeit.
SLO (Service Level Objective). Ihr internes Ziel für Ihr SLA. Normalerweise ist es eine konservativere Version Ihres SLA. Beispiel: 99,99 % Betriebszeit.
SLI (Service-Level-Indikator) . Objektive Fakten zum aktuellen Status Ihres Dienstes, die Ihnen helfen, die Frage zu beantworten, ob Sie Ihr SLO oder SLA erreichen. Beispielsweise der Prozentsatz der Anfragen, die in weniger als 300 ms eine HTTP 200-Antwort erhalten haben.

Wie bei den meisten Diensten, die Sie einführen, können Ihre SLAs, SLOs und SLIs beim ersten Versuch falsch sein – und das ist in Ordnung. Wichtiger ist, dass Sie etwas Definiertes haben, damit Sie es im Laufe der Zeit verfeinern können, wenn Sie mehr über Ihren Dienst und Ihr Unternehmen erfahren.

Eine gute Entwicklung könnte so aussehen:

1. Prozentsatz der Anfragen, die nicht zu einer 5XX-Antwort geführt haben.
2. Prozentsatz der Anfragen, die keine 5XX-Antwort erhielten und in weniger als 300 ms abgeschlossen wurden.
3. Prozentsatz der Anfragen, die keine 5XX-Antwort erhielten und in weniger als 150 ms abgeschlossen wurden.

Bei PagerDuty haben wir Jahre gebraucht, um herauszufinden, wie wir genau messen können, was unseren Kunden wichtig ist, und was ihnen wichtig ist, hat sich im Laufe der Zeit dramatisch verändert. Obwohl unsere Definitionen unserer internen SLAs, SLOs und SLIs nicht perfekt sind, haben wir etwas, das wir im Laufe der Zeit verfeinern können, wenn unsere Teams mehr darüber lernen, was den Kunden wichtig ist. Weitere Informationen dazu, wie SLOs eine gesunde Serviceüberwachung fördern und Geschäftsentscheidungen beeinflussen können, finden Sie unter Liz Fong-Jones' QCon-Gespräch, Förderung hervorragender Produktion.

Das ist es wert

All diese Arbeit ist nicht einfach und wird nie fertig oder perfekt sein. Aber es lohnt sich.

Ihr Team hat eine klarere Vorstellung davon, was vor sich geht, statt in Panik zu geraten, wenn etwas schief geht. Sie können sich auf das Problem konzentrieren und haben ein klares Zeichen dafür, wann sie fertig sind.

Die Leute können nicht auf alles reagieren, als ob es sich um einen verrückten Notfall handeln würde. Wenn Sie Ihre SLAs verstehen und veröffentlichen, wissen die Leute, wann und wie sie mit einem Fehlerbudget arbeiten können. Wenn Sie Ihre Warnmeldungen anpassen, können sich die Leute auf die wirklichen Probleme konzentrieren, anstatt gegenüber dem Alarmlärm abzustumpfen.

Und vor allem: Tun Sie es, weil Ihnen Ihre Kunden am Herzen liegen. Wenn Sie die Überwachung Ihrer Dienste nicht optimieren und iterieren, geben Sie die Probleme direkt an sie weiter. Weitere Informationen zur Optimierung Ihrer Dienstkonfigurationen in PagerDuty finden Sie hier: https://support.pagerduty.com/docs/best-practices-service-configuration

Teilen Sie uns mit, was Sie über Service Monitoring denken. Wir würden gerne hören wie andere Menschen diesen Prozess durchlaufen.