בעיות מוכרות ב-Apigee

אתם צופים במסמכי התיעוד של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

בקטעים הבאים מתוארות הבעיות הידועות ב-Apigee. ברוב המקרים, הבעיות שמפורטות כאן יטופלו במהדורה עתידית.

בעיות ידועות אחרות ב-Edge

בקטעים הבאים מתוארות בעיות שונות שידועות ב-Edge.

אזור/סיכום בעיות מוכרות
פג תוקף של מטמון גורם לערך שגוי של cachehit

כשמשתמשים במשתנה התהליך cachehit אחרי המדיניות של LookupCache, בגלל האופן שבו נשלחים נקודות ניפוי באגים להתנהגות אסינכררונית, המדיניות של LookupPolicy מאכלסת את האובייקט DebugInfo לפני שהקריאה החוזרת (call back) מבוצעת, וכתוצאה מכך מתקבלת שגיאה.

פתרון אפשרי: חוזרים על התהליך (מתקשרים בשיחה שנייה) מיד אחרי השיחה הראשונה.

הגדרת המדיניות InvalidateCache PurgeChildEntries כ-true לא פועלת כמו שצריך

הגדרת PurgeChildEntries במדיניות InvalidateCache אמורה למחוק את ערכי האלמנט KeyFragment בלבד, אבל היא מנקה את כל המטמון.

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

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

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

פתרון עקיף: הימנעו מפריסות בו-זמניות של proxy ל-API או של SharedFlow.

ייתכן שמספרי הקריאות ל-API שמוצגים ב-Edge API Analytics מכילים נתונים כפולים.

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

פתרון עקיף: מייצאים את נתוני Analytics ומשתמשים בשדה gateway_flow_id כדי לבטל את הכפילויות בנתונים.

בעיות ידועות בממשק המשתמש של Edge

בקטעים הבאים מתוארות הבעיות הידועות בממשק המשתמש של Edge.

אזור בעיות ידועות
לא ניתן לגשת לדף 'ניהול אזור SSO של Edge' מסרגל הניווט אחרי שהארגון ממופה לאזור זהות כשמחברים ארגון לאזור זהות, אי אפשר יותר לגשת לדף 'ניהול אזור SSO ב-Edge' מסרגל הניווט הימני על ידי בחירה באפשרות 'אדמין' > 'SSO'. כדי לעקוף את הבעיה, תוכלו לעבור ישירות לדף באמצעות כתובת ה-URL הבאה: https://apigee.com/sso

בעיות מוכרות בפורטל המשולב

בקטעים הבאים מתוארות הבעיות הידועות בפורטל המשולב.

אזור בעיות מוכרות
SmartDocs
  • ב-Apigee Edge יש תמיכה במפרט OpenAPI 3.0 כשיוצרים מפרטים באמצעות עורך המפרטים ומפרסמים ממשקי API באמצעות SmartDocs בפורטל, אבל עדיין אין תמיכה בקבוצת משנה של תכונות.

    לדוגמה, התכונות הבאות במפרט OpenAPI 3.0 עדיין לא נתמכות:

    • מאפייני allOf לשילוב ולהרחבה של סכימות
    • הפניות מרחוק

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

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

  • כשמשתמשים ב'ניסיון ב-API הזה' בפורטל, הכותרת Accept מוגדרת כ-application/json ללא קשר לערך שהוגדר ל-consumes במפרט OpenAPI.
  • 138438484: אין תמיכה במספר שרתים.
ספק זהויות ב-SAML אין תמיכה ביציאה יחידה (SLO) עם ספק הזהויות של SAML בדומיינים מותאמים אישית. כדי להפעיל דומיין מותאם אישית עם ספק זהויות של SAML, משאירים את השדה כתובת URL ליציאה ריק כשמגדירים את ההגדרות של SAML.
אדמין של פורטל
  • בשלב זה אין תמיכה בעדכוני פורטל בו-זמניים (כמו עריכת דפים, עיצובים, קובצי CSS או סקריפטים) על ידי כמה משתמשים.
  • אם תמחקו דף של מסמכי עזרה של API מהפורטל, לא תוכלו ליצור אותו מחדש. תצטרכו למחוק את מוצר ה-API ולהוסיף אותו מחדש, וליצור מחדש את מסמכי העזרה של ה-API.
  • כשמגדירים את מדיניות אבטחת התוכן, יכול להיות שיחלפו עד 15 דקות עד שהשינויים יחולו במלואם.
  • כשמתאימים אישית את העיצוב של הפורטל, יכול להיות שיחלפו עד 5 דקות עד שהשינויים יחולו במלואם.
תכונות הפורטל
  • החיפוש ישולב בפורטל המשולב בגרסה עתידית.

בעיות מוכרות ב-Edge for Private Cloud

בקטעים הבאים מתוארות הבעיות הידועות ב-Edge for Private Cloud.

