Bagikan melalui

Pemodelan kesehatan dan pengamatan beban kerja misi penting di Azure

  • Artikel

Pemodelan dan pengamatan kesehatan adalah konsep penting untuk memaksimalkan keandalan, yang berfokus pada instrumentasi dan pemantauan yang kuat dan kontekstual. Konsep-konsep ini memberikan wawasan penting tentang kesehatan aplikasi, mempromosikan identifikasi cepat dan penyelesaian masalah.

Sebagian besar aplikasi misi-kritis signifikan dalam hal skala dan kompleksitas dan oleh karena itu menghasilkan volume data operasional yang tinggi, yang membuatnya sulit untuk mengevaluasi dan menentukan tindakan operasional yang optimal. Pemodelan kesehatan pada akhirnya berusaha untuk memaksimalkan pengamatan dengan menambah log dan metrik pemantauan mentah dengan persyaratan bisnis utama untuk mengukur kesehatan aplikasi, mendorong evaluasi otomatis status kesehatan untuk mencapai operasi yang konsisten dan dipercepat.

Area desain ini berfokus pada proses untuk menentukan model kesehatan yang kuat, memetakan status kesehatan aplikasi yang terukur melalui observabilitas dan konstruksi operasional untuk mencapai kematangan operasional.

Penting

Artikel ini adalah bagian dari seri beban kerja misi penting Azure Well-Architected . Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan apa itu beban kerja misi penting?

Ada tiga tingkat kematangan operasional utama saat berusaha memaksimalkan keandalan.

  1. Deteksi dan tanggapi masalah saat terjadi.
  2. Mendiagnosis masalah yang terjadi atau telah terjadi.
  3. Memprediksi dan mencegah masalah sebelum terjadi.

Video: Menentukan model kesehatan untuk beban kerja misi penting Anda

Kesehatan aplikasi berlapis

Untuk membangun model kesehatan, pertama-tama tentukan kesehatan aplikasi dalam konteks persyaratan bisnis utama dengan mengukur status 'sehat' dan 'tidak sehat' dalam format berlapis dan terukur. Kemudian, untuk setiap komponen aplikasi, persingkat definisi dalam konteks status berjalan yang stabil dan diagregasi sesuai dengan alur pengguna aplikasi. Superimpose dengan persyaratan bisnis non-fungsional utama untuk performa dan ketersediaan. Terakhir, agregat status kesehatan untuk setiap alur pengguna individu untuk membentuk representasi yang dapat diterima dari kesehatan aplikasi secara keseluruhan. Setelah ditetapkan, definisi kesehatan berlapis ini harus digunakan untuk menginformasikan metrik pemantauan penting di semua komponen sistem dan memvalidasi komposisi subsistem operasional.

Penting

Saat mendefinisikan status 'tidak sehat', mewakili untuk semua tingkat aplikasi. Penting untuk membedakan antara status kegagalan sementara dan non-sementara untuk memenuhi syarat degradasi layanan relatif terhadap tidak tersedia.

Mempertimbangkan rancangan

  • Proses kesehatan pemodelan adalah aktivitas desain top-down yang dimulai dengan latihan arsitektur untuk menentukan semua alur pengguna dan memetakan dependensi antara komponen fungsional dan logis, sehingga secara implisit memetakan dependensi antara sumber daya Azure.

  • Model kesehatan sepenuhnya tergantung pada konteks solusi yang diwakilinya, dan oleh karena itu tidak dapat diselesaikan 'out-of-the-box' karena 'satu ukuran tidak cocok untuk semua'.

    • Aplikasi akan berbeda dalam komposisi dan dependensi
    • Metrik dan ambang metrik untuk sumber daya juga harus disetel dengan baik dalam hal nilai apa yang mewakili status sehat dan tidak sehat, yang sangat dipengaruhi oleh fungsionalitas aplikasi yang mencakup dan menargetkan persyaratan non-fungsional.

  • Model kesehatan berlapis memungkinkan kesehatan aplikasi ditelusuri kembali ke dependensi tingkat yang lebih rendah, yang membantu dengan cepat mengakar penyebab degradasi layanan.

  • Untuk menangkap status kesehatan untuk komponen individu, karakteristik operasional komponen yang berbeda harus dipahami dalam keadaan stabil yang mencerminkan beban produksi. Oleh karena itu, pengujian performa adalah kemampuan utama untuk menentukan dan terus mengevaluasi kesehatan aplikasi.

  • Kegagalan dalam solusi cloud mungkin tidak terjadi dalam isolasi. Pemadaman dalam satu komponen dapat menyebabkan beberapa kemampuan atau komponen tambahan menjadi tidak tersedia.

    • Kesalahan tersebut mungkin tidak segera diamati.

