Strategi arsitektur untuk memantau keandalan beban kerja

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

RE:10 Terus mengukur dan melacak kesehatan sistem menggunakan indikator waktu aktif dan keandalan di seluruh komponen dan alur penting. Pastikan data ini disimpan dan dapat diakses untuk mendukung deteksi, respons, dan analisis pasca-insiden tepat waktu.

Pemantauan keandalan adalah praktik mengukur seberapa baik sistem memenuhi persyaratan bisnisnya dari waktu ke waktu, sehubungan dengan ketahanan dan pemulihan. Sistem pemantauan yang dirancang dengan baik memberikan tampilan real time dan tren perilaku sistem dengan menetapkan visibilitas di seluruh platform, infrastruktur, dan lapisan beban kerja.

Dengan menghubungkan sinyal ini di seluruh komponen dan dari waktu ke waktu, pemantauan memungkinkan analisis insiden dan pemadaman yang cepat dan percaya diri. Buat pendekatan terstruktur sehingga wawasan bermakna, pemberitahuan mendorong tindakan yang tepat, dan umpan pembelajaran kembali ke arsitektur dan operasi.

Strategi utama dalam artikel ini dibangun berdasarkan praktik operasional dasar pengamatan, yang dijelaskan dalam strategi Arsitektur OE:07 untuk merancang sistem pemantauan. Panduan tentang menerapkan praktik pemantauan tersedia dalam Panduan Desain Pemantauan. Sebaiknya tinjau sumber daya tersebut terlebih dahulu.

Definisi

Istilah Definisi
SLA (perjanjian tingkat layanan) Komitmen eksternal yang Anda terima dari vendor, atau yang Anda buat kepada pelanggan Anda. Gagal memenuhi SLA dapat menyebabkan penalti finansial, kerusakan reputasi, atau pengalaman pengguna yang terdegradasi.
SLO (tujuan tingkat layanan) Target performa internal dan keandalan yang digunakan untuk menentukan ambang batas yang memicu pemberitahuan dan mengukur kesehatan sistem terhadap tujuan bisnis.
Model kesehatan Representasi hierarkis kondisi sistem menggunakan status kesehatan yang jelas (sehat, terdegradasi, tidak sehat) dengan sinyal real-time dan kemampuan penelusuran dari sistem keseluruhan ke komponen individual.
Stempel Unit penyebaran dengan batas kapasitas yang ditentukan, seperti pengguna bersamaan maksimum, throughput, atau ambang pemanfaatan sumber daya. Beberapa stempel memungkinkan peluasan skala dan distribusi regional.
FMA (analisis modus kegagalan) Analisis sistematis untuk mengidentifikasi titik potensi kegagalan dalam sistem, digunakan untuk memandu strategi pemantauan dan peningkatan keandalan.
RTO (tujuan waktu pemulihan) Waktu maksimum yang dapat diterima untuk mendeteksi, merespons, dan memulihkan dari kegagalan atau insiden.
RPO (tujuan titik pemulihan) Jumlah maksimum kehilangan data yang dapat diterima diukur tepat waktu, menunjukkan berapa banyak data yang dapat hilang selama skenario kegagalan.
Transaksi sintetis Pengujian otomatis yang mensimulasikan tindakan pengguna nyata dan interaksi end-to-end untuk memvalidasi kesehatan sistem dan mendeteksi masalah dari perspektif pelanggan, memberikan validasi eksternal ketersediaan sistem.
ID korelasi Pengidentifikasi unik yang digunakan untuk melacak transaksi dan permintaan di beberapa layanan dan komponen, memungkinkan identifikasi dan analisis masalah dalam sistem terdistribusi.
Kesalahan sementara Kegagalan sementara dalam dependensi sistem yang biasanya teratasi dengan sendirinya dalam waktu singkat, seperti timeout jaringan atau tidak tersedianya layanan sementara.
Tail Latency Waktu respons yang dialami oleh permintaan paling lambat, biasanya diukur pada persentil tinggi (p95, p99) di mana masalah performa sering muncul terlebih dahulu.

