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

يتناول هذا الدليل الإرشادي الخطأ 503 خدمة غير متوفرة مع رمز الخطأ حدث 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 مع ظهور خطأ إذا كانت واجهة برمجة التطبيقات Health Check API تستجيب باستخدام خطأ أو رمز استجابة، بأي وسيلة أخرى غير المحددة في عنصر SuccessResponse في أداة Health Monitor. مستخدمو Edge Private Cloud

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

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

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

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

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

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

سجلات وصول NGINX

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

يمكنك أيضًا الرجوع إلى سجلات NGINX Access لتحديد معرِّف الرسالة لأخطاء 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 message.adaptors.http.flow.NoActiveTargets، دوِّن معرّف الرسالة لطلب واحد أو أكثر من هذه الطلبات كما هو موضّح في المثال التالي:

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

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

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

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

رسائل الخطأ الشائعة التي يتم رصدها في سجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log) خدمة 503 غير متاحة مع رمز الخطأ 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 للسماح بالزيارات من عناوين IP لمعالج الرسائل على خادم الخلفية

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

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

التشخيص

  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.

    قد يحدث هذا الخطأ في حالتَي السيناريوهَين التاليتَين:

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

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

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

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

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

      2. يمكنك استخدام الحصول على واجهة برمجة تطبيقات TargetServer للحصول على تعريف الخادم المستهدف.

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

      <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: تحديد خادم هدف آمن مع ضبط أداة Health Monitor باستخدام منفذ غير آمن

    إذا حددت خادمًا مستهدفًا آمنًا ولكن تمت تهيئة تطبيق Health Monitor غير آمن مثل 80، فستحصل على هذا الخطأ. يُرجى اتّباع الخطوات أدناه لإثبات الملكية. إذا كان هذا هو سبب هذه المشكلة:

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

      استخدم الحصول على 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>

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

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

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

الدقة

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

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

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

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

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

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

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

      استخدم الحصول على 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>

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

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

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

الدقة

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

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

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

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

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

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

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

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

  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

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

  5. قبل التحقيق في سبب ظهور الخطأ من خلال واجهة برمجة التطبيقات للتحقّق من الصحة، حدِّد سبب ظهور Edge. يتوقع أن يكون رمز الاستجابة 200 لواجهة Health Check API. لإجراء ذلك، تحقَّق من تطبيق 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 من واجهة برمجة التطبيقات Health Check API، فسيتم التعامل معه على أنه خطأ ويزيد من عدد الإخفاق.

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

الدقة

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

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

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

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

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

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

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

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