Project Flash - Menggunakan Azure Resource Health untuk memantau ketersediaan Azure Virtual Machine

Artikel
08/24/2024

Azure Resource Health adalah salah satu solusi yang ditawarkan oleh Flash. Flash adalah nama internal untuk proyek yang didedikasikan untuk membangun mekanisme yang kuat, andal, dan cepat bagi pelanggan untuk memantau kesehatan komputer virtual (VM).

Artikel ini membahas penggunaan Azure Resource Health untuk memantau ketersediaan Azure Virtual Machine. Untuk gambaran umum solusi Flash, lihat Gambaran umum Flash.

Untuk dokumentasi khusus untuk solusi lain yang ditawarkan oleh Flash, pilih dari artikel berikut:

Azure Resource Health

Ini menawarkan pemeriksaan kesehatan segera dan ramah pengguna untuk sumber daya individu melalui portal. Pelanggan dapat dengan cepat mengakses bilah kesehatan sumber daya di portal dan juga meninjau catatan historis pemeriksaan kesehatan 30 hari, menjadikannya alat yang sangat baik untuk pemecahan masalah yang cepat dan mudah. Fitur Azure Resource Health yang ada membantu Anda mendiagnosis dan mendapatkan dukungan untuk masalah layanan yang memengaruhi sumber daya Azure Anda. Ini melaporkan kesehatan sumber daya Anda saat ini dan sebelumnya, menunjukkan rentang waktu bahwa setiap sumber daya Anda tidak tersedia.

Tetapi kami tahu bahwa pelanggan dan mitra kami tertarik untuk memahami apa yang menyebabkan masalah teknis yang mendasar, dan dalam meningkatkan bagaimana mereka dapat menerima komunikasi tentang masalah apa pun — untuk memberi umpan ke dalam proses pemantauan, untuk menjelaskan cegukan kepada pemangku kepentingan lain, dan pada akhirnya untuk menginformasikan keputusan bisnis.

Akar penyebab masalah VM di Azure Resource Health

Kami baru-baru ini mengirimkan peningkatan pada pengalaman kesehatan sumber daya yang akan meningkatkan informasi yang kami bagikan dengan pelanggan tentang kegagalan VM dan memberikan konteks lebih lanjut tentang akar penyebab yang menyebabkan masalah. Sekarang, selain mendapatkan pemberitahuan cepat ketika ketersediaan VM terpengaruh, pelanggan dapat mengharapkan akar penyebab ditambahkan di titik selanjutnya setelah sistem Analisis Akar Penyebab Otomatis (RCA) kami mengidentifikasi komponen platform Azure yang gagal yang menyebabkan kegagalan VM. Mari kita telusuri contoh untuk melihat cara kerja proses ini dalam praktiknya:

Pada saat T1, rak server offline karena masalah jaringan, menyebabkan VM di rak kehilangan konektivitas. Peningkatan keandalan terbaru yang terkait dengan arsitektur jaringan akan dibagikan dalam posting blog Advancing Reliability di masa mendatang—tonton ruang ini!

Pada saat T2, pemantauan internal Azure mengakui bahwa ia tidak dapat menjangkau VM di rak dan mulai mengurangi dengan menyebarkan ulang VM yang terkena dampak ke rak baru. Selama waktu ini, anotasi dikirim ke kesehatan sumber daya yang memberi tahu pelanggan bahwa VM mereka saat ini terpengaruh dan tidak tersedia.

Pada saat T3, telemetri platform dari bagian atas sakelar rak, komputer host, dan sistem pemantauan internal berkorelasi bersama-sama di mesin RCA kami untuk mendapatkan akar penyebab kegagalan. Setelah dihitung, RCA kemudian diterbitkan kembali ke kesehatan sumber daya bersama dengan rekomendasi ketahanan arsitektur yang relevan yang dapat diterapkan pelanggan untuk meminimalkan probabilitas dampak di masa depan.

Meskipun fungsionalitas pemberitahuan waktu henti awal berusia beberapa tahun, penerbitan pernyataan akar penyebab adalah penambahan baru. Sekarang, mari kita selaraskan detail tentang bagaimana kita mendapatkan akar penyebab ini.

Mesin Analisis Akar Masalah

Mari kita lihat lebih dekat contoh sebelumnya dan menelusuri detail cara kerja mesin RCA dan teknologi di belakangnya. Inti mesin RCA kami untuk VM adalah Azure Data Explorer (ADX), layanan big data yang dioptimalkan untuk analitik telemetri log volume tinggi. Azure Data Explorer memungkinkan kemampuan untuk mengurai terabyte telemetri log dengan mudah dari perangkat dan layanan yang terdiri dari platform Azure, menggabungkannya bersama-sama, dan menginterpretasikan aliran informasi yang berkorelasi untuk mendapatkan akar penyebab skenario kegagalan yang berbeda. Ini akhirnya menjadi proses rekayasa data multistep:

Fase 1: Mendeteksi waktu henti

Fase pertama dalam analisis akar penyebab adalah menentukan pemicu di mana analisis dijalankan. Untuk Komputer Virtual, kami ingin menentukan akar penyebab setiap kali VM secara tidak terduga di-boot ulang, sehingga pemicunya adalah VM yang beralih dari status naik ke status tidak berfungsi. Mengidentifikasi transisi ini dari telemetri platform sangat mudah dalam sebagian besar skenario, tetapi lebih rumit di sekitar jenis kegagalan infrastruktur tertentu di mana telemetri platform mungkin tersesat karena kegagalan perangkat atau kehilangan daya. Untuk menangani kelas kegagalan ini, teknik lain diperlukan—seperti melacak kehilangan data sebagai kemungkinan indikasi transisi ketersediaan VM. Azure Data Explorer unggul pada saat analisis seri ini, dan melihat teknik yang lebih rinci sekeliling proses ini dapat ditemukan di Komunitas Teknologi Microsoft: Menghitung waktu henti menggunakan fungsi Window dan fungsi Time Series di Azure Data Explorer.

