503 الخدمة غير متوفرة - NoActiveTargets - HealthCheckFailures

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

الفيديوهات

يمكنك الاطّلاع على الفيديوهات التالية للحصول على مزيد من المعلومات حول أخطاء 503:

المشكلة

يتلقّى تطبيق العميل رمز حالة استجابة HTTP‏ 503 مع الرسالة الخدمة غير متاحة ورمز الخطأ NoActiveTargets لطلبات خادم وكيل واجهة برمجة التطبيقات.

رسالة الخطأ

ستظهر لك استجابة الخطأ التالية:

HTTP/1.1 503 Service Unavailable
  

ستظهر لك رسالة الخطأ التالية في استجابة HTTP:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}
  

الأسباب المحتملة

عادةً ما تظهر استجابة HTTP 503 Service Unavailable مع رمز الخطأ NoActiveTargets عند استخدام خادم واحد أو أكثر من خوادم الاستهداف في إعدادات نقطة النهاية المستهدَفة في خادم وكيل واجهة برمجة التطبيقات.

يغطّي دليل التشغيل هذا الخطأ 503 Service Unavailable الذي يحمل رمز الخطأ NoActiveTargets الناتج عن تعذُّر عمليات التحقّق من السلامة. يُرجى الرجوع إلى هذا الدليل الإرشادي للتعرّف على الأسباب الأخرى لهذا الخطأ.

أخطاء التحقّق من الصحة

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

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

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

يوفّر تحذير التوافق المعلومات التالية. يساعدك ذلك في معرفة الخادم المستهدَف الذي بلغ عدد مرات الوصول إليه MaxFailure:

• اسم الخادم المستهدَف
• أسماء المؤسسة والبيئة
• اسم خادم وكيل لواجهة برمجة التطبيقات
• اسم نقطة النهاية المستهدَفة

بعد ذلك، يتوقف Edge عن إرسال أي طلبات أخرى إلى هذا الخادم المحدّد. بعد أن يصل عدد الخوادم المستهدَفة التي تم ضبطها في إعدادات LoadBalancer إلى MaxFailure، يتم الرد على طلبات البيانات من واجهة برمجة التطبيقات اللاحقة بالرمز 503 Service Unavailable مع رمز الخطأ NoActiveTargets.

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

في ما يلي الأسباب المحتملة لتعذُّر إجراء فحص السلامة:

خطوات التشخيص الشائعة

تحديد رقم تعريف الرسالة للطلب الذي تعذّر تنفيذه

رسائل الخطأ الشائعة

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

في ما يلي رسائل الخطأ الشائعة التي تم رصدها في سجلّات "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log) للخطأ 503 Service Unavailable مع رمز الخطأ NoActiveTargets :

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

تشير رسائل الخطأ هذه إلى أنّه تعذّر إرسال الطلب إلى خادم الخلفية بسبب حدوث عطل. نتيجةً لذلك، يرسل "معالج الرسائل" الرمز 503 Service Unavailable مع رمز الخطأ NoActiveTargets كاستجابة للعميل.

السبب: انتهت مهلة الاتصال

التشخيص

1. تحديد رقم تعريف الرسالة للطلب الذي تعذّر تنفيذه
2. ابحث عن رقم تعريف الرسالة في سجلّ "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. ستظهر لك رسائل الخطأ الشائعة المرتبطة بمعرّف الرسالة. ومع ذلك، للوصول إلى السبب الفعلي لتعذُّر إجراء عملية التحقّق من الصحة، انتقِل إلى أعلى رسائل الخطأ الشائعة هذه وابحث عن أي أخطاء في HEALTH MONITOR.

   على سبيل المثال، تشير رسالة الخطأ التالية في HEALTH MONITOR إلى تعذُّر عمل Message Processor بسبب انتهاء مهلة الاتصال عند تقديم طلب بيانات من واجهة برمجة التطبيقات للتحقّق من الأداء:

   Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
   java.net.ConnectException: Connection timed out (Connection timed out)
   	at java.net.PlainSocketImpl.socketConnect(Native Method)
   	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
   	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
   …<snipped>
           

   إذا تكرّر هذا الخطأ MaxFailure مرة وفقًا للإعدادات المحدّدة في "أداة مراقبة السلامة"، ستظهر لك رسالة تحذيرية على النحو التالي:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   اقرأ المعلومات الواردة في رسالة التحذير بعناية. تأكَّد من أنّ عدد MaxFailure قد تم بلوغه لخادم مستهدَف مستخدَم في خادم وكيل واجهة برمجة التطبيقات المحدّد الذي يظهر لك فيه رمز الاستجابة 503 مع رمز الخطأ NoActiveTargets.