Memantau fungsionalitas beban kerja

Pantau apa yang sebenarnya diberikan sistem Anda. Mulailah dengan melacak apakah alur kerja penting berhasil diselesaikan dan menghasilkan hasil yang valid. Sistem dapat tampak sehat saat masih menghasilkan output yang salah atau tidak lengkap, sehingga eksekusi saja tidak cukup.

Misalnya, jika beban kerja menghasilkan laporan setiap enam jam, pemantauan harus mengonfirmasi dua hal: bahwa pekerjaan berjalan seperti yang dijadwalkan, dan menghasilkan hasil yang valid, seperti laporan yang tidak kosong dengan konten dan ukuran yang diharapkan. Validasi semacam ini membantu memastikan sistem tidak hanya dijalankan, tetapi juga memberikan fungsionalitas yang dirancang untuknya.

Memantau pengalaman pengguna

Pantau keandalan dari perspektif bisnis dan pengguna. Sebagai bagian dari analisis mode kegagalan (FMA), Anda seharusnya sudah mengidentifikasi alur pengguna utama. Untuk setiap alur, lacak bagaimana kegagalan dalam komponen atau dependensi apa pun memengaruhi pengalaman pengguna dan apa hasil yang diharapkan. Misalnya, dalam alur checkout e-niaga, pemadaman layanan atau kelebihan beban dalam sistem pembayaran atau inventarisasi dapat mencegah pelanggan menyelesaikan pembelian.

Keandalan juga mencerminkan kualitas layanan. Dalam alur checkout, pengguna harus dapat menyelesaikan pembelian secara end-to-end tanpa gangguan. Gunakan metrik latensi berbasis persentil seperti p50, p95, dan p99 untuk memahami pengalaman pengguna nyata, dengan perhatian khusus pada latensi ekor di mana masalah performa sering muncul terlebih dahulu.

Masukkan sinyal yang menghadap pengguna ke dalam model kesehatan Anda sehingga kualitas layanan yang terdegradasi memicu perubahan status kesehatan. Modelkan alur pengguna yang kritis agar degradasi komponen merambat ke atas, sehingga menghubungkan dampaknya pada pengguna dengan visibilitas sistem. Gunakan model kesehatan Azure Monitor untuk menilai keandalan beban kerja Azure Anda.

Important

Pemantauan performa memberikan tampilan tentang bagaimana sistem Anda bereaksi di bawah beban nyata dengan memecah latensi end-to-end di seluruh lapisan sistem. Ini menghubungkan perubahan performa sehingga Anda dapat memahami apa yang memengaruhi pergeseran perilaku. Itu bisa disebabkan oleh penyebaran, pembaruan konfigurasi, dan peristiwa penskalakan. Bersama-sama, keandalan dan pemantauan performa memberikan gambaran lengkap tentang perilaku sistem dan sorotan di mana perhatian yang terfokus akan berdampak paling besar. Untuk informasi tentang pemantauan performa, lihat Memantau Performa.

Melacak target ketersediaan

Lacak seberapa baik sistem Anda memenuhi target yang ditentukan untuk ketersediaan, throughput, dan waktu respons. Target ini sering diformalkan sebagai perjanjian tingkat layanan (SLA) dan tujuan tingkat layanan (SLA) dan mencerminkan harapan yang telah Anda tetapkan dengan pengguna Anda. Pemantauan terhadap mereka menjaga keandalan selaras dengan hasil bisnis nyata. Untuk informasi selengkapnya, lihat Target keandalan dan Perjanjian Tingkat Layanan.

Fokus pada indikator utama yang berkontribusi pada target tersebut dan lacak dari waktu ke waktu. Ketika sesuatu melayang, Anda harus dapat menelusuri paling detail komponen atau subsistem tertentu yang terlibat. Tangkap semua sinyal yang relevan, termasuk masalah yang ditutupi oleh redundansi atau failover, sehingga Anda dapat memahami apa yang sebenarnya terjadi dan mencegah kejadian berulang.

