Nedávno David O’Brien založil svou vlastní společnost Xirus (https://xirus.com.au), která se zaměřuje na cloudové produkty Microsoft Azure Stack. Jsou určeny k konzistentnímu vytváření a nasazení hybridních aplikací v datových centrech, na okraji sítě, v odlehlých kancelářích a v cloudu.
David školí jednotlivce a firmy ve všem, co souvisí s Microsoft Azure a Azure DevOps (dříve VSTS) a stále se věnuje praktickému poradenství a infra-kódování. Již 5 let je držitelem ocenění Microsoft MVP (Nejhodnotnější profesionál Microsoftu) a nedávno získal ocenění MVP Azure. Jako spolupořadatel Melbourne Microsoft Cloud a Datacentre Meetup pravidelně vystupuje na mezinárodních konferencích, spojující svůj zájem o cestování po světě s vášní sdílet IT příběhy s komunitou. Davidův blog se nachází na adrese , také publikoval své online školení na Pluralsight.
V jeho prezentaci se hovoří o důležitosti metrik pro porozumění tomu, co se děje ve vaší oblasti a jak funguje vaše aplikace. Microsoft Azure poskytuje silný a jednoduchý způsob zobrazení metrik pro všechny typy pracovních zátěží, a v přednášce se uvádí, jak je všechny využít.
Ve 3 hodiny ráno v neděli vás během spánku náhle probudí zvuk textové zprávy: "kritická aplikace opět neodpovídá". Co se děje? Kde je příčina "zpoždění"? Z této přednášky se dozvíte o službách, které Microsoft Azure nabízí klientům pro sběr logů a především metrik vašich cloudových pracovních zátěží. David vám představí, jaké metriky by vás měly zajímat při práci na cloudové platformě a jak se k nim dostat. Dozvíte se o nástrojích s otevřeným zdrojovým kódem a budování monitorovacích panelů, a získáte tak dostatek znalostí, abyste si vytvořili vlastní panely.
A pokud vás ve 3 hodiny ráno opět probudí zpráva o pádu kritické aplikace, budete schopni rychle zjistit příčinu.
Dobrý den, dnes budeme hovořit o metrikách. Jmenuji se David O'Brien, jsem spoluzakladatel a majitel malé australské konzultační společnosti Xirus. Ještě jednou děkuji, že jste si našli čas a přišli sem. Takže, proč jsme zde? Abychom mluvili o metrikách, respektive já vám o nich povím, a než začneme s nějakými věcmi, začneme teorií.
Povím vám, co jsou metriky, co s nimi lze dělat, na co je třeba dávat pozor, jak sbírat metriky a integrovat sběr metrik v Azure, a co je to vizualizace metrik. Ukážu vám, jak tyto věci vypadají v cloudu Microsoftu a jak s tímto cloudem pracovat.
Než začneme, poprosím ty, kdo používají Microsoft Azure, aby zvedli ruku. A kdo pracuje s AWS? Vidím, že jen málokdo. A s Google? ALI Cloud? Jeden člověk! Skvěle. Takže, co jsou metriky? Oficiální definice Národního institutu standardů a technologií USA zní: „Metrika je standard měření, který popisuje podmínky a pravidla pro provádění měření nějakého vlastnosti a slouží k pochopení výsledků měření.“ Co to znamená?
Podívejme se na příklad metriky pro změnu volného místa na disku virtuálního stroje. Například nám je dáno číslo 90, a to číslo znamená procenta, tedy objem volného místa na disku činí 90%. Upozorňuji, že není příliš zajímavé číst popis definice metrik, který zabírá 40 stránek ve formátu pdf.
Metrika však neříká, jakým způsobem byl výsledek měření získán, pouze ukazuje tento výsledek. Co tedy děláme s metrikami?
Za prvé, měříme hodnotu něčeho, abychom poté mohli využít výsledek měření.
Například jsme zjistili objem volného diskového prostoru a nyní ho můžeme využívat, například tuto paměť atd. Jakmile získáme výsledek metriky, musíme ho interpretovat. Například metrika vygenerovala výsledek 90. Musíme vědět, co toto číslo znamená: objem volného prostoru nebo objem obsazeného prostoru disku v procentech nebo gigabajtech, latence sítě ve výši 90 ms atd., tedy musíme vyložit význam hodnoty metriky. Aby měření měla smysl, po interpretaci jedné hodnoty metriky je třeba zajistit sběr mnoha hodnot. To je velmi důležité, protože mnoho lidí si neuvědomuje potřebu sběru metrik. Microsoft velmi usnadnil proces získávání metrik, ale musíte zajistit jejich sběr sami. Tyto metriky jsou uchovávány pouze 41 dní a 42. den zmizí. Proto byste měli v závislosti na vlastnostech vašeho externího nebo interního zařízení přemýšlet o tom, jak uchovávat metriky déle než 41 dní — například ve formě logů, záznamů atd. Takže po sběru byste je měli umístit na nějaké místo, které vám umožní v případě potřeby vyzdvihnout celou statistiku změn výsledků metrik. Umístěním tam můžete začít s nimi efektivně pracovat.
Teprve poté, co získáte hodnoty metrik, interpretujete je a shromáždíte, můžete vytvořit SLA – dohodu o úrovni poskytování služeb. Toto SLA nemusí mít pro vaše klienty velký význam, je důležitější pro vaše kolegy, manažery, ty, kteří zajišťují chod systému a starají se o jeho funkčnost. Metrika může měřit počet tiketů — například dostáváte 5 tiketů denně, a v tomto případě ukazuje rychlost reakce na požadavky uživatelů a rychlost odstraňování závad. Metrika by neměla pouze informovat, že se váš web načítá za 20 ms nebo že rychlost odezvy činí 20 ms, metrika je víc než jen jeden technický ukazatel.
Proto je cílem našeho rozhovoru představit vám podrobný obraz podstaty metrik. Metrika slouží k tomu, abyste na ni pohlédli a dokázali získat úplný obrázek procesu.
Jakmile máme metriku, můžeme s 99% zárukou říct, že systém funguje, protože to není jen pohled do logu, kde je uvedeno, že systém pracuje. Záruka 99% provozuschopnosti znamená, že například v 99% případů API odpovídá normální 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ých serverů a přitom si nevšimnou žádných chyb a myslí si, že je vše v pořádku. Například vidí hodnocení rychlosti sítě 200 Mb/s a říkají si: „OK, všechno je skvělé!“. Ale aby se dosáhlo těchto 200, uživatelům je potřeba doba odezvy 30 milisekund, a to je právě ten parametr, který se neměří a nezaznamenává v logových souborech. Přitom uživatelé jsou překvapeni, že se stránky načítají velmi pomalu, protože bez potřebné metriky nevědí, proč se takto chovají.
Ale protože máme SLA, které zaručuje 100% provozuschopnost, začínají klienti vyjadřovat rozhořčení, protože je ve skutečnosti velmi obtížné web používat. Proto je pro vytvoření objektivního SLA nutné vidět celkový obrázek procesu, který je vytvářen shromážděnými metrikami. To je předmětem mého neustálého sporu s některými poskytovateli, kteří při vytváření SLA nechápou, co tento termín „uptime“ znamená, a ve většině případů svým klientům nevysvětlují, jak jejich API funguje.
Pokud jste vytvořili službu, například API pro třetí stranu, musíte chápat, co znamená získaná metrika 39,5 – odpověď, úspěšná odpověď, odpověď rychlostí 20 ms nebo rychlostí 5 ms. Právě vy byste měli přizpůsobit jejich SLA svému vlastnímu SLA, svým vlastním metrikám.
Jakmile to všechno zjistíte, můžete začít vytvářet skvělý monitorovací panel. Řekněte, někdo již využil aplikaci pro interaktivní vizualizaci Grafana? Skvělé! Jsem velkým fanouškem tohoto open source, protože je to zadarmo a snadno se používá.
Pokud jste ještě nepoužívali Grafanu, ukážu vám, jak s ní pracovat. Ti, kdo se narodili v 80. a 90. letech, si asi vzpomenou na milé medvídky CareBears? Neznám, jak populární byli tito medvídci v Rusku, ale co se týče metrik, měli bychom být stejně „péče plnými medvídky“. Jak jsem řekl, potřebujete ucelený pohled na fungování celého systému, a ten by neměl zahrnovat pouze vaše API, vaši webovou stránku nebo službu běžící na virtuálním stroji.
Musíte uspořádat sběr těch metrik, které nejlépe odrážejí fungování celého systému. Většina z vás je vývojářů softwaru, takže váš život se neustále mění, přizpůsobuje se novým požadavkům produktu, a tak jako se zabýváte procesy kódování, měli byste se také postarat o metriky. Musíte vědět, jak se metriky týkají každého řádku vašeho napsaného kódu. Například příští týden začínáte novou marketingovou kampaň a očekáváte, že váš web navštíví velké množství uživatelů. Pro analýzu této události budete potřebovat metriky a možná budete potřebovat celou panelovou aplikaci k sledování aktivity těchto lidí. Metriky vám přijdou vhod, abyste zjistili, jak úspěšná je a jak skutečně funguje vaše marketingová kampaň. Pomohou vám například navrhnout efektivní CRM — systém řízení vztahů se zákazníky.
Takže, pojďme se podívat na naši cloudovou službu Azure. Velmi snadno se zde nacházejí a organizují sběry metrik, protože tu máme Azure Monitor. Tento monitor centralizuje správu konfigurace vašeho systému. Každý prvek Azure, který chcete implementovat do svého systému, má mnoho výchozích metrik. Je to bezplatná aplikace, která funguje přímo „z krabice“ a nevyžaduje žádná předběžná nastavení, nemusíte nic psát ani „připojovat“ k vašemu systému. Ověříme si to prohlédnutím následujícího dema.
Kromě toho je třeba zasílat tyto metriky třetím aplikacím, jako je systém pro ukládání a analýzu logů Splunk, cloudová aplikace pro správu logů SumoLogic, nástroj pro zpracování logů ELK, IBM Radar. Pravda, že zde existují malé rozdíly, které závisí na používaných zdrojích – virtuálních strojích, síťových službách, databázích Azure SQL, takže použití metrik se liší v závislosti na funkcích vašeho pracovního prostředí. Není to tak, že by tyto rozdíly byly zásadní, ale bohužel zde jsou a je třeba je vzít v úvahu. Zahrnutí a odesílání metrik je možné několika způsoby: přes Portal, CLI/Power Shell nebo pomocí šablon ARM.
Než začneme s první ukázkou, rád odpovím na vaše případné dotazy. Pokud žádné dotazy nejsou, můžeme začít. Na obrazovce je vidět, jak vypadá stránka Azure Monitor. Může někdo z vás říct, že tento monitor nefunguje?
Takže teď je všechno v pořádku, vidíte, jak vypadají služby monitoru. Mohu říci, že je to skvělý a velmi jednoduchý nástroj pro každodenní práci. Pomocí něj lze monitorovat aplikace, síť a infrastrukturu. Nedávno bylo vylepšeno rozhraní monitorování, a pokud dříve byly služby rozloženy 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 záložka v cestě HomeMonitorMetrics, na kterou se můžete dostat, abyste viděli všechny dostupné metriky a vybrali si potřebné. Ale pokud potřebujete povolit sběr metrik, musíte použít cestu adresáře HomeMonitorDiagnostic settings a zkontrolovat zaškrtávací políčka metrik Enabled/Disabled. Ve výchozím stavu jsou prakticky všechny metriky zapnuté, ale pokud potřebujete povolit něco navíc, budete muset změnit stav diagnostiky z Disabled na Enabled.
K tomu je potřeba kliknout na řádek vybrané metriky a na otevřené záložce povolit diagnostický režim. Pokud plánujete analyzovat vybranou metriku, po kliknutí na odkaz Turn on diagnostic musíte v zobrazeném okně zaškrtnout políčko Send to Log Analytics.
Log Analytics je trochu podobný Splunku, ale je levnější. Tato služba vám umožňuje shromažďovat všechny vaše metriky, logy a vše, co potřebujete, a umístit je do pracovního prostoru Log Analytics. Služba používá speciální jazyk pro zpracování dotazů KQL – Kusto Query Language, jehož funkce si ukážeme v následujícím demu. Zatím jen zmíním, že s jeho pomocí můžete formulovat dotazy týkající se metrik, logů, termínů, trendů, vzorů atd. a vytvářet přehledové panely.
Takže zaškrtneme checkbox Send to Log Analytics a checkboxy panelu LOG: DataPlaneRequests, MongoRequests a QueryRuntimeStatistics, a níže na panelu METRIC zaškrtneme checkbox Requests. Poté přiřadíme nějaké jméno a uložíme nastavení. V příkazovém řádku to představuje dvě řádky kódu. Mimochodem, rozhraní Azure Cloud v tomto ohledu připomíná Google, který také umožňuje používat příkazový řádek ve vašem webovém prohlížeči. AWS nemá nic podobného, takže Azure je v tomto ohledu mnohem pohodlnější.
Například mohu spustit demo přes webové rozhraní, aniž bych pro to potřeboval jakýkoliv kód na svém notebooku. K tomu se musím autentizovat pomocí svého účtu Azure. Poté mohu například použít terrafone, pokud ho již používáte, počkat na připojení ke službě a získat pracovní prostředí Linux, které Microsoft používá jako výchozí.
Dále používám Bash, integrovaný v Azure Cloud Shell. Velmi užitečným nástrojem je integrované IDE v prohlížeči, zjednodušená verze VS Code. Poté mohu vstoupit do svého šablony metrik chyb, upravit ji a přizpůsobit svým potřebám.
Nastavením této šablony pro shromažďování metrik můžete aplikovat ji na vytváření metrik pro celou vaši infrastrukturu. Poté, co jsme metriky použili, shromáždili a uložili, budeme je potřebovat vizualizovat.
Azure Monitor se zaměřuje pouze na metriky a neposkytuje možnost získat celkový obraz stavu vašeho systému. Můžete mít v provozu řadu dalších aplikací, které běží mimo prostředí Azure. Takže pokud potřebujete monitorovat všechny procesy a vizualizovat všechny shromážděné metriky na jednom místě, Azure Monitor pro to nebude vyhovující.
Pro řešení tohoto úkolu Microsoft nabízí nástroj Power BI – komplexní software pro podnikovou analýzu, který zahrnuje vizualizaci nejrůznějších dat. Tento produkt je poměrně drahý a jeho cena se odvíjí od požadovaného balíčku funkcí. Ve výchozím nastavení nabízí 48 typů zpracovávaných dat a je propojen s datovými sklady SQL Azure, Azure Data Lake Storage, službami strojového učení Azure a Azure Databricks. Díky škálovatelnosti můžete každých 30 minut získávat nová data. To může být dostatečné pro vaše potřeby nebo naopak nedostatečné, pokud potřebujete vizualizaci monitorování v reálném čase. V takovém případě se doporučuje používat aplikace, jako je například Grafana, kterou jsem zmínil. Kromě toho dokumentace Microsoft popisuje možnost odesílat metriky, logy a tabulky událostí pomocí SIEM – nástroje do vizualizačních systémů, jako jsou Splunk, SumoLogic, ELK a IBM radar.
23:40 min
Pokračování bude brzy…
Malá reklama 🙂
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ých materiálů? Podpořte nás objednávkou nebo doporučením známým, , unikátní alternativa entry-level serverů, kterou jsme pro vás vymysleli: (k dispozici varianty s RAID1 a RAID10, až 24 jader a až 40GB DDR4).
Dell R730xd je dvakrát levnější v datovém centru Equinix Tier IV v Amsterdamu? Jen u nás v Nizozemsku! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Čtěte o tom
Zdroj: habr.com
