Opnametijd van gegevens vastleggen in een logboek in Azure Monitor

Artikel
10/16/2024

Azure Monitor is een grootschalige gegevensservice die duizenden klanten bedient die elke maand terabytes aan gegevens verzenden. Er zijn vaak vragen over de tijd die nodig is om logboekgegevens beschikbaar te maken nadat ze zijn verzameld. In dit artikel worden de verschillende factoren uitgelegd die van invloed zijn op deze latentie.

Gemiddelde latentie

Latentie verwijst naar het tijdstip waarop gegevens worden gemaakt op het bewaakte systeem en de tijd die deze beschikbaar is voor analyse in Azure Monitor. De gemiddelde latentie voor het opnemen van logboekgegevens ligt tussen 20 seconden en 3 minuten. De specifieke latentie voor bepaalde gegevens varieert, afhankelijk van verschillende factoren die in dit artikel worden uitgelegd.

Factoren die van invloed zijn op latentie

De totale opnametijd voor een bepaalde set gegevens kan worden onderverdeeld in de volgende gebieden op hoog niveau:

Agenttijd: het moment om een gebeurtenis te detecteren, te verzamelen en deze vervolgens als logboekrecord naar een eindpunt voor gegevensverzameling te verzenden. In de meeste gevallen wordt dit proces verwerkt door een agent. Er kan meer latentie worden geïntroduceerd door het netwerk.
Pijplijntijd: de tijd voor de opnamepijplijn om de logboekrecord te verwerken. Deze periode omvat het parseren van de eigenschappen van de gebeurtenis en het toevoegen van berekende informatie.
Indexeringstijd: de tijd die is besteed aan het opnemen van een logboekrecord in een Big Data-archief van Azure Monitor.

Details over de verschillende latentie die in dit proces is geïntroduceerd, worden beschreven in de volgende secties.

Verzamelingslatentie van agent

Tijd varieert

Agents en beheeroplossingen gebruiken verschillende strategieën om gegevens van een virtuele machine te verzamelen, wat de latentie kan beïnvloeden. Enkele specifieke voorbeelden worden vermeld in de volgende tabel.

Type gegevens	Verzamelingsfrequentie	Opmerkingen
Windows-gebeurtenissen, Syslog-gebeurtenissen en metrische prestatiegegevens	Onmiddellijk verzameld
Linux-prestatiemeteritems	Polled met intervallen van 30 seconden
IIS-logboeken en tekstlogboeken	Verzameld na het wijzigen van de tijdstempel	Voor IIS-logboeken wordt deze planning beïnvloed door het rollover-schema dat is geconfigureerd op IIS.
Active Directory-replicatieoplossing	Evaluatie om de vijf dagen	De agent verzamelt de logboeken alleen wanneer de evaluatie is voltooid.
Oplossing voor Active Directory-evaluatie	Wekelijkse evaluatie van uw Active Directory-infrastructuur	De agent verzamelt de logboeken alleen wanneer de evaluatie is voltooid.

Uploadfrequentie van agent

Minder dan 1 minuut

Om ervoor te zorgen dat de Log Analytics-agent lichtgewicht is, buffert de agent logboeken en uploadt deze periodiek naar Azure Monitor. De uploadfrequentie varieert tussen 30 seconden en 2 minuten, afhankelijk van het type gegevens. De meeste gegevens worden in minder dan 1 minuut geüpload.

Netwerk

Varieert

Netwerkvoorwaarden kunnen een negatieve invloed hebben op de latentie van deze gegevens om een eindpunt voor gegevensverzameling te bereiken.

Metrische gegevens van Azure, resourcelogboeken, activiteitenlogboek

30 seconden tot 15 minuten

Met Azure-gegevens wordt meer tijd toegevoegd om beschikbaar te worden op een eindpunt voor gegevensverzameling voor verwerking:

