David O’Brien (Xirus): Metrika! Metrika! Metrika! Osa 1

Hiljuti avas David O’Brien oma ettevõtte Xirus (https://xirus.com.au), keskendudes Microsoft Azure Stack'i pilveproduktidele. Need on mõeldud hübriidrakenduste järjepidevaks väljatöötamiseks ja kasutamiseks andmekeskustes, servas asuvates asukohtades, eemalsete büroodes ja pilves.

David õpetab inimesi ja ettevõtteid kõik, mis on seotud Microsoft Azure ja Azure DevOps'iga (endise VSTS-iga), ning jätkab praktilist nõustamist ja infrastruktuuri kodeerimist. Ta on juba viie aasta jooksul saanud Microsoft MVP (Microsofti kõige väärtuslikum professionaal) auhinna ning hiljuti sai ta MVP Azure'i auhinna. Melbourne Microsoft Cloud'i ja Datacentre Meetup'i kaasorganisaatorina esineb O’Brien regulaarselt rahvusvahelistel konverentsidel, kombineerides oma huvi maailmas reisimise ja kirge IT-lugude jagamise vastu kogukonnaga. David'i blogi on aadressil david-obrien.net, ta avaldab ka oma veebikoolitusi Pluralsight'is.

Ettekandes arutatakse mõõdikute tähtsust, et mõista, mis teie keskkonnas toimub ja kuidas teie rakendus töötab. Microsoft Azure’il on võimas ja lihtne viis kõigi töökoormuste mõõdikute kuvamiseks ning ettekandes räägitakse, kuidas neid kõiki kasutusele võtta.

Kell 3 öösel, pühapäeval, kui magate, äratab teid äkitselt tekstisõnum: "kriitiline rakendus ei reageeri jälle". Mis toimub? Kus ja milles on 'pidurite' põhjus? Sellest ettekandest saate teada teenustest, mida Microsoft Azure pakub klientidele logide kogumiseks ja eelkõige teie pilve töökoormuste mõõdikute jaoks. David räägib, millised mõõdikud peaksid teid huvitama pilveplatvormil töötades ja kuidas neid leida. Te tutvute avatud lähtekoodiga tööriistade ja juhtpaneelide loomisega ning saate piisavalt teadmisi, et luua oma paneele.

Ja kui teid kell 3 öösel uuesti äratab sõnum kriitilise rakenduse kokkuvarisemisest, saate kiiresti aru, mis selle põhjus on.

Tere hommikust, täna räägime mõõdikutest. Minu nimi on David O'Brien, olen väikese Austraalia konsultatsiooniettevõtte Xirus kaasasutaja ja omanik. Täname, et tulite siia koos minuga aega veetma. Nii et, miks me siin oleme? Et rääkida mõõdikutest, täpsemalt räägin ma teile neist ja enne kui midagi teeme, alustame teooriast.

Räägin, mis on mõõdikud, mida nendega teha saab, millele tähelepanu pöörata, kuidas mõõdikute kogumist Azure’is korraldada ja mis on mõõdikute visualiseerimine. Näitan teile, kuidas need asjad Microsofti pilves välja näevad ja kuidas selle pilvega töötada.

Enne alustamist palun tõstke käed need, kes kasutavad Microsoft Azure't. Kes töötab AWS-iga? Näen, et vaid mõni. Aga Google'i? ALI Cloud? Üks inimene! Suurepärane. Nii et, mis on mõõdikud? Ameerika Ühendriikide riiklike standardite ja tehnoloogia institudi ametlik määratlus on järgmine: "Mõõdik on mõõtmistandardi kaudu kirjeldatud tingimuste ja reeglite kogum, mille eesmärk on mõista mõõtmise tulemusi." Mida see tähendab?

Vaatame näiteks mõõdikut virtuaalmasina vaba ketta ruumi muutuse jaoks. Näiteks, kui meil antakse number 90, siis see number tähendab protsente, et vaba ketta ruumi maht on 90%. Tahan märkida, et määratlemise kirjelduse lugemine, mis hõivab 40 lehekülge pdf formaadis, ei ole just väga huvitav.

Siiski ei ütle mõõdik, kuidas mõõtmise tulemus saadakse, vaid näitab lihtsalt seda tulemust. Mida me siis mõõdikute kohta teeme?

Esiteks mõõdame millegi väärtust, et seejärel tulemusi kasutada.

Näiteks saime teada, kui palju vaba kettaruumi on, ja nüüd saame seda kasutada, et seda mälu kasutada jne. Pärast mõõdikute tulemuste saamist peame neid tõlgendama. Näiteks mõõdik näitas tulemust 90. Me peame teadma, mida see number tähendab: vaba kettaruumi maht või ketta kasutatud ruumi maht protsentides või gigabaitides, võrgulaatents 90 ms jne, seega peame mõistma mõõdiku väärtuse tähendust. Selleks, et mõõdikud omaksid üldse tähendust, peame pärast ühe mõõdiku väärtuse tõlgendamist tagama, et kogume mitmeid väärtusi. See on väga oluline, kuna paljud inimesed ei saa aru mõõdikute kogumise vajadusest. Microsoft on mõõdikute hankimise protsessi teinud väga lihtsaks, kuid te peate ise nende kogumise tagama. Need mõõdikud salvestatakse vaid 41 päevaks ja 42. päeval kaovad nad. Seetõttu, sõltuvalt teie välistest või sisemistest seadmetest, peate hoolitsema selle eest, kuidas hoida mõõdikuid kauem kui 41 päeva — logide, päevikute jne kujul. Seega, pärast kogumist peaksite nende andmeid paigutama kuhugi, mis võimaldab vajaliku korral kogu mõõdikute tulemuste statistikat ümber vaadata. Paigaldades need sinna, saate nendega tõhusalt töötada.

Ainult pärast mõõdiku väärtuste saamist, nende tõlgendamist ja kogumist suudate luua SLA - teenuse taseme kokkuleppe. See SLA ei pruugi teie klientide jaoks erilist tähendust omada, see on rohkem oluline teie kolleegide, juhtide ja süsteemi töötamise tagamise eest vastutavate inimeste jaoks. Mõõdik võib mõõta piletite arvu — näiteks saate 5 piletit päevas, ja sel juhul näitab see kasutajate päringutele vastamise kiirus ja probleemide lahendamise kiirus. Mõõdik ei tohiks lihtsalt teatada, et teie veebisait laadib 20 ms-ga või vastamise kiirus on 20 ms, mõõdik on rohkem kui lihtsalt üks tehniline näitaja.

Seega on meie vestluse eesmärk esitada teile põhjalik ülevaade mõõdikute olemusest. Mõõdikud on sellised, et vaadates neid, saate te täieliku ülevaate protsessist.

Kui me oleme mõõdiku saanud, saame 99% tõenäosusega garanteerida, et süsteem töötab, kuna see ei tähenda lihtsalt logifaili vaatamist, kus on märgitud, et süsteem töötab. 99% töökindluse garantii tähendab, et näiteks 99% juhtudel vastab API normaalsete 30 ms kiiruseni. Just seda huvitab teie kasutajaid, teie kolleege ja juhtmeid. Paljud meie kliendid jälgivad veebiserverite logisid, kuid nad ei märkagi seal ühtegi viga ja arvavad, et kõik on hästi. Näiteks nad näevad võrgu kiirusnäitaja 200 mb/s ja arvavad: "okei, kõik on suurepärane!". Kuid nende 200 saavutamiseks on kasutajate jaoks vajalik vastamiskiirus 30 millisekundit, ja see on just see näitaja, mida ei mõõdeta ja ei koguta logifailidesse. Sellegipoolest kummardavad kasutajad, et veebileht laadib väga aeglaselt, sest neil ei ole vajalikku mõõdikut, mis näitaks sellise käitumise põhjust.

Kuid kuna meil on SLA, mis garanteerib 100% töökindluse, hakkavad kliendid hakkama protestima, kuna tegelikult on veebisaidi kasutamine väga keeruline. Seetõttu on objektiivse SLA loomise jaoks oluline näha kogu protsessi, mille genereerivad kogutud mõõdikud. See on minu pidev vaidlus mitmete teenusepakkujatega, kes SLA loomise käigus ei mõista, mida mõisted nagu "uptime" tähendavad, ja enamikul juhtudel ei selgita nad oma klientidele, kuidas nende API töötab.

Kui olete loonud teenuse, näiteks API kolmandate isikute jaoks, peate mõistma, mida pideva mõõdiku väärtus 39,5 — vastus, edukas vastus, vastus kiirusel 20 ms või 5 ms. Just teie peate kohandama nende SLA omaenda SLA-ga, omaenda mõõdikutega.

Pärast kõike seda võime hakata looma suurepärast juhtpaneeli. Öelge, kas keegi on juba kasutanud interaktiivse visualiseerimise rakendust Grafana? Suurepärane! Ma olen suur selle avatud lähtekoodiga süsteemi fänn, kuna see on tasuta ja seda on lihtne kasutada.

Kui te pole veel Grafanat kasutanud, selgitan, kuidas sellega töötada. Need, kes sündisid 80-90ndatel, tõenäoliselt mäletavad hoolivaid kaisukaisusid CareBears? Ma ei tea, kui populaarsed need karud Venemaal olid, aga meetrikate osas peaksime olema samasugused "hästitöötavad karud". Nagu ma ütlesin, vajate selget ülevaadet kogu süsteemi toimimisest, mis ei tohiks piirduda ainult teie API, teie veebisaidi või virtuaalmasinal töötava teenusega.

Te peaksite korraldama nende meetrikate kogumise, mis kõige paremini kajastavad kogu süsteemi toimimist. Enamus teist on tarkvaraarendajad, seega muutub teie elu pidevalt, kohandudes uute tootega seotud nõudmistega. Nii nagu olete mures kodeerimisprotsesside pärast, peaksite muretseda ka meetrikate pärast. Te peate teadma, kuidas meetrika on seotud iga teie kirjutatud koodireaga. Näiteks järgmisel nädalal alustate uut turunduskampaaniat ja ootate, et teie veebisaidi külastab suur hulk kasutajaid. Selle sündmuse analüüsimiseks vajate meetrikate kogumit, võib-olla vajate isegi eraldi paneeli nende inimeste tegevuse jälgimiseks. Metrikad on vajalikud, et mõista, kui edukas ja tõeliselt efektiivne teie turunduskampaania on. Need aitavad teil näiteks arendada tõhusat CRM-i — kliendihaldussüsteemi.

Nii et alustame meie pilveteenusest Azure. Siin on väga lihtne leida ja korraldada meetrikate kogumist, kuna olemas on Azure Monitor. See monitor keskendab teie süsteemi konfiguratsiooni haldamisele. Iga Azure'i element, mida soovite oma süsteemis kasutada, omab palju vaikimisi lubatud meetrikate komplekte. See on tasuta rakendus, mis töötab otse "karbist välja" ja ei vaja mingeid eelhäälestusi, te ei pea midagi kirjutama ega enda süsteemile "kinnitama". Me veendume selles, vaadates järgmist demot.

Lisaks on võimalus saata neid meetrikate kolmandate osapoolte rakendustesse, nagu logide salvestamise ja analüüsi süsteem Splunk, logihaldusrakendus SumoLogic, logide töötlemise tööriist ELK, IBM Radar. Tõsi, siin on väikeseid erinevusi, mis sõltuvad teie kasutatavatest ressurssidest — virtuaalmasinatest, võrguteenustest, Azure SQL andmebaasidest, s.o meetrikate kasutamine sõltub teie töö keskkonna funktsioonidest. Ei saa öelda, et need erinevused on tõsised, kuid need siiski eksisteerivad ja seda tuleks arvesse võtta. Metrikate lubamine ja edastamine on võimalik mitmeti: läbi Portali, CLI / Power Shell või ARM-mallide abil.

Enne kui läheme esimese demonstreerimise juurde, vastan teie küsimustele. Kui küsimusi pole, siis alustame. Ekraanil on näha, milline on Azure Monitori leht. Kas keegi teist võib öelda, et see monitor ei tööta?

Nii et nüüd on kõik korras, näete, kuidas monitori teenused välja näevad. Võin öelda, et see on suurepärane ja väga lihtne tööriist igapäevaseks kasutamiseks. Selle abil on võimalik jälgida rakendusi, võrke ja infrastruktuuri. Hiljuti on monitorimise liidese kasutusmudelit parandatud, ning kui varem olid teenused erinevates kohtades, siis nüüd koondatakse kogu teave teenuste kohta monitooringuabeles kodu lehele.

Metrikate tabel on vahekaart, kuhu pääseb HomeMonitorMetrics tee kaudu, et näha kõiki olemasolevaid meetrike ja valida vajalikud. Kuid kui tahate lubada meetrikate kogumist, tuleb kasutada katalooge HomeMonitorDiagnostic settings ja kontrollida meetrikate Enabled / Disabled kastikesi. Peaaegu kõik meetrikad on vaikimisi lubatud, kuid kui vajalik on lisada midagi, peate muutma diagnostika staatust Disabled'ist Enabled'iks.

Selleks tuleb klõpsata valitud meetrika real ning avaneval vahekaardil lubada diagnostikarežiim. Kui plaanite analüüsida valitud meetrikat, siis vajutage lingile Turn on diagnostic ja märkige ilmuvast aknast kastikesse Send to Log Analytics.

Log Analytics on veidi sarnane Splunk'iga, aga odavam. See teenus võimaldab koguda kõiki teie meetrikasid, logisid ja kõike, mida vajate, ning salvestada need Log Analytics tööruumi. Teenus kasutab spetsiaalset päringute töötlemise keelt KQL — Kusto Quarry Language, mille tööd vaatame järgmisel demol. Hetkel tahan märkida, et selle abil saate koostada päringud meetrikate, logide, terminite, suundumuste, mallide jne kohta ja luua monitooringupaneele.

Nii, me märkime ära Send to Log Analytics ruudustiku ja LOG paneeli ruudustikud: DataPlaneRequests, MongoRequests ja QueryRuntimeStatistics, ning allpool METRIC paneelil ruudustiku Requests. Seejärel anname sellele mingisuguse nime ja salvestame seadistused. Käskude real on see kaks rida koodist. Muide, Azure Cloud shell meenutab selles mõttes Google'it, mis võimaldab samuti kasutada käsurida teie veebibrauseris. AWS-il ei ole midagi sellist, nii et Azure on selles osas palju mugavam.

Näiteks, ma saan demot käivitada veebiliidese kaudu, ilma et peaksin oma sülearvutis mingit koodi kasutama. Selleks pean ma autentima end oma Azure kontoga. Edasi saab kasutada näiteks terrafone, kui te seda juba kasutate, oodata teenusega ühenduse loomist ja saada töötav Linux keskkond, mida Microsoft kasutab vaikimisi.

Seejärel kasutan Bash'i, mis on integreeritud Azure Cloud Shell'i. Väga kasulik asi on brauserisse sisseehitatud IDE, kergem versioon VS Code'ist. Edasi saan minna oma veamõõtmete šablooni, seda muuta ja kohandada vastavalt oma vajadustele.

Kui olete selle šablooni mõõtmete kogumise seadistanud, saate selle rakendada kõigi oma infrastruktuuri mõõtmete loomiseks. Pärast seda, kui oleme mõõtmed rakendanud, kogunud ja salvestanud, peame need visualiseerima.

Azure Monitor tegeleb ainult mõõtmetega ja ei anna võimalust teie süsteemi üldise seisundi ülevaade saamiseks. Te võite kasutada mitmeid teisi rakendusi, mis töötavad väljaspool Azure keskkonda. Nii et kui peate jälgima kõiki protsesse, visualiseerides kõik kogutud mõõtmed ühes kohas, ei sobi Azure Monitor selleks.

Selle probleemi lahendamiseks pakub Microsoft Power BI tööriista – põhjalikku tarkvara ärianalüüsiks, mis sisaldab väga erinevate andmete visualiseerimist. See on üsna kallis toode, mille hind sõltub vajalikest funktsioonide komplektidest. Vaikimisi pakub see teile 48 tüüpi töödeldavaid andmeid ning on seotud SQL Azure andmehoidlate, Azure Data Lake Storage, Azure masinõppe teenuste ja Azure Databricks'iga. Kasutades skaleeritavust, saate iga 30 minuti järel uusi andmeid. Seda võib olla piisavalt teie vajaduste jaoks või mitte piisavalt, kui vajate reaalajas jälgimise visualiseerimist. Sellisel juhul soovitatakse kasutada selliseid rakendusi nagu minu poolt mainitud Grafana. Lisaks on Microsofti dokumentatsioonis kirjeldatud võimalust saatma mõõtmeid, logisid ja sündmuste tabeleid SIEM – Splunk'i, SumoLogic'i, ELK ja IBM radar'i visualiseerimise süsteemide tööriistade kaudu.

23:40 min

Peagi on see tulemas…

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com