سرویس 503 در دسترس نیست - NoActiveTargets - HealthCheckFailures

شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات

ویدیوها

برای اطلاعات بیشتر در مورد خطاهای ۵۰۳، ویدیوهای زیر را ببینید:

علامت

برنامه‌ی کلاینت، کد وضعیت پاسخ HTTP 503 را با پیام Service Unavailable و کد خطای NoActiveTargets برای درخواست‌های پروکسی API دریافت می‌کند.

پیام خطا

پاسخ خطای زیر را مشاهده خواهید کرد:

HTTP/1.1 503 Service Unavailable
  

پیام خطای زیر را در پاسخ HTTP مشاهده خواهید کرد:

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

علل احتمالی

خطای HTTP با کد خطای ۵۰۳ Service Unavailable و کد خطای NoActiveTargets معمولاً زمانی مشاهده می‌شود که از یک یا چند سرور هدف در پیکربندی نقطه پایانی هدف در API Proxy خود استفاده می‌کنید.

این راهنما، خطای ۵۰۳ Service Unavailable با کد خطای NoActiveTargets که به دلیل عدم موفقیت در بررسی سلامت سرور ایجاد می‌شود را پوشش می‌دهد. لطفاً برای آشنایی با سایر دلایل این خطا، به این راهنما مراجعه کنید.

خرابی‌های بررسی سلامت

خطاهای بررسی سلامت تنها در صورتی مشاهده می‌شوند که شما یک مانیتور سلامت را به عنوان بخشی از پیکربندی متعادل‌سازی بار سرور هدف در نقطه پایانی هدف پروکسی API خود پیکربندی کرده باشید.

وقتی یک سرور هدف در بررسی سلامت با شکست مواجه می‌شود، 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 رسیده است:

• نام سرور هدف
• نام سازمان و محیط
• نام پروکسی API
• نام نقطه پایانی هدف

پس از آن، Edge ارسال هرگونه درخواست بیشتر به آن سرور خاص را متوقف می‌کند. هنگامی که تمام سرورهای هدف پیکربندی شده در پیکربندی LoadBalancer به تعداد MaxFailure برسند، درخواست‌های API بعدی با خطای ۵۰۳ Service Unavailable با کد خطای NoActiveTargets پاسخ داده می‌شوند.

استفاده از Health Monitor به Apigee Edge کمک می‌کند تا پس از بهبود عملکرد سرور هدف، بدون نیاز به استقرار مجدد API Proxy، به طور خودکار آن را به چرخه‌ی کاری خود بازگرداند.

در اینجا دلایل احتمالی عدم موفقیت در بررسی سلامت آورده شده است:

مراحل تشخیص مشترک

شناسه پیام درخواست ناموفق را تعیین کنید

پیام‌های خطای رایج

وقتی از سرورهای هدف استفاده می‌شود و هنگام تلاش پردازشگر پیام برای اتصال به سرور backend خطایی رخ می‌دهد، چند پیام خطای رایج در گزارش‌های پردازشگر پیام مشاهده خواهید کرد. این خطاها پس از پیام استثنا/خطای واقعی که منجر به خرابی شده است، ثبت می‌شوند.

پیام‌های خطای رایج مشاهده شده در لاگ‌های Message Processor ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) برای خطای ۵۰۳ 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>

این پیام‌های خطا نشان می‌دهند که به دلیل بروز مشکل، درخواست نتوانسته به سرور backend ارسال شود. در نتیجه، پردازنده پیام، خطای ۵۰۳ Service Unavailable را با کد خطای NoActiveTargets به عنوان پاسخ به کلاینت ارسال می‌کند.

علت: زمان اتصال به پایان رسیده است

تشخیص

