SRE (Site Reliability Engineering) is 'n benadering om die beskikbaarheid van webprojekte te verseker. Dit word beskou as 'n raamwerk vir DevOps en praat oor hoe om sukses te behaal in die toepassing van DevOps-praktyke. Vertaling in hierdie artikel boeke van Google. Ek het hierdie vertaling self voorberei en op my eie ervaring staatgemaak om moniteringsprosesse te verstaan. In die telegramkanaal и Ek het ook 'n skakel na die vertaling van Hoofstuk 4 van dieselfde boek oor diensvlakdoelwitte gepubliseer.
Vertaling deur kat. Lekker lees!
Google se SRE-spanne het basiese beginsels en beste praktyke vir die skep van suksesvolle monitering- en kennisgewingstelsels. Hierdie hoofstuk verskaf leiding oor watter probleme 'n webbladbesoeker kan teëkom en hoe om probleme op te los wat dit moeilik maak om webbladsye te vertoon.
definieer
Daar is geen enkele woordeskat wat gebruik word om onderwerpe wat met monitering verband hou, te bespreek nie. Selfs op Google word die terme hieronder nie algemeen gebruik nie, maar ons sal die mees algemene interpretasies lys.
Monitering
Insameling, verwerking, samevoeging en vertoon van kwantitatiewe data in reële tyd oor die stelsel: aantal versoeke en tipes versoeke, aantal foute en tipes foute, versoekverwerkingstyd en bediener-uptyd.
Witboks-monitering
Monitering gebaseer op maatstawwe wat deur interne stelselkomponente vertoon word, insluitend logs, Java Virtual Machine-profielmetrieke of HTTP-hanteerdermaatstawwe wat interne statistiek genereer.
Black-box monitering
Toets toepassingsgedrag vanuit die gebruiker se oogpunt.
Dashboard
'n Koppelvlak (gewoonlik web) wat 'n oorsig bied van sleutelgesondheidsaanwysers van dienste. Die paneelbord kan filters hê, die vermoë om die aanwysers te kies wat gewys word, ens. Die koppelvlak is ontwerp om die aanwysers te identifiseer wat vir gebruikers die belangrikste is. Die dashboard kan ook inligting vir tegniese ondersteuningspersoneel vertoon: 'n tou van versoeke, 'n lys van hoë-prioriteit foute, en 'n toegewysde ingenieur vir 'n gegewe area van verantwoordelikheid.
Waarskuwing (kennisgewing)
Kennisgewings wat bedoel is om deur 'n persoon per e-pos of ander manier ontvang te word, wat veroorsaak kan word deur foute of 'n toename in die versoekry. Kennisgewings word geklassifiseer as: kaartjies, e-poswaarskuwings en kitsboodskappe.
Kernoorsaak
'n Sagtewarefout of menslike fout wat, sodra dit reggestel is, nie weer moet voorkom nie. Die probleem kan verskeie hoofoorsake hê: onvoldoende prosesoutomatisering, sagtewarefout, onvoldoende uitwerking van die toepassingslogika. Elkeen van hierdie faktore kan die hoofoorsaak wees, en elkeen van hulle moet uitgeskakel word.
Nodus en masjien (nodus en masjien)
Verwisselbare terme om te verwys na 'n enkele geval van 'n lopende toepassing op 'n fisiese bediener, virtuele masjien of houer. Een masjien kan verskeie dienste huisves. Dienste kan wees:
- aan mekaar gekoppel: byvoorbeeld 'n kasbediener en 'n webbediener;
- onverwante dienste op 'n enkele stuk hardeware: byvoorbeeld 'n kodebewaarplek en 'n towenaar vir 'n konfigurasiestelsel, soos of .
Stoot
Enige verandering in sagteware konfigurasie.
Hoekom is monitering nodig?
Daar is verskeie redes waarom toepassings gemonitor moet word:
Ontleding van langtermynneigings
Hoe groot is die databasis en hoe vinnig groei dit? Hoe verander die daaglikse aantal gebruikers?
Prestasie vergelyking
Is versoeke vinniger op Acme Bucket of Bytes 2.72 in vergelyking met Ajax DB 3.14? Hoeveel beter word versoeke gekas na die verskyning van 'n bykomende nodus? Loop die webwerf stadiger in vergelyking met verlede week?
Waarskuwing (kennisgewings)
Iets is stukkend en iemand moet dit regmaak. Of iets sal binnekort breek en iemand moet dit gou nagaan.
Die skep van dashboards
Dashboards moet basiese vrae beantwoord en iets van insluit — vertragings (latency), verkeer (verkeer), foute (foute) en vraggrootte (versadiging).
Uitvoer van retrospektiewe analise (ontfouting)
Die vertraging vir die verwerking van versoeke het toegeneem, maar wat het nog omtrent dieselfde tyd gebeur?
Moniteringstelsels is nuttig as 'n bron van data vir besigheidsintelligensiestelsels en om die ontleding van sekuriteitsinsidente te vergemaklik. Omdat hierdie boek fokus op ingenieursgebiede waarin SRE's kundigheid het, sal ons nie moniteringstegnieke hier bespreek nie.
Monitering en waarskuwings stel die stelsel in staat om jou te vertel wanneer dit onklaar geraak het of op die punt is om te breek. Wanneer 'n stelsel homself nie outomaties kan herstel nie, wil ons hê dat 'n mens die waarskuwing moet ontleed, bepaal of die probleem steeds aktief is, dit oplos en die hoofoorsaak bepaal. As jy nie stelselkomponente oudit nie, sal jy nooit 'n waarskuwing ontvang bloot omdat "iets 'n bietjie vreemd lyk."
Om 'n persoon te belas met kennisgewings is 'n redelik duur gebruik van 'n werknemer se tyd. As die werknemer werk, onderbreek die waarskuwing die werksproses. As die werknemer by die huis is, onderbreek die waarskuwing persoonlike tyd en moontlik slaap. Wanneer waarskuwings te gereeld voorkom, blaai werknemers daardeur, stel dit uit of ignoreer inkomende waarskuwings. Van tyd tot tyd ignoreer hulle die werklike waarskuwing, wat deur geraasgebeure gemasker word. Diensonderbrekings kan vir lang tydperke duur aangesien geraasgebeure verhoed dat die probleem vinnig gediagnoseer en reggestel word. Doeltreffende waarskuwingstelsels het 'n goeie sein-tot-geraas-verhouding.
Stel redelike verwagtinge vir die moniteringstelsel
Die opstel van monitering vir 'n komplekse toepassing is 'n komplekse ingenieurstaak op sigself. Selfs met 'n aansienlike infrastruktuur van versameling-, vertoon- en waarskuwingnutsgoed, sluit 'n Google SRE-span van 10–12 lede tipies een of twee mense in wie se primêre doel is om moniteringstelsels te bou en in stand te hou. Hierdie getal het mettertyd afgeneem namate ons die moniteringsinfrastruktuur konsolideer en sentraliseer, maar elke SRE-span het tipies ten minste een persoon wat uitsluitlik aan monitering toegewy is. Ons moet sê dat hoewel die monitering van stelselkontroleskerms baie interessant is om na te kyk, SRE-spanne noukeurig situasies vermy wat vereis dat iemand na 'n skerm moet kyk om probleme te monitor.
In die algemeen het Google oorgeskakel na eenvoudige en vinnige moniteringstelsels met optimale na-die-feit-analise-instrumente. Ons vermy "magiese" stelsels wat probeer om drempels te voorspel of outomaties die hoofoorsaak op te spoor. Sensors wat onbedoelde inhoud in eindgebruikerversoeke opspoor, is die enigste teenvoorbeeld; Solank hierdie sensors eenvoudig bly, kan hulle vinnig die oorsake van ernstige afwykings opspoor. Ander formate vir die gebruik van moniteringsdata, soos kapasiteitsbeplanning of verkeersvoorspelling, is meer kompleks. Waarneming oor 'n baie lang tydperk (maande of jare) teen 'n lae steekproeftempo (ure of dae) sal 'n langtermyn-tendens openbaar.
Die Google SRE-span het gemengde sukses behaal met komplekse afhanklikheidshiërargieë. Ons gebruik selde reëls soos "as ek uitvind dat die databasis stadig is, kry ek 'n waarskuwing dat die databasis stadig is, anders kry ek 'n waarskuwing dat die werf stadig is." Afhanklikheidsgebaseerde reëls verwys tipies na onveranderlike dele van ons stelsel, soos die stelsel om gebruikersverkeer na die datasentrum te filter. Byvoorbeeld, "as verkeersfiltrering na die datasentrum opgestel is, moet my nie waarsku oor vertragings in die verwerking van gebruikersversoeke nie" is een algemene reël vir waarskuwings vanaf die datasentrum. Min spanne by Google ondersteun komplekse afhanklikheidshiërargieë omdat ons infrastruktuur 'n konstante tempo van deurlopende herfaktorering het.
Sommige van die idees wat in hierdie hoofstuk beskryf word, is steeds relevant: daar is altyd 'n geleentheid om vinniger van simptoom na hoofoorsaak te beweeg, veral in stelsels wat voortdurend verander. Daarom, hoewel hierdie hoofstuk 'n paar doelwitte vir moniteringstelsels uiteensit en hoe om daardie doelwitte te bereik, is dit belangrik dat moniteringstelsels eenvoudig en verstaanbaar is vir almal in die span.
Net so, om geraasvlakke laag en seinvlakke hoog te hou, moet benaderings tot die monitering van gewaarskude bates baie eenvoudig en betroubaar wees. Reëls wat waarskuwings vir mense genereer, moet maklik wees om te verstaan en 'n duidelike probleem te bied.
Simptome teenoor oorsake
Jou moniteringstelsel moet twee vrae beantwoord: "wat het gebreek" en "waarom dit gebreek het."
"Wat gebreek" praat oor die simptoom, en "waarom dit gebreek het" praat oor die oorsaak. Die tabel hieronder toon voorbeelde van sulke verbindings.
Simptoom
rede
Kry HTTP-fout 500 of 404
Databasisbedieners verwerp verbindings
Stadige bedienerreaksies
Hoë CPU-gebruik of beskadigde Ethernet-kabel
Gebruikers in Antarktika ontvang nie kat GIF's nie
Jou CDN haat wetenskaplikes en katte, so sommige IP-adresse is uiteindelik op die swartlys geplaas
Privaat inhoud het van oraloor beskikbaar geword
Die ontplooiing van 'n nuwe sagtewarevrystelling het die firewall alle ACL's laat vergeet en almal laat inkom
"Wat" en "waarom" is van die belangrikste boustene vir die skep van 'n goeie moniteringstelsel met maksimum sein en minimum geraas.
Black-box vs White-box
Ons kombineer uitgebreide White-box-monitering met beskeie Black-box-monitering vir kritieke maatstawwe. Die maklikste manier om Black-box met White-box te vergelyk, is dat Black-box simptoom-gefokus is en reaktief eerder as proaktiewe monitering is: "die stelsel werk nie nou reg nie." Witboks hang af van die interne verifikasievermoëns van stelsels: gebeurtenislogboeke of webbedieners. Dus, White-box laat jou toe om dreigende probleme op te spoor, foute wat blyk te wees 'n herversending van 'n versoek, ens.
Let daarop dat in 'n meerlaagstelsel 'n simptoom in een ingenieur se verantwoordelikheidsgebied 'n simptoom in 'n ander ingenieur se verantwoordelikheidsgebied is. Databasisprestasie het byvoorbeeld afgeneem. Stadige databasislees is 'n simptoom van die databasis SRE wat dit opspoor. Vir 'n front-end SRE wat egter 'n stadige webwerf waarneem, is die oorsaak van dieselfde stadige databasislees 'n stadige databasis. Daarom is witboksmonitering soms simptoom-gefokus en soms oorsaak-gefokus, afhangende van hoe omvangryk dit is.
Wanneer telemetrie vir ontfouting versamel word, word White-box-monitering vereis. As webbedieners stadig is om op databasisnavrae te reageer, moet jy weet hoe vinnig die webbediener met die databasis kommunikeer en hoe vinnig dit reageer. Andersins sal jy nie tussen 'n stadige databasisbediener en 'n netwerkprobleem tussen die webbediener en die databasis kan onderskei nie.
Black-box-monitering het 'n belangrike voordeel wanneer waarskuwings gestuur word: jy aktiveer die kennisgewing aan die ontvanger wanneer die probleem reeds tot werklike simptome gelei het. Aan die ander kant is monitering nutteloos vir 'n Black-box-probleem wat nog nie ontstaan het nie, maar op hande is.
Vier goue seine
Die vier goue moniteringseine is latensie, verkeer, foute en versadiging. As jy net vier gebruikersstelselstatistieke kan meet, fokus op daardie vier.
Vertraag
Die tyd wat nodig is om die versoek te verwerk. Dit is belangrik om te onderskei tussen die vertraging van suksesvolle en onsuksesvolle versoeke. Byvoorbeeld, 'n HTTP 500-fout wat veroorsaak word deur 'n verlies van verbinding met 'n databasis of ander backend kan baie vinnig gediagnoseer word, maar 'n HTTP 500-fout kan 'n mislukte versoek aandui. Die bepaling van die impak van 'n 500-fout op algehele latensie kan tot foutiewe gevolgtrekkings lei. Aan die ander kant is 'n stadige fout selfs 'n vinnige fout! Daarom is dit belangrik om foutvertraging te monitor eerder as om net foute uit te filter.
verkeer
Die aantal versoeke aan jou stelsel word gemeet in hoëvlakstelselstatistieke. Vir 'n webdiens verteenwoordig hierdie meting tipies die aantal HTTP-versoeke per sekonde, gedeel deur die aard van die versoeke (byvoorbeeld statiese of dinamiese inhoud). Vir 'n klankstroomstelsel kan hierdie meting fokus op netwerk I/O-spoed of die aantal gelyktydige sessies. Vir 'n sleutelwaarde-bergingstelsel kan hierdie meting transaksies of soekresultate per sekonde wees.
Foute
Dit is die koers van mislukte versoeke wat eksplisiet is (bv. HTTP 500), implisiet (bv. HTTP 200 maar gekombineer met ongeldige inhoud) of beleid (bv. "As jy 'n antwoord in een sekonde vasgelê het, is enige sekonde 'n fout"). As HTTP-reaksiekodes nie voldoende is om alle mislukkingstoestande uit te druk nie, kan sekondêre (interne) protokolle vereis word om gedeeltelike mislukking op te spoor. Monitering van al sulke mislukte versoeke is dalk nie insiggewend nie, terwyl end-tot-end stelseltoetse sal help om vas te stel dat jy verkeerde inhoud verwerk.
Versadiging
Die maatstaf wys hoe intensief u diens gebruik word. Dit is 'n stelselmoniteringsmaatreël wat die hulpbronne identifiseer wat die meeste beperk is (byvoorbeeld, op 'n geheue-beperkte stelsel, wys geheue, op 'n I/O-beperkte stelsel, wys die aantal I/O's). Let daarop dat baie stelsels werkverrigting verswak voordat hulle 100% benutting bereik, dus is dit belangrik om 'n gebruiksdoelwit te hê.
In komplekse stelsels kan versadiging aangevul word deur lasmetings op hoër vlak: kan jou diens dubbele verkeer behoorlik hanteer, net 10% meer verkeer hanteer, of selfs minder verkeer hanteer as wat dit tans doen? Vir eenvoudige dienste wat nie parameters het wat die kompleksiteit van die versoek verander nie (byvoorbeeld, "Gee my niks" of "Ek het 'n unieke enkele monotoniese heelgetal nodig"), wat selde konfigurasie verander, kan 'n statiese lastoetswaarde voldoende wees. Soos in die vorige paragraaf bespreek is, moet die meeste dienste egter indirekte seine gebruik, soos SVE-benutting of netwerkbandwydte, wat 'n bekende boonste grens het. Toenemende latensie is dikwels 'n leidende aanduiding van versadiging. Die meting van die 99ste persentiel reaksietyd in 'n klein venster (bv. een minuut) kan 'n baie vroeë sein van versadiging verskaf.
Laastens word versadiging ook geassosieer met voorspellings oor naderende versadiging, byvoorbeeld: "Dit lyk of jou databasis jou hardeskyf binne 4 uur sal vol maak."
As jy al vier goue seine meet en wanneer daar 'n probleem met een van die maatstawwe is (of, in die geval van versadiging, 'n byna probleem), waarsku jy 'n persoon, sal jou diens min of meer deur monitering gedek word.
Bekommernis oor die "stert" (of instrumentasie en prestasie)
Wanneer 'n moniteringstelsel van nuuts af geskep word, is daar 'n versoeking om 'n stelsel te ontwikkel wat gebaseer is op gemiddelde waardes: gemiddelde latensie, gemiddelde SVE-benutting van nodusse, of gemiddelde databasisvolheid. Die gevaar van die laaste twee voorbeelde is duidelik: verwerkers en databasisse word op 'n baie onvoorspelbare manier ontslae geraak. Dieselfde geld vir vertraging. As jy 'n webdiens met 'n gemiddelde vertraging van 100 ms met 1000 1 versoeke per sekonde bedryf, kan 5% van versoeke 99 sekondes neem. As gebruikers afhanklik is van verskeie sulke webdienste, kan die XNUMXste persentiel van een backend maklik die mediaan reaksietyd van die frontend word.
Die eenvoudigste manier om te onderskei tussen die stadige gemiddelde en die baie stadige stert van versoeke is om metings van versoeke wat in statistieke uitgedruk word te versamel ('n goeie hulpmiddel om te vertoon is histogramme) eerder as werklike vertragings: hoeveel versoeke die diens bedien het wat tussen 0 ms geneem het en 10 ms, tussen 10 ms en 30 ms, tussen 30 ms en 100 ms, tussen 100 ms en 300 ms, ens. Om die histogramgrense ongeveer eksponensieel uit te brei (met 'n benaderde faktor van 3) is dikwels 'n eenvoudige manier om die verspreiding te visualiseer van versoeke.
Kies die toepaslike vlak van detail vir metings
Verskillende elemente van die stelsel moet op verskillende vlakke van detail gemeet word. Byvoorbeeld:
- Monitering van SVE-benutting oor 'n tydperk sal nie langtermyn-stygings toon wat tot hoë latensies lei nie.
- Aan die ander kant, vir 'n webdiens wat nie meer as 9 uur stilstand per jaar mik nie (99,9% jaarlikse uptyd), sal dit waarskynlik onnodig gereeld wees om meer as een of twee keer per minuut na 'n HTTP 200-reaksie te kyk.
- Net so is dit waarskynlik nie nodig om hardeskyfspasie vir 99,9% beskikbaarheid meer as een keer elke 1-2 minute na te gaan nie.
Wees versigtig hoe jy die korreligheid van jou metings struktureer. Die versameling van SVE-lading een keer per sekonde kan interessante data verskaf, maar sulke gereelde metings kan baie duur wees om te versamel, te stoor en te ontleed. As jou moniteringsdoelwit hoë granulariteit vereis en nie hoë responsiwiteit vereis nie, kan jy hierdie koste verminder deur metriekeversameling op die bediener op te stel en dan 'n eksterne stelsel op te stel om daardie maatstawwe te versamel en saam te voeg. Kan jy:
- Meet CPU-lading elke sekonde.
- Verminder detail tot 5%.
- Versamel statistieke elke minuut.
Hierdie strategie sal jou toelaat om data teen 'n hoë korreligheid in te samel sonder om hoë analise- en bergingskoste aan te gaan.
So eenvoudig as moontlik, maar nie eenvoudiger nie
Die oorleg van verskillende vereistes bo-op mekaar kan 'n baie komplekse moniteringstelsel tot gevolg hê. Byvoorbeeld, jou stelsel kan die volgende kompliserende elemente hê:
- Waarskuwings volgens verskillende drempels vir versoekverwerkingsvertraging, in verskillende persentiele, vir alle soorte verskillende aanwysers.
- Skryf addisionele kode om moontlike oorsake op te spoor en te identifiseer.
- Skep verwante dashboards vir elk van die moontlike oorsake van probleme.
Die bronne van potensiële komplikasies hou nooit op nie. Soos alle sagtewarestelsels, kan monitering so kompleks word dat dit broos en moeilik word om te verander en in stand te hou.
Ontwerp dus jou moniteringstelsel om dit soveel as moontlik te vereenvoudig. Hou die volgende in gedagte wanneer jy kies wat om na te spoor:
- Die reëls wat die meeste werklike voorvalle vang, moet so eenvoudig, voorspelbaar en betroubaar as moontlik wees.
- Opstelling vir data-insameling, samevoeging en waarskuwing wat selde uitgevoer word (byvoorbeeld minder as kwartaalliks vir sommige SRE-spanne) moet verwyder word.
- Metrieke wat ingesamel word, maar nie in enige voorskou-kontroleskerm gewys word nie of deur enige waarskuwing gebruik word, is kandidate vir uitvee.
By Google werk die versameling en samevoeging van basiese statistieke, gekombineer met waarskuwings en kontroleskerms, goed as 'n relatief selfstandige stelsel (Google se moniteringstelsel is eintlik in verskeie substelsels opgedeel, maar mense is tipies bewus van alle aspekte van hierdie substelsels). Dit kan aanloklik wees om monitering te kombineer met ander tegnieke om komplekse stelsels te ondersoek: gedetailleerde stelselprofiele, prosesontfouting, naspeurbesonderhede oor uitsonderings of mislukkings, vragtoetsing, loginsameling en -analise, of verkeersinspeksie. Alhoewel die meeste van hierdie dinge raakpunte het met basiese monitering, sal die vermenging daarvan te veel resultate tot gevolg hê en 'n komplekse en brose stelsel skep. Soos met baie ander aspekte van sagteware-ontwikkeling, is die ondersteuning van verskillende stelsels met duidelike, eenvoudige, losgekoppelde integrasiepunte die beste strategie (byvoorbeeld die gebruik van 'n web-API om saamgevoegde data te herwin in 'n formaat wat oor 'n lang tydperk konsekwent kan bly ).
Bind die beginsels saam
Die beginsels wat in hierdie hoofstuk bespreek word, kan gekombineer word in 'n monitering- en waarskuwingsfilosofie wat deur Google SRE-spanne onderskryf en gevolg word. Om aan hierdie moniteringsfilosofie te voldoen is wenslik, is 'n goeie beginpunt vir die skep of hersiening van jou waarskuwingsmetodologie, en kan jou help om die regte vrae oor jou bedrywighede funksie te vra, ongeag die grootte van jou organisasie of die kompleksiteit van die diens of stelsel.
Wanneer jy monitering- en waarskuwingsreëls skep, kan die volgende vrae jou help om vals positiewe en onnodige waarskuwings te vermy:
- Bespeur hierdie reël 'n andersins onopspoorbare toestand van die stelsel wat dringend is, oproepe tot aksie en onvermydelik die gebruiker raak?
- Kan ek hierdie waarskuwing ignoreer met die wete dat dit goedaardig is? Wanneer en hoekom kan ek hierdie waarskuwing ignoreer en hoe kan ek hierdie scenario vermy?
- Beteken hierdie waarskuwing dat gebruikers negatief geraak word? Is daar situasies waar gebruikers nie negatief geraak word nie, soos deur verkeersfiltrering of wanneer toetsstelsels gebruik word waarvoor waarskuwings gefiltreer moet word?
- Kan ek aksie neem in reaksie op hierdie waarskuwing? Is hierdie maatreëls dringend of kan dit wag tot die oggend? Kan 'n aksie veilig geoutomatiseer word? Sal hierdie aksie 'n langtermyn oplossing of 'n korttermyn oplossing wees?
- Sommige mense kry verskeie waarskuwings vir hierdie probleem, so is daar 'n manier om die aantal waarskuwings te verminder?
Hierdie vrae weerspieël die fundamentele filosofie oor waarskuwings en waarskuwingstelsels:
- Elke keer as 'n waarskuwing inkom, moet ek dadelik reageer. Ek kan verskeie kere per dag dringend reageer voordat ek moeg word.
- Elke waarskuwing moet relevant wees.
- Elke reaksie op 'n waarskuwing moet menslike ingryping vereis. As die kennisgewing outomaties verwerk kan word, behoort dit nie te arriveer nie.
- Waarskuwings moet wees oor 'n nuwe probleem of gebeurtenis wat nie voorheen bestaan het nie.
Hierdie benadering vervaag sekere onderskeidings: as die waarskuwing aan die vorige vier voorwaardes voldoen, maak dit nie saak of die waarskuwing vanaf 'n White-box- of Black-Box-moniteringstelsel gestuur word nie. Hierdie benadering versterk ook sekere verskille: dit is beter om baie meer moeite te spandeer om simptome te identifiseer as aan oorsake; wanneer dit by oorsake kom, hoef jy net bekommerd te wees oor die onvermydelike oorsake.
Langtermyn monitering
In vandag se produktiwiteitsomgewings monitor moniteringstelsels 'n steeds-ontwikkelende produksiestelsel met veranderende sagteware-argitektuur, werklading-eienskappe en prestasieteikens. Waarskuwings wat tans moeilik is om te outomatiseer, kan alledaags word, miskien selfs die moeite werd om aan te spreek. Op hierdie stadium moet iemand die grondoorsake van die probleem vind en uitskakel; indien sodanige oplossing nie moontlik is nie, vereis die reaksie op die waarskuwing volle outomatisering.
Dit is belangrik dat moniteringsbesluite geneem word met langtermyndoelwitte in gedagte. Elke waarskuwing wat vandag loop, lei 'n persoon af om die stelsel môre te verbeter, so daar is dikwels 'n vermindering in die beskikbaarheid of werkverrigting van 'n produktiewe stelsel vir die tyd wat nodig is om die moniteringstelsel op die lang termyn te verbeter. Kom ons kyk na twee voorbeelde om hierdie verskynsel te illustreer.
Bigtable SRE: A Tale of Over-Alert
Google se interne infrastruktuur word tipies voorsien en gemeet aan 'n diensvlak (SLO). Baie jare gelede was Bigtable se diens SLO gebaseer op die gemiddelde prestasie van 'n sintetiese transaksie wat 'n lewendige kliënt simuleer. As gevolg van probleme in Bigtable en laer vlakke van die bergingstapel, is gemiddelde werkverrigting gedryf deur 'n "groot" stert: die ergste 5% van navrae was dikwels aansienlik stadiger as die res.
E-poskennisgewings is gestuur namate die SLO-drempel genader is, en boodskapperwaarskuwings is gestuur wanneer die SLO oorskry is. Beide tipes waarskuwings is gereeld gestuur, wat onaanvaarbare hoeveelhede ingenieurstyd in beslag geneem het: die span het 'n aansienlike hoeveelheid tyd spandeer om deur die waarskuwings te sorteer om die paar te vind wat werklik relevant was. Ons het dikwels 'n kwessie gemis wat gebruikers eintlik geraak het, want slegs sommige van die waarskuwings was vir daardie spesifieke kwessie. Baie van die waarskuwings was nie dringend nie weens verstaanbare probleme in die infrastruktuur en is op 'n standaard manier verwerk, of is glad nie verwerk nie.
Om die situasie reg te stel, het die span 'n drieledige benadering gevolg: Terwyl ons hard gewerk het om Bigtable se werkverrigting te verbeter, het ons ons SLO-doelwit tydelik gestel om die 75ste persentiel vir navraagreaksie-vertraging te wees. Ons het ook e-poswaarskuwings afgeskakel omdat daar so baie van hulle was dat dit onmoontlik was om tyd te spandeer om hulle te diagnoseer.
Hierdie strategie het ons die blaaskans in staat gestel om langtermynprobleme in Bigtable en die onderste lae van die bergingstapel te begin regstel, eerder as om voortdurend taktiese probleme op te los. Ingenieurs kon eintlik werk gedoen kry sonder om heeltyd met waarskuwings gebombardeer te word. Uiteindelik het die tydelike uitstel van waarskuwingsverwerking ons in staat gestel om die kwaliteit van ons diens te verbeter.
Gmail: Voorspelbare, algoritmiese menslike reaksies
By sy ontstaan was Gmail gebou op 'n gewysigde Workqueue-prosesbestuurstelsel wat ontwerp is om stukke van 'n soekindeks te verwerk. Workqueue is aangepas vir langlewende prosesse en is daarna op Gmail toegepas, maar sommige foute in die ondeursigtige skeduleerderkode was baie moeilik om reg te stel.
Destyds was Gmail-monitering so gestruktureer dat waarskuwings geaktiveer sou word wanneer individuele take met Workqueue gekanselleer is. Hierdie benadering was nie ideaal nie, want selfs op daardie tydstip het Gmail baie duisende take uitgevoer, wat elkeen aan 'n fraksie van 'n persent van ons gebruikers verskaf is. Ons was baie bekommerd daaroor om Gmail-gebruikers 'n goeie gebruikerservaring te bied, maar die hantering van soveel waarskuwings was buite bereik.
Om hierdie probleem aan te spreek, het Gmail SRE 'n hulpmiddel geskep om die skeduleerder so goed moontlik te ontfout om die impak op gebruikers te verminder. Die span het 'n paar besprekings gehad oor die vraag of hulle eenvoudig die hele siklus van probleemontdekking deur remediëring moet outomatiseer totdat 'n langtermynoplossing gevind is, maar sommige was bekommerd dat so 'n oplossing die werklike oplossing van die probleem sou vertraag.
Hierdie spanning was algemeen in die span en het dikwels 'n gebrek aan vertroue in selfdissipline weerspieël: terwyl sommige spanlede tyd wil toelaat vir die korrekte oplossing, is ander bekommerd dat die finale oplossing vergeet sal word en die tydelike oplossing vir ewig sal duur. Hierdie kwessie verdien aandag omdat dit te maklik is om probleme tydelik op te los in plaas daarvan om die situasie permanent te maak. Bestuurders en tegniese personeel speel 'n sleutelrol in die implementering van langtermyn regstellings, ondersteun en prioritiseer potensieel langtermyn regstellings selfs nadat die aanvanklike "pyn" bedaar.
Gereelde, herhalende waarskuwings en algoritmiese reaksies moet 'n rooi vlag wees. Jou span se onwilligheid om hierdie waarskuwings te outomatiseer beteken dat die span nie vertroue het dat hulle die algoritmes kan vertrou nie. Dit is 'n ernstige probleem wat aangespreek moet word.
Lang termyn
’n Algemene tema verbind die Bigtable- en Gmail-voorbeelde: die kompetisie tussen korttermyn- en langtermynbeskikbaarheid. Dikwels kan 'n sterk poging 'n brose stelsel help om hoë beskikbaarheid te bereik, maar hierdie pad is gewoonlik van korte duur, belaai met spanuitbranding en afhanklikheid van 'n klein aantal lede van dieselfde heldhaftige span.
Beheerde, korttermyn vermindering in beskikbaarheid is dikwels pynlik, maar strategies belangrik vir die langtermyn stabiliteit van die stelsel. Dit is belangrik om nie na elke waarskuwing in isolasie te kyk nie, maar om te oorweeg of die algehele vlak van waarskuwingsvolume lei tot 'n gesonde, behoorlik toeganklike stelsel met 'n lewensvatbare span en 'n gunstige prognose. Ons ontleed waarskuwingsfrekwensiestatistieke (gewoonlik uitgedruk as voorvalle per skof, waar 'n voorval uit veelvuldige verwante voorvalle kan bestaan) in kwartaallikse verslae aan bestuur, wat besluitnemers in staat stel om 'n deurlopende siening van waarskuwingstelsellading en algehele spangesondheid te hê.
Gevolgtrekking
Die pad na gesonde monitering en waarskuwing is eenvoudig en duidelik. Dit fokus op die simptome van die probleem wat waarskuwings veroorsaak, en die monitering van die oorsaak dien as 'n hulpmiddel om probleme te ontfout. Monitering van simptome is makliker hoe hoër jy in die stapel is wat jy beheer, alhoewel die monitering van lading en werkverrigting van die databasis direk op die databasis self gedoen moet word. E-poskennisgewings het baie beperkte bruikbaarheid en is geneig om maklik geraas te word; in plaas daarvan, moet jy 'n dashboard gebruik wat alle huidige kwessies monitor wat e-poswaarskuwings veroorsaak. Die dashboard kan ook met 'n gebeurtenislogboek gekoppel word om historiese korrelasies te ontleed.
Op die lang termyn is dit nodig om 'n suksesvolle rotasie van waarskuwings oor simptome en dreigende werklike probleme te bereik, deur doelwitte aan te pas om te verseker dat monitering vinnige diagnose ondersteun.
Dankie dat jy die vertaling tot die einde gelees het. Teken in op my telegramkanaal oor monitering и .
Bron: will.com