اختبارات توفر Application Insights

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

لا تتطلب اختبارات التوفر أي تغييرات على موقع الويب الذي تختبره وتعمل لأي نقطة نهاية HTTP أو HTTPS يمكن الوصول إليها من الإنترنت العام. يمكنك أيضا اختبار توفر واجهة برمجة تطبيقات REST التي تعتمد عليها خدمتك.

إشعار

يتم تخزين اختبارات التوفر مشفرة، وفقا لتشفير بيانات Azure في نهج الثبات .

أنواع اختبارات التوفر

هناك أربعة أنواع من اختبارات التوافر:

  • اختبار قياسي: هذا نوع من اختبار التوفر الذي يتحقق من توفر موقع ويب عن طريق إرسال طلب واحد، على غرار اختبار اتصال URL المهمل. بالإضافة إلى التحقق مما إذا كانت نقطة النهاية تستجيب للأداء وقياسه، تتضمن الاختبارات القياسية أيضا صلاحية شهادة TLS/SSL، والتحقق من العمر الاستباقي، وفعل طلب HTTP (على سبيل المثال، GETHEADو، و)، ورؤوس POSTمخصصة، وبيانات مخصصة مرتبطة بطلب HTTP الخاص بك.

  • اختبار Custom TrackAvailability: إذا قررت إنشاء تطبيق مخصص لتشغيل اختبارات التوفر، يمكنك استخدام أسلوب TrackAvailability() لإرسال النتائج إلى Application Insights.

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

  • (مهمل) اختبار اتصال عنوان URL: يمكنك إنشاء هذا الاختبار من خلال مدخل Microsoft Azure للتحقق مما إذا كانت نقطة النهاية تستجيب وقياس الأداء المرتبط بهذه الاستجابة. يمكنك أيضا تعيين معيار النجاح المخصص المقترن بميزات أكثر تقدما، مثل تحليل الطلبات التابعة والسماح بإعادة المحاولة.

هام

هناك اثنان من حالات إيقاف اختبارات التوفر القادمة:

  • اختبارات الويب متعددة الخطوات: في 31 أغسطس 2024، سيتم إيقاف اختبارات الويب متعددة الخطوات في Application Insights. ننصح مستخدمي هذه الاختبارات بالانتقال إلى اختبارات التوفر البديلة قبل تاريخ الإيقاف. بعد هذا التاريخ، سنقوم بإيقاف البنية الأساسية التي ستقطع الاختبارات متعددة الخطوات المتبقية.

  • اختبارات اتصال عنوان URL: في 30 سبتمبر 2026، سيتم إيقاف اختبارات اتصال URL في Application Insights. ستتم إزالة اختبارات اتصال URL الموجودة من مواردك. راجع تسعير الاختبارات القياسية والانتقال إلى استخدامها قبل 30 سبتمبر 2026 للتأكد من أنه يمكنك الاستمرار في تشغيل اختبارات التوفر ذات الخطوة الواحدة في موارد Application Insights.

إنشاء اختبار توفر

تلميح

إذا كنت تستخدم حاليا اختبارات توفر أخرى، مثل اختبارات اتصال URL، فيمكنك إضافة اختبارات قياسية إلى جانب الاختبارات الأخرى. إذا كنت تريد استخدام الاختبارات القياسية بدلا من أحد الاختبارات الأخرى، أضف اختبارا قياسيا واحذف الاختبار القديم.

المتطلبات الأساسية

