‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

‫۵۰۳ سرویس دردسترس نیست - NoActiveTargets - HealthCheckFailures

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

ویدیوها

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

ویدیو	شرح
عیب‌یابی و رفع خطای ۵۰۳ سرویس دردسترس نیست - NoActiveTargets	درباره موارد زیر بیشتر بدانید: اهمیت سرورهای هدف و پایشگرهای سلامت عیب‌یابی و رفع خطای هم‌زمان ۵۰۳ «سرویس دردسترس نیست» - NoActiveTargets که به‌دلیل عدم موفقیت در بررسی سلامت ایجاد شده است

نشانه

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

پیام خطا

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

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 معمولاً زمانی مشاهده می‌شود که از یک یا چند سرور هدف در پیکربندی نقطه پایانی هدف در «پراکسی API» خود استفاده می‌کنید.

این کتابچه راهنما 503 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 رسیده است:

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

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

استفاده از «پایشگر سلامت» به Apigee Edge کمک می‌کند تا وقتی سرور مقصد سالم می‌شود، آن را به‌طور خودکار بدون نیاز به استقرار مجدد «پراکسی API» به چرخش برگرداند.

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

علت	شرح	چه کسی می‌تواند مراحل عیب‌یابی را انجام دهد
خطای مهلت اتصال	«پردازشگر پیام» نمی‌تواند در بازه زمانی مشخص‌شده در پیکربندی «ترازکننده بار» به سرور هدف متصل شود.	کاربران Edge Private Cloud
درخواست امن در درگاه غیرامن	اگر سرور مقصد به‌عنوان سرور امن تعریف شده باشد، اما با درگاه غیرامن به‌طور نادرست پیکربندی شده باشد. اگر سرور هدف به‌عنوان سرور ایمن تعریف شده باشد، اما پایشگر سلامت برای انجام بررسی‌های سلامت در درگاه غیرایمن پیکربندی شده باشد.	کاربران Edge Private Cloud
درخواست غیرایمن در درگاه ایمن	اگر سرور مقصد به‌عنوان سرور غیرامن تعریف شده باشد، اما به‌اشتباه با درگاه امن پیکربندی شده باشد. اگر سرور هدف به‌عنوان سرور غیرامن تعریف شده باشد، اما پایشگر سلامت برای انجام بررسی‌های سلامت در درگاه امن پیکربندی شده باشد.	کاربران Edge Private Cloud
میانای برنامه‌سازی کاربردی «بررسی سلامت» با خطا پاسخ می‌دهد	اگر میانای برنامه‌سازی کاربردی بررسی سلامت با خطا یا کد پاسخ، یا هر چیزی به‌جز آنچه در عنصر SuccessResponse «پایش سلامت» مشخص شده است پاسخ دهد.	کاربران Edge Private Cloud

مراحل متداول تشخیص خرابی

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

ابزار ردیابی

برای تعیین شناسه پیام درخواست ناموفق بااستفاده از ابزار «ردیابی»:

جلسه ردیابی را فعال کنید، فراخوانی API را انجام دهید، و مشکل - ۵۰۳ سرویس دردسترس نیست با کد خطای NoActiveTargets را بازتولید کنید.
یکی از درخواست‌های ناموفق را انتخاب کنید.
به فاز AX پیمایش کنید و با پیمایش به پایین در بخش جزئیات فاز، شناسه پیام درخواست را تعیین کنید (X-Apigee.Message-ID) همان‌گونه که در شکل زیر نشان داده شده است.

گزارش‌های دسترسی NGINX

برای تعیین شناسه پیام درخواست ناموفق بااستفاده از گزارش‌های دسترسی NGINX:

همچنین می‌توانید به گزارش‌های NGINX Access مراجعه کنید تا شناسه پیام خطاهای ۵۰۳ را تعیین کنید. این ویژگی به‌ویژه درصورتی مفید است که مشکل در گذشته رخ داده باشد یا مشکل متناوب باشد و نتوانید ردگیری را در واسط کاربر ضبط کنید. برای تعیین این اطلاعات از گزارش‌های دسترسی NGINX، از مراحل زیر استفاده کنید:

