Pertimbangan platform aplikasi untuk beban kerja misi penting

Area desain utama dari setiap arsitektur misi penting adalah platform aplikasi. Platform mengacu pada komponen infrastruktur dan layanan Azure yang harus disediakan untuk mendukung aplikasi. Berikut adalah beberapa rekomendasi menyeluruh.

• Desain dalam lapisan. Pilih set layanan yang tepat, konfigurasinya, dan dependensi khusus aplikasi. Pendekatan berlapis ini membantu dalam membuat segmentasi logis dan fisik. Ini berguna dalam menentukan peran dan fungsi, dan menetapkan hak istimewa yang sesuai, dan strategi penyebaran. Pendekatan ini pada akhirnya meningkatkan keandalan sistem.

• Aplikasi misi penting harus sangat andal dan tahan terhadap kegagalan pusat data dan regional. Membangun zonal dan redundansi regional dalam konfigurasi aktif-aktif adalah strategi utama. Saat Anda memilih layanan Azure untuk platform aplikasi Anda, pertimbangkan dukungan Zona Ketersediaan dan penyebaran dan pola operasional mereka untuk menggunakan beberapa wilayah Azure.

• Gunakan arsitektur berbasis unit skala untuk menangani peningkatan beban. Unit skala memungkinkan Anda mengelompokkan sumber daya secara logis dan unit dapat diskalakan secara independen dari unit atau layanan lain dalam arsitektur. Gunakan model kapasitas Anda dan performa yang diharapkan untuk menentukan batas, jumlah, dan skala dasar setiap unit.

Dalam arsitektur ini, platform aplikasi terdiri dari sumber daya global, stempel penyebaran, dan regional. Sumber daya regional disediakan sebagai bagian dari stempel penyebaran. Setiap stempel sama dengan unit skala dan, jika menjadi tidak sehat, dapat diganti sepenuhnya.

Sumber daya di setiap lapisan memiliki karakteristik yang berbeda. Untuk informasi selengkapnya, lihat Pola arsitektur beban kerja misi penting yang khas.

Karakteristik	Pertimbangan
Masa pakai	Berapa masa pakai sumber daya yang diharapkan, relatif terhadap sumber daya lain dalam solusi? Haruskah sumber daya lebih lama atau berbagi masa pakai dengan seluruh sistem atau wilayah, atau harus bersifat sementara?
Provinsi	Dampak apa yang akan ditimbulkan oleh status yang bertahan pada lapisan ini pada keandalan atau pengelolaan?
Jangkauan	Apakah sumber daya diperlukan untuk didistribusikan secara global? Dapatkah sumber daya berkomunikasi dengan sumber daya lain, secara global atau di wilayah?
Dependensi	Apa dependensi pada sumber daya lain, secara global atau di wilayah lain?
Batas skala	Throughput apa yang diharapkan untuk sumber daya tersebut pada lapisan tersebut? Berapa banyak skala yang disediakan oleh sumber daya agar sesuai dengan permintaan tersebut?
Ketersediaan/pemulihan bencana	Apa dampaknya pada ketersediaan atau bencana pada lapisan ini? Apakah akan menyebabkan pemadaman sistemik atau hanya masalah kapasitas atau ketersediaan yang dilokalkan?

Sumber daya global

Sumber daya tertentu dalam arsitektur ini dibagikan oleh sumber daya yang disebarkan di wilayah. Dalam arsitektur ini, mereka digunakan untuk mendistribusikan lalu lintas di beberapa wilayah, menyimpan status permanen untuk seluruh aplikasi, dan menyimpan data statis global cache.

Karakteristik	Pertimbangan Lapisan
Masa pakai	Sumber daya ini diharapkan untuk hidup lama. Masa pakai mereka mencakup masa pakai sistem atau lebih lama. Seringkali sumber daya dikelola dengan pembaruan data dan sarana kontrol di tempat, dengan asumsi sumber daya mendukung operasi pembaruan nol waktu henti.
Provinsi	Karena sumber daya ini ada setidaknya untuk masa pakai sistem, lapisan ini sering bertanggung jawab untuk menyimpan status global yang direplikasi secara geografis.
Jangkauan	Sumber daya harus didistribusikan secara global. Disarankan agar sumber daya ini berkomunikasi dengan sumber daya regional atau lainnya dengan latensi rendah dan konsistensi yang diinginkan.
Dependensi	Sumber daya harus menghindari dependensi pada sumber daya regional karena tidak tersedianya sumber daya dapat menjadi penyebab kegagalan global. Misalnya, sertifikat atau rahasia yang disimpan dalam satu vault dapat berdampak global jika ada kegagalan regional di mana vault berada.
Batas skala	Seringkali sumber daya ini adalah instans singleton dalam sistem, dan dengan demikian mereka harus dapat menskalakan sehingga mereka dapat menangani throughput sistem secara keseluruhan.
Ketersediaan/pemulihan bencana	Karena sumber daya regional dan stempel dapat mengonsumsi sumber daya global atau dihadapkan oleh sumber daya global, sangat penting bahwa sumber daya global dikonfigurasi dengan ketersediaan tinggi dan pemulihan bencana untuk kesehatan seluruh sistem.

