503 שירות לא זמין – NoActiveTargets – HealthCheckFailures

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

סרטונים

לקבלת מידע נוסף על שגיאות 503, אפשר לצפות בסרטונים הבאים:

תיאור הבעיה

אפליקציית הלקוח מקבלת את קוד הסטטוס 503 של תגובת HTTP עם ההודעה Service Unavailable וקוד השגיאה NoActiveTargets של בקשות שרת ה-API של שרת ה-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 לא זמין עם קוד השגיאה NoActiveTargets בדרך כלל מתועדת כשמשתמשים בשרת יעד אחד או יותר בהגדרת נקודת הקצה (endpoint) של היעד ב-API של שרת ה-proxy.

המדריך הזה כולל מידע על השירות 503 לא זמין עם קוד השגיאה NoActiveTargets שנוצר עקב כשלים בבדיקות התקינות. במדריך הזה מוסבר על סיבות אחרות לשגיאה הזו.

כשלים בבדיקת התקינות

הכשלים בבדיקת התקינות ייבדקו רק אם הגדרתם Health Monitor כחלק מהגדרת איזון העומסים ביעד של השרת, בנקודת הקצה של היעד של שרת ה-proxy של ה-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:

• השם של שרת היעד
• שמות של ארגונים וסביבות
• שם שרת proxy ל-API
• השם של נקודת הקצה (endpoint) של היעד

לאחר מכן, Edge מפסיק לשלוח בקשות נוספות לשרת הספציפי הזה. אחרי שכל שרתי היעד שהוגדרו בהגדרות של Load Balancer מגיעים למספר MaxFailure, בקשות ה-API הבאות מגיבות עם קוד השגיאה 503 Service Unavailable, עם קוד השגיאה NoActiveTargets.

השימוש ב-Health Monitor עוזר ל-Apigee Edge לכלול באופן אוטומטי שרת יעד בחזרה לסבב כשהוא הופך לתקין, ללא צורך בפריסה מחדש של שרת ה-proxy של ה-API.

הנה הסיבות האפשריות לכשלים בבדיקת התקינות:

שלבים נפוצים באבחון

זיהוי ההודעה של הבקשה שנכשלה

הודעות שגיאה נפוצות

כשמשתמשים בשרתי יעד ומופיעה שגיאה בזמן שמעבד ההודעות מנסה להתחבר לשרת הקצה העורפי, יופיעו כמה הודעות שגיאה נפוצות ביומנים של מעבד ההודעות. השגיאות האלה מתועדות אחרי הודעת החריגה או הודעת השגיאה שהובילו לכישלון.

