Sdílet prostřednictvím

Monitorování příjmu dat ve frontě s využitím metrik

  • Článek

V procesu příjmu dat ve frontě Azure Data Explorer optimalizuje příjem dat pro vysokou propustnost dávkovou dávkovou zásadou. Zásady dávkování umožňují nastavit podmínky triggeru pro zapečetění dávky (velikost dat, počet objektů blob nebo čas, který uplynul). Tyto dávky se pak optimálně ingestují pro rychlé výsledky dotazů.

V tomto článku se dozvíte, jak pomocí metrik monitorovat příjem dat ve frontě do Azure Data Exploreru na webu Azure Portal.

Fáze dávkování

Fáze popsané v této části platí pro všechny dávky příjmu dat. Pro Azure Event Grid, Azure Event Hubs, Azure IoT Hub a Cosmos DB příjem dat před frontou pro příjem dat získá datové připojení z externích zdrojů a provede počáteční uspořádání dat.

Příjem dat ve frontě probíhá ve fázích:

  1. Správce batchingu naslouchá frontě pro příjem zpráv a zpracovává požadavky.
  2. Batching Manager optimalizuje propustnost příjmu dat tím, že vezme malé bloky dat příchozího přenosu dat, které přijímá, a dávkování adres URL na základě zásad dávkování příjmu dat.
  3. Správce příjmu dat odešle příkazy pro příjem dat do modulu azure Data Explorer Storage.
  4. Modul azure Data Explorer Storage ukládá ingestované data a zpřístupňuje je pro dotazy.

Azure Data Explorer poskytuje sadu metrik příjmu dat služby Azure Monitor, abyste mohli monitorovat příjem dat ve všech fázích a komponentách procesu příjmu dat ve frontě.

Metriky příjmu dat v Azure Data Exploreru poskytují podrobné informace o:

  • Výsledek příjmu dat ve frontě
  • Množství přijatých dat.
  • Latence příjmu dat ve frontě a místa, kde k němu dochází.
  • Samotný proces dávkování.
  • Příjem dat služby Event Hubs, Event Grid a IoT Hub: Počet přijatých událostí.

V tomto článku se dozvíte, jak pomocí metrik příjmu dat na webu Azure Portal monitorovat příjem dat ve frontě do Azure Data Exploreru.

Požadavky

Vytváření grafů metrik pomocí Průzkumníka metrik služby Azure Monitor

Následuje obecné vysvětlení, jak používat metriky služby Azure Monitor, které se pak implementují v následujících částech. Pomocí následujících kroků vytvořte grafy metrik pomocí Průzkumníka metrik Služby Azure Monitor na webu Azure Portal:

  1. Přihlaste se k webu Azure Portal a přejděte na stránku přehledu clusteru Azure Data Exploreru.

  2. Výběrem možnosti Metriky na levém navigačním panelu otevřete podokno metrik.

  3. Otevřete panel pro výběr času v pravém horním rohu podokna metrik a změňte časový rozsah na čas, který chcete analyzovat. V tomto článku analyzujeme příjem dat do Azure Data Exploreru během posledních 48 hodin.

  4. Vyberte obor a obor názvů metrik:

    • Obor je název clusteru Azure Data Exploreru. V následujícím příkladu použijeme cluster s názvem demo11.
    • Obor názvů metrik by měl být nastavený na standardní metriky clusteru Kusto. Toto je obor názvů, který obsahuje metriky Azure Data Exploreru.

    Snímek obrazovky znázorňující výběr nastavení metriky na webu Azure Portal

  5. Vyberte název metriky a příslušnou hodnotu agregace.

V některých příkladech v tomto článku vybereme Přidat filtr a použít rozdělení pro metriky, které mají dimenze. K vykreslení dalších metrik ve stejném grafu a + Nový graf použijeme také přidání metriky, abychom viděli více grafů v jednom zobrazení.

Pokaždé, když přidáte novou metriku, zopakujete kroky čtyři a pět.

Poznámka:

