Znane problemy z Apigee

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
informacje

W sekcjach poniżej opisaliśmy znane problemy związane z Apigee. W większości przypadków wymienione problemy zostaną rozwiązane w przyszłej wersji.

Inne znane problemy z Edge

W sekcjach poniżej opisaliśmy różne znane problemy z Edge.

Obszar/podsumowanie Znane problemy
Wygaśnięcie pamięci podręcznej powoduje nieprawidłową wartość cachehit

Gdy zmienna przepływu cachehit jest używana po polityce LookupCache, ze względu na sposób wysyłania punktów debugowania w przypadku zachowania asynchronicznego, polityka LookupPolicy wypełnia obiekt DebugInfo przed wykonaniem wywołania zwrotnego, co powoduje błąd.

Obejście: powtórz proces (nawiązywanie drugiego połączenia) bezpośrednio po pierwszym połączeniu.

Ustawienie zasady PurgeChildEntries Nieważna pamięć podręczna na Prawda nie działa prawidłowo

Ustawienie wartości PurgeChildEntries w zasadzie InvalidateCache powinno spowodować usunięcie tylko wartości elementu KeyFragment, ale powoduje wyczyszczenie całej pamięci podręcznej.

Rozwiązanie: użyj polityki KeyValueMapOperations, aby iterować wersjonowanie pamięci podręcznej i ominąć konieczność unieważniania pamięci podręcznej.

Równoczesne żądania wdrożenia w przypadku SharedFlow lub interfejsu API proxy mogą spowodować niespójny stan na serwerze zarządzającym, na którym widoczne są jako wdrożone różne wersje.

Może się tak zdarzyć, gdy równolegle działają różne wersje potoku wdrożeniowego CI/CD. Aby uniknąć tego problemu, nie wdrażaj zasobów proxy API ani SharedFlow przed zakończeniem bieżącego wdrożenia.

Rozwiązanie: unikaj jednoczesnego wdrażania proxy interfejsu API i SharedFlow.

Liczby wywołań interfejsu API podawane w analityce interfejsu Edge API mogą zawierać zduplikowane dane.

Interfejs Edge API Analytics może czasami zawierać zduplikowane dane wywołań interfejsu API. W takim przypadku liczby wywołań interfejsu API wyświetlane w Edge API Analytics są wyższe niż porównywalne wartości wyświetlane w zewnętrznych narzędziach analitycznych.

Rozwiązanie: wyeksportuj dane analityczne i użyj pola gateway_flow_id, aby usunąć duplikaty.

Znane problemy z interfejsem Edge

W tych sekcjach opisano znane problemy z interfejsem Edge.

Powierzchnia Znane problemy
Po zmapowaniu organizacji na strefę tożsamości nie można uzyskać dostępu do strony administrowania strefą logowania Edge SSO z paska nawigacyjnego Gdy połączysz organizację ze strefą tożsamości, utracisz dostęp do strony Administrowanie strefą logowania na serwerach brzegowych za pomocą lewego paska nawigacyjnego – wybierz Administrator > Logowanie jednokrotne. Aby obejść ten problem, otwórz stronę bezpośrednio, korzystając z tego adresu URL: https://apigee.com/sso

Znane problemy z zintegrowanym portalem

W poniższych sekcjach opisaliśmy znane problemy związane z zintegrowanym portalem.

Obszar Znane problemy
SmartDocs
  • Apigee Edge obsługuje specyfikację OpenAPI 3.0, gdy tworzysz specyfikacje za pomocą edytora specyfikacji i publikujesz interfejsy API za pomocą SmartDocs w portalu, choć część funkcji nie jest jeszcze obsługiwana.

    Na przykład te funkcje specyfikacji OpenAPI 3.0 nie są jeszcze obsługiwane:

    • allOfwłaściwości do łączenia i rozszerzania schematów
    • odwołania zdalne.

    Jeśli w specyfikacji OpenAPI jest nawiązanie do funkcji, której nie obsługujemy, narzędzia mogą ją zignorować, ale nadal renderować dokumentację referencyjną interfejsu API. W innych przypadkach nieobsługiwana funkcja spowoduje błędy, które uniemożliwią renderowanie dokumentacji referencyjnej interfejsu API. W obu przypadkach musisz zmodyfikować specyfikację OpenAPI, aby uniknąć używania funkcji, która nie jest obsługiwana, dopóki nie zostanie obsługiwana w przyszłej wersji.

    Uwaga: podczas renderowania dokumentacji referencyjnej interfejsu API edytor specyfikacji jest mniej restrykcyjny niż SmartDocs, więc wyniki uzyskane za pomocą tych narzędzi mogą się różnić.

  • Gdy używasz opcji Wypróbuj ten interfejs API na portalu, nagłówek Accept jest ustawiony na application/json niezależnie od wartości consumes w specyfikacji OpenAPI.
  • 138438484: Wiele serwerów nie jest obsługiwanych.
