Tingkatkan ketahanan dengan mereplikasi ruang kerja Analitik Log Anda di seluruh wilayah (Pratinjau)

Mereplikasi ruang kerja Analitik Log di seluruh wilayah akan meningkatkan ketahanan dengan memungkinkan Anda beralih ke ruang kerja yang direplikasi dan melanjutkan operasi jika ada kegagalan regional. Artikel ini menjelaskan cara kerja replikasi ruang kerja Analitik Log, cara mereplikasi ruang kerja Anda, cara beralih dan kembali, dan cara memutuskan kapan harus beralih di antara ruang kerja yang direplikasi.

Berikut adalah video yang memberikan gambaran umum singkat tentang cara kerja replikasi ruang kerja Analitik Log:

Penting

Meskipun terkadang kita menggunakan istilah failover, misalnya dalam panggilan API, failover juga biasanya digunakan untuk menjelaskan proses otomatis. Oleh karena itu, artikel ini menggunakan istilah pengalihan untuk menekankan bahwa beralih ke ruang kerja yang direplikasi adalah tindakan yang Anda picu secara manual.

Izin yang diperlukan

Perbuatan	Izin yang diperlukan
Mengaktifkan replikasi ruang kerja	Microsoft.OperationalInsights/workspaces/write dan Microsoft.Insights/dataCollectionEndpoints/write izin, sebagaimana disediakan oleh peran bawaan Kontributor Pemantauan, misalnya
Beralih dan beralih kembali (memicu failover dan failback)	Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failback, dan Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action izin, seperti yang disediakan oleh peran bawaan Kontributor Pemantauan, misalnya
Periksa status ruang kerja	Microsoft.OperationalInsights/workspaces/read izin ke ruang kerja Analitik Log, sebagaimana disediakan oleh peran bawaan Kontributor Pemantauan, misalnya

Cara kerja replikasi ruang kerja Analitik Log

Ruang kerja dan wilayah asli Anda disebut sebagai yang utama. Ruang kerja yang direplikasi dan wilayah alternatif disebut sebagai sekunder.

Proses replikasi ruang kerja membuat instans ruang kerja Anda di wilayah sekunder. Proses ini membuat ruang kerja sekunder dengan konfigurasi yang sama dengan ruang kerja utama Anda, dan Azure Monitor secara otomatis memperbarui ruang kerja sekunder dengan perubahan apa pun di masa mendatang yang Anda buat pada konfigurasi ruang kerja utama Anda.

Ruang kerja sekunder adalah ruang kerja "bayangan" hanya untuk tujuan ketahanan. Anda tidak dapat melihat ruang kerja sekunder di portal Azure, dan Anda tidak dapat mengelola atau mengaksesnya secara langsung.

Saat Anda mengaktifkan replikasi ruang kerja, Azure Monitor mengirimkan log baru yang diserap ke ruang kerja utama Anda ke wilayah sekunder Anda juga. Log yang Anda serap ke ruang kerja sebelum mengaktifkan replikasi ruang kerja tidak disalin.

Jika pemadaman memengaruhi wilayah utama, Anda dapat beralih dan mengalihkan semua permintaan penyerapan dan kueri ke wilayah sekunder Anda. Setelah Azure mengurangi pemadaman dan ruang kerja utama Anda sehat lagi, Anda dapat beralih kembali ke wilayah utama Anda.

Saat Anda beralih, ruang kerja sekunder menjadi aktif dan primer Anda menjadi tidak aktif. Azure Monitor kemudian menyerap data baru melalui alur penyerapan di wilayah sekunder Anda, bukan wilayah utama. Saat Anda beralih ke wilayah sekunder, Azure Monitor mereplikasi semua data yang Anda serap dari wilayah sekunder ke wilayah utama. Prosesnya asinkron dan tidak memengaruhi latensi penyerapan Anda.

Penting

Setelah Anda beralih ke wilayah sekunder, jika wilayah utama tidak dapat memproses data log masuk, Azure Monitor akan menyangga data di wilayah sekunder hingga 11 hari. Selama empat hari pertama, Azure Monitor secara otomatis memasang ulang untuk mereplikasi data secara berkala.

Wilayah yang didukung

Replikasi ruang kerja saat ini didukung untuk ruang kerja di sekumpulan wilayah terbatas, yang diatur oleh grup wilayah (grup wilayah yang berdekatan secara geografis). Saat Anda mengaktifkan replikasi, pilih lokasi sekunder dari daftar wilayah yang didukung di grup wilayah yang sama dengan lokasi utama ruang kerja. Misalnya, ruang kerja di Eropa Barat dapat direplikasi di Eropa Utara, tetapi tidak di US Barat 2, karena wilayah ini berada di grup wilayah yang berbeda.

Grup dan wilayah wilayah ini saat ini didukung:

