Project Flash - استخدام Azure Resource Health لمراقبة توفر جهاز Azure الظاهري

مقالة
08/24/2024

Azure Resource Health هو أحد الحلول التي تقدمها Flash. Flash هو الاسم الداخلي لمشروع مخصص لبناء آلية قوية وموثوقة وسريعة للعملاء لمراقبة صحة الجهاز الظاهري (VM).

تتناول هذه المقالة استخدام Azure Resource Health لمراقبة توفر Azure Virtual Machine. للحصول على نظرة عامة على حلول Flash، راجع نظرة عامة على Flash.

للحصول على وثائق خاصة بالحلول الأخرى التي تقدمها Flash، اختر من المقالات التالية:

صحة موارد Azure

وهو يوفر فحوصات صحية فورية وسهلة الاستخدام للموارد الفردية من خلال المدخل. يمكن للعملاء الوصول بسرعة إلى شفرة صحة الموارد على المدخل ومراجعة سجل تاريخي لمدة 30 يوما من الفحوصات الصحية، ما يجعلها أداة ممتازة لاستكشاف الأخطاء وإصلاحها بسرعة ومباشرة. تساعدك ميزة Azure Resource Health الحالية على تشخيص مشاكل الخدمة التي تؤثر على موارد Azure والحصول على الدعم لها. وهو يبلغ عن الصحة الحالية والسابقة لمواردك، ويعرض أي نطاقات زمنية لم يكن كل مورد من مواردك متوفرا.

ولكننا نعلم أن عملائنا وشركائنا مهتمون بفهم الأسباب الكامنة وراء المشكلات التقنية، وتحسين كيفية تلقيهم الاتصالات حول أي مشكلات - لتغذية عمليات المراقبة، وشرح المشكلات لأصحاب المصلحة الآخرين، وفي نهاية المطاف لإبلاغ قرارات الأعمال.

الأسباب الجذرية لمشكلات الجهاز الظاهري في Azure Resource Health

لقد قمنا مؤخرا بشحن تحسين تجربة صحة الموارد التي من شأنها تحسين المعلومات التي نشاركها مع العملاء حول فشل الجهاز الظاهري وتوفير سياق إضافي حول السبب الجذري الذي أدى إلى المشكلة. الآن، بالإضافة إلى الحصول على إشعار سريع عند تأثر توفر الجهاز الظاهري، يمكن للعملاء توقع إضافة سبب جذري في وقت لاحق بمجرد أن يحدد نظام تحليل السبب الجذري التلقائي (RCA) مكون النظام الأساسي ل Azure الفاشل الذي أدى إلى فشل الجهاز الظاهري. دعونا نستعرض مثالا لمعرفة كيفية عمل هذه العملية في الممارسة العملية:

في الوقت T1، ينتقل حامل الخادم دون اتصال بسبب مشكلة في الشبكة، مما يتسبب في فقدان الأجهزة الظاهرية على الحامل الاتصال. ستتم مشاركة تحسينات الموثوقية الأخيرة المتعلقة ببنية الشبكة في منشور مدونة "Advancing Reliability" في المستقبل - شاهد هذه المساحة!

في الوقت T2، تدرك المراقبة الداخلية ل Azure أنها غير قادرة على الوصول إلى الأجهزة الظاهرية على الحامل وتبدأ في التخفيف من خلال إعادة توزيع الأجهزة الظاهرية المتأثرة إلى حامل جديد. خلال هذا الوقت، يتم إرسال تعليق توضيحي إلى صحة الموارد لإعلام العملاء بأن الجهاز الظاهري الخاص بهم متأثر حاليا وغير متوفر.

في الوقت T3، يتم ربط القياس عن بعد للنظام الأساسي من أعلى مفتاح الحامل والجهاز المضيف وأنظمة المراقبة الداخلية معا في محرك RCA لدينا لاشتقاق السبب الجذري للفشل. بمجرد حسابها، يتم نشر RCA مرة أخرى في صحة الموارد جنبا إلى جنب مع توصيات المرونة المعمارية ذات الصلة التي يمكن للعملاء تنفيذها لتقليل احتمالية التأثير في المستقبل.

