Rekomendasi untuk merancang dan membuat sistem pemantauan

Berlaku untuk rekomendasi daftar periksa Azure Well-Architected Framework Operational Excellence ini:

OE:07 Merancang dan menerapkan sistem pemantauan untuk memvalidasi pilihan desain dan menginformasikan desain dan keputusan bisnis di masa mendatang. Sistem ini menangkap dan mengekspos telemetri operasional, metrik, dan log yang dikeluarkan dari infrastruktur dan kode beban kerja.

Panduan terkait: Rekomendasi untuk melengkapi aplikasi

Panduan ini menjelaskan rekomendasi untuk merancang dan membuat sistem pemantauan. Untuk memantau beban kerja Anda secara efektif untuk keamanan, performa, dan keandalan, Anda memerlukan sistem komprehensif dengan tumpukannya sendiri yang menyediakan fondasi untuk semua fungsi pemantauan, deteksi, dan pemberitahuan.

Definisi

Istilah Definisi
Log Peristiwa sistem yang direkam. Log dapat berisi berbagai jenis data dalam format teks terstruktur atau bentuk bebas. Mereka berisi tanda waktu.
Metrik Nilai numerik yang dikumpulkan secara berkala. Metrik menjelaskan beberapa aspek sistem pada waktu tertentu.

Strategi desain utama

Untuk menerapkan desain sistem pemantauan komprehensif untuk beban kerja Anda, ikuti prinsip inti berikut:

  • Setiap kali praktis, manfaatkan alat pemantauan yang disediakan platform, yang biasanya membutuhkan sangat sedikit konfigurasi dan dapat memberikan wawasan mendalam tentang beban kerja Anda yang mungkin sulit dicapai.

  • Kumpulkan log dan metrik dari seluruh tumpukan beban kerja. Semua sumber daya infrastruktur dan fungsi aplikasi harus dikonfigurasi untuk menghasilkan data standar yang bermakna, dan data tersebut perlu dikumpulkan.

  • Simpan data yang dikumpulkan dalam solusi penyimpanan yang standar, andal, dan aman.

  • Proses data yang disimpan sehingga dapat ditangani oleh solusi analisis dan visualisasi.

  • Analisis data yang diproses untuk menentukan status beban kerja secara akurat.

  • Visualisasikan status beban kerja dalam dasbor atau laporan yang bermakna untuk tim beban kerja dan pemangku kepentingan lainnya.

  • Konfigurasikan pemberitahuan yang dapat ditindaklanjuti dan respons otomatis lainnya ke ambang batas yang ditentukan secara cerdas untuk memberi tahu tim beban kerja saat masalah muncul.

  • Sertakan sistem pemantauan dan pemberitahuan dalam praktik pengujian beban kerja Anda secara keseluruhan.

  • Pastikan bahwa sistem pemantauan dan pemberitahuan berada dalam cakupan untuk peningkatan berkelanjutan. Perilaku aplikasi dan infrastruktur dalam produksi memberikan peluang pembelajaran berkelanjutan. Masukkan pelajaran tersebut ke dalam desain pemantauan dan peringatan.

  • Ikat data pemantauan yang Anda kumpulkan dan analisis kembali ke sistem dan alur pengguna Anda untuk menghubungkan kesehatan alur dengan data selain kesehatan beban kerja secara keseluruhan. Menganalisis bahwa data dalam hal alur akan membantu menyelaraskan strategi pengamatan Anda dengan model kesehatan Anda.

Anda harus mengotomatiskan semua fungsi sistem pemantauan sebanyak mungkin, dan semuanya harus berjalan terus menerus, sepanjang hari, setiap hari.

Alur kerja ini mengilustrasikan sistem pemantauan:

Diagram yang menunjukkan tahapan sistem pemantauan komprehensif sebagai alur.

Koleksi

Catatan

Anda perlu melengkapi aplikasi Anda untuk mengaktifkan pengelogan. Untuk informasi selengkapnya, lihat panduan instrumentasi.

