مراقبة مثيلات App Service باستخدام التحقق من الصحة

إشعار

بدءا من 1 يونيو 2024، سيكون لجميع تطبيقات App Service التي تم إنشاؤها حديثا خيار إنشاء اسم مضيف افتراضي فريد باستخدام اصطلاح <app-name>-<random-hash>.<region>.azurewebsites.netالتسمية . ستظل أسماء التطبيقات الحالية دون تغيير.

مثال: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

لمزيد من التفاصيل، راجع اسم المضيف الافتراضي الفريد لمورد App Service.

تستخدم هذه المقالة التحقق من الصحة في مدخل Microsoft Azure لمراقبة مثيلات App Service. يزيد التحقق من الصحة من توفر التطبيق الخاص بك عن طريق إعادة توجيه الطلبات بعيدا عن المثيلات غير الصحية واستبدال المثيلات إذا ظلت غير صحية. وهو يفعل ذلك عن طريق اختبار اتصال كل دقيقة مسار تطبيق الويب الخاص بك من اختيارك.

لاحظ أن /api/health هو مجرد مثال مضاف لأغراض التوضيح. لا نقوم بإنشاء مسار Health Check بشكل افتراضي. يجب التأكد من أن المسار الذي تحدده هو مسار صالح موجود داخل التطبيق الخاص بك

ما تفعله App Service مع عمليات التحقق من الصحة

• عند إعطاء مسار على التطبيق، يتحقق Health من تنفيذ هذا المسار على جميع مثيلات تطبيق خدمة التطبيقات على فترات دقيقة واحدة.
• إذا لم يستجب تطبيق ويب يعمل على مثيل معين برمز الحالة بين 200-299 (شامل) بعد 10 طلبات، فإن App Service تحدد أنه غير سليم وتزيله من موازن التحميل لتطبيق الويب هذا. العدد المطلوب من الطلبات الفاشلة لمثيل يعتبر غير سليم قابل للتكوين إلى طلبين كحد أدنى.
• بعد الإزالة، يستمر فحص الصحة في اختبار اتصال المثيل غير السليم. إذا بدأ المثيل في الاستجابة برمز الحالة الصحية (200-299)، إرجاع المثيل إلى موازن التحميل.
• إذا ظل تطبيق الويب الذي يعمل على مثيل غير سليم لمدة ساعة واحدة، يتم استبدال المثيل بأخرى جديدة.
• عند التوسع، تقوم App Service باختبار الاتصال على مسار التحقق من الصحة للتأكد من أن المثيلات الجديدة جاهزة.

إشعار

• التحقق من الصحة لا يتبع عمليات إعادة التوجيه 302.
• سيتم استبدال مثيل واحد على الأكثر في الساعة، بثلاثة مثيلات كحد أقصى في اليوم لكل خطة App Service.
• إذا كان فحص السلامة يعطي الحالة Waiting for health check response، فمن المحتمل أن يفشل الفحص بسبب رمز حالة HTTP 307، والذي يمكن أن يحدث إذا كان لديك إعادة توجيه HTTPS ممكنة ولكن تم HTTPS Only تعطيلها.

تمكين التحقق من الصحة

1. لتمكين التحقق من الصحة، استعرض للوصول إلى مدخل Microsoft Azure وحدد تطبيق App Service.
2. ضمن Monitoring، حدد Health check.
3. حدد تمكين وقدم مسار URL صالحاً على التطبيق الخاص بك، مثل /health أو /api/health.
4. حدد حفظ.

إشعار

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

تنبيه

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

التكوين

بالإضافة إلى تكوين خيارات التحقق من الصحة، يمكنك أيضاً تكوين إعدادات التطبيق التالية:

اسم إعداد التطبيق	القيم المسموح بها	‏‏الوصف
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	العدد المطلوب من الطلبات الفاشلة لمثيل ما ليتم اعتباره غير صحي وإزالته من موازن التحميل. على سبيل المثال، عند التعيين إلى 2، تتم إزالة المثيلات الخاصة بك بعد 2 فشل اختبار الاتصال. (القيمة الافتراضية هي 10)
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	بشكل افتراضي، لن يتم استبعاد أكثر من نصف المثيلات من موازن التحميل في وقت واحد لتجنب غمر المثيلات الصحية المتبقية. على سبيل المثال، إذا تم تحجيم خطة خدمة التطبيقات إلى أربعة مثيلات وثلاثة غير سليمة، يتم استبعاد اثنين. ولا يزال المثيلان الآخران (أحدهما سليم والآخر غير سليم) يتلقىان الطلبات. في أسوأ سيناريو حيث تكون جميع المثيلات غير صحية، لا يتم استبعاد أي منها. لتجاوز هذا السلوك، قم بتعيين إعداد التطبيق إلى قيمة بين 1 و100. تعني القيمة الأعلى إزالة مثيلات أكثر غير صحية (القيمة الافتراضية هي 50).

المصادقة والأمان

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

