Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure Monitor è un servizio dati su larga scala che invia terabyte di dati ogni mese e continua a crescere. Nelle normali operazioni del servizio, il tempo necessario per rendere disponibili i dati di log dopo che la raccolta è prevedibile e coerente. Questo articolo illustra i fattori che influiscono su questa latenza.
Latenza media
La latenza si riferisce al tempo compreso tra il momento in cui i dati vengono creati nel sistema monitorato e quando diventa disponibile per l'analisi in Azure Monitor. La latenza media per l'inserimento dei dati di log è inferiore a 10 secondi. 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 è il tempo cumulativo dal client al servizio monitoraggio Azure.
- Orario client: il tempo necessario per individuare un evento, raccoglierlo e inviarlo a un endpoint raccolta di dati come record di log. Nella maggior parte dei casi, un agente come l'agente di monitoraggio Azure gestisce questo processo. Le applicazioni personalizzate che usano l'API di inserimento dei log non fanno parte dei calcoli di questo articolo, ma possono avere caratteristiche di latenza simili all'ora del client AMA.
- Tempo di Monitoraggio di Azure: tempo necessario per l'inserimento per elaborare il record di log dopo che il client accede a Monitoraggio di Azure. Questo periodo di tempo include l'analisi delle proprietà dell'evento e l'aggiunta potenziale di informazioni calcolate.
Le sezioni seguenti descrivono le diverse latenza introdotte in questo processo.
Latenza di raccolta degli agenti
Latenza: tempo variabile
Gli agenti usano strategie diverse per raccogliere dati, 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 di IIS, questa pianificazione dipende anche dalla pianificazione di rollover configurata in IIS. |
Per altre informazioni sulle prestazioni dell'agente, vedere Azure Monitorare le prestazioni dell'agente.
Frequenza di caricamento dell'agente
Latenza: meno di 1 minuto
Per mantenere leggero l'agente di monitoraggio Azure, memorizza nel buffer i log e li carica periodicamente in Azure Monitoraggio. 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
Latenza: varia
La rete tra un client e l'endpoint di raccolta dati di monitoraggio Azure potrebbe aggiungere ritardi imprevisti. Quando si misura la latenza di inserimento, questa latenza di rete viene inclusa come parte del AgentLatency calcolo nelle query di esempio nella sezione misurare la latenza di inserimento .
Azure metriche, log delle risorse, log attività
Latenza: da 30 secondi a 20 minuti
Azure richiede più tempo prima che i dati siano disponibili per l'elaborazione presso un endpoint di raccolta dati.
- Metriche della piattaforma Azure sono disponibili in meno di un minuto nel database delle metriche, ma richiedono altri tre minuti per essere esportate all'endpoint di raccolta dati.
- Resource logs sono in genere disponibili entro 3-10 minuti end-to-end, a seconda della complessità del servizio e dei servizi Azure coinvolti. Ad esempio, Azure SQL Database e Azure Virtual Network attualmente forniscono i log ogni cinque minuti. Per esaminare questa latenza nell'ambiente, vedere la query che segue.
- I log attività sono disponibili per l'analisi e l'invio di avvisi in 3-20 minuti.
Tempo di elaborazione di Monitoraggio di Azure
Latenza: meno di 10 secondi
Dopo che i dati raggiungono l'endpoint di raccolta dati, sono necessari meno di 10 secondi prima di poter effettuare query su di essi.
Quando Azure Monitor inserisce i record di log (come viene visualizzata la proprietà _TimeReceived), li scrive in storage temporanei. Questo passaggio garantisce l'isolamento del tenant e impedisce la perdita di dati. Questo passaggio aggiunge in genere da 5 a 15 secondi.
Alcune soluzioni usano algoritmi più complessi per aggregare i dati e derivare informazioni dettagliate durante i flussi di dati. Ad esempio, Application Insights calcola i dati della mappa delle applicazioni. Azure Network Performance Monitoring aggrega i dati in ingresso in intervalli di tre minuti, il che effettivamente aggiunge tre minuti di latenza in questo caso.
Se la raccolta dati include una trasformazione ingestion-time, questa trasformazione aggiunge una certa latenza al tempo di processo di monitoraggio Azure. 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 raccolti da un agente dai file.
Provisioning di nuovi tipi di dati personalizzati
Quando viene creato un nuovo tipo di dati personalizzati da un log custom log o dall'API di inserimento Logs, il sistema crea un contenitore di storage dedicato. Questo sovraccarico occasionale si verifica solo alla prima occorrenza di questo tipo di dati.
Controllare il tempo di inserimento
Il tempo di ingestione potrebbe variare per diverse risorse sotto diverse circostanze. Usare le query di log per identificare un comportamento specifico dell'ambiente. Nella tabella seguente viene specificato il modo in cui si determinano i diversi tempi per un record durante la creazione e l'invio a Azure Monitoraggio. Per altre informazioni sulle query di log, vedere Panoramica di Log Analytics.
Avvertimento
Durante l'inserimento dei log nel livello Ausiliario di Monitoraggio di Azure, evitare di inviare un singolo payload contenente timestamp TimeGenerated che superano i 30 minuti nella stessa chiamata API. Questa chiamata API potrebbe causare il codice RecordsTimeRangeIsMoreThan30Minutesdi errore di inserimento seguente. Si tratta di una limitazione nota che viene rimossa.
Questa restrizione non si applica ai log ausiliari che usano trasformazioni.
| Passaggio | Proprietà o funzione | Commenti |
|---|---|---|
| Record creato alla fonte dei dati | TimeGenerated | Il valore TimeGenerated non può essere maggiore di due giorni prima dell'ora ricevuta o più di un giorno in futuro. In caso contrario, Azure Monitor Logs sostituisce il valore TimeGenerated con l'ora effettiva ricevuta. Se l'origine dati non imposta questo valore, Azure Monitor Logs imposta il valore allo stesso orario di _TimeReceived. |
| Record ricevuto dall'endpoint di raccolta dati | _TimeReceived | Non usare questo campo per filtrare set di dati di grandi dimensioni. Non è ottimizzato per l'elaborazione di massa. |
| Record archiviato nell'area di lavoro e disponibile per le query | ingestion_time() | Utilizzare ingestion_time() se è necessario filtrare solo i record inseriti in un determinato intervallo di tempo. In questi casi, aggiungere anche un TimeGenerated filtro con un intervallo più ampio. |
Misurare la latenza di inserimento
Misurare la latenza di un record specifico quando si confronta il risultato della funzione ingestion_time() con la proprietà TimeGenerated. Informazioni sul comportamento della latenza di inserimento quando si usano varie aggregazioni di questi dati. Esaminare qualche percentile del tempo di inserimento per ottenere informazioni dettagliate per grandi quantità di dati.
Ad esempio, la query seguente mostra quali computer hanno il tempo di inserimento più elevato nelle otto 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 approfondire il momento di inserimento per un computer specifico in un periodo di tempo, usare la query seguente, che visualizza anche i dati del giorno scorso 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 immissione dei computer in base al Paese/alla regione in cui si trovano, che è determinato dal loro 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 di vari servizi 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 le metriche basate su log di Application Insights:
// 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
Risorse che smettono di rispondere
In alcuni casi, una risorsa smette di inviare dati. Per comprendere se una risorsa invia dati, controllare il record più recente, che il campo standard TimeGenerated identifica.
Usare la Heartbeat tabella per verificare la disponibilità di una macchina virtuale in quanto l'agente invia un heartbeat una volta al 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 l'accordo sul livello di servizio per Azure Monitor.