David O'Brien nedávno spustil svou vlastní společnost Xirus (https://xirus.com.au), která se zaměřuje na cloudové produkty Microsoft Azure Stack. Jsou navrženy tak, aby konzistentně budovaly a provozovaly hybridní aplikace v datových centrech, okrajových lokalitách, vzdálených pobočkách a cloudu.
David školí jednotlivce a společnosti ve všech věcech Microsoft Azure a Azure DevOps (dříve VSTS) a stále provádí praktické konzultace a infrakódování. Již 5 let je držitelem ceny Microsoft MVP (Microsoft Most Valuable Professional) Award a nedávno obdržel cenu Azure MVP Award. Jako spoluorganizátor Melbourne Microsoft Cloud and Datacentre Meetup O'Brien pravidelně vystupuje na mezinárodních konferencích a kombinuje svůj zájem o cestování po světě s vášní pro sdílení IT příběhů s komunitou. Davidův blog se nachází na adrese , také zveřejňuje své online školení na Pluralsight.
Přednáška hovoří o důležitosti metrik pro pochopení toho, co se děje ve vašem prostředí a jak si vaše aplikace vede. Microsoft Azure nabízí výkonný a snadný způsob, jak zobrazit metriky pro všechny druhy úloh, a přednáška vysvětluje, jak je můžete všechny používat.
V neděli ve 3 hodiny ráno, když spíte, vás náhle probudí textová zpráva: „superkritická aplikace znovu nereaguje.“ Co se děje? Kde a jaký je důvod „brzd“? V této přednášce se dozvíte o službách, které Microsoft Azure nabízí zákazníkům pro shromažďování protokolů a zejména metrik z vašich cloudových úloh. David vám prozradí, jaké metriky by vás při práci na cloudové platformě měly zajímat a jak se k nim dostat. Dozvíte se o nástrojích s otevřeným zdrojovým kódem a sestavování řídicích panelů a získáte dostatek znalostí k vytvoření vlastních řídicích panelů.
A pokud vás ve 3 hodiny ráno znovu probudí zpráva, že došlo k selhání kritické aplikace, můžete rychle zjistit její příčinu.
Dobré odpoledne, dnes budeme mluvit o metrikách. Jmenuji se David O'Brien, jsem spoluzakladatel a majitel malé australské poradenské společnosti Xirus. Ještě jednou děkuji, že jste sem přišli a strávili se mnou čas. Tak proč jsme tady? Abychom mluvili o metrikách, nebo spíše, řeknu vám o nich, a než něco uděláme, začněme teorií.
Řeknu vám, co jsou metriky, co s nimi můžete dělat, na co si musíte dát pozor, jak sbírat a povolit shromažďování metrik v Azure a co je vizualizace metrik. Ukážu vám, jak tyto věci vypadají v cloudu Microsoftu a jak s tímto cloudem pracovat.
Než začneme, požádám o zvednutí ruky od těch, kteří používají Microsoft Azure. Kdo pracuje s AWS? Vidím málo. A co Google? ALI Cloud? Jeden muž! Skvělý. Co jsou tedy metriky? Oficiální definice amerického Národního institutu pro standardy a technologie zní: „Metrika je standard měření, který popisuje podmínky a pravidla pro měření vlastnosti a slouží k pochopení výsledků měření.“ Co to znamená?
Vezměme si příklad metriky pro změnu volného místa na disku virtuálního počítače. Například máme číslo 90 a toto číslo znamená procento, to znamená, že množství volného místa na disku je 90%. Podotýkám, že není moc zajímavé číst popis definice metrik, který zabere 40 stran ve formátu pdf.
Metrika však neříká, jak byl výsledek měření získán, pouze ukazuje tento výsledek. Co děláme s metrikami?
Nejprve změříme hodnotu něčeho, abychom pak použili výsledek měření.
Zjistili jsme například množství volného místa na disku a nyní jej můžeme využít, využít tuto paměť atd. Jakmile obdržíme výsledek metriky, musíme jej interpretovat. Například metrika vrátila výsledek 90. Potřebujeme vědět, co toto číslo znamená: množství volného místa nebo množství použitého místa na disku v procentech nebo gigabajtech, latence sítě rovna 90 ms a tak dále, tj. , musíme interpretovat význam metrické hodnoty. Aby metriky měly vůbec smysl, po interpretaci jedné hodnoty metriky musíme zajistit, aby bylo shromážděno více hodnot. To je velmi důležité, protože mnoho lidí si neuvědomuje potřebu shromažďovat metriky. Společnost Microsoft velmi usnadnila shromažďování metrik, ale je na vás, abyste zajistili jejich shromažďování. Tyto metriky jsou uloženy pouze 41 dní a zmizí 42. den. V závislosti na vlastnostech vašeho externího nebo interního zařízení byste se proto měli postarat o to, jak ukládat metriky po dobu delší než 41 dní - ve formě protokolů, protokolů atd. Po shromáždění byste je tedy měli umístit na nějaké místo, které vám v případě potřeby umožní vytáhnout všechny statistiky změn ve výsledcích metrik. Jakmile je tam vložíte, můžete s nimi začít efektivně pracovat.
Teprve poté, co získáte metriky, interpretujete je a shromáždíte, můžete vytvořit SLA - smlouvu o úrovni služeb. Tato smlouva SLA nemusí mít velký význam pro vaše zákazníky, je důležitější pro vaše kolegy, manažery, ty, kteří systém udržují a mají obavy o jeho funkčnost. Metrika umí měřit počet tiketů – například obdržíte 5 tiketů denně a v tomto případě ukazuje rychlost reakce na požadavky uživatelů a rychlost odstraňování problémů. Metrika by neměla jen říkat, že se vaše stránky načítají za 20 ms nebo že vaše rychlost odezvy je 20 ms, metrika je více než jen jeden technický indikátor.
Úkolem našeho rozhovoru je proto předložit vám detailní obrázek o podstatě metrik. Metrika slouží k tomu, abyste si při jejím pohledu mohli udělat úplný obrázek o procesu.
Jakmile máme metriku, můžeme na 99 % zaručit, že systém funguje, protože to není jen pohled na soubor protokolu, který říká, že systém funguje. Záruka 99% dostupnosti znamená, že například 99% času API reaguje běžnou rychlostí 30 ms. To je přesně to, co zajímá vaše uživatele, vaše kolegy a manažery. Mnoho našich klientů sleduje logy webového serveru, ale žádné chyby v nich nezaznamenávají a myslí si, že je vše v pořádku. Například vidí rychlost sítě 200 Mb/s a pomyslí si: „ok, všechno je skvělé!“ K dosažení těchto 200 však uživatelé potřebují rychlost odezvy 30 milisekund, a to je přesně ten indikátor, který se neměří a neshromažďuje v souborech protokolu. Uživatelé jsou zároveň překvapeni, že se stránky načítají velmi pomalu, protože nemají potřebné metriky a neznají důvody tohoto chování.
Ale protože máme 100% dostupnost SLA, zákazníci si začínají stěžovat, protože použití webu je ve skutečnosti velmi obtížné. Pro vytvoření objektivní smlouvy SLA je proto nutné vidět úplný obraz procesu vytvořený nasbíranými metrikami. Toto je trvalý problém, který mám s některými poskytovateli, kteří při vytváření SLA nemají ponětí, co znamená termín „uptime“ a ve většině případů nevysvětlují svým klientům, jak funguje jejich API.
Pokud jste vytvořili službu, například API pro třetí osobu, měli byste pochopit, co znamená výsledná metrika 39,5 - odezva, úspěšná odezva, odezva rychlostí 20 ms nebo rychlostí 5 ms. Je na vás, abyste přizpůsobili jejich SLA své vlastní SLA, svým vlastním metrikám.
Jakmile to všechno zjistíte, můžete začít vytvářet ohromující řídicí panel. Řekněte mi, už někdo použil interaktivní vizualizační aplikaci Grafana? Skvělý! Jsem velkým fanouškem tohoto open source, protože tato věc je zdarma a snadno se používá.
Pokud jste Grafanu ještě nepoužili, řeknu vám, jak s ní pracovat. Každý, kdo se narodil v 80. a 90. letech, si pravděpodobně pamatuje CareBears? Nevím, jak populární byli tito medvědi v Rusku, ale pokud jde o metriky, měli bychom být stejní „medvědi“. Jak jsem řekl, potřebujete velký obrázek o tom, jak celý systém funguje, a nemělo by to být jen o vašem API, vašem webu nebo službě běžící na virtuálním stroji.
Musíte zorganizovat sbírku těch metrik, které nejlépe odrážejí provoz celého systému. Většina z vás jsou vývojáři softwaru, takže se váš život neustále mění, přizpůsobuje se novým požadavkům na produkty, a stejně jako se zabýváte procesy kódování, měli byste se zabývat i metrikami. Musíte vědět, jak metrika souvisí s každým řádkem kódu, který napíšete. Například příští týden zahájíte novou marketingovou kampaň a očekáváte, že váš web navštíví velké množství uživatelů. K analýze této události budete potřebovat metriky a možná budete potřebovat celý řídicí panel ke sledování aktivity těchto lidí. Budete potřebovat metriky, abyste pochopili, jak úspěšná je vaše marketingová kampaň a jak si skutečně vede. Pomohou vám například vyvinout efektivní CRM – systém řízení vztahů se zákazníky.
Začněme tedy s naší cloudovou službou Azure. Je velmi snadné najít a uspořádat kolekci metrik, protože má Azure Monitor. Tento monitor centralizuje správu konfigurace systému. Každý z prvků Azure, který chcete použít na svůj systém, má ve výchozím nastavení povoleno mnoho metrik. Jedná se o bezplatnou aplikaci, která funguje ihned po vybalení a nevyžaduje žádné předběžné nastavení, nemusíte do systému nic zapisovat ani „šroubovat“. To si ověříme při pohledu na následující demo.
Kromě toho je možné posílat tyto metriky aplikacím třetích stran, jako je systém ukládání a analýzy protokolů Splunk, aplikace pro správu protokolů v cloudu SumoLogic, nástroj pro zpracování protokolů ELK a IBM Radar. Pravda, existují drobné rozdíly, které závisí na používaných prostředcích – virtuální počítač, síťové služby, databáze Azure SQL, to znamená, že použití metrik se liší v závislosti na funkcích vašeho pracovního prostředí. Neříkám, že tyto rozdíly jsou vážné, ale bohužel stále existují, a to je třeba vzít v úvahu. Povolení a odeslání metrik je možné několika způsoby: prostřednictvím portálu, CLI/Power Shell nebo pomocí šablon ARM.
Než začnu s mojí první ukázkou, odpovím na všechny vaše otázky. Pokud nejsou žádné otázky, začněme. Obrazovka ukazuje, jak vypadá stránka Azure Monitor. Může někdo z vás říci, že tento monitor nefunguje?
Nyní je tedy vše v pořádku, můžete se podívat, jak vypadají služby monitoru. Mohu říci, že se jedná o vynikající a velmi jednoduchý nástroj pro každodenní práci. Lze jej použít k monitorování aplikací, sítí a infrastruktury. Nedávno bylo vylepšeno monitorovací rozhraní, a pokud byly dříve služby umístěny na různých místech, nyní jsou všechny informace o službách konsolidovány na domovské stránce monitoru.
Tabulka metrik je karta podél cesty HomeMonitorMetrics, na kterou můžete přejít a zobrazit všechny dostupné metriky a vybrat ty, které potřebujete. Pokud však potřebujete povolit shromažďování metrik, musíte použít cestu k adresáři nastavení HomeMonitorDiagnostic a zaškrtnout políčka Enabled/Disabled metrics. Ve výchozím nastavení jsou téměř všechny metriky povoleny, ale pokud potřebujete povolit něco dalšího, budete muset změnit stav diagnostiky z Disabled na Enabled.
Chcete-li to provést, klikněte na řádek vybrané metriky a na kartě, která se otevře, povolte diagnostický režim. Pokud se chystáte analyzovat vybranou metriku, musíte po kliknutí na odkaz Zapnout diagnostiku zaškrtnout políčko Odeslat do protokolu analýzy v okně, které se objeví.
Log Analytics je trochu podobný Splunk, ale stojí méně. Tato služba vám umožňuje shromažďovat všechny vaše metriky, protokoly a vše ostatní, co potřebujete, a umístit je do pracovního prostoru Log Analytics. Služba využívá speciální jazyk pro zpracování dotazů KQL - Kusto Quarry Language, na jeho práci se podíváme v příštím demu. Prozatím poznamenám, že s jeho pomocí můžete vytvářet dotazy týkající se metrik, protokolů, termínů, trendů, vzorů atd. a vytvářet dashboardy.
Zaškrtneme tedy políčko Send to Log Analytics a zaškrtávací políčka panelu LOG: DataPlaneRequests, MongoRequests a QueryRuntimeStatistics a níže na panelu METRIC – políčko Requests. Poté přiřadíme název a uložíme nastavení. Na příkazovém řádku to představuje dva řádky kódu. Mimochodem, Azure Cloud shell v tomto smyslu připomíná Google, což také umožňuje používat příkazový řádek ve webovém prohlížeči. AWS nic takového nemá, takže Azure je v tomto smyslu mnohem pohodlnější.
Například mohu spustit demo prostřednictvím webového rozhraní bez použití jakéhokoli kódu na svém notebooku. K tomu se musím ověřit pomocí svého účtu Azure. Poté můžete použít například terrafone, pokud jej již používáte, počkejte na připojení ke službě a získejte linuxové pracovní prostředí, které Microsoft standardně používá.
Dále používám Bash, zabudovaný do Azure Cloud Shell. Velmi užitečnou věcí je IDE zabudované v prohlížeči, odlehčená verze VS Code. Dále mohu přejít do své šablony chybových metrik, upravit ji a přizpůsobit tak, aby vyhovovala mým potřebám.
Jakmile v této šabloně nastavíte kolekci metrik, můžete ji použít k vytvoření metrik pro celou infrastrukturu. Jakmile použijeme metriky, shromáždíme je a uložíme, budeme je muset vizualizovat.
Azure Monitor se zabývá pouze metrikami a neposkytuje celkový obrázek o stavu vašeho systému. Můžete mít řadu dalších aplikací spuštěných mimo prostředí Azure. Pokud tedy potřebujete monitorovat všechny procesy a vizualizovat všechny nasbírané metriky na jednom místě, pak se k tomu Azure Monitor nehodí.
K vyřešení tohoto problému nabízí Microsoft nástroj Power BI, komplexní software pro obchodní analýzu, který zahrnuje vizualizaci široké škály dat. Jedná se o poměrně drahý produkt, jehož cena závisí na sadě funkcí, které potřebujete. Ve výchozím nastavení vám nabízí 48 druhů dat ke zpracování a je propojený s Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services a Azure Databricks. Pomocí škálovatelnosti můžete přijímat nová data každých 30 minut. To může, ale nemusí být dostatečné pro vaše potřeby, pokud potřebujete vizualizaci monitorování v reálném čase. V tomto případě se doporučuje použít aplikace, jako je Grafana, kterou jsem zmínil. Kromě toho dokumentace společnosti Microsoft popisuje možnost odesílat metriky, protokoly a tabulky událostí pomocí nástrojů SIEM do vizualizačních systémů Splunk, SumoLogic, ELK a IBM radar.
23:40 min
Pokračování již brzy...
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com