الشروع في العمل

  1. انتقل إلى مورد Application Insights وحدد جزء التوفر.

  2. حدد إضافة اختبار قياسي.

    لقطة شاشة تعرض جزء التوفر مع فتح علامة التبويب Add Standard test.

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

    الإعدادات ‏‏الوصف
    عنوان URL يمكن أن يكون عنوان URL أي صفحة ويب تريد اختبارها، ولكن يجب أن يكون مرئيا من الإنترنت العام. يمكن أن يتضمن عنوان URL سلسلة استعلام. لذلك، على سبيل المثال، يمكنك ممارسة قاعدة البيانات قليلاً. إذا تم حل عنوان URL لإعادة توجيه، فإننا نتابعه حتى 10 عمليات إعادة توجيه.
    تحليل الطلبات التابعة يطلب الاختبار الصور والبرامج النصية وملفات الأنماط والملفات الأخرى التي تعد جزءا من صفحة الويب قيد الاختبار. يتضمن وقت الاستجابة المسجل الوقت المستغرق للحصول على هذه الملفات. يفشل الاختبار إذا تعذر تنزيل أي من هذه الموارد بنجاح خلال المهلة المحددة للاختبار بأكمله. إذا لم يتم تحديد الخيار، فإن الاختبار يطلب فقط الملف في عنوان URL الذي حددته. يؤدي تمكين هذا الخيار إلى فحص أكثر صرامة. قد يفشل الاختبار للحالات، وهو ما قد لا يكون ملحوظا عند استعراض الموقع يدويا. يرجى ملاحظة أننا نوزع ما يصل إلى 15 طلبا تابعا فقط.
    تمكين عمليات إعادة المحاولة عندما يفشل الاختبار، يتمت إعادة محاولته بعد فترة قصيرة. لا يتم الإبلاغ عن الفشل إلا إذا فشلت ثلاث محاولات متتالية. ثم تجرى الاختبارات اللاحقة على تكرار الاختبار المعتاد. يتم تعليق إعادة المحاولة مؤقتاً حتى النجاح التالي. يتم تطبيق هذه القاعدة بشكل مستقل في كل موقع اختبار. ننصح بهذا الخيار. في المتوسط، تختفي حوالي 80% من حالات الفشل عند إعادة المحاولة.
    اختبار التحقق من شهادة SSL يمكنك التحقق من شهادة SSL على موقع الويب الخاص بك للتأكد من أنها مثبّتة بشكل صحيح، وصحيحة، وموثوق بها، ولا تعطي أي أخطاء لأي من المستخدمين.
    فحص مدى الحياة الاستباقي يتيح لك هذا الإعداد تحديد فترة زمنية محددة قبل انتهاء صلاحية شهادة SSL الخاصة بك. بعد انتهاء صلاحيته، سيفشل الاختبار الخاص بك.
    تكرار الاختبار تعيين عدد مرات تشغيل الاختبار من كل موقع اختبار. مع تكرار افتراضي من خمس دقائق وخمسة مواقع للاختبار، يتم اختبار موقعك في المتوسط كل دقيقة.
    مواقع الاختبار ترسل خوادمنا طلبات ويب إلى عنوان URL الخاص بك من هذه المواقع. الحد الأدنى لعدد مواقع الاختبار الموصى بها هو خمسة لضمان أنه يمكنك تمييز المشاكل في موقع الويب الخاص بك عن مشاكل الشبكة. يمكنك تحديد ما يصل إلى 16 موقعًا.
    العناوين المخصصة أزواج القيمة الرئيسية التي تحدد معلمات التشغيل.
    فعل طلب HTTP حدد الإجراء الذي تريد اتخاذه مع طلبك.
    نص الطلب البيانات المخصصة المقترنة بطلب HTTP الخاص بك. يمكنك تحميل ملفاتك الخاصة أو إدخال المحتوى الخاص بك أو تعطيل هذه الميزة.

معايير النجاح

الإعدادات ‏‏الوصف
مهلة الاختبار إنقاص هذه القيمة ليتم التنبيه حول الاستجابات البطيئة. يتم احتساب الاختبار على أنه فشل إذا لم يتم تلقي الاستجابات من موقعك خلال هذه الفترة. إذا حددت تحليل الطلبات التابعة، فيجب استلام جميع الصور وملفات الأنماط والبرامج النصية والموارد الأخرى التابعة خلال هذه الفترة.
استجابة HTTP رمز الحالة الذي تم إرجاعه الذي يتم احتسابه كنجاح. الرقم 200 هو التعليمات البرمجية التي تشير إلى أنه تم إرجاع صفحة ويب عادية.
مطابقة المحتوى سلسلة، مثل «Welcome!» نحن نختبر حدوث تطابق دقيق لحالة الأحرف في كل استجابة. يجب أن تكون سلسلة عادية بدون أحرف البدل. لا تنسَ أنه إذا تغير محتوى صفحتك فقد تضطر إلى تحديثه. يتم اعتماد الأحرف الإنجليزية فقط مع مطابقة المحتوى.