Anda harus mengonfigurasi semua komponen beban kerja, baik itu sumber daya infrastruktur atau fungsi aplikasi, untuk menangkap telemetri dan/atau peristiwa seperti log dan metrik.

Log terutama berguna untuk mendeteksi dan menyelidiki anomali. Biasanya, log diproduksi oleh komponen beban kerja dan kemudian dikirim ke platform pemantauan atau ditarik oleh platform pemantauan melalui otomatisasi.

Metrik terutama berguna untuk membangun model kesehatan dan mengidentifikasi tren dalam performa dan keandalan beban kerja. Metrik juga berguna untuk mengidentifikasi tren dalam perilaku penggunaan pelanggan Anda. Tren ini dapat membantu memandu keputusan tentang peningkatan dari perspektif pelanggan. Biasanya, metrik didefinisikan dalam platform pemantauan, dan platform pemantauan dan alat lain melakukan polling beban kerja untuk menangkap metrik.

Data aplikasi

Untuk aplikasi, layanan pengumpulan dapat menjadi alat manajemen performa aplikasi (APM) yang dapat berjalan secara otonom dari aplikasi yang menghasilkan data instrumentasi. Setelah APM diaktifkan, Anda memiliki visibilitas yang jelas ke dalam metrik penting, secara real time dan historis. Gunakan tingkat pengelogan yang sesuai. Verbose logging dapat menimbulkan biaya yang signifikan. Atur tingkat log sesuai dengan lingkungan. Lingkungan yang lebih rendah tidak memerlukan tingkat verbositas yang sama dengan produksi, misalnya.

Log aplikasi mendukung siklus hidup aplikasi menyeluruh. Pengelogan sangat penting untuk memahami bagaimana aplikasi beroperasi di berbagai lingkungan, peristiwa mana yang terjadi, dan kondisi di mana mereka terjadi.

Kami menyarankan agar Anda mengumpulkan log dan peristiwa aplikasi di semua lingkungan utama. Pisahkan data antar lingkungan sebanyak mungkin dengan menggunakan penyimpanan data yang berbeda untuk setiap lingkungan, jika melakukannya praktis. Gunakan filter untuk memastikan bahwa lingkungan nonkritis tidak mempersulit interpretasi log produksi. Akhirnya, entri log yang sesuai di seluruh aplikasi harus menangkap ID korelasi untuk transaksi masing-masing.

Anda harus mengambil peristiwa aplikasi dalam jenis data terstruktur dengan titik data yang dapat dibaca mesin daripada jenis string yang tidak terstruktur. Format terstruktur yang menggunakan skema terkenal dapat membuat penguraian dan analisis log lebih mudah. Selain itu, data terstruktur dapat dengan mudah diindeks dan dicari, serta pelaporan dapat sangat disederhanakan.

Data harus dalam format agnostik yang independen dari komputer, sistem operasi, atau protokol jaringan. Misalnya, memancarkan informasi dalam format yang menjelaskan sendiri seperti JSON, MessagePack, atau Protobuf daripada ETL/ETW. Format standar memungkinkan sistem untuk membangun alur pemrosesan. Komponen yang membaca, mengubah, dan mengirim data dalam format standar dapat dengan mudah diintegrasikan.

Data infrastruktur

Untuk sumber daya infrastruktur dalam beban kerja Anda, pastikan Anda mengumpulkan log dan metrik. Untuk sistem infrastruktur sebagai layanan (IaaS), ambil OS, lapisan aplikasi, dan log diagnostik selain metrik yang terkait dengan kesehatan beban kerja. Untuk sumber daya platform as a service (PaaS), Anda mungkin terbatas pada kemampuan Anda untuk menangkap log yang terkait dengan infrastruktur dasar, tetapi pastikan Anda dapat menangkap log diagnostik selain metrik yang terkait dengan kesehatan beban kerja.

Sebanyak mungkin, kumpulkan log dari platform cloud Anda. Anda mungkin dapat mengumpulkan log aktivitas untuk langganan dan log diagnostik untuk bidang manajemen.

