SRE (Site Reliability Engineering) - ein Ansatz zur Sicherstellung der Verfügbarkeit von Webprojekten. Es wird als Framework für DevOps angesehen und beschreibt, wie DevOps-Praktiken erfolgreich angewendet werden können. Dieser Artikel ist eine Übersetzung von Kapitel 6, Überwachung verteilter Systeme, aus dem Buch Site Reliability Engineering von Google. Ich habe diese Übersetzung selbst angefertigt und mich auf meine eigenen Erfahrungen im Verständnis der Überwachungsprozesse verlassen. Im Telegrammkanal @monitorim_it und im Blog auf dem Medium habe ich auch einen Link zur Übersetzung des 4. Kapitels desselben Buches über die Ziele des Servicelevels veröffentlicht.

Übersetzung von Katze. Viel Spaß beim Lesen!

Die Google SRE-Teams verfügen über die Grundprinzipien und Best Practices für die Erstellung erfolgreicher Überwachungs- und Benachrichtigungssysteme. Dieses Kapitel enthält Empfehlungen zu Problemen, auf die ein Webseitenbesucher stoßen kann, und zur Lösung von Problemen, die die Anzeige von Webseiten erschweren.

Definitionen

Es gibt kein einziges Vokabular, das zur Diskussion von Überwachungsthemen verwendet wird. Selbst bei Google werden die folgenden Begriffe nicht häufig verwendet, wir listen jedoch die am häufigsten verwendeten Interpretationen auf.

Überwachung

Erfassung, Verarbeitung, Aggregation und Anzeige quantitativer Daten über das System in Echtzeit: Anzahl der Anfragen und Arten von Anfragen, Anzahl der Fehler und Arten von Fehlern, Bearbeitungszeit für Anfragen und Server-Verfügbarkeit.

White-Box-Überwachung

Überwachung basierend auf Metriken, die von internen Komponenten des Systems angezeigt werden, einschließlich Protokollen, Profilerstellungsmetriken der Java Virtual Machine oder HTTP-Handler, die interne Statistiken generieren.

Black-Box-Überwachung

Testen des Verhaltens der Anwendung aus Sicht des Benutzers.

Dashboard (Dashboards)

Eine Schnittstelle (normalerweise das Web), die einen Überblick über die wichtigsten Gesundheitsindikatoren für Dienste bietet. Das Dashboard verfügt möglicherweise über Filter, die Möglichkeit, anzuzeigende Indikatoren auszuwählen usw. Die Benutzeroberfläche wurde erstellt, um die wichtigsten Indikatoren für Benutzer zu identifizieren. Informationen für Mitarbeiter des technischen Supports können auch im Dashboard angezeigt werden: Anforderungswarteschlange, Liste der Fehler mit hoher Priorität, zugewiesener Techniker für einen bestimmten Verantwortungsbereich.

Alarm (Hinweis)

Benachrichtigungen, die von einer Person per E-Mail oder auf andere Weise empfangen werden sollen und die aufgrund von Fehlern oder einer Zunahme der Warteschlange von Anforderungen ausgelöst werden können. Benachrichtigungen werden wie folgt klassifiziert: Tickets, E-Mail-Benachrichtigungen und Messenger-Nachrichten.

Grundursache

Ein Softwaredefekt oder menschlicher Faktor, der nach Beseitigung nicht mehr auftreten sollte. Das Problem kann mehrere Hauptgründe haben: unzureichende Automatisierung von Prozessen, Softwarefehler, unzureichende Untersuchung der Logik der Anwendung. Jeder dieser Faktoren kann die Grundursache sein, und jeder von ihnen muss beseitigt werden.

Knoten und Maschine

Austauschbare Begriffe zur Bezeichnung einer einzelnen Instanz einer ausgeführten Anwendung auf einem physischen Server, einer virtuellen Maschine oder einem Container. Auf einem Computer können mehrere Dienste vorhanden sein. Dienstleistungen können sein:

• in Bezug zueinander: zum Beispiel ein Cache-Server und ein Webserver;
• Nicht verwandte Dienste auf einer einzigen Hardware: Zum Beispiel ein Code-Repository und ein Assistent für ein Konfigurationssystem wie Puppet oder Chef .

Drücken

Jede Änderung der Softwarekonfiguration.

Warum ist Überwachung erforderlich

Es gibt mehrere Gründe, warum Anwendungen überwacht werden sollten:

Lange Trendanalyse

Wie groß ist die Datenbank und wie schnell wächst sie? Wie verändert sich die tägliche Anzahl der Benutzer?

Leistungsvergleich