Rekomendasi desain

  • Tentukan model kesehatan yang terukur sebagai prioritas untuk memastikan pemahaman operasional yang jelas tentang seluruh aplikasi.

    • Model kesehatan harus berlapis dan mencerminkan struktur aplikasi.
    • Lapisan dasar harus mempertimbangkan komponen aplikasi individual, seperti sumber daya Azure.
    • Komponen dasar harus diagregasi bersama persyaratan utama yang tidak berfungsi untuk membangun lensa kontekstual bisnis ke dalam kesehatan alur sistem.
    • Alur sistem harus diagregasi dengan bobot yang sesuai berdasarkan kekritisan bisnis untuk membangun definisi yang bermakna dari kesehatan aplikasi secara keseluruhan. Alur pengguna yang signifikan atau berhadapan dengan pelanggan secara finansial harus diprioritaskan.
    • Setiap lapisan model kesehatan harus menangkap status 'sehat' dan 'tidak sehat'.
    • Pastikan model heath dapat membedakan antara status sementara dan non-sementara yang tidak sehat untuk mengisolasi degradasi layanan dari tidak tersedia.

  • Mewakili status kesehatan menggunakan skor kesehatan terperinci untuk setiap komponen aplikasi yang berbeda dan setiap alur pengguna dengan menggabungkan skor kesehatan untuk komponen dependen yang dipetakan, mengingat persyaratan utama yang tidak berfungsi sebagai koefisien.

    • Skor kesehatan untuk alur pengguna harus diwakili oleh skor terendah di semua komponen yang dipetakan, memperhitungkan pencapaian relatif terhadap persyaratan yang tidak berfungsi untuk alur pengguna.
    • Model yang digunakan untuk menghitung skor kesehatan harus secara konsisten mencerminkan kesehatan operasi, dan jika tidak, model harus disesuaikan dan disebarkan ulang untuk mencerminkan pembelajaran baru.
    • Tentukan ambang batas skor kesehatan untuk mencerminkan status kesehatan.

  • Skor kesehatan harus dihitung secara otomatis berdasarkan metrik yang mendasar, yang dapat divisualisasikan melalui pola pengamatan dan ditindaklanjuti melalui prosedur operasional otomatis.

    • Skor kesehatan harus menjadi inti dari solusi pemantauan, sehingga tim operasi tidak lagi harus menafsirkan dan memetakan data operasional ke kesehatan aplikasi.

  • Gunakan model kesehatan untuk menghitung pencapaian Tujuan Tingkat Layanan (SLO) ketersediaan alih-alih ketersediaan mentah, memastikan demarkasi antara degradasi layanan dan tidak tersedia tercermin sebagai SLA terpisah.

  • Gunakan model kesehatan dalam alur CI/CD dan siklus pengujian untuk memvalidasi kesehatan aplikasi dipertahankan setelah pembaruan kode dan konfigurasi.

    • Model kesehatan harus digunakan untuk mengamati dan memvalidasi kesehatan selama pengujian beban dan pengujian chaos sebagai bagian dari proses CI/CD.

  • Membangun dan memelihara model kesehatan adalah proses berulang dan investasi teknik harus selaras untuk mendorong peningkatan berkelanjutan.

    • Tentukan proses untuk terus mengevaluasi dan menyempurnakan akurasi model, dan pertimbangkan untuk berinvestasi dalam model pembelajaran mesin untuk melatih model lebih lanjut.

Contoh - Model kesehatan berlapis

Ini adalah representasi yang disederhanakan dari model kesehatan aplikasi berlapis untuk tujuan ilustrasi. Model kesehatan yang komprehensif dan kontekstual disediakan dalam implementasi referensi Mission-Critical:

Saat menerapkan model kesehatan, penting untuk menentukan kesehatan komponen individual melalui agregasi dan interpretasi metrik tingkat sumber daya utama. Contoh bagaimana metrik sumber daya dapat digunakan adalah gambar di bawah ini:

Contoh definisi kesehatan misi-kritis

Definisi kesehatan ini kemudian dapat diwakili oleh kueri KQL, seperti yang ditunjukkan oleh kueri contoh di bawah ini yang mengagregasi InsightsMetrics (Wawasan kontainer) dan AzureMetrics (pengaturan diagnostik untuk kluster AKS) dan membandingkan (gabungan dalam) terhadap ambang batas kesehatan yang dimodelkan.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

Output tabel yang dihasilkan kemudian dapat diubah menjadi skor kesehatan untuk agregasi yang lebih mudah pada tingkat model kesehatan yang lebih tinggi.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Skor agregat ini kemudian dapat direpresentasikan sebagai bagan dependensi menggunakan alat visualisasi seperti Grafana untuk mengilustrasikan model kesehatan.

Gambar ini menunjukkan contoh model kesehatan berlapis dari implementasi referensi online Azure Mission-Critical, dan menunjukkan bagaimana perubahan status kesehatan untuk komponen dasar dapat memiliki dampak berjenjang ke alur pengguna dan kesehatan aplikasi secara keseluruhan (nilai contoh sesuai dengan tabel pada gambar sebelumnya).

Visualisasi Model Kesehatan Contoh Penting Misi Visualisasi Model

Video demo: Demo pemantauan dan pemodelan kesehatan

Sink data terpadu untuk analisis berkorelasi

Banyak himpunan data operasional harus dikumpulkan dari semua komponen sistem untuk mewakili model heath yang ditentukan secara akurat, mengingat log dan metrik dari komponen aplikasi dan sumber daya Azure yang mendasar. Data dalam jumlah besar ini pada akhirnya perlu disimpan dalam format yang memungkinkan interpretasi hampir real time untuk memfasilitasi tindakan operasional yang cepat. Selain itu, korelasi di semua himpunan data yang dicakup diperlukan untuk memastikan analisis yang efektif tidak terbatas, memungkinkan representasi kesehatan berlapis.

Sink data terpadu diperlukan untuk memastikan semua data operasional disimpan dengan cepat dan tersedia untuk analisis berkorelasi untuk membangun representasi 'panel tunggal' dari kesehatan aplikasi. Azure menyediakan beberapa teknologi operasional yang berbeda di bawah payung Azure Monitor, dan ruang kerja Analitik Log berfungsi sebagai sink data asli Azure inti untuk menyimpan dan menganalisis data operasional.

Pengumpulan Data Misi Penting Kesehatan Misi

Mempertimbangkan rancangan