Strategi pengumpulan

Hindari mengambil data telemetri secara manual dari setiap komponen. Pindahkan data ke lokasi pusat dan konsolidasikan di sana. Untuk solusi multi-wilayah, kami sarankan Anda terlebih dahulu mengumpulkan, mengonsolidasikan, dan menyimpan data berdasarkan wilayah demi wilayah, lalu mengagregasi data regional ke dalam satu sistem pusat.

Tradeoff: Ketahuilah bahwa ada implikasi biaya untuk memiliki penyimpanan data regional dan terpusat.

Untuk mengoptimalkan penggunaan bandwidth, prioritaskan berdasarkan kepentingan data. Anda dapat mentransfer data yang kurang mendesak dalam batch. Namun, data ini tidak boleh ditunda tanpa batas waktu, terutama jika berisi informasi sensitif waktu.

Ada dua model utama yang dapat digunakan layanan pengumpulan untuk mengumpulkan data instrumentasi:

  • Model penarikan: Secara aktif mengambil data dari berbagai log dan sumber lainnya untuk setiap instans aplikasi.

  • Model pendorongan: Secara pasif menunggu data dikirim dari komponen yang merupakan setiap instans aplikasi.

Agen pemantauan

Anda dapat menggunakan agen pemantauan dalam model penarikan. Agen berjalan secara lokal dalam proses terpisah dengan setiap instans aplikasi, secara berkala menarik data dan menulis informasi langsung ke penyimpanan umum yang dibagikan oleh semua instans aplikasi.

Diagram yang menunjukkan penggunaan agen pemantauan untuk menarik informasi dan menulisnya ke penyimpanan bersama.

Catatan

Menggunakan agen pemantauan sangat cocok untuk menangkap data instrumentasi yang secara alami diambil dari sumber data. Ini sesuai untuk aplikasi skala kecil yang berjalan pada sejumlah node terbatas dalam satu lokasi. Contohnya termasuk informasi dari tampilan manajemen dinamis SQL Server atau panjang antrean Azure Service Bus.

Pertimbangan performa

Aplikasi yang kompleks dan sangat dapat diskalakan mungkin menghasilkan data dalam volume besar. Jumlah data dapat dengan mudah membuat bandwidth I/O tersedia untuk satu lokasi pusat. Solusi telemetri tidak boleh bertindak sebagai hambatan dan harus dapat diskalakan saat sistem berkembang. Idealnya, solusi harus menggabungkan tingkat redundansi untuk mengurangi risiko kehilangan informasi pemantauan penting (seperti data audit atau penagihan) jika bagian dari sistem gagal.

Salah satu cara untuk menyangga data instrumentasi adalah dengan menggunakan antrean:

Diagram yang memperlihatkan bagaimana Anda dapat menggunakan antrean untuk menyangga data instrumentasi.

Dalam arsitektur ini, layanan pengumpulan data memposting data ke antrean. Antrean pesan cocok karena menyediakan semantik "setidaknya sekali" yang membantu memastikan bahwa data antrean tidak akan hilang setelah diposting. Anda dapat menerapkan layanan penulisan penyimpanan dengan menggunakan peran pekerja terpisah. Anda dapat menggunakan pola Antrean Prioritas untuk mengimplementasikan arsitektur ini.

Untuk skalabilitas, Anda dapat menjalankan beberapa instans layanan penulisan penyimpanan. Jika volume peristiwa yang tinggi atau sejumlah besar titik data sedang dipantau, Anda dapat menggunakan Azure Event Hubs untuk mengirimkan data ke instans komputasi yang berbeda untuk pemrosesan dan penyimpanan.

Strategi konsolidasi

Data yang dikumpulkan dari satu instans aplikasi memberikan tampilan lokal tentang kesehatan dan performa instans tersebut. Untuk menilai kesehatan sistem secara keseluruhan, Anda perlu mengonsolidasikan beberapa aspek data dari tampilan lokal. Anda dapat melakukannya setelah data disimpan, tetapi, dalam beberapa kasus, Anda dapat melakukannya saat data dikumpulkan.

