نمط مراقبة نقطة النهاية الصحيحة

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

السياق والمشكلة

من الممارسات الجيدة مراقبة تطبيقات الويب والخدمات الخلفية. تساعد المراقبة على ضمان توفر التطبيقات والخدمات وأدائها بشكل صحيح. غالبا ما تتضمن متطلبات العمل المراقبة.

في بعض الأحيان يكون من الصعب مراقبة الخدمات السحابية أكثر من الخدمات المحلية. أحد الأسباب هو أنه ليس لديك تحكم كامل في بيئة الاستضافة. آخر هو أن الخدمات تعتمد عادة على الخدمات الأخرى التي يقدمها موردو المنصة وغيرهم.

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

حل

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

عادة ما يجمع فحص مراقبة السلامة بين عاملين:

• عمليات التحقق (إن وجدت) التي يقوم بها التطبيق أو الخدمة استجابة للطلب إلى نقطة نهاية التحقق من الصحة
• تحليل النتائج بواسطة الأداة أو إطار العمل الذي يقوم بالتحقق من الصحة

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

يوفر الشكل التالي نظرة عامة على النمط.

قد تقوم التعليمات البرمجية لمراقبة السلامة في التطبيق أيضا بتشغيل عمليات فحص أخرى لتحديد:

• وقت التوفر والاستجابة للتخزين السحابي أو قاعدة البيانات.
• حالة الموارد أو الخدمات الأخرى التي يستخدمها التطبيق. قد تكون هذه الموارد والخدمات في التطبيق أو خارجه.

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

تتضمن عمليات التحقق النموذجية التي تقوم بها أدوات المراقبة ما يلي:

• التحقق من صحة التعليمة البرمجية للاستجابة. على سبيل المثال، تشير استجابة HTTP من 200 (OK) إلى أن التطبيق استجاب دون خطأ. قد يفحص نظام المراقبة أيضاً وجود تعليمات برمجية استجابة أخرى لإعطاء نتائج أكثر شمولاً.
• التحقق من محتوى الاستجابة للكشف عن الأخطاء، حتى عندما يكون رمز الحالة 200 (موافق). من خلال التحقق من المحتوى، يمكنك الكشف عن الأخطاء التي تؤثر فقط على مقطع من صفحة الويب التي تم إرجاعها أو استجابة الخدمة. على سبيل المثال، يمكنك التحقق من عنوان صفحة أو البحث عن عبارة معينة تشير إلى أن التطبيق أرجع الصفحة الصحيحة.
• قياس وقت الاستجابة. تتضمن القيمة زمن انتقال الشبكة والوقت الذي استغرقه التطبيق لإصدار الطلب. يمكن أن تشير القيمة المتزايدة إلى مشكلة ناشئة في التطبيق أو الشبكة.
• التحقق من الموارد أو الخدمات الموجودة خارج التطبيق. مثال على ذلك هو شبكة تسليم المحتوى التي يستخدمها التطبيق لتسليم المحتوى من ذاكرة التخزين المؤقت العمومية.
• التحقق من انتهاء صلاحية شهادات TLS.
• قياس وقت استجابة بحث DNS عن عنوان URL للتطبيق. يقيس هذا الفحص زمن انتقال DNS وفشل DNS.
• التحقق من صحة عنوان URL الذي يرجعه بحث DNS. من خلال التحقق من الصحة، يمكنك التأكد من صحة الإدخالات. يمكنك أيضا المساعدة في منع إعادة توجيه الطلبات الضارة التي قد تنتج بعد هجوم على خادم DNS.

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

• مكان نشر التطبيق الخاص بك
• ما إذا كان يجب نشره في أكثر من مركز بيانات واحد

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

المسائل والاعتبارات

ضع في اعتبارك النقاط التالية عندما تقرر كيفية تنفيذ هذا النمط:

• فكر في كيفية التحقق من صحة الاستجابة. على سبيل المثال، حدد ما إذا كان رمز الحالة 200 (OK) كافيا للتحقق من أن التطبيق يعمل بشكل صحيح. التحقق من رمز الحالة هو الحد الأدنى من تنفيذ هذا النمط. يوفر رمز الحالة مقياسا أساسيا لتوفر التطبيق. ولكن التعليمات البرمجية توفر القليل من المعلومات حول العمليات والاتجاهات والمشكلات القادمة المحتملة في التطبيق.

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

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

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

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

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

