Time di inserimento dati in Monitoraggio di Azure

Monitoraggio di Azure è un servizio dati su larga scala che serve migliaia di clienti che inviano terabyte di dati ogni mese a un ritmo crescente. Spesso sono state poste domande sul tempo necessario affinché i dati di log diventino disponibili dopo la raccolta. Questo articolo illustra i diversi fattori che influiscono su questa latenza.

Latenza media

La latenza si riferisce al tempo in cui i dati vengono creati nel sistema monitorato e al tempo necessario affinché diventino disponibili per l'analisi in Monitoraggio di Azure. La latenza media per l'inserimento dei dati di log è compresa tra 20 secondi e 3 minuti. La latenza specifica per tutti i dati specifici varia a seconda di diversi fattori illustrati in questo articolo.

Fattori che influiscono sulla latenza

Il tempo totale di inserimento per un determinato set di dati può essere suddiviso nelle seguenti aree di alto livello:

• Tempo dell'agente: il tempo necessario per individuare un evento, raccoglierlo e inviarlo all'endpoint di raccolta dati come record di log. Nella maggior parte dei casi, questo processo viene gestito da un agente. Una maggiore latenza potrebbe essere introdotta dalla rete.
• Tempo della pipeline: il tempo necessario alla pipeline di inserimento per elaborare il record di log. Questo periodo di tempo include l'analisi delle proprietà dell'evento e l'aggiunta potenziale di informazioni calcolate.
• Tempo di indicizzazione: il tempo impiegato per inserire un record di log in un archivio per Big Data di Monitoraggio di Azure.

Le informazioni dettagliate sulle diverse latenza introdotte in questo processo sono descritte nelle sezioni seguenti.

Latenza di raccolta degli agenti

Tempo variabile

Gli agenti e le soluzioni di gestione usano diverse strategie per raccogliere i dati da una macchina virtuale, che potrebbero influire sulla latenza. Alcuni esempi specifici sono elencati nella tabella seguente.

Frequenza di caricamento dell'agente

Meno di 1 minuto

Per assicurarsi che l'agente di Log Analytics sia leggero, l'agente memorizza nel buffer i log e li carica periodicamente in Monitoraggio di Azure. La frequenza di caricamento varia tra 30 secondi e 2 minuti a seconda del tipo di dati. La maggior parte dei dati viene caricata in meno di 1 minuto.

Rete

Variabile

Le condizioni di rete potrebbero influire negativamente sulla latenza di questi dati per raggiungere un endpoint di raccolta dati.

Metriche di Azure, log delle risorse, log attività

Da 30 secondi a 15 minuti

I dati di Azure aggiungono più tempo per diventare disponibili in un endpoint di raccolta dati per l'elaborazione:

• Le metriche della piattaforma Azure sono disponibili in meno di un minuto nel database delle metriche, ma richiedono altri 3 minuti per l'esportazione nell'endpoint di raccolta dati.
• I log delle risorse in genere aggiungono da 30 a 90 secondi, a seconda del servizio di Azure. Alcuni servizi di Azure (in particolare, il database SQL di Azure e la rete virtuale di Azure) segnalano attualmente i log a intervalli di 5 minuti. Il lavoro è in corso per migliorare ulteriormente questo tempo. Per esaminare questa latenza nell'ambiente, vedere la query che segue.
• I log attività sono disponibili per l'analisi in 3-20 minuti.

Raccolta delle soluzioni di gestione

Variabile

Alcune soluzioni non raccolgono i dati da un agente e potrebbero usare un metodo di raccolta che introduce una latenza maggiore. Alcune soluzioni raccolgono dati a intervalli regolari senza tentare di eseguire la raccolta quasi in tempo reale. Esempi specifici includono:

• La soluzione Microsoft 365 esegue il polling dei log attività usando l'API Management Activity, che attualmente non fornisce garanzie di latenza quasi in tempo reale.
• I dati delle soluzioni di Windows Analytics, ad esempio Conformità aggiornamenti, vengono raccolti dalla soluzione con frequenza giornaliera.

Per determinare la frequenza di raccolta di una soluzione, vedere la documentazione per ogni soluzione.

Tempo di elaborazione della pipeline

Da 30 a 60 secondi

Dopo che i dati sono disponibili nell'endpoint di raccolta dati, sono necessari altri 30-60 secondi per l'esecuzione di query.

Dopo l'inserimento dei record di log nella pipeline di Monitoraggio di Azure (come identificato nella proprietà _TimeReceived), i record vengono scritti nell'archiviazione temporanea per garantire l'isolamento del tenant e assicurarsi che i dati non vengano persi. Questo processo aggiunge in genere da 5 a 15 secondi.

Alcune soluzioni implementano algoritmi più pesanti per aggregare i dati e derivare informazioni dettagliate mentre i dati sono in streaming. Ad esempio, Application Insights calcola i dati della mappa delle applicazioni; Monitoraggio delle prestazioni di rete di Azure aggrega i dati in ingresso in intervalli di 3 minuti, con una latenza di 3 minuti.