Grup wilayah	Wilayah	Catatan
Amerika Utara	AS Timur	Replikasi tidak didukung ke atau dari wilayah US Timur 2.
	AS Timur 2	Replikasi tidak didukung ke atau dari wilayah US Timur.
	AS Barat
	US Barat 2
	US Tengah
	AS Tengah Bagian Selatan
	Kanada Tengah
Eropa	Eropa Barat
	Eropa Utara
	Inggris Selatan
	Inggris Barat
	Jerman Barat Tengah
	Prancis Tengah

Persyaratan residensi data

Pelanggan yang berbeda memiliki persyaratan residensi data yang berbeda, jadi penting bagi Anda untuk mengontrol tempat data Anda disimpan. Azure Monitor memproses dan menyimpan log di wilayah utama dan sekunder yang Anda pilih. Untuk informasi selengkapnya, lihat Wilayah yang didukung.

Dukungan untuk Sentinel dan layanan lainnya

Berbagai layanan dan fitur yang menggunakan ruang kerja Analitik Log kompatibel dengan replikasi dan pengalihan ruang kerja. Layanan dan fitur ini terus berfungsi saat Anda beralih ke ruang kerja sekunder.

Misalnya, masalah jaringan regional yang menyebabkan latensi penyerapan log dapat berdampak pada pelanggan Sentinel. Pelanggan yang menggunakan ruang kerja yang direplikasi dapat beralih ke wilayah sekunder mereka untuk terus bekerja dengan ruang kerja Analitik Log dan Sentinel mereka. Namun, jika masalah jaringan berdampak pada kesehatan layanan Sentinel, beralih ke wilayah lain tidak mengurangi masalah.

Beberapa pengalaman Azure Monitor, termasuk Application Insights dan VM Insights, saat ini hanya kompatibel sebagian dengan replikasi dan pengalihan ruang kerja. Untuk daftar lengkapnya, lihat Pembatasan dan batasan.

Mengaktifkan dan menonaktifkan replikasi ruang kerja

Anda mengaktifkan dan menonaktifkan replikasi ruang kerja dengan menggunakan perintah REST. Perintah ini memicu operasi jangka panjang, yang berarti dapat memakan waktu beberapa menit agar pengaturan baru diterapkan. Setelah Anda mengaktifkan replikasi, diperlukan waktu hingga satu jam agar semua tabel (jenis data) mulai mereplikasi, dan beberapa jenis data mungkin mulai mereplikasi sebelum yang lain. Perubahan yang Anda buat pada skema tabel setelah mengaktifkan replikasi ruang kerja - misalnya, tabel log kustom baru atau bidang kustom yang Anda buat, atau log diagnostik yang disiapkan untuk jenis sumber daya baru - dapat memakan waktu hingga satu jam untuk mulai mereplikasi.

Penting

Replikasi ruang kerja Analitik Log yang ditautkan ke kluster khusus saat ini tidak didukung.

Mengaktifkan replikasi ruang kerja

Untuk mengaktifkan replikasi di ruang kerja Analitik Log Anda, gunakan perintah ini PUT :

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

Mana:

• <subscription_id>: ID langganan yang terkait dengan ruang kerja Anda.
• <resourcegroup_name> : Grup sumber daya yang berisi sumber daya ruang kerja Analitik Log Anda.
• <workspace_name>: Nama ruang kerja Anda.
• <primary_region>: Wilayah utama untuk ruang kerja Analitik Log Anda.
• <secondary_region>: Wilayah tempat Azure Monitor membuat ruang kerja sekunder.

Untuk nilai yang didukung location , lihat Wilayah yang didukung.

Perintah PUT adalah operasi jangka panjang yang dapat memakan waktu untuk diselesaikan. Panggilan yang berhasil mengembalikan 200 kode status. Anda dapat melacak status provisi permintaan Anda, seperti yang dijelaskan dalam Memeriksa status provisi permintaan.

Periksa status provisi permintaan

Untuk memeriksa status provisi permintaan Anda, jalankan perintah ini GET :

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

Mana:

• <subscription_id>: ID langganan yang terkait dengan ruang kerja Anda.
• <resourcegroup_name>: Grup sumber daya yang berisi sumber daya ruang kerja Analitik Log Anda.
• <workspace_name>: Nama ruang kerja Analitik Log Anda.

GET Gunakan perintah untuk memverifikasi bahwa status provisi ruang kerja berubah dari Updating ke Succeeded, dan wilayah sekunder diatur seperti yang diharapkan.

Catatan

Saat Anda mengaktifkan replikasi untuk ruang kerja yang berinteraksi dengan Sentinel, diperlukan waktu hingga 12 hari untuk sepenuhnya mereplikasi data Daftar Tonton dan Inteligensi Ancaman ke ruang kerja sekunder.

Mengaitkan aturan pengumpulan data dengan titik akhir pengumpulan data sistem

Anda menggunakan aturan pengumpulan data (DCR) untuk mengumpulkan data log menggunakan Agen Azure Monitor dan API Penyerapan Log.