1. شناسه پیام درخواست ناموفق را تعیین کنید .
2. شناسه پیام را در گزارش پردازشگر پیام ( /opt/apigee/var/log/edge-message-processor/logs/system.log ) جستجو کنید.
3. پیام‌های خطای رایج مربوط به شناسه پیام را مشاهده خواهید کرد. با این حال، برای دریافت علت واقعی عدم موفقیت در بررسی سلامت، به بالای این پیام‌های خطای رایج بروید و هرگونه خطای HEALTH MONITOR را بررسی کنید.

   برای مثال، پیام خطای HEALTH MONITOR زیر نشان می‌دهد که هنگام ارسال درخواست بررسی سلامت API، خطای «پردازشگر پیام با خطای اتصال به پایان رسیده» رخ داده است:

   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 برای سرور هدف مورد استفاده در API Proxy خاص که برای آن کد پاسخ ۵۰۳ با کد خطای NoActiveTargets را تجربه می‌کنید، به حد نصاب رسیده است.

4. در مثال بالا، بررسی سلامت با خطای connection timed out ناموفق بود. بررسی کنید که آیا می‌توانید مستقیماً از هر یک از پردازنده‌های پیام با استفاده از دستور telnet به سرور backend خاص متصل شوید یا خیر:

telnet <BackendServer-HostName> 443
      

5. اگر بتوانید به سرور backend متصل شوید، ممکن است پیامی مانند Connected to backend-server را مشاهده کنید. در این صورت، مشکل ممکن است موقتی باشد و یا حل شود یا یک مشکل متناوب باشد. مرحله ۴ را چندین بار (بیش از ۱۰ بار) تکرار کنید و خروجی را بررسی کنید.
1. اگر به طور مداوم خطایی در دستور telnet وجود ندارد، مشکل حل شده است. دوباره بررسی کنید که آیا خطاهای بررسی سلامت متوقف شده‌اند یا خیر. اگر بله، دیگر لازم نیست کار دیگری انجام دهید.
2. اگر نمی‌توانید به طور متناوب با دستور telnet به سرور backend متصل شوید، ممکن است مشکل شبکه وجود داشته باشد یا سرور backend شما شلوغ باشد.
6. اگر نمی‌توانید به طور مداوم با دستور telnet به سرور backend متصل شوید، ممکن است به این دلیل باشد که ترافیک از پردازنده‌های پیام روی سرور backend خاص مجاز نیست.

وضوح تصویر

اگر خطای connection timed out به طور مداوم مشاهده می‌شود، مطمئن شوید که سرور backend هیچ محدودیت فایروالی ندارد و اجازه عبور ترافیک از پردازنده‌های پیام Apigee Edge را می‌دهد. به عنوان مثال، در لینوکس، می‌توانید از iptables برای اجازه عبور ترافیک از آدرس‌های IP پردازنده پیام در سرور backend استفاده کنید.

