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

مقالة
09/13/2024

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

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

إشعار

يتم تخزين اختبارات التوفر مشفرة، وفقا لتشفير بيانات 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.

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

مورد Application Insights إلى مساحة العمل

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

انتقل إلى مورد Application Insights وافتح تجربة التوفر.
حدد Add Standard test من شريط التنقل العلوي.

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

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

هام

يتطلب TrackAvailability() إجراء استثمار مطور في كتابة التعليمات البرمجية المخصصة المعقدة المحتملة و maintanining.

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

تم تصميم هذا المثال فقط لإظهار آليات كيفية TrackAvailability() عمل استدعاء واجهة برمجة التطبيقات داخل تطبيق Azure Functions. لا يظهر كيفية كتابة رمز اختبار HTTP الأساسي أو منطق العمل المطلوب لتحويل هذا المثال إلى اختبار توفر وظيفي بالكامل.

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

مورد Application Insights إلى مساحة العمل
الوصول إلى التعليمات البرمجية المصدر لتطبيق Azure Functions
خبرة المطور في تأليف تعليمات برمجية مخصصة ل TrackAvailability()، مصممة خصيصا لاحتياجات عملك المحددة

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

إشعار

لاتباع هذه الإرشادات، يجب استخدام خطة App Service أو خطة Functions Premium للسماح بتحرير التعليمات البرمجية في App Service Editor.

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

إنشاء وظيفة تشغيل المؤقت

إنشاء مورد Azure Functions مع الاعتبار التالي:
- إذا لم يكن لديك مورد Application Insights حتى الآن للدالة التي يتم تشغيلها بواسطة المؤقت، يتم إنشاؤها بشكل افتراضي عند إنشاء تطبيق Azure Functions.
- إذا كان لديك بالفعل مورد Application Insights، فانتقل إلى علامة التبويب Monitoring أثناء إنشاء تطبيق Azure Functions، وحدد أو أدخل اسم المورد الموجود في القائمة المنسدلة Application Insights:
اتبع الإرشادات لإنشاء دالة مشغلة للموقت.

إضافة تعليمة برمجية وتحريرها في محرر خدمة التطبيقات

انتقل إلى تطبيق Azure Functions المنشور، وضمن أدوات التطوير، حدد علامة التبويب App Service Editor .

لإنشاء ملف جديد، انقر بزر الماوس الأيمن ضمن دالة مشغل المؤقت (على سبيل المثال، TimerTrigger1) وحدد New File. ثم أدخل اسم الملف وحدد Enter.

إنشاء ملف جديد يسمى function.proj ولصق التعليمات البرمجية التالية:

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>

إنشاء ملف جديد يسمى runAvailabilityTest.csx ولصق التعليمات البرمجية التالية:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

استبدل التعليمات البرمجية الموجودة في run.csx بالآتي:

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

إشعار

ستظهر الاختبارات التي تم إنشاؤها باستخدام TrackAvailability() CUSTOM بجوار اسم الاختبار.

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

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

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

الإعدادات	‏‏الوصف
في الوقت الحقيقي تقريبا	نوصي باستخدام تنبيهات في الوقت الفعلي تقريبا. يتم تكوين هذا النوع من التنبيه بعد إنشاء اختبار التوفر.
عتبة موقع التنبيه	نوصي بحد أدنى 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
Microsoft 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

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

إشعار

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

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

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

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

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

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

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

تلميح

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

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

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

إذا كنت بحاجة إلى قدرات متقدمة، يمكنك إنشاء قاعدة تنبيه مخصصة في علامة التبويب تنبيهات. حدد إنشاء>قاعدة تنبيه. اختر 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 .

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

ابدأ بمراجعة الرسم البياني في تجربة التوفر في مدخل Microsoft Azure.

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

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

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

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

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

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

تلميح

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

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

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

من هنا، يمكنك تنفيذ ما يلي:

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

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

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

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

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

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

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

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

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

هام

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

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

أي اختبار اتصال URL داخل Application Insights
الوصول إلى Azure PowerShell

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

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

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

Get-AzApplicationInsightsWebTest | `
Where-Object { $_.WebTestKind -eq "ping" } | `
Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;

ابحث عن اختبار اتصال URL الذي تريد ترحيله وسجل مجموعة الموارد واسمه.

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

$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);

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

تحقق من صحة وظيفة الاختبار القياسي الجديد، ثم قم بتحديث قواعد التنبيه التي تشير إلى اختبار اتصال عنوان URL للإشارة إلى الاختبار القياسي بدلا من ذلك.
تعطيل اختبار اتصال URL أو حذفه. للقيام بذلك باستخدام Azure PowerShell، يمكنك استخدام هذا الأمر:
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

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

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

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

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

تحذير

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

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

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

إنشاء سلسلة أبجدية رقمية بدون مسافات لتحديد اختبار التوفر هذا (على سبيل المثال، MyAppAvailabilityTest). من هنا فصاعدا، نشير إلى هذه السلسلة كمعرف سلسلة اختبار التوفر.
أضف العنوان المخصص X-Customer-InstanceId بالقيمة ApplicationInsightsAvailability:<your availability test string identifier> ضمن قسم معلومات الاختبار القياسية عند إنشاء اختبارات التوفر أو تحديثها.
تأكد من أن الخدمة تتحقق مما إذا كانت نسبة استخدام الشبكة الواردة تتضمن العنوان والقيمة المحددة في الخطوات السابقة.

بدلا من ذلك، قم بتعيين معرف سلسلة اختبار التوفر كمعلمة استعلام.

مثال: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

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

إشعار

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

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

إذا كنت تستخدم مجموعات أمان شبكة Azure، فانتقل إلى مورد مجموعة أمان الشبكة وضمن الإعدادات، افتح تجربة قواعد الأمان الواردة، ثم حدد إضافة.
بعد ذلك، حدد علامة الخدمة كمصدر وApplicationInsightsAvailability كعلامة خدمة المصدر. استخدم المنافذ المفتوحة 80 (http) و443 (https) لحركة المرور الواردة من علامة الخدمة.

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

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

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

قم بتوصيل مورد Application Insights بنقطة نهاية الخدمة الداخلية باستخدام Azure Private Link.
اكتب تعليمات برمجية مخصصة لاختبار الخادم الداخلي أو نقاط النهاية بشكل دوري. أرسل النتائج إلى 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 المدرجة ومنحنيات Elliptical لاختبارات توفر Application Insights.

TLS 1.0 وTLS 1.1

يتم إيقاف TLS 1.0 وTLS 1.1.

TLS 1.2 وTLS 1.3

إصدار	مجموعات التشفير	منحنيات بيضاوية
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 القديمة.

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

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

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

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

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

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

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

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: يمكن تشغيل جميع الاستعلامات في 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.

مشاركة عبر

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إهمال تكوين TLS

TLS 1.0 وTLS 1.1

TLS 1.2 وTLS 1.3

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

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

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

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

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

ميزات أخرى

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

عام

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

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

دعم TLS

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

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

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

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

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

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

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

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

الملاحظات

الموارد الإضافية