Diagram yang memperlihatkan contoh penggunaan layanan untuk mengonsolidasikan data instrumentasi.

Data instrumentasi dapat melewati layanan konsolidasi data terpisah yang menggabungkan data dan bertindak sebagai filter dan proses pembersihan. Misalnya, Anda dapat menggabungkan data instrumentasi yang menyertakan informasi korelasi yang sama, seperti ID aktivitas. (Pengguna mungkin memulai operasi bisnis pada satu simpul dan kemudian ditransfer ke simpul lain jika simpul pertama gagal, atau karena bagaimana penyeimbangan beban dikonfigurasi.) Proses ini juga dapat mendeteksi dan menghapus data duplikat apa pun. (Duplikasi dapat terjadi jika layanan telemetri menggunakan antrean pesan untuk mendorong data instrumentasi ke penyimpanan.)

Penyimpanan

Saat Anda memilih solusi penyimpanan, pertimbangkan jenis data, cara penggunaannya, dan seberapa mendesak diperlukan.

Catatan

Gunakan solusi penyimpanan terpisah untuk lingkungan non-produksi dan produksi untuk memastikan bahwa data dari setiap lingkungan mudah diidentifikasi dan dikelola.

Teknologi penyimpanan

Pertimbangkan pendekatan persistensi poliglot, di mana berbagai jenis informasi disimpan dalam teknologi yang paling sesuai dengan cara setiap jenis kemungkinan akan digunakan.

Misalnya, Azure Blob Storage dan Azure Table Storage diakses dengan cara yang sama. Tetapi operasi yang dapat Anda lakukan pada mereka berbeda, seperti halnya granularitas data yang mereka pegang. Jika Anda perlu melakukan lebih banyak operasi analitik atau memerlukan kemampuan pencarian teks lengkap pada data, mungkin lebih tepat menggunakan penyimpanan data yang menyediakan kemampuan yang dioptimalkan untuk jenis kueri dan akses data tertentu. Contohnya:

  • Data penghitung performa dapat disimpan dalam database SQL untuk mengaktifkan analisis ad hoc.

  • Mungkin lebih baik untuk menyimpan log jejak di Log Azure Monitor atau Azure Data Explorer.

  • Anda mungkin menyimpan informasi keamanan dalam solusi HDFS.

Data instrumentasi yang sama mungkin diperlukan untuk lebih dari satu tujuan. Misalnya, Anda dapat menggunakan penghitung kinerja untuk memberikan tampilan historis performa sistem dari waktu ke waktu. Informasi ini mungkin digabungkan dengan data penggunaan lain untuk menghasilkan informasi penagihan pelanggan. Dalam situasi ini, data yang sama mungkin dikirim ke lebih dari satu tujuan, seperti ke database dokumen yang dapat menjadi penyimpanan jangka panjang untuk menyimpan informasi penagihan, dan ke penyimpanan multidimensi untuk menangani analitik performa yang kompleks.

Pastikan untuk mengaktifkan fungsionalitas untuk melindungi data dari penghapusan yang tidak disengaja, seperti kunci sumber daya dan penghapusan sementara.

Selain itu, pastikan Anda mengamankan akses ke penyimpanan dengan menggunakan kontrol akses berbasis peran untuk membantu memastikan bahwa hanya individu yang perlu mengakses data yang dapat melakukannya.

Layanan konsolidasi

Anda dapat menerapkan layanan lain yang secara berkala mengambil data dari penyimpanan bersama, partisi, dan memfilternya sesuai dengan tujuannya, lalu menulisnya ke sekumpulan penyimpanan data yang sesuai.

Diagram yang memperlihatkan layanan partisi data yang memindahkan data ke penyimpanan data yang sesuai berdasarkan jenisnya.

Pendekatan alternatif adalah memasukkan fungsionalitas ini dalam proses konsolidasi dan pembersihan dan menulis data langsung ke penyimpanan ini saat diambil ketimbang menyimpannya di area penyimpanan bersama perantara.

