Apigee की आम समस्याएं

Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
Apigee X के दस्तावेज़.
जानकारी पर जाएं

इन सेक्शन में, Apigee की आम समस्याओं के बारे में बताया गया है. ज़्यादातर मामलों में, बताई गई समस्याओं को आने वाली रिलीज़ में ठीक कर दिया जाएगा.

मिसलेनियस एज की ज्ञात समस्याएं

यहां दिए गए सेक्शन में, Edge की अलग-अलग तरह की समस्याओं के बारे में बताया गया है.

इलाका आम तौर पर होने वाली समस्याएं
कैश मेमोरी की समयसीमा खत्म होने की वजह से, cachehit की गलत वैल्यू मिलती है

lookupकैश नीति के बाद, cachehit फ़्लो वैरिएबल का इस्तेमाल किए जाने पर, एसिंक्रोनस व्यवहार के लिए डीबग पॉइंट जिस तरह से भेजे जाते हैं उसकी वजह से, कॉल बैक शुरू होने से पहले lookupPolicy, DebugInfo ऑब्जेक्ट को पॉप्युलेट करती है. इससे एक गड़बड़ी होती है.

समाधान: पहले कॉल के तुरंत बाद प्रक्रिया को फिर से दोहराएं (दूसरा कॉल करें).

अमान्यकेट कैश नीति PurgeChildEntries को 'सही है' पर सेट करने की सुविधा ठीक से काम नहीं करती

अमान्य कैश मेमोरी नीति में PurgeChildEntries को सेट करने से, सिर्फ़ KeyFragment एलिमेंट की वैल्यू पूरी तरह मिटनी चाहिए. हालांकि, इससे पूरी कैश मेमोरी मिट जाती है.

समाधान: कैश वर्शनिंग को दोहराने और कैश अमान्य होने की ज़रूरत को बायपास करने के लिए, KeyValueMapOperations की नीति का इस्तेमाल करें.

Edge यूज़र इंटरफ़ेस (यूआई) की पहले से मालूम समस्याएं

नीचे दिए गए सेक्शन में, Edge यूज़र इंटरफ़ेस (यूआई) की जानी-पहचानी समस्याओं के बारे में बताया गया है.

इलाका आम तौर पर होने वाली समस्याएं
संगठन को आइडेंटिटी ज़ोन से मैप करने के बाद, नेविगेशन बार से Edge एसएसओ (SSO) ज़ोन एडमिन पेज को ऐक्सेस नहीं कर पाना किसी संगठन को आइडेंटिटी ज़ोन से कनेक्ट करने पर, एडमिन > एसएसओ (SSO) को चुनकर, बाईं ओर मौजूद नेविगेशन बार से Edge एसएसओ (SSO) ज़ोन एडमिन पेज को ऐक्सेस नहीं किया जा सकता. समाधान के तौर पर, इस यूआरएल का इस्तेमाल करके सीधे पेज पर जाएं: https://apigee.com/sso

इंटिग्रेट किए गए पोर्टल की सामान्य समस्याएं

नीचे दिए सेक्शन में, इंटिग्रेट किए गए पोर्टल से जुड़ी समस्याओं के बारे में बताया गया है.

