موازنة الحمل عبر خوادم الخلفية

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

تعزّز Apigee Edge إمكانية توفّر واجهة برمجة التطبيقات من خلال توفير دعم مدمج لموازنة الحمل والتبديل الاحتياطي على مستوى مثيلات خادم خلفية متعددة.

تعمل إعدادات TargetServer على فصل عناوين URL المحدّدة لنقاط النهاية عن إعدادات TargetEndpoint. تتم الإشارة إلى كل TargetServer بالاسم في TargetEndpoint HTTPConnection. بدلاً من تحديد عنوان URL ملموس في الإعدادات، يمكنك ضبط خادم واحد أو أكثر من خوادم TargetServer المسماة كما هو موضّح في القسم TargetEndpoint.

يتألف تعريف TargetServer من اسم ومضيف ومنفذ، مع عنصر إضافي للإشارة إلى ما إذا كان TargetServer مفعّلاً أو غير مفعّل.

الفيديوهات

شاهِد الفيديوهات التالية لمعرفة المزيد حول توجيه طلبات البيانات إلى واجهة برمجة التطبيقات وموازنة التحميل باستخدام الخوادم المستهدَفة

مثال على إعداد TargetServer

يحدّد الرمز التالي خادمًا مستهدفًا:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

عناصر إعدادات TargetServer

يوضّح الجدول التالي العناصر المستخدَمة لإنشاء TargetServer وضبط إعداداته:

إدارة الخوادم المستهدَفة باستخدام واجهة المستخدم

إدارة الخوادم المستهدَفة، كما هو موضّح أدناه.

إدارة الخوادم المستهدَفة باستخدام واجهة برمجة التطبيقات

يمكنك استخدام Edge API لإنشاء الخوادم المستهدَفة وحذفها وتعديلها والحصول عليها وإدراجها. لمزيد من المعلومات، راجِع TargetServers.

استخدِم طلب بيانات من واجهة برمجة التطبيقات التالي لإنشاء خادم مستهدف:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

نموذج الردّ:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

بعد إنشاء TargetServer الأول، استخدِم طلب بيانات من واجهة برمجة التطبيقات التالي لإنشاء TargetServer ثانٍ. من خلال تحديد TargetServerَين، يمكنك توفير عنوانَي URL يمكن أن يستخدمهما TargetEndpoint لموازنة الحمل:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

نموذج الردّ:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

استخدِم طلب بيانات من واجهة برمجة التطبيقات التالي لاسترداد قائمة بـ TargetServers في بيئة معيّنة:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

نموذج إجابة:

[ "target2", "target1" ]

يتوفّر الآن خادما TargetServer يمكن استخدامهما من خلال خوادم وكيلة لواجهة برمجة التطبيقات تم نشرها في بيئة الاختبار. لموازنة الحمل على مستوى هذه الخوادم TargetServer، عليك ضبط اتصال HTTP في نقطة نهاية الهدف الخاصة بخادم وكيل API لاستخدام الخوادم TargetServer.

يبلغ الحدّ الأقصى لعدد TargetServers لكل بيئة 500، كما هو موضّح في موضوع الحدود.

ضبط TargetEndpoint لموازنة الحمل على مستوى TargetServers المسماة

بعد توفّر خادمتَي TargetServer، يمكنك تعديل إعداد اتصال HTTP الخاص بـ TargetEndpoint للإشارة إلى هاتين الخادمتَين بالاسم:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

الإعدادات أعلاه هي أبسط إعدادات لموازنة الحمل. يتيح جهاز موازنة الحمل ثلاث خوارزميات لموازنة الحمل، وهي Round Robin وWeighted وLeast Connection. خوارزمية Round Robin هي الخوارزمية التلقائية. بما أنّه لم يتم تحديد أي خوارزمية في الإعدادات أعلاه، سيتم بالتناوب إرسال الطلبات الصادرة من خادم وكيل واجهة برمجة التطبيقات إلى خوادم الخلفية، طلب واحد لكل خادم، بين target1 وtarget2.