4. في المثال أعلاه، تعذّر اجتياز اختبار الكفاءة بسبب الخطأ connection timed out. تحقَّق مما إذا كان بإمكانك الاتصال بخادم الخلفية المحدّد مباشرةً من كل معالجات الرسائل باستخدام الأمر telnet:

telnet <BackendServer-HostName> 443
      

5. إذا تمكّنت من الاتصال بخادم الخلفية، قد تظهر لك رسالة مثل تم الاتصال بخادم الخلفية. في هذه الحالة، قد تكون المشكلة مؤقتة، وقد تم حلّها أو قد تكون مشكلة متقطعة. كرِّر الخطوة 4 بضع مرات (10 مرات أو أكثر) وتحقّق من الناتج.
1. إذا لم تظهر أي أخطاء عند استخدام الأمر telnet بشكل متكرر، يعني ذلك أنّه تم حل المشكلة. أعِد التحقّق مما إذا كانت أخطاء فحص السلامة قد توقّفت. إذا كانت الإجابة نعم، ليس عليك اتّخاذ أي إجراء آخر.
2. إذا تعذّر عليك الاتصال بخادم الخلفية باستخدام الأمر telnet بشكل متقطع، فقد تكون هناك مشكلة في الشبكة أو قد يكون خادم الخلفية مشغولاً.
6. إذا تعذّر عليك الاتصال بخادم الخلفية باستخدام الأمر telnet بشكل متكرّر، قد يكون السبب هو عدم السماح بنقل البيانات من معالجات الرسائل إلى خادم الخلفية المحدّد.

الدقة

إذا ظهر الخطأ connection timed out بشكل متكرّر، تأكَّد من أنّ خادم الخلفية لا يتضمّن أي قيود على جدار الحماية ويسمح بزيارات من "معالجات الرسائل" في Apigee Edge. على سبيل المثال، في نظام التشغيل Linux، يمكنك استخدام iptables للسماح بالزيارات من عناوين IP الخاصة بـ "معالج الرسائل" على خادم الخلفية.

في حال استمرار المشكلة، يُرجى التواصل مع مشرف الشبكة لتحديد المشكلة وحلّها. إذا كنت بحاجة إلى أي مساعدة إضافية من Apigee، يُرجى التواصل مع فريق الدعم في Apigee.

السبب: طلب آمن على منفذ غير آمن

التشخيص

1. تحديد رقم تعريف الرسالة للطلب الذي تعذّر تنفيذه
2. ابحث عن رقم تعريف الرسالة في سجلّ "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. ستظهر لك رسائل الخطأ الشائعة المتوافقة مع رقم تعريف الرسالة. ومع ذلك، لمعرفة السبب الفعلي لتعذُّر إجراء فحص الصحة، انتقِل إلى أعلى رسائل الخطأ الشائعة هذه وابحث عن أي أخطاء في HEALTH MONITOR.

   على سبيل المثال، قد يظهر لك خطأ HEALTH MONITOR كما هو موضّح أدناه:

   Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
           at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
           at sun.security.ssl.InputRecord.read(InputRecord.java:527)
           at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
           at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
   …<snipped>
           

   إذا تكرّر هذا الخطأ MaxFailure مرة من المرات التي تم ضبطها في "أداة مراقبة السلامة"، ستظهر لك رسالة تحذيرية على النحو التالي:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   اقرأ المعلومات الواردة في رسالة التحذير بعناية. تأكَّد من أنّ عدد MaxFailure قد تم بلوغه لخادم مستهدَف مستخدَم في خادم وكيل واجهة برمجة التطبيقات المحدّد الذي يظهر لك فيه رمز الاستجابة 503 مع رمز الخطأ NoActiveTargets.

