Protokolování času pro příjem dat ve službě Azure Monitor

Azure Monitor je vysoce škálovaná datová služba, která obsluhuje tisíce zákazníků, kteří každý měsíc odesílají terabajty dat. Často se ptají, jak dlouho trvá, než se data protokolu po shromáždění zpřístupní. Tento článek vysvětluje různé faktory, které ovlivňují tuto latenci.

Průměrná latence

Latence označuje čas vytvoření dat v monitorovaném systému a čas, kdy jsou k dispozici pro analýzu ve službě Azure Monitor. Průměrná latence ingestování dat protokolu je mezi 20 sekund a 3 minuty. Konkrétní latence pro všechna konkrétní data se bude lišit v závislosti na několika faktorech, které jsou vysvětleny v tomto článku.

Faktory ovlivňující latenci

Celkovou dobu příjmu dat pro určitou sadu dat je možné rozdělit do následujících oblastí vysoké úrovně:

• Čas agenta: Čas zjištění události, jeho shromáždění a následné odeslání do koncového bodu shromažďování dat jako záznam protokolu. Ve většině případů tento proces zpracovává agent. Síť může zavést větší latenci.
• Čas kanálu: Čas, kdy kanál příjmu dat zpracuje záznam protokolu. Toto časové období zahrnuje analýzu vlastností události a potenciálně přidání počítaných informací.
• Doba indexování: Doba strávená ingestováním záznamu protokolu do úložiště velkých objemů dat ve službě Azure Monitor.

Podrobnosti o různých latencích zavedených v tomto procesu jsou popsány v následujících částech.

Latence shromažďování agenta

Čas se liší

Agenti a řešení pro správu používají různé strategie ke shromažďování dat z virtuálního počítače, což může mít vliv na latenci. Některé konkrétní příklady jsou uvedeny v následující tabulce.

Frekvence nahrávání agenta

Méně než 1 minuta

Aby se zajistilo, že je agent Log Analytics odlehčený, ukládá do vyrovnávací paměti protokoly a pravidelně je nahrává do služby Azure Monitor. Frekvence nahrávání se liší mezi 30 sekund a 2 minuty v závislosti na typu dat. Většina dat se nahrává do 1 minuty.

Síť

Liší se

Síťové podmínky můžou negativně ovlivnit latenci těchto dat, aby se dosáhlo koncového bodu shromažďování dat.

Metriky Azure, protokoly prostředků, protokol aktivit

30 sekund až 15 minut

Data Azure přidají více času, než se zpřístupní v koncovém bodu shromažďování dat ke zpracování:

• Metriky platformy Azure jsou v databázi metrik dostupné za méně než minutu, ale jejich export do koncového bodu shromažďování dat trvá dalších 3 minuty.
• Protokoly prostředků obvykle přidávají 30 až 90 sekund v závislosti na službě Azure. Některé služby Azure (konkrétně Azure SQL Database a Azure Virtual Network) v současné době hlásí své protokoly v 5minutových intervalech. Práce probíhá, aby se tento čas dále zlepšila. Pokud chcete zjistit tuto latenci ve vašem prostředí, podívejte se na následující dotaz.
• Protokoly aktivit jsou k dispozici pro analýzu za 3 až 20 minut.

Kolekce řešení pro správu

Liší se

Některá řešení neshromažďují data z agenta a můžou používat metodu shromažďování, která představuje vyšší latenci. Některá řešení shromažďují data v pravidelných intervalech bez pokusů o shromažďování téměř v reálném čase. Mezi konkrétní příklady patří:

• Řešení Microsoft 365 se dotazuje na protokoly aktivit pomocí rozhraní API pro aktivity správy, které v současné době neposkytuje záruky latence téměř v reálném čase.
• Řešení Windows Analytics (například Update Compliance) data shromažďuje řešení s denní frekvencí.

Pokud chcete zjistit četnost shromažďování řešení, prohlédni si dokumentace pro každé řešení.

Čas zpracování kanálu

30 až 60 sekund

Jakmile jsou data dostupná v koncovém bodu shromažďování dat, trvá další 30 až 60 sekund, než bude k dispozici pro dotazování.

Po ingestování záznamů protokolu do kanálu služby Azure Monitor (jak je uvedeno v _TimeReceived vlastnosti), zapisují se do dočasného úložiště, aby se zajistila izolace tenanta a zajistilo se, že se data neztratí. Tento proces obvykle přidává 5 až 15 sekund.

Některá řešení implementují těžší algoritmy pro agregaci dat a odvozování přehledů při streamování dat. Application Insights například vypočítá data mapování aplikací; Azure Network Sledování výkonu agreguje příchozí data v 3minutových intervalech, což efektivně zvyšuje 3minutovou latenci.