אלה הודעות השגיאה הנפוצות שהוצגו ביומנים של מעבד ההודעות (/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 (שירות לא זמין 503) עם קוד השגיאה NoActiveTargets כתגובה ללקוח.

הסיבה: הזמן הקצוב לחיבור פג

אבחון

1. כך בודקים מה מזהה ההודעה של הבקשה שנכשלה.
2. עליך לחפש את מזהה ההודעה ביומן של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. יוצגו הודעות השגיאה הנפוצות שתואמות למזהה ההודעה. עם זאת, כדי לברר מה הסיבה בפועל לכשלים בבדיקת התקינות, גוללים מעל הודעות השגיאה הנפוצות ומחפשים שגיאות תקינות.

   לדוגמה, הודעת השגיאה הבאה של 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 של שרת יעד שבו נעשה שימוש בשרת ה-proxy הספציפי של ה-API, שעבורו מופיע קוד התגובה 503 עם קוד השגיאה NoActiveTargets.

4. בדוגמה שלמעלה, בדיקת התקינות נכשלה עם השגיאה connection timed out. בודקים אם אפשר להתחבר לשרת הקצה העורפי הספציפי ישירות מכל אחד ממעבדי ההודעות באמצעות הפקודה telnet:

telnet <BackendServer-HostName> 443
      

5. אם אתם מצליחים להתחבר לשרת הקצה העורפי, יכול להיות שתוצג לכם הודעה כמו מחובר לשרת הקצה העורפי. יכול להיות שהבעיה זמנית ונפתרת או שמדובר בבעיה זמנית. חוזרים על שלב 4 כמה פעמים (יותר מ-10 פעמים) ומאמתים את הפלט.
1. אם אין שגיאות בפקודה telnet באופן עקבי, הבעיה נפתרה. בודקים שוב אם הכשלים בבדיקת התקינות הופסקו. אם כן, אין צורך לעשות דבר.
2. אם לא ניתן להתחבר לסירוגין לשרת הקצה העורפי באמצעות הפקודה telnet, יכול להיות שיש בעיה ברשת או ששרת הקצה העורפי עמוס.
6. אם לא הצלחת להתחבר לשרת הקצה העורפי באמצעות הפקודה telnet באופן עקבי, יכול להיות שתעבורת הנתונים הזו לא מותרת על ידי מעבדי ההודעות בשרת הקצה העורפי הספציפי.

רזולוציה

אם השגיאה connection timed out מזוהה באופן עקבי, צריך לוודא שבשרת הקצה העורפי אין הגבלות של חומת אש ושהוא מאפשר תעבורת נתונים ממעבדי ההודעות של Apigee Edge. לדוגמה, ב-Linux אפשר להשתמש ב-iptables כדי לאפשר תעבורת נתונים מכתובות ה-IP של מעבד ההודעות בשרת הקצה העורפי.

אם הבעיה נמשכת, כדאי לפנות למנהל הרשת כדי לבדוק ולפתור את הבעיה. אם אתם צריכים עזרה נוספת מ-Apigee, אפשר לפנות לתמיכה של Apigee.

הסיבה: בקשה מאובטחת ביציאה לא מאובטחת

אבחון

1. כך בודקים מה מזהה ההודעה של הבקשה שנכשלה.
2. עליך לחפש את מזהה ההודעה ביומן של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. יוצגו הודעות השגיאה הנפוצות שתואמות למזהה ההודעה. עם זאת, כדי לברר מה הסיבה בפועל לכשלים בבדיקת התקינות, אפשר לגלול מעל הודעות השגיאה הנפוצות ולבדוק אם יש שגיאות תקינות.

   לדוגמה, ייתכן שתופיע שגיאת 'מעקב בריאות' כפי שמוצג בהמשך:

   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 של שרת יעד שבו נעשה שימוש בשרת ה-proxy הספציפי של ה-API, שעבורו מופיע קוד התגובה 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. צריך לבדוק את ההגדרה של שרת היעד המשמש בהגדרה של נקודת הקצה (endpoint) של היעד.

   משתמשים ב-Get TargetServer API כדי לקבל את ההגדרה של שרת היעד.

   פלט של הגדרת שרת היעד

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

   בדוגמה שלמעלה, ההגדרה מראה ששרת היעד mocktarget הוא שרת מאובטח, כפי שמצוין בבלוק SSLInfo. עם זאת, הוא מוגדר באמצעות יציאה לא מאובטחת 80.

   2. עכשיו צריך לבדוק את ההגדרה של Health Monitor של שרת היעד בהגדרה של נקודת הקצה (endpoint) של היעד:

      הגדרה של 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), אבל עם יציאה לא מאובטחת 80.

   יציאת HM לא מאובטחת עם יעד מאובטח

   תרחיש 2: הוגדר שרת יעד מאובטח, אבל Health Monitor הוגדרה עם יציאה לא מאובטחת

   אם הגדרתם שרת יעד מאובטח אבל ב-Health Monitor הוגדרה יציאה לא מאובטחת כמו 80, הודעת השגיאה הזו תופיע. כדי לבדוק אם זו הסיבה לבעיה:

   1. צריך לבדוק את ההגדרה של שרת היעד המשמש בהגדרה של נקודת הקצה (endpoint) של היעד.

      משתמשים ב- 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 של שרת היעד בהגדרה של נקודת הקצה (endpoint) של היעד:

      הגדרה של 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, אבל ה-Health Monitor מוגדר לבצע בדיקות תקינות באמצעות יציאה לא מאובטחת 80 (המצוינת ברכיב <Port>).

      כלומר, במקרה כזה, Edge הופך את ממשקי ה-API לבדיקת תקינות כקריאה מאובטחת עם יציאה 80 לא מאובטחת, ונכשלת עם השגיאה שצוינה למעלה.