Setiap pendekatan memiliki kelebihan dan kekurangan. Menerapkan layanan partisi terpisah mengurangi beban pada layanan konsolidasi dan pembersihan, dan memungkinkan setidaknya beberapa data yang dipartisi untuk diregenerasi jika perlu (tergantung pada berapa banyak data yang disimpan dalam penyimpanan bersama). Namun, pendekatan ini mengonsumsi sumber daya tambahan. Selain itu, mungkin ada penundaan antara penerimaan data instrumentasi dari setiap instans aplikasi dan konversi data ini menjadi informasi yang dapat ditindaklanjuti.

Mengkueri pertimbangan

Pertimbangkan seberapa mendesak data tersebut diperlukan. Data yang menghasilkan peringatan harus diakses dengan cepat, sehingga harus disimpan dalam penyimpanan data yang cepat dan diindeks atau terstruktur untuk mengoptimalkan kueri yang dilakukan sistem peringatan. Dalam beberapa kasus, layanan pengumpulan mungkin perlu memformat dan menyimpan data secara lokal sehingga instans lokal dari sistem peringatan dapat mengirim pemberitahuan dengan cepat. Data yang sama dapat dikirim ke layanan penulisan penyimpanan yang ditunjukkan pada diagram sebelumnya dan disimpan secara terpusat jika juga diperlukan untuk tujuan lain.

Pertimbangan retensi data

Dalam beberapa kasus, setelah data diproses dan ditransfer, Anda dapat menghapus data sumber mentah asli yang disimpan secara lokal. Dalam kasus lain, proses tersebut diperlukan atau berguna untuk menyimpan informasi mentah. Misalnya, Anda mungkin ingin menyimpan data yang dihasilkan untuk penelusuran kesalahan yang tersedia dalam bentuk mentahnya tetapi kemudian membuangnya dengan cepat setelah bug diselesaikan.

Data performa sering memiliki masa pakai yang lebih lama sehingga Anda dapat menggunakannya untuk melihat tren performa dan untuk perencanaan kapasitas. Tampilan gabungan dari data ini biasanya disimpan online untuk jangka waktu terbatas untuk memungkinkan akses cepat. Setelah itu, tampilan tersebut dapat diarsipkan atau dibuang.

Hal ini berguna untuk menyimpan data historis sehingga Anda dapat melihat tren jangka panjang. Daripada menyimpan data lama secara keseluruhan, Anda mungkin dapat menurunkan sampel data untuk mengurangi resolusinya dan menghemat biaya penyimpanan. Misalnya, daripada menyimpan indikator performa menit demi menit, Anda dapat mengonsolidasikan data yang berusia lebih dari sebulan untuk membentuk tampilan jam demi jam.

Data yang dikumpulkan untuk pengukuran dan penagihan pelanggan mungkin perlu disimpan tanpa batas waktu. Selain itu, persyaratan peraturan mungkin menentukan bahwa informasi yang dikumpulkan untuk audit dan keamanan perlu diarsipkan dan disimpan. Data ini juga sensitif dan mungkin perlu dienkripsi atau dilindungi untuk mencegah gangguan. Anda tidak boleh merekam kata sandi pengguna atau informasi lain yang mungkin digunakan untuk melakukan penipuan identitas. Anda harus menggosok detail ini dari data sebelum disimpan.

Untuk memastikan bahwa Anda mematuhi hukum dan peraturan, minimalkan penyimpanan informasi yang dapat diidentifikasi. Jika Anda perlu menyimpan informasi yang dapat diidentifikasi, pastikan, ketika Anda merancang solusi Anda, untuk mempertimbangkan persyaratan yang memungkinkan individu untuk meminta agar informasi mereka dihapus.

Analisis