Sind Acme Bucket of Bytes 2.72-Abfragen schneller als Ajax DB 3.14? Um wie viel besser werden Anforderungen nach dem Auftreten eines zusätzlichen Knotens zwischengespeichert? Ist die Seite im Vergleich zur letzten Woche langsamer geworden?

Alarmierung (Benachrichtigungen)

Etwas ist kaputt und jemand muss es reparieren. Oder etwas wird bald kaputt gehen und jemand sollte es bald überprüfen.

Erstellen Sie Dashboards

Dashboards sollten grundlegende Fragen beantworten und einige der „4 goldenen Signale“ enthalten - Latenz, Verkehr, Fehler und Auslastung (Sättigung).

Durchführung einer retrospektiven Analyse (Debugging)

Die Verzögerung der Anforderungsverarbeitung hat zugenommen, und was ist noch ungefähr zur gleichen Zeit passiert?
Überwachungssysteme sind nützlich als Datenquelle für Business-Intelligence-Systeme und zur Vereinfachung der Analyse von Sicherheitsvorfällen. Da sich dieses Buch auf technische Bereiche konzentriert, in denen SREs über Fachwissen verfügen, werden hier keine Überwachungstechniken behandelt.

Durch Überwachung und Warnungen kann das System erkennen, ob ein Defekt vorliegt oder bevorsteht. Wenn sich das System nicht automatisch selbst wiederherstellen kann, möchten wir, dass die Warnmeldung von der Person analysiert, ermittelt, ob das Problem relevant ist, behoben und die Grundursache ermittelt wird. Wenn Sie keine Systemkomponenten prüfen, erhalten Sie niemals eine Warnung, nur weil „etwas seltsam erscheint“.

Das Aufladen menschlicher Warnmeldungen ist ein ziemlich teurer Zeitaufwand für die Mitarbeiter. Wenn ein Mitarbeiter arbeitet, unterbricht eine Warnung den Workflow. Wenn der Mitarbeiter zu Hause ist, unterbricht die Benachrichtigung die persönliche Zeit und möglicherweise den Schlaf. Wenn Warnungen zu häufig auftreten, scannen Mitarbeiter eingehende Warnungen schnell, verzögern sie oder ignorieren sie. Von Zeit zu Zeit ignorieren sie die reale Warnung, die von Geräuschereignissen verdeckt wird. Betriebsunterbrechungen können lange dauern, da Geräuschereignisse die schnelle Diagnose und Fehlerbehebung beeinträchtigen. Effiziente Warnsysteme haben ein gutes Signal-Rausch-Verhältnis.

Festlegung angemessener Erwartungen an ein Überwachungssystem

Das Einrichten der Überwachung einer komplexen Anwendung ist an sich eine schwierige technische Aufgabe. Selbst mit einer umfangreichen Infrastruktur von Tools zum Sammeln, Anzeigen und Warnen umfasst das Google SRE-Team mit 10 bis 12 Mitgliedern in der Regel ein oder zwei Personen, deren Hauptzweck die Erstellung und Wartung von Überwachungssystemen ist. Diese Zahl hat im Laufe der Zeit abgenommen, da wir die Überwachungsinfrastruktur generalisieren und zentralisieren, aber jedes SRE-Team verfügt normalerweise über mindestens ein Überwachungspersonal. Ich muss sagen, dass die SRE-Teams, obwohl es sehr interessant ist, die Dashboards des Überwachungssystems zu beobachten, Situationen sorgfältig vermeiden, in denen jemand auf den Bildschirm schauen muss, um Probleme zu überwachen.

Im Allgemeinen hat Google auf einfache und schnelle Überwachungssysteme mit optimalen Tools für die Post-Factum-Analyse umgestellt. Wir vermeiden "magische" Systeme, die versuchen, Schwellenwerte vorherzusagen oder die Grundursache automatisch zu erkennen. Sensoren, die unangemessene Inhalte in Endbenutzeranforderungen erkennen, sind die einzigen Gegenbeispiele. Solange diese Sensoren einfach bleiben, können sie schnell die Ursachen für schwerwiegende Anomalien identifizieren. Andere Formate für die Verwendung von Überwachungsdaten wie Kapazitätsplanung oder Verkehrsprognose sind schwieriger. Beobachtungen, die über einen sehr langen Zeitraum (Monate oder Jahre) mit einer geringen Stichprobenrate (Stunden oder Tage) durchgeführt wurden, lassen einen langfristigen Trend erkennen.

