בעיות ידועות ב-Apigee Edge

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

בקטעים הבאים מתוארות הבעיות הידועות ב-Apigee Edge. ברוב המקרים, הבעיות שצוינו יתוקנו בגרסה עתידית.

בעיות ידועות של Edge

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

אזור בעיות ידועות
תוקף המטמון גורם לערך cachehit שגוי

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

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

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

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

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

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

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

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

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

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

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

    לדוגמה, התכונות הבאות מ-OpenAPI Specification 3.0 עדיין לא נתמכות:

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

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

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

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

בעיות מוכרות ב-Edge לענן פרטי

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

אזור בעיות ידועות
נקודת חולשה ב-Apigee HTTP/2

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

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

אם משתמשים ב-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. עדכון הודעות אימייל:

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

אם משתמשים ב-Edge בגרסאות של ענן פרטי לפני 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. עדכון הודעות אימייל:

    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 יש בעיות בשדרוג מ-Edge for Private Cloud מגרסה 4.50 או 4.51 לגרסה 4.52. הבעיות קורות בעיקר כשמספר הטבלאות גדול מ-500.

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

select count(*) from information_schema.tables

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

apigee-mirror לא פועל ב-Red Hat Enterprise Linux (RHEL) 8.0.

פתרון אפשרי: כפתרון עקיף, אפשר להתקין את apigee-mirror בשרת שבו פועלת גרסה נמוכה יותר של RHEL או מערכת הפעלה נתמכת אחרת עבור Apigee. לאחר מכן ניתן להשתמש במראה כדי להוסיף חבילות, גם אם התקנת את Apigee בשרתי RHEL 8.0.

מדיניות LDAP

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

פתרון אפשרי:

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

  1. יוצרים קובץ מאפיינים של הגדרות אישיות אם הוא עדיין לא קיים: 
    /opt/apigee/customer/application/message-processor.properties
  2. מוסיפים את הפריטים הבאים לקובץ (מחליפים את הערכים של המאפיינים Java Naming ו-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. הערך הזה עשוי להיות נמוך מדי לרוב הפריסות. אם בפריסה יש כמה שילובים של org ו-env בהגדרה מסוימת, ועם מספר גדול של שרתי יעד שחורג מ-50 בסך הכול, כתובות ה-URL של שרתי היעד מוסרות מהמטמון וגורמות לזמני אחזור.

תיקוף: כדי לקבוע אם ההסרה של כתובת ה-URL של שרת היעד גורמת לבעיית זמן האחזור, צריך לחפש את מילת המפתח 'onEvict' או 'Eviction' (פינוי) ב-Messageprocessor system.logs. הנוכחות שלהם ביומנים מציינת שכתובות ה-URL של שרתי היעד מוסרות מהמטמון של HTTPClient כי גודל המטמון קטן מדי.

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

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

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

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

הערה: הגדרת ברירת המחדל של Edge לענן פרטי בגרסה 50.00 היא 500.
מספר רשומות של מפות של ערכים מרכזיים

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

הערה: ההגבלה הזו חלה רק על Edge לענן פרטי. המגבלה הזו לא קיימת ב-Edge עבור ענן ציבורי ו-Hybrid.

כדי לעקוף את הבעיה ב-Edge for Private Cloud, צריך ליצור את ה-KVM בהיקף של apiproxy.