Dalam arsitektur ini, sumber daya lapisan global adalah Azure Front Door, Azure Cosmos DB, Azure Container Registry, dan Azure Log Analytics untuk menyimpan log dan metrik dari sumber daya lapisan global lainnya.

Ada sumber daya dasar lainnya dalam desain ini, seperti ID Microsoft Entra dan Azure DNS. Mereka telah dihilangkan dalam gambar ini untuk keringkasan.

Penyeimbang muatan global

Azure Front Door digunakan sebagai satu-satunya titik masuk untuk lalu lintas pengguna. Azure menjamin bahwa Azure Front Door akan mengirimkan konten yang diminta tanpa kesalahan 99,99% dari waktu. Untuk detail selengkapnya, lihat Batas layanan Front Door. Jika Front Door menjadi tidak tersedia, pengguna akhir akan melihat sistem sedang tidak berfungsi.

Instans Front Door mengirim lalu lintas ke layanan backend yang dikonfigurasi, seperti kluster komputasi yang menghosting API dan SPA frontend. Kesalahan konfigurasi backend di Front Door dapat menyebabkan pemadaman. Untuk menghindari pemadaman karena kesalahan konfigurasi, Anda harus menguji pengaturan Front Door Anda secara ekstensif.

Kesalahan umum lainnya dapat berasal dari sertifikat TLS yang salah dikonfigurasi atau hilang, yang dapat mencegah pengguna menggunakan ujung depan atau Front Door berkomunikasi ke backend. Mitigasi mungkin memerlukan intervensi manual. Misalnya, Anda dapat memilih untuk kembali ke konfigurasi sebelumnya dan menerbitkan ulang sertifikat, jika memungkinkan. Terlepas dari itu, mengharapkan tidak tersedianya saat perubahan berlaku. Menggunakan sertifikat terkelola yang ditawarkan oleh Front door disarankan untuk mengurangi overhead operasional, seperti menangani kedaluwarsa.

Front Door menawarkan banyak kemampuan tambahan selain perutean lalu lintas global. Kemampuan penting adalah Web Application Firewall (WAF), karena Front Door dapat memeriksa lalu lintas yang sedang melintas. Ketika dikonfigurasi dalam mode Pencegahan , itu akan memblokir lalu lintas yang mencurigakan bahkan sebelum mencapai salah satu backend.

Untuk informasi tentang kemampuan Front Door, lihat Tanya jawab umum untuk Azure Front Door.

Untuk pertimbangan lain tentang distribusi lalu lintas global, lihat Panduan penting Misson dalam Kerangka Kerja yang dirancang dengan baik: Perutean global.

Container Registry

Azure Container Registry digunakan untuk menyimpan artefak Open Container Initiative (OCI), khususnya bagan helm dan gambar kontainer. Ini tidak berpartisipasi dalam alur permintaan dan hanya diakses secara berkala. Registri kontainer diperlukan untuk ada sebelum sumber daya stempel disebarkan dan tidak boleh memiliki dependensi pada sumber daya lapisan regional.

Aktifkan redundansi zona dan replikasi geografis registri sehingga akses runtime ke gambar cepat dan tahan terhadap kegagalan. Jika tidak tersedia, instans kemudian dapat melakukan failover ke wilayah replika dan permintaan secara otomatis dirutekan ulang ke wilayah lain. Harapkan kesalahan sementara dalam menarik gambar hingga failover selesai.

Kegagalan juga dapat terjadi jika gambar dihapus secara tidak sengaja, simpul komputasi baru tidak akan dapat menarik gambar, tetapi simpul yang ada masih dapat menggunakan gambar yang di-cache. Strategi utama untuk pemulihan bencana adalah penyebaran ulang. Artefak dalam registri kontainer dapat diregenerasi dari alur. Registri kontainer harus dapat menahan banyak koneksi bersamaan untuk mendukung semua penyebaran Anda.

