Loggdatainmatningstid i Azure Monitor

Azure Monitor är en storskalig datatjänst som skickar terabyte data varje månad och fortsätter att växa. Under vanliga driftsförhållanden är tiden det tar för loggdata att bli tillgänglig efter insamling förutsägbar och konsekvent. Den här artikeln förklarar de faktorer som påverkar den här svarstiden.

Genomsnittlig svarstid

Svarstiden avser tiden mellan när data skapas i det övervakade systemet och när de blir tillgängliga för analys i Azure Monitor. Den genomsnittliga svarstiden för att mata in loggdata är mindre än 10 sekunder. Den specifika svarstiden för vissa data varierar beroende på flera faktorer som förklaras i den här artikeln.

Faktorer som påverkar svarstiden

Den totala inmatningstiden för en viss uppsättning data är den kumulativa tiden från klienten till Azure Monitor-tjänsten.

Arkitekturdiagram över Azure Monitor-inmatningsprocessen.

• Klienttid: Tiden för att identifiera en händelse, samla in den och sedan skicka den till en datainsamlingsslutpunkt som en loggpost. I de flesta fall hanterar en agent som Azure Monitor Agent (AMA) den här processen. Anpassade program som använder API:et för logginmatning ingår inte i den här artikelns beräkningar, men de kan ha sina egna svarstidsegenskaper som liknar AMA-klienttiden.
• Azure Monitor-tid: När klienten överförs till Azure Monitor är tiden för inmatning att bearbeta loggposten. Den här tidsperioden omfattar parsning av händelsens egenskaper och potentiellt tillägg av beräknad information.

I följande avsnitt beskrivs de olika svarstider som introduceras i den här processen.

Latens för agentinsamling

Svarstid: Tiden varierar

Agenter använder olika strategier för att samla in data, vilket kan påverka svarstiden. Några specifika exempel visas i följande tabell.

Typ av data	Insamlingsfrekvens	Anteckningar
Windows-händelser, Syslog-händelser och prestandamått	Samlas omedelbart
Linux-prestandaräknare	Avsökt med 30 sekunders intervall
IIS-loggar och textloggar	Samlas in efter att deras tidsstämplar ändras	För IIS-loggar påverkas det här schemat av det rollover-schema som konfigurerats i IIS.

Mer information om agentprestanda finns i Azure Övervaka agentprestanda.

Frekvens för agentuppladdning

Svarstid: Under 1 minut

För att hålla Azure Monitor Agent lätt, buffrar den loggar och laddar regelbundet upp dem till Azure Monitor. Uppladdningsfrekvensen varierar mellan 30 sekunder och 2 minuter beroende på typen av data. De flesta data laddas upp på under 1 minut.

Nätverk

Svarstid: Varierar

Nätverket mellan en klient och Azure Monitor-datainsamlingsslutpunkten kan medföra oväntade fördröjningar. När du mäter svarstiden för inmatning inkluderas den här nätverksfördröjningen AgentLatency som en del av beräkningen i exempelfrågorna i avsnittet svarstid för måttinmatning .

Azure mätvärden, resursloggar, aktivitetsloggar

Svarstid: 30 sekunder till 20 minuter

Azure data lägger till mer tid för att bli tillgängliga vid en datainsamlingsslutpunkt för bearbetning:

• Azure plattformsmått är tillgängliga på under en minut i måttdatabasen, men det tar ytterligare tre minuter att exportera dem till datainsamlingens slutpunkt.
• Resource-loggar är vanligtvis tillgängliga inom 3 till 10 minuter från slutpunkt till slutpunkt, beroende på tjänstens komplexitet och de Azure tjänster som ingår. Till exempel tillhandahåller Azure SQL Database och Azure Virtual Network för närvarande sina loggar var femte minut. Om du vill undersöka den här svarstiden i din miljö kan du läsa följande fråga.
• Aktivitetsloggar är tillgängliga för analys och aviseringar på 3 till 20 minuter.

Azure Övervaka processtid

Svarstid: Mindre än 10 sekunder

När data når datainsamlingens slutpunkt tar det mindre än 10 sekunder innan du kan köra frågor mot dem.

När Azure Monitor matar in loggposter (som egenskapen _TimeReceived visar) skriver den dem till tillfällig lagring. Det här steget säkerställer klientisolering och förhindrar dataförlust. Det här steget lägger vanligtvis till 5 till 15 sekunder.

