Mencatat waktu penyerapan data di Azure Monitor

Azure Monitor adalah layanan data skala tinggi yang mengirim terabyte data setiap bulan dan terus bertambah. Di bawah operasi layanan normal, waktu yang diperlukan agar data log tersedia setelah pengumpulan dapat diprediksi dan konsisten. Artikel ini menjelaskan faktor-faktor yang memengaruhi latensi ini.

Latensi rata-rata

Latensi mengacu pada waktu antara kapan data dibuat pada sistem yang dipantau dan ketika tersedia untuk analisis di Azure Monitor. Latensi rata-rata untuk menyerap data log kurang dari 10 detik. Latensi khusus untuk data tertentu bervariasi tergantung pada beberapa faktor yang dijelaskan dalam artikel ini.

Faktor-faktor yang mempengaruhi latensi

Total waktu penyerapan untuk sekumpulan data tertentu adalah waktu kumulatif dari klien ke layanan Azure Monitor.

• Waktu klien: Waktu untuk menemukan peristiwa, mengumpulkannya, lalu mengirimkannya ke titik akhir pengumpulan data sebagai catatan log. Dalam kebanyakan kasus, agen seperti Azure Monitor Agent (AMA) menangani proses ini. Aplikasi kustom yang menggunakan API penyerapan Log bukan bagian dari perhitungan artikel ini, tetapi mereka mungkin memiliki karakteristik latensi mereka sendiri yang mirip dengan waktu klien AMA.
• Waktu Azure Monitor: Setelah klien mengalihkan ke Azure Monitor, waktu ingestasi untuk memproses rekaman log. Periode waktu ini termasuk mengurai properti peristiwa dan berpotensi menambahkan informasi terhitung.

Bagian berikut menjelaskan berbagai latensi yang diperkenalkan dalam proses ini.

Keterlambatan Pengumpulan Agen

Latensi: Waktu bervariasi

Agen menggunakan strategi yang berbeda untuk mengumpulkan data, yang dapat memengaruhi latensi. Beberapa contoh tertentu tercantum dalam tabel berikut.

Tipe data	Frekuensi pengumpulan	Catatan
Peristiwa Windows, peristiwa Syslog, dan metrik performa	Dikumpulkan segera
Penghitung kinerja Linux	Dipantau setiap 30 detik
Log IIS dan log teks	Dikumpulkan setelah tanda waktu mereka berubah	Untuk log IIS, jadwal ini dipengaruhi oleh jadwal rollover yang dikonfigurasi pada IIS.

Untuk informasi selengkapnya tentang performa agen, lihat performa Agen Azure Monitor.

Frekuensi unggahan agen

Latensi: Di bawah 1 menit

Untuk menjaga Azure Monitor Agent tetap ringan, agen menggunakan buffer untuk mencatat log dan mengunggahnya secara berkala ke Azure Monitor. Frekuensi upload bervariasi antara 30 detik sampai 2 menit tergantung pada jenis data. Sebagian besar data diunggah dalam waktu kurang dari 1 menit.

Jaringan

Latensi: Bervariasi

Jaringan antara klien dan titik akhir pengumpulan data Azure Monitor mungkin menambahkan penundaan yang tidak terduga. Saat Anda mengukur latensi penyerapan, latensi jaringan ini disertakan sebagai bagian dari kalkulasi dalam kueri sampel di bagian AgentLatency.

metrik Azure, log sumber daya, log aktivitas

Latensi: 30 detik hingga 20 menit

Azure data menambahkan waktu lebih lama hingga menjadi tersedia di titik akhir pengumpulan data untuk diproses.

• Metrik platform Azure tersedia dalam waktu kurang dari satu menit dalam database metrik, namun, memerlukan waktu tiga menit lagi untuk diekspor ke endpoint pengumpulan data.
• log Resource biasanya tersedia dalam waktu 3 hingga 10 menit, tergantung pada kompleksitas layanan dan layanan Azure yang terlibat. Misalnya, Azure SQL Database dan Microsoft Azure Virtual Network saat ini menyediakan log mereka setiap lima menit. Untuk memeriksa latensi ini di lingkungan Anda, lihat kueri berikut ini.
• Log aktivitas tersedia untuk analisis dan pemberitahuan dalam 3 hingga 20 menit.

Azure Memantau waktu proses

Latensi: Kurang dari 10 detik

Setelah data mencapai titik akhir pengumpulan data, dibutuhkan waktu kurang dari 10 detik sebelum Anda bisa mengkuerinya.

Ketika Azure Monitor mengolah rekaman log (seperti yang ditunjukkan _TimeReceived), mereka menuliskannya ke penyimpanan sementara. Langkah ini memastikan isolasi penyewa dan mencegah kehilangan data. Langkah ini biasanya menambahkan 5 hingga 15 detik.

