مشکلات شناخته شده با Apigee

هنگامی که متغیر جریان cachehit بعد از خط مشی LookupCache استفاده می شود، به دلیل نحوه ارسال نقاط اشکال زدایی برای رفتار ناهمزمان، LookupPolicy شی DebugInfo را قبل از اجرای تماس مجدد پر می کند، که منجر به خطا می شود.

راه حل: بلافاصله پس از اولین تماس، فرآیند را تکرار کنید (تماس دوم را برقرار کنید).

تنظیم PurgeChildEntries در خط مشی InvalidateCache باید فقط مقادیر عنصر KeyFragment را پاک کند اما کل حافظه پنهان را پاک می کند.

راه حل: از خط مشی KeyValueMapOperations برای تکرار نسخه کش و دور زدن نیاز به باطل کردن حافظه پنهان استفاده کنید.

• Apigee Edge از OpenAPI Specification 3.0 پشتیبانی می‌کند زمانی که مشخصاتی را با استفاده از ویرایشگر مشخصات ایجاد می‌کنید و APIها را با استفاده از SmartDocs در پورتال خود منتشر می‌کنید ، اگرچه زیر مجموعه‌ای از ویژگی‌ها هنوز پشتیبانی نمی‌شوند.

  برای مثال، ویژگی‌های زیر از OpenAPI Specification 3.0 هنوز پشتیبانی نمی‌شوند:

  • allOf ویژگی ها برای ترکیب و گسترش طرحواره ها
  • مراجع از راه دور

  اگر یک ویژگی پشتیبانی‌نشده در مشخصات OpenAPI شما ارجاع داده شود، در برخی موارد ابزارها این ویژگی را نادیده می‌گیرند اما همچنان مستندات مرجع API را ارائه می‌کنند. در موارد دیگر، یک ویژگی پشتیبانی نشده باعث بروز خطاهایی می شود که از ارائه موفقیت آمیز اسناد مرجع API جلوگیری می کند. در هر صورت، باید مشخصات OpenAPI خود را تغییر دهید تا از استفاده از ویژگی پشتیبانی نشده تا زمانی که در نسخه بعدی پشتیبانی نشود، خودداری کنید.

  توجه : از آنجایی که ویرایشگر مشخصات در هنگام ارائه اسناد مرجع API محدودتر از SmartDocs است، ممکن است نتایج متفاوتی را بین ابزارها تجربه کنید.

• هنگام استفاده از Try this API در پورتال، هدر Accept بدون توجه به مقدار تنظیم شده برای consumes در مشخصات OpenAPI، روی application/json تنظیم می شود.

• به‌روزرسانی‌های همزمان پورتال (مانند ویرایش صفحه، موضوع، CSS یا اسکریپت) توسط چندین کاربر در حال حاضر پشتیبانی نمی‌شود.
• اگر یک صفحه مستندات مرجع API را از پورتال حذف کنید، راهی برای ایجاد مجدد آن وجود ندارد. شما باید محصول API را حذف و دوباره اضافه کنید و اسناد مرجع API را دوباره ایجاد کنید.
• هنگام پیکربندی خط‌مشی امنیت محتوا ، ممکن است حداکثر 15 دقیقه طول بکشد تا تغییرات به طور کامل اعمال شوند.
• هنگام سفارشی کردن تم پورتال خود ، ممکن است تا 5 دقیقه طول بکشد تا تغییرات به طور کامل اعمال شوند.

• جستجو در نسخه آینده در پورتال یکپارچه ادغام خواهد شد.

apigee-nginx در گره های لبه روتر ممکن است مشکلات مربوط به اتصال پورت ها یا خاتمه فرآیند nginx را گزارش کند.

مؤلفه تحت تأثیر: Edge-router

مشکل: این مشکلات ممکن است به دلیل خطا در تنظیم قابلیت ها در هنگام نصب apigee-nginx ایجاد شود.

راه حل: با اجرای دستور زیر می توانید قابلیت ها را به صورت دستی تنظیم کنید:

setcap CAP_NET_BIND_SERVICE=+ep CAP_KILL=+ep /opt/nginx/sbin/nginx

این مشکل کاربرانی را که سعی می‌کنند SSO یا UI جدید را روی RHEL 8 دارای FIPS در Edge برای Private Cloud 4.53.00 نصب کنند، تحت تأثیر قرار می‌دهد.

مؤلفه تحت تأثیر: SSO و رابط کاربری جدید

مشکل: اگر در حال نصب SSO یا رابط کاربری جدید در سیستم عامل RHEL 8 با FIPS فعال هستید، نصب انجام نمی شود.

راه‌حل: شما تشویق می‌شوید از رابط کاربری کلاسیک استفاده کنید، که ویژگی‌های کاملی دارد و نیازهای عملکرد رابط کاربری را برآورده می‌کند.

این مشکل فقط کسانی را تحت تاثیر قرار می دهد که از MINT استفاده می کنند یا MINT را در Edge برای نصب های خصوصی Cloud فعال کرده اند.

