Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Well-Architected fungsionalitas dan performa beban kerja Framework harus dipantau dengan berbagai cara dan karena berbagai alasan. Ruang kerja Analitik Log Azure Monitor adalah log utama dan sink metrik untuk sebagian besar data pemantauan. Ruang kerja mendukung beberapa fitur di Azure Monitor termasuk kueri ad-hoc, visualisasi, dan pemberitahuan. Untuk prinsip pemantauan umum, lihat Panduan pemantauan dan diagnostik. Panduan ini menyajikan prinsip pemantauan umum. Ini mengidentifikasi berbagai jenis data. Ini mengidentifikasi analisis yang diperlukan yang didukung Azure Monitor dan juga mengidentifikasi data yang disimpan di ruang kerja yang memungkinkan analisis.
Artikel ini mengasumsikan bahwa Anda memahami prinsip desain sistem. Anda juga memerlukan pengetahuan kerja tentang ruang kerja dan fitur Analitik Log di Azure Monitor yang mengisi data beban kerja operasional. Untuk informasi selengkapnya, lihat Gambaran umum ruang kerja Analitik Log.
Penting
Cara menggunakan panduan ini
Setiap bagian memiliki daftar periksa desain yang menyajikan area kekhawatiran arsitektur bersama dengan strategi desain yang dilokalkan ke cakupan teknologi.
Juga termasuk rekomendasi tentang kemampuan teknologi atau topologi penyebaran yang dapat membantu mewujudkan strategi tersebut. Rekomendasi tidak mewakili daftar lengkap semua konfigurasi yang tersedia untuk ruang kerja Log Analytics dan sumber daya Azure Monitor terkait. Sebaliknya, mereka mencantumkan rekomendasi utama yang dipetakan ke perspektif desain. Gunakan rekomendasi untuk membangun bukti konsep Anda, merancang lingkungan pemantauan beban kerja Anda, atau mengoptimalkan solusi pemantauan beban kerja yang ada.
Cakupan teknologi
Panduan ini berfokus pada keputusan yang saling terkait untuk sumber daya Azure berikut.
- Ruang kerja Analitik Log
- Data log operasional beban kerja
- Pengaturan diagnostik pada sumber daya Azure di beban kerja Anda
Keandalan
Tujuan dari pilar Keandalan adalah untuk memberikan fungsionalitas berkelanjutan dengan membangun ketahanan yang cukup dan kemampuan untuk pulih dengan cepat dari kegagalan.
Prinsip desain Keandalan menyediakan strategi desain tingkat tinggi yang diterapkan untuk komponen individu, alur sistem, dan sistem secara keseluruhan.
Situasi keandalan yang perlu dipertimbangkan untuk ruang kerja Analitik Log adalah:
- Ketersediaan ruang kerja.
- Perlindungan data yang dikumpulkan dalam kasus kegagalan pusat data atau wilayah Azure yang jarang terjadi.
Saat ini tidak ada fitur standar untuk failover antara ruang kerja di berbagai wilayah, tetapi ada strategi yang akan digunakan jika Anda memiliki persyaratan khusus untuk ketersediaan atau kepatuhan.
Daftar periksa desain untuk Keandalan
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Keandalan dan tentukan relevansinya dengan kebutuhan bisnis Anda sambil mengingat SKU dan fitur komputer virtual (VM) dan dependensinya. Perluas strategi untuk menyertakan lebih banyak pendekatan sesuai kebutuhan.
- Tinjau batas layanan untuk ruang kerja Analitik Log. Bagian batas layanan membantu Anda memahami pembatasan pengumpulan dan retensi data, dan aspek layanan lainnya. Batas ini membantu Anda menentukan cara merancang strategi pengamatan beban kerja Anda dengan benar. Pastikan untuk meninjau batas layanan Azure Monitor karena banyak fungsi yang dibahas di dalamnya, seperti kueri, bekerja sama dengan ruang kerja Analitik Log.
- Rencanakan ketahanan dan pemulihan ruang kerja. Ruang kerja Analitik Log bersifat regional, tanpa dukungan bawaan untuk redundansi atau replikasi lintas regional. Selain itu, opsi redundansi zona ketersediaan terbatas. Dengan demikian, Anda harus menentukan persyaratan keandalan ruang kerja Anda dan menyusun strategi untuk memenuhi target tersebut. Persyaratan Anda mungkin menetapkan bahwa ruang kerja Anda harus tahan terhadap kegagalan pusat data atau kegagalan regional, atau mereka mungkin menetapkan bahwa Anda harus dapat memulihkan data Anda ke ruang kerja baru di wilayah failover. Masing-masing skenario ini memerlukan sumber daya dan proses tambahan agar berhasil, sehingga menyeimbangkan target keandalan Anda dengan biaya dan kompleksitas harus dipertimbangkan dengan hati-hati.
- Pilih wilayah penyebaran yang tepat untuk memenuhi persyaratan keandalan Anda. Sebarkan ruang kerja Analitik Log dan titik akhir pengumpulan data (DCEs) yang terletak bersama dengan komponen beban kerja yang memancarkan data operasional. Pilihan wilayah yang sesuai untuk menyebarkan ruang kerja dan DCEs Anda harus diberi tahu di mana Anda menyebarkan beban kerja Anda. Anda mungkin perlu menimbang ketersediaan regional fungsionalitas Log Analytics tertentu, seperti kluster khusus, terhadap faktor lain yang lebih terpusat pada keandalan, biaya, dan persyaratan performa beban kerja Anda.
- Pastikan sistem pengamatan Anda sehat. Seperti komponen lain dari beban kerja Anda, pastikan sistem pemantauan dan pengelogan Anda berfungsi dengan baik. Untuk mencapai hal ini, aktifkan fitur yang mengirim sinyal data kesehatan ke tim operasi Anda. Siapkan sinyal data kesehatan khusus untuk ruang kerja Analitik Log dan sumber daya terkait Anda.
Rekomendasi konfigurasi untuk Keandalan
Rekomendasi | Manfaat |
---|---|
Jangan sertakan ruang kerja Analitik Log di jalur penting beban kerja Anda. Ruang kerja Anda penting untuk sistem pengamatan yang berfungsi, tetapi fungsionalitas beban kerja Anda tidak boleh bergantung padanya. | Menjaga ruang kerja dan fungsi terkait Anda dari jalur penting beban kerja Meminimalkan risiko masalah yang memengaruhi sistem pengamatan Anda agar tidak memengaruhi eksekusi runtime beban kerja Anda. |
Untuk mendukung durabilitas data ruang kerja yang tinggi, sebarkan ruang kerja Analitik Log ke wilayah yang mendukung ketahanan data. Ketahanan data hanya dimungkinkan melalui penautan ruang kerja ke kluster khusus di wilayah yang sama. | Saat Anda menggunakan kluster khusus, kluster ini memungkinkan Anda menyebarkan ruang kerja terkait di seluruh zona ketersediaan, yang menawarkan perlindungan terhadap pemadaman pusat data. Jika Anda tidak mengumpulkan cukup data sekarang untuk membenarkan kluster khusus, pilihan regional preemptive ini mendukung pertumbuhan di masa depan. |
Pilih penyebaran ruang kerja Anda berdasarkan kedekatan dengan beban kerja Anda. Gunakan titik akhir pengumpulan data (DCE) di wilayah yang sama dengan ruang kerja Analitik Log. |
Sebarkan ruang kerja Anda di wilayah yang sama dengan instans beban kerja Anda. Memiliki ruang kerja dan DCEs Anda di wilayah yang sama dengan beban kerja Anda mengurangi risiko dampak oleh pemadaman di wilayah lain. DCEs digunakan oleh agen Azure Monitor dan API Penyerapan Log untuk mengirim data operasional beban kerja ke ruang kerja Analitik Log. Anda mungkin memerlukan beberapa DCEs meskipun penyebaran Anda hanya memiliki satu ruang kerja. Untuk informasi selengkapnya tentang cara mengonfigurasi DCEs untuk lingkungan tertentu Anda, lihat Cara menyiapkan titik akhir pengumpulan data berdasarkan penyebaran Anda.<Br Jika beban kerja Anda disebarkan dalam desain aktif-aktif, pertimbangkan untuk menggunakan beberapa ruang kerja dan DCEs yang tersebar di wilayah tempat beban kerja Anda disebarkan. Menyebarkan ruang kerja di beberapa wilayah akan menambah kompleksitas pada lingkungan Anda. Seimbangkan kriteria yang dirinci dalam Merancang arsitektur ruang kerja Analitik Log dengan persyaratan ketersediaan Anda. |
Jika Anda mengharuskan ruang kerja tersedia dalam kegagalan wilayah, atau Anda tidak mengumpulkan cukup data untuk kluster khusus, konfigurasikan pengumpulan data untuk mengirim data penting ke beberapa ruang kerja di berbagai wilayah. Praktik ini juga dikenal sebagai multicasting log. Misalnya, konfigurasikan DCR untuk beberapa ruang kerja untuk agen Azure Monitor yang berjalan di VM. Konfigurasikan beberapa pengaturan diagnostik untuk mengumpulkan log sumber daya dari sumber daya Azure dan mengirim log ke beberapa ruang kerja. |
|
Dengan cara ini, data operasional beban kerja tersedia di ruang kerja alternatif jika ada kegagalan regional. Tetapi ketahuilah bahwa sumber daya yang mengandalkan data seperti pemberitahuan dan buku kerja tidak akan secara otomatis direplikasi ke wilayah lain. Pertimbangkan untuk menyimpan templat Azure Resource Manager (ARM) untuk sumber daya pemberitahuan penting dengan konfigurasi untuk ruang kerja alternatif atau menyebarkannya di semua wilayah tetapi menonaktifkannya untuk mencegah pemberitahuan yang berlebihan. Kedua opsi mendukung pengaktifan cepat dalam kegagalan regional. Tradeoff: Konfigurasi ini menghasilkan biaya penyerapan dan retensi duplikat sehingga hanya gunakan untuk data penting. |
|
Jika Anda mengharuskan data dilindungi di pusat data atau kegagalan wilayah, konfigurasikan ekspor data dari ruang kerja untuk menyimpan data di lokasi alternatif. Opsi ini mirip dengan opsi sebelumnya untuk melakukan multicasting data ke ruang kerja yang berbeda. Tetapi opsi ini lebih murah karena data tambahan ditulis ke penyimpanan. Gunakan opsi redundansi Azure Storage, termasuk penyimpanan geo-redundan (GRS) dan penyimpanan redundansi zona geografis (GZRS), untuk mereplikasi data ini lebih lanjut ke wilayah lain. Ekspor data tidak memberikan ketahanan terhadap insiden yang berdampak pada alur penyerapan regional. |
Meskipun data log operasional historis mungkin tidak dapat dikueri dengan mudah dalam status yang diekspor, data tersebut memastikan data bertahan dari pemadaman regional yang berkepanjangan dan dapat diakses dan dipertahankan untuk jangka waktu yang lama. Jika Anda memerlukan ekspor tabel yang tidak didukung oleh ekspor data, Anda dapat menggunakan metode lain untuk mengekspor data, termasuk Logic Apps, untuk melindungi data Anda. Agar strategi ini berfungsi sebagai rencana pemulihan yang layak, Anda harus memiliki proses untuk mengonfigurasi ulang pengaturan diagnostik untuk sumber daya Anda di Azure dan di semua agen yang menyediakan data. Anda juga harus berencana untuk merehidrasi data yang diekspor secara manual ke ruang kerja baru. Seperti opsi yang dijelaskan sebelumnya, Anda juga perlu menentukan proses untuk sumber daya yang mengandalkan data seperti pemberitahuan dan buku kerja. |
Untuk beban kerja misi penting yang membutuhkan ketersediaan tinggi, pertimbangkan untuk menerapkan model ruang kerja federasi yang menggunakan beberapa ruang kerja untuk memberikan ketersediaan tinggi jika ada kegagalan regional. |
Misi penting memberikan panduan praktik terbaik preskriptif untuk merancang aplikasi yang sangat andal di Azure. Metodologi desain mencakup model ruang kerja federasi dengan beberapa ruang kerja Analitik Log untuk memberikan ketersediaan tinggi jika ada beberapa kegagalan, termasuk kegagalan wilayah Azure. Strategi ini menghilangkan biaya keluar di seluruh wilayah dan tetap beroperasi dengan kegagalan wilayah. Tetapi membutuhkan lebih banyak kompleksitas yang harus Anda kelola dengan konfigurasi dan proses yang dijelaskan dalam Pemodelan kesehatan dan pengamatan beban kerja misi penting di Azure. |
Gunakan infrastruktur sebagai kode (IaC) untuk menyebarkan dan mengelola ruang kerja dan fungsi terkait Anda. | Ketika Anda mengotomatiskan sebanyak penyebaran dan mekanisme Anda untuk ketahanan dan pemulihan sebagai praktis, itu memastikan bahwa operasi ini dapat diandalkan. Anda menghemat waktu kritis dalam proses operasi Anda dan meminimalkan risiko kesalahan manusia. Pastikan bahwa fungsi seperti kueri log yang disimpan juga ditentukan melalui IaC Anda untuk memulihkannya ke wilayah baru jika pemulihan diperlukan. |
Rancang DCR dengan prinsip tanggung jawab tunggal untuk menjaga aturan DCR tetap sederhana. Meskipun satu DCR dapat dimuat dengan semua input, aturan, dan tujuan untuk sistem sumber, lebih baik merancang aturan yang berfokus secara sempit yang mengandalkan lebih sedikit sumber data. Gunakan komposisi penetapan aturan untuk sampai pada cakupan pengamatan yang diinginkan untuk target logis. Selain itu, minimalkan transformasi dalam DCR |
Saat Anda menggunakan DCR yang berfokus pada sempit, itu meminimalkan risiko kesalahan konfigurasi aturan yang memiliki efek yang lebih luas. Ini membatasi efek hanya pada cakupan yang dibangun DCR. Untuk informasi selengkapnya, lihat Praktik terbaik untuk pembuatan dan manajemen aturan pengumpulan data di Azure Monitor. Meskipun transformasi bisa kuat dan diperlukan dalam beberapa situasi, mungkin sulit untuk menguji dan memecahkan masalah pekerjaan bahasa kueri kata kunci (KQL) yang sedang dilakukan. Jika memungkinkan, minimalkan risiko kehilangan data dengan menyerap data mentah dan menangani transformasi hilir pada waktu kueri. |
Saat mengatur batas harian atau kebijakan penyimpanan, pastikan Anda mempertahankan persyaratan keandalan dengan menyerap dan mempertahankan log yang Anda butuhkan. | Batas harian menghentikan pengumpulan data untuk ruang kerja setelah jumlah tertentu tercapai, yang membantu Anda mempertahankan kontrol atas volume penyerapan Anda. Tetapi hanya gunakan fitur ini setelah perencanaan yang cermat. Pastikan batas harian Anda tidak terpukul dengan keteraturan. Jika itu terjadi, batas Anda diatur terlalu ketat. Anda perlu mengonfigurasi ulang batas harian sehingga Anda tidak melewatkan sinyal penting yang berasal dari beban kerja Anda. Demikian juga, pastikan untuk dengan hati-hati dan bijaksana mendekati penurunan kebijakan retensi data Anda untuk memastikan bahwa Anda tidak secara tidak sengaja kehilangan data penting. |
Gunakan wawasan ruang kerja Log Analytics untuk melacak volume penyerapan, menyerap data versus batas data Anda, sumber log yang tidak responsif, dan kueri yang gagal di antara data lainnya. Buat pemberitahuan status kesehatan untuk memberi tahu Anda secara proaktif jika ruang kerja menjadi tidak tersedia karena pusat data atau kegagalan regional. | Strategi ini memastikan bahwa Anda dapat berhasil memantau kesehatan ruang kerja Anda dan secara proaktif bertindak jika kesehatan berisiko terdegradasi. Seperti komponen lain dari beban kerja Anda, sangat penting bagi Anda untuk mengetahui metrik kesehatan dan dapat mengidentifikasi tren untuk meningkatkan keandalan Anda dari waktu ke waktu. |
Kebijakan Azure
Azure tidak menawarkan kebijakan yang terkait dengan keandalan ruang kerja Analitik Log. Anda dapat membuat kebijakan kustom untuk membangun pagar pembatas kepatuhan di sekitar penyebaran ruang kerja Anda, seperti memastikan ruang kerja dikaitkan dengan kluster khusus.
Meskipun tidak terkait langsung dengan keandalan ruang kerja Analitik Log, ada kebijakan Azure untuk hampir setiap layanan yang tersedia. Kebijakan memastikan bahwa pengaturan diagnostik diaktifkan untuk layanan tersebut dan memvalidasi bahwa data log layanan mengalir ke ruang kerja Analitik Log. Semua layanan dalam arsitektur beban kerja harus mengirim data log mereka ke ruang kerja Analitik Log untuk kebutuhan keandalan mereka sendiri, dan kebijakan dapat membantu menegakkannya. Demikian juga, kebijakan ada untuk memastikan platform berbasis agen, seperti VM dan Kubernetes, telah menginstal agen.
Azure Advisor
Azure tidak menawarkan rekomendasi Azure Advisor yang terkait dengan keandalan ruang kerja Log Analytics.
Keamanan
Tujuan pilar Keamanan adalah untuk memberikan jaminan kerahasiaan, integritas, dan ketersediaan terhadap beban kerja.
Prinsip desain Keamanan menyediakan strategi desain tingkat tinggi untuk mencapai tujuan ini dengan menerapkan pendekatan pada desain teknis di sekitar solusi pemantauan dan pengelogan Anda.
Daftar periksa desain untuk Keamanan
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Keamanan dan identifikasi kerentanan dan kontrol untuk meningkatkan postur keamanan. Perluas strategi untuk menyertakan lebih banyak pendekatan sesuai kebutuhan.
- Tinjau garis besar keamanan Azure Monitor dan Kelola akses ke topik ruang kerja Analitik Log. Topik-topik ini memberikan panduan tentang praktik terbaik keamanan.
- Sebarkan ruang kerja Anda dengan segmentasi sebagai prinsip landasan. Terapkan segmentasi di tingkat jaringan, data, dan akses. Segmentasi membantu memastikan bahwa ruang kerja Anda terisolasi ke tingkat yang sesuai dan lebih terlindungi dari akses tidak sah ke tingkat setinggi mungkin, sambil tetap memenuhi persyaratan bisnis Anda untuk keandalan, pengoptimalan biaya, keunggulan operasional, dan efisiensi performa.
- Pastikan Anda dapat mengaudit ruang kerja membaca dan menulis aktivitas dan identitas terkait. Penyerang dapat memperoleh manfaat dari melihat log operasional. Identitas yang disusupi dapat menyebabkan serangan injeksi log. Aktifkan audit operasi yang dijalankan dari Portal Microsoft Azure atau melalui interaksi API dan pengguna terkait. Jika Anda tidak disiapkan untuk mengaudit ruang kerja, Anda mungkin membahayakan organisasi Anda karena melanggar persyaratan kepatuhan.
- Menerapkan kontrol jaringan yang kuat. Membantu mengamankan akses jaringan Anda ke ruang kerja dan log Anda melalui isolasi jaringan dan fungsi firewall. Kontrol jaringan yang dikonfigurasi tidak cukup mungkin membuat Anda berisiko diakses oleh aktor yang tidak sah atau jahat.
- Tentukan jenis data apa yang membutuhkan imutabilitas atau retensi jangka panjang. Data log Anda harus diperlakukan dengan ketebalan yang sama dengan data beban kerja di dalam sistem produksi. Sertakan data log dalam praktik klasifikasi data Anda untuk memastikan bahwa Anda berhasil menyimpan data log sensitif sesuai dengan persyaratan kepatuhannya.
- Lindungi data log tidak aktif melalui enkripsi. Segmentasi saja tidak akan sepenuhnya melindungi kerahasiaan data log Anda. Jika akses mentah yang tidak sah terjadi, memiliki data log yang dienkripsi saat tidak aktif membantu mencegah pelaku jahat menggunakan data tersebut di luar ruang kerja Anda.
- Lindungi data log sensitif melalui obfuscation. Sama seperti data beban kerja yang berada di sistem produksi, Anda harus mengambil langkah-langkah ekstra untuk memastikan kerahasiaan disimpan untuk informasi sensitif yang mungkin sengaja atau tidak sengaja ada dalam log operasional. Ketika Anda menggunakan metode obfuscation, ini membantu Anda menyembunyikan data log sensitif dari mata yang tidak sah.
Rekomendasi konfigurasi untuk Keamanan
Rekomendasi | Manfaat |
---|---|
Gunakan kunci yang dikelola pelanggan jika Anda memerlukan kunci enkripsi Anda sendiri untuk melindungi data dan kueri yang disimpan di ruang kerja Anda. Azure Monitor memastikan bahwa semua data dan kueri yang disimpan dienkripsi saat tidak digunakan menggunakan kunci yang dikelola Microsoft (MMK). Jika Anda memerlukan kunci enkripsi Anda sendiri dan mengumpulkan data yang cukup untuk kluster khusus, gunakan kunci yang dikelola pelanggan. Anda dapat mengenkripsi data dengan menggunakan kunci Anda sendiri di Azure Key Vault, untuk kontrol atas siklus hidup kunci, dan kemampuan untuk mencabut akses ke data Anda. Jika Anda menggunakan Microsoft Sentinel, pastikan Anda terbiasa dengan pertimbangan di Menyiapkan kunci yang dikelola pelanggan Microsoft Sentinel. |
Strategi ini memungkinkan Anda mengenkripsi data dengan menggunakan kunci Anda sendiri di Azure Key Vault, untuk kontrol atas siklus hidup kunci, dan kemampuan untuk mencabut akses ke data Anda. |
Konfigurasikan audit kueri Log untuk melacak pengguna mana yang menjalankan kueri. Konfigurasikan log audit untuk setiap ruang kerja yang akan dikirim ke ruang kerja lokal atau konsolidasikan di ruang kerja keamanan khusus jika Anda memisahkan data operasional dan keamanan Anda. Gunakan wawasan ruang kerja Analitik Log untuk meninjau data ini secara berkala. Pertimbangkan untuk membuat aturan pemberitahuan kueri log untuk secara proaktif memberi tahu Anda jika pengguna yang tidak sah mencoba menjalankan kueri. |
Audit kueri log merekam detail untuk setiap kueri yang dijalankan di ruang kerja. Perlakukan data audit ini sebagai data keamanan dan amankan tabel LAQueryLogs dengan tepat. Strategi ini memperkuat postur keamanan Anda dengan membantu memastikan bahwa akses yang tidak sah segera tertangkap jika pernah terjadi. |
Membantu mengamankan ruang kerja Anda melalui jaringan privat dan langkah-langkah segmentasi. Gunakan fungsionalitas tautan privat untuk membatasi komunikasi antara sumber log dan ruang kerja Anda ke jaringan privat. |
Saat Anda menggunakan tautan privat, ini juga memungkinkan Anda mengontrol jaringan virtual mana yang dapat mengakses ruang kerja tertentu, lebih lanjut meningkatkan keamanan Anda melalui segmentasi. |
Gunakan Microsoft Entra ID alih-alih kunci API untuk akses API ruang kerja jika tersedia. | Akses berbasis kunci API ke API kueri tidak meninggalkan jejak audit per klien. Gunakan akses berbasis ID Entra yang cukup terlingkup sehingga Anda dapat mengaudit akses terprogram dengan benar. |
Konfigurasikan akses untuk berbagai jenis data di ruang kerja yang diperlukan untuk peran yang berbeda di organisasi Anda. Atur mode kontrol akses untuk ruang kerja untuk Menggunakan izin sumber daya atau ruang kerja. Kontrol akses ini memungkinkan pemilik sumber daya menggunakan konteks sumber daya untuk mengakses data mereka tanpa diberikan akses eksplisit ke ruang kerja. Gunakan RBAC tingkat tabel untuk pengguna yang memerlukan akses ke sekumpulan tabel di beberapa sumber daya. |
Pengaturan ini menyederhanakan konfigurasi ruang kerja Anda dan membantu memastikan pengguna tidak dapat mengakses data operasional yang seharusnya tidak mereka lakukan. Tetapkan peran bawaan yang sesuai untuk memberikan izin ruang kerja kepada administrator di tingkat langganan, grup sumber daya, atau ruang kerja tergantung pada cakupan tanggung jawab mereka. Pengguna dengan izin tabel memiliki akses ke semua data dalam tabel terlepas dari izin sumber daya mereka. Lihat Mengelola akses ke ruang kerja Analitik Log untuk detail tentang berbagai opsi untuk memberikan akses ke data di ruang kerja. |
Ekspor log yang memerlukan retensi atau imutabilitas jangka panjang. Gunakan ekspor data untuk mengirim data ke akun Azure Storage dengan kebijakan imutabilitas untuk membantu melindungi dari perubahan data. Tidak setiap jenis log memiliki relevansi yang sama untuk kepatuhan, audit, atau keamanan, jadi tentukan jenis data tertentu yang harus diekspor. |
Anda dapat mengumpulkan data audit di ruang kerja yang tunduk pada peraturan yang memerlukan retensi jangka panjangnya. Data di ruang kerja Analitik Log tidak dapat diubah, tetapi dapat dibersihkan. Mengekspor salinan data operasional untuk tujuan retensi memungkinkan Anda membangun solusi yang memenuhi persyaratan kepatuhan Anda. |
Tentukan strategi untuk memfilter atau mengaburkan data sensitif di ruang kerja Anda. Anda mungkin mengumpulkan data yang menyertakan informasi sensitif. Filter rekaman yang tidak boleh dikumpulkan dengan menggunakan konfigurasi untuk sumber data tertentu. Gunakan transformasi jika hanya kolom tertentu dalam data yang harus dihapus atau dikaburkan. Jika Anda memiliki standar yang mengharuskan data asli tidak dimodifikasi, Anda bisa menggunakan harfiah 'h' dalam kueri KQL untuk mengaburkan hasil kueri yang ditampilkan dalam buku kerja. |
Mengaburkan atau memfilter data sensitif di ruang kerja Anda membantu memastikan Anda menjaga kerahasiaan pada informasi sensitif. Dalam banyak kasus, persyaratan kepatuhan menentukan cara Anda dapat menangani informasi sensitif. Strategi ini membantu Anda mematuhi persyaratan secara proaktif. |
Kebijakan Azure
Azure menawarkan kebijakan yang terkait dengan keamanan ruang kerja Analitik Log untuk membantu menegakkan postur keamanan yang Anda inginkan. Contoh kebijakan tersebut adalah:
- Kluster Log Azure Monitor harus dienkripsi dengan kunci yang dikelola pelanggan
- Kueri tersimpan di Azure Monitor harus disimpan di akun penyimpanan pelanggan untuk enkripsi log
- Ruang Kerja Analitik Log harus memblokir penyerapan berbasis Active Directory non-Azure
Azure juga menawarkan banyak kebijakan untuk membantu menerapkan konfigurasi tautan privat, seperti ruang kerja Log Analytics harus memblokir penyerapan log dan kueri dari jaringan publik atau bahkan mengonfigurasi solusi melalui kebijakan DINE seperti Mengonfigurasi Azure Monitor Private Link Cakupan untuk menggunakan zona DNS privat.
Azure Advisor
Azure tidak menawarkan rekomendasi Azure Advisor yang terkait dengan keamanan ruang kerja Analitik Log.
Pengoptimalan Biaya
Pengoptimalan Biaya berfokus pada mendeteksi pola pengeluaran, memprioritaskan investasi di area penting, dan mengoptimalkan orang lain untuk memenuhi anggaran organisasi sambil memenuhi persyaratan bisnis.
Prinsip desain Pengoptimalan Biaya memberikan strategi desain tingkat tinggi untuk mencapai tujuan bisnis tersebut. Mereka juga membantu Anda melakukan tradeoff seperlunya dalam desain teknis yang terkait dengan solusi pemantauan dan pengelogan Anda.
Untuk informasi selengkapnya tentang cara biaya data dihitung untuk ruang kerja Analitik Log Anda, lihat Perhitungan dan opsi biaya Log Azure Monitor.
Daftar periksa desain untuk Pengoptimalan Biaya
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Pengoptimalan Biaya untuk investasi dan sesuaikan desain sehingga beban kerja selaras dengan anggaran yang dialokasikan untuk beban kerja. Desain Anda harus menggunakan kemampuan Azure yang tepat, memantau investasi, dan menemukan peluang untuk dioptimalkan dari waktu ke waktu.
- Lakukan latihan pemodelan biaya. Ini membantu Anda memahami biaya ruang kerja Anda saat ini dan memperkirakan biaya Anda relatif terhadap pertumbuhan ruang kerja. Analisis tren pertumbuhan Anda dalam beban kerja Anda dan pastikan Anda memahami rencana ekspansi beban kerja untuk memperkirakan biaya pengelogan operasional Anda di masa mendatang dengan benar.
- Pilih model penagihan yang tepat. Gunakan model biaya Anda untuk menentukan model penagihan terbaik untuk skenario Anda. Cara Anda menggunakan ruang kerja saat ini, dan bagaimana Anda berencana untuk menggunakannya saat beban kerja Anda berkembang menentukan apakah model tingkat bayar sesuai penggunaan atau komitmen paling cocok untuk skenario Anda.
Ingatlah bahwa Anda dapat memilih model penagihan yang berbeda untuk setiap ruang kerja, dan Anda dapat menggabungkan biaya ruang kerja dalam kasus tertentu, sehingga Anda dapat terperinci dalam analisis dan pengambilan keputusan Anda. - Kumpulkan hanya jumlah data log yang tepat. Lakukan analisis terjadwal secara teratur tentang pengaturan diagnostik Anda pada sumber daya, konfigurasi aturan pengumpulan data, dan pengelogan kode aplikasi kustom untuk memastikan bahwa Anda tidak mengumpulkan data log yang tidak perlu.
- Perlakukan lingkungan nonproduksi secara berbeda dari produksi. Tinjau lingkungan nonproduksi Anda untuk memastikan bahwa Anda telah mengonfigurasi pengaturan diagnostik dan kebijakan retensi dengan tepat. Ini seringkali dapat secara signifikan kurang kuat daripada produksi, terutama untuk lingkungan dev/test atau sandbox.
Rekomendasi konfigurasi untuk Pengoptimalan Biaya
Rekomendasi | Manfaat |
---|---|
Konfigurasikan tingkat harga untuk jumlah data yang biasanya dikumpulkan setiap ruang kerja Analitik Log. | Secara default, ruang kerja Analitik Log menggunakan harga bayar sesuai penggunaan tanpa volume data minimum. Jika Anda mengumpulkan data yang cukup, Anda dapat secara signifikan mengurangi biaya dengan menggunakan tingkat komitmen, yang memungkinkan Anda berkomitmen pada minimum data harian yang dikumpulkan dengan imbalan tarif yang lebih rendah. Jika Anda mengumpulkan cukup data di seluruh ruang kerja dalam satu wilayah, Anda dapat menautkannya ke kluster khusus dan menggabungkan volume yang dikumpulkan dengan menggunakan harga kluster. Untuk informasi selengkapnya tentang tingkat komitmen dan panduan tentang menentukan apa yang paling sesuai untuk tingkat penggunaan Anda, lihat Perhitungan dan opsi biaya Log Azure Monitor. Untuk melihat perkiraan biaya untuk penggunaan Anda pada tingkat harga yang berbeda, lihat Penggunaan dan perkiraan biaya. |
Mengonfigurasi retensi dan pengarsipan data. | Ada biaya untuk menyimpan data di ruang kerja Analitik Log di luar default 31 hari. Ini adalah 90 hari jika Microsoft Azure Sentinel diaktifkan di ruang kerja dan 90 hari untuk data Application Insights. Pertimbangkan persyaratan khusus Anda untuk memiliki data yang tersedia untuk kueri log. Anda dapat secara signifikan mengurangi biaya Anda dengan mengonfigurasi log yang diarsipkan. Log yang diarsipkan memungkinkan Anda menyimpan data hingga tujuh tahun dan kadang-kadang masih mengaksesnya. Anda mengakses data dengan menggunakan pekerjaan pencarian atau memulihkan sekumpulan data ke ruang kerja. |
Jika Anda menggunakan Microsoft Azure Sentinel untuk menganalisis log keamanan, pertimbangkan untuk menggunakan ruang kerja terpisah untuk menyimpan log tersebut. | Saat Anda menggunakan ruang kerja khusus untuk data log yang digunakan SIEM Anda, itu dapat membantu Anda mengontrol biaya. Ruang kerja yang digunakan Microsoft Azure Sentinel tunduk pada harga Microsoft Azure Sentinel. Persyaratan keamanan Anda menentukan jenis log yang diperlukan untuk disertakan dalam solusi SIEM Anda. Anda mungkin dapat mengecualikan log operasional, yang akan dikenakan pada harga Analitik Log standar jika berada di ruang kerja terpisah. |
Konfigurasikan tabel yang digunakan untuk penelusuran kesalahan, pemecahan masalah, dan audit sebagai Log Dasar. | Tabel di ruang kerja Analitik Log yang dikonfigurasi untuk Log Dasar memiliki biaya penyerapan yang lebih rendah dengan imbalan fitur terbatas dan biaya untuk kueri log. Jika Anda jarang mengkueri tabel ini dan tidak menggunakannya untuk pemberitahuan, biaya kueri ini bisa lebih dari diimbangi dengan pengurangan biaya penyerapan. |
Batasi pengumpulan data dari sumber data untuk ruang kerja. | Faktor utama untuk biaya Azure Monitor adalah jumlah data yang Anda kumpulkan di ruang kerja Analitik Log Anda. Pastikan Anda mengumpulkan tidak lebih banyak data daripada yang Anda butuhkan untuk menilai kesehatan dan performa layanan dan aplikasi Anda. Untuk setiap sumber daya, pilih kategori yang tepat untuk pengaturan diagnostik yang Anda konfigurasi untuk memberikan jumlah data operasional yang Anda butuhkan. Ini membantu Anda berhasil mengelola beban kerja Anda, dan tidak mengelola data yang diabaikan. Mungkin ada tradeoff antara biaya dan persyaratan pemantauan Anda. Misalnya, Anda mungkin dapat mendeteksi masalah performa dengan lebih cepat dengan laju sampel yang tinggi, tetapi Anda mungkin ingin laju sampel yang lebih rendah untuk menghemat biaya. Sebagian besar lingkungan memiliki beberapa sumber data dengan berbagai jenis pengumpulan, jadi Anda perlu menyeimbangkan persyaratan khusus Anda dengan target biaya Anda untuk masing-masing. Lihat Pengoptimalan biaya di Azure Monitor untuk rekomendasi tentang mengonfigurasi pengumpulan untuk sumber data yang berbeda. |
Analisis data penggunaan ruang kerja secara teratur untuk mengidentifikasi tren dan anomali. Gunakan wawasan ruang kerja Analitik Log untuk meninjau jumlah data yang dikumpulkan di ruang kerja Anda secara berkala. Analisis pengumpulan data lebih lanjut dengan menggunakan metode dalam Menganalisis penggunaan di ruang kerja Analitik Log untuk menentukan apakah ada konfigurasi lain yang dapat mengurangi penggunaan Anda lebih lanjut. |
Dengan membantu Anda memahami jumlah data yang dikumpulkan oleh sumber yang berbeda, ia mengidentifikasi anomali dan tren ke atas dalam pengumpulan data yang dapat mengakibatkan biaya berlebih. Pertimbangan ini penting saat Anda menambahkan sekumpulan sumber data baru ke beban kerja Anda. Misalnya, jika Anda menambahkan sekumpulan VM baru, aktifkan pengaturan diagnostik Azure baru pada layanan, atau ubah tingkat log di aplikasi Anda. |
Buat pemberitahuan saat pengumpulan data tinggi. | Untuk menghindari tagihan tak terduga, Anda harus secara proaktif diberi tahu kapan saja Anda mengalami penggunaan yang berlebihan. Pemberitahuan memungkinkan Anda mengatasi potensi anomali sebelum akhir periode penagihan Anda. |
Pertimbangkan batas harian sebagai tindakan pencegahan untuk memastikan bahwa Anda tidak melebihi anggaran tertentu. |
Batas harian menonaktifkan pengumpulan data di ruang kerja Analitik Log selama sisa hari setelah batas yang dikonfigurasi tercapai. Jangan gunakan praktik ini sebagai metode untuk mengurangi biaya seperti yang dijelaskan dalam Kapan menggunakan batas harian, tetapi sebagai gantinya untuk mencegah penyerapan yang melarikan diri karena kesalahan konfigurasi atau penyalahgunaan. Jika Anda mengatur batas harian, buat pemberitahuan saat batas tercapai. Pastikan juga untuk membuat aturan pemberitahuan saat beberapa persentase tercapai. Misalnya, Anda dapat mengatur aturan pemberitahuan saat kapasitas 90 persen tercapai. Pemberitahuan ini memberi Anda kesempatan untuk menyelidiki dan mengatasi penyebab peningkatan data sebelum batas mematikan pengumpulan data penting dari beban kerja Anda. |
Kebijakan Azure
Azure tidak menawarkan kebijakan yang terkait dengan pengoptimalan biaya ruang kerja Analitik Log. Anda dapat membuat kebijakan kustom untuk membangun pagar pembatas kepatuhan di sekitar penyebaran ruang kerja Anda, seperti memastikan bahwa ruang kerja Anda berisi pengaturan retensi yang tepat.
Azure Advisor
Azure Advisor membuat rekomendasi untuk memindahkan tabel tertentu di ruang kerja ke paket data Log Dasar berbiaya rendah untuk tabel yang menerima volume penyerapan yang relatif tinggi. Pahami batasan dengan menggunakan log dasar sebelum beralih. Untuk informasi selengkapnya, lihat Kapan saya harus menggunakan Log Dasar?. Azure Advisor mungkin juga merekomendasikan perubahan tingkat komitmen harga untuk seluruh ruang kerja berdasarkan volume penggunaan keseluruhan.
Keunggulan Operasional
Keunggulan Operasional terutama berfokus pada prosedur untuk praktik pengembangan, pengamatan, dan manajemen rilis.
Prinsip desain Keunggulan Operasional menyediakan strategi desain tingkat tinggi untuk mencapai tujuan tersebut terhadap persyaratan operasional beban kerja.
Daftar periksa desain untuk Keunggulan Operasional
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Keunggulan Operasional untuk menentukan proses pengamatan, pengujian, dan penyebaran yang terkait dengan ruang kerja Analitik Log.
- Gunakan infrastruktur sebagai kode (IaC) untuk semua fungsi yang terkait dengan ruang kerja Log Analytics beban kerja Anda. Minimalkan risiko kesalahan manusia yang dapat terjadi dengan mengelola dan mengoperasikan fungsi pengumpulan, penyerapan, penyimpanan, dan kueri log Anda secara manual, termasuk kueri dan paket kueri yang disimpan, dengan mengotomatiskan sebanyak mungkin fungsi tersebut melalui kode. Selain itu, sertakan pemberitahuan yang melaporkan perubahan status kesehatan dan konfigurasi pengaturan diagnostik untuk sumber daya yang mengirim log ke ruang kerja Anda dalam kode IaC Anda. Sertakan kode dengan kode terkait beban kerja Anda lainnya untuk memastikan bahwa praktik penyebaran Anda yang aman dipertahankan untuk pengelolaan ruang kerja Anda.
- Pastikan ruang kerja Anda sehat, dan Anda akan diberi tahu saat masalah muncul. Seperti komponen lain dari beban kerja Anda, ruang kerja Anda dapat mengalami masalah. Masalah ini dapat menghabiskan waktu dan sumber daya yang berharga untuk memecahkan masalah dan menyelesaikan, dan berpotensi membuat tim Anda tidak menyadari status beban kerja produksi. Mampu memantau ruang kerja secara proaktif dan mengurangi potensi masalah membantu tim operasi Anda meminimalkan waktu yang mereka habiskan untuk memecahkan masalah dan memperbaiki masalah.
- Pisahkan produksi Anda dari beban kerja nonproduksi. Hindari kompleksitas yang tidak perlu yang dapat menyebabkan pekerjaan ekstra untuk tim operasi dengan menggunakan ruang kerja yang berbeda untuk lingkungan produksi Anda daripada yang digunakan oleh lingkungan nonproduksi. Data yang datang juga dapat menyebabkan kebingungan karena aktivitas pengujian mungkin tampak sebagai peristiwa dalam produksi.
- Lebih suka alat dan fungsi bawaan daripada solusi non-Microsoft Gunakan alat bawaan untuk memperluas fungsionalitas sistem pemantauan dan pengelogan Anda. Anda mungkin perlu menempatkan konfigurasi tambahan untuk mendukung persyaratan seperti pemulihan atau kedaulatan data yang tidak tersedia di luar kotak dengan ruang kerja Log Analytics. Dalam kasus ini, setiap kali praktis, gunakan alat Azure atau Microsoft asli untuk menjaga jumlah alat yang harus didukung organisasi Anda minimal.
- Perlakukan ruang kerja Anda sebagai komponen statis daripada komponen sementara Seperti jenis penyimpanan data lainnya, ruang kerja tidak boleh dipertimbangkan di antara komponen sementara beban kerja Anda. Well-Architected Framework umumnya mendukung infrastruktur yang tidak dapat diubah dan kemampuan untuk mengganti sumber daya dengan cepat dan mudah dalam beban kerja Anda sebagai bagian dari penyebaran Anda. Tetapi hilangnya data ruang kerja bisa menjadi bencana dan tidak dapat diubah. Untuk alasan ini, tinggalkan ruang kerja dari paket penyebaran yang menggantikan infrastruktur selama pembaruan, dan hanya melakukan peningkatan di tempat di ruang kerja.
- Pastikan bahwa staf operasi dilatih di Bahasa Kueri Kusto Melatih staf untuk membuat atau memodifikasi kueri saat diperlukan. Jika operator tidak dapat menulis atau memodifikasi kueri, itu dapat memperlambat pemecahan masalah penting atau fungsi lain karena operator harus mengandalkan tim lain untuk melakukan pekerjaan itu untuk mereka.
Rekomendasi konfigurasi untuk Keunggulan Operasional
Rekomendasi | Manfaat |
---|---|
Rancang strategi ruang kerja untuk memenuhi kebutuhan bisnis Anda. Lihat Merancang arsitektur ruang kerja Analitik Log untuk panduan tentang merancang strategi untuk ruang kerja Analitik Log Anda. Sertakan berapa banyak yang harus dibuat dan di mana menempatkannya. Jika Anda memerlukan beban kerja untuk menggunakan penawaran tim platform terpusat, pastikan Anda mengatur semua akses operasional yang diperlukan. Selain itu, buat pemberitahuan untuk memastikan kebutuhan pengamatan beban kerja terpenuhi. |
Satu atau setidaknya sedikit jumlah ruang kerja memaksimalkan efisiensi operasional beban kerja Anda. Ini membatasi distribusi data operasional dan keamanan Anda, meningkatkan visibilitas ke dalam masalah potensial, membuat pola lebih mudah diidentifikasi, dan meminimalkan persyaratan pemeliharaan Anda. Anda mungkin memiliki persyaratan untuk beberapa ruang kerja seperti beberapa penyewa, atau Anda mungkin memerlukan ruang kerja di beberapa wilayah untuk mendukung persyaratan ketersediaan Anda. Jadi, pastikan Anda memiliki proses yang sesuai untuk mengelola peningkatan kompleksitas ini. |
Gunakan infrastruktur sebagai kode (IaC) untuk menyebarkan dan mengelola ruang kerja dan fungsi terkait Anda. | Gunakan infrastruktur sebagai kode (IaC) untuk menentukan detail ruang kerja Anda dalam templat ARM, Azure BICEP, atau Terraform. Ini memungkinkan Anda menggunakan proses DevOps yang ada untuk menyebarkan ruang kerja baru dan Azure Policy untuk menegakkan konfigurasinya. Kolokasikan semua kode IaC Anda dengan kode aplikasi Anda membantu memastikan bahwa praktik penyebaran Anda yang aman dipertahankan untuk semua penyebaran. |
Gunakan wawasan ruang kerja Analitik Log untuk melacak kesehatan dan performa ruang kerja Analitik Log Anda, dan buat pemberitahuan yang bermakna dan dapat ditindakkan untuk diberi tahu secara proaktif tentang masalah operasional. Wawasan ruang kerja Log Analytics menyediakan tampilan terpadu tentang penggunaan, performa, kesehatan, agen, kueri, dan log perubahan untuk semua ruang kerja Anda. Setiap ruang kerja memiliki tabel operasi yang mencatat aktivitas penting yang memengaruhi ruang kerja. |
Tinjau informasi yang diberikan wawasan Log Analytics secara teratur untuk melacak kesehatan dan pengoperasian setiap ruang kerja Anda. Saat Anda menggunakan informasi ini, ini memungkinkan Anda membuat visualisasi yang mudah dipahami seperti dasbor atau laporan yang dapat digunakan operasi dan pemangku kepentingan untuk melacak kesehatan ruang kerja Anda. Buat aturan pemberitahuan berdasarkan tabel ini untuk diberi tahu secara proaktif saat masalah operasional terjadi. Anda dapat menggunakan pemberitahuan yang direkomendasikan untuk ruang kerja untuk menyederhanakan cara Anda membuat aturan pemberitahuan yang paling penting. |
Latih peningkatan berkelanjutan dengan sering mengunjungi kembali pengaturan diagnostik Azure pada sumber daya, aturan pengumpulan data, dan verbositas log aplikasi Anda. Pastikan Anda mengoptimalkan strategi pengumpulan log melalui tinjauan yang sering tentang pengaturan sumber daya Anda. Dari sudut depan operasional, lihat untuk mengurangi kebisingan di log Anda dengan berfokus pada log yang memberikan informasi berguna tentang status kesehatan sumber daya. |
Dengan mengoptimalkan dengan cara ini, Anda memungkinkan operator untuk menyelidiki dan memecahkan masalah ketika muncul, atau melakukan tugas rutin, improvisasi, atau darurat lainnya. Ketika kategori diagnostik baru tersedia untuk jenis sumber daya, tinjau jenis log yang dipancarkan dengan kategori ini untuk memahami apakah mengaktifkannya mungkin membantu Anda mengoptimalkan strategi pengumpulan Anda. Misalnya, kategori baru mungkin merupakan subset dari serangkaian aktivitas yang lebih besar yang sedang ditangkap. Subset baru mungkin memungkinkan Anda mengurangi volume log yang masuk dengan berfokus pada aktivitas yang penting untuk dilacak oleh operasi Anda. |
Azure Policy dan Azure Advisor
Azure tidak menawarkan kebijakan atau rekomendasi Azure Advisor yang terkait dengan keunggulan operasional ruang kerja Log Analytics.
Efisiensi kinerja
Efisiensi Performa adalah tentang mempertahankan pengalaman pengguna bahkan ketika ada peningkatan beban dengan mengelola kapasitas. Strategi ini mencakup penskalaan sumber daya, mengidentifikasi dan mengoptimalkan potensi hambatan, dan mengoptimalkan performa puncak.
Prinsip desain Efisiensi Performa menyediakan strategi desain tingkat tinggi untuk mencapai tujuan kapasitas tersebut terhadap penggunaan yang diharapkan.
Daftar periksa desain untuk Efisiensi Performa
Mulai strategi desain Anda berdasarkan daftar periksa tinjauan desain untuk Efisiensi Performa untuk menentukan garis besar untuk ruang kerja Analitik Log dan fungsi terkait Anda.
- Pahami dasar-dasar latensi penyerapan data log di Azure Monitor. Ada beberapa faktor yang berkontribusi pada latensi saat menyerap log ke ruang kerja Anda. Banyak dari faktor-faktor ini yang melekat pada platform Azure Monitor. Memahami faktor-faktor dan perilaku latensi normal dapat membantu Anda menetapkan ekspektasi yang sesuai dalam tim operasi beban kerja Anda.
- Pisahkan beban kerja nonproduksi dan produksi Anda. Ruang kerja khusus produksi mengurangi overhead apa pun yang mungkin diperkenalkan oleh sistem nonproduksi. Ini mengurangi jejak keseluruhan ruang kerja Anda, membutuhkan lebih sedikit sumber daya untuk menangani pemrosesan data log.
- Pilih wilayah penyebaran yang tepat untuk memenuhi persyaratan performa Anda. Sebarkan ruang kerja Log Analytics dan titik akhir pengumpulan data (DCEs) yang dekat dengan beban kerja Anda. Pilihan wilayah yang sesuai untuk menyebarkan ruang kerja dan DC Anda harus diberitahu oleh tempat Anda menyebarkan beban kerja. Anda mungkin perlu menimbang manfaat performa penyebaran ruang kerja dan DC Di wilayah yang sama dengan beban kerja terhadap persyaratan keandalan jika Anda telah menyebarkan beban kerja ke wilayah yang tidak dapat mendukung persyaratan tersebut untuk data log Anda.
Rekomendasi konfigurasi untuk Efisiensi Performa
Rekomendasi | Manfaat |
---|---|
Konfigurasikan audit kueri log dan gunakan wawasan ruang kerja Analitik Log untuk mengidentifikasi kueri yang lambat dan tidak efisien. Audit kueri log menyimpan waktu komputasi yang diperlukan untuk menjalankan setiap kueri dan waktu hingga hasil dikembalikan. Wawasan ruang kerja Analitik Log menggunakan data ini untuk mencantumkan kueri yang berpotensi tidak efisien di ruang kerja Anda. Pertimbangkan untuk menulis ulang kueri ini untuk meningkatkan performanya. Lihat Mengoptimalkan kueri log di Azure Monitor untuk panduan tentang mengoptimalkan kueri log Anda. |
Kueri yang dioptimalkan mengembalikan hasil lebih cepat dan menggunakan lebih sedikit sumber daya di ujung belakang, yang membuat proses yang mengandalkan kueri tersebut juga lebih efisien. |
Memahami batas layanan untuk ruang kerja Analitik Log. Dalam implementasi lalu lintas tinggi tertentu, Anda mungkin mengalami batas layanan yang memengaruhi performa dan ruang kerja atau desain beban kerja Anda. Misalnya, API kueri membatasi jumlah rekaman dan volume data yang dikembalikan oleh kueri. API Penyerapan Log membatasi ukuran setiap panggilan API. Untuk daftar lengkap batas dan batas ruang kerja Azure Monitor dan Analitik Log khusus untuk ruang kerja itu sendiri, lihat Batas layanan Azure Monitor. |
Memahami batasan yang mungkin memengaruhi performa ruang kerja membantu Anda merancang dengan tepat untuk menguranginya. Anda mungkin memutuskan untuk menggunakan beberapa ruang kerja untuk menghindari mencapai batas yang terkait dengan satu ruang kerja. Mempertimbangkan keputusan desain untuk mengurangi batas layanan terhadap persyaratan dan target untuk pilar lain. |
Buat DCI khusus untuk jenis sumber data di dalam satu atau beberapa cakupan pengamatan yang ditentukan. Buat DCR terpisah untuk performa dan peristiwa untuk mengoptimalkan pemanfaatan komputasi pemrosesan backend. | Saat Anda menggunakan DCI terpisah untuk performa dan peristiwa, ini membantu mengurangi kelelahan sumber daya backend. Dengan memiliki DCI yang menggabungkan peristiwa performa, ia memaksa setiap komputer virtual terkait untuk mentransfer, memproses, dan menjalankan konfigurasi yang mungkin tidak berlaku sesuai dengan perangkat lunak yang diinstal. Konsumsi dan kesalahan sumber daya komputasi yang berlebihan dalam memproses konfigurasi mungkin terjadi dan menyebabkan Agen Azure Monitor (AMA) menjadi tidak responsif. |
Azure Policy dan Azure Advisor
Azure tidak menawarkan kebijakan atau rekomendasi Azure Advisor yang terkait dengan performa ruang kerja Analitik Log.