SRE (Site Reliability Engineering) ass eng Approche fir d'Accessibilitéit vu Webprojeten ze garantéieren. Et gëtt als e Kader fir DevOps ugesinn a schwätzt iwwer wéi een Erfolleg bei der Uwendung vun DevOps Praktiken erreecht. Iwwersetzung an dësem Artikel Bicher vu Google. Ech hunn dës Iwwersetzung selwer virbereet an hunn op meng eegen Erfahrung vertraut fir Iwwerwaachungsprozesser ze verstoen. Am Telegram Kanal и Ech hunn och e Link op d'Iwwersetzung vum Kapitel 4 vum selwechte Buch iwwer Serviceniveauziler publizéiert.
Iwwersetzung vun Kaz. Genéisst d'Liesen!
D'SRE Teams vu Google hunn Basisprinzipien a bescht Praktiken fir erfollegräich Iwwerwaachungs- an Notifikatiounssystemer ze kreéieren. Dëst Kapitel liwwert Orientatioun iwwer wéi eng Probleemer e Websäit Besucher kéint begéinen a wéi ee Probleemer léist déi Websäite schwéier ze weisen.
Definitions
Et gëtt keen eenzege Vokabulär benotzt fir Themen am Zesummenhang mat der Iwwerwaachung ze diskutéieren. Och op Google sinn d'Begrëffer hei drënner net allgemeng benotzt, awer mir wäerten déi heefegst Interpretatiounen oplëschten.
Iwwerwaachung
Sammlung, Veraarbechtung, Aggregatioun an Affichage vu quantitativen Donnéeën an Echtzäit iwwer de System: Zuel vun Ufroen an Aarte vun Ufroen, Zuel vu Feeler an Aarte vu Feeler, Ufro Veraarbechtungszäit a Server Uptime.
Wäiss Këscht Iwwerwaachung
Iwwerwachung baséiert op Metriken, déi vun interne Systemkomponenten ugewise ginn, dorënner Logbicher, Java Virtual Machine Profiler Metriken, oder HTTP Handler Metriken déi intern Statistike generéieren.
Black-Box Iwwerwaachung
Testen d'Applikatiounsverhalen aus der Siicht vum Benotzer.
Dashboard
Eng Interface (normalerweis Web) déi en Iwwerbléck iwwer Schlëssel Gesondheetsindikatore vu Servicer ubitt. D'Dashboard kann Filteren hunn, d'Fähigkeit fir d'Indicateuren ze wielen, asw. D'Dashboard kann och Informatioun fir technesch Ënnerstëtzungspersonal weisen: eng Schlaang vun Ufroen, eng Lëscht vu prioritäre Feeler an en zougewisenen Ingenieur fir e bestëmmte Beräich vun der Verantwortung.
Alarm (Notifikatioun)
Notifikatioune geduecht fir vun enger Persoun per E-Mail oder op aner Mëttelen ze kréien, déi duerch Feeler oder eng Erhéijung vun der Ufroschlaang ausgeléist kënne ginn. Notifikatioune ginn klasséiert wéi: Ticketen, E-Mail Alarmer an Instant Messenger Messagen.
Root Ursaach
E Softwaredefekt oder mënschleche Feeler deen, wann se korrigéiert ass, net méi sollt optrieden. De Problem kann e puer Haaptursaachen hunn: net genuch Prozessautomatiséierung, Softwaredefekt, net genuch Ausbau vun der Applikatiounslogik. Jiddereng vun dëse Faktoren kann d'Wurzelursaach sinn, a jidderee vun hinnen muss eliminéiert ginn.
Node a Maschinn (Node an Maschinn)
Austauschbar Begrëffer fir op eng eenzeg Instanz vun enger lafender Applikatioun op engem kierperleche Server, virtueller Maschinn oder Container ze referenzéieren. Eng Maschinn kann verschidde Servicer hosten. Servicer kënne sinn:
- matenee verbonnen: zum Beispill e Caching-Server an e Webserver;
- onrelatéierte Servicer op engem eenzege Stéck Hardware: zum Beispill e Code Repository an e Wizard fir e Konfiguratiounssystem, wéi z. oder .
Push
All Ännerung vun Software Configuratioun.
Firwat ass Iwwerwaachung néideg?
Et gi verschidde Grënn firwat Uwendungen iwwerwaacht musse ginn:
Analyse vu laangfristeg Trends
Wéi grouss ass d'Datebank a wéi séier wiisst se? Wéi ännert sech déi deeglech Zuel vun de Benotzer?
Leeschtung Verglach
Sinn Ufroe méi séier op Acme Bucket of Bytes 2.72 am Verglach zum Ajax DB 3.14? Wéi vill besser sinn Ufroen no der Erscheinung vun engem zousätzleche Node cache? Laaft de Site méi lues am Verglach mat der leschter Woch?
Alarm (Notifikatiounen)
Eppes ass gebrach an een muss et fixéieren. Oder eppes brécht geschwënn an een muss et geschwënn iwwerpréiwen.
Schafen Dashboards
Dashboards solle grondleeënd Froen beäntweren an eppes aus enthalen - Verspéidungen (Latency), Traffic (Traffic), Feeler (Feeler) a Lastgréisst (Sättigung).
Retrospektiv Analyse maachen (Debugging)
D'Verzögerung vun der Ufroveraarbechtung ass eropgaang, awer wat ass soss ëm déiselwecht Zäit geschitt?
Iwwerwaachungssystemer sinn nëtzlech als Quell vun Daten fir Geschäftsintelligenzsystemer a fir d'Analyse vu Sécherheetsinfällen ze erliichteren. Well dëst Buch fokusséiert op Ingenieursberäicher an deenen SREs Expertise hunn, wäerte mir iwwer Iwwerwaachungstechniken hei net diskutéieren.
Iwwerwaachung an Alarmer erlaaben de System Iech ze soen wann et gebrach ass oder amgaang ass ze briechen. Wann e System sech selwer net automatesch reparéiere kann, wëlle mir datt e Mënsch d'Alarm analyséiert, feststellt ob de Problem nach ëmmer aktiv ass, léisen an d'Wurzelursaach bestëmmen. Wann Dir Systemkomponenten net auditéiert, kritt Dir ni eng Alarm einfach well "eppes e bësse komesch schéngt."
Eng Persoun mat Notifikatiounen ze belaaschten ass eng zimlech deier Notzung vun der Zäit vun engem Employé. Wann den Employé schafft, ënnerbrach d'Alarm den Aarbechtsprozess. Wann den Employé doheem ass, ënnerbrach d'Alarm perséinlech Zäit a schlofen eventuell. Wann Alarmer ze dacks optrieden, schimmen d'Mataarbechter se duerch, setzen se of oder ignoréieren erakommen Alarmer. Vun Zäit zu Zäit ignoréiere se déi richteg Alarm, déi duerch Kaméidi Eventer maskéiert ass. Service Ënnerbriechungen kënne laang Zäit daueren well Kaméidi Eventer verhënneren datt de Problem séier diagnostizéiert a korrigéiert gëtt. Effektiv Warnungssystemer hunn e gudde Signal-to-Geräusch Verhältnis.
Astellen raisonnabel Erwaardungen fir d'Iwwerwaachung System
Iwwerwaachung fir eng komplex Applikatioun opzestellen ass eng komplex Ingenieursaufgab u sech. Och mat enger bedeitender Infrastruktur vu Sammel-, Affichage- an Alarm-Tools, enthält e Google SRE Team vun 10-12 Memberen typesch een oder zwee Leit deenen hir primär Zweck ass d'Iwwerwaachungssystemer ze bauen an z'erhalen. Dës Zuel ass mat der Zäit erofgaang wéi mir d'Iwwerwaachungsinfrastruktur konsolidéieren an zentraliséieren, awer all SRE Team huet typesch op d'mannst eng Persoun déi eleng fir d'Iwwerwaachung gewidmet ass. Mir musse soen datt wärend d'Iwwerwaachungssystem Dashboards zimlech interessant sinn ze kucken, SRE Teams vermeide virsiichteg Situatiounen déi iergendeen erfuerderen op en Ecran ze kucken fir Probleemer ze iwwerwaachen.
Insgesamt ass Google op einfach a séier Iwwerwaachungssystemer mat optimalen After-The-Fact Analyse Tools geplënnert. Mir vermeiden "Magie" Systemer déi probéieren d'Schwellen virauszesoen oder d'Ursaach automatesch z'entdecken. Sensoren déi ongewollten Inhalt an Endverbraucherfuerderunge erkennen sinn dat eenzegt Géigebeispill; Soulaang dës Sensoren einfach bleiwen, kënne se séier d'Ursaache vu schlëmmen Anomalien entdecken. Aner Formater fir d'Benotzung vun Iwwerwaachungsdaten, wéi Kapazitéitsplanung oder Verkéiersprognose, si méi komplex. Observatioun iwwer eng ganz laang Zäit (Méint oder Joer) bei engem nidderegen Samplingquote (Stonnen oder Deeg) wäert e laangfristeg Trend opdecken.
D'Google SRE Team huet gemëschte Succès mat komplexe Ofhängegkeetshierarchien. Mir benotze selten Regele wéi "wann ech erausfannen datt d'Datebank lues ass, kréien ech eng Alarm datt d'Datebank lues ass, soss kréien ech eng Alarm datt de Site lues ass." Ofhängegkeet-baséiert Reegelen bezéien normalerweis op onverännerbar Deeler vun eisem System, sou wéi de System fir de Benotzerverkéier an den Rechenzentrum ze filteren. Zum Beispill, "wann de Verkéiersfilter an den Datenzenter konfiguréiert ass, alarméiert mech net iwwer Verzögerungen bei der Veraarbechtung vun de Benotzerufroen" ass eng allgemeng Regel fir Alarmer vum Rechenzentrum. Puer Teams bei Google ënnerstëtzen komplex Ofhängegkeetshierarchien well eis Infrastruktur e konstante Taux vu kontinuéierlecher Refactoring huet.
E puer vun den Iddien, déi an dësem Kapitel beschriwwe ginn, sinn nach ëmmer relevant: et gëtt ëmmer eng Geleeënheet fir méi séier vu Symptom op d'Wurzelursaach ze bewegen, besonnesch a stänneg verännerend Systemer. Dofir, wärend dëst Kapitel e puer Ziler fir Iwwerwaachungssystemer skizzéiert a wéi dës Ziler z'erreechen, ass et wichteg datt d'Iwwerwaachungssystemer einfach a verständlech fir jiddereen am Team sinn.
Och fir de Geräischer niddereg an d'Signalniveauen héich ze halen, mussen d'Approche fir d'Iwwerwaachung vun alarméierten Verméigen ganz einfach an zouverlässeg sinn. Regelen déi Warnunge fir d'Leit generéieren sollen einfach ze verstoen sinn an e klore Problem presentéieren.
Symptomer versus Ursaachen
Ären Iwwerwaachungssystem sollt zwou Froen beäntweren: "wat ass gebrach" a "firwat et gebrach ass."
"Wat gebrach" schwätzt iwwer de Symptom, a "firwat et gebrach ass" schwätzt iwwer d'Ursaach. D'Tabell hei ënnen weist Beispiller vu sou Verbindungen.
Symptom
Reason
Gitt HTTP Feeler 500 oder 404
Datebankserver refuséieren Verbindungen
Lues Server Äntwerten
Héich CPU Notzung oder beschiedegt Ethernet Kabel
D'Benotzer an der Antarktis kréien keng Kaz GIFs
Ären CDN haasst Wëssenschaftler a Kazen, sou datt e puer IP Adressen op d'Schwaarzlëscht sinn
Privaten Inhalt ass vun iwwerall verfügbar ginn
D'Rollout vun enger neier Software Verëffentlechung huet d'Firewall all ACLs vergiess a jidderee gelooss
"Wat" a "firwat" sinn e puer vun de wichtegste Bausteng fir e gudden Iwwerwaachungssystem mat maximalem Signal a minimale Kaméidi ze kreéieren.
Black-Box vs White-Box
Mir kombinéieren extensiv White-Box Iwwerwaachung mat bescheidener Black-Box Iwwerwaachung fir kritesch Metriken. Deen einfachste Wee fir Black-Box mat White-Box ze vergläichen ass datt Black-Box symptomfokuséiert ass an reaktiv ass anstatt proaktiv Iwwerwaachung: "de System funktionnéiert elo net richteg." White-Box hänkt vun den internen Verifizéierungsfäegkeete vu Systemer of: Eventprotokoller oder Webserver. Also, White-Box erlaabt Iech impending Problemer z'entdecken, Feeler déi schéngen eng Retransmission vun enger Ufro ze sinn, etc.
Notéiert datt an engem Multi-Layer System, e Symptom am Verantwortungsberäich vun engem Ingenieur e Symptom an engem Verantwortungsberäich vun engem aneren Ingenieur ass. Zum Beispill ass d'Datebankleistung erofgaang. Luesen Datebank liest sinn e Symptom vun der Datebank SRE déi se erkennt. Wéi och ëmmer, fir e Front-End SRE, deen eng lues Websäit beobachtet, ass d'Ursaach vun der selwechter luesen Datebank liesen eng lues Datebank. Dofir ass d'White-Box-Iwwerwaachung heiansdo Symptom-fokusséiert an heiansdo Ursaach-fokusséiert, jee wéi extensiv et ass.
Wann Dir Telemetrie fir Debugging sammelt, ass White-Box Iwwerwaachung erfuerderlech. Wann Webserver lues sinn op Datebank Ufroen z'äntwerten, musst Dir wëssen wéi séier de Webserver mat der Datebank kommunizéiert a wéi séier se reagéiert. Soss kënnt Dir net tëscht engem luesen Datebankserver an engem Netzwierkproblem tëscht dem Webserver an der Datebank z'ënnerscheeden.
Black-Box-Iwwerwaachung huet e Schlësselvirdeel beim Schécken vun Alarmer: Dir léist d'Notifikatioun un den Empfänger aus, wann de Problem schonn zu echte Symptomer gefouert huet. Op der anerer Säit ass d'Iwwerwaachung nëtzlos fir e Black-Box Problem deen nach net entstanen ass awer bevirsteet.
Véier gëllen Signaler
Déi véier gëllen Iwwerwaachungssignaler sinn Latenz, Traffic, Feeler a Sättigung. Wann Dir nëmme véier Benotzersystem Metriken moosse kënnt, fokusséiert op déi véier.
Verzögerung
D'Zäit déi néideg ass fir d'Demande ze behandelen. Et ass wichteg tëscht der Latenz vun erfollegräichen an net erfollegräichen Ufroen z'ënnerscheeden. Zum Beispill, en HTTP 500 Feeler verursaacht duerch e Verloscht vun der Verbindung mat enger Datebank oder engem anere Backend ka ganz séier diagnostizéiert ginn, awer en HTTP 500 Feeler kann eng gescheitert Ufro uginn. D'Bestëmmung vum Impakt vun engem 500 Feeler op d'Gesamtlatenz kann zu falsche Conclusiounen féieren. Op der anerer Säit ass e luesen Feeler souguer e séiere Feeler! Dofir ass et wichteg d'Fehlerlatenz ze iwwerwaachen anstatt einfach Feeler ze filteren.
Verkéier
D'Zuel vun den Ufroen un Äre System gëtt an héije System Metriken gemooss. Fir e Webservice representéiert dës Miessung typesch d'Zuel vun HTTP-Ufroen pro Sekonn, gedeelt duerch d'Natur vun den Ufroen (zum Beispill statesch oder dynameschen Inhalt). Fir en Audio Streaming System kann dës Messung sech op d'Netz I/O Geschwindegkeet oder d'Zuel vu simultane Sessiounen konzentréieren. Fir e Schlësselwäert-Späichersystem kann dës Messung Transaktiounen oder Sichresultater pro Sekonn sinn.
Feeler
Dëst ass den Taux vun gescheitert Ufroen déi explizit sinn (zB HTTP 500), implizit (zB HTTP 200 awer kombinéiert mat ongülteg Inhalter) oder Politik (zB "Wann Dir eng Äntwert an enger Sekonn ageholl hutt, ass eng Sekonn e Feeler"). Wann HTTP Äntwert Coden net genuch sinn fir all Feelerbedéngungen auszedrécken, kënnen sekundär (intern) Protokoller erfuerderlech sinn fir deelweis Feeler z'entdecken. D'Iwwerwaachung vun all sou falschen Ufroe kann net informativ sinn, wärend end-to-end Systemtester hëllefen z'entdecken datt Dir falschen Inhalt veraarbecht.
Sättigung
D'Metrik weist wéi intensiv Äre Service benotzt gëtt. Dëst ass e System Iwwerwachung Moossnam datt d'Ressourcen identifizéiert déi am meeschte limitéiert sinn (zum Beispill, op engem Erënnerung-begrenzte System, weist Erënnerung, op engem I / O-beschränkt System, weist d'Zuel vun I / Os). Notéiert datt vill Systemer d'Performance degradéieren ier se 100% Notzung erreechen, sou datt e Notzungsziel wichteg ass.
A komplexe Systemer kann d'Sättigung ergänzt ginn duerch Belaaschtungsmiessungen op méi héije Niveauen: kann Äre Service den duebelen Traffic richteg handhaben, nëmmen 10% méi Traffic handhaben oder nach manner Traffic behandelen wéi de Moment? Fir einfach Servicer, déi keng Parameteren hunn, datt d'Komplexitéit vun der Demande änneren (zum Beispill, "Gëff mir näischt" oder "Ech brauch eng eenzegaarteg eenzeg monoton ganzt Zuel"), datt selten änneren Configuratioun, kann eng statesch Laascht Test Wäert adäquate ginn. Wéi och ëmmer, wéi am virege Paragraph diskutéiert, mussen déi meescht Servicer indirekt Signaler benotzen wéi d'CPU-Notzung oder d'Netzbandbreedung, déi eng bekannt iewescht Grenz hunn. D'Erhéijung vun der latency ass dacks e féierende Indikator fir Sättigung. D'Messung vun der 99th percentile Äntwertzäit an enger klenger Fënster (z.B. eng Minutt) kann e ganz fréie Signal vu Sättigung ubidden.
Schlussendlech ass Sättigung och mat Prognosen iwwer impending Sättigung assoziéiert, zum Beispill: "Et gesäit aus wéi wann Är Datebank Är Festplack a 4 Stonnen ausfëllt."
Wann Dir all véier gëllene Signaler moosst a wann et e Problem mat enger vun de Metriken ass (oder, am Fall vun der Sättigung, e bal Problem), alarméiert Dir eng Persoun, Äre Service gëtt méi oder manner duerch Iwwerwaachung ofgedeckt.
Suergen iwwer de "Schwanz" (oder Instrumentatioun an Leeschtung)
Wann Dir en Iwwerwaachungssystem vun Null erstellt, gëtt et eng Versuchung fir e System ze entwéckelen baséiert op duerchschnëttleche Wäerter: Duerchschnëttslatenz, duerchschnëttlech CPU Notzung vun Noden oder duerchschnëttlech Datebankvollheet. D'Gefor vun de leschten zwee Beispiller ass evident: Prozessoren an Datenbanken ginn op eng ganz onberechenbar Manéier entsuergt. Dat selwecht gëllt fir Verspéidung. Wann Dir e Webservice mat enger duerchschnëttlecher Latenz vun 100ms mat 1000 Ufroe pro Sekonn leeft, kann 1% vun den Ufroen 5 Sekonnen daueren. Wann d'Benotzer op verschidde sou Webservicer ofhängeg sinn, kann den 99. Prozentsaz vun engem Backend einfach d'mediane Äntwertzäit vum Frontend ginn.
Deen einfachste Wee fir tëscht dem luesen Duerchschnëtt an dem ganz luesen Schwanz vun Ufroen ze differenzéieren ass Miessunge vun Ufroen ze sammelen, déi a Statistiken ausgedréckt sinn (e gutt Tool fir ze weisen ass Histogramme) anstatt tatsächlech latencies: wéi vill Ufroen de Service servéiert huet deen tëscht 0 ms gedauert huet an 10 ms, tëscht 10 ms an 30 ms, tëscht 30 ms an 100 ms, tëscht 100 ms an 300 ms, etc.. D'Histogrammgrenze ongeféier exponentiell auszebauen (duerch en ongeféiere Faktor vun 3) ass dacks en einfache Wee fir d'Verdeelung ze visualiséieren vun Demanden.
Wielt de passenden Detailniveau fir Miessunge
Verschidden Elementer vum System mussen op verschidden Detailniveauen gemooss ginn. Zum Beispill:
- Iwwerwaachung vun der CPU Notzung iwwer eng Zäit wäert keng laangfristeg Spikes weisen, déi zu héije Latenzë féieren.
- Op der anerer Säit, fir e Webservice, deen net méi wéi 9 Stonnen Ausdauer pro Joer zielt (99,9% alljährlechen Uptime), fir eng HTTP 200 Äntwert méi wéi eemol oder zweemol pro Minutt ze kontrolléieren ass méiglecherweis onnéideg dacks.
- Och d'Festplackplaz fir 99,9% Disponibilitéit méi wéi eemol all 1-2 Minutten ze kontrolléieren ass wahrscheinlech net néideg.
Passt op wéi Dir d'Granularitéit vun Äre Miessunge strukturéiert. CPU-Laascht eemol pro Sekonn sammelen kann interessant Donnéeën ubidden, awer sou heefeg Miessunge kënne ganz deier sinn fir ze sammelen, ze späicheren an ze analyséieren. Wann Äert Iwwerwaachungsziel héich Granularitéit erfuerdert an net héich Reaktiounsfäegkeet erfuerdert, kënnt Dir dës Käschten reduzéieren andeems Dir Metrikensammlung um Server opstellt an dann en externe System opstellt fir dës Metriken ze sammelen an ze aggregéieren. Kéins du:
- Mooss CPU Last all Sekonn.
- Den Detail op 5% reduzéieren.
- Aggregat Metriken all Minutt.
Dës Strategie erlaabt Iech Daten mat enger héijer Granularitéit ze sammelen ouni eng héich Analyse a Späicheroverhead ze maachen.
Sou einfach wéi méiglech, awer net méi einfach
D'Iwwerlagerung vu verschiddenen Ufuerderungen openeen kann zu engem ganz komplexe Iwwerwaachungssystem resultéieren. Zum Beispill, Äre System kann déi folgend komplizéiert Elementer hunn:
- Alarmer no verschiddenen Schwellen fir Ufro Veraarbechtung latency, a verschiddene percentiles, fir all Zorte vu verschiddenen Indicateuren.
- Zousätzlech Code schreiwen fir méiglech Ursaachen z'entdecken an z'identifizéieren.
- Erstellt verwandte Dashboards fir all méiglech Ursaache vu Probleemer.
D'Quell vu potenziellen Komplikatiounen sinn ni ophalen. Wéi all Software Systemer kann d'Iwwerwaachung sou komplex ginn datt et fragil a schwéier ze änneren an z'erhalen gëtt.
Dofir designt Ären Iwwerwaachungssystem fir et sou vill wéi méiglech ze vereinfachen. Wann Dir wielt wat fir ze verfolgen, behalen déi folgend am Kapp:
- D'Regele, déi meeschtens richteg Tëschefäll opfänken, solle sou einfach, prévisibel an zouverlässeg wéi méiglech sinn.
- Konfiguratioun fir Datesammlung, Aggregatioun an Alarm déi selten ausgefouert gëtt (zum Beispill manner wéi Véierel fir e puer SRE Teams) soll geläscht ginn.
- Metriken déi gesammelt ginn, awer net an engem Virschau-Dashboard gewise ginn oder vun enger Alarm benotzt ginn, si Kandidate fir ze läschen.
Bei Google, Basis Metriken Sammlung an Aggregatioun, kombinéiert mat Alarmer an Dashboards, funktionnéieren gutt als e relativ Stand-alone System (Google Iwwerwachungssystem ass tatsächlech a verschidde Subsystemer opgedeelt, awer d'Leit sinn normalerweis all Aspekter vun dësen Ënnersystemer bewosst). Et kann verlockend sinn d'Iwwerwaachung mat aneren Techniken ze kombinéieren fir komplex Systemer z'ënnersichen: detailléiert Systemprofiléierung, Prozessdebugging, Tracking Detailer iwwer Ausnahmen oder Feeler, Laaschtestung, Log Sammlung an Analyse, oder Trafficinspektioun. Wärend déi meescht vun dëse Saachen Gemeinsamkeeten mat Basis Iwwerwaachung hunn, vermëschen se ze vill Resultater an e komplexen a fragile System erstellen. Wéi mat villen aneren Aspekter vun der Softwareentwécklung ass d'Ënnerstëtzung vu verschiddene Systemer mat kloeren, einfachen, locker gekoppelten Integratiounspunkten déi bescht Strategie (zum Beispill d'Benotzung vun enger Web API fir aggregéiert Daten an engem Format ze recuperéieren dat iwwer eng laang Zäit konsequent bleift ).
D'Prinzipien zesummen ze verbannen
D'Prinzipien, déi an dësem Kapitel diskutéiert ginn, kënnen an eng Iwwerwaachungs- an Alarmphilosophie kombinéiert ginn, déi vu Google SRE Teams ënnerstëtzt a gefollegt gëtt. Dës Iwwerwaachungsphilosophie ze halen ass wënschenswäert, ass e gudde Startpunkt fir Är Alarmmethodologie ze kreéieren oder ze iwwerschaffen, a kann Iech hëllefen déi richteg Froen vun Ärer Operatiounsfunktioun ze stellen, onofhängeg vun der Gréisst vun Ärer Organisatioun oder der Komplexitéit vum Service oder System.
Wann Dir Iwwerwaachungs- an Alarmregelen erstellt, kënnt Dir déi folgend Froen stellen Iech hëllefen, falsch Positiven an onnéideg Alarmer ze vermeiden:
- Entdeckt dës Regel en soss ondetektéierbaren Zoustand vum System deen dréngend ass, rifft op Handlung, an zwangsleefeg de Benotzer beaflosst?
- Kann ech dës Warnung ignoréieren wëssend datt et benign ass? Wéini a firwat kann ech dës Warnung ignoréieren a wéi kann ech dëst Szenario vermeiden?
- Heescht dës Alarm datt d'Benotzer negativ beaflosst ginn? Ginn et Situatiounen wou d'Benotzer net negativ beaflosst sinn, sou wéi duerch Trafficfilterung oder wann Dir Testsystemer benotzt fir déi Alarme gefiltert ginn?
- Kann ech als Äntwert op dës Alarm handelen? Sinn dës Moossnamen dréngend oder kënne se bis de Moien waarden? Kann eng Aktioun sécher automatiséiert ginn? Wäert dës Aktioun eng laangfristeg Léisung oder eng kuerzfristeg Léisung sinn?
- E puer Leit kréien verschidde Alarmer fir dëst Thema, also gëtt et e Wee fir d'Zuel vun den Alarmer ze reduzéieren?
Dës Froen reflektéieren déi fundamental Philosophie iwwer Alarm- a Warnsystemer:
- All Kéier wann eng Alarm erakënnt, muss ech direkt reagéieren. Ech kann e puer Mol am Dag dréngend reagéieren ier ech midd ginn.
- All Alarm muss relevant sinn.
- All Äntwert op eng Alarm muss mënschlech Interventioun erfuerderen. Wann d'Notifikatioun automatesch veraarbecht ka ginn, sollt se net kommen.
- Alarmer sollen iwwer en neie Problem oder Event sinn, dee virdru net existéiert huet.
Dës Approche verschwënnt gewëssen Ënnerscheeder: wann d'Alarm déi véier Viraussetzungen entsprécht, ass et egal ob d'Alarm vun enger White-Box oder Black-Box Iwwerwaachungssystem geschéckt gëtt. Dës Approche verstäerkt och verschidden Differenzen: et ass besser vill méi Effort ze verbréngen fir Symptomer z'identifizéieren wéi op Ursaachen; wann et drëms geet, fir Ursaachen, Dir musst just iwwer déi inévitabel Ursaachen Suergen.
Laangfristeg Iwwerwaachung
An haut d'Produktivitéit Ëmfeld, Iwwerwachung Systemer iwwerwaachen engem ëmmer-entwéckele Produktioun System mat änneren Software Architektur, Aarbechtslaascht Charakteristiken, a Leeschtung Ziler. Alarmer déi momentan schwéier ze automatiséieren kënnen allgemeng ginn, vläicht souguer derwäert ze adresséieren. Zu dësem Zäitpunkt muss een d'Wurzelursaachen vum Problem fannen an eliminéieren; wann esou Resolutioun net méiglech ass, erfuerdert d'Äntwert op d'Alarm voll Automatisatioun.
Et ass wichteg datt d'IwwerwaachungsEntscheedunge mat laangfristeg Ziler am Kapp getraff ginn. All Alarm, déi haut leeft, distractéiert eng Persoun fir de System muer ze verbesseren, sou datt et dacks eng Reduktioun vun der Disponibilitéit oder der Leeschtung vun engem produktive System gëtt fir d'Zäit déi néideg ass fir den Iwwerwaachungssystem op laang Siicht ze verbesseren. Loosst eis zwee Beispiller kucken fir dëst Phänomen ze illustréieren.
Bigtable SRE: A Tale of Over-Alert
D'intern Infrastruktur vu Google gëtt typesch virgesinn a gemooss géint e Serviceniveau (SLO). Virun ville Joeren war de Bigtable Service SLO baséiert op der Moyenne Performance vun enger synthetescher Transaktioun, déi e Live Client simuléiert. Wéinst Themen am Bigtable a méi nidderegen Niveauen vum Späicherstack gouf duerchschnëttlech Leeschtung vun engem "grousse" Schwanz gedriwwen: déi schlëmmste 5% vun Ufroen waren dacks wesentlech méi lues wéi de Rescht.
E-Mail Notifikatioune goufe geschéckt wéi d'SLO-Schwell erreecht gouf, a Messenger-Alarme goufen geschéckt wann de SLO iwwerschratt gouf. Béid Aarte vun Alarmer goufen zimmlech dacks geschéckt, verbraucht inakzeptabel Quantitéiten un Ingenieurszäit: d'Team huet eng bedeitend Quantitéit un Zäit verbruecht fir duerch d'Alarmer ze sortéieren fir déi puer ze fannen déi tatsächlech relevant waren. Mir hunn dacks en Thema verpasst dat d'Benotzer tatsächlech beaflosst well nëmmen e puer vun den Alarmer fir dat spezifescht Thema waren. Vill vun den Alerte ware wéinst verständleche Problemer an der Infrastruktur net dréngend a goufen standardiséiert oder guer net veraarbecht.
Fir d'Situatioun ze behiewen, huet d'Team eng dräifach Approche geholl: Wärend schwéier geschafft fir d'Performance vum Bigtable ze verbesseren, hu mir eist SLO Zil temporär gesat fir de 75. Mir hunn och E-Mail Alarmer ausgeschalt well et sou vill vun hinnen waren datt et onméiglech war Zäit ze verbréngen fir se ze diagnostizéieren.
Dës Strategie huet eis den Atmungsraum erlaabt fir laangfristeg Themen am Bigtable an déi ënnescht Schichten vum Stockage Stack ze fixéieren, anstatt stänneg taktesch Themen ze fixéieren. D'Ingenieure konnten tatsächlech d'Aarbecht gemaach kréien ouni déi ganzen Zäit mat Alarmer bombardéiert ze ginn. Schlussendlech, temporär Ausstelle vun Alarmveraarbechtung erlaabt eis d'Qualitéit vun eisem Service ze verbesseren.
Gmail: prévisibel, algorithmesch mënschlech Äntwerten
Bei der Grënnung gouf Gmail op engem modifizéierten Workqueue Prozessmanagement System gebaut deen entwéckelt gouf fir Stécker vun engem Sichindex ze batchéieren. Workqueue gouf fir laanglieweg Prozesser ugepasst an duerno op Gmail applizéiert, awer e puer Bugs am opaken Schedulercode hu sech ganz schwéier ze fixéieren.
Deemools war Gmail Iwwerwachung strukturéiert sou datt Alarmer ausgeléist ginn wann eenzel Aufgaben mat Workqueue annuléiert goufen. Dës Approche war net ideal, well och zu där Zäit huet Gmail vill Dausende vun Aufgaben ausgefouert, déi jidderee fir eng Fraktioun vun engem Prozent vun eise Benotzer geliwwert gouf. Mir ware ganz besuergt iwwer Gmail Benotzer eng gutt Benotzererfarung ze bidden, awer d'Handhabung vu sou vill Alarmer war net erreechbar.
Fir dëst Thema unzegoen, huet Gmail SRE en Tool erstallt fir de Scheduler sou gutt wéi méiglech ze debuggen fir den Impakt op d'Benotzer ze minimiséieren. D'Team hat e puer Diskussiounen doriwwer, ob de ganzen Zyklus vun der Problementdeckung duerch Sanéierung bis eng laangfristeg Léisung fonnt gëtt, einfach automatiséiert ginn, awer e puer ware besuergt, datt sou eng Léisung d'Verzögerung vum Problem tatsächlech fixéiere géif.
Dës Spannung war heefeg am Team an huet dacks e Manktem u Vertrauen an der Selbstdisziplin reflektéiert: wärend e puer Teammemberen Zäit fir déi richteg Fix wëllen erlaben, anerer fäerten datt déi lescht Fix vergiess gëtt an déi temporär Fix fir ëmmer dauert. Dëst Thema verdéngt Opmierksamkeet well et ze einfach ass fir Problemer temporär ze fixéieren anstatt d'Situatioun permanent ze maachen. Manager an technesch Personal spillen eng Schlësselroll bei der Ëmsetzung vun laangfristeg Fixer, ënnerstëtzen a prioritär potenziell laangfristeg Fixer och nodeems den initialen "Péng" ofgeet.
Regelméisseg, repetitive Alarmer an algorithmesch Äntwerte sollten e roude Fändel sinn. D'Verzweiflung vun Ärem Team fir dës Alarmer ze automatiséieren heescht datt d'Team Vertrauen feelt datt se d'Algorithmen vertraue kënnen. Dëst ass e seriöse Problem dee muss ugeholl ginn.
Laangzäit
E gemeinsamt Thema verbënnt d'Bigtable a Gmail Beispiller: d'Konkurrenz tëscht kuerzfristeg a laangfristeg Disponibilitéit. Dacks kann e staarken Effort engem fragile System hëllefen eng héich Disponibilitéit z'erreechen, awer dëse Wee ass normalerweis kuerzlieweg, voll mat Teamburnout an Ofhängegkeet vun enger klenger Zuel vu Membere vun deemselwechten heroeschen Team.
Kontrolléiert, kuerzfristeg Reduktioun vun der Disponibilitéit ass dacks schmerzhaf, awer strategesch wichteg fir d'laangfristeg Stabilitéit vum System. Et ass wichteg net all Alarm isoléiert ze kucken, mee ze kucken ob de Gesamtniveau vum Alarmvolumen zu engem gesonden, richteg zougängleche System mat engem viabelen Team an enger favorabeler Prognose féiert. Mir analyséieren Alarmfrequenzstatistiken (normalerweis ausgedréckt als Tëschefäll pro Verschiebung, wou en Tëschefall aus multiple verbonnen Tëschefäll besteet) a Véierelberichter un d'Gestioun, wat Décideuren erlaabt eng kontinuéierlech Vue op d'Laascht vum Alarmsystem an d'allgemeng Teamgesondheet ze hunn.
Konklusioun
De Wee fir gesond Iwwerwaachung an Alarmung ass einfach a kloer. Et konzentréiert sech op d'Symptomer vum Problem, deen Alarmer ausléisen, an d'Iwwerwaachung vun der Ursaach déngt als Hëllef fir Probleemer ze Debugging. D'Iwwerwaachungssymptomer ass méi einfach wat Dir méi héich am Stack sidd deen Dir kontrolléiert, obwuel d'Iwwerwaachung vun der Belaaschtung an der Leeschtung vun der Datebank direkt op der Datebank selwer gemaach soll ginn. E-Mail Notifikatiounen hu ganz limitéiert Nëtzlechkeet an tendéieren einfach Kaméidi ze ginn; amplaz, Dir sollt en Dashboard benotzen, deen all aktuell Themen iwwerwaacht, déi E-Mail Alarmer ausléisen. Den Dashboard kann och mat engem Event Log gepaart ginn fir historesch Korrelatiounen ze analyséieren.
Op laang Siicht ass et néideg fir eng erfollegräich Rotatioun vun Alarmer iwwer Symptomer an bevirsteet richteg Problemer z'erreechen, Ziler z'adaptéieren fir sécherzestellen datt d'Iwwerwaachung eng séier Diagnos ënnerstëtzt.
Merci fir d'Iwwersetzung bis zum Schluss ze liesen. Abonnéiert Iech op mengem Telegram Kanal iwwer Iwwerwaachung и .
Source: will.com