في حين أن وظيفة إعلام وقت التعطل الأولية عمرها عدة سنوات، فإن نشر عبارة السبب الجذري هو إضافة جديدة. الآن، دعونا نتعمق في تفاصيل كيفية اشتقاق هذه الأسباب الجذرية.

محرك تحليل السبب الجذري

دعونا نلقي نظرة فاحصة على المثال السابق ونتعرف على تفاصيل كيفية عمل محرك RCA والتكنولوجيا الكامنة وراءه. في جوهر محرك RCA للأجهزة الظاهرية، يوجد Azure Data Explorer (ADX)، وهي خدمة بيانات كبيرة محسنة لتحليلات القياس عن بعد للسجلات ذات الحجم الكبير. يتيح Azure Data Explorer القدرة على تحليل تيرابايت من بيانات تتبع الاستخدام للسجل بسهولة من الأجهزة والخدمات التي تشكل النظام الأساسي ل Azure، وضمها معا، وتفسير تدفقات المعلومات المرتبطة لاشتقاق سبب جذري لسيناريوهات الفشل المختلفة. ينتهي الأمر بكونه عملية هندسة بيانات متعددة الخطوات:

المرحلة 1: الكشف عن وقت التعطل

المرحلة الأولى في تحليل السبب الجذري هي تحديد المشغل الذي يتم تنفيذ التحليل بموجبه. بالنسبة للأجهزة الظاهرية، نريد تحديد الأسباب الجذرية كلما أعاد الجهاز الظاهري التشغيل بشكل غير متوقع، لذلك يكون المشغل جهازا ظاهريا ينتقل من حالة لأعلى إلى حالة لأسفل. يعد تحديد هذه الانتقالات من القياس عن بعد للنظام الأساسي أمرا سهلا في معظم السيناريوهات، ولكنه أكثر تعقيدا حول أنواع معينة من فشل البنية الأساسية حيث قد تفقد بيانات تتبع استخدام النظام الأساسي بسبب فشل الجهاز أو فقدان الطاقة. للتعامل مع فئات الفشل هذه، يلزم تقنيات أخرى - مثل تتبع فقدان البيانات كإشارة محتملة للانتقال إلى توفر الجهاز الظاهري. يتفوق Azure Data Explorer في هذا الوقت من تحليل السلسلة، ويمكن العثور على نظرة أكثر تفصيلا على التقنيات حول هذه العملية في مجتمع Microsoft التقني: حساب وقت التعطل باستخدام وظائف النافذة ووظائف السلسلة الزمنية في Azure Data Explorer.

المرحلة 2: تحليل الارتباط

بمجرد تعريف حدث المشغل (في هذه الحالة، انتقال الجهاز الظاهري إلى حالة غير سليمة) تكون المرحلة التالية هي تحليل الارتباط. في هذه الخطوة، نستخدم وجود حدث المشغل لربط بيانات تتبع الاستخدام من نقاط عبر نظام Azure الأساسي، مثل:

مضيف Azure: الجزء الفعلي الذي يستضيف الأجهزة الظاهرية.
TOR: أعلى مفتاح شبكة الحامل.
Azure Storage: الخدمة التي تستضيف الأقراص الظاهرية لأجهزة Azure الظاهرية.

يحتوي كل نظام من هذه الأنظمة على موجزات بيانات تتبع الاستخدام الخاصة به التي تحتاج إلى تحليلها وربطها بحدث مشغل وقت تعطل الجهاز الظاهري. تتم هذه العملية من خلال فهم الرسم البياني للتبعية للجهاز الظاهري والأنظمة الأساسية التي يمكن أن تتسبب في فشل الجهاز الظاهري، ثم ضم جميع بيانات تتبع الاستخدام الصحية للأنظمة التابعة هذه معا، والتي تمت تصفيتها على الأحداث التي حدثت بالقرب من وقت انتقال الجهاز الظاهري. تساعد لغة الاستعلام البديهية والقوية في Azure Data Explorer من خلال تقديم أنماط موثقة مثل الانضمام إلى النافذة الزمنية لربط تدفقات بيانات تتبع الاستخدام الزمنية معا. في نهاية عملية الارتباط هذه، لدينا مجموعة بيانات تمثل انتقالات وقت تعطل الجهاز الظاهري مع القياس عن بعد للنظام الأساسي المترابط من جميع الأنظمة التابعة التي يمكن أن تسبب أو يمكن أن يكون لها معلومات مفيدة في تحديد ما أدى إلى فشل الجهاز الظاهري.