Jika Anda memiliki aturan pengumpulan data yang mengirim data ke ruang kerja utama, Anda perlu mengaitkan aturan ke titik akhir pengumpulan data sistem (DCE), yang dibuat Azure Monitor saat Anda mengaktifkan replikasi ruang kerja. Nama titik akhir pengumpulan data sistem identik dengan ID ruang kerja Anda. Hanya aturan pengumpulan data yang Anda kaitkan ke titik akhir pengumpulan data sistem ruang kerja yang mengaktifkan replikasi dan pengalihan. Perilaku ini memungkinkan Anda menentukan set aliran log untuk direplikasi, yang membantu Anda mengontrol biaya replikasi.

Untuk mereplikasi data yang Anda kumpulkan menggunakan aturan pengumpulan data, kaitkan aturan pengumpulan data Anda ke titik akhir pengumpulan data sistem untuk ruang kerja Log Analytics Anda:

1. Di portal Azure, pilih Aturan pengumpulan data.

2. Dari layar Aturan pengumpulan data, pilih aturan pengumpulan data yang mengirim data ke ruang kerja Analitik Log utama Anda.

3. Pada halaman Gambaran Umum aturan pengumpulan data, pilih Konfigurasikan DCE dan pilih titik akhir pengumpulan data sistem dari daftar yang tersedia:

   Untuk detail tentang System DCE, periksa properti objek ruang kerja.

Penting

Aturan pengumpulan data yang tersambung ke titik akhir pengumpulan data sistem ruang kerja hanya dapat menargetkan ruang kerja tertentu tersebut. Aturan pengumpulan data tidak boleh menargetkan tujuan lain, seperti ruang kerja lain atau akun Azure Storage.

Menonaktifkan replikasi ruang kerja

Untuk menonaktifkan replikasi ruang kerja, gunakan perintah ini PUT :

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

Mana:

• <subscription_id>: ID langganan yang terkait dengan ruang kerja Anda.
• <resourcegroup_name> : Grup sumber daya yang berisi sumber daya ruang kerja Anda.
• <workspace_name>: Nama ruang kerja Anda.
• <primary_region>: Wilayah utama untuk ruang kerja Anda.

Perintah PUT adalah operasi jangka panjang yang dapat memakan waktu untuk diselesaikan. Panggilan yang berhasil mengembalikan 200 kode status. Anda dapat melacak status provisi permintaan Anda, seperti yang dijelaskan dalam Memeriksa status provisi permintaan.

Memantau ruang kerja dan kesehatan layanan

Latensi penyerapan atau kegagalan kueri adalah contoh masalah yang sering dapat ditangani dengan melakukan failover ke wilayah sekunder Anda. Masalah tersebut dapat dideteksi dengan menggunakan pemberitahuan Service Health dan kueri log.

Pemberitahuan Service Health berguna untuk masalah terkait layanan. Untuk mengidentifikasi masalah yang memengaruhi ruang kerja spesifik Anda (dan mungkin bukan seluruh layanan), Anda dapat menggunakan langkah-langkah lain:

• Membuat pemberitahuan berdasarkan kesehatan sumber daya ruang kerja
• Mengatur ambang batas Anda sendiri untuk metrik kesehatan ruang kerja
• Buat kueri pemantauan Anda sendiri untuk berfungsi sebagai indikator kesehatan kustom untuk ruang kerja Anda, seperti yang dijelaskan dalam Memantau performa ruang kerja menggunakan kueri, untuk:
  • Mengukur latensi penyerapan per tabel
  • Mengidentifikasi apakah sumber latensi adalah agen pengumpulan atau alur penyerapan
  • Memantau anomali volume penyerapan per tabel dan sumber daya
  • Memantau tingkat keberhasilan kueri per tabel, pengguna, atau sumber daya
  • Membuat pemberitahuan berdasarkan kueri Anda

Catatan

Anda juga dapat menggunakan kueri log untuk memantau ruang kerja sekunder Anda, tetapi perlu diingat bahwa replikasi log dilakukan dalam operasi batch. Latensi yang diukur dapat berfluktuasi dan tidak menunjukkan masalah kesehatan dengan ruang kerja sekunder Anda. Untuk informasi selengkapnya, lihat Mengaudit ruang kerja yang tidak aktif.

Beralih ke ruang kerja sekunder Anda

Selama pengalihan, sebagian besar operasi berfungsi sama seperti saat Anda menggunakan ruang kerja dan wilayah utama. Namun, beberapa operasi memiliki perilaku yang sedikit berbeda atau diblokir. Untuk informasi selengkapnya, lihat Pembatasan dan batasan.

Kapan saya harus beralih?

Anda memutuskan kapan harus beralih ke ruang kerja sekunder Anda dan beralih kembali ke ruang kerja utama Anda berdasarkan performa dan pemantauan kesehatan yang sedang berlangsung serta standar dan persyaratan sistem Anda.

