לא ניתן ליצור פעילות מעקב

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

תיאור הבעיה

המשתמש לא יכול ליצור סשן מעקב בממשק המשתמש של Edge.

הודעת שגיאה

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

Error creating trace session for API proxy <api proxy name>, revision <revision number>, environment <environment name>.
Failed to create DebugSession <session number>

לפניכם צילום מסך של הודעת שגיאה לדוגמה שנצפתה בממשק המשתמש של Edge:

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

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

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

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

  1. מפעילים את ממשק ה-API הזה לניהול:

    curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

  2. אם מוצגות שגיאות, רושמים אותן לעצמכם. עוברים אל בעיית קישוריות לרשת.

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

הסיבה: בעיה בקישוריות הרשת

אבחון

  1. צריך לבדוק את היומן של שרת הניהול /opt/apigee/var/log/edge-management-server/logs/system.log ולראות אם יש שגיאות במהלך יצירת הפעילות של מעקב או ניפוי הבאגים.

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

    2018-02-08 09:08:21,310 org:myorg env:uat  qtp1073741635-1074 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID cedeabd2-e4d1-40bb-8f18-d6afc8835e5b
org.apache.http.conn.HttpHostConnectException: Connect to 10.84.75.92:8082 [/10.84.75.92] failed: Connection refused
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5]
...<snipped>
Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_65]
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_65]
...<snipped>

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

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

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

  5. בודקים את הקישוריות משרת הניהול למעבד ההודעות ביציאה 8082, באופן הבא:

    1. אם telnet זמין, השתמשו ב-telnet:

      telnet <MessageProcessor_IP> 8082

    2. אם telnet אינו זמין, השתמש ב-netcat כדי לבדוק את הקישוריות באופן הבא:

      nc -vz <MessageProcessor_IP> 8082

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

  6. מתחברים לכל אחד ממעבדי ההודעות עם כתובת ה-IP המתאימה שהציגה את השגיאה ומבצעים את השלבים הבאים:

    1. בדוק אם מעבד ההודעות מאזין ביציאה 8082:

      netstat -an | grep LISTEN | grep 8082

    2. אם מעבד ההודעות מאזין ביציאה 8082, עוברים לשלב 7.

    3. אם מעבד ההודעות לא מאזין ביציאה 8082, יש להפעיל מחדש את מעבד ההודעות באמצעות הפקודה הבאה:

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

    4. צריך להמתין עד שמעבד ההודעות יתחיל לפעול בצורה מלאה באמצעות פקודה זו:

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

    5. לאחר הפעלת מעבד ההודעות, יש לבדוק שוב אם מעבד ההודעות מאזין ביציאה 8082.

    6. אם מעבד ההודעות מאזין ביציאה 8082, עוברים לשלב 7.

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

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

  9. משתמשים בפקודה המתאימה כדי לבדוק את הכללים של חומת האש. לדוגמה, תוכלו להריץ את הפקודה iptables כדי להציג רשימה של כל כללי חומת האש שמוגדרים במערכת שלכם:

    iptables -L -n

  10. אם לא הוגדרו כללים של חומת אש ביציאה 8082, צריך לעבור אל בעיה בשימוש במשאבים גבוהים.

  11. אם הוגדרו כללים של חומת אש ביציאה 8082, יש לעבור לקטע 'פתרון' שבהמשך.

פתרון

  1. עליך לעבוד עם מנהל הרשת כדי לאפשר תעבורת נתונים נכנסת/יוצאת ביציאה 8082 משרתים חיצוניים.

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

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

אבחון

  1. צריך לבדוק את היומנים של שרת הניהול /opt/apigee/var/log/edge-management-server/logs/system.log ולראות אם יש שגיאות במהלך יצירת הסשן של מעקב/ניפוי הבאגים.

  2. במהלך היצירה של פעילות מעקב/ניפוי באגים, עשויה להופיע הודעת שגיאה כמו "אין תגובות חוקיות מ-MP(s)", כפי שמוצג כאן:

    2018-01-30 08:28:09,721 org:mynonprod env:uat  qtp2007599722-712162 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : no valid responses from MP(s), throwing error