مؤلفه تحت تأثیر: edge-message-processor

مشکل: اگر کسب درآمد را فعال کرده اید و نسخه 4.52.01 را به عنوان یک نصب جدید یا ارتقاء نسخه های قبلی Private Cloud نصب می کنید، با مشکلی در پردازنده پیام مواجه خواهید شد. افزایش تدریجی تعداد موضوعات باز که منجر به فرسودگی منابع می شود، وجود خواهد داشت. استثنای زیر در edge-message-processor system.log مشاهده می شود:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

اخیراً یک آسیب‌پذیری Denial-of-Service (DoS) در چندین پیاده‌سازی پروتکل HTTP/2 (CVE-2023-44487)، از جمله در Apigee Edge برای Private Cloud، کشف شده است. این آسیب‌پذیری می‌تواند منجر به عملکرد مدیریت Apigee Apigee شود. برای جزئیات بیشتر، به بولتن امنیتی Apigee GCP-2023-032 مراجعه کنید.

روتر Edge for Private Cloud و اجزای سرور مدیریتی در معرض اینترنت هستند و به طور بالقوه می توانند آسیب پذیر باشند. اگرچه HTTP/2 در پورت مدیریت سایر مؤلفه‌های Edge ویژه Edge برای Private Cloud فعال است، هیچ یک از آن مؤلفه‌ها در معرض اینترنت نیستند. در اجزای غیر Edge، مانند Cassandra، Zookeeper و دیگران، HTTP/2 فعال نیست. توصیه می کنیم برای رفع آسیب پذیری Edge for Private Cloud مراحل زیر را انجام دهید:

• مراحل Edge for Private Cloud نسخه 4.51.00.11 یا جدیدتر
• مراحل Edge برای نسخه‌های Private Cloud قدیمی‌تر از 4.51.00.11

اگر از 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 برای نسخه‌های 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

Apigee-postgresql با ارتقا از Edge برای 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 روی Red Hat Enterprise Linux (RHEL) 8.0 کار نمی کند.

راه‌حل: به عنوان یک راه‌حل، apigee-mirror روی سروری که نسخه پایین‌تری از RHEL یا سیستم‌عامل پشتیبانی‌شده دیگری برای Apigee دارد نصب کنید. حتی اگر Apigee را روی سرورهای RHEL 8.0 نصب کرده باشید، می‌توانید از آینه برای اضافه کردن بسته‌ها استفاده کنید.

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: تأخیرهای بالای پردازش پراکسی که در پردازشگر پیام یافت می شوند، همه پراکسی های API را تحت تأثیر قرار می دهند. علائم شامل تأخیر 200 تا 300 میلی‌ثانیه در زمان‌های پردازش بیش از زمان‌های عادی پاسخ API است و می‌تواند به‌طور تصادفی حتی با TPS پایین رخ دهد. این می تواند زمانی اتفاق بیفتد که بیش از 50 سرور هدف که در آنها یک پردازشگر پیام اتصال برقرار می کند، رخ دهد.

علت اصلی: پردازنده‌های پیام یک حافظه پنهان نگه می‌دارند که URL سرور هدف را به شی HTTPClient برای اتصالات خروجی به سرورهای هدف نگاشت می‌کند. به طور پیش فرض این تنظیم روی 50 تنظیم شده است که ممکن است برای اکثر استقرارها بسیار کم باشد. هنگامی که یک استقرار دارای چندین ترکیب org/env در یک راه‌اندازی است و تعداد زیادی سرور هدف دارد که مجموعاً از 50 بیشتر می‌شود، URL‌های سرور هدف مدام از حافظه پنهان خارج می‌شوند و باعث تأخیر می‌شوند.

اعتبار سنجی: برای تعیین اینکه آیا حذف URL سرور هدف باعث مشکل تأخیر می شود، در system.logs پردازشگر پیام برای کلمه کلیدی "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 یک مثال است. مقدار بهینه برای تنظیم شما باید بیشتر از تعداد سرورهای هدفی باشد که پردازشگر پیام به آنها متصل می شود. هیچ عارضه جانبی از تنظیم این ویژگی بالاتر وجود ندارد و تنها تأثیر آن بهبود زمان پردازش درخواست پروکسی پردازشگر پیام است.

توجه: Edge برای Private Cloud نسخه 50.00 دارای تنظیمات پیش فرض 500 است.

157933959: درج‌ها و به‌روزرسانی‌های همزمان نقشه ارزش کلیدی یکسان (KVM) با محدوده سازمان یا سطح محیط، باعث داده‌های متناقض و به‌روزرسانی‌های از دست رفته می‌شود.

توجه: این محدودیت فقط برای Edge برای Private Cloud اعمال می شود. Edge for Public Cloud و Hybrid این محدودیت را ندارند.

برای راه‌حلی در Edge برای Private Cloud، KVM را در محدوده apiproxy ایجاد کنید.