David O'Brien lastatempe lanĉis sian propran firmaon, Xirus (https://xirus.com.au), fokusante al Microsoft Azure Stack-nubaj produktoj. Ili estas dizajnitaj por konstante konstrui kaj funkcii hibridajn aplikojn en datumcentroj, randlokoj, foraj oficejoj kaj la nubo.
David trejnas individuojn kaj kompaniojn pri ĉio Microsoft Azure kaj Azure DevOps (antaŭe VSTS) kaj ankoraŭ faras praktikan konsiladon kaj infrakodigon. Li estis Microsoft MVP (Microsoft Most Valuable Professional) Award-gajninto dum 5 jaroj kaj lastatempe ricevis la Azure MVP Award. Kiel kunorganizanto de la Melburna Microsoft Cloud kaj Datacenter Meetup, O'Brien regule parolas ĉe internaciaj konferencoj, kombinante sian intereson vojaĝi tra la mondo kun pasio por kunhavigi IT-rakontojn kun la komunumo. La blogo de David troviĝas ĉe , li ankaŭ publikigas sian retan trejnadon pri Pluralsight.
La parolado parolas pri la graveco de metriko por kompreni kio okazas en via medio kaj kiel via aplikaĵo funkcias. Microsoft Azure havas potencan kaj facilan manieron montri metrikojn por ĉiaj laborŝarĝoj, kaj la prelego klarigas kiel vi povas uzi ilin ĉiujn.
Je la 3-a a.m. dimanĉe, dum vi dormas, vi estas subite vekita de tekstmesaĝo: "superkritika programo ne respondas denove." Kio okazas? Kie kaj kio estas la kialo de la "bremsoj"? En ĉi tiu parolado, vi lernos pri la servoj, kiujn Microsoft Azure ofertas al klientoj por kolekti protokolojn kaj, precipe, metrikojn de viaj nubaj laborŝarĝoj. David diros al vi kiajn metrikojn vi devus interesiĝi kiam vi laboras en nuba platformo kaj kiel atingi ilin. Vi lernos pri malfermfontaj iloj kaj panelokonstruado, kaj finos kun sufiĉe da scio por krei viajn proprajn instrumentpanelojn.
Kaj se vi denove vekiĝas je la 3-a matene per mesaĝo, ke kritika aplikaĵo kraŝis, vi povas rapide eltrovi ĝian kaŭzon.
Bonan posttagmezon, hodiaŭ ni parolos pri metriko. Mia nomo estas David O'Brien, mi estas la kunfondinto kaj posedanto de malgranda aŭstralia konsultfirmao, Xirus. Dankon denove pro veni ĉi tien por pasigi vian tempon kun mi. Do kial ni estas ĉi tie? Por paroli pri metrikoj, aŭ pli ĝuste, mi rakontos al vi pri ili, kaj antaŭ ol fari ion ajn, ni komencu per la teorio.
Mi diros al vi, kio estas metrikoj, kion vi povas fari per ili, kion vi devas atenti, kiel kolekti kaj ebligi metrik-kolekton en Azure, kaj kio estas metrika bildigo. Mi montros al vi, kiel aspektas ĉi tiuj aferoj en la Microsoft-nubo kaj kiel labori kun ĉi tiu nubo.
Antaŭ ol ni komencu, mi petos man-levon de tiuj, kiuj uzas Microsoft Azure. Kiu laboras kun AWS? Mi vidas malmultajn. Kio pri Guglo? ALI Nubo? Unu viro! Bonege. Do kio estas metrikoj? La oficiala difino de la Usona Nacia Instituto pri Normoj kaj Teknologio estas: "Metriko estas mezurnormo, kiu priskribas la kondiĉojn kaj regulojn por mezuri posedaĵon kaj utilas por kompreni la mezurrezultojn." Kion ĝi signifas?
Ni prenu ekzemplon de metriko por ŝanĝi la liberan diskspacon de virtuala maŝino. Ekzemple, ni ricevas la nombron 90, kaj ĉi tiu nombro signifas procenton, tio estas, la kvanto de libera diskospaco estas 90%. Mi rimarkas, ke ne estas tre interese legi la priskribon de la difino de metriko, kiu prenas 40 paĝojn en formato pdf.
Tamen, la metriko ne diras kiel la mezurrezulto estis akirita, ĝi nur montras ĉi tiun rezulton. Kion ni faras kun metrikoj?
Unue, ni mezuras la valoron de io por tiam uzi la mezurrezulton.
Ekzemple, ni eksciis la kvanton da libera diskospaco kaj nun ni povas uzi ĝin, uzi ĉi tiun memoron, ktp. Post kiam ni ricevis la metrikan rezulton, ni devas interpreti ĝin. Ekzemple, la metriko redonis rezulton de 90. Ni devas scii, kion signifas ĉi tiu nombro: la kvanto de libera spaco aŭ la kvanto de uzata diskspaco en procentoj aŭ gigabajtoj, reto latenteco egala al 90 ms, ktp, tio estas , ni devas interpreti la signifon de la metrika valoro. Por ke metrikoj estu signifaj, post interpreti ununuran metrikan valoron, ni devas certigi, ke pluraj valoroj estas kolektitaj. Ĉi tio estas tre grava ĉar multaj homoj ne konscias pri la bezono kolekti metrikojn. Microsoft tre facilas kolekti metrikojn, sed dependas de vi certigi, ke ili estas kolektitaj. Ĉi tiuj metrikoj estas konservitaj dum nur 41 tagoj kaj malaperas en la 42-a tago. Tial, depende de la propraĵoj de via ekstera aŭ interna ekipaĵo, vi devas zorgi pri kiel konservi metrikojn dum pli ol 41 tagoj - en formo de ŝtipoj, ŝtipoj ktp. Tiel, post kolekto, vi devas meti ilin en iu loko, kiu ebligas al vi eltiri ĉiujn statistikojn de ŝanĝoj en metrikaj rezultoj se necese. Post kiam vi metos ilin tien, vi povas komenci labori kun ili efike.
Nur post kiam vi akiras la metrikojn, interpretas ilin kaj kolektas ilin, vi povas krei SLA - servo-nivela interkonsento. Ĉi tiu SLA eble ne multe gravas por viaj klientoj; ĝi estas pli grava por viaj kolegoj, administrantoj, tiuj, kiuj konservas la sistemon kaj zorgas pri ĝia funkcieco. La metriko povas mezuri la nombron da biletoj - ekzemple, vi ricevas 5 biletojn tage, kaj ĉi-kaze ĝi montras la rapidecon de respondo al uzantpetoj kaj la rapidecon de solvado de problemoj. Metriko ne nur devas diri, ke via retejo ŝarĝas en 20ms aŭ via respondrapideco estas 20ms, metriko estas pli ol nur unu teknika indikilo.
Tial, la tasko de nia konversacio estas prezenti al vi detalan bildon de la esenco de metrikoj. La metriko servas tiel, ke rigardante ĝin vi povas akiri kompletan bildon de la procezo.
Post kiam ni havas la metrikon, ni povas garantii 99%, ke la sistemo funkcias, ĉar ĝi ne nur rigardas protokoldosieron, kiu diras, ke la sistemo funkcias. Garantio pri 99% de funkciado signifas ke, ekzemple, 99% de la tempo la API respondas kun normala rapido de 30 ms. Ĝuste ĉi tio interesas viajn uzantojn, viajn kolegojn kaj administrantojn. Multaj el niaj klientoj kontrolas retservilojn protokolojn, sed ili ne rimarkas erarojn en ili kaj pensas, ke ĉio estas en ordo. Ekzemple, ili vidas retan rapidon de 200 Mb/s kaj pensas: "bone, ĉio estas bonega!" Sed por atingi ĉi tiujn 200, uzantoj bezonas respondan rapidon de 30 milisekundoj, kaj ĉi tio estas ĝuste la indikilo, kiu ne estas mezurita kaj ne kolektita en protokolaj dosieroj. Samtempe, uzantoj estas surprizitaj, ke la retejo ŝarĝas tre malrapide, ĉar, ne havante la necesajn metrikojn, ili ne scias la kialojn de ĉi tiu konduto.
Sed ĉar ni havas 100% uptime SLA, klientoj komencas plendi ĉar la retejo estas fakte tre malfacile uzebla. Tial, por krei objektivan SLA, necesas vidi la kompletan bildon de la procezo kreita de la kolektitaj metrikoj. Ĉi tio estas daŭra problemo, kiun mi havas kun iuj provizantoj, kiuj kreante SLA-ojn, ne havas ideon, kion signifas la termino "funkcitempo" kaj plejofte ne klarigas al siaj klientoj kiel funkcias ilia API.
Se vi kreis servon, ekzemple API por tria persono, vi devus kompreni kion signifas la rezulta metriko de 39,5 - respondo, sukcesa respondo, respondo je 20 ms rapido aŭ je 5 ms rapideco. Dependas de vi adapti ilian SLA al via propra SLA, al viaj propraj metrikoj.
Post kiam vi eltrovis ĉion ĉi, vi povas komenci krei mirindan panelon. Diru al mi, ĉu iu jam uzis la interagan bildigan aplikaĵon Grafana? Bonege! Mi estas granda ŝatanto de ĉi tiu malferma fonto ĉar ĉi tiu afero estas senpaga kaj facile uzebla.
Se vi ankoraŭ ne uzis Grafana, mi diros al vi kiel labori kun ĝi. Iu ajn naskita en la 80-aj kaj 90-aj jaroj verŝajne memoras CareBears? Mi ne scias kiom popularaj ĉi tiuj ursoj estis en Rusio, sed se temas pri metriko, ni devus esti la samaj "zorgaj ursoj". Kiel mi diris, vi bezonas grandan bildon pri kiel funkcias la tuta sistemo, kaj ĝi ne devus temi nur pri via API, via retejo aŭ la servo funkcianta en virtuala maŝino.
Vi devas organizi la kolekton de tiuj metrikoj, kiuj plej plene reflektas la funkciadon de la tuta sistemo. Plej multaj el vi estas programistoj, do via vivo konstante ŝanĝiĝas, adaptiĝante al novaj produktaj postuloj, kaj same kiel vi zorgas pri kodaj procezoj, vi devus zorgi pri metrikoj. Vi devas scii kiel la metriko rilatas al ĉiu linio de kodo, kiun vi skribas. Ekzemple, venontsemajne vi komencas novan merkatan kampanjon kaj atendas ke granda nombro da uzantoj vizitos vian retejon. Por analizi ĉi tiun eventon, vi bezonos metrikojn, kaj vi eble bezonos tutan panelon por spuri la agadon de ĉi tiuj homoj. Vi bezonos metrikojn por kompreni kiom sukcesa estas via merkatika kampanjo kaj kiel ĝi efektive funkcias. Ili helpos vin, ekzemple, evoluigi efikan CRM - klientrilatan administradsistemon.
Do ni komencu kun nia Azure-nuba servo. Estas tre facile trovi kaj organizi kalkulkolekton ĉar ĝi havas Azure Monitor. Ĉi tiu monitoro centralizas vian sisteman agordan administradon. Ĉiu el la Azure-elementoj, kiujn vi volas apliki al via sistemo, havas multajn metrikojn ebligitaj defaŭlte. Ĉi tio estas senpaga aplikaĵo, kiu funkcias tuj el la skatolo kaj ne postulas iujn ajn antaŭajn agordojn; vi ne bezonas skribi aŭ "ŝraŭbi" ion ajn al via sistemo. Ni kontrolos ĉi tion rigardante la sekvan pruvon.
Krome, estas eble sendi ĉi tiujn metrikojn al triapartaj aplikoj, kiel ekzemple la Splunk-protokolo-stokado kaj analizsistemo, la nub-bazita tagalo-administra aplikaĵo SumoLogic, la ELK-protiga ilo, kaj IBM Radar. Vere, estas etaj diferencoj, kiuj dependas de la rimedoj, kiujn vi uzas - virtuala maŝino, retservoj, Azure SQL-datumbazoj, tio estas, la uzo de metrikoj diferencas laŭ la funkcioj de via labormedio. Mi ne diros, ke ĉi tiuj diferencoj estas gravaj, sed, bedaŭrinde, ili ankoraŭ ĉeestas, kaj tion oni devas konsideri. Ebligi kaj sendi metrikojn eblas laŭ pluraj manieroj: per Portalo, CLI/Power Shell, aŭ uzante ARM-ŝablonojn.
Antaŭ ol mi komencos mian unuan demonstraĵon, mi respondos ĉiujn demandojn, kiujn vi povas havi. Se ne estas demandoj, ni komencu. La ekrano montras kiel aspektas la paĝo de Azure Monitor. Ĉu iu el vi povas diri, ke ĉi tiu monitoro ne funkcias?
Do nun ĉio estas en ordo, vi povas vidi kiel aspektas la monitoraj servoj. Mi povas diri, ke ĉi tio estas bonega kaj tre simpla ilo por ĉiutaga laboro. Ĝi povas esti uzata por monitori aplikojn, retojn kaj infrastrukturon. Lastatempe, la monitora interfaco estis plibonigita, kaj se antaŭe servoj troviĝis en malsamaj lokoj, nun ĉiuj informoj pri servoj estas solidigitaj sur la hejmpaĝo de la monitoro.
La tabelo de metrikoj estas langeto laŭ la vojo HomeMonitorMetrics, al kiu vi povas iri por vidi ĉiujn disponeblajn metrikojn kaj elekti tiujn, kiujn vi bezonas. Sed se vi bezonas ebligi la kolekton de metrikoj, vi devas uzi la dosierujon de agordoj de HomeMonitorDiagnostic kaj kontroli la markobutonojn de Ebligitaj/Malŝaltitaj metrikoj. Defaŭlte, preskaŭ ĉiuj metrikoj estas ebligitaj, sed se vi bezonas ebligi ion plian, vi devos ŝanĝi la diagnozan staton de Malŝaltita al Ebligita.
Por fari tion, alklaku la linion de la elektita metriko kaj sur la langeto kiu malfermiĝas, ebligu diagnozan reĝimon. Se vi analizos la elektitan metrikon, tiam post klako sur la ligilon Ŝalti diagnozon, vi devas kontroli la markobutonon Sendi al Log Analytics en la fenestro, kiu aperas.
Log Analytics estas iom simila al Splunk, sed kostas malpli. Ĉi tiu servo permesas vin kolekti ĉiujn viajn metrikojn, protokolojn kaj ĉion alian, kion vi bezonas, kaj meti ilin en la laborspacon de Log Analytics. La servo uzas specialan KQL-pretigan lingvon - Kusto Quarry Language, ni rigardos ĝian laboron en la venonta demo. Nuntempe mi rimarkos, ke per ĝia helpo vi povas krei demandojn pri metrikoj, protokoloj, terminoj, tendencoj, ŝablonoj ktp. kaj krei panelojn.
Do, ni kontrolas la markobutonojn Sendi al Log Analytics kaj la markobutonojn de la panelo LOG: DataPlaneRequests, MongoRequests kaj QueryRuntimeStatistics, kaj sube sur la METRIC-panelo - la markobutono Petoj. Poste ni atribuas nomon kaj konservas la agordojn. Sur la komandlinio, ĉi tio reprezentas du liniojn de kodo. Cetere, la ŝelo de Azure Cloud ĉi-sence similas al Guglo, kiu ankaŭ ebligas al vi uzi la komandlinion en via retumilo. AWS havas nenion tian, do Azure estas multe pli oportuna ĉi-sence.
Ekzemple, mi povas ruli demonstron per la retinterfaco sen uzi ajnan kodon en mia tekkomputilo. Por fari tion, mi devas aŭtentikiĝi kun mia Azure-konto. Tiam vi povas uzi, ekzemple, terrafone, se vi jam uzas ĝin, atendu la konekton al la servo kaj akiri la Linuksan labormedion, kiun Microsoft uzas defaŭlte.
Poste, mi uzas Bash, enkonstruitan en la Azure Cloud Shell. Tre utila afero estas la IDE enkonstruita en la retumilo, malpeza versio de VS Code. Poste, mi povas eniri mian ŝablonon pri eraraj metrikoj, redakti ĝin kaj agordi ĝin laŭ miaj bezonoj.
Post kiam vi starigis metrikkolekton en ĉi tiu ŝablono, vi povas uzi ĝin por krei metrikojn por via tuta infrastrukturo. Post kiam ni aplikis la metrikojn, kolektis ilin kaj konservis ilin, ni devos bildigi ilin.
Azure Monitor nur traktas metrikojn kaj ne provizas ĝeneralan bildon pri la sano de via sistemo. Vi eble havas kelkajn aliajn aplikojn kurantajn ekster la Azure-medio. Do se vi bezonas monitori ĉiujn procezojn, bildigante ĉiujn kolektitajn metrikojn en unu loko, tiam Azure Monitor ne taŭgas por ĉi tio.
Por solvi ĉi tiun problemon, Mikrosofto ofertas la ilon Power BI, ampleksan programaron por komerca analizo, kiu inkluzivas bildigon de diversaj datumoj. Ĉi tio estas sufiĉe multekosta produkto, kies kosto dependas de la aro de funkcioj, kiujn vi bezonas. Defaŭlte, ĝi ofertas al vi 48 specojn de datumoj por prilabori kaj estas ligita al Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services kaj Azure Databricks. Uzante skaleblon, vi povas ricevi novajn datumojn ĉiujn 30 minutojn. Ĉi tio eble aŭ eble ne sufiĉas por viaj bezonoj, se vi bezonas realtempan monitoran vidadon. En ĉi tiu kazo, oni rekomendas uzi aplikojn kiel la Grafana, kiun mi menciis. Krome, Mikrosofta dokumentaro priskribas la kapablon sendi metrikojn, tagalojn kaj okazaĵtabelojn uzante SIEM-iloj al bildigaj sistemoj Splunk, SumoLogic, ELK kaj IBM-radaro.
23:40 min
Daŭrigota tre baldaŭ...
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com