אזור בעיות מוכרות
‫Edge for Private Cloud 4.53.00 412696630: Failure to load keystores at startup

יכול להיות שהרכיב edge-message-processor ייכשל לסירוגין בטעינה של מאגר מפתחות אחד או יותר בהפעלה, וכתוצאה מכך יתרחשו שגיאות בתנועה כשהמאגר ישמש כשרת proxy של API. הפעלה מחדש של רכיב edge-message-processor בדרך כלל פותרת את הבעיה.
‫Edge for Private Cloud 4.53.00 קריאות ל-Java

יכול להיות שקריאות מותאמות אישית של Java שמנסות לטעון את ספק ההצפנה Bouncy Castle באמצעות השם "BC" ייכשלו, כי ספק ברירת המחדל שונה ל-Bouncy Castle FIPS כדי לתמוך ב-FIPS. השם החדש של הספק שצריך להשתמש בו הוא BCFIPS.
Edge for Private Cloud 4.52.01 Mint update

הבעיה הזו משפיעה רק על משתמשים שמשתמשים ב-MINT או שהפעילו את MINT בהתקנות של Edge for Private Cloud.

הרכיב שהושפע: edge-message-processor

הבעיה: אם הפעלתם מונטיזציה ואתם מתקינים את גרסה 4.52.01 כהתקנה חדשה או משדרגים מגרסאות קודמות של Private Cloud, תיתקלו בבעיה במעבדי ההודעות. מספר השרשורים הפתוחים יגדל בהדרגה עד שייגמרו המשאבים. החריגה הבאה מופיעה ב-system.log של edge-message-processor:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
נקודת חולשה ב-HTTP/2 ב-Apigee

לאחרונה התגלתה נקודת חולשה שמאפשרת מניעת שירות (DoS) בכמה הטמעות של פרוטוקול HTTP/2 ‏ (CVE-2023-44487), כולל ב-Apigee Edge for Private Cloud. נקודת התורפה עלולה להוביל למתקפת DoS על הפונקציונליות של ניהול ה-API של Apigee. פרטים נוספים זמינים במאמר עדכון האבטחה הדחוף ל-Apigee‏ GCP-2023-032.

רכיבי הנתב ושרת הניהול של Edge for Private Cloud חשופים לאינטרנט, ויכול להיות שהם פגיעים. למרות ש-HTTP/2 מופעל ביציאת הניהול של רכיבים אחרים שספציפיים ל-Edge ב-Edge for Private Cloud, אף אחד מהרכיבים האלה לא נחשף לאינטרנט. ברכיבים שאינם Edge, כמו Cassandra, ‏ Zookeeper ואחרים, HTTP/2 לא מופעל. מומלץ לבצע את השלבים הבאים כדי לטפל בפגיעות ב-Edge for Private Cloud:

אם אתם משתמשים ב-Edge Private Cloud בגרסה 4.51.00.11 ואילך, אתם צריכים לבצע את השלבים הבאים:

  1. עדכון שרת הניהול:

    1. בכל צומת של שרת ניהול, פותחים את /opt/apigee/customer/application/management-server.properties
    2. מוסיפים את השורה הבאה לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב שרת הניהול: 
      apigee-service edge-management-server restart

  2. עדכון מעבד ההודעות:

    1. בכל צומת של מעבד ההודעות, פותחים את /opt/apigee/customer/application/message-processor.properties
    2. מוסיפים את השורה הבאה לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-message-processor restart

  3. עדכון הנתב:

    1. בכל צומת של הנתב, פותחים את /opt/apigee/customer/application/router.properties
    2. מוסיפים את השורה הבאה לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-router restart

  4. עדכון QPID:

    1. בכל צומת QPID, פותחים את /opt/apigee/customer/application/qpid-server.properties
    2. מוסיפים את השורה הבאה לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-qpid-server restart

  5. עדכון Postgres:

    1. בכל צומת של Postgres, פותחים את /opt/apigee/customer/application/postgres-server.properties
    2. מוסיפים את השורה הבאה לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-postgres-server restart

אם אתם משתמשים ב-Edge for Private Cloud בגרסאות ישנות יותר מ-4.51.00.11, צריך לבצע את השלבים הבאים:

  1. עדכון שרת הניהול:

    1. בכל צומת של שרת ניהול, פותחים את /opt/apigee/customer/application/management-server.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב שרת הניהול: 
      apigee-service edge-management-server restart

  2. עדכון מעבד ההודעות:

    1. בכל צומת של מעבד ההודעות, פותחים את /opt/apigee/customer/application/message-processor.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-message-processor restart

  3. עדכון הנתב:

    1. בכל צומת של הנתב, פותחים את /opt/apigee/customer/application/router.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-router restart

  4. עדכון QPID:

    1. בכל צומת QPID, פותחים את /opt/apigee/customer/application/qpid-server.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-qpid-server restart

  5. עדכון Postgres:

    1. בכל צומת של Postgres, פותחים את /opt/apigee/customer/application/postgres-server.properties
    2. מוסיפים את שתי השורות הבאות לקובץ המאפיינים: 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. מפעילים מחדש את רכיב עיבוד ההודעות: 
      apigee-service edge-postgres-server restart