Azure Monitor

  • Azure Monitor diaktifkan secara default untuk semua langganan Azure, tetapi Log Azure Monitor (ruang kerja Analitik Log) dan sumber daya Application Insights harus disebarkan dan dikonfigurasi untuk menggabungkan kemampuan pengumpulan dan kueri data.

  • Azure Monitor mendukung tiga jenis data pengamatan: log, metrik, dan jejak terdistribusi.

    • Log disimpan di ruang kerja Analitik Log, yang didasarkan pada Data Explorer Azure. Kueri log disimpan dalam paket kueri yang dapat dibagikan di seluruh langganan, dan digunakan untuk mendorong komponen pengamatan seperti dasbor, buku kerja, atau alat pelaporan dan visualisasi lainnya.
    • Metrik disimpan dalam database rangkaian waktu internal. Untuk sebagian besar sumber daya Azure, metrik dikumpulkan dan dipertahankan secara otomatis selama 93 hari. Data metrik juga dapat dikirim ke ruang kerja Analitik Log menggunakan pengaturan diagnostik untuk sumber daya.

  • Semua sumber daya Azure mengekspos log dan metrik, tetapi sumber daya harus dikonfigurasi dengan tepat untuk merutekan data diagnostik ke sink data yang Anda inginkan.

Tip

Azure menyediakan berbagai Kebijakan Bawaan yang dapat diterapkan untuk memastikan sumber daya yang disebarkan dikonfigurasi untuk mengirim log dan metrik ke ruang kerja Analitik Log.

  • Tidak jarang kontrol peraturan mengharuskan data operasional tetap berada dalam geografi asal atau negara/wilayah. Persyaratan peraturan dapat menetapkan retensi jenis data penting untuk jangka waktu yang lama. Misalnya, dalam perbankan yang diatur, data audit harus disimpan setidaknya selama tujuh tahun.

  • Jenis data operasional yang berbeda mungkin memerlukan periode retensi yang berbeda. Misalnya, log keamanan mungkin perlu dipertahankan untuk jangka panjang, sementara data performa tidak mungkin memerlukan retensi jangka panjang di luar konteks AIOps.

  • Data dapat diarsipkan atau diekspor dari ruang kerja Log Analytics untuk tujuan retensi dan/atau audit jangka panjang.

  • Kluster Khusus menyediakan opsi penyebaran yang memungkinkan Zona Ketersediaan untuk perlindungan dari kegagalan zona di wilayah Azure yang didukung. Kluster Khusus memerlukan komitmen penyerapan data harian minimum.

  • Ruang kerja Analitik Log disebarkan ke wilayah Azure tertentu.

  • Untuk melindungi dari hilangnya data dari tidak tersedianya ruang kerja Log Analytics, sumber daya dapat dikonfigurasi dengan beberapa pengaturan diagnostik. Setiap pengaturan diagnostik dapat mengirim metrik dan log ke ruang kerja Analitik Log terpisah.

    • Data yang dikirim ke setiap ruang kerja Analitik Log tambahan akan dikenakan biaya tambahan.
    • Ruang kerja Analitik Log yang berlebihan dapat disebarkan ke wilayah Azure yang sama, atau ke wilayah Azure terpisah untuk redundansi regional tambahan.
    • Mengirim log dan metrik dari sumber daya Azure ke ruang kerja Analitik Log di wilayah yang berbeda akan dikenakan biaya keluar data antar-wilayah.
    • Beberapa sumber daya Azure memerlukan ruang kerja Analitik Log dalam wilayah yang sama dengan sumber daya itu sendiri.
    • Lihat Praktik terbaik untuk Log Azure Monitor untuk opsi ketersediaan lebih lanjut untuk ruang kerja Analitik Log.

  • Data ruang kerja Log Analytics dapat diekspor ke Azure Storage atau Azure Event Hubs secara berkelanjutan, terjadwal, atau satu kali.

    • Ekspor data memungkinkan pengarsipan data jangka panjang dan melindungi dari kemungkinan kehilangan data operasional karena tidak tersedia.
    • Tujuan ekspor yang tersedia adalah Azure Storage atau Azure Event Hubs. Azure Storage dapat dikonfigurasi untuk tingkat redundansi yang berbeda termasuk zonal atau regional. Ekspor data ke Azure Storage menyimpan data dalam file .json.
    • Tujuan ekspor data harus berada dalam wilayah Azure yang sama dengan ruang kerja Analitik Log. Tujuan ekspor data pusat aktivitas berada dalam wilayah yang sama dengan ruang kerja Analitik Log. Azure Event Hubs pemulihan bencana geografis tidak berlaku untuk skenario ini.
    • Ada beberapa batasan ekspor data. Hanya tabel tertentu di ruang kerja yang didukung untuk ekspor data.
    • Pengarsipan dapat digunakan untuk menyimpan data di ruang kerja Analitik Log untuk retensi jangka panjang dengan biaya yang lebih rendah tanpa mengekspornya.

  • Log Azure Monitor memiliki batas pembatasan kueri pengguna, yang mungkin muncul sebagai pengurangan ketersediaan untuk klien, seperti dasbor pengamatan.

    • Lima kueri bersamaan per pengguna: jika lima kueri sudah berjalan, kueri tambahan ditempatkan dalam antrean konkurensi per pengguna hingga kueri yang sedang berjalan berakhir.
    • Waktu dalam antrean konkurensi: jika kueri berada dalam antrean konkurensi selama lebih dari tiga menit, kueri akan dihentikan dan kode kesalahan 429 dikembalikan.
    • Batas kedalaman antrean konkurensi: antrean konkurensi dibatasi hingga 200 kueri, dan kueri tambahan akan ditolak dengan kode kesalahan 429.
    • Batas laju kueri: ada batas per pengguna 200 kueri per 30 detik di semua ruang kerja.

  • Paket kueri adalah sumber daya Azure Resource Manager, yang dapat digunakan untuk melindungi dan memulihkan kueri log jika ruang kerja Log Analytics tidak tersedia.

    • Paket kueri berisi kueri sebagai JSON dan dapat disimpan di luar Azure yang mirip dengan aset infrastruktur sebagai kode lainnya.
      • Dapat disebarkan melalui MICROSOFT.Insights REST API.
      • Jika ruang kerja Analitik Log harus dibuat ulang, paket kueri dapat disebarkan ulang dari definisi yang disimpan secara eksternal.

  • Application Insights dapat disebarkan dalam model penyebaran berbasis ruang kerja, yang didukung oleh ruang kerja Analitik Log tempat semua data disimpan.

  • Pengambilan sampel dapat diaktifkan dalam Application Insights untuk mengurangi jumlah telemetri yang dikirim dan mengoptimalkan biaya penyerapan data.

  • Semua data yang dikumpulkan oleh Azure Monitor, termasuk Application Insights, dibebankan berdasarkan volume data yang diserap dan durasi data disimpan.

    • Data yang diserap ke dalam ruang kerja Analitik Log dapat dipertahankan tanpa biaya tambahan hingga 31 hari pertama (90 hari jika Sentinel diaktifkan)
    • Data yang diserap ke dalam Application Insights berbasis ruang kerja disimpan selama 90 hari pertama tanpa biaya tambahan.

  • Model harga tingkat komitmen Analitik Log memberikan pengurangan biaya dan pendekatan yang dapat diprediksi untuk biaya penyerapan data.

    • Setiap penggunaan di atas tingkat reservasi ditagih dengan harga yang sama dengan tingkat saat ini.

  • Log Analytics, Application Insights, dan Azure Data Explorer menggunakan Bahasa Kueri Kusto (KQL).

  • Kueri Analitik Log disimpan sebagai fungsi dalam ruang kerja Analitik Log (savedSearches).

