David O'Brien nemrégiben elindította saját cégét, a Xirus-t (https://xirus.com.au), amely a Microsoft Azure Stack felhőtermékeire összpontosít. Úgy tervezték, hogy következetesen építsenek és futtassanak hibrid alkalmazásokat adatközpontokban, szélső helyeken, távoli irodákban és a felhőben.
David magánszemélyeket és vállalatokat képez a Microsoft Azure és az Azure DevOps (korábban VSTS) területén, és továbbra is gyakorlati tanácsadást és infrakódolást végez. 5 éve a Microsoft MVP (Microsoft Most Valuable Professional) díj nyertese, és nemrégiben megkapta az Azure MVP-díjat. A melbourne-i Microsoft Cloud and Datacente Meetup társszervezőjeként O'Brien rendszeresen felszólal nemzetközi konferenciákon, és a világutazás iránti érdeklődését ötvözi az IT-történetek közösséggel való megosztása iránti szenvedéllyel. David blogja a címen található , online képzését is közzéteszi a Pluralsightról.
Az előadás a mérőszámok fontosságáról beszél a környezetében zajló események és az alkalmazás teljesítményének megértésében. A Microsoft Azure hatékony és egyszerű módja a metrikák megjelenítésének mindenféle munkaterheléshez, és az előadás elmagyarázza, hogyan használhatja ezeket.
Vasárnap hajnali 3-kor, miközben alszol, hirtelen egy szöveges üzenet ébreszt fel: „A szuperkritikus alkalmazás már nem válaszol.” Mi történik? Hol és mi az oka a „fékezésnek”? Ebben a beszélgetésben megtudhatja, hogy a Microsoft Azure milyen szolgáltatásokat kínál az ügyfeleknek a felhőalapú munkaterhelések naplóinak és különösen metrikáinak gyűjtésére. David elmeséli, hogy milyen mérőszámokra kell kíváncsi, ha felhőplatformon dolgozik, és hogyan érheti el ezeket. Megismerheti a nyílt forráskódú eszközöket és az irányítópult-építést, és elegendő tudással rendelkezik saját irányítópultok létrehozásához.
És ha hajnali 3-kor ismét egy üzenetre ébreszti, hogy egy kritikus alkalmazás összeomlott, gyorsan kiderítheti az okát.
Jó napot, ma a mérőszámokról fogunk beszélni. David O'Brien vagyok, egy kis ausztrál tanácsadó cég, a Xirus társalapítója és tulajdonosa vagyok. Még egyszer köszönöm, hogy eljöttél velem tölteni az idejét. Akkor miért vagyunk itt? Hogy a metrikákról beszéljünk, vagy inkább elmondom róluk, és mielőtt bármit tennénk, kezdjük az elmélettel.
Elmondom, mik azok a mérőszámok, mit kezdhetsz velük, mire kell figyelned, hogyan gyűjtsd össze és engedélyezd a metrikagyűjtést az Azure-ban, és mi az a metrikavizualizáció. Megmutatom, hogyan néznek ki ezek a dolgok a Microsoft felhőben, és hogyan kell dolgozni ezzel a felhővel.
Mielőtt elkezdenénk, kézfelemelést kérek a Microsoft Azure-t használóktól. Ki dolgozik az AWS-szel? keveset látok. Mi a helyzet a Google-lal? ALI felhő? Egy ember! Nagy. Tehát mik azok a mérőszámok? Az Egyesült Államok Nemzeti Szabványügyi és Technológiai Intézetének hivatalos meghatározása a következő: „A metrika olyan mérési szabvány, amely leírja egy tulajdonság mérésének feltételeit és szabályait, és a mérési eredmények megértését szolgálja.” Mit jelent?
Vegyünk egy példát egy virtuális gép szabad lemezterületének megváltoztatására szolgáló metrikára. Például a 90-es számot kapjuk, és ez a szám százalékot jelent, vagyis a szabad lemezterület mennyisége 90%. Megjegyzem, nem túl érdekes olvasni a mérőszámok definíciójának leírását, ami pdf formátumban 40 oldalt vesz igénybe.
A mérőszám azonban nem mondja meg, hogy a mérési eredményt hogyan kaptuk, csak ezt az eredményt mutatja. Mit kezdjünk a mérőszámokkal?
Először megmérjük valaminek az értékét, hogy aztán felhasználhassuk a mérési eredményt.
Például megtudtuk a szabad lemezterület mennyiségét, és most már használhatjuk, használhatjuk ezt a memóriát stb. Miután megkaptuk a metrikus eredményt, értelmeznünk kell azt. Például a metrika 90-es eredményt adott vissza. Tudnunk kell, hogy ez a szám mit jelent: a szabad terület mennyiségét vagy a felhasznált lemezterület mennyiségét százalékban vagy gigabájtban, a hálózati késleltetést 90 ms-ban, és így tovább. , értelmeznünk kell a metrikus érték jelentését. Ahhoz, hogy a mérőszámok egyáltalán értelmesek legyenek, egyetlen metrikaérték értelmezése után gondoskodnunk kell arról, hogy több értéket gyűjtsünk össze. Ez nagyon fontos, mert sokan nincsenek tisztában a mutatók gyűjtésének szükségességével. A Microsoft nagyon leegyszerűsítette a mutatók összegyűjtését, de az Önön múlik, hogy ezeket összegyűjti-e. Ezeket a mutatókat csak 41 napig tároljuk, és a 42. napon eltűnnek. Ezért a külső vagy belső berendezés tulajdonságaitól függően gondoskodnia kell arról, hogyan mentse el a mérőszámokat több mint 41 napig - naplók, naplók stb. Ezért az összegyűjtés után el kell helyeznie azokat egy olyan helyre, ahol szükség esetén előhívhatja a metrikus eredmények változásainak összes statisztikáját. Ha odatette őket, elkezdhet hatékonyan dolgozni velük.
Csak a mérőszámok beszerzése, értelmezése és összegyűjtése után hozhat létre SLA - szolgáltatási szint megállapodást. Ez az SLA nem biztos, hogy nagy jelentőséggel bír az ügyfelei számára, sokkal inkább a kollégáinak, vezetőinek, a rendszert karbantartóknak és a funkcionalitás miatt aggódóknak fontos. A mérőszám mérni tudja a jegyek számát - például naponta 5 jegyet kap, és ebben az esetben a felhasználói kérésekre adott válasz és a hibaelhárítás sebességét mutatja. A mérőszámnak nem csak azt kell mondania, hogy webhelye 20 ms alatt töltődik be, vagy a válaszsebesség 20 ms, a mérőszám több, mint egy technikai mutató.
Ezért beszélgetésünk feladata, hogy részletes képet adjunk a mérőszámok lényegéről. A mérőszám arra szolgál, hogy ránézésre teljes képet kaphasson a folyamatról.
Ha megvan a mérőszám, 99%-ban garantálhatjuk, hogy a rendszer működik, mert nem csak egy naplófájlt nézünk meg, amely szerint a rendszer működik. A 99%-os rendelkezésre állási garancia azt jelenti, hogy például az API az esetek 99%-ában normál, 30 ms-os sebességgel válaszol. Pontosan ez érdekli felhasználóit, kollégáit és vezetőit. Sok ügyfelünk figyeli a webszerver naplóit, de nem vesznek észre bennük hibát, és úgy gondolják, hogy minden rendben van. Például 200 Mb/s-os hálózati sebességet látnak, és azt gondolják: „ok, minden remek!” De ehhez a 200-hoz a felhasználóknak 30 ezredmásodperces válaszsebességre van szükségük, és pontosan ez az a mutató, amelyet nem mérnek, és nem gyűjtenek össze naplófájlokban. Ugyanakkor a felhasználók meglepődnek azon, hogy az oldal nagyon lassan töltődik be, mivel a szükséges mérőszámok hiányában nem ismerik ennek a viselkedésnek az okait.
De mivel 100%-os rendelkezésre állási SLA-val rendelkezünk, az ügyfelek panaszkodni kezdenek, mert a webhelyet valójában nagyon nehéz használni. Ezért egy objektív SLA létrehozásához szükséges, hogy az összegyűjtött metrikák teljes képet adjon a folyamatról. Ez egy folyamatos probléma néhány szolgáltatóval, akiknek az SLA-k létrehozásakor fogalmuk sincs, mit jelent az „üzemidő” kifejezés, és a legtöbb esetben nem magyarázzák el ügyfeleiknek, hogyan működik az API.
Ha létrehozott egy szolgáltatást, például egy API-t egy harmadik személy számára, meg kell értenie, mit jelent a kapott 39,5-ös mérőszám - válasz, sikeres válasz, válasz 20 ms sebességgel vagy 5 ms sebességgel. Önön múlik, hogy SLA-jukat saját SLA-jához, saját mérőszámaihoz igazítsa.
Ha mindezt kitalálta, megkezdheti egy lenyűgöző műszerfal létrehozását. Mondja, használta már valaki a Grafana interaktív vizualizációs alkalmazást? Nagy! Nagy rajongója vagyok ennek a nyílt forráskódnak, mert ez a dolog ingyenes és könnyen használható.
Ha még nem használta a Grafanát, akkor elmondom, hogyan kell vele dolgozni. Bárki, aki a 80-as és 90-es években született, valószínűleg emlékszik a CareBearsre? Nem tudom, mennyire voltak népszerűek ezek a medvék Oroszországban, de ha a mérőszámokról van szó, ugyanazoknak a „gondozó medvéknek” kell lennünk. Mint mondtam, átfogó képre van szüksége a teljes rendszer működéséről, és nem csak az API-ról, a webhelyről vagy a virtuális gépen futó szolgáltatásról kell szólnia.
Meg kell szerveznie azoknak a mérőszámoknak a gyűjtését, amelyek a legteljesebben tükrözik a teljes rendszer működését. A legtöbben szoftverfejlesztők, ezért élete folyamatosan változik, alkalmazkodik az új termékkövetelményekhez, és ahogyan a kódolási folyamatokkal foglalkozik, úgy a mérőszámokkal is foglalkoznia kell. Tudnia kell, hogy a metrika hogyan kapcsolódik az Ön által írt kód minden sorához. Például a jövő héten új marketingkampányba kezd, és arra számít, hogy nagyszámú felhasználó fogja felkeresni webhelyét. Az esemény elemzéséhez mérőszámokra lesz szüksége, és lehet, hogy egy teljes irányítópultra is szüksége lesz ezen személyek tevékenységének nyomon követéséhez. Mutatókra lesz szüksége ahhoz, hogy megértse, mennyire sikeres a marketingkampánya, és hogyan teljesít valójában. Segítenek például egy hatékony CRM - ügyfélkapcsolat-kezelő rendszer kidolgozásában.
Tehát kezdjük az Azure felhőszolgáltatásunkkal. Nagyon könnyű megtalálni és rendszerezni a mérőszámok gyűjteményét, mivel rendelkezik az Azure Monitorral. Ez a monitor központosítja a rendszerkonfiguráció kezelését. A rendszerére alkalmazni kívánt Azure-elemek mindegyike alapértelmezés szerint számos metrikával rendelkezik. Ez egy ingyenes alkalmazás, amely azonnal működik, és nem igényel előzetes beállításokat; nem kell semmit sem írnod vagy „csavarni” a rendszeredbe. Ezt a következő bemutatóval ellenőrizzük.
Ezenkívül lehetőség van ezeknek a mérőszámoknak a küldésére harmadik féltől származó alkalmazásoknak, például a Splunk naplótároló és elemző rendszernek, a felhő alapú naplókezelő alkalmazásnak, a SumoLogicnak, az ELK naplófeldolgozó eszköznek és az IBM Radarnak. Igaz, vannak apró eltérések, amelyek a használt erőforrásoktól – virtuális géptől, hálózati szolgáltatásoktól, Azure SQL-adatbázisoktól – függenek, vagyis a mérőszámok használata a munkakörnyezet funkcióitól függően eltérő. Nem mondom, hogy ezek a különbségek komolyak, de sajnos még mindig jelen vannak, és ezt figyelembe kell venni. A mérőszámok engedélyezése és küldése többféle módon lehetséges: a portálon, a CLI/Power Shell-en vagy az ARM-sablonok használatával.
Mielőtt elkezdenék az első bemutatómat, válaszolok minden kérdésére. Ha nincs kérdés, kezdjük. A képernyőn látható, hogyan néz ki az Azure Monitor oldal. Mondhatja közületek valaki, hogy ez a monitor nem működik?
Így most már minden rendben, láthatod, hogy néznek ki a monitorszolgáltatások. Azt mondhatom, hogy ez egy kiváló és nagyon egyszerű eszköz a mindennapi munkához. Alkalmazások, hálózatok és infrastruktúra figyelésére használható. A közelmúltban javult a felügyeleti felület, és ha korábban a szolgáltatások különböző helyeken helyezkedtek el, most a szolgáltatásokkal kapcsolatos összes információ a monitor kezdőlapján található.
A mérőszámtáblázat egy lap a HomeMonitorMetrics útvonalon, amelyen megtekintheti az összes elérhető mérőszámot, és kiválaszthatja a szükségeseket. Ha azonban engedélyeznie kell a mérőszámok gyűjtését, akkor használja a HomeMonitorDiagnostic beállítások könyvtárának elérési útját, és jelölje be az Engedélyezett/Letiltott metrikák jelölőnégyzeteket. Alapértelmezés szerint szinte az összes metrika engedélyezve van, de ha valami további engedélyezésére van szükség, akkor a diagnosztikai állapotot Letiltottról Engedélyezettre kell módosítania.
Ehhez kattintson a kiválasztott mérőszám sorára, és a megnyíló lapon engedélyezze a diagnosztikai módot. Ha a kiválasztott mérőszámot elemezni kívánja, akkor a Diagnosztika bekapcsolása linkre kattintás után a megjelenő ablakban be kell jelölnie a Naplóelemzés küldése jelölőnégyzetet.
A Log Analytics kissé hasonlít a Splunkhoz, de kevesebbe kerül. Ez a szolgáltatás lehetővé teszi, hogy összegyűjtse az összes mérőszámot, naplót és minden mást, amire szüksége van, és elhelyezheti azokat a Log Analytics munkaterületen. A szolgáltatás egy speciális KQL lekérdezés-feldolgozó nyelvet - Kusto Quarry Language - használ, ennek munkáját a következő demóban nézzük meg. Egyelőre megjegyzem, hogy segítségével lekérdezéseket hozhat létre metrikákra, naplókra, kifejezésekre, trendekre, mintákra stb. és hozzon létre irányítópultokat.
Tehát bejelöljük a Send to Log Analytics jelölőnégyzetet és a LOG panel jelölőnégyzeteit: DataPlaneRequests, MongoRequests és QueryRuntimeStatistics, lent pedig a METRIC panelen a Requests jelölőnégyzetet. Ezután nevet adunk és elmentjük a beállításokat. A parancssorban ez két kódsort jelent. Egyébként az Azure Cloud shell ebben az értelemben hasonlít a Google-ra, amely lehetővé teszi a parancssor használatát is a webböngészőben. Az AWS-ben nincs ilyesmi, tehát az Azure ebben az értelemben sokkal kényelmesebb.
Például futtathatok egy bemutatót a webes felületen keresztül anélkül, hogy kódot használnék a laptopomon. Ehhez hitelesítenem kell az Azure-fiókommal. Ezután használhatod például a terrafone-t, ha már használod, akkor várd meg a csatlakozást a szolgáltatáshoz és kapd meg azt a Linuxos munkakörnyezetet, amit a Microsoft alapértelmezés szerint használ.
Ezután az Azure Cloud Shellbe beépített Bash-t használom. Nagyon hasznos dolog a böngészőbe épített IDE, a VS Code könnyű verziója. Ezután beléphetek a hibamutató-sablonba, szerkeszthetem, és az igényeim szerint testreszabhatom.
Miután beállította a metrikagyűjteményt ebben a sablonban, használhatja a metrikák létrehozására a teljes infrastruktúrához. Miután alkalmaztuk a mutatókat, összegyűjtöttük és eltároltuk őket, vizualizálnunk kell őket.
Az Azure Monitor csak a mérőszámokkal foglalkozik, és nem ad átfogó képet a rendszer állapotáról. Előfordulhat, hogy számos más alkalmazás fut az Azure-környezeten kívül. Tehát ha az összes folyamatot figyelnie kell, az összes összegyűjtött mérőszámot egy helyen kell megjelenítenie, akkor az Azure Monitor erre nem alkalmas.
A probléma megoldására a Microsoft a Power BI eszközt kínálja, amely egy átfogó szoftver az üzleti elemzéshez, amely sokféle adat megjelenítését tartalmazza. Ez egy meglehetősen drága termék, amelynek költsége a szükséges funkcióktól függ. Alapértelmezés szerint 48 féle adatot kínál feldolgozni, és az Azure SQL Data Warehouses, az Azure Data Lake Storage, az Azure Machine Learning Services és az Azure Databricks szolgáltatáshoz kapcsolódik. A méretezhetőség segítségével 30 percenként kaphat új adatokat. Ez lehet, vagy nem elegendő az Ön igényeihez, ha valós idejű megfigyelési vizualizációra van szüksége. Ebben az esetben ajánlott olyan alkalmazásokat használni, mint az általam említett Grafana. Ezenkívül a Microsoft dokumentációja leírja a mérőszámok, naplók és eseménytáblázatok SIEM-eszközökkel történő küldésének lehetőségét a Splunk, SumoLogic, ELK és IBM radar vizualizációs rendszerekbe.
23:40 perc
Folytatás hamarosan...
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com