Setelah Anda mengumpulkan data dari berbagai sumber data, analisis untuk menilai kesejahteraan sistem secara keseluruhan. Untuk analisis ini, memiliki pemahaman yang jelas tentang:

  • Cara menyusun data berdasarkan KPI dan metrik performa yang telah Anda tentukan.

  • Cara menghubungkan data yang diambil dalam metrik dan file log yang berbeda. Korelasi ini penting ketika Anda melacak urutan peristiwa dan dapat membantu Anda mendiagnosis masalah.

Dalam kebanyakan kasus, data untuk setiap komponen arsitektur ditangkap secara lokal dan kemudian dikombinasikan secara akurat dengan data yang dihasilkan oleh komponen lain.

Misalnya, aplikasi tiga tingkat mungkin memiliki:

  • Tingkat presentasi yang memungkinkan pengguna tersambung ke situs web.

  • Tingkat menengah yang menghosting serangkaian layanan mikro yang memproses logika bisnis.

  • Tingkat database yang menyimpan data yang terkait dengan operasi.

Data penggunaan untuk satu operasi bisnis mungkin mencakup ketiga tingkatan. Informasi ini perlu berkorelasi untuk memberikan pandangan keseluruhan tentang penggunaan sumber daya dan pemrosesan untuk operasi. Korelasi mungkin melibatkan beberapa prapemrosesan dan penyaringan data pada tingkat database. Pada tingkat tengah, agregasi dan pemformatan adalah tugas umum.

Rekomendasi

  • Menghubungkan log tingkat aplikasi dan tingkat sumber daya. Evaluasi data di kedua tingkat untuk mengoptimalkan deteksi masalah dan pemecahan masalah tersebut. Anda dapat mengagregasi data dalam satu sink data atau memanfaatkan metode yang mengkueri peristiwa di kedua tingkat. Kami merekomendasikan solusi terpadu, seperti Azure Log Analytics, untuk mengagregasi dan mengkueri log tingkat aplikasi dan tingkat sumber daya.

  • Tentukan waktu retensi yang jelas pada penyimpanan untuk analisis dingin. Kami merekomendasikan praktik ini untuk mengaktifkan analisis historis selama periode tertentu. Ini juga dapat membantu Anda mengontrol biaya penyimpanan. Terapkan proses yang memastikan data diarsipkan ke penyimpanan yang lebih murah dan data agregat untuk analisis tren jangka panjang.

  • Analisis tren jangka panjang untuk memprediksi masalah operasional. Evaluasi data jangka panjang untuk membentuk strategi operasional dan juga untuk memprediksi masalah operasional apa yang mungkin terjadi, dan kapan. Misalnya, Anda mungkin mencatat bahwa waktu respons rata-rata perlahan meningkat dari waktu ke waktu dan mendekati target maksimum.

Untuk panduan terperinci tentang rekomendasi ini, lihat Menganalisis data pemantauan untuk aplikasi cloud.

Visualisasi

Dasbor

Cara paling umum untuk memvisualisasikan data adalah dengan menggunakan dasbor yang dapat menampilkan informasi sebagai serangkaian bagan atau grafik, atau dalam beberapa bentuk visual lainnya. Item ini dapat diparameterkan, dan analis dapat memilih parameter penting, seperti periode waktu, untuk situasi tertentu.

Selaraskan dasbor Anda dengan model kesehatan Anda sehingga menunjukkan kapan beban kerja atau komponen beban kerja sehat, terdegradasi, atau tidak sehat.

Agar sistem dasbor berfungsi secara efektif, sistem harus bermakna bagi tim beban kerja. Visualisasikan informasi yang berkaitan dengan kesehatan beban kerja dan itu juga dapat ditindak lanjuti. Ketika beban kerja atau komponen terdegradasi atau tidak sehat, anggota tim beban kerja harus dapat dengan mudah mengidentifikasi di mana dalam beban kerja masalah berasal dan memulai tindakan atau investigasi korektif mereka. Sebaliknya, termasuk informasi yang tidak dapat ditindaklanjuti atau yang tidak terkait dengan kesehatan beban kerja dapat membuat dasbor menjadi sangat kompleks dan membuat frustrasi anggota tim yang mencoba membedakan kebisingan latar belakang dari data yang dapat ditindaklanjuti.