يشكّل العنصر <Path> مسار basepath الخاص بمعرّف الموارد المنتظم (URI) الخاص بـ TargetEndpoint لجميع الخوادم المستهدَفة. يتم استخدامها فقط عند استخدام <LoadBalancer>. وإلا، سيتم تجاهله. في المثال أعلاه، سيتم http://target1/test الطلب الذي يصل إلى "target1"، وينطبق الأمر نفسه على خوادم الاستهداف الأخرى.

ضبط خيارات موازنة الحمل

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

خوارزمية

تُحدّد هذه السمة الخوارزمية التي تستخدمها <LoadBalancer>. الخوارزميات المتاحة هي RoundRobin وWeighted وLeastConnections، وتم توثيق كل منها أدناه.

جولة الدوري بين جميع اللاعبين

تعمل الخوارزمية التلقائية، وهي التوزيع بالتناوب، على إعادة توجيه الطلب إلى كل TargetServer بالترتيب الذي يتم به إدراج الخوادم في اتصال HTTP لنقطة النهاية المستهدَفة. على سبيل المثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

موزون

تتيح لك خوارزمية موازنة الحمل المرجّحة ضبط أحجام زيارات متناسبة مع TargetServer. يوزّع LoadBalancer المرجّح الطلبات على TargetServers بما يتناسب طرديًا مع وزن كل TargetServer. لذلك، تتطلّب الخوارزمية المرجّحة منك ضبط السمة weight لكل TargetServer. على سبيل المثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

في هذا المثال، سيتم توجيه طلبَين إلى target2 مقابل كل طلب يتم توجيهه إلى target1.

Least Connection

توجّه موازنات التحميل التي تم إعدادها لاستخدام خوارزمية أقل اتصال الطلبات الصادرة إلى TargetServer الذي يتضمّن أقل عدد من اتصالات HTTP المفتوحة. على سبيل المثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

الحدّ الأقصى لعدد الأخطاء

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

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

ومع ذلك، عندما تتلقّى Apigee استجابة من هدف، حتى إذا كانت الاستجابة عبارة عن خطأ HTTP (مثل 500)، يتم احتساب ذلك كاستجابة من خادم الهدف، وتتم إعادة ضبط عدّاد حالات الفشل. للمساعدة في ضمان أنّ استجابات HTTP غير الصالحة (مثل 500) تزيد أيضًا من عدّاد الأخطاء لإزالة الخادم غير السليم من عملية موازنة الحمل في أقرب وقت ممكن، يمكنك إضافة العنصر <ServerUnhealthyResponse> مع العناصر الفرعية <ResponseCode> إلى إعدادات موازنة الحمل. سيحتسب Edge أيضًا الردود التي تتضمّن هذه الرموز على أنّها حالات تعذّر.

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

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

القيمة التلقائية لـ MaxFailures هي 0. وهذا يعني أنّ Edge يحاول دائمًا الاتصال بالهدف لكل طلب ولا يزيل خادم الهدف من التناوب أبدًا.

من الأفضل استخدام MaxFailures > 0 مع HealthMonitor. إذا ضبطت MaxFailures > 0، تتم إزالة TargetServer من التناوب عندما يتعذّر الوصول إلى الهدف لعدد المرات الذي تحدّده. عندما يكون HealthMonitor في مكانه، تضع Apigee تلقائيًا TargetServer مرة أخرى في التناوب بعد أن يصبح الهدف جاهزًا للعمل مرة أخرى، وذلك وفقًا لإعدادات HealthMonitor. لمزيد من المعلومات، اطّلِع على مراقبة السلامة.