المرحلة 3: إسناد السبب الجذري

الخطوة التالية في العملية هي الإسناد. الآن بعد أن جمعنا جميع البيانات ذات الصلة معا في مجموعة بيانات واحدة، يتم تطبيق قواعد الإسناد لتفسير المعلومات وترجمتها إلى بيان السبب الجذري الذي يواجه العملاء. إذا عدت إلى مثالنا الأصلي لفشل TOR، فقد يكون لدينا العديد من المعلومات المثيرة للاهتمام لتفسيرها بعد تحليل الارتباط. على سبيل المثال، قد يكون لدى الأنظمة التي تراقب مضيفي Azure سجلات تشير إلى أنهم فقدوا الاتصال بالمضيفين خلال هذا الوقت. قد يكون لدينا أيضا إشارات تتعلق بمشاكل اتصال القرص الظاهري، وإشارات صريحة من جهاز TOR حول الفشل. يتم الآن مسح جميع هذه المعلومات ضوئيا، ويتم إعطاء الأولوية لإشارة فشل TOR الصريحة على الإشارات الأخرى كسبب جذري. يتم إنشاء عملية تحديد الأولويات هذه، والقواعد الكامنة وراءها، مع خبراء المجال وتعديلها مع تطور النظام الأساسي Azure. تقع آليات التعلم الآلي والكشف عن الحالات الخارجة عن المألوف على رأس هذه الأسباب الجذرية المنسوبة، للمساعدة في تحديد الفرص لتحسين قواعد التصنيف هذه واكتشاف تغييرات النمط في معدل هذه الإخفاقات في العودة إلى مسارات التوزيع الآمنة.

المرحلة الرابعة: نشر RCA

الخطوة الأخيرة هي نشر الأسباب الجذرية ل Azure Resource Health، حيث تصبح مرئية للعملاء. يتم النشر بواسطة تطبيق Azure Functions بسيط، والذي يستعلم بشكل دوري عن بيانات السبب الجذري المعالج في Azure Data Explorer، ويصدر النتائج إلى الخلفية لصحة المورد. نظرا لأن تدفقات المعلومات يمكن أن تأتي مع تأخيرات مختلفة في البيانات، يمكن تحديث RCAs أحيانا في هذه العملية لتعكس مصادر أفضل للمعلومات التي وصلت إلى سبب جذري أكثر تحديدا هو ما تم نشره في الأصل.

من الآن فصاعدًا

إن تحديد السبب الجذري لأي مشكلات وإبلاغها لعملائنا وشركائنا هو مجرد بداية. قد يحتاج عملاؤنا إلى أخذ هذه الاتفاقيات على مستوى الخدمة ومشاركتها مع عملائهم وزملاء العمل. نريد أن نبني على العمل هنا لتسهيل تحديد وتتبع الموارد RCAs، ومشاركتها بسهولة. لتحقيق ذلك، نحن نعمل على تغييرات الواجهة الخلفية لإنشاء معرفات تتبع فريدة لكل مورد وكل وقت تعطل يمكننا كشفها لك، بحيث يمكنك بسهولة مطابقة أوقات التعطل مع اتفاقيات RCAs الخاصة بهم. نحن نعمل أيضا على ميزات جديدة لتسهيل إرسال RCAs بالبريد الإلكتروني، والاشتراك في نهاية المطاف في RCAs للأجهزة الظاهرية الخاصة بك. ستمكن هذه الميزة من التسجيل في RCAs مباشرة في علبة الوارد بعد حدث عدم التوفر دون الحاجة إلى أي إجراء إضافي من جانبك.

الخطوات التالية

لمعرفة المزيد حول الحلول المقدمة، انتقل إلى مقالة الحل المقابلة:

للحصول على نظرة عامة حول كيفية مراقبة أجهزة Azure الظاهرية، راجع مراقبة أجهزة Azure الظاهرية ومرجع مراقبة أجهزة Azure الظاهرية.

مشاركة عبر