Ada beberapa poin yang perlu dipertimbangkan dalam paket Anda untuk pengalihan, seperti yang dijelaskan dalam subbagian berikut.

Jenis dan cakupan masalah

Proses pengalihan merutekan permintaan penyerapan dan kueri ke wilayah sekunder Anda, yang biasanya melewati komponen yang rusak yang menyebabkan latensi atau kegagalan di wilayah utama Anda. Akibatnya, pengalihan tidak mungkin membantu jika:

• Ada masalah lintas regional dengan sumber daya yang mendasar. Misalnya, jika jenis sumber daya yang sama gagal di wilayah utama dan sekunder Anda.
• Anda mengalami masalah yang terkait dengan manajemen ruang kerja, seperti mengubah retensi ruang kerja. Operasi manajemen ruang kerja selalu ditangani di wilayah utama Anda. Selama peralihan, operasi manajemen ruang kerja diblokir.

Durasi masalah

Pengalihan tidak seketika. Proses pengalihan permintaan bergantung pada pembaruan DNS, yang diambil beberapa klien dalam beberapa menit sementara yang lain dapat membutuhkan lebih banyak waktu. Oleh karena itu, sangat membantu untuk memahami apakah masalah dapat diselesaikan dalam beberapa menit. Jika masalah yang diamati konsisten atau berkelanjutan, jangan menunggu untuk beralih. Berikut adalah beberapa contoh:

• Penyerapan: Masalah dengan alur penyerapan di wilayah utama Anda dapat memengaruhi replikasi data ke ruang kerja sekunder Anda. Selama pengalihan, log dikirim ke alur penyerapan di wilayah sekunder.

• Kueri: Jika kueri di ruang kerja utama Anda gagal atau waktu habis, pemberitahuan pencarian log dapat terpengaruh. Dalam skenario ini, alihkan ke ruang kerja sekunder Anda untuk memastikan semua pemberitahuan Anda dipicu dengan benar.

Data ruang kerja sekunder

Log yang diserap ke ruang kerja utama anda sebelum mengaktifkan replikasi tidak disalin ke ruang kerja sekunder. Jika Anda mengaktifkan replikasi ruang kerja tiga jam yang lalu dan sekarang Anda beralih ke ruang kerja sekunder, kueri Anda hanya dapat mengembalikan data dari tiga jam terakhir.

Sebelum Anda beralih wilayah selama pengalihan, ruang kerja sekunder Anda harus berisi volume log yang berguna. Sebaiknya tunggu setidaknya satu minggu setelah Anda mengaktifkan replikasi sebelum Anda memicu pengalihan. Tujuh hari memungkinkan data yang memadai tersedia di wilayah sekunder Anda.

Pengalihan pemicu

Sebelum Anda beralih, konfirmasikan bahwa operasi replikasi ruang kerja berhasil diselesaikan. Switchover hanya berhasil ketika ruang kerja sekunder dikonfigurasi dengan benar.

Untuk beralih ke ruang kerja sekunder Anda, gunakan perintah ini POST :

POST 
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/locations/<secondary_region>/workspaces/<workspace_name>/failover?api-version=2023-01-01-preview

Mana:

• <subscription_id>: ID langganan yang terkait dengan ruang kerja Anda.
• <resourcegroup_name> : Grup sumber daya yang berisi sumber daya ruang kerja Anda.
• <secondary_region>: Wilayah yang akan dialihkan selama pengalihan.
• <workspace_name>: Nama ruang kerja yang akan dialihkan selama pengalihan.

Perintah POST adalah operasi jangka panjang yang dapat memakan waktu untuk diselesaikan. Panggilan yang berhasil mengembalikan 202 kode status. Anda dapat melacak status provisi permintaan Anda, seperti yang dijelaskan dalam Memeriksa status provisi permintaan.

Beralih kembali ke ruang kerja utama Anda

Proses switchback membatalkan pengalihan rute kueri dan permintaan penyerapan log ke ruang kerja sekunder. Saat Anda beralih kembali, Azure Monitor kembali ke kueri perutean dan mencatat permintaan penyerapan ke ruang kerja utama Anda.

Saat Anda beralih ke wilayah sekunder, Azure Monitor mereplikasi log dari ruang kerja sekunder Anda ke ruang kerja utama Anda. Jika pemadaman berdampak pada proses penyerapan log di wilayah utama, diperlukan waktu bagi Azure Monitor untuk menyelesaikan penyerapan log yang direplikasi ke ruang kerja utama Anda.

Kapan saya harus beralih kembali?

Ada beberapa poin yang perlu dipertimbangkan dalam paket Anda untuk beralih kembali, seperti yang dijelaskan dalam subbagian berikut.

Status replikasi log