इलाका आम तौर पर होने वाली समस्याएं
SmartDocs
  • स्पेसिफ़िकेशन एडिटर की मदद से स्पेसिफ़िकेशन बनाने पर और अपने पोर्टल पर SmartDocs की मदद से एपीआई पब्लिश करने पर, Apigee Edge OpenAPI स्पेसिफ़िकेशन 3.0 के साथ काम करता है. हालांकि, कुछ सुविधाएं फ़िलहाल इस पर काम नहीं करती हैं.

    उदाहरण के लिए, OpenAPI स्पेसिफ़िकेशन 3.0 की ये सुविधाएं अभी काम नहीं करती हैं:

    • स्कीमा को मिलाने और बढ़ाने के लिए allOf प्रॉपर्टी
    • रिमोट रेफ़रंस

    अगर आपके OpenAPI स्पेसिफ़िकेशन में, काम न करने वाली किसी सुविधा के बारे में बताया गया है, तो कुछ मामलों में टूल, सुविधा को नज़रअंदाज़ कर देंगे, लेकिन एपीआई के रेफ़रंस दस्तावेज़ को रेंडर करेंगे. अन्य मामलों में, काम न करने वाली सुविधा की वजह से गड़बड़ियां हो सकती हैं. इससे एपीआई रेफ़रंस दस्तावेज़ को रेंडर होने में समस्या आ सकती है. दोनों ही मामलों में, आपको OpenAPI स्पेसिफ़िकेशन में बदलाव करना होगा, ताकि काम न करने वाली सुविधा का इस्तेमाल तब तक न किया जा सके, जब तक आने वाले वर्शन में इसे इस्तेमाल न किया जा सके.

    ध्यान दें: एपीआई रेफ़रंस दस्तावेज़ रेंडर करते समय, खास जानकारी में बदलाव करने वाला, SmartDocs की तुलना में कम पाबंदी वाला होता है. इस वजह से, आपको टूल के बीच अलग-अलग नतीजे दिख सकते हैं.

  • पोर्टल में इस एपीआई को आज़माएं का इस्तेमाल करते समय, Accept हेडर application/json पर सेट होता है. इससे कोई फ़र्क़ नहीं पड़ता कि OpenAPI स्पेसिफ़िकेशन में, consumes के लिए वैल्यू कुछ भी सेट की गई है.
एसएएमएल आइडेंटिटी प्रोवाइडर कस्टम डोमेन के लिए, एसएएमएल के आइडेंटिटी प्रोवाइडर की मदद से एक बार लॉग आउट (एसएलओ) नहीं किया जा सकता. एसएएमएल आइडेंटिटी प्रोवाइडर की मदद से कस्टम डोमेन को चालू करने के लिए, एसएएमएल सेटिंग को कॉन्फ़िगर करते समय, साइन-आउट करने का यूआरएल फ़ील्ड को खाली छोड़ दें.
पोर्टल एडमिन
  • एक साथ कई लोगों को पोर्टल के अपडेट नहीं मिलेंगे. जैसे- पेज, थीम, सीएसएस या स्क्रिप्ट में बदलाव.
  • अगर पोर्टल से किसी एपीआई रेफ़रंस दस्तावेज़ वाले पेज को मिटाया जाता है, तो इसे फिर से बनाने का कोई तरीका नहीं होता. आपको एपीआई प्रॉडक्ट को मिटाकर, उसे फिर से जोड़ना होगा और एपीआई के रेफ़रंस दस्तावेज़ को फिर से जनरेट करना होगा.
  • कॉन्टेंट की सुरक्षा नीति को कॉन्फ़िगर करते समय, बदलावों को पूरी तरह से लागू होने में 15 मिनट लग सकते हैं.
  • पोर्टल थीम को पसंद के मुताबिक बनाते समय, बदलावों को पूरी तरह से लागू होने में पांच मिनट लग सकते हैं.
पोर्टल की सुविधाएं
  • आने वाले समय में, Search को इंटिग्रेट किए गए पोर्टल में इंटिग्रेट किया जाएगा.

निजी क्लाउड के लिए Edge से जुड़ी आम समस्याएं

यहां दिए गए सेक्शन में, निजी क्लाउड के लिए Edge से जुड़ी आम समस्याओं के बारे में बताया गया है.

इलाका पहले से मालूम समस्याएं
OPDK 4.52.01 Mint अपडेट

यह समस्या सिर्फ़ उन लोगों पर लागू होती है जो MINT का इस्तेमाल कर रहे हैं या निजी क्लाउड इंस्टॉलेशन के लिए Edge में MINT चालू किया गया है.

कॉम्पोनेंट पर असर हुआ: एज-मैसेज-प्रोसेसर

समस्या: अगर आपने कमाई करने की सुविधा चालू की है और Private Cloud के पुराने वर्शन से 4.52.01 को नए इंस्टॉल या अपग्रेड के तौर पर इंस्टॉल किया जा रहा है, तो आपको मैसेज प्रोसेस करने वाली कंपनियों को लेकर कोई समस्या आ सकती है. ओपन थ्रेड की संख्या धीरे-धीरे बढ़ेगी, जिससे संसाधन खत्म हो जाएंगे. यह अपवाद Edge-message-प्रोसेसर सिस्टम.log में दिखता है:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Apigee HTTP/2 से जुड़े जोखिम की आशंका