گزارش‌های دسترسی NGINX را بررسی کنید: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
جستجو کنید که آیا خطاهای ۵۰۳ برای پراکسی API خاص در طول یک دوره زمانی خاص وجود دارد یا خیر (اگر مشکل در گذشته رخ داده است) یا اینکه آیا درخواست‌هایی هنوز با خطای ۵۰۳ ناموفق هستند یا خیر.
اگر خطاهای ۵۰۳ با پیام‌رسانی X-Apigee-fault-code.adaptors.http.flow.NoActiveTargets وجود دارد، شناسه پیام را برای یک یا چند درخواست ازاین‌دست همان‌گونه که در مثال زیر نشان داده شده است یادداشت کنید:
نمونه ورودی نشان‌دهنده خطای ۵۰۳

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

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

پیام‌های خطای رایج مشاهده‌شده در گزارش‌های «پردازشگر پیام» (/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 (بدون هدف فعال) را به‌عنوان پاسخ به مشتری ارسال می‌کند.

دلیل: مهلت اتصال تمام شد

تشخیص

شناسه پیام درخواست ناموفق را تعیین کنید.
شناسه پیام را در گزارش «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log) جستجو کنید.
پیام‌های خطای رایج مربوط به شناسه پیام را خواهید دید. بااین‌حال، برای یافتن دلیل واقعی عدم موفقیت بررسی وضعیت، به بالای این پیام‌های خطای رایج پیمایش کنید و خطاهای «پایش وضعیت» را بررسی کنید.
برای مثال، پیام خطای زیر از «پایش سلامت» نشان می‌دهد که «پردازشگر پیام» هنگام ایجاد درخواست «میانای برنامه‌سازی کاربردی» بررسی سلامت با خطای پایان مهلت اتصال ناموفق بوده است:
```
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 برای سرور هدفی که در «پراکسی میانای برنامه‌سازی کاربردی» خاصی استفاده می‌شود و برای آن کد پاسخ ۵۰۳ با کد خطای NoActiveTargets را تجربه می‌کنید، به حد موردنظر رسیده است.
در مثال بالا، بررسی سلامت با خطای connection timed out ناموفق بود. بررسی کنید که آیا می‌توانید بااستفاده از دستور telnet مستقیماً از هریک از «پردازشگرهای پیام» به سرور زیرینه خاص متصل شوید یا نه:

telnet <BackendServer-HostName> 443

اگر بتوانید به سرور زیرینه متصل شوید، ممکن است پیامی مانند متصل به سرور زیرینه ببینید. در این صورت، مشکل ممکن است موقتی باشد و یا برطرف شود یا مشکلی متناوب باشد. مرحله ۴ را چند بار (بیش‌از ۱۰ بار) تکرار کنید و برونداد را درستی‌سنجی کنید.

اگر فرمان telnet به‌طور مداوم خطا ندارد، مشکل برطرف شده است. دوباره بررسی کنید که آیا خطاهای بررسی سلامت متوقف شده‌اند یا نه. اگر بله، دیگر لازم نیست کاری انجام دهید.
اگر نمی‌توانید به‌طور متناوب با فرمان telnet به سرور زیرینه متصل شوید، ممکن است مشکل شبکه وجود داشته باشد یا سرور زیرینه شما مشغول باشد.

اگر نمی‌توانید به‌طور مداوم با فرمان telnet به سرور زیرینه متصل شوید، احتمالاً به این دلیل است که ترافیک از «پردازشگرهای پیام» در سرور زیرینه خاص مجاز نیست.

وضوح

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

اگر مشکل برطرف نشد، با سرپرست شبکه خود همکاری کنید تا مشکل را تشخیص دهید و آن را برطرف کنید. اگر به کمک بیشتری از Apigee نیاز دارید، با پشتیبانی Apigee تماس بگیرید.

دلیل: درخواست ایمن در درگاه غیرایمن

تشخیص

شناسه پیام درخواست ناموفق را تعیین کنید.
شناسه پیام را در گزارش «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log) جستجو کنید.
پیام‌های خطای رایج مربوط به شناسه پیام را خواهید دید. بااین‌حال، برای یافتن دلیل واقعی عدم موفقیت بررسی وضعیت، به بالای این پیام‌های خطای رایج پیمایش کنید و خطاهای «پایش وضعیت» را بررسی کنید.
برای مثال، ممکن است خطای «پایشگر سلامت» را همان‌طور که در زیر نشان داده شده است ببینید:
```
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 برای سرور هدفی که در «پراکسی میانای برنامه‌سازی کاربردی» خاصی استفاده می‌شود و برای آن کد پاسخ ۵۰۳ با کد خطای NoActiveTargets را تجربه می‌کنید، به حد موردنظر رسیده است.
بررسی سلامت با این خطا ناموفق بود:
```
Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
      
```
پیام خطا و نشانی وب نشان می‌دهد که دلیل این مشکل این است که تماس امن (HTTPS) در درگاه غیرامن ۸۰ برقرار شده است.