שדרוג Postgresql כשמעדכנים לגרסה 4.52

יש בעיות ב-Apigee-postgresql בשדרוג מגרסה 4.50 או 4.51 של Edge for Private Cloud לגרסה 4.52. הבעיות מתרחשות בעיקר כשמספר הטבלאות גדול מ-500.

כדי לבדוק את המספר הכולל של הטבלאות ב-Postgres, מריצים את שאילתת ה-SQL הבאה:

select count(*) from information_schema.tables

פתרון עקיף: כש מעדכנים את Apigee Edge מגרסה 4.50.00 או 4.51.00 לגרסה 4.52.00, חשוב לבצע את השלב המקדים לפני שמשדרגים את Apigee-postgresql.
מדיניות LDAP

‫149245401: ההגדרות של מאגר חיבורי LDAP ל-JNDI שהוגדרו דרך משאב LDAP לא משתקפות, והגדרות ברירת המחדל של JNDI גורמות לחיבורים חד-פעמיים בכל פעם. כתוצאה מכך, חיבורים נפתחים ונסגרים בכל פעם לשימוש חד-פעמי, ונוצר מספר גדול של חיבורים לשעה לשרת ה-LDAP.

פתרון עקיף:

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

  1. יוצרים קובץ מאפייני תצורה אם הוא לא קיים: 
    /opt/apigee/customer/application/message-processor.properties
  2. מוסיפים את השורות הבאות לקובץ (מחליפים את הערכים של מאפייני Java Naming and Directory Interface‏ (JNDI) בהתאם לדרישות התצורה של משאב ה-LDAP). 
    bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
-Dcom.sun.jndi.ldap.connect.pool.prefsize=2
-Dcom.sun.jndi.ldap.connect.pool.initsize=2
-Dcom.sun.jndi.ldap.connect.pool.timeout=120000
-Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"
  3. חשוב לוודא שהקובץ /opt/apigee/customer/application/message-processor.properties נמצא בבעלות apigee:apigee.
  4. מפעילים מחדש כל מעבד הודעות.

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

‫139051927: נמצאו זמני אחזור גבוהים של עיבוד שרתי proxy במעבד ההודעות. הבעיה משפיעה על כל שרתי ה-proxy ל-API. התסמינים כוללים עיכובים של 200-300 אלפיות השנייה בזמני העיבוד מעבר לזמני התגובה הרגילים של ה-API, והם יכולים להתרחש באופן אקראי גם עם TPS נמוך. זה יכול לקרות אם יש יותר מ-50 שרתי יעד שמעבד ההודעות מתחבר אליהם.

הגורם הבסיסי: מעבדי ההודעות שומרים מטמון שממפה כתובת URL של שרת יעד לאובייקט HTTPClient עבור חיבורים יוצאים לשרתי יעד. כברירת מחדל, ההגדרה הזו מוגדרת ל-50, וזה יכול להיות נמוך מדי עבור רוב הפריסות. אם לפריסה יש כמה שילובים של ארגון/סביבה בהגדרה, ויש מספר גדול של שרתי יעד שביחד עולה על 50, כתובות ה-URL של שרתי היעד ממשיכות להימחק מהמטמון, מה שגורם לזמני אחזור.

אימות: כדי לקבוע אם הבעיה של זמן האחזור נגרמת בגלל סילוק של כתובת URL של שרת יעד, מחפשים במערכת Message Processor את מילות המפתח onEvict או Eviction. הנוכחות שלהם ביומנים מציינת שכתובות URL של שרתים יעד מוצאות מהמטמון של HTTPClient כי גודל המטמון קטן מדי.

פתרון עקיף: בגרסאות 19.01 ו-19.06 של Edge for Private Cloud, אפשר לערוך ולהגדיר את מטמון HTTPClient, ‏ /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

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

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

הערה: ב-Edge for Private Cloud בגרסה 50.00, הגדרת ברירת המחדל היא 500.
כמה רשומות למפות של מפתח/ערך

‫157933959: הוספות ועדכונים בו-זמניים לאותו מיפוי של זוגות מפתח/ערך (KVM) בהיקף של הארגון או הסביבה גורמים לנתונים לא עקביים ולעדכונים שאבדו.

הערה: המגבלה הזו רלוונטית רק ל-Edge for Private Cloud. ב-Edge for Public Cloud וב-Hybrid אין את ההגבלה הזו.

כדי לעקוף את הבעיה ב-Edge לענן פרטי, יוצרים את ה-KVM בהיקף apiproxy.