Das Google SRE-Team hat mit unterschiedlichem Erfolg mit komplexen Abhängigkeitshierarchien gearbeitet. Wir verwenden selten Regeln wie "Wenn ich feststelle, dass die Datenbank langsam arbeitet, erhalte ich eine Benachrichtigung über die Verlangsamung der Datenbank, ansonsten erhalte ich eine Warnung über eine langsam laufende Site." Abhängigkeitsbasierte Regeln gelten normalerweise für unveränderliche Teile unseres Systems, z. B. für ein System zum Filtern des Benutzerverkehrs zu einem Rechenzentrum. Beispiel: "Wenn die Verkehrsfilterung für das Rechenzentrum konfiguriert ist, warnen Sie mich nicht vor Verzögerungen bei der Verarbeitung von Benutzeranforderungen." Dies ist eine allgemeine Regel für Benachrichtigungen vom Rechenzentrum. Nur wenige Teams bei Google unterstützen komplexe Abhängigkeitshierarchien, da unsere Infrastruktur eine konstante kontinuierliche Refactoring-Rate aufweist.

Einige der in diesem Kapitel beschriebenen Ideen sind immer noch relevant: Es besteht immer die Möglichkeit, schneller von einem Symptom zu einer Grundursache zu gelangen, insbesondere in sich ständig ändernden Systemen. Daher ist es wichtig, dass die Überwachungssysteme, obwohl in diesem Kapitel einige Ziele für Überwachungssysteme und Wege zur Erreichung dieser Ziele aufgeführt sind, für alle im Team einfach und verständlich sind.

Um einen niedrigen Rauschpegel und einen hohen Signalpegel aufrechtzuerhalten, sollten Ansätze zum Überwachen von Objekten, für die Warnungen gemacht werden, ebenfalls sehr einfach und zuverlässig sein. Regeln, die Warnungen für Personen auslösen, sollten leicht verständlich sein und ein klares Problem darstellen.

Symptome und Ursachen

Ihr Überwachungssystem sollte zwei Fragen beantworten: „Was ist kaputt?“ Und „Warum ist kaputt?“.
"Was ist kaputt" spricht von dem Symptom und "warum ist es kaputt" von der Ursache. Die folgende Tabelle zeigt Beispiele für solche Bundles.

"Was" und "Warum" sind einige der wichtigsten Bausteine ​​für die Schaffung eines guten Überwachungssystems mit maximalem Signal und minimalem Rauschen.

Black-Box gegen White-Box

Wir kombinieren eine umfassende White-Box-Überwachung mit einer bescheidenen Black-Box-Überwachung für kritische Messdaten. Der einfachste Weg, die Black-Box mit der White-Box zu vergleichen, besteht darin, dass die Black-Box symptomorientiert ist und eher reaktiv als proaktiv überwacht wird: "Das System funktioniert gerade nicht." Das weiße Feld hängt von den Funktionen der internen Systemüberprüfung ab: Ereignisprotokolle oder Webserver. So können Sie mit der White-Box zukünftige Probleme, Fehlfunktionen, die wie eine erneute Übertragung einer Anfrage aussehen, usw. erkennen.

Bitte beachten Sie, dass in einem Mehrschichtsystem ein Symptom im Verantwortungsbereich eines Ingenieurs ein Symptom im Verantwortungsbereich eines anderen Ingenieurs ist. Beispielsweise hat die Datenbankleistung abgenommen. Langsame Datenbanklesevorgänge sind ein Symptom für SREs in Datenbanken, die sie erkennen. Für das Front-End-SRE, das eine langsame Website beobachtet, ist der Grund für dasselbe langsame Lesen der Datenbank die langsame Operation der Datenbank. Daher konzentriert sich die White-Box-Überwachung manchmal auf Symptome und manchmal auf Gründe, je nachdem, wie umfangreich sie ist.

Bei der Erfassung der Telemetrie ist für das Debugging eine White-Box-Überwachung erforderlich. Wenn Webserver langsam auf Datenbankabfragen reagieren, müssen Sie wissen, wie schnell der Webserver mit der Datenbank interagiert und wie schnell er reagiert. Andernfalls können Sie einen langsamen Datenbankserver nicht von einem Netzwerkproblem zwischen dem Webserver und der Datenbank unterscheiden.

Die Black-Box-Überwachung hat beim Senden von Warnungen einen entscheidenden Vorteil: Sie leiten eine Benachrichtigung an den Empfänger ein, wenn das Problem bereits zu echten Symptomen geführt hat. Bei einem noch nicht aufgetretenen, aber anstehenden Black-Box-Problem ist die Überwachung hingegen nutzlos.