تنبيهات التوفر

الإعدادات ‏‏الوصف
في الوقت الحقيقي تقريبا نوصي باستخدام تنبيهات في الوقت الفعلي تقريبا. يتم تكوين هذا النوع من التنبيه بعد إنشاء اختبار التوفر.
عتبة موقع التنبيه نوصي بحد أدنى 3/5 مواقع. العلاقة المثلى بين عتبة موقع التنبيه وعدد مواقع الاختبار هي عدد عتبة موقع التنبيه = لمواقع الاختبار - 2، مع ما لا يقل عن خمسة مواقع اختبار.

علامات تعداد المواقع

يمكنك استخدام علامات المحتوى التالية لسمة الموقع الجغرافي عند نشر اختبار اتصال عنوان URL للتوفر باستخدام Azure Resource Manager.

Azure

‏‫اسم العرض‬ اسم المنطقة السكانية
شرق أستراليا emea-au-syd-edge
جنوب البرازيل latam-br-gru-edge
Central US us-fl-mia-edge
شرق آسيا apac-hk-hkn-azr
شرق الولايات المتحدة us-va-ash-azr
جنوب فرنسا (وسط فرنسا سابقاً) emea-ch-zrh-edge
وسط فرنسا emea-fr-pra-edge
شرق اليابان apac-jp-kaw-edge
أوروبا الشمالية emea-gb-db3-azr
وسط شمال الولايات المتحدة us-il-ch1-azr
South Central US us-tx-sn1-azr
جنوب شرق آسيا apac-sg-sin-azr
غرب المملكة المتحدة emea-se-sto-edge
أوروبا الغربية emea-nl-ams-azr
غرب الولايات المتحدة us-ca-sjc-azr
جنوب المملكة المتحدة emea-ru-msa-edge

Azure Government

‏‫اسم العرض‬ اسم المنطقة السكانية
USGov Virginia usgov-va-azr
حكومة ولاية أريزونا الأمريكية usgov-phx-azr
USGov Texas usgov-tx-azr
وزارة الدفاع الأمريكية - الشرق usgov-ddeast-azr
وزارة الدفاع الأمريكية - الوسط usgov-ddcentral-azr

Microsoft Azure مُشغل بواسطة 21Vianet

‏‫اسم العرض‬ اسم المنطقة السكانية
منطقة شرق الصين mc-cne-azr
منطقة شرق الصين 2 mc-cne2-azr
منطقة شمال الصين mc-cnn-azr
منطقة شمال الصين 2 mc-cnn2-azr

تمكين التنبيهات

يتم الآن تمكين التنبيهات تلقائيا بشكل افتراضي، ولكن لتكوين تنبيه بشكل كامل، يجب عليك في البداية إنشاء اختبار التوفر الخاص بك.

إشعار

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

  1. بعد حفظ اختبار التوفر، في علامة التبويب Details ، حدد علامة الحذف حسب الاختبار الذي أجريته. حدد صفحة Open Rules (Alerts).

    لقطة شاشة تعرض جزء التوفر لمورد Application Insights في مدخل Microsoft Azure وخيار قائمة صفحة القواعد المفتوحة (التنبيهات).

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

معايير التنبيه

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

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

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

تغيير معايير التنبيه

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

إنشاء قاعدة تنبيه مخصصة