2018-01-30 08:28:09,723 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - CustomJAXRSInvoker.performInvocation() : CustomJAXRSInvoker.performInvocation : Method com.apigee.distribution.DebugSessionAPI.createDebugSession threw an exception.
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Error occurred : Failed to create DebugSession 1517297564678
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Returning error response : ErrorResponse{errorCode = distribution.CreateDebugSessionFailed, errorMessage = Failed to create DebugSession 1517297564678}

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

  3. אם אתם לא רואים שגיאה דומה לשגיאה שמוצגת בדוגמה שלמעלה, עליכם להעביר אל ערכים לא פעילים של מעבד הודעות.

  4. אם מבחינים בשגיאה הדומה לזו שמוצגת בדוגמה שלמעלה, יש לבצע את השלבים הבאים.

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

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

    curl -s http://localhost:8082/v1/runtime/organizations/<org-name>/environments

    פלט לדוגמה:

    בפלט של הפקודה שלמעלה תופיע רשימה של הסביבות ששייכות לארגון הספציפי שנטענות על מעבד ההודעות. לדוגמה, אם סביבות preprod ו-test נטענות על מעבד ההודעות, הפלט יופיע באופן הבא:

    [ "preprod", "test" ]

  7. אם הסביבה הספציפית, למשל "dev", שבה אתם מנסים ליצור סשן מעקב, רשומה כחלק מהפקודה שלמעלה, צריך לעבור אל ערכים לא פעילים של מעבד הודעות.

  8. אם הסביבה הספציפית, למשל "dev", לא רשומה כחלק מהפקודה שלמעלה, כדאי לבדוק אם יש שגיאות ב-/opt/apigee/var/log/edge-message-processor/logs/system.log וב-/opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log שבמעבדי ההודעות במהלך טעינת סביבות.

  9. יכולות להיות שגיאות רבות ושונות שעלולות לגרום לכשל בטעינת סביבה במעבד ההודעות. הפתרון תלוי בשגיאה שאירעה.

רזולוציה

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

  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. כדי לקבל את הפרטים של ה-keystore/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 שלמעלה, עליכם לעבור אל חובה לאסוף פרטי אבחון.

הסיבה: אין גישה לרשומות ישנות במעבד ההודעות או למעבדי הודעות

אבחון

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

  3. במהלך יצירת סשן של מעקב או ניפוי באגים, עשויה להופיע הודעת שגיאה כמו 'השרת <UUID> לא פועל או לא נגיש':

    2017-12-27 07:42:38,975 org:cocacola env:prod qtp2007599722-222063 INFO DISTRIBUTION - DebugSessionAPI.createDebugSession() : server 458b5910-2646-441c-a6e2-428b6d84e021 is either not up or reachable, skipping the server

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

    2017-12-27 07:44:46.000 UTC org:cocacola env:prod qtp2007599722-222063 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID {}, skipping it458b5910-2646-441c-a6e2-428b6d84e021 org.apache.http.conn.HttpHostConnectException: Connect to 192.168.101.7:8080 [/192.168.101.7] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.5.jar:4.3.5] 
…<snipped>
Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_144] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_144]
…<snipped>

  4. שתי השגיאות האלה עשויות להיגרם עקב מעבדי הודעות ספציפיים:

    1. לא פעיל (כבר לא קיים)
    2. האתר מושבת או לא זמין מסיבה כלשהי

  5. יש לפעול לפי הפתרון המתאים בהתאם לתרחיש שבו אתם נתקלים.

רזולוציה