Vier goldene Signale

Die vier goldenen Überwachungssignale sind Latenz, Verkehr, Fehler und Sättigung. Wenn Sie in einem Benutzersystem nur vier Metriken messen können, konzentrieren Sie sich auf diese vier.

Verzögerung

Die zur Verarbeitung der Anforderung erforderliche Zeit. Es ist wichtig, zwischen der Verzögerung erfolgreicher und nicht erfolgreicher Anforderungen zu unterscheiden. Beispielsweise kann ein HTTP 500-Fehler, der durch einen Verbindungsverlust zu einer Datenbank oder einem anderen Backend verursacht wird, sehr schnell diagnostiziert werden. Ein HTTP 500-Fehler kann jedoch auf eine fehlgeschlagene Anforderung hinweisen. Das Erkennen der Auswirkung des Fehlers 500 auf die Gesamtverzögerung kann zu fehlerhaften Schlussfolgerungen führen. Andererseits ist ein langsamer Fehler sogar ein schneller Fehler! Daher ist es wichtig, die Verzögerung mit einem Fehler zu verfolgen und nicht nur die Fehler zu filtern.

Verkehr

Die Anzahl der Anforderungen an Ihr System wird in allgemeinen Systemmetriken gemessen. Bei einem Webdienst stellt diese Dimension in der Regel die Anzahl der HTTP-Anforderungen pro Sekunde dar, die durch die Art der Anforderung getrennt sind (z. B. statischer oder dynamischer Inhalt). Bei einem Streaming-Audiosystem kann diese Messung auf die E / A-Geschwindigkeit des Netzwerks oder die Anzahl der gleichzeitigen Sitzungen konzentriert werden. Für ein Schlüsselwertspeichersystem kann eine solche Messung Transaktionen oder Suchergebnisse pro Sekunde sein.

Fehler

Dies ist die Häufigkeit nicht erfolgreicher Anfragen, die explizit (z. B. HTTP 500), implizit (z. B. HTTP 200, aber in Kombination mit dem falschen Inhalt) oder einer Richtlinie (z. B. "Wenn Sie die Antwort in einer Sekunde aufgezeichnet haben, ist jede Sekunde ein Fehler") sind. Wenn die HTTP-Protokollantwortcodes nicht ausreichen, um alle Fehlerbedingungen auszudrücken, sind möglicherweise sekundäre (interne) Protokolle erforderlich, um einen teilweisen Fehler zu erkennen. Das Überwachen all dieser fehlerhaften Anforderungen ist möglicherweise nicht aussagekräftig. Durch End-to-End-Systemtests können Sie feststellen, dass Sie den falschen Inhalt verarbeiten.

Sättigung

Die Metrik zeigt an, wie stark Ihr Service genutzt wird. Hierbei handelt es sich um eine Systemüberwachungsmaßnahme, mit der die Ressourcen identifiziert werden, die am meisten eingeschränkt sind (in einem System mit begrenztem Arbeitsspeicher wird beispielsweise der Arbeitsspeicher angezeigt, in einem System mit E / A-Einschränkungen wird die Anzahl der E / A angezeigt). Beachten Sie, dass viele Systeme die Leistung beeinträchtigen, bevor sie zu 100% ausgelastet sind. Daher ist es wichtig, einen Verwendungszweck zu haben.

In komplexen Systemen kann die Sättigung durch die Messung einer höheren Auslastung ergänzt werden: Kann Ihr Service den doppelten Datenverkehr ordnungsgemäß verarbeiten, nur 10% mehr Datenverkehr verarbeiten oder noch weniger Datenverkehr verarbeiten als derzeit? Bei einfachen Diensten, deren Parameter die Komplexität der Anforderung nicht ändern (z. B. "Gib mir nichts" oder "Ich benötige eine eindeutige monotone Ganzzahl"), deren Konfiguration selten geändert wird, ist der statische Wert des Auslastungstests möglicherweise ausreichend In den meisten Diensten sollten indirekte Signale wie die CPU-Auslastung oder die Netzwerkbandbreite verwendet werden, für die eine Obergrenze bekannt ist. Eine erhöhte Latenz ist häufig ein Hauptindikator für die Sättigung. Die Messung der Reaktionszeit des 99. Perzentils in einem kleinen Fenster (z. B. eine Minute) kann zu einem sehr frühen Sättigungssignal führen.

Schließlich wird die Sättigung auch mit Vorhersagen einer bevorstehenden Sättigung in Verbindung gebracht, zum Beispiel: "Es sieht so aus, als würde Ihre Datenbank Ihre Festplatte in 4 Stunden füllen."

