Catat waktu penyerapan data di Azure Monitor
Azure Monitor adalah layanan data skala tinggi yang melayani ribuan pelanggan yang mengirim terabyte data setiap bulan dengan kecepatan yang 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 rata-rata
Latensi mengacu pada waktu data dibuat pada sistem yang dipantau dan waktu tersedia untuk analisis di Azure Monitor. Latensi rata-rata untuk menyerap data log adalah antara 20 detik dan 3 menit. Latensi khusus untuk data tertentu akan bervariasi tergantung pada beberapa faktor yang dijelaskan dalam artikel ini.
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 mengirimkannya ke titik akhir pengumpulan data sebagai catatan log. Dalam kebanyakan kasus, proses ini dihandel oleh agen. Latensi lainnya mungkin diperkenalkan oleh jaringan.
- Waktu alur: Waktu untuk alur penyerapan untuk memproses catatan log. Periode waktu ini termasuk mengurai properti peristiwa dan berpotensi menambahkan informasi terhitung.
- Waktu pengindeksan: Waktu yang dihabiskan untuk menyerap rekaman log ke penyimpanan big data Azure Monitor.
Detail tentang berbagai latensi yang diperkenalkan dalam proses ini dijelaskan di bagian berikut.
Latensi pengumpulan agen
Waktu bervariasi
Agen dan solusi manajemen menggunakan strategi yang berbeda untuk mengumpulkan data dari komputer virtual, 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 | Dijajaki pada interval 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. |
| Solusi Replikasi Active Directory Domain Services | Penilaian setiap lima hari | Agen mengumpulkan log hanya ketika penilaian selesai. |
| Solusi Penilaian Active Directory Domain Services | Penilaian mingguan infrastruktur Direktori Aktif Anda | Agen mengumpulkan log hanya ketika penilaian 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 mungkin berdampak negatif pada latensi data ini untuk mencapai titik akhir pengumpulan data.
Metrik, log sumber daya, log aktivitas Azure
30 detik hingga 15 menit
Data Azure menambahkan lebih banyak waktu untuk tersedia di titik akhir pengumpulan data untuk diproses:
- Metrik platform Azure tersedia dalam waktu kurang dari satu menit dalam database metrik, tetapi membutuhkan waktu 3 menit lagi untuk diekspor ke titik akhir pengumpulan data.
- Log sumber daya biasanya menambahkan 30 hingga 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 waktu ini lebih lanjut. Untuk memeriksa latensi ini di lingkungan Anda, lihat kueri berikut ini.
- Log aktivitas tersedia untuk analisis dalam 3 hingga 10 menit.
Pengumpulan solusi manajemen
Bervariasi
Beberapa solusi tidak mengumpulkan data mereka dari agen dan mungkin menggunakan metode pengumpulan yang memperkenalkan lebih banyak latensi. Beberapa solusi mengumpulkan data secara berkala tanpa mencoba pengumpulan mendekati real time. Contoh tertentu meliputi:
- Log aktivitas polling solusi Microsoft 365 dengan menggunakan API Aktivitas Manajemen, yang saat ini tidak memberikan jaminan latensi mendekati real time.
- Data solusi Analitik Windows (Kepatuhan Pembaruan, misalnya) dikumpulkan oleh solusi pada frekuensi harian.
Untuk menentukan frekuensi pengumpulan solusi, lihat dokumentasi untuk setiap solusi.
Waktu proses alur
30 hingga 60 detik
Setelah data tersedia di titik akhir pengumpulan data, dibutuhkan 30 hingga 60 detik lagi untuk tersedia untuk kueri.
Setelah rekaman log diserap ke dalam alur Azure Monitor (seperti yang diidentifikasi di properti _TimeReceived ), rekaman tersebut ditulis ke penyimpanan sementara untuk memastikan isolasi penyewa dan untuk memastikan bahwa data tidak hilang. Proses ini biasanya menambahkan 5 hingga 15 detik.
Beberapa solusi menerapkan algoritma yang lebih berat untuk mengagregasi data dan memperoleh wawasan saat data mengalir. Misalnya, Application Insights menghitung data peta aplikasi; Pemantauan Performa Jaringan Azure menggabungkan data masuk selama interval 3 menit, yang secara efektif menambahkan latensi 3 menit.
Jika pengumpulan data menyertakan transformasi waktu penyerapan, maka ini akan menambahkan beberapa latensi ke alur. 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 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. Overhead satu kali ini hanya terjadi pada tampilan pertama 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. Perlindungan ini mencakup buffer untuk memastikan bahwa bahkan di bawah beban besar, sistem akan terus berfungsi. Di bawah beban normal, kontrol ini menambahkan kurang dari satu menit. 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 big data antara menyediakan analitik dan kemampuan pencarian tingkat lanjut dibandingkan dengan menyediakan akses langsung ke data. Dengan Azure Monitor, Anda dapat menjalankan kueri canggih pada miliaran rekaman dan mendapatkan hasil dalam beberapa detik. Performa ini dimungkinkan karena infrastruktur mengubah data secara dramatis selama penyerapannya dan menyimpannya dalam struktur ringkas yang unik. Sistem mem-buffer data sampai cukup tersedia untuk membuat struktur ini. Proses ini harus diselesaikan sebelum rekaman log muncul di hasil pencarian.
Proses ini saat ini membutuhkan waktu sekitar 5 menit ketika ada volume data yang rendah, tetapi dapat membutuhkan lebih sedikit waktu pada tingkat data yang lebih tinggi. Perilaku ini tampaknya berlawanan, tetapi proses ini memungkinkan pengoptimalan latensi untuk beban kerja produksi volume tinggi.
Periksa waktu penyerapan
Waktu penyerapan mungkin 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 mengatur nilai ini, sumber data akan diatur ke waktu yang sama dengan _TimeReceived. |
Jika pada waktu pemrosesan, nilai Waktu yang Dihasilkan lebih lama dari dua hari, baris akan dihilangkan. |
| Rekaman yang diterima oleh titik akhir pengumpulan data | _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() | Sebaiknya gunakan ingestion_time() jika ada kebutuhan untuk memfilter hanya rekaman yang diserap di jendela waktu tertentu. Dalam kasus seperti itu, kami sarankan TimeGenerated juga menambahkan filter dengan rentang yang lebih besar. |
Penundaan latensi penyerapan
Anda dapat mengukur latensi rekaman tertentu dengan membandingkan hasil fungsi ingestion_time() dengan TimeGenerated properti . Data ini dapat digunakan dengan berbagai agregasi untuk menemukan bagaimana latensi penyerapan bereaksi. Periksa beberapa persentil waktu penyerapan untuk mendapatkan wawasan untuk data dalam jumlah besar.
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, 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 data 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
Dua kueri di atas dapat dipasangkan dengan tabel Application Insights lainnya selain "permintaan".
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 standar TimeGenerated .
Heartbeat Gunakan tabel 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 untuk Azure Monitor.