Anda mungkin memiliki dasbor untuk pemangku kepentingan atau pengembang yang disesuaikan untuk hanya menampilkan data tentang beban kerja yang menurut mereka relevan. Pastikan bahwa tim beban kerja memahami jenis poin data yang tertarik oleh tim lain untuk melihat dan mempratinjau dasbor sebelum membagikannya untuk memeriksa kejelasannya. Menyediakan dasbor tentang beban kerja Anda bagi pemangku kepentingan adalah cara yang baik untuk menjaga mereka tetap mengetahui kesehatan beban kerja, tetapi membawa risiko menjadi kontraproduktif jika pemangku kepentingan tidak memahami dengan jelas data yang mereka lihat.

Dasbor yang baik tidak hanya menampilkan informasi. Ini juga memungkinkan analis untuk menimbulkan pertanyaan improvisasi tentang informasi tersebut. Beberapa sistem menyediakan alat manajemen yang dapat digunakan operator untuk menyelesaikan tugas-tugas ini dan mengeksplorasi data yang mendasarinya. Sebaliknya, tergantung pada repositori yang digunakan untuk menyimpan informasi, mungkin untuk mengkueri data secara langsung atau mengimpornya ke alat seperti Excel untuk analisis dan pelaporan lebih lanjut.

Catatan

Membatasi akses dasbor ke personel yang berwenang. Informasi tentang dasbor mungkin sensitif secara komersial. Anda juga harus melindungi data yang mendasar untuk mencegah pengguna mengubahnya.

Pelaporan

Pelaporan digunakan untuk menghasilkan tampilan keseluruhan sistem. Ini mungkin menggabungkan data historis dan informasi saat ini. Persyaratan pelaporan termasuk dalam dua kategori besar: pelaporan operasional dan pelaporan keamanan.

Pelaporan operasional biasanya mencakup hal-hal berikut:

  • Menggabungkan statistik yang dapat Anda gunakan untuk memahami pemanfaatan sumber daya dari keseluruhan sistem atau subsistem tertentu selama jendela waktu tertentu.

  • Mengidentifikasi tren dalam penggunaan sumber daya untuk keseluruhan sistem atau subsistem tertentu selama periode tertentu.

  • Memantau pengecualian yang telah terjadi di seluruh sistem atau dalam subsistem tertentu selama periode tertentu.

  • Menentukan efisiensi aplikasi untuk sumber daya yang disebarkan, dan memahami apakah volume sumber daya, dan biaya terkaitnya, dapat dikurangi tanpa memengaruhi performa yang tidak perlu.

Pelaporan keamanan melacak penggunaan sistem oleh pelanggan. Yang mencakup:

  • Mengaudit operasi pengguna. Tugas ini memerlukan perekaman permintaan individual yang diselesaikan setiap pengguna, bersama dengan tanggal dan waktu. Data harus disusun untuk memungkinkan administrator dengan cepat mengonstruksi urutan operasi yang diselesaikan pengguna selama periode tertentu.

  • Melacak penggunaan sumber daya oleh pengguna. Tugas ini memerlukan perekaman bagaimana setiap permintaan dari pengguna mengakses berbagai sumber daya yang menyusun sistem, dan berapa lama. Administrator dapat menggunakan data ini untuk menghasilkan laporan pemanfaatan, oleh pengguna, selama periode tertentu, mungkin untuk penagihan.

Dalam banyak kasus, proses batch dapat menghasilkan laporan sesuai dengan jadwal yang ditentukan. Latensi biasanya tidak menjadi masalah. Anda juga harus memiliki proses batch yang dapat menghasilkan laporan secara spontan, sesuai kebutuhan. Misalnya, jika Anda menyimpan data dalam database relasional seperti Azure SQL Database, Anda dapat menggunakan alat seperti SQL Server Reporting Services untuk mengekstrak dan memformat data dan menyajikannya sebagai sekumpulan laporan.