Wenn Sie alle vier goldenen Signale messen und wenn ein Problem mit einer der Metriken auftritt (oder im Falle einer Sättigung fast ein Problem), benachrichtigen Sie die Person, wird Ihr Service mehr oder weniger überwacht.

Angst vor dem Schwanz (oder Instrumentierung und Leistung)

Wenn Sie ein Überwachungssystem von Grund auf neu erstellen, ist es verlockend, ein System zu entwickeln, das auf Durchschnittswerten basiert: durchschnittliche Latenz, durchschnittliche CPU-Auslastung von Knoten oder durchschnittliche Datenbankbelegung. Die Gefahr der letzten beiden Beispiele liegt auf der Hand: Prozessoren und Datenbanken werden auf sehr unvorhersehbare Weise entsorgt. Das gleiche gilt für die Verzögerung. Wenn Sie einen Webdienst mit einer durchschnittlichen Verzögerung von 100 ms bei 1000 Anforderungen pro Sekunde ausführen, kann 1% der Anforderungen 5 Sekunden dauern. Wenn Benutzer von mehreren dieser Webdienste abhängig sind, kann das 99. Perzentil eines Backends leicht zur mittleren Antwortzeit der Benutzeroberfläche werden.

Die einfachste Möglichkeit, zwischen einem langsamen Durchschnitt und einem sehr langsamen "Ende" von Abfragen zu unterscheiden, besteht darin, statt tatsächlicher Verzögerungen die in Statistiken ausgedrückten Abfragedimensionen zu erfassen (ein geeignetes Werkzeug zum Anzeigen von Histogrammen): Wie viele Anforderungen wurden vom Dienst bearbeitet, die zwischen 0 ms und 0 ms dauerten? 10 ms, zwischen 10 ms und 30 ms, zwischen 30 ms und 100 ms, zwischen 100 ms und 300 ms usw. Das Erweitern der Histogrammgrenzen ungefähr exponentiell (mit einem ungefähren Koeffizienten von 3) ist oft eine einfache Möglichkeit, die Verteilung von Abfragen zu visualisieren.

Auswahl der richtigen Detaillierungsstufe für Messungen

Verschiedene Elemente des Systems müssen mit unterschiedlichem Detaillierungsgrad gemessen werden. Zum Beispiel:

• Die Überwachung der CPU-Auslastung in einem bestimmten Zeitintervall zeigt keine langfristigen Ausreißer, die zu hohen Latenzen führen.
• Bei einem Webdienst, der sich auf nicht mehr als 9 Stunden Ausfallzeit pro Jahr konzentriert (99,9% der jährlichen Betriebszeit), ist es wahrscheinlich unnötig, mehr als ein- oder zweimal pro Minute nach einer HTTP-Antwort von 200 zu suchen.
• Ebenso ist es wahrscheinlich nicht erforderlich, mehr als einmal alle 1-2 Minuten nach freiem Festplattenspeicher für 99,9% Verfügbarkeit zu suchen.

Achten Sie darauf, wie Sie die Granularität der Dimensionen strukturieren. Die Häufigkeit, mit der die CPU-Last einmal pro Sekunde erfasst wird, kann interessante Daten liefern. Die Erfassung, Speicherung und Analyse solcher häufigen Messungen kann jedoch sehr kostspielig sein. , , , . :

1. CPU .
2. 5%.
3. .

, .

,

. , :

• , , .
• .
• .

. , , , .

. , , :

• , , , .
• , , (, SRE), .
• , , - - , .

Google , , ( Google , ). : , , , , . , . , , , (, -API , ).

, , , Google SRE. , .

, , :

• , , , ?
• , , ? ?
• , ? , , , - , ?
• ? ? ? ?
• , ?

:

• , , . , .
• .
• . , .
• , .

: , , White-box Black-Box. : , ; , .

, . , , , , , . - ; , .

, . , , , , . , .

Bigtable SRE:

Google (SLO). SLO Bigtable . - Bigtable ​​«» : 5% .

SLO, SLO. , : , , . , , . - , .

, : Bigtable, SLO 75- . , , .

, Bigtable , . , . , .

Gmail: ,

Gmail Workqueue, . Workqueue Gmail, .

Gmail , , Workqueue. , Gmail , . , Gmail , .

, Gmail SRE , , . , , , , .

: , , . , , , . , , «» .

. , , . , .

Bigtable Gmail: . , , .

, , . , , , . ( , ) , , , .

Fazit

. , , . , , , . , , ; , , . , .

, , , .

, . - @monitorim_it .