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

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.

Replikasi ruang kerja adalah fitur berbayar dan dapat dikonfigurasi yang melindungi dari insiden di seluruh wilayah. Ini melengkapi zona ketersediaan, perlindungan dalam wilayah transparan terhadap kegagalan pusat data. Untuk gambaran umum komprehensif tentang semua opsi ketahanan, lihat Keandalan dalam Log Azure Monitor.

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.

Cara kerja dari replikasi ruang kerja Log Analitik

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

Proses replikasi ruang kerja menghasilkan salinan 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 Microsoft 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 masukkan ke dalam ruang kerja sebelum Anda mengaktifkan replikasi ruang kerja tidak akan disalin.

Catatan

Replikasi ruang kerja sepenuhnya mereplikasi semua skema tabel, tetapi hanya mengirim log baru yang diserap sejak replikasi diaktifkan. Log yang dimasukkan ke ruang kerja sebelum Anda mengaktifkan replikasi tidak akan disalin.

Jika terjadi pemadaman yang memengaruhi wilayah utama Anda, Anda dapat beralih dan mengalihkan semua permintaan pengumpulan 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 ruang kerja utama 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.

Catatan

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 berusaha ulang untuk mereplikasi data secara berkala.

Perlindungan terhadap kehilangan data dalam perjalanan ketika terjadi kegagalan regional

Azure Monitor memiliki beberapa mekanisme untuk memastikan bahwa data saat transit tidak hilang ketika ada kegagalan di wilayah utama.

Azure Monitor melindungi data yang mencapai titik akhir penyerapan wilayah utama saat alur wilayah utama tidak tersedia untuk memproses data. Ketika alur tersedia, alur terus memproses data saat transit, dan Azure Monitor menyerap dan mereplikasi data ke wilayah sekunder.

Jika titik akhir ingestasi wilayah utama tidak tersedia, Agen Azure Monitor secara berkala mencoba mengirim data log ke titik akhir. Titik akhir penyerapan data di wilayah sekunder mulai menerima data dari agen beberapa menit setelah Anda memicu pengalihan.

Jika Anda menulis aplikasi klien Anda sendiri untuk mengirim data log ke ruang kerja Analitik Log Anda, pastikan klien tersebut menangani permintaan ingesti yang gagal.

Pertimbangan penyebaran

Catatan

Replikasi ruang kerja saat ini tidak mendukung replikasi tabel Tambahan. Jangan aktifkan di ruang kerja yang menyertakan tabel Tambahan. Tabel tambahan tidak direplikasi, dan oleh karena itu tidak dilindungi dari kehilangan data jika terjadi kegagalan regional dan tidak tersedia saat Anda beralih ke ruang kerja sekunder Anda.

Operasi manajemen ruang kerja tidak dapat dimulai selama pengalihan, termasuk:
- Perubahan retensi ruang kerja, tingkatan harga, batas harian, dan sebagainya
- Perubahan pengaturan jaringan
- Perubahan skema melalui log kustom baru atau menghubungkan log platform dari penyedia sumber daya baru, seperti mengirim log diagnostik dari jenis sumber daya baru
Proses failover memperbarui catatan Sistem Nama Domain (DNS) Anda untuk mengalihkan semua permintaan data masuk ke wilayah sekunder Anda untuk pemrosesan. Beberapa klien HTTP memiliki "koneksi lengket" dan mungkin membutuhkan waktu lebih lama untuk mengambil pembaruan DNS. Selama peralihan, klien ini mungkin mencoba menyerap log melalui wilayah utama selama beberapa waktu. Anda mungkin memasukkan log ke ruang kerja utama Anda menggunakan berbagai klien, termasuk Agen Analitik Log lama, Agen Azure Monitor, kode (menggunakan API Penyerapan Log atau API pengumpulan data HTTP lama), dan layanan lainnya, seperti Microsoft Sentinel.

Penting

