404 לא ניתן לזהות שרת proxy למארח: <שם מארח וירטואלי> וכתובת URL: <path>

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

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס HTTP של 404 עם ההודעה Not Found והודעת השגיאה Unable to identify proxy for host: VIRTUAL_HOST and url: PATH כתגובה לקריאות ל-API.

המשמעות של השגיאה הזו היא ש-Edge לא מצא את שרת ה-proxy של ה-API למארח הווירטואלי ולנתיב שצוינו.

הודעת שגיאה

יתקבל קוד הסטטוס הבא של HTTP: 

HTTP/1.1 404 Not Found

תופיע גם הודעת שגיאה שדומה לזו: 

{
   "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

הודעת השגיאה שלמעלה מציינת ש-Edge לא מצא את שרת ה-proxy של ה-API עבור המארח הווירטואלי של default והנתיב /oauth2/token.

סיבות אפשריות

חלק מהסיבות האפשריות לשגיאה הזו מפורטות בהמשך:

סיבה התיאור ההוראות לפתרון בעיות הרלוונטיות עבור
שרת proxy של API לא משויך למארח הווירטואלי הספציפי שרת ה-API הספציפי לא מוגדר לקבל בקשות במארח הווירטואלי שצוין בהודעת השגיאה. משתמשי Edge הציבוריים והפרטיים
הוסר מארח וירטואלי בגרסה חדשה של שרת proxy ל-API שנפרסה הסרת המארח הווירטואלי מהגרסה החדשה שנפרסה בזמן שהלקוח עדיין משתמש במארח הווירטואלי הספציפי יכולה לגרום לבעיה הזו. משתמשי Edge הציבוריים והפרטיים
הנתיב לא משויך לאף שרת proxy של API שרת ה-API הספציפי לא מוגדר לקבל בקשות בנתיב שצוין בהודעת השגיאה. משתמשי Edge הציבוריים והפרטיים
שרת proxy ל-API לא נפרס בסביבה שרת ה-proxy הספציפי של ה-API לא נפרס בסביבה הספציפית שבה מנסים לשלוח את בקשות ה-API. משתמשי Edge הציבוריים והפרטיים
לא נטענה סביבה במעבד ההודעות הסביבה הספציפית (שבה ניסית לשלוח את בקשות ה-API) לא נטענה במעבדי ההודעות בגלל שגיאה. משתמשי ענן פרטי של Edge
שרת proxy של API לא נפרס במעבד הודעות אחד או יותר לא ניתן לפרוס שרת proxy של API על מעבד הודעות אחד או יותר כי חסרה התראה על אירוע במהלך הפריסה. משתמשי ענן פרטי של Edge

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

היומנים של NGINX ומעבד ההודעות יעזרו לפתור את השגיאה 404. כדי לבדוק את היומנים:

  1. מציגים את יומני NGINX באמצעות הפקודה הבאה: 
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. בודקים אם השדות הבאים מופיעים ברשומות ביומן:
    שדה Value
    Upstream_status, status 404
    X-Apigee-fault-code messaging.adaptors.http.flow.ApplicationNotFound

    מומלץ לרשום לפניכם את מזהה ההודעה ביומנים.

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

    הודעת שגיאה לדוגמה מהיומן של מעבד ההודעות

    4. NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

    היומן שלמעלה מציג את קוד השגיאה והודעת השגיאה הבאה:

    code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

הסיבה: שרת proxy של API לא משויך למארח הווירטואלי הספציפי

אם שרת ה-API של שרת ה-API לא מוגדר לקבל את הבקשות עבור המארח הווירטואלי הספציפי, אז נוכל לקבל תגובה 404 Not Found עם הודעת השגיאה Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

אבחון

  1. צריך לבדוק את ההגדרה של Proxy Endpoint (נקודת קצה לשרת proxy) של ה-API ולראות אם שרת ה-proxy של ה-API מוגדר לקבל את הבקשות למארח הווירטואלי שצוין בשגיאה. דבר זה מצוין על ידי הרכיב VirtualHost. כדי להבין זאת, נתבונן בהגדרה לדוגמה של ProxyEndpoint.

    דוגמה להגדרה של נקודת קצה (endpoint) של שרת Proxy, שמראה ששרת ה-API של שרת ה-API מקבל בקשות במארח וירטואלי מאובטח

  2. נניח שהמארחים הווירטואליים מוגדרים בסביבה הספציפית באופן הבא:
    שם נמל כינוי המארח
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. שולחים בקשת API ל-default VirtualHost באמצעות כתובת ה-URL http://myorg-prod.apigee.net/weather
  4. מאחר שב-ProxyEndpoint אין את הפרמטר default VirtualHost כפי שמוצג בדוגמה שלמעלה, קוד התגובה 404 מופיע עם הודעת השגיאה הבאה: 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. כדי לטפל בבעיה, עוברים לקטע פתרון.
  6. אם השדה ProxyEndpoint מוגדר לקבל את הבקשות ב-default VirtualHost, עוברים לגורם הבא – הנתיב לא משויך לאף שרת proxy של API.

רזולוציה

  1. כדי לטפל בבעיה, צריך להוסיף את השדה החסר VirtualHost להגדרות האישיות של ProxyEndpoint. בדוגמה שלמעלה אפשר להוסיף את ברירת המחדל VirtualHost להגדרות של ProxyEndpoint באופן הבא: 
    <VirtualHost>default</VirtualHost>

    דוגמה להגדרה של נקודת קצה (endpoint) של שרת Proxy שמוצג בה ברירת המחדל > הוספה של VirtualHost

  2. לחלופין, בדוגמה שלמעלה, אם התכוונת להשתמש רק ב-secure VirtualHost עבור שרת ה-API הספציפי הזה, אזי לשלוח את בקשות ה-API רק ל-secure VirtualHost באמצעות פרוטוקול HTTPS: 
    https://myorg-prod.apigee.net/weather

הסיבה: מארח וירטואלי הוסר בגרסה חדשה של שרת proxy ל-API שנפרסה

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

אבחון

  1. צריך לבדוק את ההגדרה של Proxy Endpoint של שרת ה-API של שרת ה-proxy כדי לראות אם שרת ה-proxy של ה-API מוגדר לקבל את הבקשות למארח הווירטואלי שצוין בשגיאה. המאפיין הזה מצוין על ידי הרכיב VirtualHost בהגדרות האישיות של ProxyEndpoint.
  2. אם המארח הווירטואלי שצוין בשגיאה לא קיים בהגדרה של ProxyEndpoint, מבצעים את השלבים הבאים. אחרת, עוברים לגורם הבא – הנתיב לא משויך לאף שרת proxy של API.
  3. השוואה בין ההגדרה ProxyEndpoint של הגרסה הקודמת שנפרסה לבין הגרסה הקודמת שנפרסה.
    1. לדוגמה, נניח שהגרסה הקודמת שנפרסה הייתה 5 והגרסה הקודמת שנפרסה היא 6:
      • מארחים וירטואליים שהוגדרו בנקודת הקצה של שרת proxy בגרסה 5
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • מארחים וירטואליים שהוגדרו בנקודת קצה של שרת proxy בגרסה 6
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. בדוגמה שלמעלה, הנכס VirtualHost vh1 היה קיים ב-revision 5,, אבל הוא הוסר ב-revision 6 והוחלף ב-VirtualHost secure.
    3. לכן, אם את/ה או הלקוחות שלך שולחים את הבקשות לשרת ה-API הזה באמצעות VirtualHost vh1 (שהיה חלק מ-revision 5), תקבלו את קוד התגובה 404 עם הודעת השגיאה הבאה: 
      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  4. צריך לבדוק אם השינוי במארח הווירטואלי בוצע במתכוון או בטעות בגרסה שנפרסה כרגע, ולנקוט את הצעדים המתאימים כפי שמוסבר בקטע פתרון.

רזולוציה

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

תרחיש מס' 1: שינוי מכוון

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

  1. צריך ליצור שרת proxy חדש עם נתיב בסיס אחר ולהשתמש במארח וירטואלי אחר (שלא קיים בגרסה הקודמת שנפרסה).

  2. אם ברצונך להמשיך להשתמש בשרת ה-API הקיים אבל להשתמש במארח וירטואלי אחר, עדיף לשמור על המארח הווירטואלי הקיים ולהוסיף את המארח הווירטואלי הנוסף.

    פעולה זו תוודא שהמשתמשים של שרת proxy זה ב-API לא יושפעו מהשינוי.

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

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

תרחיש מס' 2: שינוי לא מכוון

אם הסרת המארח הווירטואלי בוצעה בטעות ולא באופן מכוון,יש לבצע את הפעולות הבאות:

  1. צריך לעדכן את ההגדרה ProxyEndpoint בגרסה הקודמת שנפרסה, כדי להשתמש באותם מארחים וירטואליים שהיו בשימוש בגרסה הקודמת שנפרסה. בדוגמה שלמעלה, משנים את הקטע הבא מ: 
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

    עד

    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
  2. פורסים מחדש את הגרסה הקודמת.

שיטות מומלצות

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

הסיבה: הנתיב לא משויך לאף שרת proxy של API

אם שרת ה-API של ה-API לא מוגדר לקבל את הבקשות לנתיב הספציפי שכלול בכתובת ה-URL של בקשת ה-API, אנחנו יכולים לקבל תגובה 404 Not Found עם הודעת השגיאה Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

אבחון

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

תרחיש מס' 1: הנתיב לא תואם לנתיב הבסיס של שרת ה-proxy של ה-API

  1. אם ה-path שצוין בהודעת השגיאה לא זהה ל-basepath של שרת ה-API הספציפי או שהוא לא מתחיל ב-basepath, ייתכן שזו הסיבה לשגיאה.
  2. לדוגמה:
    1. הערך basepath של שרת ה-proxy המיועד ל-API הוא /weather
    2. כתובת ה-URL של בקשת ה-API היא https://myorg-prod.apigee.net/climate. כלומר הנתיב שמופיע בכתובת ה-URL של בקשת ה-API הוא /climate.
  3. בדוגמה הזו, ה-path לא זהה ל-basepath והוא לא מתחיל ב-basepath. כתוצאה מכך מתקבלת השגיאה הבאה: 
    {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

רזולוציה

  1. יש לוודא שהערך path שמשמש בכתובת ה-URL של בקשת ה-API זהה ל-basepath של שרת ה-API הספציפי.
  2. בדוגמה שלמעלה, כתובת ה-URL של בקשת ה-API צריכה להיות: 
    {
https://myorg-prod.apigee.net/weather

תרחיש מס' 2: הנתיב לא תואם לאף אחד מהזרימות המותנות הזמינות

  1. אם הערך path שמשמש בכתובת ה-URL של בקשת ה-API מתחיל ב-basepath, יכול להיות שה-path suffix (הקטע שמופיע אחרי basepath) שצוין בהודעת השגיאה לא תואם לאף אחד מהזרימות המותנות, זה עלול לגרום לשגיאה 404.
  2. נבחן דוגמה כדי להסביר את זה:
    1. הערך basepath של שרת ה-proxy המיועד ל-API הוא /weather
    2. כתובת ה-URL של בקשת ה-API היא https://myorg-prod.apigee.net/weather/Delhi. כלומר הנתיב שמופיע בכתובת ה-URL של בקשת ה-API הוא /weather/Delhi.
  3. בדוגמה הזו, path מתחיל ב-/weather basepath. בנוסף, השדה path suffix הוא /Delhi.
  4. עכשיו צריך לבדוק אם יש זרימות מותנות ב-ProxyEndpoint.
  5. אם אין זרימות מותנות או שיש כמה זרימות לא מותנות, עוברים לגורם הבא – שרת proxy ל-API לא פרוס בסביבה.
  6. אם ב-ProxyEndpoint יש רק זרימות מותנות, צריך לבדוק את הדברים הבאים:
    1. אם התנאים בכל הזרימה המותנית האלה מחפשים proxy.pathsuffix ספציפי (הנתיב שאחרי נתיב הבסיס).
    2. אם הערך path suffix שצוין בכתובת ה-URL של בקשת ה-API לא תואם לאף אחד מהתנאים, זו הסיבה לשגיאה.
  7. נניח שיש לנו שני זרימות ב-ProxyEndpoint ושתיהן זרימות מותנות כפי שמוצג כאן: 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    1. בדוגמה שלמעלה יש לנו שני תהליכי עבודה מותנים, אחד שמתאים ל-proxy.pathsuffix (נתיב אחרי נתיב הבסיס) ל-/Bangalore והשני תואם ל-/Chennai. אבל אין מזהה שתואם ל-/Delhi, שהוא path suffix שהועבר בכתובת ה-URL של בקשת ה-API.
    2. זו הסיבה לשגיאה 404. לכן תתקבל השגיאה הבאה: 
      {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

רזולוציה

  1. יש לוודא שה-path suffix תואם לפחות לאחד מהתהליכים המותנים בנקודת הקצה של שרת ה-proxy.
  2. בדוגמה שלמעלה, תוכלו להשתמש בגישות הבאות כדי לפתור את השגיאה:
    1. כדי להפעיל קבוצה ספציפית של כללי מדיניות בנתיב /Delhi, צריך להוסיף תהליך נפרד עם קבוצת כללי המדיניות הנדרשת ולוודא שיש תנאי שתואם ל-/Delhi של /proxy.pathsuffix, כמו שמוצג כאן: 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. אם רוצים להפעיל קבוצה משותפת של כללי מדיניות בנתיב /Delhi, צריך לוודא שבתהליך המשותף קיים תנאי שמאפשר /proxy.pathsuffix כללי. כלומר, הוא יאפשר כל נתיב אחרי basepath /weather כפי שמוצג בהמשך: 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

אם ב-ProxyEndpoint יש ערך תקין במאפיין basepath וה-path suffix שצוין בכתובת ה-URL של ה-API תואם לאחד מהתהליכים המותנים, עוברים לגורם הבא – שרת ה-proxy של ה-API לא פרוס בסביבה.

הסיבה: שרת proxy של API לא נפרס בסביבה

אבחון

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

    לדוגמה, נניח שהתצורה הבאה:

    • אם http://myorg-prod.apigee.net/weather היא כתובת ה-URL שלך, אז myorg-prod.apigee.net הוא כינוי המארח.
    • כינוי המארח myorg-prod.apigee.net מוגדר כחלק מאחד מהמארחים הווירטואליים בסביבת prod של הארגון שלך.
  2. צריך לבדוק אם שרת ה-Proxy הספציפי של ה-API נפרס בסביבה הספציפית שנקבעה בשלב 1 למעלה.
  3. אם שרת ה-proxy של ה-API לא נפרס בסביבה הספציפית, זו הסיבה לשגיאה 404.
    1. לכן, בדוגמה ששימשה בשלב 1 שלמעלה, נניח ששרת ה-proxy של ה-API לא נפרס בסביבה prod, וזו הסיבה לשגיאה.
    2. עוברים לקטע פתרון בהמשך.
  4. אם שרת ה-proxy של ה-API נפרס בסביבה הספציפית, עוברים לגורם הבא – הסביבה לא נטענה במעבדי הודעות.

רזולוציה

פורסים את שרת ה-proxy של ה-API בסביבה הספציפית שבה רוצים לשלוח בקשות API.

הסיבה: לא נטענה סביבה במעבדי ההודעות

אבחון

  1. צריך להתחבר לכל אחד ממעבדי ההודעות ולבדוק אם הסביבה הספציפית שבה שלחת את בקשת ה-API נטענת במעבד ההודעות באמצעות הפקודה הבאה: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. אם הסביבה הספציפית מופיעה כחלק מהפקודה שלמעלה, עוברים לסיבה הבאה: שרת proxy של API לא נפרס באחד או יותר מהמעבדים של ההודעות.
  3. אם הסביבה הספציפית לא מופיעה ברשימה, כדאי לבדוק את /opt/apigee/var/log/edge-message-processor/logs/system.log ואת /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log במעבדי ההודעות כדי לראות אם יש שגיאות במהלך טעינת הסביבות.
  4. יכולות להיות שגיאות רבות ושונות שעלולות לגרום לכשל בטעינת סביבה במעבד ההודעות. הפתרון תלוי בשגיאה שאירעה.

רזולוציה

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

  1. אם מופיעה אחת מהשגיאות הבאות ביומן של מעבד ההודעות, היא נובעת מבעיה שנמצאה באישורים או במפתחות שנוספו ל-Keystore/truststore שצוינו בסביבה שצוינה.

    שגיאה מס' 1: java.security.KeyStoreחריג: לא ניתן להחליף את האישור של עצמו

    2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
…
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

    ... 20 common frames omitted

    2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

    שגיאה מס' 2: java.security.KeyStoreחריג: לא ניתן להחליף את המפתח הסודי

    2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
...
Caused by: java.security.KeyStoreException: Cannot overwrite secret key
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
  2. כדי לקבל את הפרטים של מאגר המפתחות או ה-truststore שצוינו בהודעת השגיאה שהוצגה בשלב הקודם, משתמשים בקריאה הבאה ל-API לניהול: 
    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

    פלט לדוגמה:

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. לפי הפלט לדוגמה, יש שני אישורים ומפתח ב-Truststore myTruststore. ה-Truststore בדרך כלל לא מכיל מפתח. אם כן, עדיף שיהיה לך אישור אחד ומפתח אחד.
  4. אפשר לקבל פרטים על שני האישורים באמצעות ה-API הבא: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. בודקים את תאריך התפוגה של כל אישור כדי לקבוע איזה אישור פג/ישן.
  6. יש למחוק את האישור שתוקפו פג או שאינו רצוי מ-Truststore myTruststore.

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

הסיבה: שרת proxy של API לא נפרס במעבד הודעות אחד או יותר

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

אבחון

  1. צריך להתחבר לכל אחד ממעבדי ההודעות ולבדוק אם הגרסה הספציפית של שרת ה-proxy של ה-API נפרסה או לא באמצעות הפקודה הבאה: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. אם הגרסה הספציפית של שרת ה-proxy של ה-API לא מופיעה כפלט של הפקודה שהוזכרה בשלב 1 למעלה, יש להפעיל מחדש את מעבד ההודעות הספציפי כפי שמוסבר בפתרון.
  3. חוזרים על שלבים 1-2 עבור כל מעבדי ההודעות.
  4. אם הגרסה הספציפית של שרת ה-proxy של ה-API נפרסת בכל מעבדי ההודעות, היא לא הסיבה לבעיה. צריך לאסוף פרטי אבחון.

רזולוציה

מפעילים מחדש את מעבדי ההודעות הספציפיים שבהם לא נפרס הגרסה הספציפית של שרת ה-proxy של ה-API.

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

אבחון בעיות באמצעות API Monitoring

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

לגבי הבעיה הזו, תוכלו לעבור לדף API Monitoring > Inveg (מעקב API > חקירה) ולבחור את התאריך המתאים, שרת ה-Proxy וכן הלאה, וייתכן שיוצגו הפרטים הבאים:

קוד שגיאה וקוד סטטוס בממשק המשתמש

  • קוד שגיאה: messaging.adaptors.http.flow.ApplicationNotFound
  • קוד סטטוס: 404
  • מקור התקלה: Apigee או MP

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

צפייה ביומנים

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

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

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

  1. אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:
    • שם הארגון
    • שם הסביבה
    • שם שרת proxy ל-API
    • השלמה של פקודת curl לשחזור השגיאה
  2. אם אתם משתמשים בענן פרטי, עליכם לספק את הפרטים הבאים:
    • נצפתה הודעת שגיאה מלאה
    • שם הסביבה
    • חבילת proxy ל-API
    • יומני מעבד ההודעות /opt/apigee/var/log/edge-message-processor/logs/system.log
    • פלט של הפקודות הבאות על כל אחד ממעבדי ההודעות. 
      • curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
      curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  3. פרטים על הסעיפים שניסית במדריך הזה ותובנות נוספות שיעזרו לנו לפעול במהירות לפתרון הבעיה.