Sebelum Anda beralih kembali, verifikasi bahwa Azure Monitor selesai mereplikasi semua log yang diserap selama pengalihan ke wilayah utama. Jika Anda beralih kembali sebelum semua log mereplikasi ke ruang kerja utama, kueri Anda mungkin mengembalikan hasil parsial hingga penyerapan log selesai.

Anda bisa mengkueri ruang kerja utama Anda di portal Azure untuk wilayah tidak aktif, seperti yang dijelaskan dalam Mengaudit ruang kerja yang tidak aktif.

Kesehatan ruang kerja utama

Ada dua item kesehatan penting untuk memeriksa persiapan untuk beralih kembali ke ruang kerja utama Anda:

• Konfirmasikan tidak ada pemberitahuan Service Health yang terutang untuk ruang kerja dan wilayah utama.
• Konfirmasikan ruang kerja utama Anda menyerap log dan memproses kueri seperti yang diharapkan.

Untuk contoh cara mengkueri ruang kerja utama Anda saat ruang kerja sekunder Anda aktif dan melewati perutean ulang permintaan ke ruang kerja sekunder Anda, lihat Mengaudit ruang kerja yang tidak aktif.

Tombol balik pemicu

Sebelum Anda beralih kembali, konfirmasikan kesehatan ruang kerja utama dan selesaikan replikasi log.

Proses switchback memperbarui catatan DNS Anda. Setelah pembaruan catatan DNS, perlu waktu bagi semua klien untuk menerima pengaturan DNS yang diperbarui dan melanjutkan perutean ke ruang kerja utama.

Untuk beralih kembali ke ruang kerja utama Anda, gunakan perintah ini POST :

POST

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/failback?api-version=2023-01-01-preview

Mana:

• <subscription_id>: ID langganan yang terkait dengan ruang kerja Anda.
• <resourcegroup_name> : Grup sumber daya yang berisi sumber daya ruang kerja Anda.
• <workspace_name>: Nama ruang kerja yang akan dialihkan selama switchback.

Perintah POST adalah operasi jangka panjang yang dapat memakan waktu untuk diselesaikan. Panggilan yang berhasil mengembalikan 202 kode status. Anda dapat melacak status provisi permintaan Anda, seperti yang dijelaskan dalam Memeriksa status provisi permintaan.

Mengaudit ruang kerja yang tidak aktif

Secara default, wilayah aktif ruang kerja Anda adalah wilayah tempat Anda membuat ruang kerja, dan wilayah yang tidak aktif adalah wilayah sekunder, tempat Azure Monitor membuat ruang kerja yang direplikasi.

Saat Anda memicu failover, sakelar ini – wilayah sekunder diaktifkan, dan wilayah utama menjadi tidak aktif. Kami mengatakan ini tidak aktif karena bukan target langsung dari penyerapan log dan permintaan kueri.

Ini berguna untuk mengkueri wilayah yang tidak aktif sebelum Anda beralih antar wilayah untuk memverifikasi bahwa ruang kerja di wilayah tidak aktif memiliki log yang ingin Anda lihat di sana.

Wilayah tidak aktif kueri

Untuk mengkueri data log di wilayah yang tidak aktif, gunakan perintah GET ini:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=<query>&timespan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>

Misalnya, untuk menjalankan kueri sederhana seperti Perf | count untuk hari terakhir di wilayah sekunder Anda, gunakan:

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=Perf%20|%20count&timespan=P1D&overrideWorkspaceRegion=secondary

Anda dapat mengonfirmasi bahwa Azure Monitor menjalankan kueri Anda di wilayah yang dimaksudkan dengan memeriksa bidang ini dalam LAQueryLogs tabel, yang dibuat saat Anda mengaktifkan audit kueri di ruang kerja Analitik Log Anda:

• isWorkspaceInFailover: Menunjukkan apakah ruang kerja berada dalam mode pengalihan selama kueri. Jenis datanya adalah Boolean (True, False).
• workspaceRegion: Wilayah ruang kerja yang ditargetkan oleh kueri. Jenis datanya adalah String.

Memantau performa ruang kerja menggunakan kueri

Sebaiknya gunakan kueri di bagian ini untuk membuat aturan pemberitahuan yang memberi tahu Anda tentang kemungkinan masalah kesehatan atau performa ruang kerja. Namun, keputusan untuk beralih memerlukan pertimbangan hati-hati Anda, dan tidak boleh dilakukan secara otomatis.

Dalam aturan kueri, Anda dapat menentukan kondisi untuk beralih ke ruang kerja sekunder Setelah sejumlah pelanggaran tertentu. Untuk informasi selengkapnya, lihat Membuat atau mengedit aturan pemberitahuan pencarian log.

Dua pengukuran performa ruang kerja yang signifikan termasuk latensi penyerapan dan volume penyerapan. Bagian berikut menjelajahi opsi pemantauan ini.

Memantau latensi penyerapan end-to-end