اگر مشکل همچنان ادامه داشت، برای تعیین و رفع مشکل با مدیر شبکه خود مشورت کنید. در صورت نیاز به هرگونه کمک بیشتر از 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 برای سرور هدف مورد استفاده در API Proxy خاص که برای آن کد پاسخ ۵۰۳ با کد خطای 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) روی پورت غیر امن ۸۰ است.

   این خطا می‌تواند تحت دو سناریوی زیر رخ دهد:

   • سرور هدف امن با پورت غیر امن تعریف شده است
   • سرور هدف امن تعریف شده است اما Health Monitor با یک پورت غیر امن پیکربندی شده است

   پورت امن هدف غیر امن

   سناریو ۱: سرور هدف امن با پورت غیر امن تعریف شده است

   اگر یک سرور هدف امن تعریف کرده‌اید اما پورت آن ناامن است، مثلاً ۸۰، این خطا را دریافت می‌کنید. برای بررسی اینکه آیا این دلیل مشکل است یا خیر، مراحل زیر را دنبال کنید:

   1. تعریف سرور هدف مورد استفاده در پیکربندی نقطه پایانی هدف را بررسی کنید.

   برای دریافت تعریف سرور هدف از API Get TargetServer استفاده کنید.

   خروجی تعریف سرور هدف

   <TargetServer name="mocktarget">
     <Host>mocktarget.apigee.net</Host>
     <Port>80</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>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      توجه داشته باشید که هیچ عنصر <Port> در پیکربندی Health Monitor بالا مشخص نشده است. در این حالت، پردازنده پیام Edge از پورت مشخص شده در تعریف سرور هدف (که 80 است) برای انجام فراخوانی‌های API بررسی سلامت استفاده می‌کند.

   3. بر اساس اطلاعات فوق، علت این خطا این است که سرور هدف به عنوان یک سرور امن تعریف شده است (زیرا بلوک SSLInfo فعال است)، اما پورت ۸۰ آن ناامن است.

   پورت HM غیر امن هدف امن

   سناریو ۲: سرور هدف امن تعریف شده اما Health Monitor با یک پورت غیر امن پیکربندی شده است

   اگر یک سرور هدف امن تعریف کرده‌اید اما Health Monitor با یک پورت غیر امن مانند ۸۰ پیکربندی شده است، این خطا را دریافت می‌کنید. برای تأیید اینکه آیا این دلیل این مشکل است، مراحل زیر را دنبال کنید:

   1. تعریف سرور هدف مورد استفاده در پیکربندی نقطه پایانی هدف را بررسی کنید.

      برای دریافت تعریف سرور هدف از API Get TargetServer استفاده کنید.

      خروجی تعریف سرور هدف

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

      در مثال بالا، مانیتور سلامت با یک پورت غیر امن ۸۰ پیکربندی شده است، همانطور که با عنصر <Port> نشان داده شده است.

   3. بر اساس اطلاعات فوق، علت این خطا این است که سرور هدف به عنوان یک سرور امن تعریف شده است (زیرا بلوک SSLInfo فعال است) و از پورت امن ۴۴۳ استفاده می‌کند، اما Health Monitor طوری پیکربندی شده است که بررسی‌های سلامت را با پورت غیر امن ۸۰ (که در عنصر <Port> مشخص شده است) انجام دهد.

      یعنی، در این حالت، Edge بررسی سلامت APIها را به عنوان یک فراخوانی امن با پورت غیر امن ۸۰ انجام می‌دهد و با خطای فوق‌الذکر شکست می‌خورد.

وضوح تصویر

<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 در 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 برای سرور هدف مورد استفاده در API Proxy خاص که برای آن کد پاسخ ۵۰۳ با کد خطای NoActiveTargets را تجربه می‌کنید، به حد نصاب رسیده است.

