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

Azure Monitor je vysoce škálovatá datová služba pro tisíce zákazníků, kteří každý měsíc odesílají terabajty dat a stále rostou. Pochopení doby, kterou trvá, než se data protokolu po shromáždění zpřístupní, a faktory, které ovlivňují tuto latenci, jsou konceptem, který vysvětluje tento článek.

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 zpracování v datovém kanálu: Čas pro zpracování záznamu protokolu v kanálu příjmu dat. 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 sběru dat 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.

Typ dat	Četnost shromažďování dat	Poznámky
Události Systému Windows, události Syslogu a metriky výkonu	Okamžitě sbíráno
Čítače výkonu Linuxu	Dotazováno v 30sekundových intervalech
Protokoly služby IIS a textové protokoly	Shromážděno po změnách jejich časového razítka	U protokolů služby IIS je tento plán ovlivněn plánem přechodu nakonfigurovaným ve službě IIS.
Řešení replikace služby Active Directory	Posouzení každých pět dnů	Agent shromažďuje protokoly pouze po dokončení posouzení.
Řešení posouzení služby Active Directory	Týdenní posouzení infrastruktury služby Active Directory	Agent shromažďuje protokoly pouze po dokončení posouzení.

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 zdrojů, protokoly aktivit

30 sekund až 20 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íhají na dalším zlepšení této doby. 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 a upozorňování 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 provádí dotazování na protokoly aktivit pomocí rozhraní API pro aktivity správy, které v současné době neposkytuje záruky latence v téměř reálném čase.
• Řešení Windows Analytics, například Update Compliance, shromažďuje data s denní frekvencí.

Chcete-li zjistit četnost shromažďování řešení, podívejte se na dokumentaci pro každé řešení.

Čas zpracování potrubí

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 zpracování záznamů logových protokolů do kanálu služby Azure Monitor (jak je uvedeno ve vlastnosti _TimeReceived) jsou zapisovány do dočasného úložiště, aby se zajistila izolace tenanta a zajištění, ž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í a Sledování výkonu sítě Azure agreguje příchozí data každé 3 minuty, což účinně přidává 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 dotazu transformace použijte metrickou hodnotu Doba transformace protokolů za minutu.

Dalším procesem, který přidává latenci, je proces, který zpracovává vlastní protokoly. V některých případech může tento proces přidat několik minut zpoždění do protokolů, které agent shromažďuje ze souborů.

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

Když se vytvoří nový typ vlastních dat z vlastního protokolu záznamů nebo API kolektoru dat, vytvoří systém vyhrazený kontejner úložiště. Tento jednorázový náklad se vyskytuje pouze při prvním vyskytnutí 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ách a při selháních mohou přidat výrazný čas, přičemž zajišťují bezpečnost dat.

Čas indexování

5 minut nebo méně

Existuje integrovaná rovnováha pro každou platformu pro velké objemy dat mezi poskytováním analytických a pokročilých možností vyhledávání a zajištěním okamžitého přístupu 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 ukládá data do vyrovnávací paměti, dokud není k dispozici dostatek dat 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

Doba příjmu dat se může lišit pro různé prostředky za různých okolností. Pomocí dotazů protokolu identifikujte konkrétní 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. Další informace o dotazech protokolu najdete v tématu Přehled služby Log Analytics.

Výstraha

Při zanášení protokolů do pomocné úrovně služby Azure Monitor se vyhněte odeslání jedné datové části obsahující časová razítka TimeGenerated, která překračují 30 minut v rámci jednoho volání rozhraní API. Toto volání rozhraní API může vést k následujícímu kódu chyby příjmu dat RecordsTimeRangeIsMoreThan30Minutes. Jedná se o známé omezení, které bude odstraněno.

Toto omezení neplatí pro pomocné protokoly, které používají transformace.

Krok	Vlastnost nebo funkce	Komentáře
Záznam vytvořený ve zdroji dat	TimeGenerated	Hodnota TimeGenerated nemůže být starší než dva dny před časem přijetí nebo více než den do budoucnosti. V opačném případě nahradí protokoly služby Azure Monitor hodnotu TimeGenerated skutečným přijatým časem. Pokud zdroj dat tuto hodnotu nenastaví, nastaví protokoly služby Azure Monitor hodnotu na stejný čas jako _TimeReceived.
Záznam přijatý koncovým bodem shromažďování dat	_Čas_přijetí	Toto pole není optimalizované pro hromadné zpracování a nemělo by se používat k filtrování velkých datových sad.
Záznam uložený v pracovním prostoru a dostupný pro dotazy	ingestion_time()	Doporučujeme použít ingestion_time() , pokud je potřeba filtrovat jenom záznamy, které se ingestovaly v určitém časovém intervalu. V takových případech doporučujeme přidat TimeGenerated filtr s větším rozsahem.

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.

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

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.