Gabungkan kesadaran real-time dengan konteks historis. Sinyal real time membantu Anda merespons dengan cepat ketika target berisiko, sementara tren dari waktu ke waktu mengungkapkan pola dan masalah berulang. Mengklasifikasikan penyebab target meleset dan menggabungkan metrik ini juga mendukung pelaporan SLA yang jelas dan membantu memandu peningkatan yang sedang berlangsung.

Pantau SLA utama yang disediakan oleh pemasok dan layanan platform Anda (dari Microsoft dan lainnya). Anda harus:

  • Gunakan model kesehatan untuk mencerminkan pencapaian SLO, memungkinkan pengukuran kesehatan beban kerja secara keseluruhan di semua atribut kualitas, bukan hanya ketersediaan/waktu aktif
  • Melacak indikator potensi pelanggaran SLA secara real time
  • Tangkap dan pertahankan bukti yang diperlukan untuk mendukung klaim SLA jika terjadi pelanggaran

Melacak target pemulihan

Lacak pemulihan dengan memperlakukan setiap pengujian dan insiden nyata sebagai peristiwa yang terukur. Gunakan data pemantauan untuk memvalidasi bahwa sistem dan tim Anda dapat memenuhi tujuan pemulihan yang ditentukan dalam kondisi nyata.

Mengukur sinyal utama seperti waktu untuk mendeteksi, merespons, dan memulihkan (RTO), bersama dengan paparan kehilangan data (RPO). Sertakan indikator seperti kesiapan dan kapasitas failover, tingkat keberhasilan failover dan waktu eksekusi, keberhasilan pencadangan dan pemulihan, jeda replikasi, dan berapa banyak intervensi manual yang diperlukan.

Metrik ini juga menyoroti kesenjangan operasional, seperti prosedur yang tidak jelas, penundaan keputusan, atau dokumentasi yang sulit diakses, yang dapat memengaruhi performa pemulihan. Gunakan wawasan ini untuk memperkuat desain sistem dan praktik respons insiden.

Note

Berhati-hatilah bahwa kebijakan pembersihan atau retensi tidak begitu agresif sehingga mereka menghapus log atau telemetri hanya ketika Anda paling membutuhkannya. Untuk setiap skenario, tanyakan: Data apa yang perlu kita pahami apa yang terjadi sebelum dan selama insiden? Pendekatan yang berguna adalah berpikir ke depan untuk berbagai jenis investigasi pasca-insiden, seperti:

  • Gangguan pada platform atau infrastruktur
  • Masalah ketersediaan aplikasi (misalnya, setelah penyebaran atau perubahan konfigurasi)
  • Bug aplikasi menyebabkan kehilangan atau kerusakan data
  • Insiden keamanan

Menjadikan pemberitahuan dapat ditindaklanjuti dengan model kesehatan

Merancang pemberitahuan sehingga mereka dengan jelas menunjuk ke sesuatu yang layak ditindaklanjuti, dan membumikannya dalam model kesehatan yang mewakili sistem menggunakan status sederhana seperti sehat, terdegradasi, dan tidak sehat.

Menyusun model kesehatan secara hierarkis, dari komponen individual hingga sistem penuh, sehingga Anda dapat dengan cepat melacak masalah ke sumbernya. Tentukan ambang batas menggunakan tujuan tingkat layanan (SLO), dan gabungkan sinyal seperti metrik, log, jejak, dan pemeriksaan sintetis untuk menciptakan gambaran yang andal tentang kesehatan sistem. Ini memberi operator tampilan yang jelas tentang apa yang berfungsi, apa yang tidak, dan di mana harus bertindak tanpa menggali melalui data mentah. Untuk informasi selengkapnya, lihat panduan desain tentang Pemodelan kesehatan.