רזולוציה

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

הסיבה: בקשה לא מאובטחת ביציאה מאובטחת

אבחון

1. כך בודקים מה מזהה ההודעה של הבקשה שנכשלה.
2. עליך לחפש את מזהה ההודעה ביומן של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. יוצגו הודעות השגיאה הנפוצות שתואמות למזהה ההודעה. עם זאת, כדי לברר מה הסיבה בפועל לכשלים בבדיקת התקינות, אפשר לגלול מעל הודעות השגיאה הנפוצות ולבדוק אם יש שגיאות תקינות.

   לדוגמה, ייתכן שתופיע שגיאת 'מעקב בריאות' כפי שמוצג בהמשך:

   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 של שרת יעד שבו נעשה שימוש בשרת ה-proxy הספציפי של ה-API, שעבורו מופיע קוד התגובה 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. צריך לבדוק את ההגדרה של שרת היעד המשמש בהגדרה של נקודת הקצה (endpoint) של היעד.

      משתמשים ב- Get TargetServer API כדי לקבל את ההגדרה של שרת היעד.

      פלט של הגדרת שרת היעד

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

      בדוגמה שלמעלה, ההגדרה מראה ששרת היעד mocktarget הוא שרת לא מאובטח, כי אין חסימה של SSLInfo. עם זאת, היא מוגדרת בצורה שגויה באמצעות יציאה מאובטחת 443.

   2. עכשיו צריך לבדוק את ההגדרה של Health Monitor של שרת היעד בהגדרה של נקודת הקצה (endpoint) של היעד:

      הגדרה של 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 הוגדרה עם יציאה מאובטחת

   אם הגדרתם שרת יעד לא מאובטח אבל ב-Health Monitor הוגדרה יציאה מאובטחת כמו 443, תופיע הודעת השגיאה הזו. כדי לבדוק אם זו הסיבה לבעיה:

   1. צריך לבדוק את ההגדרה של שרת היעד המשמש בהגדרה של נקודת הקצה (endpoint) של היעד.

      משתמשים ב- Get TargetServer API כדי לקבל את ההגדרה של שרת היעד.

      פלט של הגדרת שרת היעד

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

      בדוגמה שלמעלה, ההגדרה מראה ששרת היעד mocktarget הוא שרת לא מאובטח (מכיוון שלא קיים בלוק SSLInfo) שמוגדר עם יציאה לא מאובטחת 80 נכון.

   2. בשלב הבא, צריך לבדוק את ההגדרה של Health Monitor של שרת היעד בהגדרה של נקודת הקצה (endpoint) של היעד:

      הגדרה של 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, ונכשל עם השגיאה שצוינה למעלה.

רזולוציה

<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. יוצגו הודעות השגיאה הנפוצות שתואמות למזהה ההודעה. עם זאת, כדי לברר מה הסיבה בפועל לכשלים בבדיקת התקינות, גוללים מעל הודעות השגיאה הנפוצות האלה ובודקים אם יש שגיאות או אזהרות לגבי מצב התקינות.

   לדוגמה, ייתכן שתוצג לכם אזהרה בנושא 'מעקב בריאות', כפי שמוצג בהמשך:

   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 של שרת יעד שבו נעשה שימוש בשרת ה-proxy הספציפי של ה-API, שעבורו מופיע קוד התגובה 503 עם קוד השגיאה NoActiveTargets.

