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

קריאות של לקוחות ב-Java שמנסות לטעון את ספק הקריפטוגרפיה Bouncy Castle באמצעות השם 'BC' עשויות להיכשל כי ספק ברירת המחדל השתנה ל-Bouncy Castle FIPS כדי לתמוך ב-FIPS. שם הספק החדש הוא "BCFIPS".

יומני הגישה של הנתבים

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

הבעיה הזו משפיעה רק על משתמשים שמשתמשים ב-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 לענן פרטי. נקודת החולשה עלולה להוביל להתקפת מניעת שירות (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 יש בעיות בשדרוג מ-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.
מדיניות 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 של שרת היעד ממשיכות להוצא מ-cache, וכתוצאה מכך נוצרות זמני אחזור ארוכים.

אימות: כדי לקבוע אם פינוי של כתובת URL בשרת היעד גורם לבעיה בזמן האחזור, מחפשים את מילת המפתח 'onEvict' או 'Eviction' ביומני system.logs של Message Processor. נוכחותן ביומני המערכת מציינת שכתובות ה-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 for Private Cloud בגרסה 50.00, הגדרת ברירת המחדל היא 500.
רשומות מרובות למפות מפתח/ערך

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

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

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