Zpracování open data o Covid-19 v Log Analytics s využitím Azure Automation

V tomto příspěvku bychom vám rádi představili možnosti platformy Azure Monitor, respektive komponenty Log Analytics, která zajišťuje analýzu dat s využitím zabudovaného vyhledávacího nástroje s názvem Kusto Query Language. V rámci příspěvku se budeme zabývat integrací dat z veřejných API a z dalších datových zdrojů, které nejsou přímo integrované do platformy Log Analytics.

Azure Monitor

Na začátek je důležité si říct, co je platforma Azure Monitor, potažmo její část Log Analytics, a kde vlastně tato platforma běží a jak funguje. Azure Monitor a Log Analytics jsou komponenty ze služeb Microsoft Azure, a Azure Monitor je centrální služba pro monitoring, alert management a poskytuje základní dva pohledy na data. Respektive umožňuje integrovat základní dva datové typy zdrojů, a to tzv. Metriky a Logy. Metrika je většinou něco, co běží kontinuálně, jako například výkonové ukazatele monitorovaných služeb a zařízení. Log je událost (Event), který vznikne při něčem, co se ve službě nebo na zařízení stane, jako například, když provedeme přihlášení na server, tak se nám vytvoří událost v Event Logu. Azure Monitor máme v rámci prostředí Microsoft Azure vždy jen jeden, tedy jedná se o tzv. službu tenanta Microsoft Azure. Kdežto Log Analytics je mnohem níž ve struktuře prostředí Microsoft Azure a jedná se o službu, kterou lze provozovat na úrovni každé Resource group, tedy nějakého logického celku. Z tohoto důvodu jsou logy vždy uchovávány ve vámi zvoleném regionu, a to v regionu, který je stanoven na úrovni logického celku (Resource Group). Proto můžeme data odesílat jen do datových center v rámci Evropy a nemusíme se bát přenosu dat mimo Evropský hospodářský prostor (EHS). Služba Log Analytics umožňuje stanovit různé retenční stupně v rozmezí 30–730 dní a je možné tuto retenci stanovit pro každý log samostatně. Kromě toho, že Log Analytics umožňuje prostřednictvím agenta nebo syslogu sbírat logy a metriky z koncového zařízení, má otevřené HTTP DATA API (REST API), které budeme využívat k integraci dat.

Demonstraci integrace, vizualizace a analýzy dat si představíme na datech, která jsou poskytnuta jako Open Data přímo Ministerstvem zdravotnictví, a my si analyzujeme informace o aktuálním stavu nákazy SARS-CoV-2 (COVID-19) nebo také novým koronavirem. Stejně tak, jako budeme analyzovat data o stavu nákazy, můžeme analyzovat data i z jiných datových zdrojů. Příkladem by mohla být analýza dat z portálu pastebin.com, shodan.io nebo virtustotal.com, pokud bychom chtěli vytěžovat tuto databázi a získávat tak cenné informace o různých malware, uniklých datech a informacích třeba o našem prostředí.

Proč zrovna Log Analytics a ne jiné nástroje?

To je určitě důležitá otázka a jde o to, že data ve službě Log Analytics jsou zpracovávána tak rychle, že i zpracování 100 milionu událostí trvá řádově několik málo vteřin, čehož dle dosavadních výsledků dosahuje jen málokterá platforma, a rozhodně to nelze příliš očekávat u platformy provozované v lokálním prostředí.

První, co nás bude při vytvoření prostředí čekat, je stavba Log Analytics Workspace. Vytvoření Log Analytics Workspace je velice jednoduché a v zásadě jej připravíme obratem na několik kliknutí. Budeme k tomu potřebovat zvolit název workspace, region, licenční model (tady je důležité říct, že každý měsíc máme 5 GB dat k dispozici zdarma).

Po vytvoření Log Analytics workspace budeme mít vše připraveno k okamžitému použití pro integraci dat z veřejně dostupných API nebo z veřejných zdrojů obecně. Z nově vytvořeného Log Analytics workspace budeme potřebovat opsat dva důležité parametry, a to workspace ID a primární klíč. Musíme si tedy otevřít Workspace a v něm pod položkou Advanced Settings, kde najdeme záložku Connected Sources, a oba parametry si zde můžeme zkopírovat.

Automation Account

Nyní bude nutné připravit něco, co nám zajistí orchestraci. V zásadě potřebujeme komponentu, která nám umožní automatické spouštění nějakého scriptu a bude serverless, ale pokud bychom měli někde umístěno zařízení, ze kterého budeme script spouštět například pomocí naplánované úlohy, tak můžeme. Je v celku jedno, odkud script poběží, pokud dané zařízení bude mít přístup do internetu. My však použijeme serverless technologii, a tou je tzv. Automation Accounts, tedy účet, který zařídí spuštění PowerShell scriptu, který si bude pravidelně sahat pro potřebná data, a ta bude ukládat do námi připraveného Log Analytics workspace.