بدلاً من ذلك، إذا ضبطت MaxFailures > 0 ولم تضبط أداة مراقبة السلامة، ستزيل Apigee خادم الخلفية تلقائيًا من عملية التناوب عند رصد أول خطأ. ستتحقّق Apigee من حالة الخادم المستهدف كل خمس دقائق، وستعيد إدراجه في عملية التناوب عندما يستجيب بشكل طبيعي.

إعادة المحاولة

في حال تفعيل خيار إعادة المحاولة، ستتم إعادة محاولة إرسال الطلب كلما حدث تعذُّر في الاستجابة (خطأ في الإدخال/الإخراج أو انتهاء مهلة HTTP) أو تطابقت الاستجابة التي تم تلقّيها مع قيمة تم ضبطها بواسطة <ServerUnhealthyResponse>. راجِع القسم الحد الأقصى لعدد الأخطاء أعلاه للحصول على مزيد من المعلومات حول ضبط <ServerUnhealthyResponse>.

يتم ضبط <RetryEnabled> تلقائيًا على true. اضبط القيمة على false لإيقاف إعادة المحاولة. على سبيل المثال:

<RetryEnabled>false</RetryEnabled>

IsFallback

يمكن ضبط TargetServer واحد (واحد فقط) كخادم "احتياطي". لا يتم تضمين TargetServer الاحتياطي في إجراءات موازنة التحميل إلى أن يحدّد موازن التحميل أنّ جميع TargetServer الأخرى غير متاحة. عندما يحدّد موازن التحميل أنّ جميع TargetServers غير متاحة، يتم توجيه جميع الزيارات إلى الخادم الاحتياطي. على سبيل المثال:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

يؤدي الإعداد أعلاه إلى موازنة التحميل بالتناوب بين الهدفَين 1 و2 إلى أن يصبح الهدفان 1 و2 غير متاحَين. عندما يتعذّر الوصول إلى الهدفَين 1 و2، يتم توجيه كل الزيارات إلى الهدف 3.

المسار

يحدّد المسار جزءًا من معرّف الموارد المنتظم (URI) سيتم إلحاقه بجميع الطلبات التي يصدرها TargetServer إلى خادم الخلفية.

يقبل هذا العنصر مسار سلسلة حرفية أو نموذج رسالة. يتيح لك نموذج الرسالة استبدال السلسلة المتغيرة في وقت التشغيل. على سبيل المثال، في تعريف نقطة النهاية المستهدَفة التالي، يتم استخدام قيمة {mypath} للمسار:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

ضبط خادم مستهدف لبروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL)

إذا كنت تستخدم TargetServer لتحديد خدمة الخلفية، وكانت خدمة الخلفية تتطلّب أن يستخدم الاتصال بروتوكول HTTPS، عليك تفعيل بروتوكول أمان طبقة النقل (TLS) أو بروتوكول SSL في تعريف TargetServer. هذا الإجراء ضروري لأنّ العلامة <Host> لا تتيح لك تحديد بروتوكول الاتصال. في ما يلي تعريف TargetServer لطبقة النقل الآمنة/طبقة المقابس الآمنة (TLS/SSL) أحادية الاتجاه حيث يرسل Edge طلبات HTTPS إلى خدمة الخلفية:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

إذا كانت خدمة الخلفية تتطلّب بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) ثنائي الاتجاه أو متبادلاً، عليك إعداد TargetServer باستخدام إعدادات بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) نفسها المستخدَمة في TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

للحصول على معلومات حول خصائص <SSLInfo>، مثل <Ciphers> و<ClientAuthEnabled>، راجِع المعلومات حول ضبط هذه الخصائص لمضيف افتراضي في ضبط الوصول إلى واجهة برمجة التطبيقات باستخدام بروتوكول أمان طبقة النقل (TLS) في السحابة الخاصة.

للحصول على تعليمات كاملة حول إعداد بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) الصادر، يُرجى الاطّلاع على إعداد بروتوكول أمان طبقة النقل (TLS) من Edge إلى الخلفية (السحابة الإلكترونية والسحابة الإلكترونية الخاصة).