إذا كنت بحاجة إلى قدرات متقدمة، يمكنك إنشاء قاعدة تنبيه مخصصة في علامة التبويب تنبيهات. حدد إنشاء>قاعدة تنبيه. اختر Metrics for Signal type لإظهار جميع الإشارات المتوفرة وحدد Availability.

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

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

  • تنبيه حول مقاييس التوفر: باستخدام التنبيهات الموحدة الجديدة، يمكنك التنبيه بشأن التوفر المجمع المقسم ومقاييس مدة الاختبار أيضا:

    1. حدد مورد Application Insights في تجربة المقاييس ، وحدد مقياس التوفر .

    2. ينقلك خيار تكوين التنبيهات من القائمة إلى التجربة الجديدة حيث يمكنك تحديد اختبارات أو مواقع معينة لإعداد قواعد التنبيه عليها. يمكنك أيضاً تكوين مجموعات العمل لقاعدة التنبيه هذه هنا.

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

    تتضمن المقاييس على بيانات التوفر أي نتائج توفر مخصصة قد تقوم بإرسالها عن طريق استدعاء TrackAvailability SDK. يمكنك استخدام التنبيه على دعم المقاييس للتنبيه بنتائج التوفر المخصصة.

أتمتة التنبيهات

لأتمتة هذه العملية باستخدام قوالب Azure Resource Manager، راجع إنشاء تنبيه قياسي باستخدام قالب Azure Resource Manager.

الاطلاع على نتائج اختبار التوفر

يشرح هذا القسم كيفية مراجعة نتائج اختبار التوفر في مدخل Microsoft Azure والاستعلام عن البيانات باستخدام Log Analytics. يمكن تصور نتائج اختبار التوفر مع كل من طرق عرض Line وScatter Plot .

التحقق من إمكانية التوّفر

ابدأ بمراجعة الرسم البياني في علامة التبويب Availability لمورد Application Insights.

لقطة شاشة تعرض صفحة التوفر مع تمييز زر تحديث.

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

لقطة شاشة تعرض طريقة عرض الخط.

حدد اختبارا أو موقعا معينا. أو يمكنك تقليل الفترة الزمنية لرؤية المزيد من النتائج حول فترة الاهتمام الزمنية. استخدم Search Explorer لمشاهدة النتائج من جميع عمليات التنفيذ. أو يمكنك استخدام استعلامات Log Analytics لتشغيل تقارير مخصصة على هذه البيانات.

لمشاهدة تفاصيل المعاملة من طرف إلى طرف، ضمن Drill into، حدد Successful أو Failed. ثم حدد عينة. يمكنك أيضًا الوصول إلى تفاصيل المعاملات الشاملة عن طريق تحديد نقطة بيانات على الرسم البياني.

لقطة شاشة توضح تحديد نموذج اختبار التوفر.

لقطة شاشة تعرض تفاصيل المعاملة من طرف إلى طرف.

فحص الاختبارات وتحريرها

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

لقطة شاشة تعرض تفاصيل اختبار العرض. تحرير وتعطيل اختبار ويب.

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

إذا رأيت حالات فشل

حدد نقطة حمراء.

لقطة شاشة تعرض علامة التبويب الخاصة بتفاصيل المعاملة الشاملة.

من نتيجة اختبار التوفر، يمكنك رؤية تفاصيل المعاملة عبر جميع المكونات. من هنا، يمكنك تنفيذ ما يلي:

  • راجع تقرير استكشاف الأخطاء وإصلاحها لتحديد ما قد يكون سبب فشل الاختبار ولكن التطبيق الخاص بك لا يزال متوفرا.
  • افحص الاستجابة الواردة من الخادم الخاص بك.
  • شخّص حالة الفشل باستخدام القياس المرتبط من جانب الخادم الذي تم جمعه أثناء معالجة اختبار التوفر الفاشل.
  • سجّل مشكلة أو عنصر عمل في Git أو Azure Boards لتعقب المشكلة. سيحتوي الخطأ على ارتباط لهذا الحدث.
  • افتح نتيجة اختبار الويب في Visual Studio.

لمعرفة المزيد حول تجربة تشخيص المعاملات من طرف إلى طرف، راجع وثائق تشخيص المعاملات.

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

لقطة شاشة تعرض التشخيصات من جانب الخادم.

بالإضافة إلى النتائج الأولية، يمكنك أيضا عرض مقياسي توفر رئيسيين في مستكشف المقاييس:

  • التوفر: النسبة المئوية للاختبارات التي نجحت في جميع عمليات تنفيذ الاختبار.
  • مدة الاختبار: متوسط مدة الاختبار في جميع عمليات تنفيذ الاختبار.