Další informace o tom, jak pomocí metrik monitorovat Azure Data Explorer obecně a jak pracovat s podoknem metrik, najdete v tématu Monitorování výkonu, stavu a využití Azure Data Exploreru s metrikami.

V tomto článku se dozvíte, které metriky se dají použít ke sledování příjmu dat ve frontě a jak tyto metriky používat.

Zobrazení výsledku příjmu dat

Metrika výsledků příjmu dat poskytuje informace o celkovém počtu úspěšně přijatých zdrojů a o tom, které se nepodařilo ingestovat.

V tomto příkladu použijeme tuto metriku k zobrazení výsledku našich pokusů o příjem dat a použití informací o stavu k řešení potíží s neúspěšnými pokusy.

  1. V podokně Metriky ve službě Azure Monitor vyberte Přidat metriku.
  2. Vyberte výsledek příjmu dat jako hodnotu metriky a součet jako hodnotu Agregace . Tento výběr zobrazuje výsledky příjmu dat v průběhu času v jedné spojnici grafu.
  3. Vyberte tlačítko Použít rozdělení nad grafem a zvolte Stav a segmentujte graf podle stavu výsledků příjmu dat. Po výběru hodnot rozdělení zavřete kliknutím mimo volič rozdělení.

Teď jsou informace o metrikách rozdělené podle stavu a můžeme vidět informace o stavu výsledků příjmu dat rozdělené na tři řádky:

  1. Modrá pro úspěšné operace příjmu dat
  2. Oranžová pro operace příjmu dat, které selhaly kvůli nenalezené entitě.
  3. Fialová pro operace příjmu dat, které selhaly kvůli chybnému požadavku.

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující graf výsledků příjmu agregovaných podle součtu a rozdělení podle stavu

Při pohledu na graf výsledků příjmu dat zvažte následující skutečnosti:

  • Při použití centra událostí nebo příjmu dat centra IoT existuje v komponentě datového připojení předběžná agregace událostí. Během této fáze příjmu dat se události považují za jeden zdroj, který se má ingestovat. Proto se po předběžné agregaci zobrazí několik událostí jako jeden výsledek příjmu dat.
  • Přechodné selhání se můžou opakovat interně v omezeném počtu pokusů. Každé přechodné selhání se hlásí jako přechodný výsledek příjmu dat. Proto může jeden příjem dat vést k více než jednomu výsledku příjmu dat.
  • Chyby příjmu dat v grafu jsou uvedeny podle kategorie kódu chyby. Úplný seznam kódů chyb příjmu dat podle kategorií a pokuste se lépe porozumět možnému důvodu chyby, najdete v tématu Kódy chyb příjmu dat v Azure Data Exploreru.
  • Pokud chcete získat další podrobnosti o chybě příjmu dat, můžete nastavit diagnostické protokoly neúspěšného příjmu dat. Je však důležité vzít v úvahu, že generování protokolů vede k vytvoření dodatečných prostředků, a proto zvýšení COGS (náklady na prodané zboží).

Zobrazení ingestovaných dat

Metriky zpracovávané, přijaté objekty blob a vyřazené objekty blob poskytují informace o počtu zpracovaných, přijatých a vyřazených komponentami příjmu dat během fází příjmu dat ve frontě.

V tomto příkladu použijeme tyto metriky k tomu, abychom viděli, kolik dat bylo předáno prostřednictvím kanálu příjmu dat, kolik dat přijaly komponenty příjmu dat a kolik dat bylo vyřazeno.

Zpracované objekty blob

  1. V podokně Metriky ve službě Azure Monitor vyberte Přidat metriku.
  2. Vyberte objekty blob zpracovávané jako hodnotu metriky a součet jako hodnotu agregace .
  3. Vyberte tlačítko Použít rozdělení a zvolte Typ komponenty pro segmentování grafu podle různých komponent příjmu dat.
  4. Pokud se chcete zaměřit na konkrétní databázi v clusteru, vyberte nad grafem tlačítko Přidat filtr a pak zvolte, které hodnoty databáze se mají zahrnout při vykreslení grafu. V tomto příkladu vyfiltrujeme objekty blob odesílané do databáze GitHubu tak, že v rozevíracím seznamu Hodnoty vybereme možnost Database as =, as the Operator ( Operátor) a GitHub (GitHub). Po výběru hodnot filtru zavřete kliknutím mimo volič filtru.