Latensi penyerapan mengukur waktu yang diperlukan untuk menyerap log ke ruang kerja. Pengukuran waktu dimulai ketika peristiwa awal yang dicatat terjadi dan berakhir saat log disimpan di ruang kerja Anda. Total latensi penyerapan terdiri dari dua bagian:

• Latensi agen: Waktu yang diperlukan oleh agen untuk melaporkan peristiwa.
• Latensi alur penyerapan (backend): Waktu yang diperlukan untuk alur penyerapan untuk memproses log dan menulisnya ke ruang kerja Anda.

Jenis data yang berbeda memiliki latensi penyerapan yang berbeda. Anda dapat mengukur penyerapan untuk setiap jenis data secara terpisah, atau membuat kueri generik untuk semua jenis, dan kueri yang lebih halus untuk jenis tertentu yang lebih penting bagi Anda. Kami sarankan Anda mengukur persentil ke-90 dari latensi penyerapan, yang lebih sensitif terhadap perubahan daripada rata-rata atau persentil ke-50 (median).

Bagian berikut menunjukkan cara menggunakan kueri untuk memeriksa latensi penyerapan untuk ruang kerja Anda.

Mengevaluasi latensi penyerapan garis besar tabel tertentu

Mulailah dengan menentukan latensi garis besar tabel tertentu selama beberapa hari.

Contoh kueri ini membuat bagan persentil ke-90 latensi penyerapan pada tabel Perf:

// Assess the ingestion latency baseline for a specific data type
Perf
| where TimeGenerated > ago(3d) 
| project TimeGenerated, 
IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize LatencyIngestion90Percentile=percentile(IngestionDurationSeconds, 90) by bin(TimeGenerated, 1h) 
| render timechart

Setelah Anda menjalankan kueri, tinjau hasil dan bagan yang dirender untuk menentukan latensi yang diharapkan untuk tabel tersebut.

Memantau dan memperingatkan latensi penyerapan saat ini

Setelah Anda membuat latensi penyerapan garis besar untuk tabel tertentu, buat aturan pemberitahuan pencarian log untuk tabel berdasarkan perubahan latensi dalam waktu singkat.

Kueri ini menghitung latensi penyerapan selama 20 menit terakhir:

// Track the recent ingestion latency (in seconds) of a specific table
Perf
| where TimeGenerated > ago(20m) 
| extend IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize Ingestion90Percent_seconds=percentile(IngestionDurationSeconds, 90)

Karena Anda dapat mengharapkan beberapa fluktuasi, buat kondisi aturan pemberitahuan untuk memeriksa apakah kueri mengembalikan nilai yang jauh lebih besar dari garis besar.

Menentukan sumber latensi penyerapan

Ketika Anda melihat latensi penyerapan total Anda naik, Anda dapat menggunakan kueri untuk menentukan apakah sumber latensi adalah agen atau alur penyerapan.

Kueri ini membuat bagan latensi persentil ke-90 agen dan alur, secara terpisah:

// Assess agent and pipeline (backend) latency
Perf
| where TimeGenerated > ago(1h) 
| extend AgentLatencySeconds = (_TimeReceived-TimeGenerated)/1s,
	  PipelineLatencySeconds=(ingestion_time()-_TimeReceived)/1s
| summarize percentile(AgentLatencySeconds,90), percentile(PipelineLatencySeconds,90) by bin(TimeGenerated,5m)
| render columnchart

Catatan

Meskipun bagan menampilkan data persentil ke-90 sebagai kolom bertumpuk, jumlah data dalam dua bagan tidak sama dengan persentil ke-90 penyerapan total .

Memantau volume penyerapan

Pengukuran volume penyerapan dapat membantu mengidentifikasi perubahan tak terduga pada total atau volume penyerapan khusus tabel untuk ruang kerja Anda. Pengukuran volume kueri dapat membantu Anda mengidentifikasi masalah performa dengan penyerapan log. Beberapa pengukuran volume yang berguna meliputi:

• Total volume penyerapan per tabel
• Volume penyerapan konstan (berhenti)
• Anomali penyerapan - lonjakan dan penurunan volume penyerapan

Bagian berikut menunjukkan cara menggunakan kueri untuk memeriksa volume penyerapan untuk ruang kerja Anda.

Memantau total volume penyerapan per tabel

Anda dapat menentukan kueri untuk memantau volume penyerapan per tabel di ruang kerja Anda. Kueri dapat menyertakan pemberitahuan yang memeriksa perubahan tak terduga pada total atau volume khusus tabel.

Kueri ini menghitung total volume penyerapan selama satu jam terakhir per tabel dalam megabyte per detik (MB):

// Calculate total ingestion volume over the past hour per table
Usage 
| where TimeGenerated > ago(1h) 
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated,1h), DataType

Periksa kesibukan penyerapan