Sesuaikan pemberitahuan untuk kondisi nyata dengan berfokus pada pengalaman end-to-end dan transaksi penting, sehingga mencerminkan dampak pengguna yang sebenarnya. Kurangi kebisingan dengan memperhitungkan fluktuasi sementara dan memicu perubahan status kesehatan yang bermakna daripada lonjakan atau puncak yang terisolasi. Gabungkan pemberitahuan real-time dengan wawasan tren untuk menangkap masalah langsung dan penurunan bertahap, membantu tim merespons dengan cepat dan tetap fokus.

Risiko: Pemodelan kesehatan memerlukan pengumpulan sinyal yang bermakna di seluruh sistem. Hanya mengandalkan metrik sederhana seperti CPU atau memori dapat melewatkan apa yang sebenarnya penting. Sertakan data pengalaman pengguna dan pemeriksaan sintetis untuk mendapatkan tampilan lengkap. Menentukan "sehat" menuntut adanya kesepahaman, dan ambang batas yang tidak disetel dengan baik dapat menciptakan kebisingan dan mengurangi efektivitas.

Memantau semua lapisan sistem

Pantau setiap lapisan sistem, aplikasi, data/penyimpanan, dan jaringan, untuk mempertahankan tampilan lengkap sinyal keandalan.

Gunakan model kesehatan untuk menyatukan sinyal di seluruh lapisan sistem, yang mewakili sumber daya Azure dan komponen aplikasi dalam alur pengguna dan sistem.

Pada lapisan aplikasi, lacak keberhasilan, kegagalan, dan latensi menggunakan log, metrik, dan probes kesehatan. Gunakan ID korelasi untuk mengikuti permintaan di seluruh layanan dan mempermudah pemecahan masalah. Kumpulkan log secara asinkron sehingga tidak memengaruhi performa permintaan, dan menjaga log diagnostik dan audit tetap terpisah untuk kejelasan. Tambahkan transaksi sintetis dan pengujian titik akhir untuk mengonfirmasi apa yang sebenarnya dialami pelanggan.

Tradeoff. Memilih antara pengelogan asinkron dan sinkron melibatkan keseimbangan antara performa dan keandalan telemetri.

  • Pencatatan asinkron menjaga pencatatan tetap berada di luar jalur kritis, mengurangi latensi dan meningkatkan performa sistem. Namun, ini menimbulkan risiko kehilangan telemetri, terutama jika kegagalan terjadi sebelum log dibersihkan atau dipertahankan.

  • Pengelogan sinkron memastikan bahwa log ditulis sebelum pemrosesan berlanjut, yang meningkatkan durabilitas dan auditabilitas data. Kompromi ini adalah peningkatan latensi dan keterhubungan yang lebih erat antara performa aplikasi dan sistem pengelogan.

Dalam sebagian besar skenario, pengelogan asinkron adalah pendekatan yang disukai karena dampak minimalnya pada performa. Namun, di lingkungan yang sangat diatur atau sensitif audit, pengelogan sinkron mungkin diperlukan untuk menjamin bahwa peristiwa penting ditangkap dengan andal..

Pada lapisan data dan penyimpanan, fokus pada ketersediaan, tingkat keberhasilan tulis, latensi kueri, batas waktu, kunci, dan tekanan sumber daya. Lihatlah tren dari waktu ke waktu untuk mengidentifikasi hambatan yang berkembang dan membedakan masalah berumur pendek dari degradasi berkelanjutan.

Pada lapisan jaringan, pantau konektivitas, latensi, kehilangan paket, bandwidth, dan pola lalu lintas. Gabungkan log aliran, pemeriksaan endpoint, dan pengujian sintetis untuk mengidentifikasi masalah perutean, anomali, atau perilaku terkait keamanan. Sambungkan sinyal ini kembali ke data aplikasi dan platform untuk memahami dari mana masalah berasal.