Dostawca tożsamości SAML Wylogowanie jednokrotne (SLO) z dostawcą tożsamości SAML nie jest obsługiwane w przypadku domen niestandardowych. Aby włączyć domenę niestandardową z dostawcą tożsamości SAML, podczas konfigurowania ustawień SAML pozostaw puste pole URL wylogowywania.
Administrator portalu
  • Jednoczesne aktualizowanie portalu (np. strony, motywu, szablonu CSS lub skryptu) przez wielu użytkowników nie jest obecnie obsługiwane.
  • Jeśli usuniesz stronę dokumentacji referencyjnej API z portalu, nie będzie można jej ponownie utworzyć. Musisz usunąć i ponownie dodać produkt API, a następnie wygenerować dokumentację referencyjną API.
  • Podczas konfigurowania zasad bezpieczeństwa treści pełne zastosowanie zmian może potrwać do 15 minut.
  • Gdy dostosujesz motyw portalu, wprowadzenie zmian może potrwać do 5 minut.
Funkcje portalu
  • Wyszukiwarka zostanie zintegrowana z integrowanym portalem w jednej z kolejnych wersji.

Znane problemy z Edge for Private Cloud

W sekcjach poniżej opisujemy znane problemy z Edge dla chmury prywatnej.

Obszar Znane problemy
Edge for Private Cloud 4.53.00 412696630. Nie udało się załadować magazynów kluczy podczas uruchamiania

Komponent edge-message-processor może okresowo nie wczytywać co najmniej jednego magazynu kluczy podczas uruchamiania, co powoduje błędy w ruchu, gdy magazyn kluczy jest używany przez serwer proxy interfejsu API. Ponowne uruchomienie komponentu edge-message-processor zwykle rozwiązuje problem.

Edge for Private Cloud 4.53.00 Objaśnienia w języku Java

Wywołania Java klienta, które próbują wczytać dostawcę kryptografii Bouncy Castle przy użyciu nazwy „BC”, mogą się nie powieść, ponieważ domyślny dostawca został zmieniony na Bouncy Castle FIPS, aby obsługiwać FIPS. Nowa nazwa dostawcy to „BCFIPS”.

Aktualizacja Edge for Private Cloud 4.52.01 Mint

Ten problem dotyczy tylko użytkowników, którzy korzystają z MINT lub mają włączoną tę usługę w Edge dla instalacji chmury prywatnej.

Komponent, którego dotyczy problem: edge-message-processor

Problem: jeśli masz włączoną monetyzację i instalujesz wersję 4.52.01 jako nową instalację lub uaktualniasz ją z poprzednich wersji chmury prywatnej, napotkasz problem z procesorami wiadomości. Liczba otwartych wątków będzie stopniowo wzrastać, co doprowadzi do wyczerpania zasobów. W pliku system.log procesora komunikatów brzegowych widać ten wyjątek:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Luka w zabezpieczeniach protokołu HTTP/2 w Apigee

W wielu implementacjach protokołu HTTP/2 (CVE-2023-44487), w tym w Apigee Edge dla chmury prywatnej, wykryto niedawno lukę w zabezpieczeniach, która umożliwia atak typu DoS (Denial-of-Service). Ta podatność może prowadzić do ataku typu DoS na funkcje zarządzania interfejsami API Apigee. Więcej informacji znajdziesz w biuletynie o zabezpieczeniach Apigee GCP-2023-032.

Komponenty Edge for Private Cloud router i serwer zarządzania są dostępne w internecie i mogą być podatne na ataki. Chociaż protokół HTTP/2 jest włączony na porcie zarządzania innych komponentów Edge dla chmury prywatnej, żaden z tych komponentów nie jest dostępny w internecie. W przypadku komponentów innych niż Edge, takich jak Cassandra, Zookeeper i inne, protokół HTTP/2 nie jest włączony. Aby rozwiązać problem z luką w zabezpieczeniach Edge dla chmury prywatnej, wykonaj te czynności:

Jeśli korzystasz z Edge Private Cloud w wersji 4.51.00.11 lub nowszej, wykonaj te czynności:

  1. Zaktualizuj serwer zarządzania:

    1. Na każdym węźle serwera zarządzania otwórz /opt/apigee/customer/application/management-server.properties
    2. Dodaj ten wiersz do pliku właściwości:
      conf_webserver_http2.enabled=false
    3. Ponownie uruchom komponent serwera zarządzania:
      apigee-service edge-management-server restart
  2. Zaktualizuj procesor wiadomości:

    1. Na każdym węźle procesora wiadomości otwórz /opt/apigee/customer/application/message-processor.properties
    2. Dodaj ten wiersz do pliku właściwości:
      conf_webserver_http2.enabled=false
    3. Uruchom ponownie komponent procesora wiadomości:
      apigee-service edge-message-processor restart
  3. Zaktualizuj router:

    1. Na każdym węźle routera otwórz /opt/apigee/customer/application/router.properties
    2. Dodaj ten wiersz do pliku właściwości:
      conf_webserver_http2.enabled=false
    3. Uruchom ponownie komponent procesora wiadomości:
      apigee-service edge-router restart
  4. Aktualizacja QPID:

    1. Na każdym węźle QPID otwórz /opt/apigee/customer/application/qpid-server.properties
    2. Dodaj ten wiersz do pliku właściwości:
      conf_webserver_http2.enabled=false
    3. Uruchom ponownie komponent procesora wiadomości:
      apigee-service edge-qpid-server restart
  5. Aktualizacja Postgres:

    1. Na każdym węźle Postgres otwórz /opt/apigee/customer/application/postgres-server.properties
    2. Dodaj ten wiersz do pliku właściwości:
      conf_webserver_http2.enabled=false
    3. Uruchom ponownie komponent procesora wiadomości:
      apigee-service edge-postgres-server restart

Jeśli używasz Edge for Private Cloud w wersji starszej niż 4.51.00.11, wykonaj te czynności:

  1. Zaktualizuj serwer zarządzania:

    1. Na każdym węźle serwera zarządzania otwórz /opt/apigee/customer/application/management-server.properties
    2. Dodaj do pliku właściwości te 2 wiersze:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Ponownie uruchom komponent serwera zarządzania:
      apigee-service edge-management-server restart
  2. Zaktualizuj procesor wiadomości:

    1. Na każdym węźle procesora wiadomości otwórz /opt/apigee/customer/application/message-processor.properties
    2. Dodaj do pliku właściwości te 2 wiersze:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Uruchom ponownie komponent procesora wiadomości:
      apigee-service edge-message-processor restart
  3. Zaktualizuj router:

    1. Na każdym węźle routera otwórz /opt/apigee/customer/application/router.properties
    2. Dodaj do pliku właściwości te 2 wiersze:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Uruchom ponownie komponent procesora wiadomości:
      apigee-service edge-router restart
  4. Aktualizacja QPID:

    1. Na każdym węźle QPID otwórz /opt/apigee/customer/application/qpid-server.properties
    2. Dodaj do pliku właściwości te 2 wiersze:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Uruchom ponownie komponent procesora wiadomości:
      apigee-service edge-qpid-server restart
  5. Aktualizacja Postgres:

    1. Na każdym węźle Postgres otwórz /opt/apigee/customer/application/postgres-server.properties
    2. Dodaj do pliku właściwości te 2 wiersze:
      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false
    3. Uruchom ponownie komponent procesora wiadomości:
      apigee-service edge-postgres-server restart
Uaktualnianie bazy danych Postgresql podczas aktualizacji do wersji 4.52

Występują problemy z aktualizacją Apigee-postgresql z Edge for Private Cloud w wersji 4.50 lub 4.51 do wersji 4.52. Problemy występują głównie wtedy, gdy liczba tabel przekracza 500.

Aby sprawdzić łączną liczbę tabel w PostgreSQL, uruchom to zapytanie SQL:

select count(*) from information_schema.tables