4. تعذّر إجراء فحص الكفاءة بسبب الخطأ:

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   تشير رسالة الخطأ وعنوان URL إلى أنّ سبب هذه المشكلة هو إجراء مكالمة آمنة (HTTPS) على المنفذ غير الآمن 80.

   يمكن أن يحدث هذا الخطأ في الحالتَين التاليتَين:

   • تم تحديد خادم مستهدف آمن باستخدام منفذ غير آمن
   • تم تحديد خادم مستهدف آمن، ولكن تم ضبط "أداة مراقبة السلامة" باستخدام منفذ غير آمن

   تأمين المنفذ غير الآمن المستهدَف

   السيناريو 1: تحديد خادم مستهدَف آمن باستخدام منفذ غير آمن

   إذا كنت قد حدّدت خادمًا آمنًا مستهدفًا ولكن بمنفذ غير آمن مثل 80، سيظهر لك هذا الخطأ. اتّبِع الخطوات التالية للتأكّد مما إذا كان هذا هو سبب المشكلة:

   1. تحقَّق من تعريف الخادم المستهدف المستخدَم في إعدادات نقطة النهاية المستهدَفة.

   استخدِم Get TargetServer API للحصول على تعريف الخادم المستهدف.

   ناتج تعريف الخادم المستهدَف

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

   في المثال أعلاه، يوضّح التعريف أنّ الخادم المستهدف mocktarget هو خادم آمن كما هو موضّح في كتلة SSLInfo. ومع ذلك، تم ضبطه باستخدام المنفذ 80 غير الآمن.

   2. الآن، تحقَّق من إعدادات "مراقبة السلامة" للخادم المستهدف في إعدادات نقطة النهاية المستهدَفة:

      إعدادات "مراقبة السلامة"

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      لاحظ أنّه لم يتم تحديد أي عنصر <Port> في إعدادات "مراقبة الحالة" أعلاه. في هذه الحالة، يستخدم "معالج الرسائل" في Edge المنفذ المحدّد في تعريف الخادم المستهدف (وهو 80) لإجراء طلبات البيانات من واجهة برمجة التطبيقات الخاصة بفحص السلامة.

   3. استنادًا إلى المعلومات الواردة أعلاه، يرجع سبب هذا الخطأ إلى أنّ الخادم المستهدف معرَّف على أنّه خادم آمن (لأنّه تم تفعيل الحظر SSLInfo)، ولكن مع منفذ غير آمن 80.

   تأمين منفذ HM غير آمن

   السيناريو 2: تم تحديد خادم مستهدف آمن، ولكن تم ضبط "مراقبة السلامة" باستخدام منفذ غير آمن

   يظهر هذا الخطأ إذا حدّدت خادمًا آمنًا مستهدفًا ولكن تم ضبط أداة Health Monitor باستخدام منفذ غير آمن، مثل 80. اتّبِع الخطوات التالية للتأكّد مما إذا كان هذا هو سبب المشكلة:

   1. تحقَّق من تعريف الخادم المستهدف المستخدَم في إعدادات نقطة النهاية المستهدَفة.

      استخدِم Get TargetServer API للحصول على تعريف الخادم المستهدَف.

      ناتج تعريف الخادم المستهدَف

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

      في المثال أعلاه، يوضّح التعريف أنّ الخادم المستهدَف mocktarget هو خادم آمن كما هو موضّح في الحظر SSLInfo.

   2. بعد ذلك، تحقَّق من إعدادات "مراقبة السلامة" للخادم المستهدف في إعدادات نقطة النهاية المستهدَفة:

      إعدادات "مراقبة السلامة"

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      في المثال أعلاه، تم ضبط "أداة مراقبة الصحة" باستخدام المنفذ 80 غير الآمن كما هو موضّح في العنصر <Port>.

   3. استنادًا إلى المعلومات الواردة أعلاه، يرجع سبب هذا الخطأ إلى أنّ الخادم المستهدف معرَّف على أنّه خادم آمن (لأنّه تم تفعيل الحظر SSLInfo) ويستخدم المنفذ الآمن 443، ولكن تم ضبط "مراقبة الحالة" لإجراء عمليات التحقّق من الحالة باستخدام المنفذ غير الآمن 80 (المحدّد في العنصر <Port>).

      أي أنّ Edge في هذه الحالة يطلب من واجهات برمجة التطبيقات الخاصة بعمليات التحقّق من الصحة إجراء مكالمة آمنة باستخدام المنفذ 80 غير الآمن، ويتعذّر عليه ذلك ويظهر الخطأ المذكور أعلاه.

الدقة

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

السبب: طلب غير آمن على منفذ آمن

التشخيص