Log operasional membantu mendiagnosis masalah, melacak performa, dan memahami perilaku sistem. Mereka tidak dirancang untuk berfungsi sebagai sumber kebenaran untuk peristiwa bisnis, audit, atau pelaporan peraturan, yang biasanya memerlukan keterlacakan yang lebih kuat.

Apa yang harus dipantau secara rinci untuk setiap lapisan tercakup dalam Panduan Desain Pemantauan.

Memantau dasbor administratif dan API status

Perluas pemantauan ke dasbor, API status, dan laporan yang diandalkan operator serta alat bantu downstream untuk mengetahui status sistem. Anggap nilai yang salah atau kedaluwarsa sebagai masalah keandalan, yang memerlukan tingkat ketelitian yang sama agar sistem dapat dioperasikan dengan benar.

Misalnya, dalam aplikasi manajemen pesanan, dasbor admin mungkin menampilkan jumlah pesanan yang tertunda dari tabel ringkasan yang disegarkan oleh pekerjaan latar belakang. Jika penyegaran gagal tanpa pemberitahuan, pesanan masih terus mengalir, tetapi staf operasional menangani backlog yang sudah usang. Perbandingan pada interval tetap antara jumlah pada dasbor dan kueri langsung pada tabel pesanan mendeteksi selisih sebelum berubah menjadi dampak bagi pelanggan.

Menentukan dan memantau kapasitas stempel

Tentukan batas kapasitas yang jelas untuk setiap unit penyebaran, atau stempel, dan pantau dengan cermat. Setiap stempel beroperasi dalam langit-langit terbatas, baik itu ambang batas pengguna, throughput, atau pemanfaatan sumber daya bersamaan maksimum. Jadi membuat batas tersebut eksplisit akan memberi Anda garis besar yang dapat diandalkan untuk pengambilan keputusan.

Visibilitas ini membantu Anda mengidentifikasi kapan stempel mendekati saturasi, sebelum memengaruhi keandalan. Ini juga mendukung keputusan peluasan skala tepat waktu, seperti menambahkan stempel baru atau mendistribusikan ulang beban, dan mengonfirmasi bahwa lalu lintas mengalir sesuai dengan desain Anda.

Menentukan batas ini tidak selalu mudah. Kapasitas bisa sulit diukur, terutama ketika tergantung pada beberapa layanan yang mendasar dengan karakteristik penskalakan yang berbeda. Anda harus menggunakan panduan platform, seperti kuota dan batasan dari Microsoft Azure, sebagai titik awal. Dalam praktiknya, kapasitas sering ditentukan melalui pengujian beban, pengamatan, dan penyetelan iteratif daripada pemodelan di muka yang tepat.

Memantau distribusi beban di seluruh instans redundan

Saat Anda menjalankan beban kerja di beberapa instans redundan, termasuk saat Anda mendistribusikan instans di berbagai wilayah atau zona, lalu lintas dan penggunaan sumber daya harus tetap seimbang di seluruh instans tersebut.

Anda ingin melihat ketidakseimbangan yang sering mengindikasikan masalah perutean, masalah konfigurasi, atau kendala dependensi. Ini juga memastikan bahwa sasaran failover memiliki kapasitas yang cukup untuk menyerap lalu lintas ketika diperlukan dan mengonfirmasi bahwa mekanisme redundansi berperilaku seperti yang diharapkan dalam kondisi operasi normal maupun saat terjadi kegagalan.

Mendeteksi mode kegagalan

Sebagai bagian dari latihan analisis mode kegagalan (FMA), Anda seharusnya mengidentifikasi titik potensi kegagalan.

Dalam praktik pemantauan keandalan, terus perhatikan titik-titik tersebut. Mulailah dengan berfokus pada sinyal yang lebih sederhana seperti kesalahan sementara. Pantau perilaku coba lagi dan tingkat kesalahan sementara untuk memahami bagaimana dependensi dan layanan yang mendasar Anda berperilaku dalam kondisi operasi nyata. Sinyal ini memberikan pandangan awal tentang ketidakstabilan yang muncul. Ini membantu Anda mengenali ketika pola coba ulang menyimpang dari norma yang diharapkan, mempertahankan pemahaman apakah sistem tetap berfungsi dengan baik di bawah beban, dan mengidentifikasi kapan dependensi atau layanan eksternal mulai menurun sebelum mempengaruhi pengalaman pengguna.