Automation Account vytvoříme tak, že přistoupíme v prostředí Microsoft Azure do části Automation Accounts a vytvoříme novou komponentu. Zde je potřeba si uvědomit, že spouštění bude něco málo stát, ale jedná se řádově o malé jednotky dolarů, přičemž 500 minut běhu máme zdarma. Tedy zdarma můžete toto provozovat, pokud například provedeme spuštění a načtení dat každé 3 hodiny. Na vytvoření Automation Account budeme potřebovat jen jeho jméno, vybrat subcription, kde jej budeme provozovat, resource group a umístění, tedy region.

Automation Account je potřeba trošku připravit, tedy v rámci Automation Accountu musíme nejprve vytvořit Runbook a následně bude potřeba vytvořit Scheduler, který zajistí spuštění Runbook v pravidelných intervalech. Abychom však měli co do Runbook přidat, musíme si připravit script, který nám bude data z otevřeného datového zdroje získávat a k tomu můžeme využít například níže uvedený script. Tento script se podívá do otevřených datových zdrojů umístěných na stránce Ministerstva zdravotnictví, a to na adrese https://onemocneni-aktualne.mzcr.cz/api/v1/covid-19 a zpracuje je. Vhodné je si vzít rovnou data ve formátu JSON, abychom nemuseli předpřipravovat data ve scriptu. Podle aktuální struktury dat si vybereme, zda budeme denně nahrávat všechna data, anebo si vybereme jen data konkrétního dne. Podle toho, jak data pošleme, podle toho budeme muset upravit dotazy v Kusto Query Language. Osobně však navrhuji data odesílat přírůstkově, protože optimalizujete místo v Log Analytics workspace, který nedisponuje deduplikací dat, a také vám nepoběží Runbooky příliš dlouho, zejména pokud bude datová sada příliš velká.

Mohli bychom načítat data i z CSV souboru, vždy je však nutné provést jejich převod do JSON formátu. Co se týká vnořených větví v rámci datové struktury, tak ty nejsou problém, tedy pokud máme data v košaté struktuře (tzv. nested), tak i s nimi si Log Analytics workspace poradí sám a data správně zařadí, indexuje a rozloží. Pokud by nám některá rozložení nevyhovovala, pak je můžete ještě dál parsovat přímo v Kusto Query Language, případně v námi definované vizualizaci. Co je podstatné, že i když mají jednotlivé bloky rozdílné sloupce a nahráváme je do jednoho logu, jako v našem případě, tak si s tím Log Analytics poradí sám a my se staráme jen o správné deklarování vstupů.

Nejprve jsme si tedy připravili PowerShell, který budeme používat v Azure Automation a který nám bude data vyčítat z veřejného JSON a následně odesílat do Log Analytics. Důležité je, aby výstupní formát byl JSON a obsah proměnné byl uložen jako string s tím, že začíná hranatými závorkami, tedy v JSON formátu se jedná o Array. Je vždy výhodnější nahrávat více dat v jednom volání než provádět více samostatných volání, a to zejména proto, že Azure má také své limity (například počet volání v rámci Subscription, Resource Group atd.). Pokud budeme chtít pracovat s časem v rámci vstupů, pak je potřeba počítat s tím, že formát času bude potřeba zřejmě upravit tak, aby byl relevantní a všude stejný (myslím v rámci vstupních dat). Někteří totiž mohou data posílat ve formátu dd-mm-rrrr, ale jiní zase jako mm-dd-rrrr a spousta jiných formátů. Také je potřeba nezapomenout na podstatný detail a to, že v jedné zprávě můžeme odeslat maximálně 30 MB dat a do jednoho řádku záznamu můžete vložit až 32 KB dat, přičemž počet sloupců je omezen na 500 a každý sloupec může obsahovat maximálně 500 znaků. Tedy je potřeba dobře rozmyslet jaké informace budete odesílat.

U běžných zpráv to bude určitě v pořádku, ale pokud bychom posílali například syslogové zprávy, pak mohou být řetězce zkracovány, a to rozhodně nechceme. Pak bychom museli řešit parsování už v datovém kolektoru, který data do prostředí odesílá. Pokud máme vytvořen JSON ve formě proměnné, pak je možné jej do prostředí nahrát, a toto je nutné udělat podle stanoveného postupu, který je popsán v dokumentaci společnosti Microsoft. Důležité je, že ve scriptu se generuje autentizační hlavička, která je postavena z množství hodnot, mezi nimiž je výše uvedený primární klíč. Vše se následně odesílá na API, které obsahuje vaše unikátní workspace ID. Po odeslání se vám musí zobrazit návratová hodnota 200, pak se můžete těšit na svá data v platformě Log Analytics. Data však nejsou viditelná a přístupná hned, protože musí projít indexem, a to nějakou chvilku trvá. Nejdéle trvá vytvoření schéma tabulky, když je totiž tabulka vytvořena, tak jsou data v prostředí do cca 7 minut. Vytvoření schématu trvá běžně okolo 1 hodiny.

