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

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. المعلومات

الفيديوهات الطويلة

راجع مقاطع الفيديو التالية للحصول على مزيد من المعلومات حول أخطاء 503:

حملة فيديو الوصف
تحديد المشاكل وحلّها في خدمة 503 Service Unavailable - NoActiveTargets تعرَّف على ما يلي:
  • أهمية الخوادم المستهدفة وأدوات مراقبة السلامة
  • تحديد المشاكل وحلّها وحلّ مشكلة عدم توفُّر خدمة 503 في الوقت الفعلي - خطأ NoActiveTargets الناتج عن تعذُّر التحقّق من الصحة

المشكلة

يتلقى تطبيق العميل رمز حالة استجابة 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 الخدمة غير متوفرة مع رمز الخطأ NoActiveTargets عند استخدام خادم هدف واحد أو أكثر في إعداد نقطة النهاية الهدف في الخادم الوكيل لواجهة برمجة التطبيقات.

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

حالات تعذُّر التحقق من الصحة

لن تتم ملاحظة إخفاقات التحقق من الصحة إلا في حال ضبط Health Monitor كجزء من عملية إعداد موازنة حمل الخادم الهدف في نقطة النهاية المستهدفة للخادم الوكيل لواجهة برمجة التطبيقات.

عندما يتعذّر على خادم مستهدف في عملية التحقّق من الصحة، يزيد 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.

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

في ما يلي الأسباب المحتملة لتعذُّر التحقّق من الصحة:

السبب الوصف المستخدمون الذين يمكنهم تنفيذ خطوات تحديد المشاكل وحلّها
خطأ انتهاء مهلة الاتصال يتعذّر على معالج الرسائل الاتصال بالخادم المستهدف خلال فترة المهلة المحددة في إعداد LoadBalancer. مستخدمو Edge Private Cloud
طلب آمن عند منفذ غير آمن
  1. إذا تم تحديد الخادم الهدف على أنه خادم آمن، ولكن تم إعداده بشكلٍ غير صحيح باستخدام منفذ غير آمن.
  2. إذا تم تحديد الخادم المستهدف على أنه خادم آمن، ولكن تم إعداد أداة مراقبة السلامة لإجراء عمليات التحقق من الصحة على منفذ غير آمن.
 مستخدمو Edge Private Cloud
طلب غير آمن عند المنفذ الآمن
  1. إذا تم تحديد الخادم الهدف على أنه خادم غير آمن، ولكن تم إعداده بشكلٍ غير صحيح باستخدام منفذ آمن.
  2. في حال تحديد الخادم المستهدف على أنه خادم غير آمن، مع إعداد أداة مراقبة السلامة لإجراء عمليات فحص السلامة على منفذ آمن.
 مستخدمو Edge Private Cloud
استجابة Health Check API تعرض رسالة خطأ إذا استجابت واجهة برمجة التطبيقات للتحقق من الصحة بخطأ أو رمز استجابة، أي شيء آخر غير المحدد في عنصر SuccessResponse في أداة Health Monitor. مستخدمو Edge Private Cloud

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

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

أداة التتبُّع

لتحديد رقم تعريف الرسالة الخاصة بالطلب الذي تعذّر تنفيذه باستخدام أداة التتبُّع:

  1. فعِّل جلسة التتبُّع، ونفِّذ طلب بيانات من واجهة برمجة التطبيقات، وأعِد إظهار المشكلة - خدمة 503 غير متاحة مع رمز الخطأ NoActiveTargets.
  2. اختَر أحد الطلبات التي تعذّر تنفيذها.
  3. انتقِل إلى مرحلة AX، وحدِّد معرّف الرسالة (X-Apigee.Message-ID) للطلب من خلال الانتقال للأسفل في قسم Stage Details (تفاصيل المرحلة) كما هو موضّح في الشكل التالي.

    معرّف الرسالة في قسم &quot;تفاصيل المرحلة&quot;

سجلات وصول NGINX

