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

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

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

בעיות ידועות של 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 for Private Cloud

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

אזור בעיות מוכרות
שדרוג במקום לגרסה 4.53.00

ב-Edge for Private Cloud 4.53.00, אפשר להגדיר אשכולות חדשים רק באמצעות תהליך התקנה חדש. אין תמיכה בשדרוגים במקום. אם אתם משתמשים כרגע בגרסה ישנה יותר של Edge for Private Cloud, לא תוכלו לשדרג ישירות ל-Edge for Private Cloud 4.53.00.

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

הבעיה הזו משפיעה על משתמשים שמנסים להתקין את SSO או את ממשק המשתמש החדש ב-RHEL 8 עם תמיכה ב-FIPS ב-Edge for Private Cloud 4.53.00.

הרכיב המושפע: SSO וממשק המשתמש החדש

הבעיה: אם אתם מתקינים SSO או את ממשק המשתמש החדש במערכת הפעלה RHEL 8 שתומכת ב-FIPS, ההתקנה תיכשל.

פתרון: מומלץ להשתמש בממשק המשתמש הקלאסי, הכולל תכונות מלאות ועונה על הצרכים של ממשק המשתמש.
עדכון Mint של Edge for Private Cloud 4.52.01

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

הרכיב המושפע: מעבד הודעות קצה

הבעיה: אם הפעלתם מונטיזציה ומתקינים את הגרסה 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 לענן פרטי. נקודת החולשה עלולה להוביל להתקפת מניעת שירות (DoS) על הפונקציונליות של ניהול ה-API ב-Apigee. אפשר לקרוא פרטים נוספים ב-Apigee Security Bulletin 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 יש בעיות בשדרוג מ-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 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 שנמצאו ב-Message Processor משפיעים על כל שרתי ה-API. הסימפטומים כוללים עיכובים של 200-300 אלפיות השנייה בזמני העיבוד בהשוואה לזמני התגובה הרגילים של ה-API, והם יכולים להתרחש באופן אקראי גם אם קצב הבקשות לשנייה נמוך. מצב כזה יכול לקרות כשיש יותר מ-50 שרתי יעד שבהם מעבד ההודעות יוצר חיבורים.

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

תיקוף: כדי לקבוע אם ההוצאה של כתובת ה-URL של שרת היעד גורמת לבעיה של זמן האחזור, מחפשים את מילת המפתח 'onEvict' או 'Eviction' ב-Message Processing.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 for Private Cloud. אין הגבלה כזו ב-Edge for Public Cloud וב-Edge Hybrid.

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