Juga termasuk kegagalan dampak yang lebih besar seperti pemadaman zona ketersediaan yang berdampak pada subset infrastruktur, pemadaman layanan, atau pemadaman regional yang membuat seluruh wilayah Azure offline. Bahkan perhatikan skenario keamanan seperti DDoS atau aktivitas berbahaya lainnya, kesalahan konfigurasi komponen, dan masalah performa, karena masing-masing dapat memengaruhi keandalan solusi Anda secara keseluruhan.

Untuk informasi tentang FMA, lihat Strategi arsitektur untuk analisis mode kegagalan.

Mendapatkan informasi tentang status keandalan platform

Anda memerlukan wawasan yang jelas tentang kesehatan platform untuk mengelola keandalan secara efektif. Kesadaran itu membantu Anda dengan cepat menentukan apakah masalah berasal dari beban kerja Anda atau di platform cloud yang mendasar.

Azure Service Health memberikan visibilitas ke dalam status Azure. Konfigurasikan pemberitahuan tentang Service Health sehingga Anda mendapatkan pemberitahuan saat kondisi platform berubah. Anda menerima pembaruan tentang pemadaman aktif yang memengaruhi sumber daya Anda, peristiwa pemeliharaan terencana yang dapat menimbulkan gangguan, dan degradasi regional atau khusus layanan.

Pemfasilitasan Azure

  • Masukkan layanan pemantauan dan pemberitahuan platform cloud, termasuk:

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

  • Model kesehatan Azure Monitor membantu Anda menentukan, mengukur, dan memvisualisasikan kesehatan beban kerja dengan mengkorelasikan metrik, log, dan jejak menjadi status kesehatan yang dapat ditindaklanjuti di seluruh sumber daya dan komponen Azure.

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

  • Application Insights adalah ekstensi dari Azure Monitor. Ini menyediakan fitur pemantauan performa aplikasi (APM).

  • Wawasan Azure Monitor adalah alat analitik tingkat lanjut yang membantu memantau layanan Azure, seperti komputer virtual, layanan aplikasi, dan kontainer. Wawasan dibangun di atas Azure Monitor dan Log Analytics.

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

  • Pemantau koneksi adalah alat untuk terus melacak konektivitas dan performa jaringan di seluruh sumber daya Azure. Ini menjalankan tes sintetis dan menyediakan pemberitahuan dan diagnostik real time untuk mendeteksi kegagalan lebih awal. Anda dapat membuat buku kerja kustom untuk memvisualisasikan kesehatan konektivitas dan metrik performa agregat.

  • Log aliran jaringan virtual dapat diaktifkan di seluruh beban kerja untuk memantau lalu lintas jaringan. Analitik lalu lintas dapat digunakan untuk menganalisis dan memperkaya log alur ini ke wawasan permukaan seperti lalu lintas yang diblokir, arus berbahaya, dan port aktif yang terekspos ke internet. Membuat buku kerja memungkinkan tim memantau perilaku lalu lintas langsung dan menerima pemberitahuan. Gunakan tampilan garis waktu dan visualisasi topologi untuk memantau pola lalu lintas dengan mudah yang mungkin menunjukkan penurunan performa atau ancaman keamanan.

  • Untuk praktik terbaik dalam berbagai ruang kerja, lihat Mendesain arsitektur ruang kerja Analitik Log.

Example

Untuk contoh solusi pemantauan dunia nyata, lihat Pemantauan aplikasi web pada Azure dan Arsitektur baseline untuk kluster Azure Kubernetes Service.

  • 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 keandalan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keandalan

  • Last updated on