हाल ही में, एचटीटीपी/2 प्रोटोकॉल (CVE-2023-44487) लागू करने के दौरान कई तरीकों से सेवा में रुकावट (डीओएस) के जोखिम का पता चला. इसमें Private Cloud के लिए Apigee Edge भी शामिल है. जोखिम की आशंका की वजह से, Apigee API मैनेजमेंट के फ़ंक्शन का DoS बन सकता है. ज़्यादा जानकारी के लिए, Apigee Security बुलेटिन GCP-2023-032 पर जाएं.

Private Cloud के रूटर और मैनेजमेंट सर्वर कॉम्पोनेंट के लिए एज, इंटरनेट के संपर्क में आते हैं और इससे असुरक्षित हो सकता है. हालांकि, निजी क्लाउड के लिए Edge के खास कॉम्पोनेंट के मैनेजमेंट पोर्ट पर, एचटीटीपी/2 की सुविधा चालू है. हालांकि, उनमें से कोई भी कॉम्पोनेंट इंटरनेट को ऐक्सेस नहीं करता. कैसेंद्रा, ज़ूकीपर जैसे नॉन-एज कॉम्पोनेंट पर, एचटीटीपी/2 चालू नहीं होता है. हमारा सुझाव है कि 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

अगर 4.51.00.11 से पुराने निजी क्लाउड वर्शन के लिए Edge का इस्तेमाल किया जा रहा है, तो यह तरीका अपनाएं:

  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
वर्शन 4.52 में अपडेट करने पर Postgresql अपग्रेड

Apigee-postgresql को, Edge के लिए Private Cloud के 4.50 या 4.51 वर्शन से 4.52 में अपग्रेड करने में समस्याएं आ रही हैं. मुख्य रूप से, समस्याएं तब आती हैं, जब टेबल की संख्या 500 से ज़्यादा होती है.

नीचे दी गई एसक्यूएल क्वेरी चलाकर, Postgres में टेबल की कुल संख्या देखी जा सकती है:

select count(*) from information_schema.tables

समाधान: Apigee Edge 4.50.00 या 4.51.00 से 4.52.00 को अपडेट करते समय, Apigee-postgresql को अपग्रेड करने से पहले, शुरुआती चरण पूरा करना न भूलें.

RHEL 8.0 पर apigee-mirror

apigee-mirror, Red Hat Enterprise Linux (RHEL) 8.0 पर काम नहीं करता.

समाधान: वैकल्पिक समाधान के तौर पर, Apigee के पुराने वर्शन या किसी दूसरे काम करने वाले ऑपरेटिंग सिस्टम पर चलने वाले सर्वर पर apigee-mirror इंस्टॉल करें. इसके बाद, पैकेज जोड़ने के लिए मिरर का इस्तेमाल किया जा सकता है. भले ही, आपने RHEL 8.0 सर्वर पर Apigee को इंस्टॉल किया हो.

LDAP नीति

149245401: LDAP संसाधन के ज़रिए कॉन्फ़िगर किए गए जेएनडीआई के लिए, LDAP कनेक्शन पूल सेटिंग नहीं दिखतीं और जेएनडीआई डिफ़ॉल्ट रूप से, हर बार एक बार इस्तेमाल किए जाने वाले कनेक्शन की वजह बनती है. इस वजह से, हर बार एक ही बार में इस्तेमाल के लिए कनेक्शन खोले और बंद किए जा रहे हैं. इससे LDAP सर्वर से हर घंटे बड़ी संख्या में कनेक्शन बन रहे हैं.

समाधान:

LDAP कनेक्शन पूल की प्रॉपर्टी बदलने के लिए, सभी LDAP नीतियों में ग्लोबल बदलाव सेट करने के लिए यह तरीका अपनाएं.

  1. अगर कॉन्फ़िगरेशन प्रॉपर्टी पहले से मौजूद नहीं है, तो उसे बनाएं:
    /opt/apigee/customer/application/message-processor.properties
  2. अपने LDAP रिसॉर्स कॉन्फ़िगरेशन की ज़रूरत के हिसाब से फ़ाइल में नीचे दी गई जानकारी जोड़ें (Java नेमिंग और डायरेक्ट्री इंटरफ़ेस (जेएनडीआई) की वैल्यू बदलें).
    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. हर मैसेज प्रोसेसर को रीस्टार्ट करें.