Graf teď ukazuje, kolik objektů blob, které byly odeslány do databáze GitHubu, zpracováno v jednotlivých komponentách příjmu dat v průběhu času.

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující graf objektů blob zpracovaných z databáze GitHubu agregovaný podle součtu a rozdělení podle typu komponenty

  • Všimněte si, že 13. února došlo k poklesu počtu objektů blob, které se v průběhu času ingestovaly do databáze GitHubu . Všimněte si také, že počet objektů blob zpracovaných v každé z komponent je podobný, což znamená, že přibližně všechna data zpracovávaná v komponentě Datové připojení byla také úspěšně zpracována komponentami Batching Manager, Ingestion Manager a Azure Data Explorer Storage Engine . Tato data jsou připravená k dotazování.

Přijaté objekty blob

Abychom lépe pochopili vztah mezi počtem objektů blob přijatých v každé komponentě a počtem objektů blob, které byly úspěšně zpracovány v každé komponentě, přidáme nový graf:

  1. Vyberte + Nový graf.
  2. Zvolte stejné hodnoty jako v případě oboru, oboru názvů metrik a agregace a vyberte metriku Přijatá objekty blob.
  3. Vyberte tlačítko Použít rozdělení a zvolte Typ komponenty a rozdělte metriky Přijaté objekty blob podle typu komponenty.
  4. Vyberte tlačítko Přidat filtr a nastavte stejné hodnoty jako předtím a vyfiltrujte pouze objekty blob odeslané do databáze GitHubu.

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující grafy zpracovávaných objektů blob a objektů blob přijatých z databáze GitHub agregované podle součtu a rozdělení podle typu komponenty

  • Při porovnávání grafů si všimněte, že počet objektů blob přijatých jednotlivými komponentami úzce odpovídá počtu objektů blob zpracovaných jednotlivými komponentami. Toto porovnání znamená, že během příjmu dat nebyly vynechány žádné objekty blob.

Vyřazené objekty blob

Pokud chcete zjistit, jestli během příjmu dat došlo k vyřazení objektů blob, měli byste analyzovat metriku Vyřazené objekty blob. Tato metrika ukazuje, kolik objektů blob se během příjmu dat vynechalo, a pomáhá zjistit, jestli v konkrétní komponentě příjmu dat došlo k problému. U každého vyřazeného objektu blob získáte také metriku výsledku příjmu s dalšími informacemi o důvodu selhání.

Zobrazení latence příjmu dat

Latence fáze fáze a latence zjišťování monitorují latenci v procesu příjmu dat a říkají, jestli se v Azure Data Exploreru vyskytují nějaké dlouhé latence, nebo než data dorazí do Azure Data Exploreru pro příjem dat.

  • Latence fáze označuje časové rozpětí od okamžiku, kdy Azure Data Explorer zjistí zprávu, dokud její obsah neobdrží komponenta příjmu dat ke zpracování.
  • Latence zjišťování se používá pro kanály příjmu dat s datovými připojeními (jako je centrum událostí, centrum IoT a Event Grid). Tato metrika poskytuje informace o časovém rozsahu z výčtu dat, dokud se nezjišťuje datová připojení Azure Data Exploreru. Tento časový rozsah je nadřazený do Azure Data Exploreru, takže není součástí metriky Latence fáze, která měří pouze latenci v Azure Data Exploreru.

Poznámka:

Podle výchozích zásad dávkování je výchozí doba dávkování pět minut. Proto pokud dávka není zapečetěna jinými aktivačními událostmi, dávka se zapečetí po pěti minutách.