Disarankan agar Anda menggunakan SKU Premium untuk mengaktifkan replikasi geografis. Fitur redundansi zona memastikan ketahanan dan ketersediaan tinggi dalam wilayah tertentu. Jika terjadi pemadaman regional, replika di wilayah lain masih tersedia untuk operasi sarana data. Dengan SKU ini, Anda dapat membatasi akses ke gambar melalui titik akhir privat.

Untuk detail selengkapnya, lihat Praktik terbaik untuk Azure Container Registry.

Database

Disarankan agar semua status disimpan secara global dalam database yang dipisahkan dari stempel regional. Bangun redundansi dengan menyebarkan database di seluruh wilayah. Untuk beban kerja misi penting, menyinkronkan data di seluruh wilayah harus menjadi perhatian utama. Selain itu, jika terjadi kegagalan, permintaan tulis ke database harus tetap berfungsi.

Replikasi data dalam konfigurasi aktif-aktif sangat disarankan. Aplikasi harus dapat langsung terhubung dengan wilayah lain. Semua instans harus dapat menangani permintaan baca dan tulis.

Untuk informasi selengkapnya, lihat Platform data untuk beban kerja misi penting.

Pemantauan global

Azure Log Analytics digunakan untuk menyimpan log diagnostik dari semua sumber daya global. Disarankan agar Anda membatasi kuota harian pada penyimpanan terutama pada lingkungan yang digunakan untuk pengujian beban. Selain itu, tetapkan kebijakan penyimpanan. Pembatasan ini akan mencegah pengeluaran berlebih yang dikeluarkan dengan menyimpan data yang tidak diperlukan di luar batas.

Pertimbangan untuk layanan dasar

Sistem ini kemungkinan akan menggunakan layanan platform penting lainnya yang dapat menyebabkan seluruh sistem berisiko, seperti Azure DNS dan ID Microsoft Entra. Azure DNS menjamin SLA ketersediaan 100% untuk permintaan DNS yang valid. Microsoft Entra menjamin setidaknya 99,99% waktu aktif. Namun, Anda harus menyadari dampaknya jika terjadi kegagalan.

Mengambil dependensi keras pada layanan dasar tidak dapat dihindari karena banyak layanan Azure bergantung padanya. Mengharapkan gangguan dalam sistem jika tidak tersedia. Contohnya:

• Azure Front Door menggunakan Azure DNS untuk menjangkau backend dan layanan global lainnya.
• Azure Container Registry menggunakan Azure DNS untuk mengalihkan permintaan ke wilayah lain.

Dalam kedua kasus, kedua layanan Azure akan terpengaruh jika Azure DNS tidak tersedia. Resolusi nama untuk permintaan pengguna dari Front Door akan gagal; Gambar Docker tidak akan ditarik dari registri. Menggunakan layanan DNS eksternal sebagai cadangan tidak akan mengurangi risiko karena banyak layanan Azure tidak mengizinkan konfigurasi tersebut dan mengandalkan DNS internal. Mengharapkan pemadaman penuh.

Demikian pula, MICROSOFT Entra ID digunakan untuk operasi sarana kontrol seperti membuat simpul AKS baru, menarik gambar dari Container Registry, atau mengakses Key Vault pada startup pod. Jika ID Microsoft Entra tidak tersedia, komponen yang ada seharusnya tidak terpengaruh, tetapi performa keseluruhan mungkin terdegradasi. Pod atau simpul AKS baru tidak akan berfungsi. Jadi, jika operasi peluasan skala diperlukan selama waktu ini, mengharapkan penurunan pengalaman pengguna.

Sumber daya stempel penyebaran regional

Dalam arsitektur ini, stempel penyebaran menyebarkan beban kerja dan menyediakan sumber daya yang berpartisipasi dalam menyelesaikan transaksi bisnis. Stempel biasanya sesuai dengan penyebaran ke wilayah Azure. Meskipun suatu wilayah dapat memiliki lebih dari satu stempel.