Vissa lösningar använder mer komplexa algoritmer för att aggregera data och härleda insikter medan data strömmar in. Till exempel, beräknar Application Insights programkartsdata. Azure Network Performance Monitoring aggregerar inkommande data över tre minuters intervall, vilket i praktiken lägger till tre minuters svarstid i det här fallet.

Om datainsamlingen innehåller en ingestion-time-transformering lägger den här omvandlingen till viss latens till Azure Monitor-procestiden. Använd måttet Logs Transformation Duration per Min för att övervaka effektiviteten i transformeringsfrågan.

En annan process som lägger till svarstid är den process som hanterar anpassade loggar. I vissa fall kan den här processen lägga till några minuters svarstid i loggar som en agent samlar in från filer.

Etablering av nya anpassade datatyper

När en ny typ av anpassade data skapas från en anpassad logg eller Logs inmatnings-API skapar systemet en dedikerad storage container. Den här engångsbelastningen inträffar endast vid den första förekomsten av den här datatypen.

Kontrollera inmatningstiden

Inmatningstiden kan variera för olika resurser under olika omständigheter. Använd loggfrågor för att identifiera specifika beteenden i din miljö. Följande tabell visar hur du bestämmer de olika tiderna för en loggpost när den skapas och skickas till Azure Monitor. Mer information om loggfrågor finns i Översikt över Log Analytics.

Steg	Egenskap eller funktion	Kommentarer
Uppgift skapad från datakällan	TimeGenerated	Värdet TimeGenerated får inte vara längre än två dagar före den mottagna tiden eller mer än en dag i framtiden. Annars ersätter Azure Monitor Logs värdet TimeGenerated med den faktiska mottagna tiden. Om datakällan inte anger det här värdet anger Azure Övervakningsloggar värdet till samma tid som _TimeReceived.
Post mottagen av datainsamlingens ändpunkt	_TimeReceived	Använd inte det här fältet för att filtrera stora datamängder. Den är inte optimerad för massbearbetning.
Post som lagras på arbetsytan och är tillgänglig för frågor	ingestion_time()	Använd ingestion_time() om du endast behöver filtrera poster som har matats in inom ett specifikt tidsfönster. I sådana fall lägger du också till ett TimeGenerated filter med ett större intervall.

Mäta svarstid för inmatning

Mät svarstiden för en specifik post när du jämför resultatet av funktionen ingestion_time() med egenskapen TimeGenerated. Upptäck hur svarstid för inmatning fungerar när du använder olika aggregeringar av dessa data. Granska någon percentil av inmatningstiden för att få insikter om stora mängder data.

Följande fråga visar till exempel vilka datorer som hade den högsta inmatningstiden under de senaste åtta timmarna:

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

Föregående percentilkontroller är bra för att hitta allmänna trender i svarstid. Om du vill identifiera en kortsiktig ökning av svarstiden kan det vara effektivare att använda maxvärdet (max()).

Om du vill öka detaljnivån för inmatningstiden för en viss dator under en viss tidsperiod använder du följande fråga, som även visualiserar data från den senaste dagen i ett diagram:

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

Använd följande fråga för att visa datorns inmatningstid efter det land/den region där de finns, vilket baseras på deras IP-adress:

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

Olika datatyper som kommer från agenten kan ha olika svarstid för inmatning, så tidigare frågor kan användas med andra typer. Använd följande fråga för att undersöka inmatningstiden för olika Azure tjänster:

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

Använd samma frågelogik för att diagnostisera svarstidsvillkor för Application Insights-loggbaserade mått:

// Workspace-based Application Insights schema
// This query can be paired with any other Application Insights table other than "requests"
let start=datetime("2026-01-21 05:00:00");
let end=datetime("2026-01-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

Resurser som slutar svara

I vissa fall slutar en resurs att skicka data. Om du vill veta om en resurs skickar data kontrollerar du den senaste posten, som standardfältet TimeGenerated identifierar.

Använd tabellen Heartbeat för att kontrollera tillgängligheten för en virtuell dator eftersom agenten skickar ett pulsslag en gång i minuten. Använd följande fråga för att visa en lista över aktiva datorer som inte har rapporterat ett pulsslag nyligen:

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 

Nästa steg

Läs avtalet på servicenivå för Azure Monitor.