Jika Anda menyerap log melalui agen, Anda dapat menggunakan heartbeat agen untuk mendeteksi konektivitas. Heartbeat yang masih dapat mengungkapkan penghentian penyerapan log ke ruang kerja Anda. Saat data kueri mengungkapkan penyerapan yang terdiam, Anda dapat menentukan kondisi untuk memicu respons yang diinginkan.

Kueri berikut memeriksa heartbeat agen untuk mendeteksi masalah konektivitas:

// Count agent heartbeats in the last ten minutes
Heartbeat 
| where TimeGenerated>ago(10m) 
| count

Memantau anomali penyerapan

Anda dapat mengidentifikasi lonjakan dan penurunan di data volume penyerapan ruang kerja Anda dengan berbagai cara. Gunakan fungsi series_decompose_anomalies() untuk mengekstrak anomali dari volume penyerapan yang Anda pantau di ruang kerja Anda, atau buat detektor anomali Anda sendiri untuk mendukung skenario ruang kerja unik Anda.

Mengidentifikasi anomali menggunakan series_decompose_anomalies

Fungsi ini series_decompose_anomalies() mengidentifikasi anomali dalam serangkaian nilai data. Kueri ini menghitung volume penyerapan per jam dari setiap tabel di ruang kerja Analitik Log Anda, dan menggunakan series_decompose_anomalies() untuk mengidentifikasi anomali:

// Calculate hourly ingestion volume per table and identify anomalies
Usage
| where TimeGenerated > ago(24h)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| summarize
    Timestamp=make_list(TimeGenerated),
    IngestionVolumeMB=make_list(IngestionVolumeMB)
    by DataType
| extend series_decompose_anomalies(IngestionVolumeMB)
| mv-expand
    Timestamp,
    IngestionVolumeMB,
    series_decompose_anomalies_IngestionVolumeMB_ad_flag,
    series_decompose_anomalies_IngestionVolumeMB_ad_score,
    series_decompose_anomalies_IngestionVolumeMB_baseline
| where series_decompose_anomalies_IngestionVolumeMB_ad_flag != 0

Untuk informasi selengkapnya tentang cara menggunakan series_decompose_anomalies() untuk mendeteksi anomali dalam data log, lihat Mendeteksi dan menganalisis anomali menggunakan kemampuan pembelajaran mesin KQL di Azure Monitor.

Membuat detektor anomali Anda sendiri

Anda dapat membuat detektor anomali kustom untuk mendukung persyaratan skenario untuk konfigurasi ruang kerja Anda. Bagian ini menyediakan contoh untuk menunjukkan proses.

Kueri berikut menghitung:

• Volume penyerapan yang diharapkan: Per jam, menurut tabel (berdasarkan median median, tetapi Anda dapat menyesuaikan logika)
• Volume penyerapan aktual: Per jam, menurut tabel

Untuk memfilter perbedaan yang tidak signifikan antara volume penyerapan yang diharapkan dan aktual, kueri menerapkan dua filter:

• Tingkat perubahan: Lebih dari 150% atau di bawah 66% dari volume yang diharapkan, per tabel
• Volume perubahan: Menunjukkan apakah volume yang meningkat atau menurun lebih dari 0,1% dari volume bulanan tabel tersebut

// Calculate expected vs actual hourly ingestion per table
let TimeRange=24h;
let MonthlyIngestionByType=
    Usage
    | where TimeGenerated > ago(30d)
    | summarize MonthlyIngestionMB=sum(Quantity) by DataType;
// Calculate the expected ingestion volume by median of hourly medians
let ExpectedIngestionVolumeByType=
    Usage
    | where TimeGenerated > ago(TimeRange)
    | project TimeGenerated, DataType, Quantity
    | summarize IngestionMedian=percentile(Quantity, 50) by bin(TimeGenerated, 1h), DataType
    | summarize ExpectedIngestionVolumeMB=percentile(IngestionMedian, 50) by DataType;
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| join kind=inner (ExpectedIngestionVolumeByType) on DataType
| extend GapVolumeMB = round(IngestionVolumeMB-ExpectedIngestionVolumeMB,2)
| where GapVolumeMB != 0
| extend Trend=iff(GapVolumeMB > 0, "Up", "Down")
| extend IngestedVsExpectedAsPercent = round(IngestionVolumeMB * 100 / ExpectedIngestionVolumeMB, 2)
| join kind=inner (MonthlyIngestionByType) on DataType
| extend GapAsPercentOfMonthlyIngestion = round(abs(GapVolumeMB) * 100 / MonthlyIngestionMB, 2)
| project-away DataType1, DataType2
// Determine whether the spike/deep is substantial: over 150% or under 66% of the expected volume for this data type
| where IngestedVsExpectedAsPercent > 150 or IngestedVsExpectedAsPercent < 66
// Determine whether the gap volume is significant: over 0.1% of the total monthly ingestion volume to this workspace
| where GapAsPercentOfMonthlyIngestion > 0.1
| project
    Timestamp=format_datetime(todatetime(TimeGenerated), 'yyyy-MM-dd HH:mm:ss'),
    Trend,
    IngestionVolumeMB,
    ExpectedIngestionVolumeMB,
    IngestedVsExpectedAsPercent,
    GapAsPercentOfMonthlyIngestion

