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 momento in cui i dati vengono creati nel sistema monitorato e al momento in cui diventa disponibile 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 aree generali seguenti:

• Ora agente: tempo per individuare un evento, raccoglierlo e inviarlo a un 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: tempo per l'elaborazione del record di log da parte della pipeline di inserimento. Questo periodo di tempo include l'analisi delle proprietà dell'evento e l'aggiunta di informazioni calcolate.
• Tempo di indicizzazione: tempo impiegato per inserire un record di log in un archivio 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 strategie diverse per raccogliere dati da una macchina virtuale, che potrebbero influire sulla latenza. Alcuni esempi specifici sono elencati nella tabella seguente.

Tipo di dati	Frequenza di raccolta	Note
Eventi di Windows, eventi Syslog e metriche delle prestazioni	Raccolto immediatamente
Contatori delle prestazioni di Linux	Polling a intervalli di 30 secondi
Log iis e log di testo	Raccolta dopo le modifiche del timestamp	Per i log iis, questa pianificazione è influenzata dalla pianificazione di rollover configurata in IIS.
Soluzione di replica di Active Directory	Valutazione ogni cinque giorni	L'agente raccoglie i log solo al termine della valutazione.
Soluzione Di valutazione di Active Directory	Valutazione settimanale dell'infrastruttura di Active Directory	L'agente raccoglie i log solo al termine della valutazione.

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

Varia

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, database SQL di Azure e Azure Rete virtuale) attualmente segnalano 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 seguente.
• I log attività sono disponibili per l'analisi in 3-10 minuti.

Raccolta delle soluzioni di gestione

Varia

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

• La soluzione Microsoft 365 esegue il polling dei log attività usando l'API Attività di gestione, 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 a una 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 durante lo streaming dei dati. Ad esempio, Application Insights calcola i dati della mappa delle applicazioni; La rete di Azure Monitor prestazioni aggrega i dati in ingresso in intervalli di 3 minuti, con una latenza di 3 minuti.

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 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 monouso si verifica solo al primo aspetto di questo tipo di dati.

Protezione in caso di picchi di dati

In genere meno di 1 minuto, ma può essere 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 garantire che, anche sotto un carico immenso, il sistema continuerà a funzionare. 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

C'è un equilibrio predefinito per ogni piattaforma Big Data tra la fornitura di funzionalità di analisi e ricerca avanzata anziché fornire l'accesso immediato ai dati. Con Monitoraggio di Azure è possibile eseguire query avanzate su miliardi di record e ottenere risultati entro pochi secondi. Queste prestazioni sono rese possibili perché l'infrastruttura trasforma notevolmente i dati durante l'inserimento e li archivia in strutture compatta univoche. 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.

Questo processo richiede attualmente circa 5 minuti quando è presente un volume ridotto di dati, ma può richiedere meno tempo a velocità di dati più elevate. Questo comportamento sembra poco intuitivo, ma questo processo consente l'ottimizzazione della latenza per carichi di lavoro di produzione con volumi elevati.

Controllare il tempo di inserimento

Il tempo di inserimento può variare per le diverse risorse in circostanze diverse. 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.

Passaggio	Proprietà o funzione	Commenti
Record creato nell'origine dati	TimeGenerated Se l'origine dati non imposta questo valore, verrà impostata sullo stesso tempo di _TimeReceived.	Se in fase di elaborazione il valore Time Generated è precedente a due giorni, la riga verrà eliminata.
Record ricevuto dall'endpoint di raccolta dati	_TimeReceived	Questo campo non è ottimizzato per l'elaborazione di massa e non deve essere usato per filtrare set di dati di grandi dimensioni.
Record archiviato nell'area di lavoro e disponibile per le query	ingestion_time()	È consigliabile usare ingestion_time() se è necessario filtrare solo i record inseriti in un determinato intervallo di tempo. In questi casi, è consigliabile aggiungere anche un TimeGenerated filtro con un intervallo più ampio.

Valori della latenza di inserimento

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

Ad esempio, la query seguente mostrerà quali computer hanno il tempo di inserimento più elevato nelle 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 del tempo di inserimento per un computer specifico in un determinato periodo di tempo, usare la query seguente, che visualizza anche i dati dell'ultimo giorno 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 visualizzare il tempo di inserimento del computer in base al paese o all'area geografica in cui si trovano, che si basa sul 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

Blocco delle risorse

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

Usare la Heartbeat tabella per verificare la disponibilità di una macchina virtuale perché un heartbeat viene inviato una volta al minuto dall'agente. 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.