1. تحديد رقم تعريف الرسالة للطلب الذي تعذّر تنفيذه
2. ابحث عن رقم تعريف الرسالة في سجلّ "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. ستظهر لك رسائل الخطأ الشائعة المرتبطة بمعرّف الرسالة. ومع ذلك، لمعرفة السبب الفعلي لتعذُّر إجراء فحص الصحة، انتقِل إلى أعلى رسائل الخطأ الشائعة هذه وابحث عن أي أخطاء في HEALTH MONITOR.

   على سبيل المثال، قد يظهر لك خطأ HEALTH MONITOR كما هو موضّح أدناه:

   Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
   …<snipped>
             

   إذا تكرّر هذا الخطأ MaxFailure مرة من المرات التي تم ضبطها في "أداة مراقبة السلامة"، ستظهر لك رسالة تحذيرية على النحو التالي:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
             

   اقرأ المعلومات الواردة في رسالة التحذير بعناية. تأكَّد من أنّ عدد MaxFailure قد تم بلوغه لخادم مستهدَف مستخدَم في خادم وكيل واجهة برمجة التطبيقات المحدّد الذي يظهر لك فيه رمز الاستجابة 503 مع رمز الخطأ NoActiveTargets.

4. تعذّر إجراء فحص الكفاءة بسبب الخطأ:

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   تشير رسالة الخطأ وعنوان URL إلى أنّ سبب هذه المشكلة هو إجراء مكالمة غير آمنة (HTTP) على المنفذ الآمن 443.

   يمكن أن يحدث هذا الخطأ في الحالتَين التاليتَين:

   • تم تحديد خادم مستهدَف غير آمن باستخدام منفذ آمن
   • تم تحديد خادم مستهدف غير آمن، ولكن تم ضبط "مراقبة السلامة" باستخدام منفذ آمن

   منفذ آمن مستهدَف غير آمن

   السيناريو 1: تحديد خادم مستهدَف غير آمن باستخدام منفذ آمن

   يظهر هذا الخطأ إذا حدّدت خادمًا مستهدفًا غير آمن ولكن بمنفذ آمن مثل 443. اتّبِع الخطوات التالية للتأكّد مما إذا كان هذا هو سبب المشكلة:

   1. تحقَّق من تعريف الخادم المستهدف المستخدَم في إعدادات نقطة النهاية المستهدَفة.

      استخدِم Get TargetServer API للحصول على تعريف الخادم المستهدف.

      ناتج تعريف الخادم المستهدَف

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

      في المثال أعلاه، يوضّح التعريف أنّ الخادم المستهدف mocktarget هو خادم غير آمن لأنّه لا يتضمّن أيّ حظر SSLInfo. ومع ذلك، تم ضبطه بشكل غير صحيح باستخدام المنفذ 443 الآمن.

   2. الآن، تحقَّق من إعدادات "مراقبة السلامة" للخادم المستهدف في إعدادات نقطة النهاية المستهدَفة:

      إعدادات "مراقبة السلامة"

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      لاحظ أنّه لم يتم تحديد أي عنصر <Port> في إعدادات "مراقبة الحالة" المذكورة أعلاه. في هذه الحالة، سيستخدم "معالج الرسائل" في Edge المنفذ المحدّد في تعريف الخادم المستهدف، وهو 443.

   3. استنادًا إلى المعلومات الواردة أعلاه، يرجع سبب هذا الخطأ إلى أنّ الخادم المستهدف معرَّف على أنّه خادم غير آمن (لأنّه لم يتم تعريف الحظر SSLInfo)، ولكن مع منفذ آمن 443.

      أي أنّ Edge يجري عمليات التحقّق من الصحة كطلب غير آمن باستخدام المنفذ الآمن 443، ويتعذّر عليه ذلك مع ظهور الخطأ المذكور أعلاه.

   منفذ HM آمن غير مستهدَف

   السيناريو 2: تحديد خادم مستهدف غير آمن ولكن تم ضبط "أداة مراقبة الصحة" باستخدام منفذ آمن

   يظهر هذا الخطأ إذا حدّدت خادمًا مستهدفًا غير آمن، ولكن تم ضبط "أداة مراقبة السلامة" باستخدام منفذ آمن، مثل 443. اتّبِع الخطوات التالية للتأكّد مما إذا كان هذا هو سبب المشكلة:

   1. تحقَّق من تعريف الخادم المستهدف المستخدَم في إعدادات نقطة النهاية المستهدَفة.

      استخدِم Get TargetServer API للحصول على تعريف الخادم المستهدَف.

      ناتج تعريف الخادم المستهدَف

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
              

      في المثال أعلاه، يوضّح التعريف أنّ الخادم المستهدف mocktarget هو خادم غير آمن (لأنّه لا يتضمّن حظر SSLInfo) تم إعداده باستخدام منفذ غير آمن 80 بشكل صحيح.

   2. بعد ذلك، تحقَّق من إعدادات "مراقبة السلامة" للخادم المستهدف في إعدادات نقطة النهاية المستهدَفة:

      إعدادات "مراقبة السلامة"

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      في المثال أعلاه، تم ضبط "مراقبة الحالة" باستخدام المنفذ 443 الآمن كما هو موضّح في العنصر <Port>.

   3. استنادًا إلى المعلومات الواردة أعلاه، يعود سبب هذا الخطأ إلى أنّ الخادم المستهدف معرَّف على أنّه خادم غير آمن (لأنّه لم يتم تحديد حظر SSLInfo) مع المنفذ 80 غير الآمن بشكل صحيح، ولكن تم ضبط "أداة مراقبة الصحة" لإجراء عمليات التحقّق من الصحة باستخدام المنفذ 443 الآمن (المحدّد في العنصر <Port>).

      أي أنّ Edge في هذه الحالة يجري عمليات التحقّق من الصحة كطلب غير آمن باستخدام المنفذ الآمن 443 ويتعذّر عليه إكمالها بسبب الخطأ المذكور أعلاه.