مخطط TargetServer

يمكنك الاطّلاع على المخطط الخاص بـ TargetServer والكيانات الأخرى على GitHub.

مراقبة الحالة الصحية

تتيح لك مراقبة السلامة تحسين إعدادات موازنة الحمل من خلال البحث بشكل نشط عن عناوين URL الخاصة بالخدمة الخلفية المحدّدة في إعدادات TargetServer. عند تفعيل مراقبة الصحة، يتم تلقائيًا إعادة TargetServer الذي تعذّر الوصول إليه إلى قائمة الخوادم المتاحة عندما تحدّد HealthMonitor أنّ TargetServer نشط.

تعمل ميزة "مراقبة الحالة الصحية" مع <MaxFailures>. بدون تفعيل مراقبة السلامة، تحدّد <MaxFailures> عدد الطلبات التي تعذّر تنفيذها من خادم وكيل واجهة برمجة التطبيقات إلى TargetServer، ما يؤدي إلى إعادة توجيه الطلب إلى TargetServer آخر. بعد ذلك، تتم إزالة TargetServer الذي تعذّر الوصول إليه من عملية التناوب إلى أن تعيد نشر الخادم الوكيل.

عند تفعيل ميزة مراقبة الصحة، تتم إعادة TargetServer الذي تعذّر الوصول إليه تلقائيًا إلى عملية التناوب، ولا يلزم إعادة نشر أي وكيل.

يعمل HealthMonitor كعميل بسيط يستدعي خدمة خلفية عبر TCP أو HTTP:

• يضمن برنامج TCP العميل إمكانية فتح مقبس توصيل.
• عليك ضبط برنامج HTTP لإرسال طلب HTTP صالح إلى خدمة الخلفية. يمكنك تحديد عمليات HTTP GET أو PUT أو POST أو DELETE. يجب أن تتطابق استجابة طلب مراقبة HTTP مع الإعدادات التي تم ضبطها في الحظر <SuccessResponse>.

النجاحات والإخفاقات

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

يمكن أن يكون لعملية التحقّق من الصحة إحدى النتيجتَين المحتملتَين:

• ناجح: يُعدّ الخادم المستهدف سليمًا عند إجراء عملية التحقّق من السلامة بنجاح. ويحدث ذلك عادةً نتيجة لأحد الأسباب التالية أو أكثر:
  • يقبل الخادم المستهدف اتصالاً جديدًا بالمنفذ المحدّد، ويستجيب لطلب على هذا المنفذ، ثم يغلق المنفذ خلال الإطار الزمني المحدّد. تحتوي الاستجابة من الخادم المستهدف على "Connection: close"
  • يستجيب الخادم المستهدف لطلب التحقّق من الصحة برمز حالة HTTP 200 (موافق) أو رمز حالة HTTP آخر تحدّده على أنّه مقبول.
  • يستجيب الخادم المستهدف لطلب التحقّق من السلامة من خلال نص رسالة يتطابق مع نص الرسالة المتوقّع.

  عندما يحدّد Edge أنّ الخادم سليم، يواصل إرسال الطلبات إليه أو يستأنف إرسالها.

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

  عندما يتعذّر على خادم مستهدف اجتياز عملية التحقّق من الصحة، يزيد Edge عدد مرات تعذُّر هذا الخادم. إذا كان عدد حالات التعذّر لهذا الخادم يبلغ الحدّ الأدنى المحدّد مسبقًا أو يتجاوزه (<MaxFailures>)، يتوقف Edge عن إرسال الطلبات إلى هذا الخادم.

تفعيل HealthMonitor