इस बात की पुष्टि करने के लिए कि आपकी कनेक्शन पूल जेएनडीआई प्रॉपर्टी लागू हो रही हैं, आप समय-समय पर LDAP कनेक्शन पूल के व्यवहार की निगरानी करने के लिए, tcpdump लागू कर सकते हैं.

ज़्यादा अनुरोध प्रोसेस होने में लगने वाला समय

139051927: Message प्रोसेसर में मिलने वाली ज़्यादा प्रॉक्सी प्रोसेसिंग इंतज़ार के समय से सभी एपीआई प्रॉक्सी पर असर पड़ रहा है. लक्षणों में, एपीआई से रिस्पॉन्स मिलने में सामान्य से 200 से 300 मि॰से॰ की देरी शामिल है. टीपीएस कम होने पर भी ये लक्षण अचानक दिख सकते हैं. ऐसा तब हो सकता है, जब कोई मैसेज प्रोसेसर, 50 से ज़्यादा टारगेट सर्वर से कनेक्शन बनाता है.

मुख्य वजह: मैसेज प्रोसेसर, कैश मेमोरी में सेव रखते हैं, जो टारगेट सर्वर के यूआरएल को HTTPClient ऑब्जेक्ट से मैप करता है. इससे टारगेट सर्वर पर भेजे जाने वाले कनेक्शन का पता चलता है. डिफ़ॉल्ट रूप से यह सेटिंग 50 पर सेट होती है, जो ज़्यादातर डिप्लॉयमेंट के लिए बहुत कम हो सकती है. जब किसी डिप्लॉयमेंट में संगठन/एनवायरमेंट के कई कॉम्बिनेशन होते हैं और कुल 50 से ज़्यादा टारगेट सर्वर होते हैं, तो टारगेट सर्वर के यूआरएल कैश मेमोरी से हटते रहते हैं. इस वजह से, इंतज़ार का समय बढ़ता है.

पुष्टि करना: यह पता लगाने के लिए कि टारगेट सर्वर के यूआरएल को हटाने की वजह से इंतज़ार का समय की समस्या हो रही है या नहीं, "onEytct" या "Eviction" कीवर्ड के लिए Message प्रोसेसर system.logs खोजें. लॉग में उनकी मौजूदगी से पता चलता है कि टारगेट सर्वर के यूआरएल, एचटीटीपी Client कैश मेमोरी से हटा दिए जा रहे हैं, क्योंकि कैश मेमोरी का साइज़ बहुत छोटा है.

समाधान: निजी क्लाउड के लिए Edge के 19.01 और 19.06 वर्शन के लिए, HTTPClient की कैश मेमोरी में बदलाव और कॉन्फ़िगर किया जा सकता है /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

इसके बाद, मैसेज प्रोसेसर को रीस्टार्ट करें. मैसेज प्रोसेस करने वाली सभी कंपनियों के लिए एक जैसे बदलाव करें.

500 वैल्यू एक उदाहरण है. आपके सेटअप के लिए सबसे सही वैल्यू, मैसेज प्रोसेसर से कनेक्ट किए जाने वाले टारगेट सर्वर की संख्या से ज़्यादा होनी चाहिए. इस प्रॉपर्टी को ऊपर सेट करने से कोई खराब असर नहीं होता. इसका असर, मैसेज प्रोसेसर के प्रॉक्सी अनुरोध को प्रोसेस करने में ज़्यादा समय लगेगा.

ध्यान दें: Private Cloud के वर्शन 50.00 के लिए Edge की डिफ़ॉल्ट सेटिंग 500 है.

की वैल्यू मैप के लिए एक से ज़्यादा एंट्री

157933959: संगठन या एनवायरमेंट लेवल के दायरे में आने वाले एक जैसे कुंजी वैल्यू मैप (केवीएम) में एक साथ इंसर्ट और अपडेट करने की वजह से डेटा अलग-अलग होता है और अपडेट मिट जाते हैं.

ध्यान दें: यह सीमा सिर्फ़ Private Cloud के लिए Edge पर लागू होती है. Public Cloud और हाइब्रिड के लिए Edge पर यह सीमा नहीं होती.

Private Cloud के लिए Edge में समाधान पाने के लिए, apiproxy स्कोप में केवीएम बनाएं.