Nyní tedy vezmeme script a ten umístíme do Runbooku ve službě Azure Automation a provedeme nastavení scheduleru. Tedy otevřeme si opět Automation Accounts a přidáme, do námi vytvořeného Automation Accountu, nový Runbook. Nastavíme jeho jméno a typ. Typ bude samozřejmě Powershell.

Runbook se nám otevře a my můžeme vložit kód, který následně uložíme a tlačítkem Publish jej opublikujeme do Azure prostředí. Po publikaci můžeme spustit testování daného Runbooku, tedy můžeme provést manuální spuštění a pokud vše funguje, jak má, pak jej zadáme do plánovače (Scheduleru).

Jakmile data nahrajeme do Log Analytics Workspace, tak se můžeme posunout k vytvoření prvních dotazů v Kusto Query Language, které si můžeme vizualizovat pomocí Azure Workbooks.

Abychom se dostali k možnosti vyhledávat v čisté podobě dat (v tzv. RAW datech), tak budeme potřebovat otevřít ideálně Azure Monitor, ale dostat bychom se tam mohli i skrze Log Analytics Workspace. K práci s logy lze využívat i dalších nástrojů, jen je potřeba znát správné syntaxe k možnosti připojení se do našeho Log Analytics Workspace. Těmi nástroji může být například Azure Data Explorer nebo lokální aplikace Kusto Explorer. Tyto nástroje však vyžadují zadání URL adresy, která je přístupná skrze ADX Cluster. Využít můžeme také integraci na PowerBI, a tím spojit naše data s dalšími daty v jiných systémech, aniž bychom je museli přenášet do platformy Azure Monitor, potažmo Log Analytics.

Pokud tedy otevřeme Azure Monitor, máme možnost zvolit položku Logs a definovat, ve kterém Log Analytics Workspace chceme vyhledávat. Poté můžeme psát naše dotazy. Tyto dotazy jsou značně intuitivní a nástroj dává možnost využívat i intergovaný IntelliSense, což je, laicky řečeno, nápověda k dotazům. Kusto Query Language má i velice dobře zpracovanou dokumentaci a mnoho příkladů (https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/), jak psát dotazy. Pro postoupení k vizualizaci si musíme tento jazyk osvojit, jelikož bez něho se bohužel dále nedostaneme.

Vizualizace

Data přímo v editoru můžeme zobrazit ve formě tabulky, anebo si můžeme nechat vykreslit různé grafy, abychom získali představu, jak budeme s daty pracovat a co chceme konzumentovi servírovat.

Tyto grafy je možné připnout klidně na hlavní Azure Dashboard a nechat je v čase aktualizovat, anebo si můžeme připravit vlastní report s daty, které máme k dispozici. Vše je v zásadě na nás a záleží vždy, kdo bude konzumentem informací. Doporučení, jak čerpat data, je jednoduché a vždy se dělí podle toho, kdo bude k datům přistupovat. Můžeme se držet jednoduchého klíče:

• Potřebujeme mít k dispozici operační data na centrálních monitorech krizového štábu? Pak bude jistě vhodné používat Azure Dashboards nebo Grafana, což jsou nástroje, které umí automatické obnovení stránky

• Potřebujeme vidět datové přehledy, případně propojovat data z více nástrojů na jedno místo, ale chceme se udržet v prostředí Microsoft Azure? Pak použijeme Azure Workbooks

• Potřebujeme data dostat k businessu a potřebujeme je integrovat s jinými daty nebo zobrazit na intranetu, který běží například nad SharePoint Online? Pak data vizualizujme v PowerBI.

Pokud si připravíme data a Query, přepočítáme potřebná pole a doplníme další výpočtové operace napříč datovým zdrojem, pak můžeme tyto informace velmi snadno vizualizovat v Azure Workbooks. Azure Workbooks nám umožní vytvořit různé vizualizace, jako například

• Grafy

• Plástve s filtry pro barvy

• Tabulky

• Klasické grafy

• Mapy

• Atd.

Jak můžeme následná vizualizace vypadat, se podíváme níže, a již nyní je nutné říct, že stavba reportů je o kreativitě a umění servírování dat dle konzumenta, tedy je nutné přihlédnout k tomu, jakou znalost má ten, pro něhož jsou data připravována.

Dozvěděli jsme se něco o službě Azure Monitor a Log Analytics Workspace, ukázali jsme si, jak integrovat data s využitím HTTP DATA API a jak tato data dostat do zpracovatelné struktury v Log Analytics Workspace. Ukázali jsme si, jak tato data načítat automaticky pomocí serverless technologie Azure Automation a dále jsme se podívali na hlavní vizualizační nástroje. Představili jsme si dotazovací jazyk Kusto Query Language, a to vše jsme prováděli nad otevřenými daty týkajících se nákazy novým koronavirem, které poskytuje Ministerstvo zdravotnictví.