Nemrég David O'Brien elindította saját vállalatát, a Xirust (https://xirus.com.au), amely a Microsoft Azure Stack felhőtermékeire összpontosít. Ezek célja a hibrid alkalmazások összhangban történő létrehozása és indítása adatközpontokban, határ menti elhelyezkedésekben, távoli irodákban és a felhőben.
David az egyének és a cégek számára oktatást nyújt mindaz, ami a Microsoft Azure-ra és Azure DevOps-ra (korábban VSTS) vonatkozik, és továbbra is gyakorlati tanácsadással és infrastruktúra kódolással foglalkozik. Már 5 éve birtokolja a Microsoft MVP (Microsoft Legértékesebb Szakértő) díjat, és nemrégiben megkapta az MVP Azure díjat. A Melbourne Microsoft Cloud és Datacenter Meetup társszervezőjeként O'Brien rendszeresen beszélgetéseket tart nemzetközi konferenciákon, ötvözve az utazás iránti érdeklődését az IT történetek közlésének szenvedélyével a közösséggel. David blogja elérhető a , emellett online képzéseket is publikál a Pluralsight platformon.
A prezentáció a metrikák fontosságáról szól, hogy megértsük, mi történik a környezetében és hogyan működik az alkalmazása. A Microsoft Azure erőteljes és egyszerű módot kínál mindenféle terhelés metrikáinak megjelenítésére, és az előadásban arról van szó, hogyan lehet ezeket mind kihasználni.
Hajnali 3-kor, vasárnap, miközben alszol, hirtelen megébreszt a szöveges üzenet riasztása: "a kritikus alkalmazás ismét nem válaszol". Mi történik? Hol és mi a probléma a "lassulással"? Ebből az előadásból megtudhatja, milyen szolgáltatásokat kínál a Microsoft Azure az ügyfeleknek a naplók és különösen a felhőalapú terheléseik metrikáinak gyűjtésére. David elmondja, hogy mely metrikák érdeklik Önt a felhőplatformon történő munka során, és hogyan érheti el ezeket. Megismerheti a nyílt forráskódú eszközöket és a műszerfalak létrehozását, és ennek eredményeként elegendő tudással fog rendelkezni saját műszerfalai elkészítéséhez.
És ha hajnali 3-kor ismét felébreszt egy üzenet, ami a kritikus alkalmazás összeomlásáról szól, gyorsan rá tud majd jönni, mi okozza a problémát.
Jó napot kívánok, ma a metrikákról fogunk beszélni. A nevem David O’Brien, az ausztrál Xirus tanácsadó cég társalapítója és tulajdonosa. Még egyszer köszönöm, hogy itt vagytok és velem töltitek az időt. Szóval, miért is vagyunk itt? Hogy beszélgessünk a metrikákról, pontosabban én elmondom nektek, miért fontosak, és mielőtt bármiféle dolgot tennénk, kezdjük el a teóriával.
Elmondom, hogy mik is a metrikák, mit lehet velük tenni, mire kell figyelni, hogyan lehet mérőszámokat gyűjteni és beépíteni a gyűjtést az Azure-ba, valamint mi az a metrikák vizualizációja. Megmutatom nektek, hogy ezek a dolgok hogyan néznek ki a Microsoft felhőjében és hogyan működnek ezzel a felhővel.
Azelőtt, hogy elkezdenénk, arra kérlek, hogy emeljétek fel a kezeteket, akik használják a Microsoft Azure-t. És ki dolgozik az AWS-sel? Látom, hogy kevesen. És a Googléval? ALI Cloud? Egy ember! Szuper. Szóval, mik is azok a metrikák? Az Egyesült Államok Szabványügyi és Technológiai Intézetének hivatalos definíciója így hangzik: „A metrika egy mérési standard, amely leírja a mérés körülményeit és szabályait, és segít megérteni a mérési eredményeket.” Mit is jelent ez?
Vegyük példának a virtuális gép szabad lemezterületének metrikáját. Például kapunk egy 90-es számot, és ez a szám azt jelenti, hogy a szabad lemezterület 90%-ot tesz ki. Megjegyzem, hogy nem túl izgalmas 40 oldalon keresztül olvasni a metrikák definícióját egy pdf-fájlon.
De a metrika nem mondja el, hogyan kaptuk az eredményt, csak megmutatja azt. Akkor mit is csinálunk a metrikákkal?
Először is, mérjük valaminek az értékét, hogy később felhasználhassuk a mérési eredményt.
Például megtudtuk a szabad lemezterület mennyiségét, és most már tudjuk használni ezt a memóriát stb. Miután megkaptuk a metrikák eredményét, értelmeznünk kell azt. Például a metrika 90-es értéket adott. Tudnunk kell, mit jelent ez a szám: a szabad lemezterület vagy a használt lemezterület arányban, gigabájtban vagy a hálózat késleltetése, ami 90 ms, és így tovább, tehát értelmeznünk kell a metrika jelentését. Ahhoz, hogy a metrikák egyáltalán értelmesek legyenek, a metrika egy értelmezése után biztosítani kell a sokféle érték gyűjtését. Ez nagyon fontos, mivel sok ember nem tudja, hogy szükséges a metrikák gyűjtése. A Microsoft nagyon egyszerűvé tette a metrikák beszerzésének folyamatát, de neked magadnak kell biztosítanod a gyűjtésüket. Ezek a metrikák mindössze 41 napig tárolódnak, és a 42. napon eltűnnek. Ezért a külső vagy belső hardvered tulajdonságaitól függően foglalkoznod kell azzal, hogyan őrizheted meg a metrikákat 41 napon túl — naplókként, jegyzeteként stb. Így miután összegyűjtötted őket, valamilyen helyre kell helyezned őket, amely lehetővé teszi a metrikák eredményeinek teljes statisztikájának gyors előhívását, ha szükséges. Ha ide helyezed őket, hatékony munkát kezdhetsz velük.
Csak miután megkaptad a metrikák értékeit, értelmezted és összegyűjtötted őket, tudod létrehozni az SLA-t – a szolgáltatási szint megállapodását. Ez az SLA talán nem jelent sokat az ügyfeleid számára, fontosabb a kollégáid, menedzsereid, valamint azok számára, akik biztosítják a rendszer működését és aggasztja őket a funkcionalitása. A metrika mérheti a jegyek számát – például naponta 5 jegy érkezik, és e tekintetben mutatja a felhasználói kérdésekre adott válasz sebességét és a hibák gyors elhárítását. A metrikának nem csak annyit kell jelentenie, hogy a webhelyed 20 ms alatt betöltődik, vagy a válaszidő 20 ms, a metrika több mint egy egyszerű technikai mutató.
Ezért beszélgetésünk célja, hogy bemutassam neked a metrikák lényegének kiterjedt képét. A metrika arra szolgál, hogy egy pillantás átvételekor teljes képet kaphass a folyamatról.
Amint megkaptuk a metrikát, 99%-os garanciát tudunk adni a rendszer működőképes állapotára, mivel ez nem csupán a naplófájlok megtekintése, amelyek azt mutatják, hogy a rendszer működik. A 99%-os rendelkezésre állás garanciája azt jelenti, hogy például az API 99%-ban normális 30 ms-os válaszidővel reagál. Ez pontosan az, ami a felhasználóidat, kollégáidat és menedzsereidet érdekli. Sokan a klienseink közül a webszerver naplóit követik, és nem észlelnek benne hibákat, ezért azt hiszik, hogy minden rendben van. Például látják a hálózati sebesség 200 mb/s mutatóját, és azt mondják: „oké, minden szuper!”. De ahhoz, hogy ezt a 200-at elérjék, a felhasználóknak 30 milliszekundumos válaszidőre van szükségük, és ez éppen az a mutató, amelyet nem mérnek és nem gyűjtenek be a naplófájlokban. Eközben a felhasználók meglepődnek, hogy a weboldal nagyon lassan töltődik be, mert a szükséges metrika hiányában nem tudják, miért viselkedik így.
De mivel van egy SLA-nk, amely 100%-os működést garantál, az ügyfelek elkezdenek elégedetlenkedni, mivel a weboldal valójában nagyon nehezen használható. Ezért az objektív SLA kialakításához látnunk kell a folyamat teljes képét, amelyet a gyűjtött metrikák alkotnak. Ez a folyamatos vitám tárgyát képezi néhány szolgáltatóval, akik az SLA kialakításakor nem értik, mit jelent az "uptime" kifejezés, és a legtöbb esetben nem magyarázzák el az ügyfeleiknek, hogyan működik az API-juk.
Ha létrehoztál egy szolgáltatást, például egy API-t harmadik fél számára, meg kell értened, mit jelent a kapott 39,5-ös metrika – válasz, sikeres válasz, 20 ms-os vagy 5 ms-os sebességgel érkező válasz. Neked kell alkalmaznod az SLA-jukat a saját SLA-dhoz, a saját metrikáidhoz.
Miután ezt mind kiderítettük, nekiállhatunk egy lenyűgöző monitorozó panel létrehozásának. Mondjátok, valaki már használt valaha interaktív vizualizációs alkalmazást, mint például a Grafana? Remek! Én nagy rajongója vagyok ennek az open source-nak, mert ingyenes és könnyen használható.
Ha még nem használtad a Grafanát, elmondom, hogyan működik. Akik az 80-as és 90-es években születtek, talán emlékeznek a gondoskodó CareBears macikra? Nem tudom, mennyire voltak népszerűek Oroszországban, de a metrikákkal kapcsolatban nekünk is olyan "gondoskodó maciknak" kell lennünk. Ahogy mondtam, szükség van egy átfogó képre az egész rendszer működéséről, és ez nem szabad, hogy csak a te API-dra, a webhelyedre vagy a virtuális gépen futó szolgáltatásra terjedjen ki.
Szervezned kell a legfontosabb metrikák gyűjtését, amelyek a legjobban tükrözik az egész rendszer működését. A legtöbben szoftverfejlesztők vagytok, ezért az életetek folyamatosan változik, alkalmazkodva az új termékkövetelményekhez, és ahogyan aggódtok a kódolási folyamatok miatt, úgy a metrikák miatt is aggódnotok kell. Tudnotok kell, hogyan kapcsolódik a metrika az általatok írt kód minden egyes sorához. Például a következő héten új marketingkampányba kezdesz, és számítasz rá, hogy a webhelyedet sok felhasználó fogja meglátogatni. Ehhez az eseményhez metrikákra lesz szükséged, és lehet, hogy egy egész panelre lesz szükséged a felhasználók aktivitásának nyomon követésére. A metrikák segítenek majd abban is, hogy kiderüljön, mennyire sikeres és hogyan működik valójában a marketingkampányod. Segítenek például egy hatékony CRM — ügyfélkapcsolati menedzsment rendszert kidolgozni.
Tehát kezdjük az Azure felhős szolgáltatásával. Itt nagyon könnyű megtalálni és megszervezni a metrikák gyűjtését, mert van Azure Monitor. Ez a monitor központosítja a rendszered konfigurációjának kezelését. Az Azure minden egyes eleméhez, amelyet a rendszeredben alkalmazni akarsz, rengeteg alapértelmezett metrika tartozik. Ez egy ingyenes alkalmazás, amely közvetlenül "do it yourself" módon működik, és nincs szükség előzetes beállításokra, nem kell semmit írni és „hozzáilleszteni” a rendszeredhez. Meggyőződünk erről a következő demonstráció megtekintésével.
Ezenkívül lehetőség van ezeknek a metrikáknak a harmadik féltől származó alkalmazásokba való továbbítására, mint például a Splunk logelemző és tároló rendszer, a SumoLogic felhőalapú logkezelő alkalmazás, az ELK logfeldolgozó eszköz, vagy az IBM Radar. Igaz, hogy itt kisebb eltérések vannak, amelyek az Ön által használt erőforrásoktól függenek – például a virtuális gép, a hálózati szolgáltatások vagy az Azure SQL adatbázisok. Ezért a metrikák használata a munkakörnyezet funkcióitól függően eltérő lehet. Nem mondanám, hogy ezek az eltérések jelentősek, de sajnos mégis jelen vannak, és ezt figyelembe kell venni. A metrikák engedélyezése és továbbítása több módon is lehetséges: a Portálon, CLI/Powershell segítségével, vagy ARM sablonokkal.
Mielőtt hozzákezdenénk az első bemutatóhoz, válaszolok a felmerülő kérdésekre. Ha nincs kérdés, kezdjük. A képernyőn látható, hogy hogyan néz ki az Azure Monitor oldala. Valaki közülük elmondhatja, hogy ez a monitor nem működik?
Nos, most már minden rendben van, látja, hogyan néznek ki a monitor szolgáltatásai. Azt mondhatom, hogy ez egy nagyszerű és nagyon egyszerű eszköz a napi munkához. Ezzel figyelheti a alkalmazásokat, a hálózatot és az infrastruktúrát. A közelmúltban a monitorozási felület frissült, és míg korábban a szolgáltatások különböző helyeken helyezkedtek el, mostanra minden információ a szolgáltatásokról a monitor kezdőlapján van összesítve.
A metrikák táblázata a HomeMonitorMetrics fül alatt található, ahova belépve megtekintheti az összes elérhető metrikát, és kiválaszthatja a szükségeseket. De ha a metrikák gyűjtését engedélyezni szeretné, akkor a HomeMonitorDiagnostic settings mappában kell eljárnia, és ellenőriznie kell a metrikák Engedélyezve/Letiltva jelölőnégyzetét. Alapértelmezés szerint szinte minden metrika engedélyezett állapotban van, de ha további elemeket szeretne engedélyezni, meg kell változtatnia a diagnosztikai állapotot Letiltva-ról Engedélyezve-ra.
Ehhez kattintson a kiválasztott metrika sorára, és az ott megnyíló fülön aktiválja a diagnosztikai módot. Ha a kiválasztott metrika elemzésére készül, akkor a Turn on diagnostic linkre kattintva jelölje be a megjelenő ablakban a Send to Log Analytics jelölőnégyzetet.
A Log Analytics kicsit hasonlít a Splunk-hoz, de olcsóbb. Ez a szolgáltatás lehetővé teszi az összes metrika, napló és minden szükséges információ összegyűjtését és elhelyezését a Log Analytics munkaterületén. A szolgáltatás egy speciális lekérdezésfeldolgozó nyelvet használ, a KQL-t – Kusto Quarry Language. Ennek működését a következő bemutatóban részletezzük. Addig is megjegyzem, hogy ezzel segítségével lekérdezéseket formálhat a metrikákkal, naplókkal, kifejezésekkel, trendekkel, mintákkal stb. kapcsolatban, és irányítópultokat hozhat létre.
Tehát bejelöljük a Send to Log Analytics jelölőnégyzetet és a LOG panel: DataPlaneRequests, MongoRequests és QueryRuntimeStatistics jelölőnégyzeteit, alatta pedig a METRIC panelen a Requests jelölőnégyzetet. Ezután adunk neki valamilyen nevet, és elmentjük a beállításokat. A parancssorban ez két sor kódot jelent. Mellesleg az Azure Cloud környezete ebben a tekintetben emlékeztet a Google-ra, amely szintén lehetővé teszi a parancssor használatát a böngészőben. Az AWS nem kínál ilyesmit, így az Azure ebben a tekintetben sokkal kényelmesebb.
Például a bemutatót a webes felületen keresztül indíthatom, és nem szükséges semmiféle kódot használnom a laptopomon. Ehhez be kell jelentkeznem az Azure fiókommal. Ezt követően használhatok például terrafone-t, ha már rendelkezik vele, meg kell várni a szolgáltatás kapcsolódását, és megkapni egy Linux munkakörnyezetet, amit a Microsoft alapértelmezés szerint használ.
Ezután a Bash-t használom, ami beépített az Azure Cloud Shell-be. Nagyon hasznos dolog a böngészőbe beépített IDE, ami egy könnyített verzió a VS Code-ból. Ezen kívül beléphetek a hiba metrikák sablonomba, módosíthatom azt, és a saját igényeim szerint testre szabhatom.
A metrikák gyűjtésének beállításával ezt alkalmazhatja az egész infrastruktúrája metrikáinak létrehozására. Miután alkalmaztuk a metrikákat, összegyűjtöttük és elmentettük őket, szükségünk lesz a vizualizálásukra.
Az Azure Monitor kizárólag a metrikákkal foglalkozik, és nem ad képet a rendszer állapotáról. Lehet, hogy más alkalmazásokat használ, amelyek az Azure környezetén kívül futnak. Tehát ha minden folyamatot monitorozni szeretne, és az összes összegyűjtött metrikát egy helyen vizualizálni, akkor az Azure Monitor erre nem alkalmas.
A feladat megoldásához a Microsoft Power BI eszközét kínálja – egy átfogó üzleti elemző szoftvert, amely különféle adatok vizualizálását tartalmazza. Ez egy meglehetősen drága termék, amelynek ára az Ön által szükséges funkciókészlettől függ. Alapértelmezés szerint 48 különböző adatfeldolgozási típust kínál, és kapcsolódik az SQL Azure adatbázisokhoz, az Azure Data Lake Storage-hoz, az Azure gépi tanulási szolgáltatásokhoz és az Azure Databricks-hez. A méretezhetőség révén minden 30 percben új adatokat kaphat. Ez elegendő lehet az igényeihez, vagy nem elegendő, ha valós idejű monitorozási vizualizációra van szüksége. Ebben az esetben ajánlott olyan alkalmazások használata, mint az általam említett Grafana. Ezenkívül a Microsoft dokumentációja leírja a lehetőséget, hogy metrikákat, naplókat és eseménytáblázatokat küldjön a SIEM – vizualizációs rendszerekhez, mint a Splunk, SumoLogic, ELK és IBM radar.
23:40 perc
A folytatás hamarosan érkezik...
Egy kis reklám 🙂
Köszönjük, hogy velünk maradtál. Tetszenek a cikkeink? Szeretnél több érdekes anyagot látni? Támogass minket, és rendelés leadásával vagy ismerősöknek ajánlással segíts nekünk. , Egyedülálló alternatívája az entry-level szervereknek, amelyet Önnek találtunk ki: (elérhetők RAID1 és RAID10 opciók, akár 24 magig és 40GB DDR4-ig).
Dell R730xd kétszer olcsóbban a Tier IV Equinix adatközpontban Amszterdamban? Csak nálunk Hollandiában! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 dollártól! Olvasd el ezt
Forrás: habr.com
