SRE (Site Reliability Engineering) ist ein Ansatz zur Sicherstellung der Verfügbarkeit von Webprojekten. Es gilt als Rahmenwerk für DevOps und befasst sich mit der erfolgreichen Anwendung von DevOps-Praktiken. Übersetzung in diesem Artikel Bücher von Google. Ich habe diese Übersetzung selbst erstellt und mich auf meine eigene Erfahrung im Verständnis von Überwachungsprozessen verlassen. Im Telegrammkanal и Ich habe auch einen Link zur Übersetzung von Kapitel 4 desselben Buches über Service-Level-Ziele veröffentlicht.
Übersetzung nach Kat. Viel Spaß beim Lesen!
Die SRE-Teams von Google verfügen über Grundprinzipien und Best Practices für die Erstellung erfolgreicher Überwachungs- und Benachrichtigungssysteme. Dieses Kapitel enthält Hinweise dazu, auf welche Probleme ein Webseitenbesucher stoßen könnte und wie Probleme gelöst werden können, die die Anzeige von Webseiten erschweren.
definieren
Es gibt kein einheitliches Vokabular zur Diskussion von Überwachungsthemen. Selbst bei Google werden die folgenden Begriffe nicht häufig verwendet, wir listen jedoch die häufigsten Interpretationen auf.
Überwachung
Erfassung, Verarbeitung, Aggregation und Anzeige quantitativer Daten in Echtzeit über das System: Anzahl der Anfragen und Anfragetypen, Anzahl der Fehler und Fehlertypen, Anfragebearbeitungszeit und Serververfügbarkeit.
White-Box-Überwachung
Überwachung basierend auf Metriken, die von internen Systemkomponenten angezeigt werden, einschließlich Protokollen, Java Virtual Machine-Profiling-Metriken oder HTTP-Handler-Metriken, die interne Statistiken generieren.
Black-Box-Überwachung
Testen des Anwendungsverhaltens aus Benutzersicht.
Armaturenbrett
Eine Schnittstelle (normalerweise im Internet), die einen Überblick über die wichtigsten Gesundheitsindikatoren von Diensten bietet. Das Dashboard verfügt möglicherweise über Filter, die Möglichkeit, die angezeigten Indikatoren auszuwählen usw. Die Benutzeroberfläche ist darauf ausgelegt, die Indikatoren zu identifizieren, die für Benutzer am wichtigsten sind. Das Dashboard kann auch Informationen für Mitarbeiter des technischen Supports anzeigen: eine Warteschlange mit Anfragen, eine Liste von Fehlern mit hoher Priorität und einen zugewiesenen Techniker für einen bestimmten Verantwortungsbereich.
Warnung (Benachrichtigung)
Benachrichtigungen, die dazu bestimmt sind, von einer Person per E-Mail oder auf andere Weise empfangen zu werden, und die durch Fehler oder eine Vergrößerung der Anforderungswarteschlange ausgelöst werden können. Benachrichtigungen werden klassifiziert als: Tickets, E-Mail-Benachrichtigungen und Instant Messenger-Nachrichten.
Grundursache
Ein Softwarefehler oder menschliches Versagen, der nach der Korrektur nicht erneut auftreten sollte. Das Problem kann mehrere Hauptursachen haben: unzureichende Prozessautomatisierung, Softwarefehler, unzureichende Ausarbeitung der Anwendungslogik. Jeder dieser Faktoren kann die Grundursache sein und jeder von ihnen muss beseitigt werden.
Knoten und Maschine (Knoten und Maschine)
Austauschbare Begriffe, die sich auf eine einzelne Instanz einer laufenden Anwendung auf einem physischen Server, einer virtuellen Maschine oder einem Container beziehen. Eine Maschine kann mehrere Dienste hosten. Dienstleistungen können sein:
- miteinander verbunden: zum Beispiel ein Caching-Server und ein Webserver;
- unabhängige Dienste auf einer einzigen Hardware: zum Beispiel ein Code-Repository und ein Assistent für ein Konfigurationssystem, wie z oder .
Push
Jede Änderung der Softwarekonfiguration.
Warum ist eine Überwachung erforderlich?
Es gibt mehrere Gründe, warum Anwendungen überwacht werden müssen:
Analyse langfristiger Trends
Wie groß ist die Datenbank und wie schnell wächst sie? Wie verändert sich die tägliche Nutzerzahl?
Leistungsvergleich
Sind Anfragen auf Acme Bucket of Bytes 2.72 schneller als auf Ajax DB 3.14? Wie viel besser werden Anfragen nach dem Erscheinen eines zusätzlichen Knotens zwischengespeichert? Läuft die Website im Vergleich zur letzten Woche langsamer?
Alarmierung (Benachrichtigungen)
Etwas ist kaputt und jemand muss es reparieren. Oder es geht bald etwas kaputt und jemand muss es bald überprüfen.
Dashboards erstellen
Dashboards sollten grundlegende Fragen beantworten und etwas davon enthalten — Verzögerungen (Latenz), Verkehr (Verkehr), Fehler (Errors) und Lastgröße (Sättigung).
Durchführung einer retrospektiven Analyse (Debugging)
Die Verzögerung bei der Bearbeitung der Anfrage hat zugenommen, aber was ist ungefähr zur gleichen Zeit sonst noch passiert?
Überwachungssysteme eignen sich als Datenquelle für Business-Intelligence-Systeme und erleichtern die Analyse von Sicherheitsvorfällen. Da sich dieses Buch auf technische Bereiche konzentriert, in denen SREs über Fachwissen verfügen, werden wir hier nicht auf Überwachungstechniken eingehen.
Überwachung und Warnungen ermöglichen es dem System, Sie darüber zu informieren, wenn es ausgefallen ist oder kurz vor einem Ausfall steht. Wenn sich ein System nicht automatisch selbst reparieren kann, möchten wir, dass ein Mensch die Warnung analysiert, feststellt, ob das Problem noch aktiv ist, es behebt und die Grundursache ermittelt. Wenn Sie Systemkomponenten nicht prüfen, erhalten Sie nie eine Warnung, nur weil „etwas etwas seltsam erscheint“.
Eine Person mit Benachrichtigungen zu belasten ist eine ziemlich kostspielige Zeitverschwendung eines Mitarbeiters. Wenn der Mitarbeiter arbeitet, unterbricht die Warnung den Arbeitsprozess. Wenn der Mitarbeiter zu Hause ist, unterbricht der Alarm die Freizeit und möglicherweise auch den Schlaf. Wenn Benachrichtigungen zu häufig auftreten, überfliegen Mitarbeiter diese, schieben sie auf die lange Bank oder ignorieren eingehende Benachrichtigungen. Von Zeit zu Zeit ignorieren sie den eigentlichen Alarm, der durch Lärmereignisse überdeckt wird. Betriebsunterbrechungen können lange dauern, da Lärmereignisse eine schnelle Diagnose und Behebung des Problems verhindern. Effektive Warnsysteme zeichnen sich durch ein gutes Signal-Rausch-Verhältnis aus.
Setzen angemessener Erwartungen an das Überwachungssystem
Das Einrichten der Überwachung für eine komplexe Anwendung ist an sich schon eine komplexe technische Aufgabe. Selbst mit einer umfangreichen Infrastruktur an Erfassungs-, Anzeige- und Benachrichtigungstools umfasst ein Google SRE-Team mit 10 bis 12 Mitgliedern in der Regel ein oder zwei Personen, deren Hauptaufgabe darin besteht, Überwachungssysteme aufzubauen und zu warten. Diese Zahl ist im Laufe der Zeit zurückgegangen, da wir die Überwachungsinfrastruktur konsolidiert und zentralisiert haben, aber jedes SRE-Team verfügt in der Regel über mindestens eine Person, die sich ausschließlich der Überwachung widmet. Wir müssen sagen, dass die Dashboards von Überwachungssystemen zwar sehr interessant anzusehen sind, SRE-Teams jedoch sorgfältig Situationen vermeiden, in denen jemand auf einen Bildschirm schauen muss, um Probleme zu überwachen.
Insgesamt ist Google zu einfachen und schnellen Überwachungssystemen mit optimalen nachträglichen Analysetools übergegangen. Wir vermeiden „magische“ Systeme, die versuchen, Schwellenwerte vorherzusagen oder die Grundursache automatisch zu erkennen. Das einzige Gegenbeispiel sind Sensoren, die unbeabsichtigte Inhalte in Endbenutzeranfragen erkennen. Solange diese Sensoren einfach bleiben, können sie die Ursachen schwerwiegender Anomalien schnell erkennen. Andere Formate zur Nutzung von Überwachungsdaten, etwa zur Kapazitätsplanung oder Verkehrsprognose, sind komplexer. Die Beobachtung über einen sehr langen Zeitraum (Monate oder Jahre) mit einer geringen Abtastrate (Stunden oder Tage) zeigt einen langfristigen Trend.
Das Google SRE-Team hatte gemischte Erfolge mit komplexen Abhängigkeitshierarchien. Wir verwenden selten Regeln wie „Wenn ich herausfinde, dass die Datenbank langsam ist, erhalte ich eine Benachrichtigung, dass die Datenbank langsam ist, andernfalls erhalte ich eine Benachrichtigung, dass die Website langsam ist.“ Abhängigkeitsbasierte Regeln beziehen sich typischerweise auf unveränderliche Teile unseres Systems, beispielsweise das System zum Filtern des Benutzerverkehrs zum Rechenzentrum. Eine allgemeine Regel für Benachrichtigungen vom Rechenzentrum lautet beispielsweise: „Wenn die Datenverkehrsfilterung zum Rechenzentrum konfiguriert ist, benachrichtigen Sie mich nicht über Verzögerungen bei der Verarbeitung von Benutzeranfragen.“ Nur wenige Teams bei Google unterstützen komplexe Abhängigkeitshierarchien, da unsere Infrastruktur eine konstante Refaktorisierungsrate aufweist.
Einige der in diesem Kapitel beschriebenen Ideen sind immer noch relevant: Es besteht immer die Möglichkeit, schneller vom Symptom zur Grundursache zu gelangen, insbesondere in sich ständig verändernden Systemen. Obwohl in diesem Kapitel einige Ziele für Überwachungssysteme und die Art und Weise beschrieben werden, wie diese Ziele erreicht werden können, ist es wichtig, dass Überwachungssysteme einfach und für jeden im Team verständlich sind.
Ebenso müssen Ansätze zur Überwachung alarmierter Anlagen sehr einfach und zuverlässig sein, um den Geräuschpegel niedrig und die Signalpegel hoch zu halten. Regeln, die Warnungen für Personen generieren, sollten leicht verständlich sein und ein klares Problem darstellen.
Symptome versus Ursachen
Ihr Überwachungssystem sollte zwei Fragen beantworten: „Was ist kaputt gegangen“ und „Warum ist es kaputt gegangen.“
„Was kaputt ging“ spricht über das Symptom und „warum es kaputt ging“ spricht über die Ursache. Die folgende Tabelle zeigt Beispiele für solche Verbindungen.
Symptom
Verursachen
Es wird HTTP-Fehler 500 oder 404 angezeigt
Datenbankserver lehnen Verbindungen ab
Langsame Serverantworten
Hohe CPU-Auslastung oder beschädigtes Ethernet-Kabel
Benutzer in der Antarktis erhalten keine Katzen-GIFs
Ihr CDN hasst Wissenschaftler und Katzen, daher wurden einige IP-Adressen auf die schwarze Liste gesetzt
Private Inhalte sind von überall verfügbar geworden
Die Einführung einer neuen Softwareversion führte dazu, dass die Firewall alle ACLs vergaß und alle hereinließ
„Was“ und „Warum“ sind einige der wichtigsten Bausteine für die Schaffung eines guten Überwachungssystems mit maximalem Signal und minimalem Rauschen.
Black-Box vs. White-Box
Wir kombinieren eine umfassende White-Box-Überwachung mit einer bescheidenen Black-Box-Überwachung für kritische Kennzahlen. Der einfachste Weg, Black-Box mit White-Box zu vergleichen, besteht darin, dass Black-Box symptomorientiert ist und eher eine reaktive als eine proaktive Überwachung durchführt: „Das System funktioniert im Moment nicht richtig.“ White-Box hängt von den internen Verifizierungsfähigkeiten der Systeme ab: Ereignisprotokolle oder Webserver. Auf diese Weise können Sie mit White-Box drohende Probleme, Fehler, die auf eine erneute Übertragung einer Anfrage zurückzuführen sind, usw. erkennen.
Beachten Sie, dass in einem mehrschichtigen System 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 der Datenbank-SRE, die sie erkennt. Wenn jedoch ein Front-End-SRE eine langsame Website beobachtet, ist die Ursache für denselben langsamen Datenbanklesevorgang eine langsame Datenbank. Daher ist die White-Box-Überwachung je nach Umfang manchmal symptomorientiert und manchmal ursachenorientiert.
Beim Sammeln von Telemetriedaten zum Debuggen ist eine White-Box-Überwachung erforderlich. Wenn Webserver langsam auf Datenbankanfragen reagieren, müssen Sie wissen, wie schnell der Webserver mit der Datenbank kommuniziert und wie schnell er antwortet. Andernfalls können Sie nicht zwischen einem langsamen Datenbankserver und einem Netzwerkproblem zwischen Webserver und Datenbank unterscheiden.
Beim Versenden von Alarmen hat die Blackbox-Überwachung einen entscheidenden Vorteil: Sie lösen die Benachrichtigung an den Empfänger aus, wenn das Problem bereits zu echten Symptomen geführt hat. Andererseits ist die Überwachung bei einem Black-Box-Problem, das noch nicht aufgetreten ist, aber unmittelbar bevorsteht, nutzlos.
Vier goldene Signale
Die vier goldenen Überwachungssignale sind Latenz, Datenverkehr, Fehler und Sättigung. Wenn Sie nur vier Benutzersystemmetriken messen können, konzentrieren Sie sich auf diese vier.
Verzögert
Die zur Bearbeitung der Anfrage erforderliche Zeit. Es ist wichtig, zwischen der Latenz erfolgreicher und erfolgloser Anfragen 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 Anfrage hinweisen. Die Bestimmung der Auswirkung eines 500-Fehlers auf die Gesamtlatenz kann zu falschen Schlussfolgerungen führen. Andererseits ist ein langsamer Fehler sogar ein schneller Fehler! Daher ist es wichtig, die Fehlerlatenz zu überwachen, anstatt Fehler einfach herauszufiltern.
Трафик
Die Anzahl der Anfragen an Ihr System wird in übergeordneten Systemmetriken gemessen. Für einen Webdienst stellt diese Messung typischerweise die Anzahl der HTTP-Anfragen pro Sekunde dar, geteilt durch die Art der Anfragen (z. B. statischer oder dynamischer Inhalt). Bei einem Audio-Streaming-System kann sich diese Messung auf die Netzwerk-E/A-Geschwindigkeit oder die Anzahl gleichzeitiger Sitzungen konzentrieren. Bei einem Schlüsselwertspeichersystem könnte diese Messung Transaktionen oder Suchergebnisse pro Sekunde sein.
Fehler
Dies ist die Rate fehlgeschlagener Anfragen, die explizit (z. B. HTTP 500), implizit (z. B. HTTP 200, aber in Kombination mit ungültigem Inhalt) oder richtlinienbedingt (z. B. „Wenn Sie in einer Sekunde eine Antwort erfasst haben, ist jede Sekunde ein Fehler“) fehlschlagen. Wenn HTTP-Antwortcodes nicht ausreichen, um alle Fehlerbedingungen auszudrücken, sind möglicherweise sekundäre (interne) Protokolle erforderlich, um Teilfehler zu erkennen. Die Überwachung aller dieser fehlgeschlagenen Anfragen ist möglicherweise nicht aussagekräftig, während durchgängige Systemtests dabei helfen, festzustellen, ob Sie falsche Inhalte verarbeiten.
Sättigung
Die Metrik zeigt, wie intensiv Ihr Service genutzt wird. Hierbei handelt es sich um eine Systemüberwachungsmaßnahme, die die Ressourcen identifiziert, die am stärksten eingeschränkt sind (z. B. wird auf einem System mit eingeschränktem Speicher der Speicher angezeigt, auf einem System mit eingeschränkten E/As wird die Anzahl der E/As angezeigt). Beachten Sie, dass die Leistung vieler Systeme abnimmt, bevor sie eine 100-prozentige Auslastung erreichen. Daher ist es wichtig, ein Auslastungsziel festzulegen.
In komplexen Systemen kann die Sättigung durch Lastmessungen auf höherer Ebene ergänzt werden: Kann Ihr Dienst doppelten Datenverkehr ordnungsgemäß verarbeiten, nur 10 % mehr Datenverkehr verarbeiten oder sogar weniger Datenverkehr als derzeit verarbeiten? Für einfache Dienste, die keine Parameter haben, die die Komplexität der Anfrage ändern (z. B. „Gib mir nichts“ oder „Ich benötige eine eindeutige einzelne monotone Ganzzahl“), und deren Konfiguration sich selten ändert, kann ein statischer Auslastungstestwert ausreichend sein. Wie im vorherigen Absatz erläutert, müssen die meisten Dienste jedoch indirekte Signale wie CPU-Auslastung oder Netzwerkbandbreite verwenden, für die eine bekannte Obergrenze gilt. Eine zunehmende Latenz ist oft ein Frühindikator für die Sättigung. Die Messung der 99. Perzentil-Reaktionszeit in einem kleinen Fenster (z. B. einer Minute) kann ein sehr frühes Sättigungssignal liefern.
Schließlich wird die Sättigung auch mit Vorhersagen über eine bevorstehende 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 bei einem Problem mit einer der Metriken (oder, im Falle der Sättigung, einem Beinahe-Problem) eine Person alarmieren, wird Ihr Dienst mehr oder weniger von der Überwachung erfasst.
Sorgen um den „Schwanz“ (oder Instrumentierung und Leistung)
Wenn Sie ein Überwachungssystem von Grund auf neu erstellen, besteht die Versuchung, ein System auf der Grundlage von Durchschnittswerten zu entwickeln: durchschnittliche Latenz, durchschnittliche CPU-Auslastung der Knoten oder durchschnittliche Datenbankfülle. Die Gefahr der letzten beiden Beispiele liegt auf der Hand: Prozessoren und Datenbanken werden auf sehr unvorhersehbare Weise entsorgt. Gleiches gilt bei Verzug. Wenn Sie einen Webdienst mit einer durchschnittlichen Latenz von 100 ms und 1000 Anfragen pro Sekunde ausführen, kann es sein, dass 1 % der Anfragen 5 Sekunden dauern. Wenn Benutzer auf mehrere solcher Webdienste angewiesen sind, kann das 99. Perzentil eines Backends leicht zur mittleren Antwortzeit des Frontends werden.
Der einfachste Weg, zwischen dem langsamen Durchschnitt und dem sehr langsamen Ende von Anfragen zu unterscheiden, besteht darin, Messwerte von Anfragen zu sammeln, die in Statistiken ausgedrückt werden (ein gutes Werkzeug zur Anzeige sind Histogramme), und nicht die tatsächlichen Latenzen: wie viele Anfragen der Dienst bedient hat, die zwischen 0 ms und 10 ms gedauert haben und 10 ms, zwischen 30 ms und 30 ms, zwischen 100 ms und 100 ms, zwischen 300 ms und 3 ms usw. Die annähernd exponentielle Erweiterung der Histogrammgrenzen (ungefähr um den Faktor XNUMX) ist oft eine einfache Möglichkeit, die Verteilung zu visualisieren von Anfragen.
Auswahl des geeigneten Detaillierungsgrades für Messungen
Verschiedene Elemente des Systems müssen auf unterschiedlichen Detaillierungsebenen gemessen werden. Zum Beispiel:
- Die Überwachung der CPU-Auslastung über einen bestimmten Zeitraum hinweg zeigt keine langfristigen Spitzen, die zu hohen Latenzen führen.
- Andererseits ist es bei einem Webdienst, der eine Ausfallzeit von nicht mehr als 9 Stunden pro Jahr anstrebt (99,9 % jährliche Betriebszeit), wahrscheinlich unnötig häufig, mehr als ein- oder zweimal pro Minute auf eine HTTP-200-Antwort zu prüfen.
- Ebenso ist es wahrscheinlich nicht notwendig, den Festplattenspeicher mehr als einmal alle 99,9–1 Minuten auf eine Verfügbarkeit von 2 % zu überprüfen.
Achten Sie darauf, wie Sie die Granularität Ihrer Messungen strukturieren. Das Erfassen der CPU-Auslastung einmal pro Sekunde kann interessante Daten liefern, aber derart häufige Messungen können sehr kostspielig sein, sie zu sammeln, zu speichern und zu analysieren. Wenn Ihr Überwachungsziel eine hohe Granularität und keine hohe Reaktionsfähigkeit erfordert, können Sie diese Kosten reduzieren, indem Sie die Erfassung von Metriken auf dem Server einrichten und dann ein externes System zum Sammeln und Aggregieren dieser Metriken einrichten. Könnten Sie:
- Messen Sie die CPU-Auslastung jede Sekunde.
- Reduzieren Sie die Details auf 5 %.
- Aggregieren Sie jede Minute Kennzahlen.
Mit dieser Strategie können Sie Daten mit hoher Granularität erfassen, ohne dass ein hoher Analyse- und Speicheraufwand entsteht.
So einfach wie möglich, aber nicht einfacher
Durch die Überlagerung unterschiedlicher Anforderungen kann ein sehr komplexes Überwachungssystem entstehen. Beispielsweise kann Ihr System die folgenden erschwerenden Elemente aufweisen:
- Warnungen nach unterschiedlichen Schwellenwerten für die Latenz der Anforderungsverarbeitung, in unterschiedlichen Perzentilen und für alle Arten von unterschiedlichen Indikatoren.
- Schreiben von zusätzlichem Code, um mögliche Ursachen zu erkennen und zu identifizieren.
- Erstellen Sie zugehörige Dashboards für jede der möglichen Problemursachen.
Die Quellen potenzieller Komplikationen nehmen kein Ende. Wie alle Softwaresysteme kann die Überwachung so komplex werden, dass sie fragil und schwierig zu ändern und zu warten ist.
Gestalten Sie Ihr Überwachungssystem daher so, dass es so einfach wie möglich ist. Beachten Sie bei der Auswahl der zu verfolgenden Daten Folgendes:
- Die Regeln, die am häufigsten reale Vorfälle erfassen, sollten so einfach, vorhersehbar und zuverlässig wie möglich sein.
- Konfigurationen für die Datenerfassung, -aggregation und -warnung, die selten durchgeführt werden (z. B. weniger als vierteljährlich für einige SRE-Teams), sollten entfernt werden.
- Metriken, die erfasst, aber nicht in einem Vorschau-Dashboard angezeigt oder von einer Warnung verwendet werden, können gelöscht werden.
Bei Google funktioniert die Erfassung und Aggregation grundlegender Metriken in Verbindung mit Warnungen und Dashboards gut als relativ eigenständiges System (das Überwachungssystem von Google ist eigentlich in mehrere Subsysteme unterteilt, aber die Leute sind sich normalerweise aller Aspekte dieser Subsysteme bewusst). Es kann verlockend sein, die Überwachung mit anderen Methoden zur Untersuchung komplexer Systeme zu kombinieren: detaillierte Systemprofilierung, Prozess-Debugging, Verfolgung von Details zu Ausnahmen oder Fehlern, Lasttests, Protokollerfassung und -analyse oder Verkehrsinspektion. Während die meisten dieser Dinge Gemeinsamkeiten mit der grundlegenden Überwachung aufweisen, führt eine Verwechslung zu zu vielen Ergebnissen und führt zu einem komplexen und fragilen System. Wie bei vielen anderen Aspekten der Softwareentwicklung ist die Unterstützung verschiedener Systeme mit klaren, einfachen, lose gekoppelten Integrationspunkten die beste Strategie (z. B. die Verwendung einer Web-API zum Abrufen aggregierter Daten in einem Format, das über einen langen Zeitraum konsistent bleiben kann). ).
Die Prinzipien miteinander verbinden
Die in diesem Kapitel besprochenen Prinzipien können zu einer Überwachungs- und Alarmierungsphilosophie kombiniert werden, die von Google SRE-Teams unterstützt und befolgt wird. Die Einhaltung dieser Überwachungsphilosophie ist wünschenswert, ein guter Ausgangspunkt für die Erstellung oder Überarbeitung Ihrer Alarmierungsmethodik und kann Ihnen dabei helfen, die richtigen Fragen an Ihre Betriebsfunktion zu stellen, unabhängig von der Größe Ihrer Organisation oder der Komplexität des Dienstes oder Systems.
Wenn Sie Überwachungs- und Warnregeln erstellen, können Sie durch das Stellen der folgenden Fragen Fehlalarme und unnötige Warnmeldungen vermeiden:
- Erkennt diese Regel einen ansonsten nicht erkennbaren Zustand des Systems, der dringend ist, zum Handeln aufruft und sich unweigerlich auf den Benutzer auswirkt?
- Kann ich diese Warnung ignorieren, obwohl ich weiß, dass sie harmlos ist? Wann und warum kann ich diese Warnung ignorieren und wie kann ich dieses Szenario vermeiden?
- Bedeutet diese Warnung, dass Benutzer negativ betroffen sind? Gibt es Situationen, in denen Benutzer nicht negativ beeinflusst werden, beispielsweise durch Verkehrsfilterung oder bei der Verwendung von Testsystemen, für die Warnungen gefiltert werden sollten?
- Kann ich als Reaktion auf diese Warnung Maßnahmen ergreifen? Sind diese Maßnahmen dringend oder können sie bis zum Morgen warten? Kann eine Aktion sicher automatisiert werden? Wird diese Maßnahme eine langfristige Lösung oder eine kurzfristige Problemumgehung sein?
- Einige Leute erhalten mehrere Benachrichtigungen zu diesem Problem. Gibt es also eine Möglichkeit, die Anzahl der Benachrichtigungen zu reduzieren?
Diese Fragen spiegeln die grundlegende Philosophie von Warnungen und Warnsystemen wider:
- Bei jedem Alarm muss ich sofort reagieren. Ich kann mehrmals am Tag dringend reagieren, bevor ich müde werde.
- Jede Warnung muss relevant sein.
- Jede Reaktion auf eine Warnung muss menschliches Eingreifen erfordern. Wenn die Benachrichtigung automatisch verarbeitet werden kann, sollte sie nicht eintreffen.
- Warnungen sollten sich auf ein neues Problem oder Ereignis beziehen, das vorher nicht existierte.
Dieser Ansatz verwischt bestimmte Unterscheidungen: Wenn die Warnung die vorherigen vier Bedingungen erfüllt, spielt es keine Rolle, ob die Warnung von einem White-Box- oder Black-Box-Überwachungssystem gesendet wird. Dieser Ansatz verstärkt auch bestimmte Unterschiede: Es ist besser, viel mehr Aufwand in die Identifizierung von Symptomen als in die Ursachen zu stecken; Wenn es um Ursachen geht, müssen Sie sich nur um die unvermeidlichen Ursachen kümmern.
Langzeitüberwachung
In heutigen Produktivitätsumgebungen überwachen Überwachungssysteme ein sich ständig weiterentwickelndes Produktionssystem mit sich ändernden Softwarearchitekturen, Arbeitslastmerkmalen und Leistungszielen. Warnungen, die derzeit nur schwer zu automatisieren sind, könnten alltäglich werden und es lohnt sich vielleicht sogar, sie anzugehen. An diesem Punkt muss jemand die Grundursachen des Problems finden und beseitigen; Wenn eine solche Lösung nicht möglich ist, muss die Reaktion auf die Warnung vollständig automatisiert werden.
Es ist wichtig, dass Überwachungsentscheidungen mit Blick auf langfristige Ziele getroffen werden. Jede Warnung, die heute ausgeführt wird, lenkt eine Person davon ab, das System morgen zu verbessern. Daher kommt es häufig zu einer Verringerung der Verfügbarkeit oder Leistung eines produktiven Systems für die Zeit, die zur langfristigen Verbesserung des Überwachungssystems erforderlich ist. Schauen wir uns zwei Beispiele an, um dieses Phänomen zu veranschaulichen.
Bigtable SRE: Eine Geschichte über Alarmbereitschaft
Die interne Infrastruktur von Google wird in der Regel anhand eines Service Levels (SLO) bereitgestellt und gemessen. Vor vielen Jahren basierte das Service-SLO von Bigtable auf der durchschnittlichen Leistung einer synthetischen Transaktion, die einen Live-Client simulierte. Aufgrund von Problemen in Bigtable und niedrigeren Ebenen des Speicherstapels wurde die durchschnittliche Leistung durch einen „großen“ Nachteil bestimmt: Die schlechtesten 5 % der Abfragen waren oft deutlich langsamer als der Rest.
E-Mail-Benachrichtigungen wurden gesendet, wenn der SLO-Schwellenwert erreicht wurde, und Messenger-Benachrichtigungen wurden gesendet, wenn der SLO-Schwellenwert überschritten wurde. Beide Arten von Warnungen wurden recht häufig gesendet, was unzumutbar viel Zeit für die Entwicklung in Anspruch nahm: Das Team verbrachte viel Zeit damit, die Warnungen zu sortieren, um die wenigen tatsächlich relevanten zu finden. Wir haben oft ein Problem übersehen, das tatsächlich Benutzer betraf, weil sich nur einige der Warnungen auf dieses spezifische Problem bezogen. Viele der Warnungen waren aufgrund verständlicher Probleme in der Infrastruktur nicht dringend und wurden standardmäßig oder gar nicht bearbeitet.
Um Abhilfe zu schaffen, verfolgte das Team einen dreigleisigen Ansatz: Während wir hart daran arbeiteten, die Leistung von Bigtable zu verbessern, setzten wir unser SLO-Ziel vorübergehend auf das 75. Perzentil für die Latenz der Abfrageantwort. Wir haben auch E-Mail-Benachrichtigungen deaktiviert, da es so viele davon gab, dass es unmöglich war, Zeit für die Diagnose aufzuwenden.
Diese Strategie gab uns den Spielraum, mit der Behebung langfristiger Probleme in Bigtable und den unteren Ebenen des Speicherstapels zu beginnen, anstatt ständig taktische Probleme zu beheben. Ingenieure könnten tatsächlich ihre Arbeit erledigen, ohne ständig mit Warnungen bombardiert zu werden. Letztendlich konnten wir durch die vorübergehende Verschiebung der Alarmbearbeitung die Qualität unseres Service verbessern.
Gmail: Vorhersehbare, algorithmische menschliche Reaktionen
Zu Beginn basierte Gmail auf einem modifizierten Workqueue-Prozessverwaltungssystem, das für die Stapelverarbeitung von Teilen eines Suchindex konzipiert war. Workqueue wurde an langlebige Prozesse angepasst und anschließend auf Gmail angewendet, einige Fehler im undurchsichtigen Scheduler-Code erwiesen sich jedoch als sehr schwer zu beheben.
Damals war die Gmail-Überwachung so strukturiert, dass Benachrichtigungen ausgelöst wurden, wenn einzelne Aufgaben mithilfe von Workqueue abgebrochen wurden. Dieser Ansatz war nicht ideal, da Gmail schon damals viele tausend Aufgaben ausführte, von denen jede nur einem Bruchteil eines Prozents unserer Nutzer zur Verfügung gestellt wurde. Wir waren sehr darum bemüht, Gmail-Benutzern eine gute Benutzererfahrung zu bieten, aber die Bearbeitung so vieler Benachrichtigungen war für uns unerreichbar.
Um dieses Problem zu beheben, hat Gmail SRE ein Tool entwickelt, das dabei hilft, den Planer so gut wie möglich zu debuggen, um die Auswirkungen auf Benutzer zu minimieren. Das Team diskutierte darüber, ob der gesamte Zyklus von der Problemerkennung über die Behebung bis zur Suche nach einer langfristigen Lösung einfach automatisiert werden sollte. Einige befürchteten jedoch, dass eine solche Lösung die tatsächliche Behebung des Problems verzögern würde.
Diese Spannung war im Team weit verbreitet und spiegelte häufig einen Mangel an Vertrauen in die Selbstdisziplin wider: Während einige Teammitglieder Zeit für die richtige Lösung einplanen möchten, befürchten andere, dass die endgültige Lösung vergessen wird und die vorübergehende Lösung ewig dauern wird. Dieses Problem verdient Aufmerksamkeit, da es zu einfach ist, Probleme vorübergehend zu beheben, anstatt die Situation dauerhaft zu machen. Manager und technisches Personal spielen eine Schlüsselrolle bei der Implementierung langfristiger Lösungen und unterstützen und priorisieren potenziell langfristige Lösungen, selbst nachdem die anfänglichen „Schmerzen“ nachgelassen haben.
Regelmäßige, sich wiederholende Warnungen und algorithmische Reaktionen sollten ein Warnsignal sein. Die Zurückhaltung Ihres Teams, diese Warnungen zu automatisieren, bedeutet, dass es dem Team an Vertrauen mangelt, den Algorithmen vertrauen zu können. Dies ist ein ernstes Problem, das angegangen werden muss.
Langfristig
Ein gemeinsames Thema verbindet die Beispiele von Bigtable und Gmail: der Wettbewerb zwischen kurzfristiger und langfristiger Verfügbarkeit. Oftmals kann ein starker Einsatz dazu beitragen, dass ein fragiles System eine hohe Verfügbarkeit erreicht. Dieser Weg ist jedoch in der Regel nur von kurzer Dauer und mit einem Team-Burnout und der Abhängigkeit von einer kleinen Anzahl von Mitgliedern desselben heldenhaften Teams behaftet.
Eine kontrollierte, kurzfristige Reduzierung der Verfügbarkeit ist oft schmerzhaft, aber für die langfristige Stabilität des Systems strategisch wichtig. Es ist wichtig, nicht jede Warnung isoliert zu betrachten, sondern zu überlegen, ob das Gesamtniveau der Warnungsmenge zu einem gesunden, gut zugänglichen System mit einem funktionsfähigen Team und einer günstigen Prognose führt. Wir analysieren Statistiken zur Alarmhäufigkeit (normalerweise ausgedrückt als Vorfälle pro Schicht, wobei ein Vorfall aus mehreren zusammenhängenden Vorfällen bestehen kann) in vierteljährlichen Berichten an das Management, sodass Entscheidungsträger einen kontinuierlichen Überblick über die Auslastung des Alarmsystems und den allgemeinen Zustand des Teams haben.
Abschluss
Der Weg zu einer gesunden Überwachung und Alarmierung ist einfach und klar. Es konzentriert sich auf die Symptome des Problems, die Warnungen auslösen, und die Überwachung der Ursache dient als Hilfe bei der Fehlerbehebung. Die Überwachung von Symptomen ist umso einfacher, je höher Sie sich im von Ihnen kontrollierten Stapel befinden. Die Überwachung von Auslastung und Leistung der Datenbank sollte jedoch direkt in der Datenbank selbst erfolgen. E-Mail-Benachrichtigungen haben nur einen sehr begrenzten Nutzen und neigen dazu, schnell zu Lärm zu werden. Stattdessen sollten Sie ein Dashboard verwenden, das alle aktuellen Probleme überwacht, die E-Mail-Benachrichtigungen auslösen. Das Dashboard kann auch mit einem Ereignisprotokoll gekoppelt werden, um historische Zusammenhänge zu analysieren.
Langfristig ist es notwendig, eine erfolgreiche Rotation der Warnungen zu Symptomen und drohenden realen Problemen zu erreichen und die Ziele anzupassen, um sicherzustellen, dass die Überwachung eine schnelle Diagnose unterstützt.
Vielen Dank, dass Sie die Übersetzung bis zum Ende gelesen haben. Abonnieren Sie meinen Telegram-Kanal zum Thema Überwachung и .
Source: habr.com