این خطا می‌تواند در دو سناریو زیر رخ دهد:
- سرور هدف ایمن با درگاه غیرایمن تعریف شده است
- سرور هدف ایمن تعریف شده است اما «پایش سلامت» با درگاه غیرایمن پیکربندی شده است
درگاه غیرامن هدف امن

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

اگر سرور مقصد امنی را تعریف کرده‌اید اما با درگاه غیرامنی مثل ۸۰، این خطا را دریافت می‌کنید. برای درستی‌سنجی اینکه آیا این دلیل مشکل است یا نه، مراحل زیر را دنبال کنید:
1. تعریف سرور هدف استفاده‌شده در پیکربندی نقطه پایان هدف را بررسی کنید.
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 از درگاه مشخص‌شده در تعریف سرور هدف (که ۸۰ است) برای فراخوانی‌های API بررسی وضعیت استفاده می‌کند.
3. براساس اطلاعات بالا، دلیل این خطا این است که سرور مقصد به‌عنوان سرور امن تعریف شده است (زیرا بلوک SSLInfo فعال است)، اما با درگاه غیرامن ۸۰.
درگاه HM غیرامن هدف امن

سناریو ۲: سرور هدف ایمن تعریف شده است اما «پایش سلامت» با درگاه غیرایمن پیکربندی شده است

اگر سرور هدف امنی تعریف کرده‌اید اما «پایش سلامت» با درگاه غیرامنی مثل ۸۰ پیکربندی شده است، این خطا را دریافت می‌کنید. برای درستی‌سنجی اینکه آیا این دلیل مشکل است یا نه، مراحل زیر را دنبال کنید:
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>
  در مثال بالا، «پایشگر سلامت» با «درگاه ۸۰» غیرامن پیکربندی شده است، همان‌طور که عنصر <Port> نشان می‌دهد.
3. براساس اطلاعات بالا، دلیل این خطا این است که کارساز هدف به‌عنوان کارساز امن تعریف شده است (زیرا بلوک SSLInfo فعال است) و از درگاه امن ۴۴۳ استفاده می‌کند، اما «پایش سلامت» پیکربندی شده است تا بررسی‌های سلامت را با درگاه غیرامن ۸۰ (که در عنصر <Port> مشخص شده است) انجام دهد.
  یعنی در این مورد، Edge واسط‌های برنامه‌سازی کاربردی بررسی سلامت را به‌عنوان یک تماس ایمن با درگاه غیرایمن ۸۰ برقرار می‌کند و با خطای ذکرشده در بالا مواجه می‌شود.
  
  توجه: عنصر <Port> پیکربندی‌شده در «پایشگر سلامت» بر درگاه استفاده‌شده در تعریف سرور هدف اولویت دارد.

وضوح

درگاه غیرامن هدف امن

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

برای رفع این خطا، تعریف سرور هدف را به‌روز کنید تا از درگاه امن مناسبی استفاده کند.

از «میانای برنامه‌سازی کاربردی» «به‌روزرسانی سرور هدف» برای به‌روزرسانی تعریف سرور هدف استفاده کنید و مطمئن شوید که از درگاه امن (برای نمونه: ۴۴۳) استفاده می‌شود، همان‌طور که در مثال زیر نشان داده شده است:

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

درگاه HM غیرامن هدف امن