Memantau keberhasilan dan kegagalan kueri

Setiap kueri mengembalikan kode respons yang menunjukkan keberhasilan atau kegagalan. Saat kueri gagal, respons juga menyertakan jenis kesalahan. Lonjakan kesalahan yang tinggi dapat menunjukkan masalah dengan ketersediaan ruang kerja atau performa layanan.

Kueri ini menghitung berapa banyak kueri yang mengembalikan kode kesalahan server:

// Count query errors
LAQueryLogs 
| where ResponseCode>=500 and ResponseCode<600 
| count

Pembatasan dan batasan

• Replikasi ruang kerja Analitik Log yang ditautkan ke kluster khusus saat ini tidak didukung.

• Operasi penghapusan menyeluruh, yang menghapus rekaman dari ruang kerja, menghapus rekaman yang relevan dari ruang kerja utama dan sekunder. Jika salah satu instans ruang kerja tidak tersedia, operasi pembersihan gagal.

• Replikasi aturan pemberitahuan di seluruh wilayah saat ini tidak didukung. Karena Azure Monitor mendukung kueri wilayah tidak aktif, pemberitahuan berbasis kueri terus berfungsi saat Anda beralih antar wilayah kecuali layanan Pemberitahuan di wilayah aktif tidak berfungsi dengan baik atau aturan pemberitahuan tidak tersedia.

• Saat Anda mengaktifkan replikasi untuk ruang kerja yang berinteraksi dengan Sentinel, diperlukan waktu hingga 12 hari untuk sepenuhnya mereplikasi data Daftar Tonton dan Inteligensi Ancaman ke ruang kerja sekunder.

• Selama pengalihan, operasi manajemen ruang kerja tidak didukung, termasuk:

  • Mengubah retensi ruang kerja, tingkat harga, batas harian, dan sebagainya
  • Ubah pengaturan jaringan
  • Mengubah skema melalui log kustom baru atau menghubungkan log platform dari penyedia sumber daya baru, seperti mengirim log diagnostik dari jenis sumber daya baru

• Solusi yang menargetkan kemampuan agen Analitik Log warisan tidak didukung selama pengalihan. Oleh karena itu, selama pengalihan, data solusi diserap dari semua agen.

• Proses failover memperbarui catatan Sistem Nama Domain (DNS) Anda untuk mengalihkan semua permintaan penyerapan ke wilayah sekunder Anda untuk diproses. Beberapa klien HTTP memiliki "koneksi lengket" dan mungkin membutuhkan waktu lebih lama untuk mengambil DNS yang diperbarui DNS. Selama peralihan, klien ini mungkin mencoba menyerap log melalui wilayah utama selama beberapa waktu. Anda mungkin menyerap log ke ruang kerja utama Anda menggunakan berbagai klien, termasuk Agen Analitik Log warisan, Agen Azure Monitor, kode (menggunakan API Penyerapan Log atau API pengumpulan data HTTP warisan), dan layanan lainnya, seperti Sentinel.

• Fitur-fitur ini saat ini tidak didukung atau hanya didukung sebagian:

  Fitur	Dukungan
  Paket tabel tambahan	Tidak didukung. Azure Monitor tidak mereplikasi data dalam tabel dengan paket log Tambahan ke ruang kerja sekunder Anda. Oleh karena itu, data ini tidak dilindungi dari kehilangan data jika terjadi kegagalan regional dan tidak tersedia saat Anda beralih ke ruang kerja sekunder Anda.
  Cari pekerjaan, Pulihkan	Didukung sebagian - Operasi pencarian pekerjaan dan pemulihan membuat tabel dan mengisinya dengan hasil pencarian atau data yang dipulihkan. Setelah Anda mengaktifkan replikasi ruang kerja, tabel baru yang dibuat untuk operasi ini mereplikasi ke ruang kerja sekunder Anda. Tabel yang diisi sebelum Anda mengaktifkan replikasi tidak direplikasi. Jika operasi ini sedang berlangsung saat Anda beralih, hasilnya tidak terduga. Ini mungkin berhasil diselesaikan tetapi tidak mereplikasi, atau mungkin gagal, tergantung pada kesehatan ruang kerja Anda dan waktu yang tepat.
  Application Insights melalui ruang kerja Analitik Log	Tidak didukung
  VM Insights	Tidak didukung
  Insight Kontainer	Tidak didukung
  Private Link	Tidak didukung selama failover

Konten terkait

• Memantau kesehatan ruang kerja Analitik Log
• Memantau masalah operasional di ruang kerja Azure Monitor Log Analytics Anda