Aturan pemberitahuan pencarian log terus berfungsi saat Anda beralih antar wilayah kecuali layanan Pemberitahuan di wilayah aktif tidak berfungsi dengan baik atau aturan pemberitahuan tidak tersedia. Ini dapat terjadi, misalnya, jika wilayah tempat aturan pemberitahuan dibuat sepenuhnya tidak berfungsi. Replikasi aturan pemberitahuan di seluruh wilayah tidak dilakukan secara otomatis sebagai bagian dari replikasi ruang kerja, tetapi dapat dilakukan oleh pengguna (misalnya dengan mengekspor dari wilayah utama dan mengimpor ke sekunder).

Operasi penghapusan, yang menghapus rekaman dari ruang kerja, menghilangkan rekaman yang relevan dari ruang kerja utama dan sekunder. Jika salah satu instance ruang kerja tidak tersedia, operasi pembersihan akan gagal.
Ruang kerja yang direplikasi tidak dapat dihapus. Untuk menghapus ruang kerja dengan benar, pertama-tama nonaktifkan replikasi.
Microsoft Sentinel memperbarui log di tabel Daftar Pantauan dan Intelijen Ancaman setiap 12 hari. Jadi, karena hanya log baru yang diserap ke ruang kerja yang direplikasi, diperlukan waktu hingga 12 hari untuk sepenuhnya mereplikasi data Daftar Pengawasan dan Inteligensi Ancaman ke lokasi sekunder.
Kemampuan menargetkan solusi dari agen Analitik Log lama tidak dapat didukung selama pengalihan. Selama peralihan, data solusi diserap dari semua agen.

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

Fitur	Dukungan
Rencana tabel tambahan	Tidak didukung. Azure Monitor tidak mereplikasi data di tabel dengan rencana 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 data dan pemulihan membuat tabel dan mengisinya dengan hasil pencarian atau data yang telah 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 pada ruang kerja Log Analytics	Tidak didukung
Wawasan VM	Tidak didukung
Wawasan Kontainer	Tidak didukung
Tautan Pribadi	Dukungan

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 wilayah dan wilayah ini saat ini didukung:

Grup Wilayah	Wilayah utama	Wilayah sekunder (lokasi replikasi)
Amerika Utara	Kanada Tengah Kanada Timur AS Tengah US Timur* US Timur 2* US Tengah Utara Amerika Serikat Tengah Selatan Barat Tengah AS US Barat US Barat 2 Barat AS 3	Kanada Tengah AS Tengah US Timur* US Timur 2* US Barat US Barat 2 Barat AS 3
Amerika Selatan	Brasil Selatan Brasil Tenggara	Brasil Selatan Brasil Tenggara
Eropa	Prancis Tengah Prancis Selatan Jerman Utara Jerman Barat Tengah Italia Utara Eropa Utara Norwegia Timur Norwegia Barat Polandia Tengah Inggris Selatan Spanyol Tengah Swedia Tengah Swedia Selatan Swiss Utara Swiss Barat Eropa Barat Inggris Barat	Prancis Tengah Jerman Barat Tengah Eropa Utara Inggris Selatan Eropa Barat Inggris Barat
Timur Tengah	Qatar Tengah UEA Tengah UAE Utara	Qatar Tengah UEA Tengah UAE Utara
India	India Tengah Jio India Tengah Jio India Barat India Selatan	India Tengah Jio India Tengah Jio India Barat India Selatan
Asia Pasifik	Asia Timur Jepang Timur Jepang Barat Korea Tengah Korea Selatan Asia Tenggara	Asia Timur Jepang Timur Jepang Barat Korea Tengah Asia Tenggara
Oseania	Australia Tengah Australia Tengah 2 Australia Timur Australia Tenggara	Australia Tengah Australia Timur Australia Tenggara
Afrika	Afrika Selatan Utara Afrika Selatan Barat	Afrika Selatan Utara Afrika Selatan Barat

Catatan

Ruang kerja yang terletak di Timur AS, Timur AS 2, dan AS Tengah Selatan hanya dapat mereplikasi ke wilayah sekunder di luar ketiga wilayah tersebut. Silakan pilih lokasi sekunder lain dari grup wilayah Amerika Utara.

Persyaratan tempat penyimpanan 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 Microsoft Azure 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 memengaruhi pelanggan Microsoft Azure 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 Pertimbangan penyebaran.

