בעיות מוכרות ב-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.01 NGINX Vulnerability Assessment (CVE-2026-42945)

התגלתה נקודת חולשה (CVE-2026-42945) שמשפיעה על ngx_http_rewrite_module ב-NGINX. יכול להיות שכלים לסריקת אבטחה יסמנו את קובצי ה-NGINX הבינאריים שכלולים ב-Apigee Edge לענן פרטי, כי המודול הזה עובר קומפילציה סטטית ל-NGINX.

ההשפעה על Apigee Edge Private Cloud:

‫Apigee Edge for Private Cloud לא מושפע מנקודת החולשה הזו בהגדרת ברירת המחדל שלו. הפגיעות של CVE-2026-42945 תלויה בתבניות הגדרה ספציפיות של NGINX, במיוחד בשימוש בהנחיה rewrite ברצף מסוים. הדפוסים האלה לא מופיעים בהגדרות NGINX רגילות של Apigee Edge לענן פרטי.

נדרשת פעולה:

  • במקרה של הגדרות ברירת מחדל של Apigee Edge for Private Cloud: לא נדרשים תיקונים, שדרוגים או שינויים תפעוליים. ממצאים של סורק בנוגע ל-CVE-2026-42945 יכולים להיחשב כתוצאות חיוביות כוזבות בהתקנות שמוגדרות כברירת מחדל. אפשר להשתמש בטקסט הבא כדי לתעד את החריג הזה במערכת לניהול נקודות חולשה:

    CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

  • לגבי הגדרות NGINX בהתאמה אישית: אם שיניתם באופן ידני את קובצי ההגדרות של NGINX בהתקנה של Apigee Edge לענן פרטי (לדוגמה, ב-/opt/nginx), אתם צריכים לבצע את הבדיקה העצמית הבאה כדי לוודא שההתאמות האישיות לא יצרו בטעות את התבנית הפגיעה:
    1. בודקים אם יש הוראת שכתוב: בכל צומת NGINX, מריצים את הפקודה: 
      sudo grep -rnI '^\s*rewrite\b' /opt/nginx
    2. ניתוח התוצאות:
      • אם הפקודה לא מחזירה פלט, המערכת לא מושפעת.
      • אם נמצאות התאמות, בודקים כל מופע. הפגיעות קיימת רק אם כל התנאים הבאים מתקיימים לגבי בלוק נתון:
        • נעשה שימוש בהוראה rewrite.
        • אחריו מופיעה מיד עוד הנחיית rewrite, if או set באותו בלוק הגדרה.
        • הוראות משתמשות בקבוצה לחילוץ של PCRE ללא שם (לדוגמה, $1, $2 וכו').
        • המחרוזת להחלפה בהוראה מכילה סימן שאלה (?).
    3. הפחתת הסיכון (אם יש פגיעות): אם כל התנאים שלמעלה מתקיימים לגבי חלק כלשהו בהגדרה המותאמת אישית, אפשר להפחית את הסיכון באמצעות:
      • הסרת סימן השאלה (?) ממחרוזת ההחלפה.
      • שימוש בקבוצות ללכידת PCRE עם שם במקום בקבוצות ללא שם.
      • הערכה מחדש של הצורך בהוראות משורשרות.
‫Edge for Private Cloud 4.53.00 440148595: End of Life Popup Warning Displayed Excessively

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

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

יכול להיות שקריאות ל-Java של לקוחות שמנסות לטעון את ספק ההצפנה Bouncy Castle באמצעות השם BC ייכשלו, כי ספק ברירת המחדל שונה ל-Bouncy Castle FIPS כדי לתמוך ב-FIPS. השם החדש של הספק הוא BCFIPS.
‫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, תיתקלו בבעיה במעבדי ההודעות. מספר השרשורים הפתוחים יגדל בהדרגה עד שייגמרו המשאבים. החריגה הבאה מופיעה ביומן המערכת של 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 לגרסאות של ענן פרטי שקודמות לגרסה 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 לענן פרטי לגרסה 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 של שרת יעד, מחפשים ביומני המערכת של מעבד הבקשות את מילות המפתח 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 הוא דוגמה. הערך האופטימלי להגדרה שלכם צריך להיות גדול ממספר שרתי היעד שאליהם מעבד ההודעות יתחבר. אין תופעות לוואי להגדרה של הנכס הזה לערך גבוה יותר, וההשפעה היחידה תהיה שיפור בזמני העיבוד של בקשות פרוקסי של מעבד ההודעות.

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

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

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

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