Beberapa solusi menggunakan algoritma yang lebih kompleks untuk mengagregasi data dan mendapatkan wawasan saat aliran data masuk. Misalnya, Application Insights menghitung data peta aplikasi. Pemantauan Kinerja Jaringan Azure menggabungkan data masuk selama interval tiga menit, yang secara efektif menambahkan latensi tambahan tiga menit dalam kasus ini.

Jika pengumpulan data menyertakan transformasi waktu ingestion, transformasi ini menambahkan beberapa latensi ke waktu proses Azure Monitor. Gunakan metrik Durasi Transformasi Log per Min untuk memantau efisiensi kueri transformasi.

Proses lain yang menambahkan latensi adalah proses yang menangani log kustom. Dalam beberapa kasus, proses ini dapat menambahkan beberapa menit latensi ke log yang dikumpulkan agen dari berkas.

Provisi jenis data kustom baru

Saat jenis data kustom baru dibuat dari log custom atau API penyerapan Logs, sistem membuat kontainer storage khusus. Overhead ini hanya terjadi pada saat pertama kali jenis data ini muncul.

Periksa waktu penyerapan

Waktu penyerapan mungkin bervariasi untuk sumber daya yang berbeda dalam keadaan yang berbeda. Gunakan kueri log untuk mengidentifikasi perilaku spesifik lingkungan Anda. Tabel berikut menentukan cara Anda menentukan waktu yang berbeda untuk rekaman saat dibuat dan dikirim ke Azure Monitor. Untuk informasi selengkapnya tentang kueri log, lihat Gambaran Umum Analitik Log.

Langkah	Properti atau fungsi	Komentar
Rekaman dibuat di sumber data	TimeGenerated	Nilai TimeGenerated tidak boleh lebih dari dua hari sebelum waktu yang diterima atau lebih dari satu hari di masa mendatang. Jika tidak, Azure Monitor Logs menggantikan nilai TimeGenerated dengan waktu aktual saat diterima. Jika sumber data tidak mengatur nilai ini, log Azure Monitor mengatur nilai ke waktu yang sama dengan _TimeReceived.
Rekaman yang diterima oleh titik akhir pengumpulan data	_WaktuDiterima	Jangan gunakan bidang ini untuk memfilter himpunan data besar. Ini tidak dioptimalkan untuk pemrosesan massal.
Rekaman disimpan di ruang kerja dan tersedia untuk pertanyaan	ingestion_time()	Gunakan ingestion_time() jika Anda hanya perlu memfilter rekaman yang diserap di jendela waktu tertentu. Dalam kasus seperti itu, tambahkan juga filter TimeGenerated dengan rentang yang lebih besar.

Mengukur latensi penyerapan

Ukur latensi rekaman tertentu saat Anda membandingkan hasil fungsi ingestion_time() dengan properti TimeGenerated. Temukan bagaimana latensi penyerapan bereaksi saat Anda menggunakan berbagai agregasi data ini. Tinjau persentase waktu pemrosesan untuk mendapatkan wawasan yang lebih baik tentang data dalam jumlah besar.

Misalnya, kueri berikut menunjukkan komputer mana yang memiliki waktu penyerapan tertinggi selama delapan jam sebelumnya:

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

Pemeriksaan persentil sebelumnya berguna untuk menemukan tren umum dalam latensi. Untuk mengidentifikasi lonjakan latensi jangka pendek, menggunakan maksimum ( max() ) mungkin lebih efektif.

Jika Anda ingin menelusuri paling detail waktu penyerapan komputer tertentu selama periode waktu tertentu, gunakan kueri berikut, yang juga memvisualisasikan data dari hari sebelumnya dalam grafik:

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

Gunakan permintaan berikut untuk memperlihatkan waktu pencatatan komputer menurut negara/wilayah tempat mereka berada, yang didasarkan pada alamat IP mereka.

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

Jenis data yang berbeda yang berasal dari agen mungkin memiliki waktu latensi penyerapan yang berbeda, sehingga kueri sebelumnya dapat digunakan dengan jenis lain. Gunakan kueri berikut untuk memeriksa waktu penyerapan berbagai layanan 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

Gunakan logika kueri yang sama untuk mendiagnosis kondisi latensi untuk metrik berbasis log 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

Sumber daya yang berhenti merespons

Dalam beberapa kasus, sumber daya berhenti mengirim data. Untuk memahami apakah sumber daya mengirim data, periksa rekaman terbarunya, yang diidentifikasi bidang standar TimeGenerated .

Gunakan tabel Heartbeat untuk memeriksa ketersediaan VM karena agen mengirimkan heartbeat setiap satu menit. Gunakan kueri berikut untuk mencantumkan komputer aktif yang tidak melaporkan heartbeat baru-baru ini:

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 

Langkah berikutnya

Baca perjanjian tingkat layanan untuk Azure Monitor.