Karakteristik	Pertimbangan
Masa pakai	Sumber daya diharapkan memiliki rentang hidup pendek (sementara) dengan niat bahwa sumber daya dapat ditambahkan dan dihapus secara dinamis sementara sumber daya regional di luar stempel terus bertahan. Sifat sementara diperlukan untuk memberikan lebih banyak ketahanan, skala, dan kedekatan dengan pengguna.
Provinsi	Karena stempel bersifat sementara dan dapat dihancurkan kapan saja, stempel harus tanpa status sebanyak mungkin.
Jangkauan	Dapat berkomunikasi dengan sumber daya regional dan global. Namun, komunikasi dengan wilayah lain atau stempel lain harus dihindari. Dalam arsitektur ini, tidak perlu sumber daya ini didistribusikan secara global.
Dependensi	Sumber daya stempel harus independen. Artinya, mereka tidak boleh mengandalkan stempel atau komponen lain di wilayah lain. Mereka diharapkan memiliki dependensi regional dan global. Komponen bersama utama adalah lapisan database dan registri kontainer. Komponen ini memerlukan sinkronisasi saat runtime.
Batas skala	Throughput ditetapkan melalui pengujian. Throughput stempel keseluruhan terbatas pada sumber daya yang paling tidak berkinerja. Throughput stempel perlu memperhitungkan perkiraan permintaan tingkat tinggi dan failover apa pun karena stempel lain di wilayah menjadi tidak tersedia.
Ketersediaan/pemulihan bencana	Karena sifat stempel sementara, pemulihan bencana dilakukan dengan menyebarkan ulang stempel. Jika sumber daya dalam keadaan tidak sehat, stempel, secara keseluruhan, dapat dihancurkan dan disebarkan ulang.

Dalam arsitektur ini, sumber daya stempel adalah Azure Kubernetes Service, Azure Event Hubs, Azure Key Vault, dan Azure Blob Storage.

Unit skala

Stempel juga dapat dianggap sebagai unit skala (SU). Semua komponen dan layanan dalam stempel tertentu dikonfigurasi dan diuji untuk melayani permintaan dalam rentang tertentu. Berikut adalah contoh unit skala yang digunakan dalam implementasi.

Setiap unit skala disebarkan ke wilayah Azure dan oleh karena itu terutama menangani lalu lintas dari area tertentu tersebut (meskipun dapat mengambil alih lalu lintas dari wilayah lain saat diperlukan). Penyebaran geografis ini kemungkinan akan mengakibatkan pola beban dan jam kerja yang mungkin bervariasi dari wilayah ke wilayah dan dengan demikian, setiap SU dirancang untuk menskalakan masuk/turun saat diam.

Anda dapat menyebarkan stempel baru untuk menskalakan. Di dalam stempel, sumber daya individual juga dapat menjadi unit skala.

Berikut adalah beberapa pertimbangan penskalaan dan ketersediaan saat memilih layanan Azure dalam unit:

• Mengevaluasi hubungan kapasitas antara semua sumber daya dalam unit skala. Misalnya, untuk menangani 100 permintaan masuk, 5 pod pengontrol ingress dan 3 pod layanan katalog dan 1000 RU di Azure Cosmos DB akan diperlukan. Jadi, saat menskalakan pod ingress secara otomatis, harapkan penskalaan layanan katalog dan RUs Azure Cosmos DB mengingat rentang tersebut.

• Uji beban layanan untuk menentukan rentang di mana permintaan akan dilayani. Berdasarkan hasil mengonfigurasi instans minimum dan maksimum serta metrik target. Ketika target tercapai, Anda dapat memilih untuk mengotomatiskan penskalaan seluruh unit.

• Tinjau batas dan kuota skala langganan Azure untuk mendukung model kapasitas dan biaya yang ditetapkan oleh persyaratan bisnis. Periksa juga batas layanan individu dalam pertimbangan. Karena unit biasanya disebarkan bersama-sama, faktor dalam batas sumber daya langganan yang diperlukan untuk penyebaran kenari. Untuk informasi selengkapnya, lihat Batas layanan Azure.

• Pilih layanan yang mendukung zona ketersediaan untuk membangun redundansi. Ini mungkin membatasi pilihan teknologi Anda. Lihat Zona Ketersediaan untuk detailnya.

Untuk pertimbangan lain tentang ukuran unit, dan kombinasi sumber daya, lihat Panduan penting Misson dalam Kerangka Kerja yang dirancang dengan baik: Arsitektur unit skala.

Hitung cluster

Untuk mengkontainerisasi beban kerja, setiap stempel perlu menjalankan kluster komputasi. Dalam arsitektur ini, Azure Kubernetes Service (AKS) dipilih karena Kubernetes adalah platform komputasi paling populer untuk aplikasi modern dan dalam kontainer.