Pokud shromažďování dat zahrnuje transformaci v čase příjmu dat, přidá se do kanálu určitá latence. K monitorování efektivity transformačního dotazu použijte dobu transformace protokolů metriky na minimum .

Dalším procesem, který přidává latenci, je proces, který zpracovává vlastní protokoly. V některýchpřípadechch

Zřizování nových vlastních datových typů

Když se vytvoří nový typ vlastních dat z vlastního protokolu nebo rozhraní API kolektoru dat, vytvoří systém vyhrazený kontejner úložiště. Tato jednorázová režie se vyskytuje pouze u prvního vzhledu tohoto datového typu.

Ochrana proti přepětí

Obvykle méně než 1 minutu, ale může být více

Hlavní prioritou služby Azure Monitor je zajistit, aby se neztratila žádná zákaznická data, takže systém má integrovanou ochranu proti nárůstům dat. Tato ochrana zahrnuje vyrovnávací paměti, aby se zajistilo, že i při obrovském zatížení bude systém fungovat. Pod normálním zatížením tyto ovládací prvky přidají méně než minutu. V extrémních podmínkáchach

Čas indexování

5 minut nebo méně

Existuje integrovaný zůstatek pro každou platformu pro velké objemy dat mezi poskytováním analytických a pokročilých možností vyhledávání, a nikoli okamžitým přístupem k datům. Pomocí služby Azure Monitor můžete spouštět výkonné dotazy na miliardy záznamů a získat výsledky během několika sekund. Tento výkon je možný, protože infrastruktura transformuje data dramaticky během příjmu dat a ukládá je do jedinečných kompaktních struktur. Systém uloží data do vyrovnávací paměti, dokud nebude k dispozici dostatek k vytvoření těchto struktur. Tento proces musí být dokončen před zobrazením záznamu protokolu ve výsledcích hledání.

Tento proces v současné době trvá přibližně 5 minut, když je nízký objem dat, ale může trvat méně času s vyššími rychlostmi dat. Toto chování vypadá jako neintuitivní, ale tento proces umožňuje optimalizaci latence pro úlohy v produkčním prostředí s velkým objemem.

Kontrola času příjmu dat

Doba příjmu dat se může lišit pro různé prostředky za různých okolností. Dotazy protokolu můžete použít k identifikaci konkrétního chování vašeho prostředí. Následující tabulka určuje, jak můžete určit různé časy záznamu při jeho vytvoření a odeslání do služby Azure Monitor.

Zpoždění latence příjmu dat

Latenci konkrétního záznamu můžete měřit porovnáním výsledku funkce ingestion_time() s TimeGenerated vlastností. Tato data je možné použít s různými agregacemi a zjistit, jak se latence příjmu dat chová. Prozkoumejte určitý percentil doby příjmu dat a získejte přehledy o velkých objemech dat.

Například následující dotaz vám ukáže, které počítače měly nejvyšší dobu příjmu dat za předchozích 8 hodin:

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

Předchozí kontroly percentilu jsou vhodné pro vyhledání obecných trendů v latenci. Pokud chcete identifikovat krátkodobou špičku latence, může být použití maxima (max()) efektivnější.

Pokud chcete přejít k podrobnostem o čase příjmu dat pro určitý počítač v určitém časovém období, použijte následující dotaz, který také vizualizuje data z posledního dne v grafu:

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

Pomocí následujícího dotazu můžete zobrazit čas příjmu dat počítače podle země nebo oblasti, kde se nachází, což je založené na jejich IP adrese:

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry 

Různé datové typy pocházející z agenta můžou mít různou dobu latence příjmu dat, takže předchozí dotazy je možné použít s jinými typy. K prozkoumání doby příjmu různých služeb Azure použijte následující dotaz:

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

K diagnostice podmínek latence dat Application Insights použijte stejnou logiku dotazu:

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

Výše uvedené dva dotazy je možné spárovat s jakoukoli jinou tabulkou Application Insights než "requests".

Prostředky, které přestanou reagovat

V některých případech může prostředek přestat odesílat data. Pokud chcete zjistit, jestli prostředek odesílá data nebo ne, podívejte se na nejnovější záznam, který je možné identifikovat standardním TimeGenerated polem.

Heartbeat Pomocí tabulky můžete zkontrolovat dostupnost virtuálního počítače, protože agent odešle prezenčních signálů jednou za minutu. Pomocí následujícího dotazu zobrazte seznam aktivních počítačů, které v poslední době nenahlásily prezenčních signálů:

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc 

Další kroky

Přečtěte si smlouvu o úrovni služeb pro Azure Monitor.