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 Public Cloud וב-Edge Private Cloud
הוסר מארח וירטואלי בגרסה חדשה של proxy ל-API הסרת המארח הווירטואלי מהגרסה החדשה שפריסתה הושלמה, בזמן שהלקוח עדיין משתמש במארח הווירטואלי הספציפי, עלולה לגרום לבעיה הזו. משתמשים ב-Edge Public Cloud וב-Edge Private Cloud
הנתיב לא משויך לאף proxy ל-API ה-proxy ל-API הספציפי לא מוגדר לקבלת בקשות בנתיב שצוין בהודעת השגיאה. משתמשים ב-Edge Public Cloud וב-Edge Private Cloud
לא בוצעה פריסה של proxy ל-API בסביבה ה-proxy ל-API הספציפי לא נפרס בסביבה הספציפית שבה אתם מנסים לשלוח את בקשות ה-API. משתמשים ב-Edge Public Cloud וב-Edge Private Cloud
הסביבה לא נטענה במעבד ההודעות הסביבה הספציפית (שבה אתם מנסים לשלוח את בקשות ה-API) לא נטענה במעבדי ההודעות בגלל שגיאה. משתמשים ב-Edge Private Cloud
proxy ל-API לא נפרס במעבד הודעות אחד או יותר יכול להיות ש-proxy ל-API לא נפרס באחד או יותר ממעבדי הבקשות בגלל חוסר בהתראה לגבי אירוע במהלך ה-Deployment (פריסה). משתמשים ב-Edge Private Cloud

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

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

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

    רושמים את מזהה ההודעה מתוך היומנים.

  3. בודקים את היומנים של Message Processor ‏(/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 לא משויך למארח הווירטואלי הספציפי

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

אבחון

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

    דוגמה להגדרת נקודת קצה (endpoint) של proxy ל-API שמראה ש-proxy ל-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>

    דוגמה להגדרת נקודת קצה של שרת proxy שבה מוצגת הוספה של ברירת המחדל> VirtualHost>‎

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

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

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

אבחון

  1. כדאי לבדוק את ההגדרה של נקודת הקצה של ה-Proxy בשביל ה-proxy ל-API כדי לראות אם ה-proxy ל-API מוגדר לקבל את הבקשות עבור המארח הווירטואלי שצוין בשגיאה. ההגדרה הזו מצוינת באלמנט VirtualHost בהגדרות ProxyEndpoint.
  2. אם המארח הווירטואלי שצוין בשגיאה לא קיים בהגדרה ProxyEndpoint, צריך לבצע את השלבים הבאים. אחרת, עוברים לגורם הבא – הנתיב לא משויך ל-proxy ל-API.
  3. משווים את ההגדרה ProxyEndpoint של הגרסה הקודמת שנפרסה לגרסה הנוכחית שנפרסה.
    1. לדוגמה, נניח שהגרסה הקודמת שהופעלה הייתה 5 והגרסה הנוכחית שהופעלה היא 6:
      • Virtual Hosts configured in Proxy Endpoint in revision 5
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • Virtual Hosts configured in Proxy Endpoint in revision 6
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. בדוגמה שלמעלה, VirtualHost vh1 היה קיים ב-revision 5, אבל הוא הוסר ב-revision 6 והוחלף ב-VirtualHost secure.
    3. לכן, אם אתם או הלקוחות שלכם שולחים בקשות ל-proxy ל-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. אם רוצים להמשיך להשתמש ב-proxy ל-API הקיים אבל להשתמש במארח וירטואלי אחר, עדיף להשאיר את המארח הווירטואלי הקיים ולהוסיף את המארח הווירטואלי הנוסף.

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

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

    כך תוכלו לוודא שהמשתמשים ב-proxy ל-API הזה מודעים לשינוי, ושהם יכולים להשתמש במארח וירטואלי אחר כדי לבצע את הקריאות ל-proxy ל-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

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

אבחון

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

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

  1. אם path שמופיע בהודעת השגיאה לא זהה ל-basepath של ה-proxy ל-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 של ה-proxy ל-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 מתחיל ב-basepath /weather. בנוסף, יש לו 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, צריך להוסיף זרימה נפרדת עם קבוצת כללי המדיניות הנדרשת ולוודא שיש תנאי שמתאים ל-/proxy.pathsuffix /Delhi, כמו שמוצג בהמשך: 
      <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. קובעים את הסביבה שבה קיים כינוי המארח שמשמש בכתובת ה-URL של בקשת ה-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. אם אחת מהשגיאות הבאות מופיעה ביומן של Message Processor, הבעיה היא באישור או במפתחות שנוספו למאגר המפתחות או למאגר האישורים שצוינו בסביבה שצוינה.

    שגיאה מספר 1: java.security.KeyStoreException: Cannot overwrite own certificate

    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.KeyStoreException: אי אפשר להחליף מפתח סודי

    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. כדי לקבל את הפרטים של מאגר המפתחות או מאגר האישורים שצוינו בהודעת השגיאה שמופיעה בשלב הקודם, משתמשים בקריאה הבאה ל-Management 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. בדוגמה של הפלט אפשר לראות שיש שני אישורים ומפתח במאגר האישורים myTruststore. בדרך כלל, מאגר האישורים לא מכיל מפתח. אם כן, עדיף להשתמש באישור אחד ובמפתח אחד.
  4. אפשר לקבל את הפרטים של שני האישורים באמצעות ה-API הבא: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. בודקים את תאריך התפוגה של כל אחד מהאישורים ומזהים את האישור שתוקפו פג או שהוא ישן יותר.
  6. מוחקים את האישור שפג תוקפו או שאתם לא רוצים אותו ממאגר האישורים myTruststore.

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

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

יכול להיות ש-proxy ל-API לא נפרס במעבד בקשות אחד או יותר. הבעיה הזו מתרחשת לעיתים רחוקות מאוד, והיא נובעת בעיקר מהתראה לגבי אירוע חסרה משרת הניהול למעבד בקשות במהלך הפריסה של proxy ל-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 נפרסה בכל מעבדי הבקשות, אז זו לא הסיבה לבעיה הזו. עוברים אל Must gather diagnostic information (חובה לאסוף נתוני אבחון).

רזולוציה

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

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

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

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

כדי לפתור את הבעיה הזו, אפשר לעבור לדף API Monitoring > Investigate, לבחור את התאריך המתאים, את השרת הפרוקסי וכו', ולראות את הפרטים הבאים:

קוד תקלה וקוד סטטוס בממשק המשתמש

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

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

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

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

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

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

  1. אם אתם משתמשים ב-Public Cloud, עליכם לספק את הפרטים הבאים:
    • שם הארגון
    • שם הסביבה
    • שם ה-proxy ל-API
    • השלמת פקודת curl לשחזור השגיאה
  2. אם אתם משתמשים ב-Private Cloud, עליכם לספק את הפרטים הבאים:
    • הודעת השגיאה המלאה שזוהתה
    • שם הסביבה
    • חבילת 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. פרטים על החלקים בחוברת ההדרכה הזו שניסית להשתמש בהם וכל תובנה אחרת שתעזור לנו לפתור את הבעיה במהירות.