Masa pakai kluster AKS terikat pada sifat sementara stempel. Kluster ini tanpa status dan tidak memiliki volume persisten. Ini menggunakan disk OS ephemeral alih-alih disk terkelola karena tidak diharapkan untuk menerima pemeliharaan tingkat aplikasi atau sistem.

Untuk meningkatkan keandalan, kluster dikonfigurasi untuk menggunakan ketiga zona ketersediaan di wilayah tertentu. Hal ini memungkinkan kluster menggunakan AKS Uptime SLA yang menjamin ketersediaan SLA 99,95% dari sarana kontrol AKS.

Faktor lain seperti batas skala, kapasitas komputasi, kuota langganan juga dapat memengaruhi keandalan. Jika kapasitas atau batas tidak cukup tercapai, operasi peluasan skala dan peningkatan skala akan gagal tetapi komputasi yang ada diharapkan berfungsi.

Kluster memiliki penskalaan otomatis yang diaktifkan untuk memungkinkan kumpulan simpul secara otomatis meluaskan skala jika diperlukan, yang meningkatkan keandalan. Saat menggunakan beberapa kumpulan simpul, semua kumpulan simpul harus diskalakan otomatis.

Pada tingkat pod, Horizontal Pod Autoscaler (HPA) menskalakan pod berdasarkan CPU, memori, atau metrik kustom yang dikonfigurasi. Uji beban komponen beban kerja untuk membuat garis besar untuk nilai autoscaler dan HPA.

Kluster juga dikonfigurasi untuk peningkatan gambar simpul otomatis dan untuk menskalakan dengan tepat selama peningkatan tersebut. Penskalaan ini memungkinkan waktu henti nol saat peningkatan sedang dilakukan. Jika kluster dalam satu stempel gagal selama peningkatan, kluster lain di stempel lain tidak boleh terpengaruh, tetapi peningkatan di seluruh stempel harus terjadi pada waktu yang berbeda untuk mempertahankan ketersediaan. Selain itu, peningkatan kluster secara otomatis digulirkan di seluruh simpul sehingga tidak tersedia secara bersamaan.

Beberapa komponen seperti cert-manager dan ingress-nginx memerlukan gambar kontainer dari registri kontainer eksternal. Jika repositori atau gambar tersebut tidak tersedia, instans baru pada simpul baru (di mana gambar tidak di-cache) mungkin tidak dapat dimulai. Risiko ini dapat dimitigasi dengan mengimpor citra ini ke Azure Container Registry lingkungan.

Pengamatan sangat penting dalam arsitektur ini karena stempel bersifat ephemeral. Pengaturan diagnostik dikonfigurasi untuk menyimpan semua data log dan metrik di ruang kerja Analitik Log regional. Selain itu, Wawasan Kontainer AKS diaktifkan melalui Agen OMS dalam kluster. Agen ini memungkinkan kluster mengirim data pemantauan ke ruang kerja Analitik Log.

Untuk pertimbangan lain tentang kluster komputasi, lihat Panduan penting Misson dalam Kerangka Kerja yang dirancang dengan baik: Orkestrasi Kontainer dan Kubernetes.

Key Vault

Azure Key Vault digunakan untuk menyimpan rahasia global seperti string koneksi ke database dan rahasia stempel seperti azure Event Hubs string koneksi.

Arsitektur ini menggunakan driver Secrets Store CSI di kluster komputasi untuk mendapatkan rahasia dari Key Vault. Rahasia diperlukan ketika pod baru diluapkan. Jika Key Vault tidak tersedia, pod baru mungkin tidak dimulai. Akibatnya, mungkin ada gangguan; operasi peluasan skala dapat terpengaruh, pembaruan dapat gagal, penyebaran baru tidak dapat dijalankan.

Key Vault memiliki batasan jumlah operasi. Karena pembaruan rahasia otomatis, batas dapat dicapai jika ada banyak pod. Anda dapat memilih untuk mengurangi frekuensi pembaruan untuk menghindari situasi ini.

Untuk pertimbangan lain tentang manajemen rahasia, lihat Panduan penting Misson dalam Kerangka Kerja yang dirancang dengan baik: Perlindungan integritas data.

Event Hubs

Satu-satunya layanan stateful dalam stempel adalah broker pesan, Azure Event Hubs, yang menyimpan permintaan untuk jangka waktu singkat. Broker melayani kebutuhan akan penyanggaan dan olahpesan yang andal. Permintaan yang diproses dipertahankan dalam database global.

Dalam arsitektur ini, SKU Standar digunakan dan redundansi zona diaktifkan untuk ketersediaan tinggi.