Rekomendasi desain

  • Gunakan ruang kerja Analitik Log sebagai sink data terpadu untuk menyediakan 'panel tunggal' di semua himpunan data operasional.

    • Desentralisasi ruang kerja Analitik Log di semua wilayah penyebaran yang digunakan. Setiap wilayah Azure dengan penyebaran aplikasi harus mempertimbangkan ruang kerja Analitik Log untuk mengumpulkan semua data operasional yang berasal dari wilayah tersebut. Semua sumber daya global harus menggunakan ruang kerja Analitik Log khusus terpisah, yang harus disebarkan dalam wilayah penyebaran utama.
      • Mengirim semua data operasional ke satu ruang kerja Analitik Log akan membuat satu titik kegagalan.
      • Persyaratan untuk residensi data mungkin melarang data meninggalkan wilayah asal, dan ruang kerja federasi memecahkan persyaratan ini secara default.
      • Ada biaya keluar yang substansial yang terkait dengan mentransfer log dan metrik di seluruh wilayah.
    • Semua stempel penyebaran dalam wilayah yang sama dapat menggunakan ruang kerja Analitik Log regional yang sama.

  • Pertimbangkan untuk mengonfigurasi sumber daya dengan beberapa pengaturan diagnostik yang menunjuk ke ruang kerja Analitik Log yang berbeda untuk melindungi dari ketidaktersediaan Azure Monitor untuk aplikasi dengan stempel penyebaran regional yang lebih sedikit.

  • Gunakan Application Insights sebagai alat Pemantauan Performa Aplikasi (APM) yang konsisten di semua komponen aplikasi untuk mengumpulkan log, metrik, dan jejak aplikasi.

    • Sebarkan Application Insights dalam konfigurasi berbasis ruang kerja untuk memastikan setiap ruang kerja Analitik Log regional berisi log dan metrik dari komponen aplikasi dan sumber daya Azure yang mendasar.

  • Gunakan kueri lintas Ruang Kerja untuk mempertahankan 'panel tunggal' terpadu di berbagai ruang kerja.

  • Gunakan paket kueri untuk melindungi kueri log jika ruang kerja tidak tersedia.

    • Simpan paket kueri dalam repositori git aplikasi sebagai aset infrastruktur sebagai kode.

  • Semua ruang kerja Analitik Log harus diperlakukan sebagai sumber daya yang berjalan lama dengan siklus hidup yang berbeda dengan sumber daya aplikasi dalam stempel penyebaran regional.

  • Ekspor data operasional penting dari ruang kerja Analitik Log untuk retensi dan analitik jangka panjang untuk memfasilitasi AIOps dan analitik tingkat lanjut untuk memperbaiki model kesehatan yang mendasar dan menginformasikan tindakan prediktif.

  • Evaluasi dengan cermat penyimpanan data mana yang harus digunakan untuk retensi jangka panjang; tidak semua data harus disimpan di penyimpanan data panas dan dapat dikueri.

    • Sangat disarankan untuk menggunakan Azure Storage dalam konfigurasi GRS untuk penyimpanan data operasional jangka panjang.
      • Gunakan kemampuan ekspor ruang kerja Analitik Log untuk mengekspor semua sumber data yang tersedia ke Azure Storage.

  • Pilih periode retensi yang sesuai untuk jenis data operasional dalam analitik log, mengonfigurasi periode retensi yang lebih lama dalam ruang kerja tempat persyaratan pengamatan 'panas' ada.

  • Gunakan Azure Policy untuk memastikan semua sumber daya regional merutekan data operasional ke ruang kerja Analitik Log yang benar.

Catatan

Saat menyebarkan ke zona pendaratan Azure, jika ada persyaratan untuk penyimpanan terpusat data operasional, Anda dapat membuat fork data pada instansiasi sehingga diserap ke dalam alat terpusat dan ruang kerja Log Analytics yang didedikasikan untuk aplikasi. Atau, ekspos akses ke ruang kerja Log Analytics aplikasi sehingga tim pusat dapat mengkueri data aplikasi. Pada akhirnya sangat penting bahwa data operasional yang berasal dari solusi tersedia dalam ruang kerja Log Analytics yang didedikasikan untuk aplikasi.

Jika integrasi SIEM diperlukan, jangan mengirim entri log mentah, tetapi sebaliknya mengirim pemberitahuan penting.

  • Hanya konfigurasikan pengambilan sampel dalam Application Insights jika diperlukan untuk mengoptimalkan performa, atau jika tidak, pengambilan sampel menjadi larangan biaya.

    • Pengambilan sampel yang berlebihan dapat menyebabkan sinyal operasional yang terlewat atau tidak akurat.

  • Gunakan ID korelasi untuk semua peristiwa pelacakan dan pesan log untuk mengikatnya dengan permintaan tertentu.

    • Mengembalikan ID korelasi ke pemanggil untuk semua panggilan bukan hanya permintaan yang gagal.

  • Pastikan kode aplikasi menggabungkan instrumentasi dan pengelogan yang tepat untuk menginformasikan model kesehatan dan memfasilitasi pemecahan masalah berikutnya atau analisis akar penyebab bila diperlukan.

    • Kode aplikasi harus menggunakan Application Insights untuk memfasilitasi Pelacakan Terdistribusi, dengan memberikan pesan kesalahan komprehensif kepada pemanggil yang menyertakan ID korelasi saat kegagalan terjadi.

  • Gunakan pengelogan terstruktur untuk semua pesan log.

  • Tambahkan pemeriksaan kesehatan yang bermakna ke semua komponen aplikasi.

    • Saat menggunakan AKS, konfigurasikan titik akhir kesehatan untuk setiap penyebaran (pod) sehingga Kubernetes dapat menentukan dengan benar kapan pod sehat atau tidak sehat.
    • Saat menggunakan Azure App Service, konfigurasikan Pemeriksaan Kesehatan sehingga operasi peluasan skala tidak akan menyebabkan kesalahan dengan mengirim lalu lintas ke instans yang belum siap, dan memastikan instans yang tidak sehat didaur ulang dengan cepat.

Jika aplikasi berlangganan Dukungan microsoft Mission-Critical, pertimbangkan untuk mengekspos pemeriksaan kesehatan utama ke Dukungan Microsoft, sehingga kesehatan aplikasi dapat dimodelkan dengan lebih akurat oleh Dukungan Microsoft.

  • Mencatat permintaan pemeriksaan kesehatan yang berhasil, kecuali peningkatan volume data tidak dapat ditoleransi dalam konteks performa aplikasi, karena mereka memberikan wawasan tambahan untuk pemodelan analitik.

  • Jangan mengonfigurasi ruang kerja Analitik Log produksi untuk menerapkan batas harian, yang membatasi penyerapan data operasional harian, karena ini dapat menyebabkan hilangnya data operasional penting.

    • Di lingkungan yang lebih rendah, seperti Pengembangan dan Pengujian, batas harian dapat dianggap sebagai mekanisme penghematan biaya opsional.

  • Volume penyerapan data operasional yang disediakan memenuhi ambang tingkat minimum, mengonfigurasi ruang kerja Analitik Log untuk menggunakan harga berbasis tingkat komitmen untuk mendorong efisiensi biaya relatif terhadap model harga 'bayar sesuai penggunaan'.

  • Sangat disarankan untuk menyimpan kueri Analitik Log menggunakan kontrol sumber dan menggunakan otomatisasi CI/CD untuk menyebarkannya ke instans ruang kerja Log Analytics yang relevan.

Visualisasi

Secara visual mewakili model kesehatan dengan data operasional penting untuk mencapai operasi yang efektif dan memaksimalkan keandalan. Dasbor pada akhirnya harus digunakan untuk memberikan wawasan hampir real time tentang kesehatan aplikasi untuk tim DevOps, memfasilitasi diagnosis penyimpangan yang cepat dari keadaan stabil.

Microsoft menyediakan beberapa teknologi visualisasi data, termasuk Dasbor Azure, Power BI, dan Azure Managed Grafana (saat ini dalam pratinjau). Dasbor Azure diposisikan untuk menyediakan solusi visualisasi siap pakai yang terintegrasi erat untuk data operasional dalam Azure Monitor. Oleh karena itu, ia memiliki peran mendasar untuk bermain dalam representasi visual data operasional dan kesehatan aplikasi untuk beban kerja misi penting. Namun, ada beberapa batasan dalam hal penempatan Dasbor Azure sebagai platform pengamatan holistik, dan sebagai hasilnya pertimbangan harus diberikan kepada penggunaan tambahan solusi pengamatan terdepan di pasar, seperti Grafana, yang juga disediakan sebagai solusi terkelola dalam Azure.

Bagian ini berfokus pada penggunaan Dasbor Azure dan Grafana untuk membangun pengalaman dasbor yang kuat yang mampu menyediakan lensa teknis dan bisnis ke dalam kesehatan aplikasi, memungkinkan tim DevOps dan operasi yang efektif. Dasbor yang kuat sangat penting untuk mendiagnosis masalah yang telah terjadi, dan mendukung tim operasional dalam mendeteksi dan merespons masalah saat terjadi.

Mempertimbangkan rancangan

  • Saat memvisualisasikan model kesehatan menggunakan kueri log, perhatikan bahwa ada batas Analitik Log pada kueri bersamaan dan antrean, serta tingkat kueri keseluruhan, dengan kueri berikutnya diantrekan dan dibatasi.

  • Kueri untuk mengambil data operasional yang digunakan untuk menghitung dan mewakili skor kesehatan dapat ditulis dan dijalankan di Log Analytics atau Azure Data Explorer.

  • Analitik Log memberlakukan beberapa batas kueri, yang harus dirancang untuk saat merancang dasbor operasional.

  • Visualisasi metrik sumber daya mentah, seperti pemanfaatan CPU atau throughput jaringan, memerlukan evaluasi manual oleh tim operasi untuk menentukan dampak status kesehatan, dan ini bisa menjadi tantangan selama insiden aktif.

  • Jika beberapa pengguna menggunakan dasbor dalam alat seperti Grafana, jumlah kueri yang dikirim ke Log Analytics mengalikan dengan cepat.

    • Mencapai batas kueri bersamaan pada Analitik Log akan mengantre kueri berikutnya, membuat pengalaman dasbor terasa 'lambat'.

Rekomendasi Desain

  • Kumpulkan dan sajikan output yang dikueri dari semua Ruang Kerja Analitik Log regional dan Ruang Kerja Analitik Log global untuk membangun tampilan terpadu kesehatan aplikasi.

Catatan

Jika menyebarkan ke zona pendaratan Azure, pertimbangkan untuk mengkueri ruang kerja Analitik Log platform pusat jika dependensi utama pada sumber daya platform ada, seperti ExpressRoute untuk komunikasi lokal.

  • Model 'lampu lalu lintas' harus digunakan untuk mewakili status 'sehat' dan 'tidak sehat' secara visual, dengan warna hijau yang digunakan untuk menggambarkan kapan persyaratan utama yang tidak berfungsi sepenuhnya terpenuhi dan sumber daya digunakan secara optimal. Gunakan status "Hijau", "Kuning, dan "Merah" untuk mewakili status "Sehat", "Terdegradasi", dan "Tidak Tersedia".

  • Gunakan Dasbor Azure untuk membuat lensa operasional untuk sumber daya global dan stempel penyebaran regional, yang mewakili metrik utama seperti jumlah permintaan untuk Azure Front Door, latensi sisi server untuk Azure Cosmos DB, pesan masuk/keluar untuk Azure Event Hubs, dan status pemanfaatan atau penyebaran CPU untuk AKS. Dasbor harus disesuaikan untuk mendorong efektivitas operasional, memasukkan pembelajaran dari skenario kegagalan untuk memastikan tim DevOps memiliki visibilitas langsung ke dalam metrik utama.

  • Jika Dasbor Azure tidak dapat digunakan untuk mewakili model kesehatan dan persyaratan bisnis yang diperlukan secara akurat, maka sangat disarankan untuk mempertimbangkan Grafana sebagai solusi visualisasi alternatif, menyediakan kemampuan terdepan di pasar dan ekosistem plugin sumber terbuka yang luas. Evaluasi penawaran pratinjau Grafana terkelola untuk menghindari kompleksitas operasional pengelolaan infrastruktur Grafana.

  • Saat menyebarkan Grafana yang dihost sendiri, gunakan desain yang sangat tersedia dan didistribusikan secara geografis untuk memastikan dasbor operasional penting dapat tahan terhadap kegagalan platform regional dan skenario kesalahan berjenjang.

    • Pisahkan status konfigurasi ke dalam datastore eksternal, seperti Azure Database for Postgres atau MySQL, untuk memastikan simpul aplikasi Grafana tetap stateless.

      • Mengonfigurasi replikasi database di seluruh wilayah penyebaran.

    • Sebarkan simpul Grafana ke App Services dalam konfigurasi yang sangat tersedia di seluruh wilayah, menggunakan penyebaran berbasis kontainer.

      • Sebarkan instans App Service di seluruh wilayah penyebaran yang dianggap.

      App Services menyediakan platform kontainer gesekan rendah, yang ideal untuk skenario skala rendah seperti dasbor operasional, dan mengisolasi Grafana dari AKS memberikan pemisahan kekhawatiran yang jelas antara platform aplikasi utama dan representasi operasional untuk platform tersebut. Silakan merujuk ke area deign Platform Aplikasi untuk rekomendasi konfigurasi lebih lanjut.

    • Gunakan Azure Storage dalam konfigurasi GRS untuk menghosting dan mengelola visual dan plugin kustom.

    • Sebarkan layanan aplikasi dan komponen Grafana baca-replika database ke minimal dua wilayah penyebaran, dan pertimbangkan untuk menggunakan model tempat Grafana disebarkan ke semua wilayah penyebaran yang dianggap.

Untuk skenario yang >menargetkan = 99,99% SLO, Grafana harus disebarkan dalam minimal 3 wilayah penyebaran untuk memaksimalkan keandalan keseluruhan untuk dasbor operasional utama.

  • Mitigasi batas kueri Analitik Log dengan menggabungkan kueri ke dalam satu atau sedikit kueri, seperti dengan menggunakan operator KQL 'union', dan menetapkan laju refresh yang sesuai di dasbor.

    • Laju refresh maksimum yang sesuai akan bergantung pada jumlah dan kompleksitas kueri dasbor; analisis kueri yang diimplementasikan diperlukan.

  • Jika batas kueri bersamaan Log Analytics tercapai, pertimbangkan untuk mengoptimalkan pola pengambilan dengan (sementara) menyimpan data yang diperlukan untuk dasbor di datastore berperforma tinggi seperti Azure SQL.

Respons insiden otomatis

Sementara representasi visual kesehatan aplikasi memberikan wawasan operasional dan bisnis yang tak ternilai untuk mendukung deteksi dan diagnosis masalah, itu bergantung pada kesiapan dan interpretasi tim operasional, serta efektivitas respons yang dipicu manusia berikutnya. Oleh karena itu, untuk memaksimalkan keandalan, perlu menerapkan peringatan ekstensif untuk mendeteksi secara proaktif dan menanggapi masalah mendekati real-time.

Azure Monitor menyediakan kerangka kerja pemberitahuan yang luas untuk mendeteksi, mengategorikan, dan merespons sinyal operasional melalui Grup Tindakan. Oleh karena itu, bagian ini akan berfokus pada penggunaan pemberitahuan Azure Monitor untuk mendorong tindakan otomatis sebagai respons terhadap penyimpangan saat ini atau potensi penyimpangan dari status aplikasi yang sehat.

Penting

Pemberitahuan dan tindakan otomatis sangat penting untuk mendeteksi dan merespons masalah secara efektif saat terjadi, sebelum dampak negatif yang lebih besar dapat terjadi. Pemberitahuan juga menyediakan mekanisme untuk menginterpretasikan sinyal masuk dan merespons mencegah masalah sebelum terjadi.

Mempertimbangkan rancangan

  • Aturan pemberitahuan didefinisikan untuk diaktifkan saat kriteria bersyarat terpenuhi untuk sinyal masuk, yang dapat mencakup berbagai sumber data, seperti metrik, kueri log, atau pengujian ketersediaan.

  • Pemberitahuan dapat ditentukan dalam Analitik Log atau Azure Monitor pada sumber daya tertentu.

  • Beberapa metrik hanya dapat diinterogasi dalam Azure Monitor, karena tidak semua titik data diagnostik tersedia dalam Analitik Log.

  • AZURE Monitor Alerts API dapat digunakan untuk mengambil pemberitahuan aktif dan historis.

  • Ada batas langganan yang terkait dengan pemberitahuan dan grup tindakan, yang harus dirancang untuk:

    • Batasan ada untuk jumlah aturan pemberitahuan yang dapat dikonfigurasi.
    • API Pemberitahuan memiliki batas pembatasan, yang harus dipertimbangkan untuk skenario penggunaan ekstrem.
    • Grup Tindakan memiliki beberapa batasan keras untuk jumlah respons yang dapat dikonfigurasi, yang harus dirancang untuk.
      • Setiap jenis respons memiliki batas 10 tindakan, selain email, yang memiliki batas 1.000 tindakan.

  • Pemberitahuan dapat diintegrasikan dalam model kesehatan berlapis dengan membuat Aturan Pemberitahuan untuk kueri pencarian log yang disimpan dari fungsi penilaian 'root' model. Misalnya, menggunakan 'WebsiteHealthScore' dan memberi tahu nilai numerik yang mewakili status 'Tidak Sehat'.

Rekomendasi desain

  • Untuk pemberitahuan yang berfokus pada sumber daya, buat aturan pemberitahuan dalam Azure Monitor untuk memastikan semua data diagnostik tersedia untuk kriteria aturan pemberitahuan.

  • Mengonsolidasikan tindakan otomatis dalam jumlah minimal Grup Tindakan, selaras dengan tim layanan untuk mendukung pendekatan DevOps.

  • Tanggapi sinyal pemanfaatan sumber daya yang berlebihan melalui operasi skala otomatis, menggunakan kemampuan skala otomatis asli Azure jika memungkinkan. Jika fungsionalitas skala otomatis bawaan tidak berlaku, gunakan skor kesehatan komponen untuk memodelkan sinyal dan menentukan kapan harus merespons dengan operasi skala otomatis. Pastikan operasi skala otomatis didefinisikan sesuai dengan model kapasitas, yang mengukur hubungan skala antar komponen, sehingga respons skala mencakup komponen yang perlu diskalakan dalam kaitannya dengan komponen lain.

  • Tindakan model untuk mengakomodasi pemesanan yang diprioritaskan, yang harus ditentukan oleh dampak bisnis.

  • Gunakan AZURE Monitor Alerts API untuk mengumpulkan pemberitahuan historis untuk dimasukkan dalam penyimpanan operasional 'dingin' untuk analitik tingkat lanjut.

  • Untuk skenario kegagalan kritis, yang tidak dapat dipenuhi dengan respons otomatis, pastikan 'otomatisasi runbook' operasional tersedia untuk mendorong tindakan yang cepat dan konsisten setelah interpretasi manual dan keluar disediakan. Gunakan pemberitahuan pemberitahuan untuk mendorong identifikasi cepat masalah yang memerlukan interpretasi manual

  • Buat jatah dalam sprint rekayasa untuk mendorong peningkatan inkremental dalam pemberitahuan untuk memastikan skenario kegagalan baru yang sebelumnya belum dipertimbangkan dapat sepenuhnya diakomodasi dalam tindakan otomatis baru.

  • Lakukan pengujian kesiapan operasional sebagai bagian dari proses CI/CD untuk memvalidasi aturan pemberitahuan utama untuk pembaruan penyebaran.

Tindakan prediktif dan operasi AI (AIOps)

Model pembelajaran mesin dapat diterapkan untuk menghubungkan dan memprioritaskan data operasional, membantu mengumpulkan wawasan penting yang terkait dengan pemfilteran 'kebisingan' pemberitahuan yang berlebihan dan memprediksi masalah sebelum menyebabkan dampak, serta mempercepat respons insiden ketika terjadi.

Lebih khusus lagi, metodologi AIOps dapat diterapkan pada wawasan penting tentang perilaku sistem, pengguna, dan proses DevOps. Wawasan ini dapat mencakup mengidentifikasi masalah yang terjadi sekarang (mendeteksi), mengukur mengapa masalah terjadi (mendiagnosis), atau menandakan apa yang akan terjadi di masa depan (prediksi). Wawasan tersebut dapat digunakan untuk mendorong tindakan yang menyesuaikan dan mengoptimalkan aplikasi untuk mengurangi masalah aktif atau potensial, menggunakan metrik bisnis utama, metrik kualitas sistem, dan metrik produktivitas DevOps, untuk diprioritaskan sesuai dengan dampak bisnis. Tindakan yang dilakukan sendiri dapat dimasukkan ke dalam sistem melalui perulangan umpan balik yang selanjutnya melatih model yang mendasar untuk mendorong efisiensi tambahan.

Metodologi Misi Penting AIOps Metodologi

Ada beberapa teknologi analitik dalam Azure, seperti Azure Synapse dan Azure Databricks, yang dapat digunakan untuk membangun dan melatih model analitik untuk AIOps. Oleh karena itu, bagian ini akan berfokus pada bagaimana teknologi ini dapat diposisikan dalam desain aplikasi untuk mengakomodasi AIOps dan mendorong tindakan prediktif, berfokus pada Azure Synapse yang mengurangi gesekan dengan menyatukan layanan data Azure yang terbaik bersama dengan fitur baru yang kuat.

AIOps digunakan untuk mendorong tindakan prediktif, menafsirkan, dan menghubungkan sinyal operasional kompleks yang diamati selama periode berkelanjutan untuk merespons dan mencegah masalah dengan lebih baik sebelum terjadi.

Mempertimbangkan rancangan

  • Azure Synapse Analytics menawarkan beberapa kemampuan Pembelajaran Mesin (ML).

    • Model ML dapat dilatih dan dijalankan di Kumpulan Synapse Spark dengan pustaka termasuk MLLib, SparkML, dan MMLSpark, serta pustaka sumber terbuka populer, seperti Scikit Learn.
    • Model ML dapat dilatih dengan alat ilmu data umum seperti PySpark/Python, Scala, atau .NET.

  • Synapse Analytics terintegrasi dengan Azure ML melalui notebook Azure Synapse, yang memungkinkan model ML dilatih di Ruang Kerja Azure ML menggunakan ML Otomatis.

  • Synapse Analytics juga memungkinkan kemampuan ML menggunakan Azure Cognitive Services untuk menyelesaikan masalah umum di berbagai domain, seperti Deteksi Anomali. Cognitive Services dapat digunakan dalam Azure Synapse, Azure Databricks, dan melalui SDK dan REST API dalam aplikasi klien.

  • Azure Synapse terintegrasi secara asli dengan alat Azure Data Factory untuk mengekstrak, mengubah, dan memuat (ETL) atau menyerap data dalam alur orkestrasi.

  • Azure Synapse memungkinkan pendaftaran himpunan data eksternal ke data yang disimpan di penyimpanan Azure Blob atau Azure Data Lake Storage.

    • Himpunan data terdaftar dapat digunakan dalam tugas analitik data kumpulan Synapse Spark.

  • Azure Databricks dapat diintegrasikan ke dalam alur Azure Synapse Analytics untuk kemampuan Spark tambahan.

    • Synapse mengatur pembacaan data dan mengirimkannya ke kluster Databricks, di mana Synapse dapat diubah dan disiapkan untuk pelatihan model ML.

  • Data sumber biasanya perlu disiapkan untuk analitik dan ML.

    • Synapse menawarkan berbagai alat untuk membantu persiapan data, termasuk Apache Spark, Synapse Notebooks, dan kumpulan SQL tanpa server dengan T-SQL dan visualisasi bawaan.

  • Model ML yang telah dilatih, diopsisionalkan, dan disebarkan dapat digunakan untuk penilaian batch di Synapse.

    • Skenario AIOps, seperti menjalankan prediksi regresi atau degradasi dalam ci/CD yang disalurkan, mungkin memerlukan penilaian real time .

  • Ada batas langganan untuk Azure Synapse, yang harus sepenuhnya dipahami dalam konteks metodologi AIOps.

  • Untuk sepenuhnya menggabungkan AIOps, Anda perlu memberi umpan data pengamatan mendekati real-time ke dalam model inferensi ML real-time secara berkelanjutan.

    • Kemampuan seperti deteksi anomali harus dievaluasi dalam aliran data pengamatan.

Rekomendasi desain

  • Pastikan semua sumber daya Azure dan komponen aplikasi sepenuhnya diinstrumentasikan sehingga himpunan data operasional lengkap tersedia untuk pelatihan model AIOps.

  • Serap data operasional Analitik Log dari Akun Azure Storage global dan regional ke dalam Azure Synapse untuk analisis.

  • Gunakan AZURE Monitor Alerts API untuk mengambil pemberitahuan historis dan menyimpannya dalam penyimpanan dingin untuk data operasional untuk kemudian digunakan dalam model ML. Jika ekspor data Analitik Log digunakan, simpan data pemberitahuan historis di akun Azure Storage yang sama dengan data Analitik Log yang diekspor.

  • Setelah data yang diserap disiapkan untuk pelatihan ML, tuliskan kembali ke Azure Storage sehingga tersedia untuk pelatihan model ML tanpa mengharuskan sumber daya komputasi persiapan data Synapse berjalan.

  • Pastikan operasionalisasi model ML mendukung penilaian batch dan real-time.

  • Saat model AIOps dibuat, terapkan MLOps dan terapkan praktik DevOps untuk mengotomatiskan siklus hidup ML untuk pelatihan, operasionalisasi, penilaian, dan peningkatan berkelanjutan. Buat proses CI/CD berulang untuk model ML AIOps.

  • Evaluasi Azure Cognitive Services untuk skenario prediktif tertentu karena overhead administratif dan integrasinya yang rendah. Pertimbangkan Deteksi Anomali untuk menandai varian yang tidak terduga dengan cepat dalam aliran data observabilitas.

Langkah selanjutnya

Tinjau pertimbangan penyebaran dan pengujian.

Penyebaran dan pengujian