• تخطيط كيفية تكوين الأمان لنقاط نهاية المراقبة. من خلال تكوين الأمان، يمكنك المساعدة في حماية نقاط النهاية من الوصول العام، مما قد:

  • عرض التطبيق لهجمات ضارة.
  • خطر التعرض للمعلومات الحساسة.
  • جذب هجمات رفض الخدمة (DoS).

  عادة ما تقوم بتكوين الأمان في تكوين التطبيق. ثم يمكنك تحديث الإعدادات بسهولة دون إعادة تشغيل التطبيق. ضع في اعتبارك استخدام تقنية واحدة أو أكثر من التقنيات التالية:

  • تأمين نقطة النهاية عن طريق طلب المصادقة. إذا كانت خدمة المراقبة أو الأداة تدعم المصادقة، يمكنك استخدام مفتاح أمان المصادقة في عنوان الطلب. يمكنك أيضا تمرير بيانات الاعتماد مع الطلب. عند استخدام المصادقة، ضع في اعتبارك كيفية الوصول إلى نقاط نهاية التحقق من الصحة. على سبيل المثال، لدى Azure App Service فحص صحة مضمن يتكامل مع ميزات مصادقة وتخويل App Service.

  • استخدم نقطة نهاية مخفية. على سبيل المثال، عرض نقطة النهاية على عنوان IP مختلف عن العنوان الذي يستخدمه عنوان URL للتطبيق الافتراضي. تكوين نقطة النهاية على منفذ HTTP غير قياسي. ضع في اعتبارك أيضا استخدام مسار معقد لصفحة الاختبار. يمكنك عادة تحديد عناوين ومنافذ نقطة نهاية إضافية في تكوين التطبيق. إذا لزم الأمر، يمكنك إضافة إدخالات لنقاط النهاية هذه إلى خادم DNS. ثم تجنب الاضطرار إلى تحديد عنوان IP مباشرة.

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

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

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

موعد استخدام النمط

هذا النمط مفيد لـ:

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

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط مراقبة نقطة النهاية الصحية في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.

مثال

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

تتوفر العديد من أمثلة التطبيقات التي تستخدم ASP.NET الفحوصات الصحية على GitHub.

مراقبة نقاط النهاية في التطبيقات المستضافة من Azure

تتضمن خيارات مراقبة نقاط النهاية في تطبيقات Azure ما يلي:

• استخدم ميزات المراقبة المضمنة في Azure، مثل Azure Monitor.
• استخدم خدمة تابعة لجهة خارجية أو إطار عمل مثل Microsoft System Center Operations Manager.
• إنشاء أداة مساعدة مخصصة أو خدمة تعمل على الخادم الخاص بك أو خادم مستضاف.

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

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

إذا كان هناك انقطاع رئيسي، يجب أن تكون نسبة استخدام الشبكة للعميل قابلة للتوجيه إلى نشر تطبيق متوفر عبر مناطق أو مناطق أخرى. هذا الموقف هو حالة جيدة للاتصال عبر أماكن العمل وموازنة التحميل العالمية. يعتمد الاختيار على ما إذا كان التطبيق داخليا أو خارجيا. يمكن لخدمات مثل Azure Front Door أو Azure Traffic Manager أو شبكات تسليم المحتوى توجيه نسبة استخدام الشبكة عبر المناطق استنادا إلى البيانات التي توفرها فحوصات السلامة.

Traffic Manager هي خدمة توجيه وموازنة تحميل. يمكنه استخدام مجموعة من القواعد والإعدادات لتوزيع الطلبات على مثيلات معينة من التطبيق الخاص بك. بالإضافة إلى طلبات التوجيه، يمكن ل Traffic Manager اختبار اتصال عنوان URL والمنفذ والمسار النسبي بانتظام. يمكنك تحديد أهداف ping بهدف تحديد مثيلات التطبيق الخاص بك النشطة والاستجابة للطلبات. إذا اكتشف Traffic Manager رمز حالة 200 (OK)، فإنه يضع علامة على التطبيق على أنه متوفر. تؤدي أي تعليمة برمجية حالة أخرى إلى وضع علامة على Traffic Manager للتطبيق على أنه غير متصل. تعرض وحدة تحكم Traffic Manager حالة كل تطبيق. يمكنك تكوين كل قاعدة لإعادة توجيه الطلبات إلى مثيلات أخرى من التطبيق الذي يستجيب.

ينتظر Traffic Manager فترة معينة من الوقت لتلقي استجابة من عنوان URL للمراقبة. تأكد من تشغيل رمز التحقق من الصحة في هذا الوقت. السماح لزمن انتقال الشبكة للرحلة ذهابا وإيابا من Traffic Manager إلى التطبيق الخاص بك والعودة مرة أخرى.

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

الإرشادات التالية مفيدة لتنفيذ هذا النمط:

• إرشادات مراقبة الصحة في التطبيقات المستندة إلى الخدمات المصغرة
• مراقبة صحة التطبيق للموثوقية، وهو جزء من Azure Well-Architected Framework
• إنشاء قاعدة تنبيه جديدة

الموارد ذات الصلة

• نمط مخزن التكوين الخارجي
• نمط قاطع الدائرة
• نمط توجيه البوابة
• نمط حارس البوابة