בעיות מוכרות ב-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.

אזור בעיות מוכרות
עדכון Mint ל-OPDK 4.52.01

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

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

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

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

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

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

אם אתם משתמשים בגרסה 4.51.00.11 ואילך של ענן פרטי של Edge, יש לבצע את הפעולות הבאות:

  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 עבור גרסאות של ענן פרטי מלפני יותר מ-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

יש בעיות בשדרוג מ-Edge לענן פרטי ב-Apigee-postgresql גרסה 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 ו-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 של שרת היעד גורם לבעיה של זמן האחזור, צריך לחפש את מעבד הודעות system.logs למילת המפתח 'onEvict' או 'פינוי'. הנוכחות שלהם ביומנים מצביעה על כך שכתובות ה-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.