سناریو ۲: سرور هدف امن تعریف شده است اما «پایش سلامت» با درگاه غیرامن پیکربندی شده است

برای رفع این خطا، دستورالعمل‌های زیر را دنبال کنید:

پیکربندی «پایشگر وضعیت» را تغییر دهید تا از درگاه امن (برای مثال: ۴۴۳) برای انجام بررسی‌های وضعیت سرور هدف در پیکربندی نقطه پایانی هدف «پراکسی میانای برنامه‌سازی کاربردی» ناموفق استفاده کند، همان‌طور که در زیر نشان داده شده است:

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

تغییرات را در «پراکسی API» ذخیره کنید.

دلیل: درخواست غیرایمن در درگاه ایمن

تشخیص

شناسه پیام درخواست ناموفق را تعیین کنید.
شناسه پیام را در گزارش «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log) جستجو کنید.
پیام‌های خطای رایج مربوط به شناسه پیام را خواهید دید. بااین‌حال، برای یافتن دلیل واقعی عدم موفقیت بررسی وضعیت، به بالای این پیام‌های خطای رایج پیمایش کنید و خطاهای «پایش وضعیت» را بررسی کنید.
برای مثال، ممکن است خطای «پایشگر سلامت» را همان‌طور که در زیر نشان داده شده است ببینید:
```
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 برای سرور هدفی که در «پراکسی میانای برنامه‌سازی کاربردی» خاصی استفاده می‌شود و برای آن کد پاسخ ۵۰۳ با کد خطای NoActiveTargets را تجربه می‌کنید، به حد موردنظر رسیده است.
بررسی سلامت با این خطا ناموفق بود:
```
Error sending request Request URL : http://mocktarget.apigee.net:443/status
java.net.SocketException: Unexpected end of file from server
      