Když uvidíte dlouhou latenci, dokud nebudou data připravená k dotazování, analýza latence fáze a latence zjišťování vám může pomoct pochopit, jestli je dlouhá latence způsobená dlouhou latencí v Azure Data Exploreru nebo je v Azure Data Exploreru nadřazená. Pokud je latence v Samotném Azure Data Exploreru, můžete také zjistit konkrétní komponentu odpovědnou za dlouhou latenci.

Latence fáze (Preview)

Nejprve se podíváme na latenci fáze příjmu dat ve frontě. Vysvětlení jednotlivých fází najdete v tématu Fáze dávkování.

  1. V podokně Metriky ve službě Azure Monitor vyberte Přidat metriku.
  2. Jako hodnotu metriky vyberte Latence fáze a jako hodnotu Agregace průměr.
  3. Vyberte tlačítko Použít rozdělení a zvolte Typ komponenty pro segmentování grafu podle různých komponent příjmu dat.
  4. Vyberte tlačítko Přidat filtr a vyfiltrujte data odesílaná do databáze GitHubu. Po výběru hodnot filtru zavřete kliknutím mimo volič filtru. Graf teď ukazuje latenci operací příjmu dat, které se posílají do databáze GitHubu v jednotlivých komponentách prostřednictvím příjmu dat v průběhu času:

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující graf latence fáze příjmu dat z databáze GitHub agregované průměrem a rozdělením podle typu komponenty

Z tohoto grafu můžeme zjistit následující informace:

  • Latence komponenty datového připojení služby Event Hubs je přibližně 0 sekund. To dává smysl, protože latence fáze měří latenci pouze v případě, že Azure Data Explorer zjistí zprávu.
  • Nejdelší doba v procesu příjmu dat (přibližně 5 minut) se předává, když komponenta Batching Manager přijala data do okamžiku, kdy komponenta Správce příjmu dat přijala data. V tomto příkladu používáme výchozí zásady dávkování pro databázi GitHubu . Jak je uvedeno, časový limit latence výchozích zásad dávkování je 5 minut, takže to s největší pravděpodobností značí, že téměř všechna data byla dávkově dávková podle času a většina času latence pro příjem dat ve frontě byla způsobená samotným dávkováním.
  • Latence modulu úložiště v grafu představuje latenci, dokud se data nebudou ukládat do modulu Azure Data Explorer Storage a jsou připravená k dotazování. Můžete vidět, že průměrná celková latence od doby zjišťování dat v Azure Data Exploreru, dokud není připravená na dotaz, je 5,2 minuty.

Latence zjišťování

Pokud používáte příjem dat s datovými připojeními, můžete chtít odhadnout latenci upstreamu do Azure Data Exploreru v průběhu času, protože latence může nastat i předtím, než Azure Data Explorer získá data pro příjem dat. Pro tento účel můžete použít metriku Latence zjišťování.

  1. Vyberte + Nový graf.
  2. Jako hodnotu metriky vyberte Latence zjišťování a jako hodnotu Agregace průměr.
  3. Vyberte tlačítko Použít rozdělení a zvolte Typ komponenty a segmentujte graf podle různých typů komponent datového připojení. Po výběru hodnot rozdělení zavřete kliknutím mimo volič rozdělení.

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující graf latence zjišťování pro příjem dat z databáze GitHub agregované průměrem a rozdělením podle typu komponenty

  • Vidíte, že po většinu doby trvání latence zjišťování je téměř 0 sekund, což znamená, že Azure Data Explorer získal data hned po vytvoření fronty dat. Nejvyšší špička kolem 300 milisekund je přibližně 13. února v 14:00, což znamená, že v tuto chvíli cluster Azure Data Explorer obdržel data kolem 300 milisekund po vytvoření fronty dat.

Vysvětlení procesu dávkování

Ve druhé fázi toku příjmu dat ve frontě komponenta Batching Manager optimalizuje propustnost příjmu dat dávkovým dávkováním podle zásad dávkování příjmu dat.

