Inmatningstid för loggdata i Azure Monitor
Azure Monitor är en storskalig datatjänst som betjänar tusentals kunder som skickar terabyte data varje månad i en växande takt. Det finns ofta frågor om den tid det tar för loggdata att bli tillgängliga när de har samlats in. Den här artikeln förklarar de olika faktorer som påverkar den här svarstiden.
Genomsnittlig svarstid
Svarstiden avser den tid då data skapas i det övervakade systemet och den tid då de blir tillgängliga för analys i Azure Monitor. Den genomsnittliga svarstiden för att mata in loggdata är mellan 20 sekunder och 3 minuter. 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 kan delas upp i följande områden på hög nivå:
- Agenttid: 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 hanteras den här processen av en agent. Mer svarstid kan introduceras av nätverket.
- Pipelinetid: Tiden för inmatningspipelinen att bearbeta loggposten. Den här tidsperioden omfattar parsning av händelsens egenskaper och potentiellt tillägg av beräknad information.
- Indexeringstid: Den tid det går att mata in en loggpost i ett stordatalager i Azure Monitor.
Information om de olika svarstider som introduceras i den här processen beskrivs i följande avsnitt.
Svarstid för agentinsamling
Tiden varierar
Agenter och hanteringslösningar använder olika strategier för att samla in data från en virtuell dator, vilket kan påverka svarstiden. Några specifika exempel visas i följande tabell.
| Typ av data | Insamlingsfrekvens | Kommentar |
|---|---|---|
| Windows-händelser, Syslog-händelser och prestandamått | Samlas in omedelbart | |
| Linux-prestandaräknare | Avsökt med 30 sekunders intervall | |
| IIS-loggar och textloggar | Samlas in efter tidsstämpeländringar | För IIS-loggar påverkas det här schemat av det rollover-schema som konfigurerats i IIS. |
| Active Directory Replication-lösning | Utvärdering var femte dag | Agenten samlar endast in loggarna när utvärderingen är klar. |
| Active Directory-utvärderingslösning | Veckovis utvärdering av Active Directory-infrastrukturen | Agenten samlar endast in loggarna när utvärderingen är klar. |
Frekvens för agentuppladdning
Under 1 minut
För att säkerställa att Log Analytics-agenten är enkel buffrar agenten loggarna 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
Varierar
Nätverksvillkoren kan påverka svarstiden för dessa data negativt för att nå en datainsamlingsslutpunkt.
Azure-mått, resursloggar, aktivitetslogg
30 sekunder till 15 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 3 minuter att exportera dem till datainsamlingens slutpunkt.
- Resursloggar lägger vanligtvis till 30 till 90 sekunder, beroende på Azure-tjänsten. Vissa Azure-tjänster (särskilt Azure SQL Database och Azure Virtual Network) rapporterar för närvarande sina loggar med 5 minuters intervall. Arbetet pågår för att förbättra den här gången ytterligare. 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 på 3 till 20 minuter.
Samling hanteringslösningar
Varierar
Vissa lösningar samlar inte in sina data från en agent och kan använda en samlingsmetod som ger mer svarstid. Vissa lösningar samlar in data med jämna mellanrum utan att försöka samla in dem i nära realtid. Några exempel är:
- Microsoft 365-lösningen avsöker aktivitetsloggar med hjälp av API:et för hanteringsaktivitet, som för närvarande inte ger några svarstidsgarantier i nära realtid.
- Windows Analytics-lösningar (till exempel uppdateringsefterlevnad) samlas in av lösningen med en daglig frekvens.
Information om hur du fastställer en lösnings insamlingsfrekvens finns i dokumentationen för varje lösning.
Pipelineprocesstid
30 till 60 sekunder
När data är tillgängliga vid datainsamlingens slutpunkt tar det ytterligare 30 till 60 sekunder att vara tillgänglig för frågor.
När loggposter har matats in i Azure Monitor-pipelinen (som identifieras i egenskapen _TimeReceived ) skrivs de till tillfällig lagring för att säkerställa klientisolering och för att säkerställa att data inte går förlorade. Den här processen lägger vanligtvis till 5 till 15 sekunder.
Vissa lösningar implementerar tyngre algoritmer för att aggregera data och härleda insikter när data strömmas in. Application Insights beräknar till exempel programmappningsdata. Azure Network Performance Monitoring aggregerar inkommande data över 3 minuters intervall, vilket effektivt ger 3 minuters svarstid.
Om datainsamlingen innehåller en inmatningstidstransformering lägger detta till viss svarstid i pipelinen. 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 till loggar som samlas in från filer av agenten.
Etablering av nya anpassade datatyper
När en ny typ av anpassade data skapas från en anpassad logg eller datainsamlarens API skapar systemet en dedikerad lagringscontainer. Den här engångskostnaden inträffar endast vid det första utseendet av den här datatypen.
Skydd mot toppar
Vanligtvis mindre än 1 minut, men kan vara mer
Högsta prioritet för Azure Monitor är att se till att inga kunddata går förlorade, så att systemet har inbyggt skydd för datatoppar. Det här skyddet omfattar buffertar för att säkerställa att systemet fortsätter att fungera även under enorm belastning. Under normal belastning lägger dessa kontroller till mindre än en minut. Under extrema förhållanden och fel kan de lägga till betydande tid samtidigt som data är säkra.
Indexeringstid
5 minuter eller mindre
Det finns en inbyggd balans för varje stordataplattform mellan att tillhandahålla analysfunktioner och avancerade sökfunktioner i stället för att ge omedelbar åtkomst till data. Med Azure Monitor kan du köra kraftfulla frågor på miljarder poster och få resultat inom några sekunder. Den här prestandan är möjlig eftersom infrastrukturen transformerar data dramatiskt under inmatningen och lagrar dem i unika kompakta strukturer. Systemet buffrar data tills tillräckligt många av dem är tillgängliga för att skapa dessa strukturer. Den här processen måste slutföras innan loggposten visas i sökresultaten.
Den här processen tar för närvarande cirka 5 minuter när det finns en låg mängd data, men det kan ta mindre tid vid högre datahastigheter. Det här beteendet verkar kontraintuitivt, men den här processen tillåter optimering av svarstid för produktionsarbetsbelastningar med stora volymer.
Kontrollera inmatningstiden
Inmatningstiden kan variera för olika resurser under olika omständigheter. Du kan använda loggfrågor för att identifiera specifika beteenden i din miljö. Följande tabell anger hur du kan fastställa de olika tiderna för en post när den skapas och skickas till Azure Monitor.
| Steg | Egenskap eller funktion | Kommentarer |
|---|---|---|
| Post som skapats vid datakällan | TimeGenerated Om datakällan inte anger det här värdet anges det till samma tid som _TimeReceived. |
Om värdet tidsgenererat vid bearbetningen är äldre än två dagar tas raden bort. |
| Post som tagits emot av datainsamlingens slutpunkt | _TimeReceived | Det här fältet är inte optimerat för massbearbetning och bör inte användas för att filtrera stora datamängder. |
| Post som lagras på arbetsytan och är tillgänglig för frågor | ingestion_time() | Vi rekommenderar att du använder ingestion_time() om det bara finns ett behov av att filtrera poster som matats in i ett visst tidsfönster. I sådana fall rekommenderar vi även att du lägger till ett TimeGenerated filter med ett större intervall. |
Fördröjningar av inmatningsfördröjning
Du kan mäta svarstiden för en specifik post genom att jämföra resultatet av funktionen ingestion_time() med TimeGenerated egenskapen. Dessa data kan användas med olika aggregeringar för att identifiera hur svarstiden för inmatning fungerar. 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 föregående 8 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-data:
// 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
De två frågorna ovan kan paras ihop med andra Application Insights-tabeller än "begäranden".
Resurser som slutar svara
I vissa fall kan en resurs sluta skicka data. Om du vill veta om en resurs skickar data eller inte kan du titta på den senaste posten, som kan identifieras av standardfältet TimeGenerated .
Använd tabellen Heartbeat för att kontrollera tillgängligheten för en virtuell dator eftersom ett pulsslag skickas en gång i minuten av agenten. Använd följande fråga för att lista de aktiva datorer som inte har rapporterat 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