إذا كنت تستخدم نظام المصادقة الخاص بك، يجب أن يسمح مسار التحقق من الصحة بالوصول المجهول. لتأمين نقطة نهاية التحقق من الصحة، يجب عليك أولاً استخدام ميزات مثل قيود IP، أو شهادات العميل، أو شبكة افتراضية لتقييد الوصول إلى التطبيق. بمجرد أن تكون لديك هذه الميزات قيد التشغيل، يمكنك مصادقة طلب التحقق من الصحة عن طريق فحص الرأس، x-ms-auth-internal-token، والتحقق من أنه يطابق تجزئة SHA256 لمتغير البيئة WEBSITE_AUTH_ENCRYPTION_KEY. إذا كانا متطابقين، فإن طلب التحقق من الصحة صالح وينشأ من App Service.

إشعار

على وجه التحديد لمصادقة Azure Functions، تحتاج الدالة التي تعمل كنقطة نهاية التحقق من الصحة إلى السماح بالوصول المجهول.

NET.

using System;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
    var sha = System.Security.Cryptography.SHA256.Create();
    String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return hash == headerValue;
}

Python

from hashlib import sha256
import base64
import os

def header_matches_env_var(header_value):
    """
    Returns true if SHA256 of header_value matches WEBSITE_AUTH_ENCRYPTION_KEY.
    
    :param header_value: Value of the x-ms-auth-internal-token header.
    """
    
    env_var = os.getenv('WEBSITE_AUTH_ENCRYPTION_KEY')
    hash = base64.b64encode(sha256(env_var.encode('utf-8')).digest()).decode('utf-8')
    return hash == header_value

Java

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import java.nio.charset.StandardCharsets;

public static Boolean headerMatchesEnvVar(String headerValue) throws NoSuchAlgorithmException {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    String envVar = System.getenv("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = new String(Base64.getDecoder().decode(digest.digest(envVar.getBytes(StandardCharsets.UTF_8))));
    return hash.equals(headerValue);
}

Node.js

var crypto = require('crypto');

function envVarMatchesHeader(headerValue) {
    let envVar = process.env.WEBSITE_AUTH_ENCRYPTION_KEY;
    let hash = crypto.createHash('sha256').update(envVar).digest('base64');
    return hash == headerValue;
}

إشعار

x-ms-auth-internal-token لا يتوفر العنوان إلا على Windows App Service.

المثيلات

بمجرد تمكين Health Check، يمكنك إعادة تشغيل حالة مثيلات التطبيق ومراقبتها من خلال علامة تبويب المثيلات. تعرض علامة تبويب المثيلات اسم المثيل وحالة مثيل هذا التطبيق وتمنحك خيار إعادة تشغيل المثيل يدويا.

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

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

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

جمع المعلومات التشخيصية

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

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

مراقبة‬

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

القيود

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

الأسئلة المتداولة

ماذا يحدث إذا كان تطبيقي يعمل على مثيل واحد؟

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

لماذا لا تظهر طلبات فحص الحالة في سجلات خادم الويب؟

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

هل يتم إرسال طلبات التحقق من الصحة عبر HTTP أو HTTPS؟

في Windows وLinux App Service، يتم إرسال طلبات التحقق من الصحة عبر HTTPS عند تمكين HTTPS فقط على الموقع. وإلا، يتم إرسالها عبر HTTP.

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

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

ماذا لو كان لديّ تطبيقات متعددة على نفس خطة App Service؟

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

مثال

تخيل أن لديك تطبيقين (أو تطبيق واحد مع فتحة) مع تمكين التحقق من الصحة، يسمى التطبيق A والتطبيق B. إنهم على نفس خطة App Service وأن الخطة تم توسيع نطاقها إلى أربعة مثيلات. إذا أصبح التطبيق A غير صحي على مثيلين، يتوقف موازن التحميل عن إرسال الطلبات إلى التطبيق A على هذين المثيلين. لا تزال الطلبات توجه إلى التطبيق B على تلك المثيلات بافتراض أن التطبيق B سليم. إذا ظل التطبيق A غير سليم لأكثر من ساعة على هذين المثيلين، يتم استبدال هذه المثيلات فقط إذا كان التطبيق B غير صحي أيضا على هاتين المثيلتين. إذا كان التطبيق B سليما، فلن يتم استبدال المثيل.

إشعار

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

ماذا لو كانت جميع مثيلاتي غير صحية؟

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

هل يعمل التحقق من الصحة على بيئات خدمة التطبيقات؟

نعم، يتوفر فحص السلامة لـ App Service Environment v3، ولكن ليس للإصدارات 1 أو 2. إذا كنت تستخدم الإصدارات الأقدم من App Service Environment، يمكنك استخدام ميزة الترحيل لترحيل App Service Environment إلى الإصدار 3.

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

• قم بإنشاء تنبيه سجل النشاط لمراقبة جميع عمليات محرك مقياس تلقائي في اشتراكك
• إنشاء تنبيه سجل النشاط لمراقبة جميع عمليات تكبير/تصغير الحجم على اشتراكك
• متغيرات البيئة ومرجع إعدادات التطبيق