4. بررسی سلامت با خطای زیر انجام نشد:

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

   پیام خطا و URL نشان می‌دهند که علت این مشکل، برقراری یک تماس غیر امن (HTTP) روی پورت امن ۴۴۳ است.

   این خطا می‌تواند تحت دو سناریوی زیر رخ دهد:

   • سرور هدف غیر امن با پورت امن تعریف شده است
   • سرور هدف غیر امن تعریف شده است اما Health Monitor با یک پورت امن پیکربندی شده است

   پورت امن هدف غیر امن

   سناریو ۱: سرور هدف غیر امن با پورت امن تعریف شده است

   اگر یک سرور هدف غیر امن اما با پورت امن مانند ۴۴۳ تعریف کرده‌اید، این خطا را دریافت می‌کنید. برای تأیید اینکه آیا این دلیل این مشکل است، مراحل زیر را دنبال کنید:

   1. تعریف سرور هدف مورد استفاده در پیکربندی نقطه پایانی هدف را بررسی کنید.

      برای دریافت تعریف سرور هدف از API Get TargetServer استفاده کنید.

      خروجی تعریف سرور هدف

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

      در مثال بالا، تعریف نشان می‌دهد که سرور هدف mocktarget یک سرور غیر امن است زیرا هیچ بلوک SSLInfo وجود ندارد. با این حال، به طور نادرست با پورت امن ۴۴۳ پیکربندی شده است.

   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 از پورت مشخص شده در تعریف سرور هدف که ۴۴۳ است استفاده خواهد کرد.

   3. بر اساس اطلاعات فوق، علت این خطا این است که سرور هدف به عنوان یک سرور غیر امن تعریف شده است (زیرا بلوک SSLInfo تعریف نشده است)، اما دارای پورت امن ۴۴۳ است.

      یعنی، Edge بررسی‌های سلامت را به عنوان یک فراخوانی غیر امن با پورت امن ۴۴۳ انجام می‌دهد و با خطای فوق‌الذکر شکست می‌خورد.

   پورت HM امن هدف غیر امن

   سناریو ۲: سرور هدف غیر امن تعریف شده اما Health Monitor با یک پورت امن پیکربندی شده است

   اگر یک سرور هدف غیر امن تعریف کرده‌اید اما Health Monitor با یک پورت امن مانند ۴۴۳ پیکربندی شده است، این خطا را دریافت می‌کنید. برای تأیید اینکه آیا این دلیل این مشکل است، مراحل زیر را دنبال کنید:

   1. تعریف سرور هدف مورد استفاده در پیکربندی نقطه پایانی هدف را بررسی کنید.

      برای دریافت تعریف سرور هدف از API Get TargetServer استفاده کنید.

      خروجی تعریف سرور هدف

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

      در مثال بالا، تعریف نشان می‌دهد که سرور هدف mocktarget یک سرور غیر امن است (زیرا هیچ بلوک SSLInfo وجود ندارد) که به درستی با پورت غیر امن ۸۰ پیکربندی شده است.

   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>
            

      در مثال بالا، مانیتور سلامت با پورت امن ۴۴۳ پیکربندی شده است، همانطور که توسط عنصر <Port> نشان داده شده است.

   3. بر اساس اطلاعات فوق، علت این خطا این است که سرور هدف به عنوان یک سرور غیر امن تعریف شده است (زیرا بلوک SSLInfo تعریف نشده است) و پورت غیر امن ۸۰ به درستی فعال است، اما Health Monitor طوری پیکربندی شده است که بررسی‌های سلامت را با پورت امن ۴۴۳ (که در عنصر <Port> مشخص شده است) انجام دهد.

      یعنی، در این حالت، Edge بررسی‌های سلامت را به عنوان یک فراخوانی غیر امن با پورت امن ۴۴۳ انجام می‌دهد و با خطای فوق‌الذکر شکست می‌خورد.

وضوح تصویر

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

علت: 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 برای سرور هدف مورد استفاده در API Proxy خاص که برای آن کد پاسخ ۵۰۳ با کد خطای NoActiveTargets را تجربه می‌کنید، به حد نصاب رسیده است.

4. بررسی سلامت، پیام هشدار زیر را نشان داد:

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

   پیام هشدار بالا بیان می‌کند که کد پاسخ مورد انتظار برای API بررسی سلامت، ۲۰۰ بوده است ، اما پاسخ واقعی دریافتی ۴۰۴ است . از این رو، این به عنوان یک شکست در نظر گرفته می‌شود.

5. قبل از بررسی علت پاسخ خطا از API بررسی سلامت، مشخص کنید که چرا Edge انتظار کد پاسخ ۲۰۰ را برای 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 با کد پاسخ ۲۰۰ در زیر عنصر <SuccessResponse> پیکربندی شده است. این بدان معناست که اگر Edge هر کد پاسخی (مانند ۴۰۰، ۴۰۱، ۴۰۴، ۵۰۰) غیر از ۲۰۰ را از API بررسی سلامت دریافت کند، به عنوان یک خطا در نظر گرفته می‌شود و تعداد شکست‌ها را افزایش می‌دهد.

6. اکنون، برای بررسی علت پاسخ خطا از API بررسی سلامت، مراحل زیر را دنبال کنید:
1. به پیام قبل از پیام هشدار در گزارش پردازشگر پیام نگاه کنید.

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

   آدرس اینترنتی بررسی سلامت را از این پیام یادداشت کنید.