Peringatan

Untuk membantu memastikan bahwa sistem tetap sehat, responsif, dan aman, atur pemberitahuan sehingga operator dapat meresponsnya secara tepat waktu. Pemberitahuan dapat berisi informasi kontekstual yang cukup untuk membantu mereka memulai aktivitas diagnostik dengan cepat. Peringatan dapat digunakan untuk memanggil fungsi remediasi seperti penskalaan otomatis atau mekanisme penyembuhan mandiri lainnya. Pemberitahuan juga dapat memungkinkan kesadaran biaya dengan memberikan visibilitas ke dalam anggaran dan batasan.

Rekomendasi

  • Tentukan proses untuk respons peringatan yang mengidentifikasi pemilik dan tindakan yang bertanggung jawab.

  • Konfigurasikan peringatan untuk cakupan yang terdefinisi dengan baik (jenis sumber daya dan grup sumber daya) dan sesuaikan verbositas untuk meminimalkan kebisingan.

  • Gunakan solusi pemberitahuan otomatis, seperti Splunk atau Azure Monitor, alih-alih mengharuskan orang untuk secara aktif mencari masalah.

  • Gunakan pemberitahuan untuk mengoprasi proses remediasi. Misalnya, secara otomatis membuat tiket untuk melacak masalah dan resolusi.

  • Lacak kesehatan layanan platform cloud Anda di wilayah, komunikasi tentang pemadaman, aktivitas pemeliharaan terencana, dan saran kesehatan lainnya.

Ambang

Pemberitahuan dihasilkan saat ambang batas dilewati, seperti yang terdeteksi oleh sistem pemantauan Anda. Pastikan bahwa ambang yang Anda tetapkan umumnya memberi Anda cukup waktu untuk menerapkan perubahan yang diperlukan pada beban kerja Anda untuk menghindari degradasi atau pemadaman. Misalnya, atur ambang penskalaan otomatis Anda untuk memulai penskalaan sebelum salah satu sistem yang sedang berjalan menjadi kewalahan ke titik pengalaman pengguna yang terdegradasi. Dasarkan nilai ambang yang Anda tetapkan pada pengalaman sebelumnya dalam mengelola infrastruktur dan memvalidasinya melalui pengujian yang Anda lakukan sebagai bagian dari praktik pengujian Anda.

Untuk panduan terperinci tentang memperingatkan kasus penggunaan dan pertimbangan lainnya, lihat Merancang strategi pemantauan dan pemberitahuan yang andal.

Fasilitasi Azure

  • Azure Monitor adalah solusi pemantauan komprehensif untuk mengumpulkan, menganalisis, dan merespons data pemantauan dari lingkungan cloud dan lokal Anda.

  • Analitik Log adalah alat di portal Azure yang dapat Anda gunakan untuk mengedit dan menjalankan kueri log terhadap data di ruang kerja Analitik Log.

    Jika Anda menggunakan beberapa ruang kerja, lihat panduan arsitektur ruang kerja Analitik Log untuk praktik terbaik.

  • Application Insights adalah ekstensi dari Azure Monitor. Ini menyediakan fitur APM.

  • Azure Monitor Insights adalah alat analitik tingkat lanjut untuk teknologi Azure tertentu (seperti VM, layanan aplikasi, dan kontainer). Alat-alat ini adalah bagian dari Azure Monitor dan Analitik Log.

  • Azure Monitor untuk solusi SAP adalah alat pemantauan Azure untuk lanskap SAP yang berjalan di Azure.

  • Azure Policy dapat membantu Anda menegakkan standar organisasi dan menilai kepatuhan dalam skala besar.

  • Azure Monitor Baseline Alerts (AMBA) adalah repositori terpusat definisi pemberitahuan yang dapat digunakan pelanggan dan mitra untuk meningkatkan pengalaman pengamatan mereka melalui adopsi Azure Monitor.

Daftar periksa Keunggulan Operasional

Lihat kumpulan rekomendasi lengkap.