Kesehatan Azure Event Hubs diverifikasi oleh komponen HealthService yang berjalan pada kluster komputasi. Ini melakukan pemeriksaan berkala terhadap berbagai sumber daya. Ini berguna dalam mendeteksi kondisi yang tidak sehat. Misalnya, jika pesan tidak dapat dikirim ke pusat aktivitas, stempel tidak akan dapat digunakan untuk operasi tulis apa pun. HealthService harus secara otomatis mendeteksi kondisi ini dan melaporkan status tidak sehat ke Front Door, yang akan mengambil stempel keluar dari rotasi.

Untuk skalabilitas, disarankan untuk mengaktifkan inflate otomatis.

Untuk informasi selengkapnya, lihat Layanan olahpesan untuk beban kerja misi penting.

Untuk pertimbangan lain tentang olahpesan, lihat Panduan penting Misson dalam Kerangka Kerja yang dirancang dengan baik: Olahpesan asinkron.

Akun penyimpanan

Dalam arsitektur ini, dua akun penyimpanan disediakan. Kedua akun disebarkan dalam mode zona-redundan (ZRS).

Satu akun digunakan untuk titik pemeriksaan Azure Event Hubs. Jika akun ini tidak responsif, stempel tidak akan dapat memproses pesan dari Azure Event Hubs dan bahkan mungkin berdampak pada layanan lain di stempel. Kondisi ini secara berkala diperiksa oleh HealthService, yang merupakan salah satu komponen aplikasi yang berjalan di kluster komputasi.

Yang lain digunakan untuk menghosting aplikasi satu halaman UI. Jika penyajian situs web statis memiliki masalah, Front Door akan mendeteksi masalah dan tidak akan mengirim lalu lintas ke akun penyimpanan ini. Selama waktu ini, Front Door dapat menggunakan konten yang di-cache.

Untuk informasi selengkapnya tentang pemulihan, lihat Pemulihan bencana dan failover akun penyimpanan.

Sumber daya regional

Sistem dapat memiliki sumber daya yang disebarkan di wilayah tetapi lebih lama dari sumber daya stempel. Dalam arsitektur ini, data pengamatan untuk sumber daya stempel disimpan di penyimpanan data regional.

Karakteristik	Pertimbangan
Masa pakai	Sumber daya berbagi masa pakai wilayah dan menjalankan sumber daya stempel.
Provinsi	Status yang disimpan di suatu wilayah tidak dapat hidup melebihi masa pakai wilayah tersebut. Jika status perlu dibagikan di seluruh wilayah, pertimbangkan untuk menggunakan penyimpanan data global.
Jangkauan	Sumber daya tidak perlu didistribusikan secara global. Komunikasi langsung dengan wilayah lain harus dihindari dengan biaya apa pun.
Dependensi	Sumber daya dapat memiliki dependensi pada sumber daya global, tetapi tidak pada sumber daya stempel karena stempel dimaksudkan untuk berumur pendek.
Batas skala	Tentukan batas skala sumber daya regional dengan menggabungkan semua stempel dalam wilayah.

Memantau data untuk sumber daya stempel

Menyebarkan sumber daya pemantauan adalah contoh umum untuk sumber daya regional. Dalam arsitektur ini, setiap wilayah memiliki ruang kerja Log Analytics individual yang dikonfigurasi untuk menyimpan semua data log dan metrik yang dikeluarkan dari sumber daya stempel. Karena sumber daya regional sumber daya stempel outlive, data tersedia bahkan ketika stempel dihapus.

Azure Log Analytics dan Azure Application Insights digunakan untuk menyimpan log dan metrik dari platform. Disarankan agar Anda membatasi kuota harian pada penyimpanan terutama pada lingkungan yang digunakan untuk pengujian beban. Selain itu, atur kebijakan penyimpanan untuk menyimpan semua data. Pembatasan ini akan mencegah pengeluaran berlebih yang dikeluarkan dengan menyimpan data yang tidak diperlukan di luar batas.

Demikian pula, Application Insights juga disebarkan sebagai sumber daya regional untuk mengumpulkan semua data pemantauan aplikasi.

Untuk rekomendasi desain tentang pemantauan, lihat Panduan penting Misson dalam Kerangka Kerja yang dirancang dengan baik: Pemodelan kesehatan.

Langkah berikutnya

Sebarkan implementasi referensi untuk mendapatkan pemahaman penuh tentang sumber daya dan konfigurasinya yang digunakan dalam arsitektur ini.

Implementasi: Mission-Critical Online