Fase 2: Analisis korelasi

Setelah peristiwa pemicu ditentukan (dalam hal ini, VM yang beralih ke status tidak sehat) fase berikutnya adalah analisis korelasi. Dalam langkah ini, kami menggunakan kehadiran peristiwa pemicu untuk menghubungkan telemetri dari titik-titik di seluruh platform Azure, seperti:

Host Azure: bilah fisik yang menghosting VM.
TOR: bagian atas sakelar jaringan rak.
Azure Storage: layanan yang menghosting Disk Virtual untuk Azure Virtual Machines.

Masing-masing sistem ini memiliki umpan telemetri mereka sendiri yang perlu diurai dan berkorelasi dengan peristiwa pemicu waktu henti VM. Proses ini dilakukan melalui pemahaman grafik dependensi untuk VM dan sistem dasar yang dapat menyebabkan VM gagal, dan kemudian menggabungkan semua telemetri kesehatan sistem dependen ini bersama-sama, difilter pada peristiwa yang terjadi mendekati waktu transisi VM. Bahasa kueri Azure Data Explorer yang intuitif dan canggih membantu dengan menawarkan pola yang didokumenkan seperti gabungan jendela waktu untuk menghubungkan aliran telemetri temporal bersama-sama. Pada akhir proses korelasi ini, kami memiliki himpunan data yang mewakili transisi waktu henti VM dengan telemetri platform yang berkorelasi dari semua sistem dependen yang dapat menyebabkan atau dapat memiliki informasi yang berguna dalam menentukan apa yang menyebabkan kegagalan VM.

Fase 3: Akar penyebab atribusi

Langkah selanjutnya dalam proses ini adalah atribusi. Sekarang setelah kami mengumpulkan semua data yang relevan bersama-sama dalam satu himpunan data, aturan atribusi diterapkan untuk menginterpretasikan informasi dan menerjemahkannya ke dalam pernyataan akar penyebab yang menghadap pelanggan. Jika Anda kembali ke contoh asli kegagalan TOR kami, setelah analisis korelasi kami, kami mungkin memiliki banyak informasi yang menarik untuk ditafsirkan. Misalnya, sistem yang memantau host Azure mungkin memiliki log yang menunjukkan bahwa mereka kehilangan konektivitas ke host selama waktu ini. Kami mungkin juga memiliki sinyal yang terkait dengan masalah konektivitas disk virtual, dan sinyal eksplisit dari perangkat TOR tentang kegagalan tersebut. Semua informasi ini sekarang dipindai, dan sinyal kegagalan TOR eksplisit diprioritaskan atas sinyal lain sebagai akar penyebabnya. Proses prioritas ini, dan aturan di baliknya, dibangun dengan pakar domain dan dimodifikasi seiring berkembangnya platform Azure. Mekanisme pembelajaran mesin dan deteksi anomali berada di atas akar penyebab yang diatribusikan ini, untuk membantu mengidentifikasi peluang untuk meningkatkan aturan klasifikasi ini dan mendeteksi perubahan pola dalam tingkat kegagalan ini untuk mengumpan kembali ke alur penyebaran yang aman.

Fase 4: Penerbitan RCA

Langkah terakhir adalah menerbitkan akar penyebab Azure Resource Health, di mana mereka menjadi terlihat oleh pelanggan. Penerbitan dilakukan oleh aplikasi Azure Functions sederhana, yang secara berkala meminta data akar penyebab yang diproses di Azure Data Explorer, dan memancarkan hasilnya ke backend kesehatan sumber daya. Karena aliran informasi dapat masuk dengan berbagai penundaan data, RCA kadang-kadang dapat diperbarui dalam proses ini untuk mencerminkan sumber informasi yang lebih baik yang telah tiba yang mengarah ke akar penyebab yang lebih spesifik yang awalnya diterbitkan.

Maju ke depan

Mengidentifikasi dan mengkomunikasikan akar penyebab masalah apa pun kepada pelanggan dan mitra kami hanyalah awal. Pelanggan kami mungkin perlu mengambil RCA ini dan membagikannya dengan pelanggan dan rekan kerja mereka. Kami ingin membangun pekerjaan di sini untuk mempermudah mengidentifikasi dan melacak RCA sumber daya, dan dengan mudah membagikannya. Untuk mencapainya, kami sedang mengerjakan perubahan backend untuk menghasilkan ID pelacakan per sumber daya dan per downtime unik yang dapat kami ekspos kepada Anda, sehingga Anda dapat dengan mudah mencocokkan waktu henti dengan RCA mereka. Kami juga sedang mengerjakan fitur baru untuk mempermudah email RCA, dan akhirnya berlangganan RCA untuk VM Anda. Fitur ini akan memungkinkan untuk mendaftar RCA langsung di kotak masuk Anda setelah peristiwa tidak tersedia tanpa tindakan lebih lanjut yang diperlukan di bagian Anda.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang solusi yang ditawarkan, lanjutkan ke artikel solusi yang sesuai:

Untuk gambaran umum tentang cara memantau Azure Virtual Machines, lihat Memantau komputer virtual Azure dan referensi Memantau komputer virtual Azure.

Bagikan melalui