תרחיש מס' 1 : מעבדי ההודעות לא פעילים (לא קיימים)

  1. אפשר לקבל רשימה של מעבדי הודעות באמצעות ממשק ה-API לניהול שבהמשך:

    curl -u <sysadmin> "http://<management-server-host>:8080/v1/servers?pod=<podName>&regions=<regionName>"

  2. רושמים לעצמכם את כתובת ה-IP או את שם המארח שמתאימים למזהי ה-UUID (המזהים) של מעבדי ההודעות שהוזכרו בהודעת השגיאה ביומנים של שרת הניהול (שלב 3 ב'אבחון' למעלה). יש לבדוק אם הם מעבדי הודעות חוקיים באחת מהדרכים הבאות:

    1. תרשים ההגדרה האחרון של הטופולוגיה של הענן הפרטי
    2. כתובת ה-IP האחרונה של שרת Edge – טבלת מיפוי שם המארח

    אם לדעתך הם נחשבים כמעבדי הודעות חוקיים, עליך לעבור לתרחיש 2 : אין גישה למעבדי הודעות.

  3. מוחקים את מעבדי ההודעות המיושנים (לא קיימים) באמצעות ממשקי ה-API לניהול שבהמשך:

    1. ביטול הרישום של מעבד ההודעות מסביבות הארגון: 

      curl -X POST http://<management-server-host>:8080/v1/o/<orgName>/e/<envName>/servers -d "uuid={uuid}&region=<regionName>&pod=<podName}&action=remove"

    2. ביטול הרישום של סוג השרת: 

      curl http://<management-server-host>:8080/v1/servers -X POST -d "type={message-processor}&region=<regionName>&pod=<podName>&uuid=<uuid>&action=remove"

    3. מוחקים את השרת: 

      curl http://<management-ip>:8080/v1/servers/<uuid> -X DELETE

  4. אם נתקלת באותה בעיה בסביבות אחרות בארגון, יש לחזור על שלב 3.

תרחיש 2: אין גישה למעבדי ההודעות

  1. מתחברים לכל אחד ממעבדי ההודעות על ידי קביעת כתובות ה-IP/שמות המארחים על סמך מזהי ה-UUID שזוהו בהודעת השגיאה ביומנים של שרת הניהול.

  2. מפעילים מחדש את מעבד ההודעות:

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

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

הסיבה: בעיה של ניצול גבוה של משאבים

אבחון

  1. התחברו לכל אחד ממעבדי ההודעות ובודקים אם נעשה שימוש רב במשאבים כלשהם - המעבד(CPU), זיכרון או עומס. ניתן להשתמש בפקודה top במערכות הפעלה מבוססות Unix כדי לקבל את פרטי השימוש במשאבים של תהליך מעבד ההודעות:

    top

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

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

    1. אם מעבד הודעות כלשהו חווה שימוש גבוה במעבד (CPU), יש ליצור שלושה מצבי Dump של שרשור בכל 30 שניות באמצעות הפקודה הבאה:

      sudo <JAVA_HOME>/bin/jstack -l <pid> > <filename>

    2. אם מעבד הודעות כלשהו משתמש בזיכרון גבוה, צור קובץ Dump של ערימה באמצעות הפקודה הבאה:

      sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>

    3. מעבר ל'רזולוציה'.

רזולוציה

  1. מפעילים מחדש את מעבד ההודעות באמצעות הפקודה הבאה. כתוצאה מכך, השימוש במעבד (CPU) ובזיכרון עשוי לרדת:

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

  2. צריך לעקוב אחר הקריאות ל-API ולוודא אם הבעיה עדיין קיימת.

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

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

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

אבחון

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

    curl -v localhost:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions

    פלט לדוגמה:

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

    [ "12" ]

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

  3. חוזרים על השלבים 1-2 עבור כל מעבדי ההודעות.

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

רזולוציה

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

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

הסיבה: בעיה בממשק המשתמש של Edge

אבחון

  1. כדאי לבדוק את היומנים של ממשק המשתמש של Edge /opt/apigee/var/log/edge-ui/application.log ואת /opt/apigee/var/log/edge-ui/edge-ui.log ולראות אם יש שגיאות.
  2. צריך לפנות לתמיכה של Apigee Edge ולשתף את הקבצים האלה להמשך בדיקה.

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

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

  1. הפלט של הפקודה:

    curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

  2. יומן של שרת הניהול 

    /opt/apigee/var/log/edge-management-server/logs/system.log.

  3. יומנים של מעבד ההודעות

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

  4. פלט של פקודות telnet/nc משרת ניהול אל מעבד הודעות:

    telnet <MessageProcessor_IP> 8082
nc -vz <MessageProcessor_IP> 8082

  5. הפלט של פקודת netstat הבאה על מעבדי ההודעות:

    netstat -an > netstat.txt

  6. אם זוהתה בעיה בממשק המשתמש של Edge, צריך לשלוח את היומנים של ממשק המשתמש של Edge /opt/apigee/var/log/edge-ui/application.log ואת /opt/apigee/var/log/edge-ui/edge-ui.log..

  7. פרטים על הקטעים ב-Playbook שכבר נוסו וכל תובנות אחרות שיעזרו לנו לפתור את הבעיה במהירות.