الدقة

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              

السبب: تعرض واجهة برمجة التطبيقات الخاصة بفحص الحالة رسالة خطأ

التشخيص

1. تحديد رقم تعريف الرسالة للطلب الذي تعذّر تنفيذه
2. ابحث عن رقم تعريف الرسالة في سجلّ "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. ستظهر لك رسائل الخطأ الشائعة المتوافقة مع رقم تعريف الرسالة. ومع ذلك، لمعرفة السبب الفعلي لتعذُّر إجراء فحص السلامة، انتقِل إلى أعلى رسائل الخطأ الشائعة هذه وابحث عن أي أخطاء أو تحذيرات في HEALTH MONITOR.

   على سبيل المثال، قد يظهر لك تحذير من "مراقبة الصحة" كما هو موضّح أدناه:

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
   Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
           

   إذا تكرّر هذا الخطأ MaxFailure مرة من المرات التي تم ضبطها في "أداة مراقبة السلامة"، ستظهر لك رسالة تحذيرية على النحو التالي:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   اقرأ المعلومات الواردة في رسالة التحذير بعناية. تأكَّد من أنّ عدد MaxFailure قد تم بلوغه لخادم مستهدَف مستخدَم في خادم وكيل واجهة برمجة التطبيقات المحدّد الذي يظهر لك فيه رمز الاستجابة 503 مع رمز الخطأ NoActiveTargets.

4. عرضت عملية التحقّق من الصحة رسالة التحذير التالية:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

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

5. قبل التحقيق في سبب ظهور ردّ يتضمّن خطأ من واجهة برمجة التطبيقات الخاصة بفحص السلامة، عليك تحديد السبب الذي يجعل Edge يتوقّع ظهور رمز الاستجابة 200 من واجهة برمجة التطبيقات الخاصة بفحص السلامة. لإجراء ذلك، تحقَّق من إعدادات Health Monitor للخادم المستهدف في إعدادات نقطة النهاية المستهدفة:

   إعدادات "مراقبة السلامة"

   <HealthMonitor>
     <IsEnabled>true</IsEnabled>
     <IntervalInSec>5</IntervalInSec>
     <HTTPMonitor>
       <Request>
         <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
         <Port>443</Port>
         <Verb>GET</Verb>
         <Path>/status/200</Path>
       </Request>
       <SuccessResponse>
         <ResponseCode>200</ResponseCode>
       </SuccessResponse>
     </HTTPMonitor>
   </HealthMonitor>
           

   لاحظ أنّ إعدادات "مراقبة السلامة" تم ضبطها باستخدام رمز الاستجابة 200 ضمن العنصر <SuccessResponse>. وهذا يعني أنّه إذا تلقّى Edge أي رمز استجابة (مثل 400 أو 401 أو 404 أو 500) بخلاف 200 من واجهة برمجة التطبيقات الخاصة بفحص السلامة، سيتم التعامل معه على أنّه خطأ وسيتم زيادة عدد الأخطاء.