Metrische gegevens van het Azure-platform zijn binnen een minuut beschikbaar in de database met metrische gegevens , maar het duurt nog 3 minuten voordat ze worden geëxporteerd naar het eindpunt voor gegevensverzameling.
Resourcelogboeken voegen doorgaans 30 tot 90 seconden toe, afhankelijk van de Azure-service. Sommige Azure-services (met name Azure SQL Database en Azure Virtual Network) rapporteren momenteel hun logboeken met intervallen van vijf minuten. Er wordt gewerkt om deze tijd verder te verbeteren. Als u deze latentie in uw omgeving wilt onderzoeken, raadpleegt u de volgende query.
Activiteitenlogboeken zijn in 3 tot 20 minuten beschikbaar voor analyse.

Verzameling beheeroplossingen

Varieert

Sommige oplossingen verzamelen hun gegevens niet van een agent en maken mogelijk gebruik van een verzamelingsmethode die meer latentie introduceert. Sommige oplossingen verzamelen regelmatig gegevens zonder bijna realtime te verzamelen. Voorbeelden van specifieke voorbeelden zijn:

Microsoft 365-oplossing peilt activiteitenlogboeken met behulp van de Management Activity-API, die momenteel geen bijna realtime latentiegaranties biedt.
Windows Analytics-oplossingen (bijvoorbeeld updatecompatibiliteit) worden met een dagelijkse frequentie verzameld door de oplossing.

Als u de verzamelingsfrequentie van een oplossing wilt bepalen, raadpleegt u de documentatie voor elke oplossing.

Tijd van pijplijnproces

30 tot 60 seconden

Nadat de gegevens beschikbaar zijn op het eindpunt voor gegevensverzameling, duurt het nog 30 tot 60 seconden om query's uit te voeren.

Nadat logboekrecords zijn opgenomen in de Azure Monitor-pijplijn (zoals aangegeven in de eigenschap _TimeReceived ), worden ze naar tijdelijke opslag geschreven om tenantisolatie te garanderen en ervoor te zorgen dat gegevens niet verloren gaan. Dit proces telt doorgaans 5 tot 15 seconden op.

Sommige oplossingen implementeren zwaardere algoritmen om gegevens te aggregeren en inzichten af te leiden naarmate gegevens worden gestreamd. Application Insights berekent bijvoorbeeld toepassingstoewijzingsgegevens; Met Azure Network Performance Monitoring worden binnenkomende gegevens geaggregeerd via intervallen van drie minuten, waardoor er effectief een latentie van 3 minuten wordt toegevoegd.

Als de gegevensverzameling een opnametijdtransformatie bevat, wordt er enige latentie toegevoegd aan de pijplijn. Gebruik de transformatieduur van metrische logboeken per min om de efficiëntie van de transformatiequery te bewaken.

Een ander proces dat latentie toevoegt, is het proces dat aangepaste logboeken verwerkt. In sommige gevallen kan dit proces enkele minuten latentie toevoegen aan logboeken die door de agent worden verzameld uit bestanden.

Nieuwe aangepaste gegevenstypen inrichten

Wanneer een nieuw type aangepaste gegevens wordt gemaakt op basis van een aangepast logboek of de Data Collector-API, maakt het systeem een toegewezen opslagcontainer. Deze eenmalige overhead treedt alleen op bij het eerste uiterlijk van dit gegevenstype.

Overspanningsbeveiliging

Meestal minder dan 1 minuut, maar kan meer zijn

De hoogste prioriteit van Azure Monitor is ervoor te zorgen dat er geen klantgegevens verloren gaan, dus het systeem heeft ingebouwde beveiliging voor gegevenspieken. Deze beveiliging omvat buffers om ervoor te zorgen dat zelfs onder enorme belasting het systeem blijft functioneren. Bij normale belasting voegen deze besturingselementen minder dan een minuut toe. In extreme omstandigheden en fouten kunnen ze aanzienlijke tijd toevoegen en ervoor zorgen dat gegevens veilig zijn.

Indexeringstijd

5 minuten of minder

Er is een ingebouwde balans voor elk big data-platform tussen het bieden van analyses en geavanceerde zoekmogelijkheden in plaats van directe toegang tot de gegevens. Met Azure Monitor kunt u krachtige query's uitvoeren op miljarden records en binnen enkele seconden resultaten ophalen. Deze prestaties worden mogelijk gemaakt omdat de infrastructuur de gegevens tijdens de opname aanzienlijk transformeert en opslaat in unieke compacte structuren. Het systeem buffert de gegevens totdat er voldoende beschikbaar is om deze structuren te maken. Dit proces moet worden voltooid voordat de logboekrecord wordt weergegeven in zoekresultaten.