Následující sada metrik vám pomůže pochopit, jak se data během příjmu dat dávkovají:

  • Zpracované dávky: Počet dokončených dávek pro příjem dat.
  • Velikost dávky: Odhadovaná velikost nekomprimovaných dat v dávce agregované pro příjem dat.
  • Doba trvání dávky: Doba trvání každé jednotlivé dávky od okamžiku, kdy je dávka otevřena, dokud se dávka netěsní.
  • Počet objektů blob služby Batch: Počet objektů blob v dokončené dávce pro příjem dat.

Zpracované dávky

Začněme celkovým zobrazením procesu dávkování tím, že se podíváme na metriku Zpracované dávky.

  1. V podokně Metriky ve službě Azure Monitor vyberte Přidat metriku.
  2. Vyberte Dávky zpracovávané jako hodnotu metriky a součet jako hodnotu agregace .
  3. Vyberte tlačítko Použít rozdělení a zvolte Typ dávkování pro segmentování grafu podle důvodu, proč byla dávka zapečetěná. Úplný seznam typů dávkování najdete v tématu Typy dávkování.
  4. Vyberte tlačítko Přidat filtr a vyfiltrujte dávky odeslané do databáze GitHubu. Po výběru hodnot filtru zavřete kliknutím mimo volič filtru.

Graf zobrazuje počet zapečetěných dávek s daty odesílanými do databáze GitHubu v průběhu času rozdělením podle typu batching.

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující graf dávek zpracovaných pro příjem dat z databáze GitHub agregované podle součtu a rozdělení podle typu dávkování

  • Všimněte si, že v průběhu času existují 2 až 4 dávky a všechny dávky jsou zapečetěné časem podle odhadu v části Latence fáze, kde vidíte, že dávkování dat trvá přibližně 5 minut na základě výchozích zásad dávkování.

Doba trvání, velikost a počet objektů blob dávky

Teď pojďme dále charakterizovat zpracované dávky.

  1. Vyberte tlačítko + Přidat graf pro každý graf a vytvořte další grafy pro hodnoty Batch Duration (Doba trvání) metriky (Batch Duration), Batch Size (Velikost dávky) a Batch Blob Count (Počet objektů blob dávky).
  2. Jako hodnotu Agregace použijte průměr.
  3. Stejně jako v předchozím příkladu vyberte tlačítko Přidat filtr a vyfiltrujte data odesílaná do databáze GitHubu.

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující grafy počtu objektů blob batch, doby trvání služby Batch a metrik velikosti dávky pro příjem dat z databáze GitHub agregované průměrem a rozdělením podle typu dávkování

V grafech Dávkové doby trvání, Velikosti dávky a Počtu objektů blob služby Batch můžeme uzavřít některé přehledy:

  • Průměrná doba trvání dávky je pět minut (podle výchozích zásad dávkování). Při pohledu na celkovou latenci příjmu dat byste to měli vzít v úvahu.

  • V grafu Velikost dávky můžete vidět, že průměrná velikost dávek je v průběhu času kolem 200–500 MB. Optimální velikost dat, která se mají ingestovat, je 1 GB nekomprimovaných dat a tato velikost se také definuje jako podmínka zapečetění ve výchozím nastavení zásad dávkování. Vzhledem k tomu, že v průběhu času není k dispozici 1 GB dat, nevidíme žádné dávky zapečetěné podle velikosti.

  • Průměrný počet objektů blob v dávkách je přibližně 160 objektů blob v průběhu času, což se pak sníží na 60 až 120 objektů blob. Na základě výchozích zásad dávkování může dávka zapečetit, když je počet objektů blob 1000 objektů blob. Vzhledem k tomu, že na toto číslo nepřijdeme, nevidíme dávky zapečetěné podle počtu.

Porovnání událostí přijatých k událostem odeslaných pro příjem dat

Při použití centra událostí, centra IoT nebo příjmu dat event Gridu může být užitečné porovnat počet událostí přijatých Azure Data Explorerem s počtem událostí odeslaných ze zdroje událostí do Azure Data Exploreru. Díky metrikám událostí přijatých, zpracovaných událostí a vyřazeným událostem můžete toto porovnání provést.