Se la raccolta di dati include una trasformazione in fase di inserimento, questa operazione aggiungerà una certa latenza alla pipeline. Usare la metrica Durata della trasformazione log per min per monitorare l'efficienza della query di trasformazione.

Un altro processo che aggiunge latenza è il processo che gestisce i log personalizzati. In alcuni casi, questo processo potrebbe aggiungere alcuni minuti di latenza ai log che vengono raccolti dai file dall'agente.

Provisioning di nuovi tipi di dati personalizzati

Quando viene creato un nuovo tipo di dati personalizzati da un log personalizzato o dall'API dell'agente di raccolta dati, il sistema crea un contenitore di archiviazione dedicato. Questo sovraccarico occasionale si verifica solo alla prima occorrenza di questo tipo di dati.

Protezione in caso di picchi di dati

In genere meno di 1 minuto, ma può durare di più

La principale priorità di Monitoraggio di Azure è quella di garantire che nessun dato del cliente vada perduto e pertanto il sistema dispone di una protezione predefinita in caso di picchi di dati. Questa protezione include buffer per assicurare che il sistema continui a funzionare anche in situazioni di carico elevato. Con carico normale, questi controlli aggiungono meno di un minuto. In condizioni e errori estremi, possono aggiungere tempo significativo assicurando al tempo stesso la sicurezza dei dati.

Time di indicizzazione

5 minuti o meno

Ogni piattaforma per Big Data prevede un equilibrio predefinito tra fornire funzionalità di analisi e di ricerca avanzata e fornire l'accesso immediato ai dati. Con Monitoraggio di Azure è possibile eseguire query avanzate su miliardi di record e ottenere risultati in pochi secondi. Tali prestazioni sono possibili in quanto l'infrastruttura trasforma i dati in modo significativo durante l'inserimento e li memorizza in strutture compatte uniche. Il sistema memorizza i dati finché non è disponibile una quantità sufficiente per creare queste strutture. Questo processo deve essere completato prima che il record di log venga visualizzato nei risultati della ricerca.

Attualmente questo processo richiede circa 5 minuti in caso di un volume ridotto di dati, ma può richiedere meno tempo a velocità di trasferimento dati più elevate. Questo comportamento sembra illogico, ma consente l'ottimizzazione della latenza per carichi di lavoro in produzione con volumi elevati.

Controllare il tempo di inserimento

Il tempo di inserimento può variare a seconda delle risorse e delle circostanze. Per identificare il comportamento specifico dell'ambiente è possibile usare le query di log. La tabella seguente specifica come è possibile determinare i diversi tempi per un record durante la creazione e l'invio a Monitoraggio di Azure.

Valori della latenza di inserimento

È possibile misurare la latenza di un record specifico confrontando il risultato della funzione ingestion_time() con la proprietà TimeGenerated. Questi dati possono essere usati con varie aggregazioni per individuare il comportamento della latenza di inserimento. Esaminare qualche percentile del tempo di inserimento per ottenere informazioni dettagliate per grandi quantità di dati.

La query seguente mostrerà ad esempio i computer per cui è stato riscontrato il tempo di inserimento più elevato durante le 8 ore precedenti:

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

I controlli percentili precedenti sono validi per trovare tendenze generali nella latenza. Per identificare un picco a breve termine nella latenza, l'uso del valore massimo (max()) potrebbe essere più efficace.

Se si vuole eseguire il drill-down nel tempo di inserimento per un computer specifico in un periodo di tempo, usare la query seguente che visualizza anche i dati sul giorno precedente in un grafico:

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

Usare la query seguente per mostrare il tempo di inserimento per i computer in base al Paese/alla regione in cui si trovano, che dipende dal relativo indirizzo IP:

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 

Tipi di dati diversi che hanno origine dall'agente potrebbero avere un tempo di latenza di inserimento differente. Le query precedenti possono quindi essere usate con altri tipi. Usare la query seguente per esaminare il tempo di inserimento dei vari servizi di Azure:

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

Usare la stessa logica di query per diagnosticare le condizioni di latenza per i dati di Application Insights:

// 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

Le due query precedenti possono essere abbinate a qualsiasi altra tabella di Application Insights diversa da "richieste".

Blocco delle risorse

In alcuni casi, una risorsa potrebbe interrompere l'invio dei dati. Per comprendere se una risorsa sta inviando dati, controllare il record più recente che può essere identificato dal campo TimeGenerated standard.

Usare la tabella Heartbeat per verificare la disponibilità di una macchina virtuale, poiché l'agente invia un heartbeat ogni minuto. Usare la query seguente per elencare il computer attivi che non hanno segnalato heartbeat di recente:

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 

Passaggi successivi

Leggere il contratto di servizio per Monitoraggio di Azure.