Obejście: podczas aktualizowania Apigee Edge w wersji 4.50.00 lub 4.51.00 do wersji 4.52.00 przed uaktualnieniem Apigee-postgresql wykonaj krok wstępny.

Zasady LDAP

149245401: ustawienia puli połączeń LDAP dla JNDI skonfigurowane za pomocą zasobu LDAP nie są odzwierciedlane, a ustawienia domyślne JNDI powodują, że za każdym razem używane są połączenia jednorazowe. W rezultacie połączenia są otwierane i zamykane za każdym razem do jednorazowego użytku, co powoduje dużą liczbę połączeń z serwerem LDAP w ciągu godziny.

Obejście:

Aby zmienić właściwości puli połączeń LDAP, wykonaj te czynności, aby wprowadzić globalną zmianę we wszystkich zasadach LDAP.

  1. Utwórz plik właściwości konfiguracji, jeśli jeszcze nie istnieje:
    /opt/apigee/customer/application/message-processor.properties
  2. Dodaj do pliku te wiersze (zastąp wartości właściwości Java Naming and Directory Interface (JNDI) zgodnie z wymaganiami konfiguracji zasobu 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. Upewnij się, że plik /opt/apigee/customer/application/message-processor.properties należy do użytkownika apigee:apigee.
  4. Uruchom ponownie każdy procesor wiadomości.

Aby sprawdzić, czy właściwości JNDI puli połączeń działają prawidłowo, możesz wykonać tcpdump, aby obserwować zachowanie puli połączeń LDAP w czasie.

Długi czas przetwarzania żądań

139051927: Wysokie opóźnienia przetwarzania przez serwer proxy w procesorze wiadomości mają wpływ na wszystkie serwery proxy interfejsu API. Objawy to opóźnienia w czasie przetwarzania o 200–300 ms w porównaniu z normalnym czasem odpowiedzi interfejsu API. Mogą one występować losowo nawet przy niskim TPS. Może to wystąpić, gdy liczba serwerów docelowych, z którymi łączy się procesor wiadomości, przekracza 50.

Przyczyna: Procesory wiadomości przechowują pamięć podręczną, która mapuje adres URL serwera docelowego na obiekt HTTPClient dla połączeń wychodzących z serwerami docelowymi. Domyślnie to ustawienie ma wartość 50, która może być zbyt niska w przypadku większości wdrożeń. Jeśli w konfiguracji wdrożenia występuje wiele kombinacji organizacji i środowiska, a łączna liczba serwerów docelowych przekracza 50, adresy URL serwerów docelowych są usuwane z pamięci podręcznej, co powoduje opóźnienia.

Weryfikacja: Aby sprawdzić, czy problem z opóźnieniem jest spowodowany usunięciem adresu URL serwera docelowego, wyszukaj w plikach system.logs procesora wiadomości słowa kluczowe „onEvict” lub „Eviction”. Ich obecność w logach wskazuje, że adresy URL serwera docelowego są usuwane z pamięci podręcznej HTTPClient, ponieważ jej rozmiar jest zbyt mały.

Obejście: w przypadku Edge for Private Cloud w wersjach 19.01 i 19.06 możesz edytować i konfigurować pamięć podręczną HTTPClient:/opt/apigee/customer/application/message-processor.properties

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

Następnie ponownie uruchom procesor wiadomości. Wprowadź te same zmiany we wszystkich procesorach wiadomości.

Wartość 500 jest tylko przykładem. Optymalna wartość w Twojej konfiguracji powinna być większa niż liczba serwerów docelowych, z którymi połączy się procesor wiadomości. Ustawienie wyższej wartości tej właściwości nie ma żadnych skutków ubocznych, a jedynym efektem będzie skrócenie czasu przetwarzania żądań proxy przez procesor wiadomości.

Uwaga: w przypadku Edge for Private Cloud w wersji 50.00 domyślne ustawienie to 500.

Wiele wpisów w przypadku map par klucz-wartość

157933959: Jednoczesne wstawianie i aktualizowanie tej samej mapy klucz-wartość (KVM) w zakresie organizacji lub środowiska powoduje niespójność danych i utratę aktualizacji.

Uwaga: to ograniczenie dotyczy tylko Edge for Private Cloud. Edge for Public Cloud i Hybrid nie mają tego ograniczenia.

Aby obejść ten problem w Edge for Private Cloud, utwórz KVM w apiproxyzakresie.