Přijaté události

  1. V podokně Metriky ve službě Azure Monitor vyberte Přidat metriku.
  2. Vyberte Události přijaté jako hodnotu metriky a součet jako hodnotu Agregace .
  3. Vyberte tlačítko Přidat filtr nad grafem a zvolte název komponenty hodnoty vlastnosti a vyfiltrujte události přijaté konkrétním datovým připojením definovaným ve vašem clusteru. V tomto příkladu vyfiltrujeme datové připojení GitHubStreamingEvents . Po výběru hodnot filtru zavřete kliknutím mimo volič filtru.

Graf teď zobrazuje počet událostí přijatých vybraným datovým připojením v průběhu času:

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující graf událostí přijatých během příjmu dat z databáze GitHub agregované v průběhu času

  • V tomto grafu přijímá datové připojení GitHubStreamingEvents přibližně 200–500 událostí za časovou jednotku v průběhu času.

Zpracovávané události a vyřazené události

Pokud chcete zjistit, jestli azure Data Explorer některé události vynechal, použijte metriky Zpracovávané události a Vyřazené události.

  1. V grafu, který jste už vytvořili, vyberte Přidat metriku.
  2. Vyberte Události zpracovávané jako hodnotu metriky a součet jako hodnotu Agregace .
  3. Znovu vyberte Přidat metriku a jako hodnotu Agregace vyberte Události vynechané jako hodnotu metriky a součet jako hodnotu Agregace .

Graf teď zobrazuje počet přijatých, zpracovaných a vyřazených datových připojení GitHubStreamingEvents v průběhu času.

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující grafy přijatých, zpracovávaných a ukončených událostí během příjmu dat z databáze GitHub agregované v průběhu času

  • Datové připojení úspěšně zpracovalo téměř všechny přijaté události. Došlo k jedné vyřazené události, která je kompatibilní s neúspěšným výsledkem příjmu dat kvůli chybnému požadavku, který jsme viděli při prohlížení metriky výsledků příjmu dat.

Porovnání událostí přijatých v Azure Data Exploreru s odchozími zprávami z centra událostí

Můžete také porovnat počet přijatých událostí s počtem událostí odesílaných z centra událostí do Azure Data Exploreru porovnáním metrik přijatých a odchozích zpráv .

  1. V grafu, který jste už vytvořili pro přijaté události, vyberte Přidat metriku.

  2. Vyberte Obor a v dialogovém okně Vybrat obor , vyhledejte a vyberte obor názvů centra událostí, který odesílá data do datového připojení.

    Snímek obrazovky s dialogovým oknem Vybrat obor na webu Azure Portal zobrazující hledání github4demo v seznamu oborů názvů služby Event Hubs

  3. Výběr možnosti Použít

  4. Vyberte odchozí zprávy jako hodnotu metriky a součet jako hodnotu Agregace .

Kliknutím mimo nastavení získáte úplný graf, který porovnává počet událostí zpracovaných datovým připojením Azure Data Exploreru k počtu událostí odesílaných z centra událostí.

Snímek obrazovky s podoknem Metriky na webu Azure Portal zobrazující grafy pro všechny přijaté, zpracovávané, ukončené a během příjmu dat z databáze GitHub agregované v průběhu času

  • Všimněte si, že datové připojení Azure Data Exploreru úspěšně zpracovalo všechny události odeslané z centra událostí.
  • Pokud máte v oboru názvů centra událostí více než jedno centrum událostí, měli byste metriku Odchozí zprávy filtrovat podle dimenze Název entity, abyste získali pouze data z požadovaného centra událostí v oboru názvů centra událostí.

Poznámka:

Není možné monitorovat odchozí zprávy pro každou skupinu příjemců. Metrika odchozích zpráv spočítá celkový počet zpráv, které byly spotřebovány všemi skupinami příjemců. Pokud tedy máte v centru událostí několik skupin příjemců, může se zobrazit větší počet odchozích zpráv než přijaté události.

Související obsah