6. الآن، للتحقيق في سبب ظهور استجابة خطأ من واجهة برمجة التطبيقات لعمليات التحقّق من الصحة، اتّبِع الخطوات التالية:
1. اطّلِع على الرسالة التي تسبق رسالة التحذير في سجلّ "معالج الرسائل".

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
             

   دوِّن عنوان URL الخاص بالتحقّق من الصحة من هذه الرسالة.

2. يمكنك إجراء مكالمة مباشرة إلى عنوان URL هذا من "معالج الرسائل" والتحقّق من الردّ الفعلي.

   curl -i https://mocktarget.apigee.net:443/status/200
             

   يظهر الردّ من المكالمة أعلاه 404 كما هو موضّح في سجلّات "معالج الرسائل":

   < HTTP/2 404
             

3. يوضّح ذلك أنّه حتى الطلب المباشر لعنوان URL الخاص بفحص السلامة يتعذّر تنفيذه مع ظهور رمز الاستجابة نفسه 404. وهذا يعني أنّ عنوان URL الخاص بفحص السلامة قد يكون غير صحيح أو أنّ المرجع الذي يتم الوصول إليه كجزء من عنوان URL لم يعُد متاحًا.
4. في مثال واجهة برمجة التطبيقات للتحقّق من الصحة المقدَّم أعلاه، تحدث المشكلة بسبب استخدام عنوان URL غير صحيح في إعدادات "أداة مراقبة الصحة". تم العثور على عنوان URL الصحيح وهو https://mocktarget.apigee.net:443/statuscode/200 من Mock Target API.
7. إذا تلقّيت أي ردّ آخر يتضمّن خطأ، حدِّد سبب الخطأ باتّباع الخطوات المذكورة أعلاه. إذا لزم الأمر، يمكنك العمل مع فريق الخلفية.

الدقة

1. حلّ المشكلة المتعلّقة بواجهة برمجة التطبيقات الخاصة بعمليات التحقّق من الصحة على خادم الخلفية
2. لحلّ المشكلة في المثال المذكور أعلاه، اتّبِع الخطوات التالية:
1. عدِّل العنصر <Path> في إعدادات "مراقبة السلامة" إلى /statuscode/200 كما هو موضّح أدناه:

   <Path>/statuscode/200</Path>
           

2. احفظ التغييرات في خادم وكيل واجهة برمجة التطبيقات.

إذا استمرت المشكلة، انتقِل إلى Must Gather Diagnostic Information.

تشخيص المشاكل باستخدام ميزة "مراقبة واجهة برمجة التطبيقات"

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

تتبُّع سيناريو نموذجي يوضّح كيفية تحديد المشاكل وحلّها في نطاق 5xx في واجهات برمجة التطبيقات باستخدام خدمة "مراقبة واجهة برمجة التطبيقات" على سبيل المثال، يمكنك إعداد تنبيه لتلقّي إشعار عندما يتجاوز عدد messaging.adaptors.http.flow.NoActiveTargets الأخطاء حدًا معيّنًا.

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

إذا استمرت المشكلة حتى بعد اتّباع التعليمات أعلاه، يُرجى جمع معلومات التشخيص التالية. يُرجى التواصل مع فريق دعم Apigee ومشاركة ما يلي:

1. إذا كنت من مستخدمي Public Cloud، يُرجى تقديم المعلومات التالية:
1. اسم المؤسسة
2. اسم البيئة
3. اسم خادم وكيل لواجهة برمجة التطبيقات
4. أكمِل أمر curl لإعادة إظهار الخطأ
5. ملف تتبُّع يحتوي على الطلبات التي تتضمّن الخطأ 503 Service Unavailable مع رمز الخطأ NoActiveTargets
2. إذا كنت من مستخدمي Private Cloud، يُرجى تقديم المعلومات التالية:
   1. رسالة الخطأ الكاملة التي ظهرت
   2. اسم البيئة
   3. حزمة خادم وكيل لواجهة برمجة التطبيقات
   4. ملف تتبُّع يحتوي على الطلبات التي تتضمّن الخطأ 503 Service Unavailable مع رمز الخطأ NoActiveTargets
   5. سجلّات الوصول إلى NGINX

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

   6. سجلّات معالج الرسائل

      (/opt/apigee/var/log/edge-message-processor/logs/system.log)