David O'Brien het onlangs sy eie maatskappy, Xirus (https://xirus.com.au), bekend gestel wat op Microsoft Azure Stack-wolkprodukte fokus. Hulle is ontwerp om konsekwent hibriede toepassings te bou en uit te voer in datasentrums, randliggings, afgeleë kantore en die wolk.
David lei individue en maatskappye op oor alles wat Microsoft Azure en Azure DevOps (voorheen VSTS) betref en doen steeds praktiese konsultasie en infrakodering. Hy is vir 5 jaar 'n Microsoft MVP (Microsoft Most Valuable Professional)-toekenningwenner en het onlangs die Azure MVP-toekenning ontvang. As mede-organiseerder van die Melbourne Microsoft Cloud and Datacentre Meetup, praat O'Brien gereeld by internasionale konferensies, en kombineer sy belangstelling om die wêreld te reis met 'n passie om IT-stories met die gemeenskap te deel. David se blog is geleë by , publiseer hy ook sy aanlyn opleiding op Pluralsight.
Die praatjie praat oor die belangrikheid van maatstawwe om te verstaan wat in jou omgewing gebeur en hoe jou toepassing presteer. Microsoft Azure het 'n kragtige en maklike manier om statistieke vir alle soorte werkladings te vertoon, en die lesing verduidelik hoe jy hulle almal kan gebruik.
Om 3:XNUMX op 'n Sondag, terwyl jy slaap, word jy skielik wakker gemaak deur 'n SMS: "superkritiese app reageer nie weer nie." Wat gaan aan? Waar en wat is die rede vir die “remme”? In hierdie praatjie sal jy leer oor die dienste wat Microsoft Azure kliënte bied om logs en veral statistieke van jou wolkwerkladings in te samel. David sal jou vertel in watter maatstawwe jy moet belangstel wanneer jy op 'n wolkplatform werk en hoe om daarby uit te kom. Jy sal leer oor oopbronnutsgoed en dashboardbou, en uiteindelik genoeg kennis hê om jou eie dashboards te skep.
En as jy om 3:XNUMX weer wakker gemaak word deur 'n boodskap dat 'n kritieke toepassing neergestort het, kan jy vinnig die oorsaak daarvan uitvind.
Goeiemiddag, vandag gesels ons oor metrieke. My naam is David O'Brien, ek is die medestigter en eienaar van 'n klein Australiese konsultasiemaatskappy, Xirus. Weereens dankie dat jy hier gekom het om jou tyd saam met my deur te bring. So hoekom is ons hier? Om oor metrieke te praat, of liewer, ek sal jou daarvan vertel, en voordat ons enige dinge doen, laat ons met die teorie begin.
Ek sal jou vertel wat metrieke is, wat jy daarmee kan doen, waaraan jy moet aandag gee, hoe om metriekeversameling in Azure in te samel en te aktiveer, en wat metriekevisualisering is. Ek sal jou wys hoe hierdie dinge in die Microsoft-wolk lyk en hoe om met hierdie wolk te werk.
Voordat ons begin, sal ek 'n opsteek van hande vra van diegene wat Microsoft Azure gebruik. Wie werk met AWS? Ek sien min. Wat van Google? ALI Wolk? Een man! Groot. So, wat is metrieke? Die amptelike definisie van die Amerikaanse Nasionale Instituut vir Standaarde en Tegnologie is: "'n Metriek is 'n meetstandaard wat die voorwaardes en reëls vir die meting van 'n eiendom beskryf en dien om die metingsresultate te verstaan." Wat beteken dit?
Kom ons neem 'n voorbeeld van 'n maatstaf vir die verandering van die vrye skyfspasie van 'n virtuele masjien. Ons kry byvoorbeeld die getal 90, en hierdie getal beteken persentasie, dit wil sê die hoeveelheid vrye skyfspasie is 90%. Ek merk op dat dit nie baie interessant is om die beskrywing van die definisie van metrieke te lees nie, wat 40 bladsye in pdf-formaat neem.
Die metriek sê egter nie hoe die meetresultaat verkry is nie, dit wys slegs hierdie resultaat. Wat doen ons met metrieke?
Eerstens meet ons die waarde van iets om dan die meetresultaat te gebruik.
Ons het byvoorbeeld die hoeveelheid vrye skyfspasie uitgevind en nou kan ons dit gebruik, hierdie geheue gebruik, ens. Sodra ons die metrieke resultaat ontvang het, moet ons dit interpreteer. Byvoorbeeld, die metrieke het 'n resultaat van 90 opgelewer. Ons moet weet wat hierdie getal beteken: die hoeveelheid vrye spasie of die hoeveelheid gebruikte skyfspasie in persent of gigagrepe, netwerkvertraging gelyk aan 90 ms, ensovoorts, dit is , moet ons die betekenis van die metrieke waarde interpreteer. Om metrieke enigsins betekenisvol te wees, moet ons, nadat ons 'n enkele metrieke waarde geïnterpreteer het, verseker dat veelvuldige waardes versamel word. Dit is baie belangrik omdat baie mense nie bewus is van die behoefte om maatstawwe in te samel nie. Microsoft het dit baie maklik gemaak om metrieke in te samel, maar dit is aan jou om te verseker dat dit ingesamel word. Hierdie maatstawwe word vir slegs 41 dae gestoor en verdwyn op die 42ste dag. Daarom, afhangende van die eienskappe van jou eksterne of interne toerusting, moet jy sorg vir hoe om metrieke vir meer as 41 dae te stoor - in die vorm van logs, logs, ens. Dus, na versameling, moet jy dit op 'n plek plaas wat jou toelaat om al die statistieke van veranderinge in metrieke resultate op te tel indien nodig. Sodra jy hulle daar geplaas het, kan jy effektief met hulle begin werk.
Eers nadat jy die maatstawwe verkry, dit geïnterpreteer en versamel het, kan jy 'n SLA - diensvlakooreenkoms skep. Hierdie SLA is dalk nie van groot belang vir jou kliënte nie; dit is belangriker vir jou kollegas, bestuurders, diegene wat die stelsel onderhou en bekommerd is oor die funksionaliteit daarvan. Die maatstaf kan die aantal kaartjies meet – jy ontvang byvoorbeeld 5 kaartjies per dag, en in hierdie geval wys dit die spoed van reaksie op gebruikersversoeke en die spoed van probleemoplossing. 'n Metriek moet nie net sê dat jou werf binne 20ms laai of jou reaksiespoed 20ms is nie, 'n maatstaf is meer as net een tegniese aanwyser.
Daarom is die taak van ons gesprek om u 'n gedetailleerde beeld van die essensie van metrieke te gee. Die metrieke dien sodat deur daarna te kyk jy 'n volledige prentjie van die proses kan kry.
Sodra ons die metrieke het, kan ons 99% waarborg dat die stelsel werk, want dit kyk nie net na 'n loglêer wat sê die stelsel werk nie. 'n 99% uptydwaarborg beteken dat die API byvoorbeeld 99% van die tyd teen 'n normale spoed van 30 ms reageer. Dit is presies wat jou gebruikers, jou kollegas en bestuurders interesseer. Baie van ons kliënte monitor webbedienerlogs, maar hulle merk geen foute daarin op nie en dink dat alles in orde is. Hulle sien byvoorbeeld 'n netwerkspoed van 200 Mb/s en dink: "ok, alles is wonderlik!" Maar om hierdie 200 te bereik, benodig gebruikers 'n reaksiespoed van 30 millisekondes, en dit is juis die aanwyser wat nie gemeet word nie en nie in loglêers versamel word nie. Terselfdertyd is gebruikers verbaas dat die webwerf baie stadig laai, omdat hulle nie die nodige statistieke het nie, weet nie die redes vir hierdie gedrag nie.
Maar aangesien ons 'n 100% uptyd SLA het, begin kliënte kla omdat die webwerf eintlik baie moeilik is om te gebruik. Daarom, om 'n objektiewe SLA te skep, is dit nodig om die volledige prentjie te sien van die proses wat deur die versamelde statistieke geskep word. Dit is 'n voortdurende probleem wat ek het met sommige verskaffers wat, wanneer hulle SLA's skep, geen idee het wat die term "uptyd" beteken nie en in die meeste gevalle nie aan hul kliënte verduidelik hoe hul API werk nie.
As jy 'n diens geskep het, byvoorbeeld 'n API vir 'n derde persoon, moet jy verstaan wat die gevolglike maatstaf van 39,5 beteken - reaksie, suksesvolle reaksie, reaksie teen 20 ms spoed of teen 5 ms spoed. Dit is aan jou om hul SLA aan te pas by jou eie SLA, by jou eie maatstawwe.
Sodra jy dit alles uitgepluis het, kan jy begin om 'n pragtige dashboard te skep. Sê vir my, het iemand al die Grafana-interaktiewe visualisering-toepassing gebruik? Puik! Ek is 'n groot aanhanger van hierdie oopbron, want hierdie ding is gratis en maklik om te gebruik.
As jy nog nie Grafana gebruik het nie, sal ek jou vertel hoe om daarmee te werk. Enigiemand wat in die 80's en 90's gebore is, onthou seker CareBears? Ek weet nie hoe gewild hierdie bere in Rusland was nie, maar as dit by statistieke kom, moet ons dieselfde "sorgbere" wees. Soos ek gesê het, het jy 'n groot prentjie nodig van hoe die hele stelsel werk, en dit moet nie net gaan oor jou API, jou webwerf of die diens wat in 'n virtuele masjien loop nie.
Jy moet die versameling van daardie maatstawwe organiseer wat die werking van die hele stelsel die meeste weerspieël. Die meeste van julle is sagteware-ontwikkelaars, so jou lewe verander voortdurend, pas by nuwe produkvereistes aan, en net soos jy bekommerd is oor koderingsprosesse, moet jy bekommerd wees oor metrieke. Jy moet weet hoe die metriek verband hou met elke reël kode wat jy skryf. Byvoorbeeld, volgende week begin jy 'n nuwe bemarkingsveldtog en verwag 'n groot aantal gebruikers om jou werf te besoek. Om hierdie gebeurtenis te ontleed, sal jy statistieke nodig hê, en jy sal dalk 'n hele kontroleskerm nodig hê om die aktiwiteit van hierdie mense na te spoor. Jy sal maatstawwe nodig hê om te verstaan hoe suksesvol jou bemarkingsveldtog is en hoe dit werklik presteer. Hulle sal jou byvoorbeeld help om 'n doeltreffende CRM - kliënteverhoudingbestuurstelsel te ontwikkel.
Kom ons begin dus met ons Azure-wolkdiens. Dit is baie maklik om statistiekversameling te vind en te organiseer, want dit het Azure Monitor. Hierdie monitor sentraliseer jou stelselkonfigurasiebestuur. Elkeen van die Azure-elemente wat u op u stelsel wil toepas, het baie maatstawwe by verstek geaktiveer. Dit is 'n gratis toepassing wat reg uit die boks werk en geen voorlopige instellings benodig nie; jy hoef niks aan jou stelsel te skryf of te "skroef" nie. Ons sal dit verifieer deur na die volgende demo te kyk.
Daarbenewens is dit moontlik om hierdie maatstawwe na derdeparty-toepassings te stuur, soos die Splunk-logberging- en analisestelsel, die wolkgebaseerde logbestuurtoepassing SumoLogic, die ELK-logverwerkingsinstrument en IBM Radar. Dit is waar, daar is geringe verskille wat afhang van die hulpbronne wat u gebruik - 'n virtuele masjien, netwerkdienste, Azure SQL-databasisse, dit wil sê, die gebruik van statistieke verskil na gelang van die funksies van u werksomgewing. Ek sal nie sê dat hierdie verskille ernstig is nie, maar ongelukkig is hulle steeds teenwoordig, en dit moet in ag geneem word. Aktivering en stuur van statistieke is moontlik op verskeie maniere: deur Portal, CLI/Power Shell, of deur ARM-sjablone te gebruik.
Voordat ek met my eerste demo begin, sal ek enige vrae wat jy mag hê beantwoord. As daar geen vrae is nie, kom ons begin. Die skerm wys hoe die Azure Monitor-bladsy lyk. Kan enige een van julle sê dat hierdie monitor nie werk nie?
So nou is alles in orde, jy kan sien hoe die monitordienste lyk. Ek kan sê dat dit 'n uitstekende en baie eenvoudige hulpmiddel vir alledaagse werk is. Dit kan gebruik word om toepassings, netwerke en infrastruktuur te monitor. Onlangs is die moniteringskoppelvlak verbeter, en as voorheen dienste op verskillende plekke geleë was, word alle inligting oor dienste nou op die monitor se tuisblad gekonsolideer.
Die statistiektabel is 'n oortjie langs die HomeMonitorMetrics-pad, waarheen jy kan gaan om al die beskikbare statistieke te sien en die wat jy nodig het te kies. Maar as jy statistiekversameling moet aktiveer, moet jy die HomeMonitorDiagnostic-instellingsgidspad gebruik en die Geaktiveerde/Gedeaktiveerde statistieke merkblokkies merk. By verstek is byna alle maatstawwe geaktiveer, maar as jy iets bykomend moet aktiveer, sal jy die diagnostiese status van Gedeaktiveer na Geaktiveer moet verander.
Om dit te doen, klik op die lyn van die geselekteerde metriek en aktiveer die diagnostiese modus op die oortjie wat oopmaak. As jy die geselekteerde maatstaf gaan ontleed, moet jy, nadat jy op die Skakel diagnostiese skakel geklik het, die Stuur na Log Analytics-merkblokkie merk in die venster wat verskyn.
Log Analytics is 'n bietjie soortgelyk aan Splunk, maar kos minder. Hierdie diens laat jou toe om al jou maatstawwe, logs en alles wat jy nodig het te versamel en dit in die Log Analytics-werkspasie te plaas. Die diens gebruik 'n spesiale KQL-navraagverwerkingstaal - Kusto Quarry Language, ons sal na die werk daarvan kyk in die volgende demo. Vir eers sal ek daarop let dat u met die hulp daarvan navrae kan skep oor statistieke, logboeke, terme, neigings, patrone, ens. en skep dashboards.
So, ons merk die Stuur na Log Analytics-merkblokkies en die LOG-paneel-merkblokkies: DataPlaneRequests, MongoRequests en QueryRuntimeStatistics, en onder op die METRIC-paneel – die Versoeke-merkblokkie. Dan gee ons 'n naam en stoor die instellings. Op die opdragreël verteenwoordig dit twee reëls kode. Terloops, die Azure Cloud-dop lyk in hierdie sin soos Google, wat jou ook toelaat om die opdragreël in jou webblaaier te gebruik. AWS het nie so iets nie, so Azure is baie geriefliker in hierdie sin.
Ek kan byvoorbeeld 'n demonstrasie deur die webkoppelvlak laat loop sonder om enige kode op my skootrekenaar te gebruik. Om dit te doen, moet ek verifieer met my Azure-rekening. Dan kan jy byvoorbeeld terrafone gebruik, as jy dit reeds gebruik, wag vir die verbinding met die diens en kry die Linux-werksomgewing wat Microsoft by verstek gebruik.
Vervolgens gebruik ek Bash, ingebou in die Azure Cloud Shell. 'n Baie nuttige ding is die IDE wat in die blaaier ingebou is, 'n liggewig weergawe van VS-kode. Vervolgens kan ek na my foutmetriek-sjabloon gaan, dit wysig en dit aanpas om by my behoeftes te pas.
Sodra jy metriekeversameling in hierdie sjabloon opgestel het, kan jy dit gebruik om maatstawwe vir jou hele infrastruktuur te skep. Sodra ons die maatstawwe toegepas het, dit versamel en gestoor het, sal ons dit moet visualiseer.
Azure Monitor handel slegs met statistieke en gee nie 'n algehele prentjie van die gesondheid van u stelsel nie. Jy het dalk 'n aantal ander toepassings wat buite die Azure-omgewing loop. As u dus alle prosesse moet monitor deur al die versamelde statistieke op een plek te visualiseer, dan is Azure Monitor nie geskik hiervoor nie.
Om hierdie probleem op te los, bied Microsoft die Power BI-instrument aan, 'n omvattende sagteware vir besigheidsontleding wat visualisering van 'n wye verskeidenheid data insluit. Dit is 'n redelik duur produk, waarvan die koste afhang van die stel funksies wat u benodig. By verstek bied dit jou 48 soorte data om te verwerk en is gekoppel aan Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services en Azure Databricks. Deur skaalbaarheid te gebruik, kan jy elke 30 minute nuwe data ontvang. Dit is dalk nie voldoende vir jou behoeftes as jy intydse moniteringvisualisering benodig nie. In hierdie geval word dit aanbeveel om toepassings te gebruik soos die Grafana wat ek genoem het. Daarbenewens beskryf Microsoft-dokumentasie die vermoë om metrieke, logboeke en gebeurtenistabelle met behulp van SIEM-nutsmiddels na visualiseringstelsels Splunk, SumoLogic, ELK en IBM-radar te stuur.
23:40 min
Word binnekort vervolg...
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com