Az SRE (Site Reliability Engineering) egy megközelítés a webes projektek elérhetőségének biztosítására. Ez a DevOps keretrendszere, és arról beszél, hogyan érhet el sikereket a DevOps gyakorlatok alkalmazásában. Fordítás ebben a cikkben könyvek a Google-tól. Ezt a fordítást magam készítettem, és saját tapasztalataimra támaszkodtam a megfigyelési folyamatok megértésében. A távirati csatornán и Közzétettem egy hivatkozást is ugyanennek a könyvnek a szolgáltatási szintű célokról szóló 4. fejezetének fordításához.
Fordítás: cat. Élvezd az olvasást!
A Google SRE csapatai rendelkeznek a sikeres megfigyelési és értesítési rendszerek létrehozásának alapelveivel és bevált gyakorlataival. Ez a fejezet útmutatást ad arra vonatkozóan, hogy a weboldal látogatói milyen problémákkal találkozhatnak, és hogyan lehet megoldani azokat a problémákat, amelyek megnehezítik a weboldalak megjelenítését.
meghatározzák
Nincs egyetlen szókészlet sem a monitorozással kapcsolatos témák megvitatására. Még a Google-on sem használják az alábbi kifejezéseket, de felsoroljuk a leggyakoribb értelmezéseket.
megfigyelés
Valós idejű mennyiségi adatok gyűjtése, feldolgozása, összesítése és megjelenítése a rendszerről: kérések száma és kéréstípusai, hibák száma és hibatípusai, kérésfeldolgozási idő és szerver üzemidő.
Fehér doboz felügyelet
A belső rendszerösszetevők által megjelenített mérőszámokon alapuló megfigyelés, beleértve a naplókat, a Java virtuális gép profilozási mérőszámait vagy a belső statisztikákat generáló HTTP-kezelő mérőszámait.
Fekete doboz felügyelet
Az alkalmazás viselkedésének tesztelése a felhasználó szemszögéből.
Irányítópult
Olyan felület (általában web), amely áttekintést nyújt a szolgáltatások legfontosabb egészségügyi mutatóiról. A műszerfalon lehetnek szűrők, a megjelenített mutatók kiválasztásának lehetősége stb. Az interfész célja a felhasználók számára legfontosabb mutatók azonosítása. Az irányítópult információkat is megjeleníthet a műszaki támogató személyzet számára: kérések sora, kiemelten fontos hibák listája és egy adott felelősségi területhez kijelölt mérnök.
Figyelmeztetés (értesítés)
Azok az értesítések, amelyeket egy személy e-mailben vagy más módon szeretne megkapni, és amelyeket hibák vagy a kérési sor növekedése válthat ki. Az értesítések osztályozása: jegyek, e-mailes figyelmeztetések és azonnali üzenetküldő üzenetek.
Kiváltó ok
Szoftverhiba vagy emberi hiba, amely a kijavítás után többé nem fordulhat elő. A problémának több fő oka is lehet: elégtelen folyamatautomatizálás, szoftverhiba, az alkalmazási logika elégtelen kidolgozottsága. Ezen tényezők mindegyike kiváltó ok lehet, és mindegyiket meg kell szüntetni.
Csomópont és gép (csomópont és gép)
Cserélhető kifejezések, amelyek egy fizikai kiszolgálón, virtuális gépen vagy tárolón futó alkalmazás egyetlen példányára vonatkoznak. Egy gép több szolgáltatást is befogadhat. A szolgáltatások lehetnek:
- egymással összekapcsolva: például egy gyorsítótárazó szerver és egy webszerver;
- nem kapcsolódó szolgáltatások egyetlen hardveren: például egy kódtár és egy konfigurációs rendszer varázslója, mint pl. vagy .
Nyomja
Bármilyen változás a szoftver konfigurációjában.
Miért van szükség monitorozásra?
Számos oka lehet annak, hogy az alkalmazásokat ellenőrizni kell:
A hosszú távú trendek elemzése
Mekkora az adatbázis és milyen gyorsan bővül? Hogyan változik a napi felhasználók száma?
Teljesítmény-összehasonlítás
Gyorsabbak a kérések az Acme Bucket of Bytes 2.72-ben az Ajax DB 3.14-hez képest? Mennyivel jobbak a kérések gyorsítótárazása egy további csomópont megjelenése után? Lassabban fut az oldal a múlt héthez képest?
Figyelmeztetés (értesítések)
Valami elromlott, és valakinek meg kell javítania. Vagy hamarosan elromlik valami, és valakinek hamarosan ellenőriznie kell.
Irányítópultok létrehozása
Az irányítópultoknak meg kell válaszolniuk az alapvető kérdéseket, és tartalmazniuk kell valamit — késések (latencia), forgalom (forgalom), hibák (hibák) és terhelés mérete (telítettség).
Retrospektív elemzés készítése (hibakeresés)
A kérésfeldolgozási késedelem megnőtt, de mi történt még ugyanebben az időben?
A felügyeleti rendszerek hasznosak az üzleti intelligencia rendszerek adatforrásaként és megkönnyítik a biztonsági események elemzését. Mivel ez a könyv azokra a mérnöki területekre összpontosít, amelyekben az SRE-k szakértelemmel rendelkeznek, itt nem tárgyaljuk a megfigyelési technikákat.
A megfigyelés és a riasztások lehetővé teszik a rendszer számára, hogy jelezze, ha meghibásodott vagy hamarosan meghibásodik. Ha egy rendszer nem tudja automatikusan megjavítani magát, azt szeretnénk, hogy egy ember elemezze a riasztást, megállapítsa, hogy a probléma továbbra is aktív-e, oldja meg, és meghatározza a kiváltó okot. Ha nem ellenőrzi a rendszerelemeket, soha nem fog figyelmeztetést kapni pusztán azért, mert "valami kissé furcsának tűnik".
Egy személy értesítésekkel való megterhelése meglehetősen költséges időfelhasználás a munkavállaló számára. Ha a munkavállaló dolgozik, a riasztás megszakítja a munkafolyamatot. Ha a munkavállaló otthon van, a riasztás megszakítja a személyes időt és esetleg az alvást. Ha a riasztások túl gyakran fordulnak elő, az alkalmazottak átfutják őket, elhalasztják, vagy figyelmen kívül hagyják a bejövő riasztásokat. Időről időre figyelmen kívül hagyják a valódi riasztást, amelyet a zajos események eltakarnak. A szolgáltatáskimaradások hosszú ideig tarthatnak, mivel a zajesemények megakadályozzák a probléma gyors diagnosztizálását és kijavítását. A hatékony figyelmeztető rendszerek jó jel-zaj aránnyal rendelkeznek.
Ésszerű elvárások megfogalmazása a monitoring rendszerrel szemben
Egy komplex alkalmazás monitorozásának beállítása önmagában is összetett mérnöki feladat. A Google SRE 10–12 tagú csapatában jellemzően egy vagy két emberből álló gyűjtő-, megjelenítési és riasztási eszközök infrastruktúrája mellett is van, akiknek elsődleges célja a felügyeleti rendszerek kiépítése és karbantartása. Ez a szám az idő múlásával csökkent, ahogy konszolidáltuk és központosítottuk a felügyeleti infrastruktúrát, de minden SRE-csapatban jellemzően legalább egy, kizárólag a monitorozással foglalkozó személy dolgozik. Azt kell mondanunk, hogy bár a felügyeleti rendszer irányítópultjai meglehetősen érdekesek, az SRE csapatok óvatosan kerülik azokat a helyzeteket, amelyekben valakinek a képernyőre kell néznie a problémák megfigyeléséhez.
Összességében a Google áttért az egyszerű és gyors megfigyelési rendszerekre, amelyek optimális utólagos elemzési eszközöket tartalmaznak. Kerüljük azokat a "varázslatos" rendszereket, amelyek megpróbálják megjósolni a küszöbértékeket vagy automatikusan észlelni a kiváltó okot. Az egyetlen ellenpélda az érzékelők, amelyek észlelik a nem kívánt tartalmat a végfelhasználói kérésekben; Mindaddig, amíg ezek az érzékelők egyszerűek maradnak, gyorsan felismerik a súlyos rendellenességek okait. A megfigyelési adatok használatának egyéb formátumai, mint például a kapacitástervezés vagy a forgalom-előrejelzés, bonyolultabbak. A nagyon hosszú időn át (hónapok vagy évek) alacsony mintavételi gyakorisággal (órák vagy napok) végzett megfigyelés hosszú távú tendenciát mutat.
A Google SRE csapata vegyes sikereket ért el összetett függőségi hierarchiákkal. Ritkán használunk olyan szabályokat, mint például: „Ha rájövök, hogy az adatbázis lassú, figyelmeztetést kapok, hogy lassú az adatbázis, ellenkező esetben figyelmeztetést kapok, hogy lassú a webhely.” A függőségi alapú szabályok általában rendszerünk megváltoztathatatlan részeire vonatkoznak, például az adatközpontba irányuló felhasználói forgalom szűrésére szolgáló rendszerre. Például „ha az adatközpont felé irányuló forgalomszűrés be van állítva, ne értesítsenek a felhasználói kérések feldolgozása késedelmeiről” az adatközpontból érkező riasztások egyik általános szabálya. A Google-nál kevés csapat támogatja az összetett függőségi hierarchiákat, mivel infrastruktúránkban állandó a folyamatos újrafaktorálás.
Az ebben a fejezetben leírt gondolatok egy része továbbra is aktuális: mindig van lehetőség gyorsabban haladni a tünettől a kiváltó okig, különösen a folyamatosan változó rendszerekben. Ezért, bár ez a fejezet felvázol néhány célt a felügyeleti rendszerekre és ezek elérésére, fontos, hogy a monitoring rendszerek egyszerűek és érthetőek legyenek a csapat minden tagja számára.
Hasonlóképpen ahhoz, hogy a zajszintet alacsonyan és a jelszinteket magasan tartsuk, a riasztott eszközök figyelésének módszereinek nagyon egyszerűnek és megbízhatónak kell lenniük. Az emberek számára figyelmeztetést generáló szabályoknak könnyen érthetőnek kell lenniük, és egyértelmű problémát kell jelenteniük.
Tünetek versus okok
A megfigyelőrendszernek két kérdésre kell válaszolnia: „mi tört el” és „miért tört el”.
A „mi tört el” a tünetről, a „miért tört” pedig az okról beszél. Az alábbi táblázat példákat mutat be ilyen csatlakozásokra.
tünet
ok
HTTP-hiba 500 vagy 404
Az adatbázis-kiszolgálók elutasítják a kapcsolatokat
Lassú szerverválaszok
Magas CPU kihasználtság vagy sérült Ethernet-kábel
Az Antarktiszon élő felhasználók nem kapnak macska GIF-eket
Az Ön CDN-je utálja a tudósokat és a macskákat, ezért néhány IP-cím feketelistára került
A privát tartalmak mindenhonnan elérhetővé váltak
Az új szoftverkiadás bevezetése miatt a tűzfal elfelejtett minden ACL-t, és mindenkit beengedett
A „mit” és a „miért” a legfontosabb építőelemek egy jó felügyeleti rendszer létrehozásához, maximális jellel és minimális zajjal.
Black-box vs White-box
Kombináljuk a kiterjedt White-box felügyeletet a szerény Black-box felügyelettel a kritikus mérőszámok érdekében. A Black-box és a White-box összehasonlításának legegyszerűbb módja az, hogy a Black-box a tünetekre fókuszál, és inkább reaktív, mint proaktív megfigyelés: „a rendszer jelenleg nem működik megfelelően”. A White-box a rendszerek belső ellenőrzési képességeitől függ: eseménynaplók vagy webszerverek. Így a White-box lehetővé teszi a közelgő problémák észlelését, a kérés újraküldésének tűnő hibákat stb.
Vegye figyelembe, hogy egy többrétegű rendszerben az egyik mérnök felelősségi körébe tartozó tünet egy másik mérnök felelősségi területének tünete. Például az adatbázis teljesítménye csökkent. A lassú adatbázis-olvasás az ezeket észlelő adatbázis SRE tünete. Egy lassú webhelyet megfigyelő előtérbeli SRE esetében azonban az adatbázis lassú olvasásának oka az adatbázis lassúsága. Ezért a fehér dobozos monitorozás néha a tünetekre, néha pedig az okra fókuszál, attól függően, hogy mennyire kiterjedt.
A hibakereséshez szükséges telemetria összegyűjtésekor White-box felügyelet szükséges. Ha a webszerverek lassan válaszolnak az adatbázis-lekérdezésekre, tudnia kell, hogy a webszerver milyen gyorsan kommunikál az adatbázissal, és milyen gyorsan válaszol. Ellenkező esetben nem tud különbséget tenni a lassú adatbázis-kiszolgáló és a webszerver és az adatbázis közötti hálózati probléma között.
A feketedoboz-figyelésnek kulcsfontosságú előnye van a riasztások küldésekor: értesítést küld a címzettnek, ha a probléma már valódi tüneteket eredményezett. Másrészt a monitorozás hiábavaló egy olyan Black-box probléma esetén, amely még fel sem merült, de küszöbön áll.
Négy arany jel
A négy arany figyelőjel a késleltetés, a forgalom, a hibák és a telítettség. Ha csak négy felhasználói rendszermutatót tud mérni, összpontosítson erre a négyre.
Késleltetés
A kérelem feldolgozásához szükséges idő. Fontos különbséget tenni a sikeres és a sikertelen kérések késleltetése között. Például egy adatbázissal vagy más háttérrendszerrel való kapcsolat megszakadása által okozott HTTP 500 hiba nagyon gyorsan diagnosztizálható, azonban a HTTP 500 hiba sikertelen kérést jelezhet. Az 500-as hiba általános késleltetésre gyakorolt hatásának meghatározása hibás következtetésekhez vezethet. Másrészt a lassú hiba még gyors hiba is! Ezért fontos figyelni a hiba késését, nem pedig egyszerűen kiszűrni a hibákat.
forgalom
A rendszerhez intézett kérések számát magas szintű rendszermetrikák mérik. Egy webszolgáltatás esetében ez a mérés jellemzően a másodpercenkénti HTTP-kérelmek számát jelenti, osztva a kérések természetével (például statikus vagy dinamikus tartalom). Audio streaming rendszer esetén ez a mérés a hálózati I/O sebességre vagy az egyidejű munkamenetek számára összpontosíthat. Kulcsérték-tároló rendszer esetén ez a mérés lehet tranzakciók vagy keresési eredmények másodpercenként.
Hibák
Ez az explicit (pl. HTTP 500), implicit (pl. HTTP 200, de érvénytelen tartalommal kombinált) vagy házirend (pl. „Ha egy másodperc alatt rögzített választ, minden másodperc hiba”) sikertelen kérések aránya. Ha a HTTP válaszkódok nem elegendőek az összes hibaállapot kifejezéséhez, másodlagos (belső) protokollokra lehet szükség a részleges hiba észleléséhez. Előfordulhat, hogy az összes ilyen sikertelen kérés figyelése nem tájékoztató jellegű, míg a végpontok közötti rendszertesztek segítenek észlelni, hogy helytelen tartalmat dolgoz fel.
Telítettség
A mérőszám megmutatja, milyen intenzíven használják szolgáltatását. Ez egy rendszerfigyelő intézkedés, amely azonosítja a leginkább korlátozott erőforrásokat (például memóriakorlátos rendszeren a memóriát, I/O-korlátozott rendszeren az I/O-k számát mutatja). Ne feledje, hogy sok rendszer rontja a teljesítményt, mielőtt elérné a 100%-os kihasználtságot, ezért fontos a kihasználtsági cél meghatározása.
Komplex rendszerekben a telítettség kiegészíthető magasabb szintű terhelésmérésekkel: a szolgáltatása megfelelően képes dupla forgalmat kezelni, csak 10%-kal több forgalmat bonyolít le, vagy még a jelenleginél is kevesebb forgalmat kezel? Az olyan egyszerű szolgáltatások esetében, amelyek nem rendelkeznek olyan paraméterekkel, amelyek megváltoztatják a kérés összetettségét (például "Ne adj semmit" vagy "Egyedi monoton egész számra van szükségem"), amelyek ritkán változtatják meg a konfigurációt, megfelelő lehet egy statikus terhelési teszt érték. Azonban, amint azt az előző bekezdésben tárgyaltuk, a legtöbb szolgáltatásnak közvetett jeleket kell használnia, mint például a CPU kihasználtsága vagy a hálózati sávszélesség, amelyeknek ismert felső határa van. A növekvő késleltetés gyakran a telítettség vezető mutatója. A 99. százalékos válaszidő kis ablakban (pl. egy perc) történő mérése nagyon korai telítettségi jelet adhat.
Végül a telítettség a közelgő telítettségre vonatkozó előrejelzésekhez is kapcsolódik, például: „Úgy tűnik, hogy az adatbázis 4 órán belül megtelik a merevlemeze.”
Ha megméri mind a négy aranyjelet, és ha probléma adódik valamelyik mérőszámmal (vagy telítettség esetén közeli probléma), riasztunk egy személyt, akkor a szolgáltatása többé-kevésbé lefedi a felügyeletet.
Aggodalmak a "farokkal" (vagy a műszerekkel és a teljesítménnyel)
Amikor egy megfigyelő rendszert a semmiből hozunk létre, megvan a kísértés, hogy olyan rendszert dolgozzunk ki, amely az átlagos értékeken alapul: átlagos késleltetés, a csomópontok átlagos CPU kihasználtsága vagy átlagos adatbázis-telítettség. Az utolsó két példa veszélye nyilvánvaló: a processzorok és az adatbázisok nagyon kiszámíthatatlan módon ártalmatlanodnak. Ugyanez vonatkozik a késleltetésre is. Ha egy webszolgáltatást futtat átlagosan 100 ms-os késleltetéssel, 1000 kéréssel másodpercenként, akkor a kérések 1%-a 5 másodpercet vesz igénybe. Ha a felhasználók több ilyen webszolgáltatástól függenek, akkor egy háttérrendszer 99. százaléka könnyen a frontend medián válaszidejévé válhat.
A kérések lassú átlaga és nagyon lassú végpontja közötti különbségtétel legegyszerűbb módja a statisztikákban kifejezett kérések méréseinek összegyűjtése (jó eszköz a hisztogramok megjelenítésére), nem pedig a tényleges késések: hány kérést szolgált ki a szolgáltatás, amelyek 0 ms között tartottak. és 10 ms, 10 ms és 30 ms között, 30 ms és 100 ms között, 100 ms és 300 ms, stb. kérésekből.
A mérések megfelelő részletességi szintjének kiválasztása
A rendszer különböző elemeit különböző részletességi szinten kell mérni. Például:
- A CPU-kihasználtság egy bizonyos időszakon keresztüli figyelése nem mutat hosszú távú kiugrásokat, amelyek magas késleltetéshez vezetnek.
- Másrészt egy olyan webszolgáltatás esetében, amely legfeljebb évi 9 órát vesz igénybe (99,9%-os éves rendelkezésre állás), a HTTP 200 válaszának percenkénti egyszeri vagy kétszeri ellenőrzése valószínűleg szükségtelenül gyakori.
- Hasonlóképpen, valószínűleg nem szükséges 99,9-1 percenként többször ellenőrizni a merevlemez-terület 2%-os rendelkezésre állását.
Ügyeljen arra, hogyan strukturálja a mérések részletességét. A CPU-terhelés másodpercenkénti egyszeri összegyűjtése érdekes adatokkal szolgálhat, de az ilyen gyakori mérések összegyűjtése, tárolása és elemzése nagyon költséges lehet. Ha a megfigyelési cél nagy részletességet igényel, és nem igényel nagy válaszkészséget, akkor csökkentheti ezeket a költségeket, ha beállítja a mérőszámok gyűjtését a szerveren, majd létrehoz egy külső rendszert a mérőszámok összegyűjtésére és összesítésére. Tudnál:
- Mérje meg a CPU-terhelést másodpercenként.
- Csökkentse a részletességet 5%-ra.
- Összesített mutatók percenként.
Ez a stratégia lehetővé teszi, hogy nagy részletességgel gyűjtsön adatokat anélkül, hogy magas elemzési és tárolási többletköltséggel járna.
A lehető legegyszerűbb, de nem egyszerűbb
A különböző követelmények egymásra helyezése nagyon összetett felügyeleti rendszert eredményezhet. Például a rendszer a következő bonyolító elemeket tartalmazhatja:
- Figyelmeztetések a kérésfeldolgozás késésének különböző küszöbértékei szerint, különböző százalékokban, minden típusú különböző mutató esetén.
- További kód írása a lehetséges okok felderítésére és azonosítására.
- Hozzon létre kapcsolódó irányítópultokat a problémák minden lehetséges oka számára.
A lehetséges szövődmények forrásai soha nem érnek véget. Mint minden szoftverrendszer, a felügyelet is olyan bonyolulttá válhat, hogy törékennyé válik, és nehéz megváltoztatni és karbantartani.
Ezért tervezze meg felügyeleti rendszerét úgy, hogy azt a lehető legnagyobb mértékben leegyszerűsítse. A követendő elemek kiválasztásakor tartsa szem előtt a következőket:
- A valós eseményeket leggyakrabban felfogó szabályoknak a lehető legegyszerűbbeknek, kiszámíthatóbbnak és megbízhatóbbnak kell lenniük.
- El kell távolítani az adatgyűjtésre, -összesítésre és riasztásra vonatkozó, ritkán (például néhány SRE-csapatnál kevesebb mint negyedévente) végrehajtott konfigurációt.
- Az összegyűjtött, de egyetlen előnézeti irányítópulton sem megjelenő, illetve figyelmeztetésben nem használt mutatók törölhetők.
A Google-nál az alapvető mérőszámok gyűjtése és összesítése a riasztásokkal és irányítópultokkal kombinálva viszonylag önálló rendszerként működik (a Google megfigyelőrendszere valójában több alrendszerre oszlik, de az emberek általában tisztában vannak ezen alrendszerek minden vonatkozásával). Csábító lehet a figyelést kombinálni más technikákkal az összetett rendszerek vizsgálatára: részletes rendszerprofilozás, folyamathibakeresés, kivételek vagy hibák részleteinek nyomon követése, terhelési tesztelés, naplógyűjtés és elemzés vagy forgalomvizsgálat. Míg ezeknek a dolgoknak a többsége közös az alapvető monitorozással, ezek keverése túl sok eredményt eredményez, és összetett és törékeny rendszert hoz létre. A szoftverfejlesztés sok más aspektusához hasonlóan a legjobb stratégia a különböző rendszerek támogatása világos, egyszerű, lazán csatolt integrációs pontokkal (például webes API használatával az összesített adatok olyan formátumban való lekérésére, amely hosszú ideig konzisztens marad ).
Az elvek összekapcsolása
Az ebben a fejezetben tárgyalt alapelvek egy megfigyelési és riasztási filozófiává kombinálhatók, amelyet a Google SRE csapatai támogatnak és követnek. Ennek a megfigyelési filozófiának a betartása kívánatos, jó kiindulópont a riasztási módszertan megalkotásához vagy felülvizsgálatához, és segíthet feltenni a megfelelő kérdéseket a működési funkciójával kapcsolatban, függetlenül a szervezet méretétől vagy a szolgáltatás vagy rendszer összetettségétől.
A megfigyelési és riasztási szabályok létrehozásakor a következő kérdések feltevése segíthet elkerülni a hamis pozitív eredményeket és a szükségtelen riasztásokat:
- Érzékeli-e ez a szabály a rendszer egyébként nem észlelhető állapotát, amely sürgős, cselekvésre ösztönöz, és elkerülhetetlenül érinti a felhasználót?
- Figyelmen kívül hagyhatom ezt a figyelmeztetést, ha tudom, hogy jóindulatú? Mikor és miért hagyhatom figyelmen kívül ezt a figyelmeztetést, és hogyan kerülhetem el ezt a forgatókönyvet?
- Ez a figyelmeztetés azt jelenti, hogy ez negatív hatással van a felhasználókra? Vannak-e olyan helyzetek, amikor a felhasználókat nem érinti negatívan, például a forgalomszűrés vagy olyan tesztrendszerek használatakor, amelyeknél a riasztásokat ki kell szűrni?
- Tehetek lépéseket a figyelmeztetés hatására? Sürgősek ezek az intézkedések, vagy várhatnak reggelig? Biztonságosan automatizálható egy művelet? Ez a lépés hosszú távú megoldás vagy rövid távú megoldás lesz?
- Vannak, akik több figyelmeztetést is kapnak ezzel a problémával kapcsolatban, tehát van-e mód a riasztások számának csökkentésére?
Ezek a kérdések a riasztások és figyelmeztető rendszerek alapvető filozófiáját tükrözik:
- Valahányszor riasztás érkezik, azonnal reagálnom kell. Naponta többször tudok sürgősen reagálni, mielőtt elfáradnék.
- Minden figyelmeztetésnek relevánsnak kell lennie.
- Minden riasztásra adott válasz emberi beavatkozást igényel. Ha az értesítés automatikusan feldolgozható, akkor nem szabad megérkeznie.
- A figyelmeztetéseknek olyan új problémáról vagy eseményről kell szólniuk, amely korábban nem létezett.
Ez a megközelítés elmossa bizonyos különbségeket: ha a riasztás megfelel az előző négy feltételnek, nem mindegy, hogy a riasztást White-box vagy Black-Box figyelőrendszerről küldték-e. Ez a megközelítés is megerősít bizonyos különbségeket: jobb, ha sokkal több erőfeszítést fordítunk a tünetek azonosítására, mint az okokra; ha az okokról van szó, csak az elkerülhetetlen okok miatt kell aggódnia.
Hosszú távú monitorozás
Napjaink termelékenységi környezetében a felügyeleti rendszerek egy folyamatosan fejlődő, változó szoftverarchitektúrával, munkaterhelési jellemzőkkel és teljesítménycélokkal rendelkező termelési rendszert figyelnek. A jelenleg nehezen automatizálható riasztások általánossá válhatnak, és talán érdemes is foglalkozni velük. Ezen a ponton valakinek meg kell találnia és meg kell szüntetnie a probléma kiváltó okait; ha ez a megoldás nem lehetséges, a riasztásra adott válasz teljes automatizálást igényel.
Fontos, hogy a monitoring döntéseket hosszú távú célok szem előtt tartásával hozzuk meg. Minden ma futó riasztás elvonja az ember figyelmét a rendszer holnapi fejlesztésétől, így gyakran csökken a produktív rendszer rendelkezésre állása vagy teljesítménye a megfigyelőrendszer hosszú távú fejlesztéséhez szükséges időre. Nézzünk két példát a jelenség illusztrálására.
Bigtable SRE: A Tale of Over-Alert
A Google belső infrastruktúrája általában ki van építve, és szolgáltatási szinthez (SLO) viszonyítva mérhető. Sok évvel ezelőtt a Bigtable SLO szolgáltatása egy élő klienst szimuláló szintetikus tranzakció átlagos teljesítményén alapult. A Bigtable problémái és a tárolóverem alacsonyabb szintjei miatt az átlagos teljesítményt a „nagy” korlát vezérelte: a lekérdezések legrosszabb 5%-a gyakran jelentősen lassabb volt, mint a többi.
A rendszer e-mail értesítéseket küld az SLO küszöbének közeledtével, és üzenetküldő riasztásokat küld az SLO túllépése esetén. Mindkét típusú riasztást meglehetősen gyakran küldték ki, ami elfogadhatatlanul sok tervezési időt emésztett fel: a csapat jelentős időt töltött a riasztások válogatásával, hogy megtalálja azt a néhányat, amely valóban releváns volt. Gyakran kihagytunk egy olyan problémát, amely ténylegesen érintette a felhasználókat, mert csak néhány figyelmeztetés vonatkozott erre a problémára. A riasztások közül sok nem volt sürgős az infrastruktúra érthető problémái miatt, és szabványos módon dolgozták fel őket, vagy egyáltalán nem dolgozták fel.
A helyzet orvoslására a csapat három megközelítést alkalmazott: Miközben keményen dolgoztunk a Bigtable teljesítményének javításán, ideiglenesen az SLO-célunkat a 75. percentilisre határoztuk meg a lekérdezési válaszok várakozási idejének tekintetében. Az e-mailes riasztásokat is kikapcsoltuk, mert olyan sok volt belőlük, hogy nem lehetett időt tölteni a diagnosztizálásukkal.
Ez a stratégia lehetővé tette számunkra, hogy a taktikai problémák állandó javítása helyett elkezdjük javítani a hosszú távú problémákat a Bigtable-ban és a tárolási verem alsóbb rétegeiben. A mérnökök ténylegesen elvégezhetik a munkát anélkül, hogy állandóan riasztásokkal bombáznák őket. Végül a riasztások feldolgozásának ideiglenes elhalasztása lehetővé tette számunkra, hogy javítsuk szolgáltatásunk minőségét.
Gmail: Megjósolható, algoritmikus emberi válaszok
Kezdetben a Gmail egy módosított Workqueue folyamatkezelő rendszerre épült, amelyet a keresési indexek kötegelt feldolgozására terveztek. A Workqueue-t a hosszú élettartamú folyamatokhoz igazították, majd később a Gmailre is alkalmazták, de az átláthatatlan ütemezőkód néhány hibája nagyon nehezen javítható.
Abban az időben a Gmail felügyelete úgy volt felépítve, hogy riasztások induljanak el, ha az egyes feladatokat a Workqueue segítségével törölték. Ez a megközelítés nem volt ideális, mert a Gmail még akkoriban is sok ezer feladatot látott el, amelyek mindegyikét felhasználóink töredék százaléka biztosította. Nagyon aggódtunk amiatt, hogy jó felhasználói élményt biztosítsunk a Gmail-felhasználóknak, de a sok riasztás kezelése elérhetetlen volt.
A probléma megoldása érdekében a Gmail SRE olyan eszközt hozott létre, amely a lehető legjobban segíti az ütemező hibakeresését a felhasználókra gyakorolt hatás minimalizálása érdekében. A csapat megbeszéléseket folytatott arról, hogy egyszerűen automatizálják-e a teljes ciklust a probléma felfedezésétől a helyreállításon át a hosszú távú megoldás megtalálásáig, de néhányan attól tartottak, hogy egy ilyen megoldás késlelteti a probléma tényleges megoldását.
Ez a feszültség gyakori volt a csapatban, és gyakran az önfegyelembe vetett bizalom hiányát tükrözte: míg egyes csapattagok időt akarnak hagyni a helyes javításra, mások attól tartanak, hogy a végső javítást elfelejtik, és az ideiglenes javítás örökké tart. Ez a probléma azért érdemel figyelmet, mert túl könnyű átmenetileg javítani a problémákat ahelyett, hogy állandósítaná a helyzetet. A menedzserek és a technikai személyzet kulcsszerepet játszanak a hosszú távú javítások végrehajtásában, támogatva és prioritásként kezelve a potenciálisan hosszú távú javításokat még a kezdeti „fájdalom” enyhülése után is.
A rendszeres, ismétlődő figyelmeztetéseknek és algoritmikus válaszoknak piros zászlónak kell lenniük. Az, hogy csapata vonakodik automatizálni ezeket a riasztásokat, azt jelenti, hogy a csapat nem bízik abban, hogy megbízhat az algoritmusokban. Ez egy komoly probléma, amelyet kezelni kell.
Hosszútávú
Gyakori téma a Bigtable és a Gmail példák összekapcsolása: a rövid távú és a hosszú távú elérhetőség közötti verseny. Gyakran egy erős erőfeszítés segíthet egy törékeny rendszernek magas rendelkezésre állás elérésében, de ez az út általában rövid életű, tele van csapatkiégéssel és ugyanannak a hősies csapatnak néhány tagjától való függéssel.
A rendelkezésre állás ellenőrzött, rövid távú csökkentése gyakran fájdalmas, de stratégiailag fontos a rendszer hosszú távú stabilitása szempontjából. Fontos, hogy ne külön-külön vizsgáljuk meg az egyes riasztásokat, hanem mérlegeljük, hogy a riasztások általános szintje egészséges, megfelelően hozzáférhető rendszerhez vezet-e, életképes csapattal és kedvező prognózissal. A riasztások gyakorisági statisztikáit (általában műszakonkénti incidensként fejezik ki, ahol egy incidens több összefüggő eseményből is állhat) elemezzük a menedzsmentnek szóló negyedéves jelentésekben, lehetővé téve a döntéshozók számára, hogy folyamatos képet kapjanak a riasztási rendszer terheléséről és a csapat általános állapotáról.
Következtetés
Az egészséges megfigyeléshez és riasztáshoz vezető út egyszerű és világos. A probléma azon tüneteire összpontosít, amelyek riasztásokat váltanak ki, és az ok figyelése segítséget nyújt a hibakereséshez. A tünetek figyelése annál egyszerűbb, minél magasabban van a vezérelt veremben, bár az adatbázis terhelésének és teljesítményének figyelését közvetlenül az adatbázison kell elvégezni. Az e-mail értesítések hasznossága nagyon korlátozott, és könnyen zajossá válnak; ehelyett olyan irányítópultot kell használnia, amely figyeli az összes aktuális problémát, amely e-mailes riasztásokat vált ki. Az irányítópult eseménynaplóval is párosítható a történeti összefüggések elemzéséhez.
Hosszú távon el kell érni a tünetekkel és a küszöbön álló valós problémákkal kapcsolatos riasztások sikeres rotációját, célokat igazítva annak biztosítására, hogy a monitorozás támogassa a gyors diagnózist.
Köszönöm, hogy végig olvastad a fordítást. Iratkozz fel a távirati csatornámra a megfigyelésről и .
Forrás: will.com