Dit proces duurt momenteel ongeveer 5 minuten wanneer er een laag aantal gegevens is, maar het kan minder tijd in beslag nemen bij hogere gegevenssnelheden. Dit gedrag lijkt contra-intuïtief, maar met dit proces kan de latentie voor productieworkloads met een hoog volume worden geoptimaliseerd.

Opnametijd controleren

De opnametijd kan variëren voor verschillende resources onder verschillende omstandigheden. U kunt logboekquery's gebruiken om specifiek gedrag van uw omgeving te identificeren. In de volgende tabel wordt aangegeven hoe u de verschillende tijden voor een record kunt bepalen terwijl deze wordt gemaakt en verzonden naar Azure Monitor.

Stap	Eigenschap of functie	Opmerkingen
Record gemaakt bij gegevensbron	TimeGenerated Als de gegevensbron deze waarde niet instelt, wordt deze ingesteld op hetzelfde tijdstip als _TimeReceived.	Als tijdens de verwerking de tijd gegenereerde waarde ouder is dan twee dagen, wordt de rij verwijderd.
Record ontvangen door het eindpunt voor gegevensverzameling	_TimeReceived	Dit veld is niet geoptimaliseerd voor massaverwerking en mag niet worden gebruikt om grote gegevenssets te filteren.
Record opgeslagen in werkruimte en beschikbaar voor query's	ingestion_time()	U wordt aangeraden `ingestion_time()` alleen records te filteren die in een bepaald tijdvenster zijn opgenomen. In dergelijke gevallen wordt u aangeraden ook een `TimeGenerated` filter met een groter bereik toe te voegen.

Vertragingen in opnamelatentie

U kunt de latentie van een specifieke record meten door het resultaat van de functie ingestion_time() te vergelijken met de TimeGenerated eigenschap. Deze gegevens kunnen worden gebruikt met verschillende aggregaties om te ontdekken hoe opnamelatentie zich gedraagt. Bekijk een percentiel van de opnametijd om inzichten te verkrijgen voor grote hoeveelheden gegevens.

In de volgende query ziet u bijvoorbeeld welke computers de hoogste opnametijd hadden in de afgelopen 8 uur:

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

De voorgaande percentielcontroles zijn goed voor het vinden van algemene trends in latentie. Om een korte piek in latentie te identificeren, kan het gebruik van het maximum (max()) effectiever zijn.

Als u wilt inzoomen op de opnametijd voor een specifieke computer gedurende een bepaalde periode, gebruikt u de volgende query, waarmee ook de gegevens van de afgelopen dag in een grafiek worden gevisualiseerd:

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

Gebruik de volgende query om de opnametijd van de computer weer te geven per land/regio waar ze zich bevinden, die is gebaseerd op hun IP-adres:

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

Verschillende gegevenstypen die afkomstig zijn van de agent, hebben mogelijk een andere latentietijd voor opname, zodat de vorige query's kunnen worden gebruikt met andere typen. Gebruik de volgende query om de opnametijd van verschillende Azure-services te onderzoeken:

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

Gebruik dezelfde querylogica om latentievoorwaarden voor Application Insights-gegevens te diagnosticeren:

// 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 twee bovenstaande query's kunnen worden gekoppeld aan andere Application Insights-tabellen dan 'aanvragen'.

Resources die niet meer reageren

In sommige gevallen kan een resource stoppen met het verzenden van gegevens. Als u wilt weten of een resource gegevens verzendt of niet, bekijkt u de meest recente record, die kan worden geïdentificeerd door het standaardveld TimeGenerated .

Gebruik de Heartbeat tabel om de beschikbaarheid van een VIRTUELE machine te controleren omdat een heartbeat eenmaal per minuut door de agent wordt verzonden. Gebruik de volgende query om de actieve computers weer te geven die onlangs geen heartbeat hebben gerapporteerd:

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

Volgende stappen

Lees de serviceovereenkomst voor Azure Monitor.

Share via