تمكنك Application Insights من إعداد اختبارات الويب المتكررة التي تراقب توفر موقعك على الويب أو التطبيق واستجابته من نقاط مختلفة حول العالم. ترسل اختبارات التوفر هذه طلبات الويب إلى التطبيق الخاص بك على فترات منتظمة وتنبيهك إذا كان التطبيق الخاص بك لا يستجيب أو إذا كان وقت الاستجابة بطيئا جدا.
لا تتطلب اختبارات التوفر أي تعديلات على موقع الويب أو التطبيق الذي تختبره. وهي تعمل لأي نقطة نهاية HTTP أو HTTPS يمكن الوصول إليها من الإنترنت العام، بما في ذلك واجهات برمجة تطبيقات REST التي تعتمد عليها خدمتك. وهذا يعني أنه يمكنك ليس فقط مراقبة التطبيقات الخاصة بك ولكن أيضا الخدمات الخارجية التي تعتبر ضرورية لوظائف التطبيق الخاص بك. يمكنك إنشاء ما يصل إلى 100 اختبار توافر لكل مورد Application Insights.
اختبار قياسي: نوع من اختبار التوفر الذي يتحقق من توفر موقع ويب عن طريق إرسال طلب واحد، على غرار اختبار اتصال 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 وافتح تجربة التوفر.
حدد Add Standard test من شريط التنقل العلوي.
أدخل اسم الاختبار وعنوان URL والإعدادات الأخرى الموضحة في الجدول التالي، ثم حدد إنشاء.
القسم
الإعدادات
الوصف
المعلومات الأساسية
عنوان URL
يمكن أن يكون عنوان URL أي صفحة ويب تريد اختبارها، ولكن يجب أن يكون مرئيا من الإنترنت العام. يمكن أن يتضمن عنوان URL سلسلة استعلام. لذلك، على سبيل المثال، يمكنك ممارسة قاعدة البيانات قليلاً. إذا تم حل عنوان URL لإعادة توجيه، فإننا نتابعه حتى 10 عمليات إعادة توجيه.
تحليل الطلبات التابعة
يطلب الاختبار الصور والبرامج النصية وملفات الأنماط والملفات الأخرى التي تعد جزءا من صفحة الويب قيد الاختبار. يتضمن وقت الاستجابة المسجل الوقت المستغرق للحصول على هذه الملفات. يفشل الاختبار إذا تعذر تنزيل أي من هذه الموارد بنجاح خلال المهلة المحددة للاختبار بأكمله. إذا لم يتم تحديد الخيار، فإن الاختبار يطلب فقط الملف في عنوان URL الذي حددته. يؤدي تمكين هذا الخيار إلى فحص أكثر صرامة. قد يفشل الاختبار للحالات، وهو ما قد لا يكون ملحوظا عند استعراض الموقع يدويا. نقوم بتحليل ما يصل إلى 15 طلبا تابعا فقط.
تمكين عمليات إعادة المحاولة لفشل اختبار التوفر
عندما يفشل الاختبار، فإنه يعيد المحاولة بعد فاصل زمني قصير. لا يتم الإبلاغ عن الفشل إلا إذا فشلت ثلاث محاولات متتالية. ثم تجرى الاختبارات اللاحقة على تكرار الاختبار المعتاد. يتم تعليق إعادة المحاولة مؤقتاً حتى النجاح التالي. يتم تطبيق هذه القاعدة بشكل مستقل في كل موقع اختبار. ننصح بهذا الخيار. في المتوسط، تختفي حوالي 80% من حالات الفشل عند إعادة المحاولة.
تمكين صلاحية شهادة SSL
يمكنك التحقق من شهادة SSL على موقع الويب الخاص بك للتأكد من أنها مثبّتة بشكل صحيح، وصحيحة، وموثوق بها، ولا تعطي أي أخطاء لأي من المستخدمين. سيتم إجراء التحقق من صحة شهادة SSL فقط على عنوان URL النهائي الذي تمت إعادة توجيهه.
فحص مدى الحياة الاستباقي
يتيح لك هذا الإعداد تحديد فترة زمنية محددة قبل انتهاء صلاحية شهادة SSL الخاصة بك. بعد انتهاء صلاحيته، سيفشل الاختبار الخاص بك.
تكرار الاختبار
تعيين عدد مرات تشغيل الاختبار من كل موقع اختبار. مع تكرار افتراضي من خمس دقائق وخمسة مواقع للاختبار، يتم اختبار موقعك في المتوسط كل دقيقة.
مواقع الاختبار
ترسل خوادمنا طلبات ويب إلى عنوان URL الخاص بك من هذه المواقع. الحد الأدنى لعدد مواقع الاختبار الموصى بها هو خمسة لضمان أنه يمكنك تمييز المشاكل في موقع الويب الخاص بك عن مشاكل الشبكة. يمكنك تحديد ما يصل إلى 16 موقعًا.
معلومات الاختبار القياسية
فعل طلب HTTP
حدد الإجراء الذي تريد اتخاذه مع طلبك.
نص الطلب
البيانات المخصصة المقترنة بطلب HTTP الخاص بك. يمكنك تحميل ملفاتك الخاصة أو إدخال المحتوى الخاص بك أو تعطيل هذه الميزة.
إضافة رؤوس مخصصة
أزواج القيمة الرئيسية التي تحدد معلمات التشغيل. يتم حجز عنواني "المضيف" و"عامل المستخدم" في اختبارات التوفر ولا يمكن تعديلهما أو الكتابة فوقهما.
معايير النجاح
مهلة الاختبار
إنقاص هذه القيمة ليتم التنبيه حول الاستجابات البطيئة. يتم احتساب الاختبار على أنه فشل إذا لم يتم تلقي الردود من موقعك خلال هذه الفترة. إذا قمت بتحديد تحليل الطلبات التابعة، يجب تلقي جميع الصور وملفات الأنماط والبرامج النصية والموارد التابعة الأخرى خلال هذه الفترة.
استجابة HTTP
تم حساب رمز الحالة الذي تم إرجاعه كنجاح. الرقم 200 هو التعليمات البرمجية التي تشير إلى إرجاع صفحة ويب عادية.
مطابقة المحتوى
سلسلة، مثل «Welcome!» نحن نختبر حدوث تطابق دقيق لحالة الأحرف في كل استجابة. يجب أن تكون سلسلة عادية بدون أحرف البدل. لا تنسَ أنه إذا تغير محتوى صفحتك فقد تضطر إلى تحديثه. يتم اعتماد الأحرف الإنجليزية فقط مع مطابقة المحتوى.
هام
يتطلب TrackAvailability() إجراء استثمار مطور في كتابة التعليمات البرمجية المخصصة المعقدة المحتملة و maintanining.
يجب دائما استخدام الاختبارات القياسية إذا كان ذلك ممكنا، لأنها تتطلب القليل من الاستثمار، وعدم الصيانة، ولديها متطلبات أساسية قليلة.
تم تصميم هذا المثال فقط لإظهار آليات كيفية TrackAvailability() عمل استدعاء واجهة برمجة التطبيقات داخل تطبيق Azure Functions. لا يظهر كيفية كتابة رمز اختبار HTTP الأساسي أو منطق العمل المطلوب لتحويل هذا المثال إلى اختبار توفر وظيفي بالكامل.
إذا لم يكن لديك مورد 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، مع ما لا يقل عن خمسة مواقع اختبار.
مع التنبيهات الموحدة الجديدة، يجب تكوين شدة قاعدة التنبيه وتفضيلات الإعلام باستخدام مجموعات الإجراءات في تجربة التنبيهات. بدون الخطوات التالية، ستتلقى فقط إعلامات في المدخل.
بعد حفظ اختبار التوفر، افتح قائمة السياق حسب الاختبار الذي أجريته، ثم حدد صفحة Open Rules (Alerts).
في صفحة قواعد التنبيه، افتح التنبيه، ثم حدد تحرير في شريط التنقل العلوي. هنا يمكنك تعيين مستوى الخطورة ووصف القاعدة ومجموعة الإجراءات التي تحتوي على تفضيلات الإعلام التي تريد استخدامها لقاعدة التنبيه هذه.
معايير التنبيه
تؤدي تنبيهات التوفر الممكنة تلقائيا إلى تشغيل بريد إلكتروني واحد عندما تصبح نقطة النهاية غير متوفرة، وبريد إلكتروني آخر عند توفرها مرة أخرى. تستند تنبيهات التوفر التي تم إنشاؤها من خلال هذه التجربة إلى الحالة. عند استيفاء معايير التنبيه، يتم إنشاء تنبيه واحد عند اكتشاف موقع الويب على أنه غير متوفر. إذا كان موقع الويب لا يزال معزولا في المرة التالية التي يتم فيها تقييم معايير التنبيه، فلن ينشئ تنبيها جديدا.
على سبيل المثال، افترض أن موقع الويب الخاص بك معطلة لمدة ساعة وقمت بإعداد تنبيه عبر البريد الإلكتروني بتردد تقييم يبلغ 15 دقيقة. لا تتلقى رسالة بريد إلكتروني إلا عندما يتعطل موقع الويب وبريد إلكتروني آخر عندما يعود عبر الإنترنت. لا تتلقى تنبيهات مستمرة كل 15 دقيقة لتذكيرك بأن موقع الويب لا يزال غير متوفر.
تغيير معايير التنبيه
قد لا ترغب في تلقي إعلامات عندما يكون موقع الويب الخاص بك متعطلا لفترة قصيرة فقط، على سبيل المثال، أثناء الصيانة. يمكنك تغيير تكرار التقييم إلى قيمة أعلى من وقت التعطل المتوقع، حتى 15 دقيقة. يمكنك أيضا زيادة حد موقع التنبيه بحيث يؤدي فقط إلى تشغيل تنبيه إذا كان موقع الويب معزولا لعدد معين من المناطق.
تلميح
بالنسبة لأطول أوقات تعطل مجدولة، قم بإلغاء تنشيط قاعدة التنبيه مؤقتا أو إنشاء قاعدة مخصصة. يمنحك المزيد من الخيارات لحساب وقت التعطل.
لإجراء تغييرات على حد الموقع وفترة التجميع وتكرار الاختبار، انتقل إلى صفحة تحرير قاعدة التنبيه (راجع الخطوة 2 ضمن تمكين التنبيهات)، ثم حدد الشرط لفتح نافذة تكوين منطق الإشارة.
إنشاء قاعدة تنبيه مخصصة
إذا كنت بحاجة إلى قدرات متقدمة، يمكنك إنشاء قاعدة تنبيه مخصصة في علامة التبويب تنبيهات. حدد إنشاء>قاعدة تنبيه. اختر Metrics for Signal type لإظهار جميع الإشارات المتوفرة وحدد Availability.
توفر قاعدة التنبيه المخصصة قيما أعلى لفترة التجميع (حتى 24 ساعة بدلا من 6 ساعات) وتكرار الاختبار (حتى ساعة واحدة بدلا من 15 دقيقة). كما يضيف خيارات لتعريف المنطق بشكل أكبر عن طريق تحديد عوامل تشغيل وأنواع تجميع مختلفة وقيم الحد.
تنبيه على X من مواقع Y الإبلاغ عن حالات الفشل: يتم تمكين قاعدة تنبيه X من مواقع Y بشكل افتراضي في تجربة التنبيهات الموحدة الجديدة عند إنشاء اختبار توفر جديد. يمكنك إلغاء الاشتراك عن طريق تحديد الخيار "الكلاسيكي" أو عن طريق اختيار تعطيل قاعدة التنبيه. تكوين مجموعات الإجراءات لتلقي الإعلامات عند تشغيل التنبيه باتباع الخطوات السابقة. بدون هذه الخطوة، ستتلقى إعلامات في المدخل فقط عند تشغيل القاعدة.
تنبيه حول مقاييس التوفر: باستخدام التنبيهات الموحدة الجديدة، يمكنك التنبيه بشأن التوفر المجمع المقسم ومقاييس مدة الاختبار أيضا:
حدد مورد Application Insights في تجربة المقاييس ، وحدد مقياس التوفر .
ينقلك خيار تكوين التنبيهات من القائمة إلى التجربة الجديدة حيث يمكنك تحديد اختبارات أو مواقع معينة لإعداد قواعد التنبيه عليها. يمكنك أيضاً تكوين مجموعات العمل لقاعدة التنبيه هذه هنا.
تنبيه على استعلامات التحليلات المخصصة: باستخدام التنبيهات الموحدة الجديدة، يمكنك التنبيه على استعلامات السجل المخصصة. باستخدام الاستعلامات المخصصة، يمكنك التنبيه بشأن أي حالة عشوائية تساعدك في الحصول على الإشارة الأكثر موثوقية حول مشكلات التوفر. ينطبق أيضا إذا كنت ترسل نتائج توفر مخصصة باستخدام TrackAvailability SDK.
تتضمن المقاييس على بيانات التوفر أي نتائج توفر مخصصة قد تقوم بإرسالها عن طريق استدعاء TrackAvailability SDK. يمكنك استخدام التنبيه على دعم المقاييس للتنبيه بنتائج التوفر المخصصة.
يشرح هذا القسم كيفية مراجعة نتائج اختبار التوفر في مدخل 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 حتى تتمكن من الاستمرار في الاعتماد عليه للتنبيهات.
تحقق من صحة وظيفة الاختبار القياسي الجديد، ثم قم بتحديث قواعد التنبيه التي تشير إلى اختبار اتصال عنوان URL للإشارة إلى الاختبار القياسي بدلا من ذلك.
تعطيل اختبار اتصال URL أو حذفه. للقيام بذلك باستخدام Azure PowerShell، يمكنك استخدام هذا الأمر:
لضمان توفر نقطة النهاية خلف جدران الحماية، قم بتمكين اختبارات التوفر العام أو تشغيل اختبارات التوفر في سيناريوهات غير متصلة أو بدون دخول.
تمكين اختبار التوفر العام
تأكد من أن موقع الويب الداخلي الخاص بك يحتوي على سجل نظام أسماء المجالات العامة (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.
في 1 مايو 2025، تماشيا مع إيقاف TLS القديم على نطاق Azure، سيتم إيقاف إصدارات بروتوكول TLS 1.0/1.1 وTLS 1.2/1.3 القديمة والمنحنيات Elliptical المدرجة لاختبارات توفر Application Insights.
لقد قمنا مؤخرا بتمكين 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 هو محدد التاريخ والوقت لفترة صيانة مثال. يتم تجاهل جميع البيانات التي تحدث أثناء الفترة المحددة في نتائجك.
تحتوي صفحة النظرة العامة على معلومات عالية المستوى حول:
إجمالي اتفاقية مستوى الخدمة (باستثناء فترات الصيانة، إذا تم تعريفها)
مثيلات الانقطاع من طرف إلى طرف
وقت تعطل التطبيق
يتم تحديد مثيلات الانقطاع من اللحظة التي يبدأ فيها الاختبار في الفشل حتى يمر بنجاح مرة أخرى، وفقا لمعلمات الانقطاع. إذا بدأ الاختبار بالفشل في الساعة 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 المطلوب على خادم الويب الخاص بك، من الأفضل التواصل مع الفريق الذي يمتلك النظام الأساسي للاستضافة الذي يعمل عليه خادم الويب إذا لم تكن العملية معروفة.
بعد 1 مايو 2025، ماذا سيكون سلوك اختبار الويب للاختبارات المتأثرة؟
لا يوجد نوع استثناء واحد ستقدم به جميع حالات فشل تأكيد اتصال TLS المتأثرة بهذا الإهمال. ومع ذلك، فإن الاستثناء الأكثر شيوعا الذي سيبدأ اختبار الويب الخاص بك بفشله سيكون The request was aborted: Couldn't create SSL/TLS secure channel. يجب أن تكون قادرا أيضا على رؤية أي حالات فشل متعلقة ب TLS في خطوة استكشاف أخطاء TLS Transport وإصلاحها لنتيجة اختبار الويب التي قد تتأثر.
هل يمكنني عرض تكوين TLS المستخدم حاليا بواسطة اختبار الويب الخاص بي؟
لا يمكن عرض تكوين TLS الذي تم التفاوض عليه أثناء تنفيذ اختبار الويب. طالما أن نقطة النهاية البعيدة تدعم تكوين TLS الشائع مع اختبارات التوفر، فلا ينبغي رؤية أي تأثير بعد الإهمال.
ما المكونات التي يؤثر عليها الإهمال في خدمة اختبار التوفر؟
يجب أن يؤثر إهمال TLS المفصل في هذا المستند فقط على سلوك تنفيذ اختبار اختبار الويب لاختبار التوفر بعد 1 مايو 2025. لمزيد من المعلومات حول التفاعل مع خدمة اختبار التوفر لعمليات CRUD، راجع Azure Resource Manager TLS Support. يوفر هذا المورد المزيد من التفاصيل حول المخططات الزمنية لدعم TLS والإهمال.
أين يمكنني الحصول على دعم TLS؟
للحصول على أي أسئلة عامة حول مشكلة TLS القديمة، راجع حل مشكلات TLS.