لتحديد رقم تعريف الرسالة للطلب الذي تعذّر تنفيذه باستخدام سجلات وصول NGINX:

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

  1. تحقَّق من سجلات وصول NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. ابحث عن أي أخطاء 503 للخادم الوكيل المحدّد لواجهة برمجة التطبيقات خلال مدة محدّدة (إذا حدثت المشكلة في السابق) أو إذا كانت هناك أي طلبات لا تزال تفشل في الخطأ 503.
  3. في حال وجود أي أخطاء من أخطاء 503 مع X-Apigee- error-code messaging.adaptors.http.flow.NoActiveTargets، لاحِظ معرّف الرسالة لطلب واحد أو أكثر من هذه الطلبات، كما هو موضّح في المثال التالي:

    إدخال نموذجي يعرض الخطأ 503

    إدخال نموذجي يعرض رمز الحالة ورقم تعريف الرسالة ومصدر الخطأ ورمز الخطأ

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

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

في ما يلي رسائل الخطأ الشائعة التي تم رصدها في سجلات معالج الرسائل (/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 التالية إلى أنه تعذّر على "معالج الرسائل" بسبب انتهاء مهلة الاتصال عند إجراء طلب واجهة برمجة التطبيقات للتحقق من الصحة:

    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 من المرات التي تم فيها ضبط إعدادات Health Monitor، ستظهر لك رسالة تحذير على النحو التالي:

    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:
    5. telnet <BackendServer-HostName> 443
  5. إذا كان بإمكانك الاتصال بخادم الخلفية، قد تظهر لك رسالة مثل تم الاتصال بخادم الخلفية. بعد ذلك، قد تكون المشكلة مؤقتة وقد يتم حلّها أو هي مشكلة تحدث بشكل متقطع. كرِّر الخطوة 4 عدة مرات (10 مرات أو أكثر) وتحقَّق من النتيجة.
    1. إذا لم يكن هناك أي أخطاء في الأمر telnet بشكل منتظم، يعني ذلك أنّه قد تم حلّ المشكلة. تحقَّق ممّا إذا كانت حالات تعذُّر التحقّق من الصحة قد توقفت. إذا كانت الإجابة "نعم"، لن يكون عليك اتخاذ أي إجراء آخر.
    2. إذا لم تتمكن من الاتصال بخادم الخلفية باستخدام الأمر telnet بشكل متقطع، قد تكون هناك مشكلة في الشبكة أو قد يكون خادم الخلفية مشغولاً.
  6. إذا لم تتمكّن من الاتصال بخادم الخلفية باستخدام الأمر telnet بشكل منتظم، قد يرجع ذلك إلى أنّ عدد الزيارات غير مسموح به من معالجات الرسائل على الخادم الخلفية المحدد.

درجة الدقّة

إذا تمت ملاحظة الخطأ connection timed out باستمرار، عليك التأكّد من أنّ خادم الخلفية لا يتضمّن أي قيود على جدار الحماية وأنّه يسمح بحركة البيانات من معالِجات الرسائل في Apigee Edge. على سبيل المثال، يمكنك استخدام iptables على نظام التشغيل Linux للسماح بحركة البيانات من عناوين 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 من المرات التي تم ضبطها في Health Monitor، ستظهر لك رسالة تحذير على النحو التالي:

    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. تحقق من تعريف الخادم الهدف المستخدم في إعداد نقطة النهاية الهدف.

      2. يمكنك استخدام الحصول على واجهة برمجة تطبيقات 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. والآن، تحقَّق من إعدادات Health Monitor للخادم الهدف في إعدادات نقطة النهاية الهدف:

      إعداد أداة مراقبة الصحة

      <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> في إعدادات Health Monitor أعلاه. في هذه الحالة، يستخدم معالج الرسائل في Edge المنفذ المحدد في تعريف الخادم المستهدف (وهو 80) لإجراء طلبات بيانات من واجهة برمجة التطبيقات للتحقق من الصحة.

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

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

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

    إذا كنت قد حددت خادمًا مستهدفًا آمنًا ولكن تم إعداد أداة مراقبة السلامة باستخدام منفذ غير آمن مثل 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. بعد ذلك، تحقَّق من إعدادات Health Monitor للخادم الهدف في إعدادات نقطة النهاية الهدف:

      إعداد أداة مراقبة الصحة

      <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>

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

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

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

درجة الدقّة

المنفذ الآمن غير الآمن

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

لإصلاح هذا الخطأ، عليك تعديل تعريف الخادم الهدف لاستخدام منفذ آمن مناسب.

استخدِم Update a TargetServer API لتعديل تعريف الخادم الهدف وتأكَّد من استخدام منفذ آمن (على سبيل المثال: 443) كما هو موضّح في المثال أدناه:

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

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

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

لإصلاح هذا الخطأ، اتبع التعليمات التالية:

  1. عدِّل إعدادات Health Monitor لاستخدام منفذ آمن (مثل 443) لإجراء عمليات تحقّق من سلامة الخادم المستهدف في إعداد نقطة النهاية المستهدفة للخادم الوكيل لواجهة برمجة التطبيقات الذي يتعذّر تطبيقه كما هو موضّح أدناه: 
    <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>
  2. احفظ التغييرات التي تم إدخالها على الخادم الوكيل لواجهة برمجة التطبيقات.

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

التشخيص

  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 من المرات التي تم ضبطها في Health Monitor، ستظهر لك رسالة تحذير على النحو التالي:

    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.

    يمكن أن يحدث هذا الخطأ ضمن السيناريوهين التاليين:

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

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

    السيناريو 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. والآن، تحقَّق من إعدادات Health Monitor للخادم الهدف في إعدادات نقطة النهاية الهدف:

      إعداد أداة مراقبة الصحة

      <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> في إعدادات Health Monitor أعلاه. في هذه الحالة، سيستخدم معالج الرسائل في Edge المنفذ المحدد في تعريف الخادم المستهدف وهو 443.

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

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

    منفذ HM آمن هدف غير آمن

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

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

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

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

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

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

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

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

      إعداد أداة مراقبة الصحة

      <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>

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

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

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

درجة الدقّة

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

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

لإصلاح هذا الخطأ، عليك تعديل تعريف الخادم الهدف لاستخدام منفذ آمن مناسب.

استخدِم Update a Target Server API لتعديل تعريف الخادم الهدف وتأكَّد من استخدام منفذ غير آمن (مثل: 80) كما هو موضّح في المثال أدناه: 

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

منفذ HM آمن هدف غير آمن

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

لإصلاح هذا الخطأ، اتبع التعليمات التالية:

  1. عليك إمّا إزالة العنصر <Port> من إعدادات Health Monitor أو تعديل إعدادات Health Monitor لاستخدام منفذ غير آمن (مثل: 80) لتنفيذ عمليات تحقّق من سلامة الخادم المستهدَف في إعدادات نقطة النهاية المستهدفة للخادم الوكيل لواجهة برمجة التطبيقات الذي يتعذّر اجتيازه، كما هو موضّح أدناه: 
    <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>
</HealthMonitor>
  2. احفظ التغييرات التي تم إدخالها على الخادم الوكيل لواجهة برمجة التطبيقات.

السبب: استجابة واجهة برمجة التطبيقات Health check API تعرض رسالة خطأ

التشخيص

  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 من المرات التي تم ضبطها في Health Monitor، ستظهر لك رسالة تحذير على النحو التالي:

    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>

    لاحظ أنّه تم ضبط إعدادات Health Monitor برمز الاستجابة 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 غير صحيح في إعداد أداة Health Monitor. تبيّن أنّ عنوان URL الصحيح هو https://mocktarget.apigee.net:443/statuscode/200 من Mock Target API.
  7. إذا تلقّيت أي استجابة أخرى بشأن الخطأ، حدِّد سبب المشكلة من خلال اتّباع الخطوات المذكورة أعلاه. إذا لزم الأمر، اعمل مع فريق الخلفية.

درجة الدقّة

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

في حال استمرار المشكلة، انتقِل إلى ضرورة جمع معلومات التشخيص.

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

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

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

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

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

  1. إذا كنت من مستخدمي السحابة الإلكترونية العامة، يُرجى تقديم المعلومات التالية:
    1. اسم المؤسسة
    2. اسم البيئة
    3. اسم الخادم الوكيل لواجهة برمجة التطبيقات
    4. إكمال أمر curl لإعادة إظهار الخطأ
    5. تتبع ملف يحتوي على الطلبات التي بها خدمة 503 غير متاحة مع رمز الخطأ NoActiveTargets
  2. إذا كنت أحد مستخدمي Private Cloud، يُرجى تقديم المعلومات التالية:
    1. تم رصد رسالة خطأ مكتملة.
    2. اسم البيئة
    3. حزمة الخادم الوكيل لواجهة برمجة التطبيقات
    4. تتبع ملف يحتوي على الطلبات التي بها خدمة 503 غير متاحة مع رمز الخطأ 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)