4. בדיקת התקינות החזירה את הודעת האזהרה:

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

   בהודעת האזהרה שלמעלה מצוין שקוד התגובה הצפוי ל-API של בדיקת התקינות היה 200, אבל התגובה שהתקבלה בפועל היא 404. לכן, אנחנו מתייחסים לכך כאל כשל.

5. לפני שבודקים את הסיבה לתגובה שגיאה מה-API לבדיקת תקינות, צריך להבין למה Edge מצפה שקוד התגובה יהיה 200 ל-API של בדיקת התקינות. כדי לעשות את זה, צריך לבדוק את ההגדרה של Health Monitor של שרת היעד בהגדרה של נקודת הקצה (endpoint):

   הגדרה של 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 מה-API לבדיקת תקינות, המערכת תתייחס אליו כשגיאה ותגדיל את מספר הכישלונות.

6. עכשיו, כדי לבדוק מה הסיבה לתגובה לשגיאה מה-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. האפשרות הזו מראה שאפילו הקריאה הישירה לכתובת ה-URL של בדיקת התקינות נכשלה עם אותו קוד תגובה 404. המשמעות היא שיכול להיות שכתובת ה-URL של בדיקת התקינות שגויה או שהמשאב שאליו מתבצעת גישה כחלק מכתובת ה-URL לא זמין יותר.
4. ב-API לדוגמה של בדיקת התקינות שסופקה למעלה, הבעיה מתרחשת כי נעשה שימוש בכתובת URL שגויה בהגדרה של Health Monitor. כתובת ה-URL הנכונה נמצאה היא https://mocktarget.apigee.net:443/statuscode/200 מ-Mock Target API.
7. אם מתקבלת הודעת שגיאה אחרת, צריך לבצע את השלבים שמפורטים למעלה כדי לקבוע מה הסיבה לשגיאה. במקרה הצורך, עובדים עם צוות הקצה העורפי.

רזולוציה

1. פותרים את הבעיה ב-API לבדיקת תקינות בשרת הקצה העורפי.
2. כדי לתקן את הבעיה בדוגמה שלמעלה:
1. משנים את הרכיב <Path> בהגדרות של Health Monitor ל-/statuscode/200, כמו שמוצג בהמשך:

   <Path>/statuscode/200</Path>
           

2. שומרים את השינויים ב-API Proxy.

אם הבעיה נמשכת, עליכם לקרוא את המאמר חובה לאסוף פרטי אבחון.

אבחון בעיות באמצעות מעקב אחר API

בעזרת API Monitoring אפשר לבודד במהירות אזורים בעייתיים כדי לאבחן שגיאות, ביצועים וזמן אחזור ואת המקור שלהן, כמו אפליקציות למפתחים, שרתי proxy של API, יעדים לקצה העורפי או פלטפורמת ה-API.

שלב תרחיש לדוגמה שמדגים איך לפתור בעיות של 5xx בממשקי ה-API באמצעות API Monitoring. לדוגמה, יכול להיות שתרצו להגדיר התראה לקבלת התראה כשמספר השגיאות של messaging.adaptors.http.flow.NoActiveTargets חורג מסף מסוים.

צריך לאסוף פרטי אבחון

אם הבעיה נמשכת גם אחרי שביצעת את ההוראות שלמעלה, עליך לאסוף את פרטי האבחון הבאים. אפשר לפנות אל התמיכה של Apigee ולשתף אותה:

1. אם את/ה משתמש/ת ב-Public Cloud, עליך לספק את הפרטים הבאים:
1. שם הארגון
2. שם הסביבה
3. שם שרת proxy ל-API
4. השלמה של פקודת curl לשחזור השגיאה
5. קובץ מעקב המכיל את הבקשות עם שירות 503 לא זמין עם קוד השגיאה NoActiveTargets
2. אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
   1. זוהתה הודעת השגיאה המלאה
   2. שם הסביבה
   3. חבילת שרת proxy ל-API
   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)