David O’Brien nedavno je otvorio svoju vlastitu tvrtku Xirus (https://xirus.com.au), usredotočujući se na Microsoft Azure Stack cloud proizvode. Oni su namijenjeni dosljednom razvoju i pokretanju hibridnih aplikacija u podatkovnim centrima, na rubnim lokacijama, u udaljenim uredima i u oblaku.
David obučava pojedince i tvrtke o svemu vezanom uz Microsoft Azure i Azure DevOps (bivši VSTS) te se i dalje bavi praktičnim savjetovanjem i infrastrukturnim kodiranjem. Već pet godina je dobitnik Microsoft MVP (Najvredniji Microsoftov stručnjak) nagrade, a nedavno je dobio MVP Azure nagradu. Kao suorganizator Melbourne Microsoft Cloud i Datacentre Meetupa, O’Brien redovito nastupa na međunarodnim konferencijama, kombinirajući svoj interes za putovanja po svijetu s strašću dijeljenja IT priča s zajednicom. Davidov blog se nalazi na , također objavljuje svoje online treninge na Pluralsight.
U predavanju se raspravlja o važnosti metrika za razumijevanje što se događa u vašem okruženju i kako vaše aplikacije funkcioniraju. Microsoft Azure nudi moćan i jednostavan način prikaza metrika za sve vrste radnih opterećenja, a na predavanju se objašnjava kako ih sve iskoristiti.
U 3 sata ujutro, u nedjelju, dok spavate, naglo vas budi alarm tekstualne poruke: "kritična aplikacija ponovno ne odgovara". Što se događa? Gdje je uzrok "usporavanja"? Iz ovog izlaganja saznat ćete o servisima koje Microsoft Azure nudi klijentima za prikupljanje logova i, posebno, metrika vaših cloud radnih opterećenja. David će objasniti koje bi vas metrike trebale zanimati prilikom rada na cloud platformi i kako doći do njih. Saznat ćete o alatima otvorenog koda i izgradnji nadzornih panela, te ćete na kraju steći dovoljno znanja za izradu vlastitih panela.
I ako vas u 3 sata ujutro ponovno probudi poruka o padu kritične aplikacije, moći ćete brzo istražiti uzrok.
Dobar dan, danas ćemo razgovarati o metriku. Moje ime je David O’Brien, su-founder i vlasnik male australske konzultantske tvrtke Xirus. Hvala što ste došli ovdje provesti svoje vrijeme sa mnom. Dakle, zašto smo ovdje? Da razgovaramo o metriku, točnije, ispričat ću vam o njima, a prije nego što krenemo s nekim stvarima, započnimo s teorijom.
Ispričat ću vam što su metriku, što se može učiniti s njima, na što treba obratiti pozornost, kako prikupiti i uključiti prikupljanje metriku u Azure, i što je vizualizacija metriku. Pokazat ću vam kako te stvari izgledaju u oblaku Microsofta i kako raditi s tim oblakom.
Prije nego što krenemo, zamolit ću vas da podignete ruke oni koji koriste Microsoft Azure. A tko radi s AWS? Vidim, nekoliko. A s Googleom? ALI Cloud? Jedna osoba! Odlično. Dakle, što su metriku? Službena definicija Nacionalnog instituta za standarde i tehnologiju SAD-a glasi: „Metrika je standard mjerenja koji opisuje uvjete i pravila izvršenja mjerenja nekog svojstva i služi za razumijevanje rezultata mjerenja“. Što to znači?
Uzmimo kao primjer metriku za promjenu slobodnog prostora na disku virtualne mašine. Na primjer, dobivamo broj 90, a taj broj označava postotke, to jest, volumen slobodnog prostora na disku iznosi 90%. Napominjem da nije previše zanimljivo čitati opis definicije metriku koja traje 40 stranica u pdf formatu.
Međutim, metriku ne govore na koji način je dobiven rezultat mjerenja, ona samo pokazuje taj rezultat. Što radimo s metriku?
Prvo mjerimo vrijednost nečega da bismo kasnije iskoristili rezultat mjerenja.
Na primjer, saznali smo volumen slobodnog prostora na disku i sada ga možemo iskoristiti, koristiti tu memoriju itd. Nakon što dobijemo rezultat metrike, moramo ga interpretirati. Na primjer, metrika je dala rezultat 90. Moramo znati što znači taj broj: volumen slobodnog prostora ili volumen zauzetog prostora na disku u postotcima ili gigabajtima, latencija mreže od 90 ms itd., što znači da moramo protumačiti značenje tog metričkog podatka. Kako bi metrike uopće imale smisla, nakon interpretacije jednog metričkog podatka moramo osigurati prikupljanje više vrijednosti. To je vrlo važno, jer mnogi ljudi ne prepoznaju potrebu za prikupljanjem metrika. Microsoft je učinio proces dobivanja metrika vrlo jednostavnim, ali vi sami morate osigurati njihovo prikupljanje. Ove metrike se čuvaju samo 41 dan, a 42. dan nestaju. Stoga, ovisno o svojstvima vašeg vanjskog ili unutarnjeg hardvera, trebate se pobrinuti kako sačuvati metrike duže od 41 dan - u obliku logova, dnevnika itd. Dakle, nakon prikupljanja, trebate ih smjestiti negdje gdje će vam omogućiti da, ako je potrebno, prikažete cijelu statistiku promjene rezultata metrika. Smještanjem tamo, moći ćete učinkovito raditi s njima.
Tek nakon što dobijete vrijednosti metrika, interpretirate ih i prikupite, moći ćete izraditi SLA – ugovor o razini usluge. Ovaj SLA možda neće imati poseban značaj za vaše klijente, on je važniji za vaše kolege, menadžere, one koji osiguravaju rad sustava i brinu se o njegovoj funkcionalnosti. Metrika može mjeriti broj tiketa – primjerice, primate 5 tiketa dnevno, a u tom slučaju ona pokazuje brzinu reakcije na korisničke zahtjeve i brzinu rješavanja problema. Metrika ne bi trebala samo izvijestiti da se vaša web stranica učitava za 20 ms ili da je brzina odgovora 20 ms, metrika je više od samo jednog tehničkog pokazatelja.
Stoga je zadatak našeg razgovora predstaviti vam sveobuhvatan pregled suštine metrika. Metrika služi da, kada na nju pogledate, dobijete potpunu sliku procesa.
Kada dobijemo metrik, možemo sa 99% sigurnošću garantovati funkcionalnost sistema, jer to nije samo pregled log fajla u kojem piše da sistem radi. Garancija od 99% funkcionalnosti znači da, na primer, u 99% slučajeva API odgovara normalnom brzinom od 30 ms. To je ono što zanima vaše korisnike, kolege i menadžere. Mnogi naši klijenti prate logove web servera, a pritom ne primećuju nikakve greške u njima i misle da je sve u redu. Na primer, vide brzinu mreže od 200 mb/s i pomisle: „ok, sve je sjajno!“. Ali da bi postigli tih 200, korisnicima je potrebna brzina odgovora od 30 milisekundi, a to je upravo onaj podatak koji se ne meri i ne prikuplja u log fajlovima. U tom trenutku, korisnici se iznenade što se stranica veoma sporo učitava, jer, nedostajući potrebni metrik, ne znaju uzrok takvog ponašanja.
No, pošto imamo SLA koji garantuje 100% funkcionalnost, klijenti počinju da izražavaju nezadovoljstvo, jer je u stvarnosti veoma teško koristiti sajt. Zato, za kreiranje objektivnog SLA, potrebno je videti kompletnu sliku procesa, koja se stvara prikupljenim metrikama. Ovo je tema mog stalnog spora sa nekim provajderima, koji prilikom kreiranja SLA ne razumeju šta znači termin „uptime“ i u većini slučajeva ne objašnjavaju svojim klijentima kako funkcioniše njihov API.
Ako ste kreirali servis, na primer, API za treću stranu, morate shvatiti šta znači dobijena metrika od 39,5 – uspešan odgovor, odgovor sa brzinom od 20 ms ili sa brzinom od 5 ms. To ste vi ti koji treba da prilagodite njihov SLA svom vlastitom SLA, svojim sopstvenim metrikama.
Nakon što ste to sve razjasnili, možete krenuti u kreiranje sjajne platforme za nadgledanje. Recite, da li je neko već koristio aplikaciju za interaktivnu vizualizaciju Grafana? Sjajno! Ja sam veliki obožavalac ovog open source rešenja, jer je ovo stvar besplatna i jednostavna za korišćenje.
Ako još niste koristili Grafanu, objasnit ću vam kako se njome raditi. Oni koji su rođeni 80-ih i 90-ih vjerojatno se sjećaju brižnih medvjedića CareBears? Ne znam koliko su ti medvjedi bili popularni u Rusiji, ali u pogledu metrika trebali bismo djelovati kao ti 'brižni medvjedi'. Kao što sam rekao, potrebno vam je opsežno razumijevanje rada cijelog sustava, a to ne bi trebalo obuhvaćati samo vaš API, vašu web stranicu ili uslugu pokrenutu na virtualnoj mašini.
Trebate organizirati prikupljanje onih metrika koje najpotpunije odražavaju rad cijelog sustava. Većina vas je programera, stoga se vaš život neprestano mijenja, prilagođavajući se novim zahtjevima proizvoda, i baš kao što ste zabrinuti zbog procesa kodiranja, trebate se brinuti i za metrike. Morate znati na koji način svaka metrike utječe na svaki redak koda koji ste napisali. Na primjer, sljedeći tjedan započinjete novu marketinšku kampanju i očekujete da će vašu stranicu posjetiti veliki broj korisnika. Za analizu ovog događaja bit će vam potrebne metrike, a možda će vam trebati i cijela ploča za praćenje aktivnosti tih ljudi. Metrike će vam pomoći da razumijete koliko je vaša marketinška kampanja uspješna i kako zapravo radi. One će vam, na primjer, pomoći u razvoju učinkovitog CRM-a — sustava za upravljanje odnosima s kupcima.
Dakle, krenimo s našom uslugom u oblaku Azure. U njemu je vrlo lako pronaći i organizirati prikupljanje metrika, jer postoji Azure Monitor. Ovaj monitor centralizira upravljanje konfiguracijom vašeg sustava. Svaki element Azure-a koji želite primijeniti u svom sustavu ima mnoštvo mjernih podataka uključenih prema zadanim postavkama. Ovo je besplatna aplikacija koja radi odmah 'iz kutije' i ne zahtijeva nikakve prethodne postavke; ne morate ništa pisati ili 'priključivati' svom sustavu. Uvjereno ćemo se uvjeriti u to pregledom sljedeće demonstracije.
Osim toga, postoji mogućnost slanja tih metrike vanjskim aplikacijama, kao što su sustav za pohranu i analizu logova Splunk, cloud aplikacija za upravljanje logovima SumoLogic, alat za obradu logova ELK i IBM Radar. Međutim, ovdje postoje male razlike koje ovise o resursima koje koristite - virtualnim mašinama, mrežnim uslugama, Azure SQL bazama podataka, odnosno korištenje metrika razlikuje se ovisno o funkcijama vašeg radnog okruženja. Ne mogu reći da su te razlike ozbiljne, ali, nažalost, one ipak postoje i to treba uzeti u obzir. Uključivanje i slanje metrika može se odvijati na nekoliko načina: putem Portala, CLI/Power Shell-a ili pomoću ARM predložaka.
Prije nego što krenemo na prvu demonstraciju, odgovoriti ću na vaša pitanja. Ako nema pitanja, možemo početi. Na ekranu se prikazuje kako izgleda stranica Azure Monitor. Može li netko od vas reći da ovaj monitor ne funkcioniše?
Dakle, sada je sve u redu, vidite kako izgledaju servisi monitora. Mogu reći da je to izvrstan i vrlo jednostavan alat za svakodnevni rad. Uz njegovu pomoć moguće je pratiti aplikacije, mrežu i infrastrukturu. Nedavno je sučelje za praćenje unaprijeđeno, i ako su se ranije servisi nalazili na različitim mjestima, sada se sve informacije o servisima konsolidiraju na početnoj stranici monitora.
Tablica metrika je kartica putem HomeMonitorMetrics, na koju možete otići da biste vidjeli sve dostupne metrike i odabrali potrebne. No, ako trebate uključiti prikupljanje metrika, trebate koristiti put do direktorija HomeMonitorDiagnostic settings i provjeriti potvrdne okvire metrika Enabled/Disabled. Po zadanoj postavci gotovo sve metrike su uključene, ali ako trebate uključiti nešto dodatno, morat ćete promijeniti status dijagnostike s Disabled na Enabled.
Za to trebate kliknuti na red odabrane metrike i na otvorenom kartici uključiti način dijagnostike. Ako namjeravate analizirati odabranu metriku, nakon što pritisnete vezu Turn on diagnostic, trebate označiti potvrdni okvir Send to Log Analytics u prozoru koji se pojavi.
Log Analytics je sličan Splunk-u, ali je jeftiniji. Ova usluga omogućava prikupljanje svih vaših metrika, logova i svega što vam je potrebno, a sve to pohranjuje u radnom prostoru Log Analytics. Usluga koristi poseban jezik za obradu upita KQL – Kusto Query Language, kojeg ćemo obraditi u sljedećem demonstraciji. Za sada, napominjem da uz njegovu pomoć možete formirati upite za metrike, logove, termine, trendove, obrasce itd. i kreirati nadzorne ploče.
Dakle, označujemo checkbox Send to Log Analytics kao i checkboxe na ploči LOG: DataPlaneRequests, MongoRequests i QueryRuntimeStatistics, a ispod na ploči METRIC – checkbox Requests. Zatim dodajemo neko ime i spremamo postavke. U komandnoj liniji to predstavlja dvije linije koda. Usput, Azure Cloud sučelje u tom smislu podsjeća na Google, koji također omogućava korištenje komandne linije u vašem web pregledniku. AWS nema ništa slično, tako da je Azure u tom pogledu mnogo korisniji.
Na primjer, mogu pokrenuti demonstraciju putem web sučelja, ne koristeći nikakav kod na svom laptopu. Da bih to učinio, moram se autentificirati putem svog Azure računa. Nakon toga mogu koristiti, na primjer, terrafone, ako ga već koristite, pričekati da se poveže s uslugom i dobiti radno okruženje Linuxa koje Microsoft koristi po defaultu.
Zatim koristim Bash, ugrađen u Azure Cloud Shell. Vrlo korisna stvar je ugrađeni IDE u pregledniku, lakša verzija VS Code-a. Nakon toga mogu pristupiti svom predlošku metrika grešaka, izmijeniti ga i prilagoditi prema svojim potrebama.
Nakon što ste u ovom predlošku postavili prikupljanje metrika, možete ga primijeniti za kreiranje metrika za svoju cjelokupnu infrastrukturu. Kada primijenimo metrike, prikupimo i sačuvamo ih, bit će nam potrebno da ih vizualiziramo.
Azure Monitor se bavi samo metrikama i ne daje mogućnost dobivanja cjelokupne slike o stanju vašeg sustava. Možete koristiti niz drugih aplikacija koje su pokrenute izvan Azure okruženja. Dakle, ako trebate nadzirati sve procese, vizualizirajući sve prikupljene metrike na jednom mjestu, Azure Monitor za to neće biti odgovarajući.
Za rješavanje ovog zadatka, Microsoft nudi alat Power BI – sveobuhvatan softver za poslovnu analizu, koji uključuje vizualizaciju raznovrsnih podataka. Ovo je prilično skup proizvod, a cijena ovisi o potrebnom skupu funkcija. Po defaultu, nudi vam 48 vrsta obrađivanih podataka i povezan je s skladištima podataka SQL Azure, Azure Data Lake Storage, uslugama strojno učenje Azure i Azure Databricks. Koristeći skalabilnost, svake 30 minuta možete dobivati nove podatke. To može biti dovoljno za vaše potrebe ili nedovoljno ako vam je potrebna vizualizacija nadzora u stvarnom vremenu. U tom slučaju preporučuje se korištenje aplikacija kao što je spomenuta Grafana. Osim toga, u Microsoftovoj dokumentaciji opisana je mogućnost slanja metrike, logova i tablica događaja putem SIEM – alata u vizualizacijske sustave Splunk, SumoLogic, ELK i IBM radar.
23:40 min
Nastavak slijedi vrlo brzo...
Malo reklame 🙂
Hvala što ostajete s nama. Sviđa li vam se naše članke? Želite li vidjeti više zanimljivih materijala? Podržite nas narudžbom ili preporučite prijateljima, , jedinstveni analog entry-level servera koji smo razvili za vas: (dostupne opcije s RAID1 i RAID10, do 24 jezgre i do 40GB DDR4).
Dell R730xd je 2 puta jeftiniji u data centaru Equinix Tier IV u Amsterdamu? Samo kod nas u Nizozemskoj! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Pročitajte o tome
Izvor: habr.com