Rencana harga

Saat mengaktifkan replikasi ruang kerja, Anda dikenakan biaya untuk replikasi semua data yang Anda masukkan ke ruang kerja Anda, kecuali data dengan _IsBillable = false.

Penting

Jika Anda mengirim data ke ruang kerja menggunakan Agen Azure Monitor, API Penyerapan Log, Azure Event Hubs, atau sumber data lain yang menggunakan aturan pengumpulan data, pastikan Anda mengaitkan aturan pengumpulan data dengan titik akhir pengumpulan data ruang kerja Anda. Asosiasi ini memastikan bahwa data yang Anda serap direplikasi ke ruang kerja sekunder Anda. Jika Anda tidak mengaitkan aturan pengumpulan data dengan titik akhir pengumpulan data ruang kerja, Anda masih dikenakan biaya untuk semua data yang Anda serap ke ruang kerja Anda, meskipun data tidak direplikasi.

Izin yang diperlukan

Perbuatan	Izin yang diperlukan
Mengaktifkan replikasi ruang kerja	`Microsoft.OperationalInsights/workspaces/write` dan izin `Microsoft.Insights/dataCollectionEndpoints/write`, sebagaimana disediakan oleh bawaan peran Kontributor Pemantauan, misalnya
Beralih dan beralih kembali (memicu failover dan failback)	`Microsoft.OperationalInsights/locations/workspaces/failover`, `Microsoft.OperationalInsights/workspaces/failback`, `Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action`, dan `Microsoft.Insights/dataCollectionEndpoints/triggerFailback/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 "Monitoring Contributor", misalnya

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.

Menggunakan kluster khusus

Jika ruang kerja Anda ditautkan ke kluster khusus, Anda harus terlebih dahulu mengaktifkan replikasi pada kluster, dan baru kemudian di ruang kerja. Operasi ini membuat kluster kedua di wilayah sekunder Anda (tanpa biaya tambahan di luar biaya replikasi), untuk memungkinkan ruang kerja Anda tetap menggunakan kluster khusus meskipun Anda gagal. Ini juga berarti fitur seperti kunci terkelola kluster (CMK) terus berfungsi (dengan kunci yang sama) selama failover. Setelah replikasi lintas wilayah diaktifkan, lanjutkan untuk mengaktifkan replikasi untuk satu atau beberapa ruang kerja yang ditautkan ke kluster ini.

Penting

Setelah replikasi kluster diaktifkan, mengubah tujuan replikasi memerlukan penonaktifan replikasi dan mengaktifkannya kembali terhadap lokasi yang berbeda.

Untuk mengaktifkan replikasi pada kluster khusus Anda, gunakan perintah berikut. Mengaktifkan replikasi pada kluster adalah operasi jangka panjang yang mungkin membutuhkan waktu untuk diselesaikan, dan Anda dapat melacak status yang tepat seperti yang dijelaskan dalam Memeriksa status provisi kluster.

Azure CLI
REST API

Untuk mengaktifkan replikasi kluster, gunakan perintah az rest Azure CLI untuk memanggil REST API Azure Resource Manager:

az rest --method put \
  --uri "/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01" \
  --body '{
    "properties": {
      "replication": {
        "enabled": true,
        "location": "<secondary_region>"
      }
    },
    "location": "<primary_region>"
  }'

Untuk mengaktifkan replikasi kluster, gunakan perintah ini PUT :

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

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

Di mana

<subscription_id>: ID langganan yang terkait dengan kluster Anda
<resourcegroup_name> : Grup sumber daya yang berisi sumber daya kluster Analitik Log Anda
<cluster_name>: Nama kluster khusus Anda
<primary_region>: Wilayah utama untuk kluster khusus Analitik Log Anda
<secondary_region>: Wilayah tempat Azure Monitor membuat kluster khusus sekunder

Untuk memeriksa status provisi kluster Anda, gunakan perintah az monitor log-analytics cluster show Azure CLI:

az monitor log-analytics cluster show \
  --resource-group <resourcegroup_name> \
  --cluster-name <cluster_name> \
  --query "replication.provisioningState"

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

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/clusters/<cluster_name>?api-version=2025-02-01

Di mana

<subscription_id>: ID langganan yang terkait dengan kluster Anda
<resourcegroup_name>: Grup sumber daya yang berisi sumber daya kluster Analitik Log Anda
<cluster_name>: Nama kluster Analitik Log Anda

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

Catatan

Saat Anda mengaktifkan replikasi kluster, kluster baru sedang disediakan di lokasi sekunder. Proses ini dapat memakan waktu 1-2 jam.

Mengaktifkan replikasi ruang kerja

Azure CLI
REST API

Untuk mengaktifkan replikasi di ruang kerja Analitik Log Anda, gunakan perintah az rest Azure CLI untuk memanggil REST API Azure Resource Manager:

az rest --method put \
  --uri "/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2025-02-01" \
  --body '{
    "properties": {
      "replication": {
        "enabled": true,
        "location": "<secondary_region>"
      }
    },
    "location": "<primary_region>"
  }'

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=2025-02-01

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

Di 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 wilayah yang didukung, lihat Wilayah yang didukung.

Perintah aktifkan replikasi ruang kerja adalah operasi jangka panjang yang dapat memakan waktu untuk diselesaikan. Anda dapat melacak status provisi permintaan Anda, seperti yang dijelaskan dalam Memeriksa status provisi ruang kerja.

Penting

Jika ruang kerja Anda ditautkan ke kluster khusus, pertama-tama aktifkan replikasi pada kluster. Perhatikan juga bahwa lokasi sekunder ruang kerja Anda harus identik dengan lokasi sekunder kluster khususnya.

Periksa status provisi ruang kerja

Azure CLI
REST API

Untuk memeriksa status penyediaan ruang kerja Anda, gunakan perintah Azure CLI az monitor log-analytics workspace show.

az monitor log-analytics workspace show \
  --resource-group <resourcegroup_name> \
  --workspace-name <workspace_name> \
  --query "replication.provisioningState"

Untuk memeriksa status provisi ruang kerja Anda, jalankan perintah ini GET :

GET

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

Di 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.

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.

Periksa apakah replikasi diaktifkan di ruang kerja

Untuk memeriksa apakah dan di mana replikasi ruang kerja diaktifkan, tinjau pengaturan ini.

Di portal Microsoft Azure, pilih > ruang kerja. Jika replikasi diaktifkan, bagian Esensial menampilkan lokasi Sekunder, yang menunjukkan wilayah ruang kerja yang direplikasi.

Bagian Esensial yang sama memiliki Tampilan JSON yang menampilkan detail replikasi sebagai objek JSON, yang juga tersedia melalui REST/CLI.

Mengaitkan aturan pengumpulan data dengan titik akhir pengumpulan data ruang kerja

Agen Azure Monitor, API Penyerapan Log, dan Azure Event Hubs mengumpulkan data dan mengirimkannya ke tujuan yang Anda tentukan berdasarkan cara Anda menyiapkan aturan pengumpulan data (DCR).

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 ruang kerja identik dengan ID ruang kerja Anda. Hanya aturan pengumpulan data yang Anda kaitkan ke titik akhir pengumpulan data di ruang kerja yang memastikan proses penyerapan berlanjut selama failover. 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 ruang kerja:

Di portal Azure, pilih Aturan pengumpulan data.
Dari layar Aturan pengumpulan data, pilih aturan pengumpulan data yang mengirim data ke ruang kerja Analitik Log utama Anda.
Pada halaman Gambaran Umum aturan pengumpulan data, pilih Konfigurasikan DCE dan pilih titik akhir pengumpulan data ruang kerja dari daftar yang tersedia:

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

Penting

Aturan pengumpulan data yang tersambung ke titik akhir pengumpulan data 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.

Apa yang harus diperiksa jika replikasi ruang kerja gagal

Apakah ruang kerja ditautkan ke kluster khusus?
- Replikasi harus diaktifkan pada kluster sebelum dapat diaktifkan di ruang kerja.
- Replikasi kluster dan ruang kerja harus disetel ke lokasi sekunder yang sama. Misalnya, jika kluster direplikasi ke Eropa Utara, ruang kerja yang terkait dengannya hanya dapat direplikasi ke Eropa Utara juga.
Apakah Anda menggunakan REST API untuk mengaktifkan replikasi?
- Verifikasi bahwa Anda menggunakan API versi 2025-02-01 atau yang lebih baru.
Apakah ruang kerja utama terletak di US Timur, US Timur 2, atau US Tengah Selatan?
- AS Timur, AS Timur 2, dan AS Tengah Selatan tidak dapat mereplikasi satu sama lain.
Di mana ruang kerja utama berada dan di mana ruang kerja sekunder berada? Kedua lokasi harus berada dalam grup wilayah yang sama. Misalnya, ruang kerja yang terletak di wilayah AS tidak dapat memiliki replikasi (wilayah sekunder) di Eropa, dan sebaliknya. Untuk daftar grup wilayah, lihat Wilayah yang didukung.
Apakah Anda memiliki izin yang diperlukan?
Apakah Anda mengizinkan cukup waktu untuk menyelesaikan operasi replikasi? Replikasi adalah operasi jangka panjang. Pantau status operasi seperti yang dijelaskan dalam Periksa status provisi ruang kerja.
Apakah Anda mencoba mengaktifkan kembali replikasi untuk mengubah lokasi sekunder ruang kerja? Untuk mengubah lokasi ruang kerja sekunder, Anda harus terlebih dahulu menonaktifkan replikasi ruang kerja, memungkinkan operasi selesai, lalu mengaktifkan replikasi ke lokasi sekunder lainnya.

Apa yang harus dilakukan untuk memeriksa jika replikasi ruang kerja diatur tetapi log tidak direplikasi?

Replikasi dapat memakan waktu hingga satu jam untuk mulai diterapkan, dan beberapa jenis data mungkin mulai mereplikasi sebelum yang lain.
Log yang diserap ke ruang kerja sebelum replikasi diaktifkan tidak disalin ke ruang kerja sekunder. Hanya log yang dimasukkan setelah replikasi diaktifkan yang direplikasi.
Jika beberapa log direplikasi dan yang lain tidak - verifikasi semua aturan pengumpulan data (DCR) yang mengalirkan log ke ruang kerja dikonfigurasi dengan benar. Untuk meninjau DCR yang menargetkan ruang kerja, lihat tab Pengumpulan Data Wawasan Ruang Kerja Analitik Log , di portal Microsoft Azure.

Menonaktifkan replikasi ruang kerja

Azure CLI
REST API

Untuk menonaktifkan replikasi ruang kerja, gunakan perintah az monitor log-analytics workspace update Azure CLI:

az monitor log-analytics workspace update \
  --resource-group <resourcegroup_name> \
  --workspace-name <workspace_name> \
  --replication-enabled false

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=2025-02-01

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

Di 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 nonaktifkan replikasi adalah operasi jangka panjang yang dapat memakan waktu untuk diselesaikan. Anda dapat melacak status provisi permintaan Anda, seperti yang dijelaskan dalam Memeriksa status provisi ruang kerja.

Penting

Jika Anda menggunakan kluster khusus, Anda harus menonaktifkan replikasi kluster setelah menonaktifkan replikasi untuk setiap ruang kerja yang ditautkan ke kluster ini.

Menonaktifkan replikasi kluster

Menonaktifkan replikasi kluster hanya dapat dilakukan setelah menonaktifkan replikasi untuk semua ruang kerja yang ditautkan ke kluster ini (jika sebelumnya diaktifkan).

Azure CLI
REST API

Untuk menonaktifkan replikasi untuk kluster, gunakan perintah az monitor log-analytics cluster update Azure CLI:

az monitor log-analytics cluster update \
  --resource-group <resourcegroup_name> \
  --cluster-name <cluster_name> \
  --replication-enabled false

Untuk menonaktifkan replikasi untuk kluster, gunakan perintah ini PUT :

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/clusters/<cluster_name>?api-version=2025-02-01

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

Di mana

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

Perintah ini adalah operasi yang berjalan lama dan dapat memerlukan waktu yang cukup untuk diselesaikan. Anda dapat melacak status provisi permintaan Anda, seperti yang dijelaskan dalam Memeriksa status provisi ruang kerja.

Catatan

Setelah replikasi dinonaktifkan dan kluster yang direplikasi dihapus menyeluruh, log yang direplikasi akan dihapus dan tidak dapat diakses lagi. Salinan aslinya di lokasi utama Anda tidak diubah dalam proses ini.

Penting

Proses penghapusan replikasi kluster membutuhkan waktu 14 hari. Jika Anda memerlukan proses ini untuk menyelesaikan lebih cepat, buat permintaan dukungan Azure.

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 pengambilan data 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
- Buat notifikasi 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 Pertimbangan penyebaran.

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 rencana Anda untuk pengalihan, seperti yang dijelaskan dalam subbagian berikut.

Jenis dan cakupan masalah

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

Ada masalah antar wilayah terkait sumber daya yang mendasarinya. 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 peralihan, log dialihkan ke alur penyerapan di wilayah sekunder.
Kueri: Jika kueri di ruang kerja utama Anda gagal atau mengalami batas waktu, peringatan 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.

Pemicu peralihan

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

Azure CLI
REST API

Untuk beralih ke ruang kerja sekunder Anda, gunakan perintah az monitor log-analytics workspace failover Azure CLI:

az monitor log-analytics workspace failover \
  --resource-group <resourcegroup_name> \
  --workspace-name <workspace_name> \
  --location <secondary_region>

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=2025-02-01

Di 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 proses pemindahan.
<workspace_name>: Nama ruang kerja yang akan dialihkan selama pengalihan.

Apa yang harus diperiksa jika pengalihan (failover) mengalami kegagalan

Apakah Anda menggunakan REST API untuk memicu pengalihan (failover)?
- Verifikasi bahwa Anda menggunakan API versi 2025-02-01 atau yang lebih baru.
- Pastikan bahwa lokasi sekunder yang disediakan dalam perintah failover adalah lokasi sekunder yang ditetapkan untuk ruang kerja ini. Informasi ini tersedia di tampilan portal Microsoft Azure ruang kerja, dan melalui API.
Beralih wilayah memerlukan peran Kontributor Analitik Log pada grup sumber daya ruang kerja, dan bukan hanya di ruang kerja itu sendiri.

Beralih kembali ke ruang kerja utama Anda

Proses switchback membatalkan pengalihan rute permintaan kueri dan pengambilan log ke ruang kerja sekunder. Saat Anda kembali beralih, Azure Monitor kembali ke perutean kueri dan pemrosesan permintaan pencatatan log 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 rencana Anda untuk perubahan strategi, seperti yang dijelaskan dalam subbagian berikut.

Keadaan 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 terduplikasi ke workspace utama, kueri Anda mungkin mengembalikan hasil parsial sampai pengambilan 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:

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

Untuk contoh cara melakukan kueri pada ruang kerja utama saat ruang kerja sekunder aktif dan melewati perutean ulang permintaan ke ruang kerja sekunder, lihat Audit ruang kerja yang tidak aktif.

Tombol balik pemicu

Sebelum Anda beralih kembali, konfirmasikan kesehatan dari ruang kerja utama dan pastikan replikasi log selesai.

Proses switchback memperbarui catatan DNS Anda. Setelah pembaruan catatan DNS, mungkin diperlukan waktu bagi semua klien untuk menerima pengaturan DNS yang telah diperbarui dan kembali melakukan perutean ke ruang kerja utama.

Azure CLI
REST API

Untuk beralih kembali ke ruang kerja utama Anda, gunakan perintah az monitor log-analytics workspace failback Azure CLI:

az monitor log-analytics workspace failback \
  --resource-group <resourcegroup_name> \
  --workspace-name <workspace_name>

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=2025-02-01

Di 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 dipilih kembali selama proses switchback.

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, terjadi perubahan – wilayah sekunder diaktifkan, dan wilayah utama menjadi tidak aktif. Kami menyebutkan bahwa ini tidak aktif karena bukan target langsung dari pengambilan 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.

Untuk berinteraksi dengan wilayah yang tidak aktif, Anda perlu menggunakan AZURE Monitor Log Analyics API. Untuk informasi selengkapnya, termasuk cara mengautentikasi, lihat Mengakses API Analitik Log Azure Monitor.

Kueri wilayah yang tidak aktif

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 singkat 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 jumlah 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 ingesti dari ujung ke ujung

Latensi ingest mengukur waktu yang diperlukan untuk memasukkan log ke dalam 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 dibutuhkan oleh alur penyerapan untuk memproses log dan menyimpannya ke dalam 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 dasar tabel tertentu

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

Kueri contoh ini membuat grafik dari latensi penyerapan pada persentil ke-90 di 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.

Permintaan ini membuat bagan latensi persentil ke-90 dari agen dan pipa 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 pemasukan total persentil ke-90.

Memantau volume penyerapan

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

Total volume penyerapan per tabel
Volume konsumsi konsisten (tidak berubah)
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 penghentian ingestasi

Jika Anda memasukkan log melalui agen, Anda dapat menggunakan heartbeat agen untuk mendeteksi konektivitas. Denyut jantung yang berhenti dapat menunjukkan penghentian pencatatan log ke dalam ruang kerja Anda. Saat data kueri mengungkapkan berhentinya proses penyerapan, Anda dapat menetapkan kondisi untuk memicu respons yang diinginkan.

Kueri berikut memeriksa denyut jantung agen guna 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 ketidaknormalan menggunakan fungsi pembagian seri "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

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-05-12

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

Cara kerja dari replikasi ruang kerja Log Analitik

Perlindungan terhadap kehilangan data dalam perjalanan ketika terjadi kegagalan regional

Pertimbangan penyebaran

Wilayah yang didukung

Persyaratan tempat penyimpanan data

Dukungan untuk Microsoft Azure Sentinel dan layanan lainnya

Rencana harga

Izin yang diperlukan

Mengaktifkan dan menonaktifkan replikasi ruang kerja

Menggunakan kluster khusus

Periksa status penyediaan kluster

Mengaktifkan replikasi ruang kerja

Periksa status provisi ruang kerja

Periksa apakah replikasi diaktifkan di ruang kerja

Mengaitkan aturan pengumpulan data dengan titik akhir pengumpulan data ruang kerja

Apa yang harus diperiksa jika replikasi ruang kerja gagal

Apa yang harus dilakukan untuk memeriksa jika replikasi ruang kerja diatur tetapi log tidak direplikasi?

Menonaktifkan replikasi ruang kerja

Menonaktifkan replikasi kluster

Memantau ruang kerja dan kesehatan layanan

Beralih ke ruang kerja sekunder Anda

Kapan saya harus beralih?

Jenis dan cakupan masalah

Durasi masalah

Data ruang kerja sekunder

Pemicu peralihan

Apa yang harus diperiksa jika pengalihan (failover) mengalami kegagalan

Beralih kembali ke ruang kerja utama Anda

Kapan saya harus beralih kembali?

Keadaan replikasi log

Kesehatan ruang kerja utama

Tombol balik pemicu

Mengaudit ruang kerja yang tidak aktif

Kueri wilayah yang tidak aktif

Memantau performa ruang kerja menggunakan kueri

Memantau latensi ingesti dari ujung ke ujung

Mengevaluasi latensi penyerapan dasar tabel tertentu

Memantau dan memperingatkan latensi penyerapan saat ini

Menentukan sumber latensi penyerapan

Memantau volume penyerapan

Memantau total volume penyerapan per tabel

Periksa penghentian ingestasi

Memantau anomali penyerapan

Mengidentifikasi ketidaknormalan menggunakan fungsi pembagian seri "series_decompose_anomalies"

Membuat detektor anomali Anda sendiri

Memantau keberhasilan dan kegagalan kueri

Konten terkait

Saran dan Komentar

Sumber Daya Tambahan: