Laiko eilučių stebėjimas ir įvykių valdomas stebėjimas
Norint pasirinkti tinkamą stebimumo strategiją, reikia suprasti, kaip renkami ir apdorojami duomenys. Laiko eilučių stebėjimas reguliariai seka skaitmeninius sistemos rodiklius, kad atskleistų ilgalaikes sveikatos tendencijas, o įvykiais pagrįstas stebėjimas nedelsdamas fiksuoja atskirus būsenos pokyčius, kad suaktyvintų momentinius programinius atsakymus, todėl jų architektūriniai projektai iš esmės skiriasi.
Akcentai
Laiko eilutės remiasi nuspėjama intervaline apklausa, o įvykių stebėjimas veikia tik pagal poreikį.
Įvykių telemetrija išsaugo gilų naudingosios apkrovos kontekstą, kurio tradicinės skaitinės metrikos atmeta.
Laiko eilučių saugojimo reikalavimai išlieka stabilūs, o įvykių saugykla seka sistemos aktyvumo šuolius.
Įvykiais pagrįstos sąrankos leidžia atlikti neatidėliotiną automatinį savęs taisymą, o ne retrospektyvią analizę.
Kas yra Laiko eilučių stebėjimas?
Metrikomis pagrįstas metodas, kai skaitiniai duomenys renkami nuosekliais chronologiniais intervalais, siekiant analizuoti sistemos tendencijas.
Labai priklauso nuo reguliarių apklausų intervalų, pavyzdžiui, duomenų nuskaitymo kas penkiolika sekundžių.
Saugo duomenis kaip struktūrizuotas, skaitines reikšmes, susietas su konkrečiais laiko žymomis ir dimensijų žymomis.
Optimizuota didelio našumo agregavimo užklausoms, pvz., vidutinio procesoriaus naudojimo per mėnesį skaičiavimui.
Paprastai naudojama „pull“ pagrindu sukurta architektūra, kai centrinis serveris siunčia duomenų užklausas iš tikslinių galinių taškų.
Išlaiko nuspėjamą saugyklos augimą, nes duomenų įkėlimo greitis išlieka pastovus, nepriklausomai nuo sistemos apkrovos.
Kas yra Įvykiais pagrįstas stebėjimas?
Reaktyvi sistema, kuri fiksuoja ir apdoroja išsamius kontekstinius duomenų paketus, kai įvyksta konkretus būsenos pasikeitimas.
Veikia asinchroniškai, vykdydamas veiksmus tik tada, kai apibrėžta sąlyga arba sistemos incidentas sukelia įspėjimą.
Kiekviename pakete fiksuoja gilius kontekstinius metaduomenis, įskaitant visą naudingosios apkrovos informaciją ir naudotojų ID.
Naudoja tiesioginio perdavimo architektūrą, kurioje atskiros programos nedelsdamos perduoda įvykius į įvykių magistralę.
Saugyklos reikalavimai dinamiškai keičiasi kartu su sistemos aktyvumu ir staiga padidėja netikėtų srauto šuolių metu.
Tiesiogiai integruojasi su automatizavimo įrankiais, kad infrastruktūra akimirksniu būtų atkurta savaime, nereikalaujant žmogaus įsikišimo.
Palyginimo lentelė
Funkcija
Laiko eilučių stebėjimas
Įvykiais pagrįstas stebėjimas
Duomenų rinkimo aktyviklis
Reguliarūs, iš anksto nustatyti laiko intervalai
Staigus būsenos pasikeitimo atsiradimas
Pirminis duomenų formatas
Skaitmeninės raktų ir reikšmių poros su laiko žymomis
Raiškiosios JSON arba struktūrizuoto teksto naudingosios apkrovos
Architektūrinis raštas
Pirmiausia traukimo pagrindu atliekamas grandymas
Tiesioginis srautinis perdavimas per pranešimų tarpininkus
Saugojimo augimas
Labai nuspėjamas ir linijinis
Kintamas ir tiesiogiai susijęs su sistemos aktyvumu
Idealus naudojimo atvejis
Pajėgumų planavimas ir ilgalaikių tendencijų analizė
Momentinis reagavimas į incidentus ir automatinis savęs atstatymas
Užklausos fokusas
Matematiniai agregavimai per laiko intervalus
Atskirų įvykių kelių ir struktūrinių mutacijų sekimas
Sistemos pridėtinės išlaidos
Mažas ir pastovus išteklių poveikis
Kintamas išteklių suvartojimas, pagrįstas įvykių kiekiu
Išsamus palyginimas
Duomenų įkėlimo mechanika
Laiko eilučių stebėjimas veikia kaip pastovus širdies ritmas, fiksuotais intervalais teikdamas užklausas sistemoms, kad surinktų našumo momentines nuotraukas. Šis metodas užtikrina nuolatinį skaitinių duomenų srautą, leidžiantį varikliams lengvai braižyti istorines trajektorijas. Kita vertus, įvykiais pagrįstas stebėjimas tyliai veikia, kol kažkas konkretaus nepakeičia aplinkos, akimirksniu siųsdamas išsamų duomenų paketą. Tai reiškia, kad įvykiais pagrįstas modelis neveikia ramybės periodais, tačiau įsijungia su itin išsamia informacija tą milisekundę, kai įvyksta gedimas.
Detalumas ir kontekstas
Atliekant išsamias diagnostikos užduotis, duomenų gylio skirtumai tampa akivaizdūs. Laiko eilučių struktūros pašalina tekstą ir kontekstą, kad būtų galima sutelkti dėmesį tik į skaičius, todėl viskas išlieka paprasta, bet neįtraukiama gedimo priežastis. Įvykiais pagrįsti žurnalai išsaugo visą kontekstinį foną, tiksliai nurodydami, kuris vartotojas ar funkcija nutraukė vykdymo kelią. Laiko eilučių grafikas rodo jūsų duomenų bazės ryšių sukeltus sutrikimus, o įvykių srautas rodo tikslią užklausą, kuri sukėlė problemą.
Mastelio keitimas ir saugojimo dinamika
Šių platformų finansinių ir saugojimo išteklių valdymas reikalauja dviejų visiškai skirtingų mąstysenų. Laiko eilučių konfigūracijos suteikia paguodžiamą nuspėjamumą, nes mastelio keitimas paprastai reiškia tik saugojimo politikos koregavimą arba apklausų intervalų prailginimą. Įvykiais pagrįstos sistemos yra daug nepastovesnės, joms reikalinga saugojimo architektūra, kuri galėtų susidoroti su staigiais, didžiuliais duomenų srautais, kai klaidos plinta per mikropaslaugas. Jei jūsų programa tampa virusinė arba patiria DDoS ataką, įvykių saugojimo reikalavimai išaugs kartu su gaunamu srautu.
Veiksmingumas ir įspėjimo greitis
Jūsų operacijų komandos reagavimo greitis visiškai priklauso nuo to, kaip teikiama jūsų telemetrija. Laiko eilučių įspėjimai natūraliai patiria nedidelį vėlavimą, nes sistema turi laukti kito duomenų rinkimo ciklo ir įvertinti kelis duomenų taškus, kad patvirtintų tendenciją. Įvykiais pagrįstos architektūros čia pranoksta tai, kad pašalina tarpininkus, nukreipia kritinius gedimus tiesiai į pranešimų platformas arba automatiškai keičia scenarijus vos jiems įvykus. Ši momentinių pranešimų galimybė daro įvykiais pagrįstą metodą nepakeičiamu itin svarbiai infrastruktūrai, kuriai reikalingas neatidėliotinas taisymas.
Privalumai ir trūkumai
Laiko eilučių stebėjimas
Privalumai
+Labai nuspėjamos sandėliavimo išlaidos
+Puiki ilgalaikė tendencijų analizė
+Mažos išteklių sąnaudos
+Supaprastinta matematinė agregacija
Pasirinkta
−Trūksta detalaus teksto konteksto
−Įveda būdingus apklausų vėlavimus
−Praleidžia trumpus protarpinius šuolius
−Kovos su trumpalaike infrastruktūra
Įvykiais pagrįstas stebėjimas
Privalumai
+Momentinis įspėjimas realiuoju laiku
+Išsamus situacinių metaduomenų išsaugojimas
+Puikiai tinka atjungtoms sistemoms
+Suaktyvina tiesioginius automatizuotus darbo eigų procesus
Laiko eilučių stebėjimas gali užfiksuoti kiekvieną sistemos elgesio mikrosvyravimų svyravimą.
Realybė
Kadangi laiko eilučių stebėjimas remiasi intervalais pagrįsta apklausa, bet koks našumo padidėjimas, kuris atsiranda ir visiškai išnyksta tarp dviejų duomenų išgavimo ciklų, jūsų ataskaitų suvestinėse bus visiškai nematomas.
Mitas
Įvykiais pagrįsta telemetrija yra prieinama tradicinio žurnalų agregavimo alternatyva.
Realybė
Kiekvieno sistemos įvykio saugojimas su visais kontekstiniais metaduomenimis gali greitai tapti pernelyg brangus, dažnai kainuojantis daug daugiau nei optimizuotas laiko eilučių metrikos variklis esant didžiausioms apkrovoms.
Mitas
Turite pasirinkti vieną metodiką ir ją išimtinai diegti visoje savo infrastruktūroje.
Realybė
Šiuolaikinės įmonių stebėjimo sistemos beveik visada sujungia abi sistemas, naudodamos laiko eilučių duomenis aukšto lygio sveikatos ataskaitų suvestinėms ir įvykių valdomiems signalams, kad būtų galima atsekti konkrečias operacijų klaidas.
Mitas
Įvykiais pagrįsti stebėjimo įrankiai automatiškai apskaičiuoja jūsų sistemos prieinamumo procentus.
Realybė
Įvykių srautai žino tik kada kas nors įvyksta, o tai reiškia, kad jiems trūksta pastovaus ritmo, reikalingo lengvai apskaičiuoti veikimo laiką. Norint generuoti prieinamumo metriką, paprastai reikia konvertuoti šiuos atskirus įvykius į nepertraukiamą laiko eilučių formatą.
Dažnai užduodami klausimai
Ar galiu naudoti „Prometheus“ įvykių valdomoms stebėjimo užduotims?
Ne efektyviai, nes „Prometheus“ buvo sąmoningai sukurtas nuo nulio kaip laiko eilučių metrikos variklis, pagrįstas traukimo principais. Bandymas priversti jį apdoroti atskirus būsenos įvykius perkraus jo vidinės atminties modelį, kuris skirtas „float64“ skaičiams, o ne turtingiems, teksto gausiems įvykių paketams.
Kodėl įvykiais pagrįsta stebėsena apsunkina pajėgumų planavimą?
Pajėgumų planavimui reikalingas nuolatinis, istorinis išteklių naudojimo stebėjimas, kad būtų galima pastebėti nuolatinius naudojimo modelius ir prognozuoti būsimus infrastruktūros poreikius. Įvykių duomenys yra išsklaidyti ir nereguliarūs, todėl matematiškai sunku apskaičiuoti sklandžius bazinius rodiklius, reikalingus ilgalaikėms prognozėms.
Kas nutinka įvykių valdomiems monitoriams, kai sistema visiškai sugenda?
Jei nutrūksta visas serveris ar tinklo ryšys, įvykiais pagrįsta sistema gali visiškai nustoti siųsti įvykius, o tai gali klaidingai atrodyti kaip visiškai sveika sistema. Dėl šios tylos komandos įvykių architektūras apgaubia paprastais laiko eilučių pranešimais, kad užtikrintų, jog pagrindinė platforma vis dar veikia.
Kuris stebėjimo stilius geriau tinka serverio neturinčioms funkcijoms, tokioms kaip AWS Lambda?
Įvykiais pagrįstas stebėjimas puikiai tinka serverių neturinčioms aplinkoms, nes funkcijos yra trumpalaikės ir greitai nustoja galioti. Tradiciniai laiko eilučių grandikliai dažnai visiškai praleidžia šiuos trumpalaikius vykdymus, o tiesioginiais įvykiais pagrįsti įvykiai fiksuoja visą vykdymo ciklą tuo metu, kai funkcija suaktyvinama.
Kuo skiriasi šių dviejų telemetrijos metodų derinimo darbo eigos?
Kai inžinierius derina su laiko eilučių duomenimis, jis nagrinėja plačias regresijas, pavyzdžiui, nustato laiko tarpą, kuriame klaidų procentai išaugo. Naudodamas įvykių pagrįstus duomenis, inžinierius tiesiogiai tikrina unikalų operacijų pėdsaką, kad tiksliai pamatytų, kuris API iškvietimas nutraukė operacinę seką.
Ar įvykiais pagrįsta telemetrija turi įtakos programos našumui?
Taip gali būti, jei jis prastai sukonfigūruotas, nes sinchroniškai perduodant dideles apkrovas turinčias struktūras iš pagrindinio programos kelio, atsiranda apdorojimo vėlavimas. Siekdami sumažinti šią riziką, kūrėjai paprastai perduoda įvykių registravimą foninėms demonoms arba asinchroninių pranešimų eilėms, kad vartotojams pateikiamos eilutės būtų greitos.
Koks yra geriausias būdas tvarkyti didelio kardinalumo duomenis, pvz., naudotojų ID?
Didelio kardinalumo duomenys pažeidžia tradicines laiko eilučių duomenų bazes, nes kiekvienas unikalus žymų derinys sukuria visiškai naują sekimo failą, sunaudojantį daug atminties. Įvykiais pagrįstos struktūros neturi šio apribojimo, lengvai apdoroja milijonus unikalių naudotojų ID, nes kiekvienas įvykis traktuojamas kaip atskiras žurnalo įrašas.
Kuo skiriasi įspėjimo slenksčiai tarp metrikų ir įvykių?
Metriniai įspėjimai remiasi matematinėmis tendencijomis, pavyzdžiui, suveikia, kai vidutinis klaidų lygis dešimt minučių iš eilės išlieka didesnis nei penki procentai. Įvykių įspėjimai yra dvejetainiai ir aiškūs, suveikiantys nedelsiant, kai duomenų sraute atsiranda konkretaus tipo kritinis gedimas.
Nuosprendis
Rinkitės laiko eilučių stebėjimą, jei jūsų pagrindiniai tikslai yra ataskaitų srities vizualizavimas, pajėgumų prognozavimas ir bendros infrastruktūros būklės stebėjimas per ilgą laikotarpį. Kurdami atsietas mikropaslaugas, realaus laiko audito srautus arba automatizuotas savęs atstatymo sistemas, kurios turi akimirksniu reaguoti į konkrečias programinės įrangos anomalijas, kreipkitės į įvykių valdomą stebėjimą.