لإنشاء HealthMonitor، عليك إضافة العنصر <HealthMonitor> إلى إعداد HTTPConnection الخاص بـ TargetEndpoint في خادم وكيل. لا يمكنك إجراء ذلك في واجهة المستخدم. بدلاً من ذلك، يمكنك إنشاء إعدادات خادم وكيل وتحميلها كملف ZIP إلى Edge. إعدادات الخادم الوكيل هي وصف منظَّم لجميع جوانب خادم وكيل لواجهة برمجة التطبيقات. تتألف إعدادات الخادم الوكيل من ملفات XML في بنية دليل محددة مسبقًا. لمزيد من المعلومات، يُرجى الاطّلاع على مرجع إعداد خادم وكيل لواجهة برمجة التطبيقات.

يحدّد HealthMonitor بسيط IntervalInSec مع TCPMonitor أو HTTPMonitor. يحدّد العنصر <MaxFailures> الحد الأقصى لعدد الطلبات التي تعذّر تنفيذها من خادم وكيل لواجهة برمجة التطبيقات إلى TargetServer، ما يؤدي إلى إعادة توجيه الطلب إلى TargetServer آخر. القيمة التلقائية لـ <MaxFailures> هي 0، ما يعني أنّ Edge لا يتّخذ أي إجراء تصحيحي. عند ضبط إعدادات أداة مراقبة السلامة، تأكَّد من ضبط <MaxFailures> في العلامة <HTTPTargetConnection> الخاصة بالعلامة <TargetEndpoint> على قيمة غير صفرية.

TCPMonitor

يحدّد الإعداد أدناه HealthMonitor الذي يستقصي كل TargetServer من خلال فتح اتصال على المنفذ 80 كل خمس ثوانٍ. (المنفذ اختياري. إذا لم يتم تحديد ذلك، يكون منفذ TCPMonitor هو منفذ TargetServer.)

• إذا تعذّر الاتصال أو استغرق أكثر من 10 ثوانٍ، سيزيد عدد حالات التعذّر بمقدار 1 بالنسبة إلى TargetServer.
• في حال نجاح الاتصال، تتم إعادة ضبط عدد حالات التعذّر في TargetServer على 0.

يمكنك إضافة HealthMonitor كعنصر فرعي من عنصر HTTPTargetConnetion الخاص بـ TargetEndpoint، كما هو موضّح أدناه:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

HealthMonitor مع عناصر إعداد TCPMonitor

يوضّح الجدول التالي عناصر إعداد TCPMonitor:

HTTPMonitor

سيُرسل نموذج HealthMonitor الذي يستخدم HTTPMonitor طلب استرداد بيانات باستخدام GET إلى خدمة الخلفية مرة كل خمس ثوانٍ. يضيف المثال أدناه عنوان HTTP Basic Authorization إلى رسالة الطلب. يحدّد إعداد الاستجابة الإعدادات التي ستتم مقارنتها بالاستجابة الفعلية من خدمة الخلفية. في المثال أدناه، الاستجابة المتوقّعة هي رمز استجابة HTTP 200 وعنوان HTTP مخصّص ImOK تكون قيمته YourOK. إذا لم يتطابق الرد، سيتم التعامل مع الطلب على أنّه تعذّر من خلال إعدادات موازنة الحمل.

تتيح أداة HTTPMonitor استخدام خدمات الخلفية التي تم ضبطها لاستخدام بروتوكولَي HTTP وHTTPS أحادي الاتجاه. ومع ذلك، لا يتيح ما يلي:

• بروتوكول HTTPS ثنائي الاتجاه (يُعرف أيضًا باسم بروتوكول أمان طبقة النقل/طبقة المقابس الآمنة ثنائي الاتجاه)
• الشهادات الموقَّعة ذاتيًا.

يُرجى العلم أنّ جميع إعدادات الطلب والاستجابة في أداة مراقبة HTTP ستكون خاصة بالخدمة الخلفية التي يجب استدعاؤها.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HealthMonitor مع عناصر إعداد HTTPMonitor

يوضّح الجدول التالي عناصر إعداد HTTPMonitor: