Znane problemy z Apigee Edge

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

W poniższych sekcjach opisano znane problemy z Apigee Edge. W większości przypadków wymienione problemy zostaną rozwiązane w kolejnej wersji.

Różne znane problemy z Edge

W tych sekcjach opisano różne znane problemy z Edge.

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

Gdy po zasadzie LookupCache jest używana zmienna przepływu cachehit, ze względu na sposób wysyłania punktów debugowania w celu asynchronicznego działania LookupPolicy wypełnia obiekt DebugInfo przed wykonaniem wywołania zwrotnego, co skutkuje błędem.

Obejście: powtórz ten proces (utwórz drugie wywołanie) tuż po pierwszym wywołaniu.

Ustawianie wartości „true” (prawda) PurgeChildEntries nie działa prawidłowo

Ustawienie PurgeChildEntries w zasadzie InvalidateCache powinno trwale usuwać tylko wartości elementu KeyFragment, ale czyści całą pamięć podręczną.

Obejście: użyj zasady KeyValueMapOperations, aby iterować obsługę wersji pamięci podręcznej i pominąć potrzebę unieważniania pamięci podręcznej.

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 ze zintegrowanym portalem

W poniższych sekcjach opisano znane problemy ze zintegrowanym portalem.

Powierzchnia Znane problemy
SmartDocs
  • Apigee Edge obsługuje OpenAPI 3.0, gdy tworzysz specyfikacje w edytorze specyfikacji i publikujesz interfejsy API przy użyciu SmartDokumentów w portalu, ale niektóre funkcje nie są jeszcze obsługiwane.

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

    • Właściwości allOf służące do łączenia i rozszerzania schematów
    • Odwołania zdalne

    Jeśli specyfikacja OpenAPI odwołuje się do nieobsługiwanej funkcji, narzędzia w niektórych przypadkach ją zignorują, ale nadal będą renderować dokumentację API. W innych przypadkach nieobsługiwana funkcja spowoduje błędy, które uniemożliwią prawidłowe wyrenderowanie dokumentacji referencyjnej interfejsu API. W obu przypadkach musisz zmodyfikować specyfikację OpenAPI, aby uniknąć korzystania z nieobsługiwanej funkcji do czasu jej obsługi w kolejnej wersji.

    Uwaga: edytor specyfikacji jest mniej restrykcyjny niż aplikacja SmartDokumentacja w przypadku renderowania dokumentacji referencyjnej interfejsu API, dlatego wyniki poszczególnych narzędzi mogą się różnić.

  • Gdy używasz w portalu tego interfejsu API, nagłówek Accept jest ustawiony na application/json niezależnie od wartości consumes ustawionej w specyfikacji OpenAPI.
dostawca tożsamości SAML W przypadku domen niestandardowych logowanie jednokrotne przy użyciu dostawcy tożsamości SAML nie jest obsługiwane. Aby włączyć domenę niestandardową z dostawcą tożsamości SAML, podczas konfigurowania ustawień SAML pozostaw pole Sign-out URL (URL wylogowania) puste.
Administrator portalu
  • Jednoczesne aktualizowanie portalu (np. strony, motywu, arkusza CSS lub skryptu) przez wielu użytkowników nie jest obecnie obsługiwane.
  • Jeśli usuniesz z portalu stronę dokumentacji API, nie będzie można jej ponownie utworzyć. Musisz usunąć i ponownie dodać usługę API oraz ponownie wygenerować dokumentację API.
  • Podczas konfigurowania zasad bezpieczeństwa treści może minąć do 15 minut, zanim zmiany będą w pełni stosowane.
  • Podczas dostosowywania motywu portalu zastosowanie wszystkich zmian może potrwać do 5 minut.
Funkcje portalu
  • W nadchodzącej wersji wyszukiwarka zostanie zintegrowana ze zintegrowanym portalem.

Znane problemy z Edge dla Private Cloud

Poniższe sekcje zawierają opis znanych problemów z Edge dla Private Cloud.

Powierzchnia Znane problemy
Luka w zabezpieczeniach Apigee HTTP/2

W wielu implementacjach protokołu HTTP/2 (CVE-2023-44487), w tym w Apigee Edge dla Private Cloud, wykryto ostatnio lukę w zabezpieczeniach związaną z brakiem usługi (DoS). Luka w zabezpieczeniach mogła prowadzić do działania funkcji zarządzania DoS w Apigee API. Więcej informacji znajdziesz w biuletynie na temat zabezpieczeń Apigee GCP-2023-032.

Komponenty routera i serwera zarządzania Edge for Private Cloud 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 brzegowych Edge dla Private Cloud, żaden z tych komponentów nie jest dostępny w internecie. W komponentach innych niż Edge, takich jak Cassandra, Zookeeper i innych, protokół HTTP/2 jest wyłączony. Aby usunąć lukę w zabezpieczeniach Edge dla Private Cloud, zalecamy wykonanie tych czynności:

Jeśli używasz Edge Private Cloud w wersji 4.51.00.11 lub nowszej, wykonaj te czynności:

  1. Zaktualizuj serwer zarządzania:

    1. W 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. W 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. Ponownie uruchom komponent procesora wiadomości:
      apigee-service edge-message-processor restart
  3. Zaktualizuj router:

    1. W 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. Ponownie uruchom komponent procesora wiadomości:
      apigee-service edge-router restart
  4. Zaktualizuj QPID:

    1. W 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. Ponownie uruchom komponent procesora wiadomości:
      apigee-service edge-qpid-server restart
  5. Aktualizowanie Postgres:

    1. W 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. Ponownie uruchom komponent procesora wiadomości:
      apigee-service edge-postgres-server restart

Wykonaj te czynności, jeśli używasz Edge dla Private Cloud w wersjach starszych niż 4.51.00.11:

  1. Zaktualizuj serwer zarządzania:

    1. W 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. W 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. Ponownie uruchom komponent procesora wiadomości:
      apigee-service edge-message-processor restart
  3. Zaktualizuj router:

    1. W 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. Ponownie uruchom komponent procesora wiadomości:
      apigee-service edge-router restart
  4. Zaktualizuj QPID:

    1. W 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. Ponownie uruchom komponent procesora wiadomości:
      apigee-service edge-qpid-server restart
  5. Aktualizowanie Postgres:

    1. W 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. Ponownie uruchom komponent procesora wiadomości:
      apigee-service edge-postgres-server restart
Uaktualnienie Postgresql podczas aktualizowania do wersji 4.52

W usłudze Apigee-postgresql występują problemy z uaktualnieniem usługi 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.

Możesz sprawdzić łączną liczbę tabel w Postgres, uruchamiając zapytanie SQL poniżej:

select count(*) from information_schema.tables

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

apigee-mirror w wersji RHEL 8.0

apigee-mirror nie działa w systemie Red Hat Enterprise Linux (RHEL) 8.0.

Obejście: aby obejść problem, zainstaluj apigee-mirror na serwerze z niższą wersją RHEL lub innym obsługiwanym systemem operacyjnym dla Apigee. Następnie możesz dodawać pakiety za pomocą powielania, nawet jeśli Apigee zostało zainstalowane na serwerach RHEL 8.0.

Zasada LDAP

149245401: ustawienia puli połączeń LDAP dla JNDI skonfigurowane przy użyciu zasobu LDAP nie są odzwierciedlane, a domyślne ustawienia JNDI za każdym razem powodują połączenia jednorazowe. W związku z tym połączenia są za każdym razem otwierane i zamykane do jednego użycia, co powoduje utworzenie dużej liczby połączeń z serwerem LDAP w ciągu godziny.

Obejście:

Jeśli chcesz zmienić właściwości puli połączeń LDAP, wykonaj poniższe czynności w celu ustawienia globalnej zmiany 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 poniższe wartości (zastąp wartości właściwości Java Naming and Directory Interface (JNDI) zgodnie z wymaganiami dotyczącymi konfiguracji zasobów 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. Sprawdź, czy plik /opt/apigee/customer/application/message-processor.properties należy do apigee:apigee.
  4. Ponownie uruchom każdy procesor wiadomości.

Aby sprawdzić, czy właściwości JNDI puli połączeń działają, możesz wykonać polecenie tcpdump w celu obserwowania zachowania puli połączeń LDAP w czasie.

Duże opóźnienie przetwarzania żądań

139051927: wysokie opóźnienia przetwarzania serwera proxy występujące 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 stosunku do normalnych czasów odpowiedzi interfejsu API oraz mogą występować losowo, nawet przy niskim współczynniku TPS. Ten błąd może wystąpić, gdy ponad 50 serwerów docelowych, z którymi procesor wiadomości nawiązuje połączenia.

Główna przyczyna: procesory wiadomości przechowują pamięć podręczną, która mapuje adres URL serwera docelowego na obiekt HTTPClient w przypadku połączeń wychodzących z serwerami docelowymi. Domyślnie to ustawienie ma wartość 50, co może być zbyt niskie dla większości wdrożeń. Gdy wdrożenie obejmuje wiele kombinacji organizacji i środowisk w konfiguracji i ma dużą liczbę serwerów docelowych, która łącznie przekracza 50, adresy URL serwerów docelowych są wykluczane z pamięci podręcznej, co powoduje opóźnienia.

Weryfikacja: aby sprawdzić, czy usunięcie adresu URL serwera docelowego powoduje problem z opóźnieniem, wyszukaj w pliku Message Processor system.logs słowo kluczowe „onEvict” lub „Eviction”. Ich obecność w logach wskazuje, że adresy URL serwerów docelowych są usuwane z pamięci podręcznej HTTPClient, ponieważ jest ona za mała.

Obejście: w przypadku Edge for Private Cloud w wersjach 19.01 i 19.06 możesz zmodyfikować i skonfigurować 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 w przypadku wszystkich procesorów wiadomości.

Przykładem może być wartość 500. Wartość optymalna dla Twojej konfiguracji powinna być większa od liczby serwerów docelowych, z którymi może się połączyć procesor wiadomości. Ustawienie wyższej właściwości nie będzie miało żadnych skutków ubocznych, a jedynym wpływem będzie skrócenie czasu przetwarzania żądań serwera proxy procesora wiadomości.

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

Wiele wpisów w mapach klucz-wartość

157933959: Równoczesne wstawianie i aktualizowanie tej samej mapy par klucz-wartość (KVM) o zakresie na poziomie organizacji lub środowiska powoduje niespójności w danych i utratę aktualizacji.

Uwaga: to ograniczenie dotyczy tylko Edge dla Private Cloud. W Edge dla chmury publicznej i hybrydowej nie ma tego ograniczenia.

Aby obejść ten problem, utwórz KVM w zakresie apiproxy.