Catat waktu penyerapan data di Azure Monitor
Azure Monitor adalah layanan data berskala tinggi yang melayani ribuan pelanggan yang mengirim terabyte data setiap bulan dengan kecepatan yang terus meningkat. Seringkali ada pertanyaan tentang waktu yang diperlukan untuk data log menjadi tersedia setelah dikumpulkan. Artikel ini menjelaskan berbagai faktor yang mempengaruhi latensi ini.
Latensi umum
Latensi mengacu pada waktu data dibuat pada sistem yang dipantau dan waktu saat tersedia untuk analisis di Azure Monitor. Pada umunya latensi untuk menyerap data log adalah antara 20 detik sampai 3 menit. Namun, latensi khusus untuk data tertentu akan bervariasi bergantung pada berbagai faktor.
Faktor-faktor yang mempengaruhi latensi
Total waktu penyerapan untuk sekumpulan data tertentu dapat dipecah menjadi area tingkat tinggi berikut.
- Waktu agen - Waktu untuk menemukan peristiwa, mengumpulkannya, lalu mengirimnya ke titik serap Log Azure Monitor sebagai rekaman log. Dalam kebanyakan kasus, proses ini dihandel oleh agen. Latensi tambahan dapat disebabkan oleh jaringan.
- Waktu alur - Waktu untuk alur penyerapan memproses rekaman log. Ini termasuk menguraikan properti peristiwa dan berpotensi menambahkan informasi terhitung.
- Waktu pengindeksan - Waktu yang dihabiskan untuk menyerap rekaman log ke penyimpanan data besar Azure Monitor.
Detail tentang berbagai latensi yang diperkenalkan dalam proses ini dijelaskan di bawah ini.
Latensi pengumpulan agen
Waktu bervariasi
Agen dan solusi manajemen menggunakan strategi yang berbeda untuk mengumpulkan data dari komputer virtual, yang dapat mempengaruhi latensi. Beberapa contoh spesifik meliputi yang berikut ini:
| Tipe data | Frekuensi pengumpulan | Catatan |
|---|---|---|
| Peristiwa Windows, peristiwa syslog, dan metrik performa | dikumpulkan dengan segera | |
| Penghitung kinerja Linux | disurvei pada interval 30 detik | |
| Log IIS dan log teks | dikumpulkan setelah timestamp mereka berubah | Untuk log IIS, hal ini dipengaruhi oleh jadwal rollover yang dikonfigurasikan pada IIS. |
| Solusi Replikasi Active Directory Domain Services | Penilaian setiap lima hari | Agen mengumpulkan log ini hanya ketika penilaian telah selesai. |
| Solusi Penilaian Active Directory Domain Services | penilaian mingguan infrastruktur Active Directory Domain Services Anda | Agen mengumpulkan log ini hanya ketika penilaian telah selesai. |
Frekuensi pengunggahan agen
Di bawah 1 menit
Untuk memastikan agen Analitik Log ringan, agen mem-buffer log dan secara berkala mengunggahnya 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
Bervariasi
Kondisi jaringan dapat berdampak negatif pada latensi data ini untuk mencapai titik penyerapan Log Azure Monitor.
Metrik, log sumber daya, log aktivitas Azure
30 detik hingga 15 menit
Data Azure menambahkan waktu tambahan untuk tersedia di titik penyerapan Log Azure Monitor untuk diproses:
- Metrik platform Azure tersedia dalam waktu kurang dari satu menit dalam database metrik, tetapi membutuhkan waktu tambahan 3 menit untuk diekspor ke titik peyerapan Log Azure Monitor.
- Log sumber daya biasanya menambahkan 30-90 detik, tergantung pada layanan Azure. Beberapa layanan Azure (khususnya, Azure SQL Database dan Azure Virtual Network) saat ini melaporkan log mereka pada interval 5 menit. Pekerjaan sedang berlangsung untuk meningkatkan hal ini lebih lanjut. Lihat kueri di bawah ini untuk memeriksa latensi ini di lingkungan Anda
- Data log aktivitas diserap dalam 30 detik saat Anda menggunakan pengaturan diagnostik tingkat langganan yang direkomendasikan untuk mengirimkannya ke Log Azure Monitor. Namun, mungkin membutuhkan waktu 10-15 menit jika Anda menggunakan integrasi warisan.
Pengumpulan solusi manajemen
Bervariasi
Beberapa solusi tidak mengumpulkan data mereka dari agen dan dapat menggunakan metode pengumpulan yang memperkenalkan latensi tambahan. Beberapa solusi mengumpulkan data secara berkala tanpa mencoba pengumpulan waktu yang hampir real-time. Contoh spesifik meliputi yang berikut ini:
- Solusi Microsoft 365 melakukan penjajakan log aktivitas menggunakan API Aktivitas Manajemen, yang saat ini tidak memberikan jaminan latensi hampir real-time.
- Data solusi Windows Analytics (Perbarui Kepatuhan, misalnya) dikumpulkan oleh solusi pada frekuensi harian.
Lihat dokumentasi untuk setiap solusi guna menentukan frekuensi pengumpulannya.
Waktu proses alur
30 hingga 60 detik
Setelah tersedia pada titik penyerapan, data membutuhkan waktu tambahan 30-60 detik agar tersedia untuk kueri.
Setelah rekaman log diserap ke dalam alur Azure Monitor (seperti yang diidentifikasi dalam properti _TimeReceived), catatan tersebut ditulis ke penyimpanan sementara untuk memastikan isolasi penyewa dan untuk memastikan bahwa data tidak hilang. Proses ini biasanya menambahkan 5-15 detik. Beberapa solusi manajemen mengimplementasikan algoritme yang lebih berat untuk mengagregasi data dan memperoleh insight saat data mengalir masuk. Misalnya, Pemantauan Performa Jaringan mengagregasi data masuk selama interval 3 menit, secara efektif menambahkan latensi 3 menit. Proses lain yang menambahkan latensi adalah proses yang menangani log kustom. Dalam beberapa kasus, proses ini mungkin menambahkan beberapa menit latensi ke log yang dikumpulkan dari file oleh agen.
Provisi jenis data kustom baru
Ketika jenis data kustom baru dibuat dari log kustom atau API Pengumpul Data, sistem membuat wadah penyimpanan khusus. Ini adalah overhead satu kali yang hanya terjadi pada penampilan pertama dari jenis data ini.
Perlindungan lonjakan
Biasanya kurang dari 1 menit tetapi bisa lebih
Prioritas utama Azure Monitor adalah memastikan bahwa tidak ada data pelanggan yang hilang, sehingga sistem memiliki perlindungan bawaan untuk lonjakan data. Ini termasuk buffer untuk memastikan bahwa bahkan di bawah beban besar, sistem akan tetap berfungsi. Di bawah beban normal, kontrol ini menambahkan kurang dari satu menit, tetapi dalam kondisi dan kegagalan ekstrem mereka dapat menambahkan waktu yang signifikan sambil memastikan data aman.
Waktu pengindeksan
5 menit atau kurang
Ada keseimbangan bawaan untuk setiap platform data besar antara menyediakan analitik dan kemampuan pencarian lanjutan dibandingkan dengan memberikan akses langsung ke data. Azure Monitor memungkinkan Anda menjalankan kueri yang kuat pada miliaran rekaman dan mendapatkan hasil dalam beberapa detik. Ini dimungkinkan karena infrastruktur mengubah data secara dramatis selama penyerapan dan menyimpannya dalam struktur ringkas yang unik. Sistem mem-buffer data sampai cukup tersedia untuk membuat struktur ini. Ini harus diselesaikan sebelum rekaman log muncul di hasil pencarian.
Proses ini saat ini memakan waktu sekitar 5 menit ketika volume data rendah tetapi lebih sedikit waktu pada kecepatan data yang lebih tinggi. Ini tampaknya berlawanan, tetapi proses ini memungkinkan optimalisasi latensi untuk beban kerja produksi volume tinggi.
Memeriksa waktu penyerapan
Waktu penyerapan dapat bervariasi untuk sumber daya yang berbeda dalam keadaan yang berbeda. Anda dapat menggunakan kueri log untuk mengidentifikasi perilaku tertentu di lingkungan Anda. Tabel berikut menspesifikasikan bagaimana Anda bisa menentukan waktu berbeda untuk rekaman saat dibuat dan dikirim ke Azure Monitor.
| Langkah | Properti atau Fungsi | Komentar |
|---|---|---|
| Rekaman dibuat di sumber data | TimeGenerated Jika sumber data tidak set nilai ini, maka sumber data akan diset ke waktu yang sama dengan _TimeReceived. |
Jika pada waktu pemrosesan, nilai Waktu yang Dihasilkan lebih lama dari 3 hari baris akan dihilangkan. |
| Rekaman yang diterima oleh titik akhir penyerapan Azure Monitor | _TimeReceived | Bidang ini tidak dioptimalkan untuk pemrosesan massal dan tidak boleh digunakan untuk memfilter himpunan data besar. |
| Rekaman disimpan di ruang kerja dan tersedia untuk kueri | ingestion_time() | Direkomendasikan untuk menggunakan inggestion_time() jika ada kebutuhan untuk memfilter hanya rekaman yang diserap dalam jangka waktu tertentu. Dalam kasus demikian, disarankan untuk menambahkan juga filter TimeGenerated dengan rentang yang lebih besar. |
Penundaan latensi penyerapan
Anda dapat mengukur latensi rekaman tertentu dengan membandingkan hasil fungsi ingestion_time() dengan properti TimeGenerated. Data ini dapat digunakan dengan berbagai agregasi untuk menemukan bagaimana latensi penyerapan berperilaku. Periksa beberapa persentil dari waktu penyerapan untuk mendapatkan insight untuk sejumlah besar data.
Misalnya, kueri berikut akan menunjukkan kepada Anda komputer mana yang memiliki waktu penyerapan tertinggi selama 8 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 cukup baik 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 kueri berikut untuk memperlihatkan waktu penyerapan komputer menurut negara/wilayah tempat kueri berada berdasarkan 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
Sumber daya yang berhenti merespons
Dalam beberapa kasus, sumber daya dapat berhenti mengirim data. Untuk memahami apakah sumber daya mengirim data atau tidak, lihat rekaman terbarunya yang dapat diidentifikasi oleh bidang TimeGenerated standar.
Gunakan tabel Heartbeat untuk memeriksa ketersediaan VM, karena heartbeat dikirim satu menit sekali oleh agen. Gunakan kueri berikut untuk mendata komputer aktif yang belakangan ini belum melaporkan denyut jantung (denyut jantung dikirimkan sekali semenit):
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 (SLA) untuk Azure Monitor.