```
پیام خطا و نشانی وب نشان می‌دهد که دلیل این مشکل این است که یک تماس غیرامن (HTTP) در درگاه امن ۴۴۳ برقرار شده است.

این خطا می‌تواند در دو سناریو زیر رخ دهد:
- سرور مقصد غیرامن با درگاه امن تعریف شده است
- سرور مقصد غیرامن تعریف شده است اما «پایش سلامت» با درگاه امن پیکربندی شده است
درگاه ایمن هدف غیرایمن

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

اگر سرور مقصد غیرامنی را تعریف کرده‌اید اما درگاهی امن مثل ۴۴۳ را تعریف کرده‌اید، این خطا را دریافت می‌کنید. برای درستی‌سنجی اینکه آیا این دلیل مشکل است یا نه، مراحل زیر را دنبال کنید:
1. تعریف سرور هدف استفاده‌شده در پیکربندی نقطه پایان هدف را بررسی کنید.
  از میانای برنامه‌سازی کاربردی Get TargetServer برای دریافت تعریف سرور هدف استفاده کنید.
  
  برونداد تعریف سرور هدف
  <TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer>
  در مثال بالا، تعریف نشان می‌دهد که سرور هدف mocktarget سرور غیرامنی است زیرا بلوک SSLInfo وجود ندارد. بااین‌حال، با درگاه امن ۴۴۳ پیکربندی نادرستی شده است.
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 از درگاه مشخص‌شده در تعریف سرور هدف که ۴۴۳ است استفاده خواهد کرد.
3. براساس اطلاعات بالا، دلیل این خطا این است که سرور هدف به‌عنوان سرور غیرامن تعریف شده است (زیرا بلوک SSLInfo تعریف نشده است)، اما با درگاه امن ۴۴۳.
  یعنی Edge بررسی‌های سلامت را به‌عنوان یک تماس غیرایمن با درگاه امن ۴۴۳ انجام می‌دهد و با خطای ذکرشده در بالا مواجه می‌شود.
درگاه HM ایمن هدف غیرایمن

سناریو ۲: سرور مقصد غیرامن تعریف شده است اما «پایش سلامت» با درگاه امن پیکربندی شده است

اگر سرور هدف غیرامنی را تعریف کرده‌اید اما «پایش سلامت» با درگاه امنی مثل ۴۴۳ پیکربندی شده است، این خطا را دریافت می‌کنید. برای درستی‌سنجی اینکه آیا این دلیل مشکل است یا نه، مراحل زیر را دنبال کنید:
1. تعریف سرور هدف استفاده‌شده در پیکربندی نقطه پایان هدف را بررسی کنید.
  از Get TargetServer API برای دریافت تعریف سرور هدف استفاده کنید.
  
  برونداد تعریف سرور هدف
  <TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
  در مثال بالا، تعریف نشان می‌دهد که سرور هدف mocktarget سروری غیرامن است (زیرا بلوک SSLInfo وجود ندارد) که با درگاه غیرامن ۸۰ به‌درستی پیکربندی شده است.
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>
  در مثال بالا، «پایشگر سلامت» با «درگاه ایمن ۴۴۳» پیکربندی شده است، همان‌گونه که عنصر <Port> نشان می‌دهد.
3. براساس اطلاعات بالا، دلیل این خطا این است که سرور هدف به‌عنوان سرور غیرامن (چون بلوک SSLInfo تعریف نشده است) با درگاه غیرامن ۸۰ به‌درستی تعریف شده است، اما «پایش سلامت» پیکربندی شده است تا بررسی‌های سلامت را با درگاه امن ۴۴۳ (مشخص‌شده در عنصر <Port>) انجام دهد.
  یعنی در این مورد، Edge بررسی‌های سلامت را به‌عنوان تماسی غیرایمن با درگاه ایمن ۴۴۳ انجام می‌دهد و با خطای ذکرشده در بالا ناموفق می‌شود.

وضوح

درگاه ایمن هدف غیرایمن

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

برای رفع این خطا، تعریف سرور هدف را به‌روز کنید تا از درگاه امن مناسبی استفاده کند.

از «میانای برنامه‌سازی کاربردی به‌روزرسانی سرور هدف» برای به‌روزرسانی تعریف سرور هدف استفاده کنید و مطمئن شوید که از درگاه غیرامن (برای نمونه: ۸۰) استفاده می‌شود همان‌طور که در مثال زیر نشان داده شده است:

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

درگاه HM ایمن هدف غیرایمن

سناریو ۲: سرور مقصد غیرامن تعریف شده است اما «پایش سلامت» با درگاه امن پیکربندی شده است

برای رفع این خطا، دستورالعمل‌های زیر را دنبال کنید:

یا عنصر <Port> را از پیکربندی «پایش سلامت» بردارید یا پیکربندی «پایش سلامت» را تغییر دهید تا از درگاه غیرامن (برای مثال: ۸۰) برای انجام بررسی‌های سلامت سرور هدف در پیکربندی نقطه پایانی هدف «پراکسی API» ناموفق استفاده کند، همان‌طور که در زیر نشان داده شده است:
```
<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>
        
```
تغییرات را در «پراکسی API» ذخیره کنید.

دلیل: میانای برنامه‌سازی کاربردی بررسی سلامت با خطا پاسخ می‌دهد

تشخیص

شناسه پیام درخواست ناموفق را تعیین کنید.
شناسه پیام را در گزارش «پردازشگر پیام» (/opt/apigee/var/log/edge-message-processor/logs/system.log) جستجو کنید.
پیام‌های خطای رایج مربوط به شناسه پیام را خواهید دید. بااین‌حال، برای دریافت دلیل واقعی عدم موفقیت بررسی وضعیت، به بالای این پیام‌های خطای رایج پیمایش کنید و «خطاها/هشدارهای پایش وضعیت» را بررسی کنید.
برای مثال، ممکن است هشدار «پایشگر سلامت» را همان‌طور که در زیر نشان داده شده است ببینید:
```
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 برای سرور هدفی که در «پراکسی میانای برنامه‌سازی کاربردی» خاصی استفاده می‌شود و برای آن کد پاسخ ۵۰۳ با کد خطای NoActiveTargets را تجربه می‌کنید، به حد موردنظر رسیده است.
بررسی سلامت پیام هشدار زیر را برگرداند:
```
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
      
```
پیام هشدار بالا بیان می‌کند که کد پاسخ موردانتظار برای میانای برنامه‌سازی کاربردی بررسی وضعیت ۲۲۰ بوده است، اما پاسخ واقعی دریافتی ۴۰۴ است. بنابراین، این مورد به‌عنوان ناموفق درنظر گرفته می‌شود.
قبل‌از بررسی علت پاسخ خطا از میانای برنامه‌سازی کاربردی بررسی وضعیت، تعیین کنید چرا Edge انتظار دارد کد پاسخ میانای برنامه‌سازی کاربردی بررسی وضعیت ۲۰۰ باشد. برای این کار، پیکربندی «پایش سلامت» را برای سرور هدف در پیکربندی نقطه پایان هدف بررسی کنید:
پیکربندی پایشگر وضعیت
```
<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>
        
```
توجه داشته باشید که پیکربندی «پایشگر سلامت» با کد پاسخ ۲۰۰ در عنصر <SuccessResponse> پیکربندی شده است. این یعنی اگر Edge کد پاسخی (مثل ۴۰۰، ۴۰۱، ۴۰۴، ۵۰۰) به‌جز ۲۰۰ از میانای برنامه‌سازی کاربردی بررسی وضعیت دریافت کند، این کد به‌عنوان خطا درنظر گرفته می‌شود و تعداد خطاها را افزایش می‌دهد.
اکنون برای بررسی علت پاسخ خطا از «میانای برنامه‌سازی کاربردی بررسی سلامت»، مراحل زیر را دنبال کنید:

پیام قبل‌از پیام هشدار را در گزارش «پردازشگر پیام» ببینید.
```
Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
          
```
نشانی وب بررسی سلامت را از این پیام یادداشت کنید.
می‌توانید از «پردازشگر پیام» با این نشانی وب تماس مستقیم برقرار کنید و پاسخ واقعی را بررسی کنید
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
پاسخ تماس بالا ۴۰۴ را نشان می‌دهد، همان‌طور که در گزارش‌های «پردازنده پیام» دیده می‌شود:
```
< HTTP/2 404
          
```
این نشان می‌دهد که حتی تماس مستقیم با نشانی وب بررسی سلامت نیز با همان کد پاسخ ۴۰۴ ناموفق است. این یعنی نشانی وب بررسی سلامت ممکن است نادرست باشد یا منبعی که به‌عنوان بخشی از نشانی وب به آن دسترسی پیدا می‌شود دیگر دردسترس نیست.
در میانای برنامه‌سازی کاربردی بررسی وضعیت سلامت ارائه‌شده در بالا، مشکل از آنجا ناشی می‌شود که نشانی وب نادرستی در پیکربندی «پایش وضعیت سلامت» استفاده شده است. نشانی وب صحیح https://mocktarget.apigee.net:443/statuscode/200 از میانای برنامه‌سازی کاربردی هدف ساختگی پیدا شد.

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

وضوح

مشکل مربوط به میانای برنامه‌سازی کاربردی بررسی سلامت در سرور زیرینه را برطرف کنید.
برای رفع مشکل در مثال بالا:

عنصر <Path> را در پیکربندی «پایشگر سلامت» به /statuscode/200 تغییر دهید، همان‌طور که در زیر نشان داده شده است:
```
<Path>/statuscode/200</Path>
        
```
تغییرات را در «پراکسی API» ذخیره کنید.

اگر مشکل همچنان ادامه داشت، به اطلاعات تشخیصی ضروری بروید.

عیب‌یابی مشکلات بااستفاده از پایش API

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

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

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

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

اگر کاربر «ابر عمومی» هستید، اطلاعات زیر را ارائه دهید:

Organization Name
نام محیط
نام پراکسی میانای برنامه‌سازی کاربردی
فرمان curl را برای بازتولید خطا تکمیل کنید
فایل ردیابی حاوی درخواست‌های «۵۰۳ سرویس دردسترس نیست» با کد خطای NoActiveTargets

اگر کاربر «ابر خصوصی» هستید، اطلاعات زیر را ارائه دهید:
1. پیام خطای کامل مشاهده شد
2. نام محیط
3. دسته «پراکسی میانای برنامه‌سازی کاربردی»
4. فایل ردیابی حاوی درخواست‌های «۵۰۳ سرویس دردسترس نیست» با کد خطای 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)