2. شما می‌توانید مستقیماً از پردازشگر پیام به این URL دسترسی پیدا کنید و پاسخ واقعی را بررسی کنید.

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

   همانطور که در لاگ‌های پردازشگر پیام مشاهده می‌شود، پاسخ حاصل از فراخوانی فوق، کد ۴۰۴ را ارائه می‌دهد:

   < HTTP/2 404
             

3. این نشان می‌دهد که حتی فراخوانی مستقیم به URL بررسی سلامت با همان کد پاسخ ۴۰۴ با شکست مواجه می‌شود. این بدان معناست که URL بررسی سلامت ممکن است نادرست باشد یا منبعی که به عنوان بخشی از URL به آن دسترسی پیدا شده است، دیگر در دسترس نیست.
4. در مثال API بررسی سلامت ارائه شده در بالا، این مشکل به این دلیل رخ می‌دهد که از یک URL نادرست در پیکربندی Health Monitor استفاده شده است. URL صحیح از Mock Target API، https://mocktarget.apigee.net:443/statuscode/200 است.
7. اگر با خطای دیگری مواجه شدید، با دنبال کردن مراحل بالا علت آن را مشخص کنید. در صورت لزوم، با تیم پشتیبان خود همکاری کنید.

وضوح تصویر

1. مشکل مربوط به API بررسی سلامت در سرور backend خود را برطرف کنید.
2. برای رفع مشکل در مثال مورد بحث در بالا:
1. عنصر <Path> را در پیکربندی Health Monitor به /statuscode/200 مطابق شکل زیر تغییر دهید:

   <Path>/statuscode/200</Path>
           

2. تغییرات را در API Proxy ذخیره کنید.

اگر مشکل همچنان ادامه داشت، به «اطلاعات تشخیصی مورد نیاز برای جمع‌آوری» بروید.

تشخیص مشکلات با استفاده از نظارت بر API

مانیتورینگ API به شما این امکان را می‌دهد که به سرعت حوزه‌های مشکل‌دار را جدا کنید تا مشکلات خطا، عملکرد و تأخیر و منبع آنها، مانند برنامه‌های توسعه‌دهنده، پروکسی‌های API، اهداف backend یا پلتفرم API را تشخیص دهید.

یک سناریوی نمونه را که نحوه عیب‌یابی مشکلات 5xx با APIهای شما را با استفاده از API Monitoring نشان می‌دهد، قدم به قدم بررسی کنید . برای مثال، ممکن است بخواهید هشداری تنظیم کنید تا وقتی تعداد خطاهای messaging.adaptors.http.flow.NoActiveTargets از یک آستانه خاص فراتر رفت، مطلع شوید.

باید اطلاعات تشخیصی جمع‌آوری کند

اگر مشکل حتی پس از دنبال کردن دستورالعمل‌های بالا همچنان ادامه داشت، لطفاً اطلاعات تشخیصی زیر را جمع‌آوری کنید. با پشتیبانی Apigee تماس بگیرید و آنها را به اشتراک بگذارید:

1. اگر کاربر فضای ابری عمومی هستید، اطلاعات زیر را ارائه دهید:
1. نام سازمان
2. نام محیط
3. نام پروکسی API
4. دستور curl را برای بازتولید خطا کامل کنید
5. فایل ردیابی حاوی درخواست‌هایی با خطای ۵۰۳ Service Unavailable با کد خطای NoActiveTargets
2. اگر کاربر Private Cloud هستید، اطلاعات زیر را ارائه دهید:
   1. پیام خطای کامل مشاهده شد
   2. نام محیط
   3. بسته پروکسی API
   4. فایل ردیابی حاوی درخواست‌هایی با خطای ۵۰۳ Service Unavailable با کد خطای NoActiveTargets
   5. گزارش‌های دسترسی NGINX

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

   6. گزارش‌های پردازنده پیام

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