الاستعلام في Log Analytics

يمكنك استخدام Log Analytics لعرض نتائج التوفر والتبعيات والمزيد. لمعرفة المزيد حول Log Analytics، راجع نظرة عامة على استعلام السجل.

لقطة شاشة تعرض نتائج التوفر.

لقطة شاشة تعرض علامة التبويب استعلام جديد مع تبعيات محدودة ب 50.

ترحيل اختبارات التوفر

في هذه المقالة، نرشدك خلال عملية الترحيل من اختبارات اتصال URL الكلاسيكية إلى الاختبارات القياسية الحديثة والفعالة.

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

ترحيل اختبارات اتصال URL الكلاسيكية إلى الاختبارات القياسية

ترشدك الخطوات التالية خلال عملية إنشاء الاختبارات القياسية التي تنسخ وظائف اختبارات اتصال عنوان URL. يسمح لك بالبدء بسهولة أكبر في استخدام الميزات المتقدمة للاختبارات القياسية باستخدام اختبارات اتصال URL التي تم إنشاؤها مسبقا.

هام

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

المتطلبات الأساسية

الشروع في العمل

  1. اتصل باشتراكك باستخدام Azure PowerShell (Connect-AzAccount + Set-AzContext).

  2. سرد جميع اختبارات اتصال URL في الاشتراك الحالي:

    Get-AzApplicationInsightsWebTest | `
    Where-Object { $_.WebTestKind -eq "ping" } | `
    Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
    
  3. ابحث عن URL Ping Test الذي تريد ترحيله وسجل مجموعة الموارد واسمه.

  4. تنشئ الأوامر التالية اختبارا قياسيا بنفس منطق اختبار اتصال عنوان URL.

    إشعار

    تعمل الأوامر التالية لكل من نقاط نهاية HTTP وHTTPS، والتي يتم استخدامها في اختبارات اتصال URL.

    $resourceGroup = "pingTestResourceGroup";
    $appInsightsComponent = "componentName";
    $pingTestName = "pingTestName";
    $newStandardTestName = "newStandardTestName";
    
    $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
    $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
    $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
    $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;
    
    $dynamicParameters = @{};
    
    if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
    $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
    }
    
    if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
    -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
    -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
    $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
    $dynamicParameters["ContentPassIfTextFound"] = $true;
    }
    
    New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
    -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
    -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
    -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
    -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);
    
  5. لا يحتوي الاختبار القياسي الجديد على قواعد تنبيه بشكل افتراضي، لذلك لا ينشئ تنبيهات مزعجة. لا يتم إجراء أي تغييرات على اختبار اتصال URL حتى تتمكن من الاستمرار في الاعتماد عليه للتنبيهات.

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

  7. لحذف اختبار اتصال URL باستخدام Azure PowerShell، يمكنك استخدام هذا الأمر:

    Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
    

الاختبار خلف جدار حماية

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

تمكين اختبار التوفر العام

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

تحذير

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

مصادقة نسبة استخدام الشبكة

تعيين عناوين مخصصة في اختبارات التوفر القياسية للتحقق من صحة نسبة استخدام الشبكة.

  1. إنشاء رمز مميز أو GUID لتحديد نسبة استخدام الشبكة من اختبارات التوفر الخاصة بك.

  2. أضف العنوان المخصص "X-Customer-InstanceId" بالقيمة ApplicationInsightsAvailability:<GUID generated in step 1> ضمن قسم "معلومات الاختبار القياسية" عند إنشاء اختبارات التوفر أو تحديثها.

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

    لقطة شاشة تعرض عنوان التحقق المخصص.

بدلا من ذلك، قم بتعيين الرمز المميز كمعلمة استعلام. على سبيل المثال، https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>

تكوين جدار الحماية للسماح بالطلبات الواردة من اختبارات التوفر

إشعار

هذا المثال خاص باستخدام علامة خدمة مجموعة أمان الشبكة. تقبل العديد من خدمات Azure علامات الخدمة، كل منها يتطلب خطوات تكوين مختلفة.

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

    1. إذا كنت تستخدم مجموعات أمان شبكة Azure، فانتقل إلى مورد مجموعة أمان الشبكة وضمن الإعدادات، حدد قواعد الأمان الواردة. بعد ذلك، حدد إضافة.

      لقطة شاشة تعرض علامة تبويب قواعد الأمان الواردة في مورد مجموعة أمان الشبكة.

    2. بعد ذلك، حدد علامة الخدمة كمصدر وحدد ApplicationInsightsAvailability كعلامة خدمة المصدر. استخدم المنافذ المفتوحة 80 (http) و443 (https) لحركة المرور الواردة من علامة الخدمة.

      لقطة شاشة تعرض علامة التبويب Add inbound security rules مع مصدر علامة الخدمة.

  • لإدارة الوصول عندما تكون نقاط النهاية خارج Azure أو عندما لا تكون علامات الخدمة خيارا، قم بالسماح بقائمة عناوين IP لوكلاء اختبار الويب لدينا. يمكنك الاستعلام عن نطاقات IP باستخدام PowerShell أو Azure CLI أو استدعاء REST باستخدام واجهة برمجة تطبيقات علامة الخدمة. للحصول على قائمة شاملة بعلامات الخدمة الحالية وتفاصيل IP الخاصة بها، نزل ملف JSON.

    1. في مورد مجموعة أمان الشبكة، ضمن الإعدادات، حدد قواعد الأمان الواردة. بعد ذلك، حدد إضافة.

    2. بعد ذلك، حدد عناوين IP كمصدر. ثم أضف عناوين IP الخاصة بك في قائمة محددة بفاصلة في نطاقات عنوان IP المصدر/CIRD.

      لقطة شاشة تعرض علامة التبويب Add inbound security rules مع مصدر عناوين IP.

قطع الاتصال أو سيناريوهات عدم الدخول

  1. قم بتوصيل مورد Application Insights بنقطة نهاية الخدمة الداخلية باستخدام Azure Private Link.

  2. اكتب تعليمات برمجية مخصصة لاختبار الخادم الداخلي أو نقاط النهاية بشكل دوري. أرسل النتائج إلى Application Insights باستخدام واجهة برمجة تطبيقات TrackAvailability() في حزمة SDK الأساسية.

تكوينات TLS المدعومة

لتوفير التشفير الأفضل في فئته، تستخدم جميع اختبارات التوفر بروتوكول أمان طبقة النقل (TLS) 1.2 و1.3 كآليات التشفير المفضلة. بالإضافة إلى ذلك، يتم أيضا دعم مجموعات التشفير والمنحنيات الإهليليجية التالية داخل كل إصدار.

إشعار

TLS 1.3 متاح حاليا فقط في مناطق اختبار التوفر NorthCentralUS و CentralUS و EastUS و SouthCentralUS و WestUS.

TLS 1.2

مجموعات التشفير

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

منحنيات بيضاوية

  • NistP384
  • NistP256

TLS 1.3

مجموعات التشفير

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256

المنحنيات البيضاوية:

  • NistP384
  • NistP256

إهمال تكوين TLS

تحذير

في 31 أكتوبر 2024، تماشيا مع إهمال TLS القديم على نطاق Azure، سيتم إيقاف إصدارات بروتوكول TLS 1.0/1.1 والإصدارات المدرجة أدناه من مجموعات تشفير TLS 1.2/1.3 القديمة والمنحنيات الإيليبتية لاختبارات توفر Application Insights.

TLS 1.0 وTLS 1.1

لن يتم دعم إصدارات البروتوكول بعد الآن.

TLS 1.2

مجموعات التشفير

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

المنحنيات البيضاوية:

  • منحنى25519

TLS 1.3

منحنيات بيضاوية

  • منحنى25519

استكشاف الأخطاء وإصلاحها

تحذير

لقد قمنا مؤخرا بتمكين TLS 1.3 في اختبارات التوفر. إذا كنت ترى رسائل خطأ جديدة نتيجة لذلك، فيرجى التأكد من أن العملاء الذين يعملون على Windows Server 2022 مع تمكين TLS 1.3 يمكنهم الاتصال بنقطة النهاية الخاصة بك. إذا لم تتمكن من القيام بذلك، فقد تفكر في تعطيل TLS 1.3 مؤقتا على نقطة النهاية بحيث تعود اختبارات التوفر إلى إصدارات TLS القديمة.
لمزيد من المعلومات، يرجى التحقق من مقالة استكشاف الأخطاء وإصلاحها. راجع «dedicated troubleshooting article».

مصنف وقت التعطل وSLA ومصنف الانقطاع

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

يمكن الوصول إلى قالب مصنف اتفاقية مستوى الخدمة من مورد Application Insights بطريقتين:

  • افتح جزء التوفر ، ثم حدد تقرير اتفاقية مستوى الخدمة في أعلى الشاشة.

    لقطة شاشة تعرض علامة التبويب **Availability** مع تمييز تقرير SLA.

  • افتح جزء المصنفات ، ثم حدد وقت التعطل وانقطاع التيار الكهربائي.

    لقطة شاشة لمعرض المصنف مع تمييز مصنف وقت التعطل وانقطاع التيار الكهربائي.

المعلمة التي تتسم بالمرونة

تؤثر المعلمات التي تم تحديدها في المصنف على بقية التقرير.

 لقطة شاشة تعرض المعلمات.

  • Subscriptions، App Insights Resources، و Web Test: تحدد هذه المعلمات خيارات الموارد عالية المستوى. وهي تستند إلى استعلامات Log Analytics وتستخدم في كل استعلام تقرير.
  • Failure Threshold و Outage Window: يمكنك استخدام هذه المعلمات لتحديد المعايير الخاصة بك ل انقطاع الخدمة. مثال على ذلك هو معايير تنبيه توفر Application Insights استنادا إلى عداد موقع فاشل خلال فترة مختارة. يتكون الحد النموذجي من ثلاثة مواقع على مدى فترة خمس دقائق.
  • Maintenance Period: يمكنك استخدام هذه المعلمة لتحديد تكرار الصيانة النموذجي. Maintenance Window هو محدد التاريخ والوقت لفترة صيانة مثال. يتم تجاهل كافة البيانات التي تحدث خلال الفترة المحددة في النتائج.
  • Availability Target %: تحدد هذه المعلمة هدفك المستهدف وتأخذ قيما مخصصة.

صفحة المعاينة

تحتوي صفحة النظرة العامة على معلومات عالية المستوى حول:

  • إجمالي اتفاقية مستوى الخدمة (باستثناء فترات الصيانة، إذا تم تعريفها)
  • مثيلات الانقطاع من طرف إلى طرف
  • وقت تعطل التطبيق

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

لقطة شاشة تعرض صفحة نظرة عامة تعرض جدول النظرة العامة حسب الاختبار.

يمكنك أيضا التحقق من أطول انقطاع حدث خلال فترة إعداد التقارير.

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

وقت التعطل والانقطاع والأعطال

تحتوي علامة التبويب الانقطاعات ووقت التعطل على معلومات حول إجمالي مثيلات الانقطاع وإجمالي وقت التعطل مقسما حسب الاختبار.

لقطة شاشة تعرض علامة التبويب الانقطاعات ووقت التعطل في مصنف وقت التعطل وانقطاع التيار الكهربائي.

تحتوي علامة التبويب Failures by Location على خريطة جغرافية لمواقع الاختبار الفاشلة للمساعدة في تحديد مناطق اتصال المشكلة المحتملة.

لقطة شاشة تعرض علامة التبويب فشل حسب الموقع في مصنف وقت التعطل وانقطاع الخدمة.

تحرير التقرير

يمكنك تحرير التقرير مثل أي مصنف Azure Monitor آخر.

لقطة شاشة تعرض تحديد الزر تحرير لتغيير المرئيات إلى مخطط دائري.

يمكنك تخصيص الاستعلامات أو المرئيات بناءً على احتياجات فريقك.

لقطة شاشة تعرض تغيير المرئيات إلى مخطط دائري.

Log Analytics

من الممكن تشغيل جميع الاستعلامات في سجل التحليلات واستخدامها في تقارير أو لوحات معلومات أخرى.

لقطة شاشة توضح كيفية الوصول إلى استعلام سجل.

قم بإزالة تقييد المعلمة وإعادة استخدام الاستعلام الأساسي.

لقطة شاشة تعرض استعلام سجل يمكنك إعادة استخدامه.

الوصول والمشاركة

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

 لقطة شاشة تعرض جزء مشاركة القالب.

الأسئلة الشائعة

يقدم هذا القسم إجابات للأسئلة الشائعة.

عام

هل يمكنني تشغيل اختبارات التوفر على خادم إنترانت؟

يتم إجراء اختبارات الويب الخاصة بنا على نقاط التواجد التي يتم توزيعها في جميع أنحاء العالم. يوجد حلان:

  • باب جدار الحماية: السماح بالطلبات إلى الخادم الخاص بك من قائمة طويلة وقابلة للتغيير من وكلاء اختبار الويب.
  • التعليمات البرمجية المخصصة: اكتب التعليمات البرمجية الخاصة بك لإرسال طلبات دورية إلى الخادم الخاص بك من داخل الإنترانت. يمكنك تشغيل اختبارات ويب Visual Studio لهذا الغرض. يمكن للمختبر إرسال النتائج إلى Application Insights باستخدام TrackAvailability() واجهة برمجة التطبيقات.

ما هي سلسلة عامل المستخدم لاختبارات التوفر؟

سلسلة عامل المستخدم هي Mozilla/5.0 (متوافقة؛ MSIE 9.0؛ Windows NT 6.1؛ Trident/5.0؛ AppInsights)

دعم TLS

كيف يؤثر هذا الإهمال على سلوك اختبار الويب الخاص بي؟

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

كيف أعمل تأكد من عدم تأثر اختبار الويب الخاص بي؟

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

كيف أعمل التحقق من صحة تكوين TLS الذي تدعمه نقطة النهاية البعيدة؟

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

إشعار

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

بعد 31 أكتوبر 2024، ما هو سلوك اختبار الويب للاختبارات المتأثرة؟

لا يوجد نوع استثناء واحد ستقدم به جميع حالات فشل تأكيد اتصال TLS المتأثرة بهذا الإهمال. ومع ذلك، فإن الاستثناء الأكثر شيوعا الذي سيبدأ اختبار الويب الخاص بك بفشله سيكون The request was aborted: Couldn't create SSL/TLS secure channel. يجب أن تكون قادرا أيضا على رؤية أي حالات فشل متعلقة ب TLS في خطوة استكشاف أخطاء TLS Transport وإصلاحها لنتيجة اختبار الويب التي قد تتأثر.

هل يمكنني عرض تكوين TLS المستخدم حاليا بواسطة اختبار الويب الخاص بي؟

لا يمكن عرض تكوين TLS الذي تم التفاوض عليه أثناء تنفيذ اختبار الويب. طالما أن نقطة النهاية البعيدة تدعم تكوين TLS الشائع مع اختبارات التوفر، فلا ينبغي رؤية أي تأثير بعد الإهمال.

ما المكونات التي يؤثر عليها الإهمال في خدمة اختبار التوفر؟

يجب أن يؤثر إهمال TLS المفصل في هذا المستند فقط على سلوك تنفيذ اختبار اختبار الويب لاختبار التوفر بعد 31 أكتوبر 2024. لمزيد من المعلومات حول التفاعل مع خدمة اختبار التوفر لعمليات CRUD، راجع Azure Resource Manager TLS Support. يوفر هذا المورد المزيد من التفاصيل حول المخططات الزمنية لدعم TLS والإهمال.

أين يمكنني الحصول على دعم TLS؟

للحصول على أي